Engineering

Car Code

/ hsoi / 2 Comments

I figured with the growing amounts of electronics in cars that there must be a lot of code behind it, but I didn’t realize just how much code until I read this article.

Speaking as a software developer, that is massive amounts of code. Huge. Trying to maintain that would be a bear. Furthermore, trying to ensure it’s error/bug-free? A monumental task, edging on impossible.

I don’t know how the automotive industry works in terms of producing this software, but if it’s anything like most commercial software companies then lord… it makes me want to drive a Model T, that’s all mechanical and easy to fix. All I can do is hope they have a good understanding of proper software development process and are not willing to sacrifice solid reliable code because they need some new feature and needed it yesterday.

I also hope they understand how simple is better. All those millions of lines of code? Gosh… if they can take the time to simplify and trim that down, so much better in the long run. More maintainable, less chance of errors and problems and risking catastrophic failure.

Gosh I hope they do things right.

Of course the geek in me wants to know nitty gritty details now like the language they’re using and the toolset. 🙂

-[NSTableView setDoubleAction:] not working?

/ hsoi / 1 Comment

This is documented but in a subtle way, so I thought it’d be worthwhile to mention in a more obvious way.

If you are using NSTableView’s -setDoubleAction: method, the action is only invoked if the cell or column double-clicked upon is uneditable.

Thus, it may not be enough to go:

[theTableView setDoubleAction:@selector(myAction:)];

You may also have to do something like:

[theTableView setDoubleAction:@selector(myAction:)];
[theTableColumn setEditable:NO];

I ran into this just now because I had a single-column table (just a simple table to display a list of stuff, thus the user wasn’t allowed to edit anything) and I wanted to allow a double-clicking on the item (row/cell) to advance the user to the next stage of things (they could also single-click to select the item then click a “Go” button… double-click would just be a shortcut). It actually was working fine under Mac OS X 10.6 Snow Leopard, but the double-click was failing under Mac OS X 10.4 Tiger. Once I made the table column explictly uneditable, it started working and the table received the clicks, the clicks didn’t fall through to the table column.

Code Practices

/ hsoi / 2 Comments

I’ve been developing software over 30 years, 15 of those professionally. I’ve learned a thing or two from the real-world trenches, one of which is that all code written must eventually be maintained… probably by you. The more you can do to ensure your code can be understood 6 months (or more) later, the better (your) life will be.

But this is hard.

Not just whining that it’s hard, but it is a difficult thing to do because who can know what exactly you’ll need to know or care about during maintenance. And while you’re in the heat of the moment writing code, you may not consider everything that needs to be documented. This is why the best you can do is strive to write simple code, well-factored, and as understandable as possible from the get-go. Premature optimization is the root of all evil. Simple is good; simple is best.

Via Slashdot I see this article on Coding Practices. He raises good points, but at least in my experience it doesn’t always work out that way.

Continue reading →

How do you people do it?

/ hsoi / 2 Comments

I am a Mac user. In fact, I don’t just use Macs but I write software for Macs as my chosen profession. I’ve been writing Mac software for over 17 years. The first computer I owned (well, parents owned it… first computer in my household that I had regular access to) was an Apple //e. I’ve been working with computers for over 30 years, and for the most part yes it’s been Apple-based. Sure I’ve used other computers and computing systems, but Apple computers and Macs are my mainstay.

Why do I prefer Macs? Because they are elegant, beautiful, “they just work”, there’s a familiarness in their use and design. Like any good tool, the tool should enable and enhance your ability to get work done and should not get in your way. This is the Mac User Experience. Granted, it’s not always perfect. Apple themselves have changed and refined the OS over the years, with some stumbles but some great strides too. Certainly you encounter 3rd party software that can be wonderful to use, and some that can be amazingly painful to use. Usually I’ve found the painful stuff is written by people who think they’re just writing software and don’t fully grok the notion of “user experience” and what that means and why it matters.

That’s why I write today.

I’ve been temporarily reassigned to another project within the company I work for. This particular piece of software exists on both Mac OS X and Microsoft Windows. For the most part, that it exists on Windows matters not to me. However, I was just given a couple bugs (I didn’t write them, but I get to fix them) to investigate that necessitate the use of Windows.

I haven’t had to run or really touch a Windows box in over 10 years. Oh sure from time to time I have, at a friend or relative’s house, but in general I just have no reason or need for it. Thankfully the company has copies of VMware Fusion and some pre-made “virtual disks” with Windows XP already installed. A few hours of file transfers later (the VPN is slow) and I was up and running with Windows on my MacBook Pro.

That’s where the pain started.

How in the world can you people use Windows? 🙂

Apparently the XP installs were fresh installs, so upon first login I get bombarded with questions. Little balloons popping up everywhere trying to be helpful but only serving to overwhelm me with a desire to put my fist through the screen. You close one and another one immediately pops up, again, and again, and again, and a-fucking-gain. Oh hey it noticed some sort of hardware, tho I don’t know what, and it’s trying to help me cope with it but doesn’t tell me what it wants to cope with. And the stream of dialogs and “helpful” things just keep coming like and endless parade.

MY GOD WILL YOU SHUT UP AND STOP TRYING TO BE SO FUCKING HELPFUL!

The thing is, I’m a computer savvy person so I understand a lot of what’s going on and why. But I step back and try to look at this experience from the angle of someone like my mother, and I just cringe. No wonder she has to take her computer into the shop so often. No wonder she spends so much time on the phone with tech support. What a nightmare! And all I’ve done so far is log into the machine!

Yes, I’ve been away from Windows that long. I wish it could have been longer.

The I run some installers and wow, talk about more unfriendly and bizarre designs. I know some of this is merely because it’s the devil I don’t know… because it’s “not Mac”. Ultimately however it’s not that. It’s about poor user interface and user experience considerations and design. Granted it is not easy to do, to make something so complex, so technical, into something that just anyone can use. But I do like to think Apple’s done a pretty fair job with that.

I just cannot see how people can use Windows and enjoy it. Most people have to use it because work requires it of them, and then they use it at home because it’s the devil they know. As well, I know most people just aren’t into computers as much as I am so it’s not something they think much about. Or the old stigma’s remain about Macs that keep them away. It’s all about inertia.

I have to use Windows for a little while to deal with this bug. Thankfully it’s only for a little while. 🙂

If you want to learn more about interface and user experience design, check out stuff from Bruce Tognazzini and Jef Raskin. In fact, here’s a great little article by Jef on Tog’s website, about “intuitive”.

Better than setuid – BetterAuthorizationSample

/ hsoi / 2 Comments

While scanning my RSS feeds I ran into this post from JongAm. It’s in Korean so I really don’t know what he’s talking about specifically, but generally I can tell he’s writing about Mac OS X’s authorization mechanisms. (BTW, I love that URL’s and such don’t choke on Hangul).

There’s something at work I’ve been fiddling with the past some days. The issue is that something has to be done and that something requires authorization. Unfortunately, due to how things can work under the hood by the drivers and the OS interacting, it’s possible things could change and thus require the user to authenticate again. This is not a desirable user experience because the need to re-authorize is an under-the-hood detail, not something the user would be aware of. Thus to the user the user experience is randomly, or not, being asked to reauthenticate. Not good.

So what’s the solution? The original thought was to create a little helper tool app that would have its setuid bit set and be installed as root, thus the user would have to authenticate at most one time and the little helper tool would then be authorized “forever” to do the necessary voodoo. A reasonable thing. And setuid tools are not a new concept and are well-established, but still they’re considered tricky and risky because you’re still running code as root which opens up all manner of security issues.

As I searched around for information, I came across Apple’s BetterAuthorizationSample. Obviously written by Quinn (thus you know it will rock), it’s provided as a way to achieve the same results as a setuid tool but in a safer way by use of launchd. What’s even better is BAS provides a library and mechanism to make it easy for you to utilize this functionality in your own code. There is step-by-step documentation that walks you through the whole process, and of course a sample app to demonstrate various levels of complexity. For more information, read the ReadMe, the Design and Implementation Rationale, and the lib HOWTO.

Getting it up and running in my app wasn’t too difficult a task. Just follow the HOWTO guide. It does take a little bit to wrap your head around it all just because there’s a lot going on, but the documentation is thorough and complete. Just do as it says and you’ll be up and running. Works great in my app. I’m pleased.

I will note that if you don’t have an uninstaller for your application, this is one situation that might find a simple uninstaller to be a welcome thing. There are not only files in odd places to remove, but also you will need to unload the Launch Agent from launchd. There’s also the question of removing the entry in /etc/authorization but there’s really no good way to do that. Still, something you need to consider.

All in all a fantastic bit of sample code, and while not necessary for all authorization needs, if you are considering writing a setuid tool for Mac OS X, you should look at this mechanism instead.

Good stuff. Share and enjoy.

Simple(r) Interface Design

/ hsoi / 8 Comments

Firearms instructor John Farnam writes about training experiences with particular pistols (with a follow-up article here). There are certain pistols that have external hammers but those pistols must be carried with the hammer decocked, such as the SIG 226, Beretta’s, H&K’s, etc.; to carry with them cocked is dangerous. What happened was experienced shooters were reholstering their cocked guns and didn’t realize it until an instructor pointed it out.

If well-trained people can forget….

IMHO, decockers add complexity. If I think about it from an engineering design standpoint, and more specifically thinking about the “user interface” to a pistol, decockers are a design feature that is more complex than it needs to be. Granted that’s part of the point, when you consider the evolution of where these guns came from, but it no longer has to be the case. When you have guns like Glocks, Smith & Wesson M&P, Springfield XD, and so on, they provide a much simpler user interface. You’ll also see that other manufacturers are moving towards similar designs. Evolution.

Read my write-up on choosing a gun for more details.

The plutil command obeys no one’s rules but its own.

/ hsoi

I love stumbling across little bits of programmer humor.

I just looked at the man page for plutil (“man 1 plutil“):

STANDARDS

The plutil command obeys no one’s rules but its own.

Heh heh.

Working on a smaller machine

/ hsoi / 1 Comment

As a software developer I appreciate having good hardware. In fact, I appreciate having lots of good hardware as that best facilitates getting work done in a day.

Over my career I have evolved what I prefer to have for optimal work. I like to have a laptop on which I do “communication” work. So the laptop does email, web browsing, instant messaging, and whatever other administrata or time wasting I wish to do. Having it on a laptop is good because often such tasks require portability. I do set up the machine to also do development work, but it is not meant to be a primary dev machine.

I then like to have a very beefy machine for dev work. For instance, these days something like an 8-core Mac Pro with 10 GB of RAM and multiple internal hard drives works very nice. I also like to have multiple monitors attached to the machine because lots of screen real estate is good. Furthermore, it works better to have multiple monitors instead of one big monitor because there is often different logic that can be done based upon “screen 1” or “screen 2”, especially when doing things like debugging and needing to cope with the menubar and screen redraws.

Finally, I like having extra machines for whatever needs. These are often sandbox machines of various configurations that I can nuke and pave and do what I need to to help test, reproduce bugs, and so on.

So as you can see, I’ve found surrounding myself with a lot of machines is a daily necessity for getting my job done.

What happens when I’m forced to use a little machine for everything?

I’ve been temporarily reassigned to another group in the company that needs some help with their projects. Due to the nature of the products and the fact I like to keep very clean machines (sorry Unsanity; no Input Manager hacks here), plus given the nature of the work may require working in other locations, I requested they provide me with a laptop for dedicated use for this work.

I received one. A recent MacBook Pro.

15″.

Man, that’s small. Well, to me at least. 🙂

Compounding that is Apple changed some things in Snow Leopard to make stuff bigger. For instance, the default font in Xcode is Menlo Regular 11, instead of old Monaco 9 or 10.  I played with it some trying to pick other fonts or make things smaller, but I have to say, after I got over the initial shock my eyes do like the Menlo 11 better. But with bigger font means less content on the already smaller scren.

Then when I need to run Xcode for dev work, TextWrangler for notes and other things, Firefox to get into the bug database, and a few other apps… gah. Too many windows on that little screen. Sure I love Exposé and use it all the time, but it’s still a lot for that little screen.

So I started to use Spaces.

I toyed with Spaces before, but I just haven’t had a compelling need for it. I think it’s neat. I’m glad Mac OS X has it. But I haven’t been able to successfully put it into my workflow…. until today.

Turned it on, 4 spaces. Xcode on the main, TextWrangler “below”, Firefox “to the right” and since I prefer to use the keyboard I know the shortcuts to navigate around. Man… everything worked pretty slick. A few things were annoying, such as being on the non-Xcode space and then Xcode’s build window popping open on that space; it makes sense in a way, but it’s not what I want… I want to keep that app’s windows on that space. I wonder if there’s a way to force that.

I don’t know if I’d need to use Spaces on my big dev machine with the 2 monitors and lots of screen space. But on the little machine yeah, what a help it was.

OmniObjectMeter, I love you

/ hsoi

Last night and this morning I’ve been dealing with some odd behaviors in the code I’ve been writing. I know it’s my mistake, the trouble is finding just where the mistake is. I spent time in the debugger observing behaviors that lead me to believe some object instances were not being released thus causing the side-effects I was seeing. As well, the lack of deallocation is a pure memory leak. So, find and fix the leak and many things should improve.

The current tool from Apple for finding memory leaks is the “leaks” tool of Instruments. I do think Instruments is cool and very powerful, but it’s also extremely obtuse and complex. It’s a tool that I don’t need to use all the time (in fact, rarely). Consequently what I learned the last time I needed it has left my head so I have to ramp up all over again. That’s just too much precious time spent, and too many brain cycles distancing myself from the problem at hand. Tools should not get in the way of solving your problem. Before Instruments, Apple had tools like MallocDebug and ObjectAlloc, which were useful and simpler tools but still weren’t the best in terms of interface and usability.

Some years ago I discovered OmniObjectMeter from The Omni Group. It was a godsend. It allowed me to pinpoint and track down memory leaks quickly and easily. It was so simple, so logical, so well thought out. It was easy to get going with it, it was easy to use it, and most importantly you could find your problems very quickly. Unfortunately OmniObjectMeter was left to languish and didn’t work for some time (there was a “secret beta” that helped it limp along). But I’m happy to report it’s back up and kicking with version 2.6 that was released February 2009. You see, I tried using Instruments this morning and while I could see the leak I couldn’t exactly pin down the location that caused the leak. I lamented for OmniObjectMeter, checked the Omni website on a whim, discovered v2.6, downloaded it, and within 5 minutes my leak was found, fixed, and verified.

That’s testimony. 🙂

I’m glad she’s still working. Plus, now OmniObjectMeter is free! I’m proud to say I paid for my copy (well, I got the company to pay for it) all those years ago. So FTC, yet again this is just a satisfied customer telling the tale of his happy experience.

AppleScript is not dead (yet)

/ hsoi / 5 Comments

Jason Snell @ Macworld has an article reacting to Jonathan “Wolf” Rentzsch‘s declaration that AppleScript is dead.

Hrm… get this. That previous link to AppleScript takes you to the developer web pages for AppleScript. I originally wanted to link to Apple’s user/commercial page for AppleScript: www.apple.com/applescript. But if you click on that, notice what it takes you to: Automator. That tells you what Apple thinks about AppleScript as a technology.

It’s scripting for the rest of us.

Continue reading →