Careers: Interviews
Widely Respected Development Authority and PHP, MySQL, Apache,
Internet-technologies Expert
This week, Stephen
Ibaraki, I.S.P., has an exclusive interview with the top-ranking
development authority, Julie Meloni.
Julie Meloni is a
recognized expert in PHP, MySQL and Apache, and virtually every
Internet technology. Julie is a "jack of all trades" who is able to
explain and inform on myriad topics.
She has more than eight
book credits including the highly regarded, Sams Teach Yourself PHP,
MySQL and Apache All-in-One. Her articles on programming, security,
and related IT-topics have appeared with Hotwired's Webmonkey, ZDNet
Developer, CNet Builder.com, and CNet Linux Center. As an example of
the popularity of her work and her top-standing, Julie's books have
been translated into numerous languages: Danish, Finnish, Hungarian,
Italian, Greek, Polish, Portuguese, Russian, Serbian, and
Traditional Chinese.
Julie has been Technical
Director at i2i Interactive (www.i2ii.com)
for the last several years, where she is responsible for development
projects ranging from simple web sites to complex applications.
Prior to i2i, Julie was a Technical Writer for numerous companies
ranging from Sun Microsystems to Capital One.
Discussion:
Q: Julie, you are a
leading authority on Web development. Thank you for taking the time
to speak with us.
A: Thanks for inviting me
to participate.
Q: You have an English
degree and yet you are in computing—interesting! Give us a life
history—explain how you got into computing and your journey to your
present position? Why are you currently working on the MA in
linguistics?
A: I just turned 30, so
I'm not one of those folks who can tell stories about the merits of
punch cards and "the good old days"…but I'm also not one of those
highly-wired kids who has every gadget known to man. When I was a
teenager, I liked my Atari, I liked my Commodore 64 and my TRS-80,
and I thought Btye Magazine was the greatest thing. But I also stunk
at math and therefore assumed that computing wasn't going to be my
lot in life. So when I went to college I opted for the path of least
resistance – I read a lot, so English it was. I typed my senior
paper on a typewriter, and it wasn’t until I went off to graduate
school that I got a very heavy but very cool Compaq 286 laptop and a
stylin' 1200 bps modem. I lasted about six weeks in graduate school,
until I realized that it served no purpose for me, and that there
was something to this new Internet thing (it was 1992). After about
a year of doing odd jobs unrelated to computing but doing a lot of
communication via that precious 1200 bps modem, I met some people in
California who said that maybe we should look into this whole Web
thing. That was about 1994 and creating Web applications meant that
Perl was your friend, you did a lot of banging to make things "go",
and you had to explain to the creative folks that they had to change
their thought process because so many things just did not work on
the Web.
I did that for about 4
years until I just couldn't stand it anymore – I have a big problem
with wasting things like time and money and other resources, and in
the late 1990s in Silicon Valley, Web development firms were getting
paid outrageous sums of money to produce the silliest, most useless
products, and I felt crappy about it. So I stopped working in Web
development and did technical writing for a few years. I've always
been the type of person that, if I could use it, I could write about
it, from the ground up and from the inside out, so that served me
well. Around 2000, all the money dried up and writers were always
the first to get cut, so I went back to application development and
here I am.
As for the Linguistics
thing, I certainly didn't plan it. In California, we're blessed with
a decent (and cheap) system of community colleges and state
universities. I was having a big problem (again) trying to figure
out why the managers and executives, who make up our client base,
were making certain business decisions. For example, I just can't
fathom why people will pay scads of money to go down a convoluted
and non-recommended development path just to backtrack and re-do a
project, instead of spending a few moments actually outlining
business rules and system requirements ahead of time. So I decided
to go to business school to see if it was something they were
actually taught to do (they're not). While taking business classes,
I saw that my school (San Jose State University) offers a
certificate program in computational linguistics. I thought it
sounded incredibly interesting, so I started taking classes and
decided heck with the certificate, I'll try to do a master's degree.
It has no bearing on my job; it's just for my own personal
gratification. Education is a good thing.
Q: You have an impressive
background with so many technologies. Can you share your top three
“amazing or surprising” experiences?
A: I don't really have
any. My job entails finding the best solution to the problem posed
by the client. As such, I can't in good faith use bleeding edge
technology or any early-early-adopter stuff just because I think it
might work – I have to know that it WILL work. In other words, I
have to use tools that specifically don't cause surprises!
Q: You have done a lot of
writing: contract technical writing (Sun, Capital One), valuable
technical articles, and highly recommended books. From this
background, do you have any humorous stories to share?
A: Not to sound like a
completely uninteresting dolt, but I can't really think of any.
Working in application development and writing about it when asked
is just what I do for a living. I don't particularly take great joy
in it, but I know that I'm good at it and my clients/readers like my
work. That's good enough for me. In the late '90s, we all worked
very hard for things we believed in, worked for free for companies
we thought had good products, and essentially killed ourselves for
our jobs—to get them and to keep them. Personally, it didn't get me
anywhere except in debt, while others made scads of cash. So now I
have a terribly jaded outlook on the whole things – do your best
work, do it on time and keep your clients happy, but find your joy
elsewhere in life. I make time for watching sports, going to school
and volunteering with the Literacy Center at the San Jose Public
Library. It's in those aspects of my life that I find amazing,
surprising and humorous things—and people.
Q: You pick three topics
from your extensive work experiences and writings. Please share
three “special and very useful” tips in each topic area.
A: Area - Project
Management
1) To Programmers – it
really is important. It may seem like the most annoying,
time-wasting process to go through, but it really is necessary.
2) To Managers – listen
to the programmers' input during meetings and the planning stages of
a project. Don't assume that programmers don't understand business
rules. You may find that the programmers are equally adept at
discussing and defining business concepts as you are, and they may
have a fresh perspective on things.
3) Be realistic in your
timelines. Rapid application development does not mean "do
everything really quickly and cut corners".
Area - Database-Driven
Web Sites
1) If you are tasked with
creating a database-driven application and don't know the meaning of
the phrase "database normalization", stop immediately and learn
about it.
2) If you're creating a
dynamic site, conceptualize what it is that you're telling your
script to spit out, especially if it's in the form of a table.
Tables have rows and cells, both of which require end tags to be
closed and blank spaces to be accounted for. Your scripts should
account for all possible output; else you will have wacky looking
tables.
3) Programmers, try to
play nice with the creative team. They may never grasp the concept
of dynamic sites, but if they give you a set of elements to work
with, make them work.
Area - Documentation
1) Programmers – do it.
If you can't document your code or the logical processes behind it –
and that doesn't mean write beautiful prose about it, although
that's helpful – you may want to consider the validity of what it is
you're coding. That may sound harsh, but if you can't explain it,
why should the person paying for it trust you?
2) Managers – pay for it.
Documentation is not something that programmers account for when
they say it will take 20 hours to write your little app. If you want
documentation – and you should – tell them the 20 hours is great,
and you'll give them 2 or 3 extra days to write the accompanying
documentation for it.
3) A dedicated Technical
Writer is an important part of the workforce. When hiring one,
understand that it is possible that the interviewee was actually a
programmer or a database engineer or something else along those
lines and simply got burned out by the whole thing – or their jobs
were downsized. In other words, they're technical people who can
also write well. This is quite different than the people who can
write well but aren't technically-savvy. The gaps between the two
groups are very quickly closing, and that's a great thing for hiring
managers, but the bottom line is not to pre-judge people; just
because they're applying for a job writing user guides doesn't mean
they can't build the application, too!
Q: Can you describe your
work at i2i?
A: We are a very small
company – there are 4 of us. All of us with "director" in our title,
we basically direct ourselves. The people I work with are the ones I
originally worked with when this whole Internet thing started up 10
years ago. In '97 they formed this company, and when I felt the need
to get back into technical things, I came back to work with them. We
all have essentially the same principles when it comes to design
methods, usability, project management and so forth, and we all have
the same general opinion on how to do our work – work hard all the
time for the people who are paying you, don't miss a deadline, give
your clients the best possible product. This company weathered the
ups and downs of working in Silicon Valley just fine, because our
clients stuck with us because we treat them well. We have Fortune
100 clients in high tech, and we have schools and non-profits in our
client list. Everyone gets charged the same rate and we don't price
gouge; if you have a budget, we will do everything in our power to
keep our clients under the budget. The tradeoff is that we never got
rich, but we sure can sleep at night.
As to what I actually do,
it really is everything technical. If a client wants to create some
tool that does X, we lead them down the path of planning and
business rules and decision trees and things of that nature until we
figure out what it is that they really want. Then, I go build it and
our creative director makes it look colorful. Basically, anything
that goes on a server, I'm responsible for, including the
configuration and management of the server itself. I'm the sysadmin,
the coder, the database designer, the documentation person, etc.
Doesn't leave much time for anything else.
Q: Your recent book,
“Sams Teach Yourself PHP, MySQL and Apache All-in-One” has been
garnering considerable attention. What makes this book so
interesting and valuable? With so many books on the market, how is
it different from the “other” books? Who is the intended audience?
A: The intended audience
includes those who know what each of the technologies are, but have
never used them. Or, they've used them but maybe are self-taught and
need gaps in their fundamental knowledge filled in for them. My
books are never for the advanced user, or to some extent even the
intermediate user. They are always foundation-level books. That's
not to say they're "dummies" books or "idiot's guides" – neither of
which I'm particularly fond of. They're simply well-thought-out
guides to developing a solid and broad foundation for working in
these technologies. That's why there can be database normalization
tips and system administration tips happily coexisting near a guide
to the thought processes and code necessary to build a discussion
forum. None of it is hard stuff, it's just really important.
I think that people like
my books because I write how I talk, which is like a normal person.
My books aren't written like a computer science textbook, where
you'll want to fall asleep 2 pages into the thing. I get negative
comments from people with a great deal of computer science
background or who are advanced users of various technologies who –
for whatever reason – pick up my books and then say it sucks because
it doesn't talk about X or Y or Z or because it uses "common"
language to explain how to do something technical. That sort of
thing really bothers me, because for one, descriptions clearly state
that these are foundation books, and esoteric things that even I
have never encountered in all my years of building applications …
now why exactly would I put those in my books? Secondly, there's no
rule that says you have to use technical terms to explain technical
things. If the person trying to learn a subject knew all the
technical descriptions for the subject, I'd hazard to guess they
probably already know what they need to know. The point is to get
someone to learn something, to truly know it, and that comes from
teaching it clearly, from the ground up.
Q: Share five of your
high-powered tips about installing, configuring, and setting up the
PHP scripting language, the MySQL database system, and the Apache
Web server on a Windows or Linux-based system.
A: These aren't
particularly high-powered, but here are some answers for you…
1) Read the instructions.
Seriously, you wouldn't believe the number of people who stumble on
the first chapters of my books (invariably the installation
chapters) because they simply do not read the instructions. If you
don't read my instructions, then read the "how-to's" and the
readme/install files that actually comes with the software. It's a
huge pet peeve of mine—I used to answer literally a hundred queries
a week from people on this topic, and my response would contain a
pointer to the exact paragraph on an exact page that showed the step
they missed. I would get back a note that said "oh, I didn't read
that chapter." Sort of begs the question "why not?" But anyway,
installing these technologies together could not be easier, if you
follow the very linear method that is presented and pay attention to
the notes specific to your operating system, should it be Windows.
2) Understand how the
technologies work, on their own, before you try to make them work
together. For example, Apache is a Web server and MySQL is a
database. They have nothing to do, directly, with each other. There
are no installation instructions in any book of mine, or manual I've
seen that has anything to do with "configuring Apache to use MySQL",
simply because Apache couldn't care less what database you use, and
MySQL doesn't give a flying fig what Web server you use. This is
another example of a question I get from people who are new to all
this – and it's great that they're buying my book to try to learn
something – but I don't want people to buy my book unless they have
a fundamental understanding of these technologies themselves.
3) Feel free to use all
of these technologies on a Windows 98 system, as long as it's only
you using the machine, locally. PHP, Apache and MySQL install
without a hitch on Win98 machines and it's a wonderful way for
newbies to set up a test environment on a machine in their home or
office to "play" with. I think my record for installing PHP, MySQL
and Apache on my Win98 machine, from downloading all three bits of
software to actually running a script, is 9 minutes. Not an arduous
process, but for the love of god, don't use that machine in
production!
4) When the instructions
say not to run processes as root, don't. It's not just a suggestion,
it's more like a commandment.
5) Pay attention to
changelogs. The developers of PHP, Apache and MySQL do a wonderful
job of documenting even the tiniest change, from version to version,
and minor versions are released all the time because these are three
very diligent groups of developers who have produced three amazing
products in wide usage. If they change the functionality of
something, it's usually for a very good reason, and you should see
how those changes will affect your scripts and your environment
before you upgrade your software.
Q: What are the best ways
to interact with MySQL using PHP?
A: The PHP Development
Group has made this process incredibly easy, by creating functions
for almost anything you would ever want to do directly in MySQL. In
fact, that goes for any database you want to use with PHP; there are
a ton of Oracle functions that work just great, too. The most
important aspect of communicating between PHP and MySQL is
understanding what you're actually doing when you use those
functions. You use PHP functions to open a connection, select a
database to use, send a query, retrieve the results, loop through
the results if there's more than one record returned, and so forth.
The functions are great, but if you don't know why you're doing each
step, it's sort of a waste.
Each of my books contains
a general SQL primer, to varying degrees depending on how much space
I could use, and I also wrote an entire beginner's book just on
MySQL. There are a lot of developers who have to do it all—create
the application and the database that drives it – and the database
often suffers. There's a reason that entire jobs in the enterprise
are devoted to being "the database person" – it's a different job
than being "the coder". Nowadays, since a lot of coders also have to
be the database person, if they don't have a fundamental knowledge
of databases and are just doing things on the fly, it's likely the
database isn't going to be as well-designed as if the dedicated
database person were doing it. So, I put as much of the database
fundamentals into my books as I can, for those situations.
Q: Discuss working with
forms and files.
A: You're going to note a
theme here, but users first have to understand what it is that
they're doing. I don't mean to break it down so simply, but it's a
spot that people just don't seem to "get" – I think a lot of people
pick up a book and expect it to tell them exactly what to do in X
situation. While my books do that to a certain extent, the goal of
my books is to teach the thought processes that go into situations,
and how to use that knowledge to solve a problem. In the case of
working with files, you first have to understand is that you are
using a script to issue a command that you would use in the shell.
Or in the case of Windows users, you're issuing a command that
equates to dragging or clicking or something along those lines. As
such, the rules for issuing the commands are the same as if you were
doing the things yourself – if you want to replace or delete a file,
you (in this case, the user under which the Web server runs) must
have permissions to make such changes. Same with creating and
writing to a file – if you don't have permissions to open a file and
write to it in the path you have designated, then it's not going to
work. So, knowing basic system administration is important.
As to working with forms,
there's nothing special there. You simply create the front-end of
the form using your HTML knowledge, and the "go" part of the form
can then do whatever it is you want it to do with the variables that
will be sent. It's pretty limitless.
Q: How do you create a
Web-based discussion forum or mailing list?
A: Creating a forum
requires an understanding of the logical hierarchy that makes up a
forum: forums contain topics, topics contain threads, threads are
lists of posts, posts can reply to one another or remain
independent. From that viewpoint, it's simply a set of forms and
display mechanisms that show what should be shown, depending on the
step you are looking at. The chapter in my book that talks about
creating a forum is primarily about the logic of it and how to
normalize the database tables; the actual scripts that are involved
are extremely simple.
The section of my book
that talks about using PHP and MySQL to run a small mailing list is
there as an example of how some processes work and isn't presented
as a way to really do things. If you have more than a hundred
addresses or so, then the mailing list should be run using some form
of mailing list software like majordomo or slist or
name-your-favorite-mailing-list-software. In my book, subscribing
and unsubscribing to a list and then sending a message to a list is
used as an example for looping through results from a database query
and doing something with each result (in this case issuing a mail
command).
Q: What are the important
details behind adding a storefront and shopping cart to your site?
A: Planning. As with
creating a forum (or anything, for that matter), you just have to
break it down into parts of the whole. A store is just a bunch of
categories. Categories contain items. Items have descriptions and
attributes. Create your database tables properly, to hold all those
related entities, and you're set. The shopping cart is simply a list
of items attached to the user, with selected entities for each item.
For example, an item could be a red XL sweatshirt or a black leather
carrying case. Entities come from a well-formed database table and
are saved in another well-formed database table that just makes the
code for retrieving those elements so much less convoluted.
Q: How do you optimize
your MySQL databases?
A: An out of the box
installation of MySQL barely needs any tuning. The installation
contains some pre-determined configuration files you can choose
from, depending on your server environment (lots of memory, not so
much memory, shared server with other applications and so forth). I
rarely have to modify anything in my MySQL installations, just
because the thing is so darn fast already. But that's the software
itself, which is only as good as what you put in it – in this case,
databases and tables. Normalize, normalize, normalize! The best way
to optimize your database-driven application is to put some thought
into optimizing the tables that contain your content
Q: Discuss the major ways
you can fine-tune the Apache server’s performance.
A: My tips are pretty
basic – turn off what you don't need, only add what you do need.
Apache isn't a piece of software that automatically has every
"feature" turned on and then requires that you take days and days to
trim off all the excess. When building Apache, there's no rule that
says you have to include every module ever written for it.
Q: How would you restrict
access to your applications?
A: Depends on what the
client requires. If it's a blanket user/password, I'd probably use
Apache-based authentication just because it's quicker and will save
them money. But if there's any need for customization then usernames
and hashes of passwords are stored in a simple table and all things
dynamic flow from there.
Q: What are your main
tips for setting up a secure Web server?
A: Actually purchasing a
SSL certificate is key. That certificate should match the hostname,
and be from a valid certificate authority. Generating your own,
self-signed certificate for a hostname that doesn't match the one
I'm navigating sure won't make me want to give you my credit card
information.
Q: What three additional
“surprising” coding bits can you share?
A: Three is a lot in an
area where surprises are generally bad… but one thing I put in place
did surprise me and make me chuckle for a moment. Currently, our
largest client (by volume of work) is iPass Inc., a company that
provides software-enabled enterprise connectivity services for
mobile workers. Among other things, we built the underlying
architecture of their public web site and the content management
system that controls it. Not a big deal, except that it's also
localized – there's German, Japanese and Chinese content as well as
English. Again, not a big deal if you have some insanely expensive
servers and proprietary software and other sticker-shock items. We
don't use those things unless we absolutely have to; the iPass site
(www.ipass.com)
is purely PHP, MySQL and Apache – out of the box, very little
modifications to any configurations. The surprising bit has to do
with the storage of single-byte and multi-byte languages in the same
tables, which was not supposed to be possible with the 4.0 version
of MySQL and in fact is a feature slated for the 5.0 version of
MySQL, which just recently had its first alpha release. Well, we've
been administering this content through the management system we
built, without a single hitch, for over a year now. We saved our
client I don't even know how much money, and that was a good thing.
All is stable (knock on wood).
Q: What future books can
we expect from you?
A: Whatever Sams wants me
to write, I'm all for doing as long as there's a market for it. I am
not currently under contract for anything right now, although I
recently submitted a proposal to write a book on Plone – which I
think is an interesting and well-built application.
Q: What are the most
important trends to watch, and please provide some recommendations?
A: I don't spend any time
watching things anointed as "trends" by the media. For example,
apparently Linux is a trend. I find that funny, because I just
thought it was a really stable operating system that I've been using
for years. Good to know it's trendy now.
Anything I would say
here, I'm sure your readers would say "no kidding"… but I'd say look
for a big ramp up in natural language processing tools and things of
that ilk. Hopefully whatever technology is being developed for use
by various government agencies can also be applied to educational
uses, such as for augmentative/alternative communication and
assistive technology software and devices.
Q: What are your top
recommended resources for both businesses and IT professionals?
A: I don't do a lot of
reading, period, let alone in this area. I used to read all the
sites and magazines that I was "supposed' to read – CNet, Wired, all
those types of things – but at some point all the stories were
geared toward whomever paid them the most to write about things. Or,
they were filled with stories by people trying desperately to find
and promote the Next Big Thing for their own benefit, regardless of
what it was or if it would ever be useful. Since I'm nowhere near
rolling in dough, I could never buy any of the cool toys or try some
new gadget, or even purchase a bunch of machines and load suites of
software on just for kicks. So, I don't read a lot of those types of
resources. If I want to poke my head up and peek into the true geek
world, I'll read Slashdot for a few days and learn a bunch of new
things. That's good stuff.
Q: What kind of computer
setup do you have?
A: Nothing special at
all. I work from home, and I live in a small place, so my kitchen
table equals my workspace. I have a Gateway Profile machine, one of
those all-in-one deals, and it's served me well for a couple years.
I still run Win98 on it because it's just easier to deal with and I
don't tend to upgrade my Microsoft operating systems until I'm sure
the darn thing won't crash every 10 minutes. I probably won't get a
new machine until I've worn this into the ground, but that doesn't
mean I don't covet a nice laptop with display. My rackmount servers,
I build those myself from parts I get at the local computer supply
store. My $500 servers have the same features as the $3000 servers
except the pretty stickers and the streamlined rackmount cases. I'm
not one to spend an extra $2500 for streamlined anything, so we save
a lot of money there. All my servers run SuSE Linux and I spend most
of my time connected to the machines via SSH from my plain ol'
Windows machine. No muss, no fuss.
Q: If you were doing this
interview, what three questions would you ask of someone in your
position and what would be your answers?
A: Q1: Who deemed you an
authority in anything?
A1: I don't know. It's
not that I don't have a positive opinion of myself, because I do,
but I don't throw around praise and titles. I'm just good at what I
do, and I do my job really well. So do a whole lot of other people,
like our creative director for example, or my boss, who juggles all
of our clients and our workloads so that everyone's needs are met.
The guys in the PHP Development Group, the guys at Zend Technologies
and in the Apache Foundation and those who work at MySQL AB, those
guys are experts because they're actually building the technology
that I use. I just implement what they create, and boy have they
done a heck of a job.
Q2: So, you have no
academic background in anything technical?
A2: That's correct. Not
to say there isn't value in computer science degrees, because there
absolutely is. But there are also a lot of things you can learn on
your own, and there are also a lot of things of great importance in
today's working world that aren't even taught in computer science
curriculum. For example, project management and systems analysis and
design is typically taught in the Management Information Systems
department of a business school. This is unfortunate because you
sometimes get business school grads with little technical knowledge
but this wonderful analysis and design book that they can't use, and
then you have computer science grads who can't function in a project
planning meeting. Cross-disciplinary study is your friend. If it's
not built into your curriculum, seek it out and learn on your own.
For hiring managers, be careful not to filter so strictly on the
"must have a Computer Science degree" criteria, and actually look at
the rest of the resume. I can't tell you the number of jobs I'm "not
qualified for" on paper, but that I could with my eyes closed.
Q3: What do you want to
be when you grow up?
A3: A teacher. I really
want to just teach reading and composition to college kids, or ESL
learners. But that can never happen until I pay my debts and live on
a teacher's salary. I think it's terrible that teachers at all
levels of education make about a third of what some schmuck like me
makes, and they're actually shaping people's lives.
Q: Do you have any more
comments to add?
A: Just thanks for asking
me to do this interview, and I hope your readers find it at least
funny and honest if not interesting.
Q: Julie, thank you again
for your time, and consideration in doing this interview.
A: No problem. |