Forza Motorsport 新作が出てたことを思い出した（今更）ので、 Xbox Game Pass で遊ぶことにしました。前作からすでにそうですが、このゲームは容量が 100GB 以上あります。
私の PC には 1TB の SATA 接続 SSD と、 2TB の HDD が接続されていました。すでに SSD のほうは残り容量がカツカツなので HDD のほうに入れることに。予想はしていたのですが、 HDD は時代遅れなほど遅いので、コースのロードに1分くらい待つことになるのでストレスフルでした。
そこでついに重い腰を上げて、新しい SSD を購入しました。買ったのは CFD のミドルくらいの 4TB モデル (CSSD-M2L4KSFT6KE)。 Amazon で3万を切ってたので買いだと思って購入しました。
で、ここからが本題。 Windows をクリーンインストールする元気はないので、どうにかして前の SSD から新しい SSD にデータを移行したいです。数年前にも同じことやってるのですが、やり方をメモしてなかったので、備忘録としてメモしておきます。
データベースの運用は難しい。私の運用している Pleroma (Mastodon 互換といえば世間的に通じそう) サーバー (ご隠居) は、今まで EC2 + RDS の構成でしたが、さすがに高かった ($50 が円安で厳しくなっていく)。そこで 10 月に KAGOYA CLOUD VPS に移行を行いました。で、登録したら「嘘の住所で登録してない？」とサポートに疑われて、メールチェックしてない間にアカウントが停止されていたのは別の話……。
VPS に移行すると、データベースの管理も当然自分でやることになります。今まで RDS が自動でやっていたことを自分で組み直すのは大変だったので、今年最後の技術ブログをやっておきます。
みなさんは東京の土地勘ありますか？ 私は東京で生まれ育ちましたが、未だに赤坂がどこにあるのかいまいちピンと来ません。ただ都心であることは間違いないでしょう。
東京の中心は、言わずもがな、かつての江戸城、現在の皇居です。道路や鉄道は皇居を中心とした同心円状に整備されています。例えば、道路では、環状1～8号線、首都高都心・中央線環状線があります。東京メトロの主要な路線は、東京23区の端から、皇居を半周して、山手線の駅に繋がるような構成になっています。
逆に言えば、皇居は不可侵の場所です。皇居の上を越えていくことはできません。したがって、東京を攻略するには皇居をどっちまわりで抜けていくかを知ることが重要であり、そのためには目的地が皇居からみてどの方角にあるかを知る必要があります。
そこで私はかねてからアイデアがありました。東京はもう住所を廃止して極座標（皇居から見た方角と、皇居からの距離）で表すべきだと。
そしてついに、これを簡単に実現する Web サービスをつくりました！！！
東京極座標 https://tokyopc.azyobuzi.net/
このサービスのおかげで、赤坂が皇居の南西2kmにあることがわかりました！ このことから、赤坂のお高いイメージは皇居に近いことが影響しており、また普段なぜ縁がない場所かといえば、私は総武線（皇居をの北側を通って東西へ抜ける）沿線の民なので南西方向に行かないからということがわかります。このように東京極座標は、東京攻略を有利にすることができるのです。
あけましておめでとうございます。季節感もなにもないブログですが、修論締切間近の時期に研究で使った技術をまとめようという点は季節感かもしれません。
今回のネタは、クラスタサイズに制約を設けてクラスタリングをしようという話です。
クラスタリングといったら、もっとも代表的な手法は k-means です。 k-means はクラスタ数を事前に指定して、クラスタリングを行います。つまり、 k-means を使うときは、データを k 個に分けたら何か傾向が見えるかもな～という気持ちで使うことになります。このとき、1クラスタに属するデータ数（クラスタサイズ）は、クラスタごとに異なります。
では、クラスタサイズを事前に指定するような方法はないのでしょうか。データが大量にあるので、データを c 個に均等に分割して処理したいな～というときに、どうしたらいいのでしょうか。というわけで今日の論文紹介です。
上が日本語版、下が英語版で、書いてあることは同じです。この論文では、クラスタサイズの基準 K と、クラスタサイズの下限 、上限 を指定すると、クラスタサイズがこの範囲内に収まるようにいい感じにクラスタリングする方法が示されています。英語版では、このアルゴリズムを COCBO と呼んでいるので、この記事でも COCBO と呼んでいこうと思います。
blog.azyobuzi.net を開設して1年強、メンテナンスも AsciiDoc も面倒になってきて、はてなブログに戻るのもアリだなぁという気持ちが若干発生してきていました。そもそもブログ自体書いてないじゃん。はい。すいません。
AsciiDoc というか Asciidoctor を使うことに思うところがあり、 Gatsby + Asciidoctor.js という構成をやめ、 Markdown + お手製静的サイトジェネレータ という構成に変更したというお話です。
（AsciiDoc から Markdown への移行は9月の頭には完了していましたが、記事を書く余裕がなかったので、今書いています。）
TL;DR: Xamarin.Android のグローバル例外ハンドラは AppDomain.UnhandledException。これで Java の例外も拾えます。ただし、例外が発生したスレッドによってはうまく拾えないケースがあり、現在修正中です（xamarin-android#6211）。
また TPL Dataflow の話です。突然ですが、バッファのない PropagatorBlock って欲しくないですか？
例えば、複数の SourceBlock があって、それをひとつの SourceBlock として返したいとき。
ISourceBlock<T> CreateSource()
{
IEnumerable<ISourceBlock<T>> sources = /* ... */;
var resultBlock = new BufferBlock<T>(new DataflowBlockOptions() { BoundedCapacity = 1 });
foreach (var s in sources) s.LinkTo(resultBlock);
return resultBlock;
}
どうでしょう？ resultBlock は、1件はバッファに持ってしまうので、後段のブロックがどうであれ、ソースからは必ず1件多く取り出されてしまいます。
1件くらいいいじゃない？ それは sources 次第でしょう。
というわけで、本題のバッファのない PropagatorBlock が欲しい、ということです。もし resultBlock にバッファがなければ、 CreateSource の戻り値を利用する（リンクする）とき、初めて sources からデータが取り出されます。やりたいですね。
FLIF (Free Lossless Image Format) は、実用されている可逆圧縮形式としておそらく現在最強の圧縮手法です。実際、画像圧縮手法に関する最近の研究では、 FLIF が比較対象となることが多いように思われます。このブログ記事では、 FLIF がどのように圧縮を行っているのか、理解できた範囲で記録していきます。
ファイル形式としての特徴は、アルファチャンネル対応、 HDR (サブピクセルが8ビットより大きい) 対応、アニメーション対応と、現代的な画像形式として一般的な構成となっています。
圧縮手法としての特徴は、次の2点が挙げられます。
FLIF は、すでに ImageMagick で実装されており、すぐに試すことができます。また、コーデックのリファレンス実装は GitHub にあります (FLIF-hub/FLIF)。
なお、現在 FLIF の開発はストップしており、 FLIF の成果は JPEG XL に取り込まれるようです。ただ JPEG XL の説明を読む限り、以上に挙げた特徴とは違っているので、手法としては別物になるのではないかと思っています。
開発環境を Docker でいい感じにしてくれるやつとして、 Visual Studio では「コンテナー開発ツール」が、 Visual Studio Code には Remote 拡張があります。これらは Dockerfile や docker-compose.yml を用意すると、その中でアプリを動かすことができるやつです。しかし、同じものではないので、挙動はまったく異なります。それぞれメリット、デメリットがあるので、両方使えるとうれしいわけです。そこで、うまいこと両方で使える docker-compose.yml を書いてみようという試みをやっていきます。
複数のプロジェクトをひとつのリポジトリで管理するとき、プロジェクト間の参照関係は csproj に <ProjectReference> を書くわけですが、ここで、このプロジェクトを NuGet パッケージ化するときのことを考えます。例えば、 A と B というプロジェクトがあり、 B が A に依存しているとします。このとき B を dotnet pack してできあがるパッケージの A への依存はどのようになるでしょうか？ 実際にやってみると、現在の A のバージョン以上という依存関係になります。
ここで、 A の現在のバージョンを 1.0.0 とします。 Semantic Versioning に従っていると考えると、もし 2.0.0 がリリースされたら、破壊的な変更が入っているかもしれません。それでも B から A への依存は 1.0.0 以上で良いのでしょうか？ と考えると、「以上」以外の柔軟な依存関係を指定したくなりませんか？ というわけで、 <ProjectReference> を使ったプロジェクト間参照で、柔軟なバージョン範囲指定をしたいというのが今回のお話です。
以前、「いまさら使う TPL Dataflow」で紹介した TPL Dataflow は、入力されたデータを並列に処理するプログラムを、ブロックの組み合わせで簡単に記述できるライブラリです。 「類似品との比較」で述べたように、 TPL Dataflow は、プッシュ型とプル型の両方の性質を持っており、送信者（Producer）が、受信者（Consumer）が処理しきれないほど大量のデータをプッシュしようとするとき、受信者がそのデータの受信を遅延させることで、データフロー内を流れるデータ量を制御します。
一方で、このような、大量のデータや時系列データ（イベント列）を入力し、データフロー内を流れるデータ量を制御しながら、並列にデータを加工する仕組みは、一般的に、特に Java のコミュニティでは Reactive Streams と呼ばれています。 Reactive Streams に用いられるインターフェイスは Java 9 で java.util.concurrent.Flow として標準ライブラリ入りしており、 RxJava や Akka Streams がこのインターフェイスの実装を提供しています（実際には、互換性のため reactive-streams パッケージを通じて実装しています）。
C# においても Reactive Streams は他人事ではなく、 java.util.concurrent.Flow と同様のインターフェイスが Reactive.Streams パッケージとして NuGet で配布されており、標準的なインターフェイスの座を狙っています。また Akka.NET Streams がこのインターフェイスの実装を提供しています。
いずれの方法も、 Reactive Extensions (Rx) 的なプッシュ型に対して、流量制限（back pressure）を導入することで、データ量を制御しています。この記事では、 Reactive Streams と TPL Dataflow をプロトコル（インターフェイスとその実装方法）から比較します。
Qiita 騒動で脱 Qiita といって静的サイトジェネレータに向き合うみなさん、こんにちは。私はほとんど Qiita に書いていない、根っからのはてなブログユーザーだったのですが、以前からいくつかの理由で脱はてなブログしたいなぁ～と考えており、本日ついに、自前のブログ基盤ができたので、移行していきたいと思います！
一発目の記事ということで、ブログの要件と、それに合わせてどうツールを選んだのかについて、書き残しておきたいともいます。
AsciiDoc をやめ Markdown に移行しました。