Docker Presentation

Here is a docker presentation prepared by me.

https://drive.google.com/open?id=13y6k4fmZPyYWFEQZfKttEUzOApklYZWX

Conversion of UTC time to Local Time

In order to indicate that a time is measured in Universal Time (UTC), you can append a capital letter Z to a time as in 

2015-03-10T07:11:30.079Z

The Z stands for the “zero meridian”, which goes through Greenwich in London, and it is also commonly used in radio communication where it is pronounced “Zulu” (the word for Z in the international radio alphabet). Universal Time (sometimes also called “Zulu Time”) was called Greenwich Mean Time (GMT) before 1972, however this term should no longer be used. Since the introduction of an international atomic time scale, almost all existing civil time zones are now related to UTC, which is slightly different from the old and now unused GMT.]

So if it is required to convert UTC Time to Local time


        Calendar parseDateTime = javax.xml.bind.DatatypeConverter.parseDateTime("2015-03-10T07:11:30.079Z");
        Date time = parseDateTime.getTime();
        System.out.println(time);

that prints:

Tue Mar 10 09:11:30 EET 2015

while hour is 7 AM at Greenwich Universal Time, it is 9 AM at local.

Java Public Private Key Encryption

Following unit test simulates usage of public-private key encryption between two nodes. Basically, Client Node requests to Server Node with a public key and Server Node returns a data back to Client Node encrypted with client provided public key. This data can only be decrypted by Client Node using private key.



RSA 2048 bit encryption is used. Public Key which is byte[] is conveyed from client node to server node as Base64 encoded. Also give attention that how Public Key is reconstructed on server side from byte [].

An Acceptance Test Diary

I had been in Sarajevo during the 19 Jan 2005 week for acceptance test of a delivery and want to share with you what I experienced during this work.

Basically, in this delivery we introduced Diameter Charging support to Telenity SMSC product. SMSC establishes TCP connection to Diameter Server and performs charging requests over this connection.

During the tests, we observed that connection is lost after each 1 minute interval and SMSC re-establishes connections. Also in tcpdump we captured to see packets, wireshark shows retransmissions of each packet, i.e. after first packet immediately in nanoseconds a second retransmitted of this packet is seen as sent below.

 

 As you can see packet 24 of 23, 26 of 25, 30 of 29 is shown as retransmitted.

My first impression about this connection loss was related with those retransmissions, as suggesting that somehow diameter or firewall/loadbalancer between SMSC and diameter is triggering that connection loss because those retransmissions are treated as a security issue by that firewall/loadbalancer etc. According to that suggestion, we tried to figure out reason of that retransmission issue to avoid connection loss and after consumption of hours, nothing we achieved.

And then after a during of brainstorming and discussions with other engineers and analysing the packets, we figured out that, that connection loss happens exactly after 1 minute of establishing connection (or last sent packet) by a FIN,ACK packet sent from diameter to SMSC. This FIN,ACK is an order of terminating to connection.

After exactly 1 minute of last packet 45 sent to diamater, we receive FIN, ACK from diameter at packet 46 and loosing connection, then after 2 second, we re-establishes connection.

Here is details a about connection termination with FIN,ACK.

And the only meaningful explanation of this 1 minute mystery is that: If no packet is sent during 1 minute, diameter server thinks that established connection is not healthy because it does not received any packet during 1 minute and it requests for connection termination. According to that analyse, we configured heart-beat mechanism on SMSC to send watch-dog packets to diameter at 10 sec to keep connection alive, and it worked :).

Below you can see watch dog request/answers packets 1-3, 6-8.

So my first suggestion was wrong, there were no relations between connection loss with re-transmissions.

Everything was working fine although we eliminated connection loss but could not those re-transmissions, on the other hand yet no seen side effect of, customer was asking about reason of those re-transmissions.

At my last hours of last day at Sarajevo, while discussing with customer about opening support ticket to my company for resolution of that re-transmissions issue, somehow with the help of muse, I detected that we are getting tcpdump with "-i any" interface parameter without being sure or not much thinking about meaning of that parameter or even without being aware of that parameter while executing the tcpdump command, in short we were violating the rule: "Know about what you’re doing while you’re doing it".

This is the tcpdump with any interface:

tcpdump  -vvv -i any -s 0 -w /tmp/test_charging_live_http.pcap port 8080

And then we started to recapture without "any" parameter

tcpdump -s 0 -vvv -w /tmp/charging_http.pcap host 172.31.247.71

and no retransmission!!!

Actually there were no-retransmissions all along, the first one and retranssmitted one is only same packet but since we use “–any” parameter while taking tcpdump caused recapturing packets on while passing over a second network interface. So wrongly wireshark shows that is retransmitted but actually it is the exactly same packet passing over two layers. They were not retransmitted but same packet because within IP header figure out that identification fields were the same for both packets and equals.

  

Here is one more link that might be useful: https://ask.wireshark.org/questions/1284/wireshark-showing-lot-of-tcp-retransmissions-is-it-real-retransmission-or-wireshark-showing-incorrectly

Finally, we ended with no issue, it was a great experience with a lot of learnings and enjoyed trip.

Measure Your Computer Usage Performance

Today, while trying to concentrate on what Imam says during Friday Prayer, attacking lots of different thoughts over my mind, one was that, how hard I have been working last 2 months, who knows how many times I stroke on keyboard, how many times I click on mouse even in a single working day. This curiosity produced a program when I back to Office after prayer. Here you can see details in git-hub.

Download the project and execute run.sh (for linux) or run.bat (for windows) under dist folder, and let program run on background while you work.

The program will count your keystrokes and mouse clicks and log total counts after each hour and day in myp.txt file under your home directory.

I guarantee, You will be surprised when you see counts :), and respect to keyboard and mouse for their endurance.

A special thanks goes to JNativeHook for their library I used in this project to listen system to get keyboard and mouse events.

Are you asking my performance since I started computer for preparation of this blog entry? Here

2014.12.05:22 MouseClicked:232, KeyTyped:2524

CC - What is Clean Code?

Ref: Clean Code by Robert C. Martin

Bjarne Stroustrup, 

inventor of C++and author of The C++ Programming Language

 

I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.

• Elegant, Pleasing to read. Reading it should make you smile the way a well-crafted music box or well-designed car would. Straightforward, hard for bugs to hide.
• Efficient, this should not surprise us coming from the inventor of C++
• Does one thing well, Clean Code is focused.

Grady Booch, 

Author of Object Oriented Analysis and Design with Applications

 

Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control.

• Readable like a well-written prose
• It should contain only what is necessary.

“Big” Dave Thomas, 

founder of OTI, godfather of the Eclipse strategy

 

Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways for doing one thing. It has minimal dependencies, which are explicitly defined, and provides a clear and minimal API. Code should be literate since depending on the language, not all necessary information can be expressed clearly in code alone.

• Readable as makes easy other people can enhance it.
• Dave ties cleanliness to tests. He is right, Code without test is not clean.
• Minimal, Smaller is Better. 3S Rule: Small-Simple-Safe
• Literate, in a form as to make it readable by human 

Michael Feathers, 

author of Working Effectively with Legacy Code

 

I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better. All of those things were thought about by the code’s author, and if you try to imagine improvements, you’re led back to where you are, sitting in appreciation of the code someone left for you—code left by someone who cares deeply about the craft.

• One word, CARE. Michael hit it on the head. Clean code is code that has been taken care of. Someone has taken the time to keep it simple and orderly. They have paid appropriate attention to details. They have cared.

Ron Jeffries, 

author of Extreme Programming Installed and Extreme Programming Adventures in C#

 

• Runs all the tests;
• Contains no duplication;
• Expresses all the design ideas that are in the system;
• Minimizes the number of entities such as classes, methods, functions, and the like.

Ward Cunningham, 

inventor of Wiki,

You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.

• when you read clean code you won’t be surprised at all. Indeed, you won’t even expend much effort. You will read it, and it will be pretty much what you expected. It will be obvious, simple, and compelling

 

 We are Authors

The @author field of a Javadoc tells us who we are. We are authors. And one thing about authors is that they have readers. Indeed, authors are responsible for communicating well with their readers. The next time you write a line of code, remember you are an author, writing for readers who will judge your effort.

The Boy Scout Rule

It’s not enough to write the code well. The code has to be kept clean over time. We’ve all seen code rot and degrade as time passes. So we must take an active role in preventing this degradation.

The Boy Scouts of America have a simple rule that we can apply to our profession.

Leave the campground cleaner than you found it.

If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot. The cleanup doesn’t have to be something big. Change one variable name for the better, break up one function that’s a little too large, eliminate one small bit of duplication, clean up one composite if statement.

CC - Clean Code Matters

Ref: Clean Code by Robert C. Martin

Uncle Bob states why clean code matters with a story, I have experienced this story as a member of tiger team in my career and much probably you have too :

If you have been a programmer for more than two or three years, you have probably been significantly slowed down by someone else’s messy code. If you have been a programmer for longer than two or three years, you have probably been slowed down by messy code. The degree of the slowdown can be significant. Over the span of a year or two, teams that were moving very fast at the beginning of a project can find themselves moving at a snail’s pace. Every change they make to the code breaks two or three other parts of the code. No change is trivial. Every addition or modification to the system requires that the tangles, twists, and knots be “understood” so that more tangles, twists, and knots can be added. Over time the mess becomes so big and so deep and so tall, they can not clean it up. There is no way at all.
 

As the mess builds, the productivity of the team continues to decrease, asymptotically approaching zero. As productivity decreases, management does the only thing they can; they add more staff to the project in hopes of increasing productivity. But that new staff is not versed in the design of the system. They don’t know the difference between a change that matches the design intent and a change that thwarts the design intent. Furthermore they, and everyone else on the team, are under horrific pressure to increase productivity. So they all make more and more messes, driving the productivity ever further toward zero.

The Grand Redesign in the Sky

Eventually the team rebels. They inform management that they cannot continue to develop in this odious code base. They demand a redesign. Management does not want to expend the resources on a whole new redesign of the project, but they cannot deny that productivity is terrible. Eventually they bend to the demands of the developers and authorize the grand redesign in the sky. 

A new tiger team is selected. Everyone wants to be on this team because it’s a greenfield project. They get to start over and create something truly beautiful. But only the best and brightest are chosen for the tiger team. Everyone else must continue to maintain the current system.
 

Now the two teams are in a race. The tiger team must build a new system that does everything that the old system does. Not only that, they have to keep up with the changes that are continuously being made to the old system. Management will not replace the old system until the new system can do everything that the old system does.
 

This race can go on for a very long time. I’ve seen it take 10 years. And by the time it’s done, the original members of the tiger team are long gone, and the current members are demanding that the new system be redesigned because it’s such a mess.
 

If you have experienced even one small part of the story I just told, then you already know that spending time keeping your code clean is not just cost effective; it’s a matter of professional survival.

You will not make the deadline by making the mess. Indeed, the mess will slow you down instantly, and will force you to miss the deadline. The only way to make the deadline—the only way to go fast—is to keep the code as clean as possible at all times.

Here is a great post stating about why refactoring is better than rewriting, tiger team in Uncle Bob's story did.

PragProg - Unit Testing

Ref: The Pragmatic Programmer

The Software IC (Integrated Circuit) is a metaphor that people like to toss around when discussing reusability and component-based development.The idea is that software components should be combined just as integrated circuit chips are combined. This works only if the components you are using are known to be reliable.

Like our hardware colleagues, we need to build testability into the software from the very beginning, and test each piece thoroughly before trying to wire them together.

Chip-level testing for hardware is roughly equivalent to unit testing in software—testing done on each module, in isolation, to verify its behavior. We can get a better feeling for how a module will react in the big wide world once we have tested it throughly under controlled (even contrived) conditions.

A software unit test is code that exercises a module. Typically, the unit test will establish some kind of artificial environment, then invoke routines in the module being tested. It then checks the results that are returned, either against known values or against the results from previous runs of the same test (regression testing).

Why do we go to all this trouble? Above all, we want to avoid creating a "time bomb"—something that sits around unnoticed and blows up at an awkward moment later in the project.

TIP 48: Design To Test

By making the test code readily accessible, you are providing developers who may use your code with two invaluable resources:

1. Examples of how to use all the functionality of your module
2. A means to build regression tests to validate any future changes to the code

All software you write will be tested—if not by you and your team, then by the eventual users—so you might as well plan on testing it thoroughly. A little forethought can go a long way toward minimizing maintenance costs and help-desk calls.

TIP 49: Test Your Software, or Your Users Will.

PragProg - Refactoring

Ref: The Pragmatic Programmer

Change and decay in all around I see …
H. F. Lyte, "Abide With Me"

As a program evolves, it will become necessary to rethink earlier decisions and rework portions of the code. This process is perfectly natural. Code needs to evolve; it's not a static thing.

Rather than construction, software is more like gardening—it is more organic than concrete. You constantly monitor the health of the garden, and make adjustments (to the soil, the plants, the layout) as needed.

Business people are comfortable with the metaphor of building construction: it is more scientific than gardening, it's repeatable, there's a rigid reporting hierarchy for management, and so on. But we're not building skyscrapers—we aren't as constrained by the boundaries of physics and the real world.

The gardening metaphor is much closer to the realities of software development. Perhaps a certain routine has grown too large, or is trying to accomplish too much—it needs to be split into two. Things that don't work out as planned need to be weeded or pruned. Rewriting, reworking, and re-architecting code is collectively known as refactoring.

When Should You Refactor?

When you come across a stumbling block because the code doesn't quite fit anymore, or you notice two things that should really be merged, or anything else at all strikes you as being "wrong," don't hesitate to change it. There's no time like the present. Any number of things may cause code to qualify for refactoring:

• Duplication. You've discovered a violation of the DRY principle (The Evils of Duplication).
• Nonorthogonal design. You've discovered some code or design that could be made more orthogonal (Orthogonality).
• Outdated knowledge. Things change, requirements drift, and your knowledge of the problem increases. Code needs to keep up.
• Performance. You need to move functionality from one area of  the system to another to improve performance.

Real-World Complications

So you go to your boss or client and say, "This code works, but I need another week to refactor it."
 

We can't print their reply.

Time pressure is often used as an excuse for not refactoring. But this excuse just doesn't hold up: fail to refactor now, and there'll be a far greater time investment to fix the problem down the road—when there are more dependencies to reckon with. Will there be more time available then? Not in our experience.

You might want to explain this principle to the boss by using a medical analogy: think of the code that needs refactoring as a "growth." Removing it requires invasive surgery. You can go in now, and take it out while it is still small. Or, you could wait while it grows and spreads—but removing it then will be both more expensive and more dangerous. Wait even longer, and you may lose the patient entirely.

TIP 47: Refactor Early, Refactor Often.

How Do You Refactor?

At its heart, refactoring is redesign. Anything that you or others on your team designed can be redesigned in light of new facts, deeper understandings, changing requirements, and so on. But if you proceed to rip up vast quantities of code with wild abandon, you may find yourself in a worse position than when you started.

Martin Fowler offers the following simple tips on how to refactor without doing more harm than good

1. Don't try to refactor and add functionality at the same time.
2. Make sure you have good tests before you begin refactoring. Run the tests as often as possible. That way you will know quickly if your changes have broken anything.
3. Take short, deliberate steps: move a field from one class to another, fuse two similar methods into a superclass. Refactoring often involves making many localized changes that result in a larger-scale change. If you keep your steps small, and test after each step, you will avoid prolonged debugging.