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 - klobások

Stran: [1]
1
Software / Re:Nahradenie hex stringu
« kdy: 10. 03. 2019, 13:51:47 »
https://en.wikipedia.org/wiki/Demand_paging

Cele nacitanie suboru vznika len v pripade ak robis "read all" operacie. Cize bezne sa subory prechadzaju riadok za riadkom, pripadne v blokoch, len malokedy sa nacitaju cele do pamete. Je jedno o aky jazyk ide.

2
Software / Re:Nahradenie hex stringu
« kdy: 10. 03. 2019, 12:10:35 »
Tu mas Go verziu(2mb), ale moc som to netestoval takze za nic nerucim.

Kód: [Vybrat]
package main

import (
"flag"
"golang.org/x/exp/mmap"
"log"
"os"
"time"
)

var (
what, with, where string
)

func main() {
flag.StringVar(&what, "replace", "", "String to be replaced.")
flag.StringVar(&with, "with", "", "String to act as replacement.")
flag.StringVar(&where, "in", "", "Path to file.")
flag.Parse()

reader, err := mmap.Open(where)
if err != nil {
log.Fatal(err)
}
defer reader.Close()

file, err := os.OpenFile(where, os.O_WRONLY, 0666)
if err != nil {
log.Fatal(err)
}
defer file.Close()

start := time.Now()
defer func() {
log.Println("Elapsed time:", time.Now().Sub(start).String())
}()

var pos int
whatLen := len(what)
cpr := make([]byte, whatLen, whatLen)
first := what[0]
max := reader.Len()

for {
if pos >= max {
log.Println("no match found")
return
}

if reader.At(pos) == first {
if _, err := reader.ReadAt(cpr, int64(pos)); err != nil {
log.Fatal(err)
}
if string(cpr) == what {
if _, err := file.WriteAt([]byte(with), int64(pos)); err != nil {
log.Fatal(err)
} else {
log.Println("Success")
}
return
} else {
pos += whatLen
continue
}
}

pos++
}
}


3
Vývoj / Event Sourcing - diffovacie eventy
« kdy: 05. 03. 2019, 12:22:32 »
Rastie mi kod pre jeden ES projekt a ES vzdy pridava velky "overhead". Ide o mikrosluzby takze pre kazdu treba riesit agregat(y), eventy, prikazy a td. Eventy maju schemu definovanu cez PB a kazdy event samozrejme musi mat "apply" handler.

S tym ako rastie codebase zacinam zvazovat prechod na unifikovany system. Co tym myslim je nasledovne:

Event sa vzdy vztahuje na nejaky "resource" alias agregat. Kazdy agregat je vo svojej podstate programova entita(nehovorim o ddd) co je vo svojej podstate dokument ktory mozno brat ako normalny json objekt.

Cela podstata eventu je zachytenie zmien ktore boli vykonane na specifickom agregate. Niekto moze debatovat o tom ze eventy nemusia byt vzdy spojene s agregatom(napriklad notifikacia o odoslani emailu) ale ja osobne to beriem tak ze event je VZDY napojeny na agregat, aj ked ten agregat moze reprezentovat len uplnu blbost ako je zaznam v logu, stale ide o zmenu stavu ktoru treba zachytit.

Vzhladom na hore uvedene zvazujem prerobit eventy na objekty, ktore ostanu tak ako su, avsak ich payload by nebol definovany schemou ale obsahoval by sadu zmien ktore boli na (json) dokumente vykonane formou k-v zoznamu kde kluc by bol cesta ku zmene(foo.bar.0.baz) a hodnota by bola hodnota priradena tejto ceste po aplikovani zmien(eventu). Null by znamenal zmazanie. Samozrejme by slo pouzit aj nejaky standard ako je napriklad rfc 6902 pre json patch.

Eventy by uz neniesil identitu(field_foo_changed, user_created, item_added_to_cart...) ale niesli by tagy oddelene ciarkou napriklad, ktore by niesli nazvy poli ktore boli zmenene. Cize kontext zmeny by zanikol.

Eventy stale budu podporovat verzovanie takze handler bude vediet po aplikovani eventu nacitat data z agregatu spravne. Replay eventov bude vzdy fungovat bez nutnosti riesit schemu nakolko ide o jendoduche "patchovanie" takze ku tomu netreba ziadnu specialnu logiku.

Listenery/projektory mozu stale pocuvat na eventy tak ako predtym, ale namiesto pocuvania na specificky event budud pocuvat na specificke zmeny - podla tagov, nie podla povodnych nazvov eventov zalozenych na kontexte.

Kvoli absencii schemy budu reaktory moct vytvorit aktualny stav agregatu bezs nutnosti poznat schemu. Pokial ide o nacitanie dat z agregatu, nic sa nemeni nakolko reaktory musi vzdy vediet aku formu dany agregat ma takze aj predtym musel reaktor rozumit datam ktore spracuva, cize nic sa nemeni, schema nie je nutna.

Takyto pristup ma dva nasledky - tym ze zanikne kontext eventov vzniknu eventy ktore mozu byt vecsie a obsahovat viacej udajov nez predtym, co zapricini vzysenie trafficu ale zaroven znizenie celkoveho poctu eventov.

Druhy nasledok je absencia kontextvych dat ktore neboli sucastou zmien ale boli uzitocne pre reaktory - napriklad aktualny menovy kurz. To sa vsak da vyriesit novym polom na objekte eventu specialne pre taketo data, takze prakticky sa nic nezmeni.

Co si o niecom takom myslite? Zatial som nedostal ziaden konstruktivny feedback, takze teoreticky nevidim nejake nevyhody takehoto systemu. Pozitiva o ktore mi ide su zrychlenie vyvoja a zjednodusenie logiky zakomponovania ES do biznis logiky.

4
/dev/null / Re:Sestupná kvalita lidí v IT
« kdy: 01. 03. 2019, 18:45:40 »
Snuff to presne trafil. Moja zakladka a stredna boli presne take ako pisal. IT, telekom a banking su najlukrativnejsie odvetvia, pokial ide o sluzby a nie manualnu pracu, takze sa tam bude hrnut viacej ludi, aj takych co sa na to proste nehodia. Taktiez na kodera cloveku staci klavesnica a za par mesiacov z neho moze nieco byt. Mam kamosa co nikdy nekodil, robil roky na podpore v jednej IT firme, po rokoch zistil ze karierne sa nikam nedostane, teraz je jr java developer.

Z mojho pohladu napriklad vidim problem v tom ze firmy casto davaju inzeraty s poziadavkami ktore su bud absurdne alebo to proste prehanaju s narokmi na technologie alebo skusenosti, pripadne casto pozaduju protichodne technologie.

Toto mam potvrdene aj v zahranici a je to uplne bezne. Skuseny vyvojar taky inzerat odignoruje lebo nema o uvedene technologie zaujem, neovlada ich alebo su poziadavky celkovo prilis vysoke. Kdezto "blbsi" vyvojar bud uplne nerozumie poziadavkam, alebo to fejkne a skusi a uvidi(fake it 'till you make it). Potom firmam chodia masy nie uplne idealnych kandidatov a potom zlozenie firmy aj tak vyzera. Na YT som nedavno videl video od nejakeho programatora kde hovoril ze to firmy robia schvalne kvoli tomu ze plno ludi pride z IT vysky a myslia si ze ked maju nejaky titul a vedia napisat hellow world v Jave tak su sr. programatori, pritom prax maju mizernu a realne vedia ***, takze firmy radsej zvysia poziadavky aby odfiltrovali tento typ ludi, avsak ako som pisal, odradza to aj skusenych koderov ktorym sa nechce stracat cas behanim po desiatkach pohovorov a zistovat co ta firma REALNE chce. Nehovoriac o tom ze toto do**** trh nizsimi platmi lebo tym ze chodi vela menej naskilovanych ludi a ked pride niekto kto naozaj vie co robi a vypyta si plat nalezity ku jeho skusenostiam a znalostiam, tak sa idu zblaznit lebo take sumy este nevideli ani na papieri.

Ja osobne napriklad kodim 20 rokov uz pomaly a viem co chcem a nechcem robit a prakticky 99% ponuk ignorujem. Takze aj z osobnej skusenosti mozem potvrdit ze firmy sa same podkopavaju tymito praktikami.

Ono, trh je idealny pre jr-mid vyvojarov. Je ich vela, su lacny a lahko sa vo firmach pretoci velky objem ludi. Ked produkt nema pozadovane vysledky, prepustia sa ludia. Ked je treba nieco riesit, hned sa najmu novi lebo ponuka je presytena. Seniorov ludia nechcu platit lebo sa im to nevyplati. Taktiez sa firmy stale vidia ako tie ktore maju navrch a vidia zamestnacov ako podradnych a ktory skacu ako firma piska, kdezto dobra firma chape ze dobry zamestnanec je neocenitelny. Ale takych firiem nespocitam ani na prstoch jednej ruky.

5
Sítě / Re:docker: měnící se IP hosta
« kdy: 23. 02. 2019, 13:24:57 »
Pouzi
Kód: [Vybrat]
host.docker.internal

6
Vývoj / Dynamicka cenotvorba / pricing engine
« kdy: 22. 02. 2019, 19:10:08 »
Viem ze toto nie je nic nove na svete a plno spolocnosti to uz riesilo a prislo s nejakymi navrhmi. Osobne vsak zatial neviem o ziadnom rieseni ktore je mozne aplikovat na konkretneho uzivatela a nie na vecsiu skupinu a s pouzitim pred-vypocitanych cien.

Prakticky ma zaujima, ci je vobec realne vytvorenie dynamickeho enginu ktory by vypocital cenu produktov na zaklade definovanych podmienok pre kazdeho uzivatela samostatne?

Problemom su query ktore pouzivaju cenovy rozsah alebo radenie podla ceny. Pokial je pocet produktov vo vysokych cislach tak by to znamenalo nutnost nacitania vsetkych produktov, vypocitania cien pre kazdy samostatne a nasledne aplikovanie filtra/podmienok query. Co je samozrejme mozne, ale odpoved by asi nebola vygenerovana v dostatocne rychlom casovom useku na to aby to bolo realne pouzitelne v produkcii.

Je vobec nieco take mozne? Realne ma napada akurat nejaka forma paralelizmu a shardovania ale komplexnost takehoto riesenia mi pride znacne vysoka do realnej prevadzky, respektive by to vyzadovalo asi tim odbornikov nieco take dat dokopy, jednotlivec by to asi sam nenakodil.

7
Vývoj / Re:Vývoj krabicového projektu - tipy pro začátek
« kdy: 18. 02. 2019, 18:25:35 »
prakticky sa neda odpovedat na otazku. pokial od zaciatkuu nevies co robis tak architektura moze vyzerat naozaj akokolvek.

najlepsia rada je - rob vzdy na mieru, nikdy neplanuj dopredu. zbav sa "what if" myslenia a aplikuj yagni.

osobne by som najskor isiel cestou mikrosluzieb a event sourcingu. to je jediny system kde mozes "plugovat" bez obmedzeni. mozes si aj spetne otestovat ako by sa spravala nejaka ficura alebo sluzba takze hned vies ci pokracovat alebo nie, pripadne co upravit a td.

problem je ze ES je VZDY na mieru a nenajdes teda ziadne realne priklady z ktorych sa mozes inspirovat, takze je to dost o pokus-omyl kym prides k niecomu co ti bude vyhovovat pre tvoje potreby a tona nacitaneho materiali a zhliadnutych prednasok na youtube.

druha vec je ze je to dost zlozite spravit dobre, ludia do ES tahaju zvyky z predoslcyh projektov(hlavne co sa tyka schem, orm, crud a spol.) a na koniec im vznikne tak akurat distribuovany crud system plny zavyslosti a deadlockov.

PS: samozrejme je rozdiel od toho ci krabicove riesenie je SaaS alebo self-hosted.

8
Hledám práci / Golang, externe
« kdy: 18. 02. 2019, 18:11:25 »
Robim s Go a mam volne kapacity, keby niekto zhanal externistu na kratkodobu alebo dlhodobu spolupracu. Kodim skoro 20 rokov, nie som lacny, nehladam Javu, C/C++/C#, Python a ine.

PM.

9
Server / Jak databáze řeší indexy?
« kdy: 17. 02. 2019, 18:19:01 »
Ked si vezmem ze vsetky db pod kapotou pouzivaju na indexy btree(pripadne rtree na priestorove objekty) a hashmapy pre uchovanie riadkov v tabulkach, tak by ma vcelku zaujimalo, ako riesia porovnavanie vysledkov a radenie. Napriklad ak nejaka query vrati 100 000 zaznamov pre index A a rovnako pre index B, tak ratam ze db musi do pamete nacitat 200 000 zaznamov a potom to nejak porovnat a odfiltrovat tie ktore sa nezhoduju. Nehovoriac o tom ze ak mam par mega zaznamov tak cely index asi tiez nezaberie len par kB. Pripadne potom este aplikovat aj radenie. Cize ma zaujima to, ako to robia tak aby si nezaplnili pamet pokial ide o nejaku vytazenu db napriklad a stale vedia zabezpecit rychlost odozvy?

Davkovanie moze byt riesenie ale v konencom dosledku sa aj tak musia porovnat vsekty najdene vysledky cize tam uz davkovanie asi nepomoze, plus keby sa vysledky davok zapisovali na disk, kym sa spracuju zvysne ulohy na neskorsie porovnanie, tak by to najskor znacne spomalilo takuto db, takze davkovanie tam asi nebude.

10
Server / Re:Docker a Google Cloud Datastore / Amazon S3 volume
« kdy: 18. 11. 2016, 07:11:32 »
No ved ten druhy variant prave mam.
Ale ten prvy variant mozno bude fungovat lepsie, ak by som pouzil Kubernetes a namapoval to na Pod, vtedy by to asi malo fungovat pre kontajnery v nom. Lenze som nevidel ziaden driver na to http://kubernetes.io/docs/user-guide/volumes/

11
Server / Docker a Google Cloud Datastore / Amazon S3 volume
« kdy: 17. 11. 2016, 21:49:26 »
Ahojte,
zacal som sa hrat, prvy krat, s dockerom a postupne sa prepracoval k tomu ze mam tri kontajnery: nginx, php-fpm a data.

Na nginxe bezi oficialny nginx s vlastnym konfigom, php-fpm je z oficialneho image bez zasahu a v data si stahujem z gitu php zdrojaky.

Zatial sa hram len s docker compose ale chystam sa na kubernetes, respektive Google Container Engine.

Anyway, data image spristupnuje volume v dockerfile a tu mountujem v docker-compose.jsom cez volumes_from parameter a aj php aj nginx tuto volume z data vidia.

Co vsak rieism teraz je to ze chcem namountovat Google Cloud Datastore respektive Amazon S3 do nejakej zlozky v data kontajnery/image, napriklad /app/data a moct tak citat a pisat do tohto backendu z nginx(prakticky len citanie) a php kontajneru.

Neviem ako to riesi Amazon S3 ale GCD ma na to gcsfuse utilitku zalozenu na libfuse. Cez nu sa mi podarilo v pohode namountovat backend do /app/data v mojej data image a spustit kontajner.

Ked si otvorim data kontajner cez shell tak ten backend realne funguje, vidim subory, vytvaram subory, citam subory a tak dalej...a ked si otvorim webovu amdinistraciu(google/amazon) tak je vsetko ako ma byt.

Ked sa vsak pozriem do nginx alebo php kontajneru tak zlozka je prazdna a akekolvek zmeny v tejto zlozke vidia iba tieto dva kontajnery a nie samotny data kontajner ktory volume poskytuje.

Prisiel som k zaveru ze nginx a php kontajnery vidia "originalnu" cielovu zlozku(/app/data) do ktorej nie je namountovany backend a ze tento backend funguje iba priamo v data kontajnery.

Avsak nechcem robit monoliticku aplikaciu ani mountovat backend v kazdej image, tak by ma zaujimalo ci neviete niekto ako toto rozbehat? V principe je to iba otazka dockeru a ako riesi prepojenia volume a kontajnerov do coho ja moc nevidim zatial.

Googlil som, ale neviem sa nicoho dopatrat.

Stran: [1]