決戦IndexedDB

これは何?

ブラウザに無限のストレージが用意されました。

  1. COOKIEは4KBまで
  2. LocalStorageは5MBまで
  3. 外部ファイル?セキュリティのためアクセスできません。

この軛がようやく解消された。

どうして決戦なのか

どうしてこの仕様になったかわからない仕様だらけ。この苦難のため2年ほど足踏みした。どうしてもクライアントサイドで大量データを扱わなければいけないので・・・

  1. 非同期、非同期非同期の連続、そしてバージョンという概念
    1. UIスレッドをノンブロッキングなのはわかりますが・・・非同期処理のいなし方知らないと詰む・・・
  2. キーが外部もちとデータ内保持と二種類あった。
    1. ここを理解しないと目的のデータを取り出せない。
      1. キーが外部もち:KVSのようなイメージ:OutLine−Key
      2. キーがデータ内保持:RDBMSの様に一部のプロパティーがキー:InLine−Key
      3. なにも知らずにデータ投入するとキーが外部もちになって自動連番がキーに成るため、目的のレコードを取り出せなくなってしまう。
      4. 数万オーダーのデータ処理を考えると取り出すときに全件取得はありえない。多分メモリ不足でブラウザが落ちる。
    2. DBのバージョンという概念がありまして・・・
      1. 追加、修正、削除、CRUDのCUDはバージョンアップが必要
      2. バージョンを正確に記述しないとObjectStoreの削除と作成がうまくできない。
      3. 一つのDBの中に複数のObjectStoreが有る状態で同時複数のDropCreateをトランザくショナルにやろうとするとなかなか壮観な非同期入れ子状態に成る。
  3. 溢れるエラー
    1. DBのバージョン違いはひどかった
    2. エラーの内容もわかりづらい。UnknownErrorってなんなんだー
      1. もちろんPK違反はわかるんだけどね。ConstraintError
  4. KeyPathという未解明の仕様
    1. 名前からしてパスのようにKeyを構成できるように聞こえるが利用方法がよくわからない。
    2. keyにピリオドは入れられない。
    3. もしかしたら1オブジェクトストア内に入れ子でデータ持って検索できるかもと思ったがに駄目だった。
  5. めまぐるしく変わる仕様
    1. 仕方ないのだが、実装も仕様も安定しなかった。
      1. CRUDでのバージョン取り扱いが以前は必要だったり
      2. ChromeAPI実装が標準から離れていたり
    2. ようやく現在はまともに動くように。
      1. Chrome37ではRangeにundefinedを渡すとエラーに成る。

どうあれば嬉しかったか

  1. 普通のSQLだったら良かったのに
    1. WebSQLが退けられた理由をまだ把握していない。
  2. 非同期の他に同期のオプションもあればよかったのに
    1. 非同期はハードル高いよ

特徴

以下RDBMSに比較して

  1. キーは基本一個です。
    1. 複数キーは出来るようだが、めんどくさくてやってない。
  2. 検索にはキーを使えます。
    1. 範囲絞り込みが可能です。
      1. RDBMSの様に使おうとするとキー設計に親子関係を練り込むことを考えてしまいます。
      2. jsに処理を移譲するのはやはりですね・・・ネイティブで済ませられるならソレで。
    2. 複数のキーを連携させることはできません。できる?
      1. Indexは複数作成可能なようですが。
  3. Indexで検索が出来るようです。
    1. できるようです。
  4. ただし、複雑な条件を受け付けるAPIはないです。
    1. いったんjs上にオブジェクトを展開してそこで比較するなどの条件適用が必要になります。
    2. JOIN系、GroupBy、UnionのAPIは無いです。
  5. 非同期につぐ非同期なので変な処理をはさむと遅いです。
  6. 変な処理がなければLocalStorageよりは速い気がする。
  7. FirefoxChromeは普通に動く。
    1. SafariもIE10以降も動くらしいが、悪いな家にはLinuxしかないんだ。
  8. Chromeには削除する方法があるがFirefoxCookie前消しでのみ対応
    1. 自前でDB初期化ロジックが必要

展望

何もかもDBに突っ込もうぜ!
  1. 画像
  2. 設定
クラサバが復権する

有る意味悪夢

WebRTCと組み合わせれば

夢の認証以外ストレージレスサービスが構築可能に。

セキュリティ

まあ暗号化しておかないと見る人見たら丸バレだよね

  1. ChromeとかBookmarkletとかとか。

漫画を毎週1枚挙げる体制作成に向けて。

志は高く

現状漫画を書きたいが書けていないので掛けるシステムの導入を図る。(5年越し)

やりたいこと

週イチで所要時間3時間ほどで漫画を1ページアップしたい。

  1. 内容はストーリー漫画であること
  2. 最終アウトプットの手間はボタンひとつ(チェックボックスも可)
現状

現状は以下の手順が必要

  1. 漫画のストーリーを描く必要がある
    1. プロットを作る
    2. 内容の整合性と演出を考慮する。
    3. ページにちぎって
    4. コマを割ってネームにする。
  2. コマを割る
  3. 噴き出しを描く
  4. 噴き出しに文字を入れる
  5. 下書きをする
  6. ペン入れする
  7. エフェクトを入れる
  8. png,jpeg等の出力画像に落とす
  9. 公開先サービスに投稿する、投稿文を記述する。

上記の手順を踏むと3時間では当然収まらないわけで

解決手段

手順を以下のうように変えてみたい。

  1. 平日にストーリーを構築、ネーム切るまでを完了させる。
  2. まとまった作画対応が取れる日に最終作成を行う。
システムとしての支援

結局業務系のシステムと同じでどこまで手順を目視可能にするかが鍵に思っている。
脇を締めて力を逃さず少ない力で目標に打ち込む。

  1. 文字をデバイスをまたいで一箇所にプールする。
    1. スマフォでもPCでも見れるし動く※iPhoneは除く
    2. ストック形式、量ともにツイッター式の方がいいのではと思っている。
      1. 編集作業は材料があったほうが格段に楽である。
    3. 書いた断片を整理する手段を提供する。
      1. トゥギャッターのように順番を修正できるようにする
      2. タグで振り分けられるようにする。
  2. システムが単位を管理
    1. 利用者はこの単位に従い情報を蓄積する。
    2. 考えられる区分けとしては、シリーズ、作品(話)、ページ、コマ、吹き出し、擬音、エフェクトなど
  3. ゴールまでのステップをシステムが明示する。
    1. ゴールまでに完了していないステップを提示する。
  4. 利用者に報酬を与える。
    1. アクティビティマップを提示
    2. 消化ステップ数を挙げる。
  5. ペースメーカーとなる。
    1. 埋めていく速度を記録して過去の実績との比較で線を提示する。
    2. 成功確率も上げていく
  6. 下書きまでをWebでサポートする。
    1. そのまま公開できるようににもする
      1. Pixiv,Twitterその他

ちなみにプラットフォームはWeb
それもクロスプラットフォームで作動することが高確率で期待できるFirefoxChromeが対象。

到達したい地平線。


・非常に容易に安価に入手が可能(5000円程度)
・ネットワーク機能を搭載
・バッテリを搭載
・5vで作動し、5Vのバッテリが潤沢に供給されている
・持ち運ぶのに支障がないサイズ
・計算機ノードとして申し分ないスペック
・簡易なディストリビュートが可能な手段がある。
Androidスマフォしかない。(Appleの製品は自由さ、互換性、速度、メモリ容量に劣るので使いたくはない。)