Where: Adobe Freemont Campus, Seattle
When: May 3, 2010, from 9:00am- 5:00pm
This workshop is incorporated into the Adobe Creative Suite Developer Summit (May 3 – May 7, 2010).
Registration has officially closed since April 16, but we still have some seats available. If you still would like to enroll please contact [email protected] as soon as possible to check whether we can still accommodate you.
(Photo courtesy of Mark Niemann-Ross)
For more info about the Adobe Creative Suite Developer Summit click this link:
http://www.adobe.com/go/2010csbuDevSummit/
Registration for the Adobe Creative Suite Developer Summit is free, but attendance is limited to 200 participants.
Registering for the workshop Getting Started With the InDesign SDK costs US$1149.00 per person, and attendance is limited to 12 participants.
Avoid missing out – register early!
Description Of The Workshop
- Getting started with Adobe InDesign Plug-In development?
- Does it regularly feel like things don’t make sense when you read the InDesign SDK Programming Guide?
- Is your team in need of more InDesign developers?
- Do you want to be more efficient at developing InDesign Plug-Ins?
Getting up to speed with the InDesign SDK easily takes a newbie between two and six months of non-productive time.
Attending this one-day workshop will slash the time it takes to get up to speed – it will shave at the very least one month from this non-productive lead time.
No doubt you have a good idea what the cost of one developer-month is, so you can easily estimate what value this workshop is to you.
Cost
US$1149.00 per person
Target audience
Check if your profile fits one or more of the following:
- you are or will be involved in InDesign Plug-In development
- you have some experience in C or C++ development
- you might have experience with QuarkXPress XTension development
- you might have experience with other Adobe SDKs
- you might currently already be doing InDesign plug-in development ‘by example’: you copy, paste and mold example code into a plug-in, but you know there are some basic things about the code you don’t fully understand.
If you fit the above description, you really should enroll in our one-day InDesign SDK workshop.
Registration
Registration has officially closed, but we still have some seats available. If you still would like to enroll please contact [email protected] as soon as possible to check whether we can still accommodate you.
About the course
If you have this nagging feeling the InDesign SDK documentation almost makes sense, but not quite, and some things unexpectedly make no sense at all – rest assured, you’re not alone, and this workshop is for you!
As the InDesign SDK Workshop is only one day long, and the InDesign SDK is massive, it is impossible to cover even the basics of the InDesign SDK.
For maximum effect, we’ve instead compiled a list of what we found to be the most important stumbling blocks for experienced and beginning InDesign Plug-In developers alike. The aim of the workshop is to help a developer blaze a path into the SDK, towards early productivity.
1. Advanced C++ programming techniques explained
The InDesign SDK hinges on a number of fairly modern, advanced programming techniques.
Without a thorough understanding of these techniques, an InDesign plug-in developer will often be forced to blindly copy boilerplate code without grasping the mechanisms behind it, which often leads to baffling and hard-to-diagnose bugs and strange behavior.
This issue especially affects C programmers who have been thrown in at the deep end and are forced to use C++ without having had the time to find out how C and C++ are different.
Even though C++ originated in C, it should be approached as a totally different language, and using C++ with a C mindset makes the developer miss out on a number of highly efficient programming techniques.
Examples of concepts one needs to master are: smart pointers, abstract classes, string classes, memory management, reference counting, references vs. pointers, avoiding unwanted dependencies, templates, STL, the boost library.
2. Patterns explained
Another key pillar of the InDesign SDK are a number of patterns – generic programming approaches that help breaking up a complex program into smaller, reusable elements.
Example patterns applicable to the InDesign SDK are: factories and factory methods, singleton, adapter, façade, command, iterator, observer,… Having a good basic understanding of these patterns helps making the InDesign SDK documentation much easier to understand.
3. Getting started
How to get started and how to set up a clean development environment. In many cases, development environments are ‘grown’ organically.
That works, but if for some reason you lose your development environment (e.g. you get a new laptop – yey!), setting everything up from scratch can be a pain.
This can be avoided by defining a development system setup standard – i.e. a description of how to set up a development system, what to install, in what order, where to install it, where to get it from,…
If this is done properly, setting up a new development system can be much less time-consuming, and on top of that, your transported projects can compile without a hitch – no need for adjustments.
This section of the workshop explores a real-life, proven development system standard. This standard can then be used as a starting point for your own in-house standard.
Defining such a standard is a little up-front investment with a tremendous payback; and as a bonus, it also works better with source code control systems.
4. IDE files
InDesign SDK developers need to be quite familiar with their IDEs. More often than not, a developer will use more than one IDE on a plug-in project – Xcode as well as Visual Studio.
A good understanding of the basic structure of a plug-in project allows you to quickly diagnose issues – all too often, projects are simply copies of SDK samples that have been gradually transmogrified into something that works, but without really understanding the various settings.
This leads to ‘brittle projects’ – where a single preference change causes unexpected problems, or where something that should be an easy, global change does not propagate properly to subprojects.
Things looked at in this section at are how to ‘clean out’ IDE projects in an efficient way to remove needless, possibly lethal dependencies, remove unneeded settings, and rationalize dependencies.
5. InDesign SDK concepts
The InDesign SDK is an abstract object-oriented environment, populated by abstract entities called ‘boss classes’, ‘boss objects’, ‘databases’, etc… This environment is layered on top of a few other nested abstract environments.
Right at the bottom layer we find C++, then some layered abstractions in-between, and finally at the top layer we have the InDesign SDK.
Because they are separated by multiple layers of abstraction, C++ has very little to do with the InDesign SDK. In some respects, C++ is not much more than a low-level detail of the InDesign SDK.
The problem is that both C++ and the InDesign SDK are object- oriented, and as a result, they use the same words to describe similar concepts, but at a totally different level of abstraction – e.g. ‘parent’, ‘child’, ‘inherit’, have similar meaning both in the C ++ world and in the InDesign SDK world, but they are really a long way removed from each other by multiple layers of abstraction.
When reading source code for an InDesign plug-in, it is often hard to understand what level of abstraction to ‘think at’. Compare it to electronics, networks and network protocols. The word ‘port’ can mean:
- a TCP/IP port (a highly abstract thing)
- an Ethernet port (a little hole in which you plug an Ethernet cable)
- a logic gate port (one of the little solder pads on an integrated circuit)
All meanings of the word port share some features (e.g. you can connect to a port – on all levels of abstraction), yet they are totally different things.
The same thing happens in the InDesign SDK – if one person is talking ‘C++’ and the other person is listening ‘InDesign SDK’, things won’t make sense.
This aspect of the workshop is about how to know from the context what level of abstraction to ‘think in’ when reading documentation or source code – and what sounded like gobbledygook at first will suddenly makes sense!
6. Testing and debugging techiques
Because InDesign is such a massive system, plug-ins have to run in a fairly complex environment, and making sure your plug-in is as robust as possible in a number of respects is an important aspect of plug-in development.
To make your plug-in as robust as possible, testing (in the debug as well as in the release versions of InDesign) is important, and needs to be inherently designed into your plug-in.
If testing is part of your development process from the get-go, there are much less baffling bugs to diagnose. This section will handle various testing techniques and testing tools available, and how to use them to tackle bugs.
Logistics
The US$1149.00 price of the training includes lunch on Monday, May 3, 2010.
During the course there will be very little or no time for hands-on; you also need to bring your own laptop if so desired.
You also need to arrange your own lodging and travel – Kris will be staying at the Courtyard Marriott on Union Bay during the summit. There are no hotels within a short distance of the campus – this is one of the closest (on a nice day, the walk from the hotel to the campus takes about half an hour, and is quite pleasant).
