There are a group of activist technologists, lawyers, and artists who are working hard on a very important issue that doesn’t get much press: the xcasting rights treaty currently being considered by WIPO. I’m on a couple mailing lists where folks are discussing this issue, but haven’t kept up with the discussion or attended any events lately.
Manon Ress has posted the minutes of a meeting with I believe the US WIPO delegation (and representatives from (pro-xcasting treaty) industry) where this group of activists were discussing their concerns.
ShareThis
Will recently emailed me and proposed a new Rule:
this will be called the ten-of-everything rule and it goes as follows:
“there are at least ten of everything.”
it does not refer to unicorns, although that would be nice. rather, it refers to people who know in their hearts that they have seen and touched a unicorn and are willing to say so under oath. it also refers to the swift boat veterans for truth.
the corollary to the ten-of-everything rule is the probably-only- like-10 rule, which states:
“…but there are probably only like ten, though.”
TOE and POLT for short.
when properly invoked, TOE and POLT work together to protect us against the consequences of our brains not being able to conceptualize of a world with 6.5 billion individuals and the complex web of relationships, infrastructure and events that that entails. we conceive of the pool of possibilities as being much smaller than it actually is. the gravest consequence of this is that we automatically assume that any unexpected phenomenon that suddenly arises is both (1) unique and (2) important. skilled craftsmen have already learned how to manipulate us via this cognitive illusion, but the radical refinement of technology such as aggregation allows this manipulation to reach dangerous levels. the only reasonable response is to cultivate a reactive attitude that marginalizes everything. grunge theorists in the late 20th century were making strides toward realizing this goal before the movement was infiltrated and assimilated.
ShareThis
My friend memorly writes about her horrible experience with Camera Works in Durham, NC. Beware.
ShareThis
There are two aspects of how MySQL/InnoDB use a table’s primary key on the file system that have important ramifications for the key’s design:
- The primary key determines the order in which the data is physically stored in the main data file, aka “the clustered index”. Another way of saying this: the main data file is a B-tree index that directly contains all of a table’s columns, and the key on this B-tree is the primary key. This can result in one less I/O operation (compared to MyISAM) on many queries.
- The primary key is what is used to associate all of a table’s indexes with the main data file. So the primary key is replicated in every row of every index.
How to design your InnoDB primary keys:
- Do explicitly define a primary key, and make it numeric. If no primary key is specified, or a non-numeric column is used as a primary key, InnoDB will used its own internal auto-incremented row ID to link between the main data table and the other indexes. This row ID is 6 bytes. The biggest numeric type in MySQL, BIGINT, is 8 bytes, and the next smallest type, INT, is 4 bytes. So not only is this “hidden” row ID an entire extra redundant column, it is also bigger than the data type that would be used in the vast majority of cases where a primary key is explicitly specified. Furthermore, when InnoDB falls back to using this internal row ID, the rows in the main data file are ordered by insertion order instead of your primary key, rendering InnoDB’s clustering behavior useless, and adding an entire extra I/O operation on some queries. This is a big loss.
- As alluded to above, the primary key should be sequential. Because the structure of the data on the disk is dictated by the primary key, it should be sequential, to avoid extremely expensive I/O on writes (when the B-Tree has to be reorganized), and to take advantage of the native clustering.
- The primary key should be as small as possible. Because the primary key is replicated in every entry of every index, designing the primary key to be as small as possible impacts the efficiency of all the indexes.
Using these 3 simple guidelines on a well-designed schema, InnoDB can perform at its full potential.
Above I mentioned that the primary key is stored in every row of every index. This includes the entire contents of a multi-column primary key. In a future article I will discuss scenarios/designs that can take advantage of this behavior.
ShareThis
In my quest for arbitrary and useless lexical elegance, a couple years ago I decided on a /%post_id% permalink structure for my blog. So all the URLs were of the structure http://blog.johnjosephbachir.org/330. Since then, Ben has convinced me that a /date/title structure is the way to go, as it provides orientation for the user in terms of where the content came from. Also, it allows me to never worry about my permalink structure changing again, in terms of namespace etc.
Another benefit, as noted on the claimid blog a few months back, is that search engines put value in the strings that are found in URLs. So there is a SEO benefit in having title slugs in urls.
I changed the permalink structure in the WordPress control panel, but to get permanent 301 redirects from the old URLs to the new, I needed to use Apache mod_rewrite. Here is what I came up with:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([0-9]+)/?$ http://blog.johnjosephbachir.org/?p=$1 [R=301,L]
</IfModule>
# below are the standard WordPress rewrite rules
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
ShareThis
Latest Comments
RSS