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
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