DeskMiniA300出るんだってさ。
その筋（どの筋？）で有名なASRockからMini-STXベースのベアボーンの最新作DeskMini A300出るんだってさ。
DeskMini A300(以下A300)にRyzen 5 2400G突っ込めば4Core8ThreadのPCがお安く構築できる。
なんだが、現在私はDeskMini 110(以下110)+Corei3-7100のPCを所有している。CPUをi7-7700に換装しても4Core8ThreadのPCができあがる。
というわけで、比較をしてみた。
110を延命するほうがA300で新築するよりも半値ぐらいでいけるのである。
これは悩みどこｒ・・・・
な・わ・け・な・い
新築するに決まってる。Ryzenだよ。あの４歳牝馬特別で杉本清を絶句させた末脚（それはライデンリーダー）
というわけで月末に向けてRyzen貯金をしよう。
ClosedXMLで数式を設定したみたけど動かないことがあったのさ
ようよう調べたら環境の問題やろなと。
条件：ターゲットとなるファイルはネットワークドライブに置いてある。
・ターゲットファイルにClosedXMLで数式を設定する
・↑の時点では数式は実行されない
∵ClosedXMLはファイルの中身をいじるだけで計算の機能はないはず
・ターゲットファイルを開くも保護ビューのため数式は実行されない
保護ビューを解除するかターゲットファイルをローカルにコピーしてから開けばきちんと数式が実行されました。めでたしめでたし。
UMACA時代の馬券の買い方
怪しげな予想の話ではございません。買い目は自分で決めましょう。
それはさておき、阪神競馬場にてUMACA投票が始まりました。
これまで競馬場にて馬券を買うとなったら
①マークカード書いて券売機に銭といっしょにつっこむ
②有人窓口に銭もって買い目を連呼する（非推奨）
の２通りしかありませんでした。
（スマホでPAT使って買うなんてのもありますがそれはちょっと横に置いておこう）
んが、これにUMACA投票が加わることになります。馬券買うには当然に銭が必要です。これはUMACAというICカードに事前にチャージしておくとして、買い目の指定方法にバリエーションがあります。馬券の購入（UMACA）：はじめての方へ JRA
大原則として、UMACA投票機を使うにあたっては
・UMACAタッチ＆本人認証（静脈or暗証番号）
・買い目指定
・UMACAタッチ
の手順で馬券を買うことになります。
で、買い目の指定方法のバリエーションは以下の通り
(1) マークカードを書いてUMACA投票機につっこむ
(2) スマホ上でQRコードを作成してUMACA投票機でスキャン
(3) UMAポートにてQRコードを作成して印刷したレシートをUMACA投票機でスキャン
(4) UMACA投票機でタッチパネル入力
各々ちょっと解説。
(1)はこれまでの競馬ファンおなじみ。支払方法がUMACAのチャージに代わるだけのこと。
(2)はスマッピー投票 JRAにて作成したスマホ画面上のQRコードをUMACA投票機に見せる。UMACAカードタッチ→スマホ画面提示→UMACAカードタッチという手順になるので、UMACAとスマホの持ち替えが発生する。
(3)は(2)のスマホ画面の代わりにレシート。UMACAとレシートなら片手で持てるので扱いは楽。
(4)は銀行のATMみたいな感じ。簡単操作だが点数が多いと投票機を占拠する時間が長くなる。大レース時には行列のプレッシャーが。
個人的な使い分けとして
・UMAポートが空いていたら(3)
・UMACA投票機が空いていたら(4)
・筆記具を確保できていたら(1)
・スマホを忘れなければ(2)
・UMACAカードを忘れたら①
ということになるでしょう。
（書き足し）
UMAポートでのQRコードはスマッピー投票と同じなのだが、回線の関係で我がスマホよりは操作は軽い。単勝や複勝なららくちん。しかしそれ以外は２頭以上かつ複数の指定（ボックス・流し・フォーメーションのいずれかの場合）が必要となり、入力が多少めんどくさいと感じた。落ち着いて買えるならUMAポートかUMACA使うが締切間近だとマークカード使うことになりそう。
（もういっこ。）
UMACAの本人認証に静脈認証を使う人は投票後には手を洗った方がいいんじゃないかと。
いかに弊現場のコードがむごたらしいのか数値化してみたい
VisualStudioにコードメトリックスを計算してくれる機能があるので、弊現場のコードにてつこうてみた。
結果。（当然フェイク入れまくりだが）
スコープの”メンバー"は分析の最小単位らしい。ざっくりいうとメソッドだろうか。
保守容易性指数てのは、まんま「保守」しやすさを示す値。算出方法はマイクロソフトさんに聞いてください。
サイクロマティック複雑度の詳しい説明はwikipediaさんにまかせる。循環的複雑度 - Wikipedia
で、
弊現場のコードの場合、
・保守容易性指数は一桁のオンパレード
・サイクロマティック複雑度に三桁がずらり
うん、これはひどそうな気がしてきた。
現在解読中のメソッドについてサイクロマティック複雑度をみたら61であった。コード見ただけでもかなり複雑なのはわかるし、テストを整備してリファクタリングをやろうとしたら相当の手間になるだろうとは覚悟したのだが、まだまだ上には上があることを知って茫然としている。
これは折れる。というか、もう折れてる。
いっぺんにやるのしんどひ
おいらはソフトウェアの機能追加を担っています。
弊現場では年に２度程度のリリースをおこなっていて、その手順はざっくりいうと
①改修要求の一覧表を作る
②改修要求の一覧表にそって改修手順を決める
③改修の実施
④テストの実施
たぶんどこにでもあるやり方だと思うのですが、この①の表が結構なボリュームになることがあります。改修要求が多いと、改修前アプリとの関係のみならず改修要求間の整合性を保つことも必要になってきます。
（↓青線のみならず赤線のところもケアする必要が）
おいらみたく脳の容量がトリ以下な生き物にはこれがきつい。全部の要求がきっちり頭に入らないと整合性を取るにはどうすればよかとね？という考えにはなってこない。
脳の容量を強化してくれるカードリッジは売ってませんかね？
