概要
特にカテゴリもレベルも偏らずにざっくばらんに、参考になったQiita記事を一言添えて列挙するシリーズ10本目
Qiitaまとめシリーズ
- 4年目プログラマが参考にしたQiita記事まとめ⑱
- 3年目プログラマが参考にしたQiita記事まとめ⑰
- 3年目プログラマが参考にしたQiita記事まとめ⑯
- 3年目プログラマが参考にしたQiita記事まとめ⑮
- 3年目プログラマが参考にしたQiita記事まとめ⑭
- 3年目プログラマが参考にしたQiita記事まとめ⑬
- 3年目プログラマが参考にしたQiita記事まとめ⑫
- 3年目プログラマが参考にしたQiita記事まとめ⑪
- 3年目プログラマが参考にしたQiita記事まとめ⑩
- 3年目プログラマが参考にしたQiita記事まとめ⑨
目次
- 1 概要
- 2 Haskellの入門から中級者になるまでの指針
- 3 【便乗記事】エンジニアがデスマーチを生き抜くための知見をまとめてみた
- 4 (ほぼ)世界中の宅配便業者の配達状況を知ることができるAPI
- 5 JavaScriptのシングルクォーテーションとダブルクォーテーション
- 6 VagrantとDockerについて名前しか知らなかったので試した
- 7 ここがすごいぞ! stylelint!
- 8 初心者向け、「上手い」シェルスクリプトの書き方メモ
- 9 のび太と学ぶ「機械学習」~FX予測プログラムを作成~【第1話】if文作戦
- 10 Seleniumしくじり先生 〜E2Eテストの導入で失敗した話〜
- 11 週末在宅ワークの生産性を上げる4つの視点と17の工夫
Haskellの入門から中級者になるまでの指針
既に3回、Haskellに挑戦して挫折してる。(挫折と言うか面倒になって投げ出してる) 関数プログラミングの感覚を身に着けて、副作用のない良いコードを書くためにはHaskellを使うことが近道になることはわかってるんだけど、どうにも純粋関数型言語というのは数学的センスが求められて入門レベルでもついていけなくなる。個人的には今のところ最も難しいプログラミング言語だと思うんだけど、そもそもHaskellや純粋関数型言語に対して誤解してて勝手に敷居上げてるのかも。来年こそ本気出す。
【便乗記事】エンジニアがデスマーチを生き抜くための知見をまとめてみた
まだデスマーチ的なことは行ったこと無いし、もし今後巻き込まれたとしても全ての非難を受け入れつつ緩やかに逃げるつもりでいるから関係ないと思うけど、一応こんな記事があったことは頭の片隅に入れておこう。食事についての記述がガチ過ぎてちょっと笑えた。当事者にとっては笑えないと思うけど。
(ほぼ)世界中の宅配便業者の配達状況を知ることができるAPI
面白そうだったので早速使ってみた。が、使ってみると個人的にはそんなに使う理由がないことに気づいた。よほどじゃない限り配送情報とか気にしないしね。
JavaScriptのシングルクォーテーションとダブルクォーテーション
JSに限らず、RubyでもPHPでも、どっちを使ってもいい状況ならシングルクォーテーションを使う。好みの問題と周りに合わせるかの問題だけど何かシングルクォーテーションのほうがスッキリして見えるし。
VagrantとDockerについて名前しか知らなかったので試した
こういう記事を読むたびに、自分の開発環境としてのDockerの使い方が一般的なのか怪しくなる。全然プロセス実行ツールとしてのDocker利用ができてないからなぁ。まずDockerFileをまともに書いたこともないし、Docker-Composerなんかも全然使ってないから来年はその辺りのノウハウを強化したい。
ここがすごいぞ! stylelint!
eslintのCSS版。eslintは沢山の人が使ってるけどこれはあんまり見ないな。webpackに自然に組み込めるのと、scssもちゃんと対応するのであれば使ったほうが良さそう?
初心者向け、「上手い」シェルスクリプトの書き方メモ
こういうTips記事を定期的に読んで勉強した気になっても、いざシェルスクリプトを書くときは殆ど使わない。多分日頃からシェルスクリプトを書く習慣がないから身につかないんだろうなぁ。最近はDevOpsなんかもあってRubyとかで構成情報記述できるからなおさらシェルスクリプトを書く機会が減ってる気がする。
のび太と学ぶ「機械学習」~FX予測プログラムを作成~【第1話】if文作戦
面白いしわかりやすい。何よりのぶ代ドラが脳内再生される。この記事は某タヌキアニメとは関係ないけど。
Seleniumしくじり先生 〜E2Eテストの導入で失敗した話〜
Seleniumに限らずE2Eテスト全般あるある。特に最近のリッチクライアントなWebサービスだとE2Eはほんと難しい。フロントフレームワークを使うのであればそれ専用のE2Eテストモジュール使わないとまともにできなそう。
週末在宅ワークの生産性を上げる4つの視点と17の工夫
少し古いITエンジニアの勉強時間の時間の調査[1]によると、大半が週に3時間未満というデータがありますが、プログラミング能力を競うサイトの調査[2]では、11%の人が週20時間以上勉強や個人の開発に費やしているようです。
競技プログラミング勢の平均を参考にするのはアレだけど20時間やってるかと言われると微妙だなぁ。平日平均1.5時間ぐらいで休日平均5時間、累計で17.5時間ぐらいだと思う。休日にもう少し避ければ良いんだけど、無駄に長時間寝たり頻繁にカラオケに行ったりしててロスが多いので見直したい。特に惰眠貪るのを。
時間確保のためには、他のことをしていた時間を削らなければなりません。自分の生活の中で、無駄なもの、なくしてもよいものをリストアップして、ひとつずつなくしていきましょう。
まず休日の惰眠。あとは毎日の通勤時間往復3時間弱かなぁ。もう少し上手く時間使えるといいんだけど、ついつい漫画読んだりしてる日が多い。ブログの記事などを書いている際に、統計などを調べ始めると徹底的に調べたくなりますが、結局は最終的な記事に関係ないことが多いため、一定のレベ
ルでさっさと切り上げたほうがよいでしょう。
うっ、頭がっ!スキマ時間のための考え事リスト、作業中断と再開を早くするToDoリストを書き出しておく
これちょっと前に数日ぐらい手書きメモで実行してたけど何か面倒になって三日坊主になっちゃったな。タスクの粒度が余りに小さすぎたのかも。(ex: ペットに餌上げる、風呂掃除する)
週に1日は休む
多分週2,3日は休んでる(作業時間が0)
ある研究によると、困難な問題に本腰を入れてしばらく取り組み、生産性の低下やストレスの低下を感じ始めた後に、切り替えて休憩をしてリラックスをすると、創造的なアイディアや問題解決の方法がひらめく「ブレークアウト」(ゾーン)の状態になる[10]そうです。
これ仕事でも趣味でもほんとによくある。大事。
机・場所を変える
最近はスタバとかマックとかで開発する頻度が増えてきたけど、確かに捗る。家でやるよりずっと捗る。でもだからって毎日そうしたら今度は家のほうが捗るってなってくると思われるのでバランス大事に。
普段大きなサブディスプレイにつないで仕事をするのに慣れていると、機動性に欠けるため、サブディスプレイに頼らなくてもノートPCだけで仕事が進められるようなテクニックを身に着けておくとよいでしょう。なお、開発やデザインの際は大きなディスプレイがあった方が便利なことが多いですが、モニターを増やしすぎると集中力が削がれるという記事もあります[11]。いずれにしろ道具に振り回されない程度の慣れは必要でしょう。
最近これに気づいて仕事中は外部モニタ使う頻度減らした。画面切り替えのテクニックに慣れると普通にMacBook1台でも捗る。