Writing Alfred Workflows in Go

[nikivi]

Recently I have been really enjoying programming workflows in Go using @deanishe incredible AwGo library. 

 

So I decided to write an article on how anyone can start building things with Go by going through building a complete and working workflow from scratch.

 

You can read the article here.

 

I would really love to hear your thoughts on it. ?

 

It is quite long in hindsight but I wanted to be as clear as I can be so anyone can follow along. I also leave some personal tips of my own that I use to help me develop workflows faster.

[vitor]

I’ve only skimmed the article, so I have only a few tips:

• Avoid things users can’t simply copy and paste even on your own setup. Don’t do export GOPATH=/Users/nikivi/go; do export GOPATH="${HOME}/go".
• Be consistent. Don’t say /Users/nikivi on one line and ~ on the next. That’s confusing to users who don’t already have a solid grasp of ~ being their home directory. Even worse when ~ itself is volatile in meaning (quote it and it suddenly becomes literal).
• I recommend you do ${} instead of just $. It’s clearer for when you need it.
• Get in the habit of quoting everything you can, when shell scripting. Not doing so will come back to bite you fast.
• Don’t waste too much time telling us about your preferred editor and your setup. That’s the subject for another article. But especially don’t waste time talking about plugins that are irrelevant to the tutorial.
  

 

Final tip: use ShelCheck. There’s a VSCode plugin for it.

[deanishe]

1 hour ago, vitor said:

Don’t do export GOPATH=/Users/nikivi/go; do export GOPATH="${HOME}/go"

 

The best value, imo, is export GOPATH=$HOME. That way, when you install a command (as opposed to a library) with go get ..., it's installed in ~/bin.

 

8 hours ago, nikivi said:

I would really love to hear your thoughts on it

 

All of what @vitor said. Plus:

 

You link to https://github.com/deanishe/awgo for the library, but install it from git.deanishe.net/deanishe/awgo. Install it from github.com/deanishe/awgo, too. It's a mirror, and GitHub's servers are way more reliable than my cheap-ass VPS.

 

Quote

export GOPATH=/Users/nikivi/go

And then my actual Go projects go under

~/go/src/github.com/nikitavoloboev

For you this might be different.

 

Might be different? Must be different.

 

Quote

Semantic versioning is preferred.

 

No, it's required. AwGo is a bit more flexible in what it accepts (minor and patch versions are optional), but it won't work if you call your releases "dave dee", "dozy", "beaky", "mick" and "tich".

 

Quote

echo -n ${URL/test/$1}

 

This is broken in two different ways.

 

Firstly, it will go wrong if "test" appears somewhere else in the URL, such as if someone would like to search for product reviews on https://www.test.de.

 

Secondly, you aren't URL encoding the query. It won't work if a query contains "&", for example.

 

Workflow code

 

There's no reason at all to read the CSV into a map. All you do with the map is immediately unpack it into pairs again. There's also no reason for the links variable, as the only thing you do with it is pass it to the range call. Might as well just use ... range parseCSV() {....

 

Finally, the rest of the code is taken directly from one of my AwGo example workflows, only you removed my copyright notice (in direct violation of the licence).

 

I do not appreciate your passing off my code as your own.

 

Either link to where you got the "starter code" from, or put my copyright back into my code.

 

[nikivi]

3 hours ago, vitor said:

I recommend you do ${} instead of just $. It’s clearer for when you need it.

I don't understand what are you referring too. Are you referring to the ./alfred-web-searches search "$1" call or echo -n ${URL/tester/$1} ?

 

And I have changed things as you mentioned. Thank you a lot for your comments. Also I decided to mention VS Code and plugins I use in case other people will find interest in that. And the VS Code task for `alfred build` is seriously awesome.

 

Thank you @deanishe. I have changed everything and added a link to where the starter code was taken from. Sorry for not respecting your license.

Aside from the critical comments which I do appreciate, I thought there'd be at least one positive one but oh well.

 

 

 

 

Edited September 15, 2017 by nikivi

[vitor]

1 hour ago, deanishe said:

The best value, imo, is export GOPATH=$HOME. That way, when you install a command (as opposed to a library) with go get ..., it's installed in ~/bin.

 

To be clear, what I meant to be the takeaway was “don’t do /Users/username; do ${HOME}”.

 

1 hour ago, nikivi said:

I don't understand what are you referring too. Are you referring to

 

Everywhere. If you’d do $var, do instead ${var}. As a bonus tip, instead of `command`, do $(command).

 

1 hour ago, nikivi said:

I decided to mention VS Code and plugins I use in case other people will find interest in that.

 

And in the process you’re making an already long (by your own admission) article even longer. Don’t stray — if you think something is noteworthy, write another post and link to it. The longer your tutorial is, the less likely it is someone else will read it. This is particularly egregious when you mention the vim plugin, which not only is completely irrelevant for the article, it’s irrelevant for the majority of users (especially newbies).

 

1 hour ago, nikivi said:

I have changed everything and added a link to where the starter code was taken from. Sorry for not respecting your license.

 

Choose a license is a good resource to learn about the rights and obligations of each popular open-source license. Pretty much every license — unless it’s public domain — requires that you credit the original author. But crediting is always appreciated, and deliberately taking it away is incredibly frowned upon (and, well, illegal; that’s the point). Even on public domain licenses — the most permissive of all — you can’t simply claim the code as your own.

 

1 hour ago, nikivi said:

Aside from the critical comments which I do appreciate, I thought there'd be at least one positive one but oh well.

 

There’s a common saying in graphic design: “good typography is invisible” (sometimes with the addendum “bad typography is everywhere”). Same is true of good/bad UI and everything whose goal is to solve a problem for a user.

People rarely notice when everything goes smoothly; they notice when things are frustrating. That’s why (constructive) criticism is both easier and more useful. These mistakes were what jumped first. Hopefully, with each critic and fix your article will become better and better, until at one point it’ll be so polished the only thing left to comment is “I enjoyed reading this, and it was useful to me”.

For something to be so good you notice how good it is, it needs to be so good that you understand why everything else is bad. These things are so rare and good, it’s not even (only) the content that teaches you, but the format.

[deanishe]

Thanks for changing the links to GitHub, but you missed one near the top in the "Creating workflows with Go" section: it still says go get git.deanishe.net/deanishe/awgo. Could you change that to go get github.com/deanishe/awgo?

Now I'm happy with the library, GitHub will become the official repo, and git.deanishe.net will just be a mirror.

 

[nikivi]

10 minutes ago, deanishe said:

Could you change that to go get github.com/deanishe/awgo

 

It is changed. ? 

[nikivi]

I am curious, what is the advantage of self hosting your repositories? 

[deanishe]

2 hours ago, nikivi said:

what is the advantage of self hosting your repositories?

 

Privacy. Private repos are very expensive on GitHub, and as they say, "if you aren't paying for a service, you're the product not the customer." So I prefer to self-host my personal/private stuff where reasonable.

 

The AwGo repo was only public because you needed it to re-compile the Safari Assistant workflow I gave you.

 

Which I should probably get around to finishing at some point, tbh.

[nikivi]

 

35 minutes ago, deanishe said:

Which I should probably get around to finishing at some point, tbh.

 

What do you wish to add there? I think it is perfect as it is although I only use it to search through current tabs and my safari bookmarks.

 

I wanted to use it to search through my current reading list items but for that I need a quick way to delete reading list items from Alfred too. Perhaps with a modifier key press on reading list search. That would be quite awesome. I also wanted to add a feature where opening a reading list item from Alfred will open the URL and instantly delete it from my reading list (as I will be reading it when I open it).

 

Also big thank you for sharing it with me. Not really sure why you don't host it on GitHub, I think it would get a lot more love there as now it is practically invisible to all.

 

I wonder how many other awesome workflows you or @vitor don't share because you think they only solve your problem or are too personal for sharing. I try to share all the workflows I make, even really simple ones that I use myself. But then I also share my more private workflows too like alfred-my-mind. 

Edited September 15, 2017 by nikivi

[deanishe]

On 15/09/2017 at 8:28 PM, nikivi said:

Not really sure why you don't host it on GitHub

 

Because the workflow is currently in the "one to throw away" prototype stage I mentioned yesterday. It works just great for me, but I don't want other people to see it.

 

In this case, there isn't really a whole lot I'd change code-wise, but the icons are too embarrassingly poor to release, and I don't really care enough to replace them.

 

On 15/09/2017 at 8:28 PM, nikivi said:

I need a quick way to delete reading list items

 

There is no Reading List API. Forget it.

 

On 15/09/2017 at 8:28 PM, nikivi said:

they only solve your problem or are too personal for sharing

 

I thought I made that pretty clear yesterday with the "make one to throw away" principle. It has (theoretically) nothing to do with being unique to my problems or being personal.

 

 It's because there's a big difference between "dodgy prototype that mostly does what I want if I'm careful"  and "polished product that does exactly what it says on the tin".

 

It's the 90-90 rule. Taking your web search workflow as an example: it works just fine for you, but it has obvious and significant flaws that mean there will be issues if it's widely used:

• It breaks if a URL has the string "test" in it anywhere but the query placeholder
• It breaks if the user query contains characters that are meaningful in a URL (e.g. "&") because you don't URL-encode the query
• Any update overwrites user additions to the CSV file

Fixing these obvious bugs to ensure the workflow works properly for everyone (i.e. is ready for release) requires at least doubling the amount of code.

 

And frankly I'm often not prepared to put in the second 90% to make a workflow ready for public release because I can live with the first 90%.

 

Edited September 16, 2017 by deanishe
Who's Tim?