CIPS Connections

Widely Respected Development Authority and PHP, MySQL, Apache, Internet-technologies Expert
Interview by Stephen Ibaraki, I.S.P.

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.

 

CIPS Connections | Archives | Search