Consider Trac. It combines a subversion repository browser, wiki and tickets for bugs and feature requests. It's not as sophisticated as some systems (lack of dependencies between tickets is a big problem). But the integration is well done and the interface pretty. See Catalyst as an example.

• Documentation standards (& possibly templates for the documents)
• Version control of documentation as well as code
• Testing guidelines & standards
• Peer review of designs.

One thing most people overlook, that I find extremely useful is to build EVERY application or library as if you were going to release it to CPAN. This has several advantages and takes almost no extra time once you get used to it. The main advantages are:

• You can leverage the existing install infrastructure to automatically handle dependicies for you.
• In your dist you can hold all of our associated documentation, database schemas, cron scripts, etc. all in one tar.gz.
• As one of my co-workers just started us using, you can use CPAN::Mini to help install applications and/or libraries on multiple servers easily.
• It makes each app consistent. You know what you'll find in bin/, in docs/, in sql/, in lib/... no surprises and it makes the programmer who has to maintain your code a year from now ( which is btw most likely you! ) have a much easier job.

Take a typical web app, you've got your Perl code, your database schema, your configuration information, and probably at least a few cron scripts.

By using something like module-starter and Module::Build you can automatically install your templates in say /usr/share/web-templates, your cron scripts into /opt/app/cron/, and drop your configuration into /etc/httpd/conf.d with a simple make install

If you aren't familiar with either Module::Build or ExtUtils::MakeMaker then there is a bit of a learning curve, but once you learn how to use these modules effectively, doing this adds a very trivial amount of time to each app and/or library. Trust me that once you start using it, you'll never want to work in an environment that doesn't.

Conversely, if you have no intentions of releasing your code to CPAN, you may decide to avoid the nightmare of the unnecessary, undocumented, unarchitected, unfathomable, unmaintainable, over-elaborate, rotting festering mess that is ExeUtils::MakeMaker completely.

And for anything you do have a hankering to release to CPAN, spend an hour or two trying to understand what the hell is going on when you run the Makefile.pl for any moderately complex CPAN module, and try to imagine the trouble you are going to have to incorporate any extra customs steps.

For example, say you would rather have your build process extract the files directly from your source code repository? Rather than having to do this as an extra manual step, with the inherent weakness of forcing the duplication of your source tree and/or imposing the convoluted pattern that is the 'blib' phenomena upon your source tree structure. Look hard and think very carefully how you would modify EU::MM to do this?

Of course, I (infamously) do not have any CPAN modules to my credit, so I may be just crying wolf, so I urge you to look at and think about the problems this route would cause you. Also, take a look around at some of the comments made about the ExtUtils::MakeMaker module by it's current maintainer.

And if the Module::Build route looks interesting, have a good look around at the internecine struggle between it's proponents and the EU::MM diehards.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

I find the typical Module::Build opponent’s argument that it’s not mature and won’t be for a long time to be quite disingenious. Only software which has users improves. The argument that you inflict pain on users is understandable, but for simple needs you can avoid that by way of create_makefile_pl => 'traditional'. And while users complain that there is no compatible PREFIX support, I always found it a mess to deal with as a user and applaud the coming of install_base.

The other option is Module::Install, which for some reason I can’t bring myself to like, even though everyone using it seems to rave about it. Last I looked, I couldn’t find much documentation, anyway.

Makeshifts last the longest.

Yes, you're crying wolf.

Forget EU::MM and Module::Build and just use Module::Install, which wraps BOTH of them as needed and makes writing installers almost trivial.

http://search.cpan.org/src/ADAMK/PPI-1.109/Makefile.PL

You example is bizarre... you only need to store the actual modules, the blib stuff (which is used for compiling and so on) only exists between when you run Makefile.PL and when you run make install. It never goes anywhere near the repository

As for doing things from the repository, we just use...


svn checkout http://..../project
cd project
perl Makefile.PL
make
make test
make install
[download]

My intent wasn't to promote ExtUtils::MakeMaker, I too have found it hard to work with for complex tasks, which is why I now use Module::Build and am going to be taking a hard look at Module::Install in the near future.

I also think you misunderstood most of my post. There is no duplication of your source tree, and no blib weirdness. Your source repository for a particular app *IS* your build environment. There is no need to have your build process checkout the source, your simply build a dist in your working copy.

To give a detailed example let's say I have a mod_perl application that I'm building called 'Foo'. I start off my application with module-starter and it creates the Foo/ tree for me with a lib/ ( where your code goes ) and the other various elements we're all accustomed to.

Once I've put in stubs for all of my various modules, Foo::Main, Foo::Admin::*, Foo::Model, etc... I then check this entire structure into my revision control system ( I use subversion ) and I'm done.

No blib weirdness ( incidentally this directory is only created when actually install your app ), no duplication of my source tree, no convoluted patters I can think of... unless of course you prefer to just drop everything in some very large directory without any organization.

Frank Wiles <frank@wiles.org>
http://www.wiles.org
http://www.revsys.com

I'll second that. Under Pressure was a very good book.

Code Complete should be required reading for every single programmer, regardless of how long they've been at it.

I've been programming for 20+ years and still found CC to be a great book. A lot of good tips/suggestions/reasoning in there, and very good explanation as to why those recommendations are what they are.

It doesn't need to be followed to the letter, but there are some major Best Practices in there, allowing you to choose and follows the ones best suited for you and your organization.

I read the original and actually would like to go back and read CC2 now, just to 1) Get some more info and 2) see what new changes are in it.

Under Pressure is out of print now I think but you can still buy it used on Amazon for super cheap. I thought it was definitely worth my time spent reading it.

I'm surprised no one has mentioned it yet -- get Damian Conway's "Perl Best Practices" and make that your style guide.

-- Argel

The poster actually did, just without links
2. Company Programming guidelines - (based on the perl best pactices book)
But it is definitely a good book and the links to it are good things.
Squibbie Pooh Ski Doo.

-Jeff

I like XP too. :D

I must admit that I'm still not using any of it. Just picked up a book about it few days ago. And many (basically all) things simply make sense.

Of course, I tried some things that it promotes on my own, before I even heard for XP. Like Pair Programming. I used that a lot on programming labs in High School and College. It works exactly as they say - two heads are better than one. One thinks locally (one that is typing the code) and the second thinks more globally while also checking for typos and doing other tasks like paperwork ...

Too bad I'm working as a freelancer so some of XP stuff simply wont work :(

---

Have you tried freelancing? Check out Scriptlance - I work there.

I am big fan of XP as well. At the very least, writing tests is *extremely* helpful, especially as your team grows.

Oh so true ... You may know a lot of things - like when you are reading a book you say "Boring - I know that.". But the real question is not if you know (about) it.
The question is: "Are you using it?"

In particular I have found that it is difficult to enforce regular code reviews.

But XP folks thought about that too :) For instance Pair Programming is a way that ensures a constant code review ...

---

Have you tried freelancing? Check out Scriptlance - I work there.

Thanks for the quick replies - I have ordered a couple of the books mentioned, so that I can swat up on the best way to approach the task of getting my department upto scratch. I am keen to put in some kind of monthly interpersonal code reviews - where by each member of the team reviews the others code to ensure that it follows the agreed standard, and suggest improvements etc.

My question is how do i put this into action with minimum resistance, certain members of the team i feel, would be resistant to change, and not so keen to better themselves/ their code, even though it is for the best.

Thanks
Dan

With CVS (not sure about other source control systems) you can add a hook during checkin that requires the name of the reviewer in the checkin message. Not foolproof of course, but certainly better than nothing.

I would add to your list the use of PAR and CPAN::DistroBuilder modules to help on packing your applications.