2000時間だけ、またはRSSリーダーの作成方法/私はロボコップです

みなさん、こんにちは



16週間以内に新しいウェブRSSリーダーを作成した方法の技術的な側面をお話ししますが、ほとんど夢中になりました。

長い歴史から離れて、デビッドと私（ dmiloshev 、UIデザイナー）が一緒に私たちの頭脳のプロトタイプを作ることにしたとき、それは今年2月にすべて始まったと仮定します。

「単独」-傷跡、会議、「集団的理由」がなく、技術的な部分をすべて自分でやらなければならなかったからです。



記事全体を1つの文で説明するように求められた場合、結果は次のようになります。

No-SQL、mongodb、node.js、私の頭脳、Evented I / O、キュー、出力、git、nginx、memcached、Google Reader、Atom、TTL、PHP、ZF、jQuery、結論。

I.テクノロジー

1. PHP / ZendFramework +その他

私が最初から持っていたのは、zfでの作業をもう少し便利にする小さなフレームワークだけです。 依存性注入、テーブルデータゲートウェイ、転送オブジェクト、設定を使用したより便利な作業、ほぼすべての場合に登録済みのタスクタスクでPhingを構成します。 一般的に、これらすべての作業は非常に快適です。



アーキテクチャ上のphpアプリケーションは、次のレイヤーで構成されています。

1. ルーティング/コントローラー/ビュー-なるほど..
2. サービス-ここでは、ACL、検証、キャッシュ、ロギング。 RESTを安全に固定でき、優れたAPIが提供されます。
3. ゲートウェイはビジネスロジックの本体です。 システム内の各エンティティには、独自のゲートウェイがあります。 データベースから完全に抽象化されています。
4. マッパー-実際、ここではデータベースを直接操作します。

設計時に覚えておくべきいくつかのポイント：

• キッス
• 自転車なし
• システムの論理部分は水平方向にスケーリングできる必要があります
• 外部ソースを扱うすべての手順はバックグラウンドで実行し、ユーザーインターフェイスをフリーズしないでください。
• 高負荷は、プロセスの数や開いている接続ではなく、キュー、プロセッサの電力、タイムアウトに依存する必要があります
• すべてのデータを回復できます。
• エラーだけでなく、絶対にすべてを記録する必要があります
• 「キャッシュできます」
• David：「このプレートは左に1ピクセルである必要があります..」=）

2. nginxコメントなし



3. gitは 、私が思ったほど頭が良くないことを明らかにした。



4.モンゴッド

以前は、別のプロジェクトで本番用に使用していましたが、非常に慎重であったため、完全に試すことはできませんでした。 最近、No-SQL、sharding、map-reduce、およびNo-SPOF modが特に開発されました。 私は子供のズボンから抜け出す時だと決めました。 少なくとも、それは一般的なルーチンを非常に希釈し、私を少し揺さぶりました。

みんなのドキュメントは非常に詳細であるため、最初の2週間でmongodbの深さまで浸透することができました。 リレーショナルデータベースを長年使用した後、頭を少し裏返さなければなりませんでした。 しかし、すべての重要なタスクは、フォーラムで質問することに頼ることなく、独立して解決されることが判明しました。

本番環境で起動するのが少し怖いです。 起こりうる問題に遅れないように、私は定期的にグループを読み、他の人が直面している問題を研究しています。

現時点では、完全にサポートされていないmaster-masterとして構成されていますが、この場合は正常に機能するはずです。 将来的にはシャードし、同じmysqlを使用するよりも間違いなく簡単になります。



5. Memcached

ここで言うことはありません。 ドアのようにシンプル。 将来的には、UDPで試してみたいと思いますが...楽しみのためだけです。



6. Memcacheq

今日、これには多くの選択肢がありますが、彼は前のプロジェクトの制作で非常によく自分自身を示したと言えます。

そして、良いことは、彼が特別なドライバーを必要としないことです-それはmemcached上で動作します（次の段落で役立ちました）。



7. node.js

これはおそらく、この4か月で私に起こった最も興味深いことです。 サーバーイベントI / Oは非常にエキサイティングで、 差分以上のものです。 私はすぐにすべてのphpをムードのあるrubyに書き換えたいと思いました。 これらは私の夢です。

事実、最近偶然発見したことがあります。 その後、システム自体と私の頭の両方で、かなりの数のことが起こりました。 何度も書き直さなければなりませんでしたが、結果は魂にとって非常に楽しいものであり、将来のユーザーを喜ばせることを願っています。

フィルターを使用する前に、 このページを使用しました。mongoose、kiwi、step、memcache、streamlogger、hashlib、consolelog、eyes、daemon

彼のライブラリから、彼はjsonsocketを書いた。 手は彼のgithub-threadに届きません。 そして今、私はそれからbsonsocketを作ることを夢見ています。 もちろん、キューを操作するためのものと、PHPでGatewayレイヤーを操作するためのレイヤーを作成する必要がありました（これについては後で説明します）。

また、 prowlを追加しました。バックグラウンドは1時間に1回、bashorgからランダムメッセージを送信し、携帯電話にプッシュメッセージを送信します（同時に、メモリ使用量などの統計もあります）。

多くのライブラリ（モジュール）は非常に未加工であるため、誰かのコードを直接編集しなければならない場合がありました（パッチを作成する時間はありません）。 そして、紳士の皆さん、node.jsは後方互換性を必要としているので、しばしば機能しないライブラリを見つけることができます。



8. jQuery

私にとって、これはほとんどクライアント側のJavaScriptの同義語です。

使用されているプラ​​グイン：blockUI、validate、form、tooltip、hotkeys、easing、scrollTo、text-overflow、その他いくつかの小さなプラグイン。

II。 開発

サービス自体の詳細については詳しく説明しませんが、技術的にはほぼGoogleリーダー （GR）です。

DavidはPhotoshopで灰色の四角を「運転」し、ビジネスロジックについて考えながら、基本的なモデリングから始め、その後すぐにフィードポンプシステムに切り替えました。



1.フィードプル



ここではすべてが単純なように思えます-アドレスを取得し、xml、parsimを出力し、データベースに書き込みます。 しかし、微妙な違いがあります。

• システムに保存できるようにするには、各フィードを一意に識別する必要があります。
• また、重複を避けるために各エントリを識別する必要があります。
• if-modified-sinceやetagなどのサポート
• リダイレクト処理
• RSS / Atomの異なるバージョン
• gr：date-publishedなどのさまざまなサービスの拡張
• 各レコード内のHTMLはきれいにする必要がありますが、完全ではなく、良いタグを残し、異端を排除する必要があります
• アイコンを見つけて処理することは、最も楽しいことではないことが判明しました...たとえば、livejournalはコンテンツタイプを与えないので、magic.mimeを使用する必要があります
• どうやら、仕様を読んでいる人はほとんどいないので、xmlが有効でないか、まったく有効ではない可能性があります

結論：

外部ソースは非常に異なっており、その多くは単に標準に言及しています。 そして、それらは信頼できません-コンテンツの検証は、ユーザーとやり取りするときと同じくらい厳密でなければなりません。

完全なコードは機能しませんでした。 多くの条件と例外で大きくなりました。

各アイテムには多くの時間がかかりました。 それは一見すると思えるかもしれません。



2.アップデーター



ここで、既存のすべてのスレッドを自動的に更新したいと思います。 さらに、個々のストリームのTTL（リフレッシュレート）を考慮することが望ましいです。 また、このTTLを時刻ごとに塗り付けたいと思います。 私の研究によると、プロトコルがまったく存在しないか、現実に対応していないため、プロトコルに依存しませんでした。 いずれにせよ、それだけでは十分ではありません。



私は、ストリームの更新頻度を決定するための独自のシステムについて考え始めました。

• TTL-1時間のストリームの記録間の平均時間間隔（秒単位）（最小2分、最大1時間）
• 各ストリームには、過去10日間の24時間ごとの平均TTLのリストがあります。
• 過去10日間の実際のデータに基づいて、翌日の予測が形成されます。これは、各時間の平均TTL値を表します
• ストリームが更新されるたびに、システムは現在の時間（0〜23）の平均実際TTLを再カウントします

したがって、システムは2分ごとにランチタイムに特定のストリームを更新し、この期間中に10日間、適切な更新を定期的に行う必要があるとしましょう。 これまで、システムはより頻繁にスムーズに適応および更新します。 また、たとえば、夜間、このストリームは1時間に1回更新されます。



実際、更新手順自体は前述のフィードプルであり、重要ではないが何を更新するかです。

そしてここで、これらすべてをキューに入れたいことをスムーズに理解します。 しかし、私は彼らの組織について少し後で話します。



ちなみに、 PubSubを固定し、ハブを起動することを計画しています。



3.発見



確かに、便利なrssリーダーのスキルのリストには、htmlページでrss / atomフィードの検索を含める必要があります。 ユーザーがWebサイトのアドレス（たとえばwww.pravda.ru ）を入力するだけで、システムは実際にそこにアクセスして、購読可能なフィードを検索する必要があります。



しかし、この手順はユーザーのリクエストで直接行うことはできないという事実によって複雑になります。これはWebサーバーのタスクではないため、非同期に実行する必要があるためです。 ユーザーの要求に応じて、最初にそのようなストリームがデータベースに存在するかどうかを直接確認し、ディスカバリキャッシュ（2時間続く）を調べ、何も見つからない場合はこの問題をキューに入れ、最大5秒待ちます（方法について待って、後で説明します）。 この時間内にタスクが完了しない場合、{wait：true}のスタイルでjsonを返すことでスクリプトを終了します。 その後、一定のタイムアウト後、クライアント側はサーバーに同じリクエストを行います。 タスクがバックグラウンドで完了するとすぐに、その結​​果がディスカバリキャッシュに格納されます。



この手順に関連するいくつかのニュアンス：

• 異なるエンコーディング-ヘッダーまたはヘッダーのいずれにもエンコーディングが示されていない場合があります...バイトで決定する必要があります（常に機能するとは限りません）
• 1つのページに2つの同一のフィードがあり、1つのRSSが別のAtomである場合があります-この場合、いずれかを選択する必要があります
• それが機能することを確認するために各フィードを追加でリクエストし、実際のタイトルと説明を取得する必要があります
• リダイレクト
• アイコン（同じ問題）
• 標準と有効性（同じ）

この部分はかなり粗雑だと思います。なぜなら、RSSやAtomが何であるかを知る必要のない人々のためにサービスを提供しようとしているからです。 たとえば、私が最も普通のユーザーとして、突然私のお気に入りで唯一のvkontakte.ruを購読したい場合、ブルーベリージャムが吹いているのがわかります。 少なくとも、将来的にはla grが生成したfeedを実装したいと考えています 。 最低限として、便利で人間的な検索を行います。

ちなみに、このページには具体的には代替物はありませんが、同じサイトの他のページにはどこかにあることがよくあります。 ユーザーが頻繁に入力するサイト上のrss / atomストリームをサイレントに検索するバックアップクローラーを作成するというアイデアがありました。



結論：

さまざまな種類の外部ソースを処理する場合、ランダムにスローされたドキュメントを探して巨大なゴミを掘っているようです。

特定の改良が必要です。 使いやすさの観点から、このページでの代替の単純な検索では十分ではありません。 もっと普遍的な何かをする必要があります。



4.インターフェース



次に私が本当に欲しかったのは、ストリームをサブスクライブできるインターフェースを見て、それをブックマークとして左の列に追加し、そのコンテンツをクリックして読むことでした。

インターフェースの実装の詳細については説明しません。すべてのレイアウトとUIを自分で作成したと言いたいだけです。 それは非常に不採算であり、他のタスクから注意をそらしました。 しかし、jqueryは時間を節約しました。

読者と一般的なインターフェイスでは、合計2週間を費やしました（これは、将来のかなりの修正と変更を除きます）。 その後、私たちはモニターに光り、目と魂を喜ばせるかわいいおもちゃを手に入れました。



フォルダー

もちろん、私たちは最小限の人ですが、フォルダがなければ、読者と一緒に仕事をすることは想像できません。 そして、紳士、申し訳ありませんが、Googleリーダーでは使い勝手が悪いです。 できるだけアクセスしやすくシンプルに実装するようにしました。

しかし、技術的にはこれがこのような問題になるとは思いませんでした。 インターフェースはインターフェースであり、サーバー側では、必要な動作をするためにかなりの努力をしなければなりませんでした-次の段落を参照してください。



可能な限り、私はcssスプライトを使用しようとしました（判明したところで）。

すべてのjsおよびcssは1つのファイルに収集され、gzipで縮小および圧縮されます。 中央のページ（すべての統計を含む）は300キロバイトです。 キャッシュあり-100kb。

IE6には特別なページがあります。



結論：

インターフェイス自体は非常に簡単に見えますが、その実装については同じことを言いません。

最終的に、すべてが圧縮され、firebugがオフになっている場合、スマートに機能します。

合計で、現時点では28個のスクリーンと100万のユースケースをカウントしました。



5.既読/未読のエントリ



これは、スレッドの停止、さらに多くのサブスクライバーが潜在的に存在する可能性があるシステムにとって、かなり重要なタスクであることが判明しました。 最も重要なことは、水平方向にスケーリングできることです。

各エントリエンティティでは、それを読んだユーザーのリストを保持しています。 このリストには少なくとも100万個の識別子が存在する可能性がありますが、mongodbアーキテクチャのおかげでパフォーマンスに影響はありません。 また、別のコレクションには、読み取り時間などの追加情報が格納されます。 インデックスは付けられておらず、統計のためだけに必要であるため、すべてが迅速に機能します。



ユーザーごとに、ユーザーがサブスクライブしているすべてのスレッドについて、カウンターの最終更新日が保存されます。

ユーザーがページを更新すると、システムはこの日付よりも後に表示された各ストリームの新しいレコードの数を見つけ、それを未読の数に追加します（単純な増分）。 ユーザーがレコードを読み取ると、単純なデクリメントが発生します。



別のストリームによる未読エントリの取得も非常に簡単です。



しかし、フォルダ内の未読のみを選択することはすでに問題です。 ニュアンスを明確にしたくありませんが、これはmongodbには単純に結合がないという事実によるものです。 単純な要求またはいくつかの要求では、CodeWScopeを介してのみ解決できます。 インデックス、スケールすることは不可能です-m / r。 これは現在、潜在的なボトルネックです。



5.1。 上に未読



Googleリーダーを使用しているユーザーがいる場合は、おそらく「未読のみを見る」機能について知っているでしょう。 したがって、ストリーム内にまだ読んでいないレコードがない場合は、空白のページを見ています。 最初はそれもやったのですが、テストの結果、ユーザーはこの機能が有効になっていることすら知らないことがわかりました。 彼らは、なぜストリームが空であるのか、なぜレコードがないのか、そしてどこに行くのかを理解していません。

Davidは、非常に興味深い解決策を提案しました。未解決のエントリが一番上に表示され、読み取られたエントリが単純に表示されなくなります。 そして、それを最適に、つまりフォルダに実装する方法について頭脳を壊すのに数日かかりました。



結論：

No-SQLは、速度とスケーラビリティの点で優れています。 しかし、一見些細なことのように思えますが、彼とのやり取りは非常に難しいことがわかりました。

非正規化は良いです。 一部のカウンターがノックダウンされるという問題を考慮する必要はありません。 ただし、非正規化データの場合は、完全な再計算機能が必要です（もちろん、バックグラウンドで）。

mongodbのM / Rはまだ生産用のままです。 少しテストした後、動作中にすべてを地獄にブロックすることが判明しました。 バージョン1.6では、開発者はそれを改善することを約束します。 これまでのところ、彼なしで。

スキーマレスが決定します。



8.共有



これは、読み取り可能なストリームからページへのレコードを取り除くことができる関数です。 簡単に言えば、これは、さまざまなフィードを読んでいる権威者Aが、GRの共有アイテムと同様に、特定のエントリ（もちろん、最も興味深く有用なもの）をストリームに即座に保存できることを意味します。 また、他のユーザーは、「共有アイテム」ストリームと任意のフィードを直接購読するオプションを選択できます。



当社のサービスの主な概念の1つは、情報の便利な配布です。 私にとって技術的に非常に興味深い仕事は、共有チェーンの構築を実装することでした。 Mongodbは、そのスキーマレスプロパティを本当に助けました。



興味深い点：

Googleは最近、バズの新しいReShare機能を発表しました。 そこで、「もう少し背景」というこの記事（参照）で、4か月前にDavidと私が密接に議論した点に出会い、同じ結論に達しました。 共有の実装は非常に近いです。



9. Node.js、バックグラウンド、キュー



当初、デーモンはPHPで作成されていましたが、非常に曲がっていました。 そして、mongodbを除けば、それはアプリケーションで私にとって最も愚かな場所でした。なぜなら、erenerはそのようなことを意図していないからです。

しかし、node.jsに出会ったとき（たった2週間前）、魂が歌い始め、再び静かに「眠り」ました。 しかし問題は、PHPに既に実装されているすべてのバックグラウンドコード（フィードプル、ディスカバリー、フィード情報）を書き換えるときではなかったということでした。

ノードの機能を非常に簡単に選んだ結果、妥協案である子プロセスに至りました。



9.1。 キューマネージャー



これが最初のノードデーモンです。 そのタスクは、行を読み取り、タスクをワーカーに配布し、作業のプロセスを監視することです。

• 1人のマネージャーが多くのキューを処理できます
• システム内のマネージャーは、サーバーごとに1つ、必要な数だけ実行できます。
• それぞれ独自の方法で構成できます。たとえば、異なるマネージャーが異なるキューのセットを操作できます。
• キューの構成は異なる場合があり、次のパラメーターがあります
  • 同時に働くワーカーの最大数（実際の数は負荷に応じて調整されます）
  • タスクバッファーのサイズ（タスクの種類とワーカーの数に応じて構成する必要があります）
  • ワーカーの最大アイドル時間（アイドル時間の場合、自動的にメモリを削除して解放します）
  • ワーカーの最大寿命（php-cliの場合、長く生きてはいけません。時々再起動した方が良いでしょう）
  • ワーカーの最大メモリ使用量（超過するとすぐに、kill）
  • タスク実行のタイムアウト（タスク実行中にワーカーがスタックした場合、それを強制終了し、タスクをキューに戻します）
  • タスクが失敗する可能性のある回数
• キューからタスクが選択されると、ロックが設定されます（ロックにはmemcacheが使用されます）
• タスクに結果がある場合、memcacheに保存されます
• 各キューには独自のワーカーがあり、特定のインターフェイスを持つjsクラスである必要があります
  • 現時点では、そのようなものが1つだけ動作します-インポート（さらに先になります）
• php-cliを子プロセスとして実行し、jsonで通信するWorkerPhp.jsもあります
  • そのような労働者（プロセス）の寿命は1つのタスクで終わるわけではありません。マネージャーは、「脂肪が増えた」と気付いて解雇されるまで、1つずつ実行できます。
  • 実際には、キューごとに4つを超えるphpプロセスが同時に開始されません
• POSIXシグナルを理解する
• 正しく完了した場合（-9を強制終了しないでください）、すべてのタスクをメモリからキューにきちんと返します
• 各マネージャーは、REPLインターフェースでポートを開きます。ポートを開いて、どのように作業しているかを尋ねることができます。 また、その場で再起動せずに構成を変更することもできます。

ところで、キャッチされなかった例外は、1つのスレッドのみを配置しますが、プロセス全体ではなく、喜んで配置します。

そして、このすべて-500行のコード（コメント付き）。



結論：

イベントI / Oは、ほとんどのサーバーアプリケーションが動作するために必要な方法です。 ロックは、本当に必要な場所にのみ配置する必要があります。

ノードを介してphpをプロキシすると、良い結果が得られ、時間を節約できました。

多数の作業は1つのプロセスのみで処理されます（php-cliはカウントしません）。 JSワーカーはそこで非同期に非常に突然作業します。



9.2。 コントローラー-パブリッシュ/サブスクライブハブ



多くの場合、バルクタスク（たとえば100）を並列で、さらには非同期で実行する必要があります。 しかし、線はブラックホールです。 そこに100個のタスクを送信します...そして、結果を得るために2回目にmemcacheに連絡することさえも、不利益です。

それでもキューをバイパスできます。ソケットを使用してマネージャーに直接連絡し、マネージャーにこれらのタスクを完了するように依頼して、同じ接続で応答を待つことができます。 しかし、このオプションは適切ではありません。何十人ものマネージャーがいる可能性があり、どのマネージャーに連絡できるかわかりません...要するに、これは間違っています。



そして、コントローラー（ノード）を作成しました。 通常、システム全体で唯一のものですが、スツールと同じくらいシンプルです：

• すべてのマネージャーがコントローラーとの永続的な接続を開きます
• タスクの結果またはファイルの場合、マネージャーはコントローラーに詳細を通知します
• 「一方で」それに接続し、特定のタスクまたはタスクリストをサブスクライブできます。
• タスクに関する情報が到着すると、コントローラーはすべてのサブスクライバーに通知します
• 加入者が多くのタスクを期待している場合、コントローラーは到着時に通知します
• PHP用のクライアントがあります（ブロッキング）
• ガベージコレクション

実際、PHPスクリプトがコントローラーに接続し、タスクの結果を5秒間待ち、その後ユーザーをインターフェイスに戻すのは、前述の「検出」手順です。



結論：

パブリッシュ/サブスクライブスキームは、非ブロッキング環境で非常に効果的です。

100パーセントの結果は必要ありません。 結局、100のうち5つのタスクが何らかの理由で完了しなかった場合、原則としてこれは恐ろしくなく、作業を続けます。



9.3。 Feed-updater（バックグラウンド更新）



ノードプロセス、システム全体に1つ。 定期的にデータベースに接続し、更新が必要なフィードのリストを（TTLデータを使用して）受信し、それらをキューにスローします。



9.4。 キュー



競合状態を回避するために、各タスクに対して一意のmd5識別子が生成されます。 この識別子はキューに配置され、このタスク自体のデータはmemcachedにあります。 ほぼすべてのタスクのサイズは固定されておらず、memcacheqはこれに対応していないため、そうすべきではありません。 マネージャーがタスクを取得すると、ロックを設定します。これは、memcachedエントリでもあります。 これにより、実行中に同じタスクのキューに直接再入することを回避できます。

この場合のmemcachedは他の目的で使用されるため、Redisをこのすべての代替として検討する予定です。 彼が倒れた場合、行全体が失われます。



また、キューをユーザーとシステムの2つのグループに分けました。 最初は優先事項です。

これにより、ユーザータスクを妨げることなく、バックグラウンドアップデータで使用されるfeed-pull-sysが追加されました。



結論：

この実装はまだ非常に粗雑です。

キューは、ドロップするたびに復元する必要があります。

より高度なロックシステム-ミューテックスを使用する必要がありますか？

ユーザープロセスとバックグラウンドプロセスには、異なる優先順位が必要です。



10.インポート/エクスポート



ここで私がお話ししたい別の興味深い点があります。 OPML形式でのインポート/エクスポートをサポートするには、すべての適切なリーダーが必要です。 しかし、実際には、一部のユーザーはまだシステムにない数百のフィードでopmlをアップロードできます。 そして、彼はそれらがすべてロードされるまで待たなければなりません。 それでも、同時に十数人のそのような人々がいるかもしれません。



ノードが保存されます。 「インポート」と呼ばれる新しいワーカーがあります（現時点では、一度に最大10まで動作できます）。 opmlファイルをダウンロードして検証した後、phpはタスクをキューに投入し、ユーザーをインターフェイスの進行状況バーに戻します。 一方、「インポート」は、「フィードプル」キュー内の小さなタスクをピックアップして分散させ、その後、カウンターを更新しながらコントローラーから実行されるのを待ちます。 また、ユーザーには、スムーズに進行する進行状況バーが表示されます。 何で、彼はこのページを離れて、散歩をして、そして戻ることができます。 いいね

III。 結論

• 自転車を作らないでください。 ほとんどすべてのタスクについて、わずかに適合させる必要がある既製のソリューションが既に存在します。
• 最終的にユーザーにとって製品が単純になるほど、その実装は難しくなります。 ところで、消費者はこれに気付かないでしょう。
• 自分を過大評価しないでください。 成人向け製品を「1週間で」独立して作成することはできません（この言葉は好きではありませんが）。
• 動機は、しかし、時には不可能を行います。
• 製品が完璧になることはありません。 動作するアプリケーションは、常に時間と品質の妥協点です。
• 自分で作業する場合、チームのブレインストーミングは非常に不足しています。 可能な限り集合的な心を使う価値があります。
• コンテキストの切り替えには時間がかかります。 1人の開発者がより類似したタスクに従事している場合、それははるかに効果的です。
• スタートアップをして、アイデアよりもさらに先に進むつもりなら、私生活と金曜日のビールを忘れてください。

これはほんの始まりであり、まだ多くの計画された作業が先にあります。 私たちがイノベーションと呼ぶことができるものを含めて、私はその言葉を恐れていません。 したがって、継続するには...



並行して、来週中に半閉鎖の打ち上げを発表したいと思います。

私の同僚は、先日別の記事でプロジェクトについて書きます。



技術的なコメント、アドバイス、建設的な批判に感謝します。