RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのエンジニアブログ

新しくなった大阪オフィスで Rakus Meetup Osaka #1 を開催します!

f:id:tech-rakus:20180814160204p:plain

id:radiocat です。このたび大阪Meetupの運営委員に任命されました!

9月に東京でMeetupを開催しましたが、大阪でもやります!

rakus.connpass.com

新しくなった大阪オフィスは本当に良い環境で、広くなったセミナールームを早く活用したい!ということで移転直後から準備を進めてきました。

そんな大阪オフィスの様子は↓コチラをご覧ください。

www.wantedly.com

テーマは『大阪開発チームのチャレンジ』です

せっかくの大阪初開催ですので、大阪所属のエンジニアでトークセッションを固めました。東京を中心として盛んに行われているITエンジニアの勉強会ですが、最近は大阪でも活発に行われていて私もよく同業他社の勉強会に参加させて頂いています。せっかく、梅田駅から徒歩5分という立地でセミナールームを拡充して環境も整ってきたので、我々も一緒に大阪のIT業界を盛り上げていきたいと思っています。今後はコミュニティへの会場提供もしていきたいので、この機会に新しいオフィスを覗いてみていただければと思います。

当日のトークセッションは以下を予定しています。なお、トーク内容と順番は仮のものですので当日までに変更の可能性がありますがご了承ください。

チャットディーラーの高速開発を支えるLaravel

吉元和仁(よしもとかずひと)

今年夏に開催された PHPカンファレンス関西 2018 の登壇内容をベースにお話しします。10年以上PHPでノンフレームワークにより開発・運用されてきた主力サービス(メールディーラー)の開発チームが、新規に姉妹サービス(チャットディーラー)を立ち上げる際に Laravel を選択しました。 開発期間半年というスピードが求められる中で、Laravel での新規サービス立ち上げのチャレンジをご紹介します。

Why Mob Programming? - モブプロという働き方 -

大平直宏(おおひらなおひろ)

大阪の楽楽精算の開発チームでは、スクラム開発を取り入れて新機能の開発に取り組んでいます。急成長するサービスの開発を支えるためこの1年間で4人のメンバーが増えており、メンバー同士の知識共有が課題となっています。アジャイルな開発を推進するために取り入れているモブプログラミングのチャレンジをご紹介します。

トウダン・ジャーニー

川並裕(かわなみゆう)

今年の夏に開催された PHP カンファレンス関西 2018 で、会社として初めて技術イベントに協賛し、2 名のエンジニアが登壇しました。開発組織を横断した登壇推進チームが業務として登壇プロジェクトを推進したチャレンジをご紹介します。

大阪のエンジニア同士で交流しましょう!

今回は参加者のみなさまの中からもLTを募集いたします。テーマは同じく「チャレンジ」です。みなさまが普段チャレンジしていることを共有していただければと思います。そしてトークセッション後には交流会も開催します。弊社のエンジニアも含めて参加者同士で情報を交換し合い、エンジニア同士の交流を深めていければと思っています。

f:id:radiocat:20181106013951p:plain:w500

会場の場所や参加方法については以下のconnpassに掲載していますのでご確認のうえお申し込みください。みなさまのご参加をお待ちしております!

rakus.connpass.com

大阪開発ビアバッシュ〜10月「行ってきた特集」〜

はじめに

こんにちは、strongWhiteです。ラクスでは毎月1回、開発チーム主催のビアバッシュを開催しています。
ビアバッシュとはビールや軽食をいただきながら技術内容について楽しく語り合う交流会です。
今回は10月に大阪で開催したビアバッシュの内容を記事にしたいと思います(過去の開催も記事になっていますので、よろしければ下記をご覧ください)。
tech-blog.rakus.co.jp

今回は「行ってきた特集」

大阪のビアバッシュは決められたテーマに沿って発表する「テーマ枠」と、自由なテーマで発表する「自由枠」の2セッションを設けて発表を進めます。
また、「自由枠」は質疑応答ありで15分間の発表と質疑応答なしで5分間の発表(LT枠)に分かれます。
10月のテーマは「行ってきた特集」であり、各々がこれまで参加した勉強会やセミナーの様子と、そこで得た学びを共有していただきました。
今回の記事では主に「テーマ枠」の発表の様子をご紹介いたします。

行ってきた特集(テーマ枠)

京都アジャイル勉強会に行ってきた

筆者が「京都アジャイル勉強会」に赴き、スクラムについて学んだことを発表いたしました。
スクラムとは「ソフトウェアに変更はつきもの」という前提から、要求や仕様変更に柔軟に対応するために生まれたソフトウェア開発手法です。
もともと私の所属するチームではスクラムによる開発を推進しており、私自身のスクラムに対する知識理解の向上を目的に勉強会に出席しました。
この勉強会はディスカッション形式で、会場にはスクラムを実践する人たちが集まります。特にタイムボックスはなく、開始時間になると各々が日頃からスクラムについて感じている課題や疑問を議論し合います。同じ苦難や困難に立ち向かう者同士、お互いにスクラムに対する理解を深め合うのがこの勉強会の目的です。
筆者は個人的に「スプリントバックログの作成に時間がかかる問題」を抱えており、問題解決のヒントを得るため勉強会へと足を運びました。現在は、勉強会で得た知見をもとに自身のスクラムに対する姿勢の見直しを行なっています。

ハッカソンあるある

ハッカソンに参加しているとこういう場面絶対にある!という「ハッカソンあるある」を発表していただきました。
ハッカソンによく行かれる方は、↓と同じようなことを感じられたことがあるのではないでしょうか?

  • 名刺は切れる
  • 名刺を交換すると世の中は狭いことがわかる
  • ハードウェアがわかるとありがたがられる
  • ネットワークはもっとありがたがられる etc...

ハッカソンの場合、(テーマにもよりますが)プログラマーよりハードウェアやネットワーク面に強い方がいると心強いと思います。
突発的なネットワーク障害に遭遇した場合に、すぐに原因を究明して修正してくれると勉強会もスムーズに進行するかと思います。
筆者はハッカソンに参加した経験はないですが、「名刺を交換すると世の中は狭いことがわかる」はよくわかります。
最近も、プログラミングの外部勉強会に参加したのですが、そこで大学時代の同期に出会いました。以前にエンジニアになったとは聞いていたのですが、世の中は狭いものです...「あるある」は共感するものがあるととても面白いです。

今回から新オフィスで発表

ラクスは9月末に大阪オフィスを毎日インテシオから梅田ゲートタワーへ移転しました。今回のビアバッシュは引っ越し後初のビアバッシュとなりました。
年々新卒をはじめ、社員の増加に伴ってビアバッシュの参加者も増加してきたため、旧オフィスでは開催スペースの圧迫化が問題だったのですが、新オフィスでは広々とした開催スペースとなり、より新鮮な気持ちでビアバッシュを楽しむことができました。

f:id:strongWhite:20181029205823j:plain:w500:h500

おわりに

いかがでしたでしょうか。今後も定期的にビアバッシュの様子をお伝えしていこうと思います。次回のテーマは「新機能特集」を予定しています。
最近の弊社商品のリリース機能を紹介できたらと思います。どのような発表になるか楽しみです。

参考

JMeterのシナリオ作成がうまくいかない!そんなときのトラブルシューティングガイド

f:id:northmky:20181030144050p:plain

はじめに

こんにちは、開発エンジニアのnorth_mkyです。 先日業務にて負荷検証をJMeterで行うことになり、弊社エンジニアが書いた下記の記事を読みつつ複数のシナリオ作成を行いました。

tech-blog.rakus.co.jp

ですが最初の1シナリオの作成で全然想定している動作にならず、予想よりも3倍ほど時間がかかってしまいました。。。

シナリオ作成にあたって必要な知識として、もちろんシナリオを作成する対象の画面の仕様理解も必要ですが、思った以上に小さな設定ミスが多いです。 この記事では原因箇所に気づくまでのプチ・ベストプラクティスをご紹介したいと思います。

対象読者

シナリオを作成している方には有益な記事になっていると思います。 特に少し複雑なシナリオを作成しようとしている方にはぜひ一度みていただけたらと思います。

  • JMeterのシナリオ実行はしたことがあるけどシナリオ作成は初めて/始めたばっかりの方
  • シナリオ開始から終了までの間の画面遷移が多い(サンプラーが多い)
  • 特定のリクエストパラメータの値を外部ファイル(CSV)から読み込んでセットするようにしている
  • リクエストパラメータが動的に変わる画面遷移がある

シナリオ作成トラブルシューティングガイド

ミスの原因調査が簡単なものから除々に特定が難しい原因調査へとステップを踏むと効率的ですのでそのような構成にしました。シナリオデバッグをしていると最初は直しても直しても違うエラーがでてくる...と思わせてくるところがあるのですが、多くは簡単な設定ミスなので、気にせず淡々と確認していきましょう!

Step0. 準備

まず最初にデバッグができるようにする設定が必要です。テスト計画の直下に以下2点のコンポーネントを追加します。設定を適切に行うと実際に実行したときのリクエスト・レスポンスの情報がすべて見れるようになります。注意なのですが、デバッグ用に追加するので実際に負荷検証を流すときには必ず無効にしてください。 正しく計測ができない可能性があります。

  1. リスナー > シンプルデータライタ
    実行結果をファイル出力するコンポーネント。以下のようなxmlファイル形式に設定する f:id:northmky:20181030092811j:plain

  2. リスナー > 結果をツリーで表示
    1.で出力したファイルを読み込んでリクエスト・レスポンスをわかりやすい形で表示するコンポーネント

    • 失敗したリクエストは赤字にしてくれる 1
    • まちがっていそうなパラメータを赤字にしてくれる
    • URLエンコードされたパラメータをデコードして表示してくれる

Step1. jmeter.logを確認する

  • ポイント
    • 外部ファイルが正しく読み込まれているか
      • パスの指定が誤っていないか
      • 外部ファイルの書き方とシナリオで設定したカラムの順番、情報に誤りがないか

いざテスト実行してみたものの、本来ならもっと実行に時間がかかるところが一瞬で実行が終わってしまった...という場合はそもそもシナリオを実行するための準備に不足がある可能性が高いです。そのときはまずjmeter.logを確認します。jmeter.logは実行ログとなっており、外部ファイルの読み込みがうまく行っていない場合はエラーとして記録を残してくれます。

jmeter.logをみて原因箇所が推測できたら、設定エレメント > CSV Data Set Configの設定内容であったり指定したファイルの形式があっているか確認し適宜修正してください。

Step2. リクエストパラメータの値が正しいか確認する

Step0 で設定したリスナー > 結果をツリーで表示を見て実際にアクセスしたときのリクエストパラメータを見ていきます。 このパラメータの設定のミスが割と多いので下記ポイント4つを順番に見ていくと良いと思います。

  • ポイント
    1. 変数名がそのまま出ていないか
    2. 適切にURLエンコードをしているか
    3. 前画面の値を取得する後処理 > 正規表現抽出で設定した変数名をパラメータにセットし忘れていないか
    4. 受け渡している変数パラメータの値が前画面から正しく取得されているか

1. 変数名がそのまま出ていないか
リクエストパラメータの値を見ればすぐに見つけられます。(${hoge})
大抵原因は
サンプラーに設定した変数名が定義した変数名と違う」
後処理 > 正規表現抽出正規表現が誤っていて抽出結果が空」
いづれかになります。

2. 適切にURLエンコードをしているか
マルチバイト文字であったりURLでメタ文字や利用できない文字が含まれるパラメータをURLエンコードしないでリクエストを投げているか、逆にすでにURLエンコードしているところに誤って二重でURLエンコードを行ってしまっている場合があります。「URL Encode?」チェックボックスを確認してみてください。 HTTPプロキシをたててリクエストを記録した場合、よしなにJMeterがつけてくれている場合が多いですが、正規表現を組んだりしていくうちにチェックが外れてしまった/ついてしまったことがでてくるかもしれません。緻密な作業でミスが起きやすいので自分を責めず、そしてめげずに進めていきましょう...(経験談)

3. 前画面の値を取得する後処理 > 正規表現抽出で設定した変数名をパラメータにセットし忘れていないか
リクエストを記録した場合、その記録していた値のままになっているかもしれません。もう一度変数の設定漏れがないか確認してみてください。

4. 受け渡している変数パラメータの値が前画面から正しく取得されているか
1.で書いた原因に似ていますが、正規表現抽出で前画面から抽出自体はできていても余計な文字も拾ってきていてエラーになっている可能性があります。リスナー > 結果をツリーで表示ではレスポンスのbodyに対して文字列検索ができるため、リクエストパラメータにセットした値が前画面のレスポンス内で引っかかるか確認してみてください。

Step3. シナリオ実行がどこのリクエストで落ちたか実行順に見て特定する

  • ポイント
    • リクエスト/レスポンスごとに想定の挙動になっているか確認する
      • webサーバ/アプリログなど
      • 画面

Step1,2を確認しても解消しない場合はいよいよシナリオをしらみつぶしに確認する作業になります。複数箇所でエラーが出ている場合は、だいたい上のエラーが引き継がれてエラーがでることが多いので焦る気持ちを抑えて上から順番に見ていきます。 レスポンスでエラー画面やエラー文言があれば、そこからコケた原因を考えられるかと思います。

アサーションを適切に設定していないとエラーなのに見た目は成功を表すグリーンのアイコンになるのでより原因特定が難しくなりますよね。後世のために原因がわかったらアサーションを追加して次もし引っかかったときは失敗を表すレッドのアイコンになるようにすると良いと思います。

おわりに

いかがでしたでしょうか。長いシナリオだったりパラメータの多い画面の遷移となるとシナリオに小さいミスが起きやすくなる割に原因特定に時間がかかり気味になります。 そんなときにこの記事をみていただいて皆さんのもやもやや苦痛が少しでも和らげば幸いです。


  1. 失敗かかどうかはアプリケーションに依存するのでサンプラー > アサーションで適宜エラーを定義する必要があります

連休の狭間に失敗して学んだスプリントでコールド負けしないための鉄則

id:radiocat です。

スクラム銀の弾丸ではないので、いつもうまくいくとは限りません。今回は私たちのチームの失敗事例をご紹介します。

以前の投稿 でも紹介しましたが、私たちのチームは1週間スプリントを採用しています。以下のように木曜に計画を立ててスタートし、翌週木曜にレビューを行う流れです。

f:id:radiocat:20181022202656p:plain:w500

ご覧のように開発に注力できる期間は実質4日しかありません。油断するとすぐにレビューの日を迎えるので緊張感があります。そして、その緊張感にさらに拍車をかける要素がスプリント期間中の「休日」です。

連休の狭間の期間はスクラムを進めるべきか?

ご存知の通り、2018年の9月は2週続けて月曜が休日となる期間がありました。このままだと開発が実質3日しかないスプリントが2回続きます。

f:id:radiocat:20181024002916p:plain:w500

さらに、この連休期間を利用して2人の主力メンバーが休暇を取ることになりました。5人チームなので開発力は半減します。チームはこの期間をどう過ごすべきでしょうか?

連休の狭間もスプリントを進める選択

ご察しのとおり、我々はこのままスプリントを進めました。とはいえ、さすがに丸腰でこの状況に立ち向かうほどの度胸はないので、我々なりに対策を立てて取り組もうとしました。まずはその対策をご紹介します。

連休期間のスクラムイベントは中止する

全員揃っていない状態なのでスプリントレビューは1週間スキップすることにしました。ただ、連休前の金曜から着手したスプリントを中断するのはもったいないので以下のように進めることにしました。

個々の開発は進めて良い

中途半端に作業を中断して別の事をやるのも気持ちが悪いので、出社しているメンバーは出来る範囲で開発は進めておくことにしました。ただし主力不在で開発チーム内でのフォローやレビューは手薄になるので、無理せず出来る範囲で作業を進めて、主力メンバーのレビューが必要な作業などは連休明けまで保留するようにしました。

狭間の4日間で1日分の実績を目標にする

主力2人の休暇でチーム全体のパフォーマンスは低下しますが、残りのメンバーだけでも4日あれば普段の1日分ぐらいの実績は充分達成出来るだろうと考えました。そうすることで結果的に2週間の合計が4日分の実績となるので、いつも進めている1週間スプリントと同じぐらいのベロシティを目指すことになり、感覚的にもわかりやすい目標になります。主力不在とはいえ4日で1日分なので、出勤しているメンバーにも負担がかからないはずです。

f:id:radiocat:20181028182142p:plain:w500

プランニングと共有をいつも以上にしっかり行う

念のため、休暇の前日に改めて主力メンバーが考えているスプリント中のタスクの進め方をチームのメンバーへしっかり共有して引き継いでもらいました。

下がりきらなかったバーンダウンチャート

結果的にこのスプリントでは、残タスク量を示すバーンダウンチャートの実績が次のようになりました。

f:id:radiocat:20181022214629p:plain:w500

微妙な結果です。大負けというほどでもなく、微妙な感じが逆に気持ち悪いくらいです。しかし、このスプリントのふりかえりはチームに疲弊感が漂い、私も含めてみんなモヤっとした状態で改善アクションもうまくまとめられないままスプリントは終了しました。

なぜ計画どおりにスプリントが終わらなかったのか?

いったい何が問題だったのか、後日スクラムコーチに相談してみると3つの課題が見えてきました。

スプリントを進めるのに十分な体制ではなかった

私たちのチームのメンバー構成を改めて整理すると次のようになっています。

f:id:radiocat:20181024003201p:plain:w500

現在進めているプロジェクトの在籍期間が1年以上のメンバーが誰もいない状況で、目に見える人数以上にチームの体制は弱くなっています。さらに実はこのスプリントの前半の主力メンバーが休暇に入る直前まで、チームを助けるべきスクラムマスターは出張先からリモートでチームの活動に参加しており、開発チームの状況を詳細まで把握出来ない状況にありました。いつも以上にしっかり共有してから休暇に入るという事前の対策は開発チーム内の個々のメンバーの感覚に託されており、客観的にみても対策できているといえる状態かどうかは誰もわからない状況になっていました。

バックログがReadyではなかった

さて、上記のバーンダウンチャートは狭間の4日間を1日の実績としてまとめていますが、これをそれぞれの日ごとの実績に分けてみると次のような実績になっていました。

f:id:radiocat:20181022214005p:plain:w500

主力メンバーが休暇に入った初日から実績が上がらず、残タスクが全く減っていません。すでに危険な状況に突入していることがわかります。実はこのとき、プランニング時点の想定が覆ってそのままではタスクを進められないことがわかりました。スクラムマスターはチームの状況を察知し、いったんタスクの終了条件を見直したりスプリントのゴールを見直すなどの調整を行い、一度は残タスクが減りましたが、すぐにまた別の問題が発生して逆に残タスクが増えてしまいました。

f:id:radiocat:20181028191543p:plain:w500

結果的にこの時着手していたバックログは最初からReadyではなかったのです。つまりこのスプリントは前半時点ですでにコールド負けが決まっていました。

しかし、1つ目の原因にあるとおり、チームの体制が不十分で、前半時点ではこの状況を正しく判断できるメンバーがいませんでした。スクラムマスターはチームの状況を正確に判断出来るだけの情報をキャッチできていなかったため場当たり的な対策を取ってしまい、結果的にはコールド負けしたチームにそのまま試合続行を促すことになってしまいました。

仕掛りがたまっていて手当てが追いつかず

チームはそれでもなんとかスプリントのゴールを目指そうと取り組みました。休暇が明けてから、主力メンバーの頑張りによってなんとか持ち直しますが、計画していたゴールには到達できませんでした。

バーンダウンチャートを見るとスプリントの最後で残タスクの消化が少なくなっています。実はこのとき、仕掛中のタスクがたくさ増えすぎて経験のある主力メンバーでも残りの期間で全てを手当することは出来なくなっていました。スプリント前半に発生した問題をなんとかしようとして計画時の想定とは違う進め方をしたり、いったん保留して他のタスクに手を出した結果、想定以上に仕掛り中のタスクが増えてしまったのです。

f:id:radiocat:20181028192522p:plain:w500

コールド負けしない鉄則

実はこれらの原因は既にスクラムコーチの吉羽さんが別の場で示されているものでした。

slide.meguro.ryuzee.com

この資料の中でアジャイル開発でコールド負けしないための5つのポイントが挙げられています。

  1. 十分条件で開始する
  2. Readyなプロダクトバックログ項目だけ着手する
  3. 同時の仕掛りを少なくする
  4. フィードバックサイクルを回し続ける
  5. 技術に投資し続ける

我々は5つのポイントのうち3つを犯してしまっていました。コールド負けしてしまっても仕方ないですね。スプリントを進めるにあたり、改めてこれらの3つのポイントが重要であることを痛感しました。

  • 開始するのに十分な条件か?
  • バックログはReadyになっているか?
  • 仕掛りが増えすぎる進め方をしていないか?

それでも、我々はこの1回のスプリントでとても大きな学びを得たとも思っています。今後はこれらをしっかり意識してチームで取り組もうとしています。


REGIONAL SCRUM GATHERING TOKYO 2019 のCfPを出しました!

2019年1月9日〜11日に大崎ブライトコアホールで1年に1度のスクラムのビックイベント「REGIONAL SCRUM GATHERING TOKYO 2019」が開催されます。

2019.scrumgatheringtokyo.org

私たちのスクラムの取り組みを多くの方に知っていただき、そして私たち自身が学びを得るためにプロポーザルに応募しました。下記のリンクをご確認いただき、ご興味のあるかたは是非likeをお願いします(締切が10月末ですのでご注意ください)。

confengine.com

REGIONAL SCRUM GATHERING TOKYOでは毎回たくさんの素晴らしいセッションが行われますので、スクラムに興味のあるかたはぜひチケットを入手してご参加いただければと思います。

知っていると便利かも?psqlコマンドのオプション4選

f:id:FM_Harmony:20181022092416p:plain

初めに

こんにちは!エンジニアのid:FM_Harmonyです。

前回はgitのfetchコマンドについて、記事を投稿しました。 tech-blog.rakus.co.jp

今回はpostgreSQLの対話型ターミナル、psqlのオプションについて紹介したいと思います。
普段の業務でも、psqlコマンドの-fオプションや-cオプションを利用してクエリを発行する機会が多いのですが、psqlには他にも便利なオプションが備わっています。
多くのオプションが存在しますが、今回はその中でも個人的に便利だと思う4つのオプションについて紹介します。

続きを読む

マイクロサービスアーキテクチャにおけるサービス分割の難しさ

大阪オフィスの移転を機に、生活リズムも絶賛見直し中の @kawanamiyuu です。

今回は昨年度から取り組んでいる、通称「かみせんプロジェクト」の今期の成果(の一部)についてご紹介します。

かみせんプロジェクトとは

かみせんプロジェクトとは「開発の未来に先手を打つプロジェクト」の略称で、2017 年度に取り組みが始まりました。

ミッション

『継続的に新しいことに取り組み、組織要望に対して迅速にトレンド技術で応えることができるようになる』

目標

具体的には以下の実現のための技術検証や知見獲得を、社内システムのマイクロサービス化を題材に行っています。

  1. ソフトウェア規模に比例した開発効率低下の軽減
  2. 無停止デプロイ、不具合発生率低下などの高可用性の実現
  3. 現行ソフトウェアからの段階的な移行の実現

社内システムのマイクロサービス化

社内システムの概要

  • LAMP (PHP) で構築されたモノリシックな Web アプリケーション
  • エンジニア、経理担当者などが、社内からのみアクセスして利用する
  • プロジェクト管理機能、開発稼働集計機能などを提供する

かみせんプロジェクト開始前

  • すべての機能がモノリシックなアプリケーションとして提供されている

f:id:kawanamiyuu:20180925154624p:plain

2018 年 9 月現在

  • モノリシックなアプリケーションから、一部の機能をマイクロサービスとして切り出した
  • マイクロサービスは AWS 上でコンテナとして動作している

f:id:kawanamiyuu:20180925144057p:plain

マイクロサービスの結果整合性

マイクロサービス化を進めるとバックエンドで複数のサービスが協調して動作することになり、これまではデータベースのトランザクション機能により担保されていたデータの一貫性について別のアプローチが必要になります。

かみせんプロジェクトの今期の取り組みの 1 つとして、マイクロサービスの結果整合性について調査や技術検証を行いました。

課題感

  • 複数に分割されたサービス間のデータの一貫性をどのように保てばよいか
  • データ不整合が生じた場合、どのようにリカバリーすればよいか

検証内容

  • ある機能を 2 つのサービス (図中の project-servicefunction-service) として切り出す
    • モノリシックなアプリケーションを、複数(社内での利用実績がない、あるいは少ない)の言語やフレームワークを利用して分割することも技術検証の一環
  • あるリソースを新規登録する際に、従来 1 トランザクションで行っていた処理 (SQL) の一部を、今回切り出したサービスの API 呼び出しに置き換える
  • データの整合性はリトライ処理で担保する

検証結果(得られた知見)

サービスの分割は難しい
  • 大前提としてサービスをまたぐトランザクションが発生しないようにサービスを分割すべき
  • 今回のように同一トランザクションでデータ更新をしたい処理であれば、サービス同士が疎結合ではないということであり、そもそもサービス分割の粒度が正しくない可能性が高い
  • ドメインの知識が乏しい状態では適切なドメイン境界を認識することはきわめて難しい
  • ドメインの知識が増えた中盤になってから分割し直すことも、別の意味で難易度が高そう
    • 自動テストなど品質担保の仕組みや、作り直しに対する組織の理解の度合いで実現可能性が大きく変わる
結果整合性の担保は難しい
  • 今回のようにリトライ(有限回数)で整合性を担保する場合、すべて失敗する可能性もゼロではなく、最終的にログなどから手動リカバリーできる仕組みを考えておく必要がある
  • 今回は時間の都合で検証していないが、メッセージキューを利用したイベントソーシングなアーキテクチャも検討したい
  • 分散トランザクション(二相コミットなど)の手法を使う選択肢もあるが、システムの複雑さや難易度が一気に増加しそうで現実的ではなさそう

最後に

  • マイクロサービスの分割や結果整合性に関する知見は、情報としては世の中にありますが、実際に自分の手を動かして検証することで、改めてその課題感を実感するとともに、現実のサービス開発にマイクロサービスアーキテクチャを適用する難しさも明らかになりました
  • ラクスでは現在、HR(人事労務)領域を対象した新サービスの開発に取り組んでおり、この「かみせんプロジェクト」で得られた知見が現実のプロジェクトで活かされようとしています。例えば

ラクスでは現状に満足せず開発の未来に先手を打っていける仲間、HRTech に興味があるエンジニアを募集しています!

www.wantedly.com

iPhoneだけでAPI実行!!「ショートカット」アプリを試してみた

はじめに

新卒2年目エンジニアのkasuke18です。
つい先日iOS12がリリースされました。リリースされた内容は数多くありますが、その中でも気になったのが「ショートカット」というアプリです。このアプリをうまく使えばiPhone単体でAPIの実行が可能になります。実際に試してみましたので、紹介します。

もくじ

「ショートカット」アプリについて

「ショートカット」アプリの画像
リリースノートShortcuts 2.0 release notesを見ると、「ショートカット」アプリはiOS12の以前に「Workflow」アプリとして公開されていたようです。
「ショートカット」アプリでは、ビジュアルプログラミング言語のようにアクションと呼ばれる構成要素を組み合わせて1つのショートカットを作成します。アクションにはiPhone端末の設定変更他アプリの操作・データの受け渡しといったものが用意されているほか、変数・条件分岐・繰り返し(for, foreach)といった制御を行うものも用意されています。

作成したショートカット

内容

クリップボードに保存されている画像のリンクに対してOCRAPIを実行し、画像内の文字をテキストに変換して出力する、ということをやってみました。今回使用したOCRAPIFree OCR API | OCR.spaceです。POSTパラメータやレスポンスのJSON構成はリンク先でご確認ください。

作成例

まずはPOSTリクエストを送信する部分です。

POSTリクエストを送信するショートカット
図1. POSTリクエストの送信

今回POSTパラメータとして必要な情報はAPIキー画像内の文字の言語base64エンコードされた画像の3つです。このうち画像内の文字の言語は日本語で固定としているので、残り2つを取得する処理はサブルーチンとして別ショートカットに切り出し、それらを呼び出す方式をとっています。ではそれぞれのショートカットを見ていきます。

 

APIキーの取得処理です。APIキーは環境変数に持っておきたいのですが、さすがにそこまではできないようなので、今回はリマインダーアプリに保持・読み出すようにしています。

APIキーを「リマインダー」アプリから読み出すショートカット
図2. APIキーの取得
内容はAPIキーを保持しているリマインダーを検索し、その中から今回使用するOCR.spaceというタイトルの項目からAPIキーを取得しています。
ショートカットの最後では、メインのショートカットに値を渡すため、変数から値を取り出して終了しています。

 

次にbase64エンコードされた画像の取得処理です。このパラメータに設定する値はdata:image/[フォーマット],[base64エンコードされた画像]ですので、実際は拡張子画像をbase64エンコードしたテキストの2つが必要になります。
まずは拡張子の取得処理です。

URLから画像を取得し、その拡張子を取得するショートカット
図3. 拡張子の取得

大きな流れとしては、まずクリップボードの内容がURL形式どうか確認し、URL形式ならその内容を取得します。さらにその内容がイメージであれば拡張子を、そうでなければnoneというテキストを返却する、という処理を行っています。このnoneというテキストは、ショートカットを実行する側の処理でnoneを受け取り、エラーとして処理を終了するために利用します。
次が画像をbase64エンコードしたテキストの取得処理です。
URLから画像を取得し、そのbase64エンコードしたテキストを取得するショートカット
図3. 画像をbase64エンコードしたテキストの取得

これは拡張子の時とほぼ同じ処理の流れをしていて、拡張子を取得していたところを画像をbase64エンコードしたテキストを取得するように変更しただけです。

 

最後にメインのショートカットで他のショートカットを実行する&その結果を受け取る処理と、レスポンスJSONをパースする処理を行います。 まずは他のショートカットを実行&その結果受け取る処理です。

別ショートカットを実行し、その結果を受け取るショートカット
図4. 別ショートカットの実行

処理の流れは画像の通りです。ショートカットを実行し、その結果が拡張子ではないときは中断されたことを通知しショートカットを終了します。
続いてレスポンスJSONをパースする処理です。
レスポンスJSONをパースするショートカット
図5. レスポンスJSONのパース

「ショートカット」アプリ内ではJSON辞書という単語で扱われています。アクションとしては辞書の値を取得というもので、これは組み合わせればネストされたJSONのパースも可能です。また今回は結果出力のため、最後にメモに書きだすようにしています。

実行結果

以上のサンプルを、前回私が書いた記事の画像に対して実行した結果が以下となります。

OCRで認識する画像
図6. OCRで認識する画像

ショートカット全体を実行した結果
図7. 実行結果

おわりに

今まではちょっとAPIを試してみたいだけでもPCを用意する必要がありましたが、この「ショートカット」アプリを使用すればiPhone単体で簡単にできます。また今回は紹介していませんが、テキストに対して正規表現を用いたマッチングもできるので、スクレイピングも可能です。iPhoneユーザの方は試してみてはいかがでしょうか。
最後までご覧いただきありがとうございます。

参考文献

付録:今回使用したアクション

アクション名とその使い方を以下にまとめました。

  • API実行
    • URL
      • URLを次のアクションに渡す
    • URLの内容を取得
      • 受け取ったURLをリスエストし、レスポンスを次のアクションに渡す
  • クリップボードをリクエスト用に加工
    • クリップボードを取得
    • 種類を取得
      • 受け取った値のデータ種類(イメージ・URLなど)のテキストを次のアクションに渡す
    • Base64エンコード
      • 受け取った値をBase64形式でエンコード・デコードした値を次のアクションに渡す
    • ファイルの詳細を取得
      • 受け取った値(ファイル)の詳細(拡張子・サイズなど)を次のアクションに渡す
  • JSONのパース
    • 辞書の値を取得
      • 受け取ったJSONから指定したキーの値を次のアクションに渡す
  • 制御
    • 変数を設定
      • 受け取った値を変数に代入する
      • 受け取った値をそのまま次のアクションに渡す
    • 変数に追加
      • 受け取った値を変数に追加する(Listにappendするようなイメージ)
      • 受け取った値をそのまま次のアクションに渡す
    • 変数を取得
      • 変数から値を取り出し、次のアクションに渡す
    • 次の場合(if~else文)
      • 受け取った値と指定した値を比較する(次と等しい・次を含む・より大きい・より小さい)
    • それぞれで繰り返す(foreach文)
      • 受け取ったリスト形式の値に対して1つずつ処理を行う
    • ショートカットを実行
      • 受け取った値を特定のショートカットに渡し、その実行結果を次のアクションに渡す(メソッドのようなイメージ)
  • APIキーを取得する
    • リマインダーを検索
      • 条件に合致するリマインダーを検索し、その結果を次のアクションに渡す
    • リマインダーの詳細を取得
      • 受け取った値(リマインダー)の詳細(メモ・タイトルなど)を次のアクションに渡す
  • その他
    • テキスト
      • 指定したテキストを次のアクションに渡す
    • 通知を表示
      • タイトル・メッセージを指定し、その内容を通知として表示する
    • メモを作成
      • 受け取った値をメモに新規登録する
    • "ショートカット"を終了
      • 現在のショートカットを終了する
      • 現在のショートカットに含まれる後続のアクションは実行しない
Copyright © RAKUS Co., Ltd. All rights reserved.