Sunday, March 18, 2007
5 ways to not pick a programming language
Performance is usually a big issue when people are looking at a language. They always want to see numbers in benchmarks compared to others. It's great fun but on the end it really doesn't matter that much. Let's see how much an extra server costs compared to an extra employee. That should be a one time investment of like $3000. The average salary of a developer is like ~$75,000 worldwide. Still want to use assembly now for your next project? Don't think so, pick a language which delivers great productivity to your team.
2. It doesn't have feature XOf course it has no such feature, there is no single language which has all features you need else you wouldn't have to program. When it comes down to features there are always languages who have a little bit more to offer over the other. Ask yourself how much time it would take to implement them in others and see what libraries the community already made for them.
3. My boss/client wants language X
Your boss wants big texts in blink tags too, but obviously you don't make that for him (unless you have absolutely no principles). Always try and tell them why your solution is more cost effective or has a higher ROI (they love those terms). People who have no clue about programming are always trying to outsmart you. Be prepared and convince them, thats what they hire you for.
4. But MySpace uses it too!There are always companies who have successfully deployed applications in a certain language. Doesn't mean you can't do better. Who would have thought ruby could be usefull for web applications? Before DHH not many people. If you seriously think your application can be written in Haskell, go for it and prove the community it can be done.
The fact that some site using technology X is slow doesn't mean it can't scale. Even the fact that digg.com seems to have scalability problems doesn't mean it can't scale. A properly designed application with share nothing architecture will be able to scale to extreme levels. If you don't know how to design such architecture it is not a big deal. Solve scalability problems when they arise, don't try and solve them before they happen. Premature optimization is the root of all evil.
Sunday, March 11, 2007
Where to host your ruby applictations
Dehe
Dehe was our first Ruby On Rails host. We rented a small 256 meg vps for our rails applications. I installed mysql, lighttpd and rails 1.0 at the time. The performance was sometimes disappointing. I had some problems with mysql doing really slow queries at random times. The support was good overall. They were quite quick, but they were not able to solve the problem.
Eurovps
After dehe we switched to eurovps. The performance was better (also got a better package) and we switched to postgresql. This gave us another performance gain but more important, the queries were not slow anymore at random times.
Site5
Our next host was site5, we decided we did not need that much bandwidth and resources so we decided to go for a cheaper host. In this case it was a shared host which we took based on recommendations. Personally control panels piss me off cause they are super slow and limit the flexibility of your setup. This was also the case on site5, I had to do some advanced mod_rewriting to make sure everything worked properly. The performance was quite slow, but because we used page caching so this didn't really matter.
Our current situation
Currently we still use site5 and eurovps. Our corporate site is hosted on site5 and some subprojects are hosted on our eurovps packages. We are looking to move all our sites to eurovps later this spring. Our current production stack on eurovps consist of the following components:
- Ruby On Rails 1.1.6
- Ruby 1.8.5
- RMagick
- ImageMagick
- Mongrel 1.0.1
- Nginx 0.5.14
- apache 2.2.4 (Just for mod_svn)
- subversion 1.3.2
- redhat enterprise linux 4
- mysql 5.0.12
Which host should you take
Based on my experience I would highly recommend eurovps. They use triple A quality hardware only and are very concerned about stability and security. Their support department is also very knowledgeable and solves problems in a satisfiable way.
If you got, and like to spent, more money you can also check out the following webhosts to create your custom setups.
- Railsmachine.com (they have their own deployment gem)
- textdrive.com (only accelerators, shared hosting is slow)
- engineyard.com (expensive cluster hosting)
- solarvps.com
- rackspace.com
- softlayer.com
Sunday, March 4, 2007
Our tools
- Freshbooks.com: We have used freshbooks since our third invoice and its still in use. Its super simple, cheap and at the time we used it it was the only EU regulations compatible invoice software. As you might know we are forced to put up stuff like VAT number and company ID on our invoices.
- Ruby on Rails: Our preferred technology to build web applications. Doesn't need much explaination, just try it out.
- Linux: All our applications and server based infrastructure is hosted on Linux. Mainly the centos and redhat distro's.
- Subversion: After my first projects I couldn't think of a better solution to store my sourcecode than subversion. At the moment I use Apache with an svn mod to host and serve all our code.
- MySQL: arguably one of the best open source databases out there. I didn't have any problems with the software and I basically grew up with it, so I don't have a reason to switch.
- Nginx: All our deployed websites on our custom server run on Nginx. Based on my tests it offers the best performance for both static file serving and serving mongrel output.
- Google apps: If you want a super reliable infrastructure for mail AND a kick ass web based interface there is no better choice than google apps.
- Aptana/radrails: Our main IDE for developing rails applications. I like the features more than textmate, so I have been using this since I installed it.
Subscribe to Posts [Atom]