きょこみのーと

技術に関係ないほうのブログ

ISUCON9予選にk02で参加して完全敗北しました #isucon

いつものメンバーでISUCONに参加して完全敗北...! いつもどおりGo書く人を担当。 最大スコアは3,120で、最終結果は fail 。

以下メンバーの感想。

alligatorswamp.hatenablog.com

事前にやったこと

  • scrapboxに色々使いそうな記事をまとめたり
  • ISUCON8予選の過去問の環境を構築して模擬したり
  • 使うツールの選定など

ISUCON9予選当日の作業の流れ(kyokomi目線)

  • 10:00 開始
    • ドキュメントを読む -> 読んでる途中にAlibabaでの環境構築を先にやったほうが良いと判断
  • 10:15 〜 10:15
    • Alibabaの環境構築完了
    • sshできることと、アプリケーションにログインできることを確認した https://gyazo.com/b8705539ea9092849d86721548d54399
    • 速攻でベンチマークを実行する image
    • ベンチ実行によってクレジットカードの認証が通らなくなったことに気が付かずメンバーの二人がわちゃわちゃしてた
      • しばらくjsのコードとか見た後にレギュレーションに書いてあったこと気がつく...
  • 10:00 〜 10:30
    • githubにpushする
    • scrapboxにメモってた手順のpush先が事前に素振りしたときのrepositoryになってて無駄に混乱した
    • image
    • github tokenでシュッとpushできるようにする手順書いてたのは正解だった
  • 10:30 〜 10:50
    • ファイル構成把握しながら、不要なファイル削除したり、gitignoreの設定を追加
    • ローカルで起動するようにflag追加、docker-composeの追加など
    • 初期データがローカルでなくて動かないことに気が付き120MBもあることからgitignoreされてるというやさしさに気がつく
  • 10:50 〜 11:30
    • テーブル構成を把握したかったのでER図作ろうとして外部キー貼ったら、初期処理でエラーになって「う〜ん?」って調べてたが本質ではないな...と30分くらい無駄にしてホワイトボードに手書きした
  • 11:30 〜 12:10
    • main.goのコードが長く、目的のコードがさっと見つけられず大まかな機能単位でfileを分けるリファクタに手をだした
    • 見通しはよくなったし改修時の対象を探すのも楽になった感じはある
  • 12:10 〜 12:30
    • Prometheusで監視できるようにmetricsのhandlerを仕込んだり
    • image
    • 結局ほとんど使わなかった...
  • 12:30 〜 13:30
    • マイページのtransactionsの取得がボトルネックぽいということで見始める
    • `status IN (?,?,?,?,?) AND ` がサクッと見て無駄そうなので消した(全ステータス指定してたので)
    • indexを貼った。queryの負荷はそこそこ減ったぽい(スロークエリ曰く) image
  • 13:30 〜 14:00
    • categoriesが32万回くらいselectされてたのでサクッとcacheした
    • 100〜1000回くらい?まではselect回数が減った(レコード数は40くらいなんだけど)
      • これはinitで全レコードcacheしたほうがよかったなとあとから思った
      • 一旦、できるだけ既存の実装から離れないように〜というポリシーでこうしてた
  • 14:00 〜 14:40
    • usersもcacheした
    • この時点の3120点になってた(そしてこれが最終的に最大スコア...)
  • 14:40 〜 15:00
    • なんかスコア上がらねーなと思い、このままgetTransactionを見ていっていいのか???と不安になり
    • キャンペーンを有効にしてみる?という話になって1に設定した
    • 結果なんかめっちゃエラーになる
    • そしてAPIGatewayErrorとtoo many connectionsがでまくる
    • DBのCPU使用率も落ち着く(これはミスリード...)
    • これを解消するのが鍵では!!!!!と作戦を変更(これが失敗だった...)
    • MaxConectionはアプリ側は一旦120に設定し、DB側(3号機)で300くらいに設定して一旦でなくなった
    • APIGatewayの502エラーが自分たちのNginx?と勘違いしてulimitか!!とか結構時間無駄にした
      • よく考えたらアプリログでNginxのログでるのおかしくね???ってなり、そこでようやく外部サービスやん...って気がつく
  • 15:00 〜 17:00
    • とりあえずログやmeasureでどれくらい外部APIが叩かれてるのかを可視化したり
    • statusの取得が無駄っぽいから wait_done 以外は shippings のテーブルの結果を見てresponseに設定したりを入れてリクエストを減らしたり
    • item購入時にreserveするの不要そう?(実際にshipするときでいいのでは)と判断し、shippingsテーブルのreserve_idとかをNULL許可にしてうまいことshipするやつだけreserveの外部APIを叩くようにしてリクエストを減らしたり image
  • 17:00 〜 18:00 終了
    • ずっとキャンペーン有効による外部APIのGatewayTimeoutをなんとかせねば〜と試行錯誤していてFailしたままなのでなんとかしなければと焦り始める
    • 502エラー速攻で返すくらいならタイムアウトギリギリまでRetryしたほうがいいのでは?と、適当に1秒sleepして3回までRetryするbackoff的な実装を強引にGOTO文で実装したりしたがしかし...
    • 結局最後は10回Retryしてタイムアウトになり、じゃあ5回だ!!とか完全にヤケクソ状態の山賊状態だった...
    • 10ってコメントのpushなのにコードは10 -> 5に変更っていう...もうむちゃくちゃ...
    • もう何と戦ってるか本人達もわかっていないまま試合終了してしまった... 〜完〜

まとめ

  • 想像を上回る良い出題ですごく楽しかったです
  • レギュレーション大事だよな...!って毎回わかってるつもりだけど終わるまで色々気づけてなくて悔しい
  • なんかいっぱいAPI叩かれてるね。なんかめっちゃCPU上がってるね。の深堀りができる状況になってなかった
  • 悔しい...!来年こそは...!

ISUCON8予選を突破しました!!!!!!!

k02というチームでISUCON8予選に参加し、予選を無事通過して本戦出場が確定しました。

感想と色々と良かった点や反省点をまとめようと思います。

やったこと

主にgolangの実装を改修を担当してた。

  • githubやgitまわりの設定
  • N+1の対応を何箇所か対応
  • reservationsテーブルでFOR UPDATEしてない箇所の対応
  • ORDER BY RAND() LIMIT 1してるやつをリストで取得して、golang側でシャッフルして1件選ぶ実装
  • 無駄にeventsやsheetsを取得してる箇所を修正
  • reservationsテーブルにuser_idのindexを追加
  • Adminのreportのsqlを @yasu が改善してくれてそれを組み込んだ

良かった点

  • 事前にk02用のkibelaを用意した
    • 当日の作業ログとかに埋もれてしまうpassやip、deployコマンドなどなどをslackを辿らずに調べられるようにするため
  • 横並びで全員外部モニタがある状態の会場を用意した
    • コミュニケーションコストを下げた
  • 序盤にちゃんとサービス触って理解する時間をとっていた
    • これによって途中で怪しい挙動してるときにrevertする決断が早かった
    • Lock周りの挙動がイメージしやすくなった
  • DataGripでER図をさっと作成していつでもデータの関連を見れるようにした
  • h2oはなんかパッと見そのままでも問題なさそうと @waniji が判断し、ひたすらDatabaseのチューニングに全力を注いだ
  • 流石に4回目だからか山賊してもスコア上がらないのはみんな理解してて冷静に状況判断できてたのかなと思いました
  • 去年は一発逆転でめちゃくちゃして結果Failしてたので、Failが発生しないように安定するのに注力できたのは良かった

kibe.la

f:id:kyokomi:20180918113212p:plain

反省点

  • チームの作業担当がふわっとしていて、後半までみんなウズウズしていた
  • nginxかなーと思って用意してたgoaccessとかが使えなかった
  • 自分以外がほとんどコードに手を付けられなかった(golang慣れしてて一か八かdeployを繰り返してた)
    • これは手元で動作する環境をさっさと用意しなかったのが一番の原因
  • sqlxの導入やちょっとしたリファクタリングができず終始しんどいコードを読んでた
    • これも手元で動作する環境さっさと用意すれば、悩みながらリファクタしていけて結果的にコスパ良かったと思う

以下とかもさっさとsqlx入れれば何回か実行エラーになってたタイムロスしたのを回避できたはず...

感想

今回は、飛び道具よりも愚直にSQLを改善したりindexを貼っていくのが大事な題材だったな〜と思いました。

普段仕事でやってるようなSQLをこねくり回して実行計画をみたりER図みたり、サービスの挙動としてあるべき姿をイメージしてみたいな感じでとても良かったです。

alfred-esa-workflowに検索結果から正規表現で文字列を抽出するコマンドを追加した

github.com

昔作ったこれに久しぶりに機能を追加しました。

何故作ったか?

日報に 良かったこと/悪かったこと/所感 などを毎日書いていて、2週間ごとの振り返りで漁ったりしてたんですが、いい感じに抽出したいな〜というモチベーションから機能追加しました。

使い方

※日報に記載した 悪かったこと の内容を抽出する例になってます

f:id:kyokomi:20180128175501p:plain

抽出した文字列(クリップボードにコピーされます)

## general/日報/2018/01/12/kyokomi
- ピザ食べすぎた...


## general/日報/2018/01/11/kyokomi
- とくになし


## general/日報/2018/01/10/kyokomi
- とくになし


## general/日報/2018/01/09/kyokomi
- 休み明けで体がまだなまっていて眠い... :zzz: 

....続く

設定変更方法

日報のテンプレートがウチは違うんだよな〜という方もご安心ください。

Show Alfred Preferencesを開いて、以下のRun scriptの引数を変更してください。

f:id:kyokomi:20180128180233p:plain

f:id:kyokomi:20180128175612p:plain

./alfred-esa-workflow regexp 以降の引数は、以下の内容になります。

  • ユーザ名(必須): "{query}"
  • 検索キーワード(必須): "日報"
  • 検索結果から文字列を抽出する正規表現(必須): "# 悪かったこと([\s\S]*)# 所感"
  • 抽出結果のprefixにつけた文字列: "## "

カスタマイズ

基本的に自分の振り返り用なのでいちいち引数に自分のusername設定するのめんどいという方は、こんな感じに改造すればさらに便利になります。

f:id:kyokomi:20180128180949p:plain

f:id:kyokomi:20180128181002p:plain

おわり

ちなみに制御が面倒だったので1回のGETリクエストで取得できるデフォルトの件数(20件)しか取得しないようになってます。

需要があったら改修しますのでご連絡もしくはPullRequestお待ちしてます( ^ω^)

なんとなくEthereum入門してERC20トークンをテストネットに作成するまでやった雑メモ

ちょっと調査する機会があったので、自分メモ的な感じで残しておく。

ブロックチェーンやEthereumについての概要

ざっとこの本を読んで、コマンドとか写経しながら実際にローカル環境で試してなんとなく理解した。 セキュリティ周りの事例の話とかも結構してくれて大変なんだな...というのを実感できて良かった。

ERC20トークンについてなど

ざっとインターネットで独自トークンの発行をするにはどうしたらいいんだろう?とググってたら Ethereum Advent Calendar 2017 - Qiita にたどり着いた。

とりあえず25日分をざーっと読むとみんなERC20トークン作っててなるほど〜って感じだった。

主に参考になった記事はこちら

tech.pepabo.com

qiita.com

truffleがすごい便利だった

普通にプログラミング経験者だったらこれで何も考えずにERC20トークンをつくるところまでいけそうだな〜と思った。(その後困りそうだけど)

Migrationの挙動がよくわからなかった...(T_T)

一回目のmigrateはうまくいくけど、tokenの量とか変更して二回目のmigrateするとなんかエラーになる... 理由は正直わからんかった... -resetとかすればうまくいくけど、migrateに期待してる挙動はそうじゃないので困った。(誰か知ってる人がいたら教えてください...)

./node_modules/.bin/truffle migrate --network ropsten
cricket rib insane siege quote scorpion slot seven dynamic motor innocent kind
Using network 'ropsten'.

TypeError: Cannot read property 'call' of undefined
    at /xxxxxxx/node_modules/truffle/build/cli.bundled.js:176221:50
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)

SolidityのIDEについて

Remixが一番よさそう? Remix - Solidity IDE

安定のInteliJ IDEA pluginもある様子だけど補完とかがうまいこと効かなかった... (設定かな?) Intellij-Solidity :: JetBrains Plugin Repository

go-ethereumで適当なCLIツール作ってtransactionを呼び出す

この辺を参考にした.

github.com

lotz84.hatenablog.com

コード自体はすぐにgenerateして簡単に実行できた。gasの設定をちゃんとしないと結構実行に失敗する。

GAE/Goにdeployしようとしたけど、どうやらcgoを一部利用している様子でdeployに失敗した。(残念)

github.com/ethereum/go-ethereum/crypto/secp256k1 とかだった気がする

セキュリティについてとか

必読っぽい: https://github.com/ConsenSys/smart-contract-best-practices

日本語訳がある...圧倒的感謝...!: https://github.com/sot528/smart-contract-best-practices/blob/master/README-ja.md

まとめ

なんかすごく色々な方々のお陰で参入の障壁は下がってきてるけど、セキュリティとかまともに運用してる事例がまだまだ足りてなさそう?

その辺を「やっていくぞ!」って人じゃないと本格的な参入は難しそうですね(KONAMI) という印象でした。

AnnictのAndroidアプリをKotlinでつくった

Kotlinの入門がてら作ったのですが、リリースに至るまでの流れとか利用してるライブラリとかの話しをしようかなと思います。

play.google.com

ざっくり以下の話しをしようと思います。

  • 作ったものについて
  • 開発期間について
  • Kotlinについて
  • 利用したライブラリなどについて
  • CIについて
  • タスク管理について

作ったものについて

f:id:kyokomi:20180110223121p:plain

画面はこんな感じで普通にRecylerViewでのリスト表示です。 今回は、Android Architecture ComponentsPagingLibraryを使ってかなり楽できました。(またあとで説明します)

このアプリの自分の用途について

毎クール30作品とか全部見てると時間がいくらあっても足りないので、 視聴中アニメでモチベーションが低くなってる作品のステータスを(見てる -> 一時中断 -> 視聴中止)にちゃんと更新したかった。 というモチベーションで作りました。

どのアニメ観ようかな〜とかの用途ではなく、観てる前提で自分は何を観るきなくしているのか?や自分が次に観るべきアニメはどれなんだというのを把握して確実に消化していく用途です。

ちなみに視聴時の自分ルールはこんな感じ

  • 今期で3話以上未視聴が溜まったら一時中断にする
  • 一時中断にしたものはクールの終わったときに振り返って見るかどうか?を他の人のレビューなどを参考に決める
  • ここで見ないを選択した場合は、視聴中止にする

アプリ利用の前提条件

  • Annictを結構使ってるユーザー
  • 大体今期やってるアニメを把握してる
  • Annictのチャンネル登録をちゃんと設定している
  • まとめて視聴したりせず、毎日今期アニメを消化しつづけているアニメ好き

「今期はこれだ!」みたいな1点読みとかしないで、ほぼ毎クール7割近くの作品の数話を観て徐々に観る作品を削っていく感じの人だと尚良い

開発期間について

最初に12/2くらいに開発をスタートして、最低限の機能を1日〜2日くらいで作ってちょこっとバグ直したりしてたのが12月前半。
年末までちょこちょこ触って、1/4〜1/8で一気に仕上げました。

12中旬くらいの時点でそこそこ動いてたので、わりと毎日個人的に使ってドッグフーディングできてたのは結構モチベーションにつながってよかった。 後は「やるぞ!」って気持ちと一気にやる時間があるのがやっぱり大事ですね。

f:id:kyokomi:20180110223819p:plain

f:id:kyokomi:20180110223058p:plain

f:id:kyokomi:20180110223050p:plain

Kotlinについて

Kotlinについてですが、とにかく書きやすくてコード書いてて気持ちよかったなぁ〜という感じでした。事前に以下の書籍を読んでいたので、ひとまずほとんど困らず開発できました。 ただ、もっとうまく書けたのかな〜とか思いながら書いたコードが結構あるので、今後もリファクタリングしていければと思います。

Kotlinイン・アクション

Kotlinイン・アクション

Kotlinスタートブック -新しいAndroidプログラミング

Kotlinスタートブック -新しいAndroidプログラミング

利用したライブラリなどについて

PagingLibraryについて

今回特に役立ったこちらについてもうちょっと説明。 とは言え、以下の図を見るのが一番早いw

https://developer.android.com/images/topic/libraries/architecture/paging-threading.gif 画像引用元: https://developer.android.com/topic/libraries/architecture/paging.html

今回で言うとRoom経由でSQLiteのデータがそのままRecyclerViewのリストに対応している感じになってます。 例えば、新しいデータをInsertすると参照しているRecyclerViewはハンドリングするコード等書かずにPagingLibrary内で notifyItemInserted(position) を呼び出してくれます。Deleteした場合は同様に notifyItemRemoved(position) ですね。

つまり、SQLite側のデータをどう更新するかを意識するだけでViewにはいい感じに反映してくれるという感じで最高でした。 もちろんLiveDataなので、画面回転時などにActivityが再生成されてもちゃんとobserveするコードが再度呼び出されてクラッシュするようなことも無くかなり楽でした。

ただ、かなりレールに乗ってる感はあるのでちょっとレールを外れるようなことをしようとすると、SQLiteに変なデータを突っ込んで無理やりViewHolderの処理でハンドリングして〜みたいな感じしかできなさそうな点などある程度諦めが必要かもしれません。

が、めっちゃ開発は楽になったので今後も使っていきたいと思います!

CIについて

www.bitrise.io

今回、Bitriseを初めて使いました。とにかく最高でした。 過去にWerckerやCircleCIでAndroidのbuildをしていたときに比べてやることが全然無くて、殆どがWebコンソール上で完結してとにかく最高でした。 keytoolの管理等もいつも悩まされていたのを管理してくれたりGooglePlayStoreへUploadするstepも用意されていたりなど助かりました。

CircleCIやwerckerだとたまに謎のメモリ不足?とかのbuild失敗があったのですが、それも発生しなくなった気がします。

タスク管理について

Zenhubを使ってやりました。ポイントの見積もりは結構雑だったんですが、 サクッと終わらせられる粒度にタスクを分割してたのでまあまあいい感じだった気がします。

f:id:kyokomi:20180110231734p:plain

タスクの一部を抜粋したものがこちらです。最初にばーっと10タスクつくら作って優先度決めて開発を進めていくうちにドンドンタスクを追加して、その都度優先度を変えてみたいな感じでガンガンやってました。

f:id:kyokomi:20180110231925p:plain

今後

ひとまず細かいバグ修正を優先していこうと思います。 現状AnnictのWeb側で設定する前提になっているチャンネル設定とか視聴状況の変更とかもアプリ内で出来るように〜とかも気が向いたらやるかもしれません。

バグ報告とかお気軽にお待ちしておりますので〜何卒お手柔らかに〜

2017年振り返り(技術編)

2018年を振り返るとき用にメモ書きを残すことにした。

Go

インフラまわり

  • 仕事はAWS使ってたので、この一年大体普通のWebアプリケーション作る分には、1から運用までやれる気がする
    • ただ、ecsとか自分が使い慣れてるものを使うに限る...
  • GCPはほとんど触ってない
  • FirebaseAuthは仕事で使ってたので結構ハマりどころとかわかる
    • Twitterの認証がなんか結構地雷なので辛かった
    • メールのtemplateとかも痒いところに手がとどかない感じだった
    • 昔に作ったProjectのメールtemplateを日本語に変更できないとかあったな
    • export機能がないので別のサービスに移行するのが困難
  • FirebaseAuthで痛い目にあったので、Auth0を使うようにした
    • 色々なProviderに対応してて結構いい感じだった
    • そこまで悪い点はないけど、tokyoリージョンないのでオーストラリアにしてたというくらい?
    • 将来の規模感とかちゃんと考えて、auth0使うのはありかも
    • 認証時のCallbackをjavascriptでいじったりできる機能があったのは感動した
  • terraformは、前半は結構触ってた
    • terraform最高かよって気持ち
    • 大体AWSコンソール上で手で作っていい感じだったらterraformで組んでみるという流れ
    • 大体terraform公式のドキュメントみたら分かるのでなんとかはなる
    • count周りを乱用してapplyしないとこのcountが解決できないんだけどapplyが失敗するみたいなデッドロック状態でハマったことがある
    • 最近は、自分よりガッツリterraform見れる人が現れて任せてしまってサボり気味

Android

  • 仕事でiOSアプリをちょっとつくっていた時期があって、Androidもやるかも?と思って復習してた
  • 個人アプリをkotlinで書き直したり
  • クリーンアーキテクチャ推しだったんだけど、最近はAndroid Architecture Componentsで書いてる
    • Paging Libraryとかがすごすぎるんだけど、ちょっと変わったことやろうとするとSQLiteのデータをいじらないといけなくて... う〜んってことがあった
    • RecyclerViewの最後まで行ったときに続きを取得するクルクル表示のViewとかを差し込みたいときなど
    • LiveDataで取得している箇所が、SQLiteのデータを更新したら反映されるというはマジ最高だなと思った(KONAMI
  • やっぱAndroid開発は楽しいな〜というのを思い出したり
  • 最初の会社辞めたときにAndroid開発がしたいので!って言ってたなというのを思い出した
  • 次の会社はGoが書きたいので!って言って辞めたきもする( ^ω^)
  • Kotlinが結構いい感じなので2018年もやっていきたい

Unity

  • 前半は結構触ってた
  • 2Dで放置ゲーをクライアントを作ってた(またエターなった)
  • VR周りの開発は正直数学の知識が足りなくてしんどかった
  • 普通にuGUIとかでUI組んでC#API叩くコード書いて〜みたいなのは普通に出来るレベルにはなった
  • とはいえ2Dの開発ばっかりしててもと思って、3DのSRPGを作ってたいた時期もあった(6〜7月)
  • またエターナってしまったようだな(やる気はあるんです...!)
  • 今年は触る機会あるかな〜?わからん...

iOS

  • やるぞやるぞ!!って思ってたらやることなく終わった
  • 縁が無い

Kotlin

  • 12月くらいからServerSideKotlin書き始めた
  • とりあえずSpringBootで入門中(まあなんでもいい)
  • herokuでもいいんだけどGAEが好きなのでGAE/Kotlinで動かしながら色々触ってるレベル
    • なんかよくわかってないけど、GAE/Kotlinやってる人がググってもあまり情報でてこないので適当にblogに書いていくつもり
    • HelloWorldまでして終わってる人は沢山みた

個人タスク管理

  • Trello -> Asana -> Zenhubという激しい入れわかりだった
  • 一旦zenhubで落ち着いている
  • 欠点をあげるとprivateのtaskを管理しているので、Githubの草が無駄に増えてしまう点(githubとシームレスにという利点でもあるのだが)
  • 個人の生産性をバーンダウンチャートで可視化できるのは結構良い
  • ちなみに先月はこんな感じ f:id:kyokomi:20180104232219p:plain
  • iceboxに1ヶ月以上先にやりそうなタスクをいれる、backlogに今月やる予定のものを雰囲気でポイント見積もりしていれる
    • 読書とか個人開発とか
    • 読書はぶ厚めの本の場合(1日で読めないもの)は章単位でタスクに分割したりしてる(こんな感じ) f:id:kyokomi:20180104232516p:plain
    • 〜を買うみたいな買い物系とか一瞬終わる系はtodoistで管理している(個人生産性という観点でいれるようにしている)
  • boradの機能とepicという概念が今のところ重要
  • githubの上に乗っかってるのデータの持ち方やもっさりしてるところはデメリットではある
  • 最強のタスク管理ツールは未だに探してる...

最強のメモ帳

  • 最強のMarkdownツールが沢山合った記憶...
  • 結局Evernoteを廃止してinkdropに落ち着いている
  • 月額払うのを決めた(11月くらい?)。そろそろ年間契約にしてもいいかもしれない
  • まあEvernoteでも良かったんだけどやっぱMarkfownで書きたいという欲が強がね...
  • あとEvernoteで長文書くとめっちゃもっさりしてた時期があってストレスだった
  • Inkdropは作者がすごいスピードでレスくれたりバリバリ開発してくれてるので枯れるまでは使い続けそう(枯れたらどうなん...というのはわからない)

2017年を振り返る

今年もTwitterを遡って振り返ってる。そのため、いろいろなイベントを取りこぼしてるはず。

1月〜5月

  • ひたすらcluster.のロンチに向けて仕事してた気がする
  • 5月にロンチしたが、初回のイベント人多すぎて爆死した panora.tokyo

6〜7月

8月

9月

10月〜11月

12月

アニメ

  • 劇場版なのはさんを観た:
    • 観てる時にあれ、これ収集つくのか?とか思ってたら2部構成だったときの顔してた
  • 劇場版プリヤを観た:
    • 思ってた以上にプリズマシロウだったけど良かった
  • 劇場版Fate/stay night[Heaven's Feel]を観た:
    • ひたすら最高だった。原作またプレイしたくなったけど我慢する

ゲーム(クリアしたもののみ)

まとめ

  • 毎年、国士無双和了してる気がするので来年も実績解除するぞ
  • 個人Webサービスは結局作れなかった...個人開発のゲームもロンチできなかった...
  • Goは結構相変わらず書いてた
  • ドメイン知識以外のところで迷わなくなって開発速度Upを感じた
  • Kotlinを一応覚えた。書いてて結構気持ち良いので来年もやっていく
  • 仕事とのバランスをうまく保ててるようでバランス悪かったような気がした(メリハリがイマイチだったような?)
  • 仕事で必要なスキルや知識が技術面よりも組織とか開発体制みたいなところに寄ってる気がしてなんかモヤモヤ
  • 技術のステ振りとか何やっていくかとか今後何やりたいのかとかちゃんと考えていかないとな〜と思った