2018年振り返り

2018年の目標について

  • 前述しましたが、社の一員として、成果を上げること(メインは技術的負債の返済)
    • 一番大きめの問題については問題を解消する目処が立てた。後述します。
  • MHWに時間を吸われないように
    • 200時間以上吸われた…
  • 勉強会で積極的に登壇する
    • LTが1回でした。
    • もうちょっと増やしたいっすね。

書いたブログ

記事の内容はどうあれ半年くらい書くことを続けていたので、それなりに書いた気がする。 全体的にほぼ全部の記事で反響はなかったんだけど、個人的にはこのあたりの記事を気に入っていました。 暇なら見てください。

webuilder240.hatenablog.com

webuilder240.hatenablog.com もう毎週は書いていません。

webuilder240.hatenablog.com

技術的な振り返り

技術LT

webuilder240.hatenablog.com

一本だけでした。ただLTデビューはできました。

FirebaseというかFirestore

ちょうど去年の今頃はチャット機能を作るにあたって色々アーキテクチャを探したり試している最中で、 その中でベータリリースされたばかりのFirestoreとFirebaseを触っていた。 そんな後述するUIの全面的な改修の目玉機能として、チャット機能を作るのに最終的にFirestoreを利用することになった。 RealTimeDatabaseも試してみたけど、Firestoreのほうがやはり後発なだけありかなりサクサク作れたので、作り始めるタイミングとして本当にラッキーだった。

今年はまさにFirestore元年な年だと思った。

UIの全面的な改修

後述するシステム移行の第一弾的施策として、UIの全面的な改修を行った。 スケジュールに無理があったり、ちょっとデザイナーとのごたごたがあったりして、 スケジュール通りに行けるかどうかかなり不安だったけど、蓋を開けてみると当初のスケジュールからあまり変更することなくリリースできた。

システム移行について

これまでかなり非効率だったシステム構成についてもこのままではビジネス自体の拡大を妨げてしまうので、 幾分拡張性を捨ててでも、プラットフォームサービスとして運用するほうがビジネス的にも開発側でもメリットがあるという結論にいたり、 小規模の20個ほどあるシステムを1つのシステムにまとめるシステム移行を会社として決断して実行することにしました。 新アーキテクチャ自体は完成して、新しい案件をそちらで動かしているけど、既存の案件の移行はまだという感じです。 既存の案件の新アーキテクチャ移行は来年年始から早速始動していくという感じです。

もうちょっと具体的な話については、LTとか、知っている方は直接おはなしできればとか思っています。 とにかくご協力いただいた方々には感謝しています。

PR活動

送ったPRくらいは残しておいて振り返ってもいいかなと。

ngx_mruby

github.com

前述のシステム移行の技術検証の一環として試したときに出た(確かOpenSSLが古いとかだった気がする)問題があり、 単にOpenSSLをアップデートするより、Ubuntuのベースイメージを上げてそっちで動かすようにすればいいかなと思って対応した。

MergeされたあとにDockerイメージが自動ビルドされなかったので、松本さんにお願いしてDockerイメージがビルドされるよう設定し直して頂いたりしました。

github.com

こういうDockerイメージがないライブラリやプロダクトのDockerイメージを作る業みたいなのは地味に喜ばれるんじゃないかなと思った。*1

ただこの公式Dockerイメージ、あんまり使われてなくてどうしてなんだろうかという気持ちになっている。

lograge-sql

https://github.com/iMacTia/lograge-sql/pull/4github.com

そんなにStar無いんだけど、ちょっといいなと思ってPR投げた。 その後にもうちょっと便利なソリューションが生まれてて、そっちが最初からあればいいのかーってなった。

mock_redis

github.com

会社でたまたまペアプロしていたら見つけてその晩に対応コード書いてPRしたもの。 mgetでキーが存在しない場合の挙動が異なっていました。 こんな拙い英語でも伝わったので良かった。

意気込み

社にエンジニアが数名入ってきたりしたこともあって、自分の立ち位置も安泰ではないと思っている。 社のリードエンジニアとして技術では社の誰にも負けたくないと思っているし、技術って幅広いし、自分が負けている部分があるにしても少なくとも自分がどこかの分野で1番詳しいものがないといけないと思っている。そのためにはなんでもやるし努力は惜しみたくないと思っています。

2019年: 目標

これだと思える技術見つけて、エンジニアの特色を出したい。

  • どの技術も少しだけできるみたいな器用貧乏になっちゃってるのでなんとか脱したい。もうちょっとちゃんと極めたい。
    • デザインパターンとか、設計にも興味があってそれはどんな技術にも大抵は応用が効くので、やってみようかな…
  • 28でネイティブアプリを少しかじってみて、29までに決めて、30でとことん技術に投資するとかでもいいんですかね。
    • うーん、遅いかなぁ、なんか受験みたい…

毎年、システムを廃止したり、移行したりする仕事ばかりなのでいい加減年始でやるシステム移行で最後にしたい。

  • 2016年もやったり、2017年もやった。2018年もやってて、2019年こそはこういったシステムの移行案件はあんまり心臓に良くないので、できればないようにしたい。

ネイティブiOSAndroidやっていきたい。

  • 残り半年で、Androidはまぁ趣味とかで。
  • ReactNativeとかはネイティブある程度やってからでいいかなー。

おわりに

それでは皆様残りわずかですが良いお年をお過ごしください。

*1:単にDockerイメージを用意するのもそうだし、Alpine化してよりスリムなイメージを出すとか。

SimpleDelegatorでSimpleなDecoratorを作る

そういえば、 ModelであんまりViewに関わるロジックを使わないほうがきれいにコード書けていいですよ~みたいな話をしたのですが、 その時に標準ライブラリにあるSimpleDelegatorを使うといいですよねなんて話をしたのですが使い方を復習するなどしていました。

SimpleDelegatorってなんだっけ…

るびまによると…

オブジェクトの機能を再利用する手法の一つとして、Ruby では言語仕様としてクラスの継承とモジュールの Mix-in を提供しています。これらは、元になるクラスやモジュールの実装までもをそのまま取り込んでしまいますが、他の手段で機能の再利用を実現する手法として、委譲があります。

委譲では、再利用したい機能を自分に取り込むのではなく、その機能を持つオブジェクトに処理を依頼します。

Ruby では特に言語仕様として委譲がサポートされているわけではありませんが、委譲を実現するためのライブラリとして forwardable と delegate が用意されています。具体的には、これらのライブラリを使用することによって、あるメソッド呼び出しを他のオブジェクトのメソッドにたらい回すということを簡単に記述することができます。

という感じです。 普通だと委譲を実現するのにいちいちメソッドを定義しないと行けないのですが、 SimpleDelegatorを使うと追加したいメソッドだけを追加するだけでいいので便利。

標準添付ライブラリ紹介 【第 6 回】 委譲

SimpleDelegatorで作ったSimpleなDecorator

# 委譲させたいClass
class User
  attr_reader :firstname, :lastname
  def initialize(firstname:, lastname:)
    @firstname = firstname
    @lastname = lastname
  end
end

# Decorator
class UserDecorator < SimpleDelegator
  def fullname
    "#{firstname} #{lastname}"
  end
end

user = User.new(firstname: "西尾", lastname: "拓也")
u = UserDecorator.new(user)
p u.fullname

そんな感じで委譲でよく使われる鉄板用途としてDecoratorパターンがありますが、それをSimpleDelegatorで作ってみた例になります。

12. Decorator パターン | TECHSCORE(テックスコア)

これの使い道としては、自前で簡単にViewロジックを実装するような、いわゆるHelperやDecoratorが欲しい時、 ActiveRecordに依存しないようなDecoratorがほしいときはこれでサクッと作ってしまうのがいい。 もし、ActiveRecordに依存するDecoratorならActiveDecoratorを使うのでもいいのではないでしょうか。

まとめ

  • 標準ライブラリ便利なので、他にもこういった便利ライブラリがあるのでどしどし使っていきたい。

大規模サービス技術入門読んだ

まとまりないけど、感想を簡単に。

RDBMSの分割方法の話から、大規模サービスでパフォーマンス改善するためにどうアルゴリズムを生かしていくかや、大規模サービスのWebインフラはこんな感じでやってるぞーということが書いてあってよかった。 

普通なら退屈なアルゴリズムの部分も、実戦ではこう使えるし、アルゴリズムの知識だけではダメで、それを応用してくことが大事ーということだったり、ハードやソフトウェアの進化でお安く富豪的に解決できる事もあるから、時にはナイーブな実装試して検証して、割り切ることも大事だぞーと話しててなるほどとなった。 

この本でも特に多くページを割いていた印象があるのだけど、大規模サービスではやっぱりAppサーバーよりもDBサーバーの方が大変でやることが多いのかーとなっていた。でも、n+1について言及がなくて、はてなの場合はそこまで悩む事はなかったのかと。もしくは基本的なところなので外したか?

サーバーの仮想化についても、わかりやすく説明していて、仮想化してあるとリソースを余す事なく使えていいですねーとなった。(さらに発展させるとDockerに)

大規模サービスとか運用したことないし、今後もしそういったサービスを運用する機会があった時にそもそも経験したことがなくて、この辺がめちゃくちゃコンプレックスみたいな感じだったのだけど、この本で幾分知識をつけれたので今後のインフラやミドルウェア選定、アプリケーション実装に前よりは少しは自信持てるかなぁ。

出版されて8年くらい経っているのだけど、陳腐化してる技術もそこまでなくて、割とコンピュータのベースにあるような技術やわりと今でも応用が効きそうな大規模サービスでのパフォーマンス改善のヒントがたくさん書いてあるので、もし本屋などで見かけたら読んで見るといいかもしれない。

さあ、次は何を読もうか。

WebAPI The Good Partsを再読した

そういえば昔に読んだな、 とかおもってまた引っ張り出して読んでいた。

Web API: The Good Parts

Web API: The Good Parts

改めて学びがあったトピックは

  • バージョン番号をどこに入れるといいんだっけ?
  • ページネーションの仕様について(相対参照・絶対参照)
  • オーケストレーション層(実質BFFと解釈している)についての話が簡単に
  • パブリックなAPIとして運用していく色々なTips(レートリミットなど)

このあたり。

オーケストレーションは昔のRebuildでも話したそうだけど、(今度また聴いてみる) やはりNexflixすごいよなぁとなった。

あとはセキュリティの話があったんだけど、だいたいこれはAPIにかかわらない内容でなるほどーとなっていた。

全体的に、パブリックにエンジニアにAPIが公開を前提として話を進めているためか、 イケてないURL設計とかレスポンス内容ってダサいから、特別な理由がない限り利用者の印象良くないからやめようぜよく言ってた気がした。

公開APIとしての運用面のノウハウ、エラーレスポンスをこうするとわかりやすいみたい話はあんまりネットなくて良い感じにまとまっているので、 APIを始めて設計したりする時に参考になるところはいくつかあるのでちょっとおすすめしたい。

Docker HubのSource Repositoryを変更したい場合

Docker HubでGithubあたりの自動ビルドを有効にしている時に、Source RepositoryのRename時に参照するGithubリポジトリ変更したい場合がある。 この変更を忘れると、Github上でエイリアスを設定していてもDocker Hubには適用されず、自動でビルドされない状態になる。

ではどうすればいいか

直接設定を変更する解決方法はない。

取るとすれば下記の2つが有力。

1. 潔くDocker Hub上のリポジトリを削除して、再設定する。

削除されることが許容できればこれが一番手っ取り早い。 削除されることのデメリットは、Docker Hub上のStar数がリセットされるとかそのくらいだとはと思う。

2. Docker Cloudでビルド先を設定して、Docker Hubではなく、Docker Cloudでビルドする

この辺を参照してみてほしいんだけど、面倒だし、Docker Cloudという別のサービス使わないと行けないのがとにかく良くないので、 特にこだわりがなければ、この対応よりも、前者のほうが簡単でラクでいいんでは。と思っている。

No way to change source project for automated build · Issue #313 · docker/hub-feedback · GitHub

なんでこれ調べていたか

ngx_mrubyのDockerイメージのベースイメージを新しいものに変更して、 特に問題なくMergeしてもらったのだけど、この時に1年くらい前から自動ビルドがされてないですねー。ということがわかって少し調べていた。

1年くらい前にタイミングでngx_mrubyはAuthor名が変わって、Github上のリポジトリ名が変更されていたのが原因だったらしい。

今回は面倒なので、2.を提案して対応していただいた。(その節はありがとうございました!🙏)