Kirkman Enterprises

I should start this post before the center-piece of it gets too far out of date.  On December 12, the Austin-American Statesman published an article about the lack of people with software development and design skills in the Austin area.  It was somewhat interesting, to me, that in this article that the Greater Austin Chamber of Commerce is trying to encourage the University of Texas and the Austin Community College to do more to produce skilled programmers.  A number of questions came up in my mind as I read the article.

While other students on campus have been studying hard for finals this past week, I have been relaxing and catching up on unfinished business.  Thanks to my classes this semester being project classes I'm all done.  There has been a project at work I had been delaying on to finish my class projects.  (And yes, contrary to some people's beliefs, I am employed by the University doing actual work.)  The professor I work for is not looking to replace me with another computer science student who can continue to do software development for him.

Whenever I go through a phase of updating my resume and publishing it to various sites (as I'm doing these days), I'm quickly reminded about how much I find job recruiters to be irritating.  It generally seems to me that recruiters don't care about my time or being straight and to the point in their communications.  Maybe it has to do with there being a lot of people looking for work.  Maybe I'm just being overly sensitive.  I figured that since I have this blog, and my resume links to it, I'd do a little venting in hopes that perhaps recruiters will understand why they are so irritating to me.

 I talked about this a year ago.  If you've ever looked at my resume or portfolio of work, you know that I have an interest in mainframes.  It all started in 2006 when I was introduced to IBM's "Master the Mainframe" contest.  It was only in its second running back then and only a couple thousand students participated, if that many.

 I've been meaning to write an update for this blog for a number of weeks now.  I've been happy with my progress with developing the business' website with Groovy on Grails.  I'll try to talk more about that below.  Aside from a few fixes and additional enhancements, the alpha version of our web-based application is completed.  Progress with the business itself has been slower than I'd like.  That is both a good and bad thing.  It's good, because my desired pace would likely be faster than would be good to ensure the business is a success.  Part of the lack of pace was our business partner being busy with his day-job and recently accepting a new job in a city across the state.  So, now my professor and I are communicating with our contacts for a new business partner to get things going again.  Other than that, the site itself has shaped up well and developing it with Grails has not been difficult.

 I've been posting off and on about the website I have been developing using the Groovy on Grails Framework.  Friday afternoon, I walked out of my office at school with a smile on my face.  I had just sent an e-mail to the professor I work for and our business partner telling them that I had put an early version of the site on our research group's web server.  I've come to like developing in Grails.  One of the requirements of the web development framework for me was integration with pre-existing Java code.

 As I mentioned in my last posting, I was unhappy with how Apache Wicket constructed URLs for the pages within the web-based application.  I did not see an easy solution to the issue, therefore I began looking at other alternatives.  To recap, I'm looking to develop a web-based service for a potential business that is based on a Java application that I have been developing for more than a year.  I would like to use, potentially, a substantial portion of the code from this Java application in the web-based service, therefore the framework for the site would need to be able to handle Java code.  I think Groovy on Grails may be the answer.

 A month ago I started evaluating Apache Wicket.  My end goal is to find a Java-based web framework for use in a online marketplace that will serve as the basis for a business I am attempting to start up with a couple of partners.  I first attempted to use Spring based upon the many site that suggest it was a good framework as well as the number of job openings that required the knowledge.  I found the material to learn the Spring language to be deficient and moved on.  That's when I started looking at Wicket.  After a month of working with it and creating a web-based survey, I think Wicket is a good framework with a number of resources to aid someone to easily learn how to use it, however, it does have a few deficiencies.

 A couple weeks ago I expressed my frustration with the Spring Framework and its lack of tutorials and information for those new to the framework and web frameworks in general.  I read up a little on other Java web frameworks and decided to evaluate Apache Wicket.  Wicket does use Java for the backend processing.  Web applications built with it can run on web application servers such as Tomcat.  At first I was afraid that I would toss away Wicket for the same reason as Spring.

 A week or two ago I mentioned the possibility of starting one or two businesses.  The first one would be based on research I have been doing in regards to MSDL (the Manufacturing Service Description Language).  In the research, I have been developing stand-alone Java based applications.  The reason for using Java is because we are heavily dependent upon the OWL API, which is a Java based API for working with Ontologies.  Now that I'm looking ahead to moving this work into a web-based service I have been looking into implementation options.  Of the different web-application frameworks I figured using a Java-based framework would be best.  My thinking is that it would be better to implement the web-based application directly in Java as opposed to creating the web pages and make calls to the Java application stored on the server.  Researching Java-based web-application frameworks it seemed that Spring was most popular; therefore, I decided to attempt to learn it.