Dev Up Conference 10/9/2018

My employer was kind enough to sponsor part of the DevUp conference this year. Additionally, they sent the whole development staff for professional development.

It didn’t take long for us to get seats and get comfortable for the opening Keynote about the future of technology.

Maggie on my right.

Jeff on my left.

They went all out on the opening this year. With a talk about the future, it just made sense to have a DeLorean there!

Of course, it wasn’t all learning, we did stop to have some fun!

Chad showing that cutout what real muscles look like!

A couple of beers!

This was a HUGE Foosball table, we had at least 12 people playing and still had to move to different positions to cover them all!

Chocolate covered bacon, does it get any better?

I did pretty good at this blackjack table. It may have had something to do with the way the dealer dealt his face down card… You would have looked too if it meant winning πŸ™‚

Overall it was a pretty good conference. I had lots more photos including one of a sleeping co-worker. But some people are over sensitive so some things will just have to be remembered!

Ohh, one last note, if you’re reading my blog and you run a conference center (yeah, like anybody is reading this crap), please put your screens up higher. If you’re sitting in the back, important pieces of a visual just become the back of people’s heads!

Hogan Haake

 

 

DevUp Conference – 10/16/2017

My employer, DeckCommerce participated in the DevUp conference (formerly Days of .NET) this year. This meant that the company had a booth for recruiting. It was a fun place to gather and talk about the company to others in the community.

Christa Range and Jenny Fritz were the primary people at the booth.

And no booth is complete without some sort of giveaway. We had a plastic thing that nobody could figure out. Once explained, it made sense, so I suggested that they have a contest for a creative use of it.

It was an interesting talking point, but a disappointing give away. But we live and learn as a company. Here are a few photos from the event itself.

The keynote address to kick off the event was around javascript development.

Looking to my left

Hogan, Gretcen Grote, Maggie Ma

Dave Bubenik, Jeff Hug

It isn’t something our company does, so most of us left early to check out vendor booths.

Chad LaCroix trying to pay attention

 

Gretchen Grote wondering when I’ll stop taking photos!

Overall it was a good conference with lots learned. If you’re still wondering what the give away does, its a cell phone holder. Plug in your brick through the hole and place your phone on the ledge.

Hogan Haake

 

Dependency Injection and Circular References

I’ve been using dependency injection (DI) in my code for over a year now. I wasn’t a huge fan of it when I started. The only benefit I have seen from using it is with unit testing. When code is unit tested, its easier to “hide” parts of code you don’t want to test.

I’ve also read about the performance hit for using DI. All code has a cost and I wanted to be preemptive about getting the most out of our code. The company I work for uses Ninject for their DI tool. Many performance benchmarks place Ninject near the bottom of the list for performance. DI’s performance hit is mostly during startup, but that is one of the places I feel we need to be faster.

We didn’t do anything complex with Ninject/DI. Just basic constructor injection. This is the act of using the DI container to populate the IWeapon object when it creates the object based on a Ninject config file.

--Code from Ninject's site.
class Samurai
{
    readonly IWeapon weapon;
    public Samurai(IWeapon weapon) 
    {
        this.weapon = weapon;
    }
    public void Attack(string target) 
    {
        this.weapon.Hit(target);
    }
}

class Sword : IWeapon
{
    public void Hit(string target) 
    {
        Console.WriteLine("Chopped {0} clean in half", target);
    }
}

When we use the code, we can just call the following.

Samurai sam = new Samuari();

If you’re new to DI, you’ll assume that this code will break, but Ninject/DI will use its config file to add whatever class you have bound to IWeapon.

This means that removing Ninject and its config file will break the code as the IWeapon object isn’t defined. Using our this is where I was updating our code to manually bind on the default constructor. The updated code would look like the following

--Code from Ninject's site.
class Samurai
{
    readonly IWeapon weapon;
    
    --Default Constructor replaces Ninject.
    public Samurai()
    {
        this.weapon = new Sword();
    }

    public Samurai(IWeapon weapon) 
    {
        this.weapon = weapon;
    }
    public void Attack(string target) 
    {
        this.weapon.Hit(target);
    }
}

class Sword : IWeapon
{
    public void Hit(string target) 
    {
        Console.WriteLine("Chopped {0} clean in half", target);
    }
}

If you’re still reading, thanks πŸ™‚ Ninject purists will state that I’m loosing the advantages Ninject provides. If an implementation changes, I can’t make a fix in 1 Ninject config file, but must update code in several places. I’m okay with this performance tradeoff. My implementations don’t change that much and I have find/replace tools that I am comfortable with. Using this method, I still get the advantages of basic DI for unit testing that I wanted in the first place.

Here is where the problem comes in and the title of the article. By using a DI tool such as Ninject, I can easily create circular dependencies in my projects. It turns out that in the project I was attempting to remove Ninject from, two assemblies were each referencing each other. Because we are using Ninject, there is not direct reference in the project references for the other project. Its all brought in via runtime with the DI tool.

At this time, my plans to remove Ninject are on hold as it would take a significant refactoring of the code to remove the circular reference. I am by no way saying not to use DI, but to be careful as it makes it easier to do some things that you don’t want to do.

Hogan Haake

The Trouble With Being a Software Developer

When my wife and I first got married, she took care of our monthly bills. Each month bills would pile into the desk and once a month or so, she would go up to the office and pay the bills. Then after paying the bills, she would sort and file them in a cabinet for reference. Most of the time, we never look at the bills in the cabinet, but occasionally, we review a previous bill to compare it against the current one. Sometimes for trending an electric bill, most often to see where the rate increased.

Eventually it was decided that it was my turn to handle the bills (something about pulling my weight around the house). We both soon discovered that I am horrible at organizing and filing away the bills into folders. After much deliberation, we decided that I would scan the bills and place them in folders on the computer. In order to best organize them, they were placed in a “Bills/2013/<person we owe money to>” structure. The problem I have run into is that at the beginning of the year, I end up creating a folder for the new year, then manually creating 20 plus new folders with the correct names. I would just copy the whole directory, but then it would include all of the PDF files of the bills in that folder.

Being a lazy guy, I endure this task saying that I should automate the task but never bother. This year, my father was mentioning to me that he has the same problem with is personal and professional folders. I figured that with a need greater than just mine, I would create a program that copies just the folders. I look for every opportunity to “pay back” my parents for all of the opportunities they have provided me with my life.

I spent about an hour writing a simple program that would copy the folders without the files (including sub directories). It wasn’t hard and I didn’t have to look anything up as it was a simple program. I actually had more problem trying to email the file dad as his email provider didn’t like .exe or .zip files…

I sent the program to dad and he was quite happy to have it. He sent it to other people in his office that had the same problem. Simple code that was a hit in a local accounting office.

The story would have ended there, but I was doing some work on my company’s software Continuous Integration build server. I had to copy some files over the network. I was looking into the properties for “xcopy” and came across the following documentation.

xcopy /t /e “C:\Your Folder” “C:\New Folder”
/t = Copies the subdirectory structure, but not the files
/e = Copies subdirectories, including empty ones

This got me thinking, and I did a Google search (https://www.google.com/search?q=Copy+folders+without+files). According to Google results, about 17 million results were returned with people looking for or solving this relatively simple problem. Some result pages offered multiple solutions from the built in Windows commands to elaborate custom projects that make my simple copy program seem insignificant.

The point I realized is that being a software engineer, I should have been smarter. It is very easy for me to write a quick program to solve a problem, but maybe I should be looking for alternate existing solutions before I dig in and just start writing code. Maybe I wouldn’t have missed that big play during the game if I wasn’t on the sofa writing the solution to a problem that has already been solved many times! How many other places in my professional career should I be looking for existing solutions instead of making my own?

Hogan Haake