ugiacoman

Whether 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  

Aldredcz

Notes

• This code handles any JS runtime error during rendering React components. Without this handling, once an error occurs, whole component tree is damaged and can't be used at all. With this handling, nothing will be rendered in production environment (error span in dev env.) + in production the error is logged to Sentry (if you are not using it just delete related code)
• This is basicaly a workaround for proposed feature in React core - described in Issue: facebook/react#2461
• Works for all variants of Component creation - React.createClass, extending React.Component and also stateless functional components.
• To get this work, just put this snippet into your entry js file. Then it will work in whole application.
• Also supporting React Hot Reload!
• If you find this useful, please retweet https://twitter.com/Aldredcz/status/744650159942995968 :)

Ideas

• specify custom error renderer (global / per component, e.g. by implementing method renderOnError() in a comp

rauchg

Minimum Viable Async with Node 6

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.

The promise

rauchg

require-from-twitter

Since Twitter doesn't have an edit button, it's a suitable host for JavaScript modules.

How to use

Source tweet: https://twitter.com/rauchg/status/712799807073419264

const leftPad = await requireFromTwitter('712799807073419264');

rauchg

Effective transpiling of ES6

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.

The main tool

When evaluating the available transpilers, I decided to use 6to5, which has recently been renamed to Babel. I chose it based on:

nulltask

Express / Socket.IO をスケールアウトしてみよう

• Seiya Konno
  • Works at Uniba Inc. (http://uniba.jp)

• https://twitter.com/nulltask
• https://github.com/nulltask
• https://fb.me/nulltask

russelldavies

// 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 = [

nekoruri

ついに顕在化しはじめた「vimリスク」

英語圏ではかなり前からvimで開発し続けることのリスクについて語られていたが、いよいよ具体的な弊害が出て来ているようなので、かいつまんでメモ。日本でもそう遠くない未来だと思う。

若手エンジニアの不足

Visual Studioのように需要が逼迫しているのに人材の供給が増えず需給ミスマッチが起っているわけでは無く、需要も供給も減るという状況下でわずかだが需要が上回っているとう性質の悪い状況がvimに起きている。特に深刻なのは安価な若手エンジニアの採用が絶望的に難しいという現実だ。TextMateが台頭して数年経ちXcodeがメインストリームの先頭を突っ走る2013年において新しくvimを勉強しようとする若者はよほどの物好きしかいない。30~40歳のvimエンジニアを雇うのはそれほど難しく無いだろうがコストがかかる。安価な20代前半の若手エンジニアを雇いたいという企業の思いとは裏腹にvimを新たに学ぶ若者は絶滅寸前だ。

とても優秀な若者を雇用できるチャンスが巡って来た。採用担当者はこう尋ねる。「vimは習得していますか？」「もちろんEclipse/NetBeans/Xcodeはお手の物です。IntelliJもある程度可能です」「もう一度伺いますがvimは習得していますか？」「申し訳ございません 未習得です」

Shinpeim

重要

サイズがあまりに大きくなってしまったので、gist ではなくて github 上で管理するようにしました。

https://github.com/Shinpeim/process-book

URL 変わっちゃうの申し訳ないんだけど、一覧性が高くなるのと pull req が受け取れるメリットのほうを取ります。せっかく読みにきてくれたのにひと手間かかっちゃってすみません。

この文書の目的

jboner

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