日常

ケ・セラ・セラ

日記です。渋谷.rb[:20170419]

.rb

渋谷.rb[:20170419] に行きました。会場はピクスタさんです。

shibuyarb.doorkeeper.jp

発表を聞いたり、終わっていない諸々を片付けたりした後は、mastodon と向き合って過ごしました。

tweet しつつ読んでいたところ、後半は tyabe さん、kaiba さんとそれぞれ気になるところを緩く談話しつつやっていました。良く知らないものを読んでいく作業を複数人でやると、一人でやっているよりも情報交換しながら進める分効率が良いですね。コードから入って得た学びとしては、WebFinger protocol, OStatus API, Salmon protocol 辺りを認知したことでしょうか。これらは日常生活では意識することが無かったですし。

github.com

あとは、Ruby や Rails や Git や黒い画面のことや。人に教えるやり方について色々と話したり。4月っぽい話題もあっておもしろかったですね。

当日の様子です。

日記です。猫様に MacBook Pro Touch Bar を通って頂きました

diary touchbar

今日は Touch Bar や Swift と自分にしては珍しいものに触れました。

同僚の Touch Bar は指紋認証以外いいことが無いという発言に完全同意でしたが、ふと猫様が歩いていたらそうでもないのではと思い、それと Swift に久しぶりに触れてみるのも良いかなという気持ちからスタートです。

Swift を書くのはおそらく 2 年(以上)ぶりでまったく全て忘れたような状態で始めて、インターネットの情報を頼りに 20 分程でできました。その前に 20 分ほど xcode の準備をしていたので全部で 40 分ほどです。

こんな様子です

今日はここまで。

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

diary

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 の整理など

diary

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

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

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

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

www.a3-liber.jp

prism-rush.com

その他

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

omotesandorb .rb

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

４月だしというにはもう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[増補改訂版]は僕には合わなかった

book

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

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

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

組織パターン メモ

book

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

p4 パターンとは何か？

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

p29 本書を使うべき人

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

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

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

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

p154 偉人ロール

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

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

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

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

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

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

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

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