Ext.extend and Conquer

Today it was a very productive day.

I’ve redesigned several problematic screens of an application into more functional versions, working much faster, providing more information to the end user and – the best thing – with a very consistent appearance on their layout.

ExtJS provides some nice features to standardize its components by extending its standard classes.

The simplest way to do that is like what I show on the code snippet below. It simply provides some default values – that can be easily overriden when the custom component is instantiated – that help with the implementation of sets of components.

var myCustomCombo = new Ext.extend(
        width: 180,
        mode: "local", // I load the data manually from the store.
        triggerAction: "all",
        emptyText: 'Choose an option...',
        autoSelect: false,
      editable: false
Ext.reg('mycustomcombo', myCustomCombo);

I did custom implementations of panels, forms, combo boxes and grids. With that, I make only slightly variations from one case to the other – imagine addresses, where you have several different components from the country up to the zip code for a street, avenue, square, etc.

The new layout also made it possible to eliminate different pages and consolidate all the information on a single page where all records could be browsed, edited, removed or new records could be added to the database.

On the backend – my TurboGears application – my code also shrunk considerably as I didn’t have to make some convoluted queries to get the information. All modules were better decoupled and obtaining the information using AJAX – or better AJAJ since I don’t use XML but use JSON – much easier through a cleaner interface.

Summing up: it was a complete redesign of a whole module in a day. Some hundreds of lines of code eliminated and functionality added to the system.

I hope that tomorrow the day becomes as productive as today.

An AJAX option to remember

I always forget how useful is the “$(<selector>).load(‘url’, {para: meter});” function on jQuery.

It is really a problem solver when loading HTML structures.  I am converting some old code where I got HTML fragments to replace some existing content on the page and using the usual process, I’d have to do the AJAX query, call a callback procedure and then there I’d replace the contents of the section / div / whatever I wanted.

With jQuery.load I can do that on a single call and in a more effective way.

Silly thing and so simple that I always keep forgetting about it.

Starting a mercurial (hg) remote repository

I always forget and have to search for the correct order of things here…

There are some VCS — as in Version Control System — (and DVCS, where the “D” stands for Distributed) where you can create a copy of the repository on your own system and then somewhat easily move it to the server or copy it there using the VCS software itself.

Mercurial seems to require that the thing be done in two stages:

  1. Create the repository on the central (reference) server
  2. Clone the repository on each workstation

So, here are the commands that should be run to accomplish that:

At the reference server

hg init <repository_name>

At the workstation

hg clone ssh://user@server//path/to/repository/<repository_name> <local_name>

Yes, it is that simple…  But since I work for a long time on projects, I always forget to double the slash after the server name while cloning and that I need to create the repository on the server “first”, to later start working with it locally.

I could probably do the opposite and revert the clone order, but then I am not sure if “push” and “pull” would be switched or if something else would be required to make them work.

KDE 4.2 on OpenSuSE 11.0

Continuing with updates from Factory, I’m now using KDE 4.2.

Several things have improved, the interface is as clean as 4.1’s was and I feel that some things take less resources.

It is worth a change for anyone running KDE 4.x to update to KDE 4.2.  But be aware that some configurations might be lost, so backup your settings before the change, just in case. 🙂

On what to do prior to contact another company’s tech support

I work for a company that does off shore for other companies from the same group.  There are two types of activities that are done worldwide (100+ countries): internal support and support to external business partners (mostly clients, some suppliers, etc.).

As I work with networks and data transmission, and I lead a team that interfaces with external business partners almost 100% of the time, it is common to get some support requests for problems that really aren’t our problems.

It is something that is annoying because when there is a problem — specially in production environment — we need to stop working on everything else and solve that.  Out of those, 99.999% of the times the problem isn’t on our end: we work with thousands of business partners and have the structure in place to work with them: servers, network, firewalls, etc.  Everything is working fine, debugged and stable — there are some destabilizing changes from time to time, of course, but those are rare and very well tested.  Then, there comes the question from the external business partner: “We can’t connect to your server.  What did you change?  We need to submit that data today!”

Last time this happened, I had a meeting with an Indian company from 1:30 AM to 3 AM here…  And what was the issue?  They could manually submit data, but their automation couldn’t.

Anyone that can solve a hard problem — such as adding 2+2 — can see that there is something wrong with that and that something is probably at their end…  But no, this didn’t happen.  So, we scheduled a meeting and after one hour asking questions and asking about changes, they said that they changed the server: manual process (working) was from one host, automated process from another.  When asked to manually test from the new host, it didn’t work as well.  The problem?  They changed from one server to another and didn’t update their own firewall policies…  And then, it is our fault… 🙂

Second time there even was a paging sent to our team: data corrupted.  Oh well, the customer had to fix it and not us as we don’t change data in any way.  Even within our own company, business first assumes it is our fault and then we have to insist to have them go to the customer.

Now, back to the subject:

  1. Make a change procedure, schedule times, analyze impact, etc.
  2. Keep a backup of all of your changes.  Never demise the server after the change, you might need something from it back or reverting back to the old server in case something goes wrong
  3. Check everything that has to be changed (servers, configurations, user profiles, firewalls, IP addresses, etc.)
  4. Have a “recent changes” log and don’t assume that one change is irrelevant, specially when talking to other companies trying to solve a problem
  5. Check your company first: go to your IT team or contractor, ask what has been changed, why it worked before and what is exactly the problem you’re having
  6. If it is a connectivity problem, check that you can connect to other sites that provide a similar service / interface, check that you can get out of your network to the Internet from the same host that will be used and that is presenting the failure
  7. Supply the support team a traceroute / tracert output from the failing host to their server

Give the support team from both companies enough information to solve your problem.  Guessing is too time consuming, error prone and isn’t something specialists like doing without enough information to discard the most obvious problems first.

“Help us to help you”, I always say (no, I didn’t create this expression, but I really enjoyed it!).

Changes @ Work

Lots of things happening lately.

Several big projects that required a lot of attention, a new team has been assigned to me — so now I’m leading my old team and the new one — and I have a third team to put together…

Besides all that, there’s the marriage that is closer: April 18th, 2009.  🙂

I hope to be able to post more, though…