Recently I have started a new part-time thing, mentoring students who are attending code camps on various major universities. This has caused me to delve into subjects and areas of programming that I had not visited for some time. The fundamentals mostly, and areas which are important to programmers in training. This is what the students need and honestly I am enjoying it also.
This article describes how to setup Git-Bash as its own tab inside of ConsoleZ, the command prompt replacement application. So here I go again. In using Chocolatey, the package manager for Windows, to install Console2 on my work machine I somehow ended up with what I guess is the latest iteration. I make this assumption because the menus are very similar, particularly the settings dialogs, etc. I really like the look and feel changes in ConsoleZ, and there are some new tab related features as well. It looks like Console2 is no longer maintained and so this fork is now the go to console replacement. No problem except this means I needed to get Git Bash working again in its own tab, within ConsoleZ.
All of my projects recently use MEF to handle all dependency injection in both the service layer and in the view models (PRISM). I recently needed to be able to inject a different implementation of a particular interface to all of the imports that called for that interface. All based on a setting or a flag.
Our current project communicates with a pump module that is the main hardware unit for the application, and that uses a serial port to connect with the pc and our software. I have already written a system layer service library for talking to the pump. The main application also has a pump service that is in the application layer and that is the communication point for the system service. All of the services have an interface defined in Core.Interfaces and this is where the user interface modules can reference the application services, such as in the view models. The interfaces are implemented by classes in the Application Services library including the Pump Service interface, aptly named IPumpService.
TDD is a mindset
Test driven development is a way of designing as much as it is a way of developing. I have been trying to use it on and off for a several years now without much success. I think I understand the process, but not necessarily the mindset. So, I am taking on a challenge in hopes of learning the mindset as well as the process. The transition to TDD is going to take practice and I intend to get that practice using the Project Euler problems that I started on a couple of years ago. One of the added benefits of using the Euler problems is that they are simple enough usually (or I should say, “So far”) that they can be solved using a single class or even a single method. This makes writing tests for the design a little more direct and therefore simpler.
I am back working on Project Euler again. It has been a great long while, maybe 4 or 5 years, not sure, since I started on it originally, using ruby. Now I am using a mixture, starting for Python for a bit, and possibly switching back to ruby. I say that after solving this last problem (#4) and then going thru some of the other folks solutions, the most elegant usually are the ruby ones, in my humble opinion.
There are of course smaller, or rather more concise, ones but they are too cryptic. Solutions is in statistical languages such as J or K are frightfully illegible. I have to share, just for kicks. First, the problem was to find the largest numeric palindrome that is the product of two 3-digit numbers. Similar to 9009 being the largest that is the product of two 2-digit numbers, 99 and 91. So just for giggles, here are a couple of super concise (and un-readable INHO) solutions:
1. This is in J (http://www.jsoftware.com)