I’ve been using WordPress for several years now — I’m a big fan.  It makes it really easy to run a blog (or website) and it keeps getting better.  One of the advantages of WordPress is the ability to add your own plugins to improve the functionality of your site.  Here are some of my favorite WordPress plugins… (for now).

Disqus Comment System

Disqus replaces the WordPress comment system with it’s own, which allows readers to see their comments across all the sites that use Disqus, and it has good spam collection.

FD Feedburner Plugin

FD Feedburner is a WordPress plugin which redirects all the blog’s feeds to Feedburner to utilize Feedburner’s stats and additional feed functionality.

Google XML Sitemaps

Google XML Sitemaps generates a XML site map to help search engines properly index your site.

Lijit Search

Lijit Search lets readers search the content on your site — can also support ads for your site (search and content-related).

LinkWithin

LinkWithin WordPress plugin displays other recommended stories on each article to help increase the amount of time people spend on your site.

PostRank

PostRank provides some social network tracking as well as top posts.  I use it to track the PostRank of each post which is also a metric used by the AdAge 150.

Scribe

Scribe is a paid WordPress plugin (affiliate link) which quickly and easily provides recommendations to increase the search engine optimization for each post.  Requires a theme which supports it (I use the Thesis paid theme — affiliate link).

ShareThis

ShareThis provides links so your readers can share your content on various social networks.  Lets you control which social networks show up (and what order).  Provides stats for how many times that button is used.

TweetMeme Retweet

TweetMeme Retweet adds a button for each post so your readers can tweet a link to the article.  Counts the number of times the article has been tweeted (doesn’t always catch alternative ways to tweet the article).

Wibiya Toolbar

Wibiya Toolbar adds a bar at the bottom of your site which has links for sharing your content on social media, as well as a message (among other features).

WordPress Database Backup

WordPress Database Backup automates the backing up your blog’s database — can have it email a compressed copy or save to your server or computer.  Your theme along with your database are the key parts of your blog.  Having a backup of your database means you can recreate your blog if you have to.

WP Greet Box

WP Greet Box customize a message to your blog visitors depending on where they came from.  For example, ask visitors from Digg to Digg your post.

WP Minify

WP Minify WordPress plugin helps your blog run faster by combining and compressing javascript and CSS files to improve page load time.  I’ve seen a huge improvement since using this plugin.

WP Super Cache

WP Super Cache adds caching to your blog (which you can control) to make the pages load faster.  Site speed is now a consideration for Google’s PageRank.

What are your favorite WordPress plugins?

(photo by Sarah Worsham)

This is a guest post from Chris Reynolds from WebHostingSearch.com, which provides web hosting listings & ratings.

Today, social media sites have come to be a critical part of the world’s web surfing experience. Social media campaigns demand innovative and accommodating web hosting. Due to the variety of social media formats, from forums, weblogs, and podcasts to wikis, web hosts have to be flexible and responsive to their clients’ needs. A common thread among social networkings sites is the sharing and discussing of personal information, so any social media campaign must take this into account.

A successful social media campaign may generate a great deal of traffic. This means that bandwidth usage often is through the roof. So fast servers are a prerequisite to launching a social media effort. The demand for high bandwidth grows more critical everyday as different media elements are added to social media sites as well: applets, pictures, video, and instant messaging functionality all place extraordinary demands on today’s web hosts.

Responding to public interest is where web hosts have to excel. A targeted SM campaign will mean a dramatic increase in traffic as the public start responding to your message. This increases the risk of server overload, so web hosts must be proactive in accommodating high demand. Not just any site content will do, either. Timely content management is essential for not only attracting new users, but also for cementing long-term interest as well. A site that is seldom updated, poorly maintained, and/or languid and unamenable to suggestions will fail to generate and maintain substantial web traffic, the goal of any successful SM campaign.

Since content management is vital to social media, web hosts need to provide a variety of tools to assist with the installation and editing of web content. One outstanding software package that can aid in this regard is Drupal, which can assist individuals and enterprises with web publishing. Drupal’s built-in functions and free add-ons can assist with blogs, peer-to-peer networking, and file uploading. Another helpful instrument for web hosting is cPanel, which provides for layered administration, tight security, and a depth of features unavailable anywhere else on the market. This program is an invaluable toolkit for getting new sites up and off the ground, the most crucial phase of any SM campaign.

Having the right web host can make your social media campaign much more effective by handing whatever increase in traffic you’re able to achieve. And a good content management system will allow you to post and manage updated content to keep that traffic coming.

With these tools and tips in mind, a potent social media effort is only a few clicks away!

Is Apple’s new iPad a game changer or just a shiny new toy for Apple fans? What games will it change (if any)? What niche does it fill and what impact will it have for business? Quick News – Apple, Hulu, Blockbuster. Web Strategy & Marketing News & Tips.

Show notes. Here are the links we discussed in the podcast:

• iPad Day In Numbers: 300k Devices Sold, 1 Million Apps And 250k iBooks Downloaded
  (TechCrunch)
• Kleiner Perkins Doubles The iFund To $200 Million, Ready To Fund iPad App Makers (Silicon Alley Insider)
• Don’t Forget, The JooJoo Won A ‘Most Brilliant Product Of The Year’ Award Before Going On To Sell 90 Pre-Orders (Silicon Alley Insider)
• Yelp Changes Site To Make It Less Extortionist (Silicon Alley Insider)
• Digg’s Kevin Rose: DiggBar Is Bad For The Internet, So We’re Killing It (TechCrunch)
• Fox And Sony Throw Blockbuster Another Lifeline (TechCrunch)
• Hulu Turns Profitable, We Eat Crow (Silicon Alley Insider)
• Digg CEO Jay Adelson steps down (Cnet)
• Why I won’t buy an iPad (and think you shouldn’t, either) (Boing Boing)
• The iPad and computing’s middle ground (O’Reilly Radar)
• Is iPad a game-changer? (Scripting News)
• The iPad in the Eyes of the Digerati (NYTimes)
• Ars Technica reviews the iPad (Ars Technica)
• The iPad Backlash Begins: “After having slept with her, I am having morning-after regrets.” (Silicon Alley Insider)

Subscribe to the Sazcast podcast:

• Subscribe in iTunes
• Subscribe to the feed

To see all the Sazcast episodes, click here.

If you have a topic idea you’d like us to discuss, please email us at sazcast [at] sazbean [dot] com or send us a message on Twitter @sazbean. Please consider reviewing us on the iTunes site or emailing us your comments and ideas at sazcast@sazbean.com. Intro Music by: Band: Tripudio, Song: Blue monday

You may have seen these funny little boxes around – possibly in a magazine or in a store window.  They’re called QR Codes (Quick Response Codes) and they allow the encoding of information.  For practical terms, if you were to scan one of these codes with a code reader from your phone, they’d could take you to a website where you could get more information.  But in order to work, they require you to install software on your phone (and to have your phone or other device with you).  So, is this making it easier or more difficult for someone to get more information?

Requires a Scanner

While most of us carry a phone of some sort, not all of us have phones that support a code reader application (although that will probably improve with time).  Most of us aren’t going to go through the hassle of installing a code scanner unless we perceive some sort of benefit.  Why should I install software to read a QR code when I can just go to your website?  Or search for your product name online?

Connecting Offline with Online

Marketers are interested in these QR codes because they allow another way to track specific promotions offline that lead to an online visit (and lead collection or a sale).  Measuring and understanding which campaigns are working is key to knowing where to invest resources.

Unique Information

QR codes do allow for encoding of more information than just a website address.  So there is the possibility of providing information that could not necessarily be gathered right from a URL.  The example given for use in print advertising is scanning a code to find the location nearest you with the lowest price.  Or maybe a restaurant could offer a special discount for those who scanned in and read what the day’s discount code is.

Providing a Benefit

I read the MIT Tech Review (yes, in print) and they had one of these QR codes after an article offering a special report.  While I was intrigued, I wasn’t near my phone (one of the reasons I get the magazine in print is to get away from the gadgets for a few minutes).  I also wasn’t really interested in installing special software just to get the report (especially since it was described in online one sentence).  But the idea of providing valuable content only if people scan a QR code (and thus give you a lead) is interesting.  I’m just not sure how it’s different than pointing them to a web page with a unique address.

Security Concerns

Because the QR codes are directing mobile devices to a website, it may be possible to have the phone then run some malicious code.  Or if the code points to something else, you won’t know about it until you’ve scanned it.  These concerns are probably minor right now, but there is something to be said when humans can’t read the codes ahead of time.  (Mechanical Poetry has some more information about possible security concerns with QR codes).

Intriguing Uses

Using these QR codes instead of loyalty cards may provide a benefit that consumers would want.  Although I think that services such as Foursquare make this easier with check-ins based on location.  One thing that would be nice is the ability to scan a code and then be able to search the Internet for the best price (although this would be possible with regular barcodes).  The ability to connect offline and online is enticing.  I’m just not sure if this is the right technology to do that.

What do you think?  Have you seen these QR codes?  Have you used them?  How could you see them being used?

Additional Reading

• Getting Creative with QR Barcodes; Funny Little Graphics That Contain a Lot of Information (Hugh Briss)
• Magazines Still Wasting Time With Stupid Barcodes (The Business Insider)

Liked this post? Consider subscribing to Sazbean.com through RSS feed or by email or following us on Twitter.

Technorati tags: QR codes, internet strategy marketing, web strategy, strategy, marketing, business strategy, business

I am wandering the halls of a technical conference, in Sandusky, Ohio this week.  Its called CodeMash.  While the presentations are solid, the real value add has been and always will be the hallway conversations with people in the tech field.  One thing I have noticed this week is a subtle but important change in business protocol.  We no longer exchange business cards, we now exchange twitter handles.

I’m not ready to completely throw away my stack of MooCards quite yet, they are still the Lingo Franco of the business meeting.   But the box I have should last me for the next 30 years if the twitter trend continues because more and more people are just exchanging handles.

There is an efficiency to trading that simple @name that we used to get from trading email address back before spam was such a problem.  Once you have someone’s twitter name on your follow list, they are a part of your online persona wherever you are.  Want to meet up with them on a sales call, just DM them.  Interested in getting their opinion on some idea, include them in an @.  If they have a public face online, knowing their twitter address is just about the best way going to keep in contact.

So add your twitter handle to your business card.  If there isn’t enough room, drop something less important – like your phone number.

Choosing the right web hosting company can be difficult for a non-tech person.  There are so many price points, so many options, and so many features to choose from, most of which probably don’t make sense to the average person. I’ve met many people who are either paying too much or too little for a web hosting service that meets their needs.  While cheap plans are attractive, they’re not always the best choice.  Here’s some things to look for:

Support

Most web hosting companies will offer some level of support, but is it by email, phone or ticketing system?  What is their response time?  Will they guarantee that they’ll get back to you within a set number of hours?  Can you pay for a higher level of support?  Support often is overlooked, but if your business relies on your website, and most businesses do to a certain extent, how long can you afford to have it down?  Businesses who run an online store will have less tolerance for downtime than other types of businesses, since the website is their business.

Backups

Cheaper web hosting usually doesn’t provide any type of backups, so you’ll be responsible for keeping a copy of your website (plus any changes that have been made) and any databases or applications you’re using.  Many web hosting companies have a control panel which allows you to make backups with only a few clicks.  The problem is remembering to do them (plus keeping the backup in a safe spot).  Almost all web hosting companies will have backups offered as an upgrade, and some even offer them as part of the regular service.  Backups may not seem important until there’s a server problem and you lose the website that you spent hundreds or thousands of dollars developing.  Backups area a must for any online store.

Space

Even the cheapest web hosting packages usually offer way more space (hard drive space) than you’ll ever need because space is pretty cheap.  However, if you have an online application or if you host a lot of images, audio or video, space may become an issue.  Take into account any costs for going over your space limit and whether the hosting company has any space upgrades.

Bandwidth

Bandwidth is basically a measure of how many files and pages can be downloaded or accessed from your site.  Every time someone visits your site they are using some of the bandwidth.  Bandwidth limits usually aren’t a problem unless you’re hosting a lot of video, audio or images (large files), but you still should be aware of how much is included, how much it costs to go over the limit, and whether you can upgrade your limit in the future.

Ease of Use

How easy is the web hosting to use?  Do they give you a control panel or some other web site that allows you to manage and upload files to your site? How important this is depends on your particular level of knowledge and what you’ll be doing with your website.

Control

How much control are you allowed over what can go on your site?  Does the web hosting site restrict certain types of applications or files?  Will you be able to run whatever applications you need to for your site?  Can you make changes to your site or do you have to go through support?  How much control you want depends on how comfortable you are with the technical side of things.  If you have a web developer working with you, you’ll want to make sure they can do what you’re paying them to do without too much hassle.

Upgrades

As your site grows, will you be able to purchase upgrades for space, bandwidth, functionality, etc.?  How long can you stay at this web hosting company without having to look for other options?  What upgrades do they offer?  Do these upgrades fit with the growth plan you have for your site?

Guarantees

Most reputable web hosting companies will offer some type of guarantee for uptime (99% uptime, etc.).  Some of the cheaper packages won’t have any guarantees, or will guarantee less.  Either way, how do they back their guarantee?  Will they offer you back some of the hosting costs?  What does their guarantee cover?  What about lost sales or business (usually not except with higher end hosting)?

Security

How important is security to the hosting company?  Do they do software and server upgrades to keep up with security patches and problems?  Some hosting companies will do this for you and some will expect you to keep up with them.  When you have to do them yourself, sometimes it’s just a matter of clicking an upgrade button on your control panel, and sometimes its much more difficult.  Security is pretty important for web hosting since a compromised server often has to be completely wiped and rebuilt.  What security is offered for online stores?  Do they have their own security practices?

Integration & Flexibility

Related to control – how much integration does the web hosting company allow with other applications and web services?  Will you be able to use your own shopping cart or analytics software?  Do they provide applications?  Will you be able to integrate your website with internal applications?  You may not need integration to begin with, but it may be pretty important down the road.

Freebees

Many people get caught up in all the freebees a web hosting company offers, but many of these freebees are offered for free to anyone on the Internet.  However, sometimes hosting companies will offer more valuable freebees such as Google AdWord credits or other online advertising.  They may also offer applications that you would otherwise pay for (such as some types of shopping carts, email programs, or customer relationship management systems).  Whatever the case, figure out just how valuable these offers are to what you’re trying to do with your website.

Looking Ahead

Choosing the right web hosting company should start with an understanding of what you want your website to be and do – both now and down the road.  If you eventually have higher plans for your site, but want to start with cheaper hosting, that’s fine, but make sure you know how and whether you’ll be able to move/upgrade your site when you’re ready.  Pick the hosting company that works with what want to do now, has a good reputation, and easy to work with.  Ask around for recommendations.

What’s your experience with choosing a web hosting company? What questions do you have about hosting companies?

(photo by DeclanTM @ Flickr CC)

Liked this post? Consider subscribing to our RSS feed or our free email updates or following us on Twitter.

Technorati tags: hosting, web hosting, business, web server

Have you noticed that Industry insiders like to invent their own language?  You are following along in a fascinating conversation about some interesting aspect of something and just when it is all coming together and you can sense a real strong point being made, the speaker looses you completely on some strange term or phrase or, god forbid, acronym that they just assume everyone must grok*.

Tech sector is infamous for an over reliance on short hand terms and acronyms who’s only definition are even more obscure terms or acronyms.  These little words have become an invisible wall, in my opinion.   If you are in the Online Marketing industry, wouldn’t you like to have your ideas and thoughts included in the conversation instead of dismissed out of hand because you aren’t using the exact correct word in context?  It is something that really worries me about my industry.

I’d like to help the outsiders get back into the conversation.  Maybe this post is a start, I don’t know.

Domain names are something I think most of us use and have some familiarity with.  If you are in Online Marketing, domain names are a big part of your business.  Online business strategy, too, needs to know about domain names.  But most don’t really know what they are because they cannot explain them to their mother (my golden rule for when you really understand something)

Lets get started.  First, don’t let anyone tell you otherwise, domain names have one and only one function on this earth.  They take an internet address that is written in numbers and is easy for a computer to read and they convert that into characters that are easier for humans to read.   That is the sum total of what they were invented for.

Addresses: So imagine that its 1918 and the modern US postal service is just getting off the ground.  They need a way for Americans to send a letter across the country without instructions like ‘go find Bob Jones somewhere in Seattle’.  They come up with a system of codes where, from specific to general, you can identify any house in the country.  Exact same is true of Internet Addresses, where general to specific (reading left to right) you can find any computer on the internet.  Im telling you, as a Cisco Network Engineer in a former life, anyone who tells you it is more complicated than that is confusing the point.

Domain names early on: So clearly and IP address like 192.168.0.1 doesn’t mean much to most people.  We kinda got stuck in the telecom industry when we only gave people 9 digits on their phones, forcing them to remember long strings of numbers which had no real meaning to them personally.  Lame attempts to map letters to digits like 1-800-CALLBOB didnt really help much.  Learning from their mistake, computer people realized they needed a more flexible way to related these internet addresses to the actual people who were being the computers.  This is the important bit.  Internet Addresses were for the benefit of the computers themselves, but domain names were designed only for people; the computers could have cared less about them.  They came up with a very simple idea, keep a list that maps an IP address like 192.168.0.1 to one or more words that people can remember.  In the early days this was all it was.  An IP address pointed to a computer, lets say it was physically at the University of Berkley computer lab.  Someone decided that computer’s name was Pinky.  They updated to shared list on the internet to say that, hey if you are trying to send a message or call that computer in the Berkley lab, just remember its name is Pinky.  Bada-bing, you now have the start of domain names (host names, actually, but the same purpose).  The human types in a command to send something to Pinky, that computer doesn’t know where Pinky is, but knows where the list is to look it up.  It finds the IP and sends the message

Modern Domain names: From these humble beginnings, modern domain’s were born.  If someone handed you a list like the one above, mapping ip addresses to single words like Pinky, you might be cool with it in the beginning.  Small number of computers, and even smaller number of people on the internet making up the names for these computers means its not too difficult to keep up to date.  But we all know that didn’t last, the number of computers and people on the internet grew, and grew quickly.  Soon there were ten different people, in different locations, fighting over calling their computer Pinky.  No problem, we will add a new level, call that the domain name, and make it something geographic or organizationally relative.  So now pinky.berkley is a completely different computer from pinky.darpa.  Do ya one better, since Berkley the college was getting nasty emails from Berkley the pizza parlor who also wants to have their computers online, we will throw in another layer that separates domain names into educational, companies, government, and others as needed. pinky.berkley.edu is a completely different computer from pinky.berkley.com  Problem solved.  These new names are now organized just the way computer people like it.  There are now plenty of names to go around, just get creative and have fun.  The name land grab begins. Ok, but now bob who maintains the list is getting sick of it and anyway, isn’t this what computers are good at?

Domain servers: Fine fine fine, if bob doesn’t want to keep up the list that says pinky.berkley.edu points to 192.168.0.1, we’ll use computers to do it for us.  Lucky for us, because we setup those layers of host name, domain name and TLD or top level domain, we can do something cool that we call distributed responsibility.  So in modern domain name lookup, it all still starts with a list, just like the beginning.  That list, now, no longer tells you the IP address of pinky.berkley.edu  though.  It tells you where you can ask to find out, kinda like asking the guy on the corner for directions and he telling you to go ask that other guy cuz he grew up in this neighborhood.  So at the top there are dozens of servers, run by governments and large non-profits that keep the list of who to ask for a domain.  Their responsibility is broken up by the TLD, or the end of the domain like .edu or .com  If you want Pinky.berkley.edu you ask server A but if you want Pinky.berkley.com you ask server B.  This is why it is kinda a big deal when governing bodies approve a new TLD because its is a pseudo monopoly on all those people waking up to the corner asking for directions.  So server A looks up in its list and says, for the IP address of a computer in the berkley.edu domain, go ask this server at 192.168.0.2  the computer says to itself, ok thanks for nothing, and goes to ask that other server about the IP for pinky.  Here is the magic.  That IP address that the top domain server gave you points to a server that the guys at Berkley university control.  They keep the list themselves, handing out the IP addresses they rent from their Internet Service Provider.  Thing is, since they control the specific list on berkley.edu, it is up to them to name their servers whatever they want.

Web addresses: The web is a more recent invention compared to the internet, and as such its web site names borrows from the domain name idea above.  You have your TLD, like .com, and you have your domain name, like berkley.  You also have a host name, only usually it is www instead of pinky.  That part gets you to the server.  The rest is suppose to get you to a specific file on the server.  So http://www.berkley.edu/directory/on/server/fall_classes.doc is a combination of the server you are looking for and the location on that server of where to file and finally the name of the file you want.  That http part in the beginning is kinda your native language, like when you walk up to a stranger in the airport and say ‘you speak English?’

That’s domain names in a nutshell.  I hope this has helped.

I’d like to do one of these each Tuesday, but I need your suggestions. 

What tech subject would you like translated into English? Email me at aaron@sazbean.com

* An example of a word I struggled with early in my tech career because it is just assumed you have read Stranger in a Strange Land.  It means to ‘understand’ something.

photo attributed to polandeze

Yesterday, we had part one of our interview with James Lindenbaum, CEO of Heroku, which provides hosting for Ruby on Rail applications.  We had a great conversation with James, but there was a bit much for one post, so we divided the interview into 2.  Here’s the second part of our interview….

Sazbean: How should business users that are new to Ruby on Rails (ROR) use Heroku?

James: There are several different things about Heroku that make it unique:

Firstly, it’s free to get started.  Which is great for small apps, testing, etc.  It’s very cost effective and very fast.  This means that businesses can actually develop all those good ideas without having to worry about the costs associated with hosting and deployment. Rails is so productive that you can have an app up and running in a few days or weeks – letting businesses test a lot of ideas very quickly.

Secondly, businesses don’t have to worry about the transition when going from an experimental application to a live application.  We handle everything for them.  We have all the heavy duty enterprise stuff you need when your app grows.

We also are very useful for staging.  Most companies have a very complex deployment process, with servers for development, testing, and production.  There are a lot of challenges in keeping all those environments identical, which you need to do to avoid having unforeseen problems in production.  In Heroku, all environments are identical and with staging servers, which don’t use very many resources, you pay for only what you use, making it very economical.  You can quickly create and destroy servers, so many developers are creating a new staging server for every version and leaving them in the account so they now have an audit trail to do regression testing.

Sazbean: What do you feel differentiates Heroku from your competitors?

James: There are a few things we do uniquely.  We’re the only place where you can deploy provisionlessly – just push your code and you’re done.  No steps to worry about.  We’re also the only multi-tenant platform, other than Google’s App Engine, so the platform is always up to date.  All improvements we make to the stack get rolled out to all applications.  Heroku is handling all the maintenance of the application for you.  Our scaling time is so fast – just drag the sliders and after a couple of seconds your application is scaled up.  This is really important so people can quickly match changes in demand for their application.

Sazbean: How well does Heroku handly dynamic provisioning?  If your site gets covered in TechCrunch, how does that work?

James: Right now there has to be a human decision, but it’s very quickly scaled up and we handle all the details.  We’ll do auto-scaling in the future.  We basically already have it, but we’re still at a stage where people don’t really understand how rails apps perform.  When we ask people how they want to scale an app, they don’t know.  So we need to let the community catch up so they can help figure out how apps should be scaled up and provisioned.

Sazbean: Do you provide tools so people can figure out where they should be for provisioning?

James: Not yet.  That’s right around the corner.  We’re coming out with some great features soon.  Most people use New Relic right now, which is a plugin that collects performance information about your application and then provides graphs and charts so you can see exactly what’s going on.

We have some really interesting use cases now that we have over 30,000 apps running on the platform. HeyZap, a casual gaming company, created a Swine Flu game – Swine Fighter.  They built it and then publicized it and were featured on Times, Reuters and other news sources.  They’re running on Heroku and they came to us when they were going to be in USA Today in just 2 hours.  We told them to scale up their dynos, so they did, and that was that.  They were able to serve millions of users over just a few days.

We have another customer who wrote an application for a site in Hungary that’s like Facebook.  It really took off like crazy.  6 or 7 weeks ago they were doing 300-400 dynamic requests per second, sustained.  Even at night they were doing 40 requests per second. We were able to push through 1/2 billion page views, and that doesn’t count any of the caching that was going on.  We scaled up that fast in just a matter of days and they’re able to scale up and down with the demand.

Sazbean: Where do you see the market growth for enterprise Ruby on Rails (ROR)?

James: From our internal numbers, it’s growing, but hard to say across what industries.  We have Fortune 500 companies registering all the time.  But bigger enterprises are always slower to adopt.  So, you see what you’d expect: bigger companies are starting to use Heroku for staging, testing, rapid prototyping and smaller apps.  Some are using it for larger, mission-critical apps, but they’re still the outliers.

Sometimes when someone registers from a big company, we contact them to see if they’re using Ruby at work. Last year, they’d say “no, we’re only allowed to use Java at work, I’m using Heroku for a personal project.” Six months ago, they’d say “we’re not supposed to be using Ruby, but there are three of us working on this project, and we’re using Ruby, and don’t tell anyone.” Then a few months ago, the story started to be “they came to us and told us we had to get this project done on a really short timeline, and we told them we could only get it done if they let us use Ruby. They did and the project was a success, so now we’re doing a medium-sized Ruby project.”

We have a large company that has a 400-person development team, doing Java and Perl, and they realized they weren’t agile.  So they restructured into 20, 20-person teams, with 2 of them being Ruby teams.  Immediately, the 2 Ruby teams are just way more productive, so all the business people want their stuff going to the Ruby teams because it’ll be done in 2 weeks and it’ll be pretty.

We also have Ruby teams who finish projects and then they go to IT to deploy and IT says they can’t deploy it or it’ll be 3 months to provision for it.  So the Ruby guys go to upper management and say, “look we’re building these apps in a matter of weeks, and IT provisioning is taking twice as long as the entire project to deploy.  You’ve got to let us go outside.”  So, they get to go outside, but then there’s no support from IT and you have two choices: a service-driven, highly managed hosting provider with a lot of guys to help (which is very expensive), or Heroku, where things are harder to break.

One of our big drivers right now is the inability of IT to keep up with the rate of development.

Related posts:

• Another Interview with James Lindenbaum, CEO of Heroku – Part 1
• Heroku Out of Beta – Fast, Easy & Cheap Ruby Hosting
• Heroku – Technical notes
• Interview with James Lindenbaum, CEO of Heroku

Technorati tags: heroku, ruby, rails, programming, hosting, ruby on rails, ROR, web programming, agile development, web development

Liked this post? Consider subscribing to our RSS feed or our monthly newsletter.

Heroku (who we’ve covered here, here and here) provides provision-less hosting for Ruby applications, letting developers focus on developing.  The hosting service allows developers to  just push their code and it’s up in running – no worrying about running scripts, or setting up servers.  Heroku recently came out of beta and now offers commercial, paid service.  A few weeks ago, I had the chance to speak with Heroku’s CEO, James Lindenbaum, about their recent developments:

Sazbean: So it’s been a few months since the commercial launch, how have things been going?

James: They’re going really well.  The uptake has been pretty incredible and we’re trying to keep up with it in terms of young billing systems, etc.  Lots of people are finding a lot of value in what we’re providing and there’s a good mix of paying customers – some previous beta customers and some new people.  Lots of people really liked our service but had a lot of questions about what the service was going to cost when it came out of beta.  Now that we’ve answered that, more people are comfortable with signing up.

Sazbean: Why’d you decide to go with the tiered ala-carte pricing?

James: We spent a lot of time thinking about pricing.  We tried different types of pricing with some of our beta users and got a lot of feedback. We’re in a very interesting spot.  We’re a very modern, sort of next generation platform which takes advantage of the cloud.  A lot of people wanted to see a usage-based, metered system – pay by the drink – and we’re able to do that because of the cloud infrastructure.  On the other hand, we wanted to provide a very simple, easy way to do things – the small/medium/large idea.

So, we’re trying to satisfy both groups with a hybrid model. If you don’t want to think about it, pick based on the size of the database, choose the appropriate dynos and go.  Or you can fine tune all of your performance options.  But, it’s still a work in progress – it’s a good first step and we’re going to continue to work on it.  It’s been very well received so far – even better than we expected.

Sazbean: What was the reaction at Railsconf in May?

James: It was pretty good.  We had very good acceptance.  We changed the format of Railsconf this year with 4-5 minute vinettes about different features.  People really loved it and felt it provided a lot of good information.  We had a lot of good questions in our product talk. We have 12 people at the company now, and a lot of good thought leaders in ruby, who were able to get out there and talk.  We love conferences because it’s nice to feel the enthusiasm and energy from the ruby community – and a great opportunity to get face-to-face feedback and reactions from people.

Sazbean: What should non-technical business people know about Heroku?

James: Most of our future development will be in the add-ons section of our service.  We’ll be providing functionality higher and higher up the stack in terms of application performance management, monitoring and data replication, which will be more business-value oriented and less technical in nature.  We’ve checked off the low-level prerequisites and more business-value oriented features are coming. It’s as easy as ever to deploy applications using our platform.  We have many people using the platform for enterprise, mission-critical applications and there are a lot of success stories where they’re either saving a lot of time or able to use a lot of agility in the development process due to our platform. We’re selling productivity, time and agility.

Sazbean: Why should business people want Ruby on Rails (ROR) used for their applications instead of other languages?

James: Exact same story here.  You can be so much more productive using ROR.  It’s so much faster to write a usable, useful application, and a lot easier to do things the right way on rails. With rails, out of the box, as long as you don’t do anything unusual, you have an application that just works – it spits out all the proper caching headers, provides restful resources and APIs, helps you not repeat yourself, keeps your model/view/controller logic separated – just makes it easier to write a good application.

Java lets you do things the right way, but it’s a lot of work – it’s very heavy-handed.  And even with the newer stuff, it’s also not as flexible.  When you want to make significant changes to your business process, you have a lot more work with Java than a language like ruby.

Php doesn’t have enough structure.  I love php and wrote a lot of enterprise php applications.  The newer frameworks are pretty good, but it still doesn’t get you as far as you are with rails.

.Net is similar to Java – very heavy handed, a lot more work to do things.  It’s not rocket science, it just takes a lot of little elements to get things to work.  And if you don’t have to do all those little things, you can concentrate on the more important things.  It’s like carrying a really heavy backpack all the time – you get used to it – but one day you don’t need it anymore, so you set it down – and all of a sudden it’s incredibly liberating.

Heroku is trying to provide that same level of benefit for hosting that rails provides for development.

More of the interview in Part 2, tomorrow…..

Related posts:

• Heroku Out of Beta – Fast, Easy & Cheap Ruby Hosting
• Heroku – Technical notes
• Interview with James Lindenbaum, CEO of Heroku

Technorati tags: heroku, ruby, rails, programming, hosting, ruby on rails, ROR, web programming, agile development, web development

Liked this post? Consider subscribing to our RSS feed or our monthly newsletter.

Everyone in the auditorium knew when she stood up that this was going to be an interesting weekend.  Sister Mary, dressed in a stark white Habit, stood out from the crowd of  faded jeans, Converse low-tops and silk screened Tee shirts with ironic catch phrases like some lost Lawrence Welk fan at a Neko Case concert.  But what she told the audience, how passionately she expressed her excitement for what was in essence just a new website, was nothing new by then.  They had heard the same that night from a dozen other local charities and non-profits participating in GiveCamp 2009.  Each charity started the weekend thanking the programmers and developers and designers for donating the next 48 hours of their lives to creating something for their own personal cause.  So unaccustomed to this kind of appreciation for their unique gifts in this world, the audience of software and computer experts were overwhelmed to tears more than once.  At least I was overwhelmed to tears at the opening ceremony, cresting at the pique of the emotional wave with Sister Mary shouting thanks to God that ‘The Geeks Are Coming!’

GiveCamp.org is as simple an idea as it is brilliant.  Lawyers give away their valuable time to those in need Pro Bono and doctor’s donate their expertise in free clinics in poor neighborhoods the world over.  As computers and the languages that make them run have evolved in complexity, those that truly understand them have been awkwardly elevated to a similar class of professionalism, complete with wildly expensive hourly rates.  These rates typically outpace even the broadest of charity donation bases, and come from areas first to be cut when donations slow and budgets get tight.  The community’s response to this need was GiveCamp,  a highly organize, large scale free clinic to distribute injections of software for those most in need. Software companies donate their products to the charities, hosting companies give away space on their servers and the community provides their experience and skills, free of charge, to work on one project per charity over a shotgun 48 hour weekend.

This was my first Give Camp, held in Ann Arbor, MI and conducted in concert with sites in columbus and Knoxville.  Eighteen local Michigan charities were selected and paired up with teams of programmers to deliver some software solution or website that the charity needed in their organization.  I understood before even arriving on Friday that this was a kind of ‘giving back to the community’ wholly unique to computer people.  You see, we are famously known for our bursts of manic focus and obscene late night work schedules, so GiveCamp feeds these tendencies by being an all-day all-night team relay race to the finish line.  You and your charity must complete as much as you can in all 48 hours you are given.  Like a Reality TV show, Give Camp creates its own little universe where sleep is for the weak, coffee is the ambrosia of the gods, and newly introduced teammates become strong, fast friends as the obstacles mount and the enormity of the goal looms in the distance.

We were not in competition against each other, only against the clock and our own palatable desire to solve the charities programming puzzle and make them happy.  The local Boy Scouts, for example, were paired with my self and my teammate to create a campsite reservation site.  This hugely time consuming, mind-numbingly redundant task is one that any other company or organization with an internal IT staff would have automated before the fax machine warmed up.  For us, for two days, this problem was our whole world

To an outside observer Give Camp can look like an ant colony tipped on its side.  Sixty programmers and organizers running through the halls of a borrowed community college building at 3 in the morning solving each other’s problems.  ‘Don’t get Stuck!’ one would shout, answered with ‘Don’t work past Stupid!’  It may not quite be exciting enough for an Aaron Sorkin drama, but it was probably more entertaining to watch than Michael Bay’s latest production.  In the small of the night, truly amazing things can and do happen.

It was Sunday, fifteen minutes before closing ceremony, when my team officially crossed the finish line and delivered our app to the client.  You can see it here.  Honestly what I saw when I handed the code to James, local Boy Scout administrator and our weekend contact, was all the things left we could have done.  What he saw, however, was all that it did that otherwise they would have to do themselves.  At the closing ceremony it was the same story for all the groups.  The Charities had a weekend with a team of talented programmers and what they came into the auditorium with made a huge difference in their organizations.  After another hour of speeches and applause and thanks with maybe some more crying, each developer returned home to fall soundly asleep before 8pm, maybe for the first time in their lives.

Give Camp is one of those richly rewarding experience that is the exclusive domain of the geeks.  We  own this space, it is ours and it is up to us to make Give Camp 2010 even better.  Go to GiveCamp.org and sign up now.

Technorati tags: givecamp, code, programming, agile development, business, charities,charity programming

Liked this post? Consider subscribing to our RSS feed or our monthly newsletter.

I attended KalamazooX over the weekend, which was a great combination of design, business, and technical presentations.  As someone who has transitioned from a programmer into marketing & strategy consulting, it was nice to see content that wasn’t just staring at code.  I believe some of the slides are up online, but here are some thoughts, not from every presentation, but from some of my favorites:

Dave Giard – Effective Customer Communication

• Communications is a two-way street – both sides are responsible.
• It’s important to get/give feedback early and often.
• You need to add value for the customer – what does the customer feel adds value? – need to know this up front.
• Weekly status of what you did, what you plan to do next week, any issues/problems.
• A daily standup (including the client) is better.
• The most important part of verbal communications (any communications) is listening.

James Bender – Organizational Dynamics

• Plug into the company’s information highway (water cooler, wiki, blog, intranet, etc.).
• Be someone in the know.
• Evangelize yourself and your ideas (and also your team!).
• Build coalitions.
• Learn the right way to gripe.

Josh Holmes – The Art of Simplicity

• The definition of simplicity from Websters includes: lack of sophisitcation, good sense or intelligence – which is how technologists often think.
• Systems need to be designed so the user knows immediately what to do and starts doing it.
• A simple design does not mean that the problem solved was simple.
• Users may not see a request as complex – they just know it will make their experience better.
• Agile is a buzzword, but it’s what techs need to be in order to solve problems.
• The right solution is not the one other technologists understand – its the one the user does.
• Enterprise automatically adds ten times the complexity.
• Consumer space has solved bigger issues in simpler ways.
• We usually don’t understand who are users are – the top 3 things they do.
• Use the right tool for the job.
• Solving someone’s problem adds value.

Brian Prince – 5 Easy Ways to Be More Agile

• Be Subversive – start doing things without permission, without changing what you’re doing, help people see value.
• Stand up Meetings – what was done yesterday, doing today, roadblocks.  Don’t solve problems – have speaking token.
• Keep – Stop – Start Meetings – Introspectives at end of each iteration.  What should we keep doing, what needs to stop, what do we need to start doing – assign people to solve by next iteration.
• Must – Should – Could – Won’t Priorities (from user’s view).  Keep quality and priority in the picture.  Use quality in equation always.
• Keep users and client as close as possible (not usually the same).  Ask – share – show.  Tell stories.  Use simple planning wall.

Leon Gersing – Change

• Make little changes until you don’t realize that you’ve changed.
• Be open to change.
• Know who you are.
• Don’t let others define who you are.
• There are 3 states in life – job, career, enjoying life – which are not always the same.  Know which you’re in.
• Change where you work (not always the employer, but sometimes the environment, or your state of mind).
• If nothing ever changed, there would be no butterflies.

Technorati Tags: development, code, kalamazoox, code, coding, programming

Liked this post? Consider subscribing to our RSS feed or our weekly newsletter.

Heroku, who we previously covered here and here, offers quick and easy Ruby hosting.  Today their service came out of beta, with a commercial, paid version of it’s service.  Web developers can focus on development, leaving deployment, hosting and scaling of the application to Heroku.  Meant to provide affordable services which easily scale, packages start around $36/month.  As the popularity of an application increase, Heroku can match demand, allowing developers to start small but scale up on the same platform.

Developers can customize their hosting by choosing database performance and size, http performance, and add-ons.  Databases start with 5MB of storage for free and run up to 20 compute units and 2 TB of storage for $1600.  Http performance, which Heroku calls dynos, representing one process of an application, and are priced by hour starting at 1 dyno for free and 40 dynos for $1.95/hour.  There are recommended amounts of dynos for each type of database, starting at 2 for the smallest, free version.  Add-ons include additional backups or crons (some are included), with wildcard domains and delayed jobs in beta, and memcaching, workling, and AMQP planned soon.

More coverage:

• Heroku to Exit Beta, Start Charging for Cloud Computing (GigaOM)
• Commerical Launch (Heroku)

Technorati Tags: heroku, rails, ruby on rails, ror, rails hosting, internet consulting

Liked this post? Consider subscribing to our RSS feed or our weekly newsletter.

Computer people just love to name things.   The server guy who names all his machines after Star Wars characters competes with the network guy who names all his routers and switches after Star Trek characters to see who has the more obscure references.  Usually the Desktop guy wins with his collection of Windows PCs named after Transformer characters, but that’s beside the point.  It sounds like it is all in fun, but there is a very important reason we all do it.  Technology is hard for humans to relate to.  It is cold and lacks personality.  Names help give definition to the undefined. They help give things context.

Programmers, being computer people,  really get into the naming of languages and processes.  I’d like to take this post to identify and briefly explain some of the terms you may have heard your programmers using.

Agile development

If San Francisco could be considered not just a place but a lifestyle, Agile development would have a similar vibe in the programming world.  Typically it refers to the 12 guidelines people in software teams follow when working together on software projects, though there are widely different ways to actually put those guidelines into practice.  The ideal behind an Agile development team is that it is small, it meets all the time with each other and with the clients, and it writes code in small chunks that the customer sees working every couple weeks.  Agile was a reaction to the inflexibility of older programming procedures that didn’t allow the customer any flexibility to change their mind late in the delivery cycle.  Since customers are constantly rethinking their needs, Agile was developed to allow the code to change with the requirements.  Below are the 12 principals of the Agile Manifesto.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development.  The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Scrum

HR, Sales and Accounting may have meetings, but only programmers can take the basic idea of getting together in the same room and rename it a ’scrum’.  Borrowed from the term used to describe a huddle in rugby, a scrum is a highly organized, short daily meeting of all people involved in an agile project.  It has the singular goal of keeping people focused on the project, which is really important since a ’sprint’, or stretch of time allotted to write working code, is usually only two weeks.   Guidelines for scrums can sound harsh, only three questions are asked, everyone should remain standing, only people with a stake in the project should speak, but it was invented in direct contrast to pointless time-wasting mega-meetings that the Dilbert comic made an empire satirizing.

Extreme Programming & Test Driven Development

Who wouldn’t want to work on an something with the word ‘Extreme’ in it, huh?  Extreme Programming (XP) is very similar to Agile, or it might be more accurate to say that it is a good case study of Agile programming before there was such a term.  The real big take home from XP that sets it apart is its absolute devotion to the idea of testing.  Now, as a lil programmer, I thought testing code was for suckers who worked government jobs.  Then I was turned onto the wonders to full stack testing and how it changed my whole outlook on my craft.  Testing is really the only way to write Enterprise ready code.  Some guys saw that if you wrote your tests first, then wrote code that made the tests pass, your applications would have fewer bugs.  They called it Test Driven Development (TDD).   Turns out testing is becoming the rock star of the programming world thanks to web frameworks like Ruby on Rails and Symfony having it baked into the package.

This post just scratched the surface of the terms programmers (and computer people) love to throw around.  If you know of a term that you want a little help with, add it down in the comments and I’ll try to reshape it into something that hopefully makes more sense.  I’ve been known to use puppets with clients before, so anything’s possible

photo attributed to Foxtongue

Succeed at managing your customers expectation and you can never fail.  Fail to manage your customers expectations and you can never succeed. ~ me

This is one of my all time favorite universal lessons I have gleaned from business.  There isn’t really any part of my life that involves other people which doesn’t benefit from the practiced art of managing the expectations of those I’m interacting with.  When another human knows exactly what they can expect from you, on your terms, and when you consistently meet or beat that expectation on their terms, you have set the stage for a powerful ally in business; trust.

The reason this is so important is because people on a whole are very self-referential, which means they see their own perceptions and actions within the conversations and interactions they have with other people.   Imagine two people talking business over lunch.  The speaker could say ‘it will be a short project that we can deliver with limited resources and for a reasonable amount of money’.  The listener will build context around the statements with their own assumptions, drawn from their own experiences of what is short, limited and reasonable, that will ultimately create very different picture than the speaker meant to convey.  At that moment, an expectation was set in the mind of the client that may or may not be ironed out in the contract negotiations but will greatly influence the customers satisfaction when the project is completed.

I worked with a fantastic colleague on the team that had a very bad habit of responding to challenging technical requests with an automatic ‘Not sure yet, but that should be doable’.  What he meant to deliver was ‘It SHOULD be doable, but of course I won’t know until I work on it” and what the customer heard was “That WILL be EASY and there is no reason it won’t be done on time”.  So when said colleague moved heaven and earth to deliver on what turned out to be a very difficult task, the customer was unimpressed.  They had already expected it to be done without effort and was maybe a little disappointed that the colleague didn’t work on some of the other, less important features.  This is what I would call a ‘Technical win and an Expectation fail‘

Here are some tools and tricks I use when working with other people to help set the expectation

• Pictures and mockups.  When you are working in the web industry, their really isn’t an excuse to not mockup what you are seeing in your mind for the customer.  A tool I like to use is Balsamiq, which is a Flash based web mockup framework that is quick and easy to use
• Agile Development.  The agile process focuses on rapid delivery of code, typically every two weeks, that gives the customer something to wrap their head around.  I think Ill do a full post on agile tomorrow
• Closing summaries.  When I talk with customers, I have developed a technique of always closing out a conversation by saying ‘So, what I understand you want is…’ and just re-summing everything you’ve been talking about.  Etiquette might frown on dragging on a conversation past what the listener wants to endure, but I almost always find mismatching expectations in the closing summaries.

What do you do to manage someone’s expectations?

photo attributed to polandeze

Technorati tags: software, software development, software management, agile, agile development, customer-centric, customer service

The Greeks sure were fond of super-hero team titles.  There was Jason, commander of the Argo and her crew of the best of the best, pitted against irresistible forces beyond moral man’s endurance.   What does this have to do with JSON, the JavaScript Object Notation standard used by the web 2.0’s best of the best of overcome an accent foe called Same Origin Policy?  Can’t think of a thing, I just really liked the title.

A funny thing happened on the way to the Mashup. I’m sure someone somewhere, maybe even here, told you that RSS feeds were going to revolutionize the way we distribute information.  We were all so right in so many ways because RSS, or ATOM if you prefer, has opened up the world to the unimagined possibilities available online.  Think of some way that you want to consume information.  Go ahead, I’ll wait.  Ok, you are all right you can consume information that way. Oh, heh, I mean almost all of you are right.  That guy in the back with the Helvetica shirt in Metalica font, I’m sorry but we can’t help you with your idea.  Thing is, as much as you may want to have a single page that can then pull and update XML based RSS feeds from any site in the world from within the browser without refreshing, you’re not allowed.  It is for your own protection actually.  We call it the Same Origin Policy.

Here is the idea.  When your web browser pulls down a web page’s code from a modern site, it is usually pulling down a collection of HTML, Stylesheets, Javascript.  That HTML tells the page what content goes where and what images to place by the content.  The Stylesheet (CSS) tells the browser how to make that content look and how to make it act on the page.  Then the Javascript is there to give the page life, make it interact with events, make it do impressive things that we have come to love and cherrish.  In the AJAX world, those impressive things involve grabbing information from the server and updating the page without screen refresh.  Javascript is nye omnipotent in the browser, and yet there are some quantum limitations built into the works.  Beyond the sandboxing of JS, there is one little design decision from Netscape 2.0 that has totally altered the web 2.0 landscape.  Netscape decided that a browser would only allow scripts to interact with domains that the page came from.  If a page is loaded from www.bobsdiscountlasers.com then AJAX calls are limited to bobsdiscountlasers.com.  The grand illumination of mashups, where data flows from many different locations onto one page in a relevant way, almost never happened because of this.

Web browsers weren’t designed with mashups in mind, and ‘the warts have been there from day one’, [David Boloker, cofounder of the OpenAjax Alliance and IBM's CTO of Emerging Internet Technologies] says. Browsers contain a security feature called the same-origin policy that’s meant to keep malicious code hosted on one site from grabbing data, such as stored credentials, off another site. The same-origin policy prevents websites from one domain from requesting data belonging to another domain. ~ Security services and Mashups

But, of course, Mashups do exist.  We see Google Maps on thousands of pages not under the google.com domain.  How is it done?  We’ll get to the hero of the day in a second, for now lets look at other popular workarounds

• Mashup at the Server Side:  Since the JS limitation is browser based, you could do all of your mashups at the server.  The server could serve as the collector of the different sources of information, combine them intellegently and cache the results.  At best this idea is inconvenient because it adds layers where they need not normally be.  At worst this does not scale when you have a single location for distributed information
• Flash/Flex:  The Flash VM doesn’t have the Cross Domain limitation that plagues JavaScript.  A file on the server gives a list of permitted sites that the Flex app can pull data from.  I have talked with Adobe Evangalists about this option and they seemed to hint that this design decision was intented to hit javascript where it was weakest.
• AJAX Proxy.  Similar to the first method, a proxy allows the client to pull the information through it.  It isn’t stored on the proxy, though it can be cached, and no combination is done.  Again, this is a scaling issue

Stop passing code, start passing data. What all of these work arounds do is bypass the security concern with Same Origin Policy (SOP).  SOP was originally intended to combat early attempts at Cross Site Scripting (XSS).  Modern XSS has a nasty list of exploits that I don’t have time for here, but one way to think about it is this:  If you let Javascript pull code from untrustworthy places you are inviting problems.  One possible approach to this issue was to stop the push and pull of code but to allow the pushing and pulling raw data.  That is what JSON is, a way to encode data to be pushed and pulled using AJAX calls.  Though the X in AJAX stands for XML, AJAX really is more often using JSON because SOP will allow it to be used cross-domain.  So with JSON you can pull in Google Maps and that list of Micro Brewerys right in the browser, Mash them up using Javascript, and asyncroniously keep the data refreshed, the app reactive, and your buzz in good spirits (You are walking to these pubs, right?)

My prediction; RSS feeds are going to move away from XML and on to JSON in the future.  Or at minimum, support both.  John Resig, the creator of jQuery, even has a converter to get us all started.

Photo attributed to jasonr611

Technorati tags: software, json, javascript, javascript object notation, rss, atom, xml, mashup, web development, code

If you are in software development, take a good hard look at the code you are writing right now.  If the string of Roman characters resemble Java or .Net or C/C++ then I have some wonderfully awful predictions about the next ten years of your life; That language is your scarlet letter and will follow/define you for the next two jobs you end up accepting.  That sounds bad but you are the blessed among the damned – You can and will find that next job.  For Bleeding Edgers, the road is not so well paved.

In my last job I was a Bleeding Edger.  You know one if you work with one, always looking at the latest release of the newest language to see if it has a better solution to your particular problem.   In my case as a Software Manager, being a Bleeding Edger meant an obsession with ROI in our software solutions.  Links to anything that could trim development time and/or expense filled my Delicious feed.  I pushed my team to move beyond Java’s heavy web frameworks and to adopt Rails as a rapid application prototyping framework.  We cranked out good, solid software solutions 4 times faster than our java days and I was happy.  When a project came along that could use Flash, we wrote it in Flex instead because knowing how this company worked, they’d want a desktop and an offline version in the future.  A year later we were cross compiling the Flex code into an AIR application and saving a tremendous amount of time, and we were happy.

But being a Bleeding Edger means there will be dark days to contrast the brilliantly sunny ones.   Our ROI figures were not enough to protect all of us throughout this economic upheaval and some would have to make the sacrifice for the rest.  I would like to say that, as the manager, I fell on my sword for them but that’s not really the case.  The decision never reached my level.  I was the highest compensated on the team and so I was killed by simple, cold math.  The blood spilled that day is still dripping.  It still hurts.

The software job market is a rigged system.  Heavyweights in the market put enough momentum behind enough Java and .Net and C/C++ projects that they can be considered perpetual motion machines.  A class hierarchy between Java and .Net, perpetuated by recruiters with a simple word match on a job board, stacks the deck against the Bleeding Edgers in the mainstream.  You are a Hatfield or you are a McCoy or you are an innocent bystander likely to get shot in the crossfire.  The mainstream is not a system able to help the Bleeding Edger.  Sure, there will be the occasional posting that isn’t in your location and is looking for some bizarrely specific, must have requirement that categorically eliminates all humans including the guy who originally wrote the book on the library they are using.  In the end, Bleeding Edgers need to work outside of the system.

For the young, there are no unemployed Bleeding Edgers only uncompensated open source code contributors.  If you have the ability to live on nearly nothing, working outside the system can be a very rewarding and ultimately fulfilling life choice.  For the responsibility burdened older generations, there are really only two options as a Bleeding Edger.  The first, and likely most chosen, is to re-assimilate into the collective; scrub your resume of all references to Ruby and Jython, and  Grail, prop up your sun certifications if you have them, and become a team player.  The rest of us Bleeding Edgers, the ones the economy hasn’t driven to ditch digging, will become the countries next batch of serial startup founders.  We will be easy to spot, just look for the scars.

Technorati Tags: code, ruby on rails, ROR, software, software management, software development, web development

CodeMash Jam Session on Vimeo « SazbeanBefore there was Rock Band, people spent time playing actual instruments.  This pickup band were amazing musicians independently, but riffing off each other they were just outstanding.

CodeMash Jam Session from Sazbean on Vimeo.

The guy who wrote Rails was clearly brilliant.  He just didn’t have alot of real world experience ~ Joe O’Brien, talking about the limitations of testing within Rails

So Joe O’Brien, from EdgeCase, is one of those really exciting presenters to watch because it is a certainty that both you and him are both going to learn something within 30 minutes.  Throwing the presentation safety net away and going off the map, Joe tackled the tangled subject of testing in rails by the only way that makes sense, actually doing it. Here is a bit of what you missed:

1. Make a rails project, open a test file and make some assertions.
2. Fix your errors and make more assertions.
3. goto step 2

This was a great way to see they subject matter come alive, warts and all.  If Joe had the courage to start hacking away at a program’s test code in front of 30 people, maybe it wont be so scary when you try it in the comfort and protection of your cube next week.   So here are some of the things we all learned from this demonstration:

• Mock up things to make tests more isolated can be proven by breaking the fixtures layer and demonstrating how brittle it really is.
• Separating controller tests from models and views is a good thing!
• Integration test that doesn’t start with the brower isn’t really integrated
• Changing from QUERTY to Devorak keyboard mappings a week before a live demo makes for awesome typos

Look to March for the marriage of Merb and Rails for an alternative to the ActiveRecord ORM.  Also, learn to love mocking in test and find a moching library that you like, be it RSpec or Mocha or FlexMock (which they use in EdgeRails because it WAS actually invented there).  Also, look to the Pragmatic Programmers for a screencast on testing from Joe and Jim sometime soon.

Remember fear is the mind killer, so just get over it and learn Functional Programming ~ Kevin Smith talking about Erlang

The two afternoon sessions, Erlang the Basics and Functional Concepts for OOP Developers, were one – two punches to the gut, in a good way.  If you tried to read a Functional Programming tutorial, maybe waded into the Lamda Calculus pool and found it didn’t have a bottom, you’re not alone.  I remember just innocently hitting Wikipedia for a definition of Functional Programming only to be turned back by the first sentence comprised entirely of mathematical symbols and polysyllabic words without definitions that didn’t also have mathematical symbols and polysyllabic words.

Thankfully, for the cost of gas, a room and a cheap ticket to this conference, I got the opportunity to let real functional programming masters explain it to me in English.

Kevin Smith, of EngineYard, does Erlang for a living.  That kind of makes him a grand pooba of Functional Languages in my book since OOP just about buries the list of code written today.  Still, as Kevin noted in his talk, there are high profile sites using Erlang today – Facebook is using it for chat, Amazon uses it as does CouchDB.  Unlike Haskell with its academic background, Erlang is the programmers functional programming languages ‘to make hard things eas(ier)’.  So what are those really hard things?  Well concurrency is the big one.

Not long ago, programmers had a one-machine-one-CPU view of the world that served them well in the Object Oriented Programming universe.  Software was rarely written to work as a unit over more than one CPU at a time because it was 1) very very hard and 2) impractical and unneeded for most cases.  Today, however, programmers are realizing that the multi-core growth path of hardware manufacturers has hijacked the stage, forcing us all to become concurrency experts. While OOP languages are saddled with the baggage of supporting shared memory and mutable variables, reducing them to a one legged man in a ass kicking contest, their distant cousin Functional Programming Languages aren’t feeling the same strain.  FP’s have immutable ‘variables’ (really they are unchanging pointers, so more like constants) and a very low cost for spinning up processes.  This frees them to run in a highly distributed way on many cores and many machines collaboratively. Erlang, written by the team at Computer Science Labs at Ericisson, had a real world need for a highly concurrent language to write their phone system on.  Its design works wonderfully to harness that 8 core desktop you have sitting under your desk.

Bryan Weber was kind enough to expond on this foundation talk by exploring Functional Concepts for OOP Developers.  My take home from this talk was the message model used by most Erlang programmers to achieve concurrency.  Like Scala, Erlang uses a mailbox with a send and receive paring to smoothly weave a web of interconnected processes that can be located anywhere on the network.  Simply spawn a process, which gives you a pid in response.  Now send a message to the pid.  The spawned process does a recieve to check the mailbox for the message.  Want to send a response, no problem.  Have the spawned process send to the parent and have the parent check the mailbock.  Done, you just did concurrent work.  This little scene is played out using Actors, which naturally, is an apt analogy.

I don’t know yet if FP will make it into my world any time soon.  Our concurrency neeeds are small so far.  I would say that Functional Programming isn’t the solution to all problems, but it just may be the answer to that tricky problem defying all other solutions.

Whould you want your surgeon to have a dull knife? ~ Nathaniel Schutta defending dynamic languages like Ruby as ’sharper tools’

Travel issues prevented me from seeing the very early sessions of CodeMash, which was a shame because I was very interested in Eric Meyer’s talk on how JavaScript Will Save Us All!  (I added the exclamation marks because I think that’s what he really intended).  Still, I made it early enough to sit through a couple very good presentations before lunch, both of which followed a bit of a theme.  One was a love fest for Dynamic Languages as a persecuted, second class citizen given expertly by Nathaniel Schutta.  His message is simple, programmers need to be Polyglots and if you can’t handle learning different languages than you should get out of the business.  Harsh, but dead on accurate.  One of the languages you should have in your tool belt, Nathaniel tells us, is a Dynamic Language and that you can do a whole lot worse than Ruby.  I am already sold on this idea, or was years ago when I was nearly alone in lecture rooms during similar presentations.  Since then the crowd has gotten bigger but the message is still the same.  Most of this revolves around dismantling the arguments for the need of static typing to prevent errors from bad programmers.  Truth is, bad programmers don’t get better when they have a wet nurse hand out brainless advice through compiler warnings or errors.  Take off the training wheels already and let’s get some code written already.

You go though more hoops to do it, but you can do it ~ Venkat Subramanian Mads Torgersen talking about Dynamic languages on C#

Venkat Mads works for Microsoft on the C# language.  Now I am not genetically predispositioned towards this kind of talk, but since it was while I ate my ham on marbled rye, I felt no great persuasion to not hearing the good gentleman out.  Glad I did, though, because there were some interesting things going on in the CLR camp.  CLR itself was a happening idea, a VM that was designed from the beginning to be a shared platform (Common Language Runtime) so the pieces where already there to do something interesting.  However, it seems that early decisions were made to optimise speed for the C# type base on the CLR, leaving non-microsoft languages somewhat at a disadvantage and me somewhat bewildered by the earlier statements.  Dynamic languages, for example, run though a DLR library to get to the CLR.  This Dynamic Language Runtime handles the bindings to Ruby and Python, so IronRuby and IronPython handle the mappings between DLR and CLR maybe?  I was somewhat confused.  If you type something in your code as ‘Dynamic’ it is a Dynamic type in the compiler but then reverts to its true type in runtime to allow for the dynamic langages to duck type the thing.  For a complacated problem, the fact that this solution made perfect sense to someone as slow as me is a good sign that they might be on to something.