Tag Archives: Technology

How To Create a Glow Effect In Your Unity 2D Project

This process took me entirely too long to actually figure out how to do myself. I even spent a couple of bucks on an solution off the Unity Asset store and still struggled.


I wanted to write this tutorial for anyone else that might want to add glow effects to their projects and to hopefully avoid them having to ride the struggle bus like I did. Take a peek at the end result here:

Play the game right here!

To get started, create a new Unity 2D project. Once created, open the Package Manager under the Window menu item and search for the Universal RP package, install it.

In the Project view, right-click and select “Create >> Rendering >> Universal Render Pipeline >> Pipeline Asset (Forward Renderer)”

This will create 2 objects, name the first object 2D Render Pipeline and delete the object named 2D Render Pipeline_Renderer.


Right-click in the Project view again and select “Create >> Rendering >> Universal Render Pipeline >> Pipeline Asset (Forward Renderer)”

Rename this object to 2D Renderer. You should now have two render objects like this:

Click on the 2D Render Pipeline object and in the Inspector, drag the 2D Renderer object into the Renderer List. Also check the HDR checkbox under Quality.


Now under the Project Settings which can be found under “File >> Build Settings >> Player Settings” select the Graphics tab and set the Scriptable Render Pipeline Settings to the new 2D Render Pipeline object we just created.

Under the Main Camera Inspector you will see some new options, check the box for Post Processing under the Rendering drop down.

If you want, you can change the background of the camera to black to help add to the glow effect.


In the Hierarchy, right-click and create a new 2D Sprite. On the Sprite Renderer of the new object, select the Knob sprite (or provide your own).

Also on the Sprite Renderer, set the Material option to Sprite-Lit-Default (you will have to click on the little eye, to show all of the options).


Now all you have to do is add a Light object to your new sprite and viola, he shall GLOW!

You can play around with the effect of the glow by tweaking these settings on the Point Light 2D


If you want to watch the live stream of the making of this tutorial you can check it out here: Twitch Live Stream or you can catch the shortened version on YouTube!

What is an SLO?

It means that you should work carefully and SLOwly…

Nah, I’m just kidding that’s not what it means at all. It actually stands for Service Level Objective, but what does that even mean? Is it like an SLA? What’s an SLA? Is that like an SLI? What the hell is an SLI…?

Don’t sweat any of it as this is the first part in an upcoming mini-series on what the hell all of the SL(insert letter)’s really are. Let’s dive in!

An SLO represents a level of service that a business intends to meet for it’s customers. In particular, it is an objective, a goal, or a bench mark. It is the target that the company has set to aim for and reach for and it is the mark the customers and clients will come to expect. So what goes into an SLO?

Defining an SLO can be done in a number of ways. Some of the easier ways to define and set an SLO directly relate to technology. For example, a company such as AWS may set an objective at having their services up and running 99.99% of the time. That is their objective and goal. It is what they work towards maintaining and being at, at all times.

photo cred: Christian Wiediger

If AWS has an outage, let’s say the power goes out somewhere, and their system goes down for a couple of hours they would no longer be at their objective of being up for 99.99% of the time. This would let the AWS team know they need to create and invest in ways to mitigate such outages like routing traffic to a different data center.

AWS just so happens to provide an SLA (Service Level Agreement) which states some of their SLO’s, you can view it here: Amazon Computer Service Level Agreement. An SLA is merely the agreement between AWS and their customers so that if they are not meeting their SLO they can provide credit in return for the lack of service they have agreed to meet. Think of it as a way of saying, “hey we’re sorry we didn’t do what we said we were going to do. Here’s a refund.

Obviously missing their SLO’s and having to offer up credits is not something AWS wants to do, which is why you’ll notice there is rarely a service outage for AWS. IT does however let customers and clients know that AWS is committed to providing top-tier service. I wonder if that has anything to do with why they are so widely used…. 😉


If you take a peek at the AWS SLO link above you can see that they don’t actually target having their systems up and running 100% of the time. Why is that? The reality is that 100% is not realistic.

Consider the following example, in a single day there are 1440 minutes and let’s say that there is one tiny, minor, little hiccup in the internet. Let’s say it’s so tiny that it doesn’t even take up a full second. Instead it takes up milliseconds… like… .0144 seconds. That little blip would cause AWS to miss their 100% mark. Perfection is the enemy of progress. Remember that.

Instead, most services aim for somewhere that’s more acceptable. In some cases it can be 99.999% and in other cases it can be 80% (think of an internal service that provides customer data back to AWS. It’s not a critical system so if it fails 20% of the time, it’s not the end of the world). The point is that an objective is set and the company strives to achieve it.


Now I know we dove in a little deep there and the turns got twisty. That tends to happen when you start talking SL(insert letter here)’s because there is no hard and fast right way, BUT there are some best practices and I’ll continue this series and dive in a little deeper each time.

Hopefully you learned a little bit about what an SLO is and how it relates to the service a company is aiming to achieve for it’s customers. I recommend taking a look at another SLA from Google to help paint the picture. (remember SLA is the agreement between company and customer, the SLO is the actual target the company is aiming for, the 99.99%): Google Computer Engine Service Level Agreement.

Read the next article in the series: What is an SLI?

How to Intercept WebMethods in .NET

Legacy applications often suffer from tech debt. It’s a natural part of the development life cycle and depending on the size, scope, and team, tech debt can range from a few lines, to most of the project.

In a perfect world though, tech debt wouldn’t exist, but perfect is the enemy of progress, and so progress is made and tech debt is built. As tech debt mounts it can become increasingly difficult to integrate additional features and functionality. A good refractor can always help, but what about in cases where you need to add in things like logging or metric collection?

Previously you may have been stuck with having to sprinkle code throughout the application to collect the logging that was needed or you may have had to try and hunt down each place a specific line of code was called or used (and it’s various implementations). This can be difficult and unreliable. It also means that any time you want to make a change you need to go track down each of those little sprinkles and change them.

Enter PostSharp:

photo cred: Markus Spiske

PostSharp is a 3rd party library that you can include in your project and setup through Nuget. It allows you to apply Attributes to your functions that will then override your function and pass it through as a parameter. In other words, you can add a custom Attribute to any function and then either execute your new code before or after the execution of the original function. Let’s look at some examples:

After I’ve installed the Nuget package the first thing I want to do is create a new class that will handle my needs. In this example we’ll say we want to use some sort of metric collection functionality and to inspect the results of the function.

public class CollectMetric : MethodInterceptionAspect


Our new class CollectMetric.cs class will require that we inherit from MethodInterceptionAspect and that we apply the PSeriablizable Attribute. Both are PostSharp requirements. Next we can write our actual implementation. Some of this won’t be real code but you’ll get the idea.

public class CollectMetric : MethodInterceptionAspect
     public CollectMetric(){}//constructor

     public override void OnInvoke(MethodInterceptionArgs args)
          //more code to come

So now that we have our constructor and the OnInvoke() function. We can actually wire things up and start to debug and see how this works. We can do this by going to any function that we want to intercept and adding a [CollectMetric] Attribute. Like this:

public int MyOriginalCode(string inputs)

If we were to debug MyOriginalCode() we would see that before that function even gets called our OnInvoke() function will be called. Now all we have to do is decide what we want to do in our OnInvoke() function and then when to call the original MyOriginalCode(). It might look like this:

public override void OnInvoke(MethodInterceptionArgs args)
     args.Proceed(); //this calls MyOriginalCode() function like normal
     var value = args.ReturnValue; //output from MyOriginalCode()

     SaveMetricToDatabase(value); //some other thing we wanted to do

So by calling args.Proceed() we are really just calling our old original code like normal, MyOriginalCode(), and we can even capture the output of that function with args.ReturnValue. From there we can do whatever we want. Add logging, inspect the results of the function, whatever new things we want to do.


The big advantages we gain from this solution are that we no longer have to worry about creating bugs on existing code by modifying it. We also can encapsulate all of our changes in a single place and write unit tests around them. This is a far safer solution that going around and sprinkling in lines of code throughout the application.

If you get a chance to try the solution out let me know how your implementation went! I’d love to get some feedback on what worked and didn’t work for you and how I might improve my own implementation. If you attempt this project and get stuck, feel free to reach out to me by leaving a comment!

What is Site Reliability Engineering?

I was recently asked to move into the role of a Site Reliability Engineer. The only problem was… I didn’t even know what a Site Reliability Engineer was. Over the last few weeks I’ve started to dive in on what Site Reliability Engineering really is, SRE for short, and how to fulfill this role. I’d like to share some of the insights that I’ve gained about the role, what it means, and discuss some of the topics around SRE’s.

The role of an SRE is fairly straight forward on the surface but rather complex and intricate on how it is fulfilled. The job of an SRE is to make sure a website or webservice is reliable. The question is, what does reliability mean?

photo cred: Romson Preechawit

Does it just mean the website is up and running?

Does it mean there are no bugs?

Does it mean it performs well and there’s no latency?

And once you’ve defined what SRE is, how do you accomplish it?

Lots of questions and lots of answers.

SRE’s are sometimes confused with DevOps and some of their functions are very similar and overlap. Both roles favor automation and building internal systems and tools but SRE’s really differ in what they are trying to accomplish.

In DevOps, we want to improve the internal efficiency of our daily development operations, automating builds and unit tests, creating deployment pipelines, and be really focused on the CI/CD pipeline.


For SRE’s, we want to improve the post-CI/CD side of things. Meaning, once things are deployed, we want to make sure they are running smoothly and when they’re not we want to make sure we can get back to a smooth state as quickly as possible. For SRE’s it’s all about monitoring and alerting. Remember the end goal for an SRE is reliability.

Reliability… there’s that word again… so what does it mean for an SRE? Well it actually means a lot of things that come right down to what level of service you provide for your customers. Reliability is more than just, “is the application up and running?” It actually pertains to a wide variety of categories that all come back to how end-users view the quality of your website or webservice.

Here are a few of the categories that fall under the SRE belt:

  • Latency & Response Times
  • Data Quality & Correctness
  • Uptime & Availability
  • Volume & Load
  • Errors & Bugs
photo cred: Chuttersnap

All of these fall under the umbrella of reliability. After all, what good is a website if it slows to a crawl during peak hours? What value does it have if the data is incorrect or invalid? How useful is a website or webservice if it’s filled with bugs after every release?

These are all areas of responsibility for an SRE. Thankfully there are some great tools and best practices to make the life of an SRE easier. Over the next few weeks we’ll dive into some of those practices and tools and discuss how best to implement them. Even if you aren’t an SRE there will be plenty of valuable information and content for you to add to your Software Engineering tool box!

AWS Deep Racer: Part III


Finally I feel like I’m making some progress with my racer. The first few times around I felt like I was just trying things and then sending my model through training with crap results. My little guy would constantly veer off course from the track for no real reason… it was frustrating to say the least…

It also didn’t help that AWS DeepRacer appeared to have a brief outage last week. I was unable to train or evaluate any of my models last Tuesday and Wednesday.

After that little blip though, the race was back on!


At first I wanted to try and improve the speed of my model. After watching some of the top racers fly around the track I figured I needed to go fast or go home Ricky Bobby style. I started with offering just a bit more of a variety in regards to rewards with various speeds:

    if speed < 1:
        reward = 0
    elif speed >= 1 and speed < 2:
        reward += 1
    elif speed >= 2:
        reward += speed

This didn’t really seem to get me anywhere though. I couldn’t tell if it was actually any faster or not….

Part of the problem was the little guy kept driving off the course. I realized it didn’t really matter how fast I was going if I couldn’t keep the model on the track so…



With this version I tried to focus more on keeping the model on the track. I added a small little function to detect when the wheels went off the track and if they did, to reduce the reward. I had meh results…

The green line is the reward my model is getting. Meaning he thinks he’s doing a good job. The blue and red lines represent how well he’s actually doing… fml…


This time around I upped some of the reward values for staying towards the center line of the track and increased the penalty for going off track. The results were… sort of positive… I still wasn’t keeping him on track though and he would randomly drive off the course completely…


This time I wanted to double down on keeping the model on track. It was still veering off course far too often to really make any progress or improvements. So along with the function to try and keep the model towards the center I added another function to reward the model based on his distance from the borders of the track.

    distance_from_border = 0.5 * track_width - distance_from_center
    if distance_from_border >= 0.05:
        reward *= 1.0
        reward = 1e-3

And we started to see a little more progress…



A few more tweaks on reward values and….


Hell to the yes we’ve done it!

The biggest change in Mark-10 was that I really fleshed out the function for keeping distance from the border. It seems like the more “levels” you provide the model to be rewarded for, the better it can progressively learn what you want it to do.

What I mean by this is instead of say… giving the model a full 1 point reward for staying on the center of the track and then a 0 for everything else, you give the model a gradual range of options to earn rewards on. This sort of coaxes the model towards the behavior that you want.

I’m currently ranked at 525 of 1135 racers for the October Qualifier and you can check out my latest qualifying video here:

AWS Deep Racer: Part II

The Race is on! Sort of…

So I’ve been diving in deeper to AWS Deep Racer, pun not intended… and I’ve managed to work through a handful of tutorials. I’ve built 4 different models to race with so far.

My first model, Mark-1, currently holds the best record on lap time, of my 4 models, for the October race sitting at position 737 of 791 total racers. The October 2020 track looks like this:


The Mark-1 model used a very basic reward function that simply trained the model to attempt to follow the yellow dashed line on the center track. It’s a default reward function that reinforces the model attempting to stay towards the center of the track. It doesn’t get you far… but it does get the job done. Total race time: 08:29.214



With the Mark-2 model I tried to just build off of the first iteration. I added some additional logic to keep the model from trying to zigzag too much on the track as it worked towards finding the best center line. I also made a classic rookie mistake and implemented a bug into the reward function where instead of incrementing the reward value when the model stayed on track, I was just applying a default… this model didn’t even rank.


With the Mark-3 model, still containing the defect from Mark-2, I played around with the Hyperparameters of the reinforcement model. As a part of the training system you can do more than just modify the reward function that trains the model. You can also adjust and modify the batch size, number of epochs, learning rate, and a handful of other Hyperparameters for training the model. Since I still had the bug in my reward function from the previous model, this model didn’t rank either.


On to Mark-4… I caught my defect.. ugh… and fixed that up. I also decided that at this point I was ready to move beyond the tutorials and really start adjusting the models. So the first thing I did was take a look at what the competition was doing… Here’s a look at the number 1 model currently sitting at the top of the October qualifier…


Well shit… I’ve got a ways to go to compete with this model. I mean this model is flying around the track. Mine looks like a fucking drunk wall-e….

So I’ve got some work to do but the current AWS Deep Racer app is down. As soon as it comes back I’m refocusing on speed first. I need to Lightning McQueen this bad boy if I’m going to stand a chance of even ranking in the top 100 for the October Qualifier.

Check back with me next week and we’ll see if I can get this little guy going!

AWS Deep Racer: Part I

So after my little experiment with Predicting Stock Prices with Python Machine Learning I came across the AWS Deep Racer League. A machine learning racing league built around the concept of a little single camera car that uses Reinforcement Learning to navigate a race track. I’ve decide to sign up and Compete in upcoming the October race and share what I learn along the way.

photo cred: aws

Let me give a little bit of background on how the Deep Racer works and the various pieces. There are two ways to train your little race car, virtually and physically. If you visit the Deep Racer site you can purchase a 1/18th scale race car that you can then build physical tracks for, train, and race on. There are also various models you can purchase with a couple of different input sensors so you can do things like teach the car to avoid obstacles or actually race the track against other little cars.

This little guy has 2 cameras for depth detection and a back-mounted sensor for detecting cars beside/behind it

The good news is you don’t actually have to buy one of these models to race or even compete. You can do all of the training and racing virtually via the AWS console. You also get enough resources to start building your first model and training it for free!

Now let’s get into how this actually works. What AWS has done is built a system that does most of the heavy complex machine learning for you. They offer you the servers and compute power to run the simulations and even give you video feedback on how your model is navigating the track. It becomes incredibly simple to get setup and running and you can follow this guide to get started.


When you get setup you’ll be asked to build a reward function. A reward function contains the programming logic you’ll use to tell your little race car if it’s doing it’s job correctly. The model starts out pretty dumb. It basically will do nothing or drive randomly, forward, backwards, zig-zags…. until you give it some incentive to follow the track correctly.

This is where the reward function comes in. In the function you provide the metrics for how the model should operate and you reward it when it does the job correctly. For example, you might reward the model for following the center line of the race track.

On each iteration of the function you’ll be handed some arguments on the model’s current status. Then you’ll do some fancy work to say, “okay, if the car is dead center reward it with 1 point but if it’s too far to the left or the right only give it a half point and then if it’s off the track give it zero.”

The model tests and evaluates where the best value is based on the reward function

The model will then run the track going around, trying out different strategies and using that reward function to try and earn a higher reward. On each lap it will start to learn that staying in the middle of the track offers the highest, most valuable reward.

At first this seems pretty easy… until you start to realize a couple of things. The model truly does test out all types of various options which means it may very well go in reverse and still think it’s doing a good job because you’ve only rewarded it for staying on the center line. The model won’t even take into account speed in this example because you’re not offering a reward for it.


As you start to compete you’ll find that other racers are getting even more complex like finding ways to identify how to train the model to take the inside lane of a race track or how to block an upcoming model that is attempting to pass it.

On the surface, the concepts and tools are extremely easy to pick up and get started with, however the competition and depth of this race are incredible. I’m looking forward to building some complex models over the next couple of weeks and sharing my results. If you’re interested in a side hobby check out the AWS Deep Racer League and maybe we can race against each other!