Freelance Orgsin Official Site

ごゆっくりしていって下さい

朝の4:30に書いてしまうほど悩んでいる

物事はそんなに効率的にならない。そういうことを考えることが最近多い。

 

例えば、何か特定の技術の開発を請け負ったとして、それを自宅でガリガリとコード書いていても固いアーキテクトにならざるを得ないし、運用保守を無視した提案なんてできない。本来技術を向上させるためにプログラマとして仕事をしているわけなのだが、結局そうなっていないのが現実的な話。分かりやすくプログラミングだけの話で言えば、自分が目指す綺麗な書き方、イケてる書き方をしたくても中々そうはいかない、例えばrubyでメタプロを駆使したくてもそれは難しいように。それは、自分の開発したファイルの全てがexcludeすることなしにコードチェックでwarningが出なかったとしても同じことだ。コードレビューの時間がかかるんじゃないかとか現場のレベル感を考慮してコーディングするのは避けられないし、それを無視した仕事を金の対価として納品するわけにもいかない。

 

結局、ソロでプログラマ名乗っててもなんらかの組織に従属した形になってしまう実態があるし、そういう働き方をしなかったとしても、引き継ぎの時に面倒なことはなるべく省きたい。

 

というわけで、物事はそんなに効率的にならない。技術向上や、ソロでプログラマやる!みたいな心意気は大事だが、そんな簡単な話じゃない。

また、技術をアピールしていても、上には上がいるわけで恥ずかしい思いもしたくないというダサいプライドもなかなか捨てきれない。

 

なぜ、最近そこまで深く考えるかというと、本質的ではない忖度というものに振り回されることが多いためだ。人の信頼は大切だし、誰がプロジェクトの事実上のボスかということも分かっているから簡単に自分のスキルシートの見栄えだけの為に技術を行使した話を提案するわけにもいかない。

 

ゴールはみんなそれぞれ違うと思うが、自分が何をゴールと定めるのかをしっかりと見出してプログラマやってないと今後仕事なんてできないだろう。そんなことを朝の4:30に書いてしまうほど悩んでいる。

竜は、飛ぶ時に羽を必要としない。

割と空気が澄んでいた。ただ、少し肌寒く薄着で外に出てしまったのを後悔した。嫌な予感は常につきまとっていたが、まさか竜を飼うことになろうとは思いもしなかった。

 

少し歩いた丘の先で僕はのんびりと休憩していた。2人ぐらい座れる古ぼけたベンチに座りながら、ただただ時間を消費することを楽しんでいた。

そんな時、空を見上げると割と小さめなゴールデンレトリバーぐらいのサイズの竜がいた。竜と言えば、トレーラーより大きいサイズをイメージしていたが、これがリアルの竜なのかということを知った。それは、まさに漆黒のドラゴンと呼べるに等しかった。よく見ると、そんな竜は傷を負っていたし、他の人間たちに攻撃されていた。気づいたら僕はその竜の方向へ走っていた。僕は竜を助けることにして、その人間たちを言葉巧みに誘導して竜と引き離した。人間は、竜のことを神聖な生き物だと思っているため、なぜ攻撃しているのかも結局わからなかったが、僕は真っ先に竜を助けることを選んだ。

その後竜は、僕にお礼を言い、僕は仲良くなることで竜の背中に乗せてもらった。竜の背中は意外と捕まりやすくて安定していた。僕は何度も君は羽を広げなくていいのかい?と聞いた。どうやら竜は羽を広げずに飛ぶことができるらしい。羽は威嚇のためだけに使う、とそう教えてくれた。

僕たちは天上の崖と呼ばれる場所まで行き、そこの小屋でその竜を飼うことにした。竜は、なぜか僕のペットになることを決めたらしい。僕が困っている時には一緒に戦いたい、そう言った。

その少し前、僕と竜は天空で他の竜と交戦し勝利を収めていた。竜の炎は熱く敵の竜の鱗を溶かしていった。

その時も竜は、僕が一緒にいてくれると元気が出ると嬉しいことを言ってくれた。

この後のことはあまりに悲劇であり、僕も思い出したくもないのでここで幕を閉じることにする。

【AWS】サーバレス導入・基礎編(お名前ドットコム・SES・S3・CloudFront・Certification Manager)

当記事について

最近サーバレスの相談をよく受けることもあって,せっかくなので自分のサイトも簡単にサーバレス構成にしようと思い立った.

実際S3の独自ドメインは基本行うとしても,それをHTTPS化したり,CDN化したりといったところまでは業務以外ではやらなかったのでちょうど良い機会だった.

この記事は,サーバレスの基礎編.これに今後LambdaやCognito,DynamoDBとのRelayを入れていく.その記事はまた今度書くことにする.

構成図

f:id:sinsinchang:20170717223408p:plain 構成は,お名前ドットコムで取得したドメインをSESを利用して,Certification Managerで申請したドメインで,HTTPS通信をしてCloudFrontでCDN化したS3の静的ページを表示させるというもの.

AWSの利用サービス

  • S3: S3
  • CloudFront: CF
  • Certification Manager: CM
  • SES: SES
  • Route53(今回は,お名前ドットコムのドメイン設定で代用): R

手順

  1. R: 任意のドメインを購入する(例として, example.com を買ったとする)
  2. SES: ドメインを登録する(us-east-1)(example.com)
  3. R: MX(example.com),TXT(_amazonses.example.com)レコードを登録する dig example.com mx
  4. SES: Active Rule Setを設定する(us-east-1)→Verification statusがVerifiedになればMXレコードが正常に設定されている
  5. S3: メール受信用のバケットを作成し,IAMのポリシーを設定する(グローバル)
  6. admin@example.com などにメールが届くことを確認する
  7. CM: ドメインのSSLを申請する(us-east-1)→s.example.comなどを登録する
  8. S3: 該当の場所へメールが届くので中身にあるURLにアクセスして承諾する.これは,https://us-west-2.certificates.amazon.com/approvals?code={CODE}&context={CONTENT} というURLになる.
  9. S3: 新規でバケットを作成し(Certification Managerで定義したルールと同様の名前にする),何らかの静的ページを配置する.
  10. CF: 該当のバケットと,SSLを指定する
  11. R: CloudFrontのDomainNameをCNAMEで設定する
  12. CF: StatusがIn ProgressからDeployedに変わったら完了.結構時間がかかった. dig example.com cname

※説明がわかりづらいのでもっと詳細について書いたほうがいいかも.

S3

注意点としては,一般的にS3をサイトとして公開する時のように Web Site Endpointを利用するとSSL通信ができない ということ.CNAMEをこのエンドポイントで設定するだけで,独自ドメインにできるため便利なのだが,思わぬ落とし穴であった.

docs.aws.amazon.com

公式が言っているので間違いないのだが,HTTPS化したいのならば通常のREST API エンドポイントにするしかない.

docs.aws.amazon.com

Amazon S3 バケットがウェブサイトエンドポイントとして構成されている場合、オリジンとの通信に HTTPS を使用するように CloudFront を構成することはできません。

Amazon S3 はその構成で HTTPS 接続をサポートしていないためです。

こちらでも明記されている.

REST APIエンドポイントは以下にあるので参考にしたい. docs.aws.amazon.com

Certification Manager,CloudFront

CloudFrontはus-east-1などのSSLしか受け付けていないので,SSLも同様の場所で申請する必要がある.

また, S3は元々バケットとドメインがイコール でないと表示できないという制約があるため,CloudFrontでCDN化する時もその点に注意して作成する必要がある.

例えば,cf.example.comというドメインで表示させたいなら,S3のバケットもcf.example.comという名前で作成する.

さいごに

待ちが発生する事が多いため,手順をミスると大幅な時間がかかってしまうので注意.特に先に述べたWeb Site Endpointは使わないことや,S3は元々バケットとドメインがイコールであることには注意. 今回は単純なものであるが,普通に一般的なS3のサイトにも応用できそうだったのでまとめておく.料金がいくらかかったかは,また1ヶ月後にでも追記しようと思う.

【キソ】Web APIの設計で気を付けていること

APIとは

Application Programming Interface の略です.簡単に言えば,ソフトウェア同士が自身でプログラムを組まなくても,特定の機能を呼び出すインタフェースを提供したもののことである.

APIは,内部で交互に通信をする場合に用いるだけでなくサーバサイドとネイティブアプリの通信に用いたり,時には外部に公開したりする.今回はそういったWebに関するHTTP通信によるAPIの設計についてである.

最近では,サーバレスアーキテクチャが注目されており,AWS利用者なら例えばAPI Gatewayをエントリポイントと見て,Lambdaで処理を行いS3やDynamoDBを変更するなどの動きを一連の流れとしていたりする.また,Cogniteを用いることでユーザ識別も可能となる.最近読んだ本では,TDDベースでサーバレス設計についてかなり初歩的な話から書かれていて誰でも読みやすいと思われる.

www.orgsin.com この記事でも読もうと思っていた本である.

サーバーレスシングルページアプリケーション ―S3、AWS Lambda、API Gateway、DynamoDB、Cognitoで構築するスケーラブルなWebサービス

サーバーレスシングルページアプリケーション ―S3、AWS Lambda、API Gateway、DynamoDB、Cognitoで構築するスケーラブルなWebサービス

とはいえ,必ず1つの手法が正しいとは思わないので要件や規模感,社内風土に合わせた設計が重要である.やはり,ユーザ体験を良くするためには,切っても切れないコストが隣合わせということである.

設計するにあたって

基本的には,業務上APIを設計しなくてはいけない事が多いので前提を省く事が多いが今回はそういう部分も含めて書いておこうと思う.

先ほど挙げたサーバレスアーキテクチャは,今回は使用しないという前提で話を進めるが使った場合でもフローは変わらずツール(API Gateway,Lambda)を使うかどうか,という話になってくると思う.

人は,どういうときにAPIが欲しいと思うのだろうか,どんなAPIなら使いやすいのか,セキュリティのことも考えないといけないのだろうか?

などと,挙げていくとたくさん出てくる.今回はこの3つについて簡単にまとめておく

こんな時にAPIが欲しい

業務上とあるデータが必要になったり,フロントサイドからJS等でユーザに関する特定の処理を追加したいなどというデータベースを介在するタイミングが多いのではないだろうか.あるいは,外部のOAuthを利用したログインを採用することも多々あり,その際にも何らかのエンドポイントは必要になってくる.

使いやすいAPIとは

プログラマが使いやすいAPIである.例えば,仕様がRFCベースで統一されていたり,GoogleやTwitterのようなAPIを提供している会社のルールを模倣していたり.ただ,他の企業を参考にする場合FacebookやLinkedin,Instagramなども参考にしてみると良い.

バージョン管理,リクエスト・レスポンスルール,認証等の仕様はどこでも大きく変わらないし自分ルールでやってしまうよりは使いやすいものになるかもしれない.

また,特定の用途限定のAPIとして,あるいは広く大勢の人に使ってもらうためのAPIとして提供するかで設計内容も変わってくる.前者の場合,汎用性を持たせすぎて逆に使いづらいAPIにならないように注意しなければならない.例えば本来1回の呼び出しで簡潔するような特定の用途限定の処理を,汎用的に作るせいで通信回数を無駄に増やしてしまうのような設計になっていたら,一度踏みとどまって考え直した方がよさそうだ.そのようなことがないからと言って安心はできない.特定の用途限定のAPIの場合,特定のクライアント依存のためちゃんと設計しないと実装がひっくり返るようなミスをしている可能性もあるので,その限定したレスポンスを吟味する重要性は増す.

セキュリティについて

セキュリティに限らないが,絶対安全という保証はない.全世界のプログラマを驚愕させたHeartbleedもまだ記憶に新しいところだと思う.GoogleがOpenSSLに脆弱性を報告してからも,対応が間に合わなかった企業に不正閲覧の事件が度々起こっているのだが,そもそもOpenSSL 1.0.1gが公開されるまで,2年と1ヶ月弱の間この脆弱性が混入していたという事実は消せない.

REST

Representational State Transfer の略で,Roy Fieldingという人が論文で提唱した.今回この記事で扱いたいのは一般的なWeb APIを作る時の参考にしたいだけでRESTについて掘り下げたいといった試みはまったくない.また,最近ではGraphQLを採用しクライアントにデータ項目を指定させる形式もGitHubなどで使われている.今回は採用しないが,世界中のプログラマに使われることを想定し,より汎用的な設計が求められているならGraphQLも候補に入れておくべきかもしれない.

エンドポイント

クライアントに提供するURIとしては,やはり使いやすくわかりやすいものを提供するのが理想的である.

例えば,ユーザ情報を扱うAPIを作るならば,HTTP1.1では以下のようなエンドポイントを用意して上げることになるだろう.ただし,POST, PUT, PATCHについては一緒くたにされていたりするので必ずしも使い分けることが最善策とは言い切れない.またRFCが更新されると仕様も変わったりするので情報収集は大切である.

GET /users・・・ユーザを取得する
POST /users・・・ユーザを登録する
PUT /users/{id}・・・特定のユーザを登録・更新する
PATCH /users/{id}・・・特定のユーザを部分的に更新する
DELETE /users/{id}・・・ユーザを削除する

リクエストメソッド

クライアントがAPIにリクエストを送る場合,メソッドを指定することになる.例えば,ユーザ情報の例を使ってみる.

cURL -XGET https://example.com/users
cURL -XPOST -d "" https://example.com/users

RFC7231はHTTP/1.1の仕様.英語で読むのが,という方は以下の日本語を見てみるといいかも.

RFC 7231 — HTTP/1.1: Semantics and Content (日本語訳)

引用すると

  • GET

[ ターゲットリソースに対する,現在の選定される表現 ]の転送を要請する

情報取得の主な仕組みであり,ほぼすべての処理能 最適化の力点が置かれる所である。

誰かが[ HTTP を介して識別し得る何らかの情報を取得する ]ことについて話すとき,たいていは GET 要請の発行を指している

  • POST

[ ターゲットリソースが,自前の特有の意味論に則って,要請内に同封された表現を処理する ]ことを要請する

[ HTML フォームに入力された一連のフィールド ]などのデータブロックを,データ取り扱い処理に提供する。

[ 掲示板, ニュースグループ, メーリングリスト, ブログ, その他同類の記事群 ]などへ,メッセージを投函する。

生成元サーバにより まだ識別されていない,新たなリソースを作成する。

既存のリソースの,いくつかの表現に、データを付加する。

  • PUT

[ ターゲットリソースの状態を,[ 要請メッセージペイロード内に同封された表現により定義される状態 ]として作成する, あるいはその状態に置換する ]ことを要請する

意図は、その正確な効果が 生成元サーバのみに既知であっても,冪等であり、中継者からは可視になる

  • DELETE

[ 生成元サーバに,ターゲットリソースと,その現在の機能性との間の結び付けを除去してもらう ]ことを要請する

部分的な更新

HTTPステータスコード

クライアントに返すHTTPステータスコードとしては,大きく分けると,以下のようになる

  • 2xx・・・成功した.
  • 3xx・・・リダイレクト.
  • 4xx・・・クライアント側でエラーが発生した.
  • 5xx・・・サーバ側でエラーが発生した.

より細かく各々のステータスを分類して返却しても良いが,基本的にはクライアントがわかればよいのでその辺りはAPIの規模感だったり要件にもよる.

ここで重要なことは,区分は最低限守るということ.そうでないと,昔僕が使ったことがあるAPIのように,クライアントから送るパラメータが不正なのに200を返して,メッセージにエラー内容を入れてあったり,4xx系なのに,5xxを返してきたせいでデバッグの時間が余計にかかったことがある.これでは,HTTPステータスコードを見て処理を行う場合に非常に使いづらいし,汎用的な処理を適用できなくなる.

バージョン管理

これについては様々議論のわかれるところだが,個人的にはバージョン管理はするべきだと思う.また,その場合バージョンをどう表現するかでも意見は割れやすい.よく見かけるのは以下である.

  1. バージョン管理はしない
  2. /v1, /v2 のようにメジャーバージョンのみを含めるタイプ
  3. /v1.1.1 のような,セマンティック バージョニングをURIにも採用する形式をとっている.
  4. /20170618 のように日付を含めるタイプ
  5. そもそもURIは変えずにパラメータに加えるタイプ
  6. 全てのメソッドがPOST送信であり,Bodyになんらかのキーやハッシュ値でバージョンを管理しているタイプ

個人的な意見で申し訳ないところだが,先程も言ったように1度公開したエンドポイントは後方互換を保てないような仕様変更はするべきではないと思っている.というのもAPIが変わると再度クライアント側で改修をしなくてはならないためだ,というところで,1のバージョン管理をしない場合そのデメリットを理解した上で設計する必要がある.

今回6つ参考程度に挙げたが,よく採用されているのは主に2のタイプで,僕も通常2で設計する.というのも,後方互換が取れない場合にURIを変えれば良い.クライアントは任意のタイミング,あるいはこちらがサポートを終了するまで旧URIを使用し続けることができるためだ.

2とは別に3の丁寧なバージョニングは,マイナーバージョンやパッチバージョンをカウントアップした際にもエンドポイントを変更しなくてはならないので,クライアントからしたら多少不便だと感じるだろう.

4は,日付がわかりやすくてよいが,エントリポイントとして日付管理が複雑になりがちであるため,僕は採用したことがない.

5や6は,好みかもしれない.パラメータに加える形式は昔のAPIで見たことがある.どちらにしても最近主流の方法ではなさそうだ.

※あくまでもパターンの話で,特定のAPIを否定しているわけではありません.

会社毎のバージョン管理

参考程度に,2017年 7月 2日 日曜日時点の国内会社のAPIの状況を少し貼っておく.

※こちら問題があれば言ってください.すぐに修正・削除致します.

company name version management number style
rakuten API 3 /20140222/~
yahoo API 1 /V1/~
Backlog API 1 /v1/~
chatwork API 1 /v1/~
freee API 1 /1/~
hotpepper API 1 /v1/~
HackerNews API 1 /v0/~

拡張子

基本的にはJsonで良いのではないだろうか.Amazonのような大手でもXMLだったりするが,FacebookやTwitter,GoogleではJsonで通信が可能.

文字のエンコーディング等は,サーバ側で全部決めるのではなくクライアントとコンテントの交渉をするのでそのリクエストが来ても良いようにXMLの対応をしておくのも悪くない.

セキュリティ

特定の企業に限定させるなら,IP制限をかける必要があるし,通信は基本的にはSSLが良い.最近では,認可のためOAuth2が使われることが多いでしょう.OAuthに関しての説明は書けば書くほど怪しいものになりそうなのでここでは書かない.また,リミットも重要で,1分間で何回アクセス可能だ,とか1日で数万回がマックスとか,そういう制限はかけたほうが良い.

最後に

どんなアーキテクチャを採用するにせよ,ソフトウェアに必要最低条件を盛り込むのは当然として,それ以上に「あるべき姿」も理解した上で取捨選択し,最適解を見つけていきたい.負の遺産というものは,プログラマが現時点で分かっている以上に将来的に発生するものだと思うし,全てを盛り込むことはおよそ不可能だと考えられる.別の優秀なプログラマに,「なんでここがこうなっているの?」と聞かれた時に妥当な回答ができるようにしないといけない.例えば「将来」自分の妥当な答えが「変化した」から「ソフトウェアを変えよう」と方針を決めることができる.

【2017年5月末】梅雨前に,技術的に読んでおきたい記事はどれか

自己紹介

普段ソフトウェアエンジニアをやっています.とはいえ,作るよりは壊す方が好きで,ソフトウェアを見るとまずはじめに故障しやすい箇所を発見したくなります.

タイトルはネタです.ただのメモみたいなものですね.

技術以外

いきなり技術とは関係ない記事

The First Cookbook

紀元前1750年頃にきた最初のレシピが,メゾポタミアの古代の例らしい. http://ilovetypography.com/2017/05/31/the-first-cookbook/

中身には, 他人のように指で食べるのではなく,黄金のフォークを使って食べる と書いてある.

最初の図解された料理書の「Bartolomeo Scappi’s Opera」を見ると想像力が駆り立てられる.それだけでも見る価値があった.

単発記事

なんでCSを専攻する人って全くいないの??

http://danwang.co/why-so-few-computer-science-majors/?idk

これけっこう昔から思ってた.僕は大学院まで修了してCSを学んできたが,実際職場ではあまりCS出身の人が一般的とはいえなかった.これは日本だけかと思っていたが海外の記事でも見つけた.結論から述べると,時代的に起きた出来事が要因としてあるってことでそれについて書かれていた.

なぜCS専攻が少ないのかってことを羅列してる

  1. コンピュータサイエンスは難しい.
  2. 開発するのにCSの学歴が必須でない.
  3. 実際にメジャー専攻をやっている時に,そんなに仕事のことを考えてない.
  4. 移民が全部の仕事をやってる.→これは日本は関係ないかも
  5. アンチ女性文化.→女性が少ないのは確かにそうかも
  6. 保守的な教員
  7. アンチナード文化.→CSがオタクって,そうかな?..アニメ好き多いし,確かにそうかも.でもナードってまた別の意味だよな.
  8. スキルのミスマッチとか,スタートアップでは研修がない
  9. 品質が勾配している
  10. インターネット系企業のバブルからの心理的なもの
  11. パイプラインの問題がもうなくなった

StackOverFlowの記事にあるグラフも面白い https://insights.stackoverflow.com/survey/2017#education

2017年にフロントエンドWeb開発者になる方法

medium.com

StackOverFlowでも2017年ランキング1位となってる.

Unixシェルの作成 - 第1部

indradhanush.github.io

学生だった頃,簡単なUnixシェルを作る講義があったが,結論から言えば「シェルとは、オペレーティングシステムのカーネルとやりとりするためのインターフェイス」であり,そのことがわかりやすくこの記事にまとめてあった.第2部が早く読みたくて仕方ない.面白い.

シェルとは,以下の機能で動いている.

  1. シェルを起動する
  2. ユーザーの入力を待つ
  3. ユーザー入力を解析する
  4. コマンドを実行して結果を返します
  5. 2に戻る

ポートフォリオ

https://www.michaelfogleman.com/#mapper

評価されるポートフォリオのいい参考例.

サイト全体

Hacker Noon

https://hackernoon.com/

Hack系ですかね.単純に眺めているだけで楽しいし,国内では読めない話が詰まっていたりする.後は話のネタになります.

IEEE

spectrum.ieee.org

学会系.とりあえず知っておかないとカンファレンスに行けない.

とりあえず今買おうと思ってる本

サーバーレスシングルページアプリケーション

――S3、AWS Lambda、API Gateway、DynamoDB、Cognitoで構築するスケーラブルなWebサービス

www.oreilly.co.jp

エンジニアが2020年以降を生きていくために考える

金融緩和を行うと

景気が良くなるように感じるが,中々そうは行かない.当然政府が日銀に直で金を借りて公共事業などに使うとかもあるけど,起業したり事業拡大する層が増えたりする方向になっていくのが最も良いし,金に対する信用という意味でも産業発展は不可欠であると思う.とはいえ,我々日本に住む人達が銀行に金を預けっぱなしにしておいて全く使わないのではデフレは解決しない.

極端に言えば,衣食住さえ通るのであればもうあとは必要ないのだが,今後技術発展していくと仕事も減るので,暇な人が増えていく.テーマパークや最新のゲームでは人の寂しさや余暇を解消することはできない.その暇を埋める産業も今後出てくると思う.今より年金受給額が5000円増えても誰も嬉しくない.見える金が増えることが一番だと考えるのは相当に頭の弱い人になってしまう.それよりは,産業を発展させ新しい余暇を過ごせる何かを提供することができないだろうかと考える.最近だとVRとかドローン,YouTuberのような面白い形も見えつつある.

VRやドローン,IoTなどにおいてはエンジニアの力なくしては解決できない物事だと思うが,そうではないことも多かったりする.例えば,より便利にしていくという産業とかまだ自分でもよくわからない.

金はもちろん必要だ.それは新しい産業に投資するために必要な金であり,その金が生まれたからと行って何か幸せのパーセンテージが増加するわけではない.期待値は上昇するが.

産業の発展について

小さなところで言えば

例えば,最近で出現しつつあるのがサービスの受け答え部分.昔なら文章のQ&Aやお問い合わせフォームが多かったが,最近ではチャットボットや動画などでよりUI/UXを思考しながら作られているサイトが見受けられる.Siriやペッパーのような会話ロボットもあるし,今後音声がサービスと密着していくのは明らかだろう.

なぜこのようなことをしなくてはならないかというと,今まではお客様=全員同じだったのが,最近ではお客様一人ひとりをターゲットにした受け答えという段階に来つつあるからに他ならない.

データ連携・分析については,もはややっていないというのは遅れているなという印象を受けるので,これについては割愛する.そこから生み出され,お客様一人ひとりの対応にいかないといけない段階に来ている.

これについては広告も同様の印象を受ける.結局はお客様一人ひとりについてより正しく,必要な広告を提示することでしかそこに真の価値はないのだから.

IoTはどうなる

わからない.わからないが,確実に今後未来に必要なものである.それは多くのデータが分析した結果であり,IoTを想定した補助的な産業が生まれつつあることからも明らかだ.そういう意味では,人工知能はもてはやされすぎている印象を特に2016年は受けた.周りのエンジニアの誰もがPythonを駆使してDeep Learningのようなものを行っていたし,なんとなく研究し始めた人も多かったと思う.実際に私自身もPythonの仕事を4ヶ月ほどした.

最近ではスマフォアプリのニーズは上がっているが,別段そんなにもてはやされていない印象も受ける.やってない会社は当然やらなくてはならないが,以前のようにスマフォアプリやらないと死んじゃう,みたいな状況は感じないし,私自身ものめり込んでやらなくなったと思う.

自動運転

必ず話題にあがってくる.特に最近では.私もちょうど今年に入ってからとある会社から自動運転の仕事の話があった.おそらく今後このようなユーザが意思を考える前にアシストするようなサービスは増えていくと思う.それは自動運転に限らないと思うし,もっと身近な例えば食事や遊びの場所提供などでも考えられている.

投資

やったほうがいい.というよりやらないとまずい状況になっている.投資というのは別に金だけに執着しているわけではない.技術の勉強も投資のうちであるし,優秀なエンジニアと語り合うのもそのうちだ.