私の考えるスーパーエンジニア
はじめに
これはポエムです。自分が目指すエンジニアとはなんなのか向き合いたいと思い書いてみました。殴り書きです。
スーパーエンジニアの振る舞い
- スーパーエンジニアは誰よりも早くリリースができる。機能のヒアリング、要件定義、設計、開発などひっくるめて誰よりも早い。
- スーパーエンジニアはプロダクトを作るための技術を知っている。インフラ、DB、サーバサイド、フロントエンド、モバイルを、完全なできではないものの一通り一人で作ることができる。
- スーパーエンジニアはビジネスサイドの人間と会話できる。作りたいものを一緒に考えられる。
- スーパーエンジニアはネガティブでない。常に自分の力で状況を前に進められる。
- スーパーエンジニアは最新技術をキャッチアップしている。枯れた技術と最新技術の選定のバランスが良い。
- スーパーエンジニアは適切な設計ができる。場合によってそれなりな設計ができる。変な設計や必要以上に凝った設計をしない。
- スーパーエンジニアは体力がある。いざというときにハードワークできる。
- スーパーエンジニアは家族を大切にする。それによって自分が仕事に集中できる状況を作ることができる。
- スーパーエンジニアは人に仕事を任せることができる。人を信頼し、エンパワーし、適切なフィードバックを与える事ができる。
- スーパーエンジニアは問題解決をする。やり方は問わない。
参考
自分の尊敬するエンジニアの振る舞いを元に、以下の記事をみながら書きました。
まとめ
スーパーエンジニアになるため、１歩１歩進んでいきたい。
ブログ名変更&https対応した
内容
長らく迷っていたブログ名を「ITの勉強をいろいろやってみたブログ」から「blog.waterlow.work」に変更しました。
はじめは資格試験の勉強などをアウトプットしていく予定でしたが、2014年転職したりなんやかんやで方向性が変わりました。
それから長らく名前は放置していましたが、この度思い切って。
ブログ名はurlっぽいけど、叩いても何も出ません。
（https://waterlow.work/ は今はHetlifyでGatsbyをうごかしてます。）
ついでにurlをhttps化しました。混在コンテンツも全部https対応or削除しました。
最近いろいろもんもんとかんがえていることがあって、いろいろ吐き出していきたい。
今年触った技術
はじめに
もう10月末となり、今年触ってきた技術を列挙してみようと思います。
結論言うと、思った以上にいろいろ触ってきたものの、あんまり身になっている実感がないという感想。
基本的に趣味で、本番投入はしていません。
（普段のおしごとではrailsのサーバサイドを担当しています。）
インフラ編
docker, Kubernetes
railsをk8s化しました。特にこれといったことはありません。。。社内勉強会と自宅学習を合わせるとかなりの時間触っていると思う。
GitHub - waterlow/docker_sandbox_qdqgrstwtz
ミドルウェア編
opencv
名刺サービスに携わっていて、多少なりとも画像処理ができるようになりたいと思ったため。
docker向けにコンパイルするのがひたすら難しく、結局挫折してしまいました。。。
vpsのcentosでpython(flusk)画像の矩形を切り取るサーバーを書くところまで。
GitHub - waterlow/opencv-sandbox
mongo, spark
「ビッグデータを支える技術」の本の中でバックエンドとして扱われており、dotinstallをやってからsparkをさわりだけつかってみました
PAAS編
Netlify
技術書店で本を買っていろいろやってみました。かなり高機能。
NetlifyCMS、hosting、CIを試しました。
Firebase
主にfirestoreとfunctionを触っています。railsに続く自分の武器になる予定。予定。 firestoreの設計（というかNoSQL）にはRDBとまたちがった感覚があり、苦戦中。
AWS Lambda
cloud watch eventと合わせるとcronをサーバレスで実現できるということで、試してみた。 serverless frameworkでやろうとしたけど、functionだけ書いてcronは手で入れちゃっている。
ssh接続を許可するipリストの管理をするのにも使用。
slackからのwebhookを受けられるようにAPI Gatewayと連携している。
IFTTT
これは含めていいのかわからないけど、会社の勤怠を自動化するために、GPSで会社の出勤退勤をspreadsheetに記録するために使用。
Amazon Athena
友達にデータ分析を試してみたいと相談され、まず一番手軽なところからということで使ってみる。
都道府県ごとの郵便番号のデータをzipのままS3において、そこに対してSQLで集計をかけられるという体験はすごい。
後述のredashにも接続できる。
インストール系
redash
データ分析の文脈で、athenaのデータをビジュアライズ。docker化したい。
wordpress
友人の相談でメディアサイトを作りたいと言われ、ちょっとだけ触ってみる。
docker-composeで立ち上げられるようにしてみた。
webアプリとセッション共有をしたいと言われるも、php詳しくなく断念。。。
フロントエンド編
mobx
reactの状態管理のライブラリ。reduxよりもライトに使えるというか、ルールがきつくない。 reduxのサイトにあったtodoをmobx& firebaseで作ってみた。
vue
rebuild.fmのshownoteをフィルタリングするwebアプリをvue2系&webpackerで書き直した。
GitHub - waterlow/rebuild-search
nuxt
勉強中。firebaseと合わせてtwitterみたいなものを作っている。まだ理解できていない。
GitHub - waterlow/nuxt-sandbox
gatsby
Netlify文脈でさわってみた。とりあえずデプロイしてみた程度。
JAMStack
Javascript、API、Markupの略
SSRするHTMLを先に生成してCDNに乗せておけば、SSRより爆速になるという考え方。
技術的にはあまり触っていないものの技術書典の本は1冊読んだ。
ReactNative
WEBDBに載っていたお天気アプリをつくってみた。
（やったと言えるのか。。。）
まとめ
いろいろやりすぎ！！！と思った。
深掘りというか、ちゃんと手に馴染むところまで持っていけてないのが残念。
nuxt, firebase, redashあたりは手に馴染むところまで持っていきたい。
OKR本を読んだ
はじめに
OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法
- 作者: クリスティーナ・ウォドキー,及川卓也(解説),二木夢子
- 出版社/メーカー: 日経BP社
- 発売日: 2018/03/15
- メディア: 単行本
- この商品を含むブログ (1件) を見る
OKRの本を会社から支給されました。大事なことは原典を読んでいただくのが良いですが、気になったところを書いてみます。
スタートアップでもミッションを掲げるべき
どんなに夢のあるようなビジネスでも、マネタイズしなければ意味がないというのが自分の考えでした。しかし「お金がほしいなら、ウォール街のコンサルティング企業に入社するほうが遥かに安全だ。」という言葉をみてなるほどとおもいました。マネタイズは大事だけど、同じくらいミッションというか使命みたいなものが大事だと思います。
自信度の変化のトラック
今の会社でもOKRを取り入れていますが、自信度の変化をトラックしていません。はじめは50%でも自信度は刻々と変化していくため、OKRを振り返るためにも自信度の変化は重要であると考えました。
健康、健全性
これは、「利益に走りすぎて、エンゲージメントを失う」とか「締切を守るあまり、メンテナンス性の低いコードをリリースしてしまう」といった状況への抑止になると感じました。KRを達成さえすればそれでいいというような状況はなくなりそうです。
まとめ
OKRについて、まだまだ知らないことがあるなということと、これを遂行するにはメンバーのメンタリティも重要のように思いました。 あと、これとは別に「仕事はたのしいかね？」という本も読んでいてうーーーんという感じでした。
そもそもRailsでカスタム例外を定義すべき機会は少ない
はじめに
今仕事でRailsアプリケーションの運用をやっているのですが、いろいろなところで例外が定義されていて「これ必要なくね…」となんとなく思ったことが多々ありました。 しかし、effective rubyには「raiseにはただの文字列ではなくカスタム例外を渡そう」という章もあり、この違いはなんだろうと思いました。 なんでそう思ったのか整理して、今後自分のプログラミングに生かして行こうと思います。まとめると以下になります。
- カスタム例外を自分でraiseしてrescueするな。戻り値で判断しろ。
よく見るコード
Resourceモデル
class Resource Error = Class.new(StandardError) def write # 何かの処理 result = false # 何かの処理の結果falseだったと仮定 raise Error, '保存時にエラーが発生しました。' end end
Resourcesコントローラ
class ResourcesController < ApplicationController def create Resource.new.write redirect_to '/', flash: { notice: '作成されました' } rescue Resource::Error => e redirect_to '/', flash: { error: e.message } end end
よく見るコードがあまり良くない理由
- 処理の成功失敗を例外で返すようにすると、使いたいところで毎回例外処理を書かないといけないといけない。
- モデル側での処理が複雑になった場合に、大きい範囲をrescueする形になる。
- railsでは習慣的に、例外ではなく戻り値で判断する。
- 詳細はjnchitoさんの記事がわかりやすいです。
汎用性も可読性も低い。一般的でもないということですね…。
どうすればいいか
Resourceモデル
class Resource def write # 何かの処理 false # 何かの処理の結果falseだったと仮定 end end
Resourcesコントローラ
class ResourcesController < ApplicationController def create if Resource.new.write redirect_to '/', flash: { notice: '作成されました' } else redirect_to '/', flash: { error: '作成されませんでした' } end end end
カスタム例外は必要なくなりましたし、表示用のメッセージがモデルに縛られなくなりました。
結局カスタム例外は必要ないの？
必要ないとは言いませんが、単体のRailsアプリケーションを書いている場合、自分でraiseしようとしている例外はそもそもシステムエラーではなく業務エラー（日常的におこりうる）であることが多いように思いました。 もしそれがシステムエラーならば、rescueして握りつぶしては検知できないですし、そうなるとrescueしないんだからカスタム例外ではなくてもいいよねという話になると思い、最終的に独自例外いらないよねということになるんじゃないかなと思います。。。
gemなど不特定多数の人が使うものに関しては積極的に定義していくべきだと思います。gemから返ってくる例外がRuntimeErrorだとつらいですしね。
まとめ
やっぱりRailsでカスタム例外を定義すべき機会は少ないし、少なくとも自分はめったにやらないかなと思いました。
プロジェクトの立ち上げ時に入れてよかった/入れなくてもよかったgem
はじめに
ここ最近趣味でrailsアプリを複数人で開発しています。
自分以外Railsは初心者 で、rails newしてgemを入れてDB初期設計やってはじめのコントローラ（API）をつくるまで位を自分でやったのですが、その後入れてよかった/入れなくてもよかったと思うgemがあり、多少は他の人や未来の自分にも役立つだろうということで書き留めます。
入れてよかった
onkcop(rubocop)
コーディングスタイルについて揉めたり、議論したりすることがなかった。
自分が設定して満足できた。
bootstrap
本デザインが当たっていないサンプルの状態でも、まあまあいい感じに見せられる。素のHTMLを見ることによるテンションの落ちがない。
gimei
後述するseed-fuでのサンプルデータ作成に役立った。
ridgepole
migrationファイルの記法がほとんど使えるため学習コストが低かった。ちょこちょこスキーマを修正するのにいちいちmigrationを作らなくてよかった。（古いmigrationファイルを直せばいいというのもあるけど、ほんの少し罪悪感がある。）
seed-fu
サンプルデータをはじめに整備しておくことで、いろいろイメージが付きやすかったり、たたき台にできたり。
shrine
本番ではS3を使うのだが、developmentではローカルにファイルを置くとか実装を切り替えれたのが便利。初めてつかったけど carrierwave をちゃんと使ったことがあればある程度は動かせた。
他の人を見ていると学習コストは高めだった。
capistrano-*
よくわからんままとりあえずgit pullでデプロイとかしなくてよかった。快適
入れなくても良かった
active_model_serializers
これを使いこなすためには きれいなAPI設計 がおそらく必要なのだけど、それがネックだった。 APIが汚いとserializerも汚くなる。 controllerでの手動よびだしとかするといまいち。 jbuilderや、素のhashを返すpure rubyのクラスを作って自前でas_jsonをしていくほうが、コスト低くある程度の規約ができてよかったかもしれない。
devise
自分が知っていたので立ち上がりは早かった。ただ、自分が入れてjwtなどの設定もしたので、自分が全部面倒見る感じになってしまった。 管理画面には積極的に使えばいいとおもう。
rspec
実際は「テスト各時間を取れなかった」という感じになる。作るものもよくわからないし、教える時間が満足に取れない状況ではどうしてもテストは後回しになってしまった。
まとめ
すべて学習コストとリターンのバランスかなという感じがしました！
Rails.cacheの落とし穴
はじめに
仕事で開発をしていた所、コードを動かしていてキャッシュされるべきところがキャッシュされないことがあったのでメモ。
結論
モデルをキャッシュする時、以下のようにしてもキャッシュされない。
@users = Rails.cache.fetch('user_all') do User.all end
なぜか
ActiveRecord は評価を遅延させます。@users = User.allとしてもすぐにSQLが発行されることはなく@users.eachなど発行するクエリが決まった段階でクエリ発行されるわけです。
結論に書いたケースだとUser::ActiveRecord_Relationのインスタンスがキャッシュに入り、インスタンスが評価された段階でSQLが発行されるため、結果としてキャッシュを使っても毎回SQLが発行されてしまうわけです。
どうればいいか
上記の記事を参考にさせていただきました。
以下の用にto_aを使ってクエリを即時発行すればOK。
@users = Rails.cache.fetch('user_all') do User.all.to_a end