Jump to content

New Article on Writing Workflows


Recommended Posts

  • 2 weeks later...
  • 4 weeks later...

Hi, I am glad you all liked it. The next two are written and submitted. Waiting on the editor to publish them. As soon as they are, I will post here. 

 

Great to hear, we'll keep an eye out for the next articles too, as the first one was excellent :)

Link to comment
  • 2 weeks later...
  • 3 weeks later...
  • 1 month later...

It is faster. To open in a script, you are opening a shell, running the interpreter, then the script. In the box, Alfred simply runs the interpreter with the script script. It's one less level. Running it as a command line script always creates an extra program to run that is not necessary.

 

Also, many who read the articles are not command line savvy. Alfred workflows are for everyone, even those that are not great at the command line. Many are able to run script piecemeal from others examples even though they are not great at scripting. I have been able to teach others simple script programming using Alfred without them getting scared at the command line. Many do.

 

Now, with the Alfred debugger, creating a script file and running it in a command line has no advantage (as I showed in the article). I can get the same information from running the scripts in the box as I can running them on command line. The only advantage running in a script file is being able to use a different editor.

 

Also, if you run in the box, you can use the Alfred macro {query} directly. You do not have to process it as an input. This is actually safer way to run it as the user could inject shell scripts into your script doing the other approach. It is also a little less processing that needs to be done. I hate to wait, and with a system that is processing a lot of videos (I do a lot of video editing and processing), any help in speed is a great help to my productivity.

 

It is also a preference. I like other to easily see the code I write so that they can learn from it. It's the teacher in me, but not a good one.

 

Richard

Link to comment

It is faster. To open in a script, you are opening a shell, running the interpreter, then the script. In the box, Alfred simply runs the interpreter with the script script. It's one less level. Running it as a command line script always creates an extra program to run that is not necessary.

It takes ~1/200th of a second to make that extra call to the shell. I don't believe you really think that matters: your Calca ToolKit workflow makes the same call to PlistBuddy 5 times in 7 lines of code instead of caching the result.

One less level is not inherently good. Indeed, one more level is a very good thing if it makes the code easier to understand (which putting it in source code files does compared to embedding it in info.plist, where it's impossible to get an overview of all the code).

 

Also, many who read the articles are not command line savvy. Alfred workflows are for everyone, even those that are not great at the command line. Many are able to run script piecemeal from others examples even though they are not great at scripting. I have been able to teach others simple script programming using Alfred without them getting scared at the command line. Many do.

Nobody said they have to use the command line. They can still run the scripts in Alfred (and probably should, due to the differing execution environments).

 

And it's precisely such novices that can really use the syntax highlighting and linting help provided by a proper code editor (of which there are many excellent free ones).

 

Now, with the Alfred debugger, creating a script file and running it in a command line has no advantage (as I showed in the article). I can get the same information from running the scripts in the box as I can running them on command line. The only advantage running in a script file is being able to use a different editor.

Passing over the fact that Alfred's debugger didn't exist when you wrote the non-debugger tutorials, the debugger's utility is distinctly limited when debugging anything but trivial scripts in Script boxes: there aren't any line numbers, and it can be a nightmare trying to figure them out thanks to the wrapping in the tiny box.

And there are several other advantages to using a source code file over embedded code:

  • For more than trivial workflows, you can write a "proper" script that takes other options/arguments—a better option than spreading code all over the place.
  • You can import/require your scripts from others, so you don't have to copy-paste code all over the place and consequently have to fix any errors in multiple places. You can't import from a Script box.
  • Source control is more practical: it's hard to decipher diffs of code that's embedded (in an encoded format) within an XML file.
  • It's easier to maintain an overview because all your code is there in the workflow directory, not hidden away in info.plist.
  • It's easier to code: you can look at more than one file at the same time. You can run the workflow in Alfred without losing your place in the code. You can almost instantly find the line throwing the error reported in the debugger, instead of grubbing around in a tiny box full of grey text.
It's extremely bad form to be copy-pasting the same code into multiple scripts. It goes in a separate script that can be imported as required. Your "Calca ToolKit" workflow has 6 bash Run Scripts, each of which is 50% duplicate code. That code should be in an external file and included via source. That way, you could improve it to cache the results of the call to PlistBuddy, instead of calling it 5 times, in just one place instead of 6 separate Run Script Script boxes.

(BTW, the bottommost Run Script—the calca:figure one—is broken: you have the language set to bash but the code is PHP.)

 

Also, if you run in the box, you can use the Alfred macro {query} directly. You do not have to process it as an input. This is actually safer way to run it as the user could inject shell scripts into your script doing the other approach. It is also a little less processing that needs to be done. I hate to wait, and with a system that is processing a lot of videos (I do a lot of video editing and processing), any help in speed is a great help to my productivity.

It's not safer. Not in the slightest. Regardless of whether the the Script box uses bash (or any other available language) to call an external script with an argument or directly runs bash/PHP/Python/Ruby code entered in the Script box, they all use the {query} macro and the risk of code injection is exactly the same if you don't get the escaping right. Only the language of the injected code changes.

If you get escaping right, you're golden; if you don't, your code is vulnerable/broken.

The escaping in your Calca ToolKit is, for example, by turns broken and vulnerable to injection.

Your PHP Run Scripts escape nothing, yet wrap {query} in double quotes. That means any double quote passed in {query} will break out of the quotes, and anything that PHP would normally interpolate in double quotes ($var, `shell command`) will also be executed.

That is to say, it's vulnerable to exactly what you claim is only a problem with external scripts.

You should escape backslashes, dollars, double quotes and backquotes.

Your bash Run Scripts either also escape nothing (thus having the same vulnerability as your PHP ones) or escape everything, which will give you incorrect input (there's no need to escape spaces within double quotes). You should use exactly the same escaping options as above.

As noted above, your performance argument doesn't hold water. If it mattered to you that much, it would show in your code.

 

It is also a preference. I like other to easily see the code I write so that they can learn from it. It's the teacher in me, but not a good one.

Richard

Yeah, I like them to see the code, too. Which is another reason not to use the Script box.

It makes the code extremely hard to read compared to syntax-highlighted code in a proper editor or the nicely-highlighted code examples in your tutorials. It makes finding errors reported in the debugger much harder.

Using the Script box also makes it harder for a user to tinker with the code: there's no undo function in the Script box once you've saved your changes to run the script. So, they just broke the script, and now their only option is to replace the workflow, losing all of their changes, not just the last one that broke stuff, because there's no way to reverse just that one change, unless they can remember exactly what they changed and in which line (which, of course, isn't numbered).

Unless they had the sense to copy the code into an external editor…

The very first thing I do if I want to understand or modify someone's workflow is to change it so it runs external scripts, not code from a Script box.

I appreciate that using the Script box is the right way to go in the beginners' tutorial, but by the time you get to "advanced", the many advantages of using a proper code editor and actual scripts over the Script box should be mentioned.

Putting most of the code in external files is, for all the reasons given above, a better way to write a workflow.

Edited by deanishe
Link to comment
  • 1 month later...
Great articles. Thanks for taking the time to write these.

Why are you pasting the code into the Script boxes instead of using external scripts?

For the same reason 'Hello World' examples aren't written using IDEs, closures and recursion:

Keeping it as simple means the user can get something up and running quickly, which encourages him to press on with something more complicated.

It keeps the focus on Alfred, not on introducing extras like RubyMine or PyCharm or other tools which are distracting for the learner.

Edited by MuppetGate
Link to comment

For the same reason 'Hello World' examples aren't written using IDEs, closures and recursion:

Keeping it as simple means the user can get something up and running quickly, which encourages him to press on with something more complicated.

It keeps the focus on Alfred, not on introducing extras like RubyMine or PyCharm or other tools which are distracting for the learner.

A noble goal—and the right method—for Workflow 101-type tutorials, but when we're talking about a self-confessed advanced tutorial with scripts that run to hundreds of lines of code, writing such scripts in the Script box isn't "keeping it simple" any more.

I don't know where you got the idea from I was recommending an IDE, but you're doing the readers a disservice by implying that the Script box is the right place to write a 300+ line script.

It isn't. Any basic programmer's editor with syntax highlighting and line numbers is a much better place for that.

The workflow tutorial doesn't need to be an editor tutorial, but it makes sense to point out that if you're writing such long scripts, a programmer's editor makes that one heck of a lot easier, even if when you're finished, you copy-paste the code into the Script box.

Sure, mentioning an editor adds some complexity to the discussion, but not doing so makes writing workflows appear harder than it really is. Trying to debug a bunch of grey text in a box with no line numbers is way harder than in a real editor, and the run-edit-run cycle in Alfred is slower and more complex, and has significant disadvantages compared to using Terminal.

Link to comment

Nothing has 300+ lines in a workflow box. That would be unwieldy for sure. The only thing that long is a go program for TimeKeeper that has to be compiled. The workflow boxes in the workflow just have one liners! The longest one in the Advanced tutorial is 50 lines, which is getting a little large for that editing medium.

Link to comment

I've just had a look at the "Alfred Workflows for Advanced Users" tutorial, and there's a 142-line PHP script to be pasted in a Run Script box, so let's split the difference.

Might just be that I make an extremely high number of errors when I'm coding, but the thought of writing anything over, say, a dozen lines in that Script box makes my eye twitch a little.

Completely tangentially, was there any particular reason to use Go for the workflow, and would you recommend it? Also, do you have any tips regarding getting into Go? It's an intriguing language, and I think I'd like to give it a try.

Link to comment

Nothing has 300+ lines in a workflow box. That would be unwieldy for sure. The only thing that long is a go program for TimeKeeper that has to be compiled. The workflow boxes in the workflow just have one liners! The longest one in the Advanced tutorial is 50 lines, which is getting a little large for that editing medium.

 

Maybe it would be nice to write about how to run a script instead of typing it directly in Alfred.

 

As soon as I learned how to just run an AppleScript, instead of typing it, that made a huge difference specially because it is a lot easier to read a colored code than a plain text one.

 

Maybe you could show the both worlds. :)

Link to comment

Hi,

 

To be honest, I often code my base functionality totally stand alone, then I migrate it to a workflow. Therefore, using the boxes is not that hard.

 

Also, I used go in the Alfred TimeKeeper as a learning example to teach myself go. Also, since loading the php interpreter is somewhat slow on my Mac Mini (not enough memory for all the work I give it), the go solution ran faster. Especially when calculating a week or month of timesheets!

 

I am writing an article for publication on setting up a go development environment on the Mac and teaching how to use the language some. It is not hard to learn and the easiest way to load it on a Mac is by HomeBrew "brew install go". I give a very brief expanation in the Alfred Timekeeper article, but the new article will go into more detail.

 

Richard

Link to comment
  • 2 weeks later...

Thanks. Didn't realise it was so easy. I'll give it a go.

 

Such a bad pun.

 

Although, yes, the PHP interpreter, when invoked by Alfred, does seem to take more time even on my Macbook Pro (which does have enough processing power). I'm not quite sure why this is because when I run the same scripts via the command line, they go faster, and other interpreters (python, ruby...) don't have the same sort of lag.

 

The slowness was the main reason why I rewrote my caffeinate workflow so that it operated entirely in Bash.

 

I've gone to using PHP in workflows only when I have to do something more intense than shell scripting should ever really handle. I'd go to a more appropriate language (read: either Python or Ruby) if I actually had a reasonable level of proficiency with one. So, Dean, that's why I keep doing the crazy bash stuff.

Link to comment

No pun intended…

I think the PHP interpreter is just super slow to load. I suspect it may be because it's so monolithic. With Ruby/Python, most of the functionality is in external (standard) libraries that have to be explicitly imported. I don't think it makes much difference if it's already in memory, but from a cold start…

FWIW, I've spent the last few days messing around with bash/zsh. Slowly getting the hang of it, but man is it weird. Took me a couple of hours to figure this out :(

At any rate, shell is way slower than PHP/Python/Ruby for any heavy lifting, but it starts super fast.

Edited by deanishe
Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...