はてなブックマーク

『Driving Value with Sprint Goals』は、スクラムのスプリントゴールに絞ってまるまる1冊書かれた本です。 不確実性とプランニング 第1章では非常に重要なことが述べられています。「手前の霧」と不確実性を霧というメタファーで表現していますが、ソフトウェア開発においても霧に覆われた状況に置かれることがままあります。この時に本物の霧に対してはやらないのに、何故かソフトウェア開発では、霧が存在しないかのように振る舞ったり、霧を取り除こうと考えたり分析したりできると信じたりしてしまうことがある、と指摘しています。実際に目前を霧に覆われた状況に置かれたら、計画を立てるよりも、慎重に進んでみて新しく明らかになった情報を元に次の行動を判断する。それを繰り返すはずだ、と。これは非常に秀逸な喩えだと思いました。 不確実性や複雑性に遭遇したときに、人はそこに解決策があると考えるために、

Functional Design: Principles, Patterns, and PracticesClojure読書感想文SOLID原則 クリーンコードやクリーンアーキテクチャなどの「クリーン」シリーズでお馴染みのUncle Bobの新刊です。クリーンは書籍タイトルに付きませんでした。 本書は関数型プログラミングに関する書籍ですが、関数型プログラミング言語と聞いて、真っ先に皆が思い浮かべるものではないであろうClojureを取り上げて、一貫してこれとオブジェクト指向プログラミング言語との比較がされています。 これは読み進めていくと、オブジェクト指向言語としてはC++やJavaを用いて、Clojureのコードを対比していくという構図を随所でとっており、これらとできるだけ距離の遠い言語を選びたかったのだな、というのが分かります。Clojureは関数型であり動的型付け言語です。この２つ

Kent Beckの最新作Tidy First?は、リファクタリングよりも小さな単位でコードを整理するやり方を記した本です。これをTidying（本記事では「片づけ」と呼びます）と呼んでいて、リファクタリングのサブセットと定義付けています。なので片づけはコードの振る舞いは変えないことはリファクタリングから継承します。 Tidy First?はこんまりメソッドの影響も少なからず受けてそうです。 Tidy First?を書いた背景には、リファクタリングが機能開発を止めて行うようになったり、振る舞いを変えてしまうようになったことがある、とKent Beck自身が本書の中で述べています。 最近のKent Beckの講演は、Tidy First？に関連するものになっています。最新は、DDDEUのイベントの講演で第３部の内容が中心に語られています。なおKent Beckのプレゼンは、スライドは用意せず

ScalyrブログのMicroservices Logging Best Practicesの抄訳に、いくつか補足を加えたものです。 一意のIDをリクエストと関連付ける 複数のサービスの呼び出し関係をトレースできるように一意のIDをリクエストに含めます。 ZalandoのRESTful APIガイドラインをみると、X-Flow-IDというHTTPリクエストヘッダを付けるように規約化されています。 Microsoftにも「マイクロサービスの設計: ログ記録と監視」というガイドがあります。 一意のIDをレスポンスに含める レスポンスのペイロードにも一意のIDを持っておけば、問題が発生したときに、カスタマからの連絡にも即座に対応できるようになります。 Spring Cloud Sleuthは、それらのコンセプトと実装も提供しています。 https://github.com/spring-clou

JavaのプロダクトでDockerイメージを作る場合、docker build時にmaven実行してもよいのですが、時間がかかるし、runtimeで必要のないアーティファクトもダウンロードされるので、イメージが大きくなってしまいます。 そこで、CircleCIでビルドして、作ったJarをダウンロードして実行するDockerfileにすると楽ちんでビルドも速くイメージサイズも小さくすみます。 Uber JAR or Zipを作る 依存ライブラリも全部含めたJarを作るには以下のようにshadeプラグインを使うと簡単です。ManifestResourceTransformerを使ってmainClassをMANIFESTファイルに含むようにすれば実行可能Jarにもなります。 <plugin> <groupId>org.apache.maven.plugins</groupId> <artifac

対象読者 2つの疎結合なシステム間を、メモリを大量に使っちゃうような大がかりな仕組みなしで、ほぼリアルタイムにデータロスなしに同期させたい、そういうアーキテクチャが欲しい方。 動機 Microservicesを疎結合に保ちつつ、バッチ処理やレポート機能でのクエリの高速化のため、データを同期させたいことがままあります。このあたりの話は、テキストの「5章 モノリスの分割」に載っています。 あるサービスから、データを定期的に吸い上げて、別のサービス、ツールに送るデータポンプという仕組みがあります。 イベント駆動でメッセージを関連サービスに送るイベントデータポンプや、バックアップツールを使って高速にデータ転送するバックアップデータポンプが紹介されていますが、結果整合性だけどなるべくリアルタイム(Near Real-Time)で同期させたいとなると、イベントデータポンプな仕組みしか選択肢にはならない

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Cognitect社のNygardさんが10年ぶりに改訂したRelease It! 2nd Editionがまもなくリリースされます。内容は現在のベータ5版で全て書ききっておられるようなので、是非読んでみてください。 https://pragprog.com/book/mnee2/release-it-second-edition その中から4章の安定性パターンの概要をご紹介し、実際JavaのFailsafeライブラリを使った実装例を示したいと思います。 安定性のパターン Stability Patterns 分散システムや後続をブロッ

セッションIDやアクセストークン、はたまた業務上で使う一意の識別子など、いろんなところで一意のIDを生成しなきゃいけないケースが存在します。 そこで世間で使われているIDの生成方法について調べてみました。 選択基準 ID生成における要求として、以下の観点が上げられるかと思います。 生成の速度 大量にデータを短期間で処理し、それらにIDを付与する場合、ID生成そのものがボトルネックとなることがあります。 推測困難性 IDを機密情報と結びつける場合、IDを改ざんされても、機密データが見れないようにできている必要があります。 順序性 採番した順にデータをソートする必要がある場合は、IDがソートキーとして使えないといけません。 それぞれについて各生成手段を評価します。 ID生成の手段 データベースの採番テーブル 採番用のテーブルを作り、そこで番号をUPDATEしながら取得していくやりかたです。古い

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

この半年間、久しぶりに開発チームのマネージャ的な立場もやることになったので、「ふつうの受託開発チームのつくりかた」以来、工夫したことをまとめておきます。「ふつうの受託開発チームのつくりかた」未見のかたはぜひそちらも見てみてください! チームに名前を付ける 私の受け持つチームは伝統的に「ラスカル」の名を付けるようにし、チームのアイデンティティを保つようにしています。チームメンバも本当は出来るだけ長く担当してもらいたいのですが、大きなSIerだとそれが難しいこともあります。 通常のプロジェクトチームだと、サブシステム名くらいで呼ばれることでしょう。これは、そのプロジェクトが終わったらチームも終わり、で帰る場所も無くなることを意味しますし、愛着をもって働くことは難しくなります。 メンバが多少入れ替わっても、チームは継続する"モーニング娘。方式"であれば、またいつか戻ってくることもできるし、OBと

The DevOps Handbookが2016年10月に発売になりました。これを読んで、SIerが開発対象とするようなエンタープライズ領域において、DevOpsは価値があるのかどうか、考えてみます。 The DevOps Handbookでは、DevOpsの目的を以下のように定めています。 開発者は生産性向上というとプロセスタイムの短縮にばかり目がいきがちだが、リードタイムをいかに短縮するかの方が、顧客にとっての価値であり、それがDevOpsの目的である。#DevOpsHandbook — :SIer/kawasima (@kawasima) 2016年10月19日 リードタイムとプロセスタイムの違いは、以下のような定義です。 実際にDevやOpsのタスクを実行している時間は、プロセスタイムです。それ以外の時間も短くする努力が必要です。 SoRとSoE SoRとSoEというシステム分類が

テスト計画をどう立てていくか、ふつうのシステムエンジニアにとって分かりやすく考えてみたいと思います。 テスト工程は、一番ざっくりした分類で単体テスト、結合テスト、システムテストに別れるのが一般的です。 この工程は、あくまでもV字モデルに対応したインプットがどの前工程で作られたものを検証するかの基準であって、実際にどういう観点をどういう手順でテストするか、はそれぞれのプロジェクトで計画します。それがテスト計画になっていきます。 しかし、ただの工程の話と、実際におこなうテストの内容の違いが分かっていないと、テスト計画何するものぞ状態になって、ろくなテストが実施されないことになりますし、そのようなプロジェクトも多く存在します。 テストの世界標準には、ISO/IEC/IEEE 29119があり、これを見るとテスト工程(Test Level/Phase)とテスト種別(Test Types)の組で、テ

エンタープライズの現場でJUnitテストを書きましょうとプロジェクトを進めてみると、大量のテストコードが出来上がって、CIのジョブが1時間ちかくかかるようになってしまった、なんてことを聞いたことがあります。 これらを速くしようとテストコードをチューニングしたり、ジョブを分けてスレーブで実行しようとしたりするのはわりと骨の折れることです。またスレーブマシンもたくさん用意しなくてはならず、受託開発においてはそんな予算は無いことが多いので、-Dmaven.test.skip=trueというクスリに手を染めてしまうプロジェクトもあるようです。 そんなプロジェクト向けに、準備が非常に簡単で安価に分散実行できてしまうTestStreamerなるものを開発しました。 といっても作ったのはわりと昔です。 http://www.slideshare.net/kawasima/test-streamer 以前

マイクロサービスアーキテクチャの5章は、モノリスをどうやって分割していくかが焦点です。サービス間での依存関係をできるだけ断つために、共有データや共有テーブルを避け、分割していくやり方が書かれています。 モデリングの観点からは、記述が不足なところがあって、現場のモデルに照らし合わせて考えることが難しいので、これをもう少し掘り下げて考えてみます。 データモデリングの手法としては、拙作のイミュータブルデータモデルが前提となりますので、未見の方はそちらをまずご参照ください。 エンティティは、リソース系とイベント系の2種類に大別するので、これらの関連の種類で言うと、R-R, E-R, E-Eの3つあります。これを順に分割するとどうなるかを考えます。 これらの呼び方はTM手法に準じます。 http://tmdmaker.osdn.jp/doc/ch08.html リソース-リソース(R-R) 強い依存

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Antifragileは、タレブが2012年に書いた本で、社会経済学の分野の内容ですが、他の分野においてもその考え方は有効ではないかと多くの記事や論文があります。ソフトウェア開発やアーキテクチャにどういう影響を与えていきそうかを考えてみます。 アンチフラジャイルの投資的側面 もともとはアンチフラジャイルとは、相場が動いたときに悪い方に転んでも損失はそこそこに抑えられるが、良い方に転ぶと指数関数的に大きな利益を得るということを意味します。 アンチフラジャイルな投資方法としては、プットオプションが鍵と言われています。 伝説の投資家シリーズ1

先日、マイクロサービスの呼び出し方として、オーケストレーションとコレオグラフィについて書きましたが、同じく4章では、どうHTMLを組み立てるかという問題が提起されています。 ここもやや難解なので、咀嚼を試みます。 課題設定 次のようなECサイトを考えることにします。そして、4つのマイクロサービスを合成して構成します。 商品カタログサービス ショッピングカートサービス ショップサービス リコメンドサービス API合成 無垢な気持ちで設計すると、各々のマイクロサービスがWeb APIのインタフェースをもち、XMLやJSONを返して、ECサイト側で、テンプレートエンジンなどを用いて、HTMLをレンダリングするという方式になるかと思います。 そして、この形式でマイクロサービスを利用するサイト(アプリケーション)が増えていくと次の図のようになります。 これには、次の3つの欠点があるとされています。

マイクロサービスアーキテクチャの4章にオーケストレーションとコレオグラフィという話があります。 マイクロサービスを使ってアプリケーションを組み立てる側の、サービスの呼び出し方の違いです。 「マイクロサービス的に作ってるよー」というシステムでも、ここに特に疑問を持たず、ふつうにWeb APIたちを呼び、受け取ったデータでHTMLをレンダリングするというオーケストレーション方式で作られているのが多いのではないでしょうか? Sam Newmanは、それだと呼び出されるサービス側がドメインモデル貧血症になりがちで、呼び出す側にロジックが集まっていくことになると、書籍の中で述べています。 いったいどういうことでしょうか? 書籍中の例をちょっと変えて考えてみます。 マイクロサービスアーキテクチャでECサイトを作る(オーケストレーション編) ECサイトをマイクロサービスアーキテクチャで作ることを考えてみ

JDK9でいくつかImcompatibleな問題に直面したので、ここにGitHubのIssueから、各プロダクトで挙がっているJDK9の不具合ポイントをまとめていきます。 java.specification.versionの体系変更 JDK9からは、JEP 223にともない、バージョン番号の表記が変わりました。そして、システムプロパティjava.specification.versionの返す値も従来の「1.8」みたいな値から「9-ea」が返ってくるようになっています。 このため、HibernateValidatorでは、以下の箇所でArrayIndexOutOfRangeExceptionが出てしまっていました。 sun.misc.VMの廃止 Intellij IDEAで発生していた問題ですが、sun.*パッケージのいくつかはjdk.internalパッケージに移され、本当にJDK内部

現在ではSpring Bootの手軽さに軒並み飲み込まれた感がありますが、Javaのマイクロフレームワークはちょっとしたブームでした。 Javaのマイクロフレームワーク ― この新トレンドは見逃せない enkanは、RackやExpress.jsで実装されているミドルウェアパターンをJavaで実装した、現在ファーストリリースへ向け開発中の新しいマイクロフレームワークです。 Java9のREPLを活用して開発・運用を楽にする機能も実装(予定)です。 なぜ今さら新しいWebフレームワークを? Spring BootやJava EEは、高度なDIとたくさんのアノテーションでフレームワーク内部の動きはブラックボックス化されます。これを完全にブラックボックスのまま、実用的なWebアプリケーションを完成させるのは、実際のところ難しく、フレームワークの内部を覗きにいかなくてはなりませんが、これが結構ハマ

Clojure関連のことをブログがわりに書き綴ります。 ※ここでの発言はシステムエンジニアを代表するものであって、所属する組織は二の次です。 Follow

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

(学生や新入社員に「プログラミング、どうやって勉強したらよいのですか?」とよく聞かれるので書いてみました) サッカーのことは詳しく知りませんが、モウリーニョのいうところの「サッカーを上達するにはサッカーの練習をしなければいけない」は、プログラミング学習者にも当てはまるところが大きくあると思います。 独学でプログラミングを学ぼうとすると、本を読んでExampleを動かしてみたり、チュートリアルを実践してみたりすることが多いかと思いますが、なかなか身につかず途中で挫折することがよくあります。また、それでいざ業務で使えるものを作ろうとしても、なかなか手が動かないなんてこともよくあります。 私がよくやるのは、自分が学ぼうとする言語/フレームワークとは、別のもので実装された機能を移植してみる、というものです。 JavaのバイナリシリアライザであるFressianをClojurescriptで実装 h

本番と開発の環境の違いで、本番障害を起こしてしまった…という経験がないシステムエンジニアなど存在しないと思います。 どういう点で問題が起こり、どういう対策をすべきだったのか、経験をもとに書きだしてみます。 (ここで開発と呼んでいるのは、一応本番以外のステージング、テスト環境も含みます) ミドルウェア設定 Webサーバ 同時接続可能数(MaxClients) 開発環境では、あまり気にしないパラメータですが、本番では慎重に設定しないと次のようなトラブルを起こします。 MaxClientsが小さすぎて、システム間連携APIがタイムアウトしてしまった。 MaxClientsが大きすぎて、サーバのメモリが枯渇した。 本番でのトラフィックが正確に予測できなければ、デフォルトのままにしておいて、様子をみながらチューニング、の方が下手に設定するより事故が少ないように思います。 リライト コンシューマ向けの

リコメンド的なことをやりたいという要求はよくありますが、協調フィルタリングを持ちださなくてもよい(持ち出せない)ケースは現実的には多いと思います。ユーザを特定してその嗜好を取れなかったり、あまりリピートして使うものでないシステムだったり。 例えば、あるカレー屋さんはトッピングを多く選ばせることで利ざやを稼いでいます。そこでトッピングを多く選ばせるために、食券券売機におすすめの機能を付けたいと思いました1。 このケースでは当然ユーザの嗜好は分かりません。 高々50個くらいのトッピングメニューしかないので、「おぉこんなトッピングが存在したとは…」という発見があるわけでもなく、人気の組み合わせが分かれば、十分販促に繋がると思います。 こういうパーソナライズしないリコメンドには、伝統的なマイニング技術のアソシエーションルールが良さそうです。 このアソシエーションルールを作るのを、SQLだけでやると