Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×

Managing Site Growth? 37

markmcb asks: "I started a web site about two years ago. When it began it was simple. The code was 75% hacked, and administration was easy. However, the times they are a changin'. Now I get hundreds of thousands of hits and have a steady flow of new users. I'm noticing an ever-increasing gap in terms of my site's popularity and its technological progression. Specifically, I have all sorts of 'XYZ for Beginners' books that are no longer of use to me. Even the so-called non-beginner publications seem to only scratch the surface of running a site. As problems get more complex, trying to Google every situation/issue I have with site administration has become less useful as well. I'm finding things like writing optimal code, configuring servers for high-volume, balancing ad income vs. server costs, and maximizing the efficiency from my moderation team have all become issues and that aren't addressed most books. What is the best way for a low-income, non-professional, but enthusiastic web designer/administrator like myself to manage site growth as it leaves the realm of just-for-fun?"
This discussion has been archived. No new comments can be posted.

Managing Site Growth?

Comments Filter:
  • by Jerf ( 17166 ) on Wednesday August 02, 2006 @10:03PM (#15836728) Journal
    What is the best way for a low-income, non-professional, but enthusiastic web designer/administrator like myself to manage site growth as it leaves the realm of just-for-fun?
    Unfortunately, the only answers are either hire a professional, or become one.

    "Scalable" and "customized" are two things that when put together simply require a professional. And quite a lot of people calling themselves "professional" can't handle it, either.

    Now, by "professional" I don't necessarily mean a degreed guy who makes at least $X thousand a year with Y years of experience. What I mean is, you're stepping into the domain where you can't hardly acquire the experience and skills necessary with anything less than full dedication usually brought on by having a job in the relevant domain.

    There is, however, one other possibility for you to consider. If you analyze your needs and the available packages for your type of website, you may find that you can drop the "customized" aspect of it, if you can find a project close enough to your needs to require only minimal customization, perhaps even no actual code customization. Then you just need to import the data, and you will presumably have satisfied yourself that this package can meet your performance needs.

    If the website you are referring to is the "OmniNerd" site you have a link to, then I would imagine this should be feasible. There are a lot of "news" packages, free and otherwise, and at least on first blush I don't see anything particularly unique about it. It looks an awful lot like slash, although from what I've heard that's not the easiest thing to customize. (slash hackers feel free to comment.)

    Really, there's no excuse nowadays to start a new web framework from scratch, and your first impulse if your hack-job is starting to come apart at the seams should be to change to one of the umpteen bajillion tested, performant frameworks. Depending on your skill levels, which you did anything but talk up, you may even be missing basic pieces like caching, which is pretty important on a site like that. Non-professionals should not attempt to write website caching routines. Unless you want to go insane. (It's not that it's hard to write... it's that it's hard to get correct, and debugging cache problems are close to sheer hell.)
  • by mabu ( 178417 ) on Wednesday August 02, 2006 @10:39PM (#15836878)
    You haven't elaborated much on your situation. To be honest, the scalability and technology available to you has a lot to do with what platform you're using. The initial design of a data-driven web site ultimately determines how easy, securely and efficently it will be to evolve to meet changing needs and increased demand.

    Open source technology tends to be more scalable and solid, but even there, a bad choice stifles your progress. If money is no object, I guess you can always scale up, but the commercial platforms often have their admins spending more time patching and maintaining the status quo than progressing. The bigger question is: Did you do your homework when you initially designed the system? If you're stuck, that's likely the problem.

    If you have a choice to redesign or redeploy your site, what you need to do is ask yourself, not whether or not the technology you're familiar with can do what you want, but instead, are you using the right technology to do what you want?
  • by QX-Mat ( 460729 ) on Thursday August 03, 2006 @06:33AM (#15838304)
    I didnt think I had a lot to learn about programming before I started uni... 3 years later, and I'm confident I didnt learn a single language aspect from any of my courses (with the exception of the new languages we were introduced to for assignments - such as ASML).

    However, even from day one, I could see they were trying to teach us something else, and not just how to program. This wasnt clear or evident to anyone else who didnt know how to program in a compiled language, because the workload of simply understanding how to program really did washout the assignment goals. Our assignments - based on the BlueJ work (http://www.bluej.org) - taught us how to compartmentalize classes, and structures. They made us think of more inventive ways to decouple classes. Taught use to introduce and extend classes using aditional abstract datatypes rather than rewrite the base class.

    Applying what I learned to Perl has not helped comprehensively, but it has increased my awareness of types and the structure of larger projects. Even a simple RPG can have a few hundred ADTs/structures.

    What I feel is important for me to share, however, is that there is no final solution to programing and stepping into the complex. Sometimes it's easier and quicker to isolate peices of code for what they are - functionaly complete - and not get bogged down trying to improve something that doesnt really need it. Focus on the way things are coupled - whether you use a single big import/include/use statement, or dynamically link things. It pays off in the long run to have a better execution structure (Perl's POE anyone?!) than programmatic correctness in function-orientated areas.

    Practice. Practice. Practice. Don't worry about things too much. Starting again, even twice, is not a failure. *You* learn the better ways with time. Don't be afaid to write down absolute crap on paper - even if its block diagrams, code fragments or unrolled loops. You need total awareness of your task (aka design spec) until you see the 'best way' and produce tight code.

    (nowadays, lmost everything I begin requires a little thought, but the moment I start writing code, I'm doing it correctly, making use of language features and code conventions. experience... you'll get there in time!)

    Matt
  • by FooAtWFU ( 699187 ) on Thursday August 03, 2006 @09:31AM (#15839062) Homepage
    Tips I learned running a millions-of-hits-a-year website...

    • Write valid XHTML. Use the magical DOCTYPES that keep Internet Explorer relatively happy. Develop the CSS to target Opera and Firefox (and Konqueror if you can), and install hacks for IE afterwards some way you can keep track of them. Anything else will probably blow up for you.
    • Consider keeping your structural CSS and your shiny CSS (colors and such) separate. Try to come up with a decent scheme.
    • You'll have all sorts of files and maybe even stacks of logs, presumably. At some point, you may want to replace a file, and name the previous version .old - don't. Never name anything .new either. There will always be a new new, an old new, an older old, a new old... Use dates - 20060802. YYYYMMDD sorts nicely too.
    • Use mod_rewrite (or equivalent) and pretty URLs which are purely logical. Try to hide things like 'php' and 'asp' and 'cgi' and such. If you ever want to replace whatever's driving that URL, you will be glad. For God's sake, avoid query strings in your URLs unless someone is sending a query. You'll also keep the search engines happier.
    • Sign up for a little Google Analytics account if you can. preeeeeeety shiny stats. everyone loves them.
    • PHP is a fine hypertext preprocessor. It's a lousy programming language. It's excessively convenient... a lot like Windows, really. Avoid it, of course.
    • If you're writing your own stuff, consider FastCGI and lighttpd instead of PHP+Apache.
    • I have heard good things about Ruby On Rails. Check it out some time.
    • You know HTML? Now learn HTTP. Headers. Lots of headers. Beautiful headers. And status codes of all kinds. Learn when to return a 304 versus a 206. And 301 Moved Permanently is a blessing when you're restructuring. [meta name="refresh" value="..."] is a hack.
    • Cacheability is your friend. If you can keep your public-facing content cacheable and install Squid, things go very very quickly. Otherwise, cache in your application. This usually requires something that's not PHP. FastCGI can do the trick.
    • There are always many ways to do something. Use the most elegant way possible, the simplest neatest prettiest way. Use the strictest dialect of your language, the most rigorous form of whatever you're doing - go the extra mile, do things which would make your computer science professors proud. When you don't, things will fall apart faster than you think they will.
    • If you're writing a big function suite or something to get something done, pause and reconsider. There's probably a library or such out there to do it already. Check CPAN if you're Perl, PEAR if you're stuck with PHP... Even if you think you have things under control, check them anyway. Better to look now then say "that would have been so much better" weeks in the future.
    • Keep the search engines happy. Include your page metadata. Use things like [link rel="previous"] and such. There's a whole suite of these things. Make RSS feeds and sitemaps for Google Sitemaps.
    • Get a version control system! Stuff your entire site in a Subversion repository. Then develop in a sandbox off to the side and synchronize it back. If you insist on skipping the sandbox, even just having old versions will save you, eventually. (This could also be good for backups- just back up the repository.)

"May your future be limited only by your dreams." -- Christa McAuliffe

Working...