Ends and means

Old quest

You might say my Linux quest failed miserably. I got defeated in the land of unexplained instructions and fairyland errors that had no right to exist.

But, you would be wrong. Using Linux as a platform for a website never was a real goal. It was a means to an end. And means can change while the end stays the same. In my case the end was learning. Mixed with a bit of nostalgia from times when running a site on Linux could have been an end, but would have been a means as well. (That is, a means towards cutting costs except that probably it would have meant incurring quite a steep learning bill far exceeding the price of the license fee saved.)

As learning was the end and getting an ASP.NET5 site running on a Linux shared hosting account was just the means, the quest was a success. I learned a ton.

Apart from the solutions to the problems encountered, which are always nice little conquests, I learned, perhaps again, that I am not cut out to work with Linux or any other OS or application from the land of unexplained instructions. At least, not just to satisfy my curiosity. I like a challenge and I’d happily have continued the quest if I had really needed to do something with Linux. Right now, I’d rather delve into ASP.NET 5 itself than wrestle with the ring in which it is running.

Don’t get me wrong. I like getting out of my comfort zone. That’s a huge part of my “Learner” make up. The point is that I have plenty of more pleasurable ways to get out of my comfort zone.

Sooooo… back to safety (ha!). Back to Windows and learning ASP.NET 5 and MVC 6 in their native wrestling ring.

New quest

ASP.NET 5 and MVC 6 being the subject to learn, it stands to reason that we will be building a web application and who knows, one with its own WebAPI to boot.

First steps:

• Get the ASP.NET 5 samples running on an Azure Windows VM
• Get the bare bones web site created for the Linux quest running on that as well
• Set up the infrastructure for easy deployment of new versions.

After that, it’s a free for all. Any feature is fair game. That said, I do intend to follow a specific structure. Given a feature to build:

• Is shopping the shelf an option, or perhaps even a “must”?
• What software design alternatives do we have and why choose one over the other?
• What contraints do the design of ASP.NET 5 and MVC 6 put on our design?
• Then “just do it”

So, what features is the quest’s application going to have? What is it going to be about? What is it going to need? Both in terms of “core application functionality” and in terms of “basics you just gotta have”?

What are the questions and challenges people face when they are starting out building a web application?

Couple of things come to mind immediately:

• Signing in. What’s the use of a web application if you can’t distinguish amongst your users?
• Billing. I don’t know about you, but personally I’d like to create something that maybe one day I can apply to build me something I can live off. So, yes, billing.
• Notifications. People don’t like having to log in just to see nothing happened while they were away. So let’s be kind and tell them when something interesting (to them!) happened on the site.
• Direct messaging. Users can send each other messages through our web application ensuring they can keep their contact details private and still interact with other users.
• Q&A StackOverflow style (but with less pompousness about what fits their Q&A format).

What else would be worth digging into?
What order should we address them?
Would you be interested in contrasting ASP.NET 5 / MVC 6 with previous versions? Or would you rather just forget about those?

__Please let me know in the comments.__ Apart from the first steps of the quest, I am not particularly fussed about priorities, so let me know and I’ll adapt.

One constraint I am going to put on all this, is: don’t code anything that isn’t core functionality of your application.

For example, when you are building a SaaS enabling self-employed people to bill their clients, then billing would be both “core” (your users billing their clients) and “just gotta have” (you billing your users). In the first case you want total control over what it does and how it does it as that is how you distinguish your application from the gazillion other billing applications. In the second case billing is just something “you gotta do”, and what you need to do to get the bills to your users is not part of their user experience. So shopping the shelf and just coding the integration of your application with a third party service probably has a much higher ROI. After all, even though we are of course capable of doing a better job of it ourselves, we can only spent our time once and spending our time on stuff that provides value for our users is much to be preferred.

If you don’t want to miss any of my future adventures: subscribe below and get every post delivered straight into your inbox.