Today, I finished my last assignment required in my final class required to earn my Certificate in Geographic Information Systems from Penn State. This is a 4 course program (11 credits – all distance learning) that generally takes a year to complete (or at least it did for me, with a break for last summer). What can I say about the program for anyone considering it? Simply put… it has been a great way to learn more about GIS systems.

The program consists of 3 required courses (The Nature of Geographic Information, Problem Solving with GIS, and GIS Database Development) and one elective, for which I chose to take “GIS Programming and Customization”. The first course is an excellent way to build a strong foundational knowledge of geographic information systems, and I certainly learned (and retained) more from taking it than I would have gleaned from reading several books on the subject. The courses that followed used ESRI’s ArcMap product to further teach GIS concepts and procedures with hands-on exercises to illustrate how the course content could be applied.

I have to admit I had some initial concerns during my early stages in the program regarding so much of the content being centered a round ESRI’s ArcMap product. I’m certainly not picking on ESRI as a bad choice, as their products are impressive on many fronts, and they do have quite a significant market share, so it is not exactly as if it would be a waste of time, I was just hoping for a vendor-agnostic education. Having gone through the program though, I do see the strength in focusing on one product to use as a teaching tool to dig more deeply into the possibilities of what can be done with GIS. Though the exercises may contain steps specific to ArcMap, the important concepts learned are not specific to any tool, and can certainly be applied when using other products available in the marketplace.

Speaking specifically about the latest course I took, GIS Programming and Customization, it starts out fairly easy for an experienced programmer, but becomes more challenging as it progresses. The ArcMap Desktop Object Model Diagrams are 81 pages of tiny print, and it often seems like what should be easy to accomplish in ArcMap with automation is terribly difficult until one pays their dues learning the OMDs. The course offers a lot of help though in familiarizing one’s self with the right way to do things, and it even provided free access to some of ESRI’s own training. Overall, well done.

Where to go from here? I’m excited about furthering my studies and work in GIS. The courses up to this point focused on GIS on the desktop, and I would really like to pursue more with regard to web-driven GIS systems development and geospatial database design. I think I’ll take some time working more extensively with some of the open source products and working more intelligently with the free web services available. ESRI’s web server based offerings are also of great interest, and I am likely to be doing additional work with them in the near future. Summing up, the classes offered by Penn State are a great addition to anyone’s GIS education and I’m glad I took them. I highly recommend them to anyone who has the interest in this field.

I have been using AppFuse 2.0 to create some applications that read from legacy databases. Under AppFuse’s standard configuration, you can populate the development application with sample data by adding data to the sample-data.xml file located in the src\test\resources directory. In my case, I have several data tables that contain appropriate sample data, so my real chore has how to easily get a subset of that data into the sample-data.xml file.

Groovy to the rescue.  Groovy has an XML MarkupBuilder and supports metaprogramming such that I was able to create a relatively generic script that would create an XML file in the proper format, the contents of which I could paste into sample-data.xml.

Here is how to use it:

1. Install Groovy if you have not already. Easy to do, the download and all the instructions you need are at http://groovy.codehaus.org/.
2. Copy your database jar file to the lib directory of your groovy installation. In my case, I use Oracle and I have groovy installed in C:\sdks\groovy-1.5.5\, so I copied ojdbc14.jar to C:\sdks\groovy-1.5.5\lib.
3. Create a groovy script file, let’s call it create-sample-data.groovy. Copy and paste the code below to your script file:

   import groovy.sql.Sql
   import groovy.xml.MarkupBuilder
   
   def tableName = "customers"
   def sqlString = "SELECT * FROM customers"
   def fileName = "customers-sample-data.xml"
   
   def fw = new FileWriter(fileName)
   
   def sql = Sql.newInstance("jdbc:oracle:thin:@localhost:1521:XE", "username", "password", "oracle.jdbc.OracleDriver")
   
   def getColumns(sql, sqlString) {
     columnList = new ArrayList()
     sql.query(sqlString){ rs ->
       def meta = rs.metaData
       if (meta.columnCount <= 0) return
         for (i in 0..< meta.columnCount) {
           columnList += "${meta.getColumnLabel(i+1)}"
         }
       }
       columnList
   }
   
   columnList = getColumns(sql,sqlString)
   
   def xml = new groovy.xml.MarkupBuilder(fw)
   
   xml.table (name:"${tableName}") {
     for(int i = 0; i < columnList.size(); i++)
     {
       column(columnList[i])
     }  
   
     sql.eachRow(sqlString) { myRowData ->
       xml.row {
         for(int i = 0; i < columnList.size(); i++)
         {
           value(description:columnList[i], myRowData[i] )
         }
       }
     }
   }
   

4. Edit the line def tableName = "customers", replacing "customers" with the actual table name for which you want to populate sample data in AppFuse.
5. Edit the line def sqlString = "SELECT * FROM customers", replacing it with your own SQL statement. Note that we're grabbing sample data, not referring to our actual development table. The sql select statement can be anything that you want, perhaps joining several legacy tables to provide the data you want.
6. Edit the line def fileName = "customers-sample-data.xml", replacing it with whatever destination file name you want.
7. One last edit, change the line:
   def sql = sql.newInstance("jdbc:oracle:thin:@localhost:1521:XE", "username", "password", oracle.jdbc.OracleDriver")
   to match your appropriate database connection string.
8. That's it. From a command prompt, type "groovy create-sample-data.groovy" and you should have your sample data in a file from which you can paste the contents into AppFuse's sample-data.xml file. Nuthin' to it!

I won't claim my code is the prettiest, but it works. I haven't tested it extensively, but it appears to work for all my needs, and all I have to do is change a few lines to create data for a new table. If the formatting of dates or numbers is not suitable, this can readily be fixed by performing the formatting within the SQL string itself. Hope you enjoy it

After successfully using AppFuse 1.9.4 in a production environment, we recently started developing with the AppFuse 2 version. I know, I know… it has been out for sometime, but we finally had the right opportunity to try the 2.0.2 version for a new app.

Having been familiar with the previous version, I thought it would be a breeze. AppFuse, for those of you not familiar with it, provides a great pre-assembled stack of Java technologies. We used the Spring-Hibernate-Spring MVC stack in our previous apps, and so we chose the Spring MVC Basic stack for our new app. The AppFuse site provides some great QuickStart instructions along with tutorials. I cannot recommend highly enough the benefit of doing the tutorials, even if you consider yourself an accomplished Spring/Hibernate developer. They just save a lot of time in familiarizing yourself with the AppFuse way.

Back to our experiences. Let me start by saying that in the end, AppFuse 2 works great. Getting to that “great” end has been a bit of an unanticipated trek though, mostly due to our specific environment and (in)experience with certain methods used in building software with AppFuse 2. We develop using Windows machines (from behind a firewall), accessing Oracle databases that contain a lot of legacy data tables. No greenfield development here .

Here’s what we found when moving to AppFuse 2:

• We were Ant People (sounds like a sci fi movie?). AppFuse 2 uses Maven. We had not used Maven before. We actually now like Maven, but migrating to Maven has not been without a learning curve and significant time investment. The fact that we develop from behind a firewall complicated initial configurations, and the fact that we utilize several jar files not applicable to a generic framework like AppFuse required us to learn a lot more about Maven fast. We have had to set up a local repository to deal with our issues. To be fair, AppFuse does provide instructions on how to utilize Ant rather than Maven, but we decided to stick to Maven in order to realistically evaluate if it provided any additional benefits to our build environment.
• We had Oracle issues. We use Oracle XE on our development machines, and Oracle 10G in production. AppFuse uses MySQL by default. If you’re just starting to evaluate AppFuse, stick with the MySQL at least while you are doing the tutorial portion. Configuring to Oracle has been a bit tricky. The AppFuse Forums have some detailed information on this, and we were readily able to get Oracle working on our development machines, but experienced problems with any sort of extended use. In our particular case, we had problems with exhausting database connections, and this took some additional research to cure.
• Jetty instead of Tomcat. Once again, just something new to us. We’re long time Tomcat users, and though Jetty is well regarded, we have had a few adjustments getting used to it. I’ve tried to set up the logging for Jetty and have yet to be successful.
• Hibernate Annotations Never used them before… I now like ‘em.
• Sample Data Management We do a lot of reporting systems that read large amounts of data. Several of our data tables and views are read-only “references”. We like to load these once with production data and be done with it. The AppFuse/Maven model makes this tough. I have yet to figure out how in the build process to skip creating/re-loading a table.
• Plan on using the full source version. Doing anything beyond a trivial app requires the full source version.

Overall, I think AppFuse 2 well worth the upgrade. It acts as a great starting place for an app and can really jumpstart development. The code provided and the methodologies recommended to develop apps readily demonstrate several best practices for software development, and this makes it an enjoyable framework from which to learn more about open source Java development. I do see some challenges to overcome as we customize portions of the framework to our specific purposes. I hope we are able to do this and continue to maintain a baseline from which we can easily start new applications tailored to our needs, and still maintain compatibility with the AppFuse framework. I suspect I’ll have more to say on this later.