Automator Services

I keep discovering new uses for Automator.

I'm not sure when the "Services" option became available, but it's worth checking out. I had previously wrote a text-to-markdown action, which converted the clipboard contents from markdown to HTML. This was convenient, but it involved copying, running the app and then pasting. The script did this:

pbpaste | Markdown.pl | pbcopy

With services this becomes much simpler. It's now in the contextual(right-click) menu for any application that deals with text, and I also set up the keyboard shortcut CMD-ALT-SHIFT-M. It replaces the selected markdown text with the HTML. The action is even simpler; just a single command:

/usr/local/bin/Markdown.pl

If you've installed the markdown script somewhere else, you'll have to set the appropriate path. And here's a screenshot of how the input is configured.

Search and Replace

Almost any shell command can be wired into OSX this way. If the command needs special arguments for each run, just check the box: Options > Show this action when the workflow runs. I did this for Sed search and replace action. Here's the workflow script:

sed s/old/new/g

On each run you want to change old and new with what you're searching and replacing, but it doesn't have to end there. You can change the command on the fly to anything that deals with text transformation. sed /^$/d deletes any empty lines. grep andyvanee filters out any lines not containing 'andyvanee'.

View Command Output

For text commands where you don't want to replace the text, just see the results of some command, uncheck the 'Replaces Selected Text' box and add a "Choose From List" action, or maybe "New TextEdit Document" to view the results. For good measure, add a "Copy to Clipboard" action at the end, just in case you want to do something with the output of the command.

This is probably more useful for grep type commands, so I saved this one as "Grep Text" and the previous as "Sed Text", although either can be used for a wide range of commands.

Democamp 13

I went to my first Democamp this evening. I thought I'd share the experience while it's still fresh in my mind.

First off, I wasn't too sure what to expect, but it was fairly close to what I thought. The community is pretty tight, and there is a good energy. There was only 5 demos, and a couple were somewhat underwhelming, but I'll start with the good:

pluggin.it presented their new app for selling stuff on fb/twitter and sharing the profits with the friends who helped you get the word out. Seems like a great idea, and it seems like they've thought it through quite well.

A guy (I forget his name!) from 3Di who works with their pureLIGHT lighting engine presented his concept game that was pretty cool. It was based on the idea of mapping the 3D engine onto curved space... Kind of hard to describe, and unfortunately his demo only covered the basic "training" level, which wasn't very curved at all, but I could definitely see the potential of a game that ran with that idea. The graphics and lighting were very top-notch for indie developer.

There was guys from deckle there. Solid looking application, but I had this creepy feeling when they demoed the feature of printing bank quality cheques. I suppose I'm just not all that starstruck with the wonders of print media.

And the rest don't really deserve links, in my humble opinion.

Afterwards, we headed to the pub and I got a chance to meet some cool people in the Edmonton developer community. Good stuff!

Rapid Game Prototyping in Quartz Composer

I am a Quartz Composer junky. I love tinkering with ideas and hacking together logic gates within this kind of visual programming environment.

I think this it's the best way to teach core CS techniques that are often obscured in text-based code. Things like logic gates, the value of modularity, and application structure start to really make sense when you lay them out visually. It's like a UML diagram that functions and evaluates in real-time.

As an example, I will use a game-idea I had, and how I quickly mocked it up in Quartz Composer. It's called "Stellar Debris", and the point of the prototype is to demonstrate vertical parallax motion in a 2D game (like the background scrolling in Canabalt).

The storyline is that your character is a flying robot(spaceship?) that takes off from the surface and must make it through the layer of orbiting debris in a post-apocalyptic earth. The controls are very basic, click to takeoff, mouse back and forth to move and click to shoot.

Here's the start screen. The graphics are very rudimentary (prototype remember!).

Once you click, the character takes off and you can control his motion and fire bullets.

You'll notice the foreground has scrolled off screen already and there are blocks to shoot. The background scrolls much slower, and the sky doesn't scroll at all. It also gets darker as you ascend into the atmosphere.

Game Logic

I don't think I would want to build an entire game in Quartz Composer. But having a mockup like this is great for prototyping because most of the game logic is there in a clear modular structure, which makes it a great starting point for porting it to your programming language of choice. Here's a look at the patches involved in making this "game" happen.

Rather than coding blindly, many of the logic bits required for gameplay are already in place. Things like "the bullet needs to know the character's position at the time of firing" or "each 2D layer needs to know the absolute position and multiply it by some factor" or even "the clouds look good enough as a blurred semi-opaque sprite".

From Command-line to XCode

I'm a command-line guy at heart when it comes to programming. It seems much more organic to know what every project file is doing and how each one contributes to the whole. Which files might break things, which files are optional and which files can be refactored or optimized.

"The Pragmatic Programmer" challenged this notion. They recommend diversity. If you only know and IDE, try command-line and if you know command-line, try an IDE. At first I was skeptical of this advice. I've come to know my command-line toolset fairly well, and IDE's feel like they add too much baggage and inflexibility. I've built Xcode projects before, and there is a lot of behind the scenes voodoo attached to the projects.

But, after pushing through my initial concerns, I've come to really enjoy using Xcode for my projects. Here are some command-line programmer concerns, and how to alleviate them in Xcode. Some may be obvious to those who are at home in their IDE, but they weren't to me.

• Problem: I'm going to have to fill my project folder with unnecessary Xcode-specific files.

• Solution: Make a workspace (eg. Documents > Web_development.xcworkspace). Add your project folders to this workspace(without copying the files).

• Problem: My project is unique, won't I have to use the command line anyway?

• Solution: This is where command-line knowledge really pays off. Just create a new "Scheme" and you can run scripts pre/post Build pre/post Run. For a simple HTML site, I just set Safari.app as the executable and my index.html file as the argument. The build scheme is your hook into all the command-line utilities at your disposal.

• Problem: I prefer editing with [vim, emacs, ...].
  Solution: Well, I can't really help you there. Personally, I like Vim, but I'm not a total fanboy. I'm quite happy using the standard OSX keybindings, with a few tweaks for one's I use a lot. Find & Replace works well. Split view and file navigation work well, and syntax-highlighting is fully configurable and works with every file I've thrown at it.

• Problem: I can't manage my git(svn, whatever) repositories from there.

• Solution: This was my own ignorance. I use git for all my projects, and Xcode support for git is actually pretty awesome. It automatically knows if a file is in a git repo, and puts an M beside the file if it's been modified.

All in all, I've really enjoyed programming in Xcode. It does take a small investment of time and imagination to build custom projects, but I think it's worth it.

Skratch Beta - Call for Testers

I've finally got my online coloring book ready to unleash into the wild and I would like to ask you to try it out!

If you're willing I would ask that you answer all/some/none of the following questions and e-mail them to me (1andyvanee _at_ gmail _dot_ com )or just leave a comment.

---

1. What hardware/browser(s) did you try it on?
2. What was your overall impression of the app?
3. Have you used any comparable applications? If yes, what did you like/dislike about them?
4. Was there any features that seemed unexpected or strange to you?
5. If you could add one killer feature, what would it be?

---

Thanks guys, have fun with Skratch!

Download it Here

P.S. If you answer Internet Explorer to the first question, you probably won't get to the rest...

P.P.S. Confirmed, Absolutely NO IE SUPPORT.

Endangered Species and UX

I've just picked up Gene Wolfe's collection of short stories, "Endangered Species" for a second read. I stopped after the introduction to think about it for a while. It's that good.

I'll outline his points first for context. Wolfe starts by saying that the most important aspect of a story is that it have a reader. He explains that he wrote these stories for me, the reader. He then goes on to describe me, the reader, in great detail. My hopes and fears, my character flaws, virtues, vices and deepest thoughts. He also tells me the reason he wrote a few of the stories particularly for me.

His examples are obviously generic enough to cover a lot of people, but it's truly remarkable how specifically he targets his audience. Here's an excerpt to give you the flavour.

"...At certain times you have feared that you are insane, at others that you are the only sane person in the world. You are patient, and yet eager..."

The reason I have found this so refreshing is that I've read a lot on User Experience(UX) lately. There is a fair amount of hype and self-importance in a lot of UX articles. The stated goal of UX is providing a pleasant experience for "The User", but most of the literature drives home the point that the average user is ill-tempered, ignorant and just plain stupid.

Gene Wolfe truly cares about his readers. He thinks highly of them. He also expects creative engagement and effort from his readers.

UX design seems to be focused on placating unwilling participants. I would argue that it should be focused on delighting the willing participants. Valuing them.