最近二つほどツールを作り、Webツール置き場に配置したので、そこで得た学びや、作る時に意識したことについても書いてゆく。
まずENV Checkerを作った話。
端的に言うとCyberSyndrome : ENV Checker - 環境変数チェッカーのパクリである。但しJSがないと動かない。
違いとしてはCyberSyndrome側で見れる情報のうち、ユーザー環境に起因しない情報を大幅に削り、ユーザー環境をメインに出せるようにしているほか、IPv4とIPv6の表示にも対応している。
作りとしては必要な情報を返すAPIを3つ用意し、ページを表示したときにJSがそれぞれを叩きに行き、その結果を表示している。
Get Enviroment APIはIPアドレス以外の環境変数を返却するもので、Get IPv4 APIはIPv4アドレスとホスト名、Get IPv6 APIはIPv6アドレスを返すように作ってある。
なぜこの様な分け方にしたかというと、Get Enviroment APIはIPのバージョンを問わない情報しか返さないが、IPアドレスまで返すようにするとIPv4に付随する情報やIPv6アドレスを返すことになるため処理が煩雑になる。
これは実装としてはCGIの環境変数をそのまま返しているのでREMOTE_ADDRに:が含まれているかどうかを見てIPv4か、IPv6かを振り分ける処理が必要になるからだ。
一方でGet Enviroment APIが環境変数だけを返すことに専念できるのならば、IPv4に付随する情報はGet IPv4 APIを叩けば取れるし、IPv6はGet IPv6 APIを叩けば取れるため、分岐処理が不要になる。
これによって各APIは単一の責務だけを持つことになり、コードの複雑化を回避できるといった寸法だ。この程度のシンプルな実装に求めることではないし、現状では無価値ではあるのだが、常日頃から意識することで、より複雑なものを作る時にも生かせるだろうし、将来何か改修するときにも作りが単純なほうが理解しやすいと思うので、こうしている。
IPv4とIPv6のAPIをどう分けているかというと、これはDNSレベルで解決している。Get IPv4 APIのエンドポイントにはAレコードのみを、Get IPv6 APIのエンドポイントにはAAAAレコードのみを設定することで、クライアントが接続する際に使用するIPバージョンを強制している。
こうすることで、各APIは単純にREMOTE_ADDRをそのまま返すだけでよくなり、IPバージョンの判定ロジックを一切持たなくて済むのが利点だ。欠点としてはAPIの数が一つ増えるため、管理コストは増えているといえるだろう。しかし分岐ロジックというのは往々にしてバグを生む存在であり、ないに越したことはないと思い、こういう設計にした。
また画面の描画をJavaScriptにさせているのも、こういったいわゆる関心の分離の思想によるところが大きい。やろうと思えばIPアドレス以外はCGIで表示して、IPアドレスのところだけをJSで書き換えることも、当然できる。出来るのだが、責務を分けるにはデータを返すだけのエンドポイントと、それを受けてJSで書き換える手法のほうが、より責務がはっきりしていて、わかりやすいのでこうしている。疎結合ということでもある。
項目値をダブルクリック・タップすることで値をコピーできるようにしているのも、地味だがこだわりポイントだ。
余談だが、先日Value-DomainでcertbotのDNS Challengeをやるスクリプトを書き直したのは、このドメインにTLS証明書を付与したり、DDNSできるようにする目的があったのが大きい。
というのも、このENV Checkerの開発にはipv4.lycolia.infoとipv6.lycolia.infoというドメインが関係しており、私の自宅サーバーの環境はIPv4がコロコロ変わるためDDNSが必須だった。
私が利用しているDNSレジストラであるValue-DomainはDDNS用のエンドポイントがあるのだが、1回1ドメインしか更新できず、60秒に1度しか叩けないという制約があり、これを回避するためには、Value-DomainのDNS APIに対して、一回で複数ドメインのAレコードを書き換える必要があった。
また同時に、以前使っていた、TLS証明書更新ツールである、value-domain-dns-cert-register (vddcr)はNode.jsのアップデートなどに伴う頻繁なメンテナンスが必要だったり、動作検証不足があったり、様々な面倒ごとがあり、これ以上触りたくなかった。
そんなこんなの流れがあり、ENV Checkerを作る中でOpenWrtからValue-Domainに複数サブドメインのDDNSを行うツールを作ったり、新たなTLS証明書更新ツールを作り、その検証をしたりしたのだ。
もう一つはQRコードジェネレーターを作った話。
QRコードジェネレーターなどググれば無数に出てくるわけだが、意外と読み取り可能な最小サイズかつ、それをSVGで出力できるものを見つけることができなかった。そこで作ることにした。
とはいえ、作ったのはフロントエンドだけで、QRコードの生成自体はqrcode-svgを使わせてもらっている。これはこのライブラリのデモサイトで、理想の要件のものが作れることが分かったからだ。
なぜデモサイトで使えるのに、わざわざ作ったかだが、まずこのデモサイトでは最小サイズのQRコードを簡単に得ることが困難だったほか、256px以下のサイズにすることが想定されていないように見えたからだ。少なくともUIをクリックしてDIMENSIONを256px未満にしようとしても出来なかった。
また、デモサイトはいつか消える可能性もあるし、ブックマークするのも面倒なので、自分でホスティング出来るなら、それをするに越したことはなかったというのもある。
これを作っている中で得た学びとしては、カラーパレットの入力UIがWeb標準で可能になっていたことだ。そこら中で見かけるし標準であるんちゃうか？と調べたらあったので採用した。こういう複雑なものは昔であれば恐らく何かしらのライブラリを使うか、気合で作る必要があったと思うが、全く世の中は便利になったものだ。
また、こちらの実装方法については、HTMLの標準機能でカラーパレットを使ったカラーコード入力UIを作る方法の記事で紹介している。
他にもQRコードの周りには余白が必要ということも知れた。QRコードの開発元であるデンソーウェーブでは余白の求め方の計算式が解説されている。仕様上は適切な余白がない場合、読み込めない可能性があるようだ。これは恐らく周囲の図形とQRコード本体を光学的に分けて認識させるために必要なのだと思う。
なお、今回作成したQRコードジェネレーターには余白の自動調整機能は実装していない。理由は単純でサイズを自由に変えられる仕様上、帳尻をつけるのが面倒だからだ。要は手抜きである。
Webツール置き場のドメイン配下は元々全てペラのHTMLで実装していたのだが、ページが増えるごとに共通部分のhead要素の管理が煩雑になっていた。そこで、PHPに置き換えることにした。
結果として、以下のように、head要素の中身を共通化することができた。
まぁやっていることとしては高校時代にPHPで静的HTMLの内容を共通化していたのと何ら変わらないので、何故今更そんなことを…という感じだが、元々は静的HTMLで済むものは静的HTMLのほうが表示速度が速くシンプルでよいよなという意図で、静的HTMLにしていたのだが、数が増えてくるとそうも言ってられないということで対応した形だ。こういうのは事前に考慮しすぎると、早すぎる共通化やKISSの法則的なリスクを孕むと思っていて、定期的に振り返り、都度対応するほうが良いと感じている。いや、この程度の内容でそこまで考える必要はないと思うが…ｗ
<!DOCTYPE html>
<html lang="ja">
<head>
- <meta charset='utf-8'>
- <meta http-equiv='X-UA-Compatible' content='IE=edge'>
- <title>Slackのリマインダーコマンドを作るやつ</title>
- <meta name="referrer" content="no-referrer-when-downgrade"/>
- <meta name="viewport" content="width=device-width, initial-scale=1">
- <meta name="author" content="Lycolia Rizzim">
- <meta property="og:image" content="https://tool.lycolia.info/slack-remider-creator/OGP.png">
- <meta property="og:site_name" content="Lycolia">
- <meta property="og:title" content="Slackのリマインダーコマンドを作るやつ">
- <meta property="og:description" content="必要事項を埋めることでSlackの/remindコマンドを生成するやつ">
- <meta property="og:type" content="website">
- <meta property="og:image" content="https://tool.lycolia.info/slack-remider-creator/OGP.png">
- <link rel="stylesheet" href="style.css">
- <script src="check.js"></script>
- <!-- Matomo -->
- <script>
- var _paq = window._paq = window._paq || [];
- /* tracker methods like "setCustomDimension" should be called before "trackPageView" */
- _paq.push(['trackPageView']);
- _paq.push(['enableLinkTracking']);
- (function() {
- var u="https://analytics.lycolia.info/";
- _paq.push(['setTrackerUrl', u+'matomo.php']);
- _paq.push(['setSiteId', '3']);
- _paq.push(['enableHeartBeatTimer', 10]);
- var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
- g.async=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s);
- })();
- </script>
- <!-- End Matomo Code -->
+<?php
+require_once('../template.php');
+
+renderCommonHead(
+ thumbnail: 'https://tool.lycolia.info/slack-remider-creator/OGP.png',
+ title: 'Slackのリマインダーコマンドを作るやつ',
+ description: '必要事項を埋めることでSlackの/remindコマンドを生成するやつ'
+);
+?>
</head>
template.phpの中身
関心ごとに関数を切り分け、呼び出される側は呼び出す側に依存するように設計することで、親が子の変更に引きずられないように保守性を意識した設計にしている。他にもほとんど固定値であるものについては運用を平易にする観点からOptional化して、初期値を設定している。
<?php
function buildMatomo() {
return <<<END
<script>
var _paq = window._paq = window._paq || [];
/* tracker methods like "setCustomDimension" should be called before "trackPageView" */
_paq.push(['trackPageView']);
_paq.push(['enableLinkTracking']);
(function() {
var u="https://analytics.lycolia.info/";
_paq.push(['setTrackerUrl', u+'matomo.php']);
_paq.push(['setSiteId', '3']);
_paq.push(['enableHeartBeatTimer', 10]);
var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
g.async=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s);
})();
</script>
END;
}
function buildCommonMeta(string $title, string $thumbnail) {
return <<<END
<meta charset='utf-8'>
<meta http-equiv='X-UA-Compatible' content='IE=edge'>
<title>$title</title>
<meta name="referrer" content="no-referrer-when-downgrade"/>
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="author" content="Lycolia Rizzim">
<meta name="thumbnail" content="$thumbnail">
<link rel="icon" href="https://lycolia.info/assets/brands/lycolia-32x32.png" sizes="32x32">
<link rel="icon" href="https://lycolia.info/assets/brands/lycolia-192x192.png" sizes="192x192">
<link rel="apple-touch-icon" href="https://lycolia.info/assets/brands/lycolia-180x180.png">
END;
}
function buildOG(
?string $thumbnail,
?string $site_name,
?string $title,
?string $description,
?string $type
) {
$tags = " <meta property=\"og:type\" content=\"$type\">\n";
$tags .= " <meta property=\"og:site_name\" content=\"$site_name\">\n";
if ($thumbnail !== null) {
$tags .= " <meta property=\"og:image\" content=\"$thumbnail\">\n";
}
if ($title !== null) {
$tags .= " <meta property=\"og:title\" content=\"$title\">\n";
}
if ($description !== null) {
$tags .= " <meta property=\"og:description\" content=\"$description\">\n";
}
return $tags;
}
function renderCommonHead(
?string $thumbnail = 'https://lycolia.info/assets/brands/lycolia-OGP.png',
?string $site_name = 'Lycolia.info',
?string $title = null,
?string $description = null,
?string $type = 'website'
) {
$head = buildCommonMeta($title, $thumbnail);
$head .= buildOG(
thumbnail: $thumbnail,
site_name: $site_name,
title: $title,
description: $description,
type: $type
);
$head .= buildMatomo();
echo $head;
}
また他にも、ドメイン直下にあるページの構造を見直した。
具体的にはulとliでリストにしていた部分をdl dt ddに直し、各ツールの内容を少し解りやすくした。ただ余りにも見た目が殺風景すぎるので、liに戻してカードUIをはめ込むようにするかもしれない。
| 変更前 | 変更後 |
|---|---|
 |
 |
自分の投稿にあるタグの使用回数を知りたかったのでMastodonの本番DBを見る方法を調べた記録。
Mastodon v4.5.4
postgresになってmastodon_productionを開くと見れる。
sudo su - postgres
psql mastodon_production
テーブル一覧は恐らくhttps://mstdn.example.com/pghero/で見れるものがそれだと思う。
有志が公開しているMastodonのER図を参考にさせてもらった。
自分が投稿しているタグの総数が知りたかったので、こんな感じにしてみた。たぶん自インスタンスのdomainはnullと思われる。適当なので知らんけど。
SELECT
tags.name
,COUNT(*) as post_count
FROM statuses
INNER JOIN statuses_tags
ON statuses.id = statuses_tags.status_id
INNER JOIN tags
ON statuses_tags.tag_id = tags.id
WHERE
statuses.account_id = (SELECT id FROM accounts WHERE username = 'Lycolia' AND domain IS NULL)
GROUP BY
tags.name
ORDER BY
post_count DESC;
ゾンビランドサガと三宮に対する言及がめちゃくちゃ多いことがよく分かった。
| タグ名 | 使用回数 |
|---|---|
| ゾンビランドサガ | 225 |
| 三宮 | 205 |
| 神戸 | 123 |
| 兵庫 | 101 |
| 自炊 | 93 |
| 兵庫食材 | 72 |
| 交通 | 64 |
| サイト運営 | 32 |
| 神戸食材 | 25 |
| 鉄道 | 22 |
| 映画 | 15 |
| 映画館 | 14 |
| 買い物 | 9 |
| 姫路 | 7 |
| 災害 | 5 |
| 夜景 | 4 |
| 経県値 | 4 |
| lastfm | 3 |
| markov | 3 |
| web | 3 |
| 御影 | 2 |
| 明石 | 2 |
| 尼崎 | 2 |
| カメラ | 2 |
| ai | 2 |
| ui | 2 |
| せちまなと打って性格がわかるらしい | 1 |
| しなちくシステム無料ガチャ | 1 |
| 加古川 | 1 |
| 回線 | 1 |
| 眼鏡っ娘を見るとストレスが減るらしい | 1 |
| 気動車 | 1 |
| このタグをみた人は好きな天ぷらを答える | 1 |
| 阪神 | 1 |
| 山歩しよう | 1 |
| 児島 | 1 |
| shindanmaker | 1 |
| page42 | 1 |
| notestocklogincode | 1 |
| notestock | 1 |
| 土産 | 1 |
| 飯屋 | 1 |
| last | 1 |
| fediverseプロフ帳 | 1 |
| 無事下山 | 1 |
| ガルクラ | 1 |
| ガジェット | 1 |
| ガルクラタイプ診断 | 1 |
| ガルクラ総集編 | 1 |
| ソンビランドサガ | 1 |
| インターネット | 1 |
| ネットワーク | 1 |
| プロフィール帳 | 1 |
| プロフ帳 | 1 |
| ライフハック | 1 |
この記事はadiary改造シリーズ三本目である。
今回はadiaryの私的改造版であるadiary-extendsを0.11.5から0.12.0にバージョンアップした。
何をしたかというと、adiaryを採用したいが…で導入検討以来ずっと懸念事項だったMarkdownの脚注書式に対応した。なんと二年越し。なおまともな動作確認はしていないので、ちゃんと動くかは不明だ。とはいえ、軽く見た感じとりあえず動いてそうなので、いったん対応したということにしておく。
現状では脚注に書いたMarkdownはパースされないのでそのまま出てくるが、今のところ仕様。そのうち直す。多分。
2026-02-13
Version 0.16.0で脚注記法のMarkdownをHTML展開する対応を行った。
この対応はOpus 4.6に書かせた。
ミンゲイインターネットの紹介を書くにあたり、古のサイト探究～駄文同盟のID上位100サイトを巡り、今までのネット人生や自サイトの過去を振り返ってみるをリンクしたかったのだが、この記事には破綻した脚注記法が使われており、まさか他のサイトの紹介記事を書くのにこんな状態があってはならないだろうと思い着手した。
Claude Opus 4.5に9割書いてもらった。
というのもadiaryのコードはPerlで実装されてあり、私はPerlに疎い部分もあるし、パーサー系のコードの理解が難しいためだ。
過去にGPT4やClaude Sonnet 3.5などにトライさせたことはあるのだが、余りにも出てくるコードが使い物にならず、当時は諦めていた。しかしOpus 4.5は極めて性能がいいので、ひょっとしたら今なら行けるのでは！？と思い試してみたところ、大まかには上手くいったので、実装することが出来た。
勿論コピペ実装できる代物ではなかったので、細かいところは手直ししている。
キャプチャでアレだが、こんな感じで出してもらった。最初投げつけてるのはlib/Satsuki/TextParser/Markdown.pmそのものを渡している。
行が破綻していたり、前後の行にあるコードが正しくなく、リンク処理に[]が食われた後に脚注の[]をしようとして失敗したり、正規表現が微妙に間違っていたり、余計なフラグがあったりしたので、そういうのは適当に直している。
GitHubのWikiに改造内容をまとめているが、割とそこそこ改造したと思う。
素のadiaryより格段に使いやすくなった。とはいえ、まだ足りないところは多いし、adiaryを保守するのも大変なので、そのうちフルスクラッチで作り直したいところだ。こうやってadiaryに手入れしている現状、その日がいつ来るのかは謎だが…。
ついでにロゴもSVGとPNGで作ってみた。adiaryのオリジナルロゴの改変だが、SVGの書式をMDNで引いて細かいことはOpus 4.5に聞きつつ、手書きしたものだ。
GitHubのリンクは消えるかもしれないので、現時点の版も置いておく。
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 64 64" width="64" height="64">
<rect x="0" y="0" width="64" height="64" rx="12" ry="12" fill="#899aff"></rect>
<text x="18" y="52" transform="rotate(-10, 25, 62)" font-family="Meiryo, serif" font-size="64" font-weight="bold" fill="#fff">
a
</text>
<text x="25" y="55" transform="rotate(-30, 50, 50)" font-family="Meiryo, serif" font-size="32" font-weight="bold" fill="#001382">
ex
</text>
</svg>
SVGをPNGに落とすのにはSVG to PNG / ものおきを利用させていただいた。縁のアンチエイリアスや透過情報がきちんと保たれていて、非常に便利だった。
過去のadiary改造シリーズの記事。
Google Analyticsを廃止してMatomoを導入してから集めていたIPv6のアクセス比率を集計した結果をメモしておく。
集計期間は2025/08/17～2025/10/21。
| サイト | IPv6ビジット | IPv4ビジット |
|---|---|---|
| lycolia.info | 56 (55.0%) | 77 (45.0%) |
| ブログ (blog.lycolia.info) | 2,018 (43.4%) | 2,644 (56.7%) |
| ECO-Wiki (eco.lycolia.info/wiki) | 7,946 (40.5%) | 11,291 (59.4%) |
| ツールサイト (tool.lycolia.info) | 13 (65.0%) | 7 (35.0%) |
| 合計 | 10,033 (41.7%) | 14,019 (58.2%) |
以上の結果からIPv6は約四割、v4は約六割ということが分かった。また最もアクセスがあるのはECO-Wikiで、ツールサイトにはほぼアクセスがないことも明確になった。まぁツールは私が使えればいいので仕方ないね。
lycolia.infoは突出してIPv6のアクセスが多いが、実数が少なすぎるので余りアテにならない。ただ恐らく、リンク元の特性的に、ITオタク周りのアクセスが多いことが想定されるため、この結果はある程度妥当かもしれない。ツールサイトもそういう人が興味を持って踏んでるのだとしたら納得だ。ブログも技術記事がある関係で比率が高い可能性がある。
逆にECO-Wikiは比較的一般向けのサイトなので比率が少なくなっていると思った。
まだまだIPv4の環境は多く、IPv6シングルスタックへの移行はやや戸惑うレベルだ。GitHubのWebhookもIPv4だったりするので、しばらくはデュアルスタックで運用していくのが無難だろう。
現状さくらのレンタルサーバー上にある資源を自宅サーバーにフル移行する場合、DNS側の制約でマルチドメインのDDNSが面倒な問題があるため、専用のスクリプトを作る必要が出てきそうだ。
これは契約しているDNSサーバーのDDNSが1回に1レコードしか更新できず、レートリミットが60秒に1回という面倒な仕様なため、ドメインが複数あると厄介なのだ。現状Mastodonだけが自宅サーバーにある状態なのでどうにかなっているが、どうにかして対処しないといけない。
契約しているDNSサーバーにはDDNS API以外にも、DNSレコードを全部書き換えられるAPIがあり、こちらは1回に複数レコードを触れるため、比較的レートリミットを気にする必要がなくなる。なので、これを使って自力で書き換えるスクリプトを組めばDDNS APIのレートリミットは無視できるようになる。まぁ、こっちのAPIはレートリミットが緩いので何度でも叩けるのだが、バルク編集できるAPIを何度も叩く意味もないので…。
これとは関係なく、将来的には自宅サーバー側に権威DNSを立てて、レジストラのDNSサーバー側にはNSレコードだけというのもやってみたさがある。この場合、ドメインの追加や削除で一々レジストラの管理画面にアクセスする頻度が減らせ、管理が楽になるメリットがありそうだし、レジストラのDNSでは実現できないことが出来るようになる可能性もあるだろうから面白いかもしれない。
Google Analyticsを廃止してMatomoを導入してみたから一ヶ月が過ぎ去っていたので簡単に集計をまとめてみる。
8月17日～9月16日の30日間で自分のIPを除くMatomoの集計結果を出している。今回記事にする対象サイトはこのブログのみ。
| 指標 | 数値 |
|---|---|
| ページビュー | 2,337 |
| ユニークページビュー | 2,074 |
| ビジット | 1,983 |
| 平均滞在時間 | 1分17秒 |
| バウンス率 | 80% |
ビジットが何なのかについては正直よくわかっていない。PVでもUVでもない概念なのは確かだが、Matomo内の数値は大抵これがベースである。30分以内にもう一度ページを訪れたユーザーと解釈しようにも直帰率80%である以上、直帰して別経路でアクセスされないとカウントされない気がするので謎。ほとんどのユーザーがタブを開きなおしているとか、そんなことはないと思う。
バウンスは直帰率のことらしい。
これはIPv6に対応しているアクセスの数で、IPv6に対応しているがIPv4でアクセスしてきているユーザーは「IPv6対応ユーザー」にカウントしている。
集計方法としてはAAAAレコードを持つドメインに対しJSでfetchし、200OKが出たら対応、それ以外は非対応としている。この関係で、JS非対応ユーザーは集計から外れてしまい「IPv6対応状況不明ユーザー」になっている。
| 指標 | ビジット |
|---|---|
| IPv6対応ユーザー | 886 (37.9%) |
| IPv6非対応ユーザー | 1,079 (46.2%) |
| IPv6対応状況不明ユーザー | 372 (15.9%) |
IPv6対応状況不明ユーザーをBOTと仮定した場合、IPv6対応は45.1%で非対応は54.9%となる。およそ半数弱がIPv6に対応した環境でアクセスしていることがわかる。
なぜかここはビジットではなく、PVとUVの表現だった。PVのみ記載する。
| 指標 | PV | 直帰率 | 記事作成日 |
|---|---|---|---|
| 業務用と個人用でGitHubの無料アカウントを分ける | 127 (5.4%) | 79% | 2022/07/03 |
| Windows 11で接続中のNASからログアウトし、別ユーザーで入りなおす | 122 (5.2) | 77% | 2024/02/01 |
| Oculus Touchのスティックでオダメの移動操作をする設定 | 116 (5.0%) | 79% | 2019/02/23 |
| e/Taxを使って廃業申請をした時のログ | 112 (4.8%) | 63% | 2024/04/30 |
| 久々にCOM3D2を起動して発生したトラブルの解消メモ | 107 (4.6%) | 69% | 2023/05/21 |
| トップページ | 75 (3.2%) | 53% | - |
| アイスの当たり棒が当たったので、実際に交換してみた | 74 (3.2%) | 96% | 2024/06/27 |
| Windows 11のChromeで正確な位置情報を取得できるようにする | 70 (3.0%) | 49% | 2023/02/09 |
| Visual Studio 2022 Communityで手軽にC#.NETのコードカバレッジを見る方法 | 67 (2.9%) | 58% | 2023/03/23 |
| Windows 11が0xc000000eで起動しなくなったのを直した | 66 (2.8%) | 76% | 2023/08/13 |
| 指標 | ビジット |
|---|---|
| Windows 11 | 924 (46.6%) |
| Windows 10 | 293 (14.8%) |
| iOS 18.6 | 203 (10.2%) |
| Mac 15.6 | 79 (4.0%) |
| Android 15.0 | 74 (3.7%) |
| Mac 10.15 | 58 (2.9%) |
| iOS 18.5 | 54 (2.7%) |
| Android 16.0 | 37 (1.9%) |
| Android 13.0 | 24 (1.2%) |
| Android 14.0 | 23 (1.2%) |
概ねWindowsユーザーからのアクセスが多いが、iOS, Mac系のアクセスも無視できない程度にあるようだ。
バージョンやディストリの差異を束ねたもの。
| 指標 | ビジット |
|---|---|
| Windows | 1,217 (61.4%) |
| iOS | 299 (15.1%) |
| Mac | 216 (10.9%) |
| Android | 212 (10.7%) |
| Linux | 37 (1.9%) |
| Chrome OS | 2 (0.1%) |
Androidユーザーが少ない…。地味にLinuxやChrome OSもあった。
バージョンは束ねている。
| 指標 | ビジット |
|---|---|
| Chrome | 835 (42.1%) |
| Microsoft Edge | 483 (24.4%) |
| Mobile Safari | 209 (10.5%) |
| Chrome Mobile | 163 (8.2%) |
| Firefox | 96 (4.8%) |
| Brave | 44 (2.2%) |
| Safari | 41 (2.1%) |
| Chrome Mobile iOS | 33 (1.7%) |
| Yahoo! Japan | 23 (1.2%) |
| Google Search App | 22 (1.1%) |
意外とEdgeのアクセスが多く、個人的にはうれしい。変わり種ではIronやSleipnir, Operaも見られた。
| 指標 | ビジット |
|---|---|
| 1285 (75.9%) | |
| Bing | 257 (15.2%) |
| Yahoo! Japan | 125 (7.4%) |
| DuckDuckGo | 17 (1.0%) |
| 楽天 | 5 (0.3%) |
| ニフティ | 2 (0.1%) |
| Brave | 1 (0.1%) |
| Perplexity | 1 (0.1%) |
地味にBingからの流入が多い。ちなみにこのブログはBingのほうがヒットしやすい。
| バックリンク元 | 備考 |
|---|---|
| adiary official website | adiary利用者のページだと思われる |
| block.opendns.com | AdBlocker的な奴の登録場所っぽい？ |
| X | 旧Twitter |
| tgadfs01.toshiba.co.jp | 東芝の社内SNSか何か？ |
| dメニュー | たぶんdメニューにある検索からの流入 |
| Inoreader – Build your own newsfeed | RSSリーダーを使ってこのサイトを読んでいる人がまさか…！？ |
| 133.167.8.98 | どこかのさくらのレンタルサーバーのIPっぽい。RSSリーダーかな？ |
| Adventar | アドベントカレンダーに登録しているので多分その関係 |
| あずきインターネット | Azukiという方のMisskeyインスタンス |
| hatenablog-parts.com | はてなブログのブログカードらしい |
| 教えて!goo | 質問サイト。今月でサービス終了らしい |
| Perplexity | AI検索エンジン |
| statics.teams.cdn.office.net | どこかの企業ドキュメントからの参照と思われる |
| ただ、安らかに... | adiaryユーザーさん。adiary利用者のページに載せてないタイプの人 |
| @noemi.sakura.ne.jp | adiaryユーザーさん。Matomoからは確認できなかったが、被リンクを受けていたので掲載（adiary利用者のページを眺めていて気が付いた） |
基本的に人口比そのままだと思われる。
昔からそうだが、基本的に平日に伸び、週末や祝日に下がる傾向がある。開発係記事の割合が高いので、恐らく業務中に見られることが多いのだろう。
業務時間中にアクセスが伸び、通退勤や昼休みには減っているように見える。
Google Analyticsを使っていたころはUIと動作の重さで、ここまで細かく見る気さえ起きなかったが、MatomoはUIが良く動きも機敏なため、こういったことがしやすいのがいい。事実ほぼ毎日見ているくらいだ。GAのころは年に一回見るかどうか位だった。
何より自分のアクセスが普通に弾けるので、ノイズが減るのもいい。GAでもはじく方法はあるにはあるが、全てのデバイスで無設定に弾くというのは不可能に近いし、設定しても何故か弾けなかったりして困ることが多かった。オプトアウトする拡張機能はほかのサイトにとって迷惑そうなので入れたくなかったし、そもそもスマホでは入れる手段もない。
今回の集計では前回のサーバーログベースの集計を大きく覆す結果が出たのもあり、かなり満足している。
集計手法がすべて異なるので単純比較できないが、時期によって順位に変動があることがわかる。