何かをやる上で失敗しないに越したことはないですし、そのリスクはあらかじめ減らせたり排除できると良いのはもちろんですが、どうしたってゼロにはできません。 それが新規事業のような不確実性の高い領域であればなおさらで、正解の見えない世界での判断は少なからず博打の性質を孕むことになります。 ソフトウェアエンジニアとしてそういった場面で判断をする時に、合理性で選択肢を減らしていった後で残った選択肢を選ぶ時の決め手として、自分は「失敗しても何を残せるか」という観点を持ち出します。 正解のない世界で自分を鼓舞するためのある種のまじないのようなものですが、これについて掘り下げてみます。 プレモーテムとは 終わりを意識して始める: プロジェクトのプレモーテムを行う方法 [2022] • Asana プレモーテム (premortem) とはプロジェクトの終了をまず予想し、そこから逆算してリスク要因を見つけた

github.com 背景 仕事でお世話になっているkayac/ecspressoの機能の中にローカルのタスク・サービス定義と現在使われている定義を比較して差分を出力してくれるものがある。 github.com これから加えようとしている差分をプレビューできるだけではなく、たとえばデプロイしようとしているわけでもないのに差分があればローカルの定義が古びていることがわかるのでCIに組み込めると便利。 しかし実際に使おうとすると困る点が見つかった。 たとえばタスク定義にイメージタグを書く際に {{ must_env 'IMAGE_TAG' }} のように環境変数を参照している時に「イメージタグ 以外 に差分がない」ことを確認するのが難しいということ。 理想的には image を無視したJSONの構造を比較して差分が出せると良い。あるいは出力されるdiffをパースして image の差分は無視す

これまで 色んなチームにヘルプで入ってプロジェクトやチームを良い感じにする手伝いをすることが主で、他に基盤サービスを作って運用したり、あとは開発者ブログ編集部をやったりなどなど。 現職での1年半くらいのキャリアにおいてソフトウェアエンジニアリングは高々3割くらいで、あとはプロジェクトやピープルをマネジメントするような仕事が占めていた。 振り返り 前職でもWevoxを使っていて、その当時から振り返ってもありえないくらい低い「自己成長」スコアがここ最近ついていてクソワロタ (真顔) 状態だった。 このままだと退職 or dieしかないと感じたので、上司には「もうしばらくプロジェクトマネジメントはやりたくないでござる 絶対にやりたくないでござる」と上申して新しいチームへの配属を希望した。そしてそれは叶えられた。 Webサービスを作って届ける過程でプロジェクトやピープルをマネジメントすることの必要

シェルスクリプトを書くのをやめる - blog.8-p.info これを見て: 夢の可能性が高くなってきたんですが、Perlのプラグマかなにかで、シェルスクリプトと混在できる……というか、存在しないサブルーチン呼び出しを外部コマンド呼び出しにするやつありませんでしたっけ— aereal / 青木華絵 (@aereal) 2021年9月16日 まじだ... https://t.co/IF6SyBR4o8— Kazuyoshi Kato (@kzys) 2021年9月16日 Shell - run shell commands transparently within perl - metacpan.org use Shell qw(cat ps cp); $passwd = cat('</etc/passwd'); @pslines = ps('-ww'), cp("/etc/passwd"

重い仕事・比較的やりたくない仕事・とっかかりが見つからない仕事など、アサインされたけれどどうにもやる気が出ない仕事に出くわすことはしょっちゅうあると思う。 そういう時におすすめしたいのが「誰か一緒にやりませんか」とペアプロ・ペア作業相手を募集すること。 実際に一緒に作業することになれば: 相手の作業時間を確保するので否応なしに向き合うことになる 視野が広がる 単純に他人の目が増える またプレッシャーが減ることで自身の視野も良くなりうる 作業効率が上がる 単純作業がたくさんある場合なんかにはとても助かる また、チームの状況がそれを許さない場合でも: なんか大変そうだなというアラートが届く だいたいアラートを上げるのが苦手な人は顔色を変えないことが多いので、周りからフォローしにくい アラートをあげる心理的障壁が低い 「つらいのでやりたくないです」と言える人はなかなかいないと思うし、言ったとして

コードを書かない問題解決 ソフトウェアエンジニアとしての価値観とか仕草みたいなのはだいぶid:hitode909さんの影響を受けており、その中でも自分が大きく変わったと思うのは、問題解決の手段としてソフトウェアにこだわりすぎないという視点を手に入れたこと。 自分は本来的にはコードを書くのが大好き人間というかyak shaving大好き人間なので、コードを書きはじめて実現に至るまでのすべての寄り道を楽しいと思う性質だけど、一方、チームや組織という文脈でそれが常に正しくて価値が最大かというとそうではない。 ……ということに気が付かされたのはひとでさんと仕事していて自分がソフトウェアを作るという方法にこだわって悩んでいると「とりあえずスプレッドシートで運用してみませんか」とか提案してもらえることがあり、最初はえーコード書きたいよと思っていたものの実際にやってみるとそれくらいで事足りる頻度の作業だ

SNSというかTwitterで同僚をフォローするのをやめて精神衛生が良くなった。 一緒に仕事をするうえでパーソナリティも知りたいなと思って基本的にフォローしていたのだけれど、最近それによって楽しいとか便利と思うことより、きついと感じる機会のほうが多くなったのでやめた。 『エンジニアのためのマネジメントキャリアパス』を読んだ そもそものきっかけは、チームでテックリードというエンジニアのリーダー的な役割を拝命したからだった。 チームを良くするためにという思いもあって、チームのエンジニアのそれも職能のうちの一部に限定して基礎的なマネジメントに手をつけはじめた。 会社にはシニアエンジニアによるメンタリング制度がありそちらはチーム 外 のエンジニアがメンターを務めることになっている。その制度とは別にテックリードとしてチームメンバーのキャリアプランなどを鑑みて、チームと個人がお互いにハッピーになるには

delveとは Go向けのデバッガで、ステップ実行とかブレイクした行のレキシカル変数が見えたりといった基本的な機能を提供しつつ、dlv debug でコンパイルしつつ実行 (go run) したりgo(1)とほどよく統合されている。 後述するheadlessモードがあっていわゆるリモートデバッグが可能。 delveをmacOSにインストールする 公式のドキュメントではbrew install go-delve/delve/delve一発で済むように書かれているが実際はうまくいかなかった (´°̥̥̥̥̥̥̥̥ω°̥̥̥̥̥̥̥̥｀) ==> Installing go-delve/delve/delve ==> Downloading https://github.com/derekparker/delve/archive/v1.0.0.tar.gz ==> Downloading fro

GitHub - aereal/nikki 昨年末からぼちぼち書いている。 モチベーション いわゆるページを動的に生成するWebアプリケーションのパフォーマンスチューニングの練習台 サーバサイド、クライアントサイド双方に渡る改善を試みる余地がある 諸々のWeb技術の遊び場 TypeScript Google Cloud Platform Kubernetes HTTP/2 GraphQL SPA = Single Page Application 以上が目的としてではなく、手段として求められ高度にバランスされること 普段から自分が使うアプリケーションであること (技術採用など意思決定の練習) ……を目的に考えて日記を書くためのブログシステムを書きはじめた。 Web技術で遊び続ける定まった場所がないと、技術を使うための技術の域を出ない学習が続くなという問題意識から何か作ることにし、自分はWe

実行環境をコンテナ化するDockerが普及して久しく、CIやローカルの開発環境などどこかでコンテナ技術に触れているのではないでしょうか。 コンテナはその性質上、設定のプロビジョニングに古典的な設定ファイル (のパス) 受け渡しが難しいです。etcdやconsulのようなKVS (= Key-value store) を用いることもあるでしょうが、素朴には環境変数で与えることが多いでしょう。 HerokuはThe Twelve-Factor Appというパターンを提唱し、その中でStore config in the environmentと述べています。 The twelve-factor app stores config in environment variables (often shortened to env vars or env). Env vars are easy to

speakerdeck.com だいぶ大仰なタイトルでありますが掲題の内容を社内勉強会で話しました。 音楽を作る古典的な方法論 (機能和声) を取り上げ、その中でも和声 (harmony) をコアドメインと見据え、実際に和音進行の規則などを実装したという内容です。 和声と周辺の概念をScalaで表現したコードを交えながら、和音や調・音階をエンジニア向けにどういうパラメーターを受け取ってどのように導出できるか、といった観点で紹介しています。 端折ったりやや正確さに欠ける説明になっているところがあると認識していますが、プログラミングあるいは抽象的な構造とその生成規則を発見するという観点でおもしろさを感じてもらえるようなアレンジです。 紹介したコードは素朴なWebアプリケーションとして実装し、公開しています: GitHub - aereal/music-study きっかけ アカデミックな知識を

社内グループに書いていたメモをせっかくなので放流します。 前提 昼食はオフィスで食べられる 基本はオフィス勤務だが、相談の上リモート勤務も可能 自宅からオフィスには徒歩で20分、自転車で10分 京都在住 北海道の実家で2週間程度のリモート勤務を2回経験 リモート勤務の感想 お昼ごはんの用意をしていると昼休みがあっという間になくなる 普段オフィスにいるとランチをいただくのに20〜30分くらい、残りは休憩スペースで同僚と話したり本を読んだしている お昼休み・定時になるとチャイムが鳴るが、自宅だと鳴らないのでしょっちゅう時計を気にして疲れる 途中までSlackで参加していた会話が口頭に変わると経過がわからなくなるので、あとはうまく話が進んでいることを祈るしかなくなる いまのチームに慣れたからいいけど、入りたてとかだと不安だと思う 人と関わりがなくて気が滅入ってくる 普段、人と話すわけではないけど

今年、稼働中のサービスであるはてなブログのデプロイ方法を新しい方式へ無事故で移行し、従来と比べて約6倍速くデプロイできるようになりました。 この記事では、安全にデプロイ方式を変えたプロセスを順を追って紹介します。 はてなブログと継続的デリバリー デプロイが遅い 複雑なデプロイ設定 デプロイのテストを書く ボトルネックの発見、そして pull 型から push 型のデプロイへ 新デプロイへの移行 結果 まとめ はてなブログと継続的デリバリー はてなブログは1日あたり平均して1.02回デプロイを行っています。これは土日を除いた週5日の営業日に対する平均です。ざっくりとした算出で、祝日は考慮していません。5月と9月の祝日を含めるともう少し多くなるかもしれません。 また、原則として休日の前日にはデプロイしないことになっています。もしもデプロイした変更にバグがあった場合、休日が明けてから対応するか、

GitHub - aereal/vim-colors-japanesque: The colorscheme featuring Japanese traditional colors. 日本の伝統色を使ったカラースキーム: Japanesque GUI 版の Vim 向けカラースキーム・Japanesque を作った。 iTerm 2 で使えるカラースキーム、Japanesque を作った - Sexually Knowing 以前、iTerm 向けに作った同名のカラースキームを踏襲しつつ新たにパレットから作った。 コンセプトとしては: 十分なコントラストが確保されていること 着目すべき構文要素が適切に目を引くような配色であること ……とした。 インストール方法 " neobundle.vim NeoBundle 'aereal/vim-colors-japanesque' " Vund

この記事は、はてなデベロッパーアドベントカレンダーの19日目の記事です。 昨日は、id:t_kyt による あれから一年、あの TypeScript プロジェクトは今 - 多幸感 でした。 すばやく、かつ堅牢にアプリケーションをつくる ボタンを連打したくなる性と向き合う サーバサイドにおける工夫 イベントソーシング リクエストに複数のリソースを含められるように クライアントサイドにおける工夫 イベントのバッファリング accumulate-call で簡潔に書く むすび すばやく、かつ堅牢にアプリケーションをつくる はてなの id:aereal です。アプリケーションエンジニアとして日々、サービスの開発に携わっています。 はてなではサービス開発合宿が年に一度ほどのペースで開催されています *1。今年もつい先日開催されました。 私たちのチームは技術的な挑戦を行う一方で、プロトタイプではなく初

コードは道具 コードを書くことは好きだし、死ぬまで続けると思うけど、一方で常に自分の目的であるわけではないと考えている。 よいもの、おもしろいものを作りたくて、それを作って表現する場としてインターネットでありコードを選んでいる。 対象とする文化 (ターゲットユーザ) を定めないとプロダクトの設計はできない 文化圏によって色や言葉、仕草の持つ意味が変わるということは、ビジュアル・デザインをはじめとするデザインは文化非依存に行うことはできないと考えている。 つまり、「誰に使ってもらうか」というところからプロダクトの設計が始まる。 言い方を変えると、製作者がプロダクトの魅力を伝えきれる人々は切り分けられるということ。 多くの人に使ってもらうことも大切だけれども、一方で100%を伝えようとすることができる人は限りがある、ということを受け入れないといけない。 さらに実際に伝わるか、ということを差し引

tbaggery - A Note About Git Commit Messages A successful Git branching model » nvie.com Commit Often, Perfect Later, Publish Once—Git Best Practices だいたいこれらに書いてあることを考えている。 基本的にGit Successful Branch Modelで運用する。git-flowを入れて使っているけど、手でやってもそんなに面倒ではないし好きなようにしたらよさそう。 Subversionを個人で使っていたころはブランチはよくわからないけど恐しいものだったけど、Gitを使いはじめてだいぶ親しめるようになった。 文字通り、ブランチ、枝である。気軽に扱えるということは理解の助けにもなる。 コミットの単位 論理的に最小限度のコミットをつくる。「こう

2020年8月14日付けで退職する運びとなった。 入社が2012年なので勤続丸8年を迎え社内でも古株の方になってきつつある。Web業界にしてはわりと長くいたほうだと思う。 自分自身でもこんなに長く籍を置くとは思っていなかったので驚いている。 退職を決めた理由は主に2つ。 金沢移住 1つめは、現在住んでいる京都を離れて金沢で暮らしたいと考えたから。 数年前に観光で訪れた金沢を歩いてから一目惚れしてしまい、自分がここで生活する想像をするうちに単なる夢想から具体的に実現することを考えはじめた。 これを書いている時点で、株式会社はてなの事業拠点は東京と京都のみであり、在宅勤務は育児や介護、その他会社が認めるに足る理由があるケースのみ認められている。 平時は週数日程度スポットでの在宅勤務はマネージャーと合意した上では認められている。またコロナ禍においては在宅勤務推奨となっている。ただし、継続的にフル