2022-06: 第十四工房

Mathematica 4.2 を Wine / lubuntu で ― 2022年06月07日 18:13

いいかげん、WindowsXPから脱却しようと、古いバージョンのMathematica(4.2)を、lubuntu上のWineに移す。版が古いのでWindows10では動かない。

この作業自体はあっさり。日本語入力できるようにと、uim + Mozc の設定を試みたが、こちらは実現せず。Linux上のテキストエディタで日本語入力できるからよいか。Linux使いは凝りすぎないのが、うまく付き合うコツ。

Mathematicaは、2.2→3.0→4.2 と上げてきて、都合50万円ほどかかっている。今なら、個人用途の版もあって、見たところ5万円くらいなので、新しいのを買った方がお得なのはわかっているけれど、もう少し元を取ってからでないと、と踏み切れない。

Vita Craft 鍋で低温調理 ― 2022年06月20日 15:36

夏場は暑いので、つきっきりで調理しなくて済む低温調理器でも購入しようかと考えたところ、普段使いの鍋の保温力が高いことを思い出して実験。

鍋は、Vita CraftのNoeva2000。少し前の型だが、ちょっとお高めだったことは覚えている。

・お湯3リットル。85℃まで加熱して火を止める。

・鳥の胸肉を2枚、ジップロック的な密封袋に入れて投入。

・30分経過；湯温71℃。

・45分経過；湯温68℃。

・60分経過；湯温66℃。

60分で取り出して、肉の内部温度を測る。64℃。安全には少し足りないか。

皮目に焦げ目を付けるため、取り出してオーブンで10分ほど。余熱調理の分も含めて、これならば問題あるまい。オーブンの使用時間は半減できたけど、時間を掛けた分、食味はよいことに期待。この結果なら、牛肉のステーキ用なら十分火が入りそう。

以上、精密な低温調理をめざすのでなければ、手持ちの機材でもなんとかなりそう。専用の調理器はまたの機会に。

QNAP 332X QTier - SSD 1TB 追加 ― 2022年06月21日 10:24

円安で輸入品に頼るPCパーツが2～3割値上がりしそうなのと、SATAのSSDが製品としてそろそろ終息しそうな気配がするので、ここらでNASにSSDを追加して、QTier(QNAPの階層型ストレージ)を構築してみる。

SSDを2枚装着した後、「ストレージ＆スナップショット」を開く。ストレージプールを選んで、右クリックから「管理」を選択。

QTierを未構成なら、「管理」か「アクション」あたりに「QTierプールへのアップグレード」の項目があるはず。

ウィザードが起動するので、追加したSSDを2つ選択して、先に進む。ミラーなど可用性の高い構成を組まないとQTierは導入させてもらえない。

アップグレード中。ストレージプールの容量は、SSD分、増えている。

完了したら、次に階層化対象の設定。新しく増えた「QTier自動階層」のメニューから「オンデマンド階層化」を選択。ここで、iSCSIのボリュームを対象に含むかどうかを設定できる。

細かな共有フォルダ単位の設定は、「FileStation」から。フォルダを選んで、設定。たまに読み取りでアクセスする程度の、VMのバックアップや、映像のアーカイブなどは外しておく。

一週間弱使ってみたところ。追加したSSDは、ESXiのバックアップ先になっているiSCSIボリュームへの書き込みもあってそれなりの使用率。

統計メニューから、「超高速」。翻訳がわかりにくいが、SSDの使用状況。日々、アクセス頻度の低いデータがディスクに書き戻されている。新規データの書き込みはSSDに行われ、次第にディスクに書き戻される流れ。

統計メニューから、「容量」。こちら容量重視のデバイスの趣旨で、SATAディスクの使用状況。日々、1～2GB程度、SSD側に移されている。おそらく、新規に読み込まれたFLACデータあたり。

この感じだと、事務作業中心ではSSD容量は1TBも必要ない。書き込みはSSD優先に行われるので、画像や動画など大きなデータを頻繁に扱うなら、それにあわせた容量を用意すれば、使い勝手はずいぶん向上するはず。iSCSIボリュームも対象にできるので、ESXiなどのVMの一時置き場としても重宝できそう。

そして、二週間ほど経過。最初の頃に操作した動画データ、アクセスが継続しないとみて、SSDから書き戻されている。SSD側に継続して保存されるには、二週間以内に読み書きされるほどのアクセス頻度が必要のよう。

Azure DevOpsのプロジェクトでVSTSからGitへの切替 ― 2022年06月23日 18:15

VisualStudioを用いた開発において、Azure DevOpsでソース管理をするとき、最近はGitを標準で勧めてくる。そこで、これまでVSTS(Visual Studio Team Foundation Services)で管理してきたソリューションについて、Gitへの切替を試みる。

最初に、Azure DevOpsでバージョン管理をGitに設定した空のプロジェクトを作成する。

ユーザ名とパスワードを保存し、リポジトリの場所を記録する。

VisualStudioを起動し、切替対象のソリューションを開く。オプションの「ソース管理」で、ソース管理プラグインを「Git」に設定する。

Gitグローバル設定を確認。ここでは、既定の場所を変更している。

Gitリポジトリ設定の「全般」を確認。

Gitリポジトリ設定の「リモート」で、先にAzure DevOpsで記録したリポジトリの場所を転記する。

ローカルにGitのリポジトリを作成。先に、Azure DevOpsでプロジェクトを作成しているので、「既存のリモート」を選択して、「リモートURL」を設定。

これで「Git変更」のパネルから、ローカルのソースのPushができるか、確認。

ソース管理プラグインはソリューション単位の設定であり、別のVSTSを用いているソリューションを開けば、これまで通り、VSTSのソース管理が動作する。VisualStudioの共通の設定として保存されるわけではない。

切替によりGitならではの制御が可能になるが、VSTSで不都合を感じてなければ敢えて移行する必要はない感じ。なお、Gitに切替てもAzure DevOpsのBoardsなどのサービス類は変わらず利用できる。新規作成なので空からのスタートになるけど。

ひとついいことがあった。

Gitに切り替えておくと、ローカルで運用しているGitHub互換のリポジトリに複写ができるようになる。remoteのリポジトリをAzure DevOpsとは別にローカル用に登録し、TortoiseGitなどのクライアントツールでPush時に選択すれば、複写を生成できる。VSTSの場合、「.git」のGit環境フォルダがあると、ソース管理プラグインをGitと認識するので、複数のリポジトリを選択して運用することができない。これを回避できる。