Are Mac users quicker to upgrade to InDesign CS5 than Windows users?

I recently saw some Facebook 'polls' that looked like an attempt to probe who is using what version of InDesign. Oftentimes, these polls fall flat because the sample size is too small.

But if you want to know how the InDesign user base divvies up, at Rorohiko we have fairly significant, up to date information - further down, I'll share with you some usable percentages and graphs for the month of March 2011.

The clue is in our web server logs. We watch downloads of our APID ToolAssistant for InDesign plug-in, and that tells us a lot (http://www.rorohiko.com/apidtoolassistant).

Here's how it works. APID ToolAssistant in itself does not do anything obvious for the end-user, but in order to use one or more of our extensive range of plug-ins, users need to install APID ToolAssistant on their computer. Each user needs to install APID ToolAssistant only once per installed version of InDesign. Every month we get a few hundreds of downloads of APID ToolAssistant.

What makes APID ToolAssistant unique as a market probing mechanism is that we still support versions of InDesign as far back as InDesign CS - we cover the whole range of CS, CS2, CS3, CS4 and CS5.

On top of that, our downloads are separated - instead of one single download, we provide separate downloads for each platform and each version - 10 downloads in total - so we can monitor each platform/version combination separately.

In March 2011, we had 1548 downloads - and these were separated up as shown below.

To paraphrase the graphs below in words: Mac and Windows are about even, about 10% of all users are still using CS and CS2 and about 30% of all users is still on CS3 or below. Finally, CS5 is slightly ahead of CS4.

P.S. If this info is interesting to you, contact consulting@rorohiko.com - there's more where that came from!

Downloads of APID ToolAssistant in March 2011
Mac, CS	41	3%
Mac, CS2	46	3%
Mac, CS3	130	8%
Mac, CS4	236	15%
Mac, CS5	363	23%
Win, CS	42	3%
Win, CS2	51	3%
Win, CS3	135	9%
Win, CS4	257	17%
Win, CS5	247	16%
Total	1548

Downloads of Mac APID ToolAssistant in March 2011
CS	41	5%
CS2	46	6%
CS3	130	16%
CS4	236	29%
CS5	363	44%
Total	816

Downloads of Windows APID ToolAssistant in March 2011
CS	42	6%
CS2	51	7%
CS3	135	18%
CS4	257	35%
CS5	247	34%
Total	732

Downloads of APID ToolAssistant in March 2011
Mac	816	53%
Windows	732	47%
Total	1548

More Efficient Storage of Virtual Machine Backups

Here's a little trick I use to save substantial amounts of disk space. 

For testing our software, we heavily rely on virtual machines, mostly running various versions of Windows - we use VMware (both VMware Workstation on PC and VMware Fusion on Mac), Parallels, and VirtualBox extensively. 

VirtualBox is my current favorite - it's come a long way since the earlier versions, and to me it's now on a par with VMware and Parallels. Furthermore, it has a number of very handy features that the other two lack, and above all, it's free!

The nice thing with virtual machines that we can easily 'roll back' to a known state before starting a test session. All three of the tools mentioned above have a 'snapshotting' feature that makes 'rolling back' easy.

However, snapshots of virtual machines come at a cost: the more snapshots you pile up onto a single virtual machine, the slower that virtual machine becomes. 

To avoid the performance penalty, we instead often opt for a more primitive backup strategy: we regularly make compressed copies of a 'known good' virtual machine, and restore them as needed.

Here's the trick I devised to make the compressed copies substantially smaller without loss of data: 

1) Get rid of all snapshots before backing up (so the virtual hard disk becomes a single, large file).

2) Optionally, clear any temp files and so on.

3) Use a 'wiper' tool to erase any unused disk space in the virtual machine before compressing. 

If you don't do this, any unused disk space on the virtual hard disks will contain more or less random bit patterns, which don't compress very well.

Yet, if you zero out any unused disk space, the unused disk space on the virtual drive compresses extremely well. 

For example, I just have made a compressed backup of a heavily used virtual machine twice - first without erasing the unused space and then again after erasing unused space. The compressed file size fell from close to 80GB in size to 50GB in size. How's that for savings?

I mostly use a Windows-based tool called Eraser - it's free and open source.

The main caveat is that you have to make it erase any unused space with zeroes. 

Eraser's main purpose is to make erased data irretrievable for security-purposes, and by default it will fill up any unused disk space with random bit patterns, but that is not what we're after here.

To make Eraser work for me I had to add a 'custom' bit pattern first (which is simply a zero).

There are a few variants of Eraser available - don't use the most recent 6.x version that apparently won't allow you to fill unused space with zeroes, but instead insist on using random bit patterns. That is useless for our purpose. 

Instead, you have to download the older version (I used 5.8.8) which allows you to define your own erasure patterns:

http://sourceforge.net/projects/eraser/files/Eraser%205/

After installing, you need to select the Edit - Preferences - Erasing... menu. Then add a new method, call it 'Zero' and set it to use a zero as the bit pattern. 

Then erase the unused space with this pattern. Then, after shutting down, you can compress the virtual machine.

InDesign Scripting: Putting TextFrames in Perspective - for Visually Oriented Scripters

I admit it: I don't know the InDesign Scripting DOM by heart, so I spend a lot of time browsing around in the ExtendScript Toolkit Object Model Viewer.

I frequently work on very diverse projects - sometimes it's GWT/Java, sometimes it's ActionScript, sometimes it's PHP/WordPress, sometimes it's C++ or REALbasic, and so on... - and invariably, when I come back to a particular project, I need to spend some time refreshing basic knowledge.

It's like my brain 'switches' programming environment, and when I am deeply immersed in Java, I almost forget how to spell 'EkstentScript'.

The ExtendScript Toolkit Object Model Viewer (you find it under the 'Help' menu) is great for browsing the object model - but when it's been a while, it still feels like I am wading through molasses. One of the reasons for that is that I am a visually-oriented person. A picture is worth a few thousand mouse-clicks to me!

Lately, I've been revisiting BarredText - one of our latest scripted plug-ins, and to do that, I need to get back up to speed on TextFrames, Columns, Characters, Stories, and so on.
I decided I'd put in a little bit more effort, and put everything into a diagram - I've made a 2-page PDF file as a refresher I'll use next time I need to figure out how those buggers relate.

Because this might be useful to other people, I decided to release the PDF file under the 'Attribution-Share Alike' Creative Commons license:

http://www.rorohiko.com/downloads/rorohiko.blogspot.com-extendscript-textframe.pdf

I am not claiming this is error-free - if you find any errors, or can see ways to improve this, please let me know.

And if you like this - let me know too! Soon, I need to revisit tables and cells in ExtendScript - who knows, if I get enough positive feedback I might do another visual representation.

Easy Access to System Folders on Mac and Windows

Time for a few tidbits! On my list of 'good intentions' for 2011 is an entry 'write more blog posts'.

My idea is that I want to jot down a quick blog post each time I find myself using a trick or technique that might be useful to others, and that can be explained in a relatively short blog post.

(The qualifier 'relatively' in the previous sentence is necessary - I tend to have trouble keeping the number of words in a post down to a reasonable number. I'll try to keep it short and to the point!)

It dawned on me that a lot of tricks I have personally come to find mundane and obvious can be life-changing news to some people. I had forgotten how it was for me, how nothing was obvious, when I started out doing this job long, long time ago.

If you're a hardened, experienced software developer or computer tinkerer - my blog posts are not really for you. You might find the odd gem, but most of the stuff you'll go 'duh - knew that'. But if you're starting out on a new challenge, the wee tricks I'll be describing are things that made my life easier - and I hope they'll make yours easier too.

Ok, to make a living, I am writing software, in various environments, using C++, JavaScript, ExtendScript, REALbasic, PHP, you name it... on Mac, Windows and Linux. As a project grows, invariably I 'll need a spot to put down some 'rubbish' files - temporary files created by my program that are only needed for a little while, and then can get trashed.

Sometimes, while debugging, I want to access those rubbish files with my text editor to inspect their contents - for example, to verify all is well at a certain stage of the program execution.

Mac OS X and Linux (both close relatives of Unix) have a number of spots for storing temporary files - but as on most forms of Unix, you can access that location using the /tmp path. Sometimes /tmp is not a real directory but rather an alias or link to some other place - but that does not matter too much.

If you start a command line session (go to /Applications/Utilities, and start Terminal), you can type

cd /tmp
ls

to see what's in it.

On Windows, you go to the Start button, select the Run... option, and type cmd into the Open field.

Click Ok. That brings up a command line window.

In the command line window, type

cd %TEMP%
dir

to see what's in it.

As it goes, I tend to hop all over the place in my command line sessions - using the cd command to hop from directory to directory.

Occasionally, I find myself in a command line session in a deeply nested directory, and I wish I had a Finder or Explorer window to get a better overview of the directory (aka folder) contents.

That's easy: on Mac, you simply type

open .

And on Windows, you type

explorer .

in the command line (i.e. open<Space><Period><Enter>, or explorer<Space><Period><Enter>), and a Finder or Explorer window will pop up showing the contents of the directory you're in. Then you can start dragging icons of the files you see onto various apps to inspect them. For example, I often use BBEdit, TextWrangler, 0xED on Mac, and UltraEdit or UEStudio on Windows.

If you're on the command line, and you want to inspect a text file in the current directory, that's easy enough too. I am personally well-aquainted with vi, a crusty old Unix text editor, and I use it a lot, but vi is not exactly user-friendly.

No worries - on Mac, if you have TextWrangler installed (which is a free download from BareBones), it should have asked you whether you wanted to install the command line tools. If you're not sure whether you allowed it or not - go to the TextWrangler menu, and select Install Command Line Tools...

From now on, when you're in a command line session in Terminal, you can simply type something like:

edit whateverfilename.log

to inspect the contents of the file whateverfilename.log in TextWrangler, assuming you'd have a file called whateverfilename.log in your current directory.

If you have BBEdit (TextWrangler's big brother) installed, simply substitute bbedit for edit on the command line.

On Windows, it depends on the text editor you have - everyone has Notepad or Wordpad (called write on the command line). If you have UEStudio installed, you can use that too - you could type a command similar to any of the following:

notepad whateverfilename.txt
write anotherfilename.log
uestudio yetanother.out

Now, suppose I wanted to quickly open a Finder window on the /tmp directory without needing to start up the Terminal program. If you go and look on your startup drive, you won't see it - it's there, but the Finder hides system folders like /tmp.

To get there using the Finder, select the Go - Go To Folder... menu item, and type /tmp in the dialog. Click the Go button - and you should get a Finder window on the /tmp folder.

On Windows, to quickly access a hidden folder, you go to the Run... function in the Start menu, and type in the path name. Type %TEMP% to open a window onto the temporary folder. Or type %APPDATA% to get an Explorer window straight onto the current user's hidden application data folder.

On Mac, if you need to be in the /tmp folder a lot (or any other system folder like that - /var/log for example), simply drag the little folder icon of the window for /tmp to the side bar of the Finder window - from now on you can click an icon to have instant Finder access to /tmp

Another cool one to have in the sidebar is the Originals or Masters folder inside your Pictures/iPhoto Library folder - you can get at the original files without having to go through the whole right-click, Show Package Contents routine on the iPhoto Library every time. Be careful though: you should only look at, and not touch the contents of those folders.

Windows 7 has a very similar functionality - you can drag folder icons into the Favorites on the sidebar.

Going from Finder or Explorer to Terminal or the Windows command line is also easy. Suppose you have a Finder window open, and you want to get a Terminal window positioned in the same folder.

Go to the Terminal, and type cd<Space>. Then drag the little folder icon from the Finder window title bar into the Terminal window. It will automatically spell out the correct path name - hit the <Enter> key in the terminal window and you're there.

Windows knows the same trick: in the command line window, type cd<Space> and drag the icon from the Explorer address bar into the command line window.

I hope that was useful! There's more stuff like this I could blog about - let me know whether anyone is interested!

Cheers,

Kris

Self-diagnosing code

Been a long time since I wrote a blog post - so here's a short one, about how you can make your ExtendScript code help you diagnose issues, and how to do it without killing the execution speed.
First of all, a fairly long intro about how I make my code self-diagnosing. I'll be skimping on the details - it's all part of my intro, and I'll get to the real point I want to make later.
When writing code, I nearly always routinely add all kinds of logging to the code. For example, every single function I make gets a little 'intro' and a little, er... 'extro' ;-) ?
function blah(var param) 
{
  ... body ...

  return retVal;

}
becomes
function blah(var param)
{
  if (kTracing) 
  {
     LogEntry("blah, param = " + param);
  }


  ... body ...

  if (kTracing) 

  {

     LogExit("blah);

  }

  return retVal;

}
kTracing is a constant that I define somewhere near the top of the script - e.g.
const kTracing = false;
LogEntry and LogExit are two functions I wrote that append their string parameter to a log file. 
I won't elaborate on those - they're very simple. In my case they're part of a larger set of 'standard' routines I use in all my scripts - I also have LogError, LogWarning, LogNote...and these all append their information to the same log file, and can be suppressed by modifying a constant kLogLevel. Writing those for yourself is left as an exercise. 
Secondly, I religiously test pre-conditions: things that should be true are verified and re-verified. I like using the do-while (false) 'non-loop' construct for bailing out quickly when preconditions are incorrect.
function DoSomethingWithCharacter(c)
{
  do // This is not a loop!
  {

    if (c == null)

    {

     LogError("DoSomethingWithCharacter: c == null");

     break;

    }

    if (! (c instanceof Character)) 
    {

     LogError("DoSomethingWithCharacter: c is not a Character");

     break;
    }


... body of the function ...


  }
  while (false); // This is not a loop! 
}
Not sure whether this is actually any faster than try/catch/throw constructs in ExtendScript, but I do know that in a number of environments like C and C++, try/catch comes with a performance penalty, and might not be available for various complex reasons - whereas I expect do-while(false) to be relatively cheap. 
I do use both constructs - I tend to use try/catch/throw more for really catastrophic issues, or as a workaround for InDesign issues (e.g. testing for 'dead' object references) whereas do-while(false) is used for 'controlled failure'. 
The code above is self-diagnosing: it spits out error messages into my log file every time something is not quite right, and in my experience, the error messages are more 'pin-point' precise than what you'd get with try/catch; with try/catch I often find myself struggling a bit to find the actual location of the error.
Release versions of my scripts will typically have their log level set to zero (which means calls to LogError and friends amount to almost 'do-nothing', apart from a little overhead). When things go wrong, I modify a few constants (kLogLevel, kTracing) at the top of the script, let it do its thing, and often know what the issue is very soon thereafter.
Writing this kind of code takes a bit of extra effort - but it always pays back for itself the first time I get the first hairy bug to diagnose. It's not always possible to use the ExtendScript Toolkit for a debugging session for various reasons, and having the proper testing and logging code ready-to-go is often a life saver.
Now, that's the intro - now onto the real issue I wanted to discuss.
Adding logging code to all my functions comes at a performance penalty: especially 'deep' routines that are called from within loops are often called thousands or millions of times, and even when kTracing is set to false,  this could still incur some overhead.
Now, here's a trick I often use: I use my trusty text editor (BBEdit) to make my logging code disappear and reappear as needed. Here's how it goes: I dress up all my intro and 'extro' code as follows:
...

  /*TRACEIN*/if (kTrace)
  {
    LogEntry("AdjustStory");
  }/*TRACEOUT*/

...

When the code is ready for a production environment, I do a global search-and-replace and replace

/*TRACEIN*/
with
/*TRACEIN*-/
and also (even though it is not necessary, but I am obsessive compulsive about this, so I need to do it to keep things 'even') 
/*TRACEOUT*/ 
is replaced with
/-*TRACEOUT*/
As a result, my tracing code now becomes:
...

  /*TRACEIN*-/if (kTrace)

  {

    LogEntry("AdjustStory");

  }/-*TRACEOUT*/

...

If you look closely, you'll see the whole construct is now a 3-line comment, which will almost certainly be less costly in performance. I can only guess how the ExtendScript engine works, but I suspect that the only cost will be a tiny bit of time when the script is parsed, and there would be no additional cost during repeated execution of the function.

Furthermore, my scripts often are packaged up as .spln files (using Active Page Item Developer), and this automatically strips out all comments when creating a release version of an .spln - so when using this for .spln development, the entry/exit logging code is guaranteed to be completely gone.

When an issue arises, I simply perform the reverse search-and-replace, and re-enable my disabled logging code.

There's lot of additional things you can do with logging - I've only scratched the surface here. For example, sometimes I use an XML format for output of the logging - and the extra effort to do that is rewarded by the fact that I can use an XML editor or XML browser to selectively hide and show whole sections of the log. Anyway, depending on feedback, I might do another post some time later on a few more of these techniques.