DiscussAgile Day workshop - my notes

It was a good day spent at Discuss Aagile Day workshop held on 27th Nov at Pune.
Many thank to Scrum Alliance and iZenBridge team for arranging this effective and interactive workshop.
Thanks to all the speakers for spending their valuable time with us and sharing hands on experiences on interesting agile topics. You can see Workshop Agenda here.

Let’s go on --- There were multiple tracks running in parallel and you could choose topic of your interest.
I attend below sessions and just trying to write down my take away as high level bullet points.

Also, feedback to organisers is at the end of this write up!

Power of Appreciation enquiry by Sridharan Vembu from ThoughtWorks

1.    Spend more time on “What went well” while doing retrospective activity! Most of the time during retrospective process, we always spend few mins on what went well and put lot of time in “what did NOT go well”  and  take out action items.
2.    Appreciate team on where they are doing well.
3.    Spread positivity in team even if sprint fails. This helps team to perform even better in next sprint.

Agile Coaching Journey Experience – lessons learnt (Experience Report) by Rahul Shah from The Digital Group Inc

1.    Implement continuous learning in the team.
2.    While Implementing agile in new project , start with below tasks
a.    How does current system/process work
b.    What are team dynamics
c.    How is current information flows between teams ( business, developer, testers, managers, QA, product owner etc )
d.    Access existing system with all corners and then fill the gaps with agile practices
3.    Award team or individuals for good work
4.    Have small games (max 5 mins ) in the team

Contracting for Agile Development Projects by Poonam Jain from Tieto

1.    Master SOW contract and create/review virtual SOW contracts for 2 or 3 week based on sprint delivery.
2.    SOW contact should be flexible and should be delivery/business/customer focused instead legal/laws oriented.

Agile Clinic – Strengthen Your Organization Agility by Sriharsha B from Wipro Technologies
1.    Assess org internally, if org already have agile coach or trainer
2.    Train internal team on agile practice
3.    Hire agile expert from outside and train internal team members
Note- both have its own pros and cons so choose wisely!!

FOUR ‘S’ principle for Agile Clinic
a.    Scout – pickup team members who you see are highly interested in agile implementation or leaning.
b.    Sharpen – Sharpen their skills
c.    Share -  share knowledge/learning with other teams
d.    Sustain – sustain the same learning for longer team and do continuous leaning

Event Feedback

Just my thoughts, you are the best to know how practically is this possible, but my view is, this can be achieved!
To make such workshop more interactive, productive, Please think on below process !

  1.        Before 2 or 3 weeks, ask registered participants to submit their current problem statement ( in short – just 3 lines ) in context of  published agenda.
  2.         Filter out received entries relevant to the discussion.
  3.             Map problem statement with relevant topics.
  4.            Publish problem statement mapped to appropriate agenda. – this will allow participants also to think!
  5.           Discuss that problem statement at the end of session ( 10-15 mins ). Make it Time bound!
  6.      Give a token of appreciation to the top 3 problem statement entry!
This process will make participates to think a lot in advance on the agenda and eventually sessions will become more productive.

Microservices/API design principles

My notes on MicroService design principles.

Microservice design principles - microservies has nothing to do with physical size or lines of code!!! It's about minimizing complexity.

"instead of having single complex service for your systems, design bunch of small services based on specific business capabilities. Small service means, it should minimize complexity, should serve a focused purpose and should minimize inter-service communication"

Design principles for MicroServices

1) Develop and Deployed independently 
Each service shuould be developed and deployed independently. Deployment of one service should not impact other services and a each service should have it's own code base.

You are doing wrong if
you find a need to deploy services together
you have one code base for multiple services
you need to send notification to before you deploy a service

2) Data ownership

Service should have it's own databased or preferably set of tables that is manged by only a specific service.
should avoid scenario where multiple services are writing and reading from the same set of tables, any changes to table would require changes in all services.  
having each service has it's own data ownership introduce loose coupling between service and database.
key point is , services should NOT have knowledge of each others underlying database.

Having own database for a services allows to choose right database technologies based on service functionality.

3) loosely coupled from all other services,

   once you adhere to point 1 and 2, you have already initiated loose coupling        but there are more on loose coupling:-
   minimal dependency on other services
   communication with other services should be over exposed public interfaces( API, events etc )
   such interfaces or API should NOT expose internal details  

4) Follow High cohesion methodology

    closely related functionality must stay together in a single service. this minimizes intercommunication between services.

5) Resilient service

   Single point of failure in system should NOT impact multiple services. if you have a service with independent data ownership, loose coupling, independent deployable artifact, it is a step towards resilient system!

Remember- Total resilience in the face of all situations is NOT possible.Implement what is feasible in the short term and work to achieve greater resilience in stages.

6) shared library

  carefully watch out implications of shared library introduction to your services.
  You are doing something wrong when changes to shared library requires    updates to all services simultaneously.

7) Introduce Asynchronous workers
   very important design principle - introduce asynchronous workers to minimize impact on primary service API.
example-> A batch job can be introduced in a service as an asynchronous worker which is responsible to process high volume request, re-try mechanism for failed request etc.
This asynchronous  worker provide following benefits:-

  • speed up the primary request path
  • spread load to asynchronous  worker in case of high volume request
  • reduce error scenarios on primary API
8) Service Versioning
    An API is never going to be completely stable. Change is inevitable!!  
    it's always a best practice to version your service.
   Versioning can be added to header or in the service url.
   Following technique can be used to maintain service version:- 

 The URL has a major version number (v1), but the API has date based sub-     versions which can be chosen using a custom HTTP request header. In this case, the major version provides structural stability of the API as a whole while the sub-versions accounts for smaller changes (field deprecations, endpoint changes, etc).

Risk Storming

Risk Storming - Collaborative and Visual Technique for identifying technical risk

My notes

1) Draw you app design on board - high level to show each like component, class, container etc
2) Identify risk individually - each and every member of team has different view of looking at risk!
3) Highlight risk at component/flow/integration level
4) Discuss and Priorities

Excellent write up by Simon here @ Risk Storming.


Java EE - the next inception!

Read this article on WebSphere and found this interesting about basics of how IBM WebSphere Application Server Liberty profile works, and how its architecture differs significantly from that of older Java EE application servers

Please read here complete article at Java EE, the next inception: A primer to WebSphere Liberty for Java EE developers

Portlet Preferences Usage - Best Practices

PortletPreferences should be used very carefully and in situations only when there is a valid use case for it.
So ideally, one should have good knowledge of portlet preference and most imortantly, where to apply it.

The PortletPreferences object provides the ability to store information persistently about how a client wants to use a particular portlet. 

For example, with the stock portlet, a user can provide stock code information to the portlet, and the portlet will store that information persistently using the PortletPreferences object. The next time the user visits the view mode of the portlet, the stock details for that user's choice will be displayed. 
Persistently storing this information, is all done behind the scenes for you by the portal framework.

So when you use portlet preference, did you ever think about where does portlet preference gets stored? In hard drive, some KB's data in DB or as CLOB or something that is not efficient. 
So how to store portlet preference is completely upto portal vendors and hence we as a developer or DB administrator don't have much control over the data which is stored in portlet preference.

Let's talk about application efficiency, where in if you want to store just a Boolean flag and if you choose to store it in portlet preference, you don't know how it will be stored and what size it would use for storage compared to if we chose to use our own DB to store the flag which would just take few tiny bit of space.

Furthermore, mining information from data stored in portlet prefernce is almost very difficult.

So, If you don't know how the portal stores your PortletPreferences data, and you don't know how the portal ties a particular preference to a particular user, you're going to have a pretty hard time mining your own data.

The best use of portlet preference could fall in below situations where a user wants 

1) To have red background.
2) configurable pagination numbers
3) configurable TimeZone
4) configurable portotol ( http or https etc )
5) Configurable fonts etc.

Conclusion -

  • Use portlet preference for simple configurable parameters
  • Don't ever use preference to store information where it would become impossible to do data mining from preference storage because you don't have control over preference storage.

Dynamic Registration of Servlets and Filters at application startup

Recently I read about one of the nice feature of JAVA EE 6 - Dynamic Registration of Servlets and Filters at application startup.

I then thought of use cases around this feature. 
I think, this is mostly desinged for framework creators but developers could also get benefits from this.

You can use this fefature by using new methods introduced in the ServletContext class which are able to programmatically add servlets and servlet filters to a web application during startup. 

The methods are addServlet() method to add a servlet to the web application, and the corresponding addFilter() method to add a servlet filter.

Here's an example, which dynamically registers a Servlet as soon as the ServletContextListener is triggered:

//Register Servlet
public class MyServletContextListener implements ServletContextListener {
    public void contextInitialized(ServletContextEvent sce) {
        ServletContext sc = sce.getServletContext();
        // Register Servlet here
        ServletRegistration sr = sc.addServlet("DynamicServlet",
        sr.setInitParameter("servletInitParamName", "servletInitParamValue");

The same steps can be used to register a Filter named MyDynamicFilter bound to the class com.sample.TestFilter:

// Register Filter
FilterRegistration fr = sc.addFilter("DynamicFilter","com.sample.TestFilter");
fr.setInitParameter("filterInitName", "filterInitValue");
                                     true, "DynamicServlet");

Would be great if readers of this post, could suggest creative use cases which could add useful functionality to an applications.

How to programatically refresh data from LDAP

Came across to this article which very well details out, how one can Programatically refresh date from LDAP.

The articles also have a Sample Code to programatically refresh data from the LDAP.

I am sure, this would be helpful for those who encounter this use case.