2014年9月13日土曜日

iWatchが思い出させてくれたこと:この世で売れて儲かるものは2種類しかない。最も高機能な物と、最も素敵な物だ

という記事を読みました:

If Switzerland Is Fucked, Then The iWatch Is, Too | TechCrunch
http://techcrunch.com/2014/09/07/if-switzerland-is-fucked-then-the-iwatch-is-too/

最も高機能な物と、最も素敵な物


iPadが世に出ても、モレスキンは売れつづける。
Surfaceが世に出ても、無印良品の文具は売れつづける。
Adobe Ink & Slideが世に出ても、日本製の万年筆は売れつづける。

なぜなら、最も高機能な物がすなわち最も素敵な物ではないからだ。
両者の客層はかぶらない。
あるいは、TPOに応じて両者を使い分ける。

だから、
iWatchが世に出ても、ロレックスは売れつづける。

だが、どちらでもない物を作りつづけるメーカーたちは……すべて撤退の憂き目にあうだろう。
なぜならそれらは、売れないか、儲からないからだ。

という内容です。

※若干、僕の言葉を補っています。

じゃあおまえはどうなんだ


これは、みずからの経営を考えるうえでも大切なことだとおもいます。

自分がAppleやロレックスになることは、もちろん簡単ではありません。

しかし、どっちの方向性をめざし、どっちのエコシステムに属するかについては、旗幟鮮明にしておくほうがよいとおもうのです。

※iWatchの正式名称はApple Watchと発表されました。

わかりやすく説明しようとしてるのにかえってわかりにくくなってしまう僕達の蹉跌から立ち直るただひとつの愛ある方法

WindowsでNode.jsやHubotをインストールするにあたって

本書サポート・マニュアル 目次
http://supportdoc.net/support-coffee/index.html

は非常に有用な情報源だ。

が、全篇にわたって口語を多用しているのが気になる。
ちょっと過剰と感じる。

わかりやすくしようという善意から出ていることは明らかだ。
が、まるで僕の若い頃を見ているようで、つらいものがある。

これは単に好みの問題ではない。
文語のほうが格調高くて好きとか、権威が感じられてセクシーとかいう問題ではない。
口語はなれなれしくてイヤとか、内容の知的価値を減じてるようでもったいないおとか、そういう問題ではない。

口語をむやみに使うことによって、読者による内容理解に支障が生じているおそれがあることが気になったのだ。
すなわち、技術解説におけるテクニックの問題である。

これは日頃、僕が問題意識をもって、自分も改善につとめている事柄でもある。
それだけに気になったといえよう。

以下、このサイトまたはその著者をおとしめようという意図はまったくないことをあらかじめお断りしておきます。
たまたま目についたので、ちょうど、日頃考えていることを書くためのサンプルとして、申し訳ありませんが利用させていただくだけです。
このページにかぎらず、ちまたに山ほどこういう事例はあります。
内容の有用性にケチをつけるものでももちろんありません。
なにとぞご了承ください。

たとえば、上記マニュアル内のページ

[8] npmによるCoffeeScriptのインストール
http://supportdoc.net/support-coffee/08-coffee_npm.html

に次の文がある。

図3のフォルダはホームフォルダにできます。

口語は諸刃のつるぎである。
とくに相手が初心者の場合はそうである。

たとえば僕は初心者として、最初、上記の文を
「図3のフォルダをホームフォルダに変えることが可能です。」
という意味だと勘違いした。

しかし腑に落ちないので、よく文脈を読んでみたところ、本当は著者は
「図3のフォルダはこのホームフォルダ内に生成されます。」
ということを言いたかったのだとわかった。

わかりやすさを狙うあまり、「できる」という口語表現の多義性が災いしている。

「できる」という言葉には、少なくとも
・「可能」
・「生成される」
の2つの意味があるからだ。
(ほかに「達成」「能力」などの意味もあるが、この例をそう誤解する危険はないだろう。)

この場合であれば、最低限、次のように工夫して書いてあれば誤解は生じなかっただろう。
「図3のフォルダはホームフォルダに生成されます。」

あるいは「の中」を補って
「図3のフォルダはホームフォルダの中にできます。」
とすれば、「できます」が口語表現のままでも誤解は生じにくい。

しかしもしかするとこれも、誤って
「図3のフォルダはホームフォルダの中に生成させることが可能です。」
という意味にとってしまうひとがいるかもしれない。

なのでやはり「生成されます」のほうが確実だ。

なお、この「~の中」という口語表現も、実は多義的であるので、避けたほうがよい。
文脈によっては、
・「~内」
・「~のうちの」
のどちらの意味ともとれるからである。

また、僕は、英文和訳の仕事をするとき、あるいは日本語の文を書くとき、英語でいう前置詞や定冠詞(the)にあたる語を極力省かないよう心がけている。

それは理解を大いに助けるからだ。

前置詞inにあたる「内」を補ったのが、上で僕が下線で示した改善例だ。

この改善例ではさらに「この」も補ってある。英語でいう定冠詞theである。「この」がないと、
「図3のフォルダはホームフォルダ内に生成されます。」
の中の「ホームフォルダ」は、世間一般のホームフォルダについて語っているにすぎない。

しかし文脈からして今、著者が、直前で述べたホームフォルダを指し示したい意図は明らかである。

であるならば、「他でもない、僕と貴女の間にあるこのホームフォルダ」であることを明確に示すために、「この」を補うことをためらうべきではない。

英語の場合には、ここでtheをつけるかつけないかを必ず選択しなければならないことが文法規約により義務付けられているので、逆に、こういう間違いが起こる危険が少ない。

Ruby on RailsでいうCoC(設定より規約)にも通じるものがあるかもしれない。

しかし日本語では多くの場合、theにあたる語は略されてしまう。
だから日本語でわかりやすく説明をしようとする者は、常にtheにあたる語を補うことをテクニックとして意識しなければならない。

思いやりのある、器の大きい人間は、説明をわかりやすく行うことにためらいがない。

なぜなら、それによって馬鹿に見えるほど自分の知性は脆弱ではない、という揺るぎない自信を持っているからだ。

しかし、説明をわかりやすくしようとする善意の努力の陥りやすい罠として、口語を多用してしまうということがある。

また、文が短いほうが良いだろうと考えて、前置詞や定冠詞にあたる語を省いてしまうことがある。

もちろん、口語を使うほうが理解しやすくなる場合には、口語のほうがよい。
だが、相手がトピックに不案内の場合、口語の多義性がかえって理解をさまたげることがある。

文が短くても誤解のおそれがないならば、文が短いほうがよいことは言うまでもない。
誤解のおそれがないかどうかを見極めるには、トピックに不案内な相手の思惟の進行を想像する能力と手間が必要である。

そのような手間をかけたくないときは、むやみに口語への言い換えは行わず、語の省略もしないほうが無難かもしれない。

具体的には、時間がない、それほど大切な相手ではないなどであれば、そんな手間をいちいちかけたくないとおもうだろう。

げに、相手への想像力とはすなわち愛である。

こうした、説明を受ける側が陥りやすい誤解への想像力を発揮することこそ、真に思いやりのある情報伝達姿勢であるといえるだろう。

そして、これは先天的なものでなく、努力によって獲得できる資質であると信じる。

そう信じてがんばっていきたい。

共パソのHexChatにユーザー名とパスワードを記憶しておかず、接続するたびに本人に打たせる方法

複数のひとが使うパソコンにHexChatを入れた場合、ユーザー名とパスワードを記憶させておくのは、当然本人認証のうえで好ましくない。
接続のたびに本人に打たせるのが望ましい。

それを実現させる方法。

HexChat 2.9.4 x86です。




Network Listで、Nick nameとUser nameに何か任意の文字列を入れておきます。




Networkの設定で、Use global user informationとし、サーバのアドレス・ポート・SSL・Character setを正しく設定し、テキストボックスをすべて空欄にします。



この状態でZNCに接続すると、パスワードが必要ですと言われるので、
/quote PASS <username>:<password>
または
/PASS <username>:<password>
を打たせます。

ここで

  • <username>はそのひとのZNCのUsername
  • <password>はそのUsernameに対するZNCのPassword

です。

Nick nameを空欄にすると、ZNCへ接続したあと、なぜか、チャンネルタブが生成されません。
IRC bouncerを使ってないなら、/joinの時点で生成されるでしょうから、空欄でよいでしょう。

User nameを空欄にしようとすると、さすがに、なんか入れろとおこられます。


ZNCからHexChatへは未読分のみを送るが、外出時にはもっと遡ったログが見られるように

ZNCのユーザーhirotaはスマホからつなぐ用とし、bufferをclearしない。

もうひとつ、ZNCのユーザーhirota_autoclearchanbufferを作った。bufferをclearする。HexChatからアクセス用。
znc 内で keepbuffer on と off なものを作る - @soh335 memo
http://soh335.hatenablog.com/entry/2013/01/29/170500
ZNCでLimeChatをIRCクライアントにしてiPhoneだけBuffer効かせる設定とim.kayacの設定 - さよならインターネット
http://blog.kenjiskywalker.org/blog/2013/03/20/znc-limechat-iphone/
のとおりのやり方。

自分で自分につなぐ存在って、何か本能的に暗闇の深淵を覗いたというか、畏怖心というか、セクシーさというかを感じます。(意味不明)

2014年9月12日金曜日

ブログを老眼対応

主に俺がつらかったので、
ブログの字をでかくしました。

その他ちょこちょこと文字がらみなどのデザインを変更。

CSSじかかぶせせずに変えれるのはこのへんまでが限度です。

2014年9月11日木曜日

HexChat:ZNCへ接続する設定と、クメール文字チャットに適した設定

備忘録。
HexChat 2.9.4 x86版です。

日本語インタフェースへ切り替えも可能です。
が、僕は、社員機への導入に備えて勉強のため、英語インタフェースのまま作業しています。
ですので説明も申し訳ありませんが英語版インタフェースで。
画面キャプチャなるべく載せますので、ウィンドウ内の位置で照らし合わせることができるでしょう。

○ZNCへ接続する設定

ZNCを介してIRCdにつなぐ場合、サーバ設定は、次のようにします:




  • Servers:ZNCがあるサーバのアドレスと、ZNCがlistenしているportを、/で接続します。
  • User name:ZNCのUsername
  • Server password:ZNCのPassword
  • Nick name:ZNCが覚えているので入力要らないようなものですが、入力しておかないと、なぜか、入っているチャンネルのタブが生成されてくれません。
  • Use SSL for all the servers on the network:ZNCがSSL接続を受け付けているならチェック
  • Accept invalid SSL certificate:ZNCのSSL装備がナンチャッテな貴方に
  • Character set:UTF-8(Unicode)をおすすめします。21世紀にもなってSJIS使ってる悪い子いねが!


○stickychan

HexChatって、ウィンドウの右下に、すごく押しやすい所に、×印があります。
押すなよ! 絶対押すなよ!
と言わんばかりです。
僕、期待に応えてうっかり押してしまい、チャンネルから抜けてしまいました。
チャンネル作った人間が、独裁権力を握ったままチャンネルからお亡くなりになられてしまうと、とくにZNC使ってる場合、国民皆殺しにせねばならなくなり、面倒です。
ZNCのstickychanモジュールの利用をおすすめします。

○スクロールバック


PreferencesのLoggingで、Scrollback linesを500から100000に。

HexChatには、スクロールバック機能があります。
デフォルトでオンになっています。
HexChatから入ったひとには、べつに感動するようなことでもないとおもいます。
ところがなんとLimeChatには、この機能がないっぽいのです。

この機能がないと、たとえ自分が使うクライアントが1個であっても(パソコンから入ったりケータイとかから入ったりしない)、ZNCのAuto Clear Chan Bufferをオフにしないといけなくなります。
クライアントがローカルにログを取る機能を持っているのに、それを使わずに、接続するたびにサーバから大量のログを転送させるというのは、非常に馬鹿げています。
あまりにも、当然あってしかるべきと感じる機能なので、無いというのはちょっと信じがたかったです。
たぶん本当はLimeChatにもスクロールバック機能があるんじゃないかとおもいますが、僕は見つけられませんでした。
ネット上でも使ってるひと見つけられませんでした。

スクロールバックの行数は、デフォルトは500になっています。
100000より大きい値を入れると、勝手に100000になります。

○クメール文字チャットに適した設定



PreferencesのAppearanceで、Main fontをConsolas 10からKH Content 14に変更。



Advancedで、Alternative fontsを「MS PGothic,Arial Unicode MS,Lucida Sans Unicode,Unifont」に変更。

このように、メインのフォントをクメールフォントにしておき、代替フォントを和文フォントにします。すると、クメール文字が上下の高さを取る分、行送りが自動的に広くなります。
もし、逆に、メインのフォントを和文フォントとし、代替フォントをクメールフォントとすると、行送りが狭いままとなり、クメール文字の上下が切れてしまいます。

文字サイズを10 ptから14 ptに上げたのは、僕が老眼なので、こちょこちょしたクメール文字を10 ptで見るのがつらいからです。お好みで…。

○和文インライン入力



入力欄で右クリックしてInput MethodsからWindows IMEを選択すると、和文がインライン入力できるようになります。



和文とクメール文字の混ぜ打ちもフツーにできます。
文字の大きさも相対的に同じに見え、自然です。
別にHexChatから入ったひとにとっては「だから?」ってカンジだとおもいますが。
Skypeチャットから来た人間にとっては感動的です。

Input Methodsは、HexChatを起動するたびに、System (Simple)に戻ってしまいます。
これのままだと、和文はインライン入力になりません。

HexChat 2.9.4で和文インライン入力またはクメール文字入力を可能にする

あえて最新版でなく、しかもserver-time対応になったのは2.9.6なのに、なぜ2.9.4などをインストールしたのか、理由を明かすと叩かれるので特に秘す。
2.9.5 released – HexChat
http://hexchat.github.io/news/2.9.5.html
を見て察してください。

HexChat 2.9.4 x86版をインストールして使ってみたところ、和文入力がインラインにならないという現象に直面した。

  • MS-IMEでも
  • Google日本語入力でも

どちらでもダメ。

ぐぐったところ、
Microsoft IME keyboard input does not render in textbox · Issue #1124 · hexchat/hexchat · GitHub
https://github.com/hexchat/hexchat/issues/1124
にヒントを得た。
古いGTKによるテキストボックスは和文インライン入力に対応していないようだ。

たぶん最近のバージョンのHexChatには、GTKも新しいバージョンのが入っていて、したがってこういう問題ももう起こらなくなっているのだろうなぁ~。

適当メモ - maple4estry - >> Pidgin for Windows でいろいろなメッセンジャーを便利に使う
http://www.geocities.jp/maple4estry/gaim.html
を参考に、やってみたら、うまくいった。

しかし、これをやると、Khmer Unicode Keyboard (NIDA 1.0)によるクメール文字入力がまったくできなくなってしまうという問題に直面した。

和文インライン入力もでき、かつクメール文字も可能になる設定方法が、どうしても見つからなかった。

  • 和文インライン入力を可能に(クメール文字入力はできない)
  • クメール文字入力を可能に(打てないキー5種あり。和文入力はインラインにならない)

のどちらかになってしまう。

タイトルが「または」になってるのはそういうことです。

以下、方法を記しておく。
HexChatはデフォルトパスにインストールされているものとする。


  1. C:\Program Files\HexChat\lib\gtk-2.0\2.10.0\内にimmodulesフォルダを作成し、imime 0.1.2のim-ime.dllをその中へコピー。
  2. C:\Program Files\HexChat\etc\gtk-2.0\内にgtk.immodulesファイルを作成し、中身を次のとおりにする:


○和文インライン入力を可能にしたい場合(クメール文字入力はできない)


"C:/Program Files/HexChat/lib/gtk-2.0/2.10.0/immodules/im-ime.dll"
"win32ime" "Windows IME" "gtk20" "" "*"


○クメール文字入力を可能にしたい場合(打てないキー5種あり。和文入力はインラインにならない)

"C:/Program Files/HexChat/lib/gtk-2.0/2.10.0/immodules/im-ime.dll"
"win32ime" "Windows IME" "gtk20" "" "a"


和文インライン入力が可能になるほうのgtk.immodulesの中身は先人の丸パクり。

クメール文字入力が可能になるほうのgtk.immodulesの中身は、最後の*を*以外にしてみただけ。
どういう原理かはわからない。
そもそもこのファイルの記述規則を見つけることができなかった。
なので、まったくむやみやたらにいろいろ内容を変えてみた。
が、やってみた限り、どうやっても、和文インライン入力もでき、かつクメール文字も可能になるようにすることができなかった。

しかもクメール文字入力では、

  • 「Shift-A」(アム、オアム、エア)= a + Shift-M、
  • 「Shift-:」(オッ、ウッ) = o + Shift-H、
  • 「Shift-V」(エッ) = e + Shift-H、
  • 「,」(オム、ウム) = u + Shift-M、
  • 「Shift-,」(オッ、ウッ) = u + Shift-H

の5種のキーが正しく打てない。
キーによって、Shiftを押してないときの入力結果になってしまったり、無反応だったりする。
Issue 656 - ibus - Typing in Khmer unicode misses 5 letters - IBus - Intelligent Input Bus - Google Project Hosting
https://code.google.com/p/ibus/issues/detail?id=656
に書かれてるとおり。
ただし幸い、5種いずれも、それぞれ右辺に示した2ストロークの短縮入力である。
なので、右辺の2ストロークによる入力へフォールバックできる。
したがって、この不具合により一部のクメール文字が打てなくなってしまっているということはない。

これらの問題について答えがないかぐぐってみた。
が、GTKに対して、Pangoのクメール文字対応はまだですかと聞いてる方はいるが、IMのクメール文字対応はまだですかと聞いてる方は見当たらなかった。
余談だがPangoでググると同名のタイの美少女がひっかかりすぎて
PIC : คุณยังจำ 'แป้งโกะ' ได้ไหม =) - Dek-D.com > มีรูปเด็ด > รูปคนน่ารัก
http://www.dek-d.com/board/view/2216523/
まったくもって捗らない。
もゑ~

とりあえず自分の環境は、クメール文字入力が可能なほうの設定にしておきます。
和文がインライン入力じゃないのは、まあ慣れます。

  • とくにGoogle日本語入力の場合、未確定内容は画面左下端に表示されるので、入力欄からそう遠くないし。
  • MS-IMEは画面左上端なので、入力欄から遠いけど。


社員用のIRCクライアントとしてHexChat 2.9.4を採用する場合には、当然そちらも、クメール文字入力が可能なほうの設定にしておきます。
ほとんどのカンボジア人社員は日本語できませんので、和文打つことありませんので。

---
(2014.9.11 21:32追記)
上記のgtk.immodulesもimimeも入れない状態で、入力欄で右クリックしてInput MethodsからWindows IMEを選択したら、和文インライン入力もできて、かつクメール文字入力もできるという状態になりました。
この記事でさんざん書いた苦労と懊悩はいったい何だったのでしょうか。
Input MethodsがSystem (Simple)のままだと、クメール文字入力はできるけど、和文はインライン入力になりません。
ただ、Input Methodsのデフォルトの選択肢を設定しておく方法は見つからないです。
なので、HexChatを立ち上げるたびに、毎回、和文入力をインラインでやりたい気分になってしまったら、Windows IMEを選択する必要があるっぽいです。