ポケモンGoが国内でリリースされて二日目
ポケモンGoは初日に飛びついた。今時のゲームは攻略情報が過多ですぐスポイルされてしまうし、ガチ勢と差がつきすぎてやる気を削がれるので、楽しみたいなら情報のないうちに飛び込むしかない。
で、個人的には結構楽しんでいる。この規模で社会的な何かが起こっているのを見るのは久々だ。
起きていたこと
- 駅などで歩いている人を観察すると、10～20人に一人ぐらいはポケモンGoをやっている
- 歩きスマホ率はかなり高い
- 夜中に出歩いたら、駅前のロータリーに20人くらいが並んでポケモンGoをやっていた
- たった２日で無属性の集団がゲームに最適化されてる感があり、異様だった
- 新たな課題に対して、社会の方が変化して最適化された、そんな気がした
年齢層
- 男性は３０～４０代が多いと思う。
- 女性は２０後半～３０代が多そう。それ以上の人も珍しいが少しいる。
ユーザ属性
- カップル。見た限り一番楽しそうにしている。
- 友人同士
- 男性は３人組が多い。
- 女性はたいてい二人組である。
- 一人
- 男性はゲーマーっぽい見た目の人が多い。
- 女性はOLっぽい人が多い。
所感
正直、ゲーマーはこの程度のゲーム要素だとすぐに飽きてしまいそう。
しかし、カップルや友人同士でポケストップを発見して楽しそうにしている所を見ると、別にゲームとしての完成度は重要ではなさそう。Ingressユーザのポータル芸がポケモン世代を楽しませているようだ。
文句はいろいろ言いたいが省略。全体的に監修が足りていないと思う。
ゲーム要素は軽めだが、スマホの外側に面白がれる要素が存在している。今まで認識すらしていなかった地蔵にルアーが刺さってポケモンが沸きまくるのとか、かなりシュールで面白いと思う。
非ゲーマーを行動させた、ということが大事で、そういった人たちが今後、店舗とのコラボなどの展開にどの程度乗ってきてくれるのか、気になる所。
フロントエンドで使ってるものがあまり変わってない
自分のスタックはあまり変わっていない。ほとんど10年のツケを払っていない。学習能力が低いせいでもあり、選んだスタックがバージョンを重ねている成果でもある。
毎回使う
フレームワーク：Vue.js
- 消耗、などの意見が散見されたが、べつに今でも便利に使えている。
- browserifyやwebpackがあれば便利だけど、なくてもいい、ってバランスが好き
- データフローは特に考えない。状態がそこにあるので書き換えれば良い。
- あまり頭を使わなくていいのが助かる
Reactの考え方は好きなのだけど、よっしゃFluxやるぞって気持ちにはならず、Reactのみでよしなにやるソリューションが広まったらいいなと思う。
ビルドシステム： browserify / watchify
- substackの作るものはどれも品質が高いので、もうsubstack製品だけ使っていればいいやという気持ちになりがち。余計な処理が全然無いってのが安心感がある。
- watchifyはそんじょそこらのwatcherのように暴発がなく安定して動く感じがある。安心して100%依存しているし、他のwatcherを併用しないようにしている。
タスクランナー： npm run
gulpやgruntを使わず、npm run-scriptでなんでもやろうっていう方針。
- run-scriptが長くなると破綻するという話もあるが、.babelrcやbrowserify transform fieldでなんとかならない？
- なんとかならないケースはgulpを使う時もあるが、あってもbuildタスク一つだけにする。watchに凝りだすと沼に入る。
UIフレームワーク： 使わない
- Sanitize.cssは必ず適用する。無いとフォーム周りで死んだりする
- とにかくCSSの総量を削減することが大事だと思っているので、可能な限り自分で書く。
- だるい場合は、Semantic UIを使うこともある。マージン設計が適切ですっきり見えるし、アニメーションがシュッとしてるので高級感が漂う
- UIフレームワークを使う場合は、less or sassでコンポーネントのみインクルードしたほうがよい。グローバルにいろいろなものが展開されることになる（そのうち使っているのは10%だけ、とかもありがち）。
- flexboxはおおまかなレイアウトには使うが、使い過ぎない。地雷を把握してればいいんだろうけど。
オプション
TypeScript
- OOPを採用したい時に使う。
- 別言語からの移植を行う場合は必須
- Vue.js公式が使っていないのでオプションにしているだけで、最近は必須にすべきかなぁと思っている。
less
- 以前はstylusを好んでいたが、IDEのサポートが手厚いのでlessに舞い戻った。
- シングルクラス派なので、mixinが存在するだけでかなり違う。
sushipm
https://github.com/sushicorp/sushipm/
package.jsonにrun-scriptを追加したり、index.htmlの雛形を生成したりする自家製ツール。
sushipm create index.htmlとかする。sushipm devコマンドはwatchのついたrun-scriptをparallelshellでまとめる機能で、お気に入り。
Babelは使わないのか
最近Babel使わなくていいんじゃないか説が自分の中で生まれている。便利には違いないけど、自分はそれほど賢くないので、レイヤが増えた時ハマりそうと思っている。
開発中に、babel導入ですごい改善しそうな雰囲気が出てきたら使うかもしれないけど、開発初期からは入れない。
- IE11以降であればブラウザネイティブでclassが使える
- arrow functionは使えなくても死なないし、腱鞘炎だけ気をつければよい
- importはTypeScriptと解釈が揃っていないので、requireを使っている。すなわちbrowserifyがあればいい
- （たとえbreakingな変更になったとしても標準とずれてしまったら揃えるべきじゃないのかな…）
- yieldは使えないけど、フロントエンドでさほど出番ないような気がする。サーバサイドではNodeなのでネイティブで使える。
- const / letは使いたいが、今のとこなくてもいいかな。
VSCodeは結構補完が効くので、腱鞘炎はあんまり危惧していない。
自分の賢さに合わせる
RPGでも、力が足らなければ装備できない武器があるわけで、使えなくても悲観することは無いと思う。自分は諦めがいいほうなので、React/Fluxスタックからは早々に退散した。
自分が装備を選ぶ基準は、こんぼうであることである。取っ手がついていて殴れればそれでよく、更に釘が飛び出ていたら最高だけど、こんぼうの先からビームが出るべきではない。たとえ、にくいライバルのあいつが鋼の剣を持っていたとしても、スライムを倒すにはこんぼうがいいのだ。もっといいのは、地面に落ちている石を使うことだ。どこにでもあってすぐ使える。格好をつける必要はない。石にもこんぼうにも設定は必要なく、プラグインも必要ない。
なぜCLIツールの入力は戻れないのか
例えばnpm initは最初にこんな感じのダイアログが出ます。
name: (test) test version: (1.0.0) description: entry point: (index.js) test command: git repository: keywords: author:
yeomanとかも一緒です。
これ、基本的にEnterを連打する類のものではありますが、 基本的に入力したら戻れません。 （とかいって戻れたら赤っ恥ですが）
なぜこうではいけないのでしょうか。
これなら、こんな感じの利点がありますね。
- 好きな順序で入力できる
- デフォルト値でよい項目は、エンターで確定するのではなく、単に無視すればよい
- 残項目がいくつあるのか分かる
というわけで作ってみました（ライブラリ化はしてません）。
hashrock/idea-friendly-dialog-cli · GitHub
もちろん、既存のものの方がシンプルな実装なはずで、より多くの環境で動きそうですし、 npm本体やyeoman本体にこれを送りつける自信はありません。
こんなアイデアもあるということで。
追記：そういえば、カーソルキーの使いにくい環境もありそうですね。
2015年振り返り
振り返っても大したことをしていないような気もする。
そもそも１年って区切りはどうなんだろう。毎年１２月になってから、あっやべえ今年なんもしてねえや、ってなっている気がする。４半期ごとに反省すべきなのではないか？常に反省しろという話はある。
一年を通してみると、Vue.jsのコミュニティに入ってみて、翻訳の手伝いをしたのはとても良かった気がする。知り合いができたことで勉強会の居心地が良くなった。他のエンジニアの活動に興味が持てるようになったのは自分にとっていいことじゃないかと。
とりあえず来年のことは来年考えるとして、今年のログ。
1月
- DevHubのgridfs化に協力
- …といっても、サンプル書いて提供しただけでプルリクエストにしなかった。こういう中途半端なヘルプはなるべくしないようにしたい。
3月
4月
- flexbox記事@Qiita
- 勉強のために書いた記事。IE8がいなくなるということでflexboxの機運が高まっているけど、実のところみんなfloatを使っていて、それでflexboxの実用的な記事が不足しているんじゃないだろうか。
- npmことはじめ@Qiita
- 社内勉強会で発表したところ好評だったためQiita用に書きなおした記事。フロントエンドにはいろいろ思うところがあるけど、もっとツール周りが単純じゃないと誰もついていけなくなるよねと思う。
6月
- Vue.js日本語版Docリリース
- kazuponさん中心のVue.js日本語化プロジェクトが実を結んだ。
- CSS3アニメーション記事@Qiita
- アニメーション、みんなjQueryでやってるのが現実じゃないだろうか。
7月
- 社内で脱Excel絡みのことを少しずつやってた。
9月
- jekyllいじってた
- go始めた
- 仕事のコードとかこっそりgoで書いてみたけど、生産性高いなぁ。C書かなくていい時代が早く来てほしい。
10月
- 絵の練習始めた
- 筋トレ（スクワットとプランク）始めた
- Vue.js 1.0 Docリリース
- ついに本家に取り込まれる。
11月
- 脱Bootstrapガイド@Qiita
- 実際は中途半端な記事なんだけどバズった。何も考えずにbootstrap使うのやめたほうがいいとは本当に思う。bootstrap使おうが使うまいが、作ったものの責任は自分しか取れないし。
- Node学園祭行ってきた
12月
- シャープの電子ノート買った
- 電池の持ちが本当に良い。シャープ潰れるの惜しいな（まだ決まったわけではない）
- クロッキー続けている
- いろいろ身の回りの改善活動。
- Sushicorp Advent Calendar書いた。
- 最後までは書けなかったけど、くだらないネタが書けてよかった。
リモートから鮨を送り込むコマンド
SushiCorp Advent Calendar 2015の15日目です。
新作です。 スマホをリモコンにして、手持ちのサーバにsushiを送り込めたら最高ですね。
動作の様子
- sushibtn sushi "echo sushi"とかやると、リモコンサーバが起動し、ボタンを押すとecho sushiが実行されます。
- 無駄にQRコード出力機能が備わっており実用的です。
- makeとかをスマホから実行させると実用的かもしれません。
リポジトリ
インストール
git clone https://github.com/sushicorp/sushibtn npm install -g .
実行方法
sushibtn [ボタンのラベル名] "[実行したいコマンド]"
鮨のローディングアニメーション
Sushicorp Advent Calender 2015の8日目です。
ページローディング中は、読込中を表すスピナーを回す習わしになっていますね。
でも、これって一体何でしたっけ？ そもそもなんでこれを回してるのか、よく考えると意味がわかりませんね。
待たされてる感があってイライラしますね。 ホスピタリティが今ひとつ感じられません。
こんなよくわからないものよりも、鮨を回すべきじゃないですか？
というわけで、回しました。
DEMO: Sushi Loading
あなたも、スピナーなんかより、鮨を回してみませんか。 リポジトリはこちらです。
鮨の物理演算
Sushicorp Advent Calender 2015の一日目です。
親方！空からsushiが！
http://hashrock-sandbox.github.io/study-matterjs/
matter.jsとても簡単ですね。 デフォルトレンダラが大変有能で、デフォルトでワイヤーフレームON、 OFFの場合は指定したテクスチャで物体を描画してくれます。
ソースはこちら
hashrock-sandbox/study-matterjs · GitHub
明日は弊社CTOが弊社について何か書いてくれるはずです。
