photo credit: various brennemans

It’s hard to believe but this site is four years old. Wow! Time has flown, and I’ve learned a lot – hopefully these years have been helpful for you too!

No related posts.

photo credit: mikecogh

This year started off with a foray into Rails, an experience I won’t be rushing to complete. Most of my time was spent building a small application during the Christmas break in 2010, but in 2011 I moved that site into production and wrote a little bit about separating production and development values (a feat I repeated for the Play! framework, which I actually like, later in the year). I think the only thing I really like from Rails, and this is a bit of a stretch, is the database migrations.

Having moved entirely over to a LAMP platform professionally, and getting good at the security nuances plus everything else, I reminisced a little about some of the creature comforts I missed in C#, like operators for default null variables. But when I discovered Time Machine on my Mac, there was no going back – until the company switched directions and I got thrown back into .NET development.

That’s right – back to .NET, and deep into the Windows Azure cloud. I dealt with things like figuring out which is better – table storage or SQL Azure, and figuring out the nuances of their multiple SLAs, and how to ensure we actually have Azure Compute instances on-line when it hits the fan. At this point I have a pretty good handle on Azure’s strengths and weaknesses and my overall impression of the platform is very positive. If I continue building sites on the Microsoft stack, I would definitely continue to use Azure – it seems more expensive than other options at first glance, but it has some serious computing power behind it and takes the majority of administration headaches off of my plate. It really has enabled me to, for the most part, just focus on development whereas I was spending an increasing amount of my work day on system administration issues when supporting the LAMP platform.

Scalability and high availability have been on my mind a lot, and I’ve been looking into some more ‘off-beat’ database solutions like Drizzle for my transactional needs, as well as speeding up existing deployments by moving as much as possible into RAM. There’s always a battle between changing the way we work to take advantage of the new paradigm or changing our existing configuration to get some more life out of it.

The whole cloud computing buzz feels tired but has enabled a whole new class of online business. If you have a lot of commodity hardware you can achieve, very cheaply, feats that were only possible with an expensive dedicated network just a few years ago. Sure, it adds a lot of new choke points you will need good people to help sort through, which is giving rise to a whole new sub-category of programmer specialization to make hiring in 2012 even more challenging.

There is a downside to all the cloud computing, though, as we learned during the high profile Amazon failures – backups are important. This includes geographically-redundant systems that most organizations don’t have the experience to deal effectively with just yet. Even so, the biggest lesson I learned was never let your server run into swap space or your performance will nose-dive. The growth of this site even prompted me to move more of the site into memory which prevented me from needing to spend a lot of money upgrading my infrastructure.

Social media continues to grow, with companies realizing they can’t control its effect on their business in traditional ways and less-than-useless cons ruining it for everyone by selling CEOs on cheap gimmicks.

Since my third child was born in February, I’ve definitely taken some time to sotp and reflect on what I want to work on, why I want to keep working, and what the next steps are career-wise and life-wise. I want to provide the best that I can for my family and 2012 is going to see a radical course change as I start to shift gears and begin building something that will really last, even outlast me. When will my website start paying my bills? I don’t expect it will.

I learned a lot by running dozens (over a hundred?) job interviews in the past two years. Ignoring the old adage that you shouldn’t judge a book by it’s cover, I learned that you can tell with pretty good accuracy whether or not someone will be a good match for your company within the first five minutes of an interview. I’m less interested in hiring people with domain knowledge than I am in surrounding myself with the most intelligent developers I can find – one is a skill that can be taught, the other is an aptitude candidates need to bring to the table. Really, when it comes down to it, what I really want is for people I hire to stand up for themselves (since they are adults) and make me look good by being awesome at what they do.

I also learned a lot by being responsible for some very large projects; things like the importance of continuous integration.

What’s next in 2012? Look for mobile device use to continue growth – every developer who plans to stay employed needs to know something about mobile development, because it’s going to be ubiquitous with regular desktop programming very soon. Now that version 0.6 has been released with Windows support is Node.js ready for prime-time? I had the opportunity to play with it a lot over the past few month – look for a book early in the new year co-authored by yours truly.

No related posts.

photo credit: Orin Zebest

Used properly, LinkedIn is an incredible tool for finding new opportunities and connecting with potential employers. As your network grows over time and people move on to bigger and better things, the connections you make in the early days can easily be worth hundreds of thousands of dollars in terms of salary and other business opportunities.

LinkedIn has three things going for it:

1. A thorough resume builder that is intuitive and begs to be completed
2. An easy way to find and connect to professional colleagues
3. Peer recommendations – this is what makes LinkedIn valuable

People who compare LinkedIn, Twitter, Google+ and Facebook are missing the point. Users of each network are seeking different experiences, and LinkedIn serves an excellent purpose when used “properly” as a networking tool.

Beyond giving a plain resume (which is, by its very nature, more detailed and relevant than most of the bad paper resumes I see day-to-day), LinkedIn’s user recommendations option gives potential employers a more organic view into what it would be like working with you, as seen by your colleagues.

There are a lot of elements that go into a good recommendation, but the goal should be to strike a balance between supervisor, co-worker and subordinate recommendations. For example, your direct boss may say you’re an excellent manager, but what about the people reporting to you? A vote of confidence from all levels gives a much clearer picture than a potentially biased recommendation from a single source.

The beauty of recommendations is that you must receive them from people connected to you, which means requesting them in some way. If you don’t have any recommendations already, how do you start?

The easiest way to get someone to write a recommendation for you is by writing one for them. Yes, you can nudge the person, officially request a recommendation, bug them in person, etc but the ego-boost someone will receive by getting a recommendation from you is, in many cases, enough incentive for them to respond in kind.

Don’t get upset if someone does not return your recommendation. The system only “works” when recommendations are given freely and honestly – so if you don’t truly recommend working with someone, don’t give them a review on LinkedIn. There is really no downside to this.

No related posts.

Downloading files directly from a web server is costly, even if you’re using an efficient server like nginx for static files.

A content delivery network (CDN) can help speed up the process by storing your content in data centres around the world so they get served to your visitors from locations that are physically close to them. This results in fewer network hops which makes the files download faster, and reduces the overall load on your web server so you can focus on doing more interesting dynamic application stuff.

At one point, CDN services were only available to companies with deep pockets and huge websites, but these days anyone can set up and use an inexpensive service with their regular hosting provider.

Check with your host to see if they offer a content delivery solution. The two providers I use for my blog, Media Temple and Rackspace both have excellent services. If you are using a WordPress site, check out W3 Total Cache, which provides an all-in-one package for managing your files and optimizing the overall speed of your site.

Related posts:

1. Small Site, Big Footprint

Direct Income
It is possible to make direct income from your blog, of course. The two most common models of this are ad-supported (Google Adsense is common, but higher-quality and paying ad partners are available to larger blogs), and pay-for-use where your reader pays to access premium content you produce.

The problem with direct income schemes is they take enormous amounts of traffic to work. The average user will not pay or click on ads so in order to get your 1/1000 conversion to pay off you need to have tens of thousands of visitors to your blog. That would have to be a really interesting blog.

Affiliate Income
A more common way for bloggers to make money is by hawking other people’s wares on their site for commission. Depending on the affiliate, the income from this can blow ad-supported revenue out of the water.

Marketing for Other Income
Other writers choose to use their blog as a medium to advertise some other product they have created, or as a vehicle for increasing their professional profile. In these cases the blog may or may not additionally use another model to generate income, but the focus is not on making money.

No related posts.

This isn’t a new idea; in fact, people have been talking about brands for as long as brands have existed. It’s well known that behind every customer who speaks up about their disappointment or service problem are ten others who simply switched to a different supplier. Figuring out what people are saying “on the street” and reacting to improve based on customer expectations isn’t a new concept; Facebook, Twitter and the blogosphere are only tools that make this much easier – they did not invent the conversation. So what’s the big deal?

The difference we are seeing today is the easy access to information that was not present before. Employees at all levels of the organization have access to the same outside data, the same instant feedback to everything being done. Ofttimes the worker at the lowest level has more sense of customer feelings than does the decision-making upper management – this has always been true, of course, so why the sudden magnification?

I believe we are seeing a generational change in business and mindset that is putting people ahead of function. Call it Generation X (over-workers to a fault) passing the torch over to Generation Y (family-focused individuals). In the next several years we are going to see a greater focus toward grassroots-based marketing efforts and a continuation of the trend toward niche-based services alongside the dismantling of mainstream distribution channels.

How to control this? Don’t. Service the customer and listen to their feedback. The same ingredients that have always made businesses successful are still in place: the difference is it is now easier than ever to hear the feedback faster.

Related posts:

1. How to Hire a Social Media Expert

photo credit: Ben Sutherland

I am seeing an alarming trend on my beloved Facebook. Several of my friends (ok, I haven’t really kept tabs on them for years) have become “social media experts”. You can tell who is pushing at this stuff because they start tweeting dozens of times per hour, washing out all relevant contact from your home feed. They start using @reply and #hashtags and linking to other “social media experts” blog postings about the importance of Social Media and oh-goodness-your-company-doesn’t-understand-this-like-I-do-but-I-guarantee-results-for-you!

Honestly, this kind of behaviour has become textbook newbie behaviour.

The Buzz Bin has put together a list of ways to vet would-be social media experts.

I swear if I ever see ‘social media guru’ on someone’s resume, I will not hire them.

Related posts:

1. Command and Control Social Media

What if Apache is on a different server entirely? Unless you have the luxury of an NAS device, your options are:

1. Maintain a copy of the site’s assets separate from the web site
There are two problems with this approach: maintainability, and synchronization. You’ll have to remember to deploy any content changes separately to the rest of the site, which is counter-intuitive and opens up your process to human error. User-generated content stays on the Apache server and would be inaccessible to nginx.

2. Use a replicating network file system like GlusterFS
Network-based replication systems are advanced and provide amazing redundancy. Any changes you make to one server can be replicated to the others very quickly, so any user generated content will be available to your content servers, and you only have to deploy your web site once.

The downside is that many NFS solutions are optimized for larger (>50Mb) filesizes. If you rely on your content server for small files (images, css, js), the read performance may decline when your traffic numbers increase. For high availability systems where it is critical for each server to have a full set of up-to-date files, this is probably the best solution.

3. Use an rsync-based solution
This is the method I’ve chosen to look at here. It’s important that my content server is updated as fast as possible, and I would like to know that when I perform disaster recovery or make backups of my web site the files will be reasonably up to date. If a single file takes a few seconds to appear on any of my servers, it isn’t a huge deal (I’m just running WordPress).

The Delivery Mechanism
rsync is fast and installed by default on most servers. Pair it with ssh and use password-less login keys, and you have an easy solution for script-able file replication. The only missing piece is the “trigger” – whenever the filesystem is updated, we need to run our update script in order to replicate to our content server.

Icrond is one possible solution – whenever a directory is updated icrond can run our update script. The problem here is that service does not act upon file updates recursively. fsniper is our solution.

The process flow should look like this.
1. When the content directory is updated (via site upload or user file upload), fsniper initiates our update script.
2. Update script connects to the content server via ssh, and issues an rsync command between our content directory and the server’s content directory.
3. Hourly (or whatever), initiate an rsync command from the content server to any web servers – this will keep all the nodes fairly up-to-date for backup and disaster recovery purposes.

Related posts:

1. Defaulting Null Variables
2. Memcached as Session Handler

photo credit: quinn.anya

Chris Guillebeau offers his e-book 279 Days to Overnight Success for free on his blog. This is a great piece of writing that debunks the popular myths about “making it” blogging.

1. Don’t rely on Google/Adsense as a “get-rich-quick” vehicle – they aren’t
2. You don’t need millions of visitors and command of Digg to do well
3. You will have to work hard
4. Overnight success means ‘months or years’, not ‘days’

See for yourself – download it today.

Related posts:

1. How to Blog for a Living

This week he brought up the idea of upsides versus downsides – how much effort do businesses put into minimizing their downside versus the time they put into offering the best user experience?

One of the primary examples from the post is that of a hospital spending a huge amount of time doing paperwork to prevent litigation and prevent people from getting worse when their primary goal (and reason for existing) should be improving the lives of the patients coming through their doors.

The hospital example was interesting and timely because in “real life” the Jewish General Hospital recently came out and said it has been able to improve patient care (upside) by reducing errors (downside) through its new(ish) full disclosure policy. This ties in nicely with Seth’s article because it proves that it is possible for even large organizations to let go of the status quo and achieve new levels of excellence.

In the case of the Jewish General Hospital, it seems paradoxical but by admitting and dealing with errors, the hospital is actually less likely to be sued and face costly litigation. In essence, they have found a way to improve patient care, cut costs, and foster an open corporate culture. Way to go!

No related posts.