One important part of success in any field is answering the question “Why?” As a musician, you might play a solo that everyone is impressed with, but unless you know why that solo worked, you’ll rely on luck to do it again the next time. In software this is just as important. Why is your app crashing for some users? Why did your app sell zero copies? Why did your app sell 500,000 copies? Knowing why makes it possible to consistently reproduce the results you like and avoid the ones you don’t. Your computer is running thanks to a ton of complicated electronics. None of this happens in your laptop by luck. Every circuit, every transistor, every diode, every capacitor, every piece is in your computer because someone figured out why they do what they do. Understanding why a transistor works enables them to pick the best

My previous demo video was confusing to many people, so here is attempt #2. It's getting better!

While this project hasn't quite turned out like I originally intended, it has resulted in a fairly useful app I'm happy with. It has some rough edges that need some love and attention still, so here is a little video preview while you're waiting to play with the real thing.

Project: Untitled something Total: $0.00 Made with Chainguard.app itms://itunes.com/apps/chainguard (Everything above is my first published post from my app-in-progress Ghosty. It's not much, but this means it's working!)

The first week of my morale-boosting project is nearly complete and I would like to show you what I've been working on. The app is (for now) called Ghosty. It is an iOS app for connecting to blogs using the hip platform, Ghost. Like Wordpress, they provide an option to host it yourself or to pay for hosting using their service. Either way you do this, it would be great to be able to publish from your iPhone or iPad. iOS-based publishing is part of the reason services like Twitter and Instagram are so successful, so it seemed like a good choice to build (especially considering blogs I wrote on like this one are using Ghost). With sharing extentions, this effort becomes even easier, so I believe I'll be able to build a good working product in about a month. Ghosty doesn't need to be a great blog editor, simply

I didn't want to write a long retrospective, but I thought I should mention something about the last year. 2013 was stressful and terrifying. I almost had to borrow money from my family to leave Amsterdam and move back to Oklahoma where I would need to live with my mom while I recovered. I didn't just hit the bottom, I smashed through the floor. That year I decided to take a risk and hold on. 2014 was the year my business worked. Now at the end of 2014 there is money in the bank, there are happy clients, residency is safe, and I was able to fly my mom and my aunt to come visit me. It's always hard to "know when to hold em" or "know when to fold em", especially when it involves your life or your career. I won't even pretend to claim I know what made

It's the start of a new year and that seems like a good excuse to try something different. I'd like to work on a project for funsies. For this project, I don't want to care about market, profits, making a client happy, or any of the junk that fills my RSS feeds with doom and gloom. I'd like to pick a fairly small idea and just execute on it well. It should meet a few requirements: Project time shouldn't take more than a month. It doesn't matter what gets built as long as it is built well. I must write about it. Ideally I could work on this with someone I enjoy working with. I work alone plenty already. It should be tested as much as possible. The final product will be published to the App Store for everyone to see. I don't plan on making more than about $20

As I wrote in a previous article, my last attempt at making an app had problems. I'm pleased to announce today that I've finally launched something much better. Parts was an app to keep up with items you needed to buy for projects. It could remember where you were when you found an item, what the item looked like and how much it costs so you didn't have to. I removed Parts from sale shortly after it's release because of its problems. Chainguard is my attempt to make a better version of this app. First there were a host of design problems to address: Lists could not be renamed. This meant typos lived on forever unless you wanted to delete your list and try again. Chainguard's UI allows people to simply tap on the title of a list and rename it. I was trying to be clever in Parts and

I've seen quite a few attempts at solving this problem and all of them seem to be more complicated than necessary. Many solutions I see involve using a method like this in your tableview's datasource: - (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath { NSString *text = [self textForRowAtIndexPath:indexPath]; CGSize newSize = [text sizeWithFont:[UIFont preferredFontForTextStyle:UIFontTextStyleBody] constrainedToSize:CGSizeMake(308.0f, CGFLOAT_MAX) lineBreakMode:UILineBreakModeWordWrap]; return newSize.height+10.0f; } There are a few problems with this method. Magic numbers: Where does 308.0f come from? Where does 10.0f come from? Why should your tableview's datasource know or care? This puts details about your design into a place that shouldn't give a crap about your designs. Hard-coded fonts: What happens when you decide to use a different font in your textview? Get ready to bang your head against a wall until you remember to also change the font in your datasource.

Last year I launched my first app that wasn’t funded by a client or employer. It’s called Parts. I never expected it to make millions of dollars, but I had hoped it might at least make enough to pay the rent or some such. In total, it made $44 according to AppViz (a great tool by the way). After some time being bummed out about this, working on client stuff, and considering attempting other apps, I thought it would be worth considering what was wrong with the app, and why it basically failed. Parts was originally intended to be “your purchasing todo list”. It was supposed to be your assistant when you looked for capacitors and pickups for your guitar customization, or the handlebars and cranks for your next bike build. It would accompany you while visited shops in your travels, and it would make sure you didn’

A cargo cult is any of various native religious cults of a millenarian and messianic character located in the southwestern Pacific islands, holding that spirits will bring large cargoes of modern goods for distribution among its adherents. [1] After the arrival of the computer and the practice software development, this term was used a slang to refer to a style of programming that is characterized by the ritual inclusion of code or program structures that serve no real purpose. [2]. In a modern world of lies and skepticism, we developers have learned to question new ideas, especially when a new idea results in more work. We question ever new idea: TDD, BDD, DDD (basically, any three-letter acronym), patents, new languages, new operation systems, you name it. Many times, the person sharing this idea is not able to articulate the necessary information you need to decide that their idea is valid.

Earlier on App.net/Facebook I posted this: "Also, asking potential hires to build apps as part of the hiring process is stupid." Perhaps short-text social media is not enough to properly elaborate my thought. Here’s a better version: If you want to see professional work from a developer, pay them professional rates. That’s how capitalism works and that is the world we live in. I fully understand and sympathize with the goals of someone hiring a developer. They want to know that the developer they’re talking to can do the work. An excellent way to do that is to see some of their existing work. Totally valid request. Some developers have work already visible. They have public projects in places like GitHub and BitBucket. Problem solved, browse away and enjoy! But what happens when they don’t have code publicly available (or not code in the

Getting Better Those of you who already read my blog know that I’m not the best writer. You’re likely either reading this because you’re either related to me or the technical information has helped you. Thank you for reading! This year is going to be better. More content, better writing, you’re in for a treat. The nice part about not being very good at anything is that it’s much easier to go from pretty-crap to good than it is to get from great to excellent, so this should be easy! Strategy Here’s the plot: Reduce friction to post. Reserve more time to post. Find a good editor (the person, not the application). In theory, these things will lead to higher frequency and better posts. I only wrote 15 blog posts in 2013. Some of which are maybe 2-minute reads. That’s no way to

Words like “intelligent” and “stupid” and “smart” and “genius” get thrown around quite a lot these days. I think they’re all mostly bullshit and distract from the real issues. In software, we often run into people who lack the depth of knowledge and experience in the various fields necessary to make apps. Many of us lack business and marketing experience, some of us lack experience in Object Oriented Programming or Functional Programming, many of us lack experience in a specific platform or language. Maybe now we use that new language or platform for work. Now, someone who does have experience in these fields (or at least thinks they do) might think “man, these other people are such idiots. I’m the most intelligent person here” or “they must be stupid because they don’t do xyz!” and that’s simply not the case. To say someone is stupid or

When to use #define: When you’re declaring macros like in Apple’s: #define UI_USER_INTERFACE_IDIOM() ([[UIDevice currentDevice] respondsToSelector:@selector(userInterfaceIdiom)] ? [[UIDevice currentDevice] userInterfaceIdiom] : UIUserInterfaceIdiomPhone) I’m actually not even sure why this wasn’t made as a function like NSLog instead of a macro. When not to use #define: When you’re declaring constants. Constants should look like: NSString *const RWSSomeConstantName = @"theValueDoesn'tUsuallyMatter"; const NSInteger RWSIntegerConstant = 3; Why go through this effort to type extra letters? Constants declared using #define don’t show up in tools like the debugger. #define is raw text substitution, constants are symbols to your debugger, like class names. #define won’t warn you if you use #define in some other file and change the value of your constant accidentally.

I just finished the book, Practical Object Oriented Design in Ruby. I haven’t been paid to write Ruby code in years and I still found the book incredibly useful. Sandy Metz writes excellent explanations for many things I have felt about code I have seen while working on projects. In the last chapter, Sandy discusses how to write effective tests. She walks through creating tests to document “duck types” by writing tests that make use of assert_responds_to. I think with Objective-C these tests are unnecessary for the most part. In Objective-C we can formalize these “duck types” with Protocols. This way the compiler will tells us when our object fail to implement the interface other objects expect. You know, assuming we don’t ignore the warnings coming from the compiler. A “duck type” gets is name from the phrase, “If it looks like a duck and quacks

I try to be extra careful to consider my capacity before agreeing to do something for or with someone (or even for myself). Mis-judging capacity seems to often be the cause of frustration and failure. I think now I finally have the capacity to do something cool that isn’t for a client. I think about capacity in a few different ways. Skill Producing anything, apps, music, books, needs skill. More skill and experience in theory allows a person to produce in less time. It certainly can allow a person to produce higher quality things. Social Some of us have a limited capacity for being around other people. Once this is depleted, we need to have some alone time to recharge. The internet makes this easier by allowing us more time to interact with others because it drains this capacity more slowly. Financial Producing things also cost money. Supplies cost

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