投稿

Translate

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

AI-Watsonの記事を読んで思うところ 日本のIT開発関連の職に就くと、非常にStressfulなシチュエーションが多く発生する。 例えば、何が効率の良い方法か、どうした場合に上手く行かないのか等、色々試してみないと分からない状況があった場合。 そこには、成功と失敗が付きまとう。 1回で成功する場合もあるだろうけれども、やはり、やっぱりこうした方がもっと良かったのではないか等が、必ず発生する内容だった場合には・・ これが、一番自分にとってのストレスなのだけれど、日本の企業は作る際に、一番良い結果が必ずあると既にめぼしはついていて、そのように作りたいと議論をするのだけれども、、日本のIT企業は、経営者が非常にITに疎く、取り敢えず、その結果を出すには到底あり得ないような納期を設定してくる。 そうなると、もう、一番良い結果よりも、取り敢えず、何かの結果を出すために、あり得ない程、再利用が不可能なコードとなったり、結果が正しいか正しくないかを考えずに完成させて・・・ 勿論その先に待っている物は、責任の擦り付け合い。 運よく上手く動いているように見えている物でさえ、その時結果が上手く出ているだけで、運用してみたら、あり得ない程の運用でカバーみたいなシステムが仕上がってくる。 毎日、意味不明な運用を押し付けられたり、自分でそれを運用する羽目になった場合、非常に空気が悪くなる。 こういう色々の判断を、AIを使えれば、決断をするという、ストレスが無くなるのではないだろうか。 IBMがAI Watson(ワトソン)を無償で利用できるようにするらしい。 どうすれば良いかのジャッジがAIで出来たら、みんな納得出来るのでは。 AI Watsonで病理判定をさせた時に、ベテランの医師でも気づかないような判断を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に軍配が上がる可能性も排除できない状態に( ノД`

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

日本の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!

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

ネットショップのシステムがやっぱり需要があった 段々ブログをやっている暇もなく、こんなに間が空いたけれど・・・ ネットショップのシステムはやっぱり需要があった。 ネクストエンジンでは、どうしても、色々な事業をしている会社では、物足りないと感じていたところ、とにかく早く売り上げがあがるか試したい企業とは、今回作ったシステムは相性が良かった。 後から、売上が、請求が・・・と問題は出てくるだろうけれど、後から解決可能な物ばかり。 ちょっと別な話・・・・・・・・・・・・ MicrosoftがいよいよUWPに力を注ぎ始めたところ。。。 ある事を思いついて、また、さらに個人でシステムを作り始めてみた。 たぶん、ビジネスプロセスを見てから、やっているから需要がある筈なのだけれども・・・ 軍資金を使って、いよいよ、起業しようか迷うのだけれども・・・・ ひたすら、新しい何かでコーディングする人生を送りたいと思っている自分は、 なかなか踏ん切りがつかない・・・・ やっぱり、業務の自動化は面白いからなぁ・・・ 昔から、ベルトコンベアを見るのが好きで、それを、業務を荷物と見立てて自動化していく。 そして、流れてきたデータがどんどん勝手に自分の考えた仕組みで流れていく。。。 なんか、全てを掌握した感がたまらない快感・・・ 次作るシステムは、やっぱりUWPでやりたいから、そっちだ!

認証テスト

認証テスト

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

イメージ
MVVMパターンのメリットがさっぱりわからない・・ 最近は、WindowsFormsでは無く、WPFで開発をするみたいだけれども・・・ MVVMパターンで開発が主流になってきているみたい。 MVCみたいなやつの、アプリ版みたいな感じなんだけれども・・・ ・・・が、ここまでするメリットがさっぱり分からない。 XAML側のDataBindingの指定で、直接コードの値がバインドされるのは面白いけれど・・ だからなに?って感じ。 コントロールの間にデータ中継される要素が増えて、ただ複雑になって、コード量が増えるだけなんでは? そして、日本の現場で、実際に、デザイナーと、コーダーが分かれて作業されるなんて日が実際に来るのだろうか・・・ MVCですら、実際には、デザイナーと、コーダーが分かれて作業しているなんてみ見たことが無く、実際には、デザインとコーダーが合体している。 デザイナーから、謎な巨大なイラストレーターのAIファイルを渡されるだけで・・ 実際の画像加工もコーダーの人がやっているケースが殆どでは・・!? が、これが、今の主流なのか・・・ 自分は、現場が喜ぶ結果が出来たら、あまり過程にはこだわらない。 今までと同じ表現で良いのに、複雑なプロセスを踏まなきゃいけないなんて・・・ これは、技術の進歩何だろうか?? 何となく、JAVAが人気な理由が分かってきた。 JAVAは、コーディングスタイル自体は大きく変わっておらず、コード量は多い物の、古いエンジニアも現役で戦っていけるくらい、成熟している。 ・・・が、Microsoft系の言語は、.NET Frameworkになってから、コロコロコーディングスタイルが変わって、もはや、どれが標準なのか、さっぱりぱりぱりだ。 結局のところ・・・ すっごく揉めて、こだわって作っても、1年先にはまた新しい手法が登場して、 その時それに拘っているのは、ただのエンジニアの自己満足だと思うのだけれども。。。 技術の進歩は、段々成熟して殆ど変わらないから、自分は、実際に現場の業務効率化で役に立つものだけを作っていたい。。。 言語・・・Python(パイソン)に乗り換えようかな・・・ Winアプリも、Webア

明日から、定形外の郵便料金が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円 380 円 500 円 1kg以内 600円 570 円 700 円 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やトランザクション云々の細かい処理が不要になる・・・ XamarinのDeveloperブログのサイト めちゃくちゃ便利・・・