Best Programming Practices For Web Developers 210
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?"
More than one side to this one... (Score:5, Interesting)
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.
Re: (Score:3)
look at /. and compare it to digg, that's all you need to show anyone to convince them i think.
Re:More than one side to this one... (Score:5, Informative)
Re:More than one side to this one... (Score:5, Insightful)
Thing is, serverside can be made to work for everyone, which is a plus. But the flipside is it can be *slow* for everyone, because serverside you often have no other choice than redraw the entire page (which can be expensive sometimes) even for a tiny change.
So, the way we tend to do it is graceful degradation.
If there's something to click on that'll rely only change a small part of a big page (say clicking a link to expand a comment-tree) this is what will happen:
The link is a normal a href= link, fully standards-compliant, should work even in ancient lynx.
We then use a standards-compliant well-documented library, jQuery, to add an onclick-handler to the link. The handler returns false, which supresses normal link-following for browsers with javascript turned on. The benefit is that those with javascript saves a lot of bandwith and time, they'll only load the ~500 bytes for the extra comment, not the ~20kb for the entire page.
The only way someone would be screwed with this solution would be if their browser *did* support javascript (and had it turned on), yet *wasn't* correctly supported by jQuery *AND* doesn't support the relevant standards for javascript. I am not aware of even a single example where this is true, if I became aware of such an example, a single "return true" for that browser would instantly enable all functionality.
Now, if someone has a browser with javascript, and with a faked browser-header so I can't tell it apart from browsers with a working javascript-implementation, and the javascript-interpreter doesn't understand standards-compliant javascript, then they're screwed. (well, they need to disable javascript to get the site to work...) but in that case they've spent rather a lot of energy for getting screwed....
I think this solution is a fair bit better than "only serverside everything" actually. But yeah, it is extra work, because you really offer both alternatives for these functions.
Re:More than one side to this one... (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
What payment method? I buy ebay things all the time, using FF under linux - no problems at all.
learn Python (or Perl if you're feeling feisty) and write something that at least has a chance of being reasonably structured.
Reasonably structured perl? The mind boggles.
Re:More than one side to this one... (Score:5, Insightful)
The only problem is, Perl allows insanely terse code. One line of Perl can often replace a page of C or five pages of Pascal. This is tempting, and it's easy to get hooked up and produce read-only line-noise. Yet, with a modicum of self-control you can write readable, well-structured Perl code.
Of course, this is just like writing secure code in PHP. It is possible, yet no one practices it...
Re:More than one side to this one... (Score:5, Interesting)
Re: (Score:3, Interesting)
There are so many different ways to do something in Perl that you end up doing what is expedient - but not maintainable over the long haul. On the other hand there is usually just one way to do a given thing in Python - which makes learning, and retaining the language much easier over time for me.
I've written production programs in Perl, awk, sed, Java, C(++), Pascal, sh, php, and tcl for many years - and Python is just better in every way imaginable (JIT by
Re: (Score:3, Informative)
Perl packages have a standardized method for doing unit tests, and consequently, many CPAN modules have them. Python does not, so most packages do
Re: (Score:3, Funny)
Re: (Score:2)
I was thinking about this - and couldn't come up with a scenario in which I wouldn't want my indentation to accurately reflect flow of control. This is what python enforces.
Any scenarios you can think of?
Re: (Score:3, Informative)
Indeed:
From Moving To Python From Other Languages [python.org].
Re: (Score:2)
Ah, but can you write blocks of code without block termination sequences? You know, ifs without endifs, like in Python? I THOUGHT NOT!
Seriously though, marking blocks with indentation is great. In every piece of code that matters (i.e. is not art or for fun) you are going to indent your code, so also terminating the block with statements is superfluous.
Re:More than one side to this one... (Score:5, Insightful)
Of course with the bar being set so low for getting started in website development it's no surprise that we see the horrible messes that we do today.
Re:More than one side to this one... (Score:5, Insightful)
1) DO NOT REINVENT THE BROWSER
2) DO NOT HINDER THE BROWSER
3) DO NOT TRUST THE USER
Re:More than one side to this one... (Score:5, Interesting)
4) Do not use methods that are OS or Browser specific.
As for #3) - Absolutely true. Too many developers depend on sniffing the User-Agent string to determine browser capabilities. A much better, more reliable and easier to maintain approach is to test the specific capabilities you use, and provide a way for alternative access to the content. Note "alternative" != "100% equivalent."
Re: (Score:2)
Or... you could have a single check does feature X exist. So potentially a lot less if statements
Second, when Opera 9.5 comes out and supports new features, or FF3 comes out supporting new features, above you get to rework the pag
Re: (Score:2)
Users WILL break the system out of stupidity, because most users aren't programmers or engineers. This is why an engineering/programming approach is misguided as applied to the web. If we could concentrate more on usability and design, we'd give the dumb user less opportunity to break the system.
Re: (Score:2)
Maybe you shouldn't be using a browser then. What's wrong with an old fashioned client-server app?
Re: (Score:2)
Re: (Score:3, Insightful)
Re:More than one side to this one... (Score:5, Insightful)
By gracefully degrade, do you mean "gracefully" putting up a banner that says "you need Flash to see the rest of this page"? Because that doesn't cut it.
Once Flash enters the picture, it either becomes necessary to have Flash to access the content, or it becomes obvious that Flash was unnecessary in the first place.
Very few designers use Flash to merely "enhance" a page. Flash invariably becomes necessary to access the page's core functionality. The "graceful" degradation usually follows a pretty steep curve (ie. all or nothing).
Re: (Score:3, Insightful)
The problem is that the "designers" have often only learned flash, as they consider themselves "designers" and not "programmers" (who should know more than one language, programming techniques, how to debug and ...). They only want to "design" - pick their favorite fonts, make fancy navigation structures that look cool. They usually consider programming a bit icky and "right brain"
(or is it "left brain"?) and somehow beneath them. Sadly, for many this attitude is taught to them in college (sometime
Re: (Score:2)
Until technologies like Flash are made reliable and secure across all platforms, web developers ... don't have to stop using them, but ... really must take into account that some web users won't have the capability and they (the developers) need to provide alternatives, even if less glitzy. Things like don't make the whole content be in flash would apply here. Use Flash for what can't be done by other means. And make audios and videos available directly in standard formats.
Re:More than one side to this one... (Score:4, Interesting)
If 98% of the use of hammers was just to smash random things for no reason in particular, I would avoid being around people who owned hammers. I would probably call it a "bad tool" as well.
Re: (Score:3, Insightful)
Re: (Score:2)
I agree - and the most important part of doing it correctly is Ensure that pages are accessible even when newer technologies are not supported or are turned off [w3.org].
Like JavaScript. You might excuse something as complex as Google Maps for requiring javascript: instead they made the effort and it works without it [google.com]. So how can sites like Monster.co [monster.com]
Re: (Score:2)
I'm betting that there was a time when that "low bar" was just about the right height for you, too.
The fact that the requirements for getting started in web development are very low is one of the things that makes the Internet great. I can remember when some of the web sites that today are among my favorites were also "horrible messes" in their earliest stag
Re:More than one side to this one... (Score:5, Insightful)
For example, I've written a few web applications per client spec that required various effects, animation, windowing, and tab features. These are all things which are better left to Javascript, and in my preference, the jquery [jquery.com] and interface [eyecon.ro] libraries. In fact, there's no real way to accomplish most of those effects without client side scripting. Hell, even Slashdot uses Javascript in their comment system, Firehose, etc. Or look at Google Apps, GMail, YouTube. Not even possible without client side scripting. A well programmed client side script (like anything Google's coded) runs great on even a 500MHz Pentium 3.
Anyway, my point is that while I can understand minimizing client side programming, it shouldn't, and can't really be avoided completely. I personally love mixing client and server side programming to draw out the strengths in both methods. Just because the idiots at Digg can't program, doesn't mean the whole thing should be thrown out.
Re: (Score:3, Informative)
The one app where Web 2.0 shines is Google Maps. But Google has been phasing into other things where it is just not appropriate, making them bloated, slow, awkward to use, and even buggy where they weren't before.
Example: The new Google Groups is an abortion, replacing the older interface (which was already
Re: (Score:3, Insightful)
I can still submit comments to Slashdot with Javascript disabled. Be sure your submission system works that way as well. Javascript can enhance, and should. Lack of Javascript should not disable. It is not required to submit a comment.
As for YouTube ... totally possible without Javascript, Java, or even Flash. True, it would not look so good and would be harder for some people to use. But the way they do it, it's a broken site altogether when these facilities are not usable, and that does not have to
Re: (Score:2)
Re: (Score:2)
Youtube made it work without flash for the iphone to overcome an iphone limitation - not because it was the more portable implementation.
Re: (Score:2)
Re: (Score:3, Insightful)
Per client spec. Just because your client thinks you need those things doesn't mean the users actually do. I understand you got paid to write it that way, but that doesn't mean that's the best way to write it.
Re:More than one side to this one... (Score:4, Insightful)
Make the user's browser guide the data, check the input once, and then send to the server. There, the server checks it AGAIN. That gives you a redundant check in case someone hacks your client-side script, and lets the non-hacker still get the benefit of an intelligent page.
Re: (Score:2)
saying on the page what the rule is,
or
providing a link to said rule.
But I'm wierd like that.
Re: (Score:2)
You should do both, so you've got security server side and so that users don't chew up your bandwidth or have their time wasted to find out they've entered invalid details.
Re: (Score:3, Insightful)
It's not a new idea to shift the workload to the customer. The internet did it in banking (you're your own teller in online banking), shopping (you're basically your own bookstore clerk at Amazon
Re: (Score:2)
Re:More than one side to this one... (Score:5, Informative)
Sounds like Digg is attaching events to every show/hide link instead of using event delegation and using only one event listener. Browsers can't really handle hundreds of attached event listeners, it is a known performance issue.
Now using event delegation [scripttags.com] instead of attaching hundreds of events should definitely be in a set of web development best practices.
Re: (Score:2)
Re: (Score:3, Interesting)
You can do any OO design in PHP5 just as easily as in Python. PHP is less constrained. It allows people to use bad designs because this allows hobbyists who haven't learned correct design practices to build things. However, even though
Re: (Score:2)
But the problem is that the book is not that good. Its full of redundant library functions, with inconsistent calling and naming conventions, and a glossy invitation to do things cheaply and thoughtlessly.
Perl may allow you to do incredibly terse code, yes, but even when so obfuscated, it still entices you to follow a grammatically coherent structure, as it were. Howerver,
Re: (Score:2)
Re:More than one side to this one... (Score:4, Interesting)
Python works quite well for implementing the logic of an application thanks to it's clean syntax and good object support. It's not always the easiest to get working, and keep working, with your web server though. That's something I think should be improved. It works great but isn't as good a solution for a new developer because of that issue.
PHP I usually use only for output logic and templating. I make remote calls to my app logic via XML-RPC and then use PHP to make it look nice. PHP is really easy to develop in so long as you don't code like a novice and cram everything into it. If you must program your entire app in PHP then please keep things clean and don't write HTML, CSS, Javascript, SQL, and PHP all inline. Don't mix user interface logic with application logic. If your application logic is going to be simple enough it's fine to write it in PHP so long as you keep it tidy. Sometimes it's easier than messing around with setting up something like Python as a backend.
As for glitz over function - don't do it! Make sure things work first and then go back and try to make them look and feel nicer where you can - if you think it will really help. Don't make things complex to maintain if it isn't going to benefit the user. With CSS and Javascript behaviors it's easy to write a clean XHTML site and then layer in improved looks and interactivity.
I was a programmer before the web came into existance and I started make web sites. I think there is a major benefit to learning to be a programmer and sysadmin first because you understand better how things can be done to be more effecient and easier to maintain.
I've often seen developers spending a lot of time doing even simple tasks like preparing images that'd be much easier if they had programming experience. For example, cutting out product images - my graphic artists tend to hand trim the pictures which takes forever and results in a rough edge. When I do it I create a second layer in which I fill in the parts I don't want using the very quick use of the select tool and sliding the sensitivity back and forth. Then I use a drawing tool to just fill in the individual pixels I need to smooth things out. Mine take about 30 seconds each and look nicer than my graphic artists' 5 minute effort.
I've seen developers spend a lot of time coding in features that could be configured in a couple minutes of configuring the web server or using a system feature such as cron jobs.
In principal I agree with the article that it's good to gather requirements before you start and don't repeat yourself but I feel I have to point out that web development is often a rapid application design type of thing where you aren't given significant time to plan or implement your work and requirements will change often. It's best to develop some best practices that work for everything and stick to it. Usually your boss or client isn't going to have any idea what the requirements are so stick to your best practices unless you have something specific that needs changed and update your best practices as you build experience. Do try to keep from duplicating work or repeating yourself but don't spend an exhaustive amount of time avoiding it - instead do your work and refactor now and then as needed. Refactoring is a much better idea than trying to plan every possibly line of code.
Testing I think is probably the most important thing, after following standards, that most web developers don't do. Get at least IE6, IE7, Firefox, Opera, and Safari and test every page of every site with each of them. As you develop test and re-test because things are going to change without you noticing. At least Firefox, Safari, and Ope
Re: (Score:2)
"Good practice" is an outdated concept (Score:4, Funny)
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.
Re: (Score:2, Funny)
Re: (Score:2)
Oh yeah, those were the days at some large, German company. I heard they still use the crapola spaghetticodemonster I created. I really, really don't want to meet the maintainers and have to admit that I was the one creating it. That's something you usually get to see on Springer.
Re:"Good practice" is an outdated concept (Score:5, Insightful)
Unfortunately someone has to maintain your crappy code, and from my experience contractors all seem to be well aware that it isn't going to be them. We've stopped hiring contractors now, because frankly I'm tired of cleaning up other people's shit.
As to my advice:
- have a proper data layer (we codegen it using Entityspaces [entityspaces.net])
- have a proper business layer (we codegen most of that too with Codesmith)
- it's a database, not a spreadsheet
- XHTML will make your life easier
Re: (Score:2, Interesting)
I'm not a contractor - but I like his style.
I'm a web developer with a successful SAAS product in the market. It's a cool flashy app that's kept us at the front of technology. Yesterday I could have either built a new ajax graph widget for the front page - so we can win another client - or fixed the log in code so it stopped calling the database twice per log in and save me having to order another server.
Guess which I did? :)
There are more types of apps and development practices in heaven and earth, Pike
Re: (Score:3, Interesting)
You tell a client that they need to pay for a new server and they're fine with that.
You tell them that they can pay you 30 developer-hours to fix some issues so they won't need the new server in the first place and they act like you're trying to rob them.
Re: (Score:2)
Anyway, you have to sympathize with their desire for something tangible. If anyone ever asks them to cost justify a server, they can take that guy into the server room and point to it. If someone ever asks them to justify the code...Well, that gets ugly. "We had to fix the code." "O Rly? Why didn't it work right in the first place?" "Well, it did, but..." "So you gave the same people more money?" "Uhh, well, other people would have
Re: (Score:2)
Well thing is, if you wrote stuff that worked right in the first place, bosses don't seem to appreciate it. Not like they'd give you a big raise.
After all you're not working hard like the rest fixing bugs, spending hours to add new features etc. You're also not filling out your timesheet with huge amounts of activity.
And most bosses certainly don't appreciate the "rather long period" when you're just sitting around thinking about it, or vainly trying to given th
Re: (Score:3)
I've worked in some non-computer-focused industries since then though, and the way projects come about is wildly different, so I can appreciate the bastardized hell code I used to work on better. Hell, I've even produced some of it.
When you have 20 practical projects on your plate and every single one of them has a FUNCTIONAL PURPOSE (e.g. "
Re: (Score:2)
It's a hell job, so if you can do the work, you can set your price.
Re: (Score:2)
Well, it does make me wonder, though (Score:5, Insightful)
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
Re: (Score:2, Informative)
---
Actually they did the _airport_ (not the planes) out of wood and straw, complete with tower and offices.
They wanted to attract the planes.
from Wikipedia:
Famous examples of cargo cult activity include the setting up of mock airstrips, airports, offices and the fetishization and attempt
Re: (Score:2)
However, look at the, now defunct, office cargo cults from this perspective:
Stone age Papua New Guinean sees fantastically wealthy - to a hitherto unknown level - white men arrive. His people have already figured out that they are not gods, but merely men with white skin. He takes notice of the fact that the white man sits in an office all day doing no more than passing paper around while the black fellas do all
Re: (Score:2)
The main reason I use the same set of tools for each project I do, to the limit of my ability to do so, is not because it's flashy,
Then you're not my problem (Score:2)
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
Re: (Score:2)
Holy false dichotomy, Batman! While it's impossible to pin-down 100% of the requirements in advance (the so-called BDUF methodology) that doesn't mean you shouldn't be aiming at 90%, or that 0% is ideal. Let's say we were building an accounts system. It'd be good if we knew in advance whether it had to cover sales, purchases, or both.
We can agree then (Score:2)
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 fee
Re: (Score:2)
To spoil the ending for you, you missed by a wide margin. Starting with the fact that instead of worrying about whether the message is right or wrong, you try to figure out a way to pick at who wrote it. Still, in the interest of transparency:
Can't say I have any particular fetish for that. Honestly, even if you just spend 5 minutes thinking in your head, "ok, do I need a singleton here? What am I trying to accomplish? What alternat
Sadly (Score:2)
Productivity vs. The Right Thing (Score:5, Insightful)
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.
Re:Productivity vs. The Right Thing (Score:4, Insightful)
And this is where it starts to get ugly.
Clients vs. The Right Thing (Score:2)
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 t
XSLT! (Score:2)
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+XSL
Re:XSLT! (Score:5, Insightful)
XSLT should only be used to transform backend XML into different XML or HTML. It should not be used for any kind of logic, processing, etc, because it doesn't perform nearly as well as a real programming language, and becomes very unreadable as soon as you deviate from simply applying templates and doing straightforward transformations.
I program in XSLT every single day, and I use a framework (Apache Cocoon [apache.org]) that is basically designed around XSLT transformations, and the most common problems I see, are caused by people trying to do complex stuff in XSLT. XSLT is really great. Really. But it's no substitute for Java.
Theres only one programming practice : (Score:2, Insightful)
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.
Re:Theres only one programming practice : (Score:5, Insightful)
If asked about the development process they want, most would say 'fast and cheap'. Bearing in mind that a less than perfect website that is up and gaining revenue is better then a wonderful, fully featured website of d00m that won't be ready for six more months. A good programmer should advise the smallest possible feature set at first, so that can be tested, and decisions made as to the best way to proceed.
Besides, a cheap website can be improved over time, an expensive one that looks nice but doesn't quite do the job (find me a version 1 of anything that did) is costly even if all you do is remove stuff you paid a lot for.
Re: (Score:3, Informative)
Going from version 1.0 to 1.1 is much easier than from 1.0 to 2.0. And there are added benefits.
Re:Theres only one programming practice : (Score:5, Insightful)
Re: (Score:2)
Re: (Score:2)
The guy I replaced didn't. His code looks like a trainee shipping clerk dictated it to him over a bad phone line.
No, I do. I quit!
You really can't win in this situation - say anything and you're wrong for arguing, do what they say (even if you said it won't work, it writing, in triplicate) and it's your fault when it doesn't work.
They say that if one thing irritates doctors, it's patients who self-diagnose. I can see why.
Re: (Score:2)
no client is able to object when what happened was due to what they have requested despite being warned about.
Re: (Score:2)
Re: (Score:3, Insightful)
Yes.
Elaboration:
Re: (Score:2)
Re: (Score:2)
I am pretty confident.. (Score:3, Insightful)
Misleading question (Score:5, Insightful)
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.
Re: (Score:2, Informative)
Web development adds specific complexity to "classical" dev platforms. You have to deal with 4 dialects at minimum: html, css, javascript, and the one that really run on the server. Worse than that: you are usually given development tools that makes possible (and encourage) to mix these languages
Re: (Score:2)
I know that many developers are doing their best with sucky tools, but you guys will always be outnumbered by people who aren't, same as in any other field. Most of the web developers I talk to are totally shocked at the notion that they should care about "software" engineering, when all they're doing is "page design".
Only one best practice needed (Score:2)
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.
They didnt work so well for trad projects (Score:5, Informative)
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.
Re: (Score:2)
Re: (Score:2)
you would think so.
However, remember that you can meet requirements without meeting objectives. There are quite a few applications out there that met the requirements, but failed to meet the objectives of adaptability, usability, manageability, etc.
These apps are error-prone, frustrating, and inefficient to use. They are hated and despised by their users. But they may still be quoted as successes by IT ivory-tower folks specializing in proj
Re: (Score:2)
Having worked on everything from corporate IT projects and avionics hardware to utility infrastructure development, I'd have to say this problem looks quite familiar. At some management level, there is someone who pushes the analysts/engineers/whatever to select a vendor and/or architecture. Often, this is done before the scope of the problem has been identified
Best Web Practices (Score:2, Interesting)
Last Cranky User, too. (Score:2)
It was a lot of fun.
Calendar Tech (Score:3, Insightful)
After learning how to use calendar tech and spoken/email languages for project communication, the rest of the development is relatively easy.
"Web site" is really "EAI" (Score:3, Informative)
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 [michaelnygard.com].)
Re: (Score:2)
By the way, *fantastic* book, Michael! I read the entire thing, and it was 100% spot on. Opened up my eyes to design patterns that I hadn't been aware of, made me appreciate the importance of not re-inventing logging services, and that advice about using the soft references to prioritize garbage collection... simply awesome. You really took my knowledge of programming up a notch.
Anyhow, I had been thinking of dropping you a note saying how great that book was, and lo-and-b
DRY CSS example... (Score:2, Interesting)
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 no