ファイナルアンラッキー

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

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サーバー起動時のみに読み込まれる為。

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を使う場合、データベースが代わっても、コードは変えないで済むらしいので・・・ なんか、その謳い文句は胡散臭いけれど。。。 実は、この場合は、あのライブラリを使って、ちょっとコードを変える必要があるとか出たり・・・は、まぁ覚悟。

I can't believe it!! Pythonが、C#を超えてしまった・・・・ 自分が、想像するPythonは、一種のCOBOLに置き換わるかもしれない存在で、しかも、アプリも、Webもいけてしまう、Googleが絡んだインタープリター言語。 言語の特徴は、まるで、他の言語と考え方が異なり、これを習得するコストが、長い間エンジニア活動を続けるのにリターンがあるのか謎で、なかなか手を染められない人も多い筈。 COBOLに置き換わるかもしれないと思うのは、統計処理系に強いと言われる所以なのだけれども、正直、この言語も色々なlibraryが乱立しており、どこに終着するかわからないため、選択したライブラリによっては、将来不幸に終わる可能性もある。 取り敢えず、様子見を決めていたのだけれども・・・ Rubyよりも、実は全然将来性があるのだろうか・・・・ Pythonはとにかく、同じことをするのにも色んなライブラリーから、選択する必要があり、それが淘汰されるライブラリーなのかどうかがはっきりしない所がこの言語の入口で立ち往生してしまう原因だ・・・ Googleは、Goだったり、Javaだったり、Pythonだったり、彼らが出てから、言語が乱立しまくって、変に言語のシェア争いに巻き込まれいる気がするのだけれども。 ただ、Microsoftが一番悪いと思うのは、WEBの開発に、イントラネット上では、ユーザー単位でライセンス料金を取っているところだ。 これのせいで、一斉に企業がJAVAや、PHP、Ruby、Pythonに逃げまくった。 マイクロソフトのCEOがサティア・ナデラさんになって、この状況は変わると思ったのだけれども、Visual Studio Communityのライセンス条項が少々オープンじゃ無くなって気がする。 僕もRubyに走り始めた以上、コロコロ目移りすると進まないから、取り敢えず突き進むけれど・・・ なんだか、非常に嫌な予感　( ；∀；)

とにかく、Rubyは、どのIDE（統合開発環境）を使用するのかで迷う 自分は、Visual Studio Codeにプラグインを設定して使用した。 How to add plugin of ruby on Visual Studio Code!! まず、Visual Studio Codeの拡張機能で、Rubyを検索して、下記のRuby Language and Debugging Support for Visual Studio Codeをインストールする。 下記をコマンドプロンプトで入力する。 gem install ruby-debug-ide -v 0.6.0 gem install debase -v 0.2.2.beta1 とりあえず、これで、インテリセンスが使えるようになる。 プログラミング作業で、インテリセンスが使えないと致命的なので、取り敢えず、これはやっておいた方が良い。 このプラグインの説明で上で説明した以外の設定もあるが、今は何のための設定か分からないので、無くても問題無さそうなので、これで進むことにした。 今回買った本で失敗したと思ったのは、Rubyのようなオープンソースライブラリー群に助けられながら開発するオープン言語は、本の通りにやっても動かないことが多いことだ・・ 自分が今回かなり今回買った本でいきなり苦戦したのは、erbと呼ばれるレイアウトの箇所だった。 <%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %> 解決策は、Coffee Scriptのバージョンによるものだったのだが、Coffee Scriptのバージョンを古くしないとエラーが表示されて動作しなかった。。。 Rubyは、色々なライブラリーという名の生命維持装置的な物によって生きている言語だと実感したので若干Microsoftと言う、絶対無くならない的な安心感がない言語を触るのはやっぱりリスクだなーと感じる今日このごろ。 今のとこ