マイクロサービスアーキテクチャ - たけぞう瀕死ブログ
仕事でマイクロサービスっぽいことをやっており体験から学ぶ部分も多いのですが、翻訳版が出ていたので知識の整理という意味で読んでみました。 マイクロサービスアーキテクチャ 作者: Sam Newman,佐藤直生,木下哲也出版社/メーカー: オライリージャパン発売日: 2016/02/26メディア: 単行本（ソフトカバー）この商品を含むブログを見る マイクロサービスに必要な技術基盤 結論から言えばマイクロサービスアーキテクチャを採用する上で必要となる技術的な基盤について浅く広く抑えられています。ところどころで著者の体験談やNetflixでの事例などが紹介されており、成功・失敗パターンの例として参考になります。 また、マイクロサービス固有の話ではないものの、セキュアでスケーラビリティの高いシステムを構築するためにエンタープライス業界で培われてきた技術基盤やノウハウについての解説もあり、特にこういっ
日本一のイノベーション誕生の背景には○○があった
「再生しかできないのに、売れるわけがない」 「再生しかできないのに、売れるわけがない」――今の若者が聞いたら「？」と疑問に思うかもしれません。ソニーの「ウォークマン」が生まれる前、音楽を聴くのは家庭や車の中に置かれたテープレコーダーが主流でした。つまり、再生だけでなく、録音機能が搭載されていることが“当たり前”だったのです。 当時のソニーの名誉会長、井深大氏もポータブルタイプのテープレコーダーで音楽を楽しんでいました。しかしポータブルと言えども当時流通していたものは重い肩掛けタイプ、海外出張などに携帯するにはとても不向きです。小型のものもありましたが、全てモノラル再生。そこで、録音機能を取っ払って、ステレオ再生機能のみを搭載した小型品を作れないか、と、テープレコーダー事業部に持ちかけます。 それを“二つ返事で”受けたのが、当時テープレコーダー事業部長だった大曽根幸三氏でした。いわば会長の“
実践テスト駆動開発(GOOS)読んだ - Qiita
実践テスト駆動開発を読んだ（和智さんいい仕事、ありがとう！）。 タイトル(GOOS = "Growing Object-Oriented Software, Guided By Tests")に、「テスト（TDD）」と「オブジェクト指向（Object-Oriented）」と「育てる（Growing）」が入っていて、ずっと読まなきゃと思っていた。出たときに角谷さんに「これは！」、と薦められたのに、機会を失っていたけど、最近、astahの開発でテストに悩みがあって読んでみた。 外から攻めるか、内からか テストを書いてプロダクトコードを育てていくという話なのだが、内側のテスト（ユニットテスト）と外側のシステムテスト（受け入れテスト、システムテスト、エンド・トゥ・エンド(E2E)テスト)をどっちを先に書くべきかいつも悩む。外側のテストを書いて、内側に進んでいくのか、内側から組み上げるか。設計の方向
日本と米国で異なる「想定する物量」がソフトウェア開発の生産性の違いを生む - メソッド屋のブログ
私は米マイクロソフトの DevOps のインターナショナルチームに所属しています。ただ、住んでいるところは日本なので日本側のオペレーションも実施しています。 前回のブログでも書いた通り、私はどうして米国のエンジニアが生産性が良いのかをずっと知りたいと思っていたし、今も研究中です。この２つのチームに同時に見えてきたことがあり、彼らの生産性の良さの一端に気付いたのでブログにして残しておきたいと思いました。 見えてきた「物量」の違い 私がインターナショナルチームと一緒に向こうでしているときに、仕事でアップアップになったことはありませんが、日本だとしょっちゅうです。日本のMSもはっきり言って過去に私が所属したどの会社より相当効率的で無理がないのですが、それでも存在するこの差はいったい何でしょうか？いくつかの事例を通じてだんだん見えてきたことは１つのことをこなすための「物量」が違うということです。
Ed Yourdon の『ソフトウェア工学で大切な１０の考え方』を訳しました。：An Agile Way：オルタナティブ・ブログ
先日、尊敬するエドワード・ヨードン博士が「Top 10 Software Engineering Concept」という文書の公開した、とtwitter でつぶやいていたので、「訳してもいいですか？」と聞いて、5分でOKをもらった。なんというインターネット時代だろう。 slideshare で見る PDFをダウンロード 原文を見る ヨードン博士の動機は、 不況時代に突入し、今後デスマーチが一気に増えるであろう。でも、ソフトウェア工学の大切な考え方は、そんなに昔から変わっていないんだ。新しい世代は、すごいよ、学生はみんなIMで会話して、Facebookで繋がっている。COBOLプログラマがまだ存在しているなんてことは知らないんだ。でも、ソフトウェア工学の大事なことは、なんども新しい世代が、同じ事実を発見し、過去の重要な論文や書籍にぶち当たる。ここで１０個上げて、フリー文書にしておくので、共有
Electronでデスクトップアプリを簡単構築
全国5000人のエンジニアをやめて寿司職人になろうと思っているみなさんこんばんは。 前回までスライド共有用のアプリケーションを趣味(リハビリ)で作っていたのですが、折角なのでデスクトップクライアントも作ってみました。 構築にはElectronを使ったのですが、結構簡単にできたので記録としてまとめておきます。 Electronって何？GitHubが開発するクロスプラットフォームで動作するアプリケーションを開発するためのフレームワーク。コードの記述はHTML5とNode.js。その範囲であれば既存のWeb開発技術が使いまわせる。例えばjQueryとかAngularなんかを使うのも可能Chromeブラウザのオープンソース版のChroniumのエンジンを内蔵例えばAtom・Visual Studio Code・Slackクライアントや、日本だとKobitoあたりがメジャー作り方あちこちに記事があが
Git（GitHub）の運用で気をつけていること - えいのうにっき
ある日、 PR の内容を見ずにマージすることを岡島（ピッチャーの）というらしい 笑った— いのうえ (@a_know) 2015, 9月 10 ということで、脳天気に笑っていたら、 @a_know むしろイキナリmasterリポジトリに直接pushするパターンですね！— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 という話になり、そしてなぜだか、 @a_know push -fと同様、Gitの運用アンチパターンとかどこかに纏めがほしいですねー。 #ブログ待ってます— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 というはなしになったので、本当に必要として頂いているのかどうかはともかく、 Git / GitHub でぼくやぼくの職場で気をつけていそうなことをまとめてみる。 もくじ もくじ GitHub Flow に沿って開発する 基本
ノウハウの共有文化がない場所にコードレビューをねじ込んでみた結果とか - タオルケット体操
「コードレビューをキメると品質も上がるし自分のレベルも上がるので最高」みたいな論が巷を賑わせていて、以前はそういうイケてる制度を指をくわえてみるのみだったのだけれど、最近職場と、それと個人的に関わったプロジェクトでコードレビュー制を無理矢理交渉して導入してみた結果、世間のイケてる書籍やエントリから得られる情報とはまた少し違う知見が得られたので書いてみる。 割と泥臭かったり、あまり希望に溢れてたりはしない感じのエントリなのでそういうのは期待しないほうがいいです。 準備 些末なコードレビューを極力避けるために、コードの規約やスタイルについてはlintとフォーマッターを用意した。 他は無策。 結論 結論から言うと、理想的な運用は出来なかったものの、コードレビューについて世間で言われるような成果（作業を共有する意識、レベルの向上）は得られた。良かった。 ぶっちゃけ僕なんかが浅はかな考えで導入しても
OpenShift 3.0で既存コードを捨てコンテナーに賭けるRed Hat
OpenShiftはRed Hatが展開するPaaSのプラットフォームだ。これまで日本のレッドハット株式会社からはあまり積極的に日本市場に展開しようという動きは少なく、IBM、HPが自社のPaaSとして採用したPivotalのCloud Foundaryに後れをとっていたといっても過言ではない。 そんな中、2015年1月28日にレッドハット株式会社が「次世代PaaS - OpenShift Enterprise紹介セミナー」と題したセミナーを開催した。 米国本社からOpenShift製品の責任者、アシェシ・バダニ氏と製品技術マネージャーのクリス・モーガン氏が来日し、OpenShiftの次のバージョン、V3.0を紹介。最近、注目が高まっているDockerとKubernetesによるコンテナー技術をコアにした全く新しいアーキテクチャーによる新バージョンを解説した。 クラウドコンピューティングが
本の虫: Bazaar-NG: 分散バージョン管理システムを7年ハックしてきて
Bazaar-NG: 7 years of hacking on a distributed version control system Bazaarの開発者が、Bazaarが失敗した理由について、当時を振り返って書いている。なかなか面白い。 Bazaar-NG: 分散バージョン管理システムを7年ハックしてきて この7年間、筆者はBazaarプロジェクトに関わってきた。筆者はプロジェクトから距離を置き始めている今この時、筆者のこのプロジェクへの関わりや、何が良くて何が悪かったのかの意見などを、振り返ってみるべきだと思う。 この回顧録には多くの複雑な詳細が出てくるので、筆者の誤りもあるかも知れない。間違いを見つけたら知らせてくれ。 黎明期 < ddaa> dscmsには2種類ある。古臭いやつと、実験中なやつ。 2004年、筆者は、 SambaのコントリビューターであるMartin Pool
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 はデー
新人エンジニアが知っておきたい優れたエンジニアになるための5つの心構え | Social Change!
生放送で無料授業を受けれるschooで、『新人エンジニアが知っておきたいアジャイル開発』というお題で、授業をする機会を頂きました。 この授業では、ウェブサービスやアプリの開発に携わる新人エンジニアの方を対象に「アジャイル開発」についての概要と、実際の事例を元に学ぶことが出来るようにお話したつもりです。以下が、そのときの資料です。 この記事では、授業の後半でお話しした内容から、新人エンジニアが今後アジャイル開発の現場で求められる姿勢について、改めて書いてみました。 アジャイル開発に限らず、エンジニアとして優れた人は、エンジニアリングをマスターしていることは大前提として、その上でビジネスや世の中に対して成果を出しています。 これまで多くのエンジニアの方と知り合って一緒に仕事をしてきた経験から、そうした人たちが持っている共通の姿勢を５つ洗い出してみました。 当事者意識を持つ これはエンジニアに限
topコマンドで覚えておきたい使い方14個 | 俺的備忘録 〜なんかいろいろ〜
topコマンドといえば、よくLinuxのパフォーマンス状態をモニタリングするために利用されているコマンドだ。 今回は、そんなtopコマンドで覚えておきたい使い方14個を紹介する。 なお、検証で使用したtopコマンドはCentOS 7 で利用している「procps-ng version 3.3.9」のものとなっている。 1.基本的な使い方 基本的には、オプション無しで以下のようにコマンドを実行する。 top top - 07:21:06 up 4 days, 17 min, 4 users, load average: 0.00, 0.00, 0.00 Tasks: 186 total, 1 running, 185 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0
astahチームの開発を支える技術 – 開発の流れとツール利用の関係を整理する –
こんにちは。製品事業部の近藤です。今回はastahチームの開発プロセスを改善する開発ツールの使い方を整理することで、astahチームの開発をどう改善したのかを紹介します。1 前回はastah*チームの開発にHubotを取り入れたことを紹介しました。これにより、定時連絡など、プロジェクト運営で自動化したい細かな事はHubotにお願いできるようになりました。また、各サービスからチャットに情報を流す事で、Hubotを介したサービス間連携を実現できます。HubotはJavaScriptで拡張できるので、調整も簡単です。 では、なぜHubotを導入したのでしょうか？今回はHubotの導入理由や、どのサービスを連携させたら効果的なのか、分析した時のポイントを紹介します。 Hubot導入前の問題 Hubotを導入する前のAstahチームには、開発ツールの使い方をよく間違えてしまうメンバーがいました。Gi
なぜスクラムでは不十分なのか
巨大で複雑なシステムを開発し、レガシーコードを扱うとき、企業は統合とデリバリを支援するシステムが必要だ。モジュール化はアジャイルが複数のチームで並列に働きならがスケールするのを助ける。この仕事をするのは、フレームワークや方法論ではない。Hans Dekkers氏によれば、問題解決のためにチームのメンバがどのように働くか、が重要だ。 Bits&Chips Software Engineeringカンファレンスは6月3日にオランダのアイントホーフェンで開催され、3つのセッションがあった。スクラムでは不十分というセッション、そして、デリバリトレインをブーストする、実世界のモデル駆動エンジニアリング、という3つのセッションだ。アムステルダム大学の情報学研究所で講師をしながら、マネジメントコンサルタントもしているHans Dekkers氏は最初のセッションを仕切った。 スクラムは小さなチームでうまく
TechCrunch
In an attempt at damage control, the CEO of the equity management startup Carta, Henry Ward, today emailed customers, telling them that if they are concerned about “negative press” tied to the out In the Lego-like world of Roblox, about a hundred blocky avatars march through a lamplit street, wielding Palestine flags that are larger than their own animated bodies. Characters dressed like cartoo
チーム開発の進め方 - クックパッド開発者ブログ
こんにちは！クックパッド編集室メディア開発グループ長の @yoshiori です。 今回はウチのチームの開発の進め方や見積もりの仕方を説明しようと思います。 実はコレ系の話は 5 年前にもデブサミで発表 したのですがこの時はリリースまで 1 年とかのレベルのプロジェクトの進め方の話でした。今回は 1,2 ヶ月でリリースまで持っていく開発の進め方を説明します。 動画サービス部分を microservices 化するときに実際に行った事を元に説明します。開発者は 3 人で 1.5 ヶ月位の開発です。 何故このようなことを行うのか 誰だって楽しく仕事がしたいし、なるべく不安などは無い方が良いはずです。 例えば自分がやっている作業がどうなったら終わりなのかわかっていなければ不安でしょうし、いつまでに作ればいいのかわかっていなければ不安でしょう。 そういった不安をなるべく無くすためにうちのチームでは
トヨタの車のソースコードはスパゲッティコード山盛り？ - YAMDAS現更新履歴
Toyota Unintended Acceleration and the Big Bowl of “Spaghetti” Code | Safety Research & Strategies, Inc. O'Reilly Radar で知った記事だが、この記事自体は2013年、トヨタがオクラホマ州での急加速を巡る訴訟で和解した後に書かれたものである。 この記事で面白いのは、Michael Barr が20ヶ月以上にわたりトヨタ車で使われているソースコードを、Philip Koopman カーネギーメロン大学教授がトヨタのエンジニアリングの安全プロセスを精査した話で、両者ともトヨタのソフトウェアがスパゲッティコード山盛りなことを証言している。 トヨタの生産方式はアジャイル方面においてソフトウェア開発手法に多大な影響を与えている。ところでそのトヨタが開発するソフトウェアの品質はどうなんだ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://qiita.com/shin_semiya/items/a2c0339d2a5e32eaf7db
Googleでの長期にわたるエンジニアリング
