- Épített vízhűtés (nem kompakt) topic
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Hobby elektronika
- Zenelejátszó építése, a kiváló hangzásért
- Kormányok / autós szimulátorok topikja
- Milyen TV-t vegyek?
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Nvidia GPU-k jövője - amit tudni vélünk
- ThinkPad (NEM IdeaPad)
- Milyen videókártyát?
Új hozzászólás Aktív témák
-
buherton
őstag
& bambano.
Azért egy nyelv lehetőséget ad valamire még nem biztos, hogy használni fogják. Ezért kérdeztem hogy ismertek-e olyan széleskörben használt programot, amelyik binárisában benne vannak a shared libek.
Miből gondoljátok, hogy nem értek a C-hez?
Nyilván egy programnyelv nem jó mindenre. De attól még az igaz, hogy a Google a goval óriásit lépett, amivel bőven elhúzott a többi nyelv mellett és eddig kb egyetlen nyelv sem képes hozni ezt a szintet. Néhány példa amiért kiemelkedik a go a többi nyelvvel szemben, vagy legalább pariban van:
- szuper gyors build
- implicit build rendszer
- goroutine 3-4-szer gyorsabb és kevesebb memóriát igényel, mint a thread
- CSP stílusú megközelítés pedig nagyon egyszerűbé tette a concurrencyt
- leegyszerűsített nyelvielemek, amik azt csinálják, amit a fejlesztő gondol. Az utolsó kivételt épp most fogják befoltozni: [link]
- hatékony GC. Nem csak hogy gyors, de azt is eredményezheti, hogy a goban írt program pont ugyannyi memóriát foglal, mint a C/C++-ban írt.
- stb. -
buherton
őstag
Nagyon-nagyon régen töltöttem le Firefoxot, de akkor csak egy downloadert töltöttem le. Hogy aztán az mit töltött le azt nem tudom.
Tudsz olyan C-ben írt programot, ami
-static-al van fordítva és széles körben használt?Azért mert A mellett valamit tud a B is, attól még az A nem lesz rosszabb.
-
buherton
őstag
Ez azért így, ebben a formában egyáltalán nem igaz.
Igen, ez nem is kicsit költői túlzás volt, hiszen a docker a virtualizáció miatt sok mindent képes limitálni. De az kétségtelen, hogy a többi nyelvben írt programmal szemben itt a go binárisnak gyakorlatilag nincs dependenciája (cserébe nagy). Szóval, simán működik az összes Linux disztrón, hogy ugyanaz a binárist tölti le a user és futtatja, pl: [Minikube]
A C és C++ standard sem segít, hogy egyszerű legyen, mert hogy definiál macro-kat, ami időre és helyre vonatkoznak, ezek pedig nyilvánvalóan változhatnak.
Az egyik korábbi helyen pont emiatt csináltam, hogy a log függvénynek átadott forrás fájl path macrot compiler kapcsolóval írtam át, hogy csak a fájlneve legyen benne. Így sem volt maradéktalanul azonosak az object file-k, de legalább az azonos hosszuk végett a nagyja egyezett.
-
buherton
őstag
Ez a blogbejegyzés egyébként nagyon-nagyon jó. A legtöbb pontjával tudok azonosulni. Nem véletlenül váltottam C és C++-ról go-ra. A go legtöbb olyan problémát megold, amivel a többi programnyelv nem tud mit kezdeni. Ráadásul ezen túlmenően is rengeteg olyan dolgot hoznak be, ami eddig nem igen létezett. Pl. a legutóbbi nagy dobásuk az volt, hogy teljesen reproduceolhatóak a binárisok!!! [link] Óriási dolog! Azt a blog is kiemelte, hogy a go gyakorlatilag értelmetlenné tette a dockert. És még sorolhatnám a go előnyeit, kb az összes nyelvvel szemben.
-
buherton
őstag
Talán annyi különbség van a közmű szolgáltatók és a Google között, hogy az előbbi tipikusan non profit cégek, addig az utóbbi profitorientált cég. De egyébként igen, végeredményben ha másért nem is, de a fenntartástért, üzemeltetésért, karbantartásért, stb. fizetni kell.
-
buherton
őstag
egyébként pedig adatbázist rendes helyen adatbázis szakértő tervez, és nem excelben.
A XFT fogalma pont azt takarja, hogy a csapat minden olyan kompetenciával rendelkezik, ami a munka elvégzéshez szükséges. Ha kell adatbázis szakértő a feladathoz, akkor az Agile alapján lesz adatbázis szakértő a csapatban.
ettől még az agilis módszertan sok helyen arról szól, hogy a megrendelőnek fogalma sincs, hogy mit akar, és ezen dolgoznak
A megrendelő nem tudja, hogy mit akar és az Agile pont erre ad megoldást, hogy derüljön ki mihamarabb.
-
buherton
őstag
másrészt azt elég nehéz lenne elvitatni, hogy a szoftveriparban káros folyamatok zajlanak, aminek az eredménye a pocsék szoftver. a pocsék szoftver egyik oka pedig a kapkodás, a szükséges fejlesztés megspórolása.
És az is, hogy a fejlesztők jó része megragad egy szinten, nem akar jobbá válni. Ha el is megy tanfolyamra, akkor sem igazán figyel oda és/vagy érti meg az elhangzottakat. Ez nem Agila. Btw, a Scrum Master egyik feladata, hogy a csapat megkapja a szükséges oktatást, amivel a feladatát eltudja végezni.
#126 dabadab: Nagyon nehéz objektíven összemérni két nyelvet, mindenesetre tettek próbát, aminek ez lett az eredménye:
[Rust vs C Clang]
[Rust vs C++]Nekem a fentebbiek alapján azt vontam le, hogy abszolút fej-fej mellett vannak. A Rust-t egyébként nem ismerem jól csak hallottam róla.
A go:
[Go vs Java]
[Go vs C#]
[Go vs C++] (nyilván a C++ gyorsabb, de azért az komoly, hogy a go memória footprintje az több esetben is azonos a C++-al)A go egyébként sokat merített a C-ből, talán azért is, mert az egyik megalkotója Ken Thompson. És abban is hasonlít a C-re, hogy kevés nyelvi elemet használ, de nagyon eltud aztán bonyolódni. Nekem nagyon tetszik ez a nyelv. Többek között ennek hatására tettem le a 10 éves C-s pályafutásomat.
#135 bambano: Az iterációs témakörhöz. Leírva szépen hangzik, hogy majd az üzletért felelős xy szépen megtervez meg leír mindent és alaposan mindenkit kifaggat, hogy wtf. A baj csak ott van, hogy igazából senki nem tudja, hogy mit is akar a customer. A customer maga sem tudja az elején. Azért kell mi hamarabb megmutatni, hogy legyen képe arról, hogy mi ez.
Amikor az elemző végez az iterációkkal, akkor keletkezik egy végleges rendszerterv.
Ilyen természetszerűleg nem létezik.
Amit te szeretnél az a németes waterfall, ami már kb akkor elbukott, amikor elkezdték használni.
És pontosan ezért röhögte ki a bankos haverom az agilis módszertant, mert a banki szféra speciális szabályainak nem lehet találgatással megfelelni.
A szabály az szabály, azt meg kell csinálni és ebben is segít az Agile és a CICD, hogy belegyenek tartva.
Gondolom a banki szabályok nem fedik le maradéktalanul, hogy egy alkalmazásnak hogyan kell működnie, ergo jó ott is az Agile, mert az elején ott sem tudják, hogy mit akarnak.
Autót sem úgy gyártanak, hogy már elindult a gyártóüzem felszerszámozása, de még nem világosak a célok, a marketing selling pointok, a célközönség meg a hasonló dolgok.
Szóval minden gyártónak minden autója sikeres lesz. Ha ez talán mégsem lenne igaz, akkor az Agile itt is segíthet bár ez nem SW és itt a átfutási idők jóval hosszabbak.
"Ez nem újdonság, mindig is így volt és természetesen ennek nincs köze az agile-hoz.": egy tőről fakad: azért ócska a szoftver, mert meg akarják spórolni a költségek egy részét, és ezért "fejlesztették ki" ezt a bullshit módszertant, hogy ezzel elfedjék a tróger munkát. De a tény az, a szoftver projektek zöme bedől. Tehát a jelenlegi szoftverfejlesztési módszertanok nem jók.
A fejlesztői és vezetői kvalitás hiányára nem lehet semmilyen módszertant kitalálni, ami ezeket megoldja.
Érdekes, hogy pl. a Spotifyról nem sok rosszat hallottam senkitől, holott ők aztán nagyon durván tolják az Agile-t.
-
buherton
őstag
Persze, amikor egy gyártóegység megáll egy idióta Siemens hiba miatt, akkor biztos nem kellett volna normálisan megírni.
Nem tudom milyen hibáról van szó, de hibamentes SW nem létezik, maximum olyan, amiben nagy eséllyel nem talál hibát a user. A megtalált hibák/tesztelésre fordított idő arány pedig nyilvánvalóan az idő előre haladtával csökken és aztán már nem éri meg. Ilyenkor jön az, hogy az ügyfél tesztel.
Mintha mondtam volna már, hogy a német cégekről talán még rosszabb véleményem van, mint a magyarról.
a fejlesztési költségek csökkentek,
Pontosan erről beszéltem.
#122 dabadab: "Gálánsan" elfeledkeztem az újkori nyelvekről, úgy mint a go és a rust, amik szemben a korábbi filozófiával hatékonyabban használják fel az erőforrásokat, mint a saját területeiken lévő nyelvek.
-
buherton
őstag
Ez már - szerencsére - nagyon régóta igaz, hogy a HW-t olcsóbb venni, mint a SW-t írni. És ez így van jól, mert elég meredek lenne asm-ben vagy C-ben business appokat írni. Ha már játékok, akkor valahol olvastam, hogy az Imperium Galactica tán 10k HUF volt, amikor kiadták és manapság is 20-25k körül megáll egy játék, de közben a fizetések min 10-szerese lett.
Btw, egy tisztességesen megírt SW-t kb. senki nem vesz meg, mert túl drága lenne.
Igen, vannak helyek ahol hellyel-közzel működik az Agile. És igen, tényleg kevés van sajna.
-
buherton
őstag
Miért fáj, hogy ekkora egy játék? A TB-okat nagyon olcsón adják már ráadásul, így több marad a zsebedben, mintha mondjuk kétszer annyiba kerülne a játék, mert hogy optimalizálni kell ezerrel.
#99 hcl: igen, attól még, hogy külföldi nem lesz rögtön Messiás, ahogy a magyar menedzser sem jelenti azt, hogy nem jó benne. Nekem most magyar menedzserem van és egy szinttel fentebb is magyar van. Értenek hozzá és jók benne.
#100 bambano és a többi hasonló tartalmú hsz-re: azt tapasztalom - legalábbis itthon -, hogy van egy fajta ellenszenv az Agile-al szemben és olyanokat is belelátnak, ami egyébként nem is az Agile része.
Az Agile egy keretet ad a SW fejlesztésnek. Definiál szerepköröket (Product Owner, XFT, stb.), jól definiálja azt, hogyan folyik az információ (Backlog Refinement, Sprint Planning, stb) és leírja az elvárásokat is (DoD, DoR, stb.). Ha mindenki csinálja a dolgát, akkor az ügyfél azt kapja, amit kért és akkorra amikor a cég ígérte.
A jelenlegi környezetben ez a legjobb módszer a SW fejlesztéshez. Vannak hibái, de jelenleg nincs jobb megoldás, majd biztosan lesz.
Az egyszerűen hazugság, hogy nem kell tervezni.
Az Agile - és egyébként minden elképzelésnek - természetszerű gyengesége, hogy emberek működtetik. Hogyan várjuk el az Agile-tól, hogy jól működjön, amikor tipikus mezei fejlesztőből lesz Scrum Master?! A menedzsment sem hajlandó elfogadni, hogy user story-ban kellene gondolkozni, no meg story pointban?! Nem csodálom, hogy sokaknak nincs jó tapasztalata az Agile-al, egyszerűen nincs elég jó szakember Mo-n. Azon sem lepődnék meg, hogy menedzsment sem veszi komolyan az Agile-t, mert hogy máshol sem voltak jó tapasztalataik ezzel, mert hogy szakbarbárok működtették az Agile-t.
Itt egy érdekes beszámoló a fentebbiekről: [link]
ehhez kell ez a rilízelj gyakran, gyorsan, sokat történet,
És ez nagyon jó dolog. Ez jó a fejlesztő cégnek és a vevőnek is. Btw, ez egy jó CICD nélkül nem megy. Emlékszem egy másik multinál óriási erőfeszítés kellett ahhoz, hogy a féléves releseak helyett negyedéve legyen, de úgy hogy 3 hetente már lehessen adni a customernek valamit tesztelésre. De nagyon jó, hogy meglépték, mert a SW quality sokat javult. Nyilván nemcsak azért, mert jóval gyakoribb lett a SW átadás, hanem mert több féle automata teszteket is bevezettek.
rendes helyen meg úgy megy a szoftverfejlesztés, agilitást nagy ívben kerülve, hogy üzleti elemző megnézi a folyamatot, a folyamaton történő fejlesztési igényt, és ezt iterálva elkészít egy rendes, részletes, hitelt érdemlő, elfogadott üzleti specifikációt. utána indul a program tervezés és programozás. na ezt akarja mindenki megspórolni, erre találták ki az agilis módszertanokat.
Itt utalnék vissza arra, amikor valaki olyat lát az Agile-ba, ami nem is
. Az Agile sehol nem mondja azt, hogy ne legyen üzleti/termék/SW terved, sőt! Az iteráció pont az Agile egyik lényeges pontja. -
buherton
őstag
A CICD témakör messzire vezet. Annyival szeretném itt lezárni, hogy egy SW termékfejlesztése elképesztően komplex dolog. Olyanokra kell gondolni, hogy:
- fordítható-e a kód
- statikus kód analízis
- dinamikus kód analízis (nem garbage collected language)
- 3PP check
- unit testing
- fuzzy testing
- kód vulnerability check
- formai követelmény ellenőrzés
- smoke/regression/e2e/integration/component testing
- vulnerability test
- stb.Ezeket pedig szerencsésebb automatikusan futtatni, mint sem kézihabverőzni. Szóval, igen jobb helyeken CICD nélkül nem lehet SW-t fejleszteni.
-
buherton
őstag
Ezek közül egyik sem 10-15 éves, hanem annál régebbiek. Nem véletlenül tettem ezt be a feltételek közé.
Nem sajnálom le és nem is köpök rá. Ezek mind személyes tapasztalatok különböző cégekről, szóval még csak nem is egy mintás “felmérés”. A németeket nem vettük elő, de velük talán rosszabb tapasztalataim voltak. Több német cégnél dolgoztam.
hcl: Amikor azt írtam, hogy ne legyen bughalmaz, akkor pont a syslog-ng-re gondoltam. A memóriaszivárgást szerintem a mai napig nem tudták megoldani és ez memória szűkös környezetben gond.
-
buherton
őstag
Az elmúlt 10-15 évből milyen terméket tudnál mondani, amit magyarok fejlesztettek, magyar tulajdonú cégben, és nem egy bughalmaz?! Őszintén érdekel a válaszod.
Korábban dolgoztam több magyar cégnél, többféle pozícióban és siralmas állapotok voltak.
Orvostechnikai eszközöket gyártó vállalatot kellett volna segítenünk, hogy FDA approved termékeket állíthasson elő. Olyan szintű ellenállás volt minden rétegen - kivéve persze a legfelsőt, akik felkértek -, hogy 3 hónap után belebukott az egész. Képtelenek voltak felfogni, hogy a változásra szükség van és hogy nem lehet elsőre mindent frankón megcsinálni.
A másik helyen egy angol luxus autógyártónak egy eszközt kellett készíteni. Az volt a csoda, hogy verziókövető rendszer volt. A CICD a kanyarban sem volt… Óriási csúszások, egy bughalmaz maradt ott…
Egy amerikai multi vásárolt fel egy magyar startupot. Ennek nyomán a magyar mentalitás megmaradt. A menedzser telibe sz..a hogy legalább egy alap CICD-t összedobtam két projektre autodidakta módon. Olyan kisstílű volt, hogy a csapatépítésre én vittem el autóval.
. Az Agile sehol nem mondja azt, hogy ne legyen üzleti/termék/SW terved, sőt! Az iteráció pont az Agile egyik lényeges pontja.
Új hozzászólás Aktív témák
Hirdetés
ph Nagy reményekkel figyelik a keresőriválisok a Google és az USA perét: a Google azt állítja, hogy nem élt vissza az erejével, hogy monopolhelyzetbe kerüljön a keresőpiacon – az USA viszont kemény vádakkal támadja a nagy trösztellenes perben. Állítólag az internet jövője a tét.
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest