Guide to application development
In this post I will describe my application-development preferences, specifically:
- Methodology
- Management
- Platform
- Source control
- Storage
- Tools
- Analytics
Methodology
- Business model has to evolve during development,
so: Until model proven your product is tool for learning
so: Only focus on learning, absolutely nothing else - Don’t trust yourself, you are suffering from reality distortion
so: Measure what users do, behavioural data is key to learning
so: Only talk with users for hypothesis or ideas, their thoughts are not measurements.
so: Just like plane pilots; look at your instruments - Your first users are early-adopters
so: your product won’t grow if their needs are not met
so: it’s harmful to develop product for mainstream audience
There is much more about The Lean Startup, so I recommend watching a video by Eric Ries, the original promoter of this methodology. To get from vague idea to concrete actions you can study each item on the image below.
All my preferences are based on this methodology. By simply using the services and tools I recommend, you will automatically have implemented most of the “Build” techniques, which enable you to not only build, but also measure and learn faster than before.
Management
When having learned the Lean Startup Methodology you will be able to manage effectively. The tool I recommend to actually manage a team is Trello.
Platform
I recommend writing your client-side app for the web.
- Automatic updates for all users of your application, which is critical for continuous integration.
- Takes least amount of time to change or broaden customer segment (because you never need to rewrite all your application logic and the web is available from every device, even ancient ones like windows 95!)
When your team wants to create software which does not require hardware web browsers don’t support, the web is the most logical answer. To see if your application can be written for the web and what browser compatibility you will be able to offer to your users, take a look at CanIUse.com.
I recommend writing your server-side app in the cloud, on the NodeJS platform.
- NodeJS synergizes well with the web, all your programming is done in Javascript
- NodeJS is by far the easiest to install on any platform, which allows everyone to have their own Developer Sandbox
- NodeJS is installed alongside it’s package manager NPM, I can’t even begin to describe what an improvement NPM has been in comparison to other package managers, so I wont.
- The cloud is the cheapest, most reliable and fastest way to distribute your application and connect to your global storage (database)
- The cloud is easiest and cheapest to scale
For a NodeJS Platform as a Service (PaaS) I recommend using Heroku. To learn more about this service, I can read their How it works page.
- Costs nothing to run on just one Dyno (slow, but perfect for development)
- Pay as you grow, each additional Dyno costs 34.50 USD / month
- Can be hooked up to Git-based source control (Github!)
- Supports custom domains
Source control
If you’re on your own, and you don’t have experience using Github, I would go for a simple Dropbox setup and NodeJitsu as your PaaS provider.
But when you want to work in the open, or when working on a project with more than one developer I prefer using Github. And since Heroku uses Git you might as well push versions to your Github repo.
Github offers both web-based and native apps to help you collaborate on software development. It costs nothing to work in the open, and for a small monthly fee you can create private repos.
However Github is more than just a valuable tool, it’s a community of developers. It can help you establish an open source developer community yourself, which can benefit your product in the long run.
Storage
For storage I want a scalable and fast solution. For a database to scale you will need to eventually be able to divide it into shards, therefore I prefer using a NoSQL database. There are multiple NoSQL database solutions, and generally it’s best to find out what your application needs before choosing one of them. However, for a general purpose NoSQL database, I prefer MongoDB.
And the company I use to host it is MongoHQ, their support is instant and helpful, their databases are cheap and they offer a solid monitor tool.
To connect to this database inside your NodeJS application you will need a driver. I strongly prefer Mongoskin, because of it’s overall simplicity.
Mongoskin is an easy to use driver of mongodb for nodejs, it is similar with mongo shell, powerful like node-mongodb-native, and support additional javascript method binding, which make it can act as a Model(in document way).
Tools
CSS pre-processors are required for any decent web-app. It’s simply impossible to keep CSS organized, tiny and clean in a on-demand work environment. A good tool not only allows you to use SASS / LESS or Stylus. It can also minify and prefix attributes where needed. For this I am using SimpLESS; a well-designed and clean product. Slick notifying when my LESS code is invalid. It can also watch and auto-compile files. I often forget it’s running.I much prefer using a tool over implementing an automatic LESS > CSS conversion on the server. Servers are often slower than dedicated tools and for production code you want to serve raw CSS as fast as you can. Some developers solve this by letting their code know if it’s running in dev or production. Which can create major issues if you’re in a tiny team, with a pressing deadline and feature requests spam mailed to you. You can’t test if your code will work in the other “mode” or environment. And therefore there shouldn’t be another one.
Analytics
Next post I will go into my Fledged project, where all these tools and services are implemented.
Cheers!
As I wrote in my last blog post, I am working with NodeJitsu. It’s been 3 months since I started hosting all my experimental apps on it and it’s been great.
I started out working on an application with no purpose besides implementing advanced features and developing a high-performance and well-structured web app. Besides that I used this opportunity to improve my workflow and tools. Projects like this allow me to develop at an unbelievable speed when working on real projects.
Third-party sign-in
Password hashes, security, user support, registration and confirm mails; a traditional account module is nothing but trouble. Not only that, it also does not satisfy users of any web app, since they have another password to remember, another link in the mail to click on. Third-party sign-in is essential, so I started with this feature. Using EveryAuth and an extra long weekend I created an authentication server. Which provides third-party login to 12 ID providers (the config file is missing since it contains API keys and secrets contact me if you want the get an example config file).
Project Structure
The web has a reputation of being slow and buggy. The Ajax-revolution and many HTML5 features helped solve this issue. However, if you want your app to really feel quick, you will have to do more than some front-end tricks. To reduce round-trip time you have to put your server as close to the client as possible. Putting your app in the cloud, running on multiple drones, solves this issue. So I went for this structure:
This structure gives control to a business leader. More money = more drones = higher speed. I run my databases at MongoHQ.com which only scales the costs up as my database size increases and also provides excellent back-up features and a powerful admin panel. MongoHQ uses MongoDB for all it’s databases; a solid, general-purpose NoSQL database with great documentation and a powerful interactive shell for those stress-infused moments when some data needs to be changed right away and you haven’t written an admin panel yet.
Splitting up all services into components helps keep the source code simple. Now I can enjoy a search server without messy authentication code or some horrible pre-compiled HTML templates. It’s just request -> database lookup -> response.
Tools
CSS pre-processors are required for any decent web-app. It’s simply impossible to keep CSS organized, tiny and clean in a on-demand work environment. A good tool not only allows you to use SASS / LESS or Stylus. It can also minify and prefix attributes where needed. For this I am using SimpLESS, another great program; well-designed and clean. Slick notifying when my LESS code is invalid. It can also watch and auto-compile files. I often forget it’s running, it’s just magic.
I much prefer using a tool over implementing an automatic LESS > CSS conversion on the server. Servers are often slower than dedicated tools and for production code you want to serve raw CSS as fast as you can. Some developers solve this by letting their code know if it’s running in dev or production. Which can create major issues if you’re in a tiny team, with a pressing deadline and feature requests spam mailed to you. You can’t test if your code will work in the other “mode” or environment. And therefore there shouldn’t be another one.
Implementation
Day dreaming about web applications and creating prototypes only gets you so far. There comes a moment where you need a real project, with real deadlines and real feature-requests derived not from imagination, but need. For me that project is currently ConveyancingBy.com. A web application which provides the tools and information needed to make an informed decision on which conveyancer and estate agent to contact when buying or selling property.
Next post I’ll dig into some code, and file structuring.
Cheers!
NodeJitsu & Coffeescript
While I was working on Yipiy.com I developed a keen interest in the tech stacks of web apps. My problem however was the server. I didn’t want to maintain or pay a host for a single server, since the web stack I am planning to implement needs maximum performance, all around the world. It would have to be cloud based and it’s database would have to be split up across servers. So first I dove into Google App Engine.
However, after a couple of days of wrestling with it, I realized I could never switch to anything else and I would always have to pay Google for my apps. Now this is not that troublesome for me, but if I ever wanted to use my expertise in companies and projects I work in, I would first have to sell them Google App Engine. This downside was too much, and I decided to look for other solutions.
NodeJitsu
Finding a good platform proved to be difficult. Every time I was put off by the prices, the (un)supported languages or the lack of community and documentation.
Until two days ago, when I found out NodeJitsu had rolled out a Platform as a Service (PaaS). NodeJitsu is still in Béta, however they are already letting developers create accounts and publish their apps to their servers. Let me sum up why this service is top-notch:
- Jitsu, the command line interface to deploy apps, is built on Node, and therefore 100% supported on all platforms (Linux, OSX, Windows).
- The web console is fast and modern, with an advanced front-end built on the open source Flatiron framework. These guys know what’s needed for modern, high-performance web stacks, since they have one themselves.
- They have a ton of important, significant features. Reading that list made me realize these guys know the real problems developers come across when dealing with regular PaaS providers.
- The products they use to provide their PaaS service are open source, which is always a big plus. It adds durability and security to their products; any bugs will be solved quickly and it provides a great source of documentation.
CoffeeScript
So my choice is made and I am happily hacking away at my project. And one of the first things I am doing is copying from the very best products in the world; Trello and Github. Now there is a lot to say and read about the Trello tech stack, but after I noticed both Trello and Github use CoffeeScript, I had to make the jump. Javascript was my first-learned language and the bread-and-butter I’ve been using throughout my career. And therefore I feel that even if JS Exceptions are thrown, I will be able to figure out what the problem is. Besides, when I first tried CoffeeScript it was in its infancy, now it’s even influencing the potential ES Next features. The arrival of Source Maps also convinced me that browsers are getting ready to handle compiled code. And if this is where the bleeding edge of web development is taking me, I will embrace it as well as I can.
Next post I will talk about the project I’m setting up.
Cheers!
Follow me @Luuk_vE