Fork
edit==== common
* 単純なデバッグ
* 背景色でスライダーをいじった後、チェックボックスを指定無しにして、改めてオンにすると、入力フィールドはゼロに初期化されているのに、スライダーは初期化されていない。
* スクロールプレイヤーのコンパネでパネルの詳細ページに異動できないように思うが?
* パネルエディタでエレメント削除の効果が及ばない。
* ファイラーでアイテム削除するとエラーが出る?
* ライセンスのプロファイルからコマ絵を参照できないような?
* 紙コマの詳細ページのjson APIが壊れているように思う。こんな複雑な結果を返さなきゃいけないか?
* 実素材の詳細ページは無い。期限切れの実素材を表示しないような対策が必要なので後回しになっている。
* 原画の詳細ページに、同一素材がすでに投稿されていないか確認するための部品が要る
* configページを作ろうよ!まずはアイコンの制作から。認証トークンの作成はできるんだっけか… 。これはサーバに任せた方が良いような… 。作家と絵師の登録案内だけは用意した方が良いか。
* 原画でライセンスを与えるダイアログで、拡張データの表示を崩してしまっている。
* 原画でライセンスを与えるダイアログで、ライセンスの選択肢がソートされていない。
* デモサイトのログインページでライセンスに関する注意書きを入れた方が良い。
* エレメント付きパネル取得の失敗はダイアログではなく、パネルっぽいボックスを描画する方が良いのでは?画像でも同じだと思う。
* fetchの失敗で考慮するケース
* アイテムの基礎メソッドではオプションないの失敗関数を呼び出すことに専念する。
* シンボルオプションで画像を取得するときに失敗したらペケ画像を返す。これはモデルの素材、実素材、システム画像と原画で現れる
* ファイラーのキャプションでモデルを参照する場合、失敗したら「???取得に失敗しました」の文字列を返すのが良いか?これはモデルのライセンス、原画、フキダシで現れる
* 入力フォームのセレクトボックスで選択肢を読みそこなった場合、…どうしましょ?入力フォームの親までメッセージを伝搬させなければダイアログを出すことができない。
* クレジットのアイコンを読みそこなった場合、ペケ画像を返す。
* inspireのマスターデータ取得をそこなった場合、インスパイアライブラリ側は失敗関数を呼び出す。パネルのフッターはエラーダイアログで良いのでは。
* ファイラーの要約のバインダーとリーフで親子関係を読んでいるが、ここで失敗した場合はどうしましょ?ペケアイコンと取得失敗メッセージで良いかな。author byを使うのがよろしい。
* 詳細ページでコンテンツオーナーのペンネームを表示している(author by)が、ここで失敗した場合は「???取得に失敗しました」で良いかも。アイコンとラベルのペアはよく使うのでクラスとして定義する。
* あとは個別のビューの中で取得している
* プレイヤーのページ処理がいい加減な作りになっている。スクロールが空っぽの時に表示を切り替えるべきなのだが… 。根本的な設定ミス。しかも現行バージョンも動作してないし!
* ライセンスの練り直し
* ライセンスで設定するフラグには三種類ある。絵師などの画像を編集する人たちが見るべきフラグ。作家などの素材を利用する人は見るべきフラグ。システムが見るべきフラグ。
* 絵師が見るフラグは最も重要度が高い。このフラグが適切に運用されているかどうかをシステムの検知することはできない。絵師が適切に運用してくれることを期待するしかない。よって、もっとも目立つ位置に表示されていなければならない。
* 作家が見るフラグは重要度が高い。このフラグはシステムが介入して適切に運用させることができる。作家に認知してもらわなければならないので、ロゴの下段にフラグを表示しよう。
* システムが見るフラグは重要度は低い。絵師に配慮してぺったんRが独自に盛り込んだフラグ。作家はこのフラグを意識することなく素材を利用しても不都合は起きない。
* トラックバックという名称は適切ではない。 MD5で連結されるものなので。原著作者は通知されることを期待しないで探さなければならないだろうか。ツリーが連結されれば表示も可能だと思うが。(多対多なので)そのための中間テーブルが必要だね。さて、中間テーブルの構造をどうするか… 。素材は上書き更新されてしまうので、md5でツリーを維持することができない。実素材でツリーを管理することになるが、原著作者としては、原画ベースで把握したい。ここをもう少し掘り下げる必要がある。
* GIF変換、サムネイル化の禁止はシステムに対して通知するフラグ。デフォルトではGIF変換できる・サムネイル化して良い。前回の設定をクッキーに焼いて保存している。
* アスペクト比の変更、反転(回転)の許可は作家向けのフラグ。
* トレース(トラックバック)フラグはやりたい気持ちはわかる。原作者の手がまわらないときにファンたちが改変して行く際に混乱しないための目印になる。しかし、それ をURL形式にしてしまうとサイト間の連携ができなくなってしまう。 MDライブで記述してツリー構造にするべきか。このフラグはライセンスの特記事項のsourcesと直結しているよね? 。このフラグがonの時、sourcesを参照して参考にした画像を設定しているかチェックする動作のはず。カラム名がマジックワードになっているのがダサいなぁ。
* Trace wordが指定された素材が更新された直後、ツリーの構築が始まるのか?リンクをクリックしてたどっていけるようにしたいなぁ。
* オーバーラップはプロテクトライセンスのために用意してあるもの。クリコモを安易に使わないために導入したものだろうが、クリコモは撤廃されてし まったので使い道なし。プロテクトライセンスでの利用方法は絵師が独自サーバを用意する時のみ有効。オーバーラップ禁止でweb公開しておけば、 誰でもサンプル素材を閲覧できるが、ぺったんR上では漫画にできないはずだから。でもこれcopyrightでいいよね。
* SNSモードでの利用禁止はライセンスのインポートの時点で落とさないと。
* No deriveの時はソースを入力させない。deriveの時はソースを入力しても良い。ただし、トレース指示があるときは入力必須とする。trackback_column_nameライセンスのjsonデータに組み込む。デフォルトは'sources'
* ライセンスの選択をもうちょっとわかりやすくしたい。
* やはり、絵師向けのフラグと作家向けのフラグを段階別にした方が分かりやすいような?
* わかりづらいだけで現状の仕様でも問題はないのだ。サーバ側のページでは特にいじらなくても良いはず。問題は、クライアント。
* そこで、クライアントはうまいことハックして選択インターフェイスを二段にする。
* それをしたくても、各ライセンスの中でどれが第一段階のライセンスなのか判別できないので、どないしましょ? 。
* 管理名で判別するか?上段と下段を/で区切っているので…あまりこういった制約は設けたくないのだが。
* 並び替えのカラムを追加する。一覧娘の並び替えは管理名で行われるが、ライセンスグループID +順序でできるだろうか? 。
* マイナーバージョンフラグを追加してはどうだろうか。こだわりがない人には関係ないフラグなので。
* それともグルーピングするか。並び順が一番若いライセンスがメジャーバージョンで、それ以外はマイナー。
* 全部追加しちゃってもいいんじゃない?
||t||integer||ライセンスグループ単位での並び順||
||minor||integer||0の時プライマリライセンス 大きいほどマイナー||
||category||integer||絵師向けフラグが同じ物をグルーピングするための数値||
* 絵師フラグ しなければならない/しても良い/してはならない
* システムフラグを追加できるようにする。これはサーバも対応すべき。
* サーバ側には入力フォームテンプレートを用意してフラグをマージできるようにする。
* クライアントも同じでいいのかな? 。
* エレメントのライセンス追従
作家はスムーズに技能を修得できるか。自分のコマが壊れないか。コマの維持は絵師の活動によってある程度左右される。自分のコマ絵の適切なアップグレードがなされるか。
* test
* コントローラとビューの正常系だけでも書いておいた方がよさそう。
* モデルを通るといいな
* PR活動
* 毎日一つくらいはコマを作成してPR活動をしていこう。
* 素材を作る、ネタを考える、参考資料を読み漁るなど何か一つをすればよいことにしよう。
* 保守的な開発
* APIのレスポンスに少々揺れがある。特に一部のリストがページステータスを含めていない。
* ライセンスコントローラにsearch APIが実装されている。これはおそらく、素材の貸し借りで必要だったのだろうが、各種リストAPIに絞り込み機能が追加されるので、そちらに移行する見込みで削除する。実素材および素材にもsearch APIがある。このレスポンスにはページステータスが含まれていないので、ここもを考慮する。
* カウンターapiは削除しちゃって良い。どうしても件数取得したいときは、ページサイズを一にしてリスト取得。ページステータスからトータルサイズを参照する。本丸カウンターapiの仕様が落ちてしまっているので、こちらは復帰させる。やはりSNSモードでも公開中のなんちゃらの件数は取得できるようにしたい。
* プレイAPIについて考え直したい。ストーリーと用紙はno limitで取得している。仕様としては正しそうだが、もう一度落ち着いて。
* パネル一覧をプレイモードで表示したいところだが、そこを区別するAPIをいかにするか。今のところmode =filerみたいになっているけど?
* テキストブラウザでも正しく表現できる様にする。
* yasappではシステムリソースの選択肢取得でdisabledのフラグを完全に無視しているはず。本来なら、サーバ側でフラグを停止すること で危ないライセンスを使えないようにできるはず。
* それで結局、拡張アイテムは一つのテンプレートしか持つことができないの?
* これはパネルエディタの設計ミスとも言える。
* 何が嫌かって、オブジェクトを一度ブーストしてしまうと、後戻りでそれを取り消すことが難しいからだったんだよね。しかし、パネルエディタではキャッシュのクローンを使うことになったので、問題は既に解消しているとも言える。新規作成中エレメントのオブジェクトを除いては。
* primaryのテンプレートを変更したときには、タブのフェイスも更新することになる。この辺すごく面倒なのだが、やはりこれもパネルエディタの問題。
* もう一つ、デフォルトのテンプレートが決まっていない。セカンダリのテンプレートはこれがないとどうにもならない。しかし、これも、パネルエディタのUIの問題。せめてプライマリのテンプレートくらいは決めてもらわないと話にならないので、誰がデザインしてもそうなると思うが。プライマリセカンダリにかかわらずデフォルト値は用意しておいた方が幅が広い。
* これだけの準備があればコマ絵の素材を選び直すことも不可能ではないが、複雑になるだけなのでフキダシのフキダシテンプレートと記法だけ変更できればいいや。こいつらだけは、作ってみたが、やっぱり違うなと思い直して変更するシーンが多いと思うので。
* リストグループはもう使ってないのでを削除して良い。page statusあたりで使ってるけどね。
* Herokuのサーバのバージョンが古過ぎてapiが古い形にしか対応していなくて、パネルインポート処理が回収できなくなっている。
* インスパイアの後にちょっとだけ動きがひっかかるので、余計なところをクリックされないように処理中のモーダルウインドウを表示してはどうか。本当にクリックできているのか不安になる時があるので、アプリケーション全体で考えてみる。
* 一覧の結果もキャッシュしたいような気がする。
* リフレッシュボタンが欲しい。
* 先進的な開発
* フキダシテンプレートを充実させる。
* エレメントにフレームを追加する。
* APIに対応しているので、 WordPressなどのプラグインによって、自分の記事に漫画を埋め込める。
* 一覧のAPIで絞り込みに対応する。
* モデルごとに絞り込み可能なカラムをリストアップしておく。 APIのパラメータにsearchが指定されているとき、その値を絞り込みカラムとして、 SQLを発行する。絞り込み文字列はパラメータのvalueから取得する。searchがallの時は全ての絞り込みカラムでフィルタする。
* 入力フォームのvalidationを強化。パネルエディタで不正な値を入力した時にタブの色は変わらない。
PanelEditor
コントローラのエイリアスの仕様がイマイチだと思う。
Bucketを復活させてエレメントツリー通りにフォームを展開する。最終的には、パネルのエレメントツリーから投稿データを生成できれば良い。
== JavaScriptクライアントの微妙な問題
=== アセットパイプラインの黒魔術ではまったり
クラス名が短縮されるので、 (コンストラクタの)クラス名をもとになにかを処理しようとすると痛い目を見る。例えば、名前の活用などができない。クラス名をスネークケース化してアイテム名を取得することができない。
=== ベースURLが異なる。
backboneのルーターでは、パスの先頭に/を含めてはいけないが、サーバには含めなければいけないといった違いがある。これによってURL生成処理を移植する段階で両者に差が出る。
== コマの表示単位をピクセルからemに変換する
http://pettanr.sourceforge.jp/test/html2comic_0.4.html
=== タスク
拡張データ内のフィールドは拡張データの枠を超えて並び替える事は出来ない。
マニフェストを圧縮する目的で、コピーしつつ拡張していたが、その手法はできなくなったので、例えばライセンスの拡張データでは、細かなフラグを共有することはできなくなった。
* マニフェストを固定する。
* マニフェストをエンジンに分離する。
* マニフェストをアイテムごとにファイル分割して、何らかのコマンドでマージする。こうしないと、エンジンで機能追加したとき、マニフェストの同期が出来ない。
* ライセンスのロゴを正方形にすると、ファイラーでシンボル表記がかっこよくなる。その他、様々な場所で扱いやすくなる…はず。
== 拡張性アイテムとは
* settingsの更新
ブーストした後にsettingsを更新しても、ブースターがつかんでいる拡張データはすでにインスタンス化されたオブジェクトなので、反映されない。settingsを代入し直すには、ブースト前に行うか、update_settingsメソッドを使う。
= 積み残し
AboutScenario
= ぺったんRを使ってみて感じたこと。
あらかじめ台本を作成してあって、それをコマに展開したわけだが、必ずしも台本通りに表現できるとは限らない。台本の作り方が甘いという考え方もあるが、いざ作成段階になってみて期待した素材が見つからなかった場合、大幅修正を余儀なくされる。また、コマにフキダシを載せてみるとフキダシがキャラにかぶったり、フキダシ同士がぶつかり合って、期待通りに配置できないこともある。分業するにはそれなりのテクニックが必要なようだ。
http://www.hi-ho.ne.jp/makoto_watanabe/ve/
こういうツールで作成した台本からコマの雛形を作れれば最高なんだが。ある程度のレベルまでは簡単な記法からスクリプト生成することは可能に思えるが… 。
台本を作ってからコマを作成するのが正しいが、必ずしもそれにのとらなければならない訳では無い。難しいことがわからない人にはシンプルに始められる余裕が欲しい。
国際化で問題になるのは画像を反転させたときオノマトペまでが反転ししまうこと。最低限そこだけでも別のレイヤーにしておくことが海外販売の常識らしい。
レイヤー機能が必要だったか？
==
アカウント停止フラグ原画も素材IDバックアップコミックも作家の停止と座長の停止
ライセンスは途中て替えられないフラグ変更不可
== 縦書きに関する考察
* Evilにはなるまいと心を砕いているが、一つだけ、実現するならEvilになっても良いと思うものがある
* 縦書きというやつだ
* かねてより横書きには不満がある
* 字の並ぶ向きが違うとか、ページをめくる向きが違うとか以上の違いがある
* 右利きが左を使うくらいの違和感
* 横書き漫画はなんとなくつまんない
* たぶん、同じ内容でも縦と横で面白さは変わってくる
* なぜか
* 人間の視野は横に広く、縦に狭い
* 横の動きに強く、縦の動きに弱い
* 横書きの方がリーディングの効率が良い
* 漫画は敢えて縦書き
* だが、それがいい
* セリフを追いながらも視界は絵を捉えている
* 読みの速度が遅いから絵を見る時間も長い
* 視線を何度も上下させて楽しむのが漫画
* 横書きだと…
* セリフに集中して絵を見てない
* コマをすぐ通過するから印象が残らない
* 洋書に挿絵が少ないのは、横書きだから
* 漫画文化は縦書きが生んだ
* 縦書きでこそ漫画
* CSS3.0では縦書きもできるらしいが？
{{{
あとは、数字の前にコメントが欲しいです．アウトソースなら、コミック（コマ？）毎に一意な twitter ハッシュタグを作る機能とかがあればとりあえずはいいのかな？ これならクライアントだけでできそうですし．ブクマのコメントも js で取れます．
}}}
http://sourceforge.jp/forum/message.php?msg_id=62287
* 逆フキダシ
* min_width→lower_limit
* no_adult ？
== ライセンス
== 画像の衝突
* 同じ画像がサーバに入ることがある
* 誰かがパクった？
* 素材サーバをやってる絵師が他のサーバでゴニョって重複してまった。
* md5を採用して保存すればユニーク。同じ画像はアップロードできない。
* 投稿時にValidate
* md5って計算速い？
* 時間かかるなら仕様がぐらつく。
* 投稿フォームからなら一枚単位だから楽。
* xmlインポートなるものが
* インポートは一時テーブルにたまる
* 問題ないのは正式に投稿される
* 衝突が起きたら残る
* 誰のどのライセンスか
* 誰かと衝突したらページに警告が？
* 著作権違反の疑い
* 詳しくはこちら
* 衝突ページへ
* 自分どうしであれば相手に委譲すればよいが。
* 結局誰が強いのか
* 管理者に任せるのがプログラマ的に楽
* 絵師の仕様がかわる？