2015/02/23

勉強会行った005 - Windowsでの自動化について考える会

なんで003の次が005なんだって?

うるせぇ!気にすんなw

情報

なんで行ったの?

社会人になり「自分の事はMSの社員になったと思え!」とWin95デザインガイドを抱きしめ(させられ)、デスクトップアプリ作ってた20代前半。

それがイヤで反動から「LinuxやOSSの世界」を手持の道具にした現在。

時を経て、CI(継続的インテグレーション)やCD(継続的デリバリー)知って眺めるに、浦島太郎となった「Windowsの世界」にも、Infra as a Code等の「新しい概念」がそろそろ来てるんじゃね?ってことで知識を仕入れるために参加です。


内容


1コマ目 基調講演 「Windowsでの自動化の手段」ヒダリさん (@HIDARI0415) さん

資料:

本勉強会の主催者であり『露払い』的役目のヒダリさんの発表です。(俺が遅刻して前半見てないのは言うなw)

自動化のための手段には「3つのレイヤー」がある…というのは、凄く納得行く良い説明ですね。

「Scripts」方面に関しては、懇親会でも話していたのですが、

(原始的側) コマンドプロンプト <-> PowerShell (プログラミング側)

と、(吟味し進化したものの)両極に(まだ)振りすぎなんじゃないか? という話をよくします。

で「頃合いのがほしいねん…」っていうlinux/UNIX好きがWindowsに「Sygwinだ、GitBashだ」と入れ始める。

その話を「宗教戦争にせず」に、要求ベースで考えると…

  • (イラっと来ず、かつ複雑でない程度の)制御構文(if,for,etc..)
  • リダイレクトやパイプなど「結果を受け継ぐ」に充実した手段(xargsとかも込で)
  • 「式」も出来る限りコマンドとして(bashのforとかexprとか)

なのかなーと、漠然と。(まあ、だからといって「ご破算にして4つ目作れ」とは言いませんけどw)

「Build Tools」に関しては"必修!" ハイ終了。

「Executers」に関しては、やはり「MS側のJenkins-er代表」のヒダリさんの面目躍如で、そうなりますよねw

古い人間としては「スケジューラはサードパーティ含め数々の趨勢があった」感じがしていて、やはり「公式(タスクスケジューラ)では弱い」という認識が一般的なのではないかな?と思っていましたし、ここは「標準装備で」の進化を期待したいと思います。(だいぶ進化しましたけどね)

最後に「だがpauseお前はダメだ」で参加者(fkmtさん)から「pause陣営側からのフォロー」が入ってましたが、「自動化する時(無人自動実行バッチ)には邪魔者」ってことだと思います…ってことでヒダリさんに賛成!w


2コマ目「Windowsの自動化今昔先夢語」森理 麟 (@moririring)さん

資料:

本も執筆され絶好調のモリリンさん。

この方の立ち位置って、なんとなく「ホームグラウンド/得意技を"MS系"にしている(そりゃMVPだしw)」のだけれど、それにとらわれず「自動化自体の実現方法と有用性を探ってる」っぽく思えて、そこが好きなんですよね。

で、良く似た事を考えてる…気がするw

特に「金銭のライフログ問題」とかの話されてたんですが、それもかぶってる上に高度でまた悔しい…w

俺も前から「金銭」と「健康(例:体重とか)」と「勤怠」については「無入力ライフログ」と名付けてライフワークにしているのですが…これは「一度二人で話し合った」ほうが良いのかもしれませんw


3コマ目「価値あるシステムテスト自動化の実現By friendly」石川 達也 (@StoneGuitar777 )さん

資料:

テスト系OSSプロダクト作成者 兼 社長 兼 MS-MVP 兼 おとん 兼 ギタリストの石川さんです。

「プレゼンの匠さ」と「扱ってるモノの良さ」も相まって「一番人の気を引いて、一番質問が多かった」セッションでした。

実はすっげー重要な事を前半言ってまして…

  • テストPGに「ある程度の抽象度」があれば「ロールを超えた共通知」に出来る可能性がある
  • Windowsクライアントのテストにも「WebにおけるPageObjectぽい考え」を入れるべし
  • その道具は「デフォで無い」ので「選ぶ/探す必要」がある(そうでなければ茨の道を…)

てな話が入ってたんじゃないかなーと思うのですが、自分のコンテキストで解釈しすぎでしょうか。


4コマ目「Hyper-VとPowerShellによる仮想サーバの自動構築」waka さん

資料: ここ

今回は「コレを観に来た」のです。 (他の人らごめんなさいw)

実際、CI/CDを考える時に

  • 構成をプログラムで書ける
  • (OS/ミドルの組、またそのVerの組など)組み合わせ違いの環境を簡易に用意出来る
  • クリーンな環境を用意できる

ってのは凄い「値打ち」があって、自分は「Windowsでそれやる方法」に疎かったので…。

ただ、セッション中wakaさんが「誰得」「これ役立つかどうか…」としきりに言われてたのが気になりました。

実際、仕事で…

  • 個々プログラマの「開発環境端末管理」がアフォほどコストかかる
  • 端末をクラウド化してVDI出来ないか
  • 共通部分(OS,ミドル,プログラム)は構成管理しときたいしビルド出来るようにしたい

という要望に「なんかない?」って言われ、応えられないことがありました。

そうでなくても「Linux/UNIX界隈はいいけど、WindowsServer周りの構成管理、どうすんねん!?」って問われることが何度かありました。

ニーズは多い…いや多く無くとも「クリティカルに必要としてる所はある」と思っていて、「そういうトコと繋がってくれはったらいいなー」と(自分は何もせず他力本願に)願っています。

あ、急に話変わりますけど「自分で作るときはHiper-Vに依存しない書き方を学びたいなー」と思いました。

しっかし…「サ○ラエディタが起動する度に会場から拍手が巻き起こる」ってセッション、大爆笑しましたw


番外 懇親会

もう掛け値なしにおもろかったです!

登壇者+αで居酒屋に行ったのですが「自動化について全員一家言を持ってる」ってメンツと話すのが楽しくて楽しくてw

最終的に

「世の中のエンジニアは二つに別れる…『勤怠をつけなくてはならない』か『そうでないか』だ!」

からの「勤怠エリート」「勤怠貴族」って話のクダリがww今も腹筋をwwww


所感

自動化の「マインド・考え方」と「実現手段」のバランスが凄く良い、余す所無い勉強会だったと感じました。

自動化は喧伝されるより取り組んでるところはすくなく、ましてそれを軸にするエンジニア、かつ勉強会に来る人はそう多くないのかもしれない…というのが最近の感覚です。(だっていっぱいおったら仕事なくなってまうしw)

ましてやWindowsっていうコンテキスト限定で30人前後集められる、というのは大成功なのではないでしょうか。

ド個人的には「次は無いんですか」ってのと「なんなら懇親会だけでも」と、運営に投げ込んでおきたいですw


主催者ならびに、スタッフの皆様、会場MOTEX様、お疲れさま&ありがとうございました。

2015/01/19

勉強会行った003 - Jenkinsユーザ・カンファレンス2015東京(中編) #juc2015 #jenkinsja

うん?遅いって?違うよ「資料が出るまで待ってた」んだよ!(詭弁)

(結局3部構成です…トホホ)

前回までのあらすじ

ここらへんを見てくだせえ。

内容

3コマ目:メインホール 「JenkinsとPuppet+ServerspecでインフラCI」常松伸哉 (@tnmt, GMOペパボ株式会社) さん

資料:

まとめ: http://togetter.com/li/768855

拝見したセッションです。。

2013年頃から「Infrstracture as Code」に取り組んでいらっしゃる、ペパボの常松さんの発表でした。

DevOpsと言う単語が席巻して数年、インフラエンジニアからプログラマ、プログラマからインフラエンジニアと行き来する「スーパープログラマ」が一定数いらっしゃるようになりました。

だから今「サーバ構築業」も「プログラミング」も「コードにて表す」ということにおいて垣根が薄くなってって行っていると思います。

「コードならばテスト出来るよね」「テストするなら自動テストだよね」と言う「プログラマーの文法」もおいしいとこ取りできるわけで…

  • サーバ構成管理コード = プロダクトコード
  • サーバ完成検査コード = テストコード

と見立て、それにCI回すのも頷ける話。

…の具体例でPuppetとServerspecとJenkinsで、というのがこの発表でした。

全然やってないのですが、凄く理想的に思え興味を持ちました。

で「大事なのは概念」と思いまして…

「ChefでServerspecでJenkinsでDockerな環境」

という自分が今戦ってる土俵でやってきたいと思いました。

「Serverspecいいなー、俺もやりたいなー」と思って、スライド内の入門本の発売日をみるとなんと昨日!是非買いたい!w

3コマ目:S505教室 「クックパッドにおけるJenkinsの活用」高井直人 (クックパッド株式会社) さん

資料:

まとめ: http://togetter.com/li/768841

実際には見ていないセッションですので、資料を参考に書きます。

上の"まとめ"を見ていますと「資料よりその場で説明したモノ」が多く思えます。くー残念!見たかった。そっちも参考に書きます。

「おむきんす」さん…なんですねw

内容…の前に

クックパッドさんは、自社のブログにて技術情報を開示、有用なものはOSSとして公開されています。

当日見てない自分としては「ここらへん読んどく」と理解が早かった…かなと。

クックパッドさんは「量とスピード」にずっと戦って来たのですね。

CIの構成

序盤は「普通に(CI)している」ということで、自社のCI構成の説明されています。拾えるのは…。

  • ほぼ全てAWS上
  • Jenkinsのマスター・スレーブ構成
  • スレーブ中にDockerを使ってるヤツが居る
  • スレーブ中にAndroid/iOS用があり自社サーバルームで動いてる

という感じ。(自分には出来なそうな…w)

…世の「普通」は、難度の話でなく「世のCIの原理原則に乗っ取って」すると、こうすべき…なんだろうと思いました。(資料の最後に答えをくれる構成ですが)

「なぜCIをしているのか」の話

「"CIで守るべき価値"があるから」という話で、そこを掘り進めて「そのために実際に行なっている事」を説明、という流れでした。

「ドリルダウンして説明」しているのですが、当たり前ながら「資料は平面的」なので、自分のためにアウトラインを画像にしてみました。

これを意識できれば、自分も「いっちょ前のCI-erになれる!」…かなぁ?

キーワード

整理したら満足したので、印象強かったキーワードだけ取り出して感想を言って見ます。

  • 開発者は遅いとキレる

ありますねw そうすると「最終的に見なくなる」だったりするので、「意識のある間」の「クイックフィードバック」と「嫌が応でも知る仕組み」、てのは重要かなと。

  • 長時間掛かるテストの投機的実行

これは「そういうのもあるのか!」と感心しました。

まとめに意見がありましたが、自分も「スポットインスタンス怖い」みたいな考えだったので…。

でも、スポットインスタンスでなくとも「考え方と仕組み」は脳内に置いときたく思います。

  • 偽陽性を避ける、割れ窓理論

これは強烈に同意ですね。

CIの最大の敵は、「当たり前になり無関心になってしまう」なので。

〆の言葉

「ふつうにしている

= やるべきことをやる

= 常にそうあるようにする」

うーん、そうなんですよねぇ。

特別事にしない->日頃からやっておりあたりまえにしとくっての、いろんな局面で出くわす教訓です。

3コマ目:S406教室 「Jenkinsを使ったコンシューマゲームでのデプロイとテスト」田中宏幸 (@swiftnest,株式会社イリンクス) さん

資料:

まとめ: http://togetter.com/li/768865

こちらも、実際には見ていないセッションですので、資料を参考に書きます。

同じソフトウェアでもプロダクト種が違えばコンテキストが変わる話

「デプロイに14時間34分かかる」という話、自身は業務アプリの世界に身を置いているので、そうなんだなと思いました。(大規模だと時間掛かる例はありますけど、ここまでは行かない)

しかし、横並び違うセッションでも、やはり「テスト・ビルド・デプロイ時間掛かる問題」に戦っているというのは、普遍的な問題なのだなと思いました。

Build Flow Pluign

ビルド(デプロイ)パイプラインを「Job自体に「後続はコレ!」みたいな依存を書かずに」実現するには、このプラグインになるのですが…

  • とあるJobに書かれたDSLに依存することに成る
  • DSLの構成管理がVCS等で出来ない
  • 事前にフローが視覚化出来ない(チャートでここまで来てるとか出来ない)

っていう運命を背負います。

ご多分にもれず問題と捉えられてるようですが、解決策が「Workflow Plugin」とのこと。

基調講演のアイツは「多くの人の期待を背負ってる」ってことがわかりますねw

スモークテスト

まとめから拾いますと…

「コンシューマゲームではSeleniumみたいなツールがないけど品質を保つために」

  • 全エフェクトを再生するテストを書いて、制限時間内に終わるか(刺さってないか)をもって確認
  • 引数で特定の部分だけを動くようにして、一定時間内に終了しなかったらエラーに

としているとのこと。

後者は「対象問わず有用」ですんで、自分が仕組みを作る際に頭に置いておきたいと思いました。

モンキーテスト

これは凄いと思いました。

  • ゲーム開始からエンディングまでの通しプレイを自動で行うAI作成
  • 戦闘中がガチャ押し、次エリアが開放されたら敵AIが使ってるパスを流用して移動
  • 画面の状態を見て挙動変更
  • 3回ミッション失敗で無敵&攻撃力100倍

ギョームアプリで言うと

  • Selenium/Sikuliで「一日分の代表的な業務」をやるエージェントプログラムを作成
  • あまりにもシステムエラーが出まくるなら「特権アカウント」に移行して実行

みたいなものを作成した、ということでしょうか。

パターンにもよるとは思いますが、凄い事で…この考え方を明日の仕事に生かせないか考えたいと思いました。

動画…観たかったなぁw

まとめから

「Jenkinsでの環境構築を開発スケジュールに入れておく」

自社の組織レベルで、CIをコモディティ化したいなら、重要飛び越えて必須なことだと思います。

長い目で見ると、

  • 忙しくなってくる(事後作業)だと暇ない
  • 投入してからはコンスタントに成果が出る
  • 他プロジェクトや派生開発でも使える

という特徴から、コストは回収出来るはず…です。(数字出されろつうと辛い所で、そこが課題ですが)


所感

Jenkins(ひいてはCI)の開発プロセスへの浸透は、その職種問わずコンスタントにしているのだなと感じます。

なので、カンファレンスや勉強会でも「個々の使い方」に話がシフトするのは、当然の話で…。

であるなら、事例発表からは、「その考え方」や「自分の身に置き換えて明日どう使えるのか」を抽出するのが重要だなあと感じました。


もうちっとだけ続きます。 (次回で終わらすぜ)

2015/01/14

勉強会行った003 - Jenkinsユーザ・カンファレンス2015東京(前編) #juc2015 #jenkinsja

待ちに待ったこの時がやってきましたよ!

(思いのタケがありすぎるので、二部構成ですw)

情報

なんで行ったの?

勉強会に参戦するようになってすぐで、参加しのがした「第一回Jenkinsユーザカンファレンス東京」。

参加出来なかったのを髪の毛が丸坊主に成るくらい悔やんでた2年間…そりゃ参加するってもんです!


内容

着いた!らへんの話

行きたい行きたい言うてるくせに、電源あるとこでダラダラしてしまって…開始時間を間違えたので基調講演を少し聞き逃してしまいました。(12:40くらいかなぁ着いたの)

前回もそうでしたが、大学でやるんすね!広い!! (法政大学様ありがとうございます。

入り口の出迎えで、ノベルティを大判ぶるまいしてました。ステッカー頂いたっ!

早く来たらTシャツとかバッジとか貰えたと聞いてはくやんでも悔やみきれませんw

本編紹介…の前に

基調講演の資料中に含まれてたかどうかは曖昧(遅れていったし)のですが「申し込み時のアンケート結果」が出ているので、貼っときましょう!

勿論、聞いてる層が「興味を持ってる人」達なので贔屓目は勿論ながら、「Jenkinsは必須?」が7割近いのは個人的に嬉しいところ。

「使う上で難しい点」「良くなって欲しい点」は、「Jenkins運用時にハマりあるある」とも言えるので、Jenkins導入の時に考慮しといたほうが良いところかな、と。

1コマ目 基調講演 「Jenkinsプロジェクトの現状とワークフロー」川口耕介 (@kohsukekawa, CloudBees) さん

資料:

まとめ: http://togetter.com/li/768907

基調講演は勿論!我らが川口さん。

評するのもおこがましいのですが…川口さんの講演は「力いっぱいTechな開発の話」の中に「熱い〜」って言う単語が必ず入る、そういう「技術者のエモい感じ」にじみ出てて凄く好きなんです!

また「絶対にデモ見せて唸らせる」というところもたまりませんよね。

内容も「今これに力入れてます」という「これから来るであろうトレンド」のヒントを貰えるので、聞き逃せません。(201312の東京Jenkins勉強会では次の年に「実際使ってく道具」を一杯貰いましたし)

で、お話のメインとなった「Workflow Plugin」は、

  • Scriptに寄せるのかPluginでがんばるんか
  • Pluginの中でもPlugin積んでつなぎ方をがんばるんか、DSLで実現すんのか
  • 人間系で「この人に確認してもらうねん」とかをどうすんのか

という「ビルド/リリースの長大パイプライン組んだ場合の悩みどころ」に一石を投じてくれる、良いプラグインだと思います。

「Build Pipeline Plugin(+その他Plugin盛り)」と「Build Flow Plugin」の二択に迷う時や、これらでは扱いきれないフローが出た時の選択肢になってくれそうです。

また「Jenkinsのユーザに部長とか人間組み込める」ってのは新しい感覚な気がしました。

自分も「これから人間系と複雑系に当たってく」というところなので、直近のトレンドとして使っていきたいです。

…「チェックポイントからの復帰」っての、どうするんやろう…。(使ってみて自分の目で確かめろ!系かw)

他にも「DotCi」「受け入れテスト&ハーネス」の話など「Jenkinserには使える話題」を多く貰いました。

2コマ目:S505教室 「はてなにおける継続的デプロイメントの現状と Docker の導入」信岡裕也 (@nobuoka,株式会社はてな) さん

資料:

まとめ: http://togetter.com/li/768897

(メモから記憶蘇らせてるので間違ってたらすみません)

とある理由により必ず選択する予定だったセッションです(超満員!)。

自分も「全道具をテスト実行する時に用意して終わったら跡形もなくなる環境」(イミュータブルインフラとか言うほど高度じゃない)をDockerで作ろうと(必要ないのにこだわってw)やってる身なので、高度さは30倍くらい違うものの「わかるわー」な所がありました。

(ただし、当方Java&SVN&mvnなので、イージーモードではありますが…)

「スクリプトの構成管理」問題は、

  • 標準ジョブに「svnからチェックアウト」仕込み
  • 標準ジョブにスクリプトとして「svn export *」を書く

で「実行時に最新でやる仕組み」取ってるので「はー同じかー」って見てました。

「そうか、こうするのか!」と思ったのは「(Webサーバと)DockerAPIを用いたPortの解決」でした。

自分は「コンテナ起動時にコマンドで"固定のポート"に変換してる」ので「立ち上げてから解決する」という考えをしなかったのですが、なるほどそれが正しくスマートな気がします。

その後にアドレスで環境を分けたかったらWebサーバ側で、サーバ名で分けたかったらDDNSっぽく装備を付け加えれば良いのですね。

「Dockerコンテナビルド時間かかり」問題は、よくあると思うのですが「個々パーツとライフサイクルを整理したら分割出来ないかな?」と思いました。

お話を聞いていると「Dockerイメージとコンテナは同一サイクルで作り直し」を目指されている感じがしたのですが、それでは「立ち上げるのは一瞬」というDockerの利点が失われる気がしました。

性質\Docker物 イメージ コンテナ
含むモノ ディストリやミドルなどの”土台”系 自分たちが作ってるアプリケーション
変化するタイミング おおよそ日単位 秒単位
作成タイミング 日の固定時間(+スポットで任意) commit or pushタイミング(Jenkinsおまかせ)

とか出来れば、良いのかな…とか思ったのですが、おそらく「間違ってる」ので、素人の考えと思ってご容赦を…w

(懇親会でわかったのですが「ただDockerの勉強が足らんだけ」で「間違った苦労の仕方している」が多くあるようで…)

で、公開された資料を改て読み返すと、案の定「全面的に間違ってた」のですが…自戒として残しておきます。


なんとなく

「本番/ステージング"以外の"『リアルタイム(あるいは数日前とかタイミング限定)ソースが反映されて実際に動く』サーバ環境」

というのは、ヌーラボの事例でもありましたが「絶対に必要」と考えていまして、例えば…

  • (集合体作るモノ(Javaならwarなど)に)実際バイナリが作れるか
  • (ローカル端末とサーバが異なる場合)OS違い/ミドル違い/設定の違い、による挙動差異は無いか
  • 「今作りかけはこんな状態です」を他者に見せる場合の「誰の端末でもない」環境

というのを「ステージングリリース時にどんがらがっしゃんギャー!」やってる場合じゃないので…。

なので、ここんところ色々聞いてみたく思いました。

くっそー、はてな内を見学して実物見たいぜっ!(アカンヤツ)

2コマ目:S406教室 「JenkinsとSeleniumの活用事例:試験自動化のプロジェクトへの導入」近藤 剛(NTTコミュニケーションズ) さん

資料: (公開されたら)

まとめ: http://togetter.com/li/768883

※参加出来なかったセッションです。感想できません…が資料公開されれば何か何か書き足します。


所感(毎回つけるのかこれw)

「スタッフさんめっさ働いてた!」のが印象に残っています。

フロントの @ikkiko さんや、「(大阪から)手伝いにねw」って仰ってた玉川竜司(@tamagawa_ryuji)さん、あとブートキャンプで張り付きっぱなしだった玉川紘子さん、その他「青Jenkinsシャツ」の皆様…「この人らの頑張りで俺ら祭り参加できんねんなー」ということ思うと「有難うございますm(_ _)m」の言葉しか出ませんね。感謝です♪


以上、2コマ目までです…が、コレ終わらんかもなぁ?(三部構成になるかもです)

2015/01/10

勉強会行った002 - おいしがLinux勉強会 Linux Kernel2.6解読室

書くといったからには書くのだよ!!

…また、本読めてない状態で行ったし、gdgdだったけど(トホホw

情報

  • 申し込みサイト

    http://oishiga.connpass.com/event/10659/

  • 何するのか

    • 参加前に、予め「決められた本の範囲」を読み

    • GithubのWikiに疑問点書き

    • 当日は読み進めつつ疑問を議論しつつ範囲消化

    …なのだが「相当かっ飛ばして」進むのでよほど読んでないとついてけないw

  • 範囲

    第1、2、3、4、5、6、7、8章

なんで行ったの?

俺は、Linuxは大好きで、ずっと「ユーザーとして使い続けて」いる。

しかし、内部には全く踏み込まず、読んでも日経Linux程度…。

今回、この勉強会が @tokutaka さんにより開かれたのを契機に「カーネルとかもう少し内部に踏み込んでみよう」と考え、参加しました。

内容

序盤

本日は年始の週末だからか、キャンセル・遅参が多くあるようでした。

そんな中、最初に来てたメンバーで…

  • プロ・スキャンスナッパーが教える「高品質(文字列検索可能)ドキュメント」自炊入門
  • 20テラ以上! 高信頼自宅ストレージの構築と運用体験記
  • 人柱NexasにUbuntu Touch入れてみた(そしてカーネルパニクった)日記

というテーマでの講義を受けたので、俺にとっては「本編より値千金だった」というのはご愛嬌w

開始後

4人来たので「読んだトコで気になったトコ」を流しながら、ディスカッションをしました。

自分は「1章すらまともに読めてない」ので、聞き専に徹してメモをとってました。それがこちら↓

  • この本は「カーネルを読むための手引」な感じかも?
  • 15章くらいは面白そう
  • ubuntu.so がBSD上で動く話
  • プロセススケジューラとキューの話が面白い
  • わりと「想像可能」なシンプルな実装になっているな
  • NMI割り込みであってもマスク出来る(物理)の話
  • 実際参加者がみんなLinux端末を持ってる(一部BSD)だから実践出来ておもろい
  • Dockerから見える/proc/interupts は外と同じだった
  • 「時計」って言う概念は面白くタメになるかも
  • 5.3あたりが「セキュアな設計」の時に重要なとこですよね
  • システムコールを少ない手順でトレースまでもってけるのはLinuxの良いとこだなあ
  • 排他はいろんな概念を考案されたあとが伺えるな
  • スピンロックとシーケンスカウンタロックとRCUを上手く使って排他を実現している
  • 「出来る限りのシンプルなアルゴリズム、シンプルな名詞で書いたC」は、例えgotoあれどもコメント要らずなくらい読めるものなのかもしれない
  • ミウラの「Ubuntu14.10 on MBA」だけが「マスク不可割り込みNMIが800超え」とかww

…ちょっと自分用すぎましたね。

感じたこと

  • ソース読みも本文中では「わかる程度でそんなに深く切り込んでなく、良い所をチョイスしてる」ので、Cもアルゴリズムも読めない俺でも、時間をかければ読めるのではないか
  • 『タスクスケジューラのアイドルプロセス』『ブロックデバイス』『/proc』もそうだが、Linuxの哲学は「出来るだけ統一な土俵を作り、その枠組みになんでも”特別扱いせずよく似た形で”載せてる」ことが、シンプルかつメンテナンスフルに保てている理由なのではないだろうか

反省

「俺でも読めるかもしれない」という可能性を見たのに、「読んできていない」のは言語道断だなと。

次に向けて

次回は「今回分も含めて」ゆっくり計算して読んでいこう。


しっかし…懇親会の「秋吉」の焼き鳥が美味すぎて…終電逃しかけましたw

2015/01/08

勉強会行った001 - エッセンシャルスクラム読書会#7

何を急にやりだしたのか

年始「何か新しい事を始めよう」と思い、年末に「去年行った勉強会回数」をまとめたのもあって「何か残すか…」と、勉強会へ行った時に記録をすることにしました。

基本「ブログに定期的に書く」という週間がなく、かつ日本語が下手なのですが…ま、鍛錬も兼ねてということで。

だのに…

仕事で「最後の20分くらい」しか参加できなかった。

年始最初の勉強会からダメダメですね…。

情報

  • 申し込みサイト

    http://connpass.com/event/10871/

  • 何するのか

    • 参加前に、予め「決められた本の範囲」を読み
    • GithubのWikiに疑問点書き
    • 当日は読み進めつつ疑問を議論しつつ範囲消化
  • 範囲

    「第15章さまざまなレベルでのプランニング」と「第16章ポートフォリオプランニング」(P.243〜270)

内容

なんせ、最後の20分だけな上にメモも取らなかったので、言ってたっぽいことを箇条書きにします。

  • ポートフォリオプランニングのミーティングなどに開発者の身で…
  • ポートフォリオプランニングのミーティングは、スプリントほどでなくとも、年一とかでなくもっと短いスパンでやるのが望ましい
  • しかしポートフォリオプランニング・ミーティング時には「プロダクトごとの情報」「遅延コスト」の情報はよりリアルタイムに欲しいし用意しとくこと前提っぽい
  • でもそれは膨大な労力掛かりそう、世の中どうやってる?
  • スクラム(というかこの本)では一貫して「相対見積り」とかスクラムの原則の流儀でポートフォリオなど経営戦略までもすることを是としてる
  • これは「多くのプロダクトを自社で作ってる企業」前提であり「俗に言うSIer」では考えにくい…かも
  • 本当の「開発している企業」を仮定すると「人員の育てのためにこのプロダクトに人投入」とか「人材育成込でこのプロダクトに注力」なんていう「別の価値」「別お係数」が効力を持つ場合があるかもね

他にもっと深い話してたけれど…忘れた\(^o^)/

と、これだけだと

「何の成果も得られませんでした」なので、事前に今回の読書範囲を読んでいて思ったことを、メモっとくとします。

  • この章らへんは「わかることのほうが少ない」ので、わかるとこで使えそうなとこだけ実生活に生かそう
  • P.256の「表16.1 ポートフォリオのスケジューリングの原則」は、ポートフォリオのでっかいレベルでなく、タスクとか実生活レベルでも積極的に使っていける気がしてる
  • 「遅延コスト」については、スクラムプレイヤーとして開発してても事あるごとに思い出して算出しようとしよう

反省

とにもかくにも「開始時間に参加」すること!

(単位時間に学びをキッチリ得ないと、参加費、電車代、その時間のコストが勿体無い)

次に向けて

間に合うように仕事をブッチ!w


以上、自分の備忘録ですね…。。