1150 lines
130 KiB
XML
1150 lines
130 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
||
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Lincoln Loop Blog</title><link>http://lincolnloop.com/blog/</link><description>Lincoln Loop Blog</description><atom:link href="http://lincolnloop.com/blog/feeds/latest/" rel="self"></atom:link><language>en-us</language><lastBuildDate>Tue, 13 May 2014 11:51:13 -0500</lastBuildDate><item><title>High Performance Django Kickstarter Project</title><link>http://lincolnloop.com/blog/high-performance-django-kickstarter-project/</link><description>
|
||
<p><strong>Please update to our new feed url: <a href="http://lincolnloop.com/blog/feed/">lincolnloop.com/blog/feed/</a></strong></p>
|
||
<hr/>
|
||
<p><a href="https://www.kickstarter.com/projects/1704706557/high-performance-django" style="float:left;display:inline-block; margin: 0 2em 1em 0"><img src="http://lincolnloop.com/uploads/uploads/hpd_cover.jpg" alt=""></a></p>
|
||
|
||
<p>I&#39;m really excited to (finally) announce that we are writing a book! We&#39;ve been working with Django professionally for a long time (over 7 years now). During that time, we&#39;ve learned <em>a lot</em> about how to use the framework to build fast and scalable websites. We&#39;re bundling up all that knowledge into an e-book called <strong><em>High Performance Django</em></strong> and it is up on <a href="https://www.kickstarter.com/projects/1704706557/high-performance-django">Kickstarter</a> today.</p>
|
||
|
||
<p>We&#39;re already well into the writing process, so we can tell you a little about what you&#39;ll get. The book is heavy on Django tips, but also reaches far beyond Python, showing you how to architect and tune the rest of your stack. It gives you an opinionated battle-tested blueprint utilizing many of the same techniques as high-profile Django sites like Disqus, Instagram, and Pintrest.</p>
|
||
|
||
<p>We hope to get the first edition out in July, but we need your help to make that happen. Writing and editing the book is going to be a massive undertaking and you can help support our effort. <a href="https://www.kickstarter.com/projects/1704706557/high-performance-django">Give us your vote of confidence by backing the project today</a>!</p></description><pubDate>Tue, 13 May 2014 11:51:13 -0500</pubDate><guid>http://lincolnloop.com/blog/high-performance-django-kickstarter-project/</guid></item><item><title>A Look at CSS Rule Organization</title><link>http://lincolnloop.com/blog/look-css-rule-organization/</link><description>
|
||
<p><strong>Please update to our new feed url: <a href="http://lincolnloop.com/blog/feed/">lincolnloop.com/blog/feed/</a></strong></p>
|
||
<hr/>
|
||
<p>CSS preprocessors have given us a handful of tools to re-architect our front-end code. We can keep things DRY with includes and extends or perhaps use nesting for code organization. All of these features allow a CSS rule to grow in complexity, but few people ever talk about managing that problem.</p>
|
||
|
||
<p>Let&#39;s take a look at a modern CSS rule. We&#39;ll talk about how they&#39;re structured and why we do what we do. Perhaps this will help you organize your own CSS!</p>
|
||
|
||
<p>Here&#39;s a very standard box. It is one of many box styles in our pretend design. It&#39;s sole purpose is to feature and highlight content and it can live almost anywhere in our UI.</p>
|
||
|
||
<p>(Note, we use SCSS primarily so all our demo code will as well.)</p>
|
||
|
||
<pre class="highlight"><code data-syntax="scss"><span class="nc">.featured-box</span> <span class="p">{</span>
|
||
<span class="k">@extend</span> <span class="err">%</span><span class="nt">center-box</span><span class="o">;</span> <span class="o">//</span> <span class="nt">Placeholder</span> <span class="nt">selectors</span> <span class="nt">first</span>
|
||
<span class="o">@</span><span class="nt">extend</span> <span class="nc">.info-box</span><span class="o">;</span> <span class="o">//</span> <span class="nt">Modifier</span> <span class="nt">classes</span> <span class="nt">second</span>
|
||
|
||
<span class="o">//</span> <span class="nt">All</span> <span class="nt">of</span> <span class="nt">the</span> <span class="nt">regular</span> <span class="nt">properties</span><span class="nc">.</span>
|
||
<span class="o">//</span> <span class="nt">Remember</span> <span class="nt">your</span> <span class="nt">grouping</span><span class="o">!</span>
|
||
<span class="nt">width</span><span class="nd">:</span> <span class="nt">90</span><span class="err">%</span><span class="o">;</span>
|
||
<span class="nt">height</span><span class="nd">:</span> <span class="nt">100px</span><span class="o">;</span>
|
||
|
||
<span class="nt">background</span><span class="nd">:</span> <span class="nt">blue</span><span class="o">;</span>
|
||
|
||
<span class="o">@</span><span class="nt">include</span> <span class="nt">fadeIn</span><span class="o">(</span><span class="nt">1</span><span class="nc">.5s</span><span class="o">);</span>
|
||
|
||
<span class="o">//</span> <span class="nt">Sub-selectors</span> <span class="nt">specific</span> <span class="nt">to</span> <span class="nt">this</span> <span class="nt">selector</span>
|
||
<span class="o">//</span> <span class="nt">Compiles</span> <span class="nt">to</span> <span class="nc">.featured-box</span> <span class="nc">.title</span>
|
||
<span class="k">&</span> <span class="o">&gt;</span> <span class="nc">.title</span> <span class="p">{</span>
|
||
<span class="na">font-weight</span><span class="o">:</span> <span class="no">bold</span><span class="p">;</span>
|
||
<span class="p">}</span>
|
||
|
||
<span class="c1">// Handle state. e.g. active, inactive, selected, etc.</span>
|
||
<span class="c1">// Compiles to .featured-box.is-active</span>
|
||
<span class="k">&</span><span class="nc">.is-active</span> <span class="p">{</span>
|
||
<span class="na">border</span><span class="o">:</span> <span class="mi">2</span><span class="kt">px</span> <span class="no">solid</span> <span class="no">dotted</span><span class="p">;</span>
|
||
<span class="p">}</span>
|
||
|
||
<span class="c1">// Any actions. Mostly standard interactivity</span>
|
||
<span class="c1">// Compiles to .featured-box:hover</span>
|
||
<span class="k">&</span><span class="nd">:hover</span> <span class="p">{</span>
|
||
<span class="na">background</span><span class="o">:</span> <span class="nb">green</span><span class="p">;</span>
|
||
<span class="p">}</span>
|
||
|
||
<span class="c1">// Context specific styles</span>
|
||
<span class="c1">// Compiles to .sidebar .featured-box</span>
|
||
<span class="nc">.sidebar</span> <span class="k">&</span> <span class="p">{</span>
|
||
<span class="na">width</span><span class="o">:</span> <span class="mi">100</span><span class="kt">%</span><span class="p">;</span>
|
||
<span class="na">height</span><span class="o">:</span> <span class="no">auto</span><span class="p">;</span>
|
||
<span class="na">background</span><span class="o">:</span> <span class="ni">whitesmoke</span><span class="p">;</span>
|
||
<span class="p">}</span>
|
||
|
||
<span class="c1">// Lastly, media queries!</span>
|
||
<span class="k">@media</span> <span class="o">(</span><span class="nt">min-width</span><span class="nd">:</span> <span class="nt">600px</span><span class="o">)</span> <span class="p">{</span>
|
||
<span class="na">width</span><span class="o">:</span> <span class="mi">50</span><span class="kt">%</span><span class="p">;</span>
|
||
<span class="na">margin</span><span class="o">:</span> <span class="mi">0</span> <span class="no">auto</span><span class="p">;</span>
|
||
<span class="p">}</span>
|
||
<span class="p">}</span></code></pre>
|
||
|
||
<p>It helps to think that rules tell a story. Our rule has a name. It has &quot;parents&quot; via @extend. It has a few properties and when you interact with it, it will do something (change its background color to green). When put in different situations via media queries or in <code data-syntax="text-only">.sidebar</code>, it will change its appearance.</p>
|
||
|
||
<p>Let&#39;s step through some of the best practices we use to build <code data-syntax="text-only">.featured-box</code>.</p>
|
||
|
||
<h2>Extends First</h2>
|
||
|
||
<pre class="highlight"><code data-syntax="scss"><span class="nc">.featured-box</span> <span class="p">{</span>
|
||
<span class="k">@extend</span> <span class="err">%</span><span class="nt">center-box</span><span class="o">;</span> <span class="o">//</span> <span class="nt">Placeholder</span> <span class="nt">selectors</span> <span class="nt">first</span>
|
||
<span class="o">@</span><span class="nt">extend</span> <span class="nc">.info-box</span><span class="o">;</span> <span class="o">//</span> <span class="nt">Modifier</span> <span class="nt">classes</span> <span class="nt">second</span>
|
||
<span class="nc">...</span></code></pre>
|
||
|
||
<p>Similar to includes, imports, or inheritance in other languages, we handle dependencies <em>first</em> by putting every @extend at the top. This cuts down on debug time later as we always know where to look for dependency problems.</p>
|
||
|
||
<p><code data-syntax="text-only">%center-box</code> is a <a href="http://sass-lang.com/documentation/file.SASS_REFERENCE.html#placeholder_selectors_">placeholder selector</a>, which means its name does not get compiled in our output CSS. Instead, its properties appear wherever we call them.</p>
|
||
|
||
<p>If you want to learn more about placeholder selectors, there are several <a href="http://www.sitepoint.com/sass-mixin-placeholder/">good articles</a> <a href="http://css-tricks.com/the-extend-concept/">on the topic</a>.</p>
|
||
|
||
<p>@extend can be a tricky feature, as it can tinker with the ordering of our output CSS. All the more reason to put them early in our rule. Every bit of organization helps!</p>
|
||
|
||
<p>Utility or modifier classes like <code data-syntax="text-only">.info-box</code> come next for similar reasons. I&#39;ll talk more about these in a moment.</p>
|
||
|
||
<p>Another advantage to putting external dependencies first is that it clarifies what the final output will be for a rule, as anything in a dependency would be overridden.</p>
|
||
|
||
<h2>Modifier Classes</h2>
|
||
|
||
<p>It&#39;s not uncommon to have a base class with a few other classes that change the meaning of an element. You&#39;ll see this a lot with buttons or boxes, especially in frameworks:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="html"><span class="nt">&lt;section</span> <span class="na">class=</span><span class="s">&quot;box partner-content hidden-phone featured-box no-borders&quot;</span><span class="nt">&gt;&lt;/section&gt;</span></code></pre>
|
||
|
||
<p>In this example, <code data-syntax="text-only">.box</code> is a base class that gives us some starting structure. We then inherit other styles through a series of modifier classes in an effort to nudge our box into place. This gets messy over time as we end up using a growing number of modifier classes to define what is essentially an unique element. This is where extends help again:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="scss"><span class="nc">.featured-partner</span> <span class="p">{</span>
|
||
<span class="k">@extend</span> <span class="nc">.partner-content</span><span class="o">;</span>
|
||
<span class="o">@</span><span class="nt">extend</span> <span class="nc">.featured-box</span><span class="o">;</span>
|
||
<span class="o">@</span><span class="nt">extend</span> <span class="nc">.no-borders</span><span class="o">;</span>
|
||
<span class="o">@</span><span class="nt">extend</span> <span class="nc">.hidden-phone</span><span class="o">;</span>
|
||
<span class="p">}</span></code></pre>
|
||
|
||
<p>We can then use this to new rule to write a more semantic class attribute:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="html"><span class="nt">&lt;section</span> <span class="na">class=</span><span class="s">&quot;**box featured-partner**&quot;</span><span class="nt">&gt;&lt;/section&gt;</span></code></pre>
|
||
|
||
<p>To get this effect without a CSS pre-processor we&#39;d have to write really long rules. This quickly becomes difficult to manage:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="css"><span class="nc">.featured-box</span><span class="o">,</span>
|
||
<span class="nc">.info-box</span><span class="o">,</span>
|
||
<span class="nc">.help-box</span><span class="o">,</span>
|
||
<span class="nc">.notification-box</span><span class="o">,</span>
|
||
<span class="nc">.user-info-box</span> <span class="p">{</span>
|
||
<span class="k">padding</span><span class="o">:</span> <span class="m">10px</span><span class="p">;</span>
|
||
<span class="k">font-size</span><span class="o">:</span> <span class="m">20px</span><span class="p">;</span>
|
||
<span class="p">}</span></code></pre>
|
||
|
||
<p>It&#39;s important to note that using extends or includes creates a dependency, so be careful! Also, as a rule of thumb, you should try to stick to one base class, one modifier, and one state:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="scss"><span class="o">&lt;</span><span class="nt">section</span> <span class="nt">class</span><span class="o">=</span><span class="s2">&quot;**box featured-box is-selected**&quot;</span><span class="o">&gt;</span> <span class="o">&lt;/</span><span class="nt">section</span><span class="o">&gt;</span></code></pre>
|
||
|
||
<p>That&#39;s much cleaner!</p>
|
||
|
||
<h2>Basic Properties</h2>
|
||
|
||
<p>Everyone seems to have a preferred order for properties. Some prefer alphabetical. Those who prefer grouping can almost never decide on the correct order. For example, I&#39;m a huge fan of defining components starting with the outside first, then working inward: </p>
|
||
|
||
<ol>
|
||
<li>Where is the box? (position, z-index, margins/padding)</li>
|
||
<li>What kind of a box is it? (display, box-sizing)</li>
|
||
<li>How big is the box? (width, height)</li>
|
||
<li>Box shadows, borders, etc</li>
|
||
<li>Backgrounds</li>
|
||
<li>Typography</li>
|
||
</ol>
|
||
|
||
<p>Intelligent grouping of properties will do a lot to ensure your CSS is accessible to other developers. Another common standard is &quot;one rule per line.&quot; As always, the most important guideline is <strong>be consistent</strong>.</p>
|
||
|
||
<h2>Mixins</h2>
|
||
|
||
<p>Here&#39;s where things get a little weird! You&#39;ll notice that we include a mixin in our rule:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="scss"><span class="k">@include</span><span class="nd"> fadeIn</span><span class="p">(</span><span class="mi">1</span><span class="mf">.5</span><span class="kt">s</span><span class="p">);</span></code></pre>
|
||
|
||
<p>Technically, <code data-syntax="text-only">fadeIn()</code> is a dependency. So why isn&#39;t it at the top? Mixins perform operations and inject the resulting CSS into the rule. This means that they are often dependent upon property ordering defined within the same rule. Grouping them near related properties helps make sense of output CSS. In simpler cases, I recommend putting mixins right after basic properties but before sub-selectors, which we&#39;ll discuss next.</p>
|
||
|
||
<h2>Sub-Selectors (or &quot;Think of the Children&quot;)</h2>
|
||
|
||
<p>The next section of <code data-syntax="text-only">.featured-box</code> deals with specific styles for its children. In our example above we&#39;re targeting the <code data-syntax="text-only">.title</code> class specifically:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="scss"><span class="c1">// Sub-selectors specific to this selector</span>
|
||
<span class="c1">// Compiles to .featured-box .title</span>
|
||
<span class="k">&</span> <span class="o">&gt;</span> <span class="nc">.title</span> <span class="p">{</span>
|
||
<span class="na">font-weight</span><span class="o">:</span> <span class="no">bold</span><span class="p">;</span>
|
||
<span class="p">}</span></code></pre>
|
||
|
||
<p>Notice that I didn&#39;t use a H3 or any other headline for that matter. Doing so restricts <code data-syntax="text-only">.featured-box</code> to a specific HTML structure, which may not always be best for accessibility or accurate with regard to the hierarchy of content. For example, <code data-syntax="text-only">.featured-box</code> could be used in a sidebar with a H4, or at the top of the page with a big H2.</p>
|
||
|
||
<p>Complex objects could call for dozens of sub-selectors. When this happens, consider putting common styles in a base rule, and meatier objects (that may exist on their own) into their own rules. Expanding on our original example, let&#39;s pretend we have a stylized list within <code data-syntax="text-only">.featured-box</code>.</p>
|
||
|
||
<pre class="highlight"><code data-syntax="scss"><span class="nc">.featured-box</span> <span class="p">{</span>
|
||
<span class="c1">// Lots of styles for </span>
|
||
<span class="nc">.tab-list</span> <span class="p">{</span>
|
||
<span class="c1">// 50 lines of styles for tabs!</span>
|
||
<span class="p">}</span>
|
||
<span class="p">}</span></code></pre>
|
||
|
||
<p>This is less ideal than:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="scss"><span class="nc">.featured-box</span> <span class="p">{</span>
|
||
<span class="c1">// Everything in our original example</span>
|
||
<span class="p">}</span>
|
||
|
||
<span class="nc">.featured-box</span> <span class="nc">.tab-list</span> <span class="p">{</span>
|
||
<span class="c1">// 50 lines of styles for tabs!</span>
|
||
<span class="p">}</span></code></pre>
|
||
|
||
<p>In this way we aren&#39;t losing the <em>special case</em> that is a <code data-syntax="text-only">.tab-list</code> inside of a <code data-syntax="text-only">.featured-box</code> amongst all the other styles.</p>
|
||
|
||
<h2>State and Actions</h2>
|
||
|
||
<p>CSS gives us a few actions to work with specific to our selected element. Most elements have :focus or :hover. Anchors have :visited and radio buttons have :checked. Often we shim these with classes or data attributes for use in richer interfaces:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="html"><span class="nt">&lt;button</span> <span class="na">type=</span><span class="s">&quot;submit&quot;</span> <span class="na">class=</span><span class="s">&quot;btn **is-sending**&quot;</span><span class="nt">&gt;</span>Sending...<span class="nt">&lt;/button&gt;</span></code></pre>
|
||
|
||
<p>Actions and state are usually dependent upon basic properties, but are often overridden depending on context. For example, the animation we may associate with <code data-syntax="text-only">.is-sending</code> may be different on desktop than on mobile, or we may have to override a color on hover of an anchor&#39;s default :link state.</p>
|
||
|
||
<p>As a side note, notice that I am using <code data-syntax="text-only">.is-sending</code> instead of <code data-syntax="text-only">.sending</code>. I always append <code data-syntax="text-only">.is-</code> to state classes to more clearly convey what they are.</p>
|
||
|
||
<h2>Context Specific Styles</h2>
|
||
|
||
<p>Context related styles always come last because they often have radical changes to appearance and layout. This fits well with a mobile first strategy, as you can clearly denote the <em>evolution</em> of a rule as you gain screen space.</p>
|
||
|
||
<p>In our example above, we&#39;re noting two different context changes:</p>
|
||
|
||
<ol>
|
||
<li>When <code data-syntax="text-only">.featured-box</code> is in <code data-syntax="text-only">.sidebar</code>.</li>
|
||
<li>When <code data-syntax="text-only">.featured-box</code> is on a larger display.</li>
|
||
</ol>
|
||
|
||
<pre class="highlight"><code data-syntax="scss"><span class="c1">// Context specific styles</span>
|
||
<span class="c1">// Compiles to .sidebar .featured-box</span>
|
||
<span class="nc">.sidebar</span> <span class="k">&</span> <span class="p">{</span>
|
||
<span class="na">width</span><span class="o">:</span> <span class="mi">100</span><span class="kt">%</span><span class="p">;</span>
|
||
<span class="na">height</span><span class="o">:</span> <span class="no">auto</span><span class="p">;</span>
|
||
<span class="na">background</span><span class="o">:</span> <span class="ni">whitesmoke</span><span class="p">;</span>
|
||
<span class="p">}</span>
|
||
|
||
<span class="c1">// Lastly, media queries!</span>
|
||
<span class="k">@media</span> <span class="o">(</span><span class="nt">min-width</span><span class="nd">:</span> <span class="nt">600px</span><span class="o">)</span> <span class="p">{</span>
|
||
<span class="na">width</span><span class="o">:</span> <span class="mi">50</span><span class="kt">%</span><span class="p">;</span>
|
||
<span class="na">margin</span><span class="o">:</span> <span class="mi">0</span> <span class="no">auto</span><span class="p">;</span>
|
||
<span class="p">}</span></code></pre>
|
||
|
||
<p>In this scenario, we want <code data-syntax="text-only">.featured-box</code> to be full width and have a subtle appearance when in <code data-syntax="text-only">.sidebar</code>. On larger screens, we want it to be 50% of the available width and ensure that no matter what it is center aligned regardless of other styles. The ordering doesn&#39;t matter here due to the specificity of the two changes. <code data-syntax="text-only">.sidebar &</code> will trump the media query change.</p>
|
||
|
||
<p>However, we put media queries last in rules because they most often deal with layout related changes, and putting those sort of changes in a predictable place in the same way we handled extends helps with debugging.</p>
|
||
|
||
<p><a href="http://filamentgroup.com/lab/element_query_workarounds/">Per element media queries</a> could alleviate some of the pain here, but at the time of this writing we do not have a clean CSS-only solution. Though <a href="https://github.com/Snugug/eq.js">many people</a> have put together <a href="http://www.smashingmagazine.com/2013/06/25/media-queries-are-not-the-answer-element-query-polyfill/">workable solutions</a>. Things can get out of hand when you have to consider an element&#39;s appearance not only across browsers and devices, but location in the UI and relation to other elements. </p>
|
||
|
||
<h2>That&#39;s It!</h2>
|
||
|
||
<p>This just scratches the surface of what it takes to write clean, maintainable CSS architecture. In the wild, our <code data-syntax="text-only">.featured-box</code> rule would likely be more complicated, with more dependencies, basic properties, and context changes. What best practices does your team follow to help keep complexity at bay?</p>
|
||
</description><pubDate>Thu, 08 May 2014 12:11:41 -0500</pubDate><guid>http://lincolnloop.com/blog/look-css-rule-organization/</guid></item><item><title>Speedy Browserifying with Multiple Bundles</title><link>http://lincolnloop.com/blog/speedy-browserifying-multiple-bundles/</link><description>
|
||
<p><strong>Please update to our new feed url: <a href="http://lincolnloop.com/blog/feed/">lincolnloop.com/blog/feed/</a></strong></p>
|
||
<hr/>
|
||
<p>Last month I talked about one of my favorite tools for JavaScript on the front end, <a href="http://lincolnloop.com/blog/untangle-your-javascript-browserify/">Browserify</a>, which allows you to create modular code for the browser using CommonJS modules and npm. It does this by combining the dependencies into an all-in-one bundle. In development, typically you will watch your JavaScript files for changes and then recompile the bundle.</p>
|
||
|
||
<p>If you&#39;re including some large dependencies in your bundle, though, you may have noticed that it can take several seconds to regenerate that bundle each time you edit a module. This usually isn&#39;t a big problem, but when you want to rapidly hack on a UI feature and frequently refresh to see your changes this several second display can end up seriously slowing you down.</p>
|
||
|
||
<p>One of the most effective things you can do to speed up this process is build multiple bundles - one for your application code and one for your dependencies. When your application code changes you only have to recompile that bundle, not all of your dependencies.</p>
|
||
|
||
<h2>On the command line</h2>
|
||
|
||
<p>If you&#39;re using the command line interface, creating an additional bundle is as easy as invoking <em>browserify</em> with the <em>--require</em> option. You don&#39;t have to point it at a source file, you can simply pass <em>-r my-module</em> for each module you want to include in the bundle. This will pull the requirement into the bundle and make that requirement available from outside the bundle with <code data-syntax="text-only">require(&#39;my-module&#39;)</code>.</p>
|
||
|
||
<pre class="highlight"><code data-syntax="text-only">$ browserify -r react -r q -r loglevel &gt; build/vendor.js</code></pre>
|
||
|
||
<p>If you include <em>vendor.js</em> from the example in your HTML, you can then <code data-syntax="text-only">require(&#39;react&#39;)</code> or <code data-syntax="text-only">require(&#39;q&#39;)</code> from anywhere. You may notice, however, that your application bundle is still pulling these requirements in, defeating the whole purpose. This brings us to the next command line option we need to use, <em>--external</em>. </p>
|
||
|
||
<p>The <em>--external</em> option tells browserify that the given module will be provided externally and doesn&#39;t need to be included in this bundle. When used with your application bundle, it will filter out the dependencies that you will be compiling into your vendor bundle.</p>
|
||
|
||
<pre class="highlight"><code data-syntax="text-only">$ browserify -x react -x q -x loglevel src/index.js &gt; build/app.js</code></pre>
|
||
|
||
<p>Make sure to include the <em>vendor.js</em> file <strong>before</strong> <em>app.js</em> in your HTML, so that the dependencies will be available when <em>app.js</em> is loaded.</p>
|
||
|
||
<h2>With Gulp</h2>
|
||
|
||
<p><a href="https://github.com/gulpjs/gulp">Gulp</a> has recently overtaken <a href="http://gruntjs.com/">Grunt</a> as our task manager of choice. We typically set Gulp up with our major tasks in a <em>gulp/</em> subfolder, and then we require each of those modules in our <em>gulpfile.js</em>:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="text-only">&#39;use strict&#39;;
|
||
var gulp = require(&#39;gulp&#39;);
|
||
|
||
require(&#39;./gulp/app&#39;);
|
||
require(&#39;./gulp/serve&#39;);
|
||
require(&#39;./gulp/vendor&#39;);
|
||
require(&#39;./gulp/watch&#39;);
|
||
|
||
gulp.task(&#39;build&#39;, [
|
||
&#39;app&#39;,
|
||
&#39;vendor&#39;,
|
||
]);
|
||
|
||
gulp.task(&#39;default&#39;, [&#39;build&#39;], function() {
|
||
return gulp.start(&#39;serve&#39;, &#39;watch&#39;);
|
||
});</code></pre>
|
||
|
||
<h3>The vendor bundle</h3>
|
||
|
||
<p>I&#39;ll start with our vendor bundle, and break it up to explain a few things.</p>
|
||
|
||
<pre class="highlight"><code data-syntax="text-only">&#39;use strict&#39;;
|
||
var browserify = require(&#39;gulp-browserify&#39;);
|
||
var gulp = require(&#39;gulp&#39;);
|
||
var rename = require(&#39;gulp-rename&#39;);
|
||
var uglify = require(&#39;gulp-uglify&#39;);
|
||
|
||
var libs = [
|
||
&#39;react&#39;,
|
||
&#39;react/lib/ReactCSSTransitionGroup&#39;,
|
||
&#39;react/lib/cx&#39;,
|
||
&#39;q&#39;,
|
||
&#39;underscore&#39;,
|
||
&#39;loglevel&#39;
|
||
];</code></pre>
|
||
|
||
<p>I assign an array of dependency names to a variable, because we&#39;ll be using this in a couple of places.</p>
|
||
|
||
<pre class="highlight"><code data-syntax="text-only">gulp.task(&#39;vendor&#39;, function() {
|
||
var production = (process.env.NODE_ENV === &#39;production&#39;);</code></pre>
|
||
|
||
<p>I&#39;m using the NODE_ENV environment variable to determine whether this is a production build or not.</p>
|
||
|
||
<pre class="highlight"><code data-syntax="text-only">// A dummy entry point for browserify
|
||
var stream = gulp.src(&#39;./gulp/noop.js&#39;, {read: false})</code></pre>
|
||
|
||
<p>Since Gulp is a file-based build system, it needs a file to open the stream with. We don&#39;t really need this on the vendor bundle, so my workaround is to point it to an empty file called <em>noop.js</em>.</p>
|
||
|
||
<pre class="highlight"><code data-syntax="text-only">// Browserify it
|
||
.pipe(browserify({
|
||
debug: false, // Don&#39;t provide source maps for vendor libs
|
||
}))
|
||
|
||
.on(&#39;prebundle&#39;, function(bundle) {
|
||
// Require vendor libraries and make them available outside the bundle.
|
||
libs.forEach(function(lib) {
|
||
bundle.require(lib);
|
||
});
|
||
});</code></pre>
|
||
|
||
<p>This is where the magic happens. The <a href="https://github.com/deepak1556/gulp-browserify">gulp-browserify</a> plugin doesn&#39;t have an option to handle the <em>--require</em> command, so I simply listen for the &quot;prebundle&quot; event that it sends, and interact with browserify&#39;s API directly. The <code data-syntax="text-only">bundle.require()</code> method is documented <a href="https://github.com/substack/node-browserify#brequirefile-opts">here</a>. I iterate over the list of dependencies, and call <code data-syntax="text-only">bundle.require()</code> for each one.</p>
|
||
|
||
<pre class="highlight"><code data-syntax="text-only">if (production) {
|
||
// If this is a production build, minify it
|
||
stream.pipe(uglify());
|
||
}
|
||
|
||
// Give the destination file a name, adding &#39;.min&#39; if this is production
|
||
stream.pipe(rename(&#39;vendor&#39; + (production ? &#39;.min&#39; : &#39;&#39;) + &#39;.js&#39;))
|
||
|
||
// Save to the build directory
|
||
.pipe(gulp.dest(&#39;build/&#39;));
|
||
|
||
return stream;
|
||
|
||
});
|
||
|
||
exports.libs = libs;</code></pre>
|
||
|
||
<p>The rest of the task is pretty basic. I minify it if this is a production build, give the bundle an appropriate name, and save it to the build directory. I assign the list of dependencies to <code data-syntax="text-only">exports.libs</code> so that it will be available to other modules, like our application bundle.</p>
|
||
|
||
<h3>The application bundle</h3>
|
||
|
||
<p>The application bundle follows a very similar pattern:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="text-only">&#39;use strict&#39;;
|
||
var browserify = require(&#39;gulp-browserify&#39;);
|
||
var gulp = require(&#39;gulp&#39;);
|
||
var libs = require(&#39;./vendor&#39;).libs;
|
||
var pkg = require(&#39;../package.json&#39;);
|
||
var rename = require(&#39;gulp-rename&#39;);
|
||
var uglify = require(&#39;gulp-uglify&#39;);</code></pre>
|
||
|
||
<p>I import the list of dependencies that I exported from the vendor bundle with <code data-syntax="text-only">require(&#39;./vendor&#39;).libs</code>.</p>
|
||
|
||
<pre class="highlight"><code data-syntax="text-only">gulp.task(&#39;app&#39;, function() {
|
||
var production = (process.env.NODE_ENV === &#39;production&#39;);
|
||
|
||
var stream = gulp.src(&#39;src/index.js&#39;, {read: false})
|
||
|
||
// Browserify it
|
||
.pipe(browserify({
|
||
debug: !production, // If not production, add source maps
|
||
transform: [&#39;reactify&#39;],
|
||
extensions: [&#39;.jsx&#39;]
|
||
}))</code></pre>
|
||
|
||
<p>I include some settings for browserify, including a transform and additional extension definition for working with &quot;.jsx&quot; modules from React.</p>
|
||
|
||
<pre class="highlight"><code data-syntax="text-only">.on(&#39;prebundle&#39;, function(bundle) {
|
||
// The following requirements are loaded from the vendor bundle
|
||
libs.forEach(function(lib) {
|
||
bundle.external(lib);
|
||
});
|
||
});</code></pre>
|
||
|
||
<p>Just as I did with the vendor bundle, I iterate over the list of dependencies. This time, however, I use <code data-syntax="text-only">bundle.external()</code>. It&#39;s documented (briefly) <a href="https://github.com/substack/node-browserify#bexternalfile">here</a>.</p>
|
||
|
||
<pre class="highlight"><code data-syntax="text-only">if (production) {
|
||
// If this is a production build, minify it
|
||
stream.pipe(uglify());
|
||
}
|
||
|
||
// Give the destination file a name, adding &#39;.min&#39; if this is production
|
||
stream.pipe(rename(pkg.name + (production ? &#39;.min&#39; : &#39;&#39;) + &#39;.js&#39;))
|
||
|
||
// Save to the build directory
|
||
.pipe(gulp.dest(&#39;build/&#39;));
|
||
|
||
return stream;
|
||
});</code></pre>
|
||
|
||
<p>The rest of the task is identical to the vendor bundle.</p>
|
||
|
||
<h3>Watching for changes</h3>
|
||
|
||
<p>Now, when something changes I can rebuild only the affected bundle. Here&#39;s an example of my <em>watch.js</em>:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="text-only">&#39;use strict&#39;;
|
||
var gulp = require(&#39;gulp&#39;);
|
||
var gutil = require(&#39;gulp-util&#39;);
|
||
var livereload = require(&#39;gulp-livereload&#39;);
|
||
|
||
gulp.task(&#39;watch&#39;, function() {
|
||
var reloadServer = livereload();
|
||
|
||
var app = gulp.watch(&#39;src/**/{*.js,*.jsx}&#39;);
|
||
app.on(&#39;change&#39;, function(event) {
|
||
gulp.start(&#39;app&#39;, function() {
|
||
gutil.log(gutil.colors.bgGreen(&#39;Reloading...&#39;));
|
||
reloadServer.changed(event.path);
|
||
});
|
||
});
|
||
|
||
var vendor = gulp.watch(&#39;node_modules/**/*.js&#39;);
|
||
vendor.on(&#39;change&#39;, function(event) {
|
||
gulp.start(&#39;vendor&#39;, function() {
|
||
gutil.log(gutil.colors.bgGreen(&#39;Reloading...&#39;));
|
||
reloadServer.changed(event.path);
|
||
});
|
||
});
|
||
|
||
gutil.log(gutil.colors.bgGreen(&#39;Watching for changes...&#39;));
|
||
});</code></pre>
|
||
|
||
<p>It&#39;s a little verbose, because I&#39;m using the &quot;change&quot; event in order to start the task and then trigger a liveReload as a callback. It works great, though! On one of our applications, the vendor bundle takes 5 or 6 seconds to compile, but the app bundle takes less than a second. This makes active development quite speedy!</p>
|
||
|
||
<h2>With Grunt</h2>
|
||
|
||
<p>For Grunt, we like the <em>load-grunt-config</em> plugin that loads configuration blocks from modules in a <em>grunt/</em> folder, similar to how we&#39;re handling Gulp above.</p>
|
||
|
||
<pre class="highlight"><code data-syntax="text-only">&#39;use strict&#39;;
|
||
module.exports = function(grunt) {
|
||
|
||
// Look for grunt config files in the &#39;grunt&#39; directory
|
||
require(&#39;load-grunt-config&#39;)(grunt);
|
||
|
||
grunt.registerTask(&#39;default&#39;, [
|
||
&#39;browserify:vendor&#39;,
|
||
&#39;browserify:app&#39;,
|
||
&#39;watch&#39;
|
||
]);
|
||
};</code></pre>
|
||
|
||
<h3>The browserify task</h3>
|
||
|
||
<p>Both the app and vendor bundles are configured inside the <em>browserify.js</em> task file:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="text-only">&#39;use strict&#39;;
|
||
|
||
module.exports = {
|
||
options: {
|
||
debug: true,
|
||
transform: [&#39;reactify&#39;],
|
||
extensions: [&#39;.jsx&#39;],
|
||
external: [
|
||
&#39;react&#39;,
|
||
&#39;react/lib/ReactCSSTransitionGroup&#39;,
|
||
&#39;react/lib/cx&#39;,
|
||
&#39;q&#39;,
|
||
&#39;underscore&#39;,
|
||
&#39;loglevel&#39;
|
||
]
|
||
},
|
||
app: {
|
||
files: {
|
||
&#39;build/app.js&#39;: [&#39;src/app.js&#39;]
|
||
}
|
||
},</code></pre>
|
||
|
||
<p>The app bundle uses the &quot;external&quot; config option from <a href="https://github.com/jmreidy/grunt-browserify">grunt-browserify</a>. I add the app bundle settings as the default, top-level options because I sometimes have more than one bundle that uses very similar settings. I don&#39;t add the dependencies to an array, because - as you&#39;ll see in the next step - I can&#39;t reuse the array.</p>
|
||
|
||
<p>Here&#39;s the configuration for the vendor bundle:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="text-only">vendor: {
|
||
// External modules that don&#39;t need to be constantly re-compiled
|
||
src: [&#39;.&#39;],
|
||
dest: &#39;build/vendor.js&#39;,
|
||
options: {
|
||
debug: false,
|
||
alias: [
|
||
&#39;react:&#39;,
|
||
&#39;react/lib/ReactCSSTransitionGroup:&#39;,
|
||
&#39;react/lib/cx:&#39;,
|
||
&#39;q:&#39;,
|
||
&#39;underscore:&#39;,
|
||
&#39;loglevel:&#39;
|
||
],
|
||
external: null // Reset this here because it&#39;s not needed
|
||
}
|
||
}
|
||
};</code></pre>
|
||
|
||
<p>The <code data-syntax="text-only">bundle.require()</code> API is exposed through <em>grunt-browserify</em>&#39;s &quot;alias&quot; configuration. The reason I can&#39;t reuse the array is because the plugin uses a colon to separate the module name from an optional alias (which corresponds to the &quot;expose&quot; property from browserify&#39;s <code data-syntax="text-only">bundle.require()</code> method).</p>
|
||
|
||
<h3>The watch task</h3>
|
||
|
||
<p>The watch task uses <a href="https://github.com/gruntjs/grunt-contrib-watch">grunt-contrib-watch</a>, and the configuration is quite simple:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="text-only">module.exports = {
|
||
options: {livereload: true},
|
||
app: {
|
||
files: [&#39;src/**/*.js&#39;, &#39;src/**/*.jsx&#39;],
|
||
tasks: [&#39;browserify:app&#39;]
|
||
},
|
||
test: {
|
||
files: [&#39;node_modules/**/*.js&#39;],
|
||
tasks: [&#39;browserify:vendor&#39;]
|
||
}
|
||
};</code></pre>
|
||
|
||
<p>Now you&#39;re ready to hack away, and your app bundle can be regenerated in a fraction of the time it took before!</p>
|
||
</description><pubDate>Tue, 08 Apr 2014 14:45:23 -0500</pubDate><guid>http://lincolnloop.com/blog/speedy-browserifying-multiple-bundles/</guid></item><item><title>Architecting Your App with React - Part 1</title><link>http://lincolnloop.com/blog/architecting-your-app-react-part-1/</link><description>
|
||
<p><strong>Please update to our new feed url: <a href="http://lincolnloop.com/blog/feed/">lincolnloop.com/blog/feed/</a></strong></p>
|
||
<hr/>
|
||
<p>In May of last year, Facebook released an open source library for building frontend components called <a href="http://facebook.github.io/react/">React</a>. It&#39;s built around some rather unorthodox philosophies about the browser and application structure, but over time it has gained quite a bit of steam as many developers see the advantages it offers. One of the most striking distinctives of React is the virtual DOM that it provides in order to minimize changes to the actual browser DOM and provide impressive rendering performance.</p>
|
||
|
||
<p>React is not a full MVC framework, and this is actually one of its strengths. Many who adopt React choose to do so alongside their favorite MVC framework, like Backbone. React has no opinions about routing or syncing data, so you can easily use your favorite tools to handle those aspects of your frontend application. You&#39;ll often see React used to manage specific parts of an application&#39;s UI and not others. React really shines, however, when you fully embrace its strategies and make it the core of your application&#39;s interface.</p>
|
||
|
||
<h2>Avoid the DOM wherever possible</h2>
|
||
|
||
<p>React provides a virtual DOM implemented entirely as JavaScript classes. This is so that you can make numerous updates to your applications element tree without actually incurring the overhead of browser DOM manipulations. With modern engines such as V8, JavaScript is extremely fast. So fast, in fact, that it&#39;s entirely possible for you to render your entire application every time your data changes, eliminating the need for you to manipulate elements in place or manage two-way binding. React will periodically diff the virtual DOM against the browser DOM, and make the minimal set of changes needed to bring the browser DOM into sync.</p>
|
||
|
||
<h2>One-way data flow</h2>
|
||
|
||
<p>When the cost of rendering is so dramatically reduced, you are now free to take a much more declarative approach to managing your interface. Instead of implementing complex manipulations to update your elements in place and keep multiple sources of state in sync as data changes, you can keep your state in one place and describe your interface based on that. As things change, your component reacts by re-rendering.</p>
|
||
|
||
<p>When your whole application is build around this, you can pass immutable data from the top level down to various child components and then re-render your whole application from the top down when anything changes. It changes how you think about your application and often ends up simplifying things a great deal.</p>
|
||
|
||
<h2>The browser as a rendering engine</h2>
|
||
|
||
<p>This is a pretty radical departure from the strategy of most frontend MVC frameworks, which strive to reduce re-rendering as much as possible by automatically manipulating data in place with two-way binding. When I first started looking into React, I wasn&#39;t convinced. The turning point for me was when I watched a video where <a href="https://www.youtube.com/watch?v=DgVS-zXgMTk#t=1432">Pete Hunt compared React to the Doom 3 rendering engine</a>.</p>
|
||
|
||
<p><img src="https://lincolnloop.com/uploads/uploads/Screen_Shot_2014-01-27_at_9.14.01_AM.png" alt="The Doom 3 rendering engine"></p>
|
||
|
||
<p>In the diagram, the game state is fed into a &quot;frontend&quot; layer of logic and abstraction over the lower-level graphics code. This leads to the creation of a &quot;scene intermediate representation&quot; which describes what the user should see. This is given to the &quot;backend&quot;, which takes that representation and turns it into OpenGL operations, which renders the scene with the graphics card. React works in a very similar way.</p>
|
||
|
||
<p><img src="https://lincolnloop.com/uploads/uploads/Screen_Shot_2014-01-27_at_9.14.21_AM.png" alt="React compared to Doom 3"></p>
|
||
|
||
<p>When something changes in the application state due to browser or realtime events, your application takes that state and passes it down to your components to create an intermediate representation of your user interface using the virtual DOM. No actual changes are made to the browser DOM right away, however. React periodically takes the virtual DOM and calculates the DOM operations needed, similar to how the game engine takes the scene IR and determines what OpenGL operations are needed. The browser takes the DOM and renders it to the screen.</p>
|
||
|
||
<p>In both the browser and game engine, the slow part is actually rendering the intermediate representation to the screen. You can make many small changes to the virtual DOM very quickly. React optimizes the part that matters, so you don&#39;t have to sacrifice performance for code quality.</p>
|
||
|
||
<h2>More resources</h2>
|
||
|
||
<p>In Part 2, I&#39;ll demonstrate how we use React to put these philosophies into practice. I&#39;ll share how we set up a top-level application component that renders an interface composed of smaller components with different responsibilities, and I&#39;ll describe how we integrate routing and data syncing into this structure.</p>
|
||
|
||
<p>In the meantime, take a look at the resources below if you would like to know more about React and how it works.</p>
|
||
|
||
<ul>
|
||
<li><a href="http://facebook.github.io/react/">The React homepage</a></li>
|
||
<li><a href="http://facebook.github.io/react/docs/videos.html">Videos</a></li>
|
||
<li><a href="http://facebook.github.io/react/docs/examples.html">Examples</a></li>
|
||
<li><a href="https://groups.google.com/forum/#!forum/reactjs">The React Google Group</a></li>
|
||
<li><a href="irc://chat.freenode.net/reactjs">#reactjs on Freenode</a> - the official IRC channel, which is quite active.</li>
|
||
</ul>
|
||
</description><pubDate>Tue, 11 Mar 2014 07:46:09 -0500</pubDate><guid>http://lincolnloop.com/blog/architecting-your-app-react-part-1/</guid></item><item><title>Untangle Your JavaScript with Browserify</title><link>http://lincolnloop.com/blog/untangle-your-javascript-browserify/</link><description>
|
||
<p><strong>Please update to our new feed url: <a href="http://lincolnloop.com/blog/feed/">lincolnloop.com/blog/feed/</a></strong></p>
|
||
<hr/>
|
||
<p>We&#39;ve all been there. You&#39;re working on an project with a lot of JavaScript, and you need to add a new widget that depends on some libraries. You have a complex template structure and you don&#39;t know which libraries have been added as &lt;script&gt; tags already, or where they might be. You can&#39;t just add them to the template you&#39;re working on, because that would add redundant HTTP requests. Furthermore, you might end up overwriting a library that had plugins added to it, breaking other widgets that relied on those plugins. So, you end up putting all your &lt;script&gt; tags in your base template in a monolithic block and making sure you have them listed in the correct order.</p>
|
||
|
||
<p>Some time later, you realize you need to clean up your script block, but you have no idea which ones are still being used and which aren&#39;t. You remove some tags you think are unneeded and the site seems fine when you click around, but later you get a bug report about a broken widget that was actually using that library. </p>
|
||
|
||
<h2>It doesn&#39;t have to be this way</h2>
|
||
|
||
<p>As we do increasingly amazing things with the web, the size and complexity of our JavaScript code has exploded! In many cases we&#39;re not building &quot;sites&quot; any more, we are truly building &quot;apps&quot; - highly interactive and responsive tools that look less and less like the hyperlinked pages of the original web. To move forward in this environment it&#39;s vital to keep your code clean, well structured, and maintainable.</p>
|
||
|
||
<p>It&#39;s time to embrace modularity in our client-side code. Instead of writing tightly integrated code that depends on everything being in the global scope, we should strive to create decoupled, discrete components that clearly define their dependencies and the functionality that they export. There are many tools to help with this, but two of the most popular are <a href="http://browserify.org/">Browserify</a> and <a href="http://requirejs.org/">RequireJS</a>.</p>
|
||
|
||
<h2>Browserify and transforms</h2>
|
||
|
||
<p>Though we used RequireJS briefly, in the end we chose Browserify for its simplicity, easy extension through transforms, and its focus on npm and the Node.js module system. It is an astoundingly flexible system that implements a &quot;require&quot; function on the browser and cleanly encapsulates modules so that they don&#39;t pollute the global scope.</p>
|
||
|
||
<p>Transforms allow Browserify to become incredibly versatile. You can consume AMD packages with <a href="https://github.com/jaredhanson/deamdify">deAMDify</a>, or use <a href="https://github.com/thlorenz/browserify-shim">browserify-shim</a> to consume libraries that attach themselves to the window. You can take advantage of alternate package management systems, like Bower with <a href="https://github.com/eugeneware/debowerify">debowerify</a> or Component with <a href="https://github.com/eugeneware/decomponentify">decomponentify</a>. You can smoothly handle code that needs to be precompiled, like <a href="https://github.com/jnordberg/coffeeify">CoffeeScript</a> and <a href="https://github.com/andreypopp/reactify">JSX</a>. You can even precompile things like <a href="https://github.com/epeli/node-hbsfy">Handlebars templates</a> so that you can &quot;require&quot; them in your modules.</p>
|
||
|
||
<h2>Let&#39;s get to work!</h2>
|
||
|
||
<p>So, enough talk about <em>why</em>. Let&#39;s move on to <em>how</em>! Browserify is built with Node.js, so you will need to <a href="https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager">have it installed</a> on your system. To take your first steps with Browserify, you&#39;ll probably want to install it globally so that you can use it as a command-line script.</p>
|
||
|
||
<pre class="highlight"><code data-syntax="text-only">$ npm install -g browserify</code></pre>
|
||
|
||
<h2>Writing modules</h2>
|
||
|
||
<p>Now, let&#39;s write a simple module that requires something:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="javascript"><span class="s1">&#39;use strict&#39;</span><span class="p">;</span>
|
||
|
||
<span class="kd">var</span> <span class="nx">_</span> <span class="o">=</span> <span class="nx">require</span><span class="p">(</span><span class="s1">&#39;underscore&#39;</span><span class="p">);</span>
|
||
|
||
<span class="kd">var</span> <span class="nx">logUnderscoreVersion</span> <span class="o">=</span> <span class="kd">function</span><span class="p">()</span> <span class="p">{</span>
|
||
<span class="nx">console</span><span class="p">.</span><span class="nx">log</span><span class="p">(</span><span class="nx">_</span><span class="p">.</span><span class="nx">VERSION</span><span class="p">);</span>
|
||
<span class="p">}</span>
|
||
|
||
<span class="nx">module</span><span class="p">.</span><span class="nx">exports</span> <span class="o">=</span> <span class="nx">logUnderscoreVersion</span><span class="p">;</span></code></pre>
|
||
|
||
<p>There are a few things you&#39;ll notice here. First, some of you will immediately point out that I&#39;m using <code data-syntax="text-only">&#39;use strict&#39;</code> outside of a function, and chastise me because that will apply strict mode to the entire global scope and break all the things! Thankfully, that&#39;s not the case here. Browserify encapsulates every module in it&#39;s own scope, so strict mode will only apply to the current module.</p>
|
||
|
||
<p>To use the Underscore library, I&#39;m calling &quot;require&quot; and assigning it to the familiar &quot;_&quot; variable. At the moment, however, this will fail because we haven&#39;t installed it yet. Remedy this with npm:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="text-only">$ npm install underscore</code></pre>
|
||
|
||
<p>By calling the &quot;install&quot; command without the &quot;-g&quot; flag, you&#39;re telling npm to install your dependency in the local &quot;node_modules&quot; folder, which it will create for you if needed. Browserify will use that folder to find Underscore and make it available to your module.</p>
|
||
|
||
<p>Finally, at the end of the module I&#39;m &quot;exporting&quot; the function that I defined. This means that I am making that function available outside of my module. When another module requires my module, the result will be whatever I assigned to &quot;module.exports&quot;. This is how Node.js modules work. Anything I don&#39;t export stays private to my module.</p>
|
||
|
||
<h2>Building a bundle</h2>
|
||
|
||
<p>Now, let&#39;s use the command-line script to build a bundle for the browser. This will include all the required modules in one file. If you saved your module above as &quot;logunderscore.js&quot;, browserify it like this:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="text-only">$ browserify logunderscore.js &gt; bundle.js</code></pre>
|
||
|
||
<p>Now you can include bundle.js in an HTML file using a single script tag, and you&#39;re ready to use your JavaScript! Code that is outside of a function will be executed immediately, so a common pattern is to use a &quot;main.js&quot; or an &quot;index.js&quot; as an entry point that requires whatever you need to initialize your app and kicks it off immediately.</p>
|
||
|
||
<h2>Requiring your own modules</h2>
|
||
|
||
<p>When you need to require one of your own modules, use the relative path. You don&#39;t need to add the &quot;.js&quot; at the end of the path.</p>
|
||
|
||
<pre class="highlight"><code data-syntax="javascript"><span class="kd">var</span> <span class="nx">logUnderscoreVersion</span> <span class="o">=</span> <span class="nx">require</span><span class="p">(</span><span class="s1">&#39;./logunderscore&#39;</span><span class="p">);</span>
|
||
<span class="nx">logUnderscoreVersion</span><span class="p">();</span></code></pre>
|
||
|
||
<h2>Exporting multiple things</h2>
|
||
|
||
<p>If you need to export multiple functions or objects, you can use the &quot;exports&quot; shortcut from Node.js.</p>
|
||
|
||
<pre class="highlight"><code data-syntax="javascript"><span class="s1">&#39;use strict&#39;</span><span class="p">;</span>
|
||
|
||
<span class="kd">var</span> <span class="nx">logDate</span> <span class="o">=</span> <span class="kd">function</span><span class="p">()</span> <span class="p">{</span>
|
||
<span class="nx">console</span><span class="p">.</span><span class="nx">log</span><span class="p">(</span><span class="k">new</span> <span class="nb">Date</span><span class="p">().</span><span class="nx">getDate</span><span class="p">());</span>
|
||
<span class="p">}</span>
|
||
|
||
<span class="kd">var</span> <span class="nx">logMonth</span><span class="p">()</span> <span class="p">{</span>
|
||
<span class="nx">console</span><span class="p">.</span><span class="nx">log</span><span class="p">(</span><span class="k">new</span> <span class="nb">Date</span><span class="p">().</span><span class="nx">getMonth</span><span class="p">());</span>
|
||
<span class="p">}</span>
|
||
|
||
<span class="nx">exports</span><span class="p">.</span><span class="nx">logDate</span> <span class="o">=</span> <span class="nx">logDate</span><span class="p">;</span>
|
||
<span class="nx">exports</span><span class="p">.</span><span class="nx">logMonth</span> <span class="o">=</span> <span class="nx">logMonth</span><span class="p">;</span></code></pre>
|
||
|
||
<p>Then, you can use it like this:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="javascript"><span class="kd">var</span> <span class="nx">dateUtils</span> <span class="o">=</span> <span class="nx">require</span><span class="p">(</span><span class="s1">&#39;./dateutils&#39;</span><span class="p">);</span>
|
||
<span class="nx">dateUtils</span><span class="p">.</span><span class="nx">logDate</span><span class="p">();</span>
|
||
<span class="nx">dateUtils</span><span class="p">.</span><span class="nx">logMonth</span><span class="p">();</span></code></pre>
|
||
|
||
<p>Or like this:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="javascript"><span class="kd">var</span> <span class="nx">logDate</span> <span class="o">=</span> <span class="nx">require</span><span class="p">(</span><span class="s1">&#39;./dateutils&#39;</span><span class="p">).</span><span class="nx">logDate</span><span class="p">;</span>
|
||
<span class="nx">logDate</span><span class="p">();</span></code></pre>
|
||
|
||
<h2>Integrating Browserify with build tools</h2>
|
||
|
||
<p>Once you&#39;re comfortable with Browserify, you&#39;ll probably want to integrate it with your favorite build tool. </p>
|
||
|
||
<h3>Browserify and Grunt</h3>
|
||
|
||
<p>In Grunt, you&#39;ll use <a href="https://github.com/jmreidy/grunt-browserify">grunt-browserify</a>. Here&#39;s a config snippet that builds the bundle, and then watches for changes:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="javascript"><span class="s1">&#39;browserify&#39;</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">options</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">debug</span><span class="o">:</span> <span class="kc">true</span><span class="p">,</span>
|
||
<span class="nx">transform</span><span class="o">:</span> <span class="p">[</span><span class="s1">&#39;reactify&#39;</span><span class="p">],</span>
|
||
<span class="nx">extensions</span><span class="o">:</span> <span class="p">[</span><span class="s1">&#39;.jsx&#39;</span><span class="p">],</span>
|
||
<span class="p">},</span>
|
||
<span class="nx">dev</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">options</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">alias</span><span class="o">:</span> <span class="p">[</span><span class="s1">&#39;react:&#39;</span><span class="p">]</span> <span class="c1">// Make React available externally for dev tools</span>
|
||
<span class="p">},</span>
|
||
<span class="nx">src</span><span class="o">:</span> <span class="p">[</span><span class="s1">&#39;client/index.js&#39;</span><span class="p">],</span>
|
||
<span class="nx">dest</span><span class="o">:</span> <span class="s1">&#39;build/bundle.js&#39;</span>
|
||
<span class="p">},</span>
|
||
<span class="nx">production</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">options</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">debug</span><span class="o">:</span> <span class="kc">false</span>
|
||
<span class="p">},</span>
|
||
<span class="nx">src</span><span class="o">:</span> <span class="s1">&#39;&lt;%= browserify.dev.src %&gt;&#39;</span><span class="p">,</span>
|
||
<span class="nx">dest</span><span class="o">:</span> <span class="s1">&#39;build/bundle.js&#39;</span>
|
||
<span class="p">}</span>
|
||
<span class="p">},</span></code></pre>
|
||
|
||
<p>This config takes advantage of several features, some of which I haven&#39;t mentioned yet. It&#39;s using the <a href="https://github.com/andreypopp/reactify">reactify</a> transform to precompile JSX files for use with <a href="http://facebook.github.io/react/">React</a>. It instructs browserify to look for &quot;.jsx&quot; extensions so that you don&#39;t have to include them in your require path. It sets the debug flag so that Browserify will generate source maps for effective debugging in development, but overrides that flag in the production target to keep the build lean.</p>
|
||
|
||
<p>The &quot;alias&quot; option makes a reqirement available through a global &quot;require&quot; function. This allows you to work with multiple bundles, if you&#39;d like. Here, though, it&#39;s being done so that the React dev tools extension can find React and enable a tab in Chrome. The &quot;alias&quot; setting in the Grunt plugin uses the <code data-syntax="text-only">bundle.require()</code> method from Browserify&#39;s API, which is also available with the &quot;-r&quot; flag on the command-line script.</p>
|
||
|
||
<h3>Browserify and Gulp</h3>
|
||
|
||
<p>The <a href="https://github.com/deepak1556/gulp-browserify">gulp-browserify</a> plugin is currently a bit more minimal than its Grunt counterpart, but you can still do everything that you&#39;d like to do by listening for the &quot;prebundle&quot; event and interacting with the bundler API directly.</p>
|
||
|
||
<pre class="highlight"><code data-syntax="javascript"><span class="kd">var</span> <span class="nx">browserify</span> <span class="o">=</span> <span class="nx">require</span><span class="p">(</span><span class="s1">&#39;gulp-browserify&#39;</span><span class="p">);</span>
|
||
<span class="kd">var</span> <span class="nx">gulp</span> <span class="o">=</span> <span class="nx">require</span><span class="p">(</span><span class="s1">&#39;gulp&#39;</span><span class="p">);</span>
|
||
<span class="kd">var</span> <span class="nx">gutil</span> <span class="o">=</span> <span class="nx">require</span><span class="p">(</span><span class="s1">&#39;gulp-util&#39;</span><span class="p">);</span>
|
||
<span class="kd">var</span> <span class="nx">rename</span> <span class="o">=</span> <span class="nx">require</span><span class="p">(</span><span class="s1">&#39;gulp-rename&#39;</span><span class="p">);</span>
|
||
|
||
|
||
<span class="nx">gulp</span><span class="p">.</span><span class="nx">task</span><span class="p">(</span><span class="s1">&#39;browserify&#39;</span><span class="p">,</span> <span class="kd">function</span><span class="p">()</span> <span class="p">{</span>
|
||
<span class="kd">var</span> <span class="nx">production</span> <span class="o">=</span> <span class="nx">gutil</span><span class="p">.</span><span class="nx">env</span><span class="p">.</span><span class="nx">type</span> <span class="o">===</span> <span class="s1">&#39;production&#39;</span><span class="p">;</span>
|
||
|
||
<span class="nx">gulp</span><span class="p">.</span><span class="nx">src</span><span class="p">([</span><span class="s1">&#39;index.js&#39;</span><span class="p">],</span> <span class="p">{</span><span class="nx">read</span><span class="o">:</span> <span class="kc">false</span><span class="p">})</span>
|
||
|
||
<span class="c1">// Browserify, and add source maps if this isn&#39;t a production build</span>
|
||
<span class="p">.</span><span class="nx">pipe</span><span class="p">(</span><span class="nx">browserify</span><span class="p">({</span>
|
||
<span class="nx">debug</span><span class="o">:</span> <span class="o">!</span><span class="nx">production</span><span class="p">,</span>
|
||
<span class="nx">transform</span><span class="o">:</span> <span class="p">[</span><span class="s1">&#39;reactify&#39;</span><span class="p">],</span>
|
||
<span class="nx">extensions</span><span class="o">:</span> <span class="p">[</span><span class="s1">&#39;.jsx&#39;</span><span class="p">]</span>
|
||
<span class="p">}))</span>
|
||
|
||
<span class="p">.</span><span class="nx">on</span><span class="p">(</span><span class="s1">&#39;prebundle&#39;</span><span class="p">,</span> <span class="kd">function</span><span class="p">(</span><span class="nx">bundler</span><span class="p">)</span> <span class="p">{</span>
|
||
<span class="c1">// Make React available externally for dev tools</span>
|
||
<span class="nx">bundler</span><span class="p">.</span><span class="nx">require</span><span class="p">(</span><span class="s1">&#39;react&#39;</span><span class="p">);</span>
|
||
<span class="p">})</span>
|
||
|
||
<span class="c1">// Rename the destination file</span>
|
||
<span class="p">.</span><span class="nx">pipe</span><span class="p">(</span><span class="nx">rename</span><span class="p">(</span><span class="s1">&#39;bundle.js&#39;</span><span class="p">))</span>
|
||
|
||
<span class="c1">// Output to the build directory</span>
|
||
<span class="p">.</span><span class="nx">pipe</span><span class="p">(</span><span class="nx">gulp</span><span class="p">.</span><span class="nx">dest</span><span class="p">(</span><span class="s1">&#39;build/&#39;</span><span class="p">));</span>
|
||
<span class="p">});</span></code></pre>
|
||
|
||
<h2>You, too, can Browserify today!</h2>
|
||
|
||
<p>Hopefully this guide has illustrated the usefulness of Browserify and helped you get it up and running yourself. If you&#39;ve got questions or comments, let me know below or find me on Twitter <a href="https://twitter.com/bkonkle">@bkonkle</a>. Happy coding!</p>
|
||
</description><pubDate>Mon, 03 Mar 2014 13:10:59 -0600</pubDate><guid>http://lincolnloop.com/blog/untangle-your-javascript-browserify/</guid></item><item><title>Varnish Saint Mode</title><link>http://lincolnloop.com/blog/varnish-saint-mode/</link><description>
|
||
<p><strong>Please update to our new feed url: <a href="http://lincolnloop.com/blog/feed/">lincolnloop.com/blog/feed/</a></strong></p>
|
||
<hr/>
|
||
<p>Varnish <strong>Saint Mode</strong> is a lesser known gem inside <a href="https://www.varnish-cache.org/docs/3.0/">varnish</a> that lets you serve stale content from cache, even when your backend servers are unavailable.</p>
|
||
|
||
<p>This article explains how to configure varnish to take advantage of this feature. If you want to follow along, create a directory and add an <code data-syntax="text-only">index.html</code>. I am going to use a poor man&#39;s Python web server <code data-syntax="text-only">python -m SimpleHTTPServer</code> to serve this directory.</p>
|
||
|
||
<p>Here is a simple Varnish config to take advantage of this feature:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="perl"><span class="c1"># /etc/varnish/default.vcl</span>
|
||
|
||
<span class="n">backend</span> <span class="n">default</span> <span class="p">{</span>
|
||
<span class="o">.</span><span class="n">host</span> <span class="o">=</span> <span class="s">&quot;127.0.0.1&quot;</span><span class="p">;</span>
|
||
<span class="o">.</span><span class="n">port</span> <span class="o">=</span> <span class="s">&quot;8000&quot;</span><span class="p">;</span>
|
||
<span class="o">.</span><span class="n">saintmode_threshold</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
|
||
<span class="o">.</span><span class="n">probe</span> <span class="o">=</span> <span class="p">{</span> <span class="o">.</span><span class="n">url</span> <span class="o">=</span> <span class="s">&quot;/&quot;</span><span class="p">;</span> <span class="o">.</span><span class="n">interval</span> <span class="o">=</span> <span class="mi">1</span><span class="n">s</span><span class="p">;</span> <span class="o">.</span><span class="n">timeout</span> <span class="o">=</span> <span class="mi">1</span><span class="n">s</span><span class="p">;</span>
|
||
<span class="o">.</span><span class="n">window</span> <span class="o">=</span> <span class="mi">5</span><span class="p">;</span> <span class="o">.</span><span class="n">threshold</span> <span class="o">=</span> <span class="mi">3</span><span class="p">;}</span>
|
||
<span class="p">}</span>
|
||
|
||
<span class="k">sub </span><span class="nf">vcl_recv</span> <span class="p">{</span>
|
||
<span class="k">if</span> <span class="p">(</span><span class="n">req</span><span class="o">.</span><span class="n">backend</span><span class="o">.</span><span class="n">healthy</span><span class="p">)</span> <span class="p">{</span>
|
||
<span class="n">set</span> <span class="n">req</span><span class="o">.</span><span class="n">grace</span> <span class="o">=</span> <span class="mi">1</span><span class="n">h</span><span class="p">;</span>
|
||
<span class="n">set</span> <span class="n">req</span><span class="o">.</span><span class="n">ttl</span> <span class="o">=</span> <span class="mi">5</span><span class="n">s</span><span class="p">;</span>
|
||
<span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
|
||
<span class="c1"># Accept serving stale object (extend TTL by 6h)</span>
|
||
<span class="n">set</span> <span class="n">req</span><span class="o">.</span><span class="n">grace</span> <span class="o">=</span> <span class="mi">6</span><span class="n">h</span><span class="p">;</span>
|
||
<span class="p">}</span>
|
||
<span class="p">}</span>
|
||
|
||
<span class="k">sub </span><span class="nf">vcl_fetch</span> <span class="p">{</span>
|
||
<span class="c1"># keep all objects for 6h beyond their TTL</span>
|
||
<span class="n">set</span> <span class="n">beresp</span><span class="o">.</span><span class="n">grace</span> <span class="o">=</span> <span class="mi">6</span><span class="n">h</span><span class="p">;</span>
|
||
|
||
<span class="c1"># If we fetch a 500, serve stale content instead</span>
|
||
<span class="k">if</span> <span class="p">(</span><span class="n">beresp</span><span class="o">.</span><span class="n">status</span> <span class="o">==</span> <span class="mi">500</span> <span class="o">||</span> <span class="n">beresp</span><span class="o">.</span><span class="n">status</span> <span class="o">==</span> <span class="mi">502</span> <span class="o">||</span> <span class="n">beresp</span><span class="o">.</span><span class="n">status</span> <span class="o">==</span> <span class="mi">503</span><span class="p">)</span> <span class="p">{</span>
|
||
<span class="n">set</span> <span class="n">beresp</span><span class="o">.</span><span class="n">saintmode</span> <span class="o">=</span> <span class="mi">30</span><span class="n">s</span><span class="p">;</span>
|
||
<span class="k">return</span><span class="p">(</span><span class="n">restart</span><span class="p">);</span>
|
||
<span class="p">}</span>
|
||
<span class="p">}</span></code></pre>
|
||
|
||
<p>The following scenario will let you test the saint mode:</p>
|
||
|
||
<ul>
|
||
<li>Kick-off the Python web server in the directory you created with <code data-syntax="text-only">python -m SimpleHTTPServer</code>. <em>Note: Every 1s varnish is going to probe your backend to determine if it is healthy.</em></li>
|
||
</ul>
|
||
|
||
<pre class="highlight"><code data-syntax="text-only">Serving HTTP on 0.0.0.0 port 8000 ...
|
||
127.0.0.1 - - [17/Feb/2014 11:51:02] &quot;GET / HTTP/1.1&quot; 200 -
|
||
127.0.0.1 - - [17/Feb/2014 11:51:02] &quot;GET / HTTP/1.1&quot; 200 -</code></pre>
|
||
|
||
<ul>
|
||
<li>Fetch the <code data-syntax="text-only">index.html</code> you created earlier through Varnish</li>
|
||
</ul>
|
||
|
||
<pre class="highlight"><code data-syntax="bash"><span class="nv">$ </span>curl -I http://127.0.0.1:6081
|
||
HTTP/1.1 200 OK
|
||
Server: SimpleHTTP/0.6 Python/2.7.5+
|
||
Content-type: text/html
|
||
Last-Modified: Mon, 17 Feb 2014 10:19:03 GMT
|
||
Content-Length: 146
|
||
Accept-Ranges: bytes
|
||
Date: Mon, 17 Feb 2014 10:53:07 GMT
|
||
X-Varnish: 976346109
|
||
Age: 0
|
||
Via: 1.1 varnish
|
||
Connection: keep-alive</code></pre>
|
||
|
||
<ul>
|
||
<li>Now kill the Python web server process and confirm it is down</li>
|
||
</ul>
|
||
|
||
<pre class="highlight"><code data-syntax="bash"><span class="nv">$ </span>curl -I http://127.0.0.1:8000
|
||
curl: <span class="o">(</span>7<span class="o">)</span> Failed connect to 127.0.0.1:8000; Connection refused</code></pre>
|
||
|
||
<ul>
|
||
<li>Fetch <code data-syntax="text-only">index.html</code> through Varnish again</li>
|
||
</ul>
|
||
|
||
<pre class="highlight"><code data-syntax="bash"><span class="nv">$ </span>curl -I http://127.0.0.1:6081
|
||
HTTP/1.1 200 OK
|
||
Server: SimpleHTTP/0.6 Python/2.7.5+
|
||
Content-type: text/html
|
||
Last-Modified: Mon, 17 Feb 2014 10:19:03 GMT
|
||
Content-Length: 146
|
||
Accept-Ranges: bytes
|
||
Date: Mon, 17 Feb 2014 10:55:14 GMT
|
||
X-Varnish: 976346113 976346109
|
||
Age: 127
|
||
Via: 1.1 varnish
|
||
Connection: keep-alive</code></pre>
|
||
|
||
<p>Note the <code data-syntax="text-only">Age: 127</code> header. This tells you the number of seconds since Varnish fetched this page from your web server.</p>
|
||
|
||
<p>Congratulations, you&#39;re now serving pages without your webserver! Varnish&#39;s saint mode can be a nice safety net when the unexpected (but inevitable) happens and buy you some time to get things back into working order.</p>
|
||
</description><pubDate>Thu, 20 Feb 2014 03:00:39 -0600</pubDate><guid>http://lincolnloop.com/blog/varnish-saint-mode/</guid></item><item><title>Lessons Learned Architecting Realtime Applications</title><link>http://lincolnloop.com/blog/architecting-realtime-applications/</link><description>
|
||
<p><strong>Please update to our new feed url: <a href="http://lincolnloop.com/blog/feed/">lincolnloop.com/blog/feed/</a></strong></p>
|
||
<hr/>
|
||
<p>Building realtime applications is a big change from how we&#39;ve built websites in the past. Typically, realtime websites require each client holding open a long-running connection to the server so updates can be pushed down to the client immediately. This is in stark contrast to traditional websites where the aim of the server is to serve a page and quickly free up the connection for the next request. Taking a server or application that is optimized for short-lived connections and slapping on a realtime component simply doesn&#39;t work (for reasons I&#39;ll explain below).</p>
|
||
|
||
<p>We built and maintain two real world realtime websites, our IRC logger, <a href="https://botbot.me">BotBot.me</a> and our team discussion tool, <a href="https://gingerhq.com">Ginger</a>. We intentionally took two very different approaches in building them. The first site, Ginger, was built using a two-process approach. One process handles all of the long-running connections while another serves the API and pages that require server-generated HTML. BotBot.me, on the other hand, does everything using one Django process. After having them both in production for a while, we&#39;ve learned a few things about what works and what doesn&#39;t.</p>
|
||
|
||
<h2>The Single Server Approach</h2>
|
||
|
||
<p>I&#39;ll start with the simpler approach. BotBot.me&#39;s realtime connections are handled from the same process which generates the server-side HTML pages. We&#39;re using Server Sent Events via <a href="https://github.com/niwibe/django-sse">django-sse</a>. SSE is a standardized approach to long-polling and part of the HTML5 spec. Native support in browsers is very good and unsupported browsers can use it via a JavaScript polyfill. Coupled with XHR, SSE gives you a realtime bi-directional communication channel without having to mess with websockets. There are a number reasons why you might <em>not</em> want to use websockets (see notes below).</p>
|
||
|
||
<p>This setup is beautiful because it makes development simple. Only one process to start-up and only one code-base to maintain. You start running into problems, however, when you try to take this app from toy code on your laptop to production-ready. If you&#39;re thinking about taking this approach, here&#39;s a few issues you&#39;ll encounter.</p>
|
||
|
||
<h3>You&#39;re Going to Run out of Workers</h3>
|
||
|
||
<p>A common way to serve dynamic applications is with Nginx proxying to a few workers (WSGI, Rack, etc) serving your application. Common practice is to only run 4-8 workers behind the proxy. Those workers are often capable of serving a surprising number of requests because they are constantly being freed up and re-used. That all changes when you introduce long-running connections. Now you can handle 4-8 clients using your app at any given time. Not exactly a high-traffic setup.</p>
|
||
|
||
<p>&quot;No problem&quot; you might say, &quot;I&#39;ll use &lt;insert async framework here&gt;!&quot;. Something like Gevent or EventMachine will let you serve more requests with that handful of workers, but introduces new problems.</p>
|
||
|
||
<h3>You&#39;re Going to Run out of Database Connections</h3>
|
||
|
||
<p>You&#39;ve now blown past 4-8 clients and, because most of these connections just sit idle, you can now handle more than 100 at any given time. Is your app ready for that though? Can your database handle 100 simultaneous connections? Probably not. Now you need to setup a database connection pool. Hopefully you&#39;ve done that before. If not maybe you can pull one off of PyPI that works (we&#39;ve had good luck with <a href="https://pypi.python.org/pypi/django-db-geventpool">django-db-geventpool</a>).</p>
|
||
|
||
<h3>Going Async isn&#39;t Free</h3>
|
||
|
||
<p>In Python, switching to gevent is a pip install and gunicorn flag away. It seems so simple on the surface. But wait, our database driver, <a href="http://initd.org/psycopg/docs/advanced.html#support-for-coroutine-libraries">psycopg2, isn&#39;t green thread-safe</a>. If you want to reuse connections, now you need to add <a href="https://pypi.python.org/pypi/psycogreen/1.0">psycogreen</a> into your stack and make sure it does its monkey-patching early on. Are you sure the rest of your stack works seamlessly with gevent? By going async, you&#39;ve also made debugging considerably more difficult. I think everybody I&#39;ve met with real world gevent experience has a war story about trying to solve some strange deadlock or traceback being swallowed somewhere in the stack.</p>
|
||
|
||
<h3>Your Processes Need to Know the Difference</h3>
|
||
|
||
<p>On a traditional web server, you want to kill connections that don&#39;t finish within a certain amount of time. This keeps your worker pool available to respond to other requests and protects you from <a href="http://en.wikipedia.org/wiki/Slowloris">Slowloris</a> attacks. Your realtime connections are exactly the opposite. They need to be held open indefinitely. If they drop, they should be re-opened immediately. This means, even though your code is all in the same package, you need to manage different configurations in Nginx and possibly in your application server as well to make sure they are served to clients correctly.</p>
|
||
|
||
<h3>You&#39;re Putting a Square Peg in a Round Hole</h3>
|
||
|
||
<p>There are lots of great ways to handle many concurrent long-running connections. Node.js and Go were built from the ground-up with this scenario in mind. In the Python world, we have Tornado, Twisted, and others that are much better suited for this role. Django, Rails, and other traditional web frameworks weren&#39;t built for this type of workload. While it may seem like the easy route at first, it tends to make your life harder later.</p>
|
||
|
||
<p>How about the alternative?</p>
|
||
|
||
<h2>A Separate Realtime Process</h2>
|
||
|
||
<p>The approach we took with Ginger separates concerns. Traditional web requests are routed to our Django server while long-running realtime connections are routed to a small Node.js script which holds those connections open. They communicate over a Redis pub/sub channel. This approach is great because it solves most of the issues presented in the single-process approach. Our realtime endpoint is optimized to handle lots of long connections, it doesn&#39;t need to talk to the main database, and it uses software designed to make this sort of stuff easy. Unfortunately, it too has a few issues.</p>
|
||
|
||
<h3>You Need to Do More Work Upfront</h3>
|
||
|
||
<p>If you&#39;re just building a toy app for yourself, this is going to be overkill. Splitting the components up requires a little more thought and planning upfront. It also means getting your development environment up-and-running is more of a hassle. Tools like <a href="http://ddollar.github.io/foreman/">foreman</a> or its Python counterpart <a href="https://github.com/nickstenning/honcho">honcho</a> make this easier, but, again it&#39;s one more thing to manage.</p>
|
||
|
||
<h3>You (Might) Need to Learn Something New</h3>
|
||
|
||
<p>If you&#39;ve been building traditional websites, chances are you&#39;ll be picking up a new framework, or even a new language to build your realtime endpoint. It will require a basic understanding of programming in an asynchronous manner (callbacks, co-routines, etc). Choosing the right toolkit can make this an easy transition, but it will still be more than the &quot;just throw gevent at it&quot; solution. For inspiration, read how <a href="http://blog.disqus.com/post/51155103801/trying-out-this-go-thing">Disqus replaced 4 maxed out Python/gevent servers with one mostly idle Go server in one week</a>.</p>
|
||
|
||
<h3>Your Auth Story Just Got More Complicated</h3>
|
||
|
||
<p>With one process all your sessions are in the same place. Knowing which requests are coming from authenticated clients and what resources those clients have access to is all baked in. When you add a different process to the mix, it may not have access to your session storage or even talk directly to the primary database to check permissions. You either need to do the work to make those happen or come up with an alternate authentication scheme. For Ginger, we generate short-lived tokens in Redis and pass them securely from the server to the client. The client passes the token back to the realtime endpoint for authentication. See <a href="http://pusher.com/docs/authenticating_users">Pusher&#39;s docs</a> for another example of how to handle this.</p>
|
||
|
||
<h2>What About Single Process, Realtime First?</h2>
|
||
|
||
<p>There&#39;s another option here which basically flips the option we used for BotBot.me on its head. Instead of trying to cram asynchronous bits (the realtime stuff) into your synchronous framework, you could put your synchronous bits in your asynchronous framework. Options here include Node.js (frameworks: Express, Meteor, Hapi) or Go (frameworks: Revel, Gorilla).</p>
|
||
|
||
<p>I&#39;m excited about the possibilities here, but the maturity and usability of these libraries isn&#39;t anywhere near what you get with a framework like Django or Rails. In addition, their ecosystem is years behind more mature languages. You&#39;ll be writing more code from scratch and not get the benefit of the massive open source ecosystem built around Python, Ruby, etc. I don&#39;t doubt they&#39;ll get to that place eventually, but for now, I think the trade-off is too great.</p>
|
||
|
||
<h2>Conclusion</h2>
|
||
|
||
<p>If you made it this far, it&#39;s probably clear which option I prefer. If I had to do it again, I would take the approach we used on Ginger. Separate processes optimized for separate concerns. It may be more work upfront, but it makes everything easier down the road. Especially when you need to grow from one server (in the physical or VPS sense) to multiple servers.</p>
|
||
|
||
<p>How about you? If you&#39;re running sites with realtime components in production, I&#39;d love to hear your thoughts and how you manage the processes.</p>
|
||
|
||
<p><em>Thanks to <a href="http://lucumr.pocoo.org/about/">Armin Ronacher</a> for reviewing this post for me.</em></p>
|
||
|
||
<p><strong>Recommending Reading</strong></p>
|
||
|
||
<ul>
|
||
<li>Arnout Kazemier&#39;s talk, <a href="http://lanyrd.com/2013/realtime-conf-europe/sccpxf/">Websuckets</a> for some reasons you should not rely solely on websockets.</li>
|
||
<li>Armin Ronacher&#39;s post, <a href="http://lucumr.pocoo.org/2012/8/5/stateless-and-proud/">Stateless and Proud in the Realtime World</a> which recommends a similar approach.</li>
|
||
<li>Aymeric Augstin&#39;s talk, <a href="http://lanyrd.com/2013/djangocon/scmqyy/">State of Realtime with Django</a>. TL;DW: The tools are there, but the Python ecosystem isn&#39;t built for an async world (yet).</li>
|
||
</ul>
|
||
</description><pubDate>Tue, 18 Feb 2014 10:55:46 -0600</pubDate><guid>http://lincolnloop.com/blog/architecting-realtime-applications/</guid></item><item><title>2013 Year in Review</title><link>http://lincolnloop.com/blog/2013-year-review/</link><description>
|
||
<p><strong>Please update to our new feed url: <a href="http://lincolnloop.com/blog/feed/">lincolnloop.com/blog/feed/</a></strong></p>
|
||
<hr/>
|
||
<p><img src="http://lincolnloop.com/uploads/uploads/greece.jpg" alt="Grecian Retreat"></p>
|
||
|
||
<p>2013 was an amazing roller coaster year at Lincoln Loop. This is a long post, so I&#39;ll skip the intro and dive right in.</p>
|
||
|
||
<h2>Company Accomplishments</h2>
|
||
|
||
<p>Of all the things we did and built, I&#39;m most proud of what we accomplished with our charitable giving program. <a href="http://lincolnloop.com/about/giving/">We donated $12,000 dollars</a> to charities we feel strongly about including Doctors without Borders, charity: water, Wikipedia, and the Ada Initiative. Each month, a different Looper chooses a charity that is near and dear to them. Although many of the donations were to global charity, our program lets us give back to the communities where our team lives.</p>
|
||
|
||
<p>We also became <a href="https://www.gittip.com/Lincoln%20Loop/">Gittip patrons</a>, donating another $200-300 per month to open source developers who make the tools we rely on everyday.</p>
|
||
|
||
<p>In May, we closed up shop and packed our bags for a week-long <a href="http://lincolnloop.com/blog/lincoln-loop-retreat-2013/">company retreat in Greece</a>. Working remotely, most of our interactions take place via a computer, so having a week together to relax, hang-out, hack, and discuss the future of Lincoln Loop was incredible. On top of that the location was almost perfect. After a quick stop-over in Athens, we convened at a secluded house on a Grecian Island with breathtaking ocean views. It&#39;s going to be tough to top it this year, but that won&#39;t stop us from trying.</p>
|
||
|
||
<p><a href="http://37signals.com/svn/posts/3652-remote-works-lincoln-loop">We were featured on 37signals&#39; blog, Signal vs. Noise</a> in October as part of the promotion of their latest book, <a href="http://37signals.com/remote/">Remote</a>. We received a mention in the book as well! We&#39;ve always looked up to 37signals (now renamed Basecamp) as a company. They are bootstrapped, successful and strive to create a sustainable workplace for their team. Having them take notice of what we&#39;re doing was an almost surreal event.</p>
|
||
|
||
<h2>Consulting and Development</h2>
|
||
|
||
<p>Our highest-profile project of the year and one I&#39;m immensely honored to be a part of was the relaunch of <a href="http://www.smithsonian.com">Smithsonian.com</a>. We worked with them to migrate from multiple different platforms and some proprietary vendor locked-in software to a solution built entirely on Django and open source software. The project was a huge undertaking, including architecture, legacy content migration, responsive design, accessibility, performance tuning, deployment, and more. We&#39;ll be pushing more sites to their new platform and look forward to continuing our work with the great team at Smithsonian in 2014.</p>
|
||
|
||
<p>In addition to Smithsonian, our team had the opportunity to work with some great people on the following sites and services:</p>
|
||
|
||
<ul>
|
||
<li><a href="http://www.awarnys.com/">Awarnys</a></li>
|
||
<li><a href="http://www.postmark.com/">Evite Postmark</a></li>
|
||
<li><a href="http://www.gamesradar.com">GamesRadar</a></li>
|
||
<li><a href="http://www.hukkster.com/">Hukkster</a></li>
|
||
<li><a href="http://www.redbeacon.com/">Redbeacon</a></li>
|
||
<li><a href="http://www.smithsonian.com">Smithsonian</a></li>
|
||
<li><a href="https://www.voteguide.com">VoteGuide</a></li>
|
||
</ul>
|
||
|
||
<h2>Products</h2>
|
||
|
||
<p>Our client work is usually focused on design, development, and deployment. We work closely with technical and business teams, but often don&#39;t get full insight into the level of effort it takes to make a product profitable. Our products have been a huge step forward for us in that regard and have given us a crash course in sales, marketing, and what it takes to support a project long-term. We didn&#39;t get to invest as much time as we&#39;d like in our products, but hit some big milestones nonetheless. Our recently <a href="https://github.com/BotBotMe">open sourced</a> IRC logger, <a href="https://botbot.me">BotBot.me</a>, saw steady growth and logged just under 8 million lines in 2013.</p>
|
||
|
||
<p><img src="http://lincolnloop.com/uploads/uploads/Riv3EAbv1z.jpg" alt="BotBot.me Stats"></p>
|
||
|
||
<p><a href="https://gingerhq.com">Ginger</a> is not just a product of ours, but the glue that holds our distributed team together. Quite frankly, sales were abysmal for much of the year. We decided to make a drastic move and change our pricing model from &quot;freemium&quot; to all paid plans with a free trial. Sales in the last 2.5 months of 2013 were almost <em>double</em> what we had done over the previous 1.5 years. It has been an incredible breath of fresh air and has us eager to continue to improve the platform and our sales effort.</p>
|
||
|
||
<h2>Moving On</h2>
|
||
|
||
<p>No doubt, 2013 was an incredible year for us. I&#39;d love to say it was all as amazing as portrayed here, but this is only our highlight reel. Like any good team, we had our fair share of disagreements, failures, and disappointments as well. Perhaps I&#39;ll share our lessons learned and lumps taken in another post, but for now, our sights are focused forward. We&#39;ve got some exciting new stuff planned for 2014... stay tuned.</p>
|
||
</description><pubDate>Mon, 10 Feb 2014 13:34:32 -0600</pubDate><guid>http://lincolnloop.com/blog/2013-year-review/</guid></item><item><title>Simplifying your Django Frontend Tasks with Grunt</title><link>http://lincolnloop.com/blog/simplifying-your-django-frontend-tasks-grunt/</link><description>
|
||
<p><strong>Please update to our new feed url: <a href="http://lincolnloop.com/blog/feed/">lincolnloop.com/blog/feed/</a></strong></p>
|
||
<hr/>
|
||
<p><a href="http://gruntjs.com/">Grunt</a> is a powerful task runner with an amazing assortment of plugins. It&#39;s not limited to the frontend, but there are many frontend-oriented plugins that you can take advantage of to combine and minify your static media, compile sass and less files, watch for changes during development and reload your browser automatically, and much more.</p>
|
||
|
||
<p>In the last several years, the amount of tooling around frontend development has expanded dramatically. Frameworks, libraries, preprocessors and postprocessors, transpilers, template languages, module systems, and more! Wiring everything together has become a significant challenge, and a variety of build tools have emerged to help ease this burden. Grunt is the current leader because of its fantastic plugin community, and it contains a wide array of plugins that can be very valuable to a Django developer. Today I&#39;m going to talk about an easy way to integrate Grunt with Django&#39;s runserver, and highlight a few plugins to handle common frontend tasks that Django developers often deal with.</p>
|
||
|
||
<h3>Installing Grunt</h3>
|
||
|
||
<p>Grunt uses Node.js, so you&#39;ll need to have that installed and configured on your system. This process will vary depending on your platform, but once it&#39;s done you&#39;ll need to install Grunt. From <a href="http://gruntjs.com/getting-started">the documentation</a>:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="c"><span class="err">$</span> <span class="n">npm</span> <span class="n">install</span> <span class="o">-</span><span class="n">g</span> <span class="n">grunt</span><span class="o">-</span><span class="n">cli</span></code></pre>
|
||
|
||
<blockquote>
|
||
<p>This will put the grunt command in your system path, allowing it to be run from any directory.</p>
|
||
|
||
<p>Note that installing grunt-cli does not install the Grunt task runner! The job of the Grunt CLI is simple: run the version of Grunt which has been installed next to a Gruntfile. This allows multiple versions of Grunt to be installed on the same machine simultaneously.</p>
|
||
</blockquote>
|
||
|
||
<p>Next, you&#39;ll want to install the Grunt task runner locally, along with a few plugins that I&#39;ll demonstrate:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="c"><span class="err">$</span> <span class="n">npm</span> <span class="n">install</span> <span class="o">--</span><span class="n">save</span><span class="o">-</span><span class="n">dev</span> <span class="n">grunt</span> <span class="n">grunt</span><span class="o">-</span><span class="n">contrib</span><span class="o">-</span><span class="n">concat</span> <span class="n">grunt</span><span class="o">-</span><span class="n">contrib</span><span class="o">-</span><span class="n">uglify</span> <span class="n">grunt</span><span class="o">-</span><span class="n">sass</span> <span class="n">grunt</span><span class="o">-</span><span class="n">contrib</span><span class="o">-</span><span class="n">less</span> <span class="n">grunt</span><span class="o">-</span><span class="n">contrib</span><span class="o">-</span><span class="n">watch</span></code></pre>
|
||
|
||
<h3>Managing Grunt with runserver</h3>
|
||
|
||
<p>There are a few different ways to get Grunt running alongside Django on your local development environment. The method I&#39;ll focus on here is by extending the <em>runserver</em> command. To do this, create a <em>gruntserver</em> command inside one of your project&#39;s apps. I commonly have a &quot;core&quot; app that I use for things like this. Create the &quot;management/command&quot; folders in your &quot;myproject/apps/core/&quot; directory (adjusting that path to your own preferred structure), and make sure to drop an <code data-syntax="text-only">__init__.py</code> in both of them. Then create a &quot;gruntserver.py&quot; inside &quot;command&quot; to extend the built-in.</p>
|
||
|
||
<p>In your new &quot;gruntserver.py&quot; extend the built-in and override a few methods so that you can automatically manage the Grunt process:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="python"><span class="kn">import</span> <span class="nn">os</span>
|
||
<span class="kn">import</span> <span class="nn">subprocess</span>
|
||
<span class="kn">import</span> <span class="nn">atexit</span>
|
||
<span class="kn">import</span> <span class="nn">signal</span>
|
||
|
||
<span class="kn">from</span> <span class="nn">django.conf</span> <span class="kn">import</span> <span class="n">settings</span>
|
||
<span class="kn">from</span> <span class="nn">django.contrib.staticfiles.management.commands.runserver</span> <span class="kn">import</span> <span class="n">Command</span>\
|
||
<span class="k">as</span> <span class="n">StaticfilesRunserverCommand</span>
|
||
|
||
|
||
<span class="k">class</span> <span class="nc">Command</span><span class="p">(</span><span class="n">StaticfilesRunserverCommand</span><span class="p">):</span>
|
||
|
||
<span class="k">def</span> <span class="nf">inner_run</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="o">*</span><span class="n">args</span><span class="p">,</span> <span class="o">**</span><span class="n">options</span><span class="p">):</span>
|
||
<span class="bp">self</span><span class="o">.</span><span class="n">start_grunt</span><span class="p">()</span>
|
||
<span class="k">return</span> <span class="nb">super</span><span class="p">(</span><span class="n">Command</span><span class="p">,</span> <span class="bp">self</span><span class="p">)</span><span class="o">.</span><span class="n">inner_run</span><span class="p">(</span><span class="o">*</span><span class="n">args</span><span class="p">,</span> <span class="o">**</span><span class="n">options</span><span class="p">)</span>
|
||
|
||
<span class="k">def</span> <span class="nf">start_grunt</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
|
||
<span class="bp">self</span><span class="o">.</span><span class="n">stdout</span><span class="o">.</span><span class="n">write</span><span class="p">(</span><span class="s">&#39;&gt;&gt;&gt; Starting grunt&#39;</span><span class="p">)</span>
|
||
<span class="bp">self</span><span class="o">.</span><span class="n">grunt_process</span> <span class="o">=</span> <span class="n">subprocess</span><span class="o">.</span><span class="n">Popen</span><span class="p">(</span>
|
||
<span class="p">[</span><span class="s">&#39;grunt --gruntfile={0}/Gruntfile.js --base=.&#39;</span><span class="o">.</span><span class="n">format</span><span class="p">(</span><span class="n">settings</span><span class="o">.</span><span class="n">PROJECT_PATH</span><span class="p">)],</span>
|
||
<span class="n">shell</span><span class="o">=</span><span class="bp">True</span><span class="p">,</span>
|
||
<span class="n">stdin</span><span class="o">=</span><span class="n">subprocess</span><span class="o">.</span><span class="n">PIPE</span><span class="p">,</span>
|
||
<span class="n">stdout</span><span class="o">=</span><span class="bp">self</span><span class="o">.</span><span class="n">stdout</span><span class="p">,</span>
|
||
<span class="n">stderr</span><span class="o">=</span><span class="bp">self</span><span class="o">.</span><span class="n">stderr</span><span class="p">,</span>
|
||
<span class="p">)</span>
|
||
|
||
<span class="bp">self</span><span class="o">.</span><span class="n">stdout</span><span class="o">.</span><span class="n">write</span><span class="p">(</span><span class="s">&#39;&gt;&gt;&gt; Grunt process on pid {0}&#39;</span><span class="o">.</span><span class="n">format</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">grunt_process</span><span class="o">.</span><span class="n">pid</span><span class="p">))</span>
|
||
|
||
<span class="k">def</span> <span class="nf">kill_grunt_process</span><span class="p">(</span><span class="n">pid</span><span class="p">):</span>
|
||
<span class="bp">self</span><span class="o">.</span><span class="n">stdout</span><span class="o">.</span><span class="n">write</span><span class="p">(</span><span class="s">&#39;&gt;&gt;&gt; Closing grunt process&#39;</span><span class="p">)</span>
|
||
<span class="n">os</span><span class="o">.</span><span class="n">kill</span><span class="p">(</span><span class="n">pid</span><span class="p">,</span> <span class="n">signal</span><span class="o">.</span><span class="n">SIGTERM</span><span class="p">)</span>
|
||
|
||
<span class="n">atexit</span><span class="o">.</span><span class="n">register</span><span class="p">(</span><span class="n">kill_grunt_process</span><span class="p">,</span> <span class="bp">self</span><span class="o">.</span><span class="n">grunt_process</span><span class="o">.</span><span class="n">pid</span><span class="p">)</span></code></pre>
|
||
|
||
<h3>A barebones grunt config</h3>
|
||
|
||
<p>To get started with Grunt, you&#39;ll need a barebones &quot;Gruntfile.js&quot; at the root of your project to serve as your config.</p>
|
||
|
||
<pre class="highlight"><code data-syntax="javascript"><span class="nx">module</span><span class="p">.</span><span class="nx">exports</span> <span class="o">=</span> <span class="kd">function</span><span class="p">(</span><span class="nx">grunt</span><span class="p">)</span> <span class="p">{</span>
|
||
|
||
<span class="c1">// Project configuration.</span>
|
||
<span class="nx">grunt</span><span class="p">.</span><span class="nx">initConfig</span><span class="p">({</span>
|
||
<span class="nx">pkg</span><span class="o">:</span> <span class="nx">grunt</span><span class="p">.</span><span class="nx">file</span><span class="p">.</span><span class="nx">readJSON</span><span class="p">(</span><span class="s1">&#39;package.json&#39;</span><span class="p">),</span>
|
||
|
||
<span class="c1">// Task configuration goes here.</span>
|
||
|
||
<span class="p">});</span>
|
||
|
||
<span class="c1">// Load plugins here.</span>
|
||
<span class="nx">grunt</span><span class="p">.</span><span class="nx">loadNpmTasks</span><span class="p">(</span><span class="s1">&#39;grunt-contrib-concat&#39;</span><span class="p">);</span>
|
||
<span class="nx">grunt</span><span class="p">.</span><span class="nx">loadNpmTasks</span><span class="p">(</span><span class="s1">&#39;grunt-contrib-uglify&#39;</span><span class="p">);</span>
|
||
<span class="nx">grunt</span><span class="p">.</span><span class="nx">loadNpmTasks</span><span class="p">(</span><span class="s1">&#39;grunt-sass&#39;</span><span class="p">);</span>
|
||
<span class="nx">grunt</span><span class="p">.</span><span class="nx">loadNpmTasks</span><span class="p">(</span><span class="s1">&#39;grunt-contrib-less&#39;</span><span class="p">);</span>
|
||
<span class="nx">grunt</span><span class="p">.</span><span class="nx">loadNpmTasks</span><span class="p">(</span><span class="s1">&#39;grunt-contrib-watch&#39;</span><span class="p">);</span>
|
||
|
||
<span class="c1">// Register tasks here.</span>
|
||
<span class="nx">grunt</span><span class="p">.</span><span class="nx">registerTask</span><span class="p">(</span><span class="s1">&#39;default&#39;</span><span class="p">,</span> <span class="p">[]);</span>
|
||
|
||
<span class="p">};</span></code></pre>
|
||
|
||
<h3>Combining static media</h3>
|
||
|
||
<p>A common task for the frontend, and one that we often use complex apps for in Django, is combining and minifying static media. This can all be handled by Grunt if you like, avoiding difficulties sometimes encountered when using an integrated Django app.</p>
|
||
|
||
<p>To combine files, use the <a href="https://github.com/gruntjs/grunt-contrib-concat">concat plugin</a>. Add some configuration to the &quot;grunt.initConfig&quot; call, using the name of the task as the key for the configuration data:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="javascript"><span class="nx">grunt</span><span class="p">.</span><span class="nx">initConfig</span><span class="p">({</span>
|
||
<span class="nx">pkg</span><span class="o">:</span> <span class="nx">grunt</span><span class="p">.</span><span class="nx">file</span><span class="p">.</span><span class="nx">readJSON</span><span class="p">(</span><span class="s1">&#39;package.json&#39;</span><span class="p">),</span>
|
||
|
||
<span class="c1">// Task configuration goes here.</span>
|
||
|
||
<span class="nx">concat</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">app</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">src</span><span class="o">:</span> <span class="p">[</span><span class="s1">&#39;myproject/static/js/app/**/*.js&#39;</span><span class="p">],</span>
|
||
<span class="nx">dest</span><span class="o">:</span> <span class="s1">&#39;build/static/js/app.js&#39;</span>
|
||
<span class="p">},</span>
|
||
<span class="nx">vendor</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">src</span><span class="o">:</span> <span class="p">[</span><span class="s1">&#39;myproject/static/js/vendor/**/*.js&#39;</span><span class="p">],</span>
|
||
<span class="nx">dest</span><span class="o">:</span> <span class="s1">&#39;build/static/js/lib.js&#39;</span>
|
||
<span class="p">}</span>
|
||
<span class="p">}</span>
|
||
<span class="p">});</span></code></pre>
|
||
|
||
<p>This will combine all Javascript files under &quot;myproject/static/app/js&quot; into one file called &quot;myproject/build/static/js/app.js&quot;. It will also combine all Javascript files under &quot;myproject/static/vendor&quot; into one file called &quot;myproject/build/static/js/lib.js&quot;. You&#39;ll likely want to refine this quite a bit to pick up only the files you want, and possibly build different bundles for different sections of your site. This will also work for CSS or any other type of file, though you may be using a preprocessor to combine your CSS and won&#39;t need this.</p>
|
||
|
||
<p>You&#39;ll probably want to use this along with the &quot;watch&quot; plugin for local development, but you&#39;ll use the &quot;uglify&quot; plugin for deployment.</p>
|
||
|
||
<h3>Minifying static media</h3>
|
||
|
||
<p>Once your app is ready for production, you can use Grunt to minify the JavaScript with the <a href="https://github.com/gruntjs/grunt-contrib-uglify">uglify plugin</a>. As with concatenation, minification of your CSS will likely be handled by your preprocessor.</p>
|
||
|
||
<p>This task should be run as part of your deploy process, or part of a pre-deploy build process. The uglify config will probably be very similar to your concat config:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="javascript"><span class="nx">uglify</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">app</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">files</span><span class="o">:</span> <span class="p">{</span><span class="s1">&#39;build/static/js/app.min.js&#39;</span><span class="o">:</span> <span class="p">[</span><span class="s1">&#39;myproject/static/js/app/**/*.js&#39;</span><span class="p">]}</span>
|
||
<span class="p">},</span>
|
||
<span class="nx">vendor</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">files</span><span class="o">:</span> <span class="p">{</span><span class="s1">&#39;build/static/js/lib.min.js&#39;</span><span class="o">:</span> <span class="p">[</span><span class="s1">&#39;myproject/static/js/vendor/**/*.js&#39;</span><span class="p">]}</span>
|
||
<span class="p">}</span>
|
||
<span class="p">}</span></code></pre>
|
||
|
||
<p>The main difference is that uglify takes the new-style &quot;files&quot; option instead of the classic &quot;src&quot; and &quot;dest&quot; options that concat uses.</p>
|
||
|
||
<h3>Compiling Sass</h3>
|
||
|
||
<p>You can compile Sass with Compass using the <a href="https://github.com/gruntjs/grunt-contrib-compass">compass plugin</a>, but I prefer to use the speedier <a href="https://github.com/sindresorhus/grunt-sass">sass plugin</a> that uses <a href="https://github.com/hcatlin/libsass">libsass</a>. Here&#39;s an example that includes the Foundation library:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="javascript"><span class="nx">sass</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">dev</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">options</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">includePaths</span><span class="o">:</span> <span class="p">[</span><span class="s1">&#39;bower_components/foundation/scss&#39;</span><span class="p">]</span>
|
||
<span class="p">},</span>
|
||
<span class="nx">files</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="s1">&#39;build/static/css/screen.css&#39;</span><span class="o">:</span> <span class="s1">&#39;myproject/static/scss/screen.scss&#39;</span>
|
||
<span class="p">}</span>
|
||
<span class="p">},</span>
|
||
<span class="nx">deploy</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">options</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">includePaths</span><span class="o">:</span> <span class="p">[</span><span class="s1">&#39;bower_components/foundation/scss&#39;</span><span class="p">],</span>
|
||
<span class="nx">outputStyle</span><span class="o">:</span> <span class="s1">&#39;compressed&#39;</span>
|
||
<span class="p">},</span>
|
||
<span class="nx">files</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="s1">&#39;build/static/css/screen.min.css&#39;</span><span class="o">:</span> <span class="s1">&#39;myproject/static/scss/screen.scss&#39;</span>
|
||
<span class="p">}</span>
|
||
<span class="p">}</span>
|
||
<span class="p">},</span></code></pre>
|
||
|
||
<h3>Compiling Less</h3>
|
||
|
||
<p>Less is compiled using the <a href="">less plugin</a>.</p>
|
||
|
||
<pre class="highlight"><code data-syntax="javascript"><span class="nx">less</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">dev</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">options</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">paths</span><span class="o">:</span> <span class="p">[</span><span class="s1">&#39;myproject/static/less&#39;</span><span class="p">]</span>
|
||
<span class="p">},</span>
|
||
<span class="nx">files</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="s1">&#39;build/static/css/screen.css&#39;</span><span class="o">:</span> <span class="s1">&#39;myproject/static/less/screen.less&#39;</span>
|
||
<span class="p">}</span>
|
||
<span class="p">}</span>
|
||
<span class="nx">deploy</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">options</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">paths</span><span class="o">:</span> <span class="p">[</span><span class="s1">&#39;myproject/static/less&#39;</span><span class="p">],</span>
|
||
<span class="nx">compress</span><span class="o">:</span> <span class="kc">true</span>
|
||
<span class="p">},</span>
|
||
<span class="nx">files</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="s1">&#39;build/static/css/screen.min.css&#39;</span><span class="o">:</span> <span class="s1">&#39;myproject/static/less/screen.less&#39;</span>
|
||
<span class="p">}</span>
|
||
<span class="p">}</span>
|
||
<span class="p">},</span></code></pre>
|
||
|
||
<h3>Watching for changes and live reloading</h3>
|
||
|
||
<p>Now that you&#39;ve got your initial operations configured, you can use the <a href="https://github.com/gruntjs/grunt-contrib-watch">watch plugin</a> to watch for changes and keep the files up to date. It also will send livereload signals, which you can use to automatically refresh your browser window.</p>
|
||
|
||
<pre class="highlight"><code data-syntax="javascript"><span class="nx">watch</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">options</span><span class="o">:</span> <span class="p">{</span><span class="nx">livereload</span><span class="o">:</span> <span class="kc">true</span><span class="p">}</span>
|
||
<span class="nx">javascript</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">files</span><span class="o">:</span> <span class="p">[</span><span class="s1">&#39;myproject/static/js/app/**/*.js&#39;</span><span class="p">],</span>
|
||
<span class="nx">tasks</span><span class="o">:</span> <span class="p">[</span><span class="s1">&#39;concat&#39;</span><span class="p">]</span>
|
||
<span class="p">},</span>
|
||
<span class="nx">sass</span><span class="o">:</span> <span class="p">{</span>
|
||
<span class="nx">files</span><span class="o">:</span> <span class="s1">&#39;myproject/static/scss/**/*.scss&#39;</span><span class="p">,</span>
|
||
<span class="nx">tasks</span><span class="o">:</span> <span class="p">[</span><span class="s1">&#39;sass:dev&#39;</span><span class="p">]</span>
|
||
<span class="p">}</span>
|
||
<span class="p">}</span></code></pre>
|
||
|
||
<p>Note the way the task is specified in the &quot;sass&quot; watch config. Calling &quot;sass:dev&quot; instructs it to use the &quot;dev&quot; config block from the &quot;sass&quot; task. Using &quot;sass&quot; by itself as the name of the task would have invoked both &quot;sass:dev&quot; and &quot;sass:deploy&quot; from our configuration above.</p>
|
||
|
||
<p>Also note how we&#39;re using a top-level &quot;options&quot; definition here to make livereload the default. You can then override that for an individual watch definition if you don&#39;t need livereload for that one.</p>
|
||
|
||
<p>In order for the browser to make use of the livereload signals, we&#39;ll need to add a &lt;script&gt; tag that retrieves code from the livereload server that Grunt starts in the background. In Django, you&#39;ll want to hide this tag behind a DEBUG check.</p>
|
||
|
||
<pre class="highlight"><code data-syntax="text-only">{% if debug %}
|
||
&lt;script src=&quot;//localhost:35729/livereload.js&quot;&gt;&lt;/script&gt;
|
||
{% endif %}</code></pre>
|
||
|
||
<p>You can also use a <a href="http://feedback.livereload.com/knowledgebase/articles/86242-how-do-i-install-and-use-the-browser-extensions-">LiveReload browser extension</a> instead.</p>
|
||
|
||
<h3>More to come</h3>
|
||
|
||
<p>Grunt is a fantastic tool and one that makes it easier to work with the growing set of frontend tools that are emerging. There&#39;s a vibrant plugin ecosystem, and its capabilities are growing all the time. I&#39;ll be covering more of those tools in the future, and I&#39;ll be sure to include Grunt configuration for each one. Enjoy!</p>
|
||
</description><pubDate>Mon, 27 Jan 2014 14:43:42 -0600</pubDate><guid>http://lincolnloop.com/blog/simplifying-your-django-frontend-tasks-grunt/</guid></item><item><title>Installing Node.js and npm into a Python Virtualenv</title><link>http://lincolnloop.com/blog/installing-nodejs-and-npm-python-virtualenv/</link><description>
|
||
<p><strong>Please update to our new feed url: <a href="http://lincolnloop.com/blog/feed/">lincolnloop.com/blog/feed/</a></strong></p>
|
||
<hr/>
|
||
<p>With things like <a href="http://lesscss.org/">LESS</a> and <a href="http://requirejs.org/">RequireJS</a>, we&#39;re starting to use Node.js&#39;s <code data-syntax="text-only">npm</code> (think <code data-syntax="text-only">pip</code> for JavaScript) on every other project. However, installing Node.js globally means some dependencies are also installed globally, which might be a problem if different projects use different versions of the same packages. One solution is to install Node.js/npm inside your virtualenv, so here are the steps to get there:</p>
|
||
|
||
<p>First off, activate your virtualenv, and:</p>
|
||
|
||
<pre class="highlight"><code data-syntax="bash"><span class="nv">$ </span>curl http://nodejs.org/dist/node-latest.tar.gz | tar xvz
|
||
<span class="nv">$ </span><span class="nb">cd </span>node-v*
|
||
<span class="nv">$ </span>./configure --prefix<span class="o">=</span><span class="nv">$VIRTUAL_ENV</span>
|
||
<span class="nv">$ </span>make install</code></pre>
|
||
|
||
<p>That&#39;s it! Now you can install npm packages directly to your virtualenv path with <code data-syntax="text-only">npm install -g {package}</code>.</p>
|
||
</description><pubDate>Thu, 08 Aug 2013 10:45:01 -0500</pubDate><guid>http://lincolnloop.com/blog/installing-nodejs-and-npm-python-virtualenv/</guid></item></channel></rss> |