無気力生活 (ノ ´ω`)ノ ~゜

脱力系エンジニア。てきとーに生きてます。

2018/12/11 今日の気になった記事まとめ

今日は東京急に寒くなりました。昨晩から兆候はあったものの、ここまで急激に気温下がると体がしんどいですねー(´・ω・`)

このRubyのメソッド達知らないっ...!!

thr3a.hatenablog.com

try, presenceはよく使うとして、日付の範囲取るメソッドにこんなのあるの知りませんでした。 今までTime.current.beginning_of_day..Time.current.end_of_dayと書いていたんですが、Time.current.all_dayで行けるとはあっぱれ。

to_s(:db)は割と使えるところがあって、例えば生クエリ発行することが稀にあるんですが、ActiveRecordを通すとある程度時差あたりの変換をやってくれるんですが、生クエリだと自力で変換しなくてはいけないんですよ。

to_s(:db)を使うとそのへんうまくやってくれます。(to_s(:db)といっておきながらDB自体のタイムゾーンではなく、DBサーバーのTZに依存するので地味に注意)

中長期設計はちゃんと計画立てて秩序を守らないとしんどい分かり味の深さ

speakerdeck.com

コード秩序わかる。これサービスを自社運用している人たちにはぜひ読んでもらいたい。 ある程度秩序だって実装を整理しておかないと、将来の機能拡張で無駄な苦労をするはめになります(´・ω・`)

明日の自分を救うためにも、日々妥協せず設計を考えていきたいものです。

Golangの大域脱出の手法を知る

qiita.com

defer-recoverでやれるのは知見でした。きれいな言語仕様でとても良いと思います。 Javaの検査例外についてはまあ...ほんとこれ、って感じなお気持ちです。

あるいは NullPointerException や ArrayIndexOutOfBoundsException といった如何にもコーディングのミスで起きてしまいそうな例外が RuntimeException ではなく Error のサブクラスだったとしたら、Java の例外処理はもう少し平和な世界になっていたのかもしれない

関数型言語についてはあんまり知見がないので、コメント欄でやられているやり取り等も参考になります。意識して違うパラダイムの言語を触るべきなんだろうなーと感じてます。

気軽に使える機械学習。ここまで採用簡単に行けるんですね

qiita.com

画像投稿機能有りサービス作るときに自前で頑張るより、サクッと適用して手間を防ぎたいのは同意です。アダルトといった不適切画像、世間一般的に共通認識として弾けるものはこれで十分ですね(`・ω・´)

画像チェックは人手でやると膨大なチェック工数取られます。これが一部とはいえザクッと分類できればかなりの工数削減になる。機械学習が活かせる場は思ったよりたくさん埋まってそうなので、必ず触っておきたいものだと感じています。

推奨されているスクラム開発だと、改善の時間取りにくいですよね

www.wantedly.com

弊社もまさに同じ問題を抱えています_(:3」∠)_ ビジネス要件と技術要件の優先度が付けづらい問題、どんどんビジネス要件が積まれていくので負債の返済が後回しになっていく現実があるわけで。

エンジニアが主体でやるべきことを決められるのであれば負債どんどん返していけるんですが、ビジネスサイドが決めている場合どうしても後回しになっちゃうんですよね。今日も帰り際、負債を返済するための理由付けをPOと話していて、予算獲得するためにどんな説明しようかと頭悩ませてました(´・ω・`)

予め受け取るビジネス要件以外にバッファとして時間積んでおき、ゆとりをもたせておく。自発的な改善行動を期待するのであればそれに向き合うだけの時間を用意してあげることは大切ですね。

ユーザー要望をユーザー価値に変えるために考えること

https://dely.design/n/nfff10800b770

本当にほしいのはドリルの穴だった、という話は有名ですよね。 要望には顧客自身が感じている課題や問題点がセットになります。ここで書かれているのは事実を元にして本当にほしいものを考えることで、ユーザーの願望を叶えて上げる方法論ですね。

ある事実を分析するには、「その事実はなぜ発生しているか?」に向き合う必要があるのですが、そのためには自身の考えだけではなく、様々な視点から考えることが大切ですね。

無意識だと個人個人が思うことだけ考えて終わっちゃうんですよね(´・ω・`)ヌケモレを防ぐためにこのようなツールで強制的に視点を変える方法、かなり聞くんじゃないか?と思いました。

心理的安全性ガイドライン

qiita.com

私個人として、思ったことは相手に関係なく口に出ちゃう質ですのであんまり気にしたことはないんですが、そうじゃない人の方が多数派なんです。前々職ではハングリー精神強い人が多く、目的のためなら意見のぶつかり合いを歓迎する文化だったので気づかなかったんですが、前職に転職したときに感じたことがまさにこれでした。

強いチームとして機能するには、自由に意見を言い合えてお互いに尊敬できる関係性を作ることが必須です。そういった文化を率先して作っていけるような考え方を、常に意識していくことが、メンバーの一人として大切なことなのかもしれません。