VISA デビットカードを作った
自分のクレジットカードを使うことに対する感覚が少し麻痺している気がするのと、月単位での買い物の内容を分析しやすくするために VISA デビットカードを作って使うことにした。
個人的に、インターネットで買い物ができるのであれば、特別クレジットカードでなければいけない理由はない(還元とかあるけど、お金の出入りを管理して、無駄遣いを減らすほうが大事だと判断した)。
今まで使っていたクレジットカードは、分割払いにしたい大きい額の買い物(例えば、歯の治療とか...)だけに使うことにした。
年末年始の休暇中に読んだ本
炬燵に入り、みかんを摘みながら読んだ。
- 作者: ユヴァル・ノア・ハラリ,柴田裕之
- 出版社/メーカー: 河出書房新社
- 発売日: 2016/09/08
- メディア: 単行本
- この商品を含むブログ (15件) を見る
- 作者: ユヴァル・ノア・ハラリ,柴田裕之
- 出版社/メーカー: 河出書房新社
- 発売日: 2016/09/08
- メディア: 単行本
- この商品を含むブログ (10件) を見る
人類がなぜ繁栄したかを壮大なスケールで語る一冊。集団で虚構・神話・空想を信じることができるようになった認知革命に始まり、農業、書記体系、貨幣、宗教、科学と話が進んでいく。
この本の面白さは、自分の先入観や常識が覆され、違った視点で物事を眺める体験ができることにある。自分が当たり前のように善だと信じていたもの、例えば、自由主義や資本主義が、あくまでひとつの虚構に過ぎないものだと認識させられる。
また、一般的に良かったこととして記述されがちな狩猟から農耕への移行を、人類にとっては実はそれほど利はなく、小麦が種の繁栄のために逆に人類を支配した、という主張も面白かった。
- 作者: 出口治明
- 出版社/メーカー: ポプラ社
- 発売日: 2016/01/13
- メディア: 単行本
- この商品を含むブログ (8件) を見る
若者をターゲットにお金との付き合い方が書かれている本。単純にお金の話だけでなく、少子高齢化や、それに伴う公的年金の負担増といったテレビが煽る先行きの暗い話を数字と事実で分析する過程を通して、メディア・リテラシーの重要性も説く。
- 作者: 西森秀稔,大関真之
- 出版社/メーカー: 日経BP社
- 発売日: 2016/12/09
- メディア: 単行本
- この商品を含むブログ (1件) を見る
量子コンピューターの方式の一つである量子アニーリング法とその実現方法、さらにはディープラーニングにどのように応用されるかを噛み砕いて説明している。
TypeScript で書いている Node.js サーバーをファイルが変更されたときに自動で再起動したい
題の通り。
TypeScript に慣れるために、TypeScript でちょっとした Node.js サーバーを書いていたときのメモ。
GitHub - TypeStrong/ts-node: TypeScript execution environment for node で TypeScript のコードを直接 Node.js で動かすことができるのだけど、.ts ファイルの変更の度にプロセスを落として、またコマンドを実行して... というのが面倒だったので、自動で再起動させる方法を調べた。
ts-node の Issue を眺めたかんじだと、onchange という npm でインストールできるコマンドを使って、ファイルの変更を検知して再起動すればよいのではとのこと。以下のような npm scripts のタスクを定義して、呼び出すようにする。
"scripts": {
"server:dev": "onchange server.ts -i -v -- ts-node server.ts"
},
ふしぎの国のバード を読んだ
読んだ。
ふしぎの国のバード 1巻<ふしぎの国のバード> (ビームコミックス（ハルタ）)
- 作者: 佐々大河
- 出版社/メーカー: KADOKAWA / エンターブレイン
- 発売日: 2015/05/15
- メディア: Kindle版
- この商品を含むブログ (2件) を見る
明治初期にイギリス人の探検家 イザベラ・バード が日本を探検した際の実話を基に書かれた漫画。当時の日本の風景や庶民の生活が描かれていて面白い。明治初期は、300年続いた鎖国が終わり、日本がグローバリゼーションの影響を著しく受けた時期と言える。その時期に失われた何かを知るきっかけとなる作品ではないだろうか。
2016年のふりかえり
今年も残すところあと少し。今年のふりかえりです。
去年のふりかえりはこれです。 2015年のふりかえり - kitak.blog
仕事
去年に続き、ウェブフロントエンド中心に JavaScript のコーディングなど。サービスや大きめの機能をいくつかリリースできたのと、その中で大量のオブジェクトやトラフィックを扱う案件をこなすことができて、ひとつ自信に繋がったような気がします。自己否定がちょい強めなので、ひとつひとつ形にしていって肯定感を高めていきたいところ。
前半、Java や Spring Boot ( Spring MVC ) の勉強をしていて、正直仕事や趣味でそれらをがっつり書くことはなかったんですが、上半期の仕事でデバッグをするときに抵抗なくサーバーサイドのコードを読んで、問題特定に役立てることができたので、やっておいてよかったかな、と。
去年も同じことを書いていた気がするんですが、やることを限定しすぎているような気がするので、そこは来年の課題。
アウトプット
発表
Vue.js meetup で発表しました。 Vue.js Tokyo v-meetup="#1"でLTしてきた、と発表からカットしたMVVMのあれこれ - kitak.blog
これ一回だけだったので、うーむ...というかんじです。スライドにまとめるのは自分自身の理解のためにも良いので、居酒屋で酒を呑みながらカジュアルに発表するようなのを定期的にやりたいね、と同じことを考えている人と話していたり。
執筆
gihyo.jp で Vue.js の入門記事を執筆しました。執筆の機会をいただきありがとうございました。
ブログ
特に明確な目標があったわけではないんですが、週に1回はブログを更新するように意識していました。気分が乗らないときは、とりあえず続けばいいやぐらいの気持ちで漫画やドキュメンタリーの感想を書いたり。
書いた記事のうち、何個かホットエントリ入りして、たくさんの人に読んでもらえたのがうれしかったです。
- 2016年に使った&来年使いそうな JavaScript 関連のものと所感 - kitak.blog
- 既存のコードの理解が捗るChrome DevToolsの使い方 - kitak.blog
- ウェブフロントエンドのパフォーマンス改善のひとつの日常 - kitak.blog
生活
風邪をひくことが多い一年でした。下半期は、一ヶ月半に一回くらいのペースで風邪をひいていたように思います。運動不足で、体重が増えているのもありますし、来年はもっと健康に気を使いたい。 外は寒いですが、とりあえずウォーキングから始めて、引っ越したら近くのジムに通おうかな、と思っていたり。
上でも書きましたが、来年、会社のオフィスが新宿に移転するので、それに合わせて引っ越す予定です。今のところ、祐天寺、中目黒、新宿御苑、代々木あたりを考えています。
去年に引き続き、浮いた話は全く無いので、そこは来年も引き続きがんばりましょう。
2016年に使った&来年使いそうな JavaScript 関連のものと所感
2016年に使った&来年使いそうな JavaScript 関連のもの
以下のカテゴリでなんとなく書いてみます。去年と比べて大きく変わらないかんじです。動きの早かった 2, 3年前から、年々、動きはゆっくりになってきているというのが個人的な印象。
トランスパイラ
2016年に使った:
Babel。各ブラウザの JavaScript エンジンで ES2015~ES2017 の実装が進んでいるので、関わっている案件のブラウザのシェア次第なところもありますが、ES2015~ES2017 の仕様だけトランスパイルしたいのであれば、再来年あたりから要らなくなるんじゃないかな、という気持ち。
来年使いそう:
静的型付けがメインで、ES20XX から ES5 へのトランパイルは副次的ですが、TypeScript。先日、久しぶりに触ったら( v2.1 )、v1.6 か v1.8 の頃に触って微妙だな、と思った諸々が改善されていました。
- サードパーティの型定義ファイルの取得がそれ用のツールではなく npm でできるようになった
- 別ファイルに定義された型情報を参照するために reference タグを書く必要がなくなった
- async/await を es5 target でダウンパイルできるようになった ( 以前は、いったん es2015 に変換した後に babel でさらにトランスパイルをしないとダメで、ビルドチェーンが複雑になるからスルーしていた )
- targetに esnext, es2015, es2017 が指定できるので、型宣言だけ抜いた JavaScript ファイルが生成できる。やめたくなったらすぐにやめれる
- Visual Studio Codeとの連携が良くできている ( 最近 Visual Studio Code 使っているので )
ビューライブラリ/フレームワーク
2016年に使った:
Vue。既存のサービスでのちょっとした UI の実装から、SPA のフルスクラッチの実装まで幅広く使いました。良さは色々あるんですが、以下の3点が大きいです。
周囲だと React , Redux を使っている人もちらほら。React、良いと思うんですが、今の会社のワークフローだと HTML を JSX に手で書き換える作業が発生するので、個人的にそれがつらいので選択していません。( React に限らず、Vue も含めたコンポーネント指向のライブラリを使うとどうしても二度手間感が否めないワークフローなので、来年はそこを改善したい、と思っていたり )
今年の9月末にリリースされた Vue v2.0 で パフォーマンス改善 & Server Side Rendering もできるようになったので、特別 React を選ぶ理由がなくなったというのもあります。
来年使いそう:
今年と同じ感じ。新しいライブラリを実戦で使うことは今のところなさそうですが、Shadow DOM v1 や Custom Element v1 の実装が Chrome や Safari で進んでいる背景も踏まえつつ、https://github.com/skatejs/skatejs のような WebComponent のAPIを薄くラップしたライブラリはウォッチしておこうと思っています。
モジュールバンドラ
2016年に使った:
Browserify。それなりの規模のプロジェクトだと生成されるファイルサイズが大きくなる以外は不満はなく。ビルドにかかる時間も watchify を使えばだいぶ短くできます。ただ、開発が活発ではなくなっているのと、モジュールバンドラとしては Webpack を使う人が増えて、Browserify を使う人が減ってきているような気がするのが気がかり( ソース: The State of Front-End Tooling 2016 - Results - AshleyNolan.co.uk - Blog and Portfolio for Ashley Nolan )。
来年使いそう:
Browserify でもまだ困らないとは思うんですが、Webpack2 を検討しています。理由はビルドにかかる時間が短い、コード分割(と動的ローディング)、Tree Shaking で生成されるファイルのサイズを減らせるというあたりです。ただ、先日のブログ( JavaScript のサイズを減らすことと効率良くキャッシュさせるためのメモ - kitak.blog )の最後に書いたようにツールの自由度が高く plugin と loader の使い過ぎが後々の負債に繋がりそうな予感がするので、いったんは JavaScript のモジュールバンドラとして使い、stylesheet や画像は扱わないつもりです。
タスクランナー
2016年に使った:
npm-scripts(yarn run も含む)。npm run ほにゃらら で browserify のコマンドを実行したり、コマンドをパイプで繋いだり、複雑になってきたら JavaScript で書いたスクリプトを node で実行したり、シェルスクリプトを実行しています。
数年前からあるプロジェクトや一部のタスクは Grunt を使ってます。Grunt、今でもメンテはされているので、使っている Grunt プラグインが全くメンテされなくて業務に支障が出るとかがないのであれば、既存のプロジェクトで急いで違うツールに乗り換える必要はなさそうです( 時間があれば乗り換えてもよさそうですが )。
来年使いそう:
多分、これまでと変わらず。
パッケージマネージャ
2016年に使った:
Yarn。リリース日に触ったらパッケージを git リポジトリの url で指定すると動かなくて、しばらく様子見していたんですが、一ヶ月ぐらい前に触ったら修正されていて、それ以来使っています。体感ですが、パッケージのインストールが非常に速い。その他、npm の生成する package.json と互換性があったり、バージョン固定の仕組み( npm shrinkwrap はバグやハマりどころが多かった )など、諸々鑑みて、使わない理由がない。
来年使いそう:
多分、今年と変わらず。
テスティング
2016年に使った:
あんまりこだわりがないので昔から使っている Karma(テストランナー) + Jasmine(テスティングフレームワーク) + PhantomJS。
来年使いそう:
来年使うものというより、よっぽど強い理由がないのであれば、使っているビューライブラリやフレームワークが、自身のテストに使っていたり、ドキュメントで推奨しているものを使うのが無難だと考えています。
所感
最近、心の中でふつふつと思っていたことです。
動き早い？
冒頭にも書きましたが、年々、落ち着いてきているような気がします。今年に関して言うと、去年から耳にしていた・ある程度使われていたものが今年になって、改善・改良されて、さらに使われるようになったというところではないでしょうか。それは、The State of Front-End Tooling 2016 - Results - AshleyNolan.co.uk - Blog and Portfolio for Ashley Nolan の結果にも現れています。
とはいえ、上で書いたカテゴリだけでも 6つあって(他にも色々 Lint とかあるんですが ESLint が当たり前になっているので省きました)、JavaScript を普段書かない人からすると、学ぶべきことがたくさんあるように感じる、適当にググったら、過去に広く使われていたものや「それぞれのツールを組み合わせてみた」みたいな記事が大量に出てきて、あたかも動きが早いように感じるのではないでしょうか。
実際のところ、全ての案件で上のカテゴリのツールやライブラリ全てが必要なわけではありません。極端な例をあげれば、公開期間が数週間のキャンペーンページだと、(マサカリ飛んできそうですが) jQuery 互換のライブラリを npm で入れて、ES5の仕様でシュッとコード書いて、ファイルを concat (これもいらなくなりつつある), uglify しておしまいということもあります。自分が必要なものを理解して、選んで使えばいいだけです。なので、コンテキストをすっ飛ばして「React, Redux, Webpack, ... このスタックでやっとけば間違いない！」 みたいな記事を見ると、眉をひそめたくなります。
個人的に、JavaScript やその周辺のことを学び始めた人が自分の作っているものや関わっている案件に対して、必要なものを適切に選ぶことができるガイドやYes/Noチャートのようなものが世の中に足りないんじゃないかな、と感じています。
あとは、2016年にJavaScriptを学ぶとこんな感じ – Medium Japan – Medium に書かれているような普段 JavaScript を書いている人がそうじゃない人に「イマドキはこれだから！」とその人がやりたいことに対して過剰なものを押し付けたり、不安を掻き立てるようなことをしないということですね...(自戒もこめて)
新しいライブラリ・ツールとの向き合い方
落ち着いてきているように感じるとはいえ、新しいライブラリやツールは次々と出てきます。そういったライブラリやツールとはどう向き合えばいいのか。個人的には次のような感じでやっています。
- README を読んで、それが何を解決するかやどのカテゴリに属するかを考える
- 良さそうであれば sandbox プロジェクトで試す
- そのプロジェクトが作られて2, 3年未満の場合は2, 3年経つまで放置
- 2, 3年経っていたら、それを使うことで生産性が数倍向上しそうか(ちょっと向上するぐらいだったらやめる)、その間にあったリリース内容やコミュニティの発展、直近のWeb標準やプロコトルの進化や発展で不要にならないか等を鑑みて実戦に投入するか判断
2, 3年というのは、けっこう適当なんですが、新しく出てくるツールは大抵 2, 3 年の内に消えているように思うので、2, 3 年生き延びたのであれば、今後も存続し、実戦で使うに耐えうるクオリティになっているだろうという考えです（yarn, 今年出てきたやつやんとツッコミ受けそうなんですが、package.json そのままで npm を置き換えればいいだけなので例外）。一時期、新しいものを使うのが正しいと思っていた時期もあったんですが、kintoneフロントエンド開発 モダン化への道 のスライドやロードマップ指向とエコシステム指向 - アンカテ を読んで、いわゆる中心部のレッドオーシャンを避けるようになりました。白洲次郎が、ツイードは2, 3年雨ざらしにして着ろと言っているように、JavaScript 関連のツール・ライブラリも2, 3年様子見するぐらいがちょうどいいんじゃないでしょうか（ツイード着たことないですが…）。
おしまい。
