「言語化」考｜shinshinohara
言語化は「言葉を操る」とは違う。言葉を巧みに操ることは、言語化から最も遠い姿だと思う。言葉に言葉を重ねたら、自分の感覚から遠ざかってしまう。言語化は、自分の感覚に肉薄することであって、言葉を連ねることとは違うように思う。 だから、言語化は、言葉巧みな人よりも言葉の拙い人のほうが最も近いところにいるように思う。自分の感覚を言葉にできず、もどかしい思いをしているなら、それは最も言語化に近い状態。言語化は、自分の感覚に肉薄しようと四苦八苦して言葉を紡ぐことなのかな、と思う。 言語化のもう一つのコツは、人に伝わるかどうかを指標にしないこと。人に伝わることを指標にすると、どうしても常識的な言葉を選ぶことになり、自分の感覚から離れてしまう。言葉の選択も制限されてしまう。自分の感覚により近づけた、と、自分でしっくりくることを大切にすること。人を指標にしない。 自分がしっくりするなら、その分野では使われな
「Ask What, not Why」 失敗したときに自信を失いかけたら実行しているメンタル転落回避術 - Money Forward Developers Blog
半年ぶりのカキコ……ども……。気づいたらHRソリューション本部からMFBC-CTO室に異動していたVTRyoです。兼任で引き続きHR系のマネーフォワード クラウドシリーズも担当しています。 ソフトウェアエンジニアとしての経験値が増えてくると、次第にレビュー担当者になることが増えてくるでしょう。私が所属するSREチームでもTerraformの相互レビューが頻繁に実施されています。そこで、事件は起きたのです。 自信を持ってApproveしたPull Requestで次々に事故が起きてしまった 現在HR内のマネーフォワード クラウドシリーズは、モダンな開発基盤へとリプレイス作業を多く行っています。これまで動いていた基盤に感謝しつつ、新しいPlatformへと移行し、最終的に元あったリソースを削除します。 事件はこの リソース削除 で起きました。 チーム内レビュー OK リポジトリ管理者レビュー
で、出たー！幽霊型だー！(Phantom Type) - Qiita
はじめに この記事はDenis Shevchenko氏の講演、The Way to Simplicity: How Haskell Simplifies Code Maintenance.を参考に書かせていただきました。 概要 この記事ではHaskellのデザインパターンの1つである幽霊型(Phantom Type)について取り上げたいと思います。 完成したコードはGitHubにもアップロードしているのでそちらも参照してみて下さい。 https://github.com/HirotoShioi/PhantomType 今回はメッセージの暗号及び復号を行うライブラリの開発を行い、開発する上で発生した問題を幽霊型を用いることで如何に解決できるかを紹介します。 初期実装 まずはMessage型を定義しましょう 次にメッセージを暗号化し、それを復号する関数encrypt,decryptを実装しまし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
