ごらくらいふ

プログラミングしたりゲームしたり

AHC031に参加した

MC Digital プログラミングコンテスト2024(AtCoder Heuristic Contest 031)に参加したので、問題を解いた過程を記録してみた。

問題

atcoder.jp

  • W x W のグリッドで表現されるイベントホールがある
  • D 日分の予約群があり、日毎に N 件の予約がある
  • 各予約には使いたい面積がある
    • スペースの確保は長方形で行われなければならない
    • 予約スペースは被ってはいけない
    • 要求面積より余分に大きいスペースを貸し出してもよい
  • 各予約スペースを区切るためにパーティションを設置する
    • この辺の長さ 1 に応じて 設置コスト、撤去コストが 1 かかる
    • 日付をまたいだとき、パーティションに変更がない箇所はコストがかからない
    • 要求面積に満たない区画しか貸し出せなかったとき、不足面積 x 100 のコストがかかる
  • たとえ少ない面積でも、すべての予約に場所を用意しなければ WA
  • なお、初日のパーティション設置コストは特別に 0 とする
  • コストができるだけ小さくなるようにする
  • 制約
    • W == 1000
    • 5 <= D <= 50
    • 5 <= N <= 50

サンプルをベタ移植

  • ちょっと問題を掴み取れていなかったので、サンプルをベタ移植した
  • 幅を 1 に、高さを W のほっそい区画を全件用意するもの
  • Score: 107_822_101_150

https://atcoder.jp/contests/ahc031/submissions/51728038

すべての予約を縦割りで割り当てる

  • サンプルを基盤に、高さ W のまま、幅を調整して割り当てることにした
  • 大雑把な実装なので、最低限である幅 1 は各予約に用意する
  • 余分にスペースを確保すれば、チリツモで空間が足りなくなるので、大きい面積を要求する予約から割り当てた
  • Score: 264_827_950

https://atcoder.jp/contests/ahc031/submissions/51734984

in/0004.txt

しばらくコスト算出の実装に精を出す

  • 今回、インタラクティブ問題ではないこともありコスト算出ツールがないので自前実装した
  • 使う場面が来ればいいなという思惑
  • 不足コストは比較すればよいので簡単
  • パーティション設置のコスト算出は、ABCで解くような問題に感じて楽しかった
    • 水平方向と垂直方向に線分をわけて考える
    • 線分の始点と終点で加減算して一つの線分へ合成したり(パーティションを求める)
    • 当日と前日それぞれのパーティションの始点と終点で加減算して撤去・敷設を求めたり
type PartitonEvent = (usize, usize, isize);
type AlignedPartitions = HashMap<usize, Vec<(usize, usize)>>;
fn partition_by_event(event: &Vec<PartitonEvent>) -> AlignedPartitions {
    let mut partition: AlignedPartitions = HashMap::new();

    let mut state = 0;
    let mut begin = 0;
    for (level, point, volume) in event.iter() {
        // FIXME: hardcode
        if *level == 0 || *level == 1000 {
            // 外周部は壁なのでパーティションはいらない
            continue;
        }

        if state == 0 && *volume == 1 {
            // 0から1に変わるとき線分が始まる
            begin = *point;
        } else if state == 1 && *volume == -1 {
            // 1から0に変わるとき線分が終わる
            let line = (begin, *point);
            if partition.get(&level).is_none() {
                partition.insert(*level, Vec::new());
            }
            if let Some(v) = partition.get_mut(&level) {
                v.push(line);
            }
        }

        state += *volume;
    }

    partition
}

コストについて考えた

  • コスト算出が実装できたので、手元で試行錯誤できるようになった
  • いじっては数字を観察し、コストについて考えた
    • 予約ひとつの必要とする外周の長さは、正方形に近いほうが小さい
    • 予約スペースがパーティションを共有すれば、その分コストが安くなる
    • 正方形を敷き詰めると、パーティションの置き換えが発生してコスト高になりそう
    • 最初に設置したパーティションはコストの算定外になる
  • 正方形のイベントスペースを長方形に区切って固定してしまえば、パーティションの置き換えを短辺の分だけで済ませられるのではないか

イベントスペースを長方形のセクションに分割する

  • 正方形のイベントスペースを長方形の集まりとみなすことにした
  • W は 1000 固定なので、割り切れる数はハードコードできる
  • 最も大きい面積を要求する予約を基準に、正方形の分割数を決めた
  • 未使用スペースの多いセクションから順に割り当ててみた
  • また、前日と当日で必要とするスペースが大きい方に、予約スペースをあわせてみた
  • Score: 61_243_541

https://atcoder.jp/contests/ahc031/submissions/51763370

in/0004.txt

セクションの分け方を実験した

  • 全日程を通して大きい予約を基準にセクション数を決定している
  • 日ごとに最も大きい予約を基準に分けるとどうなるか
    • -> 大半のスコアが悪化した
      • 分割数が 2 と 4 を往復したりして、都度 2000 の撤去コストが発生したりした
  • 引き続き、全日程の予約を通して最も大きいものを基準とすることにした

複数ナップサック問題

  • 全日程を通してセクション数を統一するということは、各予約面積に割り当てる高さが固定になるということだった
  • つまり、容量1000の容器がいくつかあって、各予約が必要とする面積(=実質は幅)を割り当てればよさそうだ
  • それは複数のナップサック問題ということか
    • それって難しいやつでは…?
  • あぶれた予約は、一番大きい予約から場所を分けてもらうことにした(雑実装)
  • とりあえずテストケースは通った
  • 多くのセクションで端まで使うことが増えたため、その分のパーティションが減らせるようになった
  • Score: 58_509_946

https://atcoder.jp/contests/ahc031/submissions/51763370

in/0004.txt

余裕のあるところに詰めてもらう(雑実装の解消)

  • どうしても余分にスペースを確保しているので、収まりきらない予約のために詰めてもらったりした
  • あぶれた予約の対処が雑だったので、丁寧に詰めてもらうようにした
    • 余分にスペースを調達している区画から削っていった
  • 塵も積もれば山となるらしく、かなりコストを削減できた
  • Score: 18_631_300

https://atcoder.jp/contests/ahc031/submissions/51766245

in/0039.txt BEFORE

in/0039.txt AFTER

システムテスト

  • 燦然と輝く TLE x3
  • 退場処分になりました
    • 200位付近だったのに
    • 2000ms 付近は危険領域だったか~
      • 信頼できるのは 10ms まで
  • 261位になりました
    • 該当部分のみ相対スコア0点になるが順位参加を許された

https://atcoder.jp/contests/ahc031/submissions/51939513

やりたかったこと

  • 前日の予約と当日の予約でどんどん大きい方を採用していったが、余分に確保しているスペースが多い予約だけを削れればパーティション構成の変更は少なかったのではないか
  • ナップザック問題を解いて最後に集まったセクションは、細切れの予約が多く余白も多々あることから、コストの少ない配置方法をさがせるのではないか

AHC 青パフォとなって水色になれました。今後も頑張ります。

https://atcoder.jp/users/yajamon/history/share/ahc031

ObsidianのリンクはWikiリンクを使うように戻ってきちゃった

最近、仕事寄りな個人的メモのために保管庫を切って、そこでのリンクは Markdown形式 を使うようにした。が、一週間も経たないうちに Wikiリンク形式 に戻ってきてしまった。

なんでまた保管庫の分離を?

業務知識をひたすらノートに起こしていき、いずれ誰かに資料として引き渡せるのではないかと考えたから。

また、デイリーノートに求める運用がプライベートと異なることも影響している。 プライベートではその日作成したノートの集約が主な使い方だ。 一方、仕事用の場合はノートの集約だけでなく、その日の作業内容の列挙や完了したタスクを書き込んだりしていく。 日報として書き貯め、週報として振り返り、月報としてまとめたらかっこいいと思ったのだ。 これが 1on1 で「この半期なにをしましたっけ?」と面談で話がふわふわすることを避けてくれるだろうと期待している。

Markdown形式 を選んでみた理由

Wikiリンク方式では、Markdownファイルだけを渡してもリンクを辿れない。 「可能であれば最短経路」のルールで内部リンクを使用しているのでなおさらである。 これが Markdown形式であれば、リンクは絶対パス相対パスになるため、Markdownファイルを渡しても追跡可能になるだろうと考えた。

実際のところ、赤裸々に書いたりする場面もあるので、まるまる渡せるような代物ではなくなってしまった。

Obsidianでノートを取って10ヶ月が経過した - ごらくらいふ プライベート保管庫のススメ 参照。

MarkdownリンクとWikiリンクの違い

Markdownリンクは以下のような形式だ。Obsidianの内部リンクとして使う場合、ファイル名とリンクで同じ内容が書かれ冗長になる。

[表示用文言](リンク)

Wikiリンクは以下のような形式だ。表示用文言さえもない内部リンクとして使う場合、冗長な部分はなくなる。

[[リンク|設定されれば使われる表示用文言]]

実際につかってみた感想

Markdown形式では、リンク切れの表現が甘い

Wikiリンク形式では、存在しないファイルへのリンクはグレーアウト表現によってリンク切れがわかる。Markdown形式では区別できなかった。

これは ObsidianというソフトのUI表現上の都合なので、リンク切れ表現が改善されれば不満点でなくなる。

そもそも絶対パスで通じない

絶対パスとは、どこに記述されてもその所在を完全に説明するパスのことだ。

C://Program Files/someprogram/program.exe だとか、 /var/www/html/index.html だとかだ。

Markdownとは元々プレーンテキストからHTMLを生成するために開発された軽量マークアップ言語だ。となれば絶対パスとは 絶対URL に倣っていることが望ましい。

URL とは何か - ウェブ開発を学ぶ | MDN

暗黙に省略されるのは Vaultのルートパスまでで、絶対パスといえば / から始まるパス表現であるべきだ。 しかし Obsidian が絶対パスとして生成するリンクは先頭に / がない。 「絶対パスを使う」設定で /foo.md へのリンクを張った時、 [foo](foo.md) と記述されるのだ。

/foo.md
/inbox/content.md
/inbox/foo.md

上記のファイルがあったとき、 /inbox/content.md[foo](foo.md) と記載されていたらどれが参照されていると思うだろうか。

Obsidian における答えは /foo.md である。相対URL的に馴染み深い /inbox/foo.md を指定するには、リンク部を ./foo.md と表現する必要がある。 なお、この状態で /foo.md を削除すると、参照先が /inbox/foo.md になる。

つまり、 [foo](foo.md) というリンク表現は、柔軟に参照先を変える記述ということだ。 設定で絶対パスを使うよう指定してもこの記述になるため、気を抜くと絶対パスではないパスが埋め込まれることになる。

絶対パスとして挿入されるリンクがまるで相対パスのような表現で、その実態は柔軟すぎる参照なのである。

これはもうObsidianの設計の都合なので、変わることはないだろう。リンクはObsidianの根幹であり、その挙動を今更変えるのは悪影響が大きすぎる。 せいぜい 絶対パスとして生成するリンクが / から始まるようになればマシというところか。

全体ファイル検索から「検索結果をコピー」する際の不都合

デイリーノートの運用で、その日作成したノートの集約という使い方をするが、それに活用しているのが全体ファイル検索とその「検索結果のコピー」だ。

/foo.md
/inbox/foo.md

というファイルがあるとき、 file:foo として検索し、「検索結果をコピー」するとどうなるか。

- [foo](foo)
- [foo](foo)

と提案されるのである。結果が壊れている。

「パスを表示」のトグルスイッチを有効にした結果は、

- [foo](foo.md)
- [foo](inbox/foo.md)

となり、それぞれを識別可能になるが前述のとおりこれは絶対パスではない。

だからやめた

Markdown形式にしても冗長だし、その割にリンクは直感に反するのでそのままファイルを引き渡しても通用しないしで、「可能であれば最短経路」の「Wiki形式リンク」に戻ってきてしまったのだった。

ファイル生成にルールを定め、いざ引き渡す時にかける変換スクリプトを用意したほうがマシである。

最短経路Wikiリンクを支える特別な事情

「可能であれば最短経路」の「Wikiリンク」を使うことにしたが、これが混乱を起こさない運用上の特別な事情がある。

自分の場合、「ほぼすべてのファイル名に重複がない」のだ。

デイリーノートは /daily/{YYYY-MM-DD} に生成するし、通常のノートは「ユニークノートクリエイター」を使って、/inbox に生成するようにしている。その他、たとえばテンプレートファイルは t-プレフィックスをつけるようにしている。

だから、Wikiリンクはいつでもファイル名だけのシンプルな形になるし、いざ引き渡すとなればパスを補完するような変換スクリプトがあればよいのだ。

#にゃんにゃん冬優子 を見に秋葉原へ行ってきた

シャニソン リリース100日キャンペーンのひとつとして、秋葉原で展開されている広告掲載キャンペーン「#にゃんにゃん冬優子」を見に行った。

https://campaign-shinycolors-song-for-prism.idolmaster-official.jp/release-100days/

JR秋葉原駅構内の電気街口側では柱にポスターと電子ポスター。

全部で6柱に掲示されたポスターと電子ポスター。

中央改札口側には壁面掲載のポスター。思っていた以上に大きかった。

電気街口改札を出ると namco秋葉原 のディスプレイモニターにも冬優子。

シャイニーPRオファー vol.2 「アニメ主題歌 歌唱のオファー」の屋外広告も見れた。

中の人繋がりでヴァンガード Divinezもパシャリ。

このキャンペーンでは「あいことばラリー」という企画があり、周辺店舗の等身大パネルをめぐり合言葉を集めることでちょっとしたおまけが貰える。ほとんど電気街口周辺に固まっているので巡りやすい。

キャンペーン「あいことばラリー」台紙

ということでまずはアイドルマスターオフィシャルショップへ。 久々に来たので、衣装展示の写真も撮った。

次に 2文字目のnamco秋葉原。2Fをぐるっと巡ってたらあった。

3文字目。AKIHABARA ゲーマーズ

4文字目。あみあみ 秋葉原ラジオ会館

5文字目。アニメイト秋葉原。ちょっと小雨が降ってきた中、若干歩く。 5Fのエレベーター前に設置。日によって場所が若干異なるらしい。

これであいことばは全て巡った。帰りに リスアニ! アイドルマスターシャイニーカラーズ 音楽大全を買う。発売されたばかりだ。

余裕をもって行動できるのは平日しかチャンスはなく、急に思い立って、急に行ってきた。 この週末は大阪でシャニマスの6thライブがあるので、関東の配信勢ぐらいしか気軽に行ける人は居ないかもしれない。Googleマップで順路をたどって雰囲気を想像したりしてみてはどうか。

在宅仕事で運動不足だったので、いい気分転換になった。

AHC030 に参加した

AHC030 に参加してみて、ついでに参加記録を書いてみようと思い立った。

問題

atcoder.jp

  • N x N マスの島に埋蔵されている油田プールの形状を答えよ
  • 油田はポリオミノ型をしており、事前に形状と向きが判明している
  • 掘削は確定した埋蔵量が得られるが、コスト 1 かかる
  • 占いは指定したマスの集合の数に基づいたコスト 1/√k で合計埋蔵量を得られるが、マスの数が増えるほど情報の分散も大きくなる

単純に解く

  • サンプルコードいわく、全セルを一度掘ってもコスト超過になることはない
  • (0, 0) から1セルずつ掘る
  • Score: 12_696_000_000

https://atcoder.jp/contests/ahc030/submissions/50134670

油田だけを掘れば十分である

  • ルールによれば、ポリオミノ油田の形状は4セル以上かつ隣接している
  • BFSで油田だけを掘削すれば、無駄なコストを削減できる
  • (0, 0) から順番に掘っているので、まだコスト削減の余地がある
  • Score: 9_369_000_000

https://atcoder.jp/contests/ahc030/submissions/50198163

占うコスト感を考えた

  • まとめて占ったセル数の平方根だけコストが安くなる
  • 当たるも八卦当たらぬも八卦
    • エラー率がある (0.01 ~ 0.20)
  • 飛び飛びで選んだほうがいいのか?まとめたほうがいいのか?
    • 3x3 の四隅だけを選択して占っても、2回占えばコストが1になる
    • 3x3 全部を選択すれば、3回占ってコストが1になる
    • 不安定なのは変わらない
  • 「kが16で、埋蔵量が0のとき…エラー率は…」と事例別に計算してみて、16セルは埋蔵量0でさえ完全な精度は出ないが、十分に埋蔵量を感じられそうだった
    • 肌感として、2x2 や 3x3 は占う回数も多くなり、総コストが高すぎると思った

新しい油田を少し効率的に探す

失敗:占う軸を増やす

  • 16セルずつの占いを、水平方向の線形に選んだセルだけで行っていたため、鉛直にも追加してみた
  • 結果はスコアの悪化となり、目をそらしている問題点がこっちを見つめている
    • 続きから占う実装になっていない
    • 水平と鉛直を交互に占っているため、重複して占っているセルがある
  • ただ、占いの端数が綺麗になったので、占いが油田を見逃すことはなくなったらしい
    • 中途半端なセル数で占わないため
  • Score: 7_822_500_000
  • https://atcoder.jp/contests/ahc030/submissions/50202670

ABC340 に参加する

事前に占って素早く油田を探す

  • ABC340 で「そういえばヒープ使えば優先度順に取り出せるな」と気づく
  • 4x4 の区画であらかじめ占い、濃いところから油田を掘り返す
    • ようやくコスト計算に平方根を使う出題意図に沿ってきた
  • 区画を掘り返すときも渦を描くように、外周から&各辺を均等に掘るようにした
  • この時点で、"無駄な空白セルを掘らない"というコスト削減は限界になったと判断した
    • ワーストケースでもほぼ無駄がない
  • Score: 6_714_250_000
  • https://atcoder.jp/contests/ahc030/submissions/50205955

ToDo

  • 空白セルの見込みが油田より少ない見込みがある場合は?
    • 油田が重なっていないケース
    • 油田と違って空白地帯は飛び地セルがありうる
      • 回答失敗は十分ありうる
      • 濃厚に重なってるセルの隣に空白セルがあると最悪
    • 油田の重なりもある程度占える
      • 確定している空白セル数にどれだけ上乗せするか
    • 空白をすべて埋めるか、縁取りするか
  • 油田の縁取りをする?
    • 2x2 の中央を基点にすれば次に確認する区画がわかる
      • 飛び地を掴んでしまった場合は?
        • 最も端の地点を確認すれば、ドーナツの穴か輪郭か判断できる
    • 判明している油田情報とのすり合わせをしなければ答えは分からない
      • 端からマッチしていく
        • ないはずの場所に油田がある->他の油田があるかも
        • あるはずの場所に油田がない->それはマッチしない油田
      • ちぎれた油田プールを補完していく縁取りが必要になるだろう
        • 完全に埋まってる油田は? -> 回答時には無視できる
          • 行き場の分からない油田がある中、どうやって探査を終了する?
    • 油田プールの中に隙間があったりするとめんどい
    • 油田のBFSよりコストが安くなりやすい
      • 小物は面倒
        • 細い油田の場合、角の縁取りでコストがむしろ増える
  • 意外とエッジケースが来ない
    • 油田の幅と高さがNと一致して自明になっている油田
    • 油田の幅と高さがNの半分を超えて自明になっている油田のマス

しめきり。

  • 締め切り時点で、順位は 382位 でした。

終結

終結果は、439位でした。

読書カードをObsidian Propertiesで書いてみる

Obsidian v1.4.0 にて Properties という機能が追加された。 これは、YAMLフロントマターを拡張し、ユーザーが自由にキーと値を割り当てられるようにしたものである。

これを、読書カードに用いてみようと思う。

読書カード

読書カードの目的は「本を読んだことを記録する」ことである。どんな本を、いつ買って、いつ読んだのか。読書カードを作ればあとで振り返ることができ、読書の実績が明らかになる。 さらに、Obsidianで扱う上では、リンクを貼ることで知見の引用元を示すことにも使えるのだ。

読書カードに求められる内容はたいてい決まっている。ということは、構造化データにできる。 とりあえず私が用いているのは以下のようなものだ。

  • タイトル
  • 著者
  • ページ数
  • 出版社
  • 発行日
  • 初版
  • 読了日

書き方の変遷

読書カードの内容は構造化できることはわかった。しかしちょうどいい書き方がこれまで決められなかった。以下はその変遷である。

  1. 箇条書き
    • 一行で key:value を書く書式
    • 「:」の位置が揃わず見た目が汚い
  2. 和地空白で見た目を整えた箇条書き
    • とくに key:value で言うところの key 部分
      • 著 者:発行所: とか
    • 3文字に制約されたりする
    • 見た目のためにデータを壊してはならない
  3. テーブル表現で整える
    • 拡張機能が無いとつらい
    • Markdown Viewer で見えれば良いようなガタガタのテーブル記述は嫌だ
      • 書いているのは Markdown 文書である。生のテキスト文書としての見た目も考慮されなくてはならない
  4. 見出しと本文
    • Markdown文書としては正しい形
    • 見出し1行、内容1行なのでスカスカしており、目が滑る
    • 検索性もなにもない

Obsidian Properties

読書カードの項目に Properties を使うと何が得られるか。

  • Properties なら、見た目が整う
  • Properties なら、検索性が得られる
  • Properties なら、データの構造を損ねない
  • Properties なら、入力補助が得られる
    • テキスト、テキストリスト、数値、日時などがある

Properties の制約

  • 一部予約されている項目がある(aliases, tags, cssclasses)
  • キーを定義すると、Vault全体で共通の型として扱われる
  • キーの幅は狭く、asciiで11文字くらいしかフルで表示できない
型を壊してみた
  • 型に合わない変更を行うと確認のダイアログが出るが、強行できる
  • TextDate にするなど、扱えないデータの場合は単純に無視される
  • TextList の間には特別な処理が挿入されていて、ある程度互換性がある

読書カードにPropertiesを使ってみた

  • 絵文字のプレフィックス📖を付けてみた
  • 読書カード用のテンプレートを用意し、あらかじめキーを入力しておいた
  • 検索はしやすくなった
    • ["📖/読了日": 2023] などと絞り込める

所感

  • 機能として補助が入るので、書いてEnterを押せば次の項目に遷移するため、若干入力しやすい
  • プレフィックスを付けたものの、キーが同じで型が異なるユースケース、あるだろうか
    • まぁ、まとめるのは楽だが細分化するのは大変なので、分けておく
      • アップキャスト、ダウンキャストの話みたいだな
  • もはやYAMLフロントマターが主役なので、 Markdown文書ではない
    • 本文には気になった参考文献でも書いておこうか
  • 結局、検索にI/O負荷がかかるので、特定ファイルを最速で開きたければきちんとファイル名をつけてクイックスイッチャーで開くのがよい

2023年のイベント参加を振り返る

2023年の終わりにイベント参加を振り返ってみた。 今年はGoogleカレンダーに詰めておいたので回収しやすい。

コンサートイベント

  • 01月: 十三機兵防衛圏 オーケストラコンサート
    • 両部現地
  • 01月: リスアニ!LIVE 2023
    • Day2現地
  • 01月: シャイニーカラーズ PW完走イベント
    • 昼の部
  • 02月: アイドルマスター MOIW2023
    • 両日現地
  • 03月: シャイニーカラーズ 5th LIVE If I _ wings.
    • Day1現地
    • Day2配信視聴
  • 06月: シンデレラガールズ 耀城夜祭
    • 両日配信視聴
  • 07月: シャイニーカラーズ ソロパフォーマンスLIVE 我儘なまま
    • Day1現地
    • Day2配信視聴
  • 08月: シャニマス CANVAS 1-4 リリースイベント
    • 昼の部
  • 09月: シンデレラガールズ Shout out Live
    • 両日現地
  • 10月: シャイニーカラーズ 5.5th LIVE 星が見上げた空
    • 両日現地
  • 11月: ミリオンライブ 10th LIVE tour Act-3
    • 両日配信視聴
  • 12月: 異次元フェス アイドルマスター★♥ラブライブ!歌合戦
    • 両日現地

去年は11件ライブイベントあったね、って話をしてたんですよ。12件あるってぇ!!!

まぁ、リリイベはコンパクトなイベントだからコンサートにカウントするのは違うかもしれない。それでも10件はある。

そのほとんどが心揺さぶるイベントで、凄い一年だったよ2023年。 財布も揺さぶられてる。現地参加はアーカイブ視聴もしてるから現地3日分くらい出費になってる。

いくつか円盤もやってくる。

イベント

そして、今年はコンサートイベントだけではなかった。 配信番組のイベントなど、現地に赴くイベントもあった。

  • 01月: トゲガール 1stイベント
    • 現地
  • 03月: へんぼっけ 春の幸せ劇場 2023
    • 両部現地
  • 05月: 技術書典14
    • オフライン会場
  • 05月: これがきたはらの祭典01
    • 両部現地
  • 05月: だまゆフォトブックリリースイベント
    • お昼ごろの部1件に参加
  • 05月: トゲガール 1st写真集オンラインサイン会
    • 配信視聴
  • 08月: 朗読劇「胡蝶ノ、ユメ」
    • 幸村さん出演回
  • 09月: TGS2023
    • 日曜日現地
  • 09月: ウィクロスフェス with 電音部
  • 09月: へんぼっけ 秋の幸せ劇場 2023
    • 両部現地
  • 09月: のりこめ!写真集お渡し会
    • お昼ごろの部1件に参加
  • 11月: 声優グランプリ ハロウィンパーティー 2023
    • 昼の部現地
  • 11月: AliceEyez ファンミーティング 第03回
    • 夜の部現地

はい。13件ありました。毎月なにかしらイベントがあって、それは充実した一年になるはずだ。

配信番組のイベントが目立つ。1stイベントなど新たなチャレンジの場に参加できたのはとても嬉しい。2024年も引き続いていくことを楽しみにしている。

ということで、2023年を振り返ってみた。無理せずにいこう。すでに来年はシンデレラで6件のライブが確定している。(ほとんど配信で見ることになるが)

↓2022年の振り返り。

yajamon.hatenablog.com

おまけ:ならべてみよう

  1. 01月: シャイニーカラーズ PW完走イベント
  2. 01月: トゲガール 1stイベント
  3. 01月: リスアニ!LIVE 2023
  4. 01月: 十三機兵防衛圏 オーケストラコンサート
  5. 02月: アイドルマスター MOIW2023
  6. 03月: へんぼっけ 春の幸せ劇場 2023
  7. 03月: シャイニーカラーズ 5th LIVE If I _ wings.
  8. 05月: これがきたはらの祭典01
  9. 05月: だまゆフォトブックリリースイベント
  10. 05月: トゲガール 1st写真集オンラインサイン会
  11. 05月: 技術書典14
  12. 06月: シンデレラガールズ 耀城夜祭
  13. 07月: シャイニーカラーズ ソロパフォーマンスLIVE 我儘なまま
  14. 08月: シャニマス CANVAS 1-4 リリースイベント
  15. 08月: 朗読劇「胡蝶ノ、ユメ」
  16. 09月: TGS2023
  17. 09月: へんぼっけ 秋の幸せ劇場 2023
  18. 09月: ウィクロスフェス with 電音部
  19. 09月: シンデレラガールズ Shout out Live
  20. 09月: のりこめ!写真集お渡し会
  21. 10月: シャイニーカラーズ 5.5th LIVE 星が見上げた空
  22. 11月: AliceEyez ファンミーティング 第03回
  23. 11月: ミリオンライブ 10th LIVE tour Act-3
  24. 11月: 声優グランプリ ハロウィンパーティー 2023
  25. 12月: 異次元フェス アイドルマスター★♥ラブライブ!歌合戦

あなたはどこに参加しただろうか?

HHKB StudioにDvorak配列のプロファイルを生やす

これは、HHKB Studio(日本語配列) を Dvorak配列にリマップした記事である。

買っちゃった

鳴り物入りで登場した HHKB の新しいシリーズ、「HHKB Studio」。 ポインタスティック付きのキーボードに興味がないことはなかったが、何よりも複雑なキーリマップに対応しているらしいことに強く興味が惹かれた。

いつもソフトウェアリマップで実現しているDvorak配列を、ハードウェアリマップで実現できる可能性がある。 たとえばソフトウェアリマップが期待できないPS5に接続してもDvorak配列を持ち込めるようになるのだ。実際にキーボード操作をする機会があるかはさておき。

ということで、ショップに張り付いて HHKB Studio 日本語配列 を購入した。

HHKB Studioの写真
my new gear...

https://x.com/Yajamon/status/1735863068356391151?s=20

Dvorak 配列にしたい

私は普段からDvorak配列を使っている。Windowsではソフトウェアリマップを利用して、macOSではキーボード設定によって実現している。

Dvorak配列とは、キーボード配列のひとつである。 母音が左手のホームポジションに集中しており、右手と左手の指を交互に使うので、英語のみならず日本語のローマ字入力にも有効な配列だ。

ja.wikipedia.org

しかし、一つ問題がある。Dvorak配列とは、US配列のキーボードをベースに再配置した配列である。 これに対し、HHKB Studio(日本語配列)は記号類が期待した位置にない。

たとえば、

  • @Shift + 2 に無い
  • 'Shift キー入力なしに入力できない

といったものだ。

日本語入力等の都合上、英語配列に切り替えるつもりはないので、Dvorak配列に求められる細かな違いもリマップによって実現したいと考える。 この複雑な要求に答えてくれるのが、 HHKB Studio および そのリマップなのだ。

HHKB Studio リマップの特徴

HHKB Studio のリマップは、以下の特徴がある。

  • プロファイルを4つ持てる
  • プロファイルごとに、標準キーレイアウトを1つ、Fn1-Fn3キーと同時押しで使う拡張キーレイアウトがある(合計4つのキーレイアウト)
  • Windows用、macOS用、Dvorak配列用(Win)と3種のプロファイルで運用することにした

HHKB Studioキーマップ変更ツール

HHKB Studio リマップの制約

HHKB Studioはリマップが柔軟になっているが、いくつか制限がある。

  • Fn1-Fn3 キーは、標準キーレイアウトにのみ設定できる
  • Fn1 キーレイアウトは、上書きできない予約キーがある
    • プロファイル切り替えに使う C など
    • 予約キーの位置は、標準キーレイアウトでの位置に引きずられる

リマップする

これらを踏まえ、以下の方針でリマップする。

  • 割り当てるキーの種類に「ショートカット」がある
    • Ctrl キーや、 Shift キーと同時押ししている入力を、単一のキーに割り当てられる
    • これで、ハードウェア的には Shift キーを押さずとも、 ' を入力できる
  • Fn3 キーレイアウトを使う
    • 初期設定では未使用のため、何を設定してもよい
  • Fn3 キーを左 Shift の位置に割り当て、レイアウトの内容のほとんどをDvorak配列で Shift 同時押しで期待するものに置き換える

そうしてできたリマップが以下の画像である。

標準キーレイアウト
Fn3キーレイアウト

https://x.com/Yajamon/status/1735947130173579576?s=20

Dvorak配列に置き直したキーだけでなく、Tabやクリックボタンに関しても Shift 同時押しショートカットを割り当てられたおかげで、違和感のないDvorak配列を実現できた。

現在の設定をGistで公開した。 Profile 3Dvorak配列が設定されている。なお、Profile 1, Profile 2にも独自の設定があるので注意されたし。

HHKB Studio (日本語配列) の設定。 Profile 3 をDvorak配列に改変している。 https://yajamon.hatenablog.com/entry/2023/12/18/110542 · GitHub