Amazon's Elastic Beanstalk is another git-driven deployment service, this time directly to EC2 and RDS instances on Amazon Web Services.  It's similar to what Red Hat is doing with OpenShift conceptually.

If you are a PHP developer like myself your first question is probably, will it install my composer dependencies for me?  The answer is YES.

Here's the kicker, and quite frankly this does not make any sense to me...  If you have stubbed your vendor folder in place, so you've either touched ./vendor/empty or ./vendor/.gitkeep, you are going to have to removed it.  Elastic Beanstalk will use composer based upon the presence of a composer.json or composer.lock file, but if it sees the vendor folder it bails out and doesn't execute the install command. Again, I really don't know why this is and I could not find any documentation about it.  Yet this exactly what I needed to do to get my dependencies installed.



I've become a pretty big fan of Red Hat's OpenShift platform.  I love the idea of doing deployments based off of DVCS operations. Almost two years ago when I was working for Wizzard Software we came up with a deployment process not to far off from this concept.  We were a Mercurial based team so the DVCS system was different, but we basically issuing pull's from repositories on the effected systems and out rolled new software that way.  OpenShift is a whole lot better then that though, because it's push triggered and deploys to the cloud and Red Hat has a bunch of awesome hooks tied in to make it even more powerful.  Did I mention it's FREE?  Yes, free hosting driven by git in the cloud - it doesn't get much better then this!

But what happens if you want to add a custom domain name to OpenShift?  In order to do this you have to do two things, first add the appropriate aliases to your OpenShift application, see here for more information. Second is to edit your DNS records and add CNAME records to point to the OpenShift subdomain for your application.  As with many things in the cloud, IP addresses are ever-changing so you cannot count on them when setting up your domain.  If you're lucky enough to have NameCheap as your registrar this isn't a problem, because they let you add a CNAME record as your apex (not sure how they do this, but just go with it... it works!). If you are on GoDaddy or a similar DNS service (like Route 53) you aren't so lucky.

Fortunately, Satoru systems has a naked domain redirect service over at wwwizer that fills this need.  They basically give you an IP address to use for your A record and their system automatically redirects it to "www.domain.com" where "domain.com" is the apex entry. It's dead simple to use. Best of all, this too is FREE.

As with all cloud systems, you never know how long you can get these services before they are bought out, shutdown or just run out of money, so don't use them with mission critical systems. But if you're a hobbyist or have a pet-project this is a great way to get it out on the web without incurring a lot of costs.

Check out wwwizer's naked domain redirect service.



Mailbox has garnered a lot of attention since it rolled out.  My concern from day 1, as has been with many a similar service, is how is it being paid for?  These startup services rollout free with no plan in place to make money.  Some of these startups are gunning to be bought out or "funded" by venture capitalists, and others are hoping for bright lights and a revelation on high to show them the secret to success (here's looking at you Twitter).  The truth is they lack a plan to become financially solvent and while cloud computing is cheaper then the alternative, it's still expensive.  It's no wonder then that these startups belly-up or disappear into the annals of the world wide web. I've been particularly upset about two as of late, Posterous a year ago and more recently Sparrow. In both of these cases the buyouts were about grabbing talent and had nothing to do with building the product.  In the end the consumers got screwed by dreams too big to pay be paid for.

So I can't help but wonder what will happen with Mailbox.  An announcement was just recently made that cloud-sync kingpin Dropbox has bought them. I should disclose that I do have a Mailbox account and that I have not completely bought into their way of doing Email just yet.  I'm not trying to knock it, it's just a dramatic change from the way I've managed my inbox and I am still adjusting.  I'm giving it a shot though.  I should also disclose that I am huge fan of Dropbox.  Nonetheless I can't help but wonder what Dropbox's purpose is in buying Mailbox.  To the best of my knowledge there is no income stream for Mailbox, only what I am speculating is an ever-growing EC2 bill.  The product models are completely different too.  So is it a talent grab?  It doesn't seem so, at least Dropbox's post does not give that indication.  Nonetheless I am skeptical...

I wouldn't count on Mailbox being eternally available. I hope I'm wrong, but I feel like we've learned all too recently not to depend on free cloud services for the kitchen sink.  Our data needs to be portable and we as consumers need to be startup-proof.  That means go ahead and use a service like Posterous, but make sure you can walk away from it when they shut it down.  And if they don't offer data portability, don't sign up.  With services like Mailbox that augment the way you do things, just make sure you can still function when they are gone.  In short:  D__on't put all your eggs in one basket, be startup-proof.



Google announced its latest round of spring cleaning.  The most troubling part of the news announcement is the loss of Google Reader.  I've been using Reader since 2005 when it first started. I had tried a variety of one-off RSS readers prior to it and Google Reader was perfect for me because it was "in the cloud" before that was even in-vogue. Fast forward eight years and I'm still maintaining the same list of feeds, though now I consume it through native app clients on the Mac, iPhone and iPad. I haven't used the actual web site for it in a long time.

A lot of people are worried about what will happen when Reader shuts it's doors. There is even a big online petition going to ask Google to keep the service. Some have predicted that this will be the end of RSS as we know. Quite frankly I'm not too worried about losing Google Reader.  My list of feeds has thinned out over time as I've begun using services like Twitter more.  Where I once subscribed to feeds for news and sports I am now following various outlets on twitter. Most of my friends who still blog tweet when they post to, and quite often I am clicking over to an article because I saw it on a tweet first. That being said RSS still has it's place in my mind. Not everyone does the twitter thing and they shouldn't have to. The best part of RSS is still that it's an open and parsable standard.  It's friend OPML is great and also pretty portable.  These are two things Twitter won't give you.

So what am I going to do?  Mostly wait.  I've been using Reeder for consuming Google Reader data for a long time now and the developer of that fantastic app says it's not going away just because Google Reader is.  This gives me hope that Marco Arment might be right and that this is an opportunity for guys to build new replacement service.


jGrowl 1.2.11


I released a small updated to jGrowl today that fixes an issue when triggering the shutdown method (thank you Joana for reporting it!), basically the multi-notification closer would be left behind (though not visible) and remain in limbo. The fix cleans out all nodes in the container emptying it completely out upon shutdown.  I've also cleaned up text artifacts, space/tab discrepancies and extra space at the end of lines as well.

If you hadn't noticed yet, jGrowl moved from BitBucket over to GitHub when jQuery rolled out their new plugin registry.  They've got a pretty neat system for updating a plugin's page off of a manifest file in the git repository.  The move to GitHub has also been nice because it's resulted in several outside contributors issuing pull requests (thank you Dimitry and Artem!). If you find a bug, please file it over at GitHub and always feel free to issue a pull request if you have an improvement, bug fix or feature request!

Check out jGrowl on jQuery Plugin site.

Check out jGrowl on GitHub.