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.

Comments

Popular posts from this blog

Laravel Project Architecture: The Missing Guide

At my job, we've been doing a lot of learning and development using Taylor Otwell 's Laravel 4 PHP framework.  As we've become more familiar with it, we've had to come up with better ways to structure our projects outside of what the documentation indicates and the default distribution that is provided. If you've been working with Laravel 4 for any amount of time or come with experience from another framework and are just getting started, you've probably noticed that there are a lot of different ways to cut up your projects. Choice is nice, but sometimes it can be paralysing or misleading. Concrete Advice This post is done in such a way that you can just skim the headings, but if you want a detailed explanation in each section, feel free to read in where necessary. While I can't say the entirety of my advice is in practice throughout the community, I can say that we are starting to use it, and to very good effect at my job.  Especially consider...

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: Coding Project structure Software architecture Building Delivery Community Licensing 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 ...

Laravel is Good, Facades Aren't

I've been working on some Laravel 4 based packages lately which inevitably results in me also looking at other packages. I've noticed sometimes that people use facades at times that give me pause. The most troubling being from inside their model classes. A quick google turned up this video which assures people "there's still an instance behind everything, we're fine" .  Everything mentioned in the video is true except that there is a very glaring omission. Scope What usually goes out the door at the start of a long series of mishaps in software design is scope . When the desire to obtain a solution is stronger than the desire to consider the implications of a firm approach, mistakes are sure to follow.  Sacrifices like this are made due to the assumption of a high cost to developing carefully. What really is happening however is a false dilemma , being responded to with a convenience decision . It's very easy to write model code like ...