ファイナルアンラッキー

最近、ちょっとネガティブネタばかりなんだけれども・・・ 久々に吉野家へ行った。 やっぱり月曜日の晩御飯を作って、食器を洗うなんて工程は、しんどくて無理。 とにかく月曜日は体がなんかだるい・・・ 月曜日は1週間のうちで一番忙しいイメージがある。。。 ところで、吉野家の豚丼が新しくなったのを知っていますか？ その名も 「新味豚丼」 なんか・・・肉がすかすか・・・ すかすかすか過ぎる・・・ しかも、、味が濃くなった・・・ オイラ～がおもうに、肉を少なくした分、味を濃くしてごまかしているだけなんじゃないかと思う・・・ もはや豚丼というより、タレ丼。 吉野家もついに悪い方向へ走り始めたな・・・・

昨日スシローへ行った。  専門店に負けないラーメンがあるとかなんとか聞いたから。 I went 'Sushiro' because i heard thare is serves best taste noodle at 'Sushiro' more than other restaurant. 普通に不味かった。 But best worst taste.. イオンのインスタントラーメン　とんこつ味のほうが全然美味しい。 'Aeon Top Value' of noodle is best taste more than 'Sushiro ramen' in my view. (ramen means noodle) Advertise of Sushiro. I was served noodle. 騙された。 I was fooled by Sushiro. 以上 That's all.

Bookwalker。 電子書籍サービスは、BookWalkerから入った。 自分が一番重視した点は、PCで快適に電子書籍が読めるかどうかだったからだ。 スマホやタブレットで見た方が良いのでは？と意見もあるだろうが。 もちろん、過去には選択肢としてあったが、今は無い。 今の、スマートフォンやタブレットは、バッテリーが内蔵されてしまっており、バッテリーの寿命を向かえると、端末毎買い換えなければならない。 いわば、使い捨てパソコン的な地位になったと自分では考えているからだ・・ それにしても、BookWalkerは快適だった。 特にPC版アプリで読めるのが良かった。 他の電子書籍サービスはPCはブラウザーを利用してWEB版のビューアで・・・とあるが・・・ 使いにくすぎる。 毎回読み込むは・・・通信の安定次第で、きちんと読み込まれないは・・・ 結局のところよく使うものは、WEBブラウザーで利用するよりも、アプリで利用できた方が全然快適なのだ・・・ だけど、ココに来て、日本の電子書籍サービスについて改めて考えさせられた。 ここにきて考えさせられたのではなく、こうなる気もしながら利用していて考えさせられたのだ。 元々、日本のサービスって、同じサービスが続かないことが多い。 そして、長年利用してきてこの仕打・・・・ ブックウォーカーがPC版アプリを終了させてしまった。 ＞PCビューアアプリに関しましては、現在提供中の最終版アプリを持って最終バージョンとさせて頂きます。 とあるのだ。 https://bookwalker.jp/info/pcviewer999/ 個人的には許せないが・・・ あの時、Amazonのキンドルを選んでいればと凄く後悔した。 Amazonのキンドル電子書籍も、Kindle Fireを使用しないと快適に使えないかもと警戒して、PC版が唯一まともに提供されていたBookWalkerを利用してきたのだが・・・ここにきて・・・ エンジニアたる自分は、当然ながら参考書を結構買っていた。。。 電子書籍みたいな大きな本は、はっきり言って、スマホやタブレット

WEBシステムとC/Sシステムで考え方の違いは、勿論、サーバーとクライアント、どちらに負荷がかかるかだ。 WEBシステムの場合は、当然WEBサーバーに全て負荷がかかる。 アプリ型のC/Sの場合は、各パソコンと、サーバーとで負荷が分散される。 そして、WEBがブームだという理由だけで、WEBシステムの構築プロジェクトを立ち上げる企業がちょこちょこいる。 そして、WEBサーバーが高いので、それをケチる。 結果、トンデモなく遅い不安定なシステムが完成する。。。。 謎だ・・・ 何が目的でWEBシステムを選ぶのか。 ブームと言うだけでWEBを選ぶ。 ちなみに、実際には、スマートフォンでも、WEBよりも、アプリをダウンロードして、アプリで操作する方が選ばれている。 そういう事実は何故か見ない・・・ 不思議だ。。。

糞が付くくらい無駄な説明ばかりで、しかも高い。 さらに、無駄に説明が長いが、内容が薄すぎるし、かなりどうでも良い内容。 簡単に言うと、C#や概念は知っているが、まるで、WEBが苦手な人が書いた本みたいだ・・・ プログラムが書けないSEが、理屈だけで説明しているような、無意味に分厚く、説明が薄い・・または、説明が当時しか役に立たない本。 印税的な関係で値段をかさ上げしたかっただけなのでは？ しかも、作って覚えるのではなく、ただソースをダウンロードして読むだけ・・・ それを読んだ所で、実際にプログラムは入力しながらじゃないと学習できないと思うのだが・・ しかも、この本が出た当初しか通用しないような内容も多く、もっと汎用的に解説できなかったのだろうか・・・ この本に書いてある内容は、この本が出版された2,3ヶ月以内しか使えない内容だと思う。 しかも、この本のスタイルはあくまでサンプルソースを読んで、それの解説が書いてあるだけ。 正直その程度の説明は無くても問題ないと思うのだが・・・ つまらん小説を読んでいるに等しい内容だった・・・ 絶対オススメしないC# MVCの本は、この ASP.C# MVC 5の本で決まり。 内容が薄い、なのに、本が分厚い。 書く必要のない無駄な解説ばかり。 Amazonのコメントにもあったが、この本で☆5を付ける人の気が知れない・・・ ちなみに、HTMLやJavascript、Bootstrapのレスポンシブデザインについても、薄く触れてる程度で、MVC5でどう活用するのかがほぼ書いていない。 C#が出来る人なら、この本はゴミとなる。 MVCで、BootStrapとの連携、活用方法は一番必要だと思うが・・・

MVVMデザインパターンとは何か？  簡単に言うと、WPFやXamarinの為にあると言える。 　WPF：絶えるとと思ったが、意外と耐えた。 　　　　 XAMLなる、XMLみたいなデザインで画面をデザイン出来る為、WindowsForms 　　　　であったような、コントロールで実現できないデザインはオーバーライドで 　　　　ゴリゴリしなくて良くほぼ自由自在にデザイン出来る。 　　WPFが流行るに流行れないのは、やはり、いつの間にか、MVVMデザインパターンでプログラミングするスタイルが定着した事だと思う。 　　MVVMは、物凄く大規模で、継続性があるシステムだと一定の効率効果は得られるが、小規模、モックアップ、事業として成立が難しい案件かも知れない場合、これに見合う開発工数では無くなる点だ。 　　行ってみたら、普通にコーディングしたら、一行で済むようなコードを、わざわざ、モデル、ビューモデル、ビュー（XAML）の三本柱を連携するようにコーディングして行かなくてはならない。 　 Label.Text = "test"; Windows.Formsだとフォームにラベルコントロールを一つ置いて、文字を出す場合、これだけで済むのだが、WPFの場合は、XAMLで設定したコントロールに、どのモデルの変数と割り当てるかを細かく振る舞いを書いて、モデルで変数を用意して、ビューモデルでモデルの変数とビューの橋渡しを行えるようにコードを書く。 Xamarinとは何か？  昨今流行っているクロスプラットフォームである。 何が出来るかと言うと、C#一本で、Androidアプリ、iPhoneアプリ、Windowsアプリの全てが開発出来てしまう。 欠点：　各方面でC#で開発と言われてはいるものの、実は、Android.Java 　　　　やiPhone.Objective-Cのクラス等を、そのままC#にしただけ。 　　　　つまり、Android,iPhoneの開発をそれぞれの言語でやった人では無いと、 　　　　これの意味は分かりにくいが、そういう事なのだ。 　　　　だから、Windows.Formsみたいな、LoadやInitialで始まるなんてあり得ない。 　　　　iPhoneのViewDidLoa

いくつかネットショップ運営の為のパッケージを触る機会があって、思ったのが・・ TEMPOSTARで扱っているeasyECSというソフトは、基幹システムと連携しやすそうに思えた。 何故なら、ローカルにSQL Serverを持っており、データベースを参照する事が可能だからだ。 ・・・が、一つ問題が。 サポートに連絡してみたら、データベースをどうにかする事は、一切許可してくれなかった。 まぁ、基本的にはそうだと思うのだが・・・ ・・・だけど、そうなるとeasyECSは物凄く不便なお荷物に思える。 何故なら、ローカルにデーターベースがあるのに、それを使って基幹システムと連携するような運用が出来ないとなると、データベースを保守する手間だけが発生するからだ。 つまり、easyECSをインストールしたパソコンのデータベースがバックアップを取られるように保守をしたり、パソコン自体を保守したり。。 これって、無駄じゃないのか？？ じゃあWEB上のTEMPOSTARで使えば？っとなるのだが。。 さすがに、これはネクストエンジンの方が全然機能が上だ。 ネクストエンジンの場合、WEBAPIが公開されており、社内で開発したシステムと連携が可能だからだ。 easyECS・・・惜しい・・・ もう少し、データベースの仕様を公開してくれていたら、迷わず導入する企業が出てくると思うのだが。 ネットショップのシステムを内製化すると、ネックになるのがWEB APIの開発とその保守だ。 特に保守は最悪だ。 モールショップは山程あるは、仕様はそれぞれのモールショップで異なるは、APIは廃止されたり、新規で登場したり、またまた仕様はころころ変わるわ・・・ これを、少人数のエンジニアでこれだけの為に人を裂く事は、ほぼほぼ不可能。 実際には、B To Bの取引の為のシステムの方がボリューム大きく、売上が大きい事が殆だからだ。 なので、内製化する際は、エンジニアはAPIだけパッケージで買えないか模索することもあるだろう。 各モールショップの仕様がもう少し標準化されれば良いのだが。。。 大抵、売れるモールショップは偏っており、少数だし。

長らく3大キャリアが牛耳っていた、携帯電話業界。 ソフトバンクが、ボーダーフォンを買収後は、衝撃的な事をしてくれた事を思い出す。 まだ、2大キャリアと言われていた時代、ドコモ、関西セルラー（au）が台頭していた時代、携帯電話の月額料金は上がるばかりだった。 携帯電話の月額料金が上がり始めたのは、J-Phoneが、シャープ製の携帯電話でカメラを搭載した辺だと感じている。 当時は衝撃だった。 そして、写メなんて言葉も出だした。 2001,2002年当時は、自分は関西セルラーのCDMA電波一筋だった。 関西セルラーが初めて、CDMAと言う、高品質な通話が行える電波体系を導入したのだが・・・ キャンペーンで試用してみて、衝撃だった。 音がクリアーで、まるでその場で話しているレベルの品質だったからだ。 auになる前から、割とベンチャー的な事をやってくれていたのは、関西セルラーだった。 当時はこう考えていた。 NTTドコモ　-　全国安定して使える。 関西セルラー　-　常に最新技術を導入、提供している J-Phone　-　とにかく料金体系がめちゃくちゃ安い。 J-Phoneの携帯電話を持つ転機が訪れた。 PBXの開発プロジェクトに参加する事になった当時、携帯電話をさわる機会がますます多くなり、J-Phoneの携帯電話を触ってみた。 はっきり言って、電波はクソだった。 通話がすぐ切れる。 電波が入りにくい。 ・・が、シャープ製のカメラ機能付き携帯電話は最高に良かった。 当時、デジタルカメラもそんなに小型ではなく、また、画素も少ないのにとても高かった。 ・・・が、安さを追求していたJ-Phoneだったが、安さが中途半端だったので、更新月に結局解約した。 それからは、他社でもカメラ搭載携帯電話は増えていき、関西セルラーは、GPSを搭載した携帯電話で、GPSを積極的に活用したサービスが登場し初めて、やはり最新機能に触れたい自分としては、他キャリアは興味の対象ではなかった。 そして、ボーダーフォンが、ソフトバンクに買収されて、孫さんの名前をしきりに聞くようになるのだが・・・ 携帯電話の値段も、高機能になるに連れ、何故か月額料金も高くなり、当時高給取りに近かった自分としても、このコストと機能は釣り合

一長一短だけれども、B to Bよりも、B to Cの取引が多い場合（ネットショップの事業がメイン）だった場合、TEMPOSTARの方が業務効率が良いかもしれない。 何故なら、商品管理が非常に優れているからだ。 ネクストエンジンの場合だと、一つの項目についてそれぞれのショップの制約を意識しながら登録しないと、あっという間に商品連携でエラーとなり、ショップ側のログをみたり、問い合わせたりして原因を特定する必要があるが・・・ TEMPOSTARにもそれは少しはあるのかもしれないが、圧倒的に操作しやすかった。 クレジットカード番号が保存されないのであれば、最悪な自体は起きないと信じたいが・・・

昨今、RPAパッケージを導入すれば、業務が自動化出来ると勘違いしている人が多い。 何人かの経営者と話していると共通して勘違いしている部分があった。 「ウチの会社もAIを導入して業務を自動化しようと思うんだ・・・RPAパッケージを購入して・・」 と、みんな言う。 経産省が指定業者のパッケージ導入などで補助金が100万円？出るとかがお目当てのようで・・ そして、最悪なのは、AIとRPAを勘違いしているところだ。 RPAというのは、実際には、プログラムを組むのと同じ作業が発生するのだ。 Excelで、マクロの記録という機能があるのは有名だけれど。 Excelのマクロの記録は、操作した内容で、VBAのスクリプトが自動生成され、その記録したスクリプトを使用すると、同じ操作を自動的に行なってくれると言うもの。 それを、パソコンの操作に置き換えたようなものなのだ。 RPAパッケージを導入すると、実際には、そのRPAパッケージを日々メンテナンス、障害監視する業務が増えるだけで、何人か分の業務を削減することはほぼ不可能。 プログラミングで自動化した方が、数人分の業務を無くしてしまえる。 （ワークフローを理解出来る人が必要だが） 経産省が絡むと、大抵の場合、導入がスムーズに行かない事が多い。 恐らく経済産業省の人自身、ITに疎いのだろう。 流通BMSのEDIを導入している企業を見るとよく分かる。 人を削減できても、ITコストが人件費を上回る勢いで必要になったり。 こんな考え方の人達が政府指導しているから、日本の借金が1000兆円超えてしまっているのだろう。 まともに、政府のIT推進に耳を傾けていたら、政府に守ってもらえない中小企業は全部倒産するかも。