Proc.new

We (Ceaser Larry and I) are starting a new segment of the Utah Ruby User Group called the Layton.rb. Ironically our first meeting will be held in Clinton, but we expect to find a place in Layton to host the meeting ongoing. The meetings will be held on the first Tuesday of every month, which means the first meeting will be held Tuesday, December 5th. I’m pretty excited about this, because I enjoy talking with people about technology, and it’s very exciting to meet people in the local area who like Ruby. If anyone reading this is interested and lives in the Layton Utah area, drop me an e-mail at nurug.closure@recursor.net.

Microsoft has been on the offensive when it comes to piracy lately, but perhaps their most interesting move lately comes with the Zune. The Zune has been receiving a lot of press lately, most of it deservedly bad. There is just one little area I’d like to focus in on though, and that’s the agreement Microsoft has made with the Music companies. As reported here:

The Final Reason I Won’t Buy a Zune

and here:

Avoid the loony Zune

Microsoft has made an agreement with at least Universal Music, and potentially others to pay them compensation for stolen music on the Zune. This means that every Zune sale results in a royalty type payment to Universal and whoever else has made the agreement with Microsoft. Having set a price on each Zune unit, Universal has done a couple of things.

1) They have capped their damages on a single unit. The music companies have been leveling extortive fees of many thousands of dollars at people caught with pirated music. Now that they have agreed to a specific monetary amount for each Zune, they will be hard pressed to ask for more money from any defendant since they have specifically set an amount that “pirated” music on a single device is worth.

2) You pay the fee on the Zune no matter what, therfore by purchasing a Zune you have already paid the above mentioned damages, which should effectively authorize you to download as much illegal music as you can fit on the Zune.

As I said above, I am not a lawyer, but if anyone reading this is a lawyer with experience in this area, I’d be interested in hearing what you have to say. If you are from the music companies, move along please, nothing to see here.

Microsoft may have gotten the Zune so wrong that they unintentionally got something right.  It seems as if their war against piracy will have the opposite of the intended effect.  Rather than sinfully admitting that people are going to use the Zune to pirate music, it seems like this deal paves the way for the legal piracy of music.

Slashdot ran into a major problem with their comment system today. Apparently they have a column called “parent_id” or some such that they forgot to switch an index to a 32 bit integer. The net result is they have disabled threaded comments until they can alter the table to 32 bit integers. They figure on that table it will take them 3+ hours to re-index it.

As a database guy I find this hilarious on multiple levels. First of all, I have to wonder who’s stupid idea it was to use a 24 bit integer anyway? On a 32 bit machine you don’t gain anything by using 24 bits intead of 32. The biggest thing to think about is your register size. You want your keys to align to the register size because to scan the database it takes fewer operations. Here is an example:

Let’s say you want to scan the ORDER table and find all the ORDER_DETAIL entries for each Order. Assuming your order_id is something reasonable like a 32 bit integer for 32 bit machines, the process would work something like this. You fetch order_id from the Order table into a register, you then fetch an order_id from the ORDER_DETAIL table into another register and you perform one operation to compare them. Then you move to the next order_id in either the ORDER or the ORDER_DETAIL table depending. The thing to note here is that the smallest thing you can load into the register for a comparison is 32 bits, or 4 bytes (again, assuming a 32 bit machine). So you save nothing by using a 24 bit integer, in fact it’s very possible you could waste extra operations aligning the integers into 32 bit sections of memory! Conversely imagine if you used something like a GUID for your order_id, but instead of storing it as a native GUID type and storing it in 16 bytes, you decide to store it as varchar(36), (don’t laugh, I’ve actually seen this). Now to compare one row in ORDERS to one row in ORDER_DETAILS you have to load each character into a corresponding register and compare them. After comparing the first character you then have to load the next character for each order_id into the registers and compare them, and so on. This is obviously going to take you much, much longer. How much longer will depend on how well optimized the code is, but in general I would suspect this is going to take about nine times longer than just comparing an integer key.

I honestly feel slashdot’s pain, but as someone said in one of the comments, “yes, this could happen to anyone, it’s just much funnier when it’s happening to someone else.”

Welcome to my little corner of the Internet. I like to ramble on about things that are technology related or startup related. You can take a quick look at the categories on the sidebar to get the gist of what this blog is about.

My name is Doug Tolton, I’ve been a professional programmer for over a decade now. Currently I’m hooked on Ruby on Rails, and I’m working on a new product that I hope to form a company around. This will be my fourth company, and before you ask, no I’m not rich yet. I hope to share some of the mistakes and lessons I’ve learned along the way to anyone who wants to learn through someone else’s experience.

Why Proc.new? Proc’s create blocks in Ruby that can be passed around and manipulated, they are a fundamentally powerful concept and one of the core idioms in Ruby. Learning about Procs in Ruby is important if you are interested in high level abstraction. I also couldn’t think of anything that was short that used the words database or entrepreneur, thus, Proc.new.