Friday, July 4, 2008

Trade schools and CS departments

Trade Schools

I just read this article on Hacker News about how IT graduates in the UK are struggling to find work because they don't have the skills that businesses are looking for. I've seen this same kind of article for US Computer Science grads as well. It seems like what IT really wants is trade school graduates. Someone who should be going to DeVry to learn the J2EE stack or .Net and is only doing so for the paycheck, not genuine interest in software development.

When I was in college (1996-2001), I would say an overwhelming majority of the CS students were there solely for all those tech jobs that their parents read about. They were only interested in learning something for either a grade in class or that someone might hire them to do it. Really, trade schools should be handling those types of people. It wouldn't take 4 years to learn the material and the curriculum wouldn't need to force unrelated classes on students who aren't interested in being "well-rounded." IT shops could snap up these graduates and the grads can start writing glue code for the enterprise software their employers bought. Everybody's happy, right?

Computer Science Departments

This would thin out CS departments, which university admissions would perceive as a bad thing. They don't really care if you learn anything in their schools, just that you pay your tuition on time. Less students = less money. But actually, CS students would benefit most from this. That is CS students who are more interested in science and theory for science and theory's sake. Class sizes would be smaller. Not only that but, given that you have professors that really want to teach as opposed to just doing research, you would better enable these professors to do just that.

Middle Ground

What I'd really like to see is a middle ground for people who want to do more with their lives than rot away in an IT department writing glue code for software that employees are forced to use rather than want to use, and also are more interested in practical application of software beyond research and academic interests. I'm not knocking CS students who really want to further Computer Science through research. We definitely need those people. However, I'm sure there are plenty of people who don't want to do either one of these things.

Startups and indie development are the goals of what I'm talking about. Hacking on open-source projects is good for building your skills and meeting other developers online, but if you're not fortunate enough to live physically near people with similar interests, you can miss out on the benefits of constantly being around such people. What we need are places where aspiring developers and designers can come and learn together. We can teach each other, and work together on projects that interest us. It should be kept informal. If everyone's intentions are honest, some really great software and companies could spawn from this.

I clearly haven't thought this out. It may not really be possible considering that everyone has expenses that they have to pay somehow. It may work better in a small conference format, than some sort of institution. But I think that anything that allows people to realize what could be their true calling, would be of great benefit to all of us.

Wednesday, November 21, 2007

Customizing errors generated by NSFormatters

I'm posting this because I was having a problem with errors generated by NSFormatters and saw a thread on it in the cocoa-dev archives that ended in a possible feature enhancement request with no Radar bug number to track.  After much experimentation, I think I've found a solution.

If you're working with NSFormatters (especially NSNumberFormatter), and you want some control over the default "Formatting Error" alert that you get when you give the formatter a string it cannot format, there is a way to do this.

In my situation, I had an NSTextField with an NSNumberFormatter attached to it.  The text field is bound to an attribute of a Core Data entity via NSObjectController.  The owner of the NIB file that contains all of this is an NSWindowController subclass.

At first, if I put a non-numeric string in the text field, I would get an application-modal alert stating "Formatting error" with the buttons "Discard changes" and "OK".  I'd much rather have something more descriptive, like "This field requires a numeric value".  If you override the willPresentError: method in the NSWindowController, you can inspect the NSError that is used to create the default alert.  You won't find anything too helpful, though.  The domain is NSCocoaErrorDomain, the code is NSFormattingError, and the userInfo dictionary has the "Formatting error" string, and an internal recovery attempter.

The solution I used, was to make the NSWindowController the delegate of the NSTextField, and to implement the NSControl delegate method:

- (BOOL)control: (NSControl*)control didFailToFormatString: (NSString*)str errorDescription: (NSString*)errDescription

From this method, you can inspect the string the user entered, and create your own NSError with a more descriptive message.  But, in order to get this custom NSError to appear instead of the standard one, you can use:

[control presentError: err]; return YES;

or for the alert to appear as a sheet:

[control presentError: err modalForWindow: [self window] delegate: nil didPresentSelector: NULL contextInfo: NULL]; return YES;

You need to return YES, or else you'll get both your custom error and the standard error.

If you need to determine which attribute was being edited, you can create IBOutlets in the NSWindowController, connect them to the fields with formatters, and then compare the control parameter against these outlets.

Hopefully this saves someone some time.