hiro_env

モダンな技術スタックを扱う会社のエンジニアになるまでの学習記録

Happiness Chain Euforia 4か月目の振り返り

Happiness Chain Euforia

Happiness Chainというスクールの新しく始まったEuforiaというコースで12月1日より0期生として学ばせていただいております。
毎月月報を投稿しており、今回は4回目です。 以下、2024年3月の振り返りを記載します。

3月の学習時間

  • 68h

良かったこと

  • 毎日学習記録をつけ、GitHubに日報としてあげる習慣が続いていること
  • 今の現場のお仕事を辞めることが決まり、新しい会社で業務委託をさせてもらえそうな状況ができたこと

悪かったこと

  • 学習面
    • ロードマップを進めることができていないこと
    • タスクが増えてやることが多い状況で、それらをうまく処理できていないこと
    • コミットしている時間がそもそも少ないこと
  • 生活面
    • 気分が落ち込むことが増えていたが、気付けば1週間の中で運動する日数が減っていた

改善すること(ネクストアクション)

  • コミットする時間を増やす
    • 元々夜型だったので中々思うように早起きができないことが最近は多かったが、仕事前に必ず学習する習慣を継続すること
    • → 夜より朝の方が集中して学習できている実感があるのと、遅く寝ると翌日のパフォーマンスが低下するため
  • 週5日以上は運動をする

今月の目標

  • 新しい仕事に備えてできることを精一杯やる
  • 新しい会社の研修、HCのロードマップをメインにGoの学習を続ける

Happiness Chain Euforia 3か月目の振り返り

Happiness Chain Euforia

Happiness Chainというスクールの新しく始まったEuforiaというコースで12月1日より0期生として学ばせていただいております。
毎月月報を投稿しており、今回は3回目です。 以下、2024年2月の振り返りを記載します。

2月の学習時間

  • 121h15m

良かったこと

  • 毎日学習記録をつけ、GitHubに日報としてあげる習慣が続いていること
  • 別スクールのハッカソンが比較的良い形で一旦区切りがついたこと

悪かったこと

  • 全体的にモチベーションが低下しがちな月だったこと
    • 業務、ハッカソン、TS、Goなどやることが多く、集中してやる作業が絞れずに中途半端になってしまいがちだった
  • 朝に学習する時間が減少したことで、月全体の学習時間が1月の3分の2程度に減ってしまったこと
  • 業務でTSを使う可能性があったこともあり、GoとTSを欲張ってどちらも学習しようとした結果、どちらもあまり進めることができなかった
    • 結果的に業務でフロントにTSを使って実装することはなさそう、もう今の現場辞めます

改善すること(ネクストアクション)

  • Euforiaに入会してから2ヶ月ほど続いていた早起き習慣をもう一度取り戻し、総学習時間を増やす
  • ロードマップの達成が大きなモチベーションになっているため、以前たてた予定を守ることをより強く意識する
  • 今Reactで進行中の課題を終えたら、Goのロードマップに集中して取り組むようにする

今月の目標

  • Goをメインに進めて、ロードマップ中級の半分以上、できれば課題に取り組むところまで進める
  • 早起き習慣をもう一度身につける
  • 運動習慣の継続

Golang make関数の備忘録

make関数

3つの型を作成する時に使われる

  • Slice
  • Map
  • Channel

用法

Slice

make([]T,  length, capacity)
  • capacityのみ省略可能
  • capacityをつけると容量をあらかじめ指定するため、要素を追加したときに再割り当てのメモリ操作をしないで済む。パフォーマンスの向上を見込める。
  • capacityを超えても再割り当てが行われるため問題はない。
  • lengthで指定した要素の分だけ最初はT型のゼロ値で初期化される。

Map

make(map[T]V, size)
  • sizeは省略可能。
  • 第二引数のsizeで、Mapがあらかじめ確保する初期のエントリー数のヒントを与えられる。

Channel

make(chan T, buffer)
  • bufferはチャネルのバッファサイズを指定し、非ブロッキングで受信可能な値の数。
  • bufferは省略すると、非バッファチャネルとなる。



その他の生成方法や初期化についてのメモ

スライスの生成方法

  • make([]T, length, capacity)とするか、s := []T{}とすることで中身がある状態で生成可能
  • 宣言しただけの状態 var s []Tでも変数sの中身はnilだが生成可能。(どの方法でもappendが使える)

スライスも構造体も、その他全ての組み込み型は宣言のみでゼロ値で初期化される。

  • スライスのゼロ値 => nil
  • 構造体のゼロ値 => 各フィールドがその型のゼロ値の状態を持つ

type SomeType struct {
    A int
    B string
}

var s SomeType
// sのフィールドA, Bは宣言された時点でそれぞれ0と""で初期されている

Happiness Chain Euforia 2か月目の振り返り

Happiness Chain Euforia

Happiness Chainというスクールの新しく始まったEuforiaというコースで12月1日より0期生として学ばせていただいております。
毎月月報を投稿しており、今回は2回目です。 以下、2024年1月の振り返りを記載します。

1月の学習時間

  • 180h50m

良かったこと

  • 生活面
    • 朝6~7時に起き、業務開始前に2~3時間勉強をすることが習慣になってきたこと。
    • 体力と集中力をつけて学習を効果的にできるよう先月からトレーニングを再開していましたが、最近は少しずつ強度が上がってきたこと。
  • 技術面
    • ロードマップにもありますが、Vimを毎日使うためだいぶ使い慣れてきたこと。
      • 以前は上下左右移動、インサートモードへの移行や保存終了のみを使っていましたが、今は検索や移動、文字の切り取り貼り付けや単語の書き換え、1文字のみの書き換えなどが自然にできるようになった。)
    • Goを学び始めたこと

      • スターティングGo言語を読み終え、Udemyの初級者向けの講座を1本視聴
      • 課題を通してアウトプットする中で、書き慣れていないGoの文法を少しずつ習得している最中です。
      • 新しい言語を学び始めた高揚感と、理解できていなかったり慣れていなかったりすることに対してモヤモヤする感情が混ざり合っていますが、とにかくアウトプットを中心にすることを忘れず、学習を続けていけたらと思っています。
    • 毎日日報を書き続けていること。

      • Euforiaに入会してから毎日欠かさずに学習記録を日報としてGitHubに上げています。
    • 入門書が多いですが、入会してから技術本を5冊読めたこと。(12月を含め)

      • これまでそれほど技術書を読んできていませんでした。もしかしたら人生で一番活字に触れた2ヶ月だったかもしれません。

悪かったこと

  • 朝時々起きれない時がある
    • もともと朝に弱いこともあり、朝勉強時間を確保できないくらい寝てしまうことが時々あります。
  • アウトプット量がインプットと比較して若干少ない
    • 課題に取り組んだり、気になったことを実際に手を動かして書いてみたりするということは実践していますが、まだまだアウトプット量が足りていないことを感じています。

改善すること(ネクストアクション)

  • 学習を続けたくても、夜は22時前後にはあえて切り上げて、翌朝やることをリストアップしてその日は寝る。

  • Udemyで見たことを、改めて部分的に変えて自分でアウトプットするところまで行う。

    • Reactはまだまだ実践が足りないので、アウトプット量を増やしていく。
    • TSはロードマップにクイズを含むアウトプット問題も多いので、教材と課題を中心にとにかく進めてく。
    • Go言語もインプット課題を進めるだけでなく、何かしらのコードを書いて毎日触れられるように気をつける。

今月の目標

  • TypeScriptとGoをメインにがっつりやる月にしたい
  • 2月は少し短いので毎日TODOと週間スケジュールを決めて、予定通りにタスクを終わらせる
  • 運動習慣の継続

『JavaScript Primer』の感想

JavaScript Primerjsprimer.net

~こちらの書籍を読んだ感想~

良かったところ

  • 暗黙の型変換ってそこまでやるのかというようなこれまで知らなかったことや、アロー関数と通常のfunctionでの定義の場合のthisの指すオブジェクトの違いなどの細かい点をいくつも学べたこと。

学んだこと

メモに残したものだけでも以下のような点を初めて知ったり、再認識したりできました。

  • 関数定義にある引数の数だけ渡さなくてもいい、渡されなかった引数はundefinedになり多い分には無視される
  • 暗黙の型変換では以下のように配列に入ってても暗黙の型変換される console.log(10 == ["10"]); // => true

  • オブジェクトリテラルのプロパティキーとして変数やシンボル、式を使いたい場合、[]を用いてそれを評価する必要がある。値は変数を直接書くことができる。

const key = "Key1"
const value = "Value1"
const obj = { [key]: value }
  • 取り出す際はブラケット記法なら動的にそのキーを変数やシンボルのまま書ける(obj[Symbol]の様に)が、ドット記法では静的な、キーが評価された値の方を使用する必要がある。
  • Rest Parameters / ...args のように...を使うことで残余引数を受け取れる
  • 関数の引数の取り扱いに柔軟性があるjsではオーバーロードは存在しない(引数が少ない場合はundefined,多く場合は単に無視されるため)
  • コールバック関数を引数として受け取る関数を高階関数と呼ぶ 式の最後には;が必要だが、ブロックで終わる文には必要ない
// learn関数を宣言する関数宣言文(;がいらない)
function learn() {
}
// 関数式をread変数へ代入(式で終わるため厳密には;が必要)
const read = function() {
};
  • delete演算子の存在(delete obj.key1;) -Object.hasOwnの使い方
const obj = {};
// objが"プロパティ名"を持っているかを確認する
Object.hasOwn(obj, "プロパティ名"); // true or false
  • pushは元の配列に変更を及ぼし(破壊的変更)、concatは新しい配列として返す(元の配列に影響しない、非破壊的変更)
  • array.concat() / array.slice() / [...array] はどれもarrayのコピーを作成できる。

filter関数のコールバックはbooleanを返す必要がある

const numbers = [0, 1, 2, 3, 4, 5];
const truthyValues = numbers.filter(number => number);
// truthyValues は [1, 2, 3, 4, 5] となる(JavaScriptでは0以外の数はすべてTruthy、0がFalstyのため)
  • プリミティブ型(数値、文字列、Booleanなど)からメソッドを呼び出す際、内部的には一時的に対応するラッパーオブジェクトに自動的に変換される
  • (プリミティブ型の値がラッパーオブジェクトの初期値として生成されている)

  • addEventListenerの第二引数でコールバック関数の引数として渡されるeventもオブジェクトである。

  • event.targetプロパティでそのeventのトリガーとなったDOM(要素のオブジェクト)が取得できる。
  • varによる変数宣言は、宣言部分が暗黙的にもっとも近い関数またはグローバルスコープの先頭に巻き上げられ、代入部分はそのままの位置に残るという特殊な動作をする

難しかったこと

学んだことにも記載したthisが何を指すのかがコンテキストによって変わるということが難しかったです。 開発の際はデバッグをして確認しながら間違わないように使っていきたいと思います。

RESTについての簡単な備忘録

RESTってなに?

Representational State Transfer の略
APIの設計思想である。

2000年にRoy Fieldingが論文で初めてRESTという言葉を使い、RESTに関する内容は大きく以下の6つを発表した。

  • Client-Server (クライアント/サーバー)
  • Stateless (ステートレス)
  • Cache (キャッシュ制御)
  • Uniform Interface (統一インターフェース)
  • Layered System (階層化システム)
  • Code-On-Demand (コードオンデマンド)

現在では参考記事のサイトや他の記事を見ても下記の4つくらいにわかりやすくまとめられていることが多い。


  • Statelessness(ステートレス性)
  • Uniform Interface(統一インターフェース)
  • Addressability(アドレス可能性)
  • Connectedness(接続性)

参考 : RESTful APIとは何なのか #API - Qiita

  • Statelessness(ステートレス性) RESTにおけるステートレス(状態を持たない)は、同じクライアントであっても各リクエストが前後のリクエストと独立していることである。
    それにはサーバーの資源をすぐに解放できるというメリットがある。 例として、冗長化されていて異なるサーバーに毎回リクエストを送る場合でも、リクエスト内に必要な情報を全て含めるため問題なくクライアントの望むレスポンスを受け取ることができる。

  • Addressability(アドレス可能性) 各リソースやサービスは統一された一意のURIのパス(uri/moviesなど)で表現され、アクセスが可能である。

  • Uniform Interface(統一インターフェース) 定めたURI(リソース)の操作がCRUDに応じてGET(READ), POST(CREATE), PATCH/PUT(UPDATE), DELETE(DELETE)という各HTTPプロトコルのメソッドによって行うことができるように設計する。

  • Connectedness(接続性) HTMLのように他のAPIハイパーリンクを含めることができる。 とあるAPIのレスポンスのボディに、関連する別のAPIURIが含まれることがある。

まとめ

かなり大まかに、かつシンプルに要点だけを抜き出すと以下のようにも表現することができそう。

  • 情報やサービスをリソースとして扱うこと。
  • URIを見てなんのリソースやサービスかが一目でわかり、HTTPプロトコルの各メソッドを動詞として考えた際になんの操作なのかがわかるようになっていること。
  • ステートレスであること。

ユーザーからのメリット:アドレスを見て何のページが表示されるかを予想、理解がしやすい。
開発者のメリット:統一されたインターフェースがあるためURIやHTTPメソッドに関して一貫したパターンに従って開発ができ、サービスの開発に集中しやすくなる。

達人に学ぶDB設計徹底指南書の感想(短め)

良かったところ

  • 論理設計と物理設計のトレードオフについて、その関係性が豊富に解説されておりその設計をすると何が良くて何が悪いのかが理解しやすい。
  • DBの設計に必要な多くの知識が、例題を介してグレーゾーンなパターン、またはバッドなパターンも含めて色々と学べるようになっている。
  • また、設計には完全な正解はなく思想が異なる人もいると前置きした上でご自身の見解について述べられており、どんな設計がベストかはケースバイケースであることを学ぶことができる。

学んだこと

  • 正規化の方法やなぜそれを行うべきかといった設計に関する重要なことや実務運用上の注意点、インデックスや統計情報に関して、またリレーショナルデータベースでは比較的難しいとされていたツリー構造の表現方法(入れ子集合モデル・入れ子区間モデル・隣接リストモデルや経路列挙モデル)など。
  • 特に正規化については基本かつ大切だと思うので、忘れないよう簡単に言語化しておく。
  • 正規化
    • メリット:データを挿入、更新する際の人為的ミスを防ぎ整合性を担保すること(同じ情報を複数の場所に重複して保持することを避ける)、また冗長なデータを減らすこと。
    • デメリット:データの取得や使用に際して結合が必要なとき、パフォーマンスが悪化すること。

難しかったこと

  • ツリー構造の表現をRDBで実現する方法を初めて学んだため、実際にテーブルに入れた際のクエリの作成方法が難しかった。