DEV Community: Travis Woodward

I made a Voice-Activated Pokédex on Google Assistant called PokéPartner! Here's how.

Travis Woodward — Wed, 29 Jan 2020 05:10:41 +0000

"Hey Google, Talk to Poké Partner"

It goes without saying that I'm a huge Pokémon fan. Ever since the original series came to the US and I watched Ash and Pikachu try to conquer Kanto, or when I put countless hours into Pokémon Blue and every Pokemon game since then... I've been hooked. Now my own daughter is watching the new series and has been playing Let's Go Eevee, and still throughout this entire time for more than 20 years I've wanted a talking Pokedex. Well, I got fed-up with waiting, so I made my own. In this article I will walk through my idea and execution of PokéPartner, the Google Home/ Assistant application that you can talk to about Pokémon.

Resources:

Website

Sourcecode

What is PokéPartner?

PokePartner is a Google Assistant application that you can talk to in order to quickly get answers about Pokemon. I built it to solve a problem that I was having in my own household. During a battle with a Pokemon, I wanted to be able to ask my Google Home "What's strong against Grass/ Fire type Pokemon" and get an answer right away, without grabbing my phone and looking at a type chart. Initially, that was it, I just wanted to know what Pokemon were strong or weak to other Pokemon.

Designing the Application

So I had no idea how to build an application for Google Assistant. After a bit of digging around I came across Dialogflow, a user-friendly, intuitive, natural language processing tool, owned by Google. This took a lot of the mystery out of the application as it handled communication directly between the user and Google Assistant. I started to roughly design a diagram to figure out how I was going to process the data and return it to the user.

Simple architecture for PokePartner application.

There was no way that I was going to manually add all the data I needed for an application of this caliber, I needed an API that was pre-existing and established. Luckily, PokeAPI already existed. PokeAPI provides all the Pokémon data you'll ever need in one place, easily accessible through a modern RESTful API. Perfect, exactly what I was looking for, and it was free! The only issue I had now was providing the data back to my users in a meaningful way. This means I had to actually build my own application to consume the data from PokeAPI and then return it back to my users that are using Dialogflow through Google Assistant.

Building The Backend

I ended up building a private Web API using C# and .NET Core 3.0. I built the directories into "Feature Folders" rather than Model-View-Controller (MVC) as I find the format to be cleaner, especially when you're not using traditional views. By creating feature folders, you essentially take all related files and stuff them into an easy to access directory. For larger applications, this makes a lot of sense instead of having everything scattered.

Feature Folder idea for PokePartner.Api project.

The application would be broken into three primary directories. Pokemon, Types and Services. Even though there is a Pokemon folder, there is only a model inside and that is due to right now PokePartner only supporting questions about Pokemon Types. However, the PokemonModel.cs file allows users to get PokemonTypes by their Names, which is a nice feature that I added after building the application.

The biggest problem I wanted to solve was knowing what type of Pokemon to use against any single or dual type opponent Pokemon. For this I created a TypesController and built a few different API endpoints. The controller can answer questions about Pokemon on Offense of Defense, for Single or Dual type Pokemon. It can also answer questions about Pokemon types, based on the Pokemon name alone. Here's an example:

[HttpGet("defense/{type1}/{type2}")]
        public async Task<IActionResult> DualTypeChartAsDefender(string type1, string type2)
        {
            var types = new List<string>();
            types.Add(type1);
            types.Add(type2);

            var noEffect = new List<string>();
            var notVeryEffectiveRaw = new List<string>();
            var superEffectiveRaw = new List<string>();

            foreach (var t in types)
            {
                var apiType = await _pokeApi.RequestData($"type/{t}");
                var resultsType = JsonConvert.DeserializeObject<TypesModel>(apiType);

                foreach (var rt in resultsType.DamageRelations.DoubleDamageFrom)
                {
                    superEffectiveRaw.Add(rt.Name);
                }

                foreach (var rt in resultsType.DamageRelations.HalfDamageFrom)
                {
                    notVeryEffectiveRaw.Add(rt.Name);
                }

                foreach (var rt in resultsType.DamageRelations.NoDamageFrom)
                {
                    noEffect.Add(rt.Name);
                }
            }

            var json = TypesCalculator.CalculateDamage(superEffectiveRaw, notVeryEffectiveRaw, noEffect);
            return Ok(json);

        }

Each result on the controller will return if the Pokemon Type in question will be superEffective, notVeryEffective or have noEffect. Then we send the raw data to the TypesCalculator.cs file to handle the more detailed results. This was put into its own class and method so that it could be reused efficiently and it can return if the type matchup is superEffectiveX4, superEffectiveX2, notVeryEffectiveHalf, notVeryEffectiveQuarter, or NoEffect. Ultimately this is what gets returned back to the Google Assistant and to the user.

In order to smoothly use the data from PokeAPI, I built Models for the data I was interested in and a Service to handle all the communication between my server and PokeAPI. Due to the complex nature of Pokemon data, I decided to use a model that would work well with the nestled JSON format. I came up with the following:

public class TypesModel
    {
        [JsonProperty("damage_relations")]
        public DamageResult DamageRelations { get; set; }
    }

    public class DamageResult
    {
        [JsonProperty("double_damage_from")]
        public List<DamageData> DoubleDamageFrom { get; set; }

        [JsonProperty("double_damage_to")]
        public List<DamageData> DoubleDamageTo { get; set; }

        [JsonProperty("half_damage_from")]
        public List<DamageData> HalfDamageFrom { get; set; }

        [JsonProperty("half_damage_to")]
        public List<DamageData> HalfDamageTo { get; set; }

        [JsonProperty("no_damage_from")]
        public List<DamageData> NoDamageFrom { get; set; }

        [JsonProperty("no_damage_to")]
        public List<DamageData> NoDamageTo { get; set; }
    }

    public class DamageData
    {
        [JsonProperty("name")]
        public string Name { get; set; }
    }

And for communication with PokeAPI, my service ended up being extremely simple. I simply created an HttpClient and passed the request to the correct Uri, awaited a response and then returned the raw JSON to whichever method was requesting the data. It really is that simple to get started with RESTful APIs.

public async Task<string> RequestData(string endpoint) 
        {
            using (var client = new HttpClient())
            {
                var url = new Uri($"https://pokeapi.co/api/v2/{endpoint}");
                var response = await client.GetAsync(url);
                var results = await response.Content.ReadAsStringAsync();
                return results;
            }
        }

That was pretty much all I needed to do on the backend. Now it was time to move on to an area that I was unfamiliar with, Dialogflow.

Building the Interface

So I am not an expert using Dialogflow or Firebase and I probably never will be. I won't be providing a tutorial on how to use Dialogflow, or an in-depth guide on how to setup Firebase for Dialogflow. However, here is a more detailed guide on Dialogflow that I watched before I got started. This video took the hesitation out of building a Google Assistant application for me. There are two major areas of Dialogflow I need to touch on for this to make sense:

1. Intents: How users interact with your application.

For Intents I need users to be able to ask PokePartner questions like "What's super effective against Fire Type Pokemon?", or "What are Flying and Water type Pokemon weak to?" or "What is Pikachu weak to?". I was going to need at least three different Intents, so I ended up making three Intents: SingleType, DualType, and PokemonWeakness.

It was pretty easy to add these intents. I just needed to add a list of what I thought commonly asked questions would be and then the natural language processing tool built into Dialogflow would handle similar sentences on it's own. The next problem to solve was how do I take a question like "What should I use against bug type pokemon?" and get the right data? Technically you could have Dialogflow return a pre-written answer but can you imagine trying to do that for every scenario? That would be insane! Thankfully, I already wrote backend logic to handle this, by getting raw data from PokeAPI and then putting it into a format that was useful to me. But how did I get that to Dialogflow?

2. Fulfillment: Integrating webhooks into Intents, to provide meaningful results.

By writing simple javascript and using Firebase, you're able to receive POST requests from Dialogflow. You do this by using an Inline Editor on Dialogflow in Google Cloud, which is powered by Cloud Functions for Firebase. Here's a quick example of what a request looks like:

// Single Type 
  function singleTypeHandler(agent){
    const type = agent.parameters.type.toLowerCase();  
    return axios.get(`/type/defense/${type}`)
    .then((result) => {   
      agent.add(`${type} Type Pokémon are weak to ${result.data.superEffective}. So if you want to do the most damage, use one of those types.`); 
      if (result.data.notVeryEffective.length == 0 && result.data.noEffect.length == 0) {
        // If pokemon has notVeryEffect and NoEffect
      } else if (result.data.noEffect.length == 0) {
        // If pokemon has Weakness but no NoEffects
        agent.add(` Do not use ${result.data.notVeryEffective} As those types are not very effective against ${type} Type Pokemon.`);
      } else {
        // If Pokemon has NoEffect only
        agent.add(`By the way, don't use ${result.data.noEffect} because it will have no effect.`);
      }
    }); 
  }

And that's pretty much it. Firebase handles all the complicated pieces. If you know how to write Javascript and RESTful APIs, you're in a great position to build Google Assistant applications.

Releasing the Application:

It was finally time to publish my application. I decided to use a Google Cloud computing engine to publish the private backend API which was using C# and .NET Core. I also ended up publishing a "teaser website" to go along with the Google Assistant application, and I'm using a storage bucket for that, as the website is a simple static landing page.

Screen capture from Google Cloud.

Google makes it easy to publish your application by using their Actions Console. You just need to fill out the formal information and you should have your application either Approved or Denied within a few days. It took my application 3 days initially to get denied. It was denied because the name did not match the pronunciation of the name that I listed. Honestly, that was a good catch and once I fixed it, it was accepted same day.

Action Console by Google.

That should vaguely cover everything. I've listed this project on my Github and the launch website can be found here. Note if you are going to attempt to use the application, just say "Hey Google, Talk to Poké Partner". But it's worth noting, you really need to over pronounce the é (Poke-EE-Partner).

Hope someone finds a use for it! I've personally had a great time using this application while playing through Pokemon Sword and Pokemon Shield. However, it should be noted that at the time of writing this article, PokeAPI has not yet added the latest generation of Pokemon to their API, so you won't be able to use any of their names yet.

I am hoping to add more to this project later, and I am happy to accept any additions to the work on Github! I'd like for it to become a free and easy to use resource for the Pokemon community.

'Pokemon Night' artwork by 魔人王.

The Principles of Object Orientated Programming as explained by Pokémon

Travis Woodward — Sun, 18 Aug 2019 15:22:20 +0000

Why Pokémon? Why not? Many of my peers grew up with Pokémon or now have kids that are watching Pokémon. Also, many beginners struggle to grasp the basics of Object Orientated Programming. My hope is that mixing the four core principles with something so many people have seen will help it click. By making the topic less abstract (which is ironic) and more relatable, it could help someone grasp the basics. What more could we ask for? So let's get started!

Note: If you don't follow Pokémon, this article probably won't make much sense.

What is Object Orientated Programming?

First; Object Orientated Programming (OOP) is a programming language model where Objects communicate with one another in order to solve a problem. Objects are snippets of code that can be reused so that you don't have to always rewrite it. Objects are used in classes and classes are just blue prints for those Objects. By using those blueprints (or classes) you can create instances of those Objects, which are essentially just versions of the original Object, built from the blueprint.

Okay that was a lot in a small paragraph, but it's important that you understand that before proceeding. It's also the only part of this entire article that won't use Pokémon to help you learn, so make sure you grasp these concepts before reading rest. Objects are used in classes. Classes are blueprints. Instances of objects are built from those classes.

Encapsulation

Encapsulation is the process of combining functions and data into a class. Data is not accessed directly but rather through functions within the class. The point of encapsulation is to restrict the access to your Object's components so that users aren't modifying your objects directly.

Think of encapsulation as a Pokéball. Everyone knows how to use it, regardless of how it works on the inside. The Pokemon trainer doesn't have to know why it works, they just need to know how to throw it and play by the rules. In programming, the user doesn't have to know anything other than the interface you provide, and you only want to provide them with access to relevant information. This is called information hiding and it is important.

In order to use Encapsulation properly, you will need to use access modifiers. Different languages use different variations of access modifiers, but in Java they are:

Public: Code from anywhere in the application can access it.

Private: Only code within the same class can access it.

Default: When you don't define an access modifier for your class, you will be using the default access modifier. Code within the same class and package can access the code.

Protected: The protected class has the same access as default with the addition of sub-classes having the ability to access the code.

Inheritance

Inheritance in programming is when one class acquires properties from another class. In Java a class can only be derived from one other class. We call the original class a parent class (or superclass). The derived class is called the child class (or subclass). This is where Pokémon as a comparison really starts to shine. Remember evolution? Remember when Charamader turned into Charmeleon. That's actually a great example of inheritance.

Let's say you have a Charmader (Superclass) and it knows two basic moves. Scratch and Burn. Suddenly your Charmander is strong enough to evolve and it turns into Charmeleon (Subclass). Charmeleon learns a new move called Flamethrower, but it also still has access to Scratch and Burn because it inherited those abilities from Charmander (which was the Superclass). Whoa, that kind of makes sense right?

That is the basic concept of Inheritance in object orientated programming. If you were writing a program you wouldn't want to write the same code over and over again, that's not efficient and it's a nightmare to manage. Instead you would extend your parent class with a new child class, and all of the original properties from the parent class will be extended to the child class. Same results, more efficient, but a lot less work.

Polymorphism

Polymorphism is the ability to take on many forms. In programming polymorphism means to process objects differently based on their data type. In other words, if you have one method, it may have multiple implementations for a certain class action. At the point the application runs (runtime), it will decide what to do.

In Pokémon two characters show this ability prominently, Ditto and Eevee. Let's use Eevee as the example. If you have a parent class called Eevee with multiple child classes (Vaporeon, Leafeon, Jolteon, etc...), and then put Eevee in contact with an evolution stone... The corresponding child class would be called. So if Eevee came into touch with a water stone, the Vaporeon child class would be triggered at runtime and the Vaporeon code would be used opposed to Leafeon, Jolteon, etc...

So how do you use Polymorphism? Well in Java, polymorphism can be either static or dynamic. Method Overloading is static and Method Overriding is dynamic. Overloading is considered static because the method that is invoked is decided at the time of compilation. You use overloading when methods that share the same name behave differently based on the arguments passed to the method. Here's an example in code:

public class Eevee {

    public void sound () {
        System.out.println("Eevee");
    }

    public void sound (int num) {
        for (int n : num) a
        {  
            System.out.println("Eevee");    
        }    
    }
}

Overriding is considered dynamic because it is resolved at runtime. Overriding means that a derived class is implementing a method of its parent class. If that sounds confusing, think about the Eeveelution example we talked about. Here it is in code form:

class Eevee{
    public void sound(){
        System.out.println("Eevee");
    }
}
class Vaporeon extends Eevee{
    public void sound(){
        System.out.println("Vaporeon");
    }
}

public class OverridingTest{
    public static void main(String [] args){
        Eevee eevee = new Vaporeon();
        eevee.Vaporeon();
    }
}

In this example "Vaporeon" would be the output.

Abstraction

Abstraction is the process of showing only relevant data to the users and hiding unnecessary information. A great example in Pokémon is trading with a friend. During this process, surely there is a lot going on behind the scenes. A lot of data is being transferred, files are being updated and objects are definitely being instantiated. However to the users, all you see is your Pokéball being sucked through a machine and disappearing before a new Pokéball lands before you. This is abstraction. That's it. It doesn't need to become anymore complicated than that.

Wrap it up

It goes without saying that this was a simplified explanation of Object Orientated Programming but I hope that this article can help someone who may have been struggling to understand the concepts a little better. As with most things, programming is a skill and it takes a lot of practice to master. If these concepts aren't making complete sense, you should study them deeper because they are the core fundamentals of OOP. Having a strong foundation is the best way to build your skills. I'll leave you all with the obligatory Pikachu GIF. Thanks for reading.

Tips for Writing an ETL Console Application in C# .NET Core

Travis Woodward — Sun, 04 Aug 2019 00:12:50 +0000

First and foremost this is not a guide but an outline of my experience.

I was recently tasked with writing an ETL process at work and it was something that I really enjoyed doing. The goal was to take 20 million or more documents from a Mark Logic database and move them into a Postgresdatabase. Easy enough. However the caveat was that all the data in Mark Logic is in an XML format and the desired data format in Postgres is Json. Still, thanks to Json.NET this isn't too difficult a problem, just a few lines of code. I'll walk through the process that I went with below.

What is ETL?

An ETL process is a process to E xtract T ransform and L oad data from one database to another. Depending on your datasets this could be an easy task or a very time consuming process. In my case, I was lucky enough that our principle engineer already had classes setup in our primary application that I could re-use to easily read the XML data from Mark Logic. A great example of why it's important to write clean, re-useable code.

Planning the Application

During the planning stages of the process I knew that I would be dealing with a lot of data. It might take N hours to load 5 million records, what if the application crashes before it reaches the end? We don't want to load the same 5 million records again. I would need to write a way to keep track of the records that were already inserted. In addition to that, I would need a configurable file that lets us manipulate it's contents after run-time. The file would need to be executable in any environment which presented challenges of it's own. These were my two biggest concerns, the actual extracting, transforming and loading of data was at the back of mind at this point.

Config File

So one of the first things you're going to want to do is create a Config file. There are lots of options when it comes to creating a config, I went with using a json file. Here is a more detailed guide by Gary Woodfine on setting up a Configuration file in .Net Core for console applications. By using a Json file for your configuration, you get to use Name-Value pairs which is a really easy and straightforward way to use your settings.

My appsettings.json file is designed to hold three primary bits of information. First the batch size for the amount of files I want to move at once. There will be more on this in the next section below. Secondly the connection details for the MarkLogic database that I will be connecting to and grabbing data from. Finally, the Postgres database connection information that I will be inserting data into. Your results may vary depending on how complex your console applications becomes. This would be a great place to introduce additional settings.

Extract

The Extraction process should be relatively straight forward. The goal is to grab the data and then break it into chunks that you can control better. For example, if you're writing an ETL process for 100,000,000 rows of data, you likely aren't going to do it all in one go. What if the process fails half way through? How much memory would that take to run the process? More than likely your program would crash for one reason or another. So instead you want to do this in increments.

In my situation, I am grabbing all of the IDs from the original database (roughly 20 million at the time of writing) and then storing those IDs in chunks of 10,000. Then for 10,000 documents at a time I am using their IDs and grabbing the actual documents from MarkLogic. This is a setting in my appsettings.json file and it can be adjusted based on performance or requirements.

Transform

After grabbing the 10,000 documents by their Ids, I needed to transform the data from XML to Json. This is where the Json.NET library comes into play. With just a few simple lines of code Json.NET will translate most things to Json, however based on your needs, your results may very. Note the transform section will be short here, because the Json.NET library handled most of the heavy lifting for me.

Loading

Loading should be pretty similar to extracting in the sense that you're connecting to a database using the information in your config file and then transferring data. In my case I am connecting to Postgres and inserting a single row for each document. This row holds the unique file ID, the Jsonb document, the created and updated dates and finally a transnational ID to help prevent duplicate data being added once the base loading was completed.

Initially I was using INSERT statements for getting the data into Postgres however after some research I found that using insert statements were not the most efficent way to handle this. Postgres supports COPY, which can transfer data between a file or text and a table in binary format. I found that using COPY opposed to INSERT saved me roughly 50% overall time in the loading process, which as you can imagine is more helpful as your dataset grows. I highly recommend researching if COPY is the right choice for you when writing an ETL process.

Testing

Testing is going to be an important step in your process. You don't want to just try to run your application in production, that's not a good place to find out you made an error in your transform logic or load logic. I highly recommend setting up a docker container with Postgres and connecting locally there first. You can set this to be an option in your appsettings.json file and you will be able to easily switch between environments. For setting up a Docker container for Postgres, here's a useful article. Once you've tested your application, you're ready to transfer real data.

Mission Success

At my company this console application is actively being used and it runs daily to continuously move data from one database to another. As always, there is room for optimization however for our needs this simple console application fits the bill pretty well. Thanks to using asynchronous tasks in the console application, I can create an order for which type of documents I want to pull and then run the application and have it do all the heavy lifting for me. The application does what it was created to do and gets us the results we need so I would call it a success.

TL;DR Tips Summarized

Use Existing Code and Libraries when applicable.
Asynchronous programming is likely something you'll want to use here.
Create a Config File, this will help cut down on duplicate code.
If you're dealing with a lot of data, break it into chunks.
Transforming and Loading may be tightly knitted together thanks to libraries that can convert data from one format to another (like XML to Json). This isn't a bad thing.
Explore all your options when trying to optimize your code. For example, when dealing with large chunks of data using Postgres, COPY is a lot faster than INSERT.
Create a Recovery Process. You don't want to get 19,000,000/ 20,000,000 rows of data moved and then have your application crash, only to have to do the first 19,000,000 records again.
Test Locally first, Docker is great for this sort of thing.

5 Things I Wish I Knew Before My First Day of Being A Junior Software Engineer

Travis Woodward — Sun, 28 Apr 2019 15:49:08 +0000

My list of things that I wish I knew before my first day as a Software Engineer.

I've been an Associate Software Engineer for a little over 3 months now and I thought it would be a good time to write a helpful article for other junior engineers who are about to start out at a new job, or maybe for those who are actively applying for their first development position. This list may not be as relevant for you, however for me these were my five big points. Honestly, I wish that my school work covered these areas more. Collaboration is such a huge part of development and I feel like most of what I learned through school was theory and how to program as an individual engineer, not as part of a team.

So without further ado...

1. I wish I had more experience setting up and troubleshooting my work environment

It's day 1, my only responsibility is getting my work environment setup and meeting my peers. Easy... right? Not so fast...

So throughout my university experience and while doing personal projects, I had not setup Visual Studio one time. While I did have experience setting up Netbeans @WGU, Eclipse @CSU and Rider and IntelliJ at home, I had no experience using Visual Studio. This isn't too surprising considering all of the IDEs I've used prior (except for Rider) were to development Java applications and now I am writing C# in .NET Core.

My first day I ran into a handful of errors while trying to compile my code. I was troubleshooting most of the day and while our documentation was really well done, there were areas that were not covered in it, like handling specific errors that I was running into. I really think that a course on setting up an IDE work environment could be a valuable class in college. Apparently, some of my co-workers take their whole first week to setup their work machine, which now I can understand as it takes time to get everything exactly how you want it to be. Finally, a few days later I was able to get everything working smoothly with the help of our principle engineer.

Tip to make it easier: Once you accept a job offer, contact your boss and ask about the IDE and any plugins that the team uses. Take your time to learn the IDE and try downloading some projects from the internet and try getting them setup.

2. Wish I was more familiar with Git and using it with a team

Git... Perhaps one of the most important areas of modern programming. Almost every company is either using git or some version of source control. For me, in school Git was simply not used, at all. There was no course on how to use Git, what it was, or why it was important. Luckily, I had used Git in some of my personal projects so I was not completely lost, but it was only to store projects on Github and not to collaborate.

The problem is that git really shines at collaboration but there are some scary problems that you can run into while trying to merge your branch's code back into the trunk. These problems are especially scary at a junior level when you're afraid to make mistakes. Once you go to merge your code, if you see the build fail, I guarantee as a first time recently employed junior developer your heart will fall right into your stomach. It will be okay. You can fix pretty much any Git problem that you run into and your senior engineers know this.

Tips to make it easier: Practice! Find projects that you are interested in and try to contribute to them, github is probably the best source for this. Take some of Gitlab's courses on Git... They're free. Finally, I have found that if I rebase my branch first before merging, I have a greater success rate because of how rebase works versus merge. Here's a great article on rebase vs merge.

3. Debugging code and using break points

During my first week as a junior developer, I was tasked with writing some Unit Tests for existing code that was confirmed to be working. By the way, writing Unit Tests for existing code is a great way to learn the code base and get familiar with the structure of the application you're working on. During this time, I was very green at using break points and debugging. You can imagine how ill-prepared I felt to write tests, but I did it and I even found my first bug.

In retrospect; I don't recall writing any Unit Tests at all during my time in college. I remember taking some software testing classes, but they were manual testing/ quality assurance classes. These were helpful for sure, but they helped very little with unit testing. While writing my first set of tests, I didn't realize that I could place a break point in the controller I was testing. Writing that now makes me feel a little silly, OF COURSE I can put break points in the controller I am testing but while I was writing the tests, I only thought to put break points in the test class.

Tips to make it easier: Write some unit tests for your personal projects. Test Driven Development is a big deal and a lot of companies use it. Where I am at now, we are not allowed to push out RESTful Web API Controllers/ end points without Unit Tests to go along with them. Also, ask your new team what they use for Unit Tests prior to starting and try to get familiar with it. At my job we use xUnit and I wish I had spent a little time with it prior to starting. It's not particularly difficult, but having that confidence boost in familiarity goes a long way.

4. Learning how to navigate my IDE better

This could technically go with "I wish I had more experience setting up and troubleshooting my work environment" and "debugging code and using break points" but I felt it was important enough to have it's own section.

Imagine this; You're in a 1-on-1 code review with your new supervisor. You bring your laptop into the room and you fumble around the shortcut keys and tabs while trying to run through your code with them. Sure, you're new and it's understandable that you may not be able to explain your code quickly, but fumbling around because you're unfamiliar with your IDE is something that you should be able to workout in a few weeks.

Tips to make it easier: Learn the shortcut keys for your IDE (Visual Studio, VS Code, Intellij, etc...), it will help a ton! On your next home project, code in the IDE your job uses, just to get a bit more familiar with using it. Also if you're company uses extensions or plugins, it's a good idea to get familiar with those as well.

5. It's okay to learn on the job

Okay, this is the most important point. Impostor syndrome is real. It is okay to learn on the job, in-fact it is generally encouraged. There's a line of course; you still need to complete your work and focus on work related tasks, but learning is a continuous part of programming. When I got a job offer at my current job, I was very nervous about learning C# when I had previously only used Java and Python. I did some self-learning at home, but most of my C# coding skills definitely come from learning on the job.

It's important to remember you are trying to land a junior level position. These positions are created with learning in mind. My company pays for a PluralSight and LinkedIn Learning subscription for it's developers so that we can learn new technologies or help junior engineers learn our current stack better. It's okay not to know everything and it's okay to ask questions. My advice is try to solve the problems on your own first, then try Google/ StackOverflow and if you are still stumped, ask one of your senior engineers if they can help you learn how to X.

Tips to make it easier: Learn to go with the flow and take advantage of the resources that are available to you. Become comfortable asking for help but become even more comfortable searching for solutions to your own problems. Again, it's a balance. You need to spend time trying to solve your own problems, that's expected... but it's also known that you are still learning and will need to ask for assistance at times. Also, please don't let impostor syndrome stop you from applying to junior level jobs. Get your resume out there, if you're passionate and know the basics, you can learn everything else!

And that's my list of things that I wish I knew prior to my first day as a software engineer. Hopefully this list helps someone relax and prepare for their first junior software engineer position. Also, your results may vary... All companies are different, but this should be a good starting point for most any company. Good luck on your position as a software engineer!

Please subscribe and follow me on my website for more posts like this: https://iamtravisw.com

Linux Tutorial: Make GIMP more like Photoshop

Travis Woodward — Sun, 31 Mar 2019 02:17:14 +0000

The following instructions are heavily inspired by Bernard 't Hooft over at Udemy. I found instructions from his Windows 7, 8 and 10 course here: https://www.udemy.com/make-gimp-work-as-photoshop. I know that many Linux users love GIMP but may still be missing that 'Photoshop feeling' so I wanted to share how to use his tutorial on a machine running Linux.

Here's what the end result from this tutorial will bring you:

Prerequisites:

You should have flatpak installed, you'll need this to install GIMP 2.10 on Linux.

Run the following commands:

sudo apt-get update

sudo apt-get install flatpak

1. Install GIMP 2.10.X (2.10.6 at the time of writing)

Run the following command:

sudo flatpak install https://flathub.org/repo/appstream/org.gimp.GIMP.flatpakref

Note: At the time of writing this, sudo apt-get install gimp is still returning gimp 2.8 (an older version of GIMP. This tutorial is aimed at 2.10.6)

2. Install Plugins

We are going to be installing the following two plugins along with some other cool stuff:

Resynthesizer (Content Aware Filling)
Layer Via Copy

2a. Download the .zip file from Bernard's course here:

https://www.udemy.com/make-gimp-work-as-photoshop/learn/v4/t/lecture/12014132?start=0\

Note: I think you'll need to enroll to see the files. It's a great course and goes beyond what I teach here. The primary difference is that my tutorial is aimed at Linux users. You want the Udemy file from Section 1: Part 3 'Installing Plugins'.

2b. Make sure GIMP is closed.

2c. Navigate to your GIMP folder. For me, on Crostini it was in the following location:

CD .var/app/org.gimp.GIMP/config/GIMP/

It may be different for you if you are on a different version of Linux or have a more custom install. It's important to point out that if you installed GIMP previously, you will have a GIMP 2.8 folder. This is not the correct folder for your 2.10 plugins. You may need to navigate around a bit to find the right folder. You can use the ls -a command to see your hidden folders.

2d. (Optional but recommended) Make a backup of your current setup.

Run the following command:

cp -R 2.10 2.10-backup

2e. Copy and Paste all the contents from the Udemy folder to your 2.10 folder. You'll need to know your full directory name so open a new terminal window and type ' pwd'. Mine is /home/iamtravisw/ so yours will likely be /home/YOURNAME/. Once you have that, run the following command to copy your contents over to the 2.10 folder:

Run the following command:

cp -a /home/YOURNAME/Udemy/. /home/YOURNAME/.var/app/org.gimp.GIMP/config/GIMP/2.10

3. Open GIMP and Save Preferences.

By now GIMP should look a lot more familiar if you're coming from Photoshop like I did.

3a. You'll want to click the maximize icon to make GIMP full screen then go into the Edit > Preferences menu. Click 'Window Management' then click 'Save Window Positions Now'.

There are many other ways customize GIMP, this is just the tip of the iceberg. I am a novice GIMP user myself, however the Udemy course I mentioned at the start of this tutorial covers A LOT of additional information such as customizing the user interface of GIMP to be even more like Photoshop. I recommend watching what Bernard has to offer as it could be very educational and exactly what you need. Now that you have the skills and knowledge to apply his changes to your Linux version of GIMP you should be able to mimic what he does on Windows, but in Linux.

UPDATE: Bernard 't Hooft has generously offered to let the readers of my blog have access to his new course, The Ultimate GIMP 2.10 Guide. By clicking here you can access the $199 course for free.

Happy editing!

Travis W.

Why I'm leaving my 5+ year Career in Support to become a Developer

Travis Woodward — Sun, 31 Mar 2019 02:11:43 +0000

Picture this, it's 2013 and you just landed your first real "career". You're a software support employee for a great company with great benefits. You are 23 and have had to put college on hold due to some personal and financial reasons, so this job is really important to you. Oh, and your salary is higher than all of your friends. Sounds too good to be true, right? It wasn't.

That was my situation in March 2013 when I started at the Greenbrier Companies. I owe a lot to this company. They pulled me out of a rough situation, they helped me take my chaotic life and make it stable, and rewarded me with great benefits such as paid time off and a big bonus each year. In 2016 they moved me away from Dayton, Ohio into a better, higher paying position in the beautiful state of Colorado. The move was taken care of, it was a very stress free situation.

I went from being the primary software support analyst for software that I really loved and believed in (Track and Trace) to the software support lead for all of the software in the company. This is where my fairy tale story begins to fall apart. A year after my move to Boulder, I was still getting used to my new position. Even today, I am not sure if I ever reached my full potential at Greenbrier. While I believe I was very educated in the track and trace area, supporting the rest of the company really made me burn through my passion quickly. I simply didn't want to be there anymore. I didn't want to work with customers, I didn't want to start the problem solving process to simply hand it over to a developer to finish. I wanted to be the one to fix the problem.

So what did I decide to do? Well, I went back to college. After my first term at CSU-Global I was sure that I wanted to switch careers. I no longer had the desire or passion to work directly with customers or triage 50-100 issues a day. I knew that I wanted to work on my skills and become the best developer that I could be. I really enjoyed being able to build something from nothing and share it with people. To be frank, my favorite part of my job that I enjoyed the most as a support employee once I moved to Boulder was the challenge to solve harder problems. Everything else that came with the Lead Support title was not important to me.

For a long time, I felt really guilty about wanting to move on from my role at Greenbrier. I talked with my manager, who by the way is the best manger I've ever had. A completely reasonable, extremely intelligent person who I will not name for his own privacy. We came up with a plan to move me into a junior developer role at the company, but the catch was I would need to train agents and commit to a 6 month support engineer role first. That time is on top of the time it would take to get corporate to agree to hiring new employees, which for support has traditionally been months. That's a commitment I am not sure I can make, as I felt really miserable each day I came into work. It was starting to look like it would take more than a year to even start as a developer.

At a new company I knew that my focus would be purely on becoming the best developer that I could be, I would not be weighed down by supporting the new support team or covering for a support employee when they are out of the office. My time would be spent purely on development. Knowing that I might be making a parallel move to a new company where my 6 years of tenure at Greenbrier would be lost, I still felt it would be worth it. Even if I don't get a nice bonus each year, or if my paid time off schedule is not as lenient. I know that it's the first step in having a successful career as a software engineer.

So where am I at now? I am still at The Greenbrier Companies working as the only Software Support Analyst. I am also in college again, earning a degree in Computer Software and I really hope that I will be able to land a job as software engineer/ developer soon. I spend all of my spare time learning more about programming and becoming a better software engineer. I know that I have a bright future ahead of me, I'm just working through making my path now.

So why am I leaving a 5+ year career as a support employee to become a developer? I guess I feel that I have outgrown the position and want to move into a role with more opportunity for career growth.