開発中の機能を小分けにして本番環境にどんどん出すためには - hitode909の日記
ふだんの開発では，稼働中のシステムに影響を与えないように開発中の新機能や新システムを共存させながらちょっとずつデプロイして進めている．どんな事を考えてやっているか記しておきます． フィーチャートグルを使う すべてのコードが本番環境に入っているけど無効化されている状態で開発を進める ブランチをたくさん作るのに対する考え方で，フラグを有効にすると開発中の機能を使える スタッフなら有効にしたり，フィーチャーのオンオフを選べる画面を作ってたこともある フィーチャーブランチを利用した開発はチームを継続的インテグレーションから遠ざける – ゆびてく FeatureToggle 完成したらフィーチャートグルに関係なく全員に有効状態にして完成 フロントエンドの施策で，実際のデータやインフラ構成でどれくらいスピードが出るかわからないときに，ひとまずフラグをオンにすると動く形でデプロイしたりとか レイヤの下の
【エンジニアリング組織論への招待】を10~15分で読めるように1万文字程度でまとめてみた - Qiita
■ はじめに エンジニアリング組織論への招待という本を読みました。 ジョブ理論 に続く名著でした。 理想に向けて、事業を最速かつ生産性高く成長させるには、「未来」と「他人」という2つの不確実性をマネジメントすることで、成し遂げられる ソフトウェア開発における不確実性のマネジメントには、不確実性に立ち向かえるチーム開発が何よりも重要である（ex. メンタリング、権限移譲、信頼関係、透明性） の2点を中心に、事業成長×組織の幸せに必要なフレームワークを提供してもらえるものでした。 ソフトウェア関連の事業やプロダクトに関わっている人（特にマネジメントしている人）は職種限らず読むと、みんな幸せになれそうなので、1人でも多くの人がこの概念に触れられるように、私なりの視点で雑多にまとめました。 （ちなみに著者の 広木さん - hiroki_daichi には個別にご連絡し、要約した本記事の公開許可は(
何のためにバージョンロックをするか | おそらくはそれさえも平凡な日々
外部ライブラリに依存する時に、どのようにバージョンロックをすべきかどうかという話。僕個人のスタンスです。 開発しているのがライブラリであれば依存ライブラリをバージョンロックをするべきではない 最低バージョンの指定に留めるべき(これは寧ろ積極的にやって良い) 依存ツリーが大変なことになってコンフリクトが避けられないため 実運用しているサービスやアプリケーション的なソフトウェアであればバージョンロックした方がいい これは「ある時点のビルドやリリースの再現性」のためが一番大きいと思っている 古いバージョンにとどまって良いというわけではない 基本的には、開発しているものがライブラリであれアプリケーションであれ、 とにかく依存先の最新についていく のが前提で、その前提に立った場合に、上のような考え方になるかな、と思っている。 特にライブラリ作者は依存ライブラリに非互換変更が入って動かなくなったら、頑
グローバル展開を支える量子的なサービス設計 #mercariday // Speaker Deck
Mercari DAY 2017の登壇資料です。
ソフトウェアの修正プログラムのことをなぜ「パッチ(当て布)」と呼ぶのか？
ソフトウェアやOSの不具合や動作の更新・修正を行なうアップデートプログラムのことを「パッチ」と呼びますが、なぜ「継ぎ当て用の布」を意味する「パッチ」と呼ばれるのかがわかるツイートが投稿され、注目を集めています。 And that, kids, is why we call it a "Patch". pic.twitter.com/zjiXGcS29A— Codealike (@Codealike) 上記のツイートはアメリカ初の電気機械式計算機「Harvard Mark I」に使われていた紙製のプログラムシートを撮影したもの。パンチ穴を読み取って計算を行なっていたため、もし穴を空ける場所を間違えた場合、プログラムシートに本当に「布」を継ぎ当てて穴を埋め、正しい場所に穴を空け直してプログラムの修正を行なっていたわけです。 布のパッチは後に「磁気テープ」になり、リムーバブルディスクドライブが普
エンジニアと健全なバトルをしてますか？ Increments 及川卓也が語る優秀なPMの条件 | キャリアハック（CAREER HACK）
及川さんがこれほどまでPMの重要性を語るのはなぜか。そして優秀なPMに求められる条件とは？ [プロフィール] 及川卓也 (Takuya Oikawa) Increments株式会社 Product Manager 早稲田大学理工学部卒業後、外資系コンピューター企業での研究開発、マイクロソフトでの日本語版・韓国語版Windowsの開発統括を経て、グーグルでプロダクトマネージャとエンジニアリングマネージャを務める。2015年11月より、プログラマのための技術情報共有サービス「Qiita」やドキュメントを軸としたコラボレーションサービス「Qiita:Team」を提供するIncrements株式会社にてプロダクトマネージャとして従事。エンジニアのキャリアプランニングやエンジニアリングマネージメントなどの領域で自社のQiitaやQiita:Teamの活用を軸としてスタートアップにアドバイスも行う。
Kaizen Platform, Inc. エンジニア行動指針
Engineering Teamの Akira MAEDA です。 今回はKaizen Platform, Inc.社内にあるエンジニア行動指針を紹介したいと思います。 このエンジニア行動指針は創業間もない頃に技術顧問のNaoya Itoが中心になって作成し、今から2年半ほど前にオフィスに遊びに行った私に、CTOのToshimasa Ishibashi、Naoya Itoの二人がKaizen Platformの実現しようとしている未来とともに熱心に説明してくれ、私のKaizen Platformへの転職のきっかけになったことを今でも思い出します。 以下内容 — - Kaizen Platform, Inc. エンジニア行動指針Message from CEO (Kenji Sudo)・ 我々はクラウドソーシングで新しい働き方を作り出していく集団なんだから、我々自身も新しい組織のあり方に挑戦
契約による設計の紹介 - Hatena Developer Blog
こんにちは、チーフエンジニアの id:hakobe932 です。 はてなでは毎週、社内技術勉強会を開催しています。先週の勉強会では現在開催中のはてなインターン2016の参加者のみなさんもインターン生も参加して、いっしょに技術交流を行いました。 このエントリでは、そこで発表した、契約による設計の紹介をしたスライドを公開します。 契約による設計はBertrand Meyer氏によるオブジェクト指向入門*1という書籍で紹介されている考え方です。 オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング) 作者: バートランド・メイヤー,酒匂寛出版社/メーカー: 翔泳社発売日: 2007/01/10メディア: 単行本（ソフトカバー）購入: 11人 クリック: 307回この商品を含むブログ (130件) を見る 契約による設計で
git blameによるSRP（単一責任原則）の定量化 - どこでも見れるメモ帳
はじめに ソースコードを静的解析することでSRP（単一責任原則）を定量的に算出します．*1 svn blameによるSRP算出*2を参考に、git blameによる算出をshで行ってみました． このSRP値が最大のモジュールが王様モジュールに相当します． # 単一責務性の違反指数（SRP） # SRP＝R＋U＋((L/100)－5) # R：修正リビジョンのユニーク数 # U：修正ユーザのユニーク数 # L：モジュールのライン数 function get_SRP() { local target_filepath=$1 echo $(( \ $(git --no-pager blame --line-porcelain $target_filepath | sed -n 's/^summary //p' | sort | uniq -c | sort -rn | wc -l) + \ $(
プロダクトマネジメント(あるいはオーナシップ)に関心のあるひとが集まるSlack Teamを作成した - Kentaro Kuribayashi's blog
プロダクトマネジメント、あるいはプロダクトオーナシップに関心のあるひとが集まるSlack Teamを作成しました。以下のページから参加できます。 Join Product Managers Japan on Slack! 追記: Product Managers JapanのWebサイトもできました。そちらも御覧ください → Product Managers Japan (PMJP) 昨今、プロダクトマネジメントに関心が集まっています。最近の盛り上がりは、Rebuildで語られたりなどによるものだと思いますが、しばらく前に出た『世界で闘うプロダクトマネジャーになるための本 トップIT企業のPMとして就職する方法』『プロダクトマネジャーの教科書』などにより、アメリカのWeb業界におけるその職能が紹介されてもおり、また、『スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB
いまさら聞けない「コードの英語」超入門 - クックパッド開発者ブログ
広告事業部の鈴木達矢です。コーディングをしてると変数やメソッド名の付け方に悩むことって多々ありますよね。逆にコードを読んでいると単語の選択がこれでいいのかなという時や、動詞の活用形が間違っていてよく意味がわからない、時に潔く日本語の変数名になっていることも見かけます。でもプログラミング言語の単語が英語をベースにしていますし、Railsを使っている場合は日本語が規約（Convention）に合わなかったりします(複数形が無いなど)。それから動詞の活用形が違っていると主語（動作の主体）が変わってしまい、意味が変わってしまいます。その結果コードの可読性が落ち混乱を招きやすくなります。 いくつかの基本的な法則だけおさえておけばコーディング中に可読性の高い単語の選択ができるようになります。今回はそれを目的に、英語の扱いに都度時間を費やしてしまうような方に向けていくつかの法則をご紹介します。*1 変数
OSS開発の活発さの維持と良いソフトウェア設計の間には緊張関係があるのだろうか? - t-wadaのブログ
YAPC::Asia Tokyo 2015 前夜祭に参加して、柴田さん（ hsbt さん）とモリスさん*1（ tagomoris さん）の講演を聴いた。特に最後のモリスさんの講演を聴いていて、ちょっとした衝撃を受けると共に、気づきや疑問もあったので、久しぶりに blog エントリを書こうという気になった。 なお、このエントリは講演メモや浮かんだ疑問、その後の議論等を記したものであり、すっきりとした結論は無いのでご注意。 モリスさんの講演 講演資料が公開されていた How to create/improve OSS products and its community from SATOSHI TAGOMORI 講演時に取ったメモがこちら 我々にできるOSSとそのコミュニティの育てかた ======================= id:tagomoris TD のモリスさん TD はデー
「秀丸」の秀まるおさん、そろそろMac版はいかがでしょう？ 気になることを全部聞いてみた。 | HRナビ by リクルート
Windowsでテキストエディタといえば、ほとんどの人が同じものを思い浮かべるのではないだろうか。もちろん「秀丸」である。いまも多くの人がPCをセットアップするときにまずインストールするソフトウェアの1つだ。 1990年代半ばに生まれ、20年以上にわたって使われてきている。開発者の斉藤秀夫さんは秀丸があまりに売れたため、当時勤めていた大企業を退職して独立した。元祖ソフトウェアスタートアップともいうべき存在である。 そんな斉藤さんにいろいろ聞いてみた。Mac版は出ないのか？ 秀丸御殿がたったのは本当？ いまはスタートアップが成功しやすい？ 自然体で答えてくれた斉藤さんのお話をどうぞ。 秀丸が好調で、「フェラーリに乗ってる」という噂も –「秀丸」シリーズの売上はピーク時で1億円を超え、「秀丸御殿」が建ったとか。 斉藤：Windows 95が出てきて世の中みんながWindowsを使うようになった
【後編】七転八倒の先に見出したCTO道――グリーCTOに、色々ホンネで聞いてみた / 飲み会で探るエンジニアのホンネ #naoya_sushi 編
＜前編のあらすじと後編のお話＞ 寒風吹きすさぶ師走の夜、伊藤直也氏（以下「naoya」）が寿司屋に招いたのは、かつての上司でもある『グリー』CTOの藤本真樹氏（以下「藤本」）。インターネット業界におけるCTOの第一人者であり、私淑するエンジニアも多いことで知られる藤本氏だが、焼酎片手に語り出したのは、かつてマネジメント業務で四苦八苦したという反省の歴史。CTOとしての藤本氏の“凄さ”を知る伊藤氏にとっては意外な話のオンパレードで、会話のボルテージは時とともに高まっていくのであった――。 ⇒【前編】の記事はこちら さて、今回の後編では、藤本氏のCTOとしての取り組みをさらに深掘りすることで、いかにして「CTOとはかくあるべし」と開眼するにいたったのかを明らかにしていきます。実は生魚が苦手という藤本氏ですが、今のところは料理も愉しんでいただいている様子で一安心。ぼちぼち酔いもまわってきて、二人
ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
GPL違反による「被害」、救済策は？ | スラド オープンソース
GPLv2に違反した場合の判例は非常に少なく、最も重要な条項のほとんどについては実質的に判例がないという。Versata SoftwareとAmeriprise Financialなどの間で争われている関連する5つの訴訟で 1) GPLv2違反の被害者に対する救済策は何か、2) GPLv2において責任の生ずる「配布」とは何か、3) GPLv2は特許のライセンスを含むか、4)プロプライエタリーコードとGPLv2コードをどのような形で統合すると「派生著作物」となり、プロプライエタリーコードがGPLv2の支配下に置かれるのかといった点について裁判所の判断がでる可能性があるとのこと(OpenSource.comの記事、 本家/.)。 訴訟のいきさつとしては、初めにVersataがAmeripriseにライセンスしたDistribution Channel Management(DCM)ソフトウェア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
似非サービスクラスの殺し方 / #ginzarb
快適なサービス開発を支える技術/Cookpad TechConf 2017
エンジニアが納期を守れていないとしたら、そこにはいったい何があるのだろう？（あるいはいったい何がないのだろう？）
統計的品質管理の功罪
