コンピュータやソフトウェアのあれこれ＠道民（＆元道民）
Archive for 1月, 2011
Facebook。はじめるか判断する基準と細かすぎるポイント
1月 24th
Facebook創業者をモデルにした映画「ソーシャル・ネットワーク」を観てきました。
私も一ヶ月くらい前からFacebookをはじめているので、映画の感想はあっちのノートにアップしました。
Facebookのアカウントがあれば見られますので興味があればどうぞ。
友達登録は、会ったことがある人・札幌のFacebookユーザーに限定していますが、該当する方はお気軽に申請ください。
mixiが全く続かなかった私が、どういうわけかFacebookは割と気に入っています。
単に青系が好きで、スイーツ感がないからかもしれないですが。
今回の話は、一ヶ月くらい利用して考えた
Facebookをはじめるかを「判断する基準」と「細かすぎるポイント」についてです。
判断する基準
実名公開を避ける、日本人の場合ですが…
「便利さや利益のために少々面倒なことを厭わないか」
ではないかと思います。
私は興味を持つと面倒なことを平気でします。
電化製品を買うと、説明書に目を通します。
ゲームやWebサービスをはじめると、環境設定を開きます。
なので、Facebookでもプロフィールはほぼ全て埋まっていますし、通知やプライバシー設定もカスタマイズしています。
Facebookは能動的に機能を使うほど、楽しさが増していくように思います。
この段階で「めんどくせえええええええ」と思った方。ちょっと厳しいかもです。
どんどん細かくなりますよ！興味のある方のみ以降をどうぞ。
Twitterとの違い：交流のコントロール
Twitterをそのまま流している人がいますが、即やめた方がいいです。
全く意味がないし、設定でブロックされます。
Facebookは鍵付きのTwitterに近いです。
私の場合、こんな話題はあちらでしています。
- 趣味や娯楽の長話
- リアルなお仕事の話（守秘義務に反しない範囲で）
- 検索で拾われない方が良さそうな話
…あれ？エロい話は(ry
FacebookもTwitter同様、友達の数が一ケタだとちっとも面白くありません。
かと言って、友達をむやみに増やすと、ウォールには文字制限がなく、ファンページやコメントがバンバン流れてくるので、Twitterよりグダグダになってしまいます。
「全く知らない人を友達にしない」というのは、Facebookでも注記されています。
相手に交際関係・オンライン状態がわかることを含めても、友達承認をする範囲ははじめに決めておいた方がいいです。友達100人できるかな、くらいでちょうどいいのかも。
mixiとの違い：発言のコントロール
Facebookは、つぶやくたびに「公開範囲」を変更できます。
mixiでも「マイミクのマイミク／マイミク／マイミクの特別な人」という区分ができますが、Facebookは友達をTwitterのようにリスト分けして、そのリストの人だけにつぶやきを発することができます。
（foursquare・ロケタッチなどの外部サービスではできません）
普通の人はここまでやらなくていいです。私は公的な関係と私的な関係がいっしょくたになっているので、ときどきこれで調整しています。
その他のWebサービスとの違い：連携のコントロール
他Webサービスとの連携も少しずつ分けています。
- はてブ：参照している人が多いようなのでtwitterのまま
- Foursquare：twitterに流しても文字しか出ないのでFacebook
- 動画サイト：クリックですぐ観てもらえるのでFacebook（手動）
- Instagram：ナイスが欲しいので両方
- Flickr：写真にこだわりを持たないのでFacebookに切り替えようかな
Twitterでもあまりつぶやかないし…という人は私的なWebサービス置き場からはじめるといいかもです。
「いいね！」がもらえてちょっと嬉しいです。
ファンページ
先日、北海道開発オフのファンページを作りました。
何かの団体に属している人は、試しにファンページを作ってみてください。
「いいねの数」「いいねした人」「アクティブユーザーの数」などを知ることができます。
基本機能やファン同士の交流ならmixiのコミュの方が良さげですが、アプリケーションと連携させることでかなり細かいことができます。
うーんめんどくさいですね。私がめんどくさい使い方をしているだけですが。
この一ヶ月でだいぶルールが整理できてきました。
海外の人たちは、自分を晒すリスクより利益と承認欲求を重視して、ホイホイこの手のSNSをはじめます。
その代わり、セルフアピール・セルフコントロール能力に長けていますし
「出る杭は打たれる」文化があまりありません。
強固な理性、奥ゆかしさは日本人のいいところではありますが、21世紀ですし、冒険してみてもいい頃じゃないでしょうか。
特に、きちんとプロフィールを記入している人はビジネスでの信頼性が高いです。SOHOや管理職の人は積極的に使ってみるといいと思います。
映画みたいに、会ったばかりの女の子とあんなことやこんなことはできないと思いますがwww
デザインのためのデザイン(フレデリック・P・ブルックス Jr./松田 晃一/小沼千絵)
1月 23rd
デザインのためのデザイン(フレデリック・P・ブルックス Jr./松田 晃一/小沼千絵)
いくつか今現在抱えている問いについてのヒントを貰えた。示唆に富んだ、とても素晴らしい書籍(けれど、結構ハイコンテキストな気もするので、読む人を選ぶ書籍かも)。第4章や第20章を受けて、僕らはどうアクションすべきか。
イラストのこと、キャラクターデザインのこと。(坂崎 千春)建築デザインのアイデアとヒント470 (エクスナレッジムック)(毎週住宅を作る会)
1月 23rd
建築デザインのアイデアとヒント470 (エクスナレッジムック)(毎週住宅を作る会)
「毎週住宅を作る会」という建築設計の演習活動を行っている団体による、これまでの活動の中で取り上げてきたテーマ（建築を構成する要素）を「かたち・形状」「素材・モノ」「現象・状態」「部位・場所」「環境・自然」「操作・動作」「概念・思潮・意志」という分類で整理して解説したという一冊。
テーマの選び方に『クオリティ』を感じる。カタログ化することが目的ではなく、こうした題目について「手を動かして考えてくる」「みんなで話しあう」ことが主眼なのがとてもいいね。
TDDBC 2 日目午前の部
1月 23rd
TDDBC 2 日目午前の部
今日は現実と闘うためのTDDをやってます．
TDD の目指すもの
「Emergent Design」(創発的設計)を形作るピラミッドの礎の一つ
理想はね…
現実と戦う
テストが無いコード
「レガシーコード改善ガイド」
レガシーコード改善ガイド (Object Oriented SELECTION)
翔泳社
￥ 4,410
既にデータの入ったデータベースがある
データと戦う
- データベースもリファクタリングする
- 慎重さ，周到さが必要
- ソースコードはバージョン管理してるから，ロールバックが楽だよね
- データはロールバックするのが難しい
- 長いリファクタリング期間
「データベースリファクタリング」
データベース・リファクタリング
ピアソンエデュケーション
￥ 3,780
テストコードが増えてきた
「xUnit Test Patterns」
xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))
Addison-Wesley Professional
￥ 4,870
Fragile Tests
壊れやすいテスト
振舞いを変えずに内部実装を変えた時，どれだけのテストが生き残れるか．理想は全部．
例えば mock
- mock はプログラマの想像上のオブジェクト
- mock が常に現実のオブジェクトと同じ振舞いをするようにアップデートするのはプログラマの責任
- し続けられるか…！？
Slow Tests
遅いテスト
DBの接続が遅すぎる！ -> mock を使えばいいんじゃね？ -> Fragile Tests になる…
Fragile Tests <-> Slow Tests どっちを取るかは開発者次第．@t_wadaはSlow Testsの方を取ることが多い．
最近は，テストにタグ付けしてグループ化することで，着目している部分毎にテストする手法が試されている．
対レガシーコード心得
テストできる継ぎ目を探す
オブジェクトをテストに擦り替えられる場所
なにが正しいか vs どう動いているか
今何をしているか，帽子を意識する
- コードを直そうとしている
- コードを解析しようとしている
どう動いているか -> 仕様化テスト( Characterization Test )
コンパイラを味方につける
コンパイラまかせ
テストするために手段を選ばない
テスト容易性 >>>>>>>>>>>>>>>>>>>>>> (超えられない壁) >>>> カプセル化
対レガシーコードデモ
Characterization Test は通常のテストとは異なるので，通常のテストとはファイル/クラスを分けて書く
- インスタンス化できること
- 仕様化対象メソッドを呼んでみる
- 出たものをassertしていく
- どこまでやるか
- カバレッジを取ってみて通ってない領域を眺める
仕様をあぶりだす
時間がかかりすぎるので全部は仕様化しない/できない．自分がこれから修正する部分とその周辺に対して仕様化する．
TDDBC 1 日目午後の部
1月 23rd
TDDBC 1 日目午後の部
acts_as_professional
- プロならば，自分の書いたコードに責任を持つ．
- 自分の書いたコードに責任を持つには，テストを書く．
- つまりプロならば，テストを書く．
ペアプロで fizzbuzz を書く
- テストコードの名前を 〜Test と書くか Test〜 と書くか？
- コードとテストが 1 対 1 なら 〜Test と書くのがいい
- コードとテストが 1 対多 なら Test〜 と書くのがいい
テストメソッド名は詳しく書く．メソッド名は日本語で書いていいよ．
テストは下から書く．=ゴール(やりたい事)から書く
仮実装
- テストのテスト
- 実装をコピペしたテストを実行してみる．green になることを期待．
- このテスト環境は安心して使えるのか？
テストのステップはひたすら小さく．思った以上に小さく．
TDD導入効果
IBM とか MS での測定結果
- TDD を採用した場合，TDD を採用していない場合に比べてのバグ数は 10〜60% に減少する
- TDD を採用した場合，TDD を採用していない場合に比べてのコード実装時間は 15〜35% 増加する
ざっくり言うと「コード実装時間は2割増加するけど，バグ数は半減するよ」
エリクソン他
被験者を対象としたアンケート
- 96% の被験者が「デバッグの工数を減らす」と感じた
- 88% の被験者が「要求が洗練される」と感じた
- 92% の被験者が「コードの品質を上げる」と感じた
- 50% の被験者が「開発工数を減らす」と感じた
TDDはスキル
つまり
- 才能ではなく習得可能
- 量は質に転化する
- 写経すべし
ペアプロお題
LRU Cache
[きのこ97][ソフトウェア開発][Planet] 34-API設計の黄金律
1月 23rd
「プログラマが知るべき97のこと」の34個目のエピソードは、APIの設計におけるユニットテストに関する話です。API（Application Programming Interface）は文字通りにプログラム（コード）間の境界を定めます。あるフィーチャを実現するプログラムを書くことは難しいケースも簡単なケースもあります。しかし、そのフィーチャを外部に適切に公開すること、すなわちAPIを設計する事は常に難しいものです。 例えば、「カンマ区切りの文字列を分割し、整数として合計を求める」という機能を持つプロ ...
リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法(Andy Hunt/武舎 広幸/武舎 るみ)