ゴーファーくんたちと探る Mendix の有用性/explore-usefulness-of-mendix

ミニ勉強会の資料です。

Transcript

1. 先端技術勉強会 技術講習会 2023/02 @iwasiman Advanced -STUDY GROUP- 第6回 ゴーファーくんたちと探る Mendixの有用性 Technology TECH-SESSION
2. 2 この技術講習会(先端技術勉強会)について ⚫ グループ紹介後のメンバー大幅増加に大感謝～!!(パフパフ♪) ⚫ 頻度は不定、基本1H、だいたい夕方にやっています。 ⚫ とりあえず始めてみて様子を見ながら続けています。 ⚫ 今回もスライドで資料を作りましたが、Web上のリソースなどの参照が メインになる回もあるかもしれません。 ⚫ 説明中も適宜間を挟むので、リアクションはその都度音声でもチャット でもOKです! ⚫ テーマはフリー、参加者から聞いたりして決めていきます。 次回テーマは [いよいよPythonかも?] でその後も募集中です! ⚫ 皆さんが講師をするのも大歓迎です! ゆるくやっていくので、気軽にいきましょう!
3. 第6回 ゴーファーくんたちと探る Mendixの有用性 目的： Low-Code PlatformのMendixについて ソフトウェアエンジニアリングの観点から、 モダンな他の技術と比較しながら 深掘りしてみる カニさんのフェリスが ジョインしたよ
4. ゴーファーくんたちと探る の有用性 1. Mendixとは 2. 基本的な仕組み 3. バージョン管理の観点 4. データベースの観点 5. ロジックの記述方法の観点・ Javaとの関連 6. UTのテスタビリティの観点 7. UI(画面系)のテストの観点 8. 変更容易性の観点 9. コード品質、CI/CD、 可読性の観点 10. コードアシスト、AI補助の観点 ①② 11. スケーリングの観点 12. クラウド、コスト、ｴｺｼｽﾃﾑの観点 13. アーキテクチャの観点 14. 過去の歴史の観点 15. 未来と不確実性への対応の観点 16. 世の中での知名度の観点①②③ 17. 開発者体験とキャリアの観点 18. おまけ：バズワード気味な言及 を検証するよ 19. おまけの続き：有用性のある範 囲は? 20. 本日のまとめ Mendixは Siemens Industry Software Inc. の登録商標です。 Mendix Studio Pro 1.92.0 を主な対象としています。 スクショは無料で使用できる試用版のものです。
5. 5 1. Mendixとは ◆ローコード(LowCode)： テキストベースのプログラミング言語の代わりにGUIと設定を用いて ソフトウェアを開発できないかというアプローチ。いにしえのエンドユーザーコンピューティング、 RAD、ビジュアルプログラミング、自動コード生成 (これら後述) の考え方の21世紀版の子孫 ◆その開発環境がLow-Code Platformで日本ではLCPと略されるが、英語では Low-Code Development Platform, LCDP が正しい略し方の模様 ◆Mendix: ドイツのシーメンス社が買収して展開しているLCP製品。OSSでなく有償。ローコード市 場のリーダー、ガートナー社の予測、世界中何千社で使用…など公式サイトでは華々しく紹介さ れている。エンタープライズ領域にも対応可能と謳っている ◆作り方が２通り：①簡単なアプリにはブラウザ上でのみ操作するMendix Studioを使用。元から 用意されているDeveloper PortalやTeam Serverなど一連のCI/CD的な仕組みを使える ◆②より本格的な開発にはMendix Studio ProというWindows用デスクトップアプリを使用。通常 の業務アプリレベルはこちら。今回の分析はこちらを対象 Mendix Studio Pro プログラミングにおけるIDE、 コードエディターに相当 すべてここからの操作する (オールインワンモデル) Subversion / Git でバージョン管理 （Team Serverも 一応使える模様） 業務データ、Mendixのシステム情報を RDBに保存する。 同一マシン上：ビルトインDB(HSQLDB) 別マシンも可：PostgreSQL, MySQL, Oracle, SQLServer, DB2 操作した設計情報がプロ ジェクトフォルダ内に各種 ファイルとして保存(プロ グラミングの場合と同じ) 内部的な変換、コード生成、 設定ﾌｧｲﾙ諸々、ビルドが行 われ、Webアプリケーショ ン物件が生成 JavaのWebアプリケーショ ンとして動作
6. 6 2. 基本的な仕組み ◆Mendix App(Mendixアプリ)がアプケーションの基本単位。その中にN個のModule(モジュール) という独自の単位で分割 ◆1モジュールの中： Domain Model(ドメインモデル)が1つ→中にN個のEntity(エンティティ) Page(画面)がN個 (今回深く触れません) バックエンドのロジックを記述するマイクロフローがN個 フロントエンドのロジックを記述するナノフローがN個 (今回深く触れません。マイクロフローと同様です) Mendix Studio Proで操作する ひとつのMendixアプリ ドメインモデル内 のエンティティ 画面 ナノフロー マイクロフロー 技術要素的には… RDBのテーブル群： ビルトインDB(HSQLDB) PostgreSQL, MySQL, Oracle, SQLServer, DB2 機械的に変換された Reactコンポーネント。 スマホ用ならReact Nativeでビルド JavaScriptコード になってビルド? JavaScript Java(+Scala)製の仕組み コードに変換でなく、設計 情報を内部で独自のDB? に保持している模様 バックエンド (サーバーサイド) フロントエンド (クライアントサイド) 部品やライブラリ 群も、実体はJava のjarファイルや JavaScript 他の技術との対比 →そのページまとめ 補足とか びっくり! 技術の登場年 (ほぼv1) Mendix用語と技術要素と強調 凡例です： 他、設定ファイル類 →内蔵されたTomcat上でJavaのWebアプリとして動作。
7. 7 3. バージョン管理の観点 ◆SubversionとGitの２択。Studio Pro上では、Update/Commitなど 基本的な操作のみ。(コマンドからの多種多様な操作を隠蔽) ◆画面追加、エンティティの追加、マイクロフロー追加などをするとローカルフォルダに何か作成されて いく方式かと思いきや…プロジェクトのルート直下の謎の巨大なバイナリファイル(.mpr)が 上書き更新されていく!(中は内部的なDBらしい) ◆テキストベースでの差分(diff)確認が一切できない。Studio Pro上でも確認しづらい ◆常に上書き更新なので多人数で同時に弄ったりマージの時に危険 ◆Gitは分散管理なので、ローカルにもリポジトリを持つ→上のバイナリファイルや諸々の履歴を持ち すぎてマシン容量が溢れることがある→実質SVNが安全 CVS VSS Mercurial バージョン管理 ツールのぷち歴史 (次世代は まだない) ほか色々 旧TFS →一世代前のSVNに甘んじるしかなく、 将来的には危険。大人数開発でも課題 Git: 修正テーマごとのブラン チ運用が可能。 GitHub Actions: プッシュ時に 様々な操作を行えるCI/CD GitHub Copilot: AIが文脈か らコードを推測! (後述) 2022 ◆別方法として、簡単アプリ作成でブラウザからやる方のStudioでは、Team Serverという所にコミット→ ビルド→Mendix CloudにデプロイしていくCI/CDの仕組みが整っている ◆こちらは未検証。またベンダー側に閉じた依存した仕組みになるので、普通はOSSのSVN/Gitを使うのでは Microsoftも昔はTeam Foundation Server(TFS)やVSTSというMS製品に閉じた仕組みを持っていたが、結局 Gitに切り替え、GitHubを買収して(2018)手厚くサポート。(TFSはAzure DevOps Centerという名で一応残存) 作りたてで7メガ 大規模PJだと 100メガ以上! 2004 v1 2010年代～ 2008- ふつうはコード、設定ファイルも全て プレーンテキスト(UNIX哲学の継承)
8. 8 4. データベースの観点 ◆ドメインモデルの中のエンティティ≒ほぼRDBの1テーブル、 オブジェクト≒RDBの1レコードなのだが… ◆永続保存したい業務データ(永続エンティティ、RDBとして物理ファイルに保存) ◆画面の検索項目や検索結果など一時的に使うもの(非永続エンティティ、メモリ上に保存) ◆バッチ的な処理、部品的な処理の中間データ ◆マイクロフローの入力/出力で使う、本来クラスや構造体であってほしいもの …と、複数のデータ種が１つのドメインモデル内に混在してしまう！ ←永続と非永続は 色分けで表示、 命名で区別する手も 本来のドメインモデル： 「ビジネスの対象領域(ドメイン)を抽象化して表現したもの（モデル）」的な意味。 エンティティ： 実体のあるなしに関わらず実世界にあるものに対応したプログラム内のｵﾌﾞｼﾞｪｸﾄ。“猫”とか”契約” 『ドメイン駆動設計』(DDD) という設計手法で頻出。 ◆１エンティティの簡単な検索はすぐできるが、複数エンティティ結合、部分一致検索などですぐ難しくな る ◆マイクロフローの中でOQL(SQL的なもの)で記述もできるが、制限が大きい。例：主キーの最初X文字だ けで結合、なども不可。SQL関数がほとんど使えない! ◆画面やマイクロフローから[Create object]-[commit]という操作をしないとデータが自由に作れない ◆SQLクライアントツールからDBの中身は参照できるが、Mendixが独自に振るIDを変えた途端に内部エ ラーで動かなくなったりする。テーブル名先頭にも モジュール名$が自動で振られてしまう ◆全てGUI操作なので、エンティティ数や項目数が増えてくると操作や移動がとても大変… 各言語のWebフレームワークはDBとの結合度は様々だが、基本独立している。マイグレーション機能を備えテーブル作成やデータ 投入SQLを生成してくれるものも。テーブルに対応したクラスを作ってくれるものもある。（Active Recordパターン） 結合度が低ければやり方を複数工夫できる： コマンドラインからcreate table文、テキストエディタで行コピーでcreate table文作成、 各種SQLクライアントツールで各種操作やデータ作成… →プラットフォームとDBとの結合度が高いのが大きな制限に
9. 9 5. ロジックの記述方法の観点 ◆バックエンドのコードの代わりにマイクロフローを書いていく。画面右のActivity一覧から選んで配置 ◆変数宣言はできるがスコープが１マイクロフロー全体(if文などのブロック内でない) ◆引数、戻り値ともプリミティブな値（文字列、数値、日付、真偽値..)やリストは使える ◆クラス、構造体のような独自のデータ構造が一切使えない。全てエンティティで定義。これが辛い! ◆データの入れ子構造も表現できない。(厳密にはエンティティのリレーションで頑張るとできるかも) ◆制御構造として分岐とループの２つは辛うじてある ◆セキュリティのロールの概念はあるが、プログラミング言語のクラスや関数の可視性の概念がない ◆構造化プログラミングの概念がなく全体が把握しにくい。フローから他のフローが無限に呼べる(GOTO文的) ◆Activityの中にJava Actionというものがあり、 Javaコードが書ける。制限多し(次頁) →「引数/戻り値と機能に大きな制限のある、グローバルな 関数とグローバルな変数」でのプログラミングとほぼ同等。 表現力がかなり低い 変数名の1文字目が 大文字でちょっとキモい ◆マイクロフローを記述中・実行中にエラーが起こると… ◆ルールに従っていないとStudio Pro下のConsole欄にMendix独自のエラーで教えてくれる。(英語) ◆検知できない実行時エラーはログに出され、クリックすると詳細はJava(一部Scalaも)のスタックトレース。 けっこうよく出る! いっぽう、プログラミングのパワーを活かせば技と武器は多数… ★様々な原理、原則 ★リーダブルなコードで変化に備える ★モジュール化で複雑さを分割で対処 ★オブジェクト指向のカプセル化、多態性、継承と汎化、抽象化 ★デザインパターン ★アーキテクチャの工夫 ★関数型言語のアプローチによる短い記法 ★不変値の活用 ★多彩な型による表現 ★型推論 ★言語ごとの固有機能、書き方 ★モダンな言語、コンパイラ、IDEの進化 …etc ⇒これらはMendixワールドではまったく使えません!! ⚫ 異常時にJavaのエラーが出る処理を、Javaよ り表現力が低い手段で書いているのと等しい ⚫ マイクロフローを書くレベルになると途端に 生産性が低下… ⚫ モダンなプログラミング・エンジニアリングの 進化に背を向けているのでは? →このエラー対処には結局Javaぢからが必要。 「プログラミング知識が不要」というのは完全に誤り
10. 10 補足) Java との関連 Mendix アプリ (N個のモ ジュール) １つのマイクロフロー内 Java Actionという Mendix上の単位 HelloGopherAction.java public java.lang.String executeAction() throws Exception { // ここがJavaワールド } Javaで書けるロジック 別クラスやライブラリを呼んだり 頑張れば別DBも呼べる 外部の別DB ◆Java Actionに指定したParameter: クラスのメンバ変数 Return Type: executeActionメソッドの戻り値 型の制限はマイクロフローと同じ ◆従って過去のJava資産はそのままでは使えない ◆大規模システムでのロジック実現の選択肢は以下の2択になる A) Java Action絶対禁止のルールにして全てマイクロフローで作りこむ ⇒Mendixのお作法に従った方法。しかし前項の通り、かなり表現力が低く制限も多く苦しい… B) Java Actionも使用可能のルールにする ⇒入出力の制限を除けば、Javaで書けることは理論的には全て可能。 しかしLowCodeの思想とだんだん外れてくる。 executeAction()発でロジック記述、トランザクション制御、SQL発行で別DBへアクセスし検索なども可能。 しかし戻ってきたデータは必ずMendix側の永続/非永続エンティティに移さないと画面に出せない。 画面系処理にしかMendixを使わないとなると、最初からJavaで開発した方がシンプルになる 現在のJavaのFWで生き残った ほぼ唯一の選択肢: Spring Boot 2022/11 v3! →Java Actionの存在が 長所にも短所にも 長い長い”神クラス(God class)”・”神メソッド”に なりがちな弱点アリ 有名な本たち “神クラス”の原典は さらに昔の本です 1996
11. 11 6. UTのテスタビリティ(Testability)の観点 ◆単体テストの定義は様々だが、Unit Test と言った場合、テストコードで関数をテストすることを大体指す ◆Mendixでもマイクロフローはユニットテスト可能になっている ◆テスト対象のフロー1個にテスト用フローN個、データ登録用フロー1個、共通処理でまた別に…とだいたい３ 倍以上フローが必要。マイクロフロー自体の作成の手間もあり、コスパが悪い ◆エンティティを扱う場合、SQL発行でデータ作成ができないのでマイクロフロー内でCreate object、CSVや Excelでインポートする機能を作る…など追加で工夫が必要 ◆テスト実行に至るまでのプロセスと時間が長い問題あり 対象コードと テストコード 実行ファイル この時点でコマンドなどから 即UT可能!! デプロイまで不要 Studio Pro側 の設計情報 ビルド （インタプリ タ言語なら不要) ビルド&デプロイに相当する [Run Locally] をメニューから選ぶと… デプロイ Webアプリ コード 生成 Mendix側の いろんな内部処理 ビルド デプロイ Webアプリ Mendix アプリ 通常の Webアプリ 画面以外のロジックのコードを細分化し、クラス や関数レベルでテストして品質を維持、最後に全 体をテストする方法はよく使われる。 各言語ごとにテスティング・フレームワークあり。 GoとRustは言語自体にテストの仕組みを備える。 『テスト駆動開発』 (TDD: Test Driven Development) という手法が有名。 →マイクロフローも一応UT可能だが、各言語 に比べるとかなり手間、テストしやすさ(テスタ ビリティ)が低い。ここでも生産性が下がる 常にここまで来て画面から押さないと、 テスト用マイクロフローが実行できない 大規模アプリだと平気で5分以上かかったり!! ブレークポイントを貼ってのデバッグも同じ 繰り返し
12. 12 7. UI(画面系)のテストの観点 ◆Mendixが生成する画面は、機械的生成のReactコンポーネントから生成されたSPA: Single Page Application方式。UIをテストしようとすると… ◆HTTPリクエストを発行する方式のJMeter: 伝統的なツールで主には従来のMPA用。操作を記録してサンプ ラーでHTTPリクエストを投げつける方式ではMendixアプリでは動かず ◆バックエンドの通信先のエンドポイントにのみHTTPリクエストを投げる方式もある： Mendixが完全隠蔽し ており特定が困難 ◆JMeter＋ブラウザ操作自動化のSelenium WebDriverのスクリプトの合わせ技でなんとか実行できた ◆ログイン→何かの検索→ログアウトのシナリオをJMeterで記録して中を覗いたところ… ◆SPAならバックエンドとの通信は数回で済むはずところ、数十回もHTTPリクエストを発行していた! ◆詳細な理屈は不明だが、画面内の1項目1項目すべてについて非同期にバックエンドと通信している模様… SPAの利点はHTML全体でなく必要な部分だけ を通信することで、通信量が減ること。(通信回数 も最低限に) これで速い画面描画とUX向上をも たらす。 MendixはSPAの利点を活かせていないことに! 大規模アプリでは性能問題の恐れあり。 いろんな通信先が用意 API API API 1画面内の複数のReactコンポーネントが個別に通信 Compo Compo Compo HTTPのネットワーク境界 React自体のテストの仕組みではJest＋React Testing Libraryが有名。 関数型のコンポーネントをテストコードでテスト。 GUIからのテストになると言語やFWが関係なく なり、Selemiumを始め各種。有償製品も多い。 →UI系をMendixの中に隠蔽しているため、 特有の課題あり。GUIのテスト全般について も、手動でやった方が速いケースも 2001 2004 2013 フロントエンド バックエンド
13. 13 8. 変更容易性の観点 ◆持続可能な開発：モダンなアプリやサービスは、開発後に拡張され続けていく。できるだけ修正範囲を 小さく、テスト範囲を小さく、他の機能への影響範囲を小さく抑えて追加し、デプロイし、開発体制を維 持しなければならない。修正時に影響範囲のより速い特定も必要 ◆画面の追加・修正 ◆特に課題はないが、エンティティと直接繋がっているとエンティティ変更の影響を直接受ける ◆エンティティの追加・修正 ◆操作対象のエンティティを間違えても気付く手段が少ない。(マイクロフローの戻り値と違う、などはエラー で気付ける) ◆エンティティのカラム追加、削除：そのエンティティを使っているマイクロフロー一覧は出せるが、1階層表示 ◆マイクロフローの中の１つの四角の中でOQL(SQL的なもの)でエンティティを操作しているとヒットしない どの言語でもコード内でSQL文を書いているなら、テキスト検索で確実に分かる。 Model層など特定レイヤーの関数でのみDBアクセスするようにしていれば、そこで 変更を局所化できる。 FWによってはDBアクセス専用クラスを自動で用意してくれるものも。 ◆マイクロフローの追加・修正 ◆処理の四角１つを追加するにも矢印を付け替える必要アリ。差分もテキストで確認できない ◆Javaのパッケージや他言語の名前空間のようなフォルダ分け(=モジュール化)の概念がない →そのマイクロフローを呼んでいるマイクロフローの一覧は出せるが、階層表示できない ◆スコープの制御がない→外部から呼んではいけないマイクロフローを隠す手段がない モジュール化は構造化プログラミングの基本概念。 可視性の制御はプログラミング言語の基本機能。 内部を外部から隠すカプセル化はオブジェクト指向の基本概念。 →修正の影響がアプリケーション全体に及ぶ 危険性を防御できない。変更に弱い エンティティを呼んでいるフローを検索した例 最新のコーディング本 言語はKotlin! 副題が「持続可能なソフト ウェア開発のために」 ※Mendixでのモジュールという のはより大きい別の概念です こう出てほしい例(VSCode)
14. 14 9. コード品質、CI/CD、可読性の観点 ◆コードフォーマッターや静的解析(lint)にあたる概念がない ◆マイクロフローの並び順やズレの整頓→シフトキーを押しながらの動きがOfficeに比べるとかなり微妙 ◆いまだに人間が手動で心を込めて整えてあげなければならない。モダンでない ◆例えばマイクロフローにコメントを書く、というルールを作っても人間が従い、人間によるチェックが必要。 機械でチェックできない フォーマッターはモダンなIDEや拡張機能には各種搭載。ファイル保存時やコマ ンド実行で呼び出せる。言語ごとに設定も変えられる。CI/CDでコミット時に走 らせたりと工夫も各種可能。 GoとRustは言語自体にフォーマッターを備えており、コマンド一発。 ◆CI/CDや自動化 ◆Studio ProはGUI操作が基本なので、コマンドからできることが少ない (モジュールを一気にインポートしてまとめてビルド…なども不可) ◆Studio Pro上の操作をRPA技術などで自動化もできそうで意味はあるが…コマンドから可能なのが本来の姿 ◆アプリケーション全体の定数なども定義できるが、GUI上。設定ファイルに外出しできれば自動化へ繋がる… 例えばAWSは、管理コンソールからポチポチ操作でき ることは全てコマンドからできるようになっている。 (aws cli) リソース操作自動化用のサービスCFｎも。 ◆マイクロフローの可読性 ◆１つ１つの四角(Activity)を1回以上クリックしないと詳細が参照できない。常に一度にひとつ ◆全体を一度に見通す手段がないので、プログラムの１関数のコードに比べると可読性がかなり低い 理解するまで脳に認知負荷がかかってしまう… 結局、ビジュアルプログラミングは効率が悪く一般化もしていない 2015 →こうした、中～大規模の本格開発でとても 重要になってくる要素全般が弱い。 やはり小規模な開発がターゲットでは?
15. 15 10. コードアシスト、AI補助の観点 ① ◆マイクロフロー内で変数、他のマイクロフローやエンティティをコールしようとすると… ◆ドット(.)入力でアシスト的なことはしてくれるが、アルファベット順。補足コメントは出ない。 フォルダ分けの階層表示などもない。VSCode＋拡張機能群の優秀さには及ばない モダンなIDEでは関数コメント含めてホバー表示が基本。その言語 の組み込み関数なら解説も出してくれたり、かなり自然にアシスト してくれる。 Language Server Protocol (LSP)という規格が2016年に制定され、 言語問わず、様々な開発ツールからアシストできるようになった。 ◆MxAssist Logic Botというアシスト機能が一応あるが、オプション。重くなるのでオフにすること が多い Visual Studio/VSCodeでは、GitHub上の大量のコードから機械学 習したAIがアシストしてくれる IntelliCode が2018年から既に存在。 (左スクショ) 次に入力する可能性の高い関数や変数を★で優先表示してくれる! VSCodeの例 （PHP） Visual Studioの例 （C#） Studio Pro でドットを 押した例
16. 16 ?? 10. コードアシスト、AI補助の観点 ② GitHub Copilot: (2022/6) 月10$。チャットベースでコメントからのコード生成、一定範囲のコードの要約出力、 予測、同じ処理の他言語への変換など。Open AI社。背後の言語生成モデルはChatGPTと同じ。 コパイロット=“副操縦士”、このワードがBingでも使われている ChatGPT: (2022/11) 話題沸騰中のチャットボットAI。2021年までのインターネット情報を元に学習。OpenAI社。 Microsoftは買収でなく協業、1.3兆円を出資。Azure OpenAI Serviceにも入った 新しいMicrosoft Bing: (2023/2) ChatGPTの強化版が搭載、順次使えるように。”ググる”に”ビングる”が加わ るかもしれない胸アツ展開。 Bard: (2023/3?) Googleは言語生成モデルLaMDAをベースにした別AIで対抗。創設者のセルゲイ・ブリン氏も 関わっているとのこと。 ◆最近話題のチャットボットAI周り： GitHubやインターネットから無限に学んでくるぞ! →プログラマーのコーディングの一部を助け、言語を問わず人間＋機械で 快適に協調作業していく進化の方向 一方LowCodeはコードそのものをなくそうとし(そしてなくせてない)、 別方向に向かっているのでは? AI方面は進化できないのでは? 既にVSCodeの拡張機能 あり(対話は有償) インターネット上の情報 GitHub上のOSS 様々な言語の大量のコード、 コメント、テキスト類 やりたいこと このコード やりたいこと このコード やりたいこと このコード 大 量 の 重 み 付 け 学習 演算 より精度の 高い回答 Q:~したいんだけど? A: このコードです!! MendixアプリはGitHub上には配置 されなさそう 設計情報は非テキストのバイナリ ファイルの中、学習材料不足 シーメンス社もAIの会社ではない 学習できない のでは？
17. 17 11. スケーリング(Scaling)の観点 ◆モダンなアプリケーションは機能が追加されどんどんスケールする。 Mendixでアプリケーション規模が大きくなってきた際の開発作業への影響は… ◆Studio Proの操作全般 ◆設計情報を格納したバイナリファイルが巨大(100M以上)になり、どんどん重くなってくる。稼働だけでメ モリ2G以上消費、基本動作が超絶重い!! コミットも時間が掛かってしまう。 ◆メモリ16GのマシンでもTeamsと同時起動だと遅い。8Gのマシンだと基本かなり辛い。 ◆デプロイして画面が動くまでに5-6分以上、Webサーバー稼働中はメモリ3G以上消費したり… ◆エンティティの操作 ◆Mendixアプリ上の1モジュール内にドメインモデルは常に1つだけ。エンティティ数が膨大に→どんどん視 認性が低くなり理解が困難に ◆分類や業務領域に応じて手動で上下左右に分類する方法もあるが、掴んで移動するだけでも重い!! ◆マイクロフローの操作 ◆フォルダ分けで分類しても設計情報上は同じ階層なので、検索しても階層表示できない。100個以上並ん だりすると本当に見づらい。 ◆右クリックからの複製やコピーなど基本操作がもう数秒待つぐらいに ◆GUI操作が基本なので、基本操作はドラッグ&ドロップ、矢印の付け替え、クリックしてプロパティをまた開 いて…とカチカチの連続。これらがすべて重くなる。 →タイピング、テキストベースでの関数コピーやクラスコピーなどの動作の方がはるかに速い… →各技術要素と密結合し、全てを Studio Pro内で閉じて操作する という思想がネックに。大規模開発 では生産性が大幅低下 VSCode自体がJavaScript/TypeScriptで動いており、コード規模が大きくなっても重 くなりにくいように工夫。プログラミング言語では… TypeScript言語: 型サポートでスケールする大規模開発をサポートするのが主目的 Go言語: 元からGoogle社内の大規模サービス開発を想定。スケールする複雑さに 秩序をもたらすのがコンセプトのひとつ Run Locallyで出るダイアログ
18. 18 12. クラウド、コスト、エコシステムの観点 ◆Mendix Cloud 始め各種クラウドにデプロイ可能 ◆このMendix Cloudは実際にはAWS上にある。AWSの料金＋Mendix側の料金が掛かる理屈になる ◆１クリックでデプロイ!とあり簡単。(同時に細かな調整ができないことでもある…) ◆Mendixアプリの実体はJavaアプリケーションなので、これをAWSならEC2インスタンスに載せているだけ。 (監視系のサービスも自動で備えてくれたりするのかも…?) Amazon EC2は仮想マシンを立ち上げる一番基本の サービス。AWSの一番初歩的な使い方となります。 ◆コストの観点 ◆紹介資料にあまり出てこないが、ライセンス費用がかなりお高い。以前調べた時に年間数百万～大規模アプ リならもう１桁まで ◆費用を抑えると、EC2インスタンスがAuto Scalingしない→ユーザ増加時のスケールに対応しなかったり オープンソースソフトウェア(OSS）の時代： 今はプログラミング言語、フレームワーク、ライブラリ、開発ツール、データ ベースまでもほとんど無料が基本。(パブリッククラウドサービスは例外) 様々な技術はGitHub中心にインターネット上にオープンに存在。スター数 などの人気、エンジニアのコミュニティやイベント、インターネットでの話題 性や知名度、実際に使っている開発者からの支持で評価される。(お金以 外の尺度) 支持された技術には人が集まり、善意でOSSが改良され、エコシステムが 活性化し、技術が進化していく。 エコシステム： 元は生物学の生態系の用語。エンジニアリングの世界では、 一定範囲内での言語やFWやライブラリ、技術が互いに依存したり影響し あいながら発展していくこと。”JavaScriptエコシステム”とか”Reactエコシス テム”のように使う。 →Mendix Marketplaceという ライブラリ公開所のようなものはあるが クローズド。賑わっているかというと…? コミュニティの場所もあるが、Mendixと いう単一技術にクローズドである。 質問/回答もすべて英語のみ GitHub上のReactは ２０万スター!!★
19. 19 13. アーキテクチャの観点 エンティティ （≒DB） 画面 ナノフロー マイクロフロー HTTPのネットワーク境界 データベース層 永続化層 ビジネス層 ﾌﾟﾚｾﾞﾝﾃｰｼｮﾝ層 リクエスト 標準的なレイヤード アーキテクチャ Mendixだとマイクロフローに構造 化の概念がなく、層による「関心事 の分離」「依存方向の制御」ができ ない。変更容易性、保守性に大きく 影響してしまう。 モダンなアーキ例：分散型の マイクロサービスアーキテクチャ DB サービス API層 DB サービス クライアント クライアント API層 Mendixアプリはフロントエンドとバッ クエンド(図のネットワーク境界の上下) がそもそも密結合しているので、マイク ロサービスが適用できない。 結合か分散かで言ったら密結合、伝統 的なモノリシック(1枚岩)アーキテク チャ的アプローチ。 ネットワーク境界 →アプリに秩序をもたらすアーキテク チャは中～大規模の本格開発で必須。 この領域が未考慮、退化している ソフトウェア・アーキテクチャ： 設計よりやや大きい粒度の構造。複雑さを「分割で対処」、 処理のかたまりは「凝縮度を上げ」、かたまり同士で「結合度を下げる(=疎結合)」が重要概念である。 Studio Pro上は意識しないので、どこ からでも一番奥のDBに自由にアクセス できてしまう。 現代の[UI→ビジネスロジック→DB] の「3層アーキテクチャ」より、 古い時代の[UI→直DB]の「2層アーキ テクチャ」に近い。昔に戻っている。 ITエンジニア本 大賞2023 ノミネート!
20. 20 14. 過去の歴史の観点 ▪画面～DB直でマッピング、シンプルなCRUDアプリを作ろうという人類の探求… Naked objects パターン: DBのテーブルから取ってきたドメインオブジェクトにロジックを埋め込んでUIから呼ぶようなアーキテ クチャパターン。2000年代の古い海外書籍や英語Wikipediaに一応記述あり。現代では使われていない。 C#言語のNaked Objects for .NET: これを実装したフレームワーク。過去のもの。(2008) Java言語のApache Isis: これを実装したドメイン駆動設計用のレームワーク。知名度なし。(2012) C#言語のAST.NET Web Forms: (2002) Web用だがWindowsフォームと同じように画面を作るスタイルのFW。完全隠蔽された HTMLコードが汚く、裏で勝手に通信をしていたり評判悪し。その後より洗練された ASP.NET MVC (2009頃-)に交代。 ▪スキャフォールド(Scaffold)もしくはスキャフォールディング(Scaffolding)機能： コマンドでRDBの1テーブルの情報を打ち込むと、対応したDBクラス、ロジックのクラス、画面系…と一式コードの雛形を自動生成、 そのままCRUDアプリが動くところまで大体やってくれる。バックエンドのWebFW群が備えている。英語の「足場」「骨組み」の意味。 Ruby言語のRuby on Rails: (2004-) 以下４つ、各言語を代表する現役のフレームワーク。ゼロ年代から既に実現可能である。 PHP言語のLaravel: (2011-) Python言語のDjango: (2005-) C#言語のASP.NET MVC: (2009頃-) その後 ASP.NET Core に (2016-) Java言語のSpring Framework: (2004-)には機能なしの模様。滅んだいにしえの JavaServer Faces(JSF)、Struts にも機能なし。 フロントエンドのJavaScript/TypeScript言語関連: 余談。プロジェクトディレクトリ作成の際、関連ライブラリの取得や設定ファイ ルの初期設定など諸々を準備してくれる機能も同じく「スキャフォールド」と呼んだりする。 ▪より簡単にアプリを作ろうという人類のこころみ… エンドユーザー・コンピューティング(end-user computing, EUC): 技術者以外でもアプリを作れるシステムは生み出せないかと いうアプローチ。～1990年代頃によく使われたワード。決定的なツール等は特に登場せず。 Rapid Application Development, RAD: 少人数チームで高速にプロトタイプ開発をしていこうというというやり方、あるいは開 発ツールによるコード半自動化。Visual Studioもいちおう範疇。今は使われないワード。アジャイルの遠い親戚。 自動プログラミング(Automatic programming): 1940年代の紙テープパンチ処理自動化から始まっている。(!) 人類の指示なし での完全自動生成は未達。各種IDE、フレームワーク、ライブラリが定型部分を半自動生成してくれることを指す。 ビジュアルプログラミング言語(Visual programming language): テキストでなく視覚的な図形でのプログラミング。子供向けの プログラミング教育用のものなど。 実は色々な言語があるが、通常のアプリ開発で使われるメジャー言語には結局届かず。 →Mendixの方向性は既に人類が探求済み。 過去の流れにNoCode, LowCodeという 新しい名前が(バズワード気味に)付いたのが現在
21. 21 15. 未来と不確実性への対応の観点 ◆Mendixで使われている要素技術を評価してみよう ◆バックエンドの言語： Java 既に後継言語のKotlinが出ており、 過去のJava資産が不要であれば採用する理由がなくなってきている ◆フロントエンドのJSフレームワーク： React 現在は◦、将来は△ 。ほぼ覇権となったReactを選んだのは◎だ が、機械的に呼んでいるだけ。フロントエンドは技術の流行り廃りがとても速く、変動する可能性も大きい ◆スマホ用のクロスプラットフォームFW： React Native 2022年頃からGoogle発のFW、Flutter(Dart言語を使 う) の方が優勢になっている。今後他の技術が登場する可能性も十分ある →変化をMendixがすべて吸収してくれる保証は? バージョンアップで作り直しの可能性も 商用ツールに全てを委ね依存するスタイルは今のOSS時代には危険、ﾍﾞﾝﾀﾞｰﾛｯｸｲﾝそのもの ◆もしもMendixを使うのを将来やめるとしたら、作ってきた資産は再利用できるかというと… ◆DB内のデータ： 著名RDBを使っていれば恐らくエクスポート可能。内部で持っているIDを外す必要あり ◆バックエンドのロジック： マイクロフローはJavaコードに変換されるわけではないので、一切無理 マイクロフロー内のJava Actionから呼んだJavaコードなら、部分的に再利用可能 ◆画面やフロントエンド側のロジック： Reactを機械的に使っており中のJavaScriptは読み解けないので無理。 ◆片側だけの置き換え： Mendixアプリはフロントエンド-バックエンドが密結合しており、バックエンドだけを 他の言語やFWベースに置き換え、フロントエンドだけを他のJSフレームワークで置き換え、ができない ◦-△ △ △ × ×,△ △ × 変化への対応は様々な工夫が… ・フレームワーク固有のコードを特定の層で食い止める ・ライブラリを包み込んで(=ラップして)使う ・Clean Architectureなどの構造での工夫 ・マイクロサービス: サービスごとに区切られるので、 それぞれを別の言語や技術で開発できる 技術的負債(Technical Debt)： スピード優先の開発で発生した、目に見えな い不可視のコストのこと。注目ワード。 →Mendix自体が大きな技術的負債になる 可能性もあるのでは? JavaScriptの主要3フレームワーク ２０16 v1 2012 2013 2015 フロントエンド バックエンド Mendix内はReact17.0.1 (2020/10) 最新はReact18.2.0 (2022/5)
22. 22 16. 世の中での知名度の観点 ① オープンソースの文化：ソースコードだけでなく情報も公開、共有される 技術の価値はGitHubのスター数、ググラビリティ、SNSやQAサイトやブログなどでの見つかりやすさ、アンケートやラン キング、出ている本の多さや話題に上がりやすさなどで決まる。インターネットでオープンに情報を得られるかは鍵。 ◆単純にMendixでググる：→50件を越えたあたりでもう英語。他社事例や使ってみた記事がない。他の モダン言語でも、120件ぐらいは日本語で情報が出てくるのが普通。 ◆安心の技術書、オライリー：2023年ブックカタログ（約300冊）にて… →LowCode関連の本はゼロ冊。 ◆アマゾンの本：「ローコード」「ノーコード」で探してようやく… →技術書でなく読み物が数冊。 MicrosoftのPower Platform関連は4冊ほど。 モダンな言語の本 Kotlin: 約17冊 Go: 約15冊 Rust: 約24冊 ◆YouTube: Mendix公式チャンネル→登録者6710人のみ 国内のテック系チャネルでも大手10万～海外なら100万台以上も ◆2ヶ月1回の『WEB＋DB PRESS』、月刊『Software Design』：定番雑誌。 →両雑誌とも2016年まで遡り、ローコード関連の特集回数ゼロ。 ◆企業技術ブログ：はてなブログに2022秋堂々オープン、日本の400社以上のテック企業が発信中。 →技術トピックにノーコード/ローコード関連はなし。 ◆Stack Overflow Developer Survey 2022: 毎年発表、世界の開発者7万人の アンケートからなる、信頼できる統計。愛される言語でRust言語が7年連続TOP。 →NoCode, LowCode, Mendixはそもそもワード自体が全く出てこない。 開始２０１１年、”ローコード”という名称が生まれたのが2014年、Mendixの名前は3-4年前から。 本当に素晴らしい技術なら沢山の人が価値を認め、インターネットで言及されるはずである。 →ソフトウェアエンジニアリングの世界では、人気のある/なし以前に認知されていないのが現実。 さらにインターネットと求人の状況を深掘りしていくと… https://hatena.blog/dev
23. 23 16. 世の中での知名度の観点 ② 媒体 Java C# PHP Ruby Pyt hon Java Script Reac t Type Scrip t Kotli n Go Rust AWS Azur e Low Code Men dix Qiita 21,39 4 14,47 4 27,538 38,808 69,66 8 50,996 13,89 9 11,33 5 6,403 11,79 6 3,691 34,76 3 6,873 25 19 Zenn 793 812 1,554 1,263 4,141 4,016 3,386 3,495 672 1,970 1,079 3,589 765 0 0 はてな ブック マーク 19,61 8 (417,5 84) 83,164 15,150 31,01 6 37,451 15,03 0 10,64 8 3,563 5,902 7,732 36,76 3 9,704 46 19 note 45,00 0 (992,0 00) 99,000 15,000 43,00 0 26,000 18,00 0 3,000 1,000 900 (6,000 ) 21,00 0 8,000 75 10 Terat ail 最大 値 最大 値 最大値 最大値 最大 値 最大値 最大 値 2,594 2,316 1,577 318 最大 値 546 タグ なし タグ なし Stack overfl ow 1,886, 377 1,580, 143 1,455,3 02 227,26 1 2,101 ,393 2,473,1 23 442,1 26 207,8 54 84,67 2 67,39 1 34,32 7 147,8 36 128,2 73 15 79 単位：言及された件数もしくは質問件数 “LCP”は別の技術用語でも存在するので”LowCode”を使用。 “Go”は疑わしい場合は”Golang”で検索。”Rust”も別ゲームのタイトルがヒットして いる場合あり。”C#”も”#”が誤検知の場合あり。若干疑わしい数値は()で灰色。 Qiita: トピックの記事数 Zenn: トピック検索でArticle数、ない場合はキーワード検索 note: キーワード検索 はてなブログ: タグ検索で件数が出ないので掲載を断念… はてなブックマーク： 検索対象：すべて でキーワードで検索 Teratail: 質問件数が多いと1万件でストップ、”最大値”と表現 Stack overflow: 英語版でタグ検索 →他の技術要素は数万件、QAサイトでは 数百万件あるなかで、言及数2桁のみ。 Stack OverflowのPythonの質問 2万7千件に対し、Mendixの質問は1件 だけの計算。 「媒体」のうち上３つ：エンジニア界隈 の情報共有サイト note: 一般向け 下2つ: 代表的Q&Aサイトです。 定番言語 ﾌﾚｰﾑﾜｰｸ 21世紀生まれの モダンな言語 クラウド
24. 24 16. 世の中での知名度の観点 ③ 媒体 Java C# PHP Rub y Pyth on Java Scri pt Reac t Type Scri pt Kotli n Go Rust AWS Azur e Low Cod e Men dix Forkw ell 388 (757) 285 396 440 405 616 565 261 284 31 963 159 0 0 LAPR AS 146 58 179 316 324 337 411 545 155 308 31 591 23 タグ なし タグ なし Paiza 転職 233 168 176 93 175 230 109 (32) 60 36 3 110 33 0 0 Want edly (2064 6) 7,930 23,25 8 17,09 4 18,79 0 20,07 5 10,76 6 8,314 4,858 2,026 348 18,93 0 3,089 11 14 レバ テック キャリ ア 6,218 2,403 4,319 2,877 4,249 4,475 2,267 1,661 1,447 1,757 159 7,022 2,614 5 13 RECRUI TE AGENT 24,10 8 11,23 9 8,811 3,350 9,817 7,639 3,774 2,780 2,112 332 389 13,71 1 5,941 6 45 Green 6,083 7,214 5,259 3,171 4,861 5,411 3,216 2,721 1,686 2,182 222 8,418 2,599 7 17 Indee d 355,8 23 199,7 19 235,3 23 126,0 82 (26,47 5) 355,9 56 100,0 43 83,60 3 67,44 3 10,80 8 3,698 307,5 77 128,6 28 113 230 単位：求人数 いずれもあればタグや開発言語で検索、なければキーワード 検索。件数が若干怪しいものは()で灰色。 Findy及びQiita Jobsは検索件数がうまく出ないので断念… Geekly, Bizreachはユーザー登録必須のため行わず。 →他の技術要素の求人は多くて 数千～数万ある中で、ほぼ2桁のみ。 比率では1/500-1/1800 「媒体」の上側がエンジニア系 ポートフォリオ系サービス、 下側が一般の転職サイトです。
25. 25 17. 開発者体験とキャリアの観点 ◆Mendix Studio Proでの開発者体験（DX: Developer Experience）全体をまとめると… ◆簡単な画面ならGUIで作れるのは楽。アプリ規模増大でとにかくStudio Proが重くなる。SQLで書けることが ドメインモデル/エンティティの仕組みではできない、プログラミングならすぐできることがマイクロフローで はできない…と制限が多くもどかしい。かなりストレスフル ◆OSSが流通した今日では、オールインワンモデルの考え方が流行らない。日本語化対応もまだ ◆開発でメインに使うツールの使いやすさは生産性に直結する。VSCodeの優秀さとは比べ物にならない →LowCodeのメインターゲットの市民開発者(Citizen Developer)には向いているが、 本職のソフトウェアエンジニアにとってDXは高いとは言い難い ◆Mendixでの開発経験がその後のWeb開発のどこで役に立つのか ◆フロントエンド領域： フロントエンドエンジニアに必要なスキルはHTML,CSS,JavaScript/TypeScript, フレーム ワークやライブラリ、ビルドシステム…。覇権のReactを使ってはいるが全て隠蔽されている。Mendixでの開 発経験は役に立たない ◆DB設計： エンティティ設計は経験になる。(…が、それはどのRDBを使っても同じではある) ◆バックエンド領域： マイクロフローはプログラミングより表現力がかなり低い。論理的な考え方を鍛えるには 役立つかも? (でも社員教育でやりますよね…) もしJava Actionを使っていれば、狭い範囲だがJava開発 スキルにはなる ◆Webアプリケーション開発全般： 通常のWeb開発より隠蔽されているところが多く、学びが薄い。問題解決 能力があまり育たない ⚫ Mendix全般の学びが薄く、ネットでも情報がほぼなく、求人も少ない。とするとMendix開発のみ をスキルとした人の市場価値はかなり低い。→開発者のエンゲージメント低下に繋がるのでは? ⚫ Mendixで実現できるレベルのシステムしか作れないことになり、Mendixで実現できるレベルの 人材しか揃わないことになる。 →会社や組織として技術力低下に繋がり、プログラミングすらできない会社と思われないか? × × ◦ ×-△
26. 26 こうしたコードに対する後ろ向き な気持ちや技術を軽んじる姿勢が、 LowCodeへの過度の注目、 誤った期待、肥大した幻想 とマッチしたのでは ないでしょうか。 18.おまけ：バズワード気味な言及を検証するよ ◆「AIが開発を助けてくれます!」 ◆「Kubernetesを標準採用しています!」 ◆「一説には生産性１０倍です!」 ◆「CI/CD, DevOps, クラウドです!」 ◆「クラウドネイティブアプリケーションです!」 ◆「プログラミング不要! コーディングレスです!」 ◆「デファクトスタンダード!」「これからの主流です!」 「次世代のモダンな技術です!(ｷﾘｯ」 k8sはコンテナに載せるアプリはなんでもよく 採用不採用は関係ない。Javaアプリは特に親 和性は高くない。(高いのはGo, Rust) Gitのブランチ運用ができないという欠陥あり、 自前のGit,SVNならCI/CDは自分で作る必要あ り。流行りのキーワードを全部載せてる感… クラウド特有技術をフル活用し、クラウド上で のみ存在できるようなアプリのこと。 AWSでは通常サーバーレス(Lambda, API Gateway, S3静的ｻｲﾄ)、あるいはコンテナ(ECS, EKS)、マイクロサービスなどを活用した組み 方を指す。EC2に載せただけではクラウドネイ ティブではない。Lift&ShiftのLiftしただけ。 深掘りしてきた通り。 長い長いマイクロフロー 作ってみましょう(ﾆｯｺﾘ) 誇張が大きい。Javaはモダン言語への置き換え 対象。Mendix等が居る場所は既に―― 他の技術がx年前に通過した場所だッッッ 深掘りしてきた通り。 本格開発では0.x倍では？ 拡張性・変更容易性・複雑性等 への観点が抜けてる事が多い MｘAssist Logic Botはおまけ機能 でそっとオフにしています… ◆従来型大企業にありがちな言説… ◆上流工程の方がエライ ◆プログラミングは単純作業だ ◆Excel設計書があればコーディングは誰がやっても同じだ ◆AIが発達すれば不要になる! （だから勉強しない俺はｴﾗｲ） ↑モダンなソフトウェア開発の名著・良著はいくつもあります が、こんなことを言っている本は一冊もありません!! そもそもプログラミングは設計の一部で、コードこそが動く アプリの中身、価値の本質です。 ネタです
27. 27 19. おまけの続き：有用性のある範囲は? かんたん 小規模 複雑 大規模 市民開発者、 非エンジニア層 ソフトウェア エンジニア層 ソフトウェア 開発の難易度 NoCode, LowCode の領域 一般人 こうしたツール に幻想を抱く 人の理想 現実の越えら れない壁 Mendixが向いてそうな用途： ★数エンティティで用が足りる程度の 小規模DBで済むシステム ★開発メンバー数が少ない案件 ★作ったら終わりのシステム（変更容 易性の低さを打ち消し) ★CRUDの簡単な画面(しかし、この分 野はライバル多し、Mendixはオーバー スペック&お高い) ★ロジックがないシステム(マイクロフ ロー禁止縛り) ★大規模、画面が多く、かつ簡単なシス テム(って存在するの?) ★他システムとの連携(マイクロフロー のActivityの四角でいろいろ繋げる) ★作り直し前提で仮で顧客に見せるシ ステム(アジャイル的。でも画面イメージ だけでも済むような…) ★非エンジニア層が日頃の困りごとを システム化して楽をする用途(本来の NoCode, LowCodeの領域)
28. 28 20. 本日のまとめ ◆半ばバズワードと化しているLowCode関連ですが、 複雑性、スケール、不確実性なども考えていくと有用性があるのは やはり小規模開発までと考えられます。 ◆ソフトウェアエンジニアリング界に昔から伝わる格言に 『銀の弾丸はない (No Silver Bullet) 』 の言葉があります。 ◆あらゆる問題を解決する万能の技術は永遠に存在しない｡ ケースごとにその時点でのより良い選択を行い、そして未来の変化に 備えていくのが、不確実性の時代のエンジニアリングです。 Creative Commons Attributions 3.0 The Gopher character is based on the Go mascot designed by Renée French. それではまた次回！ 資料中の様々なロゴやマスコットはその言語や技術の公式・非公式のものです。書影はその書籍・雑誌のものです。 ぼくらが生まれる 前の本だ! 故フレデリック・ブルックス さん (Wikipediaより) 1986