zsh + fzf で「あの時作業していたあのブランチ」を快適に探す - mizdra's blog
今まで id:mizdra はターミナルで Git ブランチを切り替えるときに、zsh + peco を使った Git ブランチ検索用のキーバインドを使用していた。 # .zshrc function select-git-branch() { selected_branch=$(git branch | cut -c 3- | peco) BUFFER="${LBUFFER}${selected_branch}${RBUFFER}" CURSOR=$#LBUFFER+$#selected_branch zle redisplay } zle -N select-git-branch bindkey '^b' select-git-branch zsh + peco で Git ブランチを切り替える様子 便利っちゃ便利なのだけど...沢山のブランチの中から「あの時作業していたあのブランチ」
40歳になるので30代でやってよかったことをまとめた - そーだいなるらくがき帳
来週で40歳にあるので30代の振り返りとしてこれを書く。 そんな30代を全力で走ってきた中で、これは30代でやってよかったな。 もっと早くやってもよかったな。というようなことを書く。 最初に行っとくと一般的にやったほうが良いということは基本的にやったほうがいい。 そういうのも含めて実際にやってみた経験も書く。 習慣を作れるようになる これは本当にやったほうがいい。 身につけるのであれば、早ければ早いほどほどいい。 もう少し具体的に話すと自分がやりたいことを実現していくためには習慣にできるとよい。 なんでも習慣にできると強くて、自分はどうやったら習慣になるんだろう？ってところを理解して上手くハックして習慣化していけると自分のやりたいことがどんどん実現できるようになる。 運動習慣 これも早ければ早いほど良いと思うが、朝か夜の散歩くらいからでもよいからやったほういい。 コロナ禍をきっかけに自分は
組織に自動テストを書く文化を根付かせる戦略（2024秋版） / Building Automated Test Culture 2024 Autumn Edition
2024年10月18日 日本SPIコンソーシアム（JASPIC） ソフトウェアプロセス改善カンファレンス2024
GoでYAMLを扱うすべての人を幸せにするべく、ライブラリをスクラッチから書いた話 - Qiita
この投稿は、 Go アドベントカレンダーの 6日目のものになります。 はじめに GoでYAMLを扱う際にデファクトになっているのは、おそらく github.com/go-yaml/yaml でしょう。 実装はC言語で実装された libyaml を Go に移植しつつ、 Go ならではの機能を足す作りになっているのですが、 cgo を使わずに pure Go で移植されており、開発者の気合を感じます。 枯れている libyaml を利用していることからも、 YAML の仕様を忠実に実装していることが期待できます。 ですが、このライブラリにはいくつか使いにくい点もあり、例えば以下のようなことはできませんでした 構造体を埋め込む場合に、埋め込む型をポインタで定義できない ( ※ ポインタなしは大丈夫 ) encoding/json とコンパチの インターフェース ( MarshalYAML()
ISUCONの過去問でObservabilityを体験する - Hatena Developer Blog
システムプラットフォームチームで SRE をしている id:masayoshi です。 今年もISUCON14の開催が決定しましたね！ isucon.net ISUCONとはLINEヤフー株式会社が運営窓口となって開催している、お題となるWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトルです ISUCONは、世の中に実際にありそうなWebサービスを題材に、明確なボトルネックがあるコードかつ全体のコード量もすぐ読める量なので、パフォーマンスチューニングの練習にはもってこいです。 適切なパフォーマンスチューニングをするためには、まず計測してシステム上のどこにボトルネックが存在してパフォーマンスが悪化しているのかを把握する必要があります。 このように、どこで、何が起こり、パフォーマンス上の問題やエラーがおこっているのかを把握できる能力を Observabili
GitHub ActionsのJobが落ちたときに何をするべきかを記述するPlaybookの仕組みを作って運用している話 - newmo 技術ブログ
newmoではGitHub Actionsを自動テスト、Lint、デプロイなどに利用しています。 また、newmoではmonorepoで開発しているため、1つのリポジトリに複数のチーム/複数のアプリケーションが存在しています。 GitHub Actionsではpathsを使うことで、特定のファイルが変更された場合のみ特定のWorkflowが実行できます。 newmoのmonorepoのworkflowでは基本的にpathsが指定されていますが、それでも普段は触らないファイルを変更して意図せずにCIが落ちることがあります。 GitHub ActionsのCIが落ちたときに、そのCIの仕組みを作った人やチーム以外だと何をすべきかわからないことがあります。 この問題の解決するを手助けするシンプルな仕組みとして、GitHub ActionsにCIが落ちたときに何をするべきかを表示するPlayboo
go testの時だけ時刻を固定する - newmo 技術ブログ
はじめに こんにちは。newmoでソフトウェアエンジニアをやっている@tenntennです。 newmoには2024年8月に入社しました。この記事を書いているのは2024年9月なので、入社してだいたい1ヶ月ちょっとが経過したところです。 なお、筆者が入社した経緯などは次の記事を読んでください。 note.com 入社した当初、newmoのバックエンドコードのコードを眺めていると、次のように宣言された関数を見つけました。 func Now(_ context.Context) time.Time { return time.Now().In(time.UTC) } 単にtime.Now関数を呼び出して、LocationをUTCに設定しているだけです。 しかも、引数はブランク識別子になっているので使用していません。 しかし、筆者はこれを見て、これは後々のことを考えているなと感心しました。 ちな
現職での技術的活動の振り返りと反省（自戒） | ymtdzzz.dev
2024年6月30日に今の会社を退職し、翌7月1日から別の会社に入社することになった。 現職の在籍期間は大体３年弱ほどで、アーキテクチャを中心とした技術的な意思決定も色々してきた。新規構築から運用までやってきた中で感じたことや経験豊富なエンジニアからいただいたアドバイスなど、それらを含めて当時の意思決定の反省を自戒を込めてここで書いておく。 Table of Contents 留意事項 やったこと 想定効果 基盤チーム側の効果 サービス開発（基盤のクライアント）側の効果 意思決定 技術スタック コード管理 インフラ その他 所感と教訓 コンポーネントとリポジトリの粒度は別 複雑性を犠牲にする決断の重さ（マルチクラウド、マイクロサービス etc.） 共通基盤を初めから独立したサービスとしてデプロイしないのもあり サブシステムとしての共通基盤にどこまで粗結合を求めるべきか考える 結論：後から分
DMS を利用した継続的なデータ変更検知 - クックパッド開発者ブログ
SRE の鈴木 (id:eagletmt) です。先日、この開発者ブログで赤松から One Experience プロジェクトについての紹介がありました。 自分もこの One Experiene プロジェクトに携わっており、このプロジェクトが始まったちょうど1年くらい前にはイギリスにあるオフィスに行き、グローバル版のシステムを開発・運用しているメンバーと直接顔を合わせたりもしていました。自分は One Experience プロジェクトにおいて主にデータ移行について担当していました。データ移行に必要な作業はいくつかありますが、この記事ではその中から日本版のシステムのデータベースで発生したデータの変更をどのようにしてグローバル版のシステムのデータベースに継続的に反映したかの部分について紹介します。 One Experience でのデータ移行 赤松の記事にも書かれていたように、日本版とグロー
適切なインフラコスト難しいなと思って、上場企業約30社分のサーバー費用を調査した💻
はじめまして、asachiです。 普段はプロダクトマネージャーとかデザインとかをやっています。 最近、会社・事業のインフラコストをどう評価するかという話に社内でなって、実際各企業どんなもんなんだろうなと気になり、IR資料から頑張って漁ってきました。 せっかく色々と見たので、気になった事例等含めて書いていこうかなと思います。 TL;DR 上場企業のインフラコストを調べた 規模・業態問わずで30社くらいのデータを発掘できた 最もコストがかかっていたのはゲーム会社アカツキ約11-12億/年 次点はツイキャス運営のモイ 約5.8億/年 「メメントモリ」が流行ったため、BANK OF INNOVATINが直近四半期でサーバー費用が3億円/四半期(前年同期比1,153%)になっていた 各種会計項目に対してサーバー費の比率が安定しているのは、GunosyとGameWith 売上原価に占める割合が高いのは
DuckDB で JSON Lines 形式のログを精査する
まとめ 圧縮された複数の JSON Lines を読み込める S3 から直接読み込める 好きなタイミングで Parquet で出力 DuckDB とは こちらをどうぞ。 DuckDB雑紹介(1.1対応版)@DuckDB座談会 - Speaker Deck 圧縮済みのログを読み込む 解析対象のログファイルって spam-20240501.jsonl.gz や egg-20240601.jsonl.zst みたいに圧縮されていたりします。 特に日付単位で分かれてたりすることは多いです。そこから目的のログを探し出すのは、基本はスクリプトを書くことが多いと思います。 DuckDB を使えば色々解決します。
エンジニア採用のパラダイムシフト - laiso
エンジニア採用の状況は地域によって大きく異なる 最近視聴した2つのコンテンツが、同じソフトウェアエンジニア採用の話題を取り扱っているにもかかわらず、その内容が両極端で非常に興味深かった。 ひとつは「エンジニア採用必勝法・これだけでわかるDevRel入門」という動画で、もうひとつは「最近カナダで就職したエンジニアと一緒に北米就活の攻略法を語る」というポッドキャストのエピソードだ。 エンジニア市場と企業の採用戦略は地域や業界によって異なるが、ここで話されている東京と北米（バンクーバー）では顕著な違いが見られる。 東京を中心とする日本ではテック企業間での人材獲得競争が激しく、特にエンジニアが不足しているため、採用広報の役割の重要性が増し、DevRelといった呼び名で施策が実行されている。 一方、カナダでは、永住権を持たない外国人労働者が職を得るハードルが高く、求職者の競争が激しい現状が実際
その先に進むためのモジュラーモノリス再入門
この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の 60 週目の記事です！2年間連続達成まで 残り 46 週 となりました！ 「モジュラーモノリス」はここ数年で広く普及してきました。実際にモジュラーモノリスを取り入れた開発事例を多く見かけるようになりました。当記事では改めてモジュラーモノリスの起源を遡り、また、さらにその先に進むためにどのような準備をしておくべきかを軽くまとめてみます。 モジュラーモノリスとは モジュラーモノリスの起源は 2018 年頃 「モジュラーモノリス」という言葉の正確な起源は把握していませんが、Simon Brown が GOTO Conference 2018 で行った講演がその起源の一つかもしれません。この講演は、モジュラーモノリスの概念をわかりやすく説明しており、その後、多くの企業がこれに注目するきっかけとなりま
sqlcで使うDBドライバをpqからpgx/v5に移行した話 - enechain Tech Blog
この記事は enechain Advent Calendar 2023 の 16 日目の記事です。 はじめに みなさん、こんにちは。enechainでSWEをしている@kkagurazakaです。 enechainでは最低限のルール (バックエンドサービス間の通信はgRPCを使う、など) を守っていれば、技術選定は各チームに委ねられています。 たとえば、本Advent Calendarの10日目の記事「GoのAtlasとBunを使ったマイグレーション環境を構築する」を書いたJCEXチームでは、ORMにBunを採用しています。 一方、我々のチームではsqlc-dev/sqlcをデータベースへのクエリに使っています。 最近、そのsqlc経由で用いるPostgreSQLのドライバをpqからpgx/v5に移行したのですが、それに際して幾つかの工夫をする必要がありました。 そこで、今回の記事では我々
DDDで集約を跨いだ情報でロジックを構築するための「getter高階関数パターン」の紹介
はじめに 今回はDDDで集約を跨いだ情報でロジックを構築するためのパターンについて紹介していきます。 DDD（ドメイン駆動設計）における「集約（Aggregate）」とは、関連するオブジェクト（エンティティや値オブジェクト）を一つにまとめた単位のことを指します。集約はドメインのビジネスロジックの適用や整合性を維持するために定義されます。永続化は集約単位で行われます。 例えばECサイトの注文という集約には、一つの注文に複数の注文明細があるとします。この注文と注文明細はそれぞれがエンティティであり、このとき集約は「複数の注文明細を持つ一つの注文」という単位で管理され永続化されます。一つの集約の中に二種類のエンティティがあるということです。 Amazonで注文した時に、化粧水を2個、洗顔料を1個まとめて買ったときの注文を一つの集約として取り扱っているイメージです。 class Order( va
Cloud Run のための実践 Cloud Deploy
はじめに 本記事では実践的な Cloud Run のデプロイパイプライン実装を通して Cloud Deploy の理解を試みます。Cloud Deploy は元々 Kubernetes 用のプロダクトとしてリリースされたこともあり、Cloud Run に限って利用するには学習コストが高すぎるところもあります。本記事では Cloud Run のデプロイの本番環境構築・運用に必要な部分のみをピックアップして次のようなことを説明します。 Cloud Deploy の仕組み Cloud Deploy を使ったデプロイパイプラインの設計・実装方法 Service Account、IAM 設計 おすすめの Infra as Code の方法 おすすめの skaffold.yaml の書き方 Automation、デプロイフック、カナリアデプロイなどの高度なパイプライン、監視などは上記のような基本をおさ
最高のターミナル環境を手に入れろ！WezTermに入門してみた。 | DevelopersIO
Rust製のターミナルアプリ WezTermをご存知ですか？ もしご存知なければ、最高の相棒を紹介させてください！！ WezTerm - Wez's Terminal Emulator 基本的な性能 ターミナルアプリに求められる要素はとてもシンプルです。 1に安定！ 2に軽量！ 3,4がなくて 5に機能 です。 安定と軽量の2つが満足でないとターミナルアプリは 比較という俎上に上がること自体が難しいです。 さて、WezTermはというと、 あくまでも私の実感レベルですが、どちらも全く問題ないです。 ターミナルアプリでは日本語の入力系などで難ありなものも結構あったりしますが 今の所その辺でも特に問題を感じたことはないです。 非常に主観的な記述だけで申し訳ないですが、 この辺は色々書いたところで使ってみないことにはわからないと思いますので、 まずは使ってみてください。 また私はMacで利用して
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Cloud Run YAML Reference | Cloud Run Documentation | Google Cloud
ADRを運用して3年経った僕らの現在地
sq
