Grant's Space

Sadly, it looks like Intuit’s programmers have infected the once good Mint.com

When I started this post, I was afraid I used some FlightPrep software. I was ready to delete it. Then I realized I’d considered their products, but found them inferior to other products out there. I felt they were an outdated company trying to catch up (and failing).

FlightPrep is posting on their site logical-sounding claims regarding a patent they filed and how they’ve tried to contact the maintainer of runwayfinder.com, grant him a free license during negotiation, etc.

Here’s what it really comes down to:

1. Lawyers are expensive and time-consuming. This is 1 person with a full-time job against a company with 4 full-time employees, and evidently enough capital to pay lawyers.
2. Sure, it’s good business practice to sue/buy the competition. Microsoft is famous for it. Microsoft is also hated for it. I won’t tolerate that tactic from FlightPrep. Delete.
3. FlightPrep claims that RunwayFinder is infringing on their patent and wants RunwayFinder to pay them to keep running. I run a couple of web sites – it’s not worth my time to deal with legal issues. I’m sure Dave doesn’t have time either (as he says). The mere claim of infringement overruns his resources.

I’m a software developer by profession, and software patent law needs some serious change. The problem is that people can patent simple ideas that anyone can come up with. Take Amazon’s “one click” for example. Store address and credit card information so that the user can use it later – patent! Evidently pointing out airports on a chart and letting you route (an existing process taught to every pilot) is patentable if you write a program to do it (by any means).

So yes, FlightPrep, you might be “playing by the rules”, just like the smart bullies did in elementary school. It doesn’t mean we want to be your friends any more.

Fire the person who thought that going after one of the most-used pilot tools on the web would be beneficial to anyone (including FlightPrep) and, after enough time to regain your reputation, I’ll consider using your software. If you’re still around.

(By the way, I prefer ForeFlight’s software to FlightPrep’s. I assume they’ll be sued next).

Mission
Utilize cross-media e-services to grow revolutionary communities.

Point-by-point Plan

• incubate open-source interfaces
• target synergistic models
• matrix front-end schemas
• morph bricks-and-clicks web services
• embrace one-to-one niches
• (profit!)

Plan developed with the aid of this tool.

If I get a bunch of Google hits from BS keywords, I’m going to laugh.

On August 29, 2010, Santa Monica’s Big Blue Bus took a step backward in fare handling. Ironically, to announce the change, they ran ads implying that you wouldn’t need to use money on the bus any more. In reality, they were replacing the Little Blue Card (which allowed you to load cash onto the card and pay for your bus fare, transfers, express bus fees, etc) with various trip-based or multi-day-based passes (which don’t allow you to pay for transfers or express bus fees).

So, Dear Los Angeles Public Transportation providers, here’s why spewing advertising billboards about saving gas all over the city isn’t getting people on your busses and trains:

• Make paying simple
  Seriously, I’ve lost count of the times I’ve driven to work instead of figuring out if I have exactly $1.50 for the trip there and $1.85 for the trip back (and calculating that cost in the first place). Heaven forbid I get on the wrong version of the bus I need to get back (see a lower point) and need to pay an extra amount. Take a hint from Hong Kong and London:
  • Make it easy to load cash on the TAP card (hint: online, in EVERY Metro station, and on EVERY bus)
  • Make the fares simple! Seriously, it’s one rate if you’re staying local, another if you’re going into a different “zone”, another if you’re a student, another if you’re a senior, another if you’re taking more than one bus. GEEZ! It’s easier to buy a car than take the damn bus once! Remember the old KISS rule – Keep It Simple, Stupid
• Make the busses and trains run more frequently
  Some are fine, some aren’t. If a line runs less frequently than every 20 minutes, it’s basically useless. 5-10 minutes, and you’re talking about replacing my car. 10-20 minutes, and I’ll consider it if I don’t want to drive. 20 minutes, and I’m just gonna be spending my life at bus stops – no longer worth it.
• Make the busses run reliably
  This one’s huge. I was all set to bus to work and cancel my parking until the day I got left on the street for over 40 minutes one cold night because a bus (scheduled every 20 minutes…) just didn’t show. The busses sole purpose is to get me somewhere – if it fails that purpose, I have to find something else to get me there. LA Metro repeatedly fails that purpose.
• Make all transit lines use the TAP card
  “Can’t we all just get along?” Really, everyone’s got to use the same payment system to make the system usable. LA’s too big to have to guess at the three systems you might need to use to get somewhere more than a couple miles away (or even less than a couple miles away). The EZ transit pass is ok, but is only affordable if you’re going to only use public transportation; it loses the occasional rider.
• Make the bus/train lines simple
  Sure, it’s a big city, and the system’s going to be a bit complicated. But at least try for simplicity: Let’s take the 108 Metro bus for example. One out of every three trips, the route extends into Marina Del Rey. Same bus number, different destination. Really? Who thought that would be a good idea? So if you’re waiting for the 108 and need to go to Marina Del Rey, and don’t notice that the head sign says “Fox Hills Mall” instead of “Marina Del Rey”, you just got stuck at the mall, and have to hope you have the extra buck fifty or whatever it is to get the rest of the way (whenever the right version of the 108 comes). Again, the bus just failed to get me where I need to go – time for another solution.

Yeah, I know “running the bus every 10 minutes is too expensive”, and “there aren’t enough people on the bus to warrant it running more than every 45 minutes through this one section, but there is through this other section, and we don’t really want to have it be a transfer because the people coming in from Marina Del Rey would have to transfer blah blah blah”. And so, we widen the 405, because if you take the 761 into the valley, good luck figuring out how to get back (hint: it’s not on the 761). Make it easier to pay, faster to get places, and easier to comprehend, and maybe LA can join the list of world cities in which people who can afford a car use public transportation to get around anyway.

I program a lot in Perl. I used to be a big fan of “modules should never die”. Now I’m the opposite. I want a method to die any time it can’t succeed in doing what it’s been asked to do.

Here’s why:

Without exceptions:

$module->do_something( %args ) or die "I couldn't do something";
$module->do_something_else( %args ) or die "I couldn't do something else";
[...]


With exceptions:

$module->do_something( %args );
$module->do_something_else( %args );


Now imagine that with hundreds of lines of code. I love having my script or module simply contain a list of commands – Do this then this then this – without having to babysit every single line to make sure everything went ok.

It also lets you handle things on a more transactional basis. Say you want to connect to a database and update some data. With exceptions you can do this:

use Error.pm qw(:try);

my $dbh = DBI->connect($data_source, $username, $auth, { RaiseError => 1, AutoCommit => 0 } );
# RaiseError turned on exceptions. We’re free to roam.

try {
$dbh->do(“update mytable set myfield=’gobble’ where myotherfield=’turkey’”);
$dbh->do(“update anothertable set anotherfield=’somevalue’ where yetanother=’anothervalue’”);
$dbh->commit;
} otherwise {
$dbh->revert;
};

(Don’t quote me on syntax here – this is very perl-like psuedocode. )

I also like building exceptions into my own modules using Error.pm. This lets me throw specific types of exceptions. I usually end up with an exception type for data errors, IO errors, and Database errors, just in case I want to catch those. For example, I may wait and retry IO and Database errors, but a Data error (bad user data) I’ll let go uncaught up to the UI level so that the UI can complain to the user.

That brings me to the other reason I like exceptions, and the reason I started using them in the first place. Say you’re building a complex module, or set of modules, with many layers of subroutine calls. If your error-trapping mechanism is the ever-popular “return undef”, you now have, say, 5 layers of subroutine/method calls to check and pass undef up. You forget an “or return undef” at any level, and you let an error slip by. Usually something’ll break later on in your program as a result, and you’ll have a hard-to-track bug. I prefer to throw an exception and include a stack trace (see the Error.pm docs for sample code). Then you can catch the exception at any point, and if you don’t, you still have a stack trace that shows exactly where the error occurred.

“But I don’t want my script killed by a module I’m using, I want to decide what to do if there’s a problem”. I used to think this. But the fact is, 99.9% of the time you’re going to do one of two things:

1. $module->do_something() or die “Couldn’t do something: ” . $module->errstr;
2. $module->do_something();

In the first case, if do_something threw an exception, it’d save you the babysitting code. In the second case, if “do_something” didn’t do what it was supposed to, chances are your program can’t really continue anyway, right? And if it can, maybe you don’t need to “do_something()” anyway. And for that .1% of the time you want to ignore errors, you can “eval { $module->do_something(); }”.

So there. I like throwing exceptions. Maybe you will too.

Further reading: “man Error”, http://www.perl.com/pub/2002/11/14/exception.html