株式会社はてなを退職 - Sexually Knowing
2020年8月14日付けで退職する運びとなった。 入社が2012年なので勤続丸8年を迎え社内でも古株の方になってきつつある。Web業界にしてはわりと長くいたほうだと思う。 自分自身でもこんなに長く籍を置くとは思っていなかったので驚いている。 退職を決めた理由は主に2つ。 金沢移住 1つめは、現在住んでいる京都を離れて金沢で暮らしたいと考えたから。 数年前に観光で訪れた金沢を歩いてから一目惚れしてしまい、自分がここで生活する想像をするうちに単なる夢想から具体的に実現することを考えはじめた。 これを書いている時点で、株式会社はてなの事業拠点は東京と京都のみであり、在宅勤務は育児や介護、その他会社が認めるに足る理由があるケースのみ認められている。 平時は週数日程度スポットでの在宅勤務はマネージャーと合意した上では認められている。またコロナ禍においては在宅勤務推奨となっている。ただし、継続的にフル
SNSで同僚をフォローするのをやめた - Sexually Knowing
SNSというかTwitterで同僚をフォローするのをやめて精神衛生が良くなった。 一緒に仕事をするうえでパーソナリティも知りたいなと思って基本的にフォローしていたのだけれど、最近それによって楽しいとか便利と思うことより、きついと感じる機会のほうが多くなったのでやめた。 『エンジニアのためのマネジメントキャリアパス』を読んだ そもそものきっかけは、チームでテックリードというエンジニアのリーダー的な役割を拝命したからだった。 チームを良くするためにという思いもあって、チームのエンジニアのそれも職能のうちの一部に限定して基礎的なマネジメントに手をつけはじめた。 会社にはシニアエンジニアによるメンタリング制度がありそちらはチーム 外 のエンジニアがメンターを務めることになっている。その制度とは別にテックリードとしてチームメンバーのキャリアプランなどを鑑みて、チームと個人がお互いにハッピーになるには
はてなブログのデプロイを約6倍高速化したはなし - Sexually Knowing
今年、稼働中のサービスであるはてなブログのデプロイ方法を新しい方式へ無事故で移行し、従来と比べて約6倍速くデプロイできるようになりました。 この記事では、安全にデプロイ方式を変えたプロセスを順を追って紹介します。 はてなブログと継続的デリバリー デプロイが遅い 複雑なデプロイ設定 デプロイのテストを書く ボトルネックの発見、そして pull 型から push 型のデプロイへ 新デプロイへの移行 結果 まとめ はてなブログと継続的デリバリー はてなブログは1日あたり平均して1.02回デプロイを行っています。これは土日を除いた週5日の営業日に対する平均です。ざっくりとした算出で、祝日は考慮していません。5月と9月の祝日を含めるともう少し多くなるかもしれません。 また、原則として休日の前日にはデプロイしないことになっています。もしもデプロイした変更にバグがあった場合、休日が明けてから対応するか、
GitHub の Deployments API を使ったデプロイのワークフローのイメージ - Sexually Knowing
GitHub の Deployments API を使うと Web アプリケーションのリリース (デプロイ) に関わるワークフローをより便利にできそうだったので、試したことを記録する。 Deployments API でできること Deployments | GitHub API すべてドキュメントに書いてあるが、かいつまむと: 「デプロイ」を表現するイベントを作ることができる 進捗 (e.g. 成功、実行中, etc.) を表現できる (「デプロイ」を表現するイベントに紐付くメタデータ (e.g. 説明、payload) を作ることができる) ……という具合である。 つまり GitHub の API は具体的なデプロイのタスクについて責務を負うことはなく、「デプロイ」というイベントをリポジトリにアーカイブしそれらを通知する責務のみを負う、ということになる。Webhook のひとつと言い換
work tree の外から git pull する - Sexually Knowing
バッチスクリプトなどで work tree の外から git pull を行いたい、ということはままあるシチュエーションであると思います。 git コマンドは --git-dir オプションでコマンドで操作する .git ディレクトリを指定できるので、これを指定すれば済むと思うかもしれませんが、これではうまくいきません: cd $HOME git --git-dir=$HOME/repos/@aereal/dotfiles/.git pull # Cannot pull with rebase: You have unstaged changes. # Please commit or stash them. work tree も指定する必要があります: git --git-dir=$HOME/repos/@aereal/dotfiles/.git --work-tree=$HOME/r
Gitのベストプラクティクスっぽいもの - Sexually Knowing
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を使いはじめてだいぶ親しめるようになった。 文字通り、ブランチ、枝である。気軽に扱えるということは理解の助けにもなる。 コミットの単位 論理的に最小限度のコミットをつくる。「こう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ログインシェルに fish を指定しているときに Vim の system 関数を実行すると E484 が発生する - Sexually Knowing