Ten things no one ever told you about Hudson:
- It’s extremely easy to install (unzip the file and that’s it)
- It can be configured entirely from its friendly Web UI (no XML required)
- It has an attractive dashboard with colourful and meaningful icons
- It’s extremely flexible
- It can be extended via plug-ins
- It offers a much better UI than CruiseControl
- It can execute Phing, Ant, Gant, NAnt and Maven build scripts
- It gives you clean readable URLs for most of its pages
- It has RSS, e-mail and IM integration
- It can distribute build/test loads to multiple computers
This tutorial guides you step-by-step through the fundamental concepts of Continuous Integration and Hudson. When you are done with this one-hour tutorial, you will understand the benefits of Continuous Integration as well as how to set up your environment.
Hope you like these recommendations and if you know of any other good tech-related video, then please let me know.
1. Developing Expertise: Herding Racehorses, Racing Sheep
One of my favourites. In this presentation Dave Thomas (The Pragmatic Programmer) talks about expanding people’s expertise in their domains of interest by not treating them uniformly as they had the same amount of knowledge and level of experience.
2. Real World Web Services
Another good presentation. In this one Scott Davis provides a pragmatic, down-to-earth introduction to Web services as used in the real world by public sites, including SOAP-based and REST examples.
Real World Web Services
3. CouchDB and me
This presentation is different, and that’s why I like it so much. Damien Katz shares his experiences and reminds people how difficult but at the same time gratifying is to be an open source developer. He talks about the history of CouchDB development from a very personal point of view. His inspirations for CouchDB and why he decided to move my wife and kids to a cheaper place and live off savings to build this thing.
CouchDB and me
4. Yahoo! Communities Architectures
In this presentation, Ian Flint tries to explain the infrastructure and architecture employed by Yahoo! to keep going a multitude of servers running of different platforms and offering different services. Very interesting!
Yahoo! Communities Architectures
Among the branching models used in software configuration management, the branch-by-purpose model offers better support for parallel development efforts and improved control of both planned and emergency software releases. If you want to improve software quality, you must first understand your software. What are its pieces? How are they organized and related to one another? If you do not understand your code base, your odds of updating it without breaking something are poor.
The Importance of Branching Models (PDF)
High-level Best Practices in Software Configuration Management
Here are two useful backlog templates provided by Agile Software Development. Both of them are in Excel format (XLS). Check them out:
It is far easier to kill an idea than to encourage it and turn it into a useful solution. Be on a constant watchout for putting down an idea too early without understanding the positive reasons for it being suggested. Hopefully you will see that there are many ways in which you can be constructive.
To kill an idea, say:
- It’s not part of your job
- That’s not what we do here
- Costs too much
- Against the company policy
- It’s not budgeted, maybe next year
- Let the other department handle that
- It is not our problem
- Why would you do something like that?
- We have been doing it another way for a long time and it works fine
- If it’s so good, why hasn’t someone suggested it already?
- Has anyone else tried it successfully?
- We have tried that before and it didn’t work
- Is anyone crazy enough to try that?
- We’re already doing that
To help an idea, say:
- Yes, and…
- Great, let’s try it
- How can we make time to see if it will work?
- What resources would we need to do it? Tell me more
- How can we make it work?
- What are the advantages?
- How can we remove the dis-advantages?
- What can I do to help this happen?
- I like it
- That sounds interesting, tell me more
- How can we convince everyone else?
36 steps to success as technical lead
- Define early on what success means for you, the team and the business.
- Believe in the project: idea, architecture, time, team.
- Understand the domain, the business requirements and the technical challenges.
- Know your team: strengths, weaknesses, ambitions and personalities.
- Have a plan as a result of a planning activity.
- Be part in the design of everything.
- Get your hands dirty and code.
- Act as a communication proxy for your team.
- Make sure everybody understands the big picture: their work has implications.
- Fight for architecture and design consistency.
How not to lead geeks
- Downplay training.
- Give no recognition.
- Plan too much overtime.
- Use management-speak.
- Try to be smarter than the geeks.
- Act inconsistently.
- Ignore the geeks.
- Make decisions without consulting them.
- Don’t give them tools.
- Forget that geeks are creative workers.
Nine things developers want more than money
- Being set up to succeed.
- Having excellent management.
- Learning new things.
- Exercising creativity and solving the right kind of problems.
- Having a voice.
- Being recognized for hard work.
- Building something that matters.
- Building software without an act of congress.
- Having few legacy constraints.
Top 10 ways to demotivate your programming team
- Set up impossible deadlines.
- Let them work overtime.
- Don’t allow breaks.
- Place a ban on laughing.
- Break the coffee machine.
- Don’t shield them from the dirty daily business.
- Don’t challenge them.
- Underpay them.
- Bribe them.
- Infiltrate a team member who is demotivated anyway.
Don’t bring me solutions, bring me problems
(Don’t tell me how you want it to work, tell me what you want it to do)
- Where all think alike, no one thinks very much.
- Suggesting solutions kills creativity.
- Don’t bring me solutions, bring me problems.
Classic mistakes enumerated
- Undermined motivation.
- Weak personnel.
- Uncontrolled problem employees.
- Adding people to a late project.
- Noisy, crowded offices.
- Friction between developers and customers.
- Unrealistic expectations.
- Lack of effective project sponsorship.
- Lack of stakeholder buy-in.
- Lack of user input.
- Politics placed over substance.
- Wishful thinking.
The practices discussed in this article are based on Ezequiel Cuellar’s observations. These practices will help any software development team as they come up against common obstacles. They will also contribute to a solid foundation for healthier development and help speed up production. The seven practices are:
- Improve business processes before starting development.
- Create a solid software development team.
- Improve processes for service requests.
- Minimize reporting of software metrics.
- Improve communication with the business team.
- Use the right programming language.
- Use the right IDE.
The practices target problems that are better addressed at the management level. Usually, developers can only report the issues to upper management for consideration. Because project managers have the necessary level of authorization, they are the ideal candidates to promote these practices within the organization.