Azure blob storage is an amazing service that lets you store massive amounts of unstructured data. Working with it can be pretty straightforward at first, but once you start needing better organization of your blobs things can get a bit tricky.
I see specialization on so many different levels. Specialization in a framework, a capability a product. It allows you to get up and running quickly when asked to work with what you are specialized in, but what happens when support for that product or framework is gone? In most cases companies tend not to move on or migrate from it because their employees are specialized and can't pick up new ideas or ways of doing things quickly.
When tasked with a project that included WordPress as the content management platform, I was a bit concerned as to what we would be able to accomplish. I moved on from WordPress a long time ago thinking that it would never be a developer friendly CMS system. Having come back to it years later it seems like a lot has changed and what I once thought was a subpar CMS system has turned itself into something that I believe can compete with other enterprise level solutions.
It's been a while since I've worked with a true monolithic CMS system like Drupal, but here I am again plugging away and trying to find the best way to work with it (or work around it). I took an absence from using coupled CMS systems for a lot of reasons, first and foremost was the hard dependencies on things like templating, databases and routing. What if I want to choose my database or if server side routing doesn't fulfill my expectations entirely? What if I don't want a denormalized database? As an architect these are all of the things I would love to be able to choose myself, or do I?
Git flow is the most widely used git branching strategy out there, it works... for the most part. It gets the job done, but what if we wanted to avoid planned releases, really switch to an agile methodology and be more productive? Then GitHub Flow is the strategy for you.
When setting up objects to be shared between the server and client, sometimes the size of them can get a bit out of hand. Normally I don't bother with setting up a fluent api to build objects, but in some cases it may be necessary to hide some of the complexity as well as make it easier to read. This post will show a simple example of how I have implemented it in the past.
In the past, I've generally set up one project as my data layer for not only NHibernate based projects, but other ORMs as well. This is fine for projects that have a moderate amount of domain models, but what if your data layer continues to grow? This post will help describe how to manage your data layer across different projects.
Nancy has a lightweight, low ceremony view engine built right in called the Super Simple View Engine. It has basic functionality that allows you to get the job done for simple sites, but what if you want to do a little more than the view engine offers? This is a good read if you want to know how to extend the SSVE.