「当たり前なことをやればいいのに、なぜ勉強するのか?」ということについて

久し振りになにかポエムでも書きたくなったのですね。コミュニケーション苦手な人ががんばって書いた。

「当たり前なことやるのに、なぜ勉強するの?」

フロントエンドエンジニアの会の方々を会話したときに、UXの本で教科書的なの無いと言われてとりあえず、「UXの教科書」を勧めた。

その時にその人に「UXの人と話して、当たり前なことをやればいいって言う時があるけど、自分は当たり前なことをやっているから特に勉強しなくても良いよね?」云々という発言をされたとき、ある気づきを得たので、ちょっと「なぜ勉強するのか?」について、僕の意見を述べておこうと思う。以下はUX関連を想定していいるが、別に他の領域でも当てはまることだと思う。ちなみにその人には「その件、ブログでまとめるから読め」と言った。

日々、何かを勉強し、実践していくと「良く考えると、これ当たり前なことだな」って思うことが多い。そういう気付きを得たとき、まわりの人達に共有して、「当たり前のことだなと思う」とか言うことが多い。そして、僕は何かUXに関する会話のとき、ときどき初学者に対して「当たり前のことをやれば良いんだよ」とか言う事も多い。

どうやら、そうすると初学者は「当たり前のことだから、あんなに沢山本を読んだり、ワークショップに行ったり『大変』なことしなくていいよね?」と思うらしいのだ。

「当たり前」の認識の違い

始め僕はどうしてそういう考えに至るのか、って良くわからなかった。しばらく考えていくうちに、他の人達と会話していくうちに、なるほど納得したと思うようになった。

まず、第一に「当たり前のことがちゃんとできている」って考えがあるってことだ。それには「当たり前」を「普段、普通に、日常的にやっていること」と解釈しているような気がする。だから、「普段やっていることをやればいいので、自分はやれている」と思ってしまうのだ。また、「当たり前」というのを「普通でまともな人が共有していること」と思っている場合もある。この場合も、「自分も普通の人で、まともな人」であるという意識があって、だから、自分も共有しているはずで、その通りやっている、みたいな考えを持っているように思える。

こういう考えに立ってしまうと、なるほど、わざわざ小難しいUXの本を読む必要も無いし、日々勉強すること自体が意味を成さないように思えてしまうのであろう。

また、「勉強する」その目的は、「自分達の知らない、何か真新しいもの。劇的に何かが変わるもの、改善するものを知る。身につける」である認識があるように思える。しかし、「当然のこと、当たり前な」と言ってしまうと、期待したものが得られない、ということにもなってしまうだろう。そもそも、勉強して分かる素晴しいものの殆どのことは泥臭くやって見つけることで、スマートには見つからない。

一方、僕は無意識に「誰が考えてもそうなること」を「当たり前」と言っていた。その前提として、「本質をつかむ」ということがあると思う。つまり、「本質を知ると、当然そうなるよね。」ということだと思う。逆に本質が分からないと、「当たり前の事が理解できない」ということである。

何かを勉強する、何かを学ぶことによって、なにか本質的なことを掴んだとき、凄く新しい発見や事実、概念、アイディアなどをその真新しさを感じることのように思える。その時は、その新しさを感じながら、どんどんと真髄を究めたいと思う。しかし、とある地点から、「ん?これ当然のことじゃね?」と思うようになってくる。そうして、「新しいこと」だと思えたものが「よく考えたら当たり前」ってなるんだ。

僕はそういった経験をたくさんしてきていて、最近考えるようになってきたのが、「学んで勉強して分かる本質的なこと」のほとんどが良く考えたら現実に合致している「当たり前」であるということだ。直感的でないような事実も、それは現実に起きている事実であって、本質的で、当たり前なことのように思える。「現実に起っていること」「本質的なこと」が「当然のこと」なのだ。

なぜ勉強するのか。

とすれば、「何故勉強するのか?」というのは「当たり前のことが分からない」し「当たり前のことができないから」ということだと考える。「いま自分にできない当たり前の何か?」を発見するということがまず勉強することの一つであるようにも思える。だたし、それは「当たり前にできるよう」になるってことじゃあなくて、その一歩手前の段階である。それだけではできないのである。

「当たり前のこと」をいきなりやることは難しい、「普段やること」とは違うからだ。

たとえば、ダンスをやっている人の時の話を聞いたことがある。ダンスの先生のカッコイイ動きを真似するためには普段と違うことをやらないといけない。普通じゃないのだ。しかし、初学者や下手な人達は、「自分がやりやすい動き」をする。そして、初学者や下手な人は「自分がやりやすい動き」をしたがるし、そのことに気づいていない。上手くなる人ってのは、その本質に気づく。「普段やらない動き」に挑戦するのだ。最初は失敗するものだし、しかしそのことによって「普段やらない動きが普段やる動き」になる。とダンスやっている人と飲んでて話しを聞いたことがある。

それで、「普段違う動きをする」ためにはまず、「当たり前」のことができないと認識することがまず大事なんじゃないかと思うのである。その為に勉強するのだ。

普段から現実に何が起っているのか?という関心を持ち、観察したり整理したり、思い込みを発見し、他人と議論し、自身を修正して行きながら、本質を掴んでいくものだと思う。本質的なことが見えてくると、それが「当たり前」になり、あとはそれをやるだけになる。「やるだけ」が難しい人が多いのだが。

以上が「当たり前なことやればいいのに、なぜ勉強するの?」ということについての回答である。「あの人」は参考になっただろうか?

UX シンポジウム2016 福岡にスタッフとして参加した件

uxsymposium2016.peatix.com

さてさて、久しぶりですが、書いておきます。UX シンポジウム2016 福岡にスタッフとした参加した件。

ラーニングバーについての学びと、準備

一番最初に、ヨシカワさんから、UXシンポジウムの話を聞いた。そのとき、LTを企画したりしたのだが、最終的にラーニングバーをやることなった。

始めて開催するので、僕は早速本を購入して、読書をした。そういえば、最近本が増え過ぎである。

さて、ラーニングバーの書籍を書い、いろいろ面白い本だなーって読んで思ったりした。

開催まで1ヶ月ぐらいかな? そのとき、UX Fukuokaでシンポジウムミーティングをして、森田先生から、ラーニングバーや、ラーニングバーのやり方の説明や相談をしたりして、理解を深めた。

こうした、ラーニングバーの学びもあったりしたが、もちろん、準備もした。今回は準備は前回より楽だった気がする。

参加者の増え方は今回びっくりした。1週間で30~40人ぐらい増えた? 掛け込み多すぎである。

当日

当日は、朝の8:30ぐらいにおきた。というか、犬に起こされた。そして、パンを食べた。いつものパンの味だった。そのあと、時間に余裕があったので、開発機を起動して、軽く、最近作ってる、SQLビルダーの開発を少しした。まずまず進んだ。

うだうだやってると、UX FukuokaのメンバーがSlackで、出発の連絡があった。僕はわりと、比較的、家と会場が近いところにあったので、遅く出ても大丈夫だった。とはいえ、いいぐらいであったので、準備をして家を出た。

会場に付いてから

会場は九州産業大学である。UX シンポジウムのサインの確認をしながら会場に向かった。案外駅から遠かったように思える。

会場に付く前に、メンバーと食堂で合流した。ざるそばを食べた。以外と量が少なかった。あと、食器片づけるのがちょっと分かり辛かった。

会場につくと、九産大の学生さんたちが既にいて、椅子が並べてあった。今回は九産大の学生さんたちが良く働いてくれて、助かったと思う。学生さんたち、おつかれでした。

f:id:Nobkz:20160702121220j:plain

学生さんたちとメンバーの挨拶をして、僕は、マイクの確認とか、照明の確認など、机の移動や荷物を運んだり、twitterハッシュタグ確認などをしながら、準備をすすめて行った。

f:id:Nobkz:20160702125845j:plain

f:id:Nobkz:20160702125831j:plain

f:id:Nobkz:20160702125849j:plain

準備している間に、浅野先生や、倉光さんが来られた。そうして、さらに準備していると、参加者の方々も続々と来られた。

スタート

そうこうしているうちに、UX シンポジウムが始まった。最初にヨシカワさんと森田先生から説明があり、すぐに浅野先生の登壇に移った。

f:id:Nobkz:20160702154016j:plain

浅野先生の話

最初の浅野先生のセッションがあった。毎度おなじみの話が多いのだが、復習として聞いて良かった。ただ、初めての人達には情報量が多い濃密な時間なんじゃないかと思う。というか一回聞いただけじゃ、やはり難しいところがあるとは思うので、是非とも今後UXのコミュニティに参加されたら良いと思う。あと、資料もまだまだあるらしいので、聞きたい方はまた勉強しに来て頂ければと思う。

倉光さんの話

浅野先生のあとは、倉光さんの話。ピースご飯が一番印象に残っている。倉光さんのがゲームのUIから入って、UXを学び、クックパッドまでの経緯や、クックパッドさんのデザインの実践の話が結構あったと思う。地道に、やっていたんだなと思った。クックパッドさんはクックパッドさんのやりかたで、デザインをされていると思うので、自分達がどういう風にやるべきか?を考え自分達で実践し、効果を挙げて売上を伸ばすまでということを考えられるかが、勝負であるとは思う。

ラーニングバー

これが、一番面白かったところである。

倉光さんのセッションが終わり休憩の後、机を移動した。

f:id:Nobkz:20160702155609j:plain

さて、机を移動した後、サンドイッチやおかしが机の上に置かれた。その後森田先生から、ラーニングバーの説明があった。

f:id:Nobkz:20160702155827j:plain

そのあとラーニングバーがスタートした。

いくつか島ができていた、最初、みんななんの話をしたら良いか分からないという感じだったが、とりあえずみんなで自己紹介をしながら、立ち話で、「今日はどうだったか?」みたいなことを聞きつつ、最初は懇親会の雑談みたいになっていた。

f:id:Nobkz:20160702164140j:plain

そして、浅野先生から、全体から10個ほどテーマを出して、テーマを出したオーナーを中心にグループを作り直して、再度そのテーマについて議論するという流れになった。

テーマはホワイトボードに書いて、参加者の名前を付箋を貼り、グループになる感じ。

f:id:Nobkz:20160702170358j:plain

ホワイトボードを凝視して、どのテーマに行くかみんな考えている感じ。

f:id:Nobkz:20160702164450j:plain

始まってみると、みんな活発に議論をやり出してすごい。やはり、参加者毎に関心や層が違うので、共通のテーマを持っている人達は、議論しやすいのかと思った。

f:id:Nobkz:20160702174125j:plain

UX Fukuokaのメンバーはファシリテータとして参加するが、なにもしなくても議論が活発になっていた感じ。僕は倉光さんと学生のお悩み相談のシマに行った。福大生で、大学で、自分達で学びとして、経営を実践しているということ。まだ、社会人の感覚みたいなものが分からない感じがあって、教える先生って大変だなぁとか考えていた。

そのあと発表があった。グループ毎に、議論の流れを発表して、浅野先生や倉光さんに意見を感じ。学生の発表が長々と時間を取って面白かった。「学部生に教えるのはつまらない」ってのがひっかったみたいで。

f:id:Nobkz:20160702175452j:plain

そんで、時間が伸びそうになったが、森田先生がしっかり調整してくれたみたいで、時間ちょっきり、グループ全部の発表が終わった。すごい。

そんで、最後に、会場を移して、参加者と登壇者とスタッフで飲みに行った。

個人的に思ったこと。

ラーニングバーは難しいなと思った。細かいとこだが、おそらく付箋を使わせるなら、付箋を張るスペースが必要だと思うし、今回はサンドイッチやおかしがジャマで張れてない感がある。あと、机の高さも問題なように思える、もっと付箋を書いたりする工夫が必要である。立食形式にしたが、最終的にみんなイスに座って議論していた。イスに座ったほうが、付箋を書くなどの作業がやりやすくなるのだろうか?

最近、UXの読書会などと、コミュニティの活動を続けていたのだが、今回のイベントを通して、以外にも、いろいろな人達がUXに関心を持っていることにまず驚いた。そんで、今後の活動に新しい人を入れるようにアプローチを変えて行きたいと思った。

今迄は、「自分達だけの学び」で必死だったが、今後は初心者と共に、いろいろなことを学ぶ場にしたいと思う。UX Fukuokaはなんか怖い会と思われている様子で、そんなことは全然ないということを伝えていきたい。

参加者の中にも、HCDやUXデザインなどに興味を持ってくれて、もっと勉強したいと話していたので、是非とも一緒に勉強していきたいなと思った。

  • 関連ブログ

みんな書くの早い。書くスピードほしい...

UXシンポジウム2016 福岡に登壇して来ました | 経験デザイン研究所

UXシンポジウム2016福岡でラーニングバーをやってみた - モリタヤスノブログ3.0

UXシンポジウム2016 福岡 に参加した - hor.note

UXシンポジウム2016福岡行ってきたよ。【ラーニングバー編】 - miki_mgh’s diary

UXシンポジウム2016 福岡レポート | Developers.IO

UXシンポジウム2016へ参加しました – デザインの考察、思考についてのブログ

主要な6つのプログラミング言語について、とくに説明もなく紹介

プログラミング言語を紹介する

世の中には、いろいろなプログラミング言語があり、どれを選べばいいか分からない! って人達が結構います。なので、その人達のために、僕がよく使っている良く使われているメジャーな言語を紹介します。以下のプログラミング言語を学ぶのが普通のプログラマーだと思います。

あ、説明はしないです。適当にリンクだけ張るからサイト見てね。あ、Shenだけ説明しようかな。 気がむいたら、ちゃんと新しく記事を書く。

Pony

www.ponylang.org

Nim

index - Nim Programming Language

Nemerle

About - Nemerle programming language official site

J

J Home

Haxe

haxe.org

Shen

Home | Learn Shen | OS Kernel Do

Shenは神です。

SPAである価値

以前、少し前だが、以下のブログを読んで、SPAであるべき価値について考えたことを述べる。

anond.hatelabo.jp

mizchi.hatenablog.com

そもそもSPAとは?

この議論をする前に、そもそもSPAとは何だろうか?という点について整理しておこう。僕は2つの点で特徴があると思っていて、

  • フロントエンドGUIであること
  • Webアプリケーションであること

この2点かなと思う、簡単にまとめると、

フロントエンドGUIであること

まずは、「フロントエンドGUI」というのはどういうことかと言えば、サーバーサイドレンダリングとは対照に、jsによるDOM操作によって、UIを切り替えて行って構成するGUIを指す。

Webアプリケーションであること

GUIではあるのだが、それは、Webアプリケーションでもある。サーバーからAjaxやwebsocketなどによって、サーバとデータのやりとりをする。

ここいらの話は、思う所が結構あって、たとえば、webの技術と、GUIの技術が交わっていることによって、コミュニケーションがおかしくなったりとか、そういうことがある感じがしたりしているとか。まぁ、これは話が外れる。さて、SPA の価値について考えてみよう。

SPAの価値

先程のエントリから、幾つか、抜粋、引用する。

まずこれ。正直そんなにたくさん動的にがりがり書き換えているページをあんまり見ない気がするんですよね。その上正直そういうウェブページ、あったとしても大体使いづらいです。 世の中のページが全部FBならいいのかもしれませんが、具体的にはどんなところで使ってるんでしょう。業務ページとかですか?あと、なぜSPAにしなければいけないのかもよくわからないです。画面遷移するのだめなの?という感じで。 (http://anond.hatelabo.jp/20160521163144 より引用)

この点について、mizchiさんも、いくつかアンサーを出していたが、この点を僕なりにまとめたいと思う。(これが、本ブログの趣旨である。)

まず結論から言えば、「ちゃんとしたwebアプリケーションのUIを考えたら、SPAにならざるを得ないということが多い」ということである。順番に言って行こう。

SPAと「使いにくさ」

SPAと「使いにくさ」は関係がない。

まず、言いたいことは,SPAであることと「使いにくさ」は関係がないということである。一般に使いにくい、UIの原因は、「そもそも操作が複雑であること」と「UI設計が糞」であるかどちらかである。

そもそも操作が複雑であること、これが挙げられると思う。つまりアプリケーションが本質的に難しいのだ。toBのアプリケーションやら、ギョームのアプリケーションでは、仕方無い面があるとは思う。特殊なパターンに対応しないといかん場合が多いからね。一方、一般の人達が使うのを想定するtoCで、本質的に難しいアプリケーションを作る奴は、大抵、UXとかビジネスとサービスの根本から考えなおせクソ野郎である。

UI設計が糞というのは結構多いと思う。というのも、根本的にUIを設計ができるデザイナ、エンジニアがいないってのが問題としてあると思う。たぶん、UIの設計をやる人達は、Webデザイナだとかが多いのだが、Webページを作るデザインと、GUIを作るデザインは異なるのであり、おそらくだが、GUIのインタラクションについて考えられてないとか、そもそもユーザを定義して、ちゃんとUIを設計できるってスキルが無い人達が多いと思う。SPAの自由さを活かして、よりよいユーザのためのUIデザインができるデザイナはなかなかいないのである。

多くのSPAの場合、SPAのその表現の自由さの影響で、糞UIが生まれてくることも多い。自由すぎるのだSPAは。その結果、その自由さによって、良いUIであろうが糞UIであろうが、自由にUIを作ることができるのであり、その結果、UIデザイン、さらには、フロントエンドの技術的な設計まで複雑さをもたらしているということである。ゲームのインターフェースが素晴しいとか、ゲームの体験がすばらしいからといって、マイクロインタラクションやら、アニメーションを一杯入れて、独自の世界観を作り出し、結果糞が生まれてくる、など良く聞く気がする。

SPAが「使いやすくなる」こともある

一方で、SPAは使いやすくなることがある。一つの「使いやすさ」の指標として「ユーザのタスク時間」を考える時があるが、SPAを使う事によって、タスク時間を短くすることがある。というのも、サーバーサイドレンダリングで、一々ネットワーク越しに、通信して、Webアプリケーションを使うというのは、「遅い」のであり、SPAにすることによって、解決することがある。つまり、SPAにすることによって、ユーザとコンピュータの応答を素早くする効果がある。

もちろん、「タスクの時間」は、他の事、たとえば、画面のレイアウトだとか、ページの情報の設計だとか、その他にも影響するのだが、ユーザとコンピュータの応答を素早くするは一つの方法としてあるだろう。つまり、有効なことではないが、ある程度SPAにすることによって改善することもある。また、ページ遷移履歴の管理をスッキリさせることによって、無駄な戻るとか、進むを無くしたりして、「使いやすく」なるということも考えられる。

つまり、SPAは自由な表現とさっき言ったのだが、もちろん、ちゃんとユーザ調査、定義をして、UI設計をすることによって、より「使いやすい」ものを提供することができるようになるということもある。

ちゃんとした、まともなwebGUIを作るためのSPA

結局のところ、まともなwebのGUIを作るために、SPAであるべき(ことが多い)ということです。SPAは種々の、UIデザインの問題や、フロントエンドのGUIの技術的な設計が、難しくなることが多いが、一方で、使いやすい、よりまともな、GUIを提供できるというのが、SPAである価値であると思う。ユーザにとって需要が無いということであるのではなくて、それこそ、ユーザが気づかない潜在的なニーズに答えるというのができる可能性があるということである。

追記、誤字、脱字について

当エントリじゃなくても僕のブログは基本的に僕の考えや行動の記録でありメモであり、推敲やら見直しやらは基本的にしないで公開している。ただし、指摘があったら修正する。あとときどきたまに直したりする。「誤字が多い」とか愚痴をコメントで言うぐらいだったら、指摘した方が建設的ですよ。

自分が書いた文章なので、自分が読みやすいというのは当たり前で、人が読みにくいなんてこと結構あることを分かって頂きたい。人に読ませる文章であれば、他の数名にレビューして貰ったりするのだが、こういうブログではその負担はキツい。だから、悪いというのをただ言うのではなく、どこが悪いのか、そしてどう直すべきかというのを指摘すると、それは直すのでそのような指摘を頂けると助かるのである。

追記2

id:nurehaさんの指摘頂き、ありがとうございます。やっぱり、こういう誤字や脱字は書いた本人は全然気づかないものです。

英語とプログラミング

あと、もう一本、エントリすることにする。

まぁ、この記事についてだが....

d.hatena.ne.jp

ちょっと、ツッコミながら、僕も言いたいことがあるので言うていく。

英語の学習時間を考えてない。

、やはり「英語を先に学んでからプログラミングを勉強した方が、圧倒的にプログラミングの学習効率が高い」という結論に至りました。

「プログラミングを学んでから英語を学習するよりも、英語を覚えてからプログラミングの勉強をした方が圧倒的に学習効率が良い」というが、このエントリ、全く英語の学習時間を考えてないように思える。

そもそも、その文系大学生ってTOEIC940点になるまで、どのぐらい勉強したの? という感じで、そもそも、英語を勉強していた方が、学習が早いからって、「英語を勉強していた方が学習効率が高い」とはいえんやろというか。それを言うのであれば、英語できない+プログラミングできないで、「英語->プログラミングの順番に覚える」と「プログラミング->英語の順番に覚える」ということをやるべき。

というか、英語覚えながらプログラミングやるやろ普通は。

英語関係なしに、「デキルやつがプログラミングやっただけ」

正直に言うと、思った以上に成長が早くないというか、「ふつうに、デキルやつがプログラミング覚えたらこうなるわな。」という感じである。

ぶっちゃけ、いやまぁ、悪いけど、この記事に出てくる文系大学生、僕からすれば...そんなにプログラミング覚えるの早くない気もする。ここについてはあんまり言わんで置こう。

それに、英語ができればプログラミングの学習効率が高いというけど、プログラミングとか技術ぜんぜんできねぇアメリカ人とかもいるし。おすし。

英語よりコード見りゃわかる。

とはいえば、「英語ができた方が良い」というのが確かである。しかし、僕としては「ドキュメントが英語ばかり」で困ることが実は僕はあまりない。

僕の英語力っていうたら、英語は読めるけど、読むスピードは結構遅い方だとは思う。しかし、英語が読むのが遲くても分からなくても、そのにコードが書いてある限り、分かる。理解できるのだ。

正直、英語ドキュメントよりもコードを読む。ひらすらに。というか「英語ですらドキュメントが無い」なんてことざらにあるし、そのときは、ひたすらコード読めば分かるのである。

More Source Code than English!

あと、英語のコメントが長すぎるソースコードは大嫌いですね。

とはいえ、英語はできた方が良い

しかし、とはいえ、英語はできた方が良いとは思いますけどね。

最近のフロントエンドへの違和感

そういえば今日これらを読んでて

d.hatena.ne.jp

d.hatena.ne.jp

その中で

Mediumなど海外メディアでは、もはやこの種のツールを組み合わせたフロントエンド開発が当たり前として受け入れらており...

はぁ? 「海外では当たり前()なんですねw 海外ってどこですか? タンザニア? パフアニューギニア? 」などみたいなリアクションを取りつつ、んで、まぁ、フロントエンドに関して、書きたかったことがあって、丁度良いので書いてみる。

というのも、フロントエンドが「凄く変化が早い」「ついていくのに大変」「新しい!!すごい」「これからは○○フレームワーク」だとかそんないろいろな意見が見られて、なんというか違和感を感じてるので今回はそれについて書く。

フロントエンドは変化が早い?

まずこれ。僕は普通に違和感を感じている。確かに、jsフレームワークやライブラリとしたら、jQueryから、Backbone、Knockout、Angular、Ember、Vue、React、Riotや、CSSではOOCSSとかBEMとかSMACSSとか、みたいなCSS設計、ツールとかだとnpmやYeoman、grunt, gulp, bower, browserify, webpackなどいろいろなものが出てきた。本当に一杯出てきた。

しかし、考えてみると、こういったツールが出てくることは「変化が早い」というものだろうか?

一体何が変化してるのだろうか? 「流行」? 「当たり前」? 僕には、「フロントエンド流行がすごく早く変化している」という論調が多い気がする。

どうして流行りに乗らないといけないの?

僕の最初の違和感は、「技術的な流行り」に乗ることに何の価値があるのだろうか?ということである。もちろん、最新のツールフレームワークはより何かが良くなってるかもしれない。しかし、 それをあなたのプロジェクトで採用するには何の価値があるだろうか?

フロントエンドの「最新の」フレームワークに採用したり、置き換えたりすることで、誰が喜ぶのだろうか? 同じアプリケーションでフレームワークを起き変えたって、ユーザは喜ばないだろう。だって、置き変えるだけなら、機能は変わらないのだから。フレームワークが「最新の」ものになっても、サービスが変わらなければユーザにとって意味は無い。

開発が喜ぶのだろうか? それはどうして? 設計が良くなる? 本当だろうか? ただ、あなたたちが流行り好きなだけじゃないのか?と勘ぐりたくなる。

そもそも、それ流行ってる?

たまによくある違和感としては、そもそも、「流行ってる」という出所がわりと、限定的であるということである。非常にコミュニティが狭くて、そのコミュニティに属していなかったら、「流行ってる、流行ってる」というのに説得力がないときが結構ある。

流行じゃないツールは「終わってる」のだろうか?

じゃあ、視点を変えてみよう。流行じゃないツールは「終わってる」のだろうか? そんなことは無いだろう。だって、jQueryだっていろんなところで使われているだろうし、Backbone.jsで書かれてたり、他のフレームワークやライブラリが、採用されているサービスは沢山あるだろう。そのサービスはすべて、「流行のフレームワーク」じゃないと、技術的に終わってる?今すぐ、「流行の」フレームワークに書きかえるべきだろうか?

そのフレームワークを使わないとあなたの欲しいものが作れないの?

SPAを作るみたいなとき、「React + Redux」が最近の流行みたいだから使ってみよう、みたいな感じフレームワークを選択するみたいだが、ちょっとまって欲しい。そのwebサービスは本当に「React + Redux」じゃないとダメなの? 過去に培ってきたフレームワークなどの知識でも、それはできないの? できるとしたら、それを選択する理由は何?

フロントエンドは抽象化できるほどなのだろうか?

フロントエンドと一言で言っても、いろいろあるだろう。 アプリケーションによって、フォームが一杯あってしかもそれが同期するUIかもしれないし、アニメーションがたくさんあるゲームのようなGUIだったり、画面がどんどん遷移してしまうGUIだったりするかもしれないし、画面にグラフを一杯つなげるみたいなUIかもしれないし、タッチパネルのジェスチャーをどんどんやらないといけないものかもしれない。

それらを全部まとめて、抽象化して、「フロントエンドGUI」の技術として標準化できるものだろうか? どのフロントエンドアプリケーションとして「当たり前」な技術になるほど、抽象化して語れるのだろうか?

というか、「新しい技術」を出てきても、問題が解決しないというか、問題領域が違って「そこじゃねぇだろ!」「そこ解決しなきゃ意味ねぇだろ」と思うときがけっこうあったりするのだ。

そもそも、新しくない。変化してない。

そもそも新しくなくて、変化してないなとか、思う時があって、「新しい」といって出てきた技術が実は全然あたらしくない。いや、これ昔からあったから! みたいな気分になることがある。もちろん、その時は、ちゃんと比較して調べるとかするが、それにしても騒ぎすぎな感になるときがある。

そもそも、フロントエンド開発は大変であって、やり辛いところは、どれを使っても一緒だ みたいなところはあるとは思うが、もし、そういった辛みが、なくなれば新しいんだろうなとか思ったり。

以上が僕の違和感の概観である。

最後に

こうすると、僕が「最新の」フレームワーク嫌いな人に思われるかもしれないが、そいういうことでは無い。ただ、少なくとも「これをつかうのが当たり前」とか、そういうったのが嫌いなのは確かであって、つまるところ、よりよく技術選択をして、開発したいだけである。

追記

ただ、新しいフレームワークが出てきたら勉強するというか、調べておくことはやっておくべきではあると思う。ドキュメント読んだり、サンプル読んだり、ちょっと動かしてみたりね。(僕にはフレームワークを「勉強」っていう感覚が無い。)

追記2

ちなみに、どうでもいいけど、僕もSPAを作っている人間なのですよ。

「ES5でOptionを作った」らへんに対する感想

いやまぁ、ツイッターでつぶやいて終りの内容なんだけど、きまぐれでブログに書く。

saneyukis.hatenablog.com

この記事と読んでて、その関連で、

saneyukis.hatenablog.com

とか読んでて、思わずツッコミたくなる感があるので、感想を書いておく。

「ES5でOptionを作った」に対する感想

Optionは静的型チェックで意味がある。

まず、TypeScriptなら良いのだが、Optionとかのありがたみって、コンパイラでnullチェックしてくれるとか、そういったところにあるんじゃないかなと思う。つまり、Optionによって、失敗だとか、なにもないだとかが、あるかもしれない値を静的にコンパイルして実行しなくても、静的に型エラーとして検出されるとかそういう意味でな。

そもそも、null(なにもない値)と値が同じ型であるのが問題なのだ。例えばSwiftでは、String型にnilを代入しようとするならコンパイルエラーになることによって、値が無い変数をある程度、"type safety"に扱うことができる。

TypeScriptなら利用する意味はあるような気がする。コンパイルで検知できるかもしれない。しかし、"type safety"ではない動的言語として、Optionが必要かっていうと疑問だ。

「ES6のDestructuring assignmentで解決する」に対する感想

そもそもどちらもCommon Lispにある。

これは、ツッコミというか、ただ僕がLisperなので言いたいだけなのだが、

そもそも、Destructuringもmultiple valueも、Common Lispにある。 Common Lispでは、多値も分配束縛も存在する。

;; 分配束縛
(destructuring-bind (x y z) '(1 2 3) 
     (+ x y z))
;; => 6

;;  多値を返す関数
(defun ret-mul-value () (values 1 2 3))

;; 多値を束縛する。
(multiple-value-bind (x y z) (ret-mul-value)
 (+ x y z))
;; => 6 

そして、わりと、Common Lispではたとえば、gethashなんかの関数では、多値で、成功失敗を表現したりする。

むしろ、イケテナイ気もがする

golangのmultiple valuesが「よくできてるなぁ」という感想を持ったらしいが、むしろ個人的には、かなり微妙だと思ったところである。

むしろ、多値を利用して、成功失敗を表現するのは、なんか個人的にはイケテナイ感じもする。なぜなら、毎回多値のどちらが、成功や失敗を表現するして、どちらかが、成功した時の値になるかなんて、やっぱり書く人に依存するからだ。