But now, thanks to this nice stackflow post, I now know how to do it.

First of all, there are two different scenarios. The first case is when the collaborator you were sharing with, no longer needs their copy of your branch. They might want to remove the branch to tidy up their local repo. This can be done with the following command:

git branch -d <branch>

or to follow in the steps of my old example:

git branch -d superCoolFeature

The lower case -d option will only remove the branch if the branch has not been merged or somehow saved. You can force the removal with the upper case -D option if you're feeling more forceful.

The second case is when you are done using and sharing your branch. You probably have concluded whatever you were trying to do with this branch and merged the result back into master. At this point you might want to remove the temporary branch not only locally, but remotely as well. That can be done with:

git push origin --delete <branchName>

or again, in the case of my example:

git push origin --delete superCoolFeature

And the branch should now be gone from the remote repo. To remove it from the local repo, do the same "branch -d" step as your collaborator did in the first case. Needless to say, please make sure you only erase a branch you were done with.

The problem is I'm lazy and I don't really want to read a book or website on it. I just want to solve some little problem I might have that needed scripting. You know, just take a sample script and play with it to do something useful to me.

So... after lamenting about this, my friend Mike sent me a sample python script to play with. The sample code he sent me was basically a simple grep clone.

Aha!

I have always wanted a grep-like tool that gave me more context. I know that you can tell grep itself to provide more context, but as far as I know, you can only specify the number of lines before and after your match you want included. This is realistically all one might need for most cases, but I wanted more.

So that is what me new script does. (You can find a copy of my script here) You provide three search terms:

• trigger: the main term you are looking for.
• begin: something pattern that describes the beginning of the block you want to print out.
• end: The end pattern for the block.

For example: I exported an xml file from my iTunes library that describes all of my media. I can now search for the name of an author for example and get The full dictionary entry for the song. (output listed below.)

I hope this is useful to some one else or at least serves as a starting point for your own exploration of python.

% triggerGreppy Tacuba "<dict>" "</dict>" Library.xml

    <dict>
        <key>Track ID</key><integer>7587</integer>
        <key>Name</key><string>Bar Tacuba</string>
        <key>Artist</key><string>Café Tacuba</string>
        <key>Album Artist</key><string>Café Tacuba</string>
        <key>Album</key><string>Café Tacuba</string>
        <key>Genre</key><string>Alternativo &#38; Rock Latino</string>
        <key>Kind</key><string>MPEG audio file</string>
        <key>Size</key><integer>4703278</integer>
        <key>Total Time</key><integer>233221</integer>
        <key>Track Number</key><integer>13</integer>
        <key>Year</key><integer>1992</integer>
        <key>Date Modified</key><date>2010-09-27T20:44:49Z</date>
        <key>Date Added</key><date>2010-08-03T04:30:10Z</date>
        <key>Bit Rate</key><integer>160</integer>
        <key>Sample Rate</key><integer>44100</integer>
        <key>Normalization</key><integer>2381</integer>
        <key>Artwork Count</key><integer>1</integer>
        <key>Persistent ID</key><string>E467DC7506CA7184</string>
        <key>Track Type</key><string>File</string>
        <key>Location</key><string>file://localhost/Volumes/Attic/Music/iTunes/iTunes%20Music/Cafe%CC%81%20Tacuba/Cafe%CC%81%20Tacuba/13%20Bar%20Tacuba.mp3</string>
        <key>File Folder Count</key><integer>4</integer>
        <key>Library Folder Count</key><integer>1</integer>
    </dict>

---------------------
    <dict>
        <key>Track ID</key><integer>7753</integer>
        <key>Name</key><string>Las Flores- Cafe Tacuba</string>
        <key>Artist</key><string>Various Artists</string>
        <key>Album</key><string>Hace Calor  Pop &#38; Rock</string>
        <key>Genre</key><string>General Rock</string>
        <key>Kind</key><string>MPEG audio file</string>
        <key>Size</key><integer>2752097</integer>
        <key>Total Time</key><integer>136881</integer>
        <key>Track Number</key><integer>3</integer>
        <key>Date Modified</key><date>2010-08-19T05:00:31Z</date>
        <key>Date Added</key><date>2010-08-19T04:58:27Z</date>
        <key>Bit Rate</key><integer>160</integer>
        <key>Sample Rate</key><integer>44100</integer>
        <key>Play Count</key><integer>1</integer>
        <key>Play Date</key><integer>3370023481</integer>
        <key>Play Date UTC</key><date>2010-10-16T01:38:01Z</date>
        <key>Normalization</key><integer>2518</integer>
        <key>Persistent ID</key><string>52FAE1944A13F3EE</string>
        <key>Track Type</key><string>File</string>
        <key>Location</key><string>file://localhost/Volumes/Attic/Music/iTunes/iTunes%20Music/Various%20Artists/Hace%20Calor%20%20Pop%20&#38;%20Rock/03%20Las%20Flores-%20Cafe%20Tacuba.mp3</string>
        <key>File Folder Count</key><integer>4</integer>
        <key>Library Folder Count</key><integer>1</integer>
    </dict>

---------------------

[I removed furthere matches for brevity]

Every now and then, I work an experimental feature. When I start on it, I'm not sure if it will work out and wether or not it should make it into the master branch someday. In those cases, I will make a new local branch to play with the idea. Lets say I called it superCoolFeature. At some point of the development of this feature, I might need to share this branch with one of my team members. How do do I do that?

Well... I just figured that out recently and I thought I'd post it here in order to remember it the next time I need it.

It turns out to be a two step process. First you need to push your local branch onto your remote (usually your remote is origin, but you can type git remote to see a list of remotes.) After that, you will need to make your local branch track your remote branch. Here are the commands that do just that:

Note: You need to be on a different branch before you execute the second command, so you might want to do a git checkout master first.

git push origin <branch>
git branch -f <branch> origin/<branch>

or to be more specific to my example:

git push origin superCoolFeature
git branch -f superCoolFeature origin/superCoolFeature

Once you've done that, you should have a new branch on your remote and your local branch should track it. Now you need to tell your teammate to create his own local branch that tracks the remote branch. They can do that with the following:

git branch -t <branch> origin/<branch>

or again, more specifically:

git branch -t superCoolFeature origin/superCoolFeature

As always, you should proceed with caution. Have backups of your repo before performing a new command for the first time (In general backups are a good idea, regardless of what you're up to.)

Also for future reference, here is the list of blog post on the subject I found while investigating this:

• http://www.zorched.net/2008/04/14/start-a-new-branch-on-your-remote-git-repository/
• http://coders-log.blogspot.com/2009/05/creating-remote-branch-with-git.html
• http://markelikalderon.com/2008/08/26/pushing-and-tracking-remote-branches-with-git/
• http://gitready.com/beginner/2009/03/09/remote-tracking-branches.html

About ten months ago, I had a sharp pain in my wrist. In that occasion, it happened after an accident while I was playing racquetball. I visited the doctor and he said I should wear a wrist brace. I did so on and off for about six to eight weeks. While I was in pain, I noticed that the slew of keyboard shortcuts I use on a regular basis were killing me (in particular those involving the control modifier, so I swapped control and caps lock.) I did get better and life came back to normal and stopped using the brace.

A few weeks ago, my left wrist started bugging me again. This time I remembered I had gone through this five years ago (I know, my memory is legendarily crappy.) That time the pains went away when I started using a Microsoft ergonomic keyboard. I used it until I switched to using mac laptops. So now that the pain was starting up again, I decided to get a new ergonomic keyboard.

Choosing a model

I could have gotten another Microsoft keyboard, but I was never crazy over the build quality of my last one (which BTW was not a USB model so I couldn't use my old one.) and besides, the Microsoft keyboard is obviously very biased towards Windows (can't blame them for that.)

So after investigating a bit, I found the Kinesis Advantage Contoured Keyboard. There are several less radical options out there, even Kinesis has some split in two halves keyboards, that are otherwise rather "normal." I decided that if I was going to get used to an ergonomic keyboard, I might as well get one that goes out all the way and redesigns the whole thing from scratch. (What can I say? I believe engineers do their best work when they can rid themselves of legacy constraints.) The only legacy that I decided to keep was the Qwerty layout.

Foot Switch

So I just got and I'm typing on it right now. It feels freaking weird. But first things first. I got the regular Advantage model in black. I could have gone for the Pro, but I wanted to get the three-way foot switch. I found the websites a bit confusing. Clearly, the Pro model is differentiated by its silver color and expanded macro memory, but what I missed for a while was the fact that it also includes a single-way foot switch. I was set on trying the three-way foot switch and I could not find a way online to upgrade to that with the pro without paying for a superflous one-way switch.

If you decide to get the keyboard and the foot switch, make sure you don't buy the more expensive USB foot switch. The USB models are standalone, and could work in theory with any other keyboard. If you get the pedalboard that only works with Kinesis keyboards, you will save some money, but I also believe you will enjoy tighter integration. The model that I got connects to the keyboard with a telephone style cable (RJ-45?) With this model, you supposedly can reprogram the foot switch, just like you can any other key.

First Impressions

OK, so right off the box, I have to say I'm happy with my perceived build quality. It feels solid. We shall see if it remains like this over time.

Hooking it all up was pretty straight forward. It has a little USB hub in the back with two ports. I hooked up my old mouse's wireless dongle. The ports are kind of in a cave underneath the keyboard. This is perfect for things that don't get moved around (like my mouse wireless link) It probably would not be very useful for memory sticks and such.

Right now, typing anything requires my full concentration. I'm sure that this will improve over time (in fact, just as I write this post I can start to feel the difference in my head.)

A lot of keys (mostly modifiers) get moved over to the thumbs. I expect this to be big win on the long run, but right now I feel like I'm all thumbs (pun fully intended.) In particular, my right thumb is in charge of space and my left thumb does backspace (or delete in true mac parlance) Unfortunately, I'm used to hitting space with my left thumb so now instead of getting spaces between words, I keep nuking the last letter of the previous word.

This keyboard is carefully crafted with the motion of every finger in mind. It certainly feels that way. My fingers feel less stressed than they usually do when typing something this long (sorry about the length of this post, but I need the practice.) But there is another side effect that I did not anticipate: this keyboard hilights all my bad typing habits. Apparently, I tend to hit some characters that are in the pinky column with my ring finger. The problem is that, since the column is calibrated for the pinky, using the wrong finger results in much hilarity.

I can see this will take a while to get used to. It probably would go easier if I were a better typist. I tend to depend too much on occasionally seeing the keys, that will get me into trouble with this keyboard. I do think think that sticking it out with this keyboard will make me a better typist.

So far I am liking using the foot switch for shifting, but I'm not sure if I will eventually get to use all three switches. Right now I'm working hard just to remember one. Only time will tell how well modifiers work for me on my thumbs. Right now, I can already feel my thumbs growing tired.

Finally, I can also feel my back starting to get tired. I believe that my chair doesn't provide me enough height (besides it's kind of broken.) I also think that I need to raise my table about an inch or two. This keyboard demands good posture. Again, that feels weird right now, but I believe it will bear fruits in the long run.

Sorry, for the super long post. I do plan on writing a follow up after I've had a few days with it.

Today, marks the last day RetroSketch will be featured in the App Store. It has been a very nice ride. Once again, I find myself grateful.

I released RetroSketch to the App Store last week. I am very proud of it's minimal interface. But I have found a major problem with its lack of chrome– I have no place to thank all the people who have helped me along the way.

First and foremost I need to thank God for the opportunities I have received and the talents I was given. I also need to thank my wife and kids. They have supported me all along and have endured many challenges along the way. None of this would be possible without them.

Next on the list are all my friends and colleagues that have helped me out. In particular I want to thank Rob Rhyne, Mike Ash, Mark Boszko, Sandy Wang, Guy English and everyone at NSCoder Night DC. If it wasn't for all these fine folks, RetroSketch would be a slow, pokey, ugly, barely usable pile of code plastered on a hard to read website. (Trust me on this one.)

Finally, I want to thank all of my good friends scattered over the internet. I can not begin to explain how deeply moving it has been to see the outpouring of support. The picture next to this article is something I never expected to see. What can I say?

THANK YOU.

I could write about how I wrote all this code to doctor the results of atan() depending on the quadrant of the angle, how I computed the distance of a touch from the center of knob, and how I threw away all of that as soon as Mike Ash told me about atan2() and hypot().

I could also write about how having two instances of the same knob class is a bad idea, how their events arrive independently and result in staircases when you try to draw diagonals.

But no, instead I will tell about my first experience with UI design. It's kind of funny, I figured I really didn't have much design work ahead of me with an interface that consists of a grey backdrop and just two knobs. I was wrong. (BTW coming up with a couple of marketing screenshots for a UI that consists of two knobs on a grey expanse is really fun)

The Early Placeholders

As soon as I started hacking the code, I knew I had to draw something on the screen to make sense of touch information. I just needed something to show me the boundaries the software was expecting. So I simply drew a red circle at the outer edges of the knobs.

I also drew a solid blue circle in the center of the knob which represents the dead area. I needed that to avoid the scenario where a user goes straight across the center. If the knobs were sensitive in the center, they would register that move as a sudden 180 degrees twist of the knob, triggering an ugly jump on screen.

In this early test you can see I was also trying out various ideas. The rects in the center were a comparison between 1 pixel wide lines and 2 pixels (2 pixels won). The label at the top was there to display realtime test data (angle, relative movement, etc.) reported by the knobs.

The Ellipse around the edge allowed me to see into the background (an very early rev of the texture). More importantly, notice that both the aluminum layers and the screen edge were casting shadows at this stage of development. Eventually I had to turn off these shadows for performance reasons. That was the hardest tradeoff I made in the project; those shadows are the real reason that lines in the mechanical device look black in the first place. Without these shadows, I had to artificially darken the texture to make up for it (a poor solution). In the future (if this ever turns a profit), I would like to re-write the whole thing in OpenGL to implement the shadows as shaders.

Finally, notice the placement of the knobs. Placing them in the bottom corners seemed natural at the time, but of course that changed as soon as I had an actual device in my hands.

The RoboSketch Era

I knew all along the placeholder was temporary, but after seeing it for so long I had trouble imagining anything else. I had a series of issues in my head that were complicating matters.

1. I decided early that drawing a border to house the knobs would look silly and take away screen real estate. The lack of border meant I could not use pictures or renditions of real world knobs. Real world knobs floating over a "glass" that supposedly houses moving parts seemed to work against the illusion I was trying to create.

2. I wanted large knobs. A large radius gives the user more control, so I wanted the largest knobs I could fit. Which conflicts with...

3. Knobs floating on the screen cover up the user's drawing area. The problem might be mitigated by making them transparent.

4. The knobs need to be as self explanatory as possible.

So this is what I came up with:

As you can see, I was seriously confused at this point. I actually thought of going with this design for a moment. I thought that by making them futuristic I could somehow justify having them float above the screen defying all logic. I still had to make them transparent, which really didn't make sense either.

Worst of all, having futuristic knobs clashed with the RetroSketch name. This is when I started to consider the possibility of renaming the whole thing to RoboSketch. To pull that off, I figured I should add some other futuristic features. I would have to implement a document model to save and load works in progress. I had justified not doing this, because the original retro device didn't, but a robo device certainly should. I also thought of adding some automation features to really earn the robo designation.

This RoboNightmare quickly got out of hand. Thankfully, my trusty friends at NSCoder Night DC talked me out it. It made no sense. I was turning my back on my main audience: the nostalgia market. So it was back to the drawing board.

On a side note, the discs in the picture above were Acorn'ed on top of a really old screenshot. If you look carefully, you can see two really large, but thin red arcs in both bottom corners. They are very transparent so it's really hard to see them. This was an early experiment. Placing the center of the knobs right in the corner afforded a huge radius, which in turn gave users detailed control (if you knew how it worked.) The tradeoff was that you could no longer turn the knobs in continuous circles. Problem was, people who tried it didn't get it. This confirmed two important design parameters:

1. The knobs need to be visible and obvious.

2. When in doubt, people tended to move their thumbs in circles. It is also interesting to note that this circular motion does not really come natural on the real devices with physical knobs. It is possible to go in infinite circles, but most people move using a series of short twists. Still, people seemed to assume that continuous circles were always the norm.

The Final Design

Disappointed, I went back to the placeholder design in my head. I was now convinced that making it transparent, but very red, would make it visible yet unobtrusive. Somehow being the only thing with color would set it apart visually. Instead of the thin red circles I started with, I would make them thick and represent the area of sensitivity. This meant, the blue area was no longer necessary, it would simply be empty space.

In addition, I wanted to add arrows pointing up and down on one knob and left and right on the other. I also wanted to add the text "UP" & "DOWN" along with the arrows, curved inside the knob. Finally I wanted the text and the arrows to spin around as the knob was turned.

I ran into trouble with this design. My trusty Opacity failed me for the first time. It could not curve the text the way I wanted it (Please don't take this out of context, I love me some Opacity somethin' fierce.) So at the next NSCoder Night DC meeting, I asked my friend Mark Boszko (a.k.a @bobtiki) to help me out drawing my odd shapes.

Instead of simply doing what I asked for, Mark questioned my design (Thank God!). First to go were the directions written into the knobs. Having copy as part of the knob design complicated matters (i.e. required localizations) and made things look cluttered. He also convinced me to get rid of the color. So we wound up with two grey doughnut-shaped knobs with straight double tipped arrows going either side to side or up and down.

That particular day, we happened to be graced by the visit of Sandy Wang (Mike Ash's lovely wife.) She suggested the arrows would look better curved. Both Mark and Sandy whipped out their laptops and started drawing knobs for me. (Have I mentioned how much NSCoder Nights in general rock? I recommend you find one near you)

Sandy's version is shown on the left and Mark's on the right.

Once I saw these, I knew this was it. The only thing left was to implement the design within the app. While both mockups were really good, they needed some retouching. I mostly tweaked the proportions to my liking. Problem was, I still had trouble drawing the curved angles in Opacity. So I decided to take matters into my own hands and draw the knobs from scratch using CoreGraphics.

These pictures show intermediate drawings generated live by the app using CoreGraphics calls. I used different colors on the graphical components to differentiate them. I could now change the angle and proportions of these knobs programmatically.

Turns out, this approach not only was fun for me, but it also gave me a smooth looking knob on the Retina display of the new iPhone 4. It also has the advantage that I could easily tweak parameters to make the knobs scale for both the iPad and iPhone versions of the app.

Final Touches

The last touch I added to the knobs, was the ability to fade out completely when not in use. When the app first launches, they are visible and remain so, until they are used. After they are used, they gently fade away. Touching anywhere on the screen makes them reappear momentarily. It is not necessary to wait for them to appear to start using them, just move the knobs as if they were there and it works as you would expect. By doing all of this, the knobs interfere as little as possible with the drawing. It also allows the user to take a snapshot using the built in capabilities. (just press the power button and the home button at the same time, snapshots are stored in the Photos app.)

It was a long journey for me, but it was well worth it. When it was all said and done, I was so happy with the result, it became the basis of both the product's logo and icon.

So that is the story of my rather simple knobs. I hope this post provides some useful insight. I also hope you have as much fun as I do twisting these knobs!

The size and shape of the iPad reminded me of those sketching toys and an idea got stuck in my head. I wanted a quick project that wouldn't take me from my main work, but I didn't want something so trivial it wasn't interesting. Just drawing a line controlled with two knobs didn't seem like an interesting challenge at first. So I spent some time playing with a real toy, and thats when I got inspired. To make it more interesting, I decided to recreate the way the physical object works; I wanted to simulate all the moving parts.

Spending a lot of time dealing with CoreGraphics is what made the project really compelling to me. The plan was to draw the inside of the box as a background, the vertical & horizontal bars moving the stylus casting shadows inside, and of course a layer of aluminum dust getting etched out by the stylus as it moves around. I figured most people would never notice all of these things, But I still thought is was worth doing it just for the fun of it.

So I did. And I'm done. Somewhere along the process the project went from being an exercise to becoming my first commercial app. I have no clue how it will sell, but it has been worth it already. Turning it into an app has forced me to do all the things related to launching an app that you always put off until the end (at least the stuff that I procrastinate, I'm sure everyone does something different). I had do to a website, create a corporate identity, create Ad Hoc distributions, and think of marketing in more concrete terms, etc.

Now that I'm reaching the conclusion of this phase, and while I still have the experience fresh in my mind, I set out to write a couple of blog posts about it. I want to share some of my observations and lessons learned. Here is a jumping point for those posts:

• A Tale of Two Knobs
• A Comparison of Diverging Philosophies (Coming Soon)
• Sensors: The Source of Wonderful Noise (Coming Soon)
• Sounds Easy (Coming Soon)

When all is said and done, I have to admit, I'm very excited about the whole thing.