投稿

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

Translate

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

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

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

PythonがC#を遂に抜いてしまった・・・ Finally computer language rate 'Python' exceed'c#'.

-
イメージ
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の開発はVisual Studio Codeにプラグインを設定して始めるのが無難

-
イメージ
とにかく、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と言う、絶対無くならない的な安心感がない言語を触るのはやっぱりリスクだなーと感じる今日このごろ。 今のとこ
続きを読む

Ruby始めました。

-
イメージ
Ruby始めました。 PHPにしようか迷ったけれど、以前PHPのプロジェクトやったけれど、それからは自分は、PHPのプロジェクトに関わる縁が無かったから、いっそ新しい言語をやることにした。 Ruｂｙ この言語の特徴を色々読んでみると、とにかくやってみると、どんどん楽しくなる言語という触れ込みだった。 何でも楽しくないと続かないと思ったので、この言語をチョイスしてみました～。 Rubyのダウンロードサイトは下記リンク https://rubyinstaller.org/downloads/ 自分は2.4.2の最新を選んでみました。 Devkitが2.0 to 2.3 と書いてあり、不都合が生じたので、2.2を入れました。。 エディターは、マイクロソフトのVisual Studio Code（無償） https://www.microsoft.com/ja-jp/dev/products/code-vs.aspx 結局、Microsoftからは、完全にはDe-dependent(脱依存）する事は出来ないのだった。。 Ruby言語の感想は、今のところ、パット見た感じは、C# MVCっぽかった。 よく、C＃のMVCは、Rubyをパクっていると言われているけれど、パクっているだけあって、C#のRazorにもそっくり。 もう、マイクロソフトのライセンス呪縛から逃れたいので、Rubyで行く。 取り敢えず、一日100ページをづつ行こう！！ http://amzn.to/2zoRhkx 自分が買った本はコレ。 他の言語が出来るからと行って、背伸びして深い本を買うと、入りのスピードが落ちると厄介なので、勢い良く学んで行ける本をチョイスしましたー！ 2,3日後にこれからやり始める人にどんな感じなのかレポートしたいと思います。
続きを読む

結局、Pythonの本は買わなかった。 Eventually, I don't bought a python book.

-
結局、Pythonの本は買わなかった。 Eventually, I don't bought a python book. Pythonが魔法のように書かれているサイトが多かった。 I often see web site that python is magic! でも、全然違った。 But it is totally different. つまり、簡単に要約すると。 To briefly explain. . . 色々なライブラリーがあって、特にディープラーニング系のライブラリーが豊富だよ。 There's so many library and deep leaning library. でも、ライブラリーのライセンス条項は良く読んで、利用規約をよく理解して使おうねって内容が前フリ・・ 他の言語と何ら変わらんのでは。。。 そんな言語に、お金と時間を費やす価値があるのだろうかと、本屋で立ち読み1時間・・・ 色々なパイソンの本を読んだけれど、開発環境も、本毎に違うのが書いてあった。 この言語は、言語のシェア争いだけでは無く、過去にPHPやJavaでもあった、開発環境のシェア争いの真っ只中でもあるなと思った。。。 インタープリターであるが唯、スピードも犠牲にして、ライブラリーも、フリーであるが故、覚えても、なくなって無駄になるリスクまで背負・・・ と思ったら、ちょっと尻込みしてしまった。。 これを覚えると、必ず仕事が得られるという確証に至らなかったのが、買わなかった一番の要因。 Javaでもそうだが、一番怖いのが、フリーであるが故、セキュリティーの穴をエンジニアサイドで意識しながら塞いで行くリスクが一番やっかい。 日本はセキュリティーにお金を掛ける文化が無く、情報漏えいしたら、その時の責任者の首を切って、はい対策しましたっていうのが多くて、正直、セキュリティーが影響する文に、純粋なフリーの何かを使うのが怖くてできない。。。 過去に自分ではないが、取引先で個人情報の漏洩がTV沙汰になるレベルで起きたから余計にね^^; と言う事で、Pythonは一
続きを読む

iPhoneの顔認証で、本人以外の顔で、認証を突破出来たらしいけれど、予想通り。

-
iPhoneの顔認証で、本人以外の顔で、認証を突破出来たらしいけれど、予想通り。 こーなると思っていた人は多いのでは？ Androidでも、過去に顔認証が流行った時があったけれど・・・ 暗い所で顔を登録すると、他の人の顔でも通ってしまう時があった。 それにしても、何週遅れなんだ・・・iPhone・・・
続きを読む

Pythonのプレッシャーを捨てるために、パイソンを習得する

-
イメージ
Pythonのプレッシャーを捨てるために、パイソンを習得する パイソンのプレッシャーがスゴイ・・・ 結構C#を超える位置に近づいてきた・・・ 何度か、Microsoft系の言語を捨てようとして、サティアナデラさんの方針に感銘を受けて、再びC#を習得したのだけれども・・・ Visual Studio Communityのライセンス方針転換で、やっぱり結局失望させられた今日この頃。。。 でも、何故、他の言語でなくパイソンなのかと言うと、雄一Windowsアプリ（Exeファイル）を普通に出せそうなのが、Pythonだったから。 Javaだと、Jarファイルとかになるし、微妙に遅いし、ファイルの中身みれちゃうし・・・ な変なリスクが多いけれど・・・ Pythonは、Google Driveや、Instagramのようなアプリの実績もあり、あらゆるプラットフォームに対応していて、それでいて、Webも出来る。 今のところGoogleの後ろ盾も会って、C#を超える位置に来たことから、久しぶりに新言語をやってみる事にした。。。 何より、パイソンのプレッシャーが何だか凄くて、今やっておかないと、凄く嫌な予感を感じたから。 嫌な予感はだいたい当たる・・・だから、やってみる事にした。。。 小さな案件を拾って、Pythonで実装してみよう。。 果たして、この言語をやることで、日本で波に乗れるのか・・・ コレばかりは謎だ。。。。
続きを読む

BPOに手を出してみる

-
BPOに手を出してみる フリーエンジアをやると、大体誰でも行き着くこの答え。 システム開発の受注は、短期間でどっと利益を得られるものの、外れな案件に手を出してみると、長く引っ張られることもある。 長く引っ張られると、システム開発は、人が生産する為に、他のそれに手が出せない状況が出る。 一人でやっていると、まさに、致命的になる事もあるので、業務で引き受ける方式を考えてみる。 システム屋が行き着く答えは、大抵、業務のアウトソーシングか、システムの保守になるのだけれども・・・ クラウドが進んでいる状況では、システムの保守へ行くよりも、BPOのような、業務毎取る道を選ぶかな。。。 自分個人でそこに行き着くぐらいだから、きっとこれからこの分野は修羅場になりそうだな・・ それと、内製化の道を進む企業が増えるのだろうか・・・ 内製化は、日本人工減現象上、行き詰まるはずだから、やはりBPOか・・・ また、事務の人を雇うことを考えないと・・・・
続きを読む

Visual Studio Communityのライセンスが不気味すぎる。 I think strange license of Visual Studio Community...

-
イメージ
Visual Studio Communityのライセンスが不気味すぎる。 I think strange license of Visual Studio Community... 微妙に規約が変わっている。 以前は、年商10億以内の企業は、無償で商用利用できるような内容だったと思うが・・・ Expressをダウンロード、インストールしなおして利用するか、Professionalを買わないと、ネットマネジメントシステムが販売出来なくなった(;´･ω･)・・・ Yahooの商品画像と商品データをアップする機能が微妙に人気だった。 運よく、ネットショップモールのノウハウが、商売している企業では、どこでも活かせるスキルだった。 一番は、ネクストエンジンが苦手とする、自社の基幹システムに合わせたカスタマイズが受けている。 そして、いくつか企業とやりとりして分かったのは、仕入れが得意な人が、起業している人が多い事。 仕入れが得意な人が取締になる人が多い模様。 が、仕入れ　＝　コストに敏感であるが故、　Win - Win で取引をして頂けるかどうかが微妙なので、ベンチャー企業にシステムを売る場合、最初に金額から入っておかないと、長いやり取りの末、金額でリジェクトされる。 最近、凄いPOSシステムの仕組みを思いついたのだけれども・・・ 自分で作るのか、作ってもらうのかやや悩む。 投資をしてでも、作ろうか迷っているのが、色々やり取りをしていて、日本の産業の全体を見渡して、ある重要なことに気が付いたから動き始めたのだけれども・・ あとは、多様化した価値観を、広く取り入れる努力をするのか、他の情報を享受して、相手の価値観に変化を与えて取り込むのか・・・ オフショアで開発するか・・・ 微妙にウクライナがいいことが分かった。 通貨の価値が10分の１位。 ・・・が、せめて英語が通じるところを探さなくては・・・
続きを読む

日本企業のシステムリプレースの定番な流れは、　アプリ型 → WEB型 → アプリ型

-
日本企業のシステムリプレースの定番な流れは、　アプリ型 → WEB型 → アプリ型の流れになって来ていることに気がついた。 当たり前かも知れないけれど、スマホでも、WEBで利用している物よりも、特定の使用頻度が多い場合には、アプリインストールして利用する。 アプリの方が、使いやすいからだ。 世の中のシステムのリプレイースも下記のパターンになってきた。 システムのリプレイスサイクルが遅い企業 　「そろそろ、世の中WEBだから、C/Sよりも、WEBのシステムにしよう・・・」 システムのリプレイスサイクルが早い企業 　「WEB版にしたけれど、操作性がやっぱりイマイチだわ、ブラウザのバージョンによって動作が不安定になったりするわ、業務システムはやっぱりアプリ型（C/S）の方にするか・・・」 と、大体このパターン。 使用頻度が高いものは　アプリ型（C/S）、低いものはWEB型の二本立てが良い気がする。 UWPはまさにそこに近いのかもしれない。
続きを読む

SEが増加して、PGが減少していく日本

-
SEが増加して、PGが減少していく日本 最近の現場では恐ろしいことが起き始めていることに気づいた。 基本的に、フルスタックエンジニアを売りにしている自分にとって、当たり前の全行程串刺しで対応を行う事が多いのだけれども、最近、基本PGの現場に行って驚いたのは、SE人員 ＞　PG人員　となっているのだ。 間違いなく昔は SE人員 ＜ PG人員だったので、上手く回っていたのだけれども。 SE人員 ＞ PG人員となっている現場では、そもそも作る人が居ない悲劇が起きている。 ドキュメント作ったけれど、作れる人員が足りない、外に依頼したら高くて、稟議が通らないのような流れも。 IT業界には３Kという言葉がある。 きつい、帰れない、給料が安い 最近では、７Kともいうらしい。 規則が厳しい、休暇がない、化粧がのらない、結婚できない 化粧がのらない、結婚できないは、本人の個人問題なきもするけれど^^; が、SIer絡みの案件を取り扱っているシステム会社では実際にこれはあり得る。 元々、案件の予算が決まっており、下請け下請けとどんどん中間マージンも取られて・・・ となると、利益を出すためには、雇っているエンジニアを、雇用者扱いよりも、個人事業主扱いのような契約に近くしないと、赤になるからだ。 システムインテグレーションに関わっている会社の仕事に関わらない事が重要だと思う。 確実にプログラマーという人達の人口が減っていっている様子を実感。 それにしても、日本は会社ごとに、ほとんど同じ仕事のやりかたなのに、システムが本当にバラバラ過ぎる。 同じシステムの在り方を、色んな作り方で作っている。 小さな島国なんだから、システムの在り方や、仕事のやり方は、何かプラットフォームが有った方が良いのでは無いかと思う今日このごろ。
続きを読む