Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - registrovany123

Stran: 1 ... 3 4 [5] 6 7 ... 28
61
Studium a uplatnění / Re:Plat Java vývojáře na živnost
« kdy: 24. 04. 2023, 17:14:13 »
Hele já teď remote dělal 3 měsíce, nikdy jsem v té firmě nebyl, ale byli remote friendly, a produktivní jsem byl už tak za 2 týdny. Každý den standup a zapnuté webcams, rychlé meetingy přes Slack a nikdy mi nepřišlo, že by nějak vázla
 komunikace. Akorát teda to byli pěkní šmejdi, do příště si píšu, že když někde uvidím špatný tech stav projektu, tak automaticky to znamená to samé v managementu.

Jo ale potom zkušenost s jiné firmy, kde byl Covid a všichni přešli na Remote, tak produktivita klesla - jenže tady se musí brát v potaz to, že jsem tam byli dost přetěžovaní, takže jakmile byla ta příležitost... ale to byla zvláštní doba ten COVID, hodně lidí bylo z toho zdeptaných atp.

Každopádně co tady někteří píšou o flákání na remote, tak to mě pěkně vytáčí. Firma má být schopná zjistit, kdo jak dobře pracuje, kdo jak dobře dodává do týmu. A pak se podívat na ty dodávky a říct, že to je OK, nebo říct, že to není OK a sdělit dotyčnému, že má jít s MD sazbou dolů.


62
/dev/null / Re:Chat GPT
« kdy: 10. 04. 2023, 23:48:33 »
Nevim proc to skoncilo v /dev/null

63
/dev/null / Managerské špinavé triky v IT
« kdy: 25. 03. 2023, 13:43:17 »
Dotaz, já se moc o management nezajímám, ale pracuju teď v nějaké firmě, kde je zcela očividné, že na mě zkouší vedoucí projektu nějaké triky.

Nejprve mi dali v úplně nesmyslně krátkém čase vypracovat úkol, a nehleděli na moje estimace - nejsem tam ani 3 měsíce. Viděl jsem v tom očividnou schválnost, a dost vytočený jsem jim to dal jasně najevo, dokonce jsem preventivně sepsal výpověď, jak mě to vytočilo. Tak se jakože "omlouvali" a říkali, že to tak nemysleli a podobné kraviny, jakože ty estimace dělaji jen kvůli lepšímu plánování - tak proč v tom případě sakra nevzali moje estimace a dali tam svoje nesmysly, v podstatě moje estimace zkrouhli o 50%. No, říkal jsem si, že to ještě zkusím... Jenže pak zkusili něco dalšího.

Udělali tohle: lead mi začal pochlebovat, že jsem dobrej, technicky zdatný, a že mě dostatečně nevyužívají :o. A začali mi říkat, že mi dají někoho na výpomoc, člověka co se jmenuje řekněme Jan. A říkali, že mi s tím pomůže Jan, ale že Jan je nejslabší článek týmu, že mu mám zadat úkoly, ale že sám uvidím, že je prostě slabej a že mu to bude trvat dýl než mi.

Nejprve jsem byl jenom pohoršen, proč teamlead něco takového říká za zády člověka, seniora, který tam je teprve pár měsíců a komplikovaný projekt nezná (stejně jako já), a o kterém navíc vím, že je přibližně stejně rychlý s úkolama jako já.

Ale pak jsem nad tím přemýšlel a říkám si, jestli to není další fígl - pochlebují mi, že jsem dobrej, a chtějí ze mě vymáčknout víc práce (než mi zaplatí) tím, že mě jakoby namotivují, abych nebyl já ten "nejslabší článek", o kterém za zády říkají jiným členům týmu tohle.

Tak si říkám, sakra, co je tohle za firmu? Tak jsem si aktivoval na Linkedin Premium a vidím v Insights, že průměrná délka po kterou tam jsou zaměstnanci přítomni je 1.8 let. Oproti tomu třeba můj minulý zaměstnavatel ma 5 let. A nejhorší firma kde jsem kdy dělal tak má asi 2.8 let.

No dorpčic, tak je tohle vůbec možné? A víte proč jsem tam šel? Protože měli strašně dobře udělané pohovory, byli strašně příjemní, měli to udělané asi nejlíp ze všech.



64
/dev/null / Re:Grid vs Table
« kdy: 05. 03. 2023, 11:57:49 »
Jo to by mohl byt problem, ale ja delam layout tak, ze je stejny pro mobily i pro desktop, je to tabulka s daty viz Myfitnesspal.

65
/dev/null / Grid vs Table
« kdy: 05. 03. 2023, 07:59:51 »
Hral jsem si uz nekolikrakt s tvorbou layoutu pro data pomoci gridu a pomoci table.

Parkrat jsem uz vyrobil jeden a tentyz komplikovany layout s gridem a tabulkou, a nemuzu si pomoct, ale podle me proste tabulka vede.

Vsude ctu, ze pouzivat na layout table je zastarale, jenze ono to ma radu vyhod.

S tabulkou muzu rovnou pouzivat tr a td pro radky a sloupce, kdezto s gridem musim otravne psat vsechno do divu. Plus s gridem si musim do css doprogramovat colspany a rowspany, kdezto tabulka uz tohle ma out of box.

Tak beru ze na jednoduchy layout stranky se hodi vic grid, ale kruci, vzdyt je to ve vysledku totez.

Priklad co mi prijde vyodnejsi udelat tabulkou a ne gridem, resp je to to same:

https://www.myfitnesspal.com/food/diary

66
Vývoj / Jak funguje cache v relační databázi?
« kdy: 01. 03. 2023, 23:32:17 »
Zdravím,

řekněme, že mám databazí a v ní tabulku s nutričními hodnotami potravin: FoodsTable.

Uživatelé na frontendu často potravinami listují, když vyhledávají fulltextem. A řekněme že tento query spouštím jako parametrized query:

Kód: [Vybrat]
var pstmt = con.prepareStatement("SELECT * FROM FoodTable WHERE name like CONCAT( '%',?,'%')");
pstmt.setString(1, notes);
var rs = pstmt.executeQuery();

Databáze bude řekněme Postgres a celkový objem dat v tabulce FoodTable bude řekněme 50MB.

Tzn. otázka zní, má v takovém případě vůbec smysl uvažovat o nějaké In memory cache přímo v Javovské aplikaci, když už relační databáze na své straně umí cachovat? A jak to vlastně ta databáze cachuje, drží si výsledky toho query in-memory, nebo to funguje jinak?

PS: Např. SQLite cachovat umí, ale těžko to je In-Memory cachování, spíše si tu cache nějak zapisuje na disk do souboru.

67
Best practice je ukládat taková data normalizovaně. Tady je o tom článek v kontextu Reduxu, ale v principu to platí i pro jakékoli jiné uložení: https://redux.js.org/usage/structuring-reducers/normalizing-state-shape

No tvl to je zase dalsi level komplikovanosti. V podstate s takovym modelem to znamena, ze nepotrebuju ani sqlalchemy. Fakt zajimave. Ja v podstate 1:1 muzu ozrcadlit data z relacni databaze do frontendu. Ale dava to smysl no.

68
Zdravím,

narazil jsem teď na takový princiápní problém. Mám frontend a tuto doménu:

Kód: [Vybrat]
Food(id, name, calories)
Entry(id, food_id, amount, day_id)
Day(id, date)

Day 1-N Entry, mapped by Entry
Entry 1-1 Food, mapped by Entry

Na backendu mám toto API:

Kód: [Vybrat]
GET /days
GET /foods

Momentálně mám relační DB, data jsou grafová. Ale když je načtu do frontendu přes Rest, a uložím je do modelu (globalni store), tak data přítomná v modelu už nejsou grafová, ale stromová.

Tedy např. když uživatel upraví na page Jídlo entitu Food, tak tato změna se neprojeví do objektu Day->Entry->Food, protože nemám propojeny objekty v listu Food s objekty v Day->Entry->Food.

No a tak přemýšlím. Říkám si:

1. Buďto ty objekty v modelu propojím, ale přidělám si tím práci - na backendu to za me samo propojuje Hibernate, na frontendu ale nic takového není.
2. Nebo to nepropojím, ale pak si říkám, jestli má smysl použití Relační databáze. Protože to je sice hezké, že na backendu mi to udržuje grafovou strukturu mezi objekty, ale k čemu mi to je, když na frontendu se grafová struktur stejně ztratí a změní se na stromovou.

Na jednu stranu, backend mi teď zařídí, že když se změní Food na frontendu, tak sice změna se přirozeně neprojeví do Entry->Food, ale projeví se alespoň po refreshi stránky. Na stranu drouhou použití stromové struktury i na backendu mi umožní přidat zajímavou funkci pro uživatele, jestli si po modifikaci Food přeje tuto změnu promítnout to již existujících Entry.

Prostě, svrbí mě prst zahodit relační DB a dám tam NoSQL.

69
Server / Jednoduchý cloud pro deploy webové aplikace?
« kdy: 11. 02. 2023, 15:25:56 »
Zdravím,

umím docela dobře s Amazon AWS cloudem, ale pro osobní malé projektíky se mi zdá poněkud těžkopádný.

Neexistuje nějaká alternativa, kde můžu rychle deploynout jednoduché webové aplikace? Nic jiného než AWS neznám.

Momentálně mám něco napsáno v Pythonu + Vue + SQLite.


70
Vývoj / Dokumentové databáze a relační data
« kdy: 30. 01. 2023, 20:36:58 »
Má smysl používat dokumentové databáze pro psaní webový servis, když vím, že data budu chtít ukládat relačně? Ulehčím si tím něco, když vím, že s relační DB můžu použít třeba Hibernate nebo Sqlalchemy?

Příklad relace:

Kód: [Vybrat]
Food  (id, name, calories, author_user_id)
Entry (id, day_id, food_id)
Day   (id, date, user_id)
User  (id, email)

Ty dokumentové databáze se někdy zdají lákavé, protože se zdá, že se s nimi snadněji pracuje, ale je otázka, do jaké šlamastiky se s nimi člověk dostane, když se do nich bude pokoušet cpát relační data.

Jaké máte jsou vaše zkušenosti s dokumentovými databázemi?

71
Studium a uplatnění / Re:S root.cz to jde z kopce
« kdy: 30. 11. 2022, 15:59:03 »
To je zase tema, tazatel kluk z CVUT tady polozi uplne normalni dotaz, a dostane tohle. S Root.cz vidim ze to jde z kopce, zmizeli odtud lidi co to nejak drzeli. Spousta prispevku, a nikdo mu neni schopny nic ze zkusenosti rict, a nekteri to jeste vytykaji, co jako chce slysel.
Ale houby, už čtvrtá odpověď od jehovisty mu naprosto přesně odpověděla co má udělat - projíždět inzeráty a chodit na pohovory. Takhle se totiž shání práce.
Pan študák kontroval, že to by ho fakt nenapadlo.

Tak ja nevim jestli jsi tak blby nebo se jenom delas? Tazatel se neptal "Nemuzu najit praci co mama delat", ptal se, jakym smerem se ma ubirat, protoze si vsima, ze v  tom co ho bavi neni dostatek prace. O cem se tu vlastne pokousis prit?

72
Studium a uplatnění / Re:Skoro Ing. - přechod na webařinu?
« kdy: 30. 11. 2022, 15:55:41 »
Jeste na VS bych se tomu smal, ale dneska uz tak moc ne, takovi chytri lidi dokazi ruzne veci, treba jet do ciziny, zaujmout rozumne zakazniky, a potom zajet zpatky do CR a zakladat svoje vlastni firmy. Tohle moc lidi nedokaze, byt dobry vyvojar a jeste mit i kapacitu na to, jezdit do ciziny, mluvit anglicky a nemecky, a ziskat duveru a zakazky.

73
Studium a uplatnění / Re:S root.cz to jde z kopce
« kdy: 30. 11. 2022, 10:52:00 »
Vseobecne nemusis delat rovnou weby, kdyz chces mit dostatek prac. nabidek. Rekl bych neco jako:

C embedded -> .NET/Java informacni systemy na backendu -> "Fullstack" vyvojar .NET/ Java/ Node.js pro vyvoj webovych aplikaci -> CSS/Desing a tvorba webu.
Nebo cloud (mikroslužby apod.), od C je ke Go nebo Rustu jen malý krůček.

Ano na cloud, Amazon AWS kdyz Javu, Azure (Ten horsi  :P) kdyz .NET. Akorat Golang mi neprojde, ze se v nabidkach vyskytuje nejak extra casto, oproti Jave a .NETu.

A kdyz to chces mit klikaci a vsechno vic Microsoft a vic Windows, tak .NET, a taky cim vic web tim vic .NET (delaji se v nem hodne treba EShopu) a kdyz preferujes Unix, tak Javu, delaji se v tom vetsi podnikove informacni systemy, bezi na tom banky, mobilni opoeratori, vsechny vetsi podniky, casto narazis ze devs maji Macy (i ja), atp.

74
Studium a uplatnění / S root.cz to jde z kopce
« kdy: 30. 11. 2022, 10:13:51 »
To je zase tema, tazatel kluk z CVUT tady polozi uplne normalni dotaz, a dostane tohle. S Root.cz vidim ze to jde z kopce, zmizeli odtud lidi co to nejak drzeli. Spousta prispevku, a nikdo mu neni schopny nic ze zkusenosti rict, a nekteri to jeste vytykaji, co jako chce slysel.

Me na VS taky zajimalo C a embedded, a zvazoval jsem to co ty - asi jako hodne dalsich lidi jsme narazili na to, ze v tom co te bavi neni u nas tolik prace.

Vseobecne nemusis delat rovnou weby, kdyz chces mit dostatek prac. nabidek. Rekl bych neco jako:

C embedded -> .NET/Java informacni systemy na backendu -> "Fullstack" vyvojar .NET/ Java/ Node.js pro vyvoj webovych aplikaci -> CSS/Desing a tvorba webu.

Takze moznosti mas vic, neni to bud a nebo. U lidi co delaji frontend je dost jiny kolektivy a i prac. podminky, je tam mnohem vetsi hype, min inzenyru, vic bastleni. Doporucuju ti se zamerit na vyvoj inf. systemu obecne, a to budto jako ciste "backend" nebo, pokud trvas na webech, tak se divej po nabidkach "Fullstack vyvojar" - to je prace pro inzenyry.

Vseobecne na backend se zamer na .NET/Java
A pokud fakt trvas na vyvoj web aplikaci, tak se zamer na Node.js a React a tzv. "Fullstack development"

75
Vývoj / Re:Alternativa za Excel Visual Basic?
« kdy: 20. 11. 2022, 20:51:46 »
https://www.pyxll.com/

Licence za 600,- Kc / mesic pro individual usera? To fakt ne...

Stran: 1 ... 3 4 [5] 6 7 ... 28