コードなしのコーディング

特定のインターネットサービスに次の機能があると仮定します:ユーザーは1)オブジェクトを作成し、2)オブジェクトのタイプを決定し、3)2つのオブジェクト間の接続を作成し、4)接続のタイプを決定し、5)これらの操作を実行する他のユーザーの権限を決定します。



この機能によりユーザーは何ができますか?



-通信する。 コミュニケーションは、大まかに言って、ソースと応答の関係(関係)によって接続されたテキストタイプのオブジェクトのチェーンです。

-コンテンツの構造化-さまざまなオブジェクトとセット間のリンクを確立します。 さまざまな主題分野のオントロジーを構築することを含む。

-独自のサービスとプロジェクトを作成します。 例については以下をご覧ください。



例1.特定の不動産業者がN市で不動産プロジェクトを作成したいとします。彼は、「サービス」タイプが追加された「多」タイプのオブジェクトを作成します。 または「著者のプロジェクト」。 または、別の名前を付けても、今は関係ありません。 このセット内で、このユーザーが操作を実行する他のユーザーの権限を決定することが重要です。 したがって、このセット内で、プロジェクトの作成者は、「商業用不動産」、「アパート」、「プロット」などのタイプのセットをさらにいくつか作成します。「商業用不動産」セット内には、「オフィス」、「ショップ」、「倉庫」タイプのセットが作成されます「など」「アパート」は、部屋数、地区、古い家や新しい建物の標識などに応じてセットに分割されます。同時に注意してください-同じオブジェクトを同時に異なるセットに組み合わせることができます。 つまり 著者は共通の階層を構築する理由に苦しむことはありませんが、彼に知られているすべての兆候に従ってすべての階層を構築します。 これがサブジェクト領域のオントロジーと呼ばれるかどうかはわかりませんが、この構造はプロジェクトの作者が有能な領域の実際の関係を明確に反映しています。 (確かに、問題はユーザーが画面に表示するものにそのまま残りますが、これは別の問題です)。 作成者はこの構造を自分で作成しますが、他のユーザーの場合、「コメント」タイプのオブジェクトを作成し、上記のオブジェクトのいずれかと相互に関連付けることができます。 特定のオブジェクトに関連するすべてのコメントは、「ディスカッション」タイプのセットに結合できます。 さらに、著者は「販売用アパート」タイプのセットを作成します。 他のユーザーは、「Apartment」タイプのオブジェクトを作成できますが、費用はかかります(広告配置料)。 同様に、「ルート」サービスは、仮想不動産サービスの作成者の収入の一定の割合を占めます。 (この収益化モデルに対する考慮事項がありますので、正しく適用する必要があります。これは私の別の投稿にありました )。



例2.ヤロスラフ・グレシロフは聖書プロジェクトを作成しました。 しかし、彼はこのサービスを開発して機能を向上させるのに十分な資金を持っていません。 そして彼は、ユーザーがプロジェクトの最終案を確認したい場合に、プロジェクトに参加する提案をユーザーに求めました。 どんなことかわかりません。 私の意見では、本をコメントしたり議論したりする十分な機会はありません。 実際に行われたことを見てみましょう。「Biblus」というセット内で、ユーザーは(条件付きで)「ユーザーページ」タイプのセットを作成できます。これは、「Book」タイプのオブジェクトと「Read」、 「」を読みたい、「今読んでいる」、「持っている」、および「ユーザー」タイプのオブジェクトで構成される「近隣」タイプをたくさん読みたい。 一部のセットの書籍は、「短期レビュー」または「説明」タイプのオブジェクトに関連付けられています。 Yaroslavが仮想サービスでプロジェクトを行い、書籍やレビューにコメントする機能を追加した場合、プログラムコードを変更してプログラマに支払う必要はありません。 ユーザーは、「コメント」タイプのオブジェクトを作成し、それらを「本」または「レビュー」のオブジェクトに関連付けることができます。 Biblaが書店の広告から収入を得ているとします。 これらの収益の一定の割合は、再び「ルート」サービスに有利に引き出されます。



聖書は創造的な協会13:37 (明らかに、現時点で彼らは団結するというアイデアを思いついた)と結びついています。 特に、旅行および映画プロジェクト。 私は詳細に行きたくありません、ただ構造が聖書に似ていることに注意してください-映画は「見た」、「見たい」、「今見ています」、「持っている」、そして多くの「隣人」を構成することができます 旅行でも同じです。 地理的な場所-「訪問済み」、「訪問したい」、「今の私」、そして伝統的な「隣人」。 もちろん、これは部分的に冗談です。なぜなら、異なる領域には異なる詳細があるからです。



さらに詳細にペイントしたい例がいくつかあります。 これらには、説明されている「オブジェクト+通信」モデルの特定の利点が含まれています。 これは次の投稿で行います。



備考と説明。



ここでは意図的に述べられておらず、本質に焦点を合わせるために簡略化されています。 さらに、プロジェクトの生産における標準化と統一には、長所と短所の両方があることは明らかです。 従来の方法で作成されたプロジェクトは、設計などの観点からはより優れている可能性があり、高負荷の場合はよりシャープになる可能性があります。 さらに、ビジネスプロジェクトにサービスを提供する場合、このサービスの安定性と信頼性に高い要件が課されます。



ご覧のとおり、「セット」のタイプは絶えずどこにでもあるため、その作成は別の6番目の操作で区別することもできます。 しかし、私はそれをオンにしませんでした、なぜなら 表現力豊かなミニマリズムが欲しかった。 実際のところ、タイプ(クラス)自体は、任意のフィールドの「典型的な」要素を結合するセットです。



ミニマリズムは、プロジェクトの作成が一般ユーザーに利用可能になるという事実につながります。 プログラマである必要はなく、DrupalやWordPressを学ぶ必要もありません。 彼らは自分の専門分野で能力を使うことだけが要求されます。 したがって、投稿の名前-コードなしのエンコード。 プログラミングなしでプログラミングを呼び出すこともできます。 情報、知的、その他のさまざまなネットワークリソース間の関係がプログラミングされ、人々の社会的相互作用がプログラミングされるため、これはプログラミングですが、従来の意味ではありません。 特定のユーザーインターフェイスに依存するため、コードはありません。 私は悪魔が細部にあり、おそらくそれほど単純ではないことを理解しています。 特定の首尾一貫した一連の投稿が終わったら、このインターフェイスについて考える予定です。



聖書の例でわかるように、プロジェクトの作成が単純化されるだけでなく、プロジェクトの変更と開発も単純化されます。 そして、これは一般ユーザーだけでなく重要です。



「ユーザー」と「コメント」として定義されているタイプは、2つの完全に異なるプロジェクト(不動産と書籍)に共通していることに注意してください。 つまり 共通の環境は、型の標準化と統一の基礎です。 これにより、検索と構造化が簡素化されます。 たとえば、別の都市の別の不動産プロジェクトに同じタイプの「アパート」などが含まれることは明らかです。 そして、もし何か必要なら、国のすべての都市の「アパート」タイプのすべてのオブジェクトを1セットで簡単に接続することができます。 さらに、13:37のユニオンを使用したコミック例では、タイプだけでなく、典型的な構造、セット、およびそれらの間の関係もある程度統一できることが示されています。 さまざまな世界の文学からの典型的なプロットはわずかしかないようです。



冒頭で述べたように、「オブジェクト+コミュニケーション」モデルでは、独自のプロジェクトを作成できるだけでなく、ユーザーがインターネット上で行うことに慣れていることを実行でき、さらに資料を構築することもできます。 これに関連する見通しは興味深いものです。ここでは、特にこれらすべてが共通の環境で一緒に起こることを考慮すると、さまざまな興味深いことを言うことができます。 しかし、私の過去の投稿の経験が示すように、すべてについて話すとすぐに聴衆を混乱させます。 したがって、このテキストでは、プロジェクトの制作に関連する側面のみに注目することにしました。



実際、ここでは、ユーザーセットと一般的な環境との相互作用におけるカプセル化やデータ隠蔽など、いくつかのプログラミング概念との類推を続けることが適切です。 隠蔽。ユーザー設定のアクセス許可の中に、「他のユーザーのオブジェクトの可視性を決定する」操作を含めるという考えがあるためです。 このアプローチでは、外部は何らかのインターフェイスを介してのみ内部と対話します。 ユーザーは、誰が自分のスペースでオブジェクトおよび関係を作成および/または表示できるかを決定し、どのオブジェクト/関係、特定のセットまたはタイプを正確に指定します。 また、スペースをサブスペースに分割し、それらのルールを個別に定義します。 ルールを確立する権限を他のユーザーなどに委任します。しかし、このトピックを完全に開発するには、能力が不足しています。



他に何を追加できますか? たとえば、このような環境では、プロジェクトを簡単に複製できます。 これは、会話のトピックも開きます。



All Articles