Re: [Ldsoss] Scout Tracking
Tom Welch wrote: I've used Dia in the past for Linux. I've not used Umbrello but it looks like it should do the trick just fine I used Umbrello briefly once. As I recall, it worked reasonably well for drawing, but I didn't care for its round-trip code-generation. Unless you are doing sequence diagrams, or generating code, my experience has been that CASE tools aren't worth the hassle. Visio or Dia works just as well. * As a general note: If you want to allow for synchronization between a local system and a remote system then all of your primary keys should be in the form of a guid (I use varchar(32)). Most DB's have an auto-increment type for ints and these are used as primary keys but you can't synchronize as easily .. especially if you are allowing for a multi-user system because two keys could get the same value. If your is not to allow for synchronization then I'd let the DB handle the auto-assigning of the primary key. There was a previous link to GUID's and UUID's in an earlier discussion that pointed to Wikipedia. Any system that wants to support synchronization should probably use some form of GUID. * On the "address_table", what is the "date" field for? Also do we think that we will have multiple addresses for people and so need to keep a separate table for them? I agree if this is to be expected then it would be more efficient to have the addresses in a separate table. With all the devorces, multiple addresses actually makes sense. However, to avoid burdening everyone with multiple addresses, you might define a set of "primary" address fields. * What is the date field on the "phone_table" used for? In fact, all tables have a "date" field. I'm not sure their purpose. * On the "Emergency Contact" section, I can see that you intend to have a small link table linking "boys" to their parents or other contacts. My comment here is that it may be a bit of "overkill" to force the user to enter in all parents and other people that act as emergency contact information into the DB. What I mean is that if I enter in a boy's information (address, phone number, etc) I then have to enter in the same information for his parents so that I can link the boy to the parent. What you end up with is two records with basically the same information. It may be more efficient to create a "family" table which would consist of the last name of the family and then the address, phone numbers, etc. Then have a "family members" table which you enter in family members (first name, birthdates, etc). This way you are not double or triple entering in the address. To be PC, I'd suggest calling this a "Household" and you possible might want to define one or more "Head of Household". * On the "authorization_table", I recommend that you lose the "userid" and use the email address to verify and allow the user to login. I hate it when sites do this. You are presuming (a) a person's email is fixed for life, (b) that ISP's don't reissue email addresses. Neither of these conditions are assured. One of my original ISP's re-issued my email address to someone else within a few months of my dropping the account. IMHO, email address should no more be used for a userid then a street address. * On the Image and Picture tables, would it make more sense to store the data in a blob in the DB instead of having a link to a file? Links are easily broken. Also, file links tend to interfere with data portabilility. Good start Oscar. I'm not a fan of PHP, but databases are universal :-) Also, going with a "web" application will usually facilitate a n-tier application approach, so even if the user stages it entirely on one box, the application will have been designed so that it can later be scaled. Putting a fat client on a web application is much easier then refactoring a desktop application or a client-server application. -- A. Rick Anderson ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Bounties, BarCamps, etc.
I'd love to pick it up, but the process may be a slow one - I've got 2 contractual things going on at the same time right now. Let me know what you've got and I'd love to build a client for it.Jesse
On 7/10/06, Paul Johnson <[EMAIL PROTECTED]> wrote:
On Mon, Jul 10, 2006 at 02:02:10PM -0600, Jesse Stay wrote:> Not for a bounty, but I've been wanting to develop an AJAX pedigree> browser for awhile now. You can overcome most of the cross-browser> compatibility issues by using many of the AJAX libraries that are out
> there.I've been wanting to do the same thing, but just don't have the time.I've written (most of?) the webservices code, so now it's (just!) thefront end that's left. I was planning on using Dojo, which looks very
nice, seems to be well supported and should take care of the crossbrowser compatibility problems.I'd be very pleased if someone wants to pick it up and run with it.--Paul Johnson -
[EMAIL PROTECTED]http://www.pjcj.net-- #!/usr/bin/perl$^=q;@!>~|{>krw>yn{u<$$ 0gFzD gD, 00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{ rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
___
Ldsoss mailing list
Ldsoss@lists.ldsoss.org
http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Bounties, BarCamps, etc.
On Mon, Jul 10, 2006 at 02:02:10PM -0600, Jesse Stay wrote: > Not for a bounty, but I've been wanting to develop an AJAX pedigree > browser for awhile now. You can overcome most of the cross-browser > compatibility issues by using many of the AJAX libraries that are out > there. I've been wanting to do the same thing, but just don't have the time. I've written (most of?) the webservices code, so now it's (just!) the front end that's left. I was planning on using Dojo, which looks very nice, seems to be well supported and should take care of the cross browser compatibility problems. I'd be very pleased if someone wants to pick it up and run with it. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Bounties, BarCamps, etc.
Not for a bounty, but I've been wanting to develop an AJAX pedigree browser for awhile now. You can overcome most of the cross-browser compatibility issues by using many of the AJAX libraries that are out there. We use it pretty consistently in our checkout process on
backcountry.com, and while testing is important, it hasn't been too big of an issue. I've found most of the issues Flex claims to solve can be solved with good _javascript_ libraries and experience in using them.
The other important thing, and this applies to even Flex, is that establishing a set of browsers your code will work on no matter what helps to set your limits on what you need to test on. There comes a point where older browsers just don't make sense to support any more.
JesseOn 7/10/06, Dallan Quass <[EMAIL PROTECTED]> wrote:
I've been burned too many times with _javascript_ not
working cross-browser. Code that I develop that works fine under
Firefox has bugs that are difficult to find (for me at least) under
IE. I recently had a situation where code that ran fine under IE6
just stopped working one day even though I had made no changes to my
code. I assume it was due to an automatic IE update. To test my
_javascript_ code I have one machine running IE5.5, one running IE6.0, one
running IE7beta, and I wish I still had a Mac machine to test on.
With Flex I get a stable VM that's on 95% of browsers where I don't have to
worry about browser compatibility. I agree an open platform would be
better, but overall it seems like a reasonable trade-off. Also, Flex
apps can be made to look cooler due to the built-in graphics effects, like
fade - and one of the things I'd like to do is create some online genealogy
games someday. I'd consider OpenLaszlo (www.openlaszlo.org) if enough people were
interested.
-dallan
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Jesse
StaySent: Monday, July 10, 2006 1:32 PMTo: LDS Open
Source SoftwareSubject: Re: [Ldsoss] Bounties, BarCamps,
etc.
Does the pedigree manager have to be in Flex? Why not AJAX
out of curiosity? AJAX is much more open IMO, and promotes others to
learn how you wrote the code.Jesse
On 7/10/06, Dallan
Quass <[EMAIL PROTECTED]>
wrote:
I'm
willing to do open-source programming and even sponsor
open-sourceprogramming for family history. I'd like to get
responses on what peoplethink is the most effective way to get
started. Here are some ideas; I'm interested in feedback on
these ideas and other ideas.(1) BarCamps. I could attend
and help sponsor the BarCampUtah that PhilBurns is putting together if
others interested in doing open-sourceprogramming for family history are
planning to attend. (2) Monthly meetings. I could
possibly organize a monthly meeting wherepeople could get together to
coordinate work on open-source family historyprojects. The
meeting could either be in-person (Utah Valley, with food), or online
(Skype/IRC).(3) Bounties. A bounty is a small payment
offered for someone to develop aparticular feature on an open-source
project. I could offer bounties forexample on a MediaWiki
(Wikipedia) tag handler that would display thumbnails of
images from flickr on wiki pages, a MediaWiki taghandler to
display the posts from a blog (rss feed), or an online(implemented in
Macromedia Flex) pedigree
manager.-dallan___Ldsoss
mailing listLdsoss@lists.ldsoss.org
http://lists.ldsoss.org/mailman/listinfo/ldsoss
--
#!/usr/bin/perl$^=q;@!>~|{>krw>yn{u<$$ 0gFzD gD, 00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~>
"@=,m,|,(e 0.), 01,pnn,y{ rw} >;,$0=q,$,,($_=$^)=~y,$/
C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
-- #!/usr/bin/perl$^=q;@!>~|{>krw>yn{u<$$ 0gFzD gD, 00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{ rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
___
Ldsoss mailing list
Ldsoss@lists.ldsoss.org
http://lists.ldsoss.org/mailman/listinfo/ldsoss
RE: [Ldsoss] Bounties, BarCamps, etc.
I've been burned too many times with _javascript_ not
working cross-browser. Code that I develop that works fine under
Firefox has bugs that are difficult to find (for me at least) under
IE. I recently had a situation where code that ran fine under IE6
just stopped working one day even though I had made no changes to my
code. I assume it was due to an automatic IE update. To test my
_javascript_ code I have one machine running IE5.5, one running IE6.0, one
running IE7beta, and I wish I still had a Mac machine to test on.
With Flex I get a stable VM that's on 95% of browsers where I don't have to
worry about browser compatibility. I agree an open platform would be
better, but overall it seems like a reasonable trade-off. Also, Flex
apps can be made to look cooler due to the built-in graphics effects, like
fade - and one of the things I'd like to do is create some online genealogy
games someday. I'd consider OpenLaszlo (www.openlaszlo.org) if enough people were
interested.
-dallan
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jesse
StaySent: Monday, July 10, 2006 1:32 PMTo: LDS Open
Source SoftwareSubject: Re: [Ldsoss] Bounties, BarCamps,
etc.
Does the pedigree manager have to be in Flex? Why not AJAX
out of curiosity? AJAX is much more open IMO, and promotes others to
learn how you wrote the code.Jesse
On 7/10/06, Dallan
Quass <[EMAIL PROTECTED]>
wrote:
I'm
willing to do open-source programming and even sponsor
open-sourceprogramming for family history. I'd like to get
responses on what peoplethink is the most effective way to get
started. Here are some ideas; I'm interested in feedback on
these ideas and other ideas.(1) BarCamps. I could attend
and help sponsor the BarCampUtah that PhilBurns is putting together if
others interested in doing open-sourceprogramming for family history are
planning to attend. (2) Monthly meetings. I could
possibly organize a monthly meeting wherepeople could get together to
coordinate work on open-source family historyprojects. The
meeting could either be in-person (Utah Valley, with food), or online
(Skype/IRC).(3) Bounties. A bounty is a small payment
offered for someone to develop aparticular feature on an open-source
project. I could offer bounties forexample on a MediaWiki
(Wikipedia) tag handler that would display thumbnails of
images from flickr on wiki pages, a MediaWiki taghandler to
display the posts from a blog (rss feed), or an online(implemented in
Macromedia Flex) pedigree
manager.-dallan___Ldsoss
mailing listLdsoss@lists.ldsoss.orghttp://lists.ldsoss.org/mailman/listinfo/ldsoss
--
#!/usr/bin/perl$^=q;@!>~|{>krw>yn{u<$$ 0gFzD gD, 00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~>
"@=,m,|,(e 0.), 01,pnn,y{ rw} >;,$0=q,$,,($_=$^)=~y,$/
C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
___
Ldsoss mailing list
Ldsoss@lists.ldsoss.org
http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Bounties, BarCamps, etc.
Does the pedigree manager have to be in Flex? Why not AJAX out of curiosity? AJAX is much more open IMO, and promotes others to learn how you wrote the code.JesseOn 7/10/06,
Dallan Quass <[EMAIL PROTECTED]> wrote:
I'm willing to do open-source programming and even sponsor open-sourceprogramming for family history. I'd like to get responses on what peoplethink is the most effective way to get started. Here are some ideas; I'm
interested in feedback on these ideas and other ideas.(1) BarCamps. I could attend and help sponsor the BarCampUtah that PhilBurns is putting together if others interested in doing open-sourceprogramming for family history are planning to attend.
(2) Monthly meetings. I could possibly organize a monthly meeting wherepeople could get together to coordinate work on open-source family historyprojects. The meeting could either be in-person (Utah Valley, with food),
or online (Skype/IRC).(3) Bounties. A bounty is a small payment offered for someone to develop aparticular feature on an open-source project. I could offer bounties forexample on a MediaWiki (Wikipedia) tag handler that would display
thumbnails of images from flickr on wiki pages, a MediaWiki taghandler to display the posts from a blog (rss feed), or an online(implemented in Macromedia Flex) pedigree manager.-dallan
___Ldsoss mailing listLdsoss@lists.ldsoss.orghttp://lists.ldsoss.org/mailman/listinfo/ldsoss
-- #!/usr/bin/perl$^=q;@!>~|{>krw>yn{u<$$ 0gFzD gD, 00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{ rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
___
Ldsoss mailing list
Ldsoss@lists.ldsoss.org
http://lists.ldsoss.org/mailman/listinfo/ldsoss
[Ldsoss] Bounties, BarCamps, etc.
I'm willing to do open-source programming and even sponsor open-source programming for family history. I'd like to get responses on what people think is the most effective way to get started. Here are some ideas; I'm interested in feedback on these ideas and other ideas. (1) BarCamps. I could attend and help sponsor the BarCampUtah that Phil Burns is putting together if others interested in doing open-source programming for family history are planning to attend. (2) Monthly meetings. I could possibly organize a monthly meeting where people could get together to coordinate work on open-source family history projects. The meeting could either be in-person (Utah Valley, with food), or online (Skype/IRC). (3) Bounties. A bounty is a small payment offered for someone to develop a particular feature on an open-source project. I could offer bounties for example on a MediaWiki (Wikipedia) tag handler that would display thumbnails of images from flickr on wiki pages, a MediaWiki tag handler to display the posts from a blog (rss feed), or an online (implemented in Macromedia Flex) pedigree manager. -dallan ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
I've used Dia in the past for Linux. I've not used Umbrello but it looks like it should do the trick just fine. Also, to model the data, have you given MySQL Workbench a try? Here are my comments on your data table. Take them for what they are worth...about a nickel and two pennies. As a general note: If you want to allow for synchronization between a local system and a remote system then all of your primary keys should be in the form of a guid (I use varchar(32)). Most DB's have an auto-increment type for ints and these are used as primary keys but you can't synchronize as easily .. especially if you are allowing for a multi-user system because two keys could get the same value. If your is not to allow for synchronization then I'd let the DB handle the auto-assigning of the primary key. On the "people_table", why do you have "birthdate" and also "birthmonth", "birthyear" and "date". It seems that "birthdate" would handle it and any programming language you use could extract the month/year easily. On the "address_table", what is the "date" field for? Also do we think that we will have multiple addresses for people and so need to keep a separate table for them? I agree if this is to be expected then it would be more efficient to have the addresses in a separate table. What is the date field on the "phone_table" used for? In fact, all tables have a "date" field. I'm not sure their purpose. On the "Emergency Contact" section, I can see that you intend to have a small link table linking "boys" to their parents or other contacts. My comment here is that it may be a bit of "overkill" to force the user to enter in all parents and other people that act as emergency contact information into the DB. What I mean is that if I enter in a boy's information (address, phone number, etc) I then have to enter in the same information for his parents so that I can link the boy to the parent. What you end up with is two records with basically the same information. It may be more efficient to create a "family" table which would consist of the last name of the family and then the address, phone numbers, etc. Then have a "family members" table which you enter in family members (first name, birthdates, etc). This way you are not double or triple entering in the address. On the "authorization_table", why do you have two password fields? You will need to ask for the user to enter in the password twice but that is to just verify that it is entered in correctly. On the "authorization_table", I recommend that you lose the "userid" and use the email address to verify and allow the user to login. On the Image and Picture tables, would it make more sense to store the data in a blob in the DB instead of having a link to a file? Links are easily broken. Good start Oscar. Tom Oscar Schultz wrote: Hopefully someone on the list has reviewed my set of tables and fields. no responses about the structure yet. I need a list of the needed basic functions to produce a tracker with a minimum set of functions . A set of functions to manage (add,delete, modify) people, events, awards, requirements, and produce a set of reports is what I think are needed . Additionally a set of functions to manage access to the program data. Any linux fans out there have a favorite tool to design the application. I'm looking for a good tool to flow-chart with and to do the initial design work of the app. I have looked at using umbrello to doc/flowchart the app . Suggestions are appreciated . I also plan to use sane and subversion, to extend what I can write to include scanning and image/picture version tracking . thanks oscar On Friday 07 July 2006 10:44 pm, Oscar Schultz wrote: I have spent some time attempting to setup a sql database and tables as the basis for my version of the tracking software. Hopefully those database admins out there can review my table outline for missing fields and/or crazy table relationships and make some helpful comments. enjoy and thanks oscar #the table to record personal information people_table record_id firstname middlename lastname preferredname gender birthdate birthmonth birthyear date # the table to record personal address information # 1 people record to many address record relationship address_table record_id people_record_id address1 address2 city county state zipcode type (primary, secondary, mailbox, residence, shipping, other, unknown) date # the table to record personal phone information # 1 people record to many phone record relationship phone_table record_id people_record_id type (personal cell, home, business, home2, business cell) number date # a table to record emergency contacts # 1 personal to many personal relationship emergency_contact_table record_id people_record_id (participate) people_record_id (emergency contact) relationship date # the authorization table to control access via the # web interface authorization_tabl
