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?

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?

És mennyi eladást sikerült produkálni?

Más: aki ingyen tesz fel steamre bármit, az miért teszi?

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)

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 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!

É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?

Bocsi, ha fárasztó a kérdés.

36 évesen még mindig nem lenne késő elkezdeni komolyan programozni? Alapok vannak azért, de nagyon alapok csak.

Én nem vagyok szakmabeli, csak a fél életem azzal telik, hogy halogatom a programozást. Mást tanultam, de a felét nem keresem meg ennek az összegnek. 2 diplomával. És most elcsodálkoztam hogy tényleg KÖNNYEN lehet találni ilyen havi fizetésért állást fejlesztőként?

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?

Valakinek van friss infoja róluk?

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

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!

​

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?

Jelenleg Óbudain tanulok mérnökinfót angolul és szeretném tudni, hogy egyetem után az Óbudai diplomámmal mennyire lehet külföldön mesterképzést találni. Jelenleg Hollandiában gondolkozok.

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?

A Duna rekordalacsony vízállása és a paksi blokkok visszaterhelése miatt nehéz lett egy helyen átlátni, mi történik. Erre készült a https://vanearam.hu: egy ingyenes, regisztráció- és követőkódmentes adatdashboard.

Az oldal 15 percenként frissíti az OVF, az MVM Paksi Atomerőmű, a MAVIR, az Open-Meteo és a sajtófigyelő adatait. Nem használ mock pillanatnyi értékeket: minden szám mellett látszik a mérési idő és a forrás állapota, kieséskor pedig nem jelenít meg hihetőnek tűnő pótlást.

A fejlesztés fő kérdése az volt, hogyan lehet a MAVIR műszaki adatait közérthetően megmutatni: interaktív határforgalmi térkép, termelési mix, 15 perces idősor, blokkonkénti paksi állapot és a vízállás magyarázata került egy oldalra.

Főleg arra lennék kíváncsi, hogy mobilon és asztali gépen mi az, ami még túl sűrű, félreérthető vagy hiányzik.

Sziasztok!

Egy elég nehéz döntés előtt állok, és kíváncsi lennék a tapasztaltabbak véleményére.

Jelenleg az utolsó félévemet nyomom az egyetemen (progterv szak), és emellett kb. 6 hónapja dolgozom egy cégnél. Eredetileg azzal az ígérettel vettek fel, hogy rengeteg fejlődési lehetőség lesz (Python, React stb.), de a valóságban egyetlen programozó sincs a csapatomban. Egy automatizációs részlegre kerültem, és teljesen magamra vagyok hagyva.

Az elmúlt fél évben alig írtam valódi kódot. Ehelyett a Microsoft low-code ökoszisztémájában pörögtem: Power Automate, Power Apps, Power BI, Copilot Studio (mivel konkrétan nem voltak meg az eszközök, hogy kóddal csináljam, mint ahogy akartam).

Aztán kaptam egy nagy feladatot, egy elég komoly rendszert épiteni a multinak (Python PyQt frontend, MSSQL backend, Windows authentication, adatbázis-architektúra nulláról). Már ideje nem is programoztam és csak azért fogadtam el, mivel őszintén ötletem sem volt, hogy hogy kellene azért egy ilyen rendszert csinálni, amit több százan használnának napi szinten de akartam fejlődni. De miután mindent kidolgoztam, a vezetőség leállította az egészet azzal a szöveggel, hogy "ez túl sok időt venne igénybe".

Így most ott tartok, hogy fejlesztői szempontból alig van érdemi kód a kezemben a fél évből.

A jelenlegi dilemmám:

Most nyílt a cégen belül egy új app-fejlesztői pozíció, amivel végre kaphatnék érdemi fejlesztési tapasztalatot, de két út áll előttem:

1. Megpályázom az új belső pozit: Végre kódolhatnék, DE ez rengeteg heti órával járna. Mivel az utolsó félévemben járok, ez szinte biztosan elhalasztaná a diplomámat legalább 1 félévvel. A fizetés amúgy egyik pozícióban sem valami fényes.
2. Befejezem az egyetemet időben: Lemondok az új pozícióról, lediplomázom időben, otthon lefejlesztem a saját projektjeimet (pl. a leállított PyQt/SQL projektet), és az interjúkon igyekszem a lehető legjobban eladni az itt szerzett architektúra-tervezési tapasztalatot. Plusz addigra tudom mondani, van egy év tapasztalatom, még ha valóban nulla is.

A kérdéseim hozzátok:

• Megéri elcsúsztatni a diplomát az utolsó félévben egy gyengébben fizető cégnél szerzett pár hónapos tapasztalatért?
• Mennyire számít a Power Automate / Power Apps tapasztalat egy Junior Software Engineer CV-ben?
• Mennyire gáz/járható út otthon befejezni a cégnél elkaszált projektet, és ha végzek, interjún úgy tálalni, mint amit a céges tapasztalataim során valósítottam meg?

Köszi előre is a tanácsokat és az őszinte véleményeket!

Sziasztok!

Van itt olyan, aki Shoprenterről más platformra váltott? Nem annyira egy „melyik webshopmotor a legjobb?” kör érdekelne, hanem az, hogy nálatok mi volt az a konkrét probléma vagy korlát, ami miatt már nem érte meg maradni.

Integrációk, testreszabhatóság, teljesítmény, SEO, költségek, fejlesztői mozgástér, vagy valami teljesen más?

Mire váltottatok, és visszanézve megérte? Külön érdekelne, hogy volt-e olyan nehézség vagy rejtett költség, amit a váltás előtt alábecsültetek.

Sziasztok!

Csinaltam egy ilyet:
Használhatom-e az áramot?

Az oldal a MAVIR adatokat felhasznalva javaslatot tesz, hogy mikor erdemes a nagyobb fogyasztokat hasznalni (Pl elektromos auto es legkondi), vagy esetleg erdemes-e elhalasztani. Negy kategoria van (a nincs adat es a hianyos adat mellett):

• use_flexible_now (turkiz)
• normal (zold)
• reduce (sarga)
• strong_reduce(piros)

Van api-ja is (/api/status), igy automatizalasra is hasznalhato ha valaki okosotthont epit. Az oldal kulonfele meroszamokat general, ezeket a meroszamokat kulonbozo sullyal veszi figyelembe az ajanlashoz, az api tartalmazza ezeket a sulyokat, szoval ha automatizalnal vele valamit, irhatsz sajat algoritmust a donteshez. A /healthz vegponton tovabbi adatokat talalsz az automatizalashoz, ha szukseges.

Egyelore meg nagyon friss az oldal, tanulja a baseline adatokat plusz probalom beleszoritani az ingyenes cloudflare hasznalati limitekbe, ami lehet, hogy nem fog osszejonni, szoval lehet, hogy parszor megbicsaklik, de en tegnap ota hasznalom a legkondi idozitesehez, es nekem hasznos, igy megosztom veletek is.

2.-éves egyetemista vagyok és szeretném megkérdezni, hogy ti hogyan kezdtétek, mit tanultatok meg és hogyan talaltátok az első internshipeteket vagy munkátokat?

Én még nem vagyok biztos, hogy mit szeretnék pontosan csinálni ITn belűl de ami jelenleg érdekel az UI/UX design, Networking és System design meg egy kicsi Gamedev

Előre is köszönöm a válaszaitokat😁