Sziasztok!
Bölcsészettudományi projekthez szeretnénk webes adatbázist készíteni, valami hasonlót, mint ezek:
Egy felhasználóbarát, modern kinézetű, könnyen kereshető, sok keresési szűrővel ellátott adatbázist szeretnénk csináltatni, mint amilyenek a fentebbi példák. Tekintve, hogy még nem készíttettünk ilyet, szeretnék érdeklődni, hogy amikor tárgyalunk ezzel kapcsolatban informatikusokkal, milyen paraméterekkel és igényekkel érdemes előállnunk? Én a következőkre jutottam olvasgatásaim során.
Adatbázis
Milyen adatbázis-kezelőt használ? Az adatbázis-kezelő szoftvernek van megfelelő múltja és jövője?
Az adatbázis-kezelő platformfüggetlen? Jól működik számos operációs rendszeren és böngészőn? Le is tudja ezt tesztelni a fejlesztőnk?
Mennyire van képben a legújabb technológiákkal? Jó lenne, ha cutting edge lenne, hogy 10 év múlva is még jónak számítson a rendszerünk.
Minőség és szolgáltatások
Milyen támogatást nyújt hozzá a fejlesztőnk? Hányszor kérhetünk módosítást? Milyen gyakran áll rendelkezésünkre?
Hajlandó a fejlesztő segíteni abban, hogy megtanuljuk a rendszert, vagy arra törekszik, hogy mindenben teljesen tőle függjünk?
Megfelelő grafikai felülete (UI) lesz a rendszernek?
A rendszeres mentésről (backup) tud gondoskodni?
A fejlesztő személye
Milyen referenciái, tapasztalatai vannak a fejlesztőnek?
Figyelmes, a megrendelő igényeit figyelembe veszi, vagy a saját feje után megy?
Milyen kommunikációs képességei vannak? Ha nem kommunikál velünk folyamatosan és nem mutatja meg, hol tart, könnyen más irányba viheti a projektet, mint amerre mi szeretnénk.
Úgy látom, minél tapasztaltabb (min 5 év), annál jobb. Ha valaki kezdő, hiába olcsóbb, annyi hibát el fog követni, hogy a végén ugyanolyan árban lesz, mint a profi. + A tapasztalt adatbázis-készítő eleve úgy fogja elkészíteni az adatbázist (remélhetőleg), hogy rugalmas legyen, mert tudja, hogy az évek múltán változni fog az igény.
Bármi ötlet azzal kapcsolatban, mire érdemes egy ilyen projektnél odafigyelni?
Előre is köszönöm.
Hozzászólások
Úgy nagyjából mennyi pénz van a fejlesztésre és a fenntartásra? :)
Körülbelül 500 000 Ft.
Az kb 5 mérnöknap, se. Ennyiből azt kb felejtsd el, hogy válogatsz, meg teszteljen sok böngészőre, meg egyedi igényeid vannak, meg ilyesmi. Talán találsz valakit, aki valami szigorúan ingyen cmsből vagy adatbázis frontend konzervből összekalapál neked valamit, de ehhez is valami nagyon durván olcsósított faszit kéne kifogni.
És akkor arról még nem beszéltünk, hogy hol tervezet ezt futtatni, meg üzemeltetni.
Felejtsd el... komolyan... egy hozzáértő ember óránként kerül nagyon minimum extra kedvezményes áron nettó 6-8e forintba, kell egy ilyen léptékű feladathoz nagyjából 4-5 ilyen ember különböző részfeladatokra (üzemeltető, tesztelő, frontend, backend és adatbázis fejlesztő), leültök átbeszélni, hogy mit is kellene csinálni, az óránként 30-40 ezer forintba fog kerülni és még csak az elképzelést adjátok át. Számold ki, hogy mennyi idő alatt tudod részletesen előadni azt, hogy mit is akarsz és számold ki, hogy kitart-e addig ez a pénz, amíg beszélsz...
...és még szó se esett az üzemeltetésről (hardver, szoftver, üzemeltető) és a változáskezelésről.
Majd idosebb Ver Istvan elvallalja ne aggodj ;)
Mondjuk annyit hadd tegyek hozzá, hogy mi nem akarunk akkora adatbázist létrehozni, mint például az Österreichische Nationalbibliothek. A miénk a töredéke lenne.
Miért, az adatok betöltését is ebből a pénzből kellene valakinek megoldania?
Mit értesz ezalatt? Az adatok bevitelét? Őszintén szólva nem én vezetem a projektet, úgyhogy erre nem tudok válaszolni, de gondolom ha igen, akkor ez a pénz nagyon kevés lenne.
A fejlesztők csak egy keretrendszert adnak ahhoz, hogy fel tudjátok tölteni adattal. Jellemzően ez utóbbi legalább olyan melós, mint maga a fejlesztés, bár tény, hogy olcsóbb munkaerővel megoldható.
És a keretrendszer legalább 4x kerül refaktorálásra/újraírásra amíg a fenti példák töredéke megvalósul. Azért mert a fejlesztő még nem csinált ilyet, az ügyfél még nem kért ilyet, nekik is össze kell szokniuk...
A fejlesztés idejét és összetettségét kevéssé befolyásolja, hogy egyezer vagy egymillió bejegyzés van egy adatbázisban és az adatbázis mérete 10 MBájt vagy 10 GBájt, ezek nem azok a nagyságrendek, amelyeknél drágább és komplexebb módszerek kellenek...
...a fejlesztés idejét és költségét az adatstruktúra, az adatokon végzett műveletek és a felületek komplexitása befolyásolja érdemben, nem az adatok számossága: ugyanannyiba kerül kifejleszteni azt a szoftvert, amelyikbe egy bejegyzés kerül naponta és azt is, amelyikbe ezer.
Akkor a bruttó 15-30,000 Ft reális órabérnek tűnik?
Igen.
Eleg tag intervallum...
Csinaljatok meg egyetemi keretek kozott, szakmai gyakorlatkent. Ha mar kutatas...
Nagyobb cég esetén is a reális tartomány felső része, mert még a jobban fizető bank-biztosítás szektorban is meglepő az ezer eurós napidíj szoftver fejlesztésére. Ha egyfős cég kéri, akkor baromi sok erre a feladatra... vagy van valami erős kockázat, amit beáraztak. :)
Ahogy mondani szokás, innen szép nyerni.
Idézet innen: https://apps.google.com/intx/hu_hu/driveforwork/?utm_medium=et&utm_sour…
"A felhasználónként havi 8 euróért beszerezhető Google Drive for Work korlátlan tárhelyet kínál a fájlok, mappák, biztonsági mentések és minden fontos adat számára."
:)
Szerk.: Utólag talán érdemes részleteznem, hogy miért is írtam a fentieket, előrebocsátva, hogy a Google Drive használatában nem vagyok guru:
Van benne:
- tárhely, azaz nem kell külön infrastruktúra;
- van keresési funkció, amellyel például a PDF-eken belül is lehet keresni;
- van jogosultsági rendszer;
stb.
Hátrány például, hogy nincs tetszetős felülete és hogy fizetős. Az 500eFt 10 felhasználót számolva kb. csak 1.5 évre lenne elegendő.
________________________________________
https://sites.google.com/site/eutlantis/
> Az 500eFt 10 felhasználót számolva kb. csak 1.5 évre lenne elegendő.
Ha így nézzük, igazad van, de az 500e az egy alsó-középkategóriás fejlesztő nem egészen egyhavi bérköltsége.
Szerintem amíg ennyi pénz van csak a projektre, addig sehogy nem fog működni :)
Szerintem vedd fel a kapcsolatot az ELTE IK vagy BME IK-val (vagy más releváns fi-vel). Ők amúgy is azért vannak hogy kísérletezzenek nagyjából nulla pénzből. Ha valahol ráharapnak és adnak valakiknek érte egy-egy infós diplomát, akkor megvan kevés pénzből. Mondjuk akkor is kell valahová tenni a cuccot és tárhelyet meg hálózati sávszélességet ás áramot is fog fogyasztani.
az utóbbiak az elte infrastruktúrájában szintén megoldhatóak, ésszerű keretek között(= a nyakamat tenném rá, hogy biztosítanak a projektnek technikai hátteret is, és szvsz ugyanez igaz a bme-re is). szóval ez az út tűnik számomra eddig a legéletképesebbnek ekkora büdzsénél. speciel nekem volt adatbázisok és adatszerkezetek nevű órám, így bizonyára ilyen témakörben írt szakdoga, diploma is létezik arrafelé. ha kell kontakt, akár segítek ebben is (pm).
Köszönöm, de végül nem egyetemi keretek között gondolkodunk.
Ami most eszembe jut:
1. Licenszek, szoftverek. Lehetőleg GPL,LGPL, és nyílt forráskódú. Ez költségmegtakarítást jelenthet, és esetleg könyebben lehet szakembert találni a későbbiekben, ha a kiviteklezővel/üzemeltetővel elégedetlenek vagytok.
Amennyiben "pénzes" licenszelésű valamelyik szoftver, akkor a licenszdíj késedelmes fizetése ne okozza a szoftver leállását, azaz ne legyen időkorlátos.
2. A ráfordítható pénzmennyiség kb. 20%-ára nem szabad szerződni, a teljes rendszert a 80%-ból kell kihozni, ha kell "könyörtelen" alkudozással:-) A rendszer megvalósítása utáni használat során ugyanis általában kiderül, hogy valamit még jó lenne "belefejleszteni" a rendszerbe, vagy, rosszabb esetben, eleve másképpen kellett volna.
3. A leszerződött összeg kb. 10%-át jólteljesítési garanciaként, a szerződésben rögzítetten, csak több hónap sikeres üzemeltetés után szabad kifizetni. Nem az elvártaknak megfelelő működés, rossz rendelkezésre állás esetén a vállalkozó ezért a 10%-ért köteles a hibákat javítani. A garanciális időszak csak a hibák javításától számítódik.
4. A havi és éves üzemeltetési díjakat előzetesen meg kell becsülni, beleértve a licenszek költségét, a hardver cseréjét vagy a virtuális gép bérletét stb.-t.
5. A szerződést ütemezni kell, "mérföldköveket" kell meghatározni, és szigorúan jegyzőkönyvezni a megbeszéléseket.
________________________________________
https://sites.google.com/site/eutlantis/
Köszi.
És ha ők készítik a keretrendszert, azt lehet kérni, hogy nyílt forrású legyen, vagy ilyet nem szokás?
Amennyiben a vállalkozó egy saját maga által készített és sok projektben felhasznált, illetve felhasználni kívánt, és egy eleve nem nyílt keretrendszert használ a projektedhez, akkor nem valószínű, hogy nyílttá tenné.
Ha eleve egy nyílt keretrendszer "testreszabásával" hajtja végre a projektedet, akkor elég kikötni, hogy mindazt, ami a "testreszabást" jelenti (konfigurációs állományok, beállítások, template-k, szkriptek stb.) adja át nektek. És dokumentálja úgy, hogy magatok is elvégezhessétek az üzemeltetési feladatokat, ami persze nem zárja ki, hogy azt a fejlesztőre bízzátok.
Én ragaszkodnék ahhoz, hogy az alaprendszer nyílt legyen, hiszen az interneten többségében csak ilyennel találkozni, és ezek jól bevált megoldások.
Egyébként bármelyik alaprendszert el lehet rontani egy nem megfelelő testreszabással.
Más. A projekt első lépése az ún, funkcionális specifikáció, azaz a követelményjegyzék elkészítése legyen. Ebben a megrendelő megadja, hogy mik az elvárásai, például az adatbázis nagyságát illetően, de nem MB-ban, hanem oldalszámban; az egyidejűen kiszolgálandó felhasználók és keresések számára vonatkozóan stb. Ez alapján a vállakozó feladata meghatározni a szükséges erőforrásokat MB-ban, CPU-ban, RAM-ban stb-ben.
________________________________________
https://sites.google.com/site/eutlantis/
Amennyiben a vállalkozó egy saját maga által készített és sok projektben felhasznált, illetve felhasználni kívánt, és egy eleve nem nyílt keretrendszert használ a projektedhez, akkor nem valószínű, hogy nyílttá tenné.
Magyarul fennállhat a vendor lock-in esete a későbbiekben?
Pontosan.
________________________________________
https://sites.google.com/site/eutlantis/
Az kínos (lehet).
Vendor lock nincs erős relációban a fejlesztett szoftver keretrendszerének forrásszintű nyíltságával.
Azaz az igaz, hogy ha nyílt forráskódú a keretrendszer, akkor van esély bárkinek továbbfejleszteni az adott munkát, mert ha máshogy nem, akkor a forrás alapján képes a munkát kiterjeszteni.
Amit ti megkaptok, és a termék része (azaz nem az adatbázis motorról, keretrendszerről beszélünk, hanem arról ami nektek egyedileg készül) az szükségszerűen olyan formában érdemes átvenni ami továbbfejleszthető. Szerintem az összes komolyabb piaci résztvevő ezt neked így adja tovább. Azt elvárni, hogy a mögöttes szolgáltatásokat nyújtó több éves munka eredményeként létrejött keretrendszert is odaadja valaki nyílt forrásban nem ésszerű elvárás.
Azaz az a jó elvárás, hogy a nektek készített termék általatok módosítható legyen. Ehhez pedig nem a keretrendszer forráskódja, hanem a változtathatóság
módjának dokumentációja a leghasznosabb segédeszköz.
Természetesen itt az erős probléma, hogy nehéz olyan fejlesztőt találni aki a nem általa főleg használt rendszereken kívül is vállalna munkát, vagy legalábbis jelentős árkülönbség alakulhat ki azzal szemben mintha azt használhatna amit akar. Azaz gazdaságilag jobban megérheti az eredeti szállító használata. Ami sajnos nyílt forráskódnál is hasonlóan így lehet.
A piacon az a helyzet, hogy léteznek nyílt keretrendszerek, amelyekre sok vállalkozás szakosodott, ebből építkezik, széles felhasználású. Ilyenkor az adott keretrendszer evolúciója a legnagyobb kihívás. Ugyanis az adott végterméket mindig adott időpontban létező keretrendszerrel hozzák létre, és akik fejlesztik a termékedet a legkevesebb munkára törekednek a legjobb befektetett erőforrás befolyó pénz arányának elérése érdekében. Ami természetes, de ennek okán mivel a keretrendszer fejlesztése ilyenkor legkevésbé szokott a ti általatok kiválasztott fejlesztő privilégiuma lenni, a végtermék lehet, hogy a keretrendszer fejlesztésével szembemenően lesz fejlesztve, így az alatta lévő keretrendszer frissítése nehézkessé/lehetetlenné válik.
Ugyanekkora probléma az is, amikor az adott keretrendszert érdekmúlás miatt a fejlesztője abbahagy, és e módon ugyanúgy problémássá teszi a végterméket.
Itt gyakoribb az is, hogy a végterméked előállítója hagy fel a tevékenységével, és kénytelen vagy alternatívát keresni.
Ezzel szemben aki időt és energiát áldoz a saját keretrendszer megírásába és használatába, az egyrészt tudja mire és miért fejleszt. Nála szempont az esetleges továbbfejlesztésnek megfelelő kód előállítása. Valamint emiatt kisebb a valószínűsége hogy eldobná a befektetett munkáját és abbahagyná a szolgáltatást.
En nem ezzel foglalkoznek elsosorban.
Had idezzek valamit. "Nem tobb penzt akarok hanem valaszt a kerdeseimre pl kaphatnek tobb penzt?" :)
Kezdesz elveszni a kriteriahalmokban amit komoly projektek alapjan mindenki beirt de latszolag elsiklasz a sokak altal elso blikkre megallapitott problema felett megpedig hogy a penzmag amivel rendelkezdtek egy kozepes HTML oldal osszerakasahoz sem eleg te pedig egy egyedi ratok irt megoldast akarsz ugy hogy a fejleszto kezeben kb nem hagytok semmit mindent adjon at nektek gondolom mashol ne hasznalhassa fel de ne legyen sajat altala krealt megoldas mert az nektek nem jo de fizetni meg nem fogtok/akartok erte.
Ertsd jol az 500K amit kifizettek az valami vicc kategoria barmilyen Db projekthez ami architektet kivan es tulmutat az install mysql es egy create table megoldason...
Értem én. A pénzhalmok (bár ezt a hozzászólások alapján lehet, hogy túlzás "halomnak" nevezni) felett nem én állok, az árat pedig a kéréseink alapján a cég majd megadja, és akkor majd kiderül, mennyire alulszámoltuk. Ha pedig mégsem, akkor az gondolom a cégre és a minőségre nézve gyanús.
Aki ezt ennyiert vagy akar a duplajaert is elvallalja a kriteriumok alapjan amit irtal az nagy varazslo ---->
ami abban fog kimerulni hogy eltunteti a penzeteket.
You have been warned ;)
Még egy kérdés a jólteljesítési garancia kapcsán írod, hogy "csak több hónap sikeres üzemeltetés után szabad kifizetni". Hat hónap az megfelelő, vagy többet szokás?
Ez a rendszer bonyolultságától és a használattól függ, lehet 3 hónap, 6 vagy 12 is. Mindenképpen meg kell várni amíg a rendszer felhasználása intenzívvé válik és egy-két hónapig így üzemel, illetve az üzemeltetési feladatok, ciklusok többszöri végrehajtását.
________________________________________
https://sites.google.com/site/eutlantis/
Teljesen Off
Köszönöm ezt a linket http://hungaricana.hu/hu/
Találtam egy édesapámról szóló újsághírt.
Azok a linkek, amiket megadtál, azok minimum egy 0-val többe kerülnek!
Induljatok WIKI-vel, mariadb alapon.
Ebből az összegből a gépbérlés kijön nettel együtt és akkor még nincs rajta semmi.
-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház
Ez az ár a fejlesztést tartalmazza.
Akkor is molyfing összeg. Ennyiből még junior fejlesztővel is necces, nemhogy egy profival.
-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház
Mennyit tartanál reálisnak? Vagy nehéz ezt megsaccolni anélkül, hogy eléggé belelátnál?
A leiras alapjan ez egy oktato/kutato szervezet, ugyhogy nyilvanvaloan lesz gep, lesz net.
Így van.
sub.
Fuszenecker Róbert
Pontosítok, bár gondolom a legtöbben, akik keresték, megtalálták: az osztrák oldalnál a keresés innen indítható. Nekem egyébként ez az oldal tetszik a leginkább. Letisztult, átlátható, és kellő mennyiségű szűrővel finomíthatók a találatok.
Kerdezd meg esetleg a fenti szervezeteket, hogy kikkel csinaltattak, elegedettek-e, ajanljak-e oket.
Oke, ez eleg keves info, hogy szakmai kerdeseket tegyunk fel :)
Mit akartok csinalni?
Mi a cel?
Ha kesz az adatbazis, mit akartok csinalni benne / vele?
Amiket linkeltel, azok gyakorlatilag egy fulltext search db, ami kulonbozo media ojjekteket indexel, amiket valaki, valahol mar begepelt.
Gyakorlatban az lenne a lényege, hogy kutatásokhoz használható legyen, azaz ne kelljen feltétlen valakinek elmenni x és y könyvtárba, hanem a már feldolgozott/begépelt adatok alapján tudjon dolgozni a gépéről, akár otthonról. A legfontosabb tehát a kereshetőség (pl. a megfelelő szűrők).
Ergo lesz 630ezer konyv text-kent, es azokban akartok keresni?
Es hogy akartok keresni? "Muta osszes konyvet, aminek iroja baptista de kikeresztelkedett katolikusnak, ES legalabb harom konyveben elofordul pontosan ketszer ugyanazon az oldalon, hogy 'kozteher'"?
Definiald a "megfelelő szűrők"-et legyszi. Ez a legfontosabb :)
Szerintem kezditek rávezetni arra, hogy maga is rájöjjön, hogy az elképzelés jó (kell egy adatbázis), de a kritériumokon (ár, pontos feltételek megalkotása ...stb) még dolgozni kell.
-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház
Hát az ár az sajnos adott, ahogy latom, de a pontos igenyek egyaltalan nem.
Par dolog akkor meg gyorsan amik az elso kerdesek kozott lesznek:
Publikus lesz a db?
Mennyien fogjak hasznalni?
Hogyan visznek fel adatot?
Van e migralando rendszer vagy barmi amit indulaskent be kell tolteni? Ha igen akkor ez milyen rendszerben van tarolva?
Keresesi kriteriumokat el kellene kezdeni meghatarozni de ehhez kellene egy db architect emberke aki megerti hogy mit csinalnak az adatokkal illetve mik ezek az adatok amiket tarolni kell? (gyakorlatilag ez az elso legfontosabb szempont hogy ne legyen elbaszva az egesz mar kapasbol)
Aztan majd jonnek a finomsagok:
Egy lekerdezes eredmenye mekkora lehet majd es mi legyen az output?
Csak webes felulet lesz?
etc etc...
Igen, jogosak, de ezekhez is tudni kene, hogy mit akarnak keresni... Szavakat szamolni, vagy athallasokat keresni a szovegen belul? Lehet nem is egy konvencionalis kereso kell nekik valojaban, hanem valami bonyolultabb osszefuggeseket felismero algoritmus...
De erre a kerdesre meg mindig nincs valasz xd
na hat ezert irtam az architectet mert aztan a vege az lesz hogy persze osszeutjuk a db-t nem gond csak aztan vagy a tarolt adatok miatt vagy a produkalt output miatt lesz hasznalhatatlan vagy esetleg a ketto kombinacioja :D
Lefordul? Kesz!
Fejleszto e vagy? :D
Go Horse xd
Már nem is lesz szerintem mert a kérdező már elkönyvelte magában, hogy "Ezek itt csak trollkodnak, id. Vér Istvántól kaptam ajánlatot ő azt mondta ennyiből meg tudja csinálni, bár kicsit lassan, 1 hét alatt kész lesz."
-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház
:D
Ugyan már. Ritkán írok fórumba, de ettől független sokat olvasom, úgyhogy semmin se lepődök meg. :-)
A szűrési kifejezések nem nálam vannak, mert nem én vezetem a projektet, de azért megpróbálom körülírni. Például: szeretnék rákeresni a "földművelés" szóra az 1862 és 1865 közötti xy újságban.
Az idő egyszerű, mert amikor beszkennelitek, megadjátok az újság nevét, számát, idejét.
A "földművelés" szó, ha nem pont így kerül elő a szövegben, akkor ragozni is kell a magyar szót, szinonímát is keresni, nem?
Ez tisztára google books feeling. Én nem akarlak elkeseríteni de a projekt költségvetése, hogy a végén működjön és használható legyen, olyan 50MFt-nál kezdődik. És ezt teljesen reálisan írom: 4-5 ember, 2év, plusz a cuccok (könyvszkennelő gépek, digitális kamerák, etc).
A magyar nyelvvel meg fogtok szenvedni.
500eFt konkrétan semmire se elég. Tényleg.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Igen, de a kutatási téma miatt limitált az anyag, amit fel kell dolgozni, tehát nem nagy mennyiségről van szó.
Mennyi?
Az indulás kb. 12-13000 bejegyzés (színházi lapok adatairól van szó), de ez később még bővülni fog. Ezek egy (kis) része már plain text formában be van írva a gépbe, csak át kell tenni az adatbázisba.
Írtam korábban (http://hup.hu/node/147234#comment-1985575), hogy nem a bejegyzések száma határozza meg a fejlesztés és az üzemeltetés költségét, hanem az adatstruktúra, az adatokon végzett műveletek és a felületek komplexitása befolyásolja érdemben: ugyanannyiba kerül kifejleszteni azt a szoftvert, amelyikbe egy bejegyzés kerül naponta és azt is, amelyikbe ezer.
[Feliratkozás]
Egy google books szintu projekt 500e-ert? Kettot kerek!
Egyebkent *csak* a konyvszkennelo gep, ami tisztan opensource,
lenyegeben a fejlesztes koltseget nem is kell kifizetned,
pusztan a gyartas koltseget, tobb mint 500eFt:
http://www.diybookscanner.org/archivist/
Es ezt nem egy ember csinalta, es 6 evig...
En nem tudom milyen fizetes van nalatok, de gondolom az 500eFt a a szamla vegosszege, ami netto 394eFt. Abbol kell fizetni a cegnek az emberunket,
tegyuk fel, hoyg senkinek se kell a cegen a fejleszton kivul dolgoznia rajta (teljesen elkepzelhetetlen), es a munkabol nem kell a konyvelot, irodat, fix alkalmazottakat se fizetni (akiket csak a munkakbol kellene kitermelni), ha mindent elhanyagolunk (wtf?), akkor is a fejleszto ebbol tisztan olyan 280eFt-ot vihet haza.
Ertelmes opensource OCR keretrendszer nincs is.
Valami opensource alapon megcsinalt OCR lenne olyan jo egy ev.
Egy atlagos ember orankent 400 lapot tud beszkennelni (es utana azzal meg utomunka is van), hany munkaora lenne ezt az adatbazist feltolteni?
Megvannak a szerzoi jogok hozza?
En ertem, hogy a google-t is emberek irjak .... :)
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Nem Google Books szintű projekt. Annál kisebb. :-)
Az adattárolási szoftver minősége (mennyire rugalmas a DB, milyen a struktúrája stb) az független az adatmennyiségtől.
Az, hogy kevesebb dolgot kell feldolgoznotok, mint a Google Books, nem teszi egyszerűbbé a munkát, csak épp kevesebb hardver kell.
Jogos, erre utalt _Franko_ is most megint (ld. itt).
Ez egy iszonyatosan nagy projekt, a DB tervezése talán belefér a költségkeretetek 5-10x-osába :(
Hogy konstruktiv is legyek, en magamnak igy csinaltam
(bar nem konyveket szkenneltem, de a lenyeg,
hogy digitalizalom az osszes papiromat, szamlakat, szerzodeseket, etc.)
Az 500eFt-bol ha konyvet kell szkennelnetek, vegyetek meg a "The Archivist" szkennelogepet. Ez 1700USD+szallitas+vam+afa, hogyha jol lattam.
Egy halozati megosztasba tegyetek be a konyveket, nagyjabol igy:
- minden konyvtar egy url lesz (majdan, most nem).
- egy konyvtar egy konyv
- az osszes raw anyag (szkennelt .pdf, jpg, etc) egy fix nevu konyvtarban van benne a konyvtaron belul (nalam 'rsc/')
- a leiras, elonezet, miegyeb az egy wiki szeru fajlban van (nalam: index.md, markdown-nal)
- a konyv ocr eredmenye is az rsc/ -ben van benne.
A kereses egy full text search az osszes fajlban.
Amig ilyen 5000 konyvtar alatt vagy, addig teljesen vallalhato.
En a sajat rendszeremet 2 eve irom. Volt hogy felvettem embert (eket), es tobben irtuk. Termeszetesen lenyegesen tobb, mint egy halozati megosztas.
De nektek kb. jelenleg erre van penzetek (egy halozati megosztas beallitasara, egy konyvszkennelo gep megvasarlasara).
Minden evben tervezzetek be kb. 500eFt-ot, es egy jol meghatarozott reszfeladatot programoztassatok le (pl. egy webszerver kezelje a halozati megosztast egyik evben).
Tartsatok a szemeteket a palyan, hogy milyen opensource megoldasok kerulnek elo, es egyik evben egy ilyen beepitese lehet a cel.
Elobb nyugdijba megy az egesz reszleg imho, minthogy ebbol igazan mukodo valami legyen.
A masik lehetoseg, hogy felvesztek egy programozot (kb. br. 6-900eFt/ho)
aztan tart ameddig tart... :)
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
A kereses egy full text search az osszes fajlban.
Amig ilyen 5000 konyvtar alatt vagy, addig teljesen vallalhato.
Miert nem toltod fel a text kivonatot adatbazisba es tolod azon a keresest?
Hatekonyabb fileokat nyitogatni es azokban keresni?
En meg mindig az 500eFt keretosszegen vagyok megakadva. Abba nem fer bele adatbazis.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
"En meg mindig az 500eFt keretosszegen vagyok megakadva. Abba nem fer bele adatbazis."
Ez miben növelné a költségeket? http://lucene.apache.org/solr/features.html
Es ki allitja be? Mennyiert?
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Egyrészt: "En a sajat rendszeremet 2 eve irom. Volt hogy felvettem embert (eket), es tobben irtuk."
Másrészt nem űrtechnika, fel kell telepíteni és REST interfészen beszélni... nem bonyolultabb, mint fájlokban a full text search és tud sokféle összefüggés alapján keresni.
Amit en irok, az nem is a fenti feladat:)
Egy kereses laptopon inditva mc-bol nem mukodik rosszul. Es az se erdekelne, hogyha nem 10sec lenne a kereses, hanem 16 ora. Van ugy, hogy valamit mindenkeppen meg kell talalni.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Noh. Teljesen megoli az akksiidot a laptopon.
En inkabb mongodb helyett is file-based adatbazist hasznalok laptopon (tingodb).
Teljesen vallalhato.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Az ember a drága. Bruttó 500E ft nevetséges összeg egy ilyen fejlesztésre, te is tudod.
Mi kódexek kutatásához saját engine-t fejlesztünk. Ott mondjuk hangsúlyosabb a kutatás szó, ezért kell a saját.
eprints
Megpróbálok konstruktív lenni én is, hátha segít. :) Márcsak azért is, mert látszik, hogy legalább gondolkodsz azon, higy mit kéne kérdezni, viszont akivel beszéltél, az kicsit szerintem elvitt az erdőbe, először azzal, hogy magyarázott neked mindenféle adatbázis kezelőről, másrészt azzal, hogy valószínű frontendes volt (a működik-e számos böngészőn meg ilyesmikből következtetve) viszont az itt csak a jéghegy csúcsa, a technológia meg legyen alapvetően annak a baja, aki csinálja, neked kb mindegy.
Igazából az van, hogy ahogy nézem, neked most még nem azt kellene kitalálni, hogy mit kérdezz a fejlesztőtől, hanem hogy megértsd, hogy mire is van igazából szükséged, uh ennek menjünk neki kicsit. Egyébként is két dolog lehet: vagy értelmes infossal hoz össze a sors, és ugyanezeket fogja kérdezni, akkor nem baj, ha már gondolkodtál, vagy valami kóklerral, aki megcsinálja azt, amit sikerült előadnod, és leszarja, hogy használhatatlan lesz.
Szóval, amit tudunk, hogy néhány tízezres nagyságrendben akartok színházi lapokat kereshetővé tenni. Gondolkodnivalók:
1) Hogy kerülnek ezek feldolgozásra? Ez is a megoldandó feladat része, vagy ezt ti csináljátok valahogyan? Esetleg részben?
1.1) Kell-e szállítani valamit a digitalizáláshoz? Hardwaret / szoftvert. Ha nem, akkor hogyan lesznek elérhetőek az általatok digitalizált források? Ha igen, akkor hol vannak a források (pl kijöhetnek-e onnan), mennyire érzékenyek, sérülékenyek, milyen ütemben kell feldolgozni, mennyi ember van hozzá, ilyesmi.
1.2) Adatfeldolgozás: feladat-e valamilyen automata adatfeldolgozás? Kell-e pl hogy a rendszer szövegfelismerjen ezekről a lapokról? Ha igen, milyen nyelven vannak pl? Jellemzőek-e a csicsás dolgok, vagy sima nyomtatott szöveg? Esetleg kézzel írott? Kell a tartalmat elemezni (mondjuk felismerni, hogy az impresszumon a név az egy szerző, vagy a jobb fenti sarokban a színház neve szerepel. Esetleg van-e valami plusz feldolgozandó? Mittomén, valami könyvtári leltár, amin további extra adatok vannak, pl, év, készítő, ilyesmi, amik magán az anyagon nincsenek rajta. Vagy minden fontos adatot (amit később keresni akartok) feldolgozásnál kézzel berögzít valaki?
2) Adatrögzítés. Hogy kerülnek be az adatok a rendszerbe? Arra is kell felületet adni? Ha igen, kik, honnan, és hogyan használják? Sok dolgot tesznek be egyszerrre? Esetleg az általatok már digitalizált dolgokat kell automatán elhozni? Honnan? Milyen technológiával lehet hozzáférni? Milyen gyakran kell / honnan lehet tudni, hogy van új adat?
3) Kereshető adatok: ezt már karcolgattuk feljebb, de mivel hangsúlyozod, hogy nektek a kereshetőség fontos, érdemes ezen külön gondolkodni, ugyanis, hogy milyen szűrők vannak, az alapvetően azon múlik, hogy mennyire van jól meghatározva, hogy miben kell keresni. Elég valami fullstack search, vagy vannak kiemelt típusú adatok? Mondjuk évszámok, színház neve, szereplők, rendezők, címek, nem tudom, amit nevesítve kell tudni keresni? Ezek milyen összefüggésben állnak önmagukkal? Pl évszám tól-ig? Vannak valami kategóriák, mondjuk egy színházcsoport, vagy mondjuk stílusok továbbbontva valami fastruktúrába? Hogyan függenek össze egymással, milyen relációk lehetnek köztük? (és ezek mind visszakanyarodnak a kettesre is: ki, és hogyan fogja ezeket rögzíteni, mit kell belőle a rendszernek kitalálni?) Hogyan használják a megtalált adatokat? Kell nekik valami export? Van szükség valamilyen összesített kimutatásra, statisztikára?
4) Felhasználók: ki ők? Hányan vannak? Hol vannak? Milyen eszközön használják? Mennyire rutinos számítógép használók? Kell-e őket okatatni, és ha igen, mire? Tudnak érdemben beszélni a munkájukról mert már most is csinálják, és az ő életük megkönnyítése a feladat, vagy majd csak azután jelennek meg, miután ez kész van, és majd a szakmai részt is oktatni fogjátok nekik?
5) Munkafolyamatok (felület): a felhasználók mit csinálnak? Csak keresnek? Rögzítenek is? Van még valaki a munkafolyamatban? Pl van-e olyan, aki már a rendszerben nézi a nyers képet, és pötyögi hozzá az adatokat ott? Vannak jogosultsági dolgok? (Ki mihez férhet hozzá?) Van valami fizetős dolog?
6) Üzemeltetés: hol lesz? Ki fogja üzemeltetni? Ez is része a feladatnak később, vagy majd ti? Van hozzáértő csapatotok? Vannak preferenciák, megkötések (pl windows / linux infrastruktúrátok van, azon kéne futni, nem értenek a másikhoz, ilyesmi)? Lehet-e olyan elem a renszerben, aminek pl éves licenszköltsége van? Ha ez is a feladat része, akkor nálatok kell-e üzemeltetni, vagy megoldhatja, aki csinálja, ahogy akarja (és persze ennek is vannak szintjei, milyen elvárásaitok vannak)
7) Oktatás: kinek, mennyit kell okatni?
8) Jövő: milyen hosszan kell ennek működni? Mikortól kell már csak "életben tartani", meddig tart az aktív munka?
Na, ha ezek kb megvannak, akkor majd el lehet kezdeni gondolkodni azon, hogy milyen ütemezésben szeretnétek csinálni, hogyan fogtok munkát ellenőrizni, mikor, mennyit fizettek, mihez kötitek, hogy fizettek? Hogyan akartok belefolyni a munkába, milyen gyakran akarjátok látni, hogyan fogjátok kezelni a változás kéréseket? (Mert azok lesznek). Milyen határidők vannak? Úgy képzelitek, hogy előtte részletesen megtervezitek, kész lesz, és lehetőleg utána 10 évig elketyeg, vagy inkább indulnátok valamivel, ami a legégetőbbeket megoldja most, és hogy igazából mi kell, az majd közben alakul, és szépen mindig megbeszélitek, hogy most mi jön, az mikorra kell, és mennyiért? Hogy képzelitek a supportot? Kell folyamatosan, esetileg, esetleg egyáltalán nem?
--
Na itt most abbahagyom, mert kissé sűrű így, hogy sok lehetőség van benne feszegetve :)
Köszönöm a részletes tanácsokat, felhasználom őket, ahogy tervezzük a projektet.
talan valami hasonlo?
http://lucene.apache.org/solr/
mgb
A kezdő hozzászólás (sajnos a megszokott módon) olyan távol van a a tiszta igényrendszertől, hogy még csapongó gondolatnak sem lehet szinte tekinteni. Nevezzük ötletnek. Példának okáért keveri a tervezés megvalósítás és az üzemeltetés fogalmát. Folyamatosan rossz terminusokat használ, sejtetve hogy a mögötte lévő tartalom nem biztos.
A fenti nem kritika akar lenni, bármennyire látszik is annak, hanem segítség.
Innen több út van, az egyik az, hogy felkértek valakit aki az igényeiteket lefordítja, kiteljesíti, és abból megvalósítható tervet csinál.
Vagy direktben ezt a kiválasztott megvalósítótól kéritek (jobban jártok olyannal aki ezért külön pénzt is kér, mivel már tudja miről beszél)
A harmadik út, a kész megoldás választása, és az igényeitek hozzáigazítása, akár az általad említett alternatívákkal, vagy az általad nem ismert alternatívákkal.
Ha egyetemen vagytok, nem lehetne a témát előadni mint szakdolgozat/diplomamunka feladatot?
Végül nem egyetemi keretek között valósítjuk meg.
Bár ez is inkább egyetemi alapú, elsőre inkább elrettentő, de hátha ad ötletet: http://magyar-irodalom.elte.hu/repertorium/dokument/index.html
Esetleg az ottaniakkal ha felveszitek a kapcsolatot, adhatnak tippet, kontaktot stb.
Maga az elv, hogy inkább metaadatokra lőnek - ld. még OAI-PMH - elgondolkodtató - csak nálatok nem elég. Tipp: könyvtári rendszereket fejlesztők talán láttak már hasonló igényt.
Hello,
Nem tudom menyit kerestél a neten a témában én rövid keresés után ezt a két rendszert ajánlom. (Az egyikkel készült arhivumot használtam, egész jó volt)
http://www.veridiansoftware.com/ => Nagy demó oldal: http://cdnc.ucr.edu/cgi-bin/cdnc
http://www.pressmart.com/earchive/
---...---
TLoF
Köszönöm, de végül olyan egyedi igényeink vannak (több oldalas dokumentumban írtuk végül le), amelyhez egyedi rendszer szükséges. Úgy tűnik, sikerült megtalálnunk az emberünket.
Kevés derült ki a feladatról de nem lehetséges, hogy ezzel is lefedhetőek az igények?
Drupal + biblio module
https://www.drupal.org/project/biblio
(Sok óra menne el erre is ha nem ismered legalább az alapjait mert sokat tud, elég összetett.)
Ugyanaz a válaszom, mint fentebb: Köszi a javaslatot, de olyan egyedi igényeink vannak (több oldalas dokumentumban írtuk végül le), amelyhez egyedi rendszert szükséges fejleszteni.
Nem javaslat volt, csak felvetés.
Azt el szabad árulnod, hogy milyen úton sikerült embert találni?
Mi is keresünk. Pontosabban segítenék valakinek keresni.
Egy ismerős ismerőse. Mondjuk ez nem azt jelenti, hogy rossz, ugyanis tudtommal ezzel kapcsolatos tárgyat tanít egy budapesti egyetemen.
Hogy konstruktív legyek: a kérésed a piacon jelenleg PHP alapon kb 20 millió körül van pénzmosás nélkül (azaz ennyiért vállalja be ténylegesen egy fejlesztőcég)
Technológiától és bátorságtól függően ez 15-40 millió is lehet.
Egy fejlesztő havonta egymillió körül van (hiperbruttó, ha olcsóbbak akkor ezen már van irodaköltség is, haszon az nem sok), ez 5 fejlesztő 4 hónapig.
Profi, oktatásos, mindenes meló az inkább a 40-50...
Szóval piaci alapon itt két nullával számoltátok el a dolgot.
Régen, pl. az UTCA könyvtárprojekt esetében még voltak lelkesedésből ilyet áron alul bevállaló csapatok, de a braindrain erősen érintette azóta az országot és a kereslet is exponenciálisan nő, azaz senkinek nincs ideje hobbiból kevesebbért csinálni dolgokat.
Sorry.