oship-dev team mailing list archive
-
oship-dev team
-
Mailing list archive
-
Message #00362
Notes for Code Reviewers
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
Follow ups