04 Aug 2019, 16:14

Quipper に転職して三ヶ月が経った

さて、2019 年 5 月に Quipper に入り、3 ヶ月が過ぎた。
入ってから 3 ヶ月は試用期間という扱いであったので、このブログを書いている 8 月はちょうど試用期間が終わった段階になる。

試用期間が終わったからと言って何かすごい権限が付与されるとか、ただちにクビになる心配がなくなるとか (そもそも試用期間だからっていきなりクビを切るのは難しいよねきっと) っていう変化は特になく、これまで通りのルールでこれまで通り業務をしていくという感じではある。
とはいえ試用期間が終わったということで、公の見方としてはようやく正式に (?) 社のメンバーになったということなのではないか。
ということで転職エントリー地味たものを書き記しておこうという気になったわけである。

現職は ☆ いくつか?

先日、「ところで Quipper どうよ?」みたいな往年の 2 ch を思わせるような質問をマネージャに投げかけられたわけである。1on1 で。☆ いくつよ?みたいな。

そんな「☆ いくつ」みたいなどっかの料理ショーみたいな採点はひとくちには難しかったので即答はできなかったものの、自分が何をポジティブに、もしくはネガティブにとらえているのかを改めて考えてみた。

ポジティブポイント

  • 英語キーボードの PC が使えて嬉しい。設備繋がりで言えばキーボードもマウスもお気に入りのやつ買ってもらえて嬉しい (前職では毎日リアルフォースとスリムブレードを持ち運んでいたので腰が死んだ) 。
  • そういえば Go 書きたいと言って始めた転職活動だったのを思い出したが、Go をちょこちょこ書けてて嬉しい。言語繋がりで言えば、不慣れな Ruby に挑戦出来ていてこれはこれで楽しい。
  • ちゃんとしたスクラムをしている。受託ではないからスクラムやりやすいっていう一面はありそう (前職はしばしばスクラムもどきをしていた) 。
  • 質問しやすい雰囲気があって仕事しやすい。Slack に雑に質問をすると (役に立つか立たないかは一旦置いといて) 何らかのリアクションがそれなりの速度で返ってくる。これは非常に良い体験。
  • 同様の文脈で、Slack 上で雑談がしやすいというのもある。業務と無関係な呟きをする (関係あってもいいんだけど) 個人用のチャンネル (xxxx_times、みたいなやつ) がいくつも生えていて、連日賑わっている。
  • 採用の透明さ。その気があれば採用に関わっていけるし、その気がなくても採用に関する情報はオープンになっていて「誰が応募してんのかな、どこまで行ってんのかな」とかが分かって嬉しい。
  • リモート多めの面々なので、リモートでのコミュニケーションをまあまあ前提にしてよいところは嬉しい。
  • コミュニケーションはほとんど Slack と GitHub で完結している。これはエンジニアに限らずである。人事からプルリクが飛んできてビビる日々。
    • ビジネス上の意思決定とか組織の検討とかも Slack や GitHub 上で行われているので、月並みな言葉で言えば「情報がオープン」であろうか。暇なときに眺めてはへぇーへぇーって言ってるだけだけど。
    • 社内情報を検索するときは、まず Slack、その次 GitHub、その後誰かに聞く、みたいな順番でやればだいたいヒットする。
  • 組織がフラット。フラットというか、仕事をする上で組織をあまり意識しなくて良いと言ったほうが正しいかもしれない。サービスとそれをメンテするチームがあるだけ、って感じ。
    • 横のサービスが気になったら勝手に gofmt かけてプルリク出すと喜ばれる、みたいな。
    • すべてのサービスは一個のリポジトリで管理されているので、権限的に見れないみたいなことが起こらないのも大きいかもしれない。
  • 数ヶ月に渡る結構長い育休とっている男性もそこそこの数いたりして、子育て的なところにも理解があるように見えるのも嬉しい。

ネガティブポイント

  • 謎の略語が多い (ATI、KSK、フィジビリ?) 。何度「それなんでしたっけ?」って聞き返してしまったことか…。
  • プロダクトがまあまあ大きいのに、ちゃんとメンテされたドキュメントみたいなものは皆無なのは新人にはツライと感じた。ER 図みたいなものとかモジュール構成図とかね。ドキュメントの面倒を見続けるのは大変だというのは分かりつつ…。
  • 会議室が足りなくてフリースペース的なところで軽いミーティングをすることがしばしばあるが、周りでも同じことをやってるので騒音にさらされることを免れ得ない。もうミーティングは全部オンラインでやったらいいんだ…。
  • 巨大なミーティング (キックオフみたいの) が何となく多い?これも YouTube で配信とかにしてくれたらいいんだ…。
    • とはいえ、キックオフの感想で愚痴を書いたら社長から返事がきたりする一面もあり、嬉しいところもある。
  • 職場の近くの飲食店、美味しいところが多いので無限に金を吸われてしまうし、その結果、自分の体は無限に炭水化物と脂を吸い込んでしまう。

ササッと並べてみたがこんなもんだろうか。ネガティブも並べてみたけれど “強いて言うなら” みたいな項目であり、あんまりネガティブなところ思いつかないのである。言うほど不満ないんだろうか…?不満ないとかありえる…?

Be the Worst ってやつよ

そういえば、自分のスキルセット (私はもともと組み込みソフトウェア開発をしていた、C/C++ で) は現職では結構役に立ってない印象で、Rails?slim?React?ああ何度も入門してます!みたいなノリで始まったのであるが、三ヶ月経った今でもそれほど変わってないようなところもある。おいおい 3 ヶ月たってそれって大丈夫かよ、おいら死ぬわ…。
現チームでウェブ開発のことを最も分かっていないのはきっと自分であろうと思うんだけどね。足の引っ張り具合がちょっとツライと感じるものの、どっかの本だか記事だか (情熱プログラマー (アマゾンリンク) だったかな?) に「Be the Worst」って言葉が出てきたのを思い出し。耐えればきっと自身の技術の向上もあろうと信じて、もう少し周りの人にも耐えてもらいつつ。食費を抑えつつ、引き続き頑張って行こうと思いました。まる。

20 Jun 2019, 14:52

golang.tokyo #25 @ Wantedly

2019 年 6 月 18 日 (火) に行われた golang.tokyo #25 (@Wantdly) に参加しました。

イベントページはココ

golang.tokyo #25 (2019/06/18 19:00〜)
thumbnail
# イベントについて golang.tokyo 25回目の開催です!今回のテーマは「Go の郷に入る」。 最近 Gopher になった人も昔から Gopher やってる人も、あたらめて Go を見直し Go に入り直してみましょう! # golang.tokyo って? プログラミング言語のGoの導入企業のメンバーが集まり、Goの普及を推進するコミュニティです。 トークイベント、ハンズオン、etcのイベントを開催していく予定です! # LT 参加者募集 申し込みフォーム 6/11まで、LT参加者を募集しています。 内容はGoに関連することであれば自由です。 3枠あり、枠...
https://golangtokyo.connpass.com/event/133581/

ツイッターはハッシュタグ「#golangtokyo」で検索すると、当日の実況ツイートの様子が分かります。
ツイッター検索 (#golangtokyo since:2019-06-17 until: 2019-06-19)

こういったネームカードをぶら下げての参加 (後ほど返却)
おしゃれな軽食を振る舞っていただく
アルコールの類も少々

セッション 2 つ。

今改めて読み直したい Go基礎情報 その1
thumbnail
今改めて読み直したい Go基礎情報 その1 2019/06/18 golang.tokyo #25 Yoichiro Shimizu @budougumi0617
https://docs.google.com/presentation/d/117AECfnKnKALyxHXQ0ap5yJjhB6fvg1LrGYKLagaP48/edit?usp=embed_facebook
今あらためて読み直したい Go 基礎知識 その2 / golang.tokyo #25
thumbnail
https://speakerdeck.com/izumin5210/golang-dot-tokyo-number-25
発表に対して質問をした報酬にステッカーをいただけた。嬉しい

LT は 3 つ。

golang binary hacks (golang.tokyo #25)
今日は golang.tokyo #25 というイベントにお邪魔して LT 枠で「golang binary hacks」というお題のお話をしてきました。 現地でお話を聞いてくださったみなさま、
https://l0w.dev/posts/golang-binary-hacks/
package名と変数名がかぶっているのをとにかく検出したい / I need detect to conflicts of identifier for Go
thumbnail
https://speakerdeck.com/mackee/i-need-detect-to-conflicts-of-identifier-for-go
Consider a test of image processing in Go
thumbnail
Goによる画像処理テストを考察した話
https://speakerdeck.com/po3rin/consider-a-test-of-image-processing-in-go

会場は 100 人弱くらいの入りでとても盛況。
例によって参加枠よりも多い応募があったようで、相変わらずの人気勉強会ですな。

今回のセッションのテーマは「Go の郷に入る」。
しばしば「Go らしい/らしくないコード」なんて表現されることもある気がする昨今であるが、さて実際「Go らしさ」とは一体なんなのよ?というのを、原典を当たることで振り返っていこうという回。

Go が出始めたばかりの頃の設計を紹介している記事やスライドがいくらか紹介されていったが、一環して「Go は当初から今まで基本的なポリシーを変えていない」ということが強調されていたように感じた。実際、2013 年のあたりに書かれたコーディングのベストプラクティスが今見ても古臭くないというというのは結構すごいことなのではないだろうか。
とはいえ Go はまだ若い部類の言語かと思われるので、今後もこのシンプルさが保っていけるのかっていうのは気になるところ。ぜひ Go らしさを保っていってほしい…!

ところで、「みんなの Go 言語」が改定されて第 2 版がでるという話題が出ていた。
第 1 版には、本当に「いますぐ役立つ!」という感じの記事が並んでいたので、第 2 版にも期待である。

改訂2版 みんなのGo言語
thumbnail
https://gihyo.jp/book/2019/978-4-297-10727-7

31 May 2019, 10:50

Quipper に転職した

2019 年 5 月、令和が始まるタイミングで転職した。
ACCESS → Quipper 。今度は Web Developer として主に Rails 等を触っていく仕事をする予定。

入って概ね一ヶ月が経ったが戦力には程遠くて結構あれな気持ちにはなっているものの、
急に何もかもが分かるようになるのは難しいし、徐々に馴染んでいくしかないと思っているところ。

ところで、新職場には「オンボーディング」と呼ばれる、新しく入った人が早く成果をあげられるようにするための訓練プログラム (?) のようなものがなんとなく整備されている。
そういった試みは前職にはなかったので、まずそれがあるだけでそれなりに感動であった。オンボーディングの内容自体はまだ練り上げている段階のようなので、せっかくの貴重なオンボーディング体験チャンス (当然だけど入社した直後しか体験する機会がない) であるから、よりよいオンボーディングを作る、みたいな文脈でも貢献していけたら良いなぁ等と思ったり。

Ruby / Rails に関しては未経験ではないものの、もうすっかり忘れていて戦闘能力が 0 になっている。
改めて勉強し直しているが、まあ難しいこと難しいこと。全部黒魔法に見えてくる。そのうち自分にも黒魔法が使える日が来ると信じる。

24 Apr 2019, 14:52

golang.tokyo #23 @ DeNA

2019 年 4 月 19 日 (金) に行われた golang.tokyo #23 (@DeNA) に参加ました。

イベントページはココ
golang.tokyo #23 (2019/04/19 19:10〜)

ツイッターはハッシュタグ「#golangtokyo」で検索すると、当日の実況ツイートの様子が分かります。
ツイッター検索 (#golangtokyo since:2019-04-19 until: 2019-04-23)

会場ではベイスターズ的アルコール飲料が振る舞われました
軽食 (ベイスターズ的アルコール飲料に合う) も振る舞われました
golang.tokyo #23 開幕

今回のテーマは「これから Go を始める人に知ってほしいこと」。
(実際に用いられた資料はイベントページを参照されたし)

当日使われた全ての資料のいくらかはまだ connpass のイベントページに載っていないようなので、一応本記事でもリストアップしておきます。
(以下、登壇順)

DeNA のイベントスペースらしきところでの開催であり、100 人弱くらいは集まっていたんではなかろうか。

golang.tokyo は今回で 23 回目。いつも定員オーバーになるくらいの人気な勉強会です。
今回も 74 の参加枠に対して 124 もの応募があった様子。人気。とても人気。

だので普通に参加しようと思ったら概ねの場合は抽選になってしまいますが、「ブログ枠」という「イベントの様子をブログにしたためてくれるなら参加していいよ」枠が存在します。
私もしばしばこれで参加しています。この枠だと早いもの勝ち、かつ何故か人気がない (いつもだいたい空いている) ので、参加したいが抽選にあぶれたくない人はトライしてみるのも良いのではないかと思います。

さて勉強会の様子。
今回は「これから Go を始める人に知っておいてほしいこと」ということで、セッションの内容はどちらかと言うと基礎的な内容でした。
Go の初学者の方にはもちろん有用であると思いますし、Go をやりこんでいる人にとっても諸々再確認できて非常に有意義な会だったと感じました。

前半のツール紹介は、主に Go 公式から提供されているツール類の紹介、ならびに使い方の説明でしたが、このツール類の充実っぷりは Go の特徴かと思っています。
便利ツールの諸々が野良の OSS じゃなくて公式から提供されているっていうのは安心感あるよね!ということで、知っておいてほしいツール類、必見です。

ライトニングトーク一発目の PGShohei さんは、今回が人生で初めてのライトニングトークだったとのこと。
初めてとは思えない発表クオリティにびびりつつ、その挑戦していく心意気には目頭が熱くなる思いでありました。
今回で 23 回目を数える golang.tokyo ですが、常連もいつつ、一方で新しいひともいつつ、という感じで広く門戸が開かれていると感じた会でした。

そんな golang.tokyo ですが、次回開催 (#24) が既に告知されています (2019/05/02 現在、まだ募集を開始していません) 。
golang.tokyo #24 (2019/05/20 19:10〜)

次回は Go Conference 2019 に参加できなかった勢が主なターゲット (いわゆる RejectCon) であるようなので、また濃い話が聞けるのではないかと思います。楽しみですね!
参加者募集開始のアナウンスなどは golang.tokyo 公式ツイッターアカウント をウォッチしていれば良いと思います。

最後に、ブログ枠なのにブログ書くの遅くなってほんとすんません…!イベントから二週間くらい経っちゃってますな…。
ちなみに次回の golang.tokyo #24 では「ツイッター実況枠」というのが設けられたようなので (その代わりブログ枠はなくなった) 、ツイッターの腕に覚えのある方はトライしてみてもいいんじゃないかなと思います。

13 Jul 2018, 19:15

golang.tokyo #16 @メルペイ

golang.tokyo #16 @メルペイに参加。
本日は wasm がメインテーマ。発表者と資料は末尾に記載。

そもそも wasm (WebAssembly) とは何か

以下は公式サイト。webassembly.org。
WebAssembly

公式ページからの説明を引用すると以下のように書かれている。

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications.

C/C++/Rust 等で作ったバイナリをウェブブラウザ上で動かすための規格、くらいに捉えれば良かろうか。
公式を含む各所の記事をあたってみると、wasm の存在意義としては基本的には JavaScript から比較しての軽量化、高速化である模様。

Go の wasm サポート

Go 言語も wasm へのビルド (トランスパイル) を Go 1.11 からサポートする予定であり、2018/07 現在は tip (Go の master のさきっちょ) を使うことで機能を試すことができる。
ちなみに Go 1.11 は、2018/08 にリリース予定。

Go から wasm をビルドしてみる

たとえば以下のいわゆるハローワールド的なコードも wasm 向けにビルドできるようになる。

package main

import "fmt"

func main() {
    fmt.Println("Hello world!")
}

wasm 向けのビルドは以下のようなコマンドで行う。
(上記のソースが main.go として存在していると仮定)

$ GOOS=js GOARCH=wasm go build -o hello.wasm main.go

生成した wasm の動作確認まで

動作を確認するためにはもういくつかファイルが必要であり、Go のリポジトリからコピーしてくる必要がある。
GitHub に curl を飛ばしても取得できる。

ビルドと必要なファイルを揃える処理を一式 Makefile で書くと以下のような感じになる。

WASM = test.wasm
HTML = wasm_exec.html
JS   = wasm_exec.js
CLEAN_TARGET = $(WASM) $(HTML) $(JS)

all: $(WASM) $(HTML) $(JS)

$(WASM):
	GOOS=js GOARCH=wasm go build -o test.wasm main.go

$(HTML):
	curl -sO https://raw.githubusercontent.com/golang/go/master/misc/wasm/wasm_exec.html

$(JS):
	curl -sO https://raw.githubusercontent.com/golang/go/master/misc/wasm/wasm_exec.js

clean:
	rm -f $(CLEAN_TARGET)

一式そろうと以下のようになる。

$ ls
main.go  Makefile  server.go  test.wasm  wasm_exec.html  wasm_exec.js

この状態で wasm_exec.html を何らかの HTTP Server でサーブすると、なんとなく Console に Hello world 的な文字がでることが確認できる。
ちなみに file:/// で wasm_exec.html をサーブしても正しく動作しない場合があるようで、これは Chrome が file スキームで読み込んだ HTML ファイルだと JavaScript を実行してくれないためである模様。

上記までを一式納めたものは以下のリポジトリに置いておいた。
https://github.com/pankona/go-wasm-test

各セッションを聞いて

golang.tokyo#16 の各セッションを聞いての留意点としては、

  • ベンチマークをとると、Go を JS にトランスパイルする GopherJS のほうがパフォーマンスが出る。wasm の最適化は今後の課題 (Go 1.12 以降?)
    • Chrome で動かす JS がやたら速いという一面も
  • Empscripten (C++ から wasm を作るやつ) が比較的速い
  • Go から作った wasm はまだバイナリサイズが大きい (2MB〜) という面があり、この点も今後の最適化が待たれるところ

色々まだまだな Go の wasm サポートとはいえ

ベンチマーク、バイナリサイズなどはまだ改善の余地があるとはいえ、超絶お手軽なクロスコンパイルは快適そのもの。
まだ出てきたばかり (出てきてすらいないか) なので、今後に大いに期待である。

以下、各セッションの資料を記載。

(Session1) WebAssemblyとGoの対応状況について by tenntenn さん

  • (TODO: 2018/07/17現在、発表資料がへのリンクが見当たらないので、後々更新)

  • goroutine と channel には対応。wasm にマルチスレッドの機能が入るらしい。

  • https://tip.golang.org/pkg/syscall/js を使う

(Session2) GopherJS vs GOARCH=wasm by hajimehoshi さん

GopherJS vs GOARCH=wasm

以下、ライトニングトーク。

(LT1) Go で社内向け管理画面を楽に作る方法 by yudppp さん

Goで社内向け管理画面を楽に作る方法

  • Go 歴 4 年の方。
  • Viron を使って自社向けサービスの管理画面を自動生成する話。

(LT2) Go のスライス容量拡張量がどのように決まるのか by kaznishi1246 さん

Goのスライス容量拡張量がどのように決まるのか追った / 180713 LT

  • Go 歴 1 ヶ月の方とのこと。1 ヶ月で LT しにくるの強い。
  • メモリ確保量によってクラス分けされている。
  • TCMalloc がメモリ確保量を切り上げる動作をする。

(LT3) Go言語の正規表現に後読みを実装した話 by さっき作った さん

Go言語の正規表現に後読みを実装した話

  • いまのところまだマージされていないが、上記は既に実装して Gerrit にてレビュー中。
  • マージされたら嬉しいね!