This is less of a blog post and more of a brief public service announcement. If you are using Entity Framework and you change the namespace of your Context file bad things will happen. Future Add-Migration commands will attempt to re-script your entire database. Google will be remarkably unhelpful in diagnosing this problem.
“But,” you say, in your best Comic-Book-Guy voice, “changing namespaces is annoying; no one would just change their Context’s namespace.” To which I reply, “if you’re using ReSharper you might, because it pretty much automates the process and nags you if you move files around.”
Not that solving that problem just consumed an hour of my day or anything.
One of my goals in spinning up a software development team at Foxguard has been to have a development environment ready to go before the first person comes through the door. That means a vague skeleton of the application we are developing as well as the apparatus of building, deploying, and testing that application. Since anything worth doing is worth doing right we’re approaching the latter problem with a Continuous Deployment solution in mind. That means that every time we commit code it is picked up by a automated script, built, tested, and published — ready to begin evaluation through some as-yet-to-be-determined test suite.
The first part of this is fairly easy. Jenkins is a great tool and there is no shortage of tutorials out there on how to make it play nicely with GitHub, MSBuild, or any other technologies you might be using.
Deployment, though, is a bit of an more difficult nut to crack. (more…)
Thus is the danger of over-automating your life. I long-ago configured
So now we’re back up and running with a new and improved spam filter.
Software development is about process refinement. Try something, see if it works, revise, adapt, reset, and try again. If you’re doing the same thing the same way every time you’re not moving forward and, in this field, that means you’re falling behind. Do that long enough and you start to apply it to other things in your life. I switched from a QWERTY layout to Dvorak for more or less that reason (working out well, by the way) and I’ve taken up baking and gotten into coffee with much the same approach. (more…)
After a lot of soul searching on my professional future and the path that I want that future to take I have left VirPack and, today, begin my new adventure at Foxguard.
Here I will have the opportunity to build and likely manage a development team, the freedom to build quality and maintainability into the software process from day-one, and an opportunity to really make a difference in an industry in flux.
On the down side, I no longer have a window in my office.
Deep breath; here we go!
Back in the 1940s a guy named Dvorak got it into his head that the way we type is wrong. Our fingers transit too far across the keyboard, he argued, and as a result our motions are inefficient and slow. Dvorak rearranged the standard QWERTY keyboard to make typing more efficient, eliminating the design constraints which had originally informed the layout we all learned to type on.
In theory, that should make for a faster typist though it does take some getting used to. For me, this marks the jumping off point and possibly a painful transition. This entire post was touch typed using the Dvorak layout and, despite quite a bit of practice on a
One of the projects I have been working on with VirPack has been the establishment of a developer’s training program and central to that program has been Robert Martin’s materials on Clean Code. While many of Martin’s ideas have sparked some interesting discussions at VirPack, none has been more controversial than his discussion of Test Driven Development. Martin holds to a three-part cycle: Fail, Pass, Re-factor – in which you write just enough of a test to fail, just enough code to pass, and sometimes re-factor to clean up before cycling back to failure. This results in a number of areas, particularly in Martin’s examples, where tests seem to be written merely to justify an action everyone agreed was necessary in the first place — say, a test to see if you can construct an object which is then run, and fails, because the object does not yet exist.
While I am pretty well sold on Martin’s coding philosophy I decided to take my coworkers objections under advisement but with a grain of salt. Most of the Kata and examples that Martin works through are very simple; they have to be in order to be short enough and accessible enough to communicate the points he is trying to make about software development but that simplicity also means that the early fixed-costs of TDD seem very big compared to the actual “meat” of the problem he is trying to solve.
So I set out to try out true TDD on a project which I knew was going to be complicated. Martin’s examples of things like a bowling score calculator had just a few plausible test cases and a mere handful of interesting results which could emerge from a complete examination of all possible execution paths. I wanted something much bigger and much more complicated and the historian in me knew just where to look. (more…)
There’s a wonderful post over on the JitBit founder’s blog which is apparently a 2nd generation attempt to answer this question. Follow
Job requirements: professional skills in driving normal- and heavy-freight cars, buses and trucks, trolley buses, trams, subways, tractors, shovel diggers, contemporary light and heavy tanks currently in use by NATO countries.
Skills in rally and extreme driving are obligatory!
Formula-1 driving experience is a plus. (more…)
Elliott Kember, has a post on his blog right now discussing an apparent “security vulnerability” in Chrome. Security Vulnerability is in quotes there, not to mock Mr. Kember, but because the behavior Chrome exhibits is debateable as either vulnerability or feature. First, let’s walk through the behavior.
If you’ve saved passwords into Chrome, navigate to chrome://settings/passwords and click on a row. You’ll see a “show” button which, when clicked, displays your saved password. (more…)
Inversion of Control (IOC) frameworks have become quite the rage as the software craftmanship movement has gathered steam. IOC makes it much easier to break complex multi-part programs into distict, and more importantly testable, components so that they can then be glued back together at run time. There are lots of nifty frameworks that can make this happen but at the moment I’m playing with Ninject.
Ninject is a very minimalistic IOC framework which focuses on what it calls a “fluent interface” that leverages the compiler and IDE rather than a huge XML file to map dependencies. Overall it’s very fast, very light weight, and very powerful. I’ve picked it up quickly and found it to meet almost all of my IOC needs.
Save one. And this is apparently a big problem for a lot of people. Ninject doesn’t like overloaded constructors. (more…)