投稿

[C#][黒魔術] implicit operator: あいまいなユーザー定義の変換を回避する方法

タイトルの通り黒魔術です(多分)、実行環境ごとの動作はどうなるかわかりません。また、C#などの仕様変更で使い物にならなくなる可能性はあります。(Support extension methods everywhereの流れ次第では仕様変更が入るかもしれない)implicit operatorとはなんぞやC#では比較演算子などのオーバーロードができます。その中(?)にimplicit operatorやexplicit operatorがあります。こいつらは暗黙的なキャストと明示的なキャストをオーバーロードすることができます。たとえばこんなコード↓があったとして public class A1 { public static implicit operator B1(A1 a) { return new B1(); } } public class B1 { } こんなコード↓は合法(コンパイル&実行可能)です B1 b1 = new A1(); explicit operatorなら明示的なキャストが必要でになります。また、implicit/explicit operatorは変換元のクラス/構造体以外に変換先のクラス/構造体にも定義することができて、以下のコードも合法です。 public class A2 { } public class B2 { public static implicit operator B2(A2 a) { return new B2(); } } B2 b2 = new A2(); 現時点(C# 7.3)ではimplicit/explicit operatorが定義できる場所は2箇所ということになります。implicit operator 2箇所で定義したらどうなる?当然生まれる疑問です。以下のコードに関しては合法です。 public class A3 { public static implicit operator …

.NET Standardでアプリケーションデータを保存するにはどうしたらいいんだろうっていう話

.NET Standardでは着々とAPIの共通化が行われ、PCLを使わなくてもある程度のことまでは .NET Standardで完結し始めてきました。
そこで、.NET Standardでアプリケーションデータを保存する際はどうしたらいいか手抜きながらに調べてみたのでメモとして書いておきます。Environment.GetFolderPathとIsolatedStorageFileEnvironment.GetFolderPathは単純に環境のFolderPathを取得するもので、IsolatedStorageFileはアプリケーションやアセンブリ単位で他のプログラムから分離するストレージのようです(詳しくは知らない)。今回はそれっぽい領域の以下の4つを調べました。Environment.GetFolderPath(System.Environment.SpecialFolder.ApplicationData)Environment.GetFolderPath(System.Environment.SpecialFolder.LocalApplicationData)IsolatedStorageFile.GetUserStoreForApplication()IsolatedStorageFile.GetUserStoreForAssembly()Environment.GetFolderPathに関してはアプリケーションデータを保存する領域以外にもDocumentsフォルダーとかも取得できます。
IsolatedStorageFileに関しては(Xamarin.Formsのコード覗いた感じ)enumで属性をOR指定して取得する場合もあるみたいですが、手抜きしたいので、それっぽいメソッドを使ってます。調査今回調査したのはXamarin.Android, UWP, Console Application(Windows)です。IsolatedStorageFileに関してはPathを直接取得することはできないので、リフレクション使って確認します。UWP, Console Application(Windows)の場合: private string isolatedPath(IsolatedStorageFile isolatedStorageF…

Bloggerのエディターの代わりにStackEditを使う続編

前回の続き前回はコードブロックに空行があるとタグ崩壊して非常につらいとこで終わったので今回はタグをescapeして回避したいと思いますfunction replaceCodeTagCallback(match, language, code) { return `\`\`\`${language}\n${code}\`\`\``; } function escapeCodeTag(string) { if (typeof string !== 'string') { return string; } return string.replace(/<pre><code class="prism language-(.+?)">((.|\n)+?)<\/code><\/pre>/gm, replaceCodeTagCallback); } こちらを例のごとくcontentScript.jsのdecorateTextareaよりの行に挿入してstackedit.openFile({ name: location.hostname, content: { text: escapeCodeTag(el.value), properties: preset, }, }); stackedit.openFile内のtext: 以降を書き換えてください。眠くてやっつけ感ありますが以上となります。
あと既知のバグとしてコードタグ内にタグがあるとStackEditのコード認識がバグるようです()

Bloggerのエディターの代わりにStackEditを使う

イメージ
Bloggerのエディターはエンジニア的にはマークダウンが使えず非常に厳しいものがありますが、ちょっと調べてみたらStackEditというOSSなWebエディターがあり、Chromeの拡張機能まで用意されていたりそれのソースコードが公開されていたりと夢のありそうな品物だったので、Chromeの拡張機能を改造してBloggerのエディター代わりにしようと思います。
欲しい機能 Chromeの拡張機能としてストアに公開されているものでは満足にBlogger環境で利用できないので欲しい機能を付けることにします。
StackEditの入力値がHTMLコードでBloggerに出力される StackEditがHTML encodeしすぎているので必要最小限にするBloggerの入力値がStackEditに読める形で反映される 改造環境の準備ソースコードを手に入れる これはGithubのClone or Downloadのとこからzip形式でDLすることができます。わかる人はCloneでどうぞ。記事作成時はver1.0.2ですnpmを使えるようにする npmはnode.jsをインストールしたら使えるようになるらしいので、ここからDL&インストールしてください。 改造 欲しい機能のリストは多々挙げましたが、要約するとStackEditの値を適切にBlogger側に反映させるだけでいいです。
Blogger側のHTMLコードがStackEditにそのまま表示されるのは許して(Markdownだし別にHTMLが混ざってても問題はないはず)
そこで、問題のStackEditの値をBlogger側に反映させる部分はsrc/js/contentScript.jsの48行目付近:
stackedit.on('fileChange', (file) => { el.value = file.content.text; }); el.value = file.content.text;です。これがプレーンテキストのためデフォルト状態だとマークダウンがそのままBlogger側に反映されてしまいます。
file.contentには便利なことにfile.content.htmlが生えていてHTMLコードが取得できるので、ここを書き換えてやればいいです。
ただ、これだけだと…

Blogger 独自ドメイン利用時https化が終わらない場合の解決策

※内容が正確かは保証しませんし、間違っていても責任は取りません(間違ってたら教えて)
詳しい原因はわかりませんが、Bloggerで独自ドメイン利用時に数か月もhttps化が終わらずにhttpとのMixed Contentになる場合はドメインをGoogle Domainsに移管すればhttps化が終わります。

Google Domainsへ移管する際はドメインロックを解除し、認証コードを手に入れておく必要があります。Google Domainsでドメイン・認証コード・個人情報・支払方法を入力したら移管作業が始まります(長くて数日かかるらしい)。
移管時の注意として、移管時に新たにGoogle Domainsでドメイン利用料を支払う必要があるので、ドメイン利用料を払ったばっかりですと結構損します。また、ドメイン利用期限が残り30日以内だったりすると移管できなかったりするようです。

ドメインをGoogle Domainsへ移管したらBlogger側の設定で一度独自ドメインを削除→Google Domainsのドメインを利用登録してください。
そうしたらhttps化が数時間で終わります。


というわけで、本サイトもhttps化作業終わりました~~~~m(__)m

csharplang: Disposable pattern

csharplangC# 8.0のマイルストーン、つまりC# 8.0で追加する予定の機能を眺めていたらDisposable patternが追加されてたのでそれの紹介;

Proposal: Allow `using` statement to structurally match `IDisposable` Disposable patternと勝手に呼んでいますが、中身はusingステートメントでIDisposableインターフェースのみの制約を外そう、つまりDisposeメソッドが定義されていればそちらを呼ぶようにしようという品物です。
現状IDisposableを実装するのは結構簡単なわけでメリットを感じられないわけですが、ref structの場合だけはメリットがあります。 そもそもref structはinterfaceを実装できないので、いまのところusingステートメントで使えません。 そこでDisposable patternの出番と言うことです。
似たような機能はC#ではいくつかありますが、たとえばforeachでのEnumerator patternではC# 8.0で予定されてるAsync Streamsのついでに拡張メソッドでの定義も許そうと計画されています。 そこで、そのついでにDisposable patternも拡張メソッドまで許そうという話は持ちあがってますが、こちらについてはC#チーム的には考えどころのようです。
Using Pattern それで、すでにRoslynリポジトリのほうにはfeatures/enhanced-usingに作業内容がマージされてます。Disposable patternと勝手に呼んでましたがPR的にはUsing patternのようですね。

内容はforeachでのパターン解析を汎用化して流用といった感じでした。


ということで、問題がなければC# 8.0で追加されることになると思います。

定数にUPPER_SNAKE_CASEを使うのは辞めようっていう話

JavaやKotlinのコーディング規則ではよくコンパイル時定数や実質的に定数として扱っているものをUPPER_SNAKE_CASEとする命名規則が取られていますが、UPPER_SNAKE_CASEは致命的に読みにくいので辞めようっていう話です。
※JavaやKotlinに限った話ではないです。
※定数に限った話でもないです。

なぜ読みにくいのか さまざまな命名規則 プログラムコードの命名規則にはいくつか種類があると思いますが、ここでは以下のものについて触れます。 UPPER_SNAKE_CASE(以下SNAKE_CASE)lower_snake_case(以下snake_case)UpperCamelCase(以下CamelCase)lowerCamelCase(以下camelCase) 命名規則通りの表現をしているので、どのようなものか?については文字通りになります。 また、SNAKE_CASEとsnake_caseを合わせてスネークケース、CamelCaseとcamelCaseを合わせてキャメルケースと表現することにします。
大雑把に分けたらアンダーバーを入れるスネークケースと大文字にすることで単語を区切るキャメルケースに分かれます。 (アッパーキャメルケースについてはパスカルケースとも呼ばれることがあります。)
読みやすさランキング 結論から言うと以下のようになります。 snake_case ≧ キャメルケース >>>>>> 越えられない壁 >>>>>> SNAKE_CASE
と言ってもsnake_caseとキャメルケースの読みやすさはの違いは大してないと思います。どちらを採用するかは「好きな方をどうぞ」でいいレベルです。
なぜsnake_caseはキャメルケースより読みやすいのか 普段我々が読む英語の文章から考えてみましょう。 I am application engineer. こういう文章があったとして、単語と単語の間はスペースで区切られますよね?
それをそのままsnake_case, camelCase, CamelCaseにすると i_am_application_engineer iAmApplicationEngineer IAmApplicationEngineer このようにな…