I have just been evaluating Amazon Web Services for the last couple of days and thus far I have been utterly impressed. In fact, I can’t remember the last time that a collection of technologies worked so well out of the box. Aside from the Richard Stallman concerns (which are real if a bit dramatic) the only issue I have come across so far is that Amazon have so many impressive features it takes a while to figure out the best selection of options.
I have been creating and deleting “servers”, adding disks, load balancing, databases, monitoring, and firewalls and everything I do takes a minute or two. In the world I come from it takes 7-14 days to buy a server, 1-2 days to provision it, and if I get something wrong I have to deal with it. What is most impressive is how all of this is achieved by the simple web interface with zero external assistance. Quite a contrast to the number of people that I have to rely in my current situation. Also, because things are so fast, it is really easy to try out some packages or installs and if you don’t like them you can instantly go back to where you were before.
I am keeping an eye on the meter too, if you go crazy it seems that prices could get fairly high. However, based on the amount of money we currently pay on our co-location solution I still think we can do things quite a lot cheaper in the cloud. The selection of services appropriate to the size and requirements of your client are imperative to get a handle on costs. This is where the Amazon approach can score because instead of giving all clients the same set of features you choose the appropriate set-up for each client and if they want more features they are there and they pay for them.
Will we save money in the cloud? I think so, but for me it is not so much about saving money as it is in saving time, increasing reliability, providing a better service to our clients, and offering them the options they are looking for – these really are the compelling reasons for cloud computing.
Cloud Computing is a harder sell if you already have a good hardware and software infrastructure. However, if you are starting a new company or a new project that requires new hardware I urge you to try Amazon out. Until a few months ago I was a skeptic but I have looked at clouds from sides now and am very pleased at what I have seen.
So far I have managed to avoid dealing with Cloud Computing as I like to give new technologies a few years to mature before using them. But this week I am pressing forward with an evaluation of the Amazon Elastic Compute Cloud.
I am optimistic that this will provide a good technology and infrastructure base for the new platform that I am just weeks away from commencing.
Let’s hope that unlike the song they don’t get in my way.
I’m reminded of the time when I was attending one of his lectures and he was doing some calculations on those huge scrolling chalk boards they had in those days. At some point some brave soul put up his hand and said: “Dr. McCann I think you have that calculation wrong.” Tony whirled around looking perplexed as he studied the student then looked again at the board. He then realized his mistake and told everyone: “Ah yes, sorry, I was thinking in Hex.” Of course you were Tony!
He was a great character and an amazing coder and I always appreciated his help and insights. Thanks Tony!
The software vendors push the idea that better tools, languages, frameworks, and programming systems will make better programmers. This is simply not the case.
It is certainly true that most programmers can produce better code with the right tools. However, the second you want to do something new that is not covered by the tool or framework you are using you are now left to your own innate abilities. If you aren’t a good coder you will likely produce a bad solution, no matter how good your tools are. Stick within the framework and you’ll be laughing and people will think you are hot stuff.
In fact if you stay within the framework you might even produce better code than a more talented developer without the tools – kind of depends on the tool. However, don’t stray too far from your tools if you want to continue to impress your boss.
I read this article recently and agree 100% with these words by Matt Marshall:
One of the biggest challenges is getting an ace developer. The difference between a great developer and a mediocre one is huge. A great developer can push your business forward 10 or 20 times faster than a mediocre or average developer.
However, it only goes so far. In the first two years of a company great developers are what give you a shot, however to be really successful in the long term you have to have equally as good if not better marketing and entrepreneurial vision.
I think this is where a lot of great developers fall down – they think they can do it all by sheer technical virtuosity. This view typically leads to disillusionment. You need both sides of the coin to be successful in the long run, and sadly (for the developer) after the first two years much of the success of a company is driven by the entrepreneur and not the developer.
By now you’ll have realized that I have a slight reverence for Bill Joy and so I feel compelled to talk about the first time I met him. It was back in 2000 and there was all this buzz about the article he wrote in Wired Magazine entitled: “Why the future doesn’t need us.” He spoke over lunch and discussed his views and every word was enthralling. At the end of his talk people all clamored to speak to him. I found myself standing right in front of Bill Joy with all these other guys going on about his talk. All I could think about was how this man had influenced my life with Vi, Csh, BSD, NFS, etc. and instead of talking about his lunchtime talk I started blabbing on about how grateful I was for all of his amazing contributions. It was very uncool in the context of the meeting and he looked at me as though I was a whack job.
I was a whack job. I could hardly string together a sentence, I was so in awe of this man. I eventually pulled myself together but it was too late and his attention had moved on. I felt like a real tool.
Luckily, as I was leaving the room a little while later, I saw him walking down the corridor alone. Instead of going on about how great he was I remembered that he had a young daughter and I gave him my Magic business card and said to him: “Mr. Joy I enjoyed your talk very much, if you ever need a real magician to entertain your daughter, just give me a call and I’ll be there.” He first looked at me with suspicion, but as he read the card – Magic and Mystery for Select Occasions – a big smile came over his face and he thanked me and went on his way.
Just for that instant we connected and I felt that I had redeemed my earlier mistakes. I felt so happy that afternoon.
- Bill Joy – for pretty much everything, see this post.
- Dennis Ritchie and Ken Thompson – for Unix.
- Brian Kernighan and Dennis Ritchie – for the “C” Programming Language.
- Alfred Aho and Jeffrey Ullman – Principles of Compiler Design Book – the Dragon Book.
- Larry Wall – for the Perl Programming Language.
- Linus Torvalds – for Linux.
- Dries Buytaert – for Drupal.
- Guido van Rossum – for Python.
- Richard Stallman – for Emacs, GNU, and Free Software Foundation.
- John Backus, Niklaus Wirth and Edsger Dijkstra – for the development of modern programming languages that make it all possible.
I know there are others (Alan Turing and John Von Neumann are obvious), but these guys spring to the top of my mind. If you are a fan of Outliers you’ll notice how many of these guys were born in the early 50’s – that seems to be the time when many of the great programmers were born.
I’m a big lover of Programming Languages. I know there is not one language suited for all tasks and whilst I may dislike certain languages I also realize that in the end most things can be accomplished in any of the common general purpose languages available today. Not all will be as concise or as readable or as “pure”, but give or take you can express most problems in a slew of different languages. Of course there is the odd whack job who thinks you can do everything in SQL or COBOL, in fact I remember meeting a guy who actually wrote a COBOL compiler in COBOL – now that was a dedicated individual!
When I wrote my Ph.D. I developed five different special purpose languages and wrote interpreters for them all. The core language was called CARESS – no it was not a contraceptive, but stood for “Concurrent Assignment REpresentation of Synchronous Systems”. It was even used by the third year undergraduates at the time. Nothing earth shattering but I felt the need to write these languages and they became a integral part of my Ph.D. Naturally, those languages don’t exist today. But many from the 70’s, 80’s, and 90’s do.
But why so many? I’d like to think it is not just about making money and market share, but rather because developers are passionate people who feel so strongly about their craft, that they design a whole language that enables them to express themselves perfectly.
Looking at the list I get a warm satisfaction seeing that my old love “C” is at 2, and Python is at 7 and rising.
I’m looking forward to doing a lot more with Python later this year, although sadly it seems my current project will take longer than I hoped – if only I had a more expressive language …
I have been collecting and performing magic since I was nine years old. However, when it comes to software my best advice is to avoid as much magic as you can. It is easy to think writing software that does all sorts of magicis a good thing. But after years of being burnt by such software I have come to the earth shattering conclusion that there is no place for magic in software.
The worst kind of software is code with multiple side-effects – it is a nightmare to maintain and never does quite enough magic to make it worthwhile. It doesn’t mean you can’t write useful scripts and routines that perform multiple tasks, but each task in the script needs to be spelled out rather than things happening “as if by magic.”
This revelation might seem obvious to many but for me it has really only been in the last five years that the truth has become crystal clear. These days I aim for simple and explicit code and although I like to think what I write is still cool, it is no longer magical.
2010 is clearly the year of upgrades.
I’m not a big cell phone user – I only use my cell phone for voice calls, no texts or emails and certainly no apps. I’ve had a trusty Razor (Motorola RAZR V3) for about four years now, and have been very happy with it. I had no plans on “upgrading” anytime soon.
For Christmas two of my best friends purchased an iPhone gift card for me and so I decided maybe now was the time to upgrade. My wife and kids were already on iPhones and Blackberrys, so how bad could it be?
I received my iPhone (3Gs 16GB) a few days ago and must admit if I had some spare time it does look pretty slick. The thought of having my music, photos, contacts, and easy access to emails and the web is quite interesting, not to mention all the cool apps that are available.
So far I have just synced up my iTunes and Outlook. I have not really customized it – my son offers every day to help me. I’m quite sure when I finally give into the potential I’ll be as wild about it as everyone else.
I’m not 100% sure having access to all the things that remind me of work all the time is a good thing, but we will see. You have to admit we’ve come a long way from my little Moto.
It should be obvious based on my worship of Bill Joy, but with a number of postings on Windows I wanted to make it clear:
When it comes to web servers and production environments I always use *nix and would never consider using Windows to run my enterprise.
I’m very happy with Windows 7 as my desktop I just wouldn’t want to build my server rack using anything but some form of Unix. These days I favor the CentOS distribution. For years I was a BSD guy of course, then an AIX guy, then a Solaris guy, and these days I’m happy with CentOS Linux.
“Is the customer always right?”
I get some interesting responses. My take on this is clear: the customer is clearly not always right, but it doesn’t matter as long as they are satisfied and happy. In fact, I like my customers deliriously happy if possible. It doesn’t matter if a problem is their fault you need to go out of your way to make them happy.
When it comes to developing applications one of the bad traits developers get into is doing things because they are easy to code, rather than because they are easy to use. There is rarely a time where it is a better policy to make the developer’s life easier at the expense of the end user. Of course, if possible, you want to make every ones life easier.
One of the most useful things a developer can do is to actually watch customers use their applications. It is amazing how “features” that you are proud of get used and abused by them and you can quickly see things that are poorly designed. Another practice that pays off in spades is to spend a day answering calls from customers and use the tools provided to the customer service staff. Nothing shows the flaws of a system like actually using it under fire!
Caching is so important from every aspect of running a website that without it, the Internet and/or our servers would surely grind to a halt. Caching occurs at many levels and the more levels you have the better performance you will likely have. If a few caches remain sticky along the way this is normally ok. People say they want “Real Time” but rarely do they care. Sometimes a minute or twenty minutes old is fine and frequently hours and days is also fine. The more use you make of this knowledge the better chance you have of helping out with various well placed caching systems.
Some common forms of caching are:
The best forms of caching are ones that don’t require developers to think about it. But sometimes the application requirements are unique and only the person writing the code can get the most out of the system.
However you slice it caching provides a huge benefit to both producers and consumers and without it the internet would have crumbled long ago. Caching truly is our friend.
I recently upgraded my development PC to a Dell Quad Core T3500 and in the process went from Windows XP to Windows 7. Upgrading is always a painful experience because I have installed so much software over the years, and getting it all to work on a new platform can take months. I took the opportunity to upgrade most of the core tools that I use and thought it would be revealing to list them here:
- Windows 7
- Office 2007
- Firefox 3.5
- SlickEdit 14, (with Vi bindings of course!)
- SecureCRT 6.5
- WS_FTP 12 Professional
- ActiveState ActivePerl 5.10
- ActiveState ActivePython 3.1
- Adobe Dreamweaver CS3 9.0
- COAST Webmaster 4.1 (yes ten years old now, and Coast are no longer around)
- ULEAD PhotoImpact 12
- Adobe PhotoShop Elements 8
- MKS Toolkit
Many more random packages to add, but these at least allow me to work. So far I have been very happy with my upgrade. What I find interesting is that every 3 years I buy a new machine and it always seems to cost around three grand. Why is that?
I started writing software in the outstanding music decade of our time: The Seventies. In those days good software performance was instilled in me early on. System calls and disk I/O were to be kept to the absolute minimum. When I started building websites in 1994 performance was still a big deal to me. In those days static HTML was prevalent and when I set out to build a 100% dynamic CGI site it was quite rare. For speed I used compiled “C” and the site (Garden.com) was feature rich and very fast. Over the last fifteen years there have been many hardware and software innovations to make processing dynamic pages faster. In fact, for many sites we don’t even have to think about it. However, I’m amazed how slow some large and influential sites often are.
You really need to render pages in less than a second to keep people from noticing. Certain pages (e.g. order checkout and account creation) can take longer without losing people’s interest, but for the most part clicking around from page to page should take a second or less. 0.1 to 0.5 seconds are better. You can certainly notice the difference between a second and half a second.
What happens is that developers get so enamored with adding all these “cool features” to a page that they fail to keep an eye on the clock. Or they keep an eye on the clock for the single instance and don’t take into account that 100’s or 1000’s of clicks are competing for the same resource.
I have heard on more than one occasion developers say “Performance doesn’t matter anymore.” Well, performance does matter. Without it you can’t add all the features you need to keep people coming to your site and if you do your site will be so slow that people will leave even quicker.
As we constantly change and fragment the ways we get to deliver content over the web our servers will continue to get pummeled with requests and I don’t see a time when performance will ever be irrelevant. What is more likely is that if we don’t start really thinking seriously about performance at the lowest levels we will build systems that just topple over with the load.
Performance is more relevant today than ever.