Új hozzászólás Aktív témák
-
julius666
addikt
Nincs 2-3 nagysagrend kulonbseg, inkabb nehany 10%
2-3 valóban nincs, de nem is azt mondtam.

Azért a 10%, khm. Maradjunk annyiban, hogy kb. 1 nagyságrend, picit talán kevesebb, és akkor egyikünknek sem volt igaza: [link]néha pedig a JS kód C-vel kb. megegyező sebességet produkál
Néha a nagyanyám is használt német szavakat, mégsem tudott németül.

De persze, el tudok képzelni én is olyan szituációt, amikor akár gyorsabb is a JS, pl. jól vektorizálható műveleteknél, vagy amire van dedikált utasítás, ahol a JIT compiler ezt megtalálja, az i386-ra, -O1 fordított natív kód esetén a gcc meg nem.Csak abban a benchmarkban hiszek, amit én magam hamisítok.

-
julius666
addikt
Azért a szignifikáns gyorsulásokon már túl vagyunk, nem véletlenül nem olvasni mostanság már olyan cikkeket, hogy egyik-másik böngésző JS motorja mennyit javult sunspideren az új verzióval.
Kb. eljutottak oda, ahová értelmesen el lehetett. 1-2 nagyságrenddel a natív kódnál lassabb futásidő, ennél sokkal nem hiszem, hogy lesz jobb.De persze minek is, olyan projekteknél, ahová a nyelv való nem a runtime sebessége a szűk keresztmetszet, sokkal inkább a projektekre szánt idő és pénzkeret, az egy szálon való futás, illetve a klienseknél a tróger webes szabványok, amik annyira vackok, hogy JS-ben implementált iszonyat bloat frameworkok (jQuery, AngularJS, stb.) nélkül meg sem tud mozdulni kb. az ember böngészőbeli munkánál. Nagyjából ebben a sorrendben.
Szerveroldalon pl. nem tudok róla, hogy komolyabb sebesség problémák lennének, sőt, inkább ajnározni szokták a Node.js-t.
-
EnGarde
csendes tag
Ezt ismeritek?
https://remoteok.io/
Irány a világ, az "informatikus"-oknak (pontosan mi is az a programozó? azt is nehéz definiálni..) Magyarország már sokszor túl kicsi és kevés...az elavult társadalmi berendezkedésével, ósdi stílusú, képzetlen cégvezetőivel, hatalom- és pénzéhes, civakodó politikusaival.
-
-
mekker
őstag
Szerintem nem a magasabb szintű programozás miatt tapasztalunk júzer szinten egyre több pazarlást, hanem mert egyre több rétegben gyűlik egymásra a sok szemét kód, elavult dolog, nem szabványos API, és ezeket refactoringolják, bővítgetik, miközben még a visszafele kompatibilitásra is ügyelniük kell. Az új kezdet viszont általában kockázatos és költséges. És ahogy egyre összetettebb programokra van szükségünk, ez annál inkább kezd előjönni.
Pl. a Firefox Geckós motorja is élt már meg szebb időket, de most a Mozilla remélhetőleg szépen fejleszteni fogja az új böngészőmotorját , ami nem mellesleg szintén házon belüli Rustban íródik. Amíg meg épülget azt új motor, a Geckoval is kezdenek valamit, sőt a XUL-ról is lassan át akarnak állni valami standardabb dologra.
-
-
-
+1 az egész cikkre.
Nagyon könnyen megvezethető a közvélemény azzal, hogy nincs informatikus, mert az átlagember nem tudja, milyen területek vannak. -
CyberPunk666
senior tag
Szerintem magas szinten semmi értelme az assemblynek, mert nem fog olyan mélyre menni, nem is tud, hogy kelljen vagy ilyen aspektusból vizsgálja meg a dolgot.
Viszont Isten óvjon meg attól, hogy olyan beágyazott fejlesztővel kelljen dolgoznom, aki nem programozott uC-t assemblyben. Ezt kell tudni és nem csak szemléltetésként van az iskolában. Rendszeresen futok bele olyan dolgokba, ahol bizony jó látni, hogy mi van mögötte és miért. Oldottam már meg ezzel a tudással olyan problémát is, amin 2 napot ült két másik ember. -
"most ez megy a gyógyszerekkel. Ha valaki több okból is jár különböző orvosokhoz, akkor találomra adogatnak neki gyógyszereket és néha sikerül olyan kombinációkat kihozni, hogy rosszul lesz vagy megbetegszik tőle a páciens. .... Persze ez lehet az országra jellemző körülmények miatt alakul így."
Nem, így működik a háziorvos mindenhol. Van egy szűk információs réteg + a saját tapasztalatok, hiszen a panaszok alapján nem állapítható meg egyértelműen a betegség. Sőt igazából a legmodernebb műszerekkel is csak közelíteni tudják.
De persze ez a helyzet nem csak az orvos hibája, mert az emberek többsége sem akar életmódváltozást, inkább írjanak föl valami tablettát

-
mekker
őstag
válasz
Dr. Akula
#700
üzenetére
Arra céloztak, hogy nem feltétlen érdemes úgy optimalizálni, ahogyan azt te gondolod.
Egyrészt assembly betéteknek ma legfeljebb a beágyazott rendszereknél van létjogosultsága; villanyon/infón is egyre inkább csak szemléltetés gyanánt tanítják.
Másrészt a mai fordító programok is egyre okosabbak, ahogy már előttem leírták. Elég valószínű, hogy hatékonyabb gépi kódot csinál neked, mint te asmben, sőt talán még olyanokra is ügyel, hogy az elágazásokat optimalizálja, cache-tudatosan rendezze a ciklusokat, stb.Ma az a lényeg, hogy megírj valamit, ami működik, átlátható és karbantartható. Ha megvan a jó alap, akkor ami teljesítménykritikus pont, ott utána alkalmazhatod a részfeladatra a legkorszerűbb algoritmusokat, de továbbra is fontos, hogy követhető maradjon a kód, és az érthetetlen bonyolításokat hanyagolni kell.
Ha van egy sok 100 ezer soros projekt, amin egy csapat dolgozik, akkor ott az átláthatóság viszi előre a projektet, nem a szénné optimalizálás.
Azt is érdemes hozzátenni, hogy magas szinten nem a gépi kód szintű tötymötyölés teszi optimálissá a kódot, hanem az átgondolt algoritmusok.A DX/OGL-hez még annyi közöm sincs, mint a programozáshoz, de szerintem ott sem arról van szó, hogy sokkal alacsonyabb szinten programozzák le a játékmotort, hanem hogy lehetőséget ad a hw felépítésének jobb kihasználására, és kevesebb lesz a korlátozó tényező. Simán el tudom képzelni, hogy vannak mondjuk olyan bugok, vagy olyan overheadek, amik miatt még egyszerűbb is az új API-kat használni bironyos esetekben.
Minden a magasabb szintű programozás felé mozdul el. Vas van, az eredmény nem feltétlen lesz sokkal lassabb, és minek csinálják meg azt, amit már mások egyszer megírtak. Elég azt implementálni, mert időt-tudást figyelembe véve nem biztos, hogy érdemben tudsz jobbat tenni. Ha már játékipar - vajon miért van az, hogy a legtöbben licenszelt motorok felé fordulnak?
-
azbest
félisten
most ez megy a gyógyszerekkel. Ha valaki több okból is jár különböző orvosokhoz, akkor találomra adogatnak neki gyógyszereket és néha sikerül olyan kombinációkat kihozni, hogy rosszul lesz vagy megbetegszik tőle a páciens. Néha meg olyan dolgokat ajánlanak az orvosok, amiről egy átlagember is megtudhatja kis utánakereséssel, hogy kuruzslás vagy legalábbis semmi orvosi alapja nincsen. Persze ez lehet az országra jellemző körülmények miatt alakul így.
Nemrég nagybátyám kapot olyan gyógyszer kombinációt, hogy egy harmadik orvás a kontroll alkalmával mondta, hogy azonnal hagyja abba a szedését, mert a másik betegségét súlyosbítja. Nem szabadott volna azt felírni számára. Nem emlékszem, hogy meg akart vakulni valami szívgyógyszertől vagy a szívét akarta kicsinálni valami szemgyógyszer. A lényeg, hogy nagyobb baj lehetett volna az orvosok figyelmetlenségéből és a jelentkező tünetek figyelmen kívül hagyásából.
-
proci985
MODERÁTOR
orvos pláne. minek annyit magolni, hagy egye csak a gyógyszereket a beteg, mint más az m&m-et, biztos nem lesz káros egymásrahatása...
Ahhoz, hogy lehessen tudni mi mivel nem mukodik kutatas kell.Ezt meg bemagolni felesleges ha van egy jol mukodo adatbazis amiben benne van, hogy mi mivel oke es mi mivel uti egymast. Skandinaviaban van ilyen.
-
hát ja, egy építészmérnök is inkább találgasson meg legyen önálló, meg kutasson, az a sok hülye szabvány meg szabály csak felesleges ballaszt... orvos pláne. minek annyit magolni, hagy egye csak a gyógyszereket a beteg, mint más az m&m-et, biztos nem lesz káros egymásrahatása...
-
-
-
glugi
aktív tag
válasz
Dr. Akula
#151
üzenetére
Válasszuk ketté. A jogásznak sem árt a kitartás és az ész. Aki bemagolja a jogszabályokat (ilyet nem lehet amúgy), az jogot végzett. Aki viszont tudja használni a szabályokat, felismeri és megoldja a problémát, na ő a jogász. Így a két szakma nem is áll olyan távol egymástól. Még mielőtt: infokommunikációs szakjogász vagyok elég erős IT vénával és igaz alap szinten, de programoztam anno (hobbi). Már többször olvastam itt hasonló érvelést, most kikívánkozott belőlem.
De a lényeg: volt róla szó a fórum elején, hogy most már elvárás (lenne), hogy akár egy projektmenedzser is tisztában legyen bizonyos programozási alapokkal.
Na most, mit ajánlanátok nekem, merre képezzem magam big data terén? Coursera-n már szemeztem hadoop és r témákkal. Nyilván kezdő, alap szintre gondolnék.
-
cog777
őstag
válasz
#06658560
#748
üzenetére
"1) Sosem szoftverfejlesztésről beszéltem, amikor szakmai dolgokat hoztam elő, pláne, hogy végig hangsúlyoztam is a gépészetet."
Akkor ertheto miert nem talalkozott a velemenyunk. Viszont nem igazan lehet altalanossagban beszelni teruletekrol, szakmakrol. Szoftverfejlesztes teljesen mas. Gyakorlatilag minden teruleten mar ott van, kemia, biologia, elektronika, fizika stb. Arra celoztam korabban hogy keptelenseg minden teruletre felkesziteni a hallgatot ugy hogy gyakorlatban nem latja az elmelet hasznossagat raadasul nehany nem szorosan szoftverfejleszteshez kapcsolodo teruleten pl matek, elektronika stb "tultoljak" a profok az anyagot mikozben szoftverfejesztes kevesbe kap hangsulyt. Ez az eltolodott arany ellenben nem jo.
"2) A topikban a lakáskérdéshez és a szakmai elméleti tudás fontosságához szóltam hozzá. Programozási szakmai kérdésekhez, karrierhez nem."
Ezt ertem viszont mint emlitettem, szakmai elmelethez mennyire tartoznak a fent emlitett matek, fizika, elektronika? Ezen kivul az IT vilaga hihetetlen gyorsan valtozik nem lehet teljesen felkesziteni a hallgatot mindenre, es sajnos a tanarokat sem ilyen gyorsan. Stabil alapokat lehet adni, valamelyest kovetni a trendeket de kb ennyi. Majd a cegnel az adott szituacioban megtanulja. Legalabbis ez van kulfoldon es pont ez a problema M.o.-n hogy a cegek nem akarak egy fikarcnyit sem penzt aldozni tanitani az odakerulo uj dolgozot ellenben elvarjak hogy penge legyel 5-7 dologbol. -
-
proci985
MODERÁTOR
válasz
Dr. Akula
#764
üzenetére
a valaszido varianciara erzekeny valosideju (elosztott) rendszerek -pl jatekok- azert elegge specialis felhasznalasi teruletnek minosulnek.
es ott is limitalt, hogy mit es mennyit erdemes optimizaciora kolteni. gyakorlatban ami nem bottleneck arra felesleges elkolteni egy rahedli penzt.
plusz meg egyszer, egy-egy extra call meg nem feltetlenul a vilag, osszevetve azzal ha pl a gyakorlatilag a futasido joreszet kitevo funkcio kvadratikus algoritmust hasznal a linearis helyett. grafika jatekoknal pont amiatt lehet kritikus, mert ott bizonyos pontokon egy adott funkcio valik limitalova.
-
-
Dr. Akula
félisten
válasz
fordfairlane
#710
üzenetére
Az nem, de hsz írás előtti olvasásban valóban nagy jövő rejtőzik, csak ajánlani tudom. Akár még olyanokra is válaszolhatnál amit állított valaki.
-
Dr. Akula
félisten
válasz
proci985
#704
üzenetére
"azok a feladatok, amelyek eddig az API-ban, illetve egészen pontosan az API-hoz írt grafikus eszközillesztőben voltak benne, mostantól szimplán nincsenek ott, így a programba kell beírni a szükséges implementációt ... nagy fegyvertény, hiszen a vastagabb absztrakciót használó API-kon erre nincs igazán lehetőség, ami szinte lehetetlenné teszi az optimalizálást" [link]
Itt épp nem az asm-ről volt szó.
-
Dr. Akula
félisten
Nem is kell. Az elején azzal kezdtem hogy annak _ellenére_ érdemes ismerni hogy valószínűleg sosem fogod használni. A szemlélet amit nyújt, az fontos, hogy tudd hogy is működik a kódod valójában, hogy néz ki mondjuk egy operator overload valójában, hogy miért jobb az XOR ax,ax mint a MOV ax,0. Mert ezt lehet hogy sose fogod leírni egy kódba, de magasabb szintű nyelveken is van amit meg lehet csinálni többféleképp, csak más sebességgel. És ha van ilyen szemléleted, akkor figyelsz erre (is).
-
Lortech
addikt
-
"Szerintem azt a 600 fontot inkább a magyarországi cégeknél vállalkozóként megkapható összeghez érdemes hasonlítani, kvázi alkalmazottként funkcionál, csak így kapja a bérét - így általában magasabb összeget lehet kapni, mint alkalmazotti státuszban, cserébe nagyobb a kockázat, aznap szélnek ereszthetik": ezt írtam én is, ha nem tűnt volna fel.
tehát ha ezt az összeget magyarországi cégeknél vállalkozóként megkapható összeghez hasonlítom, akkor ez egy pont jó összeg. következésképp angliában kevés.
-
Lortech
addikt
Egy kérdés, magyar ügyfél?
Utánam is számláztak 1200EUR-t időnként 600-800 pedig teljesen átlagosnak számított hosszú távon is, SME-ként, de magyar ügyfél ritkán szokott ennyit kipengetni.
Szerintem azt a 600 fontot inkább a magyarországi cégeknél vállalkozóként megkapható összeghez érdemes hasonlítani, kvázi alkalmazottként funkcionál, csak így kapja a bérét - így általában magasabb összeget lehet kapni, mint alkalmazotti státuszban, cserébe nagyobb a kockázat, aznap szélnek ereszthetik, ha nincs meló, lefújják a projektet. Itt pedig akárhogy is nézem, átlagban nem a 225k+ bruttós napidíjak pörögnek, még külföldre termelő cégeknél sem.
-
G.Zs.
senior tag
Tehat ennyiert te nem egy egyeni contractort alkalmazol, hanem egy cegtol veszel kocson egy tanacsadot. Tehat ez nem a tanacsado fizetese, pont ahogy mondod.
600GBP/nap pedig a fejleszto bere, es ez teljesen jo Londonban adozas utan is. Nem ertem, hogy miert hasonlitod ossze a kettot. -
ha egy normális, elismert (nem feltétlenül nagy) tanácsadó cégtől bérbe vesznek egy szakembert 1 napra, és nem kell letolni a gatyát árajánlat adáskor, akkor igen, kb. ez a napi szint. ha elég nagy a tanácsadó cég és elég pénzes az ügyfél, akkor valamivel több. tehát ez nem a tanácsadó fizetése, hanem ennyiért adják bérbe, amiből nyilván lejön a cég mindenféle költsége.
ha valamiért olcsósítani kell az ajánlatot, akkor ennél kevesebbért is megy, időnként sokkal kevesebbért.
ha az eredeti hozzászólást nézed, és abban contractorként kapta ezt az ajánlatot, vagyis ő adózik mindent, meg fizeti a tb-t meg amit angliában kell, akkor ez, szerintem, ott nem jó pénz. mivel ez itthon a mindkét oldalról tisztességes pénz, ezért szerintem ez ott kevés.
-
Kukipapa_rr
tag
válasz
#06658560
#616
üzenetére
Vagy szeirnted mit keresnek paneloknál a parkolókban Lexus RX300-ak, Volvo S60-S80-ak stb. is?
Szerintem ez csak egy dolgot bizonyít: bőven van probléma az általános matematikai és pénzügyi ismeretekkel.
Hosszú távon fenntarthatóan ökölszabályként én kb. a nettó vagyon 10%-ra lőném be a vásárlandó kocsi értékét, de nem rossz Kiszámoló módszere sem (3-6 havi keresettel megegyező összeg).
Persze nem 400e-be kerülő, luxus pénztemetőkre gondolok, hanem olyan kocsira, aminél van pénz a korrekt üzemeltetésre is.
Mivel ez túlnyomórészt nem teljesül (ld. a hozott példád, bár a panel nem követelmény), emiatt van az a helyzet, hogy ma itthon egyszerűen nem szabad idősödő prémium autót venni, mivel ezeket többnyire olyan emberek használják, akik ezt nem engedhetnék meg maguknak, így elhanyagolják a karbantartását, a kocsi idővel lerohad, majd amikor kitaposták már a belét, elpasszolják egy neppernek, aki lemossa és visszateker rajta pár százezret, majd eladja valami még nagyobbra vágyó baleknak.
-
-
#06658560
törölt tag
-
EnGarde
csendes tag
válasz
fordfairlane
#742
üzenetére
Nálam nem ezt volt.

-
nem volt teljesen világos, hogy alvállalkozói vagy alkalmazotti ajánlat, alvállakozóinak gyenge.
alkalmazottinak sem túl erős, mert a rövid távú szerződésekben illik magasabb fizetést fizetni a rövid távra való tekintettel. ekkora zseton egy nomrálisan megfizetett, szenior szakértőért kiszámlázott díj *PESTEN*. londonban vékonyka. -
EnGarde
csendes tag
válasz
fordfairlane
#718
üzenetére
"Mivel a fő ok a fizetések közti nagy különbség, ezért kábé sehogy."
Sztem ez nem minden esetben igaz már.
-
válasz
#95561216
#735
üzenetére
...és ha a többi kolléga beleegyezik
Na mert ennek aztán marha nagy kultúrája van nálunk! Ha csak egyetlen kolléga is azt merné mondani, hogy ne hozd be a kutyádat, akkor ő lenne a fasiszta állatgyűlölőnek kikiáltva.
Mondjuk én ettől a nagy szeretetpótlék kutyamániától is hülyét tudok kapni.

Nálunk amúgy van az épületben magánovi, 110 ezer havonta.
-
#95561216
törölt tag
válasz
#35193216
#731
üzenetére
Alapból csak jólnevelt kutya jöhetne be, és ha a többi kolléga beleegyezik, akkor igen, akár az irodában mellettem. Remek stresszoldó egy kutya, és megunni is nehezebb, mint az irodai xboxot. Mi már pedzegettük, hogy jó lenne egy project kutya
Nagyobb cégnél meg simán lehetne kialakítani dedikált helyet a háziállatok őrzésére. Kb mint egy munkahelyi óvoda. Amit szintén beírnék elvárásnak, ha lenne gyerekem. Hogy mást ne mondjak hasonlítsd üssze a nyári pesti forgalmat az év többi részével, a dugók nagy részét a munka előtt gyereket cipelő szülők okozzák. -
Kleroo
veterán
válasz
Cathfaern
#730
üzenetére

plusz mindenki motivált is lenne jobban. Én most sem tartom magam lustának, és szeretem a munkámat/munkahelyem, de nem mindegy h 4kor megyek haza, vagy 2-kor. Még boldogabban kelek fel, optimista üzemmódban habzsolom a teendőket(meg se nyitok semmi mást, max napi 5-10percet összesen), aztán húzok is tovább, hisz van még egy csomó időm, nem kell várnom a programokkal hétvégéig. Vagy bármilyen ügyintézéssel. A legtöbb hely 4-5 körül bezár... szóval marad a szerencsétlenkedés bármilyen ügyintézés(gondolok itt mondjuk autószervizes témakörre)
Ehelyett marad most ez a közeg ahol kb mindenki offol a gépén, kávé-kaki-cigi szünet állandóan, alig halad valami, és letargia hogy semmire se ér rá.meetinget olyan aspektusból értettem, hogy nehéz összesyncelni a meetingeket, kisebb idő van mindenki számára. Nálunk legalábbis rengeteg meeting van globálisan. Szóval ha 15embert össze akarsz ültetni, akkor 6órás munkaidőnél esélytelen lenne olyan órát találni ahol mindenki ráér épp.
-
-
#35193216
törölt tag
válasz
#95561216
#724
üzenetére
"5. Kellemes irodai környezet. Amit nagyon tudnék értékelni, ha lehetne kutyát bevinni."
Az irodába gondoltad, melletted, mikor dolgozol? Én biztos nem dolgoznék ilyen helyen, ismerve a hazai kutyatartási kultúrát. Mondjuk dolgoztam olyan kis cégnél, ahol az iroda egy családi ház volt, és tuti nem problémáztak volna, ha valaki az udvaron hagyja a kutyáját.
-
Cathfaern
nagyúr
100%-ig támogatnám.
"Egyedül a meetingelések miatt lehet szűkös, de vmit ki lehetne rá találni."
Én nem ültem még olyan fél óránál hosszabb meetingen, amit ne lehetett volna fél óra alatt is lerendezni
Ha mindenki tudja, hogy időkeretbe van szorítva, akkor könnyen hatékonyabbá válnak a dolgok. Nyilván ehhez az is kell, hogy tényleg csak 6 órát legyen mindenki, környezettől, cégtől és pozíciótól függően simán lehet "normális" a napi átlag 9 óra munka (nem túl órával számolva). Mert hogy igen lejárt a munkaidő, de most ő ezt még inkább befejezi. -
Kleroo
veterán
válasz
#95561216
#724
üzenetére
Open office néha tényleg gyötrelem lehet, de megfelelő szabályokkal élhetőbb.
Én egységesen bevezetném azt, hogy 6órás egy munkanap, és ugyanannyit kell teljesíteni. Szerintem ez lenne a sweetspot. Senki sem fórumozna(höhö), FB-zne, indexezne, olvasgatna a munka java részében "fáradtság", "juj mennyi idő van még hátra" alapon... hanem munka ezerrel, aztán gyerünk tovább élni az életet. Mindenki csak nyerne.
A mai világban szerintem egyre kevésbé értelmes ez a 8 óra munka és punktum. Egyedül a meetingelések miatt lehet szűkös, de vmit ki lehetne rá találni. -
De most informatikusokról volt szó. Vagy a pénzügy alatt banki informatikát kell érteni?
Flimo: 4. pontig nagyon egyetértek veled. Egyébként máig nem értem, hogyan hogyan tudnak egyesek open office space-ben dolgozni. Én már azt sem bírom, ha mögöttem ülnek. Interjún alap dolog, hogy megnézem, hol lesz a munkahelyem.
-
#95561216
törölt tag
Én elég jelentősen leadnék a bérigényemből, ha:
1. Nem openofficeban kellene dolgozni. Több tucat ember egy légtérben, úgy hogy negyede folyamatosan meetingel, súlyosbítva ha németül, mert a magyarok többsége is csak ordibálva tud németül beszélni, ha túl sokat volt köztük.
2a. Távmunka lehetőség. Bemegyek hétfőn meg pénteken meetingelni, a maradék időben online elérhető vagyok.
2b. Ne a halál faszán legyen az irodájuk, és próbálják bizonygatni, hogy de hát 1 óra alatt ide lehet érni, kocsival, mert ott 20%-al olcsóbb az iroda. Amikor meg megkérdezem, hogy jó, adtok rá céges kocsit, akkor pislognak. Amikor megmondom, hogy kocsi beszerzéssel együtt mennyivel lenne több a bérigényem, még nagyobbakat pislognak.
3. Extra szabadság, természetesen arányosan kevesebb fizetésért, levezetve, hogy akkor a maradék napokon kipihentebben jobban tudnék teljesíteni. Úgy néznek rám, mintha a Marsról jöttem volna.
4. Fizetett ebédidő, értsd: 7,5 órás munka naponta. Erre megint érdekesen bír forogni sokak szeme, miközben az output csökkenése elhanyagolható. Ez leginkább elvi okokból fontos, az hogy a munkahelyemen ebédelek nekem nem szabadidő, hanem a délutáni hatékony munka érdekében végzett tevékenység.
5. Kellemes irodai környezet. Amit nagyon tudnék értékelni, ha lehetne kutyát bevinni.
6. Részmunkaidő lehetősége. De nem úgy, hogy 4 óráért fele bér, mert az outputom se lesz fele.
-
-
EnGarde
csendes tag
válasz
Jim Tonic
#715
üzenetére
Tegnap kaptam állásajánlatot Londonba, szerződéses, 6 hónap + lehetséges hosszabitás.
600 £ / nap. Nem irtam el.
Továbbra is azt mondom, ha nem tudják az informatikusokat megfizetni (úgy, mint nyugaton), akkor máshogy kell megfogni őket.
Na de hogy? Gondolkodni szabad, kedves cégvezérek. -
cog777
őstag
válasz
#06658560
#679
üzenetére
"Már ha van internship, s van normális gyakorlat. Nem feltétlen adódik bármelyik is." Aze' M.o-hoz kepest SOKKAL tobb ceg van. Nem igy latod? London es kornyeken porog a munkaeropiac, rengeteg ceggel. Itt Daniaban sem panaszkodhatok. Mar tobb gyakorlata lesz mintha csak elmelettel toltene a fejet a sok prof.
"Ha van gyakorlata, akkor bizonyos korlátok között tud elméleti ismeretek nélkül megoldást találni. Aztán lehet, hogy a következő teszten megint elhasal. Iterálni meg nincs idő."
Elbeszelunk egymas mellett. Elmelet szukseges, de gyakorlat nelkul nem sokat er. Mar irtam miert. Gyakorlatban (IT terulet, szoftver fejleszesrol beszelek) atlatni a millio soros kodot ugy hogy nagy resze legacy tehat lehet h nincs rendesen strukturalva/tervezve es integralni a sajat feladatodat hogy is mondjam csak.. igenyel _nemi_ gyakorlatot."A SCRUM gépészeti téren a legnagyobb bullshit, amivel találkoztam. Csak hátráltatja a munkát. A kommunikációs készséget a hajadra kenheted, ha geometria, fizika témakörben képzetlen a túloldalon ülő."
Akkor valoszinuleg nalatok nincs is megtervezve a koltsegvetese az egesz projektnek hanem csak ad-hoc jelleggel csinaltok valamit? Mert ahhoz hogy _UZLETI TERV_ legyen es validalva, sztenderdeknek megfeleloen mukodve, ahhoz bizony a vezetosegnek szukseges tudnia hol tart a projekt es milyen akadalyok merultek fel. Mondom, ehhez kell komm skill hogy kepes legyel elmondani mondjuk a csapat vezetonek es a product ownernek hogy mi a szitu. Es nem integralasi modszereket varnak el hidd el.
Minden nagyobb cegnel agile-t hasznalnak pont a fentebb emlitett okok miatt.""Megkerdezhetem, honnan tudod? Ugy ertem tisztaban vagy az adott egyetemen levo tananyaggal?"
Ez az alapvetése a threadnek, hogy Magyarországon elméletközpontú, bezzegnyugaton gyakorlatközpontú az oktatás és az utóbbi mennyivel jobb."
Szoval fogalmad sincs ok mit tanultak az egyetemen
ertem."A SCRUM gépészeti téren.."
"Tarthatod a határidőt, ha mondjuk egy kötelező homologizációs ütközésteszten elszáll az ülés, vagy a kötelező elvárt funkcióját nem teljesíti.
A projekt változó: van, amelyik fél éves, van, amelyik három évnél is hosszabb volt, mire széria lett belőle.
Napi szinten látom, mit jelent a tartsuk a határidőt, minden mást szarjunk le mentalitás, amikor a gyártott, és az elméletileg elvárt alkatrész köszönő viszonyban sincs egymással, mert mindenki olyan ügyesen kommunikált a részlegek között, a beszállítóval, vagy úgy kérnek árajánlatot, szállítási időt, szerszámtervet, hogy a beszállító nem is látja, mit kéne csinálnia, s gyárthatatlan modellt akarnának használni, mert a határidő szent, gondolkodni meg luxus."
(Akkor orulok a cegemnek mert itt egesz jol megvan szervezve minden a tiedhez kepest.)Jahogy eddig nem is szoftverfejlesztesrol beszeltel? A Topic marpedig arrol szolt miert vannak betoltetlen IT es szoftver fejlesztoi allasok!
Mas teruleten, elismerem, mas modszerek szuksegesek. Nyilvan hidat is ugy terveznek hogy tovirol hegyire kiszamolnak mindent es akkor allnak neki a gyakorlatban epiteni. De szoftver fejleszteskor ezt nem lehet megcsinalni mert senki nem fizeti ki az idot a matematikai bizonyitasert.
-
#95561216
törölt tag
válasz
mrhitoshi
#699
üzenetére
Orosz Laci egy balfasz, nem lehet szebben mondani. A problémát jól látja, csak azt nem vette észre, hogy ő a probléma, nem a léptetőmotoros ember. Mert igen, emberünk megtanul majd magától léptetőmotort programozni, csak ha nem tanították meg neki rendesen egy másik rendszeren, akkor olyan kódot fog írni, hogy a tapasztalt fejlesztők sírva hánynak tőle.
Az az érve, hogy majd 30 év múlva talán a kvantummechanikáról fognak beszélni a szakmában a kvantumszámítógépek miatt. Nagyszerű, de a tanulók úgyse fognak addigra semmire sem emlékzeni. A 90%-nak akkor is annyi fog kelleni, hogy mikor mit használjon a kvantumszámítógépre megírt keretrendszerből. Mondom ezt úgy, hogy a bme-t elhagyva fizikusnak mentem, tehát abszolút nem a tárgya miatt tartom a faszit egy kreténnek. Mindezek mellett a csávó mostanáig a kommunizmusban él, ez a viselkedés megengedhetetlen egy olyan környezetben, ahol a diákok nagy része maga fizeti a képzését, magyarul ő az ügyfél.
-
#95561216
törölt tag
válasz
Dr. Akula
#700
üzenetére
Azért a magabiztos kijelentéseid közben a helyedben elgondolkoznék azon, hogy te vagy az, aki szerint nincs munkaerő-hiány, mert nem hívnak vissza interjú után, vagy ha mégis akkor rohadtul nem akarnak fizetni, és akiket próbálsz kioktatni mondják, hogy de van, úgy kell levakarni a fejvadászokat.
-
proci985
MODERÁTOR
válasz
Jim Tonic
#711
üzenetére
Itt az eredeti, azota volt tobb variacioja is.
Egy idoben az OO paradigma kapcsan is eleg sokszor elojott a dolog.
-
Cathfaern
nagyúr
"Akkor elengedhetjük végre a panel az űberfasza dolgot?
"
Sose állítottam ilyet. Onnan indultunk ki, hogy "A panel mindig is az alacsony életszínvonalat/csóróságot reprezentálta", erre mondtam, hogy azért ez erős túlzás (mint ahogy az "űberfasza" is az lenne).Dr. Akula:
Én olyan embert még nem láttam, aki szerint a pointer jó dolog egy magas szintű nyelvben. Olyat igen, aki szerint nem annyira bonyolult dolog, mint ahogy hajlamosak beállítani, de hogy jó lenne... -
proci985
MODERÁTOR
válasz
Dr. Akula
#700
üzenetére
trend a programozó kezébe minél nagyobb beleszólás adása a jobb hatékonyság érdekében
ja, ezert is megyunk vissza ASM fele es nem forditva. oh wait.mrhitoshi: ITs szemszogbol nezve a kurrens nemzetkozi publikaciok jellemzoen a gyakorlatban hasznalhato tudast fontos szempontkent szoktak felhozni. pl programozas kurzusoknal az íparban hasznalt nyelv + modern IDE pozitivan befolyasolja a diakok tudasat. ebben ahogy lattam egyetertes van.
az elmeleti kepzest lehet am gyakorlattal is kombinalni, megvannak a megfelelo didaktikai eszkozok. adott esetben az atadott tudas egyebkent jobb is lesz igy, mert a sajat boren fogja megtapasztalni a diak, hogy az adott dolog nehez mit is jelent a gyakorlatban.
Tapsi: nyugaton elegge elment gyakorlat fele, legalabbis ahol en vagyok. ettol meg elmelet ugyanugy van, csak mondjuk tetel lemma bizonyitasok helyett nagyobb suly esik arra, hogy ez megis mire jo es a gyakorlatban hogy mukodik. pl szerintem egy SQL joint egyszerubb megerteni gyakorlati peldan, mint a formalis definicioja alapjan.
kvantumfizika adott esetben szimulaciohoz kellhet szamoltatni, bar ahhoz meg nem feltetlenul ITs hatter az optimalis.
-
válasz
mrhitoshi
#699
üzenetére
A felsőoktatás az elméletről szól...
Érdekes, hogy ezt Nyugaton nem így gondolják, mivel sokkal gyakorlatorientáltabb a képzés, mint nálunk. Orosz Laci mondókája pedig teátrális, de vastagon lehetne vitatkozni vele. Mondjuk kíváncsi lennék rá, hogy az ott ülő hallgatóság mekkora része fogja legalább 1x használni a kvantummechanikát munkája során?!
-
M.Úr
tag
válasz
Dr. Akula
#700
üzenetére
Azt én se tudom hogy a hozznemértők miért akarják megmondani egy szakembernek a "tutit"
Gondolom azért, mert az üzleti alkalmazások 99%-ánál semmi értelme nekiállni Assemblyben bütykölni, mikroszekundumokat spórolni. Egy adatbázis lekérdezés nem attól fog 5 percről 5 másodpercre gyorsulni, hogy assemblyben generálod a query stringet...
Új hozzászólás Aktív témák
- Lenovo ThinkPad X1 Yoga G6 (6th Gen) - i7-1185G7, 32GB, 512GB SSD, multitouch + TOLL
- HP EliteBook 840 G9 i7-1265U 16GB 512GB 14" FHD+ 1 év teljeskörű garancia
- DELL PowerEdge R640 rack szerver - 2xGold 6138 (20c/40t, 2.0/3.7GHz), 64GB RAM,4x1G, H730 1GB, áfás
- Apple iPhone 13 Pro Max Graphite ProMotion 120 Hz, Pro kamerák 256 GB-100%-3 hó gari!
- Keresünk Galaxy S22/S22+/S22 Ultra
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopszaki Kft.
Város: Budapest







![;]](http://cdn.rios.hu/dl/s/v1.gif)


