プロジェクトのデイリーMTGで「PMの所感」という時間を設けて プロジェクトマネージャーとしての自身の”考え方”を伝えている。 その他にも社内のことや今のプロジェクトの良い点などを改めて伝えたりしている。最近だと、技術役員が僕に対して行った評価の中…
ハッシュタグは#agilesamurai #他流試合 アジャイルサムライ他流試合 : ATND 当日の臨場感はこちらのブログをお勧めします。 http://d.hatena.ne.jp/absj31/20110918/1316423657 http://d.hatena.ne.jp/absj31/20110919/1316423691 アジャイルサムライ他流試…
買った! そして開けた! Arduinoをはじめようキット出版社/メーカー: スイッチサイエンスメディア: エレクトロニクス購入: 60人 クリック: 1,090回この商品を含むブログ (51件) を見る
難しい問題をそのままに受け止めて難しいコードを書く必要はない。 というか、難しく書いてはいけない。今よりも先、あなたの作ったその難しいソースコードを 読むプログラマはその難しさに苦悩してしまうだろう。 難しい問題を難しいままに捉えるのは簡単だ…
そういえば社内読書会を開催してもらっていて、 実はちょっと前に読み終えていた。 これは良書。 今度アジャイルサムライの他流試合でLTに登壇する 予定なので改めて読み直している。 最近のプロジェクトにアジャイル開発を導入してみた失敗談や成功談の話を…
そのとおりだと思った。 結局実行されるのはソースコードのみ。 間違ってもソースコード内のコメントは実行されないし、 ドキュメントが実行されるわけじゃない。 人の言葉がそのまま実行されるわけでもない。もしドキュメントが存在しないのであれば「今あ…
新卒エンジニアが開催してくれた。registとかdatasってあるよねー、 といった話や変数名のつけ方やメソッド名のつけ方 について話した。 最近だと接尾辞にアンダースコアを入れたりするのが デファクトスタンダードらしい。やや脱線して開発環境がカオスにな…
プロジェクトの中で「暫定ソリューション(その場しのぎ)」を作ったことがある人は多いのではないかと思います。 (^o^)丿 私もです。 ほぼ間違いなく作ったことがあると思う。 とりあえず今はifでしのぐ! とりあえずIDとかベタ書きであとで直す! とかあっ…
「プロジェクトを見える化」しようという発想。 CI(Continuous Integration:継続的結合)サーバ用意してそのなかで静的コード解析ツールを走らせたり、テストカバレッジを設定して通知したり。 ところで通知には何を使うのか?メールか?IMか? このエントリ…
このエントリーはこのような表現でも意味が理解できる。 いろいろな人と目線を合わせる。プログラマだからといってコンピュータとのみ コミュニケーションをとっていれば良いというわけではない。ソフトウェア開発のプロジェクトチームの中に例えば プログラ…
「より少ないことは、より豊かなこと(Less is more)」。言い古された格言ですが、確かに真実です。 ミース・ファン・デル・ローエという方の言葉らしい。 余分なコードは決して書かない。確かにそのとおりだ。可読性も高まる。 そのコードのためのテストを書…
ダン・バーグ・ヨンソン氏のエントリー。 「今、どんな仕事をしているんですか」 プログラマ1「ああ、今、このメソッドのリファクタリングをしているところですよ」 プログラマ2「このWebアクションにパラメータをいくつか追加しているところです」 プログラ…
超人なんていない。 何も情報を与えられなくても、あらゆる質問に答え、あらゆる問題を解決できる。そんな人はいません。 社内にいるどんなに優秀なエンジニアも人なわけで完璧じゃない。 「ある超人的エンジニアに問題解決を任せると即時解決するんだよ!」…
ハードワーク=良いアウトプットとは限らない。 仕事は全力で面倒臭がる姿勢が重要だ(ただしアウトプットには誠意を持つこと)。 仕事には長い時間をかけず、集中して短い時間でおわらせるように心がける。 長く働くことを重視するのではなくて良いアウトプ…
これを読んでチームのデフォルトのバグ報告フォーマットに「本来の仕様」欄を追加した。 今まで概要、再現方法、該当の環境などなど書いていたが「本来の仕様」というものもかなり重要だなと思った。 バグレポートには必ず次の3つのことを書く必要があります…
APIを作って、そのAPIを守りたいからといって安易にfinal宣言などを使って該当のメソッドをロックするなという話。 確かに開発者側の行動に制約をもたせることができるが本当にそれが正しいのだろうか? APIの保守はそのAPIに関係するメソッドに対してのユニ…
オープンソースプロジェクトで世の中に貢献したいなあと思って早3年ぐらい経ったか。 まだ密接に関われていない。さて、オープンソースプロジェクトに参加する意義は何か? このエントリーには次の利点が挙げられていた。 多くの人の仕事ぶりを目の当たりに…
大切なこと何だけど、システム開発に魔法なんてない。 欲しいものはじっくり作ってしっかりと検証して慎重にリリースするしかないんだ。 なんとなく自分の欲しいもののラフ案を書いて、 適当に外注先に投げたら外注先の人が自分の欲しいものを すぐに動く形…
ちょっとタイトルがわかりにくいんだがこういう意味。 「言語だけでなく、言語に秘められた文化も学ぶ」以下はこのエントリーを書いたアンダース・ノラス氏の言葉 言語を学ぶというのは、ただ文法、構文を学ぶことではなく、その背景にある文化も学ぶこと 多…
このエントリーはたぶんテストデータを主に書かれているのだと思う。 テストデータはあまりに現実離れした(あるいは現実的だけど直視しがたい)ものを 入れるべきではない。 と、僕は考えている。 例えば開発機のユーザーテーブルにFuck!なんて文字列を入れ…
果たして「エキスパート」と呼ばれるだけの能力を身につけるには、 一体、どのくらいの量の訓練が必要なのでしょうか。 (略) 専門的な技術や知識は、ゆっくりと徐々に身につくものです。 1万時間が経過した途端、急に身につく、というわけではありません。…
変更を恐れないためには何が必要だろうか? 今の僕なら「最低でもユニットテストのテストコードは欲しい」と答える。 ユニットテストのテストコードが無いならプログラムの変更は恐れるに値する。 全然勇気出せない! 改良プロジェクトを実施するには、会社…
そのまんまですね。 技術的な例外、例えばDBにつながらない例外と、 ビジネス例外、例えば契約と契約の関連付けをユーザが誤って設定してしまう例外。 以上2つは異なる例外である。 このエントリを書いたダン・バーグ・ヨーンソン氏は技術例外とビジネス例外…
新しいことを始めると突如今まで解決してきた 問題と異なる問題が可視化される。プロジェクトが新しいイテレーションに移るとき、 新しいフェーズに移るとき、 リリースしたとき。新しい一歩を踏み出したときに新しい問題にぶち当たる。
第5回目(1週間続いた!)。このエントリーはDevelopersSummit2011でt-wadaさんが題目にしていたもの。 本当に身につけたい技術は、コードを自ら下記、手を動かして学ぶ 常に自分よりレベルの高い人と仕事をするようにする。 通勤時間が長い場合は、ポッドキ…
今まさにRESTでAPIを設計&実装をしていて頭を悩ませている。このエントリーに書かれていることは 「実装するものの利便性のみでAPIを提供してはいけない」 ということ。APIというのはApplication Program Interfaceの略で要はインタフェース。 ユーザであれ…
4回目。このエントリーを見てコードレビューの改善に動いた。このエントリーに出会うまでに実施していたコードレビューでは大した成果が出なかった。チームメンバーから今まで行っていたコードレビューのやり方に関して以下の指摘を受けた。 プログラムの全…
以前参加したAgile Conference Tokyo 2011のメモ。 ブログにUPしていなかった。 基調講演 マーティンファウラー氏Semantic Diffusion時が進むにつれて、人から人へ伝達されるにつれて本来のAgile開発が 希釈されてしまっている。我々はそれを危惧している。h…
LL言語を使っているとフレームワークを使う機会が多くなってしまったりして ちょっと複雑なバグを見つけたりすると「これフレームワークのバグじゃねー!?」 という態度をとってしまいがちだがそれじゃだめだ。 僕は昔あるMVCフレームワークを使っていて開…
はてなダイアリー×Facebook連携記念キャンペーン はてなTシャツほしい!