ノートPCの液晶破損

娘のノートPCの液晶ディスプレイが破損した。

イヤフォンを挟んだまま、勢い良くたたんでしまったらしい。
このように壊れた液晶を生で見たのは初めて。物理の実験ぽくってかっこいい。
※）挟んだ場所が、弾痕のように残っている（左下）。

仕方ないので、ディスプレイと外付けキーボードを接続してデスクトップのように使うことにしよう。
ディスプレイはたたんで運用する。ただし、電源を入れる時には、ディスプレイを開ける必要がある。めんどくさいが仕方ない。

ノートPCは、デルのモデル1558。発熱に問題があるのでディスプレイを閉めて運用して大丈夫だろうか？
まずは、この問題を解決する必要がある。

iPhoneで画面キャプチャ

備忘録
iPhoneで画面キャプチャするには、ホームキー＋スリープボタン。
スリープボタンを押して、ホームキーを押すと画面キャプチャがとれる可能性が高い。
端末シャットダウン画面になることもあった。

iPhone スナップショット

Chrome on iOSの更新

Google chrome on iOSに更新通知が来ていた。

タップすると、Apple Storeにジャンプする。

Google chromeは差分更新を使って頻繁にアップデートを行っていたが、iOS上では勝手に更新できないということなんだな。

GIMP on 山ライオン

Windowsでは、画像処理にPaint.NETを使っています。と、いっても画像の切り抜きが主だけど。

代替えアプリとしてGimpをインストールしました。
GIMP on OS X

mountain lionから、X11がインストールされていないので、別途インストールする必要があります。
XQuartz

X-Windowは、すぐになくなることはないと思うけど、この先どうなるんだろう。

まずは、Gimpが無事にインストールできて、めでたし、めでたし。

【書評】霞が関「解体」戦争

霞が関「解体」戦争

猪瀬直樹

草思社

発売日：2008-11-25

ブクログでレビューを見る»

2008年に出版された書籍です。

2002年に道路民営化からずっと官僚と戦っている姿は敬服に値します。
情報公開（エビデンス）、定量データに基づく議論。
口先だけの評論家が多い中、行動力をも伴った希有な人材です。
東京都副知事としての今後の活躍を期待します。

民主党政権で一番期待されていたことだったのですが。。。

------------------------------------------
以下、本文中の気になったところのメモ。

国の公務員三十三万人のうち、二十一万人が地方支分部局に属している。二重行政、三重行政になっている。

地方と国の役割分担について非常に不明瞭な部分が多いところをできるだけ分かりやすくする。会議の公開を含め、住民の利益の側にたってよくわかるようにしたい。

この国を元気にするための地方分権とは、つまり、「霞ヶ関解体計画」である。

国土交通省では二万人強が地方整備局に属する。
地方整備局には国道事務所や河川事務所がある。
道路は国道事務所、河川は河川事務所、河川国道事務所もある。
河川関係が7000人、国道関係者が6000人くらいいる。

これから先、振り出しに戻ってしまわぬようにとの歯止め、つっかえ棒のつもりで検討の経過を残しておきたかった。前線の塹壕からの頼り、ぜひ読んで欲しい。

受託プロジェクトメモ。

　受託プロジェクトを初めて体験しました。経験不足でプロジェクト関係者にご迷惑をかけてしまいました。次回、同じ轍を踏まないよう整理しておきます。


□工程
　詳細設計から単体テスト実行までを行った。

　詳細設計
 　設計レビュー
　製造
　　コードレビュー
　単体テスト仕様書作成
　　単体テスト仕様書レビュー
　単体テスト実行
　結合テスト
　品質評価

□受託プロジェクトの感想。
　余裕のないスケジュールであり、これに起因する問題が多く生じた。
　スケジュール優先（特に初期の行程）のため、単体テストが結果的に手薄になった。
　　単体テスト実行する時間より単体テスト仕様書を作成する時間の方が圧倒的に長くかかった。
　　時間的な余裕がないため各工程で時間が不足していた。
　タスク内容と担当者のスキルの理解が不十分だったため、見積もりが不適切だった。
　　このため、各工程の品質が低下した。
　　担当者(私)のスキル(経験不足)が低かった(これ重要！)。
　少ないリソースで開発したため、各工程を同一人物で行うケースが多かった。
　　たとえば、単体テストを製造担当者が行った。
　単体テストの書き方チュートリアルがなかった。
　　未経験なので困った！
　単体テストにエビデンスが存在しなかった。
　　担当者任せ。単体テストレビューがない。
　詳細設計のレビューが、仕様のレビューになっていなかった。
　　実装時に再確認が必要になった。
　品質評価で不具合の分析を行い、その結果として単体テスト仕様書を修正した。
　　何のために？
　　解決しようとしているのが、今の問題か未来の問題かが不明。
　　品質レポート作成に２日費やすくらいなら製造・テストに２日費やす方が良いですよね。きっと品質も高くなるに違いない。

□問題点
　・属人性
　　単体テストが担当者まかせになっている点。レビューがない。
　・プロジェクト管理
　　タスクとリソースを理解し適切なスケジュールを設定していない。
　　初期段階ではある程度セレクトするが途中でリソースを獲得するのは難しい。
　・無意味なドキュメントをなくす
　　品質管理に必要な項目かどうか考える
　　だだし、これはお客様の都合(要件)に依存する。

□問題分析
　詳細設計者と製造担当者が同一人物のケース
　　メリット
　　　仕様がわかっているので製造時間が短くてすむ
　　デメリット
　　　仕様のチェックは緩い
　詳細設計者と製造担当者が別人のケース
　　メリット
　　　仕様のチェックは緩い
　　デメリット
　　　仕様がわかっているので製造時間が短くてすむ

□単体テストの書き方
　機能単位ごとに記載する
　　起こりえるケースを列挙する(MECE)。
　　分岐(if、switch文)
　　境界値チェック
　　同値地チェック

□参考資料
・単体テストにおけるCMM的アプローチ
　http://www.juse.or.jp/software/pdf/20_spc/8/7_b_report.pdf

　単体テストにおける属人性をテーマとしている。良い分析だが、組織で受け入れられるかどうかが問題。プロジェクトが失敗した場合に、責任を明らかにする必要がある場合どのようにするのか？

・ソフトウエアテストに求められている役割と課題
　第6回システム検証セミナー 2006.9.8
　http://www.veriserve.co.jp/jp/seminer/seminer_list/pdf/06.09.08_katayama.pdf


・短期・高品質に向けた単体テスト作業プロセスの改善
　http://www.jasst.jp/archives/jasst07e/pdf/A3-1.pdf

　確かに、テスト仕様書とJUnitのテストケースが連動するのがベストだが、運用できるのだろうか？

・現場ですぐ使えるソフトウエアテストツール
　http://www.jasst.jp/archives/jasst11t/pdf/s1.pdf

　便利なツールが無料で使えるが、ツールを使うことが目的にならないように注意する必要がある。たとえば、カバレッジを100%にするために、テストケースを増やすのはナンセンス。