mapyo blog

日々やった事をつらつらと書くブログです

現職を退職した

途中で気がついたら会社が変わりつつも、 2018年くらいからざっくり2年半くらいは働いてたので、軽くまとめておく。

Androidエンジニアからサーバサイドエンジニアに

2018年の転職のタイミングでサーバサイドエンジニアになった。

動機

アプリだとどうしてもサービスの一部分しか見れないという印象を感じてしまっていた。 サービス全体を見ながらサービスの今後の事を考えながらやっていくにはサーバサイドかなぁと言う感じ。 これは会社やチームによっては違うと思うので一概にそう言えるかどうかはわからないけども。 サービスの立ち上げや、立ち上げ付近から大きくする経験をしたい。という指向性が少なからずあるので、 そうなった時はやっぱりサーバサイドだなという感じ。

他にも、アプリだと毎年のようにGoogleから新しいアップデートがあり、 公式がおすすめする手法も新しいものがどんどん出てくるので、キャッチアップし続けるのは結構大変そうだなーと思ってた。 サーバサイドに来てみたら、クラウドサービスは結構な頻度で新しいものが出てたり、アップデートされていくので、これもまた同じような感じではあったw

よかった事

そんなこんなで運良くサーバサイドのエンジニアとして入社出来たのはよかった。 オンプレでPHPや、副業でRails、Herokuな経験は今まであったのだけど、 クラウドサービスをいろいろと使ってサービスを作り上げていくという経験はしたことがなかったので、 非常に良い経験になった。 主にGCP、GAE、GKEとかがメインだった。AWSもlambda、SAM、IoT、Enterprise Buttonとかもろもろ触る事が出来て、 完全未経験から脱却出来たのはよかった。 インフラ専任の人がいる状況ではなかったので、自分たちでインフラ作って自分たちで監視やアラート周りなども含めて面倒を見ることが出来たのでよかった。

とはいえ、スポット的なプロジェクトでAndroidアプリ開発したりもしたので、それはとてもいい思い出。

今回の転職活動でも、サーバサイドの経験がより深まったので転職の選択肢が広がったのは非常に良いことだったし、今後もあまり技術にはこだわりがないようにしつつも、サーバサイドを主軸にやっていきたい。

課題

課題としては、Androidバリバリ出来るわけでもないし、サーバサイドも経験年数的にはまだまだな感じで、サービス全体のアーキテクチャを設計する。みたいな事はできなかった。 ゆるふわフルスタックエンジニアという感じ。 フロントエンドとiOSの経験を積めばフルスタックエンジニアと名乗ることが出来るかもしれない。フロントエンドやFlutterなどは機会があればやってみたい。

サービスの立ち上げ付近で、サービス全体のアーキテクチャの設計をして、何度も失敗して、またその失敗をバネに次に活かす。みたいなことをいっぱいやりたい。

テックリードやりました。とか、エンジニアリングマネージャーやりました。みたいな経験も特に出来なかった。肩書にこだわるわけでもないけど、個人として成果を出す事よりも、チームとしてどうやればより成果が出せるのかみたいな事を考えていかなといけないのかなと思う。

プロダクトオーナーの経験

3ヶ月とかそれくらいの短い期間だけだったけど、Androidアプリのプロダクトオーナーをやっていた。

こんな感じで作りますみたいな文章を書いたり、 パワポで雑にUIを作ってみて、デザイナさんに見てもらったり、 実際に使ってもらうユーザに話を聞いて仕様を固めたり、 なんなら軽く動くサンプルを作ってみて、こんな感じの動きになると思うんですがどうですかねー。 という事もやったりした。

コードを殆ど書かなくて、プログラマーとして大丈夫だろうかw? みたいな不安もあったけど、とてもよい経験になった。

 Node.js

なんやかんやでNode.js、GAEなコンポーネントを引き継いで、リリースまでもっていくという事があった。 Node.jsをガッツり触るのは初めてだったし、何から手を付けていくのがいいんだろうかと思った状況だった。

まずは、CI/CD周りを整備。 そしてRepositoryパターンを導入してテストを書いて、ElasticseachやRealtime Database周りの動作確認をサクッと出来るようにしたした。 その後ユースケース層を作ってRepositoryを差し替えてユニットテストを書きやすいようにしたりした。 期限があまりない中でどうやって優先順位つけて対応していくか考えることが出来た。

期間的には4〜5ヶ月くらいだったろうか。単純な開発だけではなくて、いろいろと他の人とやり取りする事も多くて、とても良い経験になった。

Go, gRPC, GKE

Goは現職(退職したので現職ではないけど)に入ってから初めて業務で使うようになった。 AndroidでKotlinを使って書いていた身からすると、最初の頃は物足りなさがめっちゃあった気がするけど、慣れればそうでもなく、書きやすいなーと思うようになった。 自分の中では愚直に書いていくという思想な気がしていて、そっちのモードに切り替わったらそれはそれでいいなと思うようになった。Go wayに関してはまだまだちゃんと理解できているとは言い難いけども。

gRPC、protoファイルをベースに自動で各種言語にコンパイルされてライブラリとして配布される環境が整っており、これが非常にやりやすかった。 ハマりどころとしては、Updateの時の部分更新周りはGoのゼロ値の事もあって、ちゃんとAPI設計を考える必要があるので、 https://cloud.google.com/apis/design/standard_methods#update この辺の事は目を通して置いたほうがよいかなと思う。

GKE、いろいろと初めてだったので楽しかった。また、GKEでk8sに初めて触れたけど、k8sの難しさをうまくGKEがカバーしてくれてる点もあるので、EKSとか触るとよりその理解が深まるのかなと思った。 DeploymentManagerでインフラ周りは管理していたのだけど、 https://www.terraform.io/docs/providers/google/r/container_cluster.html default_node_poolの事を最初に知っていればもうちょっといい作り方が出来たのになという後悔があった。

会社が変わった

労働承継とかいうやつで勤め先の会社が変わった。今までにない経験だった。 良くも悪くも、あくまで自分はただの従業員なんだなと実感した出来事だった。

改めて自分の人生とはみたいな事を考えるいいきっかけになった。 まぁ、考えてもそこまでいい答えはでないので、引き続きいい感じにやっていくしかなさそう。

今後

9月は有給消化、10月は無職で、9月も含めると2ヶ月はのんびり過ごす事になるので、 会社員に戻れるのか正直不安w 11月からは次の会社で働きます。なんやかんやでAndroidまたやる事になりそうです。勘を取り戻さないと〜。

GitHubで特定のブランチへの直pushを防ぐ

https://help.github.com/ja/github/administering-a-repository/enabling-branch-restrictions

このドキュメントに書いてはあるのだけど、最新のGitHubのUIとは変わってたので実験

設定箇所

Settings→Branchesのところで、保護したいブランチを入力し、以下の画面を設定する

f:id:mapyo:20200326015341p:plain

f:id:mapyo:20200326015345p:plain

実行結果

-> % git commit --allow-empty -m 'sample'
[master cc43a55] sample

-> % git push
Enumerating objects: 1, done.
Counting objects: 100% (1/1), done.
Writing objects: 100% (1/1), 190 bytes | 190.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0)
remote: error: GH006: Protected branch update failed for refs/heads/master.
remote: error: At least 1 approving review is required by reviewers with write access.
To ssh://github.com/mapyo/GolangSample.git
 ! [remote rejected] master -> master (protected branch hook declined)
error: failed to push some refs to 'ssh://git@github.com/mapyo/GolangSample.git'

無事、regectされるのだった。

所感

ブログを最近書かなくなったので、細々したやつでも書いていこう

mysql2のbundle installに失敗する時

mac上でbundle installした時に、以下のようなエラーが出て失敗する事がある

Fetching mysql2 0.5.3
Installing mysql2 0.5.3 with native extensions
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.


    current directory: /Users/mapyo/tmp/mysql2_sample/vendor/bundle/ruby/2.6.0/gems/mysql2-0.5.3/ext/mysql2
/Users/mapyo/.anyenv/envs/rbenv/versions/2.6.4/bin/ruby -I /Users/mapyo/.anyenv/envs/rbenv/versions/2.6.4/lib/ruby/2.6.0 -r ./siteconf20200113-35739-1ltnc8d.rb extconf.rb
checking for rb_absint_size()... yes
checking for rb_absint_singlebit_p()... yes
checking for rb_wait_for_single_fd()... yes
checking for -lmysqlclient... no
-----
mysql client is missing. You may need to 'brew install mysql' or 'port install mysql', and try again.
-----
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.


Provided configuration options:
        --with-opt-dir
        --without-opt-dir
        --with-opt-include
        --without-opt-include=${opt-dir}/include
        --with-opt-lib
        --without-opt-lib=${opt-dir}/lib
        --with-make-prog
        --without-make-prog
        --srcdir=.
        --curdir
        --ruby=/Users/mapyo/.anyenv/envs/rbenv/versions/2.6.4/bin/$(RUBY_BASE_NAME)
        --with-mysql-dir
        --without-mysql-dir
        --with-mysql-include
        --without-mysql-include=${mysql-dir}/include
        --with-mysql-lib
        --without-mysql-lib=${mysql-dir}/lib
        --with-mysql-config
        --without-mysql-config
        --with-mysql-dir
        --without-mysql-dir
        --with-mysql-include
        --without-mysql-include=${mysql-dir}/include
        --with-mysql-lib
        --without-mysql-lib=${mysql-dir}/lib
        --with-mysqlclientlib
        --without-mysqlclientlib


To see why this extension failed to compile, please check the mkmf.log which can be found here:


  /Users/mapyo/tmp/mysql2_sample/vendor/bundle/ruby/2.6.0/extensions/x86_64-darwin-17/2.6.0-static/mysql2-0.5.3/mkmf.log


extconf failed, exit code 1


Gem files will remain installed in /Users/mapyo/tmp/mysql2_sample/vendor/bundle/ruby/2.6.0/gems/mysql2-0.5.3 for inspection.
Results logged to /Users/mapyo/tmp/mysql2_sample/vendor/bundle/ruby/2.6.0/extensions/x86_64-darwin-17/2.6.0-static/mysql2-0.5.3/gem_make.out


An error occurred while installing mysql2 (0.5.3), and Bundler cannot continue.
Make sure that `gem install mysql2 -v '0.5.3' --source 'https://rubygems.org/'` succeeds before bundling.


In Gemfile:
  mysql2

対応方法としては、--with-mysql-config のオプションを指定して、bundle configを実行してあげればよかった。。(パスは各自適切な場所になおしてください)

bundle config --local build.mysql2 "--with-mysql-config=/usr/local/opt/mysql@5.7/bin/mysql_config"

オプションは、これを1つだけ指定しないとうまくいかなかった。  最初はwith-mysql-dir などを雑につけてみて試してみていたのだが、それだとbundle installは成功するがその後実際に使う場所でエラーが出てしまった。。。

mysqlの最新のバージョンじゃないものをbrewで入れていて、それを使いたかったからこういうエラーが出てしまうのかもしれない。

というか、READMEをよくみてみるとちゃんと説明が書いてあったので、それを読めばすぐわかったのかもしれない。。

参考文献

2019年振り返り

既に年明けてしまったけど、今年をざっくり振り返る

2019年の振り返りはこちら

mapyo.hatenablog.com

Android

1〜3月くらいはスポット的なプロジェクトでやってた。 このタイミングだけやったけど、めっちゃ変わってるなぁと思った。 変化のサイクルが非常に早い。

Go

そこそこは書けるようになってきたと思うけど、Goらしさとは何かがちゃんとわかってない気がする。 もっとガシガシコード書いて、他の人のコードを見て修行する必要がありそう。

GCP

めっちゃ使うようになった。 以前よりは詳しくなった気がするけど、まだまだという感じ。

何か新機能を作るときには、GCPにどういうサービスがあるか把握しつつ、 適切にサービスを選択しながら開発を進めていくスキルが必要だと思う。

Googleのカンファレンスで発表される情報を随時キャッチアップして、 今後の動向を見据えつつ選択が出来るとよさそう。

Androidやってる時はGoogleの動向に気を配りつつキャッチアップしていく必要があったけど、 サーバサイドやったとしても、引き続きGoogleの動向に気を配っていく必要がありそう。

GKE、Kubernetes

そこそこわかってきたような気もするけど、深くはわかってない気もする。 いろいろと理解するのは難しかったけど、わかってくると楽しい。

requiredDuringSchedulingIgnoredDuringExecution みたいな設定値があって、めっちゃ長いやんという気持ちになった。

 Deployment Manager

嗜む程度に使ってる。微妙に理解したような気がするけど、まだまだ使いこなせてないと思う。

Redis

Redis Streamsとか使ってた。XREADGROUPとか、XACKとか。

gRPC、gRPC-Web

使ってる。便利。ブラウザからもgRPCが使えるようになるといいのになぁ。

ブログ

2019年は3件しか書いてなかった。年々アウトプットが減っている。。。 雑なアウトプットだとしても継続的に書いていかないとなぁ。。。

まとめ

振り返ると、2019年もいろいろとやった気がする。新しい技術もいろいろと触れて楽しかった。 一方で、深く理解できたかといわれるとまだまだ足りないなという感じ。 使っていく以上は胸を張って使いましたといえるレベルになりたい。

技術的にはいろいろと楽しかったのだけど、もっと根本的なエンジニア力みたいなものが上がっていないな。という気がする。 そもそも、それって何なのだろうか?方向性として、自分はどういうところにいきたいのだろうか? というところも含めて2020年はそれを考えていく1年になりそう。 RPGでいうと、武器や防具を購入して攻撃力や守備力は上がったけど、ステータスとしてのちからや、みのまもりは上がってない感じ。

他の人がどういうキャリアを辿ってきたのか、それぞれの節目に何を考えてどう行動したのか。に興味があるから、機会があればその辺の話を聞いてみたい。

ktlintをAndroid Studio上で自動で実行してフォーマットしてくれるようにする

モチベーション

ktlintいいのだけど、pushしてからCIが回ってコメントついてから修正するよりも、事前に手元でわかるのであればわかるようにしたい。

とはいえ、毎回手元でktlintを実行するのはちょっとだるいので出来れば自動でいい感じになおして欲しい。 理想はAndroid Studioの方でktlintに沿ってないコードを書いた時に警告が表示されて、option + enterで自動でなおってほしい。しかし、そんなプラグインは現状調べた限りではなさそう。

やること

File Watchersを導入してktlintコマンドを使って定期的に実行する。

1. ktlintコマンドのインストール

brew tap shyiko/ktlint && brew install shyiko/ktlint/ktlint

2. File Watchersをインストール

pluginの部分で、 File Watchers と検索してインストールするだけ

3. File Watchersの設定

以下のように設定する。

f:id:mapyo:20190204103006p:plain

ポイントはAdvanced Optionsのところのチェックをすべて外すとよいかもしれない。

一番上の Auto-save edited files to trigger the watcher の部分にチェックが入っていると、ファイルを編集してauto saveが発動されたタイミングでktlintが実行されてしまう。

これはちょっと修正して考えている間に勝手にファイルがフォーマットされてちょっとうざいのと、ktlintが発動してフォーマット中にファイルを編集すると、メモリ上にあるやつと、フォーマットした結果のファイル、どっちが正しいの?というダイアログが毎回出てきてつらい。

弱点

この方法は完璧ではない。

  • ktlintが発動して、完了するまでが長い。6秒くらいかかる。一瞬で終わって欲しい。
  • 僕はターミナルからgit commitするからいいのだけど、IDEでCommit Changesしてる人は、command + kで出したタイミングでktlintが発動するので、コミットした後にフォーマットされてしまう。ターミナルからでも6秒くらいかかるので、一瞬でgit commitしてしまうと、commit後にフォーマットになってしまう。
  • ktlintのコマンドインストールしないといけない。そもそも、Android Studioでいい感じにやってほしい気持ち。

その他

やってもよさそうなこと

https://github.com/shyiko/ktlint#option-1-recommended

こちらにのっている、おすすめの設定の適用をする。

ktlint --apply-to-idea-project --android

以下のファイルが生成されるため、これをgit管理しとくといいかもしれない。

./.idea/codeStyles/codeStyleConfig.xml
./.idea/codeStyles/Project.xml
./.idea/inspectionProfiles/profiles_settings.xml
./.idea/inspectionProfiles/ktlint.xml
./.idea/workspace.xml

しかし、codeStyleConfigなどはすでに設定してたりするとバッティングしそう。

やってもいいかなと思ったけど、僕はやる気になれなかった事。

ktlint --install-git-pre-commit-hook

これでpre-commitに追加してくれて、commit前にチェックしてくれる。 しかしながら、これはcommitする時にちょっと処理が遅くなりそうなのと、エラーを出すだけで、自動でformatしてくれなかったのでやめた。 もうちょい様子をみて、やるかどうかは考える。

所感

もうちょっといい感じにAndroid Studioが何かしてくれたらいいなぁと思いつつ、自分で出来そうな事を考えてみた。 Androidアプリ開発は基本的にはAndroid Studioを使って開発する人が多いと思うので、それ前提で考えられるのがいいな。もっといい方法をご存知だったらどなたか教えてください。

ktlint、jvmで動いてそうだから実行が遅いのかな?

参考資料

2018年を振り返る

去年の年末〜今までにかけて、久しぶりに風邪をこじらせてしまって1週間くらい長引いていて、年末年始は殆ど何もしなかった。。。 今更だけど、振り返ってみる。

さて、2018年の目標はなんだっけかとブログを見返してみたのだけど、特に目標は立てていなかった。

参考までに、2017年の振り返りはこちら

mapyo.hatenablog.com

ざっくりいろいろと振り返ってみる

 DroidKaigi 2018での発表

Usb接続するアプリを開発した時に試行錯誤した事

USBのネタで発表した、しかし最新のOSではまた変わっている気がする。 去年はこれでしか外には発表していない。 何気に3年連続で発表できてた事が自慢だったのだけど、 今年はサーバサイドな人間なので今回はCFPを出すこともしなかった。

転職

去年で一番大きな出来事。 Androidエンジニアからサーバサイドエンジニアになった。 USBとか、BLEとか割とニッチなことやってて、やめてしまうのはもったいない感もあったのだけど、スパッとやめてサーバサイドに。 たまにKotlinのコードが恋しくなることもある今日このごろです。

Golang

ガッツリやることになるだろうかと思ってたけど、微妙に嗜むくらいしかやらなかった。 初級者なので、この辺は引き続きガッツリかけるようになりたい。

Node.js

ひょんなことから、Golangよりもこちらをガッツリ触るようになっていた。 Kotlinでずっと慣れてた自分にとっては型が欲しい気持ちが溢れていたが、ある程度慣れてくるとそこまでは思わなくなった。 しかし、ちゃんとテスト書かないとすぐ壊れそうな不安感はある。

雰囲気で書いている。

今までの僕はレスポンス作るためのクラスに一旦マッピングするのが普通だと思ってたけど、 オブジェクトから簡単にjsonが生成できるので、その特徴は生かしてコードを書いていった方がよいような気もしていた。 この辺は割とブレながら書いていたと思う。

今回はJavaScriptで書いてたけど、今度Node.jsで作る時はTypeScriptを使って書いてみたい。

クラウドサービス

AWSGCPを使うようになった。この辺もまだまだ初級者な感じがするので引き続き頑張っていきたい。

昔はベンダーにロックインしないように作る事が正義だと思っていた自分があるけど、 ちゃんとそのサービスの特性を理解して、寄り添う感じで使うのであれば全然ありなんじゃないかなとも思ってきた。 新しく何か作る時はむしろそっちが推奨されそう。 ただ、大きめのサービスになってくるとロックインされないようにするのも必要なのかもしれない。 その辺もうまく含めてマイクロサービス化して作っておくのもいいのかもしれない。

Androidやってて、技術の移り変わりが早いし、ベンダーの意向にめっちゃ左右されるなと思ってたけど、 サーバサイドになったらなったで、クラウドサービスを提供しているベンダーの意向に左右されるし、技術の移り変わりも激しいので、 どこへ言っても一緒という感じ。

 Elasticsearch

雰囲気で使えるくらいにはなってきた。 位置情報検索とか、普通のテキスト検索とかで使ってた。

なんとなくだけど、サービスの立ち上げ期にはこれでがっと作っといて大きくなってきたら別のものに置き換えていくのかなぁという感じがしている。

 AWS IoT エンタープライズボタン

誰でも簡単に使えるけど、使ったり、嗜んだりした。 こういうのを使って、自分ちをめっちゃ自動化したい気持ち。

POっぽい何か

途中、自分では作らないけどアプリの仕様を決める立場も経験した。 ひたすら、文章かいたりしてる時期が続いてた。コードは殆ど書いてなかった。 たまに、Googleスライド編集したり、めっちゃ簡単なアプリのプロト作ったり、調整的なこともしてた気がする。

ブログ

2018年は13件しか書いてなかった。2017年は29件で、段々と減少傾向にある。 今年は少なくとも50件くらいは書きたい。

体調

去年の年末までは殆ど風邪を引かなくて、、年末に久しぶりに風邪を引いてこじらせて今に至る。 インフルエンザになってないのがせめてもの救いだけど、全然風邪を引かない人になりたい。

iPhoneXを購入した

Androidエンジニアということもあってか、Android端末しか使ってこなかったので、iPhoneというものを使った事がなかった。 今は立派なiPhoneユーザ。もしGoogle Pixel 3がもっと早く日本で発売されていれば、そっちにしてたかもしれない。

モバイルSuicaを初めて使ったけど、今ではこれなしでは生きられない体になってしまった。

最後に

という感じで2018年を振り返ってみた。 2017年もいろいろと変化が多かったけど、2018年もいろいろと変化が多かった気がする。 さて2019年はどういう年になるのだろうかー