Author: DGP

How to Create Shortcuts in Visual Studio

For starters, I’m not a huge user of shortcuts. Aside from your standard cut, copy, paste, undo, and redo, there aren’t that many shortcuts that I use on a regular basis.  However, there have been several times while developing when have I realized that I could save quite a bit of time by creating my own shortcut to do something in Visual Studio.  For example, I wanted to go through 20 or so files and use the Remove and Sort Usings feature, which is buried under 3 sub-menus and has no native shortcut (too much mouse movement!).

It turns out that Visual Studio lets you customize shortcuts for thousands of different commands throughout the application. To do this, go to:

Tools -> Options, then Environment -> Keyboard:

Keyboard Options Dialog

Visual Studio Options dialog

By default, the shortcut will be available globally throughout the entire application. If you want your shortcut to be available only for a specific feature, you can adjust this using the “Use shortcut in:” drop-down list.

There is also a way that you can export all of your custom shortcuts to share them with others or to move them to another environment.  Pretty sweet!  See the MSDN documentation for more information.

So there you have it!  Such a great way to save time and avoid the monotony of redundant tasks.  Happy shortcutting!

Posted on by DGP

Manipulating Copies of JavaScript Objects with KnockoutJS

I recently ran into an issue when trying to change properties of what I thought was a copy of a JavaScript object.  I made all of the new object’s properties observable, and then tried changing the value of one of the properties in the new object. It turns out that this was also changing the same property in the original object.  This is all because JavaScript objects are assigned by reference, not value! For example:

var x = y;

In the example above, the object x is not a copy of y. It is a reference to y! So how does this relate to knockout?

In my project, we have data from the server given to the client in JSON format.  It is then given to the client-side viewModel, all non-observable.  In order to take the data from the server and make the data we need to be observable, we use a method to set all of an object’s properties to be observable.  This stomps over the original object, which is okay because we don’t ever need the original non-observable object that came from the server.  If, however, I need to clone the object’s data and manipulate properties on the clone, while keeping the original, I’ve found the easiest way is to use the jQuery extend() method.  You can specify whether or not to make a deep (recursive) copy, and even merge 2 objects as well.  The following example makes use of this method:

Notice in the results that the original object has “Not John” as the First name, since it was inadvertently changed on its reference. The object changed using the extend method did not affect the original!

References: w3schools.com

Posted on by DGP

Can You Help Me Name Some Variables?

One of the seemingly simplest tasks in programming is sometimes one of the hardest: naming variables.  One day, a coworker of mine was asked by numerous people throughout the day to help come up with meaningful variable and function names that applied to their specific situations.  By the end of the day, she was mentally exhausted from the all of the thinking and internal deliberation involved.
This mental struggle seems to be present when naming any variable, function, class, property, enumeration, or namespace. It’s always difficult to come up with a name that
  1. Represents the data accurately
  2. Is verbose enough but still concise
  3. Makes sense to you
  4. Makes sense to any other team members that will come across your code in the future

It’s important that all of these criteria are met if you have any hopes of maintaining the software moving forward.

This struggle of my coworker that day inspired me to write a song about the whole process of naming variables while writing code.  The song portrays a developer (myself) trying and trying to write code, but I need help naming variables. With none of my coworkers able to help and getting caught up in meetings, it seems like I can never make any progress! It’s just one of those days…

You can find the song below:

Posted on by DGP

Me? Write documentation? Oh dear…

“Noooooo!! Don’t say the ‘D’ word!!!”  That’s what most developers say when they hear the word “Documentation.”  No, it doesn’t sound snazzy like the latest JavaScript library or other cutting-edge technology.  But is it important?  Absolutely.  Sometimes it can be really difficult to realize the value in good, readable, and thorough documentation.

I recently spent a period of about 2 weeks chugging away at documenting a large module of our application.  Many of the business rules had never been documented before, while some had been established during the last release.  It seemed to be a sort of “business rule soup” trying to wade through all the existing (and sometimes out of date) documentation and consolidate it into a up-to-date module document.  Through the process, I came away with 6 reasons why it is so important to have good, thorough documentation:

  1. The people testing your software can know how to test it.  Obviously, you want the people testing your code to know how it works so that they can test it correctly.  Out-of-date documentation or documentation that is not put in human readable terms (e.g. someone off the street can understand what’s going on) is not going to help your testing staff.  The more business rules you document, the more bugs the testing staff can find!  How will they know if there’s a bug if they don’t know how the page is supposed to work?
  2. Other people on your development team can learn about how your software works. With many large teams, it can be difficult for every member to be familiar with every single piece of the software.  With good documentation, if a team member with no experience working on your software is assigned to add a feature to it, they can simply refer to your documentation to understand the intricacies of how it works, and the business rules it should enforce.
  3. You can remind yourself of what you wrote.  Let’s face it.  People sleep.  We forget things.  If I work on a feature back in January, and November comes around, chances are that I probably won’t remember what I did back in January.  With good documentation, I can refresh my memory of what exactly I did in the code, without having to trace through huge bits of (probably uncommented) code to try and understand what all is going on.
  4. People new to the project can learn how it works.  Pretty self-explanatory…documentation is great for onboarding new members to projects.  If they are going to be writing code one day, they better understand how the existing code works, first!
  5. You will find bugs in the software.  When thoroughly documenting a piece of code, especially ones that haven’t been documented correctly, it will require you to heavily test every single business rule present and determine the source of every single piece of data.  Sometimes you may find that some rules are partially enforced, or maybe aren’t enforced at all.  Perhaps people thought the code behaved one way, but after attempting to document it… Woops!! Doesn’t behave that way!
  6. You will have less false bugs reported by the testing staff.  It’s important that business rules are documented, but they must be correct! With thorough documentation that is correct, there will be little chance that a bug will be thrown at you, when the real problem is incorrect documentation.

See!  It’s pretty important after all!  Although documentation can be a bear to write at times, it can be your best friend in the long run!

Posted on by DGP

Let’s Start!

Woah! Hello world wide web! I can hardly believe it. After going through all of college hearing about these people who write these things called “blogs” (or as more proper people like to call them, “weblogs”…I had a professor who called them by this…but that’s a WHOLE other story…), I never envisioned myself actually partaking in such a thing, but here I am!  And I am pretty excited about it!

I intend for this blog to detail various challenges, obstacles, technologies, solutions, bugs, interesting facts, etc. that I come across as a web and .NET developer.  I hope that you, who have stumbled across this site, can take away some sort of insight or knowledge from it that you did not have before.  I don’t know how often I will post new entries to this blog, nor do I really know what they will be about, but that’s all part of the whole experience.  This is the initial kickoff to something that I hope to be pretty cool.  So here we go!

Posted on by DGP