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を使う場合、データベースが代わっても、コードは変えないで済むらしいので・・・

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

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




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に走り始めた以上、コロコロ目移りすると進まないから、取り敢えず突き進むけれど・・・

なんだか、非常に嫌な予感 ( ;∀;)





2017年11月12日日曜日

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


今のところ、流行ってきているらしい噂をよく聞くし、TIOBEでは、そうでも無いけれど、最悪でも無いランクだしと思って、日本人ならやっとこうと思ったのだが・・・


何やら、100ページづつ進むのは、色々な理由で難しそうだなぁ( ;∀;)トホホ











    2017年11月9日木曜日

    Ruby始めました。

    Ruby始めました。


    PHPにしようか迷ったけれど、以前PHPのプロジェクトやったけれど、それからは自分は、PHPのプロジェクトに関わる縁が無かったから、いっそ新しい言語をやることにした。

    Ruby

    この言語の特徴を色々読んでみると、とにかくやってみると、どんどん楽しくなる言語という触れ込みだった。


    何でも楽しくないと続かないと思ったので、この言語をチョイスしてみました~。


    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日後にこれからやり始める人にどんな感じなのかレポートしたいと思います。



    2017年11月7日火曜日

    結局、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は一旦、プレッシャーで無くなったので、辞めておくことにしました。。。


    Javascriptを極めようかと迷ったりもするけれど・・・
    Typescriptが主流と言ったり、一体どれでやれば、安泰なのか謎な世界に突入し始めていて・・・


    ちょっと言語のシェア争いに疲れた・・・・





    2017年11月6日月曜日

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

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


    こーなると思っていた人は多いのでは?


    Androidでも、過去に顔認証が流行った時があったけれど・・・

    暗い所で顔を登録すると、他の人の顔でも通ってしまう時があった。


    それにしても、何週遅れなんだ・・・iPhone・・・





    2017年11月4日土曜日

    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か・・・


    また、事務の人を雇うことを考えないと・・・・









    2017年11月3日金曜日

    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分の1位。


    ・・・が、せめて英語が通じるところを探さなくては・・・





    2017年11月1日水曜日

    日本企業のシステムリプレースの定番な流れは、 アプリ型 → 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業界には3Kという言葉がある。
    きつい、帰れない、給料が安い

    最近では、7Kともいうらしい。
    規則が厳しい、休暇がない、化粧がのらない、結婚できない

    化粧がのらない、結婚できないは、本人の個人問題なきもするけれど^^;

    が、SIer絡みの案件を取り扱っているシステム会社では実際にこれはあり得る。
    元々、案件の予算が決まっており、下請け下請けとどんどん中間マージンも取られて・・・
    となると、利益を出すためには、雇っているエンジニアを、雇用者扱いよりも、個人事業主扱いのような契約に近くしないと、赤になるからだ。

    システムインテグレーションに関わっている会社の仕事に関わらない事が重要だと思う。



    確実にプログラマーという人達の人口が減っていっている様子を実感。


    それにしても、日本は会社ごとに、ほとんど同じ仕事のやりかたなのに、システムが本当にバラバラ過ぎる。


    同じシステムの在り方を、色んな作り方で作っている。


    小さな島国なんだから、システムの在り方や、仕事のやり方は、何かプラットフォームが有った方が良いのでは無いかと思う今日このごろ。



    2017年10月29日日曜日

    AI-WatosonでStressfulは無くせるか!?

    AI-Watsonの記事を読んで思うところ



    日本のIT開発関連の職に就くと、非常にStressfulなシチュエーションが多く発生する。


    例えば、何が効率の良い方法か、どうした場合に上手く行かないのか等、色々試してみないと分からない状況があった場合。


    そこには、成功と失敗が付きまとう。
    1回で成功する場合もあるだろうけれども、やはり、やっぱりこうした方がもっと良かったのではないか等が、必ず発生する内容だった場合には・・

    これが、一番自分にとってのストレスなのだけれど、日本の企業は作る際に、一番良い結果が必ずあると既にめぼしはついていて、そのように作りたいと議論をするのだけれども、、日本のIT企業は、経営者が非常にITに疎く、取り敢えず、その結果を出すには到底あり得ないような納期を設定してくる。


    そうなると、もう、一番良い結果よりも、取り敢えず、何かの結果を出すために、あり得ない程、再利用が不可能なコードとなったり、結果が正しいか正しくないかを考えずに完成させて・・・


    勿論その先に待っている物は、責任の擦り付け合い。
    運よく上手く動いているように見えている物でさえ、その時結果が上手く出ているだけで、運用してみたら、あり得ない程の運用でカバーみたいなシステムが仕上がってくる。


    毎日、意味不明な運用を押し付けられたり、自分でそれを運用する羽目になった場合、非常に空気が悪くなる。


    こういう色々の判断を、AIを使えれば、決断をするという、ストレスが無くなるのではないだろうか。


    IBMがAI Watson(ワトソン)を無償で利用できるようにするらしい。

    どうすれば良いかのジャッジがAIで出来たら、みんな納得出来るのでは。

    AI Watsonで病理判定をさせた時に、ベテランの医師でも気づかないような判断をAIは提案して、それで、とても良い結果と繋がる治療を提供する事が出来た事例があるらしい。


    記事を読んでいる限りでは、これまで蓄積された事象でのサジェストであり、ポテンシャルの予測は、与えられたデータでしかだせないだろうから、人を相手にする商売は、結局AIでは限界があるからそういった部分のストレスを受ける職は、どうやって解決出来るのか今は思いつかないけれど。


    AIをもっと気軽に利用できる時代が到来して欲しい。






    Python(パイソン)はホンモノなのだろうか。

    Python(パイソン)はホンモノなのだろうか?



    このPythonと言う言語が、非常に台頭してきている。

    Google DriveやInstagram(インスタグラム)・・等などは、パイソンで作られているんだぞ・・・と言う触れ込みが多く・・・


    ちょっと参考書を読んでみたのだけれども・・・・


    非常に理解に苦しむ、この言語の良さが・・・・


    基本的に、他の言語と作り方は変わらない。


    この言語の特徴を読むと、大体、、オープンソースで、利用できるモジュールがたくさんあって、機械学習のモジュールも利用出来るっていうのが多い。



    いっときJAVAが同じような触れ込みでシェアを増やしていったけれど、同じような触れ込み。


    正直、どの言語でも、大体同じような事が出来るし、同じような結果になるし・・・言語のシェア争いみたいなのはもう終わってほしいのだけれども・・・


    Pythonで、Windowsアプリを作る際についてまとめると・・・

    無料で開発出来る代わりに、Visual StudioのC#で開発するよりも非効率で、開発準備にもそこそこ手間がかかる・・・とだけ言える。


    が、流行る可能性としては、Microsoftが、営利団体である限り、何をするにもライセンスの名の下に縛ってくる為、それに後から苦しめられるくらいだったら、少々遠回りでも無料で作れる言語で作ろうという人達は増えてくるのだろう・・・




    Visual Studio Communityのライセンス条項も何やら変更されて、以前より、個人が商用で開発をするための縛りを入れてきているし・・・


    Visual Studio Professionalのライセンス料金が1,2万円なら爆発的に、人口が増えると思うのだけれども、7万前後もする。


    今、Pythonは勢いだけの雰囲気だけれども、Microsoftの戦略上、Pythonに軍配が上がる可能性も排除できない状態に( ノД`










    2017年10月26日木曜日

    Windowsアップデートで、JET4.0の動作不良 Error in Windows update KB4041681

    原因は、Oct.10.2017に配信された、Windowsアップデートによるもの。

    Jet4.0はMicrosoft Accessでは、MDBにアクセスする為に使用される標準機能。


    Windows UpdateのKB4041681を適用後、EXCELのVBAでJET4.0を使用して、XLSのファイルに接続しようとすると、ドライバーエラーが表示される。

    かなり古いもので、サポートも切れていると思われるこのJETのバージョンで、Windowsアップデート後に発生したこの事象を、不具合と呼ぶのか、ただ、対応が遅れている企業の自業自得と呼ぶのか・・・

    Jet4.0で接続して、しかも、Xlsタイプのファイルと言う組み合わせは、かなり、対応が出遅れていると思うけれど。


    通常は、ライフサイクルを考えて、システムのリプレイスを見定めると思うのだけれども、止まって困るまでRunningみたいな考え方が、日本人には多すぎるな。。


    先進国で一番ITリテラシーが低いと言われるだけの事はある。。。


    システムリプレイスのサイクルを、システムが止まるまでと考えているエンジニアが意外と多い現れなのかも知れない。


    VBA使いすぎも、Officeのバージョンに左右され過ぎて危険だと思うのだけれども・・・



    もういい加減VB6からは、縁を切りたいのだけれども、、このプロジェクトはあと少しだから、何とか無難にやり過ごそう。


    C#でメール送信のサンプル: For example Send mail by C# with encoding japanese


    C# メール送信用 ブログで今日使用する予定のプログラムを貼っておけば、
    今日の仕事がコピペで一瞬で片付くという必殺技。

    早く終わったら、早く帰られる制度もほしなぁ・・・


            public void SendMailMessage(String Host,
                                        Int32 Port,
                                        String FromAddress,
                                        String[] MailAddress,
                                        String UserName,
                                        String Subject,
                                        String Body)
            {

                System.Net.Mail.SmtpClient client = new System.Net.Mail.SmtpClient(Host, Port);

                String strPass = "Password";

                client.Credentials = new System.Net.NetworkCredential(UserName, strPass);

                System.Net.Mail.MailMessage message = new System.Net.Mail.MailMessage();

                message.From = new System.Net.Mail.MailAddress(FromAddress);    

                //To
                string[] ToAddress = MailAddress;
                for (Int32 idxToAddress = 0; idxToAddress <= ToAddress.Length - 1; idxToAddress++)
                {
                    message.To.Add(ToAddress[idxToAddress]);
                }

                //Subject
                Byte[] ByteSubject = System.Text.ASCIIEncoding.GetEncoding("iso-2022-jp").GetBytes(Subject);
                message.Subject = "=?iso-2022-jp?B?" + Convert.ToBase64String(ByteSubject) + "?=";

                message.Body = Body;
                message.BodyEncoding = System.Text.Encoding.GetEncoding("iso-2022-jp");

                message.Headers.Add("X-Mailer", "SomethingSystem");

                client.Timeout = 360000;
                client.Send(message);


    とっとと仕事をかたずけて、今日は早く帰る・・・

    2017年10月12日木曜日

    日本のPGが直面する生贄フラグとは About programmer face the victim flag in japan.

    PGが直面する絶望フラグとは。

    PG(プログラミング)が出来ないタイプのPMやSEが、ブラックボックスをブラックボックスなまま解析せずに投げてくる事である。

    Japanese people is  haven't programming ability skill even PM(Project manager) SE(System Engineer).
    They are just said please developing system.

    生贄フラグが立った場合、PM、SEは、責任をPGに擦り付ける気満々なので、長くかかわらない様に短期で引き上げる事が重要である。

    I'm involved that project for first time in a while.
    I think don't need that role type engineer.

    Will you?



    久々に、立場がPGみたいな案件に関わったが・・・
    お客の言っている事をただ繰り返すやってる振りするは、必要ないのでは?

    I'm call a victim flag that situation.
    Anyway need hurry escape escape!




    2017年10月1日日曜日

    ネットショップのシステムがやっぱり需要があった

    ネットショップのシステムがやっぱり需要があった

    段々ブログをやっている暇もなく、こんなに間が空いたけれど・・・


    ネットショップのシステムはやっぱり需要があった。


    ネクストエンジンでは、どうしても、色々な事業をしている会社では、物足りないと感じていたところ、とにかく早く売り上げがあがるか試したい企業とは、今回作ったシステムは相性が良かった。


    後から、売上が、請求が・・・と問題は出てくるだろうけれど、後から解決可能な物ばかり。


    ちょっと別な話・・・・・・・・・・・・


    MicrosoftがいよいよUWPに力を注ぎ始めたところ。。。
    ある事を思いついて、また、さらに個人でシステムを作り始めてみた。


    たぶん、ビジネスプロセスを見てから、やっているから需要がある筈なのだけれども・・・

    軍資金を使って、いよいよ、起業しようか迷うのだけれども・・・・
    ひたすら、新しい何かでコーディングする人生を送りたいと思っている自分は、
    なかなか踏ん切りがつかない・・・・


    やっぱり、業務の自動化は面白いからなぁ・・・

    昔から、ベルトコンベアを見るのが好きで、それを、業務を荷物と見立てて自動化していく。


    そして、流れてきたデータがどんどん勝手に自分の考えた仕組みで流れていく。。。


    なんか、全てを掌握した感がたまらない快感・・・


    次作るシステムは、やっぱりUWPでやりたいから、そっちだ!



    2017年6月16日金曜日

    MVVMパターンのメリットがさっぱりわからない・・

    MVVMパターンのメリットがさっぱりわからない・・


    最近は、WindowsFormsでは無く、WPFで開発をするみたいだけれども・・・


    MVVMパターンで開発が主流になってきているみたい。


    MVCみたいなやつの、アプリ版みたいな感じなんだけれども・・・


    ・・・が、ここまでするメリットがさっぱり分からない。


    XAML側のDataBindingの指定で、直接コードの値がバインドされるのは面白いけれど・・
    だからなに?って感じ。

    コントロールの間にデータ中継される要素が増えて、ただ複雑になって、コード量が増えるだけなんでは?

    そして、日本の現場で、実際に、デザイナーと、コーダーが分かれて作業されるなんて日が実際に来るのだろうか・・・

    MVCですら、実際には、デザイナーと、コーダーが分かれて作業しているなんてみ見たことが無く、実際には、デザインとコーダーが合体している。

    デザイナーから、謎な巨大なイラストレーターのAIファイルを渡されるだけで・・
    実際の画像加工もコーダーの人がやっているケースが殆どでは・・!?

    が、これが、今の主流なのか・・・

    自分は、現場が喜ぶ結果が出来たら、あまり過程にはこだわらない。
    今までと同じ表現で良いのに、複雑なプロセスを踏まなきゃいけないなんて・・・

    これは、技術の進歩何だろうか??


    何となく、JAVAが人気な理由が分かってきた。
    JAVAは、コーディングスタイル自体は大きく変わっておらず、コード量は多い物の、古いエンジニアも現役で戦っていけるくらい、成熟している。

    ・・・が、Microsoft系の言語は、.NET Frameworkになってから、コロコロコーディングスタイルが変わって、もはや、どれが標準なのか、さっぱりぱりぱりだ。

    結局のところ・・・

    すっごく揉めて、こだわって作っても、1年先にはまた新しい手法が登場して、
    その時それに拘っているのは、ただのエンジニアの自己満足だと思うのだけれども。。。


    技術の進歩は、段々成熟して殆ど変わらないから、自分は、実際に現場の業務効率化で役に立つものだけを作っていたい。。。


    言語・・・Python(パイソン)に乗り換えようかな・・・
    Winアプリも、Webアプリも、AI学習も人工知能も何でもありで、Googleも使っている言語のようだし・・・




    因みに、Pythonは、TIOBEではかなり順位をあげて、一気に、4位の言語へ・・・!!



    最近、なんか、言語が多様化しすぎて意味不明な状態だから、業務を効率化させるためのプロデューサーみたいな感じな事が出来ないか模索中。

    今は、殆ど自営状態で、営業も、エンジニアも、経理も全部ひとり状態でしんどい(^^;
    このまま続けて、黒字になるのか、赤字になるのか等、不安すら持っていられない程、激務な状態だし・・・

    顧客がもっと取れれば良いのだけれども、自分で営業してみて、日本の企業が、システムに対する価値(相場)が余りにも低すぎてビックリだ・・・


    日本の場合、大きなプロジェクトは、大手ゼネコンの餌にありついているだけみたいな構図で、中の人で出来ない難しいことだけ作らされて、後はソース渡して、はい、さようなら みたいなのが起きることがまた目に見えているから、どうしてもやりたくなくて・・・・


    やっぱり、どっかのメーカーな会社員になれないか、検討中。。。

    業務効率化や自動化がやっぱり面白くて好きだからそういうのやりたいなぁ・・。
    お金のある会社で・・(^^;

    お金のない会社ではもうやりたくないなぁ(;´・ω・) ジリ貧になる





    2017年5月31日水曜日

    明日から、定形外の郵便料金が80円~150円値上げされる

    明日から、定形外の郵便料金が80円~150円値上げされる



    凄い値上げだ・・・
    そして、何気に郵便はがきの料金も。62円に値上げされる。
    重量現行料金2017年6月1日からの新料金
    規格内規格外
    50g以内120円120円200
    100g以内140円140円220
    150g以内205円205円290
    250g以内250円250円340
    500g以内400円380500
    1kg以内600円570700
    2kg以内870円取り扱いません1,020
    4kg以内1,180円1,330
    アベノミクス・・・・ただの値上げラッシュな経済政策。

    麻生大臣の振る舞い、発言を見ていると、景気は回復済みだから、消費税上げる的な勢いなようだし。


    来年の日本経済は、リーマンショック急な倒産ラッシュが起きそうだな・・・
    しかも、外的要因ではなく、内的な政策によって。

    外のせいにしたがるけれど・・・


    C#言語だと、Androidの開発でもENtityFrameworkが使えて,SQLiteの操作も簡単に。

    C#言語だと、Androidの開発でもENtityFrameworkが使えて,SQLiteの操作も簡単に。





    Xamarinで、EntityFrameworkが使えるみたい。

    Javaのエンジニアには恩恵はないけれど、C#で開発する場合、SQLを一切書かずにSQLiteのデータベースも扱えるみたい。

    JavaでAndroidのSQLiteを更新する場合、SQL文書いたり、データベースに接続する為の処理を書いたり、バインド変数に値をセットしたり・・・

    これだけで、かなり長々書くことになる。

    EntityFrameworkでこれをやると、SQLiteのデータベースに更新する位の小規模なデータベースだと、いちいちこれがとても面倒なのだけれども・・・

    EntityFrameworkでコードファーストなプログラミングが出来ると、
    これも、SQLやトランザクション云々の細かい処理が不要になる・・・




    めちゃくちゃ便利・・・



    2017年5月30日火曜日

    EntityFrameworkの接続文字列渡しで謎な現象・・・

    EntityFrameworkの接続文字列渡しで謎な現象・・・



    接続文字列を変数で渡して、Linqを実行すると、

    System.Data.Entity.Core.EntityException: '基になるプロバイダーが Open で失敗しました。'

    となる。

    でも、m_ConnectionStringに設定された文字を直接代入すると、正常にデータ取得できる。




    MYSystem.Database.Connection.ConnectionString = m_ConnectionString;
    //MYSystem.Database.Connection.ConnectionString = "data source=MR4000\\SQLEXPRESS;initial catalog=MYSystem;persist security info=True;user id=MYSystem;MultipleActiveResultSets=True;App=EntityFramework;password=asdfgh+9;";

    var Purge = MYSystem.M_PurgerCommodity.Where(x => x.PurgeCategory == "Rakuten").ToArray();


    EntityFrameworkは、バグがある!?



    2017年5月28日日曜日

    My silver tooth filling came off..

    My silver tooth filling came off..




    今日が誕生日。
    Today my birthday.


    ...まさかの・・・
    No way.....



    銀歯が取れる・・
    My silver tooth filling came off...


    この状況、このタイミングで・・・
    This condition and this timing...



    つらすぎる・・・
    hardship....


    ググってみた感じだと、きれいに取れた場合は、そのまま
    消毒して、詰めなおして終わりみたいな事が書いてあるけれど。。。

    本当なのだろうか・・・


    日曜日もやっている歯科医に突撃するしか無いなぁ・・・




    2017年5月25日木曜日

    MVNOでmineoが顧客満足度1位に!mineo selected satisfaction 1st on MVNO.

    MVNOでmineoが顧客満足度1位に!mineo selected satisfaction 1st on MVNO.




    Monthly cost
    As is : 8,000 yen
    To be : 1,500 yen!!!


    昔、一番にCDMA回線を始めただけあって、通信がとても安定しているAUの回線を使用するmineoが1位に!!


    自分も、mineoの広告を始めてみた当初、これだ!!と思い、速攻契約!!


    月々の費用が1,500程度になってびっくり!!!


    もしも、NTT,AU、Softbank等契約されていたら、違約金払ってでも、解約して乗り換えた方が絶対得!!!



    mineoは関電がやっているサービスだから、
    もちろん、適当なサービスはしていません!

    もしも、今の料金が高くて乗り換えたい人は、ココをクリックして、検討してみて下さい!

    こんな、意味なく通信費に何千円、何万円も払っているのは、あまりにも勿体ない!

    2017年5月18日木曜日

    Trump 大統領がいない方が、逆に円安!??Can't reading Trump regime nobody..

    Trump 大統領がいない方が、逆に円安!??


    誰も読めない、トランプ政権。
    Can't reading Trump regime nobody..

    トランプ大統領が居ない方が、円安なのか、居たほうが円安なのか・・・


    むしろ、彼の行動は誰も読めない。



    が、日本は、向こうの国の事を気にしている暇が無いぐらいの不景気。


    今回の、大手企業の決算発表で、相次ぐ赤字。


    あの日本郵政ですら巨額の赤字。


    お国がする事業はひたすら赤字を生む。。。

    そろそろ、大手企業のこういうのは、罰則性にしないと、ひたすら、自分たちの責任逃れ
    で、関係のないトカゲのしっぽ切りで現場に責任を押し付ける。

    つまり、国民に責任を押し付けるこれは、罰則で取り締まる必要があると思う。



    天下りや、利権を守るだけの事業は、そろそろ本気で事業整理と、責任者を罰則で厳しく取り締まる必要があると思う。


    その点、汚職は多いものの、韓国は相手が誰でも割としっかり取り締まっているように見える。
    お金持ちには甘いけれど・・・・


    まぁ・・・日本も同じ。



    2017年5月7日日曜日

    TopValueのカレーが50円とは思えないおいしさ。

    TopValueのカレーが50円とは思えないおいしさ。




    50円。50 yen.


    とにかく安い。

    しかも、ファミレスで食べるカレーと同じくらいおいしい。

    最強、コストパフォーマンスのトップバリューのカレー。

    夏だから温めなくても十分食べられるから、このレトルトと、ご飯だけ持っていったら、おひるごはん代が50円で済む素晴らしさ!!


    いつもお昼の外食で500円以上使っている人は、1/10に食事代が抑えられる素晴らしい商品!!



    イオンは、他にもプライベートブランドで冷凍のお弁当シリーズのReadyMeelとか色々だしていて、これから増税の時代には物凄く最強の強い味方だと思う。

    昔のトップバリュー製品の食品はおいしくなかったけれど、最近のは、レストランと引けを取らないおいしさになっているから、是非、このカレーもお勧めしたい一品!


    イオンオタクとしては、ますます
    やっぱりイオンは最高だと思ったよ。。




    2017年5月5日金曜日

    MVCでデフォルト_shared/_Layout.cshtmlのレイアウトから別のレイアウトに切り替える方法

    MVCでデフォルト_shared/_Layout.cshtmlのレイアウトから別のレイアウトに切り替える方法


    _ViewStart.cshtmlで切り替える


    @{

        var CallController = HttpContext.Current.Request.RequestContext.RouteData.Values["Controller"].ToString();

        string layout = string.Empty;

        if (CallController == "Login")
        {
            Layout = "~/Views/Shared/blank/blank.cshtml";
        }
        else
        {
            Layout = "~/Views/Shared/_Layout.cshtml";
        }
    }



    MVC5になってから、色々また規則が変わってしまったなぁ・・・


    これはこれで便利なんだけれども、こうコロコロやり方が変わるのはマジでキツイ。

    さらに、今までは、こんな処理不要だったのに、突然必要になったり、逆に開発工数が増えるんじゃ・・・・・

    マイクロソフト・・・いい加減にしろよと思う。






    2017年5月3日水曜日

    WPF+EntityFrameworkで簡単にログを残すソースの公開 -

    WPF+EntityFrameworkで簡単にログを残すソースの公開 
    How to use to PutActionLog on  WPF + EntityFramework

    EntityFrameworkなら、ソースからデータベースの作成、テーブルの作成が自動で行えるので、下記のソースさえコピペして貰えれば、データベースが、Postgresだろうが、SqlServerだろうが、Oracleだろうが自動的に全部使えるようになると思います。

    DataAccess.PutActionLogにて、IPアドレス、コンピュータ名等モロモロと、引数で渡した情報を+アルファを記録しています。


    ActionLog.cs  モデル(Model)
        using System;
        using System.Collections.Generic;
        
        public partial class ActionLog
        {
            public int ActionLogID { get; set; }
            public string SystemName { get; set; }
            public string SystemVersion { get; set; }
            public string IpAddress { get; set; }
            public string TerminalID { get; set; }
            public string UserID { get; set; }
            public string FunctionName { get; set; }
            public string Condition { get; set; }
            public string ErrorText { get; set; }
            public Nullable<System.DateTime> CreateDate { get; set; }
            public Nullable<System.DateTime> UpdateDate { get; set; }
            public string Property1 { get; set; }
        }


    context:コンテキスト
        using System;
        using System.Data.Entity;
        using System.Data.Entity.Infrastructure;
     
        public partial class MYSystemEntities : DbContext
        {
            public MYSystemEntities()
                : base("name=MYSystemEntities")
            {
            }
     
            protected override void OnModelCreating(DbModelBuilder modelBuilder)
            {
                throw new UnintentionalCodeFirstException();
            }
     
            public virtual DbSet<ActionLog> ActionLogs { get; set; }
        }

    DataAccess.cs
            public void PutActionLog(String LoginUser, String strFunctionName, String strCondition)
            {

                using (var context = new MYSystemEntities())
                {

                    System.Net.IPAddress ipaddres = null;
                    System.Net.IPHostEntry ipHostEntry = System.Net.Dns.GetHostEntry(System.Net.Dns.GetHostName());

                    foreach (System.Net.IPAddress ipAddr in ipHostEntry.AddressList)
                    {
                        if (ipAddr.AddressFamily == System.Net.Sockets.AddressFamily.InterNetwork)
                        {
                            ipaddres = ipAddr;
                            break;
                        }
                    }

                    context.ActionLogs.Add(new ActionLog
                    {
                        SystemName = System.Windows.Application.ResourceAssembly.GetName().Name,
                        SystemVersion = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.ToString(),
                        IpAddress = ipaddres.ToString(),
                        TerminalID = System.Net.Dns.GetHostName(),
                        FunctionName = strFunctionName,
                        Condition = strCondition,
                        UserID = LoginUser,
                        UpdateDate = DateTime.Now,
                        CreateDate = DateTime.Now
                    });

                    context.SaveChanges();
                }

            }



    Thank you for Reading



    WPF Doeventの実装方法

    WPF Doeventの実装方法




    WPFはWindows.formsのように、Doeventsが用意されていない為、自分で実装する必要がある。

    基本的にマイクロソフトのヘルプにサンプルがあるので、それをコピペで使用するだけなのだけれども、毎回探すのも不便なので、自分のブログに準備してみた。


            #region "DoEvents"
            private void DoEvents()
            {
                DispatcherFrame frame = new DispatcherFrame();
                var callback = new DispatcherOperationCallback(ExitFrames);
                Dispatcher.CurrentDispatcher.BeginInvoke(DispatcherPriority.Background, callback, frame);
                Dispatcher.PushFrame(frame);
            }
            private object ExitFrames(object obj)
            {
                ((DispatcherFrame)obj).Continue = false;
                return null;
            }
            #endregion 


    コピペするだけで使えます。
    どうぞどうぞ。


    WPF-XAMLでGridに複数のボタンを配置する方法

    WPF-XAMLでGridに複数のボタンを配置する方法



    Windows.Frormsをやっているエンジニアは、まず、WPFでコントロールを画面上にペタペタ貼っていくだけで躓くと思う。

    Androidエンジニアは、XAMLと同じレイアウトをXMLでやっているから問題ないと思うけれど。。


    WPFのGridに複数のボタンを貼る方法をご紹介

    Code.
                    <Grid Margin="0,18,0,2">
                        <StackPanel Orientation="Horizontal">
                            <Button Name="btnRakutenToNextEngine" Content="楽天→ネクストエンジン" HorizontalAlignment="Left" VerticalAlignment="Top" Width="237" Height="51" FontSize="18" BorderBrush="#FF707070" Background="#FFFBFBFB" Click="CsvFind_Click" Margin="25,10,0,0" />
                            <Button Name="btnRakutenToWowma" Content="楽天→Wowma(DeNA)" HorizontalAlignment="Left" VerticalAlignment="Top" Width="237" Height="51" FontSize="18" BorderBrush="#FF707070" Background="#FFFBFBFB" Click="CsvFind_Click" Margin="25,10,0,0" />
                        </StackPanel>
                    </Grid>


    Result follow.

    XAMLは、ボタンの中にボタンをデザインしたり、Windows.Formsと違って自由な変わりに、Android(アンドロイド)と同じようなルールがあるから、純粋なレガシーなWindowsエンジニアには敷居が高い世界かもしれない。


    日本の大手Sierが昨今、技術的に後れを取っているのは、昔ながらのスタイルを捨てきれないかららしく、Javascriptすらまともにコーディング出来ないエンジニアが多いみたい。


    在宅ワークなら、新しい技術を周りに合わせずに使っていいから凄く自由で高度なエンジニアになれる!!


    今は、事務の人しか募集していないけれど、興味があれば、右下の

    何かリクエストがあれば:Please request to me

    からお問い合わせください!!


    完全在宅なので、縛られない為、どこでも自由に仕事できます!!









    My photo get over 2.5 million view on Google Map. グーグルマップで自分の撮った写真が250万回閲覧されました!

    My photo get over 2.5 million view on Google Map. グーグルマップで自分の撮った写真が250万回閲覧されました!









    何だかうれしい。
    I'm so happy.



    ・・・が、Googleからは何ももらえない。
    ..., but I can not get anything from Google.


    。。。。


    。。。。


    ( ノД`)シクシク…




    2017年4月30日日曜日

    EntityFrameworkの登場で、SQLを覚えなくても良くなったのか!?


    EntityFrameworkの登場で、SQLを覚えなくても良くなったのか!?

    SQLを一切使わずにデータ取得できる。

    基本的は、データセットとあまり変わらないが、LINQをつかってSQLを発行するところがデータセットと異なるところ。


    LINQを覚えるのかSQL知ってるから、そっちのが早いし速いって思うけれど、時代の流れ的にLINQをバシバシ使う時代になっているようだから、LINQでやるか。


    一体同じことをする為に、何回やり方を変えさせるんだろうか・・・・・


    因みにEntityFrameworkのコードファーストで取り掛かった場合、データベースやテーブルすらも自動的に作られていく。。。


    もはやデータベースエンジニアが必要なくなってきたなぁ。。。。

    因みにテーブルがあれば、下のModelクラスは全部勝手に生成される。

    プログラムが全く必要ない世界。

    自分には違和感だらけだけれども・・・



    MYSystem.Context.cs
        public partial class MYSystemEntities : DbContext
        {
            public MYSystemEntities()
                : base("name=MYSystemEntities")
            {
            }
     
            protected override void OnModelCreating(DbModelBuilder modelBuilder)
            {
                throw new UnintentionalCodeFirstException();
            }
     
            public virtual DbSet<M_PurgerCommodity> M_PurgerCommodity { get; set; }
        }

    M_PurgerCommodity.cs
    public partial class M_PurgerCommodity
    {
            public long PuageID { get; set; }         public string PurgeCategory { get; set; }
            public string PurgeCommodityCode { get; set; }
            public Nullable<System.DateTime> UpdateDate { get; set; }
            public string UpdateUser { get; set; }
            public Nullable<System.DateTime> CreateDate { get; set; }
            public string CreateUser { get; set; } }


    実行
    LINQでデータ取得しています。
                var MYSystem = new MYSystemEntities();

                var Purge = MYSystem.M_PurgerCommodity.Where(x => x.PurgeCategory == "Rakuten").ToArray();




    2017年4月29日土曜日

    スマホ料金月8,000円が月1,700円に!解約してでも乗り換えたほうがいい! Smart phone fee Month 8,000 yen → 1,700 yen a month! It is better to change career even if you cancellation your current contract . in japan.

    スマホの契約料金見直しの依頼がどんどん入ってくる


    一般の人は、良くわからないから、やっぱりドコモ、AU、ソフトバンクの普通の高い契約プランに入っている人が多いみたい。


    1台1カ月8000円も費用をかけている!!


    それって、結局2年間で20万円近くも捨てている!!!

    1万円くらいの解約料払ってでも、絶対MVNOに乗り換えた方がいいと思う。

    MVNOなら、キャリアと同じプランでも一か月1700円前後。




    下のリンクから契約してくれたら、5/9迄なら、mineoでキャンペーンやっているので、サポートします!!
    http://mineo.jp/syokai/?jrp=syokai&kyb=T1W2C5X1F2

    契約前に、右下の「

    何かリクエストがあれば:Please request to me」

    から、連絡ください。


    ではでは。


    2017年4月27日木曜日

    EntityFrameworkも、DataSetも好きじゃないけれど、周りに合わせるか・・・

    EntityFrameworkも、DataSetも好きじゃないけれど、周りに合わせるか・・・



    はっきり言って、どっちも好きじゃない。

    結局、パフォーマンスが遅いってなって、結局SQLで作ったり、、最終的には

    「ストアドプロシージャでやった方がやっぱり早いですよ」

    と、設計の時には沈黙していた奴が、突然こんな事を言い出すのは良くある事。



    実はみんなそう思ってる。


    っが、日本のプログラムを良く知らない設計役なエンジニアは、しったかで
    「時代の流れだから、EntityFrameworkでLink」を使ってやろうと言う。




    実際は、パフォーマンスで物凄い差が出る。


    開発時は特に気にならないけれど、本番運用で、データ件数が数千万件、数億件となってくると、途端に凄まじく遅くなったり、タイムアウトに悩まされて作り直す羽目になる。


    お金持ちプロジェクトなら、サーバーを良いのにすれば良いだけだけれども、日本の企業はさほどITに価値を感じずお金をかけない体質だから、失敗する。




    そして揉める。





    っが、自分も周りに合わせないといけないから、EntityFrameworkでやるしかないようなぁ・・・・


    便利なのは分かるけれど・・・段々プログラマーって要らないレベルな世界に突入してきたなぁ・・・


    エンジニアに活路があるのは、今のところJavascriptなのかも知れない。


    こっちは、開発環境がこれって決まってないところがあって、Jquery以外はあまり進んでいないから。







    【楽天GOLD】楽天ゴールド契約時のサイト編集方法

    【楽天GOLD】楽天ゴールド契約時のサイト編集方法



    ↓FireFoxのダウンロード

    https://www.mozilla.org/ja/firefox/new/



    ↓Visual Studio Communityのダウンロード

    https://www.visualstudio.com/ja/downloads/



    2017年4月26日水曜日

    楽天ゴールド FTP接続間連備忘録 | Memorundam for rakuten gold ftp connection

    楽天ゴールド FTP接続間連備忘録 | Memorundam for rakuten gold ftp connection


    楽天GOLDのサイト接続用のFTP設定は基本的に下記となります。

    Access point:ftp.rakuten.ne.jp
    Port:16910


    ポートが通常の21→16910になっている事がポイント


    通常のFTP接続で繋がらないつながらないって焦った場合は、ポート番号が変わっていることを思い出すと、ハマらなくて済みます。


    2017年4月22日土曜日

    WPF(XAML)での開発が主流になっているので、Formsは完全に捨ててみた

    WPF(XAML)での開発が主流になっているので、Formsは完全に捨ててみた

    Photoshopみたいに、デザインが出来る。

    どちらかというと、Android(アンドロイド)の開発ににたスタイルだけれども。


    Windows Universal アプリケーション方式の開発が増えていっているので、XAMLからは逃れられないので、Windows.Formsスタイルは捨ててみた。


    Android開発をやった事がある人ならとっつきやすいかも。

    言語もC#を選べば、あまりJavaと変わらないし。



    ただ、Windows.Formsでやっている人には悲報が。

    プログラミングのスタイルが全く今までと違うから。

    同じコントロールでもコーディング方法も違って・・・ 


    自分はこっちが好き。

    見た目はとても重要だから。