まとめ 6月末でやめます 成長できる環境に…要は「俺より強い奴に会いに行く」 有給あまり過ぎてて暇 誰？ 私です⊂(・8・)⊃ RubyKaigi 2019でOpenAPI 3について登壇したり RailsDM 2019でマイクロサービスについての登壇をしたり JAWS DAYS 2019でAWS SageMakerを活用してる話をしたり 技術書典でマイクロサービスよろず本を出したり 検索結果の良さを計測して定量的に改善していく話をDevelopers Boostで話したり してました。 ６月末で退職で、ちょうど３年いた感じです。 辞めるのは一ヶ月前から決まってましたが、口止めが解除されて誰にでも言って良くなったのと、 ぷりんたいさんの株式会社SmartHR を退職しますみたいに退職前に退職ブログ書くの良さそうと思って書きました⊂(・8・)⊃ なんで辞めるのか 公開できる理由としてはぷりん

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

過去の回と比較するとこのようになります。 まとめ 前回よりチェック数は大幅に伸びていますが、販売冊数としては100冊ぐらい少ない結果になりました。 チェック数はおおよその売上の予想にはなりますが、精度としてはかなり荒い感じになりました… (売上としては黒字なので死んではないです) 総集編である一＆二がかなり売れたことや、実際に見比べてそちらを買っていく方が多いことを考えると、 三冊目なので三とつけたために先に読まないとわからない、もしくは発展的な内容であると思われてしまったのが原因かと思います。 実際に話しの流れとしてはどこから読んでも問題ない内容であり、雑誌のように2019 Springみたいなタイトルで誤解を招かないようにするべきだったかなというのが反省点です。 ただ、内容としても初心者向けのような内容は三冊目にはなく、そういったものを求めていた人もいたので難しいな…といったところです

4/14の技術書典６で「Microservices architecture よろず本 その三」を出します。場所はう５１「すべてがM(icro)になる」です。 こちらはよろず本シリーズ三冊目になりますが、これまでとはまた違ったトピックを扱っており、既刊を読んだことがあってもなくても有益な本になると思います。なお、目次はこの記事の一番下にあります。 https://techbookfest.org/event/tbf06/circle/60290003 また、「Microservices architecture よろず本 その一＆その二」を出します。 こちらは過去に頒布したその一とその二をそのままあわせた本になります。 両方別々に買うよりも安いので、新しく買う方はこちらを買うと良いと思います。 既刊の「Microservices architecture よろず本」および「Microser

TensorFlow ServingとはTensorFlowのモデルをマネージしてくれるサーバです。 モデルを処理するサーバ機能に加えて、複数モデルの管理、バージョンの管理、新たなモデルの自動ロード等を提供してくれます。 通信はgRPCやRESTで行うため、言語を問わずこれを立ち上げるだけで機械学習の恩恵を受けられる優れものです。 TensorFlow公式で、Google社内でも使っているっぽいのである程度の安心感があります。 モデルの用意 まずTensorFlowのモデルを用意します。 今回のチュートリアルにあるFashion MNISTを使います。 https://www.tensorflow.org/tutorials/keras/basic_classification Fashion MNISTは28*28のサイズに洋服の絵が描かれたデータセットです。 10種類のカテゴリからなり

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非許可の設定がうまく変換できないことが

committeeの3.0.0.alphaがリリースされました。 OpenAPI3対応とそれに伴う大規模なリファクタリングが入っています。 手元のプロジェクトではとりあえずテストが全て通りstaging環境でも動作していますが、使っていない部分や定義ファイルによってはバグる可能性があるので、ご確認をお願いします。 JSON Hyper-Schemaからの変換であれば、変換用スクリプトを書いたので、ある程度は自動で変換ができます。 初期化方法の変更 前回の方針の通り、Committee::Driversのクラスを使う初期化方法のみをサポートします。 具体的には以下のようにJSONをパースしてHyperSchemaオブジェクトを作成して渡します。 json = JSON.parse(File.read(...)) schema = Committee::Drivers::HyperSchema

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

12/15日に開かれたDevelopers Boostというイベントで、検索結果の良さを計測して定量的に改善していくという内容で発表をさせて頂きました。 簡単な内容説明 我々は物事を比較するときに何らかの基準＝「ものさし」を使って比較をします。 もちろん仕事の上でも様々な「ものさし」を利用して仕事をしています。 ですが目の前の問題に有効な「ものさし」を常に持っているとは限りません。 そのような場合、いかに「ものさし」を探すかというのが重要になってきます。 この発表では実例を元にどうやって「ものさし」を探したかという話をしました。 基本的には新しい「ものさし」を作る事は大変なので、いかに問題を整理して既に解かれている問題にマッピングするかを考えるべきです。 既存の問題にマッピングできれば、そこで用意されている物差しを利用できます。（＝巨人の肩に乗る） また、「ものさし」によって定量的に問題を

12/15日にDevelopers Boostというイベントが開かれますが、こちらで検索結果の良さを計測して定量的に改善していくという内容で講演をします。3つある公募セッションのうちの1つになり、16:15分からの話になります。 内容としては、アプリの検索精度の改善をした実際のケースを元に、良さという主観的な物事をいかに定量的に計れるように落としていったか、それによってどういう利点があり、最終的にどういった結果になったかを話す予定です。 技術書展で書いた話が、本質的に何が利点だったのかといった、もう一段上の視点から話す感じです。 ちなみに公式サイトのスピーカーを見てもらうと一人だけアイコン画像でめっっっっっっっちゃ浮いてます…みんなかっこいい写真を用意しているの凄い… (深く考えずにアイコン画像を送った⊂(・8・)⊃)

結論 Web上の2016/10/22以前のページをすべて調べた(数十ページなので) ヒヤリハットの対義語としている文献はなさそう ヤハリヒットという単語自体は過去にあったが、やっぱりヒットという意味が主(誤変換やUTAU) ヒヤリハットと関連付けた初出は2016/03/21の2chの書き込み とはいえ、面白いアナグラムなので広まっていきそう 概要 ヒヤリハットの対義語として、ヤハリヒットというものが存在するという言説を発見した。 「ヒヤリハット」の対義語が「ヤハリヒット」(事故るだろうと思って見てたら案の定、事故った)というの、草。 祥太 (`@shota_`) 2017年1月9日 ヒヤリハット（事故なんか起きないと思っていたのに、意に反してもう少しで事故になりそうだったので驚いた）の反対が、ヤハリヒット（いつか事故になると思っていたら、案の定事故になって大いに納得した）になっているのはす

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は存

10/8の技術書典５で関わった本を３冊出しました。 お買い求めくださった方、ありがとうございます。 また、マイクロサービス本とFlutter本はBOOTHでも販売していますのでどうぞ。 また、既刊のマイクロサービス本もBOOTHで販売中です。 Microservices architecture よろず本 その二 - ota42y - BOOTH（同人誌通販・ダウンロード） How to Develop Flutter Apps - ota42y - BOOTH（同人誌通販・ダウンロード） Microservices architecture よろず本 - ota42y - BOOTH（同人誌通販・ダウンロード） なお、マイクロサービス本はリアルに私に合う人であれば、紙の本も少数ですが販売します。 販売結果 マイクロサービス本は新刊３００、既刊１００冊＋αを持って行きましたが、どちらもほと

10/8の技術書典５で関わった本が３冊でます。 技術書典５で私が何故か３サークルの運営に関与していたので… Microservices architecture よろず本 その二 か１３「すべてがM(icro)になる」でマイクロサービスよろず本その二を頒布します！ https://techbookfest.org/event/tbf05/circle/28570001 この本はマイクロサービスアーキテクチャに関する実践を元にした本になります。 インフラから概念的なレイヤーまで幅広く扱っています。 また、食べログさんやQuipperさんにインタビューした記事があったりとかなり充実した内容になっています。 私はPub/Subメッセージと冪等性について書いてます。 既刊の販売もあり、どれも電子版も用意しています。 こんな感じです How to Develop Flutter Apps う７０「牛

Amazon Web Servicesサーバーレスレシピ という本が明日10/5に出ます。 元々技術書典で書いた本を更に加筆修正したものになります。 どんな本 この本は元々技術書典4で私も記事を書いた「Amazon Web Services サーバーレスレシピ 2018.04」がベースになっています。 技術書典4でAWSサーバーレス本出します！ 実際にサーバレスアプリケーションを組み立てる上で、こういうふうに組み合わせればいいんだよみたいな例を乗っけたものになります。 私は主にAWS Serverless Application Model(SAM)でECサイトを作るみたいなことを書きました。 技術書典版との差分 技術書典版ではNode.jsでコードを書いていましたが、Go言語ですべて書き直しました。 冗長な部分を削ったり、薄かった本番デプロイの説明を暑くするなど、ほぼ同じテーマで書いたの

RustでGyazoのサーバ側と同じ機能を有するRyazoを作りました。リポジトリはここです。 https://github.com/ota42y/ryazo オリジナルのGyazoと比べてDBにSQLiteを使っているところが若干違いがあります。 使い方 サーバを立てる docker hub にpushしてあるので、pullするだけで使えます。 ただし、DBファイルを先に作る必要があります。 mkdir data cargo install diesel_cli --no-default-features --features sqlite export DATABASE_URL=./data/ryazo.db diesel setup docker run -v `pwd`/data:/app/data -p 8888:8888 -e SERVER_ADDRESS=localhost: