サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
katzchang.hatenadiary.org
ポイントは 真っ先にコードをぶっこわせ! いやその前にバージョン管理に突っ込め! 安全にコードをぶっこわせ! 仕様化テスト書こうぜ! で、ようやく機能追加なりリファクタリングなり不具合の改修なりができる状態になります。 以下詳細。 …と、続けようとしたんですが、 短いサイクルで変更し続けるコードを示すには時間なり紙面なり根性なりが色々足りないので、gitのコミットを採って公開しつつ解説を入れようとも思ったんですが、コードをちょっと変更してJUnitの実行ボタンを押して git commit -a -m "いちいちコメント" などをしてたら5周目くらいに「うがー!」となったので、JUnitが実行されるたびにgit commitしてくれるようなEclipseプラグインが欲しくなりました。いまココです。 TDD Boot Camp名古屋のときも、結局最初のコミット以降ずっと忘れてたというなんとま
あなたにとって新しい視点を与えるものであれば、それはアートである。 で、考えてみれば良いよ。 例えば「ある人が、『これアートである』と主張している」こと自体は自分には関係ない。としても、自分がそれを見た/体験したときに「新しい視点」を特に感じなかったが、他の人の解説を聞いたことにより、改めて「新しい視点」を感じることができたなら、自分にとってアートであると考え直してもよい。 「アート」なんぞには徹底的に造詣の浅いオレからすれば、こんな糞下らない詐欺を保留付きでも「アート」と仮定できる神経が分からない。有村や高橋は、それが「アート」である可能性を「論理的」に説明すべきである。ぐにゃぐにゃとした訳の分からない言辞を弄するのであれば即座に偽物と看做して構わない。仮にそれが「アート」であった場合でも、「作品」の公開は被害者並びにその親族が誰も異を唱えなくなる未来まで停止すべきであろう。そして、時を
「リファクタリングが必要だと感じたときに、リファクタリングすべきである」 2009年12月のTDD Boot Campにて、"Test Driven"の著者であるLasse Koskela氏に頂いた回答。 必要だと感じてから時間が経過したあとでは、リファクタリングすべき(つまり汚い)コードに依存するコードが増え、整理する対象が増えてしまう。必要だと気付く以前には、当然手を付けられるはずがない。 一流プログラマの感覚的な指針ではないんだよね。
5/1に「@nagise 裏勉強会」が行われました。参加者は11名くらい、内容は自己紹介を兼ねたLT大会でした。id:Nagise,ご結婚おめでとうございます。 自分のネタは課題管理関連。社内向けに資料を考えていたメモをEvernoteに残していたので、説明しつつツッコミを頂くスタイルで発表させて頂きました。ありがたい。 以下、メモを加筆修正したものでございます。 タスク管理の重要性 言うまでもありません。 Excelによる課題管理は破綻する 不吉な匂い メンバーの増加 5名程度が限界 小さいがクリティカルなタスク(不具合など)が管理しにくい 優先順位付けとか 元のフォームが悪いんじゃない? 異なる拠点(自社、元請け、客先、別の客先… 増える資料(課題票、課題一覧表、線表、問題処理票&一覧表、…) これらの条件でも管理稼働を最小にしたい タスク管理サービスの導入 Redmine(うちのチー
3/13-14に開催したTDD Boot Camp 北陸から、もうすぐ1週間。幹事*1の立場から、ふりかえります。 まずは… 集まって頂いた方々、おつかれさまでした&ありがとうございました。遠方は首都圏、愛知、大阪からも、多数の参加を頂きました。どんだけ気合いが入ってんだよ!和田さんには、北陸での講演&コーチを快く受けて頂いて、本当に感謝しています。 把握してる限りの、皆さんの感想エントリです。 TDD Boot Camp 北陸に登壇させていただきました - t-wada の日記(旧) TDD Boot Camp北陸に参加してきて - M-Tea TDD Bootcamp 北陸を終えて(@fujiwoさんとの議論) - M-Tea TDDBC北陸参加してきた - logging.info(self) TDD Boot Camp北陸 - 感想とか - ひたすらプログラミング日記 あーありがち
参加者アンケートより。 想定バグ検出件数とか、昔からなぜかある指標を打ち倒すこと やろうと思ってもなかなかできない・・・ モックのライブラリー等を使ったテストケースの書き方。すべてのテストケースの実行時間の短縮 知識のみで実際の経験がないこと。テストを書くのが難しいためテストケースを書けない場合がある。 テストを先に書く文化がなかなか根付かない→テストできないコーディングをしているorz 社内が従来のやり方に固執している為、新しい手法が試せない。 テストドリブンな手法を開発以外の分野にも適用してみたい。 マルチスレッド関連のテスト方法が分からない。 BDDなど、他のテスト技法(?)との使い分けが分からない。BDDはTDDの一部? 他のクラスが必要で、テスト対象クラスのインスタンス化ができないやつとか、データベース使うやつのテストコードの書き方が分からないので、勉強が必要だと思う。 開発時点
次の次の週末は、TDD Boot Camp 北陸です。 ということで各種お知らせ、(たぶん)第一弾です。 行きの交通手段について 高速バスの場合、今すぐに予約をとりましょう。週末の東京-金沢は10日前には予約で満席になります。 http://www.kakuyasubus.jp/kanto_hokuriku/kanazawa_express/index.htmlなどから予約! 金沢、小松に着いてからの交通手段 金沢駅から自家用車で、8時30分位に出発する予定です。わたくしが。残り3名、ご希望があればメールまたはtwitterにてご連絡ください。希望者多数の場合、遠方の方優先とさせてください。 小松駅・空港からも、迎えに行く方向で調整します。 TODO:北陸エンジニアグループMLへお願いメールを出すやっぱり、参加者の中でやりとりする感じにしよう。もしくは、これをご覧の方で「俺いくよ」という方
今んとこはこんなイメージです。 *1 TDDで作るテストコードは、開発者が意図している仕様となっていることを保証している、と言う部分は言い切っちゃっていいような気はする。問題は、その仕様が要件を満たすとは限らないということ。最悪のシナリオは「仕様を保証するテストコードはきっちり出来たけど、ユーザが欲しいものは何も出来なかった」。よくある、古典的な課題の一つです。 要件を確認しながら「小さな一歩」を続けられるかってことなんだろうかなぁ。「目の前の問題に集中しろ!たまには周りを見渡せ!」っていう、相反した要素が求めらるわけですよ。これが、ペアプロとの相性がいい理由かな。 この辺りを夜な夜な語り明かしたい方々は、 TDDBootCamp北陸に是非お越し下さい(宣伝 *1:https://cacoo.com/diagrams/C1YxffZJT0r38ey6
自分たちが、持続可能なペースで製品をリリースし続けることができるようになること。 日々の仕事の中で獲得する知識と経験を取り込みながら、開発を加速していけるようになること。 自分たちの持てる力を発揮できるようになること。 確信を持ってコミットできるようになること。 反省し、失敗に学ぶことができるようになること。 ユーザにとって使いやすい製品を創り出せるようになること。 ユーザの課題と向き合えるようになること。 ユーザに価値ある製品を開発できるようになること。 関わった全ての人が、早く家に帰り、有意義な人生を送ることが出来るようになること。
2010-03-13 (- 2010-03-14)は、TDD Boot Camp北陸です。 皆さまおなじみのid:t-wadaが、ついに北陸に襲来。 ペアプロしようぜ!コード見せ合おうぜ! 終日のTDD Boot Campコースと、1泊2日のガッツリ合宿コース。 山の中の天然温泉。 参加費は500円と8,500円。 お申し込みは、http://kokucheese.com/event/index/1307/からどうぞ。 さぁ、みんなで楽しみましょう。
自由回答欄がいい感じにいい感じなので、だーっとコピペします。 引き続き、このアンケートにご協力頂けるかたを募集しています。TDDBC北陸に参加してみたい方はもちろん、興味はあるけど参加はできなさそうな方なども、ぜひご協力ください。 アンケートは => http://bit.ly/6ToL7W イベントの参加募集は、1/12くらいから始める予定です。参加表明っぽい設問がありますが、改めて募集しますので、今しばらくお待ちください。顔。 あなたが自動テストを使って開発しているなかで、課題となっていることがあれば、教えてください。 TDDを既に実践している テストの資産価値。今後役に立たない/足枷となるテストをいかに捨てるか。 スローテスト。 テストしにくいもののテスト。JavaScript や GUI など。 「テスト」という用語がもたらす誤解。お客様には品質保証として捉えられがち。都度説明して
リファクタリング・ウェットウェアを読書中です。 自身のふりかえりにも丁度いいので、第1章の「さっそく実行」をさっそく実行してみます。 自分自身を評価してみてください。 Java : 上級者 根拠 : とりあえず、綺麗なコードは書けるとの評価を頂いたので。 仕事へのインパクト : 今の案件はコードは書かないが、ほぼJavaで組まれているので、読んだり調べたり改造してみたりは問題なく、設計する上での調査や納品されたソースコードのレビューなど多くの場面で、他のチームと比べて優位性がある。 イザとなれば自分(達)で何とかなるという自信にもつながっている(が、これは良し悪し)。 仕事上で使うツール類も自作出来るので、業務効率化に繋げている。 次のレベルに進むために: テスティングへの理解と経験。実プロジェクトへのユニットテスト適用での課題とか、分かってない。 フレームワークへの理解と経験。DIやAO
仕様変更その2まで対応。 Clockオブジェクトを導入 記事にしやすいよう、モッククラスをテストないに記述してるけど、分けた方がいい。 でも、Clock.SYSTEM_CLOCKは、interface Clock内に定義すべき。通常使うだろう、デフォルトオブジェクトがわかりやすいはず。 容量変更のメソッド(fixCache())と時間でクリアのメソッド(deleteDeadCache())を分けた。 理由は、put/getメソッド内でのcache.putとcache.getとの前後関係を同じようにするため。 この一歩手前までは、fixCache()内に2行記述していた。そうすると、get時はget前に、put時はput後にfixCache()を呼ぶ必要があった。 これで、重複が出来た。が、どうやって取り除こうか。 生存時間と容量も、KeyHolderに移動。 これで、外側のオブジェクトはほ
外部から納品物に自分たちが手を入れるような場合や、他の人が作ったパッケージ製品を改造して提供するような仕事を管理する場合に使えるパターンです。つまり、SI業界には必須ともいえるパターンなはず。 レポジトリにvendorディレクトリを切っておき、その下でベンダから受領したブツを管理する。納品毎にバージョンtagをつける。そこから枝分かれさせたものを、自分のプロジェクトのサブディレクトリとして管理していく。こうやって管理することで、ベンダからの受領物を自分のプロジェクトにマージするときに、SVN力をいかんなく発揮させることができます。 参考:http://hide.xsv.info/tips/svnmanual/merge3/ 今更な人には今更だろうけど、今更じゃない人には今更じゃないよっていうのがこのセカイですので、もう気にしてません。サンタさん、僕はオトナになったよ…。 レポジトリの構成(
「一番大事なことは最初に言う」とのことなので、大事なことから順に書きます。 反芻してるうちに思い出したら、追記するかもしれません。 ペアプロの前半のパートナーである@kozy4324とともにミルズ賞を受賞しました。 「前半のペアでコードが綺麗だった。私はJavaはわからないが、何が書いてあるのか、どう動くのかがわかった。後半にペアを変えても、それぞれのペアで綺麗なコードを書いていた。」とのこと。最大級の栄誉です。 個人的な理由の一つは、「いわゆるJava」っぽくないJavaが好きなので、Javaに慣れていない人向けなコードを書いていたこと。もう一つは、TDD読書会で存分に予習できていたことです。 @kozy4324はもちろん、TDD読書会のメンバーにも感謝です。 TDD Boot Camp Hokurikuを企画中です。3月予定。コーチ役としてid:t-wadaは欠かせないでしょう。Mic
というわけで、晒します。 前半は@katzchang・@kozy4324のペア。後半は@katzchang・@yugoriのペア。 Eclipseは独自に履歴を持っているので、2パターンを引っ張り出してきました。クラス宣言部にカーソルを当てて右クリックからLocal History。たぶん20セーブくらいしか保持してないけど、たまに助かることもあります。 仕様変更直後くらい ということで、仕様変更直後くらいのセーブから。大体の時間で取っているので、REDな組み合わせかも知れません。 基本的には、テストコードは下に順に追加していっています。上にある項目から順に、プロダクトコードを作り込んでいったってことです。 第一の仕様変更(キャッシュサイズを変更できるようにする)まで対応済、第二の仕様変更(一定時間が経過したデータはキャッシュから消える)に対応しようとしたら、既存機能にバグの疑いがあり、バ
TDD読書会+北陸エンジニアグループ2009ふりかえりをしたよという話です。「http://atnd.org/events/2067」←これ。 今回は偶然にも来沢(金沢用語)していた串田さん(@kussy_y)に、ふりかえりのファシリテーター役をしていただきました。おかげさまで、自分も一人の参加者としてふりかえりに参加することができて、とても有意義な時間を過ごすことができました。さんくす!! 相当な無茶振りに快く応えていただいた串田さんには、石川名物の「とり野菜みそ(2種詰め合わせ)」をもれなくプレゼント。知る人ぞ知る地元民御用達のスーパー「ナルックス」で購入。土産物屋には売ってない…よね? 全体的には、グダグダ駆動で進めさせていただきました。相変わらずというか、こんな性分ですいません諦めましょう。 TDD 申し訳ない、こちらは途中で抜けてました。 過去2回は、10人未満であーでもないこー
なら上司がやれよ。
中くらいのジャガイモ1個をたわしなどで十分に洗い、皮付きのままスライサーで薄くスライスする。包丁じゃ無理です。 ほぐしながら水に入れて10分ほどさらし、水気を取る。水分を吸って、スライス直後よりも張りがでるはず。 低めの温度、160℃くらいに熱した油にほぐしながら入れて揚げる。たまに全体を混ぜてほぐす。箸などで混ぜながら感触をみて、柔らかくなって、固くなって、カリカリしてきたら出来上がり。 塩などをかけて食べる。 「デイリーポータルZ:揚げたてのポテトチップスは凄く美味しい」を読んで、あーそういえばと。記事の中では「スライス重要!」と言ってたけど、これはその通り。家庭で作るときはどうしても厚くなるので、ケトルチップスっぽい仕上がりになります。この辺はお好みで。 揚げイモネタとしては最近「デイリーポータルZ:マックポテトを作りたい」ってのもあったけど、カリカリに仕上げるコツは共通するものはあ
http://horicky.blogspot.com/2009/11/nosql-patterns.html 11/30時点で、一通り翻訳のうち、正直ベースのざっくり感覚(業界用語)で75%完了です。 本人も理解が怪しいながら訳しているので、随所に間違いを仕込んでいます。ご指摘頂ければ幸いです。 NOSQL Patterns ここ数年、大規模データを扱うデータストレージ機構が発展している。これらの機構は従来のRDBMSモデルとは異なっており、NOSQLとも呼ばれている。キープレイヤーとしては: GoogleBigTable, HBase, Hypertable AmazonDynano, Voldemort, Cassendra, Riak Redis CouchDB, MongoDB これらは、次の共通点を持っている。 Key-Valueストア 多数台の一般的なPCで運用可能 複数サー
「一緒に働いてくれる人を募集とか呼びかけてみる - レベルエンター山本大のブログ」について。 採用サイトが更新されたようなので、内容について疑問に思ったことをぶつけてみます。 本来であれば電話かメールで問合せるべきかもしれませんが、ブログで呼びかける熱い想いに便乗しつつw、こちらで質問を書いてみます。なんと言うか、常々疑問に思ってることでもあり、「一般論として」で十分なので、色んな方からもご意見を伺いたいです。 「大中規模の〜」とありますが、規模とは何のボリュームをさすのでしょうか(ユーザ数?データ数?ステップ数?)?また、どの位が中規模以上となるんでしょうか? 「32歳まで」という年齢制限を設ける理由について教えて下さい。*1 「システムエンジニア(Java - 共通機能開発)」について、自分の経験上、フレームワークはオープンなものを自分達で組み合わせる、もしくは客先から指定されるパター
カルボナーラを作る3つのコツ ペペロンチーノを作る3つのコツ 茄子とトマトのパスタを作る3つのコツ slideshareはflashのエラーを出すから、張りません>< 考察 チーズはパルミジャーノレッジャーノの一択でおk。買い物は前日に済ませれば良かった。 片付け手伝って頂いた方、ありがとうございました。準備と片付け込みで2時間余り、相当疲れた。 食べて頂いた方、ありがとうございました。 カルボナーラ、やっぱ難しいわw
http://atnd.org/events/1825 演目と発表者のリストです。 間違いなどあればご指摘ください。 ブログなどURLがあれば載せていきます。 発表資料などがあれば追記します。TBなど、お知らせ下さい。 感想エントリも、もちろんTB!一言でもおk! 参加者のtwitter listは => http://twitter.com/shiget84/hokuun その他雑多な情報は多分 => http://b.hatena.ne.jp/t/HokuUn?sort=eid まとめwiki => http://www20.atwiki.jp/hokuun/ 北國新聞に記事が載りました => http://www20.atwiki.jp/hokuun/pages/70.html 11:00- ウォームアップ akky http://akimoto.jp/blog/2009/11/02
元ネタ What Kind of Differences? Consider the following class. It defines an object that is able to record all the messages ever sent to it, and then playback those messages to another object. 以下のクラスは、オブジェクトに送られた全てのメッセージを記録し、他のオブジェクトで再生することが出来るよう、定義されている。 class VCR def initialize @messages = [] end def method_missing(method, *args, &block) @messages << [method, args, block] end def play_back_to(obj)
夫婦別姓より、非嫡出子の差別とか、ひとり親(行政用語)支援とかの方が問題だと思っているよ等と先日のエントリに書こうとして結局消したんだけど、その関連。 高崎経済大学教授の八木秀次氏のご意見。 −−民主党は「選択的夫婦別姓の早期実現」を政策集に盛り込んでいる 「過去に提出された民法改正法案の内容は、極端な個人主義に立脚した主張だ。民主党政権発足後に出てくるのも同様の主張だろう。彼らは別姓の導入と、婚外子の相続差別や女性の再婚禁止期間の見直しの3つをセットで主張する。犠牲になるのは本妻であり、嫡出子だ。同姓は戦前の家制度を引きずっているという主張があるが、戦後の民法は核家族を基盤とする制度であり、推進派が解体しようとしているのは核家族だ。別姓だけを見ると選択を誤る」 【金曜討論】夫婦別姓 八木秀次氏、青野慶久氏 (1/4ページ) - MSN産経ニュース (ただし、強調は引用者) この発想はなか
行ってきた。天気がよかった。 色々 HTML5、色々出来すぎて、正直怖い。多くのサイトが対応したら旧世代PCで動くにはキツいんじゃなかろうかとか、ブラウザ間の互換性がもうどうしようもない領域に達するんじゃないかとか。 Scala、色々出来すぎて、正直凄い。静的型付けなのに、プログラムの構成がかなり柔軟そうな雰囲気。IDEの対応ってどこまで進んでるんだろか。 Ruby1.9、1.8と比較するやつの詳細ってどんなだったっけか。 ワークショップは良い。参加に主体性が出る。目が覚める。ファシリテーション手法の紹介と同時に自己紹介し合う機会が得られるという一石二鳥なものを選んだんだろうと思われる、とても良い選択。 http://twitter.com/katzchang/status/3550195709あたりの前提は共有できそう。XP祭り2009もこれ中心だった。しつこいくらいにw 提供されてた無
発散しそうなので、演目を変えそうな予感がします。 自動車とトラックと乗用車をオブジェクト指向でモデリングするより、オブジェクト指向モデル/プログラムを実物でモデリングしてみる演目にしよう…かな。それにしても5分じゃキツい。 オブジェクト指向とは オブジェクト指向(オブジェクトしこう)とは、オブジェクト同士の相互作用としてシステムの振る舞いをとらえる考え方である。英語の object-oriented (直訳は、「対象物志向の」・「目的重視の」という意味の形容詞) の日本語訳である。 オブジェクト指向 - Wikipedia だいたい合ってる。 オブジェクトの相互作用で云々を逆に言うと、オブジェクトと呼ぶ単位で処理を分割していくこと。つまり、他のオブジェクトへ委譲して、目的を達成すること。 クラスとは クラス(class)は、クラスベースのオブジェクト指向においてオブジェクトの設計図にあたる
妻の姓を名乗っている男性は、知り合いに一人もいませんでした。 http://d.hatena.ne.jp/yuripop/20091001/p1 はいはいはーい!妻の姓を名乗る夫さんとして、体験談的なものを。 経緯 結婚前の話し合いにて決めた。 俺自身、自分の姓に大してそれほど執着心はない方だったと思う。ヨメさまと比較して、ね。よく「下の名前、のりゆきだったっけ?」とか間違えられてたのがムカついたせいかもしれない。東山紀之ね。正直、字数が多くて面倒だとは思ってた。 ヨメさまは、今の名前に愛着を持っていた…かどうかはわかんないけど、姓名判断サイトとかは多いに参考にしてたような気がするwwww あと、結婚前にはもう妊娠してたので、子供の名前候補と互いの苗字を合わせてみたり。これも、姓名判断サイト大活躍でした。そんなもんよ、名前なんて。山田式だったかな。 結果、ヨメさまの姓の方が点数が高かったの
やっぱり事例だよねということで、自分とこの事例をまとめてみる。 お仕事の概要 規模 => 当初の見積もりは900時間。ただし、途中で2割くらい減った。 期間 => 2ヶ月 メンバー => 3~4名。自分込み。 2〜3名が設計書作成、自分はレビュアーとして参加しつつ雑務。 概要設計に先立ち、要件定義は完了。30項目ほど。 滝。 Redmineの設定など 「概要設計」をバージョンとして作成。 30項目の要件をチケットとして登録。 ターゲットバージョン => 「概要設計」 開始日 => 登録したその日 期限日 => 概要設計完了予定日の2w前 予定工数 => それぞれの見積もり値を設定 担当者 => 設定しない ユーザの権限は全て「管理者」。 5名程度なら問題ないんじゃないの? チケットのフロー 新規 -> 担当 -> 作成済 -> レビュー済 -> 完了 運用方法 タスクの割り振り それぞれが
次のページ
このページを最初にブックマークしてみませんか?
『@katzchang.contexts』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く