サイズがあまりに大きくなってしまったので、gist ではなくて github 上で管理するようにしました。
https://github.com/Shinpeim/process-book
URL 変わっちゃうの申し訳ないんだけど、一覧性が高くなるのと pull req が受け取れるメリットのほうを取ります。せっかく読みにきてくれたのにひと手間かかっちゃってすみません。
Latency Comparison Numbers (~2012) | |
---------------------------------- | |
L1 cache reference 0.5 ns | |
Branch mispredict 5 ns | |
L2 cache reference 7 ns 14x L1 cache | |
Mutex lock/unlock 25 ns | |
Main memory reference 100 ns 20x L2 cache, 200x L1 cache | |
Compress 1K bytes with Zippy 3,000 ns 3 us | |
Send 1K bytes over 1 Gbps network 10,000 ns 10 us | |
Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD |
サイズがあまりに大きくなってしまったので、gist ではなくて github 上で管理するようにしました。
https://github.com/Shinpeim/process-book
URL 変わっちゃうの申し訳ないんだけど、一覧性が高くなるのと pull req が受け取れるメリットのほうを取ります。せっかく読みにきてくれたのにひと手間かかっちゃってすみません。
英語圏ではかなり前からvimで開発し続けることのリスクについて語られていたが、いよいよ具体的な弊害が出て来ているようなので、かいつまんでメモ。日本でもそう遠くない未来だと思う。
Visual Studioのように需要が逼迫しているのに人材の供給が増えず需給ミスマッチが起っているわけでは無く、需要も供給も減るという状況下でわずかだが需要が上回っているとう性質の悪い状況がvimに起きている。特に深刻なのは安価な若手エンジニアの採用が絶望的に難しいという現実だ。TextMateが台頭して数年経ちXcodeがメインストリームの先頭を突っ走る2013年において新しくvimを勉強しようとする若者はよほどの物好きしかいない。30~40歳のvimエンジニアを雇うのはそれほど難しく無いだろうがコストがかかる。安価な20代前半の若手エンジニアを雇いたいという企業の思いとは裏腹にvimを新たに学ぶ若者は絶滅寸前だ。
とても優秀な若者を雇用できるチャンスが巡って来た。採用担当者はこう尋ねる。「vimは習得していますか?」「もちろんEclipse/NetBeans/Xcodeはお手の物です。IntelliJもある程度可能です」「もう一度伺いますがvimは習得していますか?」「申し訳ございません 未習得です」
// Run in the JavaScript console of the hterm browser window | |
// Clear all existing settings - you probably don't want to do this. | |
// Preferences are now stored in "chrome.storage.sync" instead of | |
// "window.localStorage" so if you clear your preferences the changes | |
// will be propagated to other devices. | |
//term_.prefs_.storage.clear(); | |
var htermProfiles = [ |
After publishing my article on ECMAScript 6, some have reached out to ask how I exactly I make it all work.
I refrained from including these details on the original post because they're subject to immiment obsoletion. These tools are changing and evolving quickly, and some of these instructions are likely to become outdated in the coming months or even weeks.
When evaluating the available transpilers, I decided to use 6to5, which has recently been renamed to Babel. I chose it based on:
Since Twitter doesn't have an edit button, it's a suitable host for JavaScript modules.
Source tweet: https://twitter.com/rauchg/status/712799807073419264
const leftPad = await requireFromTwitter('712799807073419264');
With the release of Node 6.0.0, the surface of code that needs transpilation to use ES6 features has been reduced very dramatically.
This is what my current workflow looks like to set up a minimalistic and fast microservice using micro and async
+ await
.
React.createClass
, extending React.Component
and also stateless functional components.renderOnError()
in a compWhether your component relies on client-side features or you are using 3rd party components that are not designed for server-side rendering, sometimes you'll want to defer rendering until on the client. For our example, we'll be using react-chart-2 to load a Doughnut chart.
You'll need a next
project and to install chart.js
+ react-chartjs-2
.
$ npm install --save chart.js react-chartjs-2