Older blog entries for elanthis (starting at number 386)

Baggage Check Advertising - I’m a Marketing Genius!

I’m leaving in less than an hour to head to the airport to fly to Seattle for 10 days. One thing I’ve always done when flying ever since the September 11 attacks is to include a nice advertisement for the poor baggage check technicians who rifle around in our checked luggage.

The ad is a joke ad for a job seeking service, such as Monster. Sometimes I use another service like Dice, although only rarely since those are usually more specialized and not as applicable for the kind of people who check baggage.

For your own personal use, I include here the latest such ad I’ve made for this trip. Yes, it’s dumb. Yes, it amuses me (possibly because it’s 4am and I won’t likely be able to sleep until tomorrow night, in Seattle… or possibly just because I’m immature).

baggage-check.pdf

Syndicated 2008-08-27 07:49:43 from Sean Middleditch

Python Annoyances: Followup

I’ve gotten a fair bit of response to my list of minor complaints with Python. Many of those have been quite helpful, and I’ve learned some good tricks that have definitely made things easier on me. Thank you.

I’ve also gotten a lot of “you need help with switching to dynamic language” responses, however, and those frankly are pissing me off.

To be clear: I’ve been using dynamic languages for more years than I can count with my shoes on. I switched to Python BECAUSE it is a dynamic language, I knew what that meant, and that is what I wanted. The vast majority of the work I do for a living — and have done for a living for a decade now — has been in languages like Perl, PHP, Ruby, JavaScript, and an assortment of other very-much-not-static languages. My issues regarding the type system with Python are not “it uses dynamic typing,” but that it does not offer any optional facility to help with type checking when I do actually need it, which is something that quite a few other dynamic languages manage to offer just fine, thank you.

Let’s take the duck typing example that some dynamic language designers love to use as “proof” that dynamic typing is so awesome in all cases ever. Sure, “if it walks like a duck and quacks like a duck, I’d call it a duck.” That’s fine and dandy. But how the hell do you actually find out of if it quacks like a duck before you try to make it quack? Well, you just try it and then watch exceptions start flying when you try to tell a toaster to quack, apparently. Fun.

I don’t want rigid typing everywhere. I don’t need rigid typing everywhere. I do have some code that simply isn’t going to work if you pass a string, or a number, or None, or a list,
I think the problem here is that there are very, very few languages that have any kind of support for type checking based on arbitrary constraints instead of on rigid types. Java makes you use interfaces. Python just makes you hope and pray. Where the hell is the middle line?

C++0x has a pretty neat feature called Concepts. A Concept is a list of constraints for a type. For example, you might have a Duck Concept that requires that the type have a walk method and a quack method. You can then state that a generic method (which is C++’s way of doing sorta-dynamic typing) parameter must adhere to a particular Concept (or multiple Concepts). So — just like Python — you can pass ANY type you want to such a method without having to inherit from any base class; you never have to tell C++ that the type adheres to the Duck protocol. The language does the Concept tests and figures it out for you. That’s damn handy.

Imagine if in Python you could define a small set of Concepts for your module, or use built-in ones. You can say that method foo takes a “mutable container.” You could pass in a hash, a list, or an object that behaves like a container, just like you already can. If you pass in a string, an int, None, or something else, you get a nice, clear exception that tells you right up front that you passed in the wrong type (and what the right type is) instead of getting some cryptic message about attempting an array operation on some value passed to an inner function called by another function that was called by the actual public API function you originally called in the module. Oh, that would be ever so nice. And, of course, it would be optional.

I mentioned Boo before, and I think it has the right idea for variables. It’s a statically typed language that offers optional dynamic facilities. The static typing stays out of your face so you don’t have to type out huge type specifiers all over the place over and over again. Plus it has a Python-like syntax. If it wasn’t for the political troubles Mono faces with getting into various distributions, I’d probably be using that instead of Boo already.

The general idea with Boo is that, once you define a variable, that variable’s type is also static. So the following code would fail:

foo = 42
foo = “answer”

Once you declare var as an int (implicitly), var is statically typed to int. Seriously, most of the time this just isn’t an issue, because very little code is going to change a variable’s type in a single block. There are exceptions, sure, but they’re pretty darn rare in comparison.

Boo also has a duck typing facility, which allows you to declare a variable as duck (it would have been a little less goofy to call it “mixed” or “var” or something, IMO), which then allows that variable to behave just like you’d expect of any other dynamic language. You can even set Boo to use duck typing by default for variables instead of using type inference, if you so wish.

ECMAScript 4 has the opposite, in which a variable is dynamic by default but can be optionally constrained. (Without type inference, unfortunately.) So you can do:

var foo = “banjo”; // duck typing
var foo as int = 64; // static typing

So, the Python apologists can see that there are plenty of options for dynamic languages to offer static type checking facilities for those cases where it’s just plain useful, while still allowing dynamic behavior elsewhere. To put down my issues with Python purely as “problems adjusting to using a dynamic language” are bunk. Wanting the language to help me enforce the rules I know my software needs is not in any way at odds with dynamic typing. To hear Python folks say that wanting any kind of type checking is “not the Python way” is just as silly to my ears as hearing the PHP folks say that having named function parameters is “not the PHP way.” Yeah. Old versions of the language didn’t have it as the language simply hadn’t matured enough yet, so now you will decide to continue to not have the feature in perpetuity due to some indefinable criteria about “the way” code should be written in the language. If I have to hack around a language’s feature set in order to save myself time or make my code more maintainable, the proper response is not to stammer out apologies or sling accusations about me “doin’ it rong.”

That out of the way, I am again thankful for the help I’ve received. It’s been years since I’ve last used Python for anything substantial and trying to relearn some of the Python peculiarities or the new features that didn’t exist all those years ago has been slower going than I’d have hoped. Thank you!

Syndicated 2008-08-03 18:39:23 from Sean Middleditch

Python Annoyances

Forewarning: It’s been years since I last used Python, so I’m very much a “Python n00b” right now. I’m well aware that some of these complaints might entirely just me being an idiot. I would appreciate any comments pointing out said idiocy so I can stop being needlessly annoyed.

Having decided to write Source MUD in Python, I’ve come up with a list of things I find pretty annoying about the language. In no particular order:

  1. Horrendous Documentation

    The Python online manual is just atrocious. The modules are not very well documented, there are far too few examples, and functions don’t actually declare their intended parameters or behavior all too often. Trying to find the proper function to get a job done is hard, and trying to figure out how a particular function is used is even harder. Classes in the standard library are a nightmare to figure out.

    I particularly love the parts of the documentation that include verbiage such as “I can’t be bothered right now to describe…”

  2. Files as Modules

    The Python module system makes organizing code hard. Let’s say I have a dozen or so classes that are all grouped together. I have two choices: I either put them all into one file (e.g. module), or each class goes into a sub-module which somewhat bloats all the code that uses those classes (since I have to type out app.module.submodule.Class instad of app.module.Class).

    Contrast this to Java, which forces one class per file. In that setup, the directories are the module names, and the individual files just mirror the class names. So I can split up a large set of classes into a single module without having unnecessary sub-modules.

    I don’t particularly care for Java’s setup, either, but I find it infinitely better than Python’s. I’d personally prefer something like C++’s, where I the programmer get to explicitly declare modules/namespaces and can freely organize my code however I like.

    This one is really getting on my nerves. The few “too clever” tricks I’ve tried to work around it sadly don’t work. I’m pretty much ready to give up and just start putting all my code into singular huge multi-thousand line files so I don’t have to use stupidly.long.module.names.for.everything.

  3. Classes Are Weak

    Python classes act a lot more like JavaScript’s prototypes, except that they’re not as flexible. I can’t, for example, declare a set of class member variables and default values in the class definition (including documentation). No, instead I have to make a constructor and set all the class members explicitly from that.

    The really annoying part about that is that I can’t make my classes actually mean anything. Since you can just set any member on any class, or freely add or remove methods on any class, and the language can’t do a damn thing to check for simple mistakes (assigning to a misspelled class member name), my code feels really fragile.

    If a variable is set in a class, that actually defines a class variable, not a member. This works out fine for numbers, booleans, and strings, but not so well for hashes, arrays, objects.

    The Python gurus recommend unit testing to make sure code is solid. That’s great. If I wanted to write dozens of lines of boilerplate code in order to make sure stuff worked, I’d have stuck with C++. I want to write less code and be confident in the belief that that code is correct and error free.

    I might be better off with Boo for this particular complaint. I may just end up switching.

    I think to be honest what bothers me most is that the Python way of doing this is not self documenting. I can’t just look at a class and see, at the top, a list of all class members and their default values. I have to look at the __init__ method, which is a bit less clear cut. It moves all the member definitions to the same indentation level as regular method bodies, which makes them stand out less. It also means that member definitions have to have all the extra boilerplate, like the self. in front of the member name. it mixes the member definitions up with any actual initialization logic that __init__ requires. It’s just messy, and makes a class harder to read and understand.

  4. Declarator Inconsistency

    The Python declarator feature is pretty cool. Unfortunately, it’s pointlessly inconsistent. If you want a declarator that has no parameters, you define a simple function. If you want a declarator that takes parameters, however, you must define a function that returns another function. The side effect of this inconsistency is that you end up with two different syntaxes for actually using declarators in the case that you want to call one without any parameters.

    # declarator that takes no parameters
    def dec1(func):
      return func
    
    # declarator that CAN take parameters, but doesn't require them
    def dec2(param=None):
      def actual(func):
        return func
    
    # correct
    @dec1
    def func(): pass
    
    # correct
    @dec2()
    def func(): pass
    
    # correct
    @dec2(param='Test')
    def func(): pass
    
    # incorrect
    @dec1()
    def func(): pass
    
    # incorrect
    @dec2
    def func(): pass
    

    There’s no good reason for that. Both types of declarator should just work the same way.

  5. Variables Aren’t Declared

    I’m not all that interested in static typing of variables (although there are plenty of cases where it’s damn handy). What I am interested in is the need to declare that a variable exists before it can be used.

    Python already kicks up an error when you try to access a variable that hasn’t been defined yet (at runtime, unfortunately), but it will happily let you accidentally create a new variable instead of assigned to the one you intended.

    It’s a really minor complaint, and one that I’m sure a lot of people will disagree about, but I’d really prefer it if I had to declare every variable with a simple “var name = foo” syntax. Likewise, a “const name = foo” would be equally nice.

  6. Unstructured Docstrings

    Alright, sure, I could just decide to do this myself. I do just find it irritating that docstrings don’t enforce any kind of structure, though. It’s really very similar to the idea of Python’s code block structuring requiring indentation: you get better code if you require the code to be well structured. In languages like JavaScript, C, PHP, or Java, it’s not at all uncommon to see novice (or not-so-novice) developers write code with seemingly random indentation. I don’t have a clue how they manage to do that, but they do.

    The same goes with Python’s docstrings. Since they don’t require any kind of special format, they are all too often just worthless bits of text. About as worthless as most code comments (which I’m just as guilty of). I mean, you have to appreciate the silliness of things like:

    def getResults():
      """ Gets the results. """
      return ...
    
    # test if foo is valid
    if foo:
      ...
    

    Really glad that code is documented! It helps so much in understanding what is going on.

    So, I’m sitting here staring at my (quite useless) docstrings, and wondering what I should do with them. Unlike Java, which just uses special comments to document stuff, there isn’t even a standard package for generating good documentation. There’s pydoc, but I can’t for the life of me figure out what the use of that thing is. I think that’s what the official Python documentation is generated with, and you already know my thoughts on that crap.

    I don’t need anything particularly fancy. The bare bones javadoc syntax would be all I really need. Just a way to add a useful description of a function or class, and a way to list out what each parameter is for and what the return value should represent. And a tool to take that and turn it into something pretty to slap up on a website or in README for new developers on the project.

  7. I have a few other complaints, but as those all are being tackled already for Python 3000, I’m not going to bring them up here. No sense complaining about things that are already being fixed,.

Syndicated 2008-07-31 19:40:38 from Sean Middleditch

Tag Renewal

License plate tag renewal fee: $54

Late license plate tag renewal fee: $108

Ticket for having expired tags on my plate in East Lansing: $130

Total savings if I hadn’t been a moron and forgotten to renew my tags: $184

Ability to set reminders in Evolution for next year’s renewal date: priceless.

Syndicated 2008-07-03 16:55:55 from Sean Middleditch

Motherboard Hell

I’ve been meaning to upgrade to a newer and FOSS-supported video card. Since I like nice, quiet, low-power systems, that requires an integrated graphics chip. My current motherboard makes use of an NVIDIA 6150, but I really would like either an AMD 780G or Intel X4500 (when they’re out).

Since I had a birthday recently and my parents were bugging me to ask them for something, I decided to ask for a 780G motherboard. I then went and bought DDR2 RAM and a Phenom X4, as my old Athlon X2 is a socket 939 model.

The new motherboard unfortunately was a huge problem. It would hang randomly on boot, gave Linux various errors, and caused some instability. I figured it could also be the CPU or RAM, but it’s really hard to find out when you don’t have anything else to swap in. I had my parents return the motherboard and a bought a new one, which came recommended from Phoronix.

That one wouldn’t even power on.

At this point, I’m pretty much sick of pulling my computer apart and putting it back together over and over. If the replacement motherboard doesn’t work (or it turns out to the CPU or RAM) then I’m just going to send it all back and say “screw it.” Maybe I’ll try again when the Intel GMA X4500 motherboard are out, maybe I’ll just get a cheap R600-based PCI-E card and stick it in my current machine, or maybe I’ll just live with the proprietary-driver necessary for my current graphic chips. (Yes, necessary - neither of the Open Source drivers nor the VESA driver are capable of giving me a usable desktop on my monitor - I either get stuck with a tiny-ass resolution, a missing mouse cursor, or a picture that’s offset by about 50% vertically.)

Putting computers together can be kind of fun, but it’s not at all fun when putting new ones together requires you to pull apart your one and only working computer, and hoping nothing goes wrong and damages your existing working parts in the process. And I really don’t feel like having to order a new case (which costs almost as much as a CPU these days - WTF?) and hard disk just to be able to try over and over to build a new machine until Newegg manages to ship me working parts. :/

Syndicated 2008-06-25 03:49:04 from Sean Middleditch

Fedora Firefox Fsync Fix

The sqlite/fsync behavior of Firefox that’s been so heavily publicized lately is biting me in the ass, and hard. When Firefox is open, my machine frequently starts churning the disk, and any application which needs to write to the disk grinds to a halt. The second these 15-25 second pauses are done another one usually starts. It is quite literally driving me out of my mind in frustration.

For whatever reason, Fedora does not seem interested in fixing the issue. Despite Mozilla’s recommendation to apply a patch to fix the issue, Fedora will not do so (according to the bug report). I don’t know if 3.0 RC2 fixes the bug upstream, but even if it does, there are no Firefox updates for Fedora. I’m pretty much on my own here.

I tried to use a simple fsync wrapper with LD_PRELOAD, but I could not for the life of me get it to work. I don’t know why, as logically it should work just peachy. The library gets pre-loaded, but the wrapper functions just never get called. I’ve done this sort of thing before I was fairly confident that I was doing everything right, but the fact that it didn’t work clearly indicates I overlooked something.

My current “hack” is rather extreme, but it’s doing the job wonderfully. Given that I have an excess of RAM in this machine (2GB is more than I need… and I’m adding more in a week or two), I decided to create a tmpfs filesystem with a limit of 500MB, backed up my .mozilla directory, put a copy on the tmpfs filesystem, and symlinked ~/.mozilla to that. Since fsync is now essentially a no-op, I no longer get greats amount of disk churn.

It’s worth noting that some of the other programs i use probably contributed to the excessive churn. Pidgin writes to disk way too often (there are bugs open upstream on this), and for whatever reason it fsyncs even on the unimportant ones, like buddy icon caches. Evolution caches mail on the disk. Vim is constantly writing its swap file and fsyncing left and right. It probably shouldn’t be too much of a surprise that a ton of processes are building up data to be written out, fsyncing, and while blocked more data is built up, just to be followed by another fsync.

Particularly frustrating though is that even when I’m not actively using Firefox — it’s open, but on another workspace, not being interacted with, not even with sites using JavaScript or automatic page refreshes — it still manages to make my disk churn. Likewise, Pidgin seems to be writing files out at various points in time even though nobody is IMing me, nobody’s status is changing, my preferences aren’t changing, etc.

In any event, the tmpfs thing works. I just hope I remember to copy the data back to my real ~/.mozilla before I shut down the computer, because I actually do like to keep my history. I just want it to work like Firefox 2 where keeping my history did not require sacrificing my I/O throughput and sending my disk drive to an early grave.

Fedora Firefox Fsync Fix… Four F’s? Freakin’ Fantastic!

Syndicated 2008-06-14 01:00:19 from Sean Middleditch

Design of PHP

Having worked with PHP professionally for some 9 years now, I’ve slowly acquired a very dismal view of the language. Don’t get me wrong - it works, it gets the job done, and in a lot of cases there simply isn’t a sensible alternative. But let’s be honest with ourselves: PHP sucks, and it could have been a far better language.

The shortest summary of my complaints against PHP are that there was absolutely no real design effort put out before the language was written. Or before any major version release after the first. Or in the next version release, PHP 6.

PHP has a large number of well-known “oopses” built up over the years. Auto globals and magic quoting are perhaps two of the best known. Auto globals might seem like a good idea at first, but even a little bit of thought would have shown how problematic it would turn out to be. Magic quoting is another idea that might seem good if given only a few seconds thought, but if one sits down and really thinks about the problem — developers not quoting the strings they’re concatenating together to form SQL queries — it’s not hard to come up with a handful of better solutions.

Aside from the glaring mistakes, PHP also suffers from what I call the Misplaced Generality Tendency. PHP, like many other languages, are designed with a very general-purpose syntax and library despite the fact that PHP was written for one purpose: web applications. Web applications for the most part do two things very frequently (database queries and HTML output) and a lot of other things very infrequently. It would have made a lot more sense to specialize PHP towards DB queries and SQL as well as easy and safe HTML output rather than designing this general purpose C/Java/Perl like language that doesn’t really do anything better than those languages other than having an Apache module (which time has shown us is a bad idea for security reasons - hello fastcgi and suexec) and being easily embeddable in HTML (which most of us don’t even do anymore - we use domain-languages like Smarty or PHP Sugar for output).

It would be nice to think that PHP is slowly getting better, but that does not appear to be the case. When MDB2 was released as the replacement for PEAR::DB, we found that using SQL was just as much of a pain in the ass and easy to get wrong as before. You have to jump through extra hoops to get the placeholder syntax (which, in turn, uses stored procedures even for one-off queries) with MDB2 instead of it being the default, recommended way of doing things. You’re still forced to treat all SQL as just a regular string — same as all that dangerous user input — instead of treating SQL as a first-class citizen of the language. Imagine for a moment that you could write something like:

$result = $dbh->query({{ SELECT column FROM table WHERE id=$_REQUEST['id'] }});

The {{ }} syntax is for illustration only: there are a number of alternatives that might be more aesthetically pleasing. Now, imagine that PHP not only recognized the SQL expression, but also knew to automatically quote the $_REQUEST['id'] variable appropriately. Sometimes you do need to build up your SQL queries like they were strings - it’s rare, but it happens. The syntax above makes it trivial to support this.

$conditions = {{ }};
if ($_REQUEST['name']) $conditions .= {{ WHERE name={$_REQUEST['name']} }};
$result = $dbh->query({{ SELECT column FROM table $conditions }});

When a SQL value is inserted into or concatenated with another SQL value, the result is just what you’d expect.

The query method on the $dbh object would reject any input that isn’t a SQL value. It would not automatically coerce a string into a SQL value or anything like that.

In those instances where you really do want to take user input and turn it into a query (for software like PHPMyAdmin), you can provide a simple method to convert a string into a SQL value. Make it sound scary if you want, or just document it well if you trust your users to read (I don’t).

$sql = unsafe_string_to_sql($user_input);

Life would be so much easier if PHP actually decided to support SQL in the language, like any language that works 90% with SQL should.

HTML output with PHP isn’t much better. Tools like echo or print are almost as dangerous as the existing SQL libraries in PHP. The problem lies with XSS attacks and malicious content injection attacks. Simply spitting user data out to the page allows users to inject JavaScript, Flash, ActiveX, Silverlight, or other potentially harmful data into a page. If the site stores requests from users and then displays that data to other users, you’ve got yourself a big problem. Almost as big of a problem as if you just let users inject raw SQL into your database queries.

Sure, you can make your output safe using htmlentities() or htmlspecialchars(), but that’s kind of a pain — just as much of a pain as having to add $dbh->quote() all over the place in your SQL string concatenations. At least MDB2 allows you to use placeholders after enabling them; PHP has no such feature for output.

Of course, most of us use a templating engine anyway. It’s really not the core application’s job to be spitting out HTML. Really, there’s no even any good reason for the embedding syntax (the stuff) in PHP. It may have made sense back when PHP was just a hopped up server-side includes mechanism, but in the days of PHP6 (or even PHP4) it’s practically useless.

Several design flaws are illustrated by the templating needs among PHP developers. First is the fact that PHP is not at all intended to be a templating engine and yet still tries to pretend that it is one. Second is the fact that PHP is not intended to be a templating engine at all. Think about it: why is Smarty or PHP Sugar necessary? Why not just include another PHP file?

Well, for starts, there is no sandboxing mechanism in PHP. There’s no way to include a file and guarantee that that file can’t access dangerous library routines or modify application data. The PHP syntax is also relatively unfriendly to Web design professionals — PHP is focused on generalism and the C/Java/Perl syntax instead of being focused on its core domain, remember? Finally, simply including PHP scripts as your templates would provide you with a separation of core business logic and presentation but would not grant you any other niceties such as easier output of safe content.

Unfortunately, just as MDB2 doesn’t do nearly enough to offset PHP’s non-existent SQL integration, projects like the Smarty engine (which by all appearances is the semi-official PHP templating solution) don’t do nearly enough to offset the numerous design flaws PHP has regarding its HTML output facilities.

For example, even though Smarty make function calls look more like HTML tags (good for Web designers), it also managed to choose a code delimiter and conflicts with JavaScript and CSS; expose pointless internal complexities on the user like forcing them to know when to use -> and when to use . to access value properties; makes it easier to unsafely output user data than to safely output user data by requiring explicit escaping; and focusing on generalism instead of offering as many tools that are frequently needed by designers as possible. In most ways, Smarty seems to have been designed the same way as PHP — which is to say it wasn’t really “designed” at all.

PHP could alleviate many of these problems. It could have used a syntax more familiar to Web developers (which might include trying to look more like JavaScript than Perl). It could have offered a sandboxing facility. It could allow an include mechanism that enabled the embedding syntax while leaving it disabled by default for regular files. It could make sure that echo statements or statements automatically HTML escape their output by default and make outputting raw data require the extra steps instead.

Web developers would be best supported by a language actually designed for Web development, which is not the same as a language that was haphazardly slapped together with the intent of using it for Web development.

In general, I believe that it’s often better to learn and use an assortment of domain-specific languages rather than trying to make one language fit all needs. It’s often a lot easier to learn a small language specific to a single problem domain with syntax and functionality targeted exactly at what a developer is trying to accomplish rather than trying to learn large and complicated tricks to get a general purpose language to do what is needed. I often hear the mantra that developers love being able to do all their work in one language — such as being able to code both the server logic and the client behavior in C# using ASP.NET and Silverlight — but I contend that developers ask for this only because they have already been forced to build up a large assortment of C#-specific tricks and hacks to accomplish oft-repeated goals and that the alternatives to Silverlight are themselves general-purpose languages shoe-horned into a relatively simple problem domain (UI behavior).

It’s easy to see that this philosophy has been in effect amongst true computer scientists for at least 30 years just by looking at one of the core UNIX design principles: many small tools that each do a specific job and do it very well. Even in terms of language, UNIX has plenty of examples: awk, sed, tr, regular expressions, C, shell script, yacc/lex, and so on. It may take some time for someone already familiar with C to learn the awk syntax, but in for very specific yet frequently occurring problem domains it will take a programmer less time to learn awk and then write an awk script than to try to develop the equivalent logic in C. Tools like Perl may all but make languages like awk obsolete (a design goal of Perl if I recall) but there are still plenty of other problem domains with Perl barely does better than C.

Unfortunately for all of us working with PHP professionally, the only thing PHP has going for it that any other languages don’t is that PHP comes as standard in pretty much every web hosting provider service out there. After that convenience is granted, we have to start struggling in order to overcome PHP’s misdesigns and do our job: writing maintainable, secure, stable, efficient web applications. PHP is a toolbox full of interesting and useful tools — just not the ones we need to use most often.

Syndicated 2008-05-29 01:23:52 from Sean Middleditch

New LARP Weapons

Spent some hours making these. I hope they’re actually legal. :/ The halberd (looks far more like a german poleax, oops) is constructed with 1″ diameter rattan, a styrofoam kickboard, the usual tan pipe insulation, some thinner dark tan (not black) pipe insulation I found, and strapping tape.

The halberd’s head is a bit bigger than I intended. I cut the styrofoam without taking into consideration the width of the padding (I used the light tan stuff for the blade’s edge, and the head spike and butt spike), so the blade came out a bit more gargantuan than I wanted it.

The dark tan padding used on the haft kinda has me worried - it’s not the rubbery black stuff that breaks down uber quick - it’s the exact same material as the light tan padding - but it’s only about 5/8ths as thick. I actually like that fact, but it may not be up to the standards of the game I’m heading to this weekend. Guess I’ll have to find out. It seems to hold up all right and is just about as cushy as the thicker stuff, but I imagine I’ll have to repad it sooner. Granted, the light tan stuff can last well over a year if you aren’t hitting like a retard and store your weapons somewhere acceptable.

The sword is a little atypical in construction too. The hilt is attached a little differently than most, as it’s a single length of padding with a hole cut through the middle edge-wise, and the PVC slide through that. It’s then secured with a healthy amount of strapping tape, similar to how all the bits are attached on the halberd. The blade was then covered completely in the dark tan padding, and then another strip of the dark tan was cut in half and doubled up on the blade edges. This gives the sword a slightly nice shape, although it’s giant and bloated compared to a real sword. The thrusting tip then has some extra light tan padding to give it a slight taper and extra cushion. The pommel is the regular light tan padding construction, albeit attached with strapping tape instead of just duct tape.

I have complete confidence that the sword is safe. The blade edges are actually even cushier than normal boffer swords since the dark tan stuff doubled up is a bit thicker than the light tan padding.

Syndicated 2008-04-11 18:12:42 from Sean Middleditch

OpenJDK / IcedTea Web Plugin

I’ve been completely unable to get most of the Java plugins I need for work to operate using the OpenJDK / IcedTea plugin that both Ubuntu and Fedora shipped. Looking into things, it appears that they’re using a modified version of the GCJ plugin which has always been pretty behind the curve when it comes to actually working.

Anyone know why the official Java plugin isn’t released with OpenJDK, or if it is, why IcedTea is sticking with the incomplete GCJ plugin?

On a side note, why does OpenOffice.org on Fedora 9 require java-1.5.0-gcj instead of using java-1.6.0-openjdk? It seems a bit goofy to have two JRE’s installed.

Syndicated 2008-04-03 16:08:42 from Sean Middleditch

OpenID Not The Best Bet

So, I’ve tried toying around with OpenID a bit, and I’ve come back feeling a little unimpressed.

There are two problems. First, it is still a super pain in the ass to setup an OpenID server. None of the servers I could find were installable with a simple tarball unpack and config script - they all required source modifications and even then didn’t really work. There are toolkits for building OpenID servers, but no ready-to-run servers.

The biggest problem though is just the user-experience as a whole. Having to type in anything at all is still kind of clunky. I want single sign-on - if I am online, any site I go to should be able to verify I am the entity I was last time (with the ability to easily allow/deny sites from doing so). I shouldn’t need to type anything in. The amount of information available to the system should be more than enough for any site, be it a simple blog comment form, a forum, or an online store.

I’m all for having a server to centralize this, but I don’t think the technology should be built around users interacting with this server. The server should be a storage medium at most, not the actual UI. Instead, I am imagining a browser extension (which should be possible for Gecko, IE, WebKit, and Opera) that exposes a new JavaScript object, something like window.AuthService. This object allows the site to query information about the current user, including name, email, contact information, etc. It will also be able to retrieve a user ID (which would probably be an email address, or something else guaranteed to be unique per-user) as well as a site token. This token would be a completely unique and cryptographically strong random identifier that is associated with the user ID and the site domain. In particular, each user/site combo gets a different token.

So, I connect to google.com, and it wants to know who I am. It queries window.AuthService.userId and window.AuthService.siteToken and gets ’sean@mojodo’ and ‘F583AC9…4AC’ back. It then uses these to log the user in, or create a new account (which in many cases could be completely silent).

The first time a site attempts to access the AuthService object, the browser can display a popup (or one of those notice bars that are becoming popular) informing the user that the site wishes to identify him, and allow him to accept the authorization (possibly selecting between multiple profiles), permanently accept it, deny it, or select the access level (id and token only, id token and contact info, etc.).

The central server comes into play by allowing the browser to configure such a server (which could easily just be an LDAP server) to grab identifies from. Browsers set up in public terminals could be configured to ask for the server login information when the user first accepts an AuthService request (and not store this information past the end of the browser session). This allows users to keep their authentication information somewhere central, but keeps the UI solely in the browser allowing for a far better user experience.

Obviously a lot of details need to be worked out, including the exact interface (would it be better to use HTTP headers rather than or in addition to JavaScript?), the UI needs to be nailed down, etc.

I’ve considered writing a Mozilla extension for this (as well as extensions for WHAT-WG Connection class and Server-Sent DOM Events), but writing extensions for Mozilla is such a byzantine process and the documentation on how one might register new objects in windows (and do so securely - the docs just say it’s insecure if not done right, warning you not to do it, which is fucking useless compared to just explaining how to do it correctly and securely) that I haven’t been able to get anywhere on any of those ideas.

In the end though, I think OpenID is pretty much dead technology. At most it might become very slightly popular with blogs for posting comments, but it’s usefulness pretty much ends there. The UI sucks and the ease of user control and information handling is too lacking.

Syndicated 2008-02-14 19:11:50 from Sean Middleditch

377 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!