PS> $list = @("hoge","fuga_fuga","piyo_piyo_piyo")
PS> $list |
PS> %{ [RegEx]::Replace($_, "^([a-zA-Z])", { $args.groups[1].value.ToUpper() }) } |
PS> %{ [RegEx]::Replace($_, "(_)([a-zA-Z])", { $args.groups[2].value.ToUpper() }) }
Hoge
FugaFuga
PiyoPiyoPiyo
PS> $list = @("Hoge","FugaFuga","piyoPiyoPiyo")
PS> $list |
PS> %{ [RegEx]::Replace($_, "^([A-Z])", { $args.groups[1].value.ToLower() }) } |
PS> %{ [RegEx]::Replace($_, "([a-z])([A-Z])", { $args.groups[1].value + "_" + $args.groups[2].value.ToLower() }) }
hoge
fuga_fuga
piyo_piyo_piyo
Rabi-Ribi ラビリビ
クリア。
難易度ノーマルでPostGameストーリークリアまで。
基本的にメトロイドヴァニアだが、ボス戦が非常に多いのが特徴。総勢24人のキャラクターがいて、複数回戦うこともあるので30戦以上はある。
ボス戦は弾幕シューティングのような攻撃をされ、ちょうど即死でない「アイワナ」のボス戦のようなシステムになっている。弾幕は多彩で激しいが、たいていはパターンを把握していける理不尽なものにはなっている。ただしHP制というのと時間回復する無敵手段がある前提で、絶対避けられないパターンの攻撃が来ることもたまとある。
前述のようにボス戦に大きなウエイトがあるゲームだが、探索部分も決してオマケにはなっておらず、アイテムを探しがいのある構成になっており、踏破するのに歯ごたえのある難所もある。
基本的な難易度は高めだが作りは丁寧でカジュアル難易度もちゃんと用意されており、さらに高難易度を望む人にはHARDの上にHELL(地獄)やそれ以上の難易度があるという万人におすすめできるゲーム。
ただ会話は多いのにストーリーはえらく分かりづらい。あえて核心を隠している部分はともかく、当面の目標すらなんのためにこなしているか分からないというのはどうなんだ。
あとはメニュー操作時にキャンセル操作をするためのボタンにゲージ消費攻撃が割当てられており、メニューを閉じようとして何度も暴発させてしまっていたのにはちょっと困った。
またテレポート先を選択するときのメニュー位置がどういう順で並んでるのか理解できないのが地味に不便。
パイプラインチェーン
https://dev.classmethod.jp/articles/powershell-7-pipeline-chain-operator/
bashなどのシェルで利用する構文で、前のコマンドが成功したときのみ次のコマンドを実行する、逆に前のコマンドが失敗したときのみ次のコマンドを実行するといったことを記述するためのもの。
C言語系プログラム言語の、「&&」や「||」を使った短絡評価と同じ挙動をする。
command_a && command_b # command_a が成功したときのみcommand_bが実行される command_a || command_b # command_a が成功するとcommand_bは実行されない
「パイプライン」チェーンという名前が付いているが、1番目のコマンドの結果はパイプラインで2番目のコマンドに『渡されない』。
PowerShellではPowerShell7以降で使える。しかし、コマンドがエラーコードというシンプルなint型値を戻す他のシェル環境と違って、PowerShellのコマンドレットは結果がオブジェクトでシステムエラーがthrowされる場合もあるので、期待する結果が得られない場合もある。
複数のXPSファイルを統合する方法
https://docs.microsoft.com/ja-jp/previous-versions/dotnet/netframework-3.5/aa972171(v=vs.90)?redirectedfrom=MSDN
https://docs.microsoft.com/ja-jp/dotnet/api/system.windows.xps.packaging.xpsdocument?view=netcore-3.1
dotNetのSystem.Windows.Xps.Packaging名前空間のXpsDocumentクラスなどを使えばできる。
上URLのサンプルプログラムで統合ができる。
(ただし実行ファイルは付いていないので、自分でビルドしなければならない)
gitのstage領域なんて不要だと思ってたが、やはり必要だった
いままでgitのstaging領域(index)は無駄に概念を複雑にしているだけで、コミット時にコミットに含めるファイルを選択するだけでいいじゃないかと考えていたが、TortoiseGitで実際に「stage領域が無いgit」相当の操作をしてみると、やはり必要だと判った。
具体的にはamendコミット時に、前回コミットで修正されたファイルを作業コピーでも修正していた（それプラスまったく関係ないファイルの修正もammendに含めたい）場合に
・前回コミットの修正は含める
・作業コピーの修正は含めない
というコミットを行いたい時、stage領域が無いとそれが行えない。
stage領域を使う方式だと
・stage領域に前回コミットの修正は含める（何もしなくても最初から含まれている）
・stage領域に作業コピーの修正は含めない（git add しない）
として状態を表現して、コミットが行える。
コミット時にコミットに含めるファイルを選択する方式だと、
・コミットに含めると現在の作業コピーの状態が前回コミットに上書きされてしまう
・コミットに含めないと前回コミット内容からそのファイルが消えてしまう
という問題が起きてしまう。