lemonbytes

husband, dad, steelers fan and software engineer

If you don't read anything else, check out:


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:  Don'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

by Stan Lemon


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.


The New Sanctus.org

by Stan Lemon


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.

And as always... special thanks to Pastor Borghardt for donating the domain name sanctus.org!


Fairwell BlogSCL

by Stan Lemon


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.