So, I acquired a copy and finished HP 7.
While the book is pretty good overall, it suffers somewhat from repeating the same tendency to have Harry overangst things, and Dumbledore's overly complex plot that involves not telling Harry much he needs to know is not that well resolved. Several bits are left somewhat unsatisfactorily resolved, and quick flip-flopping of the wizarding world seems a bit overdone. But still, not a purchase I regret.
Sunday, July 29, 2007
Saturday, July 28, 2007
YA GeekDinner
So, another GeekDinner come and gone. Fairly good, but not perfect.
So, the bad:
So, the bad:
- Layout of the venue. I ended up at a table near one of the screens, and had to peer round corners to see anything. Fortunately most of the talks didn't use slides, so that wasn't too much of an issue, but was an annoyance
- The acoustics (do restaurant's not realise people might ant to talk to each other?)
- V & A and it's parking lots. Especially since the recent rainy weather meant I was in the car, dealing with the driving of people around the V & A area was not fun.
- The food was pretty good (although service was a bit slow at times)
- The wine (again sponsored by GETWINE.co.za (who have stupid captilisation)
- The speakers
- Dave's talk on the Scarborough mesh didn't tell me anything I didn't already know, having been to the clug talk, and seeing other people comment to progress since then, but it's still an impressive project.
- I personally didn't get much out of either Ian Gilfillan's talk on writing a technical book, or the talk on peering, although a comment at the end of the latter talk on the intention to lay a lot of fiber in the cape town area could have interesting consequences.
- GETWINE's talk was interesting on some the issues with the running such a business
- The last talk, on behaviour-based testing, was fairly interesting, but not immediately applicable to much of my current work. Goes on the list of stuff to remember to look at some time.
Sunday, July 22, 2007
Cowboy Bepop
so, the special seminar series on Cowboy Bepop finally ended (after a glitch discovering that the last 3 episodes where subtitled, and thus needed different mplayer options, and not dubbed, like everything else). So, having ow seen the series, and the movie, my opinion piece.
The series is very good. It is not, however, quite great. It suffers from a few too many filler episodes, which delay the resolution of the major plot points. It is very entertaining, most of the time, and has one of the best intro sequences ever.
The movie plays like an extended episode. This works to its advantage, though, since it allows the opponent to be fleshed out more than is possible in most of the episodes, while still allowing a good level of interaction between the main characters.
Overall, well worth seeing.
The series is very good. It is not, however, quite great. It suffers from a few too many filler episodes, which delay the resolution of the major plot points. It is very entertaining, most of the time, and has one of the best intro sequences ever.
The movie plays like an extended episode. This works to its advantage, though, since it allows the opponent to be fleshed out more than is possible in most of the episodes, while still allowing a good level of interaction between the main characters.
Overall, well worth seeing.
Friday, July 13, 2007
History of a bug
(or how a problem with our HP printer earned me so money)
The story starts some years ago, where the department bought a rather nice duplex HP4000 printer. For quite some time, I had it happily setup using the on board Postscript interpreter. Then Matlab started producing Postscript 3 graphs, and the on board interpreter didn't handle this, and there was some issue with the newer Matlab's Postscript 2 graphs exceeding the memory capacity of the printer.
Ah-ha, says I, ghostscrpt has good support for the HP printers, so I'll push everything through ghostscript and get PCL output to feed the printer. The only issue was the that the ljet4d driver did not handle Postscript's /Tumble command at all, which was inconvenient, Still, I went with the setup, and, all in all, it worked pretty well, except that, every now and then, we would run into the issue of not being able to bring with /Tumble.
Then, while digging for something, I discovered HP's list of PCL commands, and saw that, supporting /Tumble was quite simple on the PCL side. Thus informed, I spent some time digging into ghostscript's code, and created a patch (which was not very clean at that stage), which did the job. I sent the patch off to the ghosctscript ailing list, and forgot about it for a while.
Sometime later (early 2005), I upgraded the print server, and had to adapt my patch to the new version of ghostscript. In the process, I cleaned up several things, refactoring it to move the Postscipt parsing of /Tumble down into the core, and generally getting something I was much happier with. Since the post to the mailing list yielded no response, I shoved the patches in ghostscript's bugzilla (one bug for the parsing refactoring and one for the changes to the PCL drivers). Since I now had a working setup, I didn't push the issue at all.
Forward to 2007 - I again upgraded the print server, and need to port my patches. At the same time, somebody on the ghostscript side is assigned to the bugs I submitted with the previous patches, and promptly closes them as being old. After complaining that this was not a valid reason to close the bugs, I was told that the parser changes were unacceptable (a decision I disagree with, personally, but it's not my call), but that they would consider an updated fix to the laserjet drivers. There was also a not that the bug had a bounty, which I assumed would be some nomial sum, and didn't note particularly.
After some delays on my side, I eventually found an afternoon and put together yet another version of the patch, and submitted it last week. Thus, I was somewhat surprised when they contacted this week and told me that the bounty was $500. Additionally, they were quite quick about processing the payment, an, at 14:00 this afternoon, my bank contacted me to let me know that the money had arrived.
Overall, I feel quite pleased with the final result - despite the long time frame, it was never more than a couple of afternoon's work and I've had a solution in place for my problem most of the time, but, finally, next time I upgrade, I won't need to worry about this. Of course, I may also no longer have a printer to which the patch applies, but so be it.
The story starts some years ago, where the department bought a rather nice duplex HP4000 printer. For quite some time, I had it happily setup using the on board Postscript interpreter. Then Matlab started producing Postscript 3 graphs, and the on board interpreter didn't handle this, and there was some issue with the newer Matlab's Postscript 2 graphs exceeding the memory capacity of the printer.
Ah-ha, says I, ghostscrpt has good support for the HP printers, so I'll push everything through ghostscript and get PCL output to feed the printer. The only issue was the that the ljet4d driver did not handle Postscript's /Tumble command at all, which was inconvenient, Still, I went with the setup, and, all in all, it worked pretty well, except that, every now and then, we would run into the issue of not being able to bring with /Tumble.
Then, while digging for something, I discovered HP's list of PCL commands, and saw that, supporting /Tumble was quite simple on the PCL side. Thus informed, I spent some time digging into ghostscript's code, and created a patch (which was not very clean at that stage), which did the job. I sent the patch off to the ghosctscript ailing list, and forgot about it for a while.
Sometime later (early 2005), I upgraded the print server, and had to adapt my patch to the new version of ghostscript. In the process, I cleaned up several things, refactoring it to move the Postscipt parsing of /Tumble down into the core, and generally getting something I was much happier with. Since the post to the mailing list yielded no response, I shoved the patches in ghostscript's bugzilla (one bug for the parsing refactoring and one for the changes to the PCL drivers). Since I now had a working setup, I didn't push the issue at all.
Forward to 2007 - I again upgraded the print server, and need to port my patches. At the same time, somebody on the ghostscript side is assigned to the bugs I submitted with the previous patches, and promptly closes them as being old. After complaining that this was not a valid reason to close the bugs, I was told that the parser changes were unacceptable (a decision I disagree with, personally, but it's not my call), but that they would consider an updated fix to the laserjet drivers. There was also a not that the bug had a bounty, which I assumed would be some nomial sum, and didn't note particularly.
After some delays on my side, I eventually found an afternoon and put together yet another version of the patch, and submitted it last week. Thus, I was somewhat surprised when they contacted this week and told me that the bounty was $500. Additionally, they were quite quick about processing the payment, an, at 14:00 this afternoon, my bank contacted me to let me know that the money had arrived.
Overall, I feel quite pleased with the final result - despite the long time frame, it was never more than a couple of afternoon's work and I've had a solution in place for my problem most of the time, but, finally, next time I upgrade, I won't need to worry about this. Of course, I may also no longer have a printer to which the patch applies, but so be it.
Sunday, July 8, 2007
On Failure Modes
People designing systems don't think enough about failure modes. Failures are annoying, but you need to design the system to fail gracefully. It is exceedingly annoying when this doesn't happen.
A recent example, that is of particular concern, as it bite me twice yesterday, it the access control system at Stellenbosch. When the system is down for a particular building, there isn't anyone authorized to open the other doors into the building, thus one is forced to wait until the technicians responsible for the access control system respond. Since this is naturally after hours, this takes some time, and is less than ideal when all you want to do is dive into the building quickly to collect something. A failure mode not designed to enable people to do what they need.
I'd feel a lot happier about the whole experience if I thought there was some chance the system would improve.
A recent example, that is of particular concern, as it bite me twice yesterday, it the access control system at Stellenbosch. When the system is down for a particular building, there isn't anyone authorized to open the other doors into the building, thus one is forced to wait until the technicians responsible for the access control system respond. Since this is naturally after hours, this takes some time, and is less than ideal when all you want to do is dive into the building quickly to collect something. A failure mode not designed to enable people to do what they need.
I'd feel a lot happier about the whole experience if I thought there was some chance the system would improve.
Tuesday, July 3, 2007
It's been cold
When you spend a couple of minutes wiping the frost off you Bike's saddle, before setting out, then it's pretty darn cold.
Consequently, I can confidently state that last night was pretty darn cold.
Consequently, I can confidently state that last night was pretty darn cold.
Weekend 29 June 2007
Having finally got my car back, the special seminar series was able to resume on Saturday. Kevin, alas, could not make it, and thus fell even further behind in Cowboy Bepop (which remains very cool).
After reaching our Anime quota, Simon and I finally merged the database rework branch into Sutekh. This went surprisingly painlessly, although I spent part of Sunday morning stamping out various little awkward bugs in a less than ideally tested part of the code.
The reason why I was working on Sutekh was that we'd agreed to play vampire on Sunday. I left for this slightly late (due to the bug fixing), but fortunately the N2 was comparatively sane - until the bit where they'd closed it off due to some or other race, anyway - so getting across wasn't too much of an issue.
The modifed close-range Osebo deck was able to successfully burn a vampire in combat each game. It arguably needs some combat rush, and definately needs some more ways of gaining blood. Soem more tastes (if I had any) and some blood dolls would probably do. More immortal grapples wouldn't hurt, so I an get around S:CE. The deck, like all potence decks, suffers from not having a way around Fortitude damage prevention, which, since both simon and Adrianna were playing decks using fortitude, made my life rather difficult.
Anyway, in the first game, Kevin's mixed crypt Presence S:CE and bleed deck, swept all before it. In the second, Simon's Tremere deck did quite well, although Adrianna's Salubri deck farmed extremely successfully and showed good defensive capabilities, although not really able to generate enough bleed to pressurize Simon.
Afterwards, I returned to fix some more bugs in Sutekh. By the end of Sunday, it was getting to be back in reasonable shape.
After reaching our Anime quota, Simon and I finally merged the database rework branch into Sutekh. This went surprisingly painlessly, although I spent part of Sunday morning stamping out various little awkward bugs in a less than ideally tested part of the code.
The reason why I was working on Sutekh was that we'd agreed to play vampire on Sunday. I left for this slightly late (due to the bug fixing), but fortunately the N2 was comparatively sane - until the bit where they'd closed it off due to some or other race, anyway - so getting across wasn't too much of an issue.
The modifed close-range Osebo deck was able to successfully burn a vampire in combat each game. It arguably needs some combat rush, and definately needs some more ways of gaining blood. Soem more tastes (if I had any) and some blood dolls would probably do. More immortal grapples wouldn't hurt, so I an get around S:CE. The deck, like all potence decks, suffers from not having a way around Fortitude damage prevention, which, since both simon and Adrianna were playing decks using fortitude, made my life rather difficult.
Anyway, in the first game, Kevin's mixed crypt Presence S:CE and bleed deck, swept all before it. In the second, Simon's Tremere deck did quite well, although Adrianna's Salubri deck farmed extremely successfully and showed good defensive capabilities, although not really able to generate enough bleed to pressurize Simon.
Afterwards, I returned to fix some more bugs in Sutekh. By the end of Sunday, it was getting to be back in reasonable shape.
Subscribe to:
Posts (Atom)