DRN Demo preparation

Dan and I tested the manual steps for the DRN demo with Joel Spangler from Geisinger. We transferred up the user SAS program using Ross' naming conventions, Joel combined the user SAS program with the Geisinger template, Joel ran the SAS program, I copied down the output file and displayed it using Open Office's spreadsheet program. Then Dan and I ran through the same steps using the NCPHI node.

I also wrote a few simple bash shell scripts that will help the demo go faster when we're running within WebEx. These bash scripts will be replaced by Don Brown's perl scripts once they are ready.

Curiously, the SSTS client runs a lot more slowly from Linux nodes than from Dan's windows client setup. It's a significant time difference (60 seconds on Linux vs. 5 seconds on Windows) and we'll be investigating to determine what the difference is.

DRN upcoming presentations

DRN upcoming presentations as follows:

Demonstrate to DRN group ("internal presentation"): Thurs., 2/5 @ 4:30PM ET

Demonstrate to large group ("external presentation"): Thurs., 2/19 @ 2:30PM ET

WebEx Demo

Another Demo

There's another demo scheduled on Wednesday, Dec 17th for Dr. Lenert to show the NCPHI Grid Lab to some of the COTPER leadership.

Another Demo

February 24/25, 2009. AAPCC Mid-Year Director's Meeting in Albuquerque, NM.

edit: BAL- specific dates and name of meeting

Upcoming Demos

There are a few demos scheduled for PHGrid:
Today, we'll be showing off PH-DGInet and the Poison Control WS demo application to Dr. Alvin Bronstein.
Next week (Tuesday, Nov 11) Drs Lenert and Savel will present PHGrid at the AMIA Conference.
Dr. Savel might present RODSA-DAI (as a potential NHIN Domain Service) at the NHIN Public Forum on Dec 15/16.

Poicondai is getting some more love

So, after I just got to the base of how to get Introduce to do things (with many, many thanks to Felicia) despite a whole lot of demos going on... I am now given charge to give the Poicondai-web app some more nift (as it can stand to be more nifty).

Thus, I have written down the next steps of RODS-GDBC in the RODS-GDBC wiki-entry. And now I shall go into the next set of requriements for Poicondai-web.

1. Use the basic test of NPDS-Web to make sure the condition list operates properly
2. If so, code a drop down of the possible choices, and discover which choices return higher results and indicate them in some way (star, different color)
3. Get a spatial series and use a pinpointed google map.
4. Make that a shaded polygonal google map
5. Make histograms when you click on the zip
6. Work out one histogram for multiple zips.

Numbers 4, 5 and 6 get more optional as time becomes an issue. Also, someone with better web design skills than me is going to be looking at using some pretty RSS and making things a bit shinier and appealing than my usual non-centered engineer-interface JSP.

I am actually sort of excited, sprucing up a demo means that people liked what we did and are anxious to see it do more. I'll try my best to not keep them waiting.

DEMODEMODEMO(again)

So there is a big demo tomorrow, and I have been preparing for that by making sure that the RODSA-DAI and Poicondai demos have been polished and a few of their quirks have been ironed out. I also was working on making all the items a lot more portable.

Furthermore, I have been ironing out some issues with a prototype public demo, and doing a lot of documentation. And that documentation is linked-to from this shiny new wiki page that Brian set up and I have filled out: here.

Meanwhile, I have started to look into the caGrid CQL and DCQL, and that stuff looks interesting.

I wasn't able to get the demo to ncphi.phgrid.net yet.

While the demo is set up and running on our internal servers... and we have a way to get into the internal servers for the Phin conference, and while I was able to get the databases and ogsadai bits installed on Dallas (I think) and NCPHI (I know)... I will not be able to get jboss on NCPHI and the demo available for public consumption.

I faced a lot of hurdles that delayed me, including limited server access due to higher priority testing and a 4:00 PM brownout/surge that killed all of our virtual machines. I was tooting along despite that when at 5:30, I discovered that dallas wasn't accessible on port 8443. That is the port OGSA-DAI operates on, and without it I won't be able to see one of the databases needed for the demo.. as a RODSAdai demo isn't that impressive with only one server.

I also tried getting JBoss installed on the NCPHI node, only to find that there were lots of errors generated on startup and a realization that port 8080 is blocked coming in.

Thus, we are facing a big case of interrupted ports, and no-one is in the building who can un-interrupt them.

At least the internal demo is working, and very neat I think.

Demodemodemo

Greetings all.

I was out last week, and this week I was putting my nose to the grindstone... and I got some pretty neat things done with the RODSAdai demo.

I cleaned it up, so it has a simple look with only intuitive controls.
I managed to get a server-merge in the demo app, thus allowing for data to be spread across different servers and aggregated when multiple servers are selected.
I managed to get some geocaching set up so that the page loaded a lot faster after the initial runs.

I owe many thanks to Brian for being a great sounding board. He was the one that turned major redesigns in my head into minor UI tweaks.

Building Demos

I got some very cool news from Dr. Espino today, that he had gotten RODSAdai building and happy on his end, and will probably be able to integrate all the code within a week. Furthermore, he added much better logging code (log4j complete with properties files), some null checking, and some defaults. I have successfully updated everything and adjusted to fit my own environment.

On the demo end, I have discovered many things that will not work with google maps as I envisioned them. I was thinking of doing real-time geocoding of zip codes, but that would turn one javascript request to google into about 30, and there are already free databases of zipcode geospatial locations. Furthermore, I am not sure of the best way to just lay out all the data given google's finicky timeouts (thus, if your application takes a while to generate a KML file, you will need to generate the file and place it somewhere in an accessible spot and then tell google to find it there).

Considering I am not exactly working on an accessible node, I am beginning to think it might just be easier to use JSP loops to build an array and then place that array into one of googles marker manager objects. Perhaps there is a way to pass KML into a google map directly? I will probably tinker with this at home.