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
Trying this “mechanical keys” thing.
adventure You’re lying to yourself and everyone around you if you ever say you don’t want to go somewhere new. It’s ok, I lie to myself about all kinds of things. Exploration is a critical part of the human condition. A biological imperative to continue the species. Amsterdam is a very new place. A whole new country and continent as well. What I’ll be doing in Amsterdam will be a more difficult, more challenging, more terrifying version of what I have been doing. I thought the same about NYC before I arrived last year, but I’m here now and the fear is mostly gone. That tells me it is time to step it up a bit and scare myself. opportunity I cannot count the number of times I have talked to someone and listened to them talk about how “one day” they’re going to
The more I research these SOLID principles, the more I see how they don’t necessarily apply to modern programming and even less so to Objective-C. It’s easy to want to over-engineer, over-architect, or over-work anything you do as a programmer. Who wants to miss an opportunity to flex their muscles and improve their skills? I’m not going to write about the LID in SOLID, there’s plenty of info on the internet if you care to look. I am going to continue my research and come back with more once I’ve learned enough that I feel I could write a more useful blog post. If you’re bummed about this want want to discuss the SOLID principles (or any principles, methods, patterns, isms, etc), feel free to contact me. I’m down to talk often, though my responses may be delayed. Thanks for reading (all 10
My first talk, "Refactoring and stuff" given at NYC Cocoaheads
Open/Closed Principle Ivar Jacobson once said All systems change during their life cycles. This must be borne in mind when developing systems expected to last longer than the first version. This is why we want to try to architect our projects in such a way that the future doesn’t become ever so painful. The principle I’ll discuss in this article helps to make that a reality. Back about 2 years after I was born, Bertrand Meyer described the principle when he stated "Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification." Another way to state the principle is that your classes, modules, and functions should be written in such a way that future changes can be accomidated by extending existing code with new code instead of rewriting the original code. If the existing code in a class works and you don’
The Single Responsibiliy Principle Robert C. Martin wrote about the principle in his article back in 2002. The principle states: "There should never be more than one reason for a class to change." — Robert C. Martin As requirements for your project change, your code will need to change to meet them. The more reasons you have to change a given class, the greater chance you have of introducing bugs. Consider the case of the often misused Application Delegate. According to Apple’s documentation, an Application Delegate’s one responsibility is to respond to application-level events such as your application being sent to the background or your application has finished launching. You might feel tempted to add additional responsibilities to your Application Delegate for convenience. Handling your Core Data stack, downloading content to display in the Application, and other such responsbilities taint the one single job of the Application Delegate. A