Wednesday, December 28, 2011

Books I've read in 2011

I mostly read online articles/blog posts to keep me up to date. I read books occasionally whenever I get time. Below are some of the books which I've read this year.
  1. User Stories Applied: For Agile Software Development - This is one of the best books around for writing good user stories. Among many things it talks about how to gather user stories, how to best write them for acceptance testing, how to prioritize user stories, how to estimate user stories, planning for iteration, planning for release, how to measure and monitor velocity etc., Even though this is mainly for product owners/business analysts, it provides good information for developers, testers, scrum masters and managers also.
  2. 97 Things Evey Project Manager Should Know: Collective Wisdom from the Experts - This book is a collection of thoughts on things which every project manager should know and has many nice ideas and tips. This book would be useful not only for project managers, but also for anyone who leads/manages a team. If you are a team lead or development manager or technical manager, then this would be very useful to you. 
  3. The Pragmatic Programmer: From Journeyman to Master - This is one of the classic books on programming.  I think the first version was published back in 1999. Even though it was published many years before, most of the topics covered in this book are still relevant. This is a must read for every programmer and would especially help new programmers.
  4. Maven: The Definitive Guide - Maven's philosophy is convention over configuration. It works great for small projects, but for complex needs we need to configure it extensively. This book (also available as e-book) provides complete reference and would be very helpful for anyone trying to understand Maven intricacies and master it.
  5. PMP Certification: Excel with Ease - Even though I mostly work in Agile environment and like it, I wanted to see how traditional project management works and take PMP certification. This book (based on PMBOK) explains project management concepts in a simple manner. I learned more about general project management from this book and by studying for PMP certification. This book has lot of Q&A for each chapter and valuable tips/tricks on the PMP certification exam. This book would be very useful for anyone preparing for PMP certification.
Though not related directly to these books, below are some of my earlier posts related to these book topics:
  1. My favorite tips from Pragmatic Programmer (Pragmatic Programmer)
  2. Success tips for Agile teams (Agile)
  3. Key Points for any Project (Traditional or Agile) (Project Management, Agile)
  4. Ten tips for conducting effective meetings (Project Management, Agile)
  5. Effective Leadership/Communication skills needed for a Manager (Project Management)
  6. Project Management Process, Process Groups and Knowledge Areas (Project Management)
  7. Managing dependencies in Maven (Maven)
  8. GMaven goodness (Maven)
  9. Writing Maven Plugins (Maven)
  10. Maven 3 Features (Maven)
  11. Upgrading to Maven 3 (Maven)
  12. Maven 3 Parallel Builds (Maven)
  13. Books I've read in 2010 (Books)
  14. Books I've read in 2009 (Books)
 Wish everyone a very Happy and Prosperous New Year 2012!

Project Management Processes, Process Groups and Knowledge areas

Project management as explained by PMBOK (Project Management Body of Knowledge) is accomplished by the appropriate application and integration of 42 logically grouped project management processes. These processes are spread across 5 process groups and 9 knowledge areas.

The five process groups are:
  1. Initiating
  2. Planning
  3. Executing
  4. Monitoring & Controlling
  5. Closing
The nine knowledge areas are:
  1. Project Integration Management
  2. Project Scope Management
  3. Project Time Management
  4. Project Cost Management
  5. Project Quality Management
  6. Project Human Resources Management
  7. Project Communication Management
  8. Project Risk Management
  9. Project Procurement Management
The processes that belong in each process group, what they do and which knowledge area they represent can be confusing. This post (based on the info in PMBOK) discusses about each process group and briefly explains the processes that belong in each process group. The knowledge area they represent is indicated in brackets after the process. This post could serve as reference for project managers and also help someone preparing for PMP certification.


Processes performed to define a new project or a new phase of an existing project.
  • Develop Project Charter (Integration): Process of developing a document that formally authorizes a project and documenting initial requirements that satisfy the stakeholders needs and expectations. Output: Project Charter
  • Identify Stakeholders (Communication): Process of identifying all people or organizations impacted by the project and documenting relevant information regarding their interests, involvement and impact on project success. Outputs: Stakeholder register, Stakeholder management strategy 


Processes required to establish the scope of the project, refine the objectives and define the course of action required to attain the objectives of the project.
  •  Develop Project Management Plan (Integration): Process of documenting actions necessary to define, prepare, integrate and coordinate all subsidiary plans. Outputs: Project Management plan.
  • Collect requirements (Scope): Process of defining and documenting stakeholders' needs to meet the project objectives. Outputs: Requirements documentation, requirements management plan and requirements traceability matrix
  • Define scope (Scope): Process of developing a detailed description of the project and product.  Outputs: Project scope statement, project document updates
  • Create WBS (Scope): Process of subdividing project deliverables and project work into smaller, more manageable components. Outputs: WBS, WBS dictionary, scope baseline, project document updates (WBS - Work Breakdown Structure)
  • Define activities (Time): Process of identifying the specific actions to be performed to produce the project deliverables. Outputs: Activity list, activity attributes, milestone list
  • Sequence activities (Time): Process of identifying and documenting relationships among the project activities. Outputs: Project schedule network diagram, project document updates
  • Estimate activity resources (Time): Process of estimating the type and quantities of material, people, equipment, or supplies required to perform each activity. Outputs: Activity resource requirements, resource breakdown structure, project document updates
  • Estimate activity duration (Time): Process of approximating the number of work periods needed to complete individual activities with estimated resources. Outputs: Activity duration estimates, project document updates
  • Develop Schedule (Time): Process of analyzing activity sequences, durations, resource requirements and schedule constraints to create the project schedule. Outputs: Project schedule, schedule baseline, schedule data, project document updates
  • Estimate costs (Cost): Process of developing an approximation of the monetary resources needed to complete project activities. Outputs: Activity cost estimates, basis of estimates, project document updates
  • Determine budget (Cost): Process of aggregating the estimated costs of individual activities or work packages to establish an authorized cost baseline. Outputs: Cost performance baseline, project funding requirements, project document updates
  • Plan quality (Quality): Process of identifying quality requirements and/or standards of the project and product and documenting how the project will demonstrate compliance. Outputs: Quality management plan, quality metrics, quality checklists, process improvement plan, project document updates
  • Develop Human Resource plan (Human Resource): Process of identifying and documenting project roles, responsibilities and required skills, reporting relationships and creating a staffing management plan. Output: Human Resource Plan
  • Plan communications (Communication): Process of determining project stakeholder information needs and defining a communication approach. Outputs: Communication management plan, project document updates
  • Plan risk management (Risk): Process of defining how to conduct risk management activities for a project. Output: Risk Management plan
  • Identify Risks (Risk): Process of determining which risks may affect the project and documenting their characteristics. Output: Risk register
  • Perform Qualitative risk analysis (Risk): Process of prioritizing risks for further analysis or action by assessing and combining their probability of occurrence and impact. Output: Risk register updates
  • Perform Quantitative risk analysis (Risk): Process of numerically analyzing the effect of identified risks on overall project objectives. Output: Risk register updates
  • Plan risk response (Risk): Process of developing options and actions to enhance opportunities and to reduce threats to project objectives. Outputs: Risk register updates, risk contract related decisions, project management plan updates, project document updates
  • Plan procurements (Procurements): Process of documenting project purchasing decisions, specifying the approach and identifying potential sellers. Outputs: Procurements management plan, procurements statement of work, make-or-buy decisions, procurement documents, source selection criteria, change requests


Processes performed to complete the work defined in project management plan to satisfy the project specifications.
  •  Direct & Manage project execution (Integration): Process of performing the work defined in the project management plan to achieve the project's objectives. Outputs: Deliverables, work performance information, change requests, project management plan updates, project document updates
  • Acquire project team (Human Resource): Process of confirming human resource availability and obtaining the necessary team to complete project assignments. Outputs: Project staff assignments, resource calendars, project management plan updates
  • Perform quality assurance (Quality): Process of auditing the quality requirements and the results from quality control measurements to ensure appropriate quality standards are used. Outputs: Organization process assets updates, change requests, project management plan updates, project document updates
  • Develop project team (Human Resource): Process of improving the competencies, team interaction and the overall team environment to enhance project performance. Outputs: Team performance assessments, enterprise environmental factors updates
  • Manage project team (Human Resource): Process of tracking team member performance, providing feedback, resolving issues and managing changes to optimize project performance. Outputs: Enterprise environmental factors updates, organization process assets updates, change requests, project management plan updates
  • Distribute Information (Communication): Processing of making relevant information available to project stakeholders, as planned. Output: Organization process assets updates
  • Manage stakeholder expectations (Communication): Process of communicating and working with stakeholders to meet their needs and addressing issues as they occur. Outputs: Organization process assets updates, change requests, project management plan updates, project document updates
  • Conduct procurements (Procurements): Process of obtaining seller responses, selecting a seller and awarding a contract. Outputs: Selected sellers, procurement contract award, resource calendars, change requests, project management plan updates, project document updates

Monitoring & Controlling:

Processes required to track, review and regulate the progress and performance of the project.
  • Monitor & Control project work (Integration): Process of tracking, reviewing and regulating the progress to meet the performance objectives defined in the project management plan. Outputs: Change requests, project management plan updates, project document updates
  • Perform Integrated Change control (Integration): Process of reviewing all change requests, approving changes and managing changes to the deliverables, organization process assets, project documents and project management plan. Outputs: Change requests status updates, project management plan updates, project document updates
  • Verify scope (Scope): Process of formalizing acceptance of the completed project deliverables. Outputs: Accepted deliverables, change requests, project document updates
  • Control scope (Scope): Process of monitoring the status of the project and product scope and managing changes to the scope baseline. Outputs: Work performance measurements, organization process assets updates, change requests, project management plan updates, project document updates
  • Control schedule (Time): Process of monitoring the status of the project to update project progress and managing changes to the schedule baseline. Outputs: Work performance measurements, organization process assets updates, change requests, project management plan updates, project document updates
  • Control costs (Cost): Process of monitoring the status of the project to update the project budget and managing changes to the cost baseline. Outputs: Work performance measurements, budget forecasts, organization process assets updates, change requests, project management plan updates, project document updates
  • Perform quality control (Quality): Process of monitoring and recording results of executing the quality activities to assess performance and recommend necessary changes. Outputs are quality control measurements, validated changes, validated deliverables, organization process assets updates, change requests, project management plan updates, project document updates
  • Report performance (Communication): Process of collecting and distributing performance information including status reports, progress measurements and forecasts. Outputs: Performance reports, organization process assets updates, change requests
  • Monitor and control risks (Risk): Process of implementing risk response plans, tracking identified risks, monitoring residual risks, identifying new risks and evaluating risk process effectiveness throughout the project. Outputs: Risk register updates, organization process assets updates, change requests, project management plan updates, project document updates
  • Administer procurements (Procurements): Process of managing procurement relationships, monitoring contract performance and making changes/corrections as needed. Outputs: Procurement documentation, organization process assets updates, change requests, project management plan updates


Process performed to finalize all activities across all process groups to formally close the project or phase.
  •  Close project or phase (Integration): Process of finalizing all activities across all of the project management process groups to formally complete the project or phase. Outputs: Final product, service or result transition, organization process assets updates
  • Close procurements (Procurement): Process of completing each project procurement. Outputs : Closed procurements, organization process assets updates

Reference: A Guide to the Project Management Body of Knowledge (PMBOK Guide) - Fourth Edition

Tuesday, December 27, 2011

Ten tips for Conducting Effective Meetings

We all have been in meetings which are boring, too long, where other participants are poking their phones or even sleeping. This is partly because meetings are not conducted properly. Considering how many meetings we all attend every day, it is important to make meetings effective. Ineffective meetings could easily cost thousands of dollars to the organization (for ex, think about a team  of 6 meeting several times a week ineffectively) Below are some of the tips that could help in conducting effective meetings:
  1.  Invite only relevant people to the meeting - It is important to invite only relevant people. Non-relevant participants either would not pay attention to meeting discussion or distract the meetings. They would be better off doing some real work.
  2. Provide meeting agenda in meeting invite - This would help everyone to prepare for the meeting accordingly. This would also help participants to decide if the meeting is relevant for them and they can decide whether to accept or decline the invite accordingly.
  3. Set up ground rules for the meeting - This needs to be done at the start of the meeting. This could be format of the meeting, behavior during the meeting, no use of cell phones etc., Ask if everyone is ok with this or if they want to add their own.
  4. Discuss only things on agenda - During meetings, it is very easy to get distracted or get into too much details on one topic. Avoiding this or having the facilitator remind everyone when this happens is important so that meeting discussion is on track.
  5. Have a good communication link - Having everyone co-located during meetings is very rare these days. Even if there is no off-shoring, we often work with other teams in US. Make sure you have a good phone line or better a good video-conferencing facility, if your organization can afford it.
  6. Have short meetings - Short meetings are more effective. Attention span of participants might reduce as time goes by. 30 mins or 1 hour is a good time for meetings. If you need to have meetings beyond that, make sure you think about it and have a valid reason to do so.
  7. End meetings on time - Even if you have short meetings, make sure that meetings ends on time. Participants might have something else scheduled after this and it is important to respect other people's time. Many participants tune out or think about the next thing they are going to do, once meeting goes past the scheduled end time. 
  8. Communicate results of the meeting - Conclude the meeting with results of the meeting and mention if any follow-up meetings are necessary. After the meeting, document (text, word, wiki etc.,) what was discussed in the meeting and send it to everyone (even to people who have missed the meeting). This would help participants to go back later on and find out what was discussed in the meeting. It could also serve as input for subsequent meetings.
  9. Do not spread meetings throughout the day - Try to have meetings when team members are disturbed from their normal work anyway. Having back to back meetings or meetings concentrated in mornings or evenings leaves people some undisturbed time to work on their regular stuff. Programming needs concentration and every time people get disturbed, it takes time for them to get back on track.
  10. Be a good facilitator - Being a good facilitator is key and can make even dull meetings fun. Having good communication skills, understanding of the subject etc., make meetings relevant. One of the key thing is to make everyone participate and make sure that no one's view is neglected. Facilitation skills are not easy for technical guys but is important to focus on.
I'm sure there are other points that would help too. If you want to add more, feel free to add them as comments.

Monday, December 26, 2011

Maven 3 Parallel builds

We upgraded to Maven few months back and recently tried parallel builds feature (I've posted about Maven 3 features in this earlier post - in hopes of improving our build times. But, unfortunately our build times did not improve at all.

We are using the latest maven 3 version (3.0.3) and also the latest maven plugins available to date. Still, we get the many plugins are not threadsafe and so they don't take advantage of the parallel builds. For example, we get this during our build which shows these plugins are not threadsafe.

[WARNING] ********************************************************
[WARNING] * Your build is requesting parallel execution, but project
[WARNING] * contains the following plugin(s) that are not marked as
[WARNING] * @threadSafe to support parallel building.             
[WARNING] * While this /may/ work fine, please look for plugin updates
[WARNING] * and/or request plugins be made thread-safe.           
[WARNING] * If reporting an issue, report it against the plugin in
[WARNING] * question, not against maven-core                      
[WARNING] ********************************************************
[WARNING] The following plugins are not marked @threadSafe in 
[WARNING] MyProjectName project:
[WARNING] org.apache.maven.plugins:maven-pmd-plugin:2.6
[WARNING] org.codehaus.mojo:cobertura-maven-plugin:2.5.1
[WARNING] org.codehaus.groovy.maven:gmaven-plugin:1.0
[WARNING] org.codehaus.mojo:buildnumber-maven-plugin:1.0
[WARNING] org.codehaus.mojo:exec-maven-plugin:1.2.1
[WARNING] ********************************************************

It is unfortunate that these plugins don't support running in parallel even though Maven3 is out for a while now. Just posting my experience and hope it changes soon...

Sunday, July 10, 2011

Upgrading to Maven 3

In my previous post, I discussed about what is Maven 3, reasons to migrate to Maven 3 and some of it's features. I tried upgrading to Maven 3 in some of our projects and for those projects, these are the following changes that I had to do to migrate to Maven 3.

  • Reporting Section - In Maven 2, all report configuration was under top level reporting section. But, in Maven 3, these configurations have to be moved under reportPlugins in maven site plugin configuration.
  • Report configuration does not apply to build - In Maven 2, we used to have PMD/Checkstyle/Cobertura plugin configurations in report configuration and it also took effect during the build. But, this is not the case anymore in Maven 3. So, I had to move these configurations to build section for them to take effect.
  • Maven 3 needs "project." prefix for groupId, artifactId etc., In Maven 2, the prefix was not required, but now in Maven 3, because of stricter POM validation, it is necessary to add this prefix.
  • Maven versions plugin needs reportSets configured - With Maven 2, it produced default reports, but with Maven 3, I had to add reportSets section and needed to add the necessary reports under that.
  • Needed to upgrade maven site plugin from 2.2 to 3.0-beta-2 to make it work with Maven 3.
  • Needed to upgrade maven findbugs plugin from 2.3.1 to 2.3.2-SNAPSHOT to make it work with Maven 3.

After doing these changes, I could do "mvn clean install" for our project, which ran PMD/Checkstyle/Findbugs/Cobertura analysis fine and also ran tests properly. Also, did "mvn clean site" and could confirm that the site was generated properly like before.

In your project, based on the plugins that you use, there could be other changes involved. Look at the plugin compatibility notes and plugin compatibility matrix for more information. But, the above changes should work for most users.

These are the changes needed to be done in the POM. Once the POM is changed, upgrading to Maven 3 for other developers in the rest of the team is very easy. All they have to do is download Maven 3, unzip it and change M2_HOME to point the new Maven 3 install directory. That's it!

Saturday, July 9, 2011

Maven 3


Maven 3 is complete rewrite of maven internal architecture and is almost backward compatible. Maven 3 repository format is same as that of Maven 2, unlike the switch from Maven 1 to Maven 2. Reporting is not part of core Maven and is now part of maven site plugin.

Reasons to migrate to Maven3:
  • Latest and Greatest!
  • New development only in Maven 3 - 6 week release cycle
  • Maven 2 - Release cycle is unpredictable
  • Backward compatible (almost)
  • Faster
  • Parallel Builds
  • Eclipse/OSGi friendly
  • Tycho - Helps building Eclipse/OSGi bundles with Maven
  • Strict Validation of POM
  • Improved error reporting - Link to maven page with description, cause and possible fix.
  • Improved Logging


Maven documentation says that it could be anywhere from 50% - 400% faster, but it depends on the project though. In one of our simple projects, I could see 25% improvement for both clean install and clean site (no downloading of dependencies involved).

Parallel Builds:

One of the other advantage of Maven3 is parallel builds. Most of us have dual or quad cores these days and so it would be good to take advantage of them. Below are some examples:
  • mvn -T 2 clean install (Build project with 2 threads)
  • mvn -T 2C clean install (Build project with 2 threads per core)
Maven analyzes the projects and executes the plugins accordingly. Also, individual plugins need to declare themselves thread safe (@threadSafe). In one of our small project that I tried with, I could not see big difference with 2 threads, but with big projects, there could be a difference.

Maven Shell:

Maven Shell (mvnsh) seemed to be very promising. The idea is to load JVM, maven and plugins and keep it in memory, thus avoiding start up cost every time maven command is run. But, when I tried it, I kept getting out of memory error (even after increasing my MAVEN_OPTS). At least, this was the cause when I tried it few months back. It could be fixed by now.

Polyglot Maven:

Polyglot maven allows to write POM in other JVM languages - Groovy, Scala, Clojure etc., It is useful for those who don't like the verbose XML POM's. Polyglot maven needs to be downloaded separately though. It comes with translator to convert your current XML POM's. Below are some examples:
  • translate pom.xml pom.scala
  • translate pom.xml pom.groovy


  • profiles.xml is no longer supported. It is advised to move that to inside settings.xml.
  • Reporting now goes under reportPlugins in maven-site plugin configuration.
  • mvn dependency:tree may not be correct, since this still uses legacy dependency resolution code.
  • Because of stricter POM validation, you will see more errors. These have to be fixed before proceeding further.
For the comprehensive list, look at the compatibility notes available here.


I tried Maven 3 few months back (in March 2011) but just got chance to do a post on this. So, some issues that I saw might be fixed by now. This post is a compilation of what I learned in the brief time that I invested in reading/trying out maven 3. If you want to learn more, you can look at these other references, that are in my bookmarks.

Saturday, May 7, 2011

My favorite tips from Pragmatic Programmer

I recently (finally) read the Pragmatic Programmer book and it has lot of good tips. Broken Windows and DRY are some of the widely known pragmatic programmer tips. Below are some of my personal favorite tips from this book:
  1. Care about your craft - Care about the product that you develop and not just do it because you have to do it.
  2. Don't live with Broken Windows - Make sure to fix bad designs, wrong decisions or poor code as soon as possible.
  3. Be a catalyst for change - Like the stone soup story, it's time to bring out the stones. Show people what you got and how it could evolve in future and people will join you.
  4. Remember the big picture - Don't be like boiled frogs. Be aware of what's going on around you.
  5. Invest regularly in your knowledge portfolio - Just like managing a portfolio, we need to invest regularly, diversify it and manage the risks involved. Also, review and rebalance your technical portfolio in a regular basis so that it reflects the current trend.
  6. DRY - Don't Repeat Yourself. Make sure that every piece of code has a single, unambiguos and authoritative representation in the system. Not that this also applies to documentation and not just for code.
  7. Eliminate effects between unrelated things - We wants systems to be as orthogonal as possible. Less coupling allows them to change independently.
  8. Don't program by Coincidence - Always know what you do and don't code blindfolded.
  9. Test your software, or Your Users Will - It is better for the tester in your team to find issues before users find it. Better yet, make sure that you test your code and find any problem before the tester finds it.
  10. Work with a user to think like a user - Don't just assume that users might need a feature just because it is in other apps, or it is cool or you like it. Work with a user (or product owner) to find out what they want and learn to think like them.
  11. Refactor early, Refactor often - Always refactor to keep the code in good shape. Use the medical analogy of removing "growth", when explaining the need of refactoring to non-technical managers.
  12. Don't be a slave to formal methods - Formal methods are good, but don't follow it blindly. It would be good to tweak it to suit your development needs and the team structure.
  13. Don't use manual procedures - Always automate anything and everything that you do repeatedly manually.
  14. Use Saboteurs to test your testing - Test cases or suites test our code. But, we also need to test the tests. Make sure that your tests produce alarm when they should.
  15. Test state coverage, not code coverage - It is possible to fail with 100% code coverage. Make sure that all states of the system are tested well.
  16. Find bugs once - When a bug is found, add test for the bug first and see it go red. Then fix it and watch it go green. Automated tests prevent the bug from happening again.
  17. Sign Your Work - Take pride in what you do. Just like an artist signs their work, make sure to sign your code (ex - @author tag in Java) and take pride in the code your develop. Other developers should expect to see your name and expect it to be well written, tested and documented.

Saturday, April 30, 2011

Agile - Apps for Planning Poker

Backlog grooming and planning meetings used to be not so liked by our team members. Last year, we started using planning poker for estimations and started using planning poker cards. This made our not so fun planning meetings fun. During our last backlog grooming session, one of our colleague started using Android app for planning poker. Seeing him, others in our team (including me) downloaded iPhone and Android apps for planning poker. This now makes our planning meetings even more fun. Everyone waits to showcase their estimates with smartphones now.

Some of the apps for iPhone:

There are many apps for Android as well.

Feel free to leave comments here if you have any other creative ways to make Agile meetings more fun.

Sunday, March 27, 2011

My EclipseCon (2011) Experience

It was great to go to EclipseCon finally this year, after using Eclipse IDE for 6+ years and working on Eclipse RCP application for around 2+ years now. It was also good to meet and go to sessions from some of the well known names in this field (Jason Van Zyl, Eric Clayberg, Dan Rubel, Paul Webster, Tom Schindl, Kai Toedter, Patrick Paulin etc.,).

For those who could not go, below are some of the notes from some of the sessions I went to (in no specified order):

1) Tycho - Tycho provides a way to build Eclipse plugins. PDE ant build now does the same, but Tycho promises to be much easier than PDE build. Sonatype gave a good tutorial on Tycho and also showed how to automate it in Hudson. They also promised that they will release a online book on Tycho soon.

2) Jubula - Jubula seems like a great functional testing tool and it is from the same company (BredEx) who developed GuiDancer. The cool thing with Jubula is we can start writing test case scenarios before the actual development happens. This would enable testers and maybe product owners to start writing acceptance tests before development team starts working on a task. When development is done, we can start mapping components in use case scenario to actual components in the product. Also, each scenario (or sub steps in a scenario) can be created independently and thus can be reused by multiple tests. So, if a component changes in the screen, it is enough to just update that one sub-step and all test cases are updated automatically, since they just reference this step. This makes it very modular and easy to maintain. They gave a good tutorial on Jubula during the session. They are also planning to hold a webinar on Jubula soon. They also said that Jubula tests can be run in command line and can be automated to run via any CI system. Jubula can be downloaded now, but will be official in the upcoming Indigo release.

3) Chronon - This is a time traveling debugger. The idea is someone (say tester) comes across a bug and then he can send the recording (which records every line of code executed) to developer. The developer can play back the recording using time traveling debugger and can see the actual values of variables used in that execution. Also, it makes it easy to see execution path of multiple threads, which is hard to see via regular debugging. This is a very novel idea and won the best hot products showcase award for 2010. Of course, I voted for it too.

4) BIRT 360 Dashboard and BIRT Data Analyzer - We use open source BIRT as an eclipse plugin in our RCP application to produce PDF/HTML BIRT reports. But, it is not very interactive. BIRT 360 gives dashboard like functionality to end users. It would be very useful for management/executives to see what goes in their company (for example, sales report by region etc.,) at a high level easily instead of reading a big report. BIRT data analyzer goes one step further and allows users to put their own analytics in their dashboard/reports. With data analyzer, users can pick any value from the data cube in the report and can show it in any way in their report. But, both BIRT dashboard and data analyzer are not in open source and are only available in Actuate's commercial BIRT software. Also, both of them are web based applications and are not available as RCP plugins to be used by desktop applications.

5) e4 - There were many talks about e4 in EclipseCon. e4 mainly gives new way for styling and provides flexible programming model. e4 is not backward compatible with 3x version of the Eclipse plugins. However, they provide a compatibility layer which helps in running 3x plugins in e4 environment. But, still there could be issues (with actionSets, menus, menuContributions etc.,) even with that. e4 does not support activities/capabilities yet. They said it might be supported in 4.2. When developing new eclipse plugins/rcp applications, it makes sense to use e4. But, I'm not convinced about using e4 on existing applications, as the migration could take a while, especially if the code base is large.

6) Q7 - Another functional UI testing tool. It is created by XORED (a Russian Eclipse RCP consulting company) and there were many participants from XORED in the conference. Good thing here is test scripts are in ECL (Eclipse Command Language), which makes it easy for testers to read/edit the test cases. They plan to add support for BDD soon, which would make it even better. They have Q7 maven plugin which could be used to run Q7 tests via maven using Tycho. So, this could automated via CI. However, it does not seem as easy/flexible to use/intuitive as Jubula.

7) Nexus Pro - Sonatype gave a talk on how to improve onboarding of new developers using Nexus Pro. Developer Onboarding feature is in Nexus Pro and automates the normal tasks done by new developers (Downloading, Installing Eclipse, Eclipse Plugins needed, checking out source code etc.,). Basically, we just have to send a jnlp link to the new developer and when he/she clicks on that link, it guides the user to install everything needed. It does not have support for setting up other tools though. They plan to add support for downloading/setting up webserver, installing maven etc., in future. It seems like Yoxos does something similar to. You can look at Yoxos OnDemand here. Nexus Pro also supports Eclipse update sites and p2 bundle repositories. If you need to use Nexus to host Eclipse bundles, then this would be handy. If you need to know what is the difference between Nexus Pro and Nexus OpenSource, you can see it here.

8) Orion - It is aimed at making Web-based development easier in the Web. It is basically a set of linked web pages and not an IDE in a browser. File navigation and editing happens from within a browser. It looks pretty neat, but I think it needs more features before it can replace the desktop based IDE.

9) Commands - Paul Webster gave an interesting talk on 10 most patterns in using Eclipse 3x commands. The slides are available here. The session was very informative. He also gave a talk of e4 commands and slides are available here.

10) SWT 3.7 - There are many fixes/minor improvements in 3.7, but the main feature that is new is Touch and Gestures. A touch is a change in state of a finger on the input device and a Gesture is interpretation of touches. It provides events on touch/gesture just like we get Key/Mouse events. This is very cool and opens the door to make Eclipse RCP applications very interactive.

11) Keynote sessions - They had three keynote sessions - one on IBM's Watson project, one on Java Renaissance and one on Apache Hadoop. The one on Java Renaissance was interesting and speakers from IBM and Oracle gave the talk. They confirmed that Java 7 release date is July 28, 2011 and Java 8 is targeted for end of 2012. Java 8 focuses on making Java modular (Project Jigsaw). They also spoke about making the new modular framework play nicely with OSGi. They also gave some insights on what could come in Java 9. Some of the things they hinted are supporting massive multi-cores, multi gigabyte heaps etc. in Java 9.

12) Eclipse 3.7/3.8 - Eclipse 3.7 code named Indigo will come out in late June just like all previous Eclipse releases. It may/may not have support for Java 7 in that. However, they said that 3.7.1 will have support for Java 7, if the initial one does not have it. Also, they confirmed that Eclipse 3.8 is code named as Juno.

Finally, here are some stats on who attended. There were lot of attendees and it was very diverse too. They showed these stats (and other fun stats like how much beer the attendees drank etc.,) during the closing session. I wish they had provided details on how many people actually attended.

50% of attendees are from US - 25% from California and 25% from rest of US (Totally from 31 states)
10% of attendees are from Canada
40% rest of the world - Germany, France, UK, Sweden, Russia and Bulgaria had sizeable attendees
Totally, there were participants from 29 countries.

Monday, February 28, 2011

GMaven Goodness

I recently had a requirement where I wanted to get a substring of artifactId and then use it in another plugin's execution. I thought it would be easy, but it was not as easy as I thought. Initially, I had couple of options in mind:
  1. I could declare a property directly in my POM which has the substring of artifactId and then use it. But, the problem is we have so many projects and each of the projects have to declare this property. Also, we need to make sure that any new project in future declare this property too. Since, this is too manual, I was looking for an automated solution.
  2. I could write my own small maven plugin for this. This plugin would get substring of artifactId and then set a property. This property could then be used by another plugin downstream in the lifecycle. This option would work, but then I need to create a project for this and maintain it.
So, I didn't really like both of these options. Just then I found that, I could use GMaven plugin for this. With GMaven plugin, I could write groovy/java code to get substring. But, then I was wondering how to use that substring downstream in another plugin. After investigating this, found couple of options here:
  1. I could use GMaven plugin to write groovy code and then get substring. At this point, I came across maven properties plugin. The properties plugin can read properties file and set them as maven properties. So, I was thinking about writing the substring to a properties file using groovy, which I could then read using properties plugin. Then, I could use this maven property downstream. Even though this would work, it seemed too much work just to get a substring.
  2. Then, I found that GMaven plugin is also capable of setting maven properties. Apart from writing groovy code, I could use and to get/set maven properties inside GMaven plugin. This was very handy. So, my solution was just to add this execution to my gmaven plugin:









String artifactIdSubStr = new String(project.artifactId).substring(10)'myArtifactId', artifactIdSubStr)




Just two lines of groovy code and I was able to use myArtifactId property later on. GMaven plugin came in very handy here.

Using GMaven plugin, we could run an inline groovy script (like what I did above), run external groovy script and also run a remote groovy script. We could also call Java or Groovy classes and call them from here. Having the power of executing groovy and java code inside POM is great. But, we should be careful on how we use it though. If we need to do lot of things, then it makes sense to write a custom maven plugin than to go this way.

Some of the variables that could be used here are project, pom, session, settings, log, ant and fail. If we want to do some custom checks and if the check does not pass we may want to fail the build. In these cases we could implement the check in groovy and then use fail() to fail the build.

You can find more information about gmaven plugin here.

Monday, January 24, 2011

Success Tips for Agile Teams

We've been doing Scrum for few years now. I've also seen how our team and other teams do some of the common things which makes us less efficient. This post just talks about some of the things that I learned through Agile/Scrum training, Agile books, from our own experience and seeing/hearing other teams which do Scrum. Each point starts with what is good to do followed by (in brackets) how teams commonly do it now which makes it less efficient. Many of these were done by our team too, but we are trying to recognize the issues and improve them continuously.
  1. Start with product vision and release objectives. Then do road map planning to define when each functionality is needed. It is important to share this with the team so that team understands the big picture and knows where they are heading to. (Some teams go from sprint to sprint heads down, which means the team may not understand the big picture.)
  2. When release objectives are set, do release planning with the team and get commitment on what can realistically be delivered for the release. (Management could arrive at the deadline/feature list without consulting the team, which means it is not realistic. Having team commitment early on in the project is very important.)
  3. Product owner should do continuous backlog grooming and thin slice the user stories with the help from the team. (Avoid having big stories which are not flushed out properly)
  4. The focus of the sprint should be on maximizing delivering features which end users can use at the end of every sprint, even if it comes at a small cost of developer productivity. (The focus of the sprint should not be to manage the team's tasks and fully load the development team. Instead the focus should be on getting completely implemented user stories.)
  5. The team should be well cross trained i.e anyone in the team should be able to take any tasks (as much as possible) to complete the sprint stories. For this to be successful, it is important to have a small team focused on a particular area. (Avoid having teams with too many specialists)
  6. Team size including product owners and scrum master should be in single digit. (Think about breaking the team if your team size is in double digits)
  7. Sprints should be sustainable with each sprint including review, retrospective and planning taking the same amount of time. (Many sprint teams are so tired at the end of long hard working sprint. The focus should be on making the sprints enjoyable and sustainable. Also, avoid having irregular sprint lengths)
  8. The focus should be on conversation with product owners and recording the conversation as acceptance criteria for the story (confirmation), rather than writing long use case documents. This is based on famous three C's - Cards, Conversation and Confirmation. (Sprint teams should focus on face to face conversation rather than relying on long documents)
  9. User stories should be accompanied with good acceptance criteria so that team understands what done really means for that user story. (Not doing this is the root cause of many bugs. Having good acceptance criteria and shared understanding (between product owner, developer and tester) of when a story is really done would help a lot)
  10. Team should do collaborative planning and be empowered to do what it takes to deliver the sprint goals. Entire team should focus on how they can accomplish/commit to the sprint goals together. (Avoid too much focus on individual team member tasks. Instead focus should be on the delivering as a team)
  11. Estimating user stories in story points is better than doing in hours. (This could be unclear if the team does not have common understanding on what a story point is. Entire team should have common understanding of what a story point is and understand they are relative estimates.)
  12. When splitting user stories, try to split it vertically rather than horizontally i.e functionally rather than architecturally. (Developers have the natural tendency to break up a big user story into a) DB work b) DB API c) GUI work etc., Instead the user stories should be divided so that each user story delivers some meaningful functionality to the end user.)
  13. Use daily meetings as a way to communicate to other team members. (Do not use it as a way to report individual progress, which over time might become mundane and not liked by everyone in the team).
  14. Entire team should be committed to delivering the stories and delivering it completely. (Half/Almost done stories gives a false impression that they are done and also cause more bugs. Avoid it by not giving credit and don't use it's story points to count towards velocity.)
  15. When the story is done, make sure it means it is both developed and tested completely (Often teams just do development and call it done, which means testing will be done later. This really means a story is not done, if testing finds major misunderstanding/bugs in the code)
  16. Team should plan on getting the user stories implemented and give it to testers as early as possible in the sprint. (Often teams might finish a story very late in the sprint, which makes it hard for it be tested and fix bugs (found during testing) before the end of the sprint)
  17. Developers could do code reviews, work on infrastructure tasks, help with testing, learn more about the product, etc., if they are done earlier than anticipated. (Often teams pack the sprint which mostly means there is no time to do anything else)
  18. Use retrospectives efficiently to find and fix issues which slows down the team. Make progress on these issues transparent so that team can understand that their concerns are handled properly. Continuous improvement is important to any team. (Many teams use it as a formality and not really do anything with the issues raised in retrospectives. This could make retrospective meeting not liked by team members)
I just mentioned some of the things which came to my mind. Feel free to add your comments here.