Fórumok
2024-ben tenyleg irrealis elvaras olyan C# prgramozot (szenior) aki latott, hasznalt, netalan fejlesztett is linuxon c# programokat es nem riad meg a CLI-tol?
Esetleg ert docker-hez, multi stage build,stb?
Felre ne ertsetek, nem fogok most it poziciot reklamozni, ez inkabb csak reality check a reszemre, hogy a fenti az mennyire irrealis elvaras 2024-ben.
Hozzászólások
Tapasztalatom alapján a legtöbb fejlesztő számára a CLI szó tiltott. A környezetemben mindenhez is GUI kell nekik.
Docker sztem. reális elvárás lenne
A Build/CI-ban már megint el vannak kényeztetve a Dev(...)Ops pozíciókkal dolgozókkal.
Tanulság számomra, hogy a fejlesztők jelentős része (sok éves tapasztalat után) szakbarbár. Csak a programozás (jó esetben nem csak egy programnyelvre specializálódva) és semmi más, amit nem old meg a GUI az elből elutasítva.
El van nagy részük kényeztetve, és túl vannak fizetve.
Röviden: Valszeg nehéz ügy lesz. Tisztelet a kivételnek, csak azokat meg kell fizetni.
Elvárásnak nem irreális, de hogy fogsz-e találni, az más kérdés. :)
A másik oldal, hogy ha valóban szenior (és nem csak régóta csinálja :) ), és nyitott az új dolgokra, akkor hány nap alatt tanulja meg akár a Dockert, akár a Linux CLI-t, hiszen lássuk be, hogy egyik sem agysebészet.
Én pont ilyen vagyok (lásd usernév), 26 éve a gép előtt (talán senior). A fenti skillset a tudásom 25-30%-át teszi ki, nem nagyzolásból, hanem a tények miatt rakom ki ide.
A kérdésedre válaszolva: többen lehetünk így, lehet hogy csak ujjgyakorlat lenne (c# stack részleteit nem írtad). Két összetevő van, ami miatt nem találunk egymásra. Épp nem keresek állást, manapság inkább munkahely megőrzés van fókuszban. Emellett pedig nem biztos hogy c#-ban nyomulnék, amikor NodeJS "menőbb". Még lehet hogy többet is fizetnétek, de pont a senior-itás miatt már annyi idős vagyok, hogy nem a pénz számít, hanem a napi sikerek, a menőséb.
Akár privátban is kereshetsz.
A cegnel ahol dolgozok, a nagy 4 egyike felel kulsos programozoinkert, ok azok akik keptelenek megfelelo embereket talani nekuk.
Eloszor PHP-ra kerestunk embert (nem wordpress) aztan mivel a ceg nagyresze C# raalltunk arra, hogy meglevo par PHP projektet C# webapi-ra migraljuk, de egyszeruen nem kepesek olyan emereket talalni akik nem ilyednek meg a CLI-tol es tanulni is akarnak.
Pedig, pedig volt nekuk (magyar) kulsos fejlesztonk a PHP projekteken mielott att kellett alnunk a nagy 4 egyikere, vissza is sirjuk!
Support Slackware: https://paypal.me/volkerdi
Pedig szerintem php-ra sokkal hamarabb lehet ilyen embert talalni. Szuk kornyezetemben is talalok legalabb kettot, c# programozot pedig csak nagyon tavolit, de az is inkabb jatekfejlesztes vonalon
// Happy debugging, suckers
#define true (rand() > 10)
Hát, ez érdekes probléma... Én elboldogulok a cli toolokkal, de fejlesztőként a DevOps csak a szükséges velejárója a munkámnak, nem ez a főattrakció. Nem vagyok annyira jártas pl. egy docker cli-ben, hogy fejből tudjak mindent, emiatt nekem gyorsabb és kényelmesebb, ha gui-s tool-t használok.
Sok mindenre van jó gui tool, azokat kell megtalálni és használni, pl IntelliJ termékek elég sokmindent lefednek, amire szükségem van (git, docker, db console, stb).
A csapatomban volt egy srác, aki pl. parancssorból kezelte a git-et, mondván neki így kényelmes. Komolyabb merge conflict-ot nem is tudott feloldani, míg én IDEA-ból pillantok alatt megcsinálom. Volt jópár éve itt a hupon egy cikk, hogy Greg Kroah-Hartman hogyan varázsolja a linux kernel patcheket parancssorból, hát nekem ugyanaz a workflow sokkal gyorsabb a GUI-tool-al.
En ugyan igy vagyok ezzel van amit szivesebben csinalok GUI-n, tipikusan a git nekem is ilyen.
Most mar nekem eleg lenne az is ha docker-compose.yml file-t a hivalos referefencia alapjan el tudna inditani az ember, illetve be tudna allitani hozza enviromental variables-t, nem agysebeszet csak legyen hajlandosag google-t meg chatgpt-t hasznalni.
Amin kollegakkal kiakadtunk az az, hogy ssh/cd/ls/grep parancsokat sem ismertek sokan akiket senior pozira ajanlottak, mikor a munkakori leirasban alap linux ismeretek vannak kerve. Es basszus tenyleg alap cuccokat kertuk, be tudj lepni ssh-n tudj kiadni egy docker, docker-compose parancsot.
A kiakadas itt a senior-on meg azon van, hogy elvileg egy consultant ceg legyen mar olyan profi hogy vegez egy kis eloszurest, meg a szegeny joembernek is legyen mar annyi onkritikaja hogy nem jelentkezik egy olyan pozira amiben olyat kernek tole alapnak amit meg soha a budos eletbe nem csinalt es nem is latott.
Support Slackware: https://paypal.me/volkerdi
A C# még mindig "Windowsos" nyelv, nincs semmi csodálkozni való, hogy kevés a Linuxos. Linuxon ugyanarra a követelményre Javával lőnek.
Én C#-ozok is Linuxon, de teljes állásba tuti nem megyek soha sehova az biztos.
Pedig hup-os hatterrel mar boven senior lennel :D
(na, en sem tartom magam se senior-nak meg c# dev-nek se, de vakok kozt a felszemu a kiraly)
Support Slackware: https://paypal.me/volkerdi
Az csak természetes, hogy senior lennék :-)
Egyáltalán nem mozgok fejlesztés területen, ezért az itt olvasott alapján megdöbbent a szakadék a fejlesztés és pl. az általam ismert üzemeltetés között elvárásban, hozzáállásban. Úgy, hogy - tisztelet a kivételnek aki nem így gondolkodik - a progrmaozó az isten IT-ben, az üzemeltető meg majdnem a szakma alja a géptermi operátor felett egy hajszállal...
Itthon minden szakmai írás a programozót érti "informatikus" alatt (hibásan; ezt már megbeszéltük párszor), és itt mondjátok, hogy egy senior programozó a "szűk" programozáson kívül (ahol remélhetőleg nem csak egy nyelv-toolset a repertoárja) jellemzően nemhogy nem tud mást, de a legtöbben nem is hajlandóak megtanulni.
Üzemeltetésben meg úgy indul a junior pozíció kiírás általában (itt a HUP-on mindig megy is rá 50 hozzászólás, hogy persze, pláne minimálbér indulóért), hogy tudja supportálni a 30 éves MS-DOS programot az egyik végén, aztán fizikai szerver, virtuális szerver, Windows és Linux OS-ek, VMware, Hyper-V, Proxmox, ezek klaszterben, storage-ek többféle, azokon Linux konténer, Docker, összesféle alkalmazás és szolgáltatás telepítése, konfigurálása, MS SQL, Postgres, MySQL/MariaDB, nosql-ből legalább 2-3 féle, rendszer monitorozás, ITsec szervezléstől technikai részletekig, ITIL bejelentéskezelés, hálózati eszközök TP-Link szappantartótól Forti UTM-en át Cisco-ig minden, teljes körű felhős ismeretek Azure, AWS, esetleg GCP, tudjon gépet összerakni, bővíteni, javítani, tudjon hálózatot kábelezni-végszerelni-mérni, legyen jogsi ügyfélhez menni, persze akkor desktop meló is teljes körűen, mert az úgyis beesik, legyen terhelhető (7/24-ben hívhatjuk...), meg még ami nem jut eszembe... És akkor mit kérnek a medior-senior szinten... Ez nyilván túlzásnak hangzik, de nagyjából ilyen tartalommal jelennek meg üzemeltetős álláshirdetések itt (is), max egy része nem minimum feltétel, hanem ajánlott.
Na nem akarom itt azt mondani, hogy az egyik jobb vagy a másik, vagy, hogy az egyik többet ér, komolyabb terület mint a másik, mert ezek nem igazak. Ez a nagy egyész IT sok ágából kettő, és mindkettőhöz sok tanulás és sok alázat kell. De, hogy az egyik ágon ilyen "elnéző" az átlag mukaadó a másikon meg ennyire sokat elváró, az - mondjuk úgy - meglep. Ugyanis én azt hittem, hogy a programozók is tudnak-csinálnak manapság egy csomó dolgot a szigorúan vett program íráson felül, elvégre azért eléggé kiszélesedett az IT az utóbbi 20-30 évben (mióta benne vagyok), és gondolom megváltozott a programfejlesztés menete is.
Üzemeltetésben meg úgy indul a junior pozíció kiírás általában [...]
Van még néhány plusz és kötelező követelmény:
Szerintem asch mar megfejtette feljebb, es nagyjabol en is hasonloan vagyok vele. Roviden: tortenelmi oka van.
Ugye egy ideig (talan 1.1-1.3 kornyeke remlik) az MS a Java mellett volt, aztan kitalalta, hogy neki is kell ilyen, es megcsinalta a .Net-et a ra epulo nyelvekkel. Ott volt a nem tul hasznalhato Managed C++, a VB.net, meg a tobbe-kevesbe jol sikerult C# (ugy emlekszem, talan volt meg mellette 1-2 kisebb). Lapatoltak bele a feature-oket, a problema csak azzal volt, hogy naluk a platformfuggetlenseg - amit a Java amugy adott mar akkor is (Win, Linux, Solaris, Mac, meg kisebbek is le voltak fedve) - nagyjabol azt jelentette, hogy nem csak XP-n, de Vistan is megy. Aztan a Java eleg hamar potolta a hianyt, a C#-ba belelapatolt feature-ok ott is megjelentek, a Mono meg tovabbra is kinszenvedes volt az inkompatibilitasaval. Ja, a fordito is a Sun alatt ingyen elerheto volt, IDE is volt jopar, a VS ugy emlekszem fizetos volt. Mindenesetre a Java platformfuggetlenul hozta mindazt, amit a C# Winen.
Azota persze nincs Sun, a MS Ballmer utan elkezdett egyre jobban beallni a Linux moge, most mar nem lenne nagy akadaly. Viszont a Java is tudja nagyjabol azt, amit a C#. Biztos jo nyelv, de Linuxon/multiplatform kornyezetben szerintem nincs sok ertelme. A gepek meg egyre erosebbek lettek, es a legtobb scriptnyelv (JS/TS, Python, PHP) is hozza azt, amire szukseg van, csak van, ami kicsit kenyelmesebben.
Szoval ez a Linux+C# kombinacio kicsit olyan, mint a 40-es evekben a neger SS tiszt: kulon-kulon mindkettobol volt, csak a ket halmaz metszete viszonylag vekony. Aki C#-ot tanult, az valoszinuleg Windowsos kornyezetbol jon, ott erzi otthonosan magat, ott meg a CLI a Powershell elottig elegge mostoha volt, de utana sem lett annyira elterjedt, mint Linuxon. Aki Linuxon nott fel, az meg valoszinuleg elkonyvelte a C#-ot a "Windowsos hulyeseg" kategoriajaba - meg ha ez azota valtozott is - es volt mas erdekes tanulnivalo helyette (pl. a CLI-s eszkozok).
Egyebkent ti miert valasztottatok pont ezt?
A strange game. The only winning move is not to play. How about a nice game of chess?
Ennek tobb oka is van
Felreertesek elkerulese vegett, nem kell linuxon programozni.
Support Slackware: https://paypal.me/volkerdi
A Mono eredetileg a teljes kompatibilitást tűzte ki célul (AFAIK), és egész jól is sikerült, de a Windows Forms API-t nem implementálták. Sajnos volt még plusz néhány Windows API hívás, amit nem implementáltak, például az IPC szemafor API látszólag működik, de valójában nem (ha nem olvasod el a doksit, akkor hard way jössz rá...). Ezután az MS átvette a gyeplőt, és elkezdték rendbe tenni a káoszt: lett a Core API, ami mindenhol használható és lett ami nem. Ami nem kór, arra van amire warningot ad a fordító, runtime meg exceptiönt, hogy az bizony Linuxon nincsen.
Például a System.Draw API alapból nem része a core-nak. De van belőle Linux implementáció, csak valahogy alá kell lapátolni a programnak.
Szóval közepes nehézségekkel át lehet portolni egy meglévő C# alkalmazást Linuxra és teljesen jól fog teljesíteni. De nagyon észnél kell lenni. Új alkalmazás esetében viszont van értelme C#-ban gondolkodni, van valami új GUI lib is, ami multiplatform. Csak éppenséggel kevés fejlesztő van, ahogy OP is megállapította. És kevés előnye van a Javával szemben.
A .NET egyik előnye a Javával szemben az, hogy egy kicsit jobban optimalizált a VM-je, könnyebb erőforrásbarát programot írni. Úgy tudom, hogy a "billion row challenge"-ben a C# jobban teljesített egy picivel. Például C#-ban az elejétől kezdve is volt struct típus, ami képes arra, hogy tömör módon tároljunk adatokat tömbökben. Ez nagyon nagy hiányossága a Javának, bár állítólag 14-es óta a Java is talált erre a problémára valami megoldást de én még nem használtam.
Hat eleve a c#/dotnet nem egy platformfuggetlen valami. Persze par eve mar van hivatalosan dotnet _core_ ami ugye fut mac-en es linuxon is, de a hello world-on kivul nem sok mindenre hasznalhato a runtimeok/frameworkok hianya (windows-onlysaga) miatt. talan webservice backendet ossze lehet benne takolni akar mssql-el :), de pl gui-s appot biztos nem, max 3rd party megoldasokkal.
Arra mondjuk jo volt hogy a napokban kikiserletezzek crypto api-s dolgokat, hogy tudjak a wines fejlesztok c# appjaval titkositva kommunikalni. De itt is latszik az ms ms-sege: semmi ertelmes kulcs formatumot nem tud, csak a sajat binarisukat (CSP vagy mi) meg XML-t (ami szinten nem tunik valid xml-nek ranezesre). Ha pl PEM/DER/PKCS akarsz hasznalni akkro vagy 3rd party crypto (valami bouncingcastle vagy mi) kell hasznalnod c#-hoz vagy konvertalgatnod kell linuxon.
Alapvetően webes fejlesztésre (backend + valami frontend, esetleg blazor) szokták használni a C#-ot, illetve Unity-s játékfejlesztésekre.
Én világ életemben java-s voltam de volt egy C#-os projektünk még sok éve, alapvetően nem volt nehéz áttanulni, de folyamatosan belefutottunk abba hogy míg a java-hoz végtelen mennyiségű jó minőségű, karbantartott, működő, nyilt forráskódú könyvtár volt elérhető, addig a .net világban vagy azzal kellett megoldani amit az alap környezet adott, vagy pedig lehetett az 1000$-okat perkálni.
Azért ha valaki az elmúlt ~10 évben kezdett .NET-tel foglalkozni, akkor ez már bőven nem mentség. :)
Nyilván kell idő, mire a piaci szereplők a tanult tehetetlenségükkel felveszik a változást, de szerintem manapság a .NET kódok kisebbik fele fordul csak Windows-ra. Az ASP.NET és társai nagyon jók backend fejlesztésre, bőven racionális döntés lehet ma is abban elkezdeni egy projektet.
A cég nagyobbik fele C#-os, viszont róluk nem tudok közvetlenül nyilatkozni, mert a Java-s sarokba vagyok zárva. Nálunk alap a Docker és Linux CLI de látva a meglepett arcokat, mikor Docker licenszet meg ssh hozzáférést igénylünk nem csodálkozom a megfigyeléseden.