It’s been close to 18 years I am involved in software testing and learning something new all along. It was interesting all along! When I remember those early days when I started testing software verses how I test now – change is really surprising. Those were days when testing was considered as separate activity in software development. Typically someone not ‘preconditioned’ by program was preferred to perform testing so that he/she can look at it critically, from user’s perspective rather that from programmer’s glasses knowing design limitations. This also in a way promoted testers to keep away from code since knowing the code was synonym for being preconditioned with design limitations.
Typically it was more of manual testing with lot of repeat runs till the time software reached stage which was acceptable for production release. Was it enjoyable? Answer is yes and no. Yes – for the part of test…
My first blog is inspired by quote from Venkat Subramanium in his book “Functional Programming in Java 8”.
“The common, familiar design patterns are more approachable when we design with lambda expressions; we need fewer lines of code, classes, and interfaces, and far less ceremony to implement our designs.”
Other inspirations are Dhaval Dalal who lately got us introduced to Functional Programming. And lastly Naresh Jain whose Object Boot Camp provoked a thought of building a good habit of writing Blogs for our own good.
The hospitality industry has been following revenue management practices for decades now. Today, dynamic transient pricing is considered the industry standard for pricing guest rooms. Now, as rate transparency and channel complexity has increased, we hear hotels asking, “Can I manage my property’s revenue just by adjusting rates?” and “Why do I still need to manage rate availability?” It is clear that there is confusion in the hospitality industry regarding dynamic pricing and its role in maximizing profitability. The confusion around pricing approaches has paved the way for vendors to claim to have complete revenue strategy solutions, even though the solution may address only the pricing aspect of revenue management, and ignore rate availability management and its benefits. Simply put, hotels cannot maximize their revenue or profitability solely by managing rate prices.
Daily Pricing and the Limitations of “Pricing-only” Decisions
To articulate the limitations of “pricing-only” approaches, let’s work on…
First, let me thank IDeaS CSR (Corporate Social Responsibility) committee and specially Pritam n Shivani for such a wonderful idea.
This is our second year @ IDeaS where we celebrated our Christmas event with the children, youngsters & even elders from Kamayani Org.
Following has been a trend on both the occasions but I would talk about this time’s proceedings.
All the employees from IDeaS gathered in the reception BEFORE these guys (I would refer them as Enthusiasts or Champs) reached our office. Full marks to IDeaList for being there BEFORE they came. Thank you guys for that…Of course, even I was there.
When they reached on the 3rd floor, we welcomed them with a warm applause. Some of our mates were ready with Christmas caps. As they came, we helped them wear it. These champs were looking really cool.
We gave them individual gifts (probably a Santa would have been perfect, but nevertheless, may be next time). We also gave a gift for Kamayani organization.
Few incidences worth noticing here.. One of our team mate, approached a champ to give the individual gift and he promptly indicated that he already got one… Look @ his innocence…
There was another champ who was checking with other `Champ` if he got one or not… See the attitude of giving!
After we gave the gifts, these guys were prompt enough to say Thank you. Loud and Clear…
Let me take a pause here even while writing it… It’s tough for me even to write…
Then we served them snacks. Watching them enjoying the food made my tummy FULL.
My colleague Avadhoot Joshi gave each of these champs “blessings” by touching their forehead (Reiki touch therapy). Avadhut Sir, let me say “Thank you a million times “… You are super.
Then, one of their accompanying teachers came forward with a guy. Speciality of this guy is that he is good @ reading.. Every single day, he reads news paper & is so good @ general knowledge & especially has interest in following sports. He knew every milestone of Sachin Tendulkar as well as Steffi Graph.
Bad on my part that I wasn’t able to stand there (was too emotional & so left the place for 5 mins). When I returned, teacher was explaining that they are organizing a cricket tournament on Kamayani’s very own ground on 6, 7, 8th Jan.
Finally, we did thank them. Pritam (our Admin n HR Manager) handed over the gifts for those who couldn’t make it. These champs were equally excited to go back and hand over the gifts to their colleagues. What an amazing attitude..Hats off to you champs..
When Pritam asked if they would be interested to come next year, Boyyyyyy…!!! You should have been here to hear a big “Yesssssssssssss”…
Overall, it was an amazing experience, so much touchy that it made an impression deep in the heart.. Here is my IDeaS team… Thanks to all of you, you guys are awesome…!!!
From my perspective, it’s a heavy dose and was certainly a tough time to control the emotions when being there.. Not sympathizing about them here but looking @ them makes me think a lot.
Rather than cribbing, these guys live every single day with such an enthusiasm. Hats off to you champs.!!!
When I introspected myself, I felt really sad knowing how I crib and get frustrated/tensed/sad with the situation @ hand. I would, certainly try to learn it from them.
Cheers to you Champs…!!!
I recollected one story that I heard:-
Once, king Akbar announced” I want something that, if I use, would keep me grounded if I am happy but more importantly make me feel happy if I am sad no matter what the situation is. Whoever would bring such thing to me would get rewarded… ”
Everyone in his kingdom including his 9 gems tried to find it but couldn’t find one…
Next day an old man came to his Darbar with something in his hand.
Akbar asked “So you found the thing which would make me feel happy in any situation”, Old man replied “Yes, I do”
All of his 9 gems surprised to know this. Old man offered him a finger ring and asked Akbar to wear it. Akbar, all though, was puzzled, wore it. As he wore it, he got thoroughly convinced that the ring is the thing that he was looking for.
Gems asked Akbar how can a ring do that.
Akbar answered “On the ring, old man has written – This phase shall pass”
Wow… what a thought.
Often we keep cribbing & get frustrated/tensed/sad for the situation we are in.
If your developers fear touching the code, then you know you’ve hit the legacy application nightmare. This could be due to lack of test coverage, lack of domain knowledge, outdated technology stack or simply lack of comfort dealing with unknown code base. To me, this is the reality in most successful software applications. As they build new features to adapt to the market needs, they end up accumulating technical debt. Some might be better at paying off the debt, when compared to the rest. But taking on debt is inevitable.
Recently, we (Ashwini Alhat, myself & 2 more developers) started working on a product that was developed around 7 years back. When we looked @ the code base, we were happy to find some JUnit tests. But soon we realized the test cases were outdated and none of them passed. Fixing the tests seemed like a huge task in itself.
The product/application is into Revenue optimization for a particular industry (that’s what we do @ IDeaS:)) ETL is part of our application & it requires daily feeds from the 3rd party application. In order to improve the output from our Revenue Optimization analytics, we decided to enhance the data feeds specifications, for new clients. However we had to support both Specification 1 (earlier specification) & (new) specification 2.
At this stage most of our developers have seen the benefit of automated (unit and acceptance) tests. It was a scary thought for a developer to think about changing legacy code without the safety net of automated tests. However we HAD to change the code to support Specification 2.
With the help of Naresh Jain and Sachin Natu, we had learnt the right test automation strategy is to implement the Test Pyramid.
But, in our case, if we spent the time in first implementing the correct test pyramid (means 70% of Unit Tests) then it we would have obviously missed the Business timelines.
2 Layers to start-with
So after discussing with Naresh, we took a more pragmatic approach. We started with a couple of Workflow and Domain Logic acceptance Tests for the existing Specification 1.Advantage of writing these two layers of Tests was that we were confident while touching the code that as long as these Tests for Spec. 1 are passing, we haven’t broken anything significant for Spec. 1.
Now, if we look @ the Workflow test, since they are business facing tests, they should be implementation agnostic. These tests shouldn’t know how the data is stored and retrieved. They should never be tied to the database scheme.
Hence we decided to expose our existing services, as RESTful endpoints that would return the required data to verify. And hence the requirement of “RESTifying our application.”
So as a part of the last Ship It day (we have our Ship It day every quarter & Thanks Ashishfor introducing it in IDeaS) we chose to RESTify our application.
As most of the people would do, we did the same thing… We googled for some sample codes & we found few… We downloaded the sample project from javacodegeeks and built and ran it. Now, we thought that it’s going be easy to implement the similar thing in our application.
Our legacy application uses Ant scripts to build the project. The first roadblock we hit was trying to identify all the dependent JARs required to make the application RESTful.
The downloaded sample helped us in this case. The sample application was built using Jersey & Jersey-JSON APIs. Also, it was a Maven project and so when we built the .war application out of it, it pulled all the required dependencies (Thanks Maven you were useful here :), sometimes simple logical thinking helps :D).
So with that, we were ready with dependent/required JARs & it’s related infrastructure setup.
We have Struts, Spring, Hibernate & MySql in our application. Struts Action Handlers and middle Service/Manager layers are all Spring Beans (Initialized using IoC).
Like any other standard app, Service/Manager layer would implement the main business logic and Struts handlers would deal with the Request/Response part. So our idea was to RESTify the Manager layer (rest assured that we knew that we need to have good security layer around it) & so we started googling about Jersey-Spring Integration. We are using spring version in 2.5. Yes, it was that old.
We could find many references that talked about Jersey-Spring integration but for the Spring 3.0 version onwards. We were getting little anxious thinking that no-one has ever tried this, but we kept hunting.
In the mvnrepositorywe could find list of older version of Jersey-Spring integration. Believe me, but we tried all the way up to version 1.0 but it was in vain. It didn’t produce the expected behaviour. It was unable to pull the Spring bean from the application context and so all of it’s dependents beans were NULL. Boo Woooohhh!!!! 😦
Time was running and our attempt to RESTify the application was making no headway. We took a step back and discussed once more.
What’s the key objective?
Is it make our Service/Manager layer REST Enabled or is the intention is to make the application REST enabled by some way. Answer looked fairly simple. We realized that even if we would have found a Jersey-Spring integration out of the box then also, given the fact that we we would expose the REST endpoint (all though to the application), it would require us to push the incoming data validation down to the Service layer (which means, a lot of code change in the service layer).
So we took the approach of introducing a REST End-Point layer. This layer would internally pull the spring bean from the context & then make a call to an appropriate Service/Manager bean to get or PUT the data. This way we could control the data validation @ this layer even before calling the spring bean’s method. This implementation (after setting up the stage) was a no brainer and we could easily implement it for a service/manager. This success opened the gates to many needs.
We (myself, Ashwini & Naresh), are all excited with this breakthrough.
Though there were many anxious moments during our attempt to RESTify the legacy application, I must say, that the journey to `successfully RESTify a legacy application` was something we ate breathed & drank in those 24 hours…
We are no more afraid to touch the existing code.
We have ability to enhance the application and make it AJAX based