nDiki : コンポーネント

D端子+ピンプラグx2 ケーブル

帰りに5m のを買ってくる。

あれ、ウチのテレビ D4対応だったのか。 てっきりD2までだったと思っていた。 コンポーネント3入力端子もあったのか(ま、今回はプレーヤー側がD2なのでD端子接続でいいけど)。

---

[ 家電 ]

地磁気による画像の傾き

最近テレビの画像が傾いていて、とても気になっていた。 地上波もコンポーネント入力も。

ということで説明書をひっぱりだしてくる。 磁界によって発生する傾きの補正をメニューから選んで調整。

買って以来場所もほとんど動かしていないんだけれど、何の影響だろ。

---

[ 家電 ]

コミットメント・リスト vs ガントチャート

会社の人が市販のガントチャートソフトウェアを購入して、現在本格導入を検討しているとのこと。

 社内にはコミットメントをコアにした管理手法もあり、
 その優位性は十分に認めている。

 しかし、単純にガンチャートがすきなのである。
 特に見た目、がね。

 -- GAKUさんの日記 「これは好みなのだ」 2005年10月18日 13:10 より

とのことだ。 コミットメント・リスト派とはまさに私の事である(多分)。 いい機会なので自分の中でも、コミットメント・リストとガントチャートについて整理しておこう。

ここで言うところのコミットメント・リストというのはすごい会議で紹介されているものである。

ちなみに私はプロジェクトマネジメントについては教育を受けたこともないし、明確な手法を導入したプロジェクトマネージャーの下についたこともない。 「ガントチャートは駄目」だとも思っていない。 以下は試行錯誤を繰り返している中での現在の私見である。

どちらも特徴・欠点があり適材適所(と好み)があるのだと思う。 両方同時に使っているケースもあるであろう。 またこれらは一つのツールであるから、本来はもっと上位の管理手法まで議論しなければならないであろう。

モデル

コミットメント・リストでは「期日」という点で「成果」をリスト化する。 一方ガントチャートでは「期間」という点で「作業」をリスト化する(たいがい)。

• 作業時間がある程度精度よく見積もれる
• 作業時間と成果が比例的である

であるような場合はガントチャートで計画しやすい。

逆に言うとそうでない場合は、コミットメントベースの方が合っているように感じる。

ガントチャートを利用したマネジメントの特徴

• マネージャからのトップダウン的なスケジュール向き
• リソースの多重度を把握しやすい (本来はかけもちさせない方がいいと思うが)
• 比較的多人数のチームでもいける
• リソースがタスクに時間を割く割合を設定できる (やろうと思えば)
• 人月計算/コスト積算できる
• プロジェクト外からの割り込みの発生によって狂いやすい
• 成果がみにくい
• チェックしにくい
  • 「進んでますか?」「はい作業中です」「どれぐらい?」「うーん、30%ぐらい」
• ぱっと見、計画できている気がする
• 期間が長いと、チャートが見にくくなる
• 1日単位で見積もりたくなる
• 休日が気になりだす

コミットメント・リストを利用したマネジメントの特徴

• 担当の裁量を尊重・重視
• コミットメントのクロスチェックがしやすい (コミットメント、メジャーメントの明文化)
• 期日前にせっぱつまりやすい
• 依存関係が複雑だと把握しにくい
• 専用のソフトウェアがなくても可能
• 他のプロジェクトと兼任しているリソースの稼働状況がわかりにくい
• 線表派からみると計画だと思ってくれないかも

自分がガントチャートでうまくいかなかった点

ソフトウェア開発で線を引いてみたときの感想

• スケジュールの変更があった時に面倒
• 現状とあわなくなってくるとだんだん見なくなった
• 結局だんだんメンテナンスしなくなってしまう
• 進捗チェック時に、ガントチャートで○○%と入力しても適当で意味がなかった

コミットメント・リストでうまくいっている点

• 成果が達成できているか、そうでないかが明確
• 達成できていないコミットメントのチェック、フォローができている
• 担当自身が忘れていたコミットメントもクロスチェックで再認識できる
• コミットメント一つ達成するたびに「いい気分を味わえる」

まとめ

現在自分がマネジメントしているような、ソフトウェア開発の含まれる少人数体制のチームではコミットメント・リストベースがかなりイケているように思われる。

必要であるならば適応型ソフトウェア開発にあるような、タイムボックス(サイクル)を設定してコンポーネントを割り当てる形で長めの計画をコミットすればよいであろう。

ガントチャートは、それこそ「依存関係のある工程が順番に進んでいく」「クリティカルパス重要」のようなプロジェクトにはいいんだと思う。 自分が扱っているプロジェクトがそういうものではないのだなと。

Visual C# 2008 Express Edition で必須コンポーネントを同梱

Visual C# 2008 Express Edition で Windows インストーラ 3.1 と、.NET Framework 3.5 SP1 を「アプリケーションと同じ場所から必須コンポーネントをダウンロードする」ような ClickOnce アプリケーションを発行するための設定。

以下 C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages を %Packages% と書くこととする。

1. %Packages%\WindowsInstaller3_1 に WindowsInstaller-KB893803-v2-x86.exe を置く。
2. %Packages%\DotNetFx35SP1\product.xml ファイルを開いて PackagesFiles 要素の下に以下を追加。
   • <PackageFile Name="TOOLS\clwireg.exe" />
   • <PackageFile Name="TOOLS\clwireg_x64.exe" />
   • <PackageFile Name="TOOLS\clwireg_ia64.exe" />
3. %Packages%\DotNetFx35SP1\product.xml の中で Name が dotNetFX30\XPSEPSC-x86-en-US.exe のものと、dotNetFX30\XPSEPSC-amd64-en-US.exe のものの PublicKey を ※1 に変更。
4. http://go.microsoft.com/fwlink?... から dotnetfx35.exe をダウンロード。
5. dotnetfx35.exe /x:. を実行して展開する。
6. wcu\dotNetFramework の中身を %Packages%DotNetFX35SP1 にコピー。
7. dotnetfx35langpack_x86ja.exe ( http://go.microsoft.com/fwlink?... ) を %Packages%DotNetFX35SP1\ja\DotNetFX35\x86 におく。
8. dotnetfx35langpack_x86ja.exe ( http://go.microsoft.com/fwlink?... ) を %Packages%DotNetFX35SP1\ja\DotNetFX35\x64 におく。

 ※1: 以下折り返さないで1行で
 3082010A0282010100A2DB0A8DCFC2C1499BCDAA3A34AD23596BDB6CBE2122B794C8EAAEBFC6D5
 26C232118BBCDA5D2CFB36561E152BAE8F0DDD14A36E284C7F163F41AC8D40B146880DD98194AD
 9706D05744765CEAF1FC0EE27F74A333CB74E5EFE361A17E03B745FFD53E12D5B0CA5E0DD07BF2
 B7130DFC606A2885758CB7ADBC85E817B490BEF516B6625DED11DF3AEE215B8BAF8073C345E395
 8977609BE7AD77C1378D33142F13DB62C9AE1AA94F9867ADD420393071E08D6746E2C61CF40D50
 74412FE805246A216B49B092C4B239C742A56D5C184AAB8FD78E833E780A47D8A4B28423C3E2F2
 7B66B14A74BD26414B9C6114604E30C882F3D00B707CEE554D77D2085576810203010001

参考資料: http://download.microsoft.com/...

就職して初めての仕事は Mouchu でした

今の会社に就職して初めての仕事は、当時売り出されたファンシーなマウス「Mouchu (マウチュ)」関連のソフトウェアのコンポーネント開発だった。

今日 Mouchu が話題になったので、オフィスの棚に実物があったのを思い出してひっぱりだしてきた。 今でも2ボタン USB マウスとしては普通に使える。 使わないけど。

今日のさえずり - なんだ今日の西友男レジ係率は

2009年12月05日

• 08:48 待ってました。ユニクロのデニムジーンズ土日限定1000円引きセールきた。
• 09:22 妻に食べさせたかった一六タルトをあけた。ウマ。
• 10:03 今までほとんどリーバイスかエドウィンだったのでユニクロで買ったものかちょっと迷ってる。ジーンズまでユニクロになると靴が最後の砦になっちゃう。
• 11:43 @nekosuzu ユニクロのジーンズ、リーバイスの数分の1の値段ですもんね。明日ちょっと物見てから判断しようかと思ってます。
• 11:46 @nyafuru 年賀状おくれ。
• 12:01 ホットカーペットカバーのクリーニングができあがったと電話。3,520円。
• 22:23 ユニクロのジーンズ予習している。スリムフィットストレートジーンズ 66 BLUE が候補。サイズは32インチかな。
• 22:36 それかレギュラーフィットストレートジーンズ 61 BLUE。32インチがないので31インチか33インチ。

2009年12月06日

• 10:19 床屋行ってくる。
• 10:27 隣歩いていた人がデジタルハリネズミ触ってた。いいなあ。
• 10:29 床屋到着。制服変わってた。トロピカルやめ。
• 11:36 散髪終了。すっきり。来年のカレンダーは毎年貰っても貼らないので今年は遠慮しておいた。
• 11:39 次ユニクロ。
• 12:16 結局ユニクロで2本買っちゃった。スリムフィットストレートジーンズ。会社で不評なユーズドテイストカラー過ぎないやつ。
• 12:39 前にアンケートに答えた謝礼の1000円分クオ・カード届いた。ラッキー。
• 13:37 ジョナサンのお食事券が明日できれる。
• 15:42 なんだ今日の西友男レジ係率は。
• 22:31 Firefox プロファイル作り直してからしばらくログインしていなかった mixi にログイン。 http://bit.ly/3tKJ42
• 22:47 東芝の掃除機 VC-PY7E を Amazon.co.jp で買うかヨドバシ･ドット･コムで買うか迷ってる。 http://bit.ly/5fpWDe
• 23:01 @sidodtv 高機能はいらないので安価な普及機クラス。紙パック式。対抗馬の MC-K9A がカタログスペック的には静かだけれど実際のところキーン音が気になった。ヘッドの可動域も VC-PY7E の方が広く狭い部屋でも掃除やすそう。といったところです。
• 23:13 @sidodtv 家電量販店やら大型スーパーやらでなんどか触ってみて絞りこみました。カタログ見るだけではわかりませんね。
• 23:14 東芝掃除機 VC-PY7E(P) やはり Amazon.co.jp で注文した。色は妻の希望によりピンク。 http://bit.ly/8fmpBN
• 23:34 Windows 7 側に PIXUS MP980 のソフトウェア入れるのでいったん落とす。
• 23:50 PIXUS MP980 のセットアップ CD-ROM からソフトウェアインストール中。 Windows 7 関連のアップデートは別途する。
• 24:26 キヤノンのサイトからほとんど全部最新のものダウンロードしてアップデートかけた。
• 24:37 次、筆まめVer.19 インストール中。選択インストールできないのが悲しい。
• 24:51 筆まめVer.19 で不要なコンポーネントをアンインストールしようと思ったらほとんどのものが0バイトずつしか空き容量増えないという罠。

万能Jrくんでキッチンシンクと、風呂の鏡と握りバーがピカピカに

昨日ホーマック(ホームセンター)に行ったついでにマルシンの「スーパークリーナー万能Jrくん」を買ってきて、昨日と今日とでキッチンのシンクと風呂の鏡と握りバーの掃除に使ってみたところピカピカになって感激した。

• マルシン スーパークリーナー万能Jrくん

今のキッチンはシンクにクレンザーとか研磨剤入りのもの使いたくないなあと思って、デイリーのお手入れだけして1年以上経ったんだけれど汚れが落ちなくてだんだん汚なくなってなってきてしまっていた。でコンポーネントキッチンの取扱説明書をみたらこれがおすすめ便利グッズとして掲載されていたので買ってみたと。ちなみにシステムバスルームの取り扱い説明書にもこれが紹介されていたので、それなら違いないと思ったわけ(しかし実はキッチンはサンウエーブ → LIXIL で、バスルームは INAX → LIXIL であれっと)。

感じとしては靴クリームのような感じ。スポンジか布につけて綺麗にしたい面に塗り、汚れが浮いてきたら擦って汚れを落とす。

シンクのずっと落ちなかった汚れは何回か繰り返すことですっきり落ちてピカピカになった。

しばらくサボっていたレンジフードの掃除にも使ってみたけれど、固まった油汚れも万能Jrくんをつけてちょっと待つと取れるようになる。仕上げに水洗い不要なので助かる。ただ、つける・ちょっと待つ・こすって落ちなかったらもうちょっとつけて繰り返すというのレンジフードだとちょっと大変なのでこれは別の洗剤の方が良いかも。

風呂は鏡と握りバー(シャワーのスライドフックがついている棒)の掃除に使ってみた。鏡のウロコ取りというと研磨剤系が多くて躊躇するのだけれど、万能Jrくんは研磨剤が入っていないのでその点は安心できる。こちらもほぼ綺麗になった。ただ1回では落ちなくて何回も繰り返しつけてはスポンジでこするのを繰り返した。まだちょっと残っているので以降は定期的に掃除する時に使って落とそうと思う。

あと金属の握り棒についていた、お風呂洗剤やメラミンフォームでは落ちなかった水垢も結構落ちてピカピカになった。これは嬉しい。

そもそもあのバー、シャワーフック用のだと思ったのだけれど取扱説明書をみたら浴槽に入るときの握りバーだったという方が驚きであった。握りバーなんだ。握りバー。

---

[ 製品レポート ]

LINE DEVELOPER DAY_2015 Tokyo #linedevday

「エンジニアチームの様々な経験を、未解決の課題も含めて共有する」というテーマで開催された LINE 株式会社のエンジニア向けイベント LINE DEVELOPER DAY_2015 Tokyo に行ってきた。

会場の装飾やクリエイティブなどお金をかけていてすごいなと。始まる前にプレス向けにきちんと立ち位置や照明まで案内していて、とても行き届いていて運営力もすごい。

細かいところだけれどイベントサイトや事前案内は「LINE DEVELOPER DAY_2015 Tokyo」で当日の会場が「LINE DEVELOPER_DAY 2015 TOKYO」と表記を変えていてどんな理由なのかなというのが気になった。まあどうでもいいことだけれど、物を書くのにちょっと困る。

スライドはシンプルで洗練されているんだけれど、完成されすぎていて素材ぽくも感じた。

全体的に microservices アーキテクチャというのが印象に残るイベントだった。

A-1 オープニング 代表取締役社長 CEO 出澤剛氏

LINE の成長とサービスなどの紹介。ウォーミングアップ的に聞いていた。

A-2 LINE Global Culture 上級執行役員 CTO 朴イビン氏

「LINE のグローバルな開発組織や文化について」

ちょっと綺麗にまとめられすぎていて感じがした。泥臭さが感じられない。より現場的な話をぜひ聞きたいなと思った。

ペンディング・先送りされた「cold-case プロジェクト」について、また取り組むきっかけを用意するというのは良いな。

A-3 LINE Messenger for the World 上級執行役員 サービス開発担当 池邉智洋 @ikebe 氏

「色々な国の通信各社、様々な環境に対応するために進めた実験や改善方法について」

LINE アプリのバイナリは1つとのこと。各国の事情について「LINE 遠征隊」として現地で実際に使って改善していくという取り組みがきちんとできているというのは素晴しいと感じた。グローバルなサービスではなく国内向けのサービスでも参考にできるな。

ストアのレビューについて、レビュー文章のキーワード分析や変化の把握もきちんとしているとのこと。(アプリではないけれど)化粧品業界などが良くやっているやつか。 この辺りは自分の部署でも取り組んでみたい。

A-4 LINE Platform Development Chronicle Tom.T @tsurutom 氏

「LINE Platformを支えるアーキテクチャ、組織、文化について」

鶴原翔夢氏による LINE のアーキテクチャの変遷について。

• polling / push / long polling
• Erlang で LINE Event Delivery Gateway
• SPDY

など。アーキテクチャは microservices に移行している。

Abusing も独立したバックエンドになっているとのことだった。abuse 対策のコンポーネント化は考えてはいるんだけれど、サービス毎に要件が結構異なるので本体とどの程度の結合にするかが迷いどころなんだよね。いつかはやりたいところ。

A-5 HBaseとRedisを使った100億超/日 メッセージを処理するLINEのストレージ Shunsuke.N @sunsuk7tp 氏

HBase と Redis の話し。桁違いだ。

A-8 Webサービスの国際化にあたり LINE Creators Market 開発がどのように行われたか Tokuhiro.M @tokuhirom 氏

最近 Java を書かれているようだけれども LINE Creators Market はやっぱり Perl で書かれているとのこと。ちなみにアプリケーションサーバでは Starlet を使っているそうだ。

実際に開発する上で問題になったことも混じえた @tokuhirom 氏らしい語り口のセッションだった。

B-5 ベイズ推定とDeep Learningを使用したレコメンドエンジン開発 Jun.N 氏

なみかわじゅん氏。

まずはスタンプ間の(レコメンド的な)距離を計算し、その上でユーザー-スタンプ間の距離を計算するというフローでレコメンドを生成しているとのこと。処理には Hive も使っているらしい。

コールドスタート問題については、Naver Labs と共同研究開発した画像の類似度計算を使って似た絵のものをレコメンドできるようにして対応しているとのことだった。

以上

午後は途中オフィスに戻ったりしながら面白げなセッションを聞いてきた。夕方に歯医者があるので 17:30 まで聞いて退散。

第12回 エッセンシャル スクラムを読む会

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会12回目。今日は第12章 スクラムチームの構成。

今回の内容は主にスクラムチームメンバより上のレイヤーの人たち向けの内容です。

複数のスクラムチームによる共同作業が必要だと、いつかは思い知ることになるのだ。

ということで複数のスクラムチームの話。前半はフィーチャーチームとコンポーネントチームについて。本書ではフィーチャーチーム推しで、コンポーネントチーム構成からフィーチャーチーム構成へ徐々に移行する場合の体制の案を示しています。

フィーチャーチームかコンポーネントチームかという問題を解決する万能のソリューションはない。

ということで、ここはプロダクトと組織にいるメンバの状況に合わせて考えていくしかない感じです。

本章でも「同時に開発を進めるプロダクトの数を減らす」という話が出てきていろいろ考えさせられます。

スクラムオブスクラムについては、定期開催で開かれるのは良いとして現実的にはアドホックにどんどん相談していっちゃう方が早いんじゃないかなと感じました。

リリーストレインについてはかなり大規模なプロダクトが想定でしょうか。「スクラムのためのアクティビティで時間が奪われすぎないか」「末端のスクラムチームでは適応できる余地が少なくなってしまうのでは」などという疑問が湧きました。

• エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド