サブルーチンの確認
perlで自作したおひとり様ActivityPubサーバーはその後も増築改築をちまちま続けていて、例によってその場での思いつき、やっつけ仕事の現物合わせ仕様で、わけわかめ状態となっている。
Activityを約束事どおりに対応するモジュール（pmファイル）で、いったい何をしてるのか。
もうすでに忘れてる自分がいるので、サブルーチンの洗い出し用にテキトーなスクリプトをでっちあげた。という覚え書きが今回のエントリ。
#!/usr/bin/perl
use strict;
use utf8;
use Encode;
my $f = shift(@ARGV);
if(! -e $f ){
printf qq{Not Found pm %s\n}, $f;
exit;
}
open(IN, $f) || die;
my $name; my @buf=<IN>; close(IN);
foreach (@buf){
if( m!^sub (.+) *\{! ){
$name->{$1}++;
}
}
printf qq{sum : %s\n}, scalar( keys %{$name} );
foreach my $sub (sort keys %{$name}){
my $pm = join('', @buf);
my $cnt = $pm =~ s!$sub!!g;
printf qq{%s :\n}, $sub;
my @called; my $zzz;
if( $cnt > 1 ){
my $subname;
foreach (@buf){
if(m!^sub (.+) *\{!){
$subname = $1;
next;
}
if( m!\$self\-\>$sub! && !$zzz->{$subname}++ ){
push(@called, $subname);
}
}
}
printf qq{\t%s\n}, join("\t", sort @called);
}
・サブルーチンの総数
・サブルーチンの名前
・サブルーチンを呼び出しているサブルーチン
ぐらい見えれば、そこそこ役に立つかなあ、と。
文字列検索でひっかけてるだけで、signなんかはサブルーチン呼び出しじゃない部分にもヒットする。本当は動かしながらcaller()でチェックするのが確実…だけど、ざっくり見るだけのためにあちこちにcaller()を仕込むのはうっとーしいんで却下。
使い捨てのつもりで書いたスクリプトだけど、思ったよりちゃんと見えるようにしてくれたので自画自賛＆エントリとして書き起こし
10/4、ポケモンGOの対人戦GBLでACEに到達。
初期レートが1984で、ACE到達時のレートは2007。GBLで遊んでいて、ずっと継続してACEにたどり着いてたんだけど、前期初めてACEに到達できず、今期もやべえかなあ、と思ってたので、ほっとひと息。
まる6年続いているゲームで、まだ全然飽きないのがすげーす。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
小ネタ：pdftotextで文字データを抽出
元データがPDFで、圏点（傍点）やダッシュをPDFから検出する必要にせまられた。
目視確認などありえないんで、テキストデータとして取り出して検索しよう、というのが今回のエントリ…というかエントリにするまでもない内容なんだけど、たぶんそのうち忘れるんで、メモ。
PDFから文字情報だけをひっぱりだすのに定番の「pdftotext」というツールを使う。
perlだけでもできそうなんだけど（PDF::API2あたり）ちょっと時間も押してるんで、外部ツールを間に挟むことにした。
まずは肝腎のpdftotextのインストール。これがpoppler-utilsというパッケージだなんて検索しないとわからなかった（pdftotextというパッケージがあるもんだと思ってた）
以下のコマンドラインでインストール
sudo apt-get install poppler-utils
unix系のツールの例に漏れず、これもいろんなオプションが用意されてるけど、今回必要なのは文字情報だけ。レイアウトデザイン情報やなんかは不要。
rawオプションをつけて利用する。
たとえば「kappa.pdf」の文字情報を抜き出すのは
pdftotext -raw kappa.pdf
こうすると「kappa.txt」に文字情報を吐き出す。ただ、これだとひと文字ずつだあーっと出力されるので、ここからがテキストデータを扱わせたら最強のperlの出番。
pdftotextの出力には改ページがつくので、そこで改行すれば「それっぽい段落」ごとに見えるひとに優しいテキストファイルとなる。
open(P, '-|', 'pdftotext -raw kappa.pdf - ' ) || die;
binmode STDOUT => ":utf8";
open(OUT, '>' , 'kappa.txt') || die;
binmode OUT => ":utf8";
while(<P>){
my $line = Encode::decode('utf8', $_);
$line =~ s!\r?\n!!;
$line =~ s!\x{C}!\n!;
print OUT $line;
}
close(OUT);
close(P);
特筆すべきようなスクリプトじゃないんだけど。
perlは外部コマンドの「標準出力」をパイプで受け取って加工整形できる。
open(P, '-|', 'pdftotext -raw kappa.pdf - ' )
openの
・第2引数で、標準出力を受け取りますよ、という指定
・第3引数はpdftotextの結果を標準出力に出すからね、という指定
これだけでそれっぽい段落にわけたテキストファイルを作ってくれる。
そうしたら、あとは出力されたテキストファイルからダッシュや圏点（傍点）っぽいものをperlで検知するだけ。これはワードで作ったPDFで「、」が圏点となっている。inDesignで作られたデータだと「0」（ゴマ）「4」（ドット）となる。
直接触ってもいいんだけど、一度テキストファイルに吐き出したほうがなにかわからないことが起こった時に便利なので、こういう仕様、段取り。
このスクリプトのおかげで抜け漏れは捕捉できるんでずいぶんラクになった。
以前、目視確認とか無駄なだけだし、んなもんツール作ってやればいいじゃん、とか言ったら、そしたら仕事がなくなる、目視確認手作業修正は必須だ、と言われて心底、呆れた。
カネをもらった上で、人間の作業＝ミスが入り込む原因になる工程を入れるって、いろいろ悪質すぎる。
ITといってもピンキリで、こんなのが入り込んでるから要注意。
そもそも、その程度の仕事なんて、なくなっても問題ないし、特に困らない。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
電子書籍でエラーになる絵文字の検知
今回のエントリは。
経緯
・電子書籍でエラーになるのが絵文字だった。
・元データから絵文字を検知する必要が出てきた。
結論
・perlを使えば絵文字のチェックも簡単だった。
てことなんだけど、調べてみたらunicodeまわりが魔窟でびっくり。またハマりそうなのでメモ。
以下は、何を今さらという話が無駄に長くて、既知のかたには役に立たない内容です。
電子書籍に求められる基準はほぼ以下のふたつ
・Epubcheckでエラーはない。
・kindle previewerでエラーはない。
epubcheckでエラーがなければEPUB3の電子書籍として問題はないし、kindle perviewerでエラーをチェックするのは最大の配信サイトであるAmazonでエラーがあったら商売上よろしくないから。
上記２つのチェックをクリアしたのに、一部の配信サイトでエラーになるという指摘があって、追いかけてみると、問題になったのが「絵文字」
「😀」←こういうやつ
原稿に絵文字があったんで、あれ？これってイケるんだっけと思って作ってみて、上記２つのチェックにかけてもエラーはなかった。
文字コードがShiftJISの時代ならともかく、今どきはutf8。
utf8のおかげで文字化けなんかを気にする必要はほぼなくなった。機種依存、環境依存文字に神経質にならなくていいのはストレスフリーで、いい時代になったもんだとのんきに感慨深い今日この頃だったのに…。
文字として問題はないんだけど、配信サイトごとにビューワーが違ってたりして、そのビューワーが絵文字に対応してるかどうかのことだと思う。
「EPUB | CSS組版ブログ」
https://blog.antenna.co.jp/CSSPage2/archives/category/epub
↑絵文字なんかについて、縦書きのepub3が始まった頃に議論があったらしい。
（電子書籍元年当時の話が読めるのでオススメ）
「横倒しのまま」にするのか「正立させる」のか。文字の意味的に方向があるものは正立させる？とか。そのあたりのすり合わせが問題になってたっぽい（という理解でいいのかなあ）
これは縦書きの場合、見た目けっこう致命的なので、たぶん、絵文字の対応を見送ったビューワー＝配信サイトがあったんじゃないかと思う（憶測）
あるいは、そもそも、絵文字は環境ごとで見え方も違うのでそこが問題なのかもしれない（憶測）
そんなこんなの名残りもあって、面倒なものは却下、ということで今でもエラーにする配信サイトがある、んだろう（めっちゃ憶測）
epubcheckでもkindle previewerでもエラーにならない文字を自前で検知する必要にせまられる事態となった。
電子書籍のボリュームを目で追ってその中から絵文字を見つける、目視で探すなどありえない。必ず漏れが出る。
なもんで、絵文字の文字コードを調べてみて改めて今さらびっくりのunicodeだ。
ちなみに、文字を表示させるためには、以下の２本立てになっている。
・unicodeの文字コード表で文字を指定特定していて
・文字コードをエンコードすることで文字を表現する
これ、けっこう勘違いするんだけど、utf8というのは文字コードではなくてunicodeの文字コードをエンコードする方法の名前のこと。
以下のサイトを読んでまたびっくりすることをおすすめする。
「文字コード再入門 ─ Unicodeでのサロゲートペア、結合文字、正規化、書記素クラスタを理解しよう！」
https://en-ambi.com/itcontents/entry/2020/04/28/103000/
「書記素クラスタ - daiizfeel 2022」
https://isobe-yaki.hateblo.jp/entry/2023/07/20/194803
てのはともかく、読んでも難しいんで、なにか大変なことになってるんだなあ、でOK。
そもそもutf8でエンコードされた、日本語などは、ひと文字を表すのに、そのコードは3バイト使う。
ひとつの文字がアルファベットのように1バイトではないので
たとえば「日本語の文字」の６文字は、１つの文字に３バイトのコードが必要で、文字列の長さをバイト数でいうと18となる。
文字数いくつだっけ？て時に、バイト数の18ではなくて「正しく」６と数えるためにエンコードされている必要がある。
unicodeのコードをエンコードして初めて「文字として認識される」
このエンコードする方法がutf16だったりutf8とか呼ばれて、エンコードすることで初めて「文字として認識された文字を表示する＝扱うことができる」という変な日本語。
perlの場合、utf8フラグというのを使うことで問題解決する。
my $str = '日本語の文字'
my $utf8 = Encode::decode('utf8',$str)
print length($str)
→18文字
print length($utf8)
→6文字
perlはこのおかげで、文字の扱いについて、普段はまずほとんど、こんな面倒くさいことを意識する必要はなくて、なもんで、すっかりわけがわからず混乱してしまったのが昨日今日の話、だ（とほほ
unicodeとutf8についてのおさらいができたところで、やっと本題。
じゃあ、絵文字を検知するには絵文字が使ってるコードを見つければいいだけじゃん。簡単だろ、と思ったらまたひと悶着。
ていうか、ここからが今回の本丸、一丁目一番地（死語）
utf8フラグだけでは解決しない「結合文字」というのがあった。
「１つの文字を表示しているのは、１つのunicodeのコードポイント」とは限らない。
ひとつの文字を表示、扱うのに、複数のunicodeのコードポイントを使ってるケースがあって、見た目のひと文字とそれを表すコードは1対1ではない、ということ。
perlでutf8フラグがついていてもutf8の文字コード（←unicodeコード表によるコードではなくてエンコード後の文字コード）2つ結合した文字はlength()では意図通りに取得できない。ひと文字として扱ってほしいのに、たとえば二文字としてカウントされてしまってお手上げ。
実のところ、書記素クラスタというのはこういう結合文字も含めた呼び方で、書記素クラスタに対応すれば「結合文字」も「ひと文字」として扱うことができる。書記素クラスタというのがなんだか「とても面倒くさい」というのはこのあたり。
こうなってくると、電子書籍でエラーをなくすために、なんでこんなことまで調べにゃならんのか。そもそもレアケースだし、配信サイト個別のクレーム対応でいいんじゃないのか。と思わないでもないけど。乗りかかった船だししょうがない。
話がそれた。
perlはこれも解決してくれる。て、テキストを扱わせたらperl最強じゃね？
「絵文字を含む文字列を分割～解説編～」
https://www.lemorin.jp/perl/3b_split_char.html
↑こちらのサイトに知りたいことのすべてがあった（多謝
my $line = Encode::decode('utf8', $_);
my $len = length($line);
print $len . "\n";
my @x = $line =~ m!\X!g;
print scalar(@x) . "\n";
length()では「見た目のひと文字」じゃなくて困ってたところ、perlでは「いい感じに」「ちゃんと」文字として認識できる文字のための正規表現「\X」が用意されてた。
「perlの正規表現」
https://perldoc.perl.org/perlrebackslash#Misc
ということで、やっと本エントリの締めとなります（長っ！
問題のない文字ダネを削除して残った文字を正規表現「\X」で配列に取り出して、「見た目のひと文字」をコードポイントにバラして16進表現して絵文字のコードに検索をかける。検索がヒットしたら、それはイコール絵文字。
「HTMLの絵文字 文字コード表」
https://gray-code.com/html_css/list-of-emoji/
↑絵文字のコードはこちらの一覧から拝借しました。
こちらで掲載されているコードを絵文字判定の対象としました。
これでやっと絵文字検知。
前から言ってるんだけど、人間の目視確認、手作業修正（目grep、手marge）なんて1mmも信用できない。特におれ。なので機械に頼めるなら機械に任せるのが正解。
↓こちらも参考になりました
「Perl 5.26 & Unicode 9.0 で変わる書記素クラスタ(grapheme cluster)のお話」
https://shogo82148.github.io/blog/2017/08/25/unicode9-grapheme-cluster/
「UTF-8の文字コード表」
https://orange-factory.com/dnf/utf-8.html
本エントリとはまったく関係ないけど。
この埼玉県八潮市の資料館はびっくりの充実。行く前は小学校の教室ぐらいなもんだろ、と思っててすみませんでした。
交通アクセスにちょっと難があって、気楽にとはいえないけど、行けるかたはぜひぜひ
https://www.city.yashio.lg.jp/kurashi/shisetsuguide/shiryokan/index.html
[08/25 16:58:54] いろいろ間違えてたので改稿
「文字につかうバイト数」と「コードポイント」を混用していた、という乱暴な理解だった（恥
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
縦書き電子書籍のための縦中横
青空文庫に限らず、縦書きのEPUB電子書籍を作る時に半角の英数字を縦にするための小ネタが今回のエントリ…なにを今さら、というネタで、縦書き文章で半角英数字の縦中横なんて当然。
それでもネタとして取り上げるのはビミョーに考えることがあって、たぶん、どんなことを縦中横にするのか、どうやってるのかがいろいろあるから。特にWEB経由の文章は半角英数字がてんこ盛り。全部対応するのはやってられないけど。
・一文字の英数字は全角の英数字にして縦表示にしたい。
・数字の3桁以上は縦中横にすると無理矢理感が強い。この場合はそのまま転がしておきたい。
↑このへんがこだわりどころ。
そのために使ってるのが以下のもの
置換する時にゴソゴソする必要があったのでメモ…「1 while〜」のあたり、たぶん5分後には忘れる
・perl
sub _tcy{
my $self = shift;
my $str = shift;
return $str if $str =~ m![0-9][0-9][0-9]+!;
$str =~ s!([a-zA-Z0-9\!\?][a-zA-Z0-9\!\?]+)!sprintf(qq{<span class="tcy">%s</span>}, $1)!eg;
return $str;
}
sub h2z{
my $self = shift;
my $str = shift;
$str =~ tr/a-zA-Z0-9\!\?/ａ-ｚＡ-Ｚ０-９！？/;
return $str;
}
sub add_tag{
my $self = shift;
my $str = shift;
$str =~ s!^([a-zA-Z0-9\!\?])([^a-zA-Z0-9\!\?])!$self->h2z($1) . $2!e;
$str =~ s!([^a-zA-Z0-9\!\?])([a-zA-Z0-9\!\?])$!$1 . $self->h2z($2)!e;
1 while $str =~ s!([^a-zA-Z0-9\!\?])([a-zA-Z0-9\!\?])([^a-zA-Z0-9\!\?])!$1 . $self->h2z($2) . $3!eg;
$str =~ s!([a-zA-Z0-9\!\?][a-zA-Z0-9\!\?]+)!$self->_tcy($1)!eg;
return $str;
}
・style sheet
.tcy {
-webkit-text-combine: horizontal;
-epub-text-combine: horizontal;
}
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
Fediverseの辺境で秘密基地
この記事は Fediverse Advent Calender 2023 （第三会場）18日目の記事です。
Fediverseというネットの連合空間、ActivityPubという共通の言葉を喋るサーバー群というのが面白そうで「いっちょかみ」してみました。以下は、その時々の経緯というか思ったことの垂れ流しエントリとなります。
ちなみに、還暦過ぎのポンコツで、話が無駄にだらだら長いのはご容赦ください。
■レンタルサーバーとperlでおひとり様
MastodonやMisskeyをインストールして運用管理するスキルはわたしにはないので、自分のできる範囲、最小限のActivityPubサーバーをperlで自作実装しました。
レンタルサーバーとドメイン、perlがあれば、それ以外に新しく必要なものはなくて、このブログなど今まで使ってるロリポップのライトプランの環境で十分でした。
試しながら少しずつ実装していったんですが、おひとり様サーバーは、たぶんみんな大好き「秘密基地」ごっこ。
いちいち面白くて、すっかりハマりました。空いた時間のほとんどを費やしてます。
■おひとり様サーバーとして必要なことは２つ
・Fediverseの仲間入り、アカウントとして認識されること
・ActivityPubの決まりごと通りにGETやPOSTなど、リクエストのキャッチボールができること
■Fediverseにわたしが来た！
すみません。言ってみたかっただけです。
7月12日。Fediverseからアカウントとして認識されました。
何をどうすりゃいいのかまったくわからない状態からだったので、グーグル先生に聞きまくりです。
nodeinfo(json)
host-meta(xml)
webfinger(json)
actor.json(json)
以上４つのファイルを用意すればいいという話だったのでサーバーに設置。
今回作った自分のアカウント「@t2aki@tokoroten.doncha.net」をMastodonで検索してみたら、アカウントとして認識されました。
ただ無言で顔を出しただけなんですが、これで念願のFediverse仲間入り！です。
■ActivityPubおひとり様サーバー最低限の実装
アカウントとして認識されたら、後はActivityPubの決まりごとをちゃんとキャッチボールできればOKです…とか言って、これもまったくわかってなくて「そこからかよ！？」の状態でした。
リクエストのキャッチボールを始めるにはHTTP Signatureが必須になります。
（このリクエストはわたしが投げたものですよ、というのを保証するサイン・署名みたいなもの、という理解で大丈夫かな）
ところが、レンタルサーバーのロリポップでは署名のために一般的に良く使われているらしい「Crypt::OpenSSL::RSA」というperlのモジュールがない。つまり、Signature、署名ができない、ので立ち往生。
しかたなく、ローカルのPCに「Crypt::OpenSSL::RSA」をインストールして、PCのコマンドラインから投稿を送信することにしました。
7月26日。右往左往しながらも、Fediverseからアカウントとして認識されて、HTTP署名付きで投稿ができるようになりました。
発信専用と割り切ればこれでひとつゴール達成ということでしょう。
この時点でこのアカウントのフォロー/フォロワーはほかのサーバーに登録した自分のアカウントだけですが。
しばらくローカルPCからの発信専用でやってたんですが、WEB上で作業が完結した方が手間もなく気楽だし、また、ほかのひとの投稿をこのサーバーで読めないのは物足りなくなりました。
…というか。送信するのはローカルPCから、ほかのひとの投稿を読むのはMastodonのクライアントを立ち上げて、というのはやっぱり面倒くさいです。
ふたたびグーグル先生にお願いしたところ、署名するために必要な、PurePerlの（perlだけで実装されている、ユーザーレベルでインストール可能な）Cryptモジュールを見つけたので、ロリポップにインストールしました。
このperlだけで署名できるモジュールの作者さんには感謝するばかりです。
8月22日。HTTP Signatureを解決することで、やっとリクエストの送受信、キャッチボールができるようになりました。最低限の構成ですが、おひとり様ActivityPubサーバーということで大丈夫でしょうか。
■おひとり様サーバーのタイムライン
【ローカルタイムライン】
サーバーに登録しているユーザーの投稿が流れるタイムライン。
おひとり様なのでわたし一人の壁打ちタイムラインです。Fediverseに投げ込むには一意のIDが必要で、投稿へのURLもそれをもとに生成します。そのためにデータベースを使うのが手っ取り早いし、以前から使ってる自分メモ用の掲示板を改築して流用しました。
【ホームタイムライン】
フォローした人たちの投稿が流れ込んでくるタイムライン。
ここは考えなきゃいけないことがいろいろありました。
その１．
まず大前提として
「ひと様のデータは持たない、抱え込みたくない」
わたしのショボいスキルと還暦過ぎたポンコツの体力だと何があるかわからないので、リスク回避が最優先です。
その２．
タイムラインというからには「投稿は流れて消えていく」
流されてしまったものは見ない、アクセスしてたまたまその時その場にあるものを見るモノだということですね。
「袖すり合うも多生の縁」です。
ということで、こちらはデータベースも使わず、保存する投稿は、上限20個、保存期間最長1日。それ以上は古いものからところてん式に押し出されて削除、遡ることができないタイムラインということにしました。
（保存するNoteは宛先がPublic指定されているもの・わたし宛Mention投稿。それ以外は破棄）
そもそもホームタイムラインを見るにはログインが必要で、おひとり様サーバーでログインできるのはわたしひとり、見ることができるのはわたしだけです。
自分の使い方として、twitterもFacebookもそうですが、スクロールして遡るのはせいぜい2〜3画面だったので、上限20個保存ぐらいでも問題はありません。
アクセスしない間も、飛んでくるリクエストをcronで処理することにしたので、わたしが知らないうちに流れてきて、知らないうちに消えていく投稿の方が圧倒的に多い状態です。
SNSとの距離感はこのぐらいでちょうどいいんじゃないかと思ってます。
■タイムラインの育成、フォロー・フォロワー
なにはなくとも、まずフォローをして繋がらないと始まりません。
最初は、すでに登録して参加している別サーバーの別アカウントでフォローしているひとたちを、このおひとり様サーバーから少しずつフォローしました。
（聞いたこともない変な野良サーバーということもあってか、403や401で弾かれてすべてはフォローできませんでしたが）
こちらでフォローをしていくことで、ほかのひとの投稿を流し込んで読めるようになりました。
おひとり様サーバーでタイムラインを作ってると、フォロー/フォロワーでいうと、いかにフォローするのが大切かというのを実感します。
タイムラインというのは、盆栽とか本棚とかと同じ「よく育ってくれましたねえ」の世界。
twitterやFacebookだとフォローを見つけるのもそんなに大変でもないんですが、連合サーバー群だとなかなか難しくて、いくつかのサーバーにアンテナを張って少しずつこちらのタイムラインに持ってくるしかなくて。地引網でどばっと攫うのと、釣り竿を垂らして一本釣りするのと。それがまた面白いんですが。
サーバーごとの特徴があって、他のサーバーのアカウントをフォローして投稿の流入経路をひとつ増やすだけで、それまでになかった投稿が流れるタイムラインになります。
せっかくなので、いろんなサーバーをフォローしたいと思ってます。
（今ではフォローしているひとのブースト経由で他サーバーの様子も垣間見えるので、フォローを探すのもほとんどこのホームタイムライン経由になっています）
twitterなんかだとフォロワー数でのマウント合戦が見られますが、タイムラインの面白さは、フォロワーの数ではなくて、どれだけフォローしてるか、でしょう。
■おひとり様サーバーという名の秘密基地
ActivityPubという共通の言葉で繋がっているので、登録するサーバーに拘る必要はありません。どのサーバーにいても他のサーバーをフォローできる、繋がって広がるのがFediverseの特徴・メリットです。
…とはいえ、いろんなサーバー、それも個性的・特徴的なサーバーがたくさんあって、どのサーバーにしていいのか悩んでしまいますよね。
それなら、おひとり様サーバーを立ち上げて、そこを起点・窓口にActivityPubを喋っていろんなサーバーのアカウントをフォローしてFediverseに参加してみよう、そんなのが自分で作れたら面白そう、というのが始まりでした。
Activityを１つ実装するたびに、これってどうして必要？これは何か理由があるよね？など、いろいろ考えて、自分で決めて自分で作る手作り秘密基地です。
目の前にある20個だけでそれ以上は遡れないし検索もできないホームタイムラインは、穏やかに過ごせるもんだなあ、と眺めてます。
自分のために自分で作った場所というのはストレスフリーで居心地が良くて入り浸り状態。すっかりログインすることがなくなったtwitterやFacebookを見ていた時以上の時間をここで過ごすようになりました。
Fediverse空間のどこかでお会いすることがありましたら、どうぞよろしくお願いします。
だいたい映画、小説、アニメなどについて垂れ流してます。
鬼太郎誕生スゲー、復讐の記憶やべえ、トム クルーズおかしいだろ、やっぱルブランのアルセーヌ・ルパンだわ、など語彙力に問題のある投稿を見かけたら、それはたぶんわたしです。
ちなみに。
『鬼太郎誕生 ゲゲゲの謎』と『復讐の記憶』はわたしが今年映画館で観た映画でベスト。
この2本とも、おひとり様サーバーに流れてきた投稿で知った・気づいた作品です。フォローしたひとたちのおかげです。ほんとウチのおひとり様サーバーのタイムラインは「よく育ってくれました」（自画自賛）
■おひとり様サーバーを作るのに参考にさせていただいたサイト。
・まさに、このひと言。
「Webhook的に ActivityPub に投稿する実装を作った」
オープンな仕様 ActivityPub の力を借りて自前実装で他の実装とつながれる体験は心躍るものがあり
・perlでActivityPubサーバーを立ち上げるならこちらにすべてがあります。
「Fediverse入門―非中央集権型SNSサーバを作ろう！」
・静的ファイルだけでActivityPubサーバー構築。こちらの具体例が参考になりました。
「NetlifyとSupabaseでほぼ静的なActivityPubサーバ」
・こちらを発端としてActivityPub実装についてのサイトを辿りました。
「田舎の昼のサイレンbotをActivityPubで実装する(マストドンにアカウントを認識してもらう編)」
・レンタルサーバーとperlのCryptモジュール
「ロリポップ！レンタルサーバー」
「Crypt-Perl-0.38」
■蛇足というか手前味噌というか
わたしのActivityPub自作実装について。
「おひとり様ActivityPubサーバー自作実装メモ」
Follow、Like、Announce、Attachment、Hashtagなどを少しずつ実装した時の具体的なメモをまとめてます（関連する各エントリは 「ActivityPub」 というタグづけしてます）
ActivityPubの共通言語として飛び交うJsonの具体的な例を残すようにしてますので、何かのお役にたてれば幸いです。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
おひとり様ActivityPubサーバーにブースト実装
twitter（現X）に代表されるSNSの一番の特徴はリツート（ブースト、リポスト）
これがあるおかげで？せいで？SNSへの投稿は拡散力を持つことになった。良い悪いはおいといて、ウチのおひとり様APサーバーにも実装してみた。
考えなきゃいけない一番の優先順位は。
「デマの拡散に加担してはいけない」
なので、ブーストはブースト取り消しの実装と同時。
ブーストはActivityPubだとタイプAnnounceのjson。対象となるNoteのIDをobjectに入れる。
宛先の「cc」には自分のfollowersに、対象となるNoteの投稿者も含めておく。
{"@context": ["https://www.w3.org/ns/activitystreams", {"Hashtag": "as:Hashtag"}],
"type": "Announce",
"id": "https://tokoroten.doncha.net/t2aki/announce/TIMESTAMP",
"actor": "https://tokoroten.doncha.net/t2aki",
"to": ["https://www.w3.org/ns/activitystreams#Public"],
"cc": [DELIVER-LIST],
"object":"NoteID"}
Announceの取り消しはタイプUndoのjsonに、Announceに使ったjsonをobjectにそのまま入れる。
{"@context": ["https://www.w3.org/ns/activitystreams", {"Hashtag": "as:Hashtag"}],
"type": "Undo",
"id": "https://tokoroten.doncha.net/t2aki#UUID",
"actor": "https://tokoroten.doncha.net/t2aki",
"object":ANNOUNCE-OBJECT}
以上のjsonを自分のフォロワーさんのinboxに署名付きpostでリクエストをすれば、ブースト・ブーストの取り消しとなる。
これだけっちゃこれだけなんだけど、ブーストはスクリプトじゃないところに問題があるんだよなあ。
ブーストを実装したいと思ったのは。
いま、フォロワーさんの数が16人ほどで拡散力もなにもないんだけど、それでもイベントのお知らせや、発売の宣伝なんかは、微力ながら協力できればなあ、というのが動機。
せっかくSNSなんだし。
ブーストはヤバイなあと思うのは。
デマの拡散に加担する可能性、というのがもちろん一番で。
それ以外というか、他人の投稿を拡散することで自分が何かを語ったつもりになる、という乗っかりの承認欲求、自己顕示欲を得られるところ。
自分の頭で考えて自分の言葉で語ることをしなくなる、簡単に闇落ちする（自戒をこめて）
実装はしたけど、ブーストするのは基本的にイベントや発売告知だけにする。
また、ウチのおひとり様は、他人のデータを持たない、というのが原則。
なので、Annouceの投稿も期限つき。最長7日間にした。
イベントなんかは終わってたら残念だし、発売関連は初動に少し貢献できれば十分かなあ、と。
ひとつ何かを実装するのに、やっぱりけっこういろいろ考慮しなきゃいけないことってあるもんだなあ(今さら
自分のとこだけのことならどうでもいいんだけど、ActiviyPubで繋がるわけだから、そりゃそうかという話。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
