If you use GrowlMail, you’ll be disappointed to learn that it doesn’t work on Snow Leopard yet. Since I keep my dock hidden, without GrowlMail I don’t know that I’ve received mail unless I roll over the dock, which is frustrating and adds a little bit of background anxiety to my day.

While the awesome Growl team are working on a fix, here’s a small AppleScript that I wrote to give me a notification whenever a mail arrives. It’s less functional than the full thing because it doesn’t tell you anything about the mail other than it has arrived.

There’s no title, summary or who it’s from like there is with GrowlMail, but that’s good enough for me as a stop gap. If you figure out a way to include those details, I’d love to hear about it though.

Anyway, the script.

tell application "GrowlHelperApp"
   set the allNotificationsList to {"New Email Arrived"}

   set the enabledNotificationsList to {"New Email Arrived"}

   default notifications enabledNotificationsList icon of application "Mail"

   notify with name "New Email Arrived" title "New mail" description "New mail arrived." application name "Mail Notifier"
end tell

Copy that into AppleScript Editor (as it is now called in Snow Leopard), or you can download it from here. Save it somewhere sensible (I used /Library/Scripts/Mail Scripts)

Then, add a rule to Mail for every mail that arrives and have it run the AppleScript. Here’s a screenshot:

And that’s all there is to it. Hope you find it helpful.

Here’s a snippet from a transcript of a panel discussion that he seems to have invited himself into:

Milo: Finds this discussion patronising to women. There are reasons which have nothing to do with prejudice why women are not more involved in the tech scene. Do we need to change the game? [...] No! We shouldn’t be apologising for having fewer women in a sector in which men naturally perform better

His argument boils down to “men and women are different, men are better at tech, deal with it”. This is bullshit. Here’s why.

Milo seems to think that technology is a pure meritocracy, and that we can therefore say that because there are fewer women in tech we can draw the conclusion that women are not as good at it as men. But this argument doesn’t fly.

While women are under-represented, there are also comparatively few people from ethnic minorities in programming jobs in the UK. However there are quite a lot of people from ethnic minorities working in more lowly (i.e. less well paid) technology jobs like first line support and so on.

Are we therefore to draw the conclusion that white people are genetically best suited to be programmers? Of course not. Descrimination is there at every level of tech, just as it is with so many other walks of life. Programmers in the UK are overwhelmingly white, male and under forty.

Over the course of my career, I’ve had discussions with colleagues about whether a candidate is “too old”, has “good enough English” (which is code for “white”) and more. I’ve had people ask me “did she have big tits?” after interviewing a woman for a development or project management job. I’ve been told that a candidate is “interesting”, with a coy little wink, which is code for “gay”. I’ve seen pats on the bum, “morning, beautiful” and other clearly sexist acts. These things have come from senior people as often as not. They are normally laughed off as being nothing harmful, just a bit of fun. If women can’t take them then “they don’t fit in”. These prejudices are there and they need to be attacked.

We also need to constantly remind ourselves that technology is, on the whole, quite shit. Large-scale software development is still incredibly hard and huge numbers, perhaps even the majority, of projects fail. We have no laurels to rest on. The technology industry needs to change, and increased diversity can only be a good thing.

Of course this is only my experience – nearly 20 years of it now – but I’ve worked with brilliant female developers as well as crap ones, just as I’ve worked with both brilliant and crap male developers. Brilliant developers are *very* rare, and the difference is not in the chromosomes.

It’s not that long since we debated whether “allowing” women into the Vienna Philharmonic would change the orchestra’s distinctive sound (it didn’t), or whether women were capable of running a marathon (they are). These barriers have been torn down and exposed for the simple sexism they were. The same needs to happen in the tech industry, and the sooner it happens, the better.

If you want to try out the beta, head on over to the product page at Puffing Bear and download it today.

I will hopefully be ready to release a version 1.0 of Shrinker fairly shortly. It’ll be free in the sense of “free beer”. Its primary purpose was as a learning project for me, so I’m not interested in opening the source at the moment. That doesn’t mean I won’t be at some point in the future, though.

I’m making it free for a few reasons. First, I don’t think I’d make any meaningful amount of money out of it. Second, it was conceived as a learning project for me, and to scratch my own itch – a lack of a similar tool for the Mac. And, finally, I’ve received so much wonderful help from the Mac developer community, both directly and through searching blogs and mailing list archives, that I felt I should try to contribute something back. I haven’t got around to it yet, but there I’ll put a full list of acknowledgements in the About panel and on the website before I release version 1.0

I hope you like Shrinker, and please let me know if you find any bugs or have any suggestions.

Initially, I thought that the way to do this was to add an additional section to the table and add a custom cell to it. That kind of works, but is quite hard work. I think I’ve found a better and simpler way – by using the tableView:viewForHeaderInSection method on UITableViewDelegate.

To start with, we need to create a basic view-based Cocoa Touch app in XCode. I’ve called mine ContactStylee. I’ve zipped up the completed XCode project for you so that you can follow along.

Once we’ve got the basic project template, we need to implement the UITableViewDataSource in our ContactStyleeViewController. As usual, this consists of implementing tableView:numberOfRowsInSection and tableView:cellForRowAtIndexPath. I also create a simple NSArray to hold some sample data in the viewDidLoad method. Here’s the interface file:

@interface ContactStyleeViewController : UIViewController
	<UITableViewDataSource, UITableViewDelegate> {

	NSArray *data;
	ContactStyleeAppDelegate *appDelegate;
}

@property (nonatomic, retain) NSArray *data;

@end

And the implementation:

@implementation ContactStyleeViewController

@synthesize data;

- (void)viewDidLoad {
   	[super viewDidLoad];
	self.data = [NSArray arrayWithObjects:
		@"First", @"Second", @"Third", @"Fourth", nil];
}

- (NSInteger)tableView:(UITableView *)tableView
	numberOfRowsInSection:(NSInteger)section {

	return [self.data count];
}

- (UITableViewCell *)tableView:(UITableView *)tableView
	cellForRowAtIndexPath:(NSIndexPath *)indexPath {

	UITableViewCell *cell = [tableView
		dequeueReusableCellWithIdentifier:@"normalcell"];
	if(nil == cell) {
		cell = [[[UITableViewCell alloc]
			initWithFrame:CGRectZero
			reuseIdentifier:@"normalcell"] autorelease];
	}
	cell.text = [self.data objectAtIndex:indexPath.row];
	return cell;
}

- (void)dealloc {
	[data release];
	[super dealloc];
}
@end

All pretty standard stuff. In the NIB, I’ve set the table to have the “Grouped” style. Here’s what that looks like when we run it in the simulator:

So now we need to create the header view. I did this by adding a new View NIB to the project, calling it TableHeader. I then created a new view controller class, called TableHeaderViewController, and then set the class for the File’s Owner in the TableHeader.xib file to the new controller class. You need to remember to tell the File’s Owner about the view. I added an image and a couple of labels. For the purposes of this demo project, that’s all that’s needed in the header view: we won’t bother hooking it up to the data source for now.

To be able to reference the view from the ContactStyleeViewController, I added a new view controller to MainWindow.xib and made its class TableHeaderViewController, and we tell it to load the view from TableHeader.xib. I then added an IBOutlet of type TableHeaderViewController to ContactStyleeAppDelegate. This means that I can load that controller’s view from the app delegate.

Now that we’ve got the controller outlet and property in our app delegate, we need to hook that up in IB. So we make the new view controller that we just added to MainWindow.xib point to the new IBOutlet that we just added in the ContactStyleeAppDelegate. Here's how the app delegate interface file looks now:

#import <UIKit/UIKit.h>

@class ContactStyleeViewController;
@class TableHeaderViewController;

@interface ContactStyleeAppDelegate : NSObject <UIApplicationDelegate> {
	UIWindow *window;
	ContactStyleeViewController *viewController;
	TableHeaderViewController *headerViewController;
}

@property (nonatomic, retain) IBOutlet UIWindow *window;
@property (nonatomic, retain) IBOutlet ContactStyleeViewController *viewController;
@property (nonatomic, retain) IBOutlet TableHeaderViewController *headerViewController;

@end

Now we need a way for the ContactStyleeViewController to access our TableHeaderViewController. To do this, we add an IBOutlet of type ContactSyleeAppDelegate to our ContactStyleeViewController and then connect that up to our app delegate in IB. Here's the revised ContactStyleeViewController interface file:

#import <UIKit/UIKit.h>
@class ContactStyleeAppDelegate;

@interface ContactStyleeViewController : UIViewController
	<UITableViewDataSource, UITableViewDelegate> {

	NSArray *data;
	ContactStyleeAppDelegate *appDelegate;
}

@property (nonatomic, retain) NSArray *data;
@property (nonatomic, retain) IBOutlet ContactStyleeAppDelegate *appDelegate;

@end

Note that we need to forward declare the ContactStyleeAppDelegate class rather than importing the header file in order to avoid a circular include. Once we've hooked up this outlet to the app delegate in IB, we're almost ready to go. We just need to tell the table view where to get the header view from.

To do this, we need to implement two new methods in ContactStyleeViewController that are optional methods on the UITableViewDelegate protocol, tableView:viewForHeaderInSection and tableView:heightForHeaderInSection. These are pretty simple methods now that we've hooked up the app controller outlet:

- (UIView *)tableView:(UITableView *)tableView
	viewForHeaderInSection:(NSInteger)section {

	return [[appDelegate headerViewController] view];
}

- (CGFloat)tableView:(UITableView *)tableView
	heightForHeaderInSection:(NSInteger)section {

	return 85;
}

At this point, I reckoned I was done, so I built and ran the app in the simulator. What I saw wasn't quite what I had expected:

The header cell has an opaque white background, which is not what we wanted at all. We need to make a few simple adjustments in IB. Here's what the inspector looks like when the changes have been made (and you need to be careful that its the view that's selected in IB, not one of the controls):

You need to make sure that the "Opaque" checkbox is cleared, and that you set the background colour to have a 0% opacity. And that's it. Here's a screenshot:

And here's a video showing that it scrolls just like the built-in contacts app:

It took me a while to figure out that this was the best way. Hopefully this post will help someone else to get there quicker. But, since I'm strictly an iPhone development beginner, I'd be really interested to hear from people if they think there's a better way to do it.

It shows that they’re asking the wrong question. The flurry of new touchscreen devices – the BlackBerry Storm, the LG Incite (tagline: “Windows Mobile at its most intuitive”, which is kind of like saying “shit at its least smelly”) and so on – show that the boards of mobile phone companies have, in effect, told their R&D teams to create an iPhone clone.

And there’s the problem. You can’t clone the iPhone, because Apple have done such an amazing job on the design, usability and functionality that, if you’re in the market for a touchscreen phone, you’re probably going to automatically choose an iPhone. And that’s before you’ve had a play with your friend’s iPhone. I’ve never owned any other device that has made my friends *laugh* when they see how awesome it is.

There are still a few things that might hold you back: years of hearing that Macs aren’t as good as PCs (just pop into your local Apple Store if you want to find out how wrong-headed that is), the price of the monthly contract, and maybe not wanting to be on O2 due to coverage issues in your area (or AT&T or whoever the carrier is in your country). And you may just not want to be a sheep. But once the exclusive deals expire, surely the iPhone will be available on all networks and most of those concerns will go away.

But there are still a huge number of people who are not in the market for an iPhone at all. People who don’t want such a large phone, who don’t want email, or an iPod on their phone, or a mobile gaming device, who probably don’t even need a camera, and who will probably never download apps. Although the iPhone has been a massive success – when very few predicted it would be – it still only has a fraction of the market for handsets.

I boldly predict that the next big-selling phone will be designed by people who look at the iPhone and ask: “who isn’t going to want one of these?”, “why?”, and “how can we build them a phone they *do* want?” Until then, Apple will continue to eat the establish players’ lunch.

Update: fixed silly typo

The biggest change from using Visual Studio and .NET has been that the visual tools actually seem to work without screwing with your work. I’m not pushing it very hard yet, so that will probably change. I’m still nervous that I don’t understand the underlying serialization format.

I’ve been using Bill Dudney‘s Screenscasts on starting iPhone development, and his forthcoming iPhone development book, both from the Pragmatic Programmers, which have both been excellent. As a result I’ve got the basics of an iPhone app that I think could turn into something that people might actually want to install on their phones. There’s a lot of work to be done before I get to that stage, though.

In an attempt to give myself a hard deadline for learning, I also signed up for NSConference, a Mac developers conference to be held in April, organised by Scotty from the Mac Developer Network. If you’re at all interested in iPhone or Mac development it looks like the place to be. Hopefully I’ll see you there.

When you navigate to an HTTP URL with a dodgy certificate in a browser, you get a warning that gives you the option to ignore the problems. In code, this just results in an exception being thrown. The exception is a System.Security.Authentication.AuthenticationException (wrapped in a System.Net.WebException), with an error message of “The remote certificate is invalid according to the validation procedure.”

So, for testing, we needed to find a way to bypass the certificate validation. It turns out that you need to provide a RemoteCertificateValidationCallback delegate and attach it to ServicePointManager.ServerCertificateValidationCallback. What’s not clear is what happens if two threads are competing to set this property to different values, since it’s a static property. Reflector suggests that the property set method doesn’t do anything fancy, so you could easily get into a race condition.

Anyway, here’s s snippet that shows how to do this. Hopefully someone will find it useful, because it took me a while to find.

 // callback used to validate the certificate in an SSL conversation
private static bool ValidateRemoteCertificate(
object sender,
	X509Certificate certificate,
	X509Chain chain,
	SslPolicyErrors policyErrors
)
{
	if (Convert.ToBoolean(ConfigurationManager.AppSettings["IgnoreSslErrors"]))
	{
		// allow any old dodgy certificate...
		return true;
	}
	else
	{
		return policyErrors == SslPolicyErrors.None;
	}
}

private static string MakeRequest(string uri, string method, WebProxy proxy)
{
	HttpWebRequest webRequest = (HttpWebRequest)WebRequest.Create(uri);
	webRequest.AllowAutoRedirect = true;
	webRequest.Method = method;

	// allows for validation of SSL conversations
	ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(
		ValidateRemoteCertificate
	);

	if (proxy != null)
	{
		webRequest.Proxy = proxy;
	}

	HttpWebResponse response = null;
	try
	{
		response = (HttpWebResponse)webRequest.GetResponse();

		using (Stream s = response.GetResponseStream())
		{
			using (StreamReader sr = new StreamReader(s))
			{
				return sr.ReadToEnd();
			}
		}
	}
	finally
	{
		if (response != null)
			response.Close();
	}
}

So am I.

(Click for larger version

And I didn’t Photoshop it, either.

(Click for larger version)

I predict that the iPhone SDK will be seen as a watershed in the history of computing, as important as the the first PC. For the first time, proper mobile computing will be a reality.

I can’t wait to get started developing my first app.