19:48追記とうとうアイデアソンが明日に迫りました。当日の注意事項を下記のURLに書きましたので、参加者の皆様は必ずお目通しをお願い致します。直前となりましたが、多くの参加希望を頂きましたので、なんとか調整して80名まで定員を増員いたしました。それにあわせて少しプログラムを変更する予定です。本当は声を上げてくださったみなさま全員に来ていただきたかったのですが、会場と運営サイドのキャパシティ的にこれが今回限界でした。ご参加いただけなかった方にはお詫び申し上げます。時期をおかず第2回を開催するとともに、今回のレポートを時間を置かずに公開できるよう努力します。20:55追記おかげさまで募集開始から6時間足らずで増員した定員60名を超えました。多くの方にご参加いただきたく、また都合によりキャンセルされる方はキャンセル手続きをお願いします。19:55追記おかげさまで募集開始から5時間足らずで当初の定員(50名)に達しました。運営サイドとしてもここまでのスピードと注目度を予測できていませんでした。そこで検討の結果、10名の増員を行いました。これ以上の増員はオペレーション的に無理なので、参加をご検討の方はぜひお早めに参加表明ください。都合によりキャンセルされる方はキャンセル手続きをお願いします。みなさまのご協力に心より感謝いたします。青空文庫をサポートする「本の未来基金」では、青空文庫をテクノロジーで支え、発展させるお手伝いに興味をもっていただけるエンジニアの方を探しています。興味のある方はぜひご参加ください。青空文庫は現在エンジニアなしで5台のサーバを運用しています。サーバの老朽化も問題となっています。そこで青空文庫が今後も発展を続けることができるよう、エンジニアの皆さんの力をお借りしたいと考えています。青空文庫」の当面の大きなテーマはデータベースですが、今後も青空文庫を技術面でバックアップする活動を続けていく予定です。PostgreSQLで動いていますが、それ以外の技術をお持ちの方も大歓迎です。サーバインフラの問題が本ハッカソンのきっかけですが、「青空文庫にこんな機能を実装したい!」というエンジニアの方もぜひ!もちろん「エンジニアではないけど青空文庫の未来を考えたい!」という方の参加も歓迎しますが、今回は会の性質上、希望者が定員に達した場合はエンジニアの方の参加を優先させていただきます。香月啓佑(本の未来基金)前半の説明を聞いていただいて「これは協力できないな」と思われた方は、後半にご参加いただく必要はありません。昼食後、13:30をめどに適宜アイデアソンに入ります。「インフラ」「アプリ」「マネジメント・広報」の3つの分科会に分かれ、16:00くらいから成果発表をしていただいて、適宜解散となります。入館手続きの都合上、10:45〜11:00の間にご来場ください。遅れてご来場の場合は入場までお時間をいただくことがございます。飲み物と茶菓子は準備いたしますが、昼食は各自でご準備ください。入館管理の都合上、可能なら昼食はご持参いただけますと幸いです。午後のセッションのどれに興味があるかをお申込みフォームでご指定ください。これはあくまでも事前の参考にするためで、当日話を聞いた上で変更されてもかまいません。当日の運営をお手伝いいただけるボランティアも募集しています。お願いできる方はお申込みフォームでお知らせください。19:54)ちいさなことでも何ができるか考えていきたいです。丸投げ状態の現状でこのようなお願いと告知をすることにかなり恐縮していましたが、こんなにも多くの方からの支援の表明をいただけて感謝しております。当日に向けて準備を進めます。何かあればコメントを頂けますと幸いです。23:26)定員待ちの補欠ですが、福岡から参加予定です。青空文庫は文化財保存だけではなく、読書好きな若年世代のボキャブラリー向上にも効果的です。熱いコメントありがとうございます(自分も福岡出身なので特に!)。リソースの問題があるのでどうなるかわかりませんが、せっかくの思いを無駄にしたくありませんので、出来る範囲で検討してみます。難しいかもしれません。そのときはどうかご了承ください。08:56)各種ニュースサイトでも話題になってるようで青空文庫への関心の高さがうかがえます。08:57)USTREAM中継可能でしょうか?機材は提供します。16:58)面白そうですね。参加させてくださいー。20:27)まだ、時間があるので、ネットでアイデアの交換をしませんか。どんな機能を望みますか。私は、グループで入力し、グループで校正する機能が欲しいと思います。1冊は、無理でも1章ならという人も参加できるようにということです。使えば、全員が同じソースを使えます。01:14)参加したいけど行けないことが発覚しているのでインフラ側のみコメント、エンジニアレスで演るのであればDRBDがいいと思うな。レプリケーション系の技術は制約条件を十分に満たす必要があるから。サーバ購入で設置するのであればリプレース費用との兼ね合いがあるから計算しなおしなきもするけど。DRBDはスケールしないので。利用できる開発リソースとコストの兼ね合いだと思います。ちなみにDRBDは作るのはめんどくさいものの戻すのも簡単、また、バックアップデータからの復元するならいいかなーと。12:54)エンジニアレスで面倒見るならフルマネージドサービスを利用するしか無いと思う。PostgreSQLのバージョンはどこかに示されているのでしょう過。どの程度の老朽化なのかを知る為にバージョンを知りたいのですが。青空文庫のDB機能について外側からわかること。作品の情報には作業状況や作品のページに含まれる底本情報、解説などが含まれる。作業者は数千人、著作権(作者)は千人程度、作品の情報が数十万件から百万件程度。DBMSを使わないと危険な大きさです。DBサーバがコンテンツを作成して、Webサーバに定期的に反映しています。入力者、校正者との受け渡しはメールベース。これはテキストデータの品質確認のため、不可欠でセルフアップデートは避けた方が良いと思います。入力の登録はDBか青空文庫のDB機能について外側からわかること。14:44)バージョンに関しては当日報告されると思いますが、2003年に立てているのでそのくらいのバージョンです。青空文庫のDB機能について外側からわかること。14:52)たぶん、システムを作られれる方なら作業管理システムを使うとシステムの概要は検討がつくと思います。シンプルなシステムです。現行は以下の機能があります。青空文庫のDB機能について外側からわかること。14:59)そして、考えておいてくださいね。・たぶん、青空文庫は今後とも専任のシステム管理者は置かない・持続可能なシステムが欲しい・共同作業のようなシステムは勝手連で、青空文庫の基本機能以外で構築して欲しい(やるのは自由:たぶん)・これから作るシステムもやはり活動の中心として全体のフローを司るものになりますが、なるべく基本機能に絞って欲しいなあ・青空文庫はサーバやコンテンツをおそらく抱え込みません。できるだけシステムはパブリックな空間に置いて、自然に更改されるような仕組みが欲しいかな青空文庫のDB機能について外側からわかること。15:02)でも、作業者のプライバシーは守りたい!青空文庫のDB機能について外側からわかること。15:15)極論を言うと、この5台のサーバが青空文庫の実体です。DBサーバは活動の全体のフローと情報を管理する中心。Webサーバが青空文庫の外側の顔になります。これからの青空文庫の活動はみなさんのアイデアにかかっていますよ!青空文庫のDB機能について外側からわかること。15:29)UIは今の常識で組んでも良いが、80歳のおじいいさん、おばあさんも作業するということを忘れないでね。青空文庫のDB機能について外側からわかること。ローリング・リリースなので、月に一度くらい再起動をかければ、ソフトは常に最新になります。60人のエンジニアがいるのですから、管理者を置いても良いのではないでしょうか。青空文庫のDB機能について外側からわかること。13:40)たぶん、当日出ると思いますが、新規性よりも安定性と継続性を考えてくださいね。今のシステムはバージョン塩漬けのまま、20年近く稼働している計算になります。今回の更改の必要性もハードウェアの寿命の問題です。何のためにOSを最新にするのか?まで考えるとよい提案ができると思います。それと、ボランタリーベースですから、今回集まった方が全てシステム管理グループになるとは思えません。よくて、ひとりから数人。普通は0人かもしれません。皆、生活がありますからね。縛ることはできませんよ。それが長く続く、ゆるーい青空文庫のDB機能について外側からわかること。17:11)データベースサーバの検討では、現行のシーケンス図があるといいかな?青空文庫の中でのデータのやり取りがわかるから。21:15)オープンソースのソフトについて言うと、より新しいバージョンは、より信頼性が高く、より安定性が高いと言えます。トラブルは、とっくにバグフィックスが出ているのに、それを無視して古いバージョンを使い続けたことに起因します。ソースが公開されていないものは、新しいものが良くトラブルを起こしますが。ボランタリーベースだからこそ、多くの人で負荷を軽くして、管理を行う方が良いでしょう。見つかり、パッチを緊急に当てるにしても、複数いれば、誰かが動けます。)合う→会う」みたいに訂正いれてもらって、一定ユーザーからの通報が溜まれば更新みたいな合議制も面白いですね。新しい技術はいいことです。20:34)あとマネージメントに関する提案です。現在、断捨離など海外で人気の作品も沢山あります。アニメやドラマなどの無断翻訳&配信などは、著作権の問題として取り上げられています。逆に拡散マネージメントとしてグローバル化することは非常に効果的です。海外における分散マネージメントにより、寄付や少額の商用利用料はユーザーの負担を最小限に出来ます。21:10)こんなページを見つけました。富田さんが作成されたようです。青空文庫データベースのダンプをdailyに提供するまさしく、私が欲しいものです。いうコマンドで作成が出来ます。21:53)元某ソシャゲPFのエンジニアで現フリーランスの者です。今回の募集で青空文庫の現状を初めて知りました。残念ながらイベントには人数制限で参加できないのではないかと思いますので、こちらでコメントします。"青空文庫の活動継続に対してエンジニアとしてコミットする"ことって個人的にはすごく魅力的なことだと思っていて、当イベントの参加希望者数を見てもそれは妥当なのではないかと思います。そこはもっと活かせるはず。00:17)みなさまコメントありがとうございます!これまでコメントできずに申し訳ありませんでした。サーバのバージョンなどは調べてあるのですが、そのあたりは当日まとめてご報告させていただこうと思います。19:15)アイデアソンに向けての個人的な情報整理です。http://www.xmind.net/m/3Z2L/認識違いもあるかもしれませんし、うかつに先走ってしまった感もありますが、参考までに公開します。21:40)いよいよですね。ような意見交換をする場があるといいですね。青空文庫と同じ程度の規模(9000冊のオーディオブックを作成しています。運用されているフォーラムが活動の中心です。良い方法だと私は思っています。数十人が管理者になって、運営しています。青空文庫のDB機能について外側からわかること。登録作業などの青空文庫の裏側の作業の効率化と整合性を保つ意味を持っています。入力作業の開始宣言から遅い人の場合には10年以上かかる場合があります。(私ですが)青空文庫のDB機能について外側からわかること。10:11)作業の進捗はそれぞれの人のペースがありますから、青空文庫はその間、「この作品は誰それが作業中」ということを覚えておく必要があります。江戸川乱歩のような著名作家の場合、複数の人が作業をしたいと立候補することもあります。した場合、重複入力を避けるために青空文庫の方で作業者をシリアライズする必要があります。多くの作業中のファイル(点検待ちや校正待ち、公開待ちなど)のファイルは状態とともに管理する必要もあります。した役割をデータベースと呼ばれるシステムが担っています。現状の作業量では青空文庫のDB機能について外側からわかること。10:12)さすがに、現状の作業量では人の管理する限界を超えていますから、現在、青空文庫が回っているのはデータベースがあるからと言えるかもしれません。青空文庫のDB機能について外側からわかること。10:17)大久保さんも述べていますが、入力や校正の作業をされている方のITスキルを考えるとphpBB3の利用は無理かな?インフラの構築管理で使うというのなら良さそうですけれども。青空文庫のDB機能について外側からわかること。10:22)事前の知識として、青空文庫のテキストが「入力作業開始の宣言」から「Webサイト(書架)への公開」までのライフサイクル(実際にはその後、メンテナンスサイクルもあるけれど)を示してあげるといいかもしれませんね。16:37)現状の入力システムを維持するのは、マスト要件として、更にプラスがあっても良いと思います。それは、重複入力を認めるということです。夏目漱石の「鉱夫」という作品があります。ちくま文庫を、底本として青空文庫に登録されています。これは岩波文庫のものとかなり違います。ちくま文庫のものは、章が分けてなく、岩波文庫は新聞連載時の章分けがされています。オーディオブックにするには、章分けされている方が読みやすいものです。岩波文庫を底本とするものも、登録されると良いなと思っています。青空文庫のDB機能について外側からわかること。18:06)現状でも底本違いは入力が認められていますよ。20:33)みなさまコメントありがとうございます!本業や明日の準備で忙しく細かなコメントを返せず申し訳ありません。みなさんからいただいたコメントは明日のアイデアソンに持って行き一つのアイデアとして検討させていただきます。「青空文庫のDB機能について外側からわかること。」さんのご懸念については青空文庫スタッフの方からも伺っており明日はその点などもご説明するつもりです。大久保さんも関西から来ていただきますし。ATNDのコメント欄はあまり議論に向いていませんね。20:41)そして明日のアイデアソンは前半のみですがニコニコ生放送で中継しようと思っています。お時間ある方はご覧ください。いった違いで登録されている例はあるのでしょうか。私は寡聞にして知りません。例を示して頂ければ幸いです。私は、底本が同じでも、どうしてもグループでなくて、個人でやりたいという場合は、入力を認めてもよいと思います。データベースの負担はそれほど多くありません。重複を認めていて、赤毛のアンのオーディオブックは、数種類存在します。青空文庫のDB機能について外側からわかること。09:38)土曜日は皆さん、ご苦労様でした。有意義な議論ができたようでなによりです。地震がありましたが無事に帰れましたでしょうか?底本違いについては、例えば、同じ仮名遣いであっても底本違いによる文章の違いがありますから青空文庫では認められています。入力マニュアルにあったと思いますが。蟹工船は現在、登録されているものと作業中のものがあるはず(片方は私が登録していますから)ですが、これは底本の版違いの問題で2種類作業がされているものです。青空文庫のDB機能について外側からわかること。09:38)逆に言うと、本の世界では、底本が違うと文章が違うケースは結構たくさんあります。このため、青空文庫のテキストの間違い指摘に関しては底本の確認が必須なのです。底本を確認されなかったり、違う底本を確認された指摘は中の人の作業量を大幅に奪う結果になります。これが修正受付システムが閉鎖された要因の一つです。青空文庫のDB機能について外側からわかること。青空文庫のDB機能について外側からわかること。09:52)また、佐左木俊郎の「三稜鏡」は本として未出版だったことから、私が初出の雑誌「新青年」から仮名遣いを変更しながら入力していましたが、その後、ちくま文庫に収蔵されたことからそちらを底本にされた方が作業を進められて、先にできあがったので、私の方は作業を取り下げています。大きな違いがないのなら、意地を張って底本違いで入力を続けるよりも別の作品にとりかかった方がボランティアの限られた作業量にとってはプラスになりますから。青空文庫のDB機能について外側からわかること。10:39)少し会の中で出た「校正管理システム」という言葉にミスリードされている気がします。あのサーバの目的は作業のワークフローの管理と青空文庫サイトのアップロードまでの自動化です。作品は入力依頼された時点で番号が付与され、これが公開まで維持され、最終的には図書カードの格納されるディレクトリ名称に反映される作りになっています。入力から追わないと機能の全容はわかりませんよ。青空文庫のDB機能について外側からわかること。10:42)それと、テキストファイルがいまだにシフトJISなのに留意して下さい。旧仮名の作品で顕著ですが、UTFでは字形を正しく表示できない漢字があります。旧字旧仮名を使う青空文庫特有の問題だと思いますが、JISの字形を入力、校正時に正しく表示できることが大前提となります。丸投げ状態の現状でこのようなお願いと告知をすることにかなり恐縮していましたが、こんなにも多くの方からの支援の表明をいただけて感謝しております。当日に向けて準備を進めます。何かあればコメントを頂けますと幸いです。介して送信する場合、伝送速度は確かにツールや周辺地域の影響を受けます。