October 2010 Archives

Book Review - HTML + CSS: The Good Parts

Over the last few weeks, I read Ben Henick’s HTML + CSS: The Good Parts, published by O’Reilly Media. I grabbed the book in part because of having read the excellent JavaScript: The Good Parts a couple of years ago, written by Yahoo!’s own Douglas Crockford, whom I will have the opportunity to hear in a couple of weeks at YUIConf. Unfortunately, Henick’s book didn’t strike me as strongly, but I think that was largely a problem of scope.

See, Crockford only had to talk about JavaScript, and specifically the language as defined in the ECMA standards. Henick, on the other hand, has to discuss not only the standards around HTML, CSS, and DOM, but also the differences between browser implementations, at least in the most important places. True, Henick’s book is twice as long, but the problem space is over ten times as big.

I’ve been doing web development for the last four years, not exceptionally long, but in that time I’ve thrown myself into the problem space trying to become proficient. Had I read this book three years ago, I’d probably feel a lot more positive about it. Which is unfair, it’s actually an excellent book, even with it’s near constant referrals to the companion website, and even having finished the book, I have used it for reference on a few things that I knew I’d remembered reading in it, particularly when investigating how to deal with the IE menace from time to time.

This book is not the canonical source for any one topic, but as an overview, it’s excellent. And Henick is always there pointing toward more complete resources, from references to dozens of other books or websites that cover the topics in more details. If I managed new web developers, this is probably the book I’d issue to all my hires. It contains plenty of good information, and it’s a solid overview.

If you’re new to the web, it’s where I’d suggest you start. If you’ve been in the ecosystem for a while, and have really been immersed in it, well…this probably isn’t the book for you. I suspect the primary reason I reached to it for reference recently was largely that it was fresh in my mind. Make no doubt, this book is useful, but the size of the problem it’s talking about is so broad, that is mostly only scratches the surface. I know that I’ve collected more complete references on many of these issues, either in books or in links.

The book was good, but I don’t necessarily think it was good for me.

Paper Review: Robust Flexible Handling of Inputs with Uncertainty

This week I read A Framework for Robust and Flexible Handling of Inputs with Uncertainty, written by Carnegie Mellon researchers Julia Schwarz, Scott E. Hudson and Jennifer Mankoff, and Microsoft Research’s Andrew D. Wilson. I grabbed this paper because I’ve seen several references to it recently by people working on touch interfaces, such as Canoncial with the new Multitouch support they’ve made a priority for Ubuntu 11.04. Howver, while the information in this paper is relevant to touch interfaces, I think there is a lot of lessons to be learned from this paper for writers of UI frameworks.

The basis of the methods explored in this paper are fairly simple. Knowing that some events are hard to lock down to a single item, like a user touching a space that overlaps multiple buttons in a UI, the framework would support handling multiple events until it’s able to determine which one is the one that should be handled, based on changing probabilities as condition change. The first example provided was the user touching near the edge of UI window that had a desktop icon also under the window edge. Is the user trying to move the desktop icon, or resize the window? Under the framework, both events would be handled until it can be determined which one was the ‘real’ event. Too much vertical motion? User was almost certainly not trying to resize the window, move the desktop icon. Can’t determine? Don’t do either.

Certainly, this makes a lot of sense in touch. Currently, when designing touch UIs, the current thinking is that touchable controls should be large enough that the user is unlikely to miss. One of the working examples in the paper involves the size of the user’s finger basically covering three small buttons, one of which happens to be disabled, and correctly determining the right course of action, which based on their example may not have worked out if that third button had been enabled.

This research was most interesting, because they were also able to provide examples of how this system could improve the user experience for vision- and motor-impaired users. Plus, it can apply to simple mouse interactions as well. In the default GNOME themes for Ubuntu since 10.04, the border of a window is almost impossible to select for window resizing, making it nearly impossible to resize the windows, unless you grab the corners, which may not always be what you want.

The nice thing about this paper, is that it definitely talks about a framework, and I’m a bit disappointed that their .NET code doesn’t seem to be available. But since it’s a framework, the bulk of the development would need to be done by the UI toolkit developers, and sensible probabilty function defaults could be defined that many developers probably wouldn’t generally need to modify.

In a sense, I’m a bit disappointed by all the attention this paper has gotten in the ‘touch’ interfaces communities, because I really think that it’s as important, if not more, for accessibility, and improving ease of use for impaired users and even the rest of us. It may add a bit of overhead, both on the system and developers, but the authors mention in the paper that they built an accessible set of text inputs in about 130 lines of code, that would determine if input made sense for them via regular expressions. Adding support to take voice input was about another 30 lines of code.

My hope, after reading this paper, is that the multitouch working that is going to be happening in Ubuntu over the next few months will impact the rest of the system positively as well. I think that’s reasonable, since I’ve heard that there is a huge accessibility focus at the developer summit this week. Now, there is still a lot of work to be done in this space, I think, particularly as we move more toward gesture based inputs and such, but there are definitely places where it could be applied today, though I think it would best be done at the UI Toolkit layer, so that it’s available as broadly as possible.

Next weeks paper: Thumbs up or thumbs down?; semantic orientation applied to unsupervised classification of reviews.

CSS3 Query Selectors Specificity and Performance


Yesterday, on #yui on freenode, Anthony Pipkin answered someone who was trying to select a node via it’s ‘name’ property with the suggestion of using Y.all(‘[name=blargh]’). I asked him why he didn’t use input, to which he responded that he was trying to include textarea and select elements as well, which was an absolutely fair point. However, I was immediately curious about the *performance hit the selector took using ‘*’ instead of ‘input’ or something more specific.

So, off the jsperf I went to build two test cases for each jQuery and YUI, one each for the specific selector (‘input[name=foo]’) and for the generic selector (‘*[name=foo]’). I encourage you to go run the test to update the Browserscope numbers.

The findings, in short, were straightforward. Using the specific selector was always faster, by a noticeable margin. In Firefox 4, it’s only about 5%, but in Chome 7, that goes to around 14%, and nearly 30% slower in IE8.

Now, for a one-use selector, this may not be that big of an issue, but any repeating selector should absolutely be as specific as possible, and it’s worth noting that a poorly chosen selector really can have significant performance impact.

As an aside, you’ll likely notice that in current versions of both YUI and jQuery, YUI outperforms jQuery by a noticeable margin.

Dishwasher Installation

A month or so back, the Dishwasher in our place (a Whirlpool SHU5000-0) died suddenly. That particular model, it seems was originally manufactured in 1989, and parts for it are basically impossible to locate. So, after messing around trying to locate parts, I finally came to the decision that I had no choice but to buy a new one. So, Catherine and I drove up to Spokane to look at the Fred’s Appliance ding-and-dent center to see if we could get a good deal on a unit. For around $300 (with $100 in rebates for it being Energy Star), we walked away with a unit that is larger, worlds quieter, and generally better than the unit that we replaced. It’s an Estate unit, which was nearly identical to a Whirlpool (Estate is a Whirlpool brand) that cost about $200 more, so I think we did well. In fact, with a few simple hacks, I think I could make it identical, but I’ve been informed that dishwasher hacking is not in my future.

There are a few things that the otherwise very helpful sales guy at Fred’s didn’t talk to us about, and that was that we didn’t get a blanket for the dishwasher, which can help with sound and which we’ll probably need to buy later, and Dishwashers do not typically come with electrical cords, since some are hardwired into the house electrical evidently. We installed without the blanket, which may be okay since this unit is already so much quieter than our old one, and for the electrical cable, I built one with extension cord parts bought at the local hardware store, and it works fine.

Installing the unit was fairly straight forward. Holes had already been drilled in the cabinet, though I had to drill an extra one for the water line since the plug on my custom cable was dramatically larger than on the old cable. The original water line was bent copper, which I thought was probably only done twenty years ago, but according to the installation instructions for my new unit apparently isn’t that unusual anymore, still I had to replace the line since the interface wasn’t compatible, and went with a braided steel cable, which wasn’t a problem because the size of dishwasher supply lines apparently hasn’t changed over the last few decades.

We followed the instructions in the book pretty closely. Ran the water and drain lines, taping them to the ground and pushing the dishwasher over them, the water line having a 90° adapter. The electrical line was a bit short, so I tied twine it to it, and Catherine fed it through the cabinet hole while I pushed the dishwasher in. In retrospect, I wish we’d done the same with the water line, but more on that in a minute.

Hooking up the drain line to the waste disposal (or drain tee), and to the dishwasher simply involved a pair of compression clips included with the dishwasher. A good pair of pliers, and a bit of hand strength, is all that’s needed to install those. What was the biggest challenge after the unit was standing up, was installing the water supply line. This was partially because the 90° adapter was brass, with a large rubber grommet that would slip loose, while the connection on the dishwasher was plastic. Installing that under very tight quarters was quite difficult. Next time, I’m going to attach the line to the washer, and pull it through the cabinet using twine. It will be easier and cause me less heartache, I’m sure.

There were two things I learned from this experience that are very important. If you have an opportunity to get the install guide easily, take it. They unboxed my unit at the store, and while I had the opportunity to pull out the instructions before it was wrapped in plastic to go in my truck, I didn’t take it and they were sealed inside the washer, meaning my first trip to the hardware store for parts did not get me everything. Second, make sure you understand what you need. To properly install the electrical cable, I needed a strain relief that was not included on the parts list, because apparently I was expected to buy a $20 electrical cord kit from Whirlpool. Building my own cable was ~$5, including the strain relief. Also, if the hole your strain relief needs to fill is 7/8”, a 3/8” strain relief is actually large enough, because they measure the size differently, luckily the guy at the hardware store was really helpful, but I still bought a few extra, with the intent to return them if they didn’t fit.

In the end, this process ended up being significantly harder than I thought it would be. There are a few tricks I learned that will make future installations (if I have any) significantly easier. It may have taken a lot longer than it would have if we paid someone, but I figure we’d have had to pay a plumber enough that it was worth it, even if the kitchen being torn up did stress the cats out pretty bad.

Oh, one last note, the shutoff valves under our sink were rusted shut really badly. You should close them at least yearly, preferably every six months, to make sure that in an emergency you can shut them off easily. To get ours unstuck, I used PB Blaster, which smells bad and kind of goes against our tendency to try not using heavy solvents, but it works, and it works quickly, and frankly, I’m not sure any natural products would have solved my problem. I’m definitely planning to keep the shutoff valves turning more freely in the future.

Washington State Elections for 2010

The State of Washington is in a pretty difficult place right now financially, like many states. Now, we’re not as bad off as say, New York, or California, but Washington State University has faced over 10% budget cuts each year for the last three years, and many other state-funded agencies have faced similar, if not greater cuts.

So, it is little surprise that at least half the State Initiative Measures are to do with new taxes, either the repeal of recently passed ones or the state requesting the right for new taxes. I’m going to do a bit of discussion of each of these initiatives, presenting my views on them, in part to think my way through the issues.

Politically, I am a fiscally conservative Libertarian, which is the basis of where most of my opinions come from.


This initiative appears to basically serve to remind the Legislature of other restrictions passed via Initiative in years past regarding increasing taxes. It’s basically a way to remind the legislature what the people expect of them, without actually changing the people in office. A complete waste of time, and I may simply abstain from voting on this issue.


Gets the state out of the business of Industrial Insurance. I’m in favor, as it lowers the scope of government, but still forces the maintenance of insurance for industrial operations. How will this affect things? I’m not sure, but it should simplify government operations.


This initiative would, for the first time institute an income tax in the state, though they’re being very sneaky in the way they’re going about passing it. Namely, as written, the tax would only apply to individuals earning $200k per year ($400k for a couple), and the proceeds would be used to lower B&O taxes for small business and property taxes.

First, this initiative can only benefit me as a small business owner and a homeowner.

Yet, I’m opposed. Why? Well, first off, it’s uneven taxation. Now, I’m not arguing for a flat tax, but if you’re going to institute an income tax, institute a fucking income tax. Especially since the government would have the right to expand that income tax to more people. I would say that, within 5 years or so, the middle class, who this law is supposedly meant to help, would be paying this income tax.

I have seen and read several things on the wisdom of readjusting wealth distribution to narrow the gap between the middle class and the highest ends, and I generally agree, but I just don’t think this is the way to do it. If anything, the work people like Jason Calacanis are doing with groups like the Open Angel Forum, like investing in startups and innovation, is probably a better way to do it.

I-1100 & I-1105

These two initiatives seem to be tightly linked, with I-1100 seeming to deal more with the role of the State Liquor Control Board, and I-1105 being more about privatization of the distribution and retailing of alcohol. As it stands, the State of Washington maintains a monopoly of the sale of all package liquor. Bars can carry liquor, but they can not sell bottles, which was a bit odd after having turned 21 in Montana, where that’s a bit more common.

In Washington, grocers can only be licensed to carry beer and wine, and a non-consumption license is not that hard to get, based on a local short-lived sandwich shop that sold beer, but couldn’t let you drink it. If this initiative passes, the license for the sale of liquor held by grocers will allow them to sale package liquor in addition to beer and wine.

The opposition to these initiatives take a few points:

  1. It will cost people jobs.

    This is, in part, true. These initiatives would close the State Liquor Stores, and distribution mechanisms, but at the same time, in privatizing it, things will likely be even, in particular because private liquor stores will probably remain open later than 6pm.

    There is also a bit of discussion about it hurting the bars, but I’m not convinced. *Most* people who go out to bars drink Beer anyway, and bars tend to be busy, so I don’t buy it.

  2. It will result in more drunk driving.

    Doubtful. If people are buying liquor to take home, they’ll probably be doing it when still sober. Even if this results in the sale of more liquor, which it may not, I’d be interested in seeing what justifies this argument.

Actually, I’m going to leave it there, because the rest of the arguments against are basically rehashes of the second point above. Current state policy toward spirits is unreasonable, as it unfairly singles out liquor in a way that only makes sense in a moderately prohibitionary way. The State will still be able to tax spirits, in fact the initiatives seem to talk a fair amount of the liquor control board having that right, but it will greatly increase the overhead the state needs to incur in managing spirits, allowing the liquor control board to spend more time.

I am wholly in favor of these initiatives. I don’t think increased availability of alcohol will be a problem, because it’s not exactly unavailable. Grocers and gas stations can sell beer and wine until 2 am, as can bars including liquor. If anything, this might encourage more consumption in situations where a person doesn’t need to drive and risk themselves and others.


This initiative repeals taxes on candy, bottled water, carbonated beverages and other foods defined by a fairly complex set of standards. The argument against is pretty straightforward: the state needs to raise funds, and this is meant to help with that.

The for argument is slightly more complex. First, the laws passed by the legislature do some pretty crazy things, like applying taxes to products made by Washington companies, but keeping similar product imported from outside the state as tax-exempt. Then there is the standard argument against raising taxes. Now, generally, I’m against raising taxes, but I’m also generally against the government offering more services. I know full well that if we want more services, we need to be willing to pay for it, and most people don’t, which is why we’re in this economic mess right now (at least in part).

The main reason I’m opposed to this legislation is not the increased tax burden (which I’m not pleased about), but it’s rather that this law feels like an attempt to mandate behaviour via taxes, which is unsustainable, because if you succeed in changing people’s behaviour, your income goes away, but also it’s not the role of government. I would, quite frankly, have been more in favor of (though still likely opposed) to a blanket sales tax on food items.

Language Support for Lightweight Transactions

For this week, I read Language Support for Lightweight Transactions by Cambridge Researchers Harris and Fraser from 2003. The paper outlines the development of software transactional memory as a feature built into the Java Programming language. I had first read about STM as a feature of Haskell while reading Beautiful Code, which is what pulled me into this paper.

Concurrency is a big problem in modern computing. We’ve reached a point where processors aren’t getting faster, but we’re getting more cores. On one hand, this is great for multi-application environments, because each application can have full access to a core. In practice, this actually doesn’t work, since on Intel chips, the cache is shared between all the cores (which works better for concurrent programs), and some applications really need to additional speed.

STM is an mechanism of defining small atomic operations that you can be assured of will be viewed by every other application as a single op. For a simple example:

class Account
    private int balance;

    Account(int intialValue)
        balance = initialValue;

    public int getBalance() { return balance; }

    public void deposit(int amount) 
        balance += amount;

    public void withdraw(int amount)

    public void transfer(int amount, Account toAccount)

Now, in a multi-threaded environment, the above code could have problems, because deposit actually involves 3 instructions: read balance, add amount to balance, write balance, and if there are two deposits being made to an account, then they could both read at roughly the same time, which would cause their commits to be inaccurate.

With STM, you indicate somehow that they’re ‘atomic’ functions, and it checks that the value in memory hasn’t changed since you read it, to ensure that your changed amount it correct, if it has, the transaction aborts and can be retried again. It’s a similar practice to transactions in a SQL database, and as such, it does add overhead to the operations. But so does traditional locking using mutexes and semaphores.

Which is where the findings of the paper were most interesting. In their trials, using a highly tuned hash-table implementation using traditional locking mechanisms, either a single lock for the entire table, or fine-grained locking, and a simple implementation using STM, they found that the overhead on each operation in the STM case was actually pretty small compared to the fact that it was essentially non-blocking, only needing to redo work on the off chance that the same records were being updated.

With language support, which in Java would look like this:

class Account
    private int balance;

    Account(int intialValue)
            balance = initialValue;

    public int getBalance() { return balance; }

    public void deposit(int amount) 
        atomic {
            balance += amount;

    public void withdraw(int amount)
        atomic {

    public void transfer(int amount, Account toAccount)
        atomic {

The atomic keyword, at least in the research compiler that this paper was based on, who’s source can be here, would handle the creation of the transaction, as well as the enforcement of it. With STM, deadlocks are basically impossible. If a transaction fails, it can be re-executed after waiting a random interval, and move on from there. Using mutexes, the transfer function could easily deadlock with a programmer error.

This paper was really interesting, because the Haskell version makes a really big deal about not allowing functions that perform IO inside of transactions, and the Beautiful Code discussion of the feature made it sound like STM practically required being used in a purely functional language, but this paper showed that clearly wasn’t the case, and has made me very curious about other ways to use this technique.

Next weeks paper will be A Framework for Robust and Flexible Handling of Inputs with Uncertainty.

Liberty and Air Travel

There was a post from over the weekend regarding and ExpressJet Airlines pilot who refused additional TSA screening while entering the airport in uniform, and was not allowed to reach his job. What kind of secondary screening? Specifically the new Advanced Imaging Technology (AIT) systems being installed at some airports, because he didn’t see a reason to allow the TSA to see his naked body. And, then, because he wasn’t willing to be coerced into allowing the TSA agent to molest him, he was forced to leave, but not before being subjected to (probably) unlawful detention and a lot of questioning.

In the end, his supervisor heard about it from the TSA before he was able to get in touch, and his employment is now potentially in question. That’s the short version, you probably ought to read his long version as well.

I understand why the TSA wants to go this route. Almost anything short of patting down anyone getting on a plane can be circumvented. Ceramic blades can be used instead of metal to get through a metal detector. You can load explosives into your underpants and horrifically burn your genitals in a failed attempt to set them off. You can get a job as a ground crew member at an airport, which doesn’t generally require daily security screens. But, it becomes quite a bit harder to sneak a weapon onto a plane without someone storing it internally if you’re using AIT or pat downs.

And yet, we’re really not much safer. The TSA certainly hasn’t been the starting point of any of the successes in the war on terror, those successes generally coming from good old-fashioned police work.

We’ve sacrificed a lot in the name of security, and have gotten no safer. Much of that, has merely been minor inconveniences, like sending our shoes through the x-ray machine, or ridiculously small liquid containers in carry-ons. Some are big inconveniences, like the no-fly list that can thwarted by any decent fake ID.

But a line must be drawn somewhere, and if we’re going to draw it anywhere, it must be on these AIT scanners. Even ignoring people’s health concerns, which seem to have basis, the privacy concerns are just as important. I have an upcoming trip in a few weeks that I’m flying for, and frankly, I am hoping fiercely that I’m not forced to choose between making my trip and facing this sort of coercion.

Programming the Mobile Web

This week, I read Maximiliano Firtman’s Programming the Mobile Web, as I will be starting on a mobile project very soon. This book, I believe, will prove to be a great source for this project, since it covers the Mobile Industry in a nearly comprehensive fashion, which is great to see these days when so many mobile web development books focus on the iPhone. Now, admittedly, there is a lot of iPhone coverage in this book, but there are plenty of features that the iPhone has available today, that haven’t yet all come to other platforms.

However, the majority of the book is about supporting the mobile web in a way that requires the absolute minimum of code, including tools to determine server-side the browser capabilities you’re looking at so you can customize the CSS, JavaScript, or templates you serve up to various users.

This is a hard book to describe. It is not a tutorial on HTML, CSS or JavaScript, and that’s clear. If you are not familiar with web technologies, this book isn’t for you. But if you’re a web developer looking to do a mobile website, then this is a good collection of material to help with that. Firtman has collected together a comprehensive collection of material to point you at various places. For instance, for browser description, there were few code examples, but he didn’t simply cover WURFL, but also Microsoft’s Mobile Device Browser File, which has unfortunately been canned.

There are also several chapters that focus on Web Widgets, which are supported on a few high-profile platforms, but omitted from others. And discussions of web-like development platforms for developing native apps, like PhoneGap, which I didn’t read as closely as other sections.

This book is worth picking up for a few things. The compatibility tables, outlining features you can expect to work on various different browsers, making it easier to create the most basic markup that can then be improved upon with JavaScript and CSS. As well as ways to improve the JavaScript and CSS based on what browsers support. This book is going to be a useful resource, even if it mostly affirmed information I’ve received from elsewhere.

As an aside, I really responded to the section on transcoders. At Portland Code Camp, I attended a session by someone who does a lot of Mobile Web and training herself, but her tone on Transcoding seemed to be more in the lines of “It will happen, just deal with it.” Firtman has Luca Passani contribute a much more, “I’m mad as hell, and I’m not going to take it anymore” attitude. Transcoders do happen, but they should always be opt-in for the developer, instead of opt-out like the transcoder vendors are pushing. Particularly how often a transcoder will try to inject advertising into a stream. As a person who is doing web development for a State agency, this would be a massive problem if someone injected advertising into our data stream.

I enjoyed this book. It has a ton of good information, is fairly platform agnostic, and was clearly written for programmers, not designers, which I gladly count myself on the first group. Though Designing the Mobile Web, from Brian Fling is a pretty useful guide if you’re full-stack like I am.

Twitter Under Crisis

This week, I read Yahoo! Research’s paper Twitter Under Crisis: Can We Trust What We RT?, written by a trio of researchers out of Chile and Spain. The analysis was done over all the tweets sent over twitter over the time period of February 27 to March 2 of 2010, which most likely was sourced through Yahoo!’s access to Twitter’s ‘firehose’.

The crisis was the major earthquake (apparently the seventh worst ever recorded) that hit Chile on February 27, and the tsunami’s that hit shortly afterward. They filtered the data to try to focus on only those accounts based out of Chile (based largely on Timezone settings, which was the most reliable indicator they had available), and a few other factors so they could limit the data set, but also try to focus on those users most directly affected by the disaster.

The Chilean Earthquake was interesting, because as a disaster did a ton of damage to Chile’s telecommunications infrastructure. As would be expected, the traffic spiked early, quickly overtaking discussion of other events around Chile at the time, but petering out within a week or so. However, the idea that people use Twitter to trade news about disasters is hardly news.

What they found was largely unsurprising. Most people (68%) only sent out one or two tweets specifically about the disaster. The most active tweeters about a disaster generally had the most followers, but they were also generally news outlets covering the story (the top was an account named “BreakingNews”). One thing that really surprised me, was the relatively low number of retweets about the disaster, but I suppose that people in the heart of it, weren’t spending a lot of time reading their Twitter feeds for things to resend.

The keyword analysis was also fascinating, showing that Twitter could be used to gauge the progress of a disaster. The first day was all about the earthquakes, resulting tsunamis and people dying. Day two and three focused on looking for missing people, and day four had a ton of discussion about the NASA story saying that this earthquake was so powerful, it actually disrupted the rotation of the earth making days approximately 1.26 microseconds shorter.

The next interesting part of the Analysis was looking at the discussion of fourteen rumours spotted in the Twitter data, seven proven true, seven false. This is a small data set, but the findings are interesting. People were far more likely to question or deny the false rumours (oddly, there were still a lot of affirmations of the false rumours). This is going to require more study, but with enough data, it appears that Twitter can be used as a reasonable predictor of the truth of a claim made by someone on Twitter.

There were interesting findings in this paper, but for the most part, I think it’s a starting point. The findings are promising, in that if you had full access to Twitter’s Firehose, you could form a lot of reasonable conclusions from the data hitting Twitter over the course of the disaster.

Next week, I’m going to be reading Language Support for Lightweight Transactions, which I’ll post a link to, if it’s in an Open Access journal. The paper serves as the basis of features like Haskell’s Software Transactional Memory.

John Clark, Spokane WA Defense Attorney Dead

John Clark, a defense attorney in Spokane, WA who was well known in the area as being a near tireless proponent for the rights of the accused in the legal maze, has finally laid down his head Friday at the age of 58, losing his two-year battle with cancer. John and his wife Ellen had been friends of the family for near 15 years, through my younger sister and their daughter, and I’d always known the man to be vibrant, excited, and honest. And reading the news stories, it’s clear that others view the man the same.

John was a brilliant attorney, who often took on amazingly difficult cases pro bono publico simply because he felt that it was the best thing to do. He won some, like the case of the 17 Spokane area teenagers arrested for protesting police brutality in 2007. He lost some, like the case of Ken Olsen, a Spokane Area man convicted of trying to make Ricin because he was found to be in possession of Castor oil, and happened to be going through a rough patch with his wife.

John even spoke at the sentencing of a man who held a knife to his throat to coerce a pharmacist into handing over painkillers, not to demand the book be thrown at the man, but to request leniency. John truly believed every single person is redeemable, and did everything in his power to ensure that they would get the chance at a fair trial. John is part of the reason that I find such interest in the law, and in the rights of individuals under the law. He was a firm believer that the role of law was to protect the rights of the individual, and the passion with which he spoke against new attempts to reduce individual liberty was inspiring.

Spokane’s legal community, and it’s accused, have suffered an enormous loss. And those of us who knew him, miss him greatly.

News Stories * KREM, Oct 8 * Spokesman Review, Oct 8 * Spokesman Review, Oct 9 * Spokesman Review, Oct 10

Beautiful Code

I recently finished Beautiful Code from O’Reilly Media. The Beautiful series of books each contain a series of chapters from experts in their fields, in this case, software developers from all over the industry. The contributors are given guidelines, of a sort. Some focus on programs, others focus on algorithms, still other focus on techniques.

There was, for me, at least some information to glean from each chapter, though there were some, like the Gaussian Elimination chapter, that felt less useful to me. However, by and large, the thirty three chapters are excellent reads. Now, I read through the book, one chapter after another, but there really isn’t any need to do that. You’re going to be just as well off opening the book to a chapter and reading through.

I had a few favorite chapters. Douglas Crockford’s chapter on Compiler design for a simplified JavaScript compiler revealed a design that was at once elegant and…well, beautiful, in the way that it simplifies the task of parsing an expression tree, while also adding some interesting features, like optional keywords which can allow you to add new keywords to the language, even if they’ve been used as variable names in existing programs without impacting the ability to compile those older programs.

Charles Petzold, best known as the guy who wrote the books on Win32 API Programming, has an excellent piece on dynamic code generation in .NET, and how spending a small amount of time up front to build a complex algorithm with some customizations for a specific run case (such as loop unrolling, dropping no-ops, etc) can save an enormous amount of processing time. The fact that he did it in .NET was pretty cool, since this is a technique that most people simply never consider anymore, but it’s something I’ve been thinking about lately for a project that I’m planning.

While those were my favorites, in part because they felt relevant to projects I’m considering, the rest of the chapters are pretty excellent. The discussion of concurrency using Haskell’s Software Transactional Memory is a fascinating approach to safe concurrency. It works exceptionally well in Haskell, due to the fact that the language makes side-effects so implicit that it’s easy to prevent STM and side-effects from getting nested irresponsibly.

Then there are several chapters on code quality and formatting, mostly focusing on trying to make code read more like natural language. Which makes a lot of sense for long-term maintainability, which was really run home by the chapter from a Perforce developer on their DiffMerge algorithm, and how strong code standards have helped it evolve over ten years or so. Or from Ruby’s Matz about keeping code succinct and ‘bookish’, which is greatly aided in his mind by using a language like Ruby, of course.

Beautiful Code is a heavy book, there were a few chapters where the code was very Fortran or LISP heavy, both languages I know well enough to read, but with the Fortran in particular, my eyes glazed over a bit. Even the chapters written in languages I’m intimately familiar with, and that I was interested in the subject, occasionally would go down paths that were far more interesting to the author of that chapter than to me, but that happens in Essay.

I can say one thing for sure: You’re not going to love this entire book. But you will find several chapters to love, and I doubt there will be many you can’t at least appreciate. I’m not entirely sure that I feel the book is worth it’s $50.00 cover price, but then, I’m a little cheap. I got it under their eBook deal of the day, and I know it was worth well more than the $10 I did spend on it. Overall, it’s a really good read, with some excellent essays, but I would definitely suggest treating this book like what it is, a compilation of disparate pieces, and not a cohesive whole.

Becoming a Better Developer: Reading Papers

1 Comment

If I think undergraduate education, across pretty much all fields but I’m going to focus on Computer Science, is really lacking, it’s that undergraduates don’t read research papers. I’m sure some programs are different, but Catherine didn’t read any until she was in her last year of her undergrad, and that might have been related to the course being offered as graduate credit more than anything. I’m sure I was never assigned any to read, though I did from time to time.

Computer Science is unique in this respect for two reasons: there is as much, if not more, research going on in corporate research groups as in academia; but also because so many of the journals in our field are open access, so we can get access to the materials without paying.

Periodically, I’ve made an effort to read a paper a week. I’m planning on returning to that, and I think I’ll post a summary of my thoughts each week, as I did last week. With that in mind, next week’s paper is going to be Twitter Under Crisis: Can we trust what we RT?, so if you want to read and discuss it, then I’ll be glad to engage in the discussion.

Tip The Web

1 Comment

This summer, I wrote about a little micro-payments system called Flattr, praising it for making donating money to websites both easily budgetable. At that time, I had two major issues. First, Flattr’s userbase was really small, as they were limiting it for early Beta. They’re still beta, but they’ve gone to open enrollment, and they seem to be doing much better for it.

Second, you don’t get to choose the amount donated. Assuming you stick to the €2 per month minimum, what you’re Flattr’d will receive either a lot of money, or virtually none, since the amount donated is simply the monthly amount divided by the number of Flattr’ings you’ve done. This means that you have little control over the value of each click. Now, I use Flattr for several participating podcasts, and it’s interesting, but this second point has been an absolute deal breaker for a lot of people I’ve shown Flattr to.

Almost immediately after I blogged about Flattr, I got a message from Eric Ferraiuolo, a person I’m lucky enough to work with through the YUI team, regarding a project that he’d been working on for quite some time, TipTheWeb. I was given access to the early staging, but now that the service is finally into Beta, I can talk about it.

TipTheWeb is a non-profit which is seeking to change the web fundamentally for the better. Like Flattr, TipTheWeb is a micro-payments system which allows you to pay content providers a small sum of money for the work that they’ve done. However, unlike Flattr, TipTheWeb tips URLs, not content. This means that content providers don’t need to register their content, or use something like the Flattr JavaScript API which can add content via a sort of hack, I’m still holding out for the Flattr REST API, as that should be able to simplify use of the JavaScript in a really good way.

But that problem simply doesn’t exist with TipTheWeb, content can be tipped easily based on it’s URL, and as a content provider, all I need to do is ‘claim’ the content via OAuth or other standard methods. Content Providers can even claim content after it’s been tipped, and TipTheWeb will be able to disburse the tip later.

From a usage standpoint, you either donate by going to TipTheWeb and entering the URL into their website, or they’ve got a bookmarklet that you can use to donate with two clicks without ever leaving the site that you want to tip.

Once you’ve made a few tips, you go to TipTheWeb where you can fund, or not fund, as many tips as you’ve made. Of course, to start, you’ll need to make a donation to TipTheWeb, which is currently done via PayPal. But here’s the best part of that, if you donate $5.00, you get the full $5.00 to tip with.

But, clearly the content provider needs to be on TipTheWeb to recieve tips. If they are not, then TipeTheWeb will, after 6 months, return the tip for use elsewhere. I don’t know if TipTheWeb will be making efforts (automated, of course) to inform content publishers of outstanding, unclaimed tips, but that is a very tricky problem.

For now, I think that TipTheWeb and Flattr serve slightly different purposes, and may be able to coexist, but I love that TipTheWeb doesn’t require me, as a content provider, to jump through any hoops to submit content. Currently, Invite Codes are required to get into the Beta, but I hope that the closed Beta will be fairly short.

Fixing Android Market When Stuck

Recently, I was having trouble with the Android Market after I’d upgraded to CyanogenMod 6 on my HTC Dream. Since the Dream has really limited internal space, the CyanogenMod folks removed Google Maps from the Google Apps package, since Maps can be installed from the Market. Right after I’d gotten my phone up and running, I’d set it to install a bunch of stuff from the market, including maps.

Now, Maps is a huge application by Android standards, but it has an enormous amount of functionality. And even though Froyo supports saving apps to an SD Card, I can’t seem to get it to install from Market to the SD Card, so I quickly filled up the internal storage and had several app installs fail, including Market. Now, several of these Apps are not ones I particularly cared about, but this weekend Catherine and I went on a day trip where I really needed the Maps.

However, Maps thought it was already downloading (it wasn’t), even after multiple reboots, and attempts to cancel the download within Market caused a force-close. However, it is possible to fix. Since my device was rooted, and had a terminal emulator I was able to do it on the phone in the car, but it would be fully possible to do it from the Android Debug Bridge with the phone plugged into a computer.

Once into the device via a terminal you’ll want to do the following:

  1. Make sure you have root access (should be automatic via adb, su otherwise)
  2. cd /data/data/com.android.vending/databases
  3. sqlite3 assets.db
  4. `DELETE FROM assets10 WHERE state = ‘DOWNLOADING’;

When you go back into Market, you should be able to tell the app to begin downloading again, and it should just work. Oh, and don’t do this when you do have a market download that is legitimately in progress, because I suspect something bad would happen.

Being Geek

Michael Lopp, or Rands as he is better known on line, at least by those who read his blog, released this year Being Geek, subtitled “The Software Developer’s Career Handbook” through O’Reilly Media.

The book brings together much of the content from Rands’ blog about working in technology as well as managing technology. I don’t know how this book may relate to his 2007 book “Managing Humans”, but I suspect there is a lot of overlap, but I may take the opportunity to investigate later.

Being Geek is many things. It provides information on how to ensure your career is growing. On how to identify when it’s time to ‘jump ship’ and move on from one company to another. It stresses, time and again, that you alone can drive your personal and professional growth. It gives solid advice on interviewing, and not only how to do well in an Interview, but how you can get the information that you need to determine if a job is appropriate for you as well.

The discussion about how to find the right job was the most interesting, as I’m fast approaching a time when circumstance will require me to move on from my current job, but more than that, it drove home the nagging feeling that I’ve been carrying, that I’m ready to move on.

The majority of the rest of the book talks about Management. Rands assumes that anyone reading the book has the mentality to be a domain expert, and to do well in a variety of jobs, but, in his words, we’re taught to “manage bits, not people.” A lot of Engineers struggle greatly when they make the transition to management because we usually just don’t know what to do.

At this point in my career, the management lessons are slightly less relevant, but even if you’re not making that jump (now or ever), they’re worth reading. Poor managers can sometimes be made better with a tiny bit of management from their people. And thinking, even a little bit, like a manager, can help you identify a good manager when you’re thinking about making a move.

In some ways, I wish that less of this book dealt with the issues of managing people. They’re important, surely, but I wonder if it would have been possible to put in more of the content from the first section, the one that was most relevant to me at this time. However, the content that was present, I believe will be invaluable.

This isn’t a job hunting book. It also isn’t really a management book. Yes, it contains a lot of data on both, and maybe it contains enough on both subjects. But the book is exactly what the subtitle says: It’s a book about managing your career.

My father has worked for the same company since 1980. My mother, has worked for maybe a half-dozen companies, and the latest she’s been with for over fifteen years. I’ve been out of school for five years now, and I’ve been with two companies, implying I’m well on my way to beating those numbers. And that’s become the norm for many people. Technology has very much become a field where if you’re not a growing, you’re shrinking, and you need to always be looking for something new and bigger, if not for the personal gratification of it, to make sure that if you ever need to go looking for a job, people will take notice.

Being Geek also has what I consider something of a ‘bonus’ chapter. “The Nerd Handbook” is a chapter meant not for you, but for your significant other. In fact, I would almost suggest that you not read it, because having someone nail your personality and habits so accurately is…a little depressing. And while this book is called “Being Geek”, understand that it’s very much about computer geeks, maybe just general engineering geeks too, but I’m not wholly sure. My wife is at least as big of a geek as I am, but her focus is on biology and phylogenetics. While there are overlaps in the behaviors described in this chapter, it definitely applies more strongly to me, and not her.

If I were faculty in Computer Science, I would probably build a list of required reading I’d hand every senior after they applied for graduation. Hell, I’m going to make that list anyway. This book would be at the top of that list. I would call it excellent reading for any technology geek at any stage of their career, but for geeks under 30, it should be mandatory.