JQuery in Visual Studio

A big part of the appeal of jQuery is that it allows you to elegantly (and efficiently) find and manipulate HTML elements with minimum lines of code.  jQuery supports this via a nice “selector” API that allows developers to query for HTML elements, and then apply “commands” to them.  One of the characteristics of jQuery commands is that they can be “chained” together – so that the result of one command can feed into another.  jQuery also includes a built-in set of animation APIs that can be used as commands.  The combination allows you to do some really cool things with only a few keystrokes.

For example, the below JavaScript uses jQuery to find all <div> elements within a page that have a CSS class of “product”, and then animate them to slowly disappear:

$("div.product").slideUp('slow').addClass("removed");

As another example, the JavaScript below uses jQuery to find a specific <table> on the page with an id of “datagrid1”, then retrieves every other <tr> row within the datagrid, and sets those <tr> elements to have a CSS class of “even” – which could be used to alternate the background color of each row:

$("#datagrid1 tr:nth-child(even)").addClass("even");

The jQuery library also works well on the same page with ASP.NET AJAX and the ASP.NET AJAX Control Toolkit.

Visual Studio figures out external script references, such as to JQuery, by following special reference comments it finds at the top of .js files:

/// <reference path="jquery-1.2.3.js" />

You can download the JQuery from here. You can get more details on JQuery from http://jquery.com/ .

For intellisense support for JQuery you need to install this Hotfix.

Comment for javascript is written inside for intellisense support. JavaScript has the interesting feature that calling toString on a function returns the code of this function including the comments and thus the doc comments. Here’s a similar example in JavaScript where the documentation is written inside of a class constructor:

Another difference with C# or VB.NET is that property and event accessors are two different entities in JavaScript. For this reason, to choose where the documentation should be for those members. Properties should be documented in the getter and events in the “adder” for this reason:

Some skills every IT person should have

Be able to fix basic PC issues: These can be how to map a printer, back up files, or add a network card. You don’t need to be an expert and understand how to overclock a CPU or hack the registry, but if you work in IT, people expect you to be able to do some things.

Do public speaking. At least once, you should present a topic to your peers. It can be as simple as a five-minute tutorial on how IM works, but being able to explain something and being comfortable enough to talk in front of a crowd is a skill you need to have. If you are nervous, partner with someone who is good at it, or do a roundtable. This way, if you get flustered, someone is there to cover for you.

Train someone. The best way to learn is to teach.

Listen more than you speak. I very rarely say something I didn’t already know, but I often hear other people say things and think, “Darn, I wish I knew that last week.”

Know basic networking. Whether you are a network engineer, a help desk technician, a business analyst, or a system administrator, you need to understand how networks work and simple troubleshooting. You should understand DNS and how to check it, as well as how to ping and trace-route machines.

Know basic system administration. Understand file permissions, access levels, and why machines talk to the domain controllers. You don’t need to be an expert, but knowing the basics will avoid many headaches down the road.

Script. Everyone should be able to throw a script together to get quick results. That doesn’t mean you’re a programmer. Real programmers put in error messages, look for abnormal behavior, and document. You don’t need to do that, but you should be able to put something together to remove lines, send e-mail, or copy files.

Back up. Before you do anything, for your own sake, back it up.

Test backups. If you haven’t tested restoring it, it isn’t really there.

Document. None of the rest of us wants to have to figure out what you did. Write it down and put it in a location everyone can find. Even if it’s obvious what you did or why you did it, write it down.

Work all night on a team project. No one likes to do this, but it’s part of IT. Working through a hell project that requires an all-nighter to resolve stinks, but it builds very useful camaraderie by the time it is done.

Manage at least one project. This way, the next time the project manager asks you for a status, you’ll understand why. Ideally, you will have already sent the status report because you knew it would be asked for.

Don’t be afraid to debate something you know is wrong. But also know when to stop arguing. It’s a fine line between having a good idea and being a pain in the ass.

If you have to go to your boss with a problem, make sure you have at least one solution.

There is no such thing as a dumb question, so ask it … once. Then write down the answer so that you don’t have to ask it again. If you ask the same person the same question more than twice, you’re an idiot (in their eyes).

Even if it takes you twice as long to figure something out on your own versus asking someone else, take the time to do it yourself. You’ll remember it longer. If it takes more than twice as long, ask.

Learn how to speak without using acronyms.

IT managers: Listen to your people. They know more than you. If not, get rid of them and hire smarter people. If you think you are the smartest one, resign.

IT managers: If you know the answer, ask the right questions for someone else to get the solution; don’t just give the answer. This is hard when you know what will bring the system back up quickly and everyone in the company is waiting for it, but it will pay off in the long run. After all, you won’t always be available.

IT managers: The first time someone does something wrong, it’s not a mistake — it’s a learning experience. The next time, though, give them hell. And remember: Every day is a chance for an employee to learn something else. Make sure they learn something valuable versus learning there’s a better job out there.

IT managers: Always give people more work than you think they can handle. People will say you are unrealistic, but everyone needs something to complain about anyway, so make it easy. Plus, there’s nothing worse than looking at the clock at 2 p.m. and thinking, “I’ve got nothing to do, but can’t leave.” This way, your employees won’t have that dilemma.

IT managers: Square pegs go in square holes. If someone works well in a team but not so effectively on their own, keep them as part of a team.