Slashdot Mirror
What Are Good Web Coding Practices?
brink asks: "Recently it's seemed as if, due to larger and faster computers, lean and mean code isn't such an issue. However, it occurs to me that there's an overlooked area where there's little or no mention of the importance of efficient code: Web sites. This isn't so much in terms of HTML (I know that webmonkey had an article about efficient tag layout), it's more in terms of Perl, PHP, or whatever. It seems to me that the fact that your code has the potential to be executed in thousands of instances concurrently doesn't impress on anyone the necessity for uberefficient programming. Dynamically generated pages and DB querries are good examples, or just plain memory usage of your code. So my question is as follows: are there any good works to read which focus on programming for the Web, as in avenues the programming medium affords? Have I just been oblivious and missed them?"
In most cases the easiest thing to do is simply buy more hardware and replicate. This is easy to do if you're serving up static (or even dymamic) web pages that don't need to share any state across multiple web servers. This is feasible because in many situations the bottleneck of the site is the web server and dynamic page generation itself, not access to the back-end database. For really large sites, a replicated/clustered database is going to be needed, not just a single machine running MySQL.
The Application Server industry has started to provide some solutions for building scalable web sites -- for example, IBM WebSphere, BEA WebLogic, and other systems provide a platform for building web-based applications, which generally consist as a middleware layer between an HTML/presentation 'front end' (i.e., a web server) and a database 'back end'. These middleware systems support replication and clustering to increase efficiency. Replicating the front-end web servers is easy, and many products support this. You can even buy fancy network switches which load-balance HTTP requests across multiple web servers. Replicating the back-end database is much harder, but that's how companies like Oracle earn their money.
Not surprisingly nearly all heavily-loaded Web sites have to do a huge amount of work to get all of this working right. One thing you might ask is whether the process of building a scalable Web site could be made simpler. That's the goal of the research project I work on at UC Berkeley, called Ninja.
Matt Welsh, mdw@cs.berkeley.edu
There are books written on how to optimize code in general:
-Code Complete by Steve McConnell, Microsoft Press
-Writing Efficient Programs by Jon Bentley, Prentice Hall
-Flooring It: The Optimization Challenge by Michael Abrash, from PC Techniques 2, no. 6 (February/March 1992)
But code tuning can have varying results under different languages and environments. A lot of people seem to think that code optimization is unstable and difficult to maintain.
There is sometimes a difference between "efficient code" and "good code". Code may be efficient, yet hard to read and maintain.
To know what techniques are the best, a lot of experimentation is in order. It is also a good idea to become part of a community of experienced web developers, and learn from their experiences.
The greatest boost in performance I have seen in my web experience has come from using the mod_perl module for Apache, not necessarily because of anything I did in the code itself.
In dynamic sites the bottleneck is generating the content (running servlets, accessing databases, etc.), so it makes sense to optimize there. Unless your pages is /really/ complex, or the browser /really/ stupid, rendering time is negigable. And in any case, you can't do much about it even if you /do/ have the best code. Pure HTML just isn't that much of an issue. Moving into XML and XSL, and DOM manipulations, though, client-side performance may become more of an issue.
It's 10 PM. Do you know if you're un-American?
I've always like Phillip's Greenspun's ideas on web development. In a nutshell, he preaches reliable and efficient code/tools. He can be a bit biased but mostly his ideas are good (according to me).
His book is available online for free.
That which does not kill me only makes me whinier
That's so true.
My old company assumed that just because someone was a "web designer" and maybe knew a little javascript, they were qualified to do programming on complex web sites (e-commerce, etc.) They're not anymore qualified to do database work than any old artistically inept programmer is qualified to design a new logo for a company.
Companies need to wake up and realize that it takes two types of people to build the web: "real" programmers, and graphic designers. Of course some sites only need one or the other, and some people are talented enough to fall into both categories... but don't assume that Joe the Graphic Designer can code a linked list or a SQL statement...
OtakuBooty.com: Smart, funny, sexy nerds.
As far as HTML on a page, I found that you should optimize for Rendering Time, which isn't always the smallest page, esp. when it comes to tables.
For server side programming, unless every page is generated dynamically, you should program it the easiest way possible and throw some CacheFlows in front of it.
Of course, since most of the people selling themselves as "web programmers" are undegreed kids with little formal knowledge, there's a lot of crap floating around. Until employers value experienced professionals with the proper credentials (instead of thinking that every kid with green hair and a stud through his tounge is a web expert), there's little hope for a standard of quality on the web.
--- Speaking only for myself,
However, some specific things I can think of are:
Seperate out HTML/text and code as much as possible. Ideally, there should be no, or almost no, HTML in the code. This makes life easier for the HTML designers, and also means you get bugged less to alter the code to alter the output.
Make it as simple/easy/reliable/quick/painless as possible to stop/start any server processes. I've worked on a project where we had a perl process, but stopping/restarting had some unpleasant side-effects, meaning we had to restrict doing such an operation to the quietest hours.
Make sure you have a good and accurate test environment. Having some tools to help you debug the running site itself is very usefull - retesting doing a whole load of operations by hand is very labourious.
Test and code for both availability and scaleability. You want good resiliant code with minimum service downtime (which means using reliable OSs and development enviroments - don't just choose the latest).
Make sure you can say "no" to the management. You *will* get PHBs trying to force new features on you when the current ones aren't even working right yet. Make sure your code is flexible though as it'll be changing/evolving a lot anyway. Also make sure you don't get stuck doing fire-fighting - ie stamping out so many little bugs that you can't fix the fundamental problems. (this is the kinda problem M$ has with it's code development...)
Personally, I wouldn't say that C, C++, Perl and PHP promote good programming practices. Java's certainly much better here. I'm not sure about other development environments. (don't worry about server side Java's speed as on a good server, it'll be close to C/C++. I'm not kidding.)
Most scripting languages like Perl or Python need to be compiled into bytecode, and then executed. The overhead of compiling the program every time it is executed can be quite a burden, especially for applications like CGI programs where the program is started very frequently but runs only for a short time.
/usr/bin/perl for each hit. Again, this becomes significant once you start getting lots of hits.
Even if you can cache the compiled bytecode (as Python does), there is still the overhead of starting
The best thing you can do is use something like Apache's mod_perl which avoids the overhead of starting a new perl process for each page, and also the overhead of compiling the program each time. Similar features exist for all popular scripting languages and Web servers.
Once you've done that, you may find that there are other startup costs you can factor out. For example, does each hit make a new connection to the database? Depending on your application you may be able to get away with some sort of local cache, either on disk or cached in memory in some way.
Finally, you can make your site faster to _use_ and save the user's time if you make your pages appear gradually. If you're churning out a long, complex page, try to make it appear as it is computed, so the user can start reading immediately. This is partly a matter of choosing layout that web browsers can render incrementally, and partly of how you write your program. (Slashdot's comment display, at least in Minimalist Mode, is very bad at this. In Netscape 4.x you have to wait for the whole 100Kbyte or so before seeing any of it.)
-- Ed Avis ed@membled.com
Yes, it is more expensive. But, many companies are racing to be the first for survival, and they have been blessed with enough VC money, so that it is irrelevant that it takes hundreds of thousands of dollars to pick up the performance. Time to market is much more important, and having programmers spend time performance tuning takes away from that.
One clear example here is Java vs. C++. Sure, Java is much slower than C++; but developing something in Java takes orders of magnitude less time than in C++. So, it is better to throw money at hardware to cure the performance problem, but will get you to market sooner, than code in C++, which results in faster code, but takes much longer.
Of course it's not quite this simple. You can't just throw hardware and money at every problem. Obviously your application can't be so slow that no one will use it. And key performance problems are first at the high architecture level, which are mostly language and platform independent. You will always have to spend time performance tuning at some point. But initially---even long term---time to market is more important.
----------
In a real emergency, we would have all fled in terror, and you would not have been notified.
I went through so many hairstyles, fashions, music trends, the occasional piercing and tattoo that my family started referring to me as Rodman a number of years ago. However, I've been writing code for 16 years now. And I'm good. I'm good enough that now I also get to see the streams of applicants coming in and get to decide whom to hire and how to put together the teams.
Get this straight:
If I get a group of "green-hair"s in, I'll hire the ones that can code, work together, and who won't steal from the company.
If I get the GH's and some poindexter's, I'll hir the ones that can code, work together, and who won't steal from the company.
If I get a group of poindexter's, I'll hire the ones that can code, work together, and who won't steal from the company.
Part of the problem in hiring is knowing whether or not the prospective (green haired or not) can code, work with others, and won't steal from the company. Your credentials, I'm afraid to say, are what get you in the door. [ If you know someone who can recommend you, that can get you in the door as well, but I really consider that a social credential more than a side-stepping of the system. ] If you've never done anything productive, you could very well be the best programmer in the world, but you've never worked on anything. This means (to me) that you probably don't know how to work with people, or how to pursue joint code development, or what deadlines are, or why tasks are prioritized, etc.
A degree, certification, or award, is an indication that you have completed some structured program designed to increase or test your assimilation of a body of knowledge. Are there people with the proper certifications who aren't qualified to work in this industry? Certainly. Are there people with the proper certifications who are able to work? Certainly. Are there people without those certifications who can do the work? Certainly.
So, certifications are worthless then. Bullshit. Like I said before, they are an indication of completion of a structured program. Given two applicants for one position whom I judge to be of equal capability, willing to work for the same pay, I'm generally going to hire the one with more certification -- primarily because I know that person is more likely to be able to work under deadlines and prioritized sets of goals.
Similarly, given a set of qualified applicants (can do the work, can work together, won't rob us blind, have the same relative qualifications) and too few positions, I will often favor the applicants who put the most effort into applying: well written resume/cover letter, well-dressed, punctual, polite, aggressive (no there's no contradiction there), excited, motivated, etc. These people are more likely to work hard, stay with the company, act on their own initiative, and so on.
The perceived tightness of the job market (and, actually, it's not quite as tight as has been made out) has brought to the average technophile an attitude that not only are they in high demand, but also that their intrinsic coolness, which derives from often dubious technical ability, is a substitute for proof of ability. Only one component of employability is technical competence, the other more important ones include social maturity, dependability, commitment, responsibility, ambition, and respect. Some will certainly whine that technical ability is the most important, but in this day (contrary to what many of you seem to believe) that's simple to find. If that's all you have, you lose out, because the next person in the door has the others too.
"Cause there's 40 different shades of black, so many fortresses and ways to attack, so why you complainin'?"
Check out Philip and Alex's guide to web publishing. This the book you were looking for?
o/~ Join us now and share the software
Some techniques that are essential to web development are:
Often, the speed of the web is, in reality, how fast the pages appear to be. This is the most important thing to remember when designing pages that are supposed to be fast.
darren
Cthulhu for President!
(darren)
I don't know of any books, but here's what I do...
I work for a fairly large software company and we use a Linux/Apache/MySql system to dynamically track and record our production. This database/machine is getting hammered on the backend (data importing) and on the front end (our web/perl interface).
How do we tweak this datatabase to run 5 different programms and still output 1.5 million transactions a day on a 200Mhz machine with 32Mb of ram?
Efficient code!
Nothing different than you would do with your C code, just use smart programming. With perl, use the 'strict' module. Always destroy database handles as soon as you can, don't try to do complex sorts in your code, that's something the database is capable of.
Static if you can...If there is a page on your site that doesn't change very often (ie. it chagnes less than half the amount of times that it is accessed per day) generate it with a server daemon, and then let users access it has a regular html file. This saves CPU time and decreases latency of accesses.
A lot of the web programming starts with good database design. There are countless books about this. If your databse is optimized so that there are no full table scans and relationships are tightly bound, then writing efficient code is fairly simple.
Overall, just keep it simple and efficient.
I am a professional PHP developer and I personally put quite a bit of thought into the code as I write it. I think a very good set of articles which help with the problem you mentioned, at least from one angle, are the Cached Dynamic Module articles at php builder.
Don't moderate this as a Troll or a Flame, I write in Perl most of the time myself. But I've recoded some stuff and tested it, and blew the doors off.