Valóban nem ugyanarról beszélünk. Amiről te írsz, az egy elosztott rendszer.
A blockchain első számú fícsöre és problémaforrása, hogy decentralizált.

Banki ledger-ek legalább 800 éve léteznek. A lényege, hogy minden érintett fél megbízik a bankban, hogy a tranzakciókat helyesen kezeli, megérkezik az utalás, nem tűnik el a pénz a számláról. A banknak pedig elemi érdeke, hogy ezt a bizalmat fenntartsa.

A blockchain arra a problémára ad megoldást, hogy hogyan tudnánk pénzügyi tranzakciókat elvégezni és validálni abban az esetben, ha nem léteznének megbízhatóan működő banki ledger-ek. Csak hát ugye léteznek, úgy legalább 800 éve.

[ Szerkesztve ]

A hitelesség biztosításához - a technológiából adódóan - nagyságrendekkel több erőforrást éget el, mint egy centralizált rendszer. Valódi előnye pedig nincsen. Nem véletlen, hogy a nagy blockchain láz idején is a csillogó szemű hívőknek semmilyen konkrét érvük nem volt mellette, csak az olyan abszurditások, minthogy: vége az eddig létező pénzrendszernek, kormányok fognak megdőlni, és társai.

A cenzúrázás problémáját oldja meg. Ha nincs ilyen problémád, akkor nincs rá szükség. Ha van, akkor jó megoldás lehet. A legtöbb banknak nincs ilyen problémája.
Hitelességhez nem kell blockchain, példa: központi git repository.

[ Szerkesztve ]

while (!sleep) sheep++;

> A technológia röviden összefoglalva egy csak olvasható dokumentum halmaz minden node-on minden adat megvan jelleggel.
> Sok node-on az adat felírás annyival lassabb, mert minden node-ra fel kell írni minden adatot, de cserébe az adat visszaolvasás több ügyfélre elosztva tud lenni ugyan annyival gyorsabb, mert el lehet osztani az ügyfeleket a node-ok között (H/P).

Nem, total nem errol van szo. Amit leirsz, az mukodne egy normal multi-master adatbazissal is.

A blokklanc lenyege az, hogy akarhanyan beallhatnak szavazni arrol, hogy elfogadjak-e az update-eket, es ha a fele resztvevo elfogadja, akkor az valid (ez valamennyire egyszerusites). Ennyi. Egy klasszikus multi-master adatbazis eseten nem dobhatod be a te sajat geped, hogy lecci hadd legyen ez is resze a clusternek, es ha a cluster eddig 5 gepbol allt, te pedig bedobsz 6-ot, akkor onnantol te mondod meg, hogy mi a megfelelo update.

while (!sleep) sheep++;

>Lassú.

Vitatnám. Az új adat felírása lassabb. Az a része igaz. De mi van azzal, hogy cserébe az adatok visszaolvasását oszthatod? Egy kiegyensúlyozott alkalmazás egészében mindig az olvasás a nagyon sokszor több. Egy fürt mindig gyorsabb tud majd lenni, mint egy node. Nekem kicsit szűklátókörűnek tűnik a kritika.

>100% uptime nem szükséges egyébként, és a kliens szempontjából úgysem elérhető soha. A blockchain sem 100% a kliens szemszögéből.

Na itt egybedaráltál pár dolgot. A "nem szükséges" állítása egy kicsit savanyú a szőlő esetére hajazik. Nem tudják megcsinálni elavult technológiai alapon, szóval ráfogják, hogy az a felhasználói élmény nem szükséges. "Az ki van zárva, mert nem tudom" És szőnyeg alá söprik azt az esetet, hogy ha valaki azzal kezd marketingelni a piacon, hogy ők azt is meg tudják csinálni, mindjárt megváltozik a szükséges-e vagy sem minősítése. Nem csak bankok, de mezei pici cégek sem szeretnek a köztudatban arcot veszíteni. Egyik brand sem szeret arcot veszíteni konkurenciával szemben. Nyilván idő kell hozzá, de ha az utólagos statisztika eredményére kellene pénzzel fogadnom, azt arra tenném fel, hogy a "nem szükséges" veszíteni fog.

Az uptime veszítést sem érzem jogosnak. Fürtöt is kellhet leállítani, ha pancserek fejlesztik az alkalmazás egészét, és nem tudják megoldani a rolling restart-ot, vagy alkalmazás hibák miatt esetleg adat integritás sérül. Még a cyber attack problémája fordul elő (konkrétan a rendszerre történő behatolás lopott jogosultsággal), de az meg biztonságtechnikai probléma, ha elő tud fordulni, és nem írnám a partícionált rendszerek természetének számlájára. Ha azok mind megértek elég sok időt és hozzáértést, de bizony tud lenni az uptime 100.0%. Ha konkrét technikai kifogásod van, légyszíves fogalmazz konkrétan, milyen esetben látod elkerülhetetlennek a down time-ot?

>A blokklanc lenyege az, hogy akarhanyan beallhatnak szavazni arrol..

Amit írsz, az alkalmazás szintű kérdés, mint hogy páran felhasználták cryptocurrency-re ugyan azt a technológiát, amit lehet használni adatbázis építésére egy webservice mögött. Igen, lehet szavazósdit építeni belőle, ha valaki azt akar. De az mind alkalmazás és nem a technológia maga. De mondjuk megkérdezendő harmadik felet, rákerestem google-el, és ezt dobta ki:

"Blockchain defined: Blockchain is a shared, immutable ledger that facilitates the process of recording transactions and tracking assets in a business network."

Ha valakinek az angol kevésbé megy, nekik segítségképpen a "ledger" nem csak számlakönyv, hanem bármilyen jegyzék, az "asset" nem csak pénz eszköz jellegű tulajdon, hanem bármilyen természetű, és a "business network" nem csak pénzügyi hálózat, hanem bármilyen alkalmazás hálózat.

Az "akárhányan beállhatnak szavazni" azért alkalmazás szintű kérdés, mert vagy úgy van kivitelezve az alkalmazás, hogy mindenkit elfogad a megbízható hálózat tagjának, vagy nem. Nem kötelező része a technológiának. Vagy talán csak elbeszélünk egymás mellett, nem egyértelmű. Majd pontosítasz, ha gondolod.

[ Szerkesztve ]

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

>A blockchain arra a problémára ad megoldást...

...amit megoldanak vele

Bocs, nem tudtam kihagyni

Én nem figyeltem fel rá, hogy a technológiának beépítetten része lenne, hogy csak egy dologra szabad felhasználni, és semmi másra.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

De most mi a kérdésed?
Hogy lehet-e más dolgokra használni a blockchaint, amire kitalálták?
Lehet, igen. Mosogatószivaccsal is ki lehet festeni a szobát.

Vagy az a kérdésed, hogy miért nem tértek át erre a bankok?
Ugyanazért, amiért a szobafestők sem cserélik le a festékhengert mosogatószivacsra.

"Egy kiegyensúlyozott alkalmazás egészében mindig az olvasás a nagyon sokszor több." Ezen most a szenzor adatokat tarolo alkalmazasok verig lettek sertve. Meg a telekommunikacios szamlazo rendszerek. Tobbek kozott.

I am having fun staying poor.

Ha a rendszered tranzakciókat dolgoz fel, akkor az a legjellemzőbb, hogy
1. Folyamatos, nagy mennyiségű, írási műveleted van, ahol a fő szempont a gyorsaság.
2. Kevés olvasási művelet, amelyek komplexek, és ezáltal nem is gyorsak.

Azt nem tudom, mit jelent a "kiegyensúlyozott alkalmazás", gondolom ezt a faszság tantárgyon tanítják, azokra az órákra nem jártam be.

[ Szerkesztve ]

Még annyit hozzátennék, hogy a nagyon komplex olvasási műveleteket jellemzően kiszervezik az adattárház rétegbe. Ott meg aztán mindenki úgy buzul az adatokkal, ahogy akar.

Mondjuk arra kíváncsi vagyok, hogy a blockchain olvasási sebessége miért gyorsabb, mint egy centralizált rendszeré. Ugyanis ilyen állítás is elhangzott előbb.

> A "nem szükséges" állítása egy kicsit savanyú a szőlő esetére hajazik.

Nem egeszen, csak en tudom, h miert nem 0% a downtime budget, vagy miert nem csinaluk 99.99999%-ot, akkor se, ha tudnank, ha 99.999% elegendo.

> Ha konkrét technikai kifogásod van, légyszíves fogalmazz konkrétan, milyen esetben látod elkerülhetetlennek a down time-ot?

- terroristatamadas az osszes adatkozpontban egyszerre
- haboru
- globalis BGP konfiguracios problema
.. stb.

Ezek mind csokkentik a varhato rendelkezesre allast.

Azert nem szukseges pl. a 99.999999999% egy banki rendszer eseten, mert a koltsegeit nem hajlandok megfizetni az ugyfelek. Tehat ha a bankolas 10 forintba kerul tranzakcionkent, cserebe evente van 1 ora downtime, az az ugyfelek nagy reszenek jobban megeri, mint evi 1 perc downtime es 1000 forintos tranzakcios koltseg.

> hogy ők azt is meg tudják csinálni, mindjárt megváltozik a szükséges-e vagy sem minősítése

Csak epp senki nem marketingel 100%-al, akik komolyan veszi magat. A legnagyobb cloud szolgaltatok jellemzoen 99.95%-ot vallalnak datacenterenkent, 99.99% korul tobbregios elosztott rendszerekre.

De tudom, most jon az, hogy a Google-nel amatorok dolgoznak

[ Szerkesztve ]

while (!sleep) sheep++;

A blockchain témát nem kívánom folytatni, de a másodlagos véleményekre egy pár hozzáfűzést hagynék itt.

@Drizzt

>...most a szenzor adatokat tarolo alkalmazasok verig lettek sertve...

Vagy inkább csak a pancser fejlesztőik. Ahol szenzor adatokat tárolnak, normális design gyárt belőle sorfolytonos adat stream-et valami helyi flash-en, amit távoli állomás időszakosan átolvas, feldolgoz, mindenféle statisztikát gyárt belőle, és már csak a kész statisztikát tolja fel adatbázisba. Az a statisztika egyszer kap felírást, és életciklusa során vagy milliószor olvasást. Csináltam már, láttam másokat is csinálni, és azért vagyok képben arról, hogyan lehet valamit elcseszni, és normálisra csiszolni. Az egyetlen kivétel, vagy majdnem kivétel, amivel valaha életemben találkoztam szenzor információ témában, az haccp környezetében termelési log-ok esete. Volt ügyfél, aki az egészet db-ben kérte, és nem szöveges log file-ba. Nem mintha valaha valami másra kellett volna neki, mint a leállások időtartamának ellenőrzésére, amit külön megkapott feldolgozott információk formájában.

@cucka

>...Azt nem tudom, mit jelent a "kiegyensúlyozott alkalmazás"...

Ha nagyobb arányban tartozik egy alkalmazáshoz olvasás, mint írás, és már olyan sok az ügyfeled, hogy egy node nem képes kiszolgálni, olyankor jönnek azok a játékok, hogy több adat copy-t gyártasz, és osztod az ügyfelek kiszolgálását.

@emvy

>De tudom, most jon az, hogy a Google-nel amatorok dolgoznak

Nem állítottam olyat, bár tuti használ a Google is filléres rabszolgákat, ahogy az Apple is.

Hanem azt észrevételezném, hogy én még sosem találtam a Google keresőjét offline állapotban. Pedig idestova nagyon régen használom. Sőt, senkivel sem találkoztam még, aki olyat látott volna. Google, Facebook, Messenger, Amazon, AliExpress, DealeXtreme és társaik látszólag nem 99-95-öt, meg nem 99.99-et használnak, hanem 100.0-t. Meg úgy általában, amelyik brand-nek fontos a köztudatban betöltött pozíciója, látszólag mindegyik 100.0-t használ, és nem csak 99.99-et.

Ami a 99.99-et illeti, az a matek szerint minden másnap egy alkalommal valamikor az összes aktuálisan futó felhasználói munkafolyamat folyó adatainak az elvesztése abban a 16 másodpercben, amíg a szerver hidegen újraindul. Persze elfogadom azt a célzást a sorok között, miszerint a fukar mindenit neki, mert jelentős a költséghatékonyságon kaszálható profit. Természetesen értem. A BesenyőPistikeNénike Bt 10-15 havi aktív felhasználójának nincsen szüksége a 100.0-ra. És olyan kevés cégnek van legalább 1 millió havi aktív felhasználója, hogy őket nyugodtan elhanyagolhatjuk, mint olyan apró statisztikai adatot, ami lehet, hogy csak kerekítési hiba. Szóval az sem biztos, hogy tényleg léteznek. Sokáig éljenek a BesenyőPistikeNénike Bt-k.

[ Szerkesztve ]

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

"Vagy inkább csak a pancser fejlesztőik. Ahol szenzor adatokat tárolnak, normális design gyárt belőle sorfolytonos adat stream-et valami helyi flash-en, amit távoli állomás időszakosan átolvas, feldolgoz, mindenféle statisztikát gyárt belőle, és már csak a kész statisztikát tolja fel adatbázisba. Az a statisztika egyszer kap felírást, és életciklusa során vagy milliószor olvasást."
Ertem. Egy dolgot mondj akkor meg legyszives! Mit csinalsz abban az esetben, ha kiderul, hogy a statisztika gyarto fuggvenyben van egy bug, ami miatt a fel evvel ezelotti osszes adatot ujra kellene szamolni? A helyi flash meg mar azota 15-szor ujra lett irva uj adatokkal. Honnan lesz meg az adat, amibol kiszamoltad a rossz statisztikat, hogy ujraszamold helyesen?
De mondjunk egy meg egyszerubb forgatokonyvet: kellene uj statisztika az eszkozok altal begyujtheto adatbol, 5 evre visszamenoleg. Mostantol, eddig nem kellett. Viszont ugyanazokbol az adatokbol, amiket eddig is gyujtott az eszkoz.
Mit csinalsz? Tegyuk fel, hogy az adatok nagy frekvenciaval keletkeznek, a flash merete meg korlatos, mondjuk 1-2 napi adat fer el rajta maximum.

[Nagyobb google kiesesek]
[Facebook: ez nem volt olyan regen, gyarkolatilag napokig hasznalhatatlan volt a felhasznalok tobbsegenek(bar hivatalosan 6 ora utan helyre lett allitva)]

I am having fun staying poor.

> Google, Facebook, Messenger, Amazon, AliExpress, DealeXtreme és társaik látszólag nem 99-95-öt, meg nem 99.99-et használnak, hanem 100.0-t.

Ez konkrétan nem igaz. Legutoljára 2022 augusztus 8-án volt offline a kereső globálisan percekre. A Google fő szolgáltatásai olyan 99.999% körül mozognak. A felhős régiók (tehát pl. Nyugat-Európa) 99.98% körül.

> . Ahol szenzor adatokat tárolnak, normális design gyárt belőle sorfolytonos adat stream-et valami helyi flash-en, amit távoli állomás időszakosan átolvas, feldolgoz, mindenféle statisztikát gyárt belőle, és már csak a kész statisztikát tolja fel adatbázisba

Sok területen ez konkrétan tilos, minden egyes mérési eredménynek meg kell lennie. (Pénzügyi tranzakciók, egészségügyi adatok, stb.).

[ Szerkesztve ]

while (!sleep) sheep++;

Amikre ráláttam nagy rendszerek (telco, finance, retail), ott szó sem lehetett arról, hogy ne tároljanak le nyers adatokat. Egyrészt azért, mert az adat a legnagyobb kincs (ez már sok-sok éve ki lett mondva mindenhol), másrészt az aggregáció logikája nem stabil soha, ezért sosem szabad a legalsó szintre rakni. A big data módszerek terjedésével ez hatványozottan igaz.

Nincs 100%-os rendelkezésre állás, soha senki sem állította ezt magáról. A tizedesvessző utáni 9-esek számán szokott megmutatkozni a minőség, és persze az ár is.

[ Szerkesztve ]

Telco és finance iparágakban jogszabályi előírás, hogy meg kell őrizni a tranzakciókat.

Például egy rendőrségi nyomozás során kikérik a gyanúsított 4 évvel ezelőtt szombat délutáni híváslistáját.
Na akkor nem az a jó válasz, hogy "Nincsenek meg az adatok, mert nálunk nem pancser fejlesztők dolgoznak"

Persze, tudom. Ezért csaptam oda a retailt is (most pont ilyen helyen dolgozom), ahol megdöbbenek, mennyire szabályozatlan minden, mégis mindent megőriznek.

Egyébként az általános hozzáállás az, hogy az adat tárolása olcsó, szóval inkább őrizzük meg, hátha jó lesz még valamire. A szelekció önmagában egy rakás architect munkaóra lenne. A storage meg filléres tétel már.

[ Szerkesztve ]

Egyébként az általános hozzáállás az, hogy az adat tárolása olcsó, szóval inkább őrizzük meg, hátha jó lesz még valamire. A szelekció önmagában egy rakás architect munkaóra lenne. A storage meg filléres tétel már.
Attol fugg mekkora nagysagrendben... Nalunk a napi (szurt) firewall proxy log kb fel-masfel milliard rekord.

[ Szerkesztve ]

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Háát, az ilyen szerver log típusú dolgokat nem sorolnám ide. Nem mindig éles a határvonal, de például egy proxy esetében biztosan. Plusz ezeket nem is db-ben szokás tárolni, hanem fájlrendszeren plain textben. És ne gyere most azzal, hogy nálatok esetleg pont nem így van, mert akkor a kardomba dőlök!

Termeszetesen nem DB-ben van, hanem log szerveren/aggregatoron... de a diszk ott se olcsobb, mint egy DB szerveren

[ Szerkesztve ]

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Business app tranzakciós adataitól indultunk, én is erre reagáltam. De ne tapossuk ezt szélesebbre.

Köszönöm a felvilágosítást a Google trehányságairól. A jelek szerint mégiscsak filléreskednek ott is Nem hittem volna.

Szenzor adatok. Én sosem állítottam olyat, hogy azokat az adatokat kidobják vagy olyasmi. Én azt állítottam, hogy azokat nem láttam még adatbázisba feltolni és ott ténylegesen használni. És azóta sincsen lila halvány gőzöm sem, hogy leszámítva valami munkahelyi szabályzatot (amire egyszer láttam példát), vagy elpancserolt design-t (amire jó sok példát láttam), ugyan mi értelme write-heavy load-ot adatbázisba küldeni mezei bináris állomány helyett? Elvégre azt sosem kell átírni, nem lesznek rajta konfliktusok, egyszerű pozíció szerinti indexelést lehet benne használni visszaolvasáskor db motor nélkül (mezei file kezelés), szóval miért kellene annak DB-be kerülnie? Lehet ugyan, de egy adatbázis motor nem ilyesmire való.

@Drizzt

Amivel én találkoztam, részint adatok ott maradtak flash-en. Garancia időn belül nem tudott túlcsordulni 2 gigás flash. A gyors ciklusú termelési adatok központilag logolva voltak másmilyenek, azokat feltoltam binárisan file-ba, file-ok havonta darabolva, és mentek mentésbe valami hdd-re valahol. Talán még mindig ott porosodnak. Évek óta nem vagyok azon a terepen, nem tudom.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Mennyivel? Az sqlite (ami siman egy fajlba ir, ugyebar) hctree1024 backenddel 16 mag mellett kb. 1 millio tranzakcio/masodpercet tud -- ha masodpercenkent van 1M txn akkor gondolom a 16 magos hardver belefer. Cserebe megbizhato, szenne tesztelt.

while (!sleep) sheep++;

Lehet binarisan tarolni, de a nyers adatra mindenkeppen szukseg van, a termek indulasatol kezdve egeszen a mostani idopontig. Onnantol kezdve a mernokok feladata, hogy mit kezdenek ezzel a nyers adattomeggel, milyen formaban transzformaljak es taroljak. Altalaban a raw reteg utan mar valamilyen DB vagy data lake kovetkezik....
Nalunk peldaul 4 lepcso van a raw es a konkret user reteg kozott , az adat bonyolultsagatol es a kovetelmenyektol fuggoen mindet ki is hasznaljuk.

[ Szerkesztve ]

MySQL Cluster-ről találtam összeszedett dokumentációt, ugyan azt az Oracle fizetős cuccáról nem találtam meg. Brossúra anyagok vannak valamiről, amit Oracle Real Application Cluster-nek neveznek, vagy akárminek, de a linken található objektivitással összeszedett dokumentációt nem találtam. Aki ismerősebb a témában, tud dobni egy linket esetleg? Vagy halálkomolyan lenne az a helyzet, hogy a dokumentáció is fizetős?

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Nem teljesen világos, hogy melyik dokumentációra vágysz, de itt kiindulva a pdf-ekből valószínűleg jó úton leszel.

I am having fun staying poor.

A split brain problémát vizsgálom, arra vonatkozó doksit keresek. Hardver konfig, és a vonatkozó adatkezelési koncepció. A linket köszönöm.

Közben felleltem egy blogot, ami elárulja egyben, amire kíváncsi voltam.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Sziasztok!
Biztos unjátok már a hasonló hsz-ket, de hátha kapok egy-két tanácsot, megjegyzést.
Karrierváltáson gondolkodom és csalogatónak hangzik, hogy mindenhonnan azt hallani, hogy milyen hiányok vannak az IT szakmában. De ahogy elkezdtem programozási nyelvekről keresgélni, elég hamar elvesztem bennük.
Jelenleg leginkább marketinghez kapcsolódó grafikai munkáim vannak és wordpress alapú weboldalak kezelése, egy nem multi nagyságú, de már nem is családias vállalkozásnál.
Ez alapján a front-end fejlesztői környezet felé nézelődnék, de az nem pont egy telített terület? Láttam még ehhez kapcsolódóan a full-stack fejlesztést, viszont az kezdésnek meg nagyon mélyvíznek tűnik.
Ti mit tudnátok a leírtak alapján nekem ajánlani, merre fele induljak el, hogy egyáltalán érdekel-e, menne-e?
31 éves vagyok, egyetemi képzést már nem akarok vállalni, egyéb tanfolyamot, amit munka mellett lehetne végezni, azt inkább. De kezdésnek nem gondolom, hogy sok pénzt bele kéne fektetnem, míg ki nem derül, hogy alkalmas vagyok-e programozásra.

Codeacademy - learn Java

Ez annyira elég, hogy lásd érdekel-e. Hajrá!

Nothing will stand in our way. I will finish what you started.

+1. A javat mezítlábasként elfelejteném.

Ha frontenden vagy, akkor ugye a html tördelés, és a css nem nagyon okoz gondot. Annak közvetlen közelében a javascript van.

A full-stack azért tűnhet mélyvíznek, mert a front és a back 2 teljesen külön témakör tud lenni. Az egyik oldalon az esztétika, és a felhasználói kényelem a mérce, a másik oldalon a fejleszthetőség és hatékony üzemeltethetőség. Amíg önállóan backend kérdésekben nincsen meg a tapasztalatod, az integrált fullstack cuccok mindig egy kicsit problémásak lesznek, és abban sem leszel biztos, hogy miért.

Ha back-end oldalon kezdeti tapasztalatot gyűjtenél, mondjuk ez a könyv kellene neked, és haladsz vele kedved szerint. Talán némelyik e-boltban is megvan sokkal olcsóbban - nem ellenőriztem. Ha pont ez nincs, valami a környékén akkor is lesz az abban foglalt témákból.

[ Szerkesztve ]

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

sziasztok!

2023-ban Magyarországon milyen vállalkozási forma lehetőségek léteznek ITban dolgozók számára? (ami érdekelne, havi nettó/bruttó limittel együtt)
KATA meghalt. Milyen opciók vannak helyette? (átalányadózás? kft? bt? vagy egyéb más?) Ezek egy részénél van egy havi limit ami felett nem kereshetsz.

Mondjuk ha az ember contractorként próbálkozna belföldre vagy inkább külföldre bedolgozni.

(megoldásokat örömmel veszek akár privátban akár ide a fórumba)

Köszönöm!

[ Szerkesztve ]

Én azt mondom kezdésnek Python, aztán lehet egyre mélyebbre úszni a vízben. A kőegyszerű szintaxis miatt könnyebb az elméletre, logikára, koncepciókra koncentrálni. Szerintem sokat számít a kezdeti sikerélmény, még akkor is ha a Python egyfajta "cheat" a programnyelvek közül, múltkor is volt egy LeetCode feladat ami a hard kategóriában van és C-ben tényleg vért izzadsz vele, Pythonban viszont 3 perc volt megoldani és kb 8 sor kód. Mostanában így próbálok gyakorolni, megnyitok egy feladatot, a pseudocode ha megvan fejben gyorsan megírom Pythonban aztán ha működik, nekiülök ugyanazt megírni C-ben is, ami már jóval izzasztóbb feladat

Amit pedig tudok ajánlani az a Harvard CS50, teljesen ingyenes használni, Harvard előadás majd éles feladatok vannak amit le is ellenőriznek ténylegesen megoldottad-e. Ha akarsz igazolt, aláírt oklevelet a végén, akkor azért kell csak fizetni.

[ Szerkesztve ]

olyan cérna vagyok, akit anyám százszor tűvé tett

Köszönöm a válaszaitokat, akkor valamilyen ingyenes úton indulok először.

"Ha nem vagy igazán jó benne, akkor minden terület telített, ha meg igen, akkor meg egyik sem" - ez amúgy milyen igaz

Lesz egy ilyen esemény is jövő héten, lehet elnézek majd erre, ha már ingyenes. Vagy nem érdemes?

Ti hogy programoztok?
Én régen úgy csináltam hogy írtam egy kis módosítást, kipróbáltam hogy működik-e? Örült az ember hogy na ez jó. Aztán megint egy picit, próba, jó. stb.

Most meg egyszerre begépelem az egész nagy rendszert. Majd próbafuttatás. És az így keletkezett hihetetlen nagy bughalmazt utána megpróbálom kibogozni.
Képtelen vagyok a régi módszerrel dolgozni, mert hajt a tatár.

TDD