For whatever reason, I was thinking it sure would be an interesting world if Diana Spencer and John Lennon were still among us.
On a current project, whenever a menu extra menu was open and an underlying item was updated, the entire menu extra would crash. Upon further review here (note “Main Thread Only Classes”), it appears that it is verboten to update the menu item title from a thread other than the main thread. Check out this git repository for a simple project that used to reproduce the problem and now shows how to set the menu item title properly from a non-main thread.
I’m not sure why Xcode doesn’t support Print Selection like Terminal (and other) apps do. Anyway, I finally got tired of not having this feature and implemented it myself using a shell script. No step-by-step this time — you should know how to do that by now. Just notice the script’s contents, input/output, etc. This specifically prints the selection two-pages-per-sheet and will display an alert with the command output.
In case you haven’t stumbled across this yet, you can easily enter accented characters using the iPhone keyboard, simply by tapping and holding on the character you want to accent. In this example, I tapped and held on the E in order to choose and enter an é:
Well, as much as I coveted one of the new MacBook Pros, I didn’t expect I’d end up with one. Until yesterday when my stalwart 17″ MBP started blank-screening me on sleep and restart. I spent a number of hours trying about everything I could think of and finally gave in and bought a new 15″ MBP — the one released at WWDC this year.
So far, I do miss the resolution of the 17″, and I’m not sure if I’m crazy about the glossy screen or not. Otherwise, the speed is great, and the multi-finger gestures are pretty cool. Now if I could only get Boost to build….
During a recent presentation about Xcode, when the speaker brought up how to create a “snapshot,” my colleague Chris and I both had the same answer:
$ git commit
I recently was having some difficulty with some drawing in a UIView and decided that outlining the bounds of the view itself would help me to debug the problem. (It did. Instantly.) All you have to do is to stroke the bounds rectangle of the view you’re in (this assumes you have already subclassed UIView for your custom view). Add the following code to your
CGContextRef context = UIGraphicsGetCurrentContext(); CGContextSetStrokeColorWithColor(context, [UIColor redColor].CGColor); CGContextStrokeRect(context, self.bounds);
This can be done without subclassing (or with, if you prefer) very easily. Simply access the view’s CA layer and set the border on it:
[[aView layer] setBorderWidth:1.0];
On the heels of Gregg Pollack’s call to action last week to give out three thank yous, here are mine:
- Thank you Uncle Bob Martin. Adopting your three rules of TDD changed my development style and helps me to deliver excellent quality code and design.
- Thank you DHH and the Rails core team for providing a framework that truly delivers on the promise of allowing you to focus on the business logic of an application as opposed to the more pedestrian work (Java EE, are you listening?)
- Thank you Matz for Ruby. You’ve taken an old (C/C++/Java) dog and learned him some (dynamic) new tricks.
Some thoughts after spending several days immersed in the software development goodness known as RailsConf 2009:
- Uncle Bob’s keynote was not only hysterical but extremely informative and motivational.
- I enjoyed the various Cucumber talks and I believe I now know where to start with it.
- Sometimes it helps to be “old” as I knew the significance of the zip code 02134 and won a copy of the Rspec book. Send it to Zoom!
- I’m downloading RubyMine and trying it out. Gregg Pollack’s demo makes it appear extremely promising as a Ruby/Rails IDE.
- “Code smells” was a new term for me. Cool that metric_fu is available to sniff your code in many different ways.
- I need to look into Webrat and Nanite.
- I need to get a github account and put some of my code out there if I want to be like all the cool kids.
- After working with git for several weeks on a daily basis, Scott Chacon’s advanced git tips and tricks really put git over the top for me. And the cheat sheet should prove insanely useful.
- I’ve known about the various Amazon Web Services for a long time now. I should actually try them out.
- The Las Vegas Hilton needs to be put out of its misery.
I am collaborating on a project right now where multiple developers may be making changes to a single Xcode project. Since in my experience, Xcode project files “don’t merge well,” we have setup git so it treats the Xcode project file (project.pbxproj) as if it were a binary. Consequently, it sucks to have too many outstanding changes to the Xcode project file that have to be merged back in manually. To help shorten the amount of time someone might be working on an out of date Xcode project file, I setup a post-commit hook on the git repository that sends email to the developers in case this particular file changes.
- Add the following “hooks” section to the config file for the target git repository, of course updating the email(s) as appropriate:
[hooks] mailinglist = firstname.lastname@example.org email@example.com
- In the “hooks” directory in your repository, you should find a file named “post-commit.” Add the following to the file:
git show --pretty="format:" --name-only HEAD | grep project.pbxproj if [ $? -eq 0 ]; then mail $(git config hooks.mailinglist) -s "Xcode project changed" <<-EOF Please pull the latest Xcode project. EOF fi
- Make the post-commit file executable if you have not done so already.
chmod +x post-commit
That’s it! Piece o’ cake, huh? Anyway, even if my logic regarding the “mergability” (or lack thereof) of an Xcode project is flawed, the principle behind email notification on a single file is still valid. I’m sure generalizing this to notify upon changes to a list of files is easy enough.