On Fri, Apr 23, 2010 at 9:03 PM, Jo Voordeckers <jo.voordeck...@gmail.com>wrote:
> I've been through a few of these sanitizing processes at the different > customers. The key to success is to go slow, introduce each component step > by step, let the people learn to appreciate each of the changes, one at a > time. It could take years to get where you want to be, but it's worth it! > > My suggested setup for your team: Eclipse(+WTP for tomcat deploys), SVN, > Hudson, Maven (+repo), JUnit+Cobertura+Mockito, JIRA. If you're willing to > spend a few extra bucks JRebel v3 cuts your code-build-deploy-test cycle by > a huge factor, resulting in fewer redeploys, so ultimately fewer > distractions and frustrations while developing web apps. > Why SVN? There's like a biiiiiillion other SCMs other there that are better. > > If supporting multiple IDE's is a goal, Maven is definitely the way to go. > > Good luck! > > Jo > > > On Fri, Apr 23, 2010 at 8:06 PM, Lloyd Meinholz <meinh...@javabilities.com > > wrote: > >> I am in a similar situation, maybe a rung or two down the evolutionary >> ladder. I would consider trying to introduce Jira to manage the projects and >> hudson and a CI server. Those are two great tools that can help the team >> (developers and managers). I've also found FindBugs to be helpful in keeping >> things in order. >> >> In the end though, I don't think that tools are going to help as much as >> getting everyone on the same or similar page in regards to "best practices" >> and development approaches. >> >> Lloyd >> >> >> On Fri, Apr 23, 2010 at 8:43 AM, Vince O'Sullivan >> <vjosulli...@gmail.com>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 javapo...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups.com> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/javaposse?hl=en. >>> >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "The Java Posse" group. >> To post to this group, send email to javapo...@googlegroups.com. >> To unsubscribe from this group, send email to >> javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/javaposse?hl=en. >> > > > > -- > - Jo > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to javapo...@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- Viktor Klang | "A complex system that works is invariably | found to have evolved from a simple system | that worked." - John Gall Akka - the Actor Kernel: Akkasource.org Twttr: twitter.com/viktorklang -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
