A list of Node.js frameworks.
Continue reading “Node.js Frameworks”
Node.js Frameworks
A list of MVC, REST API and full-stack Node.js frameworks.
Book author Azat Mardan writes about apps, startups and technology
A list of MVC, REST API and full-stack Node.js frameworks.
A list of Node.js frameworks.
Continue reading “Node.js Frameworks”
Here is a little JavaScript trick I did to randomly include LeanPub embed (e.g., like the one in the right sidebar
Here is a little JavaScript trick I did to randomly include LeanPub embed (e.g., like the one in the right sidebar).
Continue reading “Not Everything has to be done Server-side”
This is a release candidate for 1.0 version which is going to be available to public in print. Page count has increase from 151 to 211 pages (PDF), which include the following updates:
More digestible (smaller) code examples with better comments
Express.js middleware section with an example
Express.js + MongoDB REST API server section with an example
Derby section with an example
Grammar and typo fixes
Illustrations
Summaries in the beginning of each chapter
Code examples formatting fixes
This is a release candidate for 1.0 version which is going to be available to public in print. Page count has increase from 151 to 211 pages (PDF), which include the following updates:
Download a free chapter Intro to Backbone.js or full PDF, ePub or Mobi copy at LeanPub.
Rapid Prototyping with JS touched topics such as:
If you need in-depth knowledge or references, they are usually one click or one Google search away.
Practical aspect included building multiple versions of the Message Board app:
The Message Board application has all the foundation of a typical web/mobile application: fetching data, displaying it, submitting new data. Other examples include:
Oh My JS: The Best JavaScript Articles (https://leanpub.com/ohmyjs/) is in the works!
There is a certain magic in ORMs like Mongoose. I learned it the hard way (as usual!), when I was trying to iterate over nested object’s properties…
There is a certain magic in ORMs like Mongoose. I learned it the hard way (as usual!), when I was trying to iterate over nested object’s properties. For example, here is a schema with a nested object features defines like this:
var User = module.exports = new Schema({
features: {
realtime_updates: {
type: Boolean
},
storylock: {
type: Boolean
},
custom_embed_style: {
type: Boolean
},
private_stories: {
type: Boolean
},
headerless_embed:{
type: Boolean
}
};
Let’s say I want to overwrite object features_enabled with these properties:
if (this.features) {
for (var k in this.features) {
features_enabled[k] = this.features[k];
}
}
console.log(features_enabled)
return features_enabled;
Not so fast, I was getting a lot of system properties specific to Mongoose. Instead we need to use toObject()
, e.g.:
if (this.features.toObject()) {
for (var k in this.features.toObject()) {
console.log('!',k)
features_enabled[k] = this.features.toObject()[k];
}
}
Remember rule number one, computer is always right. If we think that it’s wrong — look up the rule number one. :-)
Why Backbone.js? Because a lot of people expressed desire to use it but being a framework Backbone has a learning curve. Not a steep one like Rails but still it takes time to master and learn Backbone. The new chapter “Intro to Backbone.js” will show readers how to:
Link to the new copy of Rapid Prototyping with JS at https://leanpub.com/rapid-prototyping-with-js.
Here is a list of the update for Rapid Prototyping with JS v0.4:
LeanPub changed their purchasing. Now it’s even better for readers. Anybody can “return” the book they didn’t like within 45 days and get a full refund. Word return is in double quotes because all content is Digital Right Management (DRM) free. Does it mean that somebody can buy and download a book, get their money back, but keep the copy? Yes, but they will get bad karma for that! And not like a bad karma on Hacker News but a real bad karma. Everybody else deservers authors and publishers trust and respect.
Why Backbone.js? Because a lot of people expressed desire to use it but being a framework Backbone has a learning curve. Not a steep one like Rails but still it takes time to master and learn Backbone. The new chapter “Intro to Backbone.js” will show readers how to:
Write and follow @RPJSbook.
Don’t waste time writing tests for throwaway scripts, but please adapt the habit of Test-Driven Development for the main code base. With a little time spent in the beginning, you and your team will save time later and have confidence when rolling out new releases. Test Driven Development is a really really really good thing.
Imagine that you need to implement a complex feature on top of an existing interface, e.g., a ‘like’ button on a comment. Without tests you’ll have to manually create a user, log in, create a post, create a different user, log in with a different user and like the post. Tiresome? What if you’ll need to do it 10 or 20 times to find and fix some nasty bug? What if your feature breaks existing functionality, but you notice it 6 months after the release because there was no test!
Don’t waste time writing tests for throwaway scripts, but please adapt the habit of Test-Driven Development for the main code base. With a little time spent in the beginning, you and your team will save time later and have confidence when rolling out new releases. Test Driven Development is a really really really good thing.
Follow this quick guide to set up your Test-Driven Development process in Node.js with Mocha.
Install Mocha globally by executing this command:
$ sudo npm install -g mocha
We’ll also use two libraries, Superagent and expect.js by LeanBoost. To install them fire up npm commands in your project folder like this:
$ npm install superagent
$ npm install expect.js
Open a new file with .js
extension and type:
var request = require('superagent');
var expect = require('expect.js');
So far we’ve included two libraries. The structure of the test suite going to look like this:
describe('Suite one', function(){
it(function(done){
...
});
it(function(done){
...
});
});
describe('Suite two', function(){
it(function(done){
...
});
});
Inside of this closure we can write request to our server which should be running at localhost:8080:
...
it (function(done){
request.post('localhost:8080').end(function(res){
//TODO check that response is okay
});
});
...
Expect will give us handy functions to check any condition we can think of:
...
expect(res).to.exist;
expect(res.status).to.equal(200);
expect(res.body).to.contain('world');
...
Lastly, we need to add done() call to notify Mocha that asynchronous test has finished its work. And the full code of our first test looks like this:
var request = require('superagent');
var expect = require('expect.js');
describe('Suite one', function(){
it (function(done){
request.post('localhost:8080').end(function(res){
expect(res).to.exist;
expect(res.status).to.equal(200);
expect(res.body).to.contain('world');
done();
});
});
});
If we want to get fancy, we can add before and beforeEach hooks which will, according to their names, execute once before the test (or suite) or each time before the test (or suite):
before(function(){
//TODO seed the database
});
describe('suite one ',function(){
beforeEach(function(){
//todo log in test user
});
it('test one', function(done){
...
});
});
Note that before and beforeEach can be placed inside or outside of describe construction.
To run our test simply execute:
$ mocha test.js
To use different report type:
$ mocha test.js -R list
$ mocha test.js -R spec
One of the biggest advantages of using Node.js over Python or Ruby is that Node has a non-blocking I/O mechanism. To illustrate this let me use an example of a line in a Starbucks coffeeshop. Let’s pretend that each person standing in line for a drink is a task, and everything behind the counter — cashier, register, barista — is a server or server application. When we order a cup of regular drip coffee, like Pike, or hot tea, like Earl Grey, the barista makes it. While the whole line waits while that drink is made, and the person is charged the appropriate amount…
One of the biggest advantages of using Node.js over Python or Ruby is that Node has a non-blocking I/O mechanism. To illustrate this, let me use an example of a line in a Starbucks coffee shop. Let’s pretend that each person standing in line for a drink is a task, and everything behind the counter — cashier, register, barista — is a server or server application. When we order a cup of regular drip coffee, like Pike, or hot tea, like Earl Grey, the barista makes it. The whole line waits while that drink is made, and the person is charged the appropriate amount.
Of course, we know that these kinds of drinks are easy to make; just pour the liquid and it’s done. But what about those fancy choco-mocha-frappe-latte-soy-decafs? What if everybody in line decides to order these time-consuming drinks? The line will be held up by each order, and it will grow longer and longer. The manager of the coffee shop will have to add more registers and put more baristas to work (or even stand behind the register him/herself). This is not good, right? But this is how virtually all server-side technologies work, except Node. Node is like a real Starbucks. When you order something, the barista yells the order to the other employee, and you leave the register. Another person gives their order while you wait for your state-of-the-art eye-opener in a paper cup. The line moves, the processes are executed asynchronously and without blocking the queue by waiting.
This is why Node.js blows everything else away (except maybe low-level C/C++) in terms of performance and scalability. With Node, you just don’t need that many CPUs and servers to handle the load.
Asynchronicity requires a different way of thinking for programmers familiar with Python, PHP, C or Ruby. It’s easy to introduce a bug unintentionally by forgetting to end the execution of the code with a proper return expression.
Here is a simple example illustrating this scenario:
var test = function (callback) {
return callback();
console.log('test') //shouldn't be printed
}
var test2 = function(callback){
callback();
console.log('test2') //printed 3rd
}
test(function(){
console.log('callback1') //printed first
test2(function(){
console.log('callback2') //printed 2nd
})
});
If we don’t use return callback() and just use callback() our string test2 will be printed (test is not printed).
callback1
callback2
tes2
For fun I’ve added a setTimeout()
delay for the callback2 string, and now the order has changed:
var test = function (callback) {
return callback();
console.log('test') //shouldn't be printed
}
var test2 = function(callback){
callback();
console.log('test2') //printed 2nd
}
test(function(){
console.log('callback1') //printed first
test2(function(){
setTimeout(function(){
console.log('callback2') //printed 3rd
},100)
})
});
Prints:
callback1
tes2
callback2
The last example illustrates that the two functions are independent of each other and run in parallel. The faster function will finish sooner than the slower one. Going back to our Starbucks examples, you might get your drink faster than the other person who was in front of you in the line. Better for people, and better for programs! :-)
Web development usually involves a large number of languages each with its own syntax, keywords, special sauce and magic tricks. Here is a collection of web development cheat sheets, in no particular order, which I’ve amassed by browsing the Internet over many years of web development
Cheat sheets are great ways to organize frequently used information and keep it handy. I used cheat sheets for learning and memorizing during my crams at school, and use them now for reference.
Web development usually involves a large number of languages each with its own syntax, keywords, special sauce and magic tricks.
Here is a collection of web development cheat sheets, in no particular order, which I’ve amassed by browsing the Internet over many years of web development. They cover the following topics:
Get zip archive at http://www.webapplog.com/wp-content/uploads/web-dev-cheat-sheets.zip.
Full list of the files:
jquery12_colorcharge.png
cdiehl_firefox.pdf
CSS Help Sheet outlined.pdf
css-cheat-sheet-v2.pdf
css-cheat-sheet.pdf
CSS3 Help Sheet outlined.pdf
css3-cheat-sheet.pdf
dan-schmidt_jquery-utility-functions-type-testing.pdf
danielschmitz_jquery-mobile.pdf
davechild_css2.pdf
davechild_html-character-entities.pdf
davechild_javascript.pdf
davechild_linux-command-line.pdf
davechild_mod-rewrite.pdf
davechild_regular-expressions.pdf
dimitrios_coffeescript-cheat-sheet.pdf
gelicia_sublime-text-2-shortcuts-verbose-mac.pdf
Git_Cheat_Sheet_grey.pdf
heroku_cheatsheet.pdf
HTML Help Sheet 02.pdf
html5-cheat-sheet.pdf
i3quest_jquery.pdf
javascript_refererence.pdf
javascript-cheat-sheet-v1.pdf
JavaScript-DOM-Cheatsheet.pdf
javascriptcheatsheet.pdf
jQuery-1_3-Visual-Cheat-Sheet.pdf
Mac_Glyphs_All.pdf
Node Help Sheet.pdf
PHP Help Sheet 01.pdf
pyro19d_javascript.pdf
rgb-hex-cheat-sheet-v1.pdf
salesforce_git_developer_cheatsheet.pdf
samcollett_git.pdf
sanoj_web-programming.pdf
SEO_Web_Developer_Cheat_Sheet.pdf
skrobul_sublime-text-2-linux.pdf
WordPress-Help-Sheet.pdf
Help Sheets.zip
JavaScript is only able to handle integers up to 53-bit in size, here is a script to decrease tweet ID which is a 64-bit number in JavaScript without libraries or recursion, to use with max_id or since_id in Twitter API
As some of you might know, JavaScript is only able to handle integers up to 53-bit in size. This post, Working with large integers in JavaScript (which is a part of Numbers series) does a great job at explaining general concepts on dealing with large numbers in JS.
I had to do some research on the topic when I was re-writing some JavaScript code responsible for handling Twitter search in Storify editor: we had tweet duplicates in results! In this article, Working with Timelines, Twitter official documentation says:
Environments where a Tweet ID cannot be represented as an integer with 64 bits of precision (such as JavaScript) should skip this step.
So true, because id and id_str fields in a Twitter API response were different. Apparently, JavaScript engine just “rounds” inappropriately large numbers. :-( The task was complicated by the fact that I needed to subtract 1 from the last tweet’s ID to prevent its reappearance in a second search response. After the subtraction I could have easily passed the value to max_id parameter of Twitter API.
I’ve come across different solutions, but decided to write my own function which is simple to understand and not heavy on resources. Here is a script to decrease tweet ID which is a 64-bit number in JavaScript without libraries or recursion, to use with max_id or since_id in Twitter API:
function decStrNum (n) {
n = n.toString();
var result=n;
var i=n.length-1;
while (i>-1) {
if (n[i]==="0") {
result=result.substring(0,i)+"9"+result.substring(i+1);
i --;
}
else {
result=result.substring(0,i)+(parseInt(n[i],10)-1).toString()+result.substring(i+1);
return result;
}
}
return result;
}
To check if it works, you can run these logs:
console.log("290904187124985850");
console.log(decStrNum("290904187124985850"));
console.log("290904187124985851");
console.log(decStrNum("290904187124985851"));
console.log("290904187124985800");
console.log(decStrNum("290904187124985800"));
console.log("000000000000000001");
console.log(decStrNum("0000000000000000001"));
Alternative solution which I’ve found in a StackOverflow question was suggested by Bob Lauer, but it involves recursion and IMHO is more complicated:
function decrementHugeNumberBy1(n) {
// make sure s is a string, as we can't do math on numbers over a certain size
n = n.toString();
var allButLast = n.substr(0, n.length - 1);
var lastNumber = n.substr(n.length - 1);
if (lastNumber === "0") {
return decrementHugeNumberBy1(allButLast) + "9";
}
else {
var finalResult = allButLast + (parseInt(lastNumber, 10) - 1).toString();
return trimLeft(finalResult, "0");
}
}
function trimLeft(s, c) {
var i = 0;
while (i < s.length && s[i] === c) {
i++;
}
return s.substring(i);
}
Now, if you’re the type of person who likes to shoot sparrows with a howitzer, there are full-blown libraries to handle operations on large numbers in JavaScript; just to name a few: BigInteger, js-numbers and javascript-bignum.
Recently one of our top users complained that their Storify account is unaccessible. We’ve checked the production database and it appeared to be that the account might have been compromised and maliciously deleted by somebody using user’s account credentials. Thanks for a great MongoHQ service we had a backup database in less than 15 minutes.
Recently one of our top users complained that their Storify account was unaccessible. We’ve checked the production database and it appeares to be that the account might have been compromised and maliciously deleted by somebody using user’s account credentials. Thanks to a great MongoHQ service, we had a backup database in less than 15 minutes.
There were two options to proceed with the migration:
Because Storify user account deletion involves deletion of all related objects — identities, relationships (followers, subscriptions), likes, stories — we’ve decided to proceed with the latter option. It worked perfectly, and here is a simplified version which you can use as a boilerplate for MongoDB migration (also at gist.github.com/4516139).
Let’s load all the modules we need: Monk, Progress, Async, and MongoDB:
var async = require('async');
var ProgressBar = require('progress');
var monk = require('monk');
var ObjectId=require('mongodb').ObjectID;
By the way, made by LeanBoost, Monk is a tiny layer that provides simple yet substantial usability improvements for MongoDB usage within Node.JS.
Monk takes connection string in the following format:
username:password@dbhost:port/database
So we can create the following objects:
var dest = monk('localhost:27017/storify_localhost');
var backup = monk('localhost:27017/storify_backup');
We need to know the object ID which we want to restore:
var userId = ObjectId(YOUR-OBJECT-ID);
This is a handy restore function which we can reuse to restore objects from related collections by specifying query (for more on MongoDB queries go to post Querying 20M-Record MongoDB Collection. To call it, just pass a name of the collection as a string, e.g., "stories"
and a query which associates objects from this collection with your main object, e.g., {userId:user.id}
. The progress bar is needed to show us nice visuals in the terminal.
var restore = function(collection, query, callback){
console.info('restoring from ' + collection);
var q = query;
backup.get(collection).count(q, function(e, n) {
console.log('found '+n+' '+collection);
if (e) console.error(e);
var bar = new ProgressBar('[:bar] :current/:total :percent :etas', { total: n-1, width: 40 })
var tick = function(e) {
if (e) {
console.error(e);
bar.tick();
}
else {
bar.tick();
}
if (bar.complete) {
console.log();
console.log('restoring '+collection+' is completed');
callback();
}
};
if (n>0){
console.log('adding '+ n+ ' '+collection);
backup.get(collection).find(q, { stream: true }).each(function(element) {
dest.get(collection).insert(element, tick);
});
} else {
callback();
}
});
}
Now we can use async to call the restore function mentioned above:
async.series({
restoreUser: function(callback){ // import user element
backup.get('users').find({_id:userId}, { stream: true, limit: 1 }).each(function(user) {
dest.get('users').insert(user, function(e){
if (e) {
console.log(e);
}
else {
console.log('resored user: '+ user.username);
}
callback();
});
});
},
restoreIdentity: function(callback){
restore('identities',{
userid:userId
}, callback);
},
restoreStories: function(callback){
restore('stories', {authorid:userId}, callback);
}
}, function(e) {
console.log();
console.log('restoring is completed!');
process.exit(1);
});
The full code is available at gist.github.com/4516139 and here:
var async = require('async');
var ProgressBar = require('progress');
var monk = require('monk');
var ms = require('ms');
var ObjectId=require('mongodb').ObjectID;
var dest = monk('localhost:27017/storify_localhost');
var backup = monk('localhost:27017/storify_backup');
var userId = ObjectId(YOUR-OBJECT-ID); // monk should have auto casting but we need it for queries
var restore = function(collection, query, callback){
console.info('restoring from ' + collection);
var q = query;
backup.get(collection).count(q, function(e, n) {
console.log('found '+n+' '+collection);
if (e) console.error(e);
var bar = new ProgressBar('[:bar] :current/:total :percent :etas', { total: n-1, width: 40 })
var tick = function(e) {
if (e) {
console.error(e);
bar.tick();
}
else {
bar.tick();
}
if (bar.complete) {
console.log();
console.log('restoring '+collection+' is completed');
callback();
}
};
if (n>0){
console.log('adding '+ n+ ' '+collection);
backup.get(collection).find(q, { stream: true }).each(function(element) {
dest.get(collection).insert(element, tick);
});
} else {
callback();
}
});
}
async.series({
restoreUser: function(callback){ // import user element
backup.get('users').find({_id:userId}, { stream: true, limit: 1 }).each(function(user) {
dest.get('users').insert(user, function(e){
if (e) {
console.log(e);
}
else {
console.log('resored user: '+ user.username);
}
callback();
});
});
},
restoreIdentity: function(callback){
restore('identities',{
userid:userId
}, callback);
},
restoreStories: function(callback){
restore('stories', {authorid:userId}, callback);
}
}, function(e) {
console.log();
console.log('restoring is completed!');
process.exit(1);
});
To launch it, run npm install/update and change hard-coded database values.
Free sample chapter of Rapid Prototyping with JS which is a hands-on book which introduces you to rapid software prototyping using the latest cutting-edge web and mobile technologies including NodeJS, MongoDB, BackboneJS, Twitter Bootstrap, LESS, jQuery, Parse.com, Heroku and others.
Rapid Prototyping with JS is a hands-on book which introduces you to rapid software prototyping using the latest cutting-edge web and mobile technologies including NodeJS, MongoDB, BackboneJS, Twitter Bootstrap, LESS, jQuery, Parse.com, Heroku and others.
Here is a free sample, first chapter — Introduction, of Rapid Prototyping with JS. You can also get a free PDF from LeanPub and explore code examples at github.com/azat-co/rpjs. To buy a full version in PDF, Mobi/Kindle and ePub/iPad formats go to leanpub.com/rapid-prototyping-with-js.
Rapid Prototyping with JS is a hands-on book which introduces you to rapid software prototyping using the latest cutting-edge web and mobile technologies including Node.js, MongoDB, Twitter Bootstrap, LESS, jQuery, Parse.com, Heroku and others.
The book is designed for advanced-beginner and intermediate level web and mobile developers: somebody who has just started programming and somebody who is an expert in other languages like Ruby on Rails, PHP, and Java and wants to learn JavaScript and Node.js.
Rapid Prototyping with JS, as you can tell from the name, is about taking your idea to a functional prototype in the form of a web or a mobile application as fast as possible. This thinking adheres to the Lean Startup methodology; therefore, this book would be more valuable to startup founders, but big companies’ employees might also find it useful, especially if they plan to add new skills to their resume.
Mac OS X or UNIX/Linux systems are highly recommended for this book’s examples and for web development in general, although it’s still possible to hack your way on a Windows-based system.
Some cloud services require users’ credit/debit card information even for free accounts.
Expect a lot of coding and not much of a theory. All the theory we cover is directly related to some of the practical aspects and essential for better understanding of technologies and specific approaches in dealing with them, e.g., JSONP and cross-domain calls.
In addition to coding examples, the book covers virtually all setup and deployment step-by-step.
You’ll learn on the example of Message Board web/mobile applications starting with front-end components. There are a few versions of these applications, but by the end we’ll put front-end and back-end together and deploy to production environment. The Message Board application contains all the necessary components typical for a basic web app, and will give you enough confidence to continue developing on your own, apply for a job/promotion or build a startup!
This is a digital version of the book, so most of the links are hidden just like on any other web page, e.g., jQuery instead of http://jquery.com. The content of the book has local hyperlinks which allow you to jump to any section.
All the source code for examples used in this book is available in the book as well as in a public GitHub repository github.com/azat-co/rpjs. You can also download files as a ZIP archive or use Git to pull them. More on how to install and use Git will be covered later in the book. The source code files, folder structure and deployment files are supposed to work locally and/or remotely on PaaS solutions, i.e., Windows Azure and Heroku, with minor or no modifications.
This is what source code blocks look like:
var object = {};
object.name = "Bob";
Terminal commands have a similar look but start with dollar sign, $:
$ git push origin heroku
$ cd /etc/
$ ls
Inline filenames, path/folder names, quotes and special words/names are italicized while command names, e.g., mongod, and emphasized words, e.g., Note, are bold.
The bigger picture of web and mobile application development consists of the following steps:
Mobile applications act in the same manner as regular websites, only instead of a browser there might be a native app. Other minor differences include: data transfer limitation due to carrier bandwidth, smaller screens, and the more efficient use of the local storage.
There are a few approaches to mobile development, each with its own advantages and disadvantages:
Hyper Text Markup Language, or HTML, is not a programming language in itself. It is a set of markup tags which describes the content and presents it in a structured and formatted way. HTML tags consist of a tag name inside of the angle brackets (<>). In most cases tags surround the content with the end tag having forward slash before the tag name.
In this example each line is an HTML element:
<h2>Overview of HTML</h2>
<div>HTML is a ...</div>
<link rel="stylesheet" type="text/css" href="style.css" />
The HTML document itself is an element of html tag and all other elements are children of that html tag:
<!DOCTYPE html>
<html lang="en">
<head>
<link rel="stylesheet" type="text/css" href="style.css" />
</head>
<body>
<h2>Overview of HTML</h2>
<p>HTML is a ...</p>
</body>
</html>
There are different flavors and versions of HTML, e.g., DHTML, XHTML 1.0, XHTML 1.1, XHTML 2, HTML 4, HTML 5. This article does a good job of explaining the differences — Misunderstanding Markup: XHTML 2/HTML 5 Comic Strip.
More information is available at Wikipedia and w3schools.
Cascading Style Sheets, or CSS, is a way to format and present content. An HTML document can have several stylesheets with the tag link as in previous examples or style tag:
<style>
body {
padding-top: 60px; /* 60px to make some space */
}
</style>
Each HTML element can have id and class attribute:
<div id="main" class="large">Lorem ipsum dolor sit amet, Duis sit amet neque eu.</div>
In CSS we access elements by their id, class, tag name and in some edge cases by parent-child relationship or element attribute value:
p {
color:#999999;
}
div#main {
padding-bottom:2em;
padding-top:3em;
}
.large {
font-size:14pt;
}
body > div {
display:none;
}
input[name="email"] {
width:150px;
}
More information for further reading is available at Wikipedia and w3schools.
CSS3 is an upgrade to CSS which includes new ways of doing things such as rounded corners, borders and gradients, which were possible in regular CSS only with the help of PNG/GIF images and by using other tricks.
For more information refer to CSS3.info, w3school
and CSS3 vs CSS comparison article on Smashing.
JavaScript was started in 1995 at Netscape as LiveScript. It has the same relationship with Java as a hamster and a ham :)
It is used for both client and server side development as well as in desktop applications.
There is a script tag to use JavaScript in the HTML document:
<script type="text/javascript" language="javascript>
alert("Hello world!");
//simple alert dialog window
</script>
Usually it a good idea to separate JavaScript code from HTML; in this example we include app.js file:
<script src="js/app.js" type="text/javascript" language="javascript" />
Here are the main types of JavaScript objects/classes:
var arr = ["apple", "orange", 'kiwi"];
var bool = true;
var d = new Date();
var x = Math.floor(3.4890);
var num = 1;
var str = "some string";
var pattern = /[A-Z]+/;
NaN
window.location = 'http://google.com';
var table = document.createElement('table');
Full JavaScript and DOM objects and classes reference with examples are available at w3school.
Typical syntax for function declaration:
function Sum(a,b) {
var sum = a+b;
return sum;
}
console.log(Sum(1,2));
Functions in JavaScript are first-class citizens due to functional programming nature of the language. Therefore functions can be used as other variables/objects; for example, functions can be passed to other functions as arguments:
var f = function (str1){
return function(str2){
return str1+' '+str2;
};
};
var a = f('hello');
var b = f('goodbye');
console.log((a('Catty'));
console.log((b('Doggy'));
JavaScript has a loose/weak typing, as opposed to strong typing in languages like C and Java, which makes JavaScript a better programming language for prototyping.
More information about browser-run JavaScript is available at Wikipedia and w3schools.
Agile software development methodology evolved due to the fact that traditional methods, like Waterfall, weren’t good enough in situations of high unpredictability, i.e., when the solution is unknown. Agile methodology includes Scrum/Sprint, Test-Driven Development, Continuous Deployment, Paired Programming and other practical techniques many of which were borrowed from Extreme Programming.
In regard to the management, Agile methodology uses Scrum approach. More about Scrum can be read at:
Scrum methodology is a sequence of short cycles, and each cycle is called sprint. One sprint usually lasts from one to two weeks. Sprint starts and ends with sprint planning meeting where new tasks can be assigned to team members. New tasks cannot be added to the sprint in progress; they can be added only at the sprint meetings.
An essential part of the Scrum methodology is the daily scrum meeting, hence the name. Each scrum is a 5–15 minutes long meeting which is often conducted in the hallways. On scrum meetings each team member answers three questions:
Flexibility makes Agile an improvement over Waterfall methodology, especially in situations of high uncertainty, i.e., startups.
Advantage of Scrum methodology: effective where it is hard to plan ahead of the time, and also in situations where a feedback loop is used as a main decision-making authority.
Test-Driven Development, or TDD, consists of following steps:
Advantages of Test-Driven Development:
Continuous Deployment, or CD, is the set of techniques to rapidly deliver new features, bug fixes, and enhancements to the customers. CD includes automated testing and automated deployment. By utilizing Continuous Deployment the manual overheard is decreased, and the feedback loop time is minimized. Basically, the faster developer can get the feedback from the customers, the sooner the product can pivot, which leads to more advantages over the competition. Many startups deploy multiple times in a single day in comparison to the 6–12 month release cycle which is still typical for corporations and big companies.
One of the most popular solutions for CD is Continuous Integration server Jenkins.
Advantages of Continuous Deployment approach: decreases feedback loop time and manual labor overhead.
Pair Programming is a technique when two developers work together on one machine. One of the developers is a driver and the other is observer. The driver writes the code and the observer watches it, assists, and makes suggestions. Then they switch the roles. The driver has a more tactical role of focusing on the current task. In contrast, the observer has a more strategic role overseeing “the bigger picture,” and the ways to improve the codebase and to make it more efficient.
Advantages of Paired Programming:
Node.js is an event-driven asynchronous I/O server-side technology for building scalable and efficient web servers. Node.js consists of Google’s V8 JavaScript engine.
The purpose and use of Node.js is similar to Twisted for Python and EventMachine for Ruby. The JavaScript implementation of Node was the third one after attempts at using the Ruby and C++ programming languages.
Node.js is not in itself a framework like Ruby on Rails; it’s more comparable to the pair PHP+Apache. Here are some of Node.js frameworks: Express, Meteor, Tower.js, Railsway JS, Geddy, Derby.
Advantages of using NodeJS:
For more information go to Wikipedia, Nodejs.org, and articles on ReadWrite and O’Reilly.
MongoDB, from huMONGOus, is a high-performance no-relationship database for huge data. NoSQL concept came out when traditional Relational Database Management Systems, or RDBMS, were unable to meet the challenges of huge amounts of data.
Advantages of using MongoDB:
Could computing consists of:
Cloud application platforms provide:
$ git push
;PaaS are ideal for prototyping, building minimal viable products (MVP) and for early stage startups in general.
Here is the list of most popular PaaS solutions:
Each HTTP Request and Response consists of the following components:
In addition, HTTP Request contains:
RESTful (REpresentational State Transfer) API became popular due to the demand in distributed systems where each transaction needs to include enough information about the state of the client. In a sense this standard is stateless because no information about the clients’ state is stored on the server, thus making it possible for each request to be served by a different system.
Distinct characteristics of RESTful API:
Here is an example of simple Create, Read, Update and Delete (CRUD) REST API for Message Collection:
Method | URL | Meaning |
---|---|---|
GET | /messages.json | Return list of messages in JSON format |
PUT | /messages.json | Update/replace all messages and return status/error in JSON |
POST | /messages.json | Create new message and return its id in JSON format |
GET | /messages/{id}.json | Return message with id {id} in JSON format |
PUT | /messages/{id}.json | Update/replace message with id {id}, if {id} message doesn’t exists create it |
DELETE | /messages/{id}.json | Delete message with id {id}, return status/error in JSON format |
REST is not a protocol; it is an architecture in the sense that it’s more flexible than SOAP, which is a protocol. Therefore, REST API URLs could look like /messages/list.html
or /messages/list.xml
in case we want to support these formats.
PUT and DELETE are idempotent methods, which means that if the server receives two or more similar requests, the end result will be the same.
GET is nullipotent and POST is not idempotent and might affect state and cause side-effects.
Further reading on REST API at Wikipedia and A Brief Introduction to REST article.
This past weekend was a very productive one for me, because I’ve started to work on and released my book’s one-page website —rapidprototypingwithjs.com. I’ve used Wintersmith to learn something new and to ship fast. Wintersmith is a Node.js static site generator. It greatly impressed me with flexibility and ease of development. In addition I could stick to my favorite tools such as Markdown, Jade and Underscore.
This past weekend was a very productive one for me, because I’ve started to work on and released my book’s one-page website —rapidprototypingwithjs.com. I’ve used Wintersmith to learn something new and to ship fast. Wintersmith is a Node.js static site generator. It greatly impressed me with flexibility and ease of development. In addition I could stick to my favorite tools such as Markdown, Jade and Underscore.
Here is a good article on why using a static site generator is a good idea in general, An Introduction to Static Site Generators. It basically boils down to a few main things:
You can use template engine such as Jade. Jade uses whitespaces to structure nested elements and its syntax is similar to Ruby on Rail’s Haml markup.
I’ve copied markdown text from my book’s Introduction chapter and used it without any modifications. Wintersmith comes with marked parser by default. More on why Markdown is great in my old post, Markdown Goodness.
Everything is HTML, CSS and JavaScript so you just upload the files with FTP client, e.g., Transmit by Panic or Cyberduck.
Due to the fact that any static web server will work well, there is no need for Heroku or Nodejitsu PaaS solutions, or even PHP/MySQL hosting.
There are no database calls, no server-side API calls, no CPU/RAM overhead.
Wintersmith allows for different plugins for contents and templates and you can even write you own plugin.
There is a quick getting started guide on github.com/jnordberg/wintersmith.
To install Wintersmith globally, run NPM with -g and sudo:
$ sudo npm install wintersmith -g
Then run to use default blog template:
$ wintersmith new <path>
or for empty site:
$ wintersmith new <path> -template basic
or use a shortcut:
$ wintersmith new <path> -T basic
Similar to Ruby on Rails scaffolding Wintersmith will generate a basic skeleton with contents and templates folders. To preview a website, run these commands:
$ cd <path>
$ wintersmith preview
$ open http://localhost:8080
Most of the changes will be updates automatically in the preview mode except for the config.json file.
Images, CSS, JavaScript and other files go into contents folder.
Wintersmith generator has the following logic:
When you’re done with your static site, just run:
$ wintersmith build
Here are some of the other Node.js static site generators:
More detailed overview of these static site generators is available in the post, Node Based Static Site Generators.
For other languages and frameworks like Rails and PHP take a look at Static Site Generators by GitHub Watcher Count and the “mother of all site generator lists”.
Storify saves a lot of meta data about social elements: tweets, Facebook status updates, blog posts, news articles, etc. MongoDB is great for storing such unstructured data but last week I had to fix some inconsistency in 20-million-record Elements collection.
Storify saves a lot of meta data about social elements: tweets, Facebook status updates, blog posts, news articles, etc. MongoDB is great for storing such unstructured data but last week I had to fix some inconsistency in 20-million-record Elements collection.
The script was simple: find elements, see if there are no dependencies, delete orphan elements, neveretheless it was timing out or just becoming unresponsive. After a few hours of running different modifications I came up with the working solution.
Here are some of the suggestions when dealing with big collections on Node.js + MongoDB stack:
Interactive shell, or mongo, is a good place to start. To launch it, just type mongo in your terminal window:
$ mongo
Assuming you have correct paths set-up during your MongoDB installation, the command will start the shell and present angle brace.
>
To execute JavaScript file in a Mongo shell run:
$ mongo fix.js --shell
Queries look the same:
db.elements.find({...}).limit(10).forEach(printjson);
To output results use:
print();
or
printjson();
To connect to a database:
db = connect("<host>:<port>/<dbname>")
Separate your query into a few scripts with smaller queries. You can output each script to a file (as JSON or CSV) and then look at the output and see if your script is doing what it is actually supposed to do.
To execute JavaScript file (fix.js) and output results into another file (fix.txt) instead of the screen, use:
$ mongo fix.js > fix.txt --shell
or
$ mongo --quiet fix.js > fix.txt --shell
Simply run count() to see the number of elements in the collection:
db.collection.count();
or a cursor:
db.collection.find({…}).count();
You can apply limit() function to your cursor without modifying anything else in a script to test the output without spending too much time waiting for the whole result.
For example:
db.find({…}).limit(10).forEach(function() {…});
or
db.find({…}).limit(1).forEach(function() {…});
is better than using:
db.findOne({…})
because findOne() returns single document while find() and limit() still returns a cursor.
hint() index will allow you to manually use particular index:
db.elemetns.find({…}).hint({active:1, status:1, slug:1});
Make sure you have actual indexes with ensureIndex():
db.collection.ensureIndex({…})
Use additional criteria such as $ne, $where, $in, e.g.:
db.elements.find({ $and:[{type:'link'}
,{"source.href":{$exists:true}}
,{'date.created':{$gt: new Date("November 30 2012")}}
,{$where: function () {
if (this.meta&&this.data&&this.data&&this.data.link) {
return this.meta.title!=this.data.link.title;
} else {
return false;
}}}
, {'date.created': {$lt: new Date("December 2 2012")}}]}).forEach(function(e, index, array){
print(e._id.str);
});
Last week I joined Storify — a destination for curated social media news. Storify helps you sort through the noise to find the voices online that matter.
Last week I joined Storify — a destination for curated social media news. Storify helps you sort through the noise to find the voices online that matter. To find more about Storify take a look at the guided tour.
Storify co-founder Burt and I met a couple months ago for the first time and I’m glad that we did. There were three main reasons for me to come on board: great team, awesome product and company vision, and cool tech stack that I’m passionate about: Node.js+Express+MongoDB.
The first week at Storify exceeded my expectations! So far there were: 4 team lunches, one birthday party, two (!) break-ins. In addition, I’ve worked on the front-page on my second day and had a chance to SSH to production servers.
A few word about the office, besides free snacks and espresso and being close to everything, there are two other startups, Buffer and HomeLight. The funny thing is that I’ve discovered and fallen in love with Buffer just a few weeks ago and now I’ve met with Leo and sit next to their brilliant team!
By the way, Storify is hiring bright minds: Operations Engineer and Front-End Engineer. If you want to do work on interesting things check out full job description.
Rapid Prototyping with JS is a hands-on book which introduces you to rapid software prototyping using the latest cutting-edge web and mobile technologies including NodeJS, MongoDB, BackboneJS, Twitter Bootstrap, LESS, jQuery, Parse.com, Heroku and others.
Rapid Prototyping with JS is a hands-on book which introduces you to rapid software prototyping using the latest cutting-edge web and mobile technologies including NodeJS, MongoDB, BackboneJS, Twitter Bootstrap, LESS, jQuery, Parse.com, Heroku and others.
The book has 84 pages (in PDF format) or 13,616 words to be precise, step-by-step set-up, best practice advices, web development overview, 11 code examples (also available ready-to-go in GitHub repository azat-co/rpjs), flexible pricing ($9.99–19.99).
Order your copy of Rapid Prototyping with JS at LeanPub: leanpub.com/rapid-prototyping-with-js.
LeanPub platform allows readers to receive infinite future updates (current version of the book is 0.3) and read the book in the most popular digital formats: PDF, ePub/iPad, MOBI/Kindle. The PDF version has footnote links which make it suitable for printing.
Download a free sample at samples.leanpub.com/rapid-prototyping-with-js-sample.pdf.
Rapid Prototyping with JS is being successfully used at StartupMonthly as a training manual. Here are some of our trainees’ testimonials:
“Thanks a lot to all and special thanks to Azat and Yuri. I enjoyed it a lot and felt motivated to work hard to know these technologies.” — Shelly Arora
“Thanks for putting this workshop together this weekend… what we did with Bootstrap + Parse was really quick & awesome.” — Mariya Yao
“Thanks Yuri and all of you folks. It was a great session – very educative, and it certainly helped me brush up on my Javascript skills. Look forward to seeing/working with you in the future.” — Sam Sur
The book is designed for advanced-beginner and intermediate level web and mobile developers: somebody who has just started programming and somebody who is an expert in other languages like Ruby on Rails, PHP, and Java and wants to learn JavaScript and Node.js.
Rapid Prototyping with JS, as you can tell from the name, is about taking your idea to a functional prototype in the form of a web or a mobile application as fast as possible. This thinking adheres to the Lean Startup methodology. Therefore, this book would be more valuable to startup founders, but big companies’ employees might also find it useful, especially if they plan to add new skills to their resume.
Mac OS X or UNIX/Linux systems are highly recommended for this book’s examples and for web development in general, although it’s still possible to hack your way on a Windows-based system.
Acknowledgment
Introduction
Getting Started
Building Front-End Application
Building “Hello World” in NodeJS
Putting it All Together
Further Reading
About the Author
Order your copy of Rapid Prototyping with JS at LeanPub: leanpub.com/rapid-prototyping-with-js.
A lot of people like to pick my brain on technical things related to early stage startups, e.g., what framework to use, how long will it take to build an app or a website, should I hire or outsource. I decided to organize my answers to the most common technical questions in this post:
A lot of people like to pick my brain on technical things related to early stage startups, e.g., what framework to use, how long will it take to build an app or a website, should I hire or outsource. I decided to organize my answers to the most common technical questions in this post:
Best of the web goodies for agile web development, startups and Lean Startup startups:
If you like this post and want to lean more about building your web or mobile app using the latest tech and agile practices check out my new book on how to take your idea to a prototype with JavaScript, Node.js and MongoDB — Rapid Prototyping with JS.
If you use Ruby on Rails, Django or NodeJS frameworks on the same domains they have special folders, usually called static, public or assets. But what if you what deploy just “static” file which are usually not so static, by they way.
Heroku uses Cedar stack as an application creation tool and it doesn’t support flat-out deployment of static files such as HTML, CSS or JavaScript, unless they come with some server-side language, e.g, PHP, Ruby, Python. This might come in handy if you are using front-end applications build with jQuery or BackboneJS framework and services like Parse.com or Firebase.com or consume your own back-end deployed as a different application on different instance and/or domain.
There are multiple ways to trick Heroku and Cedar into thinking that your HTML, CSS and JavaScript files are PHP or Ruby on Rails, or any other legitimate Cedar stack, applications. Here is the simplest way is to create index.php file in your project folder, on the same level as your .git folder. You can do this in terminal with this command:
$ touch index.php
Then we turn off PHP with .htaccess directive. You can add line to .htaccess and create it with this terminal command:
$ echo 'php_flag engine off' > .htaccess
This two terminal command will create empty index.php file and .htaccess file which turns PHP off. This solution was discovered by Kenneth Reitz.
Another approach is less elegant but also involves PHP. Create file index.php on the same level as index.html in the project folder which you would like to publish/deploy to Heroku with the following content:
<?php echo file_get_contents('index.html'); ?>
Third way is to use Ruby and Ruby Bamboo stack. In this case, we would need the following structure:
-project folder config.ru /public index.html /css app.js ...
The path in index.html to CSS and other assets should be relative. i.e. ‘css/style.css’. The config.ru file should contain the following code:
use Rack::Static, :urls => ["/stylesheets", "/images"], :root => "public" run lambda { |env| [ 200, { 'Content-Type' => 'text/html', 'Cache-Control' => 'public, max-age=86400' }, File.open('public/index.html', File::RDONLY) ] }
For more details, you could refer to official Bamboo Heroku documentation.
Last but not least, for Python and Django developers, you could add following to your urls.py:
urlpatterns += patterns(”, (r’^static/(?P.*)$’, ‘django.views.static.serve’, {‘document_root’: settings.STATIC_ROOT}),)
Or with this Procfile line:
web: python my_django_app/manage.py collectstatic --noinput; bin/gunicorn_django --workers=4 --bind=0.0.0.0:$PORT my_django_app/settings.py
The full Django post is at Managing Django Static Files on Heroku.
If you use NodeJS, here is how to write your own server:
var http = require("http"), url = require("url"), path = require("path"), fs = require("fs") port = process.argv[2] || 8888; http.createServer(function(request, response) { var uri = url.parse(request.url).pathname , filename = path.join(process.cwd(), uri); path.exists(filename, function(exists) { if(!exists) { response.writeHead(404, {"Content-Type": "text/plain"}); response.write("404 Not Found\n"); response.end(); return; } if (fs.statSync(filename).isDirectory()) filename += '/index.html'; fs.readFile(filename, "binary", function(err, file) { if(err) { response.writeHead(500, {"Content-Type": "text/plain"}); response.write(err + "\n"); response.end(); return; } response.writeHead(200); response.write(file, "binary"); response.end(); }); }); }).listen(parseInt(port, 10)); console.log("Static file server running at\n => http://localhost:" + port + "/\nCTRL + C to shutdown");
Traditional Computer Science education sucks big time when it comes to modern agile technologies like Ruby on Rails, Django, NodeJS, and NoSQL databases. Last time I checked, the maximum that was offered were classes in Web Design I, Web Design II and Photoshop Basics. WTF?! Don’t get me wrong. I have Master’s degree in Information Systems Technology and value fundamentals, but I was never taught anything up-to-date. There was some ASP, some C++, some SQL, but most of my learning I had to do on my own. Sure there are tons information online and in books, but not everybody has time, dedication, focus and self-discipline to master a new technical skill this way. Reading a book or watching a screencast is just not enough. The best learning comes from 25% books, 25% peer-to-peer communication and discussion, 25% student-to-teacher relationship; the last 25% is the time and practice on your own.
I saw a huge need for effective technical trainings and decided to validate my idea. I already had plenty of teaching experience from college years, during which I wrote my first textbook, had it published on a curriculum for my classmates a year later, and from teaching yoga classes. I needed a pilot class, so I approached startup accelerator and fund, StartupMonthly, and offered to develop and teach the “Rapid Prototyping with JavaScript and NodeJS” training.
I chose JavaScript and NodeJS because students will be able to use the same language both for front-end and back-end development. Their brains don’t have to switch thus saving time and speeding the learning process. NodeJS is becoming more and more popular due to its real-time support and I’m very passionate about this technology. The training runs over a long weekend, starting on Friday night with an optional Q&A session on setting up your environment. Then, we have two full days on Saturday and Sunday, making the course 16 hours total. This way, people who have full time jobs don’t have to take time off to attend. The class is very hands-on and, as much as possible, inline with the principles of Flipped Teaching.
The goal was not to make a profit. So we priced the training very aggressively twice or thrice lower than the market price of our competitors in order to attract students. The results were amazing! The goal was to sell at least 10 seats and we had 15 people in our first class! Big thanks to Yuri Rabinovich, killer StartupMonthly team and its vast network of people interested in technology :)
Then the hard work began. In a true spirit of lean startup methodology (hey, this is what we teach, right?) the manual had only a bare minimum of information and was tailored towards intermediate web and JavaScript developers. The majority was doing well, but I couldn’t say that for everyone. This was a good feedback for me, and helped to improve the manual by including many simple steps and additional terminal commands for deployment and Git.
Overall, students were tired, but happy with the number of new technologies they’ve tried. It was sort of a Chinese Buffet of Programming. You don’t have to try everything, you only pick what you want and indulge in it :) Here is the list of topics to give you an idea:
By the end of the weekend, we had 3 teams with 2 to 3 people in each. The teams built or started to build applications using their own ideas. One of them was a remake of Reddit with better UX/UI and the other was a service for angry ex-girlfriends to post (mostly negative I suspect) feedbacks on their ex-boyfriends :)
Here are some testimonials from the students:
“Thanks Yuri and all of you folks. It was a great session – very educative, and it certainly helped me brush up on my Javascript skills. Look forward to seeing/working with you in the future” – Sam Sur.
“Thanks for putting this workshop together this weekend… what we did with Bootstrap + Parse was really quick & awesome” – Mariya Yao.
“Thanks a lot to all and special thanks to Azat and Yuri.
I enjoyed it a lot and felt motivated to work hard to know these technologies” – Shelly Arora.
Next weekend, August 10–12 2012, I’m teaching the second class of “Rapid Prototyping with JavaScript and NodeJS”. I’m exited to share my experience and passion with another 10–20 smart people and make a small dent in technical education!
“Advanced Prototyping with JavaScript and NodeJS” and “Mobile Prototyping with JavaScript” trainings are coming on the weekend of August 25–26 2012. We have other cities like Los Angeles and New York in a pipeline and, (knock on wood) the future for “Rapid Prototyping” series looks very promising .
I’m working on materials for technical workshop. The topic is “Rapid Prototyping with JavaScript”. It is mostly about jQuery, Backbone, AJAX, RESTful APIs, NodeJS and MongoDB. So a lot of JavaScript on a client side and today I was asked a question by curious friend who saw my frequent updates about the event on Facebook:
“What about users who has JavaScript disabled?”
The questions made my smile and I intuitively answered:
“It’s 2012, right? The number of such users must be insignificant”.
And later I proved to be right — only 2% of Yahoo.com users have JavaScript disabled.
Another article shows why Yahoo.com data is a good source. It has almost all of the countries covered so we can get average numbers and numbers per each country.
But I wanted to analyze the change. Just about 5 years ago companies seriously considered not to innovate AJAX-y way so they can please non-JavaScript users. Now, I barely hear about such non-sense. Even the opposite is true – startups limit their environments to only WebKit browsers. What happened to that attitude? How did that happened? One theory is that Chrome and Firefox became more popular and an update to the newer and faster versions became just a click away or even automatic in most (default) cases. JavaScript de-facto became a web standard. Not using JS is a misfit.
I can’t imagine my life without Google Docs, GMail, Facebook chat and other wonderful things which are brought to us but small scripting language which started in 1995 at Netscape as a way to make text blink if not for the XMLHTTPRequest object. Brilliant minds even overcame cross-origin limitation with dynamically injecting script tags into to DOM. This technique is known as JSONP. But that is me — sort of advanced user.
Just a few days ago Adobe announced on 5th anniversary of iPhone release, which never supported Adobe Flash, that they will discontinue support of Flash plug-in in new Android 4.1, Jelly Bean. This event completes triumph of JavaScript as cross platform tool for web and mobile development.
For those unfortunate people (2% of Yahoo.com users) and search engine bots I must remember to put noscript into my HTML:
<noscript> This website is not intended for use with JavaScript disabled. Unless you are a googlebot, telnet or i486-PC user, please go get the latest version of Chrome. </noscript>
One side note: mission critical applications without control over clients’ environment, corporate and government organizations which must try to server all users still have to take into account a lot of things which consumer facing and startup companies could get away with. Being section 508 complaint also falls into this category.
UPDATE: 06/28/2012 Today we received an email from AngelHack.com organizers. FashionMetric was selected to participate in the Grand Finals Demo on July 12. What are the odds? They choose 6 wildcards from over 40. Unbelievable! Main prizes include airfare to Silicon Valley, other team members are in Los Angeles, hotel and other things.
I have been writing code for many years but somehow I managed to avoid hackathons till last weekend. I was wondering why would somebody spend their time and energy, deprive themselves of sleep and stress to deliver half-backed products in such a short time? Yet I’ve heard that it could be fun. When I got email with early bird 75% off code for AngelHack 2012 in San Francisco I didn’t hesitate to register. I’ve heard that it’s one of the biggest and the best hackathons around. Teams from different cities compete with each other using sponsors’ APIs.
On the day of the event I still didn’t have my own team or even any decent idea due to being busy with other things. I thought I can still come and check it out, say “hi” to friends and meet new people. Immediately I was drawn into auditorium on the first floor to hear teams pitch their idea to attract designers and developers. I’ve heard a few good pitches and approached people. One of them was FashionMetric, they won Lean Startup Machine last week in Los Angeles and as a prize got tickets to this hackathon. Nevertheless I liked much simpler idea after I realized that it could be done in 24 hours and I decided to give it a try. Too bad there was only high-carb breakfast food and when I came back after lunch in downtown Palo Alto my team disassembled and their members split to contribute to other teams. Gladly, FashionMetric still needed developer so I joined them and was very glad that I did later!
I’ve noticed that there is clear separation between veterans of hackathons and just random curious folks. Former group bring sleeping bags, support teams, supplies, tooth brushes. They have strong teams of long time friends, know sponsors, their tech stack and stay heads down coding and hacking mostly all night. Latter group tends to be more individualistic, leave early to catch the last train back to San Francisco and seem to be less dedicated. I think there is nothing wrong with being casual but it could be distracting to more focused team members. We had funny situation when our designer disappeared leaving her laptop, food and 7th cup of beer on the table (she drank the previous 6). The AOL building provides many places to crash, in fact it’s the same building where startuper lived for free for 2 month escaping from security while building his prototype. She was nowhere to be found and our biz people, respect to them, had to master Photoshop, HTML and CSS to speed up our development :)
A few word about organizers. They were up all night bringing pizza, drink and normal food. They re-tweeted and responded to tweets quickly. I’ve seen somebody on Hackathon.io complaining about how they didn’t enforce rules of the hackathon: to limit development time to 24 hours, not to use code developed before the event, etc. but I’m personally not aware of bad were the violations.
Overall, despite the fact that our team, FashionMetric didn’t pass into second round I had fun working with awesome people. I was impressed by the amount of work we were able to accomplish, dedication and focus. Because we had everything brought and catered to us, even chair massage, we could concentrate on work. I think hackathons are good to test team, idea or even learn something cool like Firebase – I finally got beta invite! In addition we used Windows Azure cloud servers and BackboneJS as our thick MVC client framework.