Jay McGavren’s Journal

At the behest of the Free Software Foundation, I just fired off an e-mail to the USPTO:

Subject: Software patents limit the scope of my career!
From: Jay McGavren
To: Bilski_Guidance@ .gov
Cc: licensing@ .org

To whom it may concern:

I have countless ideas for new software that I would like to
implement. I would love to go into business for myself, to publish
new, novel, and useful software. Maybe I’d make a little money in the
process, but mostly what I want is a place in the hearts and minds of
devoted users, who benefit from my designs every day.

But every time I come up with a new idea, I stop myself. I do a quick
mental check of the underlying technologies I would need to build on
top of. Basic ones, ones we all take for granted. And almost every
time, one of those basic technologies is currently in litigation over
some overly broad patent, often a patent issued despite obviousness or
the existence of prior art. And I drop my idea, because I’m not
willing to risk my career and my family’s future on a venture that can
be shot down at any moment by a huge corporation’s legal team.

…That part was from the heart. And then, not sure of the finer points of Bilski v. Kappos, I pretty much plagiarized their talking points for the rest.

Rulings from the Supreme Court of the United States have never
validated the patentability of software. Bilski v. Kappos shows that
the historic interpretation of patent eligibility is far too broad.
The machine-or-transformation test is not suitable as the sole basis
for determining patent eligibility. Software consists of mathematical
computations, and combining software with a general-purpose computer
is obvious. As such, software should never be considered patentable.

Sincerely,
Jay McGavren
Mesa, AZ

I actually don’t favor completely eliminating software patents. But the current system is broken, and frankly, it has developers everywhere shackled. If my options are to keep it as-is or throw it away altogether, I’ll choose the latter.

I had a spectacular time live-coding on a visualizer for the third Desert Bloom PHX party tonight. I learned a few lessons while doing it, though, which I thought I’d share while they’re still fresh in my mind. I’m hoping these will help anyone who needs to supply visuals for parties.

If you’re randomly generating settings, some of them are gonna look like crap. Code up a way to quickly serialize presets to disk that you can switch between when you have an audience. (You probably don’t need a file save dialog, just a save button. Think “that’s pretty, save that” and “load up the next preset, whatever it is”.)

def save_preset
    t = Time.new
    file_name = sprintf("%04d-%02d-%02d_%02d%02d%02d", t.year, t.month, t.day, t.hour || 0, t.min || 0, t.sec || 0)
    File.open(File.join(preset_directory, file_name), "w") do |file|
        file.print YAML.dump [source_factories, @assigned_factories]
    end
    file_name
end
def next_preset
    directory = Dir.open(preset_directory)
    files = directory.entries[2..-1]
    @preset_index = @preset_index ? @preset_index + 1 : 0
    @preset_index = 0 if @preset_index > files.length - 1
    path = File.join(preset_directory, files[@preset_index])
    source_factories, @assigned_factories = YAML.load_file(path)
    path
end

Turn key settings of your visualizer into a Web service or other network service. I made the onscreen text and “next preset” functions (among others) accessible over the network, then used a script on my smartphone as a remote control, leaving me free to roam the room. This also enables something as simple as control from a second terminal window on the same machine.

class <<f
    attr_accessor :text, :text_separator, :max_font_size, :min_font_size, :reset_odds, :shape_type, :max_shape_count, :listen_url
    attr_accessor :max_size
end

Continue Reading »