Evolution of tools

Some purists may argue that man only really stepped up and made progress after the invention of electricity since most major inventions has been made in the last 100 years and no period in time has ever seen the progress made as in the last hundred years.

I, however, feel that man made his biggest evolutionary leap when he first realised that having a tool to help complete work is better than not having any tool at all, albeit the wheel, metal hammer or whatever implement of war you like (queue the overused 2001:a space odyssey reference where the ape realised the POWER of tools when he kills his fellow ape with the bone from an animal)

Apply that principal to development and the same rule applies. The better your tools, the more POWER you have.

In my team, the principal exists that a proper set of base line tools will not only help speed up development but will also help to decrease bugs and other well documented problems in the development life cycle. We have the motto that whenever a new development starts we carefully evaluate what tools we have available, what tools we can buy and ultimately what tools we need to develop ourselves to enable us to do the work smarter and faster.

One set of these tools are our code generators. Now there may be various products on the market that allow you to efficiently generate mass amounts of code, but they are expensive and often customization of specific needs take more time than what the actual benefit may be. So we develop our own. These Code generators then enable us to generate various pages (Data manipulation pages), Search pages, Code snippets and generic usage pages that not only boost development time, but also assist junior developers in understanding certain concepts. One of the major advantages of these generators are the fact that the code that is generated has already been tested, approved and cleaned up to the extent where limited bugs exist, and should a new bug be found, ALL the code can easily be regenerated with the fix and applied to existing code.

So whenever your next project starts or even in your current development / maintenance / QA cycle, keep your eyes open for opportunities to either buy or develop your own development tools. Although you may not see the benefits immediately, once the tools are refined and they start producing results the benefits will not only become clear but it will become an essential part of your development arsenal.

Not having the proper tools is like having a great car with a broken gearbox, you will always be stuck in first. So in the next project you do, PLAN properly around the proper tools and you will find yourself picking up speed in no time.


For more information visit the QBCon home page.

SketchFlow – Client Interaction Made Easy:

One of the most tedious steps when starting a new project is mapping workflow. It acts as the benchmark for the rest of your application, but the initial idea hardly ever sticks. Getting sidetracked during the design process is as certain as death and taxes. Trying to represent another's vision is a time-consuming process that often causes delays due to miscommunication. A client often won’t be interested in the flow of a program, but in how it looks or whether it will sell. Clients propose one thing and a developer will interpret it differently, purely because of different mindsets.

During design, we use fonts and colours that we are familiar with. When pitching the design, this is the first thing the client notices. It draws the client's attention away from the functionality of the application.

How do we avoid this problem until the basic functionality is complete? When I discovered SketchFlow, I felt like screaming, "Eureka!" This tool not only makes workflow mock-ups unfathomably easy, but it focuses on the simple things needed to help developers clarify the bigger goals.

This however, is not the only gun in SketchFlow’s arsenal. Clients can actually see the progress of a design and present feedback on it instantly. This feedback, in its purest form, is packaged and relayed to the designer with notes and ideas in place. It avoids confusion and speeds up the design process by focusing on core components. It gives clients the power they really want, namely being involved and in control.

Listing 1.1 shows screens as displayed in a ‘SketchFlow Map’ format. This gives a clear indication of which screens are connected. Developers might know a child window from a UserControl but to clients this might be a foreign concept. SketchFlow’s enables the designer to give different screens a Visual Tag. This makes it easier for the client to read what is being presented.

Listing 1.1.

Listing 1.2 shows the core of what the client sees. SketchFlow focuses on functionality of design, instead of image. Designs are based on a non-colour, non-font example. This helps the client to stay focused on what the program should do instead of what it looks like.

Listing 1.2.

Listing 1.3 displays SketchFlow as the client would see it. From here the client can view the map, navigate between screens individually, or follow the flow of the program as it would be in real-time. It’s published client side and makes the communication much easier. When something is unclear to the client, they can easily have a quick look instead of taking the long road through developers, designers etc.

Listing 1.3.

Listing 1.4 displays the proverbial honey of SketchFlow.

The client can draw and highlight areas on the screen and add text as notes. This gives maximum feedback and can visually present an idea, which is sometimes easier than verbalising it. It makes communication between designer and client much more reliable, which cuts out time delays on trying to decipher concepts.

Listing 1.4

SkethFlow holds many treasures for a designer. Clients are often blindsided by the end product, which takes focus off of what is important. We need to crawl before walking; SketchFlow aids in perfecting the core steps of applications before they can adopt their full potential.

ASMX or WCF? Choose your pizza

When you do a Google search on “ASMX vs. WCF” or similar you will find a lot of results. This is how I see it:

A man called Smith ordered a Regina pizza with broccoli from his local pizzeria. The man behind the counter was stunned. Why would anybody order this particular pizza? He asked the man if he would be interested in the new, awesome pizza, namely a Regina base with broccoli, pepperoni, bacon, avocado, steak, mushroom, three cheeses and pike.

The little scenario above is a mediocre comparison between ASMX* web services and the new WCF*. Although broccoli (ASMX) is still an excellent technology, there are better, newer pizzas out there (WCF).

I’ll admit it is easy to eat the broccoli pizza without making a mess. A description of what your service methods and classes will look like is stored in a WSDL*. Now, we simply decorate a method (inside a .asmx) with the [WebMethod] attribute and viola, any property with public accessors and modifiers we pass in or out, will be serialized into XML. Your method can now be called over HTTP and hosted on an IIS.

The snags with broccoli, uhm, let me think…to name a few:

• ASMX doesn’t specify how to deliver over the transports and to use a specific type of security.
• ASMX has a tight coupling with the HTTP runtime and is dependent on IIS to host it.
• ASMX service is instantiated on a per-call basis
• ASMX provides the way for interoperability but it does not provide or guarantee end-to-end security or reliable communication.

Now, let's discuss the pizza with all the new toppings. WCF irons out all of the concerns listed above and replaces all the following technologies: ASMX, MSMQ*, WSE*, COM+ and .Net Remoting.

You might have noticed that one of the toppings in my metaphor, pike, has no business being on my pizza. This represents the configuration that is keeping a lot of developers from implementing WCF. With WCF the configuration might be a bit “messy”, but the reward is an awesome, tasty pizza. From a developer's point of view the coding side stays the same, the bottom line being a method gets called with an “object” as parameter and an “object” is returned (To get the technical lingo out of the way…we call this a message).

We no longer decorate only the method, but an interface, meaning any class that implements the interface can be a service. We are no longer limited to hosting the service only on an IIS, but in Console Apps, Windows Forms, WPF, etc. A description of the Service is still stored in a WSDL (.Net 4 has support for WSDL 2.0)

WCF is the future of the .Net platform, thus it will be time wisely spent to familiarise, educate and become proficient in it. If you have been holding back I encourage you to forget about your trusty broccoli pizza and reap the benefits of a pizza with a lot of awesome toppings.

Definitions

• ASMX: Active Server Method File
• WCF: Widows Communication Foundation
• WSDL: Web Service Description Language
• MSMQ: Microsoft Message Queuing
• WSE: Web Services Enhancements

For more information visit the QBCon home page.