世の中には手続き型言語、オブジェクト指向言語、関数型言語あたりがあるとして、どれがTDDに向いてるかというと、いや特に差異はないよねという話です。 それぞれのやり方で、「手続き」なり「オブジェクト」なり「関数」なりがパターン爆発しない大きさに収まる限り、ユニットテストのコードを書くことは現実的に可能だし、RED->GREEN（もしくはその逆も）の変化を観察することに対して、大きな違いがあると思ったことはない。穿った見方をすると、書籍としてオブジェクト指向の本が多いのは、オブジェクト指向言語のパラダイムが難しいことを説明してると考えることもできる。リスコフの置換原則は我々には早すぎた道具だったのだ！！ まぁとりあえず、テスト性をよくすることで自然と高凝集かつ低結合なモジュール構成が出来上がったりします。ので、私が作る程度のプログラムでは、テスト可能な感じにまとめつつ、意図通りに変化しているこ

先日、白山に登ってきました。 登山を思い付くたびに一夜漬けスクワットを駆使する俺ですが、そんな不精でも、下山時に膝を痛めずに降りられたりするので、そのコツを紹介します。 軸足を外に開く 軸足を外に開く。もったいぶって、それだけです。 例えば、右足を軸足として、左足を前方下に踏み出す足とします。で、右足を斜面下方向に対して右に開いて、左足を一歩踏み出します。左足が安定したら、右足をあまり前に出さずに右に開いた形で一歩出し、再び軸足とします。右足と左足が90度に開いてがに股のような状態で、半歩ずつ歩くような感じです。 右足だけ開くとちょっと苦しいので、体の向きを若干右向きにしたり、斜面下方向に対して右斜めに進んだりしても楽です。 で、足を置く位置や道幅によって、左右の軸を切り替えながら歩いていきます。 平地だと、右足も左足もほぼ進行方向に向けて歩くのが普通ですが、斜面を下る場合、上で支える軸足

この記事は子育てエンジニア advent calendar 2012 : ATNDの12/3のエントリです。 日曜日 俺「ねぇ、なんか足し算の問題だしてよ」 娘「じゃぁ、せん足すー、せん足すー、せん足すー、せん足すー、せんはー？」 俺「ちょいまち」 gosh> (+ 1000 1000 1000 1000 1000) 5000 俺「ほら、5000だ、すごいだろ」 娘「ふーん、じゃぁ」 俺「（反応うすいな…）」 娘「せん足すー、ごましお足すー、ごみぶくろはー？」 俺「！？」 gosh> (* 1000 gomashio gomibukuro) *** ERROR: unbound variable: gomashio 俺「ぐぬぬ………ﾋﾟｺｰﾝ！」 gosh> (define gomashio (+ 5 4)) gomashio gosh> (define gomibukuro (+ 5 3

いよいよ本格的な冬になってきたような気がしないでもないと思ってたらもう師走な今日このごろですが、いかがお過ごしでしょうか？自称お料理ブロガーの[twitter:@katzchang]です。 VOYAGE GROUP エンジニアブログ : Advent Calendar 2012の12/2のエントリーを書かなければいけないですが、何を書こうか迷ったので、ここは湯豆腐について調査した結果を報告致します。 作り方 醤油に酒・昆布を入れて弱く加熱し、温まった程度で昆布を取り出してさらにそのまま加熱する。沸騰したくらいで加熱を止め、鰹節を投入してひと混ぜしたあとに少し放置し、漉し、冷ます。ようするにダシ醤油を作っておく。 柚子の果汁を絞っておく。 鍋に水と昆布を入れ、適当な大きさに切った豆腐を入れ、弱火にかける。丁寧に作る場合は水と昆布を合わせて一晩おいて〜みたいにするかもしれないが、ここはまぁいい

たぶんあとで書かない 細かいコーディング規約を排除できる あなたはコーディング規約の詳細まで理解しているか？ よし、しているとしよう。すばらしい。 では、あなたのチームメンバも同じか？ 無意味に思う規則に乗るなら、乗らないで失敗したほうがマシだ。 書き手のスタイルに沿った設計・プログラミングができる まだ見ぬ読み手に自分を縛られてるくらいなら、自由に書いたほうが、よほど読みやすい。 本当に読みにくい部分を読みにくいと指摘できる 読みにくいコードは、変数の名付けがダメなのだ。状態管理が混乱しているのだ。 読みにくいのはコメントがないせいでもないし、インデントが崩れているせいでもない。読むに耐えないほどインデントが崩れたコードは実際に見たことはないし、気になるなら読み手が修正してコミットすればよい。 他人に読みやすいコードを書ける 読解力とはレビュー能力である

よくわからないけど、先日作った餃子の写真でも載せておきますね。 白菜（またはキャベツ）1/4をみじん切りにして、塩少々をもみ込んでおく。豚挽き肉80gに塩これまた少々を加えて白くなるまで練り、水分を絞った白菜、ショウガすりおろしを親指程度、ごま油大さじ1、片栗粉大さじ2を混ぜ込み、皮に包む。これが餃子のミニマルセットです。これで餃子30個分…のつもりだったけど1/3位余るので、正しくは餃子45個分です。ってか写真で餡が余ってるのが見える。 で、温めたフライパンに油を引き、餃子を並べ、半分弱浸かる程度に水を入れ、ふたをして中火〜強火で焼く。水分がなくなり、皮のまわりが茶色くなったら出来上がり。焼くときに油を少なくすると「ガリッ」とした食感、多めだと「カリッ」とした食感になるはず。濁点が入るか入らないかの違い。写真では油は少なめ、もう少し多くてもよかったかも。 写真のフライパンは南部鉄器の鋳物

最初の文章のまま載せていますので、コメント欄のshiroさんの添削と合わせてどうぞ： 一概には言えないが、2点だけ。 僕は、SICPはプログラミング言語の本じゃなくて、あれはプログラミングの本なんだと思ってる。本の中でSchemeを使っているのは、アトミックなプログラミング言語だからなんだ。ラムダ計算、末尾再帰、継続を使った抽象制御、抽象構文（マクロ）、可変状態など。軽量で、かつ十分だ。 SICPでは、プログラミングをする上での課題を扱っている。モジュラリティ、抽象、状態、データ構造、並列処理など。generic dispatchやオブジェクト、並列処理、遅延リスト、（可変な）データ構造、「タギング」なんかの、明確な課題設定に対する実装例と解説が書いてある。 Clojureはアトミックなプログラミング言語じゃない。僕はもう、アトミックにプログラミングするのは古くて遅くて飽きた。Clojur

この記事は、Play! framework Advent Calendar 2011 jp #play_ja : ATNDの11日目の記事です。 さて、軽めに行きましょう！（ということにさせてください… 僕とPlay! とあるWEBサービスの受託開発案件があり、自分を含めてメンバー的にJavaプログラマが多かったので、Javaが必然。で、環境面も含めてモロモロがフルスタックでサポートされてるフレームワークはないかなーということで、Play! Frameworkを使うことになりました。 2ヶ月ばかり携わったあとで私はその仕事を離れることになったのですが、無事サービスは開始されたようです。めでたしめでたし。 初めのPlayの印象は「黒魔術」の印象でしたが、それはControllerとviewの結合部分が黒いくらいだけで、それ以外の部分は案外素直な作りではあるので、学習にかかるコストは恐ろしく低

じゃがいも、にんじん、玉ねぎ、パセリ、豚スペアリブ。調味は粒胡椒と塩。これだけ。 あとは、保温性の高い鍋。今回はホーロー鍋を用意したが、小さかったので、後で鉄鍋に入れ替えている。最も向いているのは土鍋だけど、うちにあるのはなぜかバカでかいので、今回は登場しない。 じゃがいもは皮をむく。で、鍋に入れておく。 にんじんは皮をむいて、適当に切っておく。玉ねぎもまた皮をむいて、これも適当に切っておく。で、これも鍋に入れておく。 パセリは葉の部分をちぎっては投げ、ちぎっては投げ、鍋に入れる。茎の部分も入れるが、茎は食べないことにする。 豚スペアリブは塩をまぶして、これも鍋に入れる。塩は多めでよい。 粒胡椒をそのまま入れて、塩を足す。鍋に入れる順番はこの限りではないので、準備ができたものから投入すればよい。 かぶるくらいに水を入れて、火にかける。沸騰したらそのままグツグツしておくとアクが集まるので、2

今日から、株式会社ECナビで働くことになりました。 思ってた以上にすごい人達に囲まれてたりして、「もっとも下手なプレイヤーであれ」という言葉を思い出します。 ありがとう北陸、こんにちは東京。今後ともよろしくお願いいたします。 ネット難民のため、取り急ぎ…。

さて、振り返るか。 良かったこと 客先対応からプログラミングまで、チームリードからオフショア開発依頼まで、ひと通りの経験ができた 部署として組織の規模はそれほど大きくなく、経営層まで気軽に話せた 仕事によっては、フレームワーク選定レベルから判断できた 何が必要か等、相談できる上司はいた 就業時間の管理がキッチリされていて、残業は多くなく、サービス残業はなかった 有給休暇が取りやすかった、というか普通に取ってた サーバなど（大枠で一旦稟議を通してしまえば）あとは自由に使っていた 良くなかったこと 開発標準などの社内ルールの是非についての議論する場がなかった WEBアクセスフィルタが導入され、ネットワークが遅く、情報収集が制限されていた （特に中途採用された）上司とのギャップが大きかった 受託開発業は、開発予算は案件単位で、ライブラリやパッケージなどを開発しにくかった 上記状況なのでどうしても

自分の中期的なテーマは「家でおしごと」、いわゆる在宅勤務な気がしたので、これから可能性を探るべく、まずは妄想してみます。 タイトルはデブサミ東北の発表「家でおしごと / いつまでも構想中 / Developer Summit 2011 Tohoku」から頂きました。いい写真だなぁ…。 メリット 通勤時間が不要 今の会社では片道20km30分、往復40km1時間程度の自家用車通勤だが、それが基本的にいらなくなる。1時間の節約、もしくは拘束時間が9時間が8時間に減ると考えてもいい。、燃料費8,000円の節約になる。もしかして、車1台なくてもいいかもしれない（北陸ではそりゃなさそうだけど）。あと、事故の危険性が減るのは嬉しい。 東京なんかだと、通勤1.5時間とかよく聞くので、毎日3時間の節約と考えるとそりゃすごいよね。人生得するよね。毎朝の通勤疲労や交通の乱れによるストレスなんかもよく流れてくる

まぁ、こんなところに書き散らしたところで愚痴でしかないんでしょうけど、どういう歴史的事情でこうなってるのかは気になるかも。もしかして対応方法があれば教えてください。つまり、Excelの話です。 印刷時にフォント幅が崩れるのは致命的 複数ブックを開くときに親ウィンドウ内に展開するのは勘弁してほしい 異なるパスの同名ファイルが開けるようにしてほしい 結合セルを含むコピペで結合が解けてしまうことがある "/"を入力しようとするとAlt押したような状態になる？ たぶん他にもある。

諸先輩方が「この仕事は〜」「社会人として〜」なんて色々言うのは、自分に言い聞かせてるだけだから、あまり気にせず、自分のペースで仕事していきましょうね。

共通関数継承とは、あるクラスで共通的に使うだろう関数やメンバを、親クラスのメソッドやメンバとして定義するパターンだ。Constant interfaceパターンやimport staticあたりが関係するアンチパターンとされるモノの一つで、神様ルートクラスを嫌い、POJOを好むのあたりの、ごく初歩な議論になるだろうと思う。 package spike; public abstract class SuperUtil { /** * 時刻形式の文字列から、日付部分を抜き出す */ protected String timestamp2Date(String timestamp) { if (validTimestamp(timestamp)) return timestamp.substring(0, 10); return ""; } /** * 時刻形式の文字列から、時間部分を抜き出す

はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下： 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ

メモメモ。他にあれば、ぜひおしえてください。 ソースコード中の改変コメント（"// add 2011.02.03 katzchang start"等）は不要です。 元のソースコードのコメントアウトは不要です。必要ないコードはそのまま削除してください。 ifなどのブロック（"{ ... }"）の追加や削除の場合、ブロック中のソースコードに改変がないとしても、インデントを適切に増減させてください。 Javadoc コメントを記述する場合、定義と矛盾がないようにしてください。メソッドコメントの @param が特に矛盾しやすいようです。setter/getterのように自明であれば、省略しても結構です。 Javadoc以外で、ブロックコメント("/* ... */")は使わないでください。 SCMで適切に管理されていることが前提です。 追記 あぁ、大事なことを忘れていた。 VSSで管理しないでく

3歳児に歯を磨かせるのは大変だ。 「歯を磨かないと、口腔内に残った糖分が酸に変化してエナメル質を溶かすんだよ」とか、「歯はまだいい、歯肉炎にかかりだしたらヤバいぞ」などの脅しは通じないのが、奴らの欠点だ。 そこで、いくつか試している施策を紹介する。 歯みがきの音楽 長い間、虫歯鉄道を愛用している。iTunesで6分の動画が売ってるので、買って、iPhoneで聞かせている。 「おかあさんといっしょ」の「虫歯建設株式会社」は悪くないが、テンポが早く、奴らの集中力を削ぐ。「はみがきじょうずかな」は時間が短すぎるし、何よりも「おかあさんコール」で父親の出番がなくなる。 歯みがきスタンプ 用意するものは台帳として適当な厚紙と好みのシール。台帳はamazonダンボールの底板を豪快に使うのもいい。 で、「12個たまったらおもちゃ1つ」などの条件について合意できたら、台帳に題名と数字を書き、歯みがき1回に

Aクラスは全てのAクラスのインスタンスの集合である かつ、 Set<A>のインスタンスは特定のAクラスのインスタンスの集合である ⇒ Set<A>のインスタンスはAクラスの部分集合である …となるが大丈夫か？というのが自分の疑問です。 継承は害悪か。 - Togetterや、TDDBC名古屋で夜にid:rf0444ともお話していた話題ですわね。昨日から今日にかけて、Twitterでいろいろやってたお話です。 「型は集合である」という定義もあるそう*1なので、関連するとは思うけど、型の世界は勉強不足なのでよくわかっていません。が、上記の「Aクラス」を「型A」と読み替えても割といいのかなというイメージではいます。 クラスとそのサブクラスとの関係のみを考えた場合は、「クラスはオブジェクトの集合である」というのは割と自然だったりする…んですかねぇ。 どうでしょうか。 ブコメより id:hoxo_m

えーと、どんな因果か、レビューされる側よりもする側になることが多くなってしまった。 対象となる生産物の欠点を指摘することは、レビューの大事な役割の一つであるとされている。だが、レビュアーとして一番怖いのは、間違った指摘や無意味な指摘をしてしまうことだったりする。そう、レビュアーもまた間違いを犯すんだよ。恐ろしいことに。 そこで有効なのが、"Don't Tell, Ask."「求めよ、命じるな」の原則。 レビュー対象物の「至らなさそうな点」に対して、なぜそこはそうなっているのかについて答えるよう求める。自分がより良いアイデアを持っていれば、それを伝え、どちらが優れているか判断を求める。「ここは、こうしてよ」のような命令（出す側は「アドバイス」と呼ぶ）は出さない。だって、レビュアーの意見の方が優れている保証なんて、何もないんだからね。 そもそもレビューをするのは、そのアドバイスに黙って従う初級

この記事はScala Advent Calendar jp 2010の13日目です。12/19予定だったけど、日付超えてしもたわ…。 この記事の全てのコードは https://github.com/katzchang/TDD-with-Lift にあります。 はじめに LiftはScalaで最も有名なフレームワークだろう。Scalaの能力が駆使され、ともすると取っ付きにくいとの噂もあるが、この際それはどうでもいい。フレームワークが用意するライブラリの随所に改造ポイントが見られ、もちろん、modelに対するバリデーションも独自に実装できる。…が、意外にもビルトインのバリデータは少ない。文字列の長さを検査する「ValidateLength」トレイトくらいしかないはず。 というわけで、今回はliftのmodelに対する「not null」バリデータを実装することにした。 使い心地として、Vali

この記事は Java Advent Calendar -ja 2010 の4日目のものです。 はじめに 継続的な開発では、データベーススキーマも段階的変化に耐えることが求められる。マイグレーション・システムが必要だ。 そこで、MyBatis Schema Migrationというのがあるらしいので試してみた。ほら、Java屋にはおなじみのMyBatisだ。 インストールする http://code.google.com/p/mybatis/downloads/list?can=3&q=migrations から、「MyBatis Schema Migrations 3.0.2 GA」をダウンロードし、適当な場所に展開し、PATHを通す。 migrate init - 初期設定 プロジェクトのホームがあれば、その下に空のディレクトリを作り、そこでスキーマの管理をするとしよう。空のディレクトリ

System.out.println(new java.util.Date(10000).before(new java.sql.Timestamp(20000))); System.out.println(new java.util.Date(10000).before(new java.sql.Timestamp(10999))); 上記1行目では"true"を返す。基準時から10000ミリ秒経過後の時間は基準時から20000ミリ秒経過後の時間よりも前なので、この挙動は正しい。 でも、2行目では"false"を返す、微妙な挙動がある。ってかバグだわ、こりゃ。そういうのを含めて、仕様だそうです。 なんで？ java.util.Date(long time)では、timeをミリ秒単位として解釈し、その全ての値をthis.fastTime に格納する。一方でjava.sql.Timestam

結論としては、本家サイトの情報が最も確実で、ゴールが近い。ので、大した情報ではないが、載せておく。自分用リンク集。 http://liftweb.net/ 本家。今日現在、最新は2.1-RC3。 http://liftweb.net/getting_started 取りあえずここから始めよ http://www.assembla.com/wiki/show/liftweb/ 本家wiki。より詳しい情報がある。役に立つのは： http://www.assembla.com/wiki/show/liftweb/Using_Maven http://www.assembla.com/wiki/show/liftweb/Basics のそれぞれ http://exploring.liftweb.net/ Liftのオフィシャル解説本を無料配布。htmlとpdf。2.0ベース。全体的に網羅している

"=>"ってなんやの パターンマッチングとか、関数リテラルのパラメータを渡す的な場面でつかう。 "->"ってなんやの つまるところ、2要素のタプルを作っているようだ。 ↓みたいなコードってなんやの db.use(param) { con => hogehoge(con) } openOr false つまるところ、コネクションを確保して、{}で記述した関数リテラルで定義した関数にそいつを渡して処理させて、コネクション開放までやっちゃうよということらしい。で、そいつのooenOrメソッドを引数falseを渡して呼んでいる。db.use(param)は関数を受け取る関数を返す定義になっている。こんな感じ： def use(param : String)(f : (Connection) => T) カリー化とスペースによる単一引数渡しな記法を組み合わせて、結果的に構文ブロック的な見た目にしつつ

James Strachan's Blog: Using SBT on your Scala Maven project for continous testingの意訳です。 本文 継続的テストは大事だ。ソースコードが変更されたらすぐにテスト。テストファーストはいいことだし、コードの変更への素早いフィードバックが得られる。 で、MavenでScalaプロジェクトのビルド＆実行を繰り返してるわけだ（しかも、IDEだとちょっと遅い）。 Infinitestプラグインを買ってもいいとは思うけど、ScalaTestsをコンソールビューで動かすのはキツい。failなコードを参照しにくい。しかも、ビルドコマンドを叩かなきゃいけない。テストは、自動で実行しつづけたいんだよ。 で、sbtだ。Simple Build Tool for Scala。 インストール ダウンロードしてスクリプト作ってパス通す（

開発チームの立ち上げの際、互いに自己紹介しあうのは大事です。社内だとしても、同じチームで仕事しない限りはあまり交流がなかったりするのは弊社だけじゃないはず。 で、その場で名前とか開発経験とかを言い合うわけだけど、合わせて「今までの仕事で、一番ヤバかったこと」を言う。これが「病気自慢」というプラクティスなのです！（ﾊﾞｰﾝ 仕事ではまった経験はトラウマになり、その人の判断基準に強く影響する。しかも、厄介なことに、無意識に行われることも多い。トラウマを避けるということは、ディフェンシブな開発スタイルに慣れきったオレらにとって重要な位置をしめているはず。互いを理解し判断を尊重することが出来れば、悪習慣を避けるように方向を付けられる。こんな効果が期待されます。 というかまぁ、単に盛り上がるのでオススメです。 夢を語るのは営業でもできる！クソ現場を語るのは開発チームの特権だろ！ これ、30分前に命名

前にネタにしたんだけど、結構検索で引っかかる方が多いので補足します。 timestamp with timezoneはjava.sql.Timeクラス timestamp without timezoneはjava.sql.Timestampクラス という、結構単純な話でした。ResultSet.getMetaData().getColumnClassName(int)でクラス名が取得できるので、気になる方は調べてみては如何でしょうか。 ちなみに古典的にJDBCを使ってる場合、ResultSetはやたらとgetHoge(column)メソッドが乱立してて面倒だけど、JDK5.0だとジェネリクスとやらを使って、 public <T> T get(ResultSet resultSet, String columnName) throws SQLException{ return (T)res