As projects for the new year have started to roll in, I’ve noticed some trends in how web sites and applications are built and how they are hosted.

If you’re a one-man shop or a small company, the single most important change is the advent of cloud platforms. If you haven’t been paying attention the last few years, it’s about time. Suddenly, you no longer have to worry about system administration. Platforms such as Heroku and Google’s AppEngine might not be the cheapest, but they certainly are helpful in alleviating a lot of the pain of hosting your own web applications.

However, with cloud platforms comes a major change in development: expect failure of even the smallest component and prepare for it.

With this in mind, I foresee two parallel roads in web development:

• Highly dynamic single page apps interfacing with highly distributed stateless JSON REST services. These services scale indefinitely (almost) and are ideal for systems that fail over regularly (remember, no state). Suggested technologies: AngularJS and Backbone.js on the client. Pretty much any lightweight Node.js framework will do. For instance, Express combined with some MongoDB or PostgreSQL host.
• Static SEO optimized read-only content. Ideally for distribution on CDNs. Jekyll is perfect for this. It isn’t anything new, before WordPress, Movable Type was already generating static sites. It’s only common sense, really. But Jekyll puts it into a nice, low-friction package. I haven’t researched the Node options, but Blacksmith, Wintersmith and DocPad look promising.

There will always be an overlap, where the choice won’t be clear. For instance, I can imagine a typical forum, that you want indexed by Google, will be an interesting exercise.

I’d love to learn about your vision for web development in 2013 and beyond. Please join me on Twitter and Facebook.

Also check out the new Getting Started with Web Apps guide.

Another year has (almost) passed. It was a very exiting year, in which I threw a lot against the wall to see what would stick. I also managed to implement most of my 2012 goals, although, in hindsight, they were a little too vague.

2012

Lets go over the goals and plans mentioned in my last review post:

• eLance: I’ve grown extremely tired of the way things work on this type of outsourcing sites. While I will keep helping out my existing customers, I don’t plan on picking up any new ones.
• Java, for me, is a language very quickly moving towards “COBOL status”. Development in Java is slow with an incredible amount of overhead. For no good reason. I did pick up Groovy this year and I’m loving it. While it’s not perfect, I feel it’s a good compromise.
• After some more PHP work, I realized it’s just not for me. The language is a mix of ideas, seemingly randomly thrown together. No matter what I try, I can’t really get used to it. Furthermore, due to the sheer number of PHP developers available, the job market itself is such a mess, where the lowest bidder wins, but you eventually end up cleaning up after him.
• JavaScript was the real eye-opener for me this year. Although I haven’t written too much about it, I’ve done a lot of Node.JS development last year and I still like it. Yes, you need to properly manage callbacks so they don’t turn your code into a mess. But the system works. Node.JS development forces you to think about issues that other languages try to hide (and they really shouldn’t).
• I’ve continued, with mixed success, to market some of my websites. More on that in my 2013 goals.

2013

So what’s in store for 2013? In all honesty, I’m not sure because I have no idea how much time I’ll have for development work.

In any case, I want to work on just a few, but larger projects. Here’s what I’d like to do:

• Jump into the “Big Data” waters. I’ve previously worked with SOLR, but that was just the start.
• Increase revenue for my Vaadin application. I only plan to do major development if and when I hit my revenue goals. If I do, I’d love to move the entire app to a more modern language (Gradle instead of Maven, Groovy instead of Java)
• Improve my Android app and possibly build another one. I have a big idea-file waiting for me, so I will first need to prioritize.
• Ideally, I want to do at least one major Node.JS project, but I’m not sure if I’ll be able to fit that into my schedule.

Enjoy the new year.

Also check out the new Getting Started with Web Apps guide.

After my ebook project, two weeks ago, I created an overhaul of a casual Flash game I wrote for the Ludum Dare #23 competition. It’s available on Kongregate for all the play and comment on. Read on for my experience and lessons learned.

Way back in April, I joined the Ludum Dare 48 hours game competition. The idea of the competition is to create a game, all by yourself, from scratch in 48 hours. Going in, I knew I wasn’t doing this to win, but mostly for the experience.

In hind-side, I’m pretty happy with how the weekend went. The main reason that I was able to complete this game was that I only kept one gameplay element. Ant throughout those 48 hours, I kept reminding myself not to add anything else. It worked and it was a fun weekend.

Kongregate

I choose to put the game on Kongregate, because I find it the best casual game site out there. The community is, in general, very supportive with constructive criticism. And the people behind the site seem to genuinely care about their developers.

That, and there’s some incredible talent over there.

Flash Game

Although it usually isn’t my first choice, I did go for a Flash game. Simply because, at this point in time, it’s the default for casual games. Choosing any other platform but Flash to write your casual game in, is severely limiting yourself and the potential reach of your game.

There are also a wealth of free ActionScript game libraries available. I choose Flixel, which was a good choice, but I did find the documentation was a little lacking.

It’s clear HTML5/JavaScript is the future for casual games, but I’m not sure if it’s already “there”, just yet.

Future

The game has been on Kongregate for about a week, over which it was played almost 800 times and received a 2.34 rating (which is pretty much the definition of an average game).

I’m pretty happy with that, given that I did almost no promotion and the gameplay is rather limited.

The commentary was also acceptable and the criticism as expected.

So I’ve been thinking about either enhancing this game, or creating a 2.0 version.

I love tower defense games and feel that this would be a good direction to enhance the gameplay in. But we’ll see, those ideas will need some extra time to properly form.

Conclusion

Go play the game and let me know what you think.

Also check out the new Getting Started with Web Apps guide.

A well-made video can replace many images and many more words. It’s thus not surprising that publishing videos is a growing trend. But how do you get started in what appears to be an expensive and time-consuming hobby?

Over the last few weeks, I’ve started experimenting with video. I did publish a few videos a while ago with mixed results. My DOSBox screencast gathered a pretty nice amount of views over the years, but I was never happy with the montage and voice. The morph effect demonstration never made any impact. Although it required more time and effort, its purpose wasn’t clear, people are usually searching how to do something, not just a demo.

So, after almost 4 years, it was time to take a second look at video out how to create good quality video within a reasonable time-frame and budget.

Make Videos with Kdenlive

Creating raw video material is actually fairly straightforward these days. However, on the subject of how to cut, combine and make videos, fairly little information is available.

There are a few commercial video editing packages, but they all were way more expensive than what I wanted to pay for an experiment. So I dug up Kdenlive. It’s still well-maintained and has all the options you’ll need.

After all those years, it’s still not available for Windows, which is a shame, but there are a few workarounds. Booting from a memory stick is one way, but I decided to go to my favorite visualization tool VirtualBox.

I have created an image that is freely available. You can download it from my company site (more on that later).

Publishing

After a few takes and a little getting used to Kdenlive, I ended up with this revised DOSBox tutorial. It focuses on going from an old CDROM game somewhere in your closet, to playing it on your computer.

Kindle ebooks

While I was at it, I also used this experiment to try my hands on a Kindle ebook. I used a setup almost identical to what Keith at BIT-101 is using.

I intentionally tried to keep it short and cheap, as not to overwhelm any one trying to get into this. You can buy it on the Amazon Kindle store.

If you are reading this blog, chances are you aren’t going to need the book. You can probably get the image running on your own. And the Kdenlive pages have tutorials and a full manual.

The book is just a focused compilation of just the things you need to get started.

Also check out the new Getting Started with Web Apps guide.

A variation of the servlet that was included with the GitHub repo has been running for almost 2 years on my own AppEngine application. And over that time it has been remarkably reliable (given PayPal’s API), but has also shown some issues. Some minor ones that were easily fixed, but also one major:

Whenever PayPal was down or just a little slow, the serlvet would run into timeout exceptions and would not validate the IPN message and, what was worse, would not process it correctly.

Eventually, I realized this is just part of the day-to-day operations of any application deployed to the cloud, so I’d better clean up my act and start thinking like a cloud developer.

Cloud development = make everything handle errors gracefully and retry on failure.

The first part was easy enough and should have been part of the code from the start. The second required a rethinking of my architecture. I’ve now hooked everything into task queues, which means every part is independent, can be easily retried and does not influence the other parts when it fails.

Small independent parts

There are 3 servlets that interact as follows:

All interaction between the servlets is through a queue. If you haven’t used the task queues on Google’s AppEngine, it’s about time. I too waited too long, but the push queues are an incredible easy way to build fail safety into your application.

You don’t need to worry about retries, as long as the servlet returns anything but a 200-299 status code, AppEngine will keep retrying the call. You can specify how long it should wait before retries and when it should just give up.

Transactions

Because 3 servlets are writing and reading data for the same entity, I also had to make sure every servlet has a consistent view.

Something that isn’t as easy as you might think in the DataStore. It only guarantees eventual consistency. Strong consistency can only be guaranteed in the same entity group. No problem for changing single IPN message, but duplicate checking requires a query over the entire table.

I could create one big entity group for all IPN messages, but that would sort-of defeat the entire purpose of cloud computing. I think I now have a good trade-off with only a very minor risk of duplicates entering the system. Which shouldn’t cause any major issues anyway if your program handles the messages in an idempotent way.

If you know a better way to deal with this, please have a look at the IPNValidationServlet and let me know.

Conclusion

Every one’s feedback has really helped me to improve the previous version of the code, so I hope you try out the new one too and let me know what you think. The readme has all the information to get you started.

Also check out the new Getting Started with Web Apps guide.

After last weeks review of Android in Action, it was inevitable: I just released my first Android app: Discogs Scan. Discogs Scan is a small Android 2.1+ application that allows you to quickly scan the barcodes of all your CDs and records and add it to your discogs.com collection.

It’s my first endeavor into mobile apps and I immediately got hit by some device specific bugs. After a round of debugging I think the application is now fairly stable and ready for general usage.

Discogs Scan

The application itself allows you to quickly scan all your CDs and vinyl. It uses the discogs.com database to find all the details. Once everything is scanned, you can upload it to your personal discogs.com collection, where you can organize it as you see fit.

In my own experiments it has a hitrate of about 85%, which I thought was pretty impressive. Depending on how rare the items in your music collection are, your mileage may vary.

Android Development

In general, I found Android to be very well documented. Even though things tend to move quickly.

Android does carry some of the Java overhead with it. For instance, multi-threaded code can be a hassle because anonymous inner classes aren’t exactly easy on the eye. The Eclipse plugin does help with a few things (like managing resource id’s)

There were a few exceptions were the documentation failed, most notably the “strict mode”. This mode exists to force you to make your code behave better (for instance, it forces you to do all operations it considers resource intensive in threads). According to the official documentation, it’s a development only feature, but it turns out it is enabled on production devices such as the latest Samsung Galaxy’s.

The developer’s console on the Play store was instrumental in debugging this. It gathers crash information. Definitely a big plus to have this available.

Conclusion

I’m definitely planning a few more Android apps. Most of which will be more general and less niche than this one.

But in the meantime, try out Discogs Scan and let me know what you think.

Also check out the new Getting Started with Web Apps guide.

There are many ways to learn to program for the Android platform that powers many smartphones, tablets and other devices. Google offers fairly extensive and free tutorials and documentation. So why would you want to buy and read a book? Read on for my Android in Action review.

One of my long-term goals has been to get into mobile development. I’ve always liked the idea of reusing my existing Java knowledge and really learn Android. I used the second edition of Android in Action to give me a quick start.

Android 2

First things first, you may be wondering why bother with a book that only covers Android 2. Android is already up to version 4 now.

If you take a look at the platform distribution dashboard you’ll know why: 2.3.3 has, by far, the largest install base. And I doubt this is going to change soon. Much of the features of the later Android version are simply beyond the possibilities of mobile hardware and are aimed at higher level hardware (like tablets and set top boxes)

Android in Action

After 4 chapters of Android in Action, you’ll be ready for real Android action.

The book consists of a few introductory chapters that focus on a detailed explanation of the Android fundamentals (like intents, activities and services). Afterwards most of the chapters focus on the different parts of the API: notifications, telephony, graphics, etc.

Given that the core of Android is pretty different than the usual Spring/JEE fair, I think the authors made the very wise decision of focusing on it a lot. After you’ve gone over the first 4 chapters, you will have a good understanding of the basics.

Experienced developers will probably only need those first 4 or 5 (on data storage) chapters. Incidentally, if you’ve grown used to the JavaScript and Node.JS event-based and non-blocking way of working, you’ll have a leg up on the other developers.

Part 3, containing chapters 12 and 13 is a little different. These chapters contain an in-depth look at two applications. There’s still some new knowledge in those chapters (especially 13), but these are mainly aimed at applying what was learned in the previous chapters. I found chapter 12 very useful, but I’m not sure if chapter 13 will be useful for many people. But it’s good to know it’s there if I ever need to create low-level apps.

There’s also a full chapter on web development (16) which, although a bit brief, is very timely.

The overall quality of writing is excellent. You will need some experience with Java to get the most out of the book. If you don’t know Java yet, you’ll probably get stuck too much on the example code.

Sample code

The examples in Android in Action give your a taste of most of the Android API

The usage of example code is well chosen and the code does interesting things. The book does not print the entire code, so be sure to download the full example code package before you start.

Many examples integrate various web services and result in pretty impressive apps with little actual development. The disadvantage is that many of the used services are no longer available or have changed their API. There are some limited fixes provided in the book forum, but overall, you’ll be on your own.

But lets talk about chapter 12. I’m not sure what happened there, but it feels like an ActionScript developer was let loose on the Java world. I don’t think I’ve ever seen the use of underscores to indicate private fields in a Java program, but chapter 12 has them. To top that of, there are lower case class names, uppercase method names and underscore-separated names.

I’m not sure what happened there, but although the example was very good, the code style was extremely distracting.

The good

• It covers pretty much everything in the Android 2 SDK, including some stuff that you’re probably never going to need.
• Examples are well chosen and explanation is thorough.

The bad

• Actual code quality of the examples is a mixed bag.
• No in-depth overview of APIs limits the use of the book as a reference.

Also check out the new Getting Started with Web Apps guide.

In this second installment in the series, I’m using my lunch hour to take a look at Meteor. It’s another box filled with all kind of delicious candy that any web app developer will love to use. But is it worth your time?

This article is going to sound a lot like a comparison with the previously reviewed Opa platform. And there’s good reason for that. Meteor is a full stack web application framework. Just as Opa, it comes as a standalone package. Just as Opa, it blurs the distinction between client and server.

Major differences with Opa include: Meteor is absolutely not production ready and Meteor uses JavaScript.

First Impressions

I tried Meteor on a VirtualBox Ubuntu installation. Given the way it is installed, it looks very unlikely that Meteor will run on Windows without a lot of hacking, so I didn’t even bother.

The Meteor site blurs the lines between download and examples. By the time you have installed Meteor, you also have an example app. This feels a little strange at first, “where’s that download link?”, but it’s a pretty good idea to get you started right away.

The examples are good, yet they couldn’t help but implement another multiuser live-update system (not a chat this time, though). Again, I think this is a use case that only a very small percentage of developers will encounter in their lives.

JavaScript All the Way Down

No, not turtles, to develop in Meteor, you’ll only need to know JavaScript.

Unlike Opa, Meteor uses the familiar JavaScript language. Just as Opa, it mixes both server-side and client-side code in the same files. The distinction between client and server is made through a simple “if” test. Meteor.is_client and Meteor.is_server tell you where the code is running.

As far as I understand, most existing JavaScript libraries are re-usable straight away. So while the standard API may be pretty limited, your options will be endless. There are about 10 popular web libraries included by default, Bootstrap and Underscore are a few that I will find useful.

It wasn’t immediately clear from the web pages, but Meteor is build on Node.JS.

Deploying to the Cloud

The built-in examples are a great way to get started right away. However, going over them, I’m a little confused how security works. You can just deploy to any servername you like, so I guess any one can overwrite this “live” version of the program. It’s neat to be able to get started right away, however if you happen to cross paths with some one else using the same name, it’s probably not so much fun.

Reading further it appears it is possible to set a password for the server, but by default there is none. It’s also possible to create a self-contained package that can be deployed to Heroku. Which is nice, although I’m going to need a little more explanation than provided before I can actually deploy it.

Storing and Viewing Data

If you’re used to SQL, you’ll find MongoDB’s API very refreshing.

Meteor’s default datastore is MongoDB and as far as I can see, it directly exposes MongoDB’s JavaScript API. Mongo uses a fairly intuitive interface, so even without experience, you’ll be able to write a simple CRUD application quickly.

Since there’s a lot client/server communications build into the API, it looks like it would be fairly difficult to replace MongoDB with your own choice.

On the view side, Meteor comes with Handlebars built in. It has a neat and very clean way of using helper functions to connect the template variables and events to the controller code. You can replace Handlebars with your choice of templating framework, but I see very little reason to.

Wrapping Up

Just shooting from the hip here while I wrap up my hour:

As far as I can see, there’s no dependency management. I’m not sure why they didn’t re-use what Node and NPM already offer.

Development is as “live” as it will get. You don’t need to even reload your browser. This all happens behind the scenes for you. An impressive productivity feat.

Meteor seems to use long polling client/server communication similar to Opa.

The documentation is clear and also give a good insight into how the magic works, which is important for an analytical guy like me.

Why Would You Use Meteor

With Meteor, your development time will be spent almost 100% doing actual development work. No time lost compiling, deploying or restarting.

Meteor is 100% JavaScript, a language pretty much any developer on the planet knows. You can be productive almost immediately.

Why Would You Not Use Meteor

Meteor is still extremely experimental. As far as I know, there are no production level apps online. It’s probably going to be at least a year before you will be able to deploy Meteor apps and sleep at night.

Also check out the new Getting Started with Web Apps guide.

This is a first in what I hope will become a regular feature: I give myself one hour to try out something new and decide whether I will pursue it or not. Feel free to send any suggestions my way.

First Impressions and How to Deploy

I love to try out new technology for pet projects and one thing I always worry about is small scale, cheap deployment. I could not find anywhere on the site how you’d deploy Opa. Is there support for PaaS providers like Heroku? It appears not, you need to have access to and full control over your own VPS (there’s some limited information on AWS)

OCaml

Opa is Dutch for grandfather

I don’t understand why the website says the Opa language is JavaScript-like. As soon as you start writing your own thing, you’ll notice there are some major differences between Opa and JavaScript, so be prepared to learn a new language

Opa is based on OCaml, an objective functional language that has been around for a while and seems to mostly live inside academiccircles.. I first used it in 2000, the memories

Windows Version

I tried the all-in-one Windows installer.

It automatically installs a plugin for Sublime Text. The plugin itself has a build-in mini tutorial. Which is nice if you’re a Sublime Text 2 user. Keep in mind that your Opa file must be in the root of the folder tree, otherwise the run command won’t find the correct file. The plugin also couldn’t kill the processes it started, which made the build/run integration useless.

Later on, I also discovered that the installer had deleted my path setting. I assume this is a small bug that will be solved in the next release.

HTML and NoSQL

Opa only supports NoSQL databases and I have a feeling you’re in for a lot of hurt if you try to connect to a relational one.

HTML doesn’t need to be quoted and the compiler checks for correctly closed tags. That’s pretty cool.

Type System

Static typing without the overhead

Opa uses static typing with type inference which made me think of Scala: it gets out of your way, but it’s there if you mess up. It’s probably a great feature if you are used to static typed languages but may be an annoyance if you are not.

Client/Server

Running the Hello world counter example and clicking on the header results in 5 POSTS. The last running to closed. Probabfurthers ever push communication. 5 posts just to transmit one number worries me. It’s also all Ajax, so no SEO here.

I tried to add the “server” keyword in front of the “page” function, but that did not remove the ajax updates. I suppose it’s a little too early for that but the documentation seems to indicate that this forces function to run on the server.

The first tutorial is a chat application. I can understand that this is a great demonstration of the language and API, but this is an application only 1% (or less) of the developers ever needs to write.

The chat application is concise, yet I can’t help but ask myself how you’d ask a web designer to work on this project. You could argue that CSS is all he needs, but in practice it very rarely works like that. Maybe there’s a way to externalize the HTML in seperate Opa files (like you’d split a PHP app in a controlling part and a template part, even though both are technically PHP files) Going over the table of contents, I can’t really see this explained anywhere

Integration

Going to the wiki example, I learn that aside from Bootstrap, also Markdown is built into the API. This is nice. I’ve always liked Markdown as a simple language for creating content. This has me browsing the API documentation, where I also see support for Google Charts, Canvas, Facebook and Twitter. And I also scroll past a “template” package, so my fears from the previous paragraph seem to be unfounded.

Wrapping Up

An hour is too short

Because I’m nearing the end of my one hour, I quickly scoop over the rest of the documentation. I do encounter a more detailed explanation of the client/server keywords and their usage. If I pick up Opa for a new project in the future, it will probably be the first thing I’ll read.

The one thing that keeps bugging me is the absence of any information on deploying. The Scalability chapter touches on this, but it’s very unclear to me. Probably because I’m too impatient and I should just try it out. From what I understand the “opa-cloud” application will distribute your application over SSH. However, does this also work between operating systems (the command lines presented seem to indicate that it just copies the “exe” file that was produced).

Throughout the entire hour, I also can’t help but think “Why bother learning Opa, when Node.JS offers a fairly similar model in a language all developers already know”. It’s a valid question and others have looked at it in much more detail. One of the most important things I picked up from that test was how concise Opa applications seem to be. This is probably related to its OCaml heritage.

Why would you use Opa?

You can write all of the code for your web application in one concise and type-safe language. Out-of-the-box Opa supports an interesting selection of integrations and its first-class language support for HTML and NoSQL databases is top notch.

Why would you not use Opa?

You just want to get started and don’t feel like learning a new language. You prefer a large community backing your choice framework.

More resources

• Opa questions at StackOverflow
• The Opa blog
• Practical OCaml, the base for Opa

Also check out the new Getting Started with Web Apps guide.

While the Node.JS community is quickly evolving all the libraries and making your life as a developer easier every day. One thing you read little about, is the development environment. Every one uses their own cobbled together thing. To get you started with Node.JS, this post is a step by step guide to creating a full working and reproducible environment that supports deployment to Heroku.I’ve previously sung praise for VirtualBox. It’s a tool that any developer should have. It will allow you to create an environment that’s easily portable and can be quickly reproduced by any new developer on the team.

Step 1. Installing the Operating System

If you’ve previously created a Linux virtual machine with VirtualBox, you can probably skip this step. But for those new and for my own reference, here are my steps:

1. Download the latest ISO image of your prefered Linux. I usually just go for Ubuntu because it has the largest community and thus the most chance any issues you may encounter have already been solved.
2. Create a new virtual machine, everything is default, except
• mount the Ubuntu ISO image on the CD-ROM controller.
• create a new automounted shared folder (handy for sending files between both operating systems)
• 1024 MB of memory is plenty. 512 works too, but it’s a little more comfortable with some more.
• the 8GB hard drive space is plenty for all of Node, an Apache server and one or two database engines. If you are going to install anything more, you’re either going to have to be careful with space (like removing Libre Office), or just make the virtual hard drive 16GB.
3. Start the new VM
4. If the CD image is mounted, it should automatically start the Ubuntu installation. This is going to take some time, so grab a coffee.
5. After your first boot in your newly installed VM, first open the update manager and update everything. At least if you intend on keeping your VM up-to-date, if not, it’s probably best to disable to automated update checks.
6. For Heroku, Github, etc access, you should also generate a public/private key pair:
• ssh-keygen -t rsa
7. Feel free to install any editor you like. Depending on my mood, I use VIM or Geany.

Step 2. Integrating Guest and Host

With VirtualBox you create a virtual computer, completely isolated from your actual PC

1. Install the VirtualVox Guest Additions from the VirtualBox menu that shows up when your VM is running. Or you can press Host-D (the Host key is associated with the right ctrl button on Windows)
2. With those additions installed, the shared folder will be mounted. Now you just need to add your user to the correct usergroup so he has access. Open a terminal and type (on the Ubuntu VM):
• sudo usermod -a -G vboxsf <username>
• now logout and log back on
• test your share access with “ls /media/sf_<sharename>”

Step 3. Setting Up and Configuring Node.JS and Heroku

Now we’re getting close to getting some actual work done. If you don’t already have a Heroku account and want to follow along, now is the time to sign up.

1. You can compile Node.JS for yourself. It is a pretty painless operation, but via the Ubuntu (well, Debian) package manager it’s even easier:
• sudo apt-get install python-software-properties
• sudo apt-add-repository ppa:chris-lea/node.js
• sudo apt-get update
• sudo apt-get install nodejs npm
• sudo apt-get install nodejs-dev (Needed for some of the database drivers)
2. Test out your install by creating a helloworld.js that contains:
• console.log(‘hello world’)
3. Run: node helloworld.js
4. Install the Heroku toolbelt
5. Check the correct installation by login in and adding your key:
• heroku login
• heroku keys:add ~/.ssh/id_rsa.pub
6. And configure your default git e-mail and name:
• git config –global user.name “<username>”
• git config –global user.email “<useremail>”

Step 4. Creating a Minimal CRUD App

CRUD = Create Read Update Delete

• sudo npm install railway -g
• sudo npm install coffee-script -g (avoids having to download this for every railway applications)
• railway init blog && cd blog
• npm install -l
• railway generate crud post title content
• railway server 8888
• open http://127.0.0.1:8888/posts

This will set you up with a minimal CRUD application that uses an in-memory store for all storage.

Step 5. Configuring & Deploying to Heroku

Before deploying, there are a few steps and tweaks you will want to make.

Adding a Redis session store:

• sudo apt-get install redis-server
• add”connect-heroku-redis” : “>= 0.1.2″ in your package.json
• in the config/environment.js file:
• HerokuRedisStore = require(‘connect-heroku-redis’)(express);
• app.use(express.session({secret: ‘secret’, store: new HerokuRedisStore }));
• You may want to replace the secret!

Make sure you are using the latest Node version on Heroku, by adding the following to your package.json:

• “engines” : { “node” : “0.6.x” }

You probably want to have git ignore the node_modules folder:

• echo node_modules > .gitignore

Set up Heroku as the production environment:

• heroku config:add NODE_ENV=production
• But disable file logging in the Railwayjs production.js file: remove the line “app.settings.quiet=true”

I’m keeping the database configuration for another post, because there’s just so much choice. But both MongoDB and PostgreSQL can be tested out for free on Heroku and are fairly easy to configure.

The actual deployment looks like this:

• git init
• git add .
• git commit -m “first version”
• heroku create –stack cedar
• heroku addons:add redistogo:nano
• git push heroku master
• heroku ps:scale web=1
• heroku open

This should bring up a browser with your deployed application.

During actual development the deployment flow is as simple as:

• git add <changed file>
• git commit -m “commit message”
• git push heroku master

Conclusion

A reliable development environment is the best guarantee that you’ll not only experiment with Node.JS, but also actually get some work done. Developing in Node will bring back the programmer’s joy you felt before enormous frameworks and gigantic API’s.

Also check out the new Getting Started with Web Apps guide.