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 

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:

http://almirscorner.blogspot.com/p/horsepower-weight-calculator.html

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 

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:

Learn
Anyone can learn the basic concepts of Computer Science. Choose an intro activity to start learning.code.org

Every child deserves opportunity
The Hour of Code is a one-hour introduction to computer science, designed to demystify code and show that anybody can…hourofcode.com

Scratch - Imagine, Program, Share
Scratch is a free programming language and online community where you can create your own interactive stories, games…scratch.mit.edu

Try it out. Have fun !

Almir M.

#education #programming #code #coding

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

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

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