Programming, Technology, Mobile and whatever else comes to mind.

I was working on a solution for storing a list of types that were being filtered by an NSFetch request from Core Data that the user gets to select. Each item had a type value that was one of 4 set strings. I decided to store an NSDictionary in NSUserDefaults with corresponding key:value pairs of (@”typeName”:@yes/@no).

What I wanted was a way to get an array of the keys from my dictionary that were enabled, so i could use:

My first thought was to use an NSPredicate on the dictionary to filter the dictionary, but while I could write one that would filter the keys down based on the name of the keys, I couldn’t come up with something that would filter the list of keys based on the value of the keys and return the key names.

I was sure there was some niceness in Objective-C that would do what I wanted in a nice package though. I asked on StackOverflow and was at first told that my solution was “the [standard] decision” by one member. I was slightly disheartened by that response but left the question open for a bit longer.

Luckily someone came in with exactly the type of solution I was looking for, using blocks:

Nice, clean, simple… exactly what I knew was possible but couldn’t find the function. Admittedly I don’t use blocks over other methods as often as I could, but if this doesn’t incentivize me to learn more about where I can implement them, I don’t know what will!

Feel free to comment with any improvements or alternative solutions you may have.

Over the last couple months I’ve been spending time teaching myself a new keyboard layout called Dvorak. Most people I talk to are completely unaware that there are other English based layouts that have been developed besides the QWERY standard, which is no surprise considering the prevalence of QWERTY and the obscurity of Dvorak. For those that are unfamiliar, the quick explanation is that it is a keyboard layout where the keys are positioned for optimal efficiency when typing the English language. Surprisingly, QWERTY was developed to be inefficient so that typists wouldn’t jam mechanical typebars like those used below.

Make note of the bars attached to the keys too, it is because of these bars that modern day keyboards also derived their slanted placements (instead of having keys directly above or below one another). A friend of mine brought all this up to me years ago when I was in high school, but back then I never had much incentive to switch: I already knew QWERTY, my days were spent at school using a pen and paper, and at home my computer use was mostly allocated to videogames, and changing a layout would ruin my key bindings!!!

It wasn’t until I started working as a programmer that I realized I could be doing my hands a big favour for the long run by switching to this efficient keyboard layout – it’s actually a prescribed treatment to help Repetitive Stress Injuries on people who get injured from typing too much. My fear for my hands/wrists was only solidified after reading a post from Scott Hanselman about his Programmers Hands. So, I decided it was time to do what my friend had been telling me for years and learn Dvorak.

It’s easy to physically switch, you don’t need any new hardware, just a quick setting change in Windows and you can be typing. Then all you need to do is A) learn where the keys are (I used lessons in the free program Type Faster) and then B) do it enough to have muscle memory. After about 3 weeks of going though the lessons and learning the keys in the evening, and another 3 weeks actually typing with the layout at home/work, I was typing at a very reasonable pace on the new layout!

The problem was, now that I was getting good at Dvorak and used it for about a week strait, I couldn’t type QWERTY to save my ass. I sat down at my girlfriends computer and went to type something, and literally had to hunt and peck for the right key. Every time I tried to look away my fingers went to the keys I’d just spent weeks ingraining into my brain. It got to the point where I had to go to my old computer and bring up Type Faster and do the last lesson for QWERTY to remind myself where the keys were. After about 15-30 minutes my old muscle memory took over and I breathed a sigh of relief as I could type QWERTY again.

But now I had a new problem; I couldn’t switch back and forth between QWERTY and Dvorak easily at all. I tried a couple more times to go back and forth, but every time it took me about 15 minutes after each switch before I could type whole sentences. To make matters harder, I had just got a new new mechanical keyboard without key-markings.

You might be wondering what would possess someone to do such a thing, and besides being totally vain and elitist, I thought it might also help my touch-typing of the number and symbol keys to be forced to learn them on muscle memory.

The straw on the camel’s back was when I tried to sit down at one of my boss’s computer and type some code, and I couldn’t. Sure if he’d given me 15 minutes to fumble around with the keys looking like I’d never typed at all before this very moment I would have eventually got the hang of it again, but that wasn’t an appealing option (especially since I was supposed to be typing a quick fix). That was when I decided my new layout fanaticism wasn’t going to work. Until I can figure out how to switch over between the two layouts instantly, I have to say goodbye to Dvorak.

I’ve heard only using a Ergonomic keyboard with Dvorak and standard keyboards with QWERTY will help the context switch, so that is what I will try next. If that doesn’t work, then I’ll just have to remember Dvorak as a delightful dream, where whole sentences were typed with barely no movement from home row.

If you have the chance to give Dvorak a try, and don’t often use other peoples computers or figure out how to context switch (please leave a comment if you have the answer!) then I HIGHLY recommend going for it. It truly is a marvel to type with once you get the hang of it.

I recently started writing an app for the Windows Phone 7 OS that ended up using the CameraCaptureTask to get an image from the user and everything in the emulator was working just fine, but it just took a blank picture.

“Great!” I thought. Now lets use an actual device to try out a real picture and do some debugging.

No go.

See, the problem is that you can’t use media functions like CameaCapture with Zune running and the device connected… but to debug your application you need the Zune software running and the device connected…

“Great…” I thought.

After a bit of research I stumbled upon something called Desktop Passthrough, but that was for older devices. I did find the solution in WPConnect, a tool released in the Windows Phone 7 Developer Tools October 2010 update which allows you to connect your device to the computer and debug without using Zune, so you can do stuff like take debug Camera tasks!!!

All you need to do is:

Connect your phone to the computer and make sure Zune can see it

Close Zune

Open a command prompt (cmd.exe) and browse to Program Files (x86)Microsoft SDKsWindows Phonev7.0ToolsWPConnect

Enter the command WPConnect.exe

Note: Be sure to run the command from the command prompt so you can see that it connects correctly, or what the error message is.

You should now be able to debug your application without the Zune software running! Check out the link above if you need to troubleshoot any issues.