概要
特にカテゴリもレベルも偏らずにざっくばらんに、参考になったQiita記事を一言添えて列挙するシリーズ18本目。
今回からタイトルを「4年目」に致しますが、ナンバリングは継続とします。
Qiitaまとめシリーズ
- 4年目プログラマが参考にしたQiita記事まとめ⑱
- 3年目プログラマが参考にしたQiita記事まとめ⑰
- 3年目プログラマが参考にしたQiita記事まとめ⑯
- 3年目プログラマが参考にしたQiita記事まとめ⑮
- 3年目プログラマが参考にしたQiita記事まとめ⑭
- 3年目プログラマが参考にしたQiita記事まとめ⑬
- 3年目プログラマが参考にしたQiita記事まとめ⑫
- 3年目プログラマが参考にしたQiita記事まとめ⑪
- 3年目プログラマが参考にしたQiita記事まとめ⑩
- 3年目プログラマが参考にしたQiita記事まとめ⑨
目次
機械学習案件を料理に例えると分かりやすい件
依然、記事の内容に例えて言うなら、「肉っぽい何かと赤みのある野菜とよくわからない粉とか使って、いい感じのビーフシチュー的な料理を作って」という東郷平八郎でも躊躇うような注文状態に対して肉じゃがを提供できたら大満足ぐらいな状態になった。
と言っても、自分含めてノウハウがまとまってない環境なので誰が悪いというわけでなく、試行錯誤して頑張って、後は煮るなり焼くなりどうにか「料理」と呼べるほぼ物体Xが出来たのでファーストステップとしてはありだと思ったけど。
僕とVimの1年間
一年で成長しすぎじゃないですかね‥‥。もう三年ぐらいvimしか使ってない(xcodeは除く)のに、未だにIDE的な使い方はできてなくてシンプルなvimでチマチマ作業してる。もっと根本的な解決図りたいけど、いざvimをそこまで拡張すると、「vimであり必要
なくね?」となりそう。
デザイナーとアプリエンジニアが仲良く開発できるためのチートシートを作る
記事はネイティブの話だけど、ネイティブに限らず、「開発用語を統一する」というのは大事。理想はちゃんとwikiなりに辞書をまとめて、定義されたワード以外の曖昧な言い回しとかは一切禁止にしたほうが余計な誤解とか招かずに済むはず。あとからプロジェクトに参入した人がログやソースコード追ったりするときも楽になるし。
Laravel初心者から毛を生やす
Laravelに限らずRailsとかでも、フレームワークをちょっとやってそれっぽくアプリケーションを開発できるようになるとそこで満足してしまうことが多い。フレームワークが持ってる機能はそんなちょっとやったぐらいで全て抑えられるものじゃないので、常によりより実装方法をフレームワークが提供していないかを意識して、良いコードを書く習慣を付けたい。
範囲式を使ったフリップフロップ
Rubyのフリップフロップ式の使い方。この記事見るまでRubyでそんなこと出来るの知らなかったが、こんなトリッキーなコードを使うときが来るのだろうか。よほど限定的な状況じゃないと大した可読性も得られずレビュー通らなそう。でもプログラマとしてはここぞという場面で使いたい欲が高まってくる。
学習を加速させるインデックス読書術
読書なんてのは「15分読んで合わなそうなら捨てる」ぐらいの気持ちでガンガン当たったほうが良い。全部読まなきゃならないなんて圧力を自らにかけて視野を狭めるようなことはもうしたくない。
やはりお前らの真偽値メソッド名は間違っている。 〜「Xxx できる?」系メソッドの命名〜
True/Falseを戻すメソッド名の先頭にisを付けたい気持ちはよくわかる。(Rubyだと末尾に’?’を付けられるのでそうはならないが)
英単語のチョイスはどうにかなっても、品詞を使い分けで失敗する問題が現場でもよくある。allow/allows/allowedぐらいの使い分けは社会人としてやってできてほしいけど。
品詞の使い分けで失敗するの何でかって、それっぽい日本語で機械翻訳かけて出たのをそのまま使うケースが自分含め多いからなんだよね。機械翻訳使うなら、日本語側も品詞を意識して、それに応じた翻訳結果が出るかを意識する必要がある。Google翻訳と比べるとcodicはその辺よく出来てると思うけど。
新卒エンジニアのお節介
こういうFRESHな視点を忘れないようにしたい。いや新人でここまで考えられたら最初から戦力になると思うぐらいしっかりしてるけど。
超高速な静的Webページを作ろう!
保守性と機能性を無視した極端な例だけど、阿部寛タイプはこのぐらい突き詰めたほうがいいかも。以下あたりのノウハウは一般的なWebアプリケーションでも活用できそう。
- CDNで配信する
- 画像は可能な限りSVCを用いる
- そもそも画像を減らす、縮める、base64で1ファイルに束ねる
- 圧縮して配信する
強いエンジニアにHelloWorldさせてみた(縛りあり)
パワフルな力技実装から、トンチがきいた回答、言語仕様を巧みに利用したテクニカルな回答と、色々あって面白い。単純に数値を数値以外で表現できるならASCII使ってどうにでも出来ると思ったけど、色々な回答があるからいくつかチェックしよう。
※ 回答11が何故そうなるのかさっぱりだったので検証してみた。
解答
console.log(((![]+[])[+!![] + +!![]]+([][+!![]]+[])[+!![] + +!![] + +!![] + +!![] + +!![]]+([][+[]]+[])[+!![] + +!![] + +!![] + +!![]]+([][+[]]+[])[+[]]+(![]+[])[+!![] + +!![]]+(![]+[])[+!![] + +!![]]).toUpperCase()); VM1624:1 LIFULL
まず、空配列の否定は文字列になる
![] false
配列の和は文字列結合になる。これ意外。
[1,2,3] + [4,5,6] "1,2,34,5,6"
よってこれで文字列のfalseが取れる
![] + [] "false"
空配列を反転してさらに反転すると真偽になる(true)
それを数値に変換すると1。これで数値が取れるようになる
+!![] 1
よってこれで2が取れる
+!![] + +!![] 2
これで”false”の3文字目である”l”を抜き出せる。一気に解答に近づいてきた。
(![]+[])[+!![] + +!![]] "l"
配列の範囲外を取得するとundefinedが取れる
([][+!![]]+[]) "undefined"
なんと”undefined”には、先程取得した”l”以外のLIFULLを構成するアルファベットを全て含んでる。
なのでこれまで同様の手法で文字を抜いてく
a = (![]+[])[+!![] + +!![]]+([][+!![]]+[])[+!![] + +!![] + +!![] + +!![] + +!![]]+([][+[]]+[])[+!![] + +!![] + +!![] + +!![]]+([][+[]]+[])[+[]]+(![]+[])[+!![] + +!![]]+(![]+[])[+!![] + +!![]] "lifull"
最後に大文字に変換
a.toUpperCase() "LIFULL"
ASCIIを使わずとも、false/undefinedから文字列を抜くのが目からウロコ。さらに配列のindexを数値を使わずに得るために空配列を巧みに使ってる所もスゴイ。