Content here is by:
Michael Still
mikal@stillhq.com

All my Open Source projects
Extracted view of CVS
Home
Site map

See recent comments. RSS feed of all comments. Raw dump of all comments for research purposes.

ImageMagick book
MythTV book








Thu, 22 Mar 2007



Peaked?



    I don't mean to imply I have peaked yet myself, but this is something I wonder about sometimes. How do you tell when you're at the peak of your talent and shouldn't go for that next interesting job / project / promotion?

    Presumably it happens to everyone at some stage that they end up at the edge of their competence. Ignoring additional training as an option for a second, surely it's a good measure of one's personality to therefore stop at that point. How do you know when you reach that point though?

    Tags for this post: work(S)

posted at: 22:21 | path: /work | permanent link to this entry


Fri, 15 Sep 2006



Quote

    (22:32:30) mikal-laptop: And then, days later, the highly developed carbon
    fibre sports Twinkie was stolen with my toilet paper holders that I got fair
    and square
    


    (Sorry, it seemed to make sense at the time).

    Tags for this post: work(S)

posted at: 07:01 | path: /work | permanent link to this entry


Fri, 10 Mar 2006



Cubicles

    I've ranted about life in cubicles, and now CNN has an article on the history of the cube. It's funny, I didn't like cubes at TOWER, but I don't mind them now. I think the secret is the people you're working with... The people I am with now tend to respect your need to get stuff done, and interruptions tend to be rare. If people do interrupt -- it tends to be something important.

    Interesting.

    Tags for this post: work(S)

posted at: 08:59 | path: /work | permanent link to this entry


Sat, 12 Nov 2005



At least I wont starve

    A good breakfast will hopefully stop me from starving during my bachelor phase in the US.

    Tags for this post: work(S)

posted at: 19:52 | path: /work | permanent link to this entry


Fri, 11 Nov 2005



Unemployed Bum

    So, I am an unemployed bum by the way. Yesterday was my last day at TOWER, today is our family's meta-Christmas, and then I have a little under a week to pack my stuff and help start packing everyone else's stuff before I fly off the Americania to start work with the G thing. So, now I just need to slot some good solid panicking into my schedule, and all shall be well.

    Tags for this post: work(S)

posted at: 23:33 | path: /work | permanent link to this entry


Sun, 30 Oct 2005



Two more weeks to go

    So, there are two more weeks to go for me at TOWER, and TOWER has already started recruiting my replacement (among a few positions recently made vacant). So, if you're a developer who likes the idea of living in Canberra, writing C# and perhaps some C++ for a living, and want to directly affect the lives of a million licensed users, then drop me a line and I'll tell you more about the job.

    Tags for this post: work(S)

posted at: 22:28 | path: /work | permanent link to this entry


Thu, 13 Oct 2005



Great Googly Moogly

    (As the Ferocious Beast would say). I just resigned my job, and have accepted a position with Google in Mountain View, California. I should be there in about five weeks.

    I know it's a great opportunity, but I still feel kinda weird about it. More on all of this later.

    Tags for this post: work(S)

posted at: 19:27 | path: /work | permanent link to this entry


Thu, 29 Sep 2005



What do you do when you care about a standard...

    ...but your employer doesn't? Well, the answer that I've come up with is that standards do matter, and that they shouldn't be controlled by companies for corporate gain. So, I'm going to pursue membership of the standards committee as an individual (which means that I wont be going to any of the meetings I guess), and advocate what I honestly think is the right solution, instead of what nessesarily makes things easier for my employer to implement.

    I'm kinda keen to find some time to implement some tools around the standard too, especially as I am not aware of any implementations online at the moment...

    Tags for this post: work(S)

posted at: 15:21 | path: /work | permanent link to this entry


Tue, 27 Sep 2005



Working from home today

    I always find that when I have to work with documentation, that I do it better somewhere quiet. It's hard to think about prose when you have someone else waffling on in your headphones. We don't have enough meeting spaces at work, so I am working from home today... I must admit it is also nice to eliminate the hour commute from my day once in a while.

    Tags for this post: work(S)

posted at: 15:50 | path: /work | permanent link to this entry


Thu, 22 Sep 2005



Should small ISVs be involved with the standards process?

    This week I asked my employer to fund a trip to a standards meeting. The meeting is in the US, so it's a little expensive to attend, but it's an important meeting. The meeting is important because:

    • The standard in question has just had it's first version accepted by ISO
    • There are clear problems with that first version
    • I have a lot of expertise in the subject area (not to beat my own drum or anything, but I really do)
    • The standard has a lot of potential, if pushed in the right direction
    • The meeting is to discuss the future development of the standard, so this is the right time to do that pushing


    Update: I forgot to mention that the standard is also directly related to what we do.

    The proposal was met with sarcasm in the office. This raises an interesting question that I've been pondering overnight. I've been working on the assumption that small software companies should be part of the standards process, both because standards compliance is important, and because being an early implementor of these standards can make a big difference to the acceptance of your software.

    Then again, perhaps I've been wrong all this time. Should standards development be left to the customers, Microsoft, Adobe and so forth? Should a standard be about what the customer and large vendors want, not what is possible?

    I suspect that large vendors certainly use the standards process to produce standards they know are hard for their competitors to implement -- the ODMA specification is certainly an example of one specification written by a large vendor, which is fairly closely tailored to how their code internally works, and is therefore harder for everyone else to implement.

    So, are standards about the customer? Should they be used as a competitive tool? Whatcha think?

    Tags for this post: work(S)

posted at: 16:58 | path: /work | permanent link to this entry


Mon, 29 Aug 2005



Blogging fire alarms

posted at: 17:25 | path: /work | permanent link to this entry


Ssssh, I'm hunting customers

    Scott is a random TRIM customer in Canada, who a couple of us found by having technorati watch lists for the name of our product. I have a policy of subscribing to blogs of users when I find them. It's been educational reading Scott's blog -- not just for us developers, but for the company as a whole working through how to deal with customers having a much more public voice for their thoughts.

    Scott mentions that now TOWER machines are about a third of his subscribers... Let's work out who those people are for a second:

    • Liferea: that one's easy. It's my Thinkpad R51 running Debian Unstable. As an introduction, I'm a senior software engineer in the research and development section of TOWER, and am currently in charge of the TRIM Connectivity Toolkit development.
    • Sharpreader: that will be Little Headed Simon, who is a developer on the TRIM Connectivity Toolkit project. Oh, Simon also prefers the moniker "Normal headed Simon", but that doesn't have the same ring to me.
    • Newsfire: will be Lindsay on her Macintoy (which appears not to have broken Apple like me, not that I'm ranting about Apple service at the moment or anything). Lindsay basically runs our marketing section's day to day operations, but leaves the company tomorrow.
    • And Onfolio: is Gordon, the project manager on the TRIM Context ICE web product team. And apparently Grant, our lead DBA as well.


    Hi Scott.

    Tags for this post: work(S)

posted at: 16:42 | path: /work | permanent link to this entry


Tue, 09 Aug 2005



Bye Grant and Lindsay

    Last week I had a brain wave on the way home, and decided that I should write some remarkably eloquent post about Lindsay's resignation from my employer. I had a draft paragraph floating around in my head and everything (as these things sometimes happen for me). But I realised I couldn't -- Lindsay had been offered the position at her new employer, but the contract wasn't signed, and she certainly hadn't announced her departure in the office.

    Grant's departure is similar. There's more going on than meets the eye, in my opinion, but it's not my place to comment on these things.

    Let me try to remember what I wanted to say about Lindsay's departure at the time -- it also applies to Grant. It went something like this...

    I am deeply saddened by Lindsay's and Grant's departures from work. When I started four years ago I think I ended up as being more of an acquaintance than anything else, but over the last couple of years they have become very good friends. They're the reason that we acquired Spike the Labradoodle. They're the people who supported me the most apart from my direct family when I interviewed with Microsoft, and while I try to work out what's happening with some changes that are happening in my life at the moment (more on that another time perhaps).

    But at the same time I am so very happy for them. I think they've made the right decision, and my sadness is mostly selfishness. They need to do what's right for them, and I think they're doing that.

    So, how do you manage happy and sad at the same time? All we've done so far is promise to keep in touch...

    Tags for this post: work(S)

posted at: 17:15 | path: /work | permanent link to this entry


Thu, 23 Jun 2005



Troubles hiring people

    Ryan, we have troubles hiring senior developers as well though. My current theory is that the educational system built around information technology is fairly broken. I wouldn't hire many of the people I graduated with for instance, and there are a lot of other graduates I meet who seem to be missing basic skills from my perspective -- understanding of memory allocation at a basic level, understanding how how a machine actually works, that sort of thing. Universities seriously need to have a long hard look at themselves and the value they're offering their undergraduate students.

    So, does anyone have good hiring techniques they would like to share?

    Technorati tags for this post:

posted at: 15:34 | path: /work | permanent link to this entry


Calling Tate Needham, or, Hiring in Canberra

posted at: 00:05 | path: /work | permanent link to this entry


Thu, 09 Jun 2005



Now that it's booked it's official

    I'm going to be in Melbourne on Tuesday and Wednesday for meetings, which means I'll be out of email contact, and the hotel the company has booked me into doesn't have any networking. Cest la vie.

    Technorati tags for this post:

posted at: 20:29 | path: /work | permanent link to this entry


Sun, 05 Jun 2005



An internal work email

    Perhaps this is a breach of some sort of corporate rule, but I think it's relatively innocent...

    In the weekly informational bulletin that goes around the company to tell people what various areas are doing was this gem from the human resources department:

      Generation X
      
      Born between 1965 - 1979
      
          * Often had both parents working, often known as latch key kids
          * More resourceful, individualistic, self-reliant and irreverent
          * Focus in the workplace on relationships, outcomes, rights and skills
          * Not interested in longterm careers, corporate loyalty or status symbols
          * Easy to recruit but hard to retain
          * Like to be told what needs to be done but not how
          * Enjoy variety and setting priorities
          * Have a need for their opinions and reactions to be valued
          * Enjoy informal recognition such as flexible work arrangements
      


    So, it would appear that I am a generation X member. I think most of the points listed above are fairly believable for a characterisation of my entire generation, if such a thing is ever a valid thing to do. For example, it seems only logical to me that you would have employees who have a need for their opinions to be valued -- surely that's a basic human trait?

    In fact, perhaps most of that rings true because it's true for all humans? (Kinda like those horoscopes which are simply always true, and therefore mysteriously correct for the intended recipient?)

    I do have one point there that I definitely object to. "Not interested in longterm careers, corporate loyalty or status symbols". Sorry, surely there are some people in that 14 year span who care about their career?

    Technorati tags for this post:

posted at: 17:23 | path: /work | permanent link to this entry


Sun, 22 May 2005



Web Servers, Web Applications, Web Services, Web Parts and maintaining your job security through naming conventions incomprehensible to the innocent public

    There has been something for a while which I have been meaning to discuss. It's posted here in the work category because it's related to a conversation I've just had here, but my concern is a lot wider than that. I have seen this behaviour in many places...

    There seems to be a lot of confusion about the differences between Web Servers, Web Applications, Web Services, and Web Parts. The only people who can be blamed for this are the people who felt that similarly naming things because they're conceptually in the same ball park was a good idea. Whoever you are, you should be ashamed.

    Let's try to dispel some of the myths about all of these things:

    Web Servers

    Web Servers were the first on the scene. It's a piece of software that sits on your machine, and answers requests from client machines for web pages. That is all. At a most basic level this is really a pretty simple thing to do. I know that as a first year computer science undergraduate I had written one of these, and I assume that most other undergrads have at some stage or other written one. There are really two contenders in this space at the moment, the Open Source Apache, and Microsoft's IIS. So, remember, Web Servers just hand out files to people when they're asked to. Nothing more.

    Web Applications

    Now things get more complicated. Someone out there had the brilliant idea that the files that are handed out don't actually need to exist on disc on the server. For example, the bank balance screen of your online banking thingie isn't actually stored on disc. The Web Server runs a Web Application to generate that file, and then send it to you. The file is never stored on disc, and needs to be regenerated each time you ask for it, which is why you can see changes to your bank balance in real time. This is all that a Web Application is, it's a choose your own adventure through a series of dynamically generated files. The files are called pages by the way, for a reason I don't actually know now that I stop to wonder why.

    Web Services

    On a completely different topic for a second... Imagine that you want to do something which your local machine can't do for some reason. For example you have a machine on the other side of the room hooked up to a cola dispenser, and you want it to eject a can just in time to trip the manager of your research and development section up, causing much hilarity in the office. Your client machine can't do that, because it's not connected to the cola firing machine -- it's on the other side of the room on your lap (all the better to look innocent). What you need is some way to ask the other machine to do it's thing. Luckily we're not in the stone age any more, so there is a network in between, so you have a method of communication with the other machine.

    Hundreds of years ago (in the 1990's) you would have done this by doing something called a "Remote procedure call", which is just a way of asking the remote machine to do something for you and get back to you with the result. In the cola example this would just be a simple yes or no, and you'd need to use your eyeballs to experience the extreme pleasure that is a tripping manager. Now, these stone age remote procedure call techniques used lots of random ways to communicate over the network, and were generally not firewall friendly. The former was because the vendors had locking you into their product in mind instead of what is best for the consumer (being able to use products from more than one company for instance). The latter was because most firewall people fear what they don't understand and didn't want people to be able to do useful things with their computers (this is of course a gross simplification -- some firewall people are simply not gifted enough to understand that the network is there to support valid business processes, whilst other firewall people had valid concerns with the underlying technology. I have been a firewall person in a past life, so I do have a little sympathy here).

    Anyways, ranting about network support people aside, the vendors of the remote procedure call mechanisms got together and decided that they'd sort out both of these issues. It's merely a coincidence that the urge to inter-operate came directly after one of the bigger vendors got convicted for monopolistic behaviour in the US. They decided that Web Servers and Web Services were pretty cool, and noticed that most firewall people let the traffic through, and decided that they'd come up with some standard way to talk to each other via Web Servers.

    The finished product was called a Web Service, which is an interesting quirk of history given that they talk a protocol called SOAP to each other, and really have very little to do with the Web. Apparently SOAP RPC might have tipped those darn firewall people off or something.

    So, Web Services are related to Web Servers in that they need them to work, and are similar to Web Applications in that they generate responses in real time based on things other than just a file on disc (like the status of the can firing mechanism). It should however be noted that Web Services have no user interface, are not Web Applications, will not be replacing Web Applications, and are only useful to programmers, and other similarly geeky people. The next person to ask if they can use my Web Service in Internet Explorer or Mozilla Firefox will be presented with my grumpy face.

    (Heh. Can you tell this is the most common question I field from non-technical people?)

    Oh, and the firewall people? Now they're not even aware that an RPC call is occurring, because it looks just like you surfing for your favourite muppet site. There is an arms race happening here, with the firewall people trying to get back their control of what's transiting the firewall. Interestingly they don't really appear to have learnt from the experience.

    Web parts

    So what of these web part things? Well, some brainiacs once noticed that people don't like having banking applications and other such Web Applications that can't be customised, so they came up with a way of breaking those pages up into little nuggets of user interface goodness, and instead of calling them controls or widgets like the rest of the industry, felt they should be called Web Parts. So, some Web Applications are composed of Web Parts, which run inside of a Web Server, to return virtual pages back to users. They have a user interface, because that's what they are there for. It's entirely possible that they use Web Services, but by no means mandatory.

    Conclusion

    A Web Server is something which answers queries form Web Browsers. A Web Application can run inside a Web Server if the server is setup that way. Perhaps the Web Application is composed of Web Parts. The Web Parts might also call a Web Service which also runs inside the Web Server but isn't a Web Application, but only perhaps. Web Services can also be called by things which aren't Web Parts of Web Applications, but you need a programmer to make it all happen.

    Clear? I'll leave WebDav for another day...

    Technorati tags for this post:

posted at: 22:56 | path: /work | permanent link to this entry