Web Developer Specialist (ODC)

1. Web Developer Specialist (ODC) OutSystems東京開発者コミュニティ 2025/02/26 OutSystems MVP 渡部 潤司 : https://qiita.com/jyunji_watanabe : https://twitter.com/JyunjiW : https://www.linkedin.com/in/watanabejyunji/ Qiita X LinkedIn
2. 本日の内容 1. Web Developer Specialist (ODC)とは 2. サンプル問題を確認してみる 3. まとめ
3. 1. Web Developer Specialist (ODC)とは
4. 概要 • Specializationの試験 • Web Developer Specialist、Architecture Specialist、2025/02では未発表のもう1 つのSpecializationを取ると、Professionalレベルの認定を受けることができる • O11の同名試験の認定を受けていて、対応するコースを修了すると自動認定されるらしい （私はされなかったが） • 対策用のオンラインコースとしてGet Ready for the Web Developer Specialist Exam がある
5. 出題範囲 • Associateより踏み込んだレベルで、周辺的な領域も含めた出題がされる • 一般の開発者にとっては、Associateの次に取る認定試験としてちょうど良い • 出題範囲 ◦ Asynchronous Processes ◦ Best Practices ◦ Screens and Blocks Lifecycle ◦ Exception/Transaction Handling ◦ Integrations ◦ REST APIs ◦ Troubleshooting ◦ Work in Teams
6. 必要な対策 • （当然の内容ばかりだが）以下三点の対策 1. ドキュメント・公式動画を、学生時代の試験勉強くらいの熱意で読み込んで記憶しておく 2. 試験範囲については、実際のソフトウェア上で操作しておく、一部の問題は実務で触ぅておくことも必要なレベルの 出題がある 3. 一般のシステム開発者としての知識・判断力 • 公式のサンプル問題（上で紹介したコース内にある）を解き、出題される問題のレベルと細か さを把握する • ここでは、問題は、（時間の都合で）以下の基準で1問ずつ抜粋してみていく 1. 知識があれば解ける問題 2. 知識に加えて操作・実務経験が問われる問題 3. 設計的な判断が必要とされる問題
7. 2. サンプル問題を確認してみる
8. 知識問題の例:3 Asynchronous Processes Q Eventに関連して正しいのはどれか? ①Appコンテナごとに同時に10までのEventを処理できる ②Publicにすれば、他のAppからもサブスクライブできる ③Eventを公開しているAppは他のAppのEventをサブスクライブできない ④Eventはリトライの仕組みを持たない 選択肢の検討:知識問題は、文字通り知識について聞かれるので、知っていさえすればとける ①Appコンテナごとに同時に10までのEventを処理できる →同時に処理できるのは、10までではなく100まで。ドキュメントに記載がある。 「ODC apps can simultaneously handle up to 100 back-end events per app container.」
9. 知識問題の例:3 Asynchronous Processes ②Publicにすれば、他のAppからもサブスクライブできる →正しい。右のEventの定義例参照。Publicプロパティがある ③Eventを公開しているAppは他のAppのEventをサブスクライブできない →特にこういう決まりはない。他の要素と同じく、Eventを公開しているから と言って他のAppのEventを参照できないということはない。Server Actionを公開するLibrary が他のLibraryが公開するServer Actionを利用できるのと同じ。 ドキュメントにははっきり書いていないと思うが、ODC Studioの開発をしていて、参照関係を操作 する経験があれば判断はできるはず。 ④Eventはリトライの仕組みを持たない →ある。同じドキュメントに記載あり。「ODC retries up to 10 times in case the delivery of a back-end event fails.」
10. 知識問題の例:3 Asynchronous Processes 解き方 以下の選択肢が明らかに正しいので、Eventの基礎知識を押さえていれば即答できる。 ②Publicにすれば、他のAppからもサブスクライブできる 選択肢それぞれを最初に見たときに、◦△×で評価すると ①△ 細かい知識なので覚えていないかもしれない。しかし1Appあたり10はいかにも少ないので ②◦ ③△ 明記はされていないので確信を持つのは難しい。普段の開発経験やOutSystemsのアー キテクチャ系の知識から、無さそうとは思えるはず ④× これもEventの基礎知識
11. 操作経験問題の例:4 Work in Teams Q 二人の開発者が同じAppを開発している。二人が同じRevisionを開いていた。一人 (Aとす る) がButtonの幅を変更してPublishし、もう一人 (B) が同じ箇所を変更してPublishしたら何 が起きるか。 選択肢の検討:知識でも解けることが多いが、操作経験があった方が理解しやすい ①BのODC StudioにTrue Changeエラーが出る ②Bはconflict (競合、OutSystemsのドキュメントでは衝突と書かれているかもしれない) の解 決を行わなければならない ③Aの変更分を除いて、BのバージョンがPublishされる ④Bのバージョンは捨てられ、BのODC StudioにはAがPublishしたバージョンが表示される
12. 操作経験問題の例:4 Work in Teams チーム開発経験があれば、他の開発者と同じ場所を同時に変更していると、Publish時にダイアロ グが表示されるのを体験しているはず。要素ごとに、競合が発生した2バージョンのどちらかを選択し て（マージして）Publishするダイアログ。この経験があれば、選択肢は②であることがすぐにわかる。 ドキュメントにも記載があるが、実際に操作をせず、問題を体験していないと、理解が難しいのでは ないか。 https://success.outsystems.com/documentation/outsystems_developer_clou d/building_apps/merge_the_work/compare_and_merge_example_with_conf licts/
13. 設計問題の例:9 Best Practices - Queries Q 以下の条件でCarの情報を抽出しExcelファイルを出力したい。提示された設計案に対し改 善案を検討する問題。 - Excelに出力する列:Maker name, VIN, Mileage, Year - Makerでソートする - Carの情報は全てCar Entityに含まれる - ただし、Makerについては別途マスタが存在する。CarにはMakerを参照するMakerIdがある ↑は問題文を整理したもの。この時点で、「CarとMakerをMakerIdで結合し、MakerのName でソートしたものをAggregateで取得。結果をRecordListToExcelでExcelファイルに変換すれ ばよさそう」と考えられると良い。ドキュメントを読み、幾らかの実践経験があれば恐らく可能
14. n Aggregateの名前が 「GetMakersSortedByCar」 →Carを示すなんらかの情報でソートしたMakerのリ ストを取得している? 名前だけから判断すると、奇妙な事をしていますね。 要するにMakerのリストを取得していると理解してお きます。
15. 最初のAggregateで取得したMakerのリストをループ し、ループ毎にAggregateを取得している。 Aggregate名「GetCarByMakerId」からループした 各Maker毎にCarを取得している。 取得したCarのリストは、ListAppendAllでLocal VariableのListに蓄積。 その後、ループ後に、RecordListToExcelでExcelフ ァイルに変換している。 n
16. 設計問題の例:9 Best Practices - Queries テーブルの取得結果をループし、各要素毎に別のテーブルを取得するパターンは、実行時間が⾧く なりがちであり、 RDBであればジョインを使えば1回のリクエストで取得可能なので、一般的には避 けるべき実装。また、OutSystemsのベストプラクティス違反でもある。 ベストプラクティス:Aggregate or SQL query inside a cycle （https://success.outsystems.com/documentation/outsystems_developer_clo ud/monitoring_and_troubleshooting_apps/manage_technical_debt_in_odc/pe rformance_findings/aggregate_or_sql_query_inside_a_cycle/）を参照
17. 設計問題の例:9 Best Practices - Queries 以上見てきたように、設計問題では、以下全てが必要 - ドキュメントに書かれている知識の把握 - 実践経験に基づく判断 - 設計情報を読み解き判断する 選択肢を検討すると ①×:ベストプラクティスに則っている。可能な場所では自動で最適化されるAggregateを使っている → ここまで見てきたようにベストプラクティスに則っていない ②×:2番目のAggregateをServer Actionに分離し、必要な属性だけをOutputに出す → 別の ベストプラクティスで「Aggregate1つだけのServer Action、EntityをOutput Parameterに出す」の を避けると言うものがあるが、それと混同させようとしている? ③◦:2つのAggregateを、1つのAggregateにまとめる（CarとMakerをジョインする） ④×:AggregateをそれぞれSQLに置き換える → ループ内でクエリをかける問題が治っていない
18. 3. まとめ
19. まとめ（と注意） 1. Web Developer Specialist (ODC)はAssociateの次におすすめの認定試験 2. Associateでは対象にならなかった、少し高度な話題や、周辺的な開発知識が出題 3. 対策は他の試験と同じく o ドキュメントを読む o 操作・実務経験を積む o 設計スキルを磨く 補足:個人的な見解として、サンプル問題は本番の問題より文章や設定が明確で、問題文や 設定に十分な回答根拠を見つけられることが多い。つまり本番では、十分な根拠がなく明確な回 答ができない問題が結構ある → 必要な正答率（70%）に余裕を持てるように準備したほうが 良い
20. 以上