make clean; make

golang.tokyo#6@DeNA

| Comments

2017.06.01 に DeNA さんにて、golang.tokyo #6 が行われました。

golang.tokyo #6 - connpass

開幕は DeNA の方のお話だったんですが、何やら DeNA では Go エンジニアを色々募集しているようです!
サーバーのみならず、色んなフィールドで Go を使っているとのことです。

golang.tokyo-6
今日も大勢の方が参加されております。

golang.tokyo-6
出遅れて私はありつけなかったですが、開幕前からお寿司が振る舞われていました!

golang.tokyo-6
私はおビールいただきました。

Gopher Fest 2017 に参加した話 by tenntenn さん

今日は参加レポートをしてくれました。
主に 2017年8月上旬あたりにリリースされそうな Go 1.9 の話。

スライドはこちら。
https://www.slideshare.net/takuyaueda967/gopher-fest-2017

以下、話の中で気になって点のピックアップ。

言語仕様の拡張 - Alias の追加

型にエイリアスが張れるようになるとのこと。
以下のような書き方ができるようになる。

1
type Applicant = http.Client

この場合、Applicant と http.Client は等価。

いつこれが役立つかというと、型をリネームするようなリファクタリングを行うとき。
以下の手法だとうまく行かない。

(パターン1) 新しい型を作って順次移行する場合

1
type Applicant Client
  • Applicant は Client に生えていたメソッドを引き継げない。
  • キャストは可能。

(パターン2) 埋め込みを使う場合

1
type Applicant struct { Client }
  • Applicant は Client に生えていたメソッドを引き継げる
  • しかしキャストはできない

型エイリアスを用いると、

  • 両者等価なのでキャスト不要で交換可能
  • メソッドもそのまま使える、が、エイリアス側に生やすことはできない

参考

ライブラリへの変更

ビット演算ライブラリ

http://tip.golang.org/pkg/math/bits/
各種ビット演算用の某がそろっております。

sync.Map

スレッドセーフなマップが追加に。
しかも make しないで 0 値のまま使えるらしく便利。

os.Exec 環境変数をコードで上書きできるように

環境変数で指定されている値をコード上で上書きできなかった。
Go 1.9 からは後勝ち。より直感的な動作になる。コードで上書きできるように!

などなど。
スライドには出ていませんでしたが、個人的には mips32 向けの softfloat サポートがどうなったか気になります。Go 1.9 でサポートされるんだったような。

次は DeNA の方。

初めて Golang で大規模 Microservices を作り得た教訓 by Yuichi MURATA

DeNA の方です。
AndApp を作ったときに得られた教訓の話。

Gin と Echo をさまよった話でさまざま苦労なさったそうな。
失敗談をメインに話してくださったので、そういうのは割と貴重と思います。

スライドはこちら。
https://www.slideshare.net/yuichi1004/golangtokyo-6-in-japanese

教訓1. Go でフレームワークに拘ることはない。

  • Gin を使って開発を始める。
  • ちょっと困ったことがあって、一部で別のフレームワーク (Echo) を使い始める
  • 両対応しつつ、また Echo 自身の開発がホットなせいで設計がどんどん変わってしまう

というようなことで、聞いているだけでしんどい気持ちでいっぱいでしたが、
結論としては、フレームワークに頼らずに net/http 使っとくのが一番や、という話でした。
ツールに振り回されるとツライですね。納得。

教訓2. Interface を尊重する - エラーの型の話

独自エラー型と error インターフェースを混在させると起こり得る罠。
独自 error は nil 扱いされない問題。
素直に error インターフェースの利用に統一するべきだという結論。

エラーの種類によって分岐したいとき等、結構ひとによってやり方がまちまちだという気がするので、
なにがしかデファクトスタンダードなやり方が示されていると良い気がしますね。

ちなみに、自分が書くときの「エラーで分岐」については、
deeeet さんの Golangのエラー処理とpkg/errors で記載されているやり方に従っている。

regex compile / reflection の遅さ

JSON Schema でバリデーション。
OSS として扱った二種の速度の話。

  • gojsonschema
    • validation のたびに parse & compile するので遅い
  • go-jsval
    • こちらは速い

regex / reflection 等の処理は遅いので、使うときは意識しないといけない

結論

  • Go の哲学。シンプルなアプローチを。
  • 「コンパイルする言語だから速い」と過信せず、パフォーマンスに気を配ろう。

以下、LT。

ゲーム開発で必要な by @konboi

カヤックの方。
スライドはこちら

CSV の話

データの形によっては非常に見にくいCSV。
いい感じに整形してくれるツールを作った!
csvviewer

スターしておきました。

Go code Review Comments を読もう by knsh14

KLabの方。スライドはこちら。
https://speakerdeck.com/knsh14/go-code-review-comment-wofan-yi-sitahua

こういう記事があって、Effective Go 簡易版というか、Go のお作法初級編みたく書かれている。
Go Code review comments

それを日本語訳した!
* Qiita の記事はこちら

初学者のみならず、ある程度経験がある人でも読んで損はないと思いました。
認識を改めるというかね。ちなみに社内勉強会で使わせていただきました、感謝!

Scala から Go にきた話 by James さん

エウレカの方。
スライドは発見できませんでした…。

Scala が好きということは分かりました。
悲しいアリクイかわいい。

Crypto in Go by suzuki kengo さん

マネーフォワードの方。

資料はこちら。アライさんですね。
https://paper.dropbox.com/doc/Crypto-in-Go-cWLX9XxHQm6bAPqrZYkjt

難しい。

まとめ

ということで今回も参加させていただきました、ありがとうございました。
失敗談というかアンチパターンというか、そういう話が聞けたのは大きな収穫でした。

2017.06.15 現在、既に次の golang.tokyo が企画されています。
golang.tokyo #7
気になる方は要チェックです!

golang.tokyo#4@eureka

| Comments

2017.03.01 に eureka さんにて、golang.tokyo #4 が行われました。

golang.tokyo #4 - connpass

今回もまた大盛況で一般参加枠は倍率3倍くらいの抽選となっていましたが、
たまたまブログ枠が空いているところに遭遇してしまったため、またしてもブログ枠として
参加させていただきました。内容をレポートしていきます。

発表内容の詳細は、実際発表に用いられたスライド (上記 connpass のページから辿れます) を参照いただくのが一番良いと思いますので、
本記事ではその他、イベントの雰囲気や私の感想を主にお伝えしていくような体になります。
それではいきます。今回のテーマは 「concurrency」


Concurrency for distributed Web crawlers by puhitaku さん

Concurrency for distributed Web crawlers

(↑のカードをクリックでスライドに飛びます。)

AppStore と Google Play をクロールして欲しい情報を収集するやつ

  • クロール対象はシングルドメイン。だが対象となるアプリが多い (100k以上) 。

    • 同一IPからあんまりひどいことするとバンされたりする…。
    • とはいえあんまりちんたらやってるわけにもいかない。24時間以内にクロールし終わる必要がある。
  • Commander と Crawler

    • AWS EC2 Container Service を使っている。
    • 一日30弱くらいのインスタンスを立ち上げて並列でクローリングする。
  • 1 アプリあたりのクロール時間が見積もれないと困る。

    • 1 アプリあたりのクロール速度は割とまちまち。終わるの待ってたらクロール量が安定しない。
    • 一個あたりのクロールを goroutine で行う。
    • 規定時間を設ける。規定時間より超過した場合、終わってなくても次のタスクをスタートさせる。
    • という戦略で、時間あたりのクロール数を見積もれるという寸法。
  • 落とし穴シリーズ

    • TCPコネクションを使い果たす問題。並列に行われるクロールの数が多すぎると TCP コネクションを使い果たしてしまう…。
    • この問題は、make(chan int, 100) みたくして、Channel が保持する値の数を制限することで対応。

Goのスケジューラー実装とハマりポイント by niconegoto さん

Goのスケジューラー実装とハマりポイント

Goroutine の内部実装について。

Goroutine の実装デザイン

  • runtime を読む。
  • https://golang.org/pkg/runtime

  • M、G、P という文字が頻繁に出てくる。それらの意味は、

    • M … Machine
    • G … Goroutine
    • P … Processor

スケジューラーのハマりどころ

  • C 言語の pthread なんかと同じで、goroutine もコンテキストスイッチを考慮する必要がある。
  • Morsing's Blog に詳しいこと書いてある。

Ridge a framework like GAE/Go on AWS by fujiwara さん

Ridge - A framework like GAE/Go on AWS

Go で書いた HTTP Server を AWS Lambda で動かす…!

Ridge の紹介

  • Ridge
  • 実質、GAE/Go みたいなことを AWS Lambda で実現できる
  • 裏で goroutine を延々動かしておくみたいなことはできない。Lambda はレスポンス返し終わると寝てしまう。
    • 次のリクエストが来たら起きて続きの処理が行われていく
  • 頻繁にアクセスがなく、レイテンシ要求がシビアでないようなものに向く

    • サービスが終了したゲームの告知 API とか。POST を受けて JSON を返す、という処理を EC2 使わないで行う。
  • EC2 使わず、それでいてリクエスト数が多ければスケールする、ということで用途が合えば非常にリーズナブルにできる印象。


ライブコーディング by kaneshin さん

golang.tokyo-4
写真1. ライブコーディング直前の kaneshin さん

ポイント (と思ったところ)

  • kaneshin さんは vim + vim-go プラグインを使って Go を書いている模様。
  • channel をバッファのように扱っている。
  • 入力を待ち受ける goroutine と、出力を担当する goroutine とで 2 並列。 今回のテーマにあった良い題材であると感じた。

嫁に怒られずに Go を書く技術 by teitei_tk

嫁に怒られずにGoを書く技術

「嫁のため」という免罪符を得て開発していくスタイル

  • LINE に天気予報だったりを投稿する。
  • つまり生活に役立つというか家内に益があれば良いということ。
  • 夫婦円満を願ってやまない。

Gogland by Sergey Ignatov さん

golang.tokyo-4
写真2. Gogland の開発者 Sergey Ignatov さん

JetBrains から Sergey Ignatov さんが来てくれて、Gogland の紹介をしてくれたぞ!

  • function の定義に飛んで実装を確認する必要はなく、小窓で出せるような機能がある。便利そう。
  • 引数のサジェストが賢い。ファジーサーチ的に動きつつ、型が合わないものはサジェストされない、等。
  • 保存時に go fmt、 go import する機能も最近対応された。
  • 2017年3月現在は EAP 版だが、年末くらいには EAP が取れて正式版になるような予定らしい。
  • 意見・要望があったら issue tracker へ!

ざっくりですが、かいつまんで golang.tokyo 4 回目の様子を紹介いたしました。
休憩時間にはビールも振る舞われたりして、無料でいいんですかという気持ちになります。
いつもありがとうございます。

次回もまた 4 月くらいに実施されるようなので、都合が合えば参加させていただこうかと思います。

GNOMEアプリ上で日本語入力できなくなったときの対処メモ

| Comments

何が原因かハッキリしていないが、Linux をアップデート (パッケージの更新という意味) したときに
日本語が入力できなくなることがあった。

起きたこととしては、
* firefox 上では日本語入力可能 (direct input と日本語のトグル可能) 。
* Slack、chromium の上では日本語入力できない (direct input のみ可能) 。

環境は、
* Manjaro Linux (2016年12月あたり)
* fcitx を使用
* 日本語入力は mozc

方々ググって対処法を見つけたのでメモ。

dconf Editor で設定を確認し、必要に応じて修正する

dconf Editor を開き、以下の設定を確認する。
* /org/gnome/settings-daemon/plugins/xsettings/overrides を参照する
* 値に {'Gtk/IMModule': <'fcitx'>} が入っているかどうか

コマンドラインから確認する場合は以下のように入力する。

1
2
$ gsettings get org.gnome.settings-daemon.plugins.xsettings overrides
# (期待される出力) {'Gtk/IMModule': <'fcitx'>}

入ってなかったら、上記の値をコピペして設定する。
コマンドラインから設定する場合は以下のように入力する。

1
$ gsettings set org.gnome.settings-daemon.plugins.xsettings overrides "{'Gtk/IMModule':<'fcitx'>}"

当方の環境ではこれで日本語入力ができる状態になった。

参考サイト

golang.tokyo#2@はてな

| Comments

2016.12.12 に表参道のはてなさんにて、golang.tokyo #2 が行われました。

golang.tokyo #2 - connpass

今回もまたブログ枠にて参加させていただきましたので、
その内容をレポートしていきます。

発表内容の詳細はスライド (上記 connpass のページから辿れます) を参照いただくのが一番良いと思います。
本記事ではその他、イベントの雰囲気や私の感想を主にお伝えできればいいかなと思っています。
それでは行きます。


今回の golang.tokyo は 2 回目の開催。
今後も色々目論まれているようです。楽しみ。

golang.tokyo-2
図1. golang.tokyo について

golang.tokyo 2 回目のテーマは 「テスト」 について。


テストしやすいGoコードのデザイン by deeeet さん

テストしやすいGoコードのデザイン

(↑のカードをクリックでスライドに飛びます。)

golang.tokyo-2
図2. 発表中の deeeet さん。

以下、印象に残ったところを抜粋。

deeeet さんはテストフレームワークを使わない派

テストのフレームワークは使わず、testing パッケージだけで十分であろうとの意見。
これは、フレームワークは「ミニDSL」であって、導入するひとはまだしも、
あとからプロジェクトに入ってくる人は学習する部分が増えてしんどくなってしまう、という一面があるからとのこと。
納得。

テストしやすいコードとは

「Table Driven Test」 がおすすめ。
* 入出力が理解しやすい
* テストケース追加が容易
* 「Table Driven Test に落とし込めるコード」は入出力が明確でテストしやすいコード

テストしにくくなる要素とその対策

テストしにくくなるというのは「Table Driven Test」がやりにくくなる状況を指す。
→ 入力以外の要素が出力影響を及ぼしてしまう状況。

  • グローバル変数 (暗黙の入力)
    • なるべく関数の引数に入れるようにしてテストしやすくする
    • もしくは「デフォルトの値」として のみ 使う
    • 変わらないかもしれない定数っぽい値もなるべく設定可能にする
    • 環境変数もグローバル変数と同じ
  • ユーザーの入力 (コマンドを入力→期待通りに動いたか、のテスト)
    • 入力の受取に os.Stdin を暗黙的に使わず io.Reader を使い、テスト時に仮想的な入力を行えるようにする。
    • 入力に対する出力で、Table Driven にすることができるようになる。
  • ファイル出力 (ファイル出力された内容が正しいかどうか、のテスト)
    • 実際に書いたあとに開き直して中身を確認するのでもテストは可能だが、大量にやろうと思うと遅くなってしまう。
    • 入力のときと考え方は同じで、io.Writer を出力先とし、テスト時はオンメモリのバッファに出力できるようにする。
    • バッファに出力された内容とその期待結果で、Table Driven することができるようになる。

MacherelにおけるGoのエコシステムとかテストとか by Songmu さん

MackerelにおけるGoのエコシステムとかテストとか

(↑のカードをクリックでスライドに飛びます。)

golang.tokyo-2
図3. 発表中の songmu さん

Mackerel のエコシステム周りの話

  • ソースをオープンにしてパッチ受け入れるようにした。
    • ホスト先は GitHub。contribute してもらいやすい。
    • pull request に対するレビュー体制、CI が必要。
    • Travis CI、Circle CI を使っている。CI の内容は以下のようなもの。
      • go vet、 golint go test
      • coverage 計測
      • cross build 可能か
  • ちなみに Changelog はプルリクエストの情報から自動生成している。

ミドルウェアのテスト

  • 実際にテスト時に実行する
    • DB ならばモックせずに実際に DB を立ててデータを入れて確認をする、のような。
    • モックや interface でのテストでは気づけない部分もあるので、実際にやってテストする。

休憩

deeeet さん、songmu さんの発表のあと、いったん休憩に。
休憩ではピザとビールが振る舞われまして、はてなさんにスポンサーしていただいたとのこと。
ありがたくいただきました。

golang.tokyo-2
図4. ピザとビールをはてなさんから振る舞っていただく。

golang.tokyo-2
図5. 会場遠景。芝生です。

golang.tokyo-2
図6. deeeet さんにむらがる Gophers (私もこのあとむらがりました) 。

勉強会の真ん中にこういう親睦会的なノリの時間が設けられるのは珍しいかな?
なんだか新鮮でした。参加者の方とも少しだけお話できたりしました。
勉強会終わってからの親睦会だと参加できないケースが多い私のようなものにとっては、会の真ん中にこういうのやってもらうのもいいかもしれない。


ここから LT コーナー

ピザとビールで温まってきたところで LT 開始。

timakin さん

Plain db import with Go

  • timakin/gopli
    • 開発環境を本番環境に近づけるやつ。本番データをローカルに簡単にもってくる。

osamingo さん

Go で始める JSON-RPC 入門

  • JSON-RPC!

KazuhiraTogo さん

Continuous Deployment with Go on AWS ECS

  • デプロイをとことん自動化した話。
  • 本番とローカルで同じ環境を → Docker を使う。
  • Circle CI 上の docker は Ubuntu。本番は Alpine。環境の違いが問題に。 → Docker on Docker にして解決した。

以上の内容でした。せめて雰囲気くらい伝わればいいですが。
いずれの発表もとても内容が濃くて、勉強になりっぱなしでした。感謝。
ひとまず Table Driven Test ですかね。取り入れてなかったのでやってみようか等と思い。

感謝といえば、運営サイドのこと。
ほぼトラブルなしでスムーズに進んだのは、十分に準備してくれていたということだと思います。
だいたいマイクの電池が切れたりスライドがうまく映らなかったり、そういうの対策しようがなくてしょうがないところもあるんですが、
今回に関してはそういうのほぼほぼなくて、というかマイクの音量とか超ちょうど良くて、本当に細かい配慮を感じました。多謝。
他にも、アンケートを集めて次回のネタにしたりしていて (今回のテーマも、前回のアンケートでテストに関することを聞きたいという要望が多かったから、という理由で選んだとのこと)、golang.tokyo 運営すげーなという印象です。すげーな!

次回もまた来年に予定されているようです。楽しみにしています!

Linux で 無線LAN の USB ドングルを使う

| Comments

Linux と銘打っておりますが、Manjro で試しています。
本記事は Linux で 無線LAN のドングルを使えるようにした備忘録です。

使ったドングル二種

訳あって二種類のドングルを使いました。いずれも I-O DATA 製。

  • WN-AC433UM
  • WN-G150UMK

WN-AC433UM 編

とりあえずぶっ挿してみたところ、無線LAN デバイスとしては認識されなかった。
つまりデフォルトの Manjro には WN-AC433UM のドライバが入っていなかったということ。
ドライバを入れていく。

WN-AC433UM は rtl8192eu というドライバで動いた

rtl8192eu というドライバは yaourt rtl8192eu で一応インストールされるのであるが、
それだけだと WN-AC433UM は認識されなかった。

WN-AC433UM は、idVendor が 04BB、idProduct が 0959 であるが、
yaourt rtl8192eu でインストールされるドライバではこれを認識するようになっていない。
(注: 2016.11.09 時点)

なので、上記 idVendor、idProduct 値を認識するようにソースコードを書き換えた上で、
ビルド・インストールする必要がある。ソースコードは以下から入手できる。

Mange/rtl8192eu-linux-driver - GitHub
なお、リビジョンは f016814 を使った。

os_dep/linux/usb_intf.c に、以下のように追記する。
(注: 妥当か不明だがとりあえず以下の書き換えでうまくいった)

1
2
3
4
5
6
7
8
9
10
11
12
13
diff --git a/os_dep/linux/usb_intf.c b/os_dep/linux/usb_intf.c
index 5a62f24..7138a26 100644
--- a/os_dep/linux/usb_intf.c
+++ b/os_dep/linux/usb_intf.c
@@ -220,6 +220,8 @@ static struct usb_device_id rtw_usb_id_tbl[] ={
        {USB_DEVICE(0x2357, 0x0109),.driver_info = RTL8192E}, /* TP-Link - Cameo */
        /*=== PLANEX ===========*/
        {USB_DEVICE(0x2019, 0xab33),.driver_info = RTL8192E}, /* PLANEX - GW-300S Katana */
+       /*=== I-O DATA ===========*/
+       {USB_DEVICE(0x04bb, 0x0959),.driver_info = RTL8192E}, /* I-O DATA */
 #endif
 
 #ifdef CONFIG_RTL8723B

ビルドし、インストールする。

1
2
3
$ cd rtl8192eu-linux-driver
$ make
$ sudo make install

再起動すると、無線LAN ドングルを NIC として認識するようになった。

WN-G150UMK 編

上記 WN-AC433UM を認識させるにあたって散々ドライバをインストールしたせいなのであろうが、
こちらは挿しただけで認識されてしまった。

WN-G150UMK は rtl8192cu というドライバで動いている模様

もしかしたらドライバをインストールする必要があるかもしれないのでメモしておくと、
WN-G150UMK は rtl8192cu というドライバで動いている模様。lshw コマンドで確認した。

ちなみに、WN-AC433UM は 5 GHz にしか対応していない

WN-AC433UM は 5GHz 帯「のみ」に対応しており、
つまり 2.4 GHz 帯を用いる無線機器とは接続ができない。スキャンしても発見すらしてくれない。
2.4 GHz っていうのはたとえば Android 5.0 以前の Android 端末のテザリングであったり、
ちょっと古めのルーターだったりが該当する。

完全に自分の見落としであるのだが、我が家の装備はことごとく 2.4 GHz 帯を扱うモノばかりだったので、
つまりせっかく頑張って WN-AC433UM を Linux に認識させたのであるが、日の目を見なかったのである…。
悲しい。そんなわけで WN-G150UMK を書い直したが、こちらは快調に動いてます。ナイス。

参考リンク

golang.tokyo #1@mercari

| Comments

2016.10.25 に六本木の森タワーメルカリさんにて、golang.tokyo #1 が行われました。

golang.tokyo #1 - connpass

以下に togetter まとまってます。
メルカリ本社で開催されたGo言語勉強会 golang.tokyo #1 #golangtokyo - Togetterまとめ

参加者の方のまとめです。きれいにまとまっていて読み応えあります。
Hello Gophers, Hello Golang.tokyo #1 - 365 simple life - g.o.a.t

本イベントにブログ枠にして参加させていただきましたので、
その内容をレポートしていきます。

golang.tokyo-1
図1. 入り口にていただいたステッカー。にゃってとごっふぁーくん。かわゆし。

どういう主旨のイベントかと言うと

いわゆる一般的な勉強会(?)でやるような、「数人の発表者が順繰りにスライドを用いて発表を行っていく」という体ではなく、パネルディスカッション形式。
事前に収集された質問に対して、パネラーの方々が体験談を踏まえて回答をしていく、というのが主な内容。
名だたる5名のパネラーさん達の詳細については、connpass のイベントページを参照いただきたい。

golang.tokyo-1
図2. 司会の tenntenn さん。

golang.tokyo-1
図3. 向かって左正面。Songmu さん、大谷さん、kaneshin さん。

golang.tokyo-1
図4. 向かって右正面。y_matsuwitter さん、辻さん。

写真遠いし真っ黒やんけ。しかし顔で勉強会するわけじゃないということでご容赦いただければと思います。

ちなみに開始当初から軽食、おビールなんかも振る舞われており、20時前開始という、
おそらく夕飯食べてないであろう我々には、とても良い環境を提供いただいておりました。
メルカリさん、いつもありがとうございます。

本番中も質問が募集されていた

Google Apps のどの機能なのかちょっと失念してしまったのですが、
本番中も質問を次々ポストできる形式になっていて+既存の質問に対してイイねが可能になっていて、
みんなが聞きたい質問が優先的に採用されてディスカッションされるというスキームでした。

あんまり見かけないやり方だなぁと思いつつ、視聴者参加型で面白い仕組みだと思いましたので、
今後もやってくれたらいいなー、と感想を残しておきます。

そして本編 - 質問と回答集

前置きが長くなってしまいましたが、
ここからは実際どのような質問がされ、どのように回答がなされたのかを載せていきます。
※ 全部載せるとだだ長くなってしまうので、独断と偏見で端折りつつ、お送ります。

Q. メンバーの Go の教育はどうしてますか?

Go に馴染みのないメンバーにどうやって Go を学んでもらうか?というトピック。

golang.tokyo-1
図5. そしてディスカッションが始まった

Q. IDEやデバッグはどうしているか

Go でデバッガといえば delve かと思ったが、思ったより使われていないのかなという印象。
ちょこちょこテスト書いて動かしていけば、それほど難儀なデバッグが必要になることも少ないっていうことかしら?

  • songmu さん >
    • vim 使っている。メンバーが使っているのは結構バラバラ。
    • デバッグは主に print デバッグ。ちょっとコード書いてちょっとテスト書いて、みたいな。
  • 大谷さん >
    • intellij idea。何人か vim。
    • デバッグは主に print デバッグ。実際に動かしながら。

Q. コーディオング規約、レビューの指針、golint に従うか、など。

個人的には、従うと腹を決めて一度クリーンな状態になれば、あとはさほど苦ではないと思うが、はたして。

  • 辻さん >
    • コーディング規約は CodeReviewComment を基準にしている。
    • 発火させるだけの単純なチャンネルには 空 struct を使う。
    • golint はベストエフォート。というのも、3rd party ツールがが生成するコードが golint に従ってない場合もあったりするようで…。
      • golint の対象を除外は grep -v で頑張る。
  • songmu さん >
    • glint には従っている。従えば Go っぽい書き方ができてくると思う。

golang.tokyo-1
図6.songmu さん回答中。

Q. Webフレームワークとテンプレートエンジンは?ORMは?

  • 辻さん >
    • Echo。パフォーマンス重視の選択。
    • テンプレートエンジンは…標準のを使うのは結構ツラかった。フロントエンドは Go では書いてない。
    • DB のラッパーは squirrel を使っている。
  • kaneshin さん >
    • 当初は Revel を使っていたが、重量級な感じだったのでとっぱらいたかった。
      • 後に Gin で置き換えた。
      • router に gorrila/mux。もしくは標準の http。
    • テンプレートエンジンは標準のがツライ。フロントエンドは SPA を JS で作っている。
    • ORM は XORM。 一部では gorm

ところでフロントエンド事情は…

  • Go のテンプレートはツライ。
  • react とか angular とか使っちゃう。

みな口々に「Go のテンプレートはツライ」と言っていたのが印象的でした…。

Q. エラー処理どうしてますか?pkg/errors? panic は?

  • tenntenn さん >
    • pkg/errors を主に使う。
  • songmu さん >
    • panic はなるべくしないように作る。
    • goroutine の中でのエラーは、sync.ErrorGroup

sync.ErrorGroup の使い方について、
ちょうど近頃類似トピックの記事 - sync.ErrGroupで複数のgoroutineを制御するをポストされていた deeeet さん (※ e は 4つ) からのコメント。

  • deeeet さん >
    • ErrorGroup は便利。たくさんの処理があって、一個でも失敗したらご破産にしたいときに使う。
  • kaneshin さん >
    • error はエラーを上位レイヤーに伝搬させていく思想。
    • panic はしっかり使っていく派。起動直後に実行されて失敗したらどうにもならないものとかに対して。

golang.tokyo-1
図7. deeeet さん (一番奥)。

Q. Git に上がっているオススメの Go で書かれたものは?

  • kaneshin さん >
    • aws-sdk-go。コードジェネレーション部が参考になる。
    • リクエストの作り方、リクエストのリトライの仕方。パッケージの構造なども。
    • google-cloud-go も参考になる。
    • go-github も。
    • kaneshin/gate。Makefile の使い方がポイント。rake task 的な。

Q. ロガーどうしている?

ロガーは logrus が定番といった空気でした。

  • 辻さん >
    • logrus
    • zap というのもある。使い勝手が特殊な感じだが高速らしい。
  • 大谷さん >
    • Web アプリではフレームワークのロガーをそのまま使う。
    • fluentd でひっかけて Big Query に投げる、等。

Q. パッケージ分けどうしているか?パッケージ名、循環 import 問題は?

パッケージ分けは割と悩むポイントかと思いますが、はたして。

  • 松本さん >
    • ひとつのサービス内のサブパッケージは2つか3つくらい。
      • 設計上のドメイン軸で切っていく。ニュース記事・ユーザー・…
      • サブパッケージのサブパッケージ、みたいにこまかく切っていくことはあまりない。
      • リポジトリ一個一個を小さく保つようにしている。
  • tenntenn さん >
    • internal package というのもあるが、使うのをやめた。
    • 別にそこまでしなくても、例えば private とかつけておいて区別さえできればよく、またこうやっとくといざというときにも使える。

あとは、以下のような意見も。

  • Go っぽい感じを意識すると、あんまりパッケージを分けない?
  • microservice だと、microservice 同士で重複した処理が出てきたりする。パッケージ化して、service 同士で共有するか?
    • ロジックを共有すると、変更がお互いに影響してしまうので留意が必要。

Q. テスト周り

  • songmu さん >
    • 最初は標準を使っていたが、そのうち testify を使うように。
    • lestrrat さんの mysql のテストに使うフレームワークを使ったりもしている。lestrrat/go-test-mysqld
  • kaneshin さん >
    • CI 周りはツラくて常に戦っている。テスト全消化で 30 分かかったりしている。ツラミ。
      • 今の気持ちとしては、DB 周りのテストは消したい。モック使いたい。
      • GAE にデプロイするものは、全て Pure Go で動くように設計している。テストしやすいように。
  • deeeet さん >
    • フレームワーク使わない派。フレームワークは mini DSL みたいなものだと思っていて、それを覚えるのはつらい。新規メンバーをげんなりさせる原因。
    • DB 周りのテストは、interface を使ってモックする。依存している部分を interface で分ける。
    • 詳しくはここ → Golangにおけるinterfaceをつかったテスト技法 | SOTA
  • songmu さん >
    • DB のテストはモックせずに実際に DB を立ててやるべき派。
    • ロジック外の部分の問題も留意するべき。設定ファイルの関係で実際に DB にデータが入らなかったりすることも起こる。

Q. デプロイまでのフロート工夫している点。CIとか。

  • kaneshin さん >
    • ansible。dynamic inventry を使っている。

ところで、Go のビルドが遅くなる理由

Go のビルドは一般的には早いと言われているが、遅いとしたらそれは何故かと言うと…?

  • import が煩雑である。依存が連なっていて、フルビルドがかかってしまう場合。

これは例えば、A が B に依存していて、B が C に依存している、なんていうシチュエーションのとき、C を変更したら依存を遡って B も A もビルドが走ってしまう、ということが起こる模様。
ちょうど C言語の include と同じような感じかな。ヘッダー変えたら全ビルド走っちゃうみたいな。
個人的には Go でビルド速度にそれほど苦を感じたことはないが、とはいえ、留意されたしである。

Q. pprof を本番で使っている?モニタリングやチューニングは?

  • 大谷さん >
    • pprof は本番では使ってない
    • モニタリングは zabbix で監視。プロセスが落ちたら復活させたり。
    • チューニング面では、文字列を + で繋がない。とか。
  • 松本さん >
    • pprof ではなく、golang-stats-api-handler を使っている。
    • datadog でリソース監視。プロセスが落ちたらすぐ再起動するようになっている。
    • 個のチューニングではなく、横に並べられる設計でスケールできるようにしておく。札束で殴る。金の弾丸!

その他の質問

概ね、以上のトピックスでディスカッションが行われました。
他にも、回答は得られませんでしたが、

golang.tokyo-1
図8. Go言語プログラマの給料はいかほどか…

なんていう質問も出たり。
ネタも挟みつつ、終始知見に溢れた有意義なディスカッションでありました。

おわりに

運営の方々、登壇の方々、お疲れ様でした!

golang.tokyo #2 も計画されていると噂を聞きますので、
興味を持たれた方、チェックしてみてはいかがでしょうか。
Go 言語に興味さえあれば、参加して楽しいかと思います。

golang.tokyo-1
図9. 戦利品としてTシャツいただきました!

Atte Fes@mercari

| Comments

attefes

2016.04.18 に、六本木は森タワーのメルカリさん宅にて、atte fes が行われました。
アッテの開発技術をお伝えする atte FeS【Go・Swift開発編】を開催しました - Mercari Engineering Blog
本イベントにブログ枠にて参加させていただきましたので、ひとつそのレポートをば、したためます。

発表時に用いられた資料は、↑のリンク先にアップしていただいているので、参照されたし。
ちなみに、冒頭の画像は会場でいただいたデカールです。ねこかわいい。

最初にビールと軽食で乾杯

いきなり技術的な話題ではないところからなんですが、実にシャレオツだったビールブースにふれないわけにはいかない。

attefes
図1. 三種類のビールが提供されている。しかも缶じゃない。感動。

attefes
図2. 軽食が提供されている。

ビールは3種類とも一杯ずついただきましたが、とても美味でございました。
また夕飯食べずに駆けつけたものだったので、普通に空腹でありました。軽食もいただけて良かった!
おかげさまで集中して発表に耳を傾けることができました。ありがとうございました。

attefes
図3. 司会の方の音頭で乾杯。

アッテ開発の技術:
Golang と Google Cloud Platform (鶴岡達也さん)

さて、発表内容について。

attefes
図4. 鶴岡さん

ひとつめは鶴岡達也さんによる「Golang と Google Cloud Platform」。

発表の具体的な内容は実際に資料をご覧いただければ分かると思いますので、
本記事では私が印象に残った箇所について触れていくことにします。

なぜ Web アプリ開発に Go/GAE を採用したか?

さまざま理由があったようですが、個人的には、
「3年後にもエンジニアにとって魅力的な場所であるため」 に、多様性と技術の開拓の意味もふくめての採用であったというのが印象的でした。
そういうふうな文化があると、エンジニアにとって満足感が高い職場になっていくんじゃないかなー、等と。
とてもいいと思いました。ええ、弊社でもぜひそうしていきたい…。

Go言語はチームで開発しやすい

私も個人的にちょいちょい Go 言語を触りますが、ほんとに周辺ツールの充実っぷりが凄まじい。
lint、コードフォーマッタ、変数名には Go 言語公式のポリシーが存在する、等。
チーム開発に採用すれば、やれインデントが〜とか、インポートの順番が〜、とかをソースレビューに持ち込むこともなくなる。
そういう点も学習コストを下げるのに役立っているかな。Go 言語、私もオススメです。

GoDoc を有効に使う

GoDoc は概ね常に最新に保っているとのことで、つまり、
「API を使いたいひとはとりあえず GoDoc 見て」で済んでいる、らしいです。
チームで開発しやすい、効率化という面で GoDoc を有効に使えている例かな、と。
ドキュメントをおざなりにしないところ、素敵です。
またこういうドキュメンテーションのためのツールが提供されているのも Go 言語のいいところ。
Go 言語、私もオススメです。

GAE のインスタンスは 200 ms で立ち上がる

速い!この速さはオートスケール時にとっても活きてくる模様。
アクセス過多でスパイクしてもあっとうい間に平穏を取り戻す図は、私の心にも平穏と興奮を与えるものでありました。

その他の話題、RDB vs NoSQL、DataStore の良いところ、等

他にも興味深いトピックについて話されていました。
ぜひ、スライドを直に見ていただければと。

アッテ開発の技術:
Swift と RxSwift (大庭慎一郎さん)

attefes
図5. 大庭さん

正直に言うと Reactive Programming というものがほぼ分かってない私ですが、
発表は非常に興味深く聞かせていただきました。Reactive Programming ええな!

Swift の採用を決めた経緯

Swift を採用した経緯について。そもそも流用する資産がなかったとのことで、
だったら色々機能の豊富な Swift にしましょうよ、ということだったと思います。

Objective-C は、それはそれで今まで蓄えられたノウハウが Web 上に豊富に転がっていたりして、いわゆる「ハマりにくさ」では Swift より上のような気はする。そういう意味では Objective-C にも良いところはあるだろう。
とはいえ、Swift と Objective-C、どっち採用したらテンションあがるかと言われれば、やはり Swift であるかなと。3年後もエンジニアにとって魅力的な場所を醸造しているひとつかもしれない、等と思いつつ。

リアクティブプログラミングに頼るとプログラミング能力が下がる?

プログラミング能力が下がるは言い過ぎかも?
スライド上のサンプルコードは短く完結にわかりやすく書かれていて、いったん慣れてしまったら辞められない的なものを感じた。
なるほど、馴染んできたら普通のプログラミング (?) のやり方忘れちゃうかもしれないですね。

とはいえ学習コストは高い模様。
質疑応答では「急に全部ではなく、部分的に採用していくこともできる」と。
データバインディングから始めるのがやりやすいのではないか、と仰っておられました。

リアクティブプログラミング 参考サイト

スライド中でも触れられていますが、リアクティブプログラミングについては以下のサイトが理解の助けになったとのこと。
【翻訳】あなたが求めていたリアクティブプログラミング入門 - ninjinkun's diary

以下のページでは、Reactive な動き (Stream) を図で理解できるようになっています。
RxMarbles - Interactive diagrams of Rx Observables

アッテ開発の技術:
アッテ iOS の設計と開発フローの変遷 (石川洋資さん)

attefes
図6. 石川さん

同じ構造の実装の一元化

よくある同じ構造のもの、 ページネーション、フォームのバリデーションであるとかの共通化の話。
MVVM でいうところの VM 部分で、共通するGenericな部分 + 型スペシフィックな部分は型パラメータもらって作る、という構造の紹介。
特にページネーションは、10回書いたら7回くらいバグってるくらいのバグを埋め込みやすい部分らしく、
共通化することで、「高速な開発で、かつ安全」な設計に近づくことができたとのこと。

新しい設計を試すのは、場合によっては難しいことだと思う。
つい、いま動いているところは触りたくない、以前作ったものと同じような構造が出てきたら踏襲する、等と
してしまいがちな昨今(ですよね)、飽き足らず、より良いモノ作ろうぜという熱気にあふれている、等と感じておりました。
素敵だ。

自動デプロイの話

ご多分にもれずというか、やはり iOS アプリも自動ビルド/自動デプロイをなさっている模様。
構成要素としては、
* Travis CI (CI 時間は7分くらい)
* agvtool でビルド番号を振る (Xcodeに付随)。
* DeployGate (dev) と TestFlight (prod) にデプロイ

また、その他の作法として、
* 手元でのアーカイブはしない。
* QAが通ればそのまま審査へ

というのが紹介されていました。

ビルドとかデプロイ、あと審査もだと思いますが、ものすごく属人化しがちな部分であると思う。
「病気で倒れても誰でもデプロイできる」 と仰っていましたが、これって本当に大事なこと。
作業をひとにロックインしない工夫をしていかないとね。属人化は不幸の始まり。

ところで CI に掛かる時間が7分って結構早いような気がしている。
早さ、特に CI とかそういう常日頃から何度も繰り返し行われる事柄の早さは重要。

何も考えずにそこそこの規模の iOS アプリビルドしたら、結構時間かかっちゃうと思うんだよね。それこそ10分くらい余裕で。
さらっと7分って言っていましたが、ここにはきっと色々な工夫がなされているんだと想像します。

その後

attefes
図7. 懇親会。みな思い思いの方を捕まえては話し込む。

attefes
図8. 懇親会。運営おつかれさまでした。

おわりに

Mercari からスピンアウト (?) した SOUZOH という組織は、なんというか、
新しいやり方をどんどん取り入れていて、エンジニア的にはテンションあがる環境であるという印象でした。
それで実際うまいことやれているっていうのは、なお凄いことかな。

そんな感じで、おいしいビールをいただきながら学ばせていただいた atte fes でございました。オススメは Tokyo White。
運営の方々、登壇の方々におかれましては、大変おつかれさまでございました!

ASUS ZenPad 7.0 (Z370C) レビュー その三 : イマイチなところ編

| Comments

前回に引き続き、ZenPad 7.0 (Z370C) のレビューを記事にする。
今回は、1ヶ月程度使って感じた ZenPad 7.0 に対するフラストレーションについて。
つまりイマイチな点に触れていく。
感触良い点については前回の記事で触れているので、ぜひそちらも見てね。

タッチの精度・感度がいまいち

これはもしかしたら初期不良の類かもしれないが、とにかくタッチが微妙である。
「一度タップしたのに効かなかったのでもう一度タップしてみる」、みたいなことがしょっちゅうである。

あとはロングタップ、いわゆる長押しであるが、これがとても不安定である。
一点をタップし続けているにも関わらず、タップ位置がぐらぐらずれてしまったり。
長押しに関しては、何度かトライしているとそのうち成功したりするが、かなり気を使わなければならないのが残念なところである。

※ ネット上のレビュー記事を見ていると同様の報告は見当たらなかったので、、、私が持っている端末限定の現象の可能性もある。

動画再生には向かない

性能の問題であろうが、比較的高ビットレートな動画の再生には耐えられなかった。
カクカクになったり、音だけ進んで絵がついてこない、等の現象が起きるケースがあった。
16:9 の画面は動画再生には良いので、この点は仕方ないと思いつつ、若干の残念感はある。

ちなみに、ニコニコ動画のエコノミーならいけます。

ゲームも概ね向かない

こちらもお察しいただけるかと思うが、昨今のぐりぐり 3D が動くようなゲームはほぼ動かないと言っていい。
タブレット界隈のベンチマーク的な存在である○ ○マスターとかも一応試してみたが、、厳しかった。
そういうのをプレイしたいひとには本当にオススメ端末なので、注意されたしである。

極軽い処理で済むゲーム、将棋とかそこらへんだろうか、であれば動作すると思われる。

SIM が挿さらない

これは不満点とはちょっと違うが、惜しいと思う点。
SIM が挿さらないので、ネットワークに関しては WiFi での運用となる。
移動中のネットワークに関しては、スマホのテザリングか何かで解決してあげる必要がある。

とはいえ、SIM を使いたかったら、SIM が挿せる ZenPad 7.0 (Z370KL) があるので、
そちらを求めるのが正しい。ちなみに性能も Z370KL のほうが若干良い模様である。

総評

3つの記事にわたって、ZenPad 7.0 (Z370C) の見た目、良いところ、いまいちなところについて記事にした。
性能がいまいちだったり SIM が挿せなかったりという不満点はあるものの、
値段が安いため、用途がバッチリ合えば非常にコストパフォーマンスの高い良機種であると思う。

個人的には、引き続き使い倒してやろうと思っているので、また何か気づいたことがあれば記事にしようかな、と。
前回までの記事で紹介できなかった画像をそえつつ、今回はこのへんで。

Z370C
ZenPad 7.0 with ZenClutch 開いてみたところ。片手で持つのに手頃な大きさのタブレット。

Z370C
ZenClutch は渋め。「ASUS COLLECTION」と印字されている。渋め。

Z370C
側面。電源ボタンとボリュームボタンが配置されている。カバーつけてしまうとちょっと押しにくい。
ただ、カバーあければ自動でスリープ解除になるので、あまり押す機会はないかも。

ASUS ZenPad 7.0 (Z370C) レビュー その二 : 良いところ編

| Comments

前回に引き続き、ZenPad 7.0 (Z370C) のレビューを書いていく。
今回は、1ヶ月程度使って分かってきた ZenPad 7.0 の使用感について。

性能はぶっちゃけいまいち

1ヶ月使って、使わなくても分かることかもしれないが、性能は正直物足りないと感じる。
何かにつけて動作がモタモタするというか。Chrome 起動に0.5秒くらい掛かるとかそういうの。
ZenPad 7.0 のスペックそのものは公式ページを参照されたし。

みんな大好き Antutu ベンチマーク的には、20000点弱くらい。これは Nexus 7 (2012) とドッコイな感じ。
そりゃーいまどきの OS 乗っけていまどきのアプリを動かせば、重たく感じるのも無理はないかな、と。

とはいえ、1万円台で購入できるタブレットであることを考えると妥当とも思える。
逆に言えば、性能をそれほど必要としない使い方をする分には問題にならない。

なので、 「この使い方をすれば快適」 というのを今回は紹介していく。

Web ブラウジング

いわゆるネットサーフィンをする分には、それほどストレスを感じることはなかった。
※ ページが重かったらキツイ。

普段は 5 インチのスマートフォンを使っている私であるが、
やはり画面が大きいほうが文字も見やすいし、目にも優しい。

スマートデバイスの主な用途がネットサーフィンの方はかなりいると思うが、
そういう用途では使用に耐えうる、むしろ快適、となるんじゃないかと。

Z370C
Yahoo を表示してみた様子。画面が広いため表示できる情報量は多い。

電子書籍

16:9 の画面なので電子書籍には若干不向きかもしれない(画面上下に黒帯が出てしまう)が、
これもやはりスマートフォンの 5 インチ前後の画面で見るのに比べれば、見やすさが雲泥の差である。

Z370C
漫画も読みやすい。スマートフォンだと読む気が起こらなかったが、これならイケる気がする。

フォトビューア

写真をタブレットで見るのは定番かもしれないが、やはり大きめの画面で見るのは良い。
昨今のスマートフォンは高解像度な写真も取れるし、Google フォトの同期を活かして、
撮るのはスマホ、見るのはタブレット、みたいにしていくスタイルもオススメ。快適です。

Z370C
写真を表示してみた様子。とても見やすい。かわいい。

大きさが手頃なので電車内でも快適

上記の用途は、私の場合は主に移動中に行うことになるのだが、
前回の記事で触れたように、7 インチという大きさが手頃で持ちやすく、電車のお供してとても優秀。
ついでに ZenClutch で滑りにくいこともあり、片手運用も可能。片手つり革でも大丈夫。

FEP は ATOK

実は ATOK がプリインである。常日頃から ATOK ユーザである私にとってこれは朗報。
というか ATOK 買っているのでプリインじゃなくても良かったんだけど。ATOK オススメ。
これは ZenPad のレビューではない気もするが、ATOK プリインの ZenPad オススメ、ということで。

電池のもちは普通

そこかしこの記事で Z370C はバッテリーのもちが悪い、と言われているような気がするが、
やたら電池を食うような使い方をしない限り、充電しないで丸一日はもつ程度には動いてくれる。
私にとってこれは十分なので、バッテリー面で特に不満を感じることはなかった。

ということで

使い方が間違っていなければ(変な期待を持たなければ)、性能がいまいちとはいえ、
十分快適に使っていけるポテンシャルを持っているという印象でした。
今回はこのへんで。… 次回はだめな使い方を紹介していく。

ASUS ZenPad 7.0 (Z370C) レビュー その一 : 見た目編

| Comments

ZenTour2016 にて ZenPad 7.0 (Z370C) を入手するに至った。
ASUS様より無料でいただいた形であるが、レビュー記事をしたためることが条件である。

ので、ここから3つ、ZenPad 7.0 (Z370C) のレビューをしていく。
まず見た目、次に使ってみて良いところ、最後に使ってみて悪いところ、について
書いていこうと思う。

というわけで、見た目編、行きます。

ZenPad 7.0 (Z370C) を見よ

こちらが Z370C with ZenClutch である。
以下はオモテ面。なお、大きさのイメージが伝わりやすいように近くにポンジュースを配置している。

Z370C

今回は本体だけでなく、周辺アクセサリであるカバーもいただいている。
ZenClutch。結構高いんだよこれ。いやほんとに。値段の甲斐あってか(?)、さながら高級財布のような佇まいである。
以下はウラ面。

Z370C

この ZenClutch であるが、本革のような雰囲気があり、なんというか、手触りが良い。
ただ、タブレット本体を使う際にはカバーを開いて本体の背面側に折り返す関係上、
タブレット使用中はおそらくその手触りの良い部分に触れることがない。滑り止めにもなりそうなのだが。
少し残念であるが、とはいえ小脇に抱えて持ち歩くにはとても良いことには変わりない。

大きさは持ち運びにはちょうどいい

ZenPad 7.0 (Z370C) は名の通り 7 インチのタブレット。大きさ的には Nexus 7 シリーズとほぼ同等。
Nexus 7 よりも若干薄いかな、と。

Z370C

そして軽い。公称値は 272 グラム。ZenClutch を着せているので若干重たくなるとはいえ、やはり軽い。
このくらいの軽さであれば、かばんに入れておいても全く気にならないレベルであると感じる。

カバーをあけると自動でスリープ復帰

電源ボタンを押さずともスリープから復帰するのはなかなか快適。
電源ボタンがへたって故障する心配もない点も大きいと思う。
ちなみに当然、カバーをしめたら自動でスリープします。これも快適。

ベゼルは狭め

ベゼル、特に左右の枠は狭めであると感じた(他のタブレットと比較したわけではないが)。
以下の画像で伝わるだろうか。

Z370C

この点も見た目のスタイリッシュさに寄与している点ではないだろうか。

見た目に関する総評

見た目に関しては、高級感があり、大きすぎず、軽く、画面もまあまあ大きく使えていて、良いとこばかりと言っていい。
値段が1万円台であることを考えると、こと見た目に関してはお値段以上であると思われる。見た目オススメ。

ただ、性能に関してはちょっと色々あるので次回の記事で書こうと思うが、、、
性能さえもう少しイケていれば、間違いなく誰にでもオススメできる機種だったと思う。惜しい。
今回はこのへんで。次回は性能について。