ファイナルアンラッキー

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

明日から、定形外の郵便料金が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の操作も簡単に。 Xamarinで、EntityFrameworkが使えるみたい。 Javaのエンジニアには恩恵はないけれど、C#で開発する場合、SQLを一切書かずにSQLiteのデータベースも扱えるみたい。 JavaでAndroidのSQLiteを更新する場合、SQL文書いたり、データベースに接続する為の処理を書いたり、バインド変数に値をセットしたり・・・ これだけで、かなり長々書くことになる。 EntityFrameworkでこれをやると、SQLiteのデータベースに更新する位の小規模なデータベースだと、いちいちこれがとても面倒なのだけれども・・・ EntityFrameworkでコードファーストなプログラミングが出来ると、 これも、SQLやトランザクション云々の細かい処理が不要になる・・・ XamarinのDeveloperブログのサイト めちゃくちゃ便利・・・

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は、バグがある！？ いや・・・ただ文字列が間違ってただけでした・・・というオチ。

My silver tooth filling came off.. 今日が誕生日。 Today my birthday. ...まさかの・・・ No way..... 銀歯が取れる・・ My silver tooth filling came off... この状況、このタイミングで・・・ This condition and this timing... つらすぎる・・・ hardship.... ググってみた感じだと、きれいに取れた場合は、そのまま 消毒して、詰めなおして終わりみたいな事が書いてあるけれど。。。 本当なのだろうか・・・ 日曜日もやっている歯科医に突撃するしか無いなぁ・・・