2022-11-20

色んなリソースを github に移せたのでブログも github で対応する

 ので、このブログは終了。

 個人的に必要な記事だけ github 側に寄せる予定。 バイバイ 

2022/12 

移行しました → https://sk-0520.github.io/blog/

2020-05-31

バックアップに Nextcloud クライアントと B2 Cloud Storage を使うのはやめた方がいいかも

サーバー側の Nextcloud と B2 Cloud Storage を合わせるのは多分問題ないと思う。
問題なのは Windows 側に入れる Nextcloud クライアントで、こいつの挙動がもうマジ謎すぎる。

少量のファイルで試している間は何ともなかったけど、
B2 側にドーンともの入れるとなんかもう同期を頑張りすぎてチェックしまくるわなんやでやたら遅い。
Explorer を透過的に扱えるのでまぁいいかと思っていたがさらに面倒な問題があって B2 上にすでにアップロードしたファイルを取得しようとするのがもうマジむり。
初回バックアップなので通信回数も多くなるのはしゃあなしでアップロードのため API のキャパ増やしたりはまぁ許容できる。
できるんだけどなんでダウンロードのキャパ増やす必要があるのかと。
いやー、これはちょっとしんどい。GB データをダウンロードしだしたときに諦めた。

ただ B2 連携せずサーバー上に直接ファイル送ったりする連携はなかなかきれいに動いてくれたので恐らく外部ストレージの扱いがうまくないんだと思う。
重ねて恐らくだけどサーバー側 Nextcloud は外部ストレージをうまく扱えてて、Nextcloud クライアントがサーバー側ストレージ情報を知らずに処理しちゃってる感がすごい。

なので今のところの運用はでっかいバックアップ分は rclone で B2 に飛ばす、
ちょっと頻繁っぽいデータは Nextcloud クライアントから サーバー側 Nextcloud のディレクトリに飛ばすようにした。

あれこれテストしまくったっていうのもあるけどここ1日で $1 は使ったよ。疲れたよ。

2020-05-30

バックアップ体制を Nextcloud と B2 Cloud Storage で構築した

先週メイン使用のデスクトップが死んでついでにデータ用のHDDがすべて死んだ悲しみを繰り返さないためにバックアップ体制を構築した(というかデータが主に悲しみの原因)。
まず OS の載っているストレージについては正直どうでもいいのでバックアップはできたらいいな程度に考え、データ用のストレージ冗長化を主眼に置いた。

手っ取り早くは NAS 買ってきてそこにデータ突っ込むというのが無難だと思ったけど電源つけっぱなしは精神的にしんどいし毎回電源ON/OFFするのも気持ちしんどい。
なので外部(インターネット越し)に配置したいと思ったが選択肢が多くてあれやこれや考えた結果、B2 Cloud Storage を選んだ。

B2 Cloud 自体はブラウザで開いてアップロードしたりできるがどうにも面倒なので Windows Explorer 上の OneDrive みたいに透過的に扱いたかったのでクライアントソフトを探したが
よくわからん + データ喪失の悲しみであんまりやる気ない状態だったので手っ取り早そうな Nextcloud クライアントソフトを使用することにした。
B2 Cloud は S3 互換の API を扱えるので S3 を扱える Nextcloud(サーバー側) にストレージ整理を任せて、Nextcloud クライアント側に Windows との連携を任せることにした。

B2 Cloud Storage を使用/ストレージの作成

まずは https://www.backblaze.com/b2/cloud-storage.html にアクセスしてアカウントを作成する。

B2 Cloud Storage (以下 B2) はカード情報がなくても 10 GB まで保存できるので動作確認・使用感を得るには都合がよい。なによりカード入力しなくても試せる安心感がすごい。

サインインしたら Nextcloud とやり取りさせるために設定を行っていく。
  1. [メニュー] Bucket
    1. Create a Bucket
      1. バケット名は適当に入力(入れるデータに合わせた名前)
      2. 公開範囲も適当に設定(バックアップの意味合いから private が普通だと思う)
  2. [メニュー] App Keys
    1. Add a New Application Key
      1. キー名を適当に入力
      2. 対象バケットの選択で API キーを制限しないなら ALL 、バケットごとに制限するなら対象を選択
      3. アクセス権限を All に設定
      4. その他オプションは必要な入力
      5. 出来上がった API キー の Secret をメモっておく
これで B2 の準備は完了。

Nextcloud のインストール

すでに使用可能な Nextcloud が存在すればこれは不要。

ここでは Nginx の稼働している CentOS8 を対象として、 snap を用いる。
Nextcloud 自体を直接動かしたいなら止めはしないけどやりたいのはバックアップであって Nextcloud の世話ではないので保守は snap に任せる。

# dnf install snapd -y
# systemctl start snapd
# snap install nextcloud
Warning: /var/lib/snapd/snap/bin was not found in your $PATH. If you've not restarted your session
         since you installed snapd, try doing that. Please see https://forum.snapcraft.io/t/9469
         for more details.

これでインストールは完了。
ただこの時点ではまだ起動していないし、PATH に追加された内容も反映されていないのでいったんログアウトするなりして PATH を最新化する。

次に Nginx のリバースプロキシ設定を行う。
適当なディレクティブに適当に設定値を入力。

http {
...
# アップロードサイズの変更
client_max_body_size 5g;

...

server {
...
# リバースプロキシとして動作させる
location /<NextcloudのURLパス> {
rewrite ^/<NextcloudのURLパス>(.*) $1 break;
proxy_pass http://<Nextcloud稼働IPアドレス>:<Nextcloudのポート>;
}
...
}
}

# systemctl reload nginx

これで Nginx 側の設定ができたので Nextcloud を構築していく。

# snap set nextcloud ports.http=<Nextcloudのポート>
# nextcloud.manual-install <ログインユーザー名> <ログインパスワード>
# nextcloud.occ config:system:set trusted_domains 1 --value=<リバースプロキシホスト>
# nextcloud.occ config:system:set overwritehost --value="<リバースプロキシホスト>"
# nextcloud.occ config:system:set overwriteprotocol --value="<リバースプロキシプロトコル>"   ※ http / https のどっちか
# nextcloud.occ config:system:set overwritewebroot --value="/<NextcloudのURLパス>"
# nextcloud.occ config:system:set overwrite.cli.url --value="<稼働プロトコル>://<リバースプロキシホスト>/<NextcloudのURLパス>"

これで設定OKなので <稼働プロトコル>://<リバースプロキシホスト>/<NextcloudのURLパス> にアクセスする。
※起動してなかったら起動しておくこと (多分 -> # snap start nextcloud )
※同一ホスト内だと selinux 周りで死ぬかも(一応の対応 -> # setsebool httpd_can_network_connect on -P )

Nextcloud の設定

  1. とりまログインしたら右上のアバターアイコンから アプリを選択
    1. 「External storage support」を検索して有効にする
  2. 右上のアバターアイコンから 設定 を選択
    1. 左メニュー 管理欄 の「外部ストレージ」
      1. 「フォルダー名」を適当に入力
      2. 「ストレージを追加」から「Amazon S3」を選択
      3. 「バケット名」に作成したバケット名を入力
      4. 「ホスト名」にバケットのEndpointを入力
      5. 「ポート」は空白
      6. リージョンに バケットのEndpoint のリージョンっぽいのを設定
        • s3.us-west-002.backblazeb2.com なら us-west-002
        • 作業中にどこかのページで見て知ったけどURL失念
      7. 「SSLを有効」をチェック
      8. 「パス形式を有効」をチェック(なんのこっちゃ知らん)
      9. 「レガシー認証(v2)」は非チェック
      10. 「アクセスキー」に作成した API キーの「keyID」を入力
      11. 「シークレットキー」に作成した API キーのメモしておいた Secret を入力
      12. ✔ をクリック

構築完了

これで Nextcloud と B2 を連携が完了する。
あとは Nextcloud クライアントを PC にインストールして連携すればOK。


  • B2 を使えば無料+カード情報なし(電話番号は必要)で 10 GB まで扱える
    • API 使用に関してもある程度まで同じ
  • 10 GBを超えたい、API使用数を増やしたいと思うまで無料運用可能
  • B2 連携した場合 Nextcloud 上にファイルは格納されない(一時ファイルは知らん)
  • 良い点
    • 意外と速度が速かった
    • Nextcloud クライアントアプリがアップロード失敗時に自動リトライ処理してくれる
    • Nextcloud クライアントアプリがリネームも検知してくれる
      • B2 側にも一応対応してくれてるっぽいけど遅い(?)
  • 悪い点
    • B2 提供サイト backblaze は右下で言語変えれられるけど機械翻訳で完全に何言ってるのかわからないサイトになるので素直に英語表示した方がいい

  • まだ分かってないところ
    • クライアント側未ダウンロードでアイコン表示が可能か
      • 絶対ダウンロードされる? 試してないから知らんけど
    • Nextcloud による API 使用料がちょっとまだ読めない
      • 時間がたてばどれくらいっていう目測ができるようになると思うけど導入したばっかなのできつい



2020-05-24

とりあえずメインPCを買った

一旦デスクトップPCを買うことにした。というか買った。
多分今回買ったPCがデスクトップ端末としては最後になると思う。

旧端末はOSがSSDで、それ以外のデータがHDDに入っていたけどなんかHDDも全滅してるっぽくて心折れまくる。
リカバリソフトでデータ見れたから頑張れば復旧できそうな気がしないでもないけど稼働してるノートPCのストレージが500GBしかないから新端末が来たら復元試してみる。

ここ最近NASとかクラウドストレージでデータ管理していこうかなーと思っていたんだけどその矢先にこれはきっつい。

メインパソコンこわれる

ブート領域が壊れたっぽい。

もろもろ手順を試したがダメっぽかったので再インストール中。
この記事はノートPCで書いてるけど、なんかデスクトップでどうこうするのも疲れてきた感ある。

修復の可・不可によらずそろそろメイン端末を買い替えたいと思ってたところではあるし手持ちの機器類を整理しておきたい。

前にも壊れてるし、四年そこらが耐久限界なんかね。五年くらいはいけると思ってたけどなー。

2020-02-29

Pe 0.87.001

致命的にバグってたので緊急リリース。
コマンドライン引数が設定されていない場合に ps1 実行で死んでいた。

しんどい。

2020-02-26

PowerShell AA Pe 0.86.0 版

こーいう配列があって、
9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, -1
9, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, -1
9, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, -1
9, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, -1
9, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, -1
9, 1, 0, 1, 1, 1, 0, 0, 0, 0, 0, 1, 9, 2, 9, 2, 9, 2, 2, 2, 9, 2, 2, 9, 9, 9, 2, 9, 9, 2, 2, 2, 9, 2, 2, 2, -1
9, 1, 0, 1, 0, 1, 0, 0, 0, 0, 0, 1, 9, 2, 9, 2, 9, 2, 3, 2, 9, 2, 3, 2, 9, 2, 3, 2, 9, 3, 2, 3, 9, 2, 3, 3, -1
9, 1, 0, 1, 0, 1, 0, 1, 1, 1, 0, 1, 9, 2, 9, 2, 9, 2, 9, 2, 9, 2, 9, 2, 9, 2, 9, 2, 9, 9, 2, 9, 9, 2, 9, 9, -1
9, 1, 0, 1, 1, 1, 0, 1, 0, 1, 0, 1, 9, 2, 9, 2, 9, 2, 2, 2, 9, 2, 9, 2, 9, 2, 9, 2, 9, 9, 2, 9, 9, 2, 2, 2, -1
9, 1, 0, 1, 0, 0, 0, 1, 1, 1, 0, 1, 9, 2, 9, 2, 9, 2, 3, 3, 9, 2, 9, 2, 9, 2, 2, 2, 9, 9, 2, 9, 9, 2, 3, 3, -1
9, 1, 0, 1, 0, 0, 0, 1, 0, 0, 0, 1, 9, 2, 9, 2, 9, 2, 9, 9, 9, 2, 9, 2, 9, 2, 3, 2, 9, 9, 2, 9, 9, 2, 9, 9, -1
9, 1, 0, 1, 0, 0, 0, 1, 1, 1, 0, 1, 9, 2, 2, 2, 9, 2, 9, 9, 9, 2, 2, 3, 9, 2, 9, 2, 9, 9, 2, 9, 9, 2, 2, 2, -1
9, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 9, 3, 3, 3, 9, 3, 9, 9, 9, 3, 3, 9, 9, 3, 9, 3, 9, 9, 3, 9, 9, 3, 3, 3, -1
9, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, -1
9, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, -1
9, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, -1
9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, -1
こー言う処理に食わせて
foreach ($dot in $appIcon) {
    switch ($dot) {
        0 { Write-Host '   ' -NoNewline -ForegroundColor White -BackgroundColor White }
        1 { Write-Host '|||' -NoNewline -ForegroundColor Black -BackgroundColor Black }
        2 { Write-Host '===' -NoNewline -ForegroundColor Red -BackgroundColor Red }
        3 { Write-Host '---' -NoNewline -ForegroundColor DarkRed -BackgroundColor DarkRed }
        9 { Write-Host '   ' -NoNewline }
        -1 { Write-Host '' }
    }
}
こーなる











こういう実装中の暇つぶしは好きです。。。

2020-02-25

Pe 0.84.0 リリースで分かったこと

  • まぁ動くだろ的なノリで適当にリリースするとやっぱ泣く
  • Nuget から落としてきたライブラリでも依存ライブラリがある
    • CefSharp が Microsoft Visual C++ 再頒布可能パッケージ が必要なのを完全に見落としていた
    • 見落としていたというかまっさら Win7 で動かなかったのを .NET Core のなんかだろと軽視していたツケ
    • VSで開発してるからライブラリあって当たり前でまったく気にならなかった
  • 自環境でダウンロード検証したが、帯域絞るなりしてみた方がよかった
    • 0.83.0付属のアップデート処理機能だと落としきる前にタイムアウトしてるっぽい
      • これに関してはもうどうしようもないが、リリースノートの差し替え差し替えでぐっだぐだ
  • もうまじ💩

2020-02-24

Pe 0.84.0 リリース!

Pe を .NET Framework から .NET Core に変更した。
以下文書は酔っぱらいながら書いてる🍶。

移行に当たり git log を確認すると諸々の流れはこんな感じ
  1. 2017/06/11 0.83.0 リリース
  2. 2018/11/19 バージョンアップに着手
  3. 2019/01/06 バージョンアップ諦め
  4. 2019/03/02 バージョンアップに再着手
  5. 2019/06/08 バージョンアップ再諦め
  6. 2019/08/20 バージョンアップに再々着手しつつ .NET Core に唾を付ける
  7. 2020/02/24 .NET Core にて 0.84.0 のリリース
まぁ色々あった。

.NET Framework から .NET Core への移行

まぁ気になる人はこれだと思う。
基本的には問題ない、と言いたいが対象ユーザー層との相談が必要になると思う。

サーバーサイドならなんも考える必要はないけどデスクトップ界隈ならば、
  • 対象端末に .NET Core ランタイムはあるか
  • ランタイムがないのであれば自己完結型で💩レベルに膨れ上がるバイナリを許容できるか
なのでこれを解決する必要がある。

Pe の場合、これは自己完結型でユーザー許可を取らずにぶち込んだ。
ただこれも見映えの話で、自己完結型だと DLL が山ほど出力されるのでユーザーがなんも考えず EXE を起動できる必要がある。
(ユーザー目線で見ると .NET Core 自己完結型の EXE 探してダブルクリックとか結構な無理がある)
Pe では自己完結型の出力先を <Pe>\bin\ にして必要な諸々を bin ディレクトリに委譲したうえでユーザー操作では <Pe>\Pe.exe (と互換性保持用の PeMain.exe)だけに限定した。
起動順序として Pe.exe -> bin\Pe.Main.exe となる。
せっかく .NET Core(C#) で作ってるのにこの起動アプリケーションを C で作るというなんかもう何してんのか分からないことになっているしコマンドライン引数の再受け渡しでさらに何してんのか分けわからんことになってる。
プログラマー様に渡すならどうでもいいけど配布プログラムになるとこうするのが妥協案として一番まともだと思う。

ちなみに UI 系のものはことごとく捨てた。
UI 系ライブラリの .NET Core 対応を待つのもバカっぽいのですてた。
※ .NET Framework 版の .NET Core 上での再使用はなんとなく嫌だったので除外
これに関しては現行(.NET Framework)版の UI 充実度に左右されると思うので .NET Framework ライブラリ を .NET Core 上で動かすのが最適解だと思う。

ていうかサーバー用途じゃなけりゃ .NET 5 になっても MS が互換レイヤー用意するだろうから Windows だと無理くり .NET Core 自己完結型 にする必要ないと思う。

ブラウザに関して .NET Core に移ってまで WebBrowser に心ポキポキ折られると心が持たないので CefSharp を入れたがこれもまたサイズがでっかい。
まぁ .NET Core 自己完結型の中だと誤差だよ、誤差。

リリースに関して

これもうアップデート処理が出来たからリリースしましたとしか言えない。

.NET Core だと 1 exe で MB 単位の EXE 出来上がるのでこれのためにアップデート用 EXE に切り分ける選択肢はなし、本体側で実行できないと💩状態。
.NET Framework でもそうだったけど、 EXE を殺すのはどうでもよくて依存 DLL があるとなんもできなくなるのでこれを実現するためにいろいろ考えた結果 Pe.exe(Pe.Main.exe) から powershell を呼び出して呼び出し先で渡された Pe の PID 終了を待つようにした。

正直一番ましな方法だと思ってる。
ちなみに pwsh を優先して、なければ powershell を呼び出すようにしてるから多分どこでも動く。
これに関しては bat でも何でもよかったけど、 win10 なら bat でも ps1 でもなんでも動くだろっていう安直な想い。

PowerShell

  • Pe の可動部分(アップデート周り)では PowerShell の命令に限定している。
  • ビルドスクリプトは .NET の処理使ったり好き勝手やってる。
ビルド環境(おおよそ CI 環境)は開発者側で何とでもなるのでどうでもいいが、
アップデート環境 = リリース版 = 知らない人 の環境なのでここで動くシェルスクリプトっぽくでコマンドプロンプトより高機能で bash よりどこでも動くとなるともう PowerShell しかないのでこれでやるのが現状最強だと思う(ver 5 だけに限定するなら特に)。

.NET Core(3) への移行について

  • .NET Framework から移行するのは簡単
    • ただし移行だけに専念して .NET Core にまつわるロジック変更以外は何もしない方がいいと思う
    • Pe の場合、組み直し中の .NET Core 移行だったのでかなりしんどかった
  • (非プログラマの)ユーザーがクッソ重いバイナリを許容してくれてクッソ多いファイルから EXE を見つけてくれるなら .NET Core に移行してもいいと思う。無理なら何かしら解決策を提示する必要はある
  • プログラム組む側の人間なら移行していいと思う。たのしい!
  • プログラム組まない人間であれば情シスが .NET Core って言って来たら工数を要件と確認した方がいいともう。さらに言えば 1.5 倍にした方が安全だと思う(はまると死ぬ)

結論

うちは好きにしたけど君はまぁ頑張れ。

2020/02/25 12:00 追記

0.83.0 -> 0.84.0 の自動アップデートがたぶんタイムアウトかなんかで無理な可能性あり。
俺んちではできたけど会社ではだめだった。
0.83.0 までは軽量だったから問題なかったんだろうね、手動だ手動。


2019-10-08

avastをアンインストールした

前々から誤検知が多すぎた。
昔は無料版で使って世話になったし有料版を3-4年使ったけどさっすがに誤検知がしんどくなってきた。
特に適当なプログラムを組んでデバッグ実行したらそのプログラムを検知するのがクソ鬱陶しい。

あとインターネットが追跡されてます!的なくっそどうでもいいポップアップが四六時中自己主張するのがアンインストールの引き金。

いままでありがとう さようなら avast こんにちは Windows Defender

2019-09-28

クイックデリバリー

クイックデリバリーかそれに準じるようなの欲しい。

もう仕事がんばらず駐車場生活したい。

2019-04-19

Visual Studio 2019 のタイトルバー

タイトルバーがメニューに統合されて個人的に非常に使いにくい問題。

これで解決したメモ → https://stackoverflow.com/questions/53636350/re-enable-title-bar-in-visual-studio-2019

設定にあるんかも知んないけど探しきれてない && stackoverflow 見た方が早かった。

2018-10-15

search-hook 0.2.0

PC で UA カチャカチャ変えて android firefox でも検索除外いけたのでリリースしたけど実機だと無理で笑ってしもうた。

あと pageAction のアイコン出ないんかね?
調べることいっぱいあるわぁ。

search-hook

検索時の除外ワードのアドオンを作った。

https://addons.mozilla.org/ja/firefox/addon/search-hook/

もともとを Hide Unwanted Results of Google Search 使ってたんだけど Fx のアドオン WE 化に伴い使えなくなったので作った。多分探せば同じようなんはあると思うけど探してないから知らん。

言語適用やら入力検証やら対応サイトの追加、外部データからのフィルタリングとかやることいっぱいあるけどとりあえず公開してみた。

2018-07-09

ひっさびさの MnMn

最近 eclipse で Java ばっかやってたから VS で C# が最強すぎて泣けた。

つーかもうきちんと設計して作り直すか放棄したい。
なんていうかコントローラ(VM)で全部やる書き捨て実装のノリがきつい。

2017-11-03

MnMn 簡易アップデート: 2017-11-03 10:27:25

チャンネルのコメント数取れてなかったのを修正した。
実装してから長らく使いもしなかった簡易アップデート処理を初めて使ってみた。

ちなみに公式の方は10月のリニューアル延期したんだってね。

ちなみに最近は MnMn 飽きたし .NET Core 2 ASP Mvc で遊んでいるのです。

2017-08-15

MnMn 0.82.0

地味にリリースした .NET Framework 4.7 対応版。

このバージョンはまだ自動アップデートせずに手動ダウンロードできる状態にしておいた。
週末くらいに自動アップデート対象にする。

MnMn 0.81.0, 0.81.1

最近緊急リリースが多いというかリリース後に不具合発覚が頻発してる。
検知自体はクラッシュレポートもらえるから早いうちに対応できるけどかなんなぁ。

この状態であれこれ機能実装・修正するのもリスクあるし次の 0.82.0 は .NET 4.7 に移行するだけに留めたい。

2017-08-08

NUnit から MsTest への切り替えはユニットテストが意味的に機能しない

現実的じゃない。
端的に TestCase と同じ動きのコード追加がもうすでにテスト漏れになるからやめた方がいいよ。

2017-08-05

MnMn 0.78.1 - 0.79.0 - 0.79.1

大混乱でまさかの同日 3 リリース。

なんだろう、0.78.0が諸悪の根源なんだけどちかれた。
0.78.0 から 0.79.0 までのキャッシュ状態が完全にぶっ壊れた。んふふ。
ただキャッシュデータ生きてるのが救いだよね。
(末尾に謎 1 byte が加算されるから無事ではないわな)

2017-08-04

🐎=3

もうそろそろ youtube の実装入りたいんですがいいすかね。
既存バグ? (∩ ゚д゚)アーアーきこえなーい

つーかもう今まで頑張ってきたけど API 提供してないサービスとかとワケわからん。

2017-07-08

脳細胞の劣化

課題を書こうと思って課題ページで新規作成画面開いたら書こうとしていた課題内容を忘れている。

これが最近多い。
脳みそ死んでんね。

2017-06-20

MnMn 0.69.1

緊急リリース!

仕様変更なんだろね。

2017-06-20 15:26:26 にクラッシュレポートで教えてくれた人ありがとう。
ちょうど会社PCがWindows Update走ってやる気なくしたからすぐ帰って修正した。

だたこれかなりやっつけ対応だから下手すりゃまたなんかあるかもね。
とりあえず調査やらなんやらは #642 でやる予定(0.71.0で調査反映したいけど時間があるかどうか)。
リクエストがXMLじゃなくてJsonになってるあたり超怖い。

まぁそんな感じでゆるゆるいきたい。

2017-05-28

ゆーちゅーぶ

そろそろ Youtube に取り掛かりたい今日この頃。

アップデート周り終わったらニコニコの仕様追従なければ Youtube 対応してみたい。

2017-05-14

MnMn 0.64.0

終了時の処理が根本的にバグってたから修正した。

なんかいい感じに動いてた気がしたけど幻だった。

2017-04-21

ほーむぺーじを書き換える

.Net Core とかやりたくね? って気持ち。

今のやつって D 言語使って vibe.d で構築してるけどもう何がなんだか分けわからんレベルで再構築できないんで C# ちゃんに乗っかってなんか作ってみたい。

つーわけで近々つながらないかも。

2017-04-08

MnMn 0.60.0

途中に 0.59.1 とか噛んでいろいろ面倒なことなってたけど無事リリースできた。

このバージョンでは前々からやりたかったアップデート処理の統合とファインダーからの動画ダウンロードを実装した。
アップデートの方はロジック変更っていう怖い実装なので旧処理も使えるようにしておいた。
ダウンロードの方は基本的にユーザーから隠す形で、それでいて更新履歴見れば使える形で実装した。
後者は試験パターン少なかったし試験後にもいろいろ手を加えたからなんか変だったら連絡ほしいなってお思う。

2017-03-26

MnMn 0.58.0

簡易アップデート機能を付けた。

基本的には通常のアップデートで最新版を提供してたけどちょっとした修正、特にテキストファイルベースの修正ってわざわざリリースしなくてもいいんじゃないかと思ったので作った。
今すぐ使うわけじゃないけど MnMn の各種定義データは可能な限り外部ファイルにしてるのでそれだけ直せばいい場合は簡易アップデートでささっと更新できるようになった。
(実際使ってみないとバグとかまではわかんないけど)

一応開発側の思いとしては使わない方針で、やっべぇ時にだけ使う運用でいきたい。

2017-03-24

あれあれ、あれよ

仕事したり出張したり湯豆腐がおいしかったりすると実装が全く進まないあれよ。

2017-03-20

Visual Studio 2017 拡張メモ

環境変えたりしたときいっつもあの拡張あれあれ、なんだっけってなるからよく使う VS 2017 の拡張機能をメモで残しておく。
基本的には 2015 から継続してるやつ。
  • File Nesting
    ファイルの下にファイル入れるやつ。
    機能としてはそうなんだけど操作としてはファイルをファイルの下に入れるイメージ。
  • Match Margin
    カーソルに当たってる部分単語を強調表示。
    シンボルじゃなくて文字列にヒットするから XAML で地味に便利。
  • SlowCheetah - XML Transforms
    App.Debug.config 用。
    デバッグ時に便利。
  • Trailing Whitespace Visualizer
    終端空白が見える。
    見えるのがいいのだ。
  • VSColorOutput
    出力ウィンドウの出力内容を色付け。
    初期設定でも通常出力が淡くなって error とか warning が色付けされるので WPF のバインドエラーがよく目立つ。
  • CodeBlockEndTag
    閉じカッコに先頭カッコの内容を表示する。
    上下移動しなくていいから楽なんだけどそこまで行伸ばすなという話。
    (2013のころ #region とかも見れる別のいい感じの拡張使ってた気がする)

2017-03-19

MnMn 0.57.0

クラッシュレポートから修正掛けたり前々から気になっていた処理を修正したりした。

Twitter自動投稿botがなんかバグってるけどあまり気にしないでおこうと思った。

使用許諾の文言変えたから今回も起動時に強制表示させることになった。
この表示ってネトゲのログイン画面みたいであんまり好きじゃない。


ちなみにアップデートなんだけどわざわざ全モジュール(90MB弱)落とすのすっごい資源の無駄。
デプロイを複雑化せず(1手順も増やさない)なんかいい方法ないもんかね。

2017-03-12

Bitbucket と Twitter 連携が思って他の違う

commit毎に呟くとかなんかすごい。

push時点での一番最新commitだけ表示してくれると思ってたからなんだろうね、この気持ち。

2017-03-11

Visual Studio と Visual Studio Code に対する感想

私の端末環境だと VS(2017) と VSC の起動時間って3秒くらいしか変わりないんよね。

この程度の時間なら VSC 使わずともサクラエディタや vim でも別に問題ないなぁと思う今日この頃。
なんだったら慣れ親しんだサクラエディタで十分ですん。
そもそも IDE 以外のエディタってのはいかに標準のまま使用するかであってそれなら Windows 操作の及ぶサクラエディタに軍配が上がるから Ctrl+C で意図しないモード切替とかいらないんです、コピーしたいんです、 yy とか Windows 標準外の挙動いらないです。

サクラエディタじゃあれやこれが出来ない?
そういう時ってほんの数秒待って VS 使うから別に。。。

MnMn 0.55.0

ニコ生の課題を一旦終わらせた。

細かいやつとか独立可能なやつを細分化して課題作成した。
あとTwitterデビューしたのでなんも考えずバージョンアップした(旧目安箱早く潰したいんだ)。

ついったーはじめました

IDこれ -> sk_cttn_QQ

使い方が分からん。
BitBucketと連携だけして垂れ流したいんだけどどうすりゃいいのよ。




2017-03-08

MnMn 0.53.0

クラッシュレポートの修正やらマウスジェスチャ(内臓ブラウザ)の実装やら市場情報取得やらを行った。


まだリリースする気はなかったけどVS2017入れた記念でリリースした。

あと毎度毎度リリース時にブログ書いてたけどだるいからやめる。
気が向いたときに書くことにする。

ちなみに明日は意味なく有給なのだ。ぐっすり寝るのだ。

2017-03-04

クラッシュレポート死んでんじゃないですか!

メールアドレスに null 入れるアホなプログラム作ったやつはどこのどいつや。

2017-03-03

MnMn 0.52.0

拡縮できるようにした。

開発的にはクラッシュレポート周りを調整した。

23:10 追記:
更新履歴表記ミス
a[href="_blank"] -> a[target="_blank"]

2017-03-01

MnMn 0.51.0

クラッシュレポートに情報を追加した。

いやさぁ、最初スタックトレースだけでいいと思ってたんだけどクラッシュ時に何をしてたのかが分からんのよね。
あとキャッシュディレクトリ周りで死んでもレポートにそれを含めてなかったからなーんも分からんのよね。

今のとこ見た目多そうなのが、
System.NullReferenceException: オブジェクト参照がオブジェクト インスタンスに設定されていません。
   場所 ContentTypeTextNet.MnMn.MnMn.ViewModel.Controls.Service.Smile.Video.Player.SmileVideoPlayerViewModel.SetMedia()
   ...略...  
なんだけどさぁ、ログ見ないと動画IDとかわかんなくて再現できないんだよね。

あと謎だったのがこれ、

System.DllNotFoundException: DLL 'mozglue' を読み込めません:指定されたモジュールが見つかりません。 (HRESULT からの例外:0x8007007E)
見つかんないワケねーだろと思いつつも、例外吐いてんだからファイル見つかんないんだろうとしか思えない。

今のところクラッシュレポートから課題は作成してないけど追々中身精査して課題を作るつもり。

2017-02-26

クラッシュレポート送信を実装したことによる今

MnMn が落ちたことを検知出来てすっごい便利。

0.50.0 をリリースして24時間未満そこらだけど4件送られてきて、それが全部 開発側の想定してないエラーなので今後改修する不具合候補として非常に有用だと感じる。
(逆に100DL程度で4件落ちたっていうのが結構な割合で地味に傷ついた)
たぶん今上がってるクラッシュレポート以外にクラッシュレポート生成の余裕すらない OutOfMemoryException が含まれてるはずだから氷山の水面下はもうちっと落ちてるんだろうとは思う。

でも #422: クラッシュレポート生成時に直近のログがないときっつい! で書いてるようにログがないのは結構きついね。
スタックトレースだけだと追うには追えるけど工数掛かるので追う気がない現状なので次回リリース分には直近ログも含めるようにしてから本格的に調査に入りたい。

あとクラッシュレポートが投げられると私のところにも通知メールが投げられるのでちょっとだけビクッてなる。

2017-02-25

MnMn 0.50.0

クラッシュレポートの送信機能付けたー。

google様に尻尾振って適当なWebサービス構築した、楽だわぁ。

2017-02-22

bitbucketのダウンロード先URIが変わってた

今まで https://bitbucket.org/sk_0520/mnmn/downloads を指定してたんだけどいつからか最後に `/` を付けないと 404 になるようになってた。

なのでブログとかプロジェクトサイトのトップページを https://bitbucket.org/sk_0520/mnmn/downloads/ に書き換えた。
こういうのあせるよね。

2017-02-19

MnMn 0.49.0

りりーす。

そろそろニコ生用にコミュニティとかチャンネルの処理入れないとなぁ。

ゲーム買ったんだけどイベント中にみんな抜き身の刀剣振り回してて怖い。

2017-02-12

MnMn 0.48.0

細かいのをちょこちょこ実装してデバッグコードを仕込んだ。

ちょっくら最近時間がない。

2017-02-01

永続ライセンスを円でください!

dotMemory がほしいのですよ。
でも ReSharper Ultimate が $399 ってきつくね? しかも年かよ、趣味じゃ無理っすよ。

2017-01-29

MnMn 0.46.0

GeckoFx と MnMn がすこし歩み寄った。

歩み寄るには歩み寄ったがその道を整備するのに1週間かかったから継続対応としていったんリリース。

2017-01-22

MnMn 0.45.0

ソース整理と更新履歴に画像表示できるようにした。

それ以外はこれと言って大きな実装なし。

2017-01-20

MnMn 0.44.0

XML のシリアライズ時で発生するメモリリークを修正したのと細かいのを色々いじった。

つーかあれよ、bitbucket 重い!