Webアプリを創る

「会社員プログラマー」は客観的に見て「つまらない」

2014年3月26日

イケハヤ氏の「会社員ブロガー」は客観的に見て「つまらない」というブログが結構話題になっているので、ブロガーをプログラマーに変えて個人的に思ったことを書いてみた。イケハヤ氏は、

本気でブログで食べていきたい、もっと面白いコンテンツを作りたいと思っているのなら、思い切って会社の外に飛び出した方が、早く理想に近づくことができると思います。

目処としては、「会社員を続けながらブログを更新し、毎月30万PVをコンスタントに獲得できている」のなら、かなり余裕でプロブロガーになれると思います。会社を辞めて本気で更新すればPVは恐らく1.5〜3倍(45万PV〜90万PV)にはなると思うので、収益性を1PV=0.4円とすると、 15万〜25万円は稼げると思われます。

これに対して、会社員ブロガーである gori.me氏が、月間120万PVの「会社員ブロガー」が語る、会社員でありながらブログを書くことの魅力というブログで会社員ブロガーだけど何か文句ある?という反論をしている。

では、「会社員ブロガー」は本当に「つまらない」のだろうか。もちろん、会社員を辞めてブログ運営に集中すれば記事内で言われている通り、それなりに収益化できるはず。ただ、同時に現役会社員ブロガーとしては、会社員でありながらブログを続けることによる様々なメリットも存在すると思う。
恐らくあの記事を読んで怒りと絶望で震えている会社員ブロガーも多いと思うので、本記事では会社員でありながらブログを書くことに対する魅力について紹介する!

まあ、ブロガーの場合であれば会社員であってもなくても、自由にブログを書くことができればそれでいいではないかと思う。プログラマーの場合はどうかというと、ブロガーの場合と同じように自由にソフトウェアを作ることができる環境にいるのであればそれでいいと思う。

ツイッターとかブログをみていると、「安易に会社辞めてはいけない」という意見が多い。確かに日本では、技術力ではなく大企業、中小企業、正規社員、非正規社員というような会社の規模や社内の身分によって給料が決まってくる部分があるのは事実である。欧米では、会社員とフリーランスを行ったり来たりしている人は多いようだが、日本では会社を辞めると身分的に一番下のランクになってしまうと思い込まされている人が多い。どうも成功体験が日本人の意識の中にかなり特殊な身分制度的なものを作り上げてしまったようだ。確かに日本は1990年頃まではIT業界にも活気があって、日本の大手はIBMと対等に勝負をしていた。メインフレーム中心の時代であったため、大手のSIer中心にしたゼネコン的な開発体制がマッチしていた。

今でもそうした意識のままで本当にいいのだろうか。メインフレームの時代であれば、個人ではハードを買うこともできなかったし、ソフトウェアも大手SIerでなければライブラリーを持つことは困難であった。しかし、最近のソフトウェア開発では企業の規模は関係なくなってきている。ハードウェアは安価になった上にクラウドを安く借りることができるし、ソフトウェアではOSSのライブラリが充実していて大手でなければ手に入らないものはなくなっている。こうした時代の流れに合わせて会社中心の考え方を変えていくべき時期になったと思う。

Webサイトを作ってどのぐらいの収入になるかというとイケハヤ氏のブログの内容は自分のこの1年の体験とほぼ合致していて、この1年間で WebサイトのPV数を約3倍にすることができた。サンデープログラマーで30万PVのwebサイトか10万ダウンロードのアプリが作れれば会社を辞めて余裕でフリーのソフトウェアエンジニアになれると思う。ブロガーと比較すると、ソフトウェアを自分で工夫することができるのでかなり有利だと思う。

これもイケハヤ氏の真似になりますが、プログラムで独立できるか不安な方はメールでご相談ください。最大限リアルなフィードバックを与えさせていただきます。

自宅サーバーIntel NUC D54250WYK と Azure & Amazon EC2 との性能比較

2014年2月28日

昨日、Windows Azure と Amazon EC2 との性能比較をしたので、自宅サーバーにしている Intel NUC D54250WYK との性能比較もしてみました。

自宅サーバーの CrystalMark での測定結果は以下のとおりです。ALU 及び FPU については、昨日のブログで紹介した Azure VM の M の測定結果より約2倍速くなっています。

image

Intel Core i5 4250U は、4コアです。コアあたりで計算すると、Amazon EC2 の現行世代(m3)も Windows Azure も i5 4250U もよく似た数値になります。CPU の計算性能だけでいうと、Intel Core i5 4250U は、Amazon EC2 の m3.xlarge 相当、Windows Azure の VM であれば L 相当ということになります。

ネットワークを余り必要としないで計算を中心としたことをさせるのであれば、Intel NUC は省電力でかなりパフォーマンスがいいと思います。D54250WYK は、メモリーや SSD を追加すると10万円近くになりますが、クラウドを借りることを考えれば4ヶ月もあれば元がとれます。今後は、D54250WYK をデーターベースの作成に活用していきたいと思っています。

Windows Azure の日本リージョンが開設されたので Amazon EC2 と比較してみた

2014年2月27日

注意!Amazon EC2 の価格が2014年4月1日から引き下げられる予定です。その時点での価格比較を「Amazon EC2 が値下げされるので、Azure と比較してみた」に書いています。

Microsoft が運営するクラウドサービスWindows Azure で日本リージョンが開設されました。それも、東京と大阪の2箇所にデーターセンターが開設されたので災害時の対策も容易に出来ます。そこで、まず Azure VM と Amazon EC2 の価格を比較をしてみました。Azure は、東日本リージョンで計算しています。西日本リージョンだと約10%安くなります。Amazon は東京リージョンです。

サーバー種別

Windows Server

Linux

短期・長期

短期(円/時間)

長期(円/月)

短期(円/時間)

長期(円/月)

Azure VM XS

\2.71

\2,012

\2.76

\2,049

EC2 t1.Micro

($0.0305)\3.20

\2,525

($0.027)\2.84

\1,271

Azure VM S

\10.82

\8,044

\8.27

\6,147

EC2 m1.Small

($0.1185)\12.44

\6,094

($0.088)\9.24

\3,650

※1ドル=105円とした。EC2の長期は重度使用リザーブドインスタンスを利用の場合。
EC2のWindows は、EBSが30GB必要になるのでその料金も含めている。

この表をみると、Azureの価格体系の特徴としては、Windows Server の XS の価格が押さえられています。初心者が最初に使うサーバーの価格を抑えて Windows サーバーの利用者を増やしたいという Microsoft の意図がはっきり表れています。初心者にとってはサーバー経費が結構負担になるものなので、低価格のレンタルサーバーでは満足できない場合の有力な選択肢です。

Azure VM の Sサイズでは、EC2 Small と比較して時間当たりでの単価は少し安くなっています。しかし、Azureの方は月額使用料が51,000円以上でないと長期や前払いの割引が受けられないため長期使用の場合はEC2 Smallよりも高くなります。ただし、Amazonの前の世代である m1タイプより Azure の方が性能的に相当高いので、Azure の方が勧められると思います。Gihyo.jpのクラウドサービスの比較をみると、同じSと言っても性能的に差が非常に大きいです。

次に、現行世代タイプである Azure VM の M タイプと Amazon の m3.medium とを比較してみます。

サーバー種別

Windows Server

Linux

短期・長期

短期(円/時間)

長期(円/月)

短期(円/時間)

長期(円/月)

Azure VM M

\21.63

\16,088

\16.53

\12,294

EC2 m3.medium

($0.228)\23.94

\10,761

($0.171)\17.96

\6,787

※1ドル=105円とした。EC2の長期は重度使用リザーブドインスタンスを利用の場合。
EC2のWindows は、EBSに60GB分を含めている。

こちらでも、時間当たりでは、Azure の方が安いのですが、長期使用では EC2 がリザーブドインスタンスを利用できるのでかなり安くなります。そこで、どちらを選択したらいいのかを検討するためには性能も重要になるので、どの程度の性能なのかを調べてみました。現行世代のm3は、前世代のm1より CPU の性能が約1.5倍に上がっていますが、一方料金は少し安くなっています。

以下の図が CrystalMark での測定結果です。ALU 及び FPU については、Azure の方が約2倍速くなっています。Azure VM の M は、2 vCPU  なので、CPU の性能だけでいうと、EC2のm3.medium は、1 vCPU である Azure VM の S とほぼ同等ということになります。Azure VM の S が月額約8000円なので、2700円でメモリーを 1.75GB から 3.75GBに増やせるということになります。こう考えると、Windows Server でも Azure が有利か EC2 が有利かは、ケースバイケースになるのではないかと思います。Linux の場合は、長期使用の場合の Azure VM の S の価格と EC2 の m3.medium の価格が 640円しか変わらなくなるので、短期間だけ利用する場合を除いては、EC2 が有利だと思います。

大企業に関していえば、Azureの方は月額使用料が51,000円以上になってくると、6月プランや12月プランの割引が使えるので、Azure の方が利用しやすいと思います。EC2 の重度利用は、価格的には安くなりますが、同一のインスタンスを使用しつづける必要があるので、弾力性の面で Azure の割引の方が優れていると思います。Microsoft によれば Fortune 500 の会社の50%が Azure を使っているということですが、トータルのコストパフォーマンスからみて当然の結果だと思います。

MARK Azure2

MARK Ec2

もう少し、Azure と EC2 の性能を詳しく比較するために、CrystalDiskMarkを使ってベンチマークをしてみました。以下の図がその結果で、上が Azure VM M、下が EC2 m3.medium の C ドライブです。

CDM Azure

CDM Ec2

Azure のディスクの Seq 及び 512K の読み込み性能はすばらしいです。Azure の Blobストレージは、広くいわれているとおり非常に優秀です。だから、仮想マシンの起動に関しても Azure は非常に早いです。

一方、Amazon の EC2 は、これに対抗して、現行世代の m3 では、SSD のインスタンスストレージを提供しています。m3.medium では、わずかに 4GBしかないのですが、下の図のようにディスク性能が飛躍的に上がっています。この SSD を有効に使えば処理速度は格段に上がります。m3.xlarge だと、2 x 40GB が提供されるので、OS も SSD のディスクにインストールできるので処理速度が格段に上がると思います。

CDM Ec2e

こうしてみると、クラウドコンピュータは、早い速度で進化しているのが分かります。

Azure の場合、日本リージョンだけが、他のリージョンより 東日本リージョンで 17.8%、西日本リージョンで 5.6% 高くなっています。データセンターを東日本と西日本の2カ所に設置したことで、国外にデータを出さず、国内だけでディザスタリカバリー体制を組めるようにしたり、「日本MSが米本社と連携し、国内企業が求めるクラウドの品質に応えられるようにする」という ITPro の記事から判断すると、日本の大企業の要望に沿ったサービスを提供するために高くなった思います。こう考えていくと、自分の場合は、Azure を使うのがいいのか AWS を使うのがいいのかはかなり微妙だと思っています。

Windows Azure 仮想マシン料金 http://www.windowsazure.com/ja-jp/pricing/details/virtual-machines/
Amazon EC2 料金表 http://aws.amazon.com/jp/ec2/pricing/

 

気象庁 XML と他国の気象庁の天気 API との比較

2014年2月24日

気象庁が防災情報XMLフォーマット形式電文の公開を始めて1年以上になりますが、日本の天気予報を自分の Web ページに載せたいと思って、気象庁XMLを使い始めています。それで、今まで使ったことがある他国の気象庁が公開している天気 API と比較してみました。

自分が使ったことのあるのは、アメリカイギリスノルウェーの気象庁のAPIです。まず、大きな違いは、気象庁 XML が、それを取得するために PubSubHubbub の subscriber を構築しないといけないということです。アメリカとノルウェーは、誰でもがRESTで簡単に取れます。下のリンクをクリックすると現時点での天気予報のXMLが表示されます。イギリスは、ユーザー登録が必要ですが、オンラインでキーが発行されます。

アメリカ ニューヨーク セントラルパーク

http://graphical.weather.gov/xml/sample_products/browser_interface/ndfdXMLclient.php?lat=40.78&lon=-73.97&product=glance

http://forecast.weather.gov/MapClick.php?lat=40.78&lon=-73.97&unit=1&lg=english&FcstType=dwml
こちらだと現在の気温等の観測データも入っています。

イギリス シティ オブ ロンドン

http://datapoint.metoffice.gov.uk/public/data/val/wxfcs/all/xml/350929?res=3hourly&key=(key)

ノルウェー オスロ

http://api.met.no/weatherapi/locationforecast/1.8/?lat=59.9127;lon=10.7461

気象庁が、無料で天気予報のXMLを公開するのは画期的なことだと思います。ただ、subscriber を構築しないと受信できないのは、ハードルの上げすぎではないかと思っています。初心者にとってはサーバー側のプログラムを組むというのは厳しいです。

それに、subscriber は、警報のように何時発表されるか分からない情報だと確かに便利だと思うのですが、天気予報のように定期的に発表されているものでは必要ないと思います。逆に、サーバーがダウンしたりして通知を取りこぼすと次に新しい通知があるまで復旧できないのが大きな欠点です。できれば、試行から本番に移行するときには他国のように単純に REST で XML を取得できるようにして、subscriber の方は追加の通知機能ということにして欲しいと思います。

ところで、先端IT活用推進コンソーシアム(AITC)の「気象庁防災情報XML」を活用するためのAPIが公開されているのを知りました。先端IT活用推進コンソーシアムには、日本の代表的な SIer が会員になっているし、鶴保会長も日本の SIer の代表者だと思います。こういう組織が作る利用規約だと先進的な利用規約を作るものと思っていましたが、10年以上遅れた利用規約で、明らかに気象庁の利用規約の方が上です。

具体的に言うと、利用規約に「新しい技術やデータセットの評価をおこなうためのものであるため、商用利用を固くお断りします。」、「定期的なクローリング、プログラムからの大量アクセスはご遠慮ください。」という条項があることです。

オープンデータでは、基本的に利用目的については問いません。だから、気象庁も商用利用を認めているし、イギリスの気象庁は Q&A で以下のように商用利用を積極的に認めています。今回の場合でも、商用利用といってもテスト的な利用はあるえると思うし、共同で開発していこうという姿勢を持つことが必要だと思います。それで、普通に書くとしたら「新しい技術やデータセットの評価をおこなうためのものであるため、予告なしにAPI等を変更することがあります。その結果生じたいかなる損失・損害についても、責任を負いません。」ぐらいの書き方がベターでないかと思います。

Can I use the DataPoint web services on a commercial website?

Yes, we actively encourage the use of the DataPoint web services on commercial websites, subject to the conditions set out in the detailed terms and conditions

次に「大量アクセスはご遠慮ください。」というのは、プログラムをする側からすれば意味不明です。きちんと定義すべきです。

アメリカの場合は、基本的に無制限で詳細に書いてあるのは免責条項です。サービスの説明の方にデータの更新は1時間に1回以上はしないから、アクセスの方も同一地点については1時間に1回だけにしてねと書いてあるだけです。

イギリスの利用規約では、1日5000リクエスト、1分100リクエスト以上になるとフェアーユースの範囲を超えるとして、有料になります。

For the purposes of this DataPoint Fair Use Policy, the Fair Use Limits shall be defined as follows:

  • You may make no more than 5000 data requests per day; and
  • You may make no more than 100 data requests per minute.

ノルウェーの利用規約では、毎秒20リクエスト以上を大量アクセスと定義しています。

You should save the information on your own server if you have heavy traffic. Heavy traffic means more than 20 requests from the api per second.

このサービスに多大なコストがかかるのであれば、今のような利用規約になっても仕方がないと思うのですが、最近は運用コストが低下して費用はそれほどかからないと思います。個人で天気予報 XML を公開している人もいるぐらいです。それに、先端IT活用推進コンソーシアムの会員にはクラウドコンピューティングを提供している企業もあるのでスポンサーになってもらえばいいのではないかと思います。日本の SIer も、OSS とかの活動にもう少し積極的になって欲しいと思います。

自分も希望があれば天気予報や週間天気予報の XML を他の国のようにRESTですぐに取れるように公開してもいいと思っています。もし、希望があればコメントに書いてください。

気象庁 XML を取得するサンプルを PHP から C# にしてみた

2014年2月21日

自分は、2008年の後半から2009年の前半にかけて、Web を作成するのに、PHP を使うのか ASP.NET で C# を使うべきなのか、それとも Java を使うのか迷った時期がありました。ASP.NET MVC がリリースされ、また、CMS も Umbraco が使えるということで最終的には C# を使うということにしました。

気象庁が提供する天気予報、気象警報、地震、津波情報などの気象庁 XML の取得については、PubSubHubbub の受信サーバーを用意する必要があります。自分でも受信サーバーをたてていて、最近C#で天気予報を取得するプログラムを書き始めています。気象庁の資料をみていると PHP のサンプルコードが、平成25年3月に開催された気象庁XML利活用セミナー気象庁XMLを入手しようにあったので、そのサンプルコードを C# を使って書いてみました。

資料のサンプルコードでシンプルな例は以下のとおりです。

<?php 
$method = $_SERVER['REQUEST_METHOD'];

// subscribe (or unsubscribe) a feed from the HUB 
if ($method == 'GET') { 
  $hubmode = $_REQUEST['hub_mode']; 
  $hubchallenge = $_REQUEST['hub_challenge']; 
  if ($hubmode == 'subscribe' || $hubmode == 'unsubscribe')
    // response a challenge code to the HUB
    header('HTTP/1.1 200 "OK"', null, 200);
    header('Content-Type:text/plain');
    echo $hubchallenge;
  }else{
    header('HTTP/1.1 404 "Not Found"', null, 404)
  }
}

// receive a feed from the HUB
if ($method == 'POST') {
  // feed Receive
  $string = file_get_contents("php://input");
  // feed save
  $fp = fopen(dateDateTime.UtcNow.ToString('YmdHis') . "_atom" . ".xml", "w");
  fwrite($fp, $string);
  fclose($fp);
?>

これと同じものを、ASP.NET MVC の C#で書いた例です。

using System;
using System.IO;
using System.Web.Mvc;
using System.Xml;

namespace PuSH.Controllers
{
  public class SubscriberController : Controller
  {
    // subscribe (or unsubscribe) a feed from the HUB
    [HttpGet]
    public ActionResult Index()
    {
      string hubMode = Request.QueryString["hub.mode"];
      string hubchallenge = Request.QueryString["hub.challenge"];
      if (hubMode == "subscribe" || hubMode == "unsubscribe")
        // response a challenge code to the HUB
        return Content(Request.QueryString["hub.challenge"]);
      else
        return NotFound();
    }

    // receive a feed from the HUB
    [HttpPost]
    [ActionName("Index")]
    public ActionResult IndexPost()
    {
      // feed Receive
      var reader = new StreamReader(Request.InputStream);
      string str = reader.ReadToEnd();
      // feed save
      using(var sw = new StreamWriter(DateTime.Now.ToString("yyyyMMddHHmmss) + "_atom.xml"))
      {
        sw.Write(str);
      }
      return Content("");
    }
  }
}

このプログラムだとは、PHP も C#はよく似たものだと思います。C#の方が型の宣言をしないといけないのと、関数名やプロパティ名が長いので、記述量が多くなるように見えますが、型宣言に var が使えてコンパイラーが自動で型を決めてくれるし、関数名等で名前が長いのはVSが補間してくれるので、入力が特に面倒だということはありません。

次に POST処理の部分を、変更したサンプルが紹介されています。コードは以下のとおりです。

// receive a feed from the HUB
if ($method == 'POST') {
  // feed Receive
  $string = file_get_contents("php://input");
  //feed Parse & XML GET
  if(FALSE === ($feed = simplexml_load_string($string)))
  {
    exit("feed Parse ERROR");
  }
  foreach($feed->entry as $entry)
  {
    $url = $entry->link['href'];
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, $url);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    curl_setopt($ch, CURLOPT_TIMEOUT, 60);
    curl_setopt($ch, CURLOPT_HEADER, 0);
    $fp = fopen(basename($url), "w");
    curl_setopt($ch, CURLOPT_FILE, $fp);
    curl_exec($ch);
    curl_close($ch);
    fclose($fp);
  }
}
?>

これを単純に ASP.NET MVC の C# に変更するだけだったら面白くないので、自分が現在使っているルーチンを紹介したいと思います。

追加と変更部分のみ
using System.ServiceModel.Syndication;
using Nlog;

    private static Logger logger = LogManager.GetCurrentClassLogger();

    [HttpPost]
    [ActionName("Index")]
    public ActionResult IndexPost()
    {
      using (XmlReader xmlReader = new XmlTextReader(Request.InputStream))
      {
        try
        {
          var feed = SyndicationFeed.Load(xmlReader);
          if (feed != null)
          {
            string feedtype = "e"; //定時:regular、随時:extra、地震火山:eqvol、その他:other
            foreach (var link in feed.Links)
            {
              if (link.RelationshipType == "self")
              {
                var uris = link.Uri.Segments;
                feedtype = uris[uris.Length - 1].Split('.')[0]; 
              }
            }
            var xmlWriter = XmlWriter.Create(
              Server.MapPath("~/App_Data/feed/") + feedtype + DateTime.UtcNow.ToString("yyyyMMddHHmmssfff") + ".xml");
            feed.SaveAsRss20(xmlWriter);
            xmlWriter.Close();
                    
            logger.Info("ID:{0} Update:{1} Type:{2}", feed.Id, feed.LastUpdatedTime, feedtype);
            foreach (var item in feed.Items)
            {
              string title = item.Title.Text;
              string name = item.Authors[0].Name;
              string updatetime = item.LastUpdatedTime.ToString();
              foreach (var link in item.Links)
              {
                logger.Info("{0} {1} Update:{2} uri:{3}", title, name, updatetime, link.Uri);
                switch (title)
                {
                  case "府県週間天気予報":
                    処理
                    break;
                  case "府県天気予報":
                    処理
                    break;
                }
              }
            }
          }
        }
        catch(Exception e1)
        {
          logger.Error("Feed Error:" + e1.Message);
        }
      }
      return Content("");
    }

ログの記録には、NLog を使っています。まだプログラムを始めたばかりなので、ログを取ったり、RSSをファイルに保存したりしていますが、最終的には、ログやファイルへの保存は最低限にしていこうと思っています。ログを取ってみると、気象庁 XML は、1分間に1回処理が動いてフィードが飛んでくることがわかります。ここで最大で約1分間の遅延があること、また、たまにフィードの送信が遅延することがあるので数分間程度のタイムラグがあると思った方がいいということが分かります。

実際にはプログラムができたら、気象庁への登録申請が必要になりますが、登録申請の前にきちんとテストをしておきましょう。Google のハブを使ったテストの方法は、気象庁の電文公開の仕組みのページの情報提供に係る仕様とSubscriberの構築についてというPDFファイルに記載があります。

この例からわかるように Web だけの話だったら、PHP はとてもいい言語だと思います。でも、PHP は Web以外で動かそうと思ったら結構大変です。Web 用のオープンソースのアプリケーションは非常に多いのですが、自分は Web 以外でもプログラムをしたかったので PHP は捨てました。C#は Web の世界でも、PHP に決して劣っているわけではありません。そして、多くのデバイスで動作することが魅力です。Android/iPhone のネイティブアプリが作れる Xamarin に期待しているので、時間ができれば Xamarin も使ってみたいと思います。