タグ

フラグに関するhiroomiのブックマーク (6)

  • あちこちでフラグを立てながらひたひたと近づく不動産バブル終焉の足音 : 市況かぶ全力2階建

    ジンゾウコワースの小林製薬、疑わしい死者が5人から76人に膨らむ一方で94人の遺族から紅麹サプリを飲んでないけど死んだと凸られる

    あちこちでフラグを立てながらひたひたと近づく不動産バブル終焉の足音 : 市況かぶ全力2階建
    hiroomi
    hiroomi 2016/12/25
    ”競売からの不動産叩き売り→不動産価値下落→不動産金融引締がずーっと継続して起こり、サブリース会社の破綻&強引な契約解除”
  • On Chromium Tree (to kzys) - WiT

    Google の巨大レポジトリとブランチ無し運用 に書いててあることを肴に雑談する試み。基的には kzys さん向けに書いてるので他の人には 文脈不足で誤解されそうだけどめんどくさいので特に補足しないで書きます。 ChromiumBundler みたいのを使っている。 Chromium は言うほど単一ツリーに閉じておらず、結構サードパーティのライブラリに依存している。 ビルド支援の glicent スクリプトは Bundler のしょぼいやつみたいな機能をもっていて DEPS というファイルが Gemfile(.lock) 相当。 この外部レポジトリのこのリビジョンをこの場所にチェックアウトしろと指示している。 Bundler というと大げさすぎで実際は git submodule くらいです。 代表的なところだと Blink, V8, Skia, WebP あたりはこうやって引っ

  • Google社内でのソースコード管理には「ブランチ」は使わない | スラド IT

    Googleが開催している開発車向けイベントGoogle Test Automation Conference(GTAC)にて、Google社内での開発手法について発表されていたとのこと(発表資料、発表動画、Google の巨大レポジトリとブランチ無し運用 — Kato Kazuyoshi)。 これによると、Googleでは40以上のオフィス、1万5000人以上の開発社、5000以上のプロジェクトが存在するそうなのだが、これらプロジェクトで開発されるコードはソースコード管理システム内の単一のツリーに格納されており、どのプロジェクトも同一のリポジトリを利用する形になっているらしい。さらに、ソースコード管理システムのブランチ機能は利用せず、コミットはすべて最新バージョン(head)に対して行われるルールになっているそうだ。 これにより、プロジェクト間での使用するライブラリのバージョンが統一でき

  • New community features for Google Chat and an update on Currents

    Join the official community for Google Workspace administrators In the Google Cloud Community, connect with Googlers and other Google Workspace admins like yourself. Participate in product discussions, check out the Community Articles, and learn tips and tricks that will make your work and life easier. Be the first to know what's happening with Google Workspace. ______________ Learn about more Goo

    New community features for Google Chat and an update on Currents
    hiroomi
    hiroomi 2013/08/07
    「とりあえず作ってみて、使い始めてから徐々に改善していく、という方が現実的でスピードも早い。何しろ、延々とAPIを議論をする代わりに、さっさと製品に機能を追加してリリースできるのだ。」
  • 第3回 ブランチvs.フラグ | gihyo.jp

    とっておきの変更 ソフトウェアをいつでもリリースできるようにしろと求める継続的デリバリの広まりにより、毎日のようにソフトウェアがリリースされるようになりました。早いうちからコードを野にさらせば、隠れた問題を前もって見つけることができるからです。 短いリリース間隔に身を置くと気づくことがあります。「⁠リリースできること」と「リリースしたいこと」は、必ずしも一致しないのです。たとえば大規模なビジュアルデザインの変更やとっておきの新機能を想像してみましょう。こうした粒度の大きい変更は、たとえ動作する、つまりリリース可能な状態でも、そのまま衆目にさらしたいとは限りません。期待を裏切らない形でお披露目したい、とっておきの変更があります。息を飲む新しい体験がもたらすユーザの驚きや喜びも、ソフトウェアにとっては大切な財産だからです。 とっておきの変更を仕上げるには時間がかかります。一方で、その仕上げが終

    第3回 ブランチvs.フラグ | gihyo.jp
    hiroomi
    hiroomi 2013/08/06
    "「リリースできること」と「リリースしたいこと」は,必ずしも一致しないのです。"
  • Google の巨大レポジトリとブランチ無し運用 - Kato Kazuyoshi

    GTAC 2013 Opening Keynote の Evolution from Quality Assurance to Test Engineering (スライド) を見た。 スライドの7ページ目 によると、Google では 15,000 あまりの開発者が、40 あまりの拠点に分散している。そして、彼らはひとつの巨大なレポジトリで、ブランチなしに開発しているらしい。 Single monolithic code tree with mixed langauge code Over 100 million lines of code. 50% of code changes monthly. Development on one branch - submissions at head 講演ではこの理由について One of the benefit is that we don’

    hiroomi
    hiroomi 2013/08/06
    「様々な機能ごとのモジュールがあるが、全部同じレポジトリにコミットしている。」
  • 1