monolog

monora log #=> ものろーぐ

2019年の投稿

朝起きられなくても就職がしたい!

雑記

こんばんは。この記事は whywaita Advent Calendar 2019 の21日目の記事、になる予定です!!! タイトルの通りのことを数日内をめどに書きます!! 遅刻してしまい申し訳ございません……

20日目は nersonu さんによる「剣盾新ポケモンの受けループ/サイクルへの導入を考える - そぬばこ」でした。ポケモン久しくやってない。

https://twitter.com/sukukyon/status/1223176159954759680

何を書くかアジェンダ

  • 就活の話を書きます

  • 2019年新卒 (学部卒) と 2021年新卒 (修士卒) それぞれの就活メモから面白そうな文章を適当に持ってきます 最強の ガクチカ を持ってバトル

  • 「ぜひ来てほしいって言われて行ったら落とされた」

  • 「うちはインターンの方が倍率高いから、インターンで落ちても本選考はぜひ受けてほしくて」

  • 「このオファー額に見込み残業って入ってますか?」「ん〜〜いい質問ですね!」

  • 「ごりごりにコードがかけなくても大丈夫です!!研究成果が思わしくなくても大丈夫です!!大切なのはxx様の熱意とやる気☆」

  • 「再来年入社でもこの時期にエントリーして大丈夫ですか?」「うちは通年採用なので大丈夫です」

  • 「飯を食っても弊社の志望度変わらないでしょ」

  • 「XXXはあなたにとって良い職場ではないかもしれません」

  • 「社会人になったら朝早く起きられるもんだよ」 「執行役員としての発言としては絶対にあってはならないことであり」

    逆求人サービスの完全主観レビューをします 面白そうな会社を紹介してください

  • あ、いや、決め方を教えてほしい気がしてきた……

追記

whywaita Advent Calendar 2020 でこの記事で書く予定だった内容をカバーすることにしました。1年経ったけどようやく書いたよwhywaita...

https://blog.monora.me/2020/12/jobhunting-technique/  

 

こんばんは。この記事は whywaita Advent Calendar 2019 の21日目の記事、になる予[…]

ISUCON9 予選の参加ログ (チーム: 再起動非対応)

Infrastructure Programming

こんばんは、kyontanです。

前回再起動試験で落ちたのでチーム「再起動非対応」で参加しました。ベストスコアは4410点でした。再起動試験までたどり着けなかった……悔しい……

チーム「再起動非対応」は同期3人 (自分 @kyontan, @hogashi, @h-otter) での参加でした。学生は2人いたはずですがエントリーをミスったので学生は1人ということになっています。

使用した言語

私はRubyが一番得意だと思っていますが、非同期処理が書きやすいとか型が着いていると嬉しい、みたいなことはあり今回もGo言語です。 でも今回はN+1潰すときの型マッピングで無駄に時間を溶かしてしまったので、Rubyの方が良かったかもしれない……つらい……

開始前の準備

Prometheus/Grafana等のサーバの設定を @h-otter にお願いしました。前回のコードを読み返しつつ、何をしたかを思い出すなどした。

時間がなくて完全に忘れてしまいましたが、せめて練習はやっておくべきでしたね…

あと、 Alibaba Cloud の UI が色々不思議な感じで良かったですね。

本番

完全に正解していますが、今回はマイクロサービス問だということに気が付いたのは開始してからだいぶ経ってからでした。

https://twitter.com/sukukyon/status/1170651769401069568

今回できたことが異常に少ない気がする。kataribeのログを眺めつつ、チームでやったことは以下のことです。比較的時系列だけどそうでない部分もあるかも。

  • 開始スコアは 2310

  • 10:30 メモリ多いな〜って思っていたら2, 3台目のインスタンスタイプを間違えていたことに気がつく。インスタンス立て直し コードは既にリポジトリへ追加していたのでチームメイトはルール/コードリーディングを進める

    10:50ごろ: 作業開始 11:30ごろ?: MySQL 5.7 を 8.0 へ (@h-otter)

  • スコア変化なし

    11:45 DBにインデックスを張る(@kyontan)

  • 多分間違えていて、これらにインデックスを貼りましたがあまり効いていなかったようにみえました

  • BigQuery の触りすぎでRDBのインデックスの挙動をほぼ忘れたのも敗北ポイント

config (name)
items (created_at, id)
items (id)
items (buyer_id)
items (seller_id)
shippings (transaction_evidence_id)
transaction_evidences (id)
transaction_evidences (item_id)
users (account_name)
users (id)

  • 12:20: カテゴリをオンメモリへ (@hogas, @h-otter) 2510点ぐらい

    12:30: http2 対応, 静的ファイルをキャッシュ, アップロードされた画像を nginx で返すなど

  • スコア変化なし

    13:30: config もキャッシュするように 14:00: 新着商品には発売中の商品だけを返すようにする (@hogas) 14:45  - 16:00: GET /users/transactions.json の N+1 を潰す (@kyontan)

  • 3500点ぐらい

  • なぜか色々ハマって2時間半ぐらい溶かしていた。これは敗北ポイント

  • 多分ここらへんでMySQLがサチらなくなっていた気がする CPUがサチっていたことに気が付いていたが原因が分からず (pprofをなぜ見なかったのか……)

    15:30: UserSimple が持つ情報は全てオンメモリでキャッシュする

  • ユーザの存在チェックだけするような部分 (権限チェック) も基本的にこれで対応できるのでそうした

  • 4210点 ここからスコア上がらず……

    16:00: 同じクエリを何度か叩いているエンドポイントがあったので潰す (@hogas, @kyontan) 16:00ごろ: transactions 以外詰まってないしCPUに余裕があるので campaign (負荷レベル)を弄ったところ外部APIで 403エラー  {"error":"IP address is not allowed"} が連発しだす

  • 主にGET /users/transactions.json での外部 shipment  サービスへのリクエストで連発

  • 外部APIへの403はアプリケーション的には500を返す仕様だったので、これが連発してベンチマーカが途中終了し完走しない

  • ここらへんで手詰まりに

    17:00: 明らかに不要な SELECT FOR UPDATE を削除 (4箇所+ぐらい)

  • これかこれの次辺りで4410点。これがベストスコア

    17:10: 外部APIを叩く部分で exponential backoff を実装 (@h-otter)

  • 変化なし / 403 が連発する

    17:30: 外部APIをリクエストするエンドポイントだけ2台へ分散する

  • 403 の連発は解決せず、なぜ……

    18:10: 最終スコア0点 (failed) で終了 色々施策を打つもスコアの変化要因が今ひとつ分からず頭が回っていなかったですね。 特に外部API が undocumented な 403 を返す (しかもメッセージは 「許可されていないIPアドレス」) というのは全然分かりませんでした。 マイクロサービス問題なら単一IPから連続でアクセスすると弾くようになっているのかな、などと思い、後半で外部APIへリクエストをするエンドポイントだけ複数台へ分散するなどしていましたが全く解決せず泥沼へ。

これベンチマーカと外部API側に問題あるのでは? みたいな気持ちになりつつ、マイクロサービス問だしちゃんとbackoffとか実行すればいけるでしょ! と思っていましたが、意図したエラーだったのかは未だに分からず……

他の方の感想を見た限りでは、ポータルサイトへ登録されていないIPからのアクセスは弾かれるみたいですが、これについてはUI上で正しく登録されていることを確認したので問題なさそうでした。 11:00 ごろにインスタンスを立ち上げ直してIPを再登録したのがポータルサイトの何らかのエッジケースを踏んだのでは? などと勝手に邪推しています。謎ですね。

そのほか、 campaign の値を変えると何が変わるのか (POST系アクセスが増える?)、みたいなことも終了後にログを分析してようやくなんとなく傾向がわかり悔しい気持ちに。

感想

終わってみれば途中重大な気付き (「外部APIのレスポンスキャッシュできるじゃん」「ユーザの嗜好に合わせて商品出し分けたら?」など) があり、見逃しの多い回でした。 bcrypt の件は全く気づいておらず。前回は初手でやった(があまり意味がなかった) pprof を今回なぜ見なかったのか……

短い時間で追い詰められている環境の中でどれだけ集中できる / 気付けるか、というのが重要になると改めて感じました。

コンテストとしては今回も設定が面白く、運営の手の込みようが分かり、かつ短期間で取り組みがいのあるとても良い問題でした。 運営の皆様、大変お疲れさまでした。

こんばんは、kyontanです。 前回再起動試験で落ちたのでチーム「再起動非対応」で参加しました。ベストスコア[…]

コストを掛けずにBigQueryを使い倒す会

Software

BigQueryを使い倒す会代表のkyontanです.今回は実用性低めな分野で BigQuery を1万倍有効活用する方法……ではなく延々とBigQueryがお得だという話をします.

今回ご紹介するテクニックを意味不明に活用することで,18.2GBのスキャン(10円程度)で2301億行の一時テーブルを作って集計することが可能です.便利ですね.ちなみに私は12桁の数字を突然見て混乱しました.

COUNT(*)の結果が2301億

ちなみに上のクエリは37.5秒で帰ってきましたが,内部では4時間52分のCPU時間を使用したようです.つまり,単純に計算すると約500スレッドが並列して走っていたようです.すごいですね……

(注: この記事は実用性皆無です.ごく一部を除き,一般の分析用途でBigQueryを使用するユーザにはなんの利もありません)

 

他にも,1TB超えのデータをシャッフルすることもあり…… (シャッフルという概念は一般的なRDBMSにはなく,後述するMapReduceが持つ特徴の一つです) 1TBのデータをシャッフルできるの異常じゃないですか? DC内ネットワークすごいですね.

並列度が高いクエリだと1週間どころか2週間を超えるCPU時間を1発のクエリで使うこともあります.

さて,BigQueryのコストはスキャンするデータ量に依存します.そのため,一般的なログ分析基盤でコスト削減のためにスキャンする列を減らしたり,時系列でパーティショニングして必要な分だけスキャンする手法が取られますが,こういった話はありふれているので割愛します.

ここでの目的はスキャン量を増やすこと無くスロット時間(CPU時間)を増やすことであり,これにより同じコストでより多くのCPUを使いたいということです.とにかく多くのリソースを使うことが快楽に繋がります.

実際,上の図では31日と5時間のCPU時間をわずか66.6GBのスキャンで消費することに成功しています. BigQueryは執筆時点で1TBスキャンするコストが$5ですから,66.6GBのスキャンはわずか30円程度です.30円でGCPのサーバを1ヶ月分動かせると考えるとお得な気がしませんか?

コストパフォーマンスを突き詰めていくと,1.6MBのデータから2時間41分のCPU時間を消費することもできます. BigQueryは10MB以下しかスキャンしなかった場合には,10MBへ切り上げた上で課金の計算がなされますが,10MBスキャンしたところで掛かるコストは$0.00005 ですから,これは実質無料です.

一方で,複雑なクエリを叩くと実際長い時間がかかることがあります.このとき,BigQueryではクエリのタイムアウトが6時間と定められているため,これを超えるとクエリが強制終了させられます.

他にも雑に PARTITION BYを使ってパーティションを切りつつ内部でソートを掛けているとメモリを食いすぎて死んでしまったり

(意訳ですが)予想された時間を大幅に超えたのでとりあえず止めました,みたいなエラーが出たりします. これは未だに納得がいってない.6時間動かしてから言って欲しい.

 

さて,我々は賢いので(?) BigQueryの内部アーキテクチャを攻略することで可能な限りこういった中断系エラーを避けつつ安価にクエリする方法を試すことができます.

BigQueryはSQLが使える分析特化のDBではありますが,中身はMapReduceだと推測され,実際クエリプランを見るとそれっぽい様子を垣間見ることができます. MapReduceといえばHadoopやSparkが有名ですが僕は触ったことがありません.安易に解釈すると大量のマシンにデータをバラ撒いてジョインして適当に集計する,みたいな感じでしょうか.そのうち原論文をちゃんと読みたいですね.

BigQuery公式でも述べられていますが,クエリを高速に実行するためのキモはいかにうまく分散させるかに掛かっています.CPU時間を稼ぎつつ実時間を抑えるためにはこの並列数を上げるためのクエリ書換が重要になります.

今回私が実行したかったクエリは約1万行のテーブルを2重に自己結合するクエリでした.イメージとしては下のようなクエリになります. 単純にINNER JOINを2回書けばよいのですが,計算量は単純計算で1万の3乗,1兆回のループが発生します.終わりません.

SELECT *
FROM some_table src
INNER JOIN some_table a
  ON ...
INNER JOIN some_table b
  ON ...

実際にはON句での絞り込みがあるので結果セットは数分の一(それでも数千億ありますが)になるのですが,こんなクエリを素直に書いても全然スケールしません.

これは,行数が少ないテーブルのINNER JOINはあまり並列数を上げて実行してくれない現在のBigQueryのクエリ計画エンジン(?)の特性に思えます.

ちなみに BigQuery だと WITH句を使って一時テーブルの見た目をした何かを作ることができますが,これは実行プランには影響がありません.

WITH some_table_joined AS (
  SELECT *
  FROM some_table src
  INNER JOIN some_table a
    ON ...
)
SELECT *
FROM some_table_joined
INNER JOIN some_table b
  ON ...

対策として,まず自己結合を1回した一時テーブルを作り(数千万行)クエリをし,その結果テーブルに対して再度自己結合を掛けるクエリを書いたところ500スロット並列で動くことを確認しました.具体的にはクエリを次の2つに分割することになります.

-- create some_table_joined
SELECT *
FROM some_table src
INNER JOIN some_table a
  ON ...

-- join some_table_joined and some_table
SELECT *
FROM some_table_joined
INNER JOIN some_table b
  ON ...

元の1万行のデータは高々数MBしかないため,これを2重結合するクエリが動けば実質無料になるのですが,これはうまく行かず,結局自己結合した一時テーブルのスキャンに数十円程度掛かりました.それでも安いのですが……

ちなみにここで注意すべきこととして,ストレージ課金があります.BigQueryのストレージは安価とはいえ,3ヶ月以内に変更されたデータに掛かる料金,つまりActive Storageは $0.020/GB です.中間テーブルを作ってクエリが終わり,使いみちがなくなったら不要なテーブルを削除しましょう. (実際には BigQuery でクエリしたときに勝手に作られる結果用の一時テーブル(数時間しか有効期限がない)は課金されないような気がします.僕は実験が日をまたぐこともありますし,とりあえず名前を付けてテーブルに保存していたので消す必要がありました)

他にも,やはり数千万行を超えるデータのソートは苦手なようで,なかなか苦労しました.結局PARTITION BYの中でソートをして成功したことは数えるほどしかありません.今回のケースでは諦めてMIN, MAX関数に逃げてしまいましたが,本来は一時テーブルをもう一度作らないとタイムアウト内に終わらない気がしますね.

このように,BigQueryでログデータ以外の集計をする人は実質存在しないかと思いますが,今回のケースではうまくMapReduceの特性を利用することができ,無事高速かつ安価に数千億の組み合わせを試行することができました.

read more »

BigQueryを使い倒す会代表のkyontanです.今回は実用性低めな分野で BigQuery を1万倍有効[…]

YubiKey 5C を買ったので ECDSA鍵で ssh した

Infrastructure Software

こんにちは。唐突に YubiKey が欲しくなったので買いました。こんなことをやっている場合ではない……

正確には、Amazon.co.jp を見たら異常に高くてそりゃ転売したら儲かるな、という気持ちになったので、適当に人を募って Amazon.com (US) で共同購入しました。 関税や送料を足した結果、YubiKey 5 NFC が5500円, YubiKey 5C が6100円ぐらいで買えました。良かったですね。

YubiKey といえばそもそも OTP が出てくるキーボードとして認識されるデバイスですが、最近だと WebAuthn で使えたりしますね。あとは PKCS#11 の署名用や適当な鍵を登録できたりします。

雑に手元の macOS でssh するぞ、と思ったら地味にハマってしまったのでいろいろやった結果動くようになったのでメモ

手順だけ分かればおっけー!という方は Gist にパッチ等まとめたので、そちらを参照してください: [https://gist.github.com/kyontan/763952e7be68a2e96d5c3f0ad0d3bce8

](https://gist.github.com/kyontan/763952e7be68a2e96d5c3f0ad0d3bce8)検証環境のバージョンは macOS Mojave 10.14.4 で、OpenSSH は 7.9p1, LibreSSL 2.7.3 が入っていました。 ただ、今回は最終的に OpenSSH と OpenSSL は自前でビルドしたのであまり関係ありません。 より重要そうな Homebrew でインストールしたパッケージのバージョンは、 OpenSSH 7.9p1, OpenSSL 1.0.2r (26 Feb 2019), OpenSC 0.19.0 です。

まず、下記の記事などを参考に鍵の生成を試みます。

Putty CAC で SSH に YubiKey を使う(OpenSC編) - enjoy struggling https://blog.haniyama.com/2018/02/02/yubikey-ssh-opensc/

GUI のツール (YubiKey PIV Manager) の場合は PIN を設定すると自動的に Authentication と Key Management 用の鍵を生成してくれます。現代だとデフォルトで ecdsa-sha2-nistp256 の鍵が生成されるんですね。便利。

公開鍵を取り出そうとした

YubiKey へのアクセスや署名(でよいのでしょうか?) にはスマートカード等で使う OpenSC を使用するようです。今回は Homebrew でインストールしました。 (brew install opensc)

早速試してみます。まずは上の

# ssh-keygen -D /usr/local/Cellar/opensc/0.19.0/lib/opensc-pkcs11.so
C_GetAttributeValue failed: 18
C_GetAttributeValue failed: 18
cannot read public key from pkcs11

うまく行きませんね。(上手く行った場合はこの記事を読む必要はありません。最後のステップまで飛ばしてください。

パッチを当てる

エラー文でググると偉大な先達の記事が出てきます。今回この記事がなかったら即死していたでしょう。

ssh with yubikey ECDSA keys - lithium03の物置 https://lithium03.info/yubikey/index.html

この記事を読むと、「RSA鍵なら問題なくいける」「OpenSSH が OpenSC を使うときに (具体的には PKCS#11 の署名等で) ECDSA鍵に対応できてない」ということが分かります。

親切にパッチや、そのパッチの元になったチケットまでリンクがあります。

2474 – Enabling ECDSA in PKCS#11 support for ssh-agent https://bugzilla.mindrot.org/show_bug.cgi?id=2474

このチケットを見ると、Fedora 28 では既にこのパッチがバックポートされていること、upstream には OpenSSH 8.0 でマージされる予定であることが分かります。

ちなみにパッチは OpenSSH 7.6p1 用で、上の記事では 7.8p1 用に書き換えられたものが公開されていますが、現時点の Homebrew でインストール可能なのは 7.9p1 ということで、パッチを修正しました。

というわけでパッチです: https://gist.github.com/kyontan/763952e7be68a2e96d5c3f0ad0d3bce8

ビルドする

Homebrew でパッチとかどうやるんだ……と思いましたが、どうやら brew edit openssh で行けるみたいです。こんなに簡単に当てられるなんて……便利だ……

Homebrew: Patching an existing package https://www.ralfebert.de/snippets/brew-apply-patch-to-package-formula/

というわけで雑に既に書かれている patch の下に、以下のように追記してやるとパッチが当たります。

# Add support ECDSA for PKCS11, ref: https://bugzilla.mindrot.org/show_bug.cgi?id=2474
patch do
  url "https://gist.githubusercontent.com/kyontan/763952e7be68a2e96d5c3f0ad0d3bce8/raw/2ad5f854eba7704fbb7af2182ac57ee82b9a8f61/openssh-7.9p1-pkcs11-ecdsa.patch"
  sha256 "93b4e48321db94d785833a9414b12467a4741156cec90fa3052a4092acec8938"
end

 

インストールは brew install --build-from-source openssh です。既にインストールしてあるものがある人は install を reinstall に読み替えてください。

ビルドできたら、ビルドした ssh や ssh-keygen のパスをよしなに通してやります。勝手に通ってるかもしれません。(rehash なりしてから ssh -V の結果を見るとかすれば分かると思います)

うおおおおお!!!!

# ssh-keygen -D /usr/local/Cellar/opensc/{version}/lib/opensc-pkcs11.so
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBDnIbZ4ANu...
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBBv0e8HKnx...

というわけで公開鍵が見られました。2つ見えたのは、上で自動的に作られると行っていた Authentication と Key Management 用の鍵がどちらも見えてるからだと思います。普通は上の方を使えば良いはずです。

鍵を登録して、ssh していきます。 ssh -I /usr/local/Cellar/opensc/{version}/lib/opensc-pkcs11.so host です。

# ssh -v -I /usr/local/Cellar/opensc/0.19.0/lib/opensc-pkcs11.so user@xxx.monora.me
OpenSSH_7.9p1, OpenSSL 1.0.2r  26 Feb 2019
...
debug1: Connection established.
debug1: provider /.../opensc-pkcs11.so: manufacturerID <OpenSC Project> cryptokiVersion 2.20 libraryDescription <OpenSC smartcard framework> libraryVersion 0.19
debug1: provider /.../opensc-pkcs11.so slot 0: label <Yubico PIV Authentication> manufacturerID <piv_II> model <PKCS#15 emulate> serial <...> flags 0x40d
debug1: have 1 keys
debug1: have 2 keys
...
debug1: Will attempt key: /.../opensc-pkcs11.so ECDSA SHA256:nr/MvmFI6cYmChV97dMVIBeE2Uq5UmhVvoIdIuayLvg token
debug1: Will attempt key: /.../opensc-pkcs11.so ECDSA SHA256:Z7dluZC4FCEsUAC0HYiITr5+I83bLtHUxOwdla81Rtc token
...
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /.../opensc-pkcs11.so ECDSA SHA256:nr/MvmFI6cYmChV97dMVIBeE2Uq5UmhVvoIdIuayLvg token
debug1: Server accepts key: /.../opensc-pkcs11.so ECDSA SHA256:nr/MvmFI6cYmChV97dMVIBeE2Uq5UmhVvoIdIuayLvg token
Enter PIN for 'Yubico PIV Authentication':
debug1: Authentication succeeded (publickey).
Authenticated to xxx.monora.me ([xxx.yyy.zzz.www]:22).
...
# sl
...

というわけで ssh 出来ました。嬉しいですね。

パッチを見て当ててみたらエラーが出た瞬間にやる気をなくして、うだうだやっていたら3時間ぐらい掛かってしまいましたが、なんとか動いてよかったです。

それでは皆さまもハッピーYubiKeyライフをお過ごしください!

こんにちは。唐突に YubiKey が欲しくなったので買いました。こんなことをやっている場合ではない…… 正確[…]

2019年3月あたりの今日このごろ

雑記

こんにちは。最近名乗るときに自分はkyontanなのかきょんたんなのか@sukukyonなのか分かりません。 インターネットありがちネームは Twitter や任意の ID を自由に設定できるサービスで人権がない。

3/7は名取さなさんの誕生日でしたが、皆様いかがお過ごしでしょうか。私は先日、宮城県は名取市に行ってきました。

私は昨年開業届を出してしまったがばっかりに確定申告に脳内のリソースの8割を吸いつくされながら3週間を過ごし、実際の帳簿作成/決算はわずか6時間強で終了しました。やらないならやらないで頭の隅っこからも追い出せということですね。

前回の記事では東京に引っ越したという話をしましたが、無事平穏に特に何もない生活を送っています。今日も生きててえらい。

寝られるだけ寝る、というか起きることができないのでどうしようもないですね。これからも朝が遅い仕事を探し続けます。

最近もまっとうに1日3食食べるような生活はしていないですが、周囲の人間が病んでいる割合が平均よりだいぶ高いと推測する自分が今日もぐっすり寝られるのはとりあえず良いことだと思っています。

read more »

こんにちは。最近名乗るときに自分はkyontanなのかきょんたんなのか@sukukyonなのか分かりません。 […]

東京に引っ越しました

雑記

2ヶ月前はまさか引っ越すとは思っていなかったんですが、あれよこれよとやっていたら東京で駅チカの2DKに引っ越すことになりました。

4月から社会人ということで早めに東京に出た。つまりはそういうことです (ウソです 残りは散文です。

この記事は新居ではなく、たまたま実家にいるので実家で書いています。実家って言い方もまだ慣れないですが区別ができないので使わないといけない。

そもそもの動機として、今通っている大学が遠い、ということがありました。 片道ドアツードアで1時間50分〜2時間というのはなかなかに辛いもので、1日に4時間が通学で溶けるというのは実感するとつらいものがありました。 小学校, 中学, 高校も1時間程度掛かっていたので大丈夫かと思っていたのですが、倍になると流石に色々と勝手が違いますね。毎日座れれば良いのですが……

時は流れ、今は4年目も終わろうかというところですが、幸いにして進学先も決まり(同じ場所ですが)あと2年は東京の中心部から離れたところに通うことになることが決まりました。 自分は自宅大好き人間なので実家を出るつもりはさらさらなく、社会人になったら東京に引っ越すどころかリモートワークしたいなと思う程度に今住んでいる所が気に入っています。家から出たくない。

とはいえ大学へ通わないといけないのは事実であり、研究室は比較的対面でのコミュニケーションを重視する文化が根強いため、成果さえ出せば来なくていいとはいえできる限りの時間を研究室で過ごしたいと思うようになりました。

ということで、お試しではありますが東京に住むことにしました。

read more »

2ヶ月前はまさか引っ越すとは思っていなかったんですが、あれよこれよとやっていたら東京で駅チカの2DKに引っ越す[…]