I ran across an interesting scenario at work today that I think merits some discussion. In this post, I’ll cover what DRY is, and when following it religiously may actually cause problems.
Continue reading “Extreme DRYness”
Advertisements
Category code maintenance
Hide Your Secrets
In the last post we discussed why it could be preferred to expose all of your methods publicly. However, I deliberately left something out. Some of you may have noticed. Continue reading “Hide Your Secrets”
An Interface By Any Other Name
We’re going to take a brief break from our series on plug-ins to explore an idea that I had regarding naming conventions, specifically interface naming in .Net. Continue reading “An Interface By Any Other Name”
How to Version Assemblies Destined for Nuget
Okay. Seriously. Versioning of third-party Nuget packages has been the bane of my existence for the past week. Nuget declares that packages under its system should follow Sematic Versioning, and that’s great… for the package. But it becomes a problem when the same versioning scheme is followed for the assembly. Continue reading “How to Version Assemblies Destined for Nuget”
Architecture Always Applies
I recently ran into an issue with Nuget packages. At work, we have a private Nuget repository for code that we’d like to share across applications. It’s mostly common frameworks, like configuration and logging.
Continue reading “Architecture Always Applies”
WPF Miller Columns, Part 2
Last time, I walked through an implementation of Miller Columns in WPF that I had posted on StackOverflow, but it ended with a few issues.
- It was incomplete. I didn’t post the entire implementation, and much of the context was lost between then and now.
- The implementation wasn’t very MVVM. It required a specific type to be used as a data context, whereas in MVVM proper, the view model should be completely decoupled from the view.
- The solution required a code behind. This isn’t necessarily a bad thing, but I’d like to see if we can develop a pure-XAML solution.
Microsoft Did It Wrong
It’s been several years since Microsoft announced that Newtonsoft’s Json.Net would be the default JSON serializer. If you deal with JSON communication over the web at all, you probably already know this. It’s not exactly news.
However, there does seem to be a small desire among those in the web development community who would like to use alternate serializers. Personally, I’d like to use my own serializer, Manatee.Json. I originally created it out of a dissatisfaction with Json.Net, and naturally (and perhaps from some bias) think it to be superior.
