Web Software Architecture and Engineering – Life on the Bleeding Edge

Archive for the ‘Tools of the Trade’ Category

My Notes on Finding a SaaS Email Company

Our ColdFusion-based SaaS application sends out roughly 8,000 – 10,000 emails per day, and even more on the weekends.

I wrote the code in 2007, and since then worked hard on improving memory usage. We optimized queries, re-worked string concatenation to use JAVA’s StringBuffer and StringBuilder classes, and so much more. But to tell you the truth, we always wanted to work with some other software to do the hard work for us. We have templates, to which we pass in variables and shoot that off to a slice of our clients.

Originally, we worked with WhatCounts back in 2008 to get this done. Unfortunately, their API wasn’t as mature as we thought, and batch processing was a pain. I spoke with the CEO on the phone back them, and we decided after working together for months to part ways.

I have to say our current solution is a work of art, but I’d like more. It would be nice to get email analytics – information on opens, clicks, etc. We could do that internally, but its not our core competency. So for a long time, I kept my eyes open for any new companies I could work with.

Originally, I thought that maybe I could make due with the ConstantContact and VerticalResponse’s of the world. But they are not built for this type of work, and are geared more for marketing campaigns.

Fortunately, there are some new players in the field. I narrowed the field down to half a dozen players, and did proofs of concept with the top 3: SendGrid, PostmarkApp, and PostageApp. They all feature APIs and could meet some of my needs. What wasn’t clear, was how mature the feature set was. But the great thing about them was they allowed for no-cost trials, so I went ahead and tried them.

My primary use case was the following. Remember when you first learned Microsoft Word, and that one of the neat features was doing merging… you could create a template or form, and passing an address book for example, and it would create a ton of letters? Well, that is the sort of use case I had with email. I wanted the 3rd-party system to house my templates, and for me to pass in via API – users who would receive the emails and variables with the content they would receive. Simple I thought – I mean I could write something like that in ColdFusion if I had to. The great plusses were the deliverability improvements, anti-SPAM measures, and of course the analytics and logging.

I’ll be featuring a few posts on my experience working with the 3. There was a clear winner, and some astonishing things that became quite apparent with a few – especially those written in Rails.

Does something like this interest you?


Git is Scary – But it doesn’t need to be!

I watched two Git preso over the last week by CF folks. They both tried really hard to make Git sound better than SVN, and easier to use.
But looking at their preso, if I was a newbie to source code management, I’d be scared. All that Git bash stuff is a nightmare!
Git isn’t perfect, nor is it well suited for web development. But it also doesn’t need to be scary.
As a long time SVN (and previously CVS) user, I moved to Git for all development earlier this year, but this was after watching preso and researching Git for years! And I found one common thread, it does better merging, but it can also be scary. Why? There aren’t any good tools!
Earlier this year, the great folks at syntevo GmbH launched SmartGit, and it made Git sooooo much easier to use and manage. This is what made the switch from SVN (for which they have a killer tool called SmartSVN) so much easier, and really did it for me.
Maybe someday someone will create a version control tools best suited for web development, without the confusing terminology that Git and SVN has, but for now, we’ve found a great combo that works.
Each developer has his own branch in which he works, then we have a dev branch, a staging branch, a UAT branch, and a prod/master branch. Developers commit code in their branch on a daily basis. When they feel ready they merge in (which is very easy with SmartGit) their changes to the Dev branch. As other developers have also been committing code to the dev branch, they also merge out their changes from dev back into their branch, so that they have the latest changes. The dev branch is where intergrations testing can occur, all developers code meets up, and we do our own testing on the dev box. Once we’re good, we merge from dev to stage, where QA does their testing on the staging server. And then when tickets are passed, then we merge from stage to UAT, which is on the same environment externally as prod. If we need to show off any code to customers early, we can do that here, and we also make sure the code runs OK in prod. And finally, when code has passed UAT testing, then we merge to MASTER, and push the update to the servers on the next launch. Works well for us.
Developers may also create their own experimental branches on the fly. I have one right now for testing our move from Verity to Solr, for example.
The only problem with this model is that you have to be careful when pushing up, as you can push up code that hasn’t been fully passed. So you can cherry pick commits, or just be careful. This is where the “art” of source control comes in, there is no exact science, its all what works best for your team.
My greatest wish for source control would be if you could tag a commit as being at a specific level only. So if you commit code, and say this is, for example, “dev” only, any merge from dev to stage would ignore that code, until the ticket associated with that code passes on dev, and then it’ll move up. This would make merges soooo much easier, and you could be sure your code will never make it to prod unless its passed at that level by QA. Anyways, wishful thinking.
Oh, and Git integration into Eclipse is half-baked, so much so its useless for me. I always have SmartGit and CFBuilder open side by side. Good thing is that SmartGit runs on most platforms!