I had some information ready to be posted here when I submitted my entry into Ray's Best of CF9 contest, but he covers it pretty well in his review post; and he was kind enough to host the video on his S3 account. I've also posted the video on my Vimeo account, so here it is again for reference:
You can download the source code here. Unfortunately, I haven't found any more time to continue working on this; and I have to admit that as cool as the CFaaS feature is, I'm not terribly motivated to go further with this mail client because I know it will eventually get canned. Why write a mail client when you use Outlook every day?
So it was a fun way to play with Flex 4, the latest Swiz build at the time, AIR, and CFaaS; but I don't think I'll bother continuing to mess with it.
Today I found out that I'm among those selected to join the Adobe Community Professionals program (formerly Community Experts, aka A.C.E. — but there was a conflict with Adobe Certified Experts, thus the change).
I took over as manager of Philly CFUG last October, and through that I've been working on my stage-freight and hopefully helping the Philly CF community start to re-awaken. I'm working on my own presentations, submitting topics for conferences and CFUG meetings, and still working as a copy editor for FAQU, which I personally hope finds a way to get back into print as the economy stabilizes.
2010 is going to be a great year. I'm just glad I get to go along for the ride.
I recently found myself discussing Aspect Oriented Programming (AOP) with my coworker Nathan Mische, and had one of those moments where a lightbulb turns on in your head. We came to the conclusion that when building web services and APIs in general, it may be best to initially take the approach that I'm calling "just make it work." You can worry about security and error conditions later.
Now, don't take that the wrong way. I'm not advocating no security and not checking for error conditions. There are two kinds of later: The "later" in which you plan to write the documentation, and the "later" that actually exists. When I say worry about security later, I'm referring to the one that actually exists.
Here's the thing… error conditions—including security errors—are usually cross-cutting concerns. That was my lightbulb thought. Of course, cross-cutting concerns are the bread and butter of AOP, and if you extrapolate on the thought a little bit, what it really says is that the method should only handle the best-case scenario; and that your AOP advisors should handle any errors or less-than-best-case scenarios. In fact, since I'm creating a new development methodology on the fly here, I'm going to go ahead and declare that rule #1 of just make it work: API methods should only handle the best-case scenario. Of course, rules are made to be broken, there's an exception to every rule, blah blah blah. So maybe consider it a rule of thumb.
Let's look at a real world example that (for once!) doesn't use logging as the cross-cutting functionality built with AOP.
Assume you're writing a game that simulates stock trading. Your players each represent a company with stock being traded in one of a few available markets. Each player has some cash and stocks to start with, and their goal is to make money buying and selling stocks in available markets. Of course, you can't allow insider trading, so you have to prevent players from buying and selling their own company's stock.
Start with the obvious things, methods for buying and selling stocks:
remote boolean function sellStock(playerObj, marketId, stockId, offerPrice, shares){...}
remote boolean function buyStock(playerObj, marketId, stockId, shares, maxBidPrice){...}
The contents of these functions aren't important. Write them assuming that the player has enough money to complete the purchase, enough shares to sell the number attempted, and so on… the best-case scenario. Not worrying about player's cash reserves, shares owned, and right to trade the stock frees up your mind to just make it work, which—for me, at least—can lead to increased productivity. At this point you should be tearing through your spec implementing everything you need to do, not worrying about the little details that can cause problems, and pretty soon you find yourself with a complete best-case-handling API.
After your best-case API is complete (this is the "later" that exists), think about things that can go wrong. Not enough cash to perform the transaction? Throw an error. Player isn't allowed to trade on the requested market? Throw an error. And so on.
And since these sorts of conditions are things you want to check for in a majority of your API, using AOP to write them once and apply them to the applicable API methods means you'll have more maintainable code, and your errors will be consistent across all methods (no more "401 Unauthorized" from one method and "401 Not Authorized" from another…), making it easier for your API consumers (and you should be one of them) to handle thrown errors.
And if you ever do get around to writing that documentation, your advisors will provide a centralized list of what is and isn't allowed to happen.
As promised, today I'm releasing a new version of Scribe that makes use of my new PowerMail plugin, if available. As I said yesterday, this new version will send email from and to you — the author — but BCC to your subscribers. Doing so will cut the number of messages sent by up to a factor of 100. In addition if you use Google Mail for your domain, as I do, then using PowerMail to route outbound email through gmail will make your messages look less spammy to the receiving mail server than if you used some other mail relaying service.
I've also fixed a bug where the link included in the double opt-in activation email led to a page that didn't render (though the activation was still successful).