投稿

11月 18, 2017の投稿を表示しています

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設計や実装にレスポンシブを適用するのか、それぞれの開発環境で再構築するのか、ビュー周りが微妙。 そして、何より、日本はI

Rubyはやっぱり不安定な言語だった。

イメージ
Rubyはやっぱり不安定な言語だった。 Rubyのインストーラーがやたら不安定。 他のPCでインストールしても、色々エラーがでたので、ネットで調べていたら・・・ フリーの言語でありがちな、本業が忙しくてもう更新できないギブアップがあったらしく。。。 だから、嫌なんだよな・・フリーの言語。 お金払ってでも、安定可能な言語が自分は好きだ。 Rubyは一旦一休みしよう。 スクリプト言語にありがちな、処理速度も遅いことが、今回色々試してみて分かった。 成功するか否かのプロジェクトだった場合は、予算もないだろうから、この言語は良いのかも知れないが、先が短そうな事もなんだか分かった。 困る。マジで。 記憶の無駄になる。

MVVMは、古いプログラマーにとって非常に脅威。 MVVM to attention to older programer...

MVVMは、古いプログラマーにとって非常に脅威。 MVVM to attention to older programer... 何度かMVVMパターンについて取り上げているけれど、改めて、MVVMパターンについて勝手に議論。 古いプログラマーにとって脅威と思うのは、そもそももう設計すら行うことが出来ず、ただの要件定義するだけの人に成り下がってしまうから。 要件定義は・・・実際のところ、覆される事が殆どで役に立たず、 どちらかと言うと、ヒアリングしてプロトタイプ見せて、が出来るエンジニアが良いの だけれども、日本のエンジニアは、プログラムすら組めない人が多いから、大体の要件定義は、ゼロになるレベルで覆される。 MVVMパターンはSEも知っておくべき 最近のシステムエンジニアとプログラマーの間では、大きなギャップがあると考える。 それは、今みたいにバリデーションのフレームワークやルールが無く、プロジェクト毎にシステムエンジニアによる属人的な考え方で通用していたからだ。 さらに、MVC(モデル、ビュー、コントローラー)のような考えで作られることも無く、Ruby on Railsや、他の言語にあるLINQのようなものも無かったので、とにかく、プログラムの経験も無いシステムエンジニアによる、自由な仕様でも、賛否は少々あるものの大体通用出来ていた。 昨今、急激な進化なのか、ただのシェア争いに巻き込まれているだけなので、物凄く状況は 進化 変わった。 既存の古い資産を何かする為の設計書は、誰でも書けばそれも一つの有り様だと納得は行くのだけれども、MVCやMVVMパターンだと、それはいくら何でも変じゃない?と思う物が多い。 それは、それぞれの思想モデルを全く意識せずに書かれてしまうからだ。 プログラマーからみれば、タダのやりたい事を書いただけのようなリストに見えてしまうのだ。 MVCやMVVMを意識して設計書が書かれていれば、同じ入力ルールー等は別途そのルールの設計書があれば良いのだけれども、そもそもMVVMを知らないエンジニアにとって、それのメリット、デメリットすら分からずに書く為、プログラマーは予定していた作業工数とは違う作業が発生する事に気がつく。 ビューモデルの共通性を整理する作業。 今