Structure and Interpretation of Computer Programmers

I make it easier and faster for you to write high-quality software.

Tuesday, March 2, 2010

How to hire Graham Lee

There are few people who can say that when it comes to Cocoa application security, they wrote the book. In fact, I can think of only one: me. I’ve just put the final draft together for Professional Cocoa Application Security and it will hit the shops in June: click the link to purchase through my Amazon affiliate programme.

Now that the book’s more-or-less complete, I can turn my attention to other interesting projects: by which I mean yours! If your application could benefit from a developer with plenty of security experience and knowledge to share in a pragmatic fashion, or a software engineer who led development of a complex Cocoa application from its legacy PowerPlant origins through Snow Leopard readiness, or a programmer who has worked on performance enhancement in networking systems and low-level daemon code on Darwin and other UNIX platforms, then your project will benefit from an infusion of the Graham Lee magic. Even if you have some NeXTSTEP or OPENSTEP code that needs maintaining, I can help you out: I’ve been using Cocoa for about as long as Apple has.

Send an email to iamleeg <at> securemacprogramming <dot> com and let’s talk about your project. The good news is that for the moment I am available, you probably can afford me[], and I really want to help make your product better. Want to find out more about my expertise? Check out my section on the MDN show, and the MDN security column.

[] It came up at NSConference that a number of devs thought I carry a premium due to the conference appearances, podcasts and other material I produce. Because I believe that honesty is the best policy, I want to come out and say that I don’t charge any such premium. My rates are consistent with other contractors with my level of experience, and I even provide a discounted rate for NGOs and academic institutions.

posted by Graham Lee at 13:22  

Thursday, January 1, 2009

What’s new in 2009

Of course, it’s a bit early for a retrospective of 2008, besides which I’ve already written 73 entries this year, my most prolific year to date on iamleeg. And that doesn’t count numerous tweets, stack overflow contributions and of course the occasional piece of source code here or there for some security company. As the noise of fireworks and exploding media players sounds across the world, it’s time to pre-emptively ditch 2008 and see what we can expect from 2009. Specifically, what you can expect from me.

It looks to me like the most popular pieces on this blog are the opinions and how-tos regarding Cocoa development, particularly my thoughts on properties and Cocoa memory management round-up. Don’t worry, there’s definitely more of this coming. As well as preparing for this Mac Developer Network conference talk I’ve been discussing recently, I’ve got another exciting – and unfortunately secret – project on the go now which should see plenty of collateral blog posting in the first half of the next year, all about Cocoa development. There’ll also be a bit more of an iPhone mix-in; obviously for much of last year the SDK either didn’t exist or was under non-disclosure, but now I’ve got more reasons to be using Cocoa Touch it will also be mentioned on here. I shall also be delving a bit deeper into Darwin and xnu than I have in previous times.

One example of Cocoa-related information is meetup announcements; I’m still involved in the local CocoaHeads chapter and I’ll endeavour to post an advance warning for each meeting here. I know many of my readers are in the States but a few of you are local so please do come along! In fact, if you’re not local (or “bissen’t from rond theez partz”, as we say here) then consider going to your nearest CocoaHeads or starting a new one. It’s a great way to find out who’s working on Mac or iPhone development in your area, share tips and stories and build up that professional contacts network.

Previously I’ve been concerned that readers here at iamleeg don’t seem interesting in commenting on my posts, but these days I’m no longer worried. I can tell how many people are reading, and of those how many are regulars, and I have to say that the blog is doing pretty damn well. Of course, if you do feel inclined to join in the discussion (particularly if I’ve got something wrong, or missed an important point from a post) then you should feel perfectly at liberty to leave a comment.

Finally, have a happy new year!

posted by Graham Lee at 03:47  

Friday, January 12, 2007

Eating one’s own dog food

I feel foolish for having made this error (especially after having so patiently explained how this stuff works on Mach), but today I did it. I reported the amount of free memory on a Linux system as being the amount reported by free as free.

My own opinion on this is that I suffer from a view of hardware management which was tainted by using micros like the Dragon 32 (Radio Shack/Tandy TRS-80 to my American readers) and the Amiga, where there were basically two types of memory usage: yes and no. A particular block was either in use by the system, or it wasn’t. On the Dragon 32 it was even easier than that of course; all bytes were available for reading and writing, but what happened was context-dependent. Also because this was the MC6809E, whether such a peek/poke made sense depended on whether you were trying to hit an I/O address, and what was plugged in. The Amiga had a particularly lame memory allocator which quickly sucked performance like a vacuum of performance suckage +2; but a byte of RAM was either in use or it was available.

But I digress. The point is, that such a simple view of memory availability is no longer sensible but it’s hard for me to think around it without a lot of work, just as it was hard for me to become a programmer after I’d been taught BASIC and Pascal. If I were involved in UNIX internals more (and indeed that would be fun, although I think maybe Linux wouldn’t be my first choice to open up) I’d probably be able to think about these things properly, just as I had to throw myself into C programming in a big way before I lost my BASIC-isms.

For the record (and so that it looks like this post is going somewhere), both operating systems have an intermediate state for RAM to be in between "used" and "not used" (where I’m ignoring kernel wired memory, and Linux kernel buffers). On Mach, there’s the "inactive" state which I’ve already described at el linko above. On Linux, it’s used as an I/O cache for (mainly disk, mainly read-ahead) operations. This means that Linux will automatically take almost all (if not all) of the memory during the boot process. The way that inactive memory gets populated on Mach means that on that system (e.g. Darwin) actually the amount of free memory starts large and inactive starts small, but over time as the active and inactive counts go up, the free count goes down, and it’s rare for memory to be re-freed. On both systems, free memory is really "memory it wasn’t worth you buying" as it’s not being put to any use at all.

posted by Graham Lee at 18:05  

Powered by WordPress