From a personal perspective the first thing I'd fix is replacing XP
with Ubuntu -- the lack of responsiveness and decent CLI tools tends to
drive me crazy (no, Cygwin is not a proper UNIX environment).
But let's think more practical. Number one I would sell is the move from
CVS to SVN. CVS is just too scary due to it's lack of atomic commits.
The consistent revision number across the repository is another nice
feature in SVN. While I agree with other posters that there are
technically superior options, I wouldn't even propose them based on the
description of the organizational culture. SVN makes me swear sometimes,
but it is leagues better than CVS. Setting up an SVN/trac combo is
pretty straightforward, although it of course means someone has to deal
with security patches and backups.
Talking about trac: I really miss an issue tracker in your list. JIRA is
one option, I personally find trac sufficient for most projects. From
what I read it might not be for your project, but it would certainly be
a step forward. And it kind of integrates with Eclipse if you use Mylyn
(half the time it just opens the web browser inside Eclipse, but that's
not too bad). Another nice thing about trac is that it adds value by
just being there. Even if you don't use the tickets or the wiki, it
already allows browsing the code, following the commit messages and even
full-text search on them (that of course assumes sensible commit
messages are there to begin with).
If you can convince people to use SVN instead of CVS I'd set up an
SVN/trac box and then quietly start using that myself. I would not
directly introduce all of trac's features since that might well be too
much change at once. Sell SVN to the business by making a case how
expensive a broken commit in CVS can be. Even assuming daily backups on
the CVS server it can easily stop development for 2 days (restore old
state, try to figure out what had been done since then, repeat those
things).
The other thing you can do is to introduce a continuous integration
server (I strongly recommend Hudson). That reinforces the unit testing
since they will run regularly. It is also something people can ignore as
long as you don't force them, which means you can convert some less
conservative colleagues first, and then try to change policy once there
is enough momentum. There is also value to be added if you can automate
deployment (at least to the test environments). All this doesn't require
attention by anyone else, which means it is a good submarine project.
Another thing I would personally really like to change is replacing Ant
with Maven. But that is non-trivial, I'd certainly tackle the VCS and CI
parts first.
A potentially easy, but not all that important change: replace FileZilla
with WinSCP (and thus FTP with SCP/SFTP). One less server component,
potentially better ease of use on the client (assuming keys are used).
In general: I try to tackle the things that I can change for myself
without affecting others first (the CVS->SVN change being the exception
here). Afterwards I try to lead by example, not pushing anyone much.
At my workplace I have set up Hudson very early on, I started new
projects on Maven (we have enough freedom for that), later added
Artifactory. All that means I wear the sysadmin hat quite often (despite
this not being part of my job description), but it pays off in the
longer term. About a year later most of the teams are using that
infrastructure now. Of course my environment is much less conservative:
we are developing products for scientist at a university, some
colleagues are pretty conservative, but since we have lots of
independent small projects things can move at varying speeds.
Peter
On 23/04/10 22:43, Vince O'Sullivan wrote:
My current and ongoing role involves developing web based application
for internal corporate use. The majority of applications are one-man
end-to-end developments though some may have two or (for the really
big stuff) three people involved. The people that I work with are
good developers but have hideously outdated working practices (I still
get handed Java classes with 300+ line methods, for instance). I want
to clean the place up, starting with the development tools. Listed
below are some of the tools that we currently use for software
development:
Operating System:
Developing on Windows XP on Dell hardware (laptops and desktops).
Deploying to Web app servers on Unix boxes.
No option to change this and anyway, it's the least of my problems.
Archiving and Version Control:
CVS - Getting everyone to use it was a key achievement for me in
2008.
I think I'd be lynched if I now said "Actually, I think we should
be using git/Mercurial/Subversion/etc.".
CVS has the advantage of being centrally hosted by the company.
I'm not sure I want the extra
overhead of running my own alternative but maybe.
Build Tool:
Ant - Occasionally hand built but usually Eclipse generated.
Automated End-to-End Builds:
I can do them (in a couple of stages), others just export a war
file from eclipse and load it onto the server and...
IDE:
Eclipse - I use the latest development build but most here use
whatever the latest company approved standard release was when they
received their current machine.
Language:
Java: I've dabbled in Scala and Groovy. Several other people here
are aware non-Java languages (other than basic) exist.
Currently version 1.5. I got 1.6 loaded onto the server box
last year but we haven't developed to it yet.
I cannot hand off projects in other languages to the
maintenance groups.
Testing:
JUnit: I use it. The others are suitably impressed but not
convinced it's worth "coding everything twice".
JMock: I use and love it but until the others even start using
JUnit, there's no sense in pushing it.
Web Stuff:
HTML and CSS: Hand made (by software developers like me) with many
bastardised cut and paste inclusions.
Followed with long sessions of UA where they kick back all the
stuff that looks like it was designed by
a five-year-old in the 1990s.
Web Hosting:
Internally on a corporately maintained and backed up Unix box
running Tomcat 6.
More Web Stuff:
An unholy mixture of JSP and JSF, bulked out with Primefaces for
some extra glitzy bling.
Database:
Oracle: Yay, we finally got the last developer to stop using MS
Access last year (by banning it)!
(That guy only writes Excel VBA so he's out of the loop anyway.)
It's a corporate database and very well maintained though I haven't
figured out what planet the DBAs are from.
Other stuff:
FileZilla, PuTTY, Beyond Compare, SQL Developer, TortoiseCVS....
the list goes on.
So. This lots does work (more or less) and (I don't think) that it's
as bad as it sounds, but it really isn't a good situation. What I'm
looking for is ideas on how to clean all this development environment
up. It's a mess of good ideas that are currently badly integrated.
There are just too many different and independent components to this
environment to persuade people that adopting it is progress, and the
learning curve is endless.
I'm looking for -sensible - ideas on how to clean all this up. What
technologies to drop or swap and how best to create a complete
integrated development environment (in the non-eclipse/NetBeans
sense).
Any suggestions welcome.
--
You received this message because you are subscribed to the Google Groups "The Java
Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
