Skip to main content

From PHP to ASP.net - 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 choosing the open source route because the community was open and it was easy to learn via examples on the internet.
(Despite being long before Stack Overflow, one could have pretty decent luck with searches on PHP topics at the time.)

The reason I went that way was because much of the Microsoft philosophy back then was to hide knowledge behind courses, certifications and licenses.  To make matters worse, an even higher proportion of people in the community were dark matter developers!  I had no mentor, high schools were a few years away from becoming tech savvy and I was just a teenager trying to impress himself at home in a smaller prairie city.

From 1998 to 2016, the primary ecosystem I've coded with and had demonstrable results and experience with has been PHP.
That didn't mean however that I didn't stay curious about alternatives. I've toyed with Ruby, Python and Java at various stages or for school assignments.  JavaScript is obviously there and I even played a bit with Scala. PHP matured considerably as a language through the years and so did I with it, adopting new best practices and eventually frameworks.



Microsoft for the longest time has been subject to considerable derision because they just couldn't keep up with an economy of software that was literally free.  Their attitudes towards the people promoting and using their products was considered to be toxic and until Steve Ballmer resigned, there seemed to be no end in sight.
Only after almost 20 years do I think it's finally become safe to consider the things from out of Redmond lately.

I've landed a great local opportunity recently where I've been able to start developing 9-5 using C#.  Owing to the fact that I'm always keeping up with technologies outside of my comfort zone, it's a transition I've been able to make without too much upset.
It did however give me a thought that it would be neat to document the subtle differences between the technology, culture and approaches to problem solving.  At least so long as the observations remain interesting or useful.

I've got a few blog posts already lined up for this mini series, barring a few more edits.  I'll try to get them out in the next little while, but I'd like to leave you with one thought: For what it's worth, if ever you've been told to not put all your eggs in one basket, let me tell you: That is damned good advice when it comes to tech skills.

Popular posts from this blog

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…

The Cons, Winnipeg's New Splash Pads

I never had the chance to be ungrateful, the new splash pad at Kildare and Wabasha isn't a splash pad at all.  It was taken away from us and replaced with an "aquatic park", a little bit of wordsmithing designed to gloss over the fact that an open piece of our community has been replaced with yet another closed gate.

As I write this post now, I can hear it already: "Taken away, what?! It's a new water park, you're so..."
Sure, some might reach for that tired recrimination, which is why I started this blog post by dismissing such a premise.  To be fair however, I offer the response: Don't spoil this discussion with nonsense.
You see, I was grateful before the renovations happened.  The communal service on offer was adequate and I never complained about it or saw it as flawed.  Don't believe me? Here, this is a cute google-generated animation of my son enjoying the splash pad in 2014.

Today we took the kids to see if we could spend some time at th…

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…