- Using emmet in jsx files
- Emmet expands text when js autocomplete needed
- Using
className
instead ofclass
- Install plugin RegReplace
- Install plugin Chain Of Command
┐┌┐┌┐ | |
┘└┘└┘\ₒ/ | |
┐┌┐┌┐ ∕ Friday | |
┘└┘└┘ノ) | |
┐┌┐┌┐ deploy, | |
┘└┘└┘ | |
┐┌┐┌┐ good | |
┘└┘└┘ | |
┐┌┐┌┐ luck! | |
│││││ |
One word: task automation. It's basically zero effort and you can use the ./task.js package manager to handle any repetitive tasks. You can use ./task.js
to automate everything with minimum effort.
./task.js
provides the structure, order, and authority that you as a developer so desperately crave.
./task.js
will also take responsibility for your actions if you need it to. It's what everybody is using now.
./task.js
is the new hotness. It's all about ./task.js
now, just like that.
This is compared to npm run/bash scripts, which are:
This year marks the first year that we are doing full scale rendering of our SPA application on our mobile.walmart.com Node.js tier, which has provided a number of challenges that are very different from the mostly IO-bound load of our prior #nodebf.
The infrastructure outlined for last year is the same but our Home, Item and a few other pages are prerendered on the server using fruit-loops and hula-hoop to execute an optimized version of our client-side JavaScript and provide a SEO and first-load friendly version of the site.
To support the additional CPU load concerns as peak, which we hope will be unfounded or mitigated by our work, we have also taken a variety of steps to increase cache lifetimes of the pages that are being served in this manner. In order of their impact:
We run multiple server processes in two data centers. Each process listens on two ports, one for HTTP and one for HTTPS. HTTPS is terminated by Apache prior to reaching node.js. HTTP goes directly from the client to node.js (through a master load balancer). We do not use clusters. We slice our physical servers into thin virtual machines running SmartOS, each with about 3GB of memory designed for a single node.js process.
Our node.js servers are hapi.js servers using the composer functionality and plugins architecture. We have three sets of plugins loaded: mobile web front end experience (single page app), legacy API reverse proxy, and monitoring.
We also serve original node.js services off another server zone which runs closed source plugins using hapi.
My thoughts on writing tiny reusable modules that each do just one | |
thing. These notes were adapted from an email I recently sent. | |
*** | |
If some component is reusable enough to be a module then the | |
maintenance gains are really worth the overhead of making a new | |
project with separate tests and docs. Splitting out a reusable | |
component might take 5 or 10 minutes to set up all the package | |
overhead but it's much easier to test and document a piece that is |
var If = React.createClass({ | |
render: function() { | |
return this.props.value && this.props.children; | |
} | |
}); | |
// usage | |
<If value={this.state.whatever}> | |
Stuff | |
</If> |
I've been struggling to come up with a good pattern for handling loading state in Flux (specifically using Fluxxor, though I think this is an issue for any implementation).
When I say "loading state," what I mean is state in a store that tracks:
Here's my first (very simple) pass at this, a store mixin called LoadingStoreMixin.js
:
// Disable javascript execution from console | |
// http://kspace.in/blog/2013/02/22/disable-javascript-execution-from-console/ | |
var _z = console; | |
Object.defineProperty( window, "console", { | |
get : function(){ | |
if( _z._commandLineAPI ){ | |
throw "Sorry, Can't exceute scripts!"; | |
} | |
return _z; | |
}, |