- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- eBay-es kütyük kis pénzért
- Brogyi: CTEK akkumulátor töltő és másolatai
- bitpork: Phautós tali a Balcsinál 2025 Augusztus 2 napján (szombat)
- bambano: Bambanő háza tája
- gban: Ingyen kellene, de tegnapra
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Mr Dini: Mindent a StreamSharkról!
Hirdetés
Talpon vagyunk, köszönjük a sok biztatást! Ha segíteni szeretnél, boldogan ajánljuk Előfizetéseinket!
-
LOGOUT
Új hozzászólás Aktív témák
-
martonx
veterán
válasz
Vision
#20543
üzenetére
Ez olyan, hogy akinek kalapácsa van, az mindent szögnek néz. Értsd java fejlesztőként, eddig nyilván olyan cégeknél dolgoztál, ahol java volt. Minő meglepetés, bárhova néztél java-ban indultak a projektek.
Képzeld el, hogy mondjuk Go vagy Rust fejlesztő vagy. Nyilván olyan céghez mész, ahol Go-t vagy Rust-ot használnak, ergo bárhová mész, bárhová nézel Go vagy Rust projekteket látsz.
Mindenki burokban él, én csak erre próbáltam a fenti hsz-ekkel rávilágítani, amellett, elismerve, hogy a java tényleg elterjedt, csak ezeket a nagy kijelentéseket nem szeretem, hogy kizárólag csak ebben vagy abban lehet projektet fejleszteni. -
-
cucka
addikt
válasz
Vision
#20506
üzenetére
Én nem emlékszem ilyen kikötésre. Ezt ne vedd 100% biztosra, de szerintem nem fogják visszadobni a szimulátoros screenshotokat.
Delphi azért kopott ki, mert jött a java, ami letarolta a piacot:
- jvm, krosszplatform, a java applet-ek akkoriban jó iránynak tűntek
- teljesen menedzselt oop nyelv, ez a 90-es években komoly fícsör volt
- java ee meg hasonló enterprise fícsörök
- nem volt akkora brutál vendor lock in, mint a borland rendszerével.Utána meg a kegyelemdöfést a web adta meg, ami eredetileg ugye hypertext alapú médium volt, de szép lassan alkalmazás platformmá nőtte ki magát. Manapság más kb. senki sem fejleszt windows desktop alkalmazásokat, minden a webre költözött.
Manapság meg már halott ügy, minden javascript-java-dotnet, esetleg python, mindent saas meg paas platformok futtatnak, ahova havi pár eurós a bekerülési költség, minden fordító és fejlesztőeszköz ingyenes vagy nagyon olcsó.
Na és erre jön az Embarcadero a 2000 eurós fejlesztőeszközével (ez a basic bitch verzió, frissítések nélkül, az plusz pénz), hát nem hiszem, hogy egymást tapossák érte a vásárlók. -
nyunyu
félisten
válasz
Vision
#20315
üzenetére
Amúgy én dolgozom együtt olyan fejlesztővel (BME-VIK), aki nem ismeri a HTML nyelvet. De tényleg, nulla. Nem is értem, mert amúgy középiskolás anyag.
BME VIK-re jártam, ne is kérdezd hány évig.Eredetileg távközlés, aztán sokadik nekifutásra C# fókuszú szakirányon voltam.
Tanítottak mindenfélét (Pascal, C, C++, Java? aztán C#, Java, webes valamik), végül DB, DWH oldalon kötöttem ki.
Arra emlékszem, hogy egyik évben még a .Net 2.0 webes frameworkjeit nézegettük szakirány laborokon, következőben a .Net 3.0-át (Razor?), szóval valamikor tizenéve nézegettem a HTML, CSS, JavaScript akármiket is, de azokhoz nagyon nem értek (ahogy a Java meg C#-hoz sem.)Ellenben nemrég melóhelyen hozzámvágtak egy 700 soros SQL queryt, amit az egyik vezető Java fejlesztőnk csinált 5+ éve, elvileg 15 táblából szedi össze az ilyen-olyan webshopok hiteligényléseinek az állapotát.
Csak túl sokáig fut, néha megfekszik tőle a DB szerver, aztán attól az egész alkalmazás.
Még nem sikerült átlátnom a teljes logikáját, de némelyik alquerytől agyrákot kaptam, annyira rossz a futási terve: számlaszámonként lekéri a dokumentumok állapotát, rendezi beérkezési dátumra, kiválasztja a legnagyobbat, majd veszi a következő számlaszámot, és arra megint rájoinol leválogat, rendez, szűr...
Ezeket kicseréltem olyanra, hogy először rendezem a táblát számlaszámra és beérkezési dátumra, abból válogatom le a számlaszámonkénti utolsó sorokat, így mindjárt nem többtízezer számlaszámra külön-külön fut a query, hanem egy menetben az egész.
Mindjárt lefeleződött a futási idő, és a szerver sem pusztul bele.
Elvileg az SQL is középiskolás anyag, de jól csinálni az megint más skillszetet, gondolkozásmódot igényel, mint mondjuk a Java programozás.
Nyilván ez a frontend cuccokra is igaz, nehéz az almát a körtével összehasonlítani. -
cucka
addikt
válasz
Vision
#20319
üzenetére
A UI-UX dizájnerek többsége egy kétpálcás bohóc.
Ahhoz, hogy jó legyen a termék, nem tudod megúszni, hogy kicsit érts ezekhez. Ahogy a SEO-hoz is kell érteni.
És jó hogy vannak előre megírt komponensek, mert boldog-boldogtalan komponenseket ír, de a többségük szar. Tessék-lássék jól működik.
Aztán jön a júzer héberre állított telefonnal, gyengénlátó módban, és szétesik az egész amit csináltál.És a másik a performancia. Webvitals valaki?
Ha a youtube-on a live chat ablak leblokkolja 1 másodpercre a render thread-et akkor az is UX probléma, de mégis csak a fejlesztők baszták el, és nekik kéne megoldani.
Vagy téged is zavar, amikor betöltesz egy oldalt, és össze-vissza ugrál a szöveg, amíg a háttérben betöltődik a kép meg a reklám? UX probléma, de a fejlesztő baszta el.És akkor ne beszéljünk a typescript-ről (ami ugye jó, csak mellette a javascripthez is kell érteni), a packaging-ről, meg az egész ökoszisztémáról, hogy csinálsz egy lángossütőnek egy weboldalt, és 1 giga a node_modules-od, de azért jó lenne, ha gyorsan betöltődne, meg nem akadna meg az animáció.
A frontend egy nagyon mély nyúlüreg. A felszíne egyszerű.
-
Drizzt
nagyúr
válasz
Vision
#20319
üzenetére
"Arról nem beszélve, hogy tipikusan kész komponenseket reciklálnak."
Mintha backenden nem ugyanez lenne.![;]](//cdn.rios.hu/dl/s/v1.gif)
Tok mindegy, van komplex feladat boven UI es Backend oldalon is. Aki viszont barmikor amikor nem muszaj ujrafeltalalja a kereket, az minden teruleten sulyos gond. Kiveve ha eppen tanul, de annak meg nem a munkahely a megfelelo terulete.
Algoritmust irni meg szerintem nagyon ritka mind backend, mint frontend oldalon. Felhasznalni mas altal megirt algoritmusokat: az nagyon gyakori. Bar en valoszinuleg az algoritmus iras alatt foleg az adatstrukturak implementalasat ertem. Az esetek 99.99%-aban a megfelelot kell kivalasztani a problemahoz es azt felhasznalni. Tehat nekem az, hogy egy Map, lista, etc. elemein csinalok valamit, vagy irok egy SQL query-t, az nem algoritmus iras, hanem algoritmus hasznalat. De lehet nem igy kene hasznalnom ezt a kifejezest. -
cucka
addikt
válasz
Vision
#20312
üzenetére
Ez egy hatalmas tévedés, hogy "bezzeg a backend".
Valójában a frontend fejlesztés a legtöbb esetben sokkal nehezebb.A szoftverek 95%-ában a backend annyit csinál, hogy valami adatot beolvas valahonnan, transzformálja, majd valahova valamilyen formában kiszolgálja.
Ehhez képest jó UI-t készíteni az iszonyat nehéz. Ez egy eseményvezérelt, aszinkron rendszer, aminek gyorsan és helyesen kell működnie. A komplexitás, amivel dolgoznod kell, az jelentős.
És jó UI-ra az egyszerű szoftvereknél is szükség van. Sőt, ott van igazából szükség rá.
#20313galaxy55
Összegezd már, semmi kedvem órákon át hallgatni egy random kezdő programozó életsztoriját meg locsogását a szakmáról, ennél bármit szívesebben hallgatok. -
-
emvy
félisten
válasz
Vision
#20046
üzenetére
Igen. Szerintem keveredik a fejedben a 'webes' es a 'krossz-platform' fejlesztes. Az elso generacios krossz-platform fejlesztoeszkozokkel sokszor egy webappot fejlesztettel, ami utana egy beagyazott webbongeszoben futott. Egyreszt ez lassabb (volt), mint a nativ kod, masreszt nem nezett ki ugy, mint a nativ widgeteket hasznalo app.
Viszont a Flutterrel vagy Unityvel fejlesztett krossz-platform appok nem webes technologiat hasznalnak, es kulon fordul egy iOS meg egy Android kod. Kicsit mintha C++-ban irt programot forditanal le Linuxra meg Windowsra is.
-
martonx
veterán
válasz
Vision
#20042
üzenetére
Van aki ezt mond, van aki azt. A natív appok sose fognak eltűnni, ha state-of-the art appot akarsz, ami az adott platform legapróbb újdonságait is kihasználja, akkor azt adott platformokra külön-külön kell fejlesztened.
vs.
Fele annyi energia befektetéssel több platformra is elkészül ugyanaz a rendszer, amihez némi platform specifikus egyedi feature-t, megjelenési lehetőséget tudsz adni.
Ez volt az elmélet.
Szvsz ez a multiplatform fejlesztősdi kicsit humbug, ha tényleg igazi multiplatform akarsz fejleszteni (mondjuk IOS, Android, Windows desktop és Linux desktop, OSX), akkor azért abba komolyan bele kell állni, hogy mást ne mondjak Mac nélkül lehetetlen iOS-re, OSX-re fejleszteni, Mac-es ökoszisztéma felől nézve pedig nem ideális, de nem is optimális Androidra, más platformokra fejleszteni a sajátot kivéve.
Én inkább ott látom a multiplatform fejlesztés előnyeit, hogy bármilyen nyelven neki tudsz állni, miközben natív appoknál sok választási lehetőség nincs a felhasznált nyelveket illetően. Magamból kiindulva, mint .Net fejlesztő, én MAUI-val állok (pontosabban állnék) neki a cross-platform fejlesztésnek, de ez igaziból a C# miatt, nem pedig az annyira nagy cross-platformitás miatt, és a végeredmény tök jó lesz, agyontesztelve androidon, windows-on miközben remélhetőleg, ha oda kerül a dolog, és valaki Mac-en buildel egy appot belőle, akkor elvileg iOS-en (és OSX-en) is futni fog az app.
-
pmonitor
aktív tag
válasz
Vision
#20025
üzenetére
Ma már nyilván nem az a kihívás, hogy jó vezérlési szerkezetet írjál, hanem hogy ismerd a framework lehetőségeit/korlátait,
Ha ezt a nebulók olvasták, akkor nem tudom, hogy kit szidnak, hogy őket meg ezekkel a vezérlési szerkezetekkel szívatják. És még meg is buknak, ha nem csinálják...
Én személy szerint a harmadik linkemmel értek egyet. Tehát hogy ahhoz, hogy modulokból/legókból(nevezzük, ahogy akarjuk) összerakjon valaki valamit, ahhoz tényleg nem kell zseninek lenni. Ez gyakorlatilag SM/betanított munka. Persze abban az esetben, ha nem kell még "bütykölni" valamit a "beszerzett" kódon.
#20030 JoinR: És a fizettség/kp hol marad?
-
Micsurin
nagyúr
válasz
Vision
#19960
üzenetére
+ emvy köszi
kicsit jobban utána másztam és valóban. Egyre jobban érdekel a téma így, teljesen jó legalább kapok webstack után egy másik nézőpontot is és a cégnél is maradhatok ha ez bejön. 
Bérekre saccra mint a junior webdev? Nofluffon és glassdooron nem igen látok difit.
-
emvy
félisten
válasz
Vision
#19895
üzenetére
Abszolut igazad van, hogy nem erthet mindenki mindenhez, en igazabol azt nem szeretem, amikor emberek eltologatjak maguktol a megtanulando dolgokat, mondvan h 'nem az en dolgom'. Tehat szerintem egy jo BA-t alapvetoen erdekli a technologia es valamennyire konyit is hozza, csak nem az a fo felelossegi kore, vagy mittudomen, egy jo banki programozo baromi jol ert a penzugyekhez, csak nem napi szinten folyik bele. Szoval amit irtam, az ugy igazabol nem fair (tehat vszeg nem igaz az, amit sugalltam), csak ezt az eros szegregaciot nem kedvelem.
Volt hasonlo temakorben egy jobb iras, https://www.fishmanafnewsletter.com/p/balancing-engineering-cultures-debate-vs-do
szoval az se jo, ha mindenkinek mindenhez ertenie kell, meg az se jo, ha mindenki csak azzal hajlando foglalkozni, ami a nagyon szuken vett hivatalos feladatkore.De te is biztos lattal mar csomo 22 evest, aki bejelenti az elete elso allasinterjujan, hogy 'en nem koder akarok lenni, hanem architekt'. Az _osszes_ ilyen esetrol az derult ki nekem, hogy igazabol oket nem erdekli a technologia, es bar programozonak jelentkeznek, a leheto leggyorsabban el akarnak huzni valami olyan munkakorbe, ami jol fizet, de nem kell kodot irni. Egyebkent ugye a menedzsmentre is igaz, hogy a legrosszabb menedzserek azokbol kerulnek ki, akik az elso pillanattol menedzserek akartak lenni (szerintem a jo menedzsment a 'szolgalo' menedzsment, azaz amikor a vezeto megcsinalja a szar munkat, hogy a csapata csinalhassa az erdekes munkat).
-
coco2
őstag
válasz
Vision
#19792
üzenetére
Nem lepődnék meg. Én is tudom, hogy nem készül. És szerintem általánosítva kijelenthető, hogy a legtöbb cégtől ki is rúgnának, ha dokumentálnál, merthogy "pocsékolod az időt". Az eufémizmust lehámozva róla "annyira filléreken billeg a cég életben maradása, hogy a jövőre gondolni már nem jut pénz". De végső soron pozíció védelmet tud gyártani belőle a fejlesztő ("utánam az özönvíz"), aminek örül is egészen addig, amíg valaki rá nem mosolyog ("csak nehogy téged folytsanak bele abba a vízbe"). Szóval a helyzet fokozódik.
A georedundáns tárolók statikus vagyont védeni jók. Üzleti szerződéseket letétbe helyezni, meg a mindenféle blackmail felvételi anyagok és olyasmik. De egy szoftver cég valódi értékét mindig a folyó vagyonon méri fel a cégértékelés, a terméken, amit fejleszt, és bár a jogászok és üzleti népek nem tudják, de egy karbantartható alkalmazásnak kb háromnegyede a dokumentáció, egynegyede az implementáció, és kettő közül az implementáció az egyszerűen pótolható, ha elveszik. Ahhoz képest elrakják a forrás kódot, és azt mondják, biztonságban van a folyó vagyon.
Azon gondolkodom, hogy vajon épül a következő dotcom lufi, csak ezúttal nem ingatlannal, hanem szoftver cégekkel?
-
coco2
őstag
válasz
Vision
#19693
üzenetére
Az a 409 jelent mást is, mint például újabb adatot cserélni régebbire, ami nem feltétlen menet közbeni conflict.
Esetleg elgondolkodhatsz még a 423-ason.
(Nem maradtak szabik év végére?)
-
-
martonx
veterán
válasz
Vision
#19651
üzenetére
Dolgoztál már olyan kódon, amin alapvetően indiaiak dolgoznak? Mert én igen. Van egy nagy US cég, ahol az olcsó indiai programozó a policy. És hidd el, igazán nagy cégről van szó. No, ők engem és a magyar csapatomat kritikus helyzetekben bérelnek fel, amikor rendet kell rakni, vagy valami nagyon fontos feature-t mindenképpen határidőre le kell szállítani. Ott aztán mindent lehet látni a kódban :D pedig az aztán nagy enterprise kód
-
coco2
őstag
válasz
Vision
#19644
üzenetére
Nem kell közvetlenül egymáséba beleírni. Írnak a saját területükre, és a másik azt átolvassa.
Akár egy gépen vannak, akár külön, gyártasz rá egy interface-t, és azon keresztül csinálod az adat cserét valami aszinkron protokollal - nem szabadna gondot okozzon összeraknod valamit magadnak. Abban a formában egyúttal megvan a placeholder a webapi-ra a jövőre vonatkozóan, amikor majd külön gépekre költöznek a darabok. A jelenben webapi helyett db műveletek elegendőek. Van sebességed / kicsi overhead-ed.
-
-
pmonitor
aktív tag
válasz
Vision
#19434
üzenetére
'97-ben főiskolai matek vizsgám volt(jeles). De ez már történelem...
Mondjuk sok matek ehhez nem kell, csak logika. Vegyük a wiki-s példát. A következőket kell levágni 5600 mm-es szálakból.2200, 20
2150, 18
2140, 16
2100, 14
2050, 12
2000, 10
1930, 20
1880, 18
1820, 18
1710, 14
1560, 12
1520, 25
1380, 22A wikis "megoldás" ez:
2 db 1820 1820 1820 : 140
2 db 1710 1710 2150 : 30
3 db 1380 2150 1930 : 20
12 db 1380 2150 2050 : 20
7 db 1380 2100 2100 : 20
12 db 2200 1820 1560 : 20
16 db 1520 1930 2140 : 10
10 db 1710 2000 1880 : 10
8 db 2200 1520 1880 : 0
1 db 1520 1930 2150 : 0Az én "megoldásom":
1 db 1820 1820 1380 : 580
3 db 2140 1710 1710 : 40
8 db 2140 2050 1380 : 30
3 db 1930 1820 1820 : 30
6 db 2200 2000 1380 : 20
6 db 2200 1820 1560 : 20
5 db 2140 1880 1560 : 20
7 db 2100 2100 1380 : 20
4 db 2050 1820 1710 : 20
1 db 2150 1880 1560 : 10
4 db 2000 1880 1710 : 10
8 db 2200 1880 1520 : 0
17 db 2150 1930 1520 : 0Csak 1szerűen gondold végig, hogy melyik jobb!
-
-
coco2
őstag
válasz
Vision
#19007
üzenetére
Az SAP egy olyan őrültekháza világ (eufemizmus a krónikus korrupcióra), hogy ha azoknak a kódereknek egy jó pszichológusra van szükségük, azon nincsen mit csodálkozni
IT-közeli dolgok: grafika, design, színkorrekciók, dokumentum szerkezet tervezés, felhasználói élmény tervezés, seo, marketing, modellezés / 3d, és biztos lehetne még sorolni cudar hosszan. Egyikhez sem kell egyetlen sornyi kódot sem írni. Az egykori átkos világban egy szoftver fejlesztése úgy nézett ki, hogy a user sztorit nekiestek szétkapni üzleti, technikai, társadalmi paraméterekre, és egy megvalósíthatósági tanulmány kiderítette róla, érdemes-e invesztálni az elgondolásba, vagy sem. A user sztori után létezett tervdokumentáció. Arra volt jó, hogy kiszűrje az összes olyan deklarációt, ami nem implementálható. Aztán volt implementáció terv, ami definíció szintjén írta le az elgondolást, mint memória model, és állapotgépek fázisai, azok kapcsolódása egymáshoz. És végül a tényleges implementálás már csak "rabszolga-kóder" munka volt. Azóta a miértek és hogyanok a köztudatban mind a rabszolga kóderre lettek ráhajítva, és most egyben kell érteni a tervezési lépésektől kezdve mindenhez (#érteni-mindenhez-is). Átlag. De attól még lehetnek oldschool berkek itt-ott, ahol nem annyira eszelős az ügyvitel, és ott bőven lehet IT-közeli dolgokat csinálni (akár "fejleszteni") anélkül, hogy valaki valaha egyetlen sor kódot írna, vagy valaha látott volna fejlesztői környezetet életközelből.
Ami a közgázosok programozóvá képzését illeti, én inkább az ellenkező irányra láttam példát. Nem kevesen végeznek mérnök infón, majd szembesülnek vele, hogy "ejj, én nem ilyen lovat akartam", végül rámásznak egy mérlegképes könyvelő képzésre, és abban maradnak. Az egészen jelenkori állapotokból nem vagyok up-to-date, nem tudom könyvelőből most mennyit keresnek, vagy rugdalják ki őket mindenhonnét.
-
axioma
veterán
válasz
Vision
#19000
üzenetére
Szerintem a matekos teruletek egy resze ugyan oktatasilag (ha kell erteni a tetel miertjet) tartalmaz ugyan absztrakt gondolkodasi igenyt, de utana mar alkalmazott matek, koveti a definialt de amugy keszen kapott szabalyokat. Az emelt matekban is csak mar ismert tenyeket kell max. 2 szinten alkalmazni. Az, ahol a real _alkotas_ kell, az inkabb a matekversenyhez hasonlit, es az alkotas van az IT-ben meg az epiteszetben benne. Ami lehet masik szint, mint a penzugyes. Azt nem merne'm megtippelni, hogy ez IQ (magas szintu pattern matching) alapu, vagy valami ma's, ferfiakban erosebb tulajdonsag (pl. komfortzonabol kilepes vs. feszekrakas/allandosag).
-
-
skoda12
aktív tag
válasz
Vision
#18975
üzenetére
Nincs semmi társadalmi megbecsültsége az IT-nak. Nem menő. Sokan azt gondolják, hogy aki abban dolgozik, az úgyis kocka / geek / incel / femcel és senki nem akar a nem menők közé tartozni. Esetleg a south parkos wow guyra gondolnak, ha az IT szóba kerül. Egész nap gép előtt ülni is ciki, nem akarják ezt. Nem mintha felnőttként a szellemi foglalkozásúak 99%-a nem pont ugyanezt csinálná.
Ezerszer inkább elmennek az emberek egy olyan szakra, amiről azt sem tudják hol lehet majd vele elhelyezkedni végzés után. Gimiben az egész évfolyamról csak én jelentkeztem infós szakra, pedig voltunk legalább 120-an.
Az IT szakoknak az a szerencséje, hogy a fiúk egy részét beszippantják a PC-s játékok és mivel a géppel töltik az idejük jelentős részét, így adja magát, hogy valami ilyesmivel akarnak majd foglalkozni később. Mióta közhírré tétették, hogy az IT-ban van lóvé, azóta ez picit változhatott és többen választják a pénz miatt talán.
Talán Egyiptomot szokták felhozni példának, hogy náluk majdnem 50-50% a férfiak és nők aránya a területen, mert ott az IT egy társadalmi kitörési pont.
-
coco2
őstag
válasz
Vision
#18925
üzenetére
Lakóépületben közös képviselő kitalálja, hogy extra védelemként szereljünk fel a házban biometrikus azonosítót kulcs-helyettesítőnek. Felkerülnek azok az adatok egy olcsó környezet eszközeire, és máris ott a lehetőség kompromittálódni. Ha nem azonnal, telik az idő, lecserélik a közös képviselőt, vagy bármi esemény történik, ami után az előző adatok kevésbé gondos kezelést kapnak. A hétköznapi életben temérdek sok az esemény, amikor ilyen adatok akárkinek a kezébe odakerülhetnek. És csak egyszer kell valakinek tudatosan feljegyeznie téged.
-
emvy
félisten
válasz
Vision
#18925
üzenetére
Van; plusz ott vannak azok az esetek, amikor pl. van egy ikertestvered, stb. Tehat nincs revokacios lehetoseg. Ezert jobb az, ha koveti az ember az MFA szabalyokat:
- something you are (biometrikus -- ujjlenyomat, arc)
- something you have (eszkoz -- telefon, yubikey)
- something you know (pin kod, jelszo, stb.)Tehat pl. amikor a telefonodon aktivalod a banki appnal a Face ID-t, akkor a 'something you are' es a 'something you have' kombot hasznalod.
Ezert sem tarolja el a bank pl. az ujjlenyomatodat: egyreszt kompromittalodhatna, masreszt onnantol az egy faktor, nem ketto.
-
emvy
félisten
válasz
Vision
#18919
üzenetére
Gondolom ez alkalmazastol fugg; a webauthn-jellegu flow (ami az eszkozon tarolt privat kulcsos alairassal mukodik) az igazan fasza, meg olyan is van, ahol az eszkoz a jelszot tarolja, az kevesbe fasza.
Egyik esetben sem az eszkoz csinalja az autentikaciot onmagaban, mindenhol van egy szerveroldali folyamat is.
-
emvy
félisten
válasz
Vision
#18911
üzenetére
> Én az Erste George App-ba most is FaceID-val lépek be. Ez mondjuk érdekes kérdés, hogy jelen esetben akkor az Apple szolgáltatja az authentikációt?
Majdnem, de nem egeszen; de azert nem rossz pelda. A biometrikus azonositasnal az tortenik, hogy az identitasodhoz tartozik egy azonosito, ami egyebkent az eszkozt azonositja. Amikor bejelentkezel, akkor azt bizonyitod be, hogy az eszkozt fel tudod oldani.
Tehat hasonlo, mint pl. egy Google Login, csak nem azt bizonyitod be, hogy 'az enyem az az emailcim, amit hozzarendeltem az identitasomhoz', hanem azt, hogy 'az enyem az a fizikai eszkoz, amit hozzarendeltem az identitasomhoz'.
-
fatal`
titán
válasz
Vision
#18891
üzenetére
Én nem vagyok ebben olyan biztos, pláne a Facebook esetén. Mondjuk nekem nem a kompromitálódás a probléma, hanem önmagában az adatkezelésük. Felőlem mindenki azt csinál, amit akar, de azonnal otthagynék egy bankot, ahol kizárólag facebook login van, még viccnek is rossz.
-
coco2
őstag
válasz
Vision
#18874
üzenetére
Funny sztori a jogászok valamit félrefogalmaznak, és a FB aukción eladja a banki belépődet. Elvégre azok az adatok neki vannak üzleti célú használatra
Elsődleges bankszámlát teljes joggal tuti biztos nem adnék az FB felügyelete alá. Az SMS hitelesítés elég jól van kitalálva, nekem nem tetszene azt lecserélni.
Talán valami másodlagosat odaadnék a FB vagy bárminek. Mondjuk egy wise számlára előre oda utalt pénz erejéig költeni a webshopokban. Az okés lehet.
Kérdés, hogy mi a fenét keresne a FB azon a területen? Keleten TenCent-ék csinálnak ilyesmiket, nekik működik, de nekik fejlesztőik is vannak, nem csak trollkodó jogászaik, mint a FB-nak.
-
coco2
őstag
válasz
Vision
#18499
üzenetére
Céges logisztikát illetően olyasmin gondolkodtam, mint emberek legalább 45%-a hamarabb megy el, mint medior szintig betanulhatna, senior előtt még 45% elmegy, senior idővel öregszik ki, kell az utánpótlás, meg a munkák egy része különben sem igényel juniornál több képzettséget, és ha legyen olcsóbb a munkaerő, nosza legalább 6* annyi junior legyen, mint amennyi a jövőre vonatkozó senior igény. Vagy valami hasonló. Egészen biztos vagy benne, hogy nagyobb csapatokban nincsenek hasonló megfontolások? (Vagy csak te vagy naív feltételezni, hogy mennyire számító a team lead-ek élete?)
-
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. -
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" -
-
pmonitor
aktív tag
válasz
Vision
#18105
üzenetére
Még szerencse, hogy nem vagyok IT-ban.
De ahogy elnézem nem is szeretnék. Bár mondjuk ha kényszerű választás előtt állnék, hogy csak úgy lehetnék egészséges, hogy ha IT-ban dolgozom, akkor természetesen az IT-t választanám. De egyébként én megmaradnék a hobbi programozgatásnál. Csak a fő programozási nyelveket változtatnám meg a régebben felsoroltakra... -
Ispy
nagyúr
válasz
Vision
#18014
üzenetére
Nem hiszek benne, hogy ne lehetne egy villanyszerelő is profi abban, amit csinál, és egy programozó ne lehetne középszerű, vagy csak szimplán szar. Aki komolyan veszi a szakmáját, az mindegyikben megtalálja a kihívást, a fejlődést, a tanulást és eljuthat a legmagasabb szintre vele.
Nem, nem árokásó cigányról beszélek.
Én nem, a programozáshoz nem kell egyetem, 20 évig tanulni a padban és matematika zseninek lenni. Van olyan is, de a többség rohadtul nem az, és nem is kell annak lenniük.
Vagy most mégis mi olyan rohadtul bonyolult extra dolog egy sql lekérdezést megcsinálásában vagy egy rest api backend megírásában? Vagy egy webáruház megírásában? Pont ugyanolyan nehéz, mint megtervezni egy ház elektromos hálózatát és bekábelezni.
-
Ispy
nagyúr
válasz
Vision
#18010
üzenetére
Amúgy a közhiedelemmel ellentétben a programozás is egy ugyanolyan szakma, mint bármi más, ugyanazok a szabályok érvényesekre rá, nem ufok és nem is zsenik a programozók.
Semmivel sem bonyolultabb programozónak menni, mint lakatosnak vagy burkolónak, persze más skillek kellenek hozzá, de ez igaz minden szakmára.
-
pmonitor
aktív tag
válasz
Vision
#17991
üzenetére
Ha tudtok írni olyan gyakorlati példát, amit nem lehet az ittenke lévő fogalmak ismerete nélkül megcsinálni, csak akkor, ha ezeket a fogalmakat ismeri valaki, akkor elismerem, hogy én vagyok fordítva összerakva...
-
Ispy
nagyúr
válasz
Vision
#17966
üzenetére
Persze sok mindent lehet, kérdés mire van lehetőség és idő, nem mindenki hobbiból készít programot, hanem mondjuk van 3 napja egy feladatra, ott te nem forgatsz semmit sehova, át meg pláne nem variálsz egy kiadott és működő db-t. Sajnos a legacy kód sokszor nagy úr.
De én spec inkább írok 1000 soros tárolt eljárást, mintsem szétszedjem az egészet 20részre, aztán 1 év múlva egy debuggolás egy rémálom lesz.
Persze ezek már sok tényezős dolgok, mekkora cég, mi a history, mennyi munkatárs, milyen policy stb, itt aztán már lehet minden is.
Mondjuk legutóbb kellett csinálnom egy excel exportot 1xx oszloposat, ami tényleg mindenhonnan szedett össze adatokat, különbőző számításokat végzett a különbőző adatrétegek között, szépen meg lehetett csinálni egy darab tárolt eljárással, pár temp táblával és sok tagolással, hogy később olvasható maradjon.
De ha olyan a feladat, hogy egy részfeladatot érdemes kiemelni, akkor arra inkább csinálok egy általános megoldást és kiszervezem a kódot, szóval elég speciális az, hogy mikor mi a jó megoldás.
Sqlben egyébként is a hasznos kód sokszor nagyon kevés, mert éppen én úgy szeretem formázni mondjuk az inserteket, hogy egy sor egy mező, hopp máris a fél kód insertekből áll.
-
Ispy
nagyúr
válasz
Vision
#17953
üzenetére
Ez erősen függ a kontextől, egy microservice is lehet komplex, hiába állnak a részegységek 10-20 sorból. De mondjuk egy bonyolult sql lekérdezést van, hogy nem tudsz megoldani 1000 sor alatt, ha meggörbülsz sem. Nem attól lesz egy kód rossz, hogy hosszú, hanem ha spagetti, felesleges köröket tartalmazz. Egyébként egy 20 soros kód is lehet komplex az én olvasatomba, hiszen egy problémára add választ, ami egyébként további több 100 20 soros kódból áll össze. Nem egy konkrét eljárásra gondolok, hiszen a fealdat megoldása komplex, és te hiába mész oda vele egy idegen fórumra, hogy adjanak rá választ, mert nem létezik rá kész válasz. Azt neked kell megtalálni. Minden más meg 10 perc gugli használat, csak a legtöbben nem tudnak keresni, lusták vagy csak szimplán fogalmuk sincs mit is akarnak csinálni. Szóval az én olvasatomba például egy prog.hu 95%-a olyan kérdésből áll, amit bárki megoldhatna gugli segítségével is, a maradék 5%-ra meg jó eséllyel nincs abban a formában megoldás.
-
válasz
Vision
#17880
üzenetére
Hogy lehet az, hogy meg tud nyitni fertőzött URL-t?
Mondjuk ez a resz praktikusan kivedhetelen - hacsak le nem korlatozzak teljesen a webbongeszest (ugy hogy hirportalok, meg webkereso sincs) - de ilyet idehaza egyedul az MNB-nel hallottam 10+ eve az akkor ott dolgozo kollegatol (de lehet, hogy ok is lazitottak mar azota). -
válasz
Vision
#17529
üzenetére
Pontosan - az, hogy nincs rendes készletkezelés, a cég sara, nem a fejlesztőé.
Vagy van, de nem akarják használni, vagy eleve nem is akartak, mert minek.(tudom, hogy nem neked válasz, inkább csak elmélázás) Ráadásul még mindig nem vágom, hogy az, hogy 2 hét után ír rá valaki a cégből, hogy "ja, bocs mégsincs", az mitől lenne a webshopot fejlesztő hibája...
-
coco2
őstag
válasz
Vision
#17443
üzenetére
Az, hogy valami szórakoztatóbban van magyarázva, nem feltétlenül jelenti azt, hogy eltérő entitással van dolgunk. Páran arra építenek investor-vadászatot, hogy miszticizálnak dolgokról, mert a gazdasági élet tisztán tartásának érdekében ki kell fosztani mindenkit, akinek több a pénze, mint a szellemi tisztasága. Sajnos, nem kevés digitális szemetet hagynak maguk után, amit az informatikának kell majd takarítania. Én itt és most csak arra kérdeztem rá, hogy a takarítás után mi tud majd megmaradni? Meg fog maradni bármi? Vagy tisztán csak hazugság volt az egész? Ha tudsz olyan példákat, amik ragadozás-mentes létezésre alkalmasak, jöhetnek mind.
-
coco2
őstag
válasz
Vision
#17369
üzenetére
>szatelit rendszerekkel, amelyeknek vagy nincs normális dokumentációja, vagy elavult
A mai világban tessék leszokni az általánosításról. Esélyesen közbeékelődött valaki, aki borítékot akart a zsebébe. Tőled, akkor, és ott nem kapta meg. Szóval neked, akkor, és ott nem volt dokumentáció.
Hogy egy pályára állított műholdnak ne legyen még az utolsó csavarjáról is 3x ellenőrzött dokumentáció, az nonszensz.
-
martonx
veterán
válasz
Vision
#16855
üzenetére
Előző, nem banki munkahelyemen, meg rendszeresek voltak a több milliárd soros DB táblák. Ott is észnél kellett lenni, minden egyes SQL lekérdezésnél, és nyilván egy 2 TB-os DB táblát cachelni se lehet
vagy legalábbis észnél kell lenni, hogy mit, mikor, milyen aggregáltsági szinten cachel az ember.
Azaz amikor cachelésről beszélünk, ne arra gondolj, hogy oké lerántom a táblát memóriába, és probléma megoldva. Ennél a valóság az esetek többségében nyilván bonyolultabb (bár kis rendszereknél, ez nyilván egy könnyű járható út). -
martonx
veterán
válasz
Vision
#16837
üzenetére
dolgoztam bankoknak, OTP-nél egy időben még külsős IT tanácsadó is voltam pont ilyen esetekre (mert én is csak egy nick vagyok aki ugatja a szakmát, mert nem atoi-t optimalizálok hehehe).
De mindegy is, semmi értelme egy ilyen fórum keretein belül mélyebbre mennünk. Írtál egy problémát, páran írtunk lehetséges megoldási javaslatokat, aztán ebből mindenki azt hoz ki, amit a lehetőségei, képességei (bankokat ismerve és pár kivételt mélyen tisztelve de a többség inkompetens, kezdve a menedzsmenttől, a programozókig) és a projekt scope-ja engednek.
Számomra az egészből egyedül az volt a lényeg, és amiért nagyon hálás is vagyok neked, hogy @pmonitorral ellentétben hoztál egy valós életbeli programozói problémát, szemléltetve, hogy nem az atoi-val kell szórakozni, hanem olyan robosztus rendszereket írni, tervezni, amik valós ügyfél problémákra reagálnak.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Tok mindegy, van komplex feladat boven UI es Backend oldalon is. Aki viszont barmikor amikor nem muszaj ujrafeltalalja a kereket, az minden teruleten sulyos gond. Kiveve ha eppen tanul, de annak meg nem a munkahely a megfelelo terulete.
Némelyik dicsőséges nagy cég kódjai turhábbak mint egy hobby project 
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Samsung Galaxy A56 - megbízható középszerűség
- ASUS notebook topic
- Suzuki topik
- Apple MacBook
- Épkézlábnak tűnő, vezetékmentes, de olcsó billentyűzet jött a Redragontól
- Kuponkunyeráló
- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- Debrecen és környéke adok-veszek-beszélgetek
- Kerékpárosok, bringások ide!
- További aktív témák...
- LG OLED55C9 prémium TV - 140cm, 4k, 120Hz - apró vizuális hibával
- Erős Gamer / Munka PC i7-14700, RTX 3070 Ti, 32GB RAM, 1TB SSD
- Samsung Galaxy A52S 5G Dual 8/256
- Brutál ERŐMŰ! Lenovo P710 / 2x Xeon E5 (44 mag!) / 384GB DDR4 / 2x 512 SSD / 8TB HDD, ASUS 1660 6GB
- Asus ROG X13 Flow 2in1 Touch WUXGA 120Hz Ryzen9 5900HS 16GB 1TB SSD Nvidia RTX 3050Ti Win11 Garancia
- Honor MagicBook 16 Ryzen 5 5600H 16GB 256GB FHD 144Hz
- Update 08.01. - Bomba árak 2025-ben is! Üzleti - Consumer laptopok DELL FUJITSU HP LENOVO
- Új Dell 14 Inspiron 5435 FHD+ Ryzen7 7730U 4.5Ghz 16GB 512GB SSD Radeon RX Vega 8 Win11 Garancia
- Akció! Gigabyte Vision Z590 D Wi-Fi Alaplap! LGA 1200!
- BESZÁMÍTÁS! Apple MacBook Pro 14 M4 Pro 24GB RAM 512GB SSD macbook garanciával hibátlan működéssel
Állásajánlatok
Cég: FOTC
Város: Budapest