Month: February 2023

Wednesday, June 7th. 2023, Phoenix, Arizona.

This is the day before the Creative Developer Summit, which is on June 8th.

I’ll be running an interactive, one-day advanced workshop during the Creative Pro Week: https://creativeproweek.com/

The workshop is targeted at developers working with Adobe Creative Cloud apps and will cover subjects related to ExtendScript, CEP, UXPScript and a little C++.

I know that many of you struggle with seemingly unpredictable behavior during the development and debugging of your scripts and extensions. This workshop provides you with the background knowledge you need to avoid many pitfalls and oddities.

The cost for a one-day pass for just the workshop on the 7th would be US$372.50.

This includes breakfast and networking lunches.

A two-day pass (workshop on June 7th + Creative Developer Summit on June 8th) is US$647.50.

The workshop will not be recorded, and your physical presence is required. You need to bring a laptop.

Please send expressions of interest, requests, tips, ideas to [email protected]

If you want to register, please contact me at [email protected] – I’ll give you a discount code you need to use when registering at https://creativeproweek.com/

The workshop only has room for 20 attendees. Don’t dawdle if you don’t want to miss out.

The workshop content will be flexible, and in part will be shaped by what is of most interest to the attendees. Subjects we’ll touch on:

Pragmatic Extension Development

• DRY (Don’t Repeat Yourself): Extensive code sharing between UXPScript/ExtendScript/CEP/Node

• Shared Service Modules: transparently call across divides into services provided in server, ExtendScript or CEP JavaScript code.
  – allow ExtendScript to call Node/JS functions
  – allow server-based code running in an iframe to call ES functions
  – …

• Efficient debugging, e.g.
  – how to debug the startup code for a panel
  – in a single debug session, debug ExtendScript, CEP JavaScript and browser-side JavaScript, all at the same time. This technique only applies to some Creative Cloud apps.

• Server-based panel UI for easy updating: move the UI code from locally stored ZXP into server-stored scripts. Run the panel UI from an iframe served from a remote host.
  
• Test-driven code: write self-testing code
  
• Write defensive, self-debugging code by adding debug instrumentation
  
• CEPSparker: hit the ground running and generate full-fledged starter code for an extension for any of the Creative Cloud apps.
  
• JSInterface – the counterpart to CSInterface: Tap the full power of Node/JS from ExtendScript. Make asynchronous calls from ExtendScript into Node/JS.
  
• Mix and match ExtendScript, CEP JavaScript and UXPScript

• Efficient logging

If there is interest:

• Writing ExtendScript DLLs: how to easily enhance ExtendScript with C++.

• TypeScript-enabled CEP development

• Transmogrifying InDesign EPUB output
  
• Interesting stuff you can do with InDesign IDML files

The Tightener project is still moving forward. I’ve just released alpha version 0.0.8.

Tightener is ‘automation glue’ – it ties together all kinds of computer softwares and allows them to interact in a structured and efficient manner.

Tightener is a developer’s tool – it lives in the background and allows developers to integrate disparate systems.

Watch this little Youtube demo (skip to time stamp 08:00 if you don’t want to see the intro):
https://www.youtube.com/watch?v=_r55k54AuBA

https://github.com/zwettemaan/TightenerDocs/wiki/Tightener-Architecture

This example shows how Tightener is used to make a bridge between Jupyter Notebooks (https://jupyter.org/ – originally from the Python world), and ExtendScript or UXPScript in InDesign.

This combo of Jupyter Notebooks and ExtendScript allows would-be scripters a much smoother way to ‘get into’ scripting.

For someone new to scripting, using Jupyter Notebooks is much more ‘natural’, interactive and instructive than using more specialized tools like Visual Studio Code.

Personally, I use Jupyter Notebooks during the ‘first figure it out’ phases of a new project. Once the basic ingredients have been determined, I’ll switch to Visual Studio Code for the actual system building.

Yes, I know, installing Python3 and Jupyter Notebooks is not really straightforward in its own right, and that presents a different kind of threshold, but once they’re installed, trying out scripts and script statements is much easier.

You can download an alpha version of Tightener from the Github repo:

https://github.com/zwettemaan/TightenerDocs

Version 0.0.8 has a link here:

https://github.com/zwettemaan/TightenerDocs/tree/main/Releases/Alpha

Other Stuff

Other things that are new to the 0.0.8 release: I’ve open-sourced and moved all of the supporting code for Tightener (scripts, plug-ins, and so on) into the TightenerDocs repo on Github, so you can now inspect or access a lot of the source code that makes Tightener ‘tick’.

For example, have a look here:

https://github.com/zwettemaan/TightenerDocs/tree/main/CurrentRelease/CommandLine/Scripts

https://github.com/zwettemaan/TightenerDocs/tree/main/CurrentRelease/SampleScripts

Next Steps

I’ll now turn my attention to the licensing module of Tightener. I want to make it easy for scripters to protect and monetize their work, without having to wrestle with complicated packaging and publishing rules, and Tightener will be instrumental in achieving that.

The basic idea is that Tightener will protect scripts by giving the developer multiple choices – for example: a developer could opt to never physically copt their script onto end-users computers. Tightener would only retrieve the script from the developer’s own server when the end-user computer is licensed to do so and the script would never be saved to disk, which would help in protecting the script against downloading and reverse engineering.

The Tightener licensing module will take care of ‘uniquenizing’ the end-user computer and checking licensing allowances before allowing scripts to run…

More info to come…