
February 2005
Pick the Right Tool for the Job
by Brian Dunning
digg this
article | del.icio.us
this article
I'm
often hassled because the shopping cart that I built for many of
the web sites on which I sell software products I sell is written
in PHP, and among my products are Lasso courses and Lasso code
snippets. One guy even suggested publicly that it reflects poorly
on Lasso that I don't even "trust" it for my own stuff.
Hassling me for this reason suggests a deep misunderstanding of
why technology decisions should be made. I don't agree that the
overriding concern should be pleasing the potential Lasso class
attendee by showing him that his registration was completed using
Lasso. Sure, that would be nice, and if all else was equal, I'd
probably have done it. But a more valuable experience for a student
would be to learn what considerations should be taken into account
when making a technology decision, and then to apply those considerations
and make the best selection.
In this particular case, the server in question was a virtual
host on a shared server at an ISP that didn't offer Lasso, like
most ISPs. End of story. Yet my tormentors interpreted that I "didn't
trust Lasso."
From which airplane salesman would you rather be guided to the
best aircraft for you: a guy who sticks to a single type of plane,
refuses to test any others, and knows everything about his own
plane but nothing about any other; or a guy who has flown them
all, used them all, and has a deep knowledge of many types?
So let's talk in specifics. When I'm deciding which technology
to use on a web application, here are some of the environment variables
I'll look at:
- Existing infrastructure. Are there any existing systems
or databases that this new system will need to play nicely with?
- Deployment environment. Where is this going to be hosted?
What kind of remote access will be needed and available? What
operating system is going to be used? Are these decisions dependent
upon my decision, or is my decision dependent upon them?
- Development, hardware, and software budgets. Is money
available to make the hardware and software purchases that my
decision will mandate, and what kind of development budget is
there? Don't be discouraged away from a logical course because
a project with a cost of tens of thousands of dollars is going
to require a purchase a several hundred dollars: keep your eye
on the whole forest. Be dollar wise, not penny wise and dollar
foolish.
- Maintenance situation going forward. Does the owner
of this new system want a large talent pool to draw from for
assistance in the future, or is he going to be dependent upon
a very small pool of talent who might get hit by a bus? Is it
important to use familiar, widely used technology?
- Anticipated load. Is the expected load truly going to
be enough to overwhelm FileMaker Server? Many people seem to
fear this but I've never seen a site that could come close.
FileMaker Server is great and wonderful, but it also has its drawbacks,
as does any technology. It's important to understand these drawbacks,
and those of the competing choices. In my experience, it's best
to use FileMaker Server for your data source when the application
is going to be hosted locally, and local FileMaker users want live
access to the same data that's driving the web site. If that's
established, and Mac and/or Windows are available for hosting,
the next question is to decide on the web application technology.
There are many from which to choose (Lasso and PHP being the most
prevalent), they all work, and the desired end result can be reached
with any of them.
If FileMaker Server is not going to be used, then chances are
strong that I'll recommend PHP/MySQL. I use PHP/MySQL for probably
80% of the web work that I do. It's highly optimized for any server
platform, fast as hell, and has a huge base of programmers out
in the world who can pick up the pieces if I get hit by a bus.
The primary difference between PHP/FileMaker and Lasso/FileMaker
is the query structure. With Lasso, there are zero code changes
needed to switch between a FileMaker data source and a MySQL data
source if you decide to migrate later. With PHP/FileMaker the needed
changes are significant.
The only real limitations with either is
that you need a Mac or Windows server to run Lasso or FileMaker
Server Advanced, and neither is something that most ISPs are not
likely to run unless you colo your own server. Some feel that
this is offset by Lasso's excellent administration consoles, a
feature missing from both PHP and FileMaker Server Advanced.
Usually the decision whether to use MySQL or FileMaker
is straightforward, but not always. Sometimes half of the puzzle
pieces support one model, and half support the other. Compromise
configurations are possible, including some interesting things
you can do with remote synchronization using SyncDeK. Other times,
completely different technologies arise as the best choice. I've
even used JSP/FileMaker in one case, because it fit in with the
existing infrastructure. I used to do a lot with PHP/PostgreSQL,
Witango/FileMaker, Tango/Oracle, PHP/Oracle, and even JSP using
a dynamic text file for a data source!
All of these technologies are rich, full featured languages, well
proven, with all modern programming constructs. There is no issue
of "trusting" one and "mistrusting" another,
which makes one of my detractor's comments just plain silly. Anything
you need your site to do can be delivered just as well using practically
any technology. There is never any need to ask "Can this be
done with Lasso?" or "Can FileMaker support a shopping
cart?" Of course they can - anything can - there are far more
substantial considerations that the knowledgeable developer with
foresight needs to be aware of.
Keep platform religion, personal bias, and inexperience out of
the equation. Often, a developer is thrust into the role of product
manager, as many consulting clients lack a staff member with the
proper expertise. When this happens, be up to the task. Bring an
unbiased eye to a project, look at the big picture, and make the
right decision for the right reasons.
|