First month in DevOps

So, I've just completed my first month of DevOps training at Sparta and I feel like it's time to reflect. I'm doing this more for personal reasons than any other but hey, if you get something out of these then that's great too!

Structure

Because months are messy, I am planning on doing one of these every four weeks, the course runs for 12 weeks and simply put

12\div4=3

and that's good for me!

Each post will be broken down week-by-week but this month will be the longest, simply because I'm going to talk a bit about my background too!

Let's get started shall we?

Me, myself, but not I

I am an Electronic and Computer Systems Engineering (ECS) graduate from Loughborough University, this means that my background is more in hardware rather than software engineering. Whilst there I spent the majority of my time working in C, C++, VHDL, ARM Assembly and MATLAB. This means that I have a lot of experience working with the ARM Cortex-M3, ARM mbed and ZedBoard platforms

However, in my final year I had to complete a project and of all the briefs available the one that interested me the most was "Augmented Reality App". From this, my supervisor and I planned out a project that would be in an area of interest to us both and we settled on a social network.

This gave me the first insight into the world of DevOps, and although it was only a short intro as the majority of my time was spent trying to get the Augmented Reality part of the app working, the use of CloudKit (because it was at no extra cost and integrated directly in to Xcode already) got me thinking about how best to use servers in my workflows.

Anyway, after a year of trying to find a job in ECS and getting incredibly close multiple times but being blocked by a certain pandemic, some friends and classmates from university had told me that they had been having the same experience and that they had been discussing making the move to DevOps since some of the skills were transferrable and it was a market that needed a lot of new talent considering the aforementioned pandemic had highlighted how unprepared a lot of pre-existing infrastructure was for the increased demand put in place by a lot of everyday life moving online.

Then over the following few months I started doing research whilst working at my other job that I had picked up to earn some money on the side whilst I was looking for a job in my field and here I am!

Let's take a breather

Ok, that was a lot wasn't it? Well, before we move on, check this out:

Two tortoises, one sitting on top of the other

Ok! Onwards we go:

Week 1 - Business Week

The first week focussed a lot on developing consultancy skills, SCRUM and Agile were introduced here and I have to say that I was shocked to learn that I already knew of them. Not on a first name basis but I had accidentally set myself up a similar system for dealing with coursework. Experience with Kanban had also helped with the introduction to SCRUM.

Personally speaking, SCRUM is a better fit for me since the method of breaking down a big task in to user stories and sprints has helped tremendously in helping me better understand what project requirements mean. And Gherkins 🥒 he he.

Elevator pitches, profile creation and interview techniques were also covered, this will be useful in selling myself to potential clients or perhaps even later in life if I decide to find a new job. Even so, doing this has really helped to boost my confidence with public speaking since requiring me to do it in front of people I know and strangers alike has been refreshing!

But that's enough of that, let's scoot on to week 2!

Week 2 - Python

Week 2 has gotten me started in the world of Python. I had had a little bit of experience with Python before and had completed a DevOps course that Sparta had provided me with over on Treehouse. But I can confidently say that actually, Python ain't that bad. I've had a great time with it all things considered.

Obviously, having experience with C++ and Object Oriented Programming (OOP) helped (a lot) but a new language can be scary for many and but if there's one that's really good at teaching you the basics whilst still being a very powerful language, Python has to be it.

You cannot imagine the glee I felt when for x in y was introduced. Seriously, the amount of times I'd wanted to cycle through an array (or lists as Python groovily calls them) only to have to create a function that counts the amount of entries in said array and then another function to go through that array. Well, no more! Python does them both in one go.

I love how easy Python has been to pick up in comparison to some of the other languages I've learned, but it's not all roses. One of my colleagues described the way OOP was handled in Python as "a bit of an afterthought." The instructor was inclined to agree with them despite stating that it had been designed with OOP in mind. I wouldn't necessarily go that far but I would have to say that it's not really that much more improved over how C++ does it and I think (from what I've seen) that Java probably has the better implementation.

For instance:

def function():

Is a regular ol' function

def __function():

Is a private function

def __init__(self):

Is used to initialise a class.

I think it's a little messy, but luckily most IDEs are aware of this and give you the heads up.

I also think that the indentation system is very weird, and I think that if you're going to require a : at the end of your loop initialisation, you don't need to worry about indents so much. Do one or the other, but not both, if you get my drift.

So what I mean is, in some other language you can do this:

if x > y
do something
end if
///No problem👌👌👌

VS in Python

if x > y:
do something
return
# Nope, won't work

It just feels weird. But since I have always indented my code anyway, it hasn't been a problem for me.

This was the week we also started learning Git. I had some experience with it already after having lost some coursework back at university due to a crash, and vowing never again to let that happen! But it was clear that to those people being new to Git, it is a little user unfriendly, but more on that when we get to the first project!

At this point I also created a directory which grouped together all the lessons and tasks that had been completed so far!

monotiller / engineering89_directory

Quick access to all the lessons and tasks done as part of the DevOps course

Engineering 89 directory

Hi! In order to make finding my repo's easier, I've created this directory, making it the place to go to find my lesson files as well as my completed tasks!

Enjoy!

Lessons

Tasks

View on GitHub

Week 3 - Python

This week was more on extending the use of Python with packages, APIs and Test Driven Development (TDD).

Packages I love, I think they're a great idea and even in small projects it really has helped my brain digest what's going on in a program a little better, but of course, I'd like to wait to see how they work in large projects before I get too excited over them!

APIs, well, it goes without saying. The ability to call information on demand is really cool and useful, I wish that I had the opportunity to use them more widely but low level programming never really opened them up to me in the same way this DevOps course has.

TDD has kind of changed the way I look at programming and I think it's something I wish I'd known earlier. So at it's basic core concept, you're working backwards, you have your outcome and you then need to create the code to get said outcome. I feel that this will have the bi-product of leading me to writing cleaner code since as long as the test passes, how you get there is (mostly) irrelevent.

So an example would be:

def test_add(self):
    self.assertEqual(self.calc.add(3, 2), 5) # if 3 + 2 = 5 is True test would pass

Then all we need to write is:

def add(self, num1, num2):
    return num1 + num2

and the test should pass!

Week 4 - Model View Controller and Plane Project

Week four had us setting out to do our first project: Create a flight management program. Here's the repository where we stored our code:

engineering89-plane-project-group-3 / project

The main project repository!

Bri'ish Airways

Engineering 89: Group 3 - Plane Project

The aim of this project was to, as a team, complete a plane management program using python and a model view controller (MVC). We were given 5 days to complete this task and here is the result!

Technologies used

To help us along the way we have used a few well known technololgies:

Flask

Flask was used as our MVC and helped to create the link between a public facing website and the underlying code. Flask uses HTML templates to generate standard web pages with the relevant content for the user Using flask has a number of benefits including:

Speed: Flask is very quick at generating pages
Compatibility: Since flask is generating simple web pages, no special hardware/software is required to run or view the program
Standards: HTML pages are ubiquitous across the internet so all the standard tools can be…

View on GitHub

This is where we brought it all together. Flask was selected as our go between our user facing side and the python code.

I myself worked primarily on the user accounts side of things, including registration and encryption of sensitive information as well as collaborating with another member of the team (who goes by Ahhhh-man on GitHub) on the flight trip database and the CSS layout of the site.

The project was definitely a success with our instructor being impressed with the results and team mate SBenkhelfaSparta getting a shout out in our weekly company stand-up for their incredible work with flask.

That's not to say that it was entirely plain sailing, not just our group but every group did have problems with Git and it kind of dawned on me just how unfriendly Git is to new-commers. Every single team had problems with merge conflicts, branches not being able to be pulled, etc.

We experienced it when two team members had exchanged files that each other depended on through Discord, they simply replaced the files in their own version of the branch which caused Git to treat them like new files, losing their associations to already existing files. Now this could've been caught had it not been for another innocent decision, one of the team members had decided they wanted to sync their PyCharm environment through Git so it was the same on both their machines, this lead to the creation of 100's of additional files that appeared during the pull request (PR) causing GitHub's PR page to be unusable.

This unfortunately led to us having up to 3 different versions of each file in different folders and it took nearly an hour to decide which versions of each file were the ones we actually wanted to keep. Now, is Git to blame? Maybe. Are we to blame? Maybe. However, I don't think that this is a mistake that is uncommon and it is very much a flaw of Git to allow such a thing to happen. We absolutely should've as a team cracked down on branch merging, but it's a long winded process and sharing the files between people is soooo much easier.

Edit: I feel like maybe I was too harsh on Git here when I didn't mean to be. I still like the tool however, this was written at the time and I was a little bit frustrated:

Aaron Sua • Jul 14

Git can be rough for new comers to understand for sure, but I wouldn't blame the tool for what happened. Misunderstanding and misuse is all that happened. Digging into how the binary tree of git and calculation of differences operates will help a great deal.

It's relatively easy for us humans to look at a file and say: "Both of these lines are the same, why is there a conflict?", but when you consider what git is tracking it makes sense. It isn't just what the content of a file is, but the history, parentage, and attribution of that change. So git sees that the same line in a fire was edited by two users at different times with different parentage. That causes a conflict. Even without making the mistake of passing files outside of git, you can hit similar issues by using squash and rebase to change the history in git.

Having a deep understanding of git is very fundamental in DevOps IMHO. There's a lot of creative git use needed in CICD.

But this has definitely been a learning experience and next time we do a group project I am going to make sure that we all double down on securing our file names, .gitignore and merging techniques right at the start to hopefully prevent us from making the same mistake again. Git is a fantastic tool, but it can be a cruel one for sure.

Closing thoughts

The first month has been great, I feel like Python and DevOps is a good fit for me. There's still a long way to go, but I'm positive that this is the right path for me to be on!

Plus it's just dawned on me, I don't actually use Windows in my workflow at all anymore. I don't necessarily have a problem with using Windows over any other operating system (in fact I am using it right now to write this while my games update on Steam), but I had been reliant on it to a certain degree up to this point (some engineering software is still Windows only) but now I am using macOS and Ubuntu exclusively now which is just wild to me.

But, that's all for now, this series will be back in 4 weeks time, I may do some smaller blogs between now and then but we'll see!

You may also have noticed that this post is on other sites too. I'm still trying to figure out which is best for me, but that's a post for another day!

All the best!