Part of the improvements that will hopefully deploy successfully tomorrow is the ability to have multi-region searches.
So, there will be a new button that says "add to current" which, when pressed, will add data without clearing off the old data. This means you can have all the zip3s in Florida post next to all the zip3s in Georgia in case you want to compare between the two.
Currently, there is no way to differentiate between two searches on the same region (so if you select for all the zip3s in Georgia for one condition, and then add all the zip3s in Georgia for another condition... it will just overwrite the first set)... this is going to be part of a suite of improvements that allow for different sorts of pinpoints (pinwheel) and probably for selecting regions and legends.
But, I think it's neat and I hope you will too (and I actually got it working yesterday but spent a lot of yesterday and today debugging it, as I essentially had to rip apart the gmap-polygon project to get it working (and I branched before I did, thank goodness))
Cheers!
Thursday, July 9, 2009
Wednesday, July 8, 2009
GIPSE Store update
I just updated the amds-db project so that it is renamed to gipse-store to update the database structure to support new stratifiers. Now the database structure supports new optional stratifiers of:
age
gender
service area (e.g. ED, Outpatient, Inpatient, etc.)
facility
in addition to the required stratifiers of:
indicator
region (zip5 and/or state)
Note, although the GIPSE store supports these new indicators, the BioSense GIPSE service will still only use the indicator and region stratifiers.
I'm making this change to support storage from the BioSense HIE feeds as well as adding in additional stratifiers that may be used by the CoEs and Regional Collaboratives.
Next up is the change to the AMDSService to rename to GIPSE.
This project has ddl and seed data for PostgreSQL (we use this for dev) and SQLServer (we use this for production). Should anyone require another RDBMS please let me know (or add them yourself).
age
gender
service area (e.g. ED, Outpatient, Inpatient, etc.)
facility
in addition to the required stratifiers of:
indicator
region (zip5 and/or state)
Note, although the GIPSE store supports these new indicators, the BioSense GIPSE service will still only use the indicator and region stratifiers.
I'm making this change to support storage from the BioSense HIE feeds as well as adding in additional stratifiers that may be used by the CoEs and Regional Collaboratives.
Next up is the change to the AMDSService to rename to GIPSE.
This project has ddl and seed data for PostgreSQL (we use this for dev) and SQLServer (we use this for production). Should anyone require another RDBMS please let me know (or add them yourself).
NHIN Connect 2.1 is in the lab
NHIN 2.1 is fully functional in the lab on a single VM. I like it. It is much nicer than the 2.0 version.
Testing is underway!
Testing is underway!
A cool little service registry example
I came across the Mebrane SOA Registry yesterday and thought it was a good example of a really lean service registry that is highly functional. It has basic publish/search capability, but I like how it integrates clients for testing services (you can call from the web site) and also digg like behavior of letting users rate services.
This matches a lot of the rhetorics PHGrid has been talking about.
Unfortunately, the source code isn't released yet (they plan to later this year) but I like how this is a thin response to the usually pretty weighty chunk of software for registries.
It also has a really nice little generic SOAP client for testing public services that I find useful for when I don't have soapui installed on a machine. Comes in handy with the NHIN CONNECT test cases.
This matches a lot of the rhetorics PHGrid has been talking about.
Unfortunately, the source code isn't released yet (they plan to later this year) but I like how this is a thin response to the usually pretty weighty chunk of software for registries.
It also has a really nice little generic SOAP client for testing public services that I find useful for when I don't have soapui installed on a machine. Comes in handy with the NHIN CONNECT test cases.
Hot off the press: Google Plans to Introduce a PC Operating System
Check out this NY Times article here
Tuesday, July 7, 2009
multisets
Gmap Polygon and Grid Viewer are now essentially doing cumulative searches... it's just not displaying them in any particular order... Thus tomorrow will be spent creating some updated pinpoint libraries (pinwheel), modifying the flot-plot screens, adding a "clear map" function... and filtering to make sure that empty data sets aren't added.
Also, there is a distinction for "empty set". If servers are queried and no data comes back, I'll show the pinpoints/polygons as empty. If, however, a search is run without any servers selected.... it will be considered an empty set and not added to the search tree.
Thus, when you first load the page, you'll get a map of the US, but there will be no pinpoints until you actually search for data. This behavior can change, of course, but for now it will help debug the behavior of how data is added.
Then, it's testing to see how it all behaves, and seeing whether a collection of collections will suffice or whether I will have to upgrade it to a map of some sort (a bit more complex to navigate, but probably much better "make sure these are in order" behavior)
Also, there is a distinction for "empty set". If servers are queried and no data comes back, I'll show the pinpoints/polygons as empty. If, however, a search is run without any servers selected.... it will be considered an empty set and not added to the search tree.
Thus, when you first load the page, you'll get a map of the US, but there will be no pinpoints until you actually search for data. This behavior can change, of course, but for now it will help debug the behavior of how data is added.
Then, it's testing to see how it all behaves, and seeing whether a collection of collections will suffice or whether I will have to upgrade it to a map of some sort (a bit more complex to navigate, but probably much better "make sure these are in order" behavior)
HPCCloud FYI
Got this off the gt_users mailing list and thought it may be of interest:
http://groups.google.com/group/HPCcloud
A group dedicated to high performance cloud and grid computing.
http://groups.google.com/group/HPCcloud
A group dedicated to high performance cloud and grid computing.
Enterprise...
So, I was chatting with a friend yesterday and indicated that I was a bit sad because the next set of changes (modifying GmapPolygon to hold multiple sets of polygons/indicators and writing a new polygon color handler that allows for URL's to be set) will sort of make things ugly and a bit more confusing and threatens to mottle the design patterns even more...
The friend spake (and I paraphrase): "Don't worry about it, it's enterprise code. You go in expecting A... and you end up making A, which eventually needs B after the user sees it and decides it wants B-esque features... but you don't have the time to completely remake it into B, so you make it into a mashup of A and C which works just as good but is not as pretty. So just be happy that A-C is doing good enough and make it into B if you have time before the next deadline." We then went on to discuss how the whole idea that code as a start-do-end thing is more myth than reality... as specifications change and user wishes change and sometimes you change from linux to windows or the tool you need only works with a certain version &c &c.
So yes, The next step is going to be changing the GmapPolygon and the Grid Viewer to work with indexed collections of polygons instead of just one collection of polygons. This will allow for sequential searches (search for all the fever in the US... now search for all the nausea in the US... now search for all the poison-related cellulitis in the US... now do those again for all of Texas...) to be maintained and shown simultaneously on the map until they are explicitly cleared. This means the pinpoint visualizations will need to be changed so that later searches don't show up on top of the older searches (right now I am thinking of using rotating pins... so sequential searches start filling in a pin-wheel). The flot-plotting mechanics are also going to need to change a bit to search on region type, name, and index (thus, it knows to look for the 3rd search or the 2nd search). Eventually the selection mechanisms might also be tweaked to become more intuitive or allow for more specific searches... but right now it's just about getting multiple searches on a map.
I'm sure it will actually not be as ugly or unintuitive as I fear when I'm done, but it is a lot of changes in the name of niftiness,
Cheers!
The friend spake (and I paraphrase): "Don't worry about it, it's enterprise code. You go in expecting A... and you end up making A, which eventually needs B after the user sees it and decides it wants B-esque features... but you don't have the time to completely remake it into B, so you make it into a mashup of A and C which works just as good but is not as pretty. So just be happy that A-C is doing good enough and make it into B if you have time before the next deadline." We then went on to discuss how the whole idea that code as a start-do-end thing is more myth than reality... as specifications change and user wishes change and sometimes you change from linux to windows or the tool you need only works with a certain version &c &c.
So yes, The next step is going to be changing the GmapPolygon and the Grid Viewer to work with indexed collections of polygons instead of just one collection of polygons. This will allow for sequential searches (search for all the fever in the US... now search for all the nausea in the US... now search for all the poison-related cellulitis in the US... now do those again for all of Texas...) to be maintained and shown simultaneously on the map until they are explicitly cleared. This means the pinpoint visualizations will need to be changed so that later searches don't show up on top of the older searches (right now I am thinking of using rotating pins... so sequential searches start filling in a pin-wheel). The flot-plotting mechanics are also going to need to change a bit to search on region type, name, and index (thus, it knows to look for the 3rd search or the 2nd search). Eventually the selection mechanisms might also be tweaked to become more intuitive or allow for more specific searches... but right now it's just about getting multiple searches on a map.
I'm sure it will actually not be as ugly or unintuitive as I fear when I'm done, but it is a lot of changes in the name of niftiness,
Cheers!
Monday, July 6, 2009
New NHIN Connect 2.1 released - initial feedback
Officially, the new release of the NHIN Connect software comes out tomorrow. Unofficially, it was located on the NHIN Connect web site on July 2nd. The release home is located at http://www.connectopensource.org/display/NHINR21/Release+2.1+Home even though this folder isn't in the main menu system at the time of this blog entry.
Here are some of the highlights:
1 - NHIN Adapter and Connector are now distributed as ONE pre-configured set-up. No more TWO-box solutions. ONE-box only!
2 - Documentation has been greatly improved. It isn't flawless, but it is definitely better.
For my next trick, I will be installing a NEW adapter+connector in the lab from scratch on a new VM to see a) how the install goes, but also b) how well the new adapter+connector system functions.
More to come...
Here are some of the highlights:
1 - NHIN Adapter and Connector are now distributed as ONE pre-configured set-up. No more TWO-box solutions. ONE-box only!
2 - Documentation has been greatly improved. It isn't flawless, but it is definitely better.
For my next trick, I will be installing a NEW adapter+connector in the lab from scratch on a new VM to see a) how the install goes, but also b) how well the new adapter+connector system functions.
More to come...
Thursday, July 2, 2009
3. Authentication (To Chris' Point)
Chris wrote:
The application currently does session based authentication. We could potentially look to Spring for handling authentication. We would gain persistence (remember me), an adaptor for authenticating with OpenID, LDAP, and an easier path to cross-domain authentication if that were to become a requirement in the future. Spring-Security (formerly ACEGI) also supports X.509 certificates.
Our thinking behind grid/globus is to use their authentication framework rather than creating our own, especially leveraging GAARDS (caGRID). Perhaps we need to reconsider this assumption based upon what's happening at ONC and upon our experience to date.
Team, please comment.
The application currently does session based authentication. We could potentially look to Spring for handling authentication. We would gain persistence (remember me), an adaptor for authenticating with OpenID, LDAP, and an easier path to cross-domain authentication if that were to become a requirement in the future. Spring-Security (formerly ACEGI) also supports X.509 certificates.
Our thinking behind grid/globus is to use their authentication framework rather than creating our own, especially leveraging GAARDS (caGRID). Perhaps we need to reconsider this assumption based upon what's happening at ONC and upon our experience to date.
Team, please comment.
Subscribe to:
Posts (Atom)
Posts
