massa142's blog

くり返す このポリリズム

2017年4月の振り返り

仕事

  • フロントエンドの整理
  • Django1.11へのアップグレード
  • Elastic IP自動設定
  • 社内向けのDjango Plugin作成

アウトプット

ブログ

スライド

イベント

音楽

N/A

映画・ドラマ・アニメ

ラクロス

  • 4月後半は熊本行ったり体調崩したりで練習できなかった
  • 波崎合宿行けなかったのは残念
  • 全体MTGやってよかった

その他

  • SQUEEZE Tシャツできた
  • さしぶりに体調崩してつらかった
  • PyCon JPのMTGが多くなってきた
  • ますとどん楽しいよ
  • けもフレようやく見始めた
    • サーバルちゃんきゃわわ
    • わーい！ すごーい！ たーのしー！
  • 『ボク、運命の人です。』さしぶりに連ドラ見てる

目標と成果

  1. △ フロントエンドの改修を形にする
    • 現状の整理・改修への土台作りまでしかできなかった
  2. × 執筆作業を進める
    • そろそろやばい今月から本気出す
  3. ◯ PyCon mini Kumamotoで発表する・楽しむ
    • 楽しかった！また来年もあったらいいな
  4. △ 平日のトレーニングを再開する
    • 腹筋やら皇居ラン再開した
    • そろそろジムにも行かなくては

5月に向けて

  • 執筆作業を進める
  • フロントエンドの改修を形にする
  • PyCon JPのweb開発進める
  • 平日トレをもっと頑張る

PyCon mini Kumamoto 2017 にスピーカー・スポンサーとして参加してきた #pyconkuma

はじめに

熊本にて 2017/4/23 に開催された PyCon mini Kumamoto 2017 にスピーカー兼スポンサーとして行ってきたので、その参加メモです。

PyCon mini Kumamotoって？

PyCon mini Kumamoto 2017

Kumamoto のPythonコミュニティの定着と広がりを目指しています。初回となる今回は、”未来”というテーマでイベントを開催したいと考えています。開催時期は熊本大地震のほぼ一年後であることと、熊本でのPythonコミュニティ活動としては恐らく初めてであることから、未来を考える事が大切だと考えたためです。Pythonをキーワードに、未来を、参加者と共に感じたり考えたりできるイベントにできたら良いなと考えています。

すでにあるまとめとか

参加メモ

スピーカーとしての感想

SQUEEZEに入社してからの１年間でやってきたことをまとめた感じになってます。

Python要素が少ない構成になっちゃったけど、似たような悩みを持っている方から声をかけてもらったり、参考になったという声も頂けたので良かったです。

今回のテーマが「未来」ということだったので、「バグゼロという未来に向けて」という副題にしてみました。

スポンサーとしての感想

今回SQUEEZEは、シルバースポンサーとして協賛させて頂きました。

Core Valueの１つである “With Our Community” という考えのもと、これからも会社が関わるコミュニティに貢献して、わいわい盛り上げていこうと思います。

全体を通しての感想

  • 熊本大学は緑が多くていいところ
  • @IanMLewis のKeynoteは歴史を感じられて良かった
    • 日本におけるPythonコミュニティの歴史と未来について
    • 「お前、誰よ」という自己紹介の発祥がIanだってこと知らなかった
  • ランチディスカッション楽しかった
    • ランチ休憩の時間で5つ位のテーマに分かれてディスカッションが設けられた
    • 自分は「Pythonと教育」というテーマのところに参加
    • 齋藤さんの研究の知見が聞けて勉強になった
  • １年前に起きた震災とそれからの復興を肌で感じることができた

  • 地元の大学生や高専生も参加してくれた
  • 月曜出社のため打ち上げ参加できなかったのが悔やまれる

  • 来年もPyCon mini Kumamoto開催の方向らしい！

f:id:massa142:20170428152445j:plain

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のテストに関するツールセット