golang.tokyo #12に参加してきた
概要
Go言語の勉強会であるgolang.tokyo #12にブログ書く枠で参加してきたので発表内容や感想などを書きます。
今回の発表テーマは『スタートアップ・新規事業におけるGo』
発表から2週間以上経ってのアウトプットと遅くなってしまい、乱文ではありますが書いていきます。
golang.tokyoについて
公式の文言を引用すると次の通りです
プログラミング言語のGoの導入企業のメンバーが集まり、Goの普及を推進するコミュニティです。 トークイベント、ハンズオン、etcのイベントを開催していく予定です!
Goコミュニティには次のように「初級向け」「中級向け」「上級向け」と勉強会が分かれて用意されていて、golang.tokyoは「中級向け」の内容となっている。
- Goビギナーズ
- golang.tokyo
- Go Conference
私のGoレベルですが2017-08に開催されたGo言語初心者向けハンズオン#4の参加からGoを始めた、 Go歴6ヶ月のエンジニアで業務ではPHP, C#, Node.jsを使用していて、まだまだビギナー枠に位置するのかと思っています。
しかし、、、
- Goビギナー向けハンズオン参加
- goでアプリ作ってみる
- Goビギナー向けLT会で発表
という流れを踏み、次のステップへ移行してみようという事で今回golang.tokyoに初参加してみました。
発表1
資料
登壇者
@sonata
内容
スタートアップではGAE/GOが良いという話でオートスケール、OSの管理が不要でプロダクトに集中出来るのが良い。
スタートアップはエンジニアが少ないので、限られたリソースはアプリケーションの設計、ビジネスロジックに割きたい。 技術選定はシンプルを目的としている。GAE/SEをアプリケーション毎に環境構築する。
GAE/SEではL3ネットワークを考える必要がない。自動的にドメインが割り振られる。サービスの分割をしているがソースコードは全サービス共通。adminサービスはGoogleOAuth認証を使用。
マイクロサービスの必要性はメルカリの「オーナーシップを持つため」という考え方がとても良い。 マイクロサービスの弊害としてはコード管理、ログ管理など検討事項が増える。エンジニアが3人なのでサービスではマイクロサービスは導入していない。少人数な限りモノリシックでやる。 GAEではバージョン毎にURLが作成されて、バージョン毎にブルーグリーンデプロイができる。マイグレーションを使用してるがデプロイ直後にヘルスチェックして、200が返らなければマイグレーションしないようにしてる。
レイヤーアーキテクチャを採用して、サービス毎にアーキテクチャの決定に価値を持っている。正しいDDDを目的としない。アーキテクチャの決める目的をはっきりさせて、目的達成しているかで判断する。
フレームワークの選定
- ミドルウェア
- ルーティング
上記を満たすgo-chiを選定
ライブラリ選定
- gorp
- gorm
@mattn_jpさんも使っているので安心感がある。
APIのプロトコルの選定
gRPCを採用。RestfulAPIはURLの設計が苦労の割にメリットがないと考えた。プロトコルバッファー on httpを採用。定義ファイルを使用したいのでgRPCを採用。定義ファイルからGo, Swift, TypeScript, javaなどのソースコード生成出来る。 gRPCは設計が楽との事。http-methodはPOSTのみで設計。ただgRPCはデファクトスタンダードではないので他社にAPI公開には向かない。URLとmethodは同じなので、bodyを見てどの処理をしたいかを判断。ただcurlで気軽に確認しづらい。Twitch製のRPCフレームワークを使った。
http client
Chome ExtensionのPostmanを使っている。環境変数を設定できるので便利。アクセストークンを設定して変数で使いまわせるしswaggerも必要ない
config
app.yamlで設定するのがGAEではセオリー。envconfigというライブラリを採用。
セキュリティ
Cloud Key Management Serviceで暗号化して保存してる。
開発環境
コマンド操作オンリー。WEBコンソールから操作すると操作履歴が残らないのでコマンド一択。操作はshでまとめている。
CI
CircleCI使っている。travisからCircleCIに移行したら速くなった!
発表2
資料
登壇者
@shinofara
内容
MF KESSAIとは?マネーフォワードの子会社。BtoB資金繰り改善をフォーカスしたサービスを提供する会社。
請求業務プロセスをサービスとして代行する。フローの手間をシステム化。相手が倒産してもMF社が保証する!創業から11ヶ月立ったのでノウハウを発表する。 エンジニアが2名。PO兼エンジニアとインフラ兼エンジニアで開発してる。
Goを採用した理由
お金に関わるので型は厳格にしたい。言語移行コストは下げたい。 Goは誰が書いてもソースが似てくるのがメリットである。などなどの理由から採用した。
FrameWork選定
フレームワークは使わず薄く作る方針で。足りない部分はライブラリを導入する事で効率的に。 test, lint, vetは最初から導入。
Dockerを採用した理由
環境の同一性担保のため
GCPの採用理由
インフラエンジニアがいなくても運用しやすい。Stackdriverの存在。Kubernetesの採用。
開発初期
とくにユーザーがいなかったため、社内ツール作成から開始した。
企業向けサービス開発期の話
エンジニアの新規メンバーのアサイン。社内APIはgRPCを採用。プロトコルバッファーの定義を使いまわせるのが利点として採用。社外向けにはRestfulAPI。goaを採用して使っている。認証はKongを採用。
現在
運用フェーズなので、モニタリング、エラートラッキングなどを見直し。
スケーラブルなPDF発行の仕組み
最初はバッチ処理で直列でPDFを作成していた。そこからpub/subで作成するようにしたら1時間とか掛かっていた処理が数分になった。 サーバーレスにしたかったけど、docker(kubernetes)が対応してなかった?
プロメテウスなどのモニタリングも検討したがストレージ管理などのタスクを開発フェーズ的にやりたくなかったため、DataDogというクラウドサービスを使用。 可能な限り自社開発せず、有り物のサービスを使う方針。この割り切りは良い!
振り返り
新規事業にgoを選んでみて。仕様変更がかかった時にコンパイルがあるので壊れてる事に気がつけたのは良かった。CIやtestツールを初期に導入しておいてよかった。レビューのムダを省略。チーム開発に向いている。疎結合な言語設計。
Goを使用したデメリット
- Go未経験者がいると、使用していた言語にある機能がない!など、意見の衝突が起きた
- WebUIを作るのには向いていない。Webテンプレート操作が苦しいため管理画面作成などには向いていない
- エラーハンドリングで記述量がそれなりに多くなりがち
- IDEが必要になりそう
- if err != nil ...が手間に感じた
Lightning Talk1
資料
登壇者
@cnosuke
内容
SRE at お金のデザイン社。THEOというサービス運営してる。
Go + gRPC - いくつかのアプリ向けAPI - いくつかの社内向けAPI kubernetes - GKE 開発用クラスタ - AWS 本番用クラスタ
金融系でKubernetes使っているのは、僕らだけじゃないかな? 金融系はサービスを止められない。止めると金融庁へ報告が必要だったりする。
ssh/portfowardingが面倒だった。kushiというツールを作った。sshの設定が面倒。他の人も設定が必要で面倒なので作った。ymlで定義する。
Lightning Talk2
資料
登壇者
@Seiji Takahashi
内容
AWS lamdbaがGoを採用した。今まではapexで書いていた。今は公式パッケージであるaws-lambda-goを使う。 apexからaws-lambda-goへの移行は容易。違いはそんなにないので移行しやすい。ただ、aws-lamdba-goはdeployがawscli経由。 aws-lambda-goのソースコードを追っていく。reflectionの応用例では参加者から笑いが起きたり。
Lightning Talk3
資料
登壇者
@Shohei Koyama
内容
元FPSプロゲーマーで現在はボヤージュグループでSREをしているそう DBの接続情報はどこで管理してる?aws Sysmtem Manager SSMを使ってみよう。 yaml-ssmというツールを作った。パスワードをdecryptする。デモ発表など。
所感
Goビギナーからのgolang.tokyoの初参加であったが、発表内容のレベルが高くどの話もとても面白かった。 個人的には@shinofara氏の発表に一番興味をもち、スタートアップ企業(MF Kessai社)が「創業初期」「導入企業向けサービス開発期」「現在」とビジネスフェーズにどのようにGoやシステム・アーキテクチャを採用するに至ったか、どのように判断するに至ったかの話がとても参考になった。 Goを採用したいと考えているが、どこに対してどのように採用するのか悩んでいる方はこのスライドは参考になるのではないでしょうか。
皆さんgoの強みを最大限活かしているという印象でした。
golang.tokyoで発表できるようになるにはまだまだGoレベルが足りないため、開発実績を積んで行かねばという気持ちを持った所存です。
P.S 今後は勉強会に参加した翌日にはブログを書こう!(反省)
カフェでPC作業してみた感想
カフェでお仕事やコーディングしている人の話を耳にしていたけど、自分は試した事がなかったので5日間やってみての感想を書く。
5日間でしたこと
コーディングをしようと思ったが転職ドラフトを試してみたくレジュメを書いていた。 会社帰りにあるタリーズにて、60〜90分位作業した。
思ったより集中できた
レジュメを書く時もやった事の振り返りや文章を推敲したり、なかなか集中力が必要な作業だった。 タリーズはフリーwifiもあったので、とても良かった。
集中できる前提条件 (個人の感想)
- 周りの音を消すためイヤホンは必須
- 大声で話をしてる人が側にいない事
- 視界に人が入らない事
デメリット
- コーヒー代が毎回必要
- うるさい人が近くにいると終了
まとめ
色々なカフェがあるとは思うが、自分としては作業には向かないと思った。 理由は憩いの場なのでおしゃべりしたい人も来ると思うし、作業に特化した環境ではないため、 作業するならコワーキングスペースに行こうという感想
まぁ個人の感想なので参考になれば
2018年の目標を
ずいぶん遅くなったけども2018年の目標を書いてみる。全部達成したいがひとまず列挙
英語を習得
- 文法学習から始める
- 英会話始める
- 英語限定、勉強会とかに参加する
- TOEIC800点目指す
インフラに強くなる
- OS, DB, Webなどサーバチューニング周り
- TCP/IPなどネットワーク周り
ISCON参加
- GoかNode.jsのいずれかで参加する
Goで開発経験
- 個人開発で使用しているので、業務で使える現場に行く
カンファレンス登壇
- GoかPHPで登壇する。それぞれの言語で2回登壇する
個人サービス開発
- 1個ネタがあるのでリリースする
アウトプット
- 1週間に1記事書く。Qiita or ブログ
新しいプログラミング言語習得
投資
- 続・株式投資を。目標利益150万。仮想通貨はハイリスクな感じがあるので余裕が出来たら
所感
具体的なアクションがない目標が多いが、まずはリスト化。 個人開発以外にプライベートな予定などもTrelloで管理しているので、タスク化はそっちでやる! 2018年の末に振り返りをしたい所存。
最近読んだ本の感想
本の内容をすべて覚えてないのでかなり掻い摘んで感想を。
まんがでわかる 7つの習慣
ビジネス書のバイブルと言われる、7つの習慣をわかりやすくマンガでまとめた本。 原書は読んでないが、仕事を楽しむため取り組み方・考え方を伝える本なんですかね。 マンガなのとページ数がそんなにないので、仕事にマンネリ、工夫がなくなった時にチラッと読むとやる気が出てよいかも。 どのビジネス本にも言えるけど、実践しないとインプットして終わりです。
SOFT SKILLS ソフトウェア開発者の人生マニュアル
色々なエンジニアさんがオススメしてる本。「翔泳社ITエンジニア本大賞2017」の技術書部門ベスト10にもノミネートされた本。 プログラマー・エンジニアとして生きていくに辺り、技術以外のスキルやテクニックが書かれている。 雇用形態の違い、給与交渉、出世方法、燃え尽きた後の回復方法、マーケティング知識、筋肉、食事、不動産投資、恋愛とか、色々な事に関して書いてある。 kindleで読んでるが、まぁ内容が分厚い。全部読もうなどと思わず、自分に必要と思う箇所だけピックアップして読むと良いかと。 僕は給料交渉の方法を真っ先に読んだ笑。まぁ、入社時の給料交渉の話なので今の査定システムでは使えないのかなぁ。 まだ全部読んでないけど、ちょこちょこ気がむいたら読もう。 元々英語本で翻訳されたものなので、日本の環境と少しことなる箇所があるかも。
僕たちは「会社」でどこまでできるのか? ~起業家のように企業で働く 実践編~
元野村証券の方で会社に属した状態で、新規ビジネスサービスを立ち上げた話。 上司を敵にして良い事はないよー。正論はごもっともだけど、人間は論理的ではなく感情で動く生き物だよ。物事の進め方ってあるよね?とかを説いたり、上司へのアプローチ方法、同志を巻き込んだ方法が書いてある。
新規ビジネス立ち上げ!とか大きな事に当てはめなくても、新しい役職の提案、新規技術の導入提案、業務フロー改善提案、とか実現したい事がある時に、著者が実践した上司や同僚への対応テクニックは参考になるのでは。
ITエンジニアが覚えておきたい英語動詞30
こちらも「翔泳社ITエンジニア本大賞2017」のビジネス書部門ベスト10 にノミネートされた本。 著者はMicrosoftのシニアプロジェクトマネージャーとの事。
まだまだ触りしか読んでないけど、この動詞をおさえておけば大体英語で会話できちゃうよという本。
名詞よりも、動詞を使った方が自分の意図が伝わるんだよ。I want ... we need...とか、動詞まで言えるようになったら相手に何をしたいのか?は伝わるので、名詞で会話が詰まるよりずっと良いんだよーという事が書いてあった。 ふむふむ。何か説得力を感じた。この動詞だけまずは抑えておけ!と30個位単語が載っているので、これを抑えれば喋れる気がする。(気がする)
また本読んだら感想文を書く
2017年の俺生活を振り返る
2017年も終わりに近づいている。経験した事、成長した事を確認するためにもちょっと振り返ってみる。 2017年のざっくりとした目標は次のような感じであった。
2017年の目標
- 英語話せるようになる
- 株で儲ける (目標90万)
- 個人のWebサービスをリリースして儲ける
- 副業してお金を稼ぐ
2017年の目標に対する結果は次のような感じ。所感も含めて書く。
目標に対する結果
英語話せるようになる
「英語学習に取り組んでみて」というようなブログ記事を何個か読んだだけで具体的な学習アクションはほぼなし。 社内勉強会に参加したくらいかなぁ。あ、でも技術フォーラムで質問したり回答したり、翻訳ソフトを使いながらだが英語でやり取りする耐性がついたので これは大きな前進と受け止めよう。具体的なアクションを作らないと英語学習などやらない事がわかったので2018年は具体的な目標とそれに対する予定を立てる所から!
株で儲ける (目標90万)
証券会社をたくさん開設し、IPOに何件か応募し、ゲーム系会社を中心に株取引を始めた。 IPOは全然当たらないのと、口座にお金入れたり、ログインしたりめんどくさくなってで途中で応募しなくなってしまった。 株取引は儲けもあったけど手数料とか損失とか含めると5万位マイナスじゃないかなぁと。でも株投資を始めたのを前向きに捉え、2018年も引き続きやっていく。
個人のWebサービスをリリースして儲ける
今、作っている途中で止まってしまっている。。。詳細は伏せるが2018年はリリースしたい。
副業してお金を稼ぐ
副業としてオンラインプログラミングスクールの講師をやってみたが、3ヶ月で辞めてしまった。 テキストチャット・ビデオチャットで質問を受けて回答したり、提出された課題のチェックをしたりと楽しい点もあったが 時給の安さと業務時間外でもチャット見たり、いいかげんな対応はしたくないので結構準備に時間がかかったりと割に合わないと感じたのが辞めた理由。 土日に働いていたけど業務脳をリセットできずに月曜に入るのでそれも辛かった。副業より投資の方が自分には良い。
エンジニアリング実績
2017年に業務と個人で取り組んだエンジニアリング実績を書き出してみる。
業務開発
- 社内向けComposerライブラリを開発
- Node.js、TypeScriptでWebSocketを使用したシステム開発
- Gatlingを使ったWebSocketシステムの簡易負荷テスト
- Photonクラウド、Amazon GameLift、ゲームクラウドサービスの使用
- AWSのサービスを色々使えた
- 社内向けのLaravelチュートリアル作った
個人開発
- Go言語を始めた
- 翻訳ソフトを使いながら英語フォーラムで質問や回答などした
- 複数ツイートを一括削除するLaravelアプリ
- 上場企業がドメイン登録した際にSlack通知するGoスクリプト
- GCPでスケジュール実行
- 最後はいつ?の模倣Webアプリ(WIP)
- Slackで勤怠処理できるHuBot作った
- Lineソーシャル認証サービスプロバイダ
勉強会とか登壇とか
- LaraCafeでLT発表
- LaraLabでLT発表
- PHP勉強会東京でLT発表
- LightningTalkLoversでLT発表
- GoビギナーズLT大会!でLT発表
個人的な事
- 新型MacBookPro買った
- ブログ、LTなどアウトプット増えた
- 尿酸値に引っかかった
- 転職ドラフトに登録してオファーも貰えた
- 眠っていたtwitterをアクティブにした
総括
「お金を得る」という所が行動の源になったと感じた。お金を目的に行動するのはとても良くないと考えていたが、自分のスキルアップや行動力アップにとても良かったと感じてる。お金があると本を沢山買えたり、色んな体験に投資できたり、使い方によっては人生がとても豊かになるので、安売りせず今後も意識を高めていきたい所存。
外部勉強会や社内勉強会でもアウトプット出来たし、Githubにも多少草を生やせたので来年はもっとアウトプットを増やす! あまり使っていないtwitterを再開したのは技術コミュニティと触れ合う機会が断然増えたので、これは本当に良い影響であった。 悪い影響もあり、業務中に気になってtwitterを見てしまうので集中力が落ちたと感じている。メリハリをつけて利用していきたい。
アウトプットという事を意識し行動できた1年であった。そして振り返ると色々と成長できた気がする。 エンジニアリングもNode.jsを始めてからモダンJSに対する知見も増えた。jQuery脳で止まっていたのと苦手意識も解消されて大きなメリットがあった。
個人開発でGoに取り組んだが、言語の文法学習はそこそこに「作りたいものドリブン開発」で学習するのが良かった。文法学習は楽しさが薄れて継続しない事が多かったのだが、作りたいものを目的に取り組むととても捗ったのでこの指向は続けていく。
個人開発物も何個が出来たので2017年は良かったよ。うん。 2018年の目標はまた別のポストで。(所要時間50分)
書きたいことめっちゃある
主にエンジニアリングの知見に関して、めっちゃ書きたい事あるけど、 Evernoteに溜め込んだ知見を外部に公開する時間を考えると、最初の第一歩を中々踏み出せない。 どれから手をつけて行こうかと悩んで日々が過ぎていく...
自分の手元だけメモが沢山ある人って、結構いるんじゃないだろうか?
面倒くさいと思うことなど、「10分だけやろう」と思い立って行動するのがとても効果がある事を知った。 そして、それを習慣化できるスキルが、すっごい重要なスキルであると知った。
この記事も技術的な事ではないがアウトプットする習慣をつけるために、とりあえず書いてる。
インターネットのお陰で今があるので、「自分の知識や経験なんて大した事ないー。」と卑下せずに、 アウトプットしてどなたかのお役に立てばと行動していきたい。
しかし、一番の目的はアウトプットは自分のためになる!からやるのである。
あと、アウトプットに要した時間も記録するようにしよう。 なるべく短い時間でアウトプットできるスキルが身につけたい。
やるで! (所要時間15分)
筋トレから起きる価値観の変化
筋肉 Advent Calendar 2017の11日目を担当します。k-kurikuriです。
最近、エンジニア界隈でも筋トレしてる人多いですよね! 僕も1年半ほど週一でジムに通って、ウェイトトレーニングをしてます。
ジムに行くたび肉体的成長を感じられるので楽しく続いています。
筋トレを始めるて見ると、様々な価値観の変化が起きました。 どんな変化があったのか書いていきます。
生活の中心に筋肉がいる
まだまだムキムキには程遠い僕ですが、生活をする上で筋肉をとても意識するようになりました。
特に食事です。炭水化物・脂質・タンパク質の量が気になるようになりました。
タンパク質に関してはグラム単位で気になるようになりました。
例えば、コンビニでご飯を買う時に「おっこれは14gも入ってるのか」とか、
「あぁ5gだけかぁ...」とか思うようになりました。
うん。なんかこの後何書けばいいのかわからなくなったので、箇条書きでまとめちゃいます。
筋トレによる生活の変化
- プロテインを飲むようになる
- 食事のカロリー、栄養素を意識するようになる
- 空腹を我慢しないようになる
- 筋トレ直後は謎の全能感が沸き起こる
- 体重が増える事に喜びを感じる
- 睡眠時間を確保するようになる
こんな感じです! 筋トレいいよ。皆もやりましょ!