Building a Server
A few weeks ago, I started to build a server. After years of playing around with open source software, I finally started to build an environment that I could easily deploy to that will let me work out the particulars of the things I’m particularly interested in particular.I’ve grown quite fond of the open source applications I’ve been working with over the years. Wordpress (the engine behind this blog) is all done in PHP under Apache and uses MySQL for the back end. WebProtege (a wonderful ontology editor from Standford) uses a servlet container for it’s collaboration magic - I like Tomcat alot. Given that I wanted these two applications to be managed from the same space, I dug a little and found a vendor that provide Apache and private Tomcat services.
I tend to go way overboard sometimes and this time is no fairly typical. For years, I’ve wanted to work in the above environment but in a local offline way. From my early days of researching into internet technologies, I wanted to set up an environment whereby I could develop on a “development” server and then “promote” to production. Recently, I began to construct a VirtualPC server to provide the development server function. This server uses Microsoft Windows XP (that’s the OS I know best). I installed Apache 2.2 and it listens on port 80 just like any webserver. Also, I installed Tomcat 6.0 and it listens on port 8080. I use mod_jk to hook up the two application servers so to the end user all web applications look like they’re in the same space.
I’m programming offline against this VirtualPC (yes it is very responsive this way). I modified my Hosts file so clients applications/browsers always think they’re talking to “www.slholmes.org” even though they’re talking to a computer that is running locally in a virtual machine. (VirtualPC networking was tricky but it boiled down to setting up Microsoft’s Loopback Network Adapter).
Once I got some sample apps (including WordPress) running under both PHP (Apache) and Java (Tomcat), I realized that the applications I planned to deployed would all have security accounts, authentication and authorization requirements. I dug a little and found Josso - Java Open Single Sign On. Josso is a security system divided into two main components. The first component is a Gateway which is a web service that runs under Tomcat. The other component is a set of Agents that “front-end” web applications to provide authentication and authorization services.
Today, after much configuration, head scratching and research, I successfully logged into a sample PHP web application, then switched over to a protected Tomcat application. Josso did the heavy lifting, realized I was already logged in and presented the protected Tomcat application without requiring me to log in again under some other context. This is two completely different webapp technologies using the same security engine.
Next steps. As I mentioned, WordPress uses MySQL as the backend. WordPress also has a fairly elaborate “Account” sub-system. I’m going to attempt to hook up Josso to the WordPress authorization sub-system and see how far I can get. I would like to offer up “accounts” for registered users so they can write their own blogs and work with the other web applications all on the same system. We’ll see how far I can get.
Keeping Track of Where I am
Where am I?
Recently, I configured my Blackberry and a variety of softwares to let my friends and family know approximately where I am at any given moment. I tried a variety of applications and techniques and settled on those that work best for me. Automated location tracking is still in its infancy but already many applications are up and running and providing interesting useful services.
In the very near future, my hope is that my Blackberry might make suggestions for a good restaurant in my area or might let me know that one of my friends is nearby. After some initial exploratory research, I found many services are already set up to do exactly this. Most of them are just getting started so I lowered my expectations a little and set out to get just some basic functionality happening.
The Scenario
When setting up automatted location tracking for the first time, it helps if you already have a very good idea of what you want to accomplish. Then it is simply a matter of finding the right tools to get it all working. In my case, I simply wanted to update my friends and family of my whereabouts but keep the necessity to join yet more social networks to a minimum. I came up with a small list of tasks I needed to research, install and configure:
- My Blackberry would get my current location from its built-in GPS.
- My Blackberry would send my current location to the Interweb, somehow.
- My status on FaceBook would be updated with my current location.
- A pretty little map on my Blog would be updated.
Naturally, the idea would be that I didn’t touch the Blackberry to do any of this. It just happened and it would be timely and accurate.
If you look at the list, you can divide the tasks into two processes. First, my location is detected and pushed to a central location somewhere on the web. Secondly, my location is pulled from a central location and web sites are updated. That central location turned out to be Yahoo’s Fire Eagle service which I’ll discuss in more detail later in this post.
Pushing Your Location to Fire Eagle
Installing, and configuring the web applications required to accomplish the four little items listed above is not difficult to do but does involve following a number of steps for each application - an orchestration if you will. All of the applications require no tender exchange, i.e. they’re free! All you need is a BlackBerry with GPS, and the Interweb.
Blackberry Location Tracking from GPS using MoosTrax
Most models of Blackberry have a built-in GPS along with one or two built-in GPS applications. You may have already played around with yours a little. As a matter of fact, it helps to get one of the built-in applications up and running if for no other reason than to make sure the GPS is fully functional. Later on, if you are trying to troubleshoot some weirdness, you can go into the built-in application first and make sure the GPS is still operational.
In order to send location information to the Interweb, I wanted just a simple program that runs on a Blackberry, that pings whatever satellite is in my area and that sends my current geographical location to the web periodically. MoosTrax does this very well and has just the right amount of functionality. It works for the most part in the background, i.e. hands off. To instal MoosTrax, using your Blackberry, navigate to http://moostrax.com/ota and download MoosTrax’s BlackBerry application.
After the installation, you’ll probably go looking for the MoosTrax application. LOL! There isn’t one, at least not on the Blackberry Curve. Instead, you will use BlackBerry’s Options application to configure a small number of MoosTrax settings.
So, if you’re like me, you’re already probably confused and ready to throw in the towel, right? Fortunately, detailed instructions are available at MoosTrax’s support site. Follow those instructions carefully. After installation, you’ll need to link up with your account on MoosTrax web site and make some changes to the Blackberry MoosTrax settings.
If you have trouble connecting to your account at moostrax.com, turn off the Connect with BES option. In order to save your BlackBerry’s battery, change MoosTrax to update every 240 seconds (4 minutes) and only when your location changes more than 260 meters. These settings send a good amount of information to your MoosTrax account and you’ll be able to view fairly accurate plots of trips you might take.
Once you successfully log in with the MoosTrax Blackberry application, you’ll be able to see your location on the web when you log into your MoosTrax.com online web account. It is at that site where you will connect the MoosTrax application with Yahoo’s Fire Eagle application.
Yahoo’s Fire Eagle
Fire Eagle is Yahoo’s centralized “hub” for location data. An application on the web or in our case, the BlackBerry, updates Fire Eagle with location information. Fire Eagle then routes that information to other applications on the Web.
Fire Eagle really has two major objectives - to make it easy for people to capture, manage and use their location all over the web and to make it easy for developers to build applications that can use that location without having to do all kinds of incredibly complicated work building updaters and working with very complicated geo data.
- Tom Coates, Head of Yahoo’s Fire Eagle project
Fire Eagle provides a nice friendly way to manage all the web applications out there that work with your location data. For each service you subscribe to you may specify how much or how little the application can know about your whereabouts.
After creating an account with Fire Eagle, return to MoosTrax and navigate your browser to the Extras section of your account. You’ll see an option there to configure MoosTrax with Fire Eagle. Follow the instructions and test it all out. If you use the settings as I recommend, MoosTrax will only update Fire Eagle once every four minutes and then only if you have moved more than 260 meters.
When you’re testing things, be sure to spend plenty of time on your accounts at both MoosTrax and Fire Eagle. Make sure you understand why MoosTrax is doing what it does to avoid confusion later on. Also, MoosTrax has a fairly active online support forum for those times when you just aren’t sure about what you’re seeing. I found it is best to be patient. Monitor your progress over several days and make adjustments to everything as you go.
Pulling Your Location from Fire Eagle
Once you are successfully “pushing” your location information to Fire Eagle, you can start using that information to do interesting things by using one of the many web applications listed in Fire Eagle’s Application Gallery. I’ll describe two applications that perform items 3 and 4 from my little list at the start of this post.
Geoupdater - Status Update for FaceBook
Geoupdater is a great little web application that posts a simple status message to your FaceBook account. The status includes a link to a map of where you are. When I connected Geoupdater to Fire Eagle, I set the Read Level setting to my current city because I didn’t want to bombard my friends and family with useless location information. I pass through a small number of city level locations on my way to and from work so my updates to FaceBook are relatively few.
My co-workers are hooked into FaceBook as well so now they know if I’m at the office or at home. I love the fact that my friends, family and co-workers know approximately where I am at all times. They love it too! When I go on a trip out side my region, things get even more exciting! (Actually most people probably just hide my status. And, I know who they are, too 
blogloc - Embeddable Google Map for your Blog
blogloc provides a great little service for your blog. After you create an account with their online web site, you can hook up blogloc with Fire Eagle. Then you visit their FAQ page where you can get a custom copy/paste code block for your blog’s template. I spent a little time with mine and got just the right size and zoom level so that my readers (you!) can know approximately where I am at the moment.
blogloc’s embeddable map uses Google Maps and is highly interactive. You can zoom all the way down to street level if you like. However, I have the Fire Eagle to blogloc connection set to city level so the map only shows some random point in my vicinity and not my precise location.
So, Now What?
I’ve played around with a variety of other web applications and I’m not too terribly sure about most of them. I do feel like I am prepared for the next big thing once it comes along. Friends on Fire seems really nice but the thumb tack that shows my location on their map looks pretty lonely - no friends 
As a matter of fact, most of the web sites, services and other applications using location data have little to no content. And where there is some information about a restaurant or some other place of interest nearby, the information usually looks computer generated and lacks links to more info. This is sure to change as the Semantic Web takes off and makes searching for things far more sophisticated.
Hey! The Semantic Web and Geo Location working together,
hmmm…
I love
BaseVISor Inference Engine - forward-chaining inference engine specialized to handle facts in the form of RDF triples with support for RuleML, R-Entailment and XML Schema Datatypes.
Creately - Online diagram and design tools. No Software Downloads, No Installs. Draw and Design right in your browser.
headup - The Firefox addon that helps you discover content related to your interests and your friends.
yoono - Manage all your social networks and IM services in one place.
Mapping Gestures to Features
I spent the last several weeks working on a prototype application I’m calling RDFBurner. The purpose of this application is to provide a user interface that allows for the rapid composition of triples. The triples will be parsed and used to compose RDF. The user interface provides four entries:
- Domain
- Subject
- Predicate
- Object
The idea is that you type a new Domain in or choose an existing one from a list, then type or choose a subject, predicate and object. Then save that to create a new triple. Below the entries, you’ll see a list of previously entered triples. The intent behind the user interface is to provide instant visual feedback of your work. Seeing the triples laid out in a tabular modular fashion provides you with many clues as to what sorts of triples you would need to describe your particular domain.
During the construction of the prototype, I became frustrated with the complexity of the code. Simply developing the user interface, I could see already how the code was turning into a tangled web of gibberish. This is a fairly typical result when coding to Microsoft’s “Event Driven” programming paradigm. The idea of Events letting your program know that some thing has occurred such as a key press or a record selection is, on the surface, a good idea. But in practice, if you’re not careful (and Lord knows I’m careful but I want to see results quickly so I’m not that careful) you end up with a big mess. Crafting OOP classes helps to some degree but generally, the paradigm leads to sloppy difficult to follow code.
So, once again, I began to think about the challenge of managing the complexities of a user interface. I realize that it might be possible to de-couple the intent of the user from the features in the program, thereby adding some much needed programming structure. If a user gestures by pressing a key or clicking a record in a grid, I could simply make a note of it and move on. Later, a timer in the program would wake up periodically and process these gestures. When an event fires, the logic would be extremely simple as the only task is to queue up the user’s intent. Features in the program would be simplified as they could be coded as very atomic local scope processes.
- When an event fires such as Control_KeyDown or Form_SelectionChange, create a Gesture object that represents the intent of the user’s action.
- Using a map, translate that gesture object into one or more program features invocation objects.
- Send an invocation object to each active form/control that supports those features.
The code snippet below shows that during an event, we simply queue up a new Gesture object (that’s what LogGesture does). Presumably, some program feature is going to know what to do with the mouse and keyboard focus so the event framework’s key press is suppressed by setting the KeyCode equal to zero.
| Visual Basic | | copy code | | ? |
Private Sub Entry_KeyDown(KeyCode As Integer, Shift As Integer) |
Select Case KeyCode |
Case 9 'Tab key |
LogGesture Me.Tag & "_Entry_Tab", CStr(Shift) |
KeyCode = 0 |
Case 40 ' Arrow Key Down |
LogGesture Me.Tag & "_Entry_Arrow", "Down" |
KeyCode = 0 |
Case 38 ' Arrow Key Up |
LogGesture Me.Tag & "_Entry_Arrow", "Up" |
KeyCode = 0 |
End Select |
Now later, a timer event will fire and process the Gesture objects waiting in the Queue. In my prototype, I have the timer set to 50 msec. This gives the application a nice snappy feeling. From the code snippet below, you should be able to see that the Gesture is translated into one or more Features. Each feature is supported by one or more forms. Each form is notified that the feature needs to be invoked.
| Visual Basic | | copy code | | ? |
Private Sub Form_Timer() |
' Translate GlobalGestures Into Features |
Dim pGesture As Gesture, pFeature As Feature, pFeatureQueue As FeatureQueue, pFormWithFeature As FormWithFeature, pFormsWithFeatureList As FormsWithFeatureList |
For Each pGesture In globalGestures ' Process Gestures Loop |
Set pFeatureQueue = TranslateGestureIntoFeatures(pGesture) |
If Not (pFeatureQueue Is Nothing) Then |
For Each pFeature In pFeatureQueue |
Set pFormsWithFeatureList = GetFormsThatSupportFeature(pFeature) |
If Not (pFormsWithFeatureList Is Nothing) Then |
For Each pFormWithFeature In pFormsWithFeatureList ' For every form that supports the feature |
pFormWithFeature.Form.FeatureQueue.Add pFeature ' queue up the feature - note this a form level object unlike the GestureQueue which is global |
pFormsWithFeatureList.Remove pFormWithFeature ' We're done so get rid of the form from the list |
Next pFormWithFeature |
End If |
Next pFeature |
End If |
Next pGesture |
globalGestures.RemoveAll |
Set pFeature = Nothing |
' Check for any incoming feature requests |
For Each pFeature In FeatureQueue ' Process incoming Features Loop |
DispatchFeature pFeature ' Execute the subroutine associated with the feature |
Next pFeature |
FeatureQueue.RemoveAll |
End Sub |
Finally, the code above is running in what I consider the “master” form which has it’s own queue of feature requests. The queues here are very simple. The DispatchFeature does nothing but checks the name of the Feature from the FeatureObject and calls the subroutine with the same name.
What about RDF?
Because I am building an RDF composition utility, it makes sense to encode the gesture to program feature map in RDF and use SPARQL to retrieve (parts of) the map at runtime. I’ve not done this yet in my current prototype. The purpose of the RDFBurner prototype is to compose triples that will be converted into RDF - a task which I have yet to program. The gesture to program feature mapping is currently implemented as an SQL Query against my rather simple triple store. Once I start actually generating RDF with the utility, I’ll refactor the translator portion to use RDF and SPARQL.
Inserting an RDF map into the Event logic of a typical application has some interesting connotations:
- The resulting RDF could possibly be combined the mapping RDF of other applications, implying the compositions of a type of mash-up that works at the user interaction level.
- Events are not the same as Gestures. For instance, when a user presses the up-arrow key while the focus is on the top row of a grid, the Event might be evntGrid_KeyPressed(UpArrow) while the gesture or intent of the end user is to move the focus to some other control above the grid, i.e. gstrGrid_Leave(Up). An Event is hardware/form/control kind of thing. A Gesture may be triggered by an Event but represents what the user really wants to do.
- It highly likely that there should be a translation mapping in RDF between Events and Gestures.
- Once the mapping is in RDF, it may be possible to infer patterns and sets of patterns, especially if the RDF is coaxed into OWL. We could use such inferred knowledge to generate at minimum a skeleton of the programming logic. Obviously other parts of a given application would make use of RDF knowledgebases and the combination of the classes involved could lead to an Ontology Driven Design.
-
Scott
Lawrence
Holmes
scottlholmes at gmail.com
Philadelphia , PA , 19107 USThis hCard created with the hCard creator.
