960 gridder and jQueryUI

March 17, 2010

When I coded today I did not understand why jQuery UI elements did not work. I tried everything, and I was sure my code was right. So, finally I began to systematically make the file I was editing as simple as possible to get to the bottom of the error.

Guess what? jQuery UI function worked when I disabled the 960 Gridder I’m using on my current project. Bummer. That was 4 hours of debugging right there. But I learn.

Did I find out exactly what caused the bug? No, I didn’t want to try to do that. And, tho worst thing, I did not have the use of the jQuery UI function after all.

Well, Thats it. If you have the same problem, remember: 960 may be the cause.


Learn Best Practice, don’t settle for them

March 11, 2010

I’m always trying to find what they call “Best Practice” on the problems that occur when creating a website, but they are not always easy to find on the specific problems, and sometimes they are a little bit hard to understand. For example, a lot of Best Practices are described in so-called Patterns, a template of how to build your website, but these Patterns is often hard to understand – especially if you’re trying to force them into your code. When you code a bit, and you get into a problem that one of these patterns append to, then you often understand why this is called a best practise and learn it. When you have learnt it, you can then use it and modify it to match your project in a better way.

I recently read the article Your Website is Unique. Don’t Settle for Best Practices. at Future Now, giving a little more insight at why not always settle for the best practice(when you want to increase conversion rate). The main idea is that your web page is unique, and that you have to use whatever changes that makes it unique instead of going for solutions that are made of someone else. I’m taking this idea further, to the stage when you are coding your site, instead of optimizing it.

Dont get me wrong. I still love best practices. I still are going to look for those problem solving patterns. They might be much more important in the back-end than in the front end. The thing I’m going to make sure to take into consideration is, if these best practises are best for my unique site, and that they don’t make my ideas become a copy of someone elses. Code as you can, so that you understand your code and are able to modify it with ease.

Test your code, and consider other programmers solutions after you fully understand them.

As an example, I can take the first guest book that I “programmed”. I didn’t know PHP very well back then, and had never used MySQL to store anything – so this was really basic. For me it looked like code I did not understand, so I copy pasted it, modified a bit, and got it to work – but I did not really understand it. So, when I now look back at that code, I se how flawed it was, because now I know how to code it. Even thou that guest book code was made by a programmer, based on some good practices at that time, I did not learn or know about them back then. When I look back at it now, and understand the logic, I see that even the original script was flawed, because it do not match the criteria I’ve now learned to be good code.

So, are you an experienced programmer, your code are probably mostly very good practise. Are you an average programmer, you’ll probably learn a lot from these experienced programmers. But if you are a unexperienced programmer, learn first the basics, understand the code of average programmers, and strive to achieve understanding of good code. This way, you can make your site your own. I consider myself average, that is trying to achieve what experienced programmers can do.