Shipping a 1.0 Mac App

Brent Simmons: "The idea behind the lecture was to talk about what makes a great Mac app. I took that as an excuse to talk about everything from work habits to UI to marketing. In other words, I threw in just about everything I know - which, it turns out, only takes about an hour to deliver. :)" - A whole lot of this is common sense, or knowledge you've already gained, if you've worked in the development world, but it is definitely worth revisiting because it's just too darned easy to forget. As developers it's easy to get caught up in adding one more thing to the mix, which can kill your 1.0 launch.

Great stuff, go take a look.

Thanks Brent!

Labels: , ,

Posted by Rob at 2:09 PM | 0 comments | Click here for a permalink to this entry.

Duct tape and bailing wire

Duct Tape, fixer of all things!Joel Spolsky: "Jamie Zawinski is what I would call a duct-tape programmer. And I say that with a great deal of respect. He is the kind of programmer who is hard at work building the future, and making useful things so that people can do stuff. He is the guy you want on your team building go-carts, because he has two favorite tools: duct tape and WD-40." - Sometimes duct tape and bailing wire is enough to get the job done.

Labels: ,

Posted by Rob at 4:34 PM | 0 comments | Click here for a permalink to this entry.

Vista Registration Tip

Ok, so after installing Vista for the first time last month I didn't register it, I had 30-days, why do today what you can put off until tomorrow, right?

So, I'd changed the IP address on the box, shut down, moved the machine to a different location and network, fired it back up... and I need to register it NOW of it's not going to work for be. No problem, I'll finally get around to registering it, but wait, I can't get a network connection, DOH!

So, if that happens to you, here's how to get around it.

1) Select "Run with reduced functionality" option (I don't remember the exact wording.)
2) Once up and running select Start > Run and type
3) slmgr /rearm

This will give you another 30-days, and allow you to log back in so you can fix your stinking IP address problem, which will in turn allow you to register.

Labels: ,

Posted by Rob at 2:18 PM | 0 comments | Click here for a permalink to this entry.

A great little Objective-C Blocks example

Jonathan Dann: "Lets make our code more robust, we all like robust. Blocks are anonymous functions, we can write them in-line and the can capture variables from their enclosing scope." - A great little example of using Blocks in Objective-C, restoring state after a change to a Quartz context. Handy.

Labels: , ,

Posted by Rob at 9:26 AM | 0 comments | Click here for a permalink to this entry.

Finding and fixing iPhone/Mac memory leaks

Ref CountMobile Orchard: "Some memory leaks are easy to see by looking at your code. Some are much more difficult. This is where Instruments comes in. Instruments has a 'Leaks' tool that will tell you exactly where you're leaking memory so that you can get in there and fix it!" - These are the types of tools every developer should learn. Hard as we try to write clean code we will, on occasion, forget to release a reference to an object and you get the dreaded memory leak. I must admit the Cocoa reference counting mechanism is a bit odd to an "old-school" Windows/COM developer, but I've learned to deal with the oddness.

Oh, there is a great tutorial for Windows COM guys to explore if they're coming over to Objective-C/Cocoa to help with the ref counting mechanism.

Labels: , , , , , , , ,

Posted by Rob at 1:39 PM | 0 comments | Click here for a permalink to this entry.

Listen to your users

Nick Bradbury: "If you've never supported your own software, spending just one day doing tech support will be an eye-opening - not to mention humbling - experience. You'll have to keep your ego in check, because most people who contact tech support do so because they're having problems with your software, some of whom will use colorful language to describe the annoyances they're running into." - Nick is right, on all accounts. I did developer support for a couple of years at Visio and most of the time people called because they'd run across some edge case, or wanted something we plain didn't do. On rare occasion the language could become quite, as Nick puts it, colorful. In the end it helps you create a better product and keeps you interested in pleasing the people you really work for, the users of your product.

Labels: , ,

Posted by Rob at 2:26 PM | 0 comments | Click here for a permalink to this entry.

Common sense coding

Dan Wood: "Without further ado, here are some guidelines that I try to follow. Some of these, but not all, are directly related to issues that Clang has caught. (If you have any of your own to suggest, add them to the comments please!)" - A great set of rules that apply to not only Objective-C but coding in general. But, if you're new to Objective-C, or new to coding in a language that hands you a rope and allows you to place it around your neck, this article is for you.

I really, really, like Dan because at the top of the article he mentions "no K&R style bracing", a man after my own heart.

Labels: ,

Posted by Rob at 8:25 AM | 0 comments | Click here for a permalink to this entry.

Pencil, paper, and computer

Inside Adobe Illustrator: "You'll see that Von's approach, which is in fact used by many professional Illustrators, is very careful and methodical (in the best sense of these words). Before ever firing up Illustrator, Von has gone through lots of thumbnail sketches, roughs and finally produced a tight sketch that he will scan into Illustrator to use as a template he 'builds vectors'." - Pencil and paper are still the quickest way to rough out ideas, even when you're doing software engineering. The artist in this case then scans his work to use as a template. Sounds like a good plan.

Labels: , ,

Posted by Rob at 11:17 AM | 0 comments | Click here for a permalink to this entry.

Breaking on a memory allocation

I keep forgetting to write this down, so it's going on the good ole weblog for searching later.

If you have your code setup to do heap allocation tracking, _CTRDBG_LEAK_CHECK_DF and you'd like to break on a specific allocation, here's what you do once you've started debugging.

Add the following to the watch window.

_crtBreakAlloc

Set the value to the allocation you'd like to break on. Now, if you're using the multi-threaded DLL runtime you'll have to provide a better context to the debugger. Like this.

{,,msvcr90d.dll}_crtBreakAlloc

So, if I'd like to see who allocated a hunk of memory, they were the 1000th caller, and they didn't free said memory, set the value to 1000, and the debugger will stop on allocation 1000.

Handy, big time handy.

Article on MSDN with more details, How to: Set Breakpoints on a Memory Allocation Number.

Labels: , , , , , ,

Posted by Rob at 1:48 PM | 0 comments | Click here for a permalink to this entry.

Leave well enough alone

Brian H. Madsen: "A colleague of mine sent me this little snippet of gold yesterday - it had me laughing like a drunken seal so i figured i'd share it." - Every coder is tempted to "fix" things, sometimes it works, sometimes it doesn't. I'm guessing this is a case where it doesn't work to mess with the current implementation, even if it's not so pretty.

Labels: ,

Posted by Rob at 9:53 AM | 0 comments | Click here for a permalink to this entry.

Paper, a developers best friend

Gus Mueller: "So a little while back as I was bugging Kirstin about some math (which I knew I had already bugged her about a couple of years previously, but couldn't find my notes on) I decided to get a little bit more organized. And I've now got two pretty thick sketch books, pictured above, with mostly empty pages in them but rapidly filling up. And I thought I'd just pass this tip on to you." - This is something I've done for years. I love National Brands Laboratory Notebooks. I have a stack of them from notes past, doodles, misc notes, strange names and phone numbers, and debugging sessions. They're a lot of fun to go back through and see what I was thinking at the time and how whatever I was working on at the time progressed. Most real drawings, Visio drawings, I've ever created started life on a piece of paper or a white board, maybe I shouldn't admit that, but a good piece of paper is still the fastest way to capture an idea, IMHO.

Labels: , , ,

Posted by Rob at 11:37 AM | 0 comments | Click here for a permalink to this entry.

Plugging C into Python

Ned Batchelder: "Python can be extended with extensions written in C. It's a complex topic, this will be a quick 45 minute introduction." - If you've ever wanted to hookup some good old fashioned C code to your Python application, this is a great starting point. Thanks Ned.

Labels: , , ,

Posted by Rob at 5:37 AM | 0 comments | Click here for a permalink to this entry.

But at what cost?

James Robertson: "Just ask yourself: especially in a time of uncertain budgets, is a huge rewrite really the best use of your limited resources? What will your group not be doing for the business while they waste time on that?" - Rewrites are often times destroyers of an applications place in the market, and can destroy entire companies. If you can get away with interop between the old and new, that's probably the best way to go. Go read the post, and the links to the four other posts related to this subject.

I'm sure there are a few great stories out there as well, but jumping on the flavor of the month can be fatal, especially if you have a working, established, product.

Labels: ,

Posted by Rob at 3:36 PM | 0 comments | Click here for a permalink to this entry.

Rookie mistake

Today I spent 30-minutes trying to figure something out, all because I made a very rookie mistake.

Please, allow me to share, in hopes, you don't make the same mistake in your daily coding adventures.

On rare occasion I've inserted extra code into some routine that is turned on, or off, by a conditional #define. It's nothing new, coders do it every day. The mistake I made today was I used that conditional in two spots and put the #define DO_MY_SPECIAL_STUFF in both spots. Once in a header, once in the implementation file, because the implementation didn't include the header. The reason I added the #define in both places is because I was in a hurry and didn't want change the project defines, and force a rebuild. Ahhh, save time now, pay later! Which is exactly what I did. My code worked as expected, it failed, gracefully, but it failed, and I couldn't figure out why for quite a while. After getting angry, and scratching my head for a while, it hit me. I'd commented out one of the #defines and left the other active. DOH! Instant badness.

So, lesson for the day. If you have a conditional piece of code controlled by a #define, make sure that #define is in ONE place, not two.

Rookie...

Labels: ,

Posted by Rob at 6:27 PM | 0 comments | Click here for a permalink to this entry.

Objective-C Scoping

Guy English: "In Objective-C the lifetime of an object is not governed by the scope in which it appears - it is managed manually by the programmer." - Nice talk on Objective-C object scoping and how to force the garbage collector to do your bidding.

Labels: , , ,

Posted by Rob at 10:34 AM | 0 comments | Click here for a permalink to this entry.

Making room for the keyboard

Cocoa with Love: "The iPhone's onscreen keyboard occupies the bottom 216 pixels on screen (140 in landscape mode). That's around half the screen, so if you ever have a text field you want to edit in the bottom half of the screen, it needs to move or it will get covered." - Nice tip for any iPhone developer. There is also a nice example of this in Apple's UIShowcase sample application.

Labels: , , , , ,

Posted by Rob at 8:55 AM | 0 comments | Click here for a permalink to this entry.

About

Rob Fahrni has been a Software Developer for 20 years. He's developed DOS, Windows, Linux, iPhone, and Palm based applications in C, C++, Objective-C/Cocoa, C#/ASP.Net, and, yes, even BASIC...
About >>



CrabApples.NET Home Kim Fahrni, Hacker Widow Haileigh Fahrni, My Culinary Journey Taylor Fahrni, Goin' Buggy Jerry Fahrni, Pharmacy Informatics and Technology

Apple Core Labs, LLC RxCalc - A Pharmacokinetic Calculator for iPhone

Etcetra

I work at Pelco. The opinions expressed here are my own, and neither Pelco nor any other party necessarily agrees with them.

Subscribe to ATC Send e-mail to Rob Follow me on Twitter. My Profile on LinkedIn.