<h3 id="h8d027c8ed3">はじめに</h3>学習方法は人によって最適解が異なるので、鵜呑みにせず参考程度に読んでもらえたらと思う。 自分の場合はDuolingo English Testにした。受験料が安いし、自宅から受験できるので社会人にはかなり良いと思う。 自分が海外大学院に進学する動機は<a href="https://zenn.dev/k_n/articles/3998fcb5b372e9" target="_blank" rel="noopener noreferrer">Zenn</a>に上げた。 <h3 id="hceac27c9fc">Duolingoについて</h3>Duolingo English Testは大体10種類程度の出題が出される。リーディング、リスニング、ライティング、スピーキングの中で二つ以上を組み合わせた問題になる。(例えばディクテーションや聞こえてきた問題に対して解答を喋るとか) なお、Duolingoは定期的に出題パターンが変わるのでこの内容も金科玉条ではなく一参考程度で読んでいただけたらと思う。 試験時間は約60分。自分の場合は休みの日の午前中に受験していた。<h3 id="hcf83e1357e"> </h3> <h3 id="haf66bd3a7f">実際の問題別の対策</h3> <h4 id="h25679f06f8">スペルを読み取って存在する単語を選ぶ問題</h4>いくつかの単語が表示され、存在する単語だけを選択する問題。 結構紛らわしいのもあるため慣れも必要になる。 対策としてはTOEFLの単語帳で語彙を増やしていくこと。自分の所感だと以下の単語帳のTrack3まで押さえておけば大丈夫だと思う。 <a href="https://www.amazon.co.jp/TOEFLテスト英単語3800-4訂版（音声ＤＬ付）-神部孝-ebook/dp/B071Y335LW" target="_blank" rel="noopener noreferrer">TOEFL3800</a> <h4 id="h7498c47004">単語の音声を再生して、存在する単語を選ぶ問題</h4>音声の再生ボタンを押して、存在する単語を選択する問題。 これも基本的にTOEFLの単語帳で音声と一緒に覚えれば大丈夫だと思う。 <h4 id="h6acb7fe210">文章を読み上げる問題</h4>画面に表示された文章を読み上げる問題。 発音を正しくネイティブに近づけるためには、TEDなどで音声を聞き取り、シャドーイングの形で真似をしながら喋る練習をすれば恐らく大丈夫だと思う。 <h4 id="h5da83f322c">文章の穴埋め問題</h4>虫食い算的にところどころ文章が空白になっている部分を埋める問題。 これは問題形式にかなり慣れないと結構間違える。 なのでDuolingoの公式サイトに出ている模試で問題の形式に慣れたり、普段から英語のニュースや記事を毎日最低一つ読む練習が必要になる。また、文法が苦手な場合は恐らくほとんど解けないので自信がない人は文法から学び直すと良い点が取れると思う。 <h4 id="h5630380596">長文文章読解に関する問題</h4>2022年から新しく出された問題形式。最初は文章の穴埋め問題が出され、完成した後の全体文章で内容や主旨に関する問題が出される。 ここら辺はTOEFLの読解問題をひたすら解くこと、英文法を完全に抑えることが求められる。(ただし文章量自体はTOEFLほど長くはない感じ) <h4 id="h748c5b57c7">写真の内容記述</h4>表示される写真の内容を1分以内に書く問題。とにかく時間がないのと、文章を書く練習をする必要がある。 これについては有料だが、<a href="https://learn.detready.com/31b9d27a-3345-4b9b-aade-41d3f5a1c91c" target="_blank" rel="noopener noreferrer">こちらのサイト</a>で練習するのがおすすめである。 <h4 id="hec9d585ae6">特定の話題に関する意見を記述する問題</h4>画面上にお題があり、それについて5分以内で文章でまとめる問題。 これも有料だが、<a href="https://learn.detready.com/31b9d27a-3345-4b9b-aade-41d3f5a1c91c" target="_blank" rel="noopener noreferrer">こちらのサイト</a>で練習するのがおすすめである。 <h4 id="h083172f207">聞こえてきた文章を書き取る問題</h4>いわゆるディクテーション。 無料の<a href="https://speechling.com/dictation/english" target="_blank" rel="noopener noreferrer">このサイト</a>で練習するのが良いと思う。自分が正解できるレベルから徐々に上げていく形式で恐らく鍛えられる。 <h4 id="h1f34d9b9a0">写真の内容について喋る 画面上のお題に関する意見について喋る問題 聞こえてきた話題に関して意見を喋る問題</h4> これについてはオンラインDMM英会話などで練習するのが一番である。 教師陣に英語が初学者である旨を伝えておくと、会話のスピードも落としてくれるように配慮してくれるので勇気を振り絞って練習するのが一番である。ちなみにフィリピン人の女性講師が一番良いと個人的に感じた。 教材としてはConversationとDiscussion、写真を説明するものがおすすめである。実際の問題にも割と近いので正確に喋る練習を講師とやる。(自分はここで累計4000分練習する必要があった) と言う感じある。 Good Luck

はじめに学習方法は人によって最適解が異なるので、鵜呑みにせず参考程度に読んでもらえたらと思う。
自分の場合はDuolingo English Testにした。受験料が安いし、自宅から受験できるので社会人にはかなり良いと思う。

海外大学院に進学するまでの英語の勉強

<h3 id="h8d027c8ed3">はじめに</h3> webシステムでデータの相互通信形式はREST APIやgRPCの他にGraphQLによる形式がある。 厳密にはGraphQLの通信形式はAPIとしての機構だが、クエリによってフロントエンド側が柔軟にデータを取得できる。 僕はREST API形式もGraphQL形式も扱ってきているが、GraphQLの優れている点として <ul><li> 各ページにおいてデータをまとめて取得することで、RESTのように何度も通信する必要がない(ケーニヒスベルクの橋の問題)</li></ul> <ul><li> ApolloやurqlなどのGraphQLクライアントとTypeScriptの型定義の組み合わせで強力なスキーマ駆動開発が可能</li></ul> などが挙げられる。 自分も開発していて数多くの利点を感じている。 一方で僕の中ではGraphQL側が要求する技術的要件の難易度は高いとも思っている。 その理由を次に挙げる。 <h3 id="h797932f52e">N+1問題と解決について</h3> GraphQLとRDBMSは残念ながら相性の良い技術の組み合わせとは言えない。 データの捉え方に両者には隔たりがあるからだ。 GraphQLは木構造を辿りながら、データを捉えることで、データ取得の解決方法を提示している。 一方でデータベース(ここではRDBMSとする)ではテーブルを関連づけてデータを取得する解決方法を提示している。 この木構造を辿るという行為は、例えばユーザー一覧の中で投稿一覧を探索する際にそれぞれのリソースをユーザーのデータ分だけ探索してしまうことに繋がる。 これはデータ数が多くなればRDBMSの発行するSQLクエリの数が多くなってしまい、パフォーマンス面で非常に厄介な問題を引き起こす。 RDBMSに詳しいエンジニアの場合、これをテーブル結合で解決しようとするがGraphQLの「必要なデータのみクライアントが指定する」という考え方に背くことになる。 これは <a href="https://zenn.dev/alea12/articles/15d73282c3aacc" target="_blank" rel="noopener noreferrer">先達者の記事</a> にもある通りである。 最もリーズナブルな解決方法としては記事にあるとおり、ORM層に自己解決させるというやり方だろう。(ID群を取得し、それをWHERE IN句でまとめて取得するやり方) <h3 id="he5c4d0ae2a">木構造と関係性データベース構造の難しさ</h3> GraphQLとRDBMSではデータに対する捉え方が異なる。 この両者が一同に接する接合点でデータをどの粒度で捉えるか、は問題になる。 テーブルの粒度 = GraphQLのスキーマ単位 という考え方は厳密には適用できない、と個人的には考えている。 というより無理に押し込もうとすればするほど上手くいかない。 今のところ共通解は持ち合わせていないが僕の中ではまずGraphQLとして大きなグラフ構造を考えて粒度を決める、その次に必要なテーブルを作成する、というのが良いような気がする。 <h3 id="h29ed6d54e6">プロジェクトでGraphQLとREST APIどちらを使うべきか</h3> まずプロジェクトが新規プロジェクトでデータ取得がある程度複雑になるプロジェクトであればGraphQLを採用するメリットはある。逆にいうとそれ以外のケースではお勧めしない。 例えば <ul><li> 既存プロジェクトのリライトやリファクタリング</li></ul> <ul><li> RDBMSの設計が初期段階で歪な構造になっている</li></ul> こういう状況でGraphQLを採用すれば余計に問題を複雑にするだけである。 実体より手段を先行させないことが大事だと考える。

webシステムでデータの相互通信形式はREST APIやgRPCの他にGraphQLによる形式がある。

GraphQLとRDBMSの考察

<h4 id="h308ceff509">本の紹介</h4> タイトル買いというべきか、とにかくタイトルが興味をそそる内容だったので電子書籍で買った。 <a href="https://www.amazon.co.jp/悲劇的なデザイン-あなたのデザインが誰かを傷つけたかもしれないと考えたことはありますか？-ジョナサン・シャリアート-ebook/dp/B078LX5GQV" target="_blank" rel="noopener noreferrer">悲劇的なデザイン-あなたのデザインが誰かを傷つけたかもしれないと考えたことはありますか？</a> この本は世の中に存在する「悲劇的なデザイン」を紹介し、なぜひどいのか、至った要因などを事例ごとに紹介する。 事例はユーザーに怒りを感じさせるデザイン、悲しみを感じさせるデザイン、疎外感を感じさせるデザインである。 一番しっくりきた言葉は「地獄は善意でできた道である」というワードである。アメリカのことわざらしい。 自分が良かれと思ったデザインはユーザーに不信感を抱かせたり、怒りを感じさせる側面があることを常に忘れてはいけない。 もちろん全員が満足するようなデザインなんて作るのはかなり難しい話である。(今のところそんなデザインは誰も発明してない) ただ「かなり多くの」人間が信頼し、満足できるデザインというのは目指せるかもしれない。 そのためにアクセシビリティというのは結局あるのだから。 あんまり話すとネタバレになるので、詳しくは書籍を買って読んでほしい。ページ数は300ページぐらい。

タイトル買いというべきか、とにかくタイトルが興味をそそる内容だったので電子書籍で買った。

ジョナサン・シャリアートのデザイン書籍を読んだ

<h4 id="h1a2bc1336c">個人的な振り返り</h4> 今年も色んなことがあった。 面白いこともあれば、それほど面白くないこともあったけど次に続く道筋はできたと思う。 僕が仕事で費やした時間を見ると、以下に要約される。 1. プロダクトのフロントエンド実装(4割) 2. テストコード作成(3割) 3. タスク管理や割り振り(2割) 4. OSSの更新や調査(1割) 特に2のテストコードは力を入れた。 <a href="https://zenn.dev/k_n/articles/f55d8ad6a843d1" target="_blank" rel="noopener noreferrer">Zennで投稿した記事</a>にある通り、カバレッジ率を0%から最低限の70%まで持ってこれたので結構がんばった方ではないかと思う。 「テストを書く、が当たり前」がもっと世の中に浸透してくれればと思うし、自分自身も積極的に発信できればと考える。 なぜなら再現性のないもの(ここでは画面も見ないとわからない)を確認しないといけない実装は実装ではない、という自負がある。 一方で一つ後悔したことといえば、「アクセシビリティ」の観点で足りない部分が色々あったなぁというところである。 具体的には文字やボタンの色のコントラクト比でもうちょっと深い議論ができれば、とか、エラーの見せ方とか。 来年の課題は「アクセシビリティ」の知識をさらに増やし、実践していくこと。 いっぱい本も読むこと。 あと趣味でやってるRustもう少し勉強したいなぁ。。。 <h4 id="h9224cd51c5">周辺界隈振り返り</h4> 今年も数えきれないほど技術の変化があったけど、やはり一番はNext.js 12である。 Next.js 12については<a href="https://nextjs.org/blog/next-12" target="_blank" rel="noopener noreferrer">ここ</a>にあるので読んでほしい。 その中でもEdge Function は一番わくわくする。 リクエストがオリジンに到達する前に関数を実行し、ベーシック認証とかリダイレクトとかを実装できるので、便利そう。(ぶっちゃけ Lambda Edgeでも同じことできるじゃん?とか言わない) 他にはReact 18(React Server Component)を意識したアップデートの内容になっている。 自分はまだReact Server Componentの概念が曖昧なのでもうちょっと勉強してみる予定。 あとはゲームチェンジャーとも言える<a href="https://deno.land" target="_blank" rel="noopener noreferrer">Deno</a>である。 今後どのぐらいNode.jsからDenoへの技術的置き換えが起きるのかわからないけど、このコミュニティの動きは見守りたい。

2021年を振り返る。今年も色んなことがあった。面白いこともあれば、それほど面白くないこともあったけど次に続く道筋はできたと思う。

2021年を振り返る

フロントエンドのテストは見るべき部分が多く、大変だと言われている。 複雑性の本質を見るとフロントエンドのプログラミングがロジックに合わせて画面UIが変化をする、に起因すると考える。 フロントエンドで行うテストの種類は <ol><li>ロジックレベルの単体テスト</li><li>UIコンポーネントテスト</li><li>結合テスト(E2Eテスト)</li><li>リグレッションテスト</li></ol> が挙げられる。(他にもあるかもだが) <h4 id="h44a6d4560e">ロジックレベルの単体テスト</h4> 最も取り組みやすいものの一つ。 関数単位でそれぞれのパターンごとに期待値を書いていき、判定を行う。 エンジニアがいう「テストコード」でいうと真っ先に思い浮かぶやつ。 ReactやNextでは以下のライブラリが非常に良い。 <a href="https://testing-library.com/docs/react-testing-library/intro/" target="_blank" rel="noopener noreferrer">https://testing-library.com/docs/react-testing-library</a> 気をつけている点としては 質の悪いテストコードを書かない →結果が自明である関数のテストコードはわざわざ書かない 闇雲に書くとメンテナンスコストは高くなるし、やる範囲は絞った方が良い。 自分の場合の優先順位だと下記に絞っている。 1.ドメインロジック層 2.カスタムフック層 3.通信層の一部 <h4 id="h900897c258">UI単体コンポーネントテスト</h4> これも比較的取り組みやすいものの一つ。 先程のテストライブラリや状況によってはStorybookも代用になる。 スナップショットによるコンポーネントテストは一時期やっていたが、DOM要素が複雑になると確認がしづらくなり、途中でやめた。 <h4 id="h240642deb2">結合テスト(E2Eテスト)</h4> 非常にやりづらいテスト。 最近はCypressとかが出てきて随分楽になった。 ただし、こちらは自動テストツールだと起動や実行が遅い場合があり、特にテストファイル数が多くなると顕著になる。 結合テストについてはサービスで特に重要な機能だけに自動化を絞ってCypressに回させた方が良い。 人間の介入が引き続き必要とする領域と思われる。 <h4 id="ha631e69f04">リグレッションテスト</h4> いわゆる退行テスト。 修正したコードが他の無関係な部分に影響が及んでいないかを確認するテスト。 UIのリグレッションテストについてはreg-suitとstorycapである程度自動で行うことが可能となっている。 導入自体は難しくはないが、こちらもやる範囲を決めないと無駄なケースが増えると思われる。 <a href="https://github.com/reg-viz/reg-suit" target="_blank" rel="noopener noreferrer">https://github.com/reg-viz/reg-suit</a> <a href="https://github.com/reg-viz/storycap" target="_blank" rel="noopener noreferrer">https://github.com/reg-viz/storycap</a> フロントエンドのテストは本当にやり出すとキリがない状態になる。 なので現状においては必要なタイミングで必要なツールを用いて、範囲と目的を限定させて実行するのが良さそう。

フロントエンドのテストは見るべき部分が多く、大変だと言われている。
複雑性の本質を見るとフロントエンドのプログラミングがロジックに合わせて画面UIが変化をする、に起因すると考える。



My Blog

海外大学院に進学するまでの英語の勉強

GraphQLとRDBMSの考察

ジョナサン・シャリアートのデザイン書籍を読んだ

2021年を振り返る

フロントエンドのテストの複雑性