Blog Moved

My blog has moved!

Friday, February 27, 2015

Diving Platform! A Description of Platform as a Service in Microsoft Azure

I've talked about Microsoft Azure before on this blog.  Mainly from the perspective of startups.  For those who haven't read the previous posts, I recommend you do (of course I do right).  But for just a quick high level 1000 foot view.  Azure is a cloud platform provided by Microsoft, to provide affordable and stable cloud hosting and services to clients.  

So as a developer the question is, "Why do you care?"  And the short answer is a simple one "because its the future".  Now I know that there's a very bold / poetic statement.  And many of you are probably thinking this is where the sales pitch comes in.  But honestly, cloud technologies have been growing since their inception.  Honestly, how many people do you know who used to carry a thumb drive,  and now use DropBox, Google Drive, or OneDrive.  Apple, Amazon, and Google have all debuted their own cloud platforms.  So it doesn't take a genius to see this all happening and know that the future of Software Development involves considerations for the Cloud, as much as it does the mobile space or event IoT.  

So what makes Microsoft Cloud Platform so attractive.  Why would we consider it over say Amazon, Google, or Apple's clouds.  Honestly what should really make it attractive from the .net perspective is the integration with Visual Studio, and the current Microsoft Stack.  But that being said Microsoft has made an effort to make several advancements in not only Microsoft Stack cloud services, but other options like Linux, Node.js, etc.  

Now when most people approach the idea of Cloud services they think of Virtualization.  The idea of creating Virtual Machines in some monster data center.  From there we as developers remote into the machine, configure it however we want, and build an environment to host our applications.  This all fairly standard, and honestly not that different from working on premise.  

There are some great benefits to using this approach, which Microsoft has dubbed "Infrastructure" as a service.  For example, you have the ability to spin up, and down servers at a whim.  And additionally can stand up whole networks in the cloud to utilize.  All while Microsoft manages server uptime.  What could be better?

That being said, its not without its drawbacks, given that Microsoft has handed over the VM completely to use as Developers.  It means its our job to install updates, our job to handle backups, and our job to support the machine, and possibly configure load balancing.  

Now what many aren't aware of is that "Infrastructure as a Service" is not the only option with regard to Microsoft's cloud platform.  Instead they provide the alternative of "Platform as a Service".  "Platform as a Service" provides additional cloud based services to Developers to make better use of all things the cloud has to offer outside of just "Virtual Machines".  Now these two options are not mutually exclusive and you are free to mix and match them as you see fit, and Microsoft offers a "Pay as you go" option that lets you pay for only the services you need.

So after some thought, I decided I wanted to kick off a series of blog posts dealing with Microsoft Azure Services.  With the intent of going through several of the most common services and doing more of a deep dive on them.  

The plan for this series is the following;
  1. Azure Websites - The ability to host sites within the azure platform and abstract away the headaches of managing the VM.  
  2. SQL Azure - A database hosting platform for the Cloud, letting you get down to working with SQL without having to manage the overhead of a VM.
  3. Blob Storage - A cloud based file storage option to support resources for your applications.  
  4. Table Storage - A simplistic storage mechanism to support message and passing data between platforms.  
  5. Mobile Services - Push notifications and other services designed to work with mobile devices.  
  6. Media Services - 
  7. Service Bus - A message broker platform to leverage communication between multiple end points.  
  8. Visual Studio Online - A cloud based source control and ALM tools.
So more to come, next post will be a deep dive on "Azure Websites".

Monday, February 2, 2015

Javascript Practices Make Perfect

Hello again, I'm back with another short blog about javascript.  I was really surprised and pleased to see the amount of positive feedback that my last blog post generated.  The idea of Javascript scoping is one of those things that many of us think of as best practices.

But at the end of the day, everyone has a different skill set, and a different background.  I recently was talking to a colleague, someone who I do have a great deal of respect for as a developer and a friend.  We had to go in for a technical interview, to talk to a potential resource.  And during the interview, I asked a bunch of javascript questions.  After the interview was over, he and I talked offline.  And got into a bit of a debate.  His point was that Javascript is "the duct tape of the internet", and "it's the quick and dirty way of doing things when there is no other option."

Now, do I disagree with him on this point.  Absolutely, but at the end of the day my point is that there are a lot of people out there who believe this.  If you had asked me 5 years ago, I would have totally agreed with that statement.  But then Javascript was a language plagued by cross browser portability issues, and general problems.

But that was then, and this is now.  Since then, thanks to frameworks like Knockout.js, Angular.js, jQuery, Jasmine, etc.  Javascript is no longer the "red-headed step child" of web languages.  And instead is a fully formed language that can provide a lot of functionality and even be the primary focus of business logic (in the care of Angular).

Here are some practices, I definitely recommend for javascript:

  • Scoping the logic:  See my previous post, where I discuss the idea of how to scope javascript code and why that scoping is appropriate and necessary to maintain modular code that is self contained with minimal coupling and chance of error.  
  • External Files only, no others need apply:  With very limited exception, you should always be writing your javascript code in external javascript files.  This is a point that many people will likely disagree with me, as they will say that if you are using scoped javascript, what does it matter.  Additionally, you probably are thinking.  Kevin, if we use external files, we can't leverage Razor syntax in our javascript files.   In my experience, this is a bad practice, and a bad habit to get into.  The problem is that by using Razor syntax in your code you are creating a tight coupling between your view, and the model and your javascript code.  This flies directly in the face of general best practices, as your code is no directly dependent on the elements in the view.  I will talk about ways to get around this in my next post.  It also creates code that is not testable, and in this day and age there is no excuse for that.
  • NO HARD CODED URLS:  Honestly, if this were server side code, this would be a no brainer.  But for some reason many a developer I know feels the need to hard code urls when they right jQuery AJAX calls.  I don't know why everyone seems to think this is an excuse, but Javascript should never be an excuse for bad practices.  Now, I know this falls into the same category as people who say you should be writing your javascript embedded, and using Razor syntax.  Again, I argue here that you are creating a tight coupling, which is a mistake.  If you are going to utilize "@Url.Action", I would argue a better practice would be to put that value into a hidden field and have your "scoped" javascript object grab the hidden field to populate the url.  What you'll find is that you now have javascript code that can be dropped onto other forms and be in an external file.  
That's all for now, I just wanted to take a quick talk about javascript.  I'm going to do more articles in a series, and next topic is going to be about separating the javascript logic from your URL.