Better Inkscape Palettes

Inkscape is a great vector drawing tool, and perhaps my favorite opensource app. One reason being that it is much more polished than most opensource applications (I’m looking at you Gimp and OpenOffice!) But one area that is noticeably lacking is its set of default palettes. In a word, they’re horrid. Of the 18 available, all but one or two are so specialized as to be useless to 99% of users.

I decided to do something about this on my system, so I started by moving the old palettes out of the way so the wouldn’t show up in the palette menu.  On Mac, I did this by typing the following from the command line:

cd /Applications/Inkscape.app/Contents/Resources/palettes
mkdir old
mv *.gpl old

With all that old junk out of the way, you can now google for gimp palettes (Inkscape uses the Gimp color palette format) to find custom palettes that suit your taste.  I found Colorzilla to be a good starting point.  Just download your favorite “gpl” files and place them in the ‘palettes’ directory, and then restart Inkscape.

In my installation, I currently have the Visibone2 and Pantone palettes, plus custom palettes that I made for the Best of Kuler [gpl file] and Best of ColourLovers themes [gpl file].

BTW, It’s worth pointing out one of the annoying little characteristics of Inkscape is that it insists on adding a “X” (no color) chit to these palettes, which rotates all the colors by one column from where the palette creator intended them to be.   I’ve accounted for this in my Kuler/ColourLover palettes, but expect other palettes to look a bit off.  (As a workaround, you can edit the palette files to comment out the first color – not ideal, but may be preferable depending on the palette.)

JavaScript Inheritance Performance

One area of the Prototype JavaScript library that I have a bit of a love-hate relationship with is its support for mimicing OO inheritance.   The ability to call $super from within a function to refer to a superclass’ implementation is pretty darn cool, but I’ve found myself more and more annoyed at having to navigate what seem like unnecessarily deep and complicated stack traces when trying to debug code.  It was while mired in the bowels of Class.create() and Class#addMethods() that I found myself wondering how much of a performance penalty this stuff was incurring.  To find out, I put together a test to determine how the different strategies for emulating OO inheritance in JavaScript performed.  Here’s what I tested:

  • Ad hoc inheritance – This is a common(?) homebrew technique for allowing prototypes to leverage the code in objects further up the prototype-food chain.  Methods are overridden by keeping a reference to the parent method in a separate property , which can then be invoked as needed.  It’s fast but not very pretty, and it’s arguable whether or not this qualifies as real “OO” inheritance.
  • Prototype-style inheritance – Prototype uses a strategy inspired by Alex Arenell’s Inheritance library. Subclass methods declare a “$super” argument that is set up by Prototype to reference the superclass’ method.
  • Base2-style inheritance – Dean Edwards’ library.  Subclass methods invoke “this.base()” to call their superclass’ implementation.
  • John Resig inheritance – JR, of jquery fame, experimented with a Base2 variant which he published on his blog.  It’s a bit simpler than Base2, but seemed worth testing.
  • [Update] MooTools – For you MooTools fans out there, I believe that library uses the same approach that Dean Edwards came up with for Base2, so performance should be similar.  aNieto2K links to his test in the comments, below, if you’d like to verify this for yourself.  (I’d add this to the test, but Prototype and Moo collide over the use of the ‘Class’ name)

Tests were performed by using  JSLitmus to create a Inheritance Performance testbed. In it, I create a base class and subclass using each of the above approaches.  Each base class has a single method, “foobar” which is overridden, and invoked by, the corresponding subclass. The rate at which objects could be instantiated for each base class and subclass was tested.  The rate at which a method could be invoked on the base classes and subclasses was also tested.   Here are the results (first three are on MacBook – the IE and Chrome tests are on a Dell laptop):

There are pros and cons to each technique.  For sheer balls-out performance you’re best off using the ad-hoc “move aside” approach.  That’s only really important if you’re making 100,000’s 1,000s of calls per second to overridden methods, however.   Both Base2 and Resig’s approach have decent invocation performance, but Base2 can be a bit slow at object creation.

The most interesting result was the utter crap-tastic performance of Prototype.  When calling methods that use $super it’s consistently 20x slower than the other solutions. (Likely a result of the additional closure functions it requires).  Regardless, this is definitely something to watch out for for any application that makes heavy use of subclassing.  Or, rather, of subclassed methods.

Correction: Web 2.0 Sucks For Reviews

There’s an interesting phenomenon taking place lately that I find a bit disturbing. It has to do with how consumers are leveraging their newly discovered online powers of opinion. In principle, I think empowering people by given them tools to communicate with one another is a good thing – people should be able to be heard, and share ideas and comments on everything, including the products they chose to buy or not. But when it comes to software applications and services, reviewers are all to ignorant of how permanent their actions are compared to how rapidly what they’re reviewing can change.

Take for example the smackdown currently being handed to EA’s “Spore” on Amazon.com. As of this writing it has 3,000 ratings, 2,500 of which are one-star reviews filed by users upset by the copy protection software it uses. The majority of these reviews come from users who likely haven’t played the game, mind you, they are merely protesting the copy-protection system they’ve heard about. I’m not saying DRM protection is a good thing, but it does seem like the punishment here is a bit excessive. Spore is doomed to never rise much higher than “two-something star” rating no matter what EA does to improve it or address their users concerns. This would require receiving nearly 2,000 more 5-star reviews, which is over double the total number of reviews that the most popular video game ever made (World of Warcraft) has received in the four years it’s been listed on Amazon.

The first Spore review, alone, has been marked as “helpful” by over 6,500 people, most of whom are presumably deciding not to purchase the game. This in spite of the fact that the review is no longer accurate (EA revised the Spore DRM less than two weeks after the game’s release.) That’s $325,000 in lost revenue. From a single review. Ouch.

Amazon’s review system, like nearly all such systems on the web, is designed to let people review immutable things like books, CDs, or even Tuscan Milk – products that don’t change over time. But software is dynamic – it can be updated and improved, even after you bought it. And this is something that simply isn’t taken into account; not by sites that let you comment on products, or forums, or any other myriad channels we users pay attention to. What’s needed is a way to temper the relevence of reviews and comments based on how a product evolves over time. In the meantime, it would behoove people to be a little more circumspect in what they review and how they review it.

Javascript UUID Function

[UPDATE – 1/3/2010: For the latest/greatest implementation of a JavaScript UUID function, please check out my node-uuid project.  Any future improvements/enhancements to this code will be made there.]

[UPDATE – 9/1/2011: ‘Seeing reports of UUID collisions in the wild.  Johannes Baagoe has a write up on why Math.random() can’t be trusted.  I’m not entirely sure I buy this, but I’m certainly less confident than before about the uniqueness of UUIDs generated using only Math.random().]

Here’s a little JavaScript treat: Math.uuid.js is a function for generating different flavors of UUIDs in JavaScript. The function supports RFC 4122-compliant UUIDs (or GUIDS), like this:

AFF147E4-5BB1-448E-B55D-0A834ADE3124

… as well as non-standard random IDs of arbitrary length and radix. For examples of the types of IDs it can generate, or to see performance data, check out the Math.uuid.js Test page.

I put this together after discovering that nobody had published a really thin javascript implementation for generating UUIDs. Googling around turns up several decent scripts, but all of these suffered from one drawback or another (IMHO). One common problem results from trying to produce “version 1” ids, which the RFC defines in a way that is supposed to guarantee the uniqueness of the ID. But javascript doesn’t have an API for getting a guaranteed-unique anything – the best you can do is use Math.random() as a hack workaround which, strictly speaking, shouldn’t be used when uniqueness must be guaranteed. Using JavaScript to generate a version 1 UUID could be construed as misleading.

The more correct solution is to do what Math.uuid.js does – create “version 4” ids, which are defined as randomly generated (see RFC 4122, section 4.4). This avoids making an unfulfilled promise of universal uniqueness, while allowing for much simpler code. Also, in javascript where Math.random() has to be used for UUID generation, the theoretical uniqueness of these ids is better can i buy generic celebrex than version 1 implementations since all 122 bits of field data are randomly generated. That makes for a staggering 5.3 x 10^^36 possible ids. If every person on the planet filled up a terabyte hard drive with nothing but random UUIDs, there would only be a one in 7 trillion chance that two of the UUIDs would be the same. That’s the theory.

The practice is probably a little different. The uniqueness depends on how random the numbers generated by Math.random() are. Generating truly random numbers is a notoriously tricky problem, solved in different (imperfect) ways across browser platforms and OSes. It’s difficult to say for sure what the real-world uniqueness of these numbers ends up being, but I suspect it’s more than sufficient for most purposes. Regardless, this is a weakness that all javascript UUID generators will be subject to, unless they rely on an externally-provided unique value. For example, one could use AJAX to fetch UUIDs generated by a site like http://www.uuidgenerator.com/, but that has it’s own set of issues.

Update 1/22/10: Math.uuid.js includes an Math.uuid2 Math.uuidCompact – an alternate implementation for RFC4122v4 UUIDs designed to be as compact as possible, and Math.uuidFast() – an implementation designed for performance.

Update 06/03/10: Several people have expressed concern over how random the Math.random() method is. (E.g. “If two clients load the random() lib at the same time, will they start with the same seed?”) After doing a bit of research into how various OSes handle random # generation , I’m pretty satisfied that this unlikely to be an issue.  Seeding is done from a variety of sources of almost pure random numbers – mouse movement, built-in hardware support (e.g. by measuring noise in electrical circuits), various unique device IDs, BIOS checksums, memory usage statistics… and so on.