Karbonマニフェスト

FileMaker Developer Conference 2018が始まりました。日本から参加する皆さま(中には発表する皆さまも)は、準備万端でしょうか?
今回は、カンファレンスでの発表を予告しているGeist Interactiveの新しいフレームワーク”Karbon”について紹介します。具体的にはまだどんなものかわかりませんが、Todd Geistさんのプレゼンテーションを楽しみに待ちたいと思います。


THE KARBON MANIFESTO

(元記事はこちら)
2018/7/30
Todd Geist

私たちは来週Dallasで開催されるFileMaker Developer ConferenceでKarbon Frameworkのリリースを発表します。

Karbonは、今の時代に適した野心的なFileMakerカスタムAppを構築するための「フリーな(無料の)」フレームワークです。「野心的な」とは、長期に渡って重要な価値を提供し続ける大規模で複雑なビジネスアプリケーションを意味します。あなたが解決しようとしているのが単純な問題なら、Karbonはあなたをイライラさせたり邪魔をしたりするでしょう。しかしもしあなたが(私たちと同じように)、今後成長してゆくビジネスのために柔軟で堅牢なカスタムAppが必要であると信じているなら、Karbonこそあなたが探しているものかもしれません。この記事では、私たちがなぜKarbonを作ったのか、なぜそのコアモジュールを無料で提供するのかを説明します。

時代は変わった

20年以上前から、私たちはFileMakerで複雑なアプリケーションを開発してきましたが、その間に多くのことが変わりました。ソリューションを展開する環境は、20年前とは似ても似つかないものになりました。まず技術が変わりました。競争相手が変わりました。何が可能になったかも変わりました。

FileMakerは、時代に伴う技術の変化のほとんどに対応するという点において、素晴らしい仕事をしてきました。25年以上も継続して成功し続けているプラットフォームというものは他にはほとんどありません。FileMakerプラットフォームは信じられないほど堅牢で柔軟性があり、存在意義と価値のあるカスタムAppを構築するための非常に確かな基盤を提供しています。

しかし、今のビジネス環境で存在意義や価値を持ったアプリケーションとはいったいどんな姿をしているのでしょうか? これまでにはできなかったことのうち、何ができる必要があるのでしょうか? それはどのような特徴を持っているのでしょうか?

Karbonの構築/再構築を繰り返し、顧客のニーズを解決するために働くあいだに何度も遭遇したハイレベルな問題のいくつかをここに示します。重要な価値を持つカスタムAppは、以下のほとんどを行う必要があります。

  • 他のアプリケーションと統合して分散データを処理する
    ミッションクリティカルなデータは、現在、複数のアプリやサービスにまたがって存在しています。他のアプリケーションやサービスとの統合を避けることは、もはや妥当でないばかりか、可能でもありません。FileMaker Goアプリでさえも、しばしばオフラインで作業する必要があります。他のサービスやオフラインのFileMaker Go Appとデータをやり取りできることは、技術的な最初のステップですが、複数の場所にデータを持つことの意味を理解していないと、すぐに問題に陥ることになります。
  • インターネットを介して動作
    たとえWebDirectを使用してデプロイする予定がない場合でも、FileMakerアプリケーションは、国内や世界のさまざまな場所のユーザに展開されることを想定して構築する必要があります。
  • 協業による開発と保守を可能にする
    元々の開発者だけしか改善あるいは維持することができないカスタムAppでビジネスを構築することは、もはや妥当ではありません。そのビジネスに対するリスクが高すぎます。最高のアプリケーション開発プラットフォームであっても、単一の開発者または非常に少人数のチームでは、今日の変化のペースに沿って革新的なビジネスを維持するのに十分速く働くことはできません。アプリケーションは、より大きなチームの開発者を採用するか、アプリケーションにすばやく組み込むことができるサードパーティのモジュールに頼って、他の人の努力を効果的に組み込むことができなければなりません。
  • ミッションクリティカルなビジネスロジックを自動テスト
    ミッションクリティカルなビジネスロジックが動作することを確認できない場合は、他のロジックを壊す恐れなしに、ロジックを変更することはできません。ロジックを変更できない場合、ビジネスを変更することはできません。ビジネスを変更できない場合…まあ…誰かがあなたに代わってそれを変更してくれるでしょう。
  • フェイルセーフ
    アプリケーションは必ずクラッシュします。サーバから切断されることもあります。アプリケーションを立ち上げたままラップトップを閉じることもあります。誰かがレコードをロックすることがあります。これらの種類の失敗の結果として、貴重なデータに対して重大な影響が出る可能性があります。今のネットワークとアプリケーションが分散しているという性質を考慮すると、これらのタイプの問題はさらに一般的です。価値のあるアプリケーションは、重要なデータやロジックを処理するのと同時に、障害を適切に処理する能力も求められます。
  • 堅牢かつ柔軟
    アプリケーションが永続的な価値を持つためには、データは正確で有用であり、それを長期の間保持できるものでなければなりません。簡単に変更や現実への適応ができないデータ構造を構築するということは、結果的に自分で自分の首をしめることになります。
  • 標準への準拠
    すでに他の人によって解決されている問題に対するソリューションや、FileMakerで利用可能なソリューションを改めて発明することは、もはや合理的ではありません。これは、他のプラットフォームから来る新しい開発者に対して混乱を招くだけです。私たち独自のやり方をして費やした時間は、私たちの構成員にとって価値を創造するのに費やせたかもしれない時間です。
  • 継続的な改善
    今日の複雑なビジネスアプリケーションは、永久に完成することはありません。これで終わりという境界線はないのです。これを装備したら終わりだと言える機能というものはありません。継続的に進化するのみです。アプリケーションとそれを構築するために使用されたプロセスは、そのような環境で生き残っていく必要があります。

Karbonの存在意義

私たちは上記の課題のすべてを解決するために、Karbonの開発に取り組みました。明確に言わなくてはいけませんが、それが終わったわけでも、いつか終わるわけでもありません。しかし、それを世界中の他の人々と分かち合えるほどには十分時間を費やしました。DevConではより多くの情報を公開し、ダウンロードを可能にする予定ですが、今は私たちが「Karbon Values (Karbonが重きを置くこと)」と呼んでいるものを以下に紹介したいと思います。これらは、Karbonを構築する過程で決断を行う際に使用しようとした原則です。

  • まず「正確性」、次に「十分な速度」、最後に「見た目」
    データモデルやロジックの根本的な問題を隠している美しいユーザエクスペリエンスは、データロジックとデータモデルをうまく扱う醜いユーザーインターフェイスよりもはるかに悪いものです。これは、優れたユーザインターフェイスとユーザーエクスペリエンスを私たちが重視しないと言っているわけではありません。むしろ私たちはそれを重視しています。ただデータの正確性により重きを置いているだけです。
  • モジュール設計
    数年前に策定されたモジュールガイドラインに従います。FileMakerが私たちに提供していることの範囲内で、できる限り多くのことを自分自身の内部に持っておくことは、特にサブファイルレベルでコードを整理するのに役立ちます。
  • データベースのトランザクション
    複数のレコードを更新する必要がある複雑なロジックは、もしそれがデータベースのトランザクション処理を使用していない場合、壊れていると見なされます。正しいトランザクション処理を使った方法でスクリプトを書くことを学ぶと、他の方法に戻りたいと思うことはまずありません。それは簡単で安全で、率直に言えば、動く部品がはるかに少なくてすみます。
  • 関心の分離
    重要なこととして、これは「分離モデル」のことではありません。ただし考え方のいくらかは共通しています。Karbonには3つのコアファイル(UIファイル、Controllerファイル、Dataファイル)があります。これはインポートをさけるために行うわけではありません。これにより、良いコードを書く方法について一貫した決定を下すことを容易にするためです。Controllerファイルにコードを記述するとき、私たちはユーザインタフェースやデータモデリングのリレーションシップを扱っていないことを理解しています。私たちは、堅固にスクリプト化されたビジネスロジックの作成に集中できます。またUIファイルにいるときには、良いユーザインターフェイスを構築することに集中することができます。Controllerスクリプトで処理されるビジネスやデータベースの整合性ルールを適用することに関係するレイアウトやグラフの作成については気にする必要はありません。
  • APIファースト
    Karbonは、モジュラー設計によりすべての重要なビジネスロジックに対して、テスト可能な、トランザクション処理に対応した安全なJSONベースのAPIスクリプトを構築できます。
  • 自動テスト
    私たちはKarbonとそのサポートファイルに対して技術を統合して、テスト可能なコードを簡単に記述できるようにし、また簡単にテストできるようにしました。テストされたロジックは、保守可能なロジックになります。
  • 開発版と製品版の分離
    ライブファイルに対して作業を行うことは、大災害へ通じる道です。開発環境と運用環境を分離することは、テスト、開発、メンテナンスを容易にします。データ移行の問題は、主にFileMakerや他のサードパーティによる新しいツールによって対処されてきました。
  • 真実の源を理解する
    現代のシステムでは、どこか別の場所から来たデータを使って作業する可能性が高く、どのアプリケーションのデータが正しいかを知る必要があります。ときには、これが必ずしも明確ではない場合もあります。”請求書”を例にしてみましょう。あなたの扱うシステムが、会計システムと統合している(KarbonがQuickBooks Online (QBO)と行っているように)場合、そのシステムに請求書を送付している可能性があります。請求書がそこに届いた後、QBOで修正される可能性がある場合、どちらが正しいデータでしょうか? 正しい値を保持しているのはFileMakerでしょうか、それともQBOでしょうか? この場合の答えは、おそらくQBOです。請求書がそこに届くと、その値は会計システム全体に影響を及ぼし、税金にも影響を与えます。会計期間が終了すると、FileMakerから再び更新することはできません。明らかにQBOが真実を保持しています。それを理解することは、システムの構築方法に影響します。たとえば、Karbonはデフォルトでは新しい請求書の請求書番号を生成しません。QBOが請求書番号を発行します。
  • より良いデータモデルが生き残る
    確かにPartyモデルのようなデータモデルは実装に時間がかかります。しかし、いったん完成すると、エンティティ間のさまざまなタイプの関係を、最初からやり直すような破壊的な変化なしに記述できるようになるので、柔軟性が大幅に向上します。
  • 正しいことに時間をかける
    ユーザインターフェイスは頻繁に変わります。毎年、新しいタイプのウィジェットをFileMakerから入手しています。これは、あるタイプのレイアウトを簡単に作成できるようにするために大きな影響を与えるかもしれません。たとえばFileMaker 17には、マスタ/詳細レイアウトを作成するための簡単な方法が用意されていました。もし複雑なレイアウトを作るために時間を費やしても、FileMakerがそれを新機能で置き換えてしまえば、時間を無駄にしていることになります。しかし、スクリプトやテストを使ってスクリプトを作成するのに時間を費やしても、FileMakerの次のリリースで、これらのスクリプトが変更されたり、使われなくなることはありません。
  • 共有とは相手を気遣うこと
    共有するということは、「気持ちがいい」とか「コミュニティに還元する」ということだけではありません(もちろんそれらも重要な要素ですが)。しかし、あなたが共有可能なコードを書くときは、より良いコードを書いています。コードを共有する唯一の人物が将来の自分であっても、それは価値があるでしょう。
  • シンプルなほど良い
    価値を付加しない抽象化は避けましょう。そして単に少しキーを打つ回数を減らすことは価値をうみません。すべてのものをできるだけシンプルにするようにしましょう。コードを読みにくくすることなく、より価値の高い抽象化を行いましょう。
  • ドキュメンテーション
    文書化されたコードは、文書化されていないコードと比べて、正しくメンテナンスされる可能性が高くなります。私たちが使用する標準では、コード生成ツールを構築することもできます。
  • コードを生成するコードを書く
    可能であれば、他のFileMakerアプリケーションを書くことができるFileMakerアプリケーションを作成してください。私たちはGeneratorまたはJSON Web APIと通信するためのスクリプトを生成するための無料のユーティリティで、これがうまくいくことを実証しました。

わかりました。で、それで何ができるの?

もっともな質問です。Karbonの最初のリリースはCustomer Relationship Managementに焦点を当てています。連絡先、活動、および一部の販売取引を扱います。それは完全に融合したPartyモデルを持っています。ミッションクリティカルなビジネスロジックに対して、トランザクション処理のスクリプトのテストも行いました。これはSmarty StreetsやQuickbooks OnlineのようないくつかのAPIと事前に統合されています。ビジネスを構築する上での堅実な基盤であり、将来、その機能セットを拡張するための計画がいくつかあります。

プロジェクトの初期段階にある人々の中には、それをすべて採用することを選ぶ人もいると思います。すでにプロジェクトに深く関わっている他の人は、その中の大きな部品を利用して自分のシステムに組み込むこともできます。またその他の人たちは、それを解体してそこからできることすべてを学ぼうとするかもしれません。これらの対応のすべては、私たちの戦略から見れば勝利です。

なぜ無料で提供するの?

Karbonのコアモジュールは無料で提供され、どのような目的にも自由に使用できます。上記の価値を完全に理解されるためには、このようなプロジェクトはフリーでなければならないと考えています。しかし、それはまた、大きくて複雑な問題に対する実践的なアプローチでもあります。

上に述べたような問題がますます増えてきたので、クライアントに素晴らしい価値を提供するためには、別のアプローチが必要であることが明らかになりました。私たちはこれを内部的に必要としました。しかし、それは大きくて挑戦的な仕事です。

これから、私たちはいくつかのフィードバックを得たり、関心のある人々に助けを求めたいと思っています。良いソフトウェアは、ほとんど常に広く使われています。私たちは、多くの人にKarbonを使用してもらって、意味が分からない、壊れている、今の機能の代わりに何をすべきか、などを教えてほしいと考えています。

最後に、私たちはコミュニティの中で最先端の技術を向上させることを支援したいと考えています。私たちは、この種のプロジェクトを構築したいと考えているか、すでに構築している人々と協力し、上で議論した問題にどのように対処するかの良い例を見つけることを望んでいます。

私たちはこの取り組みが、参加を選択した人に利益をもたらす恩返しのサイクルを作り出すことを願っています。

Geist Interactiveはどうやって利益を得るのですか?

ただ、私たちの関わるプロジェクトがどんなにすばらしいものだったとしても、それを経済的に支えることができなければ意味がありません。それをやりとげることは不可能です。だから私たちははっきりとこれが先々何らかの形で利益になると考えています。

  • Karbonのコアは無料ですが、いくつかのオプションモジュールを同梱して有料で提供する予定です。ユーザは、それらを削除することも、まったく使用しないこともでき、何も支払う必要はありません。しかし、それらを使用したい場合、それらの部品のライセンスを取得する必要があります。たとえば、KarbonはQuickbooks Onlineとあらかじめ統合された状態で出荷されます。この統合を可能にするモジュールはLegerLinkと呼ばれ、年間500ドルの費用がかかります。
  • Karbonと一緒に出荷されるのではなく、Karbonと連携するように作られたモジュールもあります。これらのモジュールも料金がかかります。
  • 私たちはKarbon向けのサポート契約やトレーニングも提供する予定です。

質問は?

質問があり、DevConに参加するという方は、ぜひ私たちのブースに来てください。DevConに参加されない方は、カンファレンス中に私たちが発信するいろいろなニュースフィードに注目していてください。カンファレンスの中で、Karbonのダウンロード方法と使用方法をアナウンスする予定です。
興味を持っていただいてありがとうございます。Karbonがあなたにとって有用なツールになることを祈っています。

Leave a Reply