Microsoft: Adding IntelliSense for jQuery in WebMatrix and Microsoft development tools.

I had the opportunity to work with HTML5 APIs and jQuery development inside Microsoft WebMatrix, it is a light IDE and installed with libraries and extensions that made development richer.

In order for WebMatrix to really be a useful as an editor for jQuery, I really wanted to have IntelliSense support for jQuery. However, the annoying issue is that WebMatrix does not have a built-in IntelliSense support for jQuery in and other JavaScript tools.

As jQuery is one of our focuses here in this post, adding IntelliSense for jQuery is extremely easy, therefor I am going to explain how to add the IntelliSense support for jQuery into WebMatrix or other Microsoft development tools in an easy step.

The idea
---------------
Microsoft's developer tools like WebMatrix, Visual studio 2008 SP1 and upper versions, allow you to add IntelliSense for any JavaScript library by adding a Reference Directives (.vsdoc JavaScript file) to your page.

The files that you would use for your reference directives are available at the same Microsoft CDN where you can get the jQuery library from at:

http://www.asp.net/ajaxlibrary/cdn.ashx

How to do it
-------------------
In order to use IntelliSense for jQuery, you need to download the appropriate jquery-n.n.n-vsdoc.js file for the version of jQuery that you are using and store that in your page.

1. Your project structure should be as the following
   
   
   
   
   
   
   
2. Add the reference directive (jquery-2.0.3-vsdoc.js) into your html page as the following
   
   
   
   
   
   
   
3. You also can add it to you JavaScript library file, to get the power of IntelliSense for jQuery as the following
   
   
   
   
   

Result
-------------
Now you have added the library reference directives for jQuery version, into your IDE inside your page write jquery call by just jQuery or $ you will get:

Hit the .(dot) and you will also get

Conclusion
-----------------

Also as you notice in the previous pictures, the reference not just get the IntelliSense but more than this, it gives you the power of getting the methods documentation and parameters explanations on the fly, or by hover over the method after writing it.

Thanks to Microsoft reference directives.

References
----------------
1- Microsoft Ajax Content Delivery Network.

Architecture: What’s in your architecture toolbox?

It is said that there’s a tool for every job. But when that job is IT architecture, in all its permutations, the definition of tool can be a bit fuzzy.

When I set out to get a sense of what community members consider the most important tool in their respective architectural toolboxes, I intentionally left the definition of tool open. I was curious to see how those who responded to my questions would interpret the term.

One of those respondents was Farzad Pezeshkpour, head of architecture and engineering for market and credit risk technology at the Royal Bank of Scotland. His personal choice for the most important tool is Enterprise Architect from Sparx Systems.

“In order to do enterprise architecture well,” Pezeshkpour says, “there must be a consistent way to represent it, using a number of different views at different levels of detail, including logical static, logical dynamic, and deployment. There also must be a consistent naming and referencing mechanism to tie together all the architecture views. And finally, there must be an enterprise architecture repository to store and cross-reference these artifacts.

Having these three core elements in our toolset and processes gives an architectural management information view that helps govern our estate more efficiently and intelligently.”

Architecture is deeply connected to the specific business and technological environment in which an organization operates. Pezeshkpour works at one company, in one environment—which is challenging enough. But what happens if your work as an architect takes you into a variety of different environments?

If you find yourself in that situation, Vennster Managing Partner Ronald van Luttikhuizen advises adaptability when it comes to tools. “Especially if you’re a consultant working for various clients, it greatly helps to use the tooling that is available and already in use by clients and stakeholders, instead of rigidly sticking to your own toolset,” says this Oracle ACE Director. 

That can mean dealing with a variety of Unified Modeling Language (UML), Business Process Model and Notation (BPMN), and other modeling and design tools. As for his personal favorite, van Luttikhuizen also lists Sparx Systems’ Enterprise Architect. “A great tool at a great price,” he says.

But van Luttikhuizen’s toolbox also contains some more-basic applications to help him get his message across. “In the end, architecture is about communication,” he says. “So in the beginning of an architecture-oriented project, the most important tools are a whiteboard, Microsoft PowerPoint, and Microsoft Word.”

Karina Ishkhanova, a solution architect and technical lead for payment systems at School-Day Solutions, agrees with van Luttikhuizen about the importance of basic communication tools. “The first stage in defining the future architecture happens in close collaboration with business departments,” she says. “Whiteboards, paper, and markers are indispensable. Sometimes we even cut paper into components to move them around to help visualize the variations on proximity to other system parts.”

For modeling, Ishkhanova uses UMlet, an open source UML tool, which she values for its simplicity. “At more-advanced stages, I move to Oracle JDeveloper,” she says, “to take advantage of its integration and automation features.”

Communication tools are also vital for Lambda Software President Aki Iskandar.

“By far the most important tool in my toolbox is the one that I ask my clients to hand to me before any discussions, let alone architectural work, starts. It’s the set of three blueprint documents that jointly define well-articulated and complete business requirements, the constraints within the environment, and the architectural diagrams for network topologies,” Iskandar says. “Without them, you may overarchitect or underarchitect the system. You can’t architect a system without knowing the constraints before you start.”

Perhaps his last point is the IT architect’s equivalent of the carpentry maxim “Measure twice, cut once.”

While the choice of tools varies among these four architects, that choice is driven by the shared goal of effective communication in order to ensure a good fit between the up-front plan and the completed project. Isn’t that what IT architecture is all about?