Prosjekt Slektsforskningsweb - Programmerere søkes

[tnViking]

Snedig at det ikke er større interesse i dette..

 

Det er vell fordi folk ikke bryr seg om slekten sin.

Og ikke tenker på at dette ville vært en fin inntekt og noe bra å ha i CVn sin

[MR2i]

Er ikke nødvendig med å ha interesse for slektsforskning, selv om det kanskje kan være en fordel...

 

Det er hovedsakelig det å faktisk få en løsning "som selv mor" kan bruke..

[rozon]

Jeg har tid til en klient til. Ta kontakt på PM...

[MR2i]

Myheritage.com har nå slått på stortromma og lansert v. 6.0 av Family Tree Builder.

 

De lager nye versjoner, legger til nye ting.. men fikser ikke feilene fra tidligere versjoner.. og legger bare til nye bugs.. Selv Windows er bedre. De legger til nye feil.. men gjør noe med de gamle om ikke annet..

[dahuff]

Er det snakk om en Java-basert løsning?

 

Det er ikke fastsatt, men tror Java kanskje har en bedre plattform på tvers av teknologier i forhold til ønsket funksjon.

Men kanskje en kombinasjon Java og PHP er nødvendig.

Jeg kan dessverre litt for lite om Java.

Med tanke på at å bygge trestrukturer krever endel ressurser (rekursive kall, database IO), og at PHP ikke er ett ideelt verktøy å bygge søkemotorer på, er det klart at valg av verktøy kan få betydning. Jeg antar på bakgrunn av det du skriver at søk og bygging av tre (familietre) blir viktige for denne løsningen.

 

Jeg vil likevel ikke avfeie PHP helt i ett slikt prosjekt. PHP vil være utmerket for å bygge en prototype, og til og med for å bygge en "versjon 1.0". Det koster lite å få ett PHP prosjekt i gang og finne ut hvordan mottakelsen er. Svært få prosjekter blir populære nok til at de vokser fra hva du kan få til med PHP.

 

Det er bare å være forberedt over at man må skrape alt og starte forfra i ett nytt språk og rammeverk med den endelige versjonen. Fordelen er at man vil ha ett mye bedre bilde av hva og hvordan man skal gjøre ting, slik at det blir mindre eksperimentering og opplæring når man går i gang å lage produksjonskode.

 

Om en slik strategi er interessant, går det jo an å bruke PHP rammeverk som har tilsvarende rammeverk i ett annet språk for å lette overgangen f.eks. Det er gode muligheter for dette.

 

Nå er det ikke sikkert om rådene mine har så mye tyngde (er alltids lettere å mene noe enn å gjøre noe), men kanskje det hjelper for i å skyve planleggingen videre.

Endret 30. desember 2011 av dahuff

[dahuff]

Videre er dette sikkert en bra kandidat for nosql. Tenk deg å hente ut objektet "FamilyMember" istede for å skrive sql-spørring og deretter lage objektene.

 

Eksempel med mongodb og php:

http://devzone.zend.com/1730/getting-started-with-mongodb-and-php/

 

Står kanskje mer her:

http://nosql-database.org/

[LostOblivion]

Videre er dette sikkert en bra kandidat for nosql. Tenk deg å hente ut objektet "FamilyMember" istede for å skrive sql-spørring og deretter lage objektene.

 

Eksempel med mongodb og php:

http://devzone.zend.com/1730/getting-started-with-mongodb-and-php/

 

Står kanskje mer her:

http://nosql-database.org/

hibernate, om det er en Java-løsning.

[torbjørn marø]

Videre er dette sikkert en bra kandidat for nosql. Tenk deg å hente ut objektet "FamilyMember" istede for å skrive sql-spørring og deretter lage objektene.

 

Eksempel med mongodb og php:

http://devzone.zend.com/1730/getting-started-with-mongodb-and-php/

 

Står kanskje mer her:

http://nosql-database.org/

MongoDB er en dokument-database - jeg ser for meg at dette problemet er bedre løst med en graf-database. Ta en titt på Neo4j.

[dahuff]

Videre er dette sikkert en bra kandidat for nosql. Tenk deg å hente ut objektet "FamilyMember" istede for å skrive sql-spørring og deretter lage objektene.

 

Eksempel med mongodb og php:

http://devzone.zend.com/1730/getting-started-with-mongodb-and-php/

 

Står kanskje mer her:

http://nosql-database.org/

MongoDB er en dokument-database - jeg ser for meg at dette problemet er bedre løst med en graf-database. Ta en titt på Neo4j.

Kanskje det ikke spiller spiller så stor rolle hvilket språk slektsprogrammet skrives i om man med graph database kan si; gi meg slektstreet til person x. Da vil databasen gjøre det tunge arbeidet, om jeg tolket prinsippet med graf-database riktig. Interessant.

[torbjørn marø]

hibernate, om det er en Java-løsning.

Ikke vondt ment, men dette er et klassisk eksempel på manglende forståelse for at man må velge riktig verktøy for ethvert problem. Selv om man har et verktøy som løser en utfordring på en god måte, så kan man ikke bruke det til hva som helst.

 

Hva skal man med ORM hvis man ikke har R?

[JohndoeMAKT]

Det høres absolutt interessant ut da min far har drevet litt med dette tidligere, og jeg blir alltid overrasket over hvor dårlige verktøy det er for dette.

 

Jeg er med dersom dette blir en gratis online-tjeneste hvor alle data lagt inn må lisensieres under CC, all data kan enkelt eksporteres til et åpent format og at kildekoden er tilgjengelig med en fri lisens.

[LostOblivion]

hibernate, om det er en Java-løsning.

Ikke vondt ment, men dette er et klassisk eksempel på manglende forståelse for at man må velge riktig verktøy for ethvert problem. Selv om man har et verktøy som løser en utfordring på en god måte, så kan man ikke bruke det til hva som helst.

 

Hva skal man med ORM hvis man ikke har R?

 

Selv om det skal være et prosjekt som hovedaklig angår å lagre og traversere trær effektivt, er det langt ifra det eneste man skal skrive. Hvis du ser på prosjekter som MyHeritage f.eks., som lar brukeren registrere tonnevis med info om hver eneste person, ser man lett at det blir bruk for 'R'. Dessuten er tre-delen ikke så altfor stor, 20000 noder blir fort veldig lite. Kunne muligens brukt dedikerte og optimaliserte DB for tre-delen.

 

Ikke sett meg i en boks, jeg vet hva jeg snakker om.

Endret 5. januar 2012 av LostOblivion

[GeirGrusom]

hibernate, om det er en Java-løsning.

Ikke vondt ment, men dette er et klassisk eksempel på manglende forståelse for at man må velge riktig verktøy for ethvert problem. Selv om man har et verktøy som løser en utfordring på en god måte, så kan man ikke bruke det til hva som helst.

 

Hva skal man med ORM hvis man ikke har R?

Åkei... hva er argumentet ditt her egentlig? For jeg kan ikke se noen.

[StoltHD]

Jeg har drevet en tid med slektsforskning. Har 23.000+ navn i slektstreet mitt, og vokser stadig.

 

Jeg har konto på www.geni.com og www.myheritage.com

 

Disse virker rett og slett ikke. www.geni.com ga jeg opp bare etter et par uker, og www.myheritage.com har jeg kjeftet de ansatte opp og ned i mente for total inkompetanse. Jeg lagde tilogmed et visual basic program for å lese ut deres resultatliste for kildesøk. De har en feilmargin på 50%+. Om du har en person Ola Nordmann født i 1800, så kommer forslaget Kari Normann født 1900 som et "godt" alternativ for å være samme person!! Selv barn skjønner at det er feil person. Jeg lagde derfor programmet for å lese websiden og plukke ut det som var interessant. Eks: Ut fra en liste over 3 sider, med 115 resultater, var bare 4 interessante. Mao. veldig stor tidsbesparelse.

 

De kaller sitt system "Smart Match". Jeg døpte det om til "Plain Stupid Match" i forumet til www.myheritage.com.

 

Dessuten er det ikke noe alternativ for de som har lyst på sitt slektstre, men orker ikke stria med å finne frem i kirkebøker og andre medier som man kan bruke som kilde.

 

Jeg vurderer derfor å starte et aksjeselskap med 3-4 programmerere innen mysql/php/java evt. hva som kan være et alternativ for å få til et bedre produkt enn feks. myheritage.

 

Myheritage.com omsetter for ca 50 MNOK i året. Jeg tror det kan slås med god margin grunnet bedre produktidé som i tillegg til de vanlige slektsforskningsinteresserte også treffer de som ikke gidder slektsforskning men hadde hatt glede av å se sitt eget slektstre.

 

Noen som kunne tenkt seg å blitt med på et sådant prosjekt?

Vi deler selskapet likt oss i mellom de som evt. blir med.

 

 

 

Strukturen og databasene finnes allerede som "open source", gode webbaserte løsninger som du sikkert kan bygge videre på/utvide.

gå inn på sourceforge.net og søk på geneology....

[VD]

Høres ut som ett veldig spennende prosjekt. Er selv dataingeniør og kunne selvsagt tenkt meg å blitt med men desverre er ikke programmering min sterkeste side (selv om jeg har vært innom en del og lærer stadig nye ting)

 

Selv har jeg holdt meg unna online tjenestene og bruker Legacy til min slektsforskning.

Ihvertfall til nå.

 

Lykke til.

[torbjørn marø]

hibernate, om det er en Java-løsning.

Ikke vondt ment, men dette er et klassisk eksempel på manglende forståelse for at man må velge riktig verktøy for ethvert problem. Selv om man har et verktøy som løser en utfordring på en god måte, så kan man ikke bruke det til hva som helst.

 

Hva skal man med ORM hvis man ikke har R?

 

...snip...

 

Ikke sett meg i en boks, jeg vet hva jeg snakker om.

Når du ikke sa mer enn du gjorde så var det ganske vanskelig for meg å ikke sette deg i den båsen. Du siterte et innlegg om NoSQL-teknologier, og sa at om det dreide seg om en Java-løsning så var svaret Hibernate.

 

Det virket altså som om du blåste en lang en i NoSQL-forslaget, og hevder at Hibernate uansett vil være en bedre løsning. Der kan vi selvsagt være uenige, men måten du gjorde det på var vanskelig å respektere.

 

Hibernate er dessuten ikke et alternativ i sammenhengen du siterte - det ville vært mer naturlig å argumentere for hvorfor en relasjonsdatabase burde fungere bra, ikke å hevde at en tung objektabstraksjon på toppen skulle løse noe. SQL vs. NoSQL handler om persistering, Hibernate handler om bruk av persistert data.

 

Min egen oppfatning er også at Hibernate ville kunne skape unødige problemer i forhold til en ikke-ORM SQL-basert løsning - men det er beside the point.

 

Som jeg sa var det ikke vondt ment, men kommer man med ubegrunnede utsagn som på meg virker lite reflekterte så sier jeg min mening!

 

hibernate, om det er en Java-løsning.

Ikke vondt ment, men dette er et klassisk eksempel på manglende forståelse for at man må velge riktig verktøy for ethvert problem. Selv om man har et verktøy som løser en utfordring på en god måte, så kan man ikke bruke det til hva som helst.

 

Hva skal man med ORM hvis man ikke har R?

Åkei... hva er argumentet ditt her egentlig? For jeg kan ikke se noen.

Det var ikke mye argumentasjon, det skal jeg være enig i. Men han kontret altså en diskusjon om NoSQL med Hibernate. Hvis man f.eks. ønsker å bruke MongoDB så blir jo da altså Hibernate helt overflødig. I tillegg føler jeg Hibernate og en relasjonsdatabase blir en direkte dårlig løsning på dette problemet - men det har jeg ikke argumentert for, og det kan hende jeg tar feil.

 

PS: Det var ikke min intensjon å gi dere to positiv tilbakemelding på innleggene - trykket feil

[dahuff]

Jeg tror det blir en avsporing å la debatten handle om ORM når graph-databaser synes å være ment spesielt for å brukes for å finne fram i relasjoner mellom noder, slik som i ett slektstre.

 

OrientDB er både dokument og graph database på samme tid, og skjønner SQL.

http://code.google.com/p/orient/wiki/GraphDatabase

[StoltHD]

Høres ut som ett veldig spennende prosjekt. Er selv dataingeniør og kunne selvsagt tenkt meg å blitt med men desverre er ikke programmering min sterkeste side (selv om jeg har vært innom en del og lærer stadig nye ting)

 

Selv har jeg holdt meg unna online tjenestene og bruker Legacy til min slektsforskning.

Ihvertfall til nå.

 

Lykke til.

 

Legacy er topp, og bruker en access database i bunnen.... ergo... ved å få åpnet databasen og lagd en link, så kunne man ha hatt 2 veis sync til en sql database med enkle midler... da ville kun webgrensesnittet gjenstått...

[VD]

 

Legacy er topp, og bruker en access database i bunnen.... ergo... ved å få åpnet databasen og lagd en link, så kunne man ha hatt 2 veis sync til en sql database med enkle midler... da ville kun webgrensesnittet gjenstått...

 

 

Hmm har jeg ikke tenkt på. Kansje det skal bli helgas prosjekt hehe.

[VD]

Jøss. Det var jo rett fram det jo. Kult. Takk for tips StoltHD. Da har jeg noe å leke med =)