Mobility Worker Nirvana

The title of this post could probably read as “the pursuit of working anywhere on a budget”. Since I work from home I figured that it means that I can work from anywhere. I have been looking at some possibilities for the last few weeks on where and how I could work from elsewhere than my home office.Connectivity is quite important since I do all my work remotely. I need to be able to connect to servers in different locations to do my work. Rarely can I work in an isolated mode. Here they are only a few options if I want to get wireless access from anywhere. Rogers has a modem for only $99CAD plus the data plan. Maybe that could be the solution. The only thing it needs is a power outlet. We will test and see.

Requirement Based Testing

This morning, I went to a Borland Seminar about Requirement Based Testing (RBT). I don’t think that we can justify the spending for the tools that Borland propose to achieve this concept but none the less the information was very valuable to me. Sometimes the simplest concept are the most effective.The first thing they said that got my attention is that a requirement that you can’t test is not a valid requirement. You simply need to reword it to be measurable. So the requirement of an application to be fast is not valid but saying that step x can only take y seconds is valid.

The other thing that they repeated over and over was traceability. You need to be able to see the link between your requirements, the test and the results. That is where their tools helps you greatly. Doing all this in a spreadsheet is the poor man solution to it.

I also liked hearing that you need to have the least amount of test case for your requirements. Simplify! If you have more than 5% of your test case on a specific requirement you should look at it again.

Something else that I will mention that I liked was the fact that your tester, developers should be made aware of all the requirements early on and when you make changes to them you have to communicate them effectively. The goal to get everyone on board early on is to avoid the separation of the teams and the “ennemy mentality” that “sometime” happens.

The last funny tidbit for me was the mention that 60% to 70% of work in IT is actually rework. Work that will not get used or you are simply redoing what you (or someone else) has done. So easy to believe without any need for proofs.

Blade Boot

BladeBoot seems to be all that I am doing this month. It is an IBM technology to use the builtin NICs in a blade to iSCSI boot from SAN. A little bit of firmware update, a java app to configure the NVRam of the NIC (you can also do it with DHCP) and you need a SAN with iSCSI. IBM has good documentation on how to do it with Windows and with Suse Linux. The only glitch we had to fight with was that the MS iSCSI software initiator that support boot to SAN was not available at the link advertise. I found it by “mistake” at the EmBoot site. I downloaded the WinBoot/i software and it is part of it. On the Suse installation we are waiting for the SLES 10.0 sp1 to address the need for a DHCP server. As with many technology it looks much better on paper than in reality but we have a good start now.

My first Servlet

Servlet programming has always been something I was curious about. Starting this project was a bit ackward since there is plenty of documentation but nothing to hold your hand in what I was looking at. Too much struggling convinced me to write down how to do it for a very simple servlet so I could go from there.I used Eclipsei 3.1 as my Java IDE and I use Tomcat 5.5.x as my Servlet Application Server.

  1. Creating a new project in Eclipse
    This should be a basic task that is quite easy. I called my new project HelloWorldServlet (great craetive title). I then created a new class named “HelloWorldServlet”. This opens the file in the editor and I entered this source code in it:

    import javax.servlet.*;
    import javax.servlet.http.*;
    public class HelloWorldServlet extends HttpServlet 
        static final long serialVersionUID = 1;
        public void doGet(HttpServletRequest request, HttpServletResponse response)
            throws IOException, ServletException
                PrintWriter out = response.getWriter();
                out.println("Hello World through a servlet!");
  2. Importing the servlet librarySomething that took me a little while to figure out is that I needed to add the servlet library from Tomcat to be able to properly compile but to also get the proper dynamic help in the Eclipse IDE. Under my working space directory I have a lib directory where I copy the common libraries that I use. The Tomcat servlet-api.jar was copied over there. You then simply right-click on your project in Eclipse, go to “Build Path” and click on “Add External Archives”. You simply browse to where you have copied servlet-api.jar and you now have the library imported.
  3. Unknown tidbitAfter adding this external archive it highlighted the fact that I need to have a “static final long serialVersionUID”. This is for the serialization of the object but I am not sure what value, if unique, it should have. I only added it as I was told without looking for too many answers right away.
  4. Compiled and copiedI compiled (ctrl-b) my servlet and copied it to my Tomcat box. Under the Tomcat default directory there is a webapps directory where you have to install your application. I made a new directory simply called “HelloWorld”. Under that directory I created a “WEB-INF” directory. Under the WEB-INF directory I created a “classes” directory where I copied my .class.

    The directory structure currently looks like this:

  5. Application declaration In the WEB-INF directory I had to create a web.xml file containing this: <br>&amp;lt;?xml version=”1.0″ encoding=”ISO-8859-1″?&amp;gt;<br>&amp;lt;!DOCTYPE web-app<br> PUBLIC “-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN”<br> “”&amp;gt;<br>&amp;lt;web-app&amp;gt;<br&gt; &amp;lt;servlet&amp;gt;<br> &amp;lt;servlet-name&amp;gt;HelloWorldServlet&amp;lt;/servlet-name&amp;gt;<br> &amp;lt;servlet-class&amp;gt;HelloWorldServlet&amp;lt;/servlet-class&amp;gt;<br> &amp;lt;/servlet&amp;gt;<br> &amp;lt;servlet-mapping&amp;gt;<br> &amp;lt;servlet-name&amp;gt;HelloWorldServlet&amp;lt;/servlet-name&amp;gt;<br> &amp;lt;url-pattern&amp;gt;/HelloWorldServlet&amp;lt;/url-pattern&amp;gt;<br> &amp;lt;/servlet-mapping&amp;gt;<br>&amp;lt;/web-app&amp;gt;<br>

    This file declares my servlet name, class name and URI. Since everything is the same here it is quite simple.

  6. Calling the applicationThe fun part (when it works) is calling the application and seeing the end result. Since I have already declared in my web.xml that the URI is HelloWordlServlet calling it in my browser was as simple as entering “http://serverName/HelloWordlServlet/&#8221;.
  7. A few more notesBecause I was not perfect on the first try I had to reload my application after each change I made to the class file or to the web.xml. Important to reload otherwise the cached version is what you keep seeing.