Next to keeping up on latest technology, keeping ones programming skills sharp should next on the list. Simple things like going back to the basics can be mentally rewarding.

Applying some of the basics was helpful to me as there is this system challenge at work. Seems there are problems with too much information, duplicate information, not enough information, or information going to the wrong place.

This is about duplicate information. Seems this client / server application is sending duplicate messages from point A (client) to point B (server). The real fix is to correct the problem at it's source. But after several days of getting nowhere, with the exception of learning more of system internals, the thought to prototype a solution and present it to the engineering team.

So here we go, back to basics. Essentially the problem statement is:

/*
 Send a record into the function.
 Check that record against each record in the alarmArray.

 If that incoming record is already in the alarmArray,
    1)Return with bad status.

 If that incoming record in not in the alarmArray,
    1) Shift the array down by one.
    2) Add that incoming record to the array.
    3) Return with good status.
*/

The code:
int checkDuplicateRecord(char *inStr) {

static char alarmArray[10][512];
static int  firstTime = 1;     
int i = 0;
int found = 0;

   //printf("checkDuplicateRecord: %s\n", inStr);

   /* Clear out the static char alarmArray once. */
   if(firstTime){
     memset(alarmArray,'\0', sizeof(alarmArray));
     firstTime = 0;
   }

/*
 * Search through the 10 elements of the alarmArray.
 * If it is found, it is a duplicate.
 * return 1
*/
   for(i=0;i<10;i++){
      if(!(strncmp(inStr, alarmArray[i], strlen(inStr)))){
         //printf("Duplicate record do not send: %s %s\n", alarmArray[i], inStr);
         found = 1;
         return 1;
         //break;
      }
      else{
         //printf("Non-duplicate record, continue: %s %s\n", alarmArray[i], inSt
r);
         found = 0;
      }
   }

   if(!(found)){
      /* Push all records down by one */
      strcpy(alarmArray[0], alarmArray[1]);
      strcpy(alarmArray[1], alarmArray[2]);
      strcpy(alarmArray[2], alarmArray[3]);
      strcpy(alarmArray[3], alarmArray[4]);
      strcpy(alarmArray[4], alarmArray[5]);
      strcpy(alarmArray[5], alarmArray[6]);
      strcpy(alarmArray[6], alarmArray[7]);
      strcpy(alarmArray[7], alarmArray[8]);
      strcpy(alarmArray[8], alarmArray[9]);
      strcpy(alarmArray[9], inStr);
   }

   if(!(found)){
      //printf("It is ok to send this alarm record.\n");
      return 0;
   }
}

So, I chose not to use a loop pushing down the records by one element. No real reason other than having a good visual representation of pushing down an array element.

The language is in C, though I mixed the C++ comment character //.
Though that a 10 X 512 sized array will meet the needs.

The runtime test worked out pretty well. It ran for over an hour with no problems. The next step would be to re-type this code into the client code and test. In short, keeping solutions simple, going back to programming basics can serve a programmer well in correcting system problems.

Ubuntu, Hp-2000 and what happened to my Unity desktop functionality

Last weekend, I spent most of the afternoon and early evening trying to recover my Unity desktop functionality. Somehow, it became somewhat unusable.

For example, when a terminal was opened, there was not title bar and it was positioned at the top left of the computer screen. Same for FireFox. To make matters worse, neither could be moved around on the desktop.

After a few frantic hours randomly looking at Internet posts from others with a similar problem, I took a chance and downloaded  this "compbiz" thing from Ubuntu. Once up and running, this "compbiz" eventually solved my problem.

Little to my knowledge, just about everything on the Unity desktop is configurable. Somehow I managed to mess up my configuration.

The "Window Management" section of "compiz" allows the Unity user to configure many window terminal settings. These include placement, default horizontal and vertical sizing (to name a few). This essentially saved the day and really needs to be in the software tool box for anyone using Ubuntu and Unity.

While it was in the "broke" status, one Internet post suggested to re-install Ubuntu. Yeah right, good idea. One other feature that "compiz" allows Ubuntu Unity enthusiasts is to size those little icon thing's (program launchers) on the left hand side of the computer screen. That was found to be really helpful.

In other news, I'm now on Ubuntu release 13.10. It was a seem-less download and installation process. Would you believe this is what my disk looks like.

 frank@HP-2000:~$ df -k
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda2      476783624 9987184 442554164   3% /
none                   4       0         4   0% /sys/fs/cgroup
udev             1805636       4   1805632   1% /dev
tmpfs             363144    1136    362008   1% /run
none                5120       0      5120   0% /run/lock
none             1815712     156   1815556   1% /run/shm
none              102400      40    102360   1% /run/user
/dev/sda1          94759    3360     91400   4% /boot/efi

Ubuntu, HP-2000, and disabling the touch pad

The last post mentioned of my troubles with the left palm contacting the touch pad, then, sending the mouse pointer off in random directions. Well, correction, it is my right palm. The centering of the touch pad is a tad to the right.

Well, thanks to the System Settings, the touch pad is now disabled and it is with the mouse only. That has been very helpful. Funny thing that needed to be fixed last night was the icons for the Trash and other items in the System Settings were not present. They were invisible.

Thank you INTERNET posts and troubles that others have had. Simple cycle the System Settings -> Appearance -> Theme, then  ambiance setting. The cycling to the other settings corrected that problem.

Ubuntu and HP-2000

Want to try a distribution of Linux? Want to run Linux on a brand new, fast HP Notebook, lots of ram, lots of diskspace? How about creating this system as a dual boot so you don't have to trash Windows 8. Sounds fun, right? Boy was I wrong.

Someone did not do their homework. That would be me. Seems the web is full of horror stories of geeks wanted to dual boot Windows 8 and a favorite release of Linux. These horror stories are out there and no need to repeat these here.

Getting to the end of the story, rather than trash a perfectly good Windows 8 distribution the option was to purchase an exact disk of same type, size, manufacturer and swap it in. Off to Office Depot for a Seagate 500 GB. This will give lots of room. In fact, I never see this disk ever filling up.

Over the course of several attempts, eventually, I downloaded ubuntu and made a boot disk from a usb thumb drive. From this usb, ubuntu can be booted. Just tell your bios to look at the usb as the first boot device.

Once that was done and the new blank hard drive was carefully, repeat carefully installed, this really nice and new HP-2000 booted from the usb. Once ubuntu loaded, there were a few prompts to get me up and running.

Thank you ubuntu, I am a fan.


Notebook Computer Type: HP 2000.
ubuntu 13:04
Memory:     3.5 GiB
Processor: AMD E2-2000 APU with Radeon(tm) HD Graphics × 2
Graphics: Gallium 0.4 on AMD PALM
OS Type: 64-bit
Disk: 488.3 GB

That's right, 64 bit. It's really fast and modern. Just one tweek about this HP-2000. My left palm somewhat sits on the left side of the touch. At times there is palm movement which in turn sends the pointer off on it's own. But that is cool, I can live with that.

Hiking with or without a camera and/or GPS

It has been awhile since a hiking blog entry. Partly due to not wanting to hike in Southern CA due to tic's and bugs. Let's not forget the poison oak, yeah, that took two weeks to heal. So, I waited until a trip to Kauai to pick up the hiking again. I did manage to work the hiking muscles and stamina by simple power walking around the neighborhood. As wimpy as that sounds I think the effort paid off.

So on this Kauai trip, Pihea, Waipoo Falls, Moalepe Road (Trail) and Sleeping Giant East were the trails.

Pihea Trail
This was the first hike of the trip. Started at the trail head at 0530, just before the sun came up. Ok, on this one, I did have the camera and GPS. I wanted to baseline the mileage to the Pihea junction and see how much further it was to the vista. Some of the going got fairly tough and the GPS had to be stowed away. Eventually, reached the vista and broke out the camera. Figuring it being first thing in the morning provides good opportunity for the early morning colors.

So took a bunch of photo's, some camera video and marked a geodetic marker that has been there since 1927. This is only my second time on Pihea so I figured to pack the camera, GPS, bottle of water and some energy bars (unneeded).

With pre-disposed knowledge that I wanted to hike without electronics, extra time was dedicated to enjoying the sights and sounds of the morning, making the effort to slow down and leave the electronics in the bag. With that, it was a good hike. Back at the trail head, there was no one present, so took the liberty to locate and find a geocache that I missed last trip. Guess, what, found it and took a picture. Also guess what, did not use the GPS because I know what area (tree) it was near.

Waipoo Falls
This was the second hike of the trip. It was a late afternoon hike with my friend Robert. Left the camera and GPS in the car. Leaving the items in the car was a good decision as it allowed me to better concentrate on the hike and absorb the Kauai forest. It was in the late afternoon so there was no morning dew on the ginger leaves which also tends to bring out the fragrance. Surprisingly, the only others we saw were two folks that had completed this portion of the trail and were making their way out.

There was about 2 hours before sunset as we started. Got to the upper / lower fall's in a short time and spend some time there enjoying Waimea Canyon. The afternoon shadows were very interesting against the far side of the canyon walls, making the steep valleys look very deep. On the way back, we did a Black Pipe Trail detour to a small bend, then turned around.

Not having to lug around a pack was nice, did not lug any water either. This was with full knowledge that the trail is well established, hiked using the buddy system, and we were not going to be out for over an hour and it was cool. Those factors removed much of the risk of hiking without water.

Noticed that the red head cardinals hang out in pairs, decided to make a mental note of that.

We ended this Kokee trip by going to the rest of the lookouts, stopping by the last lookout (on the way down) that was in total darkness, with the exception of the bright star's. Off in the lower distance a goat was heard doing his/her goat baah'ing thing.

Moalepe Trail (Kuamoo Rd [580])
A mid-morning hike with camera and GPS. But I left the GPS off. The camera stayed in the pack until the return  trip. Here is where I planned to record bird sounds. Thinking I invented a new word (birding), nope, someone figured that one out too. At the "paved" end of Kuamoo Rd [580], there is a parking area with this cool water crossing, suitable for most cars, that's right cars, if the water is not too high.

This is just about a two mile round trip so it does not take that long. Mid-morning time was an ok time to start, though, capturing bird sounds would be better earlier in the morning or later afternoon. Temperature was mid 80's and comfortable. There was a couple up at the picnic table when I arrived. I gave them the privacy of the area and instead wandered the perimeter of the vista taking photos and enjoying the scenery. Once they left, I took over the picnic table to hydrate and hang out.

A few minutes later, started back down torwards the parking lot (one mile, down hill) with camera and iPod ready to record bird sounds. Find that bird sounds is relaxing to listen to. Eventually, I'd like to be able to stream in these recorded "voice memo's" and set up a endless loop, well, maybe an hour's worth of looping audio.

Sleeping Giant East
An afternoon hike, no camera, no GPS. Since I had done both westerly ascent's, doing the Easterly ascent was the route I really wanted to try. The hiking books mentioned that it is steeper than the Westerly trail (it is) and not as long. As far as the physical part, I did find some areas tough, but overall it was very rewarding.

Having no camera or GPS,  just a water bottle, this allowed me to really focus on the hike, sights and sounds of Nonou Forest Reserve. I did miss the Cook Pine's as these tower over you in certain parts when doing the westerly ascent. Would I do the easterly ascent again, you bet.

Conclusion
I've found that hiking with a camera I am looking for that stunning digital photograph to take, so I am not in appreciation of my surroundings.

With a GPS, I find that my concentration is on the GPS signal so that I have a good track to upload into Google Maps. If overall location safety is a concern, a GPS is a must have, especially if there would be some unintended bush wacking involved.

Without electronics has the advantage of being lighter and able to move faster. Less weight (as little as my pack weights) the trail experience factor is slightly better as is the post hike pain.

Water, the water concern is that if the hike is longer than 2 hours and if it hot, bring water. Else, leaving it in the car would be fine, just do a good chug before hand - maybe two good chugs of water and let it settle a bit before starting.

Learning Java and Process Builder

While working on a project at work, a simple gui was needed. So I used Netbeans to create the gui. Eventually, I'd need to either code in or call previous coding projects. These would be two stand alone Java programs and a C program (exe).

Before I continue, I'd have to mention that one of the stand along java programs would have to (and does very well) interface into a scheduling tool. This scheduling tool is a cots product. Generally, this tool will start predefined files or scripts at the predefined times. The interface to this scheduling tool is generally to get a connection to it, read the data (it comes back in a result set), and parse the data. Don't forget to close that connection. Sounds like a database. It is very similar.

Back to the story, there was a short learning curve to re-acquaint myself with how to run a stand alone Java and a C program. The learning curve and internet shows there is the ProcessBuilder way, and the Runtime.getRuntime().exec("java Main"); So I used both. Not a big deal, it was a good learning experience. If I was to deploy this code, I'd be ok with using both methods.

What I did find was the program, when run within netbeans, I could not find where netbeans wrote a default file as I had not defined a full path. Your saying, "dude, this is in that netbeans project top level directory." Now you tell me. So as that story went, using the brute force method, "find . -name "myfilename.txt" {} \; Well low and behold, there it was, just like you said, in the netbeans top level directory of this project. This was a good lesson learned.

The overall design of this project is the the gui contains several jtext areas which have predefined text (strings). As the user chooses an item in each of these jtext areas (Mouse Click Event), that chosen string finds its way into a String outStr = new String. As each item is chosen across each of the jtext files, they are concatenated with a comma. Basically, the output is a String of text and is separated by comma's.

Once all the jtext areas have been looked at and the outStr is complete, the user presses a Load button. This load button essentally takes that outStr and puts it in a buffer which is then written to a outfile. It is written to the outfile when the user presses "Send".

Now this Send does three things. It is the Event Handler that writes that String to the outfile.txt, then runs (java-program-1) which reads the outfile.txt and creates a special input file for that scheduling program. Next (c-program exe) is called which has some special calls that serve to load that special input file into the scheduler. Finally, (java-program-2) reads the scheduler and presents that output to the user. This is to give the user a confirmation that the scheduler in fact has the data. It all worked out pretty well.

The other concept that was a good lesson was the use of creating jar files for those two java programs (to store the class file). Also, the need to code a c shell script which will set the necessary environment, CLASSPATH and all that good stuff. That latest lesson took about 4 hours to learn from trial and error. Sure, the internet is full of good stuff. But this customized application and my development environment is something that is not on the internet.

So the bit take away's were: If you don't specify a full qualifying path, netbeans writes it to the project top level directory. Second is to keep an open mind and expect to write a shell script, it will have a CLASSPATH, other environment stuff and will call you jar file. Oh, by the way it is these scripts that were called with ProcessBuilder and/or the getRuntime.exec().

Learning Java and a fileWriteUtils() class

As a companion to that fileUtils() class that in retrospect should have been named fileReadUtils() here is the fileUtilsWrite(). Class naming convention was broken as this should have been (and will soon be) named as fileWriteUtils().

File name and class name convention is pretty important to maintain. Makes development easier as there is less to remember. You don't need to figure out, "well is it fileUtilsRead() or fileReadUtils()...all other classes end in "Util" should I make an exception here"? So catching these early on and making the effort to achieve overall coding consistency is the way to go.

And of course once this is instantiated as:


fileUtilsWrite fileUtW = new fileUtilsWrite("fullPath","string to write");

Off it goes, runs fine and writes the string to that file on the C drive. It's pretty clear that there are two Strings being sent to the fileUtilsWrite() and those are not being used, just a heads up. Using this inside of a larger program, I suppose what needs to happen is:

1). Figure out the file name (calling program would need to manage that).
2). Assemble the String that needs to be written.
3). Either instantiate or call the class.

That's it.

Here is the code:

public class fileUtilsWrite {
    public fileUtilsWrite(String outFileName, String outFileText){

    String strFilePath = "C://Users//Frank//WriteStringAsChars.txt";
    String outString = "hello world-\n";
    outString = outString + "                string 2, -\n";
    outString = outString + "                string3, -\n";
    
   try
   {
       FileWriter fstream = new FileWriter(strFilePath);
       BufferedWriter out = new BufferedWriter(fstream);
       out.write(outString);
       out.close();
    }
    catch (IOException e)
    {
       System.out.println("IOException : " + e);
    }
}

Learning Java and a fileUtils() class

And it is 2013 and this is the first blog entry of the year. There was a urban conditioning hike that happened, more on that in a separate blog label.


Continuing on with the re-learning Java topic, seems I needed a small program that read the files in a directory and placed those file names and their full qualifying path name into a jTextField. So as this was being coded I thought, good time to add to that to a fileutils() class, later decided a fileUtilsWrite() class is needed too.
As things will have it, this fileUtils class will just return the filenames from the directory. As a prototype class, it is fairly instructive.This particular file does in fact NOT return the full qualifying path name of the files. That code went into yet another Netbeans project.



Writing this fileUtils class went pretty quickly. Most of that is a cut/paste from the Internet (why re-invent the wheel). The challenge was that the calling program, or the uitest.java (as it is called) needs to be able to read off the file list one by one. There were a few complications so I settled on reading in the files into a vector (vc), then using the object oriented nature to pick these file names off, one by one. This is how that is done:


        System.out.println("uitest: " + fileUt.getSize());
        for(int i=0;i<fileUt.getSize();i++){
           System.out.println("uitest: " + fileUt.getFileName(i));
        }

Here is the code for reading the directory and placing the filenames into a vector.

public class fileUtils {

   public fileUtils(String szendsWith){

   System.out.println("fileUtils:");

   

   File folder = new File("c:/");

   File[] listOfFiles = folder.listFiles();

   for (int i = 0; i < listOfFiles.length; i++) {

      if (listOfFiles[i].isFile()) {

         System.out.println("File: " + listOfFiles[i].getName());

      } 

      else if (listOfFiles[i].isDirectory()) {

              System.out.println("Directory: " + listOfFiles[i].getName());

      }

      if(listOfFiles[i].getName().endsWith(szendsWith)){

         System.out.println("File: " + listOfFiles[i].getName());

         vc.add(listOfFiles[i].getName());

      }

   } 

   //System.out.println("fileUtils: " + vc.get(1));

}

   public int getSize(){
       size=vc.size();
       return size;
   }
    
   public String getFileName(int i){
       String fileName;
       fileName=vc.get(i).toString();
       return fileName;
   }
    
    private int size;
    private String szFileName;
    public  Vector vc = new Vector();
    
}

But wait, there's more to come, it is the fileUtilsWrite() class.