I’m pleased to announce immediate availability of Kindle and Nook editions of Advanced Apex programming. The Kindle edition should also be available on Amazon.co.uk, Amazon.de, Amazon.it, Amazon.es and, as I understand it, to visitors from India on the main Amazon.com site.
This is the first technical book I published as an eBook, and I found the conversion process to be … interesting. The challenge related to code listings – how do you render listings in a format that can display in multiple resolutions on everything from a desktop to a smartphone? eBooks do support fixed fonts, but many do not support horizontal scrolling, and arbitrary wrapping of code can make it completely unreadable.
After some experimentation, I ended up including the listings as screen captured images from the Force.com IDE. This guaranteed consistent formatting, and allowed me to use a smaller font. It also allowed use of syntax coloring. There are tradeoffs to this approach – for one thing, the code is not text searchable. Use of color also makes the code a bit harder to read on older ePaper devices (like the original Kindles).
If you have a color Kindle or Nook, or one of the newer high-contrast e-paper readers, it should look very good. For older e-paper devices or smaller devices (like Smartphones), you’ll probably want to download the sample code to refer to as you read the book.
For the moment, the Kindle editions are not yet linked to the entries on the print edition on Amazon (that usually takes a few days).
You can find the latest links to purchase here.
I just came back from the Dreamforce conference with an epiphany – Force.com is the next Visual Basic. Some less experienced software developers might think that’s an insult, but those of us who have been around know that it’s not merely a compliment – it’s an observation that, if true, represents a potential tectonic shift to our industry.
To understand why, I need to take you back over 20 years.
When Visual Basic 1.0 came out (I participated in the original beta program), the reactions to the product fell into three categories:
- Most professional C++ programmers dismissed it. VB was a “toy language” or a “glue language” for components – not for serious software development.
- Increasing number of software engineers embraced the language because, to put it simply, when it came to desktop applications you could be an order of magnitude more productive in VB than in C++. It may not have had the stature and features of a “real” professional language, but it sure was profitable to work in it.
- VB was easy enough for anyone to use, so everyone did. Doctors, lawyers, students – millions of VB developers sprang up out of nowhere and wrote a lot of code. Much of it was very bad code, but that’s what happens when a bunch of amateurs get in the game. Entire book, magazine and training industries grew up to help them get better, and many of them did and built entire careers around the platform.
By the time VB6 came around, it was the most popular software development language and platform in the world. Simply because it was easy, and it was productive.
Why was it productive? Because VB put an abstraction layer over the Windows API that was infinitely easier to use than coding to the native API or other available frameworks such as MFC or ATL. You couldn’t do everything in VB6, but you could do most of what you needed, and could call the API directly if you really needed to. Having a rich set of available components to purchase didn’t hurt either.
Microsoft did a lot of things right building the VB community. They had great developer and ISV relations. They supported several conferences. There were books, documentation, whitepapers and so on. They really set the standard on how to build a platform.
Then they created the .NET framework.
There was a lot of negative reaction from the original VB6 community towards VB .NET, some calling it “VB .NOT” or VB.Fred (coined by Bill Vaughn). Some programmers made the transition. Some switched to C#. But two things were clear. First, VB .NET was indeed a powerful, serious, professional language and platform for software developers. Personally, I love it, and still use it all the time. But it was equally clear that VB .NET is not easy. In fact, the entire .NET framework is robust, powerful, sophisticated and complex. It’s a great platform for software developers, but is it a platform that makes it easy for non-programmers to write line of business applications? Not even close.
Both VB .NET and C# are native languages to the .NET framework – the Windows API of today’s software. Missing was the magic of the original VB – that layer of abstraction that made it easy for anyone to write software.
I’ve been searching for that magic for a long time. I kept waiting for it to appear out of nowhere the way VB 1.0 did. I sure didn’t expect it to sneak up on me from behind.
Going to Dreamforce? Be sure to go to the Developer Keynote on Thursday at 3:00pm where Salesforce will be giving everyone who attends a free copy of “Advanced Apex Programming”!
Ok, it’s not free – you did pay for your Dreamforce pass, so technically it’s included in the conference cost, but you know what I mean.
You’re also welcome to come by any of my sessions, or developer theater talk.
… or stop by the Full Circle CRM booth (#125) where I’ll be most of the time when I’m not presenting or attending sessions.
I’ll be doing a presentation at the Developer Theater at Dreamforce at 10:00am on Thursday
Here’s the official description:
Real programmers use Apex
Salesforce has always been known for its powerful point-and-click customization tools. The “Clicks before Code” mantra expressed the idea that a wide variety of business processes and use cases could be solved using workflows, formulas and other non-programming techniques. But in truth, Force.com is a software development platform – as robust and powerful as frameworks like .NET or J2EE. As such, it’s no longer enough to know some language syntax and specific techniques. You need to think as a software architect, to be able to draw on multiple design patterns based on requirements and limits, and to consider lifecycle costs (and how to mitigate them in Force.com through good design, testing and diagnostics).
In this session you’ll meet Dan Appleman, the author of the new book “Advanced Apex Programming for Salesforce.com and Force.com” that builds on the existing Apex and Force.com documentation to help developers reach that next level. You’ll discover how (and why) a past Microsoft MVP and expert .NET developer ended up writing a major AppExchange package, and some of the surprising things he discovered along the way.
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.