日記です 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) など。
いろいろと初の試みもある中、運営の方々ありがとうございました。とても勉強になり楽しい会でした。
様子
あ、twitter id は @yoshi_hirano でしたね。明日 Shinjuku.go 参加しまーす
— 秒速284km(煌めき) (@284km) 2017年4月12日
今日は Aiming さんに来ています。新宿です。
— 秒速284km(煌めき) (@284km) 2017年4月13日
大阪と中継良いですね #shinjukugo
— 秒速284km(煌めき) (@284km) 2017年4月13日
Go でリアルタイムゲームサーバーを作っている話 #shinjukugo
— 秒速284km(煌めき) (@284km) 2017年4月13日
Go 以外にも API Server は Rails ですね #shinjukugo
— 秒速284km(煌めき) (@284km) 2017年4月13日
質問です。よろしくお願いします!https://t.co/fdjBMaTNTM#shinjukugo
— 秒速284km(煌めき) (@284km) 2017年4月13日
LT#2 - 犬でもできる!疑似生体SSH認証! · Issue #2 · shinjukugo/meetups https://t.co/77LVk6oWnc#umedago #shinjukugo
— Tamrin (@Tamrin007) 2017年4月13日
CM による瞬発的なリクエストの暴力。おそろしい #shinjukugo
— 秒速284km(煌めき) (@284km) 2017年4月13日
goパッケージで型情報を用いたソースコード検索を実現する #shinjukugo
— 秒速284km(煌めき) (@284km) 2017年4月13日
字句解析(go/scanner, go/token), 構文解析(go/parser, go/ast), 型チェック(go/types, go/constant) #shinjukugo
— 秒速284km(煌めき) (@284km) 2017年4月13日
コードの質はツールで保証。とても良い。 #shinjukugo
— 秒速284km(煌めき) (@284km) 2017年4月13日
東京のターン終了 #shinjukugo
— 秒速284km(煌めき) (@284km) 2017年4月13日
お疲れ様でした。運営の方々ありがとうございました! #shinjukugo
— 秒速284km(煌めき) (@284km) 2017年4月13日
個人の日記です。今日はプロジェクト固有の rubocop の整理など
雑に書いていくと言ったので、今日も書きます。今日は A3! のアプリに大半を捧げ(夏組クラスタ)、キンプリアプリの告知に歓喜したり、残った時間でプロジェクト固有の rubocop の整理として project_cop な名前の gem を書きました。public にしたい所でしたが、色々仕方なしに private から始めることにしました。
README にポエムを書いたのですが、簡単には、
- 会社で統一的な設定を用意すのは現時点では難しい(チーム固有の何かとかあるので)
- けれど適当な単位(チームだったり、他のなにかだったり)ごとに rubocop の設定を共有できる仕組みや、public に公開できる環境であったら今よりも良いとは思う
- 今現在、僕が一手でそこまで辿り着けそうな案がありません
- が、こういう雑な一手がそこに近づく為の足場になる可能性はあるかなということでとりあえず push した
というようなことを考えてやっていました。引き続きやっていきましょう。
その他
許可より謝罪はさ、おっさんが積極的に態度を示していかなきゃいかんよね。
— 秒速284km(煌めき) (@284km) 2017年4月8日
謝罪と言うけど、大体が平謝りすれば済むのだから。これやったら怒られるけど、ただ怒られればよいならそのメリット取る以外に選択ないよね。みたいな考え方をしてしまうので、一部の方々からはよくナメた態度という評価を頂いていました✩
— 秒速284km(煌めき) (@284km) 2017年4月8日
今は楽しいですよ
— 秒速284km(煌めき) (@284km) 2017年4月8日
4月だし書いていきましょう。表参道.rb #21 ~ バックグラウンド処理 ~
久しぶりに書いています。一回止まるともうダメですね。
4月だしというにはもう7日で中途半端ではありますが、これからまた雑に書いていきたいと思います。
自己紹介で、バックグラウンド処理でなに使っています。みたいに各自言ったりしていたのですが、その中では Sidekiq が多かったですね。僕もそうで、ジョブの実行とかには sidekiq-cron を使います。shoryuken を使われている方も多かったように見えました。SQS とあわせて知見ありがたかったです。バッチ処理のデバッグとかみんなどうしてるの?とか気になりますね。
自己紹介の中では Sidekiq を使ってる方が多い。DJ もありました。 #omotesandorb
— 秒速284km(煌めき) (@284km) 2017年4月6日
sansan さん、外の眺めがきれい
— 秒速284km(煌めき) (@284km) 2017年4月6日
懇親会のようすです pic.twitter.com/sOrzleatJN
— 秒速284km(煌めき) (@284km) 2017年4月6日
ActiveJob のリトライが、素で Sidekiq を使う場合に比べて弱いですがどうしてますか?みたいな疑問があったのですが、Rails5.1 ではその辺り改善されますよと教えてもらえたり、その後調べてみましたがこの p-r で入っていますね。
後は I18n 知見が得られたり、Rails のフロント談義が出来たりとても勉強になる会でした。ありがとうございました。
初めての人のためのLISP[増補改訂版]は僕には合わなかった
あまりネガティブなことは公開したくない性分で、ブログにまで書こうか悩んだんですが、それ以上に、自由に発言して良い場を自ら失いたくないという気持ちのほうが強くてまあ書いた。
以下は自分の場合こう感じたという率直な感想を言葉にしてみたものです。
初めての人のためのLISP[増補改訂版]は僕には合わなかった。理由は以下のツイートの内容です。 途中から拒否反応で動悸がしてきたので、日本語は途中からほぼ読まず、コード部分だけで確認したという前提での感想ですが、僕がおすすめしたいのは プログラミング Gauche です。
この本、駄目だ。僕には合わない。ストーリー仕立てなんだけど、人を馬鹿にしたような内容目にしたくない。読んでて辛い気持ちになる。昭和か。僕はこれより、入門者であってもプログラミングGaucheを全力でおすすめしたい。
— 秒速284km (@284km) 2017年2月18日
組織パターン メモ
組織パターン読了。ハイライト的なやつ。 もう少しまともなまとめを書きたい想いはあるものの、時間的にここまで。
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: 逃げる