Yaga and Me

日々のログ。ソフトウェア設計とねこが好き

「過大評価されるDDD(ドメイン駆動設計)」を読んで

「過大評価されるDDD(ドメイン駆動設計)」の記事(以下、記事)を読んで、色々と思考を広げていたので言語化して整理してみる。

itnews.org

記事の全てに対して言語化をすると大変なので、筆者が一番伝えたいであろう最後の2段落を記載しつつ議論を広げてみる。

私たちは独自の言語を発明できるし、発明すべきであるというこの概念は、単純な多くのDDD使用者が考えているよりもはるかに重要です。DDDの専門家はこのことをよく知っていて、DDDの資料を最終結果ではなく出発点として見ていると信じたいです。しかし、もしあなたが既存のDDD用語の決まりきった定義を使って、この既存の構造の中に問題を押し込もうとしているだけなら、あなたの設計者としての人生は非常に悲惨なものになるでしょう。

DDDをあなたのツールセットの一部にして、そこで終わりというのはいけません。DDDの先には人生があるのです。すべての優れた設計がドメイン駆動型である必要はありません(必ずしもDDDという意味ではなく、常にドメインによって駆動されるべきであることは認めますが)。DDDの専門家でなくても、良いシステムを設計することはできます。

とても深い共感を得た。個人的な意見として人間は経験に基づくと思っているので、DDDの専門家でなくともソフトウェア設計という分野に対して向き合った経験が豊富であれば良いシステムを設計できると思う。

だとすると、DDDはどのようなモチベーションで扱うべきか。

自分なりの結論としては、「コミュニケーションというプロセスにいかに重きを置くか」ということになると思う。

例として、チーム開発ではない個人開発であれば、「良いシステムを設計できる」という結果が重要で、結果に至るまでのプロセスにコミュニケーションは発生しない。

↑個人開発であっても「現在の自分」と「未来の自分」にコミュニケーションは発生するので、この例えは良くないかもしれない。

「誰かに伝える」もしくは「誰かから伝えられる」プロセスがなければ共通言語(ユビキタス言語)は有用ではなくなる。と考える。


ちょっと話は変わるけど、「DDDはソフトウェア設計におけるユビキタス言語」という話を聞いたことがある。

Eric Evansさんはソフトウェア設計というドメインにおけるユビキタス言語を自分のようなソフトウェア開発者に提供してくれている。

がしかし、ソフトウェア設計というものは正解がなく、ソフトウェアそれぞれに異なる道がある。

つまり、ソフトウェア設計というドメインには各ソフトウェアごとに異なるコンテキストが存在するので、各ソフトウェアのコンテキストにとって最良なユビキタス言語を模索するべきであると考える。

最後に記事に対する解釈を自分なりにまとめてみる。

DDDはあくまでEric Evansさんが自分たちに提供してくれたもの。

提供されたものをただ真似するのではなく、自分の設計(人生)は自分で決めなければいけない。

自分の人生は自分で選べ。

最後はかなり強気な意見になったけど、記事の筆者が伝えたいことはそういうことなんじゃないかと思った。

scalafmtで変数型指定部分のAlignを設定する

はじめに

NeovimからIntelliJに乗り換えた際、変数に対する型指定部分の整列処理に関して躓いたのでメモ。

やりたいことは以下のような整列処理。

case class User(
  id: User.Id,
  userName: UserName,
  email: EmailAddress
)

のようなコードを、以下のように整列させたい。

case class User(
  id:       User.Id,
  userName: UserName,
  email:    EmailAddress
)

Neovim時代はvim-easy-alignというvimプラグインを用いていた。

github.com

ただideaVImで上記プラグインは対応していないらしい。ので、IntelliJでどうやって整列処理を行うか色々と試した。

解決策

IntelliJによるCaretを用いた整列を行うプラグイン等を試したが、マウスを使ってCaretの対象箇所を指定する方法があまり馴染まなかったので、一旦scalafmtによって解決することにした。

※マウスを使わずとも簡単に本記事例のようなCaretを指定できる方法をご存知の方がいましたらコメントいただけると幸いです。

.scalafmt.confの設定は以下、

version = 2.5.0

align.tokens = [
  { code = ":", owner = ".*" }
]

おわりに

自分が調べた限りだと公式ドキュメントに例が載っていなく、解決まで時間がかかってしまいましたが過去のPRからテストコードを探し出すことができました。めでたし。

以下、参考リンクです。

Configuration · Scalafmt

Align types of class arguments · Issue #174 · scalameta/scalafmt · GitHub

Add support to align by tokens that have no space before them by olafurpg · Pull Request #441 · scalameta/scalafmt · GitHub

2021年の目標を簡単に立ててみた

はじめに

新年明けて半月が経とうとしているけど、2021年の目標を立ててみた。

自分は基本的に、長期的な目標を作らず目の前のことに一つずつ取り組んでいきたい考え方が強いので、2021年の目標というよりは目先に取り組みたいことの目標になっている。

簡単にではあるけど、目標をまとめていく。

技術書インプット系

「エリック・エヴァンスのドメイン駆動設計」を読了する

www.shoeisha.co.jp

現時点で第2部第6章の集約(AGGREGATES)まで読み終わったところ。今まではコード上の実装における知識がほとんどだったけどユビキタス言語や境界づけられたコンテキスト、ドメインモデル等についてもしっかり身につけていきたい。

「マイクロサービスパターン」を読了する

book.impress.co.jp

現時点でChapter3まで読み終わったところ。自分にとってはまだ難しい内容が多く読み進めるのが大変ではあるけど、とても興味がある内容なのでしっかり読了したい。

まだ触ったことがないgRPCは近いうちに入門して手を動かしたい。

オブジェクト指向入門 第2版 原則・コンセプト」を読了する

honto.jp

近いうちに購入して読み始めようと考えている本。Scalaを使ってるのでしっかりOOPについても学んでいきたい。値段がお高いのでまずはお金を貯めるところから💰

モノリスからマイクロサービスへ」を読了する

www.oreilly.co.jp

目次やレビュー等をみている限りとても興味がある内容なので購入しようと考えている本。実践的な内容が多いらしいので、具体的な知識が多く書かれている印象がある「マイクロサービスパターン」と比較もできて良さそう。

言語キャッチアップ系

RustかElmのいずれかを手を動かしながら学ぶ

「1年に1つ新しく言語を学ぶと良い」とどこかで読んだ気がするので実践してみる。

RustとElmは前から興味はあったけど結局触っていなかった言語。

1つ学べればいいので「RustとElmのいずれか」と書いたけど、両方学ぶくらいの意欲でやっていきたい。

Scala3(Dotty)のキャッチアップ

こちらも興味はあったけど触らずにいたので目標とする。どうやってキャッチアップしていくかは随時工夫する。

アウトプット系

自作ライブラリの「librame」を継続して開発・公開する

github.com

librameは趣味開発で用いている自作のScala言語ライブラリ。趣味開発を続けつつlibrameを継続して開発する。

機能が増えてきたらテストやScaladoc等を綺麗に整備してOSSとして公開するのが目標。

はてなブログを10記事投稿する

これまでブログを書くときは、完璧主義というか長い時間をかけて作り込むことが多かった。

けど最近になって、もっと雑にでも自分の思考を文章に残すことって大事だよなと思い始めたので立てた目標。

はてなブログなら個人ブログなので、もっと気軽にブログを投稿できるようになりたい。

その他エンジニアリング以外

ビジネス書を10冊読む

2020年の年末頃からビジネス書を読むのにハマっている。ビジネス書と言ってもベースキャンプのジェイソン・フリードさんが書いた本に限っているけど。

SaaS開発に携わっている以上、営業さんやCSさんといった他の職種の方々がどんな仕事をしているのかちゃんと知りたいので、技術書以外のビジネス書もたくさん読んでいきたい。

ねこを飼うことができる家を契約する

ひたすらにねこを飼いたい。もしねこを飼うことができたらどれだけ幸せなんだろう。

おわりに

以上、2021年の目標を簡単に立ててみた。

途中で新しく取り組みたいことは増えると思うけど、この記事に書いた目標は最低限達成できるように頑張ろう。

2020年振り返り

はじめに

年越しまで時間がないため殴り書きにはなりますが2020年の振り返りをしていこうと思います。

本記事は技術メインで振り返りをしていきます。

以下目次です。

2019年末

2020年1月から内定先での内定者インターンが始まることが決まっていたため、インターンに向けた準備を進めていました。

内定先ではバックエンドにScala、フロントエンドにAngularを採用していました。

ScalaとAngularはほとんど触れたことがなかったため、ScalaとAngularを用いてシンプルなTodo管理を行うSPAを作成していました。

1~3月

4月の入社に向けて内定者インターンをしていた時期です。

いきなり実際のプロダクトに配属させてもらったのですが、業務未経験であったためにたくさんのことを学びました。

学んだことを大きく分けると以下のようになります。

  • Webエンジニアとしての基礎的な知識
  • Scalaの基礎文法
  • HTML,CSSの基礎

Webエンジニアとしての基礎的な知識

インターンが始まってすぐに自分の知識不足を実感しました。学んだ内容としては以下のような内容です。

以下、順に話していきます。

チーム開発経験がほとんどなかったため、Git, Githubに関して知らないことがたくさんあることを自覚しました。その際の学習で使用した教材は以下が良かったです。

learngitbranching.js.org

内定者インターンではVimを使用することになっていたためVimでのコーディングに慣れる練習をしました。最初は以下の教材で練習をしていました。

www.openvim.com

配属チームではスクラム開発を採用しJiraでタスク管理を行っていました。スクラム開発は名前を聞いたことがある程度だったため概要を掴むためにインプットを行いました。

Scalaの基礎文法

インターン中にScalaのコードを触っている際、なんとかコードを動かすことはできてもその背景にある知識が不足していました。

基礎知識を固めるため、2つの教材に取り組みました。

1つは「Tour of Scala」です。分からないこともありましたが6割くらいの理解で読み進めていたと思います。

docs.scala-lang.org

なんとか一周をして次の教材に進みました。

次はN予備校の「大規模Webアプリ Scala基礎コース」に取り組みました。

www.nnn.ed.nico

とても良質な教材で楽しく読み進めました。12章の「ケースクラスと同一性」等は今読んだとしても学びになるなと思います。

余談ですが、この時期に参加したScalathonというイベントがとても楽しかったです。

scalathon.connpass.com

初学者でも温かく迎えてくださり、Scalaの勉強に取り組むモチベーションがさらに上がるきっかけになりました。

HTML,CSSの基礎

インターン中のタスクにある静的ページのデザインを丸々リニューアルするというタスクがあり、HTML, CSSにガッツリ取り組みました。

それまでは雰囲気でHTML,CSSを書いていたため、Progateで一通りのコースを学び基礎を固めました。

またCSSのクラス命名にはBEM記法が採用されていたためBEM記法についても学びました。

実践してレビューを頂きながら知識を身に付けることができたのでとても有り難かったなと思います。

4~6月

4月に入社をし、4月から5月の間オンラインで研修を行いました。

そして6月にプロダクトに配属され、いよいよ社会人としてのスタートを切った期間でした。

この時期に学んだことは以下のような内容です。

  • Scala標準ライブラリ
  • 状態管理・RxJS
  • DDDのインプット

Scala標準ライブラリ

入社後研修前半ではScala標準ライブラリに関する内容の基礎研修がありました。

具体的には社内のエンジニアの方々が作成された標準ライブラリに関する研修資料と実際のライブラリ実装コードを読みながら、自分の理解をテキストにまとめていきました。

これまでScalaの基礎文法については学習時間を多く取っていましたが、標準ライブラリに関しては理解度がそれほど深くなかったことを自覚しました。

参考資料として用意して頂いた「Scala実践入門」もとても分かりやすく、それまで曖昧に使っていたmap, flatMapやパターンマッチに関する動きを深く理解することができました。

gihyo.jp

状態管理・RxJS

入社後研修後半では個人でTodo管理アプリケーションを作成する応用研修がありました。

フロントエンドにはAngularを使用したのですが、NGXSを用いて状態管理の概念に初挑戦しました。

NGXSの公式ドキュメントはとても分かりやすかったなと思います。

www.ngxs.io

状態管理の概念と同時にRxJSに関しても学習を行いました。

初めてObservable型を見たときは正直なところチンプンカンプンでしたが、公式APIを参照しながらNGXS内で値をやり取りする処理を書くことで徐々に慣れていきました。

リアクティブプログラミングに関しては年末になった現在でもしっかりとした基礎のインプットができていないので、近いうちに深く理解する機会を作りたいなと思います。

DDDのインプット

学生時代に少しだけ学んでいたDDDへの興味が再燃し、成瀬さんの「ドメイン駆動設計入門」を購入してDDDの学習をしました。

www.shoeisha.co.jp

値オブジェクトとエンティティの違い等が分かりやすく、サンプルコードもたくさんあったので気軽に読み進めることができました。

以降も楽しくDDDを学べているのはこの本で入門したおかげかなと思っています。

7~9月

配属先の業務にも慣れてきて余裕ができたのか、様々なことをインプットしつつ初めてのLT発表にもチャレンジした時期でした。

その中でも大きなトピック挙げると以下の3つかなと思います。

関数型プログラミング圏論)のインプット

しばしば名前だけ聞いていた「モナド」とはなんぞや?という疑問から始まり、関数型プログラミング圏論に関することをインプットしていました。

Haskell圏論の本を買って読んだり、個人開発でCatsライブラリを用いて色々処理を書いてみたりと細かく手を出していたと思います。

圏論に関しては、本の内容で分からない部分が多かったことからこのタイミングで一度挫折しているのですが、その後同期が社内勉強会で開催し始めた圏論勉強会を通して楽しく理解を深めています。

社内勉強会の内容は同期がブログにもまとめています。ありがたい。尊敬。

taretmch.hatenablog.com

Scala RookiesでのLT発表

人生で初めてLT発表をしました。

内容は以下のブログにまとめています。

medium.com

ファシリテーターにもチャレンジしたのですがとても緊張したのを覚えています。

その後オンラインイベント等に参加するとファシリテーターの方に注目して学びを得ることが習慣になりました。

読書記録ブログ

4~9月に読んだ本をまとめたブログを書きました。特に7~9月は色々な本を読んだなと思います。

medium.com

10~12月

この時期は以下の内容に力を入れていました。

DDDのアウトプット

以下のスライドを読んだことをきっかけに、「自分もScalaでDDDのサンプルコードのようなものを書いてみよう」と思い立ちアウトプットをし始めました。

speakerdeck.com

最終的に出来上がったものとしては、DDD開発の基盤として用いる自分用のライブラリ(librame)のようなものと

github.com

そのライブラリを用いたサンプルコードのような立ち位置である、簡単な認証機能を持つプロジェクトを作成しました。

github.com

プロジェクト内の採用技術はlibrameリポジトリのREADMEにまとめているのですが、その中でも特に学びが多かったのはEffDoobieの2つのライブラリを導入した事かなと思います。

最初はCatsのEitherTで実装していたユースケース層の処理をEffで書き換えた事で、Effから受ける恩恵を実感しました。

Doobieライブラリに関しては必然的にCats Effectに関しても学ぶ必要があったため、Cats Effectのライブラリ(主にIOモナド)を読み込みました。

以上の2つのライブラリに関してはまだまだ理論や背景等の理解が足りていない部分が多いので、引き続き学習をしていきたいです。

関数型プログラミングのアウトプット

この頃から業務でもCatsライブラリに触れる機会が多くなり、「Catsライブラリを使うことに慣れてきたかな〜」と感じていたので「今度はCatsライブラリを作ってみよう。」と思い立ちました。

まだまだ道半ばでかつ最近は更新していないのですが、以下のリポジトリでゆるくアウトプットをしています。

github.com

その途中で得た学びをZennに投稿してみました。

zenn.dev

Githubリポジトリ・シリーズ化して投稿予定だったZennの記事ともに、途中で更新が止まっているので近いうちにまた力を入れて取り組み直したいです。やり抜くの大事。

ソフトウェア設計に関する知識全般のインプット

最近はソフトウェア設計(この表現が正しいかも微妙)全般についての知識を、技術ブログ等でつまみ食いをしながらがむしゃらにインプットをしています。

キーワードとしては以下のような内容について興味を持っています。

最近はクリスマスにずっと欲しかったEvans本を書いました。上記のキーワードに関連する内容が多く登場するのでとても楽しく読ませていただいています。

「がむしゃらにインプットをしている」とは言いましたが、自分の興味のゆくままにインプットをしていると

  • Martin Fowlerさん
  • Bertrand Meyerさん
  • Eric Evansさん

といったような偉大なる先人の方々の名前が登場する事が多いです。

そのため今後は上記の方々が残してくださった原典を中心に学習を続けていきたいなと考えています。

おわりに

2020年の1年間を振り返ってみました。

1年間の振り返りをまとめるのは今回が初でしたが、実際に振り返ってみてとても良い区切りになったなと思います。

今後とも精進してドンドン成長していきたいです!

最後まで読んでいただきありがとうございました!

LITALICOの社内ISUCON【LISUCON】に参加してきた

はじめに

こんにちは。 簡単な自己紹介から始めます。

私は普段、東京にある某大学でデータサイエンス系の研究をしている修士1年の大学院生です。 就職はソフトウェアエンジニアとしての就職を決めたため、独学でWeb周りの知識を勉強しつつ就活に励んでいます。言語はGolangが好きで、ScalaとAngularを勉強中です。

今回12月13日(金)に株式会社LITALICOさんにて開催された社内ISUCON、題して【LISUCON】に学生枠として参加したところ、とても充実した時間を提供していただいたので参加レポートとしてまとめたいと思います。

本家ISUCONがどんな競技なのかと言うと

※ ISUCON

お題となる Web サービスを決められたレギュレーションの中で限界まで高速化を図る LINE 株式会社主催のチューニングバトル、それが ISUCON です。過去の実績も所属している会社も全く関係ない、結果が全てのガチンコバトルです。

( ISUCON 公式アカウントより/ @isucon_official

※本家ISUCONがどんな競技なのかについてもっと詳しく知りたい人は、こちらが参考になるかと思います。

LISUCON概要

LISUCONのテーマはWebアプリ速度チューニング + バグ修正コンテストです。

本家ISUCONとの大きな違いは競技にバグ修正要素が含まれることです。 狙いとしては、「速度チューニングに深い知識がない人でも競技を楽しむことができるよう、バグ修正でも点数が上がるようにした。」とのことでした。

個人的にはこの狙いがあったおかげで、ISUCON初心者の自分でも競技を充分に楽しむことができたと思っています。

当日までの流れ

参加した経緯

ある日Wantedlyで就活のためのインターンを探していたところ、LISUCONの募集を見つけました。

元々LITALICO社内のエンジニアの方々だけで行う予定だったようですが、「せっかくなので採用活動の一環として学生も募集してみよう。」という流れで募集をかけたみたいです。

私自身これまで独学でWebアプリの個人開発等を行ってきましたが、実務経験がなくアプリの速度チューニング等を本格的に行ったことがなかったため、これは良い機会だと思い即座に申し込みをしました。

ちなみにLISUCONに参加する前の私のISUCONに対する理解度は以下のような感じでした。

  • Webアプリの速度を競ってるらしい。
  • 高速化っていっても知っているのはN+1問題くらい、、、
  • SQLと言語仕様以外でどうやったら高速化できるんだろう?

いま思うと、これだけの少ない知識でよくイベントに飛び込んだなと思います。汗

事前ドキュメント

無事、参加が確定するとSlackチームに招待してもらい事前ドキュメントが配られました。Slackのチームアイコンがリスがトウモロコシを食べている画像だったのですが、「リス+コーン」を意味していたことは後日知らされました(全然気づかなかった)。

事前ドキュメントには競技概要、参考実装、予習情報等について記載されていました。

競技概要

  • 競技時間は4時間
  • チームは1名か2名
  • 当日配布されるインスタンス以外の外部リソースを使ってはいけない。
  • DB、ミドルウェア、キャッシュ機構、サーバーサイド実装はいくら変えてもOK。
  • API設計、フロントエンド(JavaScript/CSS)、メディアファイルは変更禁止。

参考実装

予習情報

ツール類

その他ISUCON1~9までの過去問集などがまとめられていました。

事前ドキュメントを読んで

ここまで丁寧に概要等をまとめましたが、こちらは本家ISUCONに大分寄せているみたいです。

自分も予習を進めましたが、結局、初めて触るRubyの文法、ツール類の概要の把握、過去問の参考実装を読む、程度の予習で当日を迎えてしまいました。ツール類の環境構築をもっと事前に準備しておくべきだったと反省しています。

競技当日

迎えた競技当日、会場に到着すると外部参加にも関わらず社員の方達がアットホームな雰囲気で迎えてくださいました。学生は自分以外に2名参加していました。

その後簡単な自己紹介を終えると、当日ドキュメントが配られ競技の追加説明がありました。

追加説明

アプリケーション概要

ざっくりいうとエンジニア向け勉強会プラットフォームサービスのConnpassと類似したような、イベントプラットフォームサービスです。

機能を以下に簡単にまとめると、

- ユーザー
    - 登録
    - ログイン
- イベント
    - 一覧ページ
        - 詳細ページ
            - 参加者一覧
            - 予約
            - キャンセル

といったようなシンプルなアプリケーションでした。

競技ではこちらのアプリケーションのバグ修正と速度チューニングを行っていきます。

ベンチマーク

競技は主催者の方が実装したベンチマークによってスコアが算出されます。

ベンチマークが実行されるたびにDBが初期化され、大量のAPIリクエストが届きます。時間の経過やバグ修正等の条件をクリアしたかどうかによって負荷レベルがあがっていき、リクエスト数が増えていく仕様のようです。

競技終了後には再起動試験があり、再起動してもアプリケーションが正常に動いた状態で競技を終えなければいけません。

ベンチマークが実行終了すると実行ログがSlackに届きます。また競技終了1時間前までは、前方のモニターにスコアランキングがリアルタイムで映し出されるシステムになっていました。

これらをゼロから作成した主催者の方の気合いが感じ取れました。

競技開始

競技が始まると、アプリケーション稼働済のAWSインスタンスIPアドレスが渡され、それぞれのチームで環境構築を進めていきました。

競技の結果を最初に言うと、自分は主催者の方が用意していたバグや速度チューニング要素のごく一部のみしか改善することができませんでした。

アプリケーションの改善要素

ネタバレのようになりますが、アプリにどのようなバグや速度チューニング要素があったのかを最初にまとめたいと思います(競技後に行われた主催者の方の解説を参考にしています)。

バグ修正
  • ユーザーテーブルのemailにUNIQUE KEY制約がなくAPI仕様書と異なるレスポンスが発生してしまう。
  • イベントキャンセル時に参加空き枠が減らない。
  • イベント予約とキャンセルのリクエストを大量に送るとDBのデッドロックが発生する。
速度チューニング
  • イベント一覧のGETリクエストを受け取るとN2+1のSQLクエリが発行される。
  • DBのテーブルに適切なインデックスが貼られていない。
  • Nginxのworker_process、worker_connections等の数値が極端に少ない。
  • Nginxでキャッシュを行っていない。

その他、自分が聞き逃していたり解説に入りきらなかったりした要素があるとは思いますが、だいたいこんな感じだったと思います。

自分が取り組んだこと

~1時間

最初の1時間は環境構築にほとんどの時間を費やしてしまいました。これが事前に環境構築の準備を進めておくべきだったと反省した理由です。

特にsystemctlコマンド等の操作に慣れておらず、アプリのDB接続等に躓いてしまいました。普段は便利なDockerを使っているのですが、便利なツールばかり使っていては駄目だということを思い知らされました。

またこの時間帯に躓いている点について主催者の方にSlackで何度か質問をしたのですが、当日ドキュメントに既に書かれていることを聞いてしまったことも反省しています。ドキュメントがある以上、目を通すだけではなく繰り返し読み込むことが重要だと学びました。

最終的に、主催者の方から「何も変更を加えてなくてもベンチマークを一度実行してみるといいよ」というアドバイスを頂きベンチマークを実行したところ、ベンチマークの実行ログからどのようなバグが潜んでいるかが読み取ることができることを知り、修正すべき点を把握しアプリケーションの改善に進むことができました。

1~3時間

この時間は着実にスコアを伸ばすことができた時間でした。具体的にはベンチマーク実行ログのHTTPステータスコードから予想されるバグ部分を見ていき、サーバーサイド実装のバグを修正していました。

そしてバグの修正を進め、スコアとともに負荷レベルが上がって行くと、デッドロックが発生するリクエストが送られるようになりました。デッドロック自体の単語は知っていたのですが、自分の理解が足りておらず、参考実装のコードのどこに問題があるのかを見抜くことができずに最後の1時間を迎えました。

3~4時間

この時間はデッドロックの解消を一旦諦め、SQLクエリの高速化をしようとデバッグを行った時間でした。 ただしこちらも結果として高速化をできたのはわずかなもので、一番のボトルネックであったN2+1のクエリ発行まで頭が回っていませんでした。

今回自分は、参考実装のメソッド等の機能を崩さないように、なるべく変更点が少ないコードの修正を行っていきましたが、根本的な大きな問題を見抜く視点が足りていませんでした。確かに動くアプリケーションを作るために修正を細かくすることも大事ですが、時には大きく実装方針を変えたほうが問題の解決につながるということを身を以て学びました。

競技終了5分前になるとベンチマーク実行の申し入れが締切られ、その後競技が終了しました。

競技終了後

懇親会

競技終了後、主催者の方が再起動試験を行うための空き時間があったため、参加者の懇親会がありました。ピザを食べながらLITALICOさんに在籍しているエンジニアの方々の雰囲気を知ることができ、充実した時間になりました。

結果発表

そして再起動試験完了後、主催者の方による結果発表と解説が行われました。

自分の順位ですが、なんと再起動試験に引っかかり失格となってしまいました。最後の最後に粘っていた部分のコードがエラーを起こしていたことが原因だったようです。「アプリケーションは動かなければ意味がない。」という考え方を自分の失敗から体感しました。

解説

解説では、先ほどアプリケーションの改善要素でまとめたようなバグ修正や速度チューニング要素の解説がありました。社内イベントということもあるのか、参加者同士や参加者と主催者間で積極的な議論が飛び交っていました。

また自分自身も、分からない部分をなくすためにたくさん質問をしました。するとそのどの質問にも基本的な部分から丁寧に説明をしてくださり、自分にとってとても学びの多い時間となりました。

競技の反省

自分が今回、LISUCON競技で思ったようなスコアを出すことができなかった一番大きな理由は、単純な知識・経験不足であったことかなと思います。特にNginxとSQLに関する知識です。

Nginx

Nginxは個人開発のデプロイ時に使ったことはありましたが、設定ファイルの記述はネット上の記事のコピペで済ませてしまっていました。そのため、プロキシサーバの役割を全然理解できていませんでした。Nginxの設定ファイルに目を向けていればスコアを伸ばすことができたと反省しました。

SQL

SQLはこれまでにGolangScalaでサーバーサイドの実装等をして、何回か触れてきた技術なだけに根拠のない自信を持ってしまっていました。いわゆる「完全に理解した」状態になっており、自分が表面上の知識しか持ち合わせていなかったことを自覚しました。

今回の競技でいうと、インデックスによる高速化、デッドロックの解消、N+1問題の解消に関する知識・経験が足りていませんでした。

特にN+1問題は、どんな問題なのかの理解をしていただけに悔しい思いをしました。問題を理解していても、実際に実装されたコードのどこに問題が潜んでいるのかを見抜くことができなければ意味がありません。知識は持っているだけではなく、実際に役に立てることができるようにしなければいけないということを学びました。

最後に

後日、LISUCONの競技環境を簡単に構築することができるようにGithubリポジトリが共有されました。

makeコマンドだけで簡単にWebアプリケーションやベンチマークが立ち上がるようになっていたのはとても助かりました。主催者の方の手厚いサポートには頭が上がりません。

今回自分は反省点が多くとても悔しい思いをしたため、自宅で時間を計って再チャレンジをしました。再チャレンジでは前回の反省点を生かし、解説された修正要素全てに手をつけることができました。

前回よりもスコアや負荷レベルを上げると、また新たな問題が出てきて思ったようにスコアは伸ばせませんでしたが、自分の成長を感じることができました。

その後スコアをギリギリまで伸ばそうと、Ruby・Nginx・SQL等の勉強をしていたところ、週末休みの土日を全て溶かしてしまいました。ここまで夢中になれたのは久しぶりだったので、とても充実した週末になりました。

今回LISUCONに参加してISUCONの魅力を体感し、自分のエンジニア生活の中で大きな経験をすることができました。

このような良い経験をさせていただいた、LITALICOさん、主催者の方々、一緒に参加をした方々には感謝しかありません。

今度は本家ISUCONにもチャレンジしてみようと思います。 本当にありがとうございました。