Checksum Arcanius

Websites should list their password restrictions on their login pages. Sometimes I run into the following problem:

I try to use a password generated by my “standard model” — ie, a standard prefix depending on the nature of the site and some salt determined by the website itself. However, some sites have stupid rules on their password requirements. In real life, I have encountered a wide variety of password requirements:

• A requirement of an exactly 6-character password
• A prohibition on “special characters” like any of !@#$%^&*()+=></?{}[]|\/.
• A requirement for a special character that happens to be one of !@#$%^&*()
• A requirement for numbers, uppercase, and lower case in the password
• A requirement for two sets of letters and numbers in the password — ie, fit the regex /([a-zA-Z]+[0-9]+){2}/

When my standard model password doesn’t fit into one of the more esoteric requirements, I have to modify it to fit. Fortunately, I find that on this subject at least, I tend to think the same way over time, so, given the standard model and a set of constraints, I will usually come up with the same password. However, it is uncommon for websites to list their password constraints on the log-in page. Therefore, I will usually try the standard model password first, and only when that fails twice (in case I mistyped the first time), and I’m down to one more try, do I realize that this website might be “special.”

Then I have to go to the trouble to find out what the password requirements are. This is not difficult — usually it involves clicking the “sign up button” and reading a little bit — but it does take some time and it is very annoying. Listing the password requirements at the login screen would make for a much better user experience (since it is so easy to find this information, not displaying it on the login screen can’t be interpreted as a security measure either).

Of course, the real solution is for websites to get rid of their inane password requirements, so I never have to deviate from the standard model.

In the last two days, I

1. Changed my blog’s MySQL tables storage engines from the MyISAM to InnoDB
2. Installed the Wordpress Memcache Plugin to mimimize database queries (16-25 queries reduced to 2-7)
3. Installed APC (Alternative PHP Cache) to reduce PHP bytecode compilation overhead. As a result, all PHP sites on mimimus should be faster.

In addition, I did some general cleaning up and upgrading of software on minimus and nexus.

Altogether, these changes reduce the typical Checksum Arcanius page load from 2.5-3.5 seconds to 0.5-1.5 seconds, a 2-7x improvement.

These are very easy steps to take — I would suggest them to anyone running Wordpress. Step-by-step directions follow (assuming Ubuntu Linux):

1. For each table in your blog’s database, execute the following SQL via a mysql client instance, phpMyAdmin, etc:
   ALTER TABLE <tablename> ENGINE = InnoDB;
2. Install memcache:
   sudo apt-get install memcache
3. Download the Wordpress Memcache Plugin and place it in your wp-content directory. That is all you have to do to get memcache support in Wordpress!
4. Install APC:
   sudo apt-get install php-apc
5. Restart Apache:
   sudo /etc/init.d/apache2 restart

Very simple steps with a very high payoff.

I have been trying to return a package to Amazon for over a month now. I think it might make it this time! I have two tracking numbers, and one of them (1Z7R23Y69088829050) reports the following tracking data:

Notice how it magically disappeared for almost a month after reaching Kentuky, and then reappeared in Menlo Park, only to be shipped off again. UPS magic!

That means the package has travelled over 7,000 miles since when I tried to ship it!

Almost six years ago, I first downloaded Mozilla Firebird, the web browser that became Firefox. Within a week, the new browser had won me over. It took about another year for Mozilla to release Firefox 1.0, the first generally available version of the new browser, on November 9, 2004. Now, Mozilla is celebrating Firefox’s fifth birthday.

Since then, Firefox has seen over 1 billion downloads and has made significant inroads against the once totally dominant and stagnant Microsoft Internet Explorer. Despite experiments with Chrome, Safari, Opera, and the newer versions of IE (which wouldn’t even exist had Firefox not forced Microsoft into action), Firefox has remained my browser of choice, due in large part to its constant improvements, rich set of extensions, and supporting all the little things that make browsing fast and fun.

In a lot of ways, the culture of Firefox has grown into a religion, with its adherents being encouraged to spread the good word of Firefox, convert their friends, and so on. Nevertheless, it is a religion I feel good about being a part of. So, if you don’t already use it, go give Firefox a try.

Recently, I started using Windows 7 on my laptop, which lead me to adopting PuTTYcyg as my terminal of choice. Also, in large part due to my new job at Facebook and my misgivings about some aspects of Mac OS X, I’ve been experimenting with my terminal setup a lot recently. My research during this time led me to learning about patching PuTTY to send ctrl-tab and ctrl-shift-tab. I thought that sounded like a good idea, but of course I was using PuTTYcyg now, so I had to do the patching myself.

It turned out that downloading and patching the code was straightforward enough: With a few development packages in cygwin (namely make and the normal C/C++ gcc), make worked (almost) without a hitch. All I had to do was download the PuTTYcyg icon (which was not included in the patch), and everything compiled properly. However, after compiling, when I ran a cygwin terminal, a second windows command-prompt-style window with a bunch of debug info popped up:

This of course was a non-starter, so I searched in vain for a few hours to try to fix this, and ended the night by opening a new issue at the PuTTYcyg home page.

The PuTTYcyg developer pointed me to the Makefile used to build the PuTTYcyg releases. In it are a few special XFLAGS that magically make the extra window not appear:

XFLAGS= -UDEBUG -UNO_MULTIMON

Using the new Makefile, I compiled again, and this time when I ran PuTTYcyg, there was no annoying extra window. Brilliant!

Feel free to contact me if you need any more info.

I have had a number of frustrations since I started at Facebook in adapting to the quirks of Mac OS X. I have been in Windows-land for so long that I consider its quirks normal, so figuring out the quirks of OS X has at times been frustrating. Nevertheless, I think I am making good progress.

I am using GNU screen while logged in to linux machines extensively during work, so I invested a little time in setting up a good screenrc. Afterwards, I noticed that I was unable to get the screens to switch using ctrl-left and ctrl-right the same way I would be able to from a Windows machine.

After being frustrated with trying to get Terminal to send the right control characters, and getting screen to recognize them using bindkey, I took a step back and found a solution that actually works. Despite its failings at behaving like PuTTY in every respect, Terminal does offer a lot of customizations, including the ability to change what control characters get sent when you press control-left and control-right, for example. So instead of trying to divine the right bindkey option for Mac OS X (which no one seems to have succeeded at as far as I can tell), I took another approach:

I told Terminal to send “ctrl-a p” (\001ap) for ctrl-left, and “ctrl-a n” (\001n) for ctrl-right. This makes hitting those keys the equivalent of going to the previous and next screens manually, but without the manual part. Of course, if you use a different control character for your screen, you will want to use that instead of ctrl-a as I did, but this finally got screen to behave the way I wanted, which makes me quite happy.

For reference, my screenrc looks like this right now:

vbell off
autodetach on
startup_message off
defscrollback 10000

hardstatus alwayslastline
hardstatus string '%{= kG}%-Lw%{= kW}%50> %n*%f %t%{= kG}%+Lw%< %{= kG}'

Friday marked the end of my first work week at Facebook, my new employer. As far as first weeks go, it started off with a bang when I got a new Macbook Pro and an iPhone 3Gs on the first day. I’ve grown to like the iPhone pretty well (the Twitter and Facebook apps, particularly), but I still am having my struggles with the Macbook.

I love the touchpad and the transparent terminals, and the back lit keyboard is sexy and functional, but there are also a lot of keys I miss, especially when I’m away from the extended keyboard at my main desk — home, end, page up and down, and delete (forward) being the leading examples. The function key on the laptop is also misplaced (I prefer control on the outside, as is the case on every reasonable keyboard known to man). The menu-bar-atop-primary-display decision is, quite frankly, terrible. There are also lots of other little annoyances: half of what “should be” control-key is command-key (ie, copy and paste), while the other half is still control-key (ie, changing tabs in Firefox, everything in the terminal).

The end all is that I am seriously considering swapping the Macbook for a Thinkpad. I haven’t made that decision yet, but it may happen next week. Or I may decide to tough it out, since I’ve already learned how to deal with most of the quirks.

Apart from the Macbook blues, the first week went fairly well. The first day was the normal mostly-government-mandated HR stuff, and then on day two I got to check out all of Facebook’s codebase and set up a sandbox. With some onboarding sessions, good documentation, and some help from a knowledgeable returning intern, I was actually able to be a little productive in my first week, a vastly different experience than I had at Amazon last summer.

Also, the food has been uniformly quite good to excellent, so living cheaply (except for the exorbitant rent at my too-nice Palo Alto pad), will be possible. At least, I won’t be spending too much money on groceries or restaurants.

Last but not least, there was the news that had to make this the best week to start at Facebook ever:

1. Facebook hit 300 million active users, another unprecedented milestone in social networking
2. Facebook became, for the first time, cash flow positive, a year ahead of their own projections

So overall, a good week to start, I would have to say.