massa142's blog

くり返す このポリリズム

2017年3月の振り返り

仕事

  • Danger導入
  • Djangoのlocaleファイル整理
  • ランディングページをDjangoアプリから切り離してS3管理に
    • お問い合わせフォームのPOST処理はをAPI GatewayとLambda
    • chaliceを利用
  • JS環境のモダン化に着手

アウトプット

ブログ

イベント

音楽

映画・ドラマ・アニメ

ラクロス

  • 入団・残留が落ち着いて、チームが固まってきた
  • ミーティングの数を増やそう

その他

目標と成果

  1. △ JSの勉強をする
    • 仕事でフロントエンドの改修にとりかかったけど、あまり時間確保できなかった
  2. ◯ まつもとゆきひろ 言語のしくみ を読む
  3. ◯ そろそろ2017年の抱負を書く
  4. × 執筆作業を進める
    • 今月から本気出す
  5. ◯ ラクロスの時間を確保する
    • 平日のトレーニングも再開していこう
  6. ◯ 業務外での仕事を完成させる
  7. △ PyCon mini Kumamotoの準備をする
    • スライド作成着手

4月に向けて

  • フロントエンドの改修を形にする
  • 執筆作業を進める
  • PyCon mini Kumamotoで発表する・楽しむ
  • 平日のトレーニングを再開する

2017年の抱負

あけましておめでとうございます。

ずっと書こうと思ってたけどサボり続けてた、今年の抱負を4月のいまさら書いておきます。

エンジニア

Python

JavaScript

  • Okachi.js
    • 継続参加していく
    • 定期的にアウトプットの場を設ける
  • AngularとVueを追っていく

新しい言語

達人プログラマーの教え通り、今年も新しい言語を１つ学びたい。

PyCon JP 2017が終わって落ち着いたらやる。候補は以下の３つ。

アウトプット

  • WikiHub 日報
    • 日々の作業・思考ログ
  • はてなブログ
    • 毎月の振り返り・目標設定
    • 読書ログ
    • イベント参加レポート
  • Qiita
    • 今年もAdvent Calendar駆動になりそう
  • 登壇
    • 今年はちょっとずつ登壇していきたい
  • 書籍出版
    • もう動き出したので必ずやりきろう

SQUEEZE

  • 機能断捨離
  • Python3移行
  • マイクロサービス化
  • JS環境モダン化
  • 品質向上
  • スクラム実践
  • 開発文化の明文化
  • Golang導入

ラクロス

Advance-Hanglooseでの実働4年目。

去年は入れ替え戦に負けて、二部転落。

今年は幹部として、もっと責任感を持ってやっていく。入れ替え戦に勝って、クラブ選手権に行こう。

その他

  • 肉を料理する
  • DJの練習はじめる

結び

それでは、今年もどうぞよろしくお願いします。

「まつもとゆきひろ 言語のしくみ」を読んだ

まつもとゆきひろ 言語のしくみ

まつもとゆきひろ 言語のしくみ

発売直後に買ったまま積読してあった「まつもとゆきひろ 言語のしくみ」を読み終えた。

Streemの言語デザインを決めていくなかで、次のことが詳しく説明されていてとても勉強になった。

個人的には、比較対象としてPythonがよく登場しており嬉しかった。

ただ自分はC言語スキルが乏しいので、Streemの実装に関してはわからないところが多々あった。C言語について詳しくなった時に改めて読み直したい。

github.com

また、MatzがStreemのコンカレンシーモデルをRuby3に取り込もうとしてたのは知らなかった。Ruby3の話や実際に採用されたコンカレンシーモデルのGuildについてはRebuildでも話してたので、もう一度聞きなおそう。

この本のおかげで、プログラミング言語の言語デザインというものにとても興味が持てた。普段使っているPythonやGo、JavaScriptに関してはもっと深く知りたいと思え、自分が使ったことがないプログラミング言語も新たに学びたいという意欲がかきたてられてよい。

※ 自分にもっと技術力があれば、「自分も新しいプログラミング言語をデザインしてみよう」と思えたのかもしれない。

合わせて聞きたい

合わせて読みたい

読書メモ

第1章 さあ、どんな言語を作ろう

  • バーチャルマシン
    • システムバーチャルマシン - ハードをソフトでラップ
    • プロセスバーチャルマシン - ソフトで実現したCPU
  • CPUとメモリとメモリキャッシュについて
  • 構文木インタープリタを命令列に変換して、連続したメモリ領域に格納
  • Ruby1.9から「YARV」(Yet Another Ruby VM)が導入
  • Rubyの初期設計のときに、Pythonを意識していたことが書いてあって面白い
  • Pythonは"普通"過ぎた
  • 変数名・継承・エラー処理・イテレーター
  • 他の言語と比べながらの解説でわかりやすい

第2章 新言語「Streem」の設計と実装

  • 2-1 抽象的コンカレントプログラミング

    • 並列(Parallel)
      • 複数の処理を同時に行う
    • 並行(Concurrent)
      • 少なくとも見かけ上は複数の処理を同時に行う
    • プロセス
      • 「実行中のプログラム」のことを表す
      • それぞれのメモリー空間が独立
      • メモリー空間全体を複製することから、forkによるプロセス発生のコストは高い
        • Cow(Copy on Write)などで効率化しているけど
      • プロセス間通信も難しい
    • スレッド
      • 一つのプログラムの中でメモリー空間を共有しつつ、複数の制御の流れを実現
      • 整合性を維持する排他的制御(Mutex)が面倒
      • 結局システムコール呼び出しはコストになる
        • 特権命令が実行できるカーネル空間への切り替え
        • 膨大なCPU命令数
        • スタック領域としてのメモリー割り当て
    • アクターモデル
      • 非同期のメッセージをやり取りできるアクターという独自の制御の流れを持った存在
    • Erlang
      • Ericssonが開発したの知らなかった
      • Erlangのプロセスがアクターに相当
        • OSのプロセスと紛らわしい
    • Go
      • goroutine
      • メッセージ送信の対象はchan(チャネル)オブジェクト
    • Clojure

  • 2-2 新言語「Streem」とは

    • 「Stream」から名前変わってたの知らなかった
    • 21世紀のシェルスクリプト
      • 軽量なコンカレント実行
        • 一つのプロセスの中でCPU数に応じたスレッドを生成して、それらが交代で実行を引き受ける
      • コンカレント実行における競合状態の削除
        • すべてのデータをイミュータブルに
      • 計算モデル
        • シェルの実行モデルを参考に、抽象度が高い計算モデルを導入
        • そのぶん表現の自由度は下がる

  • 2-3 文法チェッカーをまず作る

    • 供給者・消費者パターン
    • ラウンドロビンパターン
    • 放送パターン
    • 集約パターン
    • 要求・応答パターン

  • 2-4 イベントループ

    • イベント処理を行うライブラリ

      • libevent
      • libev
      • libuv

    • I/Oイベントの検出

      • ブロックを回避するために、ファイルディスクリプターにデータが届いていることを確認する必要
      • select
      • epoll(Linux)
      • kqueue(BSD系OS)
    • 文法衝突みたいなうまくいかなかった話が面白い

  • 2-5 マルチスレッドとオブジェクト

    • マルチコアの実装が難しいのがわかる
    • 優先度付きキューのアルゴリズム面白い
    • ガーベージコレクション
      • libgc

    glibのメモリ管理でlibgc(boehm gc)を使う方法

    libgcは、GC_INIT()を最初によび、以下メモリ確保でGC_MALLOCなどをmallocの代わりに使うことで、freeしなくてもガーベージコレクタが機能するプログラミングを行えるライブラリです。

  • 2-6 キャッシュとシンボル

    • マルチコアではL1キャッシュは各コアが独立にもっていて、L2とL3は複数コアで共有することが多い
    • ‘There are only two hard things in Computer Science: cache invalidation and naming things.’ - Phil Karlton
    • 『"Don’t guess, measure!（推測するな、計測せよ！）”』
    • Rubyのシンボル

    https://docs.ruby-lang.org/ja/2.3.0/class/Symbol.html

    Rubyの内部実装では、メソッド名や変数名、定数名、クラス名など の`名前'を整数で管理しています。これは名前を直接文字列として処理するよりも 速度面で有利だからです。そしてその整数をRubyのコード上で表現したものがシンボルです。 シンボルは、ソース上では文字列のように見え、内部では整数として扱われる、両者を仲立ちするような存在です。 名前を管理するという役割上、シンボルと文字列は一対一に対応します。 また、文字列と違い、immutable (変更不可)であり、同値ならば必ず同一です。

    • Pythonは文字列をインターン化することで性能解決
      • Pythonは文字列がイミュータブルなため
    • シンボルごみ問題
      • GCする必要あり
      • 「弱い参照」(参照はしているがガーベージコレクション保護の対象にならない参照)

  • 2-7 AST(抽象構文木)に変換

    • 構文木のままトラバースして実行するのは性能が良くない
      • メモリー空間を飛び飛びにアクセスするためキャッシュ効率が悪い
      • VMのバイトコードに変換して連続的に解釈するのが望ましい

  • 2-8 ローカル変数と例外処理

    • ローカル変数の実装
      • 関数のコンパイル時にローカル変数ごとに個別のインデックスを割り当て
      • この配列がスタック
    • クロージャー
      • 関数オブジェクト(無名関数)に外側のスコープの変数が「閉じ込められている」
    • CやGoは明示的エラーチェック
      • コンカレントプログラミングと相性が悪い
    • 例外安全性が大事になる
    • SwiftのOptionalおしゃれ
      • Java8でも便利だった思い出

第3章 オブジェクト指向機能を設計する

  • 3-2 Streemのオブジェクト指向

    • Namespaces are one honking great idea
    • Python・JavaScriptはLisp-1
    • RubyやSmalltalkはLisp-2
    • StreemはLisp-1.5
      • 関数名を直接指定したときには関数への参照
      • 「.」を使ったメソッドチェーン形式では引数のないメソッド呼び出し

  • 3-3 Streem文法再訪

    • Lisp-2
      • メソッドキャッシュによる高速化
      • ネームスペースに分散した関数を総称的に扱うのが得意でない

  • 3-4 パターンマッチ

    • 末尾再帰化でスタックの無駄遣いを解決

第4章 Streemオブジェクトを実装する

  • 4-1 ソケットプログラミング

    • そもそもソケットとは

  • 4-3 オブジェクト表現とNaN Boxing

    • CPython: オブジェクトへの参照は構造体へのポインタ
      • 単純ポインタ法
      • 構造体へのアクセス最速
      • オブジェクトへの割り当てが大量になる
    • CRuby・Emacs Lisp: ビットに型情報を詰め込み、整数の値など一部の値を参照に直接埋め込む
      • Tagged Pointer法
      • メモリ効率Up
    • mruby・Lua: オブジェクトへの参照は構造体
      • シンプル & 移植性の高さ
      • メモリ効率Down
    • V7: NaNの浮動小数点でオブジェクト表現

  • 4-4 ガーベージコレクション

    • トレース法
      • 「生きている」オブジェクトを確実に検出
      • 処理時間が長い
      • マークアンドスイープ法 / コピー法
    • 世代別GC
      • 「若い」オブジェクトを重点的にスキャン(マイナーGC)
      • 旧世代領域から新世代領域への参照はリメンバーセットで管理（write barrier）
      • 全ての領域をスキャンするフルGC(メジャーGC)
      • 実行時間を短くできるが、最大停止時間は変わらない
    • インクリメンタルGC
      • 処理を細切れにして少しずつ実行
      • 世代別GCと同様んひライトバリアを使用
      • 実行時間は長くなるが、最大停止時間は抑えられる
    • リファレンスカウント法
      • オブジェクトの解放を局所的に判断できる
      • 停止時間も短くなる
      • 循環参照を持つオブジェクトを解放できない
      • 並列処理と相性が悪い
    • 例えば GC を止める・Ruby ウェブアプリケーションの高速化
    • Dismissing Python Garbage Collection at Instagram

第5章 ストリームプログラミングを強化する

  • 5-1 パイプラインプログラミング

2017年2月の振り返り

もう3月になって1週間過ぎちゃったけど、2月の振り返り。

仕事

  • GoによるAPIプロキシサーバー
  • それを利用するためのPython Package
  • 依存パッケージのwheel化
  • サムネイル生成のAWS Lambda

アウトプット

ブログ

イベント

読書

先月の読書メーターまとめ

読んだ本の数：1冊
読んだページ数：144ページ

音楽

映画・ドラマ・アニメ

N/A

ラクロス

  • 鹿島OPENめっちゃ楽しめた
  • バサロカップでのパフォーマンスも良かった
  • 2月後半は忙しくてあまりできてない
  • チーム全体としてもっと練習盛り上げていかないと

その他

  • PyCon mini Kumamoto 2017のTalk採用された
  • アライド株を売った
    • 500円で買ってた株が4000円になっててすごい(小並感)

目標と成果

  1. ◯ Golangもっと勉強する
  2. × まつもとゆきひろ 言語のしくみ を読む
    • Golang以外の本を読む余裕がなかった
  3. × 1月終わったけど2017年の抱負を書く
    • 気づけばもう3月
    • 今週こそ書くぞ…
  4. ◎ 鹿島Open楽しむ・騒ぐ
    • 最高に楽しめた
    • 祝優勝！また来年！
  5. △ ラクロスの時間を確保する
    • 確保できつつあるけど、まだまだ足りない
  6. △ 業務外の時間を確保する
    • 仕事が落ち着いた月末から確保できてきた
  7. × 映画・ドラマ観たい

3月に向けて

「みんなのGo言語」を読んだ

みんなのGo言語【現場で使える実践テクニック】

みんなのGo言語【現場で使える実践テクニック】

業務でGoを書くことになったのがきっかけで、「みんなのGo言語」を読んだ。

Goの経験は、1年ちょっと前に A Tour of Go やって、CLIツールとか書いたことある程度だった。

github.com

結果として、この本から

  • Goらしいプラクティス
  • 仕事で使えるテクニック

を知ることができたおかげで仕事が捗った。

タイトルにもある通り、「現場で使える実践的なテクニック」という趣旨が各章で意識されていた。薄い本だけどカバー範囲が広く内容が詰まっていて、とても読み応えがある。

特に「第1章 Goによるチーム開発のはじめ方とコードを書く上での心得」と「第6章 Goのテストに関するツールセット」の内容が、めちゃくちゃ勉強になったのでオススメ。

プログラミング言語GoとかA Tour of Goの次に読むべき本として最適だと思う。

読書メモ

第1章 Goによるチーム開発のはじめ方とコードを書く上での心得

第2章 マルチプラットフォームで動作する社内ツールのつくり方

  • mattnさんの章
  • Goの特徴
    • スタティックビルド(プログラムの実行に必要なライブラリがあらかじめリンクされていること)
    • シングルバイナリ
  • Windows対応の話がメイン
  • 「2.6 シングルバイナリにこだわる」はWindowsだけじゃなくてweb開発で汎用的に役立つ内容だった
    • 静的ファイルをバイナリに組み込むやり方について
    • go generateをうまく使ってて参考になる

第3章 実用的なアプリケーションを作るために

第4章 コマンドラインツールを作る

第5章 The Dark Arts Of Reflection

第6章 Goのテストに関するツールセット

2017年1月の振り返り

もう2月に入ってしばらく経ってるけど、1月の振り返りブログを書いておく。

頭の整理のために、月単位での振り返りをはじめてみる。

仕事

アウトプット

ブログ

イベント

読書

先月の読書メーターまとめ

読んだ本の数：2冊
読んだページ数：672ページ

音楽

1/28にYYY Vol.2とYSTK×KPP CLUB EDITIONがあったから、今月はその関連の曲をよく聞いてた。

そしてついにTeddyLoidにハマった。

映画・ドラマ・アニメ

N/A

ラクロス

  • 体力づくりのために皇居ラン再開
  • 思ったよりブランクを感じずにシーズンインできた
  • 1月はあまり練習いけなくて申し訳なかった

その他

2月に向けて

「ジョイ・インク」を読んだ

ジョイ・インク 役職も部署もない全員主役のマネジメント

ジョイ・インク 役職も部署もない全員主役のマネジメント

*1先日のRegional SCRUM GATHERING Tokyo 2017で宣伝されていた「Joy, Inc.」日本語版を読んだ。

この本の趣旨と翻訳に至った経緯は以下のように記されている。
Ref: 【17-B-7】 『ジョイ・インク』Joy, Inc. 〜 共感のソフトウェアづくりについてみんなで考えるワークショップ | Developers Summit 2017

“Joy, Inc.: How We Built a Workplace People Love”(2015年刊行） は、アメリカ、ミネソタ州にあるソフトウェア受託開発企業メンロー・イノベーションズ社の15年にわたるモノづくり、人づくり、顧客との関係づくりの詳細をまとめた本です。そこには2000年代初頭にアジャイル開発(特にXP)とデザイン思考に出会った人々が、苦労を重ねながら優れた組織とプロセスを作り上げる過程と、行なっている優れたプラクティスについて語られています。そして、2016年12月に、原著に共感したアジャイルコーチが集まって、日本語翻訳版『ジョイ・インク』を刊行しました。

XPやアジャイル開発のことを知っている人であれば、すんなり読むことができると思う。その考えを経営・会社作りにも適用してるというもの。川鍋さんのアツいあとがきに書いてある「アジャイル経営」という言葉がとてもしっくりくる。

失敗したことやうまくいかなかったことも多く書かれていて、とても共感が持てる。またメンローという会社はシリコンバレーにあるエッジの効いたハイテクカンパニーというわけでもない。決して手の届かないどこか遠い話ではなく、自分ごとのように身近に感じることができた。

  • エンジニアだけでなく経営メンバーなど色んなひとに読んでもらいたい
  • 一緒に喜びに満ちた会社を作っていきたい

そう思える一冊でした。会社の本棚に置いておこうと思う。

合わせて読みたい

読書メモ

イントロダクション

  • 喜びと幸せは同じではない
    • 幸せとはある時点における状態の話
    • 幸せな状態が連続していなくても、喜びに満ちていられる
    • 根本的で本能に根ざした追求心は喜びに向かう

1章 僕が喜び(Joy)にたどり着くまで

2章 スペースとノイズ

  • 壁を取り払え
    • キュービクルは最悪だよね
      • コミュニケーションうまない
      • 個人主義すぎる
  • フィクションから得た「身軽」というひらめき
    • 遊びごころが戦場の緊張感を和らげる
      • 犬とか赤ちゃんとかよいよね
  • C?Oはどこにいる
    • 権威づけいらない
  • オフィス警察はいらない
    • 自分たちの場所はオーナーシップを持って自分たちの望む場所に変えていく
  • 喜びは騒がしい
    • 賛成だけど集中するためにヘッドホンしたいよね

3章 自由に学ぶ

4章 会話・儀式・道具

5章 インタビュー、採用、立ち上げ

  • 「正しい人をバスに乗せ、正しくない人をバスから降ろす」
  • 採用はカルチャーに直結するから、とことんこだわりたい
    • 長期間のトライアルは実際に仕事を一緒にできるから有効
      • コスト大きい & 情がうまれてしまって採用判断が難しそう

6章 観察のもつ力

  • ハイテク人類学をソフトウェアに適用
  • グループインタビューは人格が破綻した人に乗っ取られてしまう
  • そもそもユーザーは自分が本当に欲しいものを知らない
  • プライナリペルソナ（1人だけ）を設定する
    • 誰にとっても役立つようなサービスは誰からも使ってもらえない
    • 百徳ナイフにするな

7章 恐れと戦う、変化を抱擁する

  • すばやくたくさん失敗しよう
  • サンクコストによる思考停止
    • こんなに投資してきたんだから
    • うまくいかないことをやろうとした奴らと思われたくない
    • 実験が失敗だとわかっても、コースを変更したがらない。これまでの投資が無駄だったと認めたくない
  • 心理的安全性
  • SQUEEZEもオフィスに赤ちゃんいるけど、とてもよい試みだと感じる

8章 ボスではなくリーダーを育てる

  • みんな完璧ではないことを認めなくてはいけない
  • 何か問題があった場合に、すぐ晒け出される仕組みが大事
    • 悪いことを隠そうとしない
  • 『ビジョナリーカンパニー』からの引用多い
    • 読みたさ

9章 カオスを終わらせる、曖昧さをなくす

  • 見積もりなしに仕事はしない
  • やること/やらないことを明確に
  • 複雑なプロジェクトのためのシンプルなシステム
    • 使うツールは少なく・シンプルであるべき
  • ショッキングピンク判断

10章 厳格、規律、品質

  • 厳格さと規律が品質を保つ
  • 厳格さと規律はルーティンをもたらす
    • 一流はルーティンを大切にして、身体だけでなく魂を傾ける
    • 二流は表面的には従うが、信じてはいない

11章 持続可能性と柔軟性

  • 卓球台・ゲーム機・マッサージチェア
    • こういったの置いてるのは遊び心ある会社ですよっていうパフォーマンスでしかないよね
    • 確かにほとんど使ってないイメージ
  • 低い離職率は健全な文化の証ではない
    • ex) 東ベルリン
    • 高給で引き止めてることが多い
  • 出戻り推奨
  • 「許可を求める」という文化はいけてない

12章 スケーラビリティ

  • ブルックスの法則

    遅れているソフトウェアプロジェクトへの要因追加は、さらにプロジェクトを遅らせるだけだ

  • ペアプロのメリットはわかるが...

13章 説明責任と結果

  • かかった時間とベロシティの測定が見積もりの正確さにつながる
  • 自由さの報酬としての説明責任

14章 アライメント

  • 文化を隠すな
  • 自分たちのストーリーを話せるようにする

15章 問題

  • メンローにも他のところと同じ問題を抱えている
    • 問題の数は他と変わらないが、問題のサイズはだいぶ小さい
    • 問題が見つかれば隠さないで、小さいうちに解決
  • 会社の問題を気軽に議論にあげられる場と仕組みを作りたい

16章 まとめ

推薦者あとがき

  • 川鍋さんアツい
  • 文化が一番大事
    • 素早くたくさん失敗する
    • 見える化・情報の共有文化
    • 社員も顧客も文化を第一に選び・信じきる
  • たくさんの失敗を奨励するには、きちんとした評価制度が必要と感じた
    • 質の低い失敗を繰り返さないように

*1:Regional Scrum Gathering Tokyo 2017 に参加してきた #RSGT2017 - massa142's blog