Hawaii's high-tech industry: now hiring!

The ICS Industry Presentation

On Thursday, November 20, seven companies local to, or with locations in Hawaii visited UH Manoa to share information about their companies, missions, people, and products. As a student of the university for only about six more months, I'm more motivated than ever to see what Hawaii can use me for, lest I become part of the brain drain to the west coast, which certainly doesn't have as nice weather. Luckily, I was pleasantly surprised by several facets of the presentations and hope to take advantage of the information and networking gleaned from the experience.

Oceanit

Scott from Oceanit started things off with his experiences that lead him to Oceanit. His presentation felt a little fragmented with its terse slides, but was interesting and he is an excited presenter. As with many companies presented, this company feels like a science think-tank, always looking for a great new idea. Also, like many companies, it is closely tied to military contracts which is of interest in today's times with our ongoing conflicts in southwest Asia and a new president and congress coming into power. I spoke with Scott afterwards and he noted that they were mostly looking for people with experience in image processing, which I'm afraid isn't me, but seems like one to keep my eye on.

Alion Sciences

The next presentation was by Darren and Sid of Alion Sciences. Another company with close military ties, they emphasized their experience working on modeling and simulation which was quite interesting. The presentation felt a little disorganized as they tried to share their time and delegate their speaking, but it sounded like an interesting place and they had some really good information to share. It still is impressive to me how close to the rest of the world Hawaii is today, such that meeting with team members across three states and 9000 miles is merely an issue of time zones.

Referentia Systems

From Referentia Systems Inc came a Austin, a recent UH Manoa graduate. Another company looking for great ideas, this was the second company in a row, and not the last, which made me think "Maybe Johnson is right!" Ant, SVN, Junit, test-driven design, etc are no longer complete mysteries to me and I feel like I am developing many of the skills that these companies are looking for. I spoke with Austin afterwards and definitely am going to look into their company some more. Unfortunately, I was "that guy" and managed to leave my freshly printed copies of my resume on my desk that morning!

Datahouse.com

I didn't get a lot of notes for this presentation, or the presenter's name, but I plan to look into it more as database issues are of some interest to me and an important field to experience. The presenter seemed a bit nervous, but knowledgeable of the company.

Camber

Presenting for Camber were David and Kevin who shared information about their First Responder Readiness System. They didn't have a Powerpoint presentation, but were perfectly able to share a lot of information about their company and their experiences with software engineering. Their focus seemed mainly on Ruby on Rails design, which I'm not familiar with, but am sure I can pick up.

Ikouza

I missed the name of the presenter for this presenter, who's company comes out of the Manoa Innovation Center, which I'd heard of, but didn't really know the background of beforehand. While the presentation was interesting itself, the information about the MIC and Act 221 I found to be at least as important to know about.

Concentris

The final presentation was by Larry from Concentris, another MIC related company. They again have military ties, though with a product viable for commercial use. The presentation was well put together, and he even had a sample to pass around. I always find it good to have a solid product at the presentation - that was a good touch.

Thank you to the presenters

My thanks goes out to the presenters who came to see us, and also for the cookies - I was kinda hungry after three hours! I really enjoyed the presentations, and was especially pleased to see that there are companies right here looking for people with the skills that I'm developing. I'm glad I made a good effort to be seen and heard during and after the presentations and hope I left a good impression. A very common thread throughout the presentations was the emphasis on failing is okay! Try, fail, LEARN, repeat, and succeed. That's how great engineers and great products come into existence. They wan't people with good skills, but more importantly a willingness to learn and expand and reapply those skills. I thinking I'm definitely up to the challenge and look forward to proving it very soon.

Show the world how a stack works using wicket.

A stack is a basic structure in the world of computer science. We learn stack implementation early and it pops up (no pun intended) again and again over the years. For the uninitiated, I've created a web application to demonstrate the basics of what a stack does. Implemented using Java and Wicket I present stack-wicket-aricwest. You can download the stack-wicket-aricwest.jar file from the featured downloads. Assuming you have Java 1.6 installed, open a terminal and navigate to the directory you downloaded the jar file too and enter "java -jar stack-wicket-aricwest.jar". This will start the Jetty server. Then open up your favorite browser and navigate to "http://localhost:703/stack-wicket-aricwest/" to begin playing with the stack. You will be able to push (non-empty) strings on to the stack and pop items off the (non-empty) stack. You can also clear the whole stack. A table shows the current contents of the stack.

Challenges

Though a simple application in theory, the challenges of learning a new tool, Wicket, and integrating example and base code into my distribution proved to be a hefty undertaking. All together I probably spent 12-15 hours hacking, debugging, researching, and optimizing. A bit more than expected, but a very rewarding experience. Of course I didn't make it easy on myself: the first thing I did when starting was reconfigure Eclipse to complain about just about every warning possible. This definitely helped me with my code most of the time, though there were a few warnings than I decided to ignore during this project, and some that I turned back off as I felt they did not really apply to my coding standards. Following are some of the challenges I encountered.

Classpath variables: We've gotten a lot of experience with this lately so I only encountered minor problems while getting these set up. Luckily I get a lot of practice because I generally work on two different machines over the course of a project.

PMD hates me: Useful as it is, I was particularly perplexed not by why I was getting warnings, but why the example wicket projects, some of which had the EXACT same code, did not get warnings. I wasn't able to quite figure this out from the pmd build materials, but they are cause for some concern on my part. Specifically in my StackSession where my stack is declared final since I do not actually modify it in that class. But an unmodifiable stack spooks me a bit and I need to figure out the process that allows this to be okay, since my webapp appears to work, or how to deal with this warning like the examples have. Similarly, PMD demands that my Jetty class be made final with a private constructor, which sounds fine... but why does Start.java in my WicketExample04 not get flagged. I'm not sure.

Only one submit per FormTester: This was a bit of a stalling point for me but looking through Google and Wicket in Action revealed that a FormTester is only allowed a single submit. Then it has to be remade. Kind of a pain, but copy-paste isn't hard.

Pick a port, any port: No not that one, it's being used. I definitely need to have a better method for port designation. It also wouldn't hurt, I don't think, for me to be able to specify the port at the command line, which should be a simple fix if needed.

Serialization: Quite simply, I need to review this concept and get a better understanding of why and where it needs to be used, but I was able to get by using examples.

Inner classes: For the most part did not have too much trouble with inner classes, though got caught a couple times by the issue of simply what it does and does not have access to.

Sessions: I'm still a bit fuzzy on these, and whether my application is properly using them. I was able to get separate stacks going using different browsers at the same time, but not with different tabs in the same browser, so not entirely sure if I'm hitting this requirement properly.

Build files: The build files that were cobbled together from various projects had some important differences. My build.xml contained it's own jar target which caused some unexpected results during distribution building. I also changed jar.build.xml to meet the requirements of being able to create the jar file and immediately run it in the same directory. The jar.build.xml actually puts the jar file both in the usual build directory, as well as the base directory. dist.build.xml also cleans up after running jar so that the jar is not including in the distribution.

Cannot pop an empty issues stack

Actually I'm sure there were others too! In any case, these, and dozens of little Wicket bits of learning added up to quite a chunk of time, but a lot of good experience with these tools. Overall, I'm impressed with making a working webapp, but part of me looks at this and thinks web programming can't really be that inefficient, is it?! For example (I think) the stack table gets completely rebuilt each time it changes. Also, it feels a bit dirty having basically my whole program in the StackPage constructor! I was very happy with my testing though. While some was reactionary, I am continuing to make the effort to do test driven design and coding, as I really see how useful it can be in the brief glimmers hiding behind old habits. I also continued to think about version control and continuous integration by creating a repository and diligently trying to always verify (I think I'm addicted to "Build successful") commits and submitting them often.

Due Dates 1.2 - email results and periodic querying now available

The Good

The newest version of Due Dates is now available for public and developer use! Several new changes and additions were made to the system to allow it to output queries to a specified email and also allow the program to sleep in the background and then requery and output results.

Implementing -console was quite trivial. I simply added a boolean flag that would be true if the -console command was encountered and allow printing to go as normal.
Implementing -email was a bit more involved. An email method was created that took an email and smtp server and created a message to send. To create the message, the print method that console was using was rewritten to return a String, rather than printing out. Then that string could be sent in the email message. I had some troubles with setting up the smtp server, not realizing just how that worked. My first test run it went fine, but from then on it wouldn't work, having been flagged as a potential spammer because I was trying to send it through mail.hawaii.edu, rather than my local ISP. After that was figured out, the messages all went through fine. I also had some troubles with the string being created and pmd disagreeing on my style. I ended up including several .append(" \n") with the space included so that pmd would not complain about adding a single character.
The -wakeup option was very satisfying to get working. Initially it had some problems that caused it to create several new DueDate objects each time the timer fired and really showed the weakness of the dependency between the DueDates and Console classes. However some tweaking eliminated the multiple object creating, though it does still perform an extra query in the beginning. Overall I was very excited and happy to see it performing a useful task!

The other thing that I found to be very satisfying is I didn't really have to touch any of the Lender classes. They were self contained enough to not care about the changes and additions going on in DueDates and Console, so that's a good sign!

The Bad

While the basic features were implemented, they are not very well tested. With the current design I found it difficult to test individual methods and classes as much as I would like and this will need some vast improvement. On top of that, my sensor data that I thought was working, apparently is not. It shows very little of my activity in the latest build despite hours of development, and dozens of builds and commits. Unfortunately I didn't realize this until too late to see if I could fix it, since the daily build was done at that point. The daily build was also failing, though the Hudson builds were still usually working. It seems there's a problem with what our test cases expect and what the daily build is doing.

The Ugly

The last week saw a complete breakdown in communication between Daniel Tian and myself. We discussed some design issues a couple times, but we have had disagreement over proper design of the project and tenets of object oriented programming. Busy with other work as well, we did not get much development in for the first several days of the project. I was waiting for him to commit some code changes he had been working on, but they didn't come in for several days, right after I started to begin making changes toward "my direction." Daniel then did some work on the test classes and cleaning up the code structure. Work really didn't begin on the new features until November 16. I began and committed some basic code for the -email method and shortly after Daniel made a slight change to it and that was the last commit I saw. I continued from there to implement the remaining features, working my way around the disagreeable interaction between DueDates and Console class, but not wanting to do a whole new transfer of code to fit my design ideas and cause further confusion of how the code worked. In the end, I got it working and did the wiki updates, but am very unhappy about the design and dependencies between DueDates and Console. It does not feel or look at all elegant and easy to maintain and update, at least to me. We just never were able to solidly hammer out a good design for the project so it's been a continual battle to steer the project in the right direction, and a battle we haven't been facing together. There's still time to get things straight though.

Hackystat and monitoring the "health" of a project

The latest tool being integrated into team orange's development of the Due Dates application is a monitoring tool called Hackystat. It's analogous to a hospital ICU patient monitoring system, but for software development. Various vital signs of a project are regularly recorded through various sensors embedded into developer's IDEs and code repositories. Hackystat can then display trends and latest statistics on the project including statistics on complexity, coupling, testing, lines of code, number of builds, developer time, and others.

assertTrue(this.version.equals(hackystat.getRequirements()))

After a bit of reading up on the material, I started first be setting up my local system to be able to report my usage through my Eclipse IDE, but immediately ran into a rather crippling problem, despite just a few very simple steps. The Hackystat plugin simply would not show up as an option to configure. I readded it several times, a bunch of Eclipse restarts, and a couple computer restarts, and double checked the instructions and my version of Eclipse against the requirements. Later, realizing/told that I was using a older version of Eclipse, 3.3.0, rather than the newer 3.4.0., though Hackystat required only 3.3.0, I installed the upgrade. At that point, Hackystat worked with no problems, so I notified a Hackystat developer about the situation.

Saved again

Having gotten the hard part out of the way, I was able to get start exploring the interaction between my projects and the Hackystat collection tools, which tended to be pretty verbose! At this point my partner had already set up Team Orange's data collection, but I went over it again to make sure everything was in place, which it appeared to be. For the most part the process was smooth but I did get a stuck a couple times with issues in /.hackystat/sensorshell. The first one being, I couldn't figure out where it was. I was a little confused about how it got there, how Hackystat found it, and what I could do about moving it since it was automatically created in a dreaded directory-with-spaces-in-the-name. Then, I seemed to miss the part about setting three variables, but saw the part about if this is your first time you won't need to change anything (else). I was rather perplexed for a time that I could not find the server. Eventually though my partner was able to get me back on track and Hackystat sensors started to pick me up on radar under all of the different build tools.

Our mostly healthy project

After seeing the first build, the project was appearing pretty healthy. Low complexity and coupling, over 80% coverage, though no real work in the last 24 hours. From there, we've gotten to see a few more days of monitoring. Due to some changes with handling, our rather intensive test suite and some design changes, the coverage had dropped off dramatically. Most other stats were healthy, so it's no cause for panic yet, and should pick up soon. I personally haven't had too much opportunity to commit code lately so hoping to get some of that done this weekend, and hammer out some additional details with my partner about our design and testing. I'm optimistic the results will boost our project well into the healthy range, and hopefully no major surgery will be necessary.

Expanding code functionality - introducing Due Dates v1.1!

Having some success with the previous incarnation of the DueDates-orange project, and some tragic failures in our testing, wiki guides, and issue tracking, my project group was tasked with adding some additional functionality to Due Dates. This included a new library to query, as well as the new options -sort and -within that would allow for more customized reporting of results. We also started using a continuous integration tool called Hudson.

Welcome to Hudson, the weather is currently sunny!

Right away Team Orange got together and set about adding our project to Hudson, however, we made just a little checkbox error and ended up spamming about 70 commit logs over the next few hours. Other than that little hiccup, I found Hudson pretty useful for getting a second opinion on my project with each commit. I also enjoyed looking at the other projects and seeing how they were doing, and where other people were running into problems.

I have issues

My first task was to create a list of issues for this iteration of the project. Having learned a bit more about issue management, I went about making a large slew of issues regarding designs we had discussed and each of the new feature tasks, as well as issues for problems that had not been properly raise and resolved in DueDates 1.0. A large number of issues were added, some would end up being invalid, but nearly all were completed. I tried to break them down into small components, however some were more general to account for common wide-ranging commits such as Javadoc updates.

Why is this class doing this?

We did have some trouble pinning down a real solid design for the application. New features and realizations caused several major changes during the course of working on 1.1. Though we've had a pretty good idea on how to implement the project since the beginning, and have worked very hard to make it expandable, there were a lot of cases where we decided certain functionality needed to be moved around. Some times these moves could cause infamous huge commits that would lead to collision problems later.

See you... online

As a team, we weren't able to meet too often unfortunately. Busy schedules and somewhat opposite productive hours (Daniel is bit of a night owl, me not so much) did cause some problems, but we were generally able to iron things out. Always exciting to log in and see what happened while you were out! Despite being fairly productive on the project, I definitely see how much time could be saved working as a pair. There were a number of times when code was committed that would have been caught by the other person immediately if we were pair programming. I personally had several other big projects to work on for school and wasn't able to make commits every day, but rest assured, I certainly thought about Due Dates every day, often making charts and coding on paper in other classes! *hides*

Passing the test

Currently the two biggest issues the project has is proper testing and proper exception handling. Daniel implemented the vast majority of this code and we are both still pondering if they are properly done. The tests take quite a bit of time due to the many log ins to lender systems, but they are fairly thorough. I'm sure we'll come back to these in the future.

Conclusion

Overall, I'm fairly pleased with the DueDates-orange project. It's grown quite large and I know there are improvements to be made, but I think the functionality is pretty good and the design will allow for quick implementation of new features. We've also greatly improved the wiki guides so that the project can be used by other people as well, not just our two-person world. Stay tuned for the latest news and avoid late fees!

DueDates code review #2

It was time for another round of reviews of various DueDates projects in my software engineering course. We had a few problems with the last round of reviews - some difficulties with Google Project Hosting - but learned that some upgrades had just gone in that would make things a bit smoother. Well... I didn't seem to lose any of my comments as I was reviewing DueDates-Gold, but I never seemed to have received a review from Jeho Jung and Yasuyuki Kaneshige of DueDates-Green who we had submitted a request for review of our own project, DueDates-Orange. I'm not sure what happened - whether it was a problem on our end, or Green's, or both, or Google's. I also managed to have left my comments to Gold on revision 39, while Daniel Tian, my partner, ended up with his on revision 40.

In the mean time, I did comment (and I hope it was received) on DueDates-Gold. I had actually previously review this code and was pleased to see a bit of clean up on their part, though I did find a few minor issues and suggestions. Their developer and user guide is very nicely put together, and a good thing, because I had numerous difficulties with the initial developer set up, before I read the instructions! Also I found the use of the ArgsParser to be very interesting and definitely will consider using something prebuilt like that in my own program. The Javadocs also appear to be quite thorough.

For the most part though, I think that their design needs a lot of work. I don't believe it will expand well to the addition of new features and new libraries and lender querying tools. Some methods need to be broken up and separated, while the classes in some areas need to be much more focused and possibly the introduction of some new classes. Their testing also needs to be much more thorough since the emma scores were all in the teens.

Having not received any reviews for my own system, I'm a bit saddened. I know it has a lot of work to be done, and we know what many of the issues are, but another perspective is always very handy. Hopefully next time, as I'm sure there will be!