ブログ村

Chefがつらい人のためのAnsibleのはなし @ ゆううきブログ

なんかサーバ構築にやたらと時間かかるんだけど何で時間かかるのか考えてみた @ 馬鹿と天才は紙一重

はてブの方からまとめる。

• 「要件が明確でない」
• 「手順の検証が足りない」
  • リハーサル重要。二回目以降は時間が掛からない
• 「テスト項目が足りない」
• 「自動化の不足」
  • VargentやChef使え
• 知識不足
  • 数をこなす（経験を積む）
  • SELinuxとか、存在を知っていないと原因を思いつきもできない系のハマりどころはメモる
  • 1年で情報が陳腐化することも
  • ググって見つかる情報に頼らず、できるだけオフィシャルに近いドキュメントを見る
  • 情報の再利用は自分なりの方法を確立すべし
• 問題切り分けスキル不足
  • 基本は「作業メモを取る」
  • 20分ルールを設定してそれ以上かかったら誰かに聞く

あと、

俺がコーディングしてて感じることに酷似してる

会議で意見を言えないあなたへ。「自分で考える力」を身につける5つの方法 @ ライフハックブログKo's Style

アーキテクチャ設計の難しさについて @ arclamp

• はてブ

Webクローリング＆スクレイピングの最前線 公開用 @ はてブ

誰かを教えることになったあなたへ -IDへの招待 @ 図書館学徒未満

• 失敗してから気がついても遅い！ プレゼンの準備を怠ってしまう2つの理由 @ プレゼンの上手な話し方 | ダイヤモンド・オンライン
• 5－10分程度のプレゼン準備に関するメモ書き @ Harvard Business Schoolへの道

準備期間の投票結果によると、4割の人が3日〜1週間かけるようだけど、2割が1, 2日、1割が数時間とのこと。

一週間は理想。でも再利用の効かない毎回異なる内容の30分〜1時間のプレゼンを平均1週に1回するには2日で作成、リハ2時間が限度。
資料を書いていると問題点が整理されてきて、担当者ともう一回揉んでみたくなる事もしばしばだが、そういう時に限って相手がつかまらないんだよね。

1. クラウド事業者がテクノロジーリーダーになる理由3 @ Publickey
2. 分散ストレージの整合性をいかに解決するか。プライマリ-バックアップ方式と分散コミット
3. チップスケール原子時計やSoCがこれからクラウドを変えていく

Webデータ分析＆データサイエンスで役立つ統計学・機械学習系の分析手法10選 @ 道玄坂で働くデータサイエンティストのブログ

情報が少ない

ネットで調べても同じ境遇の人の絶対数が少ないので情報が見つけられない。 悩みどころは同じでも、OSのディストリビューションの違い、バージョンの違い、カスタマイズの違いなどで応用できる情報ではなかったり。

Windowsで、XPの『アプリケーションの追加と削除』が「プログラムのアンインストール」とか「プログラムの追加と削除」に変わっているようなもんですが、Linuxではディストロのバージョンアップの際に同種機能の別プログラムに置き換わったりするので混乱の度合いが大きい。lilo→grubとか。

日本人特有の問題として、英語の情報が苦手(その人にとっては情報が無いのも同然)ということもある。

同じことをする手段がいろいろありすぎる

ある目的に対して手段が複数用意されている。しかも「標準」の一つを覚えれば事が足りるというのではなくて、特定の環境で使えるのは一種類だけだったりするので結局二つ三つと覚えないといけなくなる。

例えば、「管理者権限で/etc/***.confを編集する」という時のお作法はいろいろある。 これまで経験しただけでも以下のようにいろいろ。

• suでrootのパスワードを入力する
• suで現在のアカウントのパスワードを入力してrootの別名アカウントになる
• sudoで現在のアカウントのパスワードを入力する
• ssh-agentに鍵を登録しておき、sudoする

どの方法が有効かはディストリビューションではなくサーバ毎のポリシー依存だから、結局全部のお作法を覚えていかないといけない。

ディストロパッケージという平和な世界は儚く脆い

OSディストリビューションのパッケージとして提供されていないプログラムを使いたい時に、ソースからビルドするとき。 configureに、ライブラリが古いと言われたがディストロパッケージでは新しいバージョンが提供されていない。 するとソースからビルドした新しいライブラリを入れることになるのだが、ディストロパッケージ由来のを削除しようとしても、依存している他のパッケージがインストールされていると警告が出て削除できない。

例えば以下のようなやり方が考えられる。
1だと、後からディストロパッケージをインストールしようとして競合するおそれがあるのでかなり危険。
2, 3は知識と手間をかなり要する。

いずれの手段をとっても、ディストリビューションの提供する世界から一歩外に出ようとすると、途端に地獄が待っているということ。

1. 依存関係を無視させてライブラリのパッケージを削除
   →ソースからbuild & install→プログラムをbuild & install
2. prefixをつけてライブラリをconfigure & build & install
   →ライブラリ、ヘッダのサーチパスをカスタマイズしてプログラムをconfigure & build & install
3. プログラム専用の仮想環境を作って、新しいバージョンのライブラリを提供しているディストリビューション(Fedoraとか?)を入れる

Depndency hellはWindows OSにおいてわざわざDLL hellという固有名詞(?)が与えられていてWindowsの問題として覚えられがちだが、今となってはLinuxの方が深刻なのではないかと思う。
GTK+とpangoのように開発グループが分かれているようなのだと、特定の組合せしか考慮していないアプリが結構ある。

まとめ: 敷居を上げちゃうような多様性が問題では

カスタマイズや組合せの自由ばかり増えても、トータルで使いこなせないものになっては意味がない。一人の人間が理解して制御できる世界なんて限られているのだから。

複雑さを増さずに機能を追加する方法はUI/UXの分野で研究されているんだけども、なんだか範囲限定でしかトータルのバランスがとれていない気がして惜しい。例えば特定のアプリケーションがOSやウィンドウマネージャのL&Fを無視した独自UIを提供するとか。

あと、既存のエクスペリエンスを体験してきたユーザが違和感なく新しいエクスペリエンスに馴染めるようにする工夫がもっとほしい。