What's the use of coding standards?

Although people think of programmers as nerds and geeks, they are actually a very varied group of people. In our own office you have mothers, geeks, jocks and even very arty people. Their programming styles vary just as much as their personalities and lifestyles. You get everything from the cowboy programmer that programs from the hip to the meticulous programmer who will write a comment for every line. This also leads to very different coding styles. Although it might not seem to be a problem initially, it can become a huge, time-consuming problem. For instance, when Mrs. Meticulous has to work with or on the cowboy’s code, the fact that he indented his code by only one space may make his code almost unreadable to her.

The compromise in the end is to have a coding standard: a set of rules that explains what the standard way of coding will be. It can specify everything from the amount of comments to where the period after a line of code must be placed. To say it is a compromise is accurate as no one person would be completely happy with all the rules as many of them might clash with their personal preference.

The advantages of a coding standard are obvious. The end result will be neat, uniform code that can easily and quickly be read by a programmer who is familiar with the standard. It will make it easier for new programmers to become acquainted with the code and for existing programmers to take over code that has been written by programmers that has left the company. Although a coding standard fixes a lot of problems, some caution has to be employed. Setting down the standard can be very time-consuming, as anyone who has sat through a two-hour meeting on where to put a “then” can attest. It might be valuable to get a neutral outsider to help negotiate the standard.

For more information please visit the QBCon home page.

GUI versus Character, the ultimate battle!

When thinking about the differences between a character system and a graphical user interface (GUI), a few things come to mind. The most prominent is the look and feel of the system. When working in a character environment all you need is your keyboard. It is a bit more rustic than GUI, but you can still design a great interface for your customer’s specific needs. Working with a keyboard takes some getting used to, but when you are familiar with all your keys and their functions you can run through a system like a hot knife through butter! The sacred art of double-clicking becomes a thing of the past. The programmer controls the flow of action, as the user can only leave a specific field by pressing enter or the tab key. When a user starts a function or action he must either finish that action or back out of it completely before choosing to do something else.

GUI, on the other hand, is a bit more refined and friendly to end-users because it’s a lot like the Windows operating system. GUI gives the programmer the ability to play around with the screen layout, sometimes to the point of frustration. Often, too much time and effort goes into the design of the screens and not enough into the logic behind it. The user controls the flow of action because he can skip over certain fields using the mouse. A user can change his mind while busy with an action and change a security option before finishing.

What character systems buttons lack in finesse, they make up for in transparency. There's no wondering what Appr. means ('approve' for those who don’t know). With GUI you can pick an icon, but what might look like ‘approve’ to the programmer might mean something else to the user. Always be sure to add your tooltip when designing buttons in GUI. Buttons often look like hieroglyphics to the user.

Virtual real estate is something that doesn't exist in a character system and probably never will. Limited space will always be a problem, so designing a system that is understandable is a priority. Real estate and virtual real estate is one of the great features in GUI. There are no limitations to the amount of buttons you can add to your toolbar or the number of tabs you can add to your program. If and when it does become a problem a bigger screen is an easy solution.

I always remember thinking when I was young that a GUI system is an upper-class software system that only the elite can use. Recently I’ve come to realize that both character and GUI offer the exact same functionality and ease of use. It all boils down to personal preference. I have come to appreciate the 3D frames and fancy buttons that come standard with a GUI system, but deep down I will always be a fan of character.

For more information please visit the QBCon website.

Written by Denielle Horn on behalf of QBCon.

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.

How to choose: Web or Windows Application?

Choosing between writing a Web application and a Windows application is like choosing between Superman and Batman. The man of steel can fly, shoot lasers from his eyes and pack a mean punch, while the Dark Knight has cool gadgets, a Batmobile and is a billionaire with a secret lair.

At QBCon we work on Web and Windows applications. There are a lot of things to consider when deciding between Web and Windows. Let’s look at some of the pros and cons.

Web applications

Pros

• No special configuration or changes are needed on the user’s computer.
• The application and information is accessible to a wide audience all over the world.
• Centralised data is secure and easy to backup.
• Anyone with a browser can access it, regardless of their operating system.
• Deployment and version management is easy, making the application immediately available to all users. There is no installation to contend with.
• When the application is used for in-house Intranet systems, no Internet connectivity is needed. Users only need access to use a local network.
• Documentation, like quotes or invoices, is readily available to clients.

Cons

• Depends on the hosting server.
• Web applications that rely on the Internet to transfer data rather than a computer's local hard drive may operate slower.
• Security risk of running an application of the Internet is more significant than when running an application on a standalone desktop computer.

Windows Applications

Pros

• Program can be used without Internet connectivity.
• The program runs faster as it sits on the local computer.
• Reduced security risks that might include hacking.
• Users don't have to compete for resources on the servers.
• Direct access to machine com objects.
• Cheaper over time.

Cons

• Deploying a .Net application might be tedious because the .Net Framework needs to be distributed and installed on all client computers.
• Platform dependant.
• Software can be pirated.
• Less chance of finding restrictions that the clients’ computer may have imposed.

Due to the fact that there is no clear winner, I suggest taking the following into account when deciding.

• Security
• Server’s hardware and software
• User’s machine hardware and software
• Geography of users
• Delivery and development times
• Downtime and maintenance
• Updates and patches
• Cost of development and maintenance

If the client has a smaller budget and needs an in-house application, go for windows applications. In all other cases, I prefer Web applications. With Web applications, I don’t need to go the client for debugging and maintenance so often. If the Windows application is flexible enough to be developed as a Web application, why not do that?

Written by Rudolph de Kock on behalf of QBCon.

For more information see the QBCon home page.

"When the pupil is ready, the master will appear."

In The Mask of Zorro Diego de la Vega puts Alejandro Murrieta through his paces. At long last Alejandro Murrieta completes the parry flawlessly. Before he can enjoy his success Diego de la Vega says one word, “Again!”

Repetition, repetition and repetition! Getting something right for the first time usually means that I remembered the steps of the process for the first time. The process becomes ingrained by repetition. To repeat a process is to perfect the process.

In my attempts to becoming a developer, the first thing I did was read a book. Learn C# in 24 Hours seemed a good choice. I thought reading would help me to develop applications. Sadly it did not. 90% of what I read was lost on me. Only now do I understand what they were talking about. One of the roadblocks was that I knew how to create web pages but I did not know the technical jargon. Speaking of aggregates and arguments only made me feel like begging them to speak English.

Guidance for junior developers is invaluable. Being left to one’s own devices is like being a classroom without a teacher for a year. The chances of passing the exams at the end of the year are slim if a syllabus was not followed. After a year of pointlessly suffering through allocated work I went into the design aspect of applications solely because I was better at it than at development.

A few years along the line I was bored out of my mind. A chance came my way to get back on the development wagon. At first I was not very excited about the prospect of developing again (keeping in mind the torture of not getting it right the first time), but my fears soon abated. A new manager, better understanding of how to allocate work and a better judge of proficiency made my second venture into the developers’ domain a pleasant experience.

Keep it simple stupid! (KISS) The acronym was first coined by Kelly Johnson and is still relevant as ever. I started out with Manage and Add/Edit screens. These were the least complicated parts of most applications, yet they contained a little bit of everything. Controls, data sources, classes, methods and stored procedures, each of these were a bit more difficult than the previous one. The next step was to start writing my own stored procedures. It took approximately eight hours of development time per page. After a month or two, the time was reduced to approximately four hours – not exclusively due to commitment, but rather to working smarter and not harder.

As I became more confident, the work became more complicated. For every four modules a more difficult module was assigned. Want to learn SQL? Try writing reports. In six months' time I went from knowing how to select a list of items from a database table to writing complex and dynamic queries that even I'm surprised at.

The last part of the success secret was a ‘work buddy’ who was assigned to me. My work buddy helps out at the stages where my progress was brought to a grinding halt due to inexperience.

For more information visit the QBCon home page.