stex.codes

Cypress on Rails 2: Electric Boogaloo

Wed, 09 Nov 2022 00:00:00 +0100

Today I held an updated version of my Cypress on Rails talk at the Hamburg Ruby UserGroup.

The talk covers an introduction to Cypress, how to communicate with a Rails server from Cypress to e.g. generate test data with factory_bot and a way to run Cypress tests in CI with spinning up the Rails application as a service in Gitlab CI or Github Actions.

We had a great discussion about responsibility for e2e tests (is it the backend team? is it the frontend team? why not both?) and whether e2e tests are needed at all when backend/frontend specific tests exist.

The slides can be found over at Github together with a demo project that contains

a Rails 7 application with Rodauth and Turbo Frames and ActionText usage
a small Cypress test suite
Dockerfiles for both the application and Cypress
a Github Actions configuration to build the Docker images and run the Cypress tests with the Rails Application as Service container

Thanks to everyone who attended the meetup, it was great talking to you!

All image were generated by DALL-E, there are a few more in the pitch folder that were not used if you’re interested 🙂

Importing an external Feed into Jekyll

Mon, 24 May 2021 22:31:08 +0200

A simple script approach to import posts from an external feed into a Jekyll blog using HEY World’s atom feed as an example. Contains some special workarounds to fix the feed’s contents, but should work with every well-formed RSS feed out there with a little customisation.

As seen in my test post, I tried HEY World, a new blogging service by Basecamp that works by sending an email that’s then published to the web. While it’s not the most powerful blogging tool, it’s definitely one that’s easy to use.

To keep everything in one place and enjoy basic functionality like syntax highlighting even for the posts made in HEY World, I decided to import the feed they provide into my homepage and fix a few things on the way.
I am aware that this might lead to some SEO issues in case Google considers this to be double content, but I’ll cross that bridge when I get there.

Edit: Of course I noticed a few problems just after writing this post, e.g. that tags were no longer extracted in all cases. I made my script more fail-safe and updated the parts below. Here’s the post on HEY World to see the script in action.

Here’s the latest version of the script, I’ll go into some of the problems I ran into that are HEY World specific though. Parsing the feed was done using feedjira which is an amazingly easy to use library for all kinds of XML feeds, so I’ll skip this part.

Converting the Post Content

Trix, the WYSIWYG editor used by Rails’ Action Text and consequently by HEY, produces HTML which is used as entry content in the atom feed. It looks like they just insert the default trix layout which still contains e.g. a surrounding div.trix-content and a lot of formatting with a few… interesting choices.

To make this as easy for me as possible, I decided to convert the HTML I get from HEY into markdown and get rid of all HTML that’s not inside pre tags. There’s a great gem called reverse_markdown out there that I already used in the past and in a perfect world, all I’d have to do was a one-liner on the content:

ReverseMarkdown.convert(content, github_flavored: true, unknown_tags: :bypass)

However, I had to work around a few of Trix’s behaviours as well as get some additional information out of the post beforehand:

1. Trix and its Lack of Paragraphs

Other editors usually produce a <p> tag for a double newline, Trix goes the literal way and inserts two <br> tags. Not wrong, but a bit unexpected and a bit difficult when it comes to markdown conversion.

Let’s take a look at the reverse_markdown conversion rule for <br> tags:

class Br < Base
  def convert(node, state = {})
    " \n"
  end
end

As you can see, it inserts 2 spaces and a newline which is “stay in the same paragraph, but start a new line” in markdown. So, what happens with Trix’s <br><br> pattern?

"hello<br><br>world".to_markdown
=> "hello \n \nworld"

While kramdown, the default markdown parser in Jekyll, ultimately converts this into paragraphs as it ignores the spaces at the end of the lines, Jekyll seems to have problems generating a post teaser out of this. By default, Jekyll takes the first paragraphs of a post for the index page tiles (depending on their length), but was unable to do so with the double <br> tags:

It looks like everything up to the code block was interpreted as a single paragraph (which is correct as explained above). To work around this with as little work as possible, I decided to introduce an own pseudo HTML tag as replacement for the double <br>s that I could translate to markdown myself:

class DoubleBr < Base
  def convert(*)
    "\n\n"
  end
end

"hello<doublebr />world".to_markdown
#=> "hello\n\nworld"

2. Headings

While the HEY editor provides a “Heading” style, it seems to only be able to produce H1 tags which is probably not the semantically best way to go on a website.

I therefore decided to add an own markdown converter again which simply translates H1 into ##. Works well and since I know that the input will never contain any other headings, this shouldn’t cause problems in the future.

3. Producing proper Code Blocks

While Trix has a basic code block functionality, it doesn’t support syntax highlighting, but introduces a few formatting tags like <em> into the code.

What it doesn’t do is inserting a proper <code> tag inside its <pre>s which would be the semantically correct way to display a block of code. I understand that they intended to simply provide a “we won’t touch whitespace here” functionality into their editor, but this behaviour made it harder to further process it.

First, I had to get rid of the extra formatting HTML that’s inserted into the code block. Luckily, the actual code contains twice encoded HTML entities while the formatting tags were only encoded once for the feed:

# A comment
class << self

&lt;em&gt;
  A comment
&lt;/em&gt;

class &amp;lt;&amp;lt; self

This way, it’s possible to decode it once and let Nokogiri remove all actual HTML tags while keeping the content intact. The easiest way to achieve this was to use #content on the <pre> itself which returns the pure text content of said node.

Additionally, I needed to alter two things in the HTML I got from HEY World:

Add a code tag so the markdown converter understands that this is in fact code
Extract the language to be highlighted

To achieve 2), I added e.g. # lang: ruby to the bottom of code blocks in the HEY World editor and extract these lines in my script.

The resulting part of the script was pretty easy in the end:

xml.css("pre").each do |pre|
  code = Nokogiri::XML::Node.new("code", xml)

  # Search for a "lang: something" line at the end of the pre.
  # If there is one, use it for syntax highlighting
  if (match = pre.content.lines.last.match(/lang: (\w+)/))
    code["lang"] = match[1]
    code.content = pre.content.lines[0...-1].join
  end

  pre.content = nil
  code.parent = pre
end

I had to extend reverse_markdown again with an own converter for <code> though as by default it doesn’t take the lang attribute into account:

class TrixPre < Pre
  def language(node)
    super.presence || node.at_css("code")["lang"]
  end
end

4. Assigning Tags to Posts

Since HEY World itself doesn’t support tags, I used the same approach as for the code block highlighting language and search for a tag line (“#tag1 #tag2”) at the end of the post. I originally did this before turning the post into markdown, but the HTML I got wasn’t consistent enough, so I now treat the last markdown line as possible tags.

def tags
  @tags ||= begin
    tag_line = markdown_content.lines.last

    if tag_line.match?(/^((#\w+) ?)+$/)
      tag_line.scan(/#(\w+)/).flatten
    else
      []
    end
  end
end

If a tag line exists in the markdown content, it is removed before writing it to disk.

Front Matter

The front matter for the Jekyll post (the YAML part at the beginning that contains the post’s title and other information) can be easily generated now that all relevant information has been extracted from the RSS entry:

<entry>
  <id>tag:world.hey.com,2005:World::Post/11280</id>
  <published>2021-05-14T19:48:10Z</published>
  <updated>2021-05-23T15:15:38Z</updated>
  <title>Testing HEY world</title>
...
</entry>

def front_matter
  {
    date: item.published.localtime.to_s,
    last_modified_at: item.updated.localtime.to_s,
    layout: "post",
    tags: tags,
    title: item.title
  }.transform_keys(&:to_s)
end

The important part here is to make sure that all Hash keys are strings, otherwise, a YAML dump would generate Symbols which Jekyll doesn’t expect.

File Generation

To keep this as simple as possible, I decided to reload all posts from the external feed every time I run the script, deleting every post that might have already been there. In case of stex.codes, this is done when building its docker container for deployment in CI.

I tried using an own collection (= an own folder) in Jekyll for these posts, but those behave slightly different from normal posts and require a bit more configuration to be included in the main feed. Therefore, I decided to simply add a distinct pattern to their file names while still following Jekyll’s naming conventions:

This allows me to remove all possibly existing posts before loading the feed again:

FileUtils.rm_rf(POSTS_DIR.join("*--hey--*"))

Re-Building the Website on Feed Changes

Since changes to HEY World should be synced over to my blog, I wrote a small script / docker image to watch for changes and trigger a docker hub build. I didn’t find a better solution than polling yet, unfortunately.

Conclusion

Well, it works. I’ll have to adjust a few styles on the website to e.g. prohibit smaller images being displayed in full width, but creating a blog post through my email client is definitely a lot easier than having to code it. And since I’m still able to create more complex posts directly in Jekyll, I’ll go with this for all simpler topics for now.

Testing HEY world

Fri, 14 May 2021 21:48:10 +0200

Test Post for writing short posts in HEY World and importing them into Jekyll (with syntax highlighting and tags). Works fine (up to a certain extend) without cluttering the output in case someone would really subscribe to this via email.

I set up stex.codes a while back in an attempt to have an online CV, but also to start blogging about technical topics regularly again and chose Jekyll since Wordpress seems a bit too big and bloated for what I needed and I liked the idea of having static content.

But when publishing a 2 paragraph long post becomes a project that takes an hour, I often don’t even want to start. Same thing as hanging your guitar on the wall ready to play rather than having to get it out of its case every time. It just doesn’t work. Therefore, I’ll give HEY World a shot. Say what you want about Basecamp in its current state of -1/3 employees, but they still manage to build bridges between “old” technology and the modern web.

(Beaver test image above)

Not sure if it will be enough for my needs when it comes to e.g. code embeds, but it’s worth a try. Maybe I’ll find a good way to display a mix of Jekyll and HEY World posts on my blog through the RSS feed, that might be the perfect solution.

Quick test of syntax highlighting (or probably the lack of it):

require "yaml"

module Neph
  #
  # Acts as a registry of everything read from the local neph.yml file.
  # All other classes should only act with this class instead of processing the file on their own.
  #
  class Config
    using Neph::Refinements::Hash

    class << self
      def exists?
        File.exist?(config_path)
      end

      def environments
        @environments ||= config_yaml["environments"].map do |name, options|
          Environment.new(name, **options.symbolize_keys)
        end
      end

      def task(name)
        tasks.find { |t| t.name == name.to_s }
      end

      def tasks
        @tasks ||= config_yaml["tasks"].map do |task_name, options|
          Task.new(task_name, **options.symbolize_keys)
        end
      end

      private

      def config_path
        File.expand_path("neph.yml", Dir.pwd)
      end

      def config_yaml
        Psych.safe_load(File.read(config_path))
      end
    end
  end
end

<!-- HTML Comment -->
<!doctype html>
<html lang="en">
  <body>
   <em>HTML</em>
   <strong>Test!</strong>
   <div class="a b c">Classes?</div>
  </body>
</html>

Edit: OK, no syntax highlighting - but that’s ok. I’ll experiment a bit with it.
Edit 2: Got syntax highlighting working in Jekyll at least with a custom magic comment at the bottom of the code block 🙂
Edit 3: Just saw that all empty lines are removed from code blocks now, that should probably be changed for readability 🙈
Edit 4: The removal of empty lines was actually done by the HTML prettification I had in place during build. Removed it now as it did more harm than good.

HEY World post is here btw: https://world.hey.com/stex/testing-hey-world-2bfcf2c0

Cypress on Rails (Talk)

Wed, 09 Dec 2020 00:00:00 +0100

A talk about how to replace Capybara with cypress.io for E2E tests while maintaining all the nice features like using FactoryBot to generate test data on-the-fly. Held on the December meeting of the Hamburg Ruby UserGroup.

As this is an interesting topic, I’ll probably write a proper blog post about it in the future.
Until then, I’ll provide my slides and the demo application I created for the talk here. It contains both capybara and cypress examples and should give a good introduction on how to start using cypress with Rails.

Demo Application

Slides

Adding Comments to a Jekyll Blog

Thu, 03 Sep 2020 18:00:00 +0200

I’m pretty happy with Jekyll and the static HTML pages it creates, but one thing every Wordpress blog features is clearly missing: a comment section. Yes, it mostly collects either dust or bitcoin scams these days, but there’s still the chance someone actually has a question or remark about the thing I wrote.

While I could have built a simple service myself, I’d then have to take care of e.g. spam filtering and generally maintaining it, so I decided to use something existing. Of course Disqus came to mind, but if I’d include that into my page, I could as well add GA and a facebook pixel for good measure.

Surely I wasn’t the first one with this problem, so I searched for a bit. There were a lot of possible solutions (many of them no longer maintained), but two of them really caught my eye: Staticman and utterances.

Both of them are open source and use Github as “database” for comments, but in very different ways. Let’s take a look:

Staticman

Staticman uses Github pull requests to add new comments as actual files to the homepage repo. You just have to point your comment form to the Staticman API, add the staticmanapp to your repo (so it can create the PRs) and you’re good to go.

Every time a user submits the comment form, a new PR is created and - depending on your configuration - automatically merged or marked for review. Each PR contains a simple YAML file with the form data the user submitted which can easily be processed by Jekyll during compilation (see here for an example repo).

Staticman can be self-hosted and comes with a lot of additional features like Akismet integration for spam checking or Mailgun for email notifications about new comments, but it’s its main feature that made me not choose it: It automatically alters my repository.

I like the idea of having my whole page as static files, including comments, but to be honest: As long as the comments are stored in a database outside my page, I can still move it to a different server without losing anything. And I really don’t like the idea of a service pushing code to my repository with whatever a user writes into a comments form (even if I review them before).

This brings us to the second point I’m not really happy about: Staticman saves exactly what the user entered into the form in the repo for me to render in my layout. While this allows for a lot of customization (the demo page uses it for movie reviews), I still have to add the convenience for the user myself. Also, I’d have to make sure all user content is properly sanitized.

Short version:

Pros

Users don’t need a Github account to comment
Integration with Akismet for spam filtering
Comments can contain custom fields like a star score (0-5)

Cons

Adds user generated content to my repo (I know, that’s the gimmick, but still…)
Rendering the comments in Jekyll has to be built, including proper sanitizing

utterances

utterances uses Github issues to store user comments. It does so by sending XHR requests to its API (also open source) which communicates with the Github API behind the scenes.

When the first user creates a comment on a post, a new issue is automatically created on Github. For each additional comment, the same issue is re-used by adding a comment to its thread. Their index page issue is probably the best example for how this works.

Compared to Staticman, the installation is pretty easy. You just have to insert a <script> tag into your page with some configuration options and you’re good to go.

The script automatically fetches all existing comments and inserts them into the page in Github’s own style, making a user feel pretty much at home. It also inserts a form to add more comments which pretty much behaves like its equivalent on Github, minus the formatting toolbar. It does have full GFM support though.

Using the Github API like this leads to two requirements for a user to comment:

1. They need a Github account to comment (since they are basically commenting on a Github issue)

I honestly see this as a positive point. I’ll mostly write about tech stuff and most of the people who might end up here will have a Github account. This should also act as a Spam filter to some degree as at least the drive by bots won’t be able to comment.

2. They have to allow the utterances Github app to “act on their behalf” to post the comment.

Allowing a Github application to access your account is always a tricky decision. Since their API is also open source, I could host it myself, but I think that’s even worse. While I’d know for sure that it’s harmless, people would have to give access to a “stex.codes” application… I think it’s easier to go with the 3k stars one on Github than with my own installation.

Also, Github makes it pretty clear that a comment wasn’t made by the user directly:

Alternatively, the user can of course add the comment directly on Github, making having an account there the only requirement.

Short version:

Pros

Easy setup through a <script> tag
It feels like writing a Github comment and looks like a Github comment (and is a Github comment).
It requires a Github account to comment.

Cons

It requires a Github account to comment.
The user has to give the utteranc.es Github app the permission to “act on their behalf”

Conclusion

As you can see on this page, I went with utterances.
Since both the library and Github application are open source, I’m fine with using it myself. It might lead to fewer people commenting (if someone makes it here anyway that is), but I like the issue flow a lot more than Staticman’s PR approach. Both are very interesting from a technical standpoint though.

Regarding placement and styling, I went with the default Github dark mode for now, but will change that to another white container below the post. It will be easier to read.

Update (06.09.2020/18.01.2020)

utterances by default places the content of the <title> attribute inside its issue names and uses it to find the matching issue for a post.
I changed this post’s title and sure enough the comments were gone.

To work around this, I decided to use an own term to put into the issue per page and use its URL as fallback. This way, I have a little more freedom to change posts after publishing them.

{% unless page.hide_comments %}
  <script src="https://utteranc.es/client.js"
          repo="stex/stex.codes"
          issue-term="{% if page.comment_issue_term %}{{ page.comment_issue_term }}{% else %}url{% endif %}"
          label="comment"
          theme="github-dark"
          crossorigin="anonymous"
          async
  ></script>
{% endunless %}

This allows setting the issue term in the posts front matter as comment_issue_term: Something or hide comments completely by providing hide_comments: true.

Building an Alfred Workflow to export Attachments from Evernote

Wed, 02 Sep 2020 19:00:00 +0200

This post is about building an Alfred workflow that allows exporting all image attachments of the currently opened Evernote note as PDF.

Update (2021-02-03)

Judging by a Tweet from the Evernote Support, it looks like they are planning to get applescript support back in the future.

Really hoping they do, currently, there doesn’t seem to be an easy, non-API solution to automate anything.

Update (2021-01-18)

I updated the workflow for the new Evernote electron app.

Since Evernote supports neither Applescript nor x-callback-url now, I had to work around it Selenium style and click on each UI element from Applescript. It works, but doesn’t look too elegant.

The new workflow can be found here: Source Code on Github

Update (2020-10-09)

With the latest evernote update to electron, it looks like applescript support was dropped completely, therefore, this workflow isn’t working any more.

Since I still need a way to export attachments, I’ll look into using the Evernote API some time, but that won’t be as accessible to other users since you need an API key - or trust a random dude’s application to connect to your Evernote account.

I’ll update this post again in case I find another solution.

I recently started using Evernote for document management purposes. I’m not the biggest fan of its note taking capabilities, but the convenience of taking a picture with the mobile app and having it optimized and indexed as a document is pretty amazing.

However, I still wanted to be able to export the documents I scanned as PDFs which proofed a bit more difficult than expected: Evernote saves its scanned documents as one PNG image per page and attaches each one to the note.

So, why not just print to PDF?

My first idea was indeed to use the print dialog and generate a PDF out of it. However, Evernote adds some pretty substancial margin around the actual image, probably because of lower dpi:

Actual Image

Print to PDF output

As you can see, I would get a tiny image inside an A4 PDF, not exactly what I was looking for.

Since I didn’t find a proper solution for this problem on the web, I decided to build one myself.

The Applescript Part

Luckily, Evernote has quite extensive Applescript support by now. It doesn’t necessarily make it easy to achieve exactly what you’re trying to do, but it at least gives you a lot of information.

If you are like me and only visit Applescript when you absolutely have to, here’s something I learned: Most applications with Applescript support come with a dictionary of the things they support. To view it, open the Script Editor, choose File -> Open Dictionary and select the application you’d like to explore.

I’ll go through the steps I took to get to my final solution and try to show off a few problems I encountered and had to work around.

Getting the Current Note’s Data

Assuming that the user didn’t select a bunch of notes at once and just opened one by clicking on it, selection is a 1 element list that contains exactly this note object.

tell application "Evernote"
  set notesList to selection
  set oNote to item 1 of notesList

  tell oNote
    ...
  end tell
end tell

Extracting the Attachments

I searched the Evernote Applescript dictionary and found that each note has a list of Attachments with each of them responding to a write method to extract them to the hard disk. Couldn’t be so difficult then, right?

First, I had to find a suitable filename for the images when saving them to disk. And I needed them in a certain order to pass them into convert to create a PDF out of them.

The Evernote dictionary gave me a few options here:

“filename (text or missing value, r/o) : The attachment’s original filename, if available.”
“hash (text, r/o) : The attachment’s hash (used to identify the attachment in the note’s ENML).”

Since filename was not a guaranteed value neither it nor hash had anything to do with the order of the attachments inside the note, I went with building an own filename using a for-loop’s index variable:

repeat with idx from 1 to count of attachments
  set oAttachment to item idx of attachments

  write oAttachment to "/Users/stex/Downloads/" & idx & ".png"
end repeat

Looks like it should work, but doesn’t. Instead, I was presented with my first error:

error “Evernote got an error: “31EB6536-288F-4A4D-8ADA-1D455165115E.png” couldn’t be copied because you don’t have permission to access “Downloads”.” number 513

What happened here? With the more recent versions of macOS, Apple followed what they already had in place for iOS applications: Each app runs inside its own little file system sandbox and you have to explicitly give it access to folders outside of it. Since I didn’t find a way to give Evernote access to a certain folder from inside Applescript, I chose an output folder instead that I knew Evernote had write access to - its own sandbox.

set evernoteDataFolder to (system attribute "HOME") & "/Library/Containers/com.evernote.Evernote/Data/"

repeat with idx from 1 to count of attachments
  set oAttachment to item idx of attachments

  write oAttachment to evernoteDataFolder & idx & ".png"
end repeat

That got rid of the permission error, but reveiled something else. I was absolutely convinced that the list of attachments Evernote gave me inside Applescript would follow the order of attachments inside the note. But no, it follows the random filenames Evernote assigned them leaving me with no guaranteed order at all.

As far as I could see, there was no way to get the actual attachment order from Evernote, so how to proceed?

Using the Note Content to get the Attachment Order

Luckily, Evernote gives us access to the note’s content both in HTML and ENML format. While the former is not of interest here, the latter is basically an XML file Evernote uses internally.

Let’s take a look at such a file:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE en-note SYSTEM "http://xml.evernote.com/pub/enml2.dtd">
<en-note>
  <div>
    <en-media hash="270493a2b1a89ceeb2528f1c0e97d1f5" title="Attachment" width="1979" type="image/png"/>
    <br/>
  </div>
  <div>
    <en-media hash="0cb8d04258fdbfe33739b2529d81fdb5" title="Attachment" width="1440" type="image/png"/>
  </div>
  <div>
    <br/>
  </div>
</en-note>

As you can see, it contains an en-media tag for each attachment in the note with, including a hash attribute which corresponds to the hash property available for each note object inside Applescript.

At this point I decided that Applescript wasn’t enough to solve my problem completely, but I still had to use it to extract all the necessary information from Evernote and make it available to another script. Namely, I needed the following data outside of Applescript:

The note’s ENML content
The attachment files saved with their hash as filenames

Both could easily be achieved:

tell oNote
  set noteContent to ENML content
  do shell script "echo '" & noteContent & "' > '" & evernoteDataFolder & "note.xml'"

  repeat with oAttachment in attachments
    set noteHash to hash of oAttachment
    write oAttachment to evernoteDataFolder & noteHash & ".png"
  end repeat
end tell

Luckily, Applescript gives us access to shell scripting with do shell script. This makes saving a string to a file by redirecting an echo output easy enough - from what I found on the internet, this seems to be the solution used by most developers.

After cleaning up a bit and putting the exported files into a subfolder to not pollute Evernote’s sandbox too much, I ended up with the following code. Please note that I return notePath as script result which points to the folder I saved all the files in. We’ll need this path in the next step.

# A helper function to create the temp directory to place our files in
on createNoteDir(path)
  do shell script "rm -rf '" & path & "'"
  do shell script "mkdir -p '" & path & "'"
end createNoteDir

tell application "Evernote"
  set notesList to selection
  set oNote to item 1 of notesList
  set evernoteDataFolder to (system attribute "HOME") & "/Library/Containers/com.evernote.Evernote/Data"

  tell oNote
    set noteTitle to title
    set noteContent to ENML content

    # We have to use a temp path that Evernote has access to... and nothing outside
    # its sandboxed container is guaranteed to be.
    set notePath to evernoteDataFolder & "/attachment_export/" & noteTitle & "/"
    my createNoteDir(notePath)

    # Save the note's XML content in a file we can later access.
    # We need it to find out the correct attachment order as Evernote
    # by default orders them by filename
    do shell script "echo '" & noteContent & "' > '" & notePath & "note.xml'"

    repeat with oAttachment in attachments
      # Save each attachment using its hash as filename.
      # This way, we can match it to the values from the XML content later.
      set noteHash to hash of oAttachment
      set imgPath to notePath & noteHash & ".png"

      write oAttachment to imgPath
    end repeat
  end tell

  return notePath
end tell

Running the this script with a note titled “Notiz” containing 2 attachments leads us to the following content on our hard drive:

/Users/stex/Library/Containers/com.evernote.Evernote/Data/attachment_export/Notiz
- 0cb8d04258fdbfe33739b2529d81fdb5.png
- 270493a2b1a89ceeb2528f1c0e97d1f5.png
- note.xml

The Ruby Part

Now that all the necessary information was available outside of Evernote, I needed to feed it to another script which would find out the actual attachment order and run convert for me. I chose Ruby as Alfred supports it well and… I just like Ruby.

The script assumes that the path the note information was saved to is passed in as first command line argument.

First of all, I had to get the note’s XML content:

require "fileutils"
require "pathname"

NOTE_PATH       = Pathname.new(ARGV[0].strip)
NOTE_XML_FILE   = NOTE_PATH.join("note.xml").to_s

xml = File.read(NOTE_XML_FILE)

As a reminder, this gives us a file containing multiple tags with the attachment information:

<en-media hash="270493a2b1a89ceeb2528f1c0e97d1f5" title="Attachment" width="1979" type="image/png"/>

Since I planned to put this into an Alfred workflow by now, I decided not to use a library like nokogiri to parse the XML since it would require other users to have it globally installed as a gem.

Instead, I went with a simple regular expression and capture groups to get the hash values out of each tag:

attachments = xml.scan(/en-media hash="(\w+)"/)
  .flatten
  .map { |a| "'" + NOTE_PATH.join("#{a}.png").to_s + "'" }

For the note exported above, this would leave us with the full pathnames to each attachment in the correct order:

attachments
# => ["/Users/stex/Library/.../270493a2b1a89ceeb2528f1c0e97d1f5.png", "/Users/stex/Library/.../0cb8d04258fdbfe33739b2529d81fdb5.png"]

All that’s left to do now is to call convert with the attachments as input files and create a PDF:

PDF_OUTPUT_FILE = File.join("/Users/stex/Downloads", "#{NOTE_PATH.basename}.pdf")

system("convert #{attachments.join(" ")} '#{PDF_OUTPUT_FILE}'")

The final script looks as follows. I added a few environment variables to make it customisable for other users and cleaned up Evernote’s sandbox:

require "fileutils"
require "pathname"

NOTE_PATH       = Pathname.new(ARGV[0].strip)
NOTE_XML_FILE   = NOTE_PATH.join("note.xml").to_s
PDF_OUTPUT_FILE = File.join(ENV["PDF_OUTPUT_FOLDER"], "#{NOTE_PATH.basename}.pdf")

xml = File.read(NOTE_XML_FILE)

attachments = xml.scan(/en-media hash="(\w+)"/)
  .flatten
  .map { |a| "'" + NOTE_PATH.join("#{a}.png").to_s + "'" }

system("#{ENV["CONVERT_PATH"]} #{attachments.join(" ")} '#{PDF_OUTPUT_FILE}'")
FileUtils.rm_rf(NOTE_PATH)

puts PDF_OUTPUT_FILE.to_s

Please note that I decided to pass in the full path to the convert utility here as an environment variable. Alfred runs its code in an environment without sourcing your .bash_profile or similar, leading to a different PATH than you’d expect.

By default, convert resides in /usr/local/bin (when installed through brew), but I wanted to make sure other users could modify the path if necessary.

The Alfred Part

Now with both scripts working on their own, I started building a new Alfred workflow to call them in succession. Creating the workflow was pretty straight forward:

Add a trigger
Call each script and pipe its output into the next script as command line argument
Add some convenience for the user (optional)

1. Adding a Trigger

While Alfred supports a lot of different trigger events (e.g. hotkeys or Applescript), I went with a simple keyword here. Whenever the user types evernote-attachments-pdf in Alfred (auto completion is available), it would offer the corresponding command.

2. Running both Scripts in Succession

I went with two “Run Script” actions for the Applescript and Ruby parts. For the Applescript, the input setting didn’t matter, but I had to make sure to set the Ruby script to take its input as ARGV.

As mentioned before, Alfred always “pipes” the console output of a script to the next action in its workflow. For Applescript, the value after return is automatically printed out, in our Ruby script, we had to do it manually through puts.

The Ruby script could be used as is, for the Applescript, I had to wrap my code inside a sub-routine:

on run argv
 ...
end run

With this done, we can already run our workflow from Alfred and are presented with a neat PDF inside the output directory. I decided to go a bit further though and give some sort of response to the user to let them know everything worked as expected.

3. Adding some Convenience

Many applications open the directory they put a file in after its creation so I went with the flow and added a “Reveil File in Finder” action to the workflow. Since our Ruby script’s output is the full path to the output directory, I just had to connect it to the Ruby script and everything worked as expected:

Since I personally find this behaviour a bit annoying from time to time, I decided to give the user a choice here. I defined another environment variable named REVEIL_IN_FINDER and added a conditional block to the workflow:

This way, the output folder from my Ruby script would either be sent to the “Reveil File in Finder” action or a notification would be shown instead.

Conclusion

When I started with the Evernote Applescript Dictionary, I was convinced I would have this solved within half an hour… should have learned that after that many years of programming.

While the app sandboxing took me the longest to figure out, it was the easiest to be solved in the end. I was a bit disappointed by the Evernote documentation regarding its Applescript usage, e.g. the order attachments would be returned. This caused me to try a lot of different solutions to work around each newfound behaviour until I finally settled with an additional script.

Anyway, I learned a bit more about MacOS applications and scripting and got a nice PDF export out of it, so definitely worth it.