(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
by Jonathan Rochkind, http://bibwild.wordpress.com
Capistrano automates pushing out a new version of your application to a deployment location.
I've been writing and deploying Rails apps for a while, but I avoided using Capistrano until recently. I've got a pretty simple one-host deployment, and even though everyone said Capistrano was great, every time I tried to get started I just got snowed under not being able to figure out exactly what I wanted to do, and figured I wasn't having that much trouble doing it "manually".
I've recently ran into a pitfall of [React.memo()
][memo] that seems generally overlooked; skimming over the top results in Google just finds it mentioned in passing in a [React issue][regit], but not in the [FAQ] or API [overview][react-api], and not in the articles that set out to explain React.memo()
(at least the ones I looked at). The issue is specifically that nesting children defeats memoization, unless the children are just plain text. To give a simplified code example:
const Memoized = React.memo(({ children }) => (<div>{children}</div>));
// Won't ever re-render
<Memoized>bar</Memoized>
// Will re-render every time; the memoization does nothing
Memoization is a somewhat fraught topic in the React world, meaning that it's easy to go wrong with it, for example, by [making memo()
do nothing][memo-pitfall] by passing in children to a component. The general advice is to avoid memoization until the profiler tells you to optimize, but not all use cases are general, and even in the general use case you can find tricky nuances.
Discussing this topic requires some groundwork about the technical terms, and I'm placing these in once place so that it's easy to skim and skip over:
# source : http://code.google.com/p/natvpn/source/browse/trunk/stun_server_list | |
# A list of available STUN server. | |
stun.l.google.com:19302 | |
stun1.l.google.com:19302 | |
stun2.l.google.com:19302 | |
stun3.l.google.com:19302 | |
stun4.l.google.com:19302 | |
stun01.sipphone.com | |
stun.ekiga.net |
# If you work with git, you've probably had that nagging sensation of not knowing what branch you are on. Worry no longer! | |
export PS1="\\w:\$(git branch 2>/dev/null | grep '^*' | colrm 1 2)\$ " | |
# This will change your prompt to display not only your working directory but also your current git branch, if you have one. Pretty nifty! | |
# ~/code/web:beta_directory$ git checkout master | |
# Switched to branch "master" | |
# ~/code/web:master$ git checkout beta_directory | |
# Switched to branch "beta_directory" |
{url:'stun:stun01.sipphone.com'}, | |
{url:'stun:stun.ekiga.net'}, | |
{url:'stun:stun.fwdnet.net'}, | |
{url:'stun:stun.ideasip.com'}, | |
{url:'stun:stun.iptel.org'}, | |
{url:'stun:stun.rixtelecom.se'}, | |
{url:'stun:stun.schlund.de'}, | |
{url:'stun:stun.l.google.com:19302'}, | |
{url:'stun:stun1.l.google.com:19302'}, | |
{url:'stun:stun2.l.google.com:19302'}, |