要求・要件の整理 #1
Comments
|
議論のタネに、一番横着したパターンを提示してみます。アイデアソンではもう少し、WebをFatにする方向性だったのは承知しつつ書いているので、参考程度にしてもらえたらと。 編集・校正ツールWebアプリに仕立てる場合は、これら要素技術の組み合わせに。
工作員ネットワーク「工作院」gemやnpmを念頭に。書籍のGitリポジトリはそれぞれがGitHub/Bitbucket/独自で持っていて、バージョンタグのついたものだけ、中央サーバにコピーするイメージ。
|
|
@cognitom さん、まとめありがとうございます。aozora-flowの要件を考えていて少し疑問に思うところが出てきたので相談させて下さい。 管理するテキストデータの単位について基本は青空文庫で言うところの「作品」だと思うのですが、それで問題ないですかね？ページ毎に分けて入力とか校正をできる様にするにはもう少し細かい単位になるのかも知れないと思いましたが、他の代案が思い浮かばず、取り敢えずは作品単位かなと思ってます。 変更者（工作員）情報の保持について入力はシステム直接だけでなく、メールや郵送で送られてくる事もあるとの事。したがって誰か別の人がシステムに代理コミットする事が前提になります。となると、gitの変更者の情報が即ちテキストデータの変更者とはならなくなります。 これをgitの中でやろうとすると例えばauthorを必ず指定して実際の工作員の名前・アドレスを入れる様にする事になります。それで何かしら不都合はないでしょうかね…？ 工作員のIDについてEmailアドレスをIDにするというのは一案と思いますが、変わる場合もありますし、複数持っている人もいるので何かしら別のモノを振った方が良いでしょうか？ 取り敢えずアドレスの想定で良いですかね？ もしこれらで何か気がついた事やご意見があれば是非。 |
|
自己フォローになりますが、emailアドレスは個人を特定する情報になるので必須にするのはまずいですね。自ら認めた場合は別として、現在運用されている様に略称に留めておくのが良いのかも知れません。 |
|
あんまり文脈がわかっていませんが、青空文庫では工作員IDとして数値を振っています。ID自体は公開情報です。 |
|
@takahashim さん、ありがとうございます。工作員の方には既に連番のIDが振られていたのですね。参考になります。 |
|
みなさま、ありがとうございます。 @cognitom さんのアイディア - #1 (comment) は、基本 GitLab/GitBucket 的なモノをほぼそのまま使い、青空文庫の文書フォーマットに最適化された最低限のツールを用意する、というアイディアですね。 編集・校正ツールについて
たぶん git-flow みたいな、成果物たる電子書籍をパブリッシュしていく上での一連の手続きのことですよね。
これはちょっとよくわかってないです。
この辺り必要そうですが、既に利用可能なツールもありそうですね。
とりあえずは GitLab 等(Git)のやつで事足りるのではないかと。
As Is でいいような気もしますが、なんらか変換しなければならないケースもあるかもしれませんね。
つまり「工作院への登録」ひいては「工作院利用マニュアル」になるという理解でよいでしょうか。 工作員ネットワーク「工作院」について
この辺り、自分のイメージできていないところです。 なんとなくですが、Web 側を API 中心に提供するか、Web UI での操作を前提にして作るかを、まず方針として決めた方がいい気がしています。 これはプロトタイプ段階では GitLab or GitBucket でどちらがやりやすいかで決めればいいかな、と思います。 以下はこちらを踏まえてコメントします。
必要ですね。
必要ですね。
"aozora-flow" とも絡みそうですね。
あまり難しいことは考えてないですが、とりあえずは GitHub っぽく commit 数が可視化できればいいかなぁと。
API ベースで作るなら必須ですね。 |
|
@ksato9700 さんのコメント #1 (comment) について。
自分もそのイメージでした。
なるほど。全然考えてなかったです。
メアド or 工作員ID を UNIQUE なものとして扱えそうですね。 |
|
@key-amb さん、コメントと整理ありがとうございます! 長くなりそうなので、議論を分割した方がいいかもしれませんね。と言いつつ、とりあえずこのまま返信しちゃうことををお許しください。 aozora.json
のところですが、npmの {
"name": "高瀬舟",
"version": "1",
"status": "released",
"author": "森鴎外",
"transcripter": "cognitom",
"corrector": "someone",
"repository": "git://github.com/cognitom/takasebune",
"format": "aozora-text"
}工作員ネットワーク
Gitサーバは各自が用意するつもりでいました。ここがちょっと私の認識のずれていたポイントかもしれません。著作権の残ったものが念頭にあったので...。参考まで、 GitHubやBitbucketであれば基本サインアップするだけで使えるので、マニュアルを整備すればなんとかならないかな...と。その辺単純化した、工作員向けのGitサーバを用意するのもありです。 編集・校正はWeb? クライアント?
ですね。最終的にはWebですが、先にクライアントで作っちゃった方が、早そうだと見てます。最小ステップとしては、幾つかのCLIコマンドの開発くらいなので、どちらかというと「頑張らない」ためかも。(ただ、そのままコマンドを工作員の方に叩いてもらうわけにはいかないので、atomのプラグインかelectronアプリ他で、ラッピングする必要はあります) |
|
おおお、なるほど！ やっと本質的な違いがわかったような気がします。
プロトタイプとして、サーバ機能は GitHub 等を使って、あとはクライアント側で頑張った方が速い、という発想ですね。 それはそれで全然アリだと思いますね。 「工作院」の方はサーバ側で頑張るプロジェクトとして、それとは別にクライアント側で頑張るプロジェクトを作るのはいかがでしょう？ クライアント側でどう要求を実現するのか、自分はイメージできていないところがあるのですが、おそらく @cognitom さんの中にはあって、勝算があるのではないでしょうか。 仮にリポジトリが分かれても、お互いに進捗状況など情報共有して、「工作院」側としては適宜アドバイスなど頂ければな、と思います。 ご一考下さい。 |
|
いくつかの要素技術を切り出した方が良さそうですね。 |
|
たぶん皆さんでホワイトボードの前で議論した方が早い気もするのですが、@cognitom さんの「npm pubilshのイメージ」で「各自がgitリポジトリを持つ」とした時に、どんな構成になるのか少し考えてみました。そして、いまだに大きな勘違いをしている気もするのですが、取り敢えず絵にしてみました。 元々の私の想定は全ての作品のテキストデータが入ったリポジトリが一つだけあるのかなと思っていました。ですが、各々が持つとすると全てをCloneするのは無駄すぎるのできっとGitリポジトリは作品単位になりますよね。自分が入力したい作品のリポジトリを共有リポジトリサイトに作りそれを手元にCloneしてくる。そして入力後、push。校正もそこからcloneしてきてPushで戻す。 そして出来上がった作品のテキストデータは npm publish的にaozora.jsonのメタを付けて別の「完成品置き場」にpushされるのかなと思いました。これもgitベースで作っても良いと思いますし、単にNoSQL/SQL DBで作っても良いのだと思います。 そしてAPIサーバーの方はこの完成品DBをバックエンドに持ち、フォーマット変換や統計情報処理などしながらデータ提供する、といったイメージです。 この想定だと、Aozora-flowとして必要なのは前半の入力や校正を行うためのgitリポジトリの為のルールという事になります。その詳細に入る前にここまでの想定が大きくずれていないことを確認したいのですが、いかがでしょうか？ ＞ @cognitom さん、 @key-amb さん |
|
わお! @ksato9700 さん、ありがとうございます!! |
|
@cognitom さん、ご確認ありがとうございます。それほどズレていなくて良かったです。 aozora-flowはgit-flowの流用で行けるような気がしていますが、仕様の明確化などのためにリポジトリあっても良いかもしれないですね。ご助言ありがとうございます。 |
|
@ksato9700 さん、整理ありがとうございます！
なるほど。 @cognitom さんは工作院を「完成品置き場」として考えてらしたのですね。 さて、自分のイメージがお2人の考えていたものと違ったことがわかったので、一旦私の案は置いておいて、お2人の案(というか @ksato9700 さんの図)をベースに考えてみます！
これはこれでアリなのではないかと思いますが、いくつか気になる点が出てきました。ので、以下に挙げます。
ひとまずこんなところでしょうか。 で、それらが解消されるとしても、やはり私が最初に思い描いたものとは違ったものになりそうなので、「公開作品置き場としての『工作院』」の方も、kosakuin とはリポジトリを分けた方がいいのではないかな、と今は思っています。 長文になりましたが、以上です。 (みなさんの都合が合えば、下北沢辺りでディスカッションしたいところではありますが。。いったん非同期で。) |
|
仰るように同期でお話できると早いと思いますが、まずはここで続けてみます。 私も実は最初は @key-amb さんと似たようなイメージを持っていました。共有リポジトリがすなわちAPIサーバのバックエンドにもなる。ここは今後の議論次第と思いますが、その可能性も無いわけじゃないと思います。READMEにaozora-flowの最初のアイディアをあげてみましたが、masterブランチ上でPUBLISHEDタグの付いているものは公開できるファイルなのでそれをそのまま公開サイトから参照するという方法もあるかと思います。 そして「幾つかの気になる点」として挙げられているポイントに関してコメントしてみます。
以上です。 |
|
@key-amb さん、一度、同期でお会いしたいですね。下北沢歓迎です :) たしかに、アクセス制御については考える必要があります。受け入れ可能な、著者名を限定するとか、公開を承認制にするとかいくつか手はあるかも。あまりまだ深くは考えてないのですが... どちらの方向性もあり、というか、要素技術を切り出してちまちま出していくか、まるっと出していくかの違いかな、とも思います。一旦、アイデアが出尽くしたところで、車輪の再発明をしなくて良いよいうに、プロトコル的なところの調整をしたいなと、いう感じでしょうか。 @ksato9700 さん、「ベーシックな仕組みだけを用意して、その上のツールで何かしらカバーできたらなと」に私も期待するところです。 |
|
@cognitom @ksato9700 さんと昨夜、下北沢のOSS Cafe で話して、方針をすり合わせました。 基本方針としては、 @cognitom さんが言うところの「完成品置き場」の実現をまずは目指すとします。 もう少し詰めないといけないところはあると思いますが、このイシューはちょっと伸びすぎているので、いったんクローズした方がいいかなと考えています。追って整理します。 @cognitom @ksato9700 さん、昨夜はありがとうございました！！ |
|
こちらこそ、ありがとうございました! お会いできて良かったです :-) |
aozorahack/aozorahack#1 の続き。
「要求・要件の整理」にとどまらない話も上ではありましたので、そちらは別イシュー切ってもらってもよいです。
要求、要件というカタイ言葉を使わずに言うと、「青空文庫の工作員の方々(より一般的な雑誌・書籍の編集・校正作業を含んでもいい)がこのシステムを使ってこんなことができるようになったらよさそうだな」というものと、「それを達成するためにこういうシステムを作ったらよさそうだな」ってとこですかね。
議論のアウトプットはこのリポジトリ内(か、どこか)にドキュメントの形でまとめたいなと思います。
完璧に洗い出すことにはこだわらない方針としたいですが、これを元に設計を進めることができるようになったり、ゴールイメージをある程度みんなが共有できるようになったらいいなと思います。
The text was updated successfully, but these errors were encountered: