stevedoria.net

After setting up and testing network monitoring software for one of our co-lo sites, it became apparent that mx.messaging.sprintpcs.com was rejecting connections from the monitoring server. I used typical methods, which include using telnet to connect to the SMTP port while analyzing the connection with a packet sniffer, to determine that the problem was with Sprint’s messaging server. It is fairly obvious that mx.messaging.sprintpcs.com closes the connection immediately after the initial TCP connection handshake. Another person shares his experience with this problem, and he can only wish that others fare better than him.

Dealing with Sprint’s front line technical support is pretty wearisome. The experience parallels the “our computer must be right (and you must be wrong)” scenario that was popularized throughout the 80s. One support representative stated, “You’re doing too much to send out text messages and making it hard for yourself.” I expressed my opinion that I would be better served by a person who did not see difficulty in resolving the problem. I was later contacted by a network engineer with knowledge of Internet protocols and using SMS over their SMTP server. He was better equipped to investigate the problem on their side, and he was very capable of helping me with any issues on my side. He actually introduced me to SenderBase, a spam monitoring service that is supposedly used by many large ISPs to minimize spam. The problem was ultimately resolved, and I continue to be a content Sprint subscriber.

One thing that I relearned from the front line technical support representative is the need to treat every problem with some attention. Because a problem seems typical, it is easy to resort to scripted responses. This might be a knee-jerk reaction that is rooted in a combination of both laziness and misplaced pride. Over the phone, the front line technical support representative sounded very authoritative with years of experience in her position and required some persuasion in forwarding my trouble ticket to a network engineer. Only through a more careful investigation can a problem be found to require a new solution.

I, too, served on technical support’s front line. Control of the conversation is very important. Effort needs to be made by both parties in keeping the dialogue from degenerating into a shoutfest. After all, in the typical case, the technical support representative accepts outbreaks from the outraged client as part of their job and simply shrugs it off at the end of the day. With a reasonably calm voice, it is almost always better to seek out solutions and keep communication open when forced to do so over the phone. Talking with a phone representative should always support the underlying objective of trying all available options, which is inhibited by frustration and raised voices.

“Few businesses are as spread out as MySQL, which employs 320 workers in 25 countries, 70 percent of whom work from home,” says Fortune’s Josh Hyatt in MySQL: Workers in 25 Countries with no HQ. A discussion of this can be found on Slashdot.

The development team of a small company that I have recently joined is continually growing, and coordinating development efforts within this team requires more than controlling file permissions. Using file permissions as a primitive means of source code control worked when the team was small, but simply using file permissions and a de facto standard of appending version numbers to modified files is becoming harder to manage as the team continues to grow. Maintaining such a hacked solution kludges the operating system’s permission control without the benefit of refined control. A more elegant solution is the use of a software versioning control system, which maintains file modification history as well as refined control over source code.

By adopting a common practice of big development companies, we gain greater project manageability. I do not believe that this will significantly affect our company’s agility, and the benefits far outweigh the costs. Training developers, who do not possess experience with versioning control systems, is a short-term cost that will yield long-term returns in the form of reduced development time and ease of project coordination. The deployment of a version control system is a strong indication that the company is interested in transforming individual developers into a team of engineers. I am a strong proponent of developing team members, and introducing them to new tools and methodologies increases their marketability to other companies and utility to our company.

Many companies worry that developing the skills of their workers results in increased turnover or wage costs. I am confident that we can continue to develop our team members’ skills as we continue to grow our team. Although our team members will become more marketable to other companies, I am also confident that each member of our team is dedicated to keeping it intact. Our company has a real interest in developing all its members, and deploying a software version control system to introduce tools to our team members and improve our development practices exemplifies our motivation.

What follows is a mini-howto on setting up the Google Web Toolkit on a fresh “Workstation” installation of CentOS or Fedora Core with Apache HTTP server and PHP installed. A series of commands that can be used to setup Google Web Toolkit. Although the howto is intended for environments that primarily use PHP, the information presented may be useful to others. The Google Web Toolkit installation process that is explored here will also cover the installation of Tomcat and configuration of Apache as a reverse proxy.

I. Installing Sun’s Java 2 Standard Edition Development Kit

II. Installing Apache Ant

III. Installing Apache Tomcat

III. Installing Google Web Toolkit

The required components are now installed on the system, however Apache Tomcat is currently not running. In Part II of this series of posts, I plan to cover the configuration of Tomcat and the configuration of Apache HTTP server as a reverse proxy for the Tomcat server. Init scripts will be set up as well. Then, in Part III, we’ll get to the more exciting stuff such as a “Hello World” application that uses GWT’s RPC features, which allow AJAX to be interesting within the Google Web Toolkit.

As a super administrator, being served some humble pie from time to time has its benefits.