ブログ記事13件
昔、僕は、アプリケーションで、アプリケーションを製作するソフトを使っていた。ローコードノーコードだ。結構、便利が良い。なんでもできる。GeneXusは、業務内容を記述するだけでデータベースやプログラムを自動生成できるツールです。昔、使っていたぞ。画面に出ている（ような）、ソフトを作った。ハンバーガーショップの、シフト表。（仕事表だったかな）コンピューターなど。確か、ジャニー先生がいる時代だ。ジャッキーさんとかもいたかな。後、岡田総理が、作っている。
監視カメラAI監視カメラにAIが入らないだろうか。画像をカメラで録画しながら、キーワードで、アイテムゴトも、ソースコードで、録画する。あれは人帽子をかぶっている。帽子車黄色サングラスなど。もし、事件が起きたら、だいたいの時刻と、キーワードを打ち込むと、監視カメラの、画像が、早くヒットする。GeneXusとかエクセルとか、監視カメラの、データ管理ソフトに、組み込まないかなあ。
GeneXus15がついに日本デビューしました。Evolution○○ではない久々の「メジャーバージョンアップ」ということで盛り上がっておりますが、それにふさわしい機能がGX15の目玉として実装されています。「ダイナミックトランザクション」です。一言でいうと、GXのIDEからDBMSにCreateViewができる、ということですが、その言葉から想像するよりかなりすごく、「作らない開発」をまた一歩前進させる可能性があるのです。つまり、今までの「作らない開発」においては、「異なる構造を
少し前に、「GeneXusによる作らない開発の成功事例」として、某コミュニティにてプレゼンされていたT社のシステム、こちらはプロジェクトIの発展形でありGXによる作らない開発としては現時点で集大成に近い作り方がされていたと思います。そのプレゼンの最後で、「100%画面はWorkWithなのですか？」という質問がありました。私は100%だと思っていたのですが、プレゼン者の回答は違っていて、「運用開始後に1画面だけWebPanelで作りました。選択した期間の分を集計表示する画面、これだ
構造で解決を真髄とする作らない開発では、WorkWithと並んでGeneXusの機能で大事なのが再編成という機能です。よく競合扱いされるWagbyやWebPerformer、OutSystemsなどでは真似ができない最大の違いがこの機能であり、むしろGXをそれらの競合である「超高速開発ツール」ではなくGXという独自ジャンルとしているものだと思っています。とはいえ、この機能は導入時にはそれほど細かく説明されませんし、開発者もそれほど有効に、かつ頻繁に使っている例はあまり見かけま
作らない開発というよりGeneXusそのものの話。ツール(IDE)の使い方やオブジェクトの作り方についてはよく説明されていますが、割とおざなりにされるのが、GeneXusらしい設計の仕方の話です。項目名はKB内で唯一無二であり、オブジェクト指向でいう所のオブジェクト名やテーブル名などでは修飾されない、という話は有名です。しかし、よく考えるとその話は最初だけに出てきて、実際使い始めたら「そうしなければ使えない」から仕方なく唯一無二にしている、ような感が満載のKBをしばしば見かけ
今まで散々「作らない開発」「作らない開発」と連発していましたが、GeneXus的な作らない開発を一言で言えば、以前の記事のタイトルにある「構造で解決」で終わってしまいます。では、なぜ構造で解決すると作らなくできるのか？それは、GeneXusにはWorkWithという万能画面が標準装備されているからです。裏返すと、GeneXusによる作らない開発＝WorkWithを使ってWebPanelを使わないこと、と短絡的に考える人も非常に多いわけですが、それは少し違って、まず構造で解決
実は失敗の表彰案件と隠れた実力者案件、なぜこうも違いが出たのか？期間がほぼほぼ並行していたとはいえ、プロジェクトIのほうが若干スタートが遅く、その若干の間にプロジェクトNのうまくいっている点、有耶無耶になってしまったが当初計画通りであればよかったであろう点のみを抽出した効果が一番大きかったようです。ストーリーポイント管理の継続、プロジェクト憲章の順守、特に画面を受け入れること＝WorkWithベースの画面のみでまずは全範囲をカバーすること。そのためには多少大きな手戻りも辞さな
プロジェクトNの途中で私はプロジェクトIの開発にどっぷり入ることになり、プロジェクトNの話は思い出したように単発の質問を受ける、くらいの関わりしか持たなくなったのですが、１サブシステムは完全に作り直し、リスケにリスケを重ねた結果大幅なコストオーバーランになりながらも現場の踏ん張りによって何とかサービスインにこぎつけたとのことでした。ビジネス的には完全に失敗、元々アンチが多かったGeneXusのツールとしての評価も低下、表面上は関係ないとされながらもやめる人が続出、という惨憺たる有様
もう少し構造の話をしましょう。件の帳票甲乙は、マスタの設計と全く乖離していたために、SDTを使ってメモリ上で照合・集計をしながら出力する、というロジックを組まなければなりませんでした。SDTはGXの重要オブジェクトの一つで、C言語なら構造体に当たるものですが、こいつがなかなかの曲者なのです。構造が全く乖離していてもSDTを使えば何とかなる、ということはSDTを使えば構造を無視することができる、ということなのです。しかも、一見して構造体やスタティック・クラスなどに似ているので
プロジェクトNに話を戻しましょう。同プロジェクトでは帳票が約150種類あったのですが、大部分をGXネイティブの帳票機能で賄っています。誰が言ったのかわかりませんが、GXは帳票が弱いということになっていますが、「専用の帳票ツールに比較して」作るのが大変である、という意味で、例えばJavaネイティブに作るのに比べたら断然簡単に開発できます。それはいいとして、ある帳票機能の作り方について、GX経験の少ない開発者Aから相談をうけたことがありました。その帳票甲は、マスタで指定した順番に
さて、前回の「C構造で吸収する」です。ちなみに最近は「構造で解決する」と称しています。これは、今までの開発方式だと、いろいろなデータストアやオブジェクトから必要なデータを抽出し、ビジネスロジックを使って集計や照合を行いましょう、としていたところ、データの配置と関連性でその大部分を賄ってしまおう、という発想です。つまり、従来「開発者の利便性」のためだけに蔑ろにされがちだったRDBMSの参照整合性を最大活用するのです。一見、GXの一般的なプレゼンとセットで出てくる「データ中心
そもそもGeneXus開発者であってもGXで何ができるかわかっていない…このことに気づくまでかなり長い時間がかかってしまいましたが、今思い返すと初めて数社のGX開発者と共同で開発を行ったプロジェクトNがその哲学？の原点でした。その前に「作らない開発」方式を適用して完了していた小規模案件プロジェクトMとその総括により、大規模案件のプロジェクトNにおいても作らない開発方式で対応可能と主要メンバーは踏んでいました。いやスーパーカツカツスケジュールのプロジェクトNではそれ以外の方式ではス
