weblog.masukomi.org

mah-soo-koh-me

 

Select Gifts On Sale November 26, 2006

Filed under: Uncategorized — masukomi @ 5:04 pm

“Select Gifts On Sale”

Those were the words prominently displayed in the window of a Pier 1 Imports today, and they are so very wrong.

  • Gift: [n] something acquired without compensation

    If it’s on sale, you have to purchase it to get it. If you have to purchase it to get it it’s not a gift.
  • In this sentence “Select” reads as a verb, and you can rest assured that they don’t want you to actually select the sale items because the sale items are the ones they’ve cut the profit margin on to entice you into the store to hopefully buy items that are not on sale. Ignoring the fact that the “Gifts” aren’t actually gifts they should either use quotes to indicate that someone has referred to these gifts as “select” and thus making it clear it’s an adjective, or they could have used “selected gifts” instead.

Yes you can easily interpret what they meant to say but the point is that you shouldn’t have to interpret their meaning. The people who made that signage (actually it was a static window decal) are being paid good money to construct English promotional material. Were I their employer I would feel gypped to think that my employees a) couldn’t correctly construct a four word sentence and b) not one person in all the meetings that this surely went through was bright enough to catch these obvious errors.

On a related note can someone please suggest a word with the same meaning as “gypped” that doesn’t have the negative racial connotation? Are the Romany considered a race?

 
 

On DRM

Filed under: Uncategorized — masukomi @ 6:31 am

When it comes to DRM “protected” music people tend to be either completely ignorant as to how it affects them, or even that it affects them, or they’re religious zealots who have such extreme viewpoints you can’t have a sensible discussion about the issue.

But there’s one simple exercise that will explain just how dangerous DRM is to you and your friends:

  • What computers were people using ten years ago?
  • Can you run the software from those computers on your current computer? Does anyone even support or update the software from then? Would you want it even if they did?

    Macs were running OS 7 in 1996. Windows was Win 95.
  • Considering that Moore’s Law essentially says that computers will double in power every 18 months do you really think that the computers we have ten years from now will even remotely resemble the ones we have today?

With that in mind what will become of the DRM “protected” music you buy today from iTunes, or almost any other online music store, if the software to unencrypt in can be reasonably expected no neither be supported, nor runnable in ten years?

 
 

On Warranties and Guarantees November 24, 2006

Filed under: Uncategorized — masukomi @ 4:49 am

Your warranty / guarantee says a lot about you and your products and shouldn’t be considered some legal thing to what you will and won’t reimburse the customer for when things go wrong.

Your company sells quality products or services right? Shouldn’t you stand behind them as if they were as good as you claim they are?

Let me give you an example. I’m looking for a new messenger bag because my current one has two holes and is starting to break down in other areas. I want something nice, that will last me a more than just four years and I’d narrowed down my search to two bags. The Ogio Hip Hop (in spite of the name) and the Ground Shinumo. I was having trouble deciding between them. The Ogio had pictures of the inside (on various sites) that looked like what I wanted but no reviews and the Ground had great reviews but no pictures of the inside. They both claimed to be durable and to use uber-fancy materials to resist wear, but every bag that isn’t pure crap claims that.

So I thought, “hmm If these are really good bags the manufacturer will stand behind them.” So I go over to their home pages to see. Ground’s warranty says:

Our lifetime warranty guarantees that the materials and workmanship in every product we make will stand up to the use for which it was intended. Our warranty does not cover damage resulting from accidents, improper care, or the natural breakdown of materials over extended use and time. Defective or damaged products must be returned to us for evaluation (they must be cleaned before you send them). We will repair or replace them at our discretion. We will repair damages resulting from accident or improper care for a modest fee.

In other words, they guarantee they didn’t screw up when they manufactured it and even accidents or improper care “for a modest fee” which probably means whatever it cost them to make your bag. Not bad at all, admirable even, but not spectacular.

Ogio’s warrantee though:

Ogio International guarantees its entire *non-golf line of products for the **lifetime of the product (original sales receipt required). This warranty covers the product for the original owner against defects in materials and workmanship only. If the product ever fails due to a manufacturing or material defect, then Ogio will repair or replace with like product at our discretion. This warranty does not cover damage caused by normal wear and tear, accident, improper use, or the natural break down of colors and materials over time.

**Expected “lifetime” of Ogio products depends on customer usage.

The first thing they do is redefine “lifetime” to be some vague number they can never be held to that is somehow tied to how much you use it, and only applies to the person who happened to pay for it (original owner). You have to keep the receipt for the “lifetime” of the bag and you’re shit outta luck if it was a gift. Accidents, improper care? Tough luck. I especially like redefining “lifetime” in such a way that their support of their products ends up being inversely proportional to how useful the product is. If they make something you really want to use it’ll wear out faster so they’ll support it less. If they make some crap product you never want to use they’ll support it longer. Thus punishing the people most likely to spread the good word about them.

Then there’s L.L. Bean’s guarantee.

Our products are guaranteed to give 100% satisfaction in every way. Return anything purchased from us at any time if it proves otherwise. We do not want you to have anything from L.L. Bean that is not completely satisfactory.

They’re not kidding either. There are many tales of people having returned worn out, beat up bags and things to L.L. Bean and had them replaced, for free, with the current year’s equivalent. Guess which company I want to buy a bag from?

In the end I think I’ll get the Ground bag. I’d love to buy from L.L. Bean but I’m picky about bags and they don’t have anything that really strikes my fancy except maybe this nice sling bag which a co-worker happens to have. Before I looked into the warranties I was really leaning towards the Ogio bag. But now, I’m willing to risk the internal pockets not being exactly what I want because they stand behind their product, whereas Ogio is doing everything in their power to get out of it.

What does your warranty/guarantee say about your company and it’s products or services?

 
 

On having a mission November 21, 2006

Filed under: Uncategorized — masukomi @ 10:10 am

The cranium of a good developer is filled with ideas for new applications. Most of them tend to bounce around with little energy and eventually succumb to entropy. Some ideas are made out of bouncier stuff and eventually reach escape velocity, at which point they are launched down the arms and funneled out the fingertips. You can tell just how cool an idea is by the speed of typing relative to the developers average words per minute.

A short while later there’s a working prototype, and, should things go well, a fully fledged app will follow. But, most of these apps have no goals, no mission in life. Sure they do something, hopefully well, but for the most part they’re like teenagers, and, like most teenagers, they’ll either figure out what they want to do in life or wander around aimlessly until they figure out what they want to do, start doing something nobody cares about, or simply keel over dead.

But what if they knew what they wanted out of life?
Your, application’s mission is it’s heart, it’s driving force. What is it’s purpose in life?

Google’s mission could be “To be the world’s best search engine.”, but how is that going to drive Google forward in any meaningful way? Where’s the vision? No, Google’s got bigger goals than that. Their mission is “to organize the world’s information and make it universally accessible and useful.” Admittedly it’s not a terribly rousing mission but take a second and think about the implications of it. To do anything useful with “the world’s information” you first have to have it. Just imagine what that means for it’s infrastructure! And how about making it useful? Well, that requires tools. Making it accessible is a combination of incredible search technology (we are talking about all the information in the world here) and tools that can handle the various types of information: text, video, audio, various forms of structured data like schedules, locations, etc.

Flickr ’s mission could be “The best place to store, sort, search and share your photos.” but honestly, how lame is that?  Their mission is to be the “eyes of the world “:

That can manifest itself as art, or using photos as a means of keeping in touch with friends and family, “personal publishing” or intimate, small group sharing. It includes “memory preservation” (the de facto understanding of what drives the photo industry), but it also includes the ephemera that keeps people related to each other: do you like my new haircut? should I buy these shoes? holy smokes - look what I saw on the way to work! It let’s you know who’s gone where with whom, what the vacation was like, how much the baby grew today, all as it’s happening.

And most dramatically, Flickr gives you a window into things that you might otherwise never see, from the perspective of people that you might otherwise never encounter.

Flickr’s mission is all about vision, maybe a little to much so because it’s so non-specific. Stuart Butterfield obviously has a good grip on how it affects them, but anyone else reading just the mission wouldn’t really get it. But that’s ok. What’s important here is that there was a mission and that the people behind it understood it’s implications. What good is it to be the world’s eyes if nobody can see through them? Flickr is driven by it’s mission to build tools to let you see through those eyes.

But missions don’t just help you plan. They help keep you on track. Every nifty feature you want to add to your app should be run through the filter of your mission. Eyes aren’t about statistics or value or anything like that. They’re just about seeing, and that’s why you won’t find any analytics or ways to earn money form your images, or anything else like that on Flickr. If your app’s mission is to be “The easiest way to do X” you have to ask yourself if that new set of 20 different configuration options actually make things easier for people or just serves to confuse or intimidate them?

So build your rough prototype. Get that initial burst of creative energy out. Then, sit back and ask yourself what it really wants to be in life, and let that drive every new feature you add and provide you with the confidence to cut out everything else .

 
 

XML-RPC vs SOAP

Filed under: Uncategorized — masukomi @ 4:52 am


Update

This article was written a few years ago, however, the information still holds true. What I would note is that both XML-RPC and SOAP have excellent libraries which makes working with both fairly simple. Please drop me a line if you find any inaccuracies.

XML-RPC vs. SOAP

by kate rhodes

masukomi@masukomi.org

A simple guide to choosing the best protocol for your XML Remote Procedure Call needs.

Within the world of XML there are two main ways to implement a Remote Procedure Call (RPC). XML-RPC and SOAP. This document will explore the differences between these two methods in order to help you decide which is best suited to your needs.

General information

XML-RPC
http://www.xmlrpc.com

XML-RPC is
“…a spec (
http://www.xmlrpc.com/spec

) and a set of implementations that allow software running on disparate operating systems, running in different environments to make procedure calls over the Internet.

It’s remote procedure calling using HTTP as the transport and XML as the encoding. XML-RPC is designed to be as simple as possible, while allowing complex data structures to be transmitted, processed and returned.” - xmlrpc.com

XML-RPC’s Goals

XML-RPC is very humble in its goals. It doesn’t set out to be the solution to every problem. Instead it seeks to be a simple and effective means to request and receive information.

“We wanted a clean, extensible format that’s very simple. It should be possible for an HTML coder to be able to look at a file containing an XML-RPC procedure call, understand what it’s doing, and be able to modify it and have it work on the first or second try… We also wanted it to be an easy to implement protocol that could quickly be adapted to run in other environments or on other operating systems.” - xmlrpc.com

 

Comments

The spec itself is roughly seven pages long, including examples and a FAQ, and is extremely easy to understand. Any competent programmer should find no difficulty whatsoever in implementing XML-RPC in their software after reading its spec.

SOAP 1.1
http://www.w3.org/TR/SOAP/

“SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses.” - the SOAP spec.

SOAP makes extensive use of namespacing and attribute specification tags in almost every element of a message. For example when mixing data types within an array you have to set the SOAP-ENC:arrayType to indicate mixed data types within the array in addition to specifying the type of each element of the array.

 

SOAP’s Goals

SOAP tries to pick up where XML-RPC left off by implementing user defined data types, the ability to specify the recipient, message specific processing control, and other features.

Comments

Weighing in at 40 pages the SOAP spec is complex and filled with little gems like, “Using SOAP for RPC is orthogonal to the SOAP protocol binding.” If you ask me, it isn’t even remotely something I would call “lightweight” and they threw out the most important feature of XML-RPC, its ease of use.

Contrary to popular belief, SOAP has not been ratified by the W3C. As of this writing it is just a submission, which, essentially, means they thought it was nifty enough to start a discussion about it.

Features & Benefits

XML-RPC

Datatypes

Scalars:

Type

Example

32-bit signed integer

-12

boolean

0 or 1

ASCII string

hello world

double-precision signed floating point number

-12.214

date/time (iso 8601)

19980717T14:08:55

base64-encoded binary

eW91IGNhbid0IHJlYWQgdGhpcyE=

Structs:
In XML-RPC structs define an anonymous set of name value pairs. “A contains s and each contains a and a . “The value(s) can be of any data type

 

Arrays:

XML-RPC arrays define an anonymous grouping of elements with no limitation mixing data types like integers and strings within the same array. “An contains a single element, which can contain any number of s.”

Stability

XML-RPC has been around for a while and, while it isn’t maintained by a standards committee, it is stable and open to community input.

Simplicity

XML-RPC’s simplicity is its greatest feature. It is extremely easy to understand, implement, and debug. The syntax is so uncomplicated that it is very easy to find, and avoid, mistakes.

SOAP

Datatypes

Scalars:

Type

Example

32-bit signed integer

-12

boolean

0 or 1

ASCII string

hello world

signed floating point number

-12.214

date/time

2001-03-27T00:00:01-08:00

base64-encoded binary

eW91IGNhbid0IHJlYWQgdGhpcyE=

Structs:
SOAP structs define a set of name value pairs. Structs can be named.

Arrays:
SOAP arrays define a grouping of elements with no limitation mixing data types like integers and strings within the same array. Arrays can be named.

Array of Bytes:
An array of bytes MAY be encoded as a single-reference or a multi-reference value. The rules for an array of bytes are similar to those for a string.

In particular, the containing element of the array of bytes value MAY have an “id” attribute. Additional accessor elements MAY then have matching “href” attributes.”

 

Polymorphic Accessors:
An accessor “…that can polymorphically access values of several types, each type being available at run time. A polymorphic accessor instance MUST contain an “xsi:type” attribute that describes the type of the actual value.”
Ex. 29.95

Enumerations:
Based on the “XML Schema Part 2: Datatypes” (
http://www.w3.org/TR/xmlschema-2/

), which is still just a recommendation, a SOAP enumeration is “…a list of distinct values appropriate to the base type.” It is supported for all simple types except boolean.

User Defined Data-Types:
Developers can define their own simple, or complex, data types.

Customizing

SOAP’s greatest feature is its ability to step past XML-RPC’s limitations and customize every portion of the message. This ability to customize allows developers to describe exactly what they want within their message. The downside of this is that the more you customize a message the more work it will take to make a foreign system do anything beyond simply parsing it.

Big Co. Support

SOAPs two biggest developers are Microsoft and IBM. Microsoft has incorporated SOAP into it’s latest OS and Visual Studio. As usual though, MS has decided that they don’t need to adhere to the whole spec. In their SOAP for Java SDK they modify the namespace (which breaks some other implementations), use a limited combination of 1.0 and 1.1 fault codes (and improperly document it), and include many serious bugs. IBM seems to have gotten almost everything right in their implementation.

Limitations

XML-RPC

Method Calls

XML-RPC calls methods via its methodName property which “may only contain identifier characters, upper and lower-case A-Z, the numeric characters, 0-9, underscore, dot, colon and slash.” For most purposes this is just fine, however it makes it particularly difficult when you need to pass an object as an argument.

Named Data Structures

The structs (hashes) and arrays are always anonymous. When passing multiple structs or arrays programmers need to rely on the order of the parameters ( ) they are contained in to differentiate between each struct or array. This isn’t a significant problem but there are cases when being able to name your structs and arrays would be nice.

Simplicity

As noted above, simplicity is also XML-RPC’s greatest limitation. Although most all of your RPC needs can be accomplished with it, there are some things that you just can’t do without bending over backwards, like passing an object as an argument to a function, or specifying which portion of a receiving application the message is intended for.

SOAP

Stability

Currently SOAP 1.1 is a submission to the W3C (
http://www.w3.org

). This means it is not an official standard and its specifications can, and almost assuredly will, change at any time. There are a lot of cooks in the kitchen right now.

Documentation

Last updated in May the SOAP spec is filled with mistakes and contradictions and points to other specs which are themselves moving targets. According to Dave Winer, one of the spec’s authors, Microsoft and IBM have taken it upon themselves to add in the WSDL (
http://www.w3.org/TR/wsdl

) layer without consulting the other authors. This doesn’t bode well for developers who need something they can count on remaining unchanged, or almost unchanged, for the forseeable future. Any current SOAP implementation may be incompatible with future revisions of the spec, although it should be noted that SOAP is far enough along that most of its spec should remain essentially the same.

Comparison

 

Feature

XML-RPC

SOAP

basic scalars

yes

yes

structs

yes

yes

arrays

yes

yes

named structs and arrays

no

yes

detailed fault handling

yes

yes

short learning curve

yes

no

Developers specified character set

no

yes (US-ASCII, UTF-8, UTF-16)

Developer defined data types

no

yes

Can specify recipient

no

yes

require client understanding

no

yes

message specific processing instructions

no

yes

 

When you get right down to it XML-RPC is about simple, easy to understand, requests and responses. It is a lowest common denominator form of communication that allows you to get almost any job done with a minimum amount of complexity. SOAP, on the other hand, is designed for transferring far more complex sets of information. It requires profuse attribute specification tags, namespaces, and other complexities, to describe exactly what is being sent. This has its advantages and disadvantages. SOAP involves significantly more overhead but adds much more information about what is being sent. If you require complex user defined data types and the ability to have each message define how it should be processed then SOAP is a better solution than XML-RPC (be sure to check out language specific solutions to this problem like java’s RMI (
http://java.sun.com/products/jdk/rmi/

)). But, if standard data types and simple method calls are all you need then XML-RPC will give you a faster app with far fewer headaches.

“Make sure you don’t use and overly complex package to address what may be your rather simple needs” -Brett McLaughlin (
brett@newinstance.com

)

 

Sources & Other Links

XML-RPC

SOAP

Assorted other links

 
 

Financial Entropy of a Webapp Subscriber November 17, 2006

Filed under: Uncategorized — masukomi @ 12:07 am

I was consumed with dreams about Stephen Hawking’s black hole entropy formula last night, which is frustrating because the math is, sadly, beyond me. But, I mention it to you today because, knowing so little about black holes my mind instead kept trying to change it into an formula to calculate the Financial Entropy of a webapp subscriber.

So, I put it to you, dear reader, have you, or any of your math enabled friends, come up with a formula for calculating the finincial entropy of a webapp subscriber? If you haven’t, but you could, there are many many entrepreneurs who would sing your praises and happily buy you a drink.

On a related note: a little Googling brings up this fascinating looking book whose price or $199.95 puts it beyond that of anything I’ll buy without having a damn good idea of what exactly is inside. Also, why is it that I never heard the phrase “Financial Entropy” until last night in my dreams?

 
 

It reminds me of home… November 14, 2006

Filed under: Uncategorized — masukomi @ 4:51 pm

It was foggy the other day in Boston and I couldn’t help but take some pictures. Something about this picture just makes me feel like I’m home. I don’t really understand it though, because it’s the old parts of Boston that I truly love.

 
 

Improved extract_fixtures

Filed under: Uncategorized — masukomi @ 12:36 pm

I’m not sure where I originally came across the extract_fixtures rake task (maybe here)but there’s nothing better than using real data to run your Rails unit tests. Well, real in the sense that it was generated by actually using your app. But there’s a problem with extract_fixtures. Once you get some real data to base your tests on you don’t want it to change because it would break your tests. So, after the first run extract_fixtures becomes almost useless because it’ll wipe out the fixtures you’ve been working with.

So what’s a girl to do? Well, in my case the answer is to beef it up a bit. The following version of extract_fixtures takes two optional parameters:

  • TABLES=foos,bars,other_foos

    Tables takes a comma delimited (no spaces) list of table names that you want to extract. If you pass this in it will only extract those tables.
  • OUTPUT_DIR=/some/fully/qualified/non-relative/path

    Tell it what directory to output to.

If you improve it further please drop me a line and I’ll add or link to your enhancements here.

desc “Create YAML test fixtures from data in an existing database.  “ +
” Defaults to development database.  Set RAILS_ENV to override. “ +
“\nSet OUTPUT_DIR to specify an output directory. Defaults to test/fixtures. “ +
“\nSet TABLES (a coma separated list of table names) to specify which tables to extract. “ +
“Leaving it blank will extract all tables.”

task :extract_fixtures => :environment do
  sql  = “SELECT * FROM %s”
  skip_tables = [“schema_info”]
  ActiveRecord::Base.establish_connection
  if (not ENV[‘TABLES’])
    tables = ActiveRecord::Base.connection.tables - skip_tables
  else
    tables = ENV[‘TABLES’].split(/, */)
  end
  if (not ENV[‘OUTPUT_DIR’])
    output_dir=#{RAILS_ROOT}/test/fixtures”
  else
    output_dir = ENV[‘OUTPUT_DIR’].sub(/\/$/, )
  end
  (tables).each do |table_name|
    i = “000″
    File.open(#{output_dir}/#{table_name}.yml”, ‘w’) do |file|
      data = ActiveRecord::Base.connection.select_all(sql % table_name)
      file.write data.inject({}) { |hash, record|
        hash[#{table_name}_#{i.succ!}] = record
        hash
      }.to_yaml
    puts “wrote #{table_name} to #{output_dir}/”
    end
  end
end
 
 

Why Rails Migrations are wrong headed November 5, 2006

Filed under: Uncategorized — masukomi @ 11:53 am

Ever since migrations were introduced to Rails I’ve heard nothing but praise for them, and truth be told, they are a far better way of setting up your database than the standard raw sql import. But, that’s where the goodness ends.

The problem is in the concept of going up or down in database versions. The core concept is great, to be able to roll back to a previous version of the database, but the implementation is completely out of sync with the version control systems we use to manage the codebase that depends on that database. I’ll use subversion as an example because (for those of you still stuck in CVS land) every time you do a check in the system gets tagged with a new revision number.

Everything starts out fine. The initial migration reflects the needs of the initial codebase. But after that they’re never the same. There’s no way to now what migration corresponds to what version of the codebase. What if in checkin 400 I add a new migration that changes the schema. A few weeks later I need to roll back the codebase to version 380. What migration number should i roll the database back to if any? Unless you happen to remember what migration number you were on when the codebase was at 380 you’re screwed.

So what’s the solution?

Well, the solution starts with the schema.rb file that’s created every time you run a migration. If you’re like me, that gets checked in whenever it changes and the schema.rb file is always in sync with your codebase. So you’ve always got a representation of the appropriate database configuration for any revision of your codebase. That’s good. In fact that’s better than the actual migration scripts because it’s always in sync. But there’s one more problem…

**Priming the database**
Most webapps don’t function well with a completely empty database. There are usually some default settings, maybe an admin account to log in with the first time, things like that. And there are a few rake tasks out there to [bootstrap your database](http://rails.techno-weenie.net/forums/2/topics/778?page=1) with the contents of some .yaml files. There are others to [dump your database](http://media.pragprog.com/titles/fr_rr/code/CreateFixturesFromLiveData/lib/tasks/extract_fixtures.rake “warning, that’s a raw rake file”) into the same files for later import, or generating real data to run your tests against.

**Putting it all together**
If you make sure that your your .yaml files for bootstrapping are always in sync (you should be keeping them in sync anyway) then you can avoid the problem entirely by just making your own schema.rb file (it’s just a migration file for all the tables at once) and never running `rake db:migrate` again. Instead run your schema.rb (make sure it forces table creation) and then `rake db:bootstrap`. When you need to modify your database schema don’t make a new migration script. It’ll only confuse matters down the road. Instead, modify your schema.rb and make sure your .yaml files are in sync (you’d have to do that even if you were using migrations).

[Damien Tanner](http://iamrice.org/) points out that migrations are *very useful* when migrating a live site. And I have to agree. My proposed solution is seriously lacking in that department. What would most likely be best is a blending of both concepts. Don’t use migrations to muck about with your database during development. Instead, create migration scripts *only* for migrating data on live sites. Don’t title them “`create_foo_table`” or “`add_foo_column`” but instead name them something like “`live_site_version_4`” or something like that that makes it clear exactly what it’s for and how it pertains to your site.

 
 

setting things in motion November 4, 2006

Filed under: Uncategorized — masukomi @ 1:20 pm

There’s been a lot on my mind lately. Gears a-moving. Projects in motion. And things to say…

I’ve had a lot to say lately, not that you’d know it from my lack of posting. But, that’s mostly because I find spam really demoralizing and some Arse-hole was manually submitting it! Bots I can understand, they suck but at least it’s just some mindless thing that happened to find a site it knew how to submit to. But no. weblog.masukomi.org was a one of a kind intstallation. So writing a bot for it would be pointless. ARGH someone too the time to manually add spam to all my new posts!

I couldn’t take it.

So, I sucked in my gut, upgraded mysql, (after doubly covering my butt against potentially hosing client databases on this box), and installed [Mephisto](http://mephistoblog.com/) (edge version). I said “screw it” to dealing with making a custom theme. There’s just way too much on my plate right now that I consider far more important. Like:

* The new web based version of ListfulThinking (not released yet).
* Another web app I’ve been working on to support ListfulThinking, then realized I could sell it too!
* Bug fixes for [ServerWatcher](http://serverwatcher.masukomi.org/) (not formally released but available in [CVS](http://sourceforge.net/projects/serverwatcher))
* A book on managing open source projects.
* And the big one you’ll see in a couple days… Caterpillar 3.0.

Caterpillar 1 and 2 were extremely compact news aggregators written in Java with a Swing UI. Caterpillar 3.0 adds Bayesian filtering to find “interesting” articles. Why? Well, you see I, unlike most people, subscribe to a LOT of feeds. 220+ last time I checked. Mostly blogs of programmers like me or people like [Dooce](http://www.dooce.com/) who just rock. But, while I’m definitely the exception you probably do exactly the same thing with Mailing lists. You end up subscribed to many interesting lists, get flooded with so much mail you couldn’t possibly keep up with it all, and then get frustrated because you *know* you’ve missed something interesting in there.

So what’s the solution? The same thing Thunderbird and just about every other mail app uses to keep out spam. Just reverse it and apply it to feeds. Instead of leaning what articles suck (spam) you train it what articles rock.

I’ve been sitting on this for over a year now. It’s a great proof of concept and I knew that with a bit more work it could be something sellable. Except, I have other projects that I am far more interested in working on and I realized that I’d been completely ignoring my own advice on when to set an app free.

As I’ve said before I think that there are some great reasons not to open source an app. The biggest of which money. But far too many developers keep things under wraps because they “might sell it someday”. Well, that’s just what I had been doing. Actually I was serious about selling it for a while but things changed. I met a girl named [Ruby](http://www.ruby-lang.org/) and fell in love. Java…. well, we won’t talk about him. Boys are icky anyway.

So, yeah. I commented out the registration bits, made some bug fixes, and will be releasing it shortly. But, I don’t really have much interest in setting up yet another project and adding yet another source of bugs needing fixing to my plate (what with two potentially profitable and far more enjoyable Ruby on Rails projects on the horizon). So it will be a drop shipment kind of release. Kersplat. code… dribble….

Regarding this site:
The feed is… well, don’t subscribe to it quite yet, I still need to hook it back into feedster which means it’ll probably be repointed within a few days, but it’s late, and i’ve been poking at annoying bits for hours now.

The old articles… no clue. Maybe I’ll take the time to import them. Maybe I won’t.

In the future you should expect a different kind of blogging from me. I’m planning on doing a [Paul Graham](http://www.paulgraham.com/) kind of approach to it. Well written articles (unlike this one) with a point. I’ve got a few queued up in my head already.