Friday, September 28, 2007

Domain Languages: Apex

Tip #17 in The Pragmatic Programmer is:

"Program Close to the Problem Domain."

Lately I've been spending a bunch of time building Apex web services for my customer and I can tell you that it's a super powerful language. My pseudo-code translates almost line-for-line in to Apex code. Here's an example:

//get the oppty line items for this oppty
List opptyLineItems = [Select Id, PricebookEntry.Product2Id from OpportunityLineItem Where OpportunityId = :opptyId];


In C# this one line of code would translate to four or five lines of code. Visualforce is the equivalent development productivity lever for user interfaces. Pretty cool stuff.

Monday, September 17, 2007

Visualforce

Salesforce.com just announced the next step in their evolution towards becoming a complete on demand platform: Visualforce. I can't wait to be able to start building applications with Visualforce instead of lower-level web technologies like ASP.Net and JavaScript, powerful as they may be in their own right.

Saturday, September 01, 2007

Designing Applications

Salesforce.com was originally built as a CRM tool. It's been amazing to see it evolve. I've even begun to see it used to model non-business processes. A co-worker recently used it to manage her wedding's guest list. Everything was stored in our product -Who will be able to attend? Would they prefer Beef, Chicken or Fish? What gift did they give? Has a Thank You card been written yet? The application didn't take very long to build and because of the wonders of SaaS multi-tenancy, my friend got to leverage our reporting module without any extra work!

One thing salesforce.com can't do yet is build custom user interfaces. The building blocks have been exposed, but they're the equivalent of 2x4s, nails, plywood and copper pipe. It still requires traditional software development skills and processes to build a sophisticated custom UI. I've heard that there's a solution coming and I'm excited to hear more about it.

Until then, I'll keep working with JavaScript and ASP.Net 2.0. I just finished up a paper usability study with my current customer for a web-based replacement for their exsiting Excel application. Jakob Nielsen's not surprised, butI'm always amazed by how effective paper prototyping is. I was pretty proud of my hand-sketched design, but after spending an hour with the future user of the system, I discovered a number of workflow flaws. According to Steve McConnell, a requirement that goes undetected during the requirements phase "will cost 10 to 100 times to fix during testing."

It's going to be tough for our ASP.Net 2.0 application to beat Excel for flexibility, but on the upside, our web app is going to perform validation, will use dynamic data sources to populate picklists and will store all user-entered data in a cental location, so our customer will never have to worry about data synchronization issues.