I’ve just had my very first online course published at Pluralsight. Here’s a brief description:
Apex is the native language of the Force.com platform, and there is a huge demand for skilled developers in this space. The Java/C# like Apex language looks familiar enough that experienced developers often expect a short learning curve, but the platform is actually radically different, and requires use of a unique set of set of design patterns. In this course, you’ll learn the core concepts that are essential for every Apex programmer to learn, and a roadmap to further resources to help you quickly become an expert in this rapidly growing space.
You can read more about it on the AdvancedApex.com blog.
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.
As many of you know, I do enjoy writing books. Which is a good thing given that I’ve written quite a few of them. I’m proud of all of my books, but there are a few that fall into a special category – and that includes my latest effort.
If you’ve looked at the book market, you’ve probably noticed that a lot of books are very similar. Most subjects offer dozens of competing books that have pretty much the same content. Personally, I’ve always felt that if a good book exists on a particular subject, I shouldn’t waste my time writing another one. As a result, most (if not all) of my books have been either unique, or the first one in a given space. For example: my original Visual Basic Programmer’s Guide to the Windows API was the only book for a long time that dared to teach Visual Basic programmers to use the Windows API. My recent book on teaching leadership skills to teens is nothing like anything else on the market.
Which brings us to Advanced Apex Programming.
As I mentioned in my previous blog post, I’ve been spending more and more time over the past few years working in Apex – the native language of Salesforce.com. I’ve learned a great deal in the process and… well, you know how it is. Sooner or later, if I learn something, I end up writing a book to teach it. In this case, I was astonished to find that nobody has written an advanced Apex book yet. There’s lots of great reference material, a good selection of articles, and plenty of beginner’s texts out there. But there was no book to help the intermediate developers take the next step, and give the advanced developers something to geek out to. Even the domain, AdvancedApex.com was available!
I couldn’t resist.
You can read about the book at AdvancedApex.com. I’m as excited about it as I was that original VB Programmer’s guide. As with that book, I think it’s going to help a lot of programmers write a lot of great code and become more successful. And as an author, hearing from readers that a book I’ve written has helped them build their careers is what really makes it worth the effort.
I wrote an online store. I didn’t really want to, but I just couldn’t find a solution that fit my needs.
I wanted a shopping cart that had really good extensibility – one that could connect to our licensing server not just to allocate keys, but to perform custom operations like allowing purchase of additional installations for existing keys.
What I found was largely disappointing. Not that there weren’t some great packages out there. If I wanted to set up a large online store with many products, it was clear that setting up my own Amazon.com equivalent would not be hard at all. There are any number of powerful online stores with numerous features available. But none of them had exactly the right features, and none had the extensibility I needed.
What I really wanted was a shopping component – some ASP .NET controls that could be dropped onto any ASP.NET page and would somehow work together to implement a shopping cart. There would be a control that would “add to cart” a single product – and a page could have any number of these control to display multiple products. There would be a shopping cart page that would allow modification of quantities or deletion of items from the cart. And there would be a checkout control.
In my ideal solution checkout would be handled by an external processor such as Paypal, and once the order was confirmed my code could issue license keys, download links, send out customer Emails and so on.
After searching through and installing trial versions of numerous packages, I came to realize that none of them came close. The truth is, I didn’t want an online store – I wanted an online store component.
So I wrote one. The excuse I used to justify the time was that it would make a great application note for the latest version of our licensing system. But in truth, it sounded like a lot of fun – and it was. I ended up using authorize.net for the credit card integration (they have the best online documentation for developers of any of the card processors I found other than perhaps Paypal).
There’s still some work ahead to turn it into an application note for distribution, but the store is now live at http://desaware.com/purchase/store.aspx.
Above all, the experience confirmed to me the rightness in the way we decided to extend the licensing system for the newly released version 2. Instead of piling in features, we focused on enhancing the extensibility model. Our licensing system is not so much a licensing application as it is a licensing component – and right now it’s hard for me to imagine a licensing scenario that it can’t implement.
A few months ago I wrote a column for Visual Studio Magazine titled “Where have all the developer’s gone” in which I pointed that interest in programming and computer science seems to be dropping – at least in the United States. And in fact, much of the interest in learning programming seems to be in countries like China, Pakistan, etc. I concluded with a somewhat cautionary note that if we want our kids to become the technologists of the future, it’s up to us to do something about it.
This brought forth a great deal of comment, one of the most interesting questioning why anyone would encourage their kids to go into the software business in the first place. Why would you go into an industry where it’s increasingly difficult to keep up, where jobs are increasingly being outsourced, and where there is rarely long term career viability? Doctors can continue treating patients into their 60’s and 70’s, Lawyers continue lawyering, bankers banking and politicians politicking until they drop dead (and sometimes longer in the case of politicians). But past 40 or so, software developers who aren’t fortunate enough to have solid management gig are likely as not to find themselves unemployed or in some other career.
I’ve been particularly fortunate in this regard. Through a combination of being self-employed, honestly passionate about technology, and a bit of talent, I’ve had the opportunity to continue coding. What’s more, I’ve had the freedom to diversify into all sorts of new technologies beyond my core expertise. But keeping up is an effort. I often compare the life of a software developer to that of Alice in “Through the Looking Glass” – where Alice is told by the Red Queen that she has to run as fast as she can just to stay in place, and to make progress she has to run even faster
Why would anyone wish this on their kids?
It seems that our interests as a nation are radically different from our interests as individuals. There is no doubt that we need a lot of skilled engineers and programmers going forward. Not only do we need to maintain our existing technological base, there’s going to be increasing demand for power engineers and some incredibly sophisticated software to handle the future smart grid (or EnergyNet” as Juval Lowy calls it). Where are those developers going to come from?
I suppose we can continue to import them. But will the United States continue to be a desirable place for migrant technologists? To some degree it is likely, but as their local economies develop, they may find better opportunities at home. And many engineers consider foreign workers to be part of the problem – competition that makes it even less desirable to enter the business. But let’s assume for the moment that for the foreseeable future foreign nationals will continue to provide needed support our technological society, and that it is in our national interest for them to do so – thus making home-grown talent less essential.
What do you encourage your kids to study if not technology?
Yesterday I needed to do a simple Excel add-in.
No problem, right?
Being an experienced .NET developer, I figured this would be a good time to try the Visual Studio Office system – to create the add-in using VB .NET. I mean, how hard could it be?
Not hard at all as it turned out. The project template for the add-in worked well, and it took no time at all to find some simple examples online to build on. I had enough familiarity with the Excel object model to make short work of the task at hand, and the integration that allowed debugging of add-ins in Visual Studio worked brilliantly.
Then it came time to test deployment – as I needed to provide this add-in to a couple of clients.
What a fiasco.
The setup project that was created didn’t work. The instructions on MSDN and other sites for diagnosing problems were complex and unreliable. I found additional articles with suggestions for creating custom installation actions to handle the security issues that might have been the problem. There were clearly differences between versions of the Visual Studio office runtimes depending on framework version and versions of Excel to support, with no clear explanation of which to use and how to create a deployment that will work with both.
I spent as much time trying to figure out the deployment as I did creating the add-in when I decided I was wasting my time. The Visual Studio office support may be nice, but the deployment solution and documentation is abysmal. Microsoft should be ashamed to have released it. It is perhaps the most disappointing experience I’ve had with any Microsoft developer technology.
I ended up porting the code to VBA in an Excel workbook and creating a .xla Excel add-in. Though I missed the intellisence of Visual Studio, the building and debugging experience was fine. And deployment was trivial – save the workbook as an add-in. Deployment consisted of browsing to the add-in file and enabling it – and the add-in worked perfectly on Excel 2003 and 2007 the first time I tried it.
I’d come to think of .NET as current technology rather than the wave of the future. It’s clear to me that at least when it comes to Office, .NET is still future technology – costly, complex and unreliable. If I need to do any more Office add-ins, you can bet I’ll stick with VBA.