Blog Moved

My blog has moved!

https://kmack.azurewebsites.net

Wednesday, July 1, 2015

Moving Blog

Hello All,

Just wanted to leave a note here that I am moving my blog from Blogger to using an open source platform called ghost.

The new blog can be found... https://kmack.azurewebsites.net/

Thanks for your support and I hope you all find your way over.  I'm working with my domain provider to move the domain name to the new site.  Keep an eye out.

Sunday, June 14, 2015

Identifying Talent....literally half the battle

So got a lot of positive feedback about last week's post which is great. Thank you all for the feedback and emails. All very much appreciated.

So I wanted to continue following through on last week's post and talk about how to develop great developers for your team. But to do that the very first thing we need to talk about is hiring. Let's face it, if who you chose sent matter the NFL draft wouldn't be that big a deal.

Over the past few years, a decent part of my job has become doing technical interviews for not just my own development teams, but for other teams as well.  Its something that I've done quite a bit of for a while now.  I've probably done upwards of 100 technical interviews in the past 3-4 years or so.  This is one of those topics that many developers write off, and that fact alone proves to continually come back to bite people in the butt when they end up hiring a bad resource.  There are lots of developers out there, and finding a good one can be like trying to divine water.  

If you want to build something you need that strong foundation to build off of. And that foundation isn't something you get to create. Think about it this way, I can have plans to build the most amazing house. But if the property I choose is the Sahara it is just going to keep sinking. It's why the three most important things in real estate are location, location, location.

So how do you make sure that the candidates you choose to hire have that foundation?  The most important thing I've found, isn't necessarily a background in the technologies you are looking to use, but instead a passion to learn.

It's worth noting here, that I'm talking strictly about hiring Jr. Developers, not necessarily mid-level or senior developers.  There are very different types of things that I recommend you look for there.

If my time as a college professor has taught me anything, its that you can teach anyone to program.  Absolutely anyone can learn.  All it takes is drive, and hard work and anyone can learn this stuff.  And that's where passion truly enters the picture.  Without passion that drive to learn, and work ethic quickly evaporate.  You can teach anyone to code, provided that they want to learn.  

So that being said I recommend looking for the following items when identifying a junior developer:
  1. Broad Experience:  Most people look for people who have had an extensive computer science background, or a background in a single language to be on their team.  In my experience this turns out to be a mistake.  Look for people who have a variety of skills.  Like someone who's experiments with HTML, CSS, Javascript, and Java.  This shows that the candidate has a drive to learn, and is willing to pursue new things that might be outside the scope of their current learning.  This shows that they have passion but might need a little guidance to point them in a direction to pursue.  That's something that will occur naturally when you assign them work.  
  2. Personal Projects:  A big bonus that you should definitely look for is personal projects.  These show that the candidate has a drive to apply their skills in new and different ways.  If they have a GitHub link on their resume, go check it out before the interview, or ask them about those projects and that types of things they are trying to do and how far they go.  Any experience on a personal project is absolutely worth its weight in gold.  This also shows that they are a self starter who seeks out ways to make the things they are working on better without needing a senior dev to do so.  
  3. Don't Discriminate on platform:  As much as I recommend not being concerned with the background in the sense that if you are working on a .net project, don't eliminate someone for not having .net on their resume.  Its not their fault if their school only taught Java, and truth be told you are going to make them learn to write code the way you want anyway.  The hardest programming language you'll ever learn is your first.  After that they are pretty much the same.
  4. Make them talk about their skills:  Even if you don't need those skills on the project, don't be afraid to ask them to talk about them.  This makes them give you a context for how deep their skills go.  You don't want someone who lists things on their resume they heard about in class, you want actual skills.  So asking them to explain a project they used java on, or what kind of work they did with MySQL is a good way to gauge the depth of those skills.  
  5. Ask general software development questions:  All programming languages are essentially the same, and because of that you can ask generic questions.  I usually do a "lightning round" with these, and ask questions like "Explain inheritance to me?", or "What are access modifiers?" or "Explain the difference between Primary and Foreign Keys?"  Any program worth your time should have covered these concepts and these make up the foundation for how someone will approach their next language.  If they don't have a strong background here, they aren't worth your time.  
  6. Ask about their process if they run into a problem they can't solve:  Nobody likes a needy developer.  And the last thing you as a senior dev needs is to have someone hovering over your desk every time they get an error message.  So you want to know what their plan is, listen for the basic debugging process and see if they have a process they mentally go through.  
  7. Pay Attention to the non technical:  Its easy as a developer to focus in on the technical part of the interview.  But remember, you have to work with this person...So pay attention to things like whether or not they are client facing (Can I take them to a client meeting?), or can I communicate with this person?  Do they seem like they would be a personality fit for my team?  Do I think they will crack under pressure?  These are important things to keep in mind when looking at a new candidate.
Many developers look at these interviews as a hassle and something they can show up to without any preparation.  But honestly these are like the NFL draft, and your the coach.  Are you prepared to live with the decision you make in 5 minutes?  Getting a good developer can make all the difference and can give you someone you can grow into a fantastic resource.

Monday, June 8, 2015

Teaching isnt just for the classrom

Lately if I'm being honest I've been burning the candle at both ends. Well more like 5-6 ends. Whether its been preparing a talk that I had to give, working on projects or estimating others. More than a few things going on. But that being said I thought it a good idea to take a step back and look at some soft skills.

Specifically looking at grooming new developers. Now this is a topic I've had quite a bit of experience with. I grew up with a family of educators. Mom a high school math teacher, dad a college professor. My grandmother even taught first grade for 35 years. So it shouldn't be surprising that the idea of teaching is something that has always been in the background. A few years ago I started as an adjunct professor, and taught an intro to web development course. Additionally I've over the past few years been working in a mentor capacity for our interns and Jr developers and building a curriculum for both.

Not trying to toot my own horn, just trying to frame the conversation. I argue the act of teaching is something every developer should embrace in some capacity. And is absolutely essential to growth in your career. As we grow through our career our developers, its only a matter of time before we are a technical lead or in a situation where we are being given Jr developers to delegate work to. Now in those cases, our ability to teach those young devs is the cornerstone of our ability to succeed in what we do.

So the trick is how do we get to teach developers effectively:
1.). Get to know the student: Not to go all kung fu master but each person you work with is different. They all have different passions, and drives. Our education background and interests are different. Get to know your Jr devs. Where did they go to school? What type of work do they like to do? Web? Database? Mobile? What do they hope to do in this career? Are they married? All of these things provide key points to how people learn. Not only that, getting to know your devs builds trust. A trust that is essential to their confidence that you are there to help them and not just some tyrannical boss.

2.). Learn their strengths: Everyone in this field has something they are good at. They either like client side script or database, or C#. All that being said this is important to establish a foundation. When assigning work to a junior dev, its important to make sure at least some of it stays within their wheel house. This is important because it prevents frustration. It allows them to grow skills they already have and fall back on when the new challenges become frustrating.

3.). Push their weaknesses: Just as its important to give your Jr devs work they are comfortable with, it is also important to push them in new directions too. If you have a guy who's fantastic with JavaScript, assign him a SSRS report. People grow through adversity and being tested. So its important to make sure that your Jr devs are working on things that are new and different.

4.) Explain yourself: Remember when your parents used to tell you "because I said so.". And man did that become infuriating. Well its just a frustrating in the corporate world. If you don't take the time to make teaching a part of your job it will never pay the dividends you want.

Just some quick thoughts on teaching and importance to this job. This is something I intend to continue to talk about in the coming weeks, but consider this the opening salvo.

Thursday, May 28, 2015

Azure Talk

Just wanted to get an update out to let you know that nothings happened to me. Its amazing how little time you have when as a parent you go from a "double coverage" situation to "Man-to-man". It makes for some very long days, combined with getting up every 2 hours or so for a feeding. You know, we as parents subject ourselves to sleep deprivation, and noise assaults willingly. These are tactics being used for torturing terrorists. What are any of us thing?

So, that being said. When I do have a spare moment lately, I find myself questioning my own judgment. I have been working on a new talk, and demo relating to the App Service offerings from Azure. All of which I've worked on during my free time, and will be available via GitHub, along with the prezi.

I also wanted to take a moment to talk about the facelift this site just received. There were many enhancements made to this site, but some of the big ones are the following:

  • Facebook Page:  I've created a BigMackBytes, facebook page.  This page I have been filling with different resources that I found in my travels online that I thought might be of use to my readers.  So please check it out, it is receiving at a minimum daily updates for the past week and a half or so, and occasionally more than that.
  • Twitter / LinkedIn:  Here are my two professional social media outlets, I do regularly post links to items on my twitter account for additional resources, and LinkedIn provides more of my professional background.
  • GitHub:  Self explanatory as my personal github account, complete with all of my demo project code.
  • Public Prezis:  Here is a link to my presentations, this will give you copies of my prezi's to review if you want and consider the information they provide.
  • Email Me:  A link to my email if you wish to directly contact me.  
  • CodeProject Profile:  This blog is consumed by CodeProject, a truly fantastic site that has a lot of great articles and I try to contribute regularly.  Here's my profile on that site.
  • Helpful Links:  One of the most visited sections of my course site when I taught was the "Helpful Links" section, which provided a wealth of resources to help people as they work.  Well I have not only brought that feature over, I've upgraded.  I now use a Google Chrome extension called Bookmark Manager, and within that have exposed a whole section of resources as public.  You will find those links here and are welcome to use them as you see fit.
If you have something you would like to contribute or discuss, please feel free to reach out via one of the many options (Twitter, LinkedIn, Email, etc), and I will happily look at it for inclusion in the helpful links, or a post on the facebook page or blog.  I am always looking for new resources to share and would love to continue a dialog of possible resources out there.

Like I said this a short post, but I have more to come, as part of this demo I've gotten to really experiment with API, Mobile, and Logic apps, and I am really excited about the possibilities they provide and look forward to discussing it further with all of you.  

Until then though, I must sleep.  

Tuesday, May 19, 2015

Azure APIs = Digital Legos

As was mentioned in the previous post, I had to modify my azure series because of the exciting new announcements that were made in the past few months.   For those of us who see the perks and power behind platform as a service (PaaS) there is definitely a lot to be happy about.  Prior to this point there were really only two options available for platform as a service...Websites and Mobile Services.

Don't get me wrong, both are powerful, but recently Microsoft opened up the options available with the new offerings available.  The first being WebApps, which I've previously done several posts on Azure websites, and there is absolutely no differences between websites and web apps.  Just a rebranding to try and show how these can coexist to make a better cloud solution.

The next one, and the focus of this post, is Azure API Apps.  Which Microsoft is pushing as the best possible option for providing and building APIs.  The idea being that these APIs can then be consume by other web apps, outside services, etc.  There are a bunch of potential options available, including using it as a potential building block in an Azure Logic App.

As for how do we setup an API app, its actually surprisingly simple, and involves the following process.  I'm not going to focus on the steps to set one up, as there is a great article in Microsoft's Azure documentation that does an excellent job of doing that.  It can be found here.

Azure API apps, are supported on the backend by Web API.  Which is an ideal choice for creating RESTful services in .net.  I've done a previous post about the basics of Web API, which can be found here.  Web API provides several benefits, but some of the biggest are the following:

  • Client Driven Content Type:  WCF Services require formal definition of end types, and can be rather inflexible, but the greatest strength of Web API is the fact that in the request header, the "Content-Type" is set, and Web API supports several different content types.  But even gives you the ability to define your own formatters.  
  • Convention over Definition:  One of the paramount principles to RESTful services is that they provide a format where convention is favored over definition.  Meaning instead of providing all kind of plumbing code to sett up endpoints for your services.  You rely on the routing and Http Verbs to define the actions within your services.  Beyond that they function the same as controllers for MVC.
Azure API Apps, utilize Web API as the primary vehicle for supporting the API within the application.  But it provides additional support by having out of the box built in support for Swagger, which provides JSON based definition of the controllers and methods available to the API.  

This allows for a scenario where we get to have our cake and eat it too.  We get all the benefit of having the RESTful services without having to define and maintain documentation based on the changes to the API.  When the API is updated periodically Visual Studio takes the opportunity to build the swagger JSON documentation.  This provides the ideal best of both worlds.  

As for my next post we will see a Web API and an API interact with one another.  

Thanks again,

~K

Saturday, May 9, 2015

Advanced Topics Talk

Well as I posted on my course site.  I am officially closing out the Spring 2015 semester.  This semester was plagued with several scheduling problems, and as a result at times felt a little rushed.  So today I held a "make-up" of my advanced topics class and invited people to meet me at Panera Bread for the discussion.

It was a great talk, and a good time.  And all seemed to enjoy it.  And as promised for a followup I said I would post links to the resources that I discussed:

  • Visual Studio Online:  As I mentioned this provides a fantastic set of project management tools, as well as source control for free to anyone with a Microsoft ID.  This allows for syncing and backing up your work in a way that makes everything easier to manage a team.  
  • Windows Azure:  Microsoft's cloud platform, with loads of free options for supporting web apps, database, and a variety of services.
  • Windows Azure Pricing Calculator:  A great resource for helping to determine how much resources will cost on a monthly basis.  Its all ridiculously cheap but its still nice to know ahead of time an estimated cost.  
  • ShareItSimple:  A startup some friends of mine worked on to help share files in a really simple fashion.  
  • Microsoft Bizspark:  Microsoft's program for startups where if approved will provide free microsoft products and $300 a month in Azure Credit for years.  Great program.  
  • Visual Studio Code:  A new product to install cross platform and work on code, great for light weight operations.  
  • Channel 9:  A collection of instructional videos from microsoft.  
  • Microsoft Virtual Academy:  A variety of training resources by microsoft MVPs.  
  • PluralSight:  A paid for service that has amazing technical resources from some of the biggest names in the technical resources.  
  • Xamarin:  A development tool that lets you leverage C# to build Android and iOS apps that share code making it easier.  

Sunday, May 3, 2015

Where the heck have I been?

Hello All, so I know I've totally been MIA for at least a month now.  And for that I apologize, I really do.  But things have been pretty busy lately.  I usually try not to dip into my personal life much on this blog, but in this case I feel like you all deserve an explanation.  The past month I've seen the following:


  • Production 1.0 Releases of Several Projects at Work
  • The release of a product for an outside client, and initial support
  • The approaching end of the semester for my course.
  • The approaching arrival of baby #2, and preparing for that.
  • Health issues with members of my extended family
  • The passing of my grandmother.
Needless to say, its been a particularly busy month.  But things are calming down now, and I intend to pick right back up with my series on Azure PaaS (Platform as a service).  Now that being said, I do have to change the plan a bit.  As many of you know, there was several announcements over the past month.  The biggest being Azure App Service.  So I am going to be modifying my series to continue discussing these new offerings.  The new schedule is:
  • Azure API Apps:        5/11
  • Azure Mobile Apps:   5/18
  • Azure Logic Apps:     5/25
  • SQL Azure:                6/1
Thanks All, more to come this week.

Monday, March 23, 2015

Azure Series - Part 1A Azure Websites

So last blog post, I reviewed how to create a Azure Website, and the steps involved.  Which is useful, but there are probably some lingering questions at this point.  Namely what are all these menu tabs across the top..;.and why am I creating a site to begin with.   

The biggest benefit to using Azure Websites is not only the amount of time saved, which was discussed last post but additionally includes the overall cost and the maintainability associated with the platform.  A quick tour around the azure pricing calculator (found here), shows what I'm talking about with basic monthly costs.  But the real savings, come in maintenance, when you create a Virtual Machine, you need to coordinate the backups that are required, as well as patching the OS, maintaining up time, and setting up load balancing.  

With Azure Websites, that all becomes not your problem.  And with Azure Websites you are letting Microsoft handle and manage that.  Rather than having direct access to the VM, instead Microsoft lets you have access to the site and the ability to make any changes you want within.  But they take over management of the VM it sits on.  This also gives them the ability to move your site from one VM to another to manage up-time and make sure that standard maintenance doesn't cause any service interruptions.  

Think about that from a small business perspective, if you only had to pay a developer to build a web application, and configure the website.  And then monitor it would be infinitely cheaper than paying an administration to monitor and do maintenance on the server.  

So the real question is what all can you do to configure an Azure Website and exactly how flexible is the platform and the answer is "EXTREMELY".  So I want to take a moment to go through the screens available:

Dashboard  Menu:

First the "Dashboard" menu, this menu serves as the start screen for Azure Websites, and displays a variety of statistics which can be used for monitoring of the application.  This includes statistics like the following:
  • CPU Time
  • Data Out
  • File System Storage
  • Memory Usage
This is not a replacement for information from analytics or metrics like Google Analytics, but allows you to keep an eye on the statistics that directly affect the overall health of your application.  If you are seeing high CPU time, or Memory Usage then you are likely to want to consider standing up multiple instances (more on that later).  

This menu also allows for the creation of "Deployment Slots" which are one of the most attractive features of Azure Websites.  Deployment slots allow you as the developer to push a new deployment to a location where you can perform any kind of testing you want to ensure that your releases work properly.  And when your ready you simply click a "Swap" button to exchange the current site for the new site.  This allow for significantly more freedom, and the ability to ensure the quality of your deployments before you push them out there for production.  

You can also perform the following actions from the dashboard:
  • Download a Publishing Profile:  
  • View Connection Strings
  • Setup Deployment from Source Control
In short this allows for several options for configuration of your site.  But this is only the tip of the iceberg.  

Monitor Menu:

The next tab is the monitor, which shows a chart form of the statistics above.  This is a chance to view the data in a graphical form, which also allows you to see when your application is being hit the hardest, and when your peak times are.  This kind of information can be useful when determining how you scale your application.  

This shows you more statistics like:
  • CPU Time
  • Data In
  • Data Out
  • HTTP Server Errors
  • Requests
This allows for a more complete look at the application health.  Additionally, though I would still advise the use of Google Analytics, to provide the most complete picture, as well as internal logging within your application.  

Web Jobs Menu:

This menu provides the developer with the ability to configure and create Web Jobs.  These web jobs serve the purpose of batch services, windows, services or scheduled processes within your Azure Website application.  Its important to note that one of the biggest strengths of Azure Websites is that you don't have to manage the underlying VM.  But that can also be one of the biggest drawbacks.  Because of this, your access to the underlying VM is minimal, meaning if you have batch processes you would like to execute they will require the use of Web Jobs.  This is where you create and configure your web jobs to deploy them from Visual Studio.  

Configure Menu:

This is one of the most important menus in an Azure Website, this is where you setup and configure your application.  This is where you make changes like setting connection string, uploading SSL certificates, configure domains, etc.  But this is where you have the most control over the environment.  

The options available to configure for your Azure Web Application:
  • .NET Version
  • PHP Version
  • Java Version
  • Python Version
  • Managed Pipeline
  • Platform (32 / 64 bit)
  • Web Sockets
  • Always On
  • Certificates
  • Domain Names
  • SSL Bindings
  • Authentication / Authorization
  • Application Logging 
  • Site Logging
  • Performance Monitors
  • Application Settings
  • Connection Strings
  • Handlers
  • Virtual Directories
That's a lot of options, and definitely gives you a granular level of control.  All of this allowing you to either go in and tune your application to work at its peak or work with a basic rollout configuration.  

One thing to note is that there are more options here than just Microsoft technologies.  This is because over the past year Microsoft has made a definite effort to go Cross Platform with their offerings.  Including supportingg PHP, Java, and Python applications in Platform as a Service, and additionally support the idea of Virtual Machines that use operating systems other than Windows / Windows Server.  

Scale Menu:

This menu is where we really look at one of the strengths of Azure Platform as a Service.  Earlier we talked about how if your application is getting tested as far as load, and requires additional resources.  One of the most common ways to handle that is to implement another server setup for load balancing.  Now in Infrastructure as a service, this would require a new VM, networked to the first and configured to allow load balancing.  

Azure Platform as a service takes this multi-hour process down to a much simpler level.  In Azure Websites, at this point you can simply go in and increase the number of instances by 1.  By adding another instance you are adding another VM to support your website.  It really is that simple.  

But they make it even easier (I know right), you have the option of setting rules.  Such as if your CPU usage rises above a certain point,, you can have Azure automatically stand up another instance to support the new demand.  Additionally you can set rules on the other end that if your demand on the CPU drops below a certain level, Azure will automatically spin down an instance.  If you are using a pay as you go plan, it means that you can truly make sure that you only use what you actually need and then actually pay for it.  Minimizing overall costs!

Linked Resources:

Azure allows you to link resources together, allowing for ease of management.  For example, you might have a database, mobile services, service bus, etc.  This makes these resources easily grouped together so you don't have to search for them.

Backups:

By default Azure provides many backup options free of charge to support your website.  But if you require additionally backups, then the application can be configured to do that.  Backups are usually stored in Azure Blob storage.  

Final Thoughts:

In short Azure offers a lot of options to you as the user.  It is important to note that with all these options available, there are some drawbacks.  Like for example, because you don't have access to the underlying VM, you can't use its built in SMTP server features.  Instead you have to rely on external services (like SendGrid) to send emails.  But that being said the options available make this a very attractive option for not just web sites, but Web API, and other web based services.  The idea being that you can quickly and cheaply provide full support for your web applications within Azure.  

Tuesday, March 17, 2015

Xamarin and Android Code Talk

What a good talk!  Just got back from the "Xamarin and Android" talk that was given by myself and a good friend of mine.  It was a great talk with a lot of great people.  Honestly it was the first time we'd given this talk, and I was pretty pumped with the overall response.

I can't recommend these user groups enough.  They are a great way to meet and network with fellow developers and learn about new topics.

For the code from tonights presentation:
https://github.com/KevinDMack

For the presentation:
https://prezi.com/5em7g1ivhmjp/xamarin-and-android-development/

More later on this.  As I do a little more of a write up on it.

Wednesday, March 4, 2015

Xamarin and Android Talk Official

Well its been officially announced so I can discuss but this month a good friend of mine, Brad Linard and I will be giving a talk at the Central PA .net user group.  The topic of choice is Xamarin and the development of Android apps. 

We will be starting at the inception of an app; talk to a cloud based service and work with a local database.  Finally, we will be talking about Google AdSense, and look at Xamarin Insights and Xamarin Social. 

It should be a great talk and a good introduction to the world of Xamarin.

Please feel free to RSVP it should be a great talk.

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.  

Saturday, January 17, 2015

Javascript and Scoping

Well it been a while since I posted and it boils down to the holidays.  There's nothing like the holidays to throw your whole life out of whack.  If your like me, then you keep your life as organized as possible and its the only reason your able to function.  And that got me thinking about this blog post and gave me an idea.

I've been preparing some articles on MVC, and even a presentation.  Something I likely will be taking to code camps, and presenting to even my students at HACC.  And that got me thinking about how one of the greatest strengths of MVC is the flexibility and ability to organize code into self contained modules.  By building this out we can organize our code into separate pieces of classes and navigation controllers.  We can isolate code and maintain loose coupling to make for more testable code.

Now I can't tell you how many times I've seen wonderful code fall apart.  Too many times I've seen people say "we're using MVC" and say that like it guarantees that you're code is not only using current technologies but is correct and architected properly.  MVC is a framework, just like any other, and that means that just like any framework, it is only as good as the design of the code and the work of the programmers.  If there was a technology that guaranteed good code, we'd all be out of a job.  

Now that being said, there are lots of developers out there who leverage MVC correctly.  They use the proper separation of concerns.  They set up their controllers, using a logical grouping of the controllers and controller actions.  But that is a whole other post on to itself, and the ways MVC can be abused.  

But all that aside, the one place I see the most abuse of basic structure and patterns is Javascript.  For example, let's say you write code like the following in partial view:

<div>
        Number 1 : <input type="text" id="Number1" /><br />
        Number 2 : <input type="text" id="Number2" /><br />
        <input type="button" id="btnAddNumbers" onclick="AddNumbers()" value="Add Numbers" />
    </div>

Now like any good developer, you put your javascript code in a separate JS file called "Add.js".  And it contains the following code:

function AddNumbers() {
        var num1 = parseInt($("#Number1").val());
        var num2 = parseInt($("#Number2").val());
        var total = num1 + num2;
        alert(total);
    }

Now to most of us, this looks like perfectly fine javascript code.  Nothing really special here.  When you go to add this to a page, you add a reference to the JS file in the head tag of your page.  And all is well right?

Not quite...see right now, the javascript code above is being declared in what is called the Global namespace.  Meaning that the code is being declared at the page level, and everything this function is available to the entire page.  

The question is, what happens when another developer writes a partial view with the following HTML:

<div>
        Number to increment:<input type="text" id="NumberValue" /><br />
        <input type="button" id="btnAdd" value="Increment Number" onclick="AddNumbers()" />
    </div>

And they write the following function:

function AddNumbers()
{
     var num = parseInt($("#NumberValue").val());
     num = num + 1;
     $("#NumberValue").val(num);
}

And they declare their JS at the bottom of the page, thinking that it would load at the end, and insert their partial view into the same view as yours.  The question is what is going to happen now?  There are two functions declared with the same name.  If this were sever side code, we would get a compilation error.  

But seeing that this is javascript.  If I entered a "1" in the "Number 1" textbox, and a "2" in the "Number 2" textbox, and clicked the "Add Numbers" button, I would get an "NaN" in the "NumberValue" textbox.

Now why is that?  Because when the browser loads the page, it does so from the top down, which means that it replaces the "AddNumbers" function with the one that does the incrementing.  This is because Javascript handles functions in much the same way as objects.  So by declaring it in the global namespace you are allowing for the potential that your code could be replaced by someone else's.  

So what can you do?  To be honest the best option is to scope your javascript so that it doesn't sit in the global namespace, and presents this type of situation.  You do that by treating a function just like an object, and modify your code in the following manner.  

function CalcMath() {
        var addNumbers = function () 
        {
            var num1 = parseInt($("#Number1").val());
            var num2 = parseInt($("#Number2").val());
            var total = num1 + num2;
            alert(total);
        }
        return {
            AddNumbers : addNumbers
        }
    }

This creates an object called "CalcMath", and a "method" off of that object called "AddNumbers".  And this allows me to update the button to have the following:

<div>
        Number 1 : <input type="text" id="Number1" /><br />
        Number 2 : <input type="text" id="Number2" /><br />
        <input type="button" id="btnAddNumbers" onclick="CalcMath().AddNumbers()" value="Add Numbers" />
    </div>

Now, if someone adds a function called "AddNumbers" it has no affect on your partial view.  This allows for everything to say modular, and separated and keeps other code from impacting your code in the future.  

Many of the javascript frameworks out there (Angular, Knockout, etc) are based on this principle, and use it as a foundation for the other benefits they provide.

So that's it for right now, more to come about the presentation, and more specifically more to come on resources for startups, and articles on lessons learned from my own current startup work.