投稿

Translate

インターネットの終焉が近づいている? by change net neutrality.

インタネットの終焉はいづれ来ると、インターネットが登場した時から言われている。 スマートフォンの登場で、ますますWebが必要されると思われたが、結果、スマートフォンでも、WEBは重要だが、アプリが使われる傾向にある。 オンラインで使用するアプリはWEBと同義だと考えられるが・・・ ところで、アメリカでは、オバマ大統領時代に守られてきた、ネットの中立性を撤廃する動きが出ている。 トランプ政権は、何かと、自分に都合の良いように手を加えたがっているが、これもその一環なのだろう。 これは、インターネット時代の終焉に向かう事案なのかもしれない。 キャリアの都合で、ネットが早くつながるサイト、ネットの接続を遅くするサイトをコントロール出来てしまうからだ。 通信は、総務省の規制やコントロールも入る事が多く、これが日本にも浸透した場合、当然、政府の都合の悪いサイトは繋がらないようにしたり等が可能になってくるかもしれない。 まぁ、これは、今考えるには深すぎると思うのだけれども。。 取り敢えず、一番最初に起こりそうな事は、ビジネス上、今はベンチャー企業もネットサービスの提供で、技術力によって、大手と対等に渡り合える土俵が用意されていた訳だけれども・・・ 例えば、キャリアの株を、大手、ソリューションを提供しているITベンダーの手によって・・・ そのベンダーが、例えば、自分達のクラウドサービスを優先的に使えるようにして、他のクラウドサービスは、不利になるように・・・みたいな申し出があったとして・・・ 最初のうちは断るだろうが・・・ロビー活動が進むに連れて、徐々にそうなるように規程を変えていき、いずれは・・ とある、無料でつかえているクラウドサービスは、技術力も世界一だけれども、最近レスポンスが悪いなぁ・・・なんて事が起きることも予想できる。 キャリアが帯域操作をしてそうなっているのか、サービス提供側の問題かはキャリアの都合によって操作されてしまう訳だから、日本のような島国は、あっと言う間に権力者により既得権益拡大な手が回ってしまうよね・・・ そこは、アメリカ政府が日本に圧力を掛けておいて貰いたいなぁ・・・ はっきり言っ

Ruby jQueryが動作していない場合の対処方法 | Ruby: How to fix method when doesn't work jQuery.

Rubyで、下記のように、javascript_include_tag を使用しても jQueryが機能しなかったので、色々調べてみたら、どうやらこれだけでは jQueryに必要なソースファイルが読み込まれていない模様。 Layout   html.erb <!DOCTYPE html> <html> <head> <title>Cards</title> <% csrf_meta_tags %> <%= stylesheet_link_tag 'ajax', 'data-turbolinks-track': 'reload' %> <%= javascript_include_tag 'application', 'data-turbolinks-track': 'reload' %> </head> <body> <div class="card"> <%= yield %> </div> </body> </html> 下記を追加することで、解決した。 <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"><script> 結果、下記のようになった。 <!DOCTYPE html> <html> <head> <title>Cards</title> <% csrf_meta_tags %> <%= stylesheet_link_tag 'ajax', 'data-turbolinks-track': 'reload' %> <!-- /jQueryを読み込む -->

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