サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
中東情勢
qiita.com/kawasima
『Driving Value with Sprint Goals』は、スクラムのスプリントゴールに絞ってまるまる1冊書かれた本です。 不確実性とプランニング 第1章では非常に重要なことが述べられています。「手前の霧」と不確実性を霧というメタファーで表現していますが、ソフトウェア開発においても霧に覆われた状況に置かれることがままあります。この時に本物の霧に対してはやらないのに、何故かソフトウェア開発では、霧が存在しないかのように振る舞ったり、霧を取り除こうと考えたり分析したりできると信じたりしてしまうことがある、と指摘しています。実際に目前を霧に覆われた状況に置かれたら、計画を立てるよりも、慎重に進んでみて新しく明らかになった情報を元に次の行動を判断する。それを繰り返すはずだ、と。これは非常に秀逸な喩えだと思いました。 不確実性や複雑性に遭遇したときに、人はそこに解決策があると考えるために、
Functional Design: Principles, Patterns, and PracticesClojure読書感想文SOLID原則 クリーンコードやクリーンアーキテクチャなどの「クリーン」シリーズでお馴染みのUncle Bobの新刊です。クリーンは書籍タイトルに付きませんでした。 本書は関数型プログラミングに関する書籍ですが、関数型プログラミング言語と聞いて、真っ先に皆が思い浮かべるものではないであろうClojureを取り上げて、一貫してこれとオブジェクト指向プログラミング言語との比較がされています。 これは読み進めていくと、オブジェクト指向言語としてはC++やJavaを用いて、Clojureのコードを対比していくという構図を随所でとっており、これらとできるだけ距離の遠い言語を選びたかったのだな、というのが分かります。Clojureは関数型であり動的型付け言語です。この2つ
Kent Beckの最新作Tidy First?は、リファクタリングよりも小さな単位でコードを整理するやり方を記した本です。これをTidying(本記事では「片づけ」と呼びます)と呼んでいて、リファクタリングのサブセットと定義付けています。なので片づけはコードの振る舞いは変えないことはリファクタリングから継承します。 Tidy First?はこんまりメソッドの影響も少なからず受けてそうです。 Tidy First?を書いた背景には、リファクタリングが機能開発を止めて行うようになったり、振る舞いを変えてしまうようになったことがある、とKent Beck自身が本書の中で述べています。 最近のKent Beckの講演は、Tidy First?に関連するものになっています。最新は、DDDEUのイベントの講演で第3部の内容が中心に語られています。なお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)で同期させたいとなると、イベントデータポンプな仕組みしか選択肢にはならない
Cognitect社のNygardさんが10年ぶりに改訂したRelease It! 2nd Editionがまもなくリリースされます。内容は現在のベータ5版で全て書ききっておられるようなので、是非読んでみてください。 https://pragprog.com/book/mnee2/release-it-second-edition その中から4章の安定性パターンの概要をご紹介し、実際JavaのFailsafeライブラリを使った実装例を示したいと思います。 安定性のパターン Stability Patterns 分散システムや後続をブロッキングしてしまう重い処理は、システム全体がスローダウンしたり、無応答になってしまう危険にさらされています。クラウド時代になって、これらの安定性を保つための設計はより強調されるようになりましたが、わりと昔から様々な工夫がされてきたものでもあります。以下、Rel
セッションIDやアクセストークン、はたまた業務上で使う一意の識別子など、いろんなところで一意のIDを生成しなきゃいけないケースが存在します。 そこで世間で使われているIDの生成方法について調べてみました。 選択基準 ID生成における要求として、以下の観点が上げられるかと思います。 生成の速度 大量にデータを短期間で処理し、それらにIDを付与する場合、ID生成そのものがボトルネックとなることがあります。 推測困難性 IDを機密情報と結びつける場合、IDを改ざんされても、機密データが見れないようにできている必要があります。 順序性 採番した順にデータをソートする必要がある場合は、IDがソートキーとして使えないといけません。 それぞれについて各生成手段を評価します。 ID生成の手段 データベースの採番テーブル 採番用のテーブルを作り、そこで番号をUPDATEしながら取得していくやりかたです。古い
Mackerelは、現状ではサーバの監視がメインで使われているかと思いますが、サービスメトリックという仕組みを使うと、アプリケーションの様々な状態も収集・監視出来るようになります(「Mackerelサーバ監視実践入門」p77より)。 ということで、Javaのアプリケーションモニタリングが出来る仕組みを作ってみました。 Dropwizard Metrics Metricsは、Javaアプリケーションのメトリックを取得するのに、色んなフレームワークで使われています。そして、集めた値をGangliaやGraphiteに送信することができます。この送信する役割をReporterと呼んでいます。 このReporterは比較的簡単に作れるので、metrics-graphiteを参考にMackerelバージョンを作ってみました。 https://github.com/kawasima/metrics-m
GitHub上の実際のコミットメッセージやIssueのやりとりをみて、チートシート作りました。 共通的なこと コミットメッセージやIssueのタイトルは、主語省略し、1文で書き行末ピリオドは付けない 動詞は現在形・過去形のどちらも同じくらいの頻度で見られるが、どちらかに揃える。 コミットメッセージを書く Japanese English
この半年間、久しぶりに開発チームのマネージャ的な立場もやることになったので、「ふつうの受託開発チームのつくりかた」以来、工夫したことをまとめておきます。「ふつうの受託開発チームのつくりかた」未見のかたはぜひそちらも見てみてください! チームに名前を付ける 私の受け持つチームは伝統的に「ラスカル」の名を付けるようにし、チームのアイデンティティを保つようにしています。チームメンバも本当は出来るだけ長く担当してもらいたいのですが、大きな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) 強い依存
Antifragileは、タレブが2012年に書いた本で、社会経済学の分野の内容ですが、他の分野においてもその考え方は有効ではないかと多くの記事や論文があります。ソフトウェア開発やアーキテクチャにどういう影響を与えていきそうかを考えてみます。 アンチフラジャイルの投資的側面 もともとはアンチフラジャイルとは、相場が動いたときに悪い方に転んでも損失はそこそこに抑えられるが、良い方に転ぶと指数関数的に大きな利益を得るということを意味します。 アンチフラジャイルな投資方法としては、プットオプションが鍵と言われています。 伝説の投資家シリーズ16-Nassim Taleb 私もこの辺りは門外漢なので、記事中の例を引用すると、通常時に50ドルのシティバンクの株式を3ドルで売る権利(プットオプション)を10セントで買います。これはシティバンク株が3ドル以下になることなど、ほとんどありえないと考えられる
エレベータはシステムエンジニア思考を鍛えるよい乗り物です。 対象について注意深く観察し、エラーを起こさずスループットが最大化されるように設計・行動する力を付けましょう。 ボタンキャンセルの仕様を確認しておく メーカーによって異なります。 基本的にはダブルクリックでキャンセル可能ですが、扉が開いてないと有効にならないものがあるので注意が必要です。 混雑したエレベータで1Fから最後らへんに乗り込み扉付近に立ったとき 高速にエレベータ運用するためには、ここのポジションは重要です。 まず何階のボタンが押されているか確認します。 エレベータが各階に止まったとき、それが… 1F出発時点で押されていない階の場合、降りる人はいないはずですので、乗ってくる人のためにエレベータの内部方向に詰めます。 1F出発時点で押されている階の場合、降りる人がいるので、一度エレベータを降りて、出入り口のスペースを作ります。
先日、マイクロサービスの呼び出し方として、オーケストレーションとコレオグラフィについて書きましたが、同じく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が出てしまっていました。 String[] specificationVersion = System.getProperty( "java.specification.version" ).spli
現在ではSpring Bootの手軽さに軒並み飲み込まれた感がありますが、Javaのマイクロフレームワークはちょっとしたブームでした。 Javaのマイクロフレームワーク ― この新トレンドは見逃せない enkanは、RackやExpress.jsで実装されているミドルウェアパターンをJavaで実装した、現在ファーストリリースへ向け開発中の新しいマイクロフレームワークです。 Java9のREPLを活用して開発・運用を楽にする機能も実装(予定)です。 なぜ今さら新しいWebフレームワークを? Spring BootやJava EEは、高度なDIとたくさんのアノテーションでフレームワーク内部の動きはブラックボックス化されます。これを完全にブラックボックスのまま、実用的なWebアプリケーションを完成させるのは、実際のところ難しく、フレームワークの内部を覗きにいかなくてはなりませんが、これが結構ハマ
Clojure関連のことをブログがわりに書き綴ります。 ※ここでの発言はシステムエンジニアを代表するものであって、所属する組織は二の次です。 Follow
黒魔術(バイトコードをいじること)なしに、Javaで動的にMixinします。 Background ミドルウェアパターンの実装などにおいて、とあるミドルウェアを追加したら、リクエストオブジェクトにメソッドを追加したい、ということがあります。 これを多重継承のできないJavaで実現しようとすると、最終的に必要となるメソッドを全部実装したクラス(またはその親子関係)が必要になります。 必要なメソッドだけ、必要なときに足したいですよね。Mixin! Mixin! インタフェースのデフォルト実装 JavaでMixinを実装したいと思っていた人たちには、Java8でインタフェースにデフォルト実装を持てるようになったのは歓迎すべき出来事だったようです。 Java8のインタフェース実装から多重継承とMixinを考える Java8でmixinをがんばってみる - yojikのlog こんな感じのデフォルト
Java8で導入されたOptionalは、その使い方に関していまだベストプラクティスがないように見受けられます。 僕にとってMaybe / Nullable / Optional が、どうしてもしっくりこないわけ。 re:僕にとってMaybe / Nullable / Optional が、どうしてもしっくりこないわけ。 Optional#mapとsomeスレッディングマクロ 私はJavaが言語としてnullを許容しているので、Javaにおいては、頑張ってnullを無くそうとするのではなく、いかにしてnullとうまく付き合っていくかが重要だと考えます。 同様にClojureのプログラムでも、nilが頻繁に出てくるのですが、NullPointerExceptionはあまり発生しません。これは、Clojureネイティブな関数たちにおいては、オブジェクト指向ではないので、nilに対するメソッド呼
Javaで多くのパラメータをもつオブジェクトを生成するとき、ビルダーパターンというやつがよく使われます。 Undertow server = Undertow.builder() .addHttpListener(port, "localhost") .setHandler(path) .build(); いろいろオプションを付けっていって、最後にbuildメソッドを呼ぶと、パラメータ間の整合性のチェックがされ、インスタンスが作られます。 ときに、そういうオプションを色々もつようなクラスをたくさん作るようなケースで、このビルダーをそれぞれ用意すると大変だよ、ということになります。 そういうとき、メソッド参照とBeanValidationを使えば、汎用的なビルダーを作れます。 こんな感じの汎用ビルダーを用意します。 public class BeanBuilder<X> { private
(学生や新入社員に「プログラミング、どうやって勉強したらよいのですか?」とよく聞かれるので書いてみました) サッカーのことは詳しく知りませんが、モウリーニョのいうところの「サッカーを上達するにはサッカーの練習をしなければいけない」は、プログラミング学習者にも当てはまるところが大きくあると思います。 独学でプログラミングを学ぼうとすると、本を読んでExampleを動かしてみたり、チュートリアルを実践してみたりすることが多いかと思いますが、なかなか身につかず途中で挫折することがよくあります。また、それでいざ業務で使えるものを作ろうとしても、なかなか手が動かないなんてこともよくあります。 私がよくやるのは、自分が学ぼうとする言語/フレームワークとは、別のもので実装された機能を移植してみる、というものです。 JavaのバイナリシリアライザであるFressianをClojurescriptで実装 h
本番と開発の環境の違いで、本番障害を起こしてしまった…という経験がないシステムエンジニアなど存在しないと思います。 どういう点で問題が起こり、どういう対策をすべきだったのか、経験をもとに書きだしてみます。 (ここで開発と呼んでいるのは、一応本番以外のステージング、テスト環境も含みます) ミドルウェア設定 Webサーバ 同時接続可能数(MaxClients) 開発環境では、あまり気にしないパラメータですが、本番では慎重に設定しないと次のようなトラブルを起こします。 MaxClientsが小さすぎて、システム間連携APIがタイムアウトしてしまった。 MaxClientsが大きすぎて、サーバのメモリが枯渇した。 本番でのトラフィックが正確に予測できなければ、デフォルトのままにしておいて、様子をみながらチューニング、の方が下手に設定するより事故が少ないように思います。 リライト コンシューマ向けの
リコメンド的なことをやりたいという要求はよくありますが、協調フィルタリングを持ちださなくてもよい(持ち出せない)ケースは現実的には多いと思います。ユーザを特定してその嗜好を取れなかったり、あまりリピートして使うものでないシステムだったり。 例えば、あるカレー屋さんはトッピングを多く選ばせることで利ざやを稼いでいます。そこでトッピングを多く選ばせるために、食券券売機におすすめの機能を付けたいと思いました1。 このケースでは当然ユーザの嗜好は分かりません。 高々50個くらいのトッピングメニューしかないので、「おぉこんなトッピングが存在したとは…」という発見があるわけでもなく、人気の組み合わせが分かれば、十分販促に繋がると思います。 こういうパーソナライズしないリコメンドには、伝統的なマイニング技術のアソシエーションルールが良さそうです。 このアソシエーションルールを作るのを、SQLだけでやると
名前、ふりがなが連続しているフォームにおいて、ふりがなを自動入力する機能は、よく要求としてあがってきます。 jquery.autoKana.jsがよく使われているようですが、これはキーイベントを拾って、フリガナを作るので、 Google日本語入力やATOKの予測変換 スマフォのフリック入力 などで、ちゃんとキーイベントが発生しないものは、うまくフリガナを作ることができません。 (参考) https://github.com/harisenbon/autokana http://qiita.com/u-chida/items/6c07d558b3f06c9ed8d8 サーバサイドでフリガナを作る ちょっと考えを変えて、サーバサイドで漢字からフリガナを生成するようにしてみます。 MeCabやKuromojiで形態素解析すると、漢字の"読み"も取得できます。 IPA辞書だと人名が弱いので、NEo
次のページ
このページを最初にブックマークしてみませんか?
『@kawasimaのマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く