Entries Tagged 'JavaScript' ↓

This weekend has been a nice relaxing weekend for me and so when I got back home this afternoon (on Sunday the 16th), I was in a great mood to refactor some of my kiosk code base. Now, I should start by saying, I decided to refactor code instead of write new code tonight because I wanted to lessen the number of files that needed to load in the Ajax functionality.

Kiosk, uses Ajax in interesting ways to provide a better experience, but with that, the Ajax applications were built as each page was assembled. This caused functionality across pages to get a bit messy or functionality shared across pages to get thrown into individual files. Well the problem with individual files, is that is yet another file for the browser to download.

So before I get any further, let me discuss refactoring and how it can solve many performance binds your application may be experiencing.

To start off, refactoring is taking common code, or code that is used across pages or frequently and moving it to a more global location so it can be called easier and the code only has to be written once.

So where can this help?

• First of all, by refactoring code into a single global file, you can limit the number of HTTP requests if that file is accessible via the web. Since your common code is in a single file, the browser only has to fetch that code once, and will then likely cache that file for each page after, giving you even better performance.
• Secondly, by placing the common code in a global method/function, you are writing less code. As now when you need to call that code on your second page, it is already written, so just call the function. Otherwise, you would need to write the code all over again.
• Thirdly, less code equals smaller files. By refactoring your code, you can have smaller file sizes and in turn that is quicker to download, quicker to parse, and quicker to execute.

Now in my situation, I took about 4 JavaScript files and combined them into a single file adequately named “general.js”. The file contained code to automatically log the user out after a set amount of inactivity in the UI (User Interface). Secondly, it contained the version checking mechanism calls that see if they are running the latest version of the software. Unfortunately, those are the only two things it does right now, but as the project progresses, I am sure more utilities will get added in this file.

My next task is to refactor the Data Grid functionality so it is 1) XHTML, 2) easy to build complex columns with complex rows, 3) customizable by identifying StyleSheet classes for the columns and rows. Hopefully, I can get my head around this idea and get it working with little trouble to the programmer.

So what can you think of that you need to refactor? What performance gains do you suspect you will achieve with the refactoring you do? Any performance markers?

Ever have to argue Ajax versus Socket Connections? Me either. Today, I had the chance to talk about the differences, their advantages and their disadvantages.

Ajax has many advantages. You do not have to parse content/page headers, you can parse XML, you can build objects out of JSON serializations, and above all there are a lot of frameworks that are cross-browser friendly so you do not have to worry about writing the framework yourself.

A Socket Connections’ advantages are much smaller in my opinion. There is no browser limitations, which is a major advantage, keeping it browser independent. It can support any type of response content, JSON serializations, XML, HTML, strings, etc.

So what about the disadvantages? Ajax has the complications of cross-browser friendliness, but that has been removed by frameworks doing all that hard work for us. Ajax’s biggest disadvantage is probably the lack of JavaScript standards being followed by each browser. Though this is removed by using popular frameworks, it matters for the rest of your JavaScript code to setup the Ajax event.

So how about Socket Connections? Socket Connection have the complication of trying to figure out where the response data starts and where the response headers end. Secondly, they are language dependent. Not all languages support sockets and some may make it very complicated to use them though, whereas, Ajax is getting easier and easier to use.

What are your thoughts?

File and project naming has been a massive debate at work lately as we teach newer employees the greatness of OOP. On my way home, I had an epiphany, and so I just had to write it out. So here is the best file naming reason/description you will ever read:

Your file names should describe your work without the developer having to open it to figure out what it does. In OOP, you should define your parts/pieces first, and then your object in individual classes. For example, you may find a class for Driver, Vehicle, Liabilities, and then one for Quote that incorporate the previous three. The names are meaningful and you do not need to even see the code to understand what is in them.

Now that file naming is covered, how about project naming? In all honesty, I am less concerned with project names than file names. But, they are important none-the-less. Your projects should describe your collection of classes in as few words as you can muster together. For example, the above files might be under the project name “QuoteEngine”. Why? Cause they are the pieces that allow a quote to process and are likely to include the methods for actually submitting a quote as well.

Should your projects include acronyms such as DABL (Data Access/Business Layer)? I personally do not think so. If you have to physically describe it is the (Data Access/Business Layer) then your tiers are not neatly organized enough and you need to separate them better, or better define your classes to help resemble which layer you are in.

Well that is my two cents for the evening.