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/
のとおりのやり方。

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