Discussion of Software Architecture and Development with programming focused on C# and Microsoft .NET.
I’ll mostly be posting about software architecture & development since that’s what I know best. There will also be some posts about IT, the cloud, the Internet and similar stuff. Occasionally I may toss in a piece of trivia or a quote. If you have thoughts, ideas or questions please leave a comment!
Comments closedHaven’t posted recently because I started a new job doing Clojure development on Mac targeting JVM on Linux hosted in AWS. In other words mostly stuff I haven’t done before so I’ve been focusing a lot of time getting up to speed on all of that (which is still a work in progress).
I am still actively working on my open source Layers library for .NET and have made considerable progress. Since its still alpha its been going through a lot of change / refactoring as I work to get it to where I want for moving forward. Most of the core layers capabilities are implemented (though not tested). Next I need to write a top layer implementation (such as .NET Core MVC WebAPI) and a bottom layer (such as Entity Framework) so that I can feed incoming requests into the layers stack and have them perform actual work. Once I have those I can start testing and working with it from an application perspective and go from there.
Due to the new Clojure work and the time that is taking it will likely take me longer than I had planned to get a working version of Layers released, but it will definitely happen. Plus I’ve also created some simply, very high level “Common” open source libraries for .NET as part of this that I think will be highly reusable for a lot of projects.
Leave a CommentHigh quality security is a good thing. Many years ago (early 90s) Phil Zimmermann released this thing called Pretty Good Privacy (PGP) that used public & private keys to enable people to sign & encrypt data. Its a really good core design and very high security. When it came out I wrote an early Windows GUI to try and make it easier for most users and exchanged a couple of emails with Mr. Zimmermann. But unfortunately PGP never caught on because it was complicated to use and requires building a network of trusted keys (so that you know who a key really belongs to).
I just recently found out about Keybase.io which is a system that provides secure chat & file sharing and uses PGP at its core. It also acts as a system for distributing keys and providing the identity of those keys. I’ve only played around on it for a little bit but it seems like this might finally be a good, viable way to enable widespread use of PGP!
Leave a CommentDependency Injection (DI) helps to enable Inversion of Control (IoC), but DI itself is not IoC because truly moving the locus of control outward requires an architecture that wraps and invokes the DI. An example of this would be ASP.NET MVC which uses DI to instantiate the controllers and other objects needed to process web requests. That is IoC, but the libraries that implement DI (“containers”) are not themselves IoC containers they are DI containers. Calling them IoC containers is inaccurate.
Leave a CommentI am not a fanboy. I don’t get excited about upcoming games. But OMG I’ve been following CyberPunk 2077 for awhile and it now has a release date! April 2020! For the first time ever I think I’m going to have to pre-order a Collector’s Edition game!
I’ll explain. Way, way, way back in college (in the 1090s) I got introduced to the CyberPunk RPG and I loved it. Then the CyberPunk 2020 edition came out and it was even better. I played RPGs when I was young but nothing ever captivated me as much as CyberPunk. I even loved the novels set in the genre (it is stil, to this day, my favorite genre for books & movies).
I don’t play games all that often but The Witcher III from CD Projekt Red was one of the best I ever played. Then I found out that their next title would be CyberPunk 2077. They are basing it on the CyberPunk 2020 RPG and they have the author of that game on staff helping them develop it! I have never in my life been this interested in a video game.
And then I was watching the latest trailer / video of the game and it was just as awesome as the ones I had seen before. Right up to the point that Kenu Reves shows up in the video right at the end as a character! Have you ever seen Johnny Mnomonic?
So this is what it feels like to be a fanboy. For this, I’m okay with it.
https://www.cyberpunk.net/us/en/
Leave a CommentDevelopers keep referring to Service Locator as an anti-pattern. If that is the case then ASP.NET MVC and every IoC container I’ve ever seen must be wrong because they use it.
The interface for accessing an IoC container is an implementation of the Service Locator pattern. You’re asking for some particular interface (aka a service) and its giving you back an instance (if it can).
Under the hood ASP.NET MVC uses a service locator (which almost always happens to be an IoC container) to new-up Controllers for handling incoming HTTP requests.
Service Locators can certainly be used incorrectly or where they should not, but they are not an anti-pattern. They are a specific tool in what should be an immense toolbox for solving certain types of problems. Sometimes they are the best choice. Sometimes they are a terrible choice. But the pattern itself is not at fault.
For more read Service Locator vs Dependency-Injection which goes into more detail and is also a very fun read. I’d mention the author’s name, but I can’t seen to find a name associated with the blog.
Leave a CommentI’ve just pushed a new version of the Original Coder Libraries up to GitHub that includes the first draft of the Layers library and architecture.
The libraries are hosted on GitHub: The Original Coder Libraries
This push includes the first version of the Layers architectural library I’ve been working on. It is based on similar architectures I’ve used on a few different projects in the past which proved to be very helpful. From a features and maturity standpoint this could probably be considered the 3rd incarnation (once they are completed, still in alpha).
The library makes it incredibly easy and efficient to build software systems using layers. Especially systems that deal with data that need CRUD (Create, Read, Update and Delete) operations. Using the library it will be possible to implement a full set of CRUD endpoints for a resource (an entity / database table / or the like) in about 100 lines of code.
I’ve included a project named LayerApiMockup that provides an example of what setting up and implementing will be like with the library. It still needs a bit of work and I need to add the add-on libraries for implementing specific technologies (Entity Framework, ASP.NET MVC, etc) but this is a good start.
1 CommentI literally almost fell out of my chair laughing during the first part of this.
The case of the 500 -mile emaill
A long time ago I worked as a UNIX, Linux and network administrator. I’ve had to figure out some very odd networking issues and have also rewritten a sendmail.cf file from scratch. So maybe that’s partially why I found this story to be so very amusing.
Credit where credit is due, I came across this on Reddit:
Card Card Leave a CommentThe S.O.L.I.D. principals didn’t exist when I was learning to program and by the time I had heard of them I had been working at a senior level for years. Once I heard about them I had a quick look, thought they were all pretty obvious and paid no more attention.
Let me clarify that. The principals that make up S.O.L.I.D. are pretty basic stuff. Junior developers will get them wrong all the time. Mid-level developers will mostly get them right but will still make mistakes. By the time a developer starts to transition into a senior role they should always be applying these sorts of basic principals correctly and mostly automatically. A developer who has been working at the senior level for a few years should never even need to think about such things consciously.
Just like people don’t consciously think about how to walk/run, how to use punctuation when writing or how to park their car after they have been doing any of those for a few years. Experienced authors and drivers don’t think about any of the basics of doing those tasks. Which is why people can commute from home to work and not even be able to remember the drive. For this same reason the S.O.L.I.D. principals should be being applied at a subconscious level by senior developers.
Which just recently has become a pain for me. Now that S.O.L.I.D. is all the rage every interviewer seems compelled to drill developers on all of the details. Try to remember all of the low-level spelling and grammar rules you use when writing. If you’ve been out of school for at least a few years I bet you can’t remember most, if any, of them. You don’t need to anymore, just like I haven’t needed to think on such a basic level for years when programming. Those basic principals are automatic and forcing them back into the conscious level isn’t a benefit and doesn’t improve anything.
Interviews just a couple/few years ago weren’t asking such basic questions during senior level interviews. These types of basic interviewing questions are not going to land good senior developers. Someone who is book smart or spent time cramming before the interview could answer those even if they weren’t a developer. But the more in depth questions that can’t be crammed for and require real (senior level) experience not just book learning aren’t getting asked as often (or at all) during senior level interviews now.
Leave a CommentI’ve created the Original-Coder-Libraries repository on GitHub and uploaded some source code to get things started! They are licensed under the GNU LGPL v3.
The libraries currently contain approximately 3,500 lines of C# according to code metrics. This is a tiny fraction of what I have in my personal libraries and I’ll be adding more in the future.
Repository: https://github.com/TheOriginalCoder/Original-Coder-Libraries
Leave a CommentThe 5 principals which make this up were bundled together as the S.O.L.I.D. principals in the early 2000s. These describe basic concepts that are required to write good code. So it is very important for novice, junior and mid-level programmers to put real thought into these and get good at applying the concepts correctly and consistently. The better a programmer gets at these the less time they should need to spend thinking about them.
As I mentioned these are very important basic programming concepts that need to be learned, mastered and (eventually) internalized by software engineers. But I personally think the language often used to define and explain the underlying concepts is a bit cryptic or overly complex. Below is my attempt at conveying these concepts.
Don’t mix multiple (especially unrelated) capabilities / functionalities together in one class. Make separate, more narrowly defined classes for each distinct capability. Classes that have a more defined / narrow purpose are easier to learn, apply, maintain and also reuse. Note that this applies to any division of code (methods, classes, interfaces, modules, libraries, etc).
Great concept, not so great name.
Once functionality has been crated and is in use don’t modify it in a way that would break existing code! At the same time there should also be a way to extend or alter the behavior of the previously written code (without rewriting or copy/paste) that won’t break code that uses it.
A good way to do this is through the use of abstract base classes and inheritance. The core functionality for performing a task should be written into a base class. A concrete descendant class will inherit that functionality and allow it to be used. That concrete class should not be changed in a way that breaks existing once in use. But new concrete classes and possibly a new level of abstract class can be added that extends or changes the functionality without impacting existing concrete classes.
A rather complicated way of defining a good concept.
Descendant classes should not break either the explicit nor implicit contract of the parent class. Descendant classes should be implemented in a manner that allows them to be dropped in as replacements to the parent class without requiring any code that expects the parent class to be changed. The key here is that it is more than just signature level compatibility (list of methods, parameters, and types). The expected behavior must also remain the same!
Note that this isn’t limited to classes. This concept should be applied anyplace where substitution is allowed by the programming language or system. Which means this also applies to interfaces. This would also apply to multiple DLLs that expose the same method signatures (which is sometimes used to implement plug-ins or extensions). Anyplace substitution is possible care should be taken to ensure the behaviors are consistent.
This is the same general concept that underlies the Single Responsibility Principal but applied specifically to interfaces. Its the same underlying concept, it doesn’t need 2 separate principals.
This is the least obvious of the bunch, possibly because this way of thinking and the frameworks / technologies needed to support it are more recent. Or maybe because this principal is emergent and not stand alone; It becomes possible due to other principals.
The idea here is that classes which require instances of other classes (or interfaces) to perform their work should not instantiate specific concrete implementations within their code. This has the effect of embedding the decision as to which concrete implementation to use in a place where it is difficult to change. This also typically results in these choices being embedded in many different places throughout a software system.
The concept behind the Open/Close principal encourages inheritance and abstractions. The concept behind the Liskov principal states that all implementations of something that allows substitution (such as classes and interfaces) must be interchangeable. If we’re applying both of those concepts consistently its a shame to make substitutions difficult by hard-coding and embedding those decisions all over the place in the code.
Bingo! And that’s why Dependency Inversion sprung up. To standardize and centralize the ability to use substitution in a software system.
Currently the most common preference for implementing this capability is the Dependency Injection pattern where concrete instances are passed into a class via its constructor. But that is not the only option, any pattern that extracts and centralizes these decisions could be used. One such alternative is the Service Locator pattern which, in some cases, can be preferable to Dependency Injection.
It is worth noting that the Dependency Inversion principal is the only one of the bunch that isn’t universally applicable. Not all applications need DI. I would likely argue that all large or complex systems probably should use it. But small systems or one-offs that aren’t expecting to be maintained probably don’t.
Leave a Comment