Remote Pair Programming is a thing now that people do. Basically, it enables you to learn from and work with anyone anywhere, ever. You can do that thing we love to do (write code) with a diverse range of people. So let’s say you’ve decided you like this idea of getting out of the bubble of programmers you know well and you can’t to go see how the rest of the world lives. I’ll show you how to setup your Mac to do just that: 1. Install the tools you’ll need. You’ll need a few things here, easiest way to install them all is with Homebrew. brew install tmux Tmux lets multiple people use the same terminal session. This is way faster than relying on any screen sharing application and works even on less-than-epic internet. It also lets you do a bunch of fancy

The annual 360iDev conference just happened. I got to go, I enjoyed it very much. This time I wasn’t just an attendee, I joined the ranks of the great 360 speakers before me and attempted to do them proud. Soon my talk will be online and any of you who missed it can watch it. People I didn’t know told me they liked the talk. I even received a very nice email from a stranger thanking me for sharing my “success story”. It made me feel special. Twitter doesn’t have enough characters to thank the necessary people, so here we go: Mike Lee (@bmf): Thank you for your training. Judy Chen (@judychen): Thank you for being there. Collin Donnell (@collindonnell): Thank you for being there. Matt Henderson (@ghostM): Thank you for being there. Joe Keeley (@joekeeley): Thank you for the present and for being there. John Wilker

Since I couldn’t sleep tonight, I watched a presentation by this guy Zach Holman who works for GitHub. One tip he shares makes the output from git status much friendlier and I thought I’d share it so you don’t have to watch an hour of talking to find out about it. Instead of: git status try typing: git status -sb I went so far as to add this to my ~/.zshrc file: alias stat='git status -sb Basically, it makes the output from git go from something like this: sgoodwin:Parts/ (master\*) \$ git status [4:13:13] On branch master Changes not staged for commit: (use “git add …” to update what will be committed) (use “git checkout — …” to discard changes in working directory) modified: Parts/Parts-Info.plist modified: Parts/RWSAppDelegate.m modified: Parts/RWSListsStore.m modified: Parts/RWSListsViewController.h modified: Parts/RWSListsViewController.m no changes added to

Being a part of Appsterdam and trying again to run my own business has made me think differently about community. We grew up as nerds in school and learned to expect people would think we’re lame for the things we loved. We kept the things we loved to ourselves and looked for the few people on Earth who also loved those things as much as we did so we could share with them. Community is really not just about sharing with other people who are as deep into what you love. It’s also about opening up what you love to teach it and make it accessible to people who are interested. Community is about helping and getting help from those around you. With one hand we each should reach out for help and with the other we should reach back to help those behind us. Together, we all

Manually set location on an item?

When I was in college for electrical engineering, I learned to program objective-C for the Mac and that has now become my full-time job instead of engineering. The primary reason for pursuing a life of software development instead of engineering was the community. The developers I read about like Mike Lee, Daniel Jalkut, Gus Mueller, and so on made me so very excited to write software for a living. When I had the chance to meet them in person, along with other developers, I was even more excited. It was a community, a group of people who gave a shit about each other. When you choose to take shortcuts in your freelance projects, consider the effect on the community. When you whip out that singleton because it’s quick and easy (and we all know it’s a bad idea), think of the community. Think of the other developer who

It is becoming popular, especially in American tech culture, to encourage failure as a natural part of learning and a key to success. Humans fail in many casual ways to learn basically anything, even basic skills like walking. Failure in software is often expected on a very minor level. Maybe I’ll release this software and it will have a bug in it. Maybe I won’t get that job at that big tech company I applied for. The real failure in software is when all the work you have done falls apart so badly, largely from your own mistakes, that you lose everything you have spent years working for and have to beg for a place to sleep with your tail between your legs barely able to afford the shirt on your back. It’s the kind of failure they joked about in engineering school when discussing friends who

Web Developer Admits: Objective-C > HTML5 "It felt like hammering nails into in a wonky floorboard. We fixed one problem and another would pop up. We probably spent over 80% of our time fixing weird side-effect glitches and making our code work within PhoneGap correctly. But eventually we felt it was much better than our HTML mobile version of our site with transitions and notifications and so we launched it."

NSLog is a fun debug tool, but it has no place living in your version control history. Those of you who came from other languages and platforms might be used to a world where NSLog’s cousins, console.log, print, puts, and the sort were all you had to try to figure out what was wrong with your code. In Objective-C we have something much better: breakpoints. I think you get them in Python or Ruby or some such depending on the platform, but I don’t know about those, so I’m not talking about them. Here’s why the breakpoint is far superior to NSLog for your OS X and iPhone projects: They don’t get mixed in with your actual code. It takes one click or key combo to disable all of them and run your app without noise. You can’t forget to remove them. The

I would like to explain my hatred for commented-out code. Some might call this hatred extreme. They’re probably right. When I look at code interspersed with commented-out lines, I think of my own home which is often covered in dog hair. Now my dog is adorable, but he does in fact shed quite a bit. llvqqvm1Js1qfcjuuo1r1_500.png "He's not very big, but he has a lot of hair."" alt="Blynken" /> Now for me, in my home, by myself, this dog hair bothers me maybe 2% of the time I am there. Most of the time I don’t even notice it. For everyone else who comes over, however, they notice it all of the time. It’s on the floor, it’s collecting in corners, it gets in your shoes. They notice it and most of the time it bothers them. I don’t vacuum for myself, I

We have a new rule here at Roundwall Software: switches get stitches. Switches and if statements can easily pile up in a method and make it difficult for someone to understand what a method does. They also makes testing harder because tests that cover a method need to cover every possible branch path one might take through the code. Combining ifs and switches in the same method can quickly turn into madness. They’re not very object oriented either and we’re mostly writing code in Objective-C. We began with a challenge — can we write our code without switch statements? Turns out most of it could be replaced with clearer switch-free implementations without too much effort. A common use case for switches appears in a table view’s data source. When the table needs to support multiple section, some of these sections are static information or perhaps each section is

The point of sample code is to show you just enough code to communicate a concept. Sometimes code for a given demonstration (such as showing how to use parts CoreData or CoreText) requires a bit of boilerplate in order to show the concept. For example, let’s consider a sample project to demonstrate how to draw text in a spiral using CoreText. You would need code to allow you to actually display your CoreText example code. This code has nothing to do with what you’re trying to demonstrate, but it is necessary for the project to function. Now you don’t want to bundle your sample project with an entire production-ready, functioning app because that would be way more code than a developer wants to look at to learn about CoreText’s ability to draw in a spiral. This is a super cool feature, we want to make sure

New since iOS 5.0, we have a new weapon at our disposal for Core Data. External Storage lets you tell Core Data that you’re going to jam large data blocks (mp3s, pngs, whatever) into a property on your Managed Object. Normally you might say “Oh no! Why would you do that? Everyone knows you shouldn’t give large data blobs to Core Data! You should write them out as a separate file you idiot!” iOS 5.0 changed everything, it’s ok. Now you can let Core Data handle those large files and stop bothering to write all kinds of files and handling deleting them yourselves. Yay less code! If you check the Google or Apple’s docs, you’ll see articles explaining how to get things running, but what you won’t find is an explanation for how Core Data deletes those files. I setup a test

None We cannot emphasize strongly enough that first-cut code is not finished. Its good enough to sort out our ideas and make sure we have everything in place, but its unlikely to express its intentions cleanly. That will make it a drag on productivity as its read repeatedly over the lifetime of the code. Its like carpentry without sandingeventually someone ends up with a nasty splinter.

It was brought to my attention last night by my good friend, Collin Donnel, that using a fetch request to grab objects based on their objectID’s was much slower than simply using a for loop and the NSManagedObjectContext method -existingObjectWithID:error: to grab each object one by one. My initial response was supreme disbelief. How could this be true? I needed a break today from my pile of work to do, so I thought I would investigate and see what’s up. I started with a dummy project to create a scenario I could measure. You can find that project here. I just created a single-view app with 2 buttons, one to trigger a fetch with a predicate and one to trigger finding objects with a for loop. When the app launched, it creates 1000 objects to have some test data. Nothing fancy, a simple object with a few

I take back everything I said about RubyMotion. While spending some time hanging out with some old musicians (guys in their 60s) I came to realize just how terrible I sound by saying pretty much anything negative about efforts in software-land like RubyMotion. Largely my motivations for disliking the project stemmed from my fear that I would have to work with people who chose to use it to make their project. That fear is entirely invalid. I will probably never need to work on a project using RubyMotion same as I won’t ever need to work on a Java project or any other language I might not like. I am fortunate enough to have the skills and friends necessary to easily find work whenever I need it. I then repaid the world for my good fortune by openly bashing a project which did not deserve my hatred. This disappoints

Buzz Andersen: Getting Final Cut I love this post. Buzz is awesome.

At work, everyone expects you to do your best. Wether you are a freelancer, a completely-independent developer, or a company person, everyone expects you to do your best. But what does that really mean? Your best? The best work you’ve ever done? This phrase keeps me up at night. This phrase makes me panic at work. This phrase has lead me to act like a jerk to people who didn’t deserve it. This phrase has made me hate projects and experiences that weren’t actually that bad. What you have in your mind right now about what your “best work” looks like is probably wrong. It most definitely does not match what your client/employer/customer thinks is your best. The work you produce is influenced by many things. If your client hands you designs and pays you to build an app, there isn’t much you can

I will make myself proud of myself. I will no longer use my current situation as an excuse for my lack of action or progress. I will not be distracted by tools or toys, but press on to the solution and that which gets me there. This is the year I become who I want to be instead of simply planning it. I will continue to do that which is terrifying and/or embarrassing. I have the strength necessary to do what must be done. I will eliminate the fear that causes me to hesitate. I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will

Now that I am moving to Amsterdam, I need a new plan. I have learned so very much since the last time I wrote out a plan and I am both excited and terrified. Previously I was very much against freelance/agency type work due to my frustrating experiences in this field. In the last year I have learned that most of these frustrations weren’t really problems with freelancing or working for an agency, but more a problem with my own experience and abilities. I feel that most of these things will no longer be as frustrating and will only get better as time goes on. Much of what I have learned has become part of my own theory about how software development should be handled. People throw around words like XP and Agile, but there are some important aspects of these practices that I will be using in