Tag Archives: Programming

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!

How I Conduct a Code Review

Code reviews have been and always will be tricky business. If you’re familiar with performing code reviews or having someone else review your code, you hopefully can understand and see the benefits. For some though, a code review can be a hit to the ego. Here’s how I’ve approached code reviews and what I find works best.

First and foremost, you have to have some formal code review practices in place. If you don’t, I suggest you start by offering up your services. Not in a way that says, “I’m a better developer and I know more so let me make sure your code is right.” If you give off any type of vibe like this, your code review is going to come off as arrogant and unwanted.

Offer your services for a code review as a means to help take some of the pressure off of the other developer. Your code review is to help them look for bugs, typos, or little details they may have missed. It’s also to provide a challenge back to that person to ask both you and them to think critically.

Once you’re able to agree to a code review with your peer, the next step is actually conducting the review. But how do you go about performing a code review? What should you be looking for? What really works? I follow these same steps, every single time, and find they always hit the nail on the head.


Step 1: Compare

Before I actually do any real review, I start by performing a compare. There are a lot of ways to compare the changes, before and after, and I’ll let you figure that part out. I start with a compare to get a sense of what I’m going to be reviewing.

How much code has changed and how much did it change by? At times I may find that too much has changed, making the review nearly impossible. When this happens, it’s best to recommend that the developer try to create smaller commits. BOOM! You just gave your first piece of code review feedback.

When looking through the compare, don’t try to focus on individual lines of code yet. We’re not at that stage. Stay at a high level and focus on structure and getting familiar with what you’re working with. Are there new classes or functions? Is it a complete rework or just a quick change? Are there unit tests? Did the developer leave any notes for the reviewer? Focus on gathering information and making an initial assessment.

If I suspect that the developer is not done working on an area or that there may be major, additional changes I will stop my review right there on that area. There is no sense in going to the next level of review if the section of code will potentially be refactored or changed. Save yourself some time and simply give the developer your high level assessment and tell them you look forward to diving deeper once they are closer to completing their changes.

photo cred: Pankaj Patel

Step 2: Debug

This is a step I think a lot of inexperienced code reviewers skip over. DEBUG THE F%$*@!+ CODE! For real though, pull the code down, set breakpoints on all of the changes (because you know where they are because you just did a before and after compare on them) and start to debug. I find that it helps me if I just go line-by-line and get an understanding of what each piece is doing.

This is where I really start performing the review. I look for any errors, bugs, or design flaws. I also ask questions about anything I’m unfamiliar with myself. If the developer created Unit Tests I try to either add my own data to those tests or see if I can break them. This helps expose any areas the developer over-looked.

You might be thinking that stepping through each line is not needed or that it’s a lot of extra work but in all honesty it’s not. You can debug a few hundred lines of code in a matter of minutes. Most developers break things out into more lines than what they would ever really need and stepping through that code becomes even easier.

photo cred: Agence Olloweb

Step 3: Feedback

After stepping through every line of code you should be prepared to provide your feedback. When it comes to feedback I find there is really only one good way to do it. Keep it positive and make it suggestive. At the end of the day, the developer who wrote the code has to be responsible for the quality of that code. Often times if you try to force a change in your code review you’ll end up with a You vs Me scenario that isn’t really productive for anyone.

I prefer to start with something positive. I try to take into account the amount of time and effort the developer had to put into their work and look for any design patterns or usage of good programming practices that I can point out right a way. It’s a lot more fun to code review someone’s work when they are using best practices.

For the harder stuff, I try to offer up changes as a suggestion. Unless I see a clear cut bug. If I see a bug or true flaw I try to provide a Unit Test or solid steps to reproduce to help the developer out. After all, we’re all in this together.

If the change is more about design or best practice, then I offer it as a suggestion. I might say, “Hey you could try this technique here to reduce x amount of code” or “If you try this, it can help keep things easier to maintain down the line. Let me know if I can help!” Offering up additional services or help is often a great way to provide feedback.


Step 4: Rinse & Repeat

From there you can send your code review back. Try to capture as much as you can in that first review. It’s much less grueling if you have to go back-and-forth and back-and-forth because you keep only catching one issue at a time. Try to capture all of it, up front, on the first review.

When the code comes back again for a second review. Hopefully all items are addressed and you can pass the review BUT don’t be afraid to go back through steps 1-3. Actually I encourage you to go through them each time, just maybe at a faster pace or a high level. For example, your first pass you should debug every line of code, maybe on your second review you just stick to the areas of change.

Hopefully this gives you a good idea of how to conduct a code review! If you have any personal tips on your best practices for code reviews I’d love to hear them!


Developers tend to be really great at writing code but not so great at documenting that code. It’s not that they can’t or don’t want to, it’s that often times the effort to write that documentation isn’t captured within the scope of the requirements for the feature.

But as developers we shouldn’t let that stop us!

photo cred: Shahadat Rahman

I’ll share a couple of good reasons to document your code and some really easy ways to make it happen. While we’re at it, let’s stop using the gross word “document.” What you want to write is a solid README!

Why You Should Document Write a README:

  1. Writing a README gives you a means to not be the sole owner of that code. When you have notes around how your code works, what it intends to accomplish, and how others can contribute the project, it stands a much greater chance of getting additional buy-in from other developers and stakeholders. When you’re the only one who knows how it works, be prepared to be the only one whoever gets asked to work on it.
  2. Writing a README for your code helps you be able to come back to that code and remember that one piece of how you set it up originally. It allows you to go back 6 months later and say, “Why the hell did I do it this way… Ohhhh… right… here’s why.” Save yourself, write a README for your code.
  3. Writing a README for your code helps you think through the scope of your project and its functionality. It helps you take a step back and really consider what you’re doing and why you’re doing it. It helps you put that official stamp of approval that you’ve completed this version and it is DONE. Scope creep is dangerous, writing a README on the current state of the project and any potential future work can help keep that project from living forever.

How You Should Document Write a README:

  1. README, README, README… most source control services provide some extra functionality around writing README’s. Some really great ones like Gitlab and Github will display the contents of the README in a web browser making for easy access. If you’re not using source control, YOU SHOULD BE!. If you are using source control, you should be writing a README and including IT with your source code.
  2. There are some great README templates out there! Save yourself a ton of headache and find one that works for you. A template gives you a head start and helps you focus in on what you need to cover. It also helps maintain the scope of your README. Here’s one that I’ve used: https://github.com/othneildrew/Best-README-Template
  3. Don’t just rely on a template. Use the template as a starting point, but think about what is going to be important for your team, users, and stakeholders to know when viewing your README. Do they need to know how to set it up? Do they need to request any special permissions from anyone? Can you reference other documentation that might help give them a deeper understanding? Try to think of your README as being something you can hand to another person and they do not need to come back to you with questions.
  4. Maintain your README. As you do get additional questions on the project, update your README. Add a Frequently Asked Questions section or fix that typo. Include an area you may have missed from the first pass and encourage others to contribute to your README. Continue to build into your README as you add new functionality to your project and just remember to Keep It Simple Stupid.

README’s often get skipped over as we jump from project to project. I’ve been guilty of missing out on including them before but I’ve also seen the advantages of including them and I’m working to continue working on them.

The best place to start is to just start. Go grab a README template, paste it into your project and fill it out bare bones. From there you can build on to what you’ve started and the next thing you know, you’ll have a solid document around the who, the what, and the why.

Happy Coding!

How to Debug a Unity APK on an Android device with Visual Studio

Oh my goodness this was far too difficult… so I had to write it up! This guide assumes you have some experience with Unity, debugging in Visual Studio, and building APK’s (let me know if you don’t in the comments!).

If you’re using Unity, you’re coding in C#, and you’re using Visual Studio… Here’s how you can setup a remote debugger to debug your APK on an Android device.

I’m currently using the following tools but the steps are generally the same:

Unity v2020.1.7f1

Visual Studio Community 2019

Android Studio v3.5 & SDK

Samsung Galaxy S9

Step 1: When you build your APK you’ll want to tick 2 boxes on the build settings menu. ‘Development Build‘ & ‘Script Debugging

Step 2: Create your build as usual and copy the build to your Android device. Connect your Android Device to your PC via USB. Be sure your machine and Android device are connected to the same wifi network.

Step 3: If you haven’t previously, Enable USB Debugging on your Android Device.

  1. Open Settings
  2. Select System
  3. Scroll to the bottom and select About Phone
  4. Scroll to the bottom and tap ‘Build Number’ 7 times
  5. Return to the previous screen and find ‘Developer Options’ near the bottom
  6. Scroll down and select to enable ‘USB Debugging’

Step 4: Back on your computer, open up a cmd prompt (or terminal) as an administrator and change your directory to:


Step 5: Back on your Android Device, find the Android Device’s IP by going to:

  1. Go to Settings
  2. Go to ‘About Phone’
  3. Got to ‘Status’
  4. Find ‘IP Address’
  5. Write it down…

Step 6: Back in your command prompt enter the following command:

adb tcpip 5555

If you need some extra help see the Unity Documentation here

Step 7: Connect to your Device with this command using your IP from Step 5:

adb connect [YourIpAddress]:5555

Step 8: Open Visual Studio from within Unity and go to the ‘Debug’ menu option. Select ‘Attach Unity Debugger’

Step 9: You should see a small menu popup and it should display both your computer and your connected Android device. Select your Android device, set some break points in your code, and have fun!

Hopefully this guide saves you some time and headache on trying to figure this out. If you need more information on connecting your device that this guide doesn’t provide let me know so I can update it!

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!