An overview of simple tools, practises and services any software house or development team should consider - add to its work cycle.

1. Services, tools &
practices for a software
house
or...how to make your development team
effective and happy
Paris Apostolopoulos

2. About me ...
● 'Met' Java back in 1999..fell in love!Java career
started 2001 (intern)
● 2003 co-founding JHUG / Administrator
● Focus on J2EE and BPM-N (lately)
● I enjoy team work, envy developers, dislike
incompetent management :P
● I love effective procedures and keeping things in
order!
● @javapapo (twitter)
● javapapo.blogspot.com (blog)
● www.linkedin.com/in/javaneze
● javapapo@mac.com

3. Agenda
● Why?
● Let's talk about us - the developers
● The software development house
○ Code repository versioning system
○ Issue / Bug Tracker
○ Wiki / Knowledge base
○ Build Server / Continuous Integration
○ Testing
○ Code Quality
○ Training developers
● Other important things
○ Project structure and build tools
○ The issue of security

4. Why? (I am doing this
presentation)

5. Why? ..2
● Why companies still ignore basic tools and
practises of moden software development
methodologies?
● Is it rocket science or difficult to implement?
○ I dont think so...
● Why developers do not push things towards
improvement? (lazy?dissapointed?)
● Why developers get used of an inefficient
software development cycle? They embrace
it at the end of the day.

6. Why? ..3
● Don't we have enough books about modern
software development?
● Is it software developers the case or IT
managers? Is there a disconnect?
● We want faster, safer, robust and flexible
software but..do we really work towards this
goal?
● Who to blame? Do we need to blame
anyone?

7. Do we fit into this category?
"One category of profession is
driven by the mediocre, the
average, and the middle-of-the-
road. In it, the mediocre is
collectively consequential."
Nassim Nicholas Taleb, The Black
Swan

8. What I really want from you today
● It is not only about a listing several tools and
techniques, that I am sure many of you know.
● It is not about blaming managers, developers or
anyone else.
● Ask yourself, I am really working in the most
effective and proper way?
● Can I introduce change? Have I tried?
● Do I want to change? Use proper tools, become
more effective?
● Is there any check list of things? (yes follow up)

10. Code repository / Versioning
System
● Do you have one? ....(hope so)
● Select the appropriate type depending on
your needs
○ VSS, CVS, SVN, Git, Merculiar
● $$ - Some of them are completely free!
● It's 2011, do we still need to talk about why
we need one??

11. Code repository / Versioning
System
● Do you Back up?
○ A code repository with no proper
backup is just like a skydiver with no
back up parachute! #fact
● Consider remote access?
● Have you invested enough time to learn
about your versioning system?
○ no matter if you have the most
advanced tool if you dont how to
proplery use it you will not make
much out of it. #fact

12. Issue / Bug Tracker
● How dissapointing ...not to
have one.
● People still use their heads,
emails or their log books to
note, remember and handle
issues.
○ A tracker does it better! #fact
● How many times you have
heard the following..
○ 'Send me an email about that'

13. Issue / Bug Tracker
● Which one? ($)
○ Many choices, free and commercial
○ JIRA, Trac, Bugzzilla,YouTrack, Redmine etc.
● Back up
○ Yes, you need to have a proper back up too.
● Invest some time or even force your people to use it -
there great managerial advantages over that!
● Try to reduce the amount of project related
information floating through emails!

14. Issue / Bug Tracker
● Developers & Managers get a system where they
can track the past ,monitor the present and plan
effectively for the future.
● Metrics regarding work allocation and performance
can be derived.
● Increase flexibility and dynamics of the development
team to address sudden changes or problems.
● Learn from your...tracked mistakes ;) #fact
● We usually forget issues resolved a week ago. #fact

15. Wiki - Knowledge Base
● We assume that there is some sort of analysis +
documentation about your software (?)..is it?
○ Saying ' we are agile and we dont waste our time with such
stuff' IS NOT cool! #fact
● Where do you store, develop and maintain this
information?
● Unfortunately many companies/teams still use
emails/ oral communication or Word documents.
● We live in the internet + collaboration era - wake up!!

16. Wiki - Knowledge Base
● There are many free or paid products or event
services plain wiki installations, MediaWiki,
Confluence
● Make them available and open to your team.
● Dont reside on closed standards or systems.
● Keep it simple.
● Try to capture all related documentation and
information regarding a project.
● Inter connect your Issue Tracker with your wiki
● Remote access : )

17. Wiki - Knowledge Base
● + You dont need so many licenses for word editing
software.
● You can still share information with outsiders.
● You can 'bring in' your customers to their specific
island on your knowledge base.
● Try to apply it on a company level- not only on
software development teams.

18. Build Server - Continuous
Integration
geeks
Code
Repository
Watch/Pull/Monitor
Customers Code
Release Build.
Provide Identify Build
Updates Builder Errors
Server
Test
Run Tests

19. Build Server - Continuous
Integration
'In essense, Continuous Integration is about reducing
risk, providing faster feedback.It is designed to help
identify and fix integration and regression issues faster,
resulting in smoother, quicker delivery and fewer bugs.'
Jenkins,The Definite Guide,Chapter 1
J.Ferguson Smart,Oreilly

20. Build Server - Continuous
Integration
● Potential solutions
○ Hudson/Jenkins,CruiseControl,Contunuum,
○ TeamCity, Bamboo
● Eventually a build server does things behind the
curtains - you just have to make sure it works and
configure it properly.
● It is the real implementation of Cont.Integration as a
practise.
● Beware of hardware requirements.
● Potential services in the cloud-internet.

21. Testing....a sad story

22. Testing..unit testing
● There are many types of testing, unit, functional,
cross cutting, integration.
● We will focus on unit tests.
● It is not the holy grail. A pragmatic approach.
● We can't ignore it!
● For the managers: Learn to properly add testing on
project estimates.
● For Developers: We get lazy sometimes, lets face it.

23. Testing..unit testing
● Tools / Frameworks
○ JUnit
○ TestNG
○ JMock
○ Mockito (#win)
○ Ejb3Unit
○ XMLUnit
○ HTMLUnit

24. Testing..unit testing
● Tools / Frameworks - Functional Testing
○ Selenium
○ Sahi
○ JMeter (Perfomance & Testing)
● Code Coverage
○ Meaning: how much of our code is 'covered' by
tests.
○ EMMA, Coberatura, Clover etc

25. Code Quality

26. Code Quality
● Another sad story... (#fail)
● It is still considered as a nice to have/ nice to check
practise by many managers and even developers.
● There are tools that can help you tackle time, effort
and estimate problems in order to monitor and
preserve the quality of the code.
● Tools that scan your code base and identify many
basic or advanced problems, sometimes perfomance
problems or potential concurrency bugs.

27. Code Quality..for Java Developers
● FindBugs
● PMD
● CheckStyle
● JDepend
● Sonar
● Prevent
● EclEmma
Most of them can be easily integrated to your IDE. It is
just a click away!

28. Training
● Training should be encouraged in an personal level +
promoted company wise.
● Skills need to be updated.
● Companies need to leverage the benefits of training
their development teams¨
○ Internal
○ Conferences
○ Support local communities

29. Training
● Introduce a company library
○ Buy at least one or two books every month and add
them to the library.
○ Encourage people to read.
● Engage developers internally with coding sessions and
presentations.
● Give space to those that are willing to experiment with
something new, let them bring back their experience.
● Promote the do-ers.
● Teach young developers...the power of the force ;)

30. Some extra things to consider...

31. Project structure / Building tools
● Please stop - creating and building projects using
your IDE as a building tool!
● You introduce a technical dependency - increase
maintenance effort and your build 'system' may be
become obsolete at any time.

32. Project structure / Building tools
● Java developers are lucky enough to have a variety
of tools that handle buidling, structure and library
dependencies.
● We have some sort of 'standards'
● The main goals for your project must be
○ to be complete IDE un-aware
○ can be built in any platform easily
○ building activitity to be easily maintained or
changed
● Keep it simple

33. Project structure / Building tools
● Tools and frameworks to consider
○ Apache Ant
○ Apache Maven
○ Apache Ivy
○ Gradle
○ Gant
○ Buildr

34. Project structure / Building tools
● Java developers are lucky enough to have a variety
of tools that handle build, structure and library
dependencies.
● We have some sort of 'standards'.
● The main goals for your project must be
○ to be complete IDE un-aware
○ can be built in any platform easily
○ building activitity to be easily maintained or
changed
● Keep it simple

35. Secure...coding
● Unfortunately it is one of our lowest priorities.
● It is obvious, since security threats appear in all sorts
of software- all the time.We still suffer from them.
● We need to embrace the principles of security in our
architecture and actual software development
activity.

36. Secure...coding
● Content provided by Dimitris Stergiou
○ http://www.linkedin.com/in/dimitriosstergiou
○ @dstergiou

37. Secure...coding
● OWASP (owasp.org)
○ free and open application security community
● Think and introduce security requirements for your
project - before implementation.
● Resources for Security testing
○ OWASP Top 10 Wev Application Security Issues
○ OWASP Testing Guide v3.v4

38. Secure...coding
● Tools (static)
○ Peer review: Check each other's code.
○ Static Code Analysis (http://en.wikipedia.
)
org/wiki/List_of_tools_for_static_code_analysis
○ Commercial Static code analysis
■ IBM (Ounce Labs)
■ HP (Fortify) - in the cloud as well
■ Veracode

39. Secure...coding
● Tools (dynamic testing)
○ Manual Penetration testing
○ MITM Proxies ( paros, burp, owasp zap, charles)
○ Web Application scanners
■ Nikto
■ w3af
■ Arachni
■ Skipfish
■ Websecurify
■ sqlamp (sql injections

40. Secure...coding
● People and all that Jazz
○ Awareness
○ Training
○ Development
○ Testing
○ Goto Awareness ;)

41. To conclude
● Do your own check list - and see on
how many of the above apply to your
working enviroment
● Ask yourself what would you like to
change or improve?
Try to change it
● Spread the word

42. Thanks, any questions?

43. References
● This talk was based on the following
posts
○ Part 1:http://javapapo.blogspot.com/2011/06/services-practises-and-tools-that.html
○ Part 2:http://javapapo.blogspot.com/2011/06/services-practices-and-tools-that.html
○ Part 3:http://javapapo.blogspot.com/2011/06/services-practices-and-tools-that_27.html
○ Part 4:http://javapapo.blogspot.com/2011/06/services-practises-and-tools-that_27.htm

44. References - books
● Jenkins, The Definite Guide, J.Ferguson Smart, Oreilly
● Agile ALM, Leighweight tools, Agile strategies, M.Huttermann, Manning
● Git (Communit Book) -book.git-scm.com
● Version Control with Subversion, svnbook.red-bean.com
● Continuous Integration,Improving software quality and reducing risk,
Martin Fowler.
● Ant in Action, Manning
● Maven the Complete reference,
○ http://www.sonatype.com/books/mvnref-book/reference/
● JUnit in Action, Manning
● Maven -the definite guide, Oreilly