Forem: Cameron Lepper

Why You Should Get Azure Certified by May 1st

Cameron Lepper — Tue, 09 Apr 2019 15:55:32 +0000

Why Microsoft's deprecation of AZ-100 and AZ-101 poses an exciting opportunity to become Associate Certified in Azure

On May 1st, Microsoft will be deprecating the AZ-100 (Infrastructure and Deployment) and AZ-101 (Integration and Security) certifications for Azure. Currently, to become an Associate Certified Azure Engineer, one must have sat and passed both of these exams.

The deprecation of these certifications is to allow for a new combined certification; AZ-103. This new exam will loosely match the AZ-100, but will incorporate some elements from the outgoing AZ-101. As of May 1st, to become Associate Certified, one is only required to sit and pass AZ-103.

Why is this good news?

Well, if you have the time to study and sit the AZ-100 exam before the 1st May, then you will automatically receive the new AZ-103 when it becomes active. This means that by sitting the current AZ-100, you will automatically be fully associated certified from May onwards.

Conversely, if you sit only the AZ-101 before 1st May, then you will merely receive an AZ-101 badge, nothing more...

With the current growth in Azure, now is as good a time as any to be taking some time to learn about the second largest Cloud Platform by market share.

I have my exam booked for Thursday. :-)

Cameron

cover image: corenttech

In CRISP-DM We Trust

Cameron Lepper — Mon, 11 Mar 2019 15:58:12 +0000

I started out in my tech career developing BI (and occasionally AI) applications, before moving more into Cloud Software Development. The early involvement in Data Science tasks was really useful, but one thing sticks with me particularly:

CRISP-DM

CRISP-DM is an acronym which stands for 'Cross-Industry Standard Process for Data Mining'. This post will explain what CRISP-DM represents, and why it's one of the most valuable things I was taught during my short dabble with Data Science.

I'll prefix this post by stating that this is intended for beginners, or those who (like me) had not come across this term.

Definition

The Cross-Industry Standard Process for Data Mining (CRISP-DM) defines a partially-iterative methodology, comprising six fundamental components which contribute towards a streamlined standard process for performing data-related tasks.

Image: Forbes

I genuinely think that the process is mostly common sense, but having it defined and labelled as a standard is demonstrably useful.

Business Understanding

When planning any task involving operations on data, it is important to understand the business or context to which the data belongs. This not only helps ensure alignment with the overall motivation for the task, but also helps in terms of understanding the best way to approach the problem.

Data Understanding

This should be fairly evident, but having understood the wider context of the business OK, analysing and understanding what the data (should) represent is critical. Without knowing the data, it's pretty impossible to process it properly, and it will become a painful battle to suss something out. Trying to understand the data may prompt you to return to gather further business understanding.

Data Preparation

Sigh... You've got all your data, and you understand its purpose and wider context. Now you have to go through and put it into a format that you can do something with. Data Cleansing! Removing duplicates, nulls, and all other usual fairly mundane, but equally crucial, clean-up tasks.

Image: PlanSpace

Data Modelling

Phew - The cleansing is over. Now time to do some fun stuff; Modelling! This may be the cool part where you do your fancy AI, or design your complex dashboard with the appropriate visuals. Really, this is where the fun happens - however, I'll add the disclaimer that you're likely to find a few data anomalies here that require you to painfully revist the Data Prep stage.

Evaluation

Now that we have modelled our data, and we're looking at the results of whatever cool thing we've done, we can started to assess whether what we're seeing on front of us is actually what we wanted to do, or of any use. If it's not, it's best to invoke another iteration of the full process again, starting from capturing more understanding of the business context.

Deployment

Once we've evaluated our results, and concluded that 'this is it chief', we can finally make it available. Publish away to whatever platform you use, and people can start to access it.

*This whole process is obviously dynamic and continuous, as live data will need cleansed and remodelled regularly, depending on the task and data usage.

Why am I telling you all this?

Unlike Software Development, which has numerous methodologies that have changed quite dramatically over the years (Waterfall, Agile, DevOps), the CRISP-DM methodology has stuck around, standing the test of time.

A lot of what I do as a developer, building and deploying applications in the cloud, relies on a significant amount of work handling data. I've adhered to the principles above since discovering CRISP-DM, and found that it has been absolutely vital to quickly, effectively and correctly perform the relevant data tasks I need on the data.

I realise I'm still fairly early on in my career in tech, so perhaps this might explain why I hadn't yet come across CRISP-DM, but for those who hadn't previously discovered it, I do hope that this offers a nice structured approach for the next time you need to do some cool data stuff!

Vulnerability Identified in Docker & RunC

Cameron Lepper — Mon, 04 Mar 2019 12:01:43 +0000

Docker Vulnerability Reported

On Saturday, RedHat posted a new entry in the Common Vulnerabilities and Exposures Database, with the impact level important. The vulnerability could enable a malicious container to be executed, eventually resulting in easy access to the host filesystem.

It defines the weakness as:

"A flaw was found in the way runc handled system file descriptors when running containers. A malicious container could use this flaw to overwrite contents of the runc binary and consequently run arbitrary commands on the container host system."

The full details can be found here.

The recommendation is to patch RunC ASAP, if you haven't already.

This was shared to me this morning, and came as a bit of a surprise. Does this affect you, or your organisation?

Edit: It has been pointed out to me that the initial publication of this CVE was in February! Thanks @ohffs for that. Hope this blog still stands as a useful resource, and a reminder of the importance of keeping patches up-to-date!

A Whirlwind Year (or so) in the Field

Cameron Lepper — Wed, 13 Feb 2019 00:19:50 +0000

I've been actively reading Dev.To, both on Twitter and on the site, for some time now, but this will be my first post. So with that in mind, please be gentle!

I thought it would be interesting to share my story, as I've seen others do, with a reflection on my first year (or actually, first 13 months) in the computing industry. Hopefully for those getting started in our wonderful field, this can be - at the very least - an interesting read.

For some background on me, I studied an undergraduate Bachelors Honours Degree in Computing Science, and then a postgraduate Masters in Computing for Business. During my undergraduate, I completed a ten week internship at mid-sized IT firm, where I did some software development. I'm not discussing any of this here, but rather just focusing on my first full year in full-time employment.

The Beginnings

In January of 2018, I was a fresh-faced graduate in a smart technologies division within an Engineering firm. Originally I was taken on as an Azure BI Developer, but as the first months passed, the BI part was dropped, and I just started developing software within the Azure Cloud. This is when I started to realise that Cloud Computing, particularly the Microsoft Azure Platform, really interested me.

As my interest in Cloud Computing grew, so did the company's need to start transitioning to Azure. This was a mutually beneficial arrangement; the company needed to migrate to Azure, and I wanted to learn how to get stuck in with Azure. I got to be very involved with, and exposed to, a lot of new Azure technologies and ways of working; particularly surrounding the MicroServices approach, container orchestration, and CI/CD (using Azure DevOps/VSTS). As my knowledge in this field grew, so did my confidence. In December last year, a new team within our division was created, aimed primarily at Azure Development. They asked me to make the horizontal move to join them, which I gladly agreed to.

Since joining this team, my responsibilities have grown day-on-day, and I've been heavily involved in a lot of R&D, innovation and trying to implement Azure efficiently. That is the position that I was in until Monday this week...

The Offer

A few weeks ago, I was approached by a recruiter for a company, who are pretty well known in the field, asking if I was interested in a quick chat explaining an available role to see if it would be a fit for myself. I explained that I was happy in my current position and that gaining experience was important to me, so there would have to be a compelling reason to move. However, a quick phone-call with the recruiter illustrated to me that there was, indeed, a number of compelling reasons to move.

The role being offered was a DevOps Engineer role, which would start focused on Azure, but slowly incorporate GCP and AWS (as they are partnered with the big three). I had a total of 5 interviews over 3 days:

An initial phone-call experience interview
An hour long video call, exploring some technical examples and discussing background more in depth
A half day, over around 3 or so hours, with a technical whiteboarding interview, a background and experience interview, and a cultural fit interview.

The interview process was good fun, and to my astonishment, I felt that I had nailed the technical assessment. I received a job offer this week, to start my new role as a DevOps Engineer mid-March. I could not be any happier. It's an exciting new opportunity for me to progress my career in an environment surrounded by experts in the cloud. Learning opportunities are going to be in abundance. I can't wait to get started.

The Surprise

I suffer from something I like to call 'Junior-itis', by which I mean that I often have little confidence in my own abilities, usually as I feel that I am inexperienced. It took until I received my feedback for the DevOps Engineer technical interview for me to actually realise that I seem to, unfathomably, actually have some idea what I'm doing. It's incredible that one year has flown by, and I've gone from being a complete rookie to having, at least, the knowledge to hold my own in a technical interview in a very specific field.

I say this because, as someone who has read these sorts of blogs on here for some time now, this sort of post is the kind of reassurance that I would have liked starting out my tech career. I still feel very 'junior' (and, of course, I am) - but knowledge comes from experience and application, and one year teaches you a lot of things. I'm excited to keep learning and growing, but I'm really starting to reflect on just how much I've grown in the last year.

The Extras

Side Projects

On top of my work experience, I also have had half a year of volunteer experience as part of the Founders4Schools initiative, where I am able to go into schools and run workshops to inspire the next generation of minds to get involved with STEM subjects. This has not only been rewarding, but it's been beneficial - my communication and confidence with people has grown greatly as a direct result of such presentations.

Tips and Tricks

One of the best things I've done is create a Slack page for my friends that I graduated University with. When we have coding issues, or general questions about something, we tag each other in and open discussions. It's been great learning from people outwith the bubble of my own organisation, and pulling from resources across the country has really helped me remain open minded about solutions.

Conclusions

These are anecdotal, so don't take them as the gospel, but this is what I would say:

If you're just starting out, the biggest thing I can suggest is to really apply yourself to the role, and try to learn as much as you can as you go along. There's no way to know everything. If you have a supportive team, you'll grow so much in your first year.
Find a way to get involved with presenting ideas. This was such a good way for me to grow my confidence when dealing with people in a business context.
You may find, early on, that your initial fields of interest change. This is OK.
One day you'll wake up and realise have a moment where you go 'oh my god, I seem to actually have a clue about this field. How did this happen?'. Enjoy that moment.
Make the most of learning and being involved with R&D where you can. If you don't have the opportunities at work, try to dedicate at least a couple of hours per week of playing around with the tech that interests you on an evening/weekend.

My first year in tech has seen me fall in love with software development in a way I never have before, discover and fall in love with cloud computing and DevOps methodologies, and gain valuable experience that has helped my technical abilities and helped me grow as a character too.

I'm so incredibly happy to be a part of this industry, and now - officially - an active member of the Dev.To community.

Thanks for taking the time to read my first ever blog-post. Take it easy.

Cameron.