仕事
これを読んでチームのデフォルトのバグ報告フォーマットに「本来の仕様」欄を追加した。 今まで概要、再現方法、該当の環境などなど書いていたが「本来の仕様」というものもかなり重要だなと思った。 バグレポートには必ず次の3つのことを書く必要があります…
APIを作って、そのAPIを守りたいからといって安易にfinal宣言などを使って該当のメソッドをロックするなという話。 確かに開発者側の行動に制約をもたせることができるが本当にそれが正しいのだろうか? APIの保守はそのAPIに関係するメソッドに対してのユニ…
オープンソースプロジェクトで世の中に貢献したいなあと思って早3年ぐらい経ったか。 まだ密接に関われていない。さて、オープンソースプロジェクトに参加する意義は何か? このエントリーには次の利点が挙げられていた。 多くの人の仕事ぶりを目の当たりに…
大切なこと何だけど、システム開発に魔法なんてない。 欲しいものはじっくり作ってしっかりと検証して慎重にリリースするしかないんだ。 なんとなく自分の欲しいもののラフ案を書いて、 適当に外注先に投げたら外注先の人が自分の欲しいものを すぐに動く形…
ちょっとタイトルがわかりにくいんだがこういう意味。 「言語だけでなく、言語に秘められた文化も学ぶ」以下はこのエントリーを書いたアンダース・ノラス氏の言葉 言語を学ぶというのは、ただ文法、構文を学ぶことではなく、その背景にある文化も学ぶこと 多…
このエントリーはたぶんテストデータを主に書かれているのだと思う。 テストデータはあまりに現実離れした(あるいは現実的だけど直視しがたい)ものを 入れるべきではない。 と、僕は考えている。 例えば開発機のユーザーテーブルにFuck!なんて文字列を入れ…
果たして「エキスパート」と呼ばれるだけの能力を身につけるには、 一体、どのくらいの量の訓練が必要なのでしょうか。 (略) 専門的な技術や知識は、ゆっくりと徐々に身につくものです。 1万時間が経過した途端、急に身につく、というわけではありません。…
変更を恐れないためには何が必要だろうか? 今の僕なら「最低でもユニットテストのテストコードは欲しい」と答える。 ユニットテストのテストコードが無いならプログラムの変更は恐れるに値する。 全然勇気出せない! 改良プロジェクトを実施するには、会社…
そのまんまですね。 技術的な例外、例えばDBにつながらない例外と、 ビジネス例外、例えば契約と契約の関連付けをユーザが誤って設定してしまう例外。 以上2つは異なる例外である。 このエントリを書いたダン・バーグ・ヨーンソン氏は技術例外とビジネス例外…
第5回目(1週間続いた!)。このエントリーはDevelopersSummit2011でt-wadaさんが題目にしていたもの。 本当に身につけたい技術は、コードを自ら下記、手を動かして学ぶ 常に自分よりレベルの高い人と仕事をするようにする。 通勤時間が長い場合は、ポッドキ…
今まさにRESTでAPIを設計&実装をしていて頭を悩ませている。このエントリーに書かれていることは 「実装するものの利便性のみでAPIを提供してはいけない」 ということ。APIというのはApplication Program Interfaceの略で要はインタフェース。 ユーザであれ…
4回目。このエントリーを見てコードレビューの改善に動いた。このエントリーに出会うまでに実施していたコードレビューでは大した成果が出なかった。チームメンバーから今まで行っていたコードレビューのやり方に関して以下の指摘を受けた。 プログラムの全…
LL言語を使っているとフレームワークを使う機会が多くなってしまったりして ちょっと複雑なバグを見つけたりすると「これフレームワークのバグじゃねー!?」 という態度をとってしまいがちだがそれじゃだめだ。 僕は昔あるMVCフレームワークを使っていて開…
第2回目。この中で幾つか書かれているのだが3つ抜粋。 すべてをゼロから書き直したくなるが、その衝動に打ち克たねばなりません 個人の好みやエゴを入れてはいけません 人間は必ずミスをする、というのを忘れないでおきましょう 本文内ではこの3つに対してさ…
今のプロジェクトでPMをやっていて毎朝議題に 「PMの所感」というgdgdなコンテンツを 含めているのだけど何かもっと有効活用できないかと 思っていたところ久々に「プログラマが知るべき97のこと」を 読みなおしてこれについてブログ書いて朝会と連動す…