koudenpaのブログ

趣味のブログです。株式会社はてなでWebアプリケーションエンジニアをやっています。職業柄IT関連の記事が多いと思います。

デスクトップ

雑記

この記事ははてな社内のスピーチで喋るネタとして書かれました。

はてなに入社する際に作業用パソコンとしてMacを選びました。結果、デスクトップはこのような感じです。

f:id:koudenpa:20190328110928p:plain
koudenpaのデスクトップ

現代は仕事をする上で色々なソフトウェアを使いますが、自分は耐えきれない不便さがない場合はデフォルトの設定のまま使っています。Macでスクリーンショットを撮ると、デフォルトではデスクトップに保存されるのでこうなります。

f:id:koudenpa:20190328111213p:plain
よく見ると複数の画像ファイルが重なっている

今日話題にしたかったのはこのザマなパソコンのデスクトップではなく、物理的な卓上の方です。

f:id:koudenpa:20190328135056j:plain
デスクトップ（物理）

プラモデル、フィギュアが好きなのでそれらを並べています。

（まだ数が少なくて寂しい）

固定ポーズのものより関節を動かせる稼働フィギュアが好きで、気分転換にポーズを変えて楽しんだりしています。

f:id:koudenpa:20190328134912j:plain
並んで座らせる

人によって目にすると癒されるものは違うと思いますが、自分の場合はそれがこうしたプラモデルやフィギュアだということですね。

これまでもおおらかな職場が多かったので、何かしら置いていました。フリーアドレスな時もあったのですが、その時は私物を配置する余地がなくて寂しかったです。

f:id:koudenpa:20190328135431j:plain
過去の例、デスクトップというよりはディスプレイトップ

現在の課題は京都オフィスで不定期に開催されているガンプラソン（退勤後に有志がガンダムのプラモデルを黙々と？　組み立てる集まり）に東京オフィスからどう食い込むか、です。

普通にビデオ通話を垂れ流しながら組み立てればいいかなー。

組み立てたらそのままデスクトップの賑やかし要員になるので、積みプラを崩せて、懇親になったりなどと合わせて一石沢山鳥です。

先日Slackに他社事例として社員のデスクトップ紹介企画が貼られていて（URL失くしたのでリンクできない）面白いと思いネタにしました。

他の方のデスクトップへの思いも聞いてみたいものです。

それでは。

.dev ドメインのブログへの設定を解除した

雑記

今朝設定した独自ドメイン設定を解除した。

はてなブログの仕様を全然理解しておらず、独自ドメインとはてなブログのサブドメインは両立するものだと思っていた。

が、独自ドメインを設定したらサブドメインへのアクセスはいい感じに独自ドメインにリダイレクトされた。

自分は *.hatenablog.com を気に入っているので他のサイトでのプロフィールに設定するURLは https://koudenpa.hatenablog.com/ のままだと思うけれど、こういう仕組みを体験するのは好きだ。

自分の嗜好は上記な感じなので、記念のスクリーンショットだけとって独自ドメイン設定を解除（CNAMEレコードを削除することで誘発）した。

そのうち *.hatenablog.com に戻るだろう。

以下記念の🦐デンス。

続きを読む

.dev ドメインを取得してブログに設定した

雑記

世の中の流れに従って自分のID名の .dev ドメインを取得して、このブログに設定した。

https://blog.koudenpa.dev/ でもこのブログを見られるようになるはず。

f:id:koudenpa:20190301090811p:plain
はてなブログへ向けたDNS CNAMEレコード設定（Google Domains）

f:id:koudenpa:20190301090725p:plain
はてなブログへの独自ドメイン設定

DNSとはてなブログの設定をした後はDNS設定の伝播や、はてなブログでの証明書発行・設定を待てばいい。

（この記事を公開したタイミングではまだ発行されていないけれどそのうち発行されるだろう）

自分は *.hatenablog.com を気に入っているので他のサイトでのプロフィールに設定するURLは https://koudenpa.hatenablog.com/ のままだと思うけれど、こういう仕組みを体験するのは好きだ。

追記：すぐ解除した。

koudenpa.hatenablog.com

NuGetパッケージデビュー App.Metrics.Reporting.Custom.Mackerel

.NET Mackerel

NuGetは.NET向けのパッケージ管理ツールで、事実上C#言語向けのライブラリが取り扱われていると考えれば良い。

現状の.NETにはざっくりWindows向けの.NET Framework、クロスプラットフォームの.NET Core、それら共通のAPIである.NET Standardがあり、新規に何かしらのライブラリを作成するのなら.NET Standardで作成しておけば概ねどのプラットフォームの.NETアプリケーションでも活用できる。

関係性はMSDNの記事（.NET Standard - .NET Core と .NET Standard の分かりやすい解説）にもまとめられている。

というわけで、先日Mackerelアドベントカレンダーで試していたApp MetricsのメトリクスをMackerelの投稿するReporterをパッケージに切り出した。

まだ切り出して独立したパッケージになっただけで、メトリクスのフォーマットや、投稿にまつわる機能も弱々なので、暇を見て自分がホスティングしているアプリケーションからのレポートをできるくらいにはしたいと考えている。

とはいえ、まずはNuGetパッケージデビュー成功。

作成、公開にあたっては以下のドキュメントを見れば良い。プラットフォーム毎にページが別れているが、.NET Standardのページへの誘導リンクはページにあるようなので、そちらを当たるべし。

docs.microsoft.com

npmやNuGetパッケージを公開してみて、使われるかどうかはともかく、公開すること自体にはそれほど敷居の高さがないと感じる。

皆さんも是非どうぞ。

.NET で動くアプリケーションを Mackerel で監視できるかな？

Mackerel .NET

Mackerel Advent Calendar 2018 - Qiita の2日目の記事は以下のようなものでした。

qiita.com

かっこいい。Javaうらやましい。.NET向けに同様な物はないかな？　とググったところ App Metrics というメトリック収集ライブラリがありました。

公式には GrafanaCloud, Prometheus, Elasticsearch, Graphite などがサポートされているようです。

サードパーティで Datadog向けのフォーマッター もありました。

「こいつは面白そうだ」ということで、Mackerelにもメトリクスをレポートしてみました。

続きを読む

ASP.NET Core の ConfigurationBuilder の構成順に気を付ける

.NET Tips

ASP.NET Core では ConfigurationBuilder を使用してアプリケーションの設定を構成する。

ただ、あまりこれを自分で呼び出すことはなく、大体はデフォルト構成で済んでしまう。 その場合はいい感じに構成される。

特別な事情があって自分で構成する場合は、構成メソッドの呼び出しに注意する。 同一のキーの設定値があった場合、後に呼び出した構成メソッドで値が上書きされていく。

私はこのような順で構成し、設定ファイル（ appsettings.json ）のダミー値が採用されました。

var config = new ConfigurationBuilder()
    .AddCommandLine(args)
    .AddEnvironmentVariables()
    .SetBasePath(Directory.GetCurrentDirectory())
    .AddJsonFile("appsettings.json", optional: true, reloadOnChange: false)
    .Build();

実行時引数 ＜ 環境変数 ＜ 設定ファイル の順（強さ）で適用される。 逆だろ！　普通！！

尚、無意識に使うASP.NET Coreのデフォルト構成はこのような感じでした。 完璧ですね。

.ConfigureAppConfiguration((hostingContext, config) =>
{
    var env = hostingContext.HostingEnvironment;

    config.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
          .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true, reloadOnChange: true);

    if (env.IsDevelopment())
    {
        var appAssembly = Assembly.Load(new AssemblyName(env.ApplicationName));
        if (appAssembly != null)
        {
            config.AddUserSecrets(appAssembly, optional: true);
        }
    }

    config.AddEnvironmentVariables();

    if (args != null)
    {
        config.AddCommandLine(args);
    }
})

ドキュメントに解説もあります。

ASP.NET Core の Web ホスト | Microsoft Docs

次の順序でアプリの構成を読み込みます。 - appsettings.json。 - appsettings.{Environment}.json。 - エントリ アセンブリを使用して Development 環境でアプリが実行される場合に使用されるシークレット マネージャー。 - 環境変数。 - コマンド ライン引数。

このBlogでは何度も書いていますが、みなさん「ドキュメントはしっかり読みましょう」。それでは。

Swagger で広がるような気がする Mackerel の世界

Mackerel Tips Azure

元々はよい感じに試行を行って『Swagger で広がる Mackerel の世界』のような景気の良いタイトルにしようと思ったのですが、なかなか辛みもあったので弱気なタイトルになりました。本記事は Mackerel Advent Calendar 2018 の4日目の記事です。

さて、Mackerelは近年のSaaSでは標準装備となっているHTTPで呼び出せるAPIの提供が行われています。

Mackerelの機能は公式の mackerel-agent も含めてほぼすべてがこのAPIを活用しています。 （Webコンソールは違う様子です。そもそも認証がAPI Keyではないですからね）

このHTTPで呼び出せるAPIには定義の仕様が存在しており、その中の一つがSwaggerです。 現在はSwaggerの後継のOpenAPI Specificationが最新なのですが、周辺エコシステムの整備状況から2018年末現在ではSwaggerを使用するのが現実的な状況です。

さて、そのSwaggerによるMackerel APIの仕様定義があるとどうなるのか？　を見てみたいと思います。

サンプルはSwaggerを良い感じに活用している気がする Azure の Logic Apps です。

定義は自分がMackerelを使うときのサンプルにしている『アラートの数をサービスメトリックに投稿する』事ができる最低限のAPIに対して行いました。

open-api-spec-sandbox/mackerel-api.yml at master · 7474/open-api-spec-sandbox · GitHub

続きを読む