I still can't believe I bought a cook book. This doesn't mean I'm going to cook anything.
Now, lets see about that Green Tea Panna Cotta with Rhubarb...
I still can't believe I bought a cook book. This doesn't mean I'm going to cook anything.
Now, lets see about that Green Tea Panna Cotta with Rhubarb...
Jarrah was celebrating her change of job at the Belgian Beer Cafe. It was good to catch up with her and her better other half, Brettski (as well as Sven, but more on that later). Its not often I get to catch up with those guys, and I always wish it could be longer. Seeing her in "business attire" was kinda funny too :P
The problem with the infrequent catch-ups is that you lose common ground for conversation, and once you've done the usual "so what have you been up to then?" type pleasantries I'm sorta lost for anything to talk about (I don't have what people would call 'good social skills'). Except the common ground that we all have - work. Sure, the purpose of tonight's celebration was work (Jarrah is celebrating a change of job), but still, as we were leaving Brett mentioned that I should update my blog more often so he could read about me bitching about work :P And it's true, I do bitch about work a lot. I don't mind that, but I sometimes worry that I'm being seen as someone who's always bitching about it - a thin line sometimes.
I think that bitching about work is not a bad thing, if you have the right frame of mind about it. I use this space as a place to let people know what I think of things. If something is on my mind and is pissing me off, I will probably say something about it here. Usually, if work is going well, or I've vented in some other forum, or nothing much is really happening, then I won't mention anything. It's kinda cathartic to put it all down on the digital landscape, and it gives you an opportunity to come back later and see how your perception of things changes over time. Sometimes the things I write here are more for myself than for other people, but I don't mind others seeing my thoughts: I am what I am, and what I think is a big part of what makes up me. (Whether or not it's just a bunch of pretentious wank is another story).
But for now, I can stop my bitching about Curtin. I've had my rants and tantrums, bitched about it, etc etc. But I handed in my resignation today. iiNet invited me to apply for a programming position in the Applications department, and after going through the interview process offered me a job.
Over the past year and a half I've had a lot of time to reflect over my previous employment at iiNet, and the things that caused me to leave. I think that the problem was two fold: I didn't fit with the way that iiNet worked (in my area, at least); and I couldn't handle not fitting with iiNet. No matter how I want to put it (the technical aspects of my reasoning at the time, the project work what wasn't proceeding, etc), that's all it boils down to. It doesn't mean that either one of us is more right or wrong than the other, but we're just different (although I still have opinions about that for some things).
People don't normally change much over a year and a half, or even up to 5 years. But I feel that I have, at least a significant amount for me. I worry that I'm not making the right choice to move back to iiNet, but I'm still going to. I want to. I've regretted not taking the opportunity to move into that team when I had the chance, and I feel that I'm in a much better position, mentally and emotionally, to approach the problems that really bugged me last time I was there. I reckon I'll still bitch about "My Crap Job" - that's just what I do. I think it helps me sort out what I feel about the situation. It helps me be more honest with myself, in turn allowing me to be critical of myself with a view to improving things. And even though I'll probably end up bitching about stuff, I'm looking forward to the challenges, both personal and professional, that are going to come from this job.
So yes, the Bitching Will Continue Until Morale Improves. You don't have to worry, Brett, I'll still be bitching about my job once the New Shiny Job Smell wears off :)
Don't you love it when two blog posts you were going to write come together nicely as one?
For various reasons, I'm trying to brush up on my Perl skills, specifically focusing on Perl's OO framework. This involves reading the relevant man pages on the topic.
One thing that I've always been wary of playing with is the AUTOLOAD feature. I've known of its existence, but I haven't really had a chance to play with it. In a script I wrote last week I compared the AUTOLOAD method of defining methods to the more traditional way of defining a accessor/mutator method for each instance variable. With correct preparation, the AUTOLOAD way is a lot easier than the other way (even if you use a common function to do the work).
One of the disadvantages is that you lose some degree of control, which you have to build back into your object. The first thing to worry about is what instance variables are allowed. Controlling this is achievable through the method supplied in the perltoot man page:
my %fields = (
name => undef,
age => undef,
peers => undef,
);
sub new {
my $that = shift;
my $class = ref($that) || $that;
my $self = {
_permitted => \%fields,
%fields,
};
bless($self, $class);
return($self);
}
This works really nicely because your AUTOLOAD method can inspect how it was called (ie: the name) and determine what it member its working on. Then it can consult the _permitted instance member to determine if that member exists, and can raise an error if it doesn't. This method also automatically populates and initialises the instance variables for you. The downside of this is that if you inherit from this you have to work a little harder to get it to work right. Also, you still can't enforce typing (which can be handy if you don't trust code).
A better combination that I'm thinking about is to define an object framework which handles initialisation, typing, and inheritance. Essentially its the same as above, but %fields is modified to contain initialisation and type information too. You then call a method to insert the modified %fields has for you, and populates the type information in the _permitted field. Easy. It could even be extended to think about permissions (eg: public, private, protected), and even extra code snippets to run if required (but you might as well explicitly define a function in that case). Coupling this with AUTOLOAD should make things nice and easy.
Another problem I considerred is that the AUTOLOAD'ed methods may not cater for everything when inherited, or you may want to autoload your methods and a super class is is autoloading some of theirs (or maybe not - who knows?). Basically, if you define an AUTOLOAD method, you may want to defer to a superclasses AUTOLOAD method for things that you can't handle. So I wanted to figure out how to do that:
sub AUTOLOAD {
my $self = shift;
my @args = @_;
my $sub = $AUTOLOAD;
$sub =~ s/.*://; # strip fully-qualified portion
# my stuff goes here
# defer to super's autoloaded methods
$sub = "SUPER::$sub";
return($self->$sub(@args));
}
It has problems still. For example, if DESTROY is called if there's no SUPER::AUTOLOAD and no defined DESTORY method, you'll get an error. I think the correct way of handling that would be to create your own DESTROY method, and then pay particular attention to the class you inherit from and call its DESTROY method if available and appropriate. (I tried calling SUPER::DESTROY from DESTROY when it didn't exist, and it didn't raise an error, even when using strict pragma and warnings, so perhaps the generall guideline would be "if you defined AUTOLOAD, define DESTROY and have it call SUPER::DESTROY").
I'm interested in how other people tackle the problem, because I'm just making this shit up as I go along. I don't know what the "best practices" are in this area - perhaps its just safer to leave the whole AUTOLOAD thing alone for the time being...
Two interesting articles posted on Slashdot today:
The Six Dumbest Ideas in Computer Security
Computer Security is a myth that is perpetuated mainly by those with a product to sell. The general assumption is that security in computing is achievable, yet time after time we see that this isn't the case. Rather than focusing on specific solutions and methodologies, this article attempts to highlight the reasons why the contemporary way of thinking about computer security is contributing to the problem. While I partially don't agree with points 3 (the "Penetrate and Patch" approach should still be employed even with a secure design approach) and 5 (there needs to be a balance between education and native usability), the ideas in here are solid and well thought out. I believe the "trust nothing" approach can be applied to all aspect of all computing systems. With that first and foremost in mind in any computing related endeavor, Computer Security should be more achievable than without it.
Don't dumb me down
I don't know about you, but every time that I hear, see, or read some report on some scientific "breakthrough", etc, I get quite annoyed because of the apparent misrepresentation and lack of details. This article doesn't so much attempt to explain some of the issues surrounding science reports but rather to poke fun at it and the people who write them. Nevertheless, it makes for an interesting read.
Well, I thought they were interesting...