年末総会から社員旅行

社員総会はセルリアンの広いホールですごい感じだった!スペシャルゲストの蝶野選手は、男子には一度はあるというプロレス期の頃ちょうど活躍していたので結構テンションがあがった!

社員旅行では、1次会はいろんな企画があったり、すごい商品のビンゴ大会があったりしたけど、自分のビンゴ運はいつも通りだった。(途中までは1つもビンゴが開かないという…)

2次会からはエンジニアっぽい集りに顔を出したり、気付いたら4時くらいで眠くなったの一休みした。

二日目のカレー対決は、P山さんとくまき君の活躍によりビジュアルもすばらしいものが出来たけど予選通過できずに残念だった。

というわけで、今年はペパボ1年目でいろいろありましたが、来年もよろしくおねがいします!

クリスマスイブ

前日から体調を崩してしまい、ほぼ一日寝てたら御飯ができていました。

ありがとうありがとう。

猫の予防接種2匹目

無事終了。

今年はめずらしく2匹とも体調を崩さなかった気がする。よいことじゃー。

知識ゼロから学ぶソフトウェアテストを読んだ

タイトルの通りソフトウェアテストを体系的に学ぶための入り口の一冊として良い本でした。

完璧ではなくとも十分な品質を持つソフトウェア製品を開発するため

とあるように、ソフトウェアテストの理論と現実の間でどう考えてバランスを取とるのか、読者が考えるためのヒントや材料が沢山提示されています。

一番ハッとさせられたのは、筆者が指導教官のCem Kanerに言われたという「何度も繰り返すって、あんまり意味ないんだよね……」という言葉。ChekingとTesting、開発を駆動するテスト、という最近の興味のポイントに刺さってきて考えさせられました。

全編を通して、アカデミックな参考文献を提示しつつ筆者の経験をふまえた現実的な方向を示すというバランスの良さと、適度にくだけた文体で最後まで楽しく読めました。

データセンターの見学ツアーに行ってきた

せっかくホスティングをやってる会社にいるので データセンター見てみたいなーと思っていたところに、見学ツアーのお知らせが来たので行ってきた。

どこまで書いていいかわからんので内容は伏せますが、物理的なConoHaちゃんがラックに並んでいる様子や、これからConoHaちゃんになるであろう予備機が無造作に置かれている様子を見れたのでまた明日からがんばれそうです。

猫の予防接種一匹目

猫の予防接種に、徒歩20分くらいのいつもの動物病院まで行ってきた。

去年から息子がついてくるようになったんだけど、昨年は何も持っていかなくて待ち時間の相手をするのが大変だったので、今年は本や折り紙を持っていかせたらそれなりに時間をつぶせたのでよかった。

今日つれていったほうは御飯のあとにたまに吐いちゃうのでその相談を何度かしているんだけど、猫は毛玉吐くのと一緒で上手に吐くので、ごはんたべてすぐ1回とかだったら大丈夫とのこと。連続だったり、そのあと食欲がないみたいなのは連れてきてねという感じだった。

来週もう1匹を連れていって今年も終わり。(丁度寝てたから写真撮ろうと近づいたら起きて盛り上ってきてしまったので一回休み)

奥さんの誕生日(前日)だったので新宿まで行ってきた

img_20141207_174202

奥さんの誕生日(の前日)だったので、京王プラザホテルのディナーブッフェに行ってきた。

お昼は秋葉原で牛かつを食べようかという話だったんだけど、長蛇の列であきらめてラーメン、その後は都庁の展望フロアにのぼったり、新宿中央公園で息子を放牧したりしていた。

ブッフェはフォアグラ食べ放題を目的に行ったんだけど、当然そんな大量に食べられるわけもなく…もう若くない。

メニューはだいたいリンクにある通りなんだけど、1.5時間でドリンクはお願いするタイプだから飲み放題は今一な印象。奥さんはビールもワインも飲めないので、無限紅茶(とコーヒー)で料理をいただいていた。

私のWishlistの中には奥さんの希望のものも入っているので一応おいておきますね。

散髪ログ

前回から約3ヶ月だった。だいぶのびてたのでいつも通りばっさりと。

Amethystっていうタイル型ウィンドウマネージャが結構いけてる

これは、Pepabo Advent Calender 2014の2日目のエントリです。

1日目は鹿くんのインターネット詩ガイドでした。3日目はまだ決まっていないようです。

まとめ

2014年の年末時点では、Macのタイル型ウィンドウマネージャはAmethystがよさそう。

タイル型ウィンドウマネージャとは

皆さんはどのようなウィンドウマネージャをお使いでしょうか?私は数年前にタイル型ウィンドウマネージャというものを知り、Awesomeに出会ってからはずっとそれを使っておりました。

ウィンドウマネージャには大きくわけて3種類があり…という説明はWikipediaにおまかせするとして、まずはなぜタイル型ウィンドウマネージャがよいのかというところからお話させていただきます。

なぜタイル型なのか

ウィンドウをきっちり配置するために、何度もウィンドウの大きさを変えたり、配置を入れ替えたり、その度に数ピクセルの隙間やずれが気になってマウスやトラックパッドに手が行ってしまう私のような人は、タイル型ウィンドウマネージャを使うと幸せになれるかもしれません。

私は、こんなかんじで開発をしています。

  • フルスクリーンのエディタやIDEでコードを書いている
  • フルスクリーンのブラウザで調べものをしたりしている
  • 画面半分のブラウザと、もう半分のターミナル or エディタでデバッグしている
  • ブラウザ、ターミナル、チャットをいいかんじに3分割して表示する

これらの配置は長時間固定されるようなものではなく、サッと切りかえたり、また戻したりというのを簡単にできないといけません。

このような使い方をしている人に、タイル型ウィンドウマネージャはとても有用です。

デモ

都合上、1画面のGIFアニメですが、もちろん外部ディスプレイを繋いでのウィンドウやフォーカスの移動も簡単にできます。

Amethyst

おすすめの設定

できることやキーバインドはREADMEに載っているので割愛しますが、mouse-follows-focusforcus-follows-mouseは設定しておくのがお勧めです。キーボードでアクティブなパネルを切りかえたときにマウスカーソルがくっついてくるのと、逆にマウスカーソルにアクティブなパネルがくっついてきます。

mod1とmod2はデフォルトだと結構複雑なコンビネーションなので、私がMacのOptionキーを使いこなせていないのもあり、optionを潰してしまっています。

また、floatingの中にはタイルに並べないアプリの識別子を書いておくと、ウィンドウのサイズに依存するアプリとかが不用意に小さくなってしまうのを防げます。

{
  "mod1": [
    "option"
  ],
  "mod2": [
    "option",
    "shift"
  ],
  "mouse-follows-focus": true,
  "focus-follows-mouse": true,
  "floating": [
    "com.apple.systempreferences",
    ...
    "com.cockos.LICEcap"
  ],
}

不満

作者が対応しないと言いきってしまっているのでどうしようもないのですが、AwesomeでいうFloating & Full Screen がないのがちょっとだけ困っています。

たとえば、左にブラウザ、右にターミナルとエディタを縦に、みたいな配置をしているときに、一瞬だけエディタだけを最大化してまたすぐ戻したいというケースが結構あります。

このときに非常に便利な機能だったのですがAmethystには追加されなさそうです。

あとは、このように綺麗に並ぶとウィンドウの影が邪魔ですよね。Yosemiteに期待しています。(諸々の事情でアップグレードできていないのです)

おわりに

なんとなくいいかんじにウィンドウを並べたい人や、毎日せっせとウィンドウをいいかんじにリサイズしている人にはタイル型ウィンドウマネージャがおすすめです。

Linuxでは沢山の選択肢がありますが、Macでは私がしっくりきたのはAmethystだけでした。ただ、他にも同じようなアプリは沢山あるので、興味がある方はぜひお試しください。

こんな人が働いているGMOペパボの新卒採用サイトがオープンしたようです。中の人もびっくりのクオリティだったので是非ご覧ください。

イテレーティブかつインクリメンタルな開発プロセスについて社内で話した

先週あたりから、ずっとお手伝いしているプロジェクトメンバーに迷いというか悩みというか不安というかが出てきたので、それを払拭するための方向付けプレゼンをした。

伝えたかったことはだいたい3つくらいあって

  • 少しずつ作るってのは、行き当たりばったりに作るわけではないよ。というPO側へのアピール
  • どでかい構想だとしても、分解してインクリメンタルに作れる例を示して、開発チームの不安を解消する
  • 今すぐできないことも、プロジェクトを通して学習していくことでできるようになる。と思い続けて実践して自信をつけてもらう

ということを、ちゃんと全員が揃う場でもう一度(といってもこれまではここまではっきりとは言わなかった気がする)合意して、不安なく一歩一歩進んでいける状態に持っていきたかったのであった。

社外秘をばっさり削った資料ですが、一応置いておきますね。

インフルエンザの予防接種

どうやら当たりの先生をひいたらしく全然痛くなかったけど、注射のあとはなんとなく気分がすぐれないのでぽよんとしていた。

予防接種なんて何年ぶりだろうというかんじで意識の低い社会人で、実際に数年前は家族でインフルエンザにかかったりしていたので、今年は元気ですごせるといいな。

ペパボっぽいkeynoteのテーマ

RubyKaigiのLTがペパボに来てから初めての発表だったんだけど、そのときに作ったKeynoteのテーマを公開していたのだった。

kenchan / keynote-theme

ポイントとしては、

  • Azusaを参考に3色
  • 3色をペパボのサイトからカラーピッカーで拾ってきている
  • 前から使っているお気に入りの「引用」スライドを入れている

というくらい。さすがデザイナーさんが選んだ配色だけあって、それっぽく見えるのでおすすめです。

ペパボ after school で AEP について話した

ペパボ after school っていうLT大会があるとのことで、せっかくなので見積りと計画づくりについてLTをしてきた。

資料は置いておくけど、だいぶ雑な感じなのでつっこみはおてやわらかに……

ちなみに、脈略のない写真がはさまっているのは、いきなり最初の人がブロッコリーについての話をはじめたので、真面目トーンだとだめか!とあわてて入れたでこんなかんじになっている。

各プロジェクトで、見積りや計画づくりをするときのヒントになればよいなーと思っております。

PreforkサーバでOctopusを使うときのDBコネクション管理

unicornに代表されるprefork(する)サーバでは、DBへのコネクションのような各プロセスで共有してはいけないリソースをbefore_forkafter_forkで適切に管理する必要がある。

ふつうのRails Applicationは以下のように、ARのコネクションをはりなおしていると思う。

before_fork do |server, worker|
  ActiveRecord::Base.connection.disconnect!
end

after_fork do |server, worker|
  ActiveRecord::Base.establish_connection
end

しかし、Octopusを使っている場合はこれだけでは不十分で、このままだと再起動直後にエラーが大量に出ることになる。今関わっているプロジェクトではNoMethodError: undefined method 'query' for nil:NilClassというかんじで、ARの@connectionがnilになるという問題が多発していた。

Octopusのissue#59では

after_fork do |server, worker|
  ActiveRecord::Base.connection_proxy.instance_variable_get(:@shards).each {|k,v| v.clear_reloadable_connections! }
end

というかんじでafter_forkでだけclear_reloadable_connections!というメソッドを呼べばいいよ、ということになっていた。

  • ActiveRecord::Base.connection、またはconnection_proxyは、OctopusのConnectionProxyに置き換えられている
  • これの持っている@shardsというインスタンス変数に、すべてのAR::ConnectionPoolがはいっている
    • シャーディングしている場合は対象の接続すべて、レプリケーションの場合は masterとslaveの接続全て
  • clear_reloadable_connections!は、ARのメソッドでだいぶ便利メソッドっぽい

というかんじである。

で、実際はこれだけでも例外はでなくなったのだが、再起動が異様にもっさりするようになったので

before_fork do |server, worker|
  ActiveRecord::Base.connection_proxy.instance_variable_get(:@shards).each  do |_, c|
    c.disconnect!
  end
end

というかんじでbefore_forkでdisconnectはするようにして様子を見ている。(これだとストレスがなかった)

おまけ

Octopusの動作を完璧に理解するには、沢山のスパイクをしたり、ソースコードを読みまくらないといけない。(つらい)

みんながそんなことをしなくてもいいとは思うので、よくある問題の一つである「意図しているDBにクエリが飛んでいない」というのをデバッグするために、DBの接続先を判断している部分のポインタを置いておく。 原因がよくわからないときは、最小の再現コードを書いてこの部分にbinding.pryして動きを追ったりしている。

https://github.com/tchandy/octopus/blob/ce55a0d931fcd0698f64357a656984981e6b3f6c/lib/octopus/proxy.rb#L260

    def method_missing(method, *args, &block)
      binding.pry # ココをひっかける
      if should_clean_connection_proxy?(method)
        conn = select_connection
        self.last_current_shard = current_shard
        clean_connection_proxy
        conn.send(method, *args, &block)
      elsif should_send_queries_to_shard_slave_group?(method)
        send_queries_to_shard_slave_group(method, *args, &block)
      elsif should_send_queries_to_slave_group?(method)
        send_queries_to_slave_group(method, *args, &block)
      elsif should_send_queries_to_replicated_databases?(method)
        send_queries_to_selected_slave(method, *args, &block)
      else
        select_connection.send(method, *args, &block)
      end
    end

なんと、Octopusは実際にクエリ投げるメソッドを横取りするためにmethod_missingを使っている。だいたいのSQLの実行はここを通るので、ここをひっかけるのが一番楽だと思う。

逆にここにひっかからない場合は、Octopusが独自に実装している何らかのメソッドを経由しているのでそれはそれで調査が捗る。

このif-elseの条件のどこにはいって、その先のDB接続先の判定をするメソッドがどう振る舞うかを見ると、「あーなるほどね」となることがけっこうある。

複数DBとの戦いの記録 で見つけたラウンドロビンに関する意図しない挙動も、これで見つけたのであった。

今夜の 複数DB Casual Talks 、盛り上げてこ!!1

WEB+DB PRESS Vol.83

WEB+DB PRESS Vol.83を一通り読んでみた。

Zshの特集とRubyのアプリケーションサーバの選択が身近で勉強になったのと、画像認識とWebP、負荷テストの話は長い目で勉強したいトピックなのであとでゆっくり読み直そうかなという感じ。

特集1のチームの話は目新しい話はそれほどなかったけど、多能工星取表とI messageのところがよかった。

最近のチームビルディングでは、毎回ドラッカー風エクササイズをやっているんだけど、それに近い話ではあるけど、より具体的にメンバーのスキルが把握できて、かつ勉強したいポイントがわかるというのはよさそう。

I messageは、本書の中でもあるようにまどろっこしい所があるので、実際に使うというよりはネガティブなフィードバックをする前に、一度おちつくためのツールくらいで使うのがよさそう。

今号もすぐに使える物から、末永く使える基礎的なトピックまで勉強になりました。

試用期間が終わった

(11/8に公開しました)

無事3ヶ月の試用期間が終わり、正式採用となりました。

そんなこともあり、今日はあんちぽさんと最近どうっすかのお話をしたりしたのでした。

先月くらいからは、大きめの新規開発の立ち上げを支援を中心に、昔取った杵柄を活用して原因がわかりにくいバグの修正とか、革新的ソフトウェアのアイデアが振ってくるのを待っていたりしてる。

新規プロジェクトの立ち上げ支援

リーンキャンバスの作成、見積りと計画作りに口を出しながら、チームビルディングの支援や、アーキテクチャを一緒に考える、ふりかえりやディスカッションのファシリテート、というあたりをやっています。

今までは1参加者としてやっていたのを一歩引いてやるってのは思ってた以上に大変ですね。

コードをばりばり書いて問題を解決するって感じではないのだけど、今までの経験を生かして、開発チームが自信を持ってリリースできるように支援しております。

これはあとでちゃんとまとめたいな。

複数DB案件

上記の新規プロジェクトに関連している既存のアプリケーションで、Octopusを使ってレプリケーションに対応しているものがある。

このアプリケーションに、パフォーマンスの問題があったり複数DBに関連するバグがあったりするのでこれを直したりしている。

ここは、完全に某プロジェクトでOctopusをプロダクション投入するために色々調べた経験が生きて、Octopusの影響がありそうなところ潜って原因となるメソッドを特定して、ドメインの知識を他の人に補完してもらって直す、みたいな感じで進めている。

imlib2からImageMagickへの移行

imlib2は高速で省エネなんだけど、画質という観点からはおせじにも褒められたものではないので、パフォーマンスを落さずにImageMagickに移行できないかと挑戦している。

おかげで、ImageMagickのオプションにはだいぶ詳しくなったし、本番に出してからサーバのロードアベレージが急上昇してすぐRevertするという通過儀礼を受けた。

そういえば、前職でもMySQLのクエリがいけてなくて辛い思いをしたのを思いだした。

インフラとか

サーバのプロビジョニングとかは、今までせいぜいローカルのVMを作るとか、借りてるVPSで遊んだりしていただけだったので、始めて本番サーバまで含めたサーバの運用というのを間近に感じられている。

自分にとては未知の分野だし、さらにホスティングをやっているという会社ということもあって、インフラエンジニアの教科書に載っているようなことを実際にやっている同僚がいるすごく刺激的な環境だと思う。

まとめ

AEP読書会に参加

AEP読書会 - 第十五章「イテレーションの長さを決める」に参加して15章のまとめを発表してきた。

資料はこちら AEP読書会:15章「イテレーションの流さを決める」

いい議論がたくさんあったんだけど、いかんせん乾杯からスタートなので殆ど覚えていないのであった。(用語がブレているのは御愛嬌)

  • 営業日ベースでイテレーションの長さを決めてる人いない?
    • 休日や長期休暇の影響を受けないけど、リズムが作りにくいかもね
    • いいとか悪いとかじゃなくて、やってる人がいたら話きいてみたい
    • 製造業(?)でそういうところあったよ
  • PO忙しすぎ問題どうしてる?
    • 代理がいれば代理をたててもらう
    • どうしても代理が立てられなければ、スクラムイベントの日程をずらしている
      • イテレーションの長さを変えるというよりは、次のスプリントの前借りをするかんじ
  • イテレーションの中でもやることを変えてもいいよね?
    • タスクAをA'にするようなのはどんどんやればいい
    • ストーリーのレベルでひっくりかえるなら、それはスプリントの中止だよね
  • イテレーションのオーバーヘッドは、プランニングのように固定で必ずかかるものも入っているから0にはできないよね
  • nイテレーションに1回、短い学習や負債返済のイテレーション入れるのいいね
    • 長期休暇前後のメンバーがそろわないときにそういうのやってるよ
  • イテレーションの計画でバッファってつんでる?
    • 1イテレーション10PTって言ってるけど、コミットメントは8PTにしておく。みたいなやつ
    • ベロシティが絶対ではないという前提が浸透していれば、バッファを積む必要はない
    • リリース前にバッファのイテレーションを置いておく、みたいなのはしておいたほうがいい
    • つまり、リリース計画にバッファもつ
  • 参加者だと、1-3週間で1イテレーションの人がほとんど
  • ハードがからんだりすると、デモまで考えると4weekイテレーションとかありそう
    • その場合でも、2weekで開発チームは一区切りってしたほうがリズムがでるかもね

こんなかんじで、どんどん突っ込みや、自分たちはこうしてる、みたいなのが議論されながらすすんでいくので、雰囲気があう人はすごくたのしい読書会だと思うし、だいぶ勉強になると思う。

次回は忘年会の季節では?という感じなのでまた参加しよう。

ひさいちくんのコードレビューのいい話を聞いた、それとポエム

新人向け座学で、ひさいちくんがコードレビューの話をするとのことだったので隣で聞いていた。

資料はこちら > コードレビューの話 by hisaichi5518

言語化しにくいところがよく言語化されていて勉強になりました。

終わってからの、hsbtはどうやってんの?という話が興味深かった。(だいたいこんな話だったと思う)

  • (OSSとかでは特に)レビュアーとレビュイーの(文化的な)コンテキストの違いに気をつけている
    • いきなりLGTM画像とか使わない
    • 半角の顔文字 :-) こういうやつはニュートラルだからおすすめ
    • Githubの絵文字はだいたい大丈夫
  • 何をレビューすることを期待されているかを確認してそれに集中している
    • たとえば、Rubyっぽいかどうかを期待されているなら、タイポは無視する。
    • 一通り見てから、タイポ多いから他の人に見てもらったほうがいいとアドバイスする

ふむふむーたしかに大事だなーと思って聞いていた。

で、不意にこっちにも振られたので、最初は「これ以上はとくにないっす」と答えたんだけど、考えなおして最後に言わせてもらったのは

  • 始めてレビューする人は、バックグラウンドや過去のレビューを調べてからコメントする
    • 他の人がその人にどういうレビューをしていて、それに対してどういう反応をしているかを知ると無駄な衝突を避けられる
  • 同様に、つらいレビューを受けても反発したり落ち込むんじゃなくて、相手のバックグランドや他のレビューを見てみる
    • 自分のことが嫌いでそういう振舞いをしているわけではないという確認

これは、特に転職してすごく思ったんですよね。(昔は各所にご迷惑かけたかと思いますが…)

ひさいちくんのスライドにもあるように、文字ベースのコミュニケーションでは感情の表現が欠落してしまうので、お互いが余計なダメージを受けないように、各自自衛しないといけないと思うのですよ。

とはいえ、やっぱり意識高い状態じゃないとそういう配慮や意識もできないので、まずは意識を高めてがんばろうということになってしまうんだけど、最低限、レビュアーとレビュイーは対等であり、そのコメントやコードの向こうには血の通った人間がいるのだ(そしてその人は仲間である)、ということを忘れなければなんとかなると思う。

HRT大事!みたいなポエムになってきたのでここで終わり。

複数DBとの戦いの記録

Rails 複数DB Casual Talks が一瞬で定員になるほど世の中は複数DBの知見に飢えているようなのですが、登壇を若者にまかせることができてよかったと思っていたのも束の間、お仕事では複数DBではまっていた。

ようやく問題の一つを解決できたので共有しておきますぞ。

Octopusには複数のslaveをラウンドロビンで使う機能があるんだけど、これがちょっと理解できない挙動をしていて

Octopus.using(slave_group: :my_slave_group) do
  User.count # my_slave_groupのslaveに行く
  User.count # masterに行く!!1?
end

というかんじで、2つ目以降のクエリがmasterのDBに行ってしまうのであった…

さすがにこれは多くの人が期待する動きではないと思うんのでうまいこと直したいなぁ。だいたいの原因はわかってるんだけど、どう修正したもんかなーという気持ち。

とりあえずすぐ再現させられるので、我こそはという人は直してくれるとすごく嬉しいです!

カメラのお掃除道具を購入

ミラーレス一眼買ったはいいけど、ほぼ本体だけ買った状態だったのでいろいろ調べたり、有識者に意見を頂いて、メンテナンス道具を購入した。

買ったのは

  • レンズプロテクタ
  • レンズペン
  • ブロワー

の3種類で、とりあえずこれだけあればいいよって感じみたい。

液晶保護フィルム撲滅運動をやっている自分としては、レンズプロテクタの意味についてかなり懐疑的ではあったんだけど、一番外側のレンズのコーティングを保護するというのと、掃除が楽になるというところで納得して購入したのであった。(有識者の皆さんありがとうございました)

で、本体以外もいろいろ買うものがあるのでだいたい5,000円くらいは余分に見ておいたほうがいいなぁというのが感想です。

運動会当日

朝から場所とりをしたり、写真をとったり、長縄の縄を回したりしていた。

肝心の写真の方は、一番肝心な「かけっこ」の写真はほぼブレていて、社会の厳しさを感じた。

正面から向かってくる被写体を撮るの難しいです…

年長さんの競技を練習台にいろいろ撮ったので、たぶん来年はいけるはず!

一日の中でも少しずつは上達したような気がするのでよかった。

ひどい写真を忘れないようにインターネットに置いておこうかと思ったんだけど、後ろの方の人に完全にピントがあってしまっているので心の中だけにしまっておきます。

ミラーレス一眼を買った

息子の運動会前日にミラーレス一眼を衝動買い的に購入した。

奥さんからビデオか一眼買おうかーという話がふってきて、どっちかだったら一眼かなーということで、インターネット上の有識者から意見を頂戴して、店舗でいろいろ触ってみた結果E-PL6のダブルズームキットを購入した。

店員の人とだいぶお話したり、運動会向けのレクチャーもしてもらったので、だいぶ割高ではあるけどちゃんと店舗で買ったのであった。

家に帰ってから猫をとって練習したけど、動く物体を撮るむずかしさを再認識している…明日は試練だ…

エッセンシャルスクラムセミナーに参加

(これを書いているのは10/20です)

VOYAGEさんで開催されたエッセンシャルスクラムセミナーに参加してきた。

今までのポジションとしては、スクラムってかなりかっちりとしたフレームワークだし、あの通りにやるのはかなりしんどいのでかなり距離を置いていたんですよね。

ただ、現職はわりとスクラム押しだし、エッセンシャルスクラムを読んでいるうちに見方がだいぶかわってきたので、そろそろ有識者と話をするといろいろ捗りそうと思ったので、タイミングとしては完璧だった。

エッセンシャルスクラムの一つのポイントは、マネージャについて書かれているという所なので、この辺を角さんや参加者の方と話せたのはよかった。

主に気になっていたのは、POとマネージャと、組織的な役割をどう考えればいいのかというところで、ここは角さんにかなりヒントを貰えたような気がする。

懇親会が終わってからは、たまたま別件でAJITOに来ていた大学の同僚と数年ぶりの再開を果して、いろいろ話をしていたら終電近くなったので帰ったのでした。

会場や懇親会の料理、飲み物を提供いただいた各社さんありがとうございました。

台風からのグループ全体ミーティング

VPNの申請をしてきたから在宅でもよゆーだぜーと思っていたら、イントラでやっておかないといけない手順があったらしく、繋がらないのでインターネットでできることをしていた。

息子も、たまたま幼稚園が代休だったので、家でだらだらしながら、偶に話しかけられるのを生返事しながら仕事をするのはなかなか大変である。

午後から出社して設定をして、帰って確認したらちゃんと繋がったので次からは大丈夫なはず。

夕方からはグループの全体ミーティングがあって、今までにない体験でこれはこれで楽しかった。

公園で息子と走る練習をするつもりだった

運動会の練習を見てきた奥さんから、息子の走りかたがひどすぎるからなんとかしろと言われたので、散歩ついでに練習でもしようかと公園に付いたところで、滑り台に走っていった息子は数歩目で転んで膝を思いっきり擦剥いた。

練習どころではなかったので、とりあえず水であらって絆創膏を買いにいって、涙目すぎたのでおやつを食べたり本屋にいったりして気をまぎらわして一日がおわった。