ぶろゲ

久しぶりにWordPressを更新するにあたり、エディターはどうあるべきかを検討した。エディターであれば使い慣れたMarkdownが望ましい。Markdownを使用するとコードと文章が混じった文章を書きやすい。今までのWordPressのエディタではうまく書くことができないだろう、と。

そう思いながらWordPressにログインして諸々の管理・更新作業を行ったあとに、ふとダッシュボードを見るとGutenbergエディターをお試しください、とある。どうやら次回のバージョンのWordPressでは、このGutenbergエディターが標準のエディターとなるらしい。

なるほどなるほど、WordPressも未だ歩みを止めていない、ということである。

Gutenbergの説明を読むとブロック単位での編集に特化したような記述が多い。かつてOneNoteを上手く扱うことができなかった記憶がよみがえる。OneNoteもブロック単位の編集に特化したアプリケーションであった。とはいえ説明をよく読むと、OneNoteとは違い、WordPressとしてあるべき姿を追求しているようである。

そうしてMarkdownを導入する手をやめ、一旦はGutenbergエディターを試しているところである。

ふむ。まぁ書ける。問題はそれほどない。

public class User {
    public User() {}
}

コードも問題なくかけるようだ。ただ、文中のコード表現、例えばUserなども書けるかどうか。これは微妙そうである。

さてはて、今後のWordPressの行先を見るためにGutenbergエディタを少しくらいは使ってみようかと思う所である。

Surface 3をMacBook Air 13(Mid 2012)の代わりに購入した。

背景

今から4年前、9.8万円で13インチのMacBook Airを購入した。その頃、使っていたPCはThinkPad x61と自作機で、MacBook Airは持ち歩きようとしても家用としても有用だった。Windowsユーザーであり本来ならWindows機を買うべきだったが、その少し前に買ったiPad(第三世代)などのアプリを書きたいという気持ちもあり、Macを買う決断となった。

それから3年後、MacBook AirではVisual Studioのビルドに耐え切れなず、またディスプレイの解像度も低かったため、作業用PCとして新たにMacBook Pro 15(2015)を購入した。15インチのProは素晴らしい性能と素晴らしいディスプレイを兼ね揃えているのだが、いかんせん15インチの大きさと2.04kgの重さが持ち運びに向かない。辛さを感じた。

そうしてMacBook Airはまだ持ち歩き用として使うことにした。しかしながら、Airでさえも、鞄の中で多少の大きさと多少の重さを感じ始めるに至り、そろそろ持ち歩き用のPCを買い替えることにしようと思った。

選定条件

MacBook Airに不満があって持ち歩き用のPCを変更するにあたり、最低限の条件は以下のとおりである。。

1. 1.35kg(MacBook Air)よりも軽いこと
2. 32.5×22.7(MacBook Air)よりも小さいこと
3. 1440×900(MacBook Air)よりも解像度が高いこと

持ち歩き用のPCとして求めるものは以下のとおりである。

1. 作業用PCにLTEを用いてVPN経由でリモートデスクトップを行う
2. したがってCPUパワーは快適にリモートデスクトップができる程度でよい
3. またWordやExcel、PowerPointなども快適に使えるとよい
4. 前者の快適さを満たすために打ちやすいキーボードは必須である
5. ブラウジングの快適さはiPad miniがあるので求めていない
6. ゲームや動画編集は行わない
7. LTEは搭載できたらよいが必須ではない

これらの選定条件に従って選別していったところ、以下のマシンが列挙された。

• Apple iPad mini 4 + Bluetoothキーボード, 追加費用約1万円
• CHUWI Hi10 Pro + Bluetoothキーボード, 521g+?, 合計約3万円
• CHUWI HiBook + Bluetoothキーボード, 550g+?, 合計約3万円
• Microsoft Surface 3(中古) + タイプカバー, 906g, 合計約5万円
• Microsoft Surface 4 Pro + タイプカバー, 合計1076g, 合計約13万円
• Apple 新しいMacBook, 920g, 約14万円
• NEC Hybrid Zero HZ330/DAS, 798g, 約11万円
• NEC Hybrid Zero HZ300/DA, 798g, 約10.4万円

選定

まずiPad mini 4とBluetoothのキーボードを活用するアイディアを考えた。iPad mini 4はすでに持っているので、キーボードを購入するだけでよい。またmini 4は常に持ち歩いているので大きく荷物が増えることがない。よいアイディアのように見えた。しかしながら、iOSでは物理キーボードのCtrlやAltを認識しないという問題があり、結果としてリモートデスクトップ時にショートカットキーが使えず、快適とは言えなくなる、という点により、敬遠した。

次にCHUWIなどの中華タブレットだが、これはタブレット本体が軽く、安いという特徴がある。ただし購入とサポートに少しの難がある。HiBookなどはキーボードもついてくるが、このキーボードは英語版である。またタイピングのタッチ感も実物を触らないとわからない。自分の満足するキーボードを得るためにはBluetoothキーボードになるだろう。

MicrosoftのSurfaceは非常に有力な候補である。まず、タイプカバーというカバーにもなるキーボードが存在するのだが、その打ちごごちが良い。デザインも楽しい。アイソレーション型ではないのだが気にならなかった。Surfaceはペンタブレットとしても利用することができる。ただし、ペンは高い。Surface 3はLTE版が存在しており、SIMを入れることで気軽にインターネットに接続できる。4 Proは少し高価だが、良い性能を持っている。MacBook Airの代替にふさわしい機種であると思わされた。この中で比較するのは卑怯だがSurface 3は中古の価格が安くなってきている。

Apple MacBook Airからの乗り換えであるのならば、新しいMacBookも検討すべきだ。このMacBookはキーボードの打面が広い。広いので打ちやすさがある。全体のデザインも良い。しかしながら、選定した機種の中では高価だ。予算制限がないのであれば、購入したい逸品である。

NECのHybrid Zeroは非常に野心的な製品であり、フルセットのノートPCでありながら軽い。異常に軽い。現時点では秋冬モデルが出ているが、春モデルの価格がこなれてきているので、そのモデルを対象にする。このHybrid Zeroはタブレットのみで410g、キーボードを含めて798gである。一般的にキーボード側はより軽く、タブレット側は重いはずなのだが、タブレット側が軽くなっている。これは本来タブレットが持つべきバッテリーの一部をキーボード側が持っているからである。この設計が秀逸であり、タブレットは重くなれば重くなるほど、手に取って利用することがむつかしくなる。タブレットとしてもノートPCとしても使える2wayタイプのPCはタブレット側が重くなってしまう傾向があり、タブレットとしては使いにくさがある。それを解決している。

結果

以上の製品を検討した結果、Surface 3を選択した。

タブレット本体とタイプカバーを合わせても約900g程度であり、Appleの新しいMacBookと同等の重量である。でありながら、中古ながら非常に安くで購入できる。問題はCPUであり、x7-Z8700はCore mシリーズには及ばない。しかし持ち歩き用のPCはリモートデスクトップで接続するためにしか使わないとの前提状況があり、その用途であれば十分である見通しである。

SIMが入るLTE版のSurface 3はGPSも持っており、地図では便利そうだ。ただし、このSurface 3とSIMの関係には注意が必要であり、まず、中古では△状態のものが多い。すなわち残債があり、LTEの利用をキャリアに止められてしまう可能性がある。LTEを使う予定であり、中古で購入する場合は○状態のものであることを気を付ける。また、Surface 3のLTEの対応する周波数帯域はSoftbankに最適化されたものであり、DocomoやAuの回線では速度が出ないとの報告が挙げられている。

このLTE/4G版のSurface 3、128GB、4GB版を4万円で購入した。そして、この記事をSurface 3で書いている。キーボードの打ちごごちが個人的に好きである。

AVアンプを買って5.1chを構築して1ヶ月経過したという記事をしたためてからもう4年も過ぎていたことに驚いている

映画なぞ，それほど見るわけでもないが音楽好きが興じてホームシアターの構築を始めた。

フロントスピーカー: Onkyo D-305F
サラウンドスピーカー: バックロードホーン
センタースピーカー: Onkyo D-305C
フロントハイ: Onkyo D-305SR
サブウーファー: Onkyo SKW-305

現時点の構成は前述の通りで、中古のスピーカーを集めたものだ。音に関してはほぼ満足で、映像は32インチのディスプレイで楽しんでいた。ところがプロジェクターの購入に至った。このプロジェクターの導入をなぜ決めたのか、という点について書き残しておこうと思う。

最近、画面が32インチでは小さすぎる、フルHDを見ることができないという問題を再発見した。 この問題に対して映像装置のアップグレードによる解決を図ろうと考えた。

当初はUPQ（アップキュー）の50インチ4K液晶テレビ購入案が有力であった。 この4Kテレビは7万5千円という2015年11月時点の4Kテレビの価格としては安価であり、その理由としてチューナーがついていない点を主張していた。 4Kテレビにチューナーがついていなくとも現時点でフルHD向けのレコーダーは所持しているのでテレビを見ることに追加の予算は必要ない。 また、4KソースをPCから入力することによって、写真などのコンテンツをより楽しむことができるだろうと想定した。

そうしているうちに、何かの拍子にプロジェクターが良い、という情報が入ってきた。 エプソンのTW-5200が良いと。 なるほど。プロジェクターは良い。が、画質に問題があるのではなかろうか。また4Kテレビと比べたらアラが目立つのではなかろうか。 また夜しか使えないのではないか。 そうした疑問が出てきた。

しかし検討していくと、プロジェクターでもフルHDまでなら可能であり、また思っていたよりも大画面化、すなわち80インチや100インチが可能であるということが分かってきた。 また想定とは異なり、重量がTW-5200であれば、3kgを切る2.8kgである。これぐらいの大きさであれば、持ち運びも可能である。 TW-5200はそうした多くの人の想定を覆して良く売れた機種であったことを知った。

TW-5200の後継機であるTW-5350にはフレーム補間なる機能があることも分かった。評判によるとフレーム補間は拙いものと考えた方が良いらしい情報が得られた。

こうした事前情報を得てプロジェクター専門店におもむき、担当者の方からプロジェクターのいろはについて教授願った。

そうして見ていった結果から、黒浮き・フレーム補間という指標が個人的に重要な項目であると感じた。

黒浮きとは黒が黒らしく見えるかどうかであり、特に映画の暗いシーンで重要な指標となる。 高級機のプロジェクターは素晴らしく黒が沈み込む。確かに映画を見るのであれば、高級機に費やす気持ちが分かってきた。 しかし、自身の用途としては映画が主ではない。 そうした映画以外のコンテンツを比較していったところ、自身の目では高級機とエントリー機の画質の違いが分からなかった。

対してフレーム補間は、自身の目にも顕著であった。映画は秒間24フレームで作成されているのだが、TW-5350は秒間120フレームに補間を行ってくれる。 TW-6600（15万円）というTW-5350（9万円）の一つ上の機種があるのだが、TW-6600は少し古くフレーム補間が搭載されていない。 TW-6600とTW-5350を見比べたところ、フレーム補間ありのTW-5350の方が良いと感じた。

こうして、10万円、15万円、30万円の機種を見比べていった結果、エントリーとしては間違いなくエプソンのTW-5350は買いであろうという結論に落ち着いた。 より上位のプロジェクターが欲しくなったなら、そのときは追加買いすれば良い。ソニーのDPL-HW60は良い機種だった。 TW-5350の絵作りは映画というよりはむしろ、テレビ番組やゲームなどのそれに向けて作ってあるようで、明るい画面では非常に好印象だった。

そのままプロジェクター専門店でTW-5350の購入に至った。TW-5350にはモバイルスクリーンが付属するものがあり、そちらを購入した。 50インチ4Kテレビのことは忘れることとした。 4K放送は限られた放送局であること、安価な4Kを買うのであれば、二倍の価格となるが16万円くらいのグレードのフレーム補間ありの4Kテレビを購入した方が良いだろうこと、それに比べたら購入しようとしているプロジェクターの方が安価でよりモビリティが高く利用価値が高いことなどが理由である。

そうしてプロジェクターを設置し、ホームシアターの個人的な完成となった。

プロジェクターを設置してみた感想としては、外で体験する80インチと自室で体験する80インチは大きさの体感が異なり、自室での80インチは大きすぎるくらい大きかった。 が、迫力は32インチのハーフHDの液晶テレビと異なる。 フルHDでもこれくらい大きくしなければ本来の映像が持っていた情報量を認識することができなかったのだな、と認識した。 これはオーディオでもスピーカーとアンプを買いそろえたときに音楽に対して感じたことでもある。

デメリットとしてプロジェクターのランプの寿命は早く、また消費電力も大きい、という点がある。 基本的に自室ではテレビは常につけるのではなく、限られた時間、1日でも1,2時間程度しか使わない。 そうした限られた時間の中で利用するのであれば、デメリットは問題とはならない。

TW-5350の2200ルーメンという明るさは、真っ暗闇を作らなくても何とか見ることができるレベルであり、多少明るいリビングでサッカーを大画面で見るときに重宝している。 またTW-5350はTW-5200より少し重く3.1kgだが、持ち運びは可能である。

こういうことであれば、より早くプロジェクターを購入しておけばよかったと思うものだが、TW-5350というフレーム補間を備えて10万円を切る機種がなければ手を出さなかっただろうとも思う。 TW-5350は2015年8月27日の発売ということで、時期もよかった。

エントリークラスのプロジェクターを支えたTW-5200およびその後継機のTW-5350に感謝したい。 昨年の良い買い物だったと思う。

東芝の便利SDカード，FlashAirを買って便利に使っている．

このSDカードの特徴は無線LANを搭載している点だ．デジタルカメラやPCからはふつうのSDカードのように見えるが，実は無線LANアクセスポイントとして動作しており，スマートフォンから無線LANで接続してブラウザ上から画像をダウンロードすることが出来る．

こうした文章上では使いやすそうな印象を持つのだが，実際は「接続した先のWebサイトが使いにくい」「転送が遅い」「写真を1枚ずつダウンロードする手間がかかる」「PCに画像をダウンロードする場合は，PCの無線LANの接続先をFlashAirに変更する必要がある」など，辛い面がいくつかある．よって，一般人は素直にEyefiを買う方が幸せになれる可能性が高い．

しかし，Linux上などでのプログラミング知識があるのなら使いやすくなる．

まず，FlashAir自体がAPになるモードではなく，FlashAirが子機になるステーションモードに設定を変更することを行うと良い． FlashAir Developers – ドキュメント – 上級者向けチュートリアル – ステーションモードの利用

これをすることによって，PCの設定を変更することなくFlashAirに接続することができる．だが自宅のAP範囲内に限られるため，外で使いたい場合は，APとして起動するように再度設定を変えなければならない．

第2に，手元のフォルダとの同期をプログラムで行うことだ． 例えば，Linuxサーバ上に/picture_dataのようなフォルダを用意し，以下のようなrubyプログラムをcamera.rbとして保存，実行する．あくまで例．

#!/usr/bin/env ruby

require 'open-uri'
require 'csv'

ip = `nmblookup flashair | tail -n1`.split(" ").first

dist = "/picture_data/"

path = "/DCIM/100__TSB"
CSV.parse(open("http://#{ip}/command.cgi?op=100&DIR=#{path}")).each do |row|
  unless row.size == 6
    next
  end
  name = row[1]
  unless name =~ /^IMG/
    next
  end
  url = "http://"+ip+path+"/"+name

  dist_path = dist + name
  if File.exists? dist_path
  else
    p url
    p dist_path
    open(dist_path, "wb") do |f|
      f.write open(url).read
    end
  end
end

FlashAirのcommand.cgiにアクセスすることで画像ファイル一覧がcsvとして取得できる． FlashAir Developers – ドキュメント – APIガイド – command.cgi

その画像ファイル一覧と，手元のpicture_dataフォルダ内の画像を比較し，手元にないものを複数枚ダウンロードして保存する，という操作をプログラムを書くと一括して行うことができる．こうした操作を10秒に一度実行するようなループ動作させてもいいし，定時に実行するタイマー動作させても便利だ．

FlashAirはNetBIOSによって”flashair”というNetBIOS名を広告しており，Windows機からはhttp://flashair/というURLでアクセスできる．IPアドレスを知っている必要がない．本プログラムでは，sambaに含まれるnmblookupを用いて，NetBIOS名からIPアドレスの問い合わせを行っている．しかし，FlashAir側の設定で固定IPにしても良いし，そうすることでWindows上のrubyでも活用可能だろうと思う（そもそもWindows上ではNetBIOSによる指定が普通に使えるのかもしれない）．

なぜ，このようなFlashAirの使い方をしているのかというと，

• 自宅でのレンズのチェックのための撮影，もしくは撮影技術の修練
• 即時のPCの画面による確認

という反復作業を行うことが多く，PCでの確認は従来手法では

• デジタルカメラからSDカード取り出し
• PCに差し込み
• 自動起動からディレクトリ閲覧をクリック
• 最新の画像をダブルクリック

という手順を踏む必要があった．これがFlashAirとプログラムを使うと，

• プログラム実行
• フォルダに増えているのでダブルクリック

程度の手間になる．プログラムをループ動作するようにすれば，

• フォルダに勝手に増えているのでダブルクリック

の手間だけになるし，その気になれば

• 増えたファイルを勝手に全画面表示する

まで行ける．

この利点が大きい．さらに工夫を加えたい場合にも，command.cgiやhttpベースの単純な仕組みは，プログラム上，簡単に取り扱うことができるので，容易である．

ただ，唯一，面倒だと思う作業があり，それはデジタルカメラのオートパワーセーブ設定を変えねばならぬ点である．FlashAirは仕組み上，SDカードに通電されていなければならないが，今，手元にあるデジタルカメラのオートパワーセーブの設定では15秒で通電が切れることになっている．その設定を「15分」や「セーブしない」などの設定に変更しなければ，画像の閲覧中・転送中に切断されてしまう．一方，セーブしないような設定にしておくと，無駄に電池を消耗してしまうので，戻す必要がある．この手間ばかりは仕方がない．

ということで，多少プログラミング知識ある人なら撮って見を楽しむことができるFlashAir，という話． Eyefi Pro X2を買えば，こんな苦労はする必要がないのだが，どうしてもLinuxサーバに自動取得・自動保存をさせたかったので．

ゲーム機によるオンラインゲームのプレイ時にラグという現象が生じる。一瞬ではあるが動作が止まっているように見えたり、弾が当たったのに当たっていない等のプレイの整合性が崩れたりする現象を指す。オンラインゲームについての掲示板ではラグを避けるための環境の整備に言及されることが多い。その中でも無線LANはやめておいた方が良いという意見が多く、注目されている。この原因について考えたい。

なお、実際にオンラインゲームを行っている人間が書いた考察ではないので、実際にどうなっているのかは知らない。

アプリケーションと通信の特性

オンラインゲームに限らず、ネットワークを使用するアプリケーションにおいて重要な通信特性は以下になる。

1. スループット
2. 遅延

スループットは単位時間あたりのデータ転送量を表す。短時間に大量のデータを送信することが要求されるファイル転送やブラウジングにおいて重要な特性である。オンラインゲームの場合、大容量のデータ転送はそれほど必要がないケースが多い。有線LANでは100BASE-TX接続では100Mbps、1000BASE-T接続では1Gbpsの帯域幅を確保できるが、無線LANではIEEE 802.11nでは100Mbps程度、IEEE 802.11gではせいぜい20～30Mbps程度が限界だ。しかしながら、1Mbps程度あれば十分だと考えられるので、それほど問題になるとは思えない。

遅延は転送データが到達する時間を表す。ネットワークにおける遅延の中には簡単に処理遅延、キューイング遅延、伝送遅延などがある。処理遅延はパケットのヘッダを処理して宛先インタフェースに出力するまでの時間、キューイング遅延はキューの中に入ったパケットが出力されるまでの時間、伝送遅延は伝送路を経由して次の端末に到達するまでの時間とされている。

特にリアルタイム性が問われる格闘ゲームの場合、映像の1フレームの操作が勝負を左右すると言及されることが多い。ゲームの処理が1秒間に60フレーム処理される場合を考えると、1秒÷60フレーム=16.6ミリ秒であり、仮に1フレーム毎に他者との通信を行うときには16.6ミリ秒の間に転送完了する必要があると考えられる。これらのことから、スループットよりも遅延の重要性が高いと考えられる。

実際に無線LAN接続が有線LAN接続に比べてどのくらい遅いのか実験を行ってみることとする。無線LANアクセスポイントを用意し、Linuxサーバと接続する。PS3と無線LANアクセスポイントは実験に応じて有線LANと無線LANのどちらかで接続される。サーバからPS3に対してpingを行うことによってRTTを測定し、遅延時間を測る。PS3は802.11b/gに対応するため、今回は802.11gを用いた。PS3と無線LANアクセスポイントの位置関係は見通しではないが、同じ部屋であり、3-4mほどの距離である。

PS3–(有線)–無線AP–(有線)–サーバ

20 packets transmitted, 20 received, 0% packet loss, time 18997ms

rtt min/avg/max/mdev = 0.271/0.313/0.651/0.089 ms

PS3–(802.11g)–無線AP–(有線)–サーバ

20 packets transmitted, 20 received, 0% packet loss, time 19027ms

rtt min/avg/max/mdev = 2.017/3.854/8.679/2.307 ms

20回程度のpingで分かることは、有線LANの場合は0.3ミリ秒程度のRTTであり無線LANの場合は3.9ミリ秒程度のRTTであるということである。
また無線LANの場合は最大8.7ミリ秒程度のRTTが記録されている。

ゲームの1処理16.6ミリ秒を思い出すと、無線LANでもその域に数値が収まっているように見える。しかし、インターネット接続が何であるか、それによってどのくらいの遅延があるのかによって条件は変わってくるかもしれない。例えばインターネット接続による相手先へデータ到達にかかる遅延が14ミリ秒であった場合、今回の実験で観測された8.7ミリ秒の半分の4ミリ秒が遅延として現れると14+4=14ミリ秒の遅延となり、目標である16.6ミリ秒を超えてしまう。有線LANの場合、最大0.7ミリ秒でその半分の0.4ミリ秒が遅延としても14+0.4=14.4ミリ秒となり16.6ミリ秒に間に合う計算になる。

この結果は無線状況が良い場合であり、無線LANアクセスポイントとPS3がもっと離れている場合や、無線状況が悪くてフレーム到達率が悪く再送を必要とする場合、より多くの伝送遅延がかかることはあり得る。それに加えてインターネット接続の遅延が大きいと無線LAN接続が問題となり、有線LAN接続にすると問題が解決するケースがあるのではないか、と推定される。

逆にインターネット接続による相手先への片方向遅延が4ms程度であり、かつ無線LANが良い状況であれば、4+4=8ミリ秒程度となり、安定したプレイができる可能性が高いはずである。しかしインターネットの遅延や無線状況は時々刻々と変化するものであり、少しでも遅延に関する懸念を減らしたいと考えるのであれば、有線LANを導入すべきだろう。

まとめ

• ゲームの1フレームの処理は16.6ミリ秒であり、1フレーム間に1回の通信が必要であるとすれば、通信の片方向遅延は16.6ミリ秒以内に抑える必要がある。
• サーバに対して無線LANアクセスポイントを有線LAN/無線LANで接続したPS3で接続し、サーバからPS3に対してpingによるRTT測定を行い、それぞれ平均0.3ミリ秒/3.9ミリ秒、最大0.7ミリ秒/8.7ミリ秒のRTTが見られた。
• インターネット接続の遅延が小さく無線LANも良い状況で接続できるのであれば無線LANの遅延時間は小さく16.6ミリ秒の目標を達成できるため、直ちに問題になることはない。
• 無線LANは有線LANより懸念がある。
  • インターネット経由で相手端末にデータ転送するためにかかる片方向遅延が大きい場合。
  • 無線LANの接続状況が悪化した場合。

おまけ

同様に無線LANアクセスポイントにiPhone 4Sを接続し、サーバからiPhoneに対してpingを行ったところ平均93ミリ秒、最大145ミリ秒のRTTという結果が出た。

20 packets transmitted, 20 received, 0% packet loss, time 19028ms

rtt min/avg/max/mdev = 33.496/93.057/144.923/32.753 ms

これに対して、iPhoneアプリのPing Analyzer – Graphical Network Pingからサーバにpingを行ったところ平均27ミリ秒、最大44ミリ秒のRTTという結果が出る。

サーバからiPhoneへのpingでは平均93ミリ秒だが、iPhoneからサーバへのpingでは平均27ミリ秒。
なぜ、このような結果が出るのか。
こういった差異こそがネットワークや無線LANの理解を深める、よい課題なのかもしれない。

やらなければならないことがあるときに思考は横道を走り、またやらねばならぬことが重大であるほど横道思考も良く走る。今回は風呂に入っている最中に表題のような仕組みを思いついた。思いついたように思えたが、過去に思いついたことを再度、書き散らしているだけかもしれない。ともかく、思考を出力してみる。

某氏が研究材料にwikiを選んでから、ほうほう、それはそれは、と横目に見つつ、自分なりの文章管理システムの在り方を考えてきた。
ぼくのかんがえたさいきょうのマニュアル管理システムはその一端であり、マニュアルとは如何なるものかという思考の流れでたどり着いた一つの考察である。

はじめに

実際にWeb上で構成されたシステムはどのようなものなのか、と問われれば、それはwikiを基盤にしたものだろうと答える。
wikiは文章の整理には向いていると考えている。
タイトルと本文で構成され、本文中のリンクによって記事同士のつながりができる。
また記事の編集も容易である。
記事タイトルの付け方にある程度のルールを定めれば構造化もできる。

しかしながら、実際にwikiをWeb上で活用している人はそれほどいない。
技術的な内容でさえ、wikiではなく、ブログ上で展開される。
解せない。そういう感情があった。
wikiに書いておけば構造化され、後から見ても分かりやすいはずだ。

ブログは時系列のデータにしかならない。後から見返すのには向かない。
普通なら、後から見返すためにはタイトル一覧くらいは用意するが、用意しているブログは少ない。
ニュース記事を配信しているサイトでさえ、タイトル一覧という考え方はあまりしない。

そういった体験を経て、wikiよりもブログが選ばれる点について、ふと思うところがある。

wikiの弱点

実際にwikiを運用し利用していく中で不都合が出る。
それは誰かが更新した結果を確認するのが面倒な点である。
もちろんwikiでは更新された記事が何であるか、どのポイントが更新されたのかは後からわかる。
Wikipediaではそのような情報を元に校正を行っているのだろうだから、機能しているはずだ。

だが、自分で実際に利用してみて、非常に分かりにくい。
また、Web上の文章としてwikiの更新履歴のRSSを自分のRSSリーダーに入れるだろうか。
自分はそのような経験はない。

よって、Web上で見られる文章はwikiではなく、ブログが選ばれやすいのだろうと勝手に考えている。

wikiの弱点の克服のために

wikiの弱点は更新履歴の追従に問題がある点であることを述べた。
そう考えるのであれば、更新追従に強いシステムを導入すればよい。
つまり、wikiとブログの長所を掛け合わせたようなシステムにすればよい。

仮にwikiにブログ的要素を付加すると考える。

wikiに構築された1つの文章、知識が更新される。
その知識の更新が重要な場合に、なぜ、更新したのかの文章を書く。

wiki側では常に最新の理論があり、古い理論は捨てられる。
ブログ側では常に最新の理論の更新理由があり、読者の興味を惹き続ける。
そのようなことを妄想した。

システムの予想される問題点

改めてこのシステムを見返すと、Githubにおけるソースコードとcommitログのような関係に見える。

しかしcommitログは詳細には書かれない。このシステムは実際に利用するのは難しいのかもしれない。
例えば、ここで書いている文章すら、wikiにどう書けばよいのか、さらなる思案が必要になるし、
逆にwikiを書き換えたとしても、すぐに更新履歴を書けるものではないのだろう。
その点は問題である。

システムの実現

wikiとブログがあればできるんじゃないでしょうか。

まとめ

改めて見返すと、別に大したアイディアではないように見える。
なぜ、こんなものが思いついて、書くというモチベーションが生まれたのか甚だ疑問である。
そういった書き散らすような文章を書くのにブログというシステムは便利であり、
ブログだから許されるものである。
よってwikiのような頭使って構造化して理論を書こうという頭でっかちなシステムは、
非常に扱うのが難しく、頭に思い浮かんだアイディアを構造化してwikiに落とし込めるような
仕組みとかそういったものの方が大事だと思うのだ。

もしくは他の人のブログを見て、理論的に重要だと思うものは自分なりにwikiにまとめて、
更新部分にそのブログ記事のURLを張っておくとか、そういったことをしておけば、
自分は困らないのではないではないか。

よく分からなくなってきたのでもう寝る。時間の無駄だった。

この記事はよく分からない人が書いている個人的な見解なので鵜呑みにしないようにして下さい。

問題点は「表現」と「収入」と「著作権」だと思った。

SmartNewsというスマートフォン向けのアプリが問題となっている。件のアプリは、起動すると朝・昼・晩の３回ニュースが配信される。このニュースは、各メディアが配信しているニュース記事の見出しと画像を、RSSもしくはスクレイピングによって抜き出して表示し、かつ、記事の内容まで表示するものである。この記事の表示の際に独自のレイアウトを行う。例えば記事の文章以外の要素（広告を含む）を排除していたり、複数ページにわたる記事の場合はつなげて1枚のページとして表示したりする。

このアプリケーションに対して、ある記者が『SmartNewsの スマートモードに全文転載されていて、とても悲しい気持ちになった。スマートモードはユーザーには便利だが、完全タダ乗り』というツイートを行った。そのツイートに呼応して様々な声が上がった。

自分としては、このアプリに関する問題点は「表現」と「収入」と「著作権」だと思った。

著作権

（追記：仮にスマートモードが「メディアからダウンロードしてサーバに一旦キャッシュ」するタイプの機能の場合。それではなく、各記事から直接ダウンロードする形式の場合は、この著作権項の主張は当たらない。この機能の詳細については未確認）

まず先に「著作権」の話をすると、侵害している可能性があるのは、メディアからダウンロードしてサーバに一旦キャッシュされる情報である。まず、これまでの判例から、複製の主体はサービス提供者側となるので私的複製にはあたらないと考えられる（複製権の侵害）。そのサーバから送信しているので、公衆送信権の侵害を行っている。ので、おそらくその点を追及されるとアウトなのだろうと思う。（プロキシのキャッシュに関して「送信障害の防止等のための複製（著作権法47条の5）」という条項があり、それが効いてくるのかどうか分からない、tubefire裁判で追いたかったが…）

この複製の問題は、アプリケーションが直接メディアからダウンロードする仕組みにすれば解決するのだと思う。若しくは、キャッシュしないプロキシサーバを作れば、問題ないと思う。他にはevernote(read it later)に蓄積してからダウンロードするとか。

表現

次に「表現」の問題について考える。

通常、メディアのニュースは多くの利用者にWebブラウザによって閲覧されることを期待する。WebブラウザはHTMLを解釈して、記事の内容を表示したり、広告を表示したりする。SmartNewsでは「記事文章以外の要素を廃」したり「広告を排除」したりした。これは問題となるか。同一性保持権や翻案権の侵害かもしれない。しかし、これは実装依存の問題だ。例えばWeb上の文章はテキストブラウザで見ても良いと思うし、広告を見たくなければ広告を表示しないようにするadblockプラグインを使っている。また、SmartNews以外にもRead it Laterなどのアプリケーションも、そうしている。

メディアからダウンロードしたデータをどのように見たいかは、利用者の好き勝手で決まり、アプリケーションは自由に選べても良いのではないか、と思う。もし、そのアプリケーションに対して問題があるのであれば、メディア側には表示させないという選択肢がある。もちろん、アプリ側もどうしても表示させようとしてくるし、それはイタチごっこになる。どうしても自由なアプリで表示させたくなければ、メディアがアプリを作るしかない。電子書籍のようなDRM世界に向かうしかないし、仕方ない。

（よくよく考えると公衆無線提供しているキャリアのプロキシさんで画像を縮小して送ることもあるので、その点は問題ない、かなーと考えるけれども、複製の主体がサービス運営側だと問題あるような気がするし、よくわからん）

収入

最後に「収入」について。

「表現」の問題において、自由なアプリによる閲覧（例えば、広告を排除して読みやすくするアプリによる閲覧）を認めると、広告による収入が入らなくなる。メディアとしては問題がある。どうする方法があるのか軽く考えてみた。

• 有料配信する
  • メルマガタイプ
  • 月額タイプ
• 自由なアプリと連携する
  • 広告収入を分け合う
• Webで公開している記事は宣伝用と割り切る
• バナー広告ではない方法で収入を得る
  • 広告記事
  • ステマ記事

この中のうち、「有料配信する」「自由なアプリと連携する」以外は受け入れがたい選択肢だと思う。「Webで公開している記事は宣伝用と割り切る」という選択しては既に「有料配信している」場合に有効だが、そうでなければ意味がない。（とはいっても、８割の記事を書いて、残りの２割の詳細は紙面で、という方法は割とうまくいく気がするのだが）

となると、自由なアプリと何らかの形で関係作っておいた方がよいと思うのだけれどもなー、と。

まとめ

個人的な見解としては、やり方を変えれば、問題ないと考えている。現状の問題点は、（追加：もし行われているのであれば、）サーバにおけるキャッシュによる複製で、それを発生させなければどうでもいい気がする。（たぶん、プロクシとは見なされないと思う、複製主体がサービス運営と見なされそうだから）

記事以外の要素を排除したり、広告を排除したりはアプリの自由だから適当にやってよいと思う。その代り、メディアが死んでしまっては問題なので、双方が共存できる方法を模索すべきだとも思う（広告を排除するアプリが広告を表示したら本末転倒だと思うけれどね）。

この記事はよく分からない人が書いている個人的な見解なので鵜呑みにしないようにして下さい。