深夜に絶叫する子を抱っこしていると、いつから泣いてるのか、いつまで泣いてるのか、など考えてしまって精神的に参ってくる。 実際のところどれくらいのペースで泣いてるのか可視化したくなって、M5StickCで可視化するグッズを作った。 作りたいもの 常時マイク入力がオンになっていて、直近しばらくの音量の履歴が可視化されたら便利そうだと考えた。 可視化によって子が泣き止むわけではなくても、「しばらく泣いてる気がしたけどまだ3分くらいだ」とか、「10分間に渡って静かにしていて偉い」とか数値を見て客観的な考察をできるようになりたい。 M5StickC M5StickCは小型のM5Stack。 小さくて邪魔にならなさそうなのと、マイクがついているので買ってみた。 3000円以下で買ってきて書いたコードが動いて画面に表示もできるのでおもしろいと思う。 www.switch-science.com 実装する

たまに、今のこの状況は組織パターンに載ってたこのパターンだ、と思い出すことがある。数年前に読んでまだ役立ってる本のうちのひとつ。 今は「常に誰かが進捗させる」というプラクティスをやっている。それ自体はいいのだけど、問題なのは、チーム内チームのエンジニア二人チームでやっているので、一人が進捗させる、もう一人が差し込み対応する、という最小の形になっていること。 奥さんが家でやってる生け花教室のホームページを作る夫、みたいなものをイメージすると、奥さんが生花を教えることで進捗させて、夫がホームページ更新など雑務を巻き取るという構造をイメージできる。百人以上の人間がいる会社であっても、夫婦の生け花教室と同じ数の人のアサインでことを進めているのだとしたら、推進力では同じくらいしか出せないはず。実際には百人いる会社には経理の人がいたり総務の人が居たり、資本が潤沢にあったら良いパソコンを使えるとか、いろ

YAPCのスポンサーセッションで，DeNAの採用担当の方が話されていて，エンジニア文化への憧れから，コードの意味は分からないけど勝手にLGTMしたり，会場の発表スライドに載せるには不適切な画像を貼ったりしている，という発表をされていた． 単に迷惑そう，と思ったのと，それ以上に悲しくなって，自分たちが大切にしていることを軽んじられると悲しい気持ちになる． LGTMな画像を貼るのは，傍目から見ると，にぎやかな画像が出てきて楽しそうな雰囲気があるけど，画像を貼る前にはコードが正しいか検証しているのであって，ミスの許されないシリアスな場所でもある． 見た目がおもしろそうだからといって遊びに来られると迷惑だし，そういうライトな活動をするような，遊んでいるように思われていたのか，という悲しさがある． 逆に，そんなシリアスな活動をしているなら，そうと分かる真剣そうな雰囲気になっているべきという気もして，

Flowはfacebookが作ってるJSに型を書けるやつ． 今日ちょっと練習してみたところ良かった．練習に手頃なところから型でも書いてみるかとやっていたところ，FormDataにFileをappendするところで，それはFileじゃなくて?Fileで，nullになる場合もあるのでおかしいよって教えてもらったりした．型をつけるだけで不具合が見つかって，こういう世界もあるのか，という感じだった．fileがなかったらreturnする処理を足しておいた． ちょっとずつ書いていけるのがよくて，このファイルは難しいことをしていて型が付くと恩恵を受けられそう，とか，このあたりはこれからがっつり開発するので先に型を付けておこう，といった進めかたができる． 最初はちょっと慣れない部分もあったけど，ちょっと練習したら普通に書けるようになった．シンタックスがちょっと増えるので，どこまでJSのシンタックスで，どこ

ふだんソフトウェア作ってるけど，僕はエンジニアとしてはめっちゃしょぼい感じで，こないだは今年が2015年だと思って2015って書いておかしいなとか言って1時間くらい無駄にした．1時間後に2016に直したのだけど，すごいエンジニアの人を見てると，その1時間の間くらいでも，すごい活躍されていたりする． みんな1日n時間くらい働いているはずで，すごいエンジニアはそのm倍みたいな時間働かれているわけではない．同じくらいの時間活動していても，活躍度合いは全然違う．ということは?? コードを書くのが速い 速くできるとすごい 腕の筋肉がすごい タイピング速そう 考えるのが速い 人によってそんなに差あるものなのか? 取り組むと効果ありそうなことを見極めるのがうまい いいことできるとすごい やっても大した効果が出ないものは後回しにするとその時間を使って効果のあることをできそう ちょうどいい作りこみ度合いのも

弊社では毎年インターンを受け入れているのだけど，いまもインターンが来てて，テスト先に書きたいけど油断すると先に実装を書いてしまう，とか話してた． 個人的には，テスト先に書くのが大事というよりかは，意識して仕様を先に考えるのが大事だと思っている．テストを先に書くと，先に仕様を考えざるを得ないので，良いスタイルが身につく． 僕がよくやるのは，関連しそうなクラスの絵をひと通りノートに書いてみて，その図だけで，うまく動くことを説明できるくらい考えてみる．その時点でおかしかったら，コード書いてもおかしくなる．ノートに方眼ついてるとクラス図書きやすい．UMLとかじゃなくても，自分で見て分かるくらいでもいいと思う． 紙でうまくいったら，外部仕様だけソースコードに書いてみる．クラス名と，メソッドの定義と，メソッドの上くらいに，ひと通りコメントでも書いてみて，この関数はこういうことをするんです，こういう引数