- Rubyについて Part49
852 ：デフォルトの名無しさん[sage]：2014/09/21(日) 22:22:20.56 ID:9m2mBLrL - >>850
Kivy について調べてみたけど、
「ゲーム開発のラピッドプロトタイピングに適したマルチプラットフォームな簡易フレームワーク」
として、とても優れていると思う
特に Unity のライセンス料金は個人デベロッパにはあまりに壁が高い設定だから、
MITライセンスである Kivy への移行を真剣に考える人が続出するかもしれない
気になったのは、以下の２点：
・ プラットフォーム(iOS/Andriod)へのアクセス能力が欠落している
もしも本格的なアプリ開発を目指すなら、プラットフォームへのアクセス能力は必須になる
たとえばiOSアプリならば CoaData や iCloud への対応は必然的に要求される
けれども Kivy にはこの能力が欠落しているから、用途はゲームアプリ開発等に限定される
・UI記述に独自の言語(kv language)を使わなければならない
Javaのような静的言語であればXMLのような記述言語が必要になるのも理解できるし、
あるいは複数のプログラミング言語をサポートするのなら納得できる
けれども Kivy は動的なスクリプト言語である Python 専用の環境なのだから、
UI記述に専用言語を要求するのは、学習コストの負担、そして表現力や拡張性が
制約に縛られるといったデメリットしかない
（長いので、ここで切る）
|
- Rubyについて Part49
853 ：デフォルトの名無しさん[sage]：2014/09/21(日) 22:42:03.10 ID:9m2mBLrL - （>>852 の続き）
最初にスペルミスを訂正しとく：CoaData --> CoreData
次に質問にあった同様な Ruby フレームワークだけど：
・重量級フレームワークとしては、>>851 が紹介した Ruboto と RubyMotion がある
これらはどちらもそれぞれ Jaya クラスライブラリやCocoaフレームワークを自由に
アクセスできる能力があるから、本格的なアプリ開発にも適応できる
・マルチプラットフォームな簡易級フレームワークとしては2007年に初リリースされた Shose がある
専用のUI記述言語を必要とせずRuby の内部DSLとして実装されているから、
前記のUI記述専用言語に関わるデメリットはすでに解決されている
Shose は iOS/Android に対応していないし OpenGL のような3D対応もないけど、
Ruboto と RubyMotion の上に簡易フレームワークレイヤーを実装する技術的な壁は小さい
もし簡易フレームワークにもニーズがあれば、Ruby でも同様なプロダクトは登場するだろう
（個人的には(Shose が普及しなかったように)簡易フレームワークのニーズは低いと思うが....）
最後に、結論としてまとめよう：
Kivy は簡易フレームワークだから初級ゲームプログラマ向けの教育用途に適しているのに対して、
Ruboto と RubyMotion はプロフェッショナル向けの本格的なアプリ開発に適している
これが >>840 で書いた「Web と iOS/Andriod の未来」の姿だ
手続き型言語の Python はプログラミング初心者向け教育と得意な科学技術計算の分野で頑張ってくれ
|
- Ruby 初心者スレッド Part 55
527 ：デフォルトの名無しさん[sage]：2014/09/21(日) 22:53:37.94 ID:9m2mBLrL - >>524
以下のCGIプログラムを実行してみる
print "Content-type: text/plain¥n¥n"
p $LOAD_PATH
|
- Rubyについて Part49
855 ：デフォルトの名無しさん[sage]：2014/09/21(日) 23:06:41.04 ID:9m2mBLrL - >>854
またスペルを間違えていたみたい： Shose --> Shoes
http://ja.wikipedia.org/wiki/Shoes
|
- Ruby 初心者スレッド Part 55
529 ：527[sage]：2014/09/21(日) 23:14:28.45 ID:9m2mBLrL - リロードするんだった...orz
|
- Rubyについて Part49
857 ：デフォルトの名無しさん[sage]：2014/09/21(日) 23:53:28.83 ID:9m2mBLrL - >>856
> UIとロジックの分離なんてのはgettext並に行われている常識でしょ
gettext は単純なキーワードと文字列の対応表だから、
UIとロジックの分離という意味では比較対象にはならんでしょ
> 文法もQMLがJS(ON)ではなくPythonライクになったぐらいの事で
>>852 で書いた Java と XML の関係と同様に、
C++ は静的言語だからUI設計に柔軟性を与える為に QML が存在する意味はある
また Qt Designer のようなGUIビルダによる開発サポートもある
言い換えると、QML の存在価値と、Python や Ruby のようなスクリプト言語で
IDE のサポートが無い専用言語を採用する Kivy のケースとでは、前提からして異なるということ
まとめると、反論として挙げた gettext や QML だけど、反論の具体例として不適格だと思うね
まあ、もしも >>856 が「Rails の has_many なんかは非常識だ、
データベースは XML や専用言語で定義するのが常識だ」と考えているのなら、
返す言葉はないけど....
|