開発チームの責務を「エンジニアリング観点でのサービス継続リスクをコントロールしながら、開発速度を最大化する」としてみた話 - $shibayu36->blog;
最近開発チームの改善を行う時に、どういう目的で開発チーム改善を行うのかや、開発チームの責務は何なのかについて悩んでいた。色々本を参考にしながら、自分の中でしっくり来た責務があったので、ブログにまとめておく。 まず自分の中で、開発チームの責務は次のものであると言語化した。 エンジニアリング観点でのサービス継続リスクをコントロールしながら、開発速度を最大化する なぜこの責務としたか まず現代のソフトウェア開発においては、非常に不確実な状況で、顧客にとって価値があるものが何かを探索しながら、高速に価値を創出・提供しなければならない。これを満たすためには、「正しいものをつくる」ということと、「正しくつくる」ということの両輪を回す必要がある。 この時、プロダクトオーナー側と開発チーム側で分業するとすれば、やはり開発チームは「正しくつくる」ことに焦点を当てて責務を持つと良いと考えた。つまり開発速度(価
ioドメイン障害を理解するため、DNSの仕組みについて勉強した - $shibayu36->blog;
先日、ioドメインの障害があったのだけど、自分がDNSの仕組みをよく分かっていないせいで、いまいちどういうことが起こっていたのか把握できなかった。そこで、DNSの仕組みについて軽く勉強したので、そのメモを残しておく。内容は間違っているかもしれないので、その場合は指摘してください。 DNSについて学んだこと Software Design 2015/4のDNSの教科書が非常に勉強になった。また、 インターネット10分講座：DNSキャッシュ - JPNICも参考になる。 権威サーバとフルリゾルバ まず、DNSサーバには権威サーバとフルリゾルバの二つの種類が存在する。 権威サーバ ドメインの情報を管理し、自分の管理しているゾーンの情報を提供するだけのサーバ 問い合わせたドメインが自分のゾーンの管理下ではない場合、別の権威サーバへ委任するという情報を返す コンテンツサーバとも言われる? 例) co
会社は儲けるためにあるのか - $shibayu36->blog;
以前、「会社は儲かればいいのかもしれないけど」というワードを聞いたことがあって、今から考えるとそうではないんじゃないかな―と思ってきたので、適当にメモとして残しておく。 今のところの個人的な意見としては、会社は儲けるために存在するのではなくて、社会的に価値を提供するために存在し、そして社会的に価値を提供した結果、自然と儲かるだけであると考えている。ただし、以下の様なことから少し問題を複雑にしているとは思う。 社会的に価値を提供し続けるためには、儲かっていなければならない 価値というのは、それが人に理解されなければ発生しない このへんの話いろいろ難しいのだけど、会社は儲けるためじゃなくて社会に対して明確な価値を提供するために存在していると僕は考えていたいし、その価値を提供し続けるために儲かっている状態を作り出さないといけないとも思う。ただし、これを逆転させてはならなくて、儲けるために会社の提
Hubot + Heroku + Slack - $shibayu36->blog;
Hubot触ってみようと思って、いろいろ動かして見たのでメモ。 参考になるURL https://github.com/github/hubot/tree/master/docs http://nanapi.co.jp/blog/2014/06/04/slack_with_hubot/ http://odoruinu.net/blog/2014/07/08/how-to-integrate-self-hosted-hubot-with-slack/ https://github.com/tinyspeck/hubot-slack Hubotのrepositoryを作る https://github.com/github/hubot/tree/master/docs これのとおりに hubot --create shibabotとかすると作れる。 bin/hubotとかして動けばひとまず良い
Docker, Mesos, Sensu等を利用したBlue-Green Deploymentの仕組み - $shibayu36->blog;
本番環境のBlue-Green Deploymentの仕組みのプロトタイプを作っていた - $shibayu36->blog; 開発合宿でDockerとMesosを使っていい感じにリソース提供とデプロイするやつを作ってた - wtatsuruの技術方面のブログ Docker + Mesos + Marathon + Graphite + Fluentd + Sensuを組み合わせたデプロイ管理ツールの話 - ゆううきブログ この辺に書いたとおり、id:wtatsuru, id:y_uuki, id:hagihala と一緒に、DockerやMesosなどを利用してBlue-Green Deploymentのプロトタイプのようなものを作っていた。この前は非常にざっくりと書いただけだったので、もう少し中身に突っ込んで書いてみる。かなり長くなったので時間があるときにでもどうぞ。 デプロイや運用の
モジュール作成からCPANに上げるまでの手順 - $shibayu36->blog;
この前WebService::Bitlyというモジュールを作ってCPANに登録したので、忘れないうちにそれを行なうまでの手順をメモしておきます。これからCPANモジュールを作る人の参考になればと思います。 0.いろいろなドキュメントを読んでおく 間違ったモジュールをCPANに上げると迷惑がかかるようなので、最低限下のドキュメントは読んでおいたらいいと思います。 PAUSE: The CPAN back stage entrance perlnewmod - 新しいモジュールを配布するには - perldoc.jp 1.モジュール名を決めて、ひな形を作る まずモジュールの名前を決めます。CPANモジュールは、「このようなモジュールはこの名前空間」のような慣習があるようなので、それを考えながら決めます。 名前が決まったら、モジュールのひな形を作ります。僕はModule::Starter::PB
福島原発以上に危険性のある高速増殖炉もんじゅで今起きていること - $shibayu36->blog;
いつもはこのブログでは、技術系の話しかしていないのですが、今回はちょっと変わって、今話題になっている原子力発電所の話を書きたいと思ってます。自分で調べてみると「高速増殖炉もんじゅって危ないな」ってことに気づきました。福島原発も難しいことになっていますが、もんじゅも現在も危険な状態になっています。それについてまとめてみました。 非常に長文になりましたので、時間があるときに読んでいただけるとありがたいです。特に福井県の方には自分たちの県のことなので読んでもらえたらと思います。 前置き まずこの内容について書きたくなった理由です。僕は福井県勝山市の出身で、福井県には多数の原子力発電所があります。これまでは原子力発電所については全く知識がなかったのですが、今回の福島原発での事故をきっかけに、やはり原発はある程度の危険性があるということに改めて気づき、原子力発電所について調べてみることにしました。そ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
