スキップしてメイン コンテンツに移動

投稿

MacからWindows10Proに乗り換えた

2019年時点で、Webやスマホのプログラマといえば、MacBookを使っている人が多かったりする。 新しい企業にいくとこうした光景はよくみる。 自分も2009年から2017年ぐらいまでは、Macをメインにつかっていた。 けれど、2017年後半ぐらいから、Windows10をメインに使うようになった。 その大きな理由は、Mac製品全般の値段が高いこと。 もちろん、値段が高くてもそれ相応に、Winマシンには比べ物にならないぐらいの優位性があるならわかる。 けれど、スペックと価格の対応をみても、Winマシンの方が遥かに低予算で高スペックなものが手に入る。 Dockerを始め仮想化や並列化が当たり前になりつつある開発現場において、CPUのコア数やメモリの高さは確保しないといけない。 Core i5、メモリ16GBぐらいが最低ラインではないかと思っている。 私は、LenovoのCore i7、メモリ16GB、15インチで使っている。購入額は12万円。同程度のMacBookProを購入すると25万円はする。約2倍の額。Winマシンならもう一台購入できてしまう。 では、Macでないとできないことがあるだろうか?ものによるだろうけれど、一番は、iOSやMacOSのアプリ開発はMacの方が向いているだろう。 (ただし、Winでも仮想化を使えばMacも動くのだけれど)  私の場合、iOSの開発は一切しない。JavaやGo、その他、PHP、Python、Ruby、RなどWebシステムや統計処理をする。この場合、MacOSである必要はほとんどない。 そして、WinPro10の場合、Hyper-vをベースとして、Docker for Windowsを利用すれば、Linux(コンテナ)を扱うこともできる。  そうでなくてもWindows10はWSL(Windows Subsystem for Linux)が使える。つまり、Linuxの機能を手軽に使える(Cygwinとか使わず)。  以前Macをつかっていたときは、Unixベースで、Webの開発などは便利なところもあったけれど、最近は、Windowsでもこの点は全く不便はない。  実は、今も、Mac miniは購入するようにして、MacOSは触っている。一応、この業界にいる以上、可能な限り...
最近の投稿

OracleJDK有償化とプログラマがJavaを選択すること

OracleJDKが有償化されることは2019年1月時点では、Javaのプログラマでなくても、プログラムに関心がある人なら知っていると思う。 今後、この有償化がどういうことをJavaに引き起こすのかを考察してみる。 まず、世界規模でJavaは大中規模の企業が利用しており、Javaはこれからも当分は使われ続けていく。 仮に有償化だとしても、すでに企業利用では、なんらかのサーバサポート費用等を払っており、JDKの有償化そのものはそれほど大きな問題ではない。 有償化はどちらかというと開発者にとって考慮される事項だろうと思う。 OracleJDKは有償化であるけれど、OpenJDKは無償で利用できる。そこには機能的な差異、サポートの差異など違いがある。 おそらく、初学者やプライベートで利用する人はOpenJDKを使うことが多いと思う。基本的に技術的な差異はないのだけれど、そもそも、他の言語は、こうした「あるものは有償化、あるものは無償化」ということが少ない。 こうした「選択、考慮」が煩わしいと感じるプログラマも多くいるはずだと思う。 実質、有償化によって格段のプログラマとしての不便が生じるのかというと、実際は、それほどないと思われる。おそらく、OpenJDK等も言語としての根幹に関わる部分は、OracleJDKとそれほど変わらないと思われる。 結局の所、言語そのものではなく、それらを取り巻く「イメージ・印象」としての「煩わしさ」なのだと思う。 アンチJavaがプログラマに存在するけれど、その理由の少なくない部分は「イメージ」であり、Oracleがバックアップにしてから更に、このアンチのイメージは悪くなった。 ずっとJavaを触っていて思うのが、Java自体は文法も平均的、パフォーマンスもスクリプトよりは遥かに速く、実用に耐えうる、よい言語だと思う。 けれど、Javaを利用したサーバサービスなどこれらを取り巻く企業による「冗長」な製品群、ライブラリ群などによって、「敷居」というか、「使い勝手そのもの」を歪曲させられている。 シンプルに言語と向き合えば、次世代言語のRustやGoよりは癖がない分、とっつきやすいし、設計もしやすく、実用的である。 けれど、Javaの不幸さは、この言語を取り巻く企業の動きによって、その良さが見にく...

情報発信として使うWeb媒体は、汎用的なブログではなく分野に特化したものを

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

SPAはReactよりもVueの方が使いやすい?

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というくくりがプログラマからするとしっくりこない

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が追っていくように見える。そして、その周りには大学発のプログラム言語や技術があったりする。 悲しいかな、日本企業はここにはなかなか入れない。入ろうとしているけれど、入れないのか、そもそも入る気がないのか。 すでにベンチャーがちょっとした技術で大舞台に出れる時代は終わりを迎え、ある程度、資本力や組織力をベースに...

Golangの普及について

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と...