えいのうにっき

a-knowの日記です

2011/07/06 日誌

今日からまた社内教育研修で、千葉の方にきています。

**今日のWeb -もう魚は勘弁してください。 : ミニ・クロスオーバー試乗 -もう魚は勘弁してください。 : ミニ・クロスオーバー(懸念事項) --この方のインプレッションは本当に大好き。読んでいるこちらまで、運転してみたくなる。 --“3ドアと一番違う、と感じたのはドアがサッシュレスであるかそうでないか。クロスオーバーはウインドウに「枠」がついています。” ---へぇ、そうなんだ! --“ドライバーにフィードバックされるインフォーメーションも豊富で、そのぶん「飽きない」車だと考えられ、事実ぼくにとって、R56ミニクーパーSは、「もっとも長く」所有した車でもありました” --“現在存在する一般的なトランスミッションについて、ぼくのプライオリティは「ツインクラッチ>シングルクラッチ>MT>CVT>AT」となります。” ---ツインクラッチ、いちど体験してみたいんだよなー。 ---会社の後輩がさいきん、AudiのA1を購入したらしい!これが多分ツインクラッチ(DSG)だったと思うので、今度試乗させてもらおっかな! -ヤフーCUが失敗した理由、LinkedInが成功する根拠--伊藤穣一氏に聞いた - CNET Japan --“2007年に一度デジタルガレージと日本展開に関する基本合意があった。日本版サイトの開発を発表するまでに3年以上時間があいた理由は。” ---“米国ではずいぶん議論して、日本に進出するタイミングを考えていた。日本はビジネスのやりかたも違うし、難しいマーケットじゃないですか。だからやるんだったらちゃんとやらないといけない。LinkedInはけっこう真面目な会社なので、世界にプッシュできると思ったタイミングが今年だった。今年のはじめくらいに日本市場に本気で取り組もうと動き出した。” --Webサービスの命綱が“スピード”なのは不変の真理だろうけど、一方でこういったところも変わらず大事なんだよね。 -おひろめ会:Javaにおけるデータシリアライズ手法 --自分で作ってるソフトは、オブジェクトをシリアライズしてファイル出力・・・なんてことをフツーにやってる。 --だからこそネックになりやすい部分かも、と思って、このスライドには吸い寄せられた ---ちなみに使ってるのはフツーのSerializable。 --JSON:たしかに直感的だけど、表せないデータもありそう。それに、モノによってはJSONで表したほうがサイズがでかくなる、ってことはない?? ---他言語の処理系が多いっていうのは大きなメリットだなぁ --Externalizable:Javaの標準APIでこんなんあったのか。 ---お、Serializableよりサイズが小さいじゃん --Protocol Buffers:コンパクトすぎワロタ ---既存の実装をコレ向けに作り替える必要あり、か・・・。。何か新しくつくるときにはいいかもね! --Hadoop Avro:なるほど、JSONスキーマ定義。冗長だけど処理は早い・・・か --Message Pack:早いJSON、か。 --性能評価、Serializable健闘してるね。 --“JavaのSerializableを使っている人はExternalizableに置き換えた方が良い。(わずかな改修で性能が向上します。)” ---グラリときた。 ---でもSerializableで取ったデータの蓄積があるからなー(変換ツールまで考えないといけなくなるよなー) --圧縮アルゴリズムにまで言及。ウチもシリアライズデータをフツーのzipで圧縮してます。 ---早いのはいいんだけど、圧縮率がアレだとやる意味ないもんなー。ジレンマ。

**WEB+DB PRESS(vol.63)読んでる -Web開発の「べし」「べからず」 --第2章・テスト編(和田卓人) ---はじめに ----“テストコードを書き続けることにより、異なる問題が立ち現れます。問題が次のステージに進むのです。” ----“テストコードを書くことで、比較的すぐに幸せになることはできるのですが、幸せであり続けるためにはまた別の努力が必要です。” ----“時代は「テストコードの書き方がわからない」時代から、「テストコードを腐らせずに、旨味を活かし続けるにはどうしたらよいか」という時代に入った” ----大原則として“汚いテストコードでもないより100倍マシ”。 ---書き方 ----テストコードに期待値を記述することにより、テストコードに「動作するドキュメンテーション」としての価値を加える -----“よく書かれたテストコードは、動く仕様書となって読み手に意図を伝えられるようになります。” ----“失敗時に十分な情報量をテスト実行者に伝えるには、複数ある懸賞メソッドの中から適切なものを選ぶ必要があります。” ----“良いテストにはテスト対象ごとに「準備→実行→検証→後片付け」を書くというパターンがあります。” ----“テストコードは動くドキュメンテーションとして、製品コードと同じ基準でメンテナンスされるべきです。” -----テストコードの重複を排除する(「メソッドの抽出」リファクタリングや@Beforeアノテーションを付加した準備用メソッドの活用) ----テストごとのassertionを1つにする ----テストクラス名、テストメソッド名に常に気を配る ----テストコードとテスト対象の数対応関係を意識する ---動作 ----テスト間でデータを引き継いでいないか? -----共有オブジェクト、共有データを避ける ----“テスト自動化の大事な点は「誰でも同じようにテストを実行できること」です。” ----テストに使うファイルはバージョン管理に入れる ----特定の環境に依存するテストは区別する ----開発者ごとにサンドボックス環境を作る ----外部サービスのスタブを作成する ----テストを“脆く”しない -----“テスト対象がどう振舞うべきかについてテストに「過剰に」記述されている場合に、意図しないテストの失敗を引き起こす場合があります。” -----テストのピントを絞る -----テスト対象の実装の内部をテストしてしまわない -----HowではなくWhatをテストする ------“実装の内部をこじ開けて詳しくテストするのではなく、publicメソッドを通して責務と振る舞いをテストしましょう。” -----モック/スタブを使い過ぎない ------“オブジェクト同士のやりとりをピントを絞らず細部まで細かく偽装してしまうと、不必要に実装の詳細をテストすることになってしまいます。” ------“自分で制御しやすいものにはスタブ/モックを書かない” ---テスト速度 ----同期部分と非同期部分に分ける -----非同期部分をスタブ/モックで置き換える ----テストに使うデータ量を絞る -----“共通のデータセットアップロジックを使い過ぎず、テストに使うテストデータの管理は、可能な限りテスト自身で行うのがよいでしょう。” ---良いテストコードとは ----完全自動化されている ----自己検証する ----再現性がある ----互いに独立している ----探しやすい ----意図を読み手に伝える

長距離移動は、それだけで疲れますねぇ。