oship-dev team mailing list archive

[Tim Cook <timothywayne.cook@xxxxxxxxx>]

Hi All,

After re-reading this and thinking about it a bit.  I realized that it
had a bit of a worksome/negative tone to it.

I want to take a moment of your time and present the upside.

Healthcare IT is the fastest growing area of IT worldwide.

Open source is the fastest growing approach to application development
worldwide.

The openEHR specifications have been in development for more than 20
years.  They were not developed by a committee sitting around a table.
They were developed by a group of clinicians and technologists and then
PROVEN that they actually worked in software.  There are several
implementations of the openEHR specs in various OO languages.  Can
anyone show me one single implementation of the HL7 v3 RIM in software?
in ANY language? ....waiting.........

There are movements around the world and especially in developing
countries to adopt these specifications as national standards.  Portions
of the openEHR specs have been adopted as ISO standards and all of the
openEHR specs were used to inform the formation of ISO 13606.

So; for your minor efforts here, I offer you an education in what is
rapidly becoming the worldwide standard in healthcare IT.

I hope that puts a little more positive (but very honest) spin on
things.

--Tim

 


On Thu, 2009-08-27 at 14:21 -0300, Tim Cook wrote:
> First, I would like to thank you all for spending time on this project.
> It has been a mission of mine for more than three years and it is a
> great feeling to have multiple people working on it with me.
> 
> Secondly, most if not all of you are probably better programmers than I.
> So do not be shy about making corrections and comments.  However, I do
> hold a philosophy of re-use of open source code.  Especially when I know
> that that code has been proven to be reliable in many implementations.
> IF you look at the statistics on Ohloh for this project
> http://www.ohloh.net/projects/oship probably less than 10% is actually
> new code.  Some this code actually dates back to 1985 but it has been
> continuously maintained.  Also, these stats do not include all of the
> Grok/Zope code that is pulled down as eggs.  When we get to a 1.0 beta
> point I will drop my shared eggs directory and include those eggs in the
> distribution so we know exactly what goes into the 1.0 release.  This
> will also make installation easier for end users (who are actually
> application developers).
> 
> You should install OSHIP per the instructions in the FAQ for your OS:
> https://answers.launchpad.net/oship/+faqs 
> 
> Be sure to use the shared eggs instructions as well.
> 
> 
> Back on topic of code review.  
> 
> The first thing you must do is create a branch to work in.  You do this
> by selecting the tab labeled Code at the top of the OSHIP project page.
> Near the top right you will find a link that says "Register a branch"
> click that link.
> 
> This takes you to a page where you setup your branch.  By default the
> owner shown should be you.  Name your branch the same as your Blueprint
> name i.e. codereview-datatypes. Then click the "Hosted" radio button
> then the "Development" radio button.  Submit the form by clicking the
> "Register Branch" button.
> 
> Back on the page where all of the branches are listed, find yours and
> click on the link.  On the left side you will see a link to associate a
> Blueprint.  Click this link and in the input box enter the name of your
> Blueprint.  Submit the form.
> 
> Back on your code branch main page you will see instructions on how to
> update your branch.  You currently have no code.  But since you do have
> the latest trunk code you can use that to populate your branch.
> 
> For example you'll see something like:
> bzr push lp:~timothywayne-cook/oship/datatypes where this is for
> updating my datatypes branch.  Now, in a terminal window, go to the
> directory just below your ~oshipenv directory.  The one that contains
> a .bzr file. Then issue the command: 
> 
> bzr push lp:~<your-branch-name-here> --use-existing-dir 
> 
> This will populate your branch with the current trunk code with all of
> the history intact. 
> 
> Now you are ready to go to work...... 
> 
> I have found that a two step process works best when doing this task.
> 1.  Compare the code to the specifications, noting any discrepancies as
> bug reports and associate them with the Blueprint.  
> 
> 2. Now go back and begin fixing the bugs that you can and ask for help
> on the ones where you need assistance. 
> 
> 
> We are working within the Grok framework.  Grok is a layer on the Zope
> Tool Kit (ZTK) also called the Zope Component Architecture (ZCA) or
> Zope3.  Grok simplifies the configuration of the ZTK (the preferred name
> now).
> 
> With this in mind and not going into too much detail; anywhere that you
> think that you would use 'object' as a base class to inherit from.   You
> must instead use grok.Model.  This plugs us into the Grok framework.
> Also any interface that defines a schema for one of those base classes
> should inherit from zope.interface.Interface 
> 
> While I do not usually take this approach.  This is certainly a time to
> do so for two reasons.  I do not want any code reviewers to spend too
> much time going through the Grok and Zope documentation looking for
> answers right now.
> 
> a)  There has been a lot of churn in the component structures and the
> documentation hasn't kept pace.  Though we have started a Grok Doc
> update project and there will be a Doc Sprint in 2 weeks.
> 
> b)  There are many concepts that can get very confusing very quickly if
> you are new to Zope/Grok.
> 
> If you have a question about why/how something was done in your module
> please ask on the mailing list.  I will either have an answer for you,
> be able to point you exactly to one or two documents or say oooops! I
> really screwed that up. :-)
> 
> One final thing to be aware of is that the order of the interfaces and
> classes in the modules are not neat and do not seem to make sense.  But
> they had to be arranged this way, in many case to prevent circular
> imports, or undefined class errors.  So, please do not rearrange the
> orders to make them look nice.  :-)
> 
> Be sure to put your name and email address in the __contributors__ space
> in the file headers.
> 
> Thanks,
> Tim
> 
> PS.  If anyone needs tips on setting up WingIDE ask on the list and I'll
> give a few tips.  I'm not an expert but I do have some experience with
> it.
>  
> 
> 
> 
> 
-- 
Timothy Cook, MSc
Health Informatics Research & Development Services
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook 
Skype ID == timothy.cook 
***************************************************************
*You may get my Public GPG key from  popular keyservers or    *
*from this link http://timothywayne.cook.googlepages.com/home *
***************************************************************

Attachment: signature.asc
Description: This is a digitally signed message part