おいこれ〜おい、これの構造どうなってんだ。教えてくれ〜

今日は明日締め切りのLINE風チャットアプリの作成と、
翌週に控えたJS選手権のアイディア出し。

チャットアプリで作った僕の作品がこちら。

WINE 

ネーミングが例によってふざけているのはご愛嬌。

ちゃんと複数人でチャットができるし、
チャットルームが複数作れるのがポイント。
（誰でも使える状態なので、いずれ閉じるかもしれない。）

今おざなりになっていてちゃんと調べないといけないと思っているのが、
このアプリを支えるFirebaseというデータベースの存在意義だ。

以前、localStorageの存在意義を理解せずにアプリケーションを作成してしまったが、
反省として、その技術の存在意義や必要性、
原理というものを理解しなければ、
プロダクト作成の本当の技術は身につかないと思っている。

来週の火曜日に向けたJS選手権のアイディアだが、
僕が起業する予定のアイディアとは全く別で行こうと思っている。

起業アイディアはARになるが、
今回は、今世の中に最も溢れている通常のWebサービスの仕組みを理解することを目的に、
直接は関係のないプロダクト制作を行う。

AR以前に僕はWebの平面で閉じたサービスも深く理解する必要があると考えたためだ。

またいずれ説明するが、僕の世界に対する理解では、
ARサービスと人間の関係性は、Webサービスと人間の関係性の拡張版だ。

つまり、通常のWebサービスの理解が必要なのだ。

そして、この流れで前から本気ではやろうとは思わないが、
ヒットするんじゃないかと思っている中途半端なアイディアを形にする好機になる。

プロダクトアイディアは近日中に公開する。

無事、火曜日の課題提出を終えることができた。

今回は、Google Map APIを利用したアプリケーションならなんでもOKという課題だった。

僕が最終的に作ったものはこれだ。

TweetMap

ツイッターのツイートをハッシュタグ検索して、
その結果をマップ上に表示するというものだ。

形にはなったが、残念ながらツイートに位置情報があまりついておらず、
マッピングが困難だったため、擬似的に位置情報を生成してマッピングする、
という荒業でデモができるようにしている。

今回、個人的に一番興味深かったのは、TwitterのAPIではなく、
全員の発表を通して見て、自分も含め、
完全な完成までこぎつけなかった人が多かったことだ。

講義でも解説があったが、APIという特性上、
そのまま実装するのは簡単でも、
いざ自分でカスタマイズするのがハードルが高く、
自分のコントロール外の要素に左右されるという経験を初めてしたことが原因なのだろう。

実際のプロダクト開発では、未完成は許されない。
僕は前回の失敗を反省して、形にしてデモできることにはこだわった。

今後、全員がこうした想定外の出来事などに苛まれるのだろう。
想定外のものをちゃんと想定内にできるように、毎回の失敗の振り返りが大切だ。

—

ところで、直近二回の課題をやってみて、
とある自分の思考特性に気づいたのが一番の収穫だった。

何かというと、僕は、目的ありきの思考しかできないということだ。

直近二回の課題は、
・canvasを使って何か作れ
・Google Map APIを使って何か作れ

だった。対して、これまでの課題は、
・LP
・じゃんけんアプリ
・メモ帳
・クイズアプリ

だ。

一つ明確な違いがある。

作るものが決まっているかどうか？

いや違う。
実は、僕にとってはそれは大して重要じゃない。

作るものが決まっていても、
どうせその枠組をはみ出した別のものを作るので、
最初から決まっていようがあまり関係がない。

僕にとって明確に違ったのが、
問題解決のテクノロジーが制限されているかどうかだ。

直近二回は、起業で言えば「シーズベース」な考え方だ。

「面白いテクノロジーがある。
これを使って面白いことができないか？」

これは、言い換えれば、手段から目的を発想する思考だ。

逆に、以前は「アイディアベース」な考え方だ。

「何か作りたいものがある。
どうやったら作れるか？」

これは、言い換えれば、目的から手段を発想する思考だ。

僕は、後者の考え方をして生活している。

起業アイディアを出すときもそうだ。

自分が面倒だとか、困ったシーンに出くわした瞬間に、
あ、こうしたらもっとよくなるのにな、と言った具合だ。

これはどっちがいい悪いではなく、
できれば使い分けが出来ると理想的なのだが、
僕は学生で研究をしていた頃から、常に目的立脚の思考しかしてこなかったせいで、
「これを使ってなにか面白いことできないか？」
という思考が全く出来ないようになってしまった。

おそらくこれが原因で、直近二回の課題で、
何を作るのかを決めるのに時間がめちゃくちゃかかってしまった。

何かの問題解決の手段としての、
地図の本質を考えてみたけれど、
結局それだけでは、ちょっとおもしろい地図というプロダクトが出来るだけで、
特別何かの問題解決にはつながらないことが分かった。

問題について考えていないのだから、当然といえば当然だ。

（逆に、本質を考えることは、そのプロダクトを理解する上で、
不可欠であることもちょっと分かってきた。無駄ではなかった。）

次回木曜日の課題は、LINE風チャットアプリだ。

今回は僕が得意な思考パターンのお題なせいか、
前回よりも俄然モチベーションが高い。

が、それ以上に、来週の今日を締め切りに、
JSを使った条件無制限のJS選手権があるので、
そっちにリソースを全部回したい。

ということで、チャットアプリはできれば今日中にMVPを作って、
明日から選手権の開発に取り掛かろうと思う。

例によって昨日の月曜日にフリーランスの仕事が入っていたため、
その準備で先週はほとんど時間がなかった。

簡単に、先週水・木分を書いておく。

まず、木曜日の課題はhtml5のcanvasを使って何かをする、という課題だった。
それに応じて、水曜日はcanvasの使い方の勉強。

僕は、Macの便利アプリSkitchのWeb版を作りたかった。
（前回の課題のときの問題意識として、自分の作りたいものを作るというのがあったが、
それについては16日目の記事に記載する）

Skitchの最も便利な機能の一つが、
ボタンを押したらスクリーンショットを起動して、
そのスクリーンショットをすぐさま編集する画面に移れるところだ。

それを実装しようとしたが、実装方針が悪かったのか、
作りきれなかった。

Macでは、command + shift + 4
でスクリーンショットを起動するが、
同時押しというイベントをJS(jQuery)で作ることが非常に困難だった。

理論上できると思っていたが、
あまりにもその実現に工数をかけすぎ、
計画倒れという非常に残念な結果になってしまった。

（アウトプットはクソすぎてアップできない）

分かる部分に対して工数を見積もるのは誰でもできる。
見えない部分に対して、工数を見積もり、アウトプットを出すのが大切なことだ。

以前のエントリで意識高い系の偉そうなことを言っておきながら、
非常に恥ずかしい結果だった。

工数管理を次回以降意識して進めるというのが僕の目下の課題だ。

火曜日は課題提出の日だ。

結論から言うと、なんとか無事間に合わせることができた。

金土は全て月曜日の仕事の準備に回し、
日曜日の朝9時から15時で課題の9割を完成させた。

そして、最後の1割は月曜日の帰宅後に2時間ほどやって完成させた。

その作品がこちら。

記憶ゲーム

今回もPCのブラウザのみ対応。

今回は完全に僕の自信を持って作れる範囲を超えることがなく、
自分に負荷が掛からなかったので、反省している。

次回からはもう少し計画的に仕事の準備をしたい。
・・・って社会人一年目から毎回同じ反省をしている気がするが。

それで、今日の講義は関数と、僕があまり使ったことのないcanvasの使い方について。

木曜日に提出の課題もcanvasを使ったペイントアプリだ。

他の人の作品を見ていて最近思うのが、
自分のほしいものを作るというのが一番プロダクト開発の力がつきそうだということだ。

僕はとにかく既存のものは嫌だとは思うものの、
なんだかんだ、とりあえず無難に面白そうなものとか、
すでにあるものを改善したものみたいなものに終始していて、
自分でもちょっとひねりが足りないと感じている。

なんというか、文字通り「課題をやっている」感が自分にあって、
それがとても嫌なのだ。

gsは一般論としては学校みたいなものだが、
これを本当に学校だと認識した瞬間、
そこでの学びは一気にしょうもないものになると僕は思っている。

課題じゃなくて、自分が世の中に必要だと思うものを作ろうと思う。

最後に、最近よく思うことをば。

普段は自称温厚な僕だが、同期に対して思っている少し辛辣なことをここで述べる。

（念を押しておくと、この文章は同期の全員が読めるし、全然陰口のつもりはない。

全員いい大人だし、わざわざ僕が直接言うようなことでもないから、
僕が正直に感じていることとしてここに記すに過ぎない。

もしかしたら明日から僕は教室に居づらくなっているかもしれないがw）

課題の発表の際、フェイスブックページでコメントを言い合うのだが、
その時の表面的なコメントが僕は嫌いだ。

何が表面的かというと、
「●●の技術ってすごいですね、教えてください」
みたいなやつだ。

教えて欲しいと思うこと自体はとてもいいことだし、
僕自身も同じようなコメントを書くのだが、問題はその後だ。

本当に教えて欲しいのなら、すぐにそれについて実装した本人に聞きに行くはずだ。

だが、それで実際に聞きに行く人の少なさに僕はがっかりしている。

別に僕がそうしたコメントをもらって来てもらえなかったから、
期待を裏切られた気持ちになったとか、そんなのじゃない。

その状態が、求める成長の度合いの低さを表していると思うからがっかりするのだ。

もちろん、ググって自分で解決したのかもしれないし、
沢山の人に聞くことがあって、優先順位が低くて回っていないのかもしれない。

だけど、休み時間に見渡している限り、
全くそういう訳じゃなさそうに僕には思える。

だってどう見ても習ってないような不思議な技術、
色んな人が沢山使ってたでしょ、っていう。

教えて欲しいというのは嘘なのか。

知りたい、もっとできるようになりたい、
という欲求はその程度なのか。

それとも、「教えて！」とコメントでちょっと言っておけば、
相手から教えてくれるものとでも思っているのだろうか？

皆それぞれ自分の成長に忙しいから、
コメントをちょっともらっただけで、
自分からご丁寧に教えに行くようなやつはそういない。
（僕の感覚が変なのだろうか？）

少なくとも、僕は自分のことで手一杯だから、
教えてとコメントでのみ言った人に自分から教えに行くような余裕はない。

だけど、自分が実装して分かった気になったところでも、
いざ人に説明しようとすると案外理解してないところがよくあるので、
自分から積極的に教えようとこそしないけれど、
面と向かって教えてと言われたときには、
全力で説明するようにしている。

それがお互いにとってプラスだからだ。

そういうことを言う僕はどうかというと、
教えて欲しいと思った人にはその旨のコメントを残し、
その人に聞きたい内容とその優先順位をメモしておき、
直後の休憩時間にスキを見て、全員に教えを請うている。

別にフィードバックのコメントというのは、
お世辞を言う場所でもないし、
ましてや嘘を言う場所でもない。

教わる気がないのなら、そんな嘘は言うべきじゃない。
フィードバックやコメントは本音で言うから意味があるのだ。

こう思うのは僕がもしかしたらSNSのコメントの位置づけを勘違いしているからかもしれないし、
あるいは僕が人の気持ちを推し測ることが苦手だからかもしれない。

だが、思っていることは本当だ。
（勘違いだったら同期の皆さん、こっそりあとで教えてくださいw）

…とまあ、思うがままにここまで書いたが、
僕は別に同期が嫌いなわけじゃないし、むしろ好きだが、
この同期という一つのチームのレベルを少しでも高くするために、
僕は基準に妥協したくないと思っているだけだ。

ただの学校ならともかく、ここは、
「世界を変えるギークになろう」という理念を掲げているgsに入った人の集まりだ。

当然、僕達が最終的に目指すレベルは、
GoogleとかAppleとかで引っ張りだこになっている世界のエンジニアなのだ。
起業家ならばジョブズやラリー・ペイジ、孫正義なのだ。

それに異論はないだろう。

タイガー・ウッズは大会で優勝争いをしているときに、
僅差の敵のショットが入らなかったときに、よくキレたそうだ。
高い基準の戦いを求めているからだ。

僕はgsにいる人には全員が高いレベルを目指してほしいと思うし、
それでお互いを切磋琢磨したい。

実際にレベルが高いことももちろん大切だが、
それよりももっと大切なのは、
そうした成長を求める気持ちを持っていることだ。

…ああ、明日も僕の席がちゃんとあればいいな。

先週の木曜日の分。

この日はJSの配列とforループとの組み合わせの使い方だった。
一通り説明のあった後は、ひたすら課題だ。
gsは自分で調べて進められるタイプの人にとっては、
とてもぴったりな環境だろう。

さて、例によってJSは基本的な部分は使い倒しているので、
僕の関心事はもっぱら次の課題と月曜日のフリーランスの仕事の両立だった。

週末が三連休で、講義がない月曜日も合わせると四日の休みがあったのだが、
フリーランスの仕事が次の月曜日に一日入っており、その準備に２日はかかる。
課題には一日未満しか使えない計算だった。

課題はクイズアプリで、
僕は企画だけはいつも出題の日に終わらせると決めているので、
今回も企画はその日のうちに考えていた。

僕が作る予定なのは、
格子の中に出現する複数の●印の位置を一秒で記憶して、
印が消えた後にその位置を正確に回答するというものだ。

クイズじゃないような気もしたが、
企画段階でクイズの本質について考えてみたところ、
結局、知識や記憶、思考のレベルを計測するために出題する問題だと考えたので、
その意味で、僕の問題はクイズという要件を満たしている。

僕が課題をやるときに気をつけていることは、
そもそものそのお題について考えることだ。

今回で言うと、クイズアプリがお題なので、
「クイズとは何か？」を問うようにしている。

これは何も無意味にやっているのではなく、
ビジネスをやるときにも必要な話で、
目の前に存在しているそれが、
どんな必要があって、どんな原理で発明されたものなのか、
という本質を考えなければ、その領域のイノベーションは見込めないのだ。

それで、クイズについては、大して深まらなかったが、
世の中に溢れているクイズというのは、
結局、
「なんの知覚情報について測定するのか」×「出題形式」
の組み合わせで出来ていることが分かった。

これを踏まえると、どんな領域のクイズはまだ存在していなくて、
どうすれば意外性や面白さが生まれるのかということが見えてくる。

僕が企画段階で断念したが、
技術的に面白そうだと思ったのが、
立体図形をマウスで触って当てるクイズだ。

マウスカーソルを画面の白紙上を動かしているときに、
カーソルの移動速度が一定の規則で変化すると、
そこで立体的な図形を触っているような錯覚を覚える。

それを利用しようと思ったのだが、
特別ゲームとして面白いものにはならなさそうな気がしたので止めた。

今回は面白いアイディアが出ることには繋がらなかったが、
引き続きお題の本質について整理して思考するというのは続けていきたい。

週末と課題がどうなったかは、12日目に続く。

僕は甘えていた。

僕はプロのエンジニアに必要なエッセンスを、
「教えてもらえる」ものだと思っていた。

だが、それは自分で探して見つけないといけないようだ。

コードのお作法、
DRY原則、
git commitのタイミング、
etc.

僕はこうした基本的なことはHack Reactorで教えてもらい、
いつの間にかその先も誰かが教えてくれるものだと思っていた。

だが、冷静に考えて、
エンジニアというのは自分で勉強し続けるものだ。

もちろん、プロの基準の高さをちゃんと認識する必要はあるが、
少し僕の学習の姿勢は甘えていたようだ。

自分で不足を感じるところは自分で書籍を買うなり、
せっかくいるGoogleやFacebookのエンジニアの友人に聞くなり、
どんどんしていけばいい。

反省は以上。

ところで、明日の課題はメモ帳だと昨日書いたが、
以下のようなものを作った。

Evernate

エバーネートと読む。
クラウドならぬローカル版Evernoteである。
Evernoteの冒涜もいいところである。

本当はブログエディタの機能もつけたかったのだが、
フリーランスの仕事の関係で、
今回はあまり時間が割けなかった。

これを作る際に、解決にかなり時間を食った部分が２つある。

・一度DOM操作で要素を取り除くと、イベントの紐付けも外れるので、再度紐付けが必要
Evernateには、ノートの全削除機能をつけたが、
全削除した後にノートの新規作成ができなくなるトラブルがあった。

これは、僕の作り方の問題でもあるのだが、
要素を全て削除してもう一度描画するという方法をとっているため、
イベントの紐づけがもう一度必要になる。

おんなじコードを二回も書いているので、DRY原則に反してしまっている。
イベント発生ベースのコードを何か変数に格納できないか、工夫が必要だ。

・アロー関数でjQueryの$(this)を使ってはいけない
僕はJSの関数は、もう慣れているので、
function () {}

を

() => {}

と記述する。
後者の書き方をアロー関数と言うが、
jQueryが古めかしいライブラリのせいか、
新しめのアロー関数を使えると急に読み込めなくなる。

なぜ使えないのか原因がわかった。
アロー関数自体がthisの束縛がなくなるという仕様なので、
参照先が変わってしまうことが原因であった。
jQueryの問題ではなかった。
ごめんなさい。

【追記】
コマンドの設定方法が少し分かってきたところで、
調子に乗ってターミナルからChromeでファイルを開けるようにもした。

ここに書いてあるコマンドをターミナルにぶち込むだけだ。
めちゃくちゃ便利である。

エンジニアがターミナルで全部操作するという気持ちが素人の僕にも少し分かってきた。

今日からいよいよJavaScriptを本格的に扱う。