Two of my younger extended family members have contacted me recently wondering how to get into app development, which is admittedly kind of a puzzler for me (apparently publishing TapWatch gained me some level of legitimacy, even though TapNote continues to vastly outperform it, dead platform and all). I could recommend a book, I suppose, except that the only coding book I have ever used is Dynamic HTML: The Definitive Reference. Dynamic HTML is fantastic if you need to reference absolutely anything to do with HTML, CSS, or Javascript, but a lot less useful for someone who wants to write, say, Objective-C and has only the foggiest of ideas about what they’re getting into.

Frankly, the way I learn a new language or tool is by using it. I start with a project, usually something I want to use myself, and then just jump in feet first. This typically involves scouring the internet for example code, tutorials, and prior art that I can implement and tweak to my own needs while regularly banging my head against the wall. I’ve bought a few coding books aside from Dynamic HTML over the years, but I never make it very far past the introduction. They bore me to tears. Head-to-wall contact is admittedly a bit painful, but it’s a lot more interesting and the things that I learn tend to stick.

So recommending books is out. I’ve heard good things about a few of them, but having never read any (or learned anything substantive the few times I did try to crack their covers), I’m rather unqualified.

But saying, “Just find a project and run with it!” isn’t terribly helpful, either. That’s a great way to encourage a proto-coder to drop the whole idea before they really get started. Especially if their ultimate goal is writing an app for their favorite iOS device, which can be a complicated and frustrating process even for veteran coders.

And at this point I find myself staring at a blank email, certain I am about to send my young relative down the path to a sad and codeless life.

Though I may not have a lot of practical knowledge when it comes to easing your way into coding, I do have a fair bit of observations based on first-hand experience to offer. Perhaps that will be helpful instead.

Overcoming the wall

The land of coding is a wonderful, magical, frustrating place but to get there you have to find your way over the wall that surrounds it. This isn’t a learning curve (although you’ll find plenty of those beyond); it is a wall. Steep, high, and not exactly obvious in approach. The simple fact is that coding is unlike anything you have ever done previously. When you write code, what you are actually doing is using a specialized language to lay out simple, logical instructions for a device that can only make the mistakes you inadvertently tell it to make (the trick is that huge numbers of other people have already layered on numerous strata of instructions with their own inadvertent mistakes that you are building on top of, so even if your code is perfect you still may find yourself running into problems that encourage head-meet-wall interaction).

There are analogs to other things you might have learned in the past (other countries’ languages, scientific experiments, math, art), but particularly if you do not know what you are getting into, jumping into coding will likely feel like running into a wall. You can vaguely see where you want to be when you back up far enough, but when you get close the whole thing is simply overwhelming.

But do not fear! Many of the other people who have scaled this wall in the past are there to help you over, through, or under it.

Your first coding lesson

I shall now give you your first coding lesson. Learn this, and you’ve basically lopped off the top few feet of the wall before you ever reached it.

Here it is: dream big, act small.

There are numerous desires that lead people to coding, but probably the two most common I run across are the desire to make money and the desire to make a tool you yourself want to use. And make it right this time, because darn it those other developers are approaching the problem all wrong.

Both are great motivations, but keep in mind that neither is something you are likely to accomplish immediately. Especially when it comes to app development a lot of people nowadays are going into it with stars in their eyes, imagining their app taking off on the bestselling charts and making hundreds of thousands of dollars in a month or two. Banish this fantasy! Yes, it is remotely possible you could succeed wildly with your first app/website/whatever, but the chances of it are vanishingly slim. Striving for widespread adoption is laudable, but if you measure your success solely against it you will quickly become discouraged, and discouraged people don’t ship software.

So have your big dream, but act on smaller things. Coding is about taking a complex problem and breaking it down into manageable smaller steps. It is about understanding the limitations and restraints you are working with and finding ways around them or adapting your code and vision to work within them. It is about having a laundry list of features that you know you absolutely must implement, but being able and willing to ship only the tiniest subset of them in your initial 1.0 release, and then steadily adding more as you go.

It is about realizing that you are not, in fact, facing a wall. You are facing a collection of stones, each of which is much easier to deal with on its own.

Three things to master

At root, there are only three things you have to learn:

1) The basic building blocks: variables (typically composed of arrays, strings, numeric types, dictionaries), functions, loops, conditional statements, and (for most modern languages) classes and objects. Learning about this stuff pretty much allows you to write in any coding language you want; usually the only thing that differs between languages is the specific syntax you use, which is (typically) easy to pick up. Coding is simply a specific, logical way of thinking and communicating using a small number of standard tools.

For basic building blocks, you can find any number of “getting started with language X” tutorials and resources online. Look for the very early introductory materials that introduce variables, functions, etc. and read through them. Once you understand if/elseif/else blocks, for and while loops, variables, and functions you will have the basics for what you need to read and write code.

2) The syntax: every language is different, so before you can write one or another you have to figure out how it handles the basic building blocks from above. For instance, here’s the same variable (a string) in three different languages:

Javascript:

var helloString = 'Hello world!';

PHP:

$helloString = 'Hello world!';

Objective-C:

NSString *helloString = @"Hello world!";

Exact same meaning in all three, but slightly different requirements for each. When you are learning the building blocks above, try to find a tutorial for whatever language you are most interested in working in right away, because all the examples will use its syntax, allowing you to learn both at once.

3) Specific capabilities: every language and environment offers slightly different built-in functions and so forth that you can call upon. This is the stuff that I typically spend very little time learning, and look up as I work.

For instance, PHP has a zillion functions that help with anything from manipulating strings to connecting to databases, and it would be a complete waste of my brain to try and memorize them. Instead, I keep the PHP documentation handy when I am working in that language and reference it when I need to figure out how to do a particular task.

The same applies to Objective-C; a lot of the complication behind Objective-C is that most of what you will be doing is working with the framework’s provided objects, functions, and methods, and since there are so many of them it can be overwhelming when you get started. Instead, ignore them. It might be worth skimming over some of the functions provided for working with the basic types of variables like strings, arrays, and dictionaries so you have an idea of what things you can do out of the box, but typically it’s easier to look this stuff up as the need arises.

Practical application

Lovely abstract overviews and pithy sayings may make you feel good, but coding is a practical activity and up to now I admittedly haven’t offered much specific, practical advice. Let’s change that, shall we?

When you are first getting into coding, any language you learn is going to help. They all will teach you the basic building blocks (and for a lot of them, you’ll pick up a fair amount of common syntax, too), so it doesn’t matter at all where you start. The corollary of this is that learning a language other than the language you want to work in might be a good idea, particularly if it will allow you to see results more quickly (and based on my own experience, seeing results quickly is important; there is something truly magical about using something you have programmed that pays for the frustration and difficulty leading up to that point).

For instance, if I were just now getting into coding with the ultimate goal of publishing a native Objective-C app, I would not start off working in Xcode and trying to learn Objective-C.

I would learn Javascript.

The benefit of Javascript is that a lot of the syntax is very similar to C, but because it is a high-level language you can go from learning the building blocks to actually creating something a bit quicker (and typically with less frustration, although there are certainly pain points in Javascript, as well). Javascript has its share of unique quirks, but with your pick of frameworks like Enyo, jQuery Mobile, Sencha Touch, and others you have some very useful tools that can speed things up by providing common interface elements and other niceties.

Granted, you will likely want to learn a framework in addition to the language itself to use them, but the same is true of Objective-C (coding in Objective-C is practically nothing but learning to use a framework).

How I would learn Javascript is a little more up in the air, but I have heard excellent things about Codecademy, so I would likely start there, and then quickly transition into writing my own app as soon as I learned enough to be dangerous. Most Javascript frameworks also have active communities surrounding them, so I would try to leverage those to help me get over the difficulties of going from idea to actual working interface elements on screen.

Once I had a working, simple Javascript app, then I would start digging deeper into Objective-C as I moved toward my true goal.

Other resources

Not everyone learns the same way as I do. If you learn better through books, then by all means visit your local bookseller, consult some Amazon reviews or similar, and try one of them.

Regardless of what you are interested in coding, I would also highly recommend taking a course in C if the chance arises (or C++, but C is far more universally useful). A local community college would probably be the most likely place to find something like this. When I was in college, taking a course in beginning C++ was an incredible boon. It taught me a lot about not only C (which has been useful when I need to write Objective-C or try to read other source code written in other low-level languages), but also introduced me to the command line. Getting enough knowledge not to be scared of the command line is incredibly liberating.

General courses on how to think about and approach code would also likely be useful, but you can usually achieve the same knowledge through active curiosity and a willingness to read a bunch of articles and blog posts online.

Go forth and code

How you go about it and what language you use doesn’t matter. Ultimately, what matters is that you get out there and start writing code. Come up with your big dream, and for your first small act create something simple but useful, be it a website, a mobile app, or a script that makes a repetitive action on your computer less onerous. Learn Javascript, or buy a book about Objective-C, or find a course to take. Experiment, fail, and try again.

No matter what route you choose, it will be frustrating, it will be difficult in the beginning, but it will be worthwhile. Even if you never spend the time to get particularly fluent in any given language, understanding the basic building blocks of code and knowing just enough to be dangerous can open a lot of doors and give you a way to tweak the devices that you rely on every day to better suit your needs.

Good luck!

I am very pleased to announce that TapWatch, my simple and beautiful stopwatch app for iOS, is now available! View it in the App Store here or check it out in all its minimal glory:

Not that long ago, I needed to time something. Having my iPhone handy, I figured it would be the work of a moment to find a simple stopwatch app and get on with things. I had wanted but three things in my stopwatch:

• No buttons
• Aesthetically pleasing design
• A log of recent times

Half an hour later, I emerged from the morass of the stopwatch apps in the App Store without having found anything that even satisfied two out of three (including the stopwatch mode in the built-in Clock app).

Clearly developing a stopwatch is something people do as a learning exercise, and then forget about. But simply because a niche is unprofitable does not mean that it should not have at least one beautiful option. So I decided to write my own stopwatch, and thus TapWatch was born.

TapWatch offers the following niceties:

• Tap anywhere to start and stop the timer: no more hovering your finger over small buttons!
• Double tap anywhere while a timer is running to start a new lap: you won’t lose any time, because TapWatch notices the timestamp from your first tap, and picks things up from there on the second
• Slide left to view your 50 most recent times (automatically saved!)
• The screen will stay awake as long as TapWatch is active and a timer is running, so feel free to watch what you’re timing
• Multitask: exit TapWatch while a timer is running with impunity; even if iOS quits it in the background it will continue timing
• Scales beautifully when timing things that last anywhere from tenths of a second to hours

If you ever need to time anything, I hope you will give TapWatch a try! I would also love to hear from you if you think the app needs improvement; my personal uses for stopwatches are pretty basic, so I would particularly love to hear how people who need to time things often like the app (coaches, teachers, etc.).

If you’re a busy person, here’s the short version: we at MacRabbit just released an awesome new app called Slicy that is absolutely essential for anyone who ever needs to export an image from Photoshop. Go check it out now.

The short story is pretty boring, isn’t it? Thought so. Here’s the long version:

Since moving from doing web development to being the guy who does whatever needs doing at MacRabbit (mostly involving Espresso plugins and customer support), I haven’t been using Photoshop as often. However, I do still need it from time to time; Photoshop is always central when it comes time to redesign one of my sites, and I crafted all of the UI for TapNote and my upcoming iOS app TapWatch in Photoshop (there was a brief stint where I spent a huge amount of time and pain trying to do the same thing in other apps, but it wasn’t remotely worth it).

But there’s one aspect of using Photoshop I always dread: slicing and exporting my images. It sucks. A lot. Always. I can spend almost as much time rearranging and slicing a file in order to get the right transparency and backgrounds as I spend designing the darn thing.

And what particularly sucks is that after I’ve painstakingly sliced my document and created a total mishmash that looks nothing like the original mockup, I inevitably discover that some small thing doesn’t work. Perhaps a button needs to be just a little bigger, or I want to change the color palette slightly.

This wouldn’t be a big deal, except that I no longer have a working mockup. I have my original mockup, and then I have the sliced-up mess that I have to use to actually generate my site files. Trying to move changes between these two versions is soul-destroying.

If you use Photoshop with any regularity to prepare graphics for apps, the web, or just about anywhere that necessitates the “save for web” dialog, you know what I mean.

Time to cue the heavenly light and choir, though, because our savior has arrived and its name is Slicy:

Using Slicy is ridiculously simple: in your Photoshop file you name your layer or layer groups the same as the file you want to output, then drop the PSD on Slicy and watch it work its magic.

For instance, I recently had to design an iOS app icon for TapWatch, which thanks to the sheer number of iOS device resolutions meant I was actually designing five versions of the same icon. When it came time to export my various icons, I simply named the appropriate layer groups “icon.png”, “[email protected]”, and so forth, then dropped the PSD on Slicy to export all of them without needing to hide or remove the background layers that provided me context for the icons (or do any other configuration). When it was done, Slicy asked me if I wanted it to watch that particular file for updates and automatically do the same export whenever it changed. I checked “yes”, and now as long as Slicy is running I can make a minor change to my TapWatch icons and export them all simply by hitting command-S.

It’s a completely different way of working, and I wish that it had been around when I was doing web work. There were so many times when the graphic designer wanted to change some small thing, and sent the change over in their original mockup, which I then had to re-translate into my sliced version (and just hope that I noticed all the changes). With Slicy, I could have renamed the layers appropriately, sent the mockup back, and they would be able to make their changes right in the same file. Once they were done, all I’d need to do would be to toss the file in Slicy once more and go.

At this point, the people who are regular users of Photoshop have probably already bought Slicy, but in the interest of helping people get the most out of it, here are some additional fun things to know:

• If you need to define a specific region for your image to live in, just add a square vector or layer mask to the tagged layer group. Slicy will base the dimensions of the final image off the mask instead of auto-generating them based on the surrounding transparency (this also works to explicitly define the image area if Slicy is missing an outer stroke or shadow, which occasionally happens in v1.0). If for some reason you don’t want to add a layer mask, you can stick a square vector shape layer named @bounds inside of the layer group, and Slicy will use it to calculate the boundaries of the image instead.
• As you would expect, layers do not need to be visible for Slicy to export them (or even completely contained in the canvas, for really large vector images and so forth).
• If you name multiple layers identically with an .icns extension, Slicy will automatically combine them all into a single Mac icon file.
• If you need to slice something like you would traditionally in Photoshop (so that the background layers are visible and so forth), add a group called @slices, and populate it with square vector shapes named after the images you want to export. Slicy will calculate the size and position of the images, and include everything in the group that contains the @slices group (which could be the entire PSD, if you place it at the root level).

Slicy is still a 1.0 product, so it doesn’t support everything (notable exceptions are CMYK documents and advanced filters), but MacRabbit will of course continue to improve it to try and address the edge scenarios. If you would like to buy it, you can find it here, and if you would like to see a Photoshop file formatted for use in Slicy there are several examples on the Slicy website.

I love tapioca pudding. I’m generally not a big fan of puddings, but tapioca was one of the few my mother made growing up, and since it’s not terribly sweet and goes wonderfully with fresh fruit I fell for it (growing up we would go to U-pick farms for strawberries and other berries, and after making the bulk of them into jam serving them over tapioca was second in awesomeness only to making them into pie).

In any case, this evening I found myself in need of something to serve with dessert crêpes since we didn’t have any ice cream in the house (a batch of crêpes split in half makes almost exactly two savory and two dessert crêpes, which is perfect for my girlfriend and me). I figured I’d try tapioca pudding, but I wasn’t eager to have plain tapioca pudding inside of plain crêpes.

One thing led to another, and I ended up with orange-flavored tapioca pudding, which is ridiculously good for a shot in the dark (I searched the internet prior to making it, but aside from learning that this is something a small number of people do I didn’t find any good recipes. If you like tapioca pudding and oranges, I highly recommend you give it a try.

Orange tapioca pudding recipe

(This is a lightly-modified version of the recipe on the Minute tapioca box; you could likely adjust it for use with other types of tapioca without much effort; the trick is substituting orange juice for most, but not all, of the milk.)

• 1/3 cup sugar
• 3 tablespoons Minute tapioca
• 2 cups orange juice
• 3/4 cup milk (whole milk is best)
• 1 egg, beaten
• Pinch of orange zest (optional)

• 1 teaspoon vanilla extract
• Splash of orange flower water (optional)

Combine the sugar, tapioca, orange juice, milk, beaten egg, and orange zest (if you have a fresh orange on hand) in a medium pot and let it sit for five minutes.

Cook on medium heat, stirring constantly, until it comes to a full boil (boils while you are still stirring). Remove from heat. Stir in the vanilla and a little orange flower water (if you have any on hand).

Let the pudding cool for 20 minutes or so, then either eat it warm or refrigerate for later. I prefer it warm, my girlfriend prefers it cold.

I can say first-hand that this is absolutely divine served in dessert crêpes, garnished with orange zest, and drizzled with chocolate sauce. I fully expect the left-overs will be great on their own, too. If you’re really feeling fancy, slice up some fresh orange or other citrus-friendly fruit and serve it alongside or on top.

Another year has passed, and once again I’ve been feeling the itch to redesign Beckism.com. So without further ado, I present to you its latest look!

I was actually pretty happy with the previous design, so I stuck with the same main layout and color scheme. The main problem I had it was that the one pixel borders and arrows were simply not breaking things up enough well enough; it was really difficult to distinguish between posts on the homepage, and viewing the site on a mobile device was an effort in frustration (since the borders were virtually invisible and the headings were longer than the text, which made zooming in difficult).

Both of these issues should now be fixed, and I also introduced some fun little features here and there like threaded comments, a search button in the header to jump straight to the footer, and so forth. Additionally, the site should look beautiful on the iPhone 4 (I haven’t had a chance to test it on other mobile devices yet).

I’ve tested things on the major non-IE browsers, but please let me know if you run into any problems! I always love getting feedback.

I am a binge reader. I will go for months at a time without cracking the cover of a book, and then in the space of a week I will do nothing but scour book listings in my free time and avidly consume everything I find. Thanks to my utter lack of discipline when it comes to reading, this typically results in me losing sleep, wandering around the house in a daze, and generally making a nuisance of myself.

It’s been a while, but I think it is long past time that I shared the love. Here are some authors that I have discovered recently who you should not miss, along with some old friends and standbys.

In general, my tastes run to fantasy and science fiction, so that’s what you will find here.

My standbys

Some of my standbys you already know about from elsewhere. Neil Gaiman (start with Neverwhere if you prefer action, StarDust if you like romance, or The Graveyard Book if you just like a ridiculously good novel). Terry Pratchett (start with Nation, or just about any Discworld book aside from Colour of Magic; Equal Rites or Guards! Guards! would be excellent entry points). J.R.R. Tolkien, J.K. Rowling, C.S. Lewis.

But there are at least four that you might not have heard of, and need to know about. (Note that all links below are unencumbered; I tried playing the affiliate linking game in the past, but it made me feel dirty and didn’t make any money, so screw that.)

First up, Diana Wynne Jones. If you like children’s fantasy, you’ve probably already run across her, but if not you should waste no time in picking up one of her novels. Sadly, Jones passed away this year but she has a large corpus of novels, virtually all of which are excellent. Start with Howl’s Moving Castle, The Lives of Christopher Chant, or (if you can find them) Cart and Cwidder or Archer’s Goon.

Diana Wynne Jones: Amazon, B&N

Second, C.J. Cherryh. Cherryh mostly writes science fiction, but she dabbles in fantasy from time to time, and she is fantastic. There are a few of her older books that I like less well, but in the last couple decades she has really hit her stride and at this point I buy whatever she publishes sight unseen. Great starting points for Cherryh are Foreigner (stick with it until you meet Bren Cameron; maybe the first quarter of the novel sets up the historical situation and is less interesting), Cyteen, or if you can find it Merchanter’s Luck. Also, don’t be scared by the number of Foreigner books out. Yes, it looks like another Robert Jordan-level commitment, but it’s not. Each book is self-contained, and they have broader story arcs that are organized into trilogies so if you only ever buy one to three books at a time you’ll have a very satisfying reading experience.

C.J. Cherryh: website, Amazon, B&N

Third, Jonathan Stroud. I, likely along with most of his readership, discovered Stroud in the surge of children’s fantasy that occurred thanks to the success of the early Harry Potter books. However, I like him far better than J.K. Rowling (particularly after reading Harry Potter and the Deathly Hallows and its awful ending/epilogue). Start with Amulet of Samarkind, and if you don’t hit it off with Bartimeus read Heroes of the Vally instead.

Jonathan Stroud: website, Amazon, B&N

Last, Megan Whalen Turner. There’s only one starting point for Turner (The Thief) since she has only published books in a single series/world so far. Aside from Cherryh (whose intense third-person style might not appeal to some folks), Turner is the most likely of these authors to not appeal to everyone. The Thief is very accessible and kid-friendly (it was a Newberry Honor book), but Queen of Attolia is much more stand-offish when it comes to characterization and is more of a YA or adult book thematically. Each of her novels so far has had a distinct flavor from the rest, making her a difficult author to pin down.

Megan Whalen Turner: website, Amazon, B&N

Indie authors

I’ve been reading a lot more self-published authors on Kindle lately, and wow is it ever a mixed bag. A small number of them have been horrible (but evidently spent a lot of time making the first part of the book that’s in the sample read great, unfortunately). Most of them have been mediocre to the point where I stop halfway through and move on. And at least two of them have quickly rocketed onto my favorite authors list.

First off, Michael J. Sullivan. At this point, he has achieved a level of legitimacy dreamed of by most other indies, and you can find his fantastic six Riryia Revelations in ebook or print format. Start with Theft of Swords (followed by Rise of Empire and finally Heir of Novron). Sullivan writes old-school adventure fantasy, and I can’t recommend him highly enough.

Michael J. Sullivan: website, Amazon, B&N

Next up is Lindsay Buroker. If Michael J. Sullivan was the best indie author I discovered in 2010, Buroker is hands-down my favorite for 2011. Her first book is The Emperor’s Edge, and it is a wonderful romp through a steam-powered fantasy city. Note that this is not steampunk (although she has a mini-series of novellas that apparently do fit that genre which I have not yet read). Instead, the Emperor’s Edge series are character-focused fantasy adventures. This is also one of the few series where I’ve discovered an “ultimate assassin” type character who actually seemed realistic (it’s really difficult to create a sympathetic cold killer, but over the course of the three books currently released Buroker manages it).

Lindsay Buroker: website, Amazon, B&N

And that’s about it for the independent authors. I’ve found others who were decent, but those are the only two who fall into my “must read everything they write and evangelize them afterward” category.

Newly discovered

I have run into a fair number of excellent authors since I last posted anything on this blog about reading, so these are in no particular order.

You need to read D.M. Cornish. His first book is The Foundling’s Tale (might also be called Monster Blood Tattoo, depending on where you live) and he is one of the authors on this list who is not optional. It is very, very rare in fantasy for people to create things that are truly unique. Typically fantasy relies on mythology, fairy tales, or Tolkien and the many stereotypes that arose out of his founding epic. D.M. Cornish, however, has created a world unto itself, including a new and wonderful vocabulary. He is also one of those rare authors who illustrates his own works, giving you some wonderful insight into how he sees the characters he is describing.

D.M. Cornish: website, Amazon, B&N

I discovered Catherine Fisher because of Incarceron, which is a fantastically interesting book about two worlds: one privileged, with their high technology hidden behind the scenes in order to enforce the illusion that they are living in the past; the other a prison-world where the prison is actively trying to kill its inmates. I highly recommend it. After finishing Incarceron I discovered Fisher is quite prolific. So far I have only read her Oracle trilogy, but it was excellent (a very odd blend of Egyptian and Greek mythology that somehow completely works). I’m looking forward to discovering more of Fisher’s work in the months to come.

Catherine Fisher: website, Amazon, B&N

A year or two ago, I tried Scott Westerfeld’s Leviathan (this one is legitimately steampunk), and since then I’ve read everything he’s written that I can find. Westerfeld is an intriguing one: his premises and characters are flawless and fascinating, but in almost every world he has written I have left it feeling like he fell short of his own potential. He tends to setup worlds where people are diametrically opposed to one another, but often they just shrug off their differences and move on with it. For instance, Leviathan focuses on World War I except that the two sides are divided into Clankers (people whose society is powered by mechanical constructs) and Darwinists (people whose society is powered by artificially fabricated animals). This is a socio-cultural divide that would be deep-seated, largely emotional, and difficult to overcome. Yet the one time the main characters address it boils down to an argument where one says “machines are better”, the other responds “no, animals are better!” and they leave it at that. The ethical, psychological, and cultural ramifications of Westerfeld’s creations are largely unexplored (or left to the imagination of the reader). I have to recommend him, though, because his books and characters are so much fun, and although he pulls back whenever it comes time to deal with deeper issues his premises on their own open up a lot of interesting supposition about our own world. Other than Leviathan, Uglies is an excellent starting point for Westerfeld. In all cases for Westerfeld, ignore the covers of his books. They are never indicative of the quality or style of the books themselves.

Scott Westerfeld: website, Amazon, B&N

Rachel Neumeier is another author whose entire corpus is worth reading (although her very first book is less excellent). In particular, The Floating Islands is a ridiculously good standalone, and her griffin mage trilogy (starting with Lord of the Changing Winds) is one of my recent favorite fantasy discoveries (and what introduced me to her). At this point, Neumeier is another one of the few authors whose books I will simply buy without looking at the description because I know they won’t disappoint.

Rachel Neumeier: website, Amazon, B&N

Lastly, Patricia Briggs. Although I have been getting bored recently with her Mercy Thompson series (stereotypical vampires+werewolves urban fantasy is not my thing), her writing is excellent, and I particularly enjoy her early “duologies” like Dragon Bones and its companion Dragon Blood. Mercy Thompson is worth reading, too, if you aren’t burnt out on all the terrible urban fantasy (this is one of the urban fantasy series of late that actually deserves to survive, although I hope Briggs brings it to a close sooner rather than later).

Patricia Briggs: website, Amazon, B&N

The search goes ever onward

There are of course loads of other great books that I’ve read in the recent past (I didn’t even touch the mountain of princess books that I worked my way through recently; I have no idea why I went on a princess kick, but once you start something like that you enter into a self-reinforcing cycle with Amazon’s “other users bought such and such” and “if you liked this, maybe you’ll like that” recommendations. I barely escaped alive). Perhaps I will remember to post about them here at some point.

In the meantime, the search for more wonderful authors and books continues! If you’ve read some ridiculously good fantasy or science fiction (particularly YA or kids stuff; I tend to enjoy adult novels less because of the graphic violence and escapist sex that often are their defining characteristic), I would love to hear!

Although you are likely aware if you follow my antics online, we at MacRabbit released Espresso 2.0 recently. Whoo hoo!

A whole lot of things are new and improved in Espresso 2, but hands-down my favorite feature is the new Javascript API, which allows you to add custom text actions to the editor using web languages you already know: XML and Javascript. This is seriously awesome; back in the days of Espresso 1.x I created Spice.sugar to allow coding text actions in Javascript, but it was a hack that I was never completely happy with. The new Javascript API is something of a spiritual successor to Spice.sugar, except without the suckiness. It is simpler, better documented, and is true Javascript (rather than Objective-C methods contorted into Javascript).

Sadly, I don’t think people realize how awesome the new Javascript API is, so in the hopes of making people’s lives better and raising awareness for it, I present to you Handy.sugar:

https://github.com/onecrayon/Handy.sugar

Every so often someone writes in to MacRabbit with a feature request that I think is awesome, but which I doubt Jan will want to integrate in the core editor for whatever reason (or that I think he probably will implement, but is currently a low priority). Of course, this was exactly why Jan implemented the Sugar system in the first place: Espresso will never support a broad enough range of actions to make everyone happy out of the box, but it is ridiculously easy to extend.

And so was born Handy.sugar: a collection of some of my favorite feature requests I’ve read at MacRabbit recently, with a focus on actions that allow you to keep your hands on the keyboard.

I am still adding things to Handy.sugar, but here are my current two favorite features (all of the visible features that Handy.sugar adds will show up in the Actions→Handy menu, so you can explore others on your own).

Keyboard of coding +1

Handy.sugar’s actions for incrementing and decrementing numbers in your code are what prompted me to create the Sugar in the first place.

Using the actions is super easy: move your cursor next to a number, and hit command option ↑ to add 1 to the number. As you might expect, command option ↓ decreases it by 1. Add the shift key, and you’ll move up or down in increments of 10.

But wait, there’s more! The incrementing/decrementing actions are smart enough to also handle the following situations:

• If you select a swathe of text that has a number somewhere in it, the action will affect that number
• If you select a swathe of text with multiple numbers in it, the action will affect all of them
• If you have multiple selections, the action will affect any numbers in them (as long as the first selection contains a number; otherwise the action will not be enabled)

For the moment, you can only modify base 10 integers using these actions. I thought about implementing something similar for hex or octals, but thanks to formatting differences across languages could not come up with a good “one size fits all” approach. You can modify floats, but only the portion before the decimal point will be modified. Transitioning between positive and negative numbers should work exactly as you would expect.

Multiple selections for fun and profit

Creating multiple selections in Espresso is easy (it works just like it does elsewhere in Mac OS X):

• Hold down the option key, then click and drag to create a column of selections
• Hold down the command key, and select things with your mouse in multiple places (by double clicking words, triple clicking lines, clicking and dragging, etc.)

But once you have multiple selections, Espresso unfortunately only really supports deleting all of them at once. Until you install the Handy.sugar, that is:

• Hit control [ to prepend text to all selections
• Hit control ] to append text to all selections
• Hit control \ to replace all selections

(Incidentally, if you opt not to type anything after invoking that last shortcut, it will instead replace all selections with the contents of your first selection, which might be useful in its own right.)

If you have been missing column selections from Textmate or block editing from Coda, these actions will likely make you very happy since they perform basically the same functions.

Not just a useful tool

Handy.sugar offers a bunch of useful functionality, of course, but hopefully it will also serve as an example of the kinds of things you can accomplish with the JavaScript API. You can check out exactly how I am accomplishing any given action by right clicking on Handy.sugar in the Finder and choosing “Show Package Contents” or by browsing the source on GitHub. I tried to keep it pretty well commented.

If you decide you would like to try your hand at your own custom Sugar actions using the JavaScript API, check out the introduction to JavaScript actions and then take a gander at the JavaScript API reference.

And if you do undertake some Sugar development, you can always email MacRabbit for help or look for aid in our Sugar developer forums.