様々なIT関連技術に関する雑感を書く

元々、なんでも屋のような感じでいろんな事をやっていたし自分自身もそうでありたいと思っていたので、フルスタックエンジニアみたいなことを今はやってる。

もともとなんでもやれるようになりたいと思っていたので、写真撮影、イラスト、記事執筆、パネルやチラシをデザインして印刷屋に発注とかもやらせてもらった。あまり得意ではないが、営業も広報もサポートも必要があればやった。
でも「やった経験があるとやれるは違うだろ」って言われそうだ。そのとおりです、すみません。でも「やった経験がある」だけでここまでくるのも中々そういう人は居ないんじゃないかなとは思う。

そういう点では満足なんだけど、こういうゼネラリスト的な人って一般的にはあんまり必要とされることが少なく、給料の伸びも悪いんですよね。組織がある程度の規模になるならばスペシャリストを揃えたほうがパフォーマンスは出るから、普通はそれをしない理由はない。だからそういう点で「この分野だけは人に負けない」みたいなのが無いままここを突き進んでくのはどうなんかなぁと思うところもあるけどそこは話が逸れるのでさておき。

最近は技術的な記事を書いておらず、書けと言われた気がしたので書いてみる。そんで、いろんな事を経験した私なのでいろんな事の概要や雑感を書いてみようかなという感じ。先に書いたとおり私はスペシャリストではないので個々の見解は間違ってたりするところもあると思いますが、そうじゃなくて全体からなにかフィーリングでいい感じに解釈してくれ。もしくは動物園で動物を見るような気持ちで見てくれ。

JVM言語

SIerでの採用例が多く、かつSIerは大嫌い、全部潰れろみたいな意見の人が多いためか「Javaはダサい」「古い」みたいな意見が多かったり、また、「Javaは有料化された」みたいな誤解も未だに少数ではありますがちらほらと見聞きします。ちなみに話は逸れますがSIerに関する私の気持ちの記事はこれです→「SIerはクズだから辞めるわ」では解決にならない

ただ個人的にはJVM言語はプログラマからの評価がどうであれこれからもずっと残ると思います。なんだかんだで安定して動くし採用例もすでに膨大だし。ただ、一番新しいモダンな言語、みたいなイメージからは離れていってるのかも知れませんけど。もしそうだったとしてもそれは単に印象の話だとも思います。

GraalVMやLLVMあたりが好例ですが、今後のプログラミング言語ってその下層にあるコンパイル環境や実行環境とは切り離されて抽象化され、「コンピュータに命令することをどのように表現するか」という方向に特化していけるようになるんだと思います。つまりこのプログラミング言語は早いとか遅いとか、このOSでしか動かないとか、そういう制限がどんどん無くなっていく方向に進むのは間違いないんじゃないかなと。ということは、関心事(ビジネスその他でITシステムが取り扱う問題)を最も簡潔に表現できるプログラミング言語を選ぶことだけ気をつけてればそれで良い、みたいな感じになるはずです。

JVM言語全般の表現面での特徴としては、まず何よりも強い型付け、型安全の思想が汲み取れるので「書く文字数は多くなるが、そうやって事前に表明しておくことで実行時のエラーを減らす」みたいなことに適した言語としてJVM系の言語は(少なくともそういう思想は)これからも残るでしょう。一方でPythonみたいな「少ない文字数で実装可能、ただし実行前に検知できるエラーは少ない」みたいな真逆の特徴を持った言語も残るでしょう。両者はどちらも必要とされる機会はありますが、前述したようになんかちょくちょく「Javaはダメ、覚える価値無い」みたいなことを言われるのって何か違うよなーと思うんですよね。それはあなたがJVM言語を必要とする場面にあまり出会わなかったという話なのでは?(もしくはそういう場面は世の中にごく小数しかないと過小評価しているのでは?)と言いたい。

プログラミング言語に関わらず世の中に方法論や道具って山ほどあるわけじゃないですか。それはそれが必要になる背景がちゃんとあったはずで、その背景を考える人って意外と居ないんですよね。だから、「なんで6角ナットを締めるのにT型レンチ、クロスレンチ、メガネ、ラチェット、ソケット、モンキー、スパナ他があるの?モンキー1個あれば十分じゃね?」みたいな意見が出てくるんでしょうね。

さて、JVM言語の中では私はJava, Kotlin, Scalaを使っています。最近よく使うのはKotlinです。

Kotlinは大嫌いだったのですが、最近はまぁこれでも良いかな?(Scalaの方が個人的には好きだけど)みたいな印象です。Kotlinの良くないところもバージョンアップに伴い徐々に解決されてきました。ただどうしても許せないのはラムダ式のシンタックス(中括弧がラムダ式となりパラメータは中括弧の中に入る、アローが => じゃなくて -> )とwhenでdestructuringが使えないという点です。

あと、Kotlinは「特定のコンテキストでは特別」みたいな言語仕様が入ってるのがちょっと嫌です。Kotlin開発者がScalaのimplicitを複雑だと批判し、一方で

val b: String? = "Kotlin"
if (b != null && b.length > 0) {
    print("String of length ${b.length}")
} else {
    print("Empty string")
}

みたいなnull safety機能を加えるのは全く意味が分かりません。「同じ命令を書いてもコンテキストに応じて解釈が違う」というのはこれはもう暗記するしかないので記憶力のない私にとっては非常にしんどいです。逆にScalaは「少数の規則で多用な表現を可能にする」ということを重視しているので複雑なようで覚えるべき言語仕様は少なく、私にとっては楽です。

一方でKotlinの良い点としては、SpringBootがKotlin対応してくれたところです(それはSpringBootの良い点では…?)。SpringBootとKotlinの組み合わせは以前は中々の地獄だった記憶がありますが、対応されてからはだいぶ使いやすくなりました。特に @Nullable アノテーションがちゃんと付いたのは良いですね。地味ですがこれがないとNull safetyがちゃんと働かないので。ただ、バックエンドで使っているTomcatその他のクラスには当然Nullableは付いていないので完全なサポートがされているわけでもないです。

Scalaは相変わらず好きで、使えるところには使ってます。ScalaのEither、Future、for式、パターンマッチなんかが好きで、当初の狙い通り関数型とオブジェクト指向の両方をいいとこ取りで使えます。一方でDSL的なやつはあんまり好きじゃないです。ただ、Akka HTTPのルーティングとかがまさにそうなんですが、覚えたら楽で書くのも早いんですよねー。まあDSLってそういうもんだよと言われればそこまでなんですが。

Javaは最近あんまり追えてないですが、新しい言語仕様が次々と導入されてなんかいい感じっぽい、という雑な感想です。switchが式になってパターンマッチも追加されたんだっけ。

Python

Pythonは一部の用途ではすごく優秀で、かつJupyter notebookやJuyputer Labと組み合わせると便利さが更に増します。bashでシェル芸するにはちょっときついが、コンパイルする言語ではちょっとやりたくない…という場合にPythonをよく使用しています。あとは後述する機械学習は現状の所開発言語は良くも悪くもPythonを使わなきゃいけないところも出てきますね。

matplotlibとかscikit-learnとかnumpyとかTensorflowとかOpenCVとかそういうものを使う時によくPythonを使ってましたが、最近はそういうことをする機会も無くなったのでここ1〜2年、前述したようなちょっとしたデータ加工をする場合などを除きあまり使わなくなったかな…。

Golang

Goはごく最近使い始めたんですが、これも非常に良い言語ですね。「ちょっとした処理をネイティブコードの速度で行いたい」という場合に完璧にGoはフィットします。文法その他はC言語によく似ていてまさに俺達が求めていた完璧なC言語の後継だって感じがします。バイナリパッケージを作るとデフォルトで単一の実行ファイルになるのも運用上非常に楽です。エラー処理は賛否両論ありますが、エラーが関数の戻り値として返ってくるような設計自体は可読性が高くて良いように私は思います。Pythonのように「とりあえず覚えておくと便利」な言語の一つと思います。学習コストも(C言語の経験があれば)かなり低いですし。

C

私は大好きなのですが、Windowsを採用したシステムから離れると極端に使う機会が無くなってしまうんですよね…。一応、Linux上でもMonoがあるので動くのですが。Androidアプリ開発とかだともう少し採用事例は増えるのかな?

C#は雑に説明すると戦うエンジニアのための言語って印象があります。言語仕様としてどうあるべきか、美しい言語とはなにかみたいな思想を一切排除して、「業務上の問題をいかに効率よく解決するか」に注力されているような気がします。

JavaScriptとフロントエンド

長らく関わってきたはずなのに一向に全体像がつかめないのがフロントエンドで、フロントエンド専業のエンジニア以外はコロコロと変わる潮流にうんざりしてるんじゃないでしょうか。私はうんざりしてます。なのでフロントでの最新技術はもう追ってません。最先端を知り続ける労力に対してメリットがあまりに少ないからです(フロント専業でもないし)。だから、私は個々数年、「すくなくともこの先2〜3年は生き残るだろう」みたいな予想が付いた技術のみをピックアップして勉強することにしています。

過去、Knockout.jsというMVVMフレームワークがちょっとだけ流行ったのですがすぐ廃れました。代わりにVueがMVVMフレームワークの一種として紹介される事が多くなり(2016年〜2017年ごろ)、現在ではMVVMという言葉は(フロント界隈では)聞かなくなりましたが、Vueは相変わらず使われています。5年前くらいはAngularかReactとか言われてて、その1〜2年語はAngularかReactかVueが良いと言われてて、今はReactかVueになるんですかね?Angularはぱったりと話を聞かなくなりましたね。もっと新しいフレームワークもあるのでしょうけど、個人的には2020年においてもVueかReactを選んどけば良いのかなと思います。

個人的にすごく気に入ってるのはVueとElement UIの組み合わせです。Element UIはUIコンポーネントが沢山集まったライブラリですが、リッチなUIを実現したいという場合によくある要望のほとんどの網羅していると思われます。例えば「固定の小数点付きの数値のみを入力できるテキストボックス」とか、カレンダーとか、ヘッダ固定でフィルタ・ソート機能のついたテーブルとか、アラートとかメッセージボックスtとか。HTML5によって実現できる機能も多いですが、HTML5の新しいinputコントロールってバリデーションその他でクセがあって望みの動作を実現するのが難しいことが多々あるので、最初からこういうUIフレームワークに頼ったほうが早いかなという気がします。

開発環境はnpmとwebpack4をインストールしていい感じに設定すればそれでOKかな、という気がします。Javaプロジェクト他に含めたいときも同様の手順でビルドしたjsを自動でプロジェクトディレクトリの指定した場所に入れるようにして運用しています。

jQueryは数年前まではちょっとだけ使っていました。なんだかんだでjQueryは廃れないだろうし、重厚なフレームワークに頼るまでもない所はjQueryで良いじゃんと。でも一度プロジェクトの中にnpmやVueを組み込んでしまうと、簡単なものであっても逆にjQueryで実装するほうが面倒くさかったりもするので、ここ3年くらいは一切触ってないです。が、合理的理由があれば今でもjQueryでも良いんじゃないかなぁと思ってます(バカにされそう)。

個人的にWebフロントエンドに限らず、UIを実現するのに最も適切な方法はMVVM(あるいはそれに類似した方法)だと思っています。つまり、最終的な見た目と内部状態をはっきりと分離できることが必要不可欠だと。で、こういう設計を取る時にView側に求められる最も大事なことは宣言的に状態を見た目に変換するコードをいかに表現力豊かに書けるかという特性だと思ってます。この考え方は個人的にはたとえVueその他が廃れたとしてもずっと続いていくのではと思います。

開発言語は悩ましいのですがChromeで動作するES6以降の言語仕様で実装して、必要に応じてpolyfillも使います。TypeScriptが登場してすぐはTypeScriptばかり使っていたのですが、AltJSはやはりいつか使えなくなるかも知れないとおもうと採用に躊躇してしまいます(基本保守的な考え方です)。ただ、おそらく多数の人で作り込む大規模なプロジェクト(巨大なSPAとかブラウザゲームとか)になるならばTypeScriptの導入は必須ではないかなと思ってます。

Docker

前職では使えなかった(DockerHubへのアクセスが規制されていた)Dockerですが、もはや使うのが当たり前、無くてはならないみたいな感じになってます。同じように職場規則でDockerを使えない(ので使ったこともない)、みたいな人って結構居るんではないかと想像しているのですが、Dockerは無理だったとしてもこういう「chrootのすごいやつ」的な(コンテナ化技術と言って良いのかな)何かはどんな職場・チームでも導入したほうが良いように思います。なぜならば「環境を汚さずに何かやりたい」という機会は必ずどこの職場・チームでもあり、かつDocker(コンテナ関連技術)が解決できる問題の一つがそれだからです。何らかのピュアな仮想化でも良いと思いますが、そうすると実行速度(起動速度)やストレージ容量的にアレですからね。逆に、Dockerがピュアな仮想化を完全に代替できるものでもないとも思っていますけど。

「環境を汚さずに何かやりたい」を解決するソリューションとしてはDocker以外にも他に適したものがあると思いますが、結局Dockerが流行っていて情報が充実しているのでDockerを使う、で良いんじゃないかなという気がします。

私が担当しているサービスではプロダクション環境でも普通に動かしています(そもそもDockerがproduction-readyかという議論ももう聞かなくなった気がする)。テスト、デプロイ、スケーリング、環境構築あらゆるところでDockerはもう不可欠です。

Dockerのその他の類似技術に比べたときの長所はいくつかありますが、個人的にはまずイメージとレイヤーという概念だと思います。続いてdocker-composeによって複数のイメージを組み合わせてサービスを構築できること。たとえばnginx, php実行環境, mysqlを束ねてwordpress実行環境を作るなどを比較的簡単に実現できます。DockerHubは個人的には便利だなとおもうものの、メンテナンスされていないイメージが多いのであと一歩かなと思うところもあります。取ってきたlatestタグのイメージが本当にlatestか疑うくらいは必要と思われます。

ただ繰り返しますがDockerがこの種の問題をすべて解決してくれるわけではないです。Dockerで解決できない例としてはハードウェアやOSと密接に結びついた処理や運用を行わなくてはならない場合などです。Dockerでも特権モードにすれば出来ることは広がりますが、それを前提とした設計をするのはなんか違う(もっといい方法がある)気がします。

Kubernetes

Dockerをもっといい感じに使うためのなにか(オーケストレーションツール)だが複雑なので自分が担当してるところでは必要ないと思っていたのですが、こないだ使う機会があり使いました。Kubernetesを使うモチベーションとしては「とにかくサーバーを直接触らないようにする」なのかな、と思ってます。アプリケーションはコンテナに入って動けば良い、コンテナは何処かのサーバーでいい感じに(スケールしたり死んだらまた立ち上がったり)動いてればそれでいい、みたいなのを極限まで追求するとここに行き着くのかなぁと思ってます。

加えて、基本的にこれはAWS他のクラウドサービスとセットで使うのが前提ではないかという気もします。

こういうインフラ側の抽象化に対するアプリケーション側の設計としては、具体的な例がぱっと思いつかないですが、あまりOSやハードウェアなど下位層に密接に結びついた設計を避けるのに気を付けた方が良いのかなと思ってます。例えばある特定のネットワークインタフェースが存在することを前提とした実装になるとか、あるアプリケーションと依存する別のアプリケーションが同じサーバ上で動いていることを前提とした設計とか。

ただ、インフラ側の抽象化が今後マストになってくるかというと個人的にはそれも微妙な気もしています。例えば1個のサーバでwordpressが動いていればそれで良いという用途にKubernetesが必要かというと…。少なくとも今は特別理由が無い限りはKubernetes(とDocker)を使用しなくても良いかなと思ってます。

例えばある一定程度に粒度が細かく、数が多いマイクロサービスを運用するときには一々インフラ側をいじってられないのである程度の抽象化があった方が望ましいと思いますが、そもそも粒度が細かいマイクロサービスが大量に存在するようなアーキテクチャが良いとも個人的には思わず。物事の流行りに流されずに現実の問題を解決するのに最も適切な方法を採るための寛容さと、それを選べるだけの知識の引き出しを持っておくことが重要と思ってます。

AWS/GCP/Azure

たとえインフラ寄りのエンジニアで無かったとしても、どれか一つ、概要くらいは知っている必要はあるんじゃないかなぁという気がします。そしてどれか一つ触ってみるならAWSが良いのかなぁという気がします。AWSはこの分野で先行者なので、ほかのクラウドサービスもAWSを真似て作っていると思われるところが多々あります。

AWSはEC2を中心に関連するサービスを使い込んでます。Azureもそんな感じで使い始めましたが、Azureは後発な分、AWSを研究して使いやすいようにあるべき姿に近づけていっているという印象を受けます。例えばサブスクリプションとリソースグループ、可用性セットという概念やはまさにこれが我々に必要だったものだと感心しました。

Azureはまた、かなりとっつきやすく作られている印象で、学習曲線は明らかにAWSよりは早めに伸びていく感があります。ただ、その分AWSでの細かい仕組みが排除されていてあまり細やかな設定もできない(AWSのほうが先行者ということもあって機能は多い?)という印象です。最近のMicrosoftは昔のような業界標準とはかけ離れた独自のライブラリやフレームワークを作ってはすぐに捨てる、みたいなのを止めてかなりオープンな文化になってきており、Azureもまたそんな印象です。たとえAWSと被っているサービスや概念だったとしても、それが良いものであれば積極的に取り入れてる、という印象を受けます。

AWSで私が一番助かったのがALB(Application Load Balancer)で、通常であればnginxをフロントエンドに立てて細かな制御をしようかな…と思う所を簡単に設定してくれます。例えばHTTPヘッダやパスで転送先を切り分け、ウェイトも付けれるなど。また、このロードバランサは自動でスケールしてくれるので基本的に手動でnginxを設定して使うことは無くなりました。もうそういう時代じゃないってことですね。(扱えることは大事とは思いますが)

Terraform

で、そのクラウドサービスをコンソール上からポチポチ手で設定していくわけにもいかないのでInfrastructure as Code(IaC)というわけですね。Terraformはクラウド上のリソースをコードで宣言して構築させるツールです。HCLというHashiCorp自身が作ったJSONライクな書式の設定ファイルを使いますが、正直これは使いにくいです…。こういったJSONライクな書式はたくさんありますが、個人的にはHOCONという書式が最も直感的で覚えやすくかつ表現の幅も広いので好きです。lightbendのconfigというもので使えます。JVM言語で利用できるアプリケーション設定構成ライブラリです。

Terraformはプロバイダーという拡張機能的なものを使用することでAWSでもGCPでもAzureでも使える、というのが一つの売りですが結局それぞれのクラウドサービスの使い方をわかってないと設定ファイルは書けない(それぞれのクラウドサービスごとに書くことが異なり流用はできない)ので期待しすぎは禁物です。

Terraformの運用自体にも多少のノウハウが必要で学習コストも低くはないですし、Terraform自体のバージョンもまだ本記事作成時点で0.12とまだ1に達してない状況ですが、しかし現状でもっともまともな(←個人的感想)ツールであることは確実であって、かつクラウド上に構築するリソースが再現可能なコードで管理されていないというのは危険すぎるので、たとえば1つか2つのサーバが起動していればそれで事足りるとかいう話で済まないのであれば、Terraformの利用は必須な気がします。

terraformingという既存のクラウド上リソースをコードにexportしてくれるツールもあるのですが、こちらは残念ながら更新が滞っているようです。

cloud-init

Terraformはクラウドサービス上のリソースをコードで管理するためのソフトウェアですが、サーバの設定をするのには私はcloud-initをよく使っています。cloud-initはAWSでもAzure他でも標準で使用できるサーバ設定ツールです。yaml形式でサーバ上で必要とされるよくある設定(例えばタイムゾーンの設定とか)を書くか、もしくは普通のスクリプトを書くか、あるいはその両方を初回起動時に1度だけ実行することができます。手動でsshしてサーバ設定するので困らなければ不要ですが、例えば同じ設定のサーバを何台も立てる必要がある(スケールするとか)だと必須になってきます。

cloud-initはあまり複雑なことができませんが、個人的にはむしろ「起動時に1度だけ起動するbashスクリプト」が一番わかりやすくかつ息の長い方法だと思うのでそれを採用することを好んでいます。

Ansibleとかもちょっと触ってみたことがあるのですが、手続き型の方法を採るならば結局bashスクリプト書いてるのと変わらんのでは…と思い、かつインフラ側を構成管理する必要が無い(ベースイメージと使用するアプリケーションのバイナリの構成管理で事足りる)のであんまり使ってません。

他にも数多あるIaC関連ツールの概要は英語ですがこちらがまとまってるような気がしました。用途に応じて選べばよいと思いますが、私自身はterraform + cloud-initの組み合わせを使うことが多いです。

When to use which Infrastructure-as-code tool

機械学習

一時期めちゃくちゃハマって仕事でもやってました。その時取り組んでいたのは現場でのメンテが必要なでかい装置の自然言語(日英語)で書かれたサービス記録の文章を読み取って装置の故障パーツを推論するという内容で、これは中々いい感じの精度を叩きだして個人的にもやってて楽しかったです。

趣味では画像や文章の生成に強い興味があります。NLPについての過去記事はこちら。

画像生成については記事にしてませんが、StyleGANで生成した顔写真とアニメ顔画像だけちょっと以下に載せておきます:






すごくないですか?これがコンピュータが生成した画像なんですよね。

もともと遺伝的アルゴリズムはニューラルネットは好きで色々触っていました。今回のAIブームについては早急に幻滅期が来るかと思ってましたが、緩やかに世の中になじんでいったような感がありますね。「AI」という言葉でこういう

仕事でもどんどん使っていきたいですが、必要と思われるところではすでにサービス化されてたりするので自分で開発するモチベーションが弱い(業務上は)んですよね…。残念ですが。

ビジネス的には「クラウド」に続くセールスのための単語として立派に活用されたんじゃないでしょうか。それを苦々しく思っている技術者は多いと思いますが、個人的には金になれば何でもいいかな、と思ってます。何か詐欺的な商品を開発するわけでもないしね。

OS

Linux / Mac / Windowsの3種をどれも使ってます。開発環境にどれを選択すべきかは好みと開発対象に依存するので一概には言えないと思います。ただ、個人的にはMac / Windowsではアプリの開発でつまづくところが多い気がするのでLinuxで作業することが多いです。Adobe系のソフトを動かすときはWindowsで作業してます。Macは正直あんまり使ってません(Parallels上のLinux/Windowsを主に使ってる)。

私は在学中からUbuntuのお世話になっていて、その前のDebianからの付き合いを考えるとLinux歴は15~6年?にもなるんでしょうか。前職でも開発用に絶対必要だと自分のデスクにPC2台を並べてWindowsとLinux(Ubuntu)を使ってました。

Linuxだと何がいいのか?個人的には、

  • 開発環境の構築が非常に容易
  • サーバ上とOSが同じという点で何かとサーバサイドの開発では都合が良い
  • デスクトップ環境(GNOME)のUIが非常に使いやすい。特に動的に仮想デスクトップが増えていく機能
  • ソフトウェアは厳格にパッケージ管理されていてセキュア
  • ハードウェアを自分で自由に選べる
  • ハードウェアが安い(というかMacが高い)

という感じです。以前はデバイスドライバが無くて周辺機器が動かないとかよくあったのですが、最近は逆に動かない機器をあまり見ないです。新しいマザーボードとかでもすぐにドライバが提供される印象。

MacやWindowsをメインの開発環境として使っている人たちはそれぞれMacやWindowsが良いと思っている理由があるので積極的に乗り換えはお勧めしませんが、こだわりが無ければLinuxで良いんじゃないかなぁと思います(こう書くと多分叩かれる)。

入力機器

システム開発って考えてる時間が長いので入力機器の使いやすさや入力速度の速さってあんまり関係ないんじゃないかなと思ってます。なのでこだわるべきポイントは「それを見る・触ることで仕事への意欲が沸くか」「ずっと使ってて辛くないか」の二つが選択のポイントとして非常に重要と思います。

上記二つを満足するキーボードの条件としては、

  • 左右分離型であること
  • トラックポイントがついてること
  • メカニカルキーボードであること
  • ボタンがいっぱいついてること

が個人的にはマストなんですが、そんなキーボードは無いので諦めてます。最近はキーボード自作というムーブメントもありますけれども、自作キーボードはキーが少ない、何なら少ない方が良いみたいな思想のものが多くて個人的には中々手を出しづらいんですよね…。

では何故ボタンが沢山あるといいのか?それは、なんかかっこいいからというのが第一です。ボタンがいっぱいある機器、なんかかっこよくないですか?それを操作したい!という欲求を仕事につなげるというのが個人的な最重要な狙い。2点目は私の脳処理の特性だと、キーの組み合わせよりも物理的な1つのキーにショートカット機能を割り当てるほうが覚えやすいという点が挙げられます。昔Emacsを使ってたときはそんな事は無かったんですけどね…。変わりました。

ポインティングデバイスは色々試した結果、マウスとトラックポイントの併用が個人的にはベストでした。キーボードから基本手を動かしたくないのはそうですが、しかし沢山のマウスの付いたボタンで操作したほうが早いことも多々あり。Mac使ってる人だと私のような「ボタンがたくさん欲しい」という要求はトラックパッド上のジェスチャーで解決するんでしょう。たぶん。

椅子と机

前項で説明したとおり、「それを見る・触ることで仕事への意欲が沸くか」「ずっと使ってて辛くないか」という観点が周辺機器では重要と考えてます。同じことが椅子と机にも言えます。

椅子は良いものを使ったほうが良いと思います。ホームセンターに売ってるようなものではなくて、ちゃんとしたオフィスチェアメーカーが作ってる椅子ですね。必ずしも高くなるわけではありません。例えばオカムラの安いオフィスチェア(下記)

なんかは実売1万円ちょっとで買えますが、IKEAとか家具屋に売っている数万円の椅子よりもずっと良いです。ずっと座っていても腰やケツが痛くなりにくいです。

机に関しては皆さん横幅にこだわる人は多いと思いますが、個人的には奥行きも重視したほうが良いと思っています。奥行きって結構使うんですよね。Mac bookに外部キーボードを接続して使用する場合などが好例ですね。あと机が狭いと結構イライラしません?わたしはする。

CSS3とHTML5

CSS3とHTML5というのももはや当たり前になっていちいち言わなくなった気がしますが、最近のCSSって表現の幅がめちゃくちゃ広がりましたよね。今までJavaScriptでアニメーション付けてたり影付けるために画像にしてたりしてたところがほぼ無くなりました。特にfilterとSVGの組み合わせが優秀と思っており、Webフォントも組み合わせれば、単純な図形やテキスト表現で画像使うって所はもう無いのでは…。データ量の削減と表示品質の向上も見込めるのでこういうところでは積極的に使っていったほうが良いと思います。クライアント側でのCPU性能が上がったのでこういう事が出来るようになったわけですね。

HTML5はまあ、あるべき姿に近づいたという感じで特に感想は無いです。videoコントロールとかインターネットの初期からあるべきだったと思うけど、まあしょうがないね。前述したようにバリデーションや入力コントロールは結局標準コントロールでは要求に合わない場合も多く、どうなんだろうという感じ。特に感想はないです。

まとめ

書いているうちに疲れてきたのでこの辺りで止めます。

結論は…特に無いです。1万文字以上書いたけど特に無いです。ありがとうございました。