About the gap...
1 view
Skip to first unread message
Derek O'Connell
Jun 6, 2014, 8:26:55 AM6/6/14
to aush...@googlegroups.com
Hi all, sorry this is a long overdue post...
I'd like to thank Easwar for patiently fielding a lot of questions (via email) about development issues that has helped me understand the current design and how it was arrived at. I suspect this was not an entirely painless process for him ;-) There was no intention to exclude the rest of you from that discussion just a desire by me to avoid spamming this group with topics not directly specific to AuShadha (general Python/ Programming/ Database/ Web techniques). There was some fall-out that is directly related...
- Choosing to use "Au" as a convenient shorthand for "AuShadha". Trivial point but since Au is also the symbol for gold it might eventually allow the byline "Au, the Gold Standard of EMR's"... lofty ambitions I know ;-)
- Re-opening the wiki to allow greater involvement from others. Atm as a dumping ground for me to capture anything that might be of general interest to the group.
- The decision to swap quickly to Pg (PostgreSQL) came about while discussing the book "Two Scoops of Django" in which it recommends using the same db for all stages. This avoids only discovering db-related problems very late in the process. Pg seems a very popular choice. Installing it was easy enough, accessing it initially was not and that was before starting to figure out how to use it via the terminal interface and the GUI PgAdminIII. Please post your experiences and feel free to ask for help if you run into any problems. Some thought should be given to providing advice to Au adopters on how best to back-up their data (unlikely they will already be a Pg admin or have access to one).
- How to best represent Au's design schematically. See the wiki for early efforts, another attempt to come soon. There are several reasons for doing this, as a convenient overview for dev's who might want to contribute, as an introspective exercise to check mine and Easwar's understanding of the current design (I believe a good robust design should be easy to represent schematically) and as a comparison for any future fundamental design changes. The last point would need some explanation, possibly too much for this post so I'll provide a scenario we discussed: if in the future different dept's want to run their own instance of Au and control the info available to other dept's running their own Au instance, then how will that impact on the design? Schematics help make that clearer. (please note this is about code not UI)
- ICD10 PCS: it might be argued that working on this has distracted from more important aspects of Au. We continued development because compared to the rest of Au it has another level of complexity and was good testbed for comparing our different approaches to programming. Long story short, it will hopefully lead to less code, simpler code and more flexible code in other parts Au. This is key to keeping the project manageable and lowering the bar for other dev's.
- Work on ICD10 PCS has also highlighted the need for a general code clean-up before any release, again to keep things manageable and more easily digestible to prospective dev's. We would be specifically avoiding any design changes during this process apart from correcting snippets of code that we have already discovered are likely to cause problems. The results of this will form a new "clean" master repo.
- Plan/ UI/ Release: these topics have largely been avoided until this week and we both agreed that any discussion should take place here on this group. So here we are :-) My personal interest is mainly to do with code but I do have some opinions about the UI which air in another post.
- Docker/Porteus: I've been looking at these for another project. Docker seems popular and there are full-stack recipies for Django servers but I can't tell how big these would be without building them. Since most of the Docker stuff seems based on the big-name distro's I imagine they are not so small ;-) So, for my own purposes, I started looking into Porteus and so far I'm impressed. It potentially allows the end user to decide the medium to boot from including running the whole thing in memory. Will update you all at a later date when I have loaded it up with a Django stack.
Once again, sorry for the long gap and any part I may have played in it.
-D
I'd like to thank Easwar for patiently fielding a lot of questions (via email) about development issues that has helped me understand the current design and how it was arrived at. I suspect this was not an entirely painless process for him ;-) There was no intention to exclude the rest of you from that discussion just a desire by me to avoid spamming this group with topics not directly specific to AuShadha (general Python/ Programming/ Database/ Web techniques). There was some fall-out that is directly related...
- Choosing to use "Au" as a convenient shorthand for "AuShadha". Trivial point but since Au is also the symbol for gold it might eventually allow the byline "Au, the Gold Standard of EMR's"... lofty ambitions I know ;-)
- Re-opening the wiki to allow greater involvement from others. Atm as a dumping ground for me to capture anything that might be of general interest to the group.
- The decision to swap quickly to Pg (PostgreSQL) came about while discussing the book "Two Scoops of Django" in which it recommends using the same db for all stages. This avoids only discovering db-related problems very late in the process. Pg seems a very popular choice. Installing it was easy enough, accessing it initially was not and that was before starting to figure out how to use it via the terminal interface and the GUI PgAdminIII. Please post your experiences and feel free to ask for help if you run into any problems. Some thought should be given to providing advice to Au adopters on how best to back-up their data (unlikely they will already be a Pg admin or have access to one).
- How to best represent Au's design schematically. See the wiki for early efforts, another attempt to come soon. There are several reasons for doing this, as a convenient overview for dev's who might want to contribute, as an introspective exercise to check mine and Easwar's understanding of the current design (I believe a good robust design should be easy to represent schematically) and as a comparison for any future fundamental design changes. The last point would need some explanation, possibly too much for this post so I'll provide a scenario we discussed: if in the future different dept's want to run their own instance of Au and control the info available to other dept's running their own Au instance, then how will that impact on the design? Schematics help make that clearer. (please note this is about code not UI)
- ICD10 PCS: it might be argued that working on this has distracted from more important aspects of Au. We continued development because compared to the rest of Au it has another level of complexity and was good testbed for comparing our different approaches to programming. Long story short, it will hopefully lead to less code, simpler code and more flexible code in other parts Au. This is key to keeping the project manageable and lowering the bar for other dev's.
- Work on ICD10 PCS has also highlighted the need for a general code clean-up before any release, again to keep things manageable and more easily digestible to prospective dev's. We would be specifically avoiding any design changes during this process apart from correcting snippets of code that we have already discovered are likely to cause problems. The results of this will form a new "clean" master repo.
- Plan/ UI/ Release: these topics have largely been avoided until this week and we both agreed that any discussion should take place here on this group. So here we are :-) My personal interest is mainly to do with code but I do have some opinions about the UI which air in another post.
- Docker/Porteus: I've been looking at these for another project. Docker seems popular and there are full-stack recipies for Django servers but I can't tell how big these would be without building them. Since most of the Docker stuff seems based on the big-name distro's I imagine they are not so small ;-) So, for my own purposes, I started looking into Porteus and so far I'm impressed. It potentially allows the end user to decide the medium to boot from including running the whole thing in memory. Will update you all at a later date when I have loaded it up with a Django stack.
Once again, sorry for the long gap and any part I may have played in it.
-D
Reply all
Reply to author
Forward
0 new messages