Felix liked to Get Things Done™. And through experience and what became an interactive idea and experience sharing productivity session, he explained mechanisms and methods that he has used to achieve the best results for projects in the shortest time possible.
Communication. While this means your team should be in contact, and that those contact points should be quality communication, it doesn't mean that instant communication is a requirement. Communication mechanisms would ideally be: decentralised and work in an offline capacity (at least for partial functionality).
Return on investment is an interesting statistic to consider when responding to or creating a new item of communication. Provide a concise message. Enough to ensure the intention of the communication is clear, and ambiguity is reduced if not eliminated. Email is a great tool, especially for the following: Timezone differences, announcements, spawning debates that require discussion, emergency notifications / reports, mailing lists, shared email accounts and automated reporting / information.
Using Email over an instant messaging mechanism for spawning debates allows contributors to formulate a constructed response. This can assist the better understanding of some ones input to the discussions, as instant messaging can be difficult for items that require discussion.
Instant messaging has good and bad traits:
- Good Stuff
- Instant
- Group Chats / conference calls
- Varying methods of communication
- Various formats (text, voice, video)
- Bad Stuff
- Distracting (interrupts workflow)
- History tracking / compatibility
- Citations / logs
Problems that exist are:
- Getting tasks into the system (May be the laziness of users)
- Tracking tasks that manage to make it into the system
- Getting those tasks done
Tools available:
- Pen and Paper (plain text files)
- OmniFocus (Mac Only)
- Lighthouse / TheChaw
So with this in mind, Felix quickly went over what has worked for him and his company:
- Check emails twice a day only.
- Turn off instant messaging tools in the morning
- Set clear distinct goals for the day, and achieve those goals
How to fail at unit testing. Felix described some common myths about unit testing, how he feels failing is possible and how to improve your approach.
Failed unit testing can come from factors such as: Attempting to reach 100% code coverage all the time, misunderstanding test driven development and expecting that all developers / users can write unit tests.
Success can be achieved by approaching projects with a top-down approach, incorporating performance tests and re-factoring code.
Continuous integration was presented in a basic format, going through the setup that Felix has found useful, making use of git post-receive hooks, and parsing of results to send notifications when necessary. In terms of increasing productivity and performance overall, Felix has begun testing Pair programming, where there is one computer for two people, and the development process is discussed ongoing, meaning that a lot of bugs an individual would miss are caught by the secondary developer on the first code pass.
Virtualization though open source and free products like VirtualBox and VMWare Server are worthwhile investigating for cheap scaling testing during development.
Version control was introduced, referencing the change of CakePHP to git from subversion, pointing out the benefits including: decentralization, can work offline, can work semi-online though the use of adhoc networks, its very fast to operate and its more intelligent with the storage of information. Following this, a detailed example of three separate working repositories was demonstrated.
Once the database has been created, bake models and controllers as normal using:
