Translate

やっぱりもう少しRubyを継続

やっぱりもう少しRubyを継続



Rubyを使う本来の目的を思い出した。

昨今、クライアント・サーバーアプリを開発する際も、処理はサーバーでやるような雰囲気になっているからだ as Universal Windows Platform(ユニバーサルウィンドウズプラットフォーム)

MicrosoftのIISサーバーを使用するWEB環境は、イントラネット上のシステムだった場合、いちいちユーザー毎にライセンスが必要になる。
はっきりいって、WEBにする理由は、経費削減が主たる理由なのに、その経費削減が+ーゼロ以下、マイナスになる。

・・・で、Ubuntuに、Rubyの環境入れて、って発想で、始めることにしたのが主たる理由。

正直、PHP、Ruby、Python、C#、Java、どれにしようか迷った時、WEBはPHPが主流と聞いて、PHPの事を調べたけれど、PHPのエンジニアがどんどんRubyに流れていると聞いて、Rubyを選んだのだけれども・・・

が、この情報は、SEO対策された、情報操作されたサイトに引っかかっただけかもしれないな・・・( ;∀;)

従来

どういう事かと言うと、今までは、C/Sアプリと言えば、クライアント側はクライアント側でデータ取得やら何やらクライアントに必要な処理は一式書いて、サーバーはサーバー専用のバッチとか色々プログラムを作っていた。
(サーバーエンド、フロントエンドが分かれていた)

これからは・・

サーバーエンド、フロントエンドががっちゃんこされる。
これはどういう事かというと、データ取得に必要な処理はクライアントからWEB-API等でデータ取得の条件をサーバーに要求(サーバーエンド側へ)、サーバー側はWEB-API側でデータ取得を行い、クライアントへJSON等で返す。

何故これが先鋭的なのかというと、こうする事で、クライアント側は、Windowsであろうが、Androidであろうが、iPhoneであろうが、表示周り以外は処理をサーバー側に持たせているので作らなくて良いと言う事になるからだ。


ただ・・・

アプリのUI設計や実装にレスポンシブを適用するのか、それぞれの開発環境で再構築するのか、ビュー周りが微妙。

そして、何より、日本はITにお金を掛けない企業が多いため、少数精鋭で立ち回る日本のシステムエンジニア・プログラマーにとって、開発工数を増やして成果を減らすよりも、環境を絞って、最速で成果を出すことに価値がある現場も多いので、日本で流行るかどうかはかなり謎。

パッケージを開発するのであれば、これは目玉商品になる。
宣伝に、全プラットフォーム対応って書けるし。


Ruby・・・Scafoldは・・・Ruby独特っぽく、これはいくらなんでも覚えても覚えなくても良さそうな雰囲気だし、読み飛ばそう。
UIが無く、コマンドをコレ以上覚えるのは、自分の脳の記憶領域の無駄だし。



このブログの人気の投稿

VBAのADOで「パラメーターが少なすぎます。xを指定してください。」と表示された場合の原因

PostgreSQL 11 でpg_dumpallを使ってバックアップしたデータをリストアするとき文字化けの対処法

ACCESSのVBAを実行するとACCESSが強制終了する事がある

ACCESSでバーコードスキャンしたら自動でイベントを起こす方法

VBSでマクロの実行時に警告を非表示にする方法

ACCESSのVBAでADOを利用したバインド変数を利用したデータベース連携方法

ACCESSのVBAでリストビュー(ListView)を使う為の設定 | Office365

pgAdmin 4が遅いのは仕方がない | PostgreSQL things.

C#でクライアント証明書を作成するプログラムコード

DataSpiderのファイル処理が遅い原因は大体コレ