シード期スタートアップエンジニアの技術ブログ

仕事で得た知見や勉強した技術を書きます。

【Webを支える技術】第2部 URIをざっくりまとめてみた

URIとは何か?

URIとは、リソース(Web上の情報)にアクセスするためのIDです。リソースを一意に識別できます。

URIの書式

http://blog.example.jp/entries/1
名前 URIを構成するパーツ 意味
URIスキーム http URIスキームは、そのURIが利用するプロトコルを表します。httpの場合、リソースにHTTPでアクセスできることが分かります。
ホスト名 blog.example.jp ホスト名の部分には、DNSで名前が解決できるドメイン名かIPアドレスがきます。インターネット上のIPアドレスグローバルIPアドレスなので、ホストはインターネット上で必ず一意になります。
ポート番号 80 ホスト名の後ろに:で区切ってポート番号を書くことができます。ポート番号は、このホストにアクセスするときのプロトコルで使用する番号です。ポート番号を省略すると、そのプロトコルで使用するデフォルトのポート番号が使われます。HTTPのデフォルトのポート番号は80番です。
パス /entries/1 ホストの中における一意なリソースを表します。リソースは一意であるべきなので、ホストの中で同じリソースが複数存在するのは良くないです。

Tips

  • URIスキームとその後ろに続く部分は「://」で区切られます。
  • インターネット上で一意なホスト、ホスト上で一意なリソースなので、あるリソースのURIは他のリソースのURIと重複しないようになっています。
  • ホストとは、ネットワークに接続されたコンピュータのことです。ホストにはIPアドレスが設定されています。

URI・URL・URNの違いは何か?

名称 意味
URI URIとURNを合わせたもの
URL リソースの一意な位置を表す
URN リソースの一意な名前を表す

URNはあまり利用されていないので、実質的にはURIとURLはほぼ同じ意味です。

絶対URIと相対URIの違い

OSのファイルシステムには、絶対パス相対パスがあります。 相対パスを使うことで、ディレクトリやファイルの位置をルートディレクトリ( / )から書かずに、カレントディレクトリから指定できます。カレントディレクトリをbar、親ディレクトリをfooとする場合、相対パス絶対パスは以下のようになります。

相対パス 絶対パス
hoge /foo/bar/hoge
hoge/fuga /foo/bar/hoge/fuga
./hoge /foo/bar/hoge
../hoge /foo/hoge
../hoge/fuga /foo/hoge/fuga
../../hoge /hoge

OSのファイルシステムと同様に、URIにも絶対URIと相対URIがあります。 相対URIは、URIスキームとホスト名を省いた、パスだけのURIです。相対URIでもリソースの位置を指定できます。クライアントは相対URIを理解できないので、相対URIを使うにはベースURI(http://example.jp/foo/bar)が必要です。相対URI、ベースURIを用いて絶対URIに変換してリソースにアクセスしているので、ベースURIは必要です。

相対URI 絶対URI 備考
/foo/bar http://example.jp/foo/bar
hoge http://example.jp/foo/bar/hoge ./hogeで同じ
../hoge http://example.jp/foo/hoge
?q=hoge http://example.jp/foo/bar?q=hoge
#hoge http://example.jp/foo/bar#hoge #から始まる文字列は「URIフラグメント」と言う

Tips

相対URIの前に/がある場合、この相対URIは、ホスト名以降のパスを示していることになります。

2つのベースURIの与え方

リソースのURIをベースURIとする

あるリソースを取得時、そのリソース内で相対URIが出てきたら、取得したリソースのURIをベースURIとするやり方です。しかし、この方法ではリソースのURIをクライアント側で保存する必要があります。リソースを取得したときのURIは保存時にはわからないので、この方法は成立しません。

ベースURIを明示的に指定する。

HTMLやXMLの中で明示的にベースURIを指定する。HTMLの場合、要素の中に要素を入れます。このやり方の場合、先ほどの問題を解決できます。

<html xmlns="http://www.w3.org/2022/xhtml">
  <head>
    <title>test web page</title>
    <! -- このHTML文書内のベースURIはhttp://example.jp/になる -->
    <base href="http://example.jp/" />
    ...
  </head>
  ...
</html>

Ruby on RailsにおけるベースURI

APIモードとして使う場合、絶対URIAPIにリクエストを出します。 フルスタックフレームワークとして使う場合、base要素にベースURIを指定するやり方で相対URIを解決しています。base要素の指定がない場合、location.hrefの値がデフォルトのベースURIになります。Railsのapplication.html.erbにはbase要素が指定されていませんが、暗黙的にlocation.hrefの値がベースURIになっています。 Image from Gyazo

相対URIをホバーすると、絶対URIが表示される

URIで利用できる文字以外をURIに含めたい場合

URIで利用できる文字は、アスキー文字だけです。半角の英字(a~z、A~Z)やアラビア数字(0~9)、記号、空白文字、制御文字など128文字が規定されています。

アスキー(ASCII)文字

種類 アスキー文字
アルファベット A-Za-z
数字 0-9
記号 -.~:@!$&'()

アスキー文字以外をURIに入れたい場合、%エンコーディングをします。%エンコーディングでその文字をエンコードします。

Tips

良いURLとは何か?

良いURIとは、「変わらないURL」です。「変わりにくいURL」と捉えることもできます。変わらないURLにすることによって、システムやドメインの変更が起きても、リンク切れを回避することができます。また、良いURIは、シンプルです。シンプルであると、入力するのが簡単で覚えやすいです。

URIの設計指針

どうしてもURIを変更したい場合

できる限り古いURIから新しいURIへリダイレクトします。

  • 変更前
http://example.jp/old
  • 変更後
http://example.jp/login

古いURIでクライアントがリクエストを出すと、次のレスポンスが返ります。

HTTP/1.1 301 Moved Permanetly
Location: http://example.jp/login

クライアントは、ステータスコードからリダイレクトであることを理解し、Locationヘッダで明示された新しいURIにリクエストを出します。 リダイレクトを実現する仕組みはHTTPサーバが用意しています。

マトリクスURIとは?

マトリクスURIとは、複数の軸のパラメータをセミコロンやカンマで区切ってリソースを表現するURIです。リソースを階層構造で表現できない場合に使用します。Googleマップで緯度や経度を表す時に使います。以下のURLでは、パラメータの順序で緯度・経度を指定しています。

https://www.google.com/maps/@34.6794753,126.7831703,5.26z?hl=ja

URIは不透明であるべき。

ユーザーが適当にURIを入力して有料会員限定のコンテンツが見れる等を防ぐため、URIからリソースの内容を推測されないようにするのが大事です。

参考記事

<base>: 文書の基底 URL 要素 - HTML: HyperText Markup Language | MDN

パーセントエンコーディング - Wikipedia

DAY19(2022 6/27) ~ DAY23(2022 7/1)

シナトラ

今週の目標

継続

yukihaga.hatenablog.com

新規

  • タスクをできるだけ早く終わらせることを意識する
  • 平日で1週間の振り返りブログを書き終わる
  • マスタリングTCP/IPを読み終わる
  • web技術で学んだ全てのことをブログにする。
  • 目的がないのに見るのをやめる。

DAY19(2022 6/27)

  • 画像レイアウトを修正した。
  • 親要素を超えるとレイアウトが崩れるエラーを修正した。
  • Webアプリケーションのテストケースをひたすら考えた。
  • github copilotが凄すぎて感動した。推測されるコードが正しいかを自分で判断する力が大事だと感じた。

DAY20(2022 6/28)

  • ひたすら作成したテストケースを手動テストした。
  • レイアウトが崩れる問題をした。70%くらいやったが、インターバルでデータを取得してたり、色々複雑だったので一旦保留にさせてもらった。

DAY21(2022 6/29)

  • サイズを変更した。
  • レイアウトが途中で消えないような実装を追加
  • オーバーレイを自力で実装した。
  • 要素全体をtransform: scale(arg)で小さくした。
  • 画像を別の画像に差し替えた。
  • 不要なログを全部消した。

DAY22(2022 6/30)

  • 5時30に起きる予定だったが、二度寝して6時20分くらいに起きた。ただ、頭の回転は朝のが良いので、夜遅くまで勉強するよりは朝にやるのがやっぱり良いなと感じた。
  • テストをひたすらやっていた。
  • バーのレイアウト修正をした。
  • 旅行でも良いからシリコンバレーに行きたくなった。DeepL使っている場合じゃない、、
  • build_associationに引数を持たせて、データ生成時に初期値を設定できるようにした。

DAY23(2022 7/1)

  • バーのレイアウトをひたすら修正したが、うまくいかないので月曜やる。
  • zero division errorを解決した。
  • リリースが終わったので、飲みにいった。

開発における気づき

  • Typographyにalignを設定するなら、width: fit-contentを指定してはダメ。Typography自体がテキストの親要素になるので。
  • 親要素にposition: relativeを指定すれば、position: fixedでも基準を親要素に変更できる。
  • overflow: scrollで要素に収まりきらない場合にスクロールできる。
  • scrollTopはスクロールされた要素の最上部から可視コンテンツの最上部までの長さである。
  • scrollHeightで画面上に表示されていないコンテンツを含む要素の高さを取得できる。
  • reactにonScrollイベントがある。
  • イベントを経由してDOMを取得するなら、useRefを事前に仕込まなくても良い。
  • loadashは値を操作する便利メソッドを提供するライブラリ。配列の比較などが簡単にできるそう。
  • transform: scale(arg)でx軸とy軸で拡大・収縮ができる。文字列とかdivでもいける。
  • 真偽値を返す関数の名前がisから始められないなら、existsを使う。
  • コミットIDはコミットタブからコピーした方が良い。
  • ショートサーキット演算子&&や||は、オペランドがtruthy or falsyかを判定して、結果的にオペランドを返している。
  • マウスは腕や肘、手を固定した方が動かしやすいかもしれない。
  • gyazoでbefore、afterを撮る場合、検証ツールでスタイルを変えるだけの方が早いので良い。
  • SaaSのカスタマーサクセスにおける「オンボーディング」とは、新規ユーザーが「自走」状態でサービスを活用できるまで導くプロセスのことです。
  • Appcuesはオンボーディング最適化ツール。
  • ブランチ切り替えて何か動作がおかしいなら、docker-compose upをする。
  • プラスアドレスでアドレスを増やすことができる。本番で1@example.comとか使ってはいけない。ほんとにそういう人がいるとメールが送られちゃうので。
  • ファイルをスクロールしない。
  • コンポーネント探す時も検索機能を使う。
  • booleanの変数名もisから初める。
  • implicit_order_columnを使うことで、どのカラムでレコードを順序づけするかを決めることができる(デフォルトはid)。idにuuidを使っている場合、使う。
  • allow_blank: trueで空の値の検証をスキップする。
  • has_one_attachedのdependent: purge_laterオプションが設定されていない場合、レコードが破棄されるたびに添付ファイルが消去される。
  • デフォルト値をテーブルに設定すると、DBの設定を変えたりなど、変更するのに一手間かかる。そのため、コードベースでデフォルト値を設定した方が良い。after_createなどを使って。変更に一手間かかり、変更に弱いシステムになる。もし絶対に変更しないカラムなら、テーブルのデフォルト値にする。ここはチームによるかもしれない。

  • カラムのオプションの変更をしたが、それをなくしたいだけなら、ファイルを消して、スキーマのオプション部分を消して、DBを直接SQLとかでいじれば良い。流れをちゃんと理解していれば良い。Railsが結局何をやっているのかを理解すれば、Rails Wayに則ってなかろうが、自分で対応策を考えられる。

  • schema.rbを直接いじっても、DBを直接変更すれば大丈夫。

調査すること

  • optionalなpropsを渡さなかった場合、undefinedになるのか?それがonClickなどのイベントに設定されたらどうなるのか?

所感

  • Railsのコマンドが結局何をやっているのか?なぜそれを使うのか?それを使ったら何が起こるのか?をもっと知るべきだなと感じました。そのブラックボックスになっている部分をもっと知ることで、結局何をしているかが分かり、自分で対応策を考えることができるので。

  • CEOと話して、シリコンバレーに行きたい欲がすごい上がった。DeepL使っている場合じゃない、、英語も並行して勉強していきます。

以上です。7/4からの5日間も頑張ってきます!

【Webを支える技術】第1部 Web概論をざっくりまとめてみた

なぜこの記事を書いたか

本を読むだけだと、読むだけで終わってしまい、「結局何なの?」が自分の中で明確にならないので、記事にしました。

インターネットとは何か?

インターネットとは、世界中のネットワークとネットワークを相互接続したネットワークのことです。ネットワークのネットワークとも言えます。

外のネットワークとどうやって接続するのか?

私たちが使っているPCやスマートフォンは家や会社のネットワークに属しています。そのネットワークは、ルータやインターネットサービスプロバイダー(インターネットに接続できるサービスを提供する事業者)を利用することで、外のネットワークに接続することができます。

Webとは何か?

Webとは、インターネット上でWebブラウザを用いて文書や他のWebリソースにアクセスできる情報空間です。文書はHTMLで構成されています。そして、ハイパーリンクを埋め込むことができます。そのため、参考資料等の関連する文書をネットワーク経由で簡単に閲覧できます。WebサイトはWebサーバを実行しているコンピュータに保存されています。

Webの2つの側面

  • ハイパーメディア(テキスト、画像などのメディアをハイパーリンクで結びつけて構成したシステム)
  • 分散システム(複数のコンピュータでデータを処理する)

Webの用途

  • Webサイト
  • ユーザインターフェース(デバイスの設定画面やメールの編集画面等。ユーザーが直接メールサーバを操作しなくて良くなる。ユーザーのしたい操作をWebサーバがメールサーバに伝えてくれる)
  • プログラム用API(プログラム向けのインターフェース)

APIとは何か?

APIとは、外部のプログラムからアプリケーションの機能を利用するための仲介役みたいなものです。Web APIの場合、Webを経由して外部プログラムがAPIと接続します。プログラム向けのインターフェース(API)で返却されるリソースのデータフォーマットは、JSONXMLなどのプログラムで解釈・処理しやすいものを使います。

Webを支える基本的な技術

  • HTML
  • URI (リソースを特定するための一意なID。プログラムはURIを用いてリソースの表現する情報にアクセスできる。)
  • HTTP (異なるコンピュータ間のWebにおけるデータ通信の取り決め。8つのメソッドを定義している)
  • Webサーバソフトウェア(Apache HTTP Server等)
  • Webクライアントソフトウェア(ブラウザ)

インターネットとWebの違いは何か?

インターネットは世界中のネットワークを相互に接続して構成された大規模なネットワークです。Webはインターネットを利用して、情報を閲覧・公開する空間です。似たような言葉ですが定義は異なります。 余談ですが、初期のインターネットにはWebがなかったそうです。実験結果を研究者間で共有するのに、既存の電子メールやファイル転送技術では使い勝手が悪かったので、Webが提案・開発されました。

REST(Representational State Transfer)とは何か?

RESTとは、Webの設計思想です。4つの原則で構成されています。RESTの原則に従ったWebシステム(RESTfulなシステム)同士は、円滑に情報を連携することができます。HTTPでやりとりするデータはハイパーテキストだけではなく、「リソースの状態」の「表現」を運んでいるという主張が、RESTという命名につながっています。

RESTの原則

  • 統一インターフェース(HTTP。あるURIに対してGETやPOSTなどのリクエストメソッドを指定してリクエスト(GETリクエスト・POSTリクエスト等)を出すと、リソースの状態の表現を取得したり、リソースの状態の更新ができる。)
  • アドレス可能性(全てのリソースが一意なURIで特定できる)
  • 接続性(やりとりされる情報にリンクを含めることができる)
  • ステートレス性

リソースとは何か?

リソースとは、Web上に存在する名前を持った情報です。リソースは状態を持ち、URI(一意なID。名前とも捉えられる)で特定できます。クライアント側にリソースを返す場合、HTMLやJSONで表現します(リソースの表現)。

参考記事

ja.wikipedia.org

www.soumu.go.jp

https://wa3.i-3-i.info/diff661network.html

https://wa3.i-3-i.info/word1121.html

en.wikipedia.org

https://wa3.i-3-i.info/word12428.html

https://wa3.i-3-i.info/word12429.html

www.mulesoft.com

en.wikipedia.org

ja.wikipedia.org

【2022年】やると決めたこと・やらないと決めたこと

なぜこの記事を書いたか

やると決めたこと・やらないと決めたことを書くことで、決めたことを忘れないようにするためです。1ヶ月弱働いたので、このタイミングで決めようと思います。色々生活する中で変化することはあるかもしれませんが、一旦は決めたことをやり抜こうと思います。

やると決めたこと

  • 7時間絶対寝る(0時~7時)。
  • 寝る前に次の日の着替えとハンカチを用意する。
  • 起きたら腕立て、背筋、腹筋をして冷水シャワーを浴びる。
  • 7時30分~8時まで30分勉強する。前日はできるだけ速く寝てこの勉強時間を増やす。8時には必ず家を出る。
  • 朝の電車では本を読む。夜帰る時にはてなブログを書く。
  • 20時には絶対帰る。
  • 朝はドーナツ、昼はパンを食う。
  • 平日も土日も1日のやることが終わってからpcを見る。
  • 土曜日だけTwitterを15分見る。ネタがあるなら何かしら投稿する。
  • 土日は自分がやる必要があると思うことに時間を投資する。
  • 朝から昼飯の間で重めのタスクをやる。
  • 13時に昼飯を食う。食べた後は15分寝る。
  • タスクやエラーに取り掛かる前は深呼吸をする。誰かに教える感じでやる。
  • どんな小さなタスクでも時間を設ける。基本的には30分周期でタスクをこなす。
  • 仕事するときは毎回「自分が今何をしたいのか」を客観的に頭の中で言う。
  • レイアウト系のタスクは、最初にhtmlを組んで検証ツールでスタイルを全部組んでから、コードを書く。
  • 1日のやることが全て終わってからDiscordを見る。なるべく朝に見る。
  • 1週間で1冊本を読む。
  • ラーメンは週一食べるか食べないかにする。
  • 月に7万~10万貯金する。(借金を早く返したいので)
  • 探すことになるべく時間をかけない。
  • マウスをなるべく使わない。
  • 本当に困った時しかQiitaは見ない。なるべく公式ドキュメントやエラー内容、検証ツール、自分の考えをもとに解決策を作る。
  • 1週間働いた感想をブログに書く。
  • 土日は皿洗いをする。
  • 水曜日の朝に洗濯をして、水曜日の夜までに洗濯を干す。
  • 1週間に1冊本を読み切る。

やらないと決めたこと

  • マターモストは毎日見ない。土曜の15分だけ見る。
  • 一人で外食するときは、提供時間の長い飲食店にはなるべく行かない。
  • ケータイでネットサーフィンをしない。
  • SaaS、スタートアップ、VC、ビジネスサイドの勉強(現時点では技術力や実装力を上げることの方が優先順位高いので、一旦保留)

1年以内に実現したい状態

  • AWS、Docker、Rails、React、TypeScript、JavaScript、Webpack、CSS、HTML、Web、ネットワーク、Linuxアルゴリズム、DB、SQLがそこそこ出来るようになる。

  • ほとんどのタスクを自力で実装できるようにする(技術力や実装力をもっと上げたい)。

  • 1年分の借金を返済する。

  • 一人暮らしをするかシェアハウスに住む。

    • 一人暮らしをしたとしても、食生活は健康的にする。
    • ちゃんと運動をする。日に日に体力だったり力が落ちている気がするので。
  • 副業を始める。

  • 基本情報を取ってみる。

  • Rubyゴールドを取る(なんだかんだgemのコードを読むこともあるので)。

  • 毎日英会話をする(フロントをやっていると英語を読むことが多いので、英語に慣れたい為)。

  • ポートフォリオサイトを作る。

  • 効率化系のChromeエクステンションを作る。

  • CSを勉強する。

将来的にやりたいこと

  • 個人開発
  • 数検1級を取る(数学をもっと知りたい)
  • 筋トレ(体力や筋力の低下を日々感じているのでそろそろやりたい。やらないとやばい。)

キャリアの選択肢

自分は割とユーザーに価値を提供するのが好きな、プロダクト志向のエンジニアなのかと思っていました。しかし、実際に働いてみるとそんなことはなく、技術を重視しているエンジニアであることがわかりました。保守性や再利用性の高いコードを書いたり、その言語やフレームワークの流儀に従ったコードを書いたり、他の人が読みやすいコードを書いたり、意味のあるディレクトリ構成を作ったり、どういう技術や実装方法でプロダクトを実現するか?に関心があるような気がします。チームで開発をしているとプロダクトよりもそういう面ばかり気になります。きっと自分が好きだと思えるプロダクトは自分にしか作れないと思うから、仕事ではプロダクト志向は一旦置いといて、技術を重視しているのかもしれません。個人開発に注ぐ熱量を仕事に注ぐのはかなり難しいと感じています。ビジネスのスピードを上げるために、実現することだけを重視したコードを書くのは間違っていないが、やはりどうしても気になってしまう。色々な要因があって現在はこのような思考になっていると思うので、将来的にはまた変化するかもしれません。

以上のような傾向を考慮すると、個人開発者、フリーランス、CTO、テックリードが良いのかなと感じています。しかし、組織を作ったり、組織に属したりするのにあまり興味が持てないし、向いていないと感じるので、個人開発者かフリーランスになると思います。2~3年後は全く別のことを言っているかもしれませんが、現時点だとそういう結論に至りました。

実現できるよう頑張ります!

DAY14(2022 6/20) ~ DAY18(2022 6/24)

今週の目標

いそじの冷やし中華



■やると決めたこと

  • 7時間絶対寝る(0時〜7時)。できるだけ早く寝て朝勉強する
  • 7時30から8:00まで30分勉強する。この時間は極限まで増やす
  • 20時には絶対帰る。
  • 今週の終わりまでに「マスタリングTCP/IP」を読み終わる
  • 水曜日の朝に洗濯をして、その日の夜までに干す。
  • 朝はドーナツ、昼はパンを食う
  • 夜のうちに朝着る服とハンカチを用意する
  • 平日も土日も1日のやることが全て終わってから家のPCを見る
  • 土曜日の朝に15分だけTwitter を見る。ネタがあるなら何かしら投稿する
  • 土日は自分がやる必要があると思うことに、時間を投資する
  • Discordは1日のやることが終わったらみる。重要度の高い場合は優先して見る。
  • 朝に重めのタスクをやる。頭が回転するので
  • 13時に昼飯を食う。食べた後は15分寝る
  • 朝に腕立て、腹筋、背筋をして冷水シャワー浴びる
  • タスクやエラーに取り掛かる前には深呼吸をする。冷静になる。誰かに教える感じでやる
  • 仕事するときは毎回「自分が今何をしたいのか」を客観的に頭の中で言う
  • どんなに短い作業でも時間を割り当てる
  • 脳みそに考えさせる前に体を動かして行動する。

■やらないと決めたこと

  • マターモストは土日しか見ない

DAY14(2022 6/20)

  • この日から朝筋トレを始めた。
  • この日から昼飯を13時に食べて、15分寝ることにした。
  • 午後は眠くならなかった気がする。月曜日だからなのかもしれない。
  • レイアウト変更のタスクに着手した。なんでか分からないが意外と苦戦した。
    cssでレイアウト整える系のタスクは、検証ツールでレイアウトを整えてからコードを書く方が効率良いと感じた。コードを書くたびにコンパイルを通すのが面倒なので。
  • Reactの書き方は本当に自由度が高いなと感じた1日だった。人によって全く書き方が違う。。

DAY15(2022 6/21)

  • 画面の大きさに応じて、横幅のレイアウトを変更できるような仕組みを作成した。
  • フォームから文字列データを送ると、その文字列データが画面のある部分に反映されるような仕組みを作成した。
  • 投資先が提供しているコミュニティで出会った方とラーメンを食べに行った。同じ自社開発でも、フェーズが違うとやる仕事が全然違うことを理解した。あといそじの冷やし中華が美味しすぎて感動した。代々木に行く際はもう一度行くかもしれない。

DAY16(2022 6/22)

  • 画面に反映される文字列データのレイアウトを修正した。
  • 変換処理が完了していない場合、別の画像を表示するような処理を作成した。
  • 既に存在しているデータを元に新しいものが作れるような処理を作成した。

DAY17(2022 6/23)

  • 既に存在しているデータを元に新しいものが作れるような処理の続きをした。

DAY18(2022 6/24)

  • 画面に画像を追加した。webpackのコードを読み解く必要があったので、公式ドキュメントを読んだり指定て意外と時間が掛かった。

開発における気づき

  • Array.prototype.findを使うことで、指定されたテスト関数に一番初めにマッチする要素を取得できる。

    const array = [1, 2, 3, 2];

    console.log(array.find(x => x === 2)); // => 2

  • overflow: hidden; は、領域からはみ出たテキストを表示させなくする。

  • React Playerは、さまざまなURLを再生するためのReactコンポーネントを提供しているライブラリ。
  • 二重否定(!!)を使うことで、明示的にあらゆる値に対応する論理型プリミティブに変換することができる。
  • webpack.config.jsonにエントリーポイントの設定方法が書いてある。
  • React-Cookieを使うことで、Reactでクッキーを管理できる。
  • document.headでhead要素を取得できる。
  • scriptタグにasync属性をつけることで、非同期でJSファイルをダウンロード、実行できる。ダウンロード完了後、即JSファイルは実行され、実行中はHTMLパースが一時停止する。scriptタグにasync属性をつけることで、HTMLパースと並行してJSファイルをダウンロードできる。async属性をつけないとHTMLパース中にscriptタグがあったら、パースを一時停止してJSファイルのダウンロードと実行を行なってしまう。実行が完了するまでHTMLのパースは再開しない。
  • 検証ツールを開いた状態でリロードのアイコンをドラッグすると、キャッシュを削除してリロードできる。cssのスタイルやJSが反映されない場合はキャッシュの削除を試してみる。
  • ブラウザコンソールで上矢印を押すと、過去に実行したスクリプトをサーチできる。
  • フォームタグだとエンターキーで送信できる。ajaxだとクリックしないと発火しない。
  • widthが100%以外の場合、calcをなるべく使う。width: 80%と指定すると、残りの20%のpxが一定ではなくなるので。calc(100% - 20px)とやると、残りが20pxであることが保証され、画面の大きさによって、余白のレイアウトが大きく変わったりしなくなる。
  • clientWidthでDOMのwidthを取得することができる。Reactを絡めるならuseRefでDOMを取得する。
  • fit-contenntを使うことで、コンテンツの幅に合わせたサイズを指定できる。
  • max-widthでこれ以上大きくならない幅を指定できる。min-widthでこれ以上小さくならない幅を指定できる。
  • box-sizing: 'border-box'でpaddingとborderをwidthに含めることができる。子要素がwidth100%なのに親要素を超える理由は、padddingやborder,marginに原因がある。
  • よく見る記事に辿り着くまでのスピードを極限まで速くする。ブックマークしてholmesで一瞬で探せるようにしておく。キーワード検索して、多くの記事の中からよく見る記事を見つけるのは意外と時間がかかるので。
  • useFormのデフォルトバリューがどうなっているのかをとことん調べてまとめる必要がると感じた。忘れやすい。
  • railsコマンドやbundlerなどのコマンドを実行したいなら、Dockerホスト上に一回入る。自分のホスト上にはbundlerなどが入っていないため。
  • 事例をネットで探すより、検証ツールやエラーを調べて「なんでこうなるのか?」を調べた方が早い。自分に100%あった事例が見つかるわけないので。どうしても分からんエラー(webpackやdocker-compose系)などは調べてから聞く。
  • httpヘッダに対する理解がまだない気がする。通信を意識できていない。
  • パーフェクトRailsを自分でやってみたい。
  • ロゴはブランドイメージを確立して認知してもらうためのもの。
  • jsxでインラインスタイルを書くことができる。
  • エラーが出たら、コンパイルが通っているのかをまずは確認する。
  • publicディレクトリには、静的ファイルやコンパイル済みのアセットが置かれる。このディレクトリ上にあるファイルはインターネットに公開される。
  • コンパイル、トランスパイル、ビルド、APIブレークポイント、グリッド、ここら辺の言葉の定義をもっと知りたい。あとscssの書き方を知りたい。
  • webpackのDefinePluginで環境変数的なのが定義できる。
  • 呼ぶ側に負担をかけない。雑に呼んでも良いようなコードを書く。
  • 交差型は、共通部分って感じではなく、両方の型を持つような型が生成されている。
  • パス = コントローラ名/アクション名となる場合、to:以下を省略できる。
  • vscode内で上下にカーソルを移動させるときは、なるべく行番号で移動させる。連打するのがしんどいので。
  • justify-contentで子要素のdivを真ん中寄せしたいなら、そのdivはwidthを持つ必要がある。そうしないと親要素いっぱい広がるので。
  • MUIのTypographyなどのテキストを真ん中寄せしたいなら、propsのalignを使う。
  • めんどくさいコマンドでキーボードを叩くような時間を極限まで減らす。
  • スタイルやレイアウトを組むスピードをもっと上げる。gridやflexcssをもっと使いこなす。
  • iframeは動画サービスの動画をhtmlに埋め込みたい時に使う。videoタグは任意の動画をhtmlに埋め込みたい時に使う。
  • axiosにonUploadProgressという機能がある。
  • attachは、active_storage_blobを引数に取るらしい。
  • active storageとは何で、どんな方法を使ってモデルとファイルを紐づけているのかをもっと深いところまで知りたいと感じた。ファイルアップロード系の機能を作るのが弱いので。
  • ビジネスロジックとは、そのシステム固有の処理のこと。ビジネスロジックを分けることで、そのシステム固有の処理と、他の部分でも利用できる処理を特定できる。システム全体に変更が発生した場合でも、ビジネスロジックを分けることで、使い回しできない部分(ビジネスロジック)を変更するだけで良くなる。使い回しできる部分(uiコンポーネントなど)を見なくても良くなる。
  • uiコンポーネントは使い回すコンポーネントなので、システム固有の処理(ビジネスロジック)を入れるのは、ビジネスロジックを分けれてないので良くない。変更に弱いコンポーネントになってしまう。
  • docker-for-macはどういう仕組みでコンテナを動かしているのかをもっと知りたい。
  • インフラ(AWS, Docker)とかwebpackのエラーが出ると太刀打ちできないのでどうにかしたい。

所感

昼飯を食べる時間(13時)を固定して食べた後に15分寝ることで、午後のパフォーマンスが良くなった気がします。眠くなったり、人のキーボード音が気になったりしなくなりました。やっぱり睡眠は大事。

 

以上です。6/27からの5日間も頑張ってきます!

DAY9(2022 6/13) ~ DAY13(2022 6/17)

今週の目標

仕事をこなしているとあっという間に1週間が過ぎるので、1週間ごとに目標を作ることにしました。
f:id:yukiHaga:20220620090445j:image
■やると決めたこと

  • 7時間絶対寝る(0時〜7時)。できるだけ早く寝て朝勉強する
  • 7時30から8:00まで30分勉強する。この時間は極限まで増やす
  • 20時には絶対帰る。頭回っていないのに仕事してもあまり意味ないので
  • 今週の終わりまでに「Webを支える技術」を読み終える
  • 水曜日に洗濯をする
  • 朝はドーナツ、昼はパンを食う
  • 夜のうちに朝着る服とハンカチを用意する
  • 平日も土日も1日のやることが全て終わってから家のPCを見る
  • 土曜日の朝に15分だけツイッターを見る。ネタがあるなら何かしら投稿する
  • 土日は自分がやる必要があると思うことに、時間を投資する
  • Discordは自分のやることが全部終わったら見る。重要な話をしているときは優先して見る
  • 朝に重めのタスクをやる。頭が回転するので

■やらないと決めたこと

  • マターモスト(週一だけ見る)

DAY9(2022 6/13)

  • オーバーレイを追加した。めんどくさそうだったが、ライブラリですぐ実装できた。
  • 画像が取得できる機能を作成した。5時間くらいかかったけど何とか行けた。

 

DAY10(2022 6/14)

  • 画像が取得できる機能のレビュー修正をした。
  • レイアウトの背景が変わるように修正した。

 

DAY11(2022 6/15)

  • 処理が成功すると、画面に非同期で反映させるような機能を作成した。5時間くらいで行けた気がする。
  • 昨日のレイアウトの背景が変わるような機能を、別の実装方法で実装した。

DAY12(2022 6/16)

  • プルリクのレビュー修正をしていた。
  • 削除機能を50%くらい作った。
  • ログインしているユーザーが特定のコンテンツしか見れないように設定した。

 

DAY13(2022 6/17)

  • ユーザーがあるものを作成していない場合、外部公開できないような機能を作成した。
  • 条件によって、ユーザーがあるものを削除できないような機能を作成した。
  • 20%くらいレイアウトを整えた。

 

開発における気づき

  • react-railsだと初期レンダリング時にAPI通信でデータを取ってくる必要がない。
  • 稼働時間に見合ったアウトプットを出す。
  • optional: trueは、子モデルの外部キーidがnilでもバリデーションを通すオプション。
  • まとめてできることはまとめてやったほうがタスクの遂行スピードが早くなる。
  • 7時間睡眠をとると頭の回転が速くなる。
  • タスクがレビュー中もしくは聞かないと分からないけど聞けない状況でそのタスクを進行できない場合、別のタスク並行すると全体の終わるスピードが早くなる。
  • この時間には絶対帰るって時間を決めると、日中を集中して過ごそうって意識が湧く。
  • 何でもいいから、失敗してもいいから、発言すると当事者意識が湧く。
  • 探すことに脳のリソースを使わない。
  • 文字を追うのに時間がかかるなら、アイコンを見て判断する。(ビューファイルはアイコンで探したり、コントローラディレクトリの下にモデルがあったり、ディレクトリ構成覚えるとファイル探すスピードがさらに上がる)
  • 目が疲れてきたり、情報が追えなくて頭が回っていないと感じたら、瞬きをしたり、伸びをしたり、休憩を取ったりする。
  • どんなに小さな作業でも何時から何時までやるかを事前に決める。その作業中は決めた時間を意識して集中する。
  • sessionStorageとlocationを使って初めて開発をした。URLに関することならlocationを使った方が良い。
  • レビューのファイル修正するときは、ファイル名と行番号を見てすぐ検索をかける。
  • 何かを消すときは、それに関連して他に消すものがないかチェックする。
  • 名が体を成すようにする。実態に即した名前をアクションやエンドポイントにつける。
  • 一つのアクションでhtml やらJSONを返すなら、respond_toを使う。
  • 入力が何で出力が何かを事前に考えておいて知っておくと、スムーズに開発できる。
  • マルチテナントとは、SaaSASPサービスなどのように、同一のシステムやサービスを無関係な複数のユーザー(企業や個人)で共有するモデルを指す。マルチテナントを実現するようなgemもある。
  • 何が分かっていないのかを言語して説明できてない。もっと分かりやすく説明する。
  • 分割代入のインポートで最後にインポートしたものに,をつけないと、インポートするものを追加したときにコード変更差分が2行で出る。だからつけている。
  • プルリクでコミットした後にコミットidをコピーするのがめんどくさい。
  • タスクに取り掛かるときは、タスクのレポート→ 分からないことが何かを分かるためにまとめる → 分からないことを調査 → ループ → 解決策 or 実装方針を2〜3個考える → 実装。
  • 何かをやるためには、絶対にやらないことを決めることのほうが重要。フェーズによって変わるかもしれないが。
  • エラーでめんどくせーって感情的になる前に、客観的に自分が誰かに教える感じでエラーを紐解くと冷静に解決できる。
  • やりたくないことは過程を一つ追加する。やりたいことは過程を限りなく少なくする
  • 基本シングルタスクでやる。何かをやりながら何かをやるみたいなことは絶対しない
  • マックのファンの音とかキーボードの音とかうるさいと感じたとき、全く集中してないことに気づいた。対応策は未定。
  • コードレビューは答え合わせ。
  • なぜこの方法を思いついたのかを自分の中にストックしていく。数学と同じ。
  • 外に知り合いを作るのは大事。
  • 数をこなすとこういうことができるはずじゃね?ってのが思いつく。
  • もっと楽をしようってマインドがあると調べたりする。

所感

睡眠時間を7時間にしたことで、無意識にボーッとする時間が減ったような気がします。頭の回転も速くなった気がします。あと、帰る時間を早めたことでインプットの時間や寝る時間を増やすことができました。

今週から1週間の目標を作ったが、今後も継続したい。社会人やってるとどうしても成長している実感が湧きづらいので。

 

まだまだ、自分の開発スピードが遅いと感じるので、自分が想像している時間より早く実装できるようになりたい、、経験だったり数をこなすのが良いらしい。言語や技術、実装に対する理解も深めていきたい。

 

以上です。6/20からの5日間も頑張ってきます!

DAY4(2022 6/6) ~ DAY8(2022 6/10)

モニタースタンド


DAY4(2022 6/6)

  • ある機能Bの作成をした。作成する中でgemのエラーが発生したので、解決するのにすごい時間がかかった。Railsのエラーの中でインフラ関連のエラーやgem関連のエラーは解決に時間がかかるので、どうにかしたい。よく使うgemは、徹底的に使いこなせるようになるべきだと感じた。

  • ある機能Bのレビューまで完了した。

  • 30分集中して仕事するを繰り返すのが良いと、何かの本で読んだので、この日以降、実行してみた。気持ち集中力が上がった気がする。

  • 大きいタスクを渡されると、色々やらないといけなくて、テンパって結果的に全然進まないことがある。何をすれば良いか分からない感じ。なので、タスクをめっちゃ小さく分解して、小さいタスクを集中して順番にこなすようにした。

DAY5(2022 6/7)

  • ある機能Cの作成をした。50%くらい完成した。いつからか分からないが、機能作成する場合、まずは既存の似たような実装のコードを見たり、Qiitaを検索して見ていた。良さそうな実装があったらコピーして値を変えたりしていた。自分のやり方をCEOに話すと、「まずは何も見ないで自分で考えて実装してみた方が、エンジニアとして成長するよ。今のやり方だと、新しい機能を作る時に作れなくなる。いくらでも失敗して良いし、会社の経営は考えなくて良いから、自分のスキルを磨いてほしい。」と助言をいただきました。なので、この日以降、フルスクラッチで実装しようと決心する。本当に分からなかったら質問するようにする。(ある程度できるようになったら、既存の実装の汎用的なコンポーネントを使ったりすることにした)。まずは実装方針をノートに書くようにした。

DAY6(2022 6/8)

  • 引き続き機能Cの実装をする。フルスクラッチで実装したことによって、自分が思っている以上にReact Hook FormやMUI等のライブラリの使い方が分かっていないことを知る。なので、この日はひたすらドキュメントを読んでいた。

  • 投資していただいているVCの新入社員向けの交流会に行った。自分と同じように未経験からエンジニアになった方がいた。親近感が沸いたので、気づいたらその人とラーメンを食べに行く約束をしていた笑。会社が3人しかいないので、このような横のつながりを提供していただいてすごい嬉しいです。

DAY7(2022 6/9)

  • 引き続き機能Cの実装をする。前日にドキュメントを読みまくったおかげで、スラスラとコードを書くことができた。この日で80%くらい完了した。

  • 入社祝いとして、CTOからモニタースタンドをいただきました。すごい見やすくなって、姿勢も良くなり嬉しかったです。

DAY8(2022 6/10)

  • 機能Cの実装がようやく完了する。完了したときは、めちゃくちゃ嬉しかった。レビューを受けたので、レビューを修正した。来週の月曜にレビューを再度頂くかもしれない。

  • clipyのスニペット機能を知る。今までなんで使ってなかったんだろうってレベルの機能だった。早速色々登録した。

  • ホットコーナー機能を知る。今までなんで使ってなかったんだろうってレベルの機能だった。早速色々登録した。

開発における気づき

  • ファイルを探す時間を極限まで減らす。ファイル探すときはcommand + f、command + p、command + shift + fを使う。

  • フロントエンドでサーバー側にアクセスする場合、最終的には値が返ってくるので、どんな値が返ってくるのか、どのurlやhttpメソッドでリクエストを投げるのかを事前に知っておく。

  • このコンポーネントはどのファイルで、どのディレクトリにいるのかを瞬時に言えるようにする。

  • 考えがまとまらないなら、今何が分かっていないのかを分かるようにする(無知の知)。

  • TypeScriptのエラーなら、〇〇 TypeScriptで調べる。

  • ネットワークタブのレスポンスタブでレスポンスボディが見れる。type xhrはAjaxリクエスト、head :okがサーバー側から返されたらレスポンスボディはない。

  • ディレクトリはABC順になっているので、直接ファイルを探す場合はそれを意識する。脳に疲労をかけないで、サクッと探せるようになる。

  • プルリクやコミットの粒度に気をつける。プルリクが大きいと見る人が大変なので、自分のタスクとかけ離れている内容は別のタスクとして切り分ける。

  • clipyのスニペット機能がすごい。アクセスできるまでの時間を極限まで減らすと、すごいストレスフリーになると感じた。すごい。

  • 開発するときはまずは自分で方針を考える。ネットなどの既存の実装に囚われすぎない。自分で考えて実装する。

  • サステナブルな開発をしたいので、開発が便利になるツールやガジェット、時短アイテムには積極的に投資するようにした。あとは体が資本なので健康を意識する。睡眠を最低でも6~7時間とり、運動もする。ある程度お金に余裕が出てきたら野菜と魚中心の食生活にする。

  • 開発スピード上げたいなら、言語やフレームワーク、ライブラリを自分の中で枯れるまで使いこなす。

  • 30分間隔で集中する。大きいタスクを小さいタスクに分解してノートに書いたり、コードを書く前にまずは方針をノートに書く。

  • コピーは絶対command + cでやる。GUI操作だと遅い。

  • GUI操作で遅くならないようにするために、GUIを画面から消す。

  • ホームポジションから極力手を離さないことで、作業効率を倍増させることができる。

  • ブランチで作業中の時、別のブランチに移動しないといけなくなったら、スタッシュをしてから移動する。

  • 最新のメインブランチにリベースするなら、メインブランチの最新の状態をプルしてきてからリベースする。

来週の月曜にやること

  • ローム拡張機能を社内PCに導入する ( Holmesのショートカットキーをcommnad + shift + kに変更しておく。よく見るサイトだけをブックマークする)。

  • Dockを非表示にする。

  • メソッドジャンプを導入する

所感

何も見ずに開発したことによって、「なんでこの方法で実装すべきなのか?他の方法でも実装できる。」「このライブラリの他の使い方はないのか?」等を考えたり、CTOと相談することができました。人のコードを参照していただけだと、ここまで深い階層の話はできなかったし、自分で方針を考えて作る力も培われないので、本当にやって良かったです。機能作成にベストプラクティスはあっても正解はないと思うので、自分で方針を考えて実装する力をもっとつけたい、、新しい方針を自分で考えるためには、もっと根底の知識を身につけるべきだと感じました(web技術、ネットワーク、プロトコルLinuxApi等)。
あと、コードを書いていると気づいたら1日が終わっているので、1時間あたりの生産性をもっと高めたいです。コードを書く時間が長いせいで、アウトプット比重になっているので、インプットできる時間も取り入れたい、、まずは言語やフレームワーク、ライブラリの理解、ツールやショートカットキーの習得を通して生産性を上げようと思います。実装力や方針を考える力は経験によって培われると思うので、どんどん失敗してチャレンジしていこうと思います。

以上です。
6/11からの5日間も頑張ってきます!