Category Archives: Development

Development related topics

The Double Save

Posted on by

I just finished proving my residency as a Colorado state citizen for some continued education. I needed to do this so that I didn’t have to pay out-of-state tuition fees of over $1000.00. While the staff at the Community College were trying to change my status to resident they went through all sorts of heck with generic error messages that didn’t help and java dialogs asking them if they wanted to try again until either their computer crashed, their computer became outdated, or the miraculous happened and things actually saved as they were supposed to (I am not making up the number 48 when I say they had to try 48 times to get things to save).

What really concerned me though was that the staff had been trained to get things to work by saving the information twice. You see the first save worked, but the second save refreshed the information from the database. Whomever coded the sorry Java/Oracle/Pergatory application was too lazy to write the code correctly and failed to understand the need to refresh tainted data. If people use your software please don’t train them to double save. It just isn’t worth keeping your code around if you work that way.

Quite the Character

Posted on by

I am amazed at how fast character arrays are compared to their string alternatives in every programming language I’ve ever used. This shouldn’t be a huge surprise but I thought I’d point out that by switching from Standard Template Library strings to char arrays in C++ on a project I’ve got going things sped up from around 25 seconds to process 55,000 lines of files to 15 seconds. Furthermore, in Java, using threading and database insertion on a previous project I was able to get even more performance increases (it was an older version of the runtime, and I switched from String to StringBuffer, which is basically an array). In JavaScript, If you have to accumulate characters into a buffer, I strongly recommend using an array and either pushing the data (if you can afford to not support IE 5) or using arrayVar[arrayVar.length] = value;.

By learning to think this way you’ll have faster code out of the box, which is always nice because it means you don’t have to spend time refactoring. You do refactor, don’t you?

Thanks to Tony Nuzzi for the String->StringBuffer conversion in Java, and Craig Kaes for helping me to better understand char *pointers and char arrays a little better.

The ‘Less is…’ Controversy

Posted on by

Within the last couple years I have gotten more into design methodology, planning methodology and the evaluation of code quality verses quantity. I read several blogs that attempt to broach this subject: lesscode.org and 37signals‘ blog. They’ve had a disagreement recently, which is fine, its none of my business… I don’t care. However, Jason’s post that I read about 2 minutes ago reminded me of something: Steve Wozniac. Steve was the keynote speaker at the Gnomedex several years back and that speech was presented as an MP3 on IT Conversations. What really grabbed me about his talk was not just the funny stories, which were sometimes hilarious, but also the that he took the limitations of his components to be a challenge of their optimization. If I can only have X then how can I make X as fast as possible? This is the mindset that all hardware designers, coders and product developers should have (unless the device is SUPPOSED to be slow 🙂 ).

Learn how to write already faster code. For example read books on speed optimization so that when you code you automatically use the loop type that is quickest for the language in your scenario (that means you need to know what type of loop is fastest in what scenario). I know in PHP that various appending operators for text strings are faster (‘,’ is faster than ‘.’), using single quotes instead of double quotes makes the page get processed faster because double quotes are always parsed for PHP variables. I recommend that you learn your language, know why C++ uses character arrays instead of string objects on a more basic level. In fact, learn why Java does that as well… if you’re using Java. But learn it and know it, you’ll be glad you did, and so will your employer if you have one. And if you’re self employed… this should be old news for you.

Do You Need This Feature?

Posted on by

A client has been evaluating various bug tracking software, and one of the packages, Mercury Quality Center, is written with many Active-X controls. Strangely enough they have a thesaurus button on the bug entry dialog. My co-contractor and friend Matt had the following to say:

Did you notice that the defect entry screen in mercury has a thesarus button?
Why do you need a thesarus when entering a defect… to find another meaning “the darn thing doesn’t work”?

I agree whole heartedly and want to know why someone would put a feature like that in a piece of software that requires clarity and precision for entering in bugs. Quality assurance means reproducing the bug, the developer fixing it, and then quality control confirming its fixed. A thesaurus is not needed for that processes.

Can Vs. Should

Posted on by

Recently a support request for WordPress came up on the wp-hackers email list I subscribe to that reminded me of one of the big delimas of programming (and frankly much of life): If you can do something, should you do it? There is a big, and valuable, movement in web design called contingency design. This design approach says, “Given Murphy’s Law of things going wrong, what can we do to prevent that from happening?” In general this is a good principle. However, it is not a law. You need to find areas that are useful for your time, things that help where 90% of the people will need it. In programming misconfigured machines can cause ‘bugs’ that are really just the result of a misconfiguration. In design it is possible to spend extra hours working on things that do not help the end user because only 1 person in 10,000 will ever do what it is you’re working on and they don’t need to do it.

This is basically an issue of prioritization and evaluation of what is vital and what is extraneous. Sometimes in interface design choices are made that make the development process quick, however, the end user is not thought of. In this case usability is so bad users might not use the feature at all. In other cases users might misconfigure the software simply because the interface is poor. Make priority judgments based on:

  • Quality
  • Cost
  • Time

Note:Thanks David O’Hara for showing me this ‘triangle of evaluation’
Realize that you usually can’t have something that is of the the utmost quality in a very small amount of time, or that if you design something that takes more time to develop because of quality needs, the cost will go up.

Just because you can do something doesn’t mean you should do something.

Firefox 1.03 and Web-FX’s Internet Explorer Emulation Code

Posted on by

If you use the Web-FX IE emulation code and users hit your site with Firefox 1.03… it’s not going to work. I don’t fully know what happened in the Firefox code but you can replace all instances of ‘this.[javascript object or parameter]’ within the extendEventObject function. Due to not being certain of legalities that are involved in posting corrections of others work I’m not going to include the corrected file. This library of code is also used in the coolbars2 code so you’ll need these changes for that as well. By my testing the changes are backward compatible to older versions of Firefox and Mozilla.

Hope this helps others, because it freaked me out 🙂

Getting Real… Most of the Time

Posted on by

In Getting Real: Ignore details early on Dan Boland of 37Signals, a reputable design and usability company that is breaking into the developer services market, shares about how important it is to rough out the details first and to not get bogged down by details. This is critical in most design and development situations. I’m going to warn of this one caveat: know your clients. If you’re going to build your own application, which is generally the focus of Dan’s article, you can work on the roughing out, and then get down to particulars and this would be a smart choice. However, I recently made the mistake of doing this on a client project and it did not get me any favor with the client. Because as we got closer to the release date they saw lots of features that were rough rather than fewer pretty features. We ended up nailing all of the needed features and they’re pretty polished, but it did not go how the client had expected. I learned a lesson in this and thought that others just might benenefit as well.