Entries Tagged 'Ruby' ↓

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?

Today we had a meeting going over a few future projects and it was brought up we could integrate the new project into an existing project that had 80% the same functionality. However, there comes a lot more complication with this short of merge.

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?

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.