As a sort of year in review post I’ve decided to review the top 5 technologies I learned and/or used this year to solve some of my problems. Here are my top 5 technologies for 2017 in no particular order. Sugar ORM My university’s mobile application development class allowed the use of any third party libraries available to produce a functioning Android application. I knew that I didn’t want to manually prepare SQL statements if I could help it and I really enjoy using Eloquent ORM for Laravel projects despite ORM being considered an anti-pattern by some folks.

I work as a hardware test engineer for a large computer hardware company. The principal software products that I work on orchestrate and execute hardware tests based on the product that is connected to the testing station. We mostly test units that are running Windows operating systems and learning batch/powershell scripting has been very useful in gluing test executions together. However, I recently discovered a few caveats in our process and this post will detail how I worked with and around the issues that I found in our polling and writing methods.

In the last part we set up our webpack with babel and our boilerplate. In this part, we’ll use that webpack setup to start building our Single-Page application with vue-router and vuex. To start putting our routing together we’ll need to define a few components to separate out our application logic. Create a folder in your source directory called components and an admin folder inside of that. Now create a Home.

This blog post will detail the necessary setup for a Vue.js single page application. It will also detail a webpack setup to minify and transpile our .vue files into a single, minified javascript file that we can “ship” to the browser. To get started we’ll head to the command line: Fill in the fields as needed for your package file. After we’re done we’ll install Vue and the Vue router. I’m also going to install the VueX state manager so that we can save application state if necessary.

I found a couple of problems with our CI workflow that we built in the last post. We’re not running any tests The docker container we’re using to build the solution doesn’t pass out the exit code of our command; if a build fails inside the container we won’t know about it as long as our docker-compose command exits with code 0. I picked xUnit to test our C# code because it’s got a more familiar assert structure that’s similar to jUnit.