Category: Software development

This is a continuation of my earlier post of Tree, recursive function and my dumb mistake. As I said in my last post, my solution was to create hash maps (singleton) to store those for the session. The main motivation was to help out the performance. But I found out it backfired on me, a few days ago and today. In both cases, it has to do with the hash map I created, it was something like (object , a list of objects). In both cases the list of objects was actually dynamic, and I made an assumption it was static. In other words, I thought I only need to put the mapping to the map once, then I can use it happily ever after. I think there might be ways to get around it, i.e., I should update the map when that list does change. I will investigate and work on it more. (Update 05-30-14) So I found a solution to one scenario, I was able to update the map as needed. And I use put method (java hashmap) to do that update.

Related articles

• Singleton Design Pattern- Java Tech Guy must read!
• Singleton Design Pattern – An Introspection w/ Best Practices

So I was able to fix that performance problem I mentioned in my previous post. But I inadvertently introduced a new problem in my previous fix. And here is the gist of how I did:


while (some condition) {
if(some other condition) {
...
return;
}
}


Guess what, I was able to put it into infinite loop…I can explain more if needed 🙂

Tree data structure is fairly common in software development, and luckily I have quite a bit experience working on those in my career. I started working on this as I was working for UGS/Siemens PLM Software, and I was involved in the development of XML based data adapter for CAD data exchange, a key piece of information we want to translate is the assembly information, or product structure, or in computer/software terms, the tree hierarchy. I did learned a few things on recursive function, etc. Interestingly enough, later on I got a interview phone call from Google, and the guy asked me about recursion, for a simple problem like this: basically they are 100 matches, every time one can take one or 2, how many combinations are there? I said let’s do it in recursive fashion, after quite a bit reminder/hint, finally I said n(100) = n(99) + n(98)

But they were not very impressed with me, as I did not come up with the solutions fast enough, which is fine. I am who I am, I can work on those kind of interesting problems, in my own pace. Or explained in my Chinese name, it’s getting faster gradually 🙂

My dumb mistake

(Update 02-19-2021)

spring.io Testing the Web Layer

Mockito Example with Best Practices

JUnit and Mockito : Best Practices, Do’s and Don’ts

(Original) Test Driven Development (TDD) is getting popular these days. I had opportunity to being exposed it recently. I am not new to unit test. In the software company I worked for 8 years, we have regression test suites that runs automatically (at least daily), and we update the test suites as we find edge cases from customer bug reports, or in our development. That was about 8 years ago. Since the switch into Java land (2010), I started using JUnit and create/run the unit tests. One thing I was exposed to recently is Mocking in unit test, and TDD. Both takes a little time, and I am not fully bought into TDD yet. But I did learned something interesting on both topics lately, and like to share.

1) TDD
One of my coworker is very experienced and in-grained in this, as we are doing pair programming, I learned this a bit. An interesting back and forth as I was making changes to a method.

Coworker: “Do you have a test case?”
Me: test case for what?
Coworker: for the change?
Me: do we need this? …

But eventually we wrote the case, magically the web app also worked as soon as we passed the unit test. But overall I still have some reservation to do this, as I am not good at mocking e.g. Mockito, or writing test, and I think there is some cases pair programming can get the code right without go heavy in unit test.

Some links for mockito and spring test

Stubbing and Mocking with Mockito and JUnit

https://www.vogella.com/tutorials/Mockito/article.html
https://stackoverflow.com/questions/39486521/how-do-i-mock-a-rest-template-exchange
https://www.baeldung.com/spring-mock-rest-template
https://stackoverflow.com/questions/11969609/junit-mockito-when-thenreturn-throws-nullpointerexception/18060451
https://javacodehouse.com/blog/mockito-tutorial/

2) Unit test (auto test suites)
I heard from my coworker recently that test suites should not use the implementation data source (database). I thought the main reason is the heavy weight/use from database resources point of view. But there is more, today I found if auto test consistently changes things on dev database, it’s really hard to find out the root cause, and cause confusion. Initially we thought the problem was caused by batch job, or the web app, spent a lot time trying to figure out, both are not the cause. And luckily, at the end we were able to find out the real cause.

This is the common saying I heard a lot when I started worked for a software company on development. I can list some of the pros and cons of fix it.

Pros
Architecture chaos: if not fixing it, basically as the software ages, per the “broken windows” theory, people would just throw in changes to get things done, without carefully thinking about the architecture, dependencies. And this leads to the related problem below.

Code hard to maintain: it will become harder and harder to fix bugs, or add new features with the code in a messy state.

Cons
Introduce new bugs by accident. Or the fix making the software worse. While it’s unlikely, it’s still possible. Not carefully planned fix could introduce bugs, and make the software worse. I have done my share of that too 🙁

Refactor
If we were to work on the clean up, refactor the code, as a minimum we should have the regression test suites. Or in ideal world, we would have automated unit tests, which could help both speed up development, and give another level of confidence for the code change.

Reading Time: 2 minutesIn my 13+ years of software development career, I have done both. So which one do I prefer? This is a bit like asking my daughter: who do you like more, mommy or daddy? (I will reveal my daughter’s answer at the end.)

I think both are interesting work, and both could be challenging. If you ask me pick one, I will probably pick the new development, as most developers like to work on new things: from new technologies to new features, new project/product. But from time to time, I have worked on some bug fixing work that is not only interesting, but also challenging and rewarding (mentally not financially, as I worked for companies all these years). I recall 6, 7 years ago, when I was working for CAD software company, we had two bugs to fix, the first one is actually not too bad, essentially it’s a tolerance problem. In other words, I just need to make sure when it checks whether the X, Y, Z axis is orthogonal to each other, I gave some tolerance. I did cross products of vectors, borrowing from similar experience I learned at work.

The second one, is a bit daunting, to say the least. Essentially we have about 2 weeks to fix a nasty problem in a CAD translator, and we don’t have any clue why the results is wrong. By working with 3rd party, and looking carefully at the problem, some teamwork, I was able to solve the mystery when I was working remotely at Shanghai. I recall I could not fall asleep that night, as I knew that’s a tough problem and will help the sales team greatly to sell into a top Europe car maker.

I had similar experience most recently, although it’s a totally different problem, and we as developers also work in much different world: with stackoverflow.com, and google search (blogs).

So back to my daughter’s answer to my silly question: most of times she will say mommy and daddy; sometimes she will say “don’t ask silly questions”.

PS: in some places bug fixing is also called as maintenance. Just like the car maintenance, software also needs regular check-up and fix 🙂