年末ポエム2022

1 年を振り返ります。今年は色々ありました。

1 月

CAMPHOR- の運営メンバーになった。CAMPHOR- は去年の 8 月ぐらいから遊びに行くようになり、特にきっかけとかなかったんですが「運営メンバーやってみない？」とお誘いいただいたので参加。なんと来年からは副代表です。CAMPHOR- はなんかイケてる感じの町家をコワーキングスペースとして開放しており、たまに楽しいイベントなどもやっています。ぜひきてください。

2 月

PortX というスタートアップでの開発にパートタイムで参加し始めた。SaaS の開発をしており主に Go でバックエンドを書いている。

3 月

留年が発覚。

メルカリの短期インターンで genq という C# の LINQ を Go で再現したものを開発した。

あと、ゆめみの短期インターンで AWS に入門するなどした。

4 月

マネフォのインターンで Go を書いた。

AP を取った。

GSoC に応募した。

この期間はなかなか忙しかった。

5 月

あまり覚えていなくて多分割と暇してた気がする。GSoC 受かってウキウキしてたことぐらいしか記憶にない。

あとは CAMPHOR- の Kubernetes クラスタの管理をやるようになったのがこれぐらいの時期だった気がする。

6 月

PortX の経営合宿というので長野に連れて行ってもらった。イケてるコテージでうまい肉を食べるなど大変楽しかった。

長い長い GSoC が始まった。週 2 で行われる英語ミーティングで毎回体力をすり減らしていた。

7 月

毎日のように ISUCON の素振りをしていた。かなり気合が入っていたと思う。気合が入りすぎて GSoC の進捗を犠牲にしていた。

残念ながら結果は予選落ち。かなりしょげました。

8 月

GSoC がうまく進まず焦っていた。謎のバグに苦しめられ続けてかなりつらかった気がする。でも Midterm Evaluation はちゃんと通ったので安心した。

9 月

クックパッドのインターンで Ruby で書かれたレガシーな広告配信サービスを Go にリプレースするということをやっていた。Ruby を読むのがつらかった。初めての物理出社インターンで楽しかった。(出社してたのはラスト 1 週間のみだったが)

10 月

GSoC のメンターにお呼ばれして G 社のオフィスに遊びに行った。

サイバーエージェントのインターンで Kubernetes Autoscaler に gRPC Expander というプラグインを入れるというのをやった。

11 月

Zig で自作 OS をやり始めた。

GSoC をついに修了した。

12 月

GSoC でやった内容を Linux upstream に送った: LKML: Soichiro Ueda: [PATCH] virtio_balloon: high order allocation

総括

今年は本当に色々あった。Web 開発、インフラ、カーネル開発など、上から下までさまざまなレイヤの開発ができ、幅広い技術に触れることができ、大変楽しかった。どれもこれも留年したおかげです。

で、色々な開発をした結果思ったことがあり、あまり「いわゆる Web 開発」みたいなのは自分はそんなに好きじゃないみたい。もちろん嫌いではないのだが、機能開発などすることで直接的に価値創出をすることよりも、基盤技術的なものを開発することで価値創出の下支えをすることの方が楽しいと感じる。なのでこれからは OSS とか SRE 的なことをやっていくと幸せになれるかもしれないとぼんやりと思った。

来年の抱負

  • 院試を頑張る
  • 未踏に応募する
  • Zig で自作 OS をもっとやっていく
  • OSS にたくさんコントリビュートする
  • 英語を頑張る

良いお年を。

Google Summer of Code に参加した話

この記事は CAMPHOR- Advent Calendar 2022 の 24 日目の記事です。

クリスマスですね。みなさんはいかがお過ごしでしょうか。僕は金曜ロードショーでホームアローンを見たりコストコへショッピングに行ったりします。

ところで、Google Summer of Code 2022 に Chromium プロジェクトに参加してきたので、参加しようと思ってからプロジェクトを終えたあとまでの話を一通りしようかなと思います。

summerofcode.withgoogle.com

GSoC とは

Google Summer of Code - Wikipedia より

Google Summer of Code (Googleサマーオブコード 略称GSoC) は2005年の5月から8月に初めて開催され、その後毎年行われている恒例のイベントで[1]、Googleがフリーソフトウェアやオープンソースのプロジェクトを指定し、その夏の間に課題をクリアした数百人の学生に賞金を支払う制度である。

要するに数ヶ月ほど OSS にコントリビュートして Google からお金をもらうというプログラムです。実は Wikipedia の情報が遅くて、現在では対象者は学生に限定されておらず、期間も秋の終わり頃まで延長することができます。

2022 年の GSoC のスケジュールが公開されています: https://summerofcode.withgoogle.com/programs/2022

参加するまで

GSoC の存在を知ったのはさんぽしさんのブログを見たのがきっかけでした。OSS 自体にそこまで興味があったわけではないんですが、大規模な OS の開発をやってみたいというのはぼんやりと思っていたので、GSoC を機にやってみようと思いました。

3 月ごろに GSoC でコントリビューターを募集する OSS プロジェクトの一覧が発表されたので、その中で OS の開発ができそうなものをいくつかあさりました。HaikuOS や FreeBSD なども候補に上がったのですが、最終的に応募したのは Chromium のみでした。頑張れば複数の OSS に応募することもできたのですが、ちょっとしんどかった。

Chromium

Chromium プロジェクトは Chromium のみを管理しているわけではなく、ChromiumOS という Chrome に対する Chromium の ChromeOS 版みたいなものも持っています。というわけで ChromeOS 絡みの開発もやってます。

2022 年に Chromium が出していた Idea List こちらです: https://docs.google.com/document/d/1QnqhnsmEnHxoD1j7sWNFL5nybQ7rh5bMgPuf3NQLAtg/edit この中の 7 つ目、VirtIO Balloon Performance Improvements というテーマに興味を持って応募を決めました。

どんなテーマかというと、Linux kernel の VirtIO Balloon のドライバの CPU 使用率が高いからそれのベンチマークをとってパフォーマンス改善してみようという内容です。

VirtIO Balloon とは何かというと、VM とホストマシンの間でメモリを共有する仕組みです。VirtIO のデバイスの一つとして実装されています。

具体的なゴールが定まっていないためなかなかハードなテーマでした。

プロポーザル

これに応募しようということで、プロポーザルを書こうと思いました。まずはこのテーマに応募する前にやっておいてほしいことリストが公開されていたためそれをやりました: https://docs.google.com/document/d/1l8Tp-HJAJInqv2Yld_L2PazQX-bh6Z41ikDdBvSe270/edit

  • VM 上で Linux を動かし、VirtIO Balloon を動かしてみる (VM は crosvm で立てた)
  • VirtIO Balloon ドライバの CPU 使用時間を測ってみる

といったことをやりました。やってほしいことリストには他にも「実際に改善を加えてみよう！」とかもあったんですが、さすがに厳しくて諦めました。

そしてそれに加えて Linux と crosvm のコードを読んだり記事を調べたりして VirtIO Balloon の仕組みを理解し、プロポーザルを書きました。

これまでやってきた中で理解した内容をすべてアウトプットするように努めました。また、さんぽしさんのブログを参考にして、スケジュールをできるだけ具体的に書くなどしました。

出来上がったのがこちら: https://docs.google.com/document/d/1yKPODnqaGJlPQkSUjDDdS9ZiDlMDhsm2lrxBAxy0JBA/
書いた内容はこんな感じ

  • VirtIO Balloon の概要や、抱えている課題について
  • VirtIO Balloon の詳細な処理内容 (ソースコードのレベル)
  • パフォーマンス計測・評価の方法
  • ざっくりしたスケジュール

プロポーザルを書くまでの過程で、メンターにたくさんメールで質問をしました。

  • 「この手順でビルドしてみたけどできなかった」
  • 「CPU の使用時間ってどうやって測ったらいい？」
  • 「VirtIO Balloon ってどうやって動かしたらいい？」

など、やってみてわからない・できないことがあったらメンターに連絡していました。(Chromium ではプロジェクトが始まる前に各テーマごとにすでにメンターが決まっているのです。)

また、プロポーザルの初稿が書けたらそれもメンターに見てもらってフィードバックをもらいました。2 往復ほどしてメンターから「ええんちゃう？」というフィードバックをもらえたので提出しました。

このように、プロポーザルを出す段階から OSS のメンテナとたくさん連絡を取るのがかなり大事だと思いました。「迷惑かな...」とか思っちゃうんですが、恥を忍んでなんでも聞いてみるのがいいと思います。

プロジェクト開始

5 月の終わり頃にメールで合格通知が来ました。

固定ツイートにするぐらい嬉しかった。

プロジェクトが始まるまで半月ほどあったんですが特に何もしてなかったと思います。一回メンターと面談してプロジェクトの進め方の話をしたぐらいでしょうか。

プロジェクトの進め方としては以下のような感じでした。

  • 週に 1 回メンターと 1on1
    • 進捗確認
    • 今後の方針決め
  • 週に 1 回 ChromeOS Virtualization チームとのカジュアルチャットがある
    • 進捗報告や技術的な相談
    • あまりカジュアルという感じではなかったがたまに普通の雑談もしていた
  • メンターが日本に来ているので時差なし (とてもありがたい)

僕は英語喋ったことなかったので英語でのミーティングがとても大変だったんですが、Google Meet の字幕機能を使って乗り切りました。メンターも英語が苦手な僕に合わせてゆっくり話したり僕のペースに合わせたりしてくれました。とても親切な方でした。

6 月

まずはコントリビュートする手順に慣れる練習を兼ねて、crosvm の VirtIO Balloon についてのドキュメントを追加しました: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3697995

その後、ベンチマークを作成してボトルネックの特定をしました。VM とホスト間でメモリを受け渡しする部分が遅いというのがわかりました。

7 月

このメモリを受け渡しする部分のアルゴリズムに改善を入れました。

メモリの受け渡しとは具体的に何かというと、ゲストからホストに解放・または確保したページの PFN (Page Frame Number) を伝えるということをします。
そこで、現状では PFN のリストを伝えるということをします。例えば、ゲストが PFN 3, 4, 5, 8, 9, 13 のページを確保してそれをホストに渡すときには [3, 4, 5, 8, 9, 13] といった整数列を渡します。 これを、連続したページをまとめて (offset, length) のペアで渡すようにします。上の例でいうと、[(3, 3), (8, 2), (13, 1)] といった配列を渡すことになります。

この改善を入れると非常に高い効果が出ました。

ところがこの改善は VirtIO Balloon の仕様に反しています。

The driver constructs an array of addresses of unused memory pages. These addresses are divided by 409614 and the descriptor describing the resulting 32-bit array is added to the inflateq.

なのでこの改善を入れると他の環境で動かなくなるため、upstream に受け入れられません。これは調査として行ったという側面が強いです。(非常に高い効果が出たためこれについては ChromeOS チームでさらなる研究がされるとかされないとか話してました。)

8 月

今度は実際に upstream に受け入れられる改善として、メモリ割当アルゴリズムの改善を行いました。

現状ではドライバは Balloon に 1 ページずつ割り当てるようになっているのですが、これを複数ページを割り当てる必要があるときは一気にメモリを割り当てるようにするという感じです。具体的な実装で言うと、alloc_page() を使っていたのを alloc_pages() を使って割り当てるということをしました。

これを実装するにあたり死ぬほどバグを生んでしまい、3,4 週間ほどデバッグに溶かすということをやっていました。その間進捗は出ていなかったため大変メンタルに悪い時間でした。

なんとか実装した結果がこんな感じでした。

ボトルネックに効いていないためさっきより効果は地味ですが、たしかに改善しているというのがわかりました。

9, 10 月

他社インターンに行っていたためおやすみしていました。

11 月

crosvm 以外の環境で動かないという厄介なバグを発見し戦っていました。メンターがめっちゃ手伝ってくれたのでなんとかなりました。ありがとうございました...

12 月

GSoC としては 11 月末頃に終わったんですが、さらに延長線としてこの改善を upstream に送るというのをやりました。ChromeOS チームに Linux kernel のメンテナがいるため、その方からレビューいただくなどして upstream に送る準備をしました。

そして満を持して昨日 upstream に投下しました: https://t.co/ZICnAqa9Mc
果たして merge されるのか... ドキドキです。

終わり

こんな感じでだらだらのんびりとやっていたような気がします。なんたってまだ延長線の途中ですからね...
パフォーマンス改善というゴールが明確でないプロジェクトに取り組むのはなかなかメンタル的にしんどかったです。ですが憧れの Linux kernel コントリビューションのきっかけになったり、ChromeOS チームの方々とたくさんお話できたりと、本当に貴重な経験をさせていただけて楽しかったです。勇気をもって GSoC に応募して良かったと思います。
メンターの方や ChromeOS チームの方々には本当に感謝してもしきれません。特にメンターの方には本当にお世話になったんですが、最後のミーティングで英語力が不足しすぎて Thank you しか言えなくてすみませんでした。親切な素晴らしいメンターでした。

また、これを機に OSS に興味を持ちました。Linux kernel へのコントリビュートを続けていくのもできたらいいなと思いますし、Kubernetes など他の OSS にもコントリビュートしてみようと思っています。OSS を身近に感じる良い機会になりました。

GSoC やってみたい方へ

ぜひやってみましょう。GSoC の応募にありがちな障壁をまとめてみました。

プロポーザルの書き方がわからない

応募したい OSS プロジェクト側から、期待されるプロポーザルの内容などが公開されていると思うのでよく読みましょう。過去のブログなどを見て参考にしましょう。よくわからんかったらその OSS のコミュニティに連絡して聞いてみましょう。積極的にメールを飛ばす姿勢はコントリビューターとして評価されると思います。

英語が心配

なんとかなります。僕も英語喋ったことなかったけど Google Meet のおかげでなんとかなりました。多分相手も完璧な英語を喋ってくれることを期待してないと思うので気楽にいきましょう。

大学の講義やテストなどとかぶって厳しい

今の GSoC は期間についてかなり柔軟に対応してくれるようになっているのでなんとかなると思います。それでも厳しいって？留年はいいぞ

Linuxデスクトップを使い始めて10ヶ月ほど経過したので感想とか述べてみる【Linuxはいいぞ】

この記事は CAMPHOR- Advent Calendar 2022 12 日目の記事です。

2月ごろに自作 PC を組んで Linux を入れてから 10 ヶ月ほど経ちました。すっかり Linux デスクトップを使い慣らした頃なので、Mac から移行してどうだったかを書いてみようと思います。

結論から言うと、Linuxにして大正解でした。

現在のデスクトップ環境紹介

モニターを縦置き横置き 1 台ずつで使っています。それぞれこんな感じです。

はい、かっこいいですね。ちなみにディストロは Manjaro、デスクトップ環境は Xfce を使っています。

おや、左上になんだか見慣れたロゴが...

YouTube に Xfce を Mac-like な見た目に変えるという動画があって、これを見ながら魔改造しています。詳しくない人がみたら普通に Mac ですね。

メニューバーが上についていたり、Plank というドックがあったり、Ulauncher という Spotlight 相当のものがあったり、使用感もけっこう Mac に近いです。また、Autokey というソフトウェアを使って Command キー相当のものも再現しています。これについては明日の記事で書きます。(書いた: Autokeyを使ってLinuxデスクトップにMacのCommandキーみたいなものを作る - Qiita)

Linux にしてよかったこと

  • Docker が速い
  • 開発環境を整えやすい
  • Linux にしてよくなくなった部分がほとんどない

いろいろあるけどとにかく良い。

Manjaro にしてよかったこと

ディストロは「流行っているから」というミーハーな理由で Manjaro にしたんですが、これも大正解でした。

  • OS インストールがとても楽
    • たぶん Ubuntu と変わらないぐらい
  • なのに Arch 系の恩恵を受けられる
    • ローリングリリース
    • pacman という快適なパッケージマネージャ
    • AUR でほぼなんでもインストールできる
  • デスクトップ環境の選択肢の多さ

Arch 系というと、ローリングリリースであるが故にソフトウェアやライブラリが最新になりすぎて動作が不安定みたいな噂がありますが、こういった問題にはほとんど遭遇していないです1。Manjaro はいいぞ。たぶん Arch もいい。

Linux はいいぞ

とにかく Linux デスクトップが快適で移行して良かったという気持ちしかないです。一般的な開発環境として最も優れていると言って間違いないと思います2。もう Mac には戻れないですね3 (高いし)。全人類 Linux を使おう。

  1. 一回あったのが、ICU というライブラリのバージョンが 72 に上がったときに Node がバージョン 71 に依存していたため動かなくなるという問題が起こりました。ただ、このときも ICU71 が AUR で配布されていたためこれをインストールするだけで解決できました。↩
  2. Windows の開発環境なら Windows が一番というのはありそう。↩
  3. とはいえ開発環境としての側面を差し置くと Mac の UX の良さは確かに十分に価値のあるものだと思います。そのために Mac を使うというならそういう選択肢もあると思います。↩

ISUCON12 予選敗退しました

どうも。Sazaです。

ISUCON12 予選に参加しましたが、スコア 0 点で敗退しました。

メンバー

  • @Saza_xxx: 主にインフラ担当
  • @energy_saving0 : 主に app 担当
  • @moririn2528_c : app 担当

やったこと

余裕なくて他のメンバーがやってくれたことはちゃんと追えてないので自分がやったことだけ書きます。

10:00 ~ 11:00

僕はひとまず開発環境の構築をしました。開発は VSCode SSH Remote を使ってサーバー上でやりました。最近知ったんですけど、ISUCON10 とかみたいにメモリ 1GB ぐらいのシビアな環境だと VSCode まともに動かせないっぽいですね。今回は 2 コア 4GB のインスタンスだったので耐えました。

導入したプロファイリングツールなどは以下の通りです。

  • top: サーバー全体の負荷を見る
  • alp: nginx のログを分析する
  • mysqldump: MySQL のスローログを分析する
  • pt-query-digest: MySQL のスローログをさらに詳細に分析するときに使う
  • pprof / gprof: Go の中でどの部分が重いのかを見る
  • measure: Go の中でどの部分が重いのかを見る2 (measuregen を使って仕込んだ)
  • goone: N+1 を検出する
  • sqlstr: ソースコードから SQL を抜け出す

ヒントは多い方がいいと思って色々入れたんですが、pprof とかは今回あんま見てなかったですね。

11:00 ~ 12:00

今回のやらかしポイント1。なんか MySQL のスローログが出なくてクネクネしてました。いつも SET GLOBAL を使ってスローログの設定をしていたんですが、isucon ユーザーに SUPER 権限がなくてできなかったので my.cnf をいじって設定しようとしたんですが、なんか設定が反映されなくてどうしよ〜って言ってたら1時間ぐらい経ってしまいました。結局、12:00 ぐらいに運営から質問への回答として、MySQL に root でログインする方法が与えられたので、それによって isucon ユーザーに SUPER 権限を与えてスローログ出すことに成功しました。

12:00 ~ 14:00

ようやくスローログを見ると、visit_history から SELECT するクエリが鬼のように重いのを発見してどうにかしようとしました。コードを読んでみると、visit_history は「各ユーザーが各大会に対し最初にランキング表を見たのがいつか」というのを参照するために使われているのに、ランキング表が閲覧されるたびにアクセス元ユーザーがどの大会のランキング表を見たかを記録していました。そのせいで、visit_history に無駄な INSERT やら MIN 演算やらがされていたので、データの持ち方を変えることで負荷を落とすことができそうだと考えました。
まず、visitor というテーブルを作り、そこに「各ユーザーが各大会に対し最初にランキング表を見たのがいつか」という情報をそのまま格納するようにしました。そのためには、まず visit_history の初期データから visitor にデータを移してくることをしないといけないので、その処理を /initialize でやるようにしました。すると visit_history のデータが多すぎて /initialize がタイムアウトしてしまいました。よって MySQL に CLI で接続してこのデータ移行をやったんですが、なんかベンチマークの整合性チェックでひっかかりました。ちゃんと /initialize 時にデータの初期化をやっていたつもりだったんですが、色々原因探して試してみてもずっとベンチが通らなかったので、「さてはデータ移行しようとしてもうまくいかないという罠だな〜！？」と思って諦めてしまいました。後日解説を見てみるとデータ移行できるよって書いてあってアになりました。なんでうまくいかなかったんだろう......

14:00 ~ 14:30

で、visit_history の SELECT が遅い問題はどうしたかというと、普通にインデックス入れるだけでも十分のような気もしたので、インデックス貼ってみるとしっかり負荷下がってました。早めにデータ移行諦めてインデックスに逃げればよかった...。今回のやらかしポイント2でした。

14:30 ~ 15:00

チームで話し合って、そろそろ複数台構成手をつけ始ようかということになって、僕はとりあえず MySQL を 2 つ目のサーバーに移行しました。これまでの修正によって MySQL の負荷はすでに大したことない状態になっていたのでスコアはほぼ変わりませんでした。

15:00 ~ 15:30

measure の計測結果を見てみると、Cache-Control: private をヘッダに付与する処理が app 側に書かれていて、これが結構重くなっていたっぽかったので、Nginx にやらせるようにしました。

15:30 ~ 17:00

ここから本格的に複数台構成に取り掛かっていきました。top の結果から、MySQL より app (と SQLite) がめっちゃ重いという状態になっていたので、app の処理をうまく各サーバーに分散させる必要がありました。今回は各テナントの情報が SQLite で保存されていたので、何も考えずに Nginx でトラフィックを各サーバーに分散させるとデータの整合性が取れなくなってしまいます。ここから SQLite を MySQL に移すの時間はないので、SQLite のまま処理を分散させるためには、リクエストをテナントごとに各サーバーに振り分けるということをする必要がありました。

具体的には、Nginx の設定で、テナント名が a~l, A~L のリクエストは 1 台目のサーバーに、テナント名が m~z, M~Z のリクエストは 3 台目のサーバーに振り分けるということをしました。(今書いてて気づいたんですがテナント名が数字で始まるパターンがないか確認してなかったですね...)
これをすれば 1 つのテナントに対してその情報が複数のサーバーにバラけてしまって整合性がなくなるという問題はなくなります。
ところが、この構成でベンチマークを通すためにはまだまだやることがありました...。

/initialize を他のサーバーにも飛ばす

ベンチマークの最初に叩かれるエンドポイント、/initialize では DB の初期化処理をしていて、これでベンチマークを実行するための DB の状態を作っています。DB が MySQL だけの構成なら一つのサーバーに /initialize を送るだけで十分なんですが、SQLite の初期化をするためには SQLite を動かしているすべてのサーバーに対し /initialize を送る必要があります。
そのため、ベンチマークから /initialize を受けるサーバーから、もう一方のサーバーに /initialize を叩くということをしていました。最初、この処理を Nginx にやらせようとしていたんですが、そうすると /initialize を転送する処理が非同期で行われるっぽくて、/initialize が完了する前にベンチマークが走ってしまい整合性チェックで落ちるという問題が発生する、などというトラブルに見舞われて時間を溶かすなどしていました。悲しい。

テナント作成を他のサーバーにもやらせる

admin のエンドポイントに、テナント作成をやってくれるものがあって、そのときに SQLite の DB が作成されるようになっていました。admin は a から始まるので、admin のリクエストはサーバー 1 に振り分けられます。そのため、SQLite のテナント DB はサーバー 1 にしか作成されなくなってしまい、サーバー 3 に作られるはずの DB が存在しないというエラーが起きます。これに対応するため、テナント作成時にもう一方のサーバーの API を叩くことでその DB を作らせるということをしました。
後で解説を見たら、テナント作成時に DB を作成しなくても、あるはずの DB が存在しないと分かったタイミングで新たに DB を作ればもっと楽にできたようです。思いつかなかった...。

17:00 ~ 18:00

この時点での自チームのスコアが 8600 ぐらいで学生 5 位のチームが 10000 ぐらいという状況でした。app 担当の 2 人からはもう手をつけられそうなところないとのことで、ここはもう残りの 1 時間で処理の分散をさらにいい感じにすることで予選突破できるのでは！？という感じでした。そこで、サーバー 2 は MySQL しか動いておらず、まだリソースに余裕のある状態だったのでこいつにも app の負荷を分散させようとしました。
Nginx で サーバー 2 を admin からのリクエストだけを処理させるようにして、残り 2 台でそれ以外のテナントの処理をさせるようにしました。残り 1 分の時点でその修正が完了し、なんとか最後にベンチを走らせた結果、Fail でした...。後で見てみると、他のサーバーのテナント作成 API を叩くとき、リクエスト先の IP アドレスを間違えていました...。今回のやらかしポイント3。

反省

という感じで終わりでした。

振り返ってみると、実装力不足とか知識不足のせいで時間を無駄にしていたことがかなりあったなと思いました。スローログ出せずに 1 時間も止まったり、visit_history のデータ移行で 2 時間も止まったりしていたのは本当にひどかったです。my.cnf いじる練習をもっとしとくべきでした。

複数台構成で詰まった原因として、まず「そのシステムがどういう構成でどういう仕組みで動いているのか」ということに注意を向けなかったことがあるなと思っていました。どんなタイミングで SQLite の DB が作成され、どんなふうに接続されるのかとかを最初に確認しておきたかったです。SQLite にインデックス貼れなかった原因もそれですね。

あと、終わった後は、「SQLite のせいで複数台構成失敗したやんけ〜」とか言い訳してたんですが、解説とか見てみると SQLite のまま、MySQL だけ他サーバーに分離するだけでも、app 側をいじるだけで十分ハイスコアを狙えるようでした。app 側でなかなか芯食った改善ができなかったのも厳しかったです。当日マニュアルにキャッシュ貼っていいよって書いてあったのでやればよかったです。

今回の問題は非常にトリッキーな内容でしたが、それによって過去問素振りだけで身につけた付け焼き刃の知識が通用しないものになっていたと思います。完全に実力不足でした。

来年は絶対決勝行きたいです。

留年しました

f:id:Saza:20220312234300p:plainf:id:Saza:20220312234300p:plainどうも。Sazaです。

三回生後期も終わり、成績表が返ってきました。今期もだいたいいつもと変わらぬ成績を維持できていることを確認していたとき、あることに気付きました。

f:id:Saza:20220312234300p:plain

あ、般教が一個足りてない。

来期にスポ実かなんかとって埋めるか〜とか呑気なこと考えてたんですが、友達に指摘されて気付きました。これ、留年らしいです。

履修要覧 を見てみると、たしかに般教で21単位以上取ることが卒業研究着手条件の一つになっているんです。つまり僕は来期から卒業研究を始めることができず、これはつまり卒業するのが半年遅れることになります。

阿鼻叫喚。突如として僕は半年の留年を余儀なくされました。
もともと僕は成績はそれなりに良い方で、累積GPAは3.4以上、総取得単位数は148単位で、数的には卒業単位に必要な単位数を超えています。
ところがこの般教の単位数条件を見落としていたことで卒業研究に着手できなくなってしまったのです。なんたる理不尽...。

この理不尽に黙って屈するわけにはいかず、アドバイザー教員のもとにかけつけて相談しました。「数理の単位や、Basic SecCapの単位を取っているんですが、これを般教の単位として認めてもらうことはできませんか？」とかいろいろ言ってみたんですが、どれも「決まりだからダメ」とのこと。
どうやらもう本当にどうにもならないらしいということをそのとき悟りました。

なんでこんなミスをしたのか

工学部の般教の単位戦略として以下の2つのことに注意するように言われることがよくあります。

  • 人文社会科目を取っておけ
  • E科目を取っておけ

この2つの条件が工学部の般教の単位を取るに当たって重要です。そこで僕は、E科目の4単位をE1科目で埋めるということをしました。そうすることで人社とE科目の単位を両方とも埋めることができるからです。
しかし、多くの人はE科目のうち2単位をE2で取っています。そうすると、情報群の単位を取得することになるので、自然と般教の合計単位数の条件をクリアすることができるのです。
僕はそのことに気付かず、人社とE科目を埋めたことに安心しきって合計単位数の条件を見落としてしまったというわけでした。

まじで最悪です。

これからどうするのか

とりあえず研究室仮配属はしておいて、残り一単位の般教を取りながらインターンとか行ったりして開発をやりまくろうと思っています。
院進については、するにしても院試受けるのは来年になるのでゆっくり考えようと思います。就職も考えてるので就活もするつもりです。
まぁ留年困るんですが、やりたいことなんでもできるほどの時間ができるので、有意義に過ごせたらいいと思います。

初めて自作PCを組んでみた

どうも。Sazaです。

かねてよりLinuxマシンがほしいと思っていました。理由は自作OSとかで必要になるのと、今もってるMacBookがよわよわだからです。 メモリ8GB、ディスク256GBで開発やるのは結構つらいと思うのです。

そこで新しいPC買ってそこにLinuxインストールしようかと思ったんですが、だいたいのPCはWindowsがついてくるんですよね。そのWindowsのライセンス料もったいなくない？というわけで自分でPC組んだらええやんということになったわけです。

構成

そこでPC組むためにいろいろ調べました。予算としては10万以内に抑えたかったので「自作PC 10万」とかでググるといろいろこのへんとかが出てきて、10万あれば相当良いスペックのものが作れそうということがわかってきました。さらにゲームもやらないからグラボ代が浮いて、かなりのオーバースペックになってしまいそうでしたが、もうここは10万使い切って圧倒的な安心感を得ようということにしました。あと、調べてるとRyzenのCPUはLinuxと相性悪い可能性があったので、ちょっと高く付くけどIntelのCPUにすることにしました。
とまぁいろいろ考えて、最終的に以下のような構成にしました。

CPU

kakaku.com

マザボ

kakaku.com

メモリ

kakaku.com

SSD

kakaku.com

電源

kakaku.com

ファン

kakaku.com

ケース

kakaku.com

組み立て

役者が揃えばあとは組み立てるだけ。

マザボの説明書を見たり、ググって調べたりしながら組み立てていくと、だいたい3時間程度で組み立て終わりました。初めてだったけどそこまで苦労しなかったです。

組み立て終わって電源つけてみようと思ったけどなんか動かないので調べてみたら24ピン主電源がめっちゃ刺さりにくいので気をつけろみたいなこと書いてあったのでもう一回指し直してつけてみると、

よかった。

ここからLinuxインストールしていくんですが、今回はここまで。続きは次回に

f:id:Saza:20220216152619j:plain かわいい

noteからはてなに移行した

どうも。Sazaです。

テストが一通り片付き、B3後期が終わりました。今までになくサボりにサボった今期でしたが、まぁなんとか今までとおよそ変わらない成績を維持できそうです。

さて、今までブログとしてnoteをやってたけどやっぱりはてなに変えます。
理由は「noteよりはてなやってる人のほうが周りに多い気がするから」。

あとは編集でマークダウン使えるのも良いですね。

noteで書いた過去記事3つのリンクを貼っておきます

セキュキャンの記事を一生書こうとしない。誰か書いてくれ。

最後に、先週作った「おつまみネギ塩豚」の写真を置いておきます。ご査収ください。

f:id:Saza:20220208231429j:plain