日常

ケ・セラ・セラ

日記です Shinjuku.go #1 〜大阪と中継でつないでカジュアルトーク〜

Shinjuku.go #1 〜大阪と中継でつないでカジュアルトーク〜 に参加した。会場は Aiming さんです。

https://shinjukugo.connpass.com/event/52929/shinjukugo.connpass.com

大阪と中継、良いですね。お互いやってる感が伝わるのも良いですし、運営の @yoshi_hirano さんの進行が素晴らしくて雰囲気がとても良かったです。

その場で見られたこともあって東京勢の発表が印象的でした。ライブコーディングが多いというのも特徴でしたね。ライブコーディングやる人はすごい。勇者だと思います。

@shiwano さんによる “Go でリアルタイムゲームサーバーを作っている話” では、API サーバが Rails、マッチングサーバが Go という構成でした。実例を見せて頂けるのは大変参考になりありがたいです。

質問は Issue に書く形式で行いました。 ( LT#1 - Goでリアルタイム通信ゲームサーバーを作っている話 · Issue #1 · shinjukugo/meetups · GitHub )

@voidofglans さんによる 犬でもできる!疑似生体SSH認証! は何というか発想が凄くて、動画を UP してもらえました。 わんこ。 on Twitter: "デモの動画撮りました。 撮影 @tenntenn w #shinjukugo https://t.co/s7PwfT0Q1B"

@void_of_glans さんの goパッケージで型情報を用いたソースコード検索を実現する では、静的解析の話の中で、Go は package が充実しているなということを改めて思いました。字句解析(go/scanner, go/token), 構文解析(go/parser, go/ast), 型チェック(go/types, go/constant) など。

いろいろと初の試みもある中、運営の方々ありがとうございました。とても勉強になり楽しい会でした。

様子

個人の日記です。今日はプロジェクト固有の rubocop の整理など

雑に書いていくと言ったので、今日も書きます。今日は A3! のアプリに大半を捧げ(夏組クラスタ)、キンプリアプリの告知に歓喜したり、残った時間でプロジェクト固有の rubocop の整理として project_cop な名前の gem を書きました。public にしたい所でしたが、色々仕方なしに private から始めることにしました。

README にポエムを書いたのですが、簡単には、

  • 会社で統一的な設定を用意すのは現時点では難しい(チーム固有の何かとかあるので)
  • けれど適当な単位(チームだったり、他のなにかだったり)ごとに rubocop の設定を共有できる仕組みや、public に公開できる環境であったら今よりも良いとは思う
  • 今現在、僕が一手でそこまで辿り着けそうな案がありません
  • が、こういう雑な一手がそこに近づく為の足場になる可能性はあるかなということでとりあえず push した

というようなことを考えてやっていました。引き続きやっていきましょう。

www.a3-liber.jp

prism-rush.com

その他

4月だし書いていきましょう。表参道.rb #21 ~ バックグラウンド処理 ~

久しぶりに書いています。一回止まるともうダメですね。

4月だしというにはもう7日で中途半端ではありますが、これからまた雑に書いていきたいと思います。

omotesandorb.connpass.com

自己紹介で、バックグラウンド処理でなに使っています。みたいに各自言ったりしていたのですが、その中では Sidekiq が多かったですね。僕もそうで、ジョブの実行とかには sidekiq-cron を使います。shoryuken を使われている方も多かったように見えました。SQS とあわせて知見ありがたかったです。バッチ処理デバッグとかみんなどうしてるの?とか気になりますね。

ActiveJob のリトライが、素で Sidekiq を使う場合に比べて弱いですがどうしてますか?みたいな疑問があったのですが、Rails5.1 ではその辺り改善されますよと教えてもらえたり、その後調べてみましたがこの p-r で入っていますね。

Add retry_on/discard_on for better exception handling by dhh · Pull Request #25991 · rails/rails · GitHub

後は I18n 知見が得られたり、Rails のフロント談義が出来たりとても勉強になる会でした。ありがとうございました。

次回お題はデバッグかな?ActionMailer かな?何かな?デバッグは人によって違いそうなのでおもしろそうですね。

初めての人のためのLISP[増補改訂版]は僕には合わなかった

あまりネガティブなことは公開したくない性分で、ブログにまで書こうか悩んだんですが、それ以上に、自由に発言して良い場を自ら失いたくないという気持ちのほうが強くてまあ書いた。

以下は自分の場合こう感じたという率直な感想を言葉にしてみたものです。

初めての人のためのLISP[増補改訂版]は僕には合わなかった。理由は以下のツイートの内容です。 途中から拒否反応で動悸がしてきたので、日本語は途中からほぼ読まず、コード部分だけで確認したという前提での感想ですが、僕がおすすめしたいのは プログラミング Gauche です。

組織パターン メモ

組織パターン読了。ハイライト的なやつ。 もう少しまともなまとめを書きたい想いはあるものの、時間的にここまで。

p4 パターンとは何か?

p7 パターン言語とは何か?

p29 本書を使うべき人

p115 トラックナンバーとは、他の人が知らない重要なドメインの専門知識を有する人の数

p118 ソロ バイオリニスト システム全体の設計と実装を、最も生産性の高い開発者一人か二人で行おう

p146 人気者の興味深い一形態が、道化師、別名賢い愚者だ。 p147 人気者は本質的に非公式だ。

p149 婦長がいれば、チームはよいときも悪いときも結束できる。 婦長は調停者のもっと広いバージョンで、婦長は通常、人気者である。 追記しておくと、このロールを誰かに押し付けてはならない。生まれついての婦長もいれば、そうでない人もいるのだ。それゆえ、仕立てるのではなく、見つける必要がある。

p154 偉人ロール

p166 うまくいっているプロジェクトというものは、成功に導くようなふるまいに報酬を与えることでうまくいき続けている。

p195 よほどのことがない限り、ロールを演じている人はプロジェクトのリリースまではそのままにしよう。ロールを混乱させるような事態が起きたときに、それに対処するという一時的なタスクを持ち上げるのはやめよう。 混乱が生じたときに、それに対処する新しいロールを作らないことがコツだ。混乱への対処、特に危機への対処にはある種のステータスがつきまとう。もしロールを作ってしまうと、そのロールのふるまいが定義され、結果として、混乱が生じることを奨励することになってしまう。それよりも “生産者” を育てることに集中しよう。

p198,199 ビジネス構造は組織構造を構築するうえで重要な考慮点だ。ビジネス構造のほとんどは、アーキテクチャの中にはっきりと表現される。したがって、コンウェイの法則は、分割統治を支える重要なパターンなのだ。 もし、サブ組織を形成する際に中心となれる中核的なロールがなければ、その組織を区切ることはできないだろう。

p213 コミュニケーションが自然に発生することは期待できない。さらに言えば、任意の社会構造の中で、特定のコミュニケーションが自然と構成されることはまったく期待できないのだ。 それゆえ: 組織内や作業場の中に、コミュニケーションのつながりを推奨するような場所を作ろう。そうしたつながりが他のパターンを養うのだ。 “組織は拠点配置に従う”

p266, 267 最初は、ソロ バイオリニストから始まり、人が増えていくこともある。… チームのオープンクローズドの原則 … 開発者リーダーがあるプロジェクトでソロ バイオリニストのロールを演じていた場合、そのふるまいをやめるのは難しいこともある。

p308 6.2 漸進的成長 一度に一つずつパターンを適用し始めるのだ。 形式主義再現性

p315 組織パターンは処方箋ではなくインスピレーション 組織のコンテキスト次第

p316 組織パターンは個人ではなくグループで使う

SCRUM BOOT CAMP THE BOOK メモ

Scrum はフレームワーク

Scrum はアジャイル開発手法のひとつ

プロダクトバックログ

p24 プロダクトオーナー

スプリント期間は固定する

Scrum ではロールの兼任は禁止されていない p53 でも兼任すべきじゃないこともある。

スプリント毎に終わらせられるポイント数はベロシティと呼ばれる。 ベロシティは決めるものではなくて測るもの。

タイムボックスを守る。制限時間内に終わらなかったものは次のタイムボックスに回すだけ。期限が来ればその作業は中断し、次のスプリントで再びやるかどうかから考え直す。

プロダクトバックログの項目の並び順はすぐに入れ替え出来るようにしておこう。たとえばこの項目は大きくて今回は終わらせられないのでその下の小さい項目をやってもいいですか?で入れ替えができるぐらいの順序でよい。

実はプロダクトバックログは空っぽにはならない。プロジェクトが終わるか続くかは別として、少しでも良くしていこうとするのが Scram の原動力。もし誰も追記しなくなったらそれは良くない兆候。

p163 デイリースクラム

安定していないベロシティは予測には使えない。

p244 鶏と豚の例え話

本来はリリーススプリントがなくてもいいようにしていく

p276 理解を深めるために読んでほしい文献

p277 ボクくんが気づいた大切なこと

Team Geek メモ

Team Geek

以下は印象に残ったあたりのメモ。

  • p8 隠したらダメになる

  • p15 三本柱 (HRT, heart, not hurt)

    • 謙虚 (Humility)
    • 尊敬 (Respect)
    • 信頼 (Trust)
  • p18 人間関係は確実にプロジェクトよりプロジェクトより長続きするものである。

  • p19 組織を自分の仕事に使うことを学べば、組織を自分の要求に合わせられるようになる。そうしなければ、宣戦布告なしの小さな戦争を人生をかけて日々戦うことになるだろう。

  • p23 過ちから学ぶには、失敗を文書化することである。我々の業界では、「ポストモーテム」を書くという。適切なポストモーテムには、学習した結果として何を学んだかと何を変更するかを記述する。書き終わったら見つけやすい場所に置いて、変更を継続できるようにする。

  • p24 優れたポストモーテムには以下のことが含まれる。

    • 概要
    • イベントのタイムライン (調査開始から解決に至るまで)
    • イベントの根本原因
    • 影響と損害の評価
    • すぐに問題を解決するための行動一式
    • 再発を防止するための行動一式
    • 学習した教訓
  • p35 自己選択的な文化

  • p71 アンチパターン: パフォーマンスの低い人を無視する

  • p73 アンチパターン: 人間の問題を無視する

  • p74 アンチパターン: みんなの友達になる

  • p74 アンチパターン: 採用を妥協する

  • p87 幸せを追い求める 「何か必要なものはある?」 ここで重要なのは、暗黙的な目標を明確化することである。

  • p99 チームの文化に含めないことについても議論すべきである。効率的で動きの早いチームを目指しているのであれば、やりたくないことも明確にしておいたほうがいい。

  • p145 プランB: 逃げる