AWSへの移設

 

AWSへの移設が終わりました。まだ一部の機能が動いていないです。Windows Live Writerで動かした時にカテゴリを指定できていません。いろいろとデバッグしていますが、まだ終わりません。しばらくいろいろとテスト書き込み等で忙しくなりますが、今しばらくお待ち下さい。投資成績もまだ出せてませんね。

tDiaryのバージョンを4に上げた関係上いろいろな不具合が発生しています。。

Socket.IOを使ってUnityとモバイル端末を会話させる(失敗)

前々からUnityとスマホやタブレット端末を会話させたいなと考えていて、XHR使ってそれをサーバー側でUDPなんかに変換すればできなくはないというか以前はそうやってたんだけど、もう少し今どきな実装方法はないかなということでSocket.IOを使った通信にトライしてみました。

取ってきたものはここらへん↓

Unity から Node.js を起動時に裏で実行・通信して諸々の処理を肩代わりしてもらう方法考えてみた

http://tips.hecomi.com/entry/2014/04/15/011255

でも動かしてみたらブラウザ側はちゃんと動くけど、Unity側が全然つながらない。。

原因を探ってみたら、つい最近Socket.IOのバージョンが1.0に変わったらしく、プロトコルが0.x以前と互換性がなくて、0.x系にしか対応していないUnity側のクライアントが最新版のSocket.IOにつながらないというオチでしたorz

  • Unityで動くSocket.IO 1.0対応クライアントを書く(移植する)
  • Socket.IOを0.x系にダウングレードする

という2つの選択肢。後者は負けを認めたというかなんかいずれは1.0系に行くのを見過ごすのが悔しいので前者にトライしようかと思ったりするわけですが、そのうち誰かやるよね??自分がやる必要ある??みたいなめんどくさい根性が出てきてちょっと止まっています。盆休みまでは本業が忙しいので、これは盆休みの自由研究ネタですな^^;

逐次プログラミングから並行、並列プログラミングへ

ちょっとだけ、今のソフトウェア開発について思っていることを書きます。(興味ない方、専門的すぎてわかんない方はすみませんがそっと閉じてくださいm(_ _)m)

これからのソフトウェア開発はまちがいなく並行プログラミング、並列プログラミングが大事になってきます。…って業界によっては今さら何言ってんだこいつってことになりかねないですけど。でも、ぶっちゃけ私が属している組込みという業界はパソコンやスマホがすでにマルチコアへ進んでいるのに比べてまだシングルコアが大多数ですし、何よりソフトウェア開発をしている人たちが逐次プログラミングしか頭にない人たちばっかりです。しかし、いずれは組込み業界にもマルチコアの流れはやってきます(って5年前からいってますけど意外と遅いね)。このハードウェアの大きな変化とそれについていけない技術者とのギャップは克服しなければならない大きな課題となると思います。

私は大学生の時に「マルチプロセッサ向け組込みOS」っていうそれっぽい研究をしていたので、「マルチプロセッサのプログラミングって何なの?」みたいなことをよく聞かれます。私はそういう質問には(面倒くさいので)「いや、普通のマルチスレッドプログラミングですよ」と答えています。この回答は自分は間違っていないと思っています。本当に普通にマルチスレッドプログラミングを作っていただければ問題など起こらないはずです。要するに、うちらの業界ってちゃんと『マルチスレッド』が扱えていないのです。

実は組込み業界ではシングルコアの時代から『プリエンプティブなマルチスレッドプログラム』で動いてきました。組込みの世界はI/Oが頻繁に発生し、その度に動作を止めて待っていたらレスポンスが悪くってたまらないからです。μITRONというOSで実現されていて、日本が誇る組込み開発を謳歌していたのですけれど、そういった技術は次世代にうまく受け継がれなかったらしく、OSがLinuxへと変わっていったあたりから動作が重いわ、バグは垂れ流すわといった体たらくを見せています。どうしてこうなったヽ(´ー`)ノ

正直な話、マルチスレッドプログラミングは難しいです。マルチスレッドの難しさをざっくり2つに集約してみます。

  • 不具合がスレッドの実行順序に依存するために再現性が低い
  • スレッドをたくさん作れば性能が向上するとは限らない

前者は本当に現場を悩ます大問題で、ある日客先で発生した不具合を再現しようとしてもこちらでは何回やっても出ない、なんてことがいっぱいあります。また、試験に関しても重大な課題を突きつけます。形式的に完全にマルチスレッドで動作を保証するためにはスレッドが実行するアトミックな命令の全ての実行順序の重ねあわせ(インタリーブ)に対して仕様通りに動くことを確認しなくてはなりませんが、これは天文学的数値です。製品は100万年たっても出なくなります。現実的には合理的にテストケースを絞り込む必要があります。絞り込むためにはソフトウェアの設計者や試験の設計者が、マルチスレッドに対して深い理解をしていることが必要です。

 

後者の問題はマルチスレッドプログラミングに対するもっとも典型的な勘違いです。マルチスレッドや並列プログラミングは素晴らしいものだから、たくさんスレッドを作ってどんどん並列化すればどんどん性能が改善するという純粋無垢な設計者がプロジェクトを担当すれば、たちまちプロジェクトは不具合と性能の低下に見舞われてしまうでしょう。そういう設計者には世のプログラムには並列化できないものが存在することと、性能向上にはアムダールの法則というものが存在するということを教えてあげる必要があります。

さらには

  • スレッドはOSによって実現されていてそこには必ずオーバヘッドが存在すること
  • 性能(いわゆるスループット)向上だけでなくタスクの優先度、応答時間を考慮することが必要なこと

も理解しなければなりません。これらが理解できない技術者はマルチスレッドを設計すべきではないでしょう。

 

私はこの問題を克服するためには教育しか無いと思っています。大学の情報系の学科ではマルチスレッドプログラミングを必修にして欲しいです。いや、マジで。MATLABやJavascriptでなんかプログラム書いてきました→じゃあプログラミングできるね→マルチスレッドやって→なんすかそれ?みたいな事例を大量生産するのはもうやめていただきたい(涙)第1段階でマルチスレッドに対する様々な問題を体験していただいて、さらにはそれらを解決するための原理や設計手法を理解してもらう。そんな教育課程があってもいいのではないでしょうか。大学でダメならせめて会社の新人研修とか、中堅向け講座でもいいですから…。

 

じゃあ自分はどうなんだって話なんですけど、業界で働いている平均から比べたら、大分ましなつもりです(キリッ)しかしながら並列プログラミングの全てを理解している自信は全く持てないので、これからもっと勉強していこうと考えています。

 

具体的にはThe Art of Multiprocessor Programmingという本を読んで理解を深めていきます。

The Art of Multiprocessor Programming 並行プログラミングの原理から実践まで

新品価格
¥8,190から
(2014/2/2 14:03時点)

D.Knuth先生のThe Art of Computer Programmingをもじった感じの名前ですね。日本語版の出版が2009年でオリジナルが2008年ですから私が会社に入社してから出た本です。プログラムはJavaで書かれています。もう、序盤から頭いてーって感じですけどステキな未来が来ると信じて頑張って読み込んでいきます。

他にもオライリー本の『並行コンピューティング技法』っていう本も読んでみました。

並行コンピューティング技法 —実践マルチコア/マルチスレッドプログラミング

新品価格
¥3,360から
(2014/2/2 14:16時点)

 

こちらの方がページ数も少なくて読みやすかったですけど、実践例が文字列処理とか、ソートとかグラフ探索とかどちらかと言うとWebサーバーがやるようなプログラミングで組込みではあまり使わないので引き出しとして取っておきます。

 

投資ブログにこんなこと書いて何の意味もなさそうですけどw私のつぶやきを最後までお付き合いいただきありがとうございました(;_;)

Facebookアプリはじめました

どうもこんにちは。

先週、平安レイサービスを少し買戻しました。これでだいぶ株の投資比率も上がって来ました。

 

さて、今日はプログラミングの話ですが、ちょっくらFacebookアプリを始めてみようかなと。

 

ソーシャルかぶコンというコンテストがありまして、これに応募するためのアプリを書こうかなと思っています。

http://kabu-con.tse.or.jp/

 

何にしても、Facebookアプリは一度も書いたことがないので参考書を見ながらちまちまと頑張っております。

Facebookアプリ プログラミング入門

新品価格
¥2,730から
(2013/7/21 19:16時点)


PHPは少しやったことあるのでまあそれほど苦もなくできるかと思います。

一応、ざっくりとしたアプリの筋書きはできているのですが、これを実行しただけだとあまり面白くならなさそうで、すこし困っています(´・ω・`)まだ時間はあるので考えてみます。

Visual C#とXNA Game Studio はじまた

image

 

独身最後の贅沢にKinect for Windowsを買ったついでにVisual C#とXNA Game Studioを使ってサンプルプログラムを動かしてみた。

 

http://msdn.microsoft.com/ja-jp/library/bb203897(v=xnagamestudio.31).aspx

 

ちなみにXNA Game Studioのインストールでbootstrapperが途中で止まる不具合に見舞われたので、手動でインストールした。

 

http://blogs.msdn.com/b/astebner/archive/2009/06/12/9740290.aspx

 

久しくWindowsプログラムから離れていたのだけれども、最新の環境をいじってみると随分とはじまってますなー。

 

私がDirectXをいじっていたのは2007年頃で、マスタリングDirectXプログラミングっていう本を片手にC++でAPIのおまじないを叩きながら、モデルを1つ表示させるのにもひーひー言いながらプログラムをしていた懐かしい思い出。

 

それに比べるとこのサンプルプログラムは30分もかからない。DirectXの初期化だとかインスタンスがどうとかはフレームワークの中に隠蔽されていて、自分が書くのはモデルをロードする部分とカメラ位置やライティング、射影行列の定義とメッシュを描画する関数だけ。おー、これぞフレームワークって感じ。

 

言語的にはC#はJavaのパクリじゃねってずっと思っているのであまり感心はしていないけど、これだけのフレームワークを無償で提供してくれたってことには感謝しなきゃいけない。Javaとほとんど一緒だから、初めて触っていてもほとんど苦もなく読めるっていうのはある意味メリット。

 

というわけで、これから先のWinアプリはC#で書いてみようかなって思ってきました。というか、早くKinect使ったゲーム作ろう♪

牌譜が出せるようになりました

麻雀プログラミングのお話。ようやく牌譜が出せるようになりました。

ここまで来るのは大変でした。うるうる。

 

とりあえずサンプル。XMLは途中かけです。

今のところ赤ドラには非対応です。

http://www.nextappli.com/openmahjong/scoredl.php

 

あと、クライアント側を落としても、もう一度再接続が可能になりました。今までは一回でも落ちたら最初からやり直しでしたが、これでいつクライアントが強制終了しても大丈夫です…ってそれはあってはならないことですけど^^;ただ、麻雀AIのほうが非対応の場合もあります。

とある企業様から問い合わせがきましたっ!

ほぼ私一人で進めているオープン麻雀プロジェクトですが、このたび初めて企業様から問い合わせがきました!!

 

ひとりでやっているとなかなか張り合いがなくて最近更新が滞っていましたが、また頑張ろうかなって気持ちになりました^^

しかし、ドキュメントを整備することは大切ですね。全然そんなもの作ってなかったのでいろいろとメールで聞かれることになりました。まだまだやることはいっぱいありますね。いっぱいありすぎてひとりで出来るかどうか心配。。

 

でも、自信出てきました。頑張ります。