TOEIC 675 から 825 に上げた
1年3ヶ月前は市販模試を3回分やって受けて675(305/370)だった。
今回は真面目に対策をして受けてみることにした。勉強期間は半日(3時間くらい)を1ヶ月半くらい。
リスニング対策は「極めろ！リスニング解答力TOIEC L&R TEST」をした。
692ページあるから忍耐力が必要だった。
リーディングのPart5対策は「TOIEC L&Rテスト文法でる1000問」をした。
1000問解く必要があったのかはわからない。
Part6,7 は英文を読むことに慣れる必要がありそうだったから「英文解釈教室」を読んだ。
文法のことが大体わかる良書。
長文を読むことに慣れるために「英文 詳説世界史 WORLD HISTORY for High School」を読んだ。
日本語の教科書があったから英語->日本語(流し読み)をした。世界史の復習にもなるから一石二鳥。
あとはSRE本の英語版が公開されているからこれも日本語と合わせて読んだ。
仕上げに市販の模試「新メガ模試1200問」を解いた。
スコアは1問5店換算で750(390/360) -> 745(425/320) -> 810(425/385) -> 790(400/390) -> 845(420/425) -> 800(415/385) だったから本番で思ったより取れてた。
リーディングは時間が余って自信があったけどそこまで伸びていなかった。
リスニングは単に問題の形式とか傾向に慣れて伸びた部分が多いと思う。
ライティングとスピーキングの学習動機としてTOEFLを検討してるけど3万円に見合うかどうか...
株式会社はてなに入社しました
株式会社はてなに入社しました
2.5年目
create-react-appからJestの実行場所を探す
create-react-appで作成されたプロジェクトにおいてTesting LibraryとJestの関係性を整理しようとした時、Testing LibraryはJest, AVA, Chai...の並びでテストランナーなのではないかという誤解が生じた。そしてtesting-library/jest-domはテストランナーとしてのTesting LibraryをJestに移行するためのツールとして理解しようとした。
誤解が生じた1番の原因は、package.jsonのdependenciesやscriptsにjestが見当たらなかったからだと思う。
けど、Testing LibraryはLibraryといってるくらいだから、さすがにテストランナーではないよな...って感じでもう少し調べてみることにした。
create-react-app が裏で何をやっているか理解する - Qiita
これでほぼ解決した。
npm run ejectするとdependenciesにjestがある！
だけどまだnpm run testでreact-scripts testが実行されているのでJestの姿がはっきりと見えない。
というわけでcreate-react-app/packages/react-scriptsを眺める。
/bin/react-scripts.js#27にpackage.jsonのscriptsの一覧がある。
/scripts/test.js#L129 のjest.run(argv);でJestが走る。
というわけでTesting LibraryはEnzymeと同じ並びでDOM構造をテストするためのライブラリで、jest-domはTesting LibraryをJestで使用する際に必要なMatcherを提供している。
DenoでDatabase Design and Implementation 3章を実装する
「Database Design and Implementation」の内容はこの記事で紹介されているので省いて、とりあえずDenoで実装を始めてみたというメモ。
tarovel4842.hatenablog.com
JavaもC++も書いたことがないので一番慣れてるJavaScrptで実装したいなーと思い、せっかくだからDenoでやろうというモチベーション。
とりあえずこのコミットで3章の大枠は実装できている。
合ってるかわからないけど合ってなかったらこの先わかるだろうという完成度。
C++の実装は他言語で実装にするにあたってスター1個じゃ足りないくらいとても参考になっている。
Bufferを扱うけれど、今までBufferを深く追求したことがなかったのでNodeの記事で入門してDenoの記事も読んだ。
はじめてのNode.js：Node.js内でバイナリデータを扱うための「Buffer」クラス | OSDN Magazine
Buffers in Deno | The JS runtimes
Buffer.from: Deno’s equivalent of Node.js | The JS runtimes
最初はstd/io/bufferを使おうと思ったけどoffsetを指定して書きこんだりするのでそれができるかまだじっくり調べてなくてとりあえずstd/node/bufferを使っている。
また、ファイルの存在を確かめる箇所があって、ビルトインにはなさそうで、std/fsでは全体がunstableでexistがdeprecatedになっていたからこれもstd/node/fsを使っている。
今気づいたけどその流れでDeno.mkdirではなくfs.mkdirを使っていた。
こんな感じでドキュメント等の情報量もstd/nodeを使う方が多くて楽だからビルトインを積極的に使ってなくてそこに関してはNodeでもいいのではって感じだけど、node_moduleがなくてスクラッチで作ってる感満載の時点でDenoは開発体験がいい。
Notes on the breaking change that occurred in Axios v0.25.0
Axios v0.25.0 was released on January 18, 2022.
One of the breaking changes is adding error handling when missing url, which returns an Error if the Request Config url specified in the argument is Falsy.
This was introduced to clarify bugs and errors, but there have been issues where the URL is intentionally set to Falsy, such as when using the baseURL of Request Config or when sending a request to GraphQL.
Some say that in order to upgrade to Node14, need the aborted event handler that was added in the same release, but can't upgrade Axios because of this change, and I, as the implementor of this breaking change, think this is an issue that should be addressed quickly.
This issue proposes the following fixes: "Allow empty strings", "Create a new option", and "Change the location of the error handling".
Maintainer jasonsaayman answers with 「It would be nice to keep everyone happy, so I would like to give this some more thought come up with a solid solution to this, I will revert back after the weekend with my ideas.」
PS January 27, 2022.
PR to be reverted is merged and will be released soon.
https://github.com/axios/axios/issues/4407#issuecomment-1022894805
PS Feburary 18, 2022.
Fix has already released.
Release v0.26.0 · axios/axios · GitHub
Axios v0.25.0 で生じた breaking change の注意点
English version:
Notes on the breaking change that occurred in Axios v0.25.0 - 経験は何よりも饒舌
2022年1月18日に Axios v0.25.0がリリースされました。
その中の breaking change の1つに Adding error handling when missing url があります。
これは、引数で指定するRequest ConfigのurlがFalsyである場合にErrorを返すという変更です。
バグやエラーの内容を明確にすることを目的に導入されましたが、Request ConfigのbaseURLを活用する際や、GraphQLにリクエストを送る際など、意図的にFalsyにしている場合があるというissueが立てられています。
Node14にアップグレードするために、同じリリースで追加されたaborted event handlerが必要だが、この変更のためにAxiosをアップグレードできないという発言もあり、このbreaking changeの実装者である私も速やかに対応すべき問題だと考えています。
このissueでは「空文字列を許容する」、「新たにoptionを作る」、「エラー処理の場所を変える」という修正案が出されており、メンテナーである@jasonsaaymanは
「It would be nice to keep everyone happy, so I would like to give this some more thought come up with a solid solution to this, I will revert back after the weekend with my ideas.」
と回答している状態です。
2022/1/27 追記
revertするPRがマージされ、もうじきリリースされます
https://github.com/axios/axios/issues/4407#issuecomment-1022894805
2022/2/18 追記
修正がリリースされています
Release v0.26.0 · axios/axios · GitHub
denodrivers/deno_mongo で作った my good first issue
この記事はDeno Advent Calendar 2021の19日目です。
deno_mongo で取り組んだ my good first issue を紹介したいと思います。
README.mdに情報を足す
リンクに飛んだ方がわかりやすいと思ったのでそうしました。
docs: Improve README by wafuwafu13 · Pull Request #294 · denodrivers/mongo · GitHub
フォーマットを統一する
varが使われているなど、VSCode上で警告の出ている箇所がちらほらあったので、CIでdeno lintを走らせるようにしました。
chore: Run `deno lint` in CI by wafuwafu13 · Pull Request #298 · denodrivers/mongo · GitHub
TODOコメントを拾う
TODO: add test casesを拾いました。
test(02_connect): Add `runCommand` test by wafuwafu13 · Pull Request #295 · denodrivers/mongo · GitHub
非推奨のAPIを使わない
非推奨になったassertThrowsAsyncが使われていたので書き換えました。
chore: `assertThrowsAsync` is deprecated by wafuwafu13 · Pull Request #313 · denodrivers/mongo · GitHub
テストの方法を改善
MongoのCURD操作のテストをしているファイルがあるのですが、最初に実行されるテストから最後まで同じコレクションが使われており、テスト間に依存関係がある状態でした。
その状態では、最後の方にあるテストを読もうとしたとき、最初の方のテストで何がinsertされたのかを順に追っていかないといけないので辛いです。
そのため、各テストの実行後のコレクションの中身をコメントで追記するという作業をしました。
chore(test/03_curd): Improve readability by wafuwafu13 · Pull Request #302 · denodrivers/mongo · GitHub
しかし、テストを追加する際にコメントも編集しないといけなくなる、そもそも依存関係をなくした方が良いという議論になりました。
それはそうだと思ったので、各テストの実行後にコレクションの中身を削除する関数を用意し、依存関係のないテストを新たに書きました。
test(03_curd): Write tests that do not depend on each other by wafuwafu13 · Pull Request #311 · denodrivers/mongo · GitHub
機能の追加やバグ修正はしていませんが、それ以外にもできることが結構ある場合があります。
good first issue といえども、コードの全体像を把握した上での good first issue なので、まずは自分なりの my good first issue に取り掛かるのもありかもしれません。
