- sziku69: Fűzzük össze a szavakat :)
- Sgr_A: Számítógépeim aktualizálása cseréje
- Geri Bátyó: Agglegénykonyha 2 – Főzés: szabályok, vagy szabadság?
- gban: Ingyen kellene, de tegnapra
- Luck Dragon: Asszociációs játék. :)
- Gurulunk, WAZE?!
- Magga: PLEX: multimédia az egész lakásban
- hcl: Kelj fel komám, ne aludjál
- Geri Bátyó: Agglegénykonyha – bevezető - igényfelmérés
- Geri Bátyó: Agglegénykonyha 1 – rizseshús másképp
-
LOGOUT
Új hozzászólás Aktív témák
-
-
martonx
veterán
Kevered az sdk-t a runtime-al. A megcélzott OS-nek megfelelő runtime-ot könnyen hozzá tudod csomagolni az apphoz (de nem kötelező, te döntesz). Szegény win így is tele van minden szarral, miközben mindenki mást és mást hiányol belőle (én pl. Total Commander szerű file kezelőt). Szóval szerintem nem baj az, hogy nincs winen alapból minden szar, majd felteszi mindenki a saját szarjait. MS kivételesen pont jól csinálta, hogy az új dotnet alapból nem a rendszer része. Pláne, hogy a cross platformság miatt egyébként is arra kell készülni, hogy az OS-en nincs elő telepítve dotnet. Ennyike.
-
martonx
veterán
-
martonx
veterán
Akkor egy könnyebb probléma:
Adott egy 10 numerikus karakter hosszú szekvencia, mint például:0000000001
0000000002
0000000003Ezekből kellene randomnak TŰNŐ, de könnyen visszakódolható, ugyanilyen hosszú csak numerikus karaktersorozatot generálni.
Azaz valami ilyesmi végeredmény kellene
0000000001 -> 9122365657
0000000002 -> 1234567890
0000000003 -> 1565789431Milyen ötleteitek vannak ehhez?
-
#18124
martonx
veterán
Ryan_Sanchez
#18116
martonx
veterán
válasz
Ryan_Sanchez
#18116
üzenetére
Adj jobb nevet neki spéci karakterek nélkül (beleértve a magyar ékezetes betűket is).
-
martonx
veterán
Hehehe, pont, hogy ugyanarról beszélünk
Hiszen én is pont ezt írtam, amit te.
Egy szintig minden tanulható. Vannak szakmák, amikbe ily módon iszonyú alacsonyan van a belépési szint (pl. rendőr, szobafestő stb...), és vannak szakmák, amikhez adottság kell (profi táncos, zenész, sportoló, programozó, kvantumfizikus stb...).
Én is pont ezt mondtam.
Az megint más kérdés, hogy lehetnek helyzetek (sőt lehet, hogy nem is kevés ilyen eset van), ahol bárki meg tudja állni a helyét programozóként pl. garázs cégnél PHP-s CMS-ekkel stackoverflow alapján összebohóckodni valamit, vagy elmenni a Kréta rendszert fejleszteni, hogy egy pici aktuálpolitikát is belecsempésszek -
martonx
veterán
Azt, hogy a szakmájában mindenki lehet profi, ne keverjük ide.
Hogy nem az iskola teszi, abban egyetértünk.
Amit mondasz butaság, de betudom annak, hogy még nem találkoztál komplex problémákkal, skálázott, elosztott, nagy terhelésű rendszerekkel.
Ahogy gondolom Computer Visionnal és Game Engine fejlesztéssel se sokat foglalkoztál.
Természetesen a programozásban is vannak kisipari, favágó feladatok, pont ezeket soroltad fel, de a programozás sokunk számára ennél sokkal komplexebb feladatok megoldásából áll. -
martonx
veterán
"Semmivel sem bonyolultabb programozónak menni, mint lakatosnak vagy burkolónak, persze más skillek kellenek hozzá, de ez igaz minden szakmára."
Ez mondjuk hülyeség.
Egy szintig nyilván tanulható a programozás, ahogy bármilyen más szakma is.
Az emberek többsége simán megreked a tömbök, ciklusok szintjénél, hogy már ezt sem igazán érti
Ők többnyire nem is mennek programozónak.
A programozók többsége ezen túljut, de megreked a picit is komplexebb feladatoknál, rekurziónál, és megmarad frontendesnek (ne értesetek félre, vannak bonyolult frontend esetek is, itt most a layoutokat futószalagon kialakító kisiparosra gondoltam), CMS taszigálónak.
És van egy elég szűk réteg, aki tényleg ért is ahhoz, amit csinál. Komplex problémákat, nagy kódbázisokat, bonyolult architektúrákat is át tud látni, azokban magabiztosan mozogni, változtatni. -
martonx
veterán
válasz
Alcsi69
#17919
üzenetére
Léteznek. És abszolút nem kell a NodeJs-t erőltetned, léteznek normálisabb nyelvek is, mint a javascript (mondjuk backenden TS-ként használva nem annyira gáz). Igaziból bármilyen program nyelvet lehet backenden használni. Talán Java és C# a legelterjedtebbek, nem számítva a PHP-s móricka projekteket, amik egyébként a piaci súlyukat tekintve a többsége a projekteknek, de ezekhez elég csak szellemi segédmunkásnak lenni.
És akkor jöhetnek a megkövezések -
martonx
veterán
válasz
skoda12
#17900
üzenetére
Engedjük már el ezt a magyar ügyfél szar dolgot. Nagyobb cégek azért nem dolgoznak magyar piacra, mert a magyar ügyféllel is ugyanannyi gond és baj van, mint egy nyugatival, csak éppen töredék pénze van cserébe. Ergo anyagi okokból fordulnak nyugati ügyfelek felé, nem pedig azért, mert átlag magyar ügyfél hülyébb lenne az átlag nyugati ügyfélnél.
Főállásomban egyszerre dolgozok magyar ügyféllel is, és egy másik projekten külföldi ügyféllel is. Egyik sem problémásabb a másiknál. Csak míg a magyarnak meg kell részletesen magyarázni (jelzem ezzel önmagában nincs baj, hogy megkérdezi, és el is fogadja a választ), hogy miért kerül havi 120-130 EUR nettóba a hostingja, addig a külföldi meg se kérdezi, hogy miért számlázunk ki havi 2000 EUR-t hostingra (miközben alig van terhelés a szerveren, és valójában megoldjuk kevesebből, mint a magyar ügyfél hostingját...). Cserébe a nyugati ügyfélnek kismillió egyéb nyűgje van, mégis mindenki boldog, hogy de jó ügyfél.![;]](//cdn.rios.hu/dl/s/v1.gif)
Ezzel csak szemléltetni akartam, hogy miért szeretnek a cégek inkább nyugati ügyfélnek dolgozni.
Mellékállásban egyéni vállalkozóként két magyar ügyfélnek dolgozok (az egyik bérel tőlem egy webshop rendszert, a másik pedig az egyik állami múzeum). Semmi baj nincs velük, tök korrekt ügyfelek. Jelzem idáig eljutni azért nem volt könnyű, és tényleg ki kell szórni a "minden kéne tegnapra, de miért nincs ingyen?" megkereséseket. -
martonx
veterán
válasz
FeniX-
#17889
üzenetére
Ez szimpla ügyfélkezelési probléma, nincs köze ahhoz, hogy az ügyfél magyar-e vagy külföldi.
Az ismerősöd nem tud bánni az ügyfelekkel és/vagy annyira rá van szorulva a pénzre, hogy rögtön ugrik mindenkinek mindenre, ezzel elkapatva az ügyfeleit.
Le kell szarni, hogy mit csinál a megrendelő dacára a szerződésnek, megegyezésnek, hiszen azért van szerződés, megegyezés, mert az a programozót is védi, nem csak a megrendelőt.
Ha le van írva, hogy milyen rendelkezésre állással dolgozik valaki és milyen módon fogadja el a support ügyeket, akkor ez van.
Persze ettől még lehet próbálkozni éjszakai telefonhívásokkal, meg mindenféle fenyegetőzésekkel, de a szerződés/megegyezés kimondja, amit kimond, ahhoz mindkét félnek tartania kell magát.No persze a dolognak lehet olyan olvasata is, hogy ismerősöd annyira szarul dolgozik, és annyira ótvar hibák jönnek elő a kódban, ami a megrendelő részéről elviselhetetlen, és mondjuk egy péntek délután felfedezett (netán előtte 10 percel kiélesített) hiba annyira durva, hogy nem várhat a hétfői javításig, mert addig X milliós bevételtől esik el a megrendelő a programozó hibájából.
Ha rendre ilyenek miatt jönnek a soron kívüli hívások, akkor meg azt tanácsolom az ismerősödnek, hogy ne erőltesse, ami nem megy, ne legyen programozó, menjen el inkább asztalosnak. -
martonx
veterán
válasz
pmonitor
#17866
üzenetére
Közszférában válogatott debilek dolgoznak, ez ismét megerősítést nyert. Tényleg közben eszembe jutott, hogy tudok neked kódot mutatni.
https://www.nuget.org/packages/BarionClient2
Az első clientben még csak közreműködő voltam. Viszont az elhagyatott lett, valakinek tovább kellett vinnie, így lett belőle 2-es. -
martonx
veterán
válasz
pmonitor
#17803
üzenetére
Jaaa, hogy a Google-t pozitív példának írtad? Azért a Google keresés sebességét hasonlítani egy garázs szerveren futó SQL-éhez, szerintem nem korrekt. Ennyi erővel egy vadász repülőt is hasonlíthatsz egy normál autóhoz...
Emellett annyiban igazad van, hogy a garázs SQL-re olyan programozó dolgozik, aki egy év alatt nem keres annyit, mint a Google-nél dolgozó egy év alatt. Google-nél ilyenből van több ezer, a garázs SQL-en meg Pista bácsi egymaga bohóckodik.
Szóval igen, nem vagyunk egyformák, nem egyformák a képességeink.
Rengeteget állás interjúztatok, és nagyon gyakran ledöbbenek, hogy milyen gyenge programozók is vannak (többnyire állami szférából érkezettek a különösen fájdalmasak). -
martonx
veterán
-
#17663
martonx
veterán
gordonfreemN
#17661
martonx
veterán
válasz
gordonfreemN
#17661
üzenetére
Én valami ilyet próbálnék meg használni: GitHub - UglyToad/PdfPig: Read and extract text and other content from PDFs in C# (port of PDFBox)
Nyelvet nem írtál, de gondolom kiindulásnak egy ilyen PDF feldolgozó is jó ötlet lehet, biztos, hogy bármilyen nyelvhez találsz hasonlót. Más kérdés, hogy szvsz még ezzel is elég izgi lehet egy pdf-ben lévő táblázatból kimazsolázni az adatot.
-
martonx
veterán
A csapatom az én vezetésemmel per pillanat Írországba készít egy új szerencsejáték rendszert (hja, ahol olyan liberalizmus van, hogy gyakorlatilag bárki bármikor beléphet a szerencsejáték piacra, ha van egy ötlete, és sok-sok pénze a megvalósításhoz), de én se vagyok igazi programozó, mert nem atoi-t optimalizálok.
-
martonx
veterán
Ráadásul ahelyett, hogy igazi programozási problémákkal foglalkoztok, foglalkozhatnátok 2D vágással (azóta se vettem a fáradtságot, hogy utánanézzek mi is ez), és itoa optimalizálással, mint az igazi nem is programozók!
Sok kis csicska programozónak hazudott nick, most mit csináltok, hogy nincs, aki megmutassa, hogy mi is az igazi programozás?
Rögtön kétségbe estetek, mi? -
#17588
martonx
veterán
racskobalazs
#17587
martonx
veterán
válasz
racskobalazs
#17587
üzenetére
Örülök, hogy sikerült téged a helyes irányba állítani :)
-
#17586
martonx
veterán
racskobalazs
#17585
martonx
veterán
válasz
racskobalazs
#17585
üzenetére
Írd nulláról, és meglátod, hogy jéé Laravelben lesz eleve user menedzsment (vagy legalábbis tippre viszonylag könnyen hozzá adható, bekonfigurálható).
A meglévő kódrészeket meg ha minden jól megy jó részt fel fogod tudni használni Laravelben is. -
#17584
martonx
veterán
racskobalazs
#17583
martonx
veterán
válasz
racskobalazs
#17583
üzenetére
Keretrendszerrel írd újra nulláról. Ha php akkor Laravel, Yii meg nem tudom még mik a menők manapság. Nyilván bármilyen nyelvet használhatsz. Személy szerint a php-t kicsit butácska script nyelvnek tartom, de az utóbbi időben sokat fejlődött, és a célodnak simán megfelel.
-
martonx
veterán
válasz
dabadab
#17552
üzenetére
Egy ilyet találam közben: Public Holiday API Documentation (theapiguy) | RapidAPI
Havi száz hívásig ingyenes.
Google Calendar is jó ötlet, csak hirtelen nem tudom, azt hogy lehetne C#-ba legkönnyebben beemelni, míg egy json-t visszaadó API result beimportálása csukló mozdulattal meg is van. -
-
-
martonx
veterán
Mi az AI-t konkrétan videókon látható arcok érzelemfelismerésére használtuk. Jelenleg pedig kódelemzésre. A lehetőségek végtelenek, csak ügyesen (erőforrásokat nem kímélve, ebbe beleértve a neurális hálót megálmodó matematikusokat is, és a végtelen sok betanítást) kell a neurális hálót megálmodni, betanítani. Előző cégemnél éveket és EUR milliókat öltek ebbe.
-
martonx
veterán
Pontosan erre írtam, hogy matematikusok csinálják a hálókat, és mindegyik ilyen kollégának a statisztika a szakterülete, doktorival, mindennel
Egyikük sem programozó, csak szín tisztán matematikus, akik kenik vágják a statisztikai számításokat.
Remélem kezd letisztulni a kép -
martonx
veterán
Azt állítom, hogy ha a sok maszlagot (amiben természetesen rohadt sok fejlődés volt mind hardveres, mind elméleti vonalon) félretesszük, és eléggé felülről nézzük, mert egy laikusnak kell elmagyarázni, hogy mi az az AI és ML, akkor a statisztikával nem lövünk mellé. Végtelenül leegyszerűsítve a koncepciót, beküldünk rohadt sok (féle) adatot, és ezek alapján kapunk egy valószínűséget (ami bármi lehet, akár egy kép is, egy érzelem, bármi, amit az AI a legvalószínűbbnek tart).
-
martonx
veterán
Az általánosítás valahol nem statisztikai fogalom? :D
Értem én, hogy volt fejlődés a statisztikában (manapság trendibb data-sciencenek hívni) az elmúlt 50 évben, és ez pont a számítógépeknek volt köszönhető. De ne tegyünk úgy ML, AI kapcsán mintha most valaki feltalálta volna a spanyol viaszt, és a semmiből idekerült volna valami tökéletesen új csoda. Igen, a számítógépeknek köszönhetően új szintre emelkedett. -
-
martonx
veterán
Kismillió bevitt adat alapján jóslást jelent az AI, ha nagyon le akarjuk egyszerűsíteni. Mondok egy szuper leegyszerűsített példát. Rúzsokat árulsz, egy éve rögzíted a boltba betérők nemét, és hogy vásárolt-e.
Ezeket az adatokat betolod valami felhős ML ízébe (nálam műveltebbek ezt hívják betanításnak). Ez alapján pedig, amikor legközelebb bejön valaki a boltba az AI meg fogja tudni egész pontosan mondani, hogy vásárolni fog-e.
Ha ez alapján úgy érzed, hogy ilyen tudomány régen is volt, csak akkor ezt másképp hívták, akkor nem állsz távol a valóságtól.
Azért a fenti Móricka példa ne vezessen félre, minél több adatot vesz az AI figyelembe a jósláshoz, annál izgibb tud lenni a dolog. -
martonx
veterán
-
#17387
martonx
veterán
Ryan_Sanchez
#17386
martonx
veterán
válasz
Ryan_Sanchez
#17386
üzenetére
Kicsit konkrétabban? Jsonról hallottál-e? Js oldalon mit csinálsz?
-
martonx
veterán
Ilyen filozófiai mélységekbe ne menjünk bele, hogy mi számít felhőnek, és mi nem.
Arra gondolok, hogy ezekhez nem igazán kell szerver. Garázs cégeknél szerver bérlés meg pláne zsákutca. Ha önképzés a cél, akkor a felhőben futtatási lehetőségekkel kellene ismerkedni, nem linux szervert konfigurálgatni. No persze felhőben (ok, számomra a felhő az AWS, Azure, Google Cloud) is lehet komplett szerver instance-t keríteni, ha valaki mindenáron ehhez ragaszkodik. -
martonx
veterán
Öööö ez a két tábla közötti kapcsolat így biztos jó???
Jól látod, a hibaüzenetet azért kapod, mert ezzel az elrontott tábla kapcsolattal seperc alatt körkörös referenciát érsz el
Feltételezem latest .Net 6-ot használsz, feltételezem default System.Text.Json-nal szerializálsz. Ez esetben itt van némi olvasnivaló, benne talán megoldással is a problémádra: System.Text.Json features in .NET 6 (okyrylchuk.dev)
-
martonx
veterán
Én már rég nem lepődök meg semmin, ilyet meg se akarok tippelni. Az biztos, hogy az egy szál kompozit index folyton buzerálva lesz, bármelyik oszlopban is változzon bármi, azaz íráskor vélhetően az 1 nagy kompozit index rosszabb lesz (aztán lehet, hogy ez is hibahatáron belül mérhetetlen eltérés csak). A külön külön index-ek meg lehet, hogy olvasáskor teljesítenek valamivel rosszabbul, de erre se vennék mérget. Ezért is kérdeztem a kollégát, hogy ha már ennyire szenved, hogy mindenáron egy nagy kompozit indexet akar, valóban kimérte, és drasztikusan jobb teljesítményt ad a kompozit index?
Szóval belőlem pusztán a szakmai kíváncsiság beszélt, mivel ott van a DB-je, remélhetőleg több millió adatsorokkal, könnyedén ki tudja mérni a különbséget a kétféle indexelési stratégia között. -
martonx
veterán
"A jelek szerint indexeket virtuálisan leírni, és később azokra hivatkozni az EF még nem tud" -
azóta is ezen gondolkozok: tényleg számít ez? Van 3 meződ, és mindegyiken van 1-1 index. Vagy van ugyanez a 3 meződ, és 1 komplex index van a három felett? Komolyan kérdezem, benchmarkot is megnéznék, hogy a valóságban mi a különbség a két megoldás között.
Mert én azt tippelem, hogy szinte semmi, bár lehet, hogy sok milliárd adatsornál már a szinte semmikre is van értelme optimalizálni, bár ott meg már úgysem ORM-ezik senki. -
martonx
veterán
Amit írsz node.js-hez (de hehe Python-t, sőt PHP-t is láttam már emiatt kártyavárként dőlni) teljesen igaz. Webes frontend dolgokra mérsékelten igaz. Egyébként meg, ahogy mondtam nem kell, agyatlanul mindenre libeket behuzigálni, és akkor elég könnyen lehet minimalizálni ezt a problémát.
-
-
martonx
veterán
Azta 100mb méret a node_modules, és maguk alá 134 alfüggőséget húznak be? Úúúú de dúrva
Az app egyébként valóban nem a legkomplexebb, viszont nem is egyszerű, még ha a dependency-k alapján annak is tűnhet. Csak mi nem rohanunk mindenért külön lib-et behúzni, hanem igyekszünk sok mindent házon belül tartani, megoldani. Lehet, hogy ezzel van amikor plusz pár nap munkát okozunk magunknak, viszont a végeredmény sokkal jobban menedzselhető lesz, és a kismillió függőségnek se vagyunk úgy kitéve, amivel meg végeredményben munkát tudunk spórolni, és a végeredményünk is személyre szabottabb, kisebb bundle méretű tud lenni. -
martonx
veterán
Hidd el, hogy amit te látsz, az nem a normális webes javascript fejlesztés.
Tudom hihetetlen lesz, de egy immár több, mint egy éves, egészen komoly nagy több emberes frontendes projektnek nálunk pl. így néznek ki a node-modules függőségei (Vuejs 3.2.X miatt még mindig sok benne a beta, alpha csomag, de ezek stabilak, csak épp nem rég lettek a 2.X-ről forkolva):"dependencies": {
"vue": "3.2.31",
"vue-grid-responsive": "next",
"vue-i18n": "9.2.0-beta.28",
"vue-meta": "3.0.0-alpha.10",
"vue-router": "4.0.14",
"vue-tiny-validate": "0.2.4",
"vue-good-table-next": "^0.1.0"
},
"devDependencies": {
"@intlify/vite-plugin-vue-i18n": "3.3.1",
"@vitejs/plugin-vue": "2.2.4",
"eslint": "8.11.0",
"eslint-config-prettier": "8.5.0",
"eslint-plugin-prettier": "4.0.0",
"sass": "1.49.9",
"vite": "2.8.6"
} -
martonx
veterán
válasz
pmonitor
#17214
üzenetére
Szövegértés, szövegértés
Én következetesen lekicsinylettem a szerepét, ettől függetlenül, ahogy abban a hsz-emben is elismertem, hogy vannak akik ennek az optimalizálásával foglalkoznak, és azt is elismertem, hogy van hova gyorsítani.
Mutasd meg hol írtam, hogy szerintem ez tényleg probléma, és egyébként tényleg szükség van az optimalizálására -
martonx
veterán
válasz
pmonitor
#17199
üzenetére
Nem.
Azt magyarázzuk, hogy probléma függő, hogy számít-e a sebesség. Nagyon sokszor nem számít. Az a fajta sebesség optimalizáció, amin te szoktál lovagolni, még annyiszor se számít. Amúgy meg WebAssembly-ről beszéltem, ahol ha értetted megint nem az itoa volt lassú :D
WebAssembly-t kérdezték leírtam mik a hátrányai, sőt azt is, hogy ezek mikor igazán hátrányok. Nyilván csomó esetben meg nem számítanak.
Azaz webshopos, Seo-ra kihegyezett oldalakat öngyilkosság WebAssembly-vel csinálni, mert Google pagespeed lepontoz a futtató környezet betöltése miatt. Miközben kismillió eset van, amire ettől még tök jó a WebAssembly (webes játékok, 3d-s webes grafika, admin screenek stb...).
Így már érthető? -
-
martonx
veterán
"Webassembly-t nem pont a sebesség miatt találták ki? És pont az a gyenge pontja
Ejnye, mi történt?" - az történt, hogy a webassembly tök gyors, meg csili-vili, éppen csak egy dolgot nem tud: DOM-ot manipulálni, ami a böngészőben lássuk be, elég nagy hiányosság.
Így aztán lassú, mint a szar, mihelyst javascript helyett akarod használni, hiszen szerencsétlennek, mindenért a javascript motort kell abajgatni, hogy ugyan rendereld már ki ezt, módosítsd már át azt...
Amellett, hogy a js natívan fut a böngészőkben, a Webassembly-nek még egy pár Mbyte-os futtatót is le kell húznia, ami érthetően nem tesz jót a pageloadnak.
Szóval szar lett, na.
Admin screenekhez, dashboardokhoz azért elég jó tud lenni (már ha a gyerek betegségeket pl. normális hot realod sikerülne kinőni), ahol nem gond, ha plusz 2 másodperc az oldal betöltési ideje, és nem dőlünk a kardunkba, ha nem atom gyors a renderelés, és az ember semmiképpen sem akarja javascripttel (vagy a még fájdalmasabb typescripttel) beszennyezni a kezét."egyszóval alkalmazás fejesztéshez sebességet adna" - pont erre való a vuejs, angular, react és a hozzájuk létező libek.
-
martonx
veterán
-
martonx
veterán
"core sdk kliens oldali támogatottság"
Web forms nincs, megszűnt, vége hála istennek.Ha azt érted a szokásosan zavaros kérdésed alatt, hogy mennyi támogatást ad az ASP.NET Core a html rendereléshez, akkor a Razor kimondottan hasznos! Viszont manapság erre már nem is a backendet szokták használni, hanem angular, react, vue javascript rendszereket.
Én php-vel semmilyen projektnek nem állnék neki, ha c#-al is lehet. És nem is feltétlenül azért mert gyorsabban lesz kész a projekt (php-s kókányolásnál biztos, hogy nincs gyorsabb), hanem a kód minőség, karbantarthatóság, szerver erőforrás kímélet miatt.
-
martonx
veterán
válasz
Sokimm
#17174
üzenetére
Szia!
Én meg a kérdésedet nem értem. Ha Web API-t akarsz, akkor hogy jönnek ehhez css, meg html file-ok?
A web api tisztán szerver oldal. Konzolba beírod:
dotnet new webapi
és voilá, nem kell feltételezni, meg érdeklődni, hanem megnézni, hogy milyen kiinduló kód generálódik
Hogy szerverre kell-e .net "csomag" (amit inkább SDK-nak vagy Runtime-nak illik hívni programozói körökben), az a kód publikálásodon múlik, több lehetőség is van. Van, amikor kell, van amikor a buildelt, deployolt kód magába foglalja a runtime-ot is.
Én mostanában docker image-re szoktam rá, hogy ekként publikálom, így garantáltan bármilyen futtató környezeten elfut (AWS, Azure, Heroku, bármi, ami docker image-et tud futtatni). -
martonx
veterán
Windowshoz kettő ingyenes, és egészen jó (noha nem hibátlan, és nem mindenható) git kliens van szerintem:
Fork - a fast and friendly git client for Mac and Windows (git-fork.com)
Sourcetree | Free Git GUI for Mac and Windows (sourcetreeapp.com)Hogy átszokni mekkora dolog, azt nem tudom, soha (na jó ez nem igaz, mert 15 évvel ezelőtt a karrierem kezdetén 4 évig használtam) nem használtam SVN-t.
-
Ők többnyire nem is mennek programozónak.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ejnye, mi történt?" - az történt, hogy a webassembly tök gyors, meg csili-vili, éppen csak egy dolgot nem tud: DOM-ot manipulálni, ami a böngészőben lássuk be, elég nagy hiányosság. 
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- NVidia RTX 3080 Founders Edition
- Canton Karat 40 hangfalpár
- AM5 Gamer PC - Ryzen 5 8400F / RX 9060 XT / A620M / 16GB vagy 32GB DDR5 RAM / 256GB M.2+1TB M.2 SSD
- Új Lenovo ideapad Slim 5i Multimédiás Laptop -35% 16" Brutál i5-1245U 10Mag 16/1TB IPS FHD+
- Asus Zenbook Pro 15 i7 7700HQ/1050ti 4GB/16GB RAM/100% sRGB
- AKCIÓ! Intel Core i9 14900K 24 mag 32 szál processzor garanciával hibátlan működéssel
- MikroTik CCR1009-7G-1C-1S+ Cloud Router
- Gamer PC-Számítógép! Csere-Beszámítás! I5 12400F / RTX 3070 8GB / 32GB DDR4 / 1TB SSD
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RTX 5080 16GB GAMER PC termékbeszámítással
- Olcsó Notebook! Dell Latitude E6540! I7 4600U / 8GB DDR3 / 128GB SSD! / HD8790M
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest