Git is not distributed version control system.¶
Git is not distributed version control system but version control system of distributed repository type.
Hack Meeting #3¶
本日はマクド南新宿店での開催。参加者はいつもの通りiwamatsuさんとワシの二人。参加者をもう少し増やしたいところ。
前半はOSCの反省とそれを受けて次回(秋)どうするかについてと来月以降のDebian勉強会をどうするかについての議論。
後半はiwamatsu先生によるgitの個人レクチャー。よく分からなかったところ(どうやってmerge時のconflictを解決するかなど)がかなり理解できた。そして何気無い質問から判明した事実。gitは“分散バージョン管理”ではなく、“分散リポジトリ型バージョン管理”である、ということ。リポジトリは分散するが、共通の目的に向かってバージョン管理は同じベクトルである。インターネットのネットワーク構成や会社組織に似ているかなと。
さらに本日の発見としては、vimで入力モード時に^Pや^Nを入力すると、キーワード候補が表示される！知らなかった。
２月度社内勉強会¶
昨夜開催。今回は５つの新たな試みを行った。
曜日を第４木曜から第４火曜に変更。曜日変えるだけなので、勉強会そのものには大したことでは無いのだが、個人的には大有りなのだ。
メイン幹事が二人とも発表しなかった。今回で確か21回目だったハズだが、実は初めて。いつもネタをどうしようか、ということで開催案内出す頃に毎回頭を悩ましていた。今回はid:z_ohnamiさんやクロスさんもからの要望があり、全社で来期以降に公開予定の共有検証用環境の立ち上げを行った同期にお願いをしてそれに関わる裏話を、もう１つは社内のコンピテンスセンターでやっているSI部隊向けの開発環境についての話をid:z_ohnamiさんの同僚にしてもらった。
参加申込みをメールから宴会くんに変えてみた。がこれはあまりうまく行かず。使ったことがない人が多いのだろうか、事前参加表明は五人だけだった。orz
直前での一本釣り作戦を敢行した。事前参加申込みには発表者は入ってなかったので、一本釣りでは四人飛び入り参加となり、参加者が今までで最大の11人に達した。またネタに対する皆さんの関心も高かったので、それぞれのネタについてもとても活発な議論を交すことができ、とても有意義だった。
懇親会を飲み屋から、その場でのビアバッシュに変えてみた。いつもの実績から5、6人と見ていたので直前の一本釣りで足りなくなるかと心配していたが、結果的には懇親会には５人参加だったので、id:z_ohnamiさんの見込み通り。ちょっとピザが多かったけど御の字。
ネタを頼んだ同期とは飲むのも会話するのも久々だったのでとても楽しかった。隣の部門レベルでさえ何をやってるのか分からないのだから、本部、事業部となるとますます分からなくなるのは当たり前だよなということと、全社的にリソース(人、金)の割り当てと各部門の取り組みをコントロールができていないのだな、という事を改めて実感。目的(開発部隊向けだったり運用部隊向けだったり)と手段(Hyper-VだったりVMwareだったり)は各部門で異なるのだが、やっている事の本質は同じ(開発環境や検証環境、トレーニング環境を用意する)なので、経営層のオッチャンたちはもうちょっとうまいこと手綱を引いてほしいなと。
上流行程で成功する人、つまずく人¶
本屋で流して立ち読みしたら面白そうだったので購入しました。
前半はタイトルにある上流行程における、特に教科書的に体系立ててまとめられてはいない、要望の収集から要求の獲得についてを重点をおいて解説されています。文中でも指摘されているが、PMPなどのプロジェクトマネジメントの手法は、要求はすでにあるもの、発注側であるお客様で洗いだし、確定していることを前提としています。契約の下に発注者と受注者が平等だという欧米社会には合っています 1 が、概して契約を挟んで受注者が発注者に従属する日本社会には、この著者が指摘するように従来の手法は必要であっても十分じゃありません。考え方としてはPMPより広い領域をカバーするP2Mに似ています。
後半はプロジェクトにおける実践の話、というかバッドノウハウというか、単なる作業者と知識労働者は違う、プロのSE、知識労働者たれ、という感じの論調です。本書のターゲットは上流行程を目指す人を想定している筈なのだが、単なる作業者はこういう輩だから気をつけろ！という感じで書かれているのが面白いですね。見方によっては単なる作業者は切り捨てているようにも取れますが、私は単なる作業者や自分は単なる作業者じゃないと思っている人ほど、本書を読むべきだと思います。後半に限らず、全般にわたり、自分はこれって出来ているだろうかとグサッとくる箇所があります。
私が気になったフレーズを以下に引用しました。
もし、プロジェクトにおいて
「ユーザーが決めてくれない」
「ユーザーがはっきりしない」
という発言がみられるとしたら、要望収集はほとんど失敗しているといえます。
また、要望を収集する役割の人が、問題を捉えていないこともあります。(中略)
「この開発では、何の問題を解決しようとしているのか」
ということを理解していなければ、誤った仕様をつくり、設計、実装するので、最終的に誤ったものをつくってしまい、結果として、プロジェクトは失敗することになります。
よく聞く話なので、自分が絡んでいない案件だとしても耳が痛い内容です。
「サンプルどおりにつくったのに、どうしていけないんだ」
「顧客が仕様変更をたくさん出すから、スケジュールが守れない」
「営業が無理な条件で仕事をとってくるから、納期なんて守れない」
「自分の考えなんて持ったって無駄。どうせ妥協しなくちゃいけないんだから」
「言われたとおりにつくったのに、何がいけないんだ」
「自分は悪くない」という姿勢かつ、自分では何も考えていない。”作業者”は「やりました」ということに重点をおく。「できました」ではない。
これもよく聞く話です。最初のとある意味では相反するところではあるのかも知れませんが、とはいえ、そういうことを言う輩も本来はプロなのだから、そんなことを言って逃げんなよ、と思います。
成果物をつくるのであれば、その成果物がその金額に見合うものかを考える。判断に迷った場合は、自分がその金額でその成果物を買うかどうかということを基準にする。
サービスであれば、自分がその仕事に対して顧客に提供した時間を考え、素の時間に素の金額に見合う価値を顧客に提供できたかを考えます。自分が提供した価値に対して同じだけの金額を自分が払うかどうかを基準にしてみてください。「今日の自分の話を聞くために、自分自身に○万円払うだろうか？」を自問自答してみましょう。
最近、自分がお客様だったらどうだろう？という視点を持つようになってきたので、これはよく理解できます。料金が決まっているとか、SE単価がいくらだから、とかいう輩には是非考えてもらいたい内容ですね。
久々の良書に出会ったと思います。細かい点では所々ツッコミどころもあるにはありますが、基本的に言いたいことは一貫しているので細かい話は瑣末な事です。ページ数もあとがき含めて150ページ程度で一時間あれば読める内容で、千円でお釣りがくるので一読してみることをお薦めします。
- 1
P2Mの研修で聞いた話だけなので、本当にそういう文化なのかはよう分からん。
OSC2009 Spring/Tokyo参加報告。¶
今回も東京エリアDebian勉強会として参加。
Debian勉強会で今回自分がやったこと。¶
Debian on Chumbyの準備・展示¶
準備は”Debian on Chumbyに挑戦中。その１～その５”としてブログに書いた。問題は、スタンドアロン環境で、どうやってsshでログインするかというところで、今回の会場は無線LANがあるということで、無線LANでやろうとこだわってしまったことで、現地での準備に時間が掛かりすぎてしまった。PCの方はギリギリ無線を拾えたのだが、Chumbyでは無線は拾えてもIPアドレスを割り当てるところまでに至らず。結局、事前に準備しておいたUSB-Ethernet変換ケーブルで接続することにした。さっさとこっちにする判断を下せばよかった。
展示した後はほとんどブースにいなかった 1 ので、来客の関心はどうだったのかを後で聞いてみたところ、イマイチだったとのこと。敗因を考えてみた。
見せ方
液晶に来月の宣伝用のWidgetを表示し、eeePCからSSHでログインして/proc/cpuinfoと/etc/debian_versionを表示させるだけだったので、Eye catchとしては弱すぎた。しかも分かりづらい。終わり間近にブースにいたときに、chumby自体に興味があるLinux勉強中という女性がいたので説明したのだが、chumbyを人寄せパンダとするのはイマイチか。
前回も、OpenBlockSやArmadillo-9を展示していたが、同時に12アーキテクチャもサポートしてリリースする変態ディストロとしては、どんなものでも動いて当たり前と思われるのかもしれない。そもそもchumby自体はLinuxだしな。次回以降のブース展示内容は単純に変わったハードウェアでDebianを動かしました、という方法じゃなくて、何かひねりを入れた方が良いかもしれない。
技術面
実際には、今回はネイティブにDebianを動かしたのではなく、USBにインストールしたDebianをchrootで動かす、という擬似的なものだったのと、液晶画面はなにもいじらなかったので面白みは少ない。ネイティブで動かすか、液晶でDebianのコンソールを表示させてUSBキーボードで操作できると面白いか。
ちなみに今回の内容は内容をまとめてDebian勉強会の資料として公開する予定。
Debian on OpenMicroServerの準備¶
ハンズオン中に準備していたのだが、ハンズオンが終わった段階ですでに１時間切っていたことと、ブースにそのスペースもなかったので展示はしなかった。
Debianパッケージ作成ハンズオンのアシスタント¶
今回は２コマで開催。前回よりは進んだが全部は終わらなかった。全員の進捗に合わせてやるのはやはり難しいですな。いきなりつまづいたのは、liveCDを起動できないマシンが結構あったのでそこで時間を食ってしまった。fail safeモードで起動させたらXfceまでちゃんと起動できたのだが、何が違うのかは謎。その他、アシスタントをやってみて、聞いた意見としては気になったのは以下。
普段つかっているviと画面表示や操作感覚が違う。
いや、それが普通のviなのですよ。普段使っているのはviはvimへsymlinkされているのですよ。
手順どおりにやったのにうまくできない。
で、見てみると、大半はスペルミス。スペルミスでつまづいた人はその後もかなりの頻度でスペルミスしていた。
実はカレントディレクトリが違う、というのもあった。
設定ファイルが保存できません。
mousepadを使っていた人に見られたが、root権限が必要なのにsudoを実行していなかった。
初心者向けのハンズオンはありませんか？
Debianパッケージの作成自体が初心者向けじゃないので、ちょっと難しいかも。
今回は岩松さんがハードルを下げる苦労をして準備した環境なのだがそれでも予想外の質問が上がった。Debianどうこうというよりは、Unixリテラシが低いのかなぁ。OSCというイベントの特性上、それはある意味止むなしなのだけど、セミナーならまだしもハンズオンの場合は、参加者ターゲットのレベルをある程度絞るために事前課題とまではいかなくても、前提条件を提示しておくのが良いのかもしれない。
一般参加者として¶
仮想化友の会のセッションを２コマ聞いた。はてなの田中さんのお話ではMyDNSを活用する方法はなるほどと思った。あとはDTraceとSolarisゾーンは楽しいですな。
宴会¶
前回同様、今回もOSCの懇親会には参加せず、Debian勉強会の面々＆会社の後輩のid:shase_labさん 2 の５人で大久保駅前の焼肉屋で宴会。生ビール２杯と豚バラ焼肉食べ放題で2,500円。食べ放題は1,500円なのでかなり安い。ここで決めたこと。
ここで宴会をするために、大久保近郊でDebian勉強会の開催を計画する。
3月の平日にDebian牧場を開催。有休をとって自然に触れ合い、3月誕生日のメンバーでセルフケーキ作りをする。
3月のDebian勉強会 in 東大で、id:shase_labさんに*BSD＆Ubuntu使いからみたDebianの話をしてもらう。
お土産とスイーツを忘れない。
さっさと何かDebianパッケージをメンテナンスする。
Debian on Chumbyを勉強会資料にする。
あと言わなかったが、Erlang & CouchDBがらみで何かネタをしこもう。