January 2009 Archives

Now that Yahtzee is nearly complete, my thoughts have started to turn to what to work on next. I have a few ideas.

The one idea that has been in my head since I started Yahtzee was to port/re-write it for Windows, using WPF. Not only would this let more people be able to use it (sadly, not everyone in my family has a Mac...for shame! ;), but it would give me more experience with using WPF. I'd say that I am doing pretty good with WPF currently, but my only experience with it has really been rewriting small personal apps that I use at work to automate a variety of activities (filling out my time sheet, entering bug reports, etc.). While that is good and all, they are all pretty small and don't do all that much. Yahtzee would be more complicated than that - but not too complicated.

Another idea I've had would be to automate how I keep track of our finances. For some history, I use a Numbers to do this currently. Yes, it would (probably) be better to buy an app to do this, but I haven't found one that I liked that also works how I want it to. Besides, I have a system, and it works, so I can't complain too much.

Granted, there is some room for error in my system which is never a good thing. While I have toyed with the idea of writing my own finances app in the past (and failed/gave up, multiple times), a better approach might be to come up with something that would make my current system more efficient. If nothing else, I wouldn't need to write much in the way of presentation and storage, since Numbers take care of that for me.

Now that Numbers '09 finally has support for AppleScript, one option would be to write a set of AppleScripts that would automate what I do manually. To take that idea one step further, maybe that should be a "real" app instead, that uses AppleScripts to put the data that I enter into Numbers for me. That could work.

Of course, at this point I'm getting perilously close to basically writing my own finances app. But, this does take a number of annoying issues out of the equation - how to store the data, and how to manage such large amounts of it that I will accumulate over time. Maybe it would be best to start with the AppleScripts themselves (since I would need to write those anyway), and if prompting for data there isn't working too well, write a Cocoa UI to wrap them.

The one downside to all this is that I currently own Numbers '08, which doesn't have said AppleScript support. Since I don't use Pages or Keynote much (the other two apps in the iWork suite), I would basically be buying AppleScript support in Numbers for $80. I haven't decided yet if that's worth that price or not.

In any event, I do have a few ideas to go with, so hopefully I'll be able to keep my programming juices flowing at home for the near future.

I've made some good progress on Yahtzee this past week. In fact, I think that I am mostly done with it! Players can take turns, and they're even notified when the game is over (and who won, of course). I have a work around for the bug that I mentioned last time (just tell the NSArrayController in the second window to update itself - not the best in the world, but it'll work). I need to test it with M a few times, but it should be mostly good to go.

I've had a few offers to test it as well, from people across the Internet. That will be a good test too, although I'm not sure why it wouldn't work. Only one way to know for sure, though.

The one feature that I've thought of that might be good to add would be some sort of chat feature. Currently, there is no in-game way for the players to communicate with each other. Sure, they could start up a separate IM chat or Skype call, but that doesn't seem to be the best way to handle things.

While chatting is easy enough to implement, the problem that I have doing so is how to display the text. I'm using an NSTableView to display the messages, and all is well if they are short. However, if the text is longer than is visible, the control appends "..." to what's visible instead of auto-sizing the column. Even better, I can't find any way to set the column to auto-sizing to contents. Nor can I find an easy way to tell it to wrap the text (I'd have to compute the height of the row myself, which is more work than I'd like to do, really).

Maybe for now I'll just leave things as-is and require a separate communication method of some sort. This just a quick and dirty app, after all - not something that I'm looking to sell or anything.

Overall, I think that this project went really well. The UI part of it was finished very quickly - that shows that I'm finally starting to get the hang of Cocoa for UI, thankfully. The client/server communication wasn't too bad, but it was definitely hindered by my lack of knowledge of general Cocoa/Objective-C APIs. That part should also get better with time and practice.

The eternal question when it comes to video games is, "Consoles or PCs?" There are groups of people that are extremely dedicated to both, with valid positives and negatives on each side. It is a question that will likely never be answered with complete satisfaction.

I have been pondering this question as of late. You see, my current PC is very old - it will be five years old in a few months. Believe it or not, it can still play some new games, although not very many. Those it can play it only barely meets the minimum requirements for. Many games, it can't even play at all. Such is the way of things.

While we do have a Wii, I don't really play that much anymore. 2008 was not a very good year for the Wii for someone looking for "normal" (i.e. non-casual or non-mini) games. 2009 does seem to be shaping up to be better in this department, but the Wii will never be an equal to the Xbox 360 or PS3 due to the large gap in hardware capabilities between them.

While it would be nice to say that I should just get a new PC and a new console (or even both an Xbox and PS3!), I do not really have the funds to do that - not to mention the incredible amount of time it would take to justify owning so many systems. That just isn't going to work out.

Instead, I started thinking about the pros and cons of owning each. That is always a good way to decide things like this.

On the PC side, one positive for me is that I've been heavily into PC gaming for a quite some time now - probably well over 15 years by now. While that doesn't mean I can, or I will, play any/all of my old games, I do have that library to fall back on, if need be. This is also ignoring all of the cool PC only games that will be out in the next few years - Starcraft 2, Diablo 3, Half-Life Episode 3, the unannounced (but inevitable) Portal 2, and Star Wars: The Old Republic (assuming that I want to tempt fate and try the MMO thing again). I'm sure there are others as well that I'm not thinking of right now.

Many games that are released for the Xbox 360 and/or PS3 are ported to the PC, too. Granted, they generally arrive a few months later, and some are shady ports and possibly with invasive DRM, but I can always avoid those games. The DRM part does seem to be getting better, though - especially after the reaction gamers had to Spore's horrible DRM.

Steam is just plain awesome, and only on the PC. While it is similar to Xbox live (which costs $50/year to play online), it is really an incredible platform. While it does have DRM built-in, it is so out of the way that it may as well not have DRM, as far as I am concerned.

Finally, the other thing to consider about the PC is that it does more than play games. I'm a Windows programmer by day, and it would help me to stay abreast of the latest technologies by writing side projects at home. This would be a good way for me to learn WPF better, for example. A console definitely can't do that.

On the console side of things, the main advantage is convenience. No dealing with driver upgrades, instability (due to the large number of potential hardware configurations), long and arduous installs...not to mention frequent hardware upgrades (I really should have upgraded my PC years ago if I had wanted to stay current). Plus, there is the price - I would be likely to pay $300-400 for a really nice Xbox or PS3. That's not bad at all, given the quality of games available for each system.

Of course, I would be starting from nothing on a new console, since I don't have any games for it. That would be quite an initial cost to justify going that route.

And really, most of the positives of going the console route (for me, at least) are things outside of the console itself. My desk is currently shared between my PC and my Macbook. If I didn't need the PC anymore, then I could have a better setup for my Macbook - use my PC monitor as a second display (while the built in 13" inch display is nice, an additional 17" display is even nicer), plug in a real keyboard and mouse, etc. That's not really a positive for the console itself, but more a side affect of going that way.

As I said earlier, to play Xbox games online it costs $50/year. While that's not too bad, at the same time it is more than I need to play PC games online (ignoring MMOs, at least). That's just another cost to gaming on a console, really.

When I started writing this, I thought it would be much more balanced between the two sides, but for me at least it seems like the PC side really wins out. That's not to say that this is the right answer for everyone, of course, but it seems like the right thing to do for me.

Of course, now the question is, "What do I get?" That is likely an entirely different post, for another time.

While I bought my MacBook over two and a half years ago, I didn't start getting into programming it until a little under a year ago. It has definitely been an eye opening experience.

I guess that I was most surprised by just how different it is from Windows programming. At first, when I had no idea what I was doing, I couldn't even search the documentation to find the answer since the whole concept of Cocoa programming (the primary API for OS X apps) was so foreign to me.

Once I got familiar with it (greatly aided by Cocoa Programming for Mac OS X, by Andy Hillegass), things got quite a bit easier. I still had a lot to learn, though.

Now that I am starting to really get into and understand WPF, it's amazing to me how similar it is to Cocoa. They both greatly emphasize the use of data binding for populating UI controls, and they have a lot of features for making programming easier.

They do have their differences, however. Personally, I still feel as if WPF is more flexible. If something that I want to do isn't provided by default, it seems like I'll have a better chance of implementing it cleanly in WPF. Granted, this could just be because I have more experience with Windows programming in general.

Cocoa does have some advantages, too - namely its UI designer. While it was weird at first that it doesn't generate any code, its approach does make sense. Plus it does a great job of enforcing standard UI conventions.

It has definitely been interesting to learn two different UI libraries at the same time. This has shown me where the strengths and weaknesses of each are - not to mention making me a better programmer by expanding my horizons.

Late last year I started working on a new programming project in my spare time - Yahtzee for Mac. While I realize that I'll neve be able to release it due to liscensing issues, I still enjoy working on it in my spare time. If nothing else, it gives me more experience and practice with Cocoa programming on OS X.

I've made pretty good progress so far. A single player can roll five dice, select which ones to keep, and roll again. Once they have the numbers that they like (or have rolled three times), they select which score to use for the roll There isn't an end game as such, but it does pretty well for a single player experience.

My current task is to add multiplayer support. While I wrote the single player part in a week or so, this is talking much longer. Currently, while multiple players can "play," taking turns isn't enforced. That's what I'm starting to work on now.

When a player starts the game as a server, a new window is displayed listing all of the players that have joined the game, and their initial roll (in order to determine who goes first). The problem is displaying the array of player in both this and the main window (defined in sepaeate XIBs) at the same time. While the array displays fine initially, if a player joins the game acres the window is displayed they are not shown in the list. This is because a different NSArrayController is used, so it doesn't have any idea that a player was added to the array.

I'm not sure how to fix this yet, sadly. I can't bind one NSArrayController to another, and I can't use the same one in both windows since they are defined in different XIBs. I could move them into the same XIB, but that just seems wrong. It might work to set the binging in code, which would allow me to use the. same controller in both windows, but I'd rather use Interface Builder for this if I can, sice that is what it is meant to do.

I haven't had much luck using Google or StackOverflow to get an answer, either. Maybe if I plug away at it, something brilliant will come to me.

For the final piece on my series on using AppleScript to add information to OmniFocus, I'm going to describe how to send news items from NetNewswire. It ended up being a lot simpler than I thought that it was going to be.

The hardest part was getting an object for the selected headline. I must be missing something, because I couldn't find this in the NetNewswire dictionary, but a Google search turned up the solution: use the selectedHeadline property. It, in turn, has many properties, of which the title and URL are of particular interest. These values are set into variables to send to OmniFocus later:

tell application "NetNewsWire"
    tell selectedHeadline
        set t to title
        set u to URL
    end tell
end tell

From there, it's the standard code to create a new task in OmniFocus:

tell application "OmniFocus"
    tell default document
        set theProject to project "Follow Up"
        set theContext to context "Online"
            of context "Mac" of context "Home"
        set newTask to make new inbox task with properties
            {name:t, note:u, context:theContext}
        set assigned container of newTask to theProject
		
        compact
    end tell
end tell

And that's it!

While I'm by no means an AppleScript expert at this point, I definitely know enough to get stuff done using AppleScript. I think I'm missing something in that I couldn't find out how to get the currently selected headline on my own (and I have had similar issues with other research this week), but in time I'm sure that I'll get it down.

Yesterday, I described how to send the current tweet in Twitterrific to OmniFocus. Today, I'll show you how to create an OmniFocus task containing the URL and title of the current window in Safari.

At first, I thought that I wouldn't need to write this script, since OmniFocus can bring in the current Safari URL using the Clippings feature. However, in order for this to work, some text in the web page must be selected first (which will become the title of the task). I'm fine with always using the title of the page, so I don't need to worry about finding the title somewhere on the page to copy it.

Anyway, the URL and title of the active Safari window need to be retrieved with AppleScript. For some reason, the document object contains the URL, while the window contains the title. They can be found like this:

tell application "Safari"
    set u to URL of front document
    set t to name of front window
end tell

tell application "OmniFocus"
    tell default document
        set theProject to "Follow Up"
        set theContext to context "Online"
            of context "Mac" of context "Home"
        make new inbox task with properties
            {name:t, note:u, context:theContext}
        set assigned container of newTask to project theProject
        compact
    end tell
end tell

Today I'm going to describe how I can send the contents of the currently selected Tweet in Twitterrific to OmniFocus using AppleScript.

The first step is to pull the necessary information from Twitterrific. In my case, I'm going to use the name of the poster as the title of the task, with the text of the Tweet as the note on the task. While this seems a bit weird at first, I couldn't think of a better way to handle it - while the content makes sense as the title at first, links in task titles aren't clickable. Plus, that could result in some pretty long tasks titles. This seems like the most automatic way of handling the situation.

In Twitterrific's AppleScript dictionary, there is a tweet object that contains a variety of information about the tweet. Today, only two properties are of interest: text (which contains the content of the tweet) and user name (which is the real name of the poster (and yes, AppleScript properties don't have to be just one word, which takes a bit of getting used to)).

For me, the hardest part of understanding AppleScript is the syntax. While it is my understanding that Apple developed it so that AppleScript would be easy for most anyone to use, for me this is hardly the case. Maybe it is because I'm use to more traditional programming languages, but AppleScript's English-like syntax strikes me as rather odd. I'm starting to get used to it, finally, but it's extremely different from any other programming language that I've used.

To pull information from a running application, you tell the application what information you want. To get the text of the currently selected tweet, the following AppleScript will do just that:

tell application "Twitterrific" to set tweetText to the text of selection

This sets the contents of the variable tweetText to the value of the text property of the currently selected tweet.

If multiple actions are desired against the same application, then you can use a multi-line tell:

tell application "Twitterrific"
    set tweetText to the text of selection
    set tweetPoster to the user name of selection
end tell

In addition to getting the content of the tweet, it also sets the real name of the poster to the tweetPoster variable.

Now that we have the information that we need from Twitterrific, we need to send that information to OmniFocus by creating a new task. This is a bit more complicated, but not too bad.

All projects, contexts, and tasks in OmniFocus are saved in a document. The document that is opened by default when running OmniFocus can be retrieved by getting the value of the default document property of the OmniFocus application. Since we're going to be asking multiple things of the document, I'm going to create a multi-line tell for it:

tell application "OmniFocus"
    tell default document
        -- Interact with the document here
    end tell
end tell

(In AppleScript, -- is the comment character. Any text after that line is treated as a comment, and is ignored when the script is executed.)

In order to create a task, the following information is needed:

• Task Name
• Context
• Project
• Notes

We have the name and note for the task already - those are stored in the tweetPoster and tweetText variables, respectively. The context and project for the task can be retrieved from the OmniFocus document that we just set up.

First, the project. Each OmniFocus document has a projects collection that can be used for this. In my case, I have a "Follow Up" project that I use to keep any tasks that I want to look into later. To get this project from AppleScript, use the following:

set theProject to project "Follow Up"

To use a different project name, just change the text in the quotes.

Getting the context can be a bit more tricky. If you want to use a top level context (that is, a context that is not within another context), then it is as simple as getting the project, only replace project with context:

set theContext to context "Online"

However, in my case, the context that I want to use is within two other contexts. To get my context, you just chain them together:

set theContext to context "Online" of context "Mac" of context "Home"

Now that we have all of the necessary parts of the task, we can tell OmniFocus to create. This is done using the make action:

set newTask to make new inbox task
    with properties {name:tweetPoster,
        note:tweetText,
        context:theContext}
    set assigned container of newTask to theProject

(You do not need to have the first two lines on separate lines - I only wrote it that way so that it would look nicer here.)

The project of the new task can't be set using properties, but instead it is set to the assigned container property of the task.

While the new task is now created, it is still sitting in the OmniFocus Inbox - even though it has a project and context defined. While you could press the Clean Up button manually in OmniFocus, that isn't very automatic now, is it? ;) Thankfully, this too can be accomplished via AppleScript:

compact

And that's it! The contents of the current tweet in Twitterrific are now safely stored in OmniFocus to be processed later.

Click the "more" link below for the full text of the AppleScript described here. If you have any questions, comments, or suggestions about this, please don't hesitate to ask. :)

I've been meaning to look into AppleScript for some time now, but I never had a reason to. This past week, I finally motivated myself to do so, since I had a goal in mind.

When I was reading my RSS feeds using Google Reader, I would star an item that I wanted to read later instead of right then. Once I had some time, I would go to my Starred Items and then read through them, or act on them as appropriate.

I have a similar process for Mail - if I wanted to remember a message for later, I would flag it and then go through the Flagged Items folder as necessary.

Once I started using Twitter, things got a bit more complicated. I finally settled on using Twitterrific as my Twitter client. While I does have built-in support for adding Favorites (which I would treat like Starred items in Google Reader), it has no way of listing my Favorite Tweets. This requires me to remember to go to the Twitter website, and then go to my Favorite Tweets section. Not the easiest thing to do in the world.

I realized that there must be a better way to handle this, since it was easy for me to forget that I had Favorite Tweets that I needed to go through. Since Twitterrific has an AppleScript dictionary, I wondered if I would be able to pull out the contents of the current Tweet and store that somewhere else on my computer where I would be more likely to remember to go through the tweets there.

OmniFocus seemed like the most logical place to put this information, since I keep the rest of my to do items there as well (with the added bonus of getting them automatically synced onto my iPod touch, as well). Since OmniFocus also has an extensive AppleScript dictionary, this approached seemed to have promise.

This then lead me to thinking about how to move my other to do/follow up items into OmniFocus as well. Mail shouldn't be a problem, but Google Reader would be another matter entirely. Since I use Firefox as my web browser (which doesn't much at all in the way of an AppleScript dictionary) this could be problematic. However, I've been thinking of switching back to Safari for a few weeks now, so this might just be enough to push me over the edge.

I have never done anything with AppleScript before (aside from copying some code into Script Editor and saving it), so this should be quite the learning experience for me. To help others out in the same situation, I am going to post the scripts that I came up for to pull follow up items from Twitterrific, Safari, and NetNewsWire into OmniFocus so that all of my information will be in one centralized location.

I hope that you will enjoy this series as posts as much as I had fun making them. :)

Welcome to my blog!

I have decided to start blogging once again. I was quite into blogging a few years back, but after sometime I just got out of the habit of posting, and one thing led to another, and I just wasn't into the whole blogging thing anymore (I think that a certain game might have helped matters, as wel). In any event, I've been thinking about getting back into it again, so I figured I might as well give it a go.

It definitely helped that M (my wife) found a great deal on hosting, too. :)

I'm not exactly sure what I'll post about here, but likely it will be things that interest me. I'm a computer programmer, and even though that is my day job, I program for fun on my own too, so I'm sure that will be a big part of this. I also enjoy video games of the computer and console variety (I have a Wii and DS from the current generation), so those topics will be on my mind, too.

There isn't much here yet, but there will be in due time, I am sure. Have a look around, and if you have any questions, comments, or whatever, feel free to leave me a comment. :)