9 posts with this tag
When deploying pet projects on remote servers, I dislike the extra step of logging into the remote machine to execute a git pull (and perhaps a server reload) every time I push new code. Sure there’s Jenkins and all sorts of bazooka-like solutions, but this is a knife fight. Poking around an old PHP repo, I found a nifty line of code that will update your app via a URL endpoint.
Deep within the brain of a developer, nestled between the gentle folds of the nucleus accumbens, lives a strong and primitive craving for automation. The concept of a function, f(x)=y, and likely algebra itself induces this region of the brain to release a powerful, pleasurable burst of dopamine.
It is from this area of the brain that Grunt, the automation system extraordinaire, was born. Grunt saves you the effort of running repetitive tasks such as concatenation, minification, translation (LESS -> CSS), testing, deployment, code linting, and more. It’s a bit like a Makefile with a bunch of community-contributed bells and whistles written in JavaScript.
A major benefit of using a shared language on the browser and the server is a smaller amount of duplicate code in your codebase. Let’s assume you want to be able to share the file shared.js between the client and the server:
On the server
var shared = require('./shared');
console.log(shared.hello());
On the browser
<script src="shared.js"></script>
<script>
console.log(shared.hello());
</script>
There are a number of libraries that can be used to facilitate this type of sharing including RequireJS, gemini, or node-browserify. If you’re looking to stay away from libraries here are two patterns for creating sharable JavaScript files that can be used on both the client and the server.
I am a toymaker. Some toys are simple, others complex, and some are just plain wacky. What unites these toys are that they are:
Showcasing, hosting, and monitoring applications can be difficult, especially if you want to have them all live under one domain or URL path (e.g. http://gleitzman.com/apps/appname). Whether you’re working in Python, Javascript, or Ruby you need a reverse-proxy that can receive requests and delegate to a specific application’s server. I’ve tried a number of techniques but ultimately landed with supervisor and nginx.
Reloading modules in Node.js can be a bit tricky. After initially importing a module, subsequent calls to require have no effect. Looking for something along the lines of Python’s reload command I’ve arrived at this solution that allows modules to be reloaded (as well as imported the first time) with the following require.reload command.
// Import a module
var mymodule = require('./mymodule')
// After making some changes to the module, reload it
mymodule = require.reload('./mymodule')
Reloading is accomplished by searching the cache for a specific module using require.searchCache and removing that module and its children with require.uncache. The real heavy lifting is done by the call to delete require.cache[mod.id]. Below is the script for starting a modified repl that includes the additional require commands by default.
“Everything old is new again.”
–Peter Allen
The evolution of the web browser is in many ways the repackaging and reintroduction of technologies that have existed on the desktop for decades. Consider WebGL replacing OpenGL with the help of the <canvas> tag and HTML5 video replacing ActionScript/Flash with the <video> element.
At the well-run Science Hack Day SF I was able to dive into these new browser technologies along with Jade and Rich to build Symphony of Satellites, an app that generates music based on the trajectories of satellites currently overhead. Using data calculated live from NORAD, musical notes ride and set as satellites appear and disappear over the horizon. The velocity of the satellite, its elevation, and other aspects of its trajectory determine the instrument, pitch, and rhythm of notes generated by that satellite and the visualization on the page. The promo video for the app is worth watching.
In search of a weekend hack and after hearing a number of nice comments about the Meteor programming platform I decided to kill two birds with one stone by porting Yet Another Choose Your Own Adventure (first debuted at Art Hack Day SF) to Meteor for folks to play online.
The result is http://adventure.gleitzman.com/
Going to meet the meteor
Programming with Meteor has a bit of a learning curve but the included examples are an excellent place to start. Below are some thoughts are observations – follow along at home with the code at https://github.com/gleitz/meteorcyoa.
In the beginning of a project it is common to cut corners to save time. Security is often the first to be sacrificed because you might not be dealing with terribly sensitive information and who really wants to hack your crowd-sourced “Netflix for knives” pinterest-clone, anyway?
However, there are some poor security decisions I’ve been alarmed to discover recently on a number of websites. These sites that I use and enjoy have made the cardinal sin of storing passwords in plain text in Javascript. This is a Bad Idea® for a number of reasons and no amount of https is going to save you.
I’ve come to appreciate the flexability of Javascript. In particular, how you can solve a problem in a number of different yet elegant ways.
Recently I’ve come across two sites that do a rather good job explaining a number of nice JS patterns. I’ll leave this here for your perusal.
http://shichuan.github.com/javascript-patterns/ https://github.com/rwldrn/idiomatic.js
And of course if you haven’t see it, check out this video of The Good Parts.
