3年目プログラマが参考にしたQiita記事まとめ①

概要

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

Qiitaまとめシリーズ

翻訳: WebAPI 設計のベストプラクティス

WebAPI、というかRestFulAPIに関するベストプラクティスをまとめた記事を日本語訳した記事。

RestFulの基本的な説明から、具体的な設計方法までわかりやすく解説されている。

個人的には「ページング情報はレスポンスヘッダに入れよう」の項が一番参考になり、その後実務でもSPAでのページング処理を実装する際に大いに役立った。

「WebAPI 設計のベストプラクティス」に対する所感

題の通り、一つ目の記事に関する捕捉記事。両記事に目を通すとよく分かるが、WebAPIの設計に絶対の正解は無い。どのような設計が最もRestFul的で、ユーザビリティに富んでいるかは、やはりその時々で違ってくるので、色々なパターンを抑えて最良の選択をできるようにしたい。

うまくメソッド名を付けるための参考情報

基本的にプログラミングは英語で行う必要があるので、英語が苦手な人にとっては特に苦労する命名作業。頻出単語と、その単語を含んだメソッドがどんな動きをするのかのルールを抑えておくだけで、コードを書くときにも読むときにも役立つ。
最近でも、命名に迷った時は軽くこの記事に目を通すようにし、この記事を見ても適切な名前が浮かばない場合はそもそも設計に誤りがあると考えるようにしている。(適切な名前を付けられないロジックは、複数の責務が混在してる可能性が高いため)

ベアプログラミングが無理ならサイレントベアプログラミングを検討しよう

(サイレント)ペアプログラミングではなく、(サイレント)ベアプログラミング。

サイレントベアプログラミングは記事内での造語だが、ベアプログラミングは昔からある手法で、「解らないことをクマのぬいぐるみに相談すると、自然と自己解決できる」というもの。もちろんクマのぬいぐるみが解決してくれるわけではなく、質問するためにまず問題点を整理するプロセスが重要ということ。記事内でのベアプログラミングは、ぬいぐるみ相手に話しかける必要があるので職場などで行うには難易度が少々高い。そのための代替案がベアプログラミングだ。

一通り記事を読んで思ったが、これプログラマなら誰しも多かれ少なかれ脳内ではやっているのでは‥‥?

ターミナル 作業効率化 tips集

ターミナルでキー入力する際のTips集。常日頃からCUI上で開発を行っていると、コマンド入力を頻繁に、それこそ息をするように行う必要があるので、こういった小さなTipsの積み重ねが生産性に大きく影響する。

ちなみに私はMacの標準ターミナルでなく、iTerm2を使っているが、基本的に記事内のTipsの多くはどのツールでも共通だったりするので問題は無い。

新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則

この手の記事はだいたいリーダブルコードを読むだけで済む話だが、一冊丸々読まずともこの記事の内容を押さえているだけでかなり変わると思う。

新人プログラマ向けと言ってるが、正直プログラミングを始めたばかりの人にこれを求めるのは少々酷かもしれない。とは言っても早い段階からこういった考えを持たせたほうが、余計なクセが付かずに済むので、遅すぎず早すぎないタイミングで学べると良さそう。

何かのときにすっと出したい、プログラミングに関する法則・原則一覧

DRYとかKISSとか驚き最小の原則とかそういったものの紹介記事。こういうのを頭に入れておいて、かつ言葉もセットで覚えておくと、コードレビューがスマートに行えそう。

個人的にはボーイスカウトの規則が好きで、日々実践をしているのだが、テストが整備されていないコードに対して行うのは勇気がいるので単体テストぐらいは整備されてて欲しい。

あきらめるにはまだ早い!ソースコードの品質向上に効果的なアプローチ

組織内のコード品質を高めるための手段まとめ。あまり即時性のあるものではなく、こういった仕組みを組織内に導入すれば、長い目で見て確実にコード品質が高まり、生産性の向上に繋がるといった感じ。
なかなか簡単に実行できることじゃないものが多いが、できそうなことから少しずつ手を出せるようにしたい。

コードレビューの極意。それは「自分のことは棚に上げる」こと!!

題の通り。これはコードレビューに関わらず、何かに対してダメ出しをする時の原則だと思う。
自分もできてないけど、そうした方が良いと思うから他の人にそれを要求するようにすれば、自然と自分もそれに従って出来る様になるのでは。

データサイエンティストを目指して半年で学んだことまとめ

軽い気持ちで機械学習に手を出してて苦労してるところで非常に参考になった。

プログラミング、フレームワークの力で、機械学習ができるのは事実ですが、作ったモデルや予測結果の説明ができなければ価値がありません。

が特に心に響いた。極端に言えば、機械学習は魔法のようなモノとまで認識していたようだ。

モデルの精度を上げるために、「とりあえず、Deep Learningで!」や「分類問題を解くならSVM!」等、アプローチだけに気をとられていると、すぐに精度があがらなくなります。勿論、納得できる良い精度は出ません。

そして早い段階でこれにぶち当たった。精度が出ない。何故?何も知らないから。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です