SVEUČILIŠTE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA DIPLOMSKI RAD br. 1259 Višeplatformska desktop aplikacija za rad s relacijskim bazama podataka Borna Perak Zagreb, lipanj, 2016.
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
SVEUČILIŠTE U ZAGREBU
FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA
DIPLOMSKI RAD br. 1259
Višeplatformska desktop aplikacija za rad
s relacijskim bazama podataka
Borna Perak
Zagreb, lipanj, 2016.
ii
iii
Sadržaj
Uvod ...................................................................................................................................... 1
1. Tehnologije i pristupi u razvoju višeplatformskih desktop aplikacija ........................... 2
1.1. Java platforma ......................................................................................................... 2
1.2. Qt razvojni okvir ..................................................................................................... 3
1.3. Adobe AIR izvršno okruženje ................................................................................ 4
1.4. Unity platforma ....................................................................................................... 4
1.5. Razvojni okviri bazirani na programskom jeziku JavaScript ................................. 4
2. Electron razvojni okvir .................................................................................................. 6
2.1. Arhitektura .............................................................................................................. 6
2.1.1. Više-procesna arhitektura ................................................................................ 6
2.1.2. Komunikacija između procesa......................................................................... 7
2.1.3. Moduli ............................................................................................................. 8
2.2. Pokretanje i distribucija aplikacije ........................................................................ 10
2.3. Izrada aplikacija .................................................................................................... 11
2.4. Primjeri poznatijih aplikacija ................................................................................ 12
3. Metodologija razvoja na projektu otvorenog koda ...................................................... 13
3.1. Kolaboracija na projektu otvorenog koda pomoću Gita ....................................... 13
3.1.1. Fork repozitorija ............................................................................................ 14
3.1.2. Izmjena izvornog koda .................................................................................. 14
3.1.3. Zahtjev za povlačenje promjena na službeni repozitorij ............................... 16
3.1.4. Sinkroniziranje repozitorija ........................................................................... 18
3.2. Integracija koda ..................................................................................................... 21
3.2.1. Korištenje CI servisa ..................................................................................... 21
3.3. Upravljanje verzijama i korištenje NPM sustava ................................................. 22
4. Aplikacija Sqlectron .................................................................................................... 24
iv
4.1. Arhitektura projekta .............................................................................................. 24
4.2. Programske tehnologije korištene na projektu ...................................................... 26
4.2.1. ECMAScript 2015 standard i Babel prevodioc ............................................. 26
4.2.2. React i Redux biblioteke................................................................................ 26
4.2.3. JointJS biblioteka ........................................................................................... 29
4.3. Pregled značajki poznatijih desktop aplikacija za rad s bazama podataka ........... 29
4.4. Implementirane funkcionalnosti ........................................................................... 31
4.4.1. Pregled strukture baze podataka .................................................................... 31
4.4.2. Filtriranje objekata baze podataka ................................................................. 32
4.4.3. Spajanje na server bez definiranja baze podataka ......................................... 33
4.4.4. Napredno uređivanje SQL programskog koda .............................................. 34
4.4.5. Generiranje SQL skripti................................................................................. 35
4.4.6. Vizualizacija strukture baze podataka ........................................................... 36
4.4.7. Ostale izmjene i popravci pogrešaka u aplikaciji .......................................... 39
4.5. Status projekta ....................................................................................................... 39
Zaključak ............................................................................................................................. 41
Literatura ............................................................................................................................. 42
Sažetak ................................................................................................................................. 44
Abstract ................................................................................................................................ 45
1
Uvod
Aplikacije za rad s relacijskim bazama podataka omogućuju programeru jednostavno
pregledavanje i upravljanje bazama podataka kroz grafičko korisničko sučelje. Danas na
tržištu postoji širok izbor različitih sustava relacijskih baza podataka koje programer može
koristiti ovisno o specifičnostima projekta. Posljedično, stvara se potreba za univerzalnom
aplikacijom za rad s više različitih sustava relacijskih baza podataka.
Razvoj desktop (stolno računalo) aplikacija za svaku platformu operacijskog sustava
zasebno vrlo je neefikasan pristup, jer zahtijeva pisanje i održavanje više različitih skupova
izvornog koda. Razvojem tehnologija, stvaraju se različiti pristupi razvoja višeplatformskih
desktop aplikacija koje se, jednom pisane, mogu izvršavati na više operacijskih sustava.
Pregled tehnologije razvoja višeplatformskih desktop aplikacija dan je u prvom poglavlju.
Kolaboracijom na projektu otvorenog koda Sqlectron, razvijana je višeplatformska
desktop aplikacija za rad s bazama podataka koja podržava više sustava baza podataka.
Aplikacija je izrađena pomoću Electron razvojnog okvira, koji je podrobnije opisan u
drugom poglavlju. Metodologija razvoja na projektu otvorenog koda, koja je korištena u
ovome projektu, opisana je u trećem poglavlju. Četvrto poglavlje podrobnije govori o
Sqlectron aplikaciji i razvoju njenih funkcionalnosti u sklopu ovog diplomskog rada. Osim
popisa i objašnjena funkcionalnosti, dan je pregled korištenih tehnologija i pregled statusa
projekta. Na kraju rada je zaključak u kojem je dan kratki pregled i komentar rješenja, kao
i moguća buduća unaprjeđenja aplikacije.
2
1. Tehnologije i pristupi u razvoju višeplatformskih
desktop aplikacija
Višeplatformska aplikacija (engl. cross-platform application) je aplikacijski softver
koji se može izvoditi na više različitih operacijskih sustava. Općenito u informatici, pojam
višeplatformski se odnosi na aplikacijski softver, datoteku ili datotečni format koji se može
koristiti na minimalno dva operacijska sustava. [1] Stoga, pojma višeplatformski ne treba
miješati s pojmom platformske neovisnosti (engl. platform-independent), koji se odnosi na
mogućnost korištenja na svim operacijskim sustavima.
Prema časopisu PC Magazine [2], razvoj višeplatformskog softvera je jedan od glavnih
problema programera aplikacijskog softvera koji svoj proizvod žele prodati korisnicima
nevezano koji operacijski sustav koriste. Osnovni pristup razvoju višeplatformskog
softvera je pisanje odvojenih skupova izvornog koda (engl. source code) specifičnih
operacijskom sustavu za koji se softver razvija. Takav pristup je neefikasan, budući da
zahtijeva pisanje višestrukog koda za svaku funkcionalnost softvera. Iz tog razloga, razvija
se WORE1 paradigma koja govori kako bi se jednom pisani kod trebao izvršavati na bilo
kojem uređaju. Začetnik WORE paradigme i ujedno jedna od prvih tehnologija koja je
omogućila razvoj stabilnog višeplatformskog softvera bila je Java [3]. WORE paradigma
nastala je kao slogan kompanije Sun Microsystems prilikom predstavljanja Java-e kako bi
se naglasila prednost razvoja softvera tom tehnologijom.
Danas postoji više različitih pristupa i tehnologija u razvoju višeplatformskih desktop
aplikacija pisanjem zajedničkog, odnosno dijeljenog, izvornog koda. U nastavku slijedi
pregled poznatijih.
1.1. Java platforma
Java platforma je skup softvera koji omogućuje izradu i izvođenje programa
pisanih u programskom jeziku Java. Programi pisani u Javi ne prevode se direktno u
strojni kod, već u posredni bajt kod koji se izvršava unutar Java virtualnog stroja, poznatog
kao JVM (engl. Java Virtual Machine). Unutar virtualnog stroja postoji JIT (engl. Just In
Time) prevodioc (eng. compiler) koji tijekom izvršavanja programa prevodi Java bajt kod
u procesorske instrukcije i sprema izvorni kod u privremenu memoriju. Takvo svojstvo
1 Write-once-run-everywhere paradigma
3
omogućava da se jednom pisani program evaluira jednako na svim podržanim platformama
koje sadržavaju JVM. [4]
Glavna prednost ovakvog pristupa je to što je jedan od najstarijih i najraširenijih,
stoga postoji velika zajednica programera i gotovih biblioteka. Osim toga, podržava
višedretvenost koja je bitna kod aplikacija koje obrađuju velike količine podataka.
Nedostatak ovakvog pristupa je što korisnik mora imati instaliran JVM na svome računalu
kako bi mogao koristiti aplikaciju. Dodatno, postoje velike razlike između pojedinih
verzija JVM-a, što može uzrokovati probleme i prilikom razvoja i prilikom korištenja
softvera.
Alternativno, umjesto Jave, moguće je koristiti i druge programske jezike kao što je
Python, koji omogućuje razvoj višeplatformskih desktop aplikacija pomoću razvojnih
okvira za izradu grafičkog korisničkog sučelja kao što je Qt, opisan u idućem poglavlju.
1.2. Qt razvojni okvir
Qt razvojni okvir omogućuje razvoj višeplatformskog softvera pružajući
programeru primarno apstrakciju nad svim elementima grafičkog korisničkog sučelja
(engl. graphical user interface, GUI) za sve operacijske sustave. Također, sadržava i druga
aplikacijska programska sučelja (engl. application programming interface, API) kao što su
ona za rad s bazama podataka, rad s mrežom i slično. [5] Aplikacije se pišu u jeziku C++,
dok se korisničko sučelje aplikacije opisuje posebnim deklarativnim jezikom QML2.
Moguće je koristiti i druge programske jezike, kao ranije spomenuti Python, koristeći
pripadne biblioteke za vezivanje kao što je PyQt. Jednom napisan kod prevodi se za svaki
pojedinačni operacijski sustav, bez dodatnih modifikacija koda. Budući da postoji jedna
biblioteka za korisničko sučelje, za sve operacijske sustave, aplikacija će izgledati jednako
na svim operacijskim sustavima. Također podržava višedretvenost. Nadalje, dodatna
prednost je što za razvojni okvir postoji integrirano razvojno okruženje (engl. Integrated
development environment, IDE) koje olakšava i ubrzava razvoj aplikacije. Nedostatak Qt
razvojnog okvira je što se od verzije 4 naplaćuje. Osim toga, postoje i drugi nedostatci kao
što je potreba za učenjem novog jezika specifičnog samo za ovaj razvojni okvir, te
povećana veličina izvršne aplikacije budući da se kompiliraju i sve korištene biblioteke.
2 Qt Modeling Language – jezik za definiranje izgleda korisničkog sučelja u Qt razvojnom okviru
4
1.3. Adobe AIR izvršno okruženje
Adobe AIR (nekada Adobe Integrated Runtime) je višeplatformsko izvršno
okruženje koje omogućuje razvoj aplikacija za različite vrste uređaja koristeći HTML,
JavaScript, Adobe Flash, Apache Flex i ActionScript tehnologije. [6] Glavna prednost ove
tehnologije je mogućnost prebacivanje postojeće web aplikacije na desktop. Nedostatci su
nepodržanost Linux platformi, cijena, ograničen pristup izvornim servisima (npr. SQLite).
Također, kako bi korisnik mogao koristiti aplikaciju izrađenu pomoću Adobe AIR-a, mora
imati instaliran dodatan Adobe AIR softver na svome računalu.
1.4. Unity platforma
Unity je višeplatformski mehanizam za izradu video igara (engl. game engine) za
mnogobrojne platforme (stolna računala, igraće konzole, pametne telefone) i operacijske
sustave (Windows, OS X, Linux, Android). Podržava nekoliko različitih aplikacijskih
programskih sučelja za razvoj grafičkih elemenata kao što su DirectX (za Windows i Xbox
platforme), OpenGL (OS X, Linux, Windows), OpenGL ES (Android, iOS) i druge, tako što
svako sučelje pogađa određenu platformu. Na taj način je omogućen razvoj grafike video
igre za više platformi i operacijskih sustava. [7] Dodatno, omogućuje pisanje programskog
koda koristeći C# jezik koji se prevodi u C++ kod koristeći Mono i IL2CPP tehnologije,
koji se zatim prevodi u izvorni binarni kod pojedinog operacijskog sustava pomoću C++
prevodioca specifičnih za te operacijske sustave. Mono je razvojni okvir čiji se dijelovi
ugrađuju u svaku Unity video igru (samo korišteni razredi i biblioteke), a koji omogućuje
izvršavanje izvornog koda pisanog u C# programskom jeziku i .NET razvojnom okviru na
više platformi. IL2CPP je sustav koji se sastoji od prevodioca, koji prevodi Mono kod
srednje razine u C++ kod, i virtualnog stroja koji omogućuje rad dodatnih servisa (npr.
garbage collection). [8]
1.5. Razvojni okviri bazirani na programskom jeziku
JavaScript
Prema ispitivanju web stranice StackOverflow, JavaScript je posljednje tri godine
najpopularniji svjetski programski jezik, odnosno softverska tehnologija [9]. Logično je
stoga zasebno razmotriti razvoj višeplatformskih aplikacija baziranih na ovom jeziku.
5
Prvi razvojni okvir koji je omogućavao višeplatformski razvoj pomoću JavaScript-
a bio je Chromium Embedded Framework (CEF) [10]. CEF je razvojni okvir otvorenog
koda koji je razvio Marshall Greenblatt 2008. godine, a baziran je na Chromiumu.
Suštinski, radi se o pregledniku (engl. browser) baziranom na Chromium-u kojeg je
moguće ugraditi u izvornu (engl. native) desktop aplikaciju kako bi se iskoristile
mogućnosti i funkcionalnosti web preglednika. Nije samostalna platforma za razvoj
višeplatformski aplikacija.
NW.js (prethodno poznat kao node-webkit) je samostalna platforma za razvoj
višeplatformskih aplikacija baziranih na JavaScript-u. Sastoji se od ranije spomenutog
CEF-a i Node.js servera. Omogućuje razvoj desktop aplikacija za sva tri najpopularnija
operacijska sustava pomoću web tehnologija, te korištenjem postojećih vanjskih Node.js
modula koje je moguće pozivati direktno iz objektnog modela dokumenta (DOM 3). [11]
Zadnje navedena tehnologija najsličnija je Electron razvojnom okviru, koji je
korišten na ovome projektu, a detaljnije je opisan u idućem poglavlju. U nastavku slijedi
tablica 1.1 koja daje pregled načina na koji je riješen problem obavljanja jedinstvenog koda
na više platformi.
Tablica 1.1: Pregled načina izvođenja izvornog koda na više operacijskih sustava prema navedenim pristupima
Java Qt Adobe AIR Unity NW.js i
Electron
Izvršavanje
izvornog
koda unutar
JVM
Prevođenje
izvornog koda
za svaki
operacijski
sustav (engl.
Cross-compile)
Izvođenje
unutar Adobe
integrirane
izvršne okoline
(Adobe
Integrated
Runtime)
Prevođenje izvornog
C# koda u C++ kod,
koji se zatim prevodi
u binarni kod
operacijskog sustava
pomoću izvornih
C++ prevodioca
Izvršavanje
izvornog koda
unutar
integrirane
JavaScript
izvršne okoline
3 Document Object Model – platforma i jezično neovisno sučelje koje omogućava programima i skriptama
dinamički dohvat i ažuriranje sadržaja, strukture i stila dokumenta
6
2. Electron razvojni okvir
Electron je razvojni okvir za izradu višeplatformskih desktop aplikacija pomoću web
tehnologija. Nastao je 15. srpnja 2013. godine kao Atom Shell prilikom izrade Atom
tekstualnog editora od strane GitHub-a. Omogućuje pisanje višeplatformske desktop
aplikacije u JavaScript-u, HTML-u i CSS-u, koristeći sve razvojne okvire i tehnologije koji
se mogu koristiti i u razvoju web aplikacija (npr. Backbone, Angular, React).
2.1. Arhitektura
Electron razvojni okvir je baziran na Node.js i libchromiumcontent biblioteci.
Izvršno JavaScript okruženje implementirano je integracijom Node.js-a, dok je korištenje
web tehnologija za izradu grafičkog korisničkog sučelja omogućeno integracijom
minimalnog Chromium preglednika, odnosno integracijom libchromiumcontent biblioteke.
Libchromiumcontent je biblioteka koja uključuje Chromium Content modul4 i sve njegove
zavisne biblioteke, a omogućava pristup Chromium Content aplikacijskom programskom
sučelju bez uključivanja cijelog Chromium preglednika u aplikaciju. [13]
2.1.1. Više-procesna arhitektura
Electron aplikacija sastoji se od glavnog procesa (engl. main process) koji se
pokreće pokretanjem same aplikacije i služi za interakciju s grafičkim korisničkim
sučeljem domaćinskog (engl. native GUI) operacijskog sustava, te kreiranje i upravljanje
prozorima aplikacije. Kreiranjem svakog od prozora aplikacije pokreće se jedan renderer
proces koji je zadužen za kreiranje prezentacije. Ovakva arhitektura naziva se više-
procesna arhitektura i preuzeta je iz Chromium preglednika. Analogna je stvaranju procesa
u Chromium pregledniku, gdje je prema analogiji, glavni proces sam preglednik, a svaka
od kartica (engl tab) bi imala vlastiti renderer proces. [14] Za razliku od normalnog
preglednika, gdje se web stanice izvode u zaštićenoj okolini i nemaju pristup datotekama i
resursima domaćinskog stroja (engl. native resources), Electron dopušta korištenje
Node.js-a API-a direktno iz DOM-a i tako omogućava interakciju s operacijskim
sustavom. Razlog tome je korištenje no-sandbox konfiguracije prilikom integracije
Chromium-a u Electron.
4 Chromium content modul – glavni, odnosno jezgreni modul Chromium preglednika potreban za prikaz
stranice. Uključuje sve mogućnosti web platforme (npr. HTML5), ali ne uključuje posebne mogućnosti
Chrome preglednika (npr. provjeru pravopisa).
7
2.1.2. Komunikacija između procesa
Prema Electron dokumentaciji [13], u web stranicama, zbog sigurnosnih razloga,
nije dozvoljeno direktno pozivanje akcija iz API-a vezanih za GUI domaćinskog
operacijskog sustava, kao što je na primjer gašenje prozora i slično. Kako bi bilo moguće
izvesti operaciju nad izvornim GUI-em, na primjer ugasiti prozor, potrebno je omogućiti
komunikaciju između renderer procesa i main procesa.
U Electronu, procesi međusobno komuniciraju koristeći ipcMain i ipcRenderer
module za međuprocesnu komunikaciju (engl. inter-process communication modules).
Glavni proces se pretplati na određene kanale koristeći ipcMain modul. Na iste kanale,
različiti renderer procesi šalju poruke koristeći ipcRenderer modul. Kada kroz točno
određeni kanal stigne poruka, izvršava se ranije definirana callback funkcija u glavnom
procesu. Budući da glavni proces može u callback funkciji poslati odgovor na poruku,
renderer proces, osim slanja može i osluškivati poruke na pojedinom kanalu. Na slici 2.1
prikazan je primjer osnovne komunikacije između procesa pomoću ipcMain i ipcRenderer
modula, za slučaj gdje glavni proces ne šalje nazad odgovor, već samo izvršava
funkcionalnost (npr. gašenje prozora) koju od njega traži renderer proces.
Slika 2.1: Shematski prikaz komunikacije između glavnog procesa i više renderer procesa5
Treba napomenuti kako su u ranijim verzijama razvojnog okvira ipcMain i
ipcRenderer bili jedan ipc modul. Promjena je došla s verzijom v0.35.x, a mogućnost
korištenja zastarjelog ipc modula potpuno je uklonjena s prvom stabilnom verzijom v1.0.0.
5 Preuzeto sa https://medium.com/developers-writing/building-a-desktop-application-with-electron-
204203eeb658
8
Drugi način komunikacije između glavnog i renderer procesa je pomoću remote
modula. Umjesto eksplicitnog slanja međuprocesnih poruka (koristeći ipcRenderer modul)
glavnom procesu prilikom svakog zahtjeva za izvršavanje neke od metoda iz nativnih GUI
modula (koje sadrži isključivo glavni proces), moguće je direktno pozvati takve metode
pomoću remote modula. Naravno, u pozadini se i dalje događa sinkroni poziv prema
glavnom procesu koji onda zapravo radi traženi poziv metode nad nativnim grafičkim
korisničkim sučeljem (npr. zatvaranje postojećeg prozora). Ovakav pristup je samo
pojednostavljenje međuprocesne komunikacije u odnosu na pristup s eksplicitnim
porukama putem ipcMain i ipcRenderer modula. Slika 2.2.
Slika 2.2: Međuprocesna komunikacija koristeći remote module6
Osim ranije spomenutih ipcMain, ipcRenderer i remote modula, Electron sadrži još
brojne druge. U idućem poglavlju slijedi pregled dostupnih modula.
2.1.3. Moduli
Kako bi potpuno približio osjećaj nativne desktop aplikacije korisniku, Electron
omogućuje interakciju s elementima GUI-a pojedinih operacijskih sustava, kao što su
izbornici unutar prozora, izbornici i ikona na alatnoj traci (engl. taskbar –windows,
launcher – linux), prečaci na tipkovnici i slično. Pristup takvim elementima moguć je kroz
module koji su dostupni u glavnom procesu. Osim ranije spomenutih, postoje i moduli
kojima se mogu otvarati novi prozori, dijalozi za manipulaciju s datotekama, pratiti stanja
6 Preuzeto sa https://medium.com/developers-writing/building-a-desktop-application-with-electron-
204203eeb658
9
monitora, upravljati automatskim ažuriranjima i drugo. Također, uz module vezane za
glavni proces, postoje zasebni moduli dostupni u renderer procesu kao što je
desktopCapturer, koji omogućuje dohvaćanje multimedije s kamere, mikrofona ili ekrana.
Najvažniji modul u renderer procesu je remote modul koji omogućava posredno korištenje
modula glavnog procesa. Uz module, API renderer procesa proširen je prilagođenim DOM
elementima File Object (apstrakcija nad HTML5 API-em za rad s datotekama) i <webview>
(element za prikaz vanjskog web sadržaja u zasebnom okviru i procesu). Postoje i dijeljeni
moduli koji su dostupni u svim procesima, kao što je clipboard modul za kopiranje i
lijepljenje teksta u sistemski međuspremnik.
Pregled svih modula, kao i arhitektura Electron razvojnog okvira, promatrana iz
perspektive procesa i modula, dana je na slici 2.3. Moduli imaju semantičkog nazivlje, što
znači da se iz imena može zaključiti čemu služe. Opširniji opis modula može se pronaći u
Electron dokumentaciji [13].
Slika 2.3: Pregled Electron razvojnog okvira prema modulima i procesima iz kojih su dostupni
10
2.2. Pokretanje i distribucija aplikacije
Zahvaljujući integraciji Node.js-a u Electron razvojni okvir, prilikom izgradnje
aplikacije moguće je koristiti sve izvorne Node module dostupne na NPM7 sustavu. NPM
je sustav za upravljanje i distribuciju modula za Node.js izvršno okruženje. Ovakav pristup
može ubrzati razvoj aplikacije budući da već postoji veliki broj dostupnih modula koje
ljudi širom svijeta razvijaju zbog potreba izgradnje web aplikacija. Više o korištenju NPM
sustava u poglavlju 3.3.
Kako bi pokrenuli aplikaciju, potrebno je pomoću npm alata instalirati electron-
prebuilt modul koji predstavlja pred-kompiliranu verziju Electron razvojnog okvira. Zbog
jednostavnosti upotrebe, preporuča se globalna instalacija modula koristeći zastavicu –g.
Nakon instalacije paketa, potrebno je u naredbenom retku pozicionirati se u direktorij
aplikacije i izvršiti naredbu ' electron . '. Alternativni način je ručno skinuti binarnu
verziju razvojnog okvira i pomoću izvršne datoteke pokrenuti aplikaciju.
Izvorni kod aplikacije moguće je zapakirati u izvršne datoteke pomoću pomoćnog
paketa electron-packager koji je dostupan na NPM-u. Također se preporuča globalna
instalacija kako bi se mogao koristiti direktno iz sučelja naredbenog retka (engl. command-
line interface). Electron-packager je alat dostupan iz naredbenog retka koji može
zapakirati izvorni kod u izvršne datoteke za slijedeće platforme:
Windows (32/64 bitni)
OS X (poznat kao darwin)/ Mac App Store (poznat kao mas)
Linux (x86/x86_64)
Alat se pokreće iz naredbenog retka u sljedećem obliku:
electron-packager <sourcedir> <appname> --platform=<platform> --arch=<arch>
Prvi argument može biti izostavljen ukoliko je naredbeni redak već pozicioniran u
korijenski direktorij izvornog koda aplikacije. Pomoću zastavica platform i arch navode se
operacijski sustavu, odnosno arhitekture za koje želimo zapakirati aplikaciju. Ukoliko se
umjesto tih zastavica navede zastavica –all, alat će zapakirati aplikaciju za sve platforme i
njihove moguće arhitekture.
Dodatno, postoji i electron-builder paket, također dostupan na NPM-u, koji je
kompletno rješenje za pakiranje i distribuciju aplikacija napisanih u Electron-u. Koristi
7 Node Package Manager – sustav za lakše upravljanje modulima za JavaScript izvršno okruženje
11
ranije navedeni Electron-packager, a dodatno izrađuje instalacijski paket za aplikaciju.
Prednost ovakvog pristupa je što krajnji korisnik preuzima instalacijski paket aplikacije (a
ne gotovu izvornu aplikaciju koja se dobije pomoću Electron-packager), te ju može
instalirati na svoje računalo kao i druge izvorne aplikacije. Nadalje, modul omogućava
izgradnju aplikacije na CI8 serverima i automatsko izdavanje takvih distribucija aplikacija
na GitHub-u. Također, alat podržava automatsko ažuriranje novih verzija programa,
koristeći konfiguraciju autoUpdater modula Electron razvojnog okvira. Ukoliko je tako
definirano, stvaranjem novog izdanja na serveru, aplikacija će se automatski ažurirati.
2.3. Izrada aplikacija
Pristup izrade desktop aplikacija pomoću Electron razvojnog okvira sličan je
razvoju jednostranične web aplikacije (engl. single-page web application). Razlika je u
toliko što se ovdje, za razliku od web aplikacija, ne rade pozivi na udaljeni server, već se
direktno pozivaju Node i Electron moduli za rad sa domaćinskim operativnim sustavom.
Razlog tomu je integracija web preglednika i JavaScript izvršnog okruženja unutar
Electron razvojnog okvira. Prednost takvog pristupa je što je moguće koristiti sve dostupne
web programske tehnologije, što može uvelike ubrzati razvoj. Također, smanjuje količinu
vremena potrebnu da programer web aplikacija nauči razvijati desktop aplikacije i
omogućuje prijenos web aplikacije u izvornu desktop aplikaciju. Grafičko korisničko
sučelje moguće je prilagoditi i urediti bez ograničenja, te time poboljšati korisničko
iskustvo. Nedostatak ovakvog pristupa je veličina aplikacija, koja zbog pakiranja Node.js
okoline i libchromiumcontent biblioteke iznosi nešto više od 100 MB (varira u nekoliko
megabajta ovisno o platformi) za osnovnu praznu aplikaciju. Osim toga, razvojni okvir je
još uvijek nestabilan, odnosno njegovo ažuriranje na novije verzije može uzrokovati
neočekivana ponašanja izgrađene aplikacije. Razvojni okvir nije dugo na tržištu, zbog čega
je zajednica programera koja ga koristi (engl. community) mala, što otežava pronalazak
odgovora na pogreške koje se javljaju prilikom razvoja.
Gledano sa aspekta težine razvoja aplikacije u odnosu na druge tehnologije (kao na
primjer Java), razvoj desktop aplikacije pomoću Electron razvojnog okvira je lakši ukoliko
programer ima veće znanje korištenja web tehnologija u odnosu druge programske jezike i
tehnologije za razvoj desktop aplikacija, kao što je Java. Vrijedi i obratno, odnosno
8 Continuous Integration – praksa spajanja radnih kopija koda različitih programera u zajednički sustav radi
prevencije nastajanja problema prilikom integracije koda iz više izvora
12
Electron ponajprije približava razvoj višeplatformskih desktop aplikacija postojećim
programerima web aplikacija i rješenja.
2.4. Primjeri poznatijih aplikacija
Electron je obećavajuća tehnologija, a tome u prilog idu i već brojne komercijalne
aplikacije i aplikacije otvorenog koda koje se nalaze na tržištu. Neke od popularnijih su
Slack ( aplikacija za komunikaciju, pogodna za kompanije), Microsoft Visual Studio Code (
kod editor), Atom ( tekstualni editor), Pixate ( Google-ov alat za web dizajnere ), Wagon (
komercijalni univerzalni SQL editor ), Nylas N1 ( open-source mail klijent ), WordPress
(desktop aplikacija za istoimeni servis) i drugi.
13
3. Metodologija razvoja na projektu otvorenog
koda
Softver otvorenog koda (engl. Open-source software) je termin koji opisuje softver čiji
je izvorni kod javno dostupan (otvoren). Izvorni kod je javno dostupan zahvaljujući jednoj
od open-source licenci kojom vlasnik (odnosno imatelj prava) izvornog koda daje bilo
kojoj trećoj osobi prava na pregled, korištenje, izmjene i daljnju distribuciju koda. Postoji
više različitih modaliteta open-source licenci, a neke od poznatijih su GNU General Public
License (koja zahtijeva da promjene i redistribucije programa zadržavaju istu licencu),
BSD licenca (omogućava promjenu licence izmijenjenog koda), MIT licenca i druge. [16]
Sqlectron je primjer projekta otvorenog koda. Radi se o aplikaciji za upravljanje
relacijskim bazama podataka, čiji je izvorni kod javno dostupan na web servisu GitHub
pod MIT licencom, što znači da treća osoba može koristiti, kopirati, izmjenjivati i
redistribuirati softver bez ograničenja uz uvjet da uključi ovu licencu u sve kopije ili
dijelove softvera. Više o samoj aplikaciji u poglavlju 4. U nastavku ovog poglavlja opisan
je način kolaboracije i rada na projektu otvorenog koda, koji je ujedno bio i praksa
prilikom rada na Sqlectron projektu.
3.1. Kolaboracija na projektu otvorenog koda pomoću
Gita
Prilikom rada na projektu otvorenog koda, bitno je imati transparentan tijek rada
(engl. Workflow) kako ne bi došlo do prelaženja preko izmjena koje su drugi korisnici
napravili. To omogućuju sustavi za upravljanje verzijama projekta (engl. Version Control
System). Git je jedan od najčešće korištenih sustava koji omogućuje distribuirano
upravljanje verzijama. [17] Kod distribuiranog pristupa upravljanja verzijama svaki
programer radi direktno na svome lokalnom repozitoriju, dok se promjene između
repozitorija izmjenjuju zasebnim korakom. Konkretno, prilikom rada na projektu otvoreno
koda, svaki prinosnik (engl. contributor) projektu ima vlastitu verziju glavnog repozitorija
na koju šalje vlastite izmjene. Ukoliko drugi korisnici žele da se njihove promjene povuku
na glavni repozitorij, rade to pomoću posebnog zahtjeva. Izmjene na glavnom repozitoriju
može raditi (i prihvaćati) samo osoba zadužena za održavanje projekta (engl. Project
maintainer). Na taj način je omogućeno vlasniku glavnog repozitorija prihvaćanje i
14
povlačenje promjena bilo kojeg korisnika, bez da mu daje prava za pisanje po glavnom
(službenom) repozitoriju. Opisani način rada u literaturi se naziva Forking Workflow. [18]
3.1.1. Fork repozitorija
Ukoliko korisnik nema prava za pisanje na repozitorij otvorenog koda čiji izvorni
kod želi izmijeniti, potrebno je napraviti fork 9 repozitorija. Fork repozitorija je kopija
službenog (glavnog) repozitorija na serveru pod vlastitim korisničkim računom (ukoliko
ranije nije, korisnik treba napraviti račun na servisu gdje se nalazi službeni repozitorij, npr.
GitHub). Takav kopirani repozitorij služi kao osobni javni repozitorij na koji niti jedna
druga osoba ne može stavljati izmjene, ali ih može povlačiti. [18]
Kako bi se povukao sadržaj novostvorenog fork-anog repozitorija na lokalni stroj,
potrebno je pomoću git alata u naredbenom retku izvršiti git clone <repozitorij> .
Moguće je navesti ime direktorija, nakon imena repozitorija, ukoliko se željeni odredišni
direktorij razlikuje od onog u kojem je naredbeni redak pozicioniran.
Promatrajući sa aspekta korisnika, u kontekstu upravljanja izvornim kodom, lokalni
repozitorij je u odnosu na udaljeni repozitorij nizvodni (engl. downstream), jer podaci
putuju od udaljenog prema lokalnom repozitoriju. Suprotno, u odnosu na lokalni
repozitorij, udaljeni repozitorij je uzvodni (engl. upstream), budući da (sa pogleda
korisnika) podaci putuju od lokalnog prema udaljenom repozitoriju. Stoga, kako bi mogli
dohvaćati promjene sa originalnog udaljenog repozitorija, potrebno je povezati originalni
(službeni) repozitorij na serveru sa lokalnim konfigurirajući upstream lokalnog repozitorija
na originalni repozitorij.
git remote add upstream https://github.com/ sqlectron/sqlectron-gui.git
Ako se sada pokrene naredba git remote –v, kao vrijednost origin stajati će fork-ani
repozitorij, a kao vrijednost upstream originalni (glavni) repozitorij. Konfiguracijom
origin i upstream varijabli, omogućeno je slanje promjena na fork-ani repozitorij i
dohvaćanje promjena sa službenog repozitorija.
3.1.2. Izmjena izvornog koda
Nakon kreiranja vlastitog fork-a i povlačenja istog na lokalno računalno, nije
preporučljivo direktno krenuti sa izmjenama u kodu. Prije samog izmjenjivanja, odnosno
pisanja novog koda, preporučljivo je napraviti novu granu (engl. branch) unutar
9 Nema pravog prijevoda na hrvatski, http://wiki.open.hr/wiki/Fork
15
repozitorija. Glavna grana lokalnog repozitorija, odnosno master branch, treba služiti
isključivo za povlačenje promjena sa glavne grane službenog repozitorija (upstream
master branch). Razlog tome je izbjegavanje problema oko konflikata (čije razrješavanje
stvara novi zapis u povijesti) prilikom sinkronizacije lokalne master grane i one sa
službenog repozitorija ukoliko je lokalni master u međuvremenu doživio izmjene. [19]
Nova grana, odnosno branch, se stvara sljedećom naredbom u naredbenom retku:
git checkout –b semantičko-ime-grane
Granu treba nazvati tako da imenom opisuje vrstu promjene o kojoj se radi.
Ukoliko se izmjene odnose na rješavanje nekog konkretnog problema u softveru za koji
postoji otvorena tema na GitHub-u, poželjno je ispred imena grane staviti identifikator
teme (troznamenkasti broj). GitHub će prilikom spajanja grane u glavni repozitorij
automatski prepoznati temu i zatvoriti je. Isto tako, ukoliko se radi o novoj funkcionalnosti
u softveru, poželjno je dodati prefiks „feature/“.
Nakon izvođenja gore navedene naredbe, git je pozicioniran u novostvorenoj grani
i mogu se početi raditi izmjene u izvornom kodu. Prilikom dodavanja novih izmjena, treba
voditi računa o ne rušenju postojećih funkcionalnosti. Najčešće projekti otvorenog koda
sadrže jedinične testove (engl. Unit tests) i objašnjenje kako ih pokrenuti. Dodavanjem
svake nove funkcionalnosti potrebno je napisati barem jedan (ili više) jediničnih testova.
Nakon napravljene željene izmjene i testiranja iste, slijedi spremanje promjene u fork-ani
repozitorij. Naredbama:
git add <ime datoteke ili datoteka koje su izmjenjene>
git commit –m „<poruka koja opisuje commit>“
Radi se snimka stanja promijenjenih datoteka, odnosno izvršava se promjena (engl. commit
change) i stvara se novi zapis u povijesti repozitorija koji se naziva commit. Commit (hrv.
izvršiti, obvezati) bi trebao biti atomaran (engl. atomic) i ne bi smio sadržavati više
različitih, djeljivih, izmjena. Na primjer, ukoliko se izmjenama riješe dva odvojena
problema (čiji je kod odijeljen), trebaju se napraviti dva različita commit-a. Naredbom git
add odlučujemo koje datoteke će se dodati u idući commit. Za dodavanje samo dijela
izmjena iz neke datoteke moguće je koristiti interaktivni način pomoću zastavice --patch
ili kraće -p. Za uklanjanje datoteke iz stanja izmjena pripremljenih za commit, koristi se
naredba git reset HEAD <ime datoteke> . Datoteka će ostati u stanju promjena koje je
16
korisnik napravio, ali neće biti uključena u idući commit. Pregled datoteka koje će biti
uključene u idući commit moguć je pomoću naredbe git status.
Poruka koja se piše prilikom stvaranja commit-a, navodi se u navodnicima nakon
zastavice -m i treba ukratko objasniti izmjenu koju commit radi. Prvi red poruke treba imati
maksimalno 72 znaka i ne sadržavati točku na kraju. Duži opis commit-a, ukoliko je
potreban, navodi se nakon prvog retka odvojen sa jednim praznim retkom. [19]
Nakon stvaranja novog commit-a, ili više njih, promjene se šalju i snimaju na
udaljeni fork-ani repozitorij pomoću:
git push origin ime-grane-na-kojoj-se-izmjene-nalaze
Na taj način se osvježava osobni javni repozitorij sa napravljenim izmjenama. Ukoliko
ranije nije postojala, na udaljenom repozitoriju će se stvoriti i nova grana koju je korisnik
lokalno definirano za rad. Poslane izmjene se neće nalaziti u grani master, već u grani koja
se definira kao argument u git push naredbi. Nije nužno potrebno raditi git push poslije
svakog commit-a, ali je preporučljivo, kako bi izmjene odmah bile javno dostupne.
3.1.3. Zahtjev za povlačenje promjena na službeni repozitorij
Kako bi željene izmjene bile pripojene (engl. merged) službenom (glavnom)
repozitoriju koji je prvotno fork-an, potrebno je napraviti zahtjev za povlačenje promjena
na službeni repozitorij. Zahtjev za povlačenjem promjena na službeni repozitorij naziva se
Pull Request. Prije samog pull request-a, potrebno je povući sve izmjene koje su se
dogodile u međuvremenu na master grani službenog repozitorija, kako bi se razriješili
mogući konflikti u kodu. Jedan način za to je koristeći git fetch i git rebase instrukcije:
git fetch upstream/master
git rebase upstream/master
Prva naredba dohvaća sve promjene (commit-ove) sa master grane službenog
repozitorija. Druga naredba preuzima povijest (svi commit-ovi) master grane službenog
repozitorija kao vlastitu i ponovno aplicira sve commit-ove (izmjene) koji su prethodno bili
napravljeni na toj grani, a ne postoje u master grani službenog repozitorija. Efektivno,
preuzima se trenutno stanje master grane službenog repozitorija i na vrh tog stanja se
iznova apliciraju sve prethodno načinje promjene, čime nove promjene imaju prednost nad
starim stanjem koda. Tim postupkom se u povijesti ne stvara novi commit za rješavanje
konflikata, jer se nove izmjene apliciraju nad najnovijom slikom stanja master grane. S
17
druge strane, na ovaj način se mijenja povijest lokalnog repozitorija, budući da se stvaraju
novi commit-ovi jednaki onima ranije napravljenima na radnoj grani lokalnog repozitorija.
Kako bi se nove promjene primijenile na udaljeni fork-ani repozitorij, potrebno je izvršiti
naredbu:
git push --force
Zastavica --force prisiljava git da izmjeni povijest na udaljenom repozitoriju, tako
što povijest repozitorija koji se šalje ima prednost. Budući da mijenja povijest na
udaljenom repozitoriju, nikako nije preporučljivo ovu naredbu koristiti na master grani
repozitorija na kojem radi više korisnika, jer će izazvati daljnje konflikte i lokalni
repozitoriji ostalih korisnika više neće biti sinkronizirani sa glavnim. Mijenjanje povijesti u
radnoj grani na fork-anom repozitoriju nije problem, jer je drugi korisnici ne koriste i
commit-ovi iz njene povijesti će biti aktualni u master grani službenog repozitorija tek
nakon prihvaćanja pull request-a.
Drugi način dohvaćanja najnovijeg stanja master grane službenog repozitorija je
koristeći naredbu:
git pull upstream/master
Naredba dohvaća sve promjene i međusobno spaja dvije grane, lokalnu u kojoj je
git pozicioniran i onu koja se dohvaća pomoću git pull naredbe. Ukoliko postoje, git
upozorava korisnika na konflikte i traži ga da ih riješit. Nakon ručnog rješavanja konflikta
kroz neki od tekst editora i odlučivanja koja promjena ima prednost, potrebno je napraviti
novi commit kako bi git znao koju verziju datoteke koristiti. Nedostatak ovakve metode je
stvaranje dodatnog commit-a koji će biti vidljiv u službenom repozitoriju nakon
prihvaćanja zahtjeva za povlačenjem izmjena, čime povijest službenog repozitorija postaje
manje čista.
Nakon povlačenja aktualnog stanja master grane službenog repozitorija i ponovnog
testiranja novih promjena, moguće je napraviti zahtjev za povlačenje izmjena na službeni
repozitorij, odnosno pull request. Na svim većim servisima (GitHub, Bitbucket) koji
podržavaju kolaboraciju pomoću git sustava, postoji gumb kojim se stvara novi pull
request. Najčešće se gumb nalazi ponuđen kada se unutar servisa pozicionira na službeni
repozitorij ili radnu granu na fork-anom repozitoriju. Pritiskom na opciju, otvara se nova
stranica gdje je potrebno odabrati granu koja se želi pripojiti i podrobnije objasniti što je
18
napravljeno. Ukoliko postoje posebni zahtjevi kako opisati pull request definiran u datoteci
CONTRIBUTING.md službenog repozitorija, poželjno je toga se pridržavati.
Nakon kreiranja pull request-a, osoba (ili više njih) zadužena za održavanje
repozitorija odlučuje hoće li prihvatiti, odbiti i doraditi zahtjev. Svi commit-ovi koji se u
međuvremenu pošalju na fork-ani repozitorij na granu koja je uključena u pull request, biti
će dio pull request-a.
Prihvaćanjem pull request-a, novi commit-ovi iz odabrane grane se pripajaju master
grani službenog repozitorija. Osoba koja je zatražila pull request postaje prinosnik (engl.
contributor) projektu i dobiva javnu referencu na servisu na kojem se repozitorij nalazi.
3.1.4. Sinkroniziranje repozitorija
Nakon što je pull request prihvaćen, potrebno je sinkronizirati lokalni i udaljeni
fork-ani repozitorij za daljnji rad na istom projektu. Prvo, potrebno je pozicionirati se na
lokalnu master granu, jer nju treba sinkronizirati s master granom službenog repozitorija:
git checkout master
Drugo, potrebno je sa službenog repozitorija dohvatiti objekte (commit-ovi, oznake, grane)
koji ne postoje u trenutnom stanju lokalnog repozitorija:
git fetch upstream
Nakon toga, na master granu lokalnog repozitorija aplicira se povijest dohvaćene master
grane službenog repozitorija:
git rebase upstream/master
Razlika u odnosu na postupak pripreme pull request-a je što ovdje ne postoje novi
commit-ovi na master grani (slijedeći pravilo da se promjene ne rade direktno na master
grani). Stoga će u ovom slučaju git efektivno samo dodati povijest koja se nalazila u
master grani službenog repozitorija. Naposljetku, promjene se šalju na fork-ani repozitorij
na serveru:
git push origin --follow-tags
Sve promjene koje su se dogodile u međuvremenu na službenom repozitoriju šalju se na
fork-ani repozitorij. Grana master fork-anog repozitorija time je u sinkronizaciji sa granom
master službenog repozitorija. Zastavica --follow-tags je opcionalna i služi slanju oznaka
(engl. tags) na fork-ani repozitorij.
19
Također, osim sinkronizacije repozitorija sa službenim, korisno je obrisati granu na
kojoj se više ne radi, a čije su promjene pripojene kroz pull request u službeni repozitorij.
Brisanje grane koja više nije potrebna lokalno i na udaljenom fork-anom repozitoriju
izvodi se pomoću sljedećih naredbi:
git branch –d <ime-grane-koja-više-nije-potrebna>
git push origin :<ime-grane-koja-više-nije-potrebna>
Cijeli opisani proces kolaboracije od početne inicijalizacije radnog direktorija sve
do pull request-a i sinkronizacije repozitorija, opisan je dijagramom na slici 3.1. Dijagram
prikazuje način rada s git sustavom kroz vremenski tijek. Redoslijed izvršavanja naredbi
jednak je onom opisanom u ovome poglavlju. Kružići na grafu predstavljaju commit-ove,
dok pune linije bez strelice na vrhu predstavljaju grane repozitorija. Kružići koji imaju
crtkanu liniju označavaju kako su tek kasnije (nakon izvršavanja određene akcije) dodani u
povijest grane repozitorija, ali imaju istu vremensku oznaku trenutka u koji su stavljeni.
Naime, commit-ovi se u povijest grane smještaju prema vlastitoj vremenskoj oznaci
postanka. Ljubičasti kružići su dodani nakon dohvaćanja promjena sa glavne grane
službenog repozitorija. Zeleni kružići su dodani nakon prihvaćanja pull request-a. Crveni
križići predstavljaju brisanje grane. Zbog urednosti, nisu dodani kružići koji predstavljaju
commit-ove na master grani lokalnog i fork-anog repozitorija nakon sinkronizacije, već je
sinkronizacija označena sa plavim crtkanim linijama.
20
Slika 3.1: Dijagram „Forking workflow“ načina rada u projektu otvorenog koda
21
3.2. Integracija koda
Nakon zaprimanja pull request-a, osoba (ili više njih) zadužena za održavanje
službenog repozitorija odlučuje hoće li ga ili ne integrirati u master granu službenog
repozitorij. Ukoliko ne postoje konflikti unutar koda, moguće je sve promjene koje sadrži
pull request pregledati unutar grafičkog korisničkog sučelja servisa na kojem se repozitorij
nalazi i po potrebi komentirati. Ukoliko je sve u redu klikom na gumb moguće je prihvatiti
i pripojiti pull request. Time se cijeli kod iz pull request-a automatski pripaja kodu
službenog repozitorija, uz dodatan commit koji predstavlja pripajanje jedne grane u drugu.
Ipak, ukoliko postoje konflikti, administrator repozitorija mora ručno povući promjene u
pull request-u i ručno riješiti konflikt kao što je opisano u prethodnom poglavlju.
Dodatno, administrator repozitorija može povući promjene lokalno kako bi ih
doradio, ukoliko kod ne prolazi sve provjere, odnosno testove koji su definirani u
repozitoriju. Testiranje koda svakog novog pull request-a ili promjene na master grani
repozitorija provodi se pomoću CI servisa.
3.2.1. Korištenje CI servisa
Kontinuirana integracija (engl. Continuous Integration, CI) je praksa razvoja
softvera gdje prinosnici projekta integriraju svoj rad često, odnosno svaki prinosnik barem
jednom dnevno, što vodi k više integracija po danu. Svaka integracija praćena je
automatskim testiranje i izgradnjom (engl. build) kako bi se integracijske pogreške
prepoznale što je brže moguće. [20]
Kod projekata otvorenog koda, praksa kontinuirane integracije sprječava
mogućnost pojave pogreške u glavnoj grani repozitorija za koju se ne može istog trenutka
jednoznačno odrediti koja ju je promjena (commit) izazvala. CI servisi služe kao pomoć
prilikom integracije svake nove promjene u postojeći repozitorij koda tako što izvršavaju
automatska testiranja i automatsku izgradnja softvera prilikom otvaranja svakog novog pull
request-a (i dodatno nakon svakog idućeg commit-a u granu koja se želi pripojiti putem
istog), te nakon svake nove promjene (commit-a) u glavnoj grani repozitorija. Skripte za
obavljanje testova i izgradnju softvera definiraju se u konfiguracijskoj datoteci (najčešće u
YML formatu) prema specifikacijama za pojedini CI servis.
22
Poznatiji CI servisi (ujedno korišteni na Sqlectron projektu) su AppVeyor za
Windows platformu, te Travis CI za platforme bazirane na UNIX-u. Oba navedena servisa
su besplatna za projekte otvorenog koda.
3.3. Upravljanje verzijama i korištenje NPM sustava
Nakon promjene ili više njih na glavnoj grani repozitorija, potrebno je izdati novu
verziju softvera ili modula (ovisno što je produkt projekta) kako bi ga krajnji korisnici
mogli koristiti. Prilikom razvoja JavaScript modula, moguće je koristiti npm version
konzolni alat za lakše upravljanje verzijama (engl. Versioning) i automatsko izdavanje
modula na NPM sustav.
Prvo, potrebno je pozicionirati se u lokalni git repozitorij i dohvatiti zadnje promjene
pomoću git pull naredbe. Nakon toga izvršavanjem naredbe:
npm version <major|minor|patch>
Stvara se nova git oznaka (engl. tag) sa odgovarajućom verzijom i commit sa izmjenom
verzije u package.json datoteci. Vrijednost koja se navodi nakon naredbe npm version
označava inkrement broja verzije prema SemVer standardu. Broj verzije se sastoji od tri
broja odvojenih točkom, koji semantički označavaju verziju. Prvi broj naziva se major i
predstavlja veliku promjenu u programu koja nije kompatibilna s prijašnjom verzijom
modula. Drugi broj naziva se minor i predstavlja dodavanje nove funkcionalnosti na način
da je kompatibilna s prijašnjom major verzijom modula. Treći broj naziva se patch i
predstavlja manje promjene (popravke) koje su kompatibilne s prijašnjom verzijom
modula. Stoga, prilikom izdavanja nove verzije modula, potrebno je promijeniti broj
verzije prema semantici promjene. [21]
Osim navedenih imena verzija, moguće je koristiti i prepatch, preminor,
premajor, prerelease vrijednosti koje verziji modula dodaju dodatan identifikator
odvojen crticom od broja verzije. Tako označene verzije ukazuju kako modul nije stabilan i
kako postoji mogućnost da ne zadovoljava kompatibilnost koja je označena brojem verzije.
Idući korak je slanje novih promjena na udaljeni git repozitorij (budući da postoje
novi commit i novi tag) i izdavanje novog modula na NPM sustav. Slanjem promjena na
udaljeni git repozitorij, na git servisu se također stvara novo izdanje:
git push --follow-tags
23
npm publish
Nakon izvršavanja prethodnih naredbi, potrebno je urediti obavijest o izdanju (engl.
release notes) na git servisu na kojemu se repozitorij nalazi. Obavijest o izdanju sadrži
popis promjena koje su uključene novom verzijom modula.
24
4. Aplikacija Sqlectron
Sqlectron je projekt otvorenog koda čiji je produkt višeplatformska univerzalna
aplikacija za upravljanje relacijskim bazama podataka. Prvo izdanje aplikacija je doživjela
10. studenog 2015. godine. Pokretači i vlasnici repozitorija su Max Claus Nunes, Vinícius
Krolow i Eduardo Nunes među kojima je prvo navedeni najaktivniji. Aplikacija je izrađena
pomoću razvojnog okvira Electron i web tehnologija. Trenutna verzija 1.10.0 ima podršku
za PostgreSQL, MySQL i Microsoft SQL Server baze podataka. Aplikacija se sastoji od
dva prozora, prvog u kojem korisnik definira vezu na bazu podataka i drugog koji se
prikazuje korisniku nakon uspješnog spajanja na bazu podataka i služi za rad s bazom.
U sklopu ovog rada, implementirane su nove i ispravljane stare funkcionalnosti po
uzoru na druge desktop aplikacije za rad sa relacijskim bazama podataka. Poglavlje opisuje
arhitekturu projekta, važnije biblioteke i tehnologije korištene na projektu, te
funkcionalnosti koje su implementirane u sklopu diplomskog rada.
4.1. Arhitektura projekta
Projekt je podijeljen na dva dijela, odnosno repozitorija:
sqlectron-core
sqlectron-gui
Sqlectron-core je modul koji implementira aplikacijsko programsko sučelje prema
različitim sustavima relacijskih baza podataka (engl. Relational database system). [22]
Ponaša se kao pozadinski sustav, odnosno back-end aplikacije. Aplikacijsko programsko
sučelje omogućuje klijentu spajanje na bazu podataka, pregled tablica, pogleda (engl.
view), procedura odnosno funkcija, izvršavanje upita, dohvat ključeva tablice, dohvat
različitih SQL skripta i drugo. Dostupne metode aplikacijskog sučelja prikazane su na slici
4.1. Svaki sustav relacijskih baza podataka implementira sučelje definirano u client.js
datoteci koje je izloženo prema van. Na taj način klijent modul koristi kao zatvorenu
kutiju, pozivajući iste metode neovisno o serveru baze podataka koji koristi. Dodavanje
podrške za nove sustave baze podataka je jednostavno i neovisno, budući da je samo
potrebno stvoriti novu datoteku (u src/db/clients/) koja implementira sučelje pomoću
jednog od modula s NPM servisa, dodati novi sustav u dostupne klijente i pokrenuti
jedinične (engl. unit) testove. Promjene u ostalom dijelu izvornog koda nisu potrebne.
25
Slika 4.1: Javno aplikacijsko programsko sučelje sqlectron-core modula
Sqlectron-gui implementira korisničko grafičko sučelje aplikacije i koristi
sqlectron-core modul za rad sa relacijskim bazama podataka. [23] Budući da uključuje
sqlectron-core modul, izgradnjom izvornog koda sqlectron-gui repozitorija nastaje
cjelokupna aplikacija. Kako je aplikacija rađena uz pomoću Electron razvojnog okvira,
korisničko grafičko sučelje izrađeno je pomoću programskih tehnologija namijenjenih za
razvoj sučelja web aplikacija kao što su React i Redux. Svaki od dva prozora ima vlastiti
kontejner (engl. container) unutar kojeg je smješteno više react komponenti. Kontejneri
(također react komponenta), uz pomoć redux biblioteke, upravljaju globalnim stanjem
aplikacije i prosljeđuju podatke komponentama koje ih prikazuju ili se mijenjaju ovisno o
njima. Detaljnije o načinu rada ovih programskih tehnologija u idućem poglavlju.
26
4.2. Programske tehnologije korištene na projektu
Uz razvojni okvir Electron koji je opisan ranije u poglavlju 2, projekt je izrađen
koristeći razne programske web tehnologije i biblioteke. U nastavku slijedi pregled
najvažnijih.
4.2.1. ECMAScript 2015 standard i Babel prevodioc
ECMAScript 2015, poznat i kao ECMAScript 6, je najnovija verzija ECMAScript
standarda. Ratificiran je u lipnju 2015. godine od strane tijela ECMA International.
Standard predstavlja značajan napredak JavaScript jezika i gotovo je u potpunosti
implementiran u najnovijem Chrome pregledniku i Nodejs izvršnoj okolini. [24] Neke od
novosti koje standard donosi su arrow funkcije, promise (objekt korišten za asinkrono
programiranje), razredi, let i const tipovi i drugo. [25]
Ipak, kako nisu sve značajke implementirane (ili nisu ranije bile), na projektu je
korišten Babel prevodioc koji prevodi kod pisan prema ECMAScript 6 standardu u
ECMAScript 5 standard koji je razumljiv izvršnoj okolini. Osim toga, podržava
funkcionalnosti jezika koje još nisu u ECMAScript 6 standardu kao async…await funkcija,
koje su vrlo često korištene na ovome projektu umjesto standardnog korištenja promise
objekta. Radi se o tzv. sintaksnom šećeru (engl. syntactic sugar) koji omogućuje
preglednije pisanje koda koji zahtjeva čekanje na izvršenje asinkrone funkcije.
4.2.2. React i Redux biblioteke
React je JavaScript biblioteka za izgradnju korisničkog sučelja bazirana na
komponentama. Omogućava razvoj interaktivnog sučelja koje se samo djelomično
osvježava prilikom dolaska novih podataka, ovisno o komponentama na koje utječu, što
sučelje čini vrlo efikasnim. Izgradnja sučelja se bazira na glavnom razredu
React.Component pomoću kojeg se stvaraju proizvoljne komponente koje imaju vlastito
stanje (kojim mogu upravljati), svojstva (koja im se prosljeđuju) i metodu render() unutar
koje se definira kako će se komponenta prikazati. Stanje komponente je moguće mijenjati
pozivom metode setState({object}) bilo gdje u komponenti osim u render() i
componentWillUpdate() metodama. Metoda render() se poziva nakon svake promjene
stanja komponente ili primanja novih podataka, čime se postiže interaktivnost sučelja.
Osim navedenog, svaka komponenta ima metode životnog ciklusa (engl. Lifecycle
methods) koje se izvršavaju u specifičnim trenucima životnog ciklusa komponente. Metode
27
životnog ciklusa omogućuju upravljanje komponentom ovisno o trenutnom stanju
komponente ili novo primljenim podacima. [26]
Redux je biblioteka za upravljanje globalnim stanjem JavaScript aplikacije.
Upravljanje globalnim stanjem aplikacije je bitno radi postizanja konzistentnog ponašanja
aplikacije. Bazira se na principu jednog izvora istine, objekta koji predstavlja sveukupno
stanje aplikacije i kojeg nije moguće direktno mijenjati. Kako bi promijenili stanje
aplikacije potrebno je napraviti akciju (engl. Action). Akcija, odnosno action, je u Reduxu
objekt koji sadrži informacije koje se žele poslati iz aplikacije u jedinstveno skladište,
odnosno store. Akcija mora sadržavati svojstvo type (najčešće tipa string) koje govori
reducer-u (hrv. redukcija) o kojem se tipu akcije radi. Reducer uzima akciju i prethodno
stanje aplikacije, te prema tipu akcije definira kako točno treba promijeniti stanje. Stanje
aplikacije čuva se u jedinstvenom skladištu, odnosno store-u. Store je objekt koji čuva
stanje aplikacije i omogućava čitanje stanja pomoću getState() metode. Direktno
mijenjanje stanja nije moguće, već isključivo slanjem akcije pomoću dispatch(action)
metode, čime se pokreće upravo opisani mehanizam promjene stanja aplikacije. [27]
React-Redux je modul dostupan na NPM sustavu koji povezuje dvije navedene
biblioteke. [28] Vezivanje React-a i Redux-a zasniva se na ideji odvajanja prezentacijske i
kontejnerske (React) komponente. Kontejnerska komponenta služi dohvaćanju podataka i
mijenjanju stanja aplikacije pomoću Redux-a. Unutar kontejnerske komponente nalazi se
sva logika za čitanje podataka iz Redux stanja i mijenjanje stanja pomoću slanja novih
akcija. Sadrži prezentacijske komponente kojima prosljeđuje potrebne podatke i funkcije
kao svojstva komponente. Prezentacijske komponente služe prikazu i ne znaju za Redux
stanje. Osvježavaju se primanjem novih podataka iz kontejnerske komponente i nikada
samostalno ne šalju akcije u Redux, već pozivaju metode koje su dobile iz kontejnerske
komponente. Treba napomenuti kako prezentacijske komponente mogu sadržavati druge
prezentacijske komponente unutar sebe, ali nikako ne smiju manipulirati s Redux stanjem,
već u tom slučaju isključivo mogu dalje prosljeđivati podatke (ili dio njih) koji su njima
već proslijeđeni. [27] U tablici 4.1 prikazana je razlika između prezentacijske i
kontejnerske komponente. Korisničko sučelje Sqlectron aplikacije izrađeno je slijedeći
ovakvu praksu, tako što svaki prozor ima jedinstven kontejner.
28
Tablica 4.1: Razlika između kontejnerske i prezentacijske komponente10
Kontejnerska komponenta Prezentacijska komponenta
Svrha Logika Prikaz
Zna za Redux Da Ne
Čitanje
podataka
Spajanje svojstava komponente
na Redux stanje
Dobiveni od vanjske komponente
kao atributi
Mijenjanje
podataka
Slanje Redux akcija pomoću
dispatch(action) metode
Pozivanje funkcije dobivene kao
atribut iz vanjske komponente
Jednostavan primjer zajedničkog korištenja React i Redux biblioteka je izgradnja
liste bilježaka. Lista je u tom slučaju kontejnerska komponenta, koja sadrži bilješke i polje
za dodavanje novih bilješki. Bilješka je prezentacijska komponenta, koja od kontejnerske
komponente prima tekst (koji treba prikazati) i funkciju koja će se izvesti prilikom pritiska
na bilješku (npr. tekst će se prekrižiti). Lista, kao kontejnerska komponenta, spaja se na
Redux skladište (koje sadrži jedinstveno stanje aplikacije) pomoću connect metode React-
Redux modula, čime ima pristup pregledu stanja. Kako bi se dodala nova bilješka u listu, u
pozadini je potrebno napraviti novu akciju, odnosno poslati pomoću redux dispatch
metode objekt koji sadrži tip (ime) akcije i podatke koji se žele dodati (u našem slučaju
tekst bilješke):
dispatch({ type: 'DODAJ-BILJESKU', tekstBiljeske});
Nakon toga, potrebno je napisati pripadajući reduktor (engl. reducer) koji će
promijeniti stanje prema primljenoj akciji. Reduktor čita trenutno stanje i primljenu akciju,
te ovisno o tipu akcije mijenja stanje. U našem slučaju će reduktor na kraj polja elemenata
state.biljeske dodati novu bilješku. Promjenom stanja, kontejnerska komponenta postaje
svjesna promjene, ponovno se pokreće render() metoda te komponente i stvara se nova
bilješka kojoj kontejnerska komponenta kao atribut predaje upravo dodani tekst bilješke.
10
Prema uzoru na tablicu iz Redux dokumentacije [27]
29
4.2.3. JointJS biblioteka
JointJS je JavaScript biblioteka otvorenog koda za izradu dijagrama unutar web
preglednika. Dijagram sadrži elemente i poveznice (engl. links) između elemenata, a
predstavljen je modelom koji se inicijalizira iz razreda joint.dia.Graph. Modelu se zatim
dodaju elementi (objekti iz razreda joint.dia.Element) i poveznice (objekti iz razreda
joint.dia.Link). Kako bi dijagram bio prikazan, model se dodaje pogledu
(joint.dia.Paper) koji dijagram prikazuje unutar svg elementa. [29]
JointJS dopušta izgradnju vlastitih elemenata iz već postojećih jednostavnim
proširivanjem (engl. extend) jednog od elemenata iz objekta joint.shapes.basic.
Dodatno, moguće je kreirati vlastite elemente koristeći HTML za definiciju izgleda
elementa. Uz proširivanje postojećeg elementa, u tom slučaju je potrebno napraviti i
vlastiti pogled (engl. view) elementa proširivanjem joint.dia.ElementView. Treba
napomenuti kako se ovdje ne radi o prikazu HTML elemenata unutar svg-a, već se stvara
HTML blok koji će se prikazivati točno iznad prozirnog elementa ekvivalente veličine
pozicioniranog unutar svg-a. Stoga, ukoliko je potrebno unutar aplikacije dijagram koristiti
kao svg, umjesto ovog pristupa preporučljivo je elemente dijagrama izgraditi koristeći
izvorne svg elemente.
4.3. Pregled značajki poznatijih desktop aplikacija za rad
s bazama podataka
Funkcionalnosti razvijene u sklopu ovog rada rađene su po uzoru na značajke
poznatijih desktop aplikacija za rad s relacijskim bazama podataka kao što su MySQL
Workbench, pgAdmin III i SQL Server Managment Studio. Navedene aplikacije
specijalizirane su za rad sa MySQL, PostgreSQL i Microsoft SQL Server sustavima
relacijskih baza podataka (redom kojim su navedene), odnosno sustavima koji su podržani
unutar Sqlectron aplikacije. U nastavku slijedi pregled važnijih značajki navedenih alata
koje su nedostajale Sqlectron aplikaciji (verzija 1.5.0) prije početka rada na projektu, a
implementirane su u sklopu rada.
Svaki od navedenih alata sadrži u lijevom dijelu aplikacije stablo sa strukturom
baze podataka. Stablo omogućuje korisniku pregled postojećih baza na serveru i njihove
strukture. Razlike između alata postoje u strukturi stabla, ali im je funkcionalnost jednaka.
Tako su na primjer okidači (engl. triggers) u MySQL Workbench i SQL Server Managment
30
Studio alatima navedeni kao pod element tablica, dok se u pgAdmin III nalaze unutar
zasebnog čvora u istoj razini s tablicama. Osim pregleda sadržaja, stablo omogućuje
jednostavno spajanje na određenu bazu podataka i dodatne opcije za rad nad objektima
baze podataka.
Jedna od takvih opcija je automatsko generiranje SQL skripti temeljenih na
strukturi objekta baze podataka. Skripte su u svakom od alata dostupne unutar padajućeg
izbornika koji se otvara prilikom desnog klika na objekt baze podataka. Objekt može biti
tablica, pogled ili rutina (procedura i/ili funkcija, ovisno što sustav baze podataka
podržava). Primjer skripte može biti SQL skripta za kreiranje objekta (CREATE upit),
ubacivanje novih zapisa u tablicu (INSERT upit) i drugo.
Automatsko završavanje upita dostupno je na sva tri alata. Praksa navedenih alata
je da se na mjestima gdje se navode objekti iz baze podataka (npr. nakon „SELECT *
FROM“ teksta) automatsko završavanje upita uključuje istodobnim pritiskom tipki control
i space (kratica na tipkovnici ctrl+space). Pritiskom tipki otvara se padajući izbornik gdje
je moguće odabrati objekt, u našem primjeru tablicu, koji se želi iskoristiti. Osim ručno
pokrenutog automatskog završavanja, alati MySQL Workbench i SQL Server Studio
omogućavaju automatsku dopunu SQL koda i prijavljivanje sintaktičkih pogrešaka prije
izvođena upita.
Alati MySQL Workbench i SQL Server Studio omogućavaju automatsko generiranje
dijagrama iz strukture baze podataka. Opcija generiranja dijagrama u SQL Server Studio-u
dostupna je unutar padajućeg izbornika mape „Database Diagrams“ koju sadrži svaka
baza podataka unutar svog stabla. S druge strane, ista opcija u MySQL Workbench-u
dostupna je na početnom ekranu aplikacije, nakon čega se korisnika vodi kroz nekoliko
koraka unutar kojih definira, među ostalim, konekciju i bazu podataka nad kojom želi
stvoriti dijagram. Dijagram je moguće stvoriti i unutar pgAdmin III pomoću Graphic
Query Builder alata. Za razliku od dva ranije navedena alata, ovdje generiranje dijagrama
nije automatsko i nije moguće spremiti dijagram u format kojim bi se mogao ponovno
otvoriti i manipulirati. Uz automatsku izradu dijagrama, SQL Server Studio sadrži brojne
vizualizacije podataka poput izvješća o zauzeću diska, statistici korištenja indeksa i druge.
31
4.4. Implementirane funkcionalnosti
Slijedi opis implementiranih funkcionalnosti slijedom kojim su implementirane
unutar višeplatformske univerzalne desktop aplikacije za rad s bazama podataka Sqlectron.
4.4.1. Pregled strukture baze podataka
Prvotno, Sqlectron je omogućavao pregled baza podataka i pripadnih tablica u
izborniku na lijevoj strani aplikacije. Pregled kompletne strukture baze podataka jedna je
od osnovnih značajki implementirana u svim drugim klijentima za rad relacijskim bazama
podataka, stoga je logično bilo implementirati istu funkcionalnost i u Sqlectron.
Izgled izbornika, odnosno stabla, koji omogućuje pregled strukture baze podataka
napravljen je po uzoru na isti izbornik u MySQL Workbench-u. Na slici 4.2 prikazan je
izbornik (stablo) za pregled strukture baze podataka u Sqlectron aplikaciji.
Slika 4.2: Pregled strukture podataka u Sqlectron aplikaciji
32
Svaka baza podataka (označena sa ikonom baze podataka lijevo od imena) sadrži
izbornik sa čvorovima „Tables“, „Views“, „Functions“ i „Procedures“, nevezano o kojem
se serveru baze podataka radi. Klikom na svaki od čvorova otvara se pod izbornik s popis
pripadajućih objekata u bazi podataka. Ukoliko sustav relacijske baze podataka ne
podržava neki tip objekta, kao na primjer PostgreSQL ugrađene procedure, unutar čvora
„Procedures“ se jednostavno objekti ne će prikazivati već će se korisniku ispisati poruka
kako takvi objekti ne postoje u bazi podataka. Klikom na jednu od tablica otvara se novi
pod izbornik sa čvorovima „Columns“ i „Triggers“. „Columns“ čvor sadrži popis atributa
tablice i njihov tip, dok „Triggers“ čvor sadrži imena okidače definiranih nad
pripadajućom tablicom. Svaki od čvorova, odnosno pod izbornika, moguće je otvarati i
zatvarati klikom na ime čvora ili pripadajući ikonu pokraj imena.
Svaka od razina stabla je nova react komponenta, zbog čega je jednostavno
implementirati otvaranje i zatvaranje čvorova preko internog stanja komponente. Kada
čvor nije otvoren, komponente unutar njega se ne prikazuju. Klikom na otvaranje čvora,
mijenja se stanje komponente koje uzrokuje prikaz komponente iduće razine. Dodatno,
ovakvim pristupom stanje svakog podizbornika (je li otvoren ili ne) pamti se i nakon
zatvaranja i ponovnog otvaranja čvora najviše razine.
Izmjena je uključivala i proširivanje aplikacijskog programskog sučelja sqlectorn-
core modula metodama za dohvaćanje objekata baze podataka, te atributa i okidača
pojedinih tablica.
4.4.2. Filtriranje objekata baze podataka
Objekte u ranije opisanom stablu moguće je filtrirati koristeći pretraživač koji se
nalazi ispod imena baze podataka. Upisivanjem u pretraživač filtriraju se svi objekti čiji su
pod izbornici otvoreni, uključujući tablice, poglede, funkcije i procedure, a koji sadrže
upisani niz u svome imenu. Služi prvenstveno jednostavnijem pretraživanju tablica unutar
baza podataka s velikim brojem tablica. Primjer filtriranja nad bazom podataka koja sadrži
oko 130 tablica prikazan je slikom 4.3.
33
Slika 4.3: Primjer filtriranja tablica baze podataka
4.4.3. Spajanje na server bez definiranja baze podataka
Sqlectron je prvotno, prilikom stvaranja konekcije, zahtijevao definiranje baze
podataka na koju se korisnik želi spojiti. Razlog takvom pristupu može se pronaći u
činjenici da je glavni prinosnik repozitoriju koristio aplikaciju za rad s PostgreSQL bazom
podataka koja zahtijeva definiranje baze podataka na koju se želi spojiti.
MySQL i SQL Server ne zahtijevaju definiranje baze podataka prilikom stvaranja
konekcije, stoga je pristup promijenjen kako bi se poboljšalo korisničko iskustvo.
Izmjenama u sqlectron-core i sqlectron-gui repozitorijima, uklonjena je verifikacija nad
poljem baze podataka (koja je postojala prilikom definiranja konekcije) i omogućeno
spajanje na server bez odabrane baze podataka. Problem sa PostgreSQL serverom je
riješen na način da se koristi zadana (engl. default) baza podataka „postgres“ u slučaju da
korisnik sam nije definirao ime baze podataka. Takav pristup koristi i pgAdmin III
aplikacija. Na slici 4.4 prikazano je uspješno spajanje, odnosno testiranje konekcije, bez
unaprijed definirane baze podataka.
34
Slika 4.4: Uspješno spajanje na MySQL server bez unaprijed definirane baze podataka
Nakon spajanja, korisnik se može spojiti na bilo koju bazu podataka dvostrukim
klikom na njeno ime u izborniku s lijeve strane prozora aplikacije.
4.4.4. Napredno uređivanje SQL programskog koda
Automatsko dopunjavanje SQL programskog koda, kao i automatsko dopunjavanje
imena objekata baze podataka postignuto je pomoću ugrađene funkcionalnosti Ace kod
editora korištenog na projektu. Prilikom stvaranja nove instance editora, svojstva
enableLiveAutocompletion i enableBasicAutocompletion se postavljaju na true vrijednost,
čime se uključuje stalno pokrenuto automatsko dopunjavanje i automatsko dopunjavanje
pokrenuto pomoću istovremenog pritiska tipki control i space. Lista riječi ponuđena
korisniku sadrži sve vrijednosti koje odgovaraju početnim upisanim znakovima i meta
podatak koji govori o kojem se tipu vrijednosti radi. Drugi riječima, automatsko
dopunjavanje ne uzima u obzir poziciju riječi unutar upita, već funkcionira kao globalni
rječnik. Ključne riječi SQL programskog koda automatski su ugrađene u kod editor, dok je
objekte baze podataka bilo potrebno ručno uključiti. Ova funkcionalnost dodana je uz
pomoć drugih prinosnika projektu. Na slici 4.5 prikazan je primjer automatske dopune
35
imena tablice iz baze podataka na koju je korisnik trenutno spojen. Kao što je vidljivo, uz
vrijednost naveden je i tip vrijednosti.
Slika 4.5: Automatska dopuna SQL upita
Osim automatske dopune SQL upita, zahvaljujući ostalim prinosnicima projekta,
dodane su i druge funkcionalnosti kao što je označavanje trenutne linije koda i izvršavanje
selektiranog upita.
4.4.5. Generiranje SQL skripti
Svakom od objekata baze podataka (tablice, pogledi, rutine) dodan je padajući
izbornik koji se otvara desnim klikom na ime objekta. Desnim klikom na tablicu otvara se
padajući izbornik sa opcijama za izvođenje upita za dohvat prvih 1000 zapisa i opcije za
automatsko generiranje SQL skripti vezanih za odabranu tablicu (slika 4.6).
Slika 4.6: Padajući izbornik otvara se desnim klikom na tablicu
Dostupne su skripte za CREATE, SELECT, INSERT, UPDATE i DELETE naredbe. Odabirom
jedne od ponuđenih skripti, osvježava se kod editor sa pripadnim SQL programskim
36
kodom skripte. Na slici 4.7 prikazan je primjer generirane CREATE naredbe nad tablicom iz
MySQL baze podataka.
Slika 4.7: Primjer generirane SQL skripte
Osim tablica, padajući izbornik imaju i pogledi i rutine, odnosno funkcije i
procedure. Za razliku od tablica, njihov izbornik sadrži samo opciju za dohvaćanje CREATE
naredbe kojom korisnik može vidjeti njihovu definiciju.
Dodavanje funkcionalnosti zahtijevalo je promjene u sqlectron-core modulu
proširivanjem aplikacijskog programskog sučelja sa novim metodama za generiranje i
dohvat SQL skripti. Svakoj naredbi dodana je pripadajuća metoda koja stvara generički
upit i vraća ga kao povratnu vrijednost. Dok je većinu skripti bilo trivijalno izgraditi
koristeći ugrađene procedure i funkcije samih sustava baza podataka, skriptu za kreiranje
tablice u PostgreSQL i SQL Server bazama podataka bilo je potrebno potpuno ručno
izgraditi koristeći složenije upite nad više sistemskih tablica. Promjene u sqlectron-gui
repozitoriju odnosile su se na dodavanje padajućeg izbornika objektima baze podataka i
pozivanje pripadajućih metoda iz sqlectron-core modula.
4.4.6. Vizualizacija strukture baze podataka
Kako bi omogućili korisniku vizualizaciju objekata baze podataka, dodana je
funkcionalnost automatskog generiranja dijagrama baze podataka. Opcija za stvaranje
dijagrama nalazi se u padajućem izborniku prilikom desnog klika na ime baze podatak u
lijevoj izborniku aplikacije. Pritiskom na opciju „Show Database Diagram“ otvara se
modalni prozor (engl. modal window) gdje se od korisnika traži da izabere tablice i
poglede koje želi uključiti u dijagram ili izabere već postojeći dijagram iz datotečnog
sustava (slika 4.8). Nakon odabira barem jedne tablice ili pogleda, korisniku se omogućuje
klik na gumb kojim se pokreće generiranje dijagrama.
37
Slika 4.8: Početni izgled modalnog prozora za prikaz dijagrama
Nakon odabira željenih tablica i pritiska na gumb „Generate diagram“, sadržaj
modalnog prozora zamjenjuje se porukom i animacijom koja govori korisniku kako se
dijagram generira. Naposljetku, nakon što je dijagram spreman, prikazuje se korisniku
unutar modalnog prozora. Na slici je 4.9 prikazan je primjer dijagrama koji uključuje sve
tablice sa slike 4.8.
Slika 4.9: Primjer automatski generiranog dijagrama jednostavne baze podataka
Dijagram se sastoji od tablica i poveznica između tablica. Svaka tablica sadrži
atribute. Primarni i strani ključevi tablice označeni su ikonom ključa (primarni žute boje,
strani crne). Poveznice služe prikazu referenci između tablica. Tablice je moguće
38
proizvoljno pomicati unutar tijela modalnog prozora, dok je poveznice moguće savijati na
proizvoljnim mjestima. Osim toga, vrhove poveznica moguće je pomicati oko bridova
tablice na koju pokazuju. Time je korisniku omogućeno da proizvoljno promjeni raspored
elemenata na grafu kako bi on bio što uredniji.
Dodatno, kako bi se korisniku omogućila brza i pregledna provjera referencijalnih
integriteta između tablica, dodana je mogućnost za dodavanje referenciranih tablica na
dijagram. Desnim klikom na tablicu, na dijagram se dodaju sve tablice na koje strani
ključevi odabrane tablice imaju reference. Poveznice između novo dodanih tablica i već
postojećih na dijagramu se također automatski ažuriraju.
Korisnik može spremiti dijagram za kasnije korištenje pomoću opcije „Save“ ili
izvesti (engl. export) dijagram u png ili jpeg format odabirom željene opcije u padajućem
izborniku „Export To“. Opcije perzistencije dijagram nalaze se na dnu modalnog prozora i
prikazane su na slici 4.10. Odabirom jedne od opcija otvara se dijalog domaćinskog
operacijskog sustava gdje je moguće odabrati željenu mapu i ime datoteke u koju se
dijagram želi spremiti.
Slika 4.10: Opcije perzistencije dijagrama
Opcija „Save“ sprema dijagram, odnosno sve elemente i njihove pozicije, u JSON
formatu. Tako spremljen dijagram moguće je ponovno otvoriti unutar aplikacije koristeći
opciju „Open diagram from file“ iz početnog modalnog prozora prikazanog na slici 4.8.
Korisnik dijagram otvoren iz ranije spremljene datoteke može ponovno koristiti, odnosno
može pomicati tablice i poveznice, te iznova spremiti dijagram ili ga izvesti u slikovni
formati. Izvozom datoteke u png ili jpeg format, dijagram se sprema kao statička slika i
nije ga moguće ponovno otvoriti unutar aplikacije.
Funkcionalnost je implementirana koristeći JavaScript biblioteku za izradu
dijagrama JointJS. Na dijagramu, tablice i atributi su elementi izvedeni iz bazičnog
joint.shapes.basic.Rect oblika biblioteke JointJS. Svaki element tablice ima ugrađene
39
elemente atributa koje sadrži. Izgled elemenata je definiran HTML-om, zbog čega nije
moguće dijagram izvesti u svg format. Razlog tome je način rada biblioteke JointJS opisan
u poglavlju 4.2.3. Ponašanje i upravljanje prikazom sadržaja modalnog prozora postignuto
je koristeći stanje komponente, budući da je modalni prozor (kao i cijelo sučelje) izveden
kao react komponenta.
4.4.7. Ostale izmjene i popravci pogrešaka u aplikaciji
Osim razvijanja novih funkcionalnosti aplikacije, u sklopu izrade rada napravljeni
su i popravci postojećih pogrešaka u aplikaciji, kao i manja poboljšanja. U nastavku su
navedeni su kronološki:
Popravak pogreške koja je uzrokovala nemogućnost spajanja nakon
prethodne neuspješne konekcije
Ispravno skaliranje editora unutar aplikacije nakon dodavanja više od 15
linija SQL programskog koda odjednom
Ispravak pogrešnog prikaza rezultata upita sa više od 15 atributa
Prikaz dugačkih znakovnih nizova u rezultatu po uzoru na druge slične
aplikacije
Mogućnost dodavanje višestrukih skripti u editor (ranije se editor
automatski osvježavao)
Dodavanje prečaca na tipkovnici za filtriranje baza podataka i objekata baza
podataka u lijevom izborniku aplikacije
4.5. Status projekta
Projekt u trenutku pisanja ovog rada, na sqlectron-gui repozitoriju, ima gotovo 500
poklonika, odnosno korisnika servisa GitHub koji su projekt označili sa zvjezdicom, i 27
pretplatnika koji primaju notifikacije o svim promjenama na repozitoriju. Osim toga, 40
korisnika je napravilo vlastiti fork repozitorija kako bi dalje razvijali vlastite
funkcionalnosti ili mijenjali postojeće, te predstavljaju potencijalne prinosnike projektu.
Prema grafovima na slici 4.11 vidljiva je povećana aktivnost na projektu u drugoj
polovici ove godine, odnosno u razdoblju izrade ovog rada. Prvi graf predstavlja broj
kontribucija, odnosno commit-ova na repozitoriju sqlectron-core, dok drugi graf
predstavlja broj commit-ova na repozitoriju sqlectron-gui Uzme li se u obzir kako je kraj
2015. godine tek početak ozbiljnijeg rada na projektu, i uključuje velik broj inicijalnih
40
commit-ova, te kako se u drugoj polovici 2016. godine broj poklonika poduplao, može se
zaključiti kako projekt u zadnjih par mjeseci doživljava porast aktivnosti.
Slika 4.11: Grafovi kontribucija na sqlectron-core, odnosno sqlectron-gui repozitorijima
Broj korisnika aplikacije nije poznat, jer ne postoji statistika broja skidanja
instalacijskih paketa sa stranica projekta. Teoretski, kako se radi o aplikaciji koja koristi
web tehnologije, broj korisnika bi se mogao mjeriti koristeći alate kao što je Google
Analytics, koji šalju podatke o ponašanju korisnika na udaljeni servis. Ipak, budući da se
radi o desktop aplikaciji, upitna je etička komponenta ovakvog pristupa. Ipak, postoji
statistika o broju posjeta na službenoj stranici (http://sqlectron.github.io/) projekta, a
prikazana je na slici 4.12. Vidljivo je iz grafa porast broja posjeta korisnika u drugoj
polovici 2016. godine što je pozitivan pokazatelj o porastu popularnosti aplikacije i samog
projekta.
Slika 4.12: Broj posjetitelja na službenoj stranici projekta po danu od početka trećeg do sredine šestog mjeseca
41
Zaključak
Višeplatformsku univerzalnu desktop aplikaciju za rad s relacijskim bazama
podataka Sqlectron moguće je koristiti na Windows, OS X i Linux operacijskim sustavima,
a omogućava korisniku rad s više različitih sustava baza podataka. Umjesto korištenja više
različitih desktop aplikacija za rad s pojedinim sustavima baza podataka, moguće je
koristiti jednu aplikaciju unutar koje se korisnik može spajati na MySQL, PostgreSQL i
SQL Server baze podataka.
Aplikacija je izgrađena koristeći Electron razvojni okvir, koji integrira Node.js
izvršno okruženje i minimiziranu verziju Chromium preglednika, zbog čega je prilikom
razvoja aplikacije moguće koristiti sve dostupne web tehnologije i biblioteke. Zahvaljujući
tome, razvoj aplikacije je ubrzan i vrlo sličan razvoju web aplikacije. Dodatno, grafičko
korisničko sučelje u potpunosti je prilagodljivo, te se aplikacija na svakom operacijskom
sustavu ponaša i izgleda jednako. Nedostatak je veličina aplikacije koja iznosi približno
153 megabajta. Aplikacija je pisana u JavaScript-u, HTML-u, CSS-u, te je za razvoj
sučelja dodatno korištena React biblioteka. Funkcionalnosti u aplikaciji razvijane su
kolaboracijom na projektu primjernom „Forking Workflow“ načina rada. Svaka
funkcionalnost razvijana je na osobnom udaljenom repozitoriju, te se nakon završetka rada
na funkcionalnosti radio zahtjev za povlačenje promjena na službeni repozitorij projekta.
Iako sam s vremenom dobio prava za pisanje na službeni repozitorij, cijela kolaboracija se
i dalje nastavila prema opisanom modelu, zbog transparentnosti i mogućnosti pregleda i
recenzije koda vlasnika repozitorija.
Razvijene funkcionalnosti uključivale su razvoj izbornika za pregled i filtriranje
strukture baze podataka, napredno uređivanje SQL programskog koda, automatsko
generiranje SQL skripti, vizualizaciju objekata baze podataka pomoću dijagrama i druge
manje promjene.
Uzevši u obzir povećan broj poklonika, pretplatnika i novih fork-ova repozitorija,
kao i povećanu aktivnost na projektu i službenim stranicama, može se zaključiti kako
projekt dobiva na popularnosti i za očekivati je daljnja poboljšanja aplikacije i veći broj
korisnika. Moguća poboljšanja u budućnosti su podrška za Oracle i SQLite sustave baza
podataka, unaprjeđenje sučelja, unaprjeđenje smještaja elemenata na dijagramu, izvoz
dijagrama u SVG i drugo.
42
Literatura
[1] CARNet, Terminologija – Rječnik najčešćih pojmova. http://www.carnet.hr/e-
presso/terminologija?news_id=2857. 20.6.2016.
[2] PC Magazine, Definition of cross-platform.
http://www.pcmag.com/encyclopedia/term/40495/cross-platform. 20.6.2016.
[3] Baker, W. C. JDK 1.0 ships. Berkley, CA, SAD. 23.1.1996.
https://embedded.eecs.berkeley.edu/Respep/Research/dds/Hyper-RNweb/0091.html.
20.6.2016.
[4] Java Platform, Documentation. https://docs.oracle.com/javase/7/docs/api/. 20.6.2016.
[5] Qt, Documentation . http://doc.qt.io/qt-5/gettingstarted.html. 20.6.2016.
[6] Adobe AIR, Documentation. http://www.adobe.com/devnet/air/documentation.html.
20.6.2016.
[7] Sometimes I Code, How does Unity export to so many platforms. 19.2.2014.
https://sometimesicode.wordpress.com/2014/02/19/how-does-unity-export-to-so-
many-platforms/. 28.6.2016.
[8] Hauwert, R. The future of scripting in Unity. 20.5.2014.
http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-in-unity/. 28.6.2016.
[9] StackOwerflow, Developer survey 2016: Most Popular Technologies. 20.6.2016.
[10] Bitbucket, Chromium Embedded Framework ,
https://bitbucket.org/chromiumembedded/cef. 20.6.2016.
[11] NW.js, Documentation , http://docs.nwjs.io/en/latest/. 20.6.2016.
[12] Mobidev, Cross-Platform Development For Desktops: Choosing The Right
Technology. Kolovoz 6, 2015. https://mobidev.biz/blog/cross-
platform_development_for_desktops_choosing_the_right_technology. 20.6.2016.
[13] Electron, Documentation. http://electron.atom.io/docs/. Veljača – lipanj 2016.
[14] Chromium Project, Multi-process Architecture.
https://www.chromium.org/developers/design-documents/multi-process-architecture.
21.6.2016.
[15] Vorobiev I. Atom Shell Architecture. https://github.com/ilyavorobiev/atom-
docs/blob/master/atom-shell/Architecture.md. Lipanj 2016.
[16] Žagar, M. Besplatnost, sloboda, otvorenost u računarstvu. Predavanje s predmeta
„Otvoreno računarstvo“, FER, Sveučilište u Zagrebu. Akademska godina
2015./2016.
43
[17] Openhub, Compare Repositories. https://www.openhub.net/repositories/compare.
23.6.2016.
[18] Atlassian, Forking Workflow. https://www.atlassian.com/git/tutorials/comparing-
workflows/forking-workflow. Ožujak - lipanj 2016.
[19] jQuery Foundation, Commits and Pull Requests.
https://contribute.jquery.org/commits-and-pull-requests/. Ožujak – lipanj 2016.
[20] Fowler, M. Continuous Integration.
http://www.martinfowler.com/articles/continuousIntegration.html. 24.6.2016.
[21] SemVer, Semantic Versioning 2.0.0. http://semver.org/. 24.6.2016.
[22] Sqlectron, Sqlectron-core. https://github.com/sqlectron/sqlectron-core. veljača –
lipanj 2016.
[23] Sqlectron, Sqlectron-gui. https://github.com/sqlectron/sqlectron-gui. veljača – lipanj
2016.
[24] Kangax, ECMAScript 6 compatibility table. http://kangax.github.io/compat-
table/es6/. 24.6.2016.
[25] Babeljs, Learn ECMAScript 2015. http://babeljs.io/docs/learn-es2015/. 24.6.2016.
[26] Facebook React, React documentation. https://facebook.github.io/react/docs/getting-
started.html. Ožujak - lipanj 2016.
[27] Redux, Documentation. http://redux.js.org/. Ožujak – travanj 2016.
[28] Reactjs, React-Redux. https://github.com/reactjs/react-redux. Ožujak – travanj 2016.
[29] JointJS, API Documentation. http://www.jointjs.com/api. Svibanj - lipanj 2016.
44
Sažetak
Višeplatformska desktop aplikacija za rad s relacijskim bazama podataka
Rad prati razvoj funkcionalnosti višeplatformske univerzalne desktop aplikacije za rad
s relacijskim bazama podataka, kolaboracijom na projektu otvorenog koda Sqlectron.
Razvijena aplikacija, koju je moguće koristiti na Windows, OS X i Linux platformi,
omogućuje korisniku rad sa više različitih sustava relacijskih baza podataka: MySQL,
PostgreSQL i SQL Server. Pisana je koristeći Electron razvojni okvir i web programske
tehnologije kao što su JavaScript i React. Razvojni okvir Electron, kao i kolaboracija na
projektu otvorenog koda primjenom „Forking Workflow“ metodologije, podrobnije su
opisani u radu. Na samom kraju rada dan je opis Sqlectron aplikacije, njene arhitekture,
korištenih tehnologija, razvijenih funkcionalnosti i pregled statusa projekta.
Ključne riječi: Višeplatformska desktop aplikacija, Relacijske baze podataka, JavaScript,
Electron razvojni okvir, Otvoreni kod, React
45
Abstract
Multi-platform Desktop Application for Relational Database Administration
Thesis sums up development of universal multi-platform desktop application for
relational database administration through collaboration on open-source project Sqlectron.
Developed application, which can be run on Windows, OS X and Linux platforms, enables
user to work with several different relational database systems: MySQL, PostgreSQL and
SQL Server. It was built with Electron framework and web technologies like JavaScript
and React. Electron framework and collaboration on the open-source project using
“Forking Workflow” methodology are further described in a paper. At the very end,
description of Sqlectron application, as well as projects architecture, developed features
and project status are all brought up.
Keywords: Multi-platform desktop application, Relational database, JavaScript, Electron
framework, Open-source, React
Related Documents
