Web app with Node, Express, Jade, Mongoose and MongoDB

It has been a couple of months in our journey to build the open learn project. Our deadline to launch the first version is November 1st (I know, coming up soon). I feel like we’ve made some headway on the technical side and it sure took me some time. Below is a summary of some tips and resources I found to help build a database driven, MVC based web app.

The Recipe

There are few different pieces I had to get comfortable with to build an end-to-end app. Here’s what I have for now:

  1. Node (obviously)
  2. Express (light framework on top of Node to help create a basic server – e.g. accept and make basic http requests)
  3. Jade (templating engine that makes writing html and logic together much easier)
  4. MongoDB (the noSQL database that was recently in the news)
  5. Mongoose (which helps Express talk to MongoDB)

In addition, I had to learn a little bit about Heroku (where the site is hosted), Github (how I share this code with collaborators on the project), and MongoHQ (the database as a service provider).

Getting Started

Given that I have never built an end-to-end web application, there were three distinct stages for me as I was getting started:

  • Hello world
  • Let’s play
  • Piecing together the puzzle

Hello world

So, the first thing I (and I am guessing anyone new to programming) wanted to do was to print Hello World using Node. Turned out, it wasn’t that complicated. I followed the steps exactly as on Heroku’s Node getting started guide (except the database part, which we will get to later) and managed to get the basic app running that outputted “Hello World” to localhost and to the app on Heroku ([app name].herokuapp.com).

Let’s play

Rather quickly after installing the basic app, I realized I didn’t know what to do next. I had hello world on the screen, but what next?

I had been reading the basics of Node.js based on one major source – javascriptissexy.com. The site recommended Professional Node.js as a good book to start from. I had zipped through steps 1 to 9 (barring step 3 which recommended buying another book), but was getting impatient for a step by step tutorial on building my first app. It felt like I hadn’t made *real* progress. Getting a little frustrated, I ultimately bought The Node Beginner Book (from step 3), and suddenly, it seemed like I had, in front of me, exactly what I wanted. This book was a lot simpler and shorter and just walked a reader through building a sample app.

It took me a couple of hours to build the sample app – a simple uploader that would let you upload an image and then display that image. It was fairly basic, however, would break some times (I believe the ebook was a little outdated). This was actually a blessing in disguise as I had to figure out what was broken, hit the forums and Express API and understand why it was broken.

Ultiately, I had the basic app up and running. I could now play with uploading and displaying images. Yay! :)

Piecing together the puzzle

Finally, I could see light at the end of the tunnel. I had a basic app which did more than Hello World! :)

The next stage for me was to understand how to go from this basic app all the way to what I had in mind for Open Learn. I went back to the Professional Node.js book (remember? the one with lots more detail). Chapter 21 of this book goes through building an app using Express so I thought it would be to go back to that. I started structuring my app using that resource and got a little further. However, yet again, it seemed like the book offered way more than what I needed at that time.

I was looking to setup the basic structure of my app and what I was getting from that book was a lot more sophisticated stuff like sessions and authentication.

So, I looked elsewhere and came across two resources on the web (long live the web!):

Given how light Express is, the sample app (MVC) on Github was a great inspiration for my setup. I quickly refactored and restructured my code accordingly. The video tutorials above were a life saver too in reinforcing a lot of basic concepts and explaining stuff I wasn’t entirely sure about in a working environment.

Ultimately, I had to choose which database to use. Initially I had setup Postgres (just because at my previous startup we had used that and I remembered it). In the spirit, however, of learning something new, I decided to go with MongoDB. A quick web search helped me narrow down MongoHQ as the service to go with (given I was on Heroku). Setting up MongoHQ was dead simple too with the instructions here  and here.

Finally, after multiple weekends, I now had a very basic MVC database driven web app running locally as well as on Heroku. Couldn’t be happier. The next few weekends will be dedicated to putting the polishing touches, and actually getting this app to launch state.

Three golden rules for being a successful startup employee

There’s a lot of material that gets written about startup founders – from their struggles to startup best practices and everything in between. Lots of good material too, and from a wide variety of perspectives – founders themselves, angels, VCs, big company CEOs, and several business authors. It’s safe to say that the topic is well covered.

Yet, there is little that gets said about the majority of the startup world – the startup employees. Even, when there is something said (see this google search for “startup employees”), its mostly generic advice – be open to learning, be passionate, persevere, be biased towards execution, and so on.

This is all great advice. For anyone. The thing is that there’s a lot more to being a successful startup employee. I’ve had an opportunity on being on both sides of the startup equation – and what follows is one perspective on what it takes to be successful as a startup employee.

How do you define success

There’s only a couple of good reasons to join a startup as an employee – either you believe in the product or the people behind the company. Ideally, both. If you find yourself in a startup for any other reason, you should probably reevaluate your choice.

Given this, the definition of your success should only rely on two factors – namely, the overall success of the startup and the success of other people in the company. Measure yourself by how much you contribute to those two factors on a day to day basis.

Learn to deal with ambiguity

Startups are a mess. It’s tempting to think, on seeing them from the outside, that startups are free of the annoyances of larger companies. They’re just a team of 20 or 100, or a few hundred. Surely, they’re faster and more organized. Perhaps, they are. A tad faster, or a tad bit more organized. However, what we forget to see is that Startups evolve a lot faster than large companies. With that evolution, naturally, comes chaos.

A successful startup employee learns to deal with the chaos and make order out of it. In any given month, you will feel the pull in 10 different directions. Get comfortable with the ambiguity instead of clinging to your natural comfort zone.

Learn to manage upwards

Given the high chaos environment, its important to manage upwards. Startups often have flatter organizations relative to larger companies. This ends up putting a lot of responsibility on managers as they end up communicating with and managing cross functional teams and initiatives.

A successful startup employee has to learn to manage upwards. This involves asking a lot of “why”s before asking “what” and “how”! Truly understanding the motivation and direction of the leadership is what will make your work the most impactful for the company.

Learn to leave everything better than you found it

In larger companies, it becomes increasingly difficult to take something broken and fix it. There are layers of bureaucracy and middle management to go through to get the right approvals to do something basic. In a startup, there is no excuse.

Not every system you find is going to be perfect. In fact, its highly likely that most systems will be sub par. Don’t criticize, figure out quickly what needs to be improved and work on getting it done. Each small system improvement effort may yield fabulous results in the long run.

So, there you have it. Deal with ambiguity. Manage upwards. Leave everything a little better than you found it. Three golden rules for becoming a successful startup employee.

Three options for fresh grads in tech

If you’re a fresh grad in the tech industry and have aspirations to start your own company one day, there are only three options you have:

  • First one’s obvious – start a company right away. Cost of doing a startup is low, and you chalk up a ton of learning. There are a lot of caveats here:
    • Only do it if you have an idea you are willing to dedicate a majority of your next 5 years to.
    • Only do it if you can afford to financially (read: no student loans).
    • Doing a startup doesn’t mean you don’t need to learn everything you can about the business world. READ.
  • Second is to learn how to build. I am not talking about working on one small part of a large technical system. I am talking about learning something end to end and seeing how it behaves in the real world. Often, these kinds of projects will only be available at small or mid sized startups.
  • Third is to learn how to sell. Sales are the weakest areas within a typical tech startup in the early days. Master this skill and you will be invaluable to any company (and eventually to your own startup).

You’ll notice that to do #1, you need to do #2 or #3 anyway. For whatever reason, if you can’t do #1, focus on honing your building or selling skills. Having been part of large and small companies, it becomes very evident that these are the two bottleneck areas – things that the companies’ success or failure depends on. Don’t get me wrong – support functions like marketing, finance, analytics all go into better decisioning, but ultimately, all of the support goes into building or selling, so why not start your career there? That’e where you get your hands dirty.

Also read up on Andy Rachleff’s post on how to build a career in tech.

Node.js project deployment with Heroku and Github

After picking up the basics, setting up the Node.js environment and sample app on a mac is dead simple. This book literally holds your hand through the entire process. Super easy. The tricky part for me was that I wanted to share this sample app with a couple of friends (who are also new to this whole web app building thing!).

I had heard about Heroku in the past and seemed like they abstract a lot of the server side stuff, and they support Node.js. Fair enough, getting started with Heroku was straight forward too. Think of them as an alternative to AWS – in fact, in some ways, way simpler than AWS (not that I have used AWS extensively, but I have tried to and it looked a lot more complicated than Heroku for a beginner). This is where to go for step by step directions.

Warning – you will have to know a little bit about Git before working with Heroku as well to truly have an appreciation for what you are doing. They use Git to deploy your local app to their servers!

Finally, the tricky part. Getting your local code synced to Github (only if you really want to use Github – I do as a way to learn, but you can happily skip this if you want). Once you have your sample app setup locally, and you have pushed it to Heroku based on the steps in the link above, there are four steps:

  1. Got to Github.com, get an account and learn the basics of git.
  2. Setup Github on your local machine.
  3. Create a Github repo.
  4. Go to your Heroku account and link your Github repo in the settings.
  5. Now, on your sample app directory in your local machine terminal, simply push to both Github and Heroku. See this (if you followed the steps above, replace “origin” with “github” in your push command from this link).
  6. If for any reason, you have some contents in your Github repo at the time of creation, make sure you do a pull and merge before pushing new code from your local machine.

Now, every new commit you make from your local machine will be visible on both your Github and Heroku repos. Have fun!

The Side Project Club

Are you building a technical side project – a web app, mobile app, or even a hardware project? Do you ever wish you had more people to bounce ideas off of, to keep you honest and to show off your progress to? If so, join the Side Project Club – something I started on a whim today morning.

We started working on a side project of our own a few weeks back – Open Learn – and would love to bring together a group of people that are in a similar position as us. I figured that getting a group together might actually be a good way to meet others like us and learn from each other.

The only things needed to join the club are:

  • An idea – you must have the idea for the side project in mind.
  • A deadline – yes, a deadline is a requirement. Its a forcing mechanism to get results (even if it happens to be wrong, you can always change it) :P

This is going to be fun! :)

Catch 22

One positive impact of the move to the city is that now my commute is a little longer – 35 minutes door to door each way. This lends very well to my desire of listening to audio books (killing two birds with one stone). I just completed A short history of nearly everything – a fun book full of trivia, which I have been told might not all be accurate! :)

I’ve always wanted to read more fiction, so I decided to download something that’s been on my list forever – Catch 22. Its hailed as one of the great literary works of modern American literature. It’s a parody based on experiences of several American soldiers during WWII, and quite unique in its style. I still haven’t gotten used to the narrative yet – jumping from character to character and story to story, and really conversational. It’s almost like listening to a movie. Perhaps that’s not my style but I am committed to finishing it!

Soldiers trying to avoid it while generals loving it and every other emotion mixed in between – makes it a unique take on war and that’s always a fun topic. If you have a great suggestion for other fictional books – please leave them in the comments! :)

One week of learning Node.js

I’ve never built an end to end web application. I’ve contributed parts of it. Some on the front-end and some on the back-end. Mostly front-end. Which is why, when the time came to build Open Learn (see introductory post), I had to make a conscious decision to learn how to build an end to end we application. Daunting – yes! Fun – yes!

Then came the confusing part of deciding which stack to build on. Php, Python, and Ruby all have very strong and dominant followings. I had played with each a little bit but never seriously committed to learning how to build with them. At the same time, I had started hearing about Node.js on hacker news and it piqued my interest. Reading more about it, I realized it was based on Javascript.

I was super confused – I had done a fair bit of javascript but always thought of it as a way to add all kinds of cool effects to html/css rather than being able to build a whole site with it. After talking to a few friends, I realized that Node.js extends javascript quite a bit to give rise to a pretty sweet piece of technology that, in fact, in some ways is more powerful than the other frameworks out there. I could care less about that for now, as I don’t have the depth to make that kind of a judgement, but what did appeal to me is that I could use all that javascript familiarity and knowledge to get up to speed with Node.js.

So, it’s been one week and I already feel like this was a great decision. The side effect of having one language across both front and back end is also very comforting. I can imagine that this simplifies web development for a lot of people who are new to the trade. The site that has made it even easier for me is Javascript is Sexy – a super simple step by step guide to learning Node.js (and javascript, if you are new to it).

I’d love to hear from others who have learnt web development from scratch and any best practices, resources and mistakes! :)