1. Fórum Root.cz
  2. Profil Ziktofel
  3. Zobrazit příspěvky
  4. Příspěvky

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

Stran: 1 2 3 [4] 5 6 ... 28
46
Sítě / Re:Nový Wi-Fi router - doporučení
« kdy: 09. 04. 2019, 23:31:40 »
Stock FW jsem nezkoumal, je to devbranch, nebot je to novej router, ale funguje to a nikde jsem USB uloziste nepotreboval, jako ja tam nic extra provozovat nechci, je to proste router, kterej jde nastavit tak, jak ja chci a bude delat, co chci

47
Sítě / Re:Nový Wi-Fi router - doporučení
« kdy: 09. 04. 2019, 16:34:46 »
Nakonec jsem jiz poridil TP-Link Archer C6 a nahral OpenWRT

48
Hardware / Re:Rychlejší RAM nebo víc paměti?
« kdy: 08. 04. 2019, 13:47:23 »
Takze moje doporuceni zni: 2x 16 GB 2667 MHz (32 GB RAM), ma-li deska 4 sloty, tak kdyz tech virtualek bude vic, tak pujde dokoupit dalsi dva moduly na konecnych 64 GB RAM

49
Hardware / Re:Rychlejší RAM nebo víc paměti?
« kdy: 08. 04. 2019, 13:44:00 »
Dej si rovnou 32 GB, potrebujes stejny moduly, aby sel dualchannel coz ti udela dvojnasobnou propustnost pameti. Ja sam mam v ntb dva 16 GB 2667MHz moduly

Jinak pouzivas integrovany GPU? To bejva hlavni zrout propustnosti pameti (sdili ji s CPU), ta dostane bez dualchannelu az polovicni vykon.

AD kapacita vs rychlost pameti: Kdyz ti dojde RAM, tak uz seberychlejsi ti nepomuze, osobne bych se podival po dvojici 16 GB 2667 MHz modulu

50
Vývoj / Re:Je Swagger utter crap?
« kdy: 04. 04. 2019, 20:21:57 »
Zprasit se da vzdycky a vsechno. Touto logikou bys nevytvoril nic

51
Vývoj / Re:Je Swagger utter crap?
« kdy: 03. 04. 2019, 23:39:29 »
Jako ja videl swagger jako cestu k vytvoreni snadno udrzovatelne dokumentace k REST API, ve springu (Springfox) se doplnilo jenom par anotaci a byl kod a dokumentace na jednom miste, coz se fajnove reviewuje. API drzelo Resource semantiku (tj GET /cats, GET /cats/1, POST /cats PUT /cats/1, DELETE /cats/1). Jako hlavni problem, na co nadavas, nevidim swagger, ale prave to, ze nekdo prasacky navrhne API. Na Swagger by se dalo jistym zpusobem pohlizet, jako na WSDL pro REST (pomoci obojiho lze vygenerovat kostru kodu)

52
Vývoj / Re:GIT server - nasazení kódu do produkce
« kdy: 03. 04. 2019, 15:10:41 »
Rozhodne se primlouvam za Gitlab CI, kazdopadne je treba domluvit a nastavit procesy tak, aby na produkci sel vyhradne jiz schvaleny a otestovany kod (Merge requesty, review, testovani), to, jak se napise CI skript je implementace nejak nastavenejch procesu

53
Vývoj / Re:Několik nejasností začátečníka s Gitem
« kdy: 27. 03. 2019, 17:25:38 »
Jinak submodul by mel splnovat nasledujici podminky:
1. Submodul je zaroven samostatnym plnohodnotnym projektem (jako napriklad knihovna). Pokud ne, tak submodul nevytvarim, ale pouziju obycejny adresar v hlavnim projektu
2. Pro sestaveni hlavniho projektu potrebuju zdrojaky submodulu. Pokud mi staci pouze produkt sestaveni submodulu (napriklad jarko), tak submodul nepouziju a pouziju napriklad maven (nebo jeho ekvivalent, zalezi na pouzitym jazyce)

Malokdy jsou obe podminky splneny, v praxi, jak uz bylo receno, submoduly se pouzivaji malokdy

54
Vývoj / Re:Ako komplikovane programujete?
« kdy: 26. 03. 2019, 23:17:11 »
Jako skoro vsechno jde snad prepsat na "for", potiz ale je v tom, poznat, co ten optimalizovanej "for" loop dela. For-loop vs foreach s lambdou, to je imho presne ta vec, co by mel delat kompilator, ne programator. Taky programator v C nedela rucne loop-unwind a udela to za nej prekladac

55
Distribuce / Re:Ubuntu - překládání
« kdy: 21. 03. 2019, 14:13:07 »
Osobne bych se napred podival, jak preklady delaji standardni nastroje (grep, sed apod.) a terminologii bych prevzal od nich

56
Server / Re:Jak se připojit k serveru z Windows?
« kdy: 13. 03. 2019, 18:05:31 »
Co jsem tu cetl, tak se tu rozjelo pekny flame...

OP chce editovat soubor na serveru, ktery je pristupny pouze s pravy roota (potrebuje sudo) v editoru, na kterej je sam zvyklej
Vidim tu nejaky narky vim ultras, ale pochopte uz krucinal, ze vim fakt neni editor pro kazdyho a kdo neni na nej zvyklej, tak snaze udela chybu (vi co zmenit, ale zmasti to v ramci ovladani editoru)

Jinak at tu jenom nehejtuju: Ja bych zvazil, to mit konfigurace v gitu a nasazovat to na servery nejakym CI (treba gitlab). Vono neni od veci mit k tem konfiguracim i nejakou dokumentaci

57
Hardware / Re:I-TEC USB 3.0 / USB-C - funguje někomu s AMD Ryzen Pro?
« kdy: 03. 03. 2019, 11:00:58 »
No, nektery krabicky sice maji dalsi USB vystupy, ale pro graficky vystupy vyzaduji DP alternate mode

58
Vývoj / Re:Jaké používáte git workflow a proč?
« kdy: 02. 03. 2019, 13:02:29 »
@prihlaseny_uzivatel: pokud mas podporovat i stary verze, tak ten tvuj model proste pouzit z principu nejde a musi se mergovat, ten tvuj postup funguje jenom na ten tvuj specifickej release model

59
Vývoj / Re:Jaké používáte git workflow a proč?
« kdy: 01. 03. 2019, 19:54:36 »
Tak tady do toho i keca release model

Udrzujou se stary releasy? Pak bude potreba branch pro kazdy release (a opravy pak mergovat ze starych do novych)
Jestli master = stable nebo master = devel head zalezi na okolnostech projektu, jsou situace, kdy dava vetsi smysl to, jindy to druhy
Pro kazdy release tag, changelog se hodi generovat z commitu referencovanych na tickety (jednoduchy a snadna udrzba)

Jinak review pred mergnuti, v Gitlab CI se na Merge Requesty spustej automaticky testy a lze odchytit radu potencialnich problemu, nez se rozbije to nekomu dalsimu. Pro topic branche pouzivame v Gitlabu forky
Merge vs Rebase: preferuju merge: commity pak vzdy obsahuji to, co dany vyvojar skutecne udelal, mirne slozitejsi historie nevadi

Nazvy branchi u nas nijak standardizovany nejsou, ale mym zvykem je to delat podle ticketu - vis ktera rozdelana prace k cemu patri a kdyz je potreba se k necemu vratit rozdelanymu, vim, kde to mam. Jinak commit by mel vzdy nejakym (v tymu standardizovanym) zpusobem bejt navazanej k ticketu, ke kterymu se vztahuje. Casto u projektu, hlavne kdyz uz jsou dlouho vyvijeny, se "blamuje", aby se zjistilo, proc se to tehda zrovna delalo tim urcitym zpusobem, jakym to je udelany.

Jinak za sebe muzu doporucit Gitlab

60
Hardware / Re:Dokovací stanice na dva monitory. USB-C, nebo Thunderbolt3?
« kdy: 14. 02. 2019, 11:37:12 »
@Marek Staněk: hlavne v tomdle vlakne uz padlo, ze USB 3.0 = USB grafika a to fakt nechces

Provozne nejlepsi a nejbezproblemovejsi je zarizeni, ktery ty dva DP z toho TB3 vytahne a pres nej se ty dva monitory (az 4K@60Hz) pripojej

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