While the .NET Core documentation and libraries do a good job of providing an easy way to get started with hosted apps (web or otherwise), it is somewhat lacking in terms of the same guidance for simple run-to-completion type console apps. You can write a simple Main() method and do your stuff, but how do you get the advantage of the amazing configuration and dependency injection that you get out of the box with hosted apps?
Even though AWS has been around for much longer, as is the norm for a lot of people coming from the .NET/Microsoft side of things, my cloud experience started with Azure. I got into AWS when I was a few years into Azure. I remember thinking at that point it would be nice to have something like this primer that would give me a very high-level introduction to AWS based on what I knew of Azure.
Recently, Go has seen a real uptick in popularity and adoption for a variety of different usages. It has been around for a while and has been continually improving. The purpose-built simplicity and extra focus on making concurrency easy and safe is part of it. The other part I like is the ease with which what you write becomes portable. These aspects especially make it a good fit to write infrastructure and tooling.
Since I wrote my initial post regarding Kubernetes and Service Fabric, a few things have happened:
Kubernetes had a chance to mature a lot more and also, needless to say, has sky-rocketed in adoption. Managed Kubernetes on the major cloud providers (AKS/EKS/GKE) has had a chance to mature a lot more. Adoption of Service Fabric is miniscule in comparison. Microsoft itself seems to be putting (wisely so) much of its firepower behind Kubernetes while Service Fabric sort-of just sits there on the side.
Even though Docker was built atop Linux containers and that is the majority of Docker usage out there, Windows Containers have been a thing for a while now. They went mainstream in 2016, and one hopes “ready for primetime” with Windows Server 2019. Even though integration with Docker is getting tighter, if you are in the unfortunate position of having to use Windows Containers with Kubernetes, you are going to have issues.
Recently, I came across having to install PKCS12 certificate bundles (i.e. a PFX file with the certificate and private key included, protected with a password) on a Docker container. This is standard fare on normal Windows machines or on PaaS systems such as Azure App Service. Doing this on a container, though, proved to be tricky (perhaps with good reason as I mention later) - so tricky that I ended up writing my own tool to do it.
.NET Core Global Tools are pretty neat. If you are targetting developers with the .NET Core SDK installed on their machines and need to ship CLI tools, your job is made immensely easier. It is just as easy as shipping a NuGet package. However, once you get used to building these things, it is easy to fall into the trap of treating this shipping mechanism as if it were Chocolatey (or apt-get, or yum, or what-have-you).
I set up CI and CD for two of my applications using Azure DevOps. It was quite easy. Setting up the build pipeline is as simple as including a YAML file in your source repository. It then just comes down to knowing how the build YAML schema works. As far as the release (or deployment) pipeline is concerned, though, I could not find a similar method. I had to set it up through the Azure DevOps UI.
UPDATE (Nov 13, 2019) My views on this have changed since I wrote this post. See this post for where I stand now.
Let us get Docker out of the way first. Microservices and containers are quite the hype these days. With hype comes misinformation and hysteria. A lot of people conflate the two (fortunately there are wise people out there to set us all straight). If you have done your due diligence and decided to go with microservices, you don’t have to go with containers.
Consider this another pitfall warning. If you are a frequent user of reader/writer locking (via the ReaderWriterLockSlim class) like I am, you will undoubtedly run into this situation. As more and more code we write these days are asynchronous with the use of async/await, it is easy to end up in the following situation (an oversimplification, but just imagine write locks in there as well):
async Task MyMethod() { ... myReaderWriterLockSlim.
For both React and for .NET Core (specifically ASP.NET Core and Entity Framework Core), I got sick of playing around with little prototypes and decided to build an application. Listor is my first proper application I have built using both these technologies. It is a simple list-maker application- nothing fancy. But I have been using it since I put it up and it has come in handy quite a bit.
Trying to get beyond just writing quick scripts here and there in F#, I went through functional design patterns targeted at building mainstream applications. Railway-oriented programming specifically stuck with me. I decided to try it along with some of the other core functional concepts such as projecting to other domains with map and bind operations. My first foray into this was applying it to, surprise, surprise, yet another quick script I had in place.
I have mentioned how part of our replatforming project that saw us move to Azure was moving the security protocol from WS-Federation/WS-Trust to OAuth2 and OpenID Connect. I kept running into rumblings on the internet about how even though it was widely adopted, OAuth2/OpenID Connect were somehow less secure. Comparing a secure implementation of both side by side, I did not really see how this could be. Since our industry is not short on oversimplification and grand proclamations, I decided to pose this question to experts in the field.
This is Part 2 of a two-part blog series:
Part 1 (Application- Services, Security and UI) Part 2 (this one; Database, Configuration, Logging, Caching, Service Bus, Emails, Tooling, Rollout) Database
We moved from our on-premises installation of SQL Server to the PaaS offering that is SQL on Azure. Other than the actual physical moving of the data, the additional challenge we had was that our system had a number of separate databases that were interconnected via synonyms.
This is Part 1 of a two-part blog series:
Part 1 (this one; Application- Services, Security and UI) Part 2 (Database, Configuration, Logging, Caching, Service Bus, Emails, Tooling, Rollout) It has been an action-packed year at work. We moved our entire platform in one fell swoop from on-premises to Azure PaaS (Platform as a Service). Since this was a big re-platforming effort that would incur regression testing across the entire set of applications, we took this opportunity to include a few technology upgrades in the process.
Having worked with Angular 1.x for some time and having liked it quite a lot (I guess that one we’re supposed to call AngularJS, and the new one is just Angular - yes, that is not confusing at all, is it?), I must say I was quite spooked when I first saw the documentation for the new Angular. It indeed is a completely different framework. There is no easy migration path from AngularJS short of a rewrite, at which point you might as well evaluate all your options including React.
I have always had a keen interest in functional programming. While I still shy away from going completely functional for full-blown applications, I try to use the tenets of functional programming as much as I can even when writing C#. This is made much easier by the fact that C# has borrowed a lot of functional programming features as it has evolved. With each new version of the language, I find my code getting more concise and more expressive mostly owing to these features.
Even though SAML and WS-* have started to be looked upon as the old guard of security protocols with the popularity of OAuth 2, they are not without their merits. For one, they are inherently more secure than OAuth (in fact, you need to rely on a separate underlying secure transport for OAuth to be considered secure- and if you are someone who believes SSL is broken, then OAuth is practically insecure).
Undoubtedly one of the biggest advantages that Git provides is using rebasing to maintain a clean commit history. I find that I am using it a lot these days- primarily in three modes:
As part of pull (i.e. git pull -rebase) Interactive rebase to: 1) keep my own history clean when I am off working on a branch by myself, and 2) clean up a feature branch’s commit history before merging it into the mainstream Rebase my branch against a more mainstream branch before I merge onto it (i.
Ideally, one should avoid data contracts with complex graphs- especially with repeated references and definitely ones with circular references. Those can make your payload explode on serialization. With repeated references, you may run into an integrity issue on deserialization. With circular references, the serialization will enter a recursive loop and you will probably run into a stack overflow.
Seeing that in certain situations, this becomes unavoidable, WCF has a way that you can tell it to preserve object references during serialization.
Using something like Bootstrap for a responsive UI covers most of the bases. But if you need more control, it’s a good idea to get familiar with Media Queries in CSS. It might come in handy some time, plus that is what Bootstrap uses under the hood as well, and it never hurts to learn how the tools you use work. The Mozilla page on media queries goes into just the right amount of detail and gives you a good outline of everything you can do with it.
For all its goodness, if something goes wrong, problems with MEF are terribly hard to diagnose. Thankfully, there’s an article out there by Daniel Plaisted at Microsoft that goes into great detail into all the things that can go wrong with MEF and how to get to the bottom of each one. I have it bookmarked, and if you work a lot with MEF, you should too. The one area that I find most useful, though, is figuring out composition-time errors using tracing.
You can find a good primer on domain events in this post by Udi Dahan. There are some issues with his approach, though that Jimmy Bogard raises and addresses in his post. However, I was left with two questions:
Shouldn’t the domain event be dispatched/handled only when the transaction or the unit-of-work commits? Because whatever changes have been made to the state of the domain isn’t really permanent until that happens.
There is a lot of discussion online around whether DDD and SOA can co-exist, and if so, what that looks like. I am of the opinion that they can co-exist and have arrived at a model that seems to work for me. Consider a complex DDD system with several bounded contexts and contrast it to an SOA system - and I am including the flavor of SOA that I describe in this post.
When you adopt service oriented architecture (SOA), the most important aspect of your architecture and high-level design step when building a new system is obviously decomposition of the system into the right services. A prudent way to decompose a system into services is to first identity what parts of the system is more likely to change more frequently. Thus, you decompose by volatility and set up dependencies such that you always have more volatile services calling less volatile services.
Domain driven design has been around for quite a while. I believe the definitive book on it by Eric Evans came out first in 2004. For whatever reason, I had not been exposed to it in places I worked. I had been hearing about it for enough time and from enough smart people to give it a try. I researched it online a bit and went through quite a few articles.
When I am in my healthy and fit zone, I get a lot done. It is quite clear there is no big secret to keeping fit - you exercise and you eat well. To that end, few would disagree that oatmeal is as healthy as they come when it comes to breakfast foods. Few would also disagree that making rolled oats is not a fun activity and eating rolled oats even less so.
If you have adopted service oriented architecture (SOA) and are using WCF as the hosting/communication mechanism for your internal services, chances are you are doing one of two things: you publish each service like any old WCF service and your other services which are consumers of said published service consume it through its WSDL; or you create shared libraries that include the contract information that both the service and its consumer reference.
As much as I raved about TypeScript in this post from some time ago, sadly the time has come for me to part with it - at least for now. It is a beautiful piece of work by a beyond-brilliant group of people. As I worked more and more with JavaScript the past year, though, I realized a few things.
The first, and this I already mentioned in my previous post, is that it is still maturing and is not quite there yet.
We’ll look at a relatively low hanging fruit in case you’re working with vanilla AngularJS and Twitter Bootstrap and are not relying on other add-ons such as AngularUI’s Bootstrap extension. One common need I have is to be able to show or hide Bootstrap modals based on a property on my view-model. Here’s a simplified view of the controller:
var app = angular.module('app', ...); ... app.controller('ctrl', function ($scope, ...) { .
This is the last in a short series of posts on writing your own LINQ provider. A quick outline of the series:
A primer Provider basics A simple, pointless solution A tiny ORM of our own (this post) A tiny ORM of our own In the previous post, we took a look at a simple, albeit pointless example of a LINQ provider. We wrap the series up this time by looking at something a little less pointless - a LINQ-based ORM, albeit a very rudimentary one.
This is the third in a short series of posts on writing your own LINQ provider. A quick outline of the series:
A primer Provider basics A simple, pointless solution (this post) A tiny ORM of our own A simple, pointless solution In the previous post, we took a look at what happens when you call LINQ methods on IQueryable<T>, and how you can use that to build your own provider.
This is the second in a short series of posts on writing your own LINQ provider. A quick outline of the series:
A primer Provider basics (this post) A simple, pointless solution A tiny ORM of our own Provider Basics In the previous post, we took a look at the two flavors of LINQ methods, i.e. the methods and classes around IEnumerable<T> and the methods and classes around IQueryable<T>. In this post, we expand upon what happens when you call LINQ methods on IQueryable<T>, and how you can use that to build your own provider.
This is the first in a short series of posts on writing your own LINQ provider. While LINQ is the best thing that ever happened to .NET, and using it is so much fun and makes life so much easier, writing your own LINQ provider is “complicated” to say the least (context- the LINQ interface to NHibernate, RavenDB or Lucene - those are all providers).
A quick outline of the series:
I just find AngularJS directives so much fun. It is so satisfying to see them work. Recently, I came across a requirement where I had a text field bound to a property that could either be a date or text. I had a way of knowing which one it was, but if the property was a date, the text field would need to become a datepicker, and turn back into a normal text field if not.
Ever since the introduction of LINQ, people have been trying all sorts of clever ways to get more functional constructs into C# to wrap away certain annoying procedural details that are part of the language because of its non-functional beginnings. One of the most annoying class of operations in this context are the TryX methods (e.g. TryGetValue, TryParse and so on) that use out parameters and force you to break into statements what is otherwise a fluent sequence of calls.
TL;DR
The CodeDOM is a cool library within .NET that can be used for structured code generation and compilation. When combined with Reflection, one neat application is to be able to inject aspects into your code at run-time. I have created Aspects for .NET, a library that does just that, and also tries to bring AOP to MEF.
Whether it be generating boilerplate, generating proxy classes or processing DSL, code generation has numerous applications.
Quite often people turn to the lock statement when protecting access to shared resources from multiple threads. A lot of times, though, this is too big of a hammer. This is because to maintain the integrity of the lock, any access of the protected resource, be it simply accessing its value or modifying it, needs to be done within the lock. This means even concurrent reads get serialized. A lot of times, what you need is for concurrent reads to be possible as long as they read a consistent value, while writes are serialized.
For some odd reason out of the blue, I got this hankering to build a message queue (albeit rudimentary - hence the name) from scratch. I’ve been working with MSMQ for a while now, mostly as a transport for WCF. As cool as it is, it can really get on your nerves at times. It is an enterprise grade product, after all, which means there are a lot of dials you can turn.
I have been hearing about responsive design on and off for some time now, and it has always appealed to me as a pattern to follow for web-based user interfaces. CSS3 is obviously quite powerful and media queries provide a relatively easy way to build one unified UI that looks great on PCs, but then adapts and shape-shifts accordingly when viewed on a smartphone or tablet without having to completely re-implement a “mobile site” as so many do today.
Within the context of software development, the phrase “rolling your own” usually has a bad smell attached to it. Most of the time, this is with good reason. If you are building a fairly complex system for a business and there is ROI at stake, it surely makes sense to at least assess what is readily available in the industry and is used and thus “certified” by the community for certain components before jumping in and building it oneself (however fun that may be).
UPDATE (2015/1/7)
This application has been re-written from scratch using some new stuff I learned. The new application is called CHORE. Understandably, the links to the application and source code as mentioned in the original post don’t work anymore. I did not update them as I want the original post to stand as is. Here, however, are relevant links to the new application:
The application is hosted here.
The source code can be found here.
A bunch of things I’ve been working on and have blogged about have culminated into an actual application that uses all of it. Finance Manager is a SPA web application I built for my own use to keep track of my finances. This application allows me to create periodic budgets and record all my transactions. I can then look at my budgeted versus actual amounts based on those transactions. This was already something I was doing with Excel spreadsheet.
UPDATE (2015/01/10)
There have been changes in my thoughts about how one should go about this. Consequently, I have abandoned the modeling library that I speak of in this blog post. Understandably, the link to which that points no longer works.
I absolutely loathe writing repetitive code. That is what machines are for. My philosophy therefore is to try to generate as much of these kinds of code as possible.
After having recently used this combination, I am in love with it. For those unfamiliar with any of these, here are quick one liners:
TypeScript is a JavaScript superset from Microsoft that compiles down to JavaScript and adds static typing and other neat features like classes and what not. It is worth mentioning that none other than Anders Hejlsberg (the father of C#) was involved in its development.
AngularJS is a JavaScript framework geared towards building rich and testable single-page applications.
A blog series on my Commons Library would not be complete without mentioning all the providers that go with it. The Commons Library, by itself, gives you a framework, some common functionality and a bunch of contracts. To get actual functionality out of it, providers need to be built that implement those contracts. The Commons Library does contain a bunch of built-in providers as well. These built-in providers are ones that do not have any third-party dependency other than the .
The data access block in the Commons Library is based on the Unit of Work and Repository patterns - or at least my take on them.
Unit of Work You start with a unit-of-work factory (which is an implementation if IUnitOfWorkFactory) and call Create on it to get an instance of IUnitOfWork which is also IDisposable. So, you get a unit-of-work and do your business inside a using block, and call Commit before you leave the block.
My major goals when building the logging block for the Commons Library were to keep the logging interface simple (just tell me what level, I will give you the message to log - don’t make me think too much), be able to log to multiple places (i.e. logging providers), and for the logging operation itself to be asynchronous (i.e. the only latency any logging should add is a memory operation).
When working on the configuration block in the Commons Library, I started out wanting to decouple the storage of configuration data and the format of that data from the actual configuration interface used by consumers to retrieve that data. I wanted consumers to be able to simply look up configuration data through a dictionary-style interface while the job of parsing the original format would be done by a configuration formatting provider and the job of getting that data from wherever would be done by a configuration store provider.
While building the composition/DI piece for the Commons Library, one problem I ran into was the fact that if you told MEF to load assemblies from a number of different places - and they all had copies of the same library (which is possible especially with common dependencies), MEF would load the exports in each assembly as many times as it finds it. What you end up with then is a whole bunch of matching exports for a contract that you expect only one of.
In the first of a series of blogs around my Commons Library, I want to shed more light on my choice of MEF as the underlying mechanism for the AK.Commons.Composition namespace - which handles dependency injection as well as extensibility or plugin type stuff. I like its attribute based syntax, choice of different types of catalogs and dynamic discovery (and yes, I am not using dynamic discovery just yet but I intend to; the same goes for taking advantage of different types of catalogs).
A commons library is something I’ve always tried to maintain. The idea is you have something of your own that handles (or at least provides a way to handle) common cross-cutting concerns in all applications that you build. This includes areas such as configuration, logging, security, error handling, data access, dependency injection and caching to name a few. As long as it is kept up to date, it is also a good way to keep up to date with new technologies in these areas.
I just ran into some presentation material from a Node.js introduction presentation I had done in a session that shall remain unnamed. I thought it would be a good idea to put it out there in case someone is starting out with Node, should they stumble on here. So, here it is.
To quote Wikipedia:
A software system designed for writing scalable internet applications, notably web servers. Programs are written in JavaScript, using event-driven, asynchronous I/O to minimize overhead and maximize scalability.
Both the .NET framework and Java are garbage-collected systems. This means that when you instantiate objects, the framework keeps track of how the object is being referenced, and automatically frees up memory used by the object when it is no longer referenced by anything and is “out of scope”. This works beautifully with objects that are part of the framework. In .NET lingo, these are called “managed resources”. However, a lot of times, a .
PASS (Professional Association for SQL Server) is “an independent, user-led, not-for-profit organization co-founded by Microsoft and CA in 1999. PASS Summit is the world’s largest, most-focused, and most-intensive conference for Microsoft SQL Server and BI professionals.” (Source: the PASS website at sqlpass.org). The summit is held every year in Seattle. This year, the summit was held from October 11 to October 14 and focused on the upcoming RTM launch of SQL Server Denali, now re-branded as SQL Server 2012.
I was running as fast as I could, but the yak kept gaining on me. All of a sudden, I found myself in my lodge room. I jumped on the bed, only to discover to my horror that the yak had made it to the room as well. With all its fury, the yak jumped on me. That is when I woke up from the vivid nightmare with cold sweat all over my body.