Skip to main content


Building .NET Core Nuget Packages

My last blog post was on building and publishing npm packages, specifically for typescript projects. In my opinion, packages are an important fundamental unit in software development. They sit at the confluence of technical competence and collaboration, and represent something the software community should be proud of.
Most of the time, you're going to be creating software packages once you're comfortable with some essential pillars: CodingProject structureSoftware architectureBuildingDeliveryCommunityLicensing
After I got my npm package up and running, my next task was to do the same thing with my C# libraries. Similar to protoculture, I have made a library called praxis.  This is done by leveraging the services and tooling known in the .NET ecosystem as nuget.

In this case, praxis abstracts many of the concepts and functionality I require when producing server projects. It builds on top of ASP.NET Core, so in that sense you can almost think of it as a framework-framework. The…
Recent posts

Making TypeScript npm Packages

If you've landed here, I can only assume you're like me and see packages as the highest form of sophistication in software development.  In that same vein, I bet at some point in the past you've wished you could start applying DRY principles to your client-side efforts.  I know for myself, I don't enjoy writing the same application bootstrap code constantly and so recently, I was motivated to codify it.

This body of understanding has taken me quite some while to figure out, hopefully what I share here is helpful enough to get you up to speed.  No post is complete without some kind of example, so throughout I'm going to reference a package I've just finished putting together called protoculture.

Briefly described, protoculture encapsulates all the common bootstrap and conventions I've been using while developing TypeScript apps that use React and Redux.  Honestly, I've already gotten a lot of benefit out of putting this package together, but nothing about…

Hey look, a tech company from Winnipeg on TV!

My wife likes to catch up on her Dragon's Den and it makes for pretty good background listening while I study in the next room. The episode she was watching tonight featured an app called musi made by some local Winnipeg talent.  Cool, right?!

Not quite.
On the TV As I started to tune in, I heard the most important question get asked which was how they sourced their content.  The presentation could have ended after that question was answered.  It was all I needed to know to put together a guess in my head as to what they were doing.  With my skepticism locked in, I paused what I was working on to watch the rest, hoping that at least one of the dragons could pick up on the warning signs I - as a developer - was hearing.

Right away, numbers of downloads predictably made an appearance.  Nothing about active user base.  Then the amount of time spent developing and cost to operate came up.  Only $25 dollars for a single server and everyone was just blown away - who are these geniuses?


From PHP to - Tooling & Workflows

Probably the first thing to be remarked when coming from any environment to .net is going to be the tightly integrated tooling.

When I used to do PHP in the late 90s early 00s, it was pretty much whatever text editor I could get my hands on.  There were some non-free IDEs, but none that were easily obtained or as impressive as Visual Studio, which also wasn't free until around 2006.

Despite the differences though, Visual Studio has always been first class.  When the same people making the languages are also making the tools, you can expect a lot of extra convenience.  One thing that's kept my interest is that despite the tight coupling, most everything is still quite generalized, unlike 4GL environments like Delphi.
Contrast .net with PHP where all you get the language and are responsible for building your stack upwards from there.  Not that our favourite friends LAMP and LEPP aren't just as mature.  Things like PHPstorm have come along to give that first class feeling but…

From PHP to - Introduction

My first real successes with server programming were back in 1998 when I started tinkering with PHP.  Back then, ASP was at version 2.0 and was - similar to PHP - a way to mix markup and scripting.  Both tended to yield some fairly interesting results and I'd say for the most part, both were quite comparable.

As such, even back then I had a choice.  I could focus my tinkering on the Microsoft based tools, or I could try my hand at this thing called open source I'd been hearing about. I had everything I needed to succeed in both spaces. I could either download everything for free or I had complete access to a set of MSDN discs in a binder with a cover like this:

If I wanted to build ASP scripts that spoke to Access or SQL databases, it wouldn't have been a problem.  In some ways, I even tried, installing all the tools and trying out the environments. Each time however, I abandoned the effort because I felt like I couldn't tinker my way into it.
So, Instead I ended up ch…

Integrating third party templates with your front end build system

I'm not by definition a front end developer, although because I do back end development, things like program structure and build systems are interesting to me regardless of whether they target servers or browsers.  So while I can't make something look pretty, I still enjoy managing the complexity of JavaScript/ES transpiled apps.

This is a seemingly trivial post in an area that I feel doesn't get enough attention sometimes.

We recently purchased and started using a premade template for some minor projects at work.  It actually looks quite nice, has a responsive layout and isn't too terrible.  My usual complaints of "too much markup" and "lots of busy spaghetti scripting" still hold true, but most of this seems to be quite fire-and-forget.

I ended up not being involved with the first few integrations of the template and while overall it ended up working, any trained eye could see where some of the cut lines were missed.

I had resolved that for the ne…

Programming: It's about how interested you are.

Had this tweet show up in my feed this morning and I think it's worth an explicit mention.  Eric Evans talks a bit about Domain Driven Design, a topic he's also not coincidentally published a book on many years ago:
Watch @ericevans0' talk from #DDDEU 2016: "Tackling Complexity in the Heart of Software" — DDD Europe 2017 (@ddd_eu) April 11, 2016 Something I've been encountering in my travels as a developer and leader of developers is the varying levels of motivation, confidence and enthusiasm my peers conduct themselves with.  At one point during his talk, Eric speaks about how a hypothetical carpenter spends more time talking about his output than he does how he might use any particular tool.
Eric also - in my opinion - correctly highlights that the best people in the industry tend to be master technologists.  They constantly have their head in the space and are naturally disposed to aspects of technology an…