はてなブックマーク

マイクロサービスを蝕む負の力学 マイクロサービスアーキテクチャでは、全体を分割し小さいチームとサービスにすることでチームの責任範囲を小さくし、 限られた範囲内で独自にPDCAを回すことで人数の拡大に対しても生産性を落とさないのが利点の一つになります。 これにより個々のマイクロサービスの関心事は小さく保たれるため、構成はシンプルになり実装しやすくなります。 一方でサービス間の依存関係が複雑になったり、通信量コストがとても増えるといったサービス間をまたいだところへの問題、 データの整合性や分散コンピューティングの落とし穴といった分散システム特有の問題、通信先のマイクロサービスの信頼性、安定性といった問題など、マイクロサービスアーキテクチャ全体としての複雑性は上がります。 そして、こういった複雑性や一部のマイクロサービスの不安定さは、そのマイクロサービスを構成する全員に悪影響を与えます。 つまり

AFTER RubyKaigi 2019で、『Q&A for “how to use OpenAPI3 for API developer”』を発表しました。 資料はこちら ベンチマークのコードはこちらになります。 https://gist.github.com/ota42y/1a5fb27e31aa5868af307fd66f52878b ベンチマークは登壇直後のブログで書いたのよりより誤差が少ない方法にしたため、 こちらのほうがより正確で、やはり気にするほどの影響はなさそうです。 ちょうどGW前に軽く書いて、きちんと作ってどこかで発表するかなーと思っていたところにちょうどいいタイミングであったので助かりました。 committeeのベンチマークをちゃんと取ったけど、どこかrubykaigi振り返りで発表枠ある所あるかな…ちこくkaigは予定かぶってた(´・_・`) — おおた@Ruby

だいぶ時間が空きましたが、2019/03/22-23で行われたRails Developers Meetup 2019にて、「我々はマイクロサービスとどう向き合うべきか」という発表を行いました。 言いたいこととしてはほぼスライドどおりで、だいたい以下の内容になります。 マイクロサービスは麻薬 適切に使えば嬉しい 嬉しすぎてついつい適切以上に使ってしまう 適切以上なマイクロサービスは辛い マイクロサービスは問題をより難しくする 例えば分割の失敗 別サービスを対象にしたリファクタリングは難しい モノリシックならまだリファクタリングができる どれくらいが適切かは組織の能力による 小規模でマイクロサービスはオーバーヘッドが多い テクノロジーの進化で中規模でもマイクロサービスがやれるようになってる 組織のパワーが上がるとマイクロサービスが大きくても大丈夫 Railsはマイクロサービスでも十分便利 マ

今回は未来の発表者のために発表までの準備や流れについて覚えているうちに書いていこうと思います。 発表内容はこちらを参考にしてください。 RubyKaigi 2019でOpenAPI 3について登壇しました 採択されたCFP 採択されたCFPを公開している例はある123ので、こちらでも公開していこうと思います。 ## Title How to use OpenAPI3 for API developer ## Abstract I'll talk about how to use OpenAPI 3 and another tools in production. JSON is widely used in the current Web. But the request / response format is not in the JSON specification, so we c

committee 3.0.0をリリースしました]。 このバージョンは主にOpenAPI 3対応が入っており、OpenAPI 3の定義ファイルを利用してリクエスト・レスポンスのバリデーションができます。 また、committee-railsも最新のバージョンで3.0.0に対応してるため、railsを利用している人はこちらも導入すると便利に扱えます。 OpenAPI 3を使う場合は様々なオプションが推奨設定になっているため、初めて使う場合はフルにその恩恵を受けられるはずです。 JSON Hyper-SchemaからOpenAPI 3への移行 JSON Hyper-SchemaからOpenAPI 3に上げる場合は変換スクリプトがあるのでこれを使うと便利です。 ただし、仕様上完全に変換することができないため、手で書いた場合に比べて冗長だったり、一部のnull非許可の設定がうまく変換できないことが

この投稿はMicroservices Advent Calendar 2018 19日目の投稿です。 簡単なまとめ マイクロサービスの大きな利点は、 チームに権限と責任を委譲することで、 組織が拡大してもチーム毎に自走することで開発スピードが落ちないことです。 小規模組織だとチーム毎に自走することが難しい場合が多く、マイクロサービスとしてのチームを組んでいることが足枷になります。 障害の局所化やビルドの高速化を欲しいならそれは垂直分割した分散システムで十分です。1 そのため、分散システムを持つチーム（≠マイクロサービスのチームではない）という認識を持った方が、無駄なオーバーヘッドが無くなりお得だと思います。 マイクロサービスの利点とは何か マイクロサービスではプロダクト毎にチームとシステムを分割し、 各チームが独自の権限で自分達のシステムを開発していくことで、 コミュニケーションコストを抑

RubyでOpenAPIやJSON Hyper-Schemaを使い、リクエスト・レスポンスバリデーションができるcommitteeのコミッターになりました。 また、同時にOpenAPI3対応を進めています。 https://github.com/interagent/committee/pull/145 方針としては以下のとおりです。 インターフェースに依存させるようにリファクタリング 現状のcommitteeはdefinitionの配列が存在するなど、JSON Hyper-Schema前提の作りになっています。既にあるOpenAPI2対応はそれに当てはまるようにデータを上手く変換して対応しています。OpenAPI3も同じように対応することを考えましたが、そうするとOpenAPI3の様々な良さを失ってしまいます。 そこで、一度スキーマを参照する部分を抽象化した操作にし、そのインタフェースに

JSON Hyper-SchemaからOpenAPI3に変換するスクリプトを作りました。 一旦はOpenAPI3でエラーのない状態に変換できます。 https://github.com/ota42y/json_hyperscheme_to_openapi3 残念ながらこの２つの仕様には完全な互換性はありません。 そのため、手元のJSON Hyper-Schemaデータに特化したいくつかの前提条件をおいています。 他の環境下ではこの前提条件が崩れる可能性があり、その場合はうまく変換できないのでご留意ください。 なお、現状ではまだ変換したファイルを使い込んでいないため、今後よりきちんと変換機能を作り込んでいく可能性はあります。 Objectに関する制約事項 Path Item Objectへの自動変換 JSON Hyper-SchemaにはOpenAPI3のPath Item Objectは存

突然プログラムが起動しなくなったため、 原因を探ったところ、localesが壊れていました。 そのため、再インストールすることで直りました。 言語取得部分は動くけど、おかしい結果を返す壊れ方のため、 発見にわりと手間取りました。 まとめ プログラム上でlocaleを参照する部分がおかしい結果を返す 常にANSI_X3.4-1968 Debian 7.8 dpkg-reconfigure localesが何か壊れているメッセージを出す localeをアップデートすると直る apt-get install locales localeの取得がおかしい pythonではgetpreferredencoding()で設定されている言語情報を取ってこれます。 ですが、 LANG='ja_JP.UTF-8' echo 'import locale; print locale.getpreferrede

http://github.com/go-sql-driver/mysql がありましたので、それを使います。 以下のように読み込むことで、sql.Openでmysqlを開くことが出来ます。

Boothで電子版の販売をしています Microservices architecture よろず本 - ota42y - BOOTH（同人誌通販・ダウンロード） 技術書典4の"か13”、「すべてがM(icro)になる」で、 Microservices architecture よろず本 を出します。 https://techbookfest.org/event/tbf04/circle/16650003 マイクロサービスアーキテクチャに関する様々な事を書いた本になります。 著者は私(@ota42y)と、@hyata、@qsona、@shinofumijp、@nobuhikosawai、@gemaの6人です。 人体ってマイクロサービスだよね、的な発言が著者人の1人からあったのでこんな表紙になっています。 目次は以下で、全77ページになります。 第 1 章 マイクロサービスとは何か？ 1.1

要約 gemのdependencyに < 5.2.0と書いてあると、 5.2.0.rc2までインストールできる 5.2.0がリリースするまでインストールできないと気がつきにくい 任意のgem依存関係を上書きして、bundle install/updateを可能にするgemを作った https://github.com/ota42y/virtual_gem 5.2.0.rc2を元に5.2.0のgemを作れる 任意のgemの依存関係を書き換えられる 事前に依存関係が壊れるのを調べやすくなる gemの依存関係によるインストール失敗 現在、Rails 5.2.0.rc2がリリースされています。 ですが、仮に現状で上手く動いていたとしても5.2.0のリリース時に一部のgemの依存関係が5.2.0.rc2までしか受け入れておらず、インストールできなくなる可能性があります。 gemには依存関係を設定でき

int型のポインタとchar型のポインタは違う型のため、同じものとして扱うことは出来ません。 ですが、実際にはポインタ型はメモリ上の特定アドレスを示すもののため、 どの型のポインタであっても、データ自体はメモリ上のアドレスを示す何bitかの数値であり、全く同じです。 （勿論、ポインタの示すアドレスに何があるかは異なります） そのため、ポインタ専用の変数を利用することで、あらゆる型のポインタを同じ変数に代入することができます。 ただし、コンパイラの型チェックが効かなくなる等の理由から、基本的にはオススメできない手法です。 C++の場合はテンプレートやクラスの継承、dynamic_castで解決できる場合はそちらを利用した方が安全です。 汎用ポインタ void *型は汎用ポインタと呼ばれ、あらゆるポインタを代入することができます。 これはたとえば以下のように、何の型かは指定しないけど、変数とし

FiNC Developer Advent Calendar 2016の19日目の記事です。 要約 リクエスト・レスポンス形式のドキュメントはメンテが大変 メンテされていなくても気がつかないため放置され気味 committeeでJSON Schemaに実装が沿っているかを確認可能 prmdでJSON Schemaを楽に書ける＋人が読めるドキュメントが生成できる メンテされていない事が検出できるので続く（はず API作成時のリクエスト・レスポンス形式問題 サーバとクライアントで並行開発しながらAPIを作成する場合、以下のようにリクエスト・レスポンス形式を整えにくいという問題があります。 リクエストの形式が想定と違う 想定外のキーを送ってくる 構造が想定していない構造 レスポンスに知らないキーが含まれている 同じデータなのにエンドポイントによって形式が違う enumの数値だったり、対応する文字

まとめ fmt.Print等にちゃんと出力されるかテストしたい 結論としては直接は無理 io.Writerを利用するように変えることで簡単にテスト可能 渡されたio.Writerに書き込むようにする 通常はos.Stdout、テストの時はbytes.Bufferを渡す どちらもio.Writerを実装している 標準出力への書き込みをテストしたい fmt.Print等で文字列を出力する場合、予期したものが出力されるかをテストしたい場合があります。 ですが、fmt.Printはそのまま出力まで行ってしまうらしく、こちら側で制御することは難しそうです。 このような場合、fmt.Printを使うのではなく、明示的に標準出力へ書き込むようにし、 テストの時は書き込み先を切り替えることで簡単にテストができるようになります。 fmt.Fprintで出力先を指定する golangでは任意の書き込み先に対し

Shinjuku.rb #42に行ってきました。 http://shinjukurb.connpass.com/event/42245/ 今回はコード分析・解析系のgemがテーマで、私はRubocopについて発表しました。 発表内容 Rubocopはソースコードをパーサgemを使ってASTに変換し、ちゃんとどういう構造なのかを見ていて凄くちゃんと解析していたので凄いなーと思う反面、 自分でルールを追加するのもの凄く大変そうでした。 また、こういったコードの整形ツールは自転車小屋の議論になって導入するの凄く大変だよね…という闇の深いディスカッションが行われました… やはり何処も苦労するところは同じようです…(´・_・`) その他 リファクタリングを支援してくれるgemが紹介されていましたが、 基本的に既存部分を切り出す→新しいロジックと同時に実行して実行結果をチェック→結果をDBとかに保存す

bundle execでrubyファイルを実行し、別のGemfileのあるディレクトリに移動してbundle系のコマンドを実行すると、 一回目のbundlerに対してbundleが実行されてしまい、 別のbundleを呼び出せないという問題が起きました。 これはbundlerが設定する環境変数が原因でした。 まとめ bundle exec中に、別のbundlerを実行するとおかしくなる 主にsystemやspawn等を使った場合 最初のbundle execと同じものであれば問題は起きない bundlerが設定をしている環境変数が問題 別のbundlerを呼ぼうとして元のbundlerが呼ばれている Bundler.with_clean_envで回避可能 Bundler.clean_systemでも可 問題 以下のような構成かつtestフォルダにいる状態で、 bundle install

freeコマンドに追加されたavailable 3.14および2.6.27から、freeコマンドの書式が変わり、 -/+ buffers/cacheが消えてavailableという項目が増えました。 availableは/proc/meminfoの中にあるMemAvailablの値を参照しています。 この値は、新しいアプリがスワップせずに使える容量はどれくらいか。といった値を示しているようです available Estimation of how much memory is available for starting new applications, without swapping. Unlike the data provided by the cache or free fields, this field takes into account page cache and

まとめ clip2dicを使うとクリップボード内を自動で辞書検索する オフラインの別アプリからも検索可能 ColorDictとGolden Dictが連携先として優秀 英辞郎は形式が違うため辛い Google Driveをビューワーとして使うといい ポップアップ辞書アプリ iOSやMacでは辞書機能がOSに統合されているため、英単語を選択するとそのまま辞書を引くことができます。 Androidで同じぐらい楽に辞書を引けないかと思って調べたところ、 clip2dicというアプリが、クリップボードの中身を自動でネット上の辞書から検索してくれました。 私はタブレットをオフラインで使用していますが、このアプリは別のアプリを呼び出して検索できるため、 他の辞書アプリを入れる事でオフラインでも辞書が引けるようになります。 clip2dictから使えるオフライン辞書アプリ ColorDict https

goでは標準でいろいろなツールが揃っていますが、 npmやbundlerのようなパッケージの依存管理をするツールはありません。 これは、goでは公開されている物は後方互換性を守り、 それを崩す場合は違うインポートパスにするべきだという思想によるものらしいです。 Packages intended for public use should try to maintain backwards compatibility as they evolve. The Go 1 compatibility >guidelines are a good reference here: don’t remove exported names, encourage tagged composite literals, and so on. If different >functionality is req

golangで構造体を定義した場合、 メモリ上にどのように配置されるのでしょうか。 通常意識する必要はありませんが、32bitと64bitで挙動がおかしい場合など、 ごく希に調べる必要に迫られる場合があります。 そのような場合、各要素のサイズや、構造体先頭からのオフセットを調べることで、 メモリ上に構造体がどう置かれるかを調べることができます。 C言語でのsizeofやoffsetofに対応する物が、golangのunsafeパッケージに用意されているため、 これを利用することで構造体の様子を調べることができます。 https://golang.org/pkg/unsafe/ 今回は以下のようなテスト構造体を使い、メモリ上にどのように置かれるかを調べました。 テスト環境はwindows7(32bit)とmac(64bit)になります。 type A struct { flag bool n

gxuiは、GoogleによるGo製のクロスプラットフォームなGUIライブラリです。 WindowsへのインストールはGoの環境を整えるところでだいぶ大変だったので、手順を書いておきます。 なお、一部の依存ライブラリが64bitに対応していないため、すべて32bit版を使います。 Go言語の環境構築 Go本体に加えて、依存ライブラリのためにgcc,hg,gitが必要になります。 元々SouceTreeがgitとhgを内部に持って、しかもコンソールまで提供していたのでそれを使っていましたが、 mingwのgccを認識してくれないため、コマンドライン版をインストールし直しました。 VCSのインストール git(http://git-scm.com/)とmercurial(http://mercurial.selenic.com/)をインストールします。 gitの場合、git bash only

https://github.com/go-yaml/yamlを使う事で、 goでYAMLを扱うことが出来ます。 サイトにはメモリ上のデータに対してYAML化するサンプルしかありませんが、 以下のようにすることでファイルからYAMLを読み込み、Mapとして扱うことが出来ます。 またExampleには型を決めて読み込む方法しか乗っていませんが、 以下の例では、go で yaml 等を「map[interface{}]interface{}」型で読み込んだ際の動的型の参照方法 を参考に型を決めずにMapで読み込んでいます。 かなり冗長な表現になっていますが…(´･_･`) package main import ( "fmt" "io/ioutil" "gopkg.in/yaml.v2" ) func main() { buf, err := ioutil.ReadFile("test.yml

cronというライブラリがあるので、それを使うととても簡単です。 なお、終了すると当然ながら実行しないので、 time.Sleep等で処理を止めておく必要があります。