テンキーNを押すと直前に入力したキーをN回連打する AutoHotkey スクリプト

スペースとか Backspace とかカーソルキーとか、連打する機会はちらほらあるけど、だるい時があるので楽できないかなと考えて、「直前に押したキーを N 回連打する」 というアイデアはどうか、とひらめいた。んで、形になったのがこんなの。

strokelone_demo

以下、細かい解説とかだらだらと。

これは何?

たとえばスペースを押した後にテンキー8を押すと、スペースが8回連打される。「→」を押した後にテンキー4を押すと、「→」が4回連打される。

そんな感じのブツ。

成果物

GitHub にアップしたのでそちらを。

strokelone

英語圏にも訴求したいので(下手だが)英語にした。あと名前は Stroke(キー入力) を Clone(複製する)、というところから名付けた。

スクリプトはどんな感じ?

こんな感じ。

priorkey := A_PriorKey

Numpad1::
  push_priorkey(1)
Return

; ...中略...

Numpad9::
  push_priorkey(9)
Return

push_priorkey(count){
  global priorkey
  old_priorkey := priorkey
  priorkey := A_PriorKey

  is_numpad_found := InStr(priorkey, "Numpad")
  if(is_numpad_found){
    priorkey := old_priorkey
  }

  Loop %count% {
    SendEvent {%priorkey%}
  }
}

スクリプト解説

(1) 繰り返し入力の実現

どうやって実現したのかというアイデアを解説する。

まず必要となるパーツは以下三つ。

Numpad1::
  ; テンキー1を押した時に実行する処理をココに書く
Return
; 直前に押されたキー内容が入っているシステム変数
A_PriorKey
; Spaceを入力する
SendEvent {Space}

これらを組み合わせれば表題を実現できそうだが、一点厄介なのが 一度テンキーを入力すると A_PriorKey の中身がテンキーになってしまう こと。これのせいで、たとえば space → テンキー8 → テンキー8 と押しても space が16回入力されない(1回目のテンキー8を押した時点で A_PriorKey がテンキー8 になってしまう)。

どころか、内部的には「テンキー8を押したら A_PriorKey(この中身がテンキー8) を Send する」という 無限再帰呼び出し になってしまい、そのうちスクリプトがエラーを出してしまう。

これを回避するために、以下のようにした。

  • A_PriorKey の値を別のグローバル変数にもたせておく(例: priorkey)
  • 二つ前に入力されたキーも保持しておく(例: old_priorkey)
  • SendEvent を行う前に priorkey の中身を見て、 もしテンキー系が入っていたら場合は priorkey の中身を old_priorkey にする

つまり「テンキーを A_PriorKey の対象から外す」処理を強引に実現した。

(2) その他必要な設定について

スクリ序盤で定義してるやつら。

#SingleInstance force

これは多重起動を防止するオプション。厳密に言うと「後から起動された場合、前に起動してた分を 強制的に(Forcely) 終了させる」という挙動になる。

#Persistent

これは「(スクリプト最後まで実行したら終了するのではなく)常駐してね」というオプション。

#KeyHistory 20

これは「入力されたキー情報をどこまで記録するか」という値。A_PriorKey 変数は、この key history 機能が有効じゃないと使えなかったりする。

この key history は keydown(キーを押し込む) と keyup(キーを離す) をそれぞれ 1 件として記録するので、「一つ前のキー」情報がほしければ最低でも 2 が必要となる……と思ったんだけど、 2 だと動作しなかったのでテキトーに 20 くらいにしといた。

#InstallKeybdHook

これは「キーボードフック」とかいう機能を有効にするオプション。詳しいことはよーわからんが、AutoHotkey ではキーボード絡みで色々複雑なことをしており、そのために「キーボードフック」なる専門的な処理が必要みたいで、このオプションはその「専門的な処理を使ってもいいですよ」ってのを指定している。おなじないみたいなもん。

GitHub の Repository Search は部分一致ではなく単語一致ですよという話

GitHub の検索ボックスから検索する人はちらほらいると思う。私もよく使うのだが、いまいちヒットしづらいというか、ちゃんと仕事してよーと感じる時が多い。

ので、その辺どうなってんのかを調べてみた。

結論

  • Repository Search は文字列の 部分一致ではない
  • Repository Search は 単語一致である (と思われる)

検索ボックスから検索したい時は、部分一致ではなく単語一致を狙うとよい。どうしても部分一致が使いたいなら clone → ローカルで Grep などで頑張ろう。

詳しく

stakiran/test_github_search というリポジトリを作って実験してみたのだが、一つ例を挙げて解説する。

リポジトリに hello.py というファイルがあるとする。

import sys

print('Hello.')
print('はろー')
print('こんにちは世界')

さてここでクイズ。以下の検索ワードのうち、hello.py にヒットするのはどれでしょう?

  • Q1. import
  • Q2. impor
  • Q3. はろー
  • Q4. こんにちは
  • Q5. こんにちは世界
  • Q6. ちは
  • Q7. "ちは"

正解(ヒットするもの)は以下です。

  • Q1. import
  • Q3. はろー
  • Q5. こんにちは世界

Q1 は import という単語に、Q3 は「はろー」という単語に、Q5 は「こんにちは世界」という単語に一致するため、ヒットしている。Q2, Q4, Q6, Q7 は 部分一致はするが単語一致してない ためヒットしない。

ここで「単語一致とは何か」という話になるが、詳しい仕様は私もわからない。ただ、

  • スペースやら "" やら '' やらで区切られた、一繋がりの文字列

という感じだと思う。もっというと、

print('こんにちは世界')

上記の日本語部分の単語とは「こんにちは」でも「世界」でもなく、「こんにちは世界」である。意味的(セマンティック)な単語ではなく構文的(シンタックス)な単語、とでも言えばいいのか。

秀丸エディタの AutoHotkey 用辞書ファイルを作った

Version 1.28.0.2 ベース。

成果物

GitHub にアップした。

効果

  • 指定したキーワードを自動補完できる
    • 例: # と打つと #NoTrayIcon などの #XXXX 系が補完される、とか

作り方

いかにしてキーワードを列挙するかが問題。

方法1: ヘルプから(今回採用案)

https://autohotkey.com/docs/AutoHotkey.htm

上記ページの Index から HTML データを取り出した(Firefox の F12ツールで inner HTML をコピーした)後、正規表現とか駆使してキーワードだけ残すようにした。

以下作業メモ。

コピーするとこんなデータ:

<a href="https://autohotkey.com/docs/commands/SetExpression.htm" tabindex="0" data-content=":=" class="selected"></a><a href="https://autohotkey.com/docs/commands/Send.htm#blind" tabindex="-1" data-content="{Blind}"></a><a href="https://autohotkey.com/docs/commands/_AllowSameLineComments.htm" tabindex="-1" data-content="#AllowSameLineComments"></a><a href="https://autohotkey.com/docs/commands/_ClipboardTimeout.htm" tabindex="-1" data-content="#ClipboardTimeout"></a>...

</a></a>\n と置換。

<a href="https://autohotkey.com/docs/commands/SetExpression.htm" tabindex="0" data-content=":=" class="selected"></a>
<a href="https://autohotkey.com/docs/commands/Send.htm#blind" tabindex="-1" data-content="{Blind}"></a><a href="https://autohotkey.com/docs/commands/_AllowSameLineComments.htm" tabindex="-1" data-content="#AllowSameLineComments"></a>
<a href="https://autohotkey.com/docs/commands/_ClipboardTimeout.htm" tabindex="-1" data-content="#ClipboardTimeout"></a>
...

色々工夫して data-content の中身のみ抽出。

:=
{Blind}
#ClipboardTimeout
...

あとはキーワードじゃない分をひたすら削除していく(上記例でいえば上二つは削除)。やり方は、

  • 記号を含む行を削除
  • スペースを含む行を削除
  • 重複行を削除

など。ただこれだと「buffering」みたいな、キーワードじゃないが索引として用意されてる単語がまだ残ってる。ここは省ききれてない。

方法2: ソースから(没案)

ソースコードにキーワードの定義が書いてあるはず、と思って覗いてみたが、結論を言うと定数化がキレイにまとまってないコードだったので抽出は諦めた。

メモ1: ビルドイン変数と関数はこの辺で定義されてる

メモ2: github.com での Search は使い物にならないので Clone して Grep とかした方がベター

感想

『秀丸エディタは長いこと使ってるけど、今回初めて「辞書ファイル」なるものの存在を知った。最近 AutoHotkey を書いているので、試しにと作ってみることにした。

導入してみると、良い感じ。この調子で AutoHotkey コーディングをどんどん捗らせる所存。

DNS におけるレジストラ、レジストリ、whois、DNS キャッシュの違い

こんがらがるのでまとめた。

レジストラとレジストリ

レジストラ はドメイン名を管理する組織。

ドメイン名は好き勝手に使われると収拾がつかないため、国際的に管理されている。親玉レジストラは ICANN。レジストラは国単位などで細分化されていて、たとえば .jp ドメインは 日本レジストリサービス というレジストラが担当する。

レジストリ はレジストラが管理するデータベース。ドメイン名と利用者情報の組が保存されている。

whois

whois はレジストリ情報を照会する(ドメイン名を与えてその利用者情報を引っ張ってくる)ためのプロトコル、あるいはサービス。

DNS キャッシュ

名前解決の際、いちいち DNS サーバに問い合わせてたら(問い合わせ先の)負荷がやばい。特に一番最初に問い合わされるルートサーバーは全世界からアクセスされるわけで、そんなの到底捌けるはずがない。

なので、一度照会した結果は手元で保存しておく(キャッシュ)。同じ問い合わせが来たら、手元に保存してる分を使えばいい。

たとえば www.google.co.jp が 172.217.25.195 と名前解決したとすると、DNS サーバはこの結果を手元に保存しておく。次、誰かが www.google.co.jp にアクセスしようとしたら、手元に保存してるキャッシュから「それは 172.217.25.195 だよ」とすぐにわかる。

以下にイメージ。

名前解決する時:

Client ---> DNS-Server1 ---> DNS-Server2 ---> ...
                                              # 世界中の DNS サーバーをあれこれ回って
                                              # 名前解決に必要な情報を集める.
                                              # 負荷高い.

キャッシュがある場合:

Client ---> DNS-Server1
            # ここで既にキャッシュが存在しており、対応できるので
            # DNS-Server2 以降への問い合わせは必要ない.

ただしキャッシュが存在してると、DNS サーバ側の情報が変わった時に対応できなくなるので、キャッシュは一定時間で勝手に消えるようになっている。

ドメイン名、ホスト名、FQDN、DNS サーバー、ネームサーバーの違い

ややこしいのでまとめた。

FQDN = ホスト名 + ドメイン名

www.example.com.jp に対して、

  • www はホスト名
  • example.com.jp はドメイン名
  • www.example.com.jp は FQDN

ちなみに

  • http:// はプロトコル
  • http://www.example.com.jp は URL

DNS サーバーとネームサーバー

DNSサーバー = ネームサーバー。同義語。

パスワード、パスフレーズ、秘密鍵、アクセストークン、二段階認証、ワンタイムパスワードの違い

理解が曖昧だったところもあったので調べた。

パスワード(Password)

言わずもがな、本人認証の常套手段。

パスフレーズ(Pass-phrase)

パスワードの一種で 「フレーズ(わかりやすい言葉)を組み合わせた」「長い」パスワード のこと。

いくつか例を挙げる。

  • 例1: yahariorenoseisyunrabukomehamatigatteiru
    • お気に入りのフレーズモロ
    • 「やはり俺の青春ラブコメはまちがっている」
  • 例2: K1ll_tw0_b1rds_w1th_0ne_st0ne
    • お気に入りのフレーズ + 換字
    • 「一石二鳥の英語 Kill two birds with one stone」
    • iを1に、oを0に、スペースを_に置換
  • 例3: vim-atom-sublime-emacs-eclipse-vscode
    • 好きな単語を並べて区切った(ここではテキストエディタやIDEの名前)

パスフレーズが生まれた背景

  • パスワードの設定は正直面倒くさい
  • でも短めにしてるとセキュリティ上危うい(クラックされる)
  • 強力なパスワードを考えるのは面倒くさいし、覚えるのも大変
  • 何か良い方法はない? → 覚えやすいフレーズを並べて長くするのはどう?

パスフレーズの特徴

  • 長いのでクラックされない(スパコンでも解読できない)
  • フレーズなので覚えやすい
  • 長いけどフレーズなので打ちやすい

パスフレーズの問題点

  • システムによっては文字数制限にひっかかって設定できない
    • 例: 「半角英数8文字以内」
  • フレーズの作り方を工夫しないとパターン(傾向や特徴)が出てしまい、クラックされてしまう
    • 例: 固有名詞やことわざを片っ端から総当たりすれば上記例1は解読される
  • (パソコンはともかく)スマホからは打ちづらい
  • そもそもタイピングに習熟してない人にとっては(入力に時間がかかるので)辛い

秘密鍵(アクセストークン)

プログラマやエンジニアにはお馴染みだが、平たく言うと「自分と相手のみが知っているおまじない」のこと。

  • クライアントは事前にシステムにログインし、秘密鍵を登録しておく
  • クライアントは秘密鍵(アクセストークン)を持っている
  • クライアントはログイン時、システムに秘密鍵を提示する
  • システムは提示された秘密鍵を調べ、正しいものであるか調べる
  • 正しくない → お前誰やねん
  • 正しい → ようこそ。ログインを許す。

普通にログインする際は使わず、スクリプトからシステムの機能を利用する(REST APIを叩くなど)といった用途で使う。たとえば REST API を叩く際に、リクエストヘッダにアクセストークンを付与しておくと、システム側でそれをチェックできる。

パスワードと違う点は、ID が必要ないことと、文字列がべらぼうに長くて複雑(数十から数百文字の英数字列)であること。

※この辺りの話は奥が深く、厳密には秘密鍵=アクセストークンではないが、ここではわかりやすさのためイコールにしている。

二段階認証

パスワード入力 +αで何かを入力させて認証させる方式。+αとして「ケータイに送信されたセキュリティコードを更に入力させる」やり方が多い。

GoogleDropbox を始め、主要なサービスは大体実装している。

Q: 二段階認証はなぜ必要?

パスワードは第三者に漏れたらおしまいだが、二段階認証があればおしまいにならない。たとえ第三者に漏れたとしても、そいつは続くセキュリティコードを知る術がない(コードは本人のケータイに送信される)ため先に進めない。

また、本人は「ログインしてないのになんでセキュリティコードが来てんの?誰か不正ログインしたやろ?」と気付けるメリットもある。

Q: でもいちいちコード打つのは面倒じゃない?

煩わしさを省くため、一度二段階認証した端末については以降のコード入力を省くようになっている。それでも他の端末からログインした場合はコード入力が発生するため、セキュリティは担保される。

ワンタイムパスワード

主に銀行で使われてる方式で、その場限り(ワンタイム)のパスワードを専用の装置やアプリによって生成し、それを使ってログインするというもの。ログイン後、そのパスワードは無効になるため、仮に漏れたとしても問題はない。

メリットとして「パスワードを覚える必要がない」ことが挙げられる。ユーザーは装置やアプリ上でボタンを押すだけで良い。それで表示されたパスワードを打てばいい。

もちろんその専用装置・アプリが第三者の手に渡ってしまうと意味がないので、紛失しないよう管理が必要。

Q: その場限りでパスワード作る?そんなのどうやって実現するの?

専門的な話になるが、 「認証」の基礎知識(7):ワンタイムパスワードの方式 – せぐなべ あたりで端的にまとまっている。

平たく言うと、ユーザー側が持ってる「ワンタイムパスワードを生成する装置 or アプリ」の生成アルゴリズムがシステム側でも保持されているので、システム側は「受け取ったパスワード」を復元して「ちゃんと正規の手順で作成したパスワードだよね?」がわかる。

参考

(おまけ) マジックリンク

初耳だったのでついでに紹介。

ログイン時に ID を入力すると自分のメアドに「ここに書いた URL にアクセスしてね。そしたらログインできるよ」というメールが送られ、そのとおりに URL にアクセスするとログインできる……という認証方法。

チャットツール Slack で導入されている。手順としては、ログイン画面に「マジックリンクを送信」ボタンがあり、これをクリックするだけという感じ。

ファイアウォールやネットワークにおける上り、下り、イングレス(Ingress)、エグレス(Egress)、インバウンド(Inbound)、アウトバウンド(Outbound)の違い

紛らわしいので調べてまとめた。

「上り」と「下り」

  • 上り …… 自分に(外から中に)流れてくる方向
  • 下り …… 自分から(中から外に)流れていく方向

自分に入ってくる方向が「上り」。

たとえばファイアウォールで言うと、外からの通信を弾くのが上り。内からの通信を弾くのが下り。

イングレスとかアウトバウンドとかその辺の用語

  • 上り = Ingress(イングレス) = Inbound(インバウンド)
  • 下り = Egress(エグレス) = Outbound(アウトバウンド)

同義語だと思っていい

自分に入ってくる(INしてくる)のが上り。自分から出ていく(OUTしていく)のが下り。

「上り」と「イングレス」と「インバウンド」の使い分けは?

意味的には同義だが、細かい使い分けはどうなっているのかという話。

答え: ケースバイケースなのでその場の流儀に従いましょう

以下に例を示す:

Adobe Acrobat Reader DC で快適に PDF を読むための設定五つ

Adobe Acrobat Reader は重たいし読みづらいが、設定を工夫すればある程度は快適になる。

(設定1) ウィンドウサイズを保存する

  • メニューバー > 編集 > 環境設定 > 文書 > 文書を再び開く時に前回のビュー設定を復元
  • チェックを入れる

(設定2) ナビゲーションペイン(右ペイン)を非表示にする

  • メニューバー > 編集 > 環境設定 > 文書 > 各文書のツールウィンドウを開く
  • チェックを外す

ナビゲーションペインは邪魔なので消す。使ってるなら消さなくてもいい。

(設定3) 戻る/進むボタンを設置する

  • ツールバー上で右クリック > ページナビゲーションツールを表示
  • 「前の画面」と「後の画面」をクリックしてツールバー上に追加する

戻る/進むの有効性はブラウザで証明されている。が、これらはデフォでは配置されていない。

(設定4) スクロール速度を速める

  • メニューバー > 表示 > ページ表示
  • 「スクロールを有効にする」を選ぶ

Acrobat Reader には「一行ずつスクロール」と「n行ずつスクロール(ブラウザやエディタなど一般的なスクロール」の二種類があって、上記設定を行うと後者のスクロールが使える。

前者はスクロール速度が遅すぎて読み辛いので後者がオススメ。

(設定5) 一つの PDF ファイルを複数タブで開く

これは設定ではなく方法だが便利なのでついでに紹介。

  • メニューバー > ウィンドウ > 新規ウィンドウ をクリック
  • 今開いてる PDF ウィンドウがもう一枚表示されるので、片方のタブ部分を、他方のタブ部分に D&D する

これで一つの PDF ファイルを複数タブで開ける。あっちとこっちを読みたいって時にいちいちスクロールで行ったり来たりしなくもよくなる(タブを切り替えるだけでよい)。

Outlook 2013 で仕分けルール作成が捗る仕分け条件

ズバリ 「メッセージヘッダーに特定の文字が含まれる場合」 である。これ一つでたいていの仕分けは行える。

仕分けとして頻出するのは以下だと思っているが、

  • 発信元に指定メアドが含まれている
  • 件名に指定文字列が含まれている

上記は二つともカバーできる。

私は20以上の仕分けルールをつくっているが、9割近くがこの条件を使っている。

AutoHotkey でメニューの表示位置がずれる時は CoordMode を調べること

以下のようにポップアップメニュー popupmenu1 を表示するスクリプトを書いていたのだが、

; <<< メニューつくってるところは割愛 >>>

; プライマリモニタの中央座標を取得
posobj := get_display_center_pos()
showx := posobj.x
showy := posobj.y

; 取得した中央位置でメニューを表示
Menu, popupmenu1, Show, %showx%, %showy%

メニュー表示位置がどうも中央位置からずれる。見た感じ アクティブウィンドウ次第で位置が変化している ように見える。何が起きているのだろう?とハマっていた。

原因

原因は単純で、 CoordMode という「座標指定時の基準値をどこにするのか」設定が スクリーン上での絶対位置になってなかった から。

AutoHotkey ではこれがデフォルトでは「アクティブウィンドウの左上からの相対座標」になっている。なので、上記のコードは実質

; activewindow_x, activewindow_y が
; アクティブウィンドウ左上座標を表しているとする
Menu, popupmenu1, Show, %showx% + activewindow_x, %showy% + activewindow_x

こうなっているに等しい。

解決

以下のように CoordMode Menu, Screen にて「スクリーン上での絶対位置にする」設定を明示的に指定する。

; デフォは座標指定がアクティブウィンドウ相対になっているので
; スクリーン絶対に直す.
CoordMode Menu, Screen
Menu, menuname1, Show, %showx%, %showy%

AutoHotkey のバージョン情報を確認する方法三つ

色々あるけど微妙に手間かかる。

(方法1)ヘルプを読む

chm ヘルプのホームページに Version v1.1.10.01 みたいな記述があるはず。

(方法2)バージョン情報を表示するスクリプトを実行する

msgbox % "Your AHK version is " A_AhkVersion

(方法3)AutoHotkey.exe のプロパティを見る

実行ファイル右クリック > プロパティ > 詳細タブ

製品バージョン: 1.1.10.1 みたいな記載があるはず。

AutoHotkey スクリプトを ahk2exe でコンパイルしてつくった実行ファイルの仕様

良さそうならメインの実行ファイル化手段として採用したいなと思って、ちょいと調べてみた。

前提

  • Windows 7 x86
  • AutoHotkey v1.1.10.1

Q: コンパイルするためのコマンドラインは?

Ans: Ahk2Exe.exe に /in で ahk ファイルを与えて、/out で実行ファイル名を与える。

$ dir "D:\work\ahk\test_compile" /b
menu.ahk
menu_config.ahk

$ "C:\Program Files\AutoHotkey\Compiler\Ahk2Exe.exe" /in "D:\work\ahk\test_compile\menu.ahk" /out menu.exe

Q: #Include しているスクリも取り込まれる?

Ans: 取り込まれる

前述では menu.ahk から menu_config.ahk を #Include しているが menu.exe は問題なく動作する。

Q: 実行ファイルサイズは?

Ans: (スクリ次第だろうが)100行程度のスクリで 805KB

Q: 実行時に他のランタイム等は必要?

Ans: 不要

生成された実行ファイル一つのみで動作する。

Q: エラー発生時はどう見える?

Ans: ダイアログが出る

タイトルは実行ファイル名、本文はスクリプト実行時に出るエラーと同じ。

Q: プロパティ情報はどう見える?

右クリックプロパティ > 詳細タブの話。

Ans: ファイルバージョンと製品バージョンに「コンパイル元 AHK のバージョン」が入る。

独自のバージョン情報を入れたい場合は Resource Hacker などの「実行ファイルを直接いじる系ツール」を使う。

Q: スクリプト内容は暗号化される?(秘匿できる?)

Ans: できない

実行ファイルをテキストエディタで開いてみると、末尾の方にモロに ahk スクリプトが書かれているのがわかる。

Ahk2exeのソース を見ても暗号化っぽいことは何もしていない。

参考

結論

結論: 採用

  • 手軽だし軽いので、ちょっとしたツールを配布する用途では優秀
  • スクリ内容を秘匿できないので業務利用レベルはさすがにキツイが、ちょっとした個人用ツールなら十分

バックアップソフト Backup で指定バックアップパターンをコマンドラインで実行して即終了する方法

ヘルプに書いてあるけど、サクっと使うためにまとめておく。

開始前ダイアログを出す&終了後の結果も残したまま

"D:\bin\backup_sota\Backup.exe" --name "(バックアップパターン名)"

バックアップを開始するには OK ボタンを押す必要がある。

バックアップ終了後は結果ウィンドウが残ったままなので様子をチェックできる。

開始前ダイアログを出さない&終了後の結果は閉じる

"D:\bin\backup_sota\Backup.exe" --name "(バックアップパターン名)" --close --start

完全に自動化したいならこれ。バックアップ中にウィンドウが表示されるだけで、OK ボタンを押す必要もない。ただしバックアップ終了後も画面が閉じられるため結果は見れない。

Q: 他にも色々オプションあるけど使うべき?

Ans: 使わなくてもいい

バックアップ設定はバックアップパターン側で作り込む。そうしたらコマンドラインからは --name オプションでパターン名を与えるだけで済む。

Slack の代替オンプレ型チャット Rocket.Chat を業務利用している時に知っておくと捗ること

仕事では Slack が使えず Rocket.Chat を使っているのだが、微妙に使い勝手が悪かったり業務利用ゆえの問題があったりしてストレスが溜まる。その辺を軽減するネタが見当たらないこともあり、今回まとめてみることにした。

(前提)

  • 業務としてガッツリ利用している(たとえばメーラーみたく常駐させている)
  • Windows + Firefox で利用している
  • 利用者サイドの話のみ扱う(管理者サイドや開発者サイドネタはほとんどありません)
  • 結果的に Rocket.Chat というよりチャット全般の話が増えてしまったので、Rocket.Chat を使ってなくても参考にできるかもしれません

Rocket.Chat 固有ネタ

実験用のプライベートグループを作る

Rocket.Chat の機能を試したい、書いたメッセージがどのように表示されるか見てみたい、あるいは投稿前の推敲を行いたいといった時のために 実験用のプライベートグループ を作っておくとよい。

プライベートグループは、誰も招待しなければ自分用スペースとして好き勝手に使える。

デスクトップアプリを使う

Rocket.Chat にはデスクトップアプリがある。

GitHub - RocketChat/Rocket.Chat.Electron

ブラウザ版と遜色無い操作感で Rocket.Chat を使うことができる。進んで導入するほど何かに優れているわけではないが、 ブラウザから利用していて問題がある(フリーズが起きやすい等) 場合には試す価値がある。

私の場合、ブラウザから利用していると日本語入力時にたまにフリーズすることがあった(結局 Firefox.exe を殺すしかなくて既に開いてるタブも全部閉じて涙をのんでいた)のだが、デスクトップアプリを使ってからは遭遇しなくなり快適である。

「これのことです」と特定メッセージを指したい時があるが、permalink を使う。メッセージの permalink は引用機能で取得できる。

(追記)最近のバージョンだと「固定リンク」という、まんま permalink をコピーする機能があります。下記は固定リンク機能がない場合に試してみてください。

引用を実行すると、以下のような表記が入力欄に挿入されるが、

[ ](http://(SERVER-IP):(PORT)/group/(GROUP-NAME)?msg=XXXXXXXXXXXXXXXXX) 

この URL 部分がそのまま permalink となる。

メッセージ検索時はクエリをエディタで打ってからコピペする

メッセージ検索は インクリメンタルサーチ(一語入力する毎に検索が走る)が走るため重たい。そのためクエリはどこかエディタ等に打って、それをコピペするのが良いだろう。

メッセージ検索時の on, before, after フィルタはタイムゾーンのズレに注意する

メッセージ側の時刻は GMT、検索時は JST だったりするため、期間系の検索フィルタが正しくフィルタリングされていない(一日分くらいズレてフィルタされる)ように見える。

気に食わないならサーバー側の設定(Rocket.Chatではなくサーバー自体の設定)を変えること。ただ私もまだ試してないので効果は不明。

参考: request: timezone overrides · Issue #3530 · RocketChat/Rocket.Chat

サイドバーを増やしたくないならルームに参加せずプレビューで覗く

公開チャンネルにせよプライベートグループにせよ、ルームに参加するとサイドバーにルーム名が追加される。これが10にも20にもなってくると見通しが悪くなるため、 参加必須でないルームについては参加せず「プレビューモードで覗く」 とよい。

REST API 利用は慎重に

Rocket.Chat は REST API を搭載している が、2018/05/08 現在で work in progress 状態である。万が一不具合でサーバーが重くなったり落ちたりしたら(業務利用しているだけに)インパクトも大きい。そのため普段 Web サービスに対して躊躇なく REST API を叩いてる人は特に注意する必要がある。

(たとえ利用ルールに REST API に関する記載がなかったとしても)念のため管理者に使ってもいいかどうかを確認する ことをオススメする。そうでないと(会社やチームにもよるだろうが) REST API を叩いただけで不正利用や非常識とみなされることさえある。「書いてない管理側の落ち度でしょ」という一般論は(会社やチームにもよるだろうが)通じないこともある。

チャットツール全般に当てはまるネタ

別タブで複数ルームを開いておく

サイドバーのチャンネル名をクリックしてルームを行き来するのは地味に負担が大きい。というのも、行き来する度にルーム内の読み込みが走り表示に時間がかかるからだ。一回ならまだしも、業務で使ってると何回も行き来することになり、結果それなりの時間と集中力が食い潰されてしまう。

よく見るルームについては 別のタブで開いておく。そうすればタブ切り替えだけで切り替えられるので楽だ。

ただしメモリはその分食ってしまうので、どこまでやるかはお使いの PC 性能と相談すること。

デスクトップ通知が邪魔なら切る

デスクトップ通知が有効だと(設定次第だがデフォでは)メンション受信時、画面左下にポップアップが表示されるのだが、これがポップアップは非常に煩わしい。一瞬視界に入っただけでも集中力が削がれる。開発などクリエイティブで集中が必要な仕事の時は特に煩わしい。メールチェックは仕事の効率を損ねると言うが、同じことがチャットでも起きる。

なので 可能なら通知設定は切っておく。その上でチャットの確認は「キリのいいタイミングで」「自分から」行うようにする。Pull 方式のチェックとでも言えば良いだろうか。

※「そんなのしてたら仕事が回らないよ」と思われるかもしれないが、意外と回る。たいていはやり方(コミュニケーションのとり方やチャットの使い方)に問題があることが多い。その辺は本題じゃないので割愛する。

ちなみにチェックすること自体を忘れてしまうならリマインダーを使うと良い。たとえば「Rocket.Chat を見る」というリマインドを毎日朝、昼、夕方の三回分セットしておけば、毎日朝、昼、夕方の三回は必ず読む。

永続(後で見返す)コンテンツは Wiki に書く

(Rocket.Chat に限った話ではないが) チャットは過去メッセージの閲覧に弱い。具体的には、

  • 表示するまでに時間がかかる
  • 表示メッセージの増加に伴ってブラウザが露骨重たくなる
    • 仮に過去一年分のメッセージを表示したらどうなる?地獄だ。

こんな感じだ。とにかく弱い。

なので後で読むようなメッセージについては Wiki などストック情報の扱いに長けたプラットフォームに転記しておく とよい。

Wiki であればページも軽く、ブラウザでサクっと開ける。尤も Wiki の整備や転記といった手間はあるが、その手間をかけるだけの価値はある。過去メッセージを転記するのがだるいなら、メッセージの permalink を書いておくだけでもいい。permalink をブラウザで開くと、当該周辺のメッセージを読み込む挙動となり、周辺の文脈も含めて追える。

最悪 Wiki の整備が無理でも 自分一人だけではテキストとしてローカルに控えておく などの工夫もできる。

大事なのでもう一度言うが、チャットはあくまでリアルタイムにやりとりするものであり、過去の情報を必要に応じて見返すシステムではない。メールと同じ使い方をしてしまいがちだが、過去情報へのアクセスという点では明らかにメールに劣る。 その点を理解せず、時間をかけて過去メッセージを読むのは不毛にも程がある