reklama

Nápad na bakalářskou práci se Spring

Nápad na bakalářskou práci se Spring
« kdy: 15. 04. 2019, 13:28:44 »
Zdravím,
mám sehnaného vedoucího práce, který by mi vedl bakalářku v tomhle směru. Ale problém je, že mě nenapadá nějaké zajímavá aplikace ve springu (mvc, security, hibernate atd)  + javascriptu. Zřejmě bych použil i REST s AJAXem, nicméně přesné zadání mě úplně nenapadá...

Jediné, co mě napadlo je - převod desktopové aplikace na webové v javě - to znamená udělat desktopovou verzi, webovou, možnosti přenosu, zabezpečení atd...

Napadlo by vás něco prosím, nějaké téma, aplikace související s tímhle tématem?

Díky moc
« Poslední změna: 15. 04. 2019, 13:35:19 od Petr Krčmář »

reklama


Re:Nápad na bakalářskou práci se Spring
« Odpověď #1 kdy: 15. 04. 2019, 17:53:27 »
Různé spolky, které mají jednotky až desítky členů, obvykle potřebují vést evidenci svých členů spolu s kontaktními údaji a často pak potřebují svým členům po přihlášení poskytnou něco z následujícího:

  • Zobrazit kontaktní údaje ostatních členů (e-mail, telefon, Facebook, poštovní adresa…).
  • Umožnit členům přihlásit se na nějakou spolkovou akci.
  • Nechat členy hlasovat třeba o termínu akce nebo barvě triček.
  • Vyexportovat seznam členů nebo jen některé údaje (třeba jen seznam e-mailů) do Excelu, CSV, vytisknout prezenční listinu všech členů nebo jen těch přihlášených na akci (vygenerovat PDF).
  • Rozeslat členům e-mail na základě nějaké šablony (třeba s platebními údaji).

Pokud má spolek ve svých řadách nějakého programátora, obvykle na to udělá nějakou webovou aplikaci, která splní minimum toho, co je potřeba. Takže takových aplikací budou po republice desítky, místo aby byl jedna dotažená a open-source, kterou si každý přizpůsobí podle svých potřeb. A nebo se to řeší různými tabulkami posílanými e-mailem, Google tabulkou, Doodle apod.

Tak můžete začít s tou opensource aplikací, ke které se později budou moci připojit ostatní :-)

Protože má zároveň každý jiné požadavky, bylo by fajn, kdyby to bylo postavené nad zdokumentovaným RESTovým rozhraním, aby se na to případně daly napojovat další systémy. Mělo by to být multitenant, aby se to na jednom serveru dalo provozovat pro víc spolků. Může tam být implementováno přihlašování pomocí OAuth 2.0 (Facebook, Google, MojeID atd.) A různých dalších vylepšení se tam dá navymýšlet spousta.

Re:Nápad na bakalářskou práci se Spring
« Odpověď #2 kdy: 15. 04. 2019, 19:22:59 »
Různé spolky, které mají jednotky až desítky členů, obvykle potřebují vést evidenci svých členů spolu s kontaktními údaji a často pak potřebují svým členům po přihlášení poskytnou něco z následujícího:

  • Zobrazit kontaktní údaje ostatních členů (e-mail, telefon, Facebook, poštovní adresa…).
  • Umožnit členům přihlásit se na nějakou spolkovou akci.
  • Nechat členy hlasovat třeba o termínu akce nebo barvě triček.
  • Vyexportovat seznam členů nebo jen některé údaje (třeba jen seznam e-mailů) do Excelu, CSV, vytisknout prezenční listinu všech členů nebo jen těch přihlášených na akci (vygenerovat PDF).
  • Rozeslat členům e-mail na základě nějaké šablony (třeba s platebními údaji).

Pokud má spolek ve svých řadách nějakého programátora, obvykle na to udělá nějakou webovou aplikaci, která splní minimum toho, co je potřeba. Takže takových aplikací budou po republice desítky, místo aby byl jedna dotažená a open-source, kterou si každý přizpůsobí podle svých potřeb. A nebo se to řeší různými tabulkami posílanými e-mailem, Google tabulkou, Doodle apod.

Tak můžete začít s tou opensource aplikací, ke které se později budou moci připojit ostatní :-)

Protože má zároveň každý jiné požadavky, bylo by fajn, kdyby to bylo postavené nad zdokumentovaným RESTovým rozhraním, aby se na to případně daly napojovat další systémy. Mělo by to být multitenant, aby se to na jednom serveru dalo provozovat pro víc spolků. Může tam být implementováno přihlašování pomocí OAuth 2.0 (Facebook, Google, MojeID atd.) A různých dalších vylepšení se tam dá navymýšlet spousta.

děkuji za pěknou inspiraci. Mohl byste, prosím, rozvinout tu druhou část? Mohl byste mi vysvětlit, jak si představujete tu část s RESTEM? A to s multitenant - "aby se to na jednom serveru dalo provozovat pro víc spolků" - to znamená, že bude jeden server, jedna databáze, do které se budou ukládat všechny ty spolky, informace a další data...
Tedy prakticky: Byl by napsán server ve springu s REST, a potencionální uživatelé by používali tu klientskou část, která by přes AJAX stahovala data ze serveru, že? S tím, že několik spolků může být spravováno v jeden čas.
Díky

Re:Nápad na bakalářskou práci se Spring
« Odpověď #3 kdy: 15. 04. 2019, 20:29:29 »

Re:Nápad na bakalářskou práci se Spring
« Odpověď #4 kdy: 15. 04. 2019, 21:46:43 »
děkuji za pěknou inspiraci. Mohl byste, prosím, rozvinout tu druhou část? Mohl byste mi vysvětlit, jak si představujete tu část s RESTEM? A to s multitenant - "aby se to na jednom serveru dalo provozovat pro víc spolků" - to znamená, že bude jeden server, jedna databáze, do které se budou ukládat všechny ty spolky, informace a další data...
Tedy prakticky: Byl by napsán server ve springu s REST, a potencionální uživatelé by používali tu klientskou část, která by přes AJAX stahovala data ze serveru, že? S tím, že několik spolků může být spravováno v jeden čas.
Díky
Psal jste, že byste použil REST s AJAXem. To zapadá do mé představy, jakou by taková aplikace měla mít architekturu – na backendu Spring, který bude veškeré služby poskytovat přes RESTové API, a jako frontend klasická SPA, která bude volat to RESTové API. Mně by se pro tu frontend část nejvíce líbilo Vue, ale klidně to může být třeba Angular nebo React.

Má poznámka k RESTu pak směřovala k tomu, aby to RESTové API bylo navržené tak, že může fungovat i samostatně, bez té webové aplikace. Často se totiž stává, že když se navrhuje RESTOvé API pro jednu konkrétní SPA, je to API s tou frontendovou aplikací natolik svázané, že prakticky nejde jinde použít. Tady by ale myslím bylo vhodné, aby cokoli, co půjde udělat přes webový frontend, šlo (bez větší námahy) udělat i voláním API. Například klasický postup přidání nového člena spolku by byl takový, že to nějaký administrátor spolku nakliká přes webové rozhraní. Ale spolek už má třeba jinou evidenci a chtěl by používat jiné funkce té aplikace – tak si udělá propojku, která přes to RESTové API bude vytvářet členy na základě toho druhého systému.

Multitenant znamená, že se aplikace provozuje jenom jednou (typicky jen s jednou databází), ale z hlediska uživatelů se to chová, jako kdyby to bylo víc nezávislých aplikací, pro každý spolek jiná. Např. můžete mít jednu instalaci účetního programu, vede se v ní ale účetnictví několika firem. Z pohledu uživatelů se to chová, jako by účetnictví každé firmy bylo zvlášť – nesmí se tedy stát, že by účetní jedné firmy viděl nějaké údaje z jiné firmy, nebo že by si i navzájem mohli jenom měnit konfiguraci.

Nejsnazší by samozřejmě bylo mít pro každou firmu/spolek jinou databázi, jenže to je zejména ve webovém prostředí obtížně řešitelné – pokud byste měl na jednom serveru třeba 100 databází, těžko může server udržovat třeba 400 spojení do databáze (pro každou databázi 4), která by byla většinu času neaktivní. Druhá možnost je mít vše ve společných tabulkách, prakticky v každé tabulce pak tedy musí být i sloupec určující, do které firmy daný záznam patří. Pak je samozřejmě potřeba ve všech dotazech přidávat i podmínku na aktuální firmu, aby se právě nestalo, že se někde zobrazí i údaje někoho jiného. To je jedna nevýhoda, druhá nevýhoda je, že se pak jednotlivé firmy ovlivňují více, než je zdrávo – když budete mít devět firem, každá bude mít deset faktur, a desátá firma bude mít deset tisíc faktur, penalizované za to, že pracují s tabulkou o desetitisíci záznamech (což je tedy pořád málo, ale v jiných tabulkách může být těch záznamů řádově víc), budou všechny firmy. Většina relačních databází pak umožňuje ještě něco mezi, že se připojujete k jedné databázi, ale uvnitř ní je víc prostorů, které jsou do jisté míry oddělené. Třeba v PostgreSQL by se pro tohle dala použít schémata.

Ale zároveň to není věc, která by tam musela být za každou cenu hned od začátku, asi to není věc, která by se řešila na úrovni bakalářské práce. Ale dá se s tím počítat třeba na úrovni API – třeba účetnictví Flexibee to má dělané tak, že první položka cesty v URL je vždy identifikátor firmy. Takže třeba pro seznam faktur Firmy1 voláte https://www.example.com/firma1/faktury a pro seznam faktur Firmy dva voláte https://www.example.com/firma2/faktury. Mimochodem zrovna Flexibee má docela pěkné API, ve kterém jde udělat skoro všechno, co umí ta aplikace samotná.

Pokud byste měl nějaké další dotazy, klidně se ptejte. Já budu rád, když taková aplikace konečně vznikne a nebudu jí muset příště psát znova sám :-)


Re:Nápad na bakalářskou práci se Spring
« Odpověď #5 kdy: 16. 04. 2019, 09:07:42 »
děkuji za pěknou inspiraci. Mohl byste, prosím, rozvinout tu druhou část? Mohl byste mi vysvětlit, jak si představujete tu část s RESTEM? A to s multitenant - "aby se to na jednom serveru dalo provozovat pro víc spolků" - to znamená, že bude jeden server, jedna databáze, do které se budou ukládat všechny ty spolky, informace a další data...
Tedy prakticky: Byl by napsán server ve springu s REST, a potencionální uživatelé by používali tu klientskou část, která by přes AJAX stahovala data ze serveru, že? S tím, že několik spolků může být spravováno v jeden čas.
Díky
Psal jste, že byste použil REST s AJAXem. To zapadá do mé představy, jakou by taková aplikace měla mít architekturu – na backendu Spring, který bude veškeré služby poskytovat přes RESTové API, a jako frontend klasická SPA, která bude volat to RESTové API. Mně by se pro tu frontend část nejvíce líbilo Vue, ale klidně to může být třeba Angular nebo React.

Má poznámka k RESTu pak směřovala k tomu, aby to RESTové API bylo navržené tak, že může fungovat i samostatně, bez té webové aplikace. Často se totiž stává, že když se navrhuje RESTOvé API pro jednu konkrétní SPA, je to API s tou frontendovou aplikací natolik svázané, že prakticky nejde jinde použít. Tady by ale myslím bylo vhodné, aby cokoli, co půjde udělat přes webový frontend, šlo (bez větší námahy) udělat i voláním API. Například klasický postup přidání nového člena spolku by byl takový, že to nějaký administrátor spolku nakliká přes webové rozhraní. Ale spolek už má třeba jinou evidenci a chtěl by používat jiné funkce té aplikace – tak si udělá propojku, která přes to RESTové API bude vytvářet členy na základě toho druhého systému.

Multitenant znamená, že se aplikace provozuje jenom jednou (typicky jen s jednou databází), ale z hlediska uživatelů se to chová, jako kdyby to bylo víc nezávislých aplikací, pro každý spolek jiná. Např. můžete mít jednu instalaci účetního programu, vede se v ní ale účetnictví několika firem. Z pohledu uživatelů se to chová, jako by účetnictví každé firmy bylo zvlášť – nesmí se tedy stát, že by účetní jedné firmy viděl nějaké údaje z jiné firmy, nebo že by si i navzájem mohli jenom měnit konfiguraci.

Nejsnazší by samozřejmě bylo mít pro každou firmu/spolek jinou databázi, jenže to je zejména ve webovém prostředí obtížně řešitelné – pokud byste měl na jednom serveru třeba 100 databází, těžko může server udržovat třeba 400 spojení do databáze (pro každou databázi 4), která by byla většinu času neaktivní. Druhá možnost je mít vše ve společných tabulkách, prakticky v každé tabulce pak tedy musí být i sloupec určující, do které firmy daný záznam patří. Pak je samozřejmě potřeba ve všech dotazech přidávat i podmínku na aktuální firmu, aby se právě nestalo, že se někde zobrazí i údaje někoho jiného. To je jedna nevýhoda, druhá nevýhoda je, že se pak jednotlivé firmy ovlivňují více, než je zdrávo – když budete mít devět firem, každá bude mít deset faktur, a desátá firma bude mít deset tisíc faktur, penalizované za to, že pracují s tabulkou o desetitisíci záznamech (což je tedy pořád málo, ale v jiných tabulkách může být těch záznamů řádově víc), budou všechny firmy. Většina relačních databází pak umožňuje ještě něco mezi, že se připojujete k jedné databázi, ale uvnitř ní je víc prostorů, které jsou do jisté míry oddělené. Třeba v PostgreSQL by se pro tohle dala použít schémata.

Ale zároveň to není věc, která by tam musela být za každou cenu hned od začátku, asi to není věc, která by se řešila na úrovni bakalářské práce. Ale dá se s tím počítat třeba na úrovni API – třeba účetnictví Flexibee to má dělané tak, že první položka cesty v URL je vždy identifikátor firmy. Takže třeba pro seznam faktur Firmy1 voláte https://www.example.com/firma1/faktury a pro seznam faktur Firmy dva voláte https://www.example.com/firma2/faktury. Mimochodem zrovna Flexibee má docela pěkné API, ve kterém jde udělat skoro všechno, co umí ta aplikace samotná.

Pokud byste měl nějaké další dotazy, klidně se ptejte. Já budu rád, když taková aplikace konečně vznikne a nebudu jí muset příště psát znova sám :-)

Co se týče tenatizace, tak je ještě možnost mít jedno schema pro metadata a sdílet všechny tabulky a pro vlastní data tabulku zvlášť.
Důvodem je, že pokud budete mít tisíce zákazníků, tak si nedokážu moc dobře představit udržbu nebo upgrade tisíce schemat v databázi.

Jedno schema pro metadata a jedno pro data. Metadata je například nastavení uživatele a informace o něm. Metadata všech tenantů sdílí tabulky. Data všech tenantů do jednoho dalšího schemata. Například pokud budete řešit faktury za dany rok, tak by každý tenant měl jednu tabulku na každý rok.

Pro sdílená data mezi všemi tenanty máme ještě třetí schema. 

Veškeré datové objekty doporučuji mít immutable a pro výkon by mohlo pomoct mít metadata uložena v cache, například Caffeine
https://github.com/ben-manes/caffeine

V cache může být jen objekt a klíčem bude id toho objektu, nebo v další cache může být i seznam id ze selektu. Záleží jak moc chcete řešit problémy cache.

Re:Nápad na bakalářskou práci se Spring
« Odpověď #6 kdy: 17. 04. 2019, 13:20:49 »
Sprav webovy soft na vizualizaciu rozvrhov pre multitrack konferencie:
  • CRUD na trackoch
  • CRUD na prednaskach
  • presuvanie prednasov medzi trackami
  • presuvanie prednasok v ramci tracku

V prvej verzii by uplne stacil hlupy editor, v dalsej verzii mozes pridat viac dni, potom by to mohlo mat aj nejaku inteligenciu (zgrupovanie kratkych prednasok kvoli minimalizacii prestojov) az po megafunkcie ako zistovanie zaujmu skupiny ludi o konkretne prednasky a nasledny rozvrh maximalne uspokojujuci celu skupinu minimalizaciou prekryvov najziadanejsich prednasok.

Vystup cez export do HTML s vizualizaciou trackou vedla seba a so zobrazenim dlzky jednotlivych prednasok.

Re:Nápad na bakalářskou práci se Spring
« Odpověď #7 kdy: 17. 04. 2019, 13:50:37 »
Kdybych dnes chodil na VS a delal bakalarku nebo diplomku, tak se zamerim na perfromance testy. Udelal bych testovaci apliakci ktera porovnava v nejakem smysluplnem scenari perfromanceHibernate a treba myBatis. Nebo se zameruje na ladeni Hibernate. V praxi kdyz se pouziva hibernate tak jsou s tim vykonostni potize.

Re:Nápad na bakalářskou práci se Spring
« Odpověď #8 kdy: 17. 04. 2019, 14:37:23 »
Kdybych dnes chodil na VS a delal bakalarku nebo diplomku, tak se zamerim na perfromance testy. Udelal bych testovaci apliakci ktera porovnava v nejakem smysluplnem scenari perfromanceHibernate a treba myBatis. Nebo se zameruje na ladeni Hibernate. V praxi kdyz se pouziva hibernate tak jsou s tim vykonostni potize.

Vyhoda je, ze tim delas opravdu nejaky obecny vyzkum, namisto toho, aby jsi na VS delal nejakou nesmyslnou aplikaci, treba pro ty konference. Protoze bezesporu ta aplikace co udelas bude beztak stat za govno, takhle alespon budes mit vysledky mereni.

Re:Nápad na bakalářskou práci se Spring
« Odpověď #9 kdy: 18. 04. 2019, 08:32:55 »
Me by treba zajimalo, jakou bude mit Hibernate v zakladni konfiguraci perfromance pro zretezeny eager fetch tabulek T1...Tn oproti tomu samemu napsanemu pomoci plain SQL, a jaky performance bude mit opakovani toho dotazu (hibernate  cachuje). Plus nejake dalsi simulovane use case.

Re:Nápad na bakalářskou práci se Spring
« Odpověď #10 kdy: 18. 04. 2019, 09:23:30 »
Kdybych dnes chodil na VS a delal bakalarku nebo diplomku, tak se zamerim na perfromance testy. Udelal bych testovaci apliakci ktera porovnava v nejakem smysluplnem scenari perfromanceHibernate a treba myBatis. Nebo se zameruje na ladeni Hibernate. V praxi kdyz se pouziva hibernate tak jsou s tim vykonostni potize.
Vyhoda je, ze tim delas opravdu nejaky obecny vyzkum, namisto toho, aby jsi na VS delal nejakou nesmyslnou aplikaci, treba pro ty konference. Protoze bezesporu ta aplikace co udelas bude beztak stat za govno, takhle alespon budes mit vysledky mereni.
Jaska, nezmyselna appka napriklad na tie konfery je somarina co sa neda rozvijat. Aj Zuck alebo Page/Brin robili statistiky okolo ORM mapovania a pekne tu myslienku rozvijaju az doteraz.

gill

Re:Nápad na bakalářskou práci se Spring
« Odpověď #11 kdy: 18. 04. 2019, 10:01:04 »
Me by treba zajimalo, jakou bude mit Hibernate v zakladni konfiguraci perfromance pro zretezeny eager fetch tabulek T1...Tn oproti tomu samemu napsanemu pomoci plain SQL, a jaky performance bude mit opakovani toho dotazu (hibernate  cachuje). Plus nejake dalsi simulovane use case.

Na tom nic nevyzkoumas. To zalezi na nastaveni cachovani. Ciste SQL muzes take cachovat, i v aplikaci.

Re:Nápad na bakalářskou práci se Spring
« Odpověď #12 kdy: 18. 04. 2019, 10:29:35 »
studoval som v dansku a tam to pre studentov softaware engineeringu byva takto: najdu si firmu pre ktoru vybuduju realny produkt. je celkom caste ze student popri skole uz aj niekde robi a ked nema vlastny napad, manazeri vedia vzdy nieco najst...vyhodou je, ze by si mohol vytvorit nieco co (ak sa podari) vytvori nejaku realnu hodnotu a bude nadalej zit. moznoze sa aj pohras s CI/CD...

ja som napriklad robil (v spolupraci s dalsim spoluziakom) dashboard(angular + net core api) na monitoring vykonu nejakeho (uz existujuceho) ML systemu...


Re:Nápad na bakalářskou práci se Spring
« Odpověď #13 kdy: 19. 04. 2019, 09:15:25 »
Me by treba zajimalo, jakou bude mit Hibernate v zakladni konfiguraci perfromance pro zretezeny eager fetch tabulek T1...Tn oproti tomu samemu napsanemu pomoci plain SQL, a jaky performance bude mit opakovani toho dotazu (hibernate  cachuje). Plus nejake dalsi simulovane use case.

Na tom nic nevyzkoumas. To zalezi na nastaveni cachovani. Ciste SQL muzes take cachovat, i v aplikaci.

Jak ze na tom nic nevyzkoumas, to si delas srandu ne. Zrovna ohledne cachovani o kterem pises muzes porovnat perfromance SQL a Hibernate kdyz ma databaze delays ze je jakoze remote a kdyz je databaze na stejnem stroji. Databaze si taky umi cachovat, takze nepotrebujes mit cache 2x, paklize jede ta DB na stejne masine.

Uz i samotne na tom nic nevyzkoumas je hlod, vsude se delaji enterprise informacni systemy a tomuhle malokdo dobre rozumi.

Re:Nápad na bakalářskou práci se Spring
« Odpověď #14 kdy: 19. 04. 2019, 09:48:26 »
Jak ze na tom nic nevyzkoumas, to si delas srandu ne. Zrovna ohledne cachovani o kterem pises muzes porovnat perfromance SQL a Hibernate kdyz ma databaze delays ze je jakoze remote a kdyz je databaze na stejnem stroji. Databaze si taky umi cachovat, takze nepotrebujes mit cache 2x, paklize jede ta DB na stejne masine.
Co na tom vyzkoumáte jiného, než síťový round-trip databáze?

Uz i samotne na tom nic nevyzkoumas je hlod, vsude se delaji enterprise informacni systemy a tomuhle malokdo dobre rozumi.
Co na tom tedy vyzkoumá užitečného? Tedy takového, co bude platit i pro jiné případy, než pro ten jeden, který zkoumal? V reálném světě je každý systém jiný a chová se jinak. Chování se mění i v závislosti na tom, kolik je zrovna aktivních uživatelů a co dělají. A zrovna u enterprise informačních systémů se milisekundy zpoždění síťové odezvy při přístupu do databáze opravdu neřeší. Navíc u enterprise systému by snad nikoho nenapadlo provozovat aplikační server a databázi na tom samém stroji.

 

reklama