HOME | Blog | YouTube | LinkedIn | About Me         || Calculators    | SoftEng/Tech Posts    | Code/Scripts

Tuesday, April 18, 2017

How Vlogging can wake up the creativity in you

A lot of us engineers have creativity but it is not the type of creativity non-engineer/non-analytical group of people typically have. Actually this other type of creativity is deep in us, but we need to somehow wake it up.
I did not explicitly look for ways to wake up this creativity in me; it happened in the process of doing vlogs with my family and friends, or at least I think it did. I have done YouTube videos in the past, but I have not put much thought into making them attractive. Even though they were tech videos and car videos, I could’ve applied a bit of authenticity in them to show my personality and when the personality comes through, then your videos are that much better.
My vlogs are not even public and I am having fun doing them. I spend time with my family on weekends and I figure out the story that I want to deliver and I attempt that 2–3 times during each weekend. Then I share the vlogs with my family. Creativity does not just come out if you do an occasional vlog in a month; it is that routine and daily pressure over the weekend that pushes you to be more creative and to improve. I am no Casey Neistat, but I am trying. I will keep doing it while I am having fun even though my audience with these unlisted YouTube family vlogs reaches only 30–40 views :)
What are you doing to wake up your creativity? Is it music? Is it photography? Is it art? Is it poetry? Whatever it is, go for it! Have fun.
Thanks for reading.
Almir Mustafic.

Wednesday, April 12, 2017

My fascination with Python — the journey I can’t fully explain

My career started in the Unix/C++ world in late 90s. Then I transitioned to a Microsoft shop doing C++ and then later .NET/C#. Recently I got into open-source technologies such as Java, NodeJS and Python. It’s been a fun journey over last 19–20 years doing software engineering. All software engineers should be privileged to be in the positions that we are in.
In last 2+ years I started getting into Python outside my work because I wanted to see a different perspective. I’ll be honest; even after 2+ years programming things in Python here and there, I am still not used to the Python syntax. I have been a critic of Python as I have been learning it. The curly brackets { } are very much engraved in my system and I still prefer the Java/C++/C# syntax, but there is something else about Python that has me fascinated. Maybe it is its simplicity. Maybe it is availability of different libraries that allow you to do cool things from IoT to web development. Maybe it is the cool community.
That fascination has led me to developing some interesting applications in my spare time that I also applied in my daily job. Some of those are:
  • * Production log analysis (Keeping track of existing errors/exception and detecting brand new types of errors/exceptions)
  • * API testing developers’ friendly tool/framework
  • * Microservices dependency analysis tool
  • * Tool for correcting DynamoDB data via your microservices (batch updates)
  • * Recommendations on modularizing Python code for existing Python operations code at work
I am not sure what my next application is going to be. It definitely depends on my availability at home. When I come up with an idea, I usually spend a week of evenings preparing for it and looking into the libraries that I could use. Then I usually develop the initial version over one or two weekends. One negative thing about Python is that it does not enforce disciplined and structured programming. However, if you combine your discipline from C++/Java/C# experiences with Python’s simplicity, you can develop some cool applications while writing elegant code.
If you have been in Java/C# world for a while, I recommend that you give Python a chance.
Thanks for reading this article. Please follow me and read some of my other articles in the software engineering field.
Almir Mustafic

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 20 years ago. Then I switched to a Microsoft shop at the end of 90s. I’ve been in the Microsoft world until recently, but I’ve shown 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 into 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 has solved problems and what 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 (Microsoft is also in open-source community now) and apply them in such a way to keep things simple. 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.
Thanks for reading this article. Please follow me and read some of my other articles about software engineering.
Almir Mustafic.

Scaled Agile Framework (SAFe) isn’t really scaled if you …

Scaled Agile Framework (SAFe) can help you in your organization if you use it the way it is intended. In SAFe, you have the program team that is a relatively lean team consisting of program managers, product managers and solutions architects. On the other side, the delivery teams/squads (product owners, tech team members) out-number the program team.
Therefore, SAFe is really a top-light system. What does this mean?
This means that you need to keep the delivery teams/squads constantly busy without ever falling into a situation where they are waiting for requirements/epics/initiatives to be specified and clearly defined. This can happen if the high-level requirements are produced in smaller increments and if they are groomed with a smooth flow and cadence.
So if your organization is trying to implement SAFe and you still get requirements in huge bulks every 6 months, your single point of failure becomes the program team.
Keep trying but after a while you might as well be truthful to yourselves and realize that this is not working. You are better off admitting that SAFe isn’t for me. You can still have the top part of your organization work in waterfall-ish way when it comes to defining requirements, reviewing requirements, doing the high-level technical design and planning. There is nothing wrong with that. On the other hand, the execution of the plan can be in “agile” fashion that goes well with the microservice architecture if you happen to implement this type of architecture. “Waterfall-ish” is not perfect, but it is still better than fooling yourself into believing that you are running SAFe and you are not.
The important thing is that you don’t really feel as if others are looking down on you because you are not fully implementing the “agile” methodology. What is really “agile”? I prefer to use the word “agility” because it a real noun. Agility is something you make it your own. Do an increment of work, discover what you can improve to go faster and smoother, improve it and repeat the process. Stick to basics.
Thank you for reading this article. Please subscribe and read some of my other articles.
Almir M.

Microservice Dependency Analysis Tool — Trust me; you need this

If you are reading this article, I am assuming that you are either in the process of implementing microservice architecture or you are thinking about it.
The microservice architecture has a lot of advantages and I am not going to talk about that; there is plenty of material about this topic that you can find on different blogs and also on YouTube.
The disadvantage of the microservice architecture is that it can easily get out of control because of the quantity of the moving pieces. You have to have a way of managing it. Therefore, you need the following:
  • * Capability built into the architecture to find all the configuration about microservices and their versions deployed in each environment.
  • * A tool that takes the above mentioned configuration (per environment), calculates the dependency among all microservices (and their versions) and displays this via graphs and/or or in a readable text/html format.
  • * An easy mechanism of measuring real-time calls among all microservices.
Here is a more detailed list of the tool mentioned above:
  • * Overall dependency graph between microservices
  • * Microservice A depends on the following microservices (text/html version)
  • * Microservice A depends on the following teams (text/html version)
  • * Team 1 depends on the following microservices (text/html version)
  • * Team 1 depends on the following teams (text/html version)
We talked about the WHAT; let’s talk about the WHY.
Why do you need this?
First, you need it to paint the big picture. Don’t underestimate the value of the big picture. Even if you are not doing the architecture work on daily basis, you still need to paint the big picture in the territory of your team and the teams that you are dependent on and the teams who are your clients.
You also need this to do impact analysis. The impact analysis is something you may do when you receive new requirements or when you have a problem in production (from usability or security point of view). This is where every second is crucial as your customer satisfaction is at stake and your revenue is at stake.
What about the HOW?
There are many different ways you can implement this. The most important advice is that you start simple and you can keep it simple. Build something, use it, then make it reusable and making it reusable may mean that you are buying a piece of software or a library that does this or fully building it in-house. For example, if Python and Boto3 library is something you use deploy your cloud infrastructure and deploy application code, you may choose Python as the programming language and building these type of tools is less costly and easy to evolve as you are getting more mature in your microservice architecture.
Thank you for reading this article. Please subscribe and read some of my other articles.
Almir M.