hitode909の日記

以前はプログラミング日記でしたが、今は子育て日記です

2010年〜2016年に書いていたアイデア帳をScrapboxに置いて供養

学生の時から、思いついたことをidea.txtというテキストファイルに書き溜めていて、Dropboxで同期して大切に持っていた。そこから、これはおもしろそう、とか役に立ちそう、と思ったものはピックアップして調べたりコードを書いたりブログに書いたりしていた。
Dropboxのmemo/ってディレクトリにテキストファイルをちまちま作っていて、どこに何があるか全く覚えていないけど、idea.txtだけは存在を覚えている。
f:id:hitode909:20200515031606p:plain


最近は、思いついたことはTodoistに入れて終わったら消していっていたので更新していなくて、昔のidea.txtを手元で眠らせておくのももったいないな、と思ったのでScrapboxに上げておいた。2010年から2016年まで、6年分置いてあります。
scrapbox.io

2010年、2011年くらいは本当にいろんなことを書いていたけど、仕事しだしてからは、仕事にリソースを奪われていって文量が下がっていっているのが分かった。
とりあえず、個人情報とか出したら不味そうなものを消して体裁を整えて貼っただけで、長大な1ページになっている。話題ごとにグルーピングしたり、1ページ1アイデアにできると新たな発想が生まれて面白そうだけど、ここから新たな何かを作ろうという気はあまりなくて、いまのところゴミ捨て場という雰囲気。

せっかくなので、おもしろかったのをいくつか紹介しておきます。

朝 = 時間ない = 音でインタラクション
気温を音で，midiでぽろぽろするとか

最近はスマートスピーカーとか登場していて、可聴化じゃなくて、普通に機械が読み上げてくれるようになっている。

Eclipseの補完のとこにグルーポンとか出る
語呂の合った広告

補完のコーナーに広告が出るのはまだ体験していない。

砂糖が出てくるデバイス

よくわからないけどよさそう。

人の携帯に音を送れるとか
↑ ボイスメッセージでは

2行目で真実に気づいていた。

分かち書きして繰り返す
リズム
すっぱい、すっぱい、すっぱい、

こういう勢い重視のメモもが多い。

重ね着おすすめサイト
開くと，その日の天気が出て，どれくらい重ね着すればよいかおしえてくれる
鍋おすすめとか
スマートフォン 1ページだけ

今日の重ね着を作ろうって思い立ったときのメモ。鍋をおすすめする機能は実現しなかった。

機械で判定するときにも，統計的に，このプロジェクトはこういう感じなので，こうしませんかみたいな，空気を読んでくれると便利そう．人がいちいち，このプロジェクトのコーディング規約は，みたいに書くのはだるい

フォーマットのルールを人間が書くんじゃなくて、既存のリポジトリを正として、インデントとか自動でやってほしいよなというのは、今でも思っている。

ソースコード解析して 変数名だけ消す $1, $2にしてから、 頻出部分を
頻出…どうやって!!!

やりたいことはあるけど手法を思いつかなくて、その瞬間にあきらめている。

perlのクラスリネームスクリプト

ここで思いついてメモしておいたおかげでPerlのリファクタリングツールを作れた。



みなさまもお手元のアイデア帳をインターネットに大公開しましょう。アイデアだけ持っていても仕方なくて、実現したり、共感する仲間と一緒に作れたりして、ようやく価値がでてくると思う。

夢と狂気の王国

『「もののけ姫」はこうして生まれた。』が好きなんですって話をしてたら紹介してもらえたので観てみた。風立ちぬを作ってるときのドキュメンタリー。もののけ姫のときみたいにピリピリした雰囲気じゃなくて、世の中にはいろんなタイプの人がいるな〜という記録という感じだった。
宮崎駿が、僕はオタクじゃないですって言った次のカットで、庵野秀明と二人並んでゼロ戦のフィギュアで遊んでるのが最高だった。
基本的に宮崎駿はもごもご話していて聞き取れないのだけど、見てるとだんだん聞き取れるようになっていく。七人の侍を観ても、最初の方のカットは全然何言ってるかわからないけど、慣れるとだんだん聞こえるようになっていく。そんな感じ。

夢と狂気の王国 [Blu-ray]

夢と狂気の王国 [Blu-ray]

  • 発売日: 2014/05/21
  • メディア: Blu-ray


崖の上のポニョのドキュメンタリーもあってこっちは12時間あるらしい…。これも買ってみたので次に観ます。

ポニョはこうして生まれた。 ~宮崎駿の思考過程~ [Blu-ray]

ポニョはこうして生まれた。 ~宮崎駿の思考過程~ [Blu-ray]

  • 発売日: 2009/12/08
  • メディア: Blu-ray

自分のブログから毎日なにかしら検索している

大半のことはブログに書いてるので検索するとだいたい出てきて便利。
たぶん毎日書くのが重要で、たとえばこの記事の内容を1年ぶりのブログ更新で出すのは気が引ける気がするけど、毎日書いてる日記の一つなら、ブログに毎日書いていると便利ですぞって話が出てきても、まあそういう日があってもいいだろう、となりそう。

仕事してたり1on1していたりしても、その話題なら、こういう本がありましたよって本の感想の記事を紹介したり、私もそういうことで苦労していて、そのときはこういう日記を書いてましたって紹介したりしている。その場で説明するよりは、文字に書いてあって関連するリンクがでてくるほうが早くて手っ取り早そう。


技術トピックでは、masawada、で検索することが多くて、masawadaさんの提供してくれている各種素材を使って、触ったことない技術の実験に使っている(人体実験)ので、あのときやった実験はどこいったかな、というときに、とりあえずmasawadaで検索することになる。
masawada の検索結果 - hitode909の日記

コードを書くには連続した2時間が必要

ある日の午後のスケジュールは、30分ミーティングx2→30分自由時間→そして1.5時間ミーティング、その後は30分自由時間と30分ミーティングを繰り返して定時を迎える…みたいな様子だった。案の定、自由時間で意味ある仕事を進めることはできなかった。
自由な時間が30分あれば、チャットを読んだり、コードレビューしたり、グループウェアを見て回ったり、とかはできる。コードを書くにしても、ここをこう変えれば良いことがわかっていて、書くだけ、とか、ライブラリのバージョンアップ、くらいなら30分で書いてpushしておいて、次の30分でテストが落ちたら直したりして、と進められる。
しかし、そういうことより難しいことをしようとすると、30分だと、さて、問題がどういうものかは分かってきたので、どうしようかな、というあたりで時間切れになってしまう。1時間あれば、ようやくコードを書き始められるかな、というところで時間切れになるので、やはり進捗はない。

最近の体感値では、2時間以上連続した自由時間がないと、メインの仕事として持っているような大きな仕事だったり難しい仕事は進められないことがわかってきた。で、2時間あれば必ず進むわけでもなくて、やってみたらいまいちだったね、といって終わることもある。
試行をするにも2時間くらいは必要と分かってきたのでので、ミーティングを入れるときはなるべくほかのミーティングの前後にくっつけたり、午前中に詰めていったりして、なるべく午後に時間を作るようにしてみている。

連続した時間を得られるという点では夜とか週末とかは魅力的なのだけど、そこでがっつり進捗を出す暮らしになってしまうと、そこから抜け出せなくなってしまうと思う。先月は週末にめちゃくちゃ仕事していたけど今月はやってない、となると週末の営みの影響によって急にベロシティが下がることになる。

Creating Documentation in an Agile Scrum Environment

普段メンテナンスしているプロダクトの仕様について、うまいストック情報を作れていないという課題感があって、世間のノウハウを知ろう、とKindleで適当に買った本を読んでみた。
スクラムチームに所属しながら製品のコンシュマー向けのドキュメントを書くためのテクニカルライティングの本。

読書メモ

  • アジャイル開発について学んでもライターについての記述はなく、ステイクホルダーにも入っていない
  • 包括的なドキュメントよりも動くソフトウェアを、という宣言があるけど、コンシュマー向けのドキュメントが不要になるわけではない
  • ドキュメントを書かずにプロダクトを作り終えたり、完全にプロダクトを作り終えてからドキュメントを書くことができるプロダクトも存在する
    • メールアプリのドキュメントを読んだことがありますか?
  • スクラム環境でドキュメントを作るには2つのパターンがあり、デベロッパのスクラムチームに所属するパターンと、情報部門(Information Engineering Team)に所属するパターン。アジャイルの各工程 x 2パターン、でそれぞれどのように振る舞うとよいかが記されていて、さくさく読んでいこうとすると、では次の場合は…みたいになってテンポが落ちる
  • スプリントでの開発とドキュメントをどのように折りをつけるか、3パターン紹介されていて、開発が終わってからスプリントを始める、というウォーターフォールっぽいもの、関連するストーリーとして同じスプリントで取り組む、同じストーリーで取り組む、という3パターン

感想

新機能とその告知ブログをセットでリリースしているような開発をしているチームの人たちにはおすすめの本だと思った。開発とドキュメントづくりがうまく連携しない場合の例としては、エンジニアが一通り開発して、QAが済んでから、では告知のブログを書きましょう、とやっていると、書いたコードをマージできない間に他の開発が進んでコンフリクトしてしまったり、開発と告知の編集のあいだに情報の分断が起きていることがあった。

また、最近チームに所属する人の職種が増えているので、職種ごとに、どのようにアジャイル開発に関わっていくかという方針建てが必要なのだなと思って、この本ではライターはステイクホルダーとみなされていない、という話だったけど、いろんな立場の人がうまいこと活躍したり、情報の分断が起きないような取り組みがあるとよさそうだな、と思った。チームがでかくなると全員で集まるのも難しくなっていくけどそれは別の話で、ピザの枚数で制限をかけましょうという話があったり、組織構造とソフトウェア構造を一致させましょうという話があったりする。

タスクのチケットごとにドキュメントの更新が必要かどうかをトラッキングできるようにしましょう、という話がのっていて、ドキュメントが成果物の第一級の仲間たちとして認められている世界が提示されていた。実装とドキュメントづくりが同じユーザーストーリーなら、マージしたりレビューしたりするまでの間にドキュメントのレビューも入るはずで、実はここも変更が必要ですとか、専門的な知識が必要となるレビューが始まりそう。そのようなレビューができる人を得るにはどうしたらよいのか、数年ごとに社内のチームをあちこち異動していると、知識の定着がなくて難しいのではないか、とか考えていた。


どのようなドキュメントをどのように整備すれば運用中のソフトウェアの仕様を必要十分に記せるのか、というヒントを得たかったけど良いアドバイスは得られなくて、ドキュメンテーションを支える人の暮らしについて教えてくれる、という本だった。


www.amazon.co.jp