Sunday, 29 April 2018

Tutorial: Set up a Linux VM on Windows using Hyper-V

Today I'm going to walk you through setting up Hyper-V and getting a Linux virtual machine up and running!

I also referenced some potential future videos on Docker/containers, this video is a great summary of what these are if you're not familiar. Past that, we'll definitely be taking a look at Virtual Box at a later time, and maybe WSL.

With this video I am not going to have a full text version, as instructions can be found elsewhere and we cover a few topics, so I'd encourage you to watch and use this as a reference. Some future videos that are more structured in their topic and/or approach will be accompanied by a full text format of the video!

Sunday, 22 April 2018

My Journey in the Tech Industry

In today's video, I chat about my journey in the tech industry, and try to give some insight on "non-traditional" ways of getting into it!

A hot topic these days on in a lot of tech circles is how to get into tech as a career. There are lots of great channels out there with videos about this recently including some of my favourites:
* CLM = Career Limiting Move

In most of these cases, these folks had pretty traditional paths into the industry in that they want to school for computer science/software engineering, whereas my experience has been a little bit different.

I've been into computers since as young as I can remember - at least 3-4 years old - and the first computer I ever had for myself was a Mac IIcx, from there a Performa 6400, and my last Mac (for a long time) was a Power Mac 7500/100 that was CPU swapped for a higher end 604e CPU and an ATI Rage 128 video card.

From there I moved on to Windows, and started dabbling into Linux. To date myself a little bit (not that bad), the Linux distros I started with were Red Hat, Mandrake, and Slackware. 

These days I'm really heavily focused on Hadoop and as a result spend most of my days working in Linux (via MacOS), mostly RHEL/CentOS. The rest of my screen time is split between MacOS (work), and Windows (fun & work).

On to jobs!

First tech job was doing website updates for the school I was going to. Prior to that I'd done "web design", but that was mostly along the lines of Geocities/Angelfire level stuff... bgsound and blink were still valid HTML elements. This project was the first thing that really got me looking at the bigger picture of a career. I thought that I wanted to do web design/freelance design work from there.

Then, Christmas 2001, I got a copy of The Blue Nowhere by Jeffery Deaver. This book is a bit over the top, but it's a very entertaining read that I'd highly recommend if you're interested at all in cybersecurity and social engineering. This book got me started down the the road I'm on now.

My first project after this was in 2003 with the launch of White Rabbit Lane with some friends. This was a collection of cybersecurity tools, white papers, and tutorials/articles that we had written or gathered (and credited) from other sources. This was a very minor project, but we of course were the "cool kids on the block"... at least in our circle, and I still run into people every so often that have at least heard of, or visited, this website despite the fact that I now live almost 3000KM away from where that was founded. Crazy!

In 2005 I landed my first "proper" job as an intern doing IT and network security work at a startup where I'm located now. I spent the whole summer pouring through firewall logs, setting up networks, and configuring IDS/IPS software like Snort.

While in school I ran my own business doing tech support just to learn stuff, and get the occasional free beer. This let me reach out to some other groups on campus, and landed me a job doing network analysis for the organization running the campus network at the school I went to. With this I got to do some basic pen testing, and a lot of traffic analysis to help resolve some issues they were having with DPI and packet shaping that was being done to try to combat piracy... which of course was replaced with people just using IRC and DC++.

Once I was out of school I joined a very large software company doing support for business intelligencebusiness analytics software. While support is usually frowned upon, this is a great way to get into the industry - this position allowed me to get a tremendous amount of experience working with a ton of operating systems and databases, not to mention learning the ins and outs of enterprise software and all of the "fun" that can come with projects to deploy it! I ended up staying there until about 2016 when I moved on to where I am now...

Now I work with a startup (< 100 people) that is heavily focused on security analytics. I won't go into any details around it, but you'll be able to find it easily enough! This job has really changed my view again on how I want my career to progress. Going from a company of 300,000+ to a company this size has really opened my eyes to how fun it can be to work at a small company because everyone is heavily invested in what they're doing and is able to get their hands on everything instead of being pigeon-holed.

At the start of this article I noted that I had a bit of a different path into this industry than may be considered traditional... While I did do some post-secondary education, it started out doing a history degree (which I quickly realized I hated) and I then moved on to doing a 2 year diploma program in Computer Systems where I was able to get a ton of hands on time with hardware, Linux/Windows in a server environment, and networking. Obviously I highly recommend this if you feel that computer science isn't necessarily your thing... it will definitely get you a foot in the door with many companies.

A lot of folks are sometimes afraid to get into a company by doing support since it can seem like it's a dead end, but the great thing with many companies is that you can use this position as a stepping stone into many other roles if you're a high performer. I know many people who started out in support, like I did, and have moved on to consulting, technical writing, project management, software design/development, etc... the possibilities are nearly endless!

Friday, 20 April 2018

Being Self-Reliant

In today's video, I discuss why asking for answers is NOT always the fastest way to solve a problem!

Let's talk about "self-reliance" as it relates to career and learning. The three aspects of this we're going to discuss are:

  • Research
  • Failure
  • Asking for Help


You're sitting at your desk, and you've got a piece of code that isn't working, or some other challenge... it's not even technical! You're stuck and you've run out of ideas, so you need to turn somewhere else for answers.

The first instinct of many people in this situation is to simply ask someone else, but I virtually guarantee that others have already done that, and you can likely find your answer on Google! Obvious, right!?

The problem many people encounter when turning to Google (or any form of research like this) is that they will try to be too specific in what they are looking for, and a lot of the time it will result in little to nothing being found. What you can do, instead, is search for variations of your issue - for example, take parts of an error message or the error code so that you can get a broad understanding of what you could be looking at.

For tech purposes, Stack Overflow is a common resource that people will turn to directly, or which will come up in searches. Very frequently, you'll find an answer to your question on Stack Overflow, but it may not be the answer. By this I mean that the solution you find may work, but it may not be the most efficient way to address the problem. 

The goal of your research should not only be to find an answer, but to learn from the plethora of information you find so that you can determine the best approach forward.


Next up, we're going to about failure.

Isn't this what got us here to start!? Yes, but it's also the best way to learn!

Continuing with the example of some broken code - you've now done some research, found ten or twenty different ways to code around the problem, and now you need to implement those and find out:
  1. Do they work?
  2. Which is the best for your purposes?
  3. What can you change to make it work even better?
It may seem intuitive that you want to test your code before using it in the real world, but this meme exists for a reason:
Image result for test in production

Work in your local (or cloud based) development environment, break things until you find what works best!

Asking for Help

We've done research, and now we've tried, and failed, to solve the problem. On the plus side, we've learned a ton about the situation and some ways to address and avoid similar problems in the future, but are still stuck... it's time to ask for help!

Yes, you could have started out with this, but the reason it's the last step is that the goal here isn't only to solve a problem - it's to learn from solving it. The great part about having done your research, and having tried things, is that you've not only saved yourself time in the future but you're going to save time for the person you're going to be asking as well.

The first questions that you will get almost every time when asking for help are "What's the issue, and what have you tried?".

By having tried many things and researched before involving someone else and using their time, you can answer this with an educated statement around what has not worked, what may have gotten you part of the way toward an answer, and what you think might be the path forward.

Chances are that the person you're asking for help already is going to follow, or already has in their past experience, the exact same steps here. It's due to this experience, that you're now trying to build, that you'll be able to work together to get a quick and good solution.

I know this all seems like it's common sense, but you'd be surprised at how many people skip this process and just jump to asking other people - especially skipping the "Failure" after not finding an exact answer after some preliminary research. At the end of the day, yes, getting your solution was slower than just asking, but think of all of the time that you've now saved yourself in the future, as well as the time that would have been working through these same steps with someone else.