単なるメモ。
Decoupled CMSの世界ではそれぞれ別々に道具を選べる
Jekyllの外の世界からdataを作る準備 - あーありがち(2018-12-09) で書いたような仕組みさえできてしまえば、逆にユーザー向けの HTML の生成が Jekyll でなければならないということもなく、バックエンドの CMS もユーザー向けの HTML を生成するジェネレータも要件に合わせて選択し直せばよい。もはや我々は
- CMS 上での作業者の作業しやすさ
- コンテンツを提供する仕組み
- コンテンツを通じたユーザー、ビジネスへの価値提供
- ユーザーの体験からどんなデータを得たいか（ビジネス価値など）
などを独立して考えることができる。
「○○だからこれができません」も「○○でないと作業担当が困ります」もない世界へ。上に挙げた要件がそれぞれ明確であれば CMS が一体ですべてを担う必要はない。これぞ Decoupled CMS のメリット。
それぞれの道具がマッチするかどうかをどう判断するのか
これらの要件を明らかにするためには一体のアリモノ（Coupled CMS）でまず始めてみて、ここがこうなっていた方がよい、いやこのままでよいといった学習が大事なんだけど、ここの線引きができるかどうかが実際にはかなり難しいと思う。
技術的には Decoupled CMS はそこまで難しい話ではない。しかし「『目先の道具が使いにくい』という視点から離れられるかどうか」は難しい問題だ。それぞれの価値を定義し、それを共有できて始めて分離後の姿を考える話に進むことができる。1
例えば Prismic.io は "Headless API CMS for both developers and marketers" と謳っている。
Headless API CMS for both developers and marketers - Prismic
マーケターにとって大事なのは細かいデザインの調整ではなく、商品価値が潜在ユーザーに伝わり、それが顧客へコンバージョンされることであり、そのために役に立たないことが CMS で実現されていても別に嬉しくもなんともない。逆にいろんな SNS と手軽に連携するための何かは即時機能追加されてほしいところだろう。
これは「マーケター」という言葉があるから考えやすくなっているのであって、恐らく同様の定義が個々の Decoupled CMS 案件であるべきなのだろう。
- コンテンツを publish する主体者は誰なのか？
- その目的はなんなのか？
- 提供する価値は何か？
- 何が成果なのか？
という話があって初めてそれぞれの道具が果たすべき役割を明確にできる。何のことはない普通の開発の話っちゃ話なんだろうけど、CMS とコンテンツということになると、その目的はそんなにきれいに整理されていないことが多そうだ。
例えば publish する主体が仮に「ライター」と定義されてしまった場合はどうだろう？ 途端に要件がボヤけてしまったはずだ。では「SEOライター」ではどうだろうか？ こうなると例えば検索エンジンのアドバイス（人気の検索ワードとか）にしたがってコンテンツをリアルタイムに採点するような仕組みがあると作業が早くなるはずだ。2
もちろんエンジニアが試してみるだけなら面白ければおっけー
いろいろ書いたけど、エンジニア一人がエンジニア一人のために分離するのはそんなに難しい話はないので、なんでもやってみるのがよさそう！（時間があれば）
ここ何年かずっと Web のフロントエンドの人にももっと Web サーバが手軽に使えるといろいろ捗るんじゃないかと思っている。なのでその紹介。
なお、分かっている人は読む必要ないし、とても冗長な記述になっています。
で、その前に、
kanazawa.js v1.6.5 に行きます
kanazawa.js v1.6.5 - もくもく会とたまにLT - : ATND
12/17(土) ITビジネスプラザ武蔵でボクと握手！
スケジュールに入ってないけど、このネタでデモります！ デモらせろ！
なぜ Web サーバか
- いちいちサーバにアップしなくても手元で本番と同じパスでアクセスできる1
- <a href="./index.html" とか書かなくても <a href="./" でよい2
- ついでに LL で開発もできちゃうかも
Webサーバの選択肢
- Apache, nginx など本格的なもの
- 主に個人向けなシンプルで軽量なもの
- LLで書かれたもの
選択基準 - 面倒はイヤ
- コンパイルとか面倒
- 設定とか面倒
面倒はイヤなので
- 設定ファイル書かなきゃいけないのはボツ
あと個人的には
- 環境が変わるたびに調べ直すのは面倒
- Mac でも Linux でも Windows でも動いてほしい。説明もその方が楽。
ということで
3. LLで書かれたもの
だけを扱うことにします。
Windows には小さい Web サーバはたくさんある
ちょっと脱線。
実は Windows にはバイナリインストールできる軽量 Web サーバがたくさんある。KUROIGAMEN とか知らないし、マウスでポチポチするだけがいい、という場合はそれらの中から好きに選んでもらえばいいんだけど、これと同じものが Windows 以外では動かないとか動くけどコンパイルが必要で面倒くさいという場合が多い。こうなると Windows 以外の環境とノウハウを共有することが難しい。ここが自分の中では問題だと感じている。
例えば開発者が Windows でデザイナが Mac という環境の場合、どちらかのノウハウもお互いに教えることができず、効率が悪い。また個人で複数の OS を使うのは作り手としてはそれほど珍しい話ではない。そうなったときにもノウハウが共有できないと面倒が増える。
それに、一つくらい LL が使えるといろいろ世界が広がるよ。
※ 実はしばらくの間 Windows でも Mac でも mongoose ( 旧 shttpd ) を使えばノウハウも共有できるし立ち上げっぱなしでも邪魔にならないし、いいじゃんと思っていたんだけど、v3 になって Windows のタスクトレイに入るようになってからどうも Windows で挙動があやしいのでオススメしないことにした。
Python
長らく LL で手軽な Web サーバと言えば Python が有名だった。と思う。
python -m SimpleHTTPServer
と打てば
- カレントディレクトリを Document Root に
- port 8000
で Web サーバが立ち上がる。
http://localhost:8000/
を開くと python を起動したディレクトリの中身が一覧に出てくる。
インストール
Python は Windows ではインストーラで手軽に入るし、OSX なら最初から入っているので新たな作業は不要。
http://www.python.org/download/releases/
Ruby
Ruby も標準で WEBRick という Web サーバを持っているのだが、長いこと手軽に起動する方法がなかった。これが 1.9.2 になって改善した。
ruby -run -e httpd DIRCTORY
で ok. DIRECTORY を `.` とするとカレントディレクトリを Document Root として動作する。
ただし OSX や Linux などでは 80 番ポートで動かそうとして root 権限がないと怒られる。
sudo ruby -run -e httpd DIRCTORY
か
ruby -run -e httpd -- --port[=]3000 DIRCTORY
などとすると良い。代表的なのはこんな感じになる。
ruby -run -e httpd -- --port 3000 .
WEBRick サーバを自分でスタートするよりは手軽だけどまだ Python に比べるとちょっと気を使うし、面倒な感じはある。
cf. ruby -run -e httpd – –port=3000 . - %!zt! <diary> (2010-12-02)
インストール
- Windows なら http://rubyinstaller.org/
- Mac の場合は
- コンパイルしたくない場合は実は JRuby が手軽じゃないか
- jruby –1.9 -run -e httpd – –port 3000 でイケる
Perl
Perl は Perl 入れて cpan から好きなもん入れてください。以上。
PHP
フロントエンドの人といちばん仲の良さげな PHP. 実は PHP も 5.4 から build-in の Web サーバを持つらしい。でもまだそれが本当に手軽に手に入る環境はないので、これも割愛。
まとめ
やっぱ手軽さでは Python か。PHP 5.4 が来たら実は本命になる可能性もあるのかなぁなんてことを思ったりしている。.htaccess と php.ini から解放されるなら、だけど。
使ったことはないけど、新しい PHP を使いたいけど野良ビルドも自力バッページングもいや、っていう場合にもしかして使えるのかな？
でも自分で使いたいモジュールがパッケージになってなかったらやっぱ自分でやらないとダメな気がするな。
Yahoo! ニュース紳助、罰金納付…女性側は引退要求、民事訴訟も示唆 の一部
最後は、「会見で島田氏は『辞めろといわれれば辞める』と言いました。本当に悪かったと反省をしているならば辞めてください」と引退を要求した。現在も心身ともに仕事に復帰できる状態ではなく、休業中。
すいません。本気で分からないかも。暴力行為の責任を取ることと仕事を辞めるのは関係ないような。この発言からは紳助を社会的に抹殺したいという意思しか読み取れない。それって本当に被害者の意思？ 被害者が普通に抱く感情ですか？
仮に自分が吉本や芸能界（の裏舞台）に復帰する意思があるからはちあわせしたときに恐怖が蘇る、とかいう話だったら「自分が歩くからこの道通るな」ってことを言ってるように聞こえます。
「仕事できんからその分補償せい」ゆーてあれこれ金を払わそうとするなら分かるんです。でも紳助辞めさせても芸能界には紳助に味方してる人だってたくさんいるわけで、そういう人たちの発言一つ一つに傷ついたゆーてるような人が今後も吉本で働けるとは思えない。テレビに出てるのを見るだけで恐怖が蘇るとかいうレベルになるとさすがにちょっとそれはいくらなんでも根拠として弱いでしょ。仮に事実でもそれで裁判を進めることはできないと思うなぁ。紳助が出てない番組の方がはるかに多いんだから番組情報チェックして見てくださいって話ですよ。難しいのは CM だけど、あれなら向こう3年 CM 契約結ぶな、とかいう話には持っていけるかも。まぁ実際には裁判の中でそういう要求をするかどうかはまだ分からないんですけど。
なんかどうも腑に落ちないんだなぁ、この事件。
ブログで会社をクビに——米国で解雇例が続出 (Hot Wired Japan)
「Blogやめますか？会社やめますか？」(slashdot.jp) でも取り上げられているけど、この話がニュースになるのは恐らく海外の事例だからじゃないかなという気がする。
これはそもそもオフラインで人間がどのように付き合っているかということによる部分が大きいんじゃなかろうか。日本では例えオフ（働いてない時間ね）でも会社の上司、部下関係を逃れるのは難しいし、所属している組織などでその人自身を判断してしまいがち。だから例えその人のオフィシャルな立場で書いていない blog でも、日本の場合は所属組織や立場と結びつけて判断してしまいがちな気がする。というか少なくとも多くの人がそれを感じ取っているはずだ。
だから日本では立場を明らかにした日記や blog は有名人のものでなければ多くないと思う。少なくとも自分の見ているものの多くは知っている人は知っているかも知れないけど blog 上では明記されていないものが大半である。そして立場を明確にしてあるものは日常的なくだけな内容のものが多い気がする。なぜならその方がビジネス上の取引関係に影響しにくいし、自分の立場に影響が出にくいから。
これがしかし研究者など、自分という存在ありきで組織を渡り歩くタイプの人の場合は若干違うように思う。例えばセキュリティ研究者がセキュリティについての事件や技術について書くのはヘマ1をしない限り自分の立場を危うくするものではない。むしろこの人は精力的な活動をしていると注目を集め、仕事が増えるかもしれない。しかしそれでも所属組織についてはおいそれと書かないだろう。例えそれが自分の個人的見解であってもだ。
これが恐らく日本的な常識なのではないかと思うが、どうだろう。日本で今回のような話が問題になるには恐らくまだまだ時間が掛かると思う2。それがよいか悪いかの判断をここでするつもりはないが、もう少し自由に書けた方がいいんじゃないかな、という個人的な見解は書き添えておく。
Acrobat
7 では Reader の機能が拡張され、Professional で生成するときに許可を与えられた文書について、Reader から付箋を貼ったりできるようになる。つまり昔 Acrobat Business なんとかって言ってたようなものが Reader に入ったってことかな？
7 では
- Professional
- Standard
- Elements
- Reader
に分かれていて、
- 付箋などの機能が問答無用で使えるのは Standard 以上
- Professional で許可が与えられればそれ以下でも可なのだろう
てことは
- 一人で普通に使う分には Standard で十分
- 大人数で PDF ベースの校正、確認作業などを行う場合は Professional を少なくとも1本用意して、あとはみんな Reader で
って運用が嬉しいのかな？ 値段は
| Professional | 5.7万 |
| Standard | 3.6万 |
| Elements | 100ライセンス以上じゃないと買えません |
| Reader | 無料 |
まー「PDF を作るだけ」なんてのソフトはクオリティにこだわらなければ無料からイチキュッパ辺りで選択肢がいくつかあるので今さら Elements で個人売りは考えないってのは正解でしょうな。1
アイディアプロセッサの不満
- インスピレーション
- 日本語版が最新版に追随してくれない。
- wmf の書き出しが特殊なのか Illustrator がダメなのか、文字の位置が保存されていない。
- Illustrator などの他のツールで編集しようと思うと変なところでオブジェクトが切れている。
- OmniGraffle 2.x
- 入力した文字量に応じてダイアログの大きさを自動で変更するようにしていていると padding がなさすぎて見にくい
- ヒラギノは例によって下に余白できすぎ
- リンクの接点が少なすぎてドローとして使いにくい
- eps に書き出したときに日本語の文字情報が残らない
- 全体的に操作スピードがインスピレーションに劣る
OmniGraffle を 3.x にすべきか悩む今日この頃。パディングの問題が解消されているだけでかなり嬉しいんだけど。。。Visio フォーマット対応は個人的にはどうでもいいけど、嬉しいときはあるかもしんない。
優待アップグレードってまだイケるのかな。
それにしたって OS X の吐き出す PDF はやたらでかいと思うけど。 ↩
最近、Space Saver II のキーの引っかかりがひどくて指が痛いので、その辺に転がっていた DELL の（サーバ用のちょっと古い）キーボードと交換。柔らかいタッチでなかなかよい感じ。
発注済のニューキーボードはあと10日はこない。しかし、エディタにかじりついている場合はトラックポイントはなくても問題ないことを発見。いやまぁ、ちょうどそういう時期だったからこそキーの引っかかりが気になったんだけど。
トラックポイントがなくても耐えられるなら、いずれは Realforce かな、こりゃ。ふっふふふ。