プログラミング初心者の時こそ最低限の英語の素養が大事だなと思った話

エンジニアとして英語の素養が重要なのは言わずもがな。

でもプログラミング初心者の時こそ英語の素養が活きてくるなーと思ったという話。

ここ数ヶ月新人教育やMENTAでメンターをやっていて

『言葉から実際の処理をイメージできるかどうかで理解度がだいぶ変わる』

 というのを実感している。

「原理はまだちゃんとはわかってないけど、 『○○そう』とか『○○ぽい』というイメージができる」って実はかなり重要なんじゃないかな。

パッと思いつく例を書いてみた。

• redirect_to
• re・・・再び → 何か繰り返してそう
• direct・・・指図する、道を教える → 何か道しるべっぽい
• render
• 描画する → 何かに絵を書いてそう
• template, partial
• template・・・雛形 → 何かの雛形になってそう
• partial・・・部分的な → 全体のうちの一部そう
• asc, desc
• asc・・・ascendantの略 → だんだん上がっていきそう
• desc・・・descendentの略 → だんだん下がっていきそう
• include
• 含む → 何かを含有してそう
• seed
• 種 → 何かの初期値っぽい
• validate
• 検証する → 何かを検証してそう
• presence, present
• 存在する → 存在してるかどうかが何かに関係してそう
• through(has_many, thorugh)
• 経由 → 何かを経由してそう
• belongs_to
• 所属する → 何かに所属・依存してそう
• request, response
• request・・・依頼 → 何かをお願いしてそう
• resposne・・・反応 → 依頼に対して何か反応してそう
• credentials
• 証明書 → 何かセキュリティに関係ありそう
• routes（ルーティング）
• 道筋 → 何かが通る道っぽい

英語が特別得意な訳ではないので説得力はないけど、大学受験時、単語の「イメージ」が付くようになってから少し英語がわかるようになったと感じてる。

わからないものに対してはまずは「イメージ」するところから入るのがいいんじゃないかな。

英語だろうが中国語だろうがプログラミング言語だろうがそれは同じなのかなーと思った。

そしてプログラミング言語は英語から成り立ってるので英語の素養は重要という。

イメージができないと理解が進まない。

理解が進まないと挫折しがち。

だからプログラミング初心者の時こそ英語の素養は大事だなと思った今日この頃でした。

超速！ Webページ速度改善ガイド 第三章

引き続きこちらの本を読んでます。

第一章、第二章はそれぞれこちら。

daidai3110.hatenablog.jp

daidai3110.hatenablog.jp

第3章 ネットワーク処理の調査と改善

3.1 サイズの大きいリソースの調査と改善

• 当たり前っちゃ当たり前だが、サイトが遅い原因の一つ。
• NetworkパネルのSizeカラムをクリックして降順で並び替えるとよい。
• ダウンロードに時間がかかっているリソースはtotal duration
• 適切な最小化が行われていないテキストリソースに対してはgZip圧縮しろ

• gzip以外にもgunzip、zopfli、brotliなどがある。

引用 超速！ Webページ速度改善ガイド 第三章

JavaScriptの圧縮に関して、webpackであればCodeSplittingという機能を使えばビルドするファイルを分割できる。

3.2待機時間が長いリクエストの調査と改善

TTFBを確認すべし。

TTFB（Time To First Byte）とは、ブラウザがWebサーバーにリクエストを送信してから、Webサーバーが最初の1バイトの応答をブラウザに返すまでの時間のこと。

• リソースへの事前接続

非表示の<img>要素を入れて事前リクエストを送るとか。結構力技だな…

他にはResourceHintsという仕様の策定が進められているらしい

• キャッシュによるリクエスト結果の再利用

Web StorageとかIndexedDBに保存しておく。

ETagやCache-Controlを適切に設定すべし。

Etagってのはリソース自体は返さないから送信コストが抑えられるぽい

CacheAPIとやらもあるらしい。ServiceWorkerを利用するらしい。

• CDNからの配信

通信経路の問題を解決

3.3 リクエスト数の調査と改善

• 不必要なリクエストの削減
• 画像の遅延読み込み
• 静的リソースの結合

ただし結合するとフィイルサイズがでかくなるので、なんでもかんでも結合すればいいというわけではない。

【参考】

引用 超速！ Webページ速度改善ガイド 第三章

• SVGスプライトとCSSスプライト

簡単にいうと、複数の画像を一個にまとめて必要なものだけ参照できる？→リクエスト数の削減？

3.4 クリティカルレンダリングパスの調査と改善

スクリプト処理によるブロッキング

スクリプト処理実行時にはDOM構築がブロッキングされる

逆にCSS読み込み時はスクリプトがブロックされる

ファイルのダウンロード後からDomContentLoadedまで時間がかかってる場合はスクリプトの実行によって遅延が発生してるかも。

スタイリングされずに表示されるコンテンツ

FOUG（Flash of Unstyled Content スタイルが適用されていないコンテンツが表示されること）はできるだけ避けるべし。

DomContentLoadedイベントより前に読み込んでいるJSがあったらDOMツリーの構築をブロッキングしている可能性が高い。FOUGの原因。遅延読み込みが可能ならそうしたほうがいい。

コンテンツに影響しないスクリプトの非同期実行

<script async>・・・DL完了後スクリプト実行までする

<script defer>・・・DL完了後スクリプト実行はDOMツリー構築まで。（つまりDOMツリー構築のブロッキングをしない）

引用 超速！ Webページ速度改善ガイド 第三章

3.5 Webフォントに関わるリソース調査と改善

Webフォントのファイルサイズが大きければそれだけ表示に時間がかかる。

• Webフォントは
• 圧縮すべし
• キャッシュすべし
• サブセット化すべし

Font Loading APIを使えばJavaScriptにより任意のタイミングでWebフォントのリクエストを行える。ちらつきを抑えるために有効な場合がある。

font-displayというプロパティも仕様策定中らしい。

引用 超速！ Webページ速度改善ガイド 第三章

超速！ Webページ速度改善ガイド 第二章

引き続きこちらの本を読んでます。

第1章はこちら。

今回は第二章。

2.1ページロードの速度を左右するネットワーク処理

ページロード時間の理想は1秒以内

→ ただ全ての処理を1秒以内に収めるのは非常に困難

ネットワーク処理に影響を与える要素

• リソースの大きさ
• HTTPリクエストの数
• ネットワークの通信距離

ネットワーク処理の流れ

1. DNS解決
2. TCP接続
3. HTTPリクエスト

HTTP/2によるネットワーク処理の効率化

• HTTPリクエストとレスポンスのやりとりを多重化・並列化
• HPACKによるヘッダ圧縮
• 取得リソースの優先順位
• サーバプッシュによる高度なリソース配信

＊一応HTTP/1でもTCPコネクションを複数持つことで並列化は実現してたっちゃしてた。

2.2ネットワーク処理の基本

フロントエンドが鍵を握る

ユーザーの待ち時間の大半はブラウザのネットワーク処理

とはいえHTMLを返すのに2~3秒かかってるならそれはサーバサイドの致命的な遅延。論外。

ネットワーク処理最適化の基本3原則

• データの転送量を小さく
• データの転送回数を少なく
• データの転送距離を短く

クリティカルレンダリングパス

• HTMLドキュメントのダウンロードと評価
• サブリソースのダウンロードと評価
• レンダーツリーの構築とレンダリング

＊CSSとJSのロード中はレンダリングブロックされる。断片化したCSSやJSのプラグインをたくさん読み込んでいる時に問題が起きやすいフェーズ

2.3ネットワーク処理の調査と計測

DevToolのNetworkパネルを使うべし

基本的な対策を確認するツール

DevToolsのAuditsパネル

PageSpeed Insights

Webページロード速度のモニタリング

「早すぎる最適化は諸悪の根源」

→定常的にモニタリングできる仕組みづくりが重要。手探りで改修なんてするもんじゃない。

モニタリングの種類

• 合成モニタリング（計測用の仮想環境を作り定期的に計測する）
• リアルユーザモニタリング（Webページに実際にスクリプトをしこんでおく）

モニタリングサービス

• WebPagetest
• SpeedCurve
• New Relic
• Calibre

ブラウザの様々な処理時間を計測するTimingAPI

• UserTiming（任意の場所に設定可能）
• NavigationTiming（リンクをクリックしたタイミングとか）
• ResourceTiming（サブリソース取得時）
• PaintTiming（Webページのレンダリング状況）
• ServerTiming（サーバないで発生した処理時間）

2.4 プロダクトに応じた指標作り 

表示速度に対する間接的な指標

• ページロードに関わるブラウザイベント（DOMContentLoadedとload）
• リクエスト数とファイルサイズ

ただこれらの指標だけだとビジュアルの表示量などユーザ体験に基づく表示速度を捉えきれない。なので次のような指標が生まれた。

ユーザー体験に基づいた表示速度の指標

• First Paint（ページが表示され始めたとき）
• First Contentful Paint（コンテンツが表示され始めたとき）
• First Meaningful Paint（ユーザに意味のある表示になったとき）
• Time To Interactive（ユーザーの操作に応答できるようになったとき）

daidai3110.hatenablog.jp

超速！ Webページ速度改善ガイド 第一章

第1章 Webページの速度

1.1 Webページの速度とは何か

• ページロードの速度--ページが表示されるまでの速度
• ランタイムの速度--ページ上での操作に対するUIの応答速度

1.2 Webページの速度の重要性

ビジネスへの影響（コンバージョン率）

デバイスやネットワークの多様化（モバイルのネットワークは非力）

技術や表現の変化（コンテンツのリッチ化）

1.3 Webフロントエンド高速化ポイント

Webフロントエンドから改善する意義

高速なリソース配信はWebページの速度を高めるために必要だがブラウザによるリソースの取得はWebページを表示するプロセスの中のほんの一部。Webページを表示するプロセスのうち残りの大半を閉めるフロントエンドの観点から改善するアプローチが重要。

サーバサイドがいかにHTMLを速くレスポンスしたとしても、Webフロントエンドに不備があればWebページの速度をすべて台なしにしてしまう。

Webフロントエンドを高速化する3つのポイント

• ネットワーク処理──HTMLドキュメントやサブリソースの取得
• レンダリング処理──ディスプレイへの表示
• スクリプト処理──JavaScriptによる演算やDOM操作

1.4 Webフロントエンド高速化の取り組み肩

推測するな、計測せよ

計測や原因の調査もせずにやみくもにコードを修正するのはよろしくない。ただの当てずっぽうで再現可能なエンジニアリングではないので。

継続的な計測と改善が重要

Webページ速度は色々な要因で遅くなるので日々計測し日々改善することが重要。

開発者の特殊なハイスペック環境

一般ユーザの環境とは違うということを自覚すべし。

目標にすべき速度の具体的基準

エンジニアリングだけでは解決できない問題

速度の問題はエンジニアだけでなくデザイナー、プランナー、マネージャーなど同じプロダクトと向き合うメンバー全員の共通認識とされるべき問題。

Webページの調査に必要なブラウザの開発者ツール

Chromeなどの検証ツール

『MOKUMOKU』をリリースしました

　先日『MOKUMOKU』というサービスをリリースしました。

www.mo-ku-mo-ku.com

一緒にもくもくできる人が見つかるかもしれないサービスです。

リリース告知時のTwitterはこれ。自分の想像以上の反響をもらえて驚きました。

【拡散希望】
気軽にいろんなエンジニアとつながれる『MOKUMOKU』をリリースしました🎉🎉
孤独なエンジニアのつらみを解決するサービスです！
「まぁ一人だったら一人でいいけど、誰かと一緒にもくもくできたらいいなー。」くらいのゆる〜い感じで使ってくれたらと思います！https://t.co/8wOFZAfwdJ

— だいそんさいとう@筋肉エンジニア (@daidai3110) November 22, 2018

なぜつくったか

背景

SIerを退職し知人のスタートアップに参画し始めたばかりのころ、周囲にプログラミングについて聞ける人がほとんどいませんでした。

学ぶのは好きなのでアプリに然りインフラに然りやるべきことが多岐にわたるのは問題ないです。むしろ嬉しいです。

一方で学習効率が悪く時間を浪費している感が自分にとっては堪えられませんでした。

勉強会に参加してみて他のエンジニアさんに聞くと僅か1分で解決するものも自分独りだと丸1日潰れるということも多々ありました。 

他のエンジニアさんが1日でクリアするところを自分は1週間以上もかけている気がしてなりませんでした。

感じた課題

一般的なIT企業に所属されている方からするとあまり感じない課題だとは思いますが、私のような実質エンジニアが一人の会社で働いている人間だったり、今はエンジニアではないがこれからプログラミングを始めていこうと思っている人間からすると『周囲に聞ける人がいない』というのは非常に大きく辛い課題です。

偶然にもこのアプリのもう一人の開発者(@Artefacttw)も自分と同じ埼玉の川越という地方出身で同様の課題を抱えていました。

よくある勉強会プラットフォームでは人数が集まらなかったら中止ということもあり得るので主催側も参加側も多少なりともハードルがあります。また、本当の初心者だと怖くてなかなか参加に踏み切れないということもあるかと思います。さらにいうと地方に住んでいる人にとっては往復の移動だけで疲弊したりもします。

それらの課題を解決しようと思い作ったサービスが『MOKUMOKU』です。

さいごに

Twitterを見る限りこれからエンジニアを目指すという人が以前より多くなってきているように見受けられます。また観測値ですがそういう人たちは独学で学んでいる人が多いように感じます。以前の自分と同じような状況です。

またMENTAでもこういった相談がかなり多いので『独学の限界』に悩んでいる人は一定数いるのでしょう。

現状では調べるのにかなり時間がかかってしまい、1週間近くかかることもありまして…そういったつっかかる部分のヒントやアドバイスがいただければと思いまして！

悩みの一つが独学で詰まることです。自分で調べていて時間をかけても解決しないので、学習が進まず停滞してしまった状態です。

只今ウェブサイトの模写(HTML,CSS )をしているのですが、多々行き詰まる箇所がありますので、メンターが見つかればと思い連絡させて頂きました。

menta.work

もちろん詰まって自分で考えることは重要ですが、必要以上に詰まるのも良くありません。

『MOKUMOKU』がそういった人たちの悩みを解決するサービスになれば嬉しいです。

『駆け出しエンジニア同士が繋がったところで…』という意見もごもっともだと思いますが、それでも独りよりは良いと確信しています。

この手のサービスは一旦過疎ると一気に過疎るのでどうか使ってみてください（笑）そしてフィードバック(@daidai3110)をいただけたらなと思います。

呑んだくれ専用Webサービス『N次会』を作った。

二次会、三次会の店を決める時ってみなさんどうしてます？
簡単にお店を探せるサービスを作って公開しました。使ってみてください！

作ったもの

『N次会』です。呑んだくれの呑んだくれによる呑んだくれのためのサービス。

いたってシンプルで、「現在地付近の店を探す」ボタンを押すと現在地から100メートル以内の店が一覧で出てくるというものです。トップページと検索結果ページの2ページしかありません。

『現在地付近の店を探す』を押す。

100メートル以内の店がずらっと出てくる。

なんで作ったのか

前職時代の話ですが、二次会の店は当時若手だった私が探すことが多く、その作業が結構面倒だったんですね。

私の場合は一次会の終盤にスマホでググった近くの店に片っ端から電話してました。

が、これが結構大変で、二次会・三次会って『近くの店』というのが最低条件なんですが、食べログやらぐるなび等で地域検索しても範囲が広すぎてなかなかほんとに近い店って探せないんです。新宿東口にいるのに西口の店が出てきたり、有楽町にいるのに銀座の店が出てきたり。

そういう経験があったので「なんかもっと簡単に近くの店を探せればな〜」と思って今回のサービスを作りました。

技術要素について

• Ruby on Rails
• Rubyによるスクレイピング
• GeolocationAPI
• Heroku
• MaterializeCSS

こんなシンプルなサービスRailsを使うのは少々オーバースペック感がありますが、位置情報を使った検索が簡単にできるgemがあったのでRailsを採用しました。

なんかもの作るのが一番身になる。

Step-to-Rails-Expert.rb#20に参加しました。

Railsの勉強会に参加しました。

こちらの勉強会です。

step-to-rails-expert-rb.connpass.com

企画について

前回までは、共通の仕様のTodoアプリを作ってきてレビューしあうExpertTodoという企画を行っていましたが、今回からもくもく会ベースになりました。経緯は以下の記事を御覧ください。

http://biibiebisuke.hatenablog.com/entry/2018/05/28/101038

もくもく会と言っても、作業したり興味ある内容を話したり各々好きな時間を過ごして頂けます。 また、ExpertTodoで作っていたアプリ以外のRailsアプリを持ち込んで頂くことも可能となりましたので、今まで参加していなかった方でもお気軽にご参加ください！

もくもく会ベースではありますが、各々関心のあることについて自由に話しながら進めていくという感じですね。

今回の内容

上述の通り、各自やりたいことを進めていくという内容でした。

私は先日Everyday RailsというRspecの本を購入したので、今までこの勉強会で作っていたToDoアプリにテストをつらつらと書いてくことにしました。

leanpub.com

周りは趣味サイトをレベルアップさせる人、Vue.jsを使ってみる人、Active Strorageを使ってみる人、通常業務をやる人、等々各々自由に進めていました。

『もくもくしながら、会話もしつつ、Slackで有益な情報を飛ばす』という並列処理能力が求めらる状況でした笑

当日教えてもらった中で、個人的にはこいつが気になりました。

Rails 5 Test Prescriptions: Build a Healthy Codebase by Noel Rappin | The Pragmatic Bookshelf

テスト全般の本なのですが諸々最新バージョンを使ってるようです。かつWebpackも併用してるみたいで、なんか漠然といけてそうだなぁと思ってます。

ただ、色々手を出す前にとりあえず前述のEveryday Railsをしっかり読んで、それから購入を検討します。

You’ll use Rails 5.2, Minitest 5, and RSpec 3.7, as well as popular testing libraries such as factory_bot and Cucumber. Updates include Rails 5.2 system tests and Webpack integration.

半年間参加してみて

ブログに書くのは今回が初なのですが、実は去年の12月から参加してるのでもう半年になります。

当時はRuby on Rails Tutorialを2週した程度だったのですが、いざ自分でWebアプリを作ろうとしたときに色々詰みました...そこで、『やっぱりすぐ聞ける人がいたらいいなぁ』と思ったのが勉強会に参加しようと思ったきっかけです。

半年間経ってみてどうだったかというと、初心者向けの話から濃い話まで色々聞けてとても良かった。例えばですけどこんな↓（全部挙げてくときりがないので一部だけ。）

• Rspec
• APIサーバ作る時の構成
• ヘルパーの立ち位置
• STIのつらみ
• Rubocop
• bundle install時のpathのお話
• capistrano
• 認可・権限の管理
• マルチテナント問題

RspecやRubocopなんかはRailsエンジニアからすると当たり前だと思いますが、当時の自分にとってはとても有益でした。 

また、うちはエンジニアというエンジニアが自分一人なので実質個人開発みたいな感じです。そんな自分にとって何が嬉しいかというと、

高い水準での開発手法を知れる

→堅牢性だったり保守性だったり、一企業が提供するサービスとしては当然なのでしょうが、その当然を知れる。

レビューをしてもらえる

→正直一人で開発してると暗闇の中を駆け抜けてる感じで辛い。が、自分じゃ気づけないところをレビューで指摘してくれるのはほんと助かる。

半年間参加してきましたが、個人開発してきた自分にとってはずっぽしハマった勉強会だったなと感じてます。

また来月も参加したい。