Slashdot Mirror
Best Programming Practices For Web Developers
An anonymous reader writes "Web pages have become a major functional component of the daily lives of millions of people. Web developers are in a position to make that part of everyone's lives better. Why not try using traditional computer programming and best practices of software engineering?"
Best programming practice is to do everything server side and not hijack the CPU of the site visitor; not depend on client-side active compatibility (for instance, just tried to pay for an EBay auction today, wouldn't work, don't use Explorer...) if you do server side processing, you can make it work for *everyone*. That alone is enough reason to go for it. Then there's Digg; Digg's pages are such a load on the visitor's CPU that I have to click "script not responding, continue?" three times on a page with 800 or so comments with Firefox and a dual-core 2 GHz CPU just to get the page to completely render. Sure, some of this is junk programming, not junk technology, but even so, if the server was doing the work of formatting (like it traditionally has here on slashdot), then it'd just be a matter of my browser reading HTML, instead of trying to run other people's scripts locally. I'd give up the web 2.0 "candy" in a second just to have a reliable web page.
Sadly, I know people will typically go for glitz over functionality, so the only thing that will kill web 2.0 is web 3.0, and I have little doubt it'll be even worse. :(
As for leaning towards good programming practices, my suggestion is to start by taking PHP off your server, learn Python (or Perl if you're feeling feisty) and write something that at least has a chance of being reasonably structured. Keeping in mind I'm a huge fan of Python.
I've fallen off your lawn, and I can't get up.
See subject.
The whole idea that you should design before implementation is laughable. So is the idea that programs should be built to last.
The program you write today will be tomorrow's cruft. Better to write cool, flashy apps that keep you at the front of the technology and let the monkeys in the basement cubes figure out how to keep your crap running. It's how you cultivate a good reputation for being a technology leader.
You only live once. Why waste that time writing good code that's going to be thrown out anyway? Write cool code that makes you look good. Make a lot of money and retire early.
"Why not try using traditional computer programming and best practices of software engineering?"
By now, this is -- or should be -- common practice.
Most web developers I know (myself included) have a fair idea of how to do things well. But most web development is project-driven, and once the page/site/app looks and works OK telling management that you need an extra week to refactor things isn't necessarily feasible.
That being said, we all know what happens to maintainability of a big project if done the fastest way possible...
Damned if you do, damned if you don't.
.: Max Romantschuk
Good article, but it doesn't mention anywhere XSLT - quite a major "step" in the giant layered cake that is web dev....which is basically from the bottom:
DBMS + Server-side code, XML, XSLT, HTML/Javascript, CSS
Xslt takes all the need to program & process display logic out of the server-side code, and is completely language independent - making it highly portable. It rocks when you know how to control the beast. You don't even need a server to run it - every browser since 1995 is capable of doing XML+XSLT client-side, meaning a whole chunk of "code" can be cut out from core development.
throw new NoSignatureException();
See subject
1 - Do whatever your client wants you to do.
there is no 2. thats that. your client is your software development customer if you are self-employed or working as a lead developer in a software house, and your client is your superior if you are a programmer employee.
each and any other practice are only valid when you are doing your own personal projects.
Read radical news here
Well, you bring an insightful point into how that goes downhill, but that's exactly what makes me wonder.
Engineering used to be about starting from a problem and figuring out the best solution. Well, best within the limits of your knowledge and abilities.
E.g., let's say you have to get people from A to B across a river. You'd start from that problem and figure out a solution, and not from "but I wanna build a cantilever bridge, 'cause it's the latest buzzword" and find a river in the middle of nowhere. Or dig a canal if you don't have a river for your buzzword bridge.
Then you'd look at the exact data your problem is based on. How wide is that river? What kind of traffic you expect over it? Is there barge traffic on the river that you'd have to deal with?
Then you'd look at the alternatives: do you need a bridge? Maybe a ferry is enough? How about a tunnel under it? If you decided on a bridge, should it be cantilever, suspension, or what? There is no free meal. Each option has its own advantages, but, and here's the important part, also its disadvantages and limitations.
And I think that's exactly what's missing in most of "software engineering" today. People start from what's the latest buzzword, and then work backwards to try to find some problem (even imaginary) to apply it to. They'll build a bridge in the middle of nowhere, in the style of 19'th century follies, just because they want a cantilever truss bridge, everything else be damned.
(Except the 19'th century follies were actually known to be follies, and built as a fucked-up form of social security in times of crisis. The laissez faire doctrine said that it's wrong to (A) just give people unemployment benefits, since supposedly that would have turned everyone into parasites, and/or (B) to use them to build something useful, since that would have competed with private initiative. So they built roads in the middle of a field, towers in the middle of nowhere, etc, instead. Whereas today's programs don't even have that excuse.)
And while it's fun to blame monolythic programs written by monkeys, I'll go and blame the opposite too: people who do basically an overblown cargo-cult design.
(Cargo cults happened on some islands in the Pacific when some supplies were supposedly paradropped to troops fighting there, but instead landed on some local tribe. The aborigines then proceeded to worship the big birds that dropped those, and pray that they come drop some more of that stuff. And when they didn't come back, they sculpted airplanes out of wood, and kept hoping that those'll drop some food and tools.)
People who don't understand what a singleton, or a factory, or a decorator pattern, or a manager pattern are, or when they're used, go ahead and created tons of them just because they got told that that's good programming practice. Everything has to go through layers upon layers of decorators, built by a factory, which is a singleton, registered with a manager, etc. They don't understand what those are or when or why they're used, so they effectively went and sculpted their own useless wooden factory, like the tribes in the Pacific.
So maybe just telling people about some "best practices" isn't everything. Some people _will_ manage to turn any best practice into the worst nightmare. Maybe what's really needed is to remind more people what engineering used to mean.
The same goes for design before implementation. There are places which sanctified the worst caricature of the waterfall model, but again, in a form that actually is worse than no design. Places where you have to spend two years (don't laugh, I know of a team which had to do just that) getting formal specs out of every single user (who hasn't even seen a mock-up yet, and some don't even understand what the techies actually want), then have an architect design an overblown framework that does everything except what the users actually wanted, then get on with the coding, then they have 1 month allocated for tests and debugging at the end
A polar bear is a cartesian bear after a coordinate transform.
"Why not try using traditional computer programming and best practices of software engineering?".
Did you see the straw man? The question assumes we do NOT follow best practices already, and sends us on the wrong path to doing so, having to explain ourselves.
A quick run down of the article: getting requirements, D.R.Y., refactoring, test-driven development. Why on Earth assume we're new to this. Grab any amateur framework for web dev and see what it's about. Framework people's mantra is all about D.R.Y. and even taking it to inappropriate extremes.
But I do use best practices, and I believe many do. Here's the catch: there's no single set of best practices.
On the server side the task, dev tools, and target platform are quite classical, and hence the best practices are similar to classic development (and it's mostly classic development after all, parallelizable task).
On the client side we have several awfully inadequate standards, with several awfully inadequate clients (browsers) that interpret those standards more subtly or less subtly differently, and all of this runs in a sandbox, streamed through the tiny pipe of our site visitors/service users. It's a brand new challenge, with brand new bottlenecks, and has brand new best practices.
And I'd argue still many people get it right for what I see. If you believe you can do better than what we have, by all means don't just talk, but go on and do it.
DUH!
Better practices make for better pages that load faster, have fewer (if any) linking errors, and make minimal use of client-side work.
My office has been taken over by iPod people.
If/when software development becomes simple enough to reduce to a set of universally applicable simple rules, human beings probably won't be needed to do the job.
The best of best practice is to use your experience and knowledge to program in a way to suit the situation you find yourself in. Don't rely on any arbitrary list of 'best' practices to suit your particular circumstances and lead you to a good result. Including this one.
I've had people seriously make that argument to me. Whatever happened to pride in workmanship?
THis story seems quite nice for me. i wonder why http://slashdot.org/firehose.pl?op=view&id=281259 is not yet being promoted by slashdot editors.it is a nice one isnt it? http://slashdot.org/firehose.pl?op=view&id=281259/
Web pages have become a major functional component of the daily lives of millions of people. Web developers are in a position to make that part of everyone's lives better.
I just know there's a porn joke in there somewhere...
"If you think you have things under control, you're not going fast enough." --Mario Andretti
Easy on the Giggle Cream...
--Giggle Cream, it makes desserts funny...
Politics is Treachery, Religion is Brainwashing
i think the idiom u want is "psyched up";-) and i think there are valid reasons to shift the load to the client: sorting tables, 4 instance...it's silly to make another db query to retrieve the same data in a different order.
Traditional projects using so called "best practices" fail with atonishing regularity.
Most project failures are covered up by tha management but in environments such as UK government projects where public scrutiny makes it imposible to spin failure into success the failure rate is about 60%.
In my experience the private sector is just as bad they are just better at redfining success to be whateever crud was delivered, or, quietly cancelling projects and pretending they never happened.
I would also posit that "traditional" best practices are a big contributer to these failures.
Among the many problems:-
1. Analysts paying lip service to user requirements but actually ramming thier own pet vision down the customers throats.
2. Equating expensive with good. Which leads to chosing ludicrously expensive and inappropriate software where something cheap and free would have worked just as well.
3. Dumping existing working software because it is not "re-usable" for a "re-usable" design which doesnt work.
4. Spending eons of time perfecting design documents and diagrams as if they were the end product not just a tool for getting there.
5. Treating all developers as equals. They arent. If you dont recognise and cherish your start programmers you will lose them.
6. Failing to reconise the simple fact that if you dont deliver something by the second year the prohject will get canned.
Old COBOL programmers never die. They just code in C.
Well, I have an entire website that is devoted to answering this question: Free Java Lectures is about that. Specifically, I have a lecture called "Web App Best Practices."
Well, instead of focusing on the programming side, why not focus on the requirements and usuabiliy side for once?
I don't care that you are some 'master webmaster' (ie: I can read learn PHP, Java/Javascript in 21 days..)..but give me a website that is FUNCTIONAL and usable. I don't want or need animated flashing cursors. I don't want or need 500 banners. I don't care about your java crapplet, just let me find the information I want.
Making a shopping website, just have a cart and a checkout button, nothing fancy.
Making an information website, let me search, and use boolean search.
and the list goes on and on...leave your java crapplets at home.
And yes, the 76 in that title is (I believe) an accurate article count. The Cranky User column has gone through something like three developerWorks "zones" and had I think six editors.
:)
It was a lot of fun.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
The most important part of being a Web programmer is knowing how to meet a deadline. Part of which is designing the project schedule, which means designing the product in terms of delivery dates and contingencies. And therefore almost as important is how to notice, and to communicate in advance when a delivery might be late, and by how much.
After learning how to use calendar tech and spoken/email languages for project communication, the rest of the development is relatively easy.
--
make install -not war
In the corporate world, there hasn't been a pure "web site" project since about 1998. I said in my book, "Despite lip service, companies didn't really get off the starting line for enterprise integration until they needed to create dynamic websites. Those projects were the impetus that finally forced many companies to integrate systems that have never played well together."
The place where you need to look for actual software engineering is in the whitespace on the block diagrams. Those innocent looking little arrows that connect the boxes together are the source of most failures and inefficiencies. I've seen one little "interface" arrow implemented with 20 moving parts on half a dozen servers. (Send a message to a queue, the broker picks up the message and appends a line to a file. Once an hour, another broker picks up the file and FTPs it to the "integration server", which then slices the file into lines and uses SOAP to send messages out to a third party.) Talk about failure modes!
Civil engineers consider the loading factors, material strength, and design life of their structures. Together, these constitute the "design envelope" of the system.
Software engineers need to think the same way. How long will this system last? One year? Five years? Two months? The level of demand and demand growth over that time span matters a great deal. An architecture that works well for 10,000 page views a day will bomb badly when it's asked to serve 10,000,000. That sounds like a "duh", but it's ignored surprisingly often.
I could go on and on about engineering systems for real-world survival... but I won't do it here. (Since I already have.)
"Genius may have its limitations, but stupidity is not thus handicapped." --Elbert Hubbard (1856-1915)
Comment removed based on user account deletion
Graceful degradation is quite possible with flash, once you discard those annoying scripts that try to auto-install it (nope. I have already have it thanks, but it's disabled by default - hello NoScript). Content inside the tag will be displayed if the plugin is not available - it's just that most developers can't be bothered to put in anything more useful than a message telling them to get flash.
This is an example of a flash site I worked on that passed WAI level 2. Try navigating it with javascript off.
h1 { font-family: Helvetica, sans-serif; font-size 250% }
h2 { font-family: Helvetica, sans-serif; font-size 200% }
h3 { font-family: Helvetica, sans-serif; font-size 150% }
h4 { font-family: Helvetica, sans-serif; font-size 100% }
should be replaced with
h1, h2, h3, h4 { font-family: Helvetica, sans-serif; }
h1 { font-size 250% }
h2 { font-size 200% }
h3 { font-size 150% }
h4 { font-size 100% }
Then they go on to say...
...while the second isn't much shorter...the second one is actually LONGER and more characters and why do you even need that top line...umm are we not using a font tag in our body?
body, td{ font-family: Helvetica, sans-serif; }
this topic makes sence for PHP, java, javascript, ASP, etc... but HTML is not a programming language it has no logic... no loops.. it's just data storage really...
the one thing I will admit (as a web designer who still makes everything in notepad) is the way web design software makes HTML does drive me nuts... but thats just 'cause I started making websites when the size of your file mattered back in the days of 28.8 k/33.6 k
</rant>
----------
Trying to fix or change something only guarantees and perpetuates it's existence
"Good in theory. In practice, you'll run into managers who get all psyched out at the idea of dumping the workload onto the clients, because they have to pay for the servers and if the servers don't have to do the work, they can handle more clients, while you don't have to pay for the clients, the customer does that."
Well now you know why P2P is so popular. Complete with defenders to the death.
"1. Analysts paying lip service to user requirements but actually ramming thier own pet vision down the customers throats."
Hmmm. Now I see the slashdot obsession with porn. You all are frustrated rammers.
Well, then you've just told me that you're not the kind I was ranting against. You know why you use those, you know about code reuse, and it's just a widget library anyway.
In a perverse way, by what you wrote there, you're the kind of guy who's closer to RL engineering. Much as you seem to be against that comparison.
The kind I'm ranting about would throw that perfectly functional library away, and rebuild it based on whatever the latest buzzword is (let's call it Snake Oil Droplets (TM)), just because they want that buzzword in the app or on their resume. If they can't figure out an existing problem that Snake Oil Droplets (TM) solves, they'll pervert the rest of the design into creating a case for using that.
And I'm not talking about people who just use a library. Using existing components is good. I'm talking people who put some hard work into creating a cargo cult framework... and a maintenance problem for their successors in the process.
I know one team where you could fill a whiteboard just with the _layers_ through which a data object had to go (with factories, decorators and managers at each step) from being read from the database to being actually used. Not just happening to be so because of some third party framework's design. They actually coded each and every line of that bloat. That were some 25 man-years or so, sunk just into coding pure bloat.
That's not the only way to do bad engineering, of course, but it's one example where pointing people at "best practices" can be just a ticket to have them turned in ingenious ways into "worst practices."
A polar bear is a cartesian bear after a coordinate transform.
Very much so, and I can only agree there. Note that that's not a dichotomy _I_ made. That's a reason I called that a caricature. But some places did feel a need to institutionalize just that kind of false dichotomy. Because no design is bad, they'll ask for everything to be 100% specified in detail before it even starts.
Amen.
A polar bear is a cartesian bear after a coordinate transform.
And then there's clients. A lot of web programming gets done either by a consultancy or at least by a programmer who works for someone who isn't a programmer. When you have non-technical people involved too deeply in the process, dumb things happen.
The article talks about things like how easy the URLs are... I had a client for which my then boss made the mistake of bringing up this topic with them, and they freaked out and spent a week coming up with a new naming scheme that was insanely complex (but they thought it was easy) and made for filenames so long that the version control system couldn't handle them. Then they got really angry with us because we brought the subject up and then "refused" to do what they wanted us to. In many situations such as this, I believe it's in the best interest of all involved for the developer to make a decision about how best to serve the site's audience and go with it, because sometimes gathering the requirements just opens up a huge can of worms unnecessarily.
The article also talks about developers anal-retentively making page layouts that control everything down to the individual pixel level of precision, and then if the slightest thing changes on the page (such as the logo) the page layout has to be substantially reworked to accommodate it. This is not abnormal. Indeed, every Fortune 500 company whose web site I worked on insisted on this level of precision, understood the consequences, and was prepared to pay for the time it would take to do the work that way. I worked out reliable methods to quickly and easily lay out a page with absolute precision, with certain reasonable constraints. Any developer working in that sort of environment does the same.
The article complains about building a site to support a specific browser. While I certainly will be among the first to chew out a programmer who builds a site to only work in one browser to the exclusion of others, I believe that it's normal and good to build it to work in a specific *set* of browsers. It's all well and good to say how standards are important and we should all write standards complaint code, except for the minor detail that none of the actual browsers are truly standards complaint as implemented. Oh sure, some are much better than others, but none are really perfect, so if you want to ensure that your site (or application) is going to actually work, the only way to do so is to code it in a way that copes with the known quirks of the various browsers.
Refactoring is a great thing to do when you need to do it. However, I try to design my software for scalability up front when possible so that I don't have to do a lot of refactoring down the road.
-1) Do not talk about web programming.
:(
0) Do not talk about web programming.
Ooops. I think I just generated an exception.
The one thing in web design that pisses me off more than anything else is when a webform is loaded, and the first, topmost, and obvious field doesn't automatically get the focus to type in. So, the hand goes back off the keyboard to the mouse to click in the box, and then typing begins or resumes. ;-)
It's a really stupid thing that affects ergonomics and workflow, but its so easily correctable. I think it's just lazy web development.. even lazier than me for having to move my hand 12 inches to the right and back.
Look back up at my post, now look back down, you're on the Internet. Now look back up. I'm a signature.
Because every generation has to make the same mistakes as the previous one before learning that just because it is the latest thing, that doesn't mean that you, educated in the latest thing, know what you are doing (until you actually do it for a while).
And then you learn it, everything works, and it seems a new golden age is upon us.
And then a new paradigm will come in, claiming that the only thing to do with (old paradigm) programmers is shoot them, just as we suggested doing to all the old COBOL programmers in our days of stupid youth, and in the meantime, lets skip all the cruft of the previous generation (wonder why everything is breaking, though).
And so on, and so on, and so on.
..is there a web site/blog/forum somewhere which discusses the latest in "best practices" (and variations thereof) all in one place? i.e. discussing good js libraries, UI design, various handy techniques for doing this and that...?
I don't know Jeremy Keith's book, but the ppk book is an excellent exposition of unobtrusive scripting. His philosophy is that js should aid usability - no more, no less. So if you have an enormous form, most of which won't be relevant to to any particular user, you put the whole thing into the HTML - so it's all there for js-off users - then hide most of it in script, revealing only the parts that become relevant as the user makes their way through the form.
The book is a good balance of theory and practise, pragmatic when necessary (eg he explains the few occasions when browser-sniffing is the best solution), with highly liftable example scripts. Recommended.
http://noscript.net/
Allows you to turn scripting off (including most flash) on a per-domain basis. Kill the ads, keep the content.
I am putting together a framework at http://methodsupport.com/program/About.html for generating process/method(ology) support websites.
The emphasis is on document (paper form equivalent) based processes automated quickly and easily.
At this stage it is pre-alpha, but I hope to get a minimum feature set in place soon and upgrade it to alpha.
The source is available from the Sourceforge page.
At this stage, I need any comments or advice that anybody can give me.
Regards, Martin IT: http://methodsupport.com Personal: http://thereisnoend.org
Sorry, I think I posted this to the wrong topic....
Regards, Martin IT: http://methodsupport.com Personal: http://thereisnoend.org
Why not indeed? In fact, we do. Where I work at Caplin Systems, my team is working on a streaming ajax trading platform, and we use mock based test driven development using mock4js, a mocking library for javascript written by a member of the team to support our work here, which has been open sourced. We do unit testing with JSUnit, and acceptance testing with Selenium. We do documentation with JSDoc. We use object oriented programming using standardized paradigms weve developed. We have automatic generation of basic UML from the live javascript code using a tool I wrote. We use Ant tasks to build, package and deploy our code. We use version control linked into our issue tracking software.
And thats just on the technical side, you can be assured that we are also following a best practices of software engineering method in the way we organize and plan our project as well.
So its hard for me to imagine what youre recommending we do that we dont already. It is difficult sometimes, compared to more traditional languages, such as java, as the tools support is already there. For us, we often have to improve the tools that exist, or write them ourselves, but its also fun being on the edge of something new.
-- adam
...please don't. please? pretty please? with a cherry on top?
If you're talking about this site I can see the main video but just an empty column on the right (headed "Payin' The Bills", ha). I enabled www.comedycentral.com in NoScript and not google-analytics.com or doubleclick.net, but I think AdBlock (with Filterset G) is doing its sterling work in the background and keeping the ads at bay.