- gban: Ingyen kellene, de tegnapra
- btz: Internet fejlesztés országosan!
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- bambano: Bambanő háza tája
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Magga: PLEX: multimédia az egész lakásban
- Carlytoo: Pánikszindróma #3
- sziku69: Szólánc.
-
LOGOUT
Új hozzászólás Aktív témák
-
Silεncε
őstag
válasz
Dißnäëß
#14896
üzenetére
Virtuális asztalokat én laptopon szoktam használni, ha éppen nincs külső monitor kéznél (Windowson). Sajnos ultrawide monitorom még nem volt, úgyhogy arról nem tudok nyilatkozni, de szerintem az inkább játékra meg videovagasra jó (havernak volt programozasra, o is inkabb eladta). Nekem otthon két 1080p van (21, 24 col, sajna nem egyforma nagyságúak), irodában előző munkahelyen két 24" 1080p volt, itt kipróbáltam az egyiket állítva, nekem nem volt jó, a tetejét már nem láttam rendesen (nem volt a legjobb a betekintési szöge meg messze is volt). Most HO miatt az otthoni monitoraimat használom munkára is, mivel laptopunk van, így van három kijelzőm is
-
#14898
I02S3F
addikt
instantwater
#14897
I02S3F
addikt
válasz
instantwater
#14897
üzenetére
Azt hiszem ez egyéni preferencia lesz, mert nekem két monitor kényelmesebb, mint a virtuális asztalok között navigálni. Bár utóbbit is használtam!
-
#14897
instantwater
addikt
Dißnäëß
#14896
-
Dißnäëß
nagyúr
Sziasztok, remélem tudtok segíteni, tapasztalt, sok éve fejlesztők tanácsát kérném következő - meglehetősen banális (?) - szituhoz:
- infra tervezés
- linux, virtualizáció, konténerek
- node.JS, python
- frontend
- SQL
- hobbi fotózás és fotókidolgozásSzóval nagyjából sokmindenben kezdek elmélyedni már egy ideje.
Gyakorlati tanácsra lenne szükségem:
Van két monitorom és nem férek. Bal oldali egy 1680x1050-es öreg (de jó), jobb oldali 1920x1080-as, szintén jó. De nem elég, a desktop-ok közötti váltogatás meg olyan idegen tőlem kicsit + szeretném egyszerre is nézni őket, mikor hova pillantva.Mit ajánlanátok inkább: több fullhd monitor egymás mellett-felett (mondjuk olcsó fhd-sek, 3db moncsi 2 sorban), vagy egy hatalmas nagy lágyan ívelt szuperszéles böhöm ?
A színhűségnek a fotózás miatt legalább az egyik moncsin meg kell lennie (sRGB elég), ha többmonitoros verzió. A többire nem fontos.
Illetve az érdekelne még, hogy van-e értelme pl. az egyik jobbszélső monitort állóba forgatni kódhoz ? 1-2 helyen látok ilyet elvétve, de nem sokan élnek ezzel, ennek oka van, hogy nem sokan, vagy szimplán csak "weirdo" ?
Ui.: Debian, XFCE, Ryzen -
válasz
dabadab
#14890
üzenetére
"Meg kellene nézni, hogy pont mire fordul le a kódod, de simán lehet, hogy a num++ nem egyetlen utasítás, hanem valami olyasmi, hogy a numot betölti egy regiszterbe, megnöveli a regisztert és azt írja vissza a memóriába:"
Ez stimmel:
mov eax, DWORD PTR num[rip]add eax, eaxmov DWORD PTR num[rip], eax -
válasz
Silεncε
#14889
üzenetére
Ennyire azert nem egyszeru a dolog, ez nem a klasszikus race condition. Ha az lenne, akkor a
std::cout<<"Double starting " << num << std::endl;
es astd::cout<<"Double ending " << num << std::endl;
sorok altal kiirt szam legalabb 2x-esere novekedne a ket sor kozott. De itt nem ez van.Mindjart gondolkozom rajta picit
-
#14891
BProgrammer
lelkes újonc
BProgrammer
lelkes újonc
Azt értem, hogy véletlenszerű, igazából pont ezt akartam próbálgatni, hogy mindig más eredményt kapok emiatt, de nem értem, hogy mi lehet az a körülmény, ami miatt nem lesz nagyobb 2000000000-nál az eredmény. Mikor látom, hogy megtörténik a duplázás, illetve egyszer valamikor a végére az összes increment-nek is le kell futni, nem?
-
#14890
dabadab
titán
BProgrammer
#14888
válasz
BProgrammer
#14888
üzenetére
Isten hozott a nematomi műveletek világában
Meg kellene nézni, hogy pont mire fordul le a kódod, de simán lehet, hogy a num++ nem egyetlen utasítás, hanem valami olyasmi, hogy a numot betölti egy regiszterbe, megnöveli a regisztert és azt írja vissza a memóriába: ha itt az első és a második vagy a második és a harmadik lépés között történik meg a duplázás, akkor a végén pont kétmilliót kapsz, mert a harmadik lépés felülírja a duplázás eredményét.
-
#14889
Silεncε
őstag
BProgrammer
#14888
Silεncε
őstag
válasz
BProgrammer
#14888
üzenetére
Race condition. A két szál teljesen véletlenszerű, mikor jut CPU-hoz, így a végkimenetele is véletlenszerű, hogy éppen mikor mi lesz az eredmény. Megoldás: mutex-szel le kell zárni a valtozót
-
#14888
BProgrammer
lelkes újonc
BProgrammer
lelkes újonc
Sziasztok!
Próbálgatom a párhuzamos programozást C++-ban és nem értem a következő működést:
Elindítok 2 szálat, az egyiken 2000000000-szor növelgetek egy globális változót, a másikat 2 másodperces sleep-pel indítom majd egyszer csak beduplázom ugyanazt a változót konkurensen, miközben az increment még nem ért véget. Közben kiírogatom a dolgokat, ellenőrzöm a 2 másodperc sleep után még valóban nem ér véget az increment sose az én gépemen. Látszik is, hogy kb. beduplázódik a szám, valamikor a futás közben. Szóval azt várnám, hogy a legvégén, mire mindkét szál lefut, valami 2000000000-nál határozottan nagyobb szám lesz az eredmény minden esetben. Valamikor tényleg ez is van, de nagyon sokszor van, hogy pontosan 2000000000 az eredmény. De ez hogy lehet, hiszen nem akkor fut le soha a duplázás, mikor az n még 0 (ellenőrzöm a kiiratással). Arra is gondoltam, hogy hátha valami optimalizáció van, hogy valójában nem fut le 2000000000-szor a ciklus, hanem az i helyett magát a num-ot nézi, hogy ha az nagyobb, akkor kilép a ciklusból, de akkor meg máskor mér lehet nagyobb? Meg hát -O0 kapcsolóval is ugyanaz a probléma.Meg amit végképp nem értek, hogy egyszer volt olyan is, hogy nem duplázta be a számot, és a duplázás előtti és utáni kiíratás csak pár incrementálásban különbözött. Szóval eléggé össze vagyok zavarodva. Van ötletetek?
Előre is köszi a válaszokat!
#include <iostream>#include <thread>#include <chrono>using namespace std::chrono_literals;unsigned int num = 0;void increment(){std::cout<<"Starting increment "<< num << std::endl;for(int i=0; i<2000000000; ++i){++num;}std::cout<<"Ending increment "<< num << std::endl;}void doubler(){std::this_thread::sleep_for(2s);std::cout<<"Double starting " << num << std::endl;num*=2;std::cout<<"Double ending " << num << std::endl;}int main() {std::thread t1(increment);std::thread t2(doubler);t1.join();t2.join();std::cout << num << std::endl;
} -
#14887
instantwater
addikt
nevemfel
#14886
válasz
nevemfel
#14886
üzenetére
Ez egy őrültség.
Első dolgom volt a GitHub organisationben beállítani, hogy továbbra is master maradjon a neve új repoknál is.
Lesz ebből még fejfájás kezdőknek, hogy nem létezik a branch amit a StackOverflowon találtak a git parancsban.Ne borítsuk már fel a világot mert néhányan unatkoznak.
Amúgy sincs már rabszolgaság. Senki nem fog megsértődni egy master branchen. Főleg, hogy soha nem is volt slave branch.
-
kovisoft
őstag
Miért van külön always blokkokba téve a számolás, a maxos-t meghatározó ciklus, ill. a maxos-ből a prediction_-t meghatározó case? Ezek egymásra épülnek, nem egymás után kellene végrehajtódniuk? Nem igazán értek hozzá, úgyhogy bocs, ha hülyeséget írok, de az always blokkok nem párhuzamosan hajtódnak végre? Mert akkor a végeredmény meglesz már mielőtt ki lenne számolva (mint a Tanú c. filmben az ítélet
). Nem kellene az egészet egy nagy always blokkba tenni? -
kovisoft
őstag
válasz
kovisoft
#14876
üzenetére
Plusz az nem probléma, hogy az i változót két dologra is használod két különálló always blokkban? Az egyik blokkban lépteted 0-tól 6-ig a neuronháló szintjeinek végigszámolásához, a másik blokkban ciklusváltozónak használod. Nem kellene a második always-ben megvárni, amíg i==6 lesz?
-
y@g4n
tag
-
kovisoft
őstag
A lenti kódrészben az i 25-től megy 34-ig, ezért a maxos 5-től 14-ig vehet fel értéket. A case-ben viszont 0-tól 9-ig vizsgálod. Ezt biztos, hogy így akartad? Nem maxos = (i - 25) kellene? És a max_ nem kap kezdőértéket, biztos, hogy alapból 0 az értéke és nem valami szemét van benne, ami miatt esetleg soha bele sem megy az if-be (és akkor a maxos-ba is valami szemét kerül)?
integer maxos;
always @(posedge clk)begin
for(i = 25; i < 35; i = i + 1)begin
if(neurons[i] > max_)
max_ = neurons[i];
maxos = (i - 20);
end
end
always @(posedge clk)
case(maxos)
0: prediction_ = 10'b1000000000;
1: prediction_ = 10'b0100000000;
2: prediction_ = 10'b0010000000;
3: prediction_ = 10'b0001000000;
4: prediction_ = 10'b0000100000;
5: prediction_ = 10'b0000010000;
6: prediction_ = 10'b0000001000;
7: prediction_ = 10'b0000000100;
8: prediction_ = 10'b0000000010;
9: prediction_ = 10'b0000000001;
endcase -
y@g4n
tag
Sziasztok, Veriloggal (Vivado) kapcsolatban kérek segítséget. Generáltam egy hosszú verilog kódot;
egy Keras-Tensorflow segítségével trainelt neurális háló weights és bias értékeit extraktáltam pythonban, majd (hogy ne kézzel gépeljek ennyit) szintén pythonban egy szkripttel legeneráltam a sok regisztert meg localparamot verilogul.
Az input az 784 darab integer localparamként (egy kép az MNIST datasetből), az output pedig az FPGA 10 ledje közül lenne az egyik (amelyik számjegyet jelentette az input, azon led villan fel).
A köztes logika pedig a neurális háló weights * biases lenne layerenként.Szintézis, implementáció lefut, kihasználtsági szint cirka 0%, a schematicon összesen 10 db output buffer van, amik fix 0-ra állítja a ledeket.
Kérdésem hogy miért történik ez?
Ami segítséget eddig kaptam:
"Mivel a bemeneteidnek fix értéke van, így a kimenetnek is (10 db nulla az értéke az adott bemenet mellett), ezért a szintézer kb. mindent kidob, hiszen nincs szükség ténylegesen a szorzók, stb, implementálásására."
Ez még egy olyan kódra volt válasz mikor a legalján lévő switch case-ben volt default ág, már nincs.
De nem tudom mit akar ez jelenteni!
Miért ne lenne szükség pl. szorzók implementálására?Kód: [link]
Hosszú nagyon, az egész csak a RAW Paste Data résznél látszódik.
Schematic: [link]
A kártya amire implementálok: Digilent Nexys 4 Artix 7 -
kovisoft
őstag
válasz
pomorski
#14869
üzenetére
Én sem igazán értek a fortranhoz, de szerintem ott lehet a gond, hogy a reduction-ben a jk-t összegzed, de ez csak a reduction végén történik meg, közben pedig minden szálnak saját private jk példánya van, nem az lesz, hogy a jk egyesével növekedne, mint ahogy az egyszálas futásnál történik. Ugyanakkor később a ciklus magjában kihasználod, hogy mi a jk értéke.
Igazából nem tudom, mi lenne a megoldás, talán a jk-t kivenni a reduction-ből és valami ordered-del rávenni, hogy márpedig jó sorrendben kapja az értékeket. De igazából passz.
-
Silεncε
őstag
-
pomorski
őstag
Sziasztok,
egy kis okosságra/segítségre volna szükségem többszálas (openmp) programozás kapcsán. Adott egy fortran kód, amit mi írtunk, néhányezer soros egyszálas. Kimértük, hogy vannak olyan részek, amik végrehajtása nagyon-nagyon időigényes, ezért kézenfekvő volt az ötlet, hogy párhuzamosítani kellene openmp segítségével az időigényes blokkokat a lehető legtriviálisabb módon. Az egyik ilyen időigényes blokk az alábbi:
.
.
.
.
.
jb=0
do ib=1,elteres
do kb=1,mutato(ib)
jb=jb+1
jk=0
do ik=1,elteres
do kk=1,mutato(ik)
jk=jk+1
if (ib.eq.ik)then
sl_tmp=0._dp
if(kb.eq.kk)sl_tmp=egyedi_proton_spe(jb,jk,mm/2,n_of_sdet,s)
if(s(jb)%neutron.eq.s(jk)%neutron.and.kb.ge.kk)then
sl_tmp1=egyedi_proton_tbint(jb,jk,mm/2,n_of_sdet,s)
ujhmatp(ib)%hh(kk,kb)=sl_tmp+sl_tmp1
ujhmatp(ib)%hh(kb,kk)=sl_tmp+sl_tmp1
endif
endif
enddo
enddo
enddo
enddo
.
.
.
.
.
ezt az alábbi módon openmp-sítettem (a legbelső vastag betűvel szedett részt):
.
.
.
.
.
jb=0
do ib=1,elteres
do kb=1,mutato(ib)
jb=jb+1
jk=0
do ik=1,elteres!$omp parallel &
!$omp private(kk,sl_tmp,sl_tmp1) &
!$omp reduction(+:jk)
!$omp dodo kk=1,mutato(ik)
jk=jk+1
if (ib.eq.ik)then
sl_tmp=0._dp
if(kb.eq.kk)sl_tmp=egyedi_proton_spe(jb,jk,mm/2,n_of_sdet,s)
if(s(jb)%neutron.eq.s(jk)%neutron.and.kb.ge.kk)then
sl_tmp1=egyedi_proton_tbint(jb,jk,mm/2,n_of_sdet,s)
ujhmatp(ib)%hh(kk,kb)=sl_tmp+sl_tmp1
ujhmatp(ib)%hh(kb,kk)=sl_tmp+sl_tmp1
endif
endif
enddo!$omp end do
!$omp end parallelenddo
enddo
enddo
.
.
.
.
.
de sajnos hülyeséget számol a progi, ha őt -openmp kapcsolóval fordítom le. Ha nem rakom be eme kapcsolót, és a fordító egyszálas üzemmódban fordítja, akkor tökéletes eredményt számol a progi, -csak lassan ugyebár.“Ökölszabályként” tudom, hogy ami értéket kap az “private”, ami felösszegződik, annál használni kell a reduction-t. Illetve azt is, tudom, hogy időként szükség van a “shared”-re is. Sok mindent kipróbáltam, de a kód csak nem akar megfelelő lenni többszálas fordítás esetén. Ötlet?
szerk: Sajnos csak így sikerült beilleszteni a kódot, a formázás eltűnt, bocs.
-
#14867
Drizzt
nagyúr
instantwater
#14855
Drizzt
nagyúr
válasz
instantwater
#14855
üzenetére
"Esetleg arról is van infód, hogy nálatok milyen branching strategy vált be, és ha van automatizált telepítés, akkor mi triggereli az egyes környezetek frissítését?"
Nevezzük módosított gitflownak. Azért módosított, mert muszáj egy adott alm, meg rlm rendszert használnunk, amit viszont más csapat birtokol, s nem igazán nyitott a változtatásokra, meg a rugalmasságra.
Automatizált deploy jelenleg nincs. DEV rendszerbe lehetne. UAT/feljebb nem mehet csak kézi kezdeményezésre, megfelelő jogosultságú emberek által, PROD-ra meg emberek még szűkebb csoportja által. Szerintem amúgy nincs ezzel különösebb gond. Minőségi garancia szinte semmi nincs jelenleg(még unit testek is általában a jobokban ki vannak kapcsolva, code review elvétve van; ha valaki önként jelzi, hogy szeretné, ha megnéznék a kódját), mégis meglepően stabilan mennek a dolgok. Ez szerintem csak azért mehet így, mert alapvetően masszív tapasztalatú emberekből áll a csapat(, legkisebb tapasztalatú ember valahol 5 év körül lehet, az átlag 15 körül).
Én amit legfontosabbnak tartok az az, hogy a build során elkészült alkalmazás része legyen mindenképpen valamilyen build metadata. Az sem árt, ha mondjuk induláskor is kiírja az ember a logba, hogy pontosan milyen verzió indult(legfontosabb a git sha-1). De azt is fontos lehet, ha meg tudja oldani az ember, hogy valahol a deployment verzió history is látsszon. De ezt a taget szintén a deployment pipeline is rárakhatja a commitra. Pl. jó ötletlet lehet rárakni a környezetet, meg a deployment timestamp-et. -
axioma
veterán
A korabbiakhoz pluszban: hackerearth, hackerrank (ezen szoktak interjut tartani, erdemes megismerni a hulyesegeit), codechef, esetleg topcoder vagy codeforces is hasonlo oldalak de azokon nem vagyok annyira kepben. Az easy-ket keresd, mert itt nem kodolastechnikailag hanem algoritmus ("technologia") nehezseg szerint vannak rangsorolva (foleg timeout szempontjabol). Bar az a tobbinel is igy van szerintem.
-
#14860
instantwater
addikt
K1nG HuNp
#14859
-
#14859
K1nG HuNp
őstag
instantwater
#14844
K1nG HuNp
őstag
válasz
instantwater
#14844
üzenetére
master, canary, + mindenkinek a jelenleg porgetett issueja canarybol leagazva, ha kesz a sprint canaryba beont, canary kozben vegig stagingen fut ugyebar, ha az zsir akkor mehet a beontes masterbe, rinse, repeat
-
Hát, az elég furcsa választás
Ez a könyv így belenézve elég használhatónak, ha rettenetes bőbeszédűnek is tűnik.
Ami meg nagyjából nélkülözhetetlen referenciaanyag, az a Ralf Brown-féle interrupt list
A hard mode meg a mindenféle miniatűr intrók kódjának tanulmányozása, ezt pl. 64 byte-tból hozta ki az alkotója: Gespensterwald, forrás is van hozzá: [link]
-
#14856
instantwater
addikt
Froclee
#14854
válasz
Froclee
#14854
üzenetére
Tehát ti külön branchet tartotok fell 0.x és 1.x verzióknak?
Tehát amolyan release branch stratégia, ahol az egyes releasek külön branchben vannak patchelve?Erről is szivesen fogadok infókat, mert nálunk is fennáll a helyzet, hogy a runtimet és a frameworkot is frissíteni kéne, viszont sok kód van ami csak a régi verzióval kompatibilis, és nem akarunk hetekig dolgozni egy feature branchen mire mindent kompatibiblissé teszünk az új verziókkal. Inkább szépen folyamatosan frissítenénk a kódbázis részeit, és szépen lassan irányítanánk át a feladatok feldolgozását az új verzióra.
-
#14855
instantwater
addikt
Drizzt
#14853
válasz
Drizzt
#14853
üzenetére
Köszi a tippeket.
PHP Laravel a környezet.
A Docker layerekkel és multi-step buildekkel tisztában vagyok, és a dependencyket külön layerbe rakom mindig pontosan a tárhely és újrahasznosíthatóság miatt, de jó tipp. Köszi.
Az alkalmazás környezeti változói jelenleg egy .env fájlban vannak minden szerveren. Ennek automatizálása is cél, és a k8s ebben is fog segíteni.
Esetleg arról is van infód, hogy nálatok milyen branching strategy vált be, és ha van automatizált telepítés, akkor mi triggereli az egyes környezetek frissítését?
Gondolkodtan egy olyan lehetőségen is, hogy masterbe mergelődnek a featurek, ami egyből telepítődik staging/UAT környezetbe és amikor kézzel tagelünk egy commitot egy verziószámmal akkor az kiküldi productionbe a kódot, de ezzel a korábban tárgyalt probléma van, hogy a fejlesztőn múlik, hogy ő patchnek vagy minor changenek itéli-e a PRját, vagy pedig a csapat senior tagjainak kell törni a fejét, hogy ez egy patch vagy minor verzió legyen mergelés után.
Jelenleg nincsenek verzió tagek. Simán a master branch van telepítve. Ezzel az a legnagyobb vaj, hogy csak a telepítésvezérlő környezetben látszik, hogy mikor mi lett telepítve, gitben erről nincs visszajelzés tagek formájában.
-
Froclee
őstag
Library nalunk a semver. Ha breaking change van, akkor atirjuk manualisan a major verziot. Aki egy app-on frissiti a libet, igy tudja hogy oda kell figyelnie.
Sot, van olyan lib-unk ahol sajnos egyelore 2 verziot kell fenntartanni (py2-py3 migracio, hosszu sztori
), ott a 0.x es az 1.x-be is mennek frissitesek. Build id megoldasnal, ezt hogyan tudnad megcsinalni?”Semmi pluszt nem ad” - de, annyit, hogy tudatosan oda figyelsz a breaking changere, plane ha olyan szerencsetlen helyzet van, hogy teszttel nincs lefedve az adott kod resz.
Deploymentet illetoen meg Docker + egy orchestrator, az nem is kerdeses. Mar csak az auto-skalazas miatt is.
-
#14853
Drizzt
nagyúr
instantwater
#14844
Drizzt
nagyúr
válasz
instantwater
#14844
üzenetére
Egy tanács:
- Nem tudom ugyan, hogy milyen nyelven/frameworkon fejlesztetek, de ha Spring boot, akkor semmiképpen ne fat jarba package-eljetek docker image esetén, hanem a dependency-k, meg az alkalmazás források legyenek külön docker layerben. Ezzel az össz. helyfoglalás jóval kisebb lesz, illetve amíg nem változik a dependency-k összetétele, addig az a layer ott tud csücsülni azon a gépen, ahol a docker már találkozott vele, így nem kell letölteni se újra.
- Még érdekes kérdés, amit tisztázni kell, hogy hol tároljátok az alkalmazáshoz tartozó környezetfüggő konfigurációkat. Különös tekintettel a szenzitív adatokra(db cred, etc.).
- "A deployment jelenleg egy több szerverre kitolt kódbázissal megy ahol a függőségek az összes szerveren helyben újra és újra telepítve vannak ami írtó sávszél pazarló, és fragile, mert boldog-boldogtalan root joggal bír a szervereken, és gyakran elb.rmolják az ownershipeket." Ez nagy baj, de docker használatával kapásból meg tudjátok oldani. -
#14852
emvy
félisten
instantwater
#14851
válasz
instantwater
#14851
üzenetére
Ja, oke, igen.
> Ha nem semver, akkor a librarykat is build number alapján húzod be, vagy hogy?
Igen, nalunk az van, hogy <build-number>-<commit-hash> -bol tevodik ossze a lib verzio.
A semverrel a kovetkezo a bajom:
- a minor es a patch verzio kozott _elvileg_ a kliensnek nem kellene kulonbseget tennie; elviekben mindig kompatibilis az uj verzio, es be lehet huzni
- a gyakorlatban ugyis ujra kell tesztelni minden esetben
- major verziovaltas ugye elvileg megtori a visszafele-kompatibilitast, tehat ennyi erovel a libet is at lehetne nevezniMagyarul semver helyett lehet azt, hogy
- mylib1-bol hasznalsz verzio 1-et, es barmikor kijon egy uj verzio, akkor tesztelsz es upgradelsz
- kompatibilitas-tores eseten mylib1-bol lesz mylib2Es kesz. Semmi pluszt nem ad ehhez a semver.
-
#14851
instantwater
addikt
emvy
#14850
Trunk based developmentben is feature branchekben fejlesztenek, csak nincs külön develop és master branch, hanem a feature branchek a masterbe kerülnek mergelésre.
Ha nem semver, akkor a librarykat is build number alapján húzod be, vagy hogy? Elég sok publikus lib használ semvert a mai napig. Persze saját fejlesztésű belső használatra szánt libeknél nem feltétlen elvárás.
Ha clusterezhetőség alatt azt érted, hogy lehet-e futtatni több szerveren a nagyobb teljesítmény elérése érdekében, akkor igen, lehet. Jelenleg is így fut. Lényegében eventeket dolgoz fel egy queueból. Kubernetes Autoscalinggel egy rakás pénzt meg tudnánk spórolni, mert jelenleg egy csomó szerver azért fut éjjel-nappal, hogy napi néhány órát dolgozzon.
-
#14850
emvy
félisten
instantwater
#14849
válasz
instantwater
#14849
üzenetére
> Tehát akkor trunk based developmentre váltottatok, ahol a masterból megy minden,
Nem, dehogy, feature branchek vannak.
A semvernek webappnal milyen értelme van? Szerintem semmi. Libraryk esetén is szinte semmi.
Clusterezheto az app? Ha nem, akkor a k8s tényleg overkill.
-
#14849
instantwater
addikt
emvy
#14847
Tehát akkor trunk based developmentre váltottatok, ahol a masterból megy minden, és a tagek jelzik a production releaset.
Nem multirepos microservice. Monolit, ugyan szét van bontva több packagere, de a build eredménye egy monolit app.
Deployolt appnál mi a semver?
Semver formátumot használsz a taghez ami triggereli a deploymentet.Mostanában elindultunk a jelenlegi infrastruktúra javítása és automatizálása felé, de én ezt zsákutcának és extra munkának érzem, hiszen ahogy te is írtad, a k8s egy csomó mindent megold.
Szerencsére elég nagy beleszólásom van a dolgok folyásába. Konkrétan nekem kell kitalálni, hogy hogyan legyenek a dolgok jobbá téve.
-
#14847
emvy
félisten
instantwater
#14844
válasz
instantwater
#14844
üzenetére
- git flowt használtunk régen, mostmár siman tagek jelzik a verziókat; tehát amikor vki taggel egyet a master branchen, akkor az egy deployolhato egység (nyilván multirepos mikroszervizek esetén kell valami metarepo, mármint ha tényleg rendesen akartok tesztelni)
- semvernek nagyon ritkán van értelme, build hash nem inkrementalis, szoval autoincremented id, pl build number (deployolt webappnal mi a fenét jelent a semver?)
- immutable docker image kell, nyilván
Mi előbb mentünk k8s-re, aztán mikroszervizekre. A k8s elég sok mindent megold önmagában, uniform környezet élesben és tesztben, ingress, health checkek, jobok, perzisztens kötetek, logok gyűjtése.. és ugye megy akár egy laptopon is, ha a fejlesztőnek kell.
Mi Docker Swarm + privát szerverek kombóról kb. 4 hónap alatt átmentünk felhőbe, k8s-el, összesen talán 8 emberhonap ment bele, de ebben volt egy 3 TB-os Postgres migráció is, és kb 20 perc downtime lett végül összesen.
-
#14846
I02S3F
addikt
instantwater
#14844
I02S3F
addikt
válasz
instantwater
#14844
üzenetére
Én nem konyítok hozzá(!) , de annyit tudok, hogy az utolsó előtti kérdésed megvalósítása óriási munka lenne.
-
#14844
instantwater
addikt
A DevOps topik kihalt, úgyhogy bedobom ide.
Egy kis brainstormingot szeretnék indítani az alábbiakról.
Continuous Deployment környezetben ki melyik branching strategyt használja, és miért? Mi triggereli a promotiont stagingből productionbe?
Melyik azonosítót használnád a deploymentek jelölésére? Semver, git hash, vagy build id?
A semver igényel emberi közreműködést, mert default a patch számot növelné a rendszer, de a fejlesztő belátásán múlik, hogy a kód amit beküld az inkább egy minor bump legyen patch bump helyett.
Git hash egyértelmű, könnyen visszavezethető pontosan a forrás commitra. Viszont nincs benne szekvencia, nehéz megmondani 2 git hashról, hogy melyik a későbbi anélkül, hogy valaki megnézi a git historyt és megkeresi a commitokat ID alapján.
Build number szekvenciális, és nem igényel emberi beavatkozást, viszont nehéz visszavezetni commitra.
Viszont, ha nem kap verzió taget egy-egy commit, akkor mi triggereli a production deployt, ha stagingben megfelelt a kód?
Van erre valami best practice? Itt vissza térünk a kérdés elejére, hogy melyik branching strategy lenne a legideálisabb.
Jelenleg GitFlowot használunk, de macerás a dupla PR a hotfixekhez (master, develop), és a develop PRrel kerül a masterbe (és deployolásra) hetente 2x, amit szintén szeretnénk lecserélni napi többszöri deploymentre.
Az eszközökkel nincs baj, GitHub Actions, Docker, Terraform, Ansible tapasztalat megvan, inkább a mit mikor és hogyan lenne a kérdés.
A deployment jelenleg egy több szerverre kitolt kódbázissal megy ahol a függőségek az összes szerveren helyben újra és újra telepítve vannak ami írtó sávszél pazarló, és fragile, mert boldog-boldogtalan root joggal bír a szervereken, és gyakran elb.rmolják az ownershipeket.
Ezt le akarom cserélni immutable image alapú deploymentre, ahol egyszer vannak telepítve a függőségek, majd ez az image van kitolva a szerverekre.
Ez lehet akár machine image buildeléssel aztán Terraformmal lecserélni a szervereket és újrakonfigurálni a routingot, de ezt lassúnak érzem. A másik opció Docker image buildelés lenne, mert az könnyen és gyorsan lehet kitolni a szerverekre.
Hosszabb távon a cél Kubernetesre költözés, de mivel egy monolit alkalmazásról van szó ezért úgy érzem az azonnali Kubernetesre váltás túl sok új komplikációt hozna, és jelenlegi archirektúra automatizálása egy jó köztes lépés lenne.
Vagy ahogy egy szakadékot sem lehet két ugrással átugrani, több értelme lenne egyből Kubernetesbe tolni az egészet, aztán lassan refaktorálni microservices architektúrára?
Kinek mi jött be, mi működött, nem működött?
-
fabri07
aktív tag
Bocsi, de az első kb nem ennyi ?
class Program{static void Main(string[] args){Megszerkesztheto();}public static void Megszerkesztheto(){Console.WriteLine("a oldal:");int a = Convert.ToInt32(Console.ReadLine());Console.WriteLine("b oldal:");int b = Convert.ToInt32(Console.ReadLine());Console.WriteLine("c oldal:");int c = Convert.ToInt32(Console.ReadLine());int d = a + b;if (d > c){Console.WriteLine("megrajzolható");}else if(d < c){Console.WriteLine("nem megrajzolható");}}}} -
#14837
instantwater
addikt
Silεncε
#14834
-
bandi0000
nagyúr
-
bambano
titán
válasz
bandi0000
#14823
üzenetére
csinálsz egy táblát, amibe belerakod az adott termék/adott rendelés azonosítóit, egy azonosítót, hogy melyik árazási függvénnyel számoltak, és magát a kiszámolt árat.
ezek után x darab program, szubrutin, stb. bármi, lefut, és mindegyik beleönti ebbe a táblába a saját árát.
majd ebből a táblából kiválasztod termék/rendelés azonosító alapján, hogy a konkrét esetben melyik árat érvényesíted. -
bandi0000
nagyúr
Szerintem is, nem is jókedvemből akartam volna refaktorálni, csak jó lenne kicsit fejlődni, mert sajnos nem nagyon van senki aki "refaktoráljon", így az ilyeneken kicsit elszoktam agyalni, hogy jó-e így, nem-e lehetne szebben, persze nyilván azt meg tudjuk, hogy senki nem fizeti azt, hogy szebb lett
-
válasz
bandi0000
#14827
üzenetére
Ebben az esetben dabadab kollegával értek egyet, ha már ennyi kész van, plusz ilyen ritkán kell változtatni, és ilyen kevés a variáció, akkor nem éri meg szopni egy teljesen generikus rendszerrel meg szétrefaktorálni az agyadat, vésd oda és kész, ha szépen csinálod meg dokumentálod (akár simán kommenteléssel), nincs azzal semmi gond, legalább triviális, de minimum egyszerű debuggolni.
-
bandi0000
nagyúr
Az a szép benne, hogy csak az árszabályok mondják meg, hogy mit vesznek előre, gyakorlatilag egy sorrendet állít felm mégha nem is minden esetre
IGazából az, hogy honnan jön az ár nem is lényeg, ugyan sok fajta kedvezmény van, mondjuk 6-7 fajta, termékhez, termékcsoporthoz, ügyfélhez stb-hez kapcsolódnak, viszont a lényeg, hogy van egy listám, amiben jelenleg el vannak ezek tárolva, egymás után lekérdezve ugye
Egyik sem feltétlen olcsóbb vagy drágább mint a többi
Pl Egyedi ár 2000Ft, Márka kedvezményes ára: 1600Ft, Akciós ár: 1000Ft1. Szabály: Egyedi ár vagy legkedvezőbb esetben akkor az 2000 Ft lesz
2. Szabály: Legolcsóbb ár: Akkor is 1000Ft lesz
Pl Márka kedvezményes ára: 500Ft, Akciós ár: 650Ft, Termékcsoport kedvezményes ár: 300Ft
1. Szabály: Egyedi ár vagy legkedvezőbb esetben akkor az 300 Ft lesz
2. Szabály:Akciós ár vagy legolcsóbb: Akkor is 650Ft lesz
Igazából már létező rendszer, de ott jelenleg csak az egyedi ár, vagy legkedvezőbb ár szabály van, és pont ez a gond, mert jött másik ügyfél, aki mást akar, plusz ez ugye elméletileg bármikor kapcsolható, szóval így nem teljesen jól működik -
válasz
bandi0000
#14823
üzenetére
Egyedi ár mindig olcsóbb, mint a bármi más akciós ár?
Akciós ár mindig olcsóbb, mint a bármi más, kivéve egyedi ár?
Hogy kéne ezt elképzelni? Van egy meglevő terméklista, vagy ilyesmi, illetve vevők, és vevő kaphat egyedi árat, termék kaphat akciós árat? Hogy lehet egy terméknek több ára (ie: maradékból a legolcsóbb)?Valami valós példát be tudsz dobni légyszi, árakkal, ilyesmivel?
Illetve: létező rendszerbe akarunk extra funkciót (akció) vagy nulláról tervezett/írt rendszerről beszélünk, aminek ez lesz az egyik funkciója?
-
válasz
bandi0000
#14823
üzenetére
Addig, amíg tényleg három ilyen szabály van, szerintem a fixen bedrótozott kódnál jobb megoldás nincs.
Majd ha lesz sok, akkor lesz egyrészt értelme annak, hogy ezt az ember valamiféle általános módon kezelje meg akkor fog látszani, hogy hogyan is érdemes a követelményeket lemodellezni (mert ugye ilyenkor az szokott lenni, hogy a három példa alapján kitalálsz valami rendszert, lekódolod, örülsz, aztán másnap valaki kitalál egy negyediket, ami baromira nem illeszkedik abba, amit megcsináltál és vagy széthekkeled a rendszered vagy kezdheted majdnem előről). -
bandi0000
nagyúr
válasz
dabadab
#14822
üzenetére
Szinte igen bàr megpróbálom valós példákkal
Adottak a következő àr típusok: Egyedi ár, Akciós ár, Márka kedvezmény, Termék csoport kedvezmény
Van 3 Fajta àrazási szabàly : Egyedi àr vagy legolcsóbb, Akciós ár vagy legolcsóbb, Legolcsóbb
1. szabálynál, ha van egyedi ár akkor azt, ha nincs, akkor a maradékból a legolcsóbbat használja
2. Hasonló, csak akciós árral
3. Az összes közül a legolcsóbbat veszi ki
Persze lenne olyan is, hogy egyéni sorrend van köztük, de ez már lehet meg se valósul
Igazábó olyasmi dolgot szeretnék ami "legenerálja" anélkül, hogy tele raknám if-el, vagy return-el, illetve könnyű legyen újat hozzátenni
Olyasmire gondoltam, hogy lehetne az egyes àrakat súlyozni, és a legolcsóbb kategóriás árakat ugyan azzal a súllyal jellemezném, és ekkor választanán ki a legolcsóbbat
Persze ez lehet hülyeség
-
válasz
bandi0000
#14819
üzenetére
Csak hogy jól értem-e a feladatot:
Van n darab függvényed (mondjuk A1, A2, A3 stb) amik visszaadnak egy értéket.
Vannak szabályaid, amik azt mondják meg, hogy a fentiek közül melyik függvények értékei közül kell kiválasztani a (legkisebb? legnagyobb?) értéket, valami olyasmi, hogy min(A1, A3, A17).
És kellene írnod valamit, ami a szabályokat kezeli.
Jól értem? -
bandi0000
nagyúr
Egy kis segítséget kérnék, hogy miképp lehetne szépen megoldani az alábbi feladatot
Adott egy árazó osztály, 3 fő árszabály van, vagy egyedi árat, vagy akciót, vagya többi fajtából a legkisebb árát vesszük figyelembe
Ezeknek különböző permutációját lehet beállítani, asszem most 3 fajta van
-Egyedi ár vagy legkedvezőbb ár a többi típusból
-Legkedvezőbb ár
-Akció vagy legkedvezőbb ár a többi típusbólEgyedi ár, akció és a többi fajtára mind van 1-1 fv az osztályon belül, ami visszaadja az árat
Nekem egyfajta megoldás jut eszembe hirtelen, 3 fő fv ami a szabályokat tartalmazza, és aszerint hívja meg a különböző fv-ket, nyilván ez annyira nem lenne szép
Van erre valami tervezési minta, amit ilyesmire lehetne alkalmazni?
-
-
skoda12
aktív tag
válasz
martonx
#14809
üzenetére
Régen én is küldtem kódot open source projektekhez, de folyton az volt, hogy a merge joggal rendelkező developerek alapvetően el voltak foglalva az új featureökkel és a critical/blocker bugokkal. Senkit nem érdekelt, hogy egy kevésbé súlyos bug engem érintett és amúgy megjavítottam, mert azt nekik idő átnézni, kipróbálni, visszaírni, hogy mi nem tetszik stb.
-
martonx
veterán
válasz
Silεncε
#14807
üzenetére
Én mostanában épp ckeditor 5-ös plugineket javítgatok aktívan, így hogy havonta jönnek a breaking change-es új verziók. Én ebben az egészben azt nem értem, hogy ha már valaki vállalja, hogy csinál egy plugint, és kap emailt egy PR érkezéséről, mégis mi a f....ért nem képes belátható időn belül rányomni egy nyomorult merge gombra?
-
Silεncε
őstag
válasz
martonx
#14806
üzenetére
Semmi komoly, 6 sor az egész, de ettől függetlenül is jó
Am ilyen nekem is volt. Cordova plugint az illető baszott karbantartani, szépen el is tört mint annak rendje, aztán lehetett valakinek a gh-n lévő megpatkolt forkját begányolni. Az open source egyik legnagyobb hátránya, hogy igazából senkié a cucc, aztán a karbantartó ráhagyja, akkor meg van baszva mindenki
-
-
#14803
instantwater
addikt
Silεncε
#14801
válasz
Silεncε
#14801
üzenetére
Mobilappnál valóban nincs szükség TORos varázslásra.
Bár, ha nagyon sok user van egy szolgáltatói NAT mögül akkor IP ban befigyelhet extrém esetben.Illetve nagyon pazarlós megoldás letölteni az egész HTMLt és kliensoldalon parsolni ahelyett, hogy a szerver csak a lényeges adatot küldené le JSONban.
Nálam ez szakmai ártalom, hogy alapból mindent szerveroldalon csinálok. Sokkal kontrollálhatóbb mint a kliens.
-
seredy
tag
válasz
Silεncε
#14799
üzenetére
Köszönöm! Igen, sejtettem, hogy ez nem valami kezdő projekt, inkább az érdekelt, hogy lehetne-e ilyet csinálni, meg mik ennek a kulcsszavai
. Én egyelore html-t, CSS-t meg js-t nézegetek, bár annyira kevés idom van mostanában, hogy inkább csak blogokat olvasására jut Idő. Aztán felmerült bennem a fenti kérdés . -
Silεncε
őstag
Visszatöröltem már, de ezzel én is tisztában vagyok. Viszont én nem szerverben gondolkoztam, hanem hogy a mobilról küldesz requestet és azt a mobilon alakítod át, nincs központi szerver amin minden átfolyik. Valamiért úgy rémlik az unofficial PH app mögött sincsen backend
Ott használjuk ezt. 
), ott a 0.x es az 1.x-be is mennek frissitesek. Build id megoldasnal, ezt hogyan tudnad megcsinalni?
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
● olvasd el a téma összefoglalót!
- gban: Ingyen kellene, de tegnapra
- Lakáshitel, lakásvásárlás
- Fejhallgató erősítő és DAC topik
- Autós topik
- PlayStation 5
- Kormányok / autós szimulátorok topikja
- Honor Magic V5 - méret a kamera mögött
- btz: Internet fejlesztés országosan!
- Lexus, Toyota topik
- Nézzük élőben: Gamescom 2025: Opening Night Live!
- További aktív témák...
- REFURBISHED - Lenovo ThinkPad 40A9 docking station
- AKCIÓ! Microsoft Surface 5 13,5 notebook - i5 1235U 8GB RAM 256GB SSD Intel Iris Xe IGP 27% áfa
- Azonnali készpénzes INTEL CPU NVIDIA VGA számítógép felvásárlás személyesen / postával korrekt áron
- Samsung Galaxy S23+ 256GB, Kártyafüggetlen, 1 Év Garanciával
- Lenovo IdeaPad S10-2 netbook jó akkumulátorral eladó
Állásajánlatok
Cég: FOTC
Város: Budapest