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 - listoper

Stran: 1 ... 3 4 [5] 6 7 ... 46
61
Studium a uplatnění / Re:Lhaní recruiterů
« kdy: 10. 01. 2022, 19:19:57 »
"Dev" a "Ops" jsou IT genders...
Vsechny ostatni lablely jsou non-binary.

Ja se identifikuju jako fluid-dev. Chvilku delam dev chvilku ops a nekdy management.
Naramky na rozeznani nenosim. Ostatni muzou poznat moje aktualni zajmena podle mnozstvi nadavek.

#VytrolReKrutu

62
Studium a uplatnění / Re:Lhaní recruiterů
« kdy: 10. 01. 2022, 10:38:22 »
setkali jste se s recruiterkou, ktera byla na urovni?
vedela, ze je rozdil mezi javou a javascriptem atp.
tusila ceho se tyka projekt.

Takova uz by ale mela za sebou ten 3 mesicni kurz a delala programatorku....  ;D

63
Studium a uplatnění / Re:Lhaní recruiterů
« kdy: 10. 01. 2022, 08:49:47 »
Vím, že následující názor by byl dnešní většinovou společností považován za staromodní, ale já věřím, že každý má svojí profesi a té by se měl držet. Ty dnešní maistreamové kecy, že každý může být čímkoli, stačí chtít a když ho to přestane bavit, tak začne dělat zase něco úplně jiného... Když se jedná o alespoň trochu příbuzné obory, tak nic proti, ale představa, že teď bude někdo chvíli programovat, až ho to přestane bavit tak se rekvalifikuje na lékaře, potom uvidí dokument o Černobylu, tak se přihlásí na operátora reaktoru a nakonec začne létat jako pilot letadla, protože má chuť cestovat...
Než jsem vydělal první korunu jako programátor, tak jsem se tomu oboru třeba 10 let alespoň nějak okrajově věnoval, ať už ve škole nebo volném čase a myslím, že to tak má většina.
Jenže někdo si nechá nabulíkovat, že stačí udělat nějaké kurzy v rozsahu desítek možná nižších stovek hodin a bez jakéhokoli předchozího backgroundu se tomu může plnohodnotně věnovat. Koneckonců je to práce v teple a prý dobře platí, tak proč ne.
Možná staromódní, ale pravdivý. Já to zastávám také. Bohužel taková je dnes doba, řeší se "rasismus", "80 sex. pohlaví" a další stupni věci. Na druhou stranu, ono to všichni tak reklamují, že uděláš bootcamp a je z Vás programátor. To jsou jen bludy, kecy prdy beďary. Určitě existují lidé, kteří třeba ze kolbenky mohou jít programovat a budou lepší než nekteří senioři, ale je to tak 2%.

Bohužel to, že Vám "kurzy" i školy tlačí do hlavy, jak z Vás udělají experta hned, je dnes trend. Jak jsem psal, mám pár zkušeností z firem, než jsem začal se svou firmou a vždy to byla katastrofa. Chápu, že junior nemůže znát vše, ale na druhou stranu musí umět a chápat základy. Pak si už jen rozšiřuje obzory. Ale dnešní junioři, po kurzech co mi chodí na pohovory, chtějí 80-90% mít seniora za pr**lí a mentoring vyžadují. Osobně mi přijde, že na těch kurzech je tak leda naučí copy & paste z StackOverflow, co neví najdou na netu a zkopírují, aniž by věděl co daný kus kódu dělá. Z "moderních" juniorů snad nikdo nezná ani debugger... ;-(

To je vsechno sice pravda, ale kde chcete ty lidi brat?

Vzhledem k tomu jaky je pomer nabidky a poptavky se nelze divit, ze se snizuji standardy a do IT se dostavaji nekvalifikovani a nezpusobili lide.
A kdyz nekdo dokaze vydelat na tom, ze ty lidi za 3 mesice "proskoli" a uplatni tak jen dobre pro nej.
"Programator" je spokojenej, recruiter je spokojenej....

Navic je tam pakovej efekt.
Neschopnej programator -> nekvalitni software -> vic penez ze supportu a potreba noveho sw -> vetsi poptavka

A to ze na to nadava par morousu na rootu(vcetne me) nikoho nezajima.

64
Software / Re:Jak monitorujete tok dokumentů?
« kdy: 05. 01. 2022, 21:30:18 »
Asi to neni primo reseni na tvuj problem, ale napada me instana.
Jsou to reseni na monitoring a alerting.
Treba by to slo nejak ohnout pro tvuj ucel.
Videl sem to pouzity a docela pekne se v tom dalo proklikat cele flow prez nekolik systemu.
Nevim jestli podporujou i SAP a asi to nebude uplne levna zalezitost...
Funguje to tak, ze se do systemu ktery chces monitorovat instalujou agenti a ty pak hlasi udalosti do nejaky centralni databaze ze ktery se pak sklada to webovy klikatko.

Existujou i dalsi.... ale instanu mam v zive pameti.
Tu retenci tam meli nastavenou jen na 7 dni... ale to jde asi zmenit... podle toho kolik dat ti budou ty agenti chrlit...

65
Vývoj / Re:Rust - std::ANY alebo lepší návrh?
« kdy: 02. 12. 2021, 19:06:58 »

Já jsem se nebavil o generování ze schematu. Já jsem obhajoval "generovat kód vždy a všude" v opozici ke "generování kódu je zlo" :-)

Jasne. Tady sme myslim na hrane, ale uznam ti ze se jedna o generovani. A uznam, ze tenhle generovany kod je potreba commitnout.
Ale ta rucni editace k tomu se mi uz fakt nelibi...


OK, Maven to dělá jinak, v pořádku.

Možná jde o to, že u Composeru (a nejen u něj), balíček nezávisí na konkrétní verzi. Takže když by byla vydána nová verze nějakého balíčku, tak by se mohlo stát, že se tam stáhne ona. A to pochopitelně nechci.
Jak to dělá Maven netuším, ale předpokládám, že je tam nějaká chytristika, aby po konfiguraci bylo zaručeno, že se vždy vytvoří stejný graf.

Uz mozna rozumim...
U mavenu mam snapshot a release artefakty. Release uz se nemuze zmenit takze i jeho tranzitivni zavislosti budou stejne.
Snapshot se meni jak sam tak jeho zavislosti... tam by to davalo smysl.
A to je mozna duvod proc na to nenarazim.
Snapshotum se obloukem vyhybam...


V leiningenu myslim muzu pouzivat version ranges... ale je u toho nejaky warning, ze se to nema delat....

66
Vývoj / Re:Rust - std::ANY alebo lepší návrh?
« kdy: 02. 12. 2021, 18:13:19 »
Graf si sice muzu vygenerovat ale nikam ho nekomitnu, protoze to stejne pri buildu nikdo nepouzije.
Graf ne, ale informace o těch konkrétních závislostech ano. Chceš tři balíčky s nějakou cca verzí - dostaneš jich stovku s konkrétní verzí. Zkontroluješ, zda všechno funguje a tím, že to commitneš (tu stovku balíčků se specifickými závislostmy) tak uděláš schválení, že takto je to správně.

to fakt v mavenu ani v leiningenu nedelam... A nebo te porad spatne chapu.

Zavisim na balicku A:1.2.3 co zavisi na X, Y, Z.
Y zavisi na P ve verzi 3.14 a ten ma bug.
Moje zavislosti budou:
  • P:3.1415 kde uz vim ze je bug opraven a
  • A

Maven sam spravne dotahne i X, Y, a Z a P tam budu mit ve verzi 3.1415

ale kdyz se podivam do repositare nikde nenajdu ani zminku o X, Y a Z

67
Vývoj / Re:Rust - std::ANY alebo lepší návrh?
« kdy: 02. 12. 2021, 18:05:39 »

Přesně takto se to používá:
1/ Generovaný kód, jehož znění nevyžaduje schválení člověkem = generuje se na CI serveru (nebo kdekoliv jinde) + necommituje se.
2/ Generovaný kód, který mi vygeneruje stroj, ale musí projít schválením člověkem = generuje se u vývojáře, a pak se commituje.

Má to tyto důsledky:
V prvním případě se jede na tvrdo optimalizace, stroj může cokoliv.
V druhém případě je očekáváno, že to co se vygeneruje musí být co nejvíce čitelné; nejlépe optimalizované pro diff. (A následně se to třeba celé ještě projede první variantou.)

TypoProvidery a podobně jsou jen první varianta. Jen už zakomponovaná do překladače. Jak už tu někdo zmínil. Ve skutečnosti je to ale spousta dalších případů: gcc, javac, scalac, ... etc, kde by tě ani nepadlo uvažovat, že je to jen prachsprostej generátor kódu. A ne, není to něco jiného :)

Mel bys nejakej netrivialni priklad 2?

Příklad 3: VisualStudio má návrháře UI. Můžeš si tam naklikat, natahat, naarangovat elementy. Ty se potom zapíšou do souboru. Buď do C#, nebo do XAML. V případě XAML se tento ještě zpracovává do výsledného něčeho. C# je part třída, kde máš jednu část, kterou má na starost návrhář, a druhou část, kterou používáš ty jako vývojář pro vlastní opičárny. Když hrábneš do té návrhářské třídy, tak pokud to nepřeženeš, tak se to zpětně promítne do toho návrháře. Osvědčilo se mi do té návrhářské třídy koukat. Lépe si všimnu, že jsem udělal nějakou nepravost. Nebo naopak, při přejmenování nějakého elementu, se přejmenuje i tady a návrhář to v pohodě zkousne.

Hmmm s tim sem nikdy nedelal.
Pamatuju si nejaky takovy udelatko pro Qt a jestli se nepletu tak tam se to do jednoho souboru nemotalo.
Tam byl snad v tom navrhari nejaky dialog pro event binding nebo co... to se mi zda lepsi.
Navic vystup z toho snad bylo nejaky xml a ne primo trida v cilovem jazyce.
Ale kdo vi... uz je to davno

Navic tady jsme trochu dal od generovani neceho ze schematu.
Tady "programator" "programuje". Sice tahanim nejakejch policek po formulari, ale to je jedno... to ze existuje kod a jeho visualni reprezentace je v poradku. Je to jedinny "zdroj pravdy" tak je v poradku ze to commitnu.

68
Vývoj / Re:Rust - std::ANY alebo lepší návrh?
« kdy: 02. 12. 2021, 17:50:20 »

Nebo z PHP světa, composer: nastavím si balíček, že má být ve verzi vendor/balicek:1.*, a on mi vygeneruje graf závislostí, kde bude jinejvendor/jinejbalicek:1.8.6, ale já vím, že zrovna tento má chybu, a potřebuju nižší/vyšší. Tak to poedituju/přinutím mu dát konkrétní verzi, a zase dám composerem zkontrolovat závislosti a vygenerovat graf.

V php sem uz dloooouho nic nedelal takze si nejsem jistej v kramflecich, ten graf zavislosti je potreba commitovat?
Ale obcene bych nepovazoval konfiguraci dependency managementu za "kod".
Takze tam jsem OK s tim ze se kousek nejak generuje a kousek pise rucne.
Ten graf závislostí je třeba commitovat (není to specifikum php, je to principielní problém), protože ty máš v jednom souboru uvedený cca verze a balíčky, které chceš, zatímco v tom druhém souboru jsou už přesné verze všech balíčků. Aby se pokaždé vygeneroval stejný graf a stáhly se vždycky ty samé balíčky - důsledky si asi domyslíš.

No nejakou dobu uz sem to nemusel resit ale pokud si pamatuju dobre tak maven a leiningen oba funguji tak ze kdyz uvedu explixitni zavislost primo na nejake verzi tak se ta verze pouzije i pro tranzitivni zavislosti.
(Myslim, ze aspon driv maven fungoval tak ze ta explicitni verze musela byt uvedena "nahore", coz je trochu napalici, ale nevim jestli to tak porad je).

Graf si sice muzu vygenerovat ale nikam ho nekomitnu, protoze to stejne pri buildu nikdo nepouzije.



69
Hardware / Re:Vývojářské stroj
« kdy: 02. 12. 2021, 17:01:17 »
Vcera sem "vyvijel" nejakej script na tomhle:
https://rpishop.cz/zero/4311-raspberry-pi-zero-2-w-5056561800004.html

A super... muzu doporucit.
Do rozpoctu se vejdes  ;)
Ale mozna trochu zalezi co chces vyvijet....

70
Vývoj / Re:Rust - std::ANY alebo lepší návrh?
« kdy: 02. 12. 2021, 16:52:00 »
Zalezelo by na konkretni situaci. Bez konkretniho prikladu co by tam bylo potreba menit nedokazu rict.

typicky vztahy, ktere nejdou vycist z cizich klicu.

Jakoze mam sice sloupec s nejakejma IDckama z jiny tabule ale nemam nad tim definovany cizi klic?
No pak je otazka jestli chci, aby bylo to ORM chytrejsi nez sama databaze...
Nemit tam ten cizi klic muze mit nejakej duvod. A ja si pak spis myslim, ze je lepsi to ctit i v modelu.

71
Vývoj / Re:Rust - std::ANY alebo lepší návrh?
« kdy: 02. 12. 2021, 16:43:59 »
Inspiroval bych se co ostatní uváděli: mám verzovanou databázi. Změním tabulku, přejmenuju pár sloupců. schema-manage mi zařve, že je tam neverzovaná změna. Řeknu mu teda, aby vygeneroval sql-commit z té změny. Jenže jsem ty sloupce přejmenoval tak šikovně, že jsem ten nástroj zmátl, a on místo aby udělal příkaz pro přejmenování, tak udělá drop table + create table. Takže to předělám jak to má být, a commitnu.

S verzovanim DB schemat mam trochu problem... (kdyz neco verzuju tak predpokladam ze se snadno budu moct vratit k predchozi verzi ale to u DB a netrivialnich zmen "snadno" nejde) ale to je asi jedno.
V tomhle pripade je to stejne jedno.... co znamena ze "prejmenuju par sloupecku"
Pripojim se k DB a spustim nejaky "alter table" ne?

Takze jestli te spravne chapu tak si pustis nejakej kod nad DB, ten si neulozis protoze mas prece schema manage.
Ten ti ho vygeneruje spatne, takze to tam prepises aby to bylo tak jak uz si to jednou delal... a pak to commitnes.
Je to tak?
V tom pripade mi prijde jednodussi rovnou commitovat ty zmeny tak jak sem je psal predtim rucne a vynechat generator.

Nebo z PHP světa, composer: nastavím si balíček, že má být ve verzi vendor/balicek:1.*, a on mi vygeneruje graf závislostí, kde bude jinejvendor/jinejbalicek:1.8.6, ale já vím, že zrovna tento má chybu, a potřebuju nižší/vyšší. Tak to poedituju/přinutím mu dát konkrétní verzi, a zase dám composerem zkontrolovat závislosti a vygenerovat graf.

V php sem uz dloooouho nic nedelal takze si nejsem jistej v kramflecich, ten graf zavislosti je potreba commitovat?
Ale obcene bych nepovazoval konfiguraci dependency managementu za "kod".
Takze tam jsem OK s tim ze se kousek nejak generuje a kousek pise rucne.

72
Vývoj / Re:Rust - std::ANY alebo lepší návrh?
« kdy: 02. 12. 2021, 16:23:05 »
Mozna... to jsem, ale jeste nezazil, ze bych mel legacy DB a chtel nad ni stavet novy projekt pro ktery bych si z ni generoval model...

podle me docela casta situace.

Asi bych se i v takovem pripade snazil o nejaky jiny pristup...

jaky?

pokud chcete ORM, alternativni pristup je pouzit reflexi z metadat, a dopsat jen to co chcete navic. (co nejde odvodit). Coz se hodi u nejakych malych jednoucelovych veci.

Asi bych sel nejakou cestou podobnou jako treba u jaxb.
Zvlastni soubor s pravidly pro kustomizaci, ktery se pri generovani zpracuje vedle schematu a vygenerovany entity budou rovnou tak jak je chci....

Zalezelo by na konkretni situaci. Bez konkretniho prikladu co by tam bylo potreba menit nedokazu rict.

73
Vývoj / Re:Rust - std::ANY alebo lepší návrh?
« kdy: 02. 12. 2021, 12:15:46 »
Generovane ORM modely je treba schvalovat clovekem?

myslim situaci, kdy je vygenerujete jednou z legacy databaze a potom uz je edituje clovek. vetsinou nejak funguji out of box, ale DB metadata vetsinou neobsahuji vsechny potrebne informace, musi doplnit clovek.

Mozna... to jsem, ale jeste nezazil, ze bych mel legacy DB a chtel nad ni stavet novy projekt pro ktery bych si z ni generoval model...
Asi bych se i v takovem pripade snazil o nejaky jiny pristup...

74
Vývoj / Re:Rust - std::ANY alebo lepší návrh?
« kdy: 02. 12. 2021, 11:11:58 »

Přesně takto se to používá:
1/ Generovaný kód, jehož znění nevyžaduje schválení člověkem = generuje se na CI serveru (nebo kdekoliv jinde) + necommituje se.
2/ Generovaný kód, který mi vygeneruje stroj, ale musí projít schválením člověkem = generuje se u vývojáře, a pak se commituje.

...

Mel bys nejakej netrivialni priklad 2?

ORM modely pro existujici databazi, DB migrace (vetsinou nemusite cist, ale obcas chcete modifikovat).

Generovane ORM modely je treba schvalovat clovekem?
(Vim ze se to deje... I na mem soucasnem projektu to tak je... dokonce mi tam do entit cpou business logiku.... ale nelibi se mi to a bojuju proti tomu... protoze si myslim, ze je to nepekne a neni to potreba.)
Tem DB migracim asi nerozumim...

75
Vývoj / Re:Rust - std::ANY alebo lepší návrh?
« kdy: 02. 12. 2021, 06:27:05 »

Přesně takto se to používá:
1/ Generovaný kód, jehož znění nevyžaduje schválení člověkem = generuje se na CI serveru (nebo kdekoliv jinde) + necommituje se.
2/ Generovaný kód, který mi vygeneruje stroj, ale musí projít schválením člověkem = generuje se u vývojáře, a pak se commituje.

Má to tyto důsledky:
V prvním případě se jede na tvrdo optimalizace, stroj může cokoliv.
V druhém případě je očekáváno, že to co se vygeneruje musí být co nejvíce čitelné; nejlépe optimalizované pro diff. (A následně se to třeba celé ještě projede první variantou.)

TypoProvidery a podobně jsou jen první varianta. Jen už zakomponovaná do překladače. Jak už tu někdo zmínil. Ve skutečnosti je to ale spousta dalších případů: gcc, javac, scalac, ... etc, kde by tě ani nepadlo uvažovat, že je to jen prachsprostej generátor kódu. A ne, není to něco jiného :)

Mel bys nejakej netrivialni priklad 2?

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