操作
人々は、安全でないブラウザや Web がのぞき見できるようになる前に、真正性を維持し、自分のアイデアが存在したことを証明できるかどうかを心配していました。
校正投稿は既知のブロックチェーンのほとんどで機能し、独自のカスタム ブロックチェーンを入力することもできます。
People had been concerned about the preservation of authenticity, and proof of time of existence of their ideas, before the time when an insecure browser and the web could peep into.
Proof-posting works with most of the known blockchains, and you can even enter a custom blockchain of your own.
19,316 3:01
@ 0 > oo
- アイデアをメーリング リスト (配布モード) に転送して、ワンクリックで記録を保存し、archive.org にも保存します。
- カテゴリへの購読を有効にし、転送先の専門的なリストを作成します。
- ウェイティング リストのランディング ページでメールを収集します。
- 転送用のスペシャリスト メーリング リストを収集します。
- アイデアの有料投稿を行います。
- ✅ 長いページの読み込み速度を改善する。
- ✅ アイデア署名機能の改善。
- 比類のない時間を持つ将来の株式を製品として自動的にリストします。理論的根拠: 現在、従来の製品を購入することは従来のシステムではるかに効率的であるため、製品機能 (物を購入することができます) は役に立ちません。しかし、プロジェクトのシェアも商品であり、定量化して分類したので、現在、資金調達可能なアイテム、資金調達先、シェアが作成される「ターゲット」があります。したがって、「ターゲット」は実際には「製品」であり、製品としてリストされ、購入される可能性があります。
- Forward ideas to mailing list (distribution mode) to preserve a record with one-click, also save to archive.org.
- Enable subscriptions to categories, and curate specialized lists of people to forward to.
- Make a waitlist landing page + collect emails.
- Collect specialist mailing list for forwarding.
- Make paid posting of ideas.
- ✅ Do something about long page loading speed.
- ✅ Improve idea signing functionality.
- Automatically list future shares that have unmatched time, as products. Rationale: currently, the products feature (which does allow to buy things), is not useful, because buying traditional products is much more efficient with traditional systems. However, project shares are products too, and we have quantified and categorized them, so there are currently: "targets" as fund-able items, funding which, shares are created. So, the "targets" are actually "products", and could be listed as products, to be bought.
ホームページを初めて訪れるユーザーの S/N 比を高めるために、メニューを非表示にし、操作をコンパクトにして、目がコンテンツに集中できるようにしました。
To increase the signal-to-noise ratio for first-time visitors of the home page, I have hidden menus, and compacted operations, so as to let the eyes focus on content.
However, apparently, some people didn't like it, because it is not clear what to do, so, I mostly reverted the change.
助けが必要です。
@ 0 > oo
- ⬜️専門家によるUXコンサルティングとUIの改善
- ⬜️ユーザーがビデオを視聴し、システムの使用方法を学ぶことができるヘルプビデオライブラリページ
- ⬜️ UX consultation from a professional and UI improvement
- ⬜️ Help video library page where users can watch videos and learn how to use the system
ターゲットをロックし、投資用のティーザーを作成し、潜在的な利害関係者と共有できるようになりました。
It is now possible to lock targets, create teasers for investment, and share them with potential interested parties.
以前のデータと現在の列、および以前のハッシュを取得してデータベース全体のハッシュを生成するハッシュを実装しました。
これにより、すべてのデータを再ハッシュし、ソートされたデータのバイナリ検索のハッシュを取得するシンクロナイザー部分を作成するときに、最小限のデータ送信で同期することができます。
I implemented a hash that takes previous data and current column and the previous hash to produce a hash of the entire database.
This allows us to synchronize with the minimum of data transmissions when I write the synchronizer part which shall rehash all its own data, then retrieve the hash of a binary search of the sorted data.
この問題の残りの部分に数時間を費やし、ドキュメントの保存が完了した後、ドキュメントの取得が機能するようになりました。
これにより、JSON ドキュメントを保存および取得できます
挿入されたドキュメント データは、SQL でクエリすることもできます。
ドキュメントに対する結合はまだサポートされていませんが、これを実装する予定です。
I spent a few hours working on the remainder of this problem and got documnent retrieval working after finishing save document.
This lets you save and retrieve JSON documents
The document data inserted is also queryable by SQL.
Joins against documents are not yet supported but I plan to implement this.
19,239 2:03
@ Postgres synchronization solution
「勝つ」コピーの問題を解決する方法についてのアイデアがあります。
すべての列フィールドと行をハッシュし、それにバージョンを与える別のテーブルを用意します。
比較対象のバージョンです。
I have an idea on how to solve the "winning" copy problem.
Have a separate table that hashes every column field and row and gives it a version.
This is the version that is compared.
ほとんどのコンピューターは同期にロックを使用しますが、これは非常に低速です。この設計ははるかに高速であり、ロックを省略してパフォーマンスを向上させることができます。
私は非同期データ構造を使用し、1 バッチのメッセージあたり 10 ナノ秒のコストで、1 秒あたり 1 億回のリクエストを生の通信パフォーマンスで達成しています。
Most computers use locks to synchronize, which are very slow. This design is far faster and allows locks to be elided for performance.
I use unscynchronized data structures and achieve 100 million requests a second raw communication performance for a cost of 10 nanoseconds per batch of messages.
JSON ドキュメントを保存し、SQL インサータを使用してドキュメントを挿入しました。理論的には、オブジェクトは SQL でクエリ可能です
{
"アイテム": [("名前": "アイテム1"), ("名前": "アイテム2")],
"subobject": {"subobject_key": "value"} }
I managed to store a JSON document and I used the SQL inserter to insert the document. In theory the object is queryable by SQL
{ "items": [("name": "item1"), ("name": "item2")], "subobject": {"subobject_key": "value"} }
- 現在、ターゲットの所有者は、ターゲットがいつ投資の準備ができているかを決定できます。デフォルトでは、投資は準備ができていません。
- Now, target owners can decide when target is ready for investment, and investment is not ready by default.
| 19,227 2:02 | ➔ | 0.02 ħ |
| 19,227 2:02 | ➔ | 0.040000000000000084 ħ |
| 19,227 2:02 | 🡰 | -0.04 ħ |
| 19,227 2:02 | 0.04 ħ | ➔ | #t-130001 | (+0.04 ḥ ⇌ Mindey) |
