Slashdot Mirror

Yes it does matter for software. Moving from system to system IS A MAJOR PAIN and very expensive.
And Yes going to Slashdot is just dumb.
Why is it dumb?
Because if you don't treat FOSS as a professional system to start with why should anybody believe you.
So what this guy should have done is go the the Drupal website and then found this page. http://drupal.org/cases
Golly gee case studies about how Drupal can be used. Just like you would find at any closed source vendors site.
Interested in Liferay?
Guess what they sell it with support. It is still FOSS but I bet you a dollar that if you contact them they have many case studies and other sales tools that they can provide you.
If you just want some more case studies...
http://www.liferay.com/web/guest/products/portal/stories
Merry Christmas. Here is your clue.

Drupal case studies.
http://drupal.org/cases

And for Liferay
http://www.liferay.com/web//guest/products/portal/stories

Next question?

One of the links in the summary is to http://durpal.org/ . I wonder if that is a fork from http://drupal.org

Also, it is interesting to see the long forgotten WorldForge on that list. Maybe Duke Nukem should go open source to get some of that good Google cash.

I find most CMS all so cookie-cutter dreadful and difficult to enhance.

Drupal aint like that. You can theme anything in Drupal.

What these new web programming frameworks all lack is some good designers on their team.

http://drupal.org/node/305743

Well, developer has utmost freedom to redesign theme from scratch or mod currently available ones, here are some websites done in drupal, check it out:

• http://www.warnerbrosrecords.com/
• http://change.gov/
• http://community.michaeljackson.com/
• http://ketnet.be/
• http://ngycp.org

more here and here.

I completely agree however, drupal != dreamweaver.

Lots more modules. Free. Works. I don't like Joomla at all. Everything cool has a big price tag on it.

1. Use Drupal
2. When writing modules always ensure you use Drupal's API, particularly for paramaterisation of Database queries and such. Check http://api.drupal.org/

I'm in the middle of this same process. I'm using Drupal along with the CCK (http://drupal.org/project/cck) and Views (http://drupal.org/project/views) modules to accomplish this. If you aren't aware of what Drupal (or CCK/Views) is, then please take a look at: http://www.drupal.org./

Basically, Drupal is a CMS application. CCK allows you to create custom content types for Drupal, thus allowing you to further control the structure of the content that is placed inside of Drupal. I'm using CCK to capture: Objectives, task lists, dependencies, team members etc. for each procedure. Views allows you to display the captured data in various ways. It allows me to generate listings of all of the procedures etc. and they are sortable.

You'd be surprised at how simple this is within Drupal. Give it a look...

This is probably overboard, but if you build a personal website with your name in the title (but keep your titles different on each page, just make sure your name is there). Then get some backlinks, Put in a pdf with your resume, your interests, whatever. Of course that takes time, especially if you haven't built a website before.. I'd recommend use a CMS like drupal with the Page Title module. SEO really isn't that difficult when there isn't much competition.. Also you can get hosting for as low as like $4 a month and a domain name is only $10 a year..

This is probably overboard, but if you build a personal website with your name in the title (but keep your titles different on each page, just make sure your name is there). Then get some backlinks, Put in a pdf with your resume, your interests, whatever. Of course that takes time, especially if you haven't built a website before.. I'd recommend use a CMS like drupal with the Page Title module. SEO really isn't that difficult when there isn't much competition.. Also you can get hosting for as low as like $4 a month and a domain name is only $10 a year..

With that in mind, you should focus on how to provide the highest value IT services for your University. That means building a business case around any changes that you proposed, including the upfront and ongoing costs of transition, training, and support. As many others have noted, "free" software isn't free.

Your University has thousands of users, including a broad diversity of stakeholders, including executive and administrative staff, faculty, and students. All of them expect to have systems up and running 24x7. Any lengthy downtime in a critical system must be avoided.

So what should you do?

• Recommend the formation of a University-wide task group to look at "future needs" and at potential cost-saving approaches. Make sure to include students. Bring in outsiders with expertise on open source software, including commercial open source solutions, e.g., Sun/MySQL and RedHat/JBoss. You can help to justify the need for a task force by mentioning the costs of moving everyone to Windows 7 next year.
• Make sure that one of the task force recommendations is to set up a server from which people can download various high quality open source software to try on their own mchines. That set can include many of the 25 packages that Palamida rated as enterprise-ready, along with Firefox and OpenOffice.org.
• Perform a census of existing open source software on your IT systems. You might be using a lot more open source software than anyone realizes.
• Put together a couple of demos or pilot projects. For example, you can bring up a working Drupal CMS or Mediawiki wiki within an hour, even less if you start with a preconfigured Bitnami stack. Anyone need a new web site right now?

Of course, there is no assurance that these methods will work, or that proprietary vendors won't try an end run around your efforts. But I've found these techniques to be an effective guerrilla marketing approach in the past. Good luck.

Joomla comes out-of-the-box as a quite powerful but extremely restrictive system. If your site needs to work exactly as Joomla's developers intended, great.

If your site doesn't exactly fit their cookie-cutter mold, though, you are screwed. Most tweaks to the way the site works will have to be done by either a) hacking core code (and thus meaning upgrades are a nightmare) or b) replacing core modules wholesale.

An example: I was an intern and the project specs called for Joomla. The project also required articles to be categorised in more than one category - i.e. it might be in the 'nightlife' category and the 'downtown' category. Joomla's categorisation system, however, allows only one category for a content item.

To have multiple categorisation, I had two options - hack apart much of Joomla's core code to wedge that functionality in, or buy commercial replacements to the main com_content module. Plus, if we'd decided we wanted a second feature that commercial replacement didn't have, we'd then have to hack apart that component too.

Add in the heavily pay-to-play nature of Joomla extensions - an oddity for a GPL project - and getting a site set up can be a nasty, nasty proposition.

If a PHP CMS is what you're looking for, my favourite is indeed Drupal. The key in Drupal is its API - you can alter essentially every bit of Drupal, even core components, without having to hack core code. As an example, API hooks like hook_nodeapi and hook_form_alter allow developers to modify any form in the Drupal installation. Want to change the username field in the signup form to a checkbox? You can do that.

Modules like CCK (allows web-based configuration of content types) and Views (lets you easily set up, via a web interface, filters and criteria for displaying content) are wonderful helps, and include their own APIs so you can extend them, again without hacking their code. There's a vibrant developer community with well over a thousand contributed modules - and all free, and (in my opinion) of higher quality than most of the ones I came across in Joomla.

It's a bit longer of a learning curve than Joomla, but the result is a far less frustrating development experience.

Joomla comes out-of-the-box as a quite powerful but extremely restrictive system. If your site needs to work exactly as Joomla's developers intended, great.

If your site doesn't exactly fit their cookie-cutter mold, though, you are screwed. Most tweaks to the way the site works will have to be done by either a) hacking core code (and thus meaning upgrades are a nightmare) or b) replacing core modules wholesale.

An example: I was an intern and the project specs called for Joomla. The project also required articles to be categorised in more than one category - i.e. it might be in the 'nightlife' category and the 'downtown' category. Joomla's categorisation system, however, allows only one category for a content item.

To have multiple categorisation, I had two options - hack apart much of Joomla's core code to wedge that functionality in, or buy commercial replacements to the main com_content module. Plus, if we'd decided we wanted a second feature that commercial replacement didn't have, we'd then have to hack apart that component too.

Add in the heavily pay-to-play nature of Joomla extensions - an oddity for a GPL project - and getting a site set up can be a nasty, nasty proposition.

If a PHP CMS is what you're looking for, my favourite is indeed Drupal. The key in Drupal is its API - you can alter essentially every bit of Drupal, even core components, without having to hack core code. As an example, API hooks like hook_nodeapi and hook_form_alter allow developers to modify any form in the Drupal installation. Want to change the username field in the signup form to a checkbox? You can do that.

Modules like CCK (allows web-based configuration of content types) and Views (lets you easily set up, via a web interface, filters and criteria for displaying content) are wonderful helps, and include their own APIs so you can extend them, again without hacking their code. There's a vibrant developer community with well over a thousand contributed modules - and all free, and (in my opinion) of higher quality than most of the ones I came across in Joomla.

It's a bit longer of a learning curve than Joomla, but the result is a far less frustrating development experience.

Drupal

I've done several sites using Drupal and ran into some of the upgrade and module installation SNAFUs mentioned here.

I found DRUSH to be one of the most useful modules available for handling module updates and installation. It is basically a CLI swiss army knife for tasks like module management, cache management, log management, etc. In short it is just plain awesome.

By using Drush and having Drupal Core checked out via CVS it is trivial to keep everything up to date in an automated fashion.

I've used CakePHP (1.2 beta) and Drupal (4,5 and 6) but Drupal more recently. I like both very much. If I were building a site with the features you describe I'd go with Drupal. Either way you've got a lot of learning ahead of you but at least with Drupal, if you get it right, you'll have the benefit of piles of modules that are already tested and other people who are familiar with them. CakePHP can get you just as far but in my experience you're doing a deeper pile of custom code.

There are at least a couple of popular shopping carts for Drupal. I'm building a simple Ubercart site.

The other popular contrib modules you're almost sure to run in to are Views and CCK. You'll want to get some screencasts or podcasts to get familiar with those (Lullabot does some good ones - they're also the authors of this book).

I've been doing a lot with Views lately and a little with CCK. There's a pile of stuff you can do with very little custom code in the right places. It just takes a lot of effort to learn what works well together.

I've used CakePHP (1.2 beta) and Drupal (4,5 and 6) but Drupal more recently. I like both very much. If I were building a site with the features you describe I'd go with Drupal. Either way you've got a lot of learning ahead of you but at least with Drupal, if you get it right, you'll have the benefit of piles of modules that are already tested and other people who are familiar with them. CakePHP can get you just as far but in my experience you're doing a deeper pile of custom code.

There are at least a couple of popular shopping carts for Drupal. I'm building a simple Ubercart site.

The other popular contrib modules you're almost sure to run in to are Views and CCK. You'll want to get some screencasts or podcasts to get familiar with those (Lullabot does some good ones - they're also the authors of this book).

I've been doing a lot with Views lately and a little with CCK. There's a pile of stuff you can do with very little custom code in the right places. It just takes a lot of effort to learn what works well together.

I've used CakePHP (1.2 beta) and Drupal (4,5 and 6) but Drupal more recently. I like both very much. If I were building a site with the features you describe I'd go with Drupal. Either way you've got a lot of learning ahead of you but at least with Drupal, if you get it right, you'll have the benefit of piles of modules that are already tested and other people who are familiar with them. CakePHP can get you just as far but in my experience you're doing a deeper pile of custom code.

There are at least a couple of popular shopping carts for Drupal. I'm building a simple Ubercart site.

The other popular contrib modules you're almost sure to run in to are Views and CCK. You'll want to get some screencasts or podcasts to get familiar with those (Lullabot does some good ones - they're also the authors of this book).

I've been doing a lot with Views lately and a little with CCK. There's a pile of stuff you can do with very little custom code in the right places. It just takes a lot of effort to learn what works well together.

Drupal has multisite capabailities that allows you to run multiple sites off one codebase. If you set up your file directory structure using best practices and use modules such as drush, you can easily and quickly update mutliple sites. I have a few scripts I've written that can update the 20+ Drupal I host in less than 10 minutes.

Regarding security, I suggest signing up for the security email, it's sent out whenever there is a security problem with modules or core code. Additionally, if you enable the Update Status module, Drupal will inform you whenever a module or core code has been updated. You can also configure watchdog to send you an email/sms/etc whenever the system logs "update available".

If you use the devel module's macro function, you can automate the entire process of setting up and configuring a module. You may also consider developing an install profile if you want to enable and configure a specific set of modules for a specific kind of site (eg: blog, cms, forums, etc).

BTW, you don't need to run update.php when you first install a module, only when you update a module.

Drupal has multisite capabailities that allows you to run multiple sites off one codebase. If you set up your file directory structure using best practices and use modules such as drush, you can easily and quickly update mutliple sites. I have a few scripts I've written that can update the 20+ Drupal I host in less than 10 minutes.

Regarding security, I suggest signing up for the security email, it's sent out whenever there is a security problem with modules or core code. Additionally, if you enable the Update Status module, Drupal will inform you whenever a module or core code has been updated. You can also configure watchdog to send you an email/sms/etc whenever the system logs "update available".

If you use the devel module's macro function, you can automate the entire process of setting up and configuring a module. You may also consider developing an install profile if you want to enable and configure a specific set of modules for a specific kind of site (eg: blog, cms, forums, etc).

BTW, you don't need to run update.php when you first install a module, only when you update a module.

Drupal has multisite capabailities that allows you to run multiple sites off one codebase. If you set up your file directory structure using best practices and use modules such as drush, you can easily and quickly update mutliple sites. I have a few scripts I've written that can update the 20+ Drupal I host in less than 10 minutes.

Regarding security, I suggest signing up for the security email, it's sent out whenever there is a security problem with modules or core code. Additionally, if you enable the Update Status module, Drupal will inform you whenever a module or core code has been updated. You can also configure watchdog to send you an email/sms/etc whenever the system logs "update available".

If you use the devel module's macro function, you can automate the entire process of setting up and configuring a module. You may also consider developing an install profile if you want to enable and configure a specific set of modules for a specific kind of site (eg: blog, cms, forums, etc).

BTW, you don't need to run update.php when you first install a module, only when you update a module.

Drupal has multisite capabailities that allows you to run multiple sites off one codebase. If you set up your file directory structure using best practices and use modules such as drush, you can easily and quickly update mutliple sites. I have a few scripts I've written that can update the 20+ Drupal I host in less than 10 minutes.

Regarding security, I suggest signing up for the security email, it's sent out whenever there is a security problem with modules or core code. Additionally, if you enable the Update Status module, Drupal will inform you whenever a module or core code has been updated. You can also configure watchdog to send you an email/sms/etc whenever the system logs "update available".

If you use the devel module's macro function, you can automate the entire process of setting up and configuring a module. You may also consider developing an install profile if you want to enable and configure a specific set of modules for a specific kind of site (eg: blog, cms, forums, etc).

BTW, you don't need to run update.php when you first install a module, only when you update a module.

Drupal has multisite capabailities that allows you to run multiple sites off one codebase. If you set up your file directory structure using best practices and use modules such as drush, you can easily and quickly update mutliple sites. I have a few scripts I've written that can update the 20+ Drupal I host in less than 10 minutes.

Regarding security, I suggest signing up for the security email, it's sent out whenever there is a security problem with modules or core code. Additionally, if you enable the Update Status module, Drupal will inform you whenever a module or core code has been updated. You can also configure watchdog to send you an email/sms/etc whenever the system logs "update available".

If you use the devel module's macro function, you can automate the entire process of setting up and configuring a module. You may also consider developing an install profile if you want to enable and configure a specific set of modules for a specific kind of site (eg: blog, cms, forums, etc).

BTW, you don't need to run update.php when you first install a module, only when you update a module.

I've used Project + Project Issue Tracking with success.
http://drupal.org/project/project
http://drupal.org/project/project_issue.

Everything else (except Gantt charts) could be created as content pages within the project.

For a more integrated system, I'm a fan of Trac, which is Python, not PHP. The wiki markup linking of Trac is worth it on its own.

I've used Project + Project Issue Tracking with success.
http://drupal.org/project/project
http://drupal.org/project/project_issue.

Everything else (except Gantt charts) could be created as content pages within the project.

For a more integrated system, I'm a fan of Trac, which is Python, not PHP. The wiki markup linking of Trac is worth it on its own.

I haven't tried it, but stumbled across it today.

http://drupal.org/project/storm

Disclaimer: I am one of the book authors (Angela - hi! :))

All of us are contributors to the Drupal handbook. In fact, Addison Berry is the Drupal project's documentation team coordinator. We definitely did NOT want to write a book that simply packaged up the Drupal community's hard work and slapped a $50 price tag on it. :P

The Drupal handbook is a fantastic resource, and is very useful to get you past installation and upgrading hurdles, provides collection of "snippets" for doing common (and not so common) tasks code-wise, is a great reference for Drupal developers, and offers many other things. So to that extent, yes. Chapters 1 (Intro to Drupal) and Appendix A (Installing/Upgrading) could be easily gleaned with the free, readily-available community documentation. If all you want to do is learn how to install Drupal and get a simple vocabulary lesson, do not buy this book! :) Read http://drupal.org/getting-started.

However, something the Drupal handbook is not very good for is a project-based, soup-to-nuts, "Here's how you DO stuff in Drupal." Nor for "here are the modules that are awesome and here are modules that are less awesome, and here's why this one is awesome for certain things but not others." A cohesive guide on this type of information is single-handedly the biggest obstacle people getting started with Drupal face, and is something that really doesn't lend itself well to 500+ documentation contributors scattered across the globe writing piece-meal page-by-page.

And that stuff is the focus of the book.

http://drupal.org/handbooks

Web Am Hard, and O'Reilly really knows how to capitalize on those who can't seek out information on their own, I respect anyone who capitalizes on the ignorance of others when the ignorance involves someone doing something on the web while at the same time being unable to use a search engine.

This either means that the username and password information in your settings.php file is incorrect or we can't contact the MySQL database server. This could mean your hosting provider's database server is down.

The MySQL error was: Too many connections.

Currently, the username is cw_blogs and the database server is 10.10.10.93.

• Are you sure you have the correct username and password?
• Are you sure that you have typed the correct hostname?
• Are you sure that the database server is running?

For more help, see the Installation and upgrading handbook. If you are unsure what these terms mean you should probably contact your hosting provider.

Arguably, it is Mollom. Especially if you are using Drupal.

Askimet is 'rotting on th evine' in many ways - including development updates. Mollom is a commercial web service, with a free version for non-profit and small volume sites/users.

The Drupal module is explained here:
http://drupal.org/project/mollom

The Mollom site:
http://mollom.com/

Outside of drupal.org, the guys at Lullabot have some awesome resources (articles, videos, podcast).

Drupal has you covered.

Anything you need to know about Drupal itself can be found in the links on that page. I recommend their beginner's cookbook as a starting place.

Drupal has you covered.

Anything you need to know about Drupal itself can be found in the links on that page. I recommend their beginner's cookbook as a starting place.

• Don't try to do everything yourself. Subcontract to other developers with complementary strengths who play nice with others: a couple of graphic designers, maybe a copywriter, sysadmin, or sales/accounts/office admin genius.
• Don't try to support too many products/platforms. If you use a different tool for every project, just keeping up with security updates will either become a full time job, or else you will get hacked at some point (I did). Life got a lot easier for me when I decided to specialise in Drupal.
• Get yourself a VPS or two. Don't bother with shared hosting - it's too expensive and limited. Your clients' hosting fees should pay for the effort _you_ put into keeping their sites ticking over, not for your hosting provider's cPanel licenses.
• About 20% of your time will be spent on technical work. The rest will be negotiating and hand-holding. You've got to develop some social skills.
• Insist on using a professional graphic designer (unless you're a graphic design genius yourself). No matter how adamantly a client initially insists that the look of their site isn't important, they will change their mind.
• Pick your clients carefully. Don't be afraid to say no. Unless you're a scam artist, say no to anybody who proudly proclaims their computer illiteracy. If they don't understand what you do, they won't appreciate it. Likewise avoid clients who think they need a website, but don't know why. Ask them what they want to achieve with the project.
• You probably won't find small/medium clients who will be happy with paying per hour. Demand a 50% deposit at commencement of work, plus timely delivery of whatever you need from them to complete the job.
• Don't take on anything that you think will take more than a fortnight's work, for which you should quote four to six weeks. Every project takes longer than you would expect, so if you expect something will take a couple of months, you may be out of business before you get paid. Split large projects into smaller stages if necessary. Even the best clients (not to mention developers) will have a tendency towards feature creep. Make it clear that additional ideas, no matter how brilliant, are for later stages of development. Throw around some buzzwords like "agile" and "iterative".
• Don't expect to do more than four billable hours a day. Don't let yourself burn out, and keep it interesting. If you don't do a lot of reading and stretch yourself with the occasional hobby/charity project with features that paying clients won't generally ask for, you'll be a miserable dinosaur in three years.
• Mind you, don't do discounts/freebies unless you really believe in the cause. If you wouldn't do a fun run, sell raffle tickets, or shave your head for them, don't do a website for them. Be clear about the limits of what you'll do.
• Did I mention you should develop with Drupal? Check out this awesome presentation on catering to small clients with Drupal.
• Catch up on the Rissington podcast. They're more graphic design focused, but have lots of useful tips for dealing with clients and organising your business, amusingly delivered, and advice about cheese.

• Don't try to do everything yourself. Subcontract to other developers with complementary strengths who play nice with others: a couple of graphic designers, maybe a copywriter, sysadmin, or sales/accounts/office admin genius.
• Don't try to support too many products/platforms. If you use a different tool for every project, just keeping up with security updates will either become a full time job, or else you will get hacked at some point (I did). Life got a lot easier for me when I decided to specialise in Drupal.
• Get yourself a VPS or two. Don't bother with shared hosting - it's too expensive and limited. Your clients' hosting fees should pay for the effort _you_ put into keeping their sites ticking over, not for your hosting provider's cPanel licenses.
• About 20% of your time will be spent on technical work. The rest will be negotiating and hand-holding. You've got to develop some social skills.
• Insist on using a professional graphic designer (unless you're a graphic design genius yourself). No matter how adamantly a client initially insists that the look of their site isn't important, they will change their mind.
• Pick your clients carefully. Don't be afraid to say no. Unless you're a scam artist, say no to anybody who proudly proclaims their computer illiteracy. If they don't understand what you do, they won't appreciate it. Likewise avoid clients who think they need a website, but don't know why. Ask them what they want to achieve with the project.
• You probably won't find small/medium clients who will be happy with paying per hour. Demand a 50% deposit at commencement of work, plus timely delivery of whatever you need from them to complete the job.
• Don't take on anything that you think will take more than a fortnight's work, for which you should quote four to six weeks. Every project takes longer than you would expect, so if you expect something will take a couple of months, you may be out of business before you get paid. Split large projects into smaller stages if necessary. Even the best clients (not to mention developers) will have a tendency towards feature creep. Make it clear that additional ideas, no matter how brilliant, are for later stages of development. Throw around some buzzwords like "agile" and "iterative".
• Don't expect to do more than four billable hours a day. Don't let yourself burn out, and keep it interesting. If you don't do a lot of reading and stretch yourself with the occasional hobby/charity project with features that paying clients won't generally ask for, you'll be a miserable dinosaur in three years.
• Mind you, don't do discounts/freebies unless you really believe in the cause. If you wouldn't do a fun run, sell raffle tickets, or shave your head for them, don't do a website for them. Be clear about the limits of what you'll do.
• Did I mention you should develop with Drupal? Check out this awesome presentation on catering to small clients with Drupal.
• Catch up on the Rissington podcast. They're more graphic design focused, but have lots of useful tips for dealing with clients and organising your business, amusingly delivered, and advice about cheese.

When you say 'old' it depends what you want to run on them.
As a developer I use a whole range of systems, and I don't throw old machines away, I use them for testing.

• My main desktop is a Quad core AMD Phenom with 8G of memory
• Sitting next to that are two AMD Athlon machines, each with 4G of memory

I also have

• Four Pentium III machines with 512M of memory
• Two AMD K6 machines with 256M of memory
• Four Pentium I (yes one) machines with 64M of memory

A Pentium III machine with 512M of memory is quite capable of running a fairly complex website. I use them to test websites developed using the Drupal content management system. If your website won't load and run in 512M of memory - you are probably doing something wrong.

In the past I have used Xen VMs, but at the time I found it tricky to setup (from what I have seen it has improved a lot since then, so this may be a better option now). For setting up a simple test system, it worked out easier to fire up one of the old machines and run the tests on that.
If I need to setup a test system that other members of our team can access, I use rented VMs from one of the cloud providers, FlexiScale, SliceHost or Amazon EC2.

One thing I would recommend is that you never configure a machine by hand. Everything should be automatic, using shell scripts or equivalent to setup the machines. Everything, including the scripts for installing packages and configuring the system should be in source control.

To setup a new set of tests, I start by writing a shell script that will install and configure all the components needed to run the tests. It will take a while to create the first few scripts, but you will gradually build up a library of functions that you can re-use. Someone else has already mentioned using Puppet and Cobbler to achieve the same thing. Unfortunately they weren't around when I started doing this. I haven't used either of them yet, but I hope to experiment with them fairly soon.

Whichever system you use, automating the install and configuration will save you a huge amount of time in the long run. Using my library of configuration scripts, I can setup and configure a new test system in a matter of minutes. The configuration scripts are designed to be portable, so I can use the same tools on one of my local test machines, or on an external VM hosted by a cloud provider.

As to what I use the Pentium I machines for - stress testing. I write Java web services for a UK eScience project, processing large (Tbyte) data sets. One of the things I need to check is the webservice should never try to load the entire dataset into memory. It should process the data bit at a time, and free up resources as soon as it has finished with them. As a stress test, I deploy a webservice on one of the tiny 64M machines, and then run multiple clients on the bigger more capable machines to hammer it into the ground, repeatedly, day after day for a week. If my webservice can process Gbyte data sets on a Pentium I machine that only has 64M of memory - without grinding to a halt. Then I can be fairly confident that when the same webservice is deployed on a multi core machine with Gbytes of memory it will probably be able to cope with the kind of load our scientists intend to throw at it.

Summary : Keep the old machines and learn how to setup, configure and use them as test machines. In the process you will encounter many of the problems that your developers and sys admins have to cope with on a daily basis, and you will be much better placed to be able t

...in fact, I would *expect* Google to do this before implementing OpenID. The fact is, OpenID has some security issues:

http://www.gnucitizen.org/blog/hijacking-openid-enabled-accounts/
http://drupal.org/node/280592
http://seclists.org/fulldisclosure/2008/Aug/0123.html

What do you know, the last one was submitted by Google's own Ben Laurie of Google's Applied Security team. They have obviously been assessing the security of this product and we can conclude what the results were. There is no way Google will implement vulnerable code, if OpenID 1/2 is insecure (it is) and needs to be redesigned in order to become secure then so be it. The real problem IMO is that Microsoft *did* implement a system that is flawed.

When Google releases their (hopefully) secure version, I predict everyone will move to that and like it.

Are you this paranoid and racist in real life, or just online?

I guess there's only one way to find out. Parent's real name is Christophe Devriese. His email is Christophe.Devriese@student.kuleuven.ac.be and he attends Katholieke Universiteit Leuven.

Still feel like publishing your insane ramblings?

So you've used Drupal then? How do you find it?

How do I find it? I find it here.

Haha, I kill myself. No seriously though, I find it to be quite a useful system. What I find irritating is the online documentation and the Drupal programmers' proclivity for changing things for seemingly tenuous or no reason, creating unnecessary headaches for those who must now update their own modules.

Anyone wanting to maintaining backwards compatibility for whatever reasons is in for some headaches.

If you have the book handy I find that the problems are minimized. Owning the book that develops against version 5 I balk at having to buy a new book for version 6 but it looks like I will have to as problems just keep arising and finding answers takes time.

Maybe I'm just a cynic but it makes me think that the changes and incomplete and/or outdated online docs are an intentional plot to sell more books.

But I will say that if you can get past the initial bumps and potholes on the path to learning Drupal it can be quite pleasant to use and develop for. YMMV but in my experience until they document things properly on drupal.org the book, while not perfect, is essential and conducive to productivity. You will lose less hair and accomplish more in less time.

Like most technologies that get books, Drupal does have great online documentation. I think the idea here is that the author can give some sort of expert advice/explanation/whatever that goes above and beyond the online docs.

http://drupal.org/handbooks

I reminded of the Drupal module Ubercart. Particularly since the strapline of the Ubercart project is One cart to rule them all. Or in this case, One cart to pwn them all.

CK-ERP (Open Source ERP / CRM / MRP) v.0.21.1 released

Use Drupal. It's like PHP, but with all the shit bits papered over. It's also a proper framework, unlike Zend.

For example drupal

And while you are at it, you may also look at their product. Wheel reinvention is not a good thing.

API: http://api.drupal.org/

Unit tests: http://www.lullabot.com/articles/introduction-unit-testing

Upgrading cues: http://drupal.org/project/coder

API: http://api.drupal.org/

Unit tests: http://www.lullabot.com/articles/introduction-unit-testing

Upgrading cues: http://drupal.org/project/coder

The whole problem with Drupal (well, the main problem, every popular software of any size is going to have lots of problems) is the project leads' refusal to make any kind of real API.

At least if they'd use an API for core functions this problem would be partially mitigated. They've been talking about an API for years, but no one wants to do it, and to be honest I think this suits the people at the top of Drupal (as opposed to everyone else) just fine - it's certainly not a high priority for them.

What's this, if not an API? api.drupal.org

The API is supposedly stable for each major version number, and even as a not-very-involved Drupal developer and Drupal user, reading the API changes and updating other author's modules for them on the occasions they've needed the help has been a breeze.

The whole problem with Drupal (well, the main problem, every popular software of any size is going to have lots of problems) is the project leads' refusal to make any kind of real API.

At least if they'd use an API for core functions this problem would be partially mitigated. They've been talking about an API for years, but no one wants to do it, and to be honest I think this suits the people at the top of Drupal (as opposed to everyone else) just fine - it's certainly not a high priority for them.

What's this, if not an API? api.drupal.org

The API is supposedly stable for each major version number, and even as a not-very-involved Drupal developer and Drupal user, reading the API changes and updating other author's modules for them on the occasions they've needed the help has been a breeze.

I think you will find:
- Drupal uses UTF8 by default
- Drupal has a robust multilanguage approach.
- Drupal includes a COD module and doesn't assume a particular payment flow.
- The Drupal developers are international. In fact this can be a downside since a good portion of the ec subsystem was developed in Australia (thank you Gordon), and at times it needs to be massaged. I'm thinking of tax issues.

IMO, having implemented Drupal-based ecommerce systems a few times now, I'd say that it's just short of ready for prime-time, and that this book is premature: a case of a publisher trying to climb on a band wagon. (I have no comment on the content of the book - I haven't read it.) I find that Drupal ecommerce is not yet slick enough that I don't worry about details that I shouldn't have to worry about, on the other hand I trust it enough to have implemented it for people who are not technical, and it does contain some really useful specialist product types.

The rate at which Drupal and subsystems such as the ecommerce subsystem improve means that the shortcomings will be fixed inside 18 months.

I'd say that the most important shortcomings are:

Drupal ecommerce does not yet have multi-currency options: it assumes pricing is in a single currency. There are modules which tell you pricing in alternative currencies, but the final bill is in the admin chosen basis currency. If you are in the US, buying from Japan, expect to see a bill in Yen on your credit card statement.

Drupal wants people to be logged in. Anonymous purchasing is a second-class citizen. IMO forcing users through a registration process before they can give you money is bad for business.

There is no nice standard for international addressing, and Drupal suffers from this. EC address management is not integrated with other address-orientated modules.

But...

It Drupal and EC are remarkably flexible. Anything can be a product. It's open source and you can add new stuff: I've built a number of modules including a specialist shipping module for Royal Mail shipping. I haven't found it to be a problem.

Someone complained about the lack of an API. In fact Drupal has a well-developed well-structured API. It's one of the reasons that it has coped well with growth. Try http://api.drupal.org/. The api is largely stable despite the established Drupal policy that backward compatibility is a nice-to-have rather than a given: I've used modules built for later versions which transferred to earlier versions without problems. Your mileage may vary, and of course things change as the system grows. But the changes between versions are well documented. I do think that the established callback injection points could be better documented. But I'd say the complaint about API was uninformed.

In light of the current Drupal release being 6.3, I hope this review will prompt the developers to shift priorities to getting a v6 compatible module out for testing.

In the mean time, you might want to take a look at Ubercart, another Drupal module.