Tools
Many of the interesting .Net bloggers are part of the Alt.Net crowd; evangelizing Dependency Injection, Design for Testability, Test Driven Development, SOLID design and other development practices that they find useful in their work. It doesn’t take long reading these blogs to pick up on what looks like an unforgiving attitude towards those who don’t use the latest acronyms in their software development. This acrimony is unfortunate because most often what is at the heart of those who question the standard Alt.Net toolset isn’t so much principle as it is context. A Fundamental Assumption Unfortunately, discussing...
And I’m okay. Indeed, last week saw a payoff for one of those hygiene things you do because you know that you “should”. A Logging Story Allow me to share what happened (feel free to skip this section). We receive orders from a number of different sources. In addition to EDI, we have spreadsheets, flat-files, and we even originate a few ourselves under Vendor Managed Inventory (VMI) agreements. One of the things we’ve done recently is create a single “process pipeline” such that once orders enter the pipeline, their processing from that point forward...
Your environment can have a profound effect on how you develop software. The details of what I discuss here have zero practical meaning outside of the .Net world (though you can probably find parallels in other environments). That’s because .Net developers have access to tools that invalidate rules of software design that are fundamentally important elsewhere (before you question whether an environment can effect what is good design, consider the difference between good design in C and, say, Prolog). For .Net, the free availability of a tool like Typemock makes a major design consideration simply disappear—namely, testability. Typemock literally...
Prior developers and others who should have known better at my company decided many years ago that our warehouse people simply could not do their jobs unless we unleashed the ability for them to use multiple "bin" locations for each item. Now, strictly speaking, this was not really the case, because our needs simply aren’t that complex. We manufacture reading glasses so we don’t need inventory aging and all the warehouse people really needed were different sites to separate receiving from QA from shipping. In other words, we have product staging, but each stage is physically as well as...
Anyone who has been forced to deal with EDI X12 documents knows that they are a royal pain. Each document has tons of fields—enough for any reasonable use for any reasonable organization. Having so many defined fields is actually its biggest liability. It means that every organization that uses EDI X12 pretty much has to decide what fields are significant for them. That means, for example, that an 850 document is functionally different for Nordstroms than it is for, say, Wal-Mart.
As a result, there’s a significant market for people who can map EDI documents. Most of them are service...
Bob Lee, creator of Google’s Guice project (the Dependency Injection framework for Java) has twice left comments here urging me to check out his talk introducing Guice. I resisted this because a) I don’t do Java and b) I figured I’d had enough with a later video recommended by Nate. This afternoon, I broke down and watched it and I’m glad that I did.
It turns out that the things that grated on me from the first Guice video I viewed came mainly from Kevin Bourillion—mostly unfair comparisons to alternatives and boosterism. Bob is very personable, open and seems honestly intent...
I can’t believe the potent response I’ve gotten on my posts about Dependency Injection. Ayende Rahien responded individually to each of my posts himself, which is more than a little bit intimidating all on its own and a couple of development heavyweights left comments directly. Nate describes Ayende’s posts as the cavalry arriving and links to a couple of other responses. All of these posts disagree with me, though a post by Aaron Jensen indicates that he’s at least willing to consider the possibilities.
All of this should have been foreseeable, really, as soon as I decided to publicly post...
When I go over the tools that I use for software development, it's not actually true (as a friend recently accused) that "if it isn't produced by Microsoft, Jacob won't use it." Still, while I don't hesitate to use tools not produced by Microsoft, there's no denying that the majority of what I use day-to-day has its origins in Redmond, Washington. The question Microsoft's detractors need to be asking themselves is why that might be the case.
It's Not the Hot and Cold Running Babes
Because here's the cold, hard truth: there's not a thing in it for me to continue using...
The trend towards increasing security introduces a number of intricacies for medium-sized business software shops using Active Directory Domains. An internal domain with more than a dozen workstations can introduce issues that are old hat for larger shops, but way beyond anything a small business will have to deal with. I ran into one such issue recently when I decided it'd be a cool thing for one of my apps to actually run from the network.
The Problem
The first sign I had a problem was when a module that worked fine locally threw a "System.Security.SecurityException" when run from a network share....