nevettem

btw érdekes olvasnivaló volt

This post was edited by xGurke on Nov 6 2014 02:48pm

Support nem jó? Oracle elég szépen fizet meg el lehet indulni BI felé, annál nem tudom mi fizet többet IT-ban Ha már VB van akkor akár MS SQL oldalon is lehet próbálkozni valami app DBA témában stb. Support anyagilag annyival jobb, hogy van ügyelet ami kb 20%-ot rádob a fizura (meg annyival kevesebbet is alszol), bár jobb helyeken fejlesztők is kapnak projekt bónuszt.

Én progban csak azt látom, hogy java Enterprise dolgok kellenek adatbázis ismeretekkel és gecire unalmas banki melóval lehet sokat keresni. Ha külföldön gondolkodik akkor tanuljon meg németül és irány Svájc. Angollal is ki lehet jutni csak hát akkor már Rajesh Kumar-al is versenyezni kell bérben, az meg nem az igazi. Nagy Britanniában kezdőként nem érdemes próbálkozni szintén a keletiek miatt.

Szóval a "nem kódolós" területen egy banknál dolgozva mondjuk külsős adatbázis tanácsadóként Svájcban olyan napi 1000 CHF lehet a csúcs, de az mondjuk 8 év tapasztalat után ilyen fél éves projekteken ahol fél évet nem alszik a tanácsadó.

/e SAP témakör lemaradt, de az aztán tényleg olyannak való akit a business process része is érdekel a dolognak. Azzal magyarországon is lehet olyan 1,2 - 1,5 körül keresni tanácsadóként, de az megint sok sok év

This post was edited by ace07 on Nov 6 2014 02:51pm

ezeket az indiai programozókat mindenki emlegeti, hogy mekkora probléma mert ők fognak mindent csinálni
a faszt
mi csak szopunk velük és mindenki utálja őket a cégnél, mert nem tudnak programozni

cpp-ben tolom most, de c-ben toltam előtte, és tanulom magamtól a c#-ot. <bejött ez a c betű>
A mostani melómat azért csinálom, mert nem elég hozzá az infós rész. Szimulációs toolba fejlesztek egy részt és mivel ez egy tök új dolog lesz benne, mérni is kell. Azt meg az infósok nem tudnak normálisan (tisztelet a kivételnek [nem is dolguk amúgy]).
Meg ugye az akusztikát is jobban átlátja egy VM, mint egy MI. Ők az ilyet -ha jól tudom- nagyon érintőlegesre veszik.

Szóval én ilyen határterületen dolgozom, és ez pont jó is nekem. A mi csapatunkban minden "programozó" az villamosmérnök végzettségű. A mi irodánkban vannak még mérnökinformatikusok is, de ők egészen mással foglalkoznak. Kevésbé low levelel és kevésbé fizikaival.
Mi (vagyis a csapat amiben vagyok, én személy szerint nem) még fpga-ra írt mikrokontrollerre is írnak vackokat.

Ha mondjuk vb scripteket kéne írnom excelbe, vagy ügyviteli programokat, akkor kiugranék az ablakon. Nekem bőven jó, hogy nem vagyok és leszek profi programozó, de így legalább fizikai rendszerekkel is foglalkozom. Ez is elég keresett dolog, szóval sem a munkalehetőségek sem a jövedelem miatt nem aggódom.
Sok VM csinálja ezt és van amire kimondottan minket keresnek ilyen helyre (itt is).




lagoltatod a jsp-t.
btw kurvalassú most az egész.

Na már most ha van egy Projekt akkor van pár pénzes igazgató akinek titkárnő és 3 rendszergazda kezeli a gépét és nem ért az informatikához (persze minden létező projekt manager és ITIL végzettsége megvan). Ők annyit mondanak: Legyen ócsó. Nem értik mi a különbség a képzett szakember és a nem képzett között. Ha a projekt bukóra áll, felvesznek még 2x annyit mert ocsók. Na ezért nyomatják ennyire a témát. De persze van több kollégám is Indiából akiknek valós szakmai tudása van és nagyon jól értenek a munkájukhoz.

Én miattuk érzem úgy, hogy ha valaki sokat akar IT-ban keresni az beszéljen az Angol mellett még németül / franciául, mert a németekben és franciákban megvan az, hogy az üzleti életben örülnek neki ha valaki anyanyelvi szinten (középfokúval nem vesznek komolyan senkit) tud velük társalogni.

btw hogy lehet megtanulni jól tervezni oop programokat?
máté segítsen

Single responsibility principle
a class should have only a single responsibility (i.e. only one potential change in the software's specification should be able to affect the specification of the class)
Open/closed principle
“software entities … should be open for extension, but closed for modification.”
Liskov substitution principle
“objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” See also <design by contract>.
Interface segregation principle
“many client-specific interfaces are better than one general-purpose interface.”[8]
Dependency inversion principle
one should “Depend upon Abstractions. Do not depend upon concretions.”[8]
Dependency injection is one method of following this principle.

mindegyikre vannak remek példák és első körben úgy lazán 2 hetet el lehet tölteni velük
főleg ha valaki programozott OOP-ben

ezek közül a D a legtágabb szerintem

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.

ez is újragondoltat pár dolgot, és nem összetéveszendő a Dependency Injection-el

valamint adott az Inversion of Control fogalma, ami egy az egyben a rendszer modularitását hivatott növelni, "kifordít dolgokat" by definition

van egy ILogger osztályod, nem mondod meg hogy mibe logoljon (txt fájl, sql, akármi) hanem azt mondod hogy ő elvár egy ILogImplementation osztályt, aminek van Log(string s) cucca, és mi ezt hívjuk meg, anélkül hogy tudnánk mi történik belül
és mikor logolnánk, ILoggeren keresztül tesszük de ezen az absztrakción nem tudjuk hogy mi történik a valóságban

aztán persze az Inversion of Control absztrakt fogalom egyik megvalósítása a Dependency Injection, ami adja is magát

ILogger(ILogImplementation logImplementation) ugye amit hívunk és akkor
ILogger(xmlLogImplementation) formájában injektálod a függőségét

így szétszedtük a rendszer részeit
nem lehet teljesen szétszedni mindent

vannak IoC containerek (ez már framework szintű dolog), amik azt csinálják hogy



puff, azt mondtuk hogy jó, én interfaceket használok, az 500.000 soros appomban még sincs egy referencia sem magukra az implementációkra, és semmi sem függ tőlük
ettől kezdve, hogy beírtam ezt egy containerbe, minden alkalommal amikor egy class-t készítek, a container végigmegy Reflection-el a classeken és injektálja a regisztrált xy élettartamú osztályainkat (transient = mindig újat kapsz ha kérsz, singleton = ...)
-> még singleton classeket sem kell írnunk, mert NORMÁLISAN írjuk meg őket, és a container gondoskodik róla
meg persze unit tesztelni sem lehet singleton osztályt, de ez már a deep shit kategóriája

most annyi keyword-öt írtam le hogy ebből 6 hónapig tudsz guglizni meg példákat nézni

ja persze és ez sem készpénz, mert néha akarsz írni BaseClassek-et mert az fasza code-reuse és akkor az egész "minden interface" dolgot agyonbasszák

oké köszi, körbeguglézom

van egy könyv nálunk az ötödiken a designokról meg hasonló témákról, ha érdekel
meg szerdán volt ilyen architectes előadás

Aztakurva ez a topik