7000PV/月達成記念、そして転落記念。

基本的にはプログラミングなどを中心とする記事を投稿するブログであるが、たまには最近の出来事についての所感などをつらつらと書き連ねるのもよかろうかと。

ボーナスタイムが終わってしまった、そんな喪失感に苛まれている。
先月、このブログは7000PV/月を達成した。このブログの訪問者数は緩やかな増加傾向にはあったが、2022年6月以前は1500PV/月前後でしかなかった。ネットの辺境に佇む掘っ立て小屋のようなブログであった。しかし、7月は大幅に更新して2500PV/月程度、8月はそこからさらに3倍近い増加と、なかなかの伸び率を叩き出した。著名な技術系ブログ運営者にとっては木っ端のような数字かも知れないが、私にとっては頬の緩む記録と言えた。

何があったのかといえば、Slackフリープランのメッセージ保存期間変更である。従来、Slackは直近10000件のメッセージが閲覧可能で、低速なワークスペースであれば全メッセージを閲覧できていた。しかし2022年7月19日、この上限が2022年9月1日以降は直近90日以内に変更されるという寝耳に水の知らせが来たのだ。流れの速さに関係なく、90日が経過した時点で削除されるのである。この変更はフリープランのユーザーにとってはなかなかの大事件で、Twitter上でも大いに話題になった。テレワークが本格化してSlackにとっては追い風となっていたにも関わらず、シェアはTeamsに奪われ、そしてこのプラン変更である。どうやら大規模な移民を生み出してしまったようだ。これがSlackにとって良い結果となるのかどうか、私には分からない。
その話題の中で、私がGitHubで公開していたSlackLogViewerがにわかに注目を集めた。削除されてしまった過去ログをまるごと全部閲覧できるという、今回の事件を解決する手段たりうるツールだったのだ。2020年9月に公開され、1年10ヶ月で星たった12個しか獲得できなかったクソ雑魚OSSのそれは、Twitterでしばしば話題になったことで一気に星60個を超えた。

まあ、うん、正直、心が踊った。私はこのブログ以外で自作ソフトウェアの宣伝などをするつもりはなかったので、GitHubで星が少ないのも当然のことだったのだが、今回のSlack制限変更によって一時的に需要が増大し、Twitter上で紹介し広めていってくれる人が数多く出現した。私が直接関与しなくてもユーザーが勝手に拡散してくれる様を眺めているのは爽快だった。
しかし、それっきりだった。Slack90日制限の開始直前である8月31日にアクセス数のピークを迎え、その後は急激に落ち込んでいる。多くの人は8月中に対処法を見つけ、途端に興味を失ったのだろう。今はおそらく、Slackの仕様変更などを正しく把握しておらず、いざ9月1日を迎えメッセージが一気に削除されてしまったことに気づいて焦ったお間抜けたちがちらほらと来訪しているのではないかと思う。もう間もなく、アクセス数は以前の水準に戻りそうである。一つの大台と言える星100個に到達するかどうかは怪しい。

私は如何せん慎ましく奥ゆかしい、もとい、チキンでネガティブな日本人なので、自分のソフトウェアを他人に押し付けたいとは思わない。しかし、これを欲している層にうまく届かないことには、広まることなど望めないのである。すなわち、宣伝力の有無である。需要そのものがそれなりにあることはslack-export-viewerが証明しているが、私のソフトウェアはあちらより幾分か優れていると思っているけれども、彼らに知らしめることがまず出来ない。現在SlackLogViewerに星をつけてくれた人たちは、ほとんどが本ブログから誘導された日本人である。GitHubは、単に公開しておけば誰かが見つけ出してくれるような親切な場所ではないのだと、そんな当たり前のことを思い知ることとなった。

GitHubの星は単なる自己満足であって目的ではない。私はプログラマーではないので、GitHubの星獲得数は何のアピールにもならない。そもそもあの星はTwitter等のいいねというよりはブックマークとして用意されているものらしく、評価値そのものではない。しかし目に見える数字として出てしまうものを気にしないのも無理な話で、ちょっと海外勢へアピールする手段を考え始めている。ちょうどslackdumpの開発者のrusq様からコンタクトがあり、今後のSlackのエクスポート補助ツールについて議論しないかと誘われたところである。あちらがどの程度本気で考えているのかは私には知る由もないけれども、slackdumpとの連携については私も色々と考えていたところではあるので、このあたりを足がかりにしてみるのは悪くなさそうだ。とりあえず、何とか星100個を達成したい。

さて、C++関連記事を投稿できないまま1年以上が過ぎてしまったが、まだ今後半年ほどはSlackLogViewerのメンテナンス以上のプログラミングをしている時間はないので、まだ暫くは更新停止、ないし小さな記事程度になるだろう。ああ、そろそろ大規模な開発をしたい。論文の校正には飽きた。

slackdumpの出力ファイルをSlackLogViewerで読ませたいときの注意点。

Slackのメッセージをエクスポートしたい時、最も一般的な方法は公式が用意しているエクスポート機能である。これはGUI上で簡単にエクスポートできること、フリープランであってもパブリックチャンネルであれば過去全てのメッセージをエクスポートできる点で優れている。しかし、ワークスペースのオーナーまたは管理者でないとエクスポート出来ないことに加え、やはりプライベートチャンネルやダイレクトメッセージをエクスポートできないのは辛い。

フリープランでこれらを行う方法の一つが、slackdumpである。

github.com

こちらはメッセージ上限に引っかからない範囲でしか出力できないので、2022年9月1日以降は90日毎にエクスポートしなければならないと思われるが、それでもプライベートチャンネルやダイレクトメッセージのバックアップ方法として十分に意義がある。slackdumpの使い方は以下の記事にとても詳しくまとめられている。

note.com

ただし、SlackLogViewerでこのエクスポートファイルを読む場合、現行の1.1.Beta-5では少し問題があるので、その話をまとめておく。

-downloadオプションは使うべきでない

上記解説ページでは、slackdumpをcommandから実行する際に-downloadというオプションを付けるよう指示されている。これはSlackにアップロードされたファイルを纏めてダウンロードするもので、バックアップ用には便利な機能だ。ただ、*SlackLogViewerは-downloadオプション付きで出力されたzipファイルを読ませると、ファイルを開くことが出来ない。ので、SlackLogViewer用に出力するときは-downloadオプションは使わないこと。

内部的には、SlackLogViewerはjsonファイルのurl_private_downloadに書かれているURLからファイルのダウンロードを試みるものの、slackdumpはこれをローカルのパスに書き換えてしまうのだ。これがSlack公式のエクスポート機能と同等の振る舞いなのかどうか私には分からないが、SlackLogViewer現行版はこれには対応していないのである。

添付ファイルをダウンロードできない。

-downloadオプションを使うかどうかに関わらずファイルをダウンロードできないことがわかった。Slackのワークスペースはユーザー名やパスワードがなければ入ることは出来ないので、当然ファイルのダウンロードにもそのような認証情報が必要になる。なぜ公式のエクスポートファイルでそれらのファイルにアクセスできるのかといえば、それらのURLに認証のためのトークンが付与されているからである。
ただslackdumpが出力するファイルの中のURLには、これらのトークンがない。多分取得できないのだろう。slackdumpには-export-tokenというオプションがあり、これを使うとURLに指定したトークンを付与できるのだが、残念ながらあちらの仕様が特殊で大本のURLだけは意図したように処理されず、これも対策にならない。

現状ではslackdumpのエクスポートを読むとき添付ファイルにアクセスする方法はない。これに関してはslackdumpの開発者と議論中で、将来的に解消される可能性はある。

チャンネル名に全角カタカナ文字が含まれる場合、フォルダ名が狂う。

Slackのエクスポートデータは、各チャンネルと同じ名前が付けられたフォルダの中に、日付ごとにメッセージをまとめたjsonファイルが格納されている。しかし、日本語特有の問題だろうと思うが、チャンネル名に全角カタカナが含まれている場合、zipファイル内のフォルダ名が半角カタカナに変換されてしまうようである。channel.json内のチャンネル名は全角カタカナなのにフォルダ名が半角カタカナになってしまうことで、SlackLogViewerではそのチャンネルを表示できなくなる。

これに関しては手作業でフォルダ名を正しいチャンネル名に修正してもらうしかないが、もしPython導入済みの環境であれば、私の友人が半角フォルダ名のファイルを全角フォルダに自動でコピーしてくれるスクリプトを用意してくれたので、これを実行するのが楽だ。詳細は以下のページを参照してほしい。ただしmojimojiというモジュールのインストールが必要なので注意。

phst.hateblo.jp

この問題はslackdump開発者に報告済みであるが、あちらは間違いなくカタカナの扱いに不慣れなので、対処してもらえるかは何とも言えない。

Windows上でslackdumpを実行した場合、そのzipファイルは展開してから読む。

これはどちらかというとSlackLogViewerの隠れたバグと言うべきなのだが、Windows上でslackdumpを実行して出力されたzipファイルは、SlackLogViewerで開くことが出来ない。Slack公式のエクスポート機能で作られたzipファイルと、slackdumpをWindows上で実行して作られたzipファイルには微妙な違いがあるのだ。

具体的には、フォルダの区切り文字が異なる。Slack公式の方では/で区切られているのに、Windows上でslackdumpを使った場合はWindowsのフォルダ区切り文字である\になっている。

これはまあ、zipを展開してから読んでもらうのが手っ取り早い。おそらく次回更新でこのバグは修正されると思われる。

[SlackLogViewer]Slack過去ログ閲覧ツール更新(5)。

前回(4)と同じく、バグ修正である。主としてMac版の不具合に対応するためのもので、既存のバージョンで満足しているWindowsユーザーは無視しても構わないが、本バージョンからはキャッシュ保存先が変更されるので、キャッシュ機能をバックアップとして使っている人はそこだけ知っておいて欲しい。

SlackLogViewerの説明はこちらへ。
Windows、macOS版のダウンロード先はこちら。

Macで正常に起動しない不具合（Windows、Linuxに対しても影響あり）

macOS上でSlackLogViewerを立ち上げた時、"cannot make cache folder"というエラーメッセージが表示されていたらしい。またGUI上でアイコンが表示されないという問題もあった。これらはGitHubのissue #5と#6で報告されている。

原因は、SlackLogViewerがカレントディレクトリに、ダウンロードしたファイルを保管するCache、アイコンなどの画像が格納されているResourcesというディレクトリがあることを前提に設計していたためである。Windowsなどでは実行ファイルを直接ダブルクリックしたりショートカットから起動したりすることが常なので基本的にはカレントディレクトリはSlackLogViewer.exeと同階層であり、これでも問題なかったのだが、macOSの場合はこれがまずかったらしい。ので、これらのディレクトリの場所の指定方法を変更することにした。

これに伴い、キャッシュファイルの保存先が変更された。デフォルトの挙動は優先度の高い順に以下の通りである。

1. SlackLogViewer実行ファイルと同階層にあるsetting.iniの中にCache/Locationという変数が設定されている場合、そこに保存する。
2. 特定の環境変数（詳細は下記）が見つかった場合、そこを基準にSlackLogViewer_cacheディレクトリを作り、そこに保存。
3. 上記環境変数が存在しない場合、WindowsまたはLinuxの場合はSlackLogViewer実行ファイルと同階層にCacheディレクトリを作成しそこに保存する。macOSの場合はSlackLogViewer.app/Contents/Resources/Cacheの中に保存する。

"特定の環境変数"を参照して作成されるSlackLogViewer_cacheディレクトリの場所は以下の通りである。

• Windowsの場合……%LocalAppData%。典型的にはC:\Users\username\AppData\Localである。
• macOSの場合……$HOME/Library/Caches。
• Linuxの場合……$XDG_CACHE_HOMEが定義されていればそれ、定義されていなければ$HOME/.cache。

setting.iniというファイルはSlackLogViewerの初回起動時に作成される。このときCache/Locationには2.、3.の順で決定された保存先がデフォルト値として書き込まれる。もしキャッシュファイルの保存先を自分で変更したい場合、この時生成されたsetting.iniのCache/Locationを書き換えれば良い。ただし必ず存在するディレクトリを指定すること。もしディレクトリが存在しない場合、cacheディレクトリを作成できないというエラーが表示される。

余談

今回の更新にはLinux、macOSへの対応を行ってくださったcielavenir様、slackdump開発者のrusq様から多大な協力をいただいたことを記しておく。

今回の対応にはひどく苦労した。私はmacOSの仕様なんてろくに知らないのだ。私がMacを使ったのはせいぜい、大学学部生の頃に情報科学系の講義の実習用としてMacをあてがわれていたときくらい。理学部生だった我々がプログラミングを深く学ぶことなどなく、ごく初歩的なインターネットリテラシーだとかC言語のさわりだとかを扱っただけだった。C++による本格的なアプリ開発を行ったことなどあるはずもなかった。Macのアプリケーションがバンドルという特殊な構造になっていることも初めて知った。
そんな中、自力ではデバッグも出来ない中で、なんとかネット上で見つかる記事などを参考に手探りで対処法を探していたのだ。上のお二方の協力がなければどうしようもなかった（私一人ならそもそもmacOS版を公開すらできていないのだが）。

cielavenir様からのコミットでGitHub Actionsを用いたmacOS用バイナリの自動ビルドも可能になったので、今回のような不具合の可能性は否めないものの、とりあえずバイナリの提供はある程度続けられそうだ。

さて、今後はslackdumpの出力するファイルやダイレクトメッセージへの対応などを行うつもりである。ただここ数日は偶然にも時間が取れたが、私の本業を停滞させていた原因がようやく解消されてそちらが忙しくなりそうなので、いつ公開されるかは全くわからない。最悪半年後である。ここ一ヶ月半で一気に増えたユーザーのうち、どれだけの人が今後の更新に期待してくれているのか知らないけれども、まあ気長に待って欲しい。