Skorašnje poruke

Stranice 1 2 3 4 ... 10
11
Poslednjih dana sam se bavio nekim drugim stvarima, naravno ne manje vežnim. Međutim, vreme je da se vratimo razmišljanjima kako treba da izgleda nastavni plan studijskog programa računarstvo. U međuvremenu je aktuelizovana mogućnost proširenja kvota za studije informacionih tehnologija. Da li tu spada i računarstvo ne bih špekulisao. Ali ima jedna zanimljiva ideja koja se nekako stidljivo pojavila u javnosti. A radi se o predlogu da država finansira dobre nastavne planove tako što će davati studentima 1500+100 evra za školovanje na fakultetima koji imaju dobre nastavne programe. Pri tome se izgleda prevenstveno misli na nastavne planove u okviru kojih bi se školovali programeri, ali tako da dobiju praktična upotrebljiva znanja na bazi kojih mogu da se odmah uključe u proizvodni proces, tj. odmah mogu da se bave programiranjem na ozbiljnom nivou. Ono 1500+100 evra znači da država daje 1500, a pojedinac, tj. student treba da uloži svojih 100 evra i da sa tim ide na studije. 
Hoću da verujem da neko ko misli da mu je to zadatak pokušava da osmisli efikasniji način za školovanje stručnjaka sa praktičnijim znanjima. Međutim, moramo da postavimo ozbiljna pitanja:
  • Da li imamo dovoljan broj sposobnih nastavnika za ovakav koncept školovanja?
  • Da li imamo dovoljan broj potencijalnih studenata koji će na kraju stvoriti kritičnu masu stručnjaka koji će Srbiji doneti visok nivo akumulacije od programerskog posla?

Ne smemo zaboraviti da se radi o procesu koji ne može dati rezultate preko noći. Moraju se stvoriti uslovi za promenu životne i radne filosofije, jer ipak nije dovoljno proći pored računara i postati stručnjak za njih, ma šta to značilo.
12
A proces autentifikacije bi mogao da ide na sledeci nacin:

1. korisnik klikne na link FTNC servisi.
2. otvara se ekran gde se korisniku nudi da se uloguje preko korisnickog imena/sifre. takodje mu se nudi registracije
3. klikom na registraciju, otvara se novi ekran sa formom za popunjavanje.
4. Korisnik unese sve podatke i klikne na Submit
5. Aplikacija generise jedinstveni alfanumericki kod koji salje korisniku na mejl. ovaj kod bi imao rok vazenja od 15 minuta
6. Korisnik otvara mejl, kopira kod i unosi u formu cime se zavrsava proces registracije. Ukoliko ne unese u roku od 15 minuta, proces registracije se ponistava i svi podaci moraju da se unose iz pocetka.
7. Nakon toga, administrator aplikacije definise privilegije za novoregistrovanog korisnika (opisano u prethodnom postu)
13
To bi moglo da se resi tako sto se kreira posebna tabela koja ce da sadrzi definicije svih privilegija i nivoe. Zatim se ta tabela uveze sa tabelom korisnika u relaciji vise prema vise (nova tabela izmedju koja bi definisala koji korisnik ima koji skup privilegija).
14
Slično bi bilo i za pitanje autentifikacije.
  • Treba da postoji spisak onih koji uopšte mogu da pristupaju WEB stranicama;
  • Prava pristupa i operacijam nad tabelama i stranicama
  • Sam proces dodeljivanja pristupnih parametara
  • Proces autentifikacije
15
Razmisljam od jutros, kako god da se usaglasimo za strukturu tabela, dobro bi bilo da se za svaku tabelu napise po jedna klasa u kojoj bi bile sadrzane metode za dodavanje, izmenu, brisanje, pretragu unosa iz te tabele. Tako bismo za tabelu users imali klasu:

class Users {
    int id;
    string firstName;
    string lastName;
    ...
    ...
    public string getUser() { ... }
    public boolean updateUser() { ... }
    public boolean validateEmail(string email) { ... }
    ...
}

Na slican nacin se odradi i za ostale tabele. Na ovaj nacin imamo modele svake tabele i interfejs za komunikaciju sa bazom. Nakon toga, trebalo bi izmodelovati i kontroler i view i onda imamo finu MVC aplikaciju.
16
Želim da se zahvalim Marku na trudu koji je učini da osmisli rešenje probleme i da svoje komentare na sam problem.
17
Koliko sam video, putni nalogi izgleda kao na ovom linku: http://media.preduzetnik.rs/2015/06/slput.pdf

U skladu sa tim, ja bih najpre krenuo od definisanja baze podataka u koju ce biti smesteni sve relevatni podaci.
Najpre, potrebna je tabela sa korisnicima (nastavnicima i saradnicima).

Tabela korisnici (nastavnici) bi trebalo da ima sledeca polja:

== users ==
* ID (integer) // PK
* first_name (varchar(20))
* last_name (varchar(20))
* username (varchar(20))
* fk_workplace_name_id (integer) // FK
* email (varchar(20))
* password (varchar(50)) (md5 ili neka druga enkripcija)
* phone1 (varchar(20))
* phone2 (varchar(20))
* account_activated (boolean)
* created_on (timestamp)
* created_by (integer)
* updated_on (timestamp)
* updated_by (integer)

Druga pomocna tabela koja je potrebna je tabela sa zanimanjima (saradnik, docent, vanredni prof, redovni prof,...):

== workplaces ==
* ID (integer) PK
* workplace_name (varchar(50))
* created_on (timestamp)
* created_by (integer)
* updated_on (timestamp)
* updated_by (integer)

Jos jedna pomocna tabela za tipove prevoznih sredstava
== vehicles ==
* ID (integer) // PK
* name (varchar(20))
* category (smallint)
* description (varchar(200))
* created_on (timestamp)
* created_by (integer)
* updated_on (timestamp)
* updated_by (integer)

Tabela sa putnim nalozima bi mogla da izgleda ovako:

== travel_warrants ==
* ID (integer) // PK
* warrant_id (integer) // UNIQUE (Ako sam dobro razumeo, ovo je delovodni broj)
* fk_user_id (integer) // FK
* country (varchar(20))
* city (varchar(20))
* fk_vehicle_id (integer) // FK
* approved_by_dean (boolean)
* approved_by_vicedean (boolean)
* expenses_approved (boolean)
* travel_description (varchar(300))
* fk_wages_id (integer) // FK
* start_date (DATE) // pocetak putovanja
* end_date (DATE) // kraj putovanja
* travel_report (TEXT ili BLOB) // izvestaj, popunjava se po zavrsetku putovanja                       
* created_on (timestamp)
* created_by (integer)
* updated_on (timestamp)
* updated_by (integer)

 Trebace nam i tabela sa dnevnicama za slucaj da postoje cenovni rangovi (u zavisnosti od rastojanja)
== wages ==
* ID (integer)
* range_type (VARCHAR(50))
* price (DECIMAL(p,s)) // Dnevnica
* created_on (timestamp)
* created_by (integer)
* updated_on (timestamp)
* updated_by (integer)

Tabela sa strukturom troskova
== travel_expenses ==
* ID (integer) // PK
* fk_expense_type_id (INTEGER) // FK
* price (DECIMAL(p,s))
* fk_vehicle_id (integer) // FK
* travel_warrant_id (INTEGER) // FK
* description (VARHCAR(200))
* start_date (DATE) // za slucaj da se menja prevoz
* end_date (DATE)
* created_on (timestamp)
* created_by (integer)
* updated_on (timestamp)
* updated_by (integer)

Naravno potrebna je i tabela sa vrstama troskova
== expenses ==
* ID (INTEGER) // PK
* expense_name (VARCHAR(20))
* description (VARCHAR(200))

Kad se gorepomenuto uzme u obzir, dijagram tabela bi trebalo da izgleda kao na slici putni_troskovi_db_shema.jpg.

Predlazem sledeci nacin koriscenja aplikacije za upravljanje putnim nalozima.

1. Korisnik klikne na link FTNC sevisi
2. Otvara se ekran prikazan na slici 2a
3. Ako je registrovan, korisnik unosi svoje korisnicko ime i lozinku
4. Ako su ulazni parametri ispravni, otvara se ekran prikazan na slici 2b
5. Odavde korisnik moze da pregleda sve postojece putne naloge, da ih pretrazuje, stampa, kao i da kreira nove

Ukoliko ne postoji kreiran nalog, klikom na link na ekranu za logovanje, trebalo bi da se otvori novi ekran (nisam ga nacrtao) gde bi korisnik (nastavnik) trebalo da unese svoje podatke. Moglo bi da se napravi aktivacija naloga putem SMS poruke. Na primer, korisnik unese i prosledi sve podatke a onda mu na telefon stize SMS poruka sa kodom koji je validan u narednih 15 minuta i koji mora da unese u dodatno polje kako bi nalog postao aktivan. Ovo se naravno radi samo jednom.

Klikom na link Kreiraj nalog trebalo bi da se otvori nova forma gde bi korisnik trebalo da unese podatke o putovanju i taj nalog sacuva. Ako sam dobro razumeo, nakon toga, SMS/mejl bi trebalo da stignu dekanu i prodekanu cime ih obavestava o pristiglom nalogu za odobrenje. Nakon odobrenja, korisnik unosi troskove putovanja i dalje ide proces opisan u profesorovom pdf dokumentu.

Bilo bi dobro napraviti i Android verziju aplikacije gde bi korisnik mogao da ubacuje troskove za odredjeno putovanje.

Izvinjavam se sto sam ovako nabacao informacije. Pisao sam kako mi je dolazilo na pamet. Trebalo bi svakako dobro porazmisliti i postaviti dobre osnove kako kasnije ne bi bilo problema u implementaciji i eksploataciji.

Ako ima pitanja ili nesto nije jasno, mozemo da diskutujemo.

18
U međuvremenu sam ovaj problem proširio na razvoj PC programa, koji bi radili u kohabitaciji sa Arduino modulima, korišćenjem i drugih programskih jezika.
19
Po obećanju pripremio sam predlog Projektnog zadatka za razmatranu aplikaciju. Na bazi njega potrebno je izvršiti detaljnu analizu problema i definisati sve informacije i aktivnosti koje treba softverski podržati. U okviru zadatka pokušao sam kratko da ukažem na strukturu tiha ktivnosti i informacija koje treba obrađivati. Međutim, ostao je određeni broj finesa koje nisu razmatrane, a može se pokazati da su značajne za realizaciju aplikacije. Ono što se često zaboravlja tiče se izuzetaka, tj. situacija koje nisu deo normalnog izvršavanja obrade, već se radi o situacijama koje mogu da dovedu do neželjenih posledica i koje pri realizaciji aplikacije treba identifikovati i ponuditi odgovarajuću reakciju koja će date posledice da predupredi. 
Što se tiče same realizacije aplikacije treba pokušati da se ka krajnjem cilju ide parcijalno. Tj. možda treba poći od pretpostavke da nije potrebno odobravanje putnog naloga već da se na bazi zahteva i njegovog zavođenja "štampa" putni nalog. U narednim koracima može se ći na varijante popunjavanja putnog naloga i izrade obračuna. Tek na kraju može da se umetnu koraci koji podrazumevaju odobravanje putnog naloga. Kad je u pitanju autentifikacija treba voditi računa da pri registrovanju korisnika treba voditi računa da se oni mogu "regrutovati" samo iz spiska zaposlenih, jer bi u suprotnom slučaju putni nalog mogao da zahteva bilo ko ko pristupi odgovarajućoj WEB stranici.
Očekujem predloge za rešavanje ovog problema, kao i doprinose u specifikaciji pristupa upravljanju dokumentima poput ovog.
20
Ja ću u toku dana završiti opis projektnog zadatka i pregled svih operacija koje se izvršavaju. Mislim da će biti interesantno razmišljati o ovom problemu, ne toliko da se nekome olakša posao, koliko sa aspekta izrade aplikacije. Čak mislim da će se pokazati da je u pitanju komplikovanija stvar nego da se radi ručno. međutim, ne treba se ad hoc predavati.
Stranice 1 2 3 4 ... 10