I’ll be presenting two sessions at Dreamforce this year:
Apex Unit Testing in the Real World
(Tuesday 1-1:30 Moscone West 2006)
Do you follow all of the best practices for unit testing described in the Apex language documentation? Probably not. Should you? The answer may surprise you. Unit tests in the real world serve many different purposes, and each purpose calls for different types of tests, and different testing design patterns. In this session you’ll learn about different types of unit tests, and how approaches vary depending on the type of application, and the specific testing goal. You’ll see how testing strategies change dramatically depending on whether you are writing code for a specific organization or for a managed package.
Apex Nirvana – Embracing Governor Limits
(Wednesday 4:30-5:00 Moscone West 2002/2004)
For many Apex developers, especially those coming from other languages, Apex governor limits can sometimes be challenging to understand and code against. But it doesn’t have to be that way. In this session you’ll learn to embrace limits, to factor them into every design you create, and how to trade off one against the other. You’ll find what the experts know – that governor limits help you to write better and more efficient code, that today’s limits already support large and complex operations, and that even when they don’t – there are usually ways to work around the issue to accomplish virtually any task.
There are a lot a lot of coders who write Apex. There are fewer designers and even fewer architects. It’s important to understand the difference between them.
Most beginners start out by learning to program – to write code. That’s how I started out. You have a task in mind and you need to find a way to implement a solution in software. In many cases you don’t even need to understand the solution – you can just use Google to find how someone else solved the problem and copy and paste the code. That’s ok too – it’s how we learn.
For a long time this was all you needed to survive as an Apex programmer. The truth was, Apex was mostly used as a “scripting” language – a tool to perform some limited tasks that weren’t quite possible using workflows, formulas and similar tools. And in this context, an “advanced” programmer is one who knows how to implement a wide variety of these tasks – and who understands how and why they work.
But Force.com has changed over the past few years. The language has grown in sophistication. The platform API has grown enormously. Some critical limits have been relaxed. The platform now supports more complex scenarios – not just simple scripts, but large applications. Some of these applications just evolve – organizations may start with a few triggers and web service calls, but these accumulate until the interactions between the various elements start interfering with each other and the whole thing becomes costly and difficult to maintain. But other applications are designed – and can avoid those problems.
There are two great truths about software that every programmer needs to know:
Writing code is only a small portion of the life-cycle cost of software.
The least expensive time to resolve software issues is during the design phase.
Real software and real applications – which is what you can now write in Apex on Force.com, require you consider the entire software life-cycle – This includes defining requirements, designing the solution, writing the code, testing and validating, training and support, and maintenance. That’s the real difference between a coder and an architect. Most coders focus on writing the code. Architects and designers care about the entire lifecycle. If you get your design right, the costs of software over the entire life-cycle drops, and the odds of a project succeeding increase dramatically.
I recently saw a post by an individual asking if this book contained some advanced coding techniques relating to JSON authentication and OAuth. It does not. Why? Because coding techniques and solutions to specific coding problems don’t belong in books anymore – that’s what you use Google and forums for.
This book is intended to help Apex developers to think in terms of design and architecture – to understand design patterns and the consequences of design choices. Yes, there’s plenty of code in the book, but instead of seeing one way to do five different things, you’re much more likely to see five ways to do the same thing – and how and why you might choose each one.
That’s what makes this an advanced book – because it’s not about writing code, it’s about programming. It’s not about learning to solve one specific technical problem, but how to learn to solve any problem you run into. It’s about learning to design code so you anticipate problems and thus never actually run into them at all.
The book doesn’t contain everything a Force.com developer needs to know – no book could. But I do believe that every serious Force.com developer needs to know what’s in this book.
I’m pleased to announce the immediate availability of the book through our online store. The book should be available sometime next week on Amazon.com.
While I don’t have a final publication date set, it’s looking likely that the book will be available sometime in the first week in August through our e-store. It will probably show up on Amazon.com about a week after that, and other channels over the next couple of months.
For those looking for a Kindle edition, I’m afraid it will have to wait until sometime in Q4. August and September will be very busy leading up to Dreamforce, and I simply won’t have time to do the conversion and QA before then.
Thank you to those who volunteered. The book has been published and the preview period is over.
Are you interested in being a preview reader for “Advanced Apex Programming for Salesforce.com and Force.com“? I’m looking for a limited number of preview readers. If you are interested, please send an email to with the following information:
Your full name (first and last name).
Are you willing and able to read the book (about 230 pages) and share your comments in the next two weeks?
Do you consider yourself an intermediate or advanced Apex developer (I’m looking for both)?
Have you ever worked on a managed application that has been published on the AppExchange?
Other than reading the book, all I ask is:
Let me know if you notice any technical errors in the book.
Let me know of any best-practices that I recommend that you think are incorrect.
Let me know of any best-practices or design patterns that you feel should be in this book (or in the next edition of the book).
Possibly provide a quote that I can use for the book, or, after publication, post a blog entry or book review on Amazon or other book site.
This is a preview copy that has not undergone a full copy-edit or final page layout, so you can expect those to still be somewhat rough.
In return for your help, you’ll get:
..to be among the first to read the book.
A first edition copy of the printed book.
Acknowledgement as a tech reviewer and thanks in the book.
