What I did in my holidays...

Bumped into this web site:

http://codility.com

It's a web site where they test coders, and every so often, they offer a public challenge you can use to hone your algorithm-design and coding skills.

These are great brain-teasers, and I had tremendous fun solving the challenges - I did the last one of 2013 and the new one of 2014 that was just released.

And I managed to get some badges!





Warning: the challenges are not trivial, and it's one of those 'cannot let it go' things: once you click 'Challenge yourself', you'll find yourself hooked!

Adobe CC. From selling assets to selling consumables.

Adobe recently made a massive switch: they switched from being a tool vendor to becoming a reseller of consumables. The Adobe CC is treated like a consumable (like electricity, petrol, toilet paper, air travel,...), whereas the Adobe CS was treated like an asset (like a chisel, a car, a house...).

The question on my mind is: if I look at companies selling consumables, how much innovation do I see? How much innovation is for the benefit of the consumer?

If I look at companies selling consumables from a monopoly situation, how much innovation do I see?

It'll be interesting to compare the amount of R&D in asset companies vs consumable companies.

Interesting times ahead!

ExtendScript Toolkit Unbearably Slow?

ExtendScript Toolkit Slowness

Note added 9-May-2017: in addition to the issues outlined below, another, now common, reason for slowness of ESTK on Macs is the 'app nap'. Background apps on Mac 'fall asleep' and become really slow (to save energy). If ESTK is talking to InDesign and InDesign falls asleep, things get really slow. Quickly switching back and forth to InDesign, then back to ESTK wakes them up. On CS6 you can disable App Nap as a 'Get Info' property on the ESTK and InDesign applications in the Finder. For CC and higher, no quick fixes. I have turned off App Nap on ESTK and InDesign CS6, and I use CS6 for script development when I need ESTK.

Recently, I was working on a fairly large script-based solution for Adobe InDesign.
Things progressed well, and the script was growing at a rapid pace.
For small tasks, I tend to write scripts more in a procedural, ad-hoc manner. For more complex tasks, I will normally define some formal object model with object classes, methods, getters, setters, inheritance,...
In this particular case, the system was teetering between the two realms, and it was clear I'd need to go for a formal object-oriented approach some time later, as the complexity started to increase.
But as I was still testing the waters and getting my head around the many aspects of the solution, I had decided not to start on an object model and a class architecture until things had become better defined. Often, with these projects, I go through a ping-pong process with the users and other stakeholders, and valuable information only emerges after a few initial prototypes have been tried out 'in real life'.
Because the script had to serve as a go-between InDesign and an outside system with a wide API (Application Programming Interface), I had a growing collection of symbolic constants, each representing some kind of 'magical' value for the outside system's API.
All was well: the solution grew, and gradually more and more functionality became available; users were impressed.
Speed and responsiveness were great, even when massive amounts of data were being chewed on.
ExtendScript, despite being an interpreted language, is amazingly fast if you know how to treat it correctly.
Until suddenly some unexpected issue came out of the blue: for some reason, ExtendScript Toolkit became unbearably slow.
At first I thought it was one of those unexplicable things that come and go. So I restarted my Mac, reset the preferences, created a brand new user account and tried that way, switched to another Mac. All to no avail.
Simply trying to run the script in ExtendScript Toolkit almost immediately caused the colored pizza to appear and everything ran like molasses.
Running the script straight from the InDesign Scripts palette worked fine. It was only when the ExtendScript Toolkit got involved that things got really slow.
Initially, it was still somewhat bearable. Having to wait a few minutes just to inspect a variable is annoying, but you can grit your teeth and wait it out. But things got out of control very rapidly: a few hours later, the minute-long waits had become half-hour waits.
Run, breakpoint, colored pizza for 30 minutes. Run, breakpoint, colored pizza for 30 minutes...
Ok, this lobster had enough: the water in the pot was becoming too hot, and something had to be done. I started to investigate.
I used the Mac's Activity Monitor to sample the ExtendScript Toolkit process, and found that the ExtendScript toolkit was working very hard. Some poking and prodding revealed that nearly all that hard work was related to the Data Browser element in the ExtendScript Toolkit.
Eventually, I figured out it had to do with the quantity of constants and variables I had created in the global variable space. The Data Browser had trouble displaying all those elements. If I closed the Data Browser, ExtendScript Toolkit's speed became normal.
For what little info I was able to glean from my poking around, I suspect the Data Browser has an extremely inefficient lookup buried somewhere inside its code: it looks like it has many levels of nested linear lookups, and as more elements start populating the global variable space, things get exponentially (or worse than exponentially) slower.
So, I had to refactor my code earlier than expected - and that fixed the issue. The main change was that instead of something like:

const kExternalSys_BoldAttribute   = 0x0001;
const kExternalSys_ItalicAttribute = 0x0002;
...

and so on, thousands of those, I made it into:

var kCST =
{
ExternalSys_BoldAttribute:   0x0001,
ExternalSys_ItalicAttribute: 0x0002
...
};
And instead of referring to kWordSys_BoldAttribute, I now referred to kKCST.WordSys_BoldAttribute and so on.
I further reduced the footprint in the global space by making the script fully object oriented, with nearly all functions as methods attached to object classes, rather than having gobs of globally defined functions.
And now it's all fine again!
So, the morale: keep the global variable space as empty as possible, or ExtendScript Toolkit will get ya!

GetURLs.jsx - access HTTP content from InDesign ExtendScript

Note added 9-May-2017: I've revisited GetURL and made a more modern version. More info here:

http://coppieters.nz/?p=133

----

In 2008, I created a sample InDesign ExtendScript called GetURLs.jsx. GetURLs.jsx is a limited http client; it allows you to fetch http URLs straight from an InDesign ExtendScript.
I used the script as sample material to demonstrate a programming technique (state machines).
It turned out the script was quite popular in its own right; I've been adding little tweaks to it over time.
The latest version has been enhanced to handle redirections (when the server returns a status code HTTP 1.0/301 Moved Permanently). Hope it works for you!

The original blog post is here:

http://rorohiko.blogspot.co.nz/2008_07_01_archive.html

and the download link is here:

http://www.rorohiko.com/podcast/geturl.zip

Cheers,

Kris

Fun with Arduino - how to get into assembler programming.

I am having fun with an Arduino Uno. I am old school; I started with a TRS-80 in the late 1970's, did a lot of Z80 assembly language. My computer had a massive memory (for the time) of 16KB, so in order to wring out a bit more, assembler was the way to go.

Gotta say, this Arduino brings back a lot of memories.

I bought a few tutorial kits (e.g. an Arduino Uno), and by the looks of it, the Arduino has a lot of similarities with my first computer, but it's a bit more powerful.

Its clock is 16MHz (my TRS-80 was 1.7MHz).
Its memory is 32KB Flash + 2KB SRAM + 1KB EEPROM (my TRS-80 had 16KB SRAM + 12KB ROM. And cassette tapes for storage)
It uses an 8-bit CPU (so did my TRS-80, which used a Z80).
Turns out that the Arduino IDE uses C++ as its 'main language' (that was Level 2 Basic on my TRS-80).

(And yes, these are KB - Kilobytes. Not Tera, not Giga, not Mega. Kilo. 1KB being 1024 Bytes. I still find it strange how, in 1978, I thought 16KB was unimaginably large, whereas nowadays 16KB in unimaginably small. My MacBook Pro has 8GB SRAM, more than 500,000 times what my TRS-80 had. Wow. That still flabbergasts me.)

The Arduino IDE is cool and all that, but feels kind of wasteful, so I set out on a quest to do some assembler programming on the Arduino.

Turns out that a lot of effort seems to have gone into discouraging doing this. There is a lot of 'magic' going on, and the Arduino IDE hides a lot of complexity from view. With good reason; there is often no need to look beyond the magic. One can opt to just accept it, and it works perfectly fine.

But I like to understand how it all works; dig into the magic, take it apart, and figure out how it works. I've always found that if you understand the magic, you can make better use of it.

I am pretty sure that most of my future Arduino (or Pinguino or Uno32; I bought one each of those too!) exploits will be using mostly, if not exclusively C/C++, but my first experiments are aimed at understanding how to do assembler programming.

I had to do a lot of fishing around to get enough info: lots and lots of little tidbits here and there, but no real 'how to get started' cookbook. So I decided to put the tidbits together in a wee dokuwiki page, and make it as complete as possible, in the hopes that someone else finds it useful.

While searching, often all I am looking for are a few good, complete examples, and that gets me going.

The dokuwiki page below is an attempt to help other people get going, by offering complete, working examples.

I tried to cover all the necessary steps, from patching up your IDE to accept assembly source code down to some increasingly advanced sample assembler programs.

There are some things I've skimmed over (e.g. I assume you know how to set up a Java development environment on your computer).

So, here goes. In case you're looking to get started with Arduino and assembler, here are my 'useful tidbits', for what they're worth:

http://rwf.co/dokuwiki/doku.php?id=smallcpus

If you want more detail for particular things, let me know. If I can find the time, I'll write additional instructions if needed.

Cheers,

Kris

How to Use DropBox More Efficiently

Lately, we've started to use DropBox more and more. Initially, we used it mainly as a tool to keep multiple workstations and laptops synchronized, as well as a means to quickly provide someone a downloadable link to a file without having to fumble about with FTP or WebDAV or other complicated things.

Then we started using the shared folders more and more.

As we nearly always work together with other people and companies scattered all over the globe, DropBox is a godsend: we set up a shared folder, and that's it. Through DropBox, a distributed workgroup can easily share a bunch of files.

But sharing wildly with all kinds of partners created a small problem. How does one keep track of all these shared folders in DropBox. Which is shared with who? Of course, one can go find out via the DropBox web site, but that's not really a quick thing.

So, now we've started to use specific names for the DropBox folders. If a DropBox folder is shared between two parties, we refer to it as a 'tunnel', and we append the name of the two sharing parties.

If we were regularly working together with a company called, say, 'Ynapmoc', I'd use a folder called 'Tunnel_Ynapmoc_Rorohiko' or 'Tunnel_Rorohiko_Ynapmoc'. Often we tend to work on multiple projects with our partners, and we use the tunnel for shuttling shared documents between us.

If a DropBox folder is shared between more than two parties, we would instead create a new folder for each individual project, and simply use the word 'Shared' followed by the name of the project. So, if we were working with, say, three parties on a project called, say, 'Terces', the folder would be called 'Shared_Terces'.

My DropBox folder now looks a lot better organized, and I can tell immediately what each shared folder is meant for.

If you get a request to share a dropbox folder with a name that starts with 'Tunnel_...' you'll know what that means!

Cheers,

Kris

Mac OS X Lion - how to get Unicode back on your Character Viewer.

One handy little tool I use all the time in Mac OS X is the Characters Palette which I can access via the menu bar.

You enable it by going to the System Preferences - Keyboard, and ticking 'Show Keyboard & Character Viewers in menu bar'.

I've upgraded to Lion a wee while back, and had not needed the characters palette - but recently I wanted to have a quick look at some Unicode character codes. I brought up the characters palette via the menu bar:

But the resulting palette seemed to be quite spartan and bare and the familiar Unicode table just was not there. 

Turns out: the Unicode table is still there, but you need to turn it on first. Click on the settings button, and select 'Customize List...'.

 Then scroll all the way down until you see 'Code Tables'. Click the disclosure triangle and tick the checkbox for Unicode.

That adds the Unicode table back. Great for browsing around in Unicode!

Hope this saves someone some time and frustration!

Cheers,

Kris