読者です 読者をやめる 読者になる 読者になる

WCF サービスを Topshelf で Windows サービス化

.net

はじめに

WCF サービスをセルフホストする場合、 Windows サービスを作ることになると思う。

本番環境で動かすときは Windows サービスでいいんだけど、 デバッグはコンソールアプリケーションの方が便利。 そのため、Windows サービスとコンソールアプリケーションのプロジェクトを両方作って保守している。 もちろんコードの大部分は共有しているが。

Topshelf 使えば手軽に Windows サービスを作れる上、 コンソールアプリケーションとしても実行できるらしい。 こいつを使えば2つのプロジェクトを保守する手間とオサラバできそうだ。 これは試してみる価値あるな。

github.com

Topshelf をインストール

Visual Studio の Package Manager Console で

> Install-Package Topshelf

を実行し、WCF サービスのプロジェクトに Topshelf をインストールする。

Topshelf を使って WCF サービスをセルフホスト

下記のようなサービスコントラクトとサービスクラスがあったとする。

namespace WcfSample.Common
{
    using System.ServiceModel;

    [ServiceContract]
    public interface ISampleService
    {
        [OperationContract]
        string GetServerName();
    }
}

namespace WcfSample.Service
{
    using System;
    using WcfSample.Common;

    public class SampleService : ISampleService
    {
        public string GetServerName()
        {
            return Environment.MachineName;
        }
    }
}

Topshelft を使えば、こんな感じで Windows サービス化できる。

namespace WcfSample.Service
{
    using System.ServiceModel;
    using Topshelf;

    class Program
    {
        static void Main(string[] args)
        {
            HostFactory.Run(config =>
            {
                config.Service<ServiceHost>(service =>
                {
                    // エンドポイントの設定はアプリケーション構成ファイルで行うことを想定しているので
                    // ここでは設定していない。
                    service.ConstructUsing(settings => new ServiceHost(typeof(SampleService)));
                    service.WhenStarted(host => host.Open());
                    service.WhenStopped(host => host.Close());
                });

                config.RunAsNetworkService();
                config.SetDescription("WCF サンプルサービス");
                config.SetDisplayName("WCF サンプルサービス");
                config.SetServiceName("WcfSampleService");
            });
        }
    }
}

コンソールアプリケーションとして実行

作成した exe を普通に実行するだけ。

> WcfSample.Service.exe

Windows サービスとしてインストール

install サブコマンドが使えるようになっているので、

> WcfSample.Service.exe install

Windows サービスをインストールできる。

インストールしただけでは開始されていないので、 start サブコマンドを使って

> WcfSample.Service.exe start

Windows サービスを開始してやる必要がある。

Windows サービスをアンインストール

uninstall サブコマンドも使える。 今回のサンプルなら

> WcfSample.Service.exe uninstall

でアンインストールできた。

おわりに

超簡単に WCF サービスを Windows サービスでホストできた。 この簡単さを経験した後だと、 もう Windows サービスのプロジェクトテンプレートを使いたいとは思えないな。 今まで仕方なく使っていたけど、もうやってられない。

16区のアイスクリームとシャーベット

gourmet

薬院にあるフランス菓子16区はダックワーズで有名だけど、まだ残暑厳しいこの時期は焼き菓子よりもアイスでしょ。 用事で近くを通ったので、アイスクリームとシャーベットをそれぞれ1種類ずつ買ってみた。

アイスクリームは定番のバニラをチョイス。濃厚でクリーミー。バニラビーンズたっぷりで風味も豊か。

シャーベットはキャバイヨン・メロンにしてみた。なんと果汁55パーセント。本当にメロンを食べているみたいだった。

16区のアイスクリームはずっと食べてみたいと思っていて、高くつくけどFAXで6個入りを注文しようとさえ思っていたから、今回念願叶って満たされた。

関連ランキング:ケーキ | 薬院大通駅桜坂駅薬院駅

『Web API : The Good Parts』を読んだ

book

Single Page Application を作る場合、Web API も作ることになるので、勉強のために購入して読んでみた。 以下、感想と読書メモ。

1章 Web APIとは何か

Web APIJSON over HTTP とも言える。REST API とは呼ばない。

Web API を提供する対象として、未知のたくさんの開発者(LSUDs)と既知の小数の開発者(SSKDs)がある。大半のアプリは SSKDs が対象になるだろうな。今作っている Web API もそう。

2章 エンドポイントの設計とリクエストの形式

Web API のエンドポイントの設計は REST と同じ。 ただ、単語をつなげるときアンダースコアを使っていた。 ホスト名と揃えるならハイフンの方が確かに良いかもしれない。

3章 レスポンスデータの設計

レスポンスデータは JSON で返すとして、API で配列を返したいときに配列のまま返すか、 オブジェクトでラップするかは悩む。

オブジェクトでラップすれば

  • JSONJavaScript として読み込んだときに構文エラーになるから JSON インジェクション防止になる
  • ページングする場合に次のページがあるかどうかといった情報も含めることができる

というメリットはあるけど…。自分の中ではまだ結論が出ていない。

4章 HTTPの仕様を最大限利用する

Web API が返すレスポンスのステータスコード

  • 成功したら 200 番台
  • クライアントが原因のエラーなら 400 番台
  • サーバー側が原因のエラーなら 500 番台

という風に HTTP の仕様にきちんと従う。 全部 200 を返してレスポンスボディにエラーコードを入れる、なんて行儀悪いことはしてはいけない。

独自の HTTP ヘッダーは定義することがあるかもしれないが、独自のメディアタイプの定義はやりすぎだな。 HTTP クライアントが対応していない可能性高いし。

5章 設計変更をしやすいWeb APIを作る

API バージョンはパスに入れる派だな。 パスに入れておけば使う側は必ずバージョンを指定することになるわけだから。

あと、API のバージョン管理はセマンティックバージョニングで。

オーケストレーション層は BFF (Backend For Frontend) と同じかな。 汎用的な Web API と、それをクライアントが使いやすい形に束ねて加工した Web API を提供する。 Web とモバイルみたいに、クライアントが増えてきたらやることになりそう。

6章 堅牢なWeb APIを作る

Web API も Web サービスなので、セキュリティは当然気をつけている。 XSSCSRFフレームワークがサポートしてくれるが、 パラメーターの改ざんだったり、大量アクセスへの対策は自前で作りこむ必要がありそうだ。

Web API: The Good Parts

Web API: The Good Parts

テックランチ

misc

最近は夜に MacBook を開く時間が 30 分くらい確保できる日が増えてきた。まぁその時には疲れ切っていて、マンガやネットを見てしまうことがままあるのだけど。

IT コミュニティへの参加はまだまだ無理そう。平日夜や休日は子育て優先。唯一自由がきくのは平日の昼休みくらいだ。

その昼休みに先日、id:shunsuk 氏とランチをご一緒する機会があった。お互いの近況に始まり、テックな話からビジネス寄りの話までと、貴重な話が聞けて非常に有意義だった。

テックランチとでも言おうか。いろんな人とこういった時間を作れたらとは思うが、その繋がりをほとんど持っていないことが、最近の悩みだ。

『起業のファイナンス』を読んだ

book

起業やスタートアップへの参加は今のところ考えていないけど

  • ストックオプションがどういったものなのか
  • 発行株式の数はどうやって決まるのか
  • スタートアップの株価がどういう風に上がっていくのか

といったことに興味があったので読んでみた。

ストックオプションはあらかじめ決めておいた金額で株が買える権利と理解。 あらかじめ決めておいた金額よりも株価の方が高ければ、 権利を行使して株を買ってから売却することで、 その差額が利益になる、と。 株をもらえるわけではなかったんだね。

シリーズAやシリーズBといったシードラウンドで、 スタートアップの価値がどう評価されて株価が上がっていくのか。 また投資を受けることで株の保持率がどう変わるのか。 それらの流れが図表にまとめられていて非常に分かりやすかった。

発行する株式の数については見当たらなかったのでネットで調べた。 例えば資本金1000万の場合、 1株50000円にするなら200株、 1株500円にするなら20000株、 という風に1株の金額を小さくすれば発行する株式の数が増えていく。 株式分割も同じかな。

本書で得た知識を使う機会は今のところ無さそう。 ただ、将来どうなるかはわからない。 プライベートプロジェクトが軌道にのって起業、ってなればいいな。 そのときは再び本書を熟読することになるだろう。 知りたかったことはだいたい知れたので、 知的好奇心は満たされた。

『WEB+DB PRESS Vol.94』を読んだ

book

WEB+DB PRESS Vol.94 を読んだので、感想をメモしておく。

特集1 実践スケーラブル AWS

仮想マシンやロードバランサを使った VPC 構成のサービスを作ることになりそうなので、 サービスをスケールさせる際に何を監視して判断基準にすればいいか勉強になった。

というか、Microsoft Azure でこういった特集は無いのかな?

特集2 はじめての Kotlin

Kotlin を最初見たとき Swift っぽいなという印象だった。 本書を読んで、その印象はさほど変わっていない。 まぁ、ところどころ Swift とは違う点があって、Swift の方が良いなと思うことはあった。 fun よりは func だな。あとプロパティの getter と setter を書くところも、好みと違う。

Kotlin は公式の開発言語じゃないので、Android アプリ開発は Java でいいかなと思っていた。 Java8 の機能も一部使えるようになったみたいだし。 ところが Kotlin 1.1 で async/await が導入されると知って、Kotlin に気持ちが傾いてきた。 非同期は Rx より async/await で書きたいからね。

特集3 作って学ぶ Electron

Electron の用途は Web サービスのクライアント開発が多そう。 本特集で作った Twitter クライアントと同じような進め方で、 他のサービスのクライアントも作れそうだ。

Web テクノロジでネイティブアプリを作るためのプロダクトは群雄割拠。 その中でも Electron がウケた理由は、 モバイルに比べてリソースが豊富なデスクトップアプリケーションが対象だったから、 というのはある気がする。

継続は力なり【第2回】プロダクトアンチパターン

「それ設定で」ていうのは悲しいことに結構遭遇する。 動きが変わるとマズイ(それが改善であっても)ので、 デフォルトは既存のままにしておいて、 設定で有効にするってね。 その結果、ソースコードがどんどんスパゲッティになっていく。 結局は信念という精神論になっちゃうんで、なかなか無くならないんだろうな。

「進化」を先取る現場から【第2回】ソニックガーデン倉貫義人

「一人前」の人の下に「見習い」の人をつけるのではなく、 「見習い」の人たちは「見習い」どうしで切磋琢磨させる、 というのがプロスポーツ的で面白かった。 ただ、顧問エンジニア的なビジネスをやっているソニックガーデンだからこそ可能、 という印象は拭えないな。 人月ビジネスにぜひ風穴を空け続けていただきたい。 いいぞもっとやれ。

大規模インフラ運用最前線【第3回】データベースのバックアップとリストア

RDS や Azure SQL Database といった、マネージドサービスで済ませることができればいいんだけど。 ハイスペックの仮想マシンSQL ServerPostgreSQL を動かすことも今後ありそうなんだよなぁ。 そのときはメルカリみたいに、バックアップ専用のスレーブを立てて、 オンラインバックアップを取る構成を採用することになるだろうな。 使うデータベース製品は違えど、方針は参考にできそう。

Emerging Web Technology 研究室【第20回】OSS によるデータ分析基盤の構築

Re:dash 良さげ。 最近、自分もデータ分析基盤を構築したけど、 そのときは Elasticsearch と Kibana を使った。 知っていれば Re:dash 試したのにな。 開発者向けの基盤だったので、Elasticsearch のクエリよりは、SQL の方が使いこなしてもらえそう。 Windows 限定だったので、SQL Server + Reporting Service(または Excel) でも良かっただろうな。

Rubyの現場の最新技術【第2回】Puma を使ってみよう!

Rails 最近使っていないから、RubyRails の情報は本連載頼み。 Puma は Heroku にデプロイするために使ったことがある。 素直に実装した Rails アプリケーションだったので、 Unicorn から Puma へ移行しても特にトラブルは無かったと記憶している。 そうか、Rails 5 からはデフォルトのサーバーになったのか。 まずライブラリ開発者が嵌ることが多そうだ。

WEB+DB PRESS Vol.94

WEB+DB PRESS Vol.94

パティスリー リンク

gourmet

地下鉄七隈線野芥駅近くにある『パティスリー リンク』に行ってみた。 この店は福岡の情報番組で紹介された『土鍋プリン』が話題みたいなんだけど、 プリンよりもケーキでしょ。 ってわけでお店の名前がついた『リンク』と『苺ショートケーキ』を買って帰った。

『苺ショートケーキ』は生クリームが非常にあっさりしていた。 1ホールいけそうなくらいに。 これほどのあっさり生クリームは経験無いかもしれない。 ただ、苺がちょっと酸っぱかったかな。

『リンク』はビターで大人向けの味かもしれない。 生地に間の生クリームはこちらも非常にあっさりしていて、 ビターな生地がいっそう引き立っていた。

デパートに出店していてもおかしくない味とお値段だった。 土鍋プリンがショーケースの場所を取っていて、ケーキの種類が少なかったのが玉に瑕かな。

関連ランキング:ケーキ | 野芥駅梅林駅賀茂駅