Windows and Tabs

My FireFox tabs were getting out of control.  I had about 50 tabs all stacked up and I couldn’t really quite keep them all straight.

Why so many?  I had about a dozen tabs for things like Gmail, Twitter, a few random sites/blog posts I’d been meaning to read/scan, two YouTube videos I wanted to watch, and a few things I wanted to blog here.  Another dozen tabs were devoted to things related to a business/blog/website – images I wanted to use in posts, post drafts, etc.  And, about two dozen consisted of awesome stuff in Thingiverse and around the web I wanted to blog over at MakerBot.

For someone who gets easily1 distracted like myself, having so many tabs across so many different topics makes it very easy for me to get sidetracked.  It occurred to me that I could just open up a few FireFox windows and drag and drop my mess of tabs into three broad categories.  I opened up two additional windows, which makes one for MakerBot blog post drafts, business/blog post drafts, and a third for miscellaneous stuff. 2

So far I’ve been able to clear out a bunch of tabs – which feels great.  One interesting and satisfying side effect is that when you close the last tab in a FireFox window, the window closes!

  1. Ohh!  Shiny! []
  2. Like this post! []

Who is tracking you? Collusion plugin for FireFox

If you want to see something that is simultaneously disturbing and ego-inflating, check out the Collusion plugin for FireFox. 1 A friend of mine e-mailed me the link to the LifeHacker post discussing it.  If you want to cut to the chase, the link to the Collusion plugin is right here.  After web surfing and blogging for about an hour, the little web it’s drawn so far is a little scary.

 

  1. In a perverse way, it is slightly ego-inflating because I’m clearly so very important to ALL these companies! []

Hello Thunderbird my old friend, I’ve come to talk with you again

For the past six months or so I have been blaming the latest update to Thunderbird1 for being ridiculously slow.  This charge has, apparently, been completely unfounded.  At about the same time I also noticed a ridiculous deterioration in Firefox’s performance as well as an overall incredible slow down on my laptop. 2  It got so bad that I had to restart Thunderbird at least once a day and shut down all of these “I’m taking too long” errors.

Yesterday I had a brainstorm …  what if having Thunderbird manage two dozen accounts with synching to four IMAP accounts was causing it to hog resources and freak out?

So, I archived a bunch of mail so that it wasn’t synching up, deleted a bunch of old RSS feeds I no longer read, and freed more than 10 GIGS of space off my drive.  Poor Thunderbird.  Here I was berating it, cursing the updates, when really it was my info-addiction that was causing the freakout.  I can now use Thunderbird to communicate again! 3  OMG, I’ve missed it so.  I had taken to using Gmail’s interface more often than not, which is a great web interface, but it’s not my dear Thunderbird!

  1. My old friend []
  2. This being the craptop. []
  3. I’ve come to talk with you again []

You know, assuming everything goes according to plan…

Which never ever happens.

Right after posting about this fantastic large MySQL file upload script…  it stalled out around insert #2,650,000.  Thus, much fiddling with file offsets and start positions ensued.  So, fair warning – the script has zero upload recovery modes.

That said, it’s still significantly easier than using any of the methods I had tried earlier.

Anyhow, if your BigDump <shudder – what a name!> script fails on you, there is a way to force it to resume the upload.  I was performing the upload on a GZipped file – which makes the recovery process more difficult.  Nevertheless, here’s how you do it:

  1. Using FireFox and the FireBug plugin (you are using FireFox, right?) examine the last AJAX call
  2. Copy and paste the URL of the last AJAX call into a new browser tab
  3. Look for the GET variables in the URL named “start” and “foffset”
  4. This is the tedious part.  You’ll need to play with those two numbers until your script restarts.  When you get these numbers wrong, BigDump will be kind enough to show you the last bad MySQL line – it will almost certainly be a partial line.
  5. Looking at what has already been uploaded into your database, estimate whether the current MySQL error falls before or after the last entry.
  6. If after, crank the “foffset” number way down and re-try.  You want to start ratcheting the “foffset” number up – but from a point below the last good entry.  This will ensure you don’t accidentally resume the upload at a point after the last good entry.
  7. When you hit the correct “foffset” value, the browser window will take a while to pull up the page.  When it does, you will see the standard status screen with the file transfer data resumed.

I’ve used this process exactly once to resume a transfer of a GZipped file.  There’s no guarantee it will work for you, so use the above at your own risk.