[API] [Isvu-koordinator] muke po isvu - obada podataka

Gjuro Kladaric gjuro at ffzg.hr
Mon Nov 3 22:30:31 CET 2014


"U biti, možda pisanje SQL upita i nebi bilo lakše, jer je veliko pitanje i kako izgleda ISVU baza... Vjerojatno ima stotine, ako ne i tisuće tablica i mislim da bi se dobro namučili razumjeti na koji način su podaci povezani (u biti - to govorim u svoje ime, ne želim nikoga podcjenjivati)."

 

kolega, vi mora da se salite  :-)))

 

ja da bih se namucio da razumijem na koji nacin su podaci povezani???  
zelite li reci da bih se manje namucio da te iste podatke razumijem ako ih skinem kroz ISVU rest api i dobijem u obliku gomile xml-ova?  da, znam, imao bih puno vremena za kontemplaciju o smislu podataka dok cekam satima da prikupim te podatke jedan po jedan

 

bilo bi mi teze pisanje SQL upita nego ove trakavice s rucnim skidanjem podataka pa preoblikovavanjem pa procesiranjem???  
napisao sam dovoljno (desetaka tisuca) linija produkcijskog programskog koda i SQL-a da se ne bojim nicega takvoga...  a i da nije tako, ocekujete li da bi mi bilo lakse upravljati istim podacima koji se daju dohvatiti kroz rest api u XML obliku i koji cesto sadrze kojekakve denormalizirane restlove koje nisam trazio (koji, naravno, trose i procesnu moc servera i propusnu moc mreze i onda opet procesnu moc klijenta)?  zasto bi to bilo lakse od tamo nekakvog SQL upitnog jezika u kojem je sve jednostavno i bas onako kako majstor zeli?

 

da vidimo, koliko nam tablica pada na pamet, ovako s nogu:

 

-          osobe u sustavu (studenti, nastavnici, sluzbenici itd)

-          fakulteti (tj. VU) - za slucaj da imamo nekog studenta koji je nas a dobio je JMBAG na nekom drugom faksu

-          studiji

-          smjerovi

-          akademske godine

-          upisi u akademske godine (upisni list)

-          predmeti

-          grupe izbornih predmeta

-          upisani predmet na upisnom listu

-          ispitni rok

-          upisani predmet na ispitnom roku

-          ispit

-          ustrojstvene jedinice

-          prijave ispita

-          priznati ispiti

-          ekvivalentni kolegiji

-          preduvjeti

-          dozvole osobi za predmet

-          izvodjaci na predmetu

-          studentov dipl. rad, mentor i tema te podaci o obrani rada

-          izracun za participaciju

-          boravak studenta izvan VU

-          prekid studija

-          sudenti koji su zavrsili studij

-          i svi opci katalozi (gradovi, drzave, vrste nastave...)

 

za ovaj drugi, crni dio popisa tablica sam koristio koordinatoricu za ISVU, ali drzim da to nije problem jer istu nju moram koristiti da mi objasni veze medju podacima i kad podatke dobijem kroz ISVU rest api i u xml obliku - razlika u nacinu dohvata i formatu podataka je samo tehnicka a podaci i njihovi odnosi su isti u oba slucaja

 

sigurno sam zaboravio ponesto, pa na ovo treba dodati jos recimo 50% tablica s bitnim podacima, plus jos 100% tablica za many-to-many odnose medju stavkama u tim tablicama

 

ali - to je to, ispod 100 tablica

 

stotinu SELECTova?  da, znam, treba ih odrzavati kad se promijeni nesto bitno u strukturi baze, ali - je li to problem?  

koliko cesto se nesto radikalno mijenja u ISVU bazi u temeljnim podacima, tako da postojeci SELECTOVI vise ne bi radili? uglavnom nikad, pretpostavljam (jer onda ni glavnina ISVU sustava vise ne bi radila)...  

ali, ako zelimo da ti SELECTOVI zahvate i podatke iz novododanih polja iz baze? je li problem odrzavati 100 SELECTova?  hajde, netrivijalnih, ali zar je to izazov za takvu ekipu?

 

sto je tu komplicirano?  osim onoga sto jest komplicirano, ali to je komplicirano na isti nacin i kad podatke dobijemo kroz rest api?

 

sto je lose u tome da ISVU ekipa napravi takav dump za sve koji ga zele, jednom, centralizirano, nocu, na jednom mjestu, iz dana u dan, tako da budu *konzistentni*!!! i da budu FTP-om dostupni na klik svakom koordinatoru (ni ISVU aplikacije ni HTTP aplikacije nisu podobne za skidanje velike kolicine podataka), umjesto da se svaki od nas dovija radeci neki aplikacijski sustav koji ***nuzno*** daje nekompletne podatke i to nakon mnogo sati cekanja (uz realnu opasnost da moramo ponoviti tih mnogo sati cekanja ako krivo zahvatimo podatke pa ih treba dohvatiti nekako drukcije) i jos nekonzistentne?

 

ili, alternativno, zasto ISVU ekipa ne napravi jednom aplikacijski sustav koji ce kod svakoga od nas replicirati gorespomenuti skup podataka i stalno azurirati neku bazu (bio to mysql ili mssql) na nasem lokalnom serveru, pa da mi to onda mozemo koristiti - tako bi se trud na izgradnji takvog sustava utrosio samo jednom (kod ISVU ekipe) a mi bismo mogli koristiti sve to

 

znam, onda bi oni shvatili da ISVU rest api ne pruza ni priblizno dovoljno podataka da bi se mogle rekonstruirati sve potrebne tablice, a i shvatili bi koliko to traje, a i shvatili bi da bi onda imali problem s konzistencijom baze

 

no, nama bi i to, kad bi funkcioniralo kako tako, bilo prihvatljivo

 

nazalost, nista od toga ne dobivamo, a ISVU ekipa misli, cini se, da je ozbiljan pristup da svatko od nas pravi svoje rjesenje za skidanje podataka sa ISVU servera...  trebam li to ne nazvati smijesnim?  ne mogu, tako i ako bih trebao...

 

a podaci su formalno i deklarativno nasi, samo nam ne daju do njih

 

slutim da bi voljni majstori s ISVU strane znali, u dogovoru s nama s ove strane, rijesiti sve te probleme

 

ali, iz meni nejasnih razloga, nisu voljni, na zalost

 

a nas zahtjev je sasvim jednostavan: dajte nam nase podatke, kompletne, konzistentne, redovito i to sve odmah pa onda dalje svaki dan kad koordinator negdje klikne DOBAVI SVE ISVU PODATKE, SAD ILI NAJKASNIJE SUTRA

 

 

a sada slusam, zasto bi mi bilo vise komplicirano shvatiti veze medju podacima kad su u bazi nego kad su u gomili xml-ova?  ili pisati SQL upite (a prava baza i pravi SQL su zapravo jedini pravi alat za to :-))))?

 

i kazete, medju ostalim: postoje izvjestajni sustavi...  da, ali kolegica kaze da ne moze dobiti izvjestaj duzi od 5.000 redaka, a popis nasih upisanih predmeta ima 500.000 redaka...  vidite problem?


u tom detalju sustav je neprimjeren ***sto PUTA***, ovako kako nam je dostupan

 

eto, zeljno cekam odgovor, mozda mi se prosire vidici,

 

srdacno,

 

gjuro kladaric

 

voditelj informatike

 

ffzg.hr

 

 

 

 

From: Marko Ivančić [mailto:ivancic at sfzg.hr] 
Sent: Monday, November 3, 2014 9:23 AM
To: Gjuro Kladaric
Cc: Ivana Sudarevic; api at isvu.hr <mailto:api at isvu.hr> ; isvu-koordinator
Subject: Re: [API] [Isvu-koordinator] muke po isvu - obada podataka

 

Hm... ne mogu se složiti da je REST API smiješan... Dapače, kad se sjetim kako FER nije dao niti pomisliti na otvaranje ISVUa - REST API je "puna šaka brade". Stvar je lijepo dokumentirana, a vjerujem da će otvaranjem novih resursa biti i još funkcionalnija. 

Vjerujem da ISVU tim ima dobre razloge zašto ne reagira na dump baze, a možda je jedan od njih i onaj "to se tako baš i ne radi...". 

Zato postoje APIji, izvještajni sustavi... Možda bi i meni pisanje SQL upita bilo lakše, ali rađe bih podržao dodatan napor da se popravi/poboljša izvještajni sustav i API. U biti, možda pisanje SQL upita i nebi bilo lakše, jer je veliko pitanje i kako izgleda ISVU baza... Vjerojatno ima stotine, ako ne i tisuće tablica i mislim da bi se dobro namučili razumjeti na koji način su podaci povezani (u biti - to govorim u svoje ime, ne želim nikoga podcjenjivati).

 

Fora je u tome što postoje ljudi koji uspješno koriste API. Vjerojatno je već dosta fakulteta napravilo skripte koje generiraju izvještaje, a koji sada možda baš i vama trebaju... Ja bih rađe pozvao sve koji uspješno rade sa APIjem da podijele svoja iskustva i svoj kod svima na korištenje, po otvorenoj licenci. Znam da je to mala utopija, ali možda ima hrabrih i buntovnih :)... Možda pomoću alata za kolaboraciju, možda preko wikija, možda preko repozitorija, možda nekako drugačije, ne znam... Počevši od primjera same organizacije koda, primjera spajanja na REST API, pravilnog korištenja, kombiniranja resursa, pa i samih funkcionalnih izvještaja i slično. Ako bi netko započeo, netko drugi bi mogao doprinijeti sa nekim svojim izvještajem i slično. Kod bi trebalo dobro dokumentirati, da ga svi mogu razumijeti (tako da i učilištima koja nisu informatička, kao što je Nenad napomenuo, možda bude malo lakše)... Možda bi SRCE to podržalo, možda i po onoj svojoj inicijativi za otvorenim pristupom znanju, obrazovnim sadržajima ili kako se već zove. Možda, možda bi se iz toga mogla izroditi funkcionalna aplikacija na kojoj bi radilo više ljudi. Sada je svatko prepušten sebi. U vremenima kada se novčani resursi fakultetima krešu (pa i SRCEu), možda je to jedan od načina da si sami pomognemo...

 

Lp

 

2014-11-01 15:37 GMT+01:00 Gjuro Kladaric <gjuro at ffzg.hr <mailto:gjuro at ffzg.hr> >:

pozdrav,

hvala na suosjecanju

podaci su se promijenili naprosto zato sto je skup podataka u ISVU-u ziva stvar i mijenja se iz
minute u minutu, vec kako neki student nesto polozi, pa se to odnosi i na prosjeke nekih studenata
koji su upisali studij ili pojedini kolegij nekih prijasnjih godina (ovisno o zahtjevu za
informacijom uprave)

uzmes podatke u ponedjeljak, pa onda u srijedu, i ta dva skupa podataka pokusavas spojiti po nekom
zajednickom podatku i - svari su gotovo iste, ali se se malcice promijenile (na pola milijuna
kolegija promjena ima par desetaka ili par stotina)...   i kako ces ona pomiriti te nejednake
skupove podataka?

sumnjam da se pronaci neko rjesenje jer isvu ekipa ne zeli razgovarati ni o cemu osim o smijesnom
pikanju podataka kroz rest api

a jedino suvislo rjesenje je u ponoc zaustaviti sve i napraviti sliku baze u tom trenutku pa onda
te podatke koristiti kao konzistentan skup podataka, natocen u neku neprodukcijsku, readonly bazu
koju onda mozemo napadati sikvelom kako bog zapovijeda i cemu milijuni redaka onda nisu problem
niti traju vise od par sekundi

dakle, dump baze u nekom konzistentnom trenutku (naravno, svakome njegov
zbog-privatnosti-podataka-obranicen podskup od svih podataka u ISVU bazi) i onda koristenje po
zelji

to sto nasa uprava zeli je rjesivo, iako cesto trazi vremena i truda, ali to sto ISVU ekipa ne
zeli razgovarati o tome - to me vise boli :-)

i - nerjesivo je...

srdacno,

gjuro kladaric

voditelj informatike

ffzg.hr <http://ffzg.hr> 


> Bok,
>
> javljam se Ä isto zato jer smo i mi na StomatoloĹĄkom fakultetu u Zg takoÄ er
> u postupku reakreditacije. Mi imamo puno manje studenata (650 do 700), pa
> nekakvi naĹĄi veÄ i ISVU upiti traju maksimalno pola sata... No, ono ĹĄto mi
> je zapelo za oko u tvom tekstu (pardon ako sam krivo razumio) - naknandno
> ste skuĹžili da je doĹĄlo do promjena u ocjenama i upisanim predmetima sada u
> roku jednog dana - za neke proĹĄle ak. god? Mi za akreditaciju takoÄ er
> radimo nad zadnjih pet ak. godina (zakljuÄ no sa 2013./14. ak. god.) i nebi
> mi palo napamet da provjerim dali je nekom studentu dodan neki predmet ili
> ocjena za proĹĄlu ak. god., i to sada u 2014./15. ak. god. u roku jednog
> dana... U principu ne znam kako vi inaÄ e radite ili kako se na drugim
> fakultetima radi (mislim na upise u novu ak. god.), ali sada je veÄ  11.
> mjesec i mi smatramo da je naĹĄe stanje sa svim proĹĄlim ak. god. - Ä isto.
>
> No, u principu razumijem ĹĄto ste htjeli reÄ i - htjeli biste imati spreman
> upit, ne zamarajuÄ i se pitanjem dali je neĹĄto mijenjano. Ja na SFZG ne mogu
> reÄ i da mi treba dump baze, ali moĹžda bi drugaÄ ije razmiĹĄljao da imamo
> toliko studenata kao i vi, ne znam...
> SuosjeÄ am za vaĹĄe probleme i nadam se da Ä ete uskoro pronaÄ i rjeĹĄenje! Znam
> da se muÄ ite i da uprava misli da je to sve jednostavno...

>
> Lp
>
> Marko
>
> 2014-10-31 15:05 GMT+01:00 Ivana Sudarevic <isudarev at ffzg.hr <mailto:isudarev at ffzg.hr> >:
>
>> pozdrav svima,
>>
>>
>>
>> filozofski fakultet u zagrebu trenutno prolazi postupak reakreditacije
>> koji provodi agencija za znanost i visoko obrazovanje te se spremamo
>> primiti strucno povjerenstvo
>>
>>
>>
>> njih, izmedju ostaloga, zanimaju podaci o studijima i studentima za prvih
>> pet generacija bolonjskih studija (osvojene bodove po nekim kriterijima za
>> pojedinu generaciju studenata, prosjek na studiju i sl.) sto se vodi u ISVU
>>
>>
>>
>> buduci da studente u ISVU ne vodimo od 2005/06. nego tek od 2007/08.,
>> odlucili smo obraditi podatke za sve generacije od 2007/08. do 2013/14. te
>> ih prezentirati povjerenstvu
>>
>>
>>
>> ovu smo obradu vec radili prije par mjeseci (i tada nam je trebalo dva
>> tjedna da iznjedrimo konacne tablice), ali kako je posjet povjerenstva
>> odgodjen i umjesto u srpnju dogodit ce se u studenome, Uprava je pozeljela
>> da osvjezimo podatke te da povjerenstvu predocimo i pomake koji su se
>> dogodili s tim podacima u zadnjih nekoliko mjeseci
>>
>>
>>
>> dakle, tijekom prvog postupka obrade tih podataka iz ISVU-a nisam
>> metodicki biljezila postupak, ali sada jesam pa imam zelju i potrebu da
>> svima prikazem s kakvim smo se problemima susreli
>>
>>
>>
>> nadam se da cu ponukati sve koji se prepoznaju u tim mukama da podupru nas
>> zahtjev centru potpore da nama (ali i svima kojima to treba) omoguce 'dump
>> baze'
>>
>>
>>
>>
>>
>> za obradu su mi bili potrebni sljedeci podaci:
>>
>>
>>

>> ¡         sifra upisnog lista ILI jmbag/paralelni studij/akademska godina
>>
>> ¡         akademska godina upisa na studij
>>
>> ¡         upisani ESS
>>
>> ¡         predmeti na ESS
>>
>> ¡         ECTS predmeta
>>
>> ¡         status predmeta
>>
>> ¡         ocjene
>>
>> ¡         osvojeni ECTS na ESS
>>
>> ¡         ulazi li predmet u prosjek

>>
>>
>>
>> to je u brojkama: nesto preko 9000 studenata i preko 30 000 upisnih listova
>>
>>
>>
>> podatke sam odlucila preuzeti preko REST APIja jer za toliku kolicinu
>> podataka ne postoji dobar nacin preuzimanja iz aplikacije
>>
>>
>>
>> izrada izvjestaja iz aplikacije traje satima zbog cega najcesce pukne veza
>> s bazom
>>
>>
>>
>> mamila me pomisao da pokusam smanjiti opseg izvjestaja iz aplikacije tako
>> da umjesto xml-a odaberem excel ravni izvjestaj koji dopusta selekciju
>> podataka pa bih mogla preuzeti samo one podatke koji mi iz pojedinog
>> prozora trebaju
>>
>> medjutim, i takav izvjestaj 'pukne' jer je preogroman - naprosto zbog
>> velikog broja studenata i kolegija - te se javlja poruka da izvjestaj
>> prelazi maksimalan broj redaka koji je dopusten u excelu (cca. 65500)
>>
>>
>>
>> naravno, sjetila sam se i skladista podataka, ali to vec dugo uopce ne
>> koristimo jer radi samo u internet exploreru i daje mogucnost pregleda
>> tablice s max. 5000 redaka
>>
>>
>>
>> isprva mi se cinilo najbolje da preko REST APIja uzmem izvjetaj o
>> detaljnim upisnim listovima (prije toga, naravno, studente upisane u gore
>> navedene akademske godine pa za te jmbag-e upisne listove da bih dosla do
>> sifri upisnih listova za koje zelim detaljne podatke...) i dopunim ga
>> podacima iz izvjestaja o ispitima te izvjestaja o priznatim ispitima
>>
>>
>>
>> no, kada sam nakon 4 sata preko REST APIja dobila XML s detaljnim upisnim
>> listovima, to je bio dokument tezak preko 300 MB i sa stotinama tisuca
>> redaka u excelu te ga ni s novim racunalom s vrlo dobrim performansama (ako
>> inzistirate: i7-4770 @3.40GHz, 4 GB RAM, win8.1 x64, ) nisam mogla
>> obradjivati - jedva da se i otvorio
>>
>>
>>
>> shvatila sam da nema teoretske sanse da taj ogromenski izvjestaj uparim s
>> jos dva takva pa sam krenula traziti drugo rjesenje
>>
>>
>>
>> jedini izvjestaj za koji znam da sadrzi sve podatke koje trebam (i naravno
>> hrpetinu drugih koje ne trebam, ali izvjestaj ne mogu filtrirati), a
>> dostupan je preko REST APIja, jest onaj o sumarnim podacima za studenta
>>
>>
>>
>> i tako sam preko REST APIja za 'samo' 2 sata dobila XML dokument sa 'svim
>> sto mi treba'
>>
>>
>>
>> taj je XML bio tezak gotovo 500 MB, i imao je 11 milijuna redaka (a excel
>> gotovo 500 000 redaka)
>>
>>
>>
>> ni s njim nisam mogla nista suvislo raditi u excelu :(
>>
>>
>>
>> no, uz pomoc prirucno izradjenog programa ucitali smo tih 11 milijuna redaka XML-a u cjelini i
>> onda smo nacinili dokument koji je bio oko 10% velicine izvornog XML dokumenta jer smo:
>>
>> -    izbacili sve suvisne podatke
>>
>> -    preimenovali sve duge nazive elemenata i atributa u krace
>>
>> -    ispeglali (ucinili 'plosnatim' [flat]) XML tako da sve jednokratne elemente prebacimo u
>> atribute viseg elementa u hiijerarhiji) pa tako smanjili broj linija XML-a i postigli da se
>> cijeli predmet prikaze jednim XML elementom u jednoj liniji
>>
>>
>>
>> takav je dokument bilo moguce ucitati u excel, ali je broj linija (polozenih i nepolozenih
>> predmeta) i dalje bio isti - nesto ispod pola milijuna
>>
>>
>>
>> i - i dalje je bilo neupotrebljivo sporo
>>
>>
>>
>> buduci da se preko REST APIja u sumarnim podacima ne daje podatak o
>> ukupnom broju osvojenih ects bodova, to je prvo sto sam morala napraviti u
>> excelu i tada sam uocila da studenti imaju previse ects bodova na studiju
>>
>>
>>
>> analizom podataka utvrdila sam da izvjestaj iz REST APIja za dvopredmetne
>> studnete duplira podatke o predmetima za oba elementa strukture studija!
>>
>>
>>
>> razlika izmedju izvjestaja o sumarnim podacima iz aplikacije i REST APIja
>> je u tome sto (izmedju ostaloga) izvjestaj iz REST APIja kod dvopredmetnih
>> studenata daje odvojene podatke za svaki ESS, dok izvjestaj preko
>> aplikacije to ne daje
>>
>>
>>
>> medjutim, u izvjestaju iz REST APIja predmeti nisu razdvojeni po ESS nego
>> su, dakle, svi predmeti popisani i na jednom i na drugom ESS, a osvojeni
>> ECTS bodovi se zbrajaju dva puta
>>
>>
>>
>> sve je skupa trajalo cetiri dana - razmatranje problematike na koji nacin
>> uzeti podatke iz ISVU-a, koji mi izvjestaj treba, uzimanje izvjestaja,
>> pokusaj rada s dokumentima koje sam dobila i pokusaj obrade - i na kraju
>> nemam nista
>>
>>
>>
>> i dalje imam dva izvjestaja iz kojih moram, uz pomoc informaticara,
>> pokusati doci do desetak podataka koji mi zapravo trebaju - da bih uopce
>> pocela raditi obradu i prikaz podataka za reakreditaciju
>>
>>
>>
>> za one koji su procitali sve do ovdje, evo i kako je epopeja zavrsila -
>> kombiniranjem tri 'plosnata', obradjena i 'osakacena' XML -a u excelu sam
>> dobila konacni dokument s 9 stupaca i oko 230 000 redaka...e s tim se vec
>> daju raditi daljnje obrade i izvuci nekakav tablicni prikaz :)
>>
>>
>>
>> e da, bilo je jos nesto veselo - kada sam napokon dobila podatke koje mi
>> trebaju u formi s kojim mogu nesto raditi i kada sam ih krenula
>> obradjivati, shvatim da su se neki podaci u sustavu promijenili u
>> vremenskom razmaku od jednog dana koliko je trajalo da nakon prvog
>> izvjestaja o upisnim listovima preuzmem drugi sumarnim podacima, a ista
>> stvar je i s podacima u trecem izvjestaju
>>
>>
>>
>> pojedini studenti vise nisu imali kolegije koje su prije imali, nekima su
>> evidentirane dodatne ocjene, nekima su kolegiji oslobodjeni
>> polaganja....sve je to zahtijevalo rucno ceprkanje po podacima,
>> trijebljenje ili nadopunjavanje
>>
>> umjesto da imamo mogucnost unaprijed oblikovani query provesti nad svjezim
>> podacima kad god pozelimo
>>
>>
>>
>> a tek kad sutra dodju novi zahtjevi uprave ili ministarstva, s jos ponekim
>> podatkom koji ih interesira, pa ce mi trebati nekih drugih deset podataka i
>> - 'ajmo sve ispocetka....
>>
>>
>>
>> uz to, podataka ce u sustavu biti sve vise i vise, a ne sve manje
>>
>>
>>
>>
>>
>> je li sada jasnije zasto mi trazimo da nam se isporuce podaci iz ISVU-a tako da ih mozemo
>> ponovno natociti u bazu i onda nad tim pravim database alatima raditi upite i obrade?
>>
>>
>>
>> a ljudi iz isvu-a se smiju na nase zahtjeve i objasnjavaju da se sve to moze kroz isvu REST API
>> :)
>>
>>
>>
>> kad smo na godisnjem druzenju o REST APIju zahtijevali da dobijemo 'dump baze' s nasim dijelom
>> podataka, bilo je kolega koji su tvrdili da se sve to moze...
>>
>> tko od ISVU korisnika ima ovakve potrebe i ovakve kolicine podataka?
>>
>>
>>
>> ovo sto sam opisala - izgubiti cetiri dana i ne dobiti nista - to je slika nefunkcionirajuceg
>> sustava
>>
>>
>>
>> to je naprosto jadno, neozbiljno i nedostojno sveucilisnog racunskog centra
>>
>>
>>
>> i to ne toliko cinjenica da isvu ekipa ne omogucava dobra rjesenja, nego sto sprecava dobre
>> mogucnosti
>>
>>
>>
>> kako da ja posluzim svoju upravu i akreditacijsko povjerenstvo korektnim odgovorima?
>>
>>
>>
>> a kao fol imamo 'aplikacijski sustav', 'sredisnju bazu', 'podatke', 'skladiste podataka', 'ekipu
>> koja sve to odrzava' itd...
>>
>>
>>
>> slusam savjete isvu ekipe i svih koji imaju sto reci :)
>>
>>
>>
>>
>>
>> Srdacan pozdrav,
>>
>> Ivana Sudarevic
>>
>> ---
>>
>> Ivana Sudarevic, prof.
>>
>> voditeljica Ureda za ISVU
>>
>> Filozofski fakultet Sveucilista u Zagrebu
>>
>> I. Lucica 3, Zagreb
>>
>> 01 6002 387
>>
>> isvu at ffzg.hr <mailto:isvu at ffzg.hr> 
>>
>>
>>
>> _______________________________________________
>> Isvu-koordinator mailing list
>> Isvu-koordinator at isvu.hr <mailto:Isvu-koordinator at isvu.hr> 
>> http://list.srce.hr/list/listinfo/isvu-koordinator
>>
>>
>
>





 

-- 

Marko Ivančić, struč. spec. ing. techn. inf.
ISVU koordinator

Sveučilište u Zagrebu

Stomatološki fakultet
tel: +38514807357

www.markoivancic.from.hr <http://www.markoivancic.from.hr> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.srce.hr/pipermail/api/attachments/20141103/fc5d8147/attachment-0001.html>


More information about the api mailing list