2017年11月21日火曜日

やっぱりもう少し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が無く、コマンドをコレ以上覚えるのは、自分の脳の記憶領域の無駄だし。



2017年11月20日月曜日

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

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





Rubyのインストーラーがやたら不安定。

他のPCでインストールしても、色々エラーがでたので、ネットで調べていたら・・・


フリーの言語でありがちな、本業が忙しくてもう更新できないギブアップがあったらしく。。。


だから、嫌なんだよな・・フリーの言語。

お金払ってでも、安定可能な言語が自分は好きだ。

Rubyは一旦一休みしよう。


スクリプト言語にありがちな、処理速度も遅いことが、今回色々試してみて分かった。

成功するか否かのプロジェクトだった場合は、予算もないだろうから、この言語は良いのかも知れないが、先が短そうな事もなんだか分かった。


困る。マジで。

記憶の無駄になる。



2017年11月18日土曜日

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を知らないエンジニアにとって、それのメリット、デメリットすら分からずに書く為、プログラマーは予定していた作業工数とは違う作業が発生する事に気がつく。

ビューモデルの共通性を整理する作業。


今、システムエンジニアやプログラマーにとって、大きく4つの世代があると思う

 1.MVVMパターンを知っている世代。
 2.MVVMパターンの名前すら知らない世代。
 3.MVVMパターンの名称だけ知っている世代。
 4.MVVMパターン実践は無いけれど、個人または、ごく小規模で試した事がある世代


1.MVVMパターンを知っている世代。


 MVVM信者の場合

  メリット
   大きなプロジェクト、又は、継続して膨らんで行く筈のプロジェクトな場合、
   最初の苦労はあるもののこのパターンを選んだ事に後から凄く恩恵を受けプロ
   ジェクトの成功を感じる事となる。

  デメリット
   どんな開発にもMVVMを適用しようとする。
   継続されるプロジェクトでは無い場合、やたら無駄な工数が発生し、依頼者側と
   の予算でかなりの亀裂を生じさせ、プロジェクト自体が成立しない可能性が..
   
   が、信者な為、選択肢が無い為、後悔は生じない。


 MVVM信者ではない場合

  メリット
   基本的に信者とメリットは同じなのだけれども、信者ではない為迷いが生じる。
   このプロジェクトは、今後も継続しうるプロジェクトで、その規模でデザイン
   パターンを選択する程のものなのだろうかと。

  デメリット
   やってみたものの、あまり必要とされなかったシステムだった場合には、信者では
   ない為、後悔が生じる。
     自分がやった為に、謎な程予算がかかってしまった事に。
   

2.MVVMパターンの名前すら知らない世代。

  メリット
   プロジェクトは単発で終わったり、継続されない数の方が実質は多いので予算が
   綺麗さっぱり単発分だけになる。

   また、どっち派のエンジニアにとってもやりやすいが、MVVM信者がいた場合、
   予算よりも職人肌的な所に重きを置くため、ちょっと ウザイ感じの軋轢が生じる。

   が、彼らは彼らで日々新しいものをやっていかないと未来が閉じられるかも知れ
   ない世界なので、それも一つの価値だと頷いてみせて、スピード、コスト重視で
         ある事を納得してもらう事が必要。

  デメリット
   大きなプロジェクトで存在していた場合、いつも通りの単発で終わる工数しか
       組まない為、小さなプロジェクトで予算通りでも、大きなプロジェクトでは
         異様に高い予算となってしまう。

   例えば、Windowsアプリ、Web、Android、iPhoneと横展開していく事も今後予想
   される場合には、それぞれで、ゼロから作るような工数を想定してしまい、倍々に
         予算が膨らんでしまう。

    また、リリースサイクルも非常に遅くなる。


3.MVVMパターンの名称だけ知っている世代。

  基本的に、メリット、デメリットは同じだが、まだ、ピュアな為、教えてあげると
      選択肢に組み込まれる可能性がある。


4.MVVMパターン実践は無いけれど、個人または、ごく小規模で試した
  事がある世代

  メリット
   小規模でしか試していない為、小規模には向かない事を重々承知している為、
       おおよそ上手くどっちが良いか判断してくれる。

  デメリット
   小規模でしか経験をしていない為、コーディング量のボリューム増加や使用する
   フレームや言語によっては、作り方も全然異なる為、プログラマーサイドからは
   常に妥協を提案するやりとりが発生してしまう。

   その妥協で救わる場合も多いとシステムエンジニア側もある程度は分かっている為
   規則じゃ無い場合には、メリットになる。
     

勝手にまとめと感想

  理想は、取り敢えず雑に作って、当たればMVVMデザインパターンで作り直せる
    事が出来る環境なんじゃないかなと・・・
 
  当たるか当たらないかが分からないから、予算管理をする側にとっては、常にその時
  一番安いコストを選択するのが、日本のシステム何だと思うけれど。

  ただ、これらのMVPや、MVVMや、MVW的なデザインパターンを選ぶデメリットだけ
  思う所があるのは、最近は、フレームワーク自体が物凄いシェア争いの渦中にあり、
  そのやり方が古くなったり、例えば根本的に変えられてしまった場合には、
  色々なデザインパターンのシステムが増え続け、コストの関係でシステム維新が行
  えない場合には、言語がトレンドでも、COBOL言語のような運命になりかねないリス
  クを抱えてしまうのではと考えてしまう。

  まだ、コンピューターシステムが浸透して、そんなに世代交代が起きていない
  ので、今後世代交代や色々な世代が出てくることで、折角オープンな世界で
  コストを削減できても、後からそれが分かっているエンジニアを確保するのが
      難しくなることに気がつくのかもしれない。
   

   

2017年11月16日木曜日

Ruby 独自レイアウトの適用方法

Rubyで、viewに対応する独自レイアウトを用意する場合に必要な設定


layouts -> view name.html.erb を用意する。
レイアウトの中身は、一旦、application.html.erbの内容をコピーし、適応するviewの名前に置き換える


        <!DOCTYPE html>
<html>
<head>
<title>RailsApp</title>
<%= csrf_meta_tags %>

<%= stylesheet_link_tag 'view name', media: 'all', 'data-turbolinks-track': 'reload' %>
<%= javascript_include_tag 'view name', 'data-turbolinks-track': 'reload' %>
</head>

<body>
<%= yield %>
</body>
</html>


assets.rbへコンパイルされるように設定を行う。


Rails.application.config.assets.precompile += %w( view name.css )
Rails.application.config.assets.precompile += %w( view name.js )


コントローラーにも設定
layout 'people'

これらの設定は、Railsサーバーを再起動しないと適用されないため要注意。
Railsサーバー起動時のみに読み込まれる為。





2017年11月13日月曜日

Ruby on Railsのセットアップにハマったからコマンドまとめ

Rubyのサイトには、ダウンロードできる最新のバージョンは、Nov.13.2017時点で、2.4なのだけれども、このバージョンから何やら色々内包されていて本の通りで上手く行かなかったので、2.3をダウンロード。

新しいバージョンでやりたいろころだけれども、Ruby初心者が最初に躓いて進まないと、数をこなす目的が果たせなくなるので、取り敢えず、新しい分は後から吸収するとして、2.3をダウンロード、そしてセットアップ後に、下記のコマンドを、コマンドプロンプトから打つ!

DeveloperKitを、作成されたRuby直下のフォルダーに配置してから、そのフォルダーにCD(チェンジディレクトリ)してから、コマンドを打つ。

  • //初期化
  • ruby dk.rb init
  •  
  • //Install
  • ruby dk.rb install

    //Railsのセットアップ
  • gem install rails

    //バージョン確認
    ruby -v
  • rails -v

    //Sqlite3
    gem install sqlite3


aa

SQLite3で、Webの開発をする事は余り考えられないけれど、取り敢えず、書いてあるとおりに進めていって、一通りやったら、SQL Serverに切り替えてみよう。

Railsを使う場合、データベースが代わっても、コードは変えないで済むらしいので・・・

なんか、その謳い文句は胡散臭いけれど。。。

実は、この場合は、あのライブラリを使って、ちょっとコードを変える必要があるとか出たり・・・は、まぁ覚悟。