sh1’s diary

プログラミング、読んだ本、資格試験、ゲームとか私を記録するところ

2022 年 会社勤めの買ってよかったモノ、まとめ

12月の風物詩。毎年やっているけど、買って損していないのかチェックみたいな気もする。

運動系

ランニング

コロナ禍になってからというもの、どうしても運動不足気味になるので、ランニンググッツを増やしました。家でちょっとしたランニングの際に利用するセット。

夜走る際は LED クリップライトと反射アームは必須です。最初は自分の身を守る用途だと思っていたのだけれけど、ですね、これ。

夜にすれ違う人間って、ちょっと怖いんですよね。(ほとんどマスクもしているし)怖がられるのは、自分のことだと知る。

常識的なランニングの服装をしている+LEDを付けている+反射アームをつけているっていうのは、その人の目的がはっきりします。犬の散歩をしてる人を必要以上に警戒しないのと同じで、安心して貰えるというか。マナーなんだな、と強く思った。

最後に、メリノグローブは初めて使ってみたけど、スマートフォンの操作がしやすくて感動した。FlipBelt はとにかく便利。ジッパーの中にスマホと家の鍵を入れて走ります。(背中に回せる)2つ欲しい。

矯正

軽度の巻き爪持ちです。ランニングの回数を増やすとちょっと親指の爪端が食い込んで痛いな、って感じるようになったので、とりあえず試しに。(血が出るほどではない)

サンプルの爪の形状がえぐい。ちょっと怖い。

取り付けたところの爪が割れたりしたけど、矯正する力はしっかりしてて、爪が痛い症状はすぐに改善。ただ、すぐに外すと元に戻っちゃうみたいなので、つけっぱなしにしてます。

筋トレ

45kg が軽くなったので 54 kg に更新しました。今は、54 kg もだいぶ楽になってきた。テレワークで集中が切れたときに、腕立て伏せ、ハンドグリップ、腹筋ローラー、ストレッチポールなんかをしています。

ストレッチポールは、通っているジムに置いてあった物と同じ物を購入しました。猫背になるので、疲れたときや、寝る前に柔軟すると腰が気持ちいい。

体重計

スマホで体重や体脂肪率などを記録できる。パッと乗ったら、自動でスマホに記録されてるんで楽。元々は月に1回程度の頻度でジムの体重計で同じように調べてたけど、モチベーション向上を目的に購入。

ゲームとか、データで遊ぶのが好きな人は、体重計は面白いアイテム。筋トレや食事の改善を考えるときは絶対にあったほうがいい。毎日、週、月の結果から判断するようになったほうがノウハウも溜まるし、どのくらいの運動量、どのくらいの食事がどのように影響するのかよくわかる。(あと、風邪をひいたときの影響なんかも、すごかった)

QOL 関係

センサーライト

夜にトイレ行きたくなったときは、いちいち電気をつけないことのほうが多いです。で、目が慣れない暗闇の中で、なんか踏んだり足をぶつけたりする。愚か。飼い犬のトラップだ。

このセンサーライトは、周りが暗いとき、なおかつ、人がいるときに反応するタイプ。無駄なときは点灯しないので、電池が長持ちする。

Anker Eufy (ユーフィ) HomeVac H11

デスク回りなどの埃とり。ちょっとした掃除をよくする人はおすすめ。

Sound Blaster Play! 4

テレワーク時のマイクは持っているけど、ちょっと古いタイプでノイズがのりやすかったため追加。Creative の製品は、スピーカー T60 も愛用してるけど、丁度いい価格でほど良い満足感が得られるので好感が持てる。

友達と一緒に COOP 対応のゲームで遊ぶときにも活躍する。

カナル式やヘッドホンはちょっと耳まわりが疲れやすいので、疲れづらいモデルを用意しました。

音質を気にしないときは、これでいいかってなった。収納ケースを開けてイヤホンを取り出すと自動で(デスクトップ PC でも)スピーカーはイヤホンに切り替わり、イヤホンを収納ケースにしまうとスピーカーに戻る。

地味にこれは感動した。すごい。そういう動作を自動でするんですね。

Fire HD 8 Plus タブレット

タブレットなんて何につかうんだと思っていたけど、コロナ禍の間は特に髪をバリカンで切っていたので、タブレットで映画やアニメを見るのは便利でした。

スマホで見るよりも電子書籍の特に参考書関係は読みやすくて便利。旅行の際も、移動中、渋滞時の映画や飛行機の待合など隙間の時間に活躍することがわかった。

使おうって持っていたら全然使えるし、ノート PC の出番が減る。

プログラミング

プログラミング関係の書籍は今年はあまり読めていない。Unity 関係も去年に続いてあまり触れず。

リファクタリング関係への興味は今も薄れていないけど、リファクタリングとテストの紐づきが年々しっかりしてきている感覚を覚えます。

投資・金融基礎

初心者です。投資関係の本は、風呂に持ち込んで長風呂して逐次読破していきました。メモが取りたいけど、とにかく一読しないと始まらないと思った。気になったら、あとで部屋で読み直せばいいやって感じにしました。

お金に関する理解度を上げると、現代人として生きる能力の向上を感じる。スポーツが根性論だけでは通じなくなっているのと同じように、お金に関しても、ただ溜める、ただ稼ぐだけでは通じない or 能力が足りないのではないか、と個人的に思うようになりました。(ほどよく楽に生きるにはバランスの悪い感じがします)

その他・漫画

今年はこれだけ。小説は古本屋でちょこちょこ購入してた。(あとで追記するかも)

ちはやふるが完結するらしい。長年にわたって熱をわけてもらった作品。熱中すること、熱を感じることができる作品だと思う。

ルリドラゴンは話進んでないみたいだけど面白いので頑張ってほしい。(怪獣8号は合わなかった。主人公以外も人間離れしすぎてて、中盤以降の進撃の巨人と同じで危機感を全く感じない)

総括

相変わらず成長を感じない一年でしたが、今年のプライベートは、投資を(いくらか本格的に)はじめたことが大きな変化でした。

去年の総括では、「来年度の学びたいことや目標のようなものは定まっておらず」としていたけど、プライベートのこたえは「投資」になったと思います。

大学の学費をまとめて支払ったので、もう借金らしい借金がない。いいことなんだけど、世間の金銭感覚やお金の悩みと距離が空く感覚がありました。

なんで、今年は投資をやってみようとなった。はじめたところ、コロナ禍(第三次)、ロシアとウクライナの戦争、アメリカの金融引き締めと、ここ数年で一番のビックウェーブに参入した形となりました。自分の投資したお金が、結構な乱高下をする様子をみて、自分の心がどうなるのか見つめる経験ができたのは、よかったと思います。

結果的に言えば、この一年の投資は常識的なプラスで終わりそうです。また、思ったほど自分は、睡眠に影響が出ることもなければ、大きなストレスになることもなかったです。ただ、国際情勢や政治のことを調べる機会は圧倒的に増えました。(前年、前々年に政治関係の教科書を趣味で読んでいてよかった)

当然反省もあって、「金利のない日本だと3%でもプラスになれば合格でしょう」くらいの考えで予定して投資をしたのですが、あきらかにそれよりも大きな額になってしまった。(自慢ではないです)素人なんだな、と強く実感できた。予定よりもリスクを取っていたから、リターンが生まれてしまったのだと感じています。

来年は、リスクの理解を深めたい。なので、来年も投資に関しては継続。精神的にも落ち着く効果が見られたので、投資の古典/教科書的なものは継続して読んでいきたい。

最後に、ビジネス面での今年は、実務がここ数年で特に忙しかった。「今年は仕事に集中しよう」というスイッチも途中で入った。コロナ禍ピークの間は、熱を入れることもなかったので、その代わりといったくらいには働いたと思います。いただいた賃金よりもよく働いたので、来年は相応に戻そうと思っています。

それで、Unity の勉強/遊びを再開したいです。

履歴

C# デバイスマネージャーを開く(.NET 6)

.NET Framework 時代のデバイスマネージャーは、以下のようなコードで呼び出されていたと思います。

Process.Start("devmgmt.msc");

.NET6 や .NET7 が現れる現在だと上記のコードは例外が発生してエラーになります。

An error occurred trying to start process 'devmgmt.msc' with working directory 'C:\Users...\bin\Debug\net6.0-windows10.0.17763.0'. The specified executable is not a valid application for this OS platform.

指定された実行は、OS プラットフォームで有効なアプリケーションではありません、というような感じでしょうか。実際は、Windows OS で実行しているので「そんな馬鹿な!」って感じでエラーメッセージも十分機能しているとは言えない状態です。

解決

以下のコードを実行します。ただし、アプリケーションを「管理者」として実行する必要があります。

var processStartInfo = new ProcessStartInfo
{
    FileName = "mmc.exe",
    Arguments = "devmgmt.msc"
};

var process = new Process
{
    StartInfo = processStartInfo
};

process.Start();

従来は、特にアプリケーション権限のような要件は、必要としていなかったように思います。(違っていたらすいません。忘却しています)

なので、今回の問題の根本的な要点は、セキュリティ的な都合ではないかと思いました。確かに、どんなアプリケーションからでも mmc.exe のサービスに対して簡単にアクセスできてしまうというのは、セキュリティ的な視点では面白くないのかもしれないです。

プラスα

Process.Start() を呼び出す前に、アプリケーションが管理者の権限を有しているかどうかを確認して、管理者 (Administrator) のときだけコントロールを有効にする、または、実行を可能にするような安全対策をしておけばよいと思います。

    public bool HasRoleAdministrator
    {
        get
        {
            var identity = WindowsIdentity.GetCurrent();
            var principal = new WindowsPrincipal(identity);

            return principal.IsInRole(WindowsBuiltInRole.Administrator);
        }
    }

参考

WPF カスタムコントロールの作り方(ToggleButton の例)

WPF のカスタムコントロールの作り方……というか、基本的には設計者が設計したとおりに動作すればそれでいいような気もしますが、WPF にはいろんなカスタムコントロールの作り方があって、お作法というのか一応、とりあえず基本の線路はこれってものがあると思っていて、そこからやりやすいようにすればいいと思います。

以下のリンクでは、ユーザーコントールで Toggle を実装しています。

記事中では WPF の ToggleButton は認識しづらい……という話でスタートしているので、 ToggleButton のカスタムコントロールを作る話になると思うのですが、UWP の ToggleSwitch に引っ張られたのかユーザーコントールで実装されています。

ユーザーコントールにすると、当然ですが UserControl のプロパティを持つことになるため、ToggleButton のプロパティをそのまま継承することができないです。IsChecked プロパティをそのまま使えないのは面倒ですよね。(記事を見ればわかりますが)Dependency Property を使って、ToggleButton っぽいプロパティの再定義をすることになります。私は、あまり効率のよいやり方だとは思わないのですが、0から丁寧に再設計をしたいなら良いのかもしれないです。

そんなところで、今回は、ToggleButton のカスタムコントロールで作るパターンを書いた記事です。

以前にも似た記事を書いていますが。

カスタムコントロールライブラリ

まず、カスタムコントロールを作成するソリューションのプロジェクトは、「WPF カスタム コントロール ライブラリ」に分けておくことをオススメします。理由は、カスタムコントロールを作るくらいだし、使い回せるようにしたほうがいいと思います。

WPF カスタム コントロール ライブラリ」を作成すると、プロジェクトの構成は、こんな形になっていると思います。

作成するカスタムコントロール.cs ファイルはこんな感じで作成されています。DefaultStyleKeyProperty はコントロールのデザインを決めるためのもので、Generic.xaml ファイルで設定されます。(これはそういう WPF のルールで、必ず Themes/Generic.xaml ファイルから読み込むことになっています)

デフォルトだと作成するカスタムコントロールのファイル名は CustomControl1 みたいになっていると思いますが、具体的な名前に変更します。今回は ToggleControl にします。本当は ToggleButton がいいけど、コントロールとしてすでに存在するためややこしいので。(あとで ToggleBoxToggleSwitch で良かったかもと思いました)

ToggleControl の継承元はデフォルトだと Control になっていると思います。具体的なコントールの継承予定があるなら、そっちにしたほうがいいです。たとえば、TextBox、CheckBox、ToggleButton のデザインを作り変えて、すこしプロパティを追加したい、くらいなら素直にそっちを継承します。今回の例では ToggleButton を作ります。なので、ControlToggleButton に書き換えておきます。

public class ToggleControl : Control // ToggleButton に書き換え
{
    static ToggleControl()
    {
        DefaultStyleKeyProperty.OverrideMetadata(typeof(ToggleControl), new FrameworkPropertyMetadata(typeof(ToggleControl)));
    }
}

Generic.xaml ファイルは、DefaultStyleKeyProperty で指定したデザインを記述してあります。プロジェクトが HeritageLibrary.Wpf.Controls だと、こんな感じに記述しています。

実際のところは Themes/ToggleControlTheme.xaml にコントールの具体的なスタイルを記述しています。BasedOn で継承してやることで、このファイルでもデザインを拡張できるメリットもありますが、どちらかというと Generic.xaml にごちゃごちゃとスタイルを記述すると、わけがわからないことになるので、このようにしています。

Generic.xaml の役割は、「あくまでもカスタムコントロールに、スタイルを適用すること」だけにしています。

<ResourceDictionary
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:heri_ctrl="clr-namespace:Heritage.Wpf.Control">
    <ResourceDictionary.MergedDictionaries>
        <ResourceDictionary Source="/HeritageLibrary.Wpf.Controls;component/Themes/ToggleControlTheme.xaml" />
    </ResourceDictionary.MergedDictionaries>

    <Style TargetType="{x:Type heri_ctrl:ToggleControl}" BasedOn="{StaticResource ToggleControlDefaultStyle}" />

</ResourceDictionary>

ToggleControl のデザインはこんな感じです。このファイルでやっていることは ToggleControl のスタイルを定義しているだけです。それ以外はやりません。

これは、一般的なクラスファイルと同じ考えです。1つのクラス……ファイルに、いくつも役割を持たせると Git で更新履歴を管理するメリットが薄れてしまうと思います。ファイルの更新履歴を見たときに、どの役割に変更が入ったのか、パッと見てもはっきりしなくなってしまうと思います。1ファイルの役割が少ないほど、更新したときになぜ更新されたのかがわかりやすいです。

役割に変化がなければ、更新もされない。Generic.xaml も新しいコントロールを追加しない限りは更新されません。更新履歴の多いファイルは、作業/仕事をした感が出ているかもしれないですが、(個人的な意見ですが)そうしたファイルは、結構な割合で役割過多なファイルだと思っていて、設計的な意味で注意して見たりします。

<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
                    xmlns:hf_conv="clr-namespace:Heritage.Wpf.ValueConverters;assembly=HeritageLibrary.Wpf"
                    xmlns:hf_ctrl="clr-namespace:Heritage.Wpf.Control">

    <Style x:Key="ToggleControlDefaultStyle" TargetType="{x:Type hf_ctrl:ToggleControl}">

        <Setter Property="SnapsToDevicePixels" Value="True" />
        <Setter Property="UseLayoutRounding" Value="True" />
        <Setter Property="FocusVisualStyle" Value="{x:Null}" />
        <Setter Property="HorizontalAlignment" Value="Left" />
        <Setter Property="VerticalAlignment" Value="Top" />

        <Setter Property="Template">
            <Setter.Value>
                <ControlTemplate TargetType="{x:Type hf_ctrl:ToggleControl}">
                    <Border Name="_Box"
                                Height="20" Width="40"
                                CornerRadius="10"
                                BorderThickness="1" Padding="2">
                        <Border Name="_CheckMark" 
                                    Width="14"
                                    Height="14"
                                    HorizontalAlignment="Left"
                                    CornerRadius="10">
                            <ContentPresenter />
                        </Border>
                    </Border>
                    <ControlTemplate.Triggers>
                        <Trigger Property="IsChecked" Value="True">
                            <Setter TargetName="_CheckMark" Property="HorizontalAlignment" Value="Right" />
                            <Setter TargetName="_CheckMark" Property="Background" Value="#FFFFFFFF" />
                            <Setter TargetName="_CheckMark" Property="BorderBrush" Value="#FF0067C0" />
                            <Setter TargetName="_Box" Property="Background" Value="#FF0067C0" />
                            <Setter TargetName="_Box" Property="BorderBrush" Value="#FF0067C0" />
                            <Setter TargetName="_Box" Property="BorderThickness" Value="0" />
                        </Trigger>
                        <Trigger Property="IsChecked" Value="False">
                            <Setter TargetName="_CheckMark" Property="HorizontalAlignment" Value="Left" />
                            <Setter TargetName="_CheckMark" Property="Background" Value="#FF5B5B5C" />
                            <Setter TargetName="_Box" Property="Background" Value="Transparent" />
                            <Setter TargetName="_Box" Property="BorderBrush" Value="#FF868688" />
                            <Setter TargetName="_Box" Property="BorderThickness" Value="1" />
                        </Trigger>
                        <Trigger Property="IsEnabled" Value="False">
                            <Setter TargetName="_CheckMark" Property="Background" Value="#FFFFFFFF" />
                            <Setter TargetName="_CheckMark" Property="BorderBrush" Value="#FFCCCCCC" />
                            <Setter TargetName="_Box" Property="Background" Value="#FFCCCCCC" />
                            <Setter TargetName="_Box" Property="BorderBrush" Value="#FFCCCCCC" />
                            <Setter TargetName="_Box" Property="BorderThickness" Value="0" />
                        </Trigger>
                    </ControlTemplate.Triggers>
                </ControlTemplate>
            </Setter.Value>
        </Setter>

    </Style>

</ResourceDictionary>

ToggleControl のうごき

こんな感じでテストしてみます。

<UserControl x:Class="..."
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
             xmlns:hf_ctrl="clr-namespace:Heritage.Wpf.Control;assembly=HeritageLibrary.Wpf.Controls"
             mc:Ignorable="d" 
             d:DesignHeight="450" d:DesignWidth="800">
    <StackPanel Orientation="Vertical">
        <hf_ctrl:ToggleControl IsEnabled="False" />
        <hf_ctrl:ToggleControl />
    </StackPanel>
</UserControl>

ToggleButton の見た目が悪いだけなら、これだけでもかなり良くなったのではないかと思います。

個人的な意見として「カスタムコントロール」の欠点は、いつも作り方を忘れてしまっていることです。よく触る機能ではないので、触るたびに基本的な記憶が抜けてます。

そこで、もう少しデザインを凝るなら、ToggleButton の「xaml の実装」を確認するのも良いやり方だと思います。基本的なスタイルをカバーする方法を学ぶことができます。

サンプル

GitHub に、今回のサンプルを公開しています。

参考

ダンジョンスクワッド 攻略ヒントのメモ

ダンジョンメーカーで知られる GAME COASTER の新作スマートフォンゲーム DUNGEON SQUAD の個人的にプレイしてみた感じの攻略メモです。ちなみに squad は分隊くらいの意味みたいです。

現在、Build 00130 のプレイ情報でしたが Build 00149 あたりにも言及。

クラケンはまだ未プレイ(未開放)。他キャラは全部ノーマルクリア。ヨルムンガンドで難しいクリア。くらいのプレイ感での情報まとめです。

ステノとクラケンは、特にいいネタあったら教えてほしいです。

重要な情報

  • マスタースキルは、アクティブスキルを回強化してから、闇の根源より選択(強化は捕虜変換の重なりなので運要素)
    • アクティブスキルの強化は5種類あるので、全部を取得できない(ビルドに関わるので注意)
  • 一部のパッシブスキルは、アクティブスキルを取得しないと出現しない
    • 「酸性アンコウ」の選択は重要なので、はやめに出現させたい
    • 逆に選択肢を減らす目的でスキル取得を(一時的に)控えるのも、ビルド完成率を高めるテクニック

ディアブロ

初クリアなのでビルドは甘い感じ

初期スキルの火種を伸ばすのと雑に強かったです。ノーマルなら以下の組み合わせでどうでしょうか。

  • 恐怖の火種
  • 終末
  • 炎 or 恐怖の領域
  • 地獄の炎
  • 自由
  • 自由

序盤は地獄の炎くらいを覚えたら、あとは下手に他スキルを覚えずに恐怖の火種と地獄の炎を伸ばしたほうが序盤は対処しやすいと思います。2面のどこかで終末を伸ばすくらいで間に合うような気がする。

火を伸ばす or 闇を伸ばすビルドに大きくわかれるので、半端にしないほうがいい。(「地獄の炎」or「深淵の闇」は、属性ダメージを2倍にして、逆の属性をパーティ含め半減にするスキルなので強力だけど、パーティ構成に注意が必要になる)

最初から決めておいたほうがよくて、炎ならケルベロスを入れたいし、闇ならダークペガサスを入れるとシナジーがある。ふたりは同じような攻撃タイプ。(ダークペガサスは物理+魔法属性だけど)いずれの場合も、半減するスキルがあるので、炎ならダークペガサスは雇用できないし、闇ならケルベロスはやや落ちる。(闇の砲撃は強力だけど、他で炎が乗りやすいから)

ボスへの火力も平均~以上には期待できるけど、一人でどうにかできる感じではない。分隊のみんなで頑張ろう、みたいな感じになると思います。

アイテムはクリスタル+クリスタル(範囲増加)を入れるポジション。指輪+魔法書でシールドをつけるのもいいと思います。

なお、クラケンを分隊加入する際は、濡れをつけないこと。火属性ダメージが-30%になってしまうのでマイナスです。通常は加入させても、やむを得ない5人目くらいで「捕縛」したいだけの運用くらいになると思います。(アップデートで変更されました)

全キャラ共通で3面ボスを対処できないなら、メドゥーサを入れて後述の石化寄りのビルドをすると吉。また、「神聖だった存在」で聖属性対策するのも効果があると思います。

ケルベロス

2キャラ目でメドゥーサに気づきつつある

簡単。ビルドの方向性が楽。

初期スキル+「三頭」を活かすビルドが基本です。ショックウェーブ」は「三頭」が活きない(アプデで変更があり、純物理+阻害ビルドとして並みのスキルになった)ので、どちらかというと4~5人目で分隊に加える際に三頭ビルドを形にできる時間がないなら簡易ビルドとして有効かも。「ショックウェーブ」だけ伸ばせば、気絶や束縛で邪魔できるはずなので雑に貢献しますが、気休めくらい。

評価が高いのは、「砲撃」を伸ばして最後に「闇の砲撃」にする。「盾熟練」を取得してボスからの攻撃に耐える守備を主力に乗せるあたりかと思います。個人的にはこのあたりが伸び切らないのが致命的だと思うので、このあたりから取得するようにします。(初期スキル伸ばしたいけど、初期スキルだけでは力不足だし)

ケルベロスはバフに乏しい印象があり、後半ダメージが入りにくい状態になってしまったらアイテムで攻撃を伸ばせなかったか、分隊のデバフが足りない気がします。

分隊ディアブロを入れると「地獄のトゲ」が火属性一致したり、「恐怖拡散」を使ってもらって被ダメージ増加など、全体攻撃が得意なケルベロスと方向性が一致しています。(アイテムも攻撃と魔法ですみ分けしやすい)

ディアブロを加入させると物理+火炎ビルドになるので、純粋な物理特化のビルドにしない場合は、クラケンの分隊加入に注意。濡れをつけないこと。火属性ダメージが-30%になってしまうのでマイナスです。(アップデートで運用しやすくなっています)

アイテムは血の剣(ルビー+長剣)、はやくもナーフを受けた血石の首飾り(ルビー+首飾り)は間違いなく向いているはずだけど……といった感じで、回復手段の乏しいゲーム性なので入れておくと多少の安定に寄与すると思います。

ヨルムンガンド

完全にやりたいビルドを意識してる

ちょっとだけ慣れるまで難しいかもしれないけど、ビルドが形になると一番わかりやすく強いって感じると思います。

  • 酸性胞子
    • 追加投射体、弾倉、リロード優先
  • 飽食
    • 引き寄せスキル優先
    • マスタースキル「魅惑の入口」を覚える
  • 酸性地帯
  • 酸性アンコウ
    • 酸性胞子の発動時に、30%の確率で目標地点に飽食を発動
  • 超再生身体
  • 過成長

序盤は、すぐに分隊に仲間を加える+「酸性胞子」を強化しないと普通に負けるくらい弱いです。できれば飽食のスキルを覚えたら一旦、他のスキルを覚えるのを控えて、飽食と酸性胞子のマスタースキルを目指しつつ、「酸性アンコウ」だけは例外で覚える。超再生や過成長をはやくに覚えると、攻撃を伸ばすビルドの成長が、遅れてしまう恐れがあります。(序~中盤の戦闘で押されてしまう)

「酸性アンコウ」は飽食を発動させるタイプを選択する必要があり、違うものを選択するとビルドが死んでしまいます。要注意。

アイテムはクリスタル+クリスタル(範囲増加)、(長剣+ルビー)、(盾+盾)など。分隊とアイテムで耐性やデバフを整えれば、難しいの難易度でも3面ラスボスと数十秒タイマンできる性能になりました。

分隊は、地味にヨルムンガンドが晩成型の攻撃なので、序盤の牽引係として個人的にはケルベロスよりもダークペガサスのほうがアイテムの取り合いで楽になる気がする。ただ、ダークペガサスは、「鋼鉄の羽」を順調に伸ばしてマスタースキルの「超巨大な羽根」をはやめに覚えないと、火力不足になると思います。

タイタン

ビルドに失敗したけど何とかなった

おそらく、(ルビー+首飾り)のナーフで一番泣いている。2面以降、雑魚狩りのプロをしてほしい。

範囲スキルがわかりやすいので、攻撃=アイテム効果で回復をばらまいてヒーラーを担当する運用が、初期バージョンだとわかりやすかったと思います。なので、以下はちょっと弱体しています。

  • 雷の矢
  • 連鎖稲妻
  • 稲妻の波長
  • 超電流
  • 蓄電球

雑魚処理や回復などのサポートが得意なキャラだと思っていて、少なくともケルベロスのような、わかりやすい火力を持っていないです。また、シールド系全般ですが、3面ボスは密着まで接近してきてくれないので、一番の要所で死にスキルとなりかねないものは、注意が必要です。

「雷閃」は、マスタースキルで一部キャラにシナジーがあるものの、まだビルドの軸にするのは難しそうです。

とにかく、連続発動が前提、かつ、3面ボスは苦手とするはずなので、メデゥーサを石化ビルドしておくのが一番形になりやすいと思います。(ただし、石化ビルドは道中弱いです)タイタンは雑魚処理できるビルドにしつつ、ボスを分隊でどう対処するのか、といった模索をすることになると思います。

なお、クラケンを分隊加入する際は、濡れシナジーがあるので、雑に強化アイテムっぽく利用できます。しかし、どっちも範囲攻撃を得意するけれど、ボスを攻撃する能力に欠ける点に注意。(クラケン自体のアップデートバフが大きいのでシナジーが上がっています)

攻撃が魔法属性なので、(指輪+魔法書)や(指輪+指輪)が欲しい。魔法寄りアイテムを集めてしまうので、ディアブロ+ステノを入れると、アイテムの取り合いになる。特に序盤のアイテムで長剣あたりが出ると悲しいので、攻撃型のキャラをはやめに加入させておいたほうが安心できると思います。(なので、クラケンはおすすめ)

ダークペガサス

初期3キャラでやりたいことができた

個人的にダークペガサスは、序盤の分隊に加入させて補助的なビルドをするサブキャラとして活躍させやすいキャラだと思います。(メインとしては、ノーマルクリアに4回くらいかかってしまい、ゲームを理解するきっかけになったキャラでした)

魔法+攻撃のハーフなのでアイテムを選ばないためゴミ箱にしても腐りづらい。物理型、罠型、闇型(デバフ)とビルドが複数あるので、メインキャラに合わせてビルドの使い分けも可能で、癖のあるクラケンとは逆に対応力があると思います。とりあえず、基本の物理型だとこんな感じだと思います。

  • 黒い羽
  • 鋼鉄の羽
  • 一千の羽
    • 羽を1回投げるたびに1~5の羽が累積
  • 自由

羽をたくさん投げるビルドは見栄えいいし、ノーマルだと無理なく使えると思います。(スキル加速をすこし乗せるのもよさそう)なお、闇ビルドなら、「一千の羽」は「一千の羽にダメージを受けた敵は5.0秒間闇耐性が20%減少」を選択すると思います。

他キャラは、範囲型のキャラと相性がいいと思います。攻撃 or 魔法タイプ、どちらでも気にしない組み合わせのしやすさがあるので、良い素体のキャラをそのまま採用してみるとよいと思います。

他キャラがよく重なって、別に火力担当ができてしまった場合、テクニカルだけど、ダークペガサスは(首飾り+首飾り)で分隊のスキル加速もしつつ、「鋼鉄の羽」のマスタースキルを「落雷の羽根」に変更することで、妨害キャラにもなります。(サブキャラで火力伸びないときも、こっちでいいと思う)

普通のビルドは「軽い羽」で「鋼鉄の羽」の弾速を上げたり、貫通効果を高めるんだけど、ビルドの伸びがよいときは、「罠専門家」になると画面上ごちゃごちゃしていい感じ。「一千の羽」+範囲拡大ぎみの「羽罠」は見た目にロマンがあっていいと思います。

アイテムは、(長剣+リング)のルーン剣を一番うまく活用できるキャラだと思うので、なるべく組み入れてあげてほしいです。単純にマスタースキルを狙うので(長剣+長剣)も悪くない。だめそうなら、あきらめて(首飾り+首飾り)や味方の回復を期待して(ルビー+魔法書)や回復係(ルビー+首飾り)など。

3面ボスを一人で倒せることは無いと思います。ディアブロは、ディアブロを中心としたみんな頑張れですが、ダークペガサスは、分隊のみんな頑張れに合わせが可能だと思うので、例えば、メドゥーサの石化を育てつつ、ダークペガサスが道中引っ張るようなビルドも考えられます。ヨルムンガンドのビルドは重たいので、「鋼鉄の羽」のマスタースキルが間に合わないと中盤から厳しいので注意など、捕虜の重なり方をみて進めることになると思うので、分隊とゲームの理解度が必要なキャラクターだと思います。

メドゥーサ

引率のペガサスありがとうビルド

メドゥーサは、初期スキルに引っ張られると、猛毒や酸、物理っぽい型になりますが、それだと猛毒にシナジーのある分隊キャラがまだいなかったり、貫通能力も無ければ跳弾もしないため、下手に育てると劣化ケルベロス、劣化ダークペガサスになってしまいます。

個人的には、(バグかもしれないけど)石化ビルドは3面ラスボスで華のある火力を叩き出してくれるので、おすすめです。(Build 00134 で弱体化してると思います。猛毒スタック上限に変更があったため)

  • 触手の矢
    • [猛毒]ダメージ周期-20.0%/[猛毒]最大スタック+5つ
  • 石の呪い
  • 石化の魔眼
    • [猛毒]につき1の追加ダメージ+5.0%
  • 呪われし瞳
  • 石像狩り
    • 「石化が終了する時、石化状態中の被ダメージの10%分物理ダメージ」
  • 神聖だった存在

石化ビルドのおもしろい(謎)ところは、何が原因で単体高火力を出しているのか今のところよくわかっていないと思います。おそらくスキル強化のダメージ倍率が非常に高いので掛け算の率がすごいため、そのあたりがあやしい or 上記のあたりを積んでいるとバグってて、高体力のキャラに石化が刺さった瞬間溶ける現象が確認されています。(そこそこ刺さります)

アップデートで、どちらかといえば、猛毒寄りにしても強いです。「猛毒の霧」で猛毒威力を上げ、「堕落した血」で猛毒の酸性ダメージを上げる感じ。(なので盾を装備していいのは、えらい)分隊加入なら、ロキとか霧の魔術師とか。

通常だと、3面ラスボスは自分と相手の耐久レースになることも少なくないと思いますが、メドゥーサは上手くやると、ボスが攻撃地点に到着するころには瀕死になっている他ではなかなか見れない絵になります。

個人的に、メドゥーサは4、5人目の分隊サブキャラとしても優秀です。「神聖だった存在」で耐性をつけたり、石化による妨害、小さなビルドでも機能すると思います。ダークペガサスと同じで実は、攻撃型(石化)、魔法型(猛毒)とテクニカルで晩成型だけど使いやすいと思います。

Build 00134 で機能するのかわからないビルドだと思います。

ステノ

難しかったです

ステノは Build 00134 でプレイしました。予想通り難しい。というより、メインで使うと1-2で死にかねない貧弱さ。

  • 黒死病
  • 破滅の群烏
  • 闇の囁き
  • 疫病術師
  • 破滅の指示
  • 遅き死

こんな感じでした。最近バフがあってだいぶ良くなったみたい。

初期だと、「死の命令」と「死と腐敗」が簡単で評価も高かったです。上は面倒かつ凝った育成が必要なビルドだったと思います。実際、「死の命令」から「死の歓喜」をとれば「HP30%以下の敵に死の命令が当たると即死」効果をつけることで、今のところ3面ラスボスにも有効。「死の命令」+「死の腐敗」は雑に機能する。

もう少しメインとして役割を持たせると上述のビルドじゃないかと思うけど、とにかく立ち上がりが悪い。「黒死病」を1発ずつ雑魚にばらまいて、スリップダメージで倒す涙ぐましい作業を推奨しますが、なお厳しい。

プレイ感だと最序盤は間違いなく最弱だと思います。

じゃあ、どうするかというと、2、3人目にケルベロスディアブロを引くまでリセマラするのが一番後半楽だと思います。できれば、ケルベロスは剣士系で、ディアブロは魔法使い系がいいけど片方は最悪村人でもいい。

ケルベロスに「三頭」を入れ、とにかく立ち上がりを急ぎます。ケルベロスじゃないと、1面の強敵系が本当にしんどかった。ディアブロは2面に間に合う程度で闇ビルド。

ダークペガサスは、ディアブロの代わりに入れても機能するかもしれない(後半は間違いなくそう)ですが、序盤に余裕があれば。序盤だけなら、おそらくディアブロのほうが機能させやすい。ダークペガサス+ディアブロだと、序盤~中盤の火力が足りない問題さえ解決できればって感じ。

ステノの強化も特徴的で「黒死病」を3面までまったく強化せず、「破滅の群烏」のマスタースキルを最速で取得し(マスタースキルにならないと弱いから)、次に「闇の囁き」を強化しマスター、最後におまけで「黒死病」をマスターの流れでした。基本スキル無視。(闇の囁きは敵を倒す係ではないので、支援目的)

アイテムもスキル加速をつけるなど、ちょっと珍しい感じになる気がします。

なお、クリア時は4、5人目はほぼ機能していません。神聖耐性を付与してくれた程度かと。

クラケン

簡単になってしまっていた

無事40個あつまったのでクリアしました。

「触手強打」が強くなって、そのあともバフがかかり、濡れもデメリットがなくなり、評価が一番変化したキャラだと思います。

「強化触手」「触手の種」あたりで触手を伸ばし、範囲と攻撃力を上げる装備をつければ簡単に完成する。雑につええ。どうしてこうなった。

とりあえず、タイタンとのシナジーがわかりやすいので絶対入れたほうがいい。難しい以上なら、最初に出てくるまで待ってもいい気がする。(強い以上の理由として、シナジーを意識して遊ぶのは面白いから)

複数の bool 値と byte 値を相互に変換する

DB を設計していると、ひとつの列で bool 値をまとめてしまおうという発想をすることがある。ほとんどのケースで、これは設計ミス(アンチパターン)となりやすいことで知られ、jaywalking(信号無視)パターンと言います。

どうして jaywalking パターンは、悪いのか。

カラムに文字数制限があれば(わかりづらい)上限になること、格納されるカラム名が無いから仕様書がないと情報が減ること(=誤ったデータを挿入して運用を進めると困ったことになる)……色々考えられると思います。

なので、本当だったらあんまり使いたくない。でも、既存 DB で使われている場合や、参照の少ない履歴を管理するテーブルで(僅かな)容量削減を目的に利用されてたりする。さて、どうしよう。

リファクタリングするにしても、リファクタリングをする価値のないデータやプロジェクトであるなら、そこに時間を投資しても困る。したくない。残念ながら、(体力だったり、政治だったりを含め)色々な理由でやむを得ないケースはある。

そんなわけで、DB 上に存在することを想定した byte (int) 型のデータを複数の bool 値に変換したり、その逆をしたりするサンプルです。

byte to bool[8]

private bool[] ToBools(byte data)
{
    var bools = new bool[8];

    for (int i = 0; i < 8; i++)
    {
        bools[i] = (data & (1 << i)) != 0;
    }

    Array.Reverse(bools);

    return bools;
}

bool[8] to byte

private byte ToByte(bool[] sources)
{
    byte result = 0x00;
    int index = 8 - sources.Length;

    if (sources.Length <= 0)
    {
        return result;
    }

    foreach (var source in sources)
    {
        if (source)
        {
            result |= (byte)(1 << (7 - index));
        }

        index++;
    }

    return result;
}

サンプル

WPF の binding を利用するとこんな感じになると思います。IsEnabled1 ~ IsEnabled8 は、8つのチェックボックス IsChecked プロパティにそれぞれ対応。

public byte Result
{
    get
    {
        var bools = new bool[8];

        bools[0] = IsEnabled1;
        bools[1] = IsEnabled2;
        bools[2] = IsEnabled3;
        bools[3] = IsEnabled4;
        bools[4] = IsEnabled5;
        bools[5] = IsEnabled6;
        bools[6] = IsEnabled7;
        bools[7] = IsEnabled8;

        return ToByte(bools);
    }
    set
    {
        var bools = ToBools(value);

        IsEnabled1 = bools[0];
        IsEnabled2 = bools[1];
        IsEnabled3 = bools[2];
        IsEnabled4 = bools[3];
        IsEnabled5 = bools[4];
        IsEnabled6 = bools[5];
        IsEnabled7 = bools[6];
        IsEnabled8 = bools[7];
    }
}

これも当然ながら、jaywalking パターンらしい欠点を持つ byte 型を格納することになる。

参考

Windows11 右クリックメニューを元の (Windows 10 相当) に戻す方法

Windows 11 に変更すると、右クリックメニューの内容が windows 11 のものになって、サードパーティが追加したメニュー項目が表示されなくなってしまった。

「その他のオプションを表示」とすれば旧メニューも表示できるけど、面倒くさい。まだ(業務用として)新しいメニューは使いづらいと思うので前メニューを継続したい。

対応方法

Windows ボタンを右クリックして、Windows ターミナル(管理者)を開きます。

以下のコマンドを実行します。レジストリを編集するので、登録/解除の実行後は OS の再起動が必須です。

登録時:

reg.exe add “HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32” /f /ve

解除時:

reg.exe delete “HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}” /f

これでデフォルトの右クリックメニューが Windows10 と同じ状態になったと思います。

右クリックメニューのカスタマイズ

新しい右クリックメニューを旧来の右クリックメニューに戻すと、今度は右クリックメニューに不要なメニューがたくさんあることに気づく。ほとんど使わないメニュー項目は消し込んでしまっていいと思います。

「送る」の内容を編集

Win+R を押して「ファイル名を指定して実行」を表示し以下のコマンドを実行。

  • shell:sendto

「新規作成」の内容を編集

右クリックメニューの編集

レジストリを編集すればよいが、わかりづらくて怖いのでツールを利用する。

WinRAR のように個別に「オプション」から設定したほうがよいこともある。

結論として、結構めんどくさい。そのうえ、なにかをインストールするとまたメンテナンスする必要が生まれる恐れもある。利用率が極端に低いメニューだけ調整しておく。

参考

GitHub に間違って API キーをコミットしてしまったときの対応

GitHubAPI キーを間違ってコミットしてしまったら。

Git (GitHub) はコードを遡って調べることができる反面、API キーのような情報を修正しようとすると、遡って記録を訂正しなければいけません。思ったよりも面倒な手順で、今のところボタン一つで解決……とはいきません。

問題の記録を確認する

まず、削除したい情報を確認します。

git log --all --name-status --pretty=short --graph -- 削除するファイル/ディレクトリパス

このとき、コミット ID を取得することが可能です。これは重要な情報なので、メモします。あとで、コミット ID を checkout してコミット履歴が復元できるかどうかをチェックしましょう。

git checkout コミットID

対応方法

コマンドを使って対応を進めるので、Git Bash でも Visual Studio Code でもいいので、すぐにコマンドを打てる環境を構築しておくようにしましょう。Visual Studio で普段の commit 等の操作をしていると、Git とフレンドリーな CUI 環境を構築し忘れていたりします。注意。

git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch 削除するファイル' HEAD
git filter-branch --force --index-filter 'git rm -rf --cached --ignore-unmatch 削除するディレクトリーパス' HEAD
or
git filter-branch --force --tree-filter 'rm --cached --ignore-unmatch 削除するファイル/ディレクトリパス' HEAD
git filter-branch --force --tree-filter 'rm -rf --cached --ignore-unmatch 削除するファイル/ディレクトリパス' HEAD

filter-branch の命令で Git に記録している情報の歴史を書き換えます。

書き換えのオプションが --index-filter です。--tree-filter という似ているオプションもあります。index-filter はローカルリポジトリの index 上で書き換えて、tree-filter はローカルリポジトリのファイルを working tree に checkout してから書き換えます。

反映

filter-branch のコマンドは GitHub上のデータを直接編集するわけではないので、最後に push が必要です。

git push --all --force origin

// 問題がないことを確認して後日実行
git reflog expire --expire-unreachable=now --all
git gc --prune=now

なお、削除したファイルはもう実体を取得できませんが、その記録(ファイルが存在したことがわかる)だけは残っています。この削除はもう少し複雑です。

参考