Habaritag:zetafleet.com,2012-03-12:atom/4aa1ac0ff2e6ef4f36493cf275f66e1b8ffc4d25ZetafleetWeb design &amp; development | Minneapolis, MN2012-03-12T12:46:30-05:00Unified codebases with Dojo, Node, and RequireJS: the holy grail of DRY codecolinzetafleet.comtag:zetafleet.com,2011:one-codebase-to-rule-them-all-dojo-node-requirejs-and-the-holy-grail-of-web-development/12989429632011-02-28T23:40:22-06:002011-02-28T23:40:22-06:00<p><strong>Update 2011-05-10:</strong> The code referenced in this post is now out of date. Please check <a class="https://github.com/csnover/dojo-boilerplate/tree/amd1.7">Dojo Boilerplate’s AMD branch</a> for up-to-date code.</p><p>For a large part of my Web development career, I’ve felt unease at the fact that every single Web app I’ve worked on has required two completely separate codebases: one for the server, usually written in a language like PHP, and one on the client, written in JavaScript. Over the years, thousands of frameworks have been written to try to streamline and automate this process, from <a class="ajaxpatterns.org/PHP_Ajax_Frameworks">crappy little AJAX page loaders</a> to <a class="code.google.com/webtoolkit/">incredibly complex Java-to-JavaScript translators</a>—but no matter how good any of these frameworks was, you were always writing to the language running on the server <em>first</em>, even though that language was (and likely always will be) incompatible with what runs in browsers on the client.</p><p>For the first time in over a decade, I’m happy to say that I believe this discontinuity has finally been solved in a way that will fundamentally change how all Web applications are written in the future. I say this because yesterday, for the first time ever, I succeeded in running a single JavaScript codebase seamlessly on both the client and server using a simple combination of <a class="dojotoolkit.org">Dojo Toolkit 1.6</a>, <a class="nodejs.org">Node.js 0.4.1</a>, and <a class="requirejs.org">RequireJS 0.24</a>.</p><p>I’m sure this isn’t the first time someone has accomplished this, but the robustness of Dojo’s tools, the performance of Node, and the simplicity of RequireJS all combined in a way that made me feel that the time has finally come for Web development to shift to pure, seamless, fully-integrated JavaScript. Unlike past experiments that often involved gross hacks or the use of barely functional pre-alpha software, I would feel confident in deploying this solution to a production environment today. I hope this article gets others to start exploring and feeling excited about these technologies and how they’re changing Web development as we know it.</p><h2>Dojo on Node.js</h2><p>In Dojo 1.6, the Dojo team spent a <em>huge</em> amount of effort adding full support for the <a class="wiki.commonjs.org/wiki/Modules/AsynchronousDefinition">CommonJS <abbr title="Asynchronous Module Definition">AMD</abbr> specification</a> across all Dojo and Dijit modules; this change is the key that really puts Dojo worlds above any other toolkit when it comes to creating single codebase applications. Prior to this, Dojo was already the best <abbr title="Rich Internet Application">RIA</abbr> toolkit on the market, but running it in Node meant some ugly hacking to circumvent Node’s module sandboxing. With AMD, these hacks are no longer necessary.</p><p>Unfortunately, a tiny amount of modification is necessary in order to get Dojo 1.6.0 running in Node 0.4. Luckily, the changes amount to <a class="bugs.dojotoolkit.org/ticket/12357">two one-liners and an alternative package main module</a>, and these fixes are already scheduled to be added to the next version of Dojo.</p><h2>RequireJS on Node.js</h2><p>Node’s default module system is designed around the idea that dependencies can be loaded synchronously, which makes it a terrible choice for writing code modules that will run on the client. Swap it out with RequireJS—which still allows you to seamlessly use Node packages on the server-side—and writing highly modular code for both client and server suddenly becomes trivial. Roughly speaking, RequireJS provides a 1:1 mapping between filenames and defined modules, so if you had a component named <code>my/app/FirstClass</code>, you would just put it in <code>my/app/FirstClass.js</code> and RequireJS would load the definition from that file. Easy-peasy!</p><p>RequireJS also has support for basic loading of text files as dependencies and simple Object dictionaries for <abbr title="internationalisation">i18n</abbr>. It also provides a highly robust build system, which means that when you’re ready to deploy to production, it’ll concatenate and minify all your code, intern external text, even let you split your code into arbitrary collections of modules that can be lazy-loaded on demand and minify your CSS. <a class="www.youtube.com/watch?v=Jo6dkHgT6TI">Amazing!</a></p><h2>Putting it all together</h2><p>In order to run a single codebase application using Dojo, RequireJS, and Node, you really only need 4 special things (and they really aren’t that special):</p><ol><li>A stub HTML file that loads RequireJS (index.html)</li><li>A shell script that invokes Node with RequireJS (server.sh)</li><li>A stub script that configures RequireJS for each environment and loads your main application code (js/my/_base.js)</li><li>Some sort of logic within your application that branches depending upon the environment for any modules that need to load only in one place or the other (js/my/app.js)</li></ol><p>In the examples given below, the application structure looks roughly like this:</p><ul><li>app/<ul> <li>index.html</li> <li>server.sh</li> <li>css/</li> <li>js/<ul> <li>lib/<ul> <li>requirejs/</li> <li>dojo/</li> <li>dijit/</li> </ul><li>my/</p><ul> <li>_base.js</li> <li>app.js</li> <li>nls/<ul><li>app.js</li></ul></li> </ul> </li> </ul> </li> </ul></li></ul><p>There’s no particular requirement that the application be structured in this way, it’s just how I personally like to structure mine today.</p><h3>index.html</h3><p>A very basic HTML file; this loads RequireJS, then loads the application stub. Everything else is handled by Dojo/Dijit and RequireJS from this point on.</p><pre style="overflow: auto;"><code>&lt;!DOCTYPE html>&lt;html> &lt;head> &lt;title>my app&lt;/title> &lt;meta charset="utf-8"> &lt;link rel="stylesheet" class="css/app.css"> &lt;/head> &lt;body> &lt;!-- this will change to a single, minified<br> JS file once you are in production --> &lt;script src="/img/spacer.gif"> Google Chrome's Heap Profiler and Memory Timeline, explainedcolinzetafleet.comtag:zetafleet.com,2011:using-google-chrome-s-heap-profiler-and-memory-timeline-to-reduce-memory-usage/12956760032011-01-27T12:36:20-06:002011-01-27T12:36:20-06:00<p style="font-style: italic;">(with thanks to <a class="www.linkedin.com/in/mnaganov">Mikhail Naganov</a> for his <a class="groups.google.com/group/google-chrome-developer-tools/browse_thread/thread/a5f86cb20fa1e9eb/">feedback on the Developer Tools mailing list</a>)</p><p><a class="code.google.com/chrome/devtools">Chrome’s Developer Tools</a> contain some useful features for inspecting memory usage of a given page (and its change over time), but the documentation for these features is a bit sparse—and, if you are unfamiliar with these sorts of tools and what they do, their output can seem undecipherable. Hopefully this brief post helps explain these features and what they can do for you.</p><h2>The Memory Timeline</h2><p><a class="zetafleet.com/user/files/blog/chrome-memtimeline.png"><img style="display:block;" src="/img/spacer.gif"> Introducing TracTicketGraphcolinzetafleet.comtag:zetafleet.com,2010:introducing-tracticketgraph/12879907272010-10-25T02:18:44-05:002010-10-25T02:18:44-05:00<p>The <a class="jquery.com">jQuery project</a> uses <a class="trac.edgewall.org/">Trac</a> for bug tracking, and a request from several team members (including myself) was to have a page that showed overview of ticket activity over time. There are a couple different Trac plugins that exist to perform this task, but they don’t work very well. TracTicketStatsPlugin requires YUI (even though Trac uses jQuery), it loads a bunch of debug crap, it has SQL injection issues, it’s ugly, and it requires Flash. TracMetrixPlugin requires matplotlib, which in turn requires a bunch of X11 libraries, screws up Trac permissions in 0.12, has worthless documentation, and is very slow. So, I dove into the world of Python and Trac and came up with something that should be much better.</p><p><strong>TracTicketGraph</strong> has no external dependencies and uses the awesome <a class="code.google.com/p/flot/">flot</a> library to generate graphs. It is released under an MIT license. There are a few caveats, mostly due to time constraints, but anyone with some Python and JS skill should be able to take care of these issues quickly and easily:</p><ol><li>You can use a “days” query parameter to change the number of previous days viewed, but there is not currently any UI for making this change.</li><li>The end date is always fixed to the current date.</li><li>The size of the graph is fixed in JS, instead of being configurable by CSS.</li><li>It is not internationalized.</li><li>There are no tooltips.</li></ol><p><a class="zetafleet.com/user/files/software/TracTicketGraph.tar.bz2">Download TracTicketGraph</a> · <a class="zetafleet.com/user/files/software/TracTicketGraph.png">View a screenshot</a></p>Standalone Universal Character Set Detectioncolinzetafleet.comtag:zetafleet.com,2010:standalone-universal-character-set-detection/12846881162010-09-16T20:48:36-05:002010-09-16T20:48:36-05:00<p><a class="mozilla.com">Mozilla</a> have a pretty nice universal character set detector built into their products. It’s modular, it’s quick, and it has a great deal of real-world research and testing behind it. I wanted to be able to use it as part of a project I am working on, but couldn’t find a nice standalone command-line version. There is a <a class="code.google.com/p/juniversalchardet/" title="Java version of universalchardet">Java port</a>, but the overhead of loading up a JVM just to detect the character set of a document was unappealing, and porting the entire codebase to another language would take too long (plus it would run a lot slower). So, I spent an evening learning some C/C++ and came up with just what I needed. I thought it might be useful to someone else, too, so I am releasing it here.</p><p>The <tt>README.txt</tt> contains compilation and usage instructions. I have no more words now. Get it below!</p><p><a class="zetafleet.com/user/files/software/universalchardet.tar.bz2">Download universalchardet</a></p>What the hell is this? I don’t even…colinzetafleet.comtag:zetafleet.com,2010:what-the-hell-is-this-i-don-t-even-know/12844367492010-09-13T22:59:09-05:002010-09-13T22:59:09-05:00<h2>Introducing Imma Let U Finish</h2><p><q><a class="immaletufinish.com">Imma Let U Finish</a> these offers here is the code to get and give support for any other information on file!</q> <cite>—An actual sentence generated by Imma Let U Finish</cite></p><p>Imma Let U Finish abuses Google Scribe to generate sentences that almost make sense sometimes but nearly always end up hilariously baffling. Enjoy!</p><p>(Design by <a class="nimbupani.com/">Nimbupani Designs</a>. Thanks to <a class="www.bentruyman.com/">Ben Truyman</a> for the domain name.)</p>
Related searches:
zetafleet google server chrome change
gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.