JavaScriptを初めてちゃんと触った記録
色々とありまして、スマホ位置情報ARゲームの雄「INGRESS」の簡易シミュレーター「truthseeker (deadcopy build)」というサイトをJavascriptで構築しました。
元々プログラム関係では何一つ作れた試しがなく、大体は「何かしら作ってみたい→手を出す→基礎的な文法は学ぶがモノは作れず2日くらいで飽きる」という流れで習得できたことがありませんでしたが、今回は大体3週間ほどみっちり向き合ってカタチにしてみた次第です。
今回はどのよーな流れでとりあえずの完成までもっていけたのかの話と、今回作ってみて気がついたことなどをつらつらっと書いてみます。
元々プログラム関係では何一つ作れた試しがなく、大体は「何かしら作ってみたい→手を出す→基礎的な文法は学ぶがモノは作れず2日くらいで飽きる」という流れで習得できたことがありませんでしたが、今回は大体3週間ほどみっちり向き合ってカタチにしてみた次第です。
今回はどのよーな流れでとりあえずの完成までもっていけたのかの話と、今回作ってみて気がついたことなどをつらつらっと書いてみます。
0.今回の作業で色々わかったこと
このあとどーでもいい話が続くので、先に同じようなのを作ってみたいという人に向けてメモをいくつか残しておきます。
0-1 このサイトでエージェント情報を残すために使った二次元コードは、生成が「jquery-rqcode.js」、復元は「jsqrcode」利用したものです。
前者はパラメータをひとつづきの文字列にして二次元コードにしてそのライブラリに渡すんだけど、書き出されたコードはブラウザによっては画像として保存できないため「.toDataURL」で変換して表示させました(このあたりのくだりを殆ど現役SEにやってもらうという体たらく)
ほんで後者はQRコードをそのままデコードさせるんだけど、このままだと2次元コードを保存するか写真で撮影して保存しないといけなかったんで、スマホならカメラ起動して値を渡すようにしました。このへんの解りやすいサンプルがなかったので、一か八かだーと思いhtml側はinputタグで「type="file" accept="image/*" capture="camera」でカメラ起動、js側は「addEventListener」で直接そのデータを読んでjsqrcodeに渡したらあっさり読み取りできました。結構楽だったな。
0-2 実際に組んでみて意外だったことは
- html内にscriptタグを入れるのはbodyタグの一番最後のあたりが安全
- 実行結果のタイミングをずらすためにsetTimeoutを使ったけど、もしかしてJavaScriptって中身を一回実行したうえでsetTimeoutの順に結果を画面に反映するの?
- setTimeoutは行番号の順に実行じゃなく、指定された時間になったら実行されるっていう使い方だった
- nsertAdjacentHTMLを利用して指定したタグの要素を囲むようにもういっこタグを入れようとしたら全然指定してない場所にタグを挿入されることが頻発、結局innerHTMLでまるごと書き換えたほうが早くなるってケースがちょいちょいあった
- 思ってたよりはるかにブラウザによる動作の違いが少なくて助かった
0-3 今回の作業において役に立ったのはchromeのディベロッパーコンソールだけど、firefoxにもそんなかんじの機能があったと思う。エラーの場所が具体的に解るんでかなり助かります。
1.具体的な目標が必要だ
何はなくとも、作るなら目標は必要だなあと思いました、
というのも、これまでプログラム言語を習得しよう!と思い立ったときは「何か作りたい!」という意欲しかなかったため、実際に習得したもので何ができるのかについてのビジョンが全く自分の中に無く、結果としてスタートラインから動くことなく飽きてしまうという状況だったわけです。
それと比較すると、今回は計画段階で「何が作りたいのか」「必要なプロセスは何か」「下準備はどのくらい必要か」がおおよそ筋立て出来ていたので最後まで集中してすすめることができました。
まず「何が作りたいか」については、最初の段階から「INGRESSを家から出ずに遊ぶ方法」というところから始まっていて、実際にコーディングする前にどんな仕組みで動くのかを予め設計図としてまとめていきました。
このサイトは「INGRESSでの自分のプロフィールを入力して、一定期間の活動をシミュレートする」というものなので計算が中心、ということで計算の順番や関わる計算式などが結構な量になることが当初の段階から予想できていたんですよね。
組み上げる上で一番めんどくさそうなところを、コードを書く前に別で設計図にしておいたおかげで、後で何かしら挙動が上手くいかないところはその原因を設計と照らして確認できた場面もありました。
いきあたりばったりで作ってると、想定外の結果が返ってきたときに「プログラムの記述ミス等で」か「そもそも設計がおかしい」のかの判別が難しくなる可能性もあるし、そういう意味でも目標が具体的なら修正しやすいし心も折れにくいなあと思いました。
このサイトは「INGRESSでの自分のプロフィールを入力して、一定期間の活動をシミュレートする」というものなので計算が中心、ということで計算の順番や関わる計算式などが結構な量になることが当初の段階から予想できていたんですよね。
組み上げる上で一番めんどくさそうなところを、コードを書く前に別で設計図にしておいたおかげで、後で何かしら挙動が上手くいかないところはその原因を設計と照らして確認できた場面もありました。
いきあたりばったりで作ってると、想定外の結果が返ってきたときに「プログラムの記述ミス等で」か「そもそも設計がおかしい」のかの判別が難しくなる可能性もあるし、そういう意味でも目標が具体的なら修正しやすいし心も折れにくいなあと思いました。
2.ツール選びは意外に大事だ
現役のプログラマ等そっち系のお仕事してる人は結構「キーボードはHHKBじゃないと」みたいな事で盛り上がってたりしますよね。僕も曲作ったり手芸やったりがあるんで理解できなくはなかったんですが、そこまで変わるんかなーと思いつつ眺めていました。
で、僕の場合は今までStyleNoteというhtmlエディタを使っていたんですが、今回はMicrosoftの「Visual Studio Code」を使ってみたところ、入力補助機能や変数の確認とか結構細かいところでサポートされたり、必要な機能はしっかりしつつもゴテゴテになりすぎない丁度いいシンプルさでとても使いやすいエディタでした。
あと、個人的にMicrosoftのプログラミング向けフォントConsolasが、見やすいしカタチも好みで使っててテンション上がってとても捗りました。エディタ側で配色をハイコントラストにするとファンクションやタグの見分けもしやすいしね。
元々僕が愛用しているのがThinkpadということもあって、作業のしやすさは最初から約束されていたようなもの(選んだ理由は堅牢なのでクラブでPCDJやっても大丈夫な堅牢さだったんだけど) ディスプレイ上部のLEDを照らすと、なんとなーく本物っぽさもあったんでさらにやる気が積み上げられるという結果に。思ってた以上に道具選びって大事なんですなー。
3.8割完成させてから出す
大体において、集中力が切れると別のやりたいことが目に入ってきちゃうので、特に新しい物事を習得しているときはできるだけ別の誘惑を避けるように心がけています(で、大体は失敗して横道に逸れます)
今回もそれに則って1週間ほど集中してJavaScriptの基礎とか必要な処理方法を調べ上げトライアンドエラーを繰り返した結果、気がついたら3週間もかかりっきりになった上ヘンな対戦で座り続けたので背中と肩になかなかのダメージを負うことになりました・・・さっきの話に戻るけど椅子と机はちゃんとしたのを用意しないとイカンね。
ただ、たとえば実装する機能を想定して、とりあえず動いて使える程度なら大丈夫でしょ、という状況だったときに「じゃあ残りは気がついたときにやるかな」となると、まあ殆どの場合それ以上を実装するまでに時間がかかるか、それ以上改修される可能性は0に近いだろうという話。
最低ラインとして「絶対必要ではないけど使う側の事考えるとストレスを極力軽減できる程度の完成度」までは作るつもりで一気に仕上げていかないと尻すぼみのまま終わってしまうかもしれないなーと作り始めてからぼんやり思いました。
まず、想像する一番ちゃんと仕上がってる状態から見て大体8割くらい出来ていれば公開してみんなの反応を見つつ改修するように作業すると、自分が想定していた残り2割がどんどん膨らんでいったとき根本的な作り変えのタイミングを逃しちゃいそうっていうのもありますよね。
で、使う側は初手で使いづらくて手放すと、次回もっかい使う確立が極端に減るだろうなあと。実際僕もそうやって使わなくなったモノが結構あるんで、最初の時点でできるだけある程度の使いやすさは確保しないとダメなんだろうなーということはちょっと意識していました。
まあこんな感じかな? 結構頑張って作ったサイトなんでみんなに使って欲しいんだけど反応薄いんだよね・・・