優秀なプログラマになるためには?

すまんが分からん。僕は優秀じゃないからな。

なぜUSよりJISキーボードをおすすめするか。

なぜJISよりUSキーボードをオススメするのか、というお話 | coardware

この記事をよんだ。

これはまぁ、一つ一理ある意見として尊重してもらっておいてよい。USキーボードをつかうための理由づけとして非常に有用だと思っている。

しかし、ぼくはそれでもJISキーボードをつかい続けている。それは単につかいやすいからだ。正直なところ人それぞれで、人合う合わないの問題がある。それは元記事にも、最後の方にそう書かれている。ちなみに、JISキーボードなMacbookとかのAppleのキーボードのことに限定させて頂く。

では、僕はなぜこの記事を書くのかと思ったのは、僕がJISキーボードを使うために考えているメモ的なものでもあり、他方、JISキーボードを使っている、これから使う人への意見の共有でもあるのである。

「キーボードは本質的に使いやすい」とは?

これは、ちょっと反論というか疑念なのだが、そもそも、記事中に書かれていることであるが、「本質的に使いやすい」とはどういうことであるか? 意味不明であるのだが。

そもそも「使いやすさ」というのは、主観的な事柄で自分が使いやすいかどうかがそのユーザにとって使いやすいか?というのが本質ではないだろうか? 客観的なものとして、たとえば、アンケート調査などをして、100人のうちに、99人が「使いやすい」といって、のこり1人が「使いやすくない」と言えば、たしかに大多数は「使いやすい」ということを共有できるだろう。しかしながら、その「使いにくい」という1人にとっては、それは「本質的な使いやすさ」ではないのだ。

つまりは、その程度のものでしかない。ということを補足しておきたいのがまず最初にあるのである。ユーザ一人一人は目的があり、その目的を効率よく達成できるかの度合いによって、「使いさすさ」は異なるというのが僕の一つの意見ではる。

ちなみにISO 9241-11の定義によれば、これは使いやすさというより、ユーザビリティの話ではあるが、

ユーザビリティ (usability): 特定の利用状況において、特定のユーザによって、ある製品が、指定された目標を達成するために用いられる際の、有効さ、効率、ユーザの満足度の度合い。

とある。

あと、元の記事には、1972年がどうたらと書かれているが、国際標準のQWERTYってのは、そもそも「タイプライターの時代のに使いやすい配列」もので、それが人間が慣れちゃったら、みんなでQWERTYにしようってなったようになったと記憶、解釈としている。だから、そもそもQWERTYはそもそも、訓練が必要なある意味「使いにくい」配列のように思える。

僕は一時期dvorak配列に感動し、一時期つかっていて、今でも使いやすい配列だと思うのであるが、しかしながら、一般に勧めらるものでは無い。また、SKKを利用して>いるが、これもまた、勧められるものではない。しかし、ながら僕にとって本質的に使いやすいのがこれである。それで大多数が使いにくい印象があるのかもしれないが、僕にとって本質的なのだ。それ以外何があるんだろうか?

Returnキーがでかい

僕にとってはReturnキーは小さいと使いにくい。以上だ。元の記事を書いた、彼にとっては、大問題じゃないかもかもれない。それだけだ。何をそこまで書く必要があるのだろうか?

なんか元の記事にはいろいろ書いてあるが、僕にはピンとこなかった。たとえば、

意見によっては「日本語は変換の確定をReturnで頻繁に行うからキーが大きい方が良い」というのがありますが、頻繁に行うからこそホームポジションを崩さずにReturnできることが大事なのではないでしょうか。

そもそも、ホームポジションを崩さずに日本語のReturnを押せる僕にとってはまったく無意味である。まぁ言うなれば僕は手がでかい。だから、JISキーボードが使いやすい。そして、Returnは日本語では変換の決定によく使うので重要であると思う。(最近ではSKKのおかげでそもそもReturnをタイプすることが少なくなったの、本心を言えばぶっちゃけ大きいとか小さいとかどうでもよい)

だから、そうだな、彼の都合だと、たぶん、Returnキーが遠いことが不都合なのだろう。それはそれで、彼にとって本質なのだろう。

左右の独立した英数かなキーがある。

さてさて、元の記事には、わりとごちゃごちゃ書かれているのだが、要約すると「Commandキーが押しにくいから、かなとか英数は無駄」みたいなことを書いていた。なるほどね? まぁ、ぶっちゃけると、JISキーボードでもCommandキーは慣れれば別にどうってことない。ということになる。

あと、そもそも「Commandキーはなんのためにあんの?」というわかりにくさが普通にある。一方で、「かな」と「英数」はああ押せば、かな入力になったり、英数入力になったりする分かりやすさがわりとある。それだけで、あれ? 英数かなキーめっちゃ使いやすくね?

僕とって独立した英数かなキーがあるおかげで、僕は大助かりである。間違いなく、かな入力と、英数入力をボタンひとつで切り変えられる。入力状態を現在の入力状態が何であるかにも関わらず、変更できるのだすばらしい。

元記事には、なにやらソフトを入れなければならないが、なぜ、そんなソフトをインストールして設定をしなければならないかね。それだったら、JISのままでよい。

などと、僕にとってはいろいろと使いやすいと思うことがたくさんある。これはなんどでも言っていることだが。しかしながら、彼にはそうは思わないだろう。たぶん、そういうことで、それが使いやすさの本質であるのだ。

もうちょっと書いておこう。これは、「日本人にとって使いやすいデザイン」であると思うのである。日本語入力をしない外国人にとっては不便で極まりないだろう。

controlキーが押しやすい。

これまでは、元記事に対する、反応でしかない。じゃあ、JISの利点をもうひとつ上げておこうか? USのキーボードにはないのだが、JISにてすばらしいなぁと思っているのが、controlキーがすごく押しやすいのである。

これはたぶんプログラマーならではの意見であろう。僕はemacsをよく使うのであるが、controlキーがそこにあるおかげで、emacsのコマンドが入力しやすいのである。これはすごく大きい。一方USの方はどうか? controlにある位置にはCaps Lockがある。これは無駄としか言いようがない。なんのためにあるんだろうか? emacsのUSのキーのユーザはわざわざ、Caps LockをControlに設定しなおしてるのだ。

しかし、たぶん、これはやはり僕都合の使いやすさでしかないだろう。

日本人のためにデザイン

USキーボードはアルファベットを入力するためのものだと考えている。それを考えると合理的だ。しかしながら、日本語を扱う日本人には向いてないように思える。ずっと、USキーボードは海外の人達がその人達のことを考えて作られているのであって、JISキーボードは日本人のためにデザインされているように考えている、ように思える。思えるだけで、そうだって根拠はなにもねぇのだが。

キーボードのレイアウトがどうであれ、作業効率は変わらない

ここまでの話、僕の主観でしかない。そして、いろいろ書いたけど、僕が「つかいやすい」ということを伝えきれてないと思っている。結局の話、僕が使いやすいから、使いやすいのだ。そしてたぶん、僕以外は違うだろう。これに尽きる。

正直なはなし、キーボードがなんであれ、どうであれ、たぶん作業効率は変わらないと思う。如何にそれに習熟するかそれだけであって、習熟すればするほど、こだわりが出る。愛着が出る。元の記事も、この記事も、その道具の愛着故のことであって、その愛着を正当化しようとするだけの行為にしか過ぎないと思う。

あと、今後のコンピュータを考えるに、そもそもキーボードの需要さ薄れていくかもしれない。現に今の子供達はほとんど音声入力にまかせてしまって、キーボードの訓練をなかなかしなくなってきている。

最後に言わせてもらおう、USキーボードは使いたければつかうが良いけど、僕はJISのキーボードをおすすめする。ていうか、たかだがキーボードの選定のためにそんなに悩むな。以上である。

マンガログその1:「36.5度の天使 1巻」

はじめに

ちょっとマンガレビューを書こうと思う。

ここ2~3年、マンガを読むようになった。

読むようになったキッカケを述べておこう。いろいろ、飛行機で行ったり来たりするときに、乗り物の乗っている間暇なのだ。携帯やPC弄くっても良いが、電波がなかったり電源が切れると怖い。そもそも飛行機の中では使いにくい。なので、乗る前にコンビニや本屋で雑誌や小説などを買って読んだりしていたのだが、本だと眠くなるし、そもそも乗っている間に読むと酔う。雑誌のマンガだと酔いにくいのだが、途中から読んでも面白くない。だから、単行本を買って乗っている間に読むのだ。大体3~5冊程度買う。

そうすると、家に帰宅するときには、大体6冊~10冊ぐらい持って帰ることになる。まぁ、その後大体電子化するのだが。そんなこんなで、気がつくと沢山マンガを買っていた。すると困ったことが最近おこる。間違って既に買っているマンガを買うことが多くなったのだ。

マンガは1巻で完結することはまれである。大体、とあるマンガの単行本には、ある程度巻数があるのだが、そのたびたびいろんなマンガを雑多に読むので、あれ?僕どこまで読んだっけ?ってなる。そうすると、間違って、既に読んだことがある巻を読んでしまうのだ。

これは困ったなということで、まぁ、エクセルかなんかで読んだ本、購入した本を管理しようかと思ったけど、なんかそれではつまらないので、ブログのネタにしようってわけだ。ついでになんとなくレビューをしようと思う。

レビューの方針

レビューするときにちょっと僕なりの気遣いを表明しておこう。基本的にけなすことはしない。 どうやったら、楽しめるか?みたいなことを書いていく。というか書いていきたい。また、ネタバレはしない程度に。するときは白字で書くかな。

これは、毎回のっけておくかな。

さて、レビューをしていこう。

マンガログその1:「36.5度の天使 1巻」

今回読んだのは、「36.5度の天使」である。

これは、まぁ、基本的に表紙で買った本だ。

絵が綺麗だなと思った。すごく綺麗。わりと好き。わりと好み。

話としては、隕石が落ちて、なんかウィルスが蔓延している世界で、主人公とヒロインがなんか抗体を持っていて、なんたらかんたら。けれども、話としてはよくあるかなと思ったがなかなか面白い。

あと、エッチいシーンが多いのは好き。個人的に。というか基本的にエロいマンガは好きである。というか、表紙がエロかったから買ったんだが。

結構満足したのである。

そして、続きはどうなるのか?面白くなりそうなのでこれは期待できる。2巻は出てるみたいだが、まだ購入していない。

これからのUXデザインに行ってきたのでレポート

uxf-basic2017.peatix.com

僕のなかで「これからのUXデザイン」はブログ書いてないので、終了していない。 最近、終わってないイベントが多い。つらい。

あんまり僕は忙しいとか、そんなことは言わないのだが、なんというか、どんどんとやることが増えてるので、いろいろ遅れている。決定が間に合わないって感じの週だった気がする。

さて、ちゃっと、レポートを書いていきます。

イベント自体は、気楽に参加できた。というか、久し振りの「単純なる参加者」になったと思う。気楽。

f:id:Nobkz:20170630213130j:plain

写真はビアバッシュのもの。

さて、流れは、浅野先生のセミナー -> ビアバッシュな感じなので、印象に残ったり考えたりしたメモをちょっとまとめる。

まず、前半の方では、今のIoTやBigData、機械学習(AI)の時代になることによる、デザインについてだったと思う。この内容は、特にUXに関心のある、ない関係なく、聞いて言い話なんじゃないかな?

特に考えさせられるのが、「操作」についての話である。 この辺、最近僕は、Direct Manipulationに関する論文をひたすら読んでるので興味深い話であった。まだ僕はCLI からGUIになる時代の人間でしかない。もういちど自分の中で考えなおしたいのである。

後半は、いつもの感じだったが、バージョンアップしていた。考え直したのは、おにぎりの話。あれ、機械学習の「過学習」の話だなと思った。データが多ければ多いほど、機械は学習するのだが、学習しすぎると機械は間違ってしまうのだ。以前、梨を学習させた時、梨の画像を沢山処理させたが、洋梨を処理できなかった記憶を思い出す。

ビアバッシュ以降では、参加者がデザイナー、エンジニア以外にも広がっているのが面白かった。あとIoTの主婦が大興奮していた。

最後に、参加する前よりも、今後の時代が変わっていくんだろうと思った。僕は「エンジニア」だが、「エンジニア」であることは最早どうでもよくて、そのこれからの総力戦の時代の中で、いかにチームに貢献すべきか?ということを考えた方が良いと思った。まだまだ、学ぶべきこと、身につけるべきことが沢山ある。そんなことを感じるセミナーであった。

カタンの魅力と怖さ

最近、カタンをよくプレイすることが多くて、そして、ずっと思うことと、ちょっと思うことがあったので書いていく。

カタンは面白い。その面白さにはいろいろな意見があると思う。楽しみ方も人それぞれだ。僕は、「ゲームが勝ち負け関係なく、自分と『プレイしている面子』、そして『観戦者』も含めて、それぞれが楽しいと思える」ということを重視している。これは、そもそもカタンのみならず、僕がプレイするボードゲーム全般に言えることなのだが。

僕が最近気がついたのは、そういうプレイスタイルだから、僕はゲームに強いんだ。と思うことが良くある。ボードゲームってのは、一つに他人とのインタラクションを楽しむってのがあると思う。「自分がこういうプレイしたら相手が楽しいだろうか?」ということを考えるってことは、自然と相手の視点に立つことになる。そこには、「自分がこういうプレイをすると相手がどういう状況になるんだろうか?」「相手がそういう状況になったら、どのようなプレイが可能になるんだろうか?」とか自然と考えるようになる。また、相手を良く見ることになる。「相手の手札は何枚で資源はこれだけ持っていて」だとか「相手の資源の産出量は」とか「相手から見たら自分の手札は」とか、相手に関する情報を自然と把握するようになる。自然と相手の動き方を予測できるようになる。

あと、相手の動き方を予測できると言ったが、その期待に反する行動をして、なるほどってなるのも楽しいし、実は僕はそれが面白いなぁと思う。以外な動きをすると本当に面白い。学びがある。また、相手の演技や表情を見るのも面白い。「お~」とか「すごい~」とかよく喋っていたかと思えば、余裕がなくなると何も言わなくなるみたいな。カードを並べる癖だとか、沢山資源が出たときは、トレイからしれ~っと資源を取るとかね。

こう考えると、ふと、カタンの作者、クラウス・トイバーの言葉に「『また明日あなたと遊びたい』と、言われるようなプレイで遊びましょう。」を思い出す。それは、やっぱりゲーマーを強くする言葉だと最近思う。やっぱり、クラウス・トイバーは偉大だ。

あと、相手の動きのみならず、「観戦者が楽しい」というのも重要だなぁと思う。よく面白いと言わるゲームは観戦者が楽しくなる要素がある。それは、実は「負けても楽しい」と思える要素だと思ったりもする。そして、またこれもゲーマーを強くする。それは、一つに俯瞰的な視点を得られるということだ。 僕はこのゲームがテレビで放映されていたら、視聴者は楽しいだろうか?という見方をしている。やっぱりそれは、自分や相手の視点だけでない、客観的な視点を得られる。ゲーム上で何が起っているのか?というのが把握できるようになる。また、ゲーム上においてのマナーや発言が楽しくあるようにする。まぁ、僕は雑で気が聞かない性格なので、よく失礼を働いて申し訳ないと思うのだが。

さて、最近のことを話そう。最近ちょっとカタンをプレイしていて、カタンの怖さと感じることがある。しかし、それは逆にカタンの面白さである。それは何か?というと、カタンが一つのミスですごくゲームが動くんだと思うのである。それは最近いくつかあった。

最近、てか、昨日の深夜、てか今日の午前か。10点、5点、5点、5点でゲームで勝った。それは、他がゲームの初心者ではなく、ゲームをある程度プレイしている経験者である。むしろ、強いと思う人達である。

僕はわりと、先行して逃げ切りたいタイプであって、先行して逃げ切るには、単純に生産量パワーやゲームの展開の最適化を行なうようにする。そのプレイだと、わりと叩かれる。飛び抜けてしまうので、みんなで、飛び抜けた人を叩こうとする。そして、1 vs 3になる。ちなみに、それが僕にとって楽しい状況である。他人が以下にして僕を苛めようとするのが観察できるからね。そして、わりと盗賊を置かれたりするのが気持ちが良い(笑)。とある人から、ドMと言われまくっている所以かもしれない(笑)。

んで、先の、10点、5点、5点、5点でゲームで勝ったときというのは、なぜそういう状況になったかと言えば、たった一軒の開拓地のせいである。一人のプレイヤーが、トップ目(僕)ではなくて、他の人が建てたいと思うところを妨害するようなところに開拓地を建てたプレイをしたのである。そのおかげで、3人が協力体制にならず、その人との生産力の勝負になってしまう。

f:id:Nobkz:20170603161902j:plain

ただ、その時僕は、すごくぞっとしたのだ。よく考えればそのミスは観戦者の視点からはありえない置き方かもしれないが、その人から見ると、ある意味最善手に見えるからだ。わりとしやすいミスであると個人的には思う。しかし、それで、このようなワンサイドゲームができるとはという感じである。僕は、その時は、勝ったときに嬉しさを感じるというより、ゲーム全体として、「こういうこともあるんだぁ」という思いである。

そして、その時は、その後にもう一戦やって、僕が勝ったのだが、僕の反省としては「どうしたら、もっと周りを楽しませられるんだろうか?」という点をずっと考えていた。しかし、競技である以上、ゲームの非情さってのは付きものなんだろうなと思っている。その非情さが、ゲームを面白いと思わせるものでもあるのだ。

また、もうひとつ話そう。僕が8点、周りが、9点、7点、6点の盤面である。6点の人の視点に立つと、やっぱり9点は怖い。だから、9点に集中してしまう。そのような状況である。しかしながら、僕は、7点を注目していた。なぜなら、9点の人は、道を2本建てて、家を建てないと勝てなくて、まだまだターンが掛るからだ。最大の生産力を持ったとしても、2ターンはかかる。そのような状況で、怖いのは7点の人である。騎士王か道王を取り、1点を稼ぐみたいなプレイが1ターンでできるような、最大生産力を持っている。それが起こる確率を持っていた。そして、6点の協力体制を築くかないといけない時に僕は築けなかったなと思うときである。どう説得すれば良かったのだろうか?と思うことがよくある。似たような事例で最近良く負けることが多いなぁと思う。

最後にもうひとつ、僕は、とあるところに開拓地を建てて…ってことを考えていたが、そこに都市化材交換する交渉を持ち駆けられた。僕の視点からは、その交渉で、相手に道材を渡して、都市化することが次のターンでできるような交渉だった。あとでその道を建てて、開拓地を建てれば良い。そして、そちらの方が強いなとも考えていた。しかし、その交渉で、僕が建てたいと思われる場所に開拓地を建てられてしまったのである。そして、生産力の差で負けてしまった。

カタンの非情さは、道や開拓地の建て方、協力体制の築き、相手との交渉において、一つのミスをすることによって、ゲームがすごく傾いてしまうことにあるのである。そのミスとカードの引き方や、ダイスの出目次第では、どうしようもないことが起る。それは、魅力であり、怖さでもあるのだ。

KA法の練習会に行ってきた。

KA法の練習会に行ってきた。ひさしぶりのUXブログである。

ux-fukuoka.connpass.com

日も経っているが、覚えている範囲で書いておこう。

さて、この日、僕は別の技術的な研究があって徹夜であった。僕は「忙しい」と言わないように努力しているが、思わず「忙しい」とつぶやいているほど、最近楽しいのである。

それで、徹夜で参加したのにもかかわらず、とても良い学びができた気がする。しかし、やっている間は渋井顔をした浅野先生がずっと脳内にいて、「まだまだだな、はなだくんは~」って言われいる気がする。

さて、書いていこう。

着いたときは、まだまだ、会場はがらんとしていて、会場設営から始めた。机を5つ並べて、模造紙があった。

f:id:Nobkz:20170513124527j:plain

さてさて、いつもどうりヨシカワさんの説明。説明というか若干、講義である。ずっと先生やっているからねぇ。

f:id:Nobkz:20170513131339j:plain

さてさて、ワークショップをやる。最初に、インタビューの調査の結果などから、カードをまず作成する。カードには、出来事、心の声、価値を書いていく。

KA法の練習シートがあってまず、カードの書き方を学習した。なんというか、ここで出来事だけを読んで、「自分に置き変えて考える」ってのはあんまり良くなくて、ユーザを意識したほうがいいんじゃね、的はことをしゃべった気がする。

カードの出来事はあくまで、その人のインタビューした結果である。そして、「心の声」というのは、そのユーザの内面を「そのユーザの言葉で」書いていく。これがまず難しい。

そして、「ユーザの言葉」から「価値」を書いていく。これは、僕は「翻訳」作業のように思っている。「ユーザの言葉」というを自分たちの言葉に「翻訳」する作業である。

カードがたくさんあって、書くのが大変だった気がする。時給が出ると思った。

次に、カードをグルーピングして、「価値マップ」をつくって行く。

f:id:Nobkz:20170513170528j:plain

この作業が大変だった。やっぱりグルーピングして行く。「似たようなもの」を探す。カテゴライズではなく、「似たようなもの」である。表面ではなく、その背景を考える作業だ。何が大変かといえば、枚数は忘れたが、60枚だっけ?を似たようなものを探す作業である。ある1枚と似ているものを59枚のうちから選んで行かなければならない。

そして、ある程度まとまったら、そのグループに対して、上位の概念を入れていく。これが難しい。しかし、僕は一番クリエイティブな作業だと思う。上位の概念は抽象化しすぎると意味がない。最大の抽象化は「幸せになること」と書けるからね。

なんとなくコツが掴めてきた感じがする。あくまで、この抽象化は「誰でも思うこと」ではなくて、「その人(ユーザ)が思うこと」に関する抽象化である。だから、価値マップが書いたときに、ありきたりなものではなく、その人ユーザの独自性みたいなものがなければならないと思う。人間を理解するって難しいな。

さて、まとまって、価値マップを作成したら、発表である。

f:id:Nobkz:20170513173137j:plain

いろいろ聞いていて、思うことは、同じデータを活用している筈なのに、チームによって特色が出ることが面白い。着眼点が違う感じがした。みんなでやると、ぼんやりと見えてくるものがある。

最後に、ヨシカワさんが、「結果ではなくて、みんなでやること自体が大事」って言うてたけどその通りだと思うんですけど、まぁけど、結果を出さないとダメだよねって、グルグル思っているところです。

みんなでやって「ユーザのこと分かってなかったわ」と言うてもわらないと、ダメなんだろうなという感じです。カンタンじゃない。効率ではない。非効率で難しいものです。

だから、コミュニティで、いろいろ共有できたらなーと思っているところです。 まだまだ、勉強しますよー。

結局VanillaJSである。

anond.hatelabo.jp

nida3001.hatenablog.com

上記のブログに刺激されて私もフロントエンドというかJavaScriptに対する思いを綴ったポエムをば。しかし、なんか書くのダルいので、大分大雑把にかくぞ。

さて、さっそく結論を述べよう。今のフレームワーク論争やらに対する解決策はVanillaJSを使うってことである。

フロントエンドSPAのフレームワークについて

まず、今のほとんどのフレームワークが使えないってのはそのとおりである。その話してみよう。その理由は、「フロントエンド」 ってのは一括りにできないからである。「ハッカーと画家」のとある言葉をアレンジして言えば「フロントエンドはユーラシア大陸のようなものである」。フロントエンドが関わる範囲が大きすぎるのである。ヨーロッパもあればアジアもあれば中東もあるという感じである。

範囲が大きすぎて、フレームワークとして扱えるほど技術が抽象化できないのである。だから、そもそもすっげーReact+Reduxに乗っかれるところもあれば、そうでないこともある。フロントエンド一般じゃなくて、もしそれがSPAの範疇だとしても、SPAのすべてのプロダクトで抽象化できない。というか、できていないと言った方が正しいのだ。

フロントエンドで難しいことやろうとすればとことん難しくできるし、フロントエンドで簡単にやろうと思えば簡単にやれる。だから、複雑なところたとえば、フロントエンドSPAやらであれば、フレームワークのことやAltJSやTypeScriptを考える人が多いだろうし(僕はそれでもVanillaJSで書くのだが)、そのクライアントのところでゴチャゴチャしないんだったら、jQueryとかでいい(僕はそれでもVanillaJS…)という考えもいるだろう。

また、フロントエンドのSPA自体の話を考えてみると、あれはフロントエンドでGUIをちゃんとやろうとすることだと思っている。そしてGUIは難しい。

GUIは難しいってのは、僕はツイッターとかで何度も言ってきたと思うけど、改めて言うと、まずその非同期性、GUI のアプリケーションや操作などの状態管理、ユーザ行動の非決定性、そして速度やらと戦わないといけない。また、そのUIデザインと実装を分けて考えることはできない面もある。インタラクションをきちんと考えると難しい。

そのようなGUIに大して設計、実装技術の歴史はあった。GUIの設計や実装の歴史を調べてみると、実際に昔から発展してきた。しかし、Webが台頭してくると、GUIの文脈は引き継がれず、Webが独自に発展していった。そうして、フロントエンドSPAの時代になり、またクライアントサイドMVCであったりとかフロントエンドはそういった議論になっていった。僕から見れば、それらは、昔のGUIの設計や実装技術をやりなおしているようにしか見えなかった。

だから、

ウェブフロントエンドの技術の進歩と興亡の速度には目を見張るものがある。

ということに大しては、違和感しなかくて、そもそも既視感がありありとあって、「進歩」しているようにはまったく思えなかった。(ただ、その中でも、WebのSPAだから出てくる問題もあってそこは、今までに無かったことはあった。)

また、フロントエンドSPAのフレームワークを見ていくと、僕にはただのWebアプリの延長としてか考えてない人達が多くて、そもそもGUIとしての実装を思ってない人が多い。だから、そういう人達と議論しても議論がまったく噛み合わないことが多い。サーバーサイドレンダリングをしたいだけの人達が多い。そのUIやらインタラクションを考えずに。だから、はっきり言っておこう。当たり前なのだが、フロントエンドとバックエンドの技術は異なるのだと。

まずその人達と会話すると「フレームワークの選定」から始まる。僕としては、おいおい、なんでいきなり、「どのフレームワークを使うか?」になってるんだ、いきなりフレームワークに乗っかる前提になっているだ? という思いになる。まず、設計の話をしろよと。設計してから、フレームワークをどのフレームワークにすべきか、そもそも使うべきか使わないか、などを考えるべきである。

さっきも言ったがフロントエンドはバックエンド程抽象化されてないのだ。だから、「デファクトフレームワーク」だとか、「無難なもの」なんて無い。もちろん、僕はフレームワークをつかうなと言っているわけではない、いろいろ設計した上で、フレームワークにのっかれると思えば乗っかればいいのだ。しかし、設計もなくフレームワークにただ乗っかると、結果、フレームワークの設計と、自分たちのアプリケーションが合わないなんてことが多発する。そういう人達をたくさん見てきた。

僕はVanillaJSを使う。「VanillaJSを使う」という意味は、まず設計から始まるってことを言いたいのである。フロントエンドSPAについて必要なのは設計である。設計した上で、その「プラグイン」として、フレームワークやライブラリを利用するのだ。

また、おすすめしたいのが、フレームワークの実装を読むことである。また、フレームワークを自作してみよう。そうすると他のフレームワークの実装がより理解できる。自作した上で、他のフレームワークを利用することも多々あるのだ。むしろ、そのお陰で上手い乗っかり方が分かる思う。

デファクト」に頼るな。JSの「トレンド」「デファクト」ってのは、多数の人達が「使っている」にしか過ぎない。JSの人達は、すごい人達ばかりじゃなくて、阿呆もいる。玉石混合なのだ。「デファクト」は単純にマーケティングが上手くいったとかしょうもない理由でデファクトになっていることが多い。だから、デファクトフレームワークが一番素晴しいなんてことないし、安定しているなんてことはない。むしろ、安定していないからこそ「トレンド」がコロコロ変遷するのだ。

「トレンド」がコロコロ「変遷」する。と言った。ここで、僕は「進歩」したとは言ってないことに注意したい。トレンドが変遷することと、フロントエンドが進歩したを同じではないのだ。言うが、フロントエンドの技術はまったく「進歩」していないと思う。トレンドが変化しているだけなのだ。

jQueryじゃなくて、なぜVanillaJSなのか?

さて、jQueryを使い続ける、って結論の人達が多いのだが、僕はjQueryを使わない。というか使う必要が無いと思っているのだ。

以前、

qiita.com

なんてVanillaJSの入門記事を書いたのだが、そのコメントで書いたことを引用する。

たとえば、jQueryは速記記法であり、また、ブラウザ間の違いを吸収したJSのライブラリで、以前はデファクトスタンダードなライブラリで、DOM APIを学ばずjQueryだけ学習するということがことが起っていました。しかし、その分オーバーヘッドもあり、また、HTML5になり、ブラウザ依存度が低くなり、DOM機能も便利になった今、「jQueryが前提」という考えはとても技術的選択の視野を狭くする、もったいないものです。そもそも、フロントエンドエンジニアであるならば、DOM APIは知っておくべきじゃないでしょうか。

ということである。

もちろん、既に書かれたjQueryのコードを今更Vanillaにしろなんてことは言わないし、たぶん僕もそんなことはしないような気がする。しかし、今後フロントエンドのコードが肥大化するのであれば、まずVanillaにすると思う。

jQuery」というのは、多くの人達は「フレームワークの利用」を考えるだろうが、僕は文字通り「jQueryをつかわないようにする」ってことをやると思う。「jQueryもなく、そこに設計されたVanillaJSのコードがあるようにする」ってことである。そうした上で、フレームワークの利用を検討するというのは考えてもいい。

ぺちぱーエンジニャーからのフロントエンドに対する思い - 虚無愛好部活動記録 こちらのほうで

結局jQueryはVanillaJSの便利なラッパーでしかなく、つらいつらいDOM操作の悪夢に悩まされるのはJavaScript使う以上どれでも変わらないでしょう。それなら記述量の減るjQuery使えばいいじゃん派です。

僕としてはjQueryを使っても、記述量はそこまで減らないし、DOM操作をするんだったらそもそも、VanillaJSでええやんって感じだし、なので、jQueryはVanillaJSの便利なラッパーではない。という意見である。「お前のなかではそうなんだろ」と言われそうではあるが。

設計しろよということ

結局僕は、jQueryも嫌ってはいないし、フレームワークを嫌ってはいない。設計されてないゴチャゴチャしたコードが嫌いなだけなのだ

本来、ソフトウェアエンジニアである以上、設計することは当然なのだが、何故か、サボっている人達が多いのだ。サボってサボってサボりまくって、コードをごちゃごちゃにしている。本来であれば考えないといけないことを、考えずに過ごしている人達が多いのだ。本質的なことを考えずに、最新のトレンドだからだとか、騙し騙しコードを書いているのだ。

書くの疲れたので辞めにする。ああ、僕も丸くなったものだ。