情報処理技術の今と未来

久しぶりにBloggerでメモに近い随想を書いている。 一応、アクセス数がみれるからみているけど、まあ、自分の端末以外からのアクセスはほとんど皆無だろう。 一方、note、Qiita、Mediumなどここ数年でてきた、ある分野に特化したような情報発信メディアについては、そのサービスに対して登録しているユーザーが見てくれたり、検索結果の上位にくる工夫があるため、無名のちっぽけなユーザーでもそこそこ閲覧数が得られたり、反応を得られる。 このBloggerとかその他の汎用的な「古来からある」ブログサービスはこれらに全くかなわない。もう、閉鎖してもいいんじゃないかというぐらいのブログ。 （そこで記述しているのは、本当にメモに近いのだけど） もし、何かを発信したい、ビジネスに結び付けたいなら、「分野を絞った発信メディア」を選ぶことだと思う。 汎用的なブログ、Facebookなどは辞めた方がいい気もする。Twitterはちょっと悩ましところだけど、まずは、「分野を絞った発信メディア」がいいと思う。 そのあと、Twitterを使えばいいと思う。 とにかく、検索結果や、検索ではなく、サービスのユーザーがみてくれやすいものを投稿先として選ぶべきだろう。 　 Webのマーケティングや公知の手段も時代とともにかわっている。 本当に、このBloggerはやめてもいいんじゃないかというほどのお粗末さだ。

SPA（Single Page Application）についてはここ数年、Javascriptでは当然考えられるアプリケーションの構造・設計となっている。 そして、それを実現するために使われるライブラリ、フレームワークとして、React、Angularが以前は代表格としてあげられていた。 　 そのあとから、Vueが徐々に人気を集めだした。今では、もうSPAするならVueでとりあえずしようかという感じになっている。 Angularについては、まだまだバージョンアップを続けてはいるけれど、速度の遅さや学習コストの高さを敬遠するエンジニアが多い。 逆に、ReactはAngularのようにSPAのフレームワークというわけではなく、パーツ作りの「コードギブス」のようなもの。フレームワークというほど、多くの工程を規定するものではなく、画面のパーツの作り方の指針を示す程度のライトなライブラリ。 Reactは、ステート管理をReduxという方針に従って、それをもとにしたフレームワークを使ったり、組み合わせをしてSPAを作り上げる。 作るのもライトであり、Angularに比べればその分動作も軽快なので、エンジニアに好まれる傾向があった。 Vueは、どちらかというとAngularに近い作りでフレームワークといってよく、ルーターとかも一式持っている。あと、JSXというJS内にHTMLを記述するReactと違ってHTMLをベースにパーツをつくっていく。 個人的には、Vueの方が分かりやすいし、必要なものが一式そろっているので使いやすい。こうした点を好意的にみる人たちが利用しているのかなと個人的には思う。 Vueは今やパーツ自体もライブラリとなっており、かなりコミュニティも発達している。 勿論、Reactも悪くはないけれど、ReactはSPAという観点でいうと基幹部分も継ぎ接ぎになったり、JSXという処理言語とView言語が混在するという分離しにくさがある。 今となっては、Vueの人気も高まり、Vueを採用するのがとりあえずは無難かなと思う。 　

AIを使った自動運転についてはよくニュースになる。 プログラム、統計をしていて思うのは、自動車の自動運転を実現するには莫大なコストと人材が必要になるし、実際には、保険や法律の改正なども必要になる。 おそらく、犠牲になる人たちもいるだろうと思う。実際に、自動運転を実現させようとするならであるけど。 　 こうかくとAIに対するアンチだからかというとそうではない。AIでもできることとできないことがある。全知全能の機能ではない。あくまでも、入手できる情報をもとに、基準に照らして判断していくことがAIの処理。 けれど、インプットがない情報については、判断を下すことはできない。 電車やモノレール、飛行機など、比較的、運航経路に不確定要素がないものであれば、自動化は比較的容易だと思う。一番は電車だろうと思う。これは線路を走り、止まる場所、そして、乗客の動向を見たりすればいいので、人間よりも多数のカメラにより自動判別するAIの方が正確なオペレーションができる可能性が高い。 一方、自動車が難しいのが、走行経路に同じくAIにしろ、自動運転ではない走行車が複数走っている。また、歩行者の存在もある。これらを比較的遠くから、認知できて他の走行車も想定内の動きをするのであれば、正しい自動運転ができるだろう。 けれど、これら多数の要素が、予期しない行動に出た場合、AIでどう判断するだろうか？ AI同士で通信しあうなら、どちらかが譲り合いをして問題を回避するかもしれない。けれど、そうでない場合、囚人のジレンマのようなことがおきかねない。 また、曲がり角からの歩行者の飛び出しやスリップなど、突発的な出来事が多数存在する。 電車と比べるとあまりにも突発的な要素が多すぎる。これらをクリアしていくには、かなりの人材とテストが必要になるだろう。勿論、法律についても、自動車メーカーとオーナーのどちらに法的責任があるのかも決めなければならない。自動車メーカーとししては、リスクを負いたくないはずだから、オーナーに法的責任が追わせられるかもしれない。もしく、自動運転基金などにようにして、メーカーもオーナーも法的責任はとらず、基金から被害者への賠償が支払われる罪を帳消しにする仕組みがでくるかもしれない。 いずれにしろ、自動運転は、他の乗り物と比べてかなり超えるべきハードルが高い。そ...

GAFAというくくりは、プログラムなど技術に関係しない、経済評論家的な視点、すなわち、株価とかニュースのイメージで括ったものに見える。 G:Google、A:Apple、F:Facebook、A:Amazon。 エンジニアからすると、GAMAならまだわかる。M:Microsoft。 これは技術的なくくり。Facebookはエンジニアとして、何か恩恵をうけているかというと、Reactぐらいだろうか。けれど、その他GAAにおいては、端末、サービス、言語など幅広い恩恵を受けている。 むしろ、Mの方がエンジニアとしてはあまりあるほどの恩恵を受けている。 なので、エンジニアの観点では、GAMAの方がしっくりくる。 GAMAのくくりのなかでも、ちょっと色合いが違ってて、AppleはSwiftとかはあるけれど、今後、新しい技術やプラットフォームをつくっていくのかというと少し疑問が残る。 あくまでも、自社の製品やサービスが売れることに注力している。 　 Google、Microsoftにおいては、オープンソースやフリーのものによる技術者への貢献が高い。プログラム言語、IDE、エディタ、Webサービスなどなど。 勿論、それぞれ有償の製品やサービスも持っている。 Amazonは、無償での技術貢献は少ないけれど、AWSを中核にSaasをはじめ技術的なインフラをつくっていっている。また、自社の販売サービスからの知見も取り入れて、新しいOSやDBの開発なども行っている。今後は、GoogleやMicrosoftなどと同様にオープンソースでもっと貢献する可能性もある。まだしてないけれど。 OracleやIBMは、技術的なリードというよりも、上記の企業やその他の新興企業が打ち出したものを、既存の自社製品などに取り込んでサービス化していくというスタイルで、けん引役のようにはあまり見えない。 エンジニアとしては、GMがリードし、そのあとを、AAOIが追っていくように見える。そして、その周りには大学発のプログラム言語や技術があったりする。 悲しいかな、日本企業はここにはなかなか入れない。入ろうとしているけれど、入れないのか、そもそも入る気がないのか。 すでにベンチャーがちょっとした技術で大舞台に出れる時代は終わりを迎え、ある程度、資本力や組織力をベースに...

1.広まりつつあるGolang。でも、まだ課題もある。 元々PHPやJavaでWebや統計のプログラムをしていたけれど、最近は、Golangを使うようにしている。 世界規模でみればDockerをはじめ使われることも多くなってきた。日本でもAbemaなどICT系の先端をいこうとする企業で採用されることが多くなった。 Golangは2009年から世にでて来年で10年になる。まだ、ジェネリクスができないことや、slice（動的配列・リスト）や正規表現の速度の遅さなどが欠点として指摘される。 個人的には、ソースファイルが名前空間の区切りではなく、フォルダ・パッケージ単位での名前空間の区切りというのが、疎結合を志向した設計をする上では、結構、使いにくいなと思ったりする。パッケージ単位で小さいモジュールをつくればそれでもいいのかもしれないけれど。 ただ、多くのGolangのソフトは、一つのパッケージフォルダに多数のソースをいれて、循環参照をさけるためか、フラットな構造にしているのをよく見る。 これならやはりソースファイル単位で名前空間は切ってもらった方が何かと便利だと思うけど。 見えない部分で、名前衝突があるとか、あまりコーディングをするうえでは好ましくない仕様だと思う。 2.Go2.0がいつでるのかの予測 それはさておき、ジェネリクスやエラーについては、Go2.0で改善されるといわれている。 Go2.0へのロードマップは現時点（2018.11）では発表されていない ので、いつになるかわからないけれど、 Go2.0は、Go1.20と同様の仕様か、それ以降にでるといわれている。 現時点では、Go1.11なので、1.20になるのは再来年の2020年ぐらいだろうか。 3.Golangが新規採用になると思われる点 GolangはJavaの有償化も手伝って、今後採用する企業が増えていくと予想している。RustやSwiftなどほかにも次世代言語でコンパイルをする速い言語はあるけれど、開発体制の大きさ、文法のシンプルさ、大きなソフトでの実績、クロスプラットフォームでのビルド・実行などが採用の決め手になると思う。 また、最近ではRasspery Piのプログラムを作るのに、GoBotをつかったりと、組み込みなどの分野でもPythonやCと...