- gban: Ingyen kellene, de tegnapra
- sh4d0w: Netflix? Ugyan, VW előfizetés!
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Klaus Duran: Youtube AI szinkron
- eBay-es kütyük kis pénzért
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Magga: PLEX: multimédia az egész lakásban
-
LOGOUT
Új hozzászólás Aktív témák
-
acsati
aktív tag
Sziasztok!
Udemy-n szemezgetek ezzel a python kurzussal, meg is örültem, hogy 100€ helyett most megvehetem 18€-ért. Aztán bejelentkeztem és ott már teljes áron van.
Ezt egy új regisztrációval ki lehet játszani vajon, vagy várható szerintetek leakciózás?
Leírás, tematika alapján érdemes lehet egyáltalán? -
btraven
őstag
ChatGPT-t ki lehet próbálni?
Van egy foci bajnokság szimulátor programom. De jó lenne ha lennének kupameccsek is, egyenes kieséses rendszerben az összes bajnokság összes csapata indulna.
Elég ha ezt beírom a ChatGPT-be? Meg a project github címét?
És akkor megcsinál mindent? Nekem csak le kell szednem a végeredményt?
Tök jó lenne, mert nagyon jó a játék és ezzel még jobb lenne. De én már annyira utálom a programozói kulimunkát. Kiver a víz ha rágondolok mennyi meló lenne ezt megcsinálni nekem. -
-
skoda12
aktív tag
Szerintem nincs fix definíció a devopsra, mert minden cégnél kicsit mást értenek alatta. Régen ez egy szemlélet volt, hogy a fejlesztők üzemeltetik is a saját cuccukat. Aztán kiderült, hogy ez nem illeszkedik a trendi fejlesztési modellekbe, mert az interrupt driven üzemeltetési problémák nem láthatóak előre, megbecsülhetetlenek, de azonnal meg kell oldani őket, felborítják a sprinteket és így kiszervezték az ops részt külön csapatokba és elnevezték őket devopsosoknak. Erre mondják, hogy ahol külön devops csapat van, ott külön ops csapat van.
Alapvetően minden feladatot megpróbálnak áttolni devopsnak, ami nem eredményez konkrét business valuet, de mégis szükség van rá a működéshez: deployment, cloud infra, ad-hoc scriptelések, monitoring, stb. -
-
cucka
addikt
De, pont ezért van, leleplezted a nagy IT-ipar összeesküvést!
Viccet félretéve - a devops és az üzemeltetés az ugyanaz.
Csak régen az üzemeltető az volt, aki a hóna alatt becipelte a szervert a szerverterembe. Most meg ugyanez az ember ír egy python scriptet amivel a cloud-ban szervert hoz létre, voilá, devops. -
#18481
coco2
őstag
mindthecrap
#18480
coco2
őstag
válasz
mindthecrap
#18480
üzenetére
Hmm, valaki világosítson fel, mert el vagyok tévedve, de nagyon.
A devops nem bűnbaknak van azért, mert sem a programozók sem az üzemeltetés nem ért semmihez, de lévén ők a dicsőségesek, tekintélyt kell védeni?
Biztos meg lehet fogalmazni diplomatikusabban is, csak ahhoz én nem értek. Help plz!
-
padzso
tag
Köszönöm mégegyszer a válaszra méltatást!
A hozzászólások alapján legalább el tudok indulni, aztán úgyis letisztul később az, hogy mire lesz idő, kapacitás. Mindig a reálisan elérhető célokat tartottam szem előtt, most is igyekszem ezt betartani.
Motiváció az biztos lesz, már csak rendszeres gyakorlat kell hozzá és tényleg nekilátni komolyabban, mert amit a jelenlegi tanfolyam nyújt az nem valami sok.
-
coco2
őstag
válasz
padzso
#18474
üzenetére
Szerintem sem kell feladni. Az első lépések nehezek. Meg kell értened a leképezést, hogyan lesz a kézzelfogható valóságból absztrakt adat képezve, aztán mi a realitás amögött, amire és ahogyan az adatot használják. Ha azt sikerül átlátnod, és rá tud állni a gondolkodásod a miértekre, onnantól könnyebb lesz.
Ha mégsem a programozás a kedvenced, IT-ben van például design / esztétika. Az a grafikai vonal, ami mellé html tördelni kellhet. Van marketing vonal, címszavak súlyát érezni a köztudatban, és átfogalmazni a bullsh1tet. Ha találkoztál már a "seo"-val, az arról szól. Jó szónokok előnyben. Van technikai segítségnyújtás, amikor gyakorlatilag az egész napodat autóban töltöd, és mászkálsz ügyfelekhez visszadugni azt a kábelt, amit ők véletlenül kihúztak, és nem mernek hozzáérni, hogy ők dugják vissza. Valakinek oda kell menni, és annyi a lényeg. Van az üzemeltetés, amikor 24 órás üzemben azt nézed egy levegőtlen lukban (iroda helyiség), hogy rendben működik valami, és ha mégsem, adva van a tennivalók listája, mit kezdhetsz vele - insomniásoknak való munka. Van üzletkötés, amikor te dumálod meg az ipsét, hogy vegye meg a sz@rt 3x-os áron. Mentalistáknak van kitalálva. Lehetsz munka vezető, ha elég jó rabszolgahajcsár vagy. Pszichopaták előnyben. Szóval van IT közelében bőven temérdek sok más, nem csak programozás.
-
-
JoinR
őstag
válasz
padzso
#18474
üzenetére
Szerintem sem kell a seniorságról lemondani, ha nincs is meg a Z-generáció lendülete, hogy pár év alatt azzá válj, a nyugdíjig még sok idő van.
Ha mégsem a programozás vonz, ránézhetsz a system admin, devops, esetleg SRE vonalakra, a leírásod alapján lehet, hogy szellemiségében azok jobban tetszenének a hardcore programozásnál. -
K1nG HuNp
őstag
válasz
padzso
#18474
üzenetére
miert ne lehetne beloled senior szoftverfejleszto? ennek semmi koze a korhoz. szerencsere nem azt nezik, hogy hanyszor tudsz egy kezzel fekvozni 30 perc alatt. 4-5 ev alatt siman ki lehet kupalni magad. ha van annyi motivaciod belulrol akkor siman otthonrol full ingyen a netrol, ha nincs akkor egyetem, ott majd basztatnak
-
padzso
tag
Sziasztok!
Az alaphelyzet: 44 leszek ez évben, szeptemberben elkezdtem 1 tanfolyamot, amit hívjunk érettségi után végezhetőnek(nem magyar, szóval nem akarok mellévezetni a megnevezéssel senkit). Ez csak 10 hónap, utána papír jár. A megnevezése: Szoftver és applikáció fejlesztés. Az elnevezésnek talán nagyobb a füstje, mint a lángja.
Tantárgyak: alap html és css, python, blokkok rakosgatása MIT app inventorral, BBC microbit, matek, adatbázis (tkp. Access), kommunikáció, digitális marketing.
21 éve szereztem egyetemi diplomát, nem ebben a témakörben. Az azóta elmúlt években kétkezi munkából volt kenyerem, most eljött az idő a karrierváltáshoz.Programozásról csak olvastam, nem írtam, tinédzser koromban volt egy kevés C64, basic, aztán annyi. Szeretek romokat tenni a telefonjaimra, ilyen-olyan problémamegoldások után kutatni, aztán molyolni velük. Meg aztán telepítgetések, hardveres kalandozások. Épp CSS weboldalt kell beadni, ahelyett, hogy inkább követném a a vizsgalapot és egyszerűen összedobnám, letöltök egy komplexebb keretet s azzal szórakozok, hogyan lehet gif-ből kimetszett ikonnal fb-re linkelni. Ezek érdekelnek, meg szeretek benézni a szoftveres színfalak mögé.
Azt tudom, hogy hekker vagy épp szenior szoftverfejlesztő már nem lesz belőlem. Mivel a tanfolyam eléggé alap, nem látom, hogy képes lennék-e egy adott feladatot mondjuk pythonra applikálni. Gondolom ennek nagyon sok gyakorlás és tapasztalás lenne az alapja. Ez az objektumorientált megközelítés eléggé új téma nekem. Meg úgy, minden.Vajon programfejlesztésben csak annak van lehetősége, aki kirázza a kisujjából az összeset, vagy kellenek olyanok is, akik besegítenek a mesternek?
Szóval érdemes lenne elmerülni a programokban vagy esetleg milyen irányt vehetnék még IT-ban?
Bocs, kissé bőlére lett eresztve, remélem érthető voltam. Köszönöm! -
coco2
őstag
Sziasztok!
Kicsi db topic.
Van egy lista a db kezelőkről itt, meg egy YT videó az arányokról itt.
Nehezen tudom összeadni, hogy mi történt az oracle rdbms-el. Hogy került az 30%-ról 3%-ra, vagy éppen fordítva, vagy az egy hírek simán csak nem igaz? Mondjuk a chart-ról nem sikerült kiderítenem, mikori, de nem tűnik őskorinak az sem. Ami sokadlagos forrásokat még találok, a mysql pozícióját igazolják vissza.
Követte valaki az eseményeket, hogy miféle db-geddon történt az elmúlt 2.5 évben oracle rdbms-éknél?
-
#18468
JoinR
őstag
kozeposztaly
#18467
JoinR
őstag
válasz
kozeposztaly
#18467
üzenetére
Nagyjából helyes a számítás igen. Neten bármilyen kalkulátorral leellenőrízheted (az más kérdés, hogy 100% pontos-e, ez például a kerettúllépést a 2022-es minimálbérrel számolja). Hogy pontosan hogyan kerül át más adózási formába a vállalkozás, ha eléri a limitet, nem tudom megmondani, erre van a könyvelő.
-
#18467
kozeposztaly
csendes tag
JoinR
#18463
kozeposztaly
csendes tag
#18460-ban írtam egy saját értelmezést, jól gondolom?
Ergo a 2023-ban felső limit egyéni vállalkozó - átalányadózó esetén 27M-nál 1.6M nettó per hóban számítódik.
Ha efölött szeretnék, akkor már kikerülök az átalányadózói körből, minden járulék alapja 100%-al számítódik, ergó ez a forma nem éri ott már meg. -
#18466
coco2
őstag
kozeposztaly
#18460
coco2
őstag
válasz
kozeposztaly
#18460
üzenetére
Ha átléped a 10x-es minimálbért, át kell térned tételes elszámolásra, és ott maradsz tárgy év + következő évre.
Ha fejlesztés mellé bevállalsz olyat, mint szerver üzemeltetés, szinte biztos, hogy azonnal fogod azt a korlátot átlépni. Azt lehetőleg hagyd az ügyfélnél
-
#18465
mobal
nagyúr
mindthecrap
#18464
válasz
mindthecrap
#18464
üzenetére
Javavál kezdtem és most python fejlesztéssel foglalkozom, szóval ez megint nem egy axióma. A jávának akár kezdésnek is sok előnye van...
A user pedig általában nem tudja mit akar
-
#18464
mindthecrap
aktív tag
mobal
#18461
-
#18463
JoinR
őstag
kozeposztaly
#18459
JoinR
őstag
válasz
kozeposztaly
#18459
üzenetére
Várható bevétel, kiadás, elvárt havi fizetés, kivennéd az osztalékot vagy eredménytartalék, stb..az, hogy milyen lehetőségek vannak egy EV számára, még egy origo cikk is jól összeszedi, de hogy neked mi a megfelelő, csak számolással lehet megmondani.
-
#18460
kozeposztaly
csendes tag
coco2
#18447
kozeposztaly
csendes tag
Jól tudom, hogy 2023ban 27.8M Ft éves bevételig választható? Magyarul havi 2.3M adózás előtti bevételig, amiből ha jól néztem 1.7M nettó marad kb. (ha nem ennyi, javítsatok ki)
Ergo egyéni vállalkozó + átalányadózás havi nettó bevételem max 1.7M lehet.
Efölött milyen lehetőségek vannak? Akkor már kikerülök az átalányadózásból? -
Drizzt
nagyúr
válasz
ValGerald
#18456
üzenetére
És az miért baj? Amióta van professzionális Java programozás, azóta nem nagyon volt olyan év, amikor ne tartozott volna a 3 legjobban fizetett nyelv közé(, a 2-t is meg merem talán kockáztatni). Mellesleg Java-val dolgozni nagyon jó, a nyelv kötöttségei miatt nagyon könnyű például automatizáltan refaktorálni, nagyon könnyű megbízható kódot írni vele. Az ökoszisztémájával meg nem igazán tud felérni semmi. Végtelen agyonhasznált és bizonyított futtatókörnyezet, library és framework van hozzá és hasonló mértékben fejlődnek is, meg keletkeznek teljesen újak. Közben maga a nyelv is egyre gyorsabban fejlődik, gyakran más nyelvekben kipróbált és bevált újdonságokat beemelve.
De bevallom én is utáltam a Javat amikor egyetemen tanultam, kb. J2SE 1.2-t, ráadásul az akkoriban még igencsak kezdetleges Eclipse-szel. De ugyanezt már egy JDK8 + IntelliJ-re cserélve is kb. mintha űrhajóba raknák az embert. Ami meg azért létezik már szintén majd 1 évtizede. -
Ispy
nagyúr
Én először szétszedem kisebb részekre, és elsőre csak a vázát írom meg a végéig, a nem fontos részekkel nem foglalkozva, hogy menjen az elejétől a végéig. Ha ez megvan, akkor jöhetnek az apróbb, baszakodós részek is. Pont mint egy házépítésnél, először legyenek falak, meg tető, a többi csak utána.
-
válasz
btraven
#18451
üzenetére
A rendes programozással az ilyen game jamek olyan kapcsolatban vannak , mint a rendes rendrakással az, amikor a vendégek érkezése előtt öt perccel megpróbálsz minden kacatot eltüntetni szem elől
Nyilván megvan a maga varázsa, tökre jó arra, hogy az ember gyorsan kipróbáljon mindenféle ötleteket, de a végén előálló kód az leginkább csak arra jó, hogy eldobja az ember és rendesen újraírja, amikor már van ideje és már nagyjából látja, hogy mit is szeretne csinálni (és ez fontos, mert játékfejlesztésnél általában nem a konkrét programozás a sok idő, hanem az, hogy menet közben szokott kiderülni, hogy ami papíron remek ötlet volt, az a gyakorlatban nem annyira működik, ami meg csak szinte véletlenül került bele, az meg igen).
-
-
btraven
őstag
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. -
acsati
aktív tag
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?
-
#18447
coco2
őstag
kozeposztaly
#18444
coco2
őstag
válasz
kozeposztaly
#18444
üzenetére
A legkisebb rutin szétesés a kata után a magánvállalkozó átalányadózással. Valamennyi pénzt elbuktál, huncutkodni ezután nem fog menni, de az minden változás.
-
#18446
mindthecrap
aktív tag
acsati
#18435
mindthecrap
aktív tag
válasz
acsati
#18435
üzenetére
É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.
-
#18445
JoinR
őstag
kozeposztaly
#18444
JoinR
őstag
válasz
kozeposztaly
#18444
üzenetére
Kevered a vállalkozási formákat az adózási formákkal. Valszeg bt/kft a megoldás tao/kivával, de konkrétum nélkül nem lehet sokkal többet mondani. Egy könyvelővel kellene leülnöd átbeszélni.
-
#18444
kozeposztaly
csendes tag
kozeposztaly
csendes tag
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!
-
coco2
őstag
válasz
acsati
#18435
üzenetére
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.
-
válasz
acsati
#18435
üzenetére
Ez alapján a front-end fejlesztői környezet felé nézelődnék, de az nem pont egy telített terület?
Ha nem vagy igazán jó benne, akkor minden terület telített, ha meg igen, akkor meg egyik sem
A full-stack tényleg mélyvíz, teljes kezdőként semennyire nem ajánlom. Akkor inkább a frontend, amihez már önmagában elkerülhetetlen a html, css, javascript hármasa meg bármilyen nagyobb projekthez valami framework is (react, angular, svelte, ilyenek).
A webes tanfolyamok / tutorialok között vannak egész jók, de ebben nem nagyon tudok segíteni. -
válasz
KubanitoS
#18436
üzenetére
Miért Java?
Frontenden, ami érdekli, abszolút nem használják és hát backenden is elég feketeöves (tippre nem is túl gyakori), mert a konkrét nyelv mellé még kell egy Spring vagy Hibernate is, hogy elinduljon.
Akkor inkább Javascript (aminek - a neve ellenére - semmi köze a Javahoz) / Typescript. -
acsati
aktív tag
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. -
coco2
őstag
válasz
K1nG HuNp
#18433
üzenetére
Viszont néztem az architektúrát (már amennyit kihámozni tudtam az oracle clustering doksiból), és nem hinném, hogy az a blog valótlant állított. A mysql cluster és az oracle database cluster elavult szemlélet megdrótozott gányolása. Az mssql ugyan semmi védelmet nem kínál a primary node kiesése ellen, de a replika szerkezet van annyira letisztult, hogy a split brain probléma azért nem tud adat konfliktust okozni.
-
coco2
őstag
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?
-
Marky18
aktív tag
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. -
-
É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?
Hogy lehessen majd rajta lekérdezéseket csinálni. Ugyanis - többek között - erre jó az adatbáziskezelő.
Szívesen. -
coco2
őstag
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.
-
válasz
sztanozs
#18420
üzenetére
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!
-
válasz
Vision
#18419
üzenetére
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)firewallproxy log kb fel-masfel milliard rekord. -
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.
-
cucka
addikt
válasz
Vision
#18417
üzenetére
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" -
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.
-
> 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.).
-
Drizzt
nagyúr
"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)] -
coco2
őstag
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.
-
> 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
-
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.
-
cucka
addikt
válasz
Drizzt
#18410
üzenetére
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.
-
cucka
addikt
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. -
-
coco2
őstag
>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.
-
> 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.
-
-
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.
-
cucka
addikt
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.
Ezt egy új regisztrációval ki lehet játszani vajon, vagy várható szerintetek leakciózás?
- a félreértés elkerülése végett ez a CD nem az a CD, ami a CI/CD-ben van. 
).
Az volt a kérdés, mivel érdemes belelógatni a lábujjadat a programozás vizébe ha nem vagy biztos benne, hogy egyáltalán érdekel-e, és nem az, hogy melyik nyelvre tedd fel a karriered 
![;]](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!
- Redmi Note 11 és 11S - biztos alapra jobb építeni
- gban: Ingyen kellene, de tegnapra
- sh4d0w: Netflix? Ugyan, VW előfizetés!
- Realme GT 2 - aláírjuk
- Háztartási gépek
- ThinkPad (NEM IdeaPad)
- AMD GPU-k jövője - amit tudni vélünk
- AMD Navi Radeon™ RX 9xxx sorozat
- Kerékpárosok, bringások ide!
- Egy óra, két rendszer
- További aktív témák...
- Új Acer Predator 16 WQXGA 165Hz G-Sync i9-13900HX 16GB 1TB Nvidia RTX 4070 8GB 140W Win11 Garancia
- Számítógép, ryzen 5 2600, RX 580 8GB, 16gb ddr4, 512gb ssd, 1tb hdd
- HP EliteBook 850 G8 Fémházas Multimédiás Laptop 15,6" -65% i7-1185G7 16/512 Iris Xe FHD
- Gigabyte GeForce GTX 1660 Ti OC hibátlan, dobozos, 14 nap személyes garanciával
- HP EliteBook 850 G8 Fémházas Multimédiás Laptop 15,6" -65% i7-1185G7 32/512 Iris Xe FHD
- Lenovo ThinkPad T14 G1 Ryzen 5 PRO 4650U 16GB 256GB 1 év garancia
- Bomba ár! Lenovo ThinkPad X250 - i7-5GEN I 8GB I 256GB SSD I 12,5" HD I Cam I W10 I Garancia!
- AKCIÓ! ASUS H81M-PLUS H81 chipset alaplap garanciával hibátlan működéssel
- Lenovo Thunderbolt 3 kábel (4X90U90617)
- Gamer Notebook! Acer Nitro 5! Csere-Beszámítás! I5 11400H / RTX 3050Ti / 16GB DDR4 / 500GB SSD!
Állásajánlatok
Cég: FOTC
Város: Budapest