クロスプラットフォーム ～OpenFL 統合環境～
OpenFL開発の統合環境は、「FlashDevelop」を用いる。
ここで残念なお知らせだ。このFlashDevelop、Windows環境しなかないのである。
会社ではWindows、外出時にはMacBookAirを使っているボクとしては、両方の環境で使える開発環境が必要である。余談だが、単にかっこいいのでMacBookAirを使っているが、非常に不便である。
もしMacでFlashDevelopを使う場合は、仮想環境を使ってくれとのこと。とりあえず、Windowsのみで試してみる。
以下のサイトで、「Downloads」→最新のFlashDevelopをダウンロード
インストールウィザードが表示されるので何も気にすることなくNextをクリックし、Installする。
そしてインストール完了。なんてらくちん。
試しにプロジェクトを作成してみる。
「プロジェクト」→「新規プロジェクト」をクリックし、「OpenFL」を選択。
名前は適当に「Test」と入れてみる。ＯＫをクリックすると、空のプロジェクトができる。
右側のツリーから「src->Main.hx」を選ぶとなにやらソースが表示される。
ここにコードを書くことで実行できるらしい。
画面上部には、「html5」や「flash」といったコンボボックスある。きっとこれで自由に出力イメージを選択できるに違いない。
さて、次回は実際にプログラムを書いてみようと思う。
クロスプラットフォーム ～OpenFL インストール～
では早速OpenFLのインストールを実行してみる。
結論から言うと、かなり簡単である。
インストール環境
Windows8.1
Haxe 3.1.3
ちなみMacOSにもインストールしてみたが、同じ手順でOKだった。
では、早速インストールしてみる。
以下のURLからバイナリをダウンロードして実行する。
ウィザードに従って、インストールを完了させる。
次にコマンドプロンプトから以下のコマンドを実行する。
# haxelib setup
# haxelib install lime
# haxelib run lime setup
# lime install openfl
※Windowsの場合
# lime setup windows
以上でインストール完了。
次にコマンドからサンプルアプリケーションを作成してみる。
以下のコマンドで、サンプルアプリケーションの一覧を表示できる。
# lime create openfl
* openfl:project
* openfl:ActuateExample
* openfl:AddingAnimation
* openfl:AddingText
* openfl:BunnyMark
* openfl:DisplayingABitmap
* openfl:HandlingKeyboardEvents
* openfl:HandlingMouseEvents
* openfl:HerokuShaders
* openfl:PiratePig
* openfl:PlayingSound
* openfl:SimpleBox2D
* openfl:SimpleOpenGLView
* openfl:SimpleSWFLayout
* extension
とりあえず、イメージの表示を行うサンプルを作成してみる。
# lime create openfl:DisplayingABitmap
# cd DisplayingABitmap
# lime test neko
nekoというのはOpenFL専用の仮想マシンのようだ。
実際には、「html5」「flash」「windows」を指定することになる。
うむ、見事だ。
圧巻なのはwindowsでネイティブコードを出力して、コンパイルを実行している。
残念だったのはFlash。コンパイルエラーが発生してしまった。
とりあえず、今回はスルー。
OpenFLのコンパイル環境は整った。だが、私は現代っ子。
正直、統合環境がない状況で開発をする気になれない。
面倒とか不慣れ、という以前に統合環境、特にデバッグ環境の充実さは質に直結する。
なので、充実した統合環境がない言語は基本的に採用しない。
では、次回は統合環境の整備を行ってみようと思う。
クロスプラットフォーム ～OpenFL 考察～
仕事の都合上、複数のプラットフォーム上（Win,Mac,iOS）で動作可能なアプリケーションの開発が必要になりそうだ。
ネットワークが接続できない環境での使用が必須で、残念ながらWEBではなく、アプリでの開発が必要な案件だ。
要員を投入してそれぞれのプラットフォームごとに開発を行うのも可能だが、過去の経験で、同一仕様でWindowsとHP-UX向けの運用支援スクリプトを作成した際、仕様の誤差が最後まで縮まらず大変苦労した経験がある。
できれば、単一ソースで作成し、複数環境で動作可能なアプリケーションを実現したい。
今もっている技術で実現可能なのは、Javaだ。
しかしながら、Javaで作られたクロスプラットフォームのアプリケーションをいくつか使ったみたが、ほとんどは開発支援用のツールだ。しかも、動作は緩慢で、Windows以外のプラットフォームでの操作感に違和感がある。ツールや使用環境が限られるアプリケーションであれば我慢できるが、一般公開するようなアプリケーションの作成には不向きだ。
次に考えられるのが、AdobeAIR。日本郵政が提供している「はがきデザインキット」で使用したことがある。（逆に他のアプリケーションは見たことがない）
これは主にWEB開発に利用できる技術（HTMLやFlash）でリッチなデスクトップアプリケーションを作成することができるものである。確かに非常にきれいなU/Iであり、一般公開するアプリケーションとして十分に耐えうるものではある。しかし、とにかく重い。起動までに時間がかかりすぎて、作業を中断することもたびたびあった。我慢して、ということも可能だが、開発者側の都合を、使用者に押し付けるようで、少々心苦しい。
そこで他に選択肢がないか調べた結果、「OpenFL」というゲームやアプリケーションを構築するためのソフトウェア開発キットがあった。すばらしいのは、出力形態がiOS、Android、BlackBerry、Windows、Mac、Linux、FlashとHTML5に対応しているのだが、単一ソースからそれぞれのプラットフォーム向けにネイティブコードを出力してコンパイルするのだ。Java、AdobeAIRの動作が緩慢な理由は、クロスプラットフォームを実現するためにVMという仮想マシン上で中間コードを実行するためである。ネイティブコードでコンパイルするのであれば、パフォーマンスに関してはかなり期待することができる。比較的新しい技術のようで、参考文献はまだ少ない。
だが、このような技術はエンジニアとしてワクワクする。次回、環境を構築して評価してみたい。
海洋深層水の謎
週末、あまりにも喉が渇いたので買った水が海洋深層水。
喉も乾いていたので当然おいしくいただきましたが、ここで疑問。
海洋深層水っていうくらいだから、当然海の水だと思うが、
なぜしょっぱくないのだろう？深い海の水はしょっぱくないのか？
というわけで調査。
～引用元「http://brightjyuku.com/2-7.html」～～
海洋深層水は水深200m以下から採水されますが採水されたままの海水はしょっぱくて、とても人が飲めるものではありません。
そこで深海水を汲みあげた後にミネラル、水分とを分け塩を除去したり殺菌などの処理が施された後に再度ミネラルを含ませているため、海洋深層水は海水なのにしょっぱくないのです。
こうした工程を経てお店で売られている海洋深層水はミネラルウォーターには属さず、機能水に属します。
ちなみに海洋深層水は各メーカーによって特徴が異なります。
- 地下水をプラスしている
- ミネラルを添加している
～～～～～～～～～～～～～～～～～～～～～～～～
やっぱり加工しているんだ。では、なぜワザワザ加工してまで、
海の水を使うのか？
～～～～～～～～～～～～～～～～～～～～～～～～
特にミネラルウォーターに比べマグネシウムの含有量が豊富
～～～～～～～～～～～～～～～～～～～～～～～～
効能はとりあえず置いておくとして、やはりそれなりの効果はあるようだ。
それでもワザワザ水をくみ上げて加工するほどの効果やコスト面のメリットは
あるのか？気が向いたら次回調べてみることにする。
Microsoft Azureにやられた、、、
仕事上、試験的立ち上げているサービスについては、コストの面からMicrosoft Azureを使っているのだが、本日、そのサービスに繋がらないのでログインしてみると、ドライブ全体が読み取り専用になっておて、すべてのサービスが起動しない状態になっていた。（Azure上に構築している仮想マシンは、CentOS）
dmesgや/var/log/message を確認したところ、 案の定ファイルシステム（ext4）が壊れた模様。大して利用していないサービスにも関わらずファイルシステムが壊れるとは、一体全体なぜ...？
Azureの冗長化の仕組みなど調査が必要だと思うが、まずはサービスの復旧が優先。
１）fsck の実行
２）別サーバーにて再構築
１は、手っ取り早いが、最悪まったく動かくなくなる可能性あり。２は、/から読み取り専用になっているので、データの移動ができない状態で吸い上げなければならない。かつ、DataBaseについては、dumpをとらずにデータファイルの移動だけで再構築を行わなければならない状況。
幸いにも、mountしているディスクで壊れていない領域があり、移動が必要なファイルを圧縮しながらコピーすることが可能だったので、2を選択。
新しく仮想マシンを立ち上げ、環境を構築することに成功！
DBはPostgresだったが、以外とデータファイルのコピーだけでリストアできるのね。
今回は、仮想マシンへのログインができた＆壊れていない領域があった、ということで新しい環境への移行を行うことができたが、正直、運が良かったと言わざるをえないだろう。
度々Azureはサービスダウンやリブートが起きるようだが、自分たちの使い方が悪いのか、理解が足りていないのか？まだまだ安心してお客様に案内できるレベルではない。一度、Microsoftのセミナーに参加して詳細を学ぶべきなのだろう。
