概要

特にカテゴリもレベルも偏らずにざっくばらんに、参考になったQiita記事を一言添えて列挙するシリーズ4本目

Qiitaまとめシリーズ

• 4年目プログラマが参考にしたQiita記事まとめ⑱
• 3年目プログラマが参考にしたQiita記事まとめ⑰
• 3年目プログラマが参考にしたQiita記事まとめ⑯
• 3年目プログラマが参考にしたQiita記事まとめ⑮
• 3年目プログラマが参考にしたQiita記事まとめ⑭
• 3年目プログラマが参考にしたQiita記事まとめ⑬
• 3年目プログラマが参考にしたQiita記事まとめ⑫
• 3年目プログラマが参考にしたQiita記事まとめ⑪
• 3年目プログラマが参考にしたQiita記事まとめ⑩
• 3年目プログラマが参考にしたQiita記事まとめ⑨

【フロントエンドエンジニアだからこそ】プロトコルも理解して最適なコーディングしよう

HTTPなんて今更‥‥。と軽い気持ちで開いたらHTTP/2に関する丁寧でわかりやすい説明が書かれていて参考になった。まだHTTP/2を実用的に使ったことはないけど、HTTP/1.1の弱点は日々感じているのでどこかのタイミングで使ってみたい。もしかすると仕事の中で気づかないうちに使ってたりするのかな？

thisを書く派？書かない派？

特定の言語に限った話じゃないけど、こういう省略できる接頭語を書くか書かないかってのは結構わかれるのかな？個人的にはほぼ間違いなくthisは付けるし、むしろ付けなくても見逃してくれる処理系の方が疑わしいとさえ思う。スコープを抽象化するみたいなメリットが挙げられてるけど、それメリットなのかな。抽象化すべき部分でない気がする。

技術系の名言まとめ++

この手の記事を見ると一瞬凄まじいやる気になる。でもそのやる気は一過性のものでスグに移り変わってゆくので、やる気があるその一瞬のうちに何らかのアウトプットを出して、またやる気を出してを繰り返して成長したい。

技術的負債とどうやって戦うか

技術的負債に関する記事はQiitaでよく見かけるが、個人的にはこれが一番参考になった。技術的負債を溜めることにどんな問題があるのか、これはエンジニアじゃないとわからない問題なのに、負債を返済するチャンスを得るには非エンジニアに説明しなければならなかったりする。まぁ日頃から負債を生まないような開発を心がければいいんだろうけどなかなかそうも行かない。

【翻訳】あまり知られてないけど便利なRubyのメソッド7選

どれも知って入るんだけど上手く使いこなせた試しは殆どない。知ってるだけで使いこなせないのは知らないのと一緒だ。個々のメソッドの性質を捉えて、ここぞという時に使えるようにしたい

AWS初心者がインフラ設計/構築を理解するために、まず最初におさえるべき専門用語 15選

こういう、初心者が自ら学びながらまとめた記事というのは、上級者が知見を整理した記事よりもスンナリ入ってくることが多い。視点の違いだろうか。上級者になると、初級者の目線が見えなくなって、わかりやすく書いているつもりでも暗黙知を含んでしまいそう。といっても、初心者の記事には誤りが含まれてる可能性も多分に含まれているので、情報の真偽を確認する必要もある。

モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう

名詞形と形容詞系の区別がついてない命名をたまに見かけるし、自分でもやらかしてしまうことがある。多分適当に単語でググったり、機械翻訳にぶん投げた結果をそのまま使ってるからだと思う。ちゃんと辞書なりで品詞を確認して、的確に使い分けるようにしよう。

&演算子と、procと、Object#method について理解しなおす

Rubyのこの辺、普通に開発やってるとほぼ使わないなぁ。いや使ったほうが効果的だったりはするんだろうけど、理解してない人の方が多いであろうテクニックを使うと相対的な可読性が落ちてしまいそう。変にテクニックに走るよりは多少効率落としてでも読みやすいコードを書いたほうがいいのかな。

Qiitaをズァーって感じで広く見るアプリ

TweetDeckのQiita版みたいな感じかな。オシャレなUIで使い勝手良さそう。でもQiitaは玉石混交だからあんまり新着を追うってことは無いから、このままだと使い道ないかなぁ。

Linux | source コマンドは何をしているのか > 実は環境をリロードするためのものではない

確かに、更新したbashrcを適用するためのコマンドぐらいの認識しか無かった。でも記事読んだ限り、どのへんが”source”コマンドなのかよくわからなかった。もっと良い名前あったんじゃないかな。