Two Piece Set

Karo Socken

2009-08-07T17:22:00.000-07:00

Karo means square in German, or diamond as in the suit of cards. Socken, of course, means socks.
This pattern was inspired by a photo by montillon.

The pattern is also available for download as a PDF.

Materials

1 skein (~200 yards) solid-colored fingering weight sock yarn
1 skein (~200 yards) self-striping fingering weight sock yarn
Example photo uses Knit Picks Essential (now Stroll) (Black) and Knit Picks Felici (Martinique); 75% superwash merino wool, 25% nylon
US 0 (2.0 mm) needles — double-points, or circular for magic loop method
US 1.5 (2.5 mm) needles — double-points, or circular for magic loop method
Size E crochet hook
Waste yarn (~16")
Tapestry needle

Size & Gauge
Fits an average-sized woman’s foot (size 8)
30 sts = 4" in stockinette stitch

Abbreviations

cast on

knit

knit, wrapping the yarn around the needle 3 times before pulling it through

m1r

make 1 right (increase)

purl

slip as if to purl

st(s)

stitch(es)

solid-colored yarn

self-striping yarn

Instructions

On US 0 needles, using a provisional cast-on (such as the crochet cast-on), CO 32 sts with Y1. Knit a standard short row toe. You can find detailed instructions on short-row toes in this pattern.

If you want to make the sock wider or narrower, just make sure the total number of sts around is divisible by 5. The pattern as written uses 65 sts ((32 × 2) +1 increase), but you could CO 30 sts, 35 sts, 37 (+1 inc), etc.

When you're on the last row of the toe, carefully remove the provisional CO and place the resulting live sts on your needles so that you're ready to knit in the round. Knit until the last st in this round; end m1r, k1 (65 sts total). You're now ready to start the patterned part of the sock.

Round 1: Using US 1.5 needles, [ kw, k4. ] Repeat from [ to ].
Rounds 2 - 6: Using Y2, [ unwrap the 3 wraps from the previous row so that they form one very loose st. Sl, k4 ]. Repeat from [ to ].
Rounds 7 - 8: Using Y1, k around.

Repeat these eight rounds until sock measures 1.5" from heel, ending with Round 6.
On Round 7, do a standard short-row heel (using only Y1). You can find detailed instructions on short-row heels in this pattern; they're exactly the same as a short-row toe.

After the heel is complete, continue in pattern, starting with Round 8.
Repeat pattern until sock is 0.75" from desired height, ending with Round 8.
K one row around.

Cuff: [ K1, p1, k2, p1 ]. Repeat from [ to ].
Repeat this round 6 more times.
Bind off; I used Elizabeth Zimmerman's sewn bind-off. Weave in ends.

This is my first attempt at writing a pattern, so please leave a comment or message me on Ravelry if you have any questions or comments!

Karo Socken by Susan Moskwa is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.
Based on a work at www.flickr.com.

S3 Performance Benchmarks

2009-06-06T17:46:00.000-07:00

Over the last couple of weeks we've been working with S3 to read data to power real-time user query processing. So we've made a lot of optimizations and measurements of the kinds of performance you can expect from S3.

S3 Throughput: 20-40MB/sec (per client IP): 20 MB/sec is the neighborhood for many small objects, with as much as 40 MB/sec for larger objects. We're pushing a lot of parallel transfers and range queries on the same objects. Each request is only pushing about 200 KB/sec. I don't think I've ever seen a single connection push more than 5 or 6 MB/sec. I'm assuming this is partly S3 traffic shaping. So this should scales well if you've lots of clients.
S3 Response Time: 180 ms: We're pulling from EC2 (just across the hall from S3?) We've seen response time range between 8ms (just like a disk!) and as long as 7 or 8 seconds. But under 200ms is quite reasonable to expect on average. We're pushing a lot of parallel requests (thousands per second across our cluster, with hundreds on individual machines).
Parallel Connections to S3: 20-30 or 120: 20-30 roughly maximizes throughput, 120 roughly maximizes response time. S3 seems to do some kind of traffic shaping, so you want to transfer data in parallel. If you're hosting web assets (e.g. images) at S3 this is less of an issue since your clients are widely distributed and will hit different data centers. But if you're serving complex client data requests pulling data from S3 at just a few servers, you might be able to structure your app to download data in parallel. Do it with 20-30 parallel requests. More than that and you start getting diminishing returns. We happen to run more than that (perhaps as many as 100 per process, with as many as 1000 per machine) because we're focusing on response time, rather than throughput.
S3 Retries: 1: We do see plenty of 500 or 503 errors from S3. If you haven't, just wait. We build retry logic into all our applications and typically see success with even just one or two retries with very short waits. I should recommend exponential back-off (that's what the Amazon techs say in the forums). So if you're making more than one or two retries, start waiting a second, then two, then four, and so on. I'd bail and send yourself an email if you don't get a 200 OK after four or five retries and a minute of waiting. But maybe retry the first one right away, it'll work 9.9 times out of ten :)

If you're getting different results, do let me know :)

Advertising fail

2009-03-25T09:46:00.000-07:00

Not quite ironic enough for FailBlog, but still funny. Now if only the same ad appeared for [hanky-panky]...

Looking for a good home: Sammy

2009-03-17T17:41:00.000-07:00

This is Sammy. He's a foster cat from the Humane Society who's currently living with us to get a break from the shelter. He's totally adorable so I'm looking for a good home for him!

Sammy's been with us for nearly 2 weeks and he's been super low-maintenance. He's very friendly; he'll immediately walk up to new people rather than hiding or shying away. He has long whiskers and soft, silky fur which only gets silkier the more you pet him. He loves to be petted, especially on his face and belly, and he'll purr pretty much as soon as you touch him.

He seems to really like being around people, and is very amenable to whatever ways you want to give him attention. He doesn't mind sitting on your lap, being picked up, cuddled, used as a pillow, etc. He's also very happy to just sit in the same room as you while you're doing whatever; we've spent many hours sewing, knitting, and surfing the web together. He doesn't get freaked out by noises (like the sewing machine, or even the vacuum cleaner). I think he would make a great match for anyone looking for a lap cat, or a companion to just hang out with while watching movies and putzing around the house.

Incidentally, he doesn't do any of the bad stuff that my cats do, like chewing on cords or tipping over wastebaskets and playing in the trash. And he doesn't scratch the furniture (although he does like to knead his claws into the carpet when he's really happy).

If you or anyone you know is looking for a cat like this, please let me know (or contact the Humane Society directly)! You're also welcome to come over and meet him. More photos here.

Performance Measurement for Small and Large Scale Deployments

2009-03-15T23:59:00.000-07:00

As well as powering a few cool tools, Linkscape is a data platform. Performance (and its measurement) isn't just important to reduce user latency, or cut costs. It's actually something we're hoping is part of our core competency, something that adds significant value to our startup. And the shortest path to performance is measurement.

For those in a hurry, jump straight to the tools we're using.

This post is inspired by (and at times borrowed from) an email I sent to some friends for a consulting gig I did recently. But it rings so true, and I come back to it so often, that I thought I would share it. Alex and Nick, I hope you don't mind me sharing some of the work we've done on your very neat, very fun Facebook game.

Let me motivate the need for performance monitoring with a couple of case studies taken from our infrastructure:

This dashboard (above) illustrates 28 hours of load on our API cluster. I can immediately see service issues on the first server (the red segment of the first graph). This is correlated with a spike in CPU and some strange request patterns on the second server (the layered, multi-colored bar on the graph below). The degraded service lasted for a few hours, which was a configuration issue I solved in our monitoring framework. It should have guaranteed downtimes of no more than 4 minutes.

Even after solving our monitoring issue I still needed to investigate the underlying issue: I can see the CPU and request pattern are related. Ultimately I solved this issue within two weeks. Without this kind of measurement I would not even have known we had an issue, and would not have had the data to solve it.

From part of our back-end batch-mode processing, we had thought we'd tuned our system about as well as we could. At times we were pulling data through at a very respectable pace, roughly 10MB/sec per node. but we had also observed occasional unresponsiveness on nodes, with a corresponding slowness in processing. We left the system alone for a while, thinking, "don't fix it if it ain't broke". But recently we've been tuning performance for cost reasons; so we came back to this system.

Once we instrumented our machines with performance monitoring (illustrated above) we saw that the anecdotes were actually part of a worrying trend: the red circles show this. Our periods of 10MB/sec throughput are punctuated by periods of extremely high load. The graphs above show load averages of 10 or more on 4 core nodes, along with one process spiking up to hundreds of megabytes and nearly exhausting system memory. This high system load dramatically reduced our processing throughput.

It turned out that the load was caused by a single rogue program which consumed all available system memory due to buffered I/O. Usually we have a few I/O pipelines and give each many megabytes for buffering. However, this program has many dozens of pipelines, altogether consuming nearly a gigabyte of memory. This lead to significant paging and finally thrashing on disk.

Once we reduced the size of buffers (from roughly 40-100MB per pipeline to just 1-2MB per pipeline) we saw dramatic improvements in performance: a nearly 60% boost! And the nodes have become dramatically more responsive—no more load averages of 10+. The graphs above show load average maxing out at 4 and plenty of memory available. The data suggest that we might even be able to nearly double our performance with the same hardware by increasing parallelism and running another pipeline on each node.

All of this work is powered by simple monitoring and measurement techniques. Sometimes this has lead to significant, but necessary engineering work. But sometimes it's lead to a single afternoon's efforts yielding a 60% performance boost, with an opportunity to nearly double performance on top of that.

We're using a few tools:

collectd measures the system health dimensions (cpu, mem usage, disk usage, etc.) and sends those measurements to a central server for logging.
RRDTool records and visualizes the data in an industry standard way.
drraw gives me a very simple web interface to view and manage my visualizations.
Monit watches processes and system resources, bringing things back up if they crash and sending emails if things go wrong.

These tools work together, in an open, plug-in powered way. I could swap out individual components and move to other tools, such as Nagios (which I've used for other projects) or Cacti (which I have not used).

Whether you're an on-the-ground operations engineer looking to watch system health and fix issues before they turn into downtime, or you're managing large-scale engineering, looking to cut costs and squeeze out more page or API hits, these tools and techniques point you in the right direction and give you hard data to justify your efforts after the fact. We've had many high ROI efforts initiated and justified by this kind of measurement.

Why is this Report So Slow: Let the Database Handle the Data

2009-03-08T23:59:00.000-07:00

We have a data-rich report in our Linkscape tool with even more in our Advanced Report. We think the data is great. But the advanced report can be awfully slow to load. Don't get me wrong, we think it's worth the wait. But this kind of latency is a challenge for many products, and clearly, there's room for improvement. We're finding improvements by porting logic from the front-end into the data layer, and by paging through data in small chunks.

We present our data (links) in two forms. One is an aggregated view, showing the frequency of anchor text, one attribute of each link:

We also present a paged list of links, showing all the attributes we've got:

The time we spend on each request is very roughly illustrated by this diagram. From it you can see each component in our system: disk access, data processing, and a front-end scripting environment. I've included the aggregate time the user experiences as well. We have a custom data management system rather than using a SQL RDBMS such as MySQL. But I list it as SQL because SQL presents the same challenge.

In total the user can experience between 15 seconds to three minutes of latency! The slowness comes from a couple of design flaws. The first is that we're doing a lot of data processing outside our data processing system. Saying that programming environment doesn't matter is a growing trend, which has some advantages; rapid development comes to mind. But (and I'm a back-end data guy, so I'm a bit biased) it's important to let each part of your system do the work it's best at. For presentation and rapid prototyping that means your scripting environment. But for data that means data processing.

We're currently working on moving data processing into our data layer, resulting in performance something like that illustrated in the diagram below. The orange bars represent time spent in this new solution; the original blue bars are included for comparison.

In addition to latency improvements, pulling this logic out of our front-end adds that data to our platform and consequently makes it re-usable by many users and by applications. The maintenance of this feature will then lie in the hands of our data processing team, rather than our front-end developers. And we've taken substantial load off of our front-end servers, in exchange for a smaller amount of extra load on our data-processing layer. For us this is a win across the board.

The other problem we've got is that we're pulling up to 3000 records for every report, even though the user has a paged interface. And those 3000 records are generated from a join which is distributed across our data management platform, involving many machines, and potentially several megabytes of final data pulled from many gigabytes of source data.

The other big improvement we want to introduce is to implement paging at the data-access level. Since our users already get the data in a paged interface, this will have no negative effect on usability. And it'll make things substantially faster, as illustrated (again very roughly) below. The yellow bars illustrate the new solution's projected performance. Orange and blue bars are included for comparison.

The key challenge here is to build appropriate indexes for fast, paged, in-order retrieval of the data by many attributes. Without such indexes we would still have to pull all the data and sort it at run-time, which defeats the purpose.

In the solution we're currently working on we've addressed two issues. First, we've been processing data in the least appropriate segment of our system. Process data in your data management layer if possible. Second, we've been pulling much more data than we need to show to a user. Only pull as much data as you need to present to users; show small pages if you can. The challenges have been to port this logic from a rapid prototyping language like Ruby into a higher-performance language like C or stored procedures, and to build appropriate indexes for fast retrieval. But the advantages of this work are substantial, and are clearly worth it.

These issues are part of many systems out there and result in both end-user latency problems, as well as overall system scalability problems. Fixing those problems results in higher user satisfaction (and hopfully higher revenue), and reduces overall system costs.

By the way, we haven't released anything around these improvements in performance yet. If you want to keep up to date on Linkscape improvements watch the SEOmoz Blog or follow me on Twitter @gerner.

High Performance Computing at Amazon: A Cost Study

2009-03-04T09:55:00.000-08:00

In building Linkscape we've had a lot of high performance computing optimization challenges. We've used Amazon Web Services (AWS) extensively and I can heartily recommend it for the functionality at which it excels. One area of optimization I often see neglected in these kinds of essays on HPC is cost optimization. What are the techniques you, as a technology leader, need to master to succeed on this playing field? Below I describe some of our experience with this aspect of optimization.

Of course, we've had to optimize the traditional performance front too. Our data set is many terabytes; we use plenty of traditional and proprietary compression techniques. Every day we turn over many hundreds of gigabytes of data, pushed across the network, pushed to disk, pushed into memory, and pushed back out again. In order to grab hundreds of terabytes of web data, we have to pull in hundreds of megabytes per second. Every user request to the Linkscape index hits several servers, and pages through tens or hundreds megabytes of data in well under a second for most requests. This is a quality, search-scale data source.

Our development began, as all things of this scale should, with several prototypes, the most serious of which started with the following alternative cost projections. You can imagine the scale of these pies makes these deicions very important.

These charts paint a fairly straight forward picture: the biggest slice up there, on the colocation chart, is "savings". We spent a lot of energy to produce these charts, and it was time well spent. We built at least two early prototypes using AWS. So at this point we had a fairly good idea, at a high-level of what our architecture would be, especially the key costs of our system. Unfortunately, after gathering quotes from colocation providers, it became clear that AWS, in aggregate, could not compete on a pure cost basis for the total system.

However, what these charts fail to capture is the overall cost of development and maintenance, and many "soft" features. The reason AWS was so helpful during our prototype process has turned out to be the same reason we continue to use it. AWS' flexibility of elastic computing, elastic storage, and a variety of other features are aimed (in my opinion) at making the development process as smooth as possible. And the cost-benefit of these features goes beyond the (many) dollars we send them every month.

When we update our index we bring up a new request processing cluster, install our data, and roll it into production seamlessly. When the roll-over is complete (which takes a couple of days), we terminate the old cluster, only paying for the extra computing for a day or so. We handle redundancy and scaling out the same way. Developing new features on such a large data set can be a challenge, but bringing up a development cluster of many machines becomes almost trivial on the development end, much to the chagrin of our COO and CFO.

These things are difficult to quantify. But these are critical features which make our project feasible at any scale. And they're the same features the most respected leaders in HPC are using.

All of this analysis forced us to develop a hybrid solution. Using this solution, we have been able to leverage the strength of co-location for some of our most expensive system components (network bandwidth and crawling), along with the strengths of utility computing with AWS. We've captured virtually all of the potential savings (illustrated below), while retaining most of our computing (and system value) at AWS.

I would encourage any tech leaders out there to consider their system set-up carefully. What are your large cost compentents? Which of them require the kind of flexibility of EC2 or EBS? Which ones need the added reliability of something like S3 with it's 4x redundancy? (which we can't find for less anywhere else). And which pieces need less of these things? Which you can install in a colocation facility, for less?

As an aside, in my opinion AWS is the only utility computing solution worth investigating for this kind of HPC. Their primitives (EC2, S3, EBS, etc.) are exactly what we need for development and for cost projections. Recently we had a spate of EC2 instance issues, and I was personally in touch with four Amazon reps to address my issue.

Hhffrrrggh: WTF?

2008-11-01T21:48:00.000-07:00

Once upon a time, while driving up to Madison from Chicago, I noticed a sign alongside the highway. It was one of those signs that precedes an exit and shows all the different restaurants that you'll find off that exit. I sped past at 80mph, barely glancing at the sign, and immediately thought Did I just see... ??. One of the restaurant adverts was pink with white text, so it was kind of hard to read, but I could've sworn it said something completely unintelligible. It was a weird bit of surreality in an otherwise uneventful drive, and I soon forgot about it.

But I drive that highway several times a year, and (when I remember) I started looking for that sign each time I drove past, trying to figure out whether I was crazy or whether it actually was complete gibberish. And today I'm pleased to report that I've found the culprit, and that I am not, in fact, crazy (or at least not hallucinating):

Welcome to the Hhffrrrggh Inn - Janesville's hmost hfun place to eat and drink. Can't say it, can't spell it, can't forget it.

So... did they just let their cat walk on the keyboard and name the restaurant after the results?

Knitting breakthroughs

2008-10-25T00:13:00.000-07:00

Ahh, the joys of being self-taught.

This week while poring over diagrams of a new knitting stitch I'm trying to learn, I realized that for the five years I've been knitting, I've been doing the most basic stitch—"the knit"—wrong.

Sigh. At least I figured it out before making a mess of my latest project. This is the first time I've tried anything that wasn't just a basic stockinette or seed stitch, so it never really mattered before.

Incidentally—although I don't think this had anything to do with my learning the stitch wrong—I taught myself to knit while I was in Paris, so my book is all in French. This means I don't really know any knitting vocabulary in English. For those interested, here's my new stitch:

The yarn is Plymouth baby alpaca grande paint, #8819. It's a bit expensive but is gorgeously soft (and the color is much better than this photo makes it out to be). Here's the stitch ("Grille ondulée"):

Cast on a number of stitches evenly divisible by 12.
1er rang: *4 mailles croisées à droite (glisser 2 m. en attente derrière le travail, tricoter les 2 m. suivantes à l'endroit, puis les 2 m. en attente), 4 m. endroit, 4 m. croisées à gauche (glisser 2 m. en attente devant le travail, tricoter les 2 m. suiv. à l'endroit puis les 2 m. en attente)*, répéter de * à *
2e et tous les rangs pairs suivants: à l'envers
3e et 7e rangs: à l'endroit
5e rang: *2 m. end., 4 m. croisées à gauche, 4 m. croisées à droite, 2 m. end.*, répéter de * à *
Répéter toujours ces 8 rangs.

Mimes as traffic cops

2008-10-24T13:31:00.000-07:00

I know it's a blogging no-no to just republish stuff if you don't have original commentary to add, but I was so floored by learning about this yesterday that I just have to share it with you:

[Antanas Mockus, the former mayor of Bogotá, used] mimes to improve both traffic and citizens' behavior. Initially 20 professional mimes shadowed pedestrians who didn't follow crossing rules: A pedestrian running across the road would be tracked by a mime who mocked his every move. Mimes also poked fun at reckless drivers. The program was so popular that another 400 people were trained as mimes.

NPR story—which is even more compelling than the above article—here, starting at 34:00.

Lessons Learned while Indexing the Web

2008-10-16T16:55:00.000-07:00

If you know what I've been working on for the last nine months, you might (correctly) suspect that I've learned a few lessons about developing large-scale (highly scale-able) and complex software. Let me share some thoughts I've got about the subject.

But before I begin, I should point out some aspects that make this a special project. I can't speak for the UI, and while everyone on the engineering team worked on the project in the final months, the development team—especially in the early stages—was small. Ben Hendrickson and I headed up architecture and the software efforts. We were the "core" team for the back-end efforts. So this made some things a lot easier. I'll comment more about this later.

Be Bullish (but Realistic) in the Planning Stages

One thing that helped us tremendously was to be broad and optimistic in the early stages. Doing this gave us a large menu of features and directions for development to choose from as plans firmed up and difficulties arose. I know the adage, "Under-promise, over-deliver." And there's a place for that mentality. When we did start to firm up plans, clearly we were not going to promise everything. But we tried to keep things as fluid as possible for as long as possible. This worked out for almost all of our features, and by the time we were half-way through with our project we had the final feature set nailed down, and prototyped out.

There was one substantial feature that we had to cut just a few weeks before launch. Perhaps we were too bullish, but I believe that this kind of thing is fairly normal for large software projects. I'm looking forward to working on that for the next release. ;)

Have Many Milestones and Early Prototypes

I wish we had had more milestones and stuck to them. The last couple of months were hellish with literally 14-16 hour days, 7 days a week. With my commute, there were many days that I arrived home, got into bed, woke up, and rolled back onto the bus to start it all over again. Despite reading about "hard-core" entrepreneurs who have this as a "lifestyle", I would not recommend it for a successful software engineering team.

We hit our earliest milestones and even had an early version about four months before launch. But the two milestones between that prototype and launch both slipped and no one stepped in to repair the schedule. So the rest of the team (including Ben and me, plus another six software engineers) had to take up the slack at the last minute. Missing these milestones should have told us something about the remainder of the schedule. Frankly, I think we were lucky to launch when we did (good job team!).

Low Communication Overhead = Success

We were lucky to have a small team. For the back-end it was basically just Ben and me. And we do all of the data management and most of the processing in the back-end. So it was easy for Ben and me to stay in sync. Add to that the fact that we work well together and we were able to achieve in a small team, what normally requires a much larger team.

While I've worked in much larger organizations, I've never had the leadership role in those organizations that I do now. So I can't say how much of this advice applies to larger organizations. I guess my feeling is the same that many people have: keep related logic together in small teams, have clear interfaces to other units. This worked well when we integrated with our middle-ware and front-end.

KISS

Anna Patterson describes a simple roadmap for building search engine technology. I'm not saying we followed this plan, but I can say that our (I hope successful) plan is equally simple. Identify the work you need to do. Come up with reasonable solutions. Plan and implement them. Don't get bogged down in hype or fancy technology.

There's certainly more to success than these points. These are just what come to mind when I think about the success of this project. In any case, good luck on your own projects!

What's a little impending doom among friends?

2008-10-01T21:54:00.000-07:00

As you hopefully know, CERN's Large Hadron Collider—one of the most elaborate physics experiments ever built—is finally finished and was first turned on several weeks ago. Leaving aside the fact that it broke down a few days later (!), I've been truly surprised by how many people are worried that it's going to create some sort of time-space anomaly that could destroy the world. The subject came up recently over lunch and (to my surprise) the majority of my PFM sisters were freaked out about our planet's impending Swiss-wrought doom.

And they're clearly not the only ones, since the BBC broadcast an interview the day before the collider was turned on in which they asked a scientist about the possibility of black holes being created during the experiments. His response was to laugh knowingly and say not to worry; even if the experiments do create (tiny) black holes, "there's no chance of them devouring the world. Ha, ha, ha!"

I couldn't find the exact interview, but here's a very similar one. Unfortunately it doesn't quite recreate the awkwardness of that scientist's particular response. I think the definition of 'egghead' somehow fundamentally involves the idea of believing so deeply in science that you'll laugh at another person's fear of death as if they were confusing a Stephen King novel for reality. "Black holes? Ha! Next thing I know, you'll be worried about langoliers!"

TSA Permitted & Prohibited Items

2008-09-29T13:11:00.000-07:00

I'm flying to WI later this week (roller derby Eastern Regionals, baby!), and—having recently started a new knitting project—was wondering what happens when you try to bring knitting needles through airport security. Even though you could do much more damage with a ballpoint pen than with a blunt knitting needle, I would hate to underestimate TSA's overzealousness in "protecting public safety" in a post-9/11 world.

So I found this useful list of what's allowed and prohibited on airplanes. It even breaks things out into what's allowed in carry-ons vs. what's allowed in checked luggage. According to the list, knitting needles and crochet hooks are allowed on the plane; however, this follow-up article isn't exactly confidence-inspiring ("In case a Security Officer does not allow your knitting tools through security it is recommended that you carry a self addressed envelope so that you can mail your tools back to yourself as opposed to surrendering them at the security checkpoint").

I was surprised to learn that disposable razors and scissors < 4" long are allowed in carry-on luggage. Happily, the list confirms that throwing stars, cattle prods, hand grenades and tear gas are not.

I feel safer already.

[Edit: Maybe I just need one of these. "Nothing to see here, folks!" (Hat tip to Nish.)]

Read a banned book

2008-09-27T08:52:00.000-07:00

Today is the first day of Banned Books Week 2008. From their website:

Banned Books Week is the only national celebration of the freedom to read. It was launched in 1982 in response to a sudden surge in the number of challenges to books in schools, bookstores and libraries. More than a thousand books have been challenged since 1982. The challenges have occurred in every state and in hundreds of communities.

To my surprise, I discovered that a book I just started reading today (The Perks of Being a Wallflower, which I learned of through NPR) was one of the top 10 most challenged books in 2007. So I'll be celebrating Banned Books Week by curling up on the couch to finish it.

If you too value the freedom to access the literature of your choice—literature that may educate, entertain, shock, or open your mind—then check out this list of most frequently challenged books, visit your local library, and go exercise your First Amendment rights.

Ladies!

2008-09-26T20:38:00.001-07:00

Thanks to beatnikside, I just stumbled across a delightful video which combines two very delightful things: roller skating and Flight of the Conchords! If you're unacquainted with either one, I highly recommend both. :-)

You could face certain death. Maybe.

2008-09-12T11:55:00.000-07:00

Today the news keeps mentioning how Hurricane Ike is bearing down on the Texas coast. Their repeated quote is that

The National Weather Service warned residents of smaller structures on Galveston they could "face certain death" if they ignored an order to evacuate.

Why is everyone saying "could face certain death"? Shouldn't it be "will face certain death"? If you could face it (but maybe not), then it's not really certain, is it. And if they really do think it's certain death, they should probably be using more unambiguous language.

Robert Fulghum knows everything there is to know

2008-09-10T09:02:00.000-07:00

Last fall our local NPR station (KUOW) did an interview with Robert Fulghum, the author of All I Really Need to Know I Learned in Kindergarten. It sounds like he has a pretty sweet life these days—hanging out, writing books about being a good person and getting back to the basics of life. Being a nice guy. Talking on public radio.

One of the things that struck me was his comment about bloggers. He said that the web's full of bloggers these days and they're all trying to be gurus: specialized in one topic, authoritative, informative. In contrast, on his blog (he says) he just writes as if he were writing to a friend. Topic: whatever's on his mind. Tone: relaxed. No need for research or references. Just engaging in a bit of friendly conversation with no one in particular. It's like that crazy guy at your coffee shop who talks vaguely to anyone within a few meters of him, only when you do it in writing it doesn't make you look like a such a weirdo. :)

He said he tries not to "get into the guru racket" because all the good advice in the world has already been known for ages, so who needs a bunch of self-proclaimed gurus popping up all over the internet trying to say something new. He actually said, "...The good stuff has been there, we don't need any new stuff."

Now, I can see how that goes along with his whole philosophy of simplification. It's summed up in the idea that "all I really need to know I learned in kindergarten," right? He believes that there are some fundamental ideas that are easy to learn, and everything else is just a more complex version of those fundamental ideas. But I can't really get behind this idea that everything has already been said and that there's nothing left to be an expert in. I mean, honestly? What's the point of perpetuating the human race if everything has already been said and done and figured out?

Perhaps my perspective as a technologist colors my view on this; but it seems to me that there are tons of new things being thought up all the time, and that we do still have a need for experts in new fields—people who can speak compellingly and authoritatively. That's not to say that I think every random blogger is compelling and authoritative (far from it!); but I think it's overly simplistic to say that we don't need new thought leaders.

What do you think?

The relevant part of the interview starts around 14 min. into the audio file, if you're interested in listening.

Google Tech Talk: Hacking English

2008-09-08T08:46:00.000-07:00

Since my last post on a Google tech talk was such a hit (well, as much as anything on a blog that averages 10 visits/day can be considered "a hit"), I've been meaning to blog about another great talk I attended. It was called "Wordmaking: What it takes to succeed in hacking English and invent a new word," and was much more light-hearted than the talk on plurilingualism. Here's the abstract:

Learn the basics of word formation in English, get "raw materials" for new words, and invent your own word (and have it critiqued) before you let it loose into the English language. The maker of the "best new word" (as voted on by the participants) will win a new dictionary.

The speaker was Erin McKean, a dictionary evangelist, lexicographer and editor of dictionaries. She's a very entertaining speaker, and even has a Murphy's Law-style law named after her:

McKean's Law: Any correction of the speech or writing of others will contain at least one grammatical, spelling, or typographical error.

The talk was about the productivity of English (the degree to which it lends itself to making up new words that other English-speakers can understand), and the building blocks that make that possible. English has inherited a lot of words and grammar from various language families (principally Germanic and Latinate), so English speakers have a lot of morphemes (the building blocks of words) to play around with—prefixes, suffixes, different roots that mean the same thing.

I think my favorite part of the talk was the obvious glee that Erin took in playing with language, and all the new words I learned (both "real" and made-up) from her talk. Here are my favorites, which I encourage you to incorporate into your daily speech:

catachresis (n.): A linguistic error that comes to be accepted as "correct," usually because it's so common.
Examples: apron used to be napron, but people heard "a napron" and started interpreting it as "an apron." Strait-laced is more commonly misspelled as straight-laced than correctly spelled; so who's to say how long the "incorrect" version remains incorrect, if a majority of people are using it?
epicene (adj.): Gender-neutral.
Example: English-speakers have been trying to invent an epicene singular pronoun for years, but none have ever really stuck so we usually end up saying "they" even for singular referents.
nonce (adj.): A nonce word is a particularly time- or place-specific word (which is thus unlikely to catch on as a word that survives the test of time).
Examples: Excaliburger, comcastic.
pregret (n.): The knowledge that you're about to do something you will later regret having done.
See also: prevenge.

The word that I'd like to get traction for is kez, meaning "fake cheese, or any plastic-like substance trying to pass itself off as cheese." Which brings me to this great website I heard of recently via Says You, a public radio show that every linguaphile should check out: Addictionary.org, where you can make up words, vote on other people's submissions, or submit definitions in search of words. Go to Addictionary and vote for my word.

Have you coined any words?

The Homeland Generation

2008-09-06T17:21:00.000-07:00

I was recently filling out a survey and was asked to give my age in terms of what generation I'm part of. These were the options provided:

Birth Year

2001-Present, Homeland Generation

1982-2000, Millennial Generation

1961-1981, Generation X

1943-1960, Baby Boom Generation

1925-1942, Silent Generation

1901-1924, Depression/GI Generation

Homeland Generation?? Have you ever heard that before? That sounds so depressing to me. I mean, who wants to be part of the generation that grew up in a world in which you have to meet your friends at the baggage claim because you're not allowed to meet them at the gate? In a world in which the US is progressively more isolated and our constitution is being progressively eroded? I guess it is interesting to realize that there are now kids who've only known this type of world, though—it still surprises me that the Sept. 11 attacks were 7 years ago now. It's surprising that things have been going downhill for that long.

Hopefully we'll be able to turn things around so that by the time the Homeland Generation is old enough to be politically aware, we'll once again have a government that they can be proud of.

What happens at a caucus?

2008-09-06T15:00:00.000-07:00

I'm cleaning out some old drafts I never got around to publishing, and thought this one was kind of interesting given that both parties have held their conventions in the last 2 weeks.

* * *

In February Washington state held its first round of Democratic and Republican caucuses for the 2008 presidential election. Having learned that the Democratic primary doesn't actually count for squat in selecting delegates, I decided to attend my first caucus ever in order to make my vote count for something. I'd heard that a caucus was an in-person event that fostered political discussion at a local level, where you could attempt to argue and cajole other voters over to your side; but beyond that I had a fuzzy idea at best of what to expect. Having now been through it, I can give you the down-low:

We showed up early. The caucus was officially scheduled to start at 1:00, but I had a suspicion it was going to be crazy, which turned out to be well-founded. Our caucus was held in the local school district office building, and the hallways were already crowded when we got there. We were just barely in time to fill the last bits of standing room in the back of a room fire-coded to hold 110 people... there must have been at least 350 in it.

As we entered we signed in with our precinct. There were ~10 different precincts at our caucus. Along with the usual (name, address, phone), the sign-in sheet had a blank for "Initial candidate preference" and "Final candidate preference." You have to fill in your preference at the start of the caucus in order for your vote to count; you can put "undecided" if you're not sure, but leaving the field blank means your presence at the caucus won't count. At the end of the caucus everyone filled in the "Final candidate preference" blank so that there was a paper trail of how many people changed their opinion during the course of the caucus.

The Pledge of Allegiance was said and several Required Documents were read (scripts for calling the caucus to order, explaining the process, etc.). There was general milling around, apologizing for the overcrowding, long periods of waiting and seeming disorganization (announcements had to be made twice, once in the main room and once for the overflow in the hallway), and widespread restlessness. Organizers announced that they were just volunteers and that they were doing the best they could. I think a lot of organizers were doing this for the first time.

Around 1:45 we broke out into precincts. Most precincts caucused in the parking lot or on the lawn due to the overcrowding. Our precinct was the largest at this caucus; 89 people showed up. We had 9 delegates to assign based on our precinct's size.

A frazzled-looking volunteer from our precinct filled out the delegate allotment paperwork while the rest of us sat around wondering what would happen next. I think the majority of voters had never attended a caucus before. There were a couple experienced folks there who explained to us what the process would be like, but mostly we sat around being 80% confused and 20% slowly figuring out what was going on. This would turn out to be a theme throughout the caucus.

The delegate allotment paperwork consists of a chart that helps you do the math to figure out how many supporters are needed to get how many delegates for each candidate. If my memory serves me correctly, it has the following columns:

initial number of supporters
total number of caucusers present
each candidate's percentage of total supporters
percentage × number of precinct delegates
number of delegates allotted to this candidate (after rounding)
final number of supporters
total number of caucusers present
candidate's final percentage of total supporters
percentage × number of precinct delegates
final number of delegates allotted to this candidate (after rounding)

The 5th and 10th columns get rounded down, which is part of where the discussing and cajoling is supposed to come in: say your precinct had 6 delegates to allot, and the values of the 4th column were 1.35, 2.35, 2.3. They'd all get rounded down to 1, 2, 2, and your precinct would only allot 5 delegates and would "lose" the 6th. So you want to try to get people to switch groups in order not to split those last fractions of a delegate.

At some point we broke into groups based on who our initial candidate preference was. I don't think the paperwork was done yet, we just got tired of waiting and figured we should get the show on the road. We needed to pick which members of our group would be the delegates that we sent on to the next round (if you ever wondered who the delegates are or how they get chosen, it's here at the caucus, by random folks like you and me). At first people were getting up and making impassioned speeches about why they believed Barack Obama was the best candidate for the presidency, but then someone said "Y'know, you're kind of preaching to the choir, since this is the Obama group," and Nick pointed out that we had 10 delegates to pick (5 primary and 5 alternates) and there were < 10 people standing, so instead of making speeches and fighting for the positions, maybe we should just see if we could get 10 warm bodies standing and then take it from there.

Turns out there were only 5 people who actively wanted to be delegates, and we were able to get 5 more to agree to be alternates, so that wasn't too hard (it just needed some organization). At that point we decided to send our delegates over the to the "undecided" group to answer their questions and try to cajole them over to Obama's side. But, although everyone was in agreement over who the delegates should be, our precinct chair said that the rules required a paper ballot to decide the delegates, so the rest of us sat around trying to decide the easiest way to do this and tearing up a legal pad into little pieces of paper. You'd think that if a paper ballot was part of the rules, someone would've brought ballot-sized pieces of paper to vote on... are you starting to see a theme of disorganization here?

After awhile the Hillary group sent cajolers over to the undecided group too, and it was kind of painful to listen to everyone arguing for their candidate. Clearly everyone believed in their candidate so strongly and felt this burning certainty in their stomach that it was critically important for the future of America that the other candidate not be selected. It's hard to watch when people fervently believe contradictory things and someone is eventually going to lose. Things went around for awhile (with both sides saying "But—wait, can you please let me speak? The reason that—excuse me, the reason—would you please let me speak??") and then the paperwork lady announced that she was done with the first five columns and we should wrap this up (it was probably nearing 2:30 by then).

Slowly the undecided group broke up and either joined the Barack or the Hillary groups. I talked later with a lady who'd been undecided, and she said that if they'd kept their undecided delegate it basically meant none of them had any control over who that person would vote for, so rather than making their vote essentially a wild card, most of them decided to pick one candidate or the other (even if they weren't 100% certain). Everyone reported their final candidate choice to the paperwork lady, who started working on the next five columns of the spreadsheet.

At this point most people thought their work was done, especially since there wasn't much left to do besides wait for the paperwork to be filled out. People started to trickle out of the room. The paperwork lady made some math errors even though she was using a calculator. I pointed out to her that her percentages added up to > 100% and she had to start over. When she'd finally tallied the delegates (and I have no idea why this all took soooo long), the Barack group had won an extra delegate (thanks to the undecideds who'd come over), so we had to scrounge around for another delegate and another alternate, and then alter the paper ballots to indicate that we'd appropriately voted for the 6th delegate. More and more people were leaving the room, so it was kind of funny that at the beginning of the delegate-choosing process people were grilling the delegates with all sorts of questions about whether they'd be a good delegate or not, but by the end I could just raise my hand and say, "I'll do it," and people were like "Okay, great; fill out this form."

So basically it was a big free-for-all, and there was far less "fostering of political discussion" than I had anticipated. Although I guess that's to be expected; since it's easier to vote than to caucus, a lot of the people who show up are probably there because they care so much about a particular candidate that they want to make sure their vote counts in the selection process. Meaning they're too passionate for anyone to change their mind. But it was certainly an interesting experience; depending on what the political scene is looking like in four years, I might caucus again and even consider being a primary delegate (if there's a candidate I feel passionately about).

Calling Ondrej Elleder

2008-08-01T11:49:00.000-07:00

Let's do an experiment.

I have a Google Alert set up on my name, so (presumably) whenever someone blogs about me I'll get an email with the link and can check it out. I'm wondering whether this is somewhat common, or just among tech geeks. So let's drop the name of one of my friends from college, and see if this post makes its way to him across the internet.

His name is Ondrej Elleder (read a bit about him here), and this postcard that he sent me was another find while I was cleaning out old papers this week. One of the biggest things I miss about college is living and socializing with such fascinating, diverse and entertaining people. Linguaphiles who would write postcards like this:

To: The discreditable SUSAN MOSKWA

Susan! Hail, by mail, from the city of the FLAIL! Whyever the FLAIL? This be the reason, Missus: It was the favourite weapon of the Hussites. And don't you ask me who the Hussites were! :-S Contemplate instead the Freudian symbolism of having the flail for a weapon.

Happy New Year,
Ondřej

What do you know about Sri Lanka?

2008-07-30T17:26:00.000-07:00

For many years I used to work as a barista in a Borders café. Sometimes on slow days we'd come up with a Question Of The Day that we'd ask all our customers as we were making their drinks. It was invariably fascinating to hear the wide variety of answers; some people were shockingly knowledgeable, others shockingly ignorant or misguided. Either way, it was a fun way to engage people and pass the time.

Today while cleaning out some old boxes I came across my notes from one of those days. The question was, "What can you tell me about Sri Lanka?" Here are some of the answers we got (I'll leave it to you and your favorite search engine to determine which are true and which are bogus):

Sri Lanka is not a very rich country
Good music comes from Sri Lanka
Sri Lanka is a character in Lord of the Rings
It's next to India
It has lots of violence
Sri Lanka sounds like something out of Star Wars
It used to be named Ceylon
It's a country
People speak Latvian in Sri Lanka
It used to be part of the USSR
They have good tea
There are semi-precious stones in Sri Lanka (sapphires, rubies)
The Tamil Tigers from Southern India are in Sri Lanka (this person regaled us with a long discourse on the political situation in Sri Lanka)
It's an island
My professor is from Sri Lanka
People speak Sri Lankan in Sri Lanka
Kandy is a large city in Sri Lanka; the English word candy comes from that city's name because the Dutch brought rock candy to Europe from Sri Lanka
Sri Lanka is the term for a type of sex
Sri Lanka is a mythical place of paradise
Sri Lanka is a kind of food
There's a famous tower in Sri Lanka
They make copra there (the dried meat of a coconut, used for making coconut oil)
Sri Lanka is a Catholic country
People there are starving
They have poisonous watersnakes
Sri Lanka is low-lying and subject to hurricanes
Arthur C. Clarke lives there

To set the record straight, Sri Lanka is an island off the southeast coast of India. Area: ~25,330 square miles. Population: ~20 million. Major languages: Sinhala, Tamil.

Another round of fresh meat

2008-06-26T15:31:00.000-07:00

Looks like it's that time of year again: Rat City held their mid-season tryouts this past weekend, and PFM rocked all rounds of the tryouts, ending up with nine members recruited onto Rat City:

Throttle Rockets
Sirius Mischief
StarStruck
Grave Danger
Jody
Jocelyn 4 Position
Piston Vinegar
Sockit Wenches
Anna S
Caddie Smack
Trouble Loves Mimi
DLF
Drea the Slaya

We also have several alumnae in Jet City Booty Camp right now, and their tryouts are tonight. Good luck, ladies!!

First steps with Google Analytics & Webmaster Tools

2008-03-19T18:42:00.000-07:00

After setting up Google Analytics and Webmaster Tools for your site, there are a couple quick settings and tweaks that I'd recommend:

Set your preferred domain.
Decide whether you want your website to be referenced with or without the www prefix (example.com vs. www.example.com). In your Webmaster Tools account, navigate to Tools > Set preferred domain and select the radio button next to your preferred version of your domain. I'll talk more soon about how to set this preference on your own server as well (so that anyone visiting your site will know which version you prefer).
Remove yourself from your Analytics traffic reports.
You probably don't want to include your own visits to your site in your reports. To fix this, create a filter in Analytics for each IP address from which you frequently access your site. I've created filters for my home IP address and my office IP address. Here's how to create the filter. If you don't know what your IP address is, a site like WhatIsMyIP.com can find it for you. Note that if you frequently access your site from a public location (such as a library computer or your local cafe), filtering out traffic from that IP address will also exclude from your reports anyone else visiting your site from that location.

If tools like Analytics freak you out, or you want to dig deeper but don't have the time, consider contracting an Analytics Authorized Consultant. These companies have in-depth knowledge of Analytics and can provide hands-on setup and support if the do-it-yourself style of the Help Center isn't enough for you.

Previous: Installing Analytics & Webmaster Tools

Setting up Google Analytics & Webmaster Tools

2008-03-18T17:50:00.000-07:00

A friend called recently and told me he'd started his own blog about comics and film. He's not very web savvy, and simply asked, "What should I do to make my blog successful?" My next couple posts cover the advice I gave him. The examples are tailored for a site using Blogger, but the advice applies to all types of sites.

The first thing I walked him through was setting up Google Webmaster Tools and Google Analytics. Webmaster Tools gives you information about your site's performance in search results, and Analytics gives you information about who's visiting your site and what they're doing once they reach your site. Here are the steps to sign up:

[Edit: Blogger is now integrated with Webmaster Tools, so you can skip steps 8-12 below and just click the 'Webmaster Tools' link at the bottom of your Blogger Dashboard.]

Log in to Blogger and click the 'Layout' link for your blog.
Click the 'Edit HTML' link.
Click the 'Download Full Template' link to save a copy of your current Blogger template on your computer. That way, if you mess something up while you're editing your template, you can revert to this saved version.
Leave the browser window with your Blogger template open. In a new window (or tab), go to http://analytics.google.com/.
Log in to Analytics and click 'Sign Up'. Enter your site's URL and name your account something like "My personal sites" (you can add other websites to this account in the future if you like).
Walk through the rest of the sign-up process. You should end up on a page that says 'Tracking Code' and contains a block of code. Copy this code.

Go back to Blogger and scroll down to the bottom of your site's HTML template. You should see code that looks like this:

  </div></div> <!-- end outer-wrapper -->
</body>
</html>

Paste the Analytics code that you copied right above the </body> tag, like this:

  </div></div> <!-- end outer-wrapper -->

<!-- Analytics code -->
<script src="http://www.google-analytics.com/urchin.js"
  type="text/javascript">
</script>
<script type="text/javascript">
_uacct = "UA-1234567-8";
urchinTracker();
</script>

</body>
</html>

Leave the browser window with Blogger open. In a new browser window (or tab), go to https://www.google.com/webmasters/tools/.
Type your site's URL into the box on the Dashboard and click 'Add Site'.
Click the 'Verify your site' link on the next page.
In the drop-down menu, select the 'Add a meta tag' option. Copy the code that appears.

Go back to Blogger and scroll up to the top of your site's HTML template. You should see code that looks like this:

<head>
  <b:include data='blog' name='all-head-content'/>
  <title><data:blog.pageTitle/></title>
  <b:skin><![CDATA[/*

Paste the Webmaster Tools code right after the <title> tag, like this:

<head>
  <b:include data='blog' name='all-head-content'/>
  <title><data:blog.pageTitle/></title>
  <meta content='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
    name='verify-v1'/>
  <b:skin><![CDATA[/*

Click the 'Save Template' button below your HTML template.
Click the 'Verify' button in your Webmaster Tools account. Your site's status should change to Verified. If not, wait a few seconds and click 'Verify' again.
Go back to your Analytics account and click 'Check status' for your tracking code. It should tell you that your code has been installed correctly and data is being collected.
Go to your blog's homepage and view your blog to make sure that everything looks okay (make sure you didn't mess up your site's template while editing it). If everything looks okay, you can delete the copy of your template that you saved to your desktop. (If something looks wrong, you can erase your changes by uploading the template copy that you saved at the beginning.)

If you have problems with these steps you can drop me a note, or get help here: Blogger Help, Webmaster Tools Help, Analytics Help.

Next: A couple tips for your initial Analytics/Webmaster Tools setup