Tag Archives: Lifehacks

Just the Facts

Local news sites are notorious for low signal-to-noise ratios.  The news content is good, but that’s often crowded out by excessive ads, Flash videos, runaway JavaScript, and animated GIFs. These things make 90s websites look clean and elegant. I get seasick visiting them.

My typical antidote has been to just stick to RSS, and let blockers like Chrome’s Click to Play squelch things when I have to visit the site.  But the Atlanta Journal-Constitution (AJC) recently broke their RSS feeds while at the same time expanded their JavaScript and floating div monstrosities. What’s a guy to do when he just wants to read the latest Falcons and Georgia Tech news?

Well, I took the nuclear solution and went with lynx.  Yes, lynx: the old text mode browser. Whenever I want to read content from the AJC or similar news sites, I just fire it off from the command line and browse away. It works well, and I can do a quick news check in no time. Hopefully, the AJC won’t start disallowing or punishing lynx use.

Friday Fixes

It’s Friday, and time again for some Friday Fixes: selected problems I encountered during the week and their solutions.

You know the old saying, “build a man a fire and he’s warm for a day; set a man on fire, and he’s warm for the rest of his life.”  Or something like that.  I’ve been asked about tool preferences and development approaches lately, so this week’s post focuses on tools and strategies.

JRebel

If you’re sick of JVM hot-swap error messages and having to redeploy for nearly every change (who isn’t?), run, do not walk, to ZeroTurnaround‘s site and get JRebel.  I gave up on an early trial last year, but picked it up again with the latest version a few weeks ago.  This thing is so essential, it should be part of the Eclipse base.

And while you’re in there, check out their Java EE Productivity Report.  Interesting.

Data Studio

My DB2 tool of choice depends on what I’m doing: designing, programming, tuning, administering, or monitoring.  There is no “one tool that rules them all,” but my favorites have included TOAD, Eclipse DTP, MyEclipse Database Tools, Spotlight, db2top, db2mon, some custom tools I wrote, and the plain old command line.

I never liked IBM’s standard GUI tools like Control Center and Command Editor; they’re just too slow and awkward.  With the advent of DB2 10, IBM is finally discontinuing Control Center, replacing it with Data Studio 3.1, the grown-up version of the Optim tools and old Eclipse plugins.

I recently switched from a combination of tools to primarily using Data Studio.  Having yet another Eclipse workspace open does tax memory a bit, but it’s worth it to get Data Studio’s feature richness.  Not only do I get the basics of navigation, SQL editors, table browsing and editing, I can do explains, tuning, and administration tasks quickly from the same tool.  Capability wise, it’s like “TOAD meets DTP,”  and it’s the closest thing yet to that “one DB2 tool.”

Standardized Configuration

For team development, I’m a fan of preloaded images and workspaces.  That is, create a standard workspace that other developers can just pick up, update from the VCS, and start developing.  It spares everyone from having to repeat setup steps, or debug configuration issues due to a missed setting somewhere.  Alongside this, everybody uses the same directory structures and naming conventions.  Yes, “convention over configuration.”

But with the flexibility of today’s IDEs, this has become a lost art in many shops.  Developers give in to the lure of customization and go their own ways.  But is that worth the resulting lost time and fat manual “setup documents?”

Cloud-based IDEs promise quick start-up and common workspaces, but you don’t have to move development environments to the cloud to get that.  Simply follow a common directory structure and build a ready-to-use Eclipse workspace for all team members to grab and go.

Programmer Lifestyle

I’ve been following Josh Primero’s blog as he challenges the typical programmer lifestyle.

Josh is taking it to extremes, but he does have a point: developers’ lives are often too hectic and too distracted.  This “do more with less” economy means multiple projects and responsibilities and the unending tyranny of the urgent.  Yet we need blocks of focused time to be productive, separated by meaningful breaks for recovery, reflection, and “strategerizing.”  It’s like fartlek training: those speed sprints are counterproductive without recovery paces in between.  Prior generations of programmers had “smoke breaks;” we need equivalent times away from the desk to walk away and reflect, and then come back with new ideas and approaches.

I’ll be following to see if these experiments yield working solutions, and if Josh can stay employed.  You may want to follow him as well.

Be > XSS

As far as I know, there’s no-one whose middle name is <script>transferFunds()</script>.  But does your web site know that?

It’s surprising how prevalent cross-site scripting (XSS) attacks are, even after a long history and established preventions.  Even large sites like Facebook and Twitter have been victimized, embarrassing them and their users.  The general solution approach is simple: validate your inputs and escape your outputs.  And open source libraries like ESAPI, StringEscapeUtils, and AntiSamy provide ready assistance.

But misses often aren’t due to systematic neglect, rather they’re caused by small defects and oversights.  All it takes is one missed input validation or one missed output-encode to create a hole.  99% secure isn’t good enough.

With that in mind, I coded a servlet filter to reject post parameters with certain “blacklist” characters like < and >.  “White list” input validation is better than a blacklist, but a filter is a last line of defense against places where server-side input validation may have been missed.  It’s a quick and simple solution if your site doesn’t have to accept these symbols.

I’m hopeful that one day we’ll have a comprehensive open source framework that we can simply drop in to protect against most web site vulnerabilities without all the custom coding and configuration that existing frameworks require.  In the mean time, just say no to special characters you don’t really need.

Comments Off

On that note, I’ve turned off comments for this blog.  Nearly all real feedback comes via emails anyway, and I’m tired of the flood of spam comments that come during “comments open” intervals.  Most spam comments are just cross-links to boost page rank, but I also get some desperate hack attempts.  Either way, it’s time-consuming to reject them all, so I’m turning comments off completely.  To send feedback, please email me.

Downtime

During my freshman year at Georgia Tech, Tina gave me a coffee mug depicting green bar paper bearing the words “While the Computer is Down…” repeating in a Westminster font.  That old phrase registered at that time because I then did most of my programming assignments on an overworked and frequently-crashing CDC Cyber (I needed at least sophomore status to use the Xerox Stars, HP 9000s, and other more modern machines).  Restarts usually took 20 minutes or more, and there was nothing we could do but wait.  So, at the very least, “Cyber is down” meant we could enjoy a good coffee break.

My first real job put me alongside seasoned mainframe programmers who knew well how to handle outages: step away from the green screen, talk a walk, visit the cafeteria, catch up on techniques, chat with friends, and so on.  These guys would often swing by my office while I was pecking away at my LAN-connected PCs and servers, totally unaware of the outage.  And they were usually pretty good at convincing me to join them in their forced break.

The advent of the personal computing era meant that any outage was under my own control, and there was always a suitable backup nearby.  So “always on” became a way of life: if my PC, laptop, PDA, pager, or cell phone died, I typically had several alternatives to turn to.  This removed all excuses for ever being disconnected, and we grew to expect 24×7 access to everything.  The unexpected result was that, in making these redundant devices slaves to us, we became slaves to them.

Now, of course, cloud computing is chipping away at that and pushing us back into a bygone era when folks were at the mercy of whatever was at the other end of a dumb terminal.  As more of what I do gets pushed out into the cloud, I lose more control.  Remote VPSes, VMs, and EC2s replace local servers, Gmail and GCal replace Outlook, Mint replaces Quicken, and so on.  I have multiple ways to access all these things, but there’s still just one of each of these services out there.  And along with that, we get back the shared computing pecking order: paying customers with SLAs get all the redundancy, fail-over, and guaranteed up-time, while smaller and free users rank somewhere below computer science freshmen.

So downtime has again become a part of life.  Just recently, I was affected by extended outages at Visa, Chase and Intuit, and shorter outages at less critical sites: Google, 1and1, MapMyrun, Facebook, Weather.gov, etc.  What can one do when such outages occur?  Not much, other than find something else to do, like take a coffee break.  And that’s not always such a bad thing.

Battling Droids

Given recent questions about my Droid phone, perhaps it’s time to post again about it.  This time, I’ll offer tips on battling two common Droid demons.

1. The condensation poltergeist. The tiniest amounts of condensation can make Droid’s touch screen act possessed.  The Ghost of Droid will scroll automatically, start apps, search for things, make phone calls, and wreck all sorts of direct-manipulation havoc.  And there’s no point in fighting it: it’s much faster than you, and when it takes over, it’s usually impossible to win the battle and override it.  A locked screen offers some protection against emailing your boss or calling Tokyo without your consent; in this case, it can only repeatedly try to draw out your unlock pattern, usually resulting in a series of “wait 30 seconds” holds.  It’s entertaining to watch, but annoying to say the least.

This weird phenom has been ascribed to viruses, chargers, and other hardware and software issues, but, in my experience, it’s always due to condensation on the touch screen.  And since it requires so little moisture, it’s hard to predict when it will happen.  It has happened to me upon walking into an indoor pool area, and inside my car after a long run.

As long as you keep your Droid at 70 degrees and 40% humidity (perhaps in the raised floor area of your personal data center), you’ll be fine.  For those of us in the real world (and who like Georgia summers), just stop using it when it happens, turn it off, be patient, and wait for it to dry out.  You can help it along by bringing it back into the air conditioned indoors or using a blow dryer on a cool setting.

2. The grim reaper ringer. That “slide to answer” control and dexterity test works great at preventing accidental unlocks and butt calls.  So great that if you try it while driving, you’re as likely to annihilate as answer.  An early Android update made it slightly easier (straight rather than curved slide), but it’s still difficult.  Most bluetooth headsets provide an alternative, but if you’re not headsetting it, it’s best to just pull over before attempting to answer, or simply miss the call and return it later.  Answering that call is not worth crashing into the ditch or oncoming traffic.

I’ve heard that the latter problem will be fixed soon in an Android (software) update, but the touch screen issues will probably have to wait for a new phone (gotta love “new every two”).  My next phone will almost certainly be an Android, but probably won’t be a Motorola Droid.

IRQ?

Typical Wednesday.  One of my meetings for today was a conference call where I expected to remain mainly in listening mode.  So I attempted some of my own work during the call, making good use of the speaker and mute button.  I am male, but can usually handle two things at once.

But during the course of that one hour session, I got two cell phone calls, five urgent emails, IMs from four co-workers, and many more questions than expected from the call.  It came to a few dozen separate topics, far exceeding my “two plus or minus seven” capacity. Postponing non-urgent interruptions helps, but increases my backlog queue length.  Yet responding “on demand” often leads to dropped interrupts and increased interrupt latency.  It can be tough to maintain the balance.

Careful thoughtwork requires focus and concentration, and interruptions can quickly wreck that.  I was reminded of Larry Constantine’s classic essay, Irksome Interruptions.  In it, he wittily suggests that programmers adopt the nomenclature of CPU interrupt handling to deal with this problem.  It’s a geeky way to go about things, but handled this way, an “interrupt request” becomes short enough not to derail a thought process.  Want to chat with someone who might be busy at task?  Just ask “IRQ?” (pronounced “irk?”).  If it’s a good time, they’ll “ACK” you, which buys a moment to “save state” before “servicing your interrupt.”  If it’s a bad time, they can just answer “NAK” (negative acknowledge), and you know to try later, with no harm done (no thought process wrecked).  And someone who has developed a habit of frequent interruptions might be labeled IRQsome.

Constantine wrote his essay before our work environments had so many more interrupt request lines to service.  Multiple IMs and chat rooms, multiple phones, and emails arriving at high rates add to classic face-to-face interruptions.  And the economy was better then (and engineer-to-workload ratio higher), so folks weren’t pulled in so many different directions.  Yet his suggestions are compelling, and I do exchange “irq”s, “ack”s, and “nak”s (over IM) with one co-worker who has also read the old essay.  The classic instant messaging “yt?” also works, provided one is willing to answer “n” or “no” when not prepared to be mentally there.

Droid Does

A friend and fellow Droidian asked me today what my favorite free Android apps were.  I really didn’t know where to begin because I use so many of them so regularly.  This includes, of course, the preloaded ones: music, calendar, gmail, browser, maps, navigation, talk, contacts, messaging, YouTube, Picasa, etc., etc..  But to answer the question, I thought I’d jot down a list of some of my favorite free Market downloads here:

– Scoreboard – All my sports scores, all the time.
– Pandora and Slacker – Personalized internet radio, love it.
– Google Places – Must… find… coffee.  Perfect GPS compliment to Maps and Navigation.
– Flixster Movies – What’s on and what will be on.
– Weather Channel – Faster than looking out the window.
– Google Sky Map, Clear Sky Droid – For my astronomy fixes.
– Google Goggles – Still under development, but fun to try.
– androidVNC and ConnectBot (ssh) – The remote access classics.
– Shop Savvy – Barcodes R us.
– NewsRob, wpToGo, Google Listen, Read Later – For feeds, blogs, podcasts, and news.
– KeePassDroid – The world’s most portable password safe.
– Evernote – Snap a photo or jot a note, and it’s on the web in seconds.
– “Commercial news” readers: Thomson Reuters, BBC News, USA Today, Fox News, etc.
– Toys and Games – Compass, Labyrinth, DailyStrip, Jewels, Sudoku, Solitaire, Frozen Bubble, etc., etc.
– And, of course, lots of mainly pointless apps like Run, Zombie, Run and Talking Parrot.

Of course, half the fun is searching Android Market for any app you can think of that just might be out there.  There’s a good chance it is.