dackdive's blog

新米webエンジニアによる技術ブログ。JavaScript(React), Salesforce, Python など

2020年7〜9月のふりかえり

10月も間もなく終わろうかというところですが、2020年第3四半期(7〜9月)にやっていたことのふりかえり。

過去のふりかえり

2020年7〜9月にやったこと

7月:「実践Rust入門」を読んでRustに入門した

実践Rust入門[言語仕様から開発手法まで]

実践Rust入門[言語仕様から開発手法まで]

5月から読み始めて7月末にようやく読み終えた。
感想はこちらに:「実践Rust入門」を読んだ - dackdive's blog

読み終えた当初は「んーまだ自分で書けるようになった感じは全くしないけどとりあえず読めるようにはなったかな」という感触だったんだけど
9, 10月あたりRustを書く機会を全く作れず、今だと読む方も怪しくなってしまった。

8月:WebAssembly に入門した

Rust が終わった後、WebAssembly がどういうしくみで動作しているかぐらいは理解しておきたいなと思い Rust x WebAssembly の入門寄りの記事をいくつかこなした。

最初 Tour of WebAssembly をやったけどさっぱりわからなくて日本語の良さそうな本を読み、それでも結局よくわからないので公式ドキュメントに戻ってきた感じ。
ふりかえると最初から Rust and WebAssembly やっておけばよかったなという感想。

「wasm-bindgen とか wasm-pack ってなんなの?」とか「今 Rust で WebAssembly 書くならどういうツール導入して開発するの?」みたいなものはぼんやり理解した。
ただ学んだことをアウトプットできてないので人に説明できるレベルではない。次の四半期のうちにまとめたい。

その他学習リソースになりそうなもののまとめ:Rust, WebAssemblyの学習に良さそうなチュートリアル系記事まとめ - dackdive's blog

9月:AWS CDK に入門した

7月末ぐらいに東大のAWSの講義資料がバズってて、自分もAWSの知識が全然なくて勉強したいなと思っていたのでやってみた。

東京大学の講義「AWSによるクラウド入門」をTypeScriptで写経した - dackdive's blog

講義内容はCDKに限定せずAWSのさまざまなサービスを使いながら今どきのクラウドについて学ぼうという趣旨のものだったんだけど、
自分にとってはCDKでAWSのリソースを管理するというのがどういう感じなのか掴めてよかった。

9月〜10月: OAuth 2.0 を学び直している(WIP)

業務でのちょっとした出来事がきっかけで、自分がOAuth 2.0についてなんとなくしか理解できてないことに気づき、
基本的なところからおさらいしている。

手始めにAuthlete社のこの動画を観て、

www.youtube.com

次に

【電子版】雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本 - Auth屋 - BOOTH

を読み、現在は

を読んでいる最中。

自分は手を動かして勉強した方が理解が深まるタイプなので、Rust 書けてない問題も合わせて自分で簡単な認可サーバーを作るのを次の目標としても面白いかなと思っている。

leetcode

前回ふりかえり時点で6問。いま11問。

f:id:dackdive:20201026090122p:plain

8月後半ぐらいから全然やれなかった。

所感

この3ヶ月どうだったか、今のお気持ちは、など。

本を買う/読むハードルが低くなった

特に今やっているOAuthの勉強をしてて感じたこと。
これまでは本を買って読む心理的なハードルが高かったというか、「買った本ははじめから終わりまで丁寧に読み進めて全部理解しないともったいない」みたいな(ケチくさい)考え方だったんだけど
一冊読んで解決できなかった疑問を解消するためにまた別の本を買って、気になるトピックだけかいつまんで読むというのも効率が良いやり方だと感じた。

いま読んでる OAuth 徹底入門 がそんな感じ。

  • 読む前に、何がわかってないのかリストアップしておく
  • 目次を読んで「ここにこういうことが書いてそう」みたいなあたりをつける
  • そこだけ読む

というのにトライしている。

ネットワーク周りの勉強したい欲が高まった

この四半期に
Content delivery networks (CDNs)
という記事を読んで、あと他のきっかけもあり、CDNの基本的なしくみとかSSL/TLSとか、ネットワークまわりの知識が皆無なので勉強したいなーと思うようになった。

OAuthの勉強の傍ら、先日こちらの本を読んで

非常にわかりやすかったので、もうちょっと理論的な話とか勉強したいなと感じている。

次の四半期(2020年10〜12月)のテーマ

メインはOAuthになりそう。

  • OAuth 徹底入門 を読む
  • Rust で OAuth 認可サーバーを作る
  • Rust x WebAssembly で学んだことを整理し直す

年末に立てたTryの確認

東京大学の講義「AWSによるクラウド入門」をTypeScriptで写経した

AWSによるクラウド入門

少し前に話題になっていた東京大学の講義資料をやってみたので、内容、感想などメモ。

講義で使用するソースコードはすべて Python で書かれていますが、自分が実際に使うとしたら TypeScript で書くだろうなと思ったので TypeScript で写経しました。
が、CDK のコードはすべて TypeScript で書けましたが、Lambda 関数や動作確認用のスクリプトなどを全て置き換えるところまでは至らず、Python のままです。

写経したリポジトリhttps://github.com/zaki-yama-labs/intro-aws に。

続きを読む

HTMLのフォームコントロールをカスタマイズ可能にするプロポーザル(Enabling Custom Control UI)

Edge の PM (Program Manager) やってる方のツイートが目に留まったので内容をざっくり読んでみた、という話です。

該当のプロポーザルが置かれているリポジトリ https://github.com/MicrosoftEdge/MSEdgeExplainers から、Edge チームが中心になって検討を進めているプロポーザルのようですが、冒頭の Authors を見る限り他にも Google, Salesforce の人が関わってます。

※以下、 https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ControlUICustomization/explainer.md の内容をかいつまんで説明したものであり、また追加で調べたことなど自由に補足を入れているため、完全な翻訳ではありません。

Introduction

  • ブラウザに組み込まれたフォームコントロール<select> やさまざまなタイプの <input>。以下「コントロール」)の問題点として、開発者がサイトのデザインやユーザー体験にフィットするように見た目を柔軟にカスタマイズできないことが挙げられる
  • Survey results for controls & components | Greg Whitworth というサーベイによると、開発者がコントロールをリライトする一番の理由は、ネイティブのコントロールの見た目を十分にカスタマイズすることができないことだったそう
    • リンク先のこのグラフがそれを表してそう

f:id:dackdive:20200817030539p:plain
http://gwhitworth.com/surveys/controls-components/ より引用

  • 開発者がスクラッチでコントロールを再実装すると、web プラットフォームがやってくれているパフォーマンス、信頼性(reliability)、アクセシビリティの最適化の恩恵を受けられない
    • 注: "they're not able to leverage the work done on the Web Platform to optimize performance, ..." なので、「プラットフォームの取り組みを活用してパフォーマンス、... を最適化することができない」と訳した方が適切?
  • このプロポーザルによって、開発者はプラットフォームの恩恵を受けつつ、自分たちのサイトにフィットするようネイティブコントロールをカスタマイズすることが可能になる

Goals

  • 開発者がネイティブコントロールの任意の箇所をスタイリングできる
  • 開発者がネイティブコントロールの好きな部分に任意のコンテンツを挿入できる
  • 複数のパーツからなるコントロールに対し、開発者はすべてのUIをリライトすることなく特定の箇所をスタイリングできる
  • 開発者はデータモデルやユーザー入力にリーチするためのコードを再実装することなく、UIをカスタマイズできる。これはカスタムエレメントとしてスクラッチ実装するような今のアプローチとは対照的である
  • カスタマイズしたコントロールはデフォルトでアクセシブルである

Incremental Approach

  • このドキュメントの目的は上述したゴールを達成でき、かつすべてのコントールに適用できるようなモデルを検討することだが、実際にはモデルの適用はそれぞれのコントロールずつ - つまり各コントロールごとに固有のプロポーザル - になるだろう
    • ロールアウトは開発者の要求(demand)や各コントロールの複雑度合によるし、一部のコントロールには適用されない(実装されない)可能性もある
  • このドキュメントはコンセプトの例として <select><input type="range"> を多用するが、これらのコントロールの詳細なスペックを決めることがゴールではない
    • 全体的なアプローチについて合意がとれたら、これらや他のコントロールの固有なふるまいについて詳細を詰めていく
    • 進捗はすでに https://open-ui.org/ の方で確認できる

Use Cases

  • 主要なユースケースは「コントロールを自分のサイトに配置したいが、コントロールの見た目に高いレベルでの柔軟性を必要としているWeb開発者」
  • 現在、そのようなシチュエーションでは、コントロールのscriptable model(?)とUIをリンクするコードや、アクセシブルにするためのARIA属性などを含めたコードをスクラッチで実装する必要がある
    • このプロポーザルにより開発者はカスタムのマークアップとスタイルのみ提供し、残りはプラットフォームが提供する(というように役割分担がされ、開発者は見た目のカスタマイズに注力できるようになる)

Proposed Solution

Custom content and styles via standardized parts, named slots, and shadow DOM replacement

開発者がネイティブコントロールをカスタマイズする方法には3つの選択肢がある:

  1. 標準化されたパーツと状態(standardized parts and states)を使い、擬似クラスと擬似要素でネイティブコントロールのスタイルを上書きする
    • 擬似クラス: :hover:first など (MDN)
    • 擬似要素: ::after など (MDN)
  2. 名前つき <slots> を使い、ネイティブコントロールの一部はそのままに、一部のパーツを開発者が作成したコンポーネントに置き換える
  3. ネイティブコントロールのUI全体を開発者が提供する shadow root で置き換える

下にいくほど自由度が高くなるイメージ。

Standardized control UI anatomy, parts, and behavior

上のいずれの方法を取るにしても、今のコントロールの概念的なパーツやふるまい、ならびに各パーツの名称についての標準化が必要。
このプロセスは現在 https://open-ui.org/ によって進められている。

標準化の例として、たとえば <select> については

  • 以下のパーツで構成される
    • 1つの "button" という名前のパーツ
    • 1つの "selected-value" という名前のパーツ
    • 1つの "listbox" という名前のポップアップパーツ
    • 0〜N 個の "option" という名前のパーツ
  • 期待するふるまいは以下の通り
    • "button" がクリックされるとリストを表示する
    • "selected-value" は内部テキストを更新し現在選択中のオプションの値を表示する
    • 開いているリストの外をクリックすると折りたたむ
    • etc.

開発者はここで定義されたパーツからなるカスタムUIを提供すれば、プラットフォームがよしなにイベントハンドラーやARIA属性を付与して期待するふるまいやアクセシビリティを担保してくれる、というしくみ。

なおネイティブのスタイルは標準化される予定がなく、ブラウザによって今後も差異がある予定。

選択肢1のアプローチ(Styling native parts using pseudo-classes and the part pseudo-element)

先ほどの標準化によって決定された各パーツの名称と、 part という擬似要素を使って、以下のように今より細かい粒度でスタイルを適用できる。

<style>
  .styled-select::part(button) {
    background-color: red
  }
</style>
<select class="styled-select">
  <option>choice 1</option>
  <option>choice 2</option>
</select>

選択肢2のアプローチ(Named slots)

標準化によって決定された各パーツの名称に対応するように slot の name 属性も標準化することで、開発者はカスタマイズしたいパーツを slot name で指定して任意のコンポーネントに置き換えられるようになる。

たとえば <select> であれば "button" や "listbox" という名前が標準化されるので、

<style>
  .custom-button {
    /*...*/ 
  }

  option {
    /*...*/
  }

  .option-text {
    /*...*/
  }
</style>
<select>
  <div slot="button" part="button" class="custom-button">Choose a pet</div>
  <div slot="listbox" part="listbox" class="custom-listbox">
    <option>
      <img src="./cat-icon.jpg"/>
      <div class="option-text">Cat</div>
    </option>
    <option>
      <img src="./dog-icon.jpg"/>
      <div class="option-text">Dog</div>
    </option>
  </div>
</select>

こういったコードを書くことで、↓のようなドロップダウンが作れる。

f:id:dackdive:20200819005527p:plain
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ControlUICustomization/explainer.md より引用

コンテンツを与えなかった slot についてはデフォルトのUIにフォールバックされる。

選択肢3のアプローチ(Shadow DOM replacement)

注:3つの選択肢のうち、これだけ親となるセクションが異なっていて、文章のつながりにいまいち自信が持てなかった。けど、おそらく上述した選択肢の3番目の説明にあたると思われる。

attachShadow() を呼ぶことで、UIをまるごと開発者が用意したコンポーネントで置き換えちゃうアプローチ。

let customSelect = document.createElement('select');
customSelect.setAttribute("custom", "");
let selectShadow = customSelect.attachShadow({ mode: 'open' });
selectShadow.innerHTML = `My custom select UI`;
document.body.appendChild(customSelect);

今はコントロールに対して attachShadow() を実行すると例外を throw するが、カスタマイズができるようになるとこのメソッドが実行可能になる。

この場合も、プラットフォーム側は開発者が渡した shadow DOM にコアとなるパーツ(<select> なら part="button"part="listbox")が含まれているかどうかチェックする。

もし必須のパーツが渡されなかった場合は、shadow DOMはレンダーされない。


その他

ここまでで背景やどういう解決方法になりそうなのかはなんとなく把握できましたが、元のドキュメントの内容的には半分ぐらいです。
残りはざっと読んでいくつか気になった部分をメモします。

Light-DOM content under <input>

先ほどの選択肢2のようにカスタマイズしたい内容をコントロールの子要素として配置していくアプローチの問題点として、 <input> には子要素を配置できないという問題がある。

この問題に対するワークアラウンドとして、 <input> の各 type に対応する新しい HTMLElement を標準化することを提案している。
新しい element は対応する <input> element と等価だが、その type と無関係なメソッドやプロパティは取り除かれたものになる。 例: <input type="range"> に対して HTMLRangeElement を新しく導入する。これは <input type="range"> と同じメソッド、プロパティ、ふるまいを持つが、その他の input type にのみ関係するメソッド・プロパティは除外されている。この element は以下のように使うことができる。

<range>
  <div slot="thumb" part="thumb"><svg><!-- Use SVG to draw the thumb icon... --></svg></div>
</range>

Ensuring accessibility by default

このプロポーザルの key goal に「カスタムコントロールはデフォルトでアクセシブルである」というのがあった。
これを達成するために、part 属性の値に応じて ARIA 属性などをプラットフォーム(ブラウザー)側が暗黙的に適用する。

プロポーザル中では implicit accessibility semantics という用語を使っており、これは HTML AAM というドキュメントに定義されている implicit semantics と同じ意味合いだそう。(該当のドキュメントを読んでいないので詳しいことはわかりません)

ARIA 属性は HTML に実際に追加されるわけではないが、プラットフォームは適切な ARIA 属性が付与されているかのようにみなしてアクセシビリティツールに伝える。

たとえば、先ほどの

<range>
  <div slot="thumb" part="thumb"><svg><!-- Use SVG to draw the thumb icon... --></svg></div>
</range>

の場合、プラットフォームは <div part="thumb"> について以下のような implicit accessibility semantics をアクセシビリティツールに伝える。

  • slider という ARIA role
  • aria-valuenow
  • aria-valuemax
  • aria-valuemin

Feature detection

ブラウザ側がこの機能に対応しているかどうかを判定する方法について。

新しい HTMLElement が導入されている要素(先ほどの、<input type="range"> に対する <range> のように)であれば、以下のようにその要素が存在するかどうかでチェックできる。

if (!window.hasOwnProperty("HTMLRangeElement")) {
  /* apply polyfill/fallback */
}

そうでない場合、 attachShadow() が例外を投げるかどうかで判断できる。

function hasCustomSelectFeature() {
  try {
    document.createElement("select").attachShadow({mode: "open"});
    return true;
  } catch (e) {
    return false;
  }
}

Privacy and Security Considerations > Security

コントロールの中には、サードパーティのコードにそのまま提供されていると危険な、特権的な振る舞いを持つものがある。

  • たとえば <select> のドロップダウンリストはブラウザのウィンドウや iframe の外に飛び出すことが可能

f:id:dackdive:20200819014740p:plain:w480

  • このプロポーザルによって任意のコンテンツを <select> に渡せるようになると、OSのUIになりすましたり、iframeから外のコンテンツになりすますといったことが可能
  • すべてのコントロールタイプは、このような潜在的に悪用される可能性のある特権的な振る舞いのケースを慎重に調査する必要がある

「実践Rust入門」を読んだ

一旦読み終わったので、感想や個人的に良かったなあと思ったポイントなどをメモしときます。

全体的な感想

私のように、初めて Rust を勉強する人が基本的な文法やテスト・パッケージ(クレート)などのエコシステムについて体系的に学ぶのに良い本だと思いました。
私の場合、最初は the book と呼ばれる公式ドキュメントから入ろうとしたものの英語に挫折し、日本語訳を見つけるも情報の鮮度にいまいち確証が持てず(エディションがなんなのかいまいちわからなかった)。。。という感じだったので
2018 Edition に対応しており、かつ日本語で書かれた書籍という点では非常にありがたかったです。

また、サンプルも豊富です。

  • 「2-4節 RPN計算機プログラムとデバッガによる実行」では RPN逆ポーランド記法)で記述された数式を計算するプログラム
  • 「第3章 クイックツアー」ではソートアルゴリズムの 1 つであるバイトニックソート
  • 「7-9節 ライフタイムの詳細:簡単なベクタの実装」では簡易的なベクタ型
  • 「第9章 パーサを作る」では四則演算を行うためのパーサ
  • 「第10章 パッケージを作る」ではファイルの文字数をカウントするパッケージ
  • 「第11章 Web アプリケーション、データベース接続」ではWebアプリ
  • 「第12章 FFI」ではRustとCの連携プログラム

というように、実際に手を動かしてある程度のまとまりのあるコードを書くための題材が複数用意されています。
基本文法を覚えた後でいくつか実践的なお題に取り組めるのは良いと思いました。

加えて、本書は500ページ超と自分にとってはかなりのボリュームだったんですが、各サンプルは独立性が高いので、
特に後半の第10章〜第12章は自分に興味のあるトピックだけかいつまんで読み進めることができます。
私も第11, 12章は必要になったときに熟読しようと思い流し見だけしました。

困ったところがあるとすると、RPN計算機、バイトニックソートなど、題材自体の理解が難しいものがいくつかあったことでしょうか。
私は本を読むときたいてい前の方からじっくり読んでしまうんですが、文法もよくわかってない状態であれば第2, 3章はとばして第4, 5, 6, 7章あたりから読めばよかったなーと思いました。

写経したソースコード

https://github.com/zaki-yama-labs/rust-study/tree/master/bicycle-book
にあります。

良かったところ、勉強になったところ

VSCode でのデバッグ方法を知ることができた

「2-4-2 デバッガのセットアップ」の項で、CodeLLDB というVSCode拡張を使ったデバッグ方法について説明されており、これは今後も役立ちそうです。

データがメモリ上にどう配置されるのか、図を交えて説明されておりわかりやすかった

本書でRustを勉強して印象に残ったことの1つとして
「Rustでもデータがメモリ上にどういうふうに格納されているのかとか、ポインタに近い概念みたいなものは意識しないといけないんだ」
という感想を抱いたのですが、本書ではそのあたりの説明が丁寧でわかりやすかったように思えました。

「5-1 スタック領域とヒープ領域」でそれぞれのメモリ領域の特徴の紹介がされていたり、ちょっと話が複雑な場面では「今メモリ上はこのようになっています」というのを説明した図が何度も登場しました。

例として、Rustで文字列を扱う際に登場するStringとstrを比較した図を引用します。

f:id:dackdive:20200729013932p:plain

let foo = "abc" などとしたときの文字列リテラルは不変なので静的領域に置かれるがStringは可変なのでヒープ領域に置かれる、とか、
&str は実データを所有せず参照している、というのが図によってイメージしやすかったです。

パッケージの作り方、テストの書き方が理解できた

これは主に第10章です。
普段はWebフロントエンドの開発をしているため、npm パッケージに相当するものはRustだとなんだろう?とか、テストはどういうライブラリを使うんだろう?といった疑問がこちらの章で解決しました。

また、CI についても触れられていて、実際にRustで何か作ろうとするときには役立ちそうな知識だなーと思いました。
本書で紹介されていたのはTravisCIとAppVeyorでしたが、私はGitHub Actionsで構築しました。

そのへんの話はこちらに書きました:

余談ですが、Cargo.toml に書く [badges] というセクションは現在は deprecated のなんですかね。
Remove badges from crate lists and details · Issue #2436 · rust-lang/crates.io

README にこんな感じでバッジを直接埋め込むとよさそう。

[![<YOUR-CRATE-NAME> at crates.io](https://img.shields.io/crates/v/<YOUR-CRATE-NAME>.svg)](https://crates.io/crates/<YOUR-CRATE-NAME>)
[![<YOUR-CRATE-NAME> at docs.rs](https://docs.rs/<YOUR-CRATE-NAME>/badge.svg)](https://docs.rs/<YOUR-CRATE-NAME>)

実際に試したやつ:https://crates.io/crates/zaki-yama-bicycle-book-wordcount

また、クレート名はグローバルで一意じゃないといけない(npmパッケージのscopeみたいなものがない)、というのも、クレートを公開しようとしたときに地味にハマったポイントでした。

疑問点をSlackで質問できる

https://github.com/ghmagazine/rustbook#ご質問や不具合報告など

にも記載がありますが、本書に関する質問は rust-jp チームの Slack で著者らに質問することができます。
私も2つほど質問させていただきました。とても助かりました。

f:id:dackdive:20200729090419p:plain

引き続き勉強が必要だと感じたところ

「Rustならではの型や構文は覚えたので前より読めるようにはなったけど、正直まだまだ自分でRustを書けるレベルには程遠いな〜」というのが率直な感想です。

具体的には

  • Box<T> 型はまだよくわかってない
  • 所有権システム
    • 参照とか借用とかムーブとか
    • 7-9 節で簡易ベクタ型を実装するとき、メソッドの引数が &self だったり &mut self だったり self だったり。どういうときにどう書くのがいいか全然わからない
    • ライフタイム...
  • ベクタを扱う操作
  • モジュール単位、ディレクトリ構成など
    • 本書では単一ファイルに全部の関数やそのテストも書く、みたいな感じだったので、どういう粒度でファイル分けるんだろうなとか

この記事にもライフタイムは鬼門だって書いてますね。

次やること

次は WebAssembly の作り方、動かし方を勉強したいです。
Tour of WebAssembly をはじめました。

学習メモ

本を読みながらとっていたメモはリポジトリに。
https://github.com/zaki-yama-labs/rust-study/tree/master/bicycle-book

GitHub ActionsでRustプロジェクトを複数ツールチェイン&複数OSでビルドする

背景

こちらの本を読んでRustを勉強しています。

「10-5 自動テストを行う」でTravis CIとAppVeyorを使ったCI環境の構築方法が紹介されていたのですが、せっかくなので同じことをGitHub Actionsで実現しようとして、調べたことをメモ。

やりたいこと

  1. Rustの Stable/Beta/Nightly チャネルそれぞれでビルド・テストを実行したい
  2. 加えて、Windows/macOS/Linux でビルド・テストを実行したい
  3. Nightly チャネルでのテスト失敗は無視したい
続きを読む

Rust, WebAssemblyの学習に良さそうなチュートリアル系記事まとめ

個人的な興味で5月ぐらいからRustを勉強してるんだけど、「今読んでる本が終わったら読みたいなー」という記事が溜まってきたので一旦メモ。
Tips 系の記事というよりは、ある程度まとまったボリュームのチュートリアルっぽいものだけ集めた。

🇯🇵: 日本語。または日本語訳もある

Rust

WebAssembly (WASM)

おまけ:書籍

実践Rust入門[言語仕様から開発手法まで]

実践Rust入門[言語仕様から開発手法まで]

今読んでる。かなりのボリュームだけどサンプルプロジェクトが多くて個人的にはありがたい。

プログラミング言語Rust入門

プログラミング言語Rust入門

実践Rust入門を読んでる最中に、より出版日が新しい本があることを知った。
内容は調べてない。

買ったけど、RustとTCP/IPの基礎知識があることが前提らしく積ん読

2020年4〜6月のふりかえり

前回のふりかえりからまた3ヶ月経ったので。
前回:2020年1〜3月のふりかえり

2020年4〜6月にやったこと

「みんなのデータ構造」を読み終えた

みんなのデータ構造

みんなのデータ構造

  • 作者:Pat Morin
  • 発売日: 2018/07/20
  • メディア: 単行本(ソフトカバー)

コンピューターサイエンスを勉強するぞ計画の第一弾。
読み終えました。4/23 に終わっていたらしい。

かなり読み飛ばしている(まえがきでオススメされていたところしか読めてない)のに加え、最後に全体のまとめをしたかったんですができてないことに気づいた。

Rust の勉強を始めた

「みんなのデータ構造」を読み終わった後、何しようかなーとしばらく考えた結果
やっぱ Rust 一回勉強してみたいなという気持ちになり、本を一冊買った。

実践Rust入門[言語仕様から開発手法まで]

実践Rust入門[言語仕様から開発手法まで]

5, 6月はほとんどこれしかやってない。なのに全然終わらない。

それから、買った後に発行日がもっと新しい本もあることに気づいた。

プログラミング言語Rust入門

プログラミング言語Rust入門

こちらもレビューとかを読む限り良さそう。

leetcode をちょくちょくやるようになった

Rust 勉強しつつコンピューターサイエンス系の勉強も継続するために、週1ぐらいでいいので leetcode をやるようにした。
まだ6問しか解いてないようです。

f:id:dackdive:20200706232217p:plain

30分ぐらい自分で考える→discussionから模範解答っぽいの探して、もう30分で実装してみる、みたいな感じでやってます。

所感

この3ヶ月どうだったか、今のお気持ちは、など。

👍 コンピューターサイエンス:大学に通いたい熱が高まった

身の回りで自分と同じようにコンピューターサイエンスを学びたいと考えている人が何名かいて、中には実際にオンラインの大学に通い始めた人もいたので
自分も大学に行きたいというモチベーションが高まった。

ぼんやり35歳ぐらいでチャレンジするイメージだったけど、どういう選択肢があるのかだけでも調べておくのはいいことだなと。

そして、いろんな方の話を聴いてると問題は金ではなく時間だということがわかりつつある。

👍 読書が以前よりも習慣づくようになった

Rust の勉強をし始めてから、在宅勤務の中でコンスタントに毎日30分〜1時間ぐらい本を読む習慣ができてきた気がする。

😢 Webエンジニアとして成長した感じがしない3ヶ月だった

はっきりとした理由はわからないが、業務でやっていること、コロナにより今まで通りの仕事ができない(と感じている)こと、その他いろんな要因があって
エンジニアとして何かできるようになった、というのが実感できない数ヶ月だった。
5, 6月のブログが0件なのも一部それを表している気がする。

ありがたいことに一緒に働く仲間たちがみんな優秀なので、必要以上に彼らと比較してしまっているという部分もあるのだとは思う。
四半期の後半あたりから「もう今一番自分がやりたいと思うことをやろう」と考えるようになってから少し吹っ切れたかも。

次の四半期(2020年7〜9月)のテーマ

7月中に今読んでる本は終わるといいなあ。
終わったら、次はこの2冊のどちらかを読みたい。

年末に立てたTryの確認

  • 英語ブログ、今年こそ書く!目標は3本
    • →何もやってない
  • 今年もどっかのカンファレンスにCfP出す
    • →何も(略
  • 「みんなのデータ構造」とあともう1冊、コンピュータサイエンスに関する本を読む
    • ✅「みんなのデータ構造」
  • 本は年間で6冊読む
    • →2冊め