Career Mentors (Bye Jay)

Today my manager Jay is leaving. It was a massive shock when I found out. As he’s the CTO I had two thoughts:

  1. “Oh no, I’m sad now”
  2. “Is the company in trouble?”

So in fact, he’s making the decision to go purely because he wants a new challenge which is completely understandable and I wish him the best of luck.

He has been the best manager I have had so far because he’s been supportive, encouraging, and an ear when I need to moan (which can happen often as I am very picky particular dedicated to delivering a great product). He also doesn’t just tell me things I want to hear (which is pretty rare in people). I get honest answers and opinions.

Being a woman in tech, I didn’t have many people to look up to in order to steer me in the right direction, getting me to where I am now. I have done it all by myself (which makes me proud now that I think about it) but it’s been exhausting.

I haven’t had someone else to give me their wisdom which would’ve undoubtedly meant that I probably would’ve made less mistakes along the way. But from the beginning Jay has given advice, let me feel like I can research everything that will help improve the team and the area that I work in for the company, has given me autonomy, let me attend the events that I want (through which I have met some great people), sends me Twitter links to awesome women in tech (like @TheAmyCode) for further encouragement, and in general has made me feel more confident about being in this role and that I deserve this role because I am awesome.

Find A Career Mentor

It’s important to find people like this to guide you through your career because no matter whether you’re male or female, careers are hard and a little guidance goes a long long way.

If you do find these people, make sure that it’s not just a one-sided relationship. Make sure that there’s something that you can give them too. Whether it’s small things like being self-sufficient so that they don’t need to worry about you or giving back something tangible that could help make their lives easier or better.

So, bye Jay. See you soon, it’s been great working with you and remember BBQ!

 

Moving to Containers

It seems that containers are the new technology within IT that everyone is trying to incorporate into their infrastructure. And why? Containers not only benefit those in DevOps, but have positive implications for all teams involved in product delivery.

At Immerse, we’ve recently moved our infrastructure to a containerised solution. It’s early days to analyse the impact that this has had on our development teams, but I thought it would be a good opportunity to deepen my understanding of the this technology.

What Are Containers?

Containers give us the ability to store a number of different systems virtually within the same location. This means that if one environment needs a website front-end, server and database in order to function, all of these can be stored within the same place.

What sort of systems can be run within containers? Well, that’s where container images come in.

What Are Images?

A container image is a stand-alone, executable package of a software that has everything needed to run it including code, runtime, system tools, system libraries, and settings.

An image is required in order to build a container, otherwise it will be empty when created.

So where did all this new tech come from then? It seems like it’s come out of nowhere but spread fast (kinda like Bitcoin right?). Well, it all started by a small company now called Docker Inc. They created the system that containers run on, Docker.

What is Docker?

Docker is a computer program that allows you to perform operating-system-level virtualization known as containerization. This is the creation of containers.

Docker allows independent containers to run within a single Linux instance. This reduces the overhead of starting and maintaining virtual machines (VMs).

Since Docker began, there are other tools than have been developed that can perform containerization.

The World Before Containers

Before we used containers, there were virtual machines (VMs). VMs remove the need for physical hardware and allows one server to be turned into multiple servers. App of this is possible because of a hypervisor.

A hypervisor (also considered a VM monitor), is software that creates and runs VMs. It is the reason why you can run many VMs on a single machine. Each VM will have a full copy of the required operating system, one or more applications and the needed binaries and libraries. All of this can take up tens of gigabytes of space!

Some companies have made the switch to containers from VMs because:

  1. VMs can also be slow to boot, while you can spin up a container within a few minutes providing you have the right image. And if the don’t, that usually only takes a few minutes to obtain.
  2. You can pack a lot more of your companies applications into a single physical server using containers than a what you can fit in a VM.
  3. VMs take up a lot of system resources as they not only just run a full copy of an operating system, but a virtual copy of all the hardware that the operating system needs to run. All that a container needs is enough of an operating system, supporting programs and libraries, and system resources to run a specific program.
  4. With containers you can create a portable, consistent operating environment for development, testing, and deployment.

So How Do You Manage Containers?

Container Orchestration are frameworks that are used to integrate and manage containers. These are not necessary for everyone using containers. Usually enterprise level organisations are more likely to use orchestration tools as they manage a large range of containers and their images. Examples of these tools are Kubernetes, ECS and Ansible.

These tools help to simplify container management from the initial deployment to managing multiple containers, scaling for load, availability, or networking.

The Benefits and Drawbacks

Like any new piece of technology or tool, containers too have their own list of benefits and drawbacks that mean you choose to either integrate them into your development pipeline or you don’t. So, what do containers offer?

Benefits

  • The ability to spin up whole environments consisting of all the systems you need within minutes.
  • The ability to change the configuration and deploy those changes quickly.
  • Containers allow all users of the system to be self contained. This mean that rogue developers who develop new features, don’t run tests locally, push to the test environment, then leave to go home only for QA to find that test is broken is no longer a daily issue (wow, that sounded like a rant!).
  • Features can be tested in isolation easily.
  • Testers can be in control of checking out and pushing features to the test environment.
  • Differences between environments is no longer an issue because they’re all spun up from the same set of stable images

Drawbacks

  • Initially, there maybe some complexity to setting up containers.
  • There are some security issues that you med to be aware of when using containers. For example, if a user or application has superuser privileges within the container, the underlying operating system could, in theory, be cracked.
  • It’s time intensive to set up decent security measures for containers. There’s no default, out if the box solution yet
  • Everyone is making container images and it could be easy to download something malicious into your system.
  • Breaking deployments into more functional discrete parts is smart, but that means we have more parts to manage. There’s an inflection point between separation of concerns and container sprawl!
  • Containers tend to lock you into a particular operating system version

Are containers the future of development?

It seems because of the fast adoption of containers that they may eventually replace VMs once their issues have been overcome. And because it is a new technology, there will be drawbacks at this early stage so don’t let these deter you from experimenting with the tech yourself on your own projects.

However, technology has changed extremely fast over the last 30 years, so it may be that containers are superseded by a new emerging technology that solves the drawbacks of containers and gives us a while load of other benefits too.

For more information of containers especially if you’re learning the basics, please check out the Docker videos by Nigel Poulton on Pluralsight. I found these videos extremely helpful in delivering information and background about a brand new technology. The concepts were also broken down into easy to understand topics which is perfect for beginners. After watching them, I was able to understand a lot more and felt more confident when speaking to the DevOps at Immerse about how they had implemented container and why they made the decisions they did.

What’s your experience with containers? Do you love them? Are they growing on you? Or, have you not yet made the leap into using them? Whatever your experience, I hope this article has given you a better insight into the background of containers.

For more information about containers, please feel free to view the references I used:

This post was imported into WordPress in one click using Wordable.

Rebasing from Master onto your local branch

 

Now that my QA team are adding to the test coverage by writing integration tests directly into the project code base, it’s finally time that I start to embrace rebasing (I sort of feel that lightning should crack when you read rebasing)!

As I survive with the basics of Git and because Irina and I only usually submit to our own repos, apart from branching and merging back to master, there’s not much activity going on. But once you work on a repo where at least two people are active on it, merging their code into master and creating branches weekly, your local changes can fall behind quite quickly. This is where rebasing comes in.

Rebasing essentially rewinds back your branch to when you created it from master (if that’s where you branched from) and applies all the commits that have happened from master branch to your own. If there are conflicts or differences between the commits to the master branch and yours, you can either:

fix them at each commit, then you

[sourcecode language=”css”]git rebase –continue[/sourcecode]

, or you can accept the changes on the other branch and

[sourcecode language=”css”]git rebase –skip[/sourcecode]

The concept is quite clear to me (now), but what I struggled with was doing this all on the commandline. I know I could use a tool like Source Tree to do all the heavy lifting for me, but in fact, despite me being quite a visual person, I like using the commandline for Git. So I vowed that this will be the time to learn and to do it more often so that it’s solidified in my brain.

So after being walked through the process, I learned that these are the steps that you need in order to rebase from master on to your own branch.

So these are the steps, pretty simple and after a couple of times, I reckon I’ll be able to do this from memory…providing the conflicts are few and far between!

[sourcecode language=”css”]

git checkout master
git pull
git checkout MyBranchName
git rebase master
git rebase –continue (until you fix the conflicts) or git rebase –skip (to skip these changes)
git pull
git push
git status

[/sourcecode]

The steps here are what I found works, but if you spot anything wrong, don’t be afraid to let me know.

9 Steps To Approach A Development Task

My most recent guest post on Simple Programmer.com was the process that I would go to when tackling a development task. I got the advice from a previous manager and thought it would be good to share with a wide audience. So another blog post for the Simple Programmer community was created – 9 Steps To Approach A Development Task.

https://simpleprogrammer.com/2016/12/16/9-steps-to-approach-development-task/

10 Tips To Start Off Well In A Junior Dev Role

Here’s my next post which appeared first on Simple Programmer..

As I look back on my first full year of working as a developer, I have realised a number of things that are essential to this position.

Daily, a developer needs to think mostly like a developer, but partly like a business analyst to get the reason why the business wants the new feature. You need to think partly like a product owner to understand its value of this in the team’s roadmap, and partly like a tester to defensively code around the ways they will think of breaking your beautiful new feature by anticipating users’ behaviour. That’s before you consider all the tech skills developers need to accomplish fulfilling the tasks these different ways of thinking will bring.

These different ways of thinking and the abundance of skills are things that I didn’t consider when deciding to switch careers into development. Taking all this into consideration, I thought back over my first year and came up with a short list of tips that I think will help anyone entering as a junior developer in any industry. If you implement any of these tips below, I am positive that your first steps into a development career will be a lot less daunting, a lot more productive, and get you off to a great start.

Embrace debugging and improve your debugging skills

You will always need to debug no matter what level you get to. Most of a developer’s job is reading code, figuring out how and why things have been made the way they have, and fixing bugs. But it can take you a longer time than most developers if you’re not as experienced at reading code. And even if you are, trying to navigate archaic code or “smelly”, “unclean” code isn’t a task you enjoy. Because if you’re a good developer with a conscience, you know that you’ll have to fix the issues in the code that you’ve found on top of your original task.

Practice reading code

The best way I’ve found to improve is to read code as often as possible. Just like any language, the more you read and write it, the more you’ll improve.

Always be asking “How does this work?”

Delve deep into how something works the way it does. For extra credit, learn the reasons behind the technical methods that were chosen to fulfill this feature.

Diving deep

Walk through the code and see if you can understand why it works the way it does. To understand what technical techniques were used, speak to any long-standing members of your team that would know why they made those technical decisions. It may be that the methods they used are now outdated and you can suggest newer techniques that will save time, save money, or improve performance and ultimately make your company more money. This is always a big win in your favour.

Understand the value of your task

There’s no point in spending time implementing a new feature if you don’t understand why you’re doing it, how it’ll be used, what value it’ll provide the end user, and its impact on the business itself.

Look at the bigger picture

Make sure you talk this through with your line manager about the larger value of the product you’re working on. It’s their job to ensure you get all the help you need in order to produce the best results.

This is usually discussed before you even start developing. But if you’re unclear, make sure you ask why you’re doing what you’re doing. You could have a new way to approach the task that hasn’t been thought of which would deliver more value.

Find what you enjoy and become an expert

Let’s be honest. During the first year (or maybe longer) of your development career, you’ll feel stupid.

The sheer amount of technology that you’re supposed to be able to use competently will overwhelm you. What will keep you optimistic, even on those dark days where you feel everything is breaking and you’re powerless to stop it, is finding something you enjoy.

When you enjoy something, it doesn’t matter how inexperienced you are in the topic, you’re just learning, so it’s all fun and games. You don’t expect to know everything, but you’ve got the confidence that you’ll get there eventually.

Become the expert in this topic and make sure you share your learnings with the team.

Explore your interests

Keep a log of the different skills that you use daily. Make a short list of the ones that you enjoy, pick one and deep dive into it.

Picking a skill that you use daily means that it’ll continuously be useful to you and your team. Whereas, if you pick a tool that you’ve only used once or twice i.e. a really cool bit of new tech to solve an edge case business problem, it may be fun, but there might not be any long-term use. So although diving deep into a specific skill is a good idea, make sure that you gain a return in the long term for the time you invest.

And picking one means you won’t spread yourself thin. You can focus on building that one skill up so that you are confident using it.

Keep a log of your activities

I think I learned this skill from one of John’s YouTube videos. Keeping a log of your activities helps you to recall what you’ve done and learned in your role. It also gives your manager an insight into your daily activities if you’re not in regular contact.

The format of this log is up to you but remember, this log should not take time away from your actual role.

Create a template that’s quick to fill in but extracts the important information for you or your manager to peruse. I would also advise that you send these logs to your manager on a weekly basis as opposed to daily.

How I do this?

I experimented with completing daily logs then compiling these into a weekly report for my manager. But in the end, this took way too much of my time. So I ended up just completing a weekly log and I email this to my manager every week.

In my template I include:

  • My feelings for the day
  • Weekly goal
  • Daily tasks
  • General daily summary
  • Numbers for work items
  • Anything unexpected
  • Anything I’ve watched, read, or attended that improves the skills I use in my role
  • My next week’s goal
  • Lessons learned

Find out what skill or role your team lacks then throw yourself into it

Every team has their own strengths and weaknesses. Your team is no different.

If you’ve created a shortlist of topics you enjoy or, if you’ve been compiling your list of daily skills in your weekly report, you may want to figure out what skill your team is weakest on.

How to do this?

After identifying this list, you will be able to see if the skills that you most enjoy cross with a skill that the team needs. If so, great! You can kill two birds with one stone, finding something that you enjoy and provide the team with valuable knowledge in an area.

If not, then pick the skill that you believe will give the team the most value.

Try and pick a resource or medium that you learn from easily so that the information can be absorbed quickly.

Keep a log of anything you do above and beyond your job in a ready to view format

In every permanent, big company role that I’ve had, there is always a process in place to review performance of employees.

But, when you’re sitting in front of your desk looking at a document asking you what you did six months ago to contribute to the organisation, it’s not surprising if your mind goes blank.

Everyone finds recalling information like this challenging. Sometimes people can’t remember what they did the day before, let alone six months ago!

Compile your list in a single file

I’ve tried a few different ways of keeping track of my extra activities. I first tried keeping a list with pen and paper noting down the task I did and the date. I found that at this stage, you don’t need to mention what the outcome was, as you’re just noting it down so you don’t forget all of your examples.

But, this list suddenly became quite long and random bits of paper tend to get lost or deteriorate over time. I needed a more durable and easy to edit solution. Enter Excel.

My second solution was to use Excel and use it in the same war as the pen and paper. But I found that maintaining the dates and accounting for ongoing tasks wasn’t so simple in this format. So, I searched the internet and found this free timeline software. It’s really simple to use, and exports to PDF.

I’m still using this piece of software now (although I’d love a Mac version).

So, what should you track?

Note down everything you do inside and outside of work that either directly contributes to your role or strengthens any other skills you’re interested in.

If you’re working with a backlog, you may find setting this up is a bit tedious, but have patience. Once it’s done, it’s done and very simple to update.

As a junior, you may feel that you’re constantly learning and never gaining knowledge. But this will paint you a very different picture. After six months, looking back on your timeline will make you feel really awesome. Your confidence in your abilities will soar because the timeline clearly shows you exactly what you have achieved.

Make time to train yourself everyday

It’s important that you keep up your skills in a software development role, because the technology in this field is ever-changing. So don’t wait to be offered training by your manager –– seek it it out yourself.

Finding time even on busy days

Carving out time to learn will be another challenge. It takes a lot of discipline to stick to a training session every day. You need to make sure that you don’t take on too much day-to-day work so that you’ll have to skip a session. The danger of this is that once you skip one session, you’ll be more likely to skip another.

To combat this, schedule this time into your calendar and set yourself as busy. This will deter anyone from contacting you during this time, remind you that your session daily will be commencing soon so you can prepare, and get you into the routine of training yourself regularly.

What do you train on if you don’t have a focus?

If you don’t know where you should start, you can either focus on:

  • skills that your team needs, or
  • improving your weaknesses

There are many resources online that you can use to train yourself. These range from free, online courses to paid and subscription courses like Pluralsight, Udemy, and Coursera.

Like everything you want to improve, you should do this everyday. Even if you do one coding challenge, read one page of a chapter of a book, or watch one video that will improve the way you work, it all adds up in the end.

Share your challenges and how you came to the solution

This is invaluable to show how you learn and solve problems. Try and share solutions with others in the same position as you, with the same problem. Sometimes learning from someone at the same level as you is far easier than learning from a senior.

How do you do this?

Try and keep this in an easy to search format, so if you find the problem you solved months ago reoccurs, you’ll be able to save time searching Google for the solution.

Blogs are the easiest way to store this information (and one of the things John recommends every programmer has), because they are easily accessible by everyone.

Make sure your posts are properly tagged and are SEO optimised. Doing this in a public medium does mean you’re more vulnerable to negative feedback but it also publicly builds up your authority and shows your growth to the community. So ignore the haters and keep blogging.

Find a mentor

Everyone knows that you learn best from making mistakes, but it can be more beneficial sometimes to bypass your mistakes altogether.

If someone else has already spent time making the same mistakes, has learned the lessons, and is willing to share their findings, wouldn’t you want to skip the mistakes and go straight to the lessons learned? This is exactly how a mentor can help you.

Among other important things like guiding you in your career, you can use mentors by listening to their experiences and what they’ve learned.

How you should do this?

A mentor can be someone within your team or outside of it. To be honest, they don’t need to be within the same field you work in. They just need to have gained the skills that you want to acquire or level you want to reach.

In some companies, pairing juniors with someone more experienced is a structured programme, so take advantage of this if you think you’ll benefit.

However, for many, finding a mentor can be tough.

Being a mentor can require a lot of time to deliver the best value you can to your mentee and sadly, some people just haven’t got the time. So if you are one of the lucky few who get a mentor, make sure you’re clear on what each of you expect, the time you can both put in, when you’ll meet, how often and what you’ll discuss in each session to ensure neither of you waste your time.

If there’s nothing formal set up in your company, ask your manager if they can arrange something. If you’re not able to find anyone within your company, there are a few sites that match mentors with mentees, like Mentorsme.

If you do manage to find a mentor, don’t accept someone without first asking them about themselves, their skills, experience and their time restrictions. Also keep in mind that your mentor should be someone you get on with as you’ll be spending your precious extra time with them.

So there you have it

I feel that recording your progress, sharing your newly found knowledge, knowing where you’re going, and getting the guidance by more experienced minds is crucial to starting off well as a developer.

Being able to reflect over your accomplishments throughout your early days as a developer is crucial in building your confidence. It may also give you an indication of which path to specialise in. But, you can’t do that without keeping logs and recording your progress. Recognise that at the very least this task will help you identify your own achievements and be a physical reminder that you have grown in your field.

I’d love to know what you think. Which steps do you think are more important? Have I missed something that you’ve found was integral to your progression and growth? If so, feel free to leave a comment or message me so we can discuss our junior developer challenges and hopefully overcome them together.

Xamarin Dev Day London October 2016

The Xamarin Dev Day was held at Microsoft’s building near Paddington.  It was a modern building, very bright and filled with light.

 

What Was Covered on this Xamarin Dev Day

Short presentations were made to start the day off.  The presentations given were:

  • Intro to Xamarin
  • Cross platform Xamarin
  • Cloud Xamarin (Azure)

The Hands on Lab session began after lunch where we worked through setting up a Xamarin Forms app and connecting it to an Azure mobile backend.

What Did I Learn

20161008_102733I learned more about Xamarin Forms and that Azure should be an option when I’m developing mobile apps, especially using Xamarin, as you can connect with it by following a step by step guide. And the Xamarin team have made a GitHub repository of example code to help just in case I forget.

Using Azure, I was able to spin up a mobile backend in minutes. And although you have to pay for the use, you only pay for what you use.

I need to look into how compatible Azure is with Unity, but it seems like a good option for a backend solution.

The best thing I think was learning about Azure. The downside of the day? Building my project seemed to take between five to ten mins at times, and that was before it got to the iOS emulator. Not sure if this was just an issue for iOS and not Android.  Unfortunately, I was behind on the latest version of Android and couldn’t build an Android project.

Action Points

Before going to another one of these Dev Days, I need to:

  • Make sure I update Mac OS
  • Get the lastest version of Xcode to get latest iOS SDK
  • Update Android Studio to get the latest Android SDKs

 

Web APIs and HTTP Clients

Yesterday I was asked by one of the senior developers whether a project was a HTTP client or an API etc as that would affect whether I downgraded a DLL. I couldn’t give them an answer. I had a rough idea of what each were when I was working on creating a new web service months ago. Now that I’ve moved onto other things (and had Christmas and New years) my rough idea has dissolved fast. So, I decided to not only learn the difference between these things but how they relate to each other and write an idiot proof definition. If I forgot again in the future I’d have this to refer to and refresh myself quickly. So here’s what I’ve come up with, if you feel that this is incorrect or could use a little tweaking please let leave a comment.

Web APIs are programming interfaces that consist of one or more endpoints. Endpoints are locations (urls) that contain information in the form of JSON or XML. These are static.

Http clients interact with (server-side) web APIs using the request and response message system. Http clients get requests and responses in the form of JSON or XML from web APIs.

Restful web APIs conform to the constraints of Rest. They mostly communicate over http protocols i.e. Http and https using the standard methods e.g get, post, delete that webpages use.

<!–January 7, 2016–>