Monday, May 23, 2016

POC in HTML/NodeJS, Java microservices — what I have done to engage better with my product team and consumers of our microservices

My team and I have been working on an important strategic project in our company. We are trying to improve our agility and in the process of doing that, it is important that our product team gets to see their own product in action before we end up spending multiple iterations developing it.
Sometimes you find yourself developing a microservice that is used in the overall design and then you realize that you really need to meet with the teammates who are going to consume your microservices. You need to agree on the APIs (request / response). Agreeing on these APIs is valuable to our UI developers and possibly developers of other microservices that may consume my microservice, but it does not really give a good live representation of the overall product to product management teammates after 1st or 2nd sprint. My goal was to have a journey working from A to Z in the first sprint.
What I decided to do is the following:
(1) Picked the most important customer journey.
(2) Created a diagram of this customer journey and annotated the diagram explaining what microservices would be called at what point in the journey. Keep in mind that this is all based on my initial thinking. I know that the design was not perfect. However, no project was successfully delivered without the original design and no project was delivered by the original design. Having that initial design is very important for having more productive conversations when you walk into a room with a lot of smart developers.
(3) Coded three core microservices to be functional without hard-coding and with the actual database backend. I also put together a stubbed version of some peripheral microservices.
(4) Dashboard/Programmer’s Page: I coded a simple HTML page (hosted by NodeJS) that uses Javascript to make AJAX calls to all microservices to fetch the data from all the tables and to display in somewhat presentable fashion. It is a more presentable version of your data than directly accessing the database in your demo.
(5) POC Website to represent a customer journey: This is a list of HTML pages hosted by NodeJS. These HTML pages are very simple pages but very functional as per the mockups provided. These pages are functional to the degree that they do call the POC versions of microservices and make the journey very interactive without using any hard-coded information.
The goal was to have this overall POC be used by product owners so they can provide good feedback and that feedback can be added to subsequent sprints. By building this POC, we already achieved one goal and that is our initial design which will evolve in future sprints. In the process of developing this overall POC, I learned so much about what I want in these microservices and it helped me define the initial version of the data structure for each microservice and the initial version of the business logic needed to support the customer journey that I picked. Yes, this design will need to evolve and improve.
I kind of coded most of this in my personal time during the first sprint because I thought it would help out the team a lot. What I would like to see in future projects is that this approach becomes the definition/standard/guideline for every sprint #1.
Almir M.



Saturday, May 21, 2016

Your car’s character changing with a simple modification

I currently drive a 2008 Honda Fit (aka GD3 chassis). It has a 5-speed manual transmission and a 1.5L engine that can be very lively when pushed. Over the years, I worked out a typical formula that I like to apply as soon as I buy a car. 
That formula consists of:
  • * suspensions modifications to make the handling fun
  • * cat-back exhaust modification
  • * lightweight wheels
  • * summer performance tires
  • * possibly an air intake system depending on what car I get
In a nutshell, they are all very functional changes. These type of changes turn an economical car into a fun car that puts a smile on my face every time I drive it. I spend on average 1h 30min every day in my car so I choose to make it fun for me. Everybody is different and everybody defines “fun” for their cars differently. You may be into horsepower and I totally respect that; you may be into stance look and I also respect that.
I am slowly getting to my point. The changes above are what I consider standard modifications that absolutely change and the character of your car and that’s what we expect.
However, there are changes that I would never consider as character-changing modifications and yet they are. I am talking about very simple and cheap changes. No, it is not that “10+ HP” sticker even though that’s sometimes fun to do because my low-power Fit needs it :)
I am specifically talking about a shift knob change and a shift lever extension modification. I started with an aftermarket Karcepts shift knob that made the gear shifting a pleasure because of the added weight in this shift knob. The weight of the shift knob just makes the lever fall into the right gear with more confidence. The second type of character-changing modification is the shift lever extension. I recently purchased a 3" shift lever extension for my Honda Fit. After a quick installation I could not believe how much it changed the character of my car. This meant that the shift knob is closer to my steering wheel and when doing canyon drives, it means that I could use both hands on the steering wheel and have the shift knob in close distance for more confident gear changes. So this modification gave me that “rally racing” feel. To some degree, having this taller shift lever gave me a feel as if I am driving some old school Porsche and I am a big fan of 1960s, 1970s and 1980s Porsches.
So what I ended up doing is alternating between the short shifter and the shifter with this extension and it totally changes the character of my car with a 2-minute swap. That’s the advantage of having a manual transmission.
These are the small things that keep me happy. What is the simple modification on your car that puts a smile on your face every time you drive your car?
Almir M (almirsCorner.com)



Thursday, April 14, 2016

Linux Tip of the Day -- Environment variables, bash script execution in the context of your command-line window

Linux Tip of the Day --  Environment variables, bash script execution in the context of your command-line window


I had to remind myself about this as I worked on Unix/Linux platform a long time ago and having been in Microsoft shops for many years did not help either :)


If you want your environment variables (being set up by another script) to be properly set up in the context of the window where you are running the script, you have to run the script with a dot and a space in front of it as shown in the screenshots below.


Screenshot of vim editor showing you the content of setup.sh script:











Executing the script in bash window and then verifying if an environment variable is set up:













Almir M.

#Linux #bash #scripts #environmentvariables #programming #code #coding

Saturday, March 12, 2016

Kids & Information Security - Fun Introduction

Teaching kids about information security is very important today because the social network websites and applications are blurring the line between what should be shared securely and what not.

Everybody is busy over-sharing the good, bad and ugly over the internet and in the process of doing that forgetting the basics of information security or never taking the time to learn it. Or is it that nobody is introducing these concepts in school? It is something that needs to be introduced in our education systems from early days.

Do you remember the days when we used to send those short messages on a piece of paper in our classrooms? Some encoded those messages because you did not want another person in the middle to open it and understand what it says. How were those messages encoded?

The simplest example is: You create a simple mapping for each letter and number in the alphabet. Then you encode your message and write it on a piece of paper. Then the person on the other end decodes this message knowing the mapping because you shared it with them secretly.

Here is an example of mapping:

Separator between characters is ;;;
A is 0
B is 1
C is 2
D is 3
E is 4
....etc
a is 100
b is 101
...etc

Then if you want to encode "Do you want to play tennis tonight?", you would write the following:

3;;;114;;;___;;;124;;;114;;;120;;;___;;;122;;;100;;;113;;;119;;;___;;;119;;;114;;;___;;;115;;;111;;;100;;;124;;;___;;;119;;;104;;;113;;;113;;;108;;;118;;;___;;;119;;;114;;;113;;;108;;;106;;;107;;;119;;;?;;; 

The person on the other side would be able to translate this message into English as long as you previously shared the mapping with him/her. Obviously with the technology these days you would not be using paper and translating this; you would be using a software tool. I quickly put together an example in a simple web page using Javascript where you can plug in some sentences and it will use the exact same mapping as I explained above.

Try it out: HTML page where you can try this


The example above is a very simple mapping. If you want to use a slightly more complicated mapping, here is another example:

Try it out: Encoding/Decoding example in Javascript


The above algorithms for encoding/decoding are simple and can be figured out by experts very easily but they are relatively complex for novice and average computer users. These examples are just a way of introducing these concepts and encouraging you to teach your kids the importance of security.

These examples are easy to try and have some fun with them. You can save those examples as HTML files on your local computer, then edit the file and change the mapping at the top of file to what you want. Then in some secure way share that HTML file with your friend. From that point, you can send encoded messages to your friend in an email. The receiver can decode the message by copying and pasting the message into this simple HTML page and decoding it :)

Let's use this opportunity to do a quick security gauge of your security habits and if you have kids/nieces/nephews, teach them. Here are few comments/questions for you:

  • If you are using the same password across multiple accounts, you should change this.
  • If your passwords have names of cities, countries, or any word that you can find in a dictionary, you need to change this habit very soon.
  • If your passwords are not long enough and complex enough, then you need to do something about this. Details on what "long enough" and "complex enough" can be found on internet and the best way to deal with this is to use well respected tools for this. 
  • Are you using two-factor authentication for any accounts that support this?


Almir M.

#InfoSec #encoding #decoding #programming #programmer #code #coding #software #softwaredevelopment #InformationSecurity #SecureCommunication 

Friday, March 11, 2016

Horsepower per Weight Calculator - Really?

There is saying “Horsepower is what sells cars”. That is mostly true. This blog post is about pointing out another factor that is important in determining what the horsepower number really means. If you are a car enthusiast, then you are probably bored by this post, but even we car enthusiasts need to be occasionally reminded about it.
Here is the link to this simple calculator and my explanation is below:
The horsepower number tells you how powerful the engine of that car is. It does NOT tell you how fast that engine can move the car. This is where you need to look at the overall weight of your car. The laws of physics cannot be broken. If object A is heavier than object B, then you will be slower running with object A in your backpack. The same rules apply to cars.
Let’s look at one example. My 2008 Honda Fit has a 1.5L engine producing 109hp and it weighs 2465 LB. 2016 Honda HR-V has a 1.8L engine producing around 141hp and it weighs 2888 LB. If you calculate power-to-weight ratio and you use the Honda Fit as the BASE, then Honda Fit stays at 109hp and Honda HR-V ends up being 120hp. So when Honda HR-V is compared to Honda Fit, it does NOT really have 141hp; it has 120hp. This is how I like to compare cars; I use my current car as the baseline.
Another way to approach this is by calculating Weight/Horsepower ratio. Keep in mind that smaller number is better.
This is not a deciding factor but it could be one of factors for some of us. At the end of the day, nothing replaces a test-drive and the X-factor of a given car without looking at any calculations. For example, based on my list below, my car has the top 2% worst ratio, but I still have a big smile on my face as the power is not a deciding factor for me. However, I might be an exception.
Here is the list of WEIGHT/HORSEPOWER ratios of some cars for your reference. Keep in mind that smaller number is better.
  • 22.6 lb/hp (2008 Honda Fit LX) …..my current car :)
  • 16.9 lb/hp (2016 Acura TLX, 2.4 AUTO)
  • 14.4 lb/hp (2016 Acura MDX SH-AWD)
  • 16.6 lb/hp (2016 Audi A4 2.0T quattro)
  • 11.6 lb/hp (2016 Audi S4)
  • 8.9 lb/hp (2015 Audi RS5)
  • 7.1 lb/hp (2015 Audi R8 V10)
  • 13.8 lb/hp (2016 BMW 328)
  • 16.5 lb/hp (2016 BMW i3)
  • 9.7 lb/hp (2016 BMW i8)
  • 7.2 lb/hp (2016 Chevrolet Corvette Stingray 1LT)
  • 11.0 lb/hp (2015 Dodge Challenger R/T)
  • 5.8 lb/hp (2015 Ferrari 458 Italia)
  • 23.4 lb/hp (2016 Fiat 500)
  • 8.5 lb/hp (2016 Ford Mustang GT)
  • 19.3 lb/hp (2016 Honda Fit LX)
  • 20.5 lb/hp (2016 Honda HR-V LX)
  • 17.7 lb/hp (2016 Honda Civic EX CVT 2.0L)
  • 16.7 lb/hp (2016 Honda Civic EX-T CVT 1.5L Turbocharged)
  • 17.8 lb/hp (2016 Honda Accord Sport CVT, 2.4L 189hp)
  • 14.6 lb/hp (2016 Honda Pilot EX 2WD)
  • 12.1 lb/hp (2009 Honda S2000)
  • 5.6 lb/hp (2014 Lamborghini Gallardo LP-560 AWD)
  • 8.5 lb/hp (2016 Lexus RC-F)
  • 10.5 lb/hp (2011 Lotus Elise Base)
  • 15.0 lb/hp (2016 Mazda MX-5 …Miata)
  • 19.6 lb/hp (2016 Mini Cooper Base)
  • 14.7 lb/hp (2016 Mini Cooper S)
  • 7.2 lb/hp (2016 Nissan GT-R)
  • 7.7 lb/hp (2016 Porsche Carrera S)
  • 6.3 lb/hp (2016 Porsche Carrera Turbo S)
  • 6.3 lb/hp (2016 Porsche GT3 RS)
  • 7.7 lb/hp (2016 Porsche Cayman GT4)
  • 10.0 lb/hp (2016 Tesla Model S P90D AWD, 463hp)
  • 25.4 lb/hp (2016 Toyota Prius Two …..121hp)
  • 18.2 lb/hp (2016 Toyota Camry LE)
  • 15.6 lb/hp (2014 VW GTI)

Almir M. (almirsCorner.com)
#cars #horsepower #lightweight #racing 

Thursday, March 10, 2016

Teaching Kids the Concepts of Programming - How important is this?

Code kids? Let me start by saying that I was NOT a code kid. Generally speaking a code kid is a kid that starts programming at early age and by early age, I am talking about 6 to 12 years old. I was good in math and science, but the first time I was exposed to programming was in grade 8 which is considered late by code-kid standards :)
In grade 8, I was writing code on paper and asking one of my friends to borrow his Commodore-64 to see what it runs. I was excited to see my first for-loop working. When I really got into it, I was in grade 11 and 12.
I enjoyed it and I have been deep in this world ever since. There is a level of satisfaction that programmers get when they figure out a problem after hours of troubleshooting. It is hard to explain until you experience and you can experience it.
Does every kid need to end up working as a software developer? No, they don’t, but being introduced to programming in early days is very important for exposing kids to different type of problems and clever solutions for those problems. It is actually not the final solutions that are important; it is the approach and thought process that is more important.
The level at which humans think, and the approach humans take to solve problems is much more advanced than the level that computers are at. Computers are good in repeating things that you program them for, and we as humans need to program them. You really need to explain to computers in layman terms how they should perform something in the form instructions. So we should give ourselves a lot of credit for that. Teaching kids how to break problems into layman terms is not easy, but kids are smart and they absorb information much faster than adults can. Combining these problem-solving skills with good communication skills is a powerful recipe for success.
Here are the links to some of the organizations that put their passion into introducing kids to coding/programming:
Try it out. Have fun !
Almir M.
#education #programming #code #coding

Tuesday, March 8, 2016

Healthy To Learn Something Outside Your Box

When you have a problem to solve, what is the most typical way to approach it?
Everybody is different, but most of us try to stay within our comfort zone because that’s what makes us feel more stable or more secure. We have one tool and we try to solve all the problems with that tool. When it comes to providing software solutions, you have to step a bit out of that comfort zone in order to innovate and in order to provide flexibility for someone else to innovate.
I started my career in Unix/C++ software engineering world years ago. Then I switched to a Microsoft shop at the end of 90s. I’ve been in the Microsoft world ever since, but I’ve shown a bit of interest in other technologies that are from the open-source community. In last few years I started digging deeper into Python, Node.js, and recently back in Java area. I have not been doing this because I am unhappy with what Microsoft had to offer, but I am rather doing it because I want to explore and find out how the open-source community have solved problems and what the solutions/options are in the open-source world. This expanded my horizon a lot. It could mean that I will stay more in the open-source world or it could mean that I would take the concepts I learned and take them back into the Microsoft-shop and apply them in such a way to keep things simple and proper at the same time. Regardless, it is a win-win for me.
What are you doing to step out of your box? Try to dedicate only 1 hour per day and don’t worry about your progress. Check back in 30 days and you will see amazing results.
Almir M.

#productivity #softwareengineering #programming #softwaredevelopment #outsidethebox #learn #learning





Sunday, March 6, 2016

Challenge the person that tells you “We don’t really do agile here”

How many times did you hear somebody say “We don’t really do agile here”.
What does that even mean? First, the word “agile” is not a noun and you can’t do “agile”. We all forget this and we all get caught using the word “agile” as a noun.
The Agile Manifesto is very good, and how some of the organizations that promote scrum approach interpreted that manifesto is just one way of looking at it. I understand why these organizations worked on converting the word “agile” from adjective to a noun. It is because you can sell nouns and you can’t sell adjectives. Think about the overall industry that is built around training people on agile methodologies and all the certifications. I have nothing against these organizations writing books and providing courses on this matter. That is all good. I encourage everybody to learn and get exposed to different types of opinions and interpretations. You can treat all that available material on agile methodology as case studies. We all know that case studies are taken, absorbed and then you decide for yourself and for your organization what works for you.
You and your organization really need to go back to basics. Go back to that Agile Manifesto, print it in huge print and post it on your walls. Then take all that knowledge from scrum master certification courses, SAFe courses and define for yourself what that manifesto really means to you. It may mean that you start with a very simple approach; for example, you could start by doing the following:
  • Analyze at the end of your sprint, just find one thing that you would want to improve.
  • Improve it during the next sprint and acknowledge that small win.
  • Repeat the process and get that much closer to higher level of agility.
Your organization has a lot of smart people who are passionate about increasing agility because the word “agile” lost its meaning. You can create a committee of these smart individuals and have them exposed to all the training material on the agile methodology and then bring them back into the room and work on how you can translate the Agile Manifesto into a very achievable and short list of guidelines (not rules) for your company that you can evolve through iterations.
Let me just leave you with one simple advice. Please make sure that the items on the RIGHT side of the manifesto do not weigh more and tip over the scale to the right side.
Almir M.
#agile #agility #scrum #softwaredevelopment #softwareengineering #SDLC

Saturday, March 5, 2016

Self-Organizing Team — Is this possible? What happens to the tech lead role?

Teams, tech leads, self-organization and responsibilities are some of the keywords that I will use this in blog post.
Let me first ease into this topic by talking about the role of tech leads in the software engineering field. Be patient with me as this is all directly related to the main topic. I believe that the role of good tech leads is very often underestimated or taken for granted until they are removed from the equation and then you start realizing how much work goes into it. While the role of tech-lead is kind of stuck in between keeping project/program managers happy and working on low-level technical details, there are what I call unofficial/unwritten benefits of being a tech lead. You are in that special position as a leader where you are closest to all the activities on the floor and you can shape and improve things unofficially even though there are different rules and perceptions at that layer above. If you have that super-connection with your fellow engineers/developers doing the amazing work on the floor, then you are in that unique position to influence how the culture shapes up in the company and how people feel when they show up to work every day. When you reach that level of connection with your fellow developers, you know that you would jump in front of a bus to save them and you know that they would jump in front a bus to save you when it comes to your projects. In most cases, you a tech lead know the members of all teams better than their own resource managers; you are their unofficial manager and you are in the position to influence their careers in positive ways. They follow you because they respect you and that’s a huge responsibility that tech leads have on their shoulders.
This leads me into the topic of SAFe (Scaled Agile Framework) and how the role of a tech-lead gets translated to the TEAM and a new role of a solutions architect gets born which is more tied with the overall architecture, product management and program management.
What do I mean by “tech-lead role gets translated to the TEAM”?
What I mean is that the TEAM does not have an official tech lead and that responsibilities of a tech lead need to be divided into small pieces and shared by the team and then somehow all of that has to be put together and facilitated to hopefully get the same results of having an official tech lead. Yes, there are less and more senior people on the team, but one thing that should NOT be done is just appoint that one more senior person and give all the responsibilities of a tech-lead to that person. What happens when you do that? You are basically taking abilities away from that senior person to do any coding/development throughout the major part of their days. For example, if you your teams are small then you might have just lost 25% of productivity.
What you as the organization really need to is identify the unwritten checklist of what tech leads do in order to make it a successful formula. Don’t try creating this checklist if you are not on the floor. You might have had experience in other companies with this, but their floor is different then the floor in your current company. Please reach out to your leads and team members and come up with a good list and keep fine-tuning it. I will share my list with you below, but let’s first discuss how you put all these pieces together and achieve the same result as if you had a full-time tech lead on the floor. This is where a strong scrum master role is absolutely vital. Let’s assume there are ten of these items on the list which a tech lead would typically handle. Let’s assume these are split among 5 people on the team. If each one of these five people handle two items, does 5 x 2 equal “10”. It will equal “10” if your scrum master does an amazing job and if every team member puts passion into what they are doing and constantly tries to improve it. The chemistry on the team has to be at the top, and the role of a scrum master becomes that much more important. Building that level of chemistry is not easy and to be honest, I am not a big fan of specific things in the agile methodology that make things mechanical and too military-like. How many times did you hear people say “Nobody does agile properly”. First, you can’t do “agile”. The word “agile” is not a noun? I understand why the scrum organizations made the word “agile” a noun; it is because you can sell nouns and you can’t sell adjectives. I am going a bit of tangent here. What I mean is that chemistry within the team cannot be naturally achieved if you have so many rules that you need to follow. In my opinion the agile methodology is about the Agile Manifesto and the programs and certifications that came out of Agile Manifesto are just one interpretation of that manifesto. So don’t allow anybody to tell you “we don’t really do agile here”. Challenge them on that statement. I encourage creative debates on it.
This leads me to the main topic about the self-organizing teams. All of the above recommendations is what can get you closer to having self-organizing teams. I specifically said “closer to self-organizing” because in reality the teams are never 100% self-organizing; you always need a little bit of leadership involvement to keep things in check. Even though that magic 100% is never reached, the main thing is that most of the tech lead responsibilities are evenly distributed among teammates and you are avoiding a very common problem of tech leads being bottlenecks and being overworked.
Here is an example of the list that could be taken from tech leads and distributed among teammates to get closer to self-organizing team. This is the list that I came up with as I was trying to make teams more self-organizing in order to free myself up to focus on strategic architectural items:
  • * Somebody who can decide at the beginning of the sprint when PAIR-PROGRAMMING is needed and on what story. This worked well in a recent projects where we paired up developers on bigger user stories. This was done selectively when needed. Both developers keep each other challenged and you are automatically doing peer-review and what I call drive-by demos.
  • * Coding methodologies review: Appoint a person who needs to have in every sprint a quick session to review with architecture what the approach is and find out what further architecture involvement is needed.
  • * Risk assessment on existing functionality in production due to common code changes: Somebody on the team should be made the owner on this item.
  • * Ongoing special instructions as you are coding during your sprint: Somebody needs constantly check with fellow developers if anything special had to be done besides regular code checkin/commits. Having a person that keeps people honest throughout the sprint is important during busy times and this is one of those things that could save you from late finding in Stage and Production launches. Obviously if you script/automate your special instructions, then it is that much easier.
  • * Quick drive-by meetings to explain to your peer how you are about to code something: You will be surprised how these “drive-by high-level technical designs” increase the quality of the software by a huge factor. Every developer should be doing and scrum master could be constantly encouraging this. This is where architecture members can be brought in if these drive-by sessions require need to be design oriented.
  • * Drive-by technical demos among peers after each user story: Instead of just marking that user story completed and ready for testing, I strongly recommend that you bring over a teammate and do a quick technical demo and you may get some recommendations that will help prevent issues down the line. Every developer should be doing this throughout the sprint.
  • * Peer code-review: When a developer finishes a user story, that piece of code should be given to a peer for a code-review before the code is checked in or committed to your source control. Every developer should be participating in peer code-review instead of relying on tech leads or senior developers.
  • * Main contact person to collaborate with system engineers and DevOps teams: Sometimes you have changes where you need new servers set up or a new type of build. There should be a go-to person on the team to be the spokesperson when communicating with system engineers and DevOps.
  • * Day-to-day support of the environments (Dev & QA): If QA teammates or somebody finds and issue in Dev/QA environments, somebody has to do the initial analysis and determine if it could be related to your teammate’s user story or it could be related to your user story. Having that one go-to person on the team to do the initial analysis saves the rest of the teammates from being interrupted. Obviously you can rotate this responsibility from sprint to sprint as any other responsibility in this list.
  • * Source control (TFS, Git, …etc): Somebody on the team should be responsible for source control related things and your branching and merging strategy. For example somebody should be doing forward integration from the MAIN branch (trunk) into your development branch and deploying those changes to your Dev/QA environments and doing some initial smoke-testing if things are not fully automated.
  • * Builds to Dev and QA runways throughout the sprint: Somebody on the team should be focused on doing daily builds or on-demand builds depending how automated or half-automated your builds are. If the build scripts are owned by a DevOps team outside your team, this teammate should be the focal point communicating with the DevOps team about any changes needed in build scripts as part of your sprint work.
  • * Final code-review: Somebody more senior on your team should review all the code and involve architecture on need-to-need basis on implementation and definitely involve architecture for design decisions before you even get to the final code-review.
  • * Launch preparation: There should somebody dedicated on your team to work with all the external teams (Change Control, DevOps, …etc) on preparation of your release to production. Obviously this person needs to understand the technical details of the release and have ability to translate that into instructions that Change Control team requires from the process point of view.
The items above are just examples of what a tech lead would handle and now the work would be divided among all teammates. Obviously teammates can rotate the responsibilities based on how the team decides.
Good luck, have fun, put passion into what you are doing and try to improve things from iteration to iteration. At a minimum, identify just one thing that you want to change to make things more flexible and do it. Repeat this from iteration to iteration. Isn’t that what agility is all about?
Almir M
#leadership #techlead #team #selforganizing #softwaredevelopment #softwareengineering #scrum #agile #agility #iteration