If you do this, you are guaranteed the following:

1. It is easy to maintain and understand the code you wrote months later
2. Chances are your application will not be the quickest in response
3. You will make use of techniques you fully understand than trying to adapt ones that you are unfamiliar with and may implement wrong

So how does JSON differ from returning XML in your AJAX requests? Lets first look at the advantages of XML.

1. Standardized and easily serialized into via .NET
2. The XML is easy to read all within itself
3. You can make use of XSLT, DTDs, etc

How about disadvantages of XML?

1. It is slow in comparison to JSON
2. It can be clumsy when not designed properly

Now for the advantages of JSON:

1. It is faster than XML to parse in JavaScript
2. There are addin’s you can install in .NET or a library in PHP to serialize a JSON string from an object
3. It is hard to make this clumsy as it is based on the Object Design

And the disadvantages of JSON:

1. It is harder to read the serialized output
2. You can’t use XSLT, DTDs, or something of the sort to validate or style the request

As for myself, I am a JSON person. I didn’t used to be though. My original AJAX applications were focused around XML primarily because I could make use of an XSLT and I always validated against a schema. However, JSON has won me over due to speed. JSON’s speed is just ridiculously fast and it showed when I converted a major application over to it. I saved nearly a third of the time it took to do a fairly simple task.

However, pick the poison that you understand most, otherwise, it could have detrimental affects.

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?

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?

For example, what happens if two people are working in the same project on two different pieces. The first person is finished with their piece and checks it in happy as can be, while the second person finishes later and his change needs to go in ASAP, while the first person’s change can’t go in till the end of the month. Now what?

Now in a perfect world, one would state that the first person shouldn’t check in their code till it can go in, or person two would get the previous version of the first person’s code.

At work we decided to keep the projects separate and not consolidate them even though it would share 80% of the functionality for the UI. But in the end, it allows us to not step on each others toes.

So my question is, how do you handle this?

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.

The majority of problems start with the lack of analysis, or the complication the analysis turns up. This afternoon, I was meeting with one of our tech system guys going over a support issue we received when a co-worker dropped by to hash out his new issue, which brings me to this blog post.

Analyze, Analyze, and then Analyze again! Analysis is a major part of every project and it something that should be taken seriously and completely is at Central (where I work). My co-worker had done quite a bit but had major questions about the project and the path he found best so far, primarily, would the data set he wanted to achieve be too large to handle efficiently. So, considering one of our tech system guys was already at my desk, and I am a bit of a SQL genius myself, we hashed it out.

We estimated that in the worst case scenario we would be approaching 15 MB of data, which is fairly large. However, during our discussion we also established that the data would only need to be pulled out of the database once per day. Now that is very important! Think about it, 15 MB is nothing if all you need it is one time. If you have to call it 25 times a day, that makes a hell of a difference.

However, the code path my co-worker choose would have made him pull out the data 25 times. Analysis with others, or re-analyzing your project due to the questions you are left with should be taken seriously. If the data your application is going to use will never change for 24 hours, then program it so it take advantage of this tidbit. Persist that data outside of your storage solution to reuse throughout the day so you do not have to hit up the server to retrieve that data over and over again (in a sense, cache it).

If the data might exceed a decent size to cache (ie: 15 MB), then write it to a flat file and open, read, and close immediately thereafter. That way, you still only pull the data from SQL Server once, and for the remainder of the day you work with the flat file.

By all means, keep your co-workers informed and when questions arise, talk out your solution with them to see if they have any better ideas, or agree with your approach.

This evening Mark and I were having a bit of a debate, he was asking how to execute .NET code in the HTML designer, and I personally wanted to say “It’s not possible”, but went ahead and told him to use < % code here %>. Of course, I then proceeded to warn him of the danger that will present in the future and the fact that it is bad practice to do such.

So let me explain to everyone why it is necessary to separate code and design.

1. Reusability
   Let me present fact number one, by separating design and code, you are forced to write code in a more reusable manner. For example, with the separation you are likely to write a placeholder on your page, that you will use the CodeBehind page to write the output (or for PHP, in a class you call).

   Now the idea is to build an object for your data, something that can be reused by numerous applications. Yes, I know what you are thinking, this data will never need to be reused, why can’t I just write the code in the design? You say it can’t be reused now, but just give it a few months and when someone asks how to access your data, you will feel pitiful. ALWAYS write your code as if everyone would want to use it! Anyways, you have your object of data, and then it is up to each application to determine how they wish to display it. Thus, if you do not incorporate it directly into the design, it is entirely reusable in any fashion, form, design, etc. Thus point number 1.

2. Maintenance – Updating
   By placing your code in a separate file from your design, you can achieve easy maintenance and updating of the design without having to rewrite significant pieces of code. How site designs has your company been through? Are they looking into going into Web 2.0? Will they likely rebrand if bought? Will users complain about the complexity of the design and seek an alternate way of access their data? All these are things to consider at design time and at code time.

   How cool would it be if all you had to do was alter the CSS and the HTML to implement the new design, all of this is possible when you separate Code and Design. At work, our sites are made just like that, and I am damn proud about it too. The fact I can just a few lines in the stylesheet and show off an entirely new looking site just rocks! Unfortunately, very few know this and every so often write code that doesn’t quite flow with what I try to achieve.

3. It’s Easy!
   Why not separate design and code? If you are using Visual Studio for .NET, you are an IDIOT not to separate them. Visual Studio makes it easy! Binding objects, datasets, etc to just about every possible control you can think of, and you aren’t doing this. You think it is overkill? Well its’ not. It was designed this way intentionally to ensure the practice of separating design and code get utilized into your coding lifestyle. So if you feel it is overkill, GOOD. You are doing exactly what the developers of Visual Studio wanted you to do.

There are many more reasons, and everyone typically has a personal reason for separating code and design, what are yours? Why do you do it, or not do it?

For example, imagine having the ability to upload 1000 images for all of your products using cpCommerce or a different cart variant. You would have to upload them individually. Now, take a look at how kiosk handles it.

Let’s take a look at the Kiosk Image Area located in the Administration Area. This area has many options, but look at the intriguing “Find FTP’d Images”. Now that is what I am talking about!

Now, this is the folder where the images are stored in Kiosk. Look carefully, and you will see a folder named “FTP”. This is the folder where your 1000 images should be uploaded to.

To show you that this works, I have placed over 600 images in the folder! I realize that isn’t exactly 1000, but it should be enough to prove it will work with 1000 as well. Now, that I have the images placed, I need to head back to the Administration Area to complete this process.

Back in the Images Administration Area, I clicked on the “Find FTP’d Images” and this is what you will be presented with! Now realize, only one process of this is able to run at a time. So if you have 4 people updating the store, when one person runs this command, it will prevent the other 3 from running it too. With that said, the process also checks to see where in the process it is. For example, it checks every few seconds to see if it is finished inserting the images, or if it is still running. Now, I know what you are thinking. What about the Time Out Limit in PHP? How do you get around that? Well that is my secret and you can’t figure it out unless you pull down the Source Code from the SVN Repository.

Finally, when it is all said and done, you the user are prompted with this final screen. The process is complete.

Upon clicking on “Close” it will reload the page to show all of your images now listed within the application. That’s it! It doesn’t get any easier than that! Feel free to comment and leave your remarks, as this is going to make kiosk stand out from Joe Smoe and you got my word on that!

Images are entirely reusable. So if you want to show a Product’s Image as the Category Image too, YOU CAN! And you can do it without uploading another file! I like to think kiosk is taking what cpCommerce started and taking it to a whole new level learning from its’ mistakes, and hopefully you all agree.

Well that is enough on that for now, I will update everyone once again, when I have these sections entirely done. Then you can pull it from the kiosk subversion repository and give it a try yourself.

I wrote a few sample scripts using it in less than 5 minutes! 5 minutes!! I cannot stress that enough. I was amazed at the type of complexity I could write in just a few minutes of using it. Now, I am not a “big” M$ fan, but I am willing to give credit when due, and they deserve credit for this. I am truly pleased with the fact it works in Firefox, it works in IE, and it probably works in Opera (though I haven’t tested it). It has files for all languages, to handle currencies, dates, etc. Totally amazing.

I have so many plans on how to use this to perform more advance functionality in several of my applications and best of all, I didn’t have to write my own XmlHttpRequest methods.