読者です 読者をやめる 読者になる 読者になる

epubcheck-ruby

epubcheck-ruby | RubyGems.org | your community gem host

github.com

やはりないと厳しいので、作った。4.0.2対応。

開発者向けopenBD関連リンク集

公式

openBD | 書誌情報・書影を自由に

API仕様書 OpenBD 書誌APIデータ仕様 (v1)

2017/01/23 セミナー資料

GitHub Organization

github.com

https://github.com/OpenBD は別物なのに注意

ライブラリ・ツール・アプリ in GitHub

Go

github.com openBD APIライブラリ (Go)

github.com ISBNで書誌情報を取得するツール (Go)

JavaScript

github.com Chrome拡張

github.com 書誌情報表示サンプル (JavaScript)

github.com 新刊情報アプリ (JavaScript)

openBDの全データを整形しつつ単一ファイルにダウンロード · GitHub 全件取得スクリプト (JavaScript)

Ruby

Crawl all data using openBD API · GitHub 全件取得ダウンローダ (Ruby(Rails))

github.com openBD APIライブラリ (Ruby)

github.com openBD APIライブラリ (Ruby)

github.com openBDの登録データ取得 (Ruby)

Python

github.com 全件取得用ダウンローダ (Python)

PHP

github.com ISBNから書誌情報を表示するサンプル (PHP)

github.com 出版社記号を使って特定出版社の書籍データを抽出するサンプル (PHP)

hontoの書籍ページにISBNでリンクする

hontoの書籍ページは独自IDが振られているので、直接リンクできない。

例えば以下のようなURLになっている。

https://honto.jp/netstore/pd-book_28169493.html

これとは別に、ISBNを指定する方法がある。

http://honto.jp/redirect.html?bookno=(ISBN)という形だが、ここでのISBNは13桁ではなく、末尾のチェックデジットを落とした12桁になるのがポイント。

http://honto.jp/redirect.html?bookno= 9784822239176 ではダメ。

http://honto.jp/redirect.html?bookno= 978482223917 だとうまくいく(冒頭のURLにリダイレクトされる)。

もうちょっと何とかならなかったのか…という仕様としか言いようがない。

textlint-rule-preset-ja-technical-writingが厳しすぎるのではないか問題

というのを某所で見かけたので。

github.com

「このルールをエラーなしで通る文章の集合」よりも「特に問題なく読める技術文書」の方がだいぶ大きそうなので、一般的な技術文書のlintの雛形として導入するのは過検出が多発してたいへんとのこと。もうちょっとゆるいサブセットを作るべき?

一般的には外したいルールとしては、

  • 1文の長さは90文字以下とする
  • カンマは1文中に3つまで
  • 読点は1文中に3つまで
  • 連続できる最大の漢字長は5文字まで
  • 同じ助詞を連続して使用しない

辺りとかでしょうか。

あと、例えば『「ですます調」、「である調」を統一します』辺りは一般的には導入したいけど、引用が入るとどうにもならなくなるので、その辺りは簡単に対応できるようになると幸せになれそうです。つまり引用文は例外にするとか。

2017年のmd2reviewの開発目標

github.com

今年はとりあえず2.0をリリースしたいです。2.0での大きな変更点は2つです。

  1. Kramdownのサポート
  2. 1ファイルのFrontmatterつきMarkdownをRe:VIEWプロジェクトに変換する機能を追加

1については、Redcarpetよりは手軽にMarkdownの拡張に対応できるのでは…という期待があります。が、全てのオプションが同じように導入できないかもしれません。それもあってメジャーバージョンをあげます。 Kramdownに完全移行するか、Redcarpetとどちらを導入するかを設定で決められるようにするかは未定です。

2についてですが、JekyllやMiddlemanが対応しているやつですね。

jekyllrb.com

Middleman: Frontmatter

MarkdownからRe:VIEWへの変換で問題になるのは「Re:VIEW側のconfig.ymlをどう生成するか」なのですが、Frontmatterで対応できればこれでいけそうな気がします。

実際にはちょっとFrontmatterのparserを書きかけた程度なのですが、まずはエンジンの方を解決した方がよさそう…ということで後回しになっています。

個人のOSS開発は作者個人のメリットを最優先させるのがよさそう

chezou.hatenablog.com

読みました。私は英語でばんばんissueが飛んでくるようなプロダクトを作ってるわけではないので、実感としてはわからないところもあるのですが。

歌を作るたびに どこかで傷つく人がいる
誰かをほめることは 誰かを敵に回すこと
片桐麻美『つまらないものですが』より)

大原則として個人プロジェクトであれば、自分にとってのメリットを最優先するべきだと思います。 作ってる人が幸せになれないプロダクトは使ってる人も幸せにならない、少なくとも一時的には幸せであってもその幸せは持続可能な形にならないのでは、という気持ちがあります。

自身の意に反して、人生を削ってまで生み出す価値のあるプロダクトなんてこの世にありはしない、というのが私の信念なので。事実でも真実でもないかもしれませんが。

その前提をおいた上で、でも、プロダクトを世の中に送り出してしまうということは、それを使ったり使わなかったりする他の人々を巻き込んで不幸にしてしまう可能性があります。それはもちろん知ったことではないと言うか、そこは責任の範疇とするべきではないと思うべきだと思っているのですが、そう割り切れないことはあって。そういう時はつらいですよね。

よくある作戦としては、手伝ってくれるメンテナを見つけて(趣味的なものではあっても)複数人体制にしてみる等がありますが、そうすると今度は開発チームをメンテナンスするコストが発生したりするので、根本的には解決してないような疑念もあります。もうちょっと強行的な策としては、issueを閉じて質問についてはStack Overflow等に振ることにして、pull requestのみを受け付ける作戦もあるそうですが、そうすると変なPRが飛んでくるのは容易に想像できますし。うーむ。困ったものですね。

また、chezouさんの認識とは異なるかもしれませんが、多くの人に使われてすごいissueやPRがばんばん飛んでくるのをびしばしさばくのが理想的なOSSプロダクト開発であって、そうしないと承認要求を満たせない、みたいに思われがちなのかもしれません。それはそれで理想形の一つではありますが、そういう形にみんなが固執してしまうようになるのはいろんな意味で健全ではないんじゃないかなと思うわけです。別にユーザを減らすべきとは思いませんが、プロダクトやその開発プロセスにはさまざまな理想形があるべきで、どんな形を選ぶのかは作者次第であって、根本的には作者がうれしいプロダクト開発の形を選ぶことがそのプロダクトの理想形であるべきだと信じています。

……なんかいろいろ書いたけどタイトル以上の内容がなさそう。でもやっぱりその一言に尽きるし、それでもいろいろ言ってくる人への回答としては「言い出しっぺの法則ってご存知ですか?」に尽きるんですよね……。

他人の人生を巻き込んで 私は歌を作り続ける
本当につまらないわたしだけど
いま 好きな人がいます
(同)

エコシステムの適切なサイズとコンパクト化

去年の終わり頃に気になる記事がいくつかありました。

qiita.com

qiita.com

tk0miya.hatenablog.com

去年の12月に行われたYAPC::Hokkaido 2016 SAPPOROでのsyohexによる発表資料も、同じようなテーマとして気になりました。

speakerdeck.com

実際のところそれぞれのプロジェクトがどうなのかはよく知らないので深くは触れられませんが、一般論としては気になっているのは、最近のOSSプロダクトは特定プロダクトが1個だけで独立しているわけではなく、その周囲に複数のサブプロジェクトなりエコシステムが作られやすいという点です。それはモジュールであったりプラグインであったりパッケージであったり、テーマのようなものも含まれるかもしれません。

そのような、サブプロジェクトによる大きなエコシステムを作っていく流れは、規模が大きくなっていく過程では非常に有益です。メインプロダクトの作者が面倒を見られる大きさには限界があり、そのようなコントロールを積極的に行わなくても自律的に動くサブプロジェクトとして機能拡張ができる、ということは、そのプロダクトの開発者・利用者両方にとってメリットになります。

ですが、いったん活発に拡大していく時期が過ぎ去り、プロダクトの発展が停滞し始めてしまうと、メリットであったはずのものがそのままデメリットとして機能してしまうおそれがあります。そもそも作者がコントロールしなくて済むはずのものだったのに、いったんサブプロジェクトを利用するものが増えてしまうと、誰かが責任を持ってコントロールしなければいけなくなってしまう。下手に放置すると、そこに依存するいろんなものが壊れ始めてしまう。その流れに抗うべくいくつかのサブプロジェクトに手を差し伸べた人も、気をつけないと消耗してしまい、無理に手を出さなければ保守できたはずだったものまで巻き込んで放棄せざるを状態になってしまうのは不幸なことです。そしてある程度以上壊れてしまうと、部分的にではあれ、一気に衰退に向かってしまう危険性もあります。

そもそもの問題として、ボランタリーなエコシステムが拡大を続けることを期待することは危険すぎます。拡大とは言わずとも、一定規模を長期間に渡って維持し続けることすら簡単ではないでしょう。ある程度以上大きくなったプロジェクトの場合、どこかの時点で「撤退戦」のようなことを避けることは難しいのかもしれません。

そのような持続可能なプロジェクトを目指すことは、都市計画における「コンパクトシティ」に似ているような気もします。一方、コンパクトシティの実現については、さまざまな困難が語られます。

www.nhk.or.jp

news.yahoo.co.jp

都市計画とOSSプロジェクトでは、共通要素よりは相違点が多そうですが、「多くの人々により自由に拡大されてきたものを人為的な制限により縮小させる」ことの難しさという意味では似ているところがありそうです。とはいえOSSについても、現状維持にコストがかかり、そのコストを負担する人が減少してきた場合、何かしらの方策で規模の縮小を迫られることになるのではないでしょうか。

新年早々縁起の良い話ではないですし、具体的な対応策はないのですが、あるいはこういうタイミングだからこそ考える時間を取れるということもあるので、改めて書いておきます。