だけどこんなところで待っているよりは

書き忘れ防止用。タイトルは飽きたら変える予定です。

スクーでRailsの入門を実演します & 前回の授業での質問へのお返事

もはや今日になってしまいましたが、前回に続いてスクーでRailsの実演をします。

Ruby入門 - Webアプリケーションの制作プロセス【前半】 高橋 征義 先生 - 無料動画学習｜schoo（スクー）

Ruby入門 - Webアプリケーションの制作プロセス【後半】 高橋 征義 先生 - 無料動画学習｜schoo（スクー）

というか前回の授業ではだいぶハードルが高かったようで、難しすぎた人には大変申し訳なかったです…が、質問がたくさんいただけたので、それに答えられたところは良かったかもです。

ちなみに今回はNitrous.IOを使う予定です（が、どうもRailsを動かすとまめにkillされる場合があるので、もしかしたら違う環境にするかも）。 オンラインの授業でハンズオン形式だと辛いらしいので、一人でちゃかちゃか進めるスタイルになる予定ですが、興味のあるひとは触っておくと良いかもです。

Nitrous

さて、前回の授業の質問について、答えられなかったものも含めて回答をこちらに書いておきます。

槇村 浩司さん： 「メタプログラミングはどんな時に使うのですか？」

桐山 洋平さん： 「「メタプログラミング」についてもっと詳しく聞きたいです！メタプログラミングができるとどんな良いことがあるのでしょうか？」

や、入門者向けにメタプログラミングについて説明したのは失敗だったかなあ…と思わなくもないのですが。 Railsでは「Don't Repeat Yourself」(DRY)という原則があって、 が、これを実現するには「あらかじめ書かれてないメソッドをプログラムの実行中に定義してそれを実行する」、といったことを行うのですね。

池田 順一さん： 「Webを作るといえばHTMLやjavascriptを思い浮かべますが、それらを使わずにRubyだけでサイトを作れるということですか？」

そうではなくて、HTMLだけでは JavaScriptだけではクライアントサイド（要するにブラウザ上）で動く部分しか 書けません。

そこで、決められたHTMLではなく都度都度HTMLやJavaScriptを生成したり、 JavaScriptと通信して結果を返したりする、といった機能をRubyで記述するのでした。

菅沼 慎平さん： 「RubyでどんなWebアプリケーションができるのか？具体的に知りたいです(SNS承認等）」

SNSとかであればRubyでいろいろ書けますね。

いわゆる最近のリアルタイムウェブみたいなものはちょっと辛いところがあるかもですが、 そういったもののサーバサイドをRubyで書く場合もあるそうですし、 クライアントサイドもRubyで書く（それをJSに変換する）という場合もあるそうです。すごい。

豊田 昌代さん： 「最初の最初の一歩、って何をすればいいんでしょう？プログラミング未経験ですが。」

とりあえずコマンドラインの画面（いわゆる「黒い画面」というやつですね）から、Rubyが動くかどうかを試してみます。

例えば、OS Xならターミナルを開いて、

ruby -v

と入力して、

$ ruby -v
ruby 2.1.2p95 (2014-05-08 revision 45877) [x86_64-darwin13.0]

みたいな出力が返ってくることを確認します。返ってくるなら、

ruby -e 'p "hello, world"'

と入力すると、

"hello, world"

と出力されれば、Rubyのpメソッドの実行に成功したことになります。

この辺は次回の授業でも実演してみます。

Hisashi Takagiさん： 「海外では日本に比べてRubyがとても人気があるようですが今後、日本でRubyが流行っていくでしょうか？」

日本でもまあ流行ってはいるような気がしますが、それなりに温度差はあるのかもしれません。

そもそも新しい言語やフレームワークを積極的に取り入れていくかどうか、というところで、日本では消極的になる企業が多いのかもしれません。どうなんでしょうね。

Yoshi Sakuさん： 「Rubyで何を開発するのが一番よいですか？」

Rubyそのものは「汎用プログラミング言語」とも言われる、何か特定の目的のための言語ではなく、 いろんな目的のために

というわけで何を開発してもいいのですが、いわゆるWeb2.0以降のWebサーバサイド開発では Railsが流行ってるので、 Webアプリを開発するために使われることが多いです。

槇村 浩司さん： 「Rubyのどんなところが楽しいのですか？」

伊藤 茂さん： 「Rubyを書いていて、一番楽しい瞬間はどこですか？　教えてください！」

Ruby界隈では「オレってばスゲー感」という謎の表現が広まったことがありました。これは、自分の実力以上に、書きたいことがさくっと書ける、といったようなときに使われていました。 これも「たのしい瞬間」の一つですよね。

Fukui Mionaさん： 「Ruby on Rails には link_to などのHTMLタグを生成するヘルパーがありますが、HTMLタグとどう使い分ければいいでしょうか。」

プログラム側で生成する場合は、特に問題ない場合はHTMLタグヘルパーを使った方がいいかもしれません。が、タグヘルパーでは難しそうな場合はタグを生成してもいいでしょう。

ただし、一般に公開されるWebサイトでHTMLを生成する場合は、XSSなどのセキュリティに気をつけてください。

名坂 さおりさん： 「どのWEBサービスがどの言語で開発されているかというのはどうやったらわかるのですか？（どこをみればわかりますか？）」

授業でも答えましたが、これは「分からない場合も多い」というのが答えですね……。WebサーバならHTTPのレスポンスでサーバアプリケーション名を答えてくれる場合もありますが（もちろん情報がなかったり、偽の情報を返すこともできますが）、Webアプリケーションフレームワークにはそういうことはありません。中の人に答えてもらうしかありません。

福間 正人さん： 「Rubyが導入済みのレンタルサーバーってあるのですか？」

最近のLinuxディストリビューションではRubyが標準で用意されている場合が多いので、シェルが使える環境であれば導入済みの場合も多いでしょうね。

とはいえ、Railsを動かそうとなると、単にCGIやApacheモジュール的な物を動かすのとはわけが違うので、Railsに対応したいわゆるPaaS的なサービスを利用した方がいいかもしれません。こちらはHerokuやEngine Yard、MOGOK、C4SAやSqaleなどがあります。 それぞれ検索で探してみてください。

菅沼 慎平さん： 「RailsはPHPでいうCakePHPみたいな人気?のフレームワークなんですか？」

授業でも答えましたが、CakePHPはRailsよりは後発のフレームワークであり、開発初期にRailsの影響を受けています。ただ、CakeもRailsもそれぞれ独自に進化しているので、最近のバージョンだと違いも大きいかも。とはいえ、まあどちらも似たフレームワークですし、どちらも人気があります。

ただ、PHPの場合はCakePHP以外にも人気のあるフレームワークがありますが、Rubyの場合は圧倒的にRailsの人気が高い、という点はちょっと違います。

摩文仁 和博さん： 「Azureとかでも、できるのかな？」

Azureでももちろんできます。Windows環境ならartonさんのNougakuDo(http://msdn.microsoft.com/ja-jp/windowsazure/hh531535 )を使うという技もありましたが、今ならAzure環境でのLinuxを使った方が早いかもしれません。

赤星 亮太さん： 「クックパッドがRubyでできているということですが、htmlなどの他の言語でできないことをRubyで行っているということでしょうか?」

さっきの池田さんの質問と同じような回答になりますが、「HTMLを動的に生成にするためにRubyを使っている」と考えるといいかもしれません。

というか、cookpad.comくらいの規模になると、ふつうにユーザに見える部分以外にも様々なプログラムが必要になってきます（推測ですが）。そういったもろもろの中心部分がRubyで作られている、という感じです。

福間 正人さん： 「WEB構築で、PHPやJAVA、Rubyをそれぞれ使い分ける理由ってなんですか？」

細かいことを言うといろいろな違いがあるのですが、開発する人やチームの慣れや、開発・運用する環境の制約による場合もあります。選べる状況なら何を選んでも（多くの場合は）あまり大差ないかもです。

一方で、規模が大きくなったり、速度が重要になってきたりすると、Ruby以外の言語を使った方がいいこともあります。

豊田 昌代さん： 「ひとつのWebサイトを複数の言語をつかって開発することもあるんですか？？」

授業でも答えた通り、いろいろあります。もちろんひとつの言語でできた方がよいこともありますが、むしろ（ライブラリ群やコミュニティも含めた）言語には向き不向きがあるので、それに応じて部分々々を異なる言語で書き分けた方がよい、という考え方です。

もちろん、そうであっても同一言語に揃えた方がよい、という考え方もあって、 その場合は向き不向きがあっても技術や根性やお金で何とかします。

Kodama Hitoshi： 「Rubyってまだまだ需要はあると思われますか？」

こちらは授業でも答えましたが、それはさておき、「誰の」「どういった」需要があるのか、ということはありますね。Ruby以外の新しい言語も生まれたりしていますが、Rubyで新しいプログラムが作られなくなることは当分ないでしょうし、何かしら便利なものをRubyで書きたいという人がいる限り、Rubyが求められなくなることはありません。

とりあえずRubyのお仕事は国内外にいろいろあるかと思います。

花岡 龍さん： 「Rubyのコミッタになるにはどんなスキルが必要ですか？」

お、頼もしい質問ですね。 CRuby(MRI)のコミッタになるならCの、JRubyのコミッタになるならJavaのスキルが必要です。むしろRubyのスキルはそれほど高くなくてもいいかもしれません。また、CRubyであれば、Rubyの標準ライブラリをメンテナンスするコミッタになる場合もあるので、その場合ならRubyのスキルだけでも十分です。

要はRuby処理系に新しい機能を付け加えることができればいいわけで、その「新しい機能」に関して詳しいことが大切です。

あと、コミッタに求められるものは「継続性」です。一瞬超頑張ってコミッタになっても続かないとあまり意味がありません（別にコミッタにならずともRubyの開発に参加することはできます）。それも大事な「スキル」だと思います。

田端 亮さん： 「何が出来るようになったらRubyが使えるようになった、と言っていいでしょうか？」

これは分野にもよりますね。例えばまつもと ゆきひろさんに、「Rubyでスクーみたいなサイトを作れますか？」と聞いたら、たぶん「今の私には作れません」と言われるような気がします（まつもとさんが本気出してしばらく勉強すれば作れるようになるとは思いますが、そういう状況になることはちょっと想像つきません）。

何か作りたいと思うことがあった時に、Rubyで簡単に作れそうかどうか、そして簡単に作れそうなら実際に自分で作れるかどうか、といったことが判断できるようになったら、 その人にとって「Rubyが（そこそこ）使えるようになった」と言ってもいいのかもしれません。

槇村 浩司さん： 「どんな準備をしたらいいですか？」

や、ほんとに直前になってすみませんが、 とりあえずNitrous.IOを使う予定なので、Nitrous.IOのアカウントを作って、使い方を調べておくとよいかもです。

あと、Rubyの基本については、 「プログラミング入門　- Rubyを使って -」(http://www.ie.u-ryukyu.ac.jp/~kono/software/s04/tutorial/) が世界的に有名な入門ガイドですね。

Ruby以外の言語を使ったことのあるひとは、 「Ruby基礎文法最速マスター」(http://route477.net/d/?date=20100125) がよいかも。

が、今回は雰囲気優先なんで、あんまり前提知識がなくてもそれなりに伝わると……いいなあ。

スクーでRuby入門の話をします

もう明日なんですが、改めて告知をば。

Ruby入門 - プログラミング言語Rubyの概要と出来ること 高橋 征義 先生 - 無料動画学習｜schoo（スクー）

改めていちからRubyのことを話すのはすごく久しぶりな気がします。基本的にはWebアプリ開発に入門したい非プログラマ向けではあるのですが、「Rails入門」ではなく「Ruby入門」なので、RailsよりもRubyに寄せたお話になる予定です。

とはいえ、先週末までRubyConf 2014でうちの奥さんがEclipse向けmruby debuggerを作ったという発表のお手伝いをしていたので（サンディエゴは楽しかったです。2005年の時はほぼホテルと空港の往復でまともに観光しなかったのですが、今回はあちこち行ってきました）もう少し準備しないと…。

非プログラマ向けなのではありますが、興味のある方はぜひどうぞ。

ついでに、Ruby歴史家向けの小ネタですがRubyのホームページのURLの変遷を調べてみました。当然ながら最後以外はリンク切れしてます。

最初のサイトは間借りで、その後でまつもとさんの職場に置かれたそうです（回線が遅かったためらしい）。97年の変更は転職のせいですね。 99年は2度目のメジャーデビューみたいな年で、この年に最初の書籍が出たのと合わさって、改めてRubyが世に知られるようになったのでした（最初のデビューはfj.sourcesに投稿した95年、3度目の世界デビューはPragProg本が出てRubyConfが開催された2001年というRuby史観）。

WEB+DB PRESS Vol.83でMarkdownについての記事を書きました

今週発売予定のWEB+DB PRESSに、「もっと知りたい! Markdown　ついに標準化が始まった軽量記法」という原稿を書きました。WEB+DB PRESSに書くのは久しぶりです。

WEB+DB PRESS Vol.83

WEB+DB PRESS Vol.83

記事のタイトルと内容ですが、当初はMarkdownを使ってると何より気になるMarkdownの方言について、その現状と対策みたいなことを書こうとしたのでした。が、今回担当していただいた稲尾さんと相談しいろいろ書いてみて、そしていったん草稿がまとまった 後で Standard Markdown騒動が勃発してしまったため、全体を見直しつつ前後にその辺の事情を追加し、標準化話っぽくまとめてみました。まさか書き終えたタイミングでこんなちゃぶ台返しみたいな事件が起こるとは…という気分でしたが、タイミングとしてはちょうど良かったと言えるかも。

個人的にはMarkdownの差異についてはCommonMarkを中心にまとまってほしいと思っているので、CommonMarkには好意的な書き方になっています。人によっては、CommonMarkはMarkdownの新しい方言を付け加えてより混乱させるだけで「標準化」でもなんでもないしどうなのよ、という意見の人もいるでしょう。とはいえ、例えば本記事でも紹介しているJSのMarkdownエンジンであるMarkedの作者が「Markdown is broken」(https://github.com/chjj/marked/blob/master/doc/broken.md)みたいな、ついカッとなってMarkdownエンジンの不満をぶちまけたりしている文章を読んだりすると、たとえJohn Gruberにはやる気がないにしても、第三者の勝手案であれ標準案をまとめることの意義は大きいんではないかと思っています。もちろんその場合はMarkdownという名前を使うのはよろしくないので、現状のCommonMark案も落とし所としては悪くはないんでないかなあ、というスタンスです。

執筆は、最初は（当然ながら）Re:VIEWで書いて入稿用Markdownに変換していたのですが、最終的には直接Markdownを編集する方向に切り替えています。これは、「Markdownの記法についての説明をMarkdownで書く」だけでもエスケープ等で混乱しやすい上に、「Markdownの記法についての説明をMarkdownで書かれた原稿をRe:VIEWから生成する」という時点でMarkdownのエスケープとRe:VIEWのエスケープが混沌を極めたためです。軽量マークアップ言語はその辺りのケアが弱いものが多いので辛いですよね…。

また、執筆にあたっては、id:lost_and_foundさんとid:uasiさんに草稿を読んでいただき、ご指摘をいただきました。この場を借りてお礼申し上げます。しかし二人に読んでもらった原稿はまだCommonMark話が入る前の段階だったので、あれからずいぶんと変わってしまったのでした…すみません。もちろん、誤り等があれば全て私の責任です。

とりあえず、Pandocでフィルタを書く話や、PandocのWriterがLuaで書ける話とかは今まで紙媒体では紹介されてないと思うので、それが書けたのは良かったです（後者は誌面の都合でだいぶ削れてしまいましたが…）。あと、でんでんマークダウンの記法について紙の書籍（ムックですが）で触れておきたかったというのもあります。JSではひそかにvue.jsを使ってみましたが、これは良いものですね。

最後に、原稿ではURLを脚注の形でばんばん書いてみており、編集時のどこかの段階で整理されるかなあと思っていたら最後までだいぶ残っていたので、クリックできない紙の代わりにURLのリストをこちらに転記しておきます。どうぞご利用ください。

電子書籍とDRMとコピーについての整理

メモ。

電子書籍はデジタルデータを有償または無償で配布（頒布、販売）しているものと考えられる。

電子書籍はデジタルデータの形でも著作物である（著作権法第2条第1項第1号、第6条、第10条）。なお、プログラムの著作物となっている電子書籍の話はここでは触れない。

著作物は私的使用のための複製が許されている（同第30条）。

そのため、（後述する例外に該当しない限り）購入者が自由に複製することが許されている。

ただし私的使用のための複製には例外がある。

第三十条 　著作権の目的となつている著作物（以下この款において単に「著作物」という。）は、個人的に又は家庭内その他これに準ずる限られた範囲内において使用すること（以下「私的使用」という。）を目的とするときは、次に掲げる場合を除き、その使用する者が複製することができる。

一 　公衆の使用に供することを目的として設置されている自動複製機器（複製の機能を有し、これに関する装置の全部又は主要な部分が自動化されている機器をいう。）を用いて複製する場合

二 　技術的保護手段の回避（第二条第一項第二十号に規定する信号の除去若しくは改変（記録又は送信の方式の変換に伴う技術的な制約による除去又は改変を除く。）を行うこと又は同号に規定する特定の変換を必要とするよう変換された著作物、実演、レコード若しくは放送若しくは有線放送に係る音若しくは影像の復元（著作権等を有する者の意思に基づいて行われるものを除く。）を行うことにより、当該技術的保護手段によつて防止される行為を可能とし、又は当該技術的保護手段によつて抑止される行為の結果に障害を生じないようにすることをいう。第百二十条の二第一号及び第二号において同じ。）により可能となり、又はその結果に障害が生じないようになつた複製を、その事実を知りながら行う場合

三 　著作権を侵害する自動公衆送信（国外で行われる自動公衆送信であつて、国内で行われたとしたならば著作権の侵害となるべきものを含む。）を受信して行うデジタル方式の録音又は録画を、その事実を知りながら行う場合

２ 　私的使用を目的として、デジタル方式の録音又は録画の機能を有する機器（放送の業務のための特別の性能その他の私的使用に通常供されない特別の性能を有するもの及び録音機能付きの電話機その他の本来の機能に附属する機能として録音又は録画の機能を有するものを除く。）であつて政令で定めるものにより、当該機器によるデジタル方式の録音又は録画の用に供される記録媒体であつて政令で定めるものに録音又は録画を行う者は、相当な額の補償金を著作権者に支払わなければならない。

この例外により、電子書籍にDRMがかかっているものをコピーする場合、すなわち「技術的保護手段の回避」に該当する場合、「私的使用のため」であっても複製できない。

逆に、DRM＝「技術的保護手段」がなされていない場合、「私的使用のため」であればコピー可能となる。

上記に加えて、公衆送信の話が出てくるけどそれはまた別途。

書店別コンピュータ書売上冊数推移(2008〜2013)

毎年恒例のコンピュータ出版販売研究機構「コンピュータ書籍 書店別 売上ランキング」（2013年度）が公開されてました。

今年も1位はジュンク堂書店池袋本店でした。おめでとうございます！

気になったので過去分も合わせてグラフにしてみました。

f:id:takahashim:20140715225407p:plain

https://docs.google.com/spreadsheets/d/12BY8ka6frA3Qj07oxme59-zdRMJ4kKSq6rqp8swTQdE/edit?usp=sharing

2013年の上位11店に加えてジュンク堂書店新宿店をプロットしてます。2008年と2009年についてはベスト200のデータが見つからなかったので当時ベスト10に入っていなかったものはデータが抜けてたりします（ブックファースト新宿店とか）。

予想通りとはいえ、全体的に徐々に下がりつつあって残念な感じですが、増えてるところも若干ありそう。紀伊國屋書店新宿本店が2012年から伸びているのはジュンク堂の新宿店がこの年になくなってビックロになった影響もありそうですよね……。

これからどうなるんでしょうか。

電書幼年期の終り、あるいは電子書籍元年とは何だったのか

東京国際ブックフェア・電子出版EXPOとその某裏企画みたいなものに参加してきました。

最近の電子書籍を取り巻く環境を思いつつ、電子出版EXPOの会場の光景を眺めていると、「電子書籍の黎明期が終わった」、という少しばかり感慨深い思いがありました。

  • トッパンやDNP、あるいは楽天Koboといった電子出版の大きなプレイヤーが電子出版EXPOにではなく東京国際ブックフェアに出展していた。「電子で読みたい人向け」ではなく「一般読者向け」の中に組み入れられていた（まあ単に土曜日にも出したかっただけかもですが）。
  • そのせいもあってか、電子出版EXPOが小さくなっていた。「ボイジャーの一人勝ち」という声もありましたが、確かに一人気を吐いて様々なイベントをやりつつ、Romancerという（ある意味でエキスパンドブックやT-Timeの初心に返ったかのような）プラットフォームを引っさげていたのは例外的で、あとはあまり去年と大きく変わってはいない、よくも悪くも「地に足の着いた」展示が多かった（メディアドゥは目立っていたけどそれはOverDriveとScribdの海外サービス輸入業のせいで、これからどうなるかは未知数だったし）。
  • これは電子出版EXPOとは直接関係ないかもしれないけれど、数年前に会社を作ったりサービスを立ち上げたりしたものがこういうところに現れたりすることはついぞなかった。それ以前の問題として、そもそもサービスが終了していたり、会社自体がなくなっていたりしたのも少なくない。

そのような電子出版EXPOを見たり、某裏企画に参加したりしながら考えていたことは、「電子書籍元年」とは何だったのか、ということです。

2014年のこの時点から振り返ってみると、「電子書籍元年」というキャッチーな言葉は、結局のところ何か得体の知れない、よく分からないものとしての「電子書籍」に対する過大評価と過小評価のブレの産物だった、と言えるでしょう。紙の本がなくなるのか、あるいはケータイコミック＋α程度の影響力で終わるのか。そして書籍を読む、書籍を作る、書籍を売るというビジネスと文化の形が大きく変わってしまうのか、それともそうでもないのか。その変化の帰趨の予測には幅があり、過度の期待と幻滅の間のどこかに現実的な未来があるはずだとはいえ、果たしてどこに着地することになるのか。その将来を予期することが困難だったため、余計に幻想が広がってしまったことが、ある種の「ブーム」を引き起こしてしまった。それが「電子書籍元年」を取り巻く状況だったように思います。

そしてなぜそれが「元年」と呼ばれていたのかというと、それが将来的には革命的な変化につながるはずの「始まり」であるのではないか、いや、始まりであって欲しい、という期待と願望が込められていたからだったのではないでしょうか。

しかしながら、「元年」と呼ぶに足るほどの革命的な変化のきっかけはあったのか？　と尋ねられたならば、「そうでもないかも」と答えたくなってしまいます。どちらかというとRevolutionというよりもEvolutionと呼ぶ方が適切でしょう。確かに変わりつつはありますし、その変化の中には重要なものも含まれていると思われますが、今のところはまだ見慣れた世界の延長線上にあるように感じます。そして、「元年」と呼びたくなるような年があったのかどうかも、よく分からないところです（具体的な数値を補足しておくと、元年と言われ始めた2010年の電子書籍市場規模が約650億円、2013年が約936億円で、3年たっても約1.5倍にもなっていない程度です）。

ネットバブルと元年ブーム

私自身は、1990年代後半からずっとインターネット・Webを趣味でも仕事でも関わっていたので、物事を考えるときの基準がネットになっています。そんな私が今の電子書籍の状況に触れながら思い出すのは、ネット業界の90年代半ばから90年代の終わり頃までの時期です。このあたりが、電子書籍と同様の「よく分からないものに対する過大評価と過小評価」が入り乱れていた時期でありました。俗にいうインターネットバブル(ドットコムバブル)、ITバブルです。これが弾けるのが2000年から2001年ごろで、その後しばらくは「ネットは面白いけど金（ビジネス）にならないおもちゃ」的な評価になっていました。

今の電子書籍界隈の雰囲気も、このバブル直後のネットに通じるところがあります。ネットに比べると、電子書籍の方はブーム・バブル後のダメージがあまり大きくはないように見えますが、それはネットほど大きくバブルが膨らまなかったせいというのもあるでしょう。まあ、それ自体は悪いことではありません。

もちろん、当時のネットと同様、電子書籍も（大きな利益は生んでいないとしても）それなりに成長し、それなりに仕事も回るようにはなっています。元年があったかどうかはさておき、電子書籍の時代そのものは始まっています。

ネットの方も、バブルがはじけた後にブログのムーブメントが起こり、そこからソーシャルの動きが始まり、今の勢いにつながっています。そこで鍵となったのは、ネットならではのコンテンツ、エコシステムでした。結局のところ、ネットバブルの時期のネットは紙やTV、ラジオの代替物（にあんまりなりきれてない劣化版）でしかなかったのに対し、そこから速報性・携帯性・接続性などなどの独自の価値を見出し、その価値にフォーカスした新しいツールとユーザが揃った辺りから、本格的なネットの時代がやってきたのでした。電子書籍の方も、その独自のコンテンツと価値が見出され（あるいは見直され）、その本格的な普及期が訪れるのはこれからなのではないでしょうか。

これからの電子書籍の新たな動きに期待しつつ、そこに私自身も関わっていければ、と思っています。

ブログタイトルについて

現在のタイトル、「だけどこんなところで待っているよりは」は、篠原美也子の歌からとってます。

「思っているよりもずっとずっと人生は短い」と同様、『秒針のビート』という曲です。


篠原美也子 - 秒針のビート (live on music da Leda, 2013.12.12)

選ぼうとしなければもっとずっと人生はたやすい
望んだりしなければきっとずっと人生は優しい
思っているよりもずっとずっと人生は短い
遅すぎるかもしれない　だけど顔をあげて
　
誇り高くありたいと願えば日々はあまりに切ない
勝ち負けで決まるならきっとずっと人生はたやすい
動機を見失ったまま過ごす日々はなんて儚い
遅すぎるかもしれない
だけどこんなところで待っているよりは
（篠原美也子『秒針のビート』より）

今年は美也子さん20周年でめでたい年でした。メジャーデビュー1枚目からずっと聞いている者としては、今も、今でも歌い続けてくれるのは大変心強いです。

遅すぎるかもしれない。だけどこんなところで待っているよりは。