This week, I’m at That Conference in Wisconsin Dells, WI. It’s a 3-day, language agnostic developer conference, and I have attended for the past four years (this year inclusive).

That Conference logo

I actually started on Saturday and Sunday by participating in Give Camp, which is essentially a hack-a-thon. This year, as last year, the project to which we contributed is Humanitarian Toolbox, which aims to work provide software to prevent, prepare for, and respond to disasters. Working on Humanitarian Toolbox was my first exposure to open source projects, and I really felt like I was able to contribute on the project well this year. Not only did it give me an opportunity to work with other people (an opportunity that I relish since I work as a solo developer at my day job), but I also gained some exposure to some new technologies (.Net Core, Git, MoQ, etc). I look forward to continuing to contribute with the project and watch it mature into something that can really help people.

Today was the first day of regular sessions. The keynote, titled “You have too much time”, was delivered by Jeff Blankenberg and focused on the idea that people are generally very bad at prioritizing their time. We use excuses such as “I don’t have the time” or “I am too busy”, but we really mean “I did not prioritize this” or “I would rather be doing something else.” When examining waking hours, time spent consuming media alone is often more than an entire month of the year. However, I think it’s important to note (as did the speaker) that time spent consuming media where you have specifically chosen that as your priority is perfectly acceptable. For the most part, I feel good about where I am right now, but I have spent a lot of time thinking about this problem. Earlier this year, I implemented a Kanban system at home to try and help me prioritize the projects and things going on in my life. My work Kanban has been a lot more successful than my home life board, though, as some tasks just languish and never seem to see completion.

The first session I attended was a discussion on microservices lead by Mark Heckler. I am a sucker for discussions on architecture and new ideas in software engineering, and microservices seems to be the direction that most things are headed. Mark had a really great analogy to describe the differences between SOA (service-oriented architecture) and microservices: SOA tends to be more like an orchestra where a conductor leads the group, whereas microservices are more like having a choreographer teach the group the moves.

Having written monolithic applications and also watching the .Net framework become a monstrous, resource-intensive thing over the years, I have seen firsthand the issues that can arise from this approach. So has Microsoft, obviously, as they have really embraced modularity with their approach to .Net Core and the future of their framework. One of the things that hit home the most for me about monoliths is that failure in a single component leads to failure of the whole, and a fix requires replacing the entire executable. Making a change in a large, monolithic structure can also be daunting if you aren’t familiar with the architecture – I remember that it took me somewhere around six months to get my head around the main application when I started working at my current job. This is definitely a topic I want to explore some more and see how I can take advantage of what microservices can do for the applications I develoop. One of the resources offered was a site called which details a methodology for building software-as-a-service apps.

The second session I attended was about continuous security, and offered some ideas for integrating security tools into build and/or continuous delivery pipelines. Security is something I have spent a lot of time reviewing over the past year or so, but Wendy Istvanick’s talk taught me a lot of things I could and should be doing to really make sure that my software is being checked for vulnerabilities. One of the highlights was the use of OWASP (Open Web Application Security Project) to identify project dependencies with known vulnerabilities. Like any good developer, I include a variety of third-party packages in my project, and they usually have their own dependencies that I don’t even think twice about. Being able to view a report of which dependencies might have known vulnerabilities is a big plus. Another tool called talisman is a precommit hook that prevents team members from checking in sensitive information (passwords, app secrets, etc). Finally, OWASP Zap sends out attacks to whereever you point it, and there are ways to automate this (in addition to providing a web interface).

Kirsten Hunter gave the third presentation of the day, and it was about becoming a polyglot (or, one who is comfortable programming in multiple, disparate languages). I’ve always liked the idea of dabbling in many different languages, but have had trouble overcoming the issues of setting up the infrastructure to get everything working. The speaker at this session had set up a docker container that had the code to stand up instances of essentially the same API (a random quote generator) in five different languages: python, ruby, php, perl, and javascript. I plan on using this as a starting point to examine other languages and commit new languages back to the project after I’ve had a chance to become familiar with the project.

Lastly, I went to a session on optimizing Asp.Net core code to be more SOLID (single responsibility, open for extension/closed for modification, liskov substitution, interface segregation, and dependency inversion). The session was given by Jimmy Bogard, who wrote the excellent AutoMapper, a tool that I use every day to map my domain entities to view models. Asp.Net core has given the ability to write more flexible IActionFilters that plug in to the services configuration section of Startup.cs than previous versions. This now allows us to remove a lot of duplicative code, especially in things like POST requests that follow a similar pattern: validate input, map to database entity, persist to database. He also detailed some of the abilities of AutoMapper to project specific columns directly from the database without having to hydrate the entities into memory first. Finally, he gave some good reasons for more clearly defining the transaction scope that Entity Framework uses – it’s not always clear what the scope is when you call “Save changes” in your code.

His examples also made me think about using a flatter structure of my code. I use a pattern that requires several layers and the repository / unit of work patterns in concert, but as frameworks develop, it seems that much of this is unnecessary and adds some overhead. For one thing, I am unable to take advantage of the ProjectTo optimization because I am hydrating my entities in a service layer and passing them back to my controllers.

Overall, I really enjoyed the first day and am looking forward to the second.