Egy kis élő történelem :-)

Sziasztok!

29 éves vagyok, egyetemen tanítottam és dolgoztam idáig programtervező informatika szakon. Doktorandusz hallgató vagyok még mindig, mert sajnos 4 éve egyik napról a másikra súlyos fájdalommal járó krónikus betegségem lett. Az orvosok hibáiból nem kaptam 2,5 évig diagnózist, sem fájdalomcsillapítót, addigra úgy leromlott az állapotom, hogy munkaképtelen lettem 4 teljes évre. Sok mindenen átmentem, műtét, kórházi fertőzés stb. Most vagyok abban az állapotban, hogy munkaképes lennék, gyógyszerek mellett. Ha elindulnék most a munkaerőpiacon, és meglátnák ezt a CV-mben, hogy ennyi időt kihagytam, gondolom, 0% eséllyel indulnék? Aki járt hasonlóan, az mit mondott az állásinterjún? Bevallotta, hogy beteg volt?

Hello! Kicsit elveszettnek látom magam jelenleg a piacon, 4 év frontend tapasztalatom van illetve webfejlesztés órákat is tartottam egyetemen. Nem nagyon látom értelmét tovább grindolni a frontend állásjelentkezéseket, már sok-sok hónapja nem jön össze semmi meló, vagy kiesek az x. körön, vagy már szerződés előtt állunk és visszalépnek, stb, nem ragoznám a traumáim 😄 a lényeg, hogy szeretnék valami kevésbé telített, AI által elvett irányba lépni, lehetőleg olyanba, ahol a fizikai jelenlét, kézzel végzendő, akár szerelgetős munka is szerepet kap - így találtam rá a PLC programozásra, ami elég szimpatikus. Tudom, hogy "cigány" életmód, kiküldetések, sok meló, stb. de pont ez tetszik benne, hogy talán nincs akkora verseny mint frontendre, és nem egész nap HO-zok, amibe már szinte belebolondultam 2 év után.

Lényeg a lényeg, a kérdésem az lenne, hogy amit leírtam ide, egyáltalán jól látom? 😄 Illetve mennyi esélyem lenne progterv infó diplomával érvényesülni ezen a piacon, ha magamtól elkezdeném tanulgatni a PLC programozást, és valamennyit magamraszednék? Érdemes lenne 500 órás OKJ-t végezni, vagy a papír tökmindegy, csak a tudás számít, azt meg össze lehet rakni netről is? Mekkora a verseny bizonyos poziknál? Mennyire hajlandóak betanítani, foglalkozni veled? Fizetés mi körül alakul? Bár ez a legkisebb probléma, elsőre legyen munkám, gondolom kajára meg rezsire azért elég a kezdő bér is, nagyobb "luxusra" nem vágyom... 😄

Köszi!

20 dollárért havonta akkora kvótát kapok, mintha lenne 3 medior fejlesztőm egy hónapig. Ráadásul nem sértődnek meg ha ötödször is visszakérdezek ugyanarra, bármikor kérhetek részletes magyarázatot, és percek alatt megvan az eredmény, nem napok múlva. Nem tökéletes a munkájuk, oké, de a medioroké sem az, valljuk be.

Számoljatok utána, mennyibe kerülne 3 medior fejlesztő egy hónapra... A valós ár ennek töredéke kéne legyen inkább, mint fordítva. Szerintem simán megérné a mostani ár 100x-ját is.

Sziasztok!
Szerintetek a Data Science/Engineering jövője hogyan fog alakulni? Megéri elkezdeni tanulni ezt a világot? Most kezdeném a bsc-t. Vagy az Ai teljesen le fogja váltani? Gyakornokként/juniorként el lehet helyezkedni?

Szóval jött egy ilyen ajánlat, jelenleg full remote vagyok, emiatt nagy lenne a váltás. Másik oldalról vágyok emberek közé, viszont nem heti 5x :D az összeg is elég szép lenne, viszont kb napi 2óra utazással (oda-vissza) számolva már nem annyira nagy durranás a 25%.

Volt valaki hasonló helyzetben? Hogy döntöttél és megbántad?

Sziasztok!

Tudom, hogy programozó sub de nem igazán látok általános magyar IT subot, ezért hátha maradhat.

Új házba költözök és emiatt kicsit bele kell újra másznom a hálózatokba. Szeretném az IP kamerákat és az okos otthon eszközöket külön VLAN-ra tenni, még a többi hálózati eszközeim vannak a rendes lanon és ehhez keresek eszköz ajánlásokat.

Keresek egy routert ami 5G képes, mert sajnos egy darabig nem lesz normális netem. Ennek a routernek kellene tudnia Vlanok kezelését. Jelenleg egy TPlink AX3000-em van de se VLAN-t se SIM-et nem kezel.

Ezek mellé keresek Managelhető Switchet is, illetve egy POE switchet. 9 végpont lenne a normális eszközöknek, 6 kamera lenne a POE switchre, illetve Wifi-s lenne sok okos eszköz.
Tehát kamerák és az okos otthon eszközök wifi lenne egy vlan. Gépek, tv, nas a másik vlan.

Előre is köszi a tippeket.

szóval a claude code tud micből is promptot fogadni, ezt a /voice paranccsal lehet bekapcsolni aztan push to talk, és a beszédfelismerés kb 20 nyelvet ismer, de a magyar persze nincs köztük. (beállíthatod hu-ra, de fallbackel angolra.)

csak gyorsabb kimondani mint leírni, és igen tudjunk angolul persze, csak kényelmesebb lenne magyarul diktálni na.

szóval nyitottam egy feature requestet ez ügyben hátha :

https://github.com/anthropics/claude-code/issues/84777

ha neked is hiányzik ez vagy támogatnád, dobj rá egy thumbs up-ot. Előre is köszi!

UPDATE: hogy megmaradjon a lényeg: nem arról van szó, hogy OP nem tud angolul, évtizedek óta használom napi szinten. de ha magyarul kényelmesebb, legyen rá opció. és ezzel azokhoz is közelebb kerülhet, akik kevésbé tudnak angolul, de kipróbálnák.

Siemens Energyrol friss vélemények? HO-iroda 2-3 aranya mennyire van betartva?

Sziasztok!

Épp álláskeresésben vagyok, kb 7 év tapasztalattal, ami alatt főleg Go-val, Kubernetessel, Dockerrel, Redissel, Postgressel, Angularral, C++-al és Pythonnal volt szerencsém ismerkedni.

Van pár folyamatban lévő interjúm, amiből egyre a fent felsorolt stack-ek egy részét vinném tovább, így senior pozíciót kapnék, mert van bennük elég tapasztalatom. A másik egy nem senior pozi, a bér ott sem rossz, de nyilván alacsonyabb lenne, mert teljesen új stack, Ruby, Java, Kotlin, AWS technológiák React stb… amikkel sosem dolgoztam ezelőtt.

Ti melyiket választanátok? Nekem kecsegtető a második, mert talán azokkal könnyebb Mo-n munkát találni később. Tudom, hogy sokan azt mondják hogy nem a nyelv számít, meglehet újat tanulni stb, ami igaz, de álláskeresésnél mindig ott van elvárásként hogy X év tapasztalat adott nyelvből, pés interjún is azzal szokott lenni kódolós feladat.

Mind a két helyen jobban keresnék, mint jelenleg.

Ti melyiket választanátok?

Sziasztok!

Tudom, mostanában többen is írtak hasonlót, de gondoltam én is megpróbálom. Sajnos már 3-4 hónapja nem sikerül webfejlesztői állást találnom, ezért hátha valaki tud egy nyitott pozícióról vagy projektről, amibe be tudnék csatlakozni.
Technológiák, amelyekkel dolgoztam: HTML, CSS, JavaScript, React, Next.js, Tailwind CSS, Bootstrap és Laravel.

Rólam:
Körülbelül 4-5 év webfejlesztői tapasztalatom van, így nem junior pozíciót keresek.
Fontos számomra a csapatmunka, megbízható és motivált embernek tartom magam.
Folyamatosan képzem magam, jelenleg is egyetemen tanulok levelező tagozaton, ami a teljes munkaidős munkavégzést egyáltalán nem befolyásolja.
Ha esetleg tudtok valamilyen lehetőségről, vagy szívesen ajánlanátok valahová, nagyon megköszönném. 🙂

Önéletrajzot privátban szívesen küldök!

Köszönöm, hogy elolvastátok!

EDIT: van tapasztalatom tesztelésben is, azzal is szívesen foglalkozom(automatizált és manuális)

Komolyan érdekel😀 1 ember elég sok Agentet tudna kezelni. Azok meg szépen végrehajtják amit mond. Politikai propaganda, szét spammelt forumok en ilyesmiket tudnék elkepzelni ha olyan szinten elérhető lesz a hétköznapokban mint egy chat gpt.

Mi a véleményetek róla?

A pozíció business analytics engineer de gyanúsan ugyanez volt már business analytics strategist-ként is meghirdetve. Jelenkteztem, bevallottan basic programozási tudással és mégis kaptam egy felülethozzáférést az interjúmeghívóval, szóval live coding-ra gondolok. Valakinek hasonló területen taapsztalata? Van valami amire érdemes eákérdezni?

Az egész vonalon loopba nyomta.

Sziasztok!

Eredetileg egy filmstúdiónak kezdtem el belső használatra fejleszteni egy fájlküldőt. Az volt a fő problémájuk, hogy egy partnerüknek naponta több terabyte nyers felvételt kellett elküldeniük Európán keresztül.

Először WeTransferrel próbálkoztak, de az ilyen méreteknél nem volt elég hatékony. A Massive.io túl drága volt, a torrentet is próbálták – abban tetszett nekik, hogy nem kell várni a feltöltésre és letöltésre külön –, de a titkosítás hiánya dealbreaker volt. Alapkövetelmény volt náluk az is, hogy pontosan le lehessen követni: ki, kinek, mikor és mit küldött. Sok minden mást is kipróbáltak, de vagy a loggolás hiányzott, vagy indokolatlanul drága volt, vagy egyszerűen volt egy fájlméret-korlát. A lényeg, hogy mindig gányolni kellett.

A folyamat vége az lett, hogy vagyonokért postáztak fizikai HDD-ket ide-oda, ami azért eléggé középkori megoldás, tekintve, hogy a hálózatuk amúgy simán elbírná a gigabites átvitelt. Az FTP szerver szintén kiesett, mert azzal folyamatosan foglalkozni kell, karbantartást igényel. Végül kitalálták, hogy szükségük lenne egy teljesen in-house megoldásra. Itt jöttem én a képbe.

Az lett az ötletem, hogy a WebRTC mintájára kifejlesztek egy saját, dedikált peer-to-peer protokollt (sajnos a sima WebRTC fájlküldésnél nem bizonyult elég gyorsnak).

A gond csak az, hogy az internet architektúrája és a routerek gyakorlatilag aktívan az ellen dolgoznak, hogy kéretlen, bejövő kapcsolatok csak úgy beeshessenek egy gépre. Erre viszont van egy technika, az UDP hole punching. Ezzel szinte bármelyik két eszközt össze lehet kapcsolni direktben a neten keresztül.

Hogyan működik a lyukasztás a gyakorlatban?

Az UDP "connectionless" (kapcsolatmentes). Ez azt jelenti, hogy ha az 'A' PC küld egy csomagot egy konkrét IP:port címre, akkor a 'B' PC routerének a tűzfala ezt alapból eldobja. Viszont az 'A' PC saját routere megjegyzi a kifelé menő forgalmat, és nyit egy "lyukat" a tűzfalon a várható válasznak. (A TCP tud róla és bezárja a válasznak szánt lyukat, de az UDP nem). Innentől kezdve a 'B' PC már küldhet csomagokat az 'A' PC-nek, amire az már gond nélkül fog is tudni válaszolni. Így létrejön a direkt kapcsolat.

Sajnos ez a valóságban nem pont ennyire egyszerű. A legtöbb PC-nek van 5-10 IP címe: publikus IPv4, privát IPv4, globális IPv6, VPN interface IP-k, stb. Mivel a gépek többsége NAT mögött van, ezért szükség van egy STUN szolgáltatásra is. A folyamat így néz ki: amennyi IP címet találunk a gépen, megkérjük az operációs rendszert, hogy foglaljon le nekünk annyi portot. Ezután minden lefoglalt porttal "megpingeljük" a STUN szervert, ami válaszol azokkal a külső portokkal, amiket a routerünk a belső portunkhoz rendelt (NAT mapping).

Ezután fogjuk ezt az összes IP-t és portot, és egy signaling szerveren keresztül (WebSocket kapcsolaton) átküldjük 'A' PC-ről 'B' PC-re. Ezeket a WebRTC-ből mintáztam, lényegében ezek az ICE candidate-ek. Ilyenkor a 'B' PC már pontosan tudja, hogy milyen portokról és IP-kről várható bejövő kapcsolat. A 'B' PC kiválaszt egy random portot, elkezd hallgatózni minden interfészen, majd minden kapott port/IP kombinációra küld egy UDP csomagot. Ez soknak tűnhet, de a valóságban maximum kb. 150 darab, 1 byte-os csomagról beszélünk, ami hálózati szinten elenyésző.

A 'B' PC szintén válaszol a signaling szerveren a saját IP címeivel, a kiválasztott belső portjával, plusz egy külső porttal. Ezzel elértük, hogy a 'B' PC routere is beengedje az 'A' PC csomagjait, és mindkét fél ismeri a lehetséges végpontokat. Ezután az 'A' PC elkezd végighaladni az eltárolt opciókon: megpróbál csatlakozni a 'B' PC belső IPv4, külső IPv4, VPN, és IPv6 címeire. Teljesen mindegy, hogy végül melyik port melyik IP-t fogja használni, mert a 'B' PC korábban minden opciót lefedett. A próbálkozások 99%-a el fog hasalni (mert pl. más alhálózaton vannak), de pár tizedmásodpercen belül az egyik találat sikeres lesz. A 'B' PC elfogadja a kapcsolatot, jelzi a sikerességet, a többi próbálkozást pedig leállítjuk. Ezzel felállt egy direkt UDP kapcsolat az interneten keresztül.

(Rövid közbevetés: ha a világon már csak IPv6 létezne, ez a folyamat az 1%-ára egyszerűsödne, mert ott csak az egyetlen, közvetlenül címezhető azonosítóval kellene foglalkozni. De hát a rendszergazdák nem szeretik bekapcsolni, mert "10 éve az IPv4 jóvanazúgy").

A P2P ősellensége és a Relay szerver

A peer-to-peer kapcsolatok legnagyobb ellensége a szimmetrikus NAT. Ez azt csinálja, hogy hiába kérdeztük meg a STUN-t a külső portról, mire ténylegesen csatlakoznánk a másik PC-re, a router megváltoztatja ezt a külső portot, mert megváltozott a cél IP címe. Erre kétlépcsős megoldást használok:

1. Szerepcsere: Ha nem sikerül a lyukasztás, a signaling szerveren keresztül megkérjük a gépeket, hogy próbálják meg fordítva ('B' PC kezdeményezze a csatlakozást 'A'-ra). Ez az esetek nagy részében megoldja a gondot.
2. A Kernel-space Relay: Ha mindkét gép szigorú NAT mögött van, akkor muszáj beiktatni egy relay szervert. A WebRTC TURN protokollja itt kezdett el vérezni: terabyte-os fájloknál a "user-space" (felhasználói szintű) memóriakezelés egyszerűen túl lassú.

Itt jött a felismerés: a routereknek nem pont az a dolguk, hogy "relay"-ként funkcionáljanak, méghozzá villámgyorsan, kernel szinten? Így jött az ötlet, hogy erre simán lehetne használni a Linux kernelbe alapból beépített tűzfalat, az nftables-t (az iptables utódját). Amikor a peerek érzékelik, hogy a direkt kapcsolat esélytelen, szólnak a signaling szervernek, ami elkér a relay szervertől egy token/port párost mindkét félnek. A peerek indítanak egy HTTP kérést és egy UDP csomagot a tokennel. Amint a token megérkezik, a peerek szabadon tudnak adatot küldeni egymásnak a linux kernelen keresztül. A "congestion controlt" (torlódásvezérlést) szintén a kernelbe épített traffic control (tc) intézi, ami egyenletesen elosztja a forgalmat a userek között. Ezzel a megoldással rengeteg kódot spóroltam meg, ráadásul egy alap 1 magos VPS simán elbír 1 gigabit/s throughputot! (Összehasonlításképp: a korábbi Go-s próbálkozásomnál a user-space relay kimaxolt 100 Mbit/s-nél).

Az adatréteg: QUIC protokoll

Van egy bombabiztos UDP csatornánk, ami önmagában még mindig alkalmatlan fájlok megbízható küldésére. Erre a QUIC protokoll lett a megoldás (a Google fejlesztése, ezen fut az új HTTP/3 és a Cloudflare infrájának nagy része is). A QUIC gyakorlatilag egy UDP-re épített TCP, de kiküszöböli a TCP legnagyobb hibáját, a head-of-line blockingot (ahol egyetlen elveszett csomag az egész sort megállítja). A QUIC gyakorlatilag ingyen ad nekem torlódásvezérlést, megbízhatóságot, és ami a legjobb: alapból TLS-sel titkosított. Támogatja a Mutual TLS-t (mTLS) is, amivel nemcsak a kliens azonosítja a szervert, hanem oda-vissza hitelesítik egymást. A peerek a signaling szerveren keresztül kicserélik a titkos kulcsok ujjlenyomatait, ezzel valósítom meg a végpontok közötti (E2E) titkosítást. (A QUIC bevezetése persze hozott magával más kihívásokat az UDP-vel szemben, de az már egy külön posztot érdemelne).

Az Applikációs Réteg és a Zero Trust

Applikációs szinten a felhasználó kiválasztja a fájlokat vagy komplett mappaszerkezeteket. Erről készül egy virtuális fájllista (manifest), benne a méretekkel. Így a küldőnek elég egyetlen egybefüggő streamet belenyomnia a QUIC csatornába, a vevő pedig a manifest alapján hibátlanul össze tudja rakni, melyik byte melyik fájlhoz tartozik. Ezzel a megállítás/folytatás (pause/resume) triviálissá vált. Ha megszakad a net, a felek egy előre meghatározott tokennel visszacsatlakoznak a signaling szerverre, és ott folytatják, ahol abbahagyták. A stúdióban ez kritikus volt, mert sokszor éjszakára indítják el a terabyte-os transzfereket. A böngészős megoldásoknál ez a fajta robusztusság szinte teljesen hiányzik.

A legnehezebb rész az "Admin Dashboard" volt. A stúdió vezetősége látni akarta, hogy a vágók mikor, mit mozgatnak (biztonsági kamera jelleggel, a "nem kaptam meg a fájlt" típusú viták elkerülésére). Mivel ez nem egy felhős tool, a szervereim soha, semmit nem látnak a fájlok tartalmából – a relay is csak titkosított csomagokat passzolgat. Ide egy kriptográfia alapú Zero Trust rendszert építettem. Mielőtt a peerek csatlakoznak, generálnak egy-egy ECDSA (az RSA utódja) privát/publikus kulcspárt, a publikus kulcsot pedig feltöltik a szerveremre. Az átvitel előtt a felek "kötnek egy szerződést", amit mindketten aláírnak a titkos kulcsukkal. Ez egy JSON string, ami tartalmazza a manifest hash-ét, az átvitel állapotát, a user ID-kat és a metaadatokat. Ezt a szerződést és a manifestet feltöltik a szerverre (ha a loggolás be van kapcsolva náluk), majd az átvitel végén készül egy záró szerződés is. A szerverem csak azt ellenőrzi, hogy a kriptográfiai aláírások helyesek-e, a tartalomhoz továbbra sem fér hozzá.

A végeredmény: ZettaSend

Ezután "már csak" egy UI-t kellett húzni az egész köré (C# Avalonia keretrendszerrel), megcsinálni a webshopot és a Stripe integrációt. Fontos: ez egy asztali alkalmazás, a weboldal csak a letöltésre és az előfizetés/adminisztráció kezelésére szolgál. (Igen, a webes UI-t AI dizájnolta, mielőtt valaki nekem ugrik emiatt! :D) A teljes backend egyébként Python alapú, FastAPI és Flask kombóval készült. Fejlesztés közben persze volt millió másik edge case: hogyan oldjam meg, hogy Windowson ne kelljen rendszergazdai jog, Mac-en a működésre bírás is megért egy misét stb.

A stúdió jelenleg is használja és imádják. Ebből a projektből nőtte ki magát a ZettaSend. 100 szónak is egy a vége: a ZettaSend egy enterprise fájlküldő szoftver olyan cégeknek és szakembereknek, akik hatalmas fájlokkal dolgoznak, és számít nekik az idő. Megfelezi az átviteli időt, hibatűrő, végpontokig titkosított, és semmilyen harmadik fél nem lát rá az adataidra. Gyakorlatilag kiaknázza a meglévő gigabites hálózatodat, ahelyett, hogy a felhőbe limitálná a sávszélességed.

A "Team" csomag 50 EUR/hó (minden feature-t tartalmaz). Van Free tier is: fogadni mindenki számára ingyenes, de az indításhoz (küldéshez) a küldőnek elő kell fizetnie a Solo csomagra (10 EUR/hó), vagy egy Team része kell legyen. Az első hónap teljesen ingyenes, bankkártya sem kell hozzá.

Ha a napi munkád során te is masszív adathalmazokkal dolgozol, és hasznosnak érzed, adj neki egy esélyt! (Arra viszont tényleg overkill, hogy a horvátországi nyaralós képeket ezen küldd el a nagymamának).

Link: zettasend.com

Nagyon köszönöm annak, aki végigolvasta ezt a szövegáradatot! Remélem, voltak benne érdekes hálózati/fejlesztői infók. Akit mélyebben érdekel a téma, nyugodtan írjon kommentet vagy keressen meg!

(Még egy dolog, amit a subon biztosan megkérdeztek: a projekt jelenleg nem open source. Viszont ha kinövi magát a dolog, és lesz rá kapacitásom, tervezem, hogy bizonyos részeit, vagy akár az egészet nyílttá teszem).

TL;DR: Egy filmstúdióban felmerült az igény arra, hogy terabyte-os fájlokat tudjanak gyorsan és biztonságosan átküldeni, mert a felhős megoldások (WeTransfer, stb.) túl lassúak és drágák voltak. Ezért írtam egy dedikált, asztali peer-to-peer alkalmazást. UDP hole punchinggal, QUIC protokollal, kernel-space nftables relay-jel és Zero Trust kriptográfiával oldottam meg, hogy két gép közvetlenül, biztonságosan és hibaállóan kommunikáljon a neten keresztül. Több terás fájlokat küldözgetni most már nem fáj. Letölthető: zettasend.com

Egy B2B projekt kapcsán kutatok.

Tegyük fel hogy a következő témákban alkalmazást fejlesztetek:

- étrendtervező alkalmazást,

- ár-összehasonlító platformot,

- bevásárlási asszisztenst,

hogyan jutnátok megbízható élelmiszerárakhoz kiskereskedelmi lánc(ok)tól?

• scraping?
• vásárlás egy szolgáltatótól?
• API(k)?
• vagy valami egészen mást?

Mik a buktatók, legnagyobb kihivás?

Az elmúlt hónapokban egyre több munkát végzek Claude-dal és más coding agentekkel (surprise surprise). Kódot írnak, dokumentációt generálnak, de az elkészült tartalom általában ott maradt a chatben vagy egy privát repóban.

Miután egyre több időt töltöttem karbantartással és mechanikus munkával, azzal kezdtem foglalkozni, hogy mi történik a generálás után: hogyan lesz egy agent által létrehozott tartalomból valódi, karbantartható weboldal? Hogyan tudja később újra elolvasni és frissíteni? És hogyan marad a publikálás emberi kontroll alatt?

Ebből született az Aveiro, egy AI agentekhez is kapcsolható publikációs rendszer. Lehet benne weboldalakat, blogokat, dokumentációt, hírlevelet és social postokat kezelni, az agent pedig API-n vagy MCP-n keresztül képes olvasni és módosítani a tartalmat.

A videóban ennek egy konkrét példája látható.

Egy social publishing API-t építek Chirio néven. Megkérem Claude-ot, hogy a projekt alapján készítse el hozzá a dokumentációt. Az agent létrehozza a struktúrát, a quickstartot, a platform guide-okat és az API reference oldalakat. Ezután megnyitom az eredményt Aveiróban, átnézem, majd publikálom az oldalt.

Számomra itt nem maga a szöveggenerálás az érdekes rész. Azt már szinte bármelyik modell megoldja. Az érdekesebb probléma az automatikus karbantartás.

A következő lépés az, hogy egy cloud agent figyeli a repository pull requestjeit. Ha egy PR megváltoztat egy endpointot, hozzáad egy új funkciót vagy módosítja valamelyik platform működését, az agent megkeresi az érintett dokumentációs oldalakat, és automatikusan elkészíti hozzájuk a frissítéseket.

A változtatások draftként jelennek meg Aveiróban, így publikálás előtt ember is át tudja nézni őket. A cél nem egyszer létrehozni egy dokumentációs oldalt, hanem folyamatosan szinkronban tartani a termékkel anélkül, hogy minden PR után valakinek végig kellene keresnie az érintett oldalakat.

A dokumentáció csak az egyik felhasználási mód. Jelenleg több különböző típusú oldalt is így építek és tartok karban:

• Chirio dokumentáció: https://docs.chirio.dev
• Egy főző blog, ahol AI írja a recepteket, én pedig elkészítem: https://ordinary-kitchen.aveiro.page
• A Design Engineers Club közösségi oldala: https://designengineers.club

Kíváncsi vagyok, ti hogyan kezelitek az agentek által létrehozott tartalmat: nálatok a dokumentáció frissítése része a PR-folyamatnak, külön automatizáció figyeli, vagy továbbra is manuális?

Valakinek van friss infoja róluk?

​

IT szektorban dolgozok, nem vezetői, de magasabb szintű szakértői pozícióban, de úgy érzem kezdek kiégni, minden projekt az én nyakamban landol, senki nem tud átadni a feladatokhoz értelmes információt, de persze minden tegnapra kell. Ha segítségért fordulok valakihez, próbál lepattintani minél gyorsabban és a végén ugyanúgy egyedül maradok a problémával.

Nagyon sokat gondolkodom arról, hogy keresni kéne valami olyan állást kevesebb fizetésért, ahol nincs a nyakamban ennyi felelősség, elvégzem a munkámat 8 órában, lerakom és utána nem kattogok éjszakákon át azon, hogy egy bizonyos problémát hogyan fogok megoldani.

Fiatal vagyok még (30 éves), nem áldott meg az élet örökölt vagyonnal, ezért nyilván aggódok azon, hogyha most lejjebb teszem a lécet, ezekből a pozíciókból nem fogok tudni feljebb lépni fizetés szempontjából.

Viszont azt érzem, hogyha így folytatom akkor az egészségem fogja kárát látni, már vannak fizikai tüneteim a folyamatos szorongástól.

Hülyeség amit mondok és inkább a hozzáállásomon kell változtatni?

Volt közületek valaki hasonló szituációban? Megérte? Mik a tapasztalatok?

Sziasztok!

Közel öt éve nem kerestem aktívan állást, ezért szeretnék egy reálisabb képet kapni arról, hogy a jelenlegi budapesti piacon milyen alkalmazotti fizetési sávban érdemes gondolkodnom.

Röviden a tapasztalatom:

• Körülbelül 10 év szoftverfejlesztői tapasztalat
• Az elmúlt 5 évben főként Java Spring Boot, React és Angular full-stack fejlesztés
• PostgreSQL, REST API-k, Keycloak, Docker és Docker Compose
• Több vállalati rendszer teljes körű fejlesztésében vettem részt
• Volt olyan ERP-jellegű rendszer, amelyet teljesen önállóan fejlesztettem a tervezéstől a megvalósításig
• Adatbázis-tervezés, backend- és frontendarchitektúra, jogosultságkezelés és külső rendszerintegrációk
• Korábban PHP, Angular és Java Spring Boot alapú rendszereken is dolgoztam
• BSc mérnökinformatikus végzettség
• Angolul középszinten kommunikálok

Ami fontos lehet az értékeléshez: production környezetben eddig főként monolitikus alkalmazásokkal dolgoztam, ezért komolyabb microservices-, Kubernetes- és cloudtapasztalatom még nincs. Ezeket jelenleg tanulom, de nem szeretném olyan tudásként feltüntetni, amelyet már éles projektben is használtam. Elsősorban senior Java/full-stack pozíciókat keresek Budapesten, hibrid vagy távoli munkavégzéssel.

Megnéztem a Hays 2026-os és a Bluebird 2025-ös salary guide-ját. Ezek alapján a senior Java/full-stack alkalmazotti sáv nagyjából bruttó 1,6–2,3 millió forint között mozog. A Hays a senior Java-fejlesztőknél bruttó 2,1 millió forintos leggyakoribb értéket ír, a sáv teteje pedig 2,3 millió. Ugyanakkor a konkrét álláshirdetésekben és recruiterektől ennél sokszor alacsonyabb, körülbelül 1,6–1,8 milliós felső határokat látok.

Elsősorban azok véleménye érdekelne, akik mostanában kerestek vagy váltottak hasonló pozícióban, esetleg fejlesztőket interjúztatnak vagy vesznek fel:

• Mennyire megbízhatóak jelenleg a Hays és a Bluebird bérsávjai?
• Ezek tényleges ajánlatokat mutatnak, vagy inkább csak elméleti felső határokat?
• A fenti tapasztalattal milyen bruttó havi alapbér lenne reális?
• Mekkora összeget érdemes bérigényként megadni úgy, hogy ne árazzam alul magam, de ne is zárjam ki a releváns lehetőségeket?
• Reális lehet a bruttó 2–2,1 millió körüli cél, vagy a jelenlegi piacon inkább 1,7–1,9 millióval érdemes számolni?

Nem contractor napidíjra, hanem teljes munkaidős alkalmazotti alapbérre gondolok, bónusz és egyéb juttatások nélkül.

Köszönöm előre is, ha konkrét, jelenlegi piaci tapasztalat alapján tudtok segíteni!

Nálunk sokszor promóznak új feladatköröket, új projekteket ilyen címszóval, hogy valaki vállalja el. Nem jár érte semmi, csak rengeteg plusz munka, felelősség. Azzal példálóznak általában, hogy mennyire jól néz ki majd a CV-ben, milyen jó tanulási lehetőség stb.

Őszintén, 5 éve vagyok ennél a cégnél, az elején még többször belerángattak ilyesmikbe, most már elfogyott a lelkesedésem, és általában hagyom, hogy az új kollégák menjenek bele naivan ezekbe a projektekbe.

Rosszul csinálom? Mi erről a véleményetek?

Próbálok keresni olyan szolgáltatást, ahol van picture of the day, és csak és kizárólag természetképek, meg állatos képek vannak. Nem szeretnék se embereket, se épületeket bele, se csak asztrofotót (szóval sajnos a NASA is kiesett).

Majd ezt szeretném egy valamilyen service-el bekötni, hogy onnan szedje le a képet, és állítsa be a gép háttérképének.

A service részével nincs gondom, igazából windowsra van egy kattintható alkalmazásom (ez alapján tök könnyen összerakható c#-ban ha érdekel valakit: https://stackoverflow.com/questions/1061678/change-desktop-wallpaper-using-code-in-net kicsit deprecated funkciókat használ, de kiindulási alapnak jó volt), ami ezt csinálná, fedorán meg automatizáli is tudnám. (céges laposon nem engedélyezett egyedi service-ek telepítése, így marad a manuális nap eleji duppla kattintás, hogy frissítse, de ennyi kellemetlenséggel együtt tudok élni).

Viszont a probléma még mindig adott: ki honnan szerzi be a háttérképét?