Új hozzászólás Aktív témák
-
emelhu
aktív tag
válasz
Predatorr
#127
üzenetére
"az a biztos, ha a programozókat odaültetik a felhasználó mellé, aki minden apró bosszankodásnál jól pofán vághatja őket. Szerinte nagyon hamar megtanulnának jó kódot írni"
Elsőre jó, másodjára minden felhasználói igényre azonnal határidő és díjmódosítás, amit (természetesen szakmailag alá kell támasztani, de nem megkérdőjelezhető csak másik kompetens szakmai alátámasztás esetén)
Így már jogos
-
pengwin
addikt
A WYSIWYG azért előny, mert a sok laikus felhasználó azt hiszi, hogy könnyebben felfogja. Nincs meg még az a vékonyka absztrakciós réteg sem a felhasználó és a kreált tartalom között, ami egy TeX (vagy HTML, vagy XML, vagy stb.) dokumentum esetén jelen van.
Viszont a saját tapasztalataim szerint ezek a laikusok sokkal kevésbé értik, hogy mi történik, és miért. Én tisztában vagyok vele (ahogy minden más kommentelő is), hogy az IT piac ebbe az irányba megy minden téren. Minden "apple"-ösödik, nem kell érteni a felhasználónak semmihez, csak idomított majomként nyomkodja a szoftverét.
Széllel szemben pisilünk azzal, hogy ez nem tetszik és ezt tudjuk is, csak attól még nem kell örülni az informatika ilyen irányú butulásának.Én munkaként dokumentációt írók, nálunk ezek munkaeszköznek minősülnek, és nagyon éles határvonal van a WYSIWYG FrameMaker-en szocializálódott kollégák és a DITA XML-hez szokottak között. Utóbbiak sokkal könnyebben átlátják a FrameMakert, a hibáit és a lehetséges megoldásokat. Előbbiek meg szenvednek, és már egyszerű problémákkal is nálunk kérdezősködnek. És én segítek nekik megoldani a problémákat úgy, hogy kb. másfél hónapja láttam először Adobe FM-t.
(#222) Tapsi
Nos igen, ez már hitvita kérdése.
Nem az.
Objektíven szemlélve rossz a piacnak, hogy egy cég kezében ekkora a kontroll, és az embereknek nem is mutatnak mást.Nekem például nem fáj, hogy olyan tudást adnak a gyerekeknek, amire a piacon igény van.
Neked nem fáj, viszont objektíven szemlélve óriási probléma, hogy emiatt csak idomítás van az iskolai informatika órákon. A gyerekek nem tanulnak meg alapvető GUI-s konvenciókat, nem tudnak semmit egy átlagos szoftver logikai felépítéséről (értsd: melyik funkciót hol találhatom meg? milyen logika alapján társítanak össze különböző eszközöket eszköztárakba?), hanem csak az Office egy adott verziójában tudják, hogy kb. hova kell kattintaniuk.
A legtöbb cégnél azért írják a rohadt Office csomag ismeretét, mert ők sem tudják, hogy mit várnak el ténylegesen a munkavállalótól. És az pedig a problémamegoldás és alkalamazkodás [a manageri hülyeségekhez] szokott lenni, aminek az Office csomag ismerete csak egy elenyésző része.
Mert ha éppen változik a céges toolchain, akkor a T.Munkavállaló legyen szíves átlátni az új (többnyire szintén MS-os) szoftver logikáját, GUI-ját, találja meg benne ugyanazokat a funkciókat, mint az addigi eszközben.
De ha csak egy adott eszköz nyomkodását idomítod addig a pontig, akkor még a szóban forgó szoftver egy újabb verziójának új GUI-ja is haza fogja vágni a "MS Office csomag ismeretével rendelkező" munkavállalók produktivitását. -
Petyyyyy
addikt
Remek összefoglalás.
A kettő közt lesz valahol az igazság - a vezetőség irtó bamba tud lenni, nem fogadják el a tényeket és valóban sok a pék.Szinte kivédhetetlen a jelenség, egyszerűen nem programoznak elegen olyan minőségben, hogy ne kelljen állandóan új erőforrást tolni a sw alá.
-
-
#06658560
törölt tag
Nem, nem is arra reagáltam vele. Vagyis emlegetheted, csak relevanciája nem lesz semmi. Az, hogy nekem munkaeszköz, annyit jelent, nem otthoni bohócokodás szintjén kell vele foglalkoznom, és nem lesz elég az otthoni felhasználók tömegének elég funkció szint.
#231 hcl: például azért, mert ha marad is benne hiba, könnyebb kezelni, lehet vele dolgozni. A 3D render programok által generált háromszög alapú felületet meg csak kidobni lehet. Vagy referencia lehet komplett újramodellezéshez.
-
válasz
#06658560
#226
üzenetére
OK, akkor ha két profi CAD cucc is gyakran inkompatibilis, akkor miért nagyob baj, ha az egyik oldal free? Nem mindegy, miben vannak bajok?
S azért ezek csak megoldhatóak valahogy, hiszen szoktak cégek modelleket átvinni egyikből a másikba...Amúgy LOL : kerestem valamit, ami Linuxon DWG nézegető. Draftsight.
Nem nézegető, Autocad 2000 Egyedül az hiányzik, hogy mutattja a közeli pontokat, de az ikonok, parancsok, layout 90%-ban ugyanaz -
bambano
titán
válasz
#06658560
#228
üzenetére
"nekem ezek a szoftverek munkaeszközök": hogy emlegessem az eredeti problémát: elfogadjuk, hogy neked ezek a szoftverek munkaeszközök, ebből kötelezően következik, hogy mindenki másnak is azok?
ez kb. az az állítás lenne, hogy ha te vega vagy, akkor senki nem ehet húst.
-
Apollyon
Korrektor
Az igény egy eléggé relatív dolog.
Pl. az office felhős funkciója biztonsági szempontból mennyire épkézláb megoldás? Persze oké, nyilvános dolgokra teljesen rendben van, de nem publikus céges dolgokra nem igazán.Az meg egy másik dolog, hogy pl. az office is bloatware, de ott se lehet kikapcsolni egy csomó mindent, és ha nem használok X funkciót, meg nincs rá szükségem, akkor is ott dekkol a programban és be kell tölteni minden indítási alkalommal. De persze arra nincs igény, hogy kikapcsolható legyen. Ezért meg amikor betölt, eléggé laaaaaaaaaaaaaassssssssssssúúúúúúúúú.
Még egy SSD-s, csilliógiga ramos gépen is. Nincs igény = szívjon mindenki, persze nem szánt szándékkal, mert meg lehetne ezt okosabban is oldani, gyorsabban is, csak az embereknek elképzelésük sincs, hogy ha lenne rá igényük ("neadjég" gyártanának rá igényt), akkor valóban el is készülne az ilyesmi.Amiket te írtál az eléggé rétegigény egy átlaguser által használt szoftverhez képest. Ott mondjuk elhiszem, hogy nincs erőforrás jobbat írni, csak éppen nem ez a minta, hanem a windows és az arra írt, mindenki által ismert és használt átlagfelhasználói szoftverek a minta. Ennek megfelelően alakult ki egy valamilyen elvárás, amit vagy teljesítenek, vagy nem, legyen az az elvárás bármilyen alacsony.
-
válasz
Apollyon
#229
üzenetére
> a bloatware szoftverek nagy része zárt, fizetős stb.
Ezt hogy szamoltad ki?
Egyebkent elmondom, miert tunik igy. Azert, mert az enterprise kovetelmenyek _nagyon_ kacifantosak. Csomo egyszeru ingyenes szoftver a felhasznalok 80%-anak lefedi az igenyeit kb. 80%-ban. Ez tok jo, gyorsak, egyszeruek, szeretjuk oket. Viszont amikor egy enterprise-ban a felhasznalok 99%-anak kellene lefedni az igenyeit 99%-ban, akkor elszall a komplexitas. Ez az, amiert az enterprise szoftverek bloatnak tunnek. Az a bloat az, amiert fizetnek, mert azt a nehez megcsinalni.
Pl. en dolgozom klinikai rendszerekkel is. Csunyak, bloatok. Egy szep modern apphoz vagy websitehoz kepest minden bajuk van. Ja, de ha populacioszinten akarsz szolgaltatast nyujtani, es kb. senkit nem hagyhatsz ki, akkor ugy kell webappot csinalni, hogy
- IE8-at is tamogatsz
- muszaj, hogy gyengenlatok es vakok is hasznalhassak
- muszaj, hogy gyenge hardverrel rendelkezok is hasznalhassak
- nem csinalhatsz ugy 2FA-t, hogy eloirod a mobiltelefonszamot vagy akar azt, hogy legyen okostelefonja az illetonek
- satobbiSzoval olyan kotottsegek vannak, amit rengeteg szopassal lehet csak teljesiteni.
-
Apollyon
Korrektor
válasz
#06658560
#228
üzenetére
Nem feltétlenül neked szólt, csak te is példálóztál vele, ezért neked jelöltem meg válaszként. Egyébként nem azt állítottam, hogy a profi szoftverek mindegyike bloatware, hanem hogy a bloatware szoftverek nagy része zárt, fizetős stb.
Persze openszósz oldalon is megvannak a gigagáz dolgok, pl. a komplett Android úgy ahogy van (beleértve AOSP-ot is) bloatware. -
#06658560
törölt tag
válasz
Apollyon
#227
üzenetére
Nem én hoztam fel, de ez a vonal is említve lett. Tudsz amúgy mutatni valami bloatwaret egy CATIA, NASTRAN Creo esetében?
Hogy kiegészítsem: nekem ezek a szoftverek munkaeszközök, nyitott vagyok alternatív megoldásokra, de munkában az ügyfél mondja meg, mit követel, nem én verem az asztalt, hogy használja ezt vagy azt. -
Apollyon
Korrektor
válasz
#06658560
#226
üzenetére
Tökjó egyébként, hogy amikor feljön az openszósz meg egyéb nem windows-related szoftver téma, akkor mindig előkerül a kad, pées és társai mint ütőkártya, merthogy ezek profi szotftverek rakás pénzért, a többi meg szar és semmire se jó.
A hír egyébként meg arról szól, hogy mivel a hw gyártók bénáznak / vagy egyéb tech. akadály van, nem lesz extra hw teljesítmény, szóval esetleg kéne optimalizálni is, már ha lehet, különben adott szoftver megkapja a bloatware címet.Amúgy tök érdekes az is, hogy a bloatware szoftverek többsége általában nem openszósz, hanem éppen fizetős, meg "profi" szoftverek. Hoppá...
-
#06658560
törölt tag
Az, hogy olvassa, vagy hogy lapátolja bele egyik vagy másik szoftver az adatot, nagyon nem mindegy. Például a lent már emlegetett Blender és társai hiába tudnak CAD kompatibilis kimenetet, az használhatatlan bármi másra. Been there, done that shit. És még két CAD szoftver között is lehetnek gondok, de akár ugyanazon rendszerek közötti semleges formátum használatával is.
-
Értsd rá : Pont arról szól a cikk, hogy manapság egy egyszerű irodai gépbe brutál számítási teljesítmény kell, kb. a semmiért, mert nincsenek optimalizálva a szoftverek. Akkora baromba puffadt programokat kell futtatni, mint a ház, és akkor az csak egy szövegszerkesztő. Atom pazarlás.
"Nos igen, ez már hitvita kérdése. Nekem például nem fáj, hogy olyan tudást adnak a gyerekeknek, amire a piacon igény van. "
Nekem is inkább az, hogy azért van rá igény, mert semmi konkurrencia nincs, mert senki nem is tudja elképzelni, hogy léteznek más oprendszerek.
Na most egy bármilyen ökoszisztéma (és piac) halála, ha nem változatos. -
válasz
Apollyon
#216
üzenetére
...az optimálisabb, nem ms-alternatívák viszont nem.
Mi az, hogy optimálisabb nem MS alternatíva? Ha kicsit visszalapozol, akkor kiderül, hogy munkaeszköz esetén nem nagyon van ilyen.A gyerekek elé már általános iskolában is windowst raknak ms-office-szal...
Nos igen, ez már hitvita kérdése. Nekem például nem fáj, hogy olyan tudást adnak a gyerekeknek, amire a piacon igény van. Az álláshirdetések 99%-ában pedig MS Office programcsomag használata szerepel, már ahol ez releváns tud lenni.(#217) hcl
Nézd, amelyik gép erőforrásait egy MS Word ki tudja akasztani, az szerintem egyébként is csereérett. És megfordítva, senkinél sem az MS Word erőforrásigénye a szűk keresztmetszet, illetve nincs valódi igény a gyorsításra. Akkor már inkább a mindenféle webes tartalmak zabálják az erőforrást. Tehát ez fikciós kijelentés a részedről. -
-
-
-
Mind a kettő arra való, hogy szöveget lehessen vele formázni. Word esetén konkrétan oda is gépeled, de ennyi erővel a *tex forráskódot is lehet a standard inputról bevinni, csak nem kényelmes
@Kisgépkezelő : Még ha tudná, de ha voltál már user supportos, tudod, hogy ahhoz is olyan hülyék tudnak lenni az emberek, hogy még
@Tapsi : Pl. azt érdekli, aki vehetne olcsóbb gépet, mert kevesebb erőforrás is elég lenne adott cucc futtatásához.
-
Apollyon
Korrektor
ms szoftver valamelyike szinte mindenhol elvárt / kötelező, az optimálisabb, nem ms-alternatívák viszont nem. A gyerekek elé már általános iskolában is windowst raknak ms-office-szal, szóval nem csoda hogy a többség ms függő lett. Aztán maga az ms sem izzad vért, hogy a termékei kompatibilisek legyenek más szoftverekkel. plusz <insert random ms evilness here>
-
-
-
> dropbox, onedrive, stb. az egyrészt nem előny
Sok embernek az.
> real time kollaboráció: az a sima word tud működőképes módon, vagy csak az office365?
Tud. Az Office365 az nem az online szoftvert jelenti egyebkent.
> ha te tudsz mondjuk egy c forráskódban change trackinget, akkor texben is tudsz.
Vizualisan? GUI-n? Anelkul, commitolni kellene, meg ilyesmi?
Szoval nyilvan nem, QED.
-
bambano
titán
latex forrás az egy ascii szövegfájl. ha te tudsz mondjuk egy c forráskódban change trackinget, akkor texben is tudsz.
online template: a tex tud rendes template rendszert, vajon a word tud-e? (hint: nem)
dropbox, onedrive, stb. az egyrészt nem előny, másrészt az fájlrendszer kérdés, menteni oda mentesz, ahova akarsz.
real time kollaboráció: az a sima word tud működőképes módon, vagy csak az office365? -
Oke. A Word masra valo, mint a Latex. Csomo dolog van, amit Worddel meg lehet csinalni, Latex-hel meg nem. Es forditva. Alma-korte.
Ha azt gondolnad, hogy a Latex mindenre alkalmas, amire a Word, akkor siman ignorans idota lennel, de gondolom nem vagy az, szoval nem gondolod ezt.
-
bambano
titán
ezt írtad: "Mint minden egyéb komoly hozzáadott értéket tartalmazó eszköz esetén."
A "minden" kvantor negáltja a létezik kvantor, vagyis ha tudok legalább egy alkalmazást, amelyik cáfolja az állításodat, akkor az állításod hamis.
másrészt meg attól, hogy egy ellenpéldát írtam (mivel matlog szerint elég egy is), még van több.
Amennyiben egy pongyola megfogalmazás (bárki is írta) rossz fényben tünteti fel a szabad szoftvereket, meg fogom cáfolni. eddig is megtettem, ezután is meg fogom.
szerk: egyébként az, hogy az ipar mit használ vagy mi van tömegesen elterjedve, kb. nullát jelent komoly hozzáadott érték szempontjából. itt van példának a word. elterjedt mindenhol, mégis mennyit is ér minőség szempontjából a latex-hel szemben? nullát.
-
Értsd már jól, könyörgöm! Ki beszélt itt szerver alkalmazásokról?
Amúgy zseniális, hogy belinkelsz egyetlenegy CAD alkalmazást, miközben mindenki tudja, aki képben van, hogy az iparban az Archicad, Autocad, Catia, Proengineer, Solidedge, stb. használatos. Mind-mind keményen fizetős. Sőt, ezek az iskolai tananyagok.
-
bambano
titán
[link] "Trusted by U.S Military
BRL-CAD is choice of U.S Military. For more than 20 years, BRL-CAD has been the primary tri-service solid modeling CAD system used by the U.S. military to model weapons systems for vulnerability and lethality analyses."a linux kernel az "minden egyéb komoly hozzáadott érték"? és a postgresql? az apacs? a komplett java ecosystem? az aosp?
-
"hogy ha szazan veszik meg, akkor nem ugyanaz lesz a szoftver, mint ha ezren."
Ebből a szempontból mi a különbség a warezolás és az alternatív szoftver használat között?
Amióta linuxozom, és pl. Gimp-et és ingyenes RAW konvertereket használok PS helyett, egy csomó ismerősnek ajánlottam ezeket, és segítettem nekik elindulni vele. Volt köztük olyan, aki korábban előfizetett PS-re és LR-ra, de mivel nem használta ki őket, beállt a Gimp-ezős és Raw Therapee-zős ismerősök közé.
Törvényesen jártam el, de mégis anyagilag rosszul jár emiatt az adobe. Hol az igazság?
-
Persze, ugyan annak a szoftvernek a kifejlesztese ugyanannyiba kerul, csak ott a problema, hogy ha szazan veszik meg, akkor nem ugyanaz lesz a szoftver, mint ha ezren.
A Makitat egyszer legyartod, aztan el is felejted, a szoftvert supportolni kell folyamatosan, szoval ez a resze kb egal.
-
Mellékállásban segítek be ebből élő volt kollegáknak. Tehát keresek vele pénzt, de nem ez a fő forrásom.
Ki tudnám termelni a fizetős szoftverek árát, csak nem akarom. Inkább egy részét odaadom fakultatív módon a nyílt szoftverek fejlesztőcsapatának. Az említett hármasnak (is) rendszeres támogatója vagyok.Ha főállásban csinálnám, akkor is simán elég lenne ez a három progi. Persze, nem tudnék velük komoly filmes projectekbe bedolgozni főlegkompatibilitási okok miatt, de reklámokba, meg játékokba, ahol termékfüggetlen a leadási formátum, oda hibátlan.
-
Más a kettő - legalábbis gyakorlatilag - mivel ugyanannyiba kerül a szoftver kifejlesztése, ha 100-an, és ha 1000-en veszik meg. A makitát meg pénzbe kerül gyártani is.
Erkölcsileg persze ugyanaz; mindkettő lopás.Mondjuk én sokkal inkább az ingyenes alternatívák felé mennék, mint a fizetős szoftverek felé, de ez más téma.
-
Béééla
őstag
válasz
janeszgol
#179
üzenetére
>drága a 18 ezres játék, ne legyen több
Persze hogy az, ha a végösszeg 100 ezer forint felett van mert egy teljes árú játéknál úgy kell fizetni, mint a mobilos free2pay szutyoknál hogy haladj! (a 2018-as kosaras EA lehúzás valami 120 ezerre jött ki?)
Azt meg felejtsük el, hogy a warez visszaszorulóban van? Amióta egy játék crackelve és offline játszva a felét se nyújtja, egyre inkább megveszik, na meg egyre több emberhez tud eljutni! Mindig mondom, hogy tessék jó játékot írni, és akkor a megjelenés napján visszahozza az árát, mint a gta 5!Az ablakos oprendszer kalózkodása azért dívik, mert nagy cégeknek (vagy konkrétan a tisztaszoftver keretein belül) évi egy bigmekk áráért jár a windows és office, de otthonra hülye leszek magamnak 50 ezret adni csak a windózért! (kösz schawo a licenszekért ;) ) Ha a home usernek is adnák ennyiért, minden gépemre külön előfizetnék!
Egy CAD megint más, kis cég vagy EV nem engedhet meg mindent magának sajnos és sokan úgy gondolják, hogy akkor majd a virágbolti licensz lesz a megoldás. (téves út) -
janeszgol
félisten
Az biztos, hogy nagyon pazarlón, ugyanakkor spórolósan is bánnak a hardverrel. Ma már egyértelműen szoftverkrízis van. Van jó hardver, szóval át kell gondolni a programozást.
De ennek az is az oka, hogy senki nem akarja megfizetni azt, amibe ezek kerülnek. Legyen olcsó, majd lewarezolom, drága a 18 ezres játék, ne legyen több (amikor már 5 éve is magasabbnak kellene lennie), meg egyáltalán a szoftver nem érték, mert csak a munkámhoz kell, meg csak kipörgetem a játékot és kész.És akkor elindul a költségcsökkentés. Nem kell bugreport, még ezt tegyük be, persze plusz pénz nincs, inkább legyen ez, meg az, persze plusz pénz nincs stb.
-
#176
Peter Kiss
őstag
Bici
#172
Peter Kiss
őstag
Ha gyengék az emberek, akkor megérdemlik.
Azt is sokan elfelejtik, hogy hülyéket nem kellene felvenni, értelmetlen, fogyatékos embereket nem kellene lead pozícióba rakni (hogy aztán maguk fajtát interjúztassák és vegyék fel)... Kompetencia alapján kell felépíteni a hierarchiát, és akkor lehet az bármekkora, viszi.
A példában sem alapból a menegement a köcsög, mindenki magával szúr ki először, aztán mellette ülővel.
Nyilván az fontos fent mindig, hogy gyorsan sok pénz szakadjon le, de ezt kellene ellensúlyoznia mindenkinek azzal, hogy igenis odapakolja magát; ha kell, akkor kihajtja a belét, ha kell, nemet mond a faszságra. De nem, ettől sokkal könnyebb ignorálni meg hisztizni, panaszkodni. -
floatr
veterán
A nodejs runtime az ami a nyers logikát futtatja egy alkalmazáson belül. Ha egy alkalmazás egyszerű feladatokat old meg, akkor teljesen rendben van. De ha a JS kód komplex, akkor a runtime által fordított kód nem lesz elég jó. Ahhoz képest a JVM JIT is jobb. Akkor is gond van, ha egy felhasznált lib nagyon összetett JS kódot tartalmaz. Ez persze nem olyan orbitális baj, mert a jellemző felhasználás esetében egy nodejs app jobban skálázódik, mint egy java
-
cog777
senior tag
A vitakeszseg arrol is szol, hogy tiszteled a vitapartnered anelkul hogy emlegetnel "hulye" es "idiota" szavakat.
Amugy en nem magyarorszagi szemszogbol mondtam amit, en mar regota nyugaton dolgozom. Es ott bizony fontos a referencia. Pl UK-ban anelkul nem kapsz allast. Presze sokszor nem hivjak fel, de ha ugy adod be az oneletrajzod hogy nincs egy fia referencia sem az elmult 5 evbol, akkor elgondolkodnak.
A hozzaszolasod magyarorszagi vonatkozasaival egyetertek, en is tuloraztam anno eleg sokat, de nyugaton ez nem jellemzo. Nalunk nagyon ritkan van tulora,de az onkentes es azt busasan kifizetik. Ja, es senki nem nezi hogy a 7 ora munkaidot te ott toltotted-e tenylegesen vagy otthonrol dolgoztal.
Latom hogy m.o-i szemszogbol kommentaltal en viszont europai nemzetkozi piacot figyelembe veve - leven hogy ez nemzetkozi tema - igy a kommented nagyobb resze irrelevans a valaszomra."Márpedig a tarthatatlan határidő az akadályozza a jó munkát. " Terulettol fuggoen de pl egy termek fejlesztese ugy indul, hogy a reszvenyesek penzt adnak. (tekintsunk el az m.o-i belterjes piactol)
Ha csuszik a projekt, akkor konnyel lelohetik az egeszet. Ergo a menedzsment szereti ha koran van egy mukodo verzio es fokuszalnak a funkcionalitasra. Terulettol fuggoen tolodhat ez at a minosegre is. Pl ipari teruleten az ugyfel szereti ha nem crashel a cucc mert az neki idokieses, de mobil es jatekfejlesztes teruleten altalaban alacsonyabb a minoseg.Szoval mit jelent a jo munka? Optimalizaltsag? Jol fusson, keves memoriat fogyasszon, ne crasheljen? Ezek igen jol osszekeveredtek ebben a forumban, viszont ezek a kovetelmenyek ellentmondoak. Jol optimalizaltsag ellene dolgozik a karbantarthatosagnak. Tehat uj funkciok hozzaadasa sokkal nagyobb rizikot jelent.
En pl a stabilitast es a karbantarthatosagot szoktam szemelott tartani, mert ha a markolo vagy furo vezerloszoftvere crashel mukodes kozben az igen nagy gaz. Letojom hogy tudnek meg 10% cpu hasznalatot nyerni, majd a telemetria kihozza a teszt kozben, hogy bizonyos muveleteknel nincs eleg eroforras es szepen kiprofilozzuk.
A "jo munkanak" igen sok lehetseges definicioja van, persze az latja ezt igazan, aki reszt vett mar egy tobb eves termekfejlesztesben ahol raadasul 10+ eves kodok is akadnak.
-
#172
Bici
félisten
Peter Kiss
#170
válasz
Peter Kiss
#170
üzenetére
Ez csak kisebb csapatokban megoldás, vagy egyszemélyesen, vagy akkor, ha te vagy a csoport vezetője, és mögéd áll a többi.
Egy nagyobb csapatban én még nem láttam akkora egységet, amit a vezetőség 1on1 beszélgetésekkel ne tudott volna megtörni. Ha pedig felmondasz, akkor a következő helyen is ez lesz, legfeljebb nem annyira.
Én a webes szoftverek területén tapasztalom ezt, de lehet, hogy máshol máshogy van.
-
#170
Peter Kiss
őstag
Bici
#149
Peter Kiss
őstag
Megoldás: bambano #159
-
Silεncε
őstag
A jelenlegi meg egy vicc, f0sbook egy kétmagos, 2,5ghz körüli , 4GB RAM-os izét felzabál? A Gmail új felülete olyan tetű, hogy elunod az életed egy átlagos gépen? Ezért nem lesz kár. Tudtak ezek az oldalak gyengébb hardveren gyorsabban is működni, amíg nem volt teletömve mindennel. - Hát igen, üdvözöllek a mindenkitudjavascriptbengányolni korban. A YT-n ott a polymer (bár ezt még meg lehet kerülni kis hackeléssel), az FB oldalán meg gondolom százával futnak az analitikák. De ugyanez az Angular is, vagy mobilon akár az Ionic, desktopon meg barátjuk, az Electron (mindhez van szerencsém nekem is....). Nincs ezekkel baj, csak olyan mennyiségű plusz erőforrást igényelnek az egyszerűbb fejlesztésért cserébe, ami borzalmas. De nem baj, programozzunk JS-ben mobilappot, mert az gyorsan elkészül
-
bambano
titán
látom, a magyar irodalom, az írói eszközök, a hasonlat és hasonlók neked kimaradtak.
A vitakészség (merugye egy szó) nem arról szól, hogy jön a sok hülye managga az idióta határidőivel, és ezt minden programozó szó nélkül benyeli. A vitakészség (esetleg csapatmunka) pont arról szól, hogy az egyik fél jelzi, ha olyan akadályba ütközik, ami a jó munkát akadályozza. Márpedig a tarthatatlan határidő az akadályozza a jó munkát. Az a kizsákmányolás, ami a múlt évtizedben a szűkös munkakínálatos piacra volt jellemző, ma nem tartható a vállalatok részéről, mert munkaerő hiány van. Tehát ha egy vállalat hajlandó egy csomó mindent megtenni a munkaerő megtartásáért, akkor azt is tegye már meg, hogy nem égeti ki a munkaerőt folyamatos túlóráztatással. Mert amíg 2009-ben ebbe belepusztultak, ma két perc alatt szedik a sátorfájukat és továbbállnak.Ez nem az én teóriám, ezt zengi a komplett hr szektor mostanában és ezt mutatja az is, hogy az elmúlt időszakban példátlanul sikeres sztrájkhullám volt. Meg az is, hogy a jobb élet reményében sokan kimentek nyugatra.
Én tökre csapatmunkaprojektorientáltvitaképes vagyok, csak már túl öreg vagyok ahhoz, hogy hagyjam magam kizsákmányoltatni. 8 órát fizettél a szerződésben, akkor 8 órát kapsz, utána nekem fel is út, neked meg le is út. Ha te egy managga vagy, nyugodtan elémállhatsz, jogszabályt is pontosabban ismerem, mint te, menedzsment elméleteket is többet ismerek, mint te, megeszlek reggeli elé előételnek.
Egyelőre a legjobb helyen dolgozom, ennél nincs feljebb. De ha mégis, mit fognak írni a referenciába, és azt te hogyan fogod értelmezni? tudnék sztorikat mesélni...
"Kicsit kevesebb erzelemmel es tobb esszeruseggel tobbet el lehetne erni.": az nem eléggé több ésszerűség, hogy rákényszerítek egy főnököt a munka törvénykönyvének megtartására? ha ez nem ésszerűség, akkor mi az?
-
Én is azon a véleményen vagyok a cikk után, hogy majd szépen érték lesz az optimalizálás újra.
Ha egy 8086Corruption-t, 8086Domination-t meg lehetett írni, akkor mindent is meg lehet A kényszer a legnagyobb úr. A jelen állapotot az okozta, hogy minél gyorsabban kellett fejleszteni, így elharapódzott a "majd a hardver megoldja" szemlélet. Ha ez nem lesz, akkor az lesz majd előnyben, akinek gyorsabb a cucca - gondolom lesz majd egy lufi, amikor az egekbe szökik a programozás ára, de aztán újra érték lesz az optimalizát, stabil kód. (Ennek a "képezzünk át bárkit is programozóvá" kényszer nem barátja. Alapok nélkül senkiből nem lesz jó szakember.)A jelenlegi meg egy vicc, f0sbook egy kétmagos, 2,5ghz körüli , 4GB RAM-os izét felzabál? A Gmail új felülete olyan tetű, hogy elunod az életed egy átlagos gépen? Ezért nem lesz kár. Tudtak ezek az oldalak gyengébb hardveren gyorsabban is működni, amíg nem volt teletömve mindennel.
-
con_di_B
tag
Fuhh, én inkább azt mondanám, hogy ez a fórum máris remekül reprezentálja, hogy nem egy helyen van gond ebben az iparban. (Bocs, ez hosszú lesz.)
Kezdjük azzal, hogy a valóságban nincsen egyöntetűen elfogadott, vagy elfogadható definíció arra, hogy milyen az a program, ami "nem kókány". Eleve meglátszik, hogy ki milyen példákat hozott fel hibákra, az sem vágott egybe már eleve, van aki az optimalizáció hiányán tépte ki a haját, van aki a biztonsági hiányosságokon, van aki azon, hogy a megvalósitott funkciók végül nem feleltek meg az üzleti igényeknek a gyakorlatban.
Kezdeném az optimalizációval, mert hozzám ez a része áll legközelebb - meg a cikk is erről szólt. Ez általában nem csak azért marad ki, mert explicite nincs rá igény, hanem mert végtelenszer könnyebb működő kódot TALÁLNI (nem írni), mint optimálisat, ergo én itt a "programozó a hibás" tábort erősíteném. Két rétegét különíteném el az optimalizációnak, az egyik az algoritmikus és adatszerkezet, a másik az implementáció tekintetében történő (alacsony szintű kódolás).
Az algoritmikus optimalizáció adja az eredmények oroszlánrészét, és ez egyben ez a legkevesebb munka is, feltéve, hogy az ember ismer algoritmusokat. Ha van valami épkézláb sejtésünk arról, hogy adott adat írva/olvasva/keresve/rendezve lesz-e legtöbbet és hogyan, márpedig ha nincs, akkor általában van kit megkérdezni, akkor jó eséllyel tudunk elsőre is épkézláb döntést hozni, hogy az adott nyelven/platformon elérhető, már eleve implementált algoritmusok és adatszerkezetek közül melyiket kellene használni. És ehhez nem kell mély, "egyetemi szintű" tudás, ez pont az a műfaj, ami jóeszű középiskolásoknak is érdekes lehet, és nagyjából ki is tudják "maxolni". Nem programozóknak is egyszerűen elmagyarázható, hogy a hatékonyabb algoritmus azt jelenti, hogy tízszer annyi inputot mondjuk ne százszor annyi idő legyen feldolgozni, és utólag meglepődni, hogy hoppá, ez nem skálázódott, hanem kevesebb. Ugyanígy a párhuzamos skálázódás is általában jól érthető. És tényleg senki nem csap a kezedre, ha nem rontod el izomból.
A második lépés, a kód optimalizálása, de erre profilozás nélkül eleve nem tudhatjuk pontosan, hogy mekkora szükség van, melyik részen, és, hogy őszinte legyek, ez az a műfaj, amit a gyakorlatban az iparban használt fejlesztési terminológiák, eszközök, nyelvek és emberek a lehető legkevésbé sem támogatnak. A gyakorlatban ez a műfaj a C/C++ (Fortran is él ám még!
) világra korlátozódik eleve, magasabb szintű nyelveken élből sokkal nehezebb olyan kódot írni, hogy pontosan tudjam, hogy mi fog történni futásidőben. Én magam például nagyon szeretek Python/numpy vonalon prototipizálni, de nem hiszem, hogy egyáltalán képes lennék ténylegesen gyors kódot írni így, még valamilyen előfordítós trükkel sem. Az olyan kód, főleg GPU-n, amire meg én mondanám azt, hogy ez igen, az meg van írva rendesen, mert látom, hogy pontosan hogy néz ki a memóriaelérés, mikor mi lesz melyik gyorsítótárban, miből mi fog lefordulni gépi kódba, hol lesz a szűk keresztmetszet, az sok más szempontból biztosan kiverné a biztosítékot a legtöbb "normális" programozónak akik az éppen sláger best practice-eknek él, pl. mert:
- egy függvény nem három sor, hanem akár több száz is, mert így optimális
- az adatszerkezetek terén nem feltétlenül az van együtt, ami logikailag egybe tartozik, hanem inkább az, aminek egy-egy kritikus pillanatban hasznos, ha egyszerre vannak a memóriában
- ennélfogva a modularizáció és a kód maga is "átláthatatlan spagetti"
- mivel a unitok nem azok, amit gondolnál, ennélfogva unit teszteket sem fogsz rá írni
- de legalább ha megpróbálnád, akkor meg szívnál, mert az arc aki ilyen kódot tud írni lehet h egy délután refaktorálja az egészet fejjel lefelé +2% gyorsulásért, és kezdheted előlről - ő maga jellemzően nem ír teszteket, mert nem szeret, és mert soha senki nem fogja ezért letolni, mert amit ő tud azt nem tudják mások.Hosszú sztori röviden: nem akartok ti ilyen értelemben optimalizált kódot látni. Én pedig nem tudom, hogy Linus erre gondolt-e, valószínűleg igen, mert neki ilyesmi a háttere személy szerint, de szerintem amiben még igaza is van biztosan, az az algoritmikus része, és ez a nagyobb baj.
Biztonság: Kb. 13+ év tapasztalattal és eléggé sikeresnek mondható karrierrel a hátam mögött, néhány alap dolgot leszámítva, mint memória inicializálás, meg, hogy ne legyen túl egyszerű puffer túlcsordulást előidézni kívülről nincs ám túl sok fogalmam arról, hogy mit kéne csinálni ahhoz a kód szintjén, hogy valami biztonságos legyen. Ezeken kívül ha az analízis tool rácsap kezemre, megnézem mi baja van, valamekkora eséllyel nem röhögöm ki, h nem nyert, de ennyi. Nyilván iparág függő, de egyrészt bele lehet gondolni, hogy akkor az én műveim mennyire tele lehetnek "hibával", másrészt viszont amit én írok az eleve "mélyebben" van a rendszerben. Tehát ebből a szempontból (is) én például kókány kódot írok, d elegalább idővel sme lesz feltétlenül jobb a helyzet.
Végül pedig az üzleti igényeknek való megfelelés. Most viszont pont, hogy a tech-soviniszta oldalra fogok állni, de a lényeg annyi, hogy a valóságban nincsen az "üzleti világot a technológia világával összekötő" csodálatos tudás, aminek felkent birtokosai joggal vezethetnének programozókat. Nem, programozni tudni kell és pont, különben eleve nem tudod értelmesen specifikálni, hogy mi a munkafolyamat meg mik a követelmények. E mellé kell még tudni emberekkel is bánni, de még ha ez is adott, akkor is szökő évben egyszer fordul elő, hogy adott legyen a fogadó oldal arra, hogy egy technológiai innováció létrejöhessen. Eleve nem minden emberek által végzett munkafolyamat kellő mértékben algoritmizált, mert vagy eleve nincs folyamatspecifikáció, vagy van ugyan, de senkit sem érdekel, és helyette szájhagyomány útján vagy esetleg kihalásos alapon vannak dolgok amiket Gipsz Jakab szokott megcsinálni valahogy. Na mármost Giksz Jakabot lekódolni nem fogja tudni senki, főleg ha leginkább ötletszerűen csinálgat számára magától értetődő dolgokat. Te pedig ugye megkaptad a specifikációt amit Gipsz Jakab főnöke írt anno (vagy kirakták valami analystnek aki meginterjúvolt valakit), aki egyébként sem te, sem az ő munkáját nem tudná ellátni.
A valóságban ezek a keserű helyzetek általában mind megoldhatók, ha sikerül létrehozni a közvetlen forródrótot azok között, akik programoznak, illetve azok között, akik a programot használni fogják, effektíve kiiktatva a menedzsmentet, mint olyat a folyamatból, és önszervezőleg eljárni. Mivel ez értelemszerűen sérti az olyan emberek érdekét, akik pontosan tudják, hogy megfelelő kvalitások nélkül ülnek ott ahol, azzal, hogy demonstrálja, hogy nincs rájuk szükség, ezért ebből a verzióból még túl sokhoz nem volt szerencsém. De amikor igen, az nagyon jó, és még a végén jó dolgok is sülnek ki belőle!
Végezetül, a legfontosabb: az olyan ügyfél, aki pontosan tudja, hogy nem tudja mit akar, a valós lehetőségekhez képest ideális, mert az ad teret, h kitaláld neki, amire sajnos programozóként eleve csak te vagy alkalmas. Ennél sokkal rosszabb az az ügyfél, amelyik azt hiszi, hogy ő pontosan tudja, hogy mit akar, téged pedig azért tart, hogy lefordítsd azt neki gépi nyelvre.
Nem, nem tudja, és ez nem egy nyelvi fordítási probléma, az egy borzasztóan rossz hasonlat, ami sajnos megragadt az emberekben. Minden, ami a programozáshoz kell, az világos, racionális, emberi gondolkodás, nagyon gyorsan kell tudni lemodellezni dolgokat számokkal, utána pedig folyamatábrákat rajzolni, hogy mi legyen a számokkal. Ezek olyan dolgok amiket egyébként és kéne tudni többé kevésbé úgy 8 általános iskola után, csak ugye nem mindenkinek előnyös, ha a dolgok világosak.
Linus-ra visszatérve meg: semmi baj sincs, legalább megjobban felértékelődik majd a szellemi teljesítmény a szoftveriparban, márhogy a kókányoláson és copy-pastelésen túlmutató.
-
#25954560
törölt tag
ennek utana kellett olvassak, koszonom, hogy mondtad
mindig tanul az ember.
bar ha jol ertem, akkor nem csak arrol van szo h csillio futas utan meglepoen jo bytecode keszul, hanem jol is skalazodik a jvm.
hatekonysag szempontjabol pedig 'csak' hasznaljak a mindenhol mashol bevalt technikakat (nincs thread-valtas, nincs kernel hivas, nem hasznalnak lock-okat, es a kritikus fontossagu adatot a memoriaban direktben erik el, stb) viszont nagyon szep h mindez java alatt is elerheto, ertheto h a java produktivitasa mellett miert valasztjak ezt. -
cog777
senior tag
Jol erzekelem, hogy nincs valami kifinomult targyalasi technikad? :P
Tudod mi hianyzik a magyar oktatasi rendszerbol? A vita keszseg elsajatitasa, csapatmunka, project orientaltsag. Remek peldat mutattal...
Ha jo helyen akarsz elhelyezkedni (seniorhoz melto, csapatvezetoi, izgalmas r&d) akkor bizony kerik a korabbi melohelyek referenciait, amit megneznek hogy milyen lenne ha asztalt csapkodva hagytal ott...
Kicsit kevesebb erzelemmel es tobb esszeruseggel tobbet el lehetne erni.Amugy nalunk lehet nem vallalni melot, akkor megcsinalja mas, es te meg masmilyen melot kapsz. Tehat kb hatastalan a dolog.
-
bambano
titán
én pont arról írok, hogy ne tegyen bele többet.
ha egy szoftver kifejlesztésére kell egy év, akkor a tisztelt programozó csapjon az asztalra, ha egy évnél érdemben rövidebb határidőt akarnak behajtani rajta. akkor teszel bele többet, ha a szemét kód miatt olyan túlórákra kényszerülsz, amiért nem fizetnek. ezzel szemben ha kivered a balhét, hogy márpedig egy év az egy év, akkor szépen napi 8 órában fizetésért megcsinálod rendesen.tudom, hogy erre sokan mit fognak gondolni, válaszolni, de a helyzet az, hogyha soha senki nem csap az asztalra ebben a kérdésben, akkor a vezetés fejében benne marad, hogy jól van ez így. jelenleg a programozók munkaerőpiaca úgy áll, hogy egy kóder, aki már el tudja indítani az ide-t, azonnal kap állást, úgyhogy azzal se tudnak megfenyegetni, hogy ha nem vállalod, kirúgnak. kirúgnak, naés? neked lesz új állásod két nap alatt, neki meg -1 programozó. most vagy olyan pozícióban, hogy érvényesíteni tudod az érdekeidet, akkor most kell megtenni.
-
-
floatr
veterán
Egyrészt nem állami szektorról beszélek, másrészt bármikor fel lehet állni, de az ügyfél attól nem fog fizetni. Harcolni is lehet, de szerintem messze nem éri meg. Az a véleményem, hogy annyit kell beletenni mindenbe, amennyit ér, amennyit adnak érte. Lehet geekeskedni, meg 1337 klubot alakítani, de akinek nincsen napi 24 órája csak ezzel nyomorkodni (jópár évvel az egyemista kor után), az csak az ésszerűség határain belül mozog.
Persze kell érteni hozzá, meg jobbnak lenni, de ez is csak munka, és hibás elvárás mindenkin számon kérni, hogy sokkal többet tegyen bele "mer-ez-a-hivatáááás" -
bambano
titán
anno dolgoztam állami szektorban, közepesen pocsék állásban, céges autóval, stb.
mikor nekem olyat akartak letolni a torkomon, ami hülyeség volt (nem nekem, tényszerűen rossz lett volna mindenkinek, lehet, hogy törvénytelen is), kihajítottam a kocsikulcsot az asztal közepére. ebből megértették.
-
Nálunk általában az USA irodából jönnek ezek a változtatgatások, a felsőbb szintekről, és az itteni vezetés meg nem elég tökös, hogy ellentmondjon.
A demo nálunk nem csak a UI-ról szól, mert most pl. alig van UI a terméken, hanem arról, hogy az API megfelelően válaszolgat, stb. A kinti vezetésnek el lehetne adni, hogy nem működő dolgot demózunk (vagy nem demózunk, csakszóban elmondjuk, hogy hol tratunk), de az itthoni meg nagyon teker, és erőlteti, hogy az a valós legyen. Próbáltuk kijátszani, de mindig lebuktunk. Aztán az lett a vége, hogy az ebből fakadó komolyra forduló viták miatt szétesett a csapategység, páraknak sok volt így a stressz, és megtörtek.
A közös komponens lényege nálunk ez esetben az volt, hogy ne kelljen kükön hostolni valamit, mert a terhelés lazán bírta a meglévő, csak as funkcionalitása nem volt fasza. Ha ezt forkoljuk, akkor külön kellett volna hostolni, amt a devops-on keresztül megvétóztak volna, mert nem ez a cél.
Végül ezt sikerült megoldani teljesen saját komponenssel, de csak azt fogadták el érvként a vezetők (kint USA-ban), hogy lassítja a fícsörök feljesztését a folyamatos kompatibilitás fenntartása. De ehhez kellett másfél év.Szóval az én tapasztalataim nem azt mutatják, hogy az itteni vezetők egyértelműen rosszak, a kintiek meg jók, hanem azt, hogy egy csomó dologban nem értik a fejlesztőket a vezetők, sőt, gyakran ostoba szakiknak gondolják őket. Emiatt nem hallgatnak rájuk, mert "úgyis csak túloznak", "láttam, hogy működik, nem kell azt tovább javíytgatni", sőt, volt olyan, hogy egy régi C++-ban írt komponensen egyik fejlesztő szeretett volna javítani, stabilitás, és gyorsaság terén, és őt kiáltották ki lusta, buta kovkának, mert nem haladt az új fícsörrel eléggé.
-
-
strogov
senior tag
"A vezetőség az, aki az utolsó pillanatban meggondolja magát, hogy máshogy kéne, de több időt nem ad a rendes átalakításra."
Ez sok dolog miatt lehet, mindegyik management gond. Nekem volt szerencsém jó PM-mel dolgozni, így tudom milyen amikor a megfelelő ember végzi ezt a tevékenységet. Magyarországon lehet ilyen vagy ... hát a két kezem biztos elég lenne megszámolni őket. A többit egy forward robot, vagy lvl1 support helyettesíteni tudná. Nem véletlen, hogy várhatóan a középvezetőket túrja ki az MI elsőnek.
"A felsőbb vezetőség várja el, hogy a fejlesztés közben már rögtön az elejétől legyen demo, hogy hol tartanak a dev-ek, és a középvezető ba*sztatja a fejlesztőket, hogy legyen minél színesebb, szagosabb a demo mutatható funckinalitással, és ha a fejlesztőnek emiatt össze kell csapnia valamit, akkor utána nem kap időt rendesen megcsinálni"Erre eddig mindig külön feladatot indítottam, és sehol se várták el, hogy valós alkalmazás legyen. Volt olyan project-em ahol megcsináltam pár html oldalt, hogy mutogassák. Teljesen jó volt a feladatra, és senki sem gondolta úgy, hogy ez egy működő alkalmazás.
Nagyon régi UI fejlesztési elv, hogy ami nincs kész az vagy ne legyen ott, vagy mutassa, hogy
nincs kész. Különben félreértés lesz belőle. A "kirakok neked egy üres grid-et" mondat általában elég szokott lenni, hogy rövidre zárjuk a hülyeségeket."Szintén a vezetőség erőlteti azt, hogy a cégen belül egyszer már lefejlesztett komponenst minél több projecten használjanak fel, még akkor is, ha nem alkalmas mindenre"
Refactoring. Felveszed feladatnak, és megcsinálod jól. Aztán ha bárkit érdekel akkor megmutatod, hogy közös ősön vannak.
-
#146
Peter Kiss
őstag
Bici
#145
Peter Kiss
őstag
-
#145
Bici
félisten
Peter Kiss
#144
válasz
Peter Kiss
#144
üzenetére
Én eddig négy nagyobb, normálisabb melóhelyen dolgoztam, és mindegyik helyen az volt, hogy a vezetőség piszkálta a fejlesztőket, hogy engedjék már el a szőrszálhasogatást, ne tech-pornózzanak, hanem adják át a QA-nak a fejlesztést végre. Ha van bug, vagy lassú, majd ők kiderítik.
A QA-t meg azért piszkálták, hogy negedjék már ki a release-t, mert majd utólag megjavítjuk a kisebbeket.
Minden retro-n panaszkodtak, hogy szar így dolgozni, hogy nem csinálhatják meg rendesen.Persze, kivételek mindig vannak, de a nagyrészük az általam ismert cégeknél nagyon is akarna jobb minőségben dolgozni.
Volt olyan, hogy összebeszélt a QA és a DEV csapat, hogy felpontozzuk a jövőbeli feladatokat, hogy beleférjen egy kis refaktor. Sajnos, nem sokkal később az egyik QA-s lett a scrum master és ő köpött a PO-nak.
-
#141
strogov
senior tag
forumpista
#138
strogov
senior tag
válasz
forumpista
#138
üzenetére
Hasonlót akartam én is írni, úgyhogy +1. Ennyi kiegészítés csak:
"gyorsan futó kód meg a jó kód (karbantartható kód) két külön dolog, és bár van közös keresztmetszete, általában azt a legnehezebb összehozni."Ezt legfeljebb úgy érhetjük el mint a marshall kereszt metszéspontját. Az ilyen kód se nem gyors, se nem jól karbantartható.
Erőforrás probléma magyar legacy project-ben amihez hozzá kellett nyúlnom eddigi 20 év alatt szinte mindig DB oldalon volt. Teszteltek X rekordra, aztán 5-10 év alatt felhízott, és előjöttek olyan gondok amit újabb vassal nem lehetett kezelni.
-
Én sem a spagetti kódról beszéltem, hanem az optimalizálásról. Annak pedig nyilván vannak szintjei.
...és minél jobban kell optimalizálni, annál durvábban nő az extra fejlesztési igény
Persze, ez igaz teljesen zöldmezős K+F projektek esetén. De ez a fejlesztési projektek hány százalékát teszi ki? És hány olyat látni, ahol ismétlődő programozási problémákra ugyanazok a rossz megoldások születnek? -
-
#138
forumpista
aktív tag
ddaydome
#131
forumpista
aktív tag
válasz
ddaydome
#131
üzenetére
Kérdés ki mit ért optimalizálás alatt...
A többieknek:
Végigolvastam a topicot és tényleg a 10 millió szoftverfejlesztő országa vagyunk.Kapásból kb. 3-4 szál van összemosva:
vannak kókány és vannak jó programozók: ez egy szál (egyébként ezt a legkönnyebb szürni és megváltoztatni céges szinten, csak pénzkérdés)Gyorsan írható kód (nem keverendő össze a gyors kóddal): egy másik szál
Jó kód (ala clean kód): ez egy harmadik szál
Gyorsan futó kód: ez egy negyedik szál.
Ezeket nem ártana külön kivesézni és nem összemosni, mert például a gyorsan futó kód meg a jó kód (karbantartható kód) két külön dolog, és bár van közös keresztmetszete, általában azt a legnehezebb összehozni.
Mint ahogy van olyan programozó aki képes gyorsan kódolni jó és gyorsan futó programot, csak épp megfizetni senki nem akarja, ha van olyan aki gyorsan kódol sz@r de gyorsan futó programot.Hozzáteszem, ez az egész egyáltalán nem programozó specifikus dolog, biztos mindenki hallott már az intel procikat sújtó spectre meltdown stb hibákról. Semmi más nem történt, mint a gyorsaság oltárán feláldozták a biztonságot.
Ezzel az Intel egy évtizedre lezúzta az AMD-t, a managerek évekig nyaraltak a bahamákon a bónuszokból, és senkit nem érdekelt a userek közül hogy de az AMD procija biztonságosabb, hát ki nem sz@rja le.És ezzel meg is érkeztünk az ötödik szálhoz, miszerint welcome in the kapitalizmus. Mindenki gyorsan akar olcsót, hát meg is kapja a szemetet mindenki (szintén nem programozás specifikus dolog).
-
HDR123
tag
Én rendszeresen javítok 20-30 éves appokat. Ezek főleg irodai alkalmazások. Amit utálok, az az amikor valaki megírja úgy hogy 1 év múlva már nem is a cégnél dolgozik, csak összegány valamit. Elég sok appra mondta, hogy azt én nem javítom, csak újra írom. Egyszer visszaköszön ez a hozzáállás....
Mellesleg, rajtam kívül kíváncsi lennék ki ír fejlesztői dokumentációt.
-
ddaydome
senior tag
Sziasztok!
Lehet, hogy van ilyen, ha igen, akkor nem tudtam...😀
Van olyan, hogy pl. a Bethesda be dob egy olyat, hogy itt a mozgàsèrt felelős kód ès, aki megîrja a legjobb optimalizálást annak pènzt vagy melót ad? Szerintem az ilyesmi elősegítenè az optimalizálàst ès egyben feltàrnà a fejlesztendő területeket! -
#25954560
törölt tag
válasz
buherton
#107
üzenetére
ejgen, minel magasabb szintu a nyelv, annal jobban van elabsztraktalva a hardvertol, annal kevesebb beleszolasa van a programozonak a hardver kihasznalasaba.
ilyenkor jon jol az pl, ha python-hoz tudsz libet irni c-ben, vagy ismered a python mukodeset. de ha jol emlexem, java eseten is meg lehet oldani egy feladatot sokfelekeppen, neked jol kell tudnod valasztani a megoldasok kozul. bocs a pongyola fogalmazasert, nagyon regen nem foglalkoztam java-val.
vannak ugye nyelvek, amik nem kifejezetten a futasi sebessegukrol hiresek, cserebe viszont kenyelmes(ebb) a hasznalatuk, mert sokminden vagy le van implementalva bennuk hivhato modon vagy eleve hatterben megoldjak. de legtobb esetben mar a program tervezesekor amikor megvalasztod a programnyelvet, tudod h miert azt valasztottad. ritkan allsz neki gui-t irni asm-ben es ritkan csinal sokmillio pps csomagprocesszalast egy java program. akarsz memoria menedzsmenttel foglalkozni vagy eleg az automatikus garbage collection; figyelsz az adattipusokra vagy oldja meg neked a programnyelv; gyorsan akarsz kodot irni vagy gyors kodot akarsz irni; stb...
viszont barmit csinalsz, erdemes a programozasi nyelv erossegeit kihasznalni. celhoz az eszkoz.a brainf*ck-ot pedig eleve nem arra talaltak ki h maga a program amit irsz benne gyors legyen. csillio interpreter van hozza, kulonbozo sebessegekkel. egyebkent, mivel meglehetosen limitalt az utasitaskeszlete, szerintem elkepeszto gyors kodot lehetne generalni vele, ha megtalalod neki a megfelelo feladatot
-
Azt nem mondtam, hogy kókány módon... de a korábbi rétegek amikre építünk, már nem túl jók használhatóság szempontjából. Viszont olyan elképzelhetetlen, hogy nem készüljön el, vagy annyit csússzon...
-----------------------------------------------------------------------------------------
De egyébként nagyon tanulságos ez a topik...jó pár olyan hozzászólást látok, akiknek még halvány sejtelmük sincs a témáról, de azért jól megszakértik a dolgokat. Most már 10 millió szoftverfejlesztő országa lettünk. Kiváló eredmény!
-
Predatorr
őstag
Dehogy nincs. Hogy kis országunkban az emberek 3%-a sem indít hivatalos eljárást megkárosítása miatt, nem jelenti, hogy nincs bünti. Sokszor a jótállás betartását is jogi úton kell kikényszeríteni. A meghibásodás más dolog, mintha rossz/hibás az összes termék, mint az esetünkben említett processzorok.
bambano: Ezért szerepel MINDEN EULA-ba, hogy a szoftver "as is", azaz olyan, amilyen, nem reklamálhatsz miatta. (Marad az anyázás.) Próbálnának meg autót vagy mosóport így eladni. Egy ismerősöm szerint az a biztos, ha a programozókat odaültetik a felhasználó mellé, aki minden apró bosszankodásnál jól pofán vághatja őket. Szerinte nagyon hamar megtanulnának jó kódot írni.
-
-
bambano
titán
válasz
MrSealRD
#120
üzenetére
"És maradt 3-4 hónap a fejlesztésre, ami irdatlan kevés, sok kompromisszummal, de kb 1-2 hetes engedélyezett csúszással ment ki a világba a fejlesztés...": pontosan erről beszélek, mi történt volna, ha egy év múlva lesz kész a fejlesztés? semmi. a vezérkar hiába pattog, akkor se lesz kész hamarabb. ti vagytok a hibásak, hogy 3-4 hónap alatt elvégeztétek egy év munkáját, kókány módon.
-
Fidel76
tag
válasz
MrSealRD
#120
üzenetére
Szerintem a programozást egy idegen nyelvhez lehet a legjobban hasonlítani. Sok ember meg tudja szerezni, de mégis nagy a szórás, hatalmas különbségek vannak. Angol középfok és az anyanyelvi szint és már képes "angolul" is gondolkodni ha akar. És ugye az elején mondják, hogy tud angolul. Valahogy így kezdődik, hogy tud programozni. Mindenhol, munkában, sportban a leggyengébb láncszem határoz meg mindent. Szerintem a vezető dolga a "csapatban" felismerni az egyéni képességeket és úgy beosztani, optimalizálni. Ha ez már nincs meg, akkor nem a programozók hibájáról, képességeiről van szó.
-
CsabaZz
tag
EZ a valóság, amit leírtál. Persze a szakmában nem dolgozó "szakértők" könnyen bégetnek itt, hogy a programozók 99%-a alkalmatlan. Megnéztem volna a kivitelező csapat arckifejezését, ha a végső simítások alatt odament volna Eiffel, hogy "Szépnek szép, de inkább mégis legyen egy szimpla toronyház, meg tudjátok csinálni a holnapi átadásra?". Persze nem gányolva, mert akkor alkalmatlanok a feladatra, ezt innen a fotelból megmondom.
-
"ez explicit törvénytelen. tehát ha erre való hivatkozással akarnak bármit is tenni, közölni kell velük, hogyha következményei vannak a program által rögzített adatoknak, akkor a rögzítés tényének is következményei lesznek."
Erre van valami nyilatkozatuk személyesen valami adatvédelmi ombudsmantól...
"és ki mondja meg a záros határidőt egy olyan iparágban, ahol a projektek zöme csúszik?" Nézd, azt nem tudtam elérni, hogy a fejlesztők részt vehessenek az időbecslésben... Ki van adva, hogy élesítési dátum december 12. Akkor ez eddig kb annyit jelentett, hogy 1 év fejlesztési időből kb 6-7 hónapot vakarózott az üzlet, aztán további 1 hónapig összedobáltak valamit, mert szólva lett nekik, hogy ennyi idő alatt az IT nem fogja tudni megcsinálni. Aztán további 1-2 hónap mire az üzleti igényeket átfordították feladatokra. És maradt 3-4 hónap a fejlesztésre, ami irdatlan kevés, sok kompromisszummal, de kb 1-2 hetes engedélyezett csúszással ment ki a világba a fejlesztés...
Egyébként, néha van, hogy a fejlesztési vezető beül melléd pair programming módba aztán próbál "segíteni"
Nem akarom tovább részletezni, de szerintem besírnál ha látnád mi megy és megtudnád, hogy hol... egyébként ez nem az anyacégem...ez egy ügyfél ahol kint vagyok kölcsönbe...
Az anyacég az más, ott sokkal jobban mennek a dolgok...
-
-
bambano
titán
válasz
MrSealRD
#116
üzenetére
"Ezen kívül, van erre a célra megfigyelő szoftver...logolja a tevékenységed, screenshot...stb...": ez explicit törvénytelen. tehát ha erre való hivatkozással akarnak bármit is tenni, közölni kell velük, hogyha következményei vannak a program által rögzített adatoknak, akkor a rögzítés tényének is következményei lesznek.
"A feladattal nyilván záros időn belül végezni kell...": és ki mondja meg a záros határidőt egy olyan iparágban, ahol a projektek zöme csúszik?
-
"hogyan oldják meg, hogy te ne azt csináld, amit akarsz?"
Úgy, hogy van egy Sonar szerint 110 ezer soros monstrum. Át kéne tenni Java 11-re, meg az elavult függőségi viszonyokat újragondolni. A borzasztó common kódokat refaktorálni...stb. Hogy oldják meg? Úgy, hogy JIRA feladatban kiadják, hogy indul a következő termékhez kapcsolódó alkalmazás. Azt kell csinálni. Itt is van az első feladat... tessék... Kb. így csinálják.
ha nagyon sarkos vagyok. -
#113
#06658560
törölt tag
Necroman_Mk2
#94
#06658560
törölt tag
válasz
Necroman_Mk2
#94
üzenetére
Ami ráadásul még simán tartható is egy jó ideig, amíg 1 chip el nem éri a wafer méretét. Mert nem sűrűségről vagy teljesítményről szólt, hanem db/db-ról.
-
bambano
titán
válasz
MrSealRD
#109
üzenetére
nem nézhetem le a szakmát, mert rosszul járok, ha belenézek a diplomámba. ez nem zárja ki azt, hogy a szakmát művelők közül azokat, akik alkalmatlanul vannak adott helyen, ne nézhetném le.
"Szerintem ha fejlesztői státuszban nem nyögtél végig még egy néhány hónapos projektet, akkor nem tudod milyen szituációkról beszélek...": szerintem meg tudhatom. ismétlem magam: nem csak fejlesztőknek adhatnak hülye utasítást a főnökök.
"Szerintem itt össze vannak mosva dolgok": szerintem is. ti programozás-technológiai oldalról akartok megközelíteni egy menedzsment-emberi problémát.
"4. éve dolgozom legacy kódon és azóta nem sikerült elérni, hogy fejlesztői idővel, mint erőforrással megtámogassák a refaktort...": hogyan oldják meg, hogy te ne azt csináld, amit akarsz?
-
-
"nem kell elmennem fejleszteni ahhoz, hogy analóg eseteket tapasztaljak."
Ez úgy hangzik mintha kicsid lenéznéd a szakmát. Szerintem ha fejlesztői státuszban nem nyögtél végig még egy néhány hónapos projektet, akkor nem tudod milyen szituációkról beszélek...
"kérdés, hogy az a full isp menedzsment rendszer, amit írtam, "
Oké, de ezt hány user használja? Ki írja ki az igényeket? Ki validálja ezt? Ki készít feladatokat? Ki ütemezi a fejlesztést? Ki végzi az implementálást? Ki tesztel? Ki hagyja jóvá az üzleti oldalról?"akkor kitalálod nekik, helyettük."
Ugye most csak viccelsz... Ehhez nincs meg a jogköröd. Ezt vissza kell kérdezni az üzletről, hogyan legyen megcsinálva..."én voltam már olyan helyzetben multinál, hogy rám akartak erőltetni egy nyilvánvalóan rossz döntést a külföldi központból. "
Más környezet más működés... Én sem olyan fejlesztési irányokat határoznék meg mint amik vannak... de hát ez van."kizárólag rajtad múlik, hogy mennyire hódolsz be a főnöki hülyeségnek. kizárólag te döntöd el, hogy jobb fizető állásban maradni keserű szájízzel vagy jobb nyugodt álláskeresőnek lenni. A magam részéről határozottan a második, ha egy főnök nem tűri el, hogy a hatalmának vannak határai, akkor én nem dolgozom ott."
Szerintem itt össze vannak mosva dolgok. Az optimalizáció célját kell meghatározni. De amikor többen dolgoztok egy projekten akkor nincs olyan, hogy saját kód. Mindenki kódja van...hiába írsz te jó kódot, ha telibe fossa valaki más... vagy a te feladatod miatt kell olyan kódhoz nyúlni amit más írt és bottal sem piszkálnád... Ezért mondom, hogy amíg ezeket a konkrét helyzeteket nem tapasztalod meg első kézből, hogyan dobnak vissza javaslatokat amikkel próbálsz javítani a helyzeten... hát addig max csak fotelszakértő leszel.4. éve dolgozom legacy kódon és azóta nem sikerült elérni, hogy fejlesztői idővel, mint erőforrással megtámogassák a refaktort...
-
#25954560
törölt tag
en azt talalom problemanak, hogy nagyon sok szoftverfejlesztonek goze sincs a hardver mukodeserol. innen kezdve pedig nehez optimalizalni. "majd a fordito megoldja", peeeeeeersze. egyre ugyesebbek a forditok, ez nem ketseges, de mindent akkor sem tudnak, nem tudhatnak.
ha hatekony kodot akarsz irni, akkor eleve ugy kell nekiallni. a projekt vegen az optimalizalasra szant ido (ha nem vagtak le vegul a sok csuszas miatt) nagyon hasznos, de ha hirtelen talalsz benne 100% teljesitmeny-novekedest, akkor az eredeti kod nem jol volt megirva.
-
"Kérdés, hogy a fejlesztési projektek hány százalékára igaz az, hogy nagyságrendi eltérés van a jó kód és a rossz kód költsége között?"
Hogy jobb megvilágítsam azt, amit Emvy nem nagyon fejtett ki: szépen struktúrált, áttekinthető kódot írni nagyjából ugyanannyi meló, mint valami összegányolt izét. Általában ezt szokták érteni jó meg rossz kód alatt, viszont Torvalds nem erről beszélt, hanem arról, hogy nem lesz még gyorsabb processzor meg még több memória, hanem a meglévőből kell többet kihozni.
És ha már az a kérdés, hogy a jó, karbantartható kódnál mennyivel tart tovább olyat írni, ami jó, karbantartható ÉS gyorsabb ésvagy kevesebb memóriát eszik, ott már az a válasz, hogy jelentősen és minél jobban kell optimalizálni, annál durvábban nő az extra fejlesztési igény (aminek ráadásul egyre kevesebb lesz a hozadéka).
mindig tanul az ember.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Mondjuk eleve SM-ként így eljátszani a hitelességét.. Hát, nem tudom.
Új hozzászólás Aktív témák
- Eladó szép állapotban levő Lenovo Tab M8HD 3/32GB / 12 hó jótállással / gyári tartozékokkal
- Telefon felvásárlás!! iPhone 16/iPhone 16 Plus/iPhone 16 Pro/iPhone 16 Pro Max
- Azonnali készpénzes nVidia RTX 4000 sorozat videokártya felvásárlás személyesen / csomagküldéssel
- LG K61 128GB, Kártyafüggetlen, 1 Év Garanciával
- GYÖNYÖRŰ iPhone 13 512GB Starlight -1 ÉV GARANCIA - Kártyafüggetlen, MS3077, 100% Akkumulátor
Állásajánlatok
Cég: FOTC
Város: Budapest