Is there time to apply some discipline to the codebase?

[Peter Hutten-Czapski-2]

During the OSCUS meeting Aart gave a demonstration of proof of concept
for using new tools (the Google Webkit) to develop the Alberta billing
module.  As anyone who has looked at Oscar code is probably aware
OSCAR has used a number of tools, languages, libraries etc over the
years, depending on the preferences of who was taking the lead.

While under the hood it looks somewhat... well you know..., this has
served us well in the past, especially when it comes to our
phagocytosis of code from other projects (Hylafax, mule, drugref,
hapi).  However code and projects evolve and now that OSCAR is so big,
it becomes a challenge for debugging, updating (and not breaking
dependencies) and dare I mention it, documenting (we do have that
elephant named ISO in the room).

An argument could be made to come to some consensus to pick just one
(for new code and for rewrites of existing modules).  The
demonstration certainly showed that OSCAR could be programmed in the
Google toolkit.  It is very shiny chrome, and has very nice database
binding, such that forms are updated without being completely redrawn
and so on.

There was no discussion of this at OSCUS and presumably the acceptance
of using the Google toolkit is left to David and Jay.  Hard for them
not to let code be committed in (yet another toolkit should be no big
impediment), but it is another matter to *gasp* enforce the tools and
libraries that we use to program with.

However structure is not necessarily bad.  We are after all now coming
out with releases on a schedule.  Is it time to start by defining the
tools that we support/endorse?

================
Peter Hutten-Czapski
Haileybury Ontario

"The attitude that ‘if rural people want these services they’ll have
to come to the city to get them’ is simply not acceptable…” (Newbery,
1999)

Before printing, think about the environment. Avant d' imprimer,
pensez à l'environnement.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Oscarmcmaster-devel mailing list
Oscarmcmaster-devel@...
https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-devel

[Aart de Vries-2]

Thanks Peter for that. Finally we get some discussion on this list, and
I hope this thread will draw some more hard needed comments and visions.

Peter: Right on, and exactly in line with what I told John already when
I first started looking at the OSCAR code back in May: It doesn't take a
brilliant visionary to conclude by just looking at the current code-base
and the lack of documentation and project standards that OSCAR is the
product of a severely underfunded effort.
I'm astounded at how far OSCAR has gotten as far as it has, and it is
probably largely due to the fact that Jay works on it far after midnight
regularly, as well as others donating tons of private time. Our problems
are only going to get bigger fast if we don't get our act together: As
soon as we bring Alberta and Quebec Billing (and in my vision billing
modules for the other provinces and territories as well), users in these
new provinces will start to demand interfaces to other provincial
systems as well (like the Alberta Pharmacy system). In other words: the
rate of growth of the code base is going to accelerate, and with the
current absence of a project standards, the project will collapse by its
own success.

In the light of ISO, we will need a.o. the following things documented:
1 Architect
2 DB standards
3 Java coding standards (with Hibernate standards)
4 UI standards
5 How to set-up your development environment
6 Which versions of libraries and frameworks are used on the project
7Requirements
8 Test plan with test data sets, automated tests
9 Release notes (containing things like which Java/Tomcat/Database
version the project is released under)
10 User documentation (Manual and Online Help)
During the OCUS meeting the whole issue around the 2 user manual was
totally bogus: The User Manual is a deliverable of the development team
(as is online help, which is part of your UI-standards).

On Wednesday prior to the OCUS meeting, I had David Chan at my house,
and given him an extensive demo, a code run-down and showed him some of
the above documentation that I wrote while making my proof of concept.
At first his stance at documentation was: "Don't bother: Nobody keeps
them up to date, so they are not valuable anyways, so better not do it
all together". Probably this explains a.o. reasons why today there is
hardly any documentation. I said I disagreed with his vision: Documents
1,2,3,4,5,6 are fairly static documents. Together they will cost about a
month of initial effort of a senior developer to write, and thereafter,
these documents change only 5-10% year over year, so only little effort
is required to maintain them. As for the other documents: The
development-team will have to be disciplined enough to grow them with
each new function they make. The code base is now so large, that a
dedicated Analyst as well as a dedicated Software Tester are needed on
the project, and therefore these 2 positions need to be filled by very
senior people.
Regarding requirements, David's concern of them being unmaintainable is
partially valid, but it depends on how you write them. If you go full
flat out with writing requirements in UML with all kinds of fancy views
and diagrams on the object model, than yes David is correct. But
requirements can be written in many different ways: Choosing to work
with user stories for example lessons the burden significantly.
Since David got a feeling I have some affinity to writing documentation
because I see the value in it, he asked me whether I would be willing to
document the current OSCAR. No way: I think it is cheaper to clean up
first, and while doing that write your documentation. David told me that
clean-up is already on its way: For 2 years he secured $75000,- for this
activity (Jackson is on that).

Also because of ISO, we will probably have to take away the rights of
many people to check-in code into the repository. Code contributions
have to be moderated by a core full-time developer (paid positions).
This to ensure that the contribution does comply with the project
standards, and thereby that we are not risking our ISO certification at
a next audit. And this is not unusual: Most successful Open Source
projects work like that. Take Linux for example: Linus has assigned
specialists for various parts that make up the Linux system that
moderate code changes to the modules under their responsibilities.

As for the technology side: I choose GWT not because it looks so cool,
but mainly because it can lead to a significant reductions in both code
volume, as well as a significant reduction in technologies and
frameworks used. The demo you saw was running without me programming:
- struts
- spring
- JSPs
- HTML
- CSS
- JavaScript
The main technologies were Java and Hibernate. The fair number of
screens in the OSCAR application could be made with just what I had in
the demo, and can therefor with the helper-library that I programmed
myself, be programmed by intermediate level developers.
Note: I have to do write a bit of our own libraries to compensate for
wanting to get rid of Spring, but that should be overly difficult.

Another 2 senior developers will have to be present on the project with
HTML, CSS and maybe JavaScript skills to develop custom components to do
the appointment and e-chart screens. These developers also have to
moderate the intermediate developers doing the hibernate layer: I'm
currently working on hiding in the hibernate layer some of the
db-modeling errors that were made in the past, so that bad database
design isn't rippling through all the way into the business- and
UI-layers of the application. After this phase is done, the db can be
migrated easily: Only some Hibernate mappings will have to change,
without having to touch the vast majority of the code.

Don't pin me on GWT, there are other directions that can be taken for
OSCAR as well (http://www.icefaces.org/main/home/ to name but one). I
think a kind of OSCAR developer summit should be organized pretty soon
(before I start working on Alberta Billing), and maybe before Jackson
burns the 2x$75.000,-), in which developers as a group are going to
decide in which direction development should be taken.

All these activities come at a price. My initial ballpark figure to
realize all this is about $750.000,- annually on an ongoing bases. That
will give us at least 4 seniors, 2 intermediate people, their
hardware/network/telecom/traveling and ISO certification expenses. So I
have given that as an assignment to John, and we are hopeful about him
raising it.

Also by starting to think big, we might be more successful at
penetrating market share. In the OCUS meeting everyone was particularly
proud to be approaching 1000 users. But that is only roughly about 2% of
the Canadian market after 10 years of efforts. One can also take a
stance: Wouldn't we already be at 10 or 15%, if 3 years ago, someone was
smart enough to raise enough money to do all these clean-up's, do the
documentation, build the billing modules for all the provinces etc.
Especially after what David Daley brought to the table: Commercial
vendors will be offering EMR/EHR software and services for free (free
$$$-wise, but take valuable patient data as payment), and many
cash-strapped family physicians might fall into this marketing trap.
This would be an easy thing to do for these vendors, since some
provincial governments seem to favor ASP solutions. Above all, before
the governments will have a clue of what is going on, it will be too
late and they will not be able to revert the situation anymore. This
practice will be lucrative for those vendors, and they won't be
cash-strapped to fund their development efforts. So, aside from today's
short-slightness of both federal and the various provincial governments
to give proprietary vendors preferential treatment, OSCAR will face even
harder competition from vendors 'stealing' patient data. In this light,
I reckon that if we go on like the way things have been going, it will
take us a long long time to get to even 5%.

So regarding the not-for profit organization: Great in my opinion. The
current OSCAR was mainly developed, funded and run by McMaster with the
help of some grants. Universities however are places of education and
research. As a product of research, often excellent projects are
incubated at universities, and OSCAR can be easily qualified as one such
successful project. Universities have however limited resources to
sustain ongoing development: again OSCAR can be seen as a sad example of
this where current development activities (of taking a click away here
and there, or change some colors elsewhere) can hardly be earmarked as
'research' or world shocking novelties.

Regarding the board seats of this not for profit organization I was not
at all happy: The share of seats assigned to universities is
non-proportionally large. Also having no seats reserved for important
stake holder groups such as the vendors, and the software developers,
can be viewed as awkward at best. More than 80% of software projects are
known to fail in Canada. Since this corporation is not much different
from a software development company, some direct developer expertise
input into the board seems prudent (look at The Linux Foundation board
member list as an example). I think that David Chan is not the ideal
candidate to represent the development team: He is a professor of
medicine, not a full time IT professional who has kept up with modern
software development practices and strategies. Also since David is
attached to McMaster, there is a conflict of interests there.
As for the vendors: They invest a lot of personal time and effort in
OSCAR as well, and without them, OSCAR would not nearly be as big today.
Having vendor seat or seats in the not for profit organization seems
fair: They have a right to know which direction the development is going
to take, and the right to influence it as well. Their livelihoods depend
on it.
I'm also open to have someone on the board that is more of a business
person: A person that can think big, maybe a person with more marketing
experience. Aside from university professors like Dr. Martin Dawes, I
think a person like that can be very helpful in the current government
unfriendly OpenSource EMR climate.

For those developers who were not at the event, here is what I wrote to
Colleen to help her out with her minutes regarding the presentation that
I did:

"We are on the eve of the the 10th birthday of OSCAR, and OSCAR will be
around for yet another decade easily. Knowing this, and knowing the vast
progress that is being made in programming tools and libraries, I found
the time was ripe to look at newer technologies than those that were
available in the year 2000. Newer technologies that will allow us to
develop faster, write code that is cleaner, write less code: In short
code that is easy maintainable.

A fair few libraries/frameworks have already been added to OSCAR since
it's inception, and adding yet another one should not be done without
giving it due consideration, or just because the tool 'looks cool' or
for some other invalid reason. Once we do, the module build in it is
likely going to be around a long long time. So although I'm eying GWT
(Google Web Toolkit) technology for Alberta Billing in the short term, I
want to make sure that this toolkit could not just be used for the
billing module, but for other screens in OSCAR as well.

Hence I have been working on a prototype GWT implementation of a few
'old' OSCAR screens. This allowed me to focus on the technological
challenges that we always face when embracing a new technology, vs. me
having to both face these challenges and having to design the Alberta
Billing on top of that.

Goals Proof of Concept
1) New technology can run in conjunction with the old technologies
2) UI is as responsive as today's OSCAR
3) Load on the server is going to decrease
4) Network load is going to decrease
5) UI can be entirely multilingual
6) That the UI becomes more user friendly (short-cut keys, quick
navigation, live-update, asks to save modified data)
7) That fewer technologies are used to make screens than today
8) That screens can be made with fewer lines of code that are simple
9) That existing OSCAR screens can be invoked from the new
   technology screens
10) Single logon
11) The new screens log screen access as the old screens do
12) That the new screens abide by the same security restrictions as the
      old screens do
13) Documentation (online help, architecture, db-standards, java coding
     standards, UI standards)

The goals 1..9 have been realized to my satisfaction. Goal 13 is coming
along nicely, as I'm letting the documentation grow with my progress.
10..12 are not so exciting from a 'Proof of Concept' standpoint of view,
as I see little technical challenges in there: It is only a matter of
time until these will be completed.

By doing the 'proof of concept', I hope get buy-in from David, Jay and
others in the developer community, as well as from vendors and OSCAR
users. "

Aart

Peter Hutten-Czapski wrote:

> During the OSCUS meeting Aart gave a demonstration of proof of concept
> for using new tools (the Google Webkit) to develop the Alberta billing
> module.  As anyone who has looked at Oscar code is probably aware
> OSCAR has used a number of tools, languages, libraries etc over the
> years, depending on the preferences of who was taking the lead.
>
> While under the hood it looks somewhat... well you know..., this has
> served us well in the past, especially when it comes to our
> phagocytosis of code from other projects (Hylafax, mule, drugref,
> hapi).  However code and projects evolve and now that OSCAR is so big,
> it becomes a challenge for debugging, updating (and not breaking
> dependencies) and dare I mention it, documenting (we do have that
> elephant named ISO in the room).
>
> An argument could be made to come to some consensus to pick just one
> (for new code and for rewrites of existing modules).  The
> demonstration certainly showed that OSCAR could be programmed in the
> Google toolkit.  It is very shiny chrome, and has very nice database
> binding, such that forms are updated without being completely redrawn
> and so on.
>
> There was no discussion of this at OSCUS and presumably the acceptance
> of using the Google toolkit is left to David and Jay.  Hard for them
> not to let code be committed in (yet another toolkit should be no big
> impediment), but it is another matter to *gasp* enforce the tools and
> libraries that we use to program with.
>
> However structure is not necessarily bad.  We are after all now coming
> out with releases on a schedule.  Is it time to start by defining the
> tools that we support/endorse?
>
> ================
> Peter Hutten-Czapski
> Haileybury Ontario
>
> "The attitude that ‘if rural people want these services they’ll have
> to come to the city to get them’ is simply not acceptable…” (Newbery,
> 1999)
>
> Before printing, think about the environment. Avant d' imprimer,
> pensez à l'environnement.
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Oscarmcmaster-devel mailing list
> Oscarmcmaster-devel@...
> https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-devel
>  

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Oscarmcmaster-devel mailing list
Oscarmcmaster-devel@...
https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-devel

[peter_hc]

Aart has a grand vision.  I am also frightened by the level of change
that he describes. I am cognisant that I have contributed but several
hundreds of lines to the code base, and am at best an amateur
programmer, and thus have little (or should have) little influence,.
However there are some things that can be done incrementally to change
the development modus operandi without increasing our resource needs,
and indeed reducing our needs for same as time goes on, and it doesn't
necessarily have to be done in the big P project fashion.

By example I don't agree that we need to depend on programmers to
write user documentation.  Most larger projects use technical writers
after all, and we have too few resources to hire either programming
nor technical writer time.  It would be a shame to ignore the
community which is willing and capable of writing a users manual - and
only needs a structure (the editor, a table of contents, a style guide
etc which we/they can develop them/ourselves.  All they need are
details from the programmers on how the help function will call the
pages)

I agree entirely that similar definition of programming structures
will improve the longevity of the project, and the sooner we do that
the easier it will be to become ISO compliant.  We don't need anything
more than will and a consensus on what the project needs to have in
the next two years from a development point of view.  I am glad that
Aart is not married to the Google Webkit, (I like it as well but that
is not the point), the question is what the lead developers that know
the project the best want to do.

For Aart there is some urgency.   I suspect that Aart will not want to
commit much code before there is some agreement as to what
framework(s) the project will be using in the near future, because
there is little point in using the Google Webkit, if Jay is thinking
of going to another toolkit in the next year.

That shouldn't rush the lead developers, but it does point out how not
enough structure can inhibit the project.


================
Peter Hutten-Czapski
Haileybury Ontario

"The attitude that ‘if rural people want these services they’ll have
to come to the city to get them’ is simply not acceptable…” (Newbery,
1999)

Before printing, think about the environment. Avant d' imprimer,
pensez à l'environnement.



2009/11/1 Aart de Vries <aart.de.vries@...>:

> Thanks Peter for that. Finally we get some discussion on this list, and I
> hope this thread will draw some more hard needed comments and visions.
>
> Peter: Right on, and exactly in line with what I told John already when I
> first started looking at the OSCAR code back in May: It doesn't take a
> brilliant visionary to conclude by just looking at the current code-base and
> the lack of documentation and project standards that OSCAR is the product of
> a severely underfunded effort.
> I'm astounded at how far OSCAR has gotten as far as it has, and it is
> probably largely due to the fact that Jay works on it far after midnight
> regularly, as well as others donating tons of private time. Our problems are
> only going to get bigger fast if we don't get our act together: As soon as
> we bring Alberta and Quebec Billing (and in my vision billing modules for
> the other provinces and territories as well), users in these new provinces
> will start to demand interfaces to other provincial systems as well (like
> the Alberta Pharmacy system). In other words: the rate of growth of the code
> base is going to accelerate, and with the current absence of a project
> standards, the project will collapse by its own success.
>
> In the light of ISO, we will need a.o. the following things documented:
> 1 Architect
> 2 DB standards
> 3 Java coding standards (with Hibernate standards)
> 4 UI standards
> 5 How to set-up your development environment
> 6 Which versions of libraries and frameworks are used on the project
> 7Requirements
> 8 Test plan with test data sets, automated tests
> 9 Release notes (containing things like which Java/Tomcat/Database version
> the project is released under)
> 10 User documentation (Manual and Online Help)
> During the OCUS meeting the whole issue around the 2 user manual was totally
> bogus: The User Manual is a deliverable of the development team (as is
> online help, which is part of your UI-standards).
>
> On Wednesday prior to the OCUS meeting, I had David Chan at my house, and
> given him an extensive demo, a code run-down and showed him some of the
> above documentation that I wrote while making my proof of concept. At first
> his stance at documentation was: "Don't bother: Nobody keeps them up to
> date, so they are not valuable anyways, so better not do it all together".
> Probably this explains a.o. reasons why today there is hardly any
> documentation. I said I disagreed with his vision: Documents 1,2,3,4,5,6 are
> fairly static documents. Together they will cost about a month of initial
> effort of a senior developer to write, and thereafter, these documents
> change only 5-10% year over year, so only little effort is required to
> maintain them. As for the other documents: The development-team will have to
> be disciplined enough to grow them with each new function they make. The
> code base is now so large, that a dedicated Analyst as well as a dedicated
> Software Tester are needed on the project, and therefore these 2 positions
> need to be filled by very senior people.
> Regarding requirements, David's concern of them being unmaintainable is
> partially valid, but it depends on how you write them. If you go full flat
> out with writing requirements in UML with all kinds of fancy views and
> diagrams on the object model, than yes David is correct. But requirements
> can be written in many different ways: Choosing to work with user stories
> for example lessons the burden significantly.
> Since David got a feeling I have some affinity to writing documentation
> because I see the value in it, he asked me whether I would be willing to
> document the current OSCAR. No way: I think it is cheaper to clean up first,
> and while doing that write your documentation. David told me that clean-up
> is already on its way: For 2 years he secured $75000,- for this activity
> (Jackson is on that).
>
> Also because of ISO, we will probably have to take away the rights of many
> people to check-in code into the repository. Code contributions have to be
> moderated by a core full-time developer (paid positions). This to ensure
> that the contribution does comply with the project standards, and thereby
> that we are not risking our ISO certification at a next audit. And this is
> not unusual: Most successful Open Source projects work like that. Take Linux
> for example: Linus has assigned specialists for various parts that make up
> the Linux system that moderate code changes to the modules under their
> responsibilities.
>
> As for the technology side: I choose GWT not because it looks so cool, but
> mainly because it can lead to a significant reductions in both code volume,
> as well as a significant reduction in technologies and frameworks used. The
> demo you saw was running without me programming:
> - struts
> - spring
> - JSPs
> - HTML
> - CSS
> - JavaScript
> The main technologies were Java and Hibernate. The fair number of screens in
> the OSCAR application could be made with just what I had in the demo, and
> can therefor with the helper-library that I programmed myself, be programmed
> by intermediate level developers.
> Note: I have to do write a bit of our own libraries to compensate for
> wanting to get rid of Spring, but that should be overly difficult.
>
> Another 2 senior developers will have to be present on the project with
> HTML, CSS and maybe JavaScript skills to develop custom components to do the
> appointment and e-chart screens. These developers also have to moderate the
> intermediate developers doing the hibernate layer: I'm currently working on
> hiding in the hibernate layer some of the db-modeling errors that were made
> in the past, so that bad database design isn't rippling through all the way
> into the business- and UI-layers of the application. After this phase is
> done, the db can be migrated easily: Only some Hibernate mappings will have
> to change, without having to touch the vast majority of the code.
>
> Don't pin me on GWT, there are other directions that can be taken for OSCAR
> as well (http://www.icefaces.org/main/home/ to name but one). I think a kind
> of OSCAR developer summit should be organized pretty soon (before I start
> working on Alberta Billing), and maybe before Jackson burns the
> 2x$75.000,-), in which developers as a group are going to decide in which
> direction development should be taken.
>
> All these activities come at a price. My initial ballpark figure to realize
> all this is about $750.000,- annually on an ongoing bases. That will give us
> at least 4 seniors, 2 intermediate people, their
> hardware/network/telecom/traveling and ISO certification expenses. So I have
> given that as an assignment to John, and we are hopeful about him raising
> it.
>
> Also by starting to think big, we might be more successful at penetrating
> market share. In the OCUS meeting everyone was particularly proud to be
> approaching 1000 users. But that is only roughly about 2% of the Canadian
> market after 10 years of efforts. One can also take a stance: Wouldn't we
> already be at 10 or 15%, if 3 years ago, someone was smart enough to raise
> enough money to do all these clean-up's, do the documentation, build the
> billing modules for all the provinces etc. Especially after what David Daley
> brought to the table: Commercial vendors will be offering EMR/EHR software
> and services for free (free $$$-wise, but take valuable patient data as
> payment), and many cash-strapped family physicians might fall into this
> marketing trap. This would be an easy thing to do for these vendors, since
> some provincial governments seem to favor ASP solutions. Above all, before
> the governments will have a clue of what is going on, it will be too late
> and they will not be able to revert the situation anymore. This practice
> will be lucrative for those vendors, and they won't be cash-strapped to fund
> their development efforts. So, aside from today's short-slightness of both
> federal and the various provincial governments to give proprietary vendors
> preferential treatment, OSCAR will face even harder competition from vendors
> 'stealing' patient data. In this light, I reckon that if we go on like the
> way things have been going, it will take us a long long time to get to even
> 5%.
>
> So regarding the not-for profit organization: Great in my opinion. The
> current OSCAR was mainly developed, funded and run by McMaster with the help
> of some grants. Universities however are places of education and research.
> As a product of research, often excellent projects are incubated at
> universities, and OSCAR can be easily qualified as one such successful
> project. Universities have however limited resources to sustain ongoing
> development: again OSCAR can be seen as a sad example of this where current
> development activities (of taking a click away here and there, or change
> some colors elsewhere) can hardly be earmarked as 'research' or world
> shocking novelties.
>
> Regarding the board seats of this not for profit organization I was not at
> all happy: The share of seats assigned to universities is non-proportionally
> large. Also having no seats reserved for important stake holder groups such
> as the vendors, and the software developers, can be viewed as awkward at
> best. More than 80% of software projects are known to fail in Canada. Since
> this corporation is not much different from a software development company,
> some direct developer expertise input into the board seems prudent (look at
> The Linux Foundation board member list as an example). I think that David
> Chan is not the ideal candidate to represent the development team: He is a
> professor of medicine, not a full time IT professional who has kept up with
> modern software development practices and strategies. Also since David is
> attached to McMaster, there is a conflict of interests there.
> As for the vendors: They invest a lot of personal time and effort in OSCAR
> as well, and without them, OSCAR would not nearly be as big today. Having
> vendor seat or seats in the not for profit organization seems fair: They
> have a right to know which direction the development is going to take, and
> the right to influence it as well. Their livelihoods depend on it.
> I'm also open to have someone on the board that is more of a business
> person: A person that can think big, maybe a person with more marketing
> experience. Aside from university professors like Dr. Martin Dawes, I think
> a person like that can be very helpful in the current government unfriendly
> OpenSource EMR climate.
>
> For those developers who were not at the event, here is what I wrote to
> Colleen to help her out with her minutes regarding the presentation that I
> did:
>
> "We are on the eve of the the 10th birthday of OSCAR, and OSCAR will be
> around for yet another decade easily. Knowing this, and knowing the vast
> progress that is being made in programming tools and libraries, I found the
> time was ripe to look at newer technologies than those that were available
> in the year 2000. Newer technologies that will allow us to develop faster,
> write code that is cleaner, write less code: In short code that is easy
> maintainable.
>
> A fair few libraries/frameworks have already been added to OSCAR since it's
> inception, and adding yet another one should not be done without giving it
> due consideration, or just because the tool 'looks cool' or for some other
> invalid reason. Once we do, the module build in it is likely going to be
> around a long long time. So although I'm eying GWT (Google Web Toolkit)
> technology for Alberta Billing in the short term, I want to make sure that
> this toolkit could not just be used for the billing module, but for other
> screens in OSCAR as well.
>
> Hence I have been working on a prototype GWT implementation of a few 'old'
> OSCAR screens. This allowed me to focus on the technological challenges that
> we always face when embracing a new technology, vs. me having to both face
> these challenges and having to design the Alberta Billing on top of that.
>
> Goals Proof of Concept
> 1) New technology can run in conjunction with the old technologies
> 2) UI is as responsive as today's OSCAR
> 3) Load on the server is going to decrease
> 4) Network load is going to decrease
> 5) UI can be entirely multilingual
> 6) That the UI becomes more user friendly (short-cut keys, quick navigation,
> live-update, asks to save modified data)
> 7) That fewer technologies are used to make screens than today
> 8) That screens can be made with fewer lines of code that are simple
> 9) That existing OSCAR screens can be invoked from the new
>  technology screens
> 10) Single logon
> 11) The new screens log screen access as the old screens do
> 12) That the new screens abide by the same security restrictions as the
>     old screens do
> 13) Documentation (online help, architecture, db-standards, java coding
>    standards, UI standards)
>
> The goals 1..9 have been realized to my satisfaction. Goal 13 is coming
> along nicely, as I'm letting the documentation grow with my progress. 10..12
> are not so exciting from a 'Proof of Concept' standpoint of view, as I see
> little technical challenges in there: It is only a matter of time until
> these will be completed.
>
> By doing the 'proof of concept', I hope get buy-in from David, Jay and
> others in the developer community, as well as from vendors and OSCAR users.
> "
>
> Aart
>
> Peter Hutten-Czapski wrote:
>>
>> During the OSCUS meeting Aart gave a demonstration of proof of concept
>> for using new tools (the Google Webkit) to develop the Alberta billing
>> module.  As anyone who has looked at Oscar code is probably aware
>> OSCAR has used a number of tools, languages, libraries etc over the
>> years, depending on the preferences of who was taking the lead.
>>
>> While under the hood it looks somewhat... well you know..., this has
>> served us well in the past, especially when it comes to our
>> phagocytosis of code from other projects (Hylafax, mule, drugref,
>> hapi).  However code and projects evolve and now that OSCAR is so big,
>> it becomes a challenge for debugging, updating (and not breaking
>> dependencies) and dare I mention it, documenting (we do have that
>> elephant named ISO in the room).
>>
>> An argument could be made to come to some consensus to pick just one
>> (for new code and for rewrites of existing modules).  The
>> demonstration certainly showed that OSCAR could be programmed in the
>> Google toolkit.  It is very shiny chrome, and has very nice database
>> binding, such that forms are updated without being completely redrawn
>> and so on.
>>
>> There was no discussion of this at OSCUS and presumably the acceptance
>> of using the Google toolkit is left to David and Jay.  Hard for them
>> not to let code be committed in (yet another toolkit should be no big
>> impediment), but it is another matter to *gasp* enforce the tools and
>> libraries that we use to program with.
>>
>> However structure is not necessarily bad.  We are after all now coming
>> out with releases on a schedule.  Is it time to start by defining the
>> tools that we support/endorse?
>>
>> ================
>> Peter Hutten-Czapski
>> Haileybury Ontario
>>
>> "The attitude that ‘if rural people want these services they’ll have
>> to come to the city to get them’ is simply not acceptable…” (Newbery,
>> 1999)
>>
>> Before printing, think about the environment. Avant d' imprimer,
>> pensez à l'environnement.
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Oscarmcmaster-devel mailing list
>> Oscarmcmaster-devel@...
>> https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-devel
>>
>
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Oscarmcmaster-devel mailing list
Oscarmcmaster-devel@...
https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-devel

[Aart de Vries-2]

Thanks Peter, any more people with input, especially from the lead
developers?

Don't say you should have little influence: The problems you shook up in
your opening e-mail of this thread are real. It is a bit shocking that
an 'amateur' programmer had to do it.

I didn't say the programmers should be writing the user manuals, but I
still think that it is a deliverable of the development team. I've been
on projects of the size you mention where we had dedicated people
writing the user documentation, but we are not in such a luxurious
position. More realistically on this project would be that the Analyst
would write them, that would create more consistency then the individual
developers writing it. Another option is that the Analyst co-ordinates
the efforts of the Users writing the stuff, this would resemble the
function that we were trying to fill-in during the OCUS meeting.

As for the approach: I agree. It should be incremental, whether GWT or
not, stronger still: The sheer size of today's code base can not be
replaced all at once. If we go with newer technologies, old screens will
have to be replaced by new screens in phases, hence, the goal in my
proof of concept that that can be done with GWT running in conjunction
with the current OSCAR app-server.

Peter, you got the urgency right, maybe even you underestimate it a bit:
I haven't committed any code, nor am I planning to until some direction
from the lead developers becomes visible. I consider it a waste of my
time of programming Alberta Billing in GWT if Jay will shoot the
initiative down by the time I'm finished. That would seriously piss me off.

On Thursday I have played open card with Jay: I have given him a private
demo, and a serious code walk-though. If he, or any of the other lead
developers want to go over it again with me in detail once more once I
have logging and security in place, then I'll be more than happy to do
that with them. However, if he already has good reasons for not going
with GWT, then I would like to hear that ASAP.

A.

Peter Hutten-Czapski wrote:

> Aart has a grand vision.  I am also frightened by the level of change
> that he describes. I am cognisant that I have contributed but several
> hundreds of lines to the code base, and am at best an amateur
> programmer, and thus have little (or should have) little influence,.
> However there are some things that can be done incrementally to change
> the development modus operandi without increasing our resource needs,
> and indeed reducing our needs for same as time goes on, and it doesn't
> necessarily have to be done in the big P project fashion.
>
> By example I don't agree that we need to depend on programmers to
> write user documentation.  Most larger projects use technical writers
> after all, and we have too few resources to hire either programming
> nor technical writer time.  It would be a shame to ignore the
> community which is willing and capable of writing a users manual - and
> only needs a structure (the editor, a table of contents, a style guide
> etc which we/they can develop them/ourselves.  All they need are
> details from the programmers on how the help function will call the
> pages)
>
> I agree entirely that similar definition of programming structures
> will improve the longevity of the project, and the sooner we do that
> the easier it will be to become ISO compliant.  We don't need anything
> more than will and a consensus on what the project needs to have in
> the next two years from a development point of view.  I am glad that
> Aart is not married to the Google Webkit, (I like it as well but that
> is not the point), the question is what the lead developers that know
> the project the best want to do.
>
> For Aart there is some urgency.   I suspect that Aart will not want to
> commit much code before there is some agreement as to what
> framework(s) the project will be using in the near future, because
> there is little point in using the Google Webkit, if Jay is thinking
> of going to another toolkit in the next year.
>
> That shouldn't rush the lead developers, but it does point out how not
> enough structure can inhibit the project.
>
>
> ================
> Peter Hutten-Czapski
> Haileybury Ontario
>
> "The attitude that ‘if rural people want these services they’ll have
> to come to the city to get them’ is simply not acceptable…” (Newbery,
> 1999)
>
> Before printing, think about the environment. Avant d' imprimer,
> pensez à l'environnement.
>
>
>
> 2009/11/1 Aart de Vries <aart.de.vries@...>:
>  
>> Thanks Peter for that. Finally we get some discussion on this list, and I
>> hope this thread will draw some more hard needed comments and visions.
>>
>> Peter: Right on, and exactly in line with what I told John already when I
>> first started looking at the OSCAR code back in May: It doesn't take a
>> brilliant visionary to conclude by just looking at the current code-base and
>> the lack of documentation and project standards that OSCAR is the product of
>> a severely underfunded effort.
>> I'm astounded at how far OSCAR has gotten as far as it has, and it is
>> probably largely due to the fact that Jay works on it far after midnight
>> regularly, as well as others donating tons of private time. Our problems are
>> only going to get bigger fast if we don't get our act together: As soon as
>> we bring Alberta and Quebec Billing (and in my vision billing modules for
>> the other provinces and territories as well), users in these new provinces
>> will start to demand interfaces to other provincial systems as well (like
>> the Alberta Pharmacy system). In other words: the rate of growth of the code
>> base is going to accelerate, and with the current absence of a project
>> standards, the project will collapse by its own success.
>>
>> In the light of ISO, we will need a.o. the following things documented:
>> 1 Architect
>> 2 DB standards
>> 3 Java coding standards (with Hibernate standards)
>> 4 UI standards
>> 5 How to set-up your development environment
>> 6 Which versions of libraries and frameworks are used on the project
>> 7Requirements
>> 8 Test plan with test data sets, automated tests
>> 9 Release notes (containing things like which Java/Tomcat/Database version
>> the project is released under)
>> 10 User documentation (Manual and Online Help)
>> During the OCUS meeting the whole issue around the 2 user manual was totally
>> bogus: The User Manual is a deliverable of the development team (as is
>> online help, which is part of your UI-standards).
>>
>> On Wednesday prior to the OCUS meeting, I had David Chan at my house, and
>> given him an extensive demo, a code run-down and showed him some of the
>> above documentation that I wrote while making my proof of concept. At first
>> his stance at documentation was: "Don't bother: Nobody keeps them up to
>> date, so they are not valuable anyways, so better not do it all together".
>> Probably this explains a.o. reasons why today there is hardly any
>> documentation. I said I disagreed with his vision: Documents 1,2,3,4,5,6 are
>> fairly static documents. Together they will cost about a month of initial
>> effort of a senior developer to write, and thereafter, these documents
>> change only 5-10% year over year, so only little effort is required to
>> maintain them. As for the other documents: The development-team will have to
>> be disciplined enough to grow them with each new function they make. The
>> code base is now so large, that a dedicated Analyst as well as a dedicated
>> Software Tester are needed on the project, and therefore these 2 positions
>> need to be filled by very senior people.
>> Regarding requirements, David's concern of them being unmaintainable is
>> partially valid, but it depends on how you write them. If you go full flat
>> out with writing requirements in UML with all kinds of fancy views and
>> diagrams on the object model, than yes David is correct. But requirements
>> can be written in many different ways: Choosing to work with user stories
>> for example lessons the burden significantly.
>> Since David got a feeling I have some affinity to writing documentation
>> because I see the value in it, he asked me whether I would be willing to
>> document the current OSCAR. No way: I think it is cheaper to clean up first,
>> and while doing that write your documentation. David told me that clean-up
>> is already on its way: For 2 years he secured $75000,- for this activity
>> (Jackson is on that).
>>
>> Also because of ISO, we will probably have to take away the rights of many
>> people to check-in code into the repository. Code contributions have to be
>> moderated by a core full-time developer (paid positions). This to ensure
>> that the contribution does comply with the project standards, and thereby
>> that we are not risking our ISO certification at a next audit. And this is
>> not unusual: Most successful Open Source projects work like that. Take Linux
>> for example: Linus has assigned specialists for various parts that make up
>> the Linux system that moderate code changes to the modules under their
>> responsibilities.
>>
>> As for the technology side: I choose GWT not because it looks so cool, but
>> mainly because it can lead to a significant reductions in both code volume,
>> as well as a significant reduction in technologies and frameworks used. The
>> demo you saw was running without me programming:
>> - struts
>> - spring
>> - JSPs
>> - HTML
>> - CSS
>> - JavaScript
>> The main technologies were Java and Hibernate. The fair number of screens in
>> the OSCAR application could be made with just what I had in the demo, and
>> can therefor with the helper-library that I programmed myself, be programmed
>> by intermediate level developers.
>> Note: I have to do write a bit of our own libraries to compensate for
>> wanting to get rid of Spring, but that should be overly difficult.
>>
>> Another 2 senior developers will have to be present on the project with
>> HTML, CSS and maybe JavaScript skills to develop custom components to do the
>> appointment and e-chart screens. These developers also have to moderate the
>> intermediate developers doing the hibernate layer: I'm currently working on
>> hiding in the hibernate layer some of the db-modeling errors that were made
>> in the past, so that bad database design isn't rippling through all the way
>> into the business- and UI-layers of the application. After this phase is
>> done, the db can be migrated easily: Only some Hibernate mappings will have
>> to change, without having to touch the vast majority of the code.
>>
>> Don't pin me on GWT, there are other directions that can be taken for OSCAR
>> as well (http://www.icefaces.org/main/home/ to name but one). I think a kind
>> of OSCAR developer summit should be organized pretty soon (before I start
>> working on Alberta Billing), and maybe before Jackson burns the
>> 2x$75.000,-), in which developers as a group are going to decide in which
>> direction development should be taken.
>>
>> All these activities come at a price. My initial ballpark figure to realize
>> all this is about $750.000,- annually on an ongoing bases. That will give us
>> at least 4 seniors, 2 intermediate people, their
>> hardware/network/telecom/traveling and ISO certification expenses. So I have
>> given that as an assignment to John, and we are hopeful about him raising
>> it.
>>
>> Also by starting to think big, we might be more successful at penetrating
>> market share. In the OCUS meeting everyone was particularly proud to be
>> approaching 1000 users. But that is only roughly about 2% of the Canadian
>> market after 10 years of efforts. One can also take a stance: Wouldn't we
>> already be at 10 or 15%, if 3 years ago, someone was smart enough to raise
>> enough money to do all these clean-up's, do the documentation, build the
>> billing modules for all the provinces etc. Especially after what David Daley
>> brought to the table: Commercial vendors will be offering EMR/EHR software
>> and services for free (free $$$-wise, but take valuable patient data as
>> payment), and many cash-strapped family physicians might fall into this
>> marketing trap. This would be an easy thing to do for these vendors, since
>> some provincial governments seem to favor ASP solutions. Above all, before
>> the governments will have a clue of what is going on, it will be too late
>> and they will not be able to revert the situation anymore. This practice
>> will be lucrative for those vendors, and they won't be cash-strapped to fund
>> their development efforts. So, aside from today's short-slightness of both
>> federal and the various provincial governments to give proprietary vendors
>> preferential treatment, OSCAR will face even harder competition from vendors
>> 'stealing' patient data. In this light, I reckon that if we go on like the
>> way things have been going, it will take us a long long time to get to even
>> 5%.
>>
>> So regarding the not-for profit organization: Great in my opinion. The
>> current OSCAR was mainly developed, funded and run by McMaster with the help
>> of some grants. Universities however are places of education and research.
>> As a product of research, often excellent projects are incubated at
>> universities, and OSCAR can be easily qualified as one such successful
>> project. Universities have however limited resources to sustain ongoing
>> development: again OSCAR can be seen as a sad example of this where current
>> development activities (of taking a click away here and there, or change
>> some colors elsewhere) can hardly be earmarked as 'research' or world
>> shocking novelties.
>>
>> Regarding the board seats of this not for profit organization I was not at
>> all happy: The share of seats assigned to universities is non-proportionally
>> large. Also having no seats reserved for important stake holder groups such
>> as the vendors, and the software developers, can be viewed as awkward at
>> best. More than 80% of software projects are known to fail in Canada. Since
>> this corporation is not much different from a software development company,
>> some direct developer expertise input into the board seems prudent (look at
>> The Linux Foundation board member list as an example). I think that David
>> Chan is not the ideal candidate to represent the development team: He is a
>> professor of medicine, not a full time IT professional who has kept up with
>> modern software development practices and strategies. Also since David is
>> attached to McMaster, there is a conflict of interests there.
>> As for the vendors: They invest a lot of personal time and effort in OSCAR
>> as well, and without them, OSCAR would not nearly be as big today. Having
>> vendor seat or seats in the not for profit organization seems fair: They
>> have a right to know which direction the development is going to take, and
>> the right to influence it as well. Their livelihoods depend on it.
>> I'm also open to have someone on the board that is more of a business
>> person: A person that can think big, maybe a person with more marketing
>> experience. Aside from university professors like Dr. Martin Dawes, I think
>> a person like that can be very helpful in the current government unfriendly
>> OpenSource EMR climate.
>>
>> For those developers who were not at the event, here is what I wrote to
>> Colleen to help her out with her minutes regarding the presentation that I
>> did:
>>
>> "We are on the eve of the the 10th birthday of OSCAR, and OSCAR will be
>> around for yet another decade easily. Knowing this, and knowing the vast
>> progress that is being made in programming tools and libraries, I found the
>> time was ripe to look at newer technologies than those that were available
>> in the year 2000. Newer technologies that will allow us to develop faster,
>> write code that is cleaner, write less code: In short code that is easy
>> maintainable.
>>
>> A fair few libraries/frameworks have already been added to OSCAR since it's
>> inception, and adding yet another one should not be done without giving it
>> due consideration, or just because the tool 'looks cool' or for some other
>> invalid reason. Once we do, the module build in it is likely going to be
>> around a long long time. So although I'm eying GWT (Google Web Toolkit)
>> technology for Alberta Billing in the short term, I want to make sure that
>> this toolkit could not just be used for the billing module, but for other
>> screens in OSCAR as well.
>>
>> Hence I have been working on a prototype GWT implementation of a few 'old'
>> OSCAR screens. This allowed me to focus on the technological challenges that
>> we always face when embracing a new technology, vs. me having to both face
>> these challenges and having to design the Alberta Billing on top of that.
>>
>> Goals Proof of Concept
>> 1) New technology can run in conjunction with the old technologies
>> 2) UI is as responsive as today's OSCAR
>> 3) Load on the server is going to decrease
>> 4) Network load is going to decrease
>> 5) UI can be entirely multilingual
>> 6) That the UI becomes more user friendly (short-cut keys, quick navigation,
>> live-update, asks to save modified data)
>> 7) That fewer technologies are used to make screens than today
>> 8) That screens can be made with fewer lines of code that are simple
>> 9) That existing OSCAR screens can be invoked from the new
>>  technology screens
>> 10) Single logon
>> 11) The new screens log screen access as the old screens do
>> 12) That the new screens abide by the same security restrictions as the
>>     old screens do
>> 13) Documentation (online help, architecture, db-standards, java coding
>>    standards, UI standards)
>>
>> The goals 1..9 have been realized to my satisfaction. Goal 13 is coming
>> along nicely, as I'm letting the documentation grow with my progress. 10..12
>> are not so exciting from a 'Proof of Concept' standpoint of view, as I see
>> little technical challenges in there: It is only a matter of time until
>> these will be completed.
>>
>> By doing the 'proof of concept', I hope get buy-in from David, Jay and
>> others in the developer community, as well as from vendors and OSCAR users.
>> "
>>
>> Aart
>>
>> Peter Hutten-Czapski wrote:
>>    
>>> During the OSCUS meeting Aart gave a demonstration of proof of concept
>>> for using new tools (the Google Webkit) to develop the Alberta billing
>>> module.  As anyone who has looked at Oscar code is probably aware
>>> OSCAR has used a number of tools, languages, libraries etc over the
>>> years, depending on the preferences of who was taking the lead.
>>>
>>> While under the hood it looks somewhat... well you know..., this has
>>> served us well in the past, especially when it comes to our
>>> phagocytosis of code from other projects (Hylafax, mule, drugref,
>>> hapi).  However code and projects evolve and now that OSCAR is so big,
>>> it becomes a challenge for debugging, updating (and not breaking
>>> dependencies) and dare I mention it, documenting (we do have that
>>> elephant named ISO in the room).
>>>
>>> An argument could be made to come to some consensus to pick just one
>>> (for new code and for rewrites of existing modules).  The
>>> demonstration certainly showed that OSCAR could be programmed in the
>>> Google toolkit.  It is very shiny chrome, and has very nice database
>>> binding, such that forms are updated without being completely redrawn
>>> and so on.
>>>
>>> There was no discussion of this at OSCUS and presumably the acceptance
>>> of using the Google toolkit is left to David and Jay.  Hard for them
>>> not to let code be committed in (yet another toolkit should be no big
>>> impediment), but it is another matter to *gasp* enforce the tools and
>>> libraries that we use to program with.
>>>
>>> However structure is not necessarily bad.  We are after all now coming
>>> out with releases on a schedule.  Is it time to start by defining the
>>> tools that we support/endorse?
>>>
>>> ================
>>> Peter Hutten-Czapski
>>> Haileybury Ontario
>>>
>>> "The attitude that ‘if rural people want these services they’ll have
>>> to come to the city to get them’ is simply not acceptable…” (Newbery,
>>> 1999)
>>>
>>> Before printing, think about the environment. Avant d' imprimer,
>>> pensez à l'environnement.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart your
>>> developing skills, take BlackBerry mobile applications to market and stay
>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>>> http://p.sf.net/sfu/devconference
>>> _______________________________________________
>>> Oscarmcmaster-devel mailing list
>>> Oscarmcmaster-devel@...
>>> https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-devel
>>>
>>>      
>>    

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Oscarmcmaster-devel mailing list
Oscarmcmaster-devel@...
https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-devel

[David Chan-3]

Aart, I agree with most of what you said except for your quote of me saying (regarding the need for good documentation): "Don't bother: Nobody keeps them up to date, so they are not valuable anyways, so better not do it all together". The recent grant of $75,000 a year for 2 years is precisely for cleaning up the code and documentation. It has not been easy to find the money or the person to help in this regard. You yourself have turned down this offer in favor of doing something entirely new (which I am not objecting;).

Your work on getting GWT to work with the existing OSCAR code base is very exciting and I hope you will be able to make sure that the new GWT code will run side by side with the current code with a single sign on. Once that is shown to be possible then I have no doubt GWT will eventually replace the archaic assortment of tools existing in OSCAR today.

May I remind you (and everyone else) that OSCAR is an Open Source project. It is what it is today because a lot of people have committed their valuable time and talents to make it happen. It is always good netiquette by being positive and encouraging. Predicting OSCAR's demise is never a good thing (as many have done over the years and proven wrong!). The project is more than the code or the architecture, or the documentation. The measure of success is NEVER (sorry for shouting...) about market share or venture capital investment. OSCAR would have failed its mission if at the end of the day we are not improving the health of our patients, or to improve our health care system despite what our governments are doing or not doing.

So welcome to this community but remember - release early and update frequently. You will find many in this forum who will be eager to help you.

Respectfully yours,
David

p.s. don't blame Jay or Jackson. They work for me. The buck stops here!

 David H Chan, MD, CCFP, MSc, FCFP
Associate Professor
Department of Family Medicine
McMaster University



----- Original Message ----
From: Aart de Vries <aart.de.vries@...>
To: oscarmcmaster-devel@...
Sent: Sun, November 1, 2009 12:28:47 PM
Subject: Re: [Oscarmcmaster-devel] Is there time to apply some discipline to the codebase?

Thanks Peter, any more people with input, especially from the lead
developers?

Don't say you should have little influence: The problems you shook up in
your opening e-mail of this thread are real. It is a bit shocking that
an 'amateur' programmer had to do it.

I didn't say the programmers should be writing the user manuals, but I
still think that it is a deliverable of the development team. I've been
on projects of the size you mention where we had dedicated people
writing the user documentation, but we are not in such a luxurious
position. More realistically on this project would be that the Analyst
would write them, that would create more consistency then the individual
developers writing it. Another option is that the Analyst co-ordinates
the efforts of the Users writing the stuff, this would resemble the
function that we were trying to fill-in during the OCUS meeting.

As for the approach: I agree. It should be incremental, whether GWT or
not, stronger still: The sheer size of today's code base can not be
replaced all at once. If we go with newer technologies, old screens will
have to be replaced by new screens in phases, hence, the goal in my
proof of concept that that can be done with GWT running in conjunction
with the current OSCAR app-server.

Peter, you got the urgency right, maybe even you underestimate it a bit:
I haven't committed any code, nor am I planning to until some direction
from the lead developers becomes visible. I consider it a waste of my
time of programming Alberta Billing in GWT if Jay will shoot the
initiative down by the time I'm finished. That would seriously piss me off.

On Thursday I have played open card with Jay: I have given him a private
demo, and a serious code walk-though. If he, or any of the other lead
developers want to go over it again with me in detail once more once I
have logging and security in place, then I'll be more than happy to do
that with them. However, if he already has good reasons for not going
with GWT, then I would like to hear that ASAP.

A.

Peter Hutten-Czapski wrote:

> Aart has a grand vision.  I am also frightened by the level of change
> that he describes. I am cognisant that I have contributed but several
> hundreds of lines to the code base, and am at best an amateur
> programmer, and thus have little (or should have) little influence,.
> However there are some things that can be done incrementally to change
> the development modus operandi without increasing our resource needs,
> and indeed reducing our needs for same as time goes on, and it doesn't
> necessarily have to be done in the big P project fashion.
>
> By example I don't agree that we need to depend on programmers to
> write user documentation.  Most larger projects use technical writers
> after all, and we have too few resources to hire either programming
> nor technical writer time.  It would be a shame to ignore the
> community which is willing and capable of writing a users manual - and
> only needs a structure (the editor, a table of contents, a style guide
> etc which we/they can develop them/ourselves.  All they need are
> details from the programmers on how the help function will call the
> pages)
>
> I agree entirely that similar definition of programming structures
> will improve the longevity of the project, and the sooner we do that
> the easier it will be to become ISO compliant.  We don't need anything
> more than will and a consensus on what the project needs to have in
> the next two years from a development point of view.  I am glad that
> Aart is not married to the Google Webkit, (I like it as well but that
> is not the point), the question is what the lead developers that know
> the project the best want to do.
>
> For Aart there is some urgency.   I suspect that Aart will not want to
> commit much code before there is some agreement as to what
> framework(s) the project will be using in the near future, because
> there is little point in using the Google Webkit, if Jay is thinking
> of going to another toolkit in the next year.
>
> That shouldn't rush the lead developers, but it does point out how not
> enough structure can inhibit the project.
>
>
> ================
> Peter Hutten-Czapski
> Haileybury Ontario
>
> "The attitude that ‘if rural people want these services they’ll have
> to come to the city to get them’ is simply not acceptable…” (Newbery,
> 1999)
>
> Before printing, think about the environment. Avant d' imprimer,
> pensez à l'environnement.
>
>
>
> 2009/11/1 Aart de Vries <aart.de.vries@...>:
>  
>> Thanks Peter for that. Finally we get some discussion on this list, and I
>> hope this thread will draw some more hard needed comments and visions.
>>
>> Peter: Right on, and exactly in line with what I told John already when I
>> first started looking at the OSCAR code back in May: It doesn't take a
>> brilliant visionary to conclude by just looking at the current code-base and
>> the lack of documentation and project standards that OSCAR is the product of
>> a severely underfunded effort.
>> I'm astounded at how far OSCAR has gotten as far as it has, and it is
>> probably largely due to the fact that Jay works on it far after midnight
>> regularly, as well as others donating tons of private time. Our problems are
>> only going to get bigger fast if we don't get our act together: As soon as
>> we bring Alberta and Quebec Billing (and in my vision billing modules for
>> the other provinces and territories as well), users in these new provinces
>> will start to demand interfaces to other provincial systems as well (like
>> the Alberta Pharmacy system). In other words: the rate of growth of the code
>> base is going to accelerate, and with the current absence of a project
>> standards, the project will collapse by its own success.
>>
>> In the light of ISO, we will need a.o. the following things documented:
>> 1 Architect
>> 2 DB standards
>> 3 Java coding standards (with Hibernate standards)
>> 4 UI standards
>> 5 How to set-up your development environment
>> 6 Which versions of libraries and frameworks are used on the project
>> 7Requirements
>> 8 Test plan with test data sets, automated tests
>> 9 Release notes (containing things like which Java/Tomcat/Database version
>> the project is released under)
>> 10 User documentation (Manual and Online Help)
>> During the OCUS meeting the whole issue around the 2 user manual was totally
>> bogus: The User Manual is a deliverable of the development team (as is
>> online help, which is part of your UI-standards).
>>
>> On Wednesday prior to the OCUS meeting, I had David Chan at my house, and
>> given him an extensive demo, a code run-down and showed him some of the
>> above documentation that I wrote while making my proof of concept. At first
>> his stance at documentation was: "Don't bother: Nobody keeps them up to
>> date, so they are not valuable anyways, so better not do it all together".
>> Probably this explains a.o. reasons why today there is hardly any
>> documentation. I said I disagreed with his vision: Documents 1,2,3,4,5,6 are
>> fairly static documents. Together they will cost about a month of initial
>> effort of a senior developer to write, and thereafter, these documents
>> change only 5-10% year over year, so only little effort is required to
>> maintain them. As for the other documents: The development-team will have to
>> be disciplined enough to grow them with each new function they make. The
>> code base is now so large, that a dedicated Analyst as well as a dedicated
>> Software Tester are needed on the project, and therefore these 2 positions
>> need to be filled by very senior people.
>> Regarding requirements, David's concern of them being unmaintainable is
>> partially valid, but it depends on how you write them. If you go full flat
>> out with writing requirements in UML with all kinds of fancy views and
>> diagrams on the object model, than yes David is correct. But requirements
>> can be written in many different ways: Choosing to work with user stories
>> for example lessons the burden significantly.
>> Since David got a feeling I have some affinity to writing documentation
>> because I see the value in it, he asked me whether I would be willing to
>> document the current OSCAR. No way: I think it is cheaper to clean up first,
>> and while doing that write your documentation. David told me that clean-up
>> is already on its way: For 2 years he secured $75000,- for this activity
>> (Jackson is on that).
>>
>> Also because of ISO, we will probably have to take away the rights of many
>> people to check-in code into the repository. Code contributions have to be
>> moderated by a core full-time developer (paid positions). This to ensure
>> that the contribution does comply with the project standards, and thereby
>> that we are not risking our ISO certification at a next audit. And this is
>> not unusual: Most successful Open Source projects work like that. Take Linux
>> for example: Linus has assigned specialists for various parts that make up
>> the Linux system that moderate code changes to the modules under their
>> responsibilities.
>>
>> As for the technology side: I choose GWT not because it looks so cool, but
>> mainly because it can lead to a significant reductions in both code volume,
>> as well as a significant reduction in technologies and frameworks used. The
>> demo you saw was running without me programming:
>> - struts
>> - spring
>> - JSPs
>> - HTML
>> - CSS
>> - JavaScript
>> The main technologies were Java and Hibernate. The fair number of screens in
>> the OSCAR application could be made with just what I had in the demo, and
>> can therefor with the helper-library that I programmed myself, be programmed
>> by intermediate level developers.
>> Note: I have to do write a bit of our own libraries to compensate for
>> wanting to get rid of Spring, but that should be overly difficult.
>>
>> Another 2 senior developers will have to be present on the project with
>> HTML, CSS and maybe JavaScript skills to develop custom components to do the
>> appointment and e-chart screens. These developers also have to moderate the
>> intermediate developers doing the hibernate layer: I'm currently working on
>> hiding in the hibernate layer some of the db-modeling errors that were made
>> in the past, so that bad database design isn't rippling through all the way
>> into the business- and UI-layers of the application. After this phase is
>> done, the db can be migrated easily: Only some Hibernate mappings will have
>> to change, without having to touch the vast majority of the code.
>>
>> Don't pin me on GWT, there are other directions that can be taken for OSCAR
>> as well (http://www.icefaces.org/main/home/ to name but one). I think a kind
>> of OSCAR developer summit should be organized pretty soon (before I start
>> working on Alberta Billing), and maybe before Jackson burns the
>> 2x$75.000,-), in which developers as a group are going to decide in which
>> direction development should be taken.
>>
>> All these activities come at a price. My initial ballpark figure to realize
>> all this is about $750.000,- annually on an ongoing bases. That will give us
>> at least 4 seniors, 2 intermediate people, their
>> hardware/network/telecom/traveling and ISO certification expenses. So I have
>> given that as an assignment to John, and we are hopeful about him raising
>> it.
>>
>> Also by starting to think big, we might be more successful at penetrating
>> market share. In the OCUS meeting everyone was particularly proud to be
>> approaching 1000 users. But that is only roughly about 2% of the Canadian
>> market after 10 years of efforts. One can also take a stance: Wouldn't we
>> already be at 10 or 15%, if 3 years ago, someone was smart enough to raise
>> enough money to do all these clean-up's, do the documentation, build the
>> billing modules for all the provinces etc. Especially after what David Daley
>> brought to the table: Commercial vendors will be offering EMR/EHR software
>> and services for free (free $$$-wise, but take valuable patient data as
>> payment), and many cash-strapped family physicians might fall into this
>> marketing trap. This would be an easy thing to do for these vendors, since
>> some provincial governments seem to favor ASP solutions. Above all, before
>> the governments will have a clue of what is going on, it will be too late
>> and they will not be able to revert the situation anymore. This practice
>> will be lucrative for those vendors, and they won't be cash-strapped to fund
>> their development efforts. So, aside from today's short-slightness of both
>> federal and the various provincial governments to give proprietary vendors
>> preferential treatment, OSCAR will face even harder competition from vendors
>> 'stealing' patient data. In this light, I reckon that if we go on like the
>> way things have been going, it will take us a long long time to get to even
>> 5%.
>>
>> So regarding the not-for profit organization: Great in my opinion. The
>> current OSCAR was mainly developed, funded and run by McMaster with the help
>> of some grants. Universities however are places of education and research.
>> As a product of research, often excellent projects are incubated at
>> universities, and OSCAR can be easily qualified as one such successful
>> project. Universities have however limited resources to sustain ongoing
>> development: again OSCAR can be seen as a sad example of this where current
>> development activities (of taking a click away here and there, or change
>> some colors elsewhere) can hardly be earmarked as 'research' or world
>> shocking novelties.
>>
>> Regarding the board seats of this not for profit organization I was not at
>> all happy: The share of seats assigned to universities is non-proportionally
>> large. Also having no seats reserved for important stake holder groups such
>> as the vendors, and the software developers, can be viewed as awkward at
>> best. More than 80% of software projects are known to fail in Canada. Since
>> this corporation is not much different from a software development company,
>> some direct developer expertise input into the board seems prudent (look at
>> The Linux Foundation board member list as an example). I think that David
>> Chan is not the ideal candidate to represent the development team: He is a
>> professor of medicine, not a full time IT professional who has kept up with
>> modern software development practices and strategies. Also since David is
>> attached to McMaster, there is a conflict of interests there.
>> As for the vendors: They invest a lot of personal time and effort in OSCAR
>> as well, and without them, OSCAR would not nearly be as big today. Having
>> vendor seat or seats in the not for profit organization seems fair: They
>> have a right to know which direction the development is going to take, and
>> the right to influence it as well. Their livelihoods depend on it.
>> I'm also open to have someone on the board that is more of a business
>> person: A person that can think big, maybe a person with more marketing
>> experience. Aside from university professors like Dr. Martin Dawes, I think
>> a person like that can be very helpful in the current government unfriendly
>> OpenSource EMR climate.
>>
>> For those developers who were not at the event, here is what I wrote to
>> Colleen to help her out with her minutes regarding the presentation that I
>> did:
>>
>> "We are on the eve of the the 10th birthday of OSCAR, and OSCAR will be
>> around for yet another decade easily. Knowing this, and knowing the vast
>> progress that is being made in programming tools and libraries, I found the
>> time was ripe to look at newer technologies than those that were available
>> in the year 2000. Newer technologies that will allow us to develop faster,
>> write code that is cleaner, write less code: In short code that is easy
>> maintainable.
>>
>> A fair few libraries/frameworks have already been added to OSCAR since it's
>> inception, and adding yet another one should not be done without giving it
>> due consideration, or just because the tool 'looks cool' or for some other
>> invalid reason. Once we do, the module build in it is likely going to be
>> around a long long time. So although I'm eying GWT (Google Web Toolkit)
>> technology for Alberta Billing in the short term, I want to make sure that
>> this toolkit could not just be used for the billing module, but for other
>> screens in OSCAR as well.
>>
>> Hence I have been working on a prototype GWT implementation of a few 'old'
>> OSCAR screens. This allowed me to focus on the technological challenges that
>> we always face when embracing a new technology, vs. me having to both face
>> these challenges and having to design the Alberta Billing on top of that.
>>
>> Goals Proof of Concept
>> 1) New technology can run in conjunction with the old technologies
>> 2) UI is as responsive as today's OSCAR
>> 3) Load on the server is going to decrease
>> 4) Network load is going to decrease
>> 5) UI can be entirely multilingual
>> 6) That the UI becomes more user friendly (short-cut keys, quick navigation,
>> live-update, asks to save modified data)
>> 7) That fewer technologies are used to make screens than today
>> 8) That screens can be made with fewer lines of code that are simple
>> 9) That existing OSCAR screens can be invoked from the new
>>  technology screens
>> 10) Single logon
>> 11) The new screens log screen access as the old screens do
>> 12) That the new screens abide by the same security restrictions as the
>>     old screens do
>> 13) Documentation (online help, architecture, db-standards, java coding
>>    standards, UI standards)
>>
>> The goals 1..9 have been realized to my satisfaction. Goal 13 is coming
>> along nicely, as I'm letting the documentation grow with my progress. 10..12
>> are not so exciting from a 'Proof of Concept' standpoint of view, as I see
>> little technical challenges in there: It is only a matter of time until
>> these will be completed.
>>
>> By doing the 'proof of concept', I hope get buy-in from David, Jay and
>> others in the developer community, as well as from vendors and OSCAR users.
>> "
>>
>> Aart
>>
>> Peter Hutten-Czapski wrote:
>>    
>>> During the OSCUS meeting Aart gave a demonstration of proof of concept
>>> for using new tools (the Google Webkit) to develop the Alberta billing
>>> module.  As anyone who has looked at Oscar code is probably aware
>>> OSCAR has used a number of tools, languages, libraries etc over the
>>> years, depending on the preferences of who was taking the lead.
>>>
>>> While under the hood it looks somewhat... well you know..., this has
>>> served us well in the past, especially when it comes to our
>>> phagocytosis of code from other projects (Hylafax, mule, drugref,
>>> hapi).  However code and projects evolve and now that OSCAR is so big,
>>> it becomes a challenge for debugging, updating (and not breaking
>>> dependencies) and dare I mention it, documenting (we do have that
>>> elephant named ISO in the room).
>>>
>>> An argument could be made to come to some consensus to pick just one
>>> (for new code and for rewrites of existing modules).  The
>>> demonstration certainly showed that OSCAR could be programmed in the
>>> Google toolkit.  It is very shiny chrome, and has very nice database
>>> binding, such that forms are updated without being completely redrawn
>>> and so on.
>>>
>>> There was no discussion of this at OSCUS and presumably the acceptance
>>> of using the Google toolkit is left to David and Jay.  Hard for them
>>> not to let code be committed in (yet another toolkit should be no big
>>> impediment), but it is another matter to *gasp* enforce the tools and
>>> libraries that we use to program with.
>>>
>>> However structure is not necessarily bad.  We are after all now coming
>>> out with releases on a schedule.  Is it time to start by defining the
>>> tools that we support/endorse?
>>>
>>> ================
>>> Peter Hutten-Czapski
>>> Haileybury Ontario
>>>
>>> "The attitude that ‘if rural people want these services they’ll have
>>> to come to the city to get them’ is simply not acceptable…” (Newbery,
>>> 1999)
>>>
>>> Before printing, think about the environment. Avant d' imprimer,
>>> pensez à l'environnement.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart your
>>> developing skills, take BlackBerry mobile applications to market and stay
>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>>> http://p.sf.net/sfu/devconference
>>> _______________________________________________
>>> Oscarmcmaster-devel mailing list
>>> Oscarmcmaster-devel@...
>>> https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-devel
>>>
>>>      
>>    

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Oscarmcmaster-devel mailing list
Oscarmcmaster-devel@...
https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-devel



      __________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!

http://www.flickr.com/gift/

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Oscarmcmaster-devel mailing list
Oscarmcmaster-devel@...
https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-devel

[Aart de Vries-2]

David,

Thanks for that. A few remarks:
- I discussed the single sign-on with Jay on Thursday. We agreed that
this is a non-issue. As soon as we merge the GWT code into the existing
OSCAR source tree, and thereby running of the same path, a single sign
on and session-id would be reality, without having to code something in
either the GWT code, nor in the existing OSCAR code. Problem solved.
- I did not predict the demise of OSCAR in the texts below. As I stated
during my demo: OSCAR is going to be around easily during the next
decade. The point I wanted to get across is that given the current
climate (ISO, governments subsidizing proprietary solutions and the
advent of free proprietary solutions) is going to make life for OSCAR
harder.
- I'm not blaming Jay, or Jackson or anybody else. Clearly I stated that
the shortcomings mentioned by Peter at the start of this thread are for
the most part caused by OSCAR being an underfunded project. I know that
Jay, Jackson, you yourself, and many other developers, vendors and users
invested lots and lots into OSCAR. But the point I think Peter and I are
getting at is probably clearly stated in the thread-name Peter started:
How can we improve things so that development can be undertaken more
efficiently. I would like to see a plan agreed upon how development is
going to be structurized and questions answered like: Are we going after
ISO? Who is going to look after that, because the deadline of August
2010 is coming up extremely fast? What is the not for profit
organization going to look like? How is it funded? What are it's
responsibilities? Is there any money for Alberta and Quebec billing, or
are we continuing to kick off modules that are underfunded? Do we want
to work with requirements? Are we going to formalize testing? If we
write standards documents, who has authority to write them? Which tool
do we write them in? How are we going to version all that? And I can
probably come up with a long list of more of these questions given time.
Now that there is some consensus that things have to be documented (if
only for ISO), who is ultimately responsible that these activities are
being worked on, and that they are moving in the right direction?
- I probably misunderstood you on Wednesday: I thought you asked whether
I would be interested in documenting the current code. And I had given
you my answer to that: No. I misunderstood the clean-up bit of it.
Because here I agree: Clean-up first then document that. But as you said
so yourself: Jackson could do that given the right tools
(coding/documentation standards, and libraries). I think I should move
onto expanding the GWT library I'm writing (if Jay/Randy and other
senior OSCAR developers approve of GWT, because that is still not clear
to me), and I should be on Alberta Billing and maybe develop Quebec
billing at the same time, as the best possible contribution of my time
and efforts to OSCAR.
- I'm not stating that you said that you don't see the value of good
documentation, and I'm glad you reckon that good documentation is
needed. That is not what I quoted. I know the quote is not exact,
because I didn't record our conversation, but you stated something that
you had personal experience with projects for which the docs were not
properly maintained, and thereby lost their value. I have personal
experiences with such projects as well. And this sounded to me as if you
were using this as an excuse for the absence of most of the
documentation in OSCAR that are quite common among software projects,
even Open Source projects. I'm sorry if I understood you wrong.

Thank you for welcoming me as a community member, but without a funding
stream in place for my activities, I might not survive in the OSCAR
world: My wife is not going to let me do this for another half year
without taking salary, and I think that me becoming an OSCAR vendor
first, and then a developing vendor would be a bit of a waste of my
developing capacities.

kind regards,
Aart



David Chan wrote:

> Aart, I agree with most of what you said except for your quote of me saying (regarding the need for good documentation): "Don't bother: Nobody keeps them up to date, so they are not valuable anyways, so better not do it all together". The recent grant of $75,000 a year for 2 years is precisely for cleaning up the code and documentation. It has not been easy to find the money or the person to help in this regard. You yourself have turned down this offer in favor of doing something entirely new (which I am not objecting;).
>
> Your work on getting GWT to work with the existing OSCAR code base is very exciting and I hope you will be able to make sure that the new GWT code will run side by side with the current code with a single sign on. Once that is shown to be possible then I have no doubt GWT will eventually replace the archaic assortment of tools existing in OSCAR today.
>
> May I remind you (and everyone else) that OSCAR is an Open Source project. It is what it is today because a lot of people have committed their valuable time and talents to make it happen. It is always good netiquette by being positive and encouraging. Predicting OSCAR's demise is never a good thing (as many have done over the years and proven wrong!). The project is more than the code or the architecture, or the documentation. The measure of success is NEVER (sorry for shouting...) about market share or venture capital investment. OSCAR would have failed its mission if at the end of the day we are not improving the health of our patients, or to improve our health care system despite what our governments are doing or not doing.
>
> So welcome to this community but remember - release early and update frequently. You will find many in this forum who will be eager to help you.
>
> Respectfully yours,
> David
>
> p.s. don't blame Jay or Jackson. They work for me. The buck stops here!
>
>  David H Chan, MD, CCFP, MSc, FCFP
> Associate Professor
> Department of Family Medicine
> McMaster University
>
>
>
> ----- Original Message ----
> From: Aart de Vries <aart.de.vries@...>
> To: oscarmcmaster-devel@...
> Sent: Sun, November 1, 2009 12:28:47 PM
> Subject: Re: [Oscarmcmaster-devel] Is there time to apply some discipline to the codebase?
>
> Thanks Peter, any more people with input, especially from the lead
> developers?
>
> Don't say you should have little influence: The problems you shook up in
> your opening e-mail of this thread are real. It is a bit shocking that
> an 'amateur' programmer had to do it.
>
> I didn't say the programmers should be writing the user manuals, but I
> still think that it is a deliverable of the development team. I've been
> on projects of the size you mention where we had dedicated people
> writing the user documentation, but we are not in such a luxurious
> position. More realistically on this project would be that the Analyst
> would write them, that would create more consistency then the individual
> developers writing it. Another option is that the Analyst co-ordinates
> the efforts of the Users writing the stuff, this would resemble the
> function that we were trying to fill-in during the OCUS meeting.
>
> As for the approach: I agree. It should be incremental, whether GWT or
> not, stronger still: The sheer size of today's code base can not be
> replaced all at once. If we go with newer technologies, old screens will
> have to be replaced by new screens in phases, hence, the goal in my
> proof of concept that that can be done with GWT running in conjunction
> with the current OSCAR app-server.
>
> Peter, you got the urgency right, maybe even you underestimate it a bit:
> I haven't committed any code, nor am I planning to until some direction
> from the lead developers becomes visible. I consider it a waste of my
> time of programming Alberta Billing in GWT if Jay will shoot the
> initiative down by the time I'm finished. That would seriously piss me off.
>
> On Thursday I have played open card with Jay: I have given him a private
> demo, and a serious code walk-though. If he, or any of the other lead
> developers want to go over it again with me in detail once more once I
> have logging and security in place, then I'll be more than happy to do
> that with them. However, if he already has good reasons for not going
> with GWT, then I would like to hear that ASAP.
>
> A.
>
> Peter Hutten-Czapski wrote:
>  
>> Aart has a grand vision.  I am also frightened by the level of change
>> that he describes. I am cognisant that I have contributed but several
>> hundreds of lines to the code base, and am at best an amateur
>> programmer, and thus have little (or should have) little influence,.
>> However there are some things that can be done incrementally to change
>> the development modus operandi without increasing our resource needs,
>> and indeed reducing our needs for same as time goes on, and it doesn't
>> necessarily have to be done in the big P project fashion.
>>
>> By example I don't agree that we need to depend on programmers to
>> write user documentation.  Most larger projects use technical writers
>> after all, and we have too few resources to hire either programming
>> nor technical writer time.  It would be a shame to ignore the
>> community which is willing and capable of writing a users manual - and
>> only needs a structure (the editor, a table of contents, a style guide
>> etc which we/they can develop them/ourselves.  All they need are
>> details from the programmers on how the help function will call the
>> pages)
>>
>> I agree entirely that similar definition of programming structures
>> will improve the longevity of the project, and the sooner we do that
>> the easier it will be to become ISO compliant.  We don't need anything
>> more than will and a consensus on what the project needs to have in
>> the next two years from a development point of view.  I am glad that
>> Aart is not married to the Google Webkit, (I like it as well but that
>> is not the point), the question is what the lead developers that know
>> the project the best want to do.
>>
>> For Aart there is some urgency.   I suspect that Aart will not want to
>> commit much code before there is some agreement as to what
>> framework(s) the project will be using in the near future, because
>> there is little point in using the Google Webkit, if Jay is thinking
>> of going to another toolkit in the next year.
>>
>> That shouldn't rush the lead developers, but it does point out how not
>> enough structure can inhibit the project.
>>
>>
>> ================
>> Peter Hutten-Czapski
>> Haileybury Ontario
>>
>> "The attitude that ‘if rural people want these services they’ll have
>> to come to the city to get them’ is simply not acceptable…” (Newbery,
>> 1999)
>>
>> Before printing, think about the environment. Avant d' imprimer,
>> pensez à l'environnement.
>>
>>
>>
>> 2009/11/1 Aart de Vries <aart.de.vries@...>:
>>  
>>    
>>> Thanks Peter for that. Finally we get some discussion on this list, and I
>>> hope this thread will draw some more hard needed comments and visions.
>>>
>>> Peter: Right on, and exactly in line with what I told John already when I
>>> first started looking at the OSCAR code back in May: It doesn't take a
>>> brilliant visionary to conclude by just looking at the current code-base and
>>> the lack of documentation and project standards that OSCAR is the product of
>>> a severely underfunded effort.
>>> I'm astounded at how far OSCAR has gotten as far as it has, and it is
>>> probably largely due to the fact that Jay works on it far after midnight
>>> regularly, as well as others donating tons of private time. Our problems are
>>> only going to get bigger fast if we don't get our act together: As soon as
>>> we bring Alberta and Quebec Billing (and in my vision billing modules for
>>> the other provinces and territories as well), users in these new provinces
>>> will start to demand interfaces to other provincial systems as well (like
>>> the Alberta Pharmacy system). In other words: the rate of growth of the code
>>> base is going to accelerate, and with the current absence of a project
>>> standards, the project will collapse by its own success.
>>>
>>> In the light of ISO, we will need a.o. the following things documented:
>>> 1 Architect
>>> 2 DB standards
>>> 3 Java coding standards (with Hibernate standards)
>>> 4 UI standards
>>> 5 How to set-up your development environment
>>> 6 Which versions of libraries and frameworks are used on the project
>>> 7Requirements
>>> 8 Test plan with test data sets, automated tests
>>> 9 Release notes (containing things like which Java/Tomcat/Database version
>>> the project is released under)
>>> 10 User documentation (Manual and Online Help)
>>> During the OCUS meeting the whole issue around the 2 user manual was totally
>>> bogus: The User Manual is a deliverable of the development team (as is
>>> online help, which is part of your UI-standards).
>>>
>>> On Wednesday prior to the OCUS meeting, I had David Chan at my house, and
>>> given him an extensive demo, a code run-down and showed him some of the
>>> above documentation that I wrote while making my proof of concept. At first
>>> his stance at documentation was: "Don't bother: Nobody keeps them up to
>>> date, so they are not valuable anyways, so better not do it all together".
>>> Probably this explains a.o. reasons why today there is hardly any
>>> documentation. I said I disagreed with his vision: Documents 1,2,3,4,5,6 are
>>> fairly static documents. Together they will cost about a month of initial
>>> effort of a senior developer to write, and thereafter, these documents
>>> change only 5-10% year over year, so only little effort is required to
>>> maintain them. As for the other documents: The development-team will have to
>>> be disciplined enough to grow them with each new function they make. The
>>> code base is now so large, that a dedicated Analyst as well as a dedicated
>>> Software Tester are needed on the project, and therefore these 2 positions
>>> need to be filled by very senior people.
>>> Regarding requirements, David's concern of them being unmaintainable is
>>> partially valid, but it depends on how you write them. If you go full flat
>>> out with writing requirements in UML with all kinds of fancy views and
>>> diagrams on the object model, than yes David is correct. But requirements
>>> can be written in many different ways: Choosing to work with user stories
>>> for example lessons the burden significantly.
>>> Since David got a feeling I have some affinity to writing documentation
>>> because I see the value in it, he asked me whether I would be willing to
>>> document the current OSCAR. No way: I think it is cheaper to clean up first,
>>> and while doing that write your documentation. David told me that clean-up
>>> is already on its way: For 2 years he secured $75000,- for this activity
>>> (Jackson is on that).
>>>
>>> Also because of ISO, we will probably have to take away the rights of many
>>> people to check-in code into the repository. Code contributions have to be
>>> moderated by a core full-time developer (paid positions). This to ensure
>>> that the contribution does comply with the project standards, and thereby
>>> that we are not risking our ISO certification at a next audit. And this is
>>> not unusual: Most successful Open Source projects work like that. Take Linux
>>> for example: Linus has assigned specialists for various parts that make up
>>> the Linux system that moderate code changes to the modules under their
>>> responsibilities.
>>>
>>> As for the technology side: I choose GWT not because it looks so cool, but
>>> mainly because it can lead to a significant reductions in both code volume,
>>> as well as a significant reduction in technologies and frameworks used. The
>>> demo you saw was running without me programming:
>>> - struts
>>> - spring
>>> - JSPs
>>> - HTML
>>> - CSS
>>> - JavaScript
>>> The main technologies were Java and Hibernate. The fair number of screens in
>>> the OSCAR application could be made with just what I had in the demo, and
>>> can therefor with the helper-library that I programmed myself, be programmed
>>> by intermediate level developers.
>>> Note: I have to do write a bit of our own libraries to compensate for
>>> wanting to get rid of Spring, but that should be overly difficult.
>>>
>>> Another 2 senior developers will have to be present on the project with
>>> HTML, CSS and maybe JavaScript skills to develop custom components to do the
>>> appointment and e-chart screens. These developers also have to moderate the
>>> intermediate developers doing the hibernate layer: I'm currently working on
>>> hiding in the hibernate layer some of the db-modeling errors that were made
>>> in the past, so that bad database design isn't rippling through all the way
>>> into the business- and UI-layers of the application. After this phase is
>>> done, the db can be migrated easily: Only some Hibernate mappings will have
>>> to change, without having to touch the vast majority of the code.
>>>
>>> Don't pin me on GWT, there are other directions that can be taken for OSCAR
>>> as well (http://www.icefaces.org/main/home/ to name but one). I think a kind
>>> of OSCAR developer summit should be organized pretty soon (before I start
>>> working on Alberta Billing), and maybe before Jackson burns the
>>> 2x$75.000,-), in which developers as a group are going to decide in which
>>> direction development should be taken.
>>>
>>> All these activities come at a price. My initial ballpark figure to realize
>>> all this is about $750.000,- annually on an ongoing bases. That will give us
>>> at least 4 seniors, 2 intermediate people, their
>>> hardware/network/telecom/traveling and ISO certification expenses. So I have
>>> given that as an assignment to John, and we are hopeful about him raising
>>> it.
>>>
>>> Also by starting to think big, we might be more successful at penetrating
>>> market share. In the OCUS meeting everyone was particularly proud to be
>>> approaching 1000 users. But that is only roughly about 2% of the Canadian
>>> market after 10 years of efforts. One can also take a stance: Wouldn't we
>>> already be at 10 or 15%, if 3 years ago, someone was smart enough to raise
>>> enough money to do all these clean-up's, do the documentation, build the
>>> billing modules for all the provinces etc. Especially after what David Daley
>>> brought to the table: Commercial vendors will be offering EMR/EHR software
>>> and services for free (free $$$-wise, but take valuable patient data as
>>> payment), and many cash-strapped family physicians might fall into this
>>> marketing trap. This would be an easy thing to do for these vendors, since
>>> some provincial governments seem to favor ASP solutions. Above all, before
>>> the governments will have a clue of what is going on, it will be too late
>>> and they will not be able to revert the situation anymore. This practice
>>> will be lucrative for those vendors, and they won't be cash-strapped to fund
>>> their development efforts. So, aside from today's short-slightness of both
>>> federal and the various provincial governments to give proprietary vendors
>>> preferential treatment, OSCAR will face even harder competition from vendors
>>> 'stealing' patient data. In this light, I reckon that if we go on like the
>>> way things have been going, it will take us a long long time to get to even
>>> 5%.
>>>
>>> So regarding the not-for profit organization: Great in my opinion. The
>>> current OSCAR was mainly developed, funded and run by McMaster with the help
>>> of some grants. Universities however are places of education and research.
>>> As a product of research, often excellent projects are incubated at
>>> universities, and OSCAR can be easily qualified as one such successful
>>> project. Universities have however limited resources to sustain ongoing
>>> development: again OSCAR can be seen as a sad example of this where current
>>> development activities (of taking a click away here and there, or change
>>> some colors elsewhere) can hardly be earmarked as 'research' or world
>>> shocking novelties.
>>>
>>> Regarding the board seats of this not for profit organization I was not at
>>> all happy: The share of seats assigned to universities is non-proportionally
>>> large. Also having no seats reserved for important stake holder groups such
>>> as the vendors, and the software developers, can be viewed as awkward at
>>> best. More than 80% of software projects are known to fail in Canada. Since
>>> this corporation is not much different from a software development company,
>>> some direct developer expertise input into the board seems prudent (look at
>>> The Linux Foundation board member list as an example). I think that David
>>> Chan is not the ideal candidate to represent the development team: He is a
>>> professor of medicine, not a full time IT professional who has kept up with
>>> modern software development practices and strategies. Also since David is
>>> attached to McMaster, there is a conflict of interests there.
>>> As for the vendors: They invest a lot of personal time and effort in OSCAR
>>> as well, and without them, OSCAR would not nearly be as big today. Having
>>> vendor seat or seats in the not for profit organization seems fair: They
>>> have a right to know which direction the development is going to take, and
>>> the right to influence it as well. Their livelihoods depend on it.
>>> I'm also open to have someone on the board that is more of a business
>>> person: A person that can think big, maybe a person with more marketing
>>> experience. Aside from university professors like Dr. Martin Dawes, I think
>>> a person like that can be very helpful in the current government unfriendly
>>> OpenSource EMR climate.
>>>
>>> For those developers who were not at the event, here is what I wrote to
>>> Colleen to help her out with her minutes regarding the presentation that I
>>> did:
>>>
>>> "We are on the eve of the the 10th birthday of OSCAR, and OSCAR will be
>>> around for yet another decade easily. Knowing this, and knowing the vast
>>> progress that is being made in programming tools and libraries, I found the
>>> time was ripe to look at newer technologies than those that were available
>>> in the year 2000. Newer technologies that will allow us to develop faster,
>>> write code that is cleaner, write less code: In short code that is easy
>>> maintainable.
>>>
>>> A fair few libraries/frameworks have already been added to OSCAR since it's
>>> inception, and adding yet another one should not be done without giving it
>>> due consideration, or just because the tool 'looks cool' or for some other
>>> invalid reason. Once we do, the module build in it is likely going to be
>>> around a long long time. So although I'm eying GWT (Google Web Toolkit)
>>> technology for Alberta Billing in the short term, I want to make sure that
>>> this toolkit could not just be used for the billing module, but for other
>>> screens in OSCAR as well.
>>>
>>> Hence I have been working on a prototype GWT implementation of a few 'old'
>>> OSCAR screens. This allowed me to focus on the technological challenges that
>>> we always face when embracing a new technology, vs. me having to both face
>>> these challenges and having to design the Alberta Billing on top of that.
>>>
>>> Goals Proof of Concept
>>> 1) New technology can run in conjunction with the old technologies
>>> 2) UI is as responsive as today's OSCAR
>>> 3) Load on the server is going to decrease
>>> 4) Network load is going to decrease
>>> 5) UI can be entirely multilingual
>>> 6) That the UI becomes more user friendly (short-cut keys, quick navigation,
>>> live-update, asks to save modified data)
>>> 7) That fewer technologies are used to make screens than today
>>> 8) That screens can be made with fewer lines of code that are simple
>>> 9) That existing OSCAR screens can be invoked from the new
>>>  technology screens
>>> 10) Single logon
>>> 11) The new screens log screen access as the old screens do
>>> 12) That the new screens abide by the same security restrictions as the
>>>     old screens do
>>> 13) Documentation (online help, architecture, db-standards, java coding
>>>    standards, UI standards)
>>>
>>> The goals 1..9 have been realized to my satisfaction. Goal 13 is coming
>>> along nicely, as I'm letting the documentation grow with my progress. 10..12
>>> are not so exciting from a 'Proof of Concept' standpoint of view, as I see
>>> little technical challenges in there: It is only a matter of time until
>>> these will be completed.
>>>
>>> By doing the 'proof of concept', I hope get buy-in from David, Jay and
>>> others in the developer community, as well as from vendors and OSCAR users.
>>> "
>>>
>>> Aart
>>>
>>> Peter Hutten-Czapski wrote:
>>>    
>>>      
>>>> During the OSCUS meeting Aart gave a demonstration of proof of concept
>>>> for using new tools (the Google Webkit) to develop the Alberta billing
>>>> module.  As anyone who has looked at Oscar code is probably aware
>>>> OSCAR has used a number of tools, languages, libraries etc over the
>>>> years, depending on the preferences of who was taking the lead.
>>>>
>>>> While under the hood it looks somewhat... well you know..., this has
>>>> served us well in the past, especially when it comes to our
>>>> phagocytosis of code from other projects (Hylafax, mule, drugref,
>>>> hapi).  However code and projects evolve and now that OSCAR is so big,
>>>> it becomes a challenge for debugging, updating (and not breaking
>>>> dependencies) and dare I mention it, documenting (we do have that
>>>> elephant named ISO in the room).
>>>>
>>>> An argument could be made to come to some consensus to pick just one
>>>> (for new code and for rewrites of existing modules).  The
>>>> demonstration certainly showed that OSCAR could be programmed in the
>>>> Google toolkit.  It is very shiny chrome, and has very nice database
>>>> binding, such that forms are updated without being completely redrawn
>>>> and so on.
>>>>
>>>> There was no discussion of this at OSCUS and presumably the acceptance
>>>> of using the Google toolkit is left to David and Jay.  Hard for them
>>>> not to let code be committed in (yet another toolkit should be no big
>>>> impediment), but it is another matter to *gasp* enforce the tools and
>>>> libraries that we use to program with.
>>>>
>>>> However structure is not necessarily bad.  We are after all now coming
>>>> out with releases on a schedule.  Is it time to start by defining the
>>>> tools that we support/endorse?
>>>>
>>>> ================
>>>> Peter Hutten-Czapski
>>>> Haileybury Ontario
>>>>
>>>> "The attitude that ‘if rural people want these services they’ll have
>>>> to come to the city to get them’ is simply not acceptable…” (Newbery,
>>>> 1999)
>>>>
>>>> Before printing, think about the environment. Avant d' imprimer,
>>>> pensez à l'environnement.
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>>>> is the only developer event you need to attend this year. Jumpstart your
>>>> developing skills, take BlackBerry mobile applications to market and stay
>>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>>>> http://p.sf.net/sfu/devconference
>>>> _______________________________________________
>>>> Oscarmcmaster-devel mailing list
>>>> Oscarmcmaster-devel@...
>>>> https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-devel
>>>>
>>>>      
>>>>        
>>>    
>>>      
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Oscarmcmaster-devel mailing list
> Oscarmcmaster-devel@...
> https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-devel
>
>
>
>       __________________________________________________________________
> Looking for the perfect gift? Give the gift of Flickr!
>
> http://www.flickr.com/gift/
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Oscarmcmaster-devel mailing list
> Oscarmcmaster-devel@...
> https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-devel
>  

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Oscarmcmaster-devel mailing list
Oscarmcmaster-devel@...
https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-devel

[Ted Leung-7]

On Sun, Nov 1, 2009 at 12:28 PM, Aart de Vries <aart.de.vries@...> wrote:

Thanks Peter, any more people with input, especially from the lead
developers?

Don't say you should have little influence: The problems you shook up in
your opening e-mail of this thread are real. It is a bit shocking that
an 'amateur' programmer had to do it.

Without embarking onto this topic in too much detail. I just wanted to say that the Hamilton-Oscar developer and the Toronto-Caisi developers have had these discussions over the last 3 years. Specifically they did pertain to performance, maintainability of the code base as well as unifying the libraries and documentation.

It seems like the people involved in this discussion on this thread were never part of those other meetings and discussions.

We has similar concerns about the scope of work, magnitude of change and compatability of new v.s. old libraries etc.

We've made "slow" progress on making some of these changes - mainly because there really isn't anyone of us dedicated to fixing and cleaning up the existing code base. Sometimes it also seems like the mess is growing faster than we're able to clean it up.

My suggestion is that if you're attempting to embark on such a major reworking of the system, you might want to actively gather the hamilton-oscar and toronto-caisi groups to find out what has already been doing and or what is already in the works. It is my understanding that these two groups contribute the majority of the code to the code base.


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Oscarmcmaster-devel mailing list
Oscarmcmaster-devel@...
https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-devel

[Aart de Vries-2]

Thanks Ted,

You are right: I was not part of the discussion, I'm certainly to new to
the OSCAR game. If you have had meetings and discussions on this topic:
Were there any minutes made during those that are open to the public?
It would be really helpful to be able to read upon these things, so that
ignorant developers such as myself don't ask questions that already have
been answered in the past.

Aart

Ted Leung wrote:

> On Sun, Nov 1, 2009 at 12:28 PM, Aart de Vries <aart.de.vries@...
> <mailto:aart.de.vries@...>> wrote:
>
>     Thanks Peter, any more people with input, especially from the lead
>     developers?
>
>     Don't say you should have little influence: The problems you shook
>     up in
>     your opening e-mail of this thread are real. It is a bit shocking that
>     an 'amateur' programmer had to do it.
>
>
> Without embarking onto this topic in too much detail. I just wanted to
> say that the Hamilton-Oscar developer and the Toronto-Caisi developers
> have had these discussions over the last 3 years. Specifically they
> did pertain to performance, maintainability of the code base as well
> as unifying the libraries and documentation.
>
> It seems like the people involved in this discussion on this thread
> were never part of those other meetings and discussions.
>
> We has similar concerns about the scope of work, magnitude of change
> and compatability of new v.s. old libraries etc.
>
> We've made "slow" progress on making some of these changes - mainly
> because there really isn't anyone of us dedicated to fixing and
> cleaning up the existing code base. Sometimes it also seems like the
> mess is growing faster than we're able to clean it up.
>
> My suggestion is that if you're attempting to embark on such a major
> reworking of the system, you might want to actively gather the
> hamilton-oscar and toronto-caisi groups to find out what has already
> been doing and or what is already in the works. It is my understanding
> that these two groups contribute the majority of the code to the code
> base.
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> ------------------------------------------------------------------------
>
> _______________________________________________
> Oscarmcmaster-devel mailing list
> Oscarmcmaster-devel@...
> https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-devel
>  

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Oscarmcmaster-devel mailing list
Oscarmcmaster-devel@...
https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-devel

[Ted Leung-7]

Tthere use to be developer meetings which seem to have stopped in the last little while.

I know that at least some of the discussions were over email, not entirely sure if it was on the mail-list or if it was on direct emails.

We've had discussions on revamping everything from the database, database tables, hibernate/jpa to the mid layer/spring, to the rendering jsp/struts/jsf, to unifying ajax frameworks such as gtw etc. These were pretty long meetings / discussions so I'm not going to go through it in email.

I think there's discussion right now about starting the developer meetings again. That might help spread information and co-ordinate disparate efforts again.

On Sun, Nov 1, 2009 at 7:39 PM, Aart de Vries <aart.de.vries@...> wrote:

Thanks Ted,

You are right: I was not part of the discussion, I'm certainly to new to
the OSCAR game. If you have had meetings and discussions on this topic:
Were there any minutes made during those that are open to the public?
It would be really helpful to be able to read upon these things, so that
ignorant developers such as myself don't ask questions that already have
been answered in the past.

Aart

Ted Leung wrote:
> On Sun, Nov 1, 2009 at 12:28 PM, Aart de Vries <aart.de.vries@...

> <mailto:aart.de.vries@...>> wrote:
>
>     Thanks Peter, any more people with input, especially from the lead
>     developers?
>
>     Don't say you should have little influence: The problems you shook
>     up in
>     your opening e-mail of this thread are real. It is a bit shocking that
>     an 'amateur' programmer had to do it.
>
>
> Without embarking onto this topic in too much detail. I just wanted to
> say that the Hamilton-Oscar developer and the Toronto-Caisi developers
> have had these discussions over the last 3 years. Specifically they
> did pertain to performance, maintainability of the code base as well
> as unifying the libraries and documentation.
>
> It seems like the people involved in this discussion on this thread
> were never part of those other meetings and discussions.
>
> We has similar concerns about the scope of work, magnitude of change
> and compatability of new v.s. old libraries etc.
>
> We've made "slow" progress on making some of these changes - mainly
> because there really isn't anyone of us dedicated to fixing and
> cleaning up the existing code base. Sometimes it also seems like the
> mess is growing faster than we're able to clean it up.
>
> My suggestion is that if you're attempting to embark on such a major
> reworking of the system, you might want to actively gather the
> hamilton-oscar and toronto-caisi groups to find out what has already
> been doing and or what is already in the works. It is my understanding
> that these two groups contribute the majority of the code to the code
> base.
>

> ------------------------------------------------------------------------

>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> ------------------------------------------------------------------------
>
> _______________________________________________
> Oscarmcmaster-devel mailing list
> Oscarmcmaster-devel@...
> https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-devel
>


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Oscarmcmaster-devel mailing list
Oscarmcmaster-devel@...
https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-devel

--
Ted Leung
tedleung@...
---
This e-mail is intended only for the named recipient(s) and may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. No waiver of privilege, confidence or otherwise is intended by virtue of communication via the internet. Any unauthorized use, dissemination or copying is strictly prohibited. If you have received this e-mail in error, or are not named as a recipient, please immediately notify the sender and destroy all copies of this e-mail. Please be aware that internet communications are subject to the risk of data corruption, transmission errors, and privacy breaches.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Oscarmcmaster-devel mailing list
Oscarmcmaster-devel@...
https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-devel

[David Chan-3]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Maybe when CAISI and McMaster developers are meeting, others can dial in.
David

 

David H Chan, MD, CCFP, MSc, FCFP
Associate Professor
Department of Family Medicine
McMaster University

---

From: Ted Leung <tedleung@...>
To: oscarmcmaster-devel@...
Sent: Mon, November 2, 2009 9:58:59 AM
Subject: Re: [Oscarmcmaster-devel] Is there time to apply some discipline to the codebase?

Tthere use to be developer meetings which seem to have stopped in the last little while.

I know that at least some of the discussions were over email, not entirely sure if it was on the mail-list or if it was on direct emails.

We've had discussions on revamping everything from the database, database tables, hibernate/jpa to the mid layer/spring, to the rendering jsp/struts/jsf, to unifying ajax frameworks such as gtw etc. These were pretty long meetings / discussions so I'm not going to go through it in email.

I think there's discussion right now about starting the developer meetings again. That might help spread information and co-ordinate disparate efforts again.

On Sun, Nov 1, 2009 at 7:39 PM, Aart de Vries <aart.de.vries@...> wrote:

Thanks Ted,

You are right: I was not part of the discussion, I'm certainly to new to
the OSCAR game. If you have had meetings and discussions on this topic:
Were there any minutes made during those that are open to the public?
It would be really helpful to be able to read upon these things, so that
ignorant developers such as myself don't ask questions that already have
been answered in the past.

Aart

Ted Leung wrote:
> On Sun, Nov 1, 2009 at 12:28 PM, Aart de Vries <aart.de.vries@...

> <mailto:aart.de.vries@...>> wrote:
>
>     Thanks Peter, any more people with input, especially from the lead
>     developers?
>
>     Don't say you should have little influence: The problems you shook
>     up in
>     your opening e-mail of this thread are real. It is a bit shocking that
>     an 'amateur' programmer had to do it.
>
>
> Without embarking onto this topic in too much detail. I just wanted to
> say that the Hamilton-Oscar developer and the Toronto-Caisi developers
> have had these discussions over the last 3 years. Specifically they
> did pertain to performance, maintainability of the code base as well
> as unifying the libraries and documentation.
>
> It seems like the people involved in this discussion on this thread
> were never part of those other meetings and discussions.
>
> We has similar concerns about the scope of work, magnitude of change
> and compatability of new v.s. old libraries etc.
>
> We've made "slow" progress on making some of these changes - mainly
> because there really isn't anyone of us dedicated to fixing and
> cleaning up the existing code base. Sometimes it also seems like the
> mess is growing faster than we're able to clean it up.
>
> My suggestion is that if you're attempting to embark on such a major
> reworking of the system, you might want to actively gather the
> hamilton-oscar and toronto-caisi groups to find out what has already
> been doing and or what is already in the works. It is my understanding
> that these two groups contribute the majority of the code to the code
> base.
>

> ------------------------------------------------------------------------

>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> ------------------------------------------------------------------------
>
> _______________________________________________
> Oscarmcmaster-devel mailing list
> Oscarmcmaster-devel@...
> https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-devel
>


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Oscarmcmaster-devel mailing list
Oscarmcmaster-devel@...
https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-devel

--
Ted Leung
tedleung@...
---
This e-mail is intended only for the named recipient(s) and may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. No waiver of privilege, confidence or otherwise is intended by virtue of communication via the internet. Any unauthorized use, dissemination or copying is strictly prohibited. If you have received this e-mail in error, or are not named as a recipient, please immediately notify the sender and destroy all copies of this e-mail. Please be aware that internet communications are subject to the risk of data corruption, transmission errors, and privacy breaches.

---

Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Oscarmcmaster-devel mailing list
Oscarmcmaster-devel@...
https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-devel