Properties about a year on

Leopard has now been out for nearly a year, which means that (publicly) we've had Objective-C 2.0 for the same amount of time. At the release many developers were champing at the bit to talk about the new language capabilities[*], including properties. There were arguments on both sides of the divide, and even a little bit of discussion. But now that we've been using these things for a while, and because I'm bored awake grouchy vocal opinionated, let's have a look back at what they've given us.

There is a broken abstraction in traditional Objective-C, which is the accessor-method-as-property-declaration. Essentially an object can give you two things; work (i.e. it can do stuff) and state information (i.e. it can say stuff about itself and let you change it). In traditional object-oriented languages, because 'saying' and 'changing' are verbs which can be 'done', the two have both been expressed using the same method (heh) as the expression of work. This is not the case in much object-oriented design, for instance in UML a class always has separate "attributes" and "operations".

Properties fix up this abstraction by giving us orthogonal ways to express the two concepts. Work is done in methods; state is got/changed in properties. Now it may be that the state information is actually backed by a method (although it may bang on the ivar directly; more below), but we don't need to know that any more than we need to know in the interface that a property is synthesized or dynamic. All we do need to know is that it is there for us to use, and has certain attributes such as being read-only.

The "on more below" bit is that discussions of KVC-like mechanisms - such as KVC :-) - often involve someone pointing out that they break encapsulation, because it's possible to access an @private ivar with no accessors by retrieving it by key. That's really thinking about the design of a class in terms of the way it's executed rather than its interface contract with the developer, because the @private ought to tell the developer not to touch that particular ivar. Properties neither help nor hinder breakage from the execution side, but from the design side they do provide a stronger distinction between "properties I'm telling you about in the interface" and "things you shouldn't touch". Now we can all get back to using the class's interface to observe how to use it, and that C struct bit at the top to observe how to extend it, as nature intended. It's both a blessing and a curse that Objective-C allows things to appear in source files which don't make it into the executable code, but that doesn't stop such information being useful to the developer in the same way that code comments can be read but not executed.

One of the popular complaints about ObjC properties is the syntax for referring to them in methods (OK, or indeed in functions), where it is argued that myObject.someProperty = 4; doesn't readily tell you whether myObject is an ObjC object, a C struct or a C union. That seems to be at worst a straw man argument to me, and at best a hypothetical issue; in well-designed software it will be rare to mix code at various levels of abstraction except in limited circumstances such as adapter classes. Besides, if the code has been written such that it can be inspected or reviewed (i.e. to some agreed style and standard) and the reviewer is paying attention then it will be easy to distinguish use of the various types. At some conceptual level the C . and Objective-C . operator are doing the same thing anyway; they're both saying "this attribute of that thing".

[*]The fact that I have stopped using the word 'feature' in many contexts is an entire blog post and a few therapy sessions in itself.

MacDev 2009!

It's a long way off, but now is a good time to start thinking about the MacDev '09 conference, organised by the inimitable Scotty of the Mac Developer Network. This looks like being Europe's closest answer to WWDC, but without all those annoying "we call this Interface Builder, and we call this Xcode" sessions. Oh, and a certain Sophist Mac engineer software will be talking about building a secure Cocoa application.

Rhetoric, smoothly outlined

Something I did a number of years ago (I could tell you how many, couldn't I? If I could remember; I think it must have been 7) was to study critical analysis. That's the application of linguistics and sociology to, well, basically to refusing to believe anything people say to you ever again. As an example of how it's useful to someone who isn't a professional rhetorician, here's a discussion of the things I read in The iPhone Store Impending Disaster Myth. Mainly because that article is fairly close to the top of my RSS feed reader.

The first thing to note is the use of loaded language in the title - the hyperbolic phrase "impending disaster" and its syzygy with the word "myth" clearly setting the author's stall out. This is reinforced by the first paragraph:

According to the predictable opinion scribes [...]They’re wrong, here’s why.

That first sentence fragment paints the subjects of the author's post as thoughtless machines, churning out page after page of text reinforcing their unchanging opinion. Ironically that is exactly what we are about to read for the next several paragraphs. It's a convenient amalgamation of two rhetorical techniques; most obviously it is an ad hominem (to the man) argument. Attention is diverted away from the discussion of Apple's app store and onto the people with which the author disagrees. This then is the beginning of a straw man which will be constructed toward the end of the piece, sowing the seed in the reader's mind that the author's opponent does not have a relevant argument.

The final sentence, "they're wrong, here's why", is a trademark of this particular author (or maybe that's an example of confirmation bias on my part) and actually renders the rest of the article meaningless for most people. It tells us that the rest of the article is a repudiation (for why it isn't a refutation, read on, but the point of this sentence is some verbal sleight of hand to make you believe that a refutation is to follow) of the position the author has defined for the "predictable opinion scribes", which is either going to make you believe that what's coming up will be an excellent riposte or a boring diatribe, depending on the opinion you've already formed about this author. All that the remaining part of the article needs to do is to fill up past the end of the page so that you believe the riposte/diatribe really exists, and it performs this task with aplomb.

What happens from here is actually rather subtle. The author outlines the position he intends to oppose, followed by "here’s[sic] the facts they’re missing". But the next few sections, from "Developers, Developers, Developers" to "Why Platforms Win" contain an opinionated retrospective on the computing industry, using links to the author's own articles as references. Opinionated? Well, count the number of times the phrase "third rate, old technology" appears. It's actually only four, but it moves from what "IBM, Microsoft, and the PC cloners [Oxford comma sic]" were doing to "the Microsoft strategy". There's enough filler (26 paragraphs and 10 linked articles in the same style by the same author) that it could be easy to forget that segue occurred. A fact which doesn't escape the author:

If you made it this far, you may have forgotten that the first argument against Apple vetoing apps

Too right we might have forgotten. What we haven't forgotten is that we were told "here's why" the app store naysayers were wrong, but have actually been told why Lotus 1-2-3 outsold Visicalc. The author's argument follows the pattern "B follows A. C. Therefore A." Loosely the argument could be described as a "red herring fallacy", although a word I prefer is that the intervening text underwent a process known as "contextomy".

Anyway, before we got here, our author let his façade slip a little:

Now let’s hammer away at the sappy pleading on behalf of developers who want Apple to cater to their whims due to the attractive populist concept of fairness in doing so.

Ooops! Now, do we think that the author is for or against people who disagree with Apple? Anyway, enough backtracking. Why don't we move forward from the end of my previous <q>?

[...] is that its decisions are unpredictable and arbitrary.

Now read the rest of that section. There's a good amount of text to describe why these decisions aren't arbitrary. Whatever happened to unpredictable? Oh, and for bonus points, look for where the final paragraph contradicts the earlier thrust of the section and reinforces the notion that arbitrary rejections have occurred.

The rest of the article carries on in the same vein, and having seen the way in which I automatically parse the earlier part you can probably guess how my cynical mind interprets the rest of the text. Oh, and speaking of cynicism, if you're still wondering why this is a repudiation and not a refutation, then my evil little mind-play trick worked! You've read at least part of every paragraph in the hope to get information I promised at the beginning; if only I'd put some adverts in the post somewhere. So to refute means to prove to be false, whereas to repudiate means to reject. The article we've just looked at is an internally inconsistent expression of the author's opinion, no proof having occurred. It's also an example of the informal fallacy of suppressed correlative. Apple's practices can't be bad, because Microsoft's practices are bad and Apple's are better than Microsoft's.

Well, that was fun! The next time you're talking to your boss (or better, your marketing people), listen out for those rhetorical devices and remember to stay critical :-).

AppleScript, for once

AppleScript isn't something I write much about, in fact this is the first post I've ever created on the topic. But AppleScript, like the Services menu and Automator, provides that most useful of usability enhancements: the ability to use multiple applications together without fulfilling the marketing requirements of having to look at them all.

As an example, a folder action script might let me combine the Finder with any other application, such as, choosing completely at random, Sophos Anti-Virus:

on adding folder items to this_folder after receiving these_items

  set theScript to "/usr/bin/sweep -nc"

  repeat with i from 1 to number of items in these_items

    set thePath to POSIX path of item i of these_items

    set theScript to theScript & space & thePath

  end repeat

  set theScript to theScript & space & "--quarantine:mode=000"

  do shell script theScript

end adding folder items to

that script then scans any file which appears in a particular folder and locks it if it contains a virus (up to a point). But that's not really the point, the point is that I haven't actually had to use any of the target apps in order to get this combined functionality. It's like I was able to summon the Megazord without having to actually talk to the individual Power Rangers. Erm, or something. And that, really, is how a computer should work; I didn't buy OmniFocus so that I could look at its icon, or a splash screen, I bought it because it can manage my lists of things to do. And I got iCal in order to manage events in time. If I have things to do at specific times, then I ought to be able to combine the two, and the computer can do the work involved. After all, that is why I bought the computer.

Overdoing the risk management

I own a notebook. In fact, I own several notebooks. One in particular has an interesting feature (where I use "feature" in the "different from the competition, though we don't know whether anyone actually needs it" sense); inside the front cover is space to write your address, and a dollar value reward available to the person who returns the notebook.

Now the notebook itself is probably worth about $20, but on the face of it a used notebook is worth less than a pristine notebook, with a full notebook having no value. Presumably the value of the reward should be related to the value of the notes contained within it, and therefore can't be ascertained until I've filled the notebook up. But then if I were to lose it before filling in the pages, I would not have entered an interim value; and if I had then whenever I made new notes I would need to update the worth of the book.

And who should be footing the bill, anyway? Are my musings of any financial benefit to me, or if my employers get more worth from them should they be contributing to the reward fund? Could I possibly make the same notes again were I to lose this book? Could I pay someone with a lower salary than mine to have thoughts with a similar monetary value? Would someone else who came across my notebook be able to extract the same worth from the contents than me? If so, should I write in an encrypted fashion? How much more would that cost me? Should the reward factor in the costs of decrypting the contents, possibly reverse-engineering the method if I've forgotten it?

Do ideas depreciate? Clearly patentable ideas do, will my ideas be patentable? Will I be able to benefit from the patents? If someone finds the notebook and returns it, are the ideas still patentable? What about non-patentable thoughts, do they all depreciate at a constant rate? Should the reward value be a function of time?

Clearly the only people who can answer all of these questions upfront, and therefore the people who can use this reward feature with confidence, are the people whose ideas can be modelled with a waterfall development process. Take Terry Pratchett; he might know that the content of one notebook equates to roughly 50% of a novel, and that each novel is worth £200k, and therefore the value to him of the notebook is less than £100k. A thought process which eventually results in a cash value for a notebook. For those of us whose ideas are somewhat more iterative (read: chaotic), this seems like a complete misfeature.

Me.com. Your identity, everywhere.

Title linky goes to a Sophos blog post I wrote about the relative success of MobileMe phishing scams, and the insecurity of MobileMe web access.

Apple 2, iamleeg 0

So, my few-year-old iPod decided it had had enough, and with pay day having only just passed I thought maybe it would be nice to get a new one. What's happened today? Got the new one home, and it won't work at all (searching for "error 1434" isn't particularly useful, either). However, the one that previously broke, having now been taken apart, started working again. So my 20GB 4G iPod is now humming along nicely (running Podzilla), and my 160GB classic is b0rked :-(.

The twitter sitter hit a bitter critter

Yup, more on the subject of a home-grown Twitter client. This time, posting and sorting out the UI somewhat have both been achieved:



Posting tweets is amazingly simple - just take the tweet and stuff it into the body of a POST NSURLRequest. The Twitter API even handily returns the posted tweet, so the same code which parses the friends timeline can also insert the new tweet.

So, where to go next? Well, I'm getting bored of typing my password in all the time so Keychain would be nice, @reply buttons and perhaps searching. I'm going to need cache management soon, too.

Mac user Gmail account hack

I found today in Macintouch reader reports the news that a Mac user found his Gmail account had been taken over. He writes:

I woke up this morning and looked at my gmail and thought, gee that's weird, it won't accept my password. I figured it was a glitch and tried it on my iphone, same thing.

Then I asked for a password reset. When I got back into the account, found a bunch of sent emails from a Nigerian scammer. I also looked at the ip history in gmail and noticed the weird IP, which of course came from Nigeria.

This relates well to a point I've made repeatedly in podcasts and papers; namely that having information worth stealing is not a Windows-only situation. As more data is stored "in the cloud" then the security of the cloud and of the way we use it becomes as important what is going on in our own computers. Having a weak Facebook password compromised will work just as well if you're on Trusted Solaris as Windows.

In other news, yesterday's Twitter client is not really much further along, because a thunderstorm has meant I've unplugged all of my electronics (the laptop isn't plugged in to anything, obviously). I am now very grateful to MarsEdit for having offline editing capability, otherwise I'd have to try and remember all this stuff later ;-)

A better bit o' twitter than the bitter twitter Tommy Titter bought

Just because everyone these days writes a Twitter client:



This was actually a quick hack project to make up for the fact that I missed CocoaHeads tonight (due to a combination of an uninteresting phone call, and a decision to recover from the phone call by using the rest of my petrol tank). Really just an excuse to play with some APIs (the tweets are grabbed by the controller using NSURLConnection, then some NSXML/XPath extracts the useful information (or not, it is Twitter after all) and puts it into the model), there are many things which need to happen before this is at all a useful Twitter client; the ability to write back, nicer formatting are just the starters. Shiny Core Animation twitting ought to happen.

Still, not bad for two hours I think.

Fuzzing as a security testing tool

Google have a new browser project, called chrome, and in their introduction they explain perfectly, through the medium of image, how fuzzing works.

Of course, as anyone could tell you, if you take a thousand monkeys and a thousand typewriters and put them all in a room for long enough, you will end up with a thousand broken typewriters, ten fat monkeys and 990 monkey skeletons.

Walking a mile dans ses chausseurs

The word 'translator' has an interesting history. In the Anglo-Saxon language, 'wealhstod' meant "learned in Welsh" more or less, and described someone who could parlay with the important members of the local British tribes. As is often the case with invasions the British started to use the word, so the Welsh title 'Gwalstawt' means "interpreter of tongues", i.e. the Welsh word for "can speak another language" originally meant "can speak Welsh" (there's another word more closely related to Breton treiñ or Cornish trélya in Welsh, too; trosi).

Anyway, to see what localisation people go through during the l10n process, I decided the best thing to do was to try it myself. To save the time it would have taken to write an internationalised app, I used someone else's; namely TextEdit. Here's the result after about 90 minutes of work:

The first thing to notice is that I haven't actually got much done yet. I've started working on the main menu NIB file (Edit.nib), and I'm about halfway through that. At this rate, it would take me at least a (working) day to finish - granted I'm no expert at the task, so I'm having to make a more heroic effort on otherwise "standard" translations than most localisers would. Although I do have a glossary to help. Even so, TextEdit is a fairly simple app; it's easy to see that even if the translation became a mechanical process, translating a complex program would take a long time.

The other thing you might have noticed is that Mac OS X doesn't actually support Old English, and yet that's the language of my translation. There's a simple trick here; convince Mac OS X that it does support Old English ;-). Type this command in the Terminal:

$ defaults write NSGlobalDomain AppleLanguages '(ang, en, /* other languages */)'

and Robert, as they say, is your father's brother. Apps will now look for localised resources in 'ang.lproj' when they start, so that's where your Old English resources live.

Next CocoaHeads Swindon meeting

1st September (that's this coming Monday), in the Glue Pot, Swindon. 8:00pm start. Chris Walters will talk about, well, something, and we'll be drinking beer, listening and occasionally chipping in. See you there!

So are Macs uber-pricey?

No, but Sony Vaios are.

Back from holiday

I went on holiday to Stockholm this week. Of the ~1.5GB I downloaded from the camera, this was the photo I thought most apt to describe the experience on this blog:

Cocoa#, Mono and Me

My great application:

Yeah, OK, not so great. But this Inverse Hoffman is the result of a couple of hours hacking in Mono, with Cocoa#. My app's largely based on the Stupid Word Counter tutorial, though it's a from-scratch implementation of the famous Apple/NeXT sample application in C#.

Firstly, a little history. My first encounter with .NET was back in about 2003 at a Microsoft Developer Roadshow in the car park (and later lecture theatre) in Oxford's comlab. I was particularly interested in their discussions of cross-platform capability, Project Rotor (I kept in touch with one of the Rotor developers) and so on, but really didn't see much exciting in .NET. Nonetheless, being a fair man, I took my beta CDs of Windows 2003 and Visual Studio .NET and gave them a whirl. Unfortunately, still not much interesting. Largely due to buggy betas and a lack of beta documentation.

Now accessing Cocoa from non-ObjC languages is nothing new, we've been doing it from Perl, Python, Ruby and Java for ages and partcularly old farts might even remember Objective-Tcl. Why should I care about Cocoa#? Well for a start, there are likely to be a lot Windows developers out there with some (language that boils down to MS IL eventually) skills who are wanting to produce Mac applications, and it'd be interesting to see what we'll end up with when they do. And it's always fun to learn a new language, anyway ;-)

Good points

• Real NIB files. No really, that interface is genuinely an IB 3.x NIB based on the Cocoa Application template. The objects inside it are Objective-C objects, and there are good old outlets and actions (I haven't yet investigated whether Cocoa Bindings would work).


• macpack. A command-line tool which takes your IL executable and wraps it up in a Cocoa application bundle, ready for drag-deployment.


• Good inline bridging information. Unlike, say, PyObjC the language bridge isn't completely dynamic, but unlike the Java bridge or JIGS you don't have to keep a separate manual mapping of real classes onto ObjC shams. For instance, here's the controller from Currency Converter.net, complete with class, ivar and method exports:

namespace info.thaesofereode.CurrencyConverter
{
	[Cocoa.Register("CurrencyConverterController")]
	public partial class CurrencyConverterController : Cocoa.Object
	{
		public CurrencyConverterController(System.IntPtr native_object) : base(native_object) {}

		//Cocoa IBOutlets
		[Cocoa.Connect]
		private Cocoa.TextField inputCurrency;
		[Cocoa.Connect]
		private Cocoa.TextField outputCurrency;
		[Cocoa.Connect]
		private Cocoa.TextField conversionRate;

		//Cocoa IBAction
		[Cocoa.Export("calculate:")]
		public void calculate(Cocoa.Object sender)
		{
			//get the rate from the view
			System.String rate = conversionRate.Value;
			CurrencyConverterModel.Rate = System.Convert.ToDouble(rate);
			//get the currency
			System.String input = inputCurrency.Value;
			System.Double output = CurrencyConverterModel.convert(System.Convert.ToDouble(input));
			//update the UI
			outputCurrency.Value = System.Convert.ToString(output);
		}
	}
}

Bad points

• Not very Cocoa-like wrapper classes. I think this is deliberate; they've gone for making the Cocoa shim look like a .NET interface because after all, we're programming from .NET. This is a bit disappointing as I'm more familiar with PyObjC and the Perl-ObjC-Bridge where the APIs are left pointedly alone, but given the target audience of Cocoa# it's unsurprising.


• MonoDevelop. Luckily, using it isn't mandated.

So, overall, one more good point than bad (and a tentative two, if you overlook MonoDevelop); a pretty good initial evaluation and I might give this a deeper scrape.

Microblogging

For a long time, I deliberately avoided microblogs like twitter. I thought that they were simply an acknowledgement that people want to be published more than they want to have something to say. However, it would be rude of me to completely disavow the medium without actually giving it a go.

To that end, I may indeed be iamleeg on twitter, as soon as twitter actually finishes processing the signup form.

I'd like to point out that one problem I'm going to have is brevity - I have spent 650 characters telling you what my username is. Constraining myself to SMS-sized wibblings will indeed be tricksy.

Common sense writ large

Looking at the bottom of Apple's Q3 results, as indeed with any similar publication from a US publicly-traded company, we see the following text.

This press release contains forward-looking statements including without limitation those about the Company’s estimated revenue and earnings per share. These statements involve risks and uncertainties, and actual results may differ. Risks and uncertainties include without limitation potential litigation from the matters investigated by the special committee of the board of directors and the restatement of the Company’s consolidated financial statements; unfavorable results of other legal proceedings; the effect of competitive and economic factors, and the Company’s reaction to those factors, on consumer and business buying decisions with respect to the Company’s products; war, terrorism, public health issues, and other circumstances that could disrupt supply, delivery, or demand of products; continued competitive pressures in the marketplace; the Company’s reliance on sole service providers for iPhone in certain countries; the continued availability on acceptable terms of certain components and services essential to the Company’s business currently obtained by the Company from sole or limited sources; the ability of the Company to deliver to the marketplace and stimulate customer demand for new programs, products, and technological innovations on a timely basis; the effect that product transitions, changes in product pricing or mix, and/or increases in component costs could have on the Company’s gross margin; the effect that product quality problems could have on the Company’s sales and operating profits; the inventory risk associated with the Company’s need to order or commit to order product components in advance of customer orders; the effect that the Company’s dependency on manufacturing and logistics services provided by third parties may have on the quality, quantity or cost of products manufactured or services rendered; the Company’s dependency on the performance of distributors and other resellers of the Company’s products; the Company’s reliance on the availability of third-party digital content; and the potential impact of a finding that the Company has infringed on the intellectual property rights of others. More information on potential factors that could affect the Company’s financial results is included from time to time in the Company’s public reports filed with the SEC, including the Company’s Form 10-K for the fiscal year ended September 29, 2007; its Forms 10-Q for the quarters ended December 29, 2007 and March 29, 2008; and its Form 10-Q for the quarter ended June 28, 2008, to be filed with the SEC. The Company assumes no obligation to update any forward-looking statements or information, which speak as of their respective dates.

Erm, like, duh. Stuff which we say might happen in the future, might not actually happen. Really? You've got to get out of the financial industry, there's a lucrative career ahead of you in construction.

Designing a secure Cocoa application

That's the title of next month's CocoaHeads Swindon, and I'll be leading the presentation/discussion. So if you want to learn a little about how to ensuring your Cocoa app doesn't give away the keys to the kingdom, or have some experiences to share with the rest of the group, come along! We'll be at the Glue Pot, which is nice and near the train station as well as reasonably close to a car park. We'll be congregating at 7:00 but will wait for everyone to be settled with a beer in their hand before starting ;-).

Ah, the sweet sound of my own voice

The title is a linky to the press release regarding the edition of Sophos Podcasts I recorded with Carole, and which has now (clearly) gone live. In it we mainly talk about the data theft and Macs technical paper I've already posted about. This is the first podcast I've ever been involved in, so any feedback you have (apart from telling me that I sound drunk in my first sentence, I'm not sure what that's all about) will be most welcome!