【G’s Academy LABコース体験記】17日目

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

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

WINE 

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

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

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

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

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

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

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

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

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

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

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

【G’s Academy LABコース体験記】16日目

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

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

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

TweetMap

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

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

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

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

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

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

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

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

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

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

だ。

一つ明確な違いがある。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【G’s Academy LABコース体験記】13・4日目

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

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

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

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

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

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

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

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

(アウトプットはクソすぎてアップできない)

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

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

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

【G’s Academy LABコース体験記】15日目

順序が前後するが、先に15日目。
今日は”English for Software Developer”という授業だった。

講師はiOSアプリエンジニアの望月さんという方だ。

今日の講義の目的は、英語ができることによって広がる可能性を知ることだった。

僕は前職で元Googleのアメリカ人のMさんと一緒に仕事をする中で、
英語ができることによるメリットを、人生で初めてと言っていいぐらい強く感じた。

英語の必要性に駆られたことのある人には既知かもしれないが、
以下のようなメリットがある。

・情報量が多い
・オフショア開発ができるようになりコスト減
・アメリカで働ければ賃金が倍以上になる

etc.

どうやって英語を勉強していくのか

気になるのは勉強方法だ。

・恐れない精神性

僕はインドネシア人の話す英語が全く聞こえなくて苦労したことがあるが、
国や地域によって発音は結構変わる。

でも、彼らは第二母国語として使っていたりするのだ。

日本語訛の英語があってもいいじゃないか。

・新しい概念を勉強するときは日本語でサラッと読む
これはやはり僕が普段から思っていたとおりだった。
新しい概念を母国語以外の言語でインプットするのはコストが高すぎる。

・情報収集サイト
product hunt/betalist/chrunch base

・プログラミング学習サイト
codecademy/codeschool/udemy/udacity
androidhive
Youtube のTutorial

色々ある。

・楽しむ
大前提だ。

・音読する
僕は中学高校とテキストを相当音読しまくっていたので、
発音とリスニングはそこそこできるようになった。
その経験から言っても音読は重要だ。

ちなみに僕の英語の発音はカナダっぽいらしい。

・映画を日本語字幕→英語字幕→字幕なしで観る
これは僕にとって新しい勉強方法だった。
昔英語のリスニング能力をレベルアップさせるため、
Friendsを字幕なしでやろうとしたが、結局全く向上しなかった。
その反省を踏まえても、この段階を踏んだ勉強方法は理にかなっている。

最後に

生き方に関するメッセージをいただいた。

・難易度の高い選択肢を選ぶべし
理由は簡単な選択肢を選ぶ人が多くてレッドオーシャンになり、
結果的にしんどくなるから。
逆に、難易度の高い選択肢を選ぶと、選ぶ人が少なくて実は楽。

その通りだと思う。

【G’s Academy LABコース体験記】12日目

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

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

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

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

その作品がこちら。

記憶ゲーム

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【G’s Academy LABコース体験記】11日目

先週の木曜日の分。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【G’s Academy LABコース体験記】10日目

僕は甘えていた。

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

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

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

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

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

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

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

反省は以上。

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

Evernate

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

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

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

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

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

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

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



() => {}

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

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

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

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

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

【G’s Academy LABコース体験記】8日目

先週金曜日の分である。

毎週金曜日はプログラミング以外の内容の講義だ。

今回は、DeNAで少し前までUI/UXデザイナーをやっていて、
今はフリーランスの増田さんという方の講義だった。

僕は機械工学専攻ながら、
エンジンの熱効率や外れにくいネジを研究するのではなく、
設計やデザインを研究するちょっと変わった研究室にいたので、
かねてからUI/UX系の話は大好きだった。

例えば、アフォーダンスなんかは大学生の頃に授業で覚えて以来、
ドアノブの形やピクトグラムなんかの情報デザインはよく観察するようになった。

さて、彼が教えてくれたよいUI/UXの条件というのは、
以下の7つの要素から成るものだという。(若干僕の解釈で言い換えている)
①使いやすい
②予想可能
③シンプル
④寛容
⑤安全
⑥記憶してくれる
⑦やり直せる

僕はこういう列挙される事項というのが、
MECEであるか、物理的にモデル化されていないと、
まったく頭に入ってこない。
意味のない文字の羅列が覚えられないのと同じだ。

ということで、一旦僕の中で全項目を整理してみた。

デザイン講義

まず、UIという概念自体が人と対象物の関係性の話なので、
人がどう対象物と相互作用するのか、を時系列で並べた。

予想可能で、シンプルでわかりやすいと言うのは、
最初に対象物と接触するときに、
全体を見たときにどこがどうなっているのか、
どう使うものなのかが直感的に分かるという話だ。
(厳密にはここにも認識のプロセスが入るが、後述の認識プロセスとの区別のために割愛)

次に、パーツと接触するが、その際に情報を認識し、
それが操作するものである場合、対象物に触れる。
認識の際、情報的情報(日本語がいまいちだ)が先行する。

情報がわかりやすくて使いやすい(読みやすい、見やすい、意味が分かりやすい、etc)、
などだ。

そして、対象物に触れるときに感じるのが、物理的情報だ。
物質的に使いやすい(使っていて気持ちいい、持ちやすい、etc)などがそれに該当する。

そのときに思い通りに動きやすい
(ちょっと狙いを外しても、意図を汲み取ってくれる。
iPhoneのフリック入力などのボタン操作が好例)というのが寛容さだ。

最後に、行動の結果には成功と失敗の2パターンが生じる。
失敗したときに、もとの状態に回復してくれるのが、
記憶してくれることや、やり直せることだ。

失敗に関してはフェイルセーフとフールプルーフという設計思想があるが、
それに沿って考えてみれば上記の2つ以外にも対応方法は沢山出て来るだろう。

そして何より、プロセス全体を通して、命やお金、人間関係などの観点で、
安全であるというのが保証されている必要がある。

ざっとこんな感じだろうか。

人から教えてもらった概念やフレームワークはこうして自分の中で整理して、
初めて使えるようになるものだ。

僕はだいたいこうして図式化して整理するが、
こうしたモデル化のいいところは、ヌケモレとダブリが視覚的に分かることだ。

今回の場合のUXというのは、
僕の解釈ではあくまで人が対象物と接触している間の話に特化しているので、
その前後は含まれていない意味でのUXということが分かる。
つまり、この場合はUI = UXと言って差し支えないだろう。

そして、接触している間においては、
少なくともプロセスはMECEに(ヌケモレダブりなく)
説明されていることが分かる。

これで僕はまた一つ少しだけ賢くなった。

【追記】
ちなみに、僕はとても嫌な奴で、
何かのプロフェッショナルの人には、
その「何か」がその人の言葉で何と定義されているのか、
聞くようにしている。

割りと最近、全く別のデザイナーの方に彼のデザイン論を聞いたばかりだったので、
また別の言葉で聞けるかもしれないと思って増田さんにも聞いてみた。

すると、彼にとってのデザインとは(若干うろ覚えだが)
「うまく伝えるための道具」
だった。

【G’s Academy LABコース体験記】9日目

8日目の分は遅ればせながら明日にでも投稿する。

今日は課題発表およびJavaScriptの続きだった。

課題では、僕は以下の作品を作った。

軍艦じゃんけん

(Mac Book Pro 15inchじゃないと一画面に収まらないというクソUI)

JSの非同期という性質に悩まされ、
promiseとasyncという処理順序を整理する仕組みを
理解して実装することを強いられた。

まあ、言語の基本的な性質を理解することは非常に重要なので、
最初の段階で躓いたのはよかった。

さて、JSの授業としては、今日は配列とオブジェクト、
そしてブラウザのローカルストレージを学習した。

周りではカリキュラム上のJSの演習不足が祟ってか、
ついていくのがやっとだという人が増えてきた印象だ。

僕は昔HackReactorの入学試験に向けてJSの問題をひたすら
codewarsで解いた過去があるので、幸いJSに関しては何も問題ない。

どれ位解いたことがあるかというと、
超簡単な問題を150問、難しいレベルの問題を100問程度だ。
ここまでやると、JSON.stringifyというメソッドを自分でゼロからコードを書いて再現できるようになる。
(ちなみに、書くには再帰(recursion)を理解する必要がある。)

個人的な感想としては、こうした演習を沢山しないと、
JSは流暢には書けるようにならないと思っているので、
この先あまり演習がなさそうなことを考えると未経験者には辛いかもしれない。

どう辛いかというと、単純に思考のメモリが、
プロダクト作成ではなくプログラミングに取られてしまうからだ。
(ちなみに、Hack Reactorでは入学試験に受かったあとにも、さらに腐るほどJSをやらされる)

Hack Reactorの人に教えてもらったことだが、
タイピングも基本的なコードも、無意識でできるようにならないとダメだ。

参考
無意識で作業するスキルの重要性

逆に、僕はサーバーサイドはほぼ経験がないので、
その部分の演習を自分で補完しない限り、かなり実力が不足する恐れがあるので、
演習量には今後注意を払う必要があると考えている。

ところで余談だが、本日ようやく、sublime textのためのsublコマンドを設定することに成功した。
以下の2つの記事を読めば、完全に理解して設定することができるはずだ。

パスを通すとは?
sublコマンドの設定方法

僕は少しでもエンジニアらしく振る舞うために、
最近は極力ターミナルでファイル操作をするようになったが、
だいぶ仕組みが分かってきたせいか、
ダウンロードしたファイルもいちいちファインダーを開いて
ドラッグアンドドロップするのさえ面倒だと感じるようになってきた。

いい兆候だ。

明後日提出の課題はlocalStorageを使ったWebメモ帳だ。

僕はEvernoteとブログエディタの間の子みたいなのを作る予定だ。

明日に備えてそろそろ寝る。

【G’s Academy LABコース体験記】7日目

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

が、講義では、最初にgsが他のプログラミングスクールと何が違うかの説明があった。 

山崎主任講師曰く、
gsが他のプログラミングキャンプと違うポイントは、
ツールとしてのプログラミングをどう活かすかという、
創造力や自走力が違うとおっしゃっていた。

確かにそうだと思っていて、
僕がgsに入って一番感じていた特徴は、参加者の優秀さだった。
(同期のみなさん、上から目線の言葉でごめんなさい。)

これは言い換えると、
gsのブランディング力あるいは集客力の高さだ。

ここでの優秀さは学校で言う優秀さとも、
会社で言う優秀さとも違う。

一人で生きていくことができる能力が高い、
という意味でみんな優秀なのだ。

逆に、旧来の学校や企業といった既存のシステムに当てはめると、
僕も含めた多くの人が、社会不適合者だと思う。
(同期の皆さん、再びごめんなさい。
でも僕は本当にそう思っていて、そしてこれは最高の褒め言葉だと思っています。)

既存のルールに従ったり、
自分以外の誰かの命令に従うことが極端に苦手な人が多いように思う。

逆に、自分に全く束縛がない状態が、最もパフォーマンスが高くなる人種だ。

今の時代にとても合っている最強の特性でもある。

だからこそ自分の意志で皆ここにいるのだろう。
自分の沢山のお金と時間を投資して。

この特性は、一朝一夕で身につくものではないので、
それを持っているちょっと変わった人を引きつける力が、
gsにあるということだ。

同期の半数がこれから起業するということを考えても、
やはり異常な集団と言えよう。

よくよく考えてみれば、
起業家向けのプログラミングキャンプというビジネス自体、
対象者がニッチ過ぎてやろうと思う人は少ない領域だ。

だが、今伸びているプログラミングキャンプという市場に、
そのまま普通に飛び込んだらレッドオーシャンに巻き込まれるというgsの先見の明と、
それ以上に本当に世界を変えたいというgsの人たちの想いが見て取れる。

前置きが長くなってしまった。

今日はJSを使ってプログラミングの基本的な内容をやった。

まずは、変数、if文だ。

僕は大学でC言語もやっていたし、
JSも多少馴染みがあるので、
(たまに僕が知らない大事なことがポロッと出て来るため)授業には耳をそばだてつつも、
最初から演習と課題に手を付けた。

来週火曜日までの課題は、じゃんけんアプリだ。

これ自体は、プログラミングキャンプの体験コースや、
開発会社の採用課題なんかでよくあるお題だ。

だが、例によって三期生の先輩のアウトプットを見ると、
普通にじゃんけんアプリを作るのがいかに恥ずかしいことかがよくわかった。

実際のその作品をお見せできないのが残念だが、
僕が見たのは以下のようなものだった。
・FFの戦闘形式を模したもの
・音声認識機能のあるUIのきれいなもの
・シューティングゲームとの掛け合わせのもの
・ルーレットとの掛け合わせのもの

まあ、普通にWeb上にゲームとして置いてあっても全然不思議じゃないものばかりだ。

誰がじゃんけんアプリを作れと言われて、
新しいゲームを作ってしまえるだろうか。

普通の人はそんなことやらない。

だが、先輩たちも、僕たちはそれをやる。

やりたいからだ。

ということで、僕は来週に向けて、
「軍艦じゃんけん」を実装することにした。
(音量注意)

地方によって呼び名やルールが若干違うが、
僕が最後にやったのは中学生のときで、
「手の痛みに我慢できなくなったら負け」というルールだった。

最初はじゃんけんという課題を無視して、
ブラックジャックを作ってやろうと思ったのだが、
すでにweb上にアプリがあったため、やる気を無くしてしまった。
(軍艦じゃんけんはサクッとググってみたところ出てこない)

やっぱり、僕は世の中にまだないものを作りたい。
来週の月曜には完成する予定なので、また公開する。