Monthly Archives: October 2009

Using Google Apps on iGoogle

Posted by on October 29, 2009 1 comment

I love Google Apps, the sevice which hosts email, calendaring, online docs and chat for your own domain name free of charge at Google. Sure there are some disadvantages and I still don’t like working in the Google Docs word processor too much but the email and calendaring are great. I also love the iGoogle service where you can customize a homepage with RSS feeds and include a Gmail and Google Docs module.

The problem is that internal communication at Google between these projects is pretty much non-existant, at least it appears that way. iGoogle integrates wonderfully with the consumer Gmail and Google Docs service but not at all with the hosted Google Apps service which is becoming even more popular as companies, particularly universities and colleges, around the world start to adopt it. One of my customers was particularly annoyed that documents created with their hosted app couldn’t show up on their iGoogle page and asked me to find a solution. After much frustrations the best solution I could come up with is a series of hacked together iGoogle apps which replicate as much of the functionality as possible from the official Gmail, Calendar and Google Docs iGoogle apps.

1) Google Docs for hosted domains iGoogle gadget

2) Google Mail for hosted domains iGoogle gadget

3) Google Talk for hosted domains iGoogle gadget

4) Google Calendar for hosted domains iGoogle gadget

5) Google Tasks for hosted domains iGoogle gadget

Of course, this is really just a workaround and doesn’t do as nice a job of integration as the regular apps do. In related news the Google account authorization is a mess because of this as well. For example, you can log into the iGoogle site (and other Google services) using a non-gmail address which is linked to a regular gmail account but this is confusing if you also have a hosted apps mail account on that domain. A mess all around. Google…if you’re listening you really need to make some improvements to how your hosted apps service integrates with the rest of your services and sites!

Packet Radio With Soundcards Including APRS

Posted by on October 29, 2009 Comments Off on Packet Radio With Soundcards Including APRS

This summer I decided to explore a bit more about packet radio. You know, transmitting small amounts of information over amateur radio frequencies at very slow speeds. Prior to the advent of fairly ubiquitous high speed Internet connections this was a popular way for hams to move around information related to their activities. As it turns out the need for a dedicated packet modem (TNC) has gone away and the functionality can now be replaced with software and a sound card. One of my specific interests though was in learning about and improving the APRS system in the Twin Cities which allows people to automatically send GPS position information along with remote weather station packets and a variety of other small pieces of data. As it turns out APRS data can also be sent and received with a soundcard attached to a radio, forgoing the TNC and reducing the barrier to entry.

The primary program for soundcard TNC emulation is a free program called AGWPE and my first task was to learn how to setup and configure it as some of my firends had tried and failed to get it working in the past. Thanks to the great resources on the Internet I came upon the website of KC2RLM which contained excellent instructions for setting up and using the AGWPE program as well as a number of applications which would interact with the software.

Once I had gotten the basic soundcard TNC software up and running the next step was to start experimenting with APRS software. I tried lots of software including the common UI-View32 software but found the easiest to use and most modern software to be AGWTracker, a trialware program by the maker of AGWPE which supports all kinds of map layers such as Google Maps, MapPoint, etc. greatly improving the user experience. Of course, if you want to send updates back to the APRS-IS Internet network you need a password to go along with your callsign. As it turns out the password is a simple hashing algorithm designed just to prevent non-hams for injecting data into the network and is a documented algorithm. You can get your own APRS password or learn more about the algorithm at the APRS Password Generator website.

Making Relational Databases Hierarchical

Posted by on October 29, 2009 Comments Off on Making Relational Databases Hierarchical

I’m not one who really enjoys writing code. In fact, I tend to avoid it whenever possible as it’s just not that interesting to me. That said from time to time I have projects to complete where no existing software quite meets my needs and writing my own makes the most sense. This summer I was in the midst of collecting information and publishing a large extended family directory.

Clearly, the best way to do this is to store the data in a database. Because relational databases are most prevalent, I already have quite a bit of experience with MySQL and I knew I wanted to eventually make the data available via a PHP web application I decided to go with a MySQL backend. The trick here is that families aren’t as relational as you might originally think. Families are really hierarchical data (parents, children, grandchildren, etc.) and relational databases have a hard time storing and recalling things based on these types of relationships. For example, a typical family query might be one for a list of all descendants of someone. As it turns out families aren’t the only hierarchical data people might try to store in a relational database. Any business database which shows managers and reporting personnel is also a hierarchical data set albeit usually with fewer levels and much less complication (no need to track divorces, remarriages, spouses, etc.)

I was able to find and read up on several methods for storing the relational information but the one I ended up using is that proposed by Rob Volk of SQLTeam where the expensive (computationally) hierarchical relationships are stored in two additional fields for each record (depth and lineage) with parseable separators between generations. The database is initially loaded through a series of several (expensive) recursive queries but then can be maintained through triggers when information is added or updated.