Posted by: lrrp | October 15, 2017

Never Stop working on yourself…..

Posted by: lrrp | October 15, 2017

The software engineering notebook

Fellow software engineers/hackers/devs/code gardeners, do you keep a notebook (digital or plain dead-tree version) to record things you learn?

Since my days assembling glassware and synthesizing various chemicals in the organic chemistry lab, I’ve found keeping notes to be an indispensable tool at getting better and remembering important lessons learned. One of my professors recommended writing down, after every lab sessions, what had been accomplished and what needed to be done next time. When lab sessions are few and far apart (weekly instead of daily), it is easy to forget the details (for example, the mistakes that were made during weighing of chemicals ). A good quick summary helps with this!

When I first started working for a software company, I was overwhelmed. Academic software development was indeed very different to large scale distributed software development. For example, the academic software I wrote was rarely version controlled and had few tests. I had never heard of a ‘build’ or DEV/QA/PROD environments, not to mention things like Gradle or Jenkins. The academic software I worked on was distributed in zip files and usually edited by only one person (usually the original author). The systems I started working on were simultaneously developed by tens of developers across the globe.

To deal with the newbie developer info-flood, I went back to the concept of a ‘software engineering lab notebook’. At first, I jotted down commands needed to setup proper compilation flags for the dev environment and how to run the build locally to debug errors. A bit later, I started jotting down diagrams of the internals of the systems I was working on and summaries of code snippets that I had found particularly thorny to understand. Sometimes these notes proved indispensable in under-stress debug scenarios when I needed to quickly revisit what was happening in a particular area of the codebase without the luxury of a long debug.

In addition to keeping a record of things that can make your development and debug life easier, a software engineering lab notebook can serve as a good way to learn from previous mistakes. When I revisit some of the code I wrote a year ago or even a few months ago, I often cringe. It’s the same feeling as when you read a draft of a hastily written essay or work of fiction and then approach it again with fresh eyes. All of the great ideas suddenly seem – well- less than great. For example, recently I was looking at a server side process that I wrote to perform computations on a stream of events (coming via ZeroMQ connection from another server ) and saw that for some reason I had included a logging functionality that looped through every single item in an update (potentially 100s ) and wrote a log statement with the data! Had the rate of events been higher, this could have caused some performance issues, though the exact quantification of the impact still remains an area where I need to improve. Things such as these go into the notebook to the ‘avoid-in-the-future-list’.

Posted by: lrrp | October 14, 2017

Do You Have ‘Self-Taught’ Imposter Syndrome?

In a world where devs are increasingly self-taught, it may be easy to negatively compare yourself to those colleagues who have a BS or MS in Computer Science. But don’t.

A lot of you are brilliant, and you don’t know it. It saddens me to see such wasted potential in those that think they are not good enough but in fact are amazing and often 10 times better than those that think highly of themselves. These people, not all of them, but some, I feel suffer from imposter syndrome.

I will do my best to explain my experiences with this mental state of mind and how I’m currently battling with it. Once you understand what imposter syndrome means, and a read a real life example, I hope you get some mental clarity.

Always Planning: Procrastination

Once you see what I’m talking about you will understand the importance of taken action instead of planning. This is the only cure for “imposter syndrome.” Allow me to explain.

What Exactly Is Imposter Syndrome?

By its very definition, it is a concept describing high-achieving individuals who are marked by an inability to internalize their accomplishments and a persistent fear of being exposed as a “fraud.”

Let me start with my personal experience. I know I’m good at what I do. But often times, I get the fear that I’m not as good as the teacher or that I should not do it because it’s already been done. I believe this has been established since I have been on my own. I know I am good enough, and I know I can get it done. But the feeling that I don’t deserve what I have persists.

Imposter Syndrome: The Roots I’m Seeing

Learning in isolation and being self-taught leaves you (typically) to hold yourself accountable. Whereas in college and other team-based learning environments, you have a team or classmates to compare and be held accountable against. The lack of accountability while learning (no bad grades here) sets an unvalidated tone in our society. You didn’t go to school, why should you be trusted? Other forms of validation are also, in my opinion, critical to our success, but understanding which ones to seek makes the difference.

It is important to understand that not being validated is something a lot of people fear in their careers. Being validated means you have the skills or you are “valued” for your achievements. The misconceptions of what validation truly is versus what it is believed to be is the number one thing that holds people back from excelling in their careers and life in general.

Getting the Right Validation

What Is the Wrong Kind Validation to Seek?

The desire to please everyone. Negative, unconstructive opinions and thoughts of you mean absolutely nothing. Get that into your head. If someone doesn’t provide feedback that helps you grow, it isn’t worth accepting. Do not take invalidation from negative peers, take validation from your works and knowing you did your best and always working towards improving.

The piece of paper. – The internet has changed the way we learn by several orders of magnitude. It has lifted us to new heights and has made us excel in research and innovation. This has left some developers who are self-taught without the ability to land high paying gigs in the corporate world. The need for a bachelor’s degree continues, when, in all reality, the real world experience that we have implemented by far exceeds the value of the 4-year computer science degree. Real world experience always triumphs unused knowledge. Don’t get me wrong – having a degree is fantastic! But it shouldn’t be a huge variable in today’s world.

Please don’t let not having a degree bother you. If you are self-taught, you have a lot of skills that many others don’t. It takes self-discipline to sit down and do research in order to learn a new craft. You have to take pride in that. Never undervalue the education you are presented with, even if it’s an education you gave yourself at your own pace.

Where Should You Find Validation?

The answer should be your work. Your work is your validation. At the end of the day, when you lay your head down, your projects, your art, whatever it is you have tossed out into the world is your validation. It shows, “Hey I can do this. I did this. Look here it is.” Hopefully, people will see what you can do and hopefully want to work with you or encourage you in a positive and motivating way.

Improve Daily – Remind Yourself Who You Are!

You have to tell yourself nearly every day that you are good enough. That you have the ability to succeed as long as you put time and energy into your goals. That you will succeed and that there is only one person who could stop you. Yourself.

Keep this in mind: I have to hold myself accountable for all my work. Only I can change my direction. Each day I wait is a day I get behind. I will move forward. I will succeed, and I will establish myself in the areas of my expertise. I will grow every day. I will do something unique to find new people and opportunities. I will not fail. I will never give up. I will always do my best to complete what I put my blood, sweat, and tears into. I will not be scared to hear the word ‘No’ and I will not be afraid to overcome it either.

How to Over Come Imposter Syndrome

One word, execute. I have noticed that when I have the most down time is when the imposter syndrome kicks in. I don’t think I’m good enough. I question life choices. If I’m executing, doing something productive, like writing this blog, then I’m doing something to put something out into the world which serves as my validation. Some people will read this, some will share. Others may not even get past the first sentence. But it is okay. The ones that reach the end are all that matters.

You have built your own success – remember that.

Posted by: lrrp | October 8, 2017

Microservices Communication: Eureka Client

Eureka! No more need to store service URLs in code properties and update them with every change. Service discovery with Eureka will solve the problem for us.

In the previous Java microservices tutorial example, I created a Eureka Server. In this tutorial, I will show you how microservice communication happens. In this tutorial, I will create a Eureka client that communicates with a Eureka server — a microservices service registry.

Before diving into the code, let me tell you more about the about Eureka’s client/server communication.

Eureka Client/Server Communication

Talk to the Eureka server: At first, while the Eureka client is bootstrapped, it tries to talk with the Eureka server in the same Zone. So, suppose a Eureka client instance is in the Asia Zone —  it tries to connect to the Asia Zone’s Eureka server. If it is not available, then it fails over to another Zone.

It determines its targets using the eureka.client.serviceUrl.defaultZone property, so we need to give a URL of the same Zone’s Eureka server. And for failing over to another Zone, the Eureka server should be peer connected.

Register: Next, the Eureka client/microservices share the instance information with the Eureka server and registers themselves with the {service-id } (

Heartbeat: After registration is successful, after every 30 seconds, the Eureka client sends a heartbeat to the Eureka server to renew its leases. So, if after 90 seconds the Eureka server does not get any heartbeat from the Eureka client, it unregisters the Eureka client instance from the service registry and sends the updated registry to all peers and Eureka clients.

Fetching service registry: Eureka clients fetch the service registry from the Eureka server so it can discover other services and communicate with them. After every 30 seconds, this service registry information gets updated by receiving delta updates from the Eureka server. Please note that the Eureka server also caches the delta updates every 3 minutes, so the Eureka client can receive the same delta instances multiple times. After receiving delta updates, it again tries to compare its local registry with the server registry to check that delta is successfully applied. If there are any mismatches, it pulls all the registries again.

Unregister: When the client instances are going to shut down, they send a cancel signal to the Eureka client so the Eureka server unregisters it from its registry.

Synchronization: Be aware that there may be some time lag as the Eureka server and client manage the cache.

Coding Time:

We will make the EmployeeSearchService a Eureka client. To do that, first, we need to add the discovery module for Spring Boot in the Maven pom.xml.


Now add the @EnableDiscoveryClient annotation on top of

package com.example.EmployeeSerachService;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
public class EmployeeSearchServiceApplication {
   public static void main(String[] args) {, args);
After that, run the Eureka server first, then EmployeeSearchApplication. You will see that the Employee Search application is registered in the Eureka server with the service id EmployeeSearchService.

Learn what a Eureka server does, why it is useful in microservice architecture, and how to complete its standalone setup.

What Is the Eureka Server?

The Eureka server is nothing but a service discovery pattern implementation, where every microservice is registered and a client microservice looks up the Eureka server to get a dependent microservice to get the job done.

The Eureka Server is a Netflix OSS product, and Spring Cloud offers a declarative way to register and invoke services by Java annotation.

Why Is the Eureka Server?

To understand why the Eureka server is needed in microservice architecture, let’s understand how one service calls another service REST endpoint for communication.

Say we need to call the employee payroll service to get payroll information for an employee. The payroll service is deployed on the localhost 8080 port (we got that information by passing the employee primary key) so we just call the following:

http://localhost:8080/payroll/1 or

Where localhost/ is the hostname/IP address and payroll is the payroll service context, 1 is the employee primary key.

But this is only possible when you know the hostname/IP addresses beforehand, then you can configure your URL. So here the hostname or IP address is a constraint or a pain point.

If the IP address of a server/container is fixed, then you can use that approach, but what happens when your IP addresses and hostname are unpredictable?

Nowadays, on a cloud platform, it is obvious that all the servers or containers use dynamic IPs for autoscaling. And the interesting thing is that in microservice architecture, the key principle is that your service can autoscaled as per load, so cloud platforms are ideal for microservices.

What I am trying to say here is that we can not predict the IP addresses of the container/server beforehand, so putting dependent services IP addresses in the config file is not a solution. We need a more sophisticated technique to identify the service, and Eureka server steps in here.

Eureka Server/Client Communication

Every microservice registers itself in the Eureka server when bootstrapped, generally using the {ServiceId} it registers into the Eureka server, or it can use the hostname or any public IP (if those are fixed). After registering, every 30 seconds, it pings the Eureka server to notify it that the service itself is available. If the Eureka server not getting any pings from a service for a quite long time, this service is unregistered from the Eureka server automatically and the Eureka server notifies the new state of the registry to all other services. I will write this mechanism elaborately in the next article.

Now one question may pop up our mind: what is the Eureka server itself?

The Eureka server is nothing but another microservice which treats itself as a Eureka client.

What I mean is that the Eureka server has to be highly available as every service communicates it to discover other services. So it is recommended that it should not be a single point of failure. To overcome it, we need multiple Eureka server instances running behind a load balancer. Now when there are multiple Eureka servers, each server needs to have synchronized registry details so that every server knows about the current state of every microservice registered in the Eureka server registry.

The Eureka server communicates its peer server as a client and clones the updated state of the registry, so the Eureka server itself acts as a client. We can perform this by just configuring the eureka.client.serviceUrl.defaultZone property.

The Eureka server works in two modes:

  • Standalone: in local, we configure a stand-alone mode where we have only one Eureka server (localhost) and the same cloning property from itself.
  • Clustered: we have multiple Eureka servers, each cloning its states from its peer.

The Eureka server can have a properties file and communicate with a config server as other microservices do.

Standalone Setup of Eureka Server

Step 1: Create a project template from While creating the template choose the following modules:

  1. Config Client
  2. Actuator
  3. Eureka Server



Step 2: Open the downloaded code template and import it as a Maven project in your IDE. The pom.xml looks like this:

<?xml version=”1.0″ encoding=”UTF-8″?>




    <description>Demo project for Spring Boot</description>


        <relativePath/> <!– lookup parent from repository –>












Step 3: Now open and put the annotation @EnableEurekaServer on top of the class. By doing so, this application now acts as a service registry. All other Microservices can register themselves by using this service URL.
package com.example.EmployeeEurekaServer;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
public class EmployeeEurekaServerApplication {
    public static void main(String[] args) {, args);
Step 4: Now change the to as it may consult with the config server if it has any properties defined in config server. In the file, write the following lines:
Unique name for Eureka server service
It consult with other Eureka server for sync the service registry as it is standalone mode I give the local server address.
In which port server will be bound.
This determines is this server register itself as client as I said earlier Eureka server is also act as client so that it  can sync the registry.The value false means prevent itself act as a client.
Not register itself in service registry
Now our Eureka server setup is complete. We will now run this project as a Java application. Now hit the following URL: http://localhost:9091. You will see the following dashboard:
Posted by: lrrp | October 7, 2017

The Burden of Being a Senior Developer

To truly be a ‘senior’ developer, one needs to not only have the requisite experience but a need to get better a produce quality code.

Who is a senior software developer? A developer who has over seven years of experience. I think this is not quite encompassing. I think it is a developer who possesses a certain state of mind. So a developer with six months’ experience can be senior (theoretically) if they have that state. But this state is usually acquired through knowledge and experience, over time. This state comes with some responsibilities (or burdens).

Any enterprise that is worth something is then worth doing well. And how do we do things right? By ensuring that what we do does not ‘collapse’ or is not done messily. In the field of software engineering, the fear of not incurring technical debt, and the ability to prevent such debt, is the state of being a senior engineer.

With the burden of a technical sort also comes an emotional one. In fact, the latter drives the acquisition of the former. And it is this emotional burden that I want to talk about.

I started out programming as an independent contractor in my home country of Nigeria. I specialized in Java applications. I was self-taught and happened (fortunately) to start out on high-level projects. Having been brought in on a referral, I quickly acquired a senior developer image before my clients (they were mostly international nonprofits), although I was new. I was stretched by these projects to research software engineering best practices (not because I was required to do so by my clients, but for fear of mediocrity). So I had an accelerated path.

Now, seven years after my first gig I have decided to become a JavaScript developer. There is a dearth of quality software firms in my country (and I hate boring jobs). So I have set my eyes on a new American world-class software engineering organization with an office in Lagos. This company is of course very team-oriented in their development approach. But I have been like a solo assassin as a consultant, not like a member of a well-commanded army. So here comes my call for integrity and being true to the craft.

Will I apply for a senior position? By the way, I have seven years under my belt. And yes, I might land the job. But I will have holes in my skills. Now I would be working with people. Perhaps I would need some training.

I will be applying for a technical leadership program offered by the company, as a developer. I have the need (fear) to be competent if I would bear the title senior. When I have completed my training I would apply for a promotion.

Being a true senior developer comes with a huge emotional burden. You have the need for technical competence. You will not rest until you have the right (optimal?) architecture. You must learn and acquire knowledge. It is language-agnostic. You know when a solution or code doesn’t look right. You know (or are able to know) how to fix it. And you have the nightmare of living with bad code. If this does not happen to you, perhaps you are not yet senior.

Posted by: lrrp | October 7, 2017

Let Code Quality Guide You

Back in the 1990s when I was faced with multiple design choices, I’d have to code them up in multiple ways in order to figure out which one was best. This was time-consuming, and evaluating design choices was one of the hardest things for me.

But now I have a better approach, thanks to code qualities. If we agree that CLEAN code is good code, then we simply have to evaluate each design choice in terms of their code qualities and we’ll find the better options. I find that this is a fast way of evaluating design choices and now that I do it all the time, I can make these evaluations almost instantly.

Each code quality represents a key aspect of code. Cohesion means that code is more focused to deal with only one thing at a time, and it makes code much clearer and more straightforward to work with.Loose coupling means the code is more independent and easier to test in smaller units. Encapsulatedcode can’t be overwritten by something external so it’s more reliable. Assertive code is more performant and better organized. Code that is nonredundant costs less to maintain and extend.

Each code quality represents an important aspect in code that when missing can distort the object model and make code difficult to work with in the future.

These code qualities guide me. They are my teachers in the pursuit of understanding good code and I find that when I pay attention to these code qualities, I end up building code that’s more maintainable, more straightforward to work with, that’s in better alignment with the principles of good programming, and I even discovered design patterns.

Understandability in code is for us humans. Computers don’t care but we should. In order to maintain software, we have to understand it. We have to start by building software in such a way that it’s understandable. Architects don’t go off and just draw whatever they want on a blueprint without paying attention to the standards and practices of their industry. In the software industry, we need to establish good standards and practices that we can follow just like builders and architects follow.

Pay attention to code qualities that will help you more than anything else to stumble upon the right designs and have you use principles, patterns, and practices that support good software development. Let code qualities be your teacher and guide you to build code that continues to provide value into the future.

But don’t stop with code. If CLEAN is fundamental to the way we understand the world, then we should see it reflected everywhere—and we do. Good communication is cohesive. Healthy relationships are loosely coupled. Well-formed ideas are encapsulated. Healthy people are assertive. And unique ideas are nonredundant. These same code qualities are in the arts, in sciences—they’re everywhere because they help us understand the world around us. And because they’re everywhere, because they’re at the foundation of how we humans understand, we can and must imbue our software with these same qualities so that it can be understandable to us.

The good news is you don’t have to focus on all five code qualities. Just pick one or two that make the most sense to you and focus on those. What you’ll find is that as you improve one code quality, all the other code qualities will improve as well. They are not independent of each other. In fact, they are very much interrelated, like facets of the same gem.

Posted by: lrrp | October 7, 2017

Developers Love Development

We software developers are a fortunate lot. We love what we do, and a lot of the time, when we’re actually building software, we’re very happy people. Unfortunately, this isn’t universally true since so many software development projects require developers to do a lot of other things aside from writing code such as sitting through boring meetings and building documentation or other artifacts. This is not as enjoyable to us as facing the challenge of solving unknown problems, learning and discovering as we go. This is what attracts us to writing software.

Professional software development is fundamentally different than most people think. It has nothing to do with using software or networking or virtually anything else. Building software is an immensely creative activity.

One of the questions I ask almost every group of students I teach is do they think writing software is more art or science. The majority of developers say that although there are elements of both, that software development is more art than science. By this, they mean that there’s more creative and abstraction skills required to be a good software developer than there is an explicit process. Of course, it takes a tremendous amount of discipline to write even the simplest of programs but this is an area where we get addicted to growth. Developers love the challenge of building things that have never been built before, solving problems, and providing tools that improve people’s lives.

We really don’t conform to the typical stereotype of the antisocial nerd or geek who found friendship in silicone circuitry. Modern software developers come from all walks of life and all backgrounds.

Writing software is perhaps the most engaging and challenging profession of all. Software development requires a greatly diverse set of skills and we have to be good at all of them to be successful. To design software takes a tremendous amount of creative visualization-after all, we’re using our imagination to understand a problem and model its solution. To write software requires a great deal of tenacity-we must keep track of a large number of details and use a whole variety of techniques to manage the enormous complexity of even a relatively trivial program. To debug code takes exceptional analytical skills-completely different from the skills required to design software, but developers must be good at both. As a result, we tend to use both sides of our brain in the process of building software, and this can make for a highly satisfying experience, but also a highly challenging one.

I’ve asked a number of non-software developers what they think the process of writing software is and I’ve heard of lots of different answers, none of which are anywhere near what the process really is about. I supposed that’s true for other fields. Professional acting is much more than just pretending. Great actors become their characters and transform into another person. It’s a great skill to have and certainly very few people have it, but what they do is not anything like the title of their profession implies. They are not act-ors, they are “be-ors.”

I know people who have gone into the restaurant business because they love the process of sharing food with their friends. But preparing five hundred meals a day is very different from sitting down with your friends and enjoying a scrumptious dinner. Chefs are some of the hardest working people of any profession. It’s a highly intense environment, which is why a lot of people drop out of the profession. I think a lot of people in a lot of fields feel like they have to make compromises because that’s just the way life is, and perhaps it is for many of them, but software developers still find fulfillment in our work every day we actually get to build software.

Of course, it takes an enormous commitment and it’s certainly not easy to break into the profession. Most of the developers I know learned what they needed to on the job or through a lot of self-study. As such there’s a huge divergence in skill sets and knowledgeability in this industry. There is no set of clear standards so it can be challenging to work on teams when everyone has their own ideas on how to do things.

Writing software is a group activity. Most software development projects do not have coders siloed from each other just turning code out. Most of the code built for business today happens in a subdued environment that requires entire teams of individuals to work together. Of course, developers aren’t really known for their social skills, but a lot of that is changing as we realize the desperate need for communication among teammates.

How do you evaluate a design?

This is a question I often ask software developers in my senior advanced software design classes. I tend to get blank stares in response, not because they don’t know how to evaluate a design but they rarely have a common rubric to apply. This can be a challenge for teams, making it hard for us to communicate and collaborate when building software. So I spend a lot of time in my classes defining terms that will serve us in being able to evaluate what’s virtuous in software designs.

Developers love my classes because they immediately recognize the value of talking about and thinking about these things. I’ve had the chance to work with many senior software developers and I’ve made it my mission to find out why the successful ones are so successful then I share that with other developers I work with. It seems as if we each have a piece of the puzzle, and when we put it together we get the big picture. That’s precisely what I do in my work, which is amazingly satisfying.

Posted by: lrrp | September 17, 2017

Hates when you win….


“Don_t blame others as an excuse for your not working hard enough”

Older Posts »