2018年版コミュニケーションメディア 所感

eメール

最近はeメールを使う人は本当に減ってしまったようで、個人的なやりとりに使われることは現状ほぼない。

特段見くびるほどの欠点があるわけではないと思うのだが、実際のところレガシーな使いづらさというのは存在する これはどちらかというとソフトウェア実装上の問題である。

ただし、柔軟性に関しては最も優れている。 オープンで共通の仕様という意味では被験するのはXMPPくらいのもので、 この点を理由にeメールを扱いたい理由はある。

若い人の場合、大学生、あるいは大学卒であればeメールは扱えるが、 そうでない場合は扱えない傾向があるようだ。 また、eメールを扱う場合でも、特定のアプリとアカウントが紐付けられた状態(LINEのような状態)で認識しており、使い方は理解できていないというケースが目立ち始めている。

LINE

依然として日本においてデファクトスタンダードの座を譲らないLINEである。

アプリの使いづらさはある程度改善されつつあるのだが、Windowsアプリ版の使いにくさには批判が多いようだ。 また、アプリの種類によって機能が異なる点は単なる使いづらさになっている。

モバイルアプリ版に関してはヴォイスメッセージ機能が秀逸である。 トーク画面でヴォイスボタンを押している間に発した言葉が送信される。 あまり活用されていないようだが、非常に優れた機能といっていいだろう。(LINEが初なのかはわからないが)

メッセージ消去機能がついたが、Skypeと比べれば証拠消しなどには使いづらく良心的だと言えるだろう。 直前消去だけで良いのではないかという気がするのだが…

通話品質はあまり改善がみられず、非常に切れやすい。

LINEが優れている点はわずかだが、普及とスタンプという蓄積要素があるため、乗り換えも容易ではないところまできたように感じる。

Kakao Talk

混沌の時代に現れ、様々な雑な対応でユーザーを失ったカカオトークだが、 その混沌と荒野、そして雑さをついて出会い系利用に拍車がかかった。

直接的にIDを交換するケースもあるが、他の出会い系メディアからの連絡手段交換として利用されているようだ。 出会い系、というとソフトにきこえるが、ほぼ売春・援助交際目的である。

そして、それ以外の用途というのはあまり利用されていないことから、 「インストールすることでその人の素行品性が問われる」という状況にあるといっていい。

Skype

Microsoftに買収されてから改悪を続けるSkype。 5.4になってからレビューを著しく落としたのは有名な話だが、それ以降さらなる改悪を続けている。

まず、コンタクト機能がなくなった。 電話帳利用を強制しており、利用しない場合はコンタクト機能が存在せず管理不能の状態になる。 チャットした相手は全て自動的にコンタクトがある状態になる、という仕組みだ。 電話知用機能のないLinuxの場合、「チャットをしたことのある相手一覧」という形式になる。

また、ステータス表示機能もなくなった。 これは一旦削除し、激しい批判を浴びて復活させたのだが、完全になくなってしまった。 これは今までは「モバイルアプリ版にはない」だったのだが、ステータス通知APIもろともの削除で、外部アプリを使った場合でもステータスは取得できない。

SkypeのSNS化進行も激しく、だいたいsnapchat化している。 Skypeのコンタクトにはあまり親しくない人も多いことから非常に困ってしまう。

通話品質も低下しつつあり、より通話品質に優れるアプリが登場していることから避けたいメディアになりつつあるようだ。

Telegram

LINEと類似の一通りの機能、無料のステッカー、ステッカー同様にGIFを利用する機能などなかなか魅力的だ。 また、LINEに追加されたヴォイスメッセージに近い機能(もうちょっと慎重)と、同様に利用できるビデオメッセージも利用可能だ。

だが、致命的なのはWhats Appを意識しているのか、「電話番号と本名を前提としている」ということだ。

基本的にユーザー検索時はファーストネームと電話番号が必須である。 裏技として、ユーザーIDだけわかっていればシークレットチャット開始→ID検索ということも可能だが、 検索結果に本名と電話番号が表示される。

検索を防ぐ設定はないので女の人などは非常に不安だろうし、 「電話の代わり」という仕様はWhats App同様いかがなものか。 「日本人は秘密主義すぎる」みたいに言われることがあるのだが、世界的に見てそんなに受け入れられている気はしない。 むしろアメリカ人が個人情報やプライバシーに無頓着すぎると思う。

通話機能はかなり切れやすく、快適ではない。

XMPP

依然としてXEP-180(ビデオ通話)に対応したクライアントがなく、どのアプリも快適にはほど遠い。

期待されていたJitsiに関してはそもそもXMPPをやめてしまったという状況だ。

モバイルアプリは最も有力なのはXabberだが、Xabberにしてもあまりデキはよくない。 重要な相手とのやりとりには使用できないが、あまり密ではない(取りこぼしがあったとしても構わない)ような相手とのやりとりには利用できるだろう。

「XMPPを利用している人は少ない」という前提のもと、「XMPPを利用できないレベルの人にXMPPでやりとりをできるようにする」という作業を行う状況というのが限定的すぎて現実的ではない。

ただし、メリットは全くないわけではない。 XMPPアカウントの取得は比較的容易で、XMPPのウェブクライアントも存在するためだ。

PCの場合はインストールも不要で簡単にXMPPで会話することが可能になる。

現実的にはスマートフォンでインストールもせずにチャットするのはかなり難しい。 だが、そのような人はおそらく会話する意思に著しく乏しいものと思われるので配慮するだけ無駄ではないか。

Jitsi Meet

Jitsi MeetはWebRTCクライアント+WebRTCサービスである。

一応、他のWebRTCサービスも利用できるようだ。

つながっている手段が通話機能を提供していない場合(たとえばTwitterなど)、あるいはその方法が適切ない場合に有効である。 特に個人情報を教えたり登録したりする必要もないのもメリットと言えるだろう。

Discord

Discrodが良いものであることは既に明らかだが、明確な欠点がある。 それは、アカウントの使い分けが困難だということだ。

PCならいくつか方法はあるのだが、Discordは活用ジャンルが非常に広く、通知を分けることもできず、特定のチャンネルに集中することも難しい。 別にDiscordに固有の問題ではないとはいえ、便利だからといってあれもこれも教えていると困ることになってしまう。

方法は色々ある(たとえばInvisibleにするとか)のだが、使い方に配慮が必要なのは確かだ。

通話品質は非常によく、現状ベストな選択肢である。

なお、招待すると「ゲーマー」のところにみんなひっかかるので、そろそろ他のことも書いてくれないか。

Slack

日本語版がリリースされ、CMも打たれたため、名前だけは知っているような状態になっている。

実際一般にそこまでSlackが広まった印象はないが、少なくとも提案したときに受ける抵抗は減ったように思う。

Slackはログを商売にしているが、あまり良い手ではないというのが一般の意見だ。 XMPPサポートをそれを理由に切ったことも批判的に見られている。

Slackは全体的にDiscordに見劣りするが、明確にDiscordより優位な点がある。 それは切り分けが容易なことである。ユーザー単位では認識されないし、チームは分離される。 常に適切なリージョンで分割できるというのはメリットといっていいだろう。

なお、Slack Webはスマートフォンでは利用できない。

Google Hangouts

品質はあまり変わっておらず、少なくともSkypeやLINEよりは良い選択肢といっていいと思う。

しかし、Googleアカウントが特定されてしまうこと、結果としてGMailもわかってしまうこと、Google+をやっている場合は自動的にGoogle+でもつながってしまうことなどFacebook Messanger同様の使いづらさが存在している。

Viber

楽天が取り込んでいるけれども、プライバシー面で改善されたという話は聞かず、 かなり不安な状況のままだ。

まとめ

  • Discordは良いもの
  • 仕事など限定された環境のつながりはDiscordでなくSlackで
  • DiscordとSlackの使い分けは大事
  • LINEやTelegramのようなプライバシーに関わるものをプライベートなつながりでないのに要求する人からは逃げよう
  • 親しい人とLINEを交換するのは妥当。ただし「その人が親しい人でなくなるリスク」とセットで考えないと、ブロック/削除しても可視性が残る
  • Googleアカウントでつながってしまっている人に関してはHangoutsというのも結構妥当
  • 「とりあえずXMPPアカウント交換しておこうかな」というのもまぁ妥当な判断
  • カカオトークはやめましょう。人間性の問題になる。
  • Telegramは現状、電話番号以上のプライバシーの塊なので、本当に親しい人とでないと困難
  • チャット機能に関してはTelegramかなり使い心地いい
  • 妥当というか無難なのはLINE。メッセージ到達性は一番優秀
  • メール侮るべからず
  • 匿名性を保ってつながりたいという人は、XMPPとJitsi Meetを提案するのが多分無難
  • そのうちチャットつくるよ
  • Mimir YokohamaはTelegramが対応済み。XMPPもそのうち対応します

凋落するソーシャルメディア

悪化していくTwitter

予てから迷走が指摘されていたTwitterだけれども、 従来アクティビティとして存在した、「ほかの人が他の人にいいねした」という情報などを通知に載せるようになった一方、 自分が引用ツイートされた場合については通知されなくなった。

従来、タイムラインに流していて大変不評だったのだが、いよいよ通知に流すようになったのだ。 Twitter側の主張としては、実際にそのようなツイートに対するリアクション率が高いから、ということなのだが、 設定すらできない強制である。

このようなノイズを強制する仕様はFacebookと同じである。

私はFacebookが好きではない。 他の人が知らない人にコメントしたとかどうでもいいし、知っている人に知らない人がコメントしたことに関してはもっとどうでもいい。 そのような関わり方で人と接したくないので、「Facebookで交流」はしないようにしているし、むしろFacebookからの通知はブロックしてすらいる。

しかしそもそもFacebookは元々そのような仮面をかぶった交流を前提としたものだからそういうものだと諦めてもいる(しあまりつかっていない)が、反Facebookで誕生したはずのTwitterがFacebookに倣うというのはこの上なく愚かな選択に見える。

そのようなしがらみや、「何を見るかを強制される」のはとても嫌なので、 より強くTwitterやめたいなと思うようになった。

Twitterが(従来から指摘していたことではあるものの)プライバシーの覗き見をしているということが問題になっていたり、Twitterでの言論が荒れていることも含めて、Twitterは心地よく、自分なりにいられる場所ではなくなってしまっている。

個人情報の扱いが危険なLINE

LINEの情報取り扱いに関する問題は随分昔から言われ続けているけれども、今回の利用規約改定で明示的にトークの内容の見ることを含むものに変更された。

これは、検閲しなければ不可能な内容で、しかもその内容の利用に対して非抑止的なポリシーを採用したものである。

このようなポリシーを採用するものをプライベートなやりとりに使用していて、いいのだろうか。

おまけ。Live.me

Live.meというライブストリーミングアプリがある。

SHOWROOMのような、「女の子が配信して視聴者男性が貢ぐ」スタイルの配信アプリだが、 問題が山ほどある

  • live.meというドメインはTwitchが持っている。便乗、あるいはユーザーを混乱させるものだ
  • アプリケーションが異様な権限を要求している。連絡先を不明なdestinationに対して送信している(配信サーバーではない)
  • 山ほどジャンク通知を送り、必要な通知をオフにすることはできるが、ジャンク通知はオフにできない
  • 退会の仕方が不明、退会できなくなったみたい
  • 課金額が非常に高い

なんらかの提携やインセンティブからレースクイーンの方たちはLive.meを使っているのだろうけれども、これはユーザーに対する負担が大きく、信頼性を損ねるものなんじゃなかろうか。 こういうところとは早めに縁を切ったほうがいいと思うのだけど。

ちなみに、中国KINGSOFTが展開しているらしい。中国語にも遭遇する。

アメブロから更新時に一部を抽出して通知する

私はかなりの頻度でアメブロのとあるブログエントリの更新をチェックしているのだが、ほとんどの場合重要な情報はそのごく一部である。 しかし、アメブロにスマホでアクセスするたびに、くだらない広告や関心のないTV出演者の話に通信量が割かれ、時間も割かれることを大変に腹立たしく思っていた。

そこで、PCからページを取得し、スクレイピングする方針で考えたものである。 スクレイピングした内容はDiscordで通知する。

具体的な内容は差し障るので抽象化する。

コード

解説

「アメブロから」という難しさ

ユーティリティスクリプトでは「問題自体を可能な限り引き下げ、ゆるく解決する」のが重要である。 開発コストを下げるべきなのだ。

amebloの内容を見ると、独特なエディタから生成されるものだけに、エディタ上での記述はちょっとした違いで大幅に異なるHTMLコンテンツが生成される。 私は投稿者とは連携していないので、ちょっとした記述のブレで抽出すべきコンテンツを見失う可能性がある。

生成されるタグと比べると見た目上の違いは少ない。 言い回しの違いや、スペースの有無程度である。

そこで、w3mを活用する。w3m-dumpオプションは、見た目に近い形でレンダリングした上でテキストにして出力する。 アメブロの執筆者はエディタ上の見た目で書いている可能性が高く、このようにレンダリングしてしまったほうがブレは抑えられる。

その中から情報を抽出する。 ある正規表現に一致する行、またはある正規表現の範囲をアドレスとして出力すれば多くの場合は十分だろう。

続くエントリや広告のゴミ値を拾ってしまわないように、エントリ終了時にはSedを終了させる。 多くの場合、/^AD$/で良いかと思うが、/いいね!した人.*リブログ/というパターンも考えられる。

例えばおやつ工房 ひびのやをdumpした結果からメニューを取得するとすれば、筆者はメニューの表記前に本日のメニューは、という行を置く習慣があるようで、またブログの締めとして本日もよろしくお願いいたしますを置いている。 これに基づけば

メニューそのものを抽出するならば、で囲むようにしているようなので、そこに限定しても良い。

しかし、どうもこれは項目であるようだから、メニューとしては成立しないかもしれない。 項目終わりは空行を空けているようなので、この項目から空行まで抽出してみよう。 一応、スペースを入れていた場合にも対応しておく。

しかし次のようなケースが発見された。

*天然酵母パン*
⚫︎食パン1斤→焼き上がりました
自家製カボス酵母、春よ恋使用。
乳製品不使用のシンプルなパンです。国産のお粉の素朴な風味をそのまま味わっていただけます。 

⚫︎レーズンとくるみのパン→焼き上がりました
自家製レモン酵母、春よ恋使用。

⚫︎カンパーニュ →焼き上がりました
自家製ラ・フランス酵母使用。
ライ麦粉と全粒粉を配合。

なので、項目開始だけでなく小項目開始も受け入れることにする。

結果次のように抽出できた。

*マフィン*
プレーン⬇
ポップシュガーに戻しました。
きのこみたい

*シフォンケーキ*
プレーン小

*天然酵母パン*
⚫食パン1斤→焼き上がりました
自家製カボス酵母、春よ恋使用。
乳製品不使用のシンプルなパンです。国産のお粉の素朴な風味をそのまま味わっていた
だけます。 

⚫レーズンとくるみのパン→焼き上がりました
自家製レモン酵母、春よ恋使用。

⚫カンパーニュ →焼き上がりました
自家製ラ・フランス酵母使用。
ライ麦粉と全粒粉を配合。

日付も入れるならば、投稿時タイムスタンプの行を追加しよう。

/[0-9]\{4\}-[0-1][0-9]-[0-3][0-9] [0-2][0-9]:[0-5][0-9]:[0-5][0-9]/ p
/*.**\|^⚫/, /^\s*$/ p
/^AD$/ q
//いいね!した人.*リブログ/ q

なお、サンプルとして「ameblo 本日のメニュー」で検索して最上位に出たおやつ工房 ひびのやさんを使わせていただいた。 埼玉県越谷市にあり、東京スカイツリーライン大袋駅、せんげん台駅が最寄りとなる、パンとお菓子のお店だそうである。11時から18時営業、金曜日休業。

更新されたかどうか

単純に考えれば取得したページをteeで保存して比較したいところだが、 広告などランダムに生成される部分があるため、これは失敗する。

amebloはDateヘッダを含み、Content-Lengthヘッダを含まないため1、ヘッダ部分だけ保存するという方法もある。 curl--dump-headerを使用し、内容は捨てるという方法が良いだろう。

もうひとつはそもそも抽出した内容を比較するという方法がある。 リクエスト回数が減るため合理的だ。

いずれにせよ、前回取得分をローテーションして、今回取得分と比較する。

diff -q ~/.cache/someameblo/header ~/.cache/someameblo/header.prev > /dev/null

通知する

今回の場合、Discordのwebhookを使用している。

Twitterという手もある。ここではtwを使用する。 セルフDMの送信自体は可能だが、Twitter webや公式アプリでは確認/通知はなくなっている。

LINE Notifyという方法もある。

メールが配送できる環境からであればMMS宛というのも悪くない

ジョブスケジューラによる定期実行

スクリプトを書いても手動実行するというのはちょっとださい。 ジョブスケジューラによって自動的に実行してほしいところだ。

anacronあたりを使うのが妥当なのだろうけれど、私はSystemd Timer (User)を使用することにした。

まずはserviceユニットを書く。 ここでは~/.config/systemd/someameblo.serviceを作成している。

[Unit]
Description=Get ameblo entry.

[Service]
Type=simple
ExecStart=/bin/zsh "/home/aki/opt/someameblo/getamebloentry.zsh"

[Install]
WantedBy=default.target

次に対応したtimerユニットを書く。 ここでは起動から10分で初回実行し、それ以降4時間ごとに起動している。

[Unit]
Description=Get ameblo entry.

[Timer]
OnBootSec=10min
OnUnitActiveSec=4hour
Unit=someameblo.service

[Install]
WantedBy=timers.target

ユーザーユニットをリロードする。

タイマーを起動&有効化

「ゆるい解決」について

このようなユーティリティは基本的に人間を補助するものである。 オートメーションに属するものの、このユーテリティが人間に無断で何かを決断するわけではない。 また、人間にとってこのユーテリティによって与えられる唯一絶対の情報というわけでもない。

できるだけ精度が高ければ嬉しいけれども、もしも例外的ケース(例えば著者が普段とはまるで違う書き方をした場合など)においてうまく機能しなかったとしたならば、それは単に普通にブログを見に行けばいいだけである。 例外的ケースにおいて問題が発生しないように設計し、成功しない可能性については許容する。

同様に情報が常に完璧なフォーマットであることを求める必要もない。 ソースが完璧なフォーマットで書かれない可能性は高いので、完璧を求めることは不毛である可能性が高い。 これもまた、不十分な情報となったときには自らブログを見に行く選択肢もあるのだ。

ただし、十分に機能させるためには、抽出条件はfalse negative(取りこぼしがある)よりはfalse positive(ゴミがはいる)ほうが好ましい。 ゴミがあっても無視すればいいが、取りこぼしがあると必要な情報が損なわれる可能性があるためだ。

プログラミングはプログラムを書くことよりも、どのようにアプローチするかということのほうが重要な場合は少なくない。 プログラミング初級者のうちは設計をないがしろにしがちだが、プログラムの出来や困難性はだいたい設計によって決まる。 今回の主題も、正攻法ではかなり難しい条件を、考え方を変えることで簡単な問題に変換しているということだ。


  1. あるいはcurlがContent-Lengthを含まないのかもしれない

Discordを使ってみた

Discordというアプリを知っているだろうか。 まぁ、だいたいの人は知らないだろう。

簡単に言えばSkypeのようなメッセンジャー+通話アプリであり、Discordは大声で「Skypeを投げ捨てろ!!」と言っている。 だが、単純にSkypeのようなアプリというわけではない。 ものすごく乱暴に言えばSkypeのような機能と、Slackに通話機能をつけたものを一体化させたものである。

通話とメッセージングのソフトウェア(例えばSkypeやLINE)と比べると結構複雑だ。 これは「2つの側面がある」と考えてもらうと良いだろう。

Slack的な部分

だが、まずSlackを知らない人が圧倒的に多いだろうからそこから説明しよう。

Slackは簡単にいえば共同作業用のチャットツールである。 「Slackのアカウント」というのは基本的に存在せず、「チーム」というのがその単位となる。 「チーム」はメンバーを招待することができ、招待された人はそのリンクを使ってメールアドレスを登録するとそのチームのメンバーとなることができる。 チームでの活動は、チームのアドレス、またはチーム名とメールアドレスを使って行う。

メンバーにはプロフィールがあるが、プロフィールもチームごとに設定する必要がある。 逆にいえば、チームの性質によって異なるプロフィールを使うことができる。 メンバーにはロール(役割)を与えることができ、メンバーを追放する、チャンネルを作成するなどの権限を分けることができる。

チームにはチャンネルがある。 全体の発言は#generalというチャンネルで行うが、チャンネルを作成すれば、話題を分けたり、閲覧できるメンバーや発言できるメンバーを制限することができる。 基本的には議題ごと、あるいはチーム内のメンバー区分ごとにチャンネルでやりとりをすることになる。 メンション機能もあるが、これは特定の人だけにメッセージが届くわけではなく、特定の人に通知を飛ばすだけである。 ユーザーグループというのもあるが、これはメンションを飛ばす時に複数人をまとめて書いたり、チャンネルに加えるときにまとめて書くための機能。

Slackは主にIT企業の業務で使われていて、ビジネスツールというニュアンスが強い。 社内でのやりとりとしてはメールなんかよりよっぽどいいのは確かだと思う。

ただ、逆に言えばそれ以外では全然使われていない。もともとゲーム用のツールだったなんてことは、ほぼ忘れ去られている(私も知らなかった)。

しかし、実のところ、マメ派のカップルにはかなり良いと思うのだ。 デートの予定やイベントの計画、今日の買い物といった話題をLINEでやりとりしていると、どんな話をしていたか確認するのが大変になってくる。 LINEはログをさかのぼりにくいし、ノートに立てていればいいのだが、LINE for Chromeはノート機能がなかったりするし、明確に議題を定めてから話がはじまるとは限らない。 そもそもノートも増えてくると議論には向いていないことになる。 なので、Slackで#date, #event, #todoなどチャンネルを作っておけばスムーズにやりとりや確認ができてとても便利だ。

ところが、LINEを投げ捨ててSlackにいけない理由がある。 まず、割とSlackの通知はまちまちで、あまりリアルタイムではこない。マメ派カップルにとっては割と致命的だ。 しかも通話機能もない。ラブラブなカップルにとってはますますもって致命的だ。

ここでDiscordである。

DiscordはこのあたりはだいたいSlackと同じだ。 大きな違いとして、Slackで「チーム」と呼んでいるものは「サーバー」という名前に変わっている。 そして、通話機能がある。

通話機能がちょっと独特で、1名でも通話をはじめられる。 チャットのように(特にIRCのように)、「通話チャンネルに入っている人が自動的に通話する」という方式だ。 途中参加もできるし、途中離脱もできる。というか、最後ひとりになっても勝手には切れない。 通話チャンネルも複数作ることができる。

また、雑音を積極的に検出し、しゃべっていない時はマイクを切るようになっている。 プッシュトゥトークにすることもできるので、大勢参加していてもノイズまみれにならないようになっている。 これは便利だ。

また、SkypeやHangoutsのグループトークにない機能として、ユーザーごとに音量設定できる。 声の小さい人を大きく、声の大きい人を小さく。好きな人を大きく、嫌いな人を小さくすることが可能だ。

そして重要な違いとして、Slackと違ってちゃんとすぐに通知がくる。

Skype的な部分

だが、Discordの場合はユーザーアカウントがある。

そのため、複数のデバイスでDiscordを使用した場合、自分が参加しているサーバーはすべて一覧されるし、招待するときはユーザー名とDiscord番号の組み合わせで行う。 フレンド登録もできる。プロフィールや名前もサーバーごとというわけではない。

さらにフレンド登録すると、ダイレクトメッセージとダイレクトコールが可能になる。 これはSkypeやLINEのように、人単位でメッセージを飛ばしたり、通話したりすることができるのだ。

ただし、Skypeにあるビデオ通話や画面の共有は、実装予定の機能となっており現在はない。 これを書いている今日テストがスタートしたようだが。

また通話手順がちょっと複雑だ。Discordがフロントにある場合は普通に通話がかかってくる。 ただし、通話をかけた側は通話画面にはならず、右下にあるVoiceの矢印で開かなければチャット画面での通話になる。 これは通話を受けた場合も同様。

また、通話を切っても残った側の通話は自動的には切れない。これはサーバーの場合と同じである。

なんらかの理由で最初からチャット画面に変遷した場合(通知から飛んだ場合などだ)、まずDM画面にいき、JOINをタップしたあと、Connect to Voiceを選択しないと通話に参加できない。 これはなかなかややこしい。

グループDM機能があり、これは招待もなにもなく、グループDMを作成すると招待された全員が自動的に参加する。 グループDMはフレンドリストに登録される。グループから退出したり、グループに追加で招待することは可能。 退出してもすぐ招待されるようなことが起きるとちょっと面倒。最後のひとりになってもグループ自体は消えない。

スタンプ機能はない。写真埋め込みは可能。

Slackに対するメリットとして、日本語に対応している。 Slackが便利でもインターフェイスは英語に限られていたSlackは敷居が高いという人が多かった。

また、ちゃんとしたクロスプラットフォームアプリがあるということも大きい。Slackの場合はアプリケーションもいまひとつだ。

また、Slackのように有料プランがあって、機能が制限されているというわけでもない。

もっと便利な部分

Discordはゲストログインが可能で、サーバーを作ってアドレスを伝えれば、相手がDiscordのアカウントを作らないまま通話することができる。 しかもDiscordにはWeb版があるので、共通の通話可能なアプリがない、あるいはアカウントを教えたくない場合でも通話することが可能だ。 かなり特殊な要求だとは思うが。

残念な部分

通知のオンオフはできるのだが、通知音は変更できない。

ゲーマー向け

Discordがゲーマー向けということで、ゲーマー以外で使っている人をみかけることがない。

オンラインゲームでは多人数協力プレイができたりするので、通話しながら意思疎通ができたほうがスムーズにプレイできるのだ。 従来はSkypeを使っていたようだが、最近SkypeがどんどんダメになっているのでDiscordに移っている人が多いらしい。

だが、微妙にバグはあるが、SkypeもLINEもXMPPも投げ捨ててDiscordで生きていけるくらいには便利である。 実用上の話であって、かわいいスタンプが好きな人は辛いかもしれないが。

ゲーム中は特に言うことがなければ黙っているだろうし、発言者のみ聞こえるようになっているのはこのためだろう。 割とキーノイズもするわけだし。

バグ

3つのバグを発見した。

通話通知がおかしい

P02E(Android 4.1.2)だと、通知音が通話でもメッセージのものになってしまい、一度鳴るだけで終わってしまう。

アプリを殺すと通知されない

CM Securityでクリーンアップしてしまうと通知は届かない。 これはNotifications wake up device.をオンにしていてもダメだ。

なかなか恐ろしい通話ループ

  1. AがBに書ける
  2. Bが出る前にAが切る
  3. Bが通知エリアから通話に出る
  4. BにAからかかってきたと表示される。「出ない」ことができない
  5. Bが通話に参加するとAに呼び出しがかかる。こちらも「出ない」ことができない
  6. BがAが出る前に切ったら立場を入れ替えて3にループする

みんなDiscordしようぜ

良い点

  • SlackとSkypeの合体とか超魅力
  • 日本サーバーのないWebRTCとは思えないほど音が良い
  • Windows, Mac, Linux, Android, iOSに対応
  • ちゃんと通知される
  • 画像も貼れる
  • グループDMやグループ通話もできる
  • Skypeよりはるかに軽い
  • 話題を分けて整理することができる
  • グループの中で特定の人に呼びかけることができる
  • 運営が透明で技術的にも透明
  • 登録も簡単でゲスト利用も可能、個人情報も要求されない

悪い点

  • 若干複雑
  • ちょっとバグがある
  • 通知音の設定ができない
  • 個人情報もいらないので尻尾切りのような残虐行為が気軽にできてしまう
  • キモいスタンプが使えない

メッセージングアプリ/連絡手段 with スマートフォン/フィーチャーフォン/PC 2016

まえがき

今やネットはリアルの延長線上にある、という考え方の人が多いようです。いわゆるウェイというやつでしょうか。

そんなリア充であるならば連絡も電話やLINE、Twitterなど皆と合わせれば良いだけで悩む必要はないのでしょう。
しかし、我々はまだ慣れない相手と距離感を測りながら恐る恐る連絡先の交換を提案することだってあるの
です。(特に女性と連絡先を交換するのには勇気が必要でしょう)。

おそらく、Twitterは無難な選択です。
ふたりきりではないから警戒心を抱かせにくく、気詰まりもしません。会話が切れてもそれほど気になりません。
しかし、むしろ発展を阻むかもしれませんし、Twitterだけは見せたくないという人もいるでしょう。また、それがビジネスの相手ならばTwitterは完全にプライベートだという人もいるでしょう。

LINEを聞いてみたものの、やっていない、あるいはLINEは教えたくないと断られて勇気をへし折られた人もいるかと思います。

新しい人との出会い、つながりを活かし、相手をよく知るためにも、いかにして会話するかということは重要なことであると思います。そこでLINEか電話しか思いつかないようでは、いきなり詰んでしまうかもしれませんしね。

ここでは電話を除き、1:1で任意のタイミングで連続的に会話できるインスタントメッセンジャー/VoIPアプリを中心に検討したいと思います。

インスタントメッセージングとメッセージングアプリ

現存する最古のアプリケーションプロトコルはFTPです。つまり、ネットワーキングの原始とは「ファイルのダウンロード」でした。

しかしプロトコルこそ異なれど、1965年にはeメールが実現しており、それどころかeメールの発明など17世紀です。
インターネット以前、UUCPやバソコン通信の時代においては、ファイルのダウンロード、eメールでのやりとり、メーリングリストによるディスカッションが主な用途でした。

そして、インターネット以前にもうひとつ重要な役割を果たしたのがIRCです。1988年誕生、チャットという文字をベースにしてその場で即時やりとりをするという方法はインターネット以前に既に存在していました。今やインターネットを支配するウェブ(1991年発明)よりもはるかに早く、人々がいかにコミュニケーションを渇望していたかが感じられます。

いわゆるインスタントメッセンジャーの誕生はおそらくは1996年のICQだと思われます。
マルチユーザーのタイムシェアリングシステムにおいてやり取りする方法はtalk(1)などもあります。こちらは1970年台には既に存在していました。
1980年代から1990年代初頭にかけて大変人気があったのですが、それはUnixユーザーの間だけでの話で、一言でいえば「ハッカーたちの超マニアックなおもちゃ」でした。

確かに、eメールも手紙などよりはるかに早いですし、議論したければメーリングリストが、おしゃべりしたければIRCが(そしてHTMLチャットが)ありました。
しかし仲良くなったメーリングリストの仲間やIRCの友だち、あるいはペンパルと気兼ねせず、いつもすぐそこにいるかのように話したい、という願いは日増しに大きくなっていったのでしょう。
メーリングリストやIRCの愛好家ならtalk(1)くらい使えると考えられますが、WWW発明以来インターネットでのコミュニケーションはもっとカジュアルになりました。talk(1)ではあまりに難しすぎます。

そこで普通な人(当時ネットをしていた人が普通だとは思わないけれど)が普通に使えるものとしてICQが誕生したわけです。
ICQがあれば、その人と話したいと思った時に気軽に話しかけることができ、互いにオンラインになった時はすぐにでも二人でおしゃべりに興じることができます。

「特定の場所にいかなくても相手のことが通知され、いつでも話しかけられる2人のチャット」というのはコミュニケーションの世界を大きく変えました。そしてそれは、不可欠なものへとなっていったのです。

とはいえ、その時代にインターネットを利用している人というのは、それなりにマニアックな人でした。
しかし日本ではまた別のムーブメントがありました。

この素晴らしさは、主に女子高生と女子大生がハッカーたちと同時期から知っていたのです。それは「ポケベル」でした。ポケベルにはじまった新スタントシグナル文化はPHSとなった時わずか20文字のカタカナ(JIS-X0201)という制約の中でインスタントメッセージングへと進化したのです。

ケータイは進化し、eメールに対応しました。そして、ケータイメールはわずか20文字のPメールから、
JIS-X0208に対応し漢字も使えるeメールに近い感覚のものへと進化しました。
ケータイメールが文字で普通に会話できるとなれば、授業そっちのけで送り合う人があらわれるのも必然。
女子高生たちは「いつでもできる文字でのおしゃべり」に夢中になりました。

しかしケータイメールならそうやっておしゃべりできるのにeメールではできない。でも自分はDDIで友だちはJフォン…なんてことはよくあったもので、その要望にキャリアはeメールの到着を電話回線でプッシュ通知し、eメールを受信させてしまうという大胆な方法で叶えました。

これでケータイメールでもeメールでも、いつでも、どこでも、文字でおしゃべりができるようになりました。しかも、相手の状態は気に書けず話しかけたい時に話しかけられます。

この進化は続いたのですが、突然に断絶が訪れます。

1996年のSimon以来、ビジネス用に超小型パソコンに通信機能がついたものであったはずのスマートフォンが、2007年、iPhoneの登場によって突如脚光を浴びます。
女の子たちはこぞってiPhoneを買い求め、フィーチャーフォンを見下しスマートフォンを賛美することが正しいことであるという世論が形成されました(主にメディアの手で)。

しかしながらスマートフォンはキャリアメールをすることができず、コミュニケーションという意味では重大な後退となりました。

韓国でも似たような状況だったのでしょうか。それとも、スマートフォンの普及でSMSが身近になったことでSMSに対する不満点が出たのでしょうか。
2010年にViberとカカオトークがリリースされ、チャット感覚で会話できるようになりました。
それはインスタントメッセンジャーのスマートフォン流解釈でもあり、SMSのような「連続するメールの感覚」でもありました。

それは従来のキャリアメールの望ましい姿に見えたのでしょう。一日片道300通をこえるメール、3分以内の返信という熱心さから熱望された「返事がないとき、相手が読んだかどうかを知りたい」という熱望を叶えるという点でも既読機能のあるLINEが受け入れられた理由なのではないでしょうか。

パソコンよりもスマートフォンが主流となる中、パソコンでのインスタントメッセンジャー、スマートフォンのメッセージングアプリ、無料通話ができるVoIPアプリが交差していきました。そのため、インスタントメッセンジャーは淘汰される一方、これらの性格は類似してきましたが、やはりその出自は今も影響を及ぼしています。

ちなみに、ドコモがはじめたケータイの「絵文字」はとうとう世界統一の文字コードであるUnicodeにおいて大量導入され、「文字」という概念を極度に拡張するほど世界に影響を及ぼしています。

オープンプロトコルとプロプライエタリプロトコル

XMPPはオープンな仕様のコミュニケーション・プロトコルです。

といってもよくわからないでしょう。

一般的にはメッセージングアプリはその通信方法や通信相手はそのメッセージングアプリの提供者専用のものになります。
LINEアプリは裏ではLINE語を話し、LINEサーバーと通信します。SkypeアプリはSkype語を話し、Skypeサーバーと通信します。LINEを使ってSkypeの友達に連絡することはできません。

このうち、「LINE語」「Skype語」と言っている部分がコミュニケーション・プロトコルの話です。
LINEでやりとりする方法は基本的にはLINEアプリですが、LINEアプリではないけれどLINEでやりとりできるアプリも存在はしています(ただし、これは規約に抵触します)。
こうしたアプリはLINE語を話し、LINEサーバーとやりとりするのですが、プロプライエタリプロトコルの場合は、「LINE語」がどんな言葉であるかということが秘密にされていますから、開発者はそれを調査することによって分析し、それっぽく振る舞うアプリをつくっているということになります。

XMPPは逆に、どんな言葉なのか、ということがはっきりと書かれています。
ですから、サーバーが受け入れてさえくれれば、XMPPに対応したどんなアプリを使っても構いません。
LINEだったらLINEアプリを使うしかないのですが、XMPPであればやりとりするのに使うアプリはAudiumでもiMessageでもPsiでもIM+でもXabberでも良いのです。

Google TalkはXMPPを拡張したものを使用していました。Google HangoutにおいてもGoogle Talk同様のXMPPによるやりとりが可能です。

Facebook MessangerもXMPPを使用していましたが、現在はXMPPではなくなりました。

LINE

LINEは次のような特徴を持ちます

  • 完全にスマートフォン前提
  • プロプライエタリプロトコルで、アプリも原則として純正のみ
  • ログはサーバー/ローカル両方で保存、ただしサーバー側のログの参照は不可
  • テキスト主体、付加機能として
  • オフライン
  • 既読マークあり
  • スタンプ(sticker)機能があり、非常に人気が高い
  • 通知音は固定で専用の数種類からの選択のみ
  • スマートフォンアプリで通知表示は通知エリアを使用するほか、ポップアップも併用する
  • 暗号化は仕様非公開のLetter Sealing。仕様非公開のため安全性が疑問視されている
  • Letter Sealingは送受信両側がonにしている場合のみ有効になる
  • 日本においてはユーザー数が非常に多く、主流
  • 開発元は韓国企業
  • 韓国政府がLINEに対するやりとりの検閲を要求したことがあり、一度ははねつけたものの再度要求したあとどうなったかが不明。つまり韓国政府に検閲されているかもしれない
  • 個人情報を勝手に取っている/使用している疑惑があり、範囲は限定的ながらある程度は事実。プライバシーについて意図に反する勝手な振る舞いをする
  • 原則として電話番号登録。Facebookアカウントによる登録もできるものの、電話番号を登録しないと結構不自由する

誰もが使っているので使わざるをえない、というのが一番大きいのですが、プライバシーの懸念と検閲問題、さらにスマートフォンだけを利用していることを想定しすぎている(PCユーザーに対する冷遇)ことや、アプリや通信についての仕様が過度に非公開であることから信用できない/使いにくい部分が大きいことから、「知っている人ほど使うのを嫌がる」アプリになっています。

また、通知offがカスタマイズしにくく、端末によっては「この時間まで通知してほしくない」というのが反映されません。

Viber

ViberはLINEのようなメッセージングアプリでは元祖に近いものです。
スマートフォン主体にしたという点でパイオニアです。

海外では主流だったりアプリですが、セキュリティ上の重大な問題が繰り返し指摘され、もはや下火になっています。
また、Viberのプライバシーに対する振る舞いにも問題があると考えられています。

削除推奨アプリです。

カカオトーク

LINEの類似アプリで、LINEよりもViberよりも早くリリースされ、Viberと類似アプリとなっています。

その歴史と事情に注目すべきです。

LINEはLINEのほかまとめサイトも運営するNAVERのもの(現在はグループ会社のLINE。NAVERは現在Livedoorも保有)ですが、カカオトークはもとはカカオ社のものでした。
カカオ社はハンゲーム(現NHN)の元CEOが設立したもので、現在はダウムコミュニケーションと合併し、ダウムカカオになっています。

日本法人であるカカオジャパンにはYahoo! Japanが出資しており、本家韓国法人にはAmebaを展開するサイバーエージェントが出資しています。
また、中国企業のテンセントが大株主となっています。

個人情報の取り扱いに対する不満が非常に多くきかれる企業が名を連ねているあたりにカカオの問題点を示しています。Viber同様の問題から個人情報の流出もあり、また暗号化されていないことによる流出もありました。

さらに、韓国警察の要求に応じてログの提供を行っており(特定の容疑者のやりとりの提出ではなく、検閲・傍受行為)、「しない」と言っていたものの再開していた、といったことがあります。
LINEが拒否したことを、カカオは最初から行っていたということになります。

それ以上に問題なのがカカオトークの使われ方です。

LINEと比べ制限がゆるく、検索がしやすかったことから初期から出会い目的、特に売春目的の利用が非常に多く、もっぱらそれでした。
出会い系サイトでは主だった連絡手段として交換されていますが、今やほかのところで見ることは稀です。
一般の認識として(カカオトークを分かっている人は)売春等犯罪製のある出会い目的のアプリであるという認識が成立しています。

カカオ側はこれを歓迎しておらず、様々に対策し、制限をかけていますが、その制限は一般利用にも非常に大きな制約となっている一方、出会い系での利用が減少しているわけではなく、一般利用においては「使いにくい」ということでユーザー離れが急速に進んでいることと併せてより「いかがわしい出会い系専用アプリ」という色合いが強くなっています。

個人情報と実際の利用のされ方という点から利用は推奨できない、それ以上にインストールしているのなら即刻削除したほうが良いアプリとなっています。

ICQ

1996.11.15とインスタントメッセージングサービスの草分けだったICQ。昔のネットユーザーはやりとりにこれを必ずといっていいほど利用していましたが、MSN Messangerの流行と共にみかけなくなりました。

現在はLINEのような仕様となり、超進化して存続しています。
イスラエル生まれのサービスですが、現在のサービス提供元はロシアのMail.ru。

Webインターフェイスを持つため、インストールなしの利用も可能です。

非常に良いのですが、問題点が結構あり

  • 油断するとすぐロシア語に付き合わされる
  • 電池消費が激しい
  • モバイル版はアプリが全アクセス権を要求する。そこまで信用するのは難しい
  • アカウントが昔ながらのUINのメールアドレス両方が使える方式だけど、ものすごくわかりにくい

PCからの利用と比べると、非常に辛いところがあります。
スマホで使うなら、WEB ICQ経由にしたほうが良いかもしれません。

ビデオ通話も可能、グループ機能があり、グループは公開にすることもできます。
しかしそのせいか、怪しげなグループでいっぱいになっています。

少なくとも英語ができ(ICQ for Windowsはロシア語の回避が困難ですが)、個人情報等についてMail.ruを信用できるのであれば非常に良い選択でしょう。

メッセージ到達は即時ですが、メッセージ通知までにラグがあります。

ICQ Chat

ICQ resent

ICQ 通知

ICQ コンタクトリスト

公開グループ。エロばかり
公開グループ。エロばかり

Facebook Messanger

Facebookに付属するチャット機能です。

Facebookのアカウントと完全に一体になっているため、一般的な連絡手段として使うのは無理があるのではないでしょうか。

Google Hangouts

以前はGoogle TalkとしてXMPP拡張で提供されていたサービスです。
現在はテキスト部分のみXMPPで、音声通話/ビデオ通話はXMPP拡張のJingleを用いているわけではなく、独自のものです。

他のGoogleサービスとの連携が可能であるほか、チャットと音声、ビデオでのやりとりが可能で、利便性の高いサービスです。ビデオ通話サービスはLINEと同程度の品質でSkypeには及びません。

GoogleアカウントはLINEやカカオトークと比べ取得しやすいため、カジュアルに交換できますが、一方でAndroidスマートフォンと密接に絡んでいるGoogleアカウントを教える(それ以上にGoogleアクティビティ経由で情報を取得されるリスクをおかす)ことにはむしろ抵抗があるかもしれません。

大きなメリットとして、ユーザーごとにメッセージ、受話ともに通知音をカスタマイズすることができます。
アプリの使いやすさは最も高いのではないでしょうか。

既読とタイピング両方の通知があるのはHangoutsだけです。
モバイル系っぽい振る舞いを見せますが、ちゃんとオンライン通知もあります。

WhatsApp

SMSの代替としては海外で急速に流行しているのがWhatsAppです。SMSと同時にViberを置き換えるものであるとも考えられます。

SMS代替ということが意識され、コンタクトには電話番号を利用します。
コンタクトはそのまま電話帳を使用し、WhatsApp独自のコンタクトリストを持ちません。

99セントの年間利用料が必要です。

ブロックはメッセージのみ可能で、受話は着信拒否によって行う必要があります。

日本ではSMS自体流行っていないので、わざわざ
WhatsAppを使うメリットを見いだせないように思います。SMSを使っていると高額になりますから、その回避が受けているのでしょう。
日本が独自の流れとなっているのは、キャリアメールによるインスタントメッセージングという独自の文化がはるか以前に形成されたためと考えられます。

電話帳にいるWhatsAppユーザーの登録は強制です。

日本の文化やユーザー事情を考えると、わざわざ使う必要はないのではないでしょうか。

Slack

ビジネス向けのチャットであるSlackは個人利用でもなかなか魅力的です。
スケジュール調整が可能だったり、グループでの調整機能があるため個人利用でも利点は多いようです。Googleのサービスと連携できますから、Googleのサービスを積極的に利用している人たちの間ではより有効でしょう。

Slackの場合、基本的にはグループ単位である「チーム」でやりとりを行います。
チームメンバーに対しては個別にメッセージを送ることができ、またチームメンバーの中の特定のメンバーで構成されるチャンネルを作ることもできます。チャンネルは他のメンバーに対して非公開にすることもできます。

チャンネルを作ることができるため、話題ごとにログをわけることができるのは結構便利なようです。カップルで使っている人もいるようですが、それにはちょっとお硬すぎるかもしれませんね。

LINEなど伝統的な「人に対して友達がいて、友達を複数人登録して会議室を作る」という方式ではなく、逆に「会議室をまず設置して、そこに参加している人と1:1で連絡できる」というチャットベースの方式になっています。

通知される個人情報は登録しなければメールアドレスだけなので、面識が浅い人とも比較的気軽に利用できます。

IRCまたはXMPP経由で接続することもでき、利便性は高いといえます。
自分側に既読がつくため、どこまで呼んだか見失わなくて済みます。

モバイルアプリは通知が5分くらいでまとめられるため、なかなきません。即時性は乏しいですね。

Twitter DM

通知もされるし対応アプリも豊富、グループトーク機能もあり意外と使えるTwitterのDM。
Twitterアカウントと一体であるため、単に連絡手段として使うのは不適ですが、ネットで知り合った人との連絡先交換という意味ではオープンな連絡手段もあり、特にTwitterである程度のポピュラリティを持っている人であれば他のユーザーによる監視効果も生じるため、公明正大を誓える人は身の潔白を示しながらの連絡先交換手段として良いかもしれません。
ツイートから人間性がうかがえる場合もありますしね。

10000文字まで拡張されて使いやすくなったTwitter DMですが、問題点として

  • 対応アプリが豊富といっても、DMが使いやすいアプリはごく少ない
  • Twitter DMは漏れる

漏れる、というのは、Twitter DMでしか発言していないURIに対してその人以外からのアクセスを確認した、ということを示しており、それはすなわち内容が漏洩しているという事実を示しています。

Skype

Skypeは2003年に誕生した「電話ソフトウェア」で、他のIMとは全く異なるものでした。
同じく電話アプリのBitArena(JALが提供していた!)などと違い、チャットもできる、というメリットがあります。

エストニア生まれルクセンブルク育ち、現在はアメリカのMicrosoftが保有しているという点も歴史を感じさせます。

元々、Skypeはオンラインユーザーに対する電話を行うためのソフトウェアなので、オフラインユーザーに対するメッセージは破棄されていましたが、モバイル対応と絡んだのか、現在はメッセージはサーバーで保管され、オンラインになった時に配信されるようになりました。

また、これに関連してログ保存はローカルからサーバーに変更になりました。
ただし、他の端末からアクセスした場合、サーバーからログを同期しようとするものの、同期範囲は限定的で、取り漏らしがかなり発生します。

元々通話アプリですから、通話品質がよく、ビデオ通話も安定しています。

盗聴は難しいため、通話の安全性は高いのですが、ユーザーの意味を誘ってより多くの個人情報を登録させようとする(しかもそれを公開する)、ディレクトリでのユーザー検索は止めることができない、セッション確立方法につけこむ隙がある、といった理由から安全性における問題があります。
特に安易なコンタクトリストへの登録は危険である場合があります。

また、Skypeの秘密主義はなんらかの危険(サービス側での盗聴や、その他悪意ある振る舞い)があっても感知しえないものであることから、問題があるとみなされる場合が多々あります。

それ以外にも国によっては、電話会社への損害を考えて禁止していたりします。

非常に有用なアプリですが、正しい使い方としては

  • 登録・公開する情報に最新の注意を払う
  • Skypeでやりとりする内容は公開できるものに限る。重大な秘密を流さない
  • コンタクトリストへの登録は最低限とする
  • 設定を吟味する
  • 超高性能コンピュータを利用する施設内では使わない(スーパーノードとして利用される問題)
  • 電話番号登録されている場合は、SMSなど電話の機能を用いた利用に注意する

スマートフォンアプリは通知がややわかりにくく通知音も変更できないなど、チャット面ではディスアドバンテージが目立ちます。また、電池消費量がLINEよりも激しく、性能の低い古いスマートフォンだと厳しいものがあります。

現代の遠距離恋愛においては不可欠なものでもあります。
ちなみに、通信量は比較的少なく、YouTubeのように急激に上限に達することはありません。

Skypeは高性能でグローバルアクセス可能なコンピュータをSkypeのインフラを維持するスーパーノードとして利用します。「Skype全体のために勝手にネットワークやコンピュータが利用される」「Skypeでのやりとりに知らない第三者を中継として利用する」ということが気持ち悪いと感じる人には勧められないものでもあります。

タイピング通知がなされます。

Androidアプリ「メッセージ」

チャット感覚で非常に使いやすいアプリなのですが、裏側で利用しているのはSMS。

電話番号ベースのSMSは、送信も受信も有料なので、アプリの使いやすさ以前の問題な気がします。

ケータイメール(キャリアメール)

日本独自の文化として育ったキャリアメールは、他の手段がネット接続を常に維持することでやりとりしているのに対し、キャリアメールはeメールが届いたことを「キャリアから電話回線で」通知されます。
昔のケータイでは単に「メールが届いた」という通知を出すだけというものもありましたが、現代的にはこの通知が届いた時点でデータ通信を行い、メールを受信しにいきます。

メールの内容自体は電話回線で送られているわけではありませんが、「メールをとりにこい」という指令を電話回線で送り、それに対応してメールを取りにいく仕組みのため、「メールが勝手に受信される」ように見えます。

これは、メールがサーバーに到着したら時を待たずして端末にも反映されるのであり、高い即時性がありました。携帯電話は常時携行しているものですから、どこでもいつでも即座にやりとりができる画期的な通信手段となりました。

携帯電話の入力効率問題を別とすれば、パソコンの前に常にいる人と同様のインスタント性があることになり、いつでもすぐそこにいるかのようにやりとりをすることができます。
ただし、この性質は携帯電話の性質と併せることで常時携帯電話に拘束されることとなり、簡単に生活が崩壊してしまうため、双方に自重が求められます。

キャリアメールの場合メールであるために画面変遷を伴い、操作するが多く新着を確認するのもやや面倒です。応答間隔は早い人でも2-3分といったところであることを考えると、10秒程度であるLINEと比べかなり低速なやりとりになります。その割に拘束時間はながく、返事を待っている時間が発生しやすいため時間の損失率が高いという問題があります。

キャリアメールはこのプッシュメール構造のために余計な通信が発生せず、効率がいい仕組みになっています。また、eメールであるため相手を限定せずにやりとりができるというのも大きなメリットといえるでしょう。

一方でキャリア変更によって強制的にアカウント変更となる上、利用できるのは国内主要キャリアとの契約で、かつ日本国内向け専用端末のみ、ということから、必ずしもその前提が成立しない現在においては「キャリアメールが使える」という前提は成立しづらい場合が多く、またキャリアメールの利用者とパソコンでのeメールユーザーとの間で温度差が生じやすい、という問題もあります。

着信音を個別にカスタマイズできるのは大きなメリットといえるでしょう。

GMail

Androidユーザーならまず間違いなくGoogleアカウントがあり、GMailが利用できます。

裏側を見なければGMailは即時メール到着が通知されるため、感覚的にはケータイメールに近い
感じでやりとりができます。

ただし、あくまでメールの画面でやりとりするため、やりとりの程度としてはケータイメールと同等で、LINEのようにがんがんやりとりできるわけではありません。

ケータイメールのように省エネ構造になっているわけではなく、Googleに対して接続を維持しています。

AndroidスマートフォンではGMailでの着信音は個別にカスタマイズすることができます。

XMPP(Jabber)

Jabberは1999.1.4リリースという老舗のインスタントメッセージングサービスです。
ICQなどがライバルでした。

Jabberの大きな特徴として、プロトコルにXMPPを採用し、これを公開していることがあります。
LINEが裏でどんな言葉を話しているのかということは明らかにされていません。そのため、「公式のLINEじゃなくて鈴木家のLNIEを作ろう」ということはできません。
しかし、Jabberはオープンプロトコルであるため、このXMPPを使って「佐藤家のJabberを作ろう」ということは可能なのです。

このため、「アプリは便利だけど、サービス提供者が信頼できない」というような場合に「信頼できるサービス提供者を選ぶ」ということが可能になる、という大きなメリットがあります。

さらに、そのように独自にサーバーを用意することができるため、社内で機密性が高いやりとりを行うために、インターネットに接続していないクローズドなLAN内にXMPPサーバーを設置し、Jabber/XMPP用のアプリでやりとりをする、ということが可能ということが言えます。

逆にサービスはいいけれどアプリがいまいち、ということで言えば、これがオープンな仕様であるために、たくさんあるアプリの中から気に入ったものを使えばよい(Twitterと同じような状況)というメリットもあります。

XMPPの場合

  • サービス提供者の選択
  • アプリの選択

というふたつの選択ができる(必要となる)ということが言えます。

ですが安心してください。XMPPの場合、他のサービス提供者のサーバーともやりとりできます。

たとえば鈴木さんはexample.orgのアカウントを持っていて、佐藤さんはexample3.co.jpのアカウントを持っているとします。

XMPPのアカウントはメールと同じく

<アカウント名>@<サーバーアドレス>

の形式で表し、鈴木さんはsuzuki@example.org, 佐藤さんはsato@example3.co.jpというアカウントを持っているとします。

鈴木さんはexample.orgを利用していますが、そのままコンタクトとしてsato@example3.co.jpを登録すると、そのままやりとりすることができます。

中央集権方式になっていないのはメール同様の構造で、非常に優れています。

XMPPはそれ自体がオープンでわかりやすい仕様になっていて、最初からこのように自由に、オープンに利用されることを想定していたものでした。

eメールのように一般的で普遍的なものであるにもかかわらず、インターネットレベルでのXMPPユーザーはごく少ないというのが差存念なところで、とても残念に思っている人は私を含めてたくさんいます。

xmppサーバーを自分で用意しても良いのですが、一般的に利用されているサービスとしてはjabber.orgと日本のxmpp.jpでしょう。リストもあります

また、アプリとしてはPsiJitsiが人気のようです。MacユーザーならiMessageがXMPPに対応しています。AndroidならXabber, Conversations, Freelab XMPP Messanger、iOSユーザーならIM+かMonalでしょうか。

AndroidにおいてはFreelab XMPP MessangerのほうがUIは洗練されていますが、サーバー設定が微妙にしづらかったり、ポップアップの通知がなかったりするのでXabberのほうがおすすめですね。
なお、Freelabのほうはタイピング通知が可能です。XMPPでタイピング通知はあるのですが、タイピング通知するアプリが少ないので目にすることは稀です。

XMPPの拡張としてJingleというものがあり、これは音声通話やビデオ通話が可能です。
この利用はサーバーではなく、双方のアプリの対応が必要です。
AndroidアプリでJingle対応のものはないっぽいので、このあたりは負けていますね。
XMPPのみ使っていてスマホで通話する場合はWebRTC、というのが妥当なスタイルのようです。

AOL Instant Messanger (AIM)

MSNメッセンジャーやYahooメッセンジャーよりも早く、1997.5にサービスを開始したインスタントメッセージングサービスでありながら現在もしぶとく生き残っているAIM。

プロトコルはプロプライエタリプロトコルであるOSCARですが、古くから解析が続けられているため非純正の互換クライアントは結構豊富です。AOLは強烈に抵抗していますけれど。

ただし、2004年以降、文句はいいつつ遮断はしておらず、2006年からは仕様を一部オープンにしました。

Android / iPhone版もあります。

AOLアカウントを持っている知人がおらず、現在AOLアカウント取得にはケータイ番号が必須のため、アプリのテストはできませんでした。

AIMのユーザーが日本にいないのは昔からです

WebRTC

WecRTCはW3Cでちゃんと策定されている音声/ビデオ通話の仕様です。

Google ChromeとFirefoxに機能が実装されていて、Web上で簡単に通話できるので便利です。
次世代のおもしろ技術として流行っている感がありますが、「連絡先を交換しなくても通話できる」のはある意味便利です。また、Skypeが落ちている時の非常手段にもなります。

ただ、WebRTCで手軽に利用できていたFirefox Helloがversion49であっさり削除されてしまったのでどこを使うかが悩みどころです。Jitsi Meetでしょうか。

音声もビデオも品質としてはあまりよくないです。かろうじて話せる程度。

今回の話題としてはかなり番外な感じになりますが、XMPPを使用している場合や、とりあえず連絡先交換はしないけどおしゃべりはしたいという時にとても便利です。

終了したサービス

MSN Messanger / Windows Live Messanger

日本では非常に高い人気をほこったインスタントメッセージングサービスです。
ビデオ通話の機能まで取り込まれ、様々なゲームまで可能となっていました。

後継のWindows Live Messangerも終了したのは、サービスを提供していたMicrosoftがSkypeを買収したためでしょう。
ただし、Skypeとは性格の違うものなので、Skypeへ移行というのは違和感があります。

MSNアカウント(hotmail.com/hotmail.co.jpアカウント)はSkypeで利用できます。

PC向けのサービスで、スマートフォンでの利用は困難でした。

オフライン時に送信されたメッセージは破棄されます。

2013.4.8終了。

Yahoo Instant Messanger

YIM。日本ではサーバーの仕様が異なり、YIM対応のソフトウェアでも「Yahoo Japan対応」である必要がありました。

2004.4.12-2014.3.26

Odigo

日本ではマイナーなまま終了したインスタントメッセージングサービスで、女性が登録するとものすごくナンパされました。

まとめ

表1 基本

サービス アプリ プロトコル モバイル Windows Mac Linux Web
LINE LINE LINE 前提 WINE / Purple-LINE なし
Viber Viber Viber 前提 なし
カカオトーク カカオトーク カカオトーク 前提 × なし
ICQ ICQほか多数 OSCAR 純正はないが互換アプリあり
Google Hangouts Google Hangouts XMPP拡張 + WebRTC拡張 △(音声通話はJitsiのみ?)
Slack Slack / XMPP / IRC Slack ? ? ?
Twitter (DM) Twitter (+3rd) Twitter
Skype Skype Skype
キャリアメール キャリアメールアプリ eメール拡張 専用端末
GMail GMailほか eメール
XMPP 多数あり XMPP
WebRTC なし WebRTC          
AIM AIMほか多数 OSCAR 純正はないが互換アプリあり ?

表2 安全性

サービス e2e暗号化 セキュリティ
LINE オプション (Letter Sealing) 検閲疑惑, 個人情報搾取疑惑
Viber なし 個人情報搾取/漏洩
カカオトーク なし 検閲あり, 個人情報搾取疑惑
ICQ なし アプリの権限過剰
Google Hangouts オプション (TLS) 個人情報取り扱いの疑問
Slack オプション (TLS)
Twitter DM オプション (SSL) 漏洩あり
Skype 独自 個人情報取り扱いの疑問
キャリアメール なし 平文(漏洩リスク高い)
GMail オプション (TLS/PGP) PGP併用の場合非常に安全, ただし平文の場合Googleは検閲あり
XMPP オプション (TLS) サービス提供者による
WebRTC オプション (SSL) サービス提供者による
AIM なし ?

表3 通知と機能

サービス 既読 タイプ通知 オンライン通知 チャット 通話 ビデオ
LINE あり なし なし
ICQ なし なし あり
Google hangouts あり あり あり
Slack なし なし あり × ×
Twitter DM なし なし なし × ×
Skype なし あり あり
XMPP なし オプション あり 条件付き 条件付き
WebRTC テキストなし テキストなし 入室通知 なし

表4 その他の機能と登録

サービス 画像 スタンプ 注目 画面共有 登録 グループ
LINE なし なし 電話番号 or Facebook あり (通話対応)
カカオトーク なし なし 電話番号 あり
ICQ なし なし 電話番号 or メールアドレス あり(公開)
Google Hangouts なし あり メールアドレス and 個人情報 あり (通話対応)
Slack × あり なし メールアドレス チームベース
Twitter DM × なし なし メールアドレス あり
Skype なし あり 電話番号 or メールアドレス あり
XMPP × あり アプリによる 選択 サーバー対応
WebRTC なし なし サービスによる サービスによる 不要なものもある 通話のみ
AIM ? なし なし なし 電話番号 and 住所 ?

表5 アプリ仕様と通知

サービス 音声通知 ポップアップ 個別サイレント 時間別サイレント ブロック
LINE わずかに変更可 ウィンドウ 非常に限定的
ICQ 全体 OSD / ウィンドウ 手動
Google Hangotus 個別設定 OSD ?
Slack 全体 OSD × 指定時刻内 or 手動 ×
Skype 変更不可 OSD ×
キャリアメール 個別設定 端末による ×
GMail 個別設定 OSD ×
Pidgin (XMPP/Hangouts/LINE) 全体 なし × ×
Xabber (XMPP) 個別設定 OSD 手動
Freelab XMPP Messanger jabber (XMPP) 全体 なし × ×

結局のところ実情からお勧めは?

LINEはいれざるをえないのではないでしょうか。

よく通話する人、遠距離恋愛している人はSkypeも使いましょう。

LINEを教えたくないよという相手、LINEは使いたくないよという相手とは、端末がAndroid同士ならGoogle Hangoutならすんなりいける可能性があります。

XMPPの利用者を広げたいところです。XMPPはとても良いものです。しかし現状では使っている人がほとんどおらず、この手のアプリとしては用を為しません。
ふたりの連絡用、ということでは意味があるのですが、リソース消費量(主にメモリとバッテリー)を考えればそのためだけというのもちょっとどうだろうという気持ちになるかと思います。

ちなみに、この手の連絡先交換としては、既に重要なものとして使用しているものを教える(だいたいはLINEかSkype)ことは相手に対する肯定の表現になりますが、一方でそのコンタクト数が多い場合は、むしろ専用に別のものを用意して、これまでのものの利用頻度を下げることが強い愛情表現になる場合もあります。
特にSkypeの場合、オンライン通知がありますから、その相手と会話しようと思ってSkypeを立ち上げると他の人に話しかけられる、という事態も発生します。

深く付き合うのであれば切り捨てにくくすることにより向き合う必然性を自ら生じさせるという方法もあります。人間、退路を断つことは案外重要です。

通知が弱いとどうしても後回しになってしまうがちですから、積極的な人は通知の強いアプリを望むでしょう。

連絡先交換がためらわれるようなカジュアルな関係において利用するのであればアカウント取得・破棄が容易なSlackが結構良いと思います。通知が弱いこともカジュアルな関係をほどよく持続させることになるかもしれません。
通話する時はWebRTCで良いと思います。

逆に真面目に付き合っていくのであれば、既存のコンタクトがないような状態であればSkypeが良いと思いますが、話しかけるのに向きませんし、会話が筒抜けの可能性もあります。

外出中の通話がなく、家にはパソコンがあるのであれば、XMPPを利用し、通話はJitsiやPidginで行うという方法がなかなかスマートで良いと思います。
スマートフォンによる通話が必要で、かつ通話定額制になっていない、あるいはビデオ通話を必要とするのであれば、通話用としてSkypeを併用するのがスマートだと思います。あるいは、その場合はWebRTCを利用してもいいかもしれません。

なんにせよ、この手のアプリで一番難しいのは合意形成です。どれがいいかな、と一緒に考えられるとしたら、十分信頼しあっている良い仲であるような気がします。

超要約すると

  • Viberとカカオトークは今すぐ退会して窓から投げ捨てよう
  • LINEやSkypeを信用しきるのは危険
  • Google Hangoutsは「Googleである」という点を除けば非常に良い
  • 音声・ビデオではSkypeが圧倒的に良い。遠距離恋愛の必需品
  • XMPPをXabber経由で利用するというのはかなり快適。通話はJitsiかPidginで
  • やっぱりXMPPを普及させたい
  • Slackはうまく使いこなせばかなり可能性あり。ただし密なやりとりにはあまり向いてない

XMPP利用の手引

ここではxmpp.jpとAndroidアプリのXabberによる利用を説明します。

xmpp.jpでの登録

登録ページからメールアドレスとパスワードを設定して登録するだけです。
CAPTCHがあります。

xmpp.jp

xmpp.jp登録

Xabber

PlayストアXabberをインストールします。

Xabber on Play store

起動すると「アカウントはありません」と表示されます。アカウントを追加します。

Xabber アカウントを追加
Xabber アカウントを追加

Xabberはサーバーの指定フィールドはありません。ユーザー名でサーバーも指定します。
「アカウントを追加」をタップすると登録が完了します。

アカウントとパスワードを入力
アカウントとパスワードを入力

アカウントの編集に移動します。
「メッセージの履歴を保存」で保存の仕方を設定できます。

アカウント編集画面
アカウント編集画面
メッセージ履歴の設定
メッセージ履歴の設定

コンタクトはグループごとにまとめられます。複数アカウントの利用も可能です。

Xabber コンタクトリスト
Xabber コンタクトリスト

メッセージを受信するとチャットスクリーンを開いていない場合はOSDによる通知がなされます。ちなみに、チャットスクリーンを開いて設定を行うことで、通知サウンドだけでなくOSDの表示も個別に設定することができます。

Xabber 通知
Xabber 通知

チャットスクリーンはこんな感じ。背景や色の個別設定はできません。
暗号化にも対応しています。左下のロックをタップすれば設定できます。

Xabber チャット
Xabber チャット

Xabberは常駐し、このようなステータスメッセージを表示します。

通知エリアで動作する
通知エリアで動作する

用語集

サーバー

サービスを提供しているコンピュータ。サービス提供者のコンピュータ群。
サービス提供者のところ。

#### ログ

やりとりの記録

既読

そのメッセージを相手が見た(少なくとも開封した)ことを示すもの。

通知音

相手からメッセージが届いた時に鳴る音。
個別に、といっているのは、相手が誰かであるかによって
違った音を鳴らせるかどうか。

テキスト/トーク

文字でのやりとり

通知エリア

お知らせがあった場合に表示される領域。通知エリアから通知を確認することができる。

ポップアップ

スマートフォンにおけるポップアップは、他の画面を覆うように、あるいは他の画面よりも優先して表示レされるもの。

LINEの場合はロックした状態で受信すると、画面が点灯して受信内容が表示され、ロック画面の上に居座る形になる。

ユーザー

利用者

ローカル

手元の端末、あるいはその地域。

アクセス権

スマートフォンアプリの場合は、そのアプリが何をしてもいいか、といったことが権限として持たされている。
権限がなければ勝手にネットに接続して何かを送ったりすることはできないし、逆に権限があれば勝手にそのような振る舞いをすることも可能。

傍受・検閲

公的機関等特別な立場にある者が、やりとりの内容を覗き見たり、特定の内容でやりとりを検索したりすること。

盗聴

第三者がやりとりの内容を覗き見ること。暗号化されている場合、除きみたものの内容はわからなかったという場合は盗聴できなかった、ということになる。

アカウント

IDに紐付いてその人物として登録されているもの。

サービスの利用はアカウント単位で行う。アカウントは「口座」という意味で、実際に銀行であれば口座にあたる。

グループ機能/会議室(カンファレンス)/マルチユーザーチャット

1:1ではなく、三名以上でやりとりする機能。

Web / ウェブブラウザ

「インターネット」と呼ぶ人も最近は多い。

Safari, Google Chrome, Internet Explorer, Microsoft Edge, Oepra, Firefoxなどで利用するもの。
これらのソフトウェア/アプリを「ウェブブラウザ」と呼ぶ

タイピング通知

「今この人は入力を行っています」という表示

カスタマイズ

変更すること

SMS

電話番号を用いたショートメール。
送信・受信ともに有料。定額制も関係ない。

コンタクト

  • 連絡すること
  • 連絡先

LINEでいうと「友だち」

コンタクトリスト

連絡先の一覧。LINEでいうと「友だち」登録されている人たちということになる。

Android

スマートフォンのOSの名前。Google製。

iPhoneでないスマートフォンユーザーはまず間違いなくAndroidと考えていい。他にもWindows PhoneやBlackberry OSやTizenやFirefox OSやopen WebOSやPlasma MobileやSailfish OSなど色々とあるが、そんなものを使っている人は相当な物好きだろう。

モバイル

携帯電話(スマホ含む)

オンライン通知

現在連絡可能な状態にあるかどうかを示すもの。

パソコンの場合は起動していてインターネットに接続している、という状態は明らかに「連絡可能な状態」として区別できるため、今オンラインなのかオフラインなのかという表示には意味がある。
そのため、インスタントメッセンジャーに類するものはオンライン通知に対応したものが多い。

ところがスマートフォンの場合は、例えスリープ状態になっていたとしても通知があればすぐに見るかもしれない。連絡可能な状態にあるかどうかを判断するのが難しく、往々にしてそれは意味がない。そのため、LINEやカカオトーク、Viberなどはオンライン通知を持っていない。

purple-line(pidgin)を使ってのLINEがエラーになる

purple-lineで突如、相手によってやりとりは空白テキストになり、送ろうとすると

Failed to send message: can not send using plain mode

と言われるという問題が発生していた。

調べてもなんの情報も出なかったので、issue報告した。

これは、Letter Sealingを有効にすると、Letter Sealingを有効にしている相手とはpurple-lineでやりとりできない、ということらしい。
く慰安とレベルの実装だと思ったのだが、サーバー側が有効にしているか知っていて、plainで送ることを受け付けないようだ。

purple-lineを使う場合はLetter Sealingを無効にすること。

壊れたシステムの修復のためのManjaro 0.8.13インストール

update-grubできない問題は根が深く、様々なところで訊いてはみたものの、結局答えが出ない。

Manjaro 0.8.13について

Manjaro Linuxは0.9.0リリースを控えていたが、新インストーラのCalamaresのバグがなかなか解消できず、結局0.8.12でCalamaresを採用したものの、インストーラをThusに戻した0.8.13をリリースするに至った。

Manjaro Linuxの日本語を一手に引き受け、Manjaro JPも開発するrago1975さんによれば、0.9.0のThusインストーラバージョン的なものだとという。

実際にそのように感じる。というのは、XFceはGTK3を採用する4.12、KDEはPlasma5なので、デスクトップが別物になっている。 XFce版だとDMも完全に別物となっており(もしかしたらMDMから差し替えられたのかもしれないが)、雰囲気はがらっと変わった。

XFceは0.8.12でも4.12の開発版である4.11を採用しており、現行のManjaroテーマも既に採用されていたため、0.8.12からの目新しさは特にない。 とはいえ、それまでの0.8.11からすれば劇的に変わり、垢抜けないデザインが特徴だったXFceもぐっとスタイリッシュになった。0.8.12と比べてもやはり部分的に見た目も変更されている。

アップデートでは見た目に関する部分は変わらないため、「見た目が変わった」というのは、入れ替える動機にもなるかとは思うが(Plasma4がPlasma5に置き換えられるのは当面先だろうから、入れ替えはかなり大変だと思う)、今回はThusの改良に非常に力が入れられていた。

まず、Thusインストーラの起動はすごく速くなった。これまでは、忘れた頃に起動する勢いだったが、すぐに起動するようになった。

Thusは手動パーティショニングをしてもLUKSの利用ができるようになったはずだが、それについては今回試していない。

LUKSパスフレーズについては、「特殊な文字を使うな」という注意書きが増えた。「LUKSパスフレーズに記号を含めると復号化できなくなる」という問題に対応したのか。

またブートローダーはGRUB2とGummibootを選択できるようになった。しかし、Gummibootを選択するとブートローダーはインストールされない。 また、Gummibootを選択した場合、ブートできない可能性があるのでウェブサイトを見るかと聞かれる。

Thusはかなり改善されたことを感じられる。

また、0.8.11まではUEFIでインストールしても第1パーティションにGRUB_BOOTを切っていたが、これをやめて3パーティション構成になった(ESP, BOOT, LVM)。Gummibootにすると、2パーティションになる。

Gummibootにきちんと対応してくれると嬉しかったのだが…

なお、Manjaro 0.8.11をそのままにしてインストールすると、GRUB2でも起動しなかった。 事前にGPTを作成しておくことで無事に起動できた。

ただし、UEFIブートメニューに謎の無効な空欄エントリがあるということは変わらない。

導入しようにも…

しかし、Alternative HDD (500GB)に入れても、そこで構築してSSDに移す、というのはかなり大変な作業になる。SSDのほうが小さいからだ。

かといって、環境をイチから作るのに、現行の環境を潰してしまうと、だいぶ長く仕事ができなくなってしまう可能性がある。

散々悩んだ挙句、結局はSSDをもう1台追加することにした。 ケーブルも併せてだいたい12000円の出費。なかなか痛い。 だが、仕事を見通しが立たないまま止めるわけにもいかないし、かといって更新できない状態でも放置できないので、やむなしか。

ケーブルはAmazonで、SSDはNTT-Xで購入。NTT-Xは仕事でも使えるようなので、これからかなりお世話になることになるだろう。

ケーブルは当日、SSDは翌日に到着した。

インストール作業

インストール

まずは単純に、SSDを組み込んで元のSSDとAlternative HDDを外し、予めGPTを作成した上でThusインストーラでインストールする。

UEFIでLVM, LUKS, /home分割はon, GRUB2を選択、なお起動時にはnomodesetnokmsbootオプションが必要。

ただし、インストール後はnomodeset及びnokmsbootは必要なかった。

基本セッティング

まずはworldencmountの必要なファイルをtarで展開する。これでbtrfsボリュームのマウントが可能になる。

そしてzshのインストール。 なお、zsh-configについてはかなり癖がある設定の上に、手元の.zshrcで設定できなくなるので私は好まない。

これでマウントできるようになったら、btrfsをroでマウントし、最低限のファイルをコピーする。主要な設定ファイルは

cp ~/share/manjaro-home-transition/*(#q@) .

で以降できる。データ本体は~/shareにあるため、データの以降は必要ない。

日本語フォントはあるが、日本語入力ができない状態でスタートするため、とりあえず

yaourt -S fcitx-mozc-ut

インストール前にPKGBUILDをいじってニコと英語dicを有効にしてインストール。 ただし、googlecode.comのIPv6問題があるため、その前に

yaourt -S dnsutils

してdigを使えるようにし、

dig japanese-usage-dictionary.googlecode.com

して/etc/hostsにIPv4で決め打ちする。

私のプログラムは多くがRubyを使うため、Rubyも設定しておく必要がある。 これは次の方法で行う。元々

pacman -Q > pacman-q

としてあり、ここから

grep -F ruby pacman-q | cut -d " " -f 1 > rubypkg

として抽出。このうちインストール済みのものは必要ないので、

pacman -Q | cut -d " " -f 1 > pacman-qq

と現状のものを取得し

cat pacman-qq pacman-qq rubypkg | sort | uniq -u > target-ruby

とする。あとは

yaourt -S $(cat target-ruby)

でOKだ。

同様の方法でTTFファイルもインストール。

また、EncFSをコアに入れているので、EncFSをインストール。

yaourt -S encfs

また、nemoはテンプレートディレクトリにシンボリックリンクを許容するが、Thunarはしないので、シンボリックリンクをやめて、コピーに

rm template
cp -R share/template .

さらに、エスケープしたfstabをベースにfstabを修正する。 その前にVIもVimもなくて混乱するため(例えばvipwはあるのに、vipwはできない)、インストールしておく。

yaourt -S gvim vi

とりあえずエディタはmousepadが使える。とりあえずはmousepadで修正しリブート。

日本語周り

fcitx-mozc-utだけ入れたが、それさえ入っていなかった。 そして、日本語周りはManjaro JPベースではないため、それなりに複雑だ。

まず、fcitx-mozc-utがベースになるので、それをインストール。

yaourt -S fcitx-mozc-ut

各ツールキットに対して入力するためのパッケージと、設定のためのパッケージも導入

yaourt -S fcitx-gtk2 fcitx-gtk3 fcitx-qt4 fcitx-qt5 fcitxconftool

これだけでは入力できないため、~/.xprofileに追記

export GTK_IM_MODULE=fcitx
export GTK2_IM_MODULE=fcitx
export GTK3_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
export XMODIFIERS="@im=fcitx"
export DefaultIMModule=fcitx
export PATH=/home/aki/bin:$PATH

$PATHは別件だが、ついでに書いておいた。XMODIFIERSXMODIFERSと書いており、LINEやSkypeに対して日本語入力できないという問題が発生して若干ハマった。

なお、さらに後ほど突如としてGTKアプリケーションに対してfcitxが有効にならず、

gtk-query-immodules-2.0 --update-cache 
gtk-query-immodules-3.0 --update-cache 

しても直らず、結局両パッケージをアンインストールした上で再インストールしたら直った、などということもあった。

そして再起動。

パッケージインストール part1

先にいくつか使われるのがわかっている~/.config以下のファイルをコピーしておく。 .config以下はそのままシンボリックリンクに変換できないからだ。

cp ~/share/manjaro-home-transition/.config/usr-dir* .config/
cp -R ~/share/manjaro-home-transition/.config/opera-developer .config/
cp -R ~/share/manjaro-home-transition/.config/tasque .config/
cp -R ~/share/manjaro-home-transition/.config/fontconfig .config/

そして次のパッケージをインストールしていく。

  • ctags
  • leafpad
  • medit
  • geany, geany-plugins
  • smplayer, smplayer-themes, smplayer-skins
  • opera-developer
  • linux405
  • infinality*
  • wine
  • plasma
  • kde-applications
  • kopete

Wine * LINEで文字が非常に汚い、という問題があったが、いつの間にか直った。

KDE5関連はplasmaパッケージで、kde-applicationと合わせるとかなりの部分がインストールされる。

kopeteのファイルは~/.kde4以下にあるので、これをコピーする。

cp -R ~/share/manjaro-home-transition/.kde4/share/apps/koepte ~/.kde4/share/apps/
cp  ~/share/manjaro-home-transition/.kde4/share/config/kopeterc ~/.kde4/share/config

KDE5

KDE5は、KDE4よりもさらにスタイリッシュにはなったが、スマホっぽいふらっとUIになり、洗練されたがいかにも重量級な「すごい演出」は損なわれた。

また、非常に多くの機能が未実装だ。

マルチディスプレイの対応についてはkscreenパッケージで対応できるが、細かく設定ができない。 Catalystで設定することはできるが、永続しない。

また、systrayが未実装(!)。libappindicatorとsni-qtを使えばいけるような話なのだが、実際はいくつかのアプリケーションがこれでもsystrayに入らない。

相変わらずKDEで設定が効かない部分があるので、

  • kde-gtk-config
  • kcm-gtk

を導入、さらにqtconfig-qt4を使って設定する。

悪くはないけれど、KDE4から乗り換えるには早いか。 アニメーションはKDE5のほうがパワーアップしているが、KDE4よりも良いかと言われると悩むところ。 少なくとも、設定の問題でKDE4のほうが現状は良いと思う。

KDEとXFce

そして、KDEで設定するとXFceのUIが壊れたりするのでたちが悪い。 この設定はかなり難しいが、基本的には「設定マネージャー→外観」でテーマ設定してからgtk-theme-configで調整すれば良い。

ちょっとややこしいが、gtk-theme-configはextraに"gtk-theme-preferences"という名前でパッケージがあり、さらにAURに"gtk-theme-config"というパッケージもある。 恐らくは公式入りしたが、AURのパッケージ作者がメンテナになっているわけではないのだろう。

より細かく設定するならばxfce-theme-managerがあれば良いが、場合によってはより迷宮入りする。KDEといったり来たりすることになるだろう。

なお、一度XFceが起動不能になり、~/.config/xfce4を吹き飛ばして作りなおすはめになった。この場合、skelからコピーするのが近道。

パッケージインストールpart2

  • cinnamon
  • xsane
  • xfce4-theme-manager
  • fetchmail
  • spamassassin
  • razor
  • virtualbox*
  • tasque
  • skype, skype-call-recorder
  • openssh, sshfs
  • lv
  • w3m
  • nss-mdns
  • amarok
  • audacious, audacious-plugins
  • libcue
  • audacity
  • inkscape-gtk3-bzr

Inkscapeは猛烈に長い。

Zeroconfの設定は、これに加え/etc/nsswitch.confにmdns-minimalを書くこと。avahi-daemonは標準で起動。

Pandoc

相変わらずhaskell-pandocパッケージが入らないので

yaourt -S ghc cabal happy alex

してから

export PATH=$HOME/.cabal/bin
cabal update
cabal install pandoc

PDF出力用に…

yaourt -S texlive-core texlive-langcjk

うまくいった。

TODO

今わかっているのは、Spamassassinのsa_learnで学習したデータを持ち込んでいないこと。

あと、SOXもまだインストールしていない。 それ以外は恐らくは必要になったら足す形で、ゴミパッケージをなるべく増やさないようにするだろう。結局使えなかったものをためこんでしまったからだ。

また、英数キーを押すと問答無用でCapsLockになる、というトラブルも出ている。