What's the use of coding standards?

Fri, 12 Nov 2010 07:35:00 +0000

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!

Wed, 20 Oct 2010 11:20:00 +0000

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

Wed, 08 Sep 2010 11:53:00 +0000

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:

Wed, 08 Sep 2010 11:39:00 +0000

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

Thu, 02 Sep 2010 07:53:00 +0000

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?

Tue, 31 Aug 2010 10:39:00 +0000

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.

• 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.

• 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.

• 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.

• 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

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

Fri, 27 Aug 2010 11:49:00 +0000

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.

“Suddenly you’re like a pirate, you’re 65 years old and you’ve got an ear-ring....”

Thu, 08 Jul 2010 09:20:00 +0000

I just love this quote. It shows us our unchanging ways and how we stick to something for the sake of sticking to it and after careful consideration we might find that something that held true for years and which we either liked or came to depend on is no longer relevant.

This is maybe the biggest challenge I find as a leader, to continuously challenge the process and to refine it, redefine the reason and to improve on it.

In my team we continuously investigate all processes and try to either improve on them or at least see whether they still hold true or whether we are just doing them for some legacy reason. Processes are only relevant if they still hold true.

Here is an example of our revision when it comes to tracking development work and bugs.

“We need prisoners to interrogate, and that tends to work best when they're alive”

As with prisoners you also need to keep bugs in a location so that they don’t “escape” and cause mayhem. We I took over the department, bugs was handled in a spreadsheet that was mailed around and everyone could do one, add one and it was expected that every developer would test his own bugs / work and bugs was only reported and added to the sheet after the publish was made to the client. This means that most of the bugs were reported by the client. (Not so good)

I started looking at the process and it was very inefficient and costly. Sometimes the same bug would be fixed by two developers, communication on the process and progress was shoddy and we often had recurring issues.

The process was insufficient

The first step we took was to centralize the logging, progress tracking and assignment of bugs by creating a system we call “Devlog”. This meant that all bugs was hosted in a databases and that developers would only do the bugs that was assigned to them or in some cases where the developers were faster than I could allocate work they could claim bugs. This tool has now evolved to where it helps with overall planning and resource allocation.

This process seemed to work really well: in the beginning. Soon loop holes appeared and bugs would still be recognized too late or developers would not test their own work properly.

The process was better, but had loopholes

I soon realized, as a developer, I would test around the conditions that made the software work and users tested a completely different way. Since there was no way I could sufficiently do Hallway testing I decided to hire someone to do my QA (see our blog on QA). So my Quality assurance department was born. Rules were wrote up, reports styled and we would soon dedicate time for every developer to give their work QA for testing, and we would allocate time before any release for testing and bug fixing. This meant that most bugs were reported internally and the client would never see 90 % of the issues instead of reporting 90 % of the issues.

The process delivers results

Soon we had less bugs, better turnaround time, and due to the QA reports being official and used in every developer’s revue we had less bugs and software that was developed faster and better than ever before.

“The Code is more like guidelines, really”

Although this is a small part of our entire development process and even our current QA process, it is a critical one and we continuously look to giants like Microsoft, Apple and Google to see what they do differently and how we could take their processes and apply them to our business. Taking into consideration that we don’t have Google type budgets, man power or timelines there always seem to be some tweaking to a process to get it to work for us, but it does help us to see that one fact holds true. Even though a process might be sufficient today, it can always be optimized tomorrow.

Visit the QBCon website.

INTERNET EXPLORER 8: COMBINING CSS, TABLES AND DIVS TO SOLVE ALIGNMENT ISSUES

Thu, 08 Jul 2010 09:11:00 +0000

The main difference between IE7 and IE8 seems to be that the alignment is all messed up in IE8. Although the alignment issue isn't ideal, IE8 has improved support for various web standards, especially cascading style sheets. Cascading style sheets is separate content from presentation. This will be our starting point. For this solution to work it is necessary for the presentation to be defined in external style sheets.

Step 1: Referencing the external Style sheet

In Example 1 an external style sheet is referenced and inside the tags a