ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
インフラにかかるコストを正しく「説明」するための取り組み - クックパッド開発者ブログ
技術部 SRE グループの mozamimy です。 クックパッドでは、 SRE が中心となって、サービスを動かす基盤の大部分である AWS のコスト最適化を組織的に取り組んでいます。 昨年夏に公開した記事である、インフラのコスト最適化の重要性と RI (リザーブドインスタンス) の維持管理におけるクックパッドでの取り組みでは、 なぜインフラのコスト最適化が必要なのか、具体的にどのような考え方に沿って進めてゆけばよいのか。 SRE が一括して管理する AWS のリソースプールそのもののコスト最適化を実践するための具体的な取り組みの一例として、RI のモニタリングや異常時の対応フローによる維持管理。 といった話題にフォーカスしました。 今回は、インフラにかかるコストを正しく「説明」するための取り組みということで、コスト最適化に貢献する社内アプリケーションである Costco (Cost Co
様々なTODOアプリやタスク管理方法を試行した結果最終的にプレーンテキストに行き着いた話 - みんからきりまで
TODOアプリという永遠のテーマ このブログでは過去に何度かタスク管理についてエントリを書いてきました。 kirimin.hatenablog.com kirimin.hatenablog.com kirimin.hatenablog.com タスク管理のためのいわゆるTODOアプリについては色々なものを試してきて、KanbanFlow→Habitica→GitHub→Todoistと移り変わっていった。 でもやっぱりメモ帳を使ってしまう問題 このように最高のタスク管理をしようとポモドーロ機能やリマインド機能、優先度設定やタグ付け、定期タスク登録など様々な機能を持ったタスク管理アプリを使ってきたが、いつも気がつくとWindows標準のメモ帳かVScodeでプレーンテキストに書きなぐってしまう。 しかもそれが一番しっくりくるのだ。 多分理由はいろいろあって、たとえば 一瞬で開ける いらなくな
タスク管理ツールの理想を追い求めた結果→自分で作った｜ガッシー｜Repsona
Repsona LLCの@GussieTechです。 タスク管理ツール、情報共有ツール、便利ですね！ これまでいろんな仕事で、いろんなツールを使ってきました。それぞれ、特に不自由もなく、乗り換えるほどのモチベーションもなく使い続けていたんですが、不満が全くなかったわけではありませんでした。 ・遅い ・ダサい ・わかりにく ・カンバンがない ・ガントチャートがない ・Wiki的なものがない ・なぜか仕事がうまく進まない ・SNSみたいな感じで、社員がもっと楽しくつながれたらおもしろそう ・スキルがレベルアップしてる様子とか、可視化されたらおもしろそう ・勝手に仕事してくれたりしないかな、AIとかで ・使ってたら無意識にPMBOKみたいになるように、レールが敷かれていると便利な気がする ・（ひどいコメントをしそうになったときに）「言葉にトゲがないですか？」とか、ボットがやんわり教えてくれるとか
権限を持つと人は偉そうになってしまう
最近配置転換があり、昇格してさまざまな権限を持つようになった。社内のほぼすべての書類を見ることができ、社員の管理ができ、各社員の給与を見ることのできる権限をもらい、予算の裁可権限までもらった。 権限を持つようになると「○○さんが知ってるよ」という情報をどこかから得てきた人が「お忙しいところすみません」というふうに声をかけてくるようになった。今までもそういう声かけは皆無ではなかったとはいえ、明らかに急増した。これが実に煩わしい。煩わしいので、一時しのぎの雑な対応になる。雑な対応になると「お忙しいところ申し訳ありません」というふうに声をかけられるようになる。権限がない人からすると、権限がある人になるべく早くやってもらわないと仕事が進まないのでどうしてもそうなるのだ。 そして、誰がどういう業務をやっているのかかなりハッキリ見えてくるようになった。これはすごい。まるで王様にでもなったかのような気持
書評「入門 監視」雰囲気で監視をやっているすべての人にオススメ | DevelopersIO
監視という一種マニアックな領域を真正面から解説した貴重な本です。監視で悩む人のみならずシステム開発に携わるすべての人にオススメ。 「全然わからない。俺たちは雰囲気で監視をやっている」 自分はAWS事業本部コンサルティング部所属ということもあって、いろんなお客様にAWSインフラのコンサルティングしてます。最初のインフラ構成設計時に監視の話をすることも非常に多いんですが、 「どうしましょう。CloudWatchでいけますかね？」 「MackerelとかDatadogとかもありますが、どうしましょ。マネージドとの違いは〜」 「とりあえず、ディスク使用率80%でしきい値設定しておきましょうか。みんなそうしてますよ」 とか言っていた昔の自分に見せつけたい本、それが今回紹介する「入門 監視」。 監視設計の原則がよくわかんない メトリクスのしきい値決めるところから監視を考えてしまいがち よく考えずに、い
linuxカーネルに関する独自コードをメンテナンスするコスト - Qiita
はじめに Linuxカーネル(以下カーネル)に機能を追加する、あるいはバグを修正する自作コードには次の2つの種類があります。 独自カーネルモジュールの作成 カーネル本体の変更 これらの変更を長期間メンテナンスするには次の方法があります。 Linux開発コミュニティに働きかけて独自コードを公式のmainlineと呼ばれるツリーにコードをマージする 独自コードを自分自身で管理して、mainlineカーネルの新バージョンが出るたびに追従する(後述) 本記事は前者の方法に比べて後者の方法をとった場合に必要なメンテナンスコストについて述べます。本記事の表題にはlinuxと書いていますが、linuxと似たようなドラスティックな変更(後述)を是とするソフトウェアすべてに当てはまる話なのでlinuxの開発には関係ないかたにも役立つ話かと思います。 独自カーネルモジュールを作る場合の追従コスト 昨日書いたエ
『怒らないからヤバいと思っていること全部言う会』の有用性について - ゆとりずむ
こんにちは、らくからちゃです。ぶらっとTwitterサーフィンしておりますとこんなツイートが目に留まりました。 「なんでもポジティブに考えれば幸せになれる」っての、まるっきりウソだから。現実のネガティブな側面を直視して受け入れることで、不安がなくなり、的確に現実に対処できるようになり、成功確率がぐっと高まり、はるかに幸せになれることなんて、いくらでもある。 — ふろむだ⭐️若い頃知りたかったこと書く (@fromdusktildawn) 2018年2月17日 すげーわかる。 確かに『すごーい』『たーのしー』と言いながらお仕事をしていても、ヤバめな何かを『あれ大丈夫なのかな・・・』『もしかしてヤバくない...？』と不安を抱えながらだと、全く楽しめません。 で、こうした不安を綺麗さっぱりしてお仕事を楽しむため、弊チームでは定期的に『怒らないからヤバいと思っていること全部言う会』を開催しているの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
