Using AppleScript and USB Overdrive to rewire my external keyboard

So I’ve recently made an investment in the Kinesis Freestyle 2 for Mac – an amazing keyboard that is supposed to be ergonomic and very friendly for your hands to type.

After playing it for a while, I really like it except for one thing – when I press the prev, play/pause and next buttons, it will always bring up iTunes even if Spotify is open. This is very annoying as I’ve said goodbye to iTunes long time ago and have migrated over to Spotify. It is also different from the default behavior of the Mac’s native keyboard. If I press these buttons on the default keyboard while Spotify is open, it will just play Spotify. Same goes for QuickTime Player.

This annoys me enough that I spent the past 2 hours looking into a solution. I’ve found one that is sort of a workaround that works well for me for now, so I thought I should leave it here.

First, I use USB Overdrive to manage the behavior of external mice and keyboards. It is just an incredible piece of software in terms of the amount of control it gives you.

It is almost perfect for what I need to do, except that for Media keys, it only allows mapping to iTunes commands.

To gives Spotify any sort of priority, I have to use the ‘Execute AppleScript’ feature. Even for someone who’s relatively good at programming, this was scary to me at first. The thought of programmatically alter my Mac was a scary thought, and a downhill move I thought. That is until I learned how friendly AppleScript is. Here’s a little code I wrote to get the play/pause button do what I want:

# prioritize Spotify first
						if application "Spotify" is running then
						    tell application "Spotify" to playpause
						
						# if Spotify isn't open, QuickTime Player is second on the list
						else if application "QuickTime Player" is running then
						    tell application "QuickTime Player"
						        tell document 1 to if exists then
						            if playing then
						                pause
						            else
						                play
						            end if
						        end if
						    end tell
						
						# only play iTunes when nothing else is open
						else if application "iTunes" is running then
						    tell application "iTunes" to playpause
						
						# if no media app is open, start Spotify and play some tunes!
						else
						    tell application "Spotify"
						        activate
						        delay 2 -- I added this in because having play right after activate doesn't quite work. It turns out the delay gives it a nice fade in effect
						        play
						    end tell
						end if
						

This is an opinionated solution to what to do. It is also limited to currently 3 apps right now, so it’s probably not as versatile as the built-in keys. However, for now, these are the 3 apps I use the most. If you use “VLC”, then just replace “QuickTime Player” with that, or put it before QuickTime.

Here are another example of what I did with my previous button. The next button is pretty much the same.

if application "Spotify" is running then
						    tell application "Spotify" to previous track
						
						else if application "QuickTime Player" is running then
						    tell application "QuickTime Player"
						        tell document 1 to if exists then
						            step backward
						        end if
						    end tell
						else if application "iTunes" is running then
						    tell application "iTunes" to previous track
						end if
						

I hope this is helpful to someone out there who’s looking to get more power of their keyboard and mouse mappings. As you can see, there is a limitless number of things you can do with this.

One more note, to start writing AppleScript, a good place to start is open the ‘AppleScript Editor’ on your Mac. Once you’re there, you can open the Application Dictionary through the shortcut cmd + shift + O or “File -> Open Dictionary”. Have fun!

When to use INDEX in MySQL

A great article explain when and how to use INDEX in MySQL. Want to leave it here so I could easily find it later. View article.

RESTful WordPress

WordPress is an incredibly powerful and user-friendly web platform. It is loved by both developers and users alike. WordPress’s polished wp-admin and Dashboard are probably one of the biggest reasons WordPress is chosen by many people as their go-to CMS. As a developer, I pick WordPress over other CMSes whenever I feel my client need a friendly CMS to manage their rich content in a smart and usable way, which turns out to be quite often.

In the State of the Word speech in 2012, Matt Mullenweg outlined a vision for WordPress with an even bigger emphasis on making wp-admin more user-friendly. I think this is a great direction to follow, given how User Experience has become the focal point in web development work in the past couple of years. In the same talk, Matt also shared his vision for WordPress being used more for web applications. Now this really got me off my seat.

Imagine a day when you are able to query every single bit of information that is on your WordPress site, from each Custom Post Type (CPT) and its custom meta fields to every user meta data. This will transform WordPress into a true web application powerhouse, with RESTful APIs on the back end and a stellar front end interface. The introduction of the REST API in JetPack 1.9 is a big step in that direction. However, there’s still much to be done.

A few months ago, I started working on a mobile application with a few friends. We wanted to make a nice tool for students to create meaningful interactions through a small on-campus social network. During the architectural design process, being a true WordPress developer, I urged the group to use WordPress as our backend. I was very optimistic that we could turn WordPress into a RESTful API while leveraging on the current familiar theme templates to rapidly build and deploy a web app version. We could then focus more of our time on designing and making the iOS app more user-friendly. Unfortunately, with a 3 month deadline in mind, we decided against using WordPress because the Jetpack REST API only supports regular post types and not CPTs (we also decided not to build an independent REST API because that would take even longer). This was a bummer because with a secure and mature user management system and a tested framework for interacting with the database in place, coupled with many plugins for optimization, WordPress would be the ideal candidate for small teams like ours to deploy mobile and web applications that rely on a solid backend in a relatively short period of time.

This experience led me to believe that there is a huge potential for making the WordPress Core RESTful. With work already done in Jetpack, I think that we’re already more than half way to achieving this goal. I don’t think the rest of the way is easy (or otherwise it would already be done), especially in trying to extend Core while maintaining it backward compatible. Nonetheless, being able to achieve this will put WordPress to the front and center of a developer’s toolkit in building awesome applications.

There are many benefits to this.

Despite these potentials, a quick search for REST API plugins from the WordPress plugin repository revealed only a couple of plugins which have not been maintained for more than 2 years (highly rated plugins nonetheless). I am not certain what the reason for that would be, but there have been definitely a lot of changes in the WordPress Core for the last 2 years. My dream right now is to be able to spend a few months focusing on building a more fully featured REST API for WordPress.

It would not be easy to do that all by myself, but if I were in a team of really talented and experienced developers who know WordPress in and out,the process would be a lot more fun and productive. Another important thing is knowing how to test the features and make sure it is scalable. These are the things the good people at Automattic do really well. But more than anything else, working on this would be a great learning experience.

tinhnguyenlonghoa.org launched!

tinhnguyenlonghoa.org has finally launched this past week.

It is my first work for a non-profit, and I am very proud to do my part and help out a friend. I’ve known Minh, the project director, for a while. We did a community service trip in Vietnam together more than 4 years ago, not too different from Long Hoa. Since then I’ve gained a lot of respect for him and his dedication to community service.

This site features a simple, minimal design with a focus on pictures as a way to tell the story. Here are some nice aspects of the site:

This is also my first site in Vietnamese, which imposes an interesting restriction on fonts. There are only 3 fonts from Google Web Fonts that fully support the Vietnamese characters. I lucked out as Open Sans, my favorite font, supports the Vietnamese language.

Working with Minh has been a very pleasant experience. He is always on top with his part of the project, providing content and images very early on. This allowed me to have a good grasp on the content and design to maximize their impact. He is also flexible in working with me in developing solutions for various ideas.

There are certain areas of the site that could be further optimized/ revisited for better performance and user experience. Hopefully these will be tackled on soon as the site gains more traffic and has more user testing.

This site is also the first to be hosted with pagodabox (wow! there are many firsts with this project!). I really like the object-oriented approach to hosting and the version control (git) built in from the start. However, I had to jump through a few hoops to get WordPress working correctly on there, such as configuring writable directories, syncing with local development (.htaccess for permalink) or WP Super Cache plugin – these warrant their own post.

Enjoy looking through the site (my apologies in advance for the cryptic and weird Google Translation – Google definitely needs to work on their translation machine for English – Vietnamese) and let me know if you have any suggestions/ comments.