Today I released a new version of Sanctus.org, my Lutheran lectionary calendar project. I started this project when I was in college at Concordia University, River Forest. I was studying theology and fascinated with liturgics and the church year. The project started with the purpose of assisting our dorm in planning our daily prayer services and quickly evolved into something bigger as other people gained interest in it as well. Today's release is the third time I have rewritten the site. Today's code is deployed on Red Hat's OpenShift platform and I am using Zend Server's page cache and data cache to keep things fast. The new layout utilizes Twitter's Bootstrap library for a nice responsive design. Under the hood the actual calculation algorithm has been open sourced and can be found on GitHub, the rest of the plumbing is Slim, Doctrine and Twig respectively. I've also restructured a good portion of the persistence layer to be more normalized and it runs on MySQL instead of SQLite too. All in all I think it's a better piece of software then it was. I hope you enjoy the new look, faster response times and all around better experience of using Sanctus.org. Feel free to leave me some feedback on the redesign.
In the summer of 2004 I was a single college student with far too much free time on my hands. I had started writing web software in 2002 with my friend Erich Musick, now a super-star developer ninja at Microsoft. At the time we were focussed on making plain old websites and solving the difficult challenges of managing content with consistent templates and automatic linking. Life was easy back then. Erich had this nifty news manager system written in Perl and he used it like a blog. Meanwhile I was conquering server side includes while rigging together Apache on my Windows XP laptop. Again, life was easy. Always striving to be unique I took a different path and started exploring PHP. I had a singular goal of replicating Erich's new manager in my own special way. What resulted was a rickety and clunky news management system that ran a pseudo-blog on my website into the summer of 2003.
In the summer of 2003 my coding skills were getting better and I rewrote my news manager and it materialized as the first version of what I affectionately called BlogSCL. Those letters, S-C-L, belong to me - they're my initials. Blogging was new back then, there was no wordpress.com and blogger wasn't owned by Google, in fact it was some hackie CGI scripts you would upload to your own server and hope worked. I was determined to turn BlogSCL into something cool and so I rigged together a basic way for people to sign up. After all, I had a shared hosting account on some ghetto-fabulous server costing me almost nothing and it has unlimited space on it.
In early 2004 I became involved with an organization called Higher Things. It was a Lutheran Youth Organization and they had a website but it stunk. They wanted something better and I was cheap, as in free. One of the things they wanted was a better way to manage news, so I introduced them to my super awesome BlogSCL platform. It worked and they were happy, but then some of the staff wanted their own blogs. I began building out BlogSCL like crazy, adding comments, pingbacks, trackbacks, captcha, categories, pages and just about anything I could think of. If I saw it on one of the up and coming blogging platforms I pulled it into mine.
But the first version of BlogSCL was difficult to maintain and I had learned a lot, including how to write object oriented software. I decided to rewrite it from the ground up and open up public signups. A half a bottle of tequila and a long night yielded the first working version of BlogSCL2, which served as the basis for the platform as I built it out over the next two years. Seven years later I am finally pulling the plug on the last of the BlogSCL blogs. I have just wrapped up migrating the Higher Things blogs to wordpress.com. You might be wondering, why? Well, it wasn't for the outstanding quality of wordpress code - that's for sure. There were a couple of reasons though, firstly I don't have the time to be spending developing a blogging platform when there are others out there being actively developed by large communities (yes, I'm looking at you wordpress!). Secondly, wordpress has a pretty simple format for exporting and importing and it was easy to write an exporter from BlogSCL to it. Thirdly, while under the hood wordpress is nothing to gawk over it does have a robust UI, expansive plugin system, far reaching hosting service and an iOS app to boot.
As a developer I constantly want to write my own stuff. Not necessarily because I think I can do better (though I can), but because I enjoy the challenge. Getting BlogSCL to the point it as was a challenge and it forced me to learn how to become a better developer. I'm very grateful for the learning exercise and also happy that it was able to get used by Higher Things as long as it did.
Amazon Web Services is like the godfather of cloud computing. In PCI or HIPPA/HI-TECH compliant environments though it doesn't quite cut it. There are a bunch of fancy letters indicating various certifications that seal the compliance deal for those looking to provide services in the cloud under those regulations. Fortunately Amazon developed the GovCloud as a compliant region to meet those needs. GovCloud requires special approval from Amazon to get started with it. I've been "tinkering" around with GovCloud for a little while now and have come across some gotchas that I wanted to document and share, if for no other reason then to save the next poor soul from all that googling around...
1. Web Interface
If it's not clear from the website, don't be surprised: GovCloud does not have a web interface to it. All of the fancy tools that us EC2-lovers have grown accustomed to in the East and West regions are out of luck. In GovCloud you have to use either the command line tools (all umpteen trillion of them) or you have to use a tool called ElasticWolf. ElasticWolfe is a decent tool, when it works... and that right there is the problem with it. I've filed three tickets as of the writing of this post, and while turn around has been fast, I don't feel like I can trust it to do what I need, whenever I need it. So get comfortable with the command line, as that's your primary place of operation in the GovCloud. Don't worry though... it's only intimidating at first, you'll get used to it!
2. White Listed Load Balancing
This was not disclosed to me upfront, but apparently the Elastic Load Balancing service has some sort of separate white list you need to be on when joining GovCloud. Quite honestly this doesn't make sense, but nonetheless I found myself with everything working except the Elastic Load Balancer and when I finally appealed to my GovCloud sales rep, she directed me to a nice (and hardly responsive) technician who told me I needed to be white listed. Rumor is he took care of white listing my account, and while I now have an Elastic Load Balancer up and working in the GovCloud I am still waiting to hear from my Support Technician at Amazon. So if you want to use an ELB in GovCloud save yourself the time and trouble and pre-empt the white listing by telling your sales rep up front.
3. Elastic Beanstalk
This is a great service that basically powers the automation of a full AWS deployment using git. It's akin to services like OpenShift from Redhat but with an order of magnitude more power by virtue of the plumbing underneath. I was stoked when Beanstalk came out because it gave me a standard PHP AMI with RDS, an ELB and an AS/CW configuration right out of the box. I had dreams of spinning my service up with git push and then walking away to enjoy a cold beverage of some sort. Not on GovCloud though. Despite having ALL of the services that make up the underpinning of Beanstalk, the tools for Beanstalk themselves are not actually configured for the GovCloud region. This isn't spelled out anywhere clearly and the Beanstalk website is sort of misleading when it describes the service as a management wrapper around existing services. It seems that there is some dedicated plumbing in there too.
4. Endpoint URLs
Most of the command line tools that Amazon ships are not configured to run with GovCloud out of the box. You have to change the endpoint URLs for them in order to make magic happen. Unfortunately try as I might I couldn't find all of the necessary environment variables that needed changing documented anywhere. The endpoint URL's can be found here. But what variables should you set? I am not sure I have discovered all of them just yet, but here are the ones I have found and have been using:
What threw me for a loop was "EC2_URL" and then "AWS_ELB_URL" and then "RDS_URL" and then "AWS_CLOUDWATCH_URL"... what the rhyme and reason was for when "AWS_" was prefixed is beyond me, but knowing this inconsistency would have saved me some time and I hope it saves you some too!
Hopefully there won't be any more surprises in GovCloud, but if they are expect a followup!
Unfortunately as I predicted when Posterous was bought, the product is dying. It's going to get shutdown soon and that leaves those of us who loved it searching for something instead. It's a bummer, but I don't blame Twitter. Rather, I blame the CEO of Posterous and its investors for creating a fantastic product with no way to make money on it. More and more this seems to be the story of Silicon Startups and it really kind of stinks. I find myself at this juncture wanting my next blog solution to be portable and Wordpress seems to fit that ticket. I'm tired of hosting a blog, that's why I went to Posterous in the first place. The fact that Wordpress has a good mobile presence is also a win in my book. So I am going to give this a shot and see what happens.
