delirious thoughts

A blog about anything that I can feel delirious from

「酒を飲みながらコードを書く」というLTをした

ハックガールズpresents システムライトニングトークBar Vol.2」というイベントにお誘いいただき、LTをしてきました。話す方も聴く方もお酒を飲みながらという感じとのことなので、技術的な内容というよりは、軽く聴けるカジュアルな内容がよかろうというわけで、「酒を飲みながらコードを書く」というタイトルで話をしました。

イベントは、渋谷・道玄坂にある実験型イベント企画スペース ヒミツキチラボ Produced by SCRAPで行われました。いらっしゃったのは20人ぐらい?いつも参加するようなイベントとはやや違った感じのお客さんだったように思われましたが、反応もよかったし、もちろんトークしてくださった方々も面白かったし、いいイベントになったように思います。

貴重なご機会を与えていただきまして、ありがとうございました。ハックガールズとあまり近しくなれなかったのが心残りでした。

Gyo - Yo for Go

「Yoはコンテキストだ」。

新時代のコミュニケーションに触れてみようってんで、手遊びに、GoでYo APIのクライアント + Webhookを書いた。まあ、「書いた」とかいうほどのものでもないけど。

こんな感じで使う。以下は、Yoされたら、YoしてきたひとにYoをそのまま返す例。echoサーバみたいなやつ。

package main

import (
    "flag"
    "github.com/kentaro/gyo"
    "log"
)

var apiToken = flag.String("token", "", "API Token")
var port = flag.Int("port", 8080, "Port of the server")
var path = flag.String("path", "/callback", "Callback URL of the server")

func init() {
    flag.Parse()
}

func main() {
    if *apiToken == "" {
        log.Fatalln("API token is required")
    }

    gyo := gyo.NewGyo(*apiToken)
    gyo.Server(*path, *port, func(username string) {
        gyo.Yo(username)
        log.Printf("Sent Yo to %s\n", username)
    })

    return
}

Herokuにデプロイしてみようと思ったけど、面倒になったので、手元で動かしてみて満足した。

どうぞご利用ください。

ペバボのエンジニア職位制度のアップデートについて

ペパボで行っているエンジニア職位制度について、最新情報を共有します。

本エントリの背景

ペパボで行っているエンジニア職位制度(シニアエンジニア、アドバンスドシニアエンジニアの選考)については、制度の運用当初に、当時の責任者であるmizzyさんがPaperboy's engineer evaluation system - Gosuke Miyashitaというエントリで紹介しています。その頃から2年半ほどが経過し、また、責任者が変わったこともあるので、あらためていまはどういう感じなのかお知らせしたいと思います。ちなみに、一般のエンジニア評価制度については、新たに運用開始した内容を、既にペパボのエンジニア評価制度をパワーアップしたでお知らせしています。

本エントリの目的

そのような、いってみれば内輪の話の共有を、ある意味わざわざ行う目的は、エンジニアとしての将来をあれこれと検討している社外のエンジニアのみなさんに対して、ペパボについて考慮の範囲に入れる材料としていただき、ひいてはよい形で入社していただくことで、ともに会社の成長を実現していきたいと考えるからです。

制度の概要

本制度をひとことでいうと、技術専門職(この場合だとエンジニア)における、上級職へのステップアップを定めたものです。その特徴としては、以下があります。

  • 全職種共通の等級から、専門上級職へのステップアップであること(シニアエンジニア、アドバンスドシニアエンジニア)
  • 誰かの任命によるのではなく、本人の立候補により選考過程が始まること
  • これまでの実績、自分を昇格させるべき理由を主張する文書をGitHubのpull requestによって提出し、全社員公開の元にプロセスが進むこと

以下に掲げる文章は、今半期の評価結果について社内向けに書いた文章のうち、完全に社内向けのものを除いたものです。


選考過程

  1. 6/6告知、6/18立候補締め切り
  2. 6/20〜6/24面談
  3. 面談に参加した技術基盤チーム各自の意見を参考にしつつ、antipopの責任において決定
  4. 6/25一次評価結果公開

このあと、6/30の経営会議において、最終決定します。

選考基準

mizzyさんのエントリにある基準に基づき評価を行いました。その際、そこで謳われている「技術力」を以下のように分解しました。

  • 作り上げる力
  • 時間の経過に耐える力
  • 影響を広げる力

作り上げる力

これは、一般に技術力といった場合に想像しやすい能力でしょう。「他の人にはない、技術的に優れた何か」を用いて、技術的に困難な問題を、素早く、確実に解決することができる、ということです。

時間の経過に耐える力

一方で、我々が作るものは、単に一度作れば済むものではなく、継続的に価値を届け続けるべきものです。つまり、ある特定の時点における線の価値のみが高いだけでは不十分です。それに加えて、時間の経過に対して積分的な面の価値を増大させる必要があります。そのためには、設計力、テストを書く能力が必要です。

影響を広げる力

さらには、上記の能力に基づいて、自分や身の回りだけではなく、エンジニアリングにおけるリーダーとして影響力を広い範囲に及ぼせることも、シニア、アドバンスドシニアには求められます。技術的には技術レイヤーの上下方向へ、プロセス的には広い範囲の人々を巻き込んでいく左右方向へ、それぞれ影響を広げていける能力です。

(社内向け文面略)

講評

先述の選考基準に基づき評価を行い、上記の通り1次評価を決定しました。基準のうち、3点とも満たしていることがもちろんよいのですが、今回、すべてにおいて文句なしというひとはいませんでした。そうした条件をすべて満たし、かつそれ以上の成果・能力・影響力を持つ人が、アドバンスドシニアということになるんだと思います。

逆に、不通過とした方々についても、それぞれにおいてもう一歩というところまできていると思います。その点、今後どうしていけばいいのかということについて、面談やコメントを通してお伝えしたつもりです。是非、また次を目指してください。

今回1次通過した人に関しては特に、シニアエンジニアとなった暁には、さらに以下についてのコミットを求めていきます。

  • 他のエンジニアをリードし、技術的な成長を支援すること
  • 社内外(特に社外)へのアウトプットをすること

シニア、アドバンスドシニアエンジニアは、役職上のリーダーとはまた異なる意味において、技術的な知見・能力に基づくリーダーシップを発揮すべき存在です。そこには年齢や社歴はまったく関係ありません。自らの成果を出すことは当たり前、その上で、他のエンジニアたちを引っ張り、成長を支援する存在となることを求めます。

また、ひとそれぞれの性格や取り組んでいる内容などによって打ち出し方は異なってくるとは思いますが、社内で影響力を及ぼしていくことは必須として、社外に対しても、活発に技術イベント等を通してプレゼンスを発揮するとか、あるいはそうしたことが苦手なひとに関しては、OSSを通してアウトプットを行う等、技術の会社としてのペパボという立場をアピールすることに貢献をもとめます。

また、いま現在シニア、アドバンスドシニアエンジニアであるみなさんについても、今回の結果と自分の能力・成果等について振り返り、いまも自分がシニア、アドバンスドシニアという職位にふさわしいかどうかを、真剣に考えてみてください。この職位は「資格」のようなものとは違います。制度の運用から2年半以上が過ぎました。今後の適正な運用と全社の成果向上のために、制度とともに個々の職位についても、適宜見直していきます。


というわけで、ペパボではこんな感じの制度を運用しながら、エンジニアがよりよく働ける環境作りを大切にしつつ、ひいてはそのことが事業の成長につながることを確信して日々やっていっています。興味のあるかたは、是非以下をご覧になっていただきますよう、お願いいたします。もちろん、僕個人に直接ご連絡くださってもかまいません。

2014年6月に読んだ本をブクログでふりかえる

今月は18冊。最近、雑駁な感じにしか読めてなかったのでよくなかったのだけど、今月は比較的マシな感じで読めたのでよかったかな。

『浅田孝―つくらない建築家、日本初の都市プランナー』は、メタボリズム運動のファンとしては、よく出してくれた!とうれしかった1冊。丹下健三とメタボリストたちのちょうど間の世代に位置する浅田孝は、その知性のあり方やひととなりが、自分的になんだか好きな感じの人物なのであった。

その他、仕事関連であれこれと考えていることがあっていくつか必要な本を読んでいたのだけど(『強い調達』『企業内人材育成入門』『人事管理入門』あたり)、いろいろと学習するべきことは多い。本だけではもちろん足りないが、本を読まなければそれはそれで足りないのである。

今後の予告としては、マネジメントや経営戦略に関する知見の歴史みたいなのに興味を覚えてきた(そのモチベーションは、実用というよりは、純粋に歴史に対する興味の方にずっと近い)ので、そのへんをちょいちょい掘っていこうかなと思っているところ。『マネジメントの世紀』あたりはそういう本。

kentaroの本棚 - 2014年06月 (18作品)
経営を見る眼
伊丹敬之
読了日:06月25日
評価3

powered by booklog

書評『Chef実践入門 コードによるインフラ構成の自動化』

Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus)』をご恵贈いただきました。毎度ありがとうございます。

Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus)

Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus)

Chefについては、先日「書評『Chef活用ガイド - コードではじめる構成管理』」にて、ほぼ同時期に刊行された別の本について述べたところです。僕自身のChefやInfrastructure as Codeへの考えについては、繰り返す必要もないでしょう。そちらのエントリをご覧ください。

さて、こちらの本は「実践入門」というだけあって、実際に手を動かしながらChefに慣れていこうという構成です。Vagrantを用いて、本の記述に沿って試してみるうちに、次第にChefがわかってくるという寸法。『入門Chef Solo - Infrastructure as Code』からブラッシュアップした章もありますし、そのアップデート版といった感じでしょうか。概要を把握しつつ手を動かしていくうちに、ちょっとしたシステムについてなら、それなりにInfrastructure as Codeできるようになりそうです。

また、Chefにあんまり詳しくない僕としては、細かいお作法みたいなものがちょいちょい書かれているのが便利でした。たとえば、以下。

なお、Ohaiの値のキーは:platformとしてシンボルで指定するのに対し、Nodeオブジェクトに定義したものはnode['httpd']['port']とキーに文字列を使うのが慣習です。

(本書p.83)

ifを使うとインデントが深くなり、可読性を落とします。このようなときは、条件付きアクションを使うことでスマートに処理を記述できます。

(本書p.229〜230)

こうしてひと通りのレシピを書けるようになったあと、実際の複雑なシステムに立ち向かった時、読者はその複雑さをどのように読み解き、モデル化し、メンテナンサブルなクックブックに落としていくのかという現実に突き当たると思います。その答えの一端について触れていないわけではないものの、それは本書の範囲を超えるでしょう。その際は、コミュニティのクックブックで設計を学んだり、『Chef活用ガイド コードではじめる構成管理』を読んでさらに知見を深めたりといったことが必要でしょう。

ともあれ、Chefを学びたいひとにとっての最初の1冊として、間違いなくおすすめできる本だと思います。

Casto: 史上最速にライブコーディングができるサービス

CastoというWebサービスがあります。史上最速に、インターネット経由でライブコーディングができる、非常に素晴らしいサービスです。その素晴らしさのわりにまだあまり知られていないので、紹介します。

Castoでライブコーディングを始めるには、ふたつの方法があります。

後者のコマンドの例は、作者によって以下の様なアニメーションGifで紹介されています。

↑の画像では、Casto上のURLをコピペしてブラウザで開いていますが、--browseオプションをわたすと自動的にブラウザで開くよう、pull requestを送って、マージされております。

コマンドについては、最近追加されたのですが、さらに利便性が高まったと思います。是非お試しいただきたいサービスです。

ghqを使ったローカルリポジトリの統一的・効率的な管理について

GitなどのVCSからcloneしたローカルリポジトリをどう管理するのがいい感じなのか、よくわからない。なんとなく自己流でやっているが、もっといい方法を知りたい。

tl;dr - ディレクトリレイアウトをgolangの作法に合わせ、すべてのリモートリポジトリをghqを使ってcloneし、percolを使って簡単に検索できるようにしましょう。

背景

そんな課題を抱えつつも、特になにかをするわけでもなく日々暮らしていた折、Rebuild: 42: When in Golang, Do as the Gophers Do (lestrrat)@lestrratさんが、Goのお作法に、他の言語のリポジトリも含め、すべてあわせるようにしたとおっしゃっていて、なるほど!と思ったのであった。

Goのお作法

以下、「Goのお作法」を知らない人向けの簡単な解説。

Goのディレクトリレイアウト

Goには、外部のコードを以下のようにして取得するユーティリティが付属している。

$ go get github.com/motemen/ghq

この結果、ローカルリポジトリが、$GOPATH/srcというディレクトリ以下へ、mainパッケージがあればビルドされたコマンドとして$GOPATH/bin以下へ、次の通りに配置される。

$GOPATH
|-- src/
|   `-- github.com/
|       `-- motemen/
|           `-- ghq/
|-- bin/
     `-- ghq

これが、Goのディレクトリレイアウトに関するお作法である。簡単ですね。

パッケージのインポート

このお作法は、Goのコードを書く際にも意識する必要がある。ライブラリを使う場合、以下のように書く。

import "github.com/kentaro/delta"

この指定により、$GOPATH/src/github.com/kentaro/delta直下にあるパッケージがインポートされる。

また、この指定は、サブディレクトリ以下に配置されたパッケージをインポートする場合にも使われる。たとえば以下のような配置のプロジェクトがあり、

$GOPATH
|-- src/
    `-- github.com/
        `-- motemen/
            `-- ghq/
                |-- main.go
                `-- utils/
                    `-- log.go

いま、main.goを書いているとする。utils/log.goを使おうとする場合、単にimport utilsとするのはダメで、正しくは

import "github.com/motemen/ghq/utils"

とする必要がある。そして、その際はもちろん、$GOPATH以下からファイル名が解決される。

「Goのお作法」のインプリケーション

一般に、外部ライブラリやツールとして入れたソースコードと、自分のワークスペースは分けるものだ。たとえばCPANrubygemsなどでも、普通に運用する分には、そうなるだろう。

Goにおいては、上記のような事情により、外部ライブラリと自分の開発用ワークスペースとを区別しない方が便利である。ある意味、大胆な選択といえるが、いったん慣れてしまえば、最初からこれでよかったのでは?というか、言語にかかわりなく、これでいいのでは?という気になる。

解決

では、Goのお作法に合わせようということになったところで、そのお作法通りのディレクトリ構造を、その都度手動で作るのは面倒だ。そこで、id:motemen作のghqを使う。使い方については、リンク先を読んでもらえばよいだろう。

さらに、我々としては上記のGoのお作法に合わせたいのだから、どこにcloneするかについてもきちんと設定する必要がある。これはどこでもいいのだけど、シンプルさを追求するため、以下のように、$GOPATH$HOMEとを同じものにすることにした。

export GOPATH=$HOME

その上で、先述の通り、Goはgo getした結果を$GOPATH/src以下に配置するので、ghqの設定を、以下の通り.gitconfigに追加する。

[ghq]
  root = ~/src

これで、ghq getしたものも、go getしたものと同様のディレクトリに配置されることになる。また、ghqGitHub Enterpriseに対応させる私の送ったプルリクエストも採用されたので、プライベート/パブリックなもの、github.com/GH:Eとを問わず、すべてのリポジトリを同じようにghqを用いて扱うことができる。

gem-src

ところで、gem-srcという、@amatsudaさん作成のgemがある。これは、gem installをフックして、そのライブラリのgitリポジトリを自動的にcloneしてくれるというもの。

これに関しても、上記と同じようにghqを使って、同じディレクトリ構造でcloneしておくようにしたら便利ではないか。そういうわけで、gem-srcにプルリクエストを送ったり、amatsudaさんによる改良を経て、以下のような設定を.gemrcに入れておくと、ghqを使ってcloneするようになった。

.gemrc:

gemsrc_use_ghq: true

その後、ライブラリをgem installすると、以下のようになる。

$ gem i glint
Fetching: glint-0.0.2.gem (100%)
/Users/usr0600239/bin/ghq
     clone http://github.com/kentaro/glint -> /Users/usr0600239/src/github.com/kentaro/glint
       git clone http://github.com/kentaro/glint /Users/usr0600239/src/github.com/kentaro/glint
Cloning into '/Users/usr0600239/src/github.com/kentaro/glint'...
remote: Reusing existing pack: 185, done.
remote: Total 185 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (185/185), 20.76 KiB, done.
Resolving deltas: 100% (61/61), done.
Successfully installed glint-0.0.2
1 gem installed

clone先の管理

このようにして、なんでもかんでもこの方法に従ってcloneしていくと、$GOPATH/src以下に、大量のディレクトリが格納されることになるだろう。そして、なにがそこにあるのかがどんどんwかりにくくなっていく。

これに対処するにはいろんな方法があるが、ここではpercolを使う。percolはまさにUNIXライクなツールで、標準入力から入ってきた行区切りの入力に対するフィルタUIを提供する。これを使って、ghqで管理しているリポジトリのディレクトリに、簡単にcdできるようにする。

zshの場合、このような関数を用意しておく。

function percol-src () {
    local selected_dir=$(ghq list --full-path | percol --query "$LBUFFER")
    if [ -n "$selected_dir" ]; then
        BUFFER="cd ${selected_dir}"
        zle accept-line
    fi
    zle clear-screen
}
zle -N percol-src

んでもって、たとえば^sでこの関数が起動するようにしておく。

bindkey '^S' percol-src

動作の様子は以下。

応用

@lestrratさんに、以下のようなのも便利と教えてもらいました。

$ godoc $(ghq list --full-path | percol) | $PAGER

実行すると、ghqで管理されてるディレクトリからフィルターして絞り込んだ結果をgodocにわたすことで、効率よくGoのライブラリのAPIドキュメントをひけます。

結論

gitでもhgでも、プライベートでもパブリックでも、もはや同じ、統一されたディレクトリレイアウトを採用できる。そして、以上のように、そのためのツールも整った。これで私たちは、迷うことなく、コードを書いていけるだろう。