Trapdoor In The Sun

Alan Shanahan, Technician & Consultant

Tag Archives: developers


by Leave a comment

The Transition To Force.com Developer

This is aimed at Java and C# developers who want to move into cloud computing and create demand for their skills.

One thing I regard as vital is to constantly keep an eye on your career progression. My aim is to make myself just that little bit more employable every year. It’s tough to combine this with a busy work schedule, but just because it’s tough doesn’t mean it’s not worthwhile.

The last year has seen huge growth and even bigger projections for the future of Cloud Computing. The trends are all upward, there’s no doubt. Gartner’s recent report states that the areas of “social, mobile, big data and cloud” will experience growth as they are championed by new IT leaders. Forrester predicts patterns of growth that are also encouraging. Most pundits and industry commentators agree and many of the big players are positioning themselves along these lines.

Along with explosive sales in mobile and tablet devices, it’s clear that mobile applications (particularly those that are cloud-based) will feature strongly in a global IT context for some time to come.

Add social media to the mix and it’s clear that Salesforce.com (with its Force.com platform) has its bases well and truly covered. They’ve got Chatter; Facebook and Twitter integration is covered; Touch is their technology stack for mobile; mobile apps proliferate.

And at their heart SFDC are “Cloud”. They are pioneers in the arena, that’s an undisputed fact.

Getting down to nuts and bolts, if you’re a developer with Java or C# skills, there’s a definite path you can take to sharpen your skills to become a certified Force.com developer. If you have designs on such a career path, my advice would be to follow these lists:

Application & Configuration Skills:

  • Get yourself trained up on the (Sales Force Automation) SFA application and, optionally, get yourself a certification
  • Understand what Account, Contact, Opportunity, Pricebook, Product, Case, Lead are, and what they do
  • Understand how to use Reports & Dashboards
  • Preferably, attend at least one of the Salesforce Administrator courses
  • Learn how to configure custom objects, custom fields, page layouts, field sets, formula fields, validation rules, custom buttons & links
  • Learn about Security, Roles & Profiles, field-level security
  • Get acquainted with Workflow and Approvals, what they are, what they can do
  • Learn how to import data with the Data Import Wizard

Technical & Coding Skills:

  • Sign up for a free SFDC Developer org
  • Learn about coding on the Force.com platform: Apex Triggers & Classes, VisualForce, Components, Custom Settings, Custom Labels, Resources
  • Understand what Force.com Governor Limits are, how to apply them
  • Learn what SFDC API usage limits are and understand how they may affect any application you design
  • Learn the new coding paradigms for bulk processing (a large topic but here’s a useful starter blog post)
  • Understand Lists, Maps, Sets and when to use them to handle batches of data
  • Understand Test Classes & methods
  • Learn about Apex Batch and Scheduled jobs
  • Learn how to use the SFDC SOAP and REST APIs and Workflow Outbound Messaging options
  • Learn how to extend the API with your own custom web services
  • Understand how to process inbound emails in Apex
  • Use Eclipse and the Force.com plugin to maintain Apex & Visualforce code and to examine the database schema
  • Learn how to debug code and troubleshoot using the various tools on the Force.com platform
  • Understand all the places (or “hooks”) where you can plug into the SFDC application to customise it
  • Gain at least a cursory understanding of SControls (deprecated functionality) in case you need to modernise or maintain old applications
  • Understand how to use the Apex Data Loader
  • To help you on your way with the above, here is a link to all SFDC documentation (pay special attention to the Apex and Visualforce reference docs)

You can also take your existing skills with you, and these will be invaluable:

  • Database and application design skills
  • Data Migration skills
  • Data Integration knowledge
  • Service-Oriented Architecture (SOA) and web service knowledge
  • Industry vertical expertise
  • Test-Driven Development (TDD) strategies
  • Source code version control tools and techniques
  • Multi-developer, multi work-stream development
  • Application testing strategies & methods

You can acquire all the training resources you need with little or no cost, but you can also accelerate your ramp-up time by attending SFDC formal training courses.

Anecdotal evidence would suggest that there are at least some Java developers out there who have a reluctance to extend their knowledge into the Force.com arena, primarily because of the more restricted nature of the environment. However, if you take the plunge, the rewards are there for the taking and you’ll join a growing army of technicians with niche skills.

Don’t be too quick to assume, however, that because you can instantly read Apex code (which a Java or C/Whatever coder can), your transition will be instant – there’s a little more to it than that. Most who took that path with that outlook fell foul of platform differences, a.k.a. the famed Governor Limits. But, learning the How, When and Why of these limits will help get you to the next stage in the transition process.

Acronyms used above:

  • SFDC = SalesForceDotCom
  • API = Application Programming Interface
  • SOA = Service-Oriented Architecture
  • SOAP = Simple Object Access Protocol
  • REST = Representational State Transfer
  • TDD = Test-Driven Development
Advertisement


by Leave a comment

Developer Maturity

Thirty-odd years ago, I wrote my first lines of BASIC code on an Apple II computer donated to my secondary school by some local businesses. We were the first of our school and, to some degree, our generation to have access to such a device. I was hooked from the word go. All these years and a few dozen jobs later, I can tell you I’ve seen the full spectrum of good and bad in the world of programming; I may even have contributed to the bad side, but I live in hope that most of what I produced was leaning towards the better side of things.

But I can see definite steps in my progression in those intervening years; let me focus on programming itself, or “development” as the industry likes to call it. Today, I have a very different mindset to that of my teen years. My young naive self revelled in the idea that you could type an arbitrary set of instructions into a machine and it could do the most marvellous things. Coding was an end in itself! It existed just so that beautiful programs could be written and run. I had a lot to learn.

Then I started working in the real world. My programs were now being used by real people, in a real business, every day. There was a huge amount of job satisfaction in that idea. Everything changed. My “hobby” was now something to take seriously and it had to perform to a new standard. But I didn’t fully realise that and I still saw programming as an isolated pursuit with its own intrinsic value; in my mind it was a primary activity with its own purpose rather than an enabler. This illustrated an immaturity in terms of my business viewpoint.

Many years later, I’ve managed programmers and development teams. Still doing that. I’ve designing solutions for customers that are implemented by these teams. I’ve seen and reviewed a lot of code. In that sea of code, the full spectrum of quality exists. Some bad practices can have a subjective slant to them, but other bad practices are just plain bad. I’ll tackle the subject of quality later, it’s just too big to even contemplate here. But one point on quality is worth reiterating here and now: quality is everyone’s responsibility. I won’t explain that further, I believe the words do that for themselves. You own quality. You own problems created by your programs, no matter how trivial. At least to some extent. You owe it to your team to properly ring fence and test scenarios your programs are supposed to handle. You owe it to the customers who are paying for your development efforts.

And what I have seen is a set of behaviour patterns that seem to be repeating.

Firstly, there is an obvious disconnect between some programmers and the end user they are programming for. Think about users. Someone will sit in front of a screen and use your programs. They are real people, no matter how distant they are, or how imaginary they seem.

Another misalignment I’ve seen is that some programmers don’t conceive that data represents real world things. Financial data represents money, real money, not imaginary money. This is important to customers. It’s their money, the life blood of their business, which would simply curl up and die without it.

Polish! Polish your code. Polish the user interface. Try to break your programs. Keep trying until they no longer break.

Open your mind. Let go. Don’t be afraid to rework what you’ve written. The best writers and authors do this regularly; that’s why they’re the best. Coding is not an end in itself, it’s a means to an end: the business aim is the end. Code is just an enabler.

Do these things…

…and you’ll be all grown up.

[Note: I’ve emphasised “some programmers” in this piece. I’ve worked and continue to work with many superb developers. It’s worth mentioning.]