Álláskeresési tanácsok szoftverfejlesztőknek (és másoknak)

Egy levélben az alábbi kérést kaptam:

Arra szeretnélek még megkérni amennyiben időd engedi, hogy pár sorban összefoglalnád-e mivel foglalkozol a jelenlegi munkahelyeden és milyen elvárásoknak kell megfelelned. Azért érdekel, mert ha hasonló területen/pozícióban helyezkednék el, akkor mire számíthatnék, milyen szakmai vagy egyéb kihívásoknak kellene megfelelnem. Röviden mi a jó és rossz oldala annak az állásnak amelyet betöltesz.

Azt hiszem nem én vagyok a legmegfelelőbb ember, aki erre a kérdésre választ tud adni (és éppenséggel időm sincs valami sok), de gondoltam ha már válaszolok megosztom mindenkivel, elvégre egyre több ember próbál elhelyezkedni ezen a területen, nem árt ha tudják mire számítanak.

Ha pár évvel ezelőtt tették volna fel nekem ezt a kérdést egyszerű választ adtam volna. Ismerni kell a megfelelő technológiákat, trendeket, gyorsan jól kell dolgozni.

Lehet tényleg a korral jár, de azóta sokkal többrétűnek látom ezt a problémát. Ezért nem is a konkrét kérdésekre fogok válaszolni (nem hiszem, hogy a válaszaim bárkinek is segítenének elhelyezkedni) inkább azokat a dolgokat írom le, amit én fontosnak tartok a témával kapcsolatban.

Tehát:

1. Mit várnak el manapság egy szoftverfejlesztőtől?

Amikor döntenek valakiről (felvegyük/ne vegyük)  több szempontot értékelnek. Hogy pontosan miket és milyen súllyal az változhat, de jó eséllyel a lentiek mindig benne lesznek:

Szakmai elvárások: Legyen kielégítő szakmai tudása. Tegyük fel ha java fejlesztőről beszélünk, akkor ismerje a java nyelvet (öröklődés, generikus típusok, objektumok és natív típusok közötti különbségek, stb.), tudjon kódot értelmezni, és legyen (legalább) áttekintő képe a fontosabb technológiákról (ha nem is mindenről de: spring, hibernate, soap, xml/xsd, servlet, jsp, svn, stb.). Jó kérdés, hogy mi minősül fontosabb technológiának. Erre a válasz az, hogy amelyek beleillenek a trendekbe, megfelelő támogatottságuk van, stb. Nincs konkrét recept, de ha valaki megfelelő fórumokat/listákat olvas, vagy megkérdez egy szakmabelit biztos fog egy listát kapni, ami kiindulásnak tökéletes.

Management elvárások: A szoftverfejlesztés (vagy bármi más) nem csak a szoftverfejlesztésről szól. Fontos, hogy a jelentkező képben legyen a saját korlátaival, képességeivel, be tudja határolni mi az elvárása/célja, és tudja ezeket megfelelően kommunikálni. Ha valaki kezdő fejlesztő persze nem nagyon tudja megállapítani saját korlátait (mert nincs viszonyítási alapja) de még mindig szerencsésebb ezt mondani, mint bármi mást. Képzeljük el az alábbi helyzetet. Jelentkezik valaki fejlesztőnek, és beáll azok közé, akik x éve fejlesztenek, napi x órában. Ha úgy állnak az új emberhez, hogy ő tapasztalt, joggal elvárhatják, hogy a feladat ismeretében határozza meg, mennyi ideig fog tartani a megvalósítás. Ez egy egyszerű kérdés, emiatt többen alul is becsülik ennek a súlyát. A kérdés egyszerűsége ellenére a választ nagy ritkán sikerül még napra pontosan is megmondani. Rutinnal és sok gyakorlással jól lehet tippelni (feltéve ha az ember odafigyel erre, és tanul a hibáiból). Egy pályakezdő 90%-ban rossz választ fog adni, és ha mégsem, az is inkább a szerencse miatt van. Vagy nagyon felülbecsüli, ami kiveri a biztosítékot a vezetőknél, és elmagyarázzák neki, hogy na ez itt ám nem az a hely, vagy alul és jó esetben napi 12 órákat dolgozik mire behozza a lemaradást. Rossz esetben valaki másnak kell átvenni tőle a feladatot ami nem biztos, hogy elősegíti a további jó munkahelyi kapcsolatok kialakulását (pl. ha az új kolléga miatt kell valakinek hétvégézni, miközben egész héten 1x órákat volt bent 🙂 ). A “becsüljük meg mennyi idő lesz” probléma minden fejlesztőnél létezik, sajnos ezt csak gyakorlással lehet fejleszteni (pl. megkérünk valakit vagy keresünk a neten egy fejlesztési feladatot, megbecsüljük, megcsináljuk, megnézzük mennyit tévedtünk, elemezzük mit becsültünk alul, felül, stb.), de nagyban megkönnyíti az életünket ha ebben jók vagyunk (akkor is ha nem mi szabjuk meg a határidőket, mert legalább tudunk sípolni időben ha valami nem kerek azzal amit nekünk mondtak).

Emberi elvárások: A szoftverfejlesztés (főleg ha nagy projekt) olyan mint egy sokszereplős társasjáték. Az emberek azért dolgoznak, hogy beérjenek a célba (elkészüljön az amit csinálnak, és még jó is legyen). Csak itt a játékosok nem egymás ellen, hanem egymással játszanak. Szép dolog (és igen jó érzés) ha ez működik. Ha valaki elkapkod valamit, nem gondolkozik, hajlamos félvállról venni dolgokat az felér azzal, mint amikor azt mondják a társasjátékban a többi játékosnak, hogy 2 körből kimaradsz. Ha valaki nem lát meg egy problémát előre előfordul. Ha valaki meglátja, és nem érdekli, az a probléma. Tehát az alaposság, következetesség, és kommunikáció kiemelten fontos (nem csak IT területen, de itt sokkal több a kevésbé kommunikatív ember, ami a reál tudományágaknál egy ismert tendencia). Szintén érdemes gyakorolni az önmegtartóztatást. A fejlesztések során a projekt méretével a tévedések száma valamint mérete is nőni szokott. Például nem túl szerencsés fennhangon anyázni egy kódrészletet mert: lehet valaki tévedett, lehet, hogy amikor megcsinálta még jó volt, csak tudtán kívül átalakult körülötte a kód többi része, vagy csak fáradt volt mert 1x órája dolgozott. Ezt soha nem tudhatjuk (persze van amikor mérgelődünk kicsit konszolidáltan, de azt hiszem ettől vagyunk emberek  😉 )

2. Milyen egy szoftverfejlesztő élete

Társaság: Ha egy jó csapatba/cégbe csöppen az ember, akkor nagyon jó. Nekem személyes tapasztalatom az, hogy az emberek sokkal fontosabbak mint a projektek. Ez az a szakma ahol mindig meglehet találni a feladatok szépségét, vagy egy semmitmondó feladatot is meg lehet oldani érdekesen, oly módon, hogy tanulni is lehessen belőle (persze itt is kiemelten fontos az önismeret, bukott el nem egy nagy projekt a túlcizellált megoldásokon).

Szabadidő: Természetesen a szoftverfejlesztés nem kevéssé időigényes feladat, és ha valaki egy új cég életébe csökken, az első napok/hetek/hónapok biztos nagyon húzósak lesznek (túlórák, rengeteg új dolog, érthetetlen összefüggések). Ezek ismert dolgok, nem szabad megijedni, szépen lassan tisztul a kép, és utána megtérül a sok befektetett idő és energia.Természetesen ezek után sem áll meg az élet, folyamatosan jönnek az újabb trendek, mérföldkövek, verziók, hibajegyek, stb.

Pénz: A szoftverfejlesztésben van pénz. Vannak fizetések is (bár ez cégtől függ 😉 ). Kevés szoftverfejlesztőt láttam porsche-val munkába járni (én egy időbe szerettem volna, de nem jött össze 🙂 ), de szerintem a legtöbben megtalálják a számításaikat.

Microsoft termékkulcs visszavétel

Amikor az ember feltelepít egy Microsoft alkalmazást fel sem merül benne a gondolat, hogy a használt termékkulcsot már nem látja viszont. Ha valakinek több Windows-a is van (ráadásul legálisan, mert az illegálisnál nem számít) akkor nem árt ha meg tudja találni, melyik termékkulcs hány vagy milyen gépeken van használva.
Erre egy kiváló alkalmazás az alábbi:
http://www.magicaljellybean.com/keyfinder/

GWT rpc servlet Vs Apache proxy

A gwt alkalmazások (egyik) legnagyobb előnye a perfect cache kezelés. Ahhoz, hogy ez hatékony legyen érdemes minden statikus tartalmat egy apache-ra rakni, és csak az RPC hívásokat átfűzni egy proxy-n az alkalmazás szerver felé. Ennek hatására viszont előállhat az a furcsa helyzet, hogy az RPC szolgáltatásokat kezelő szervlet context-root-ja eltér a statikus fájlok context-root-jától.

Ezt a GWT rpc kezelő servlete nem szereti valami nagyon és mindenkit megjutalmaz az alábbi hibaüzenettel:

[10/28/10 12:50:44:383 CEST] 00000041 webapp        I com.ibm.ws.webcontainer.webapp.WebApp log SRVE0296E: [app_war#app.war][/app/services][Servlet.LOG]:.PartnerServiceServlet: ERROR: The module path requested, /app/, is not in the same web application as this servlet, /app/services.  Your module may not be properly configured or your client and server code maybe out of date.:.null

Ez önmagában nem baj, csak csúnya, de amikor komplex osztályokat küldünk fel a szerverre, ennél komolyabb hibák is jelentkeznek (cannot load serialization policy).

Ennek oka, hogy az RPC üzenetek hordozzák magukban, hol keletkeztek, és a szerver oldal ellenőrzi, hogy az egyezik e a context rootjával.

Ha megfigyeljük az RPC hívások tartalmát látszik, hogy az url a verziók után utazik, pl:

verziók|hívó|ser policy fájl|hívás névtér|szolgáltatás, stb…

A valóságban valami ilyesmi:

5|0|9|http://server/app/|D0C8380096848CC179C5488360839537|hu.aftershock.client.services.gwtrpc.modules.common.ICommonService|getCommonCodes

A probléma a 4 résznél van, amit cserélni kell (ha az alkalmazás context rootja nem /app hanem /app/services). Ezt oly módon tudjuk megtenni, hogy leszármazunk a RemoteServiceServlet osztályból, és felülírjuk a processcall funkciót (ezt egyébként is érdemes megtenni, ide lehet mindenféle hasznos dolgot mint profiling, audit, security implementálni).

@Override

public String processCall(String paydload) throws SerializationException {

paydload=mainUrlFix(paydload);

A mainUrlFix implementáció az alábbi módon néz ki:

private String mainUrlFix(String payload) {

int tokenNum=0;

String prefixString=””, mainUrl=””, postfixString=””;

for (int i=0, il=payload.length(); i<il; i++ ) {

if (payload.charAt(i)== AbstractSerializationStream.RPC_SEPARATOR_CHAR) {

tokenNum++;

if (tokenNum==3) {

prefixString=payload.substring(0,i);

} else if (tokenNum==4) {

mainUrl=payload.substring(prefixString.length(),i);

postfixString=payload.substring(i);

break;

}

}

}

if (!mainUrl.endsWith(“services/”)) {

mainUrl+=”services/”;

}

return prefixString+mainUrl+postfixString;

}

Ubuntu too many open files

Ha túl sok a megnyitott fájl (enterprise és java alkalmazások előnyben), akkor az alábbit kell tenni:

Ide kell írni a limiteket:

/etc/security/limits.conf

Az alábbi módon:

* soft nofile 65535
* hard nofile 65535

Ezek után ellenőrizhetjük a beállításunkat:

ulimit -n

Ha 1024-et ír ki a 65535 helyett, akkor annak az az oka, hogy nincs benn a megfelelő pam modul, amit az alábbi módon tudunk betenni.

/etc/pam.d/common-session

session required pam_limits.so

UPC internet féláron

Nem kell sokat a sorok között olvasni, hogy a UPC felsővezetése egyáltalán nem a partnerek elégedettségére hajt. Biztos vagyok benne, hogy minden vezetői értekezleten egy számot tartalmazó report képezi a board elégedettségének alapját, ami az új ügyfelek számát tartalmazza.

Ezért aki már nem új ügyfél, könnyen ráfizet. Vegyük alapul a mostani akciót. A legdrágább előfizetés 6000 forint. Aki már 3 éve előfizető ugyanezért 12000 forintot fizet.

Felmerülhet az ötlet mindenkiben, minek fizessek 2x annyit, lemondom, és újrakötöm. Sajnos erre gondoltak, ha valaki lemondja az előfizetését, akkor a lemondás címére (igen nem név, és nem előfizető hanem cím) 3 hónapig nem köthet akciós szolgáltatást. Ez különösen jó dolog akkor, ha valaki kiköltözik valahonnan, jól ki tud tolni az utána jövővel.

Ellenben van megoldás. Első körben szerezni kell egy címet, ahol nem neteznek, de elérhető a UPC. Át kell köttetni oda az internet előfizetést (ez ingyenes). Le kell mondani az internet előfizetést (átköltözetni és lemondani többször is lehet). Újra kell kötni az internet előfizetést. Lehet örülni a félárú internetnek. A legjobb a dologban, hogy lemondott címre 3 hónapig nem lehet kötni kedvezményes előfizetést, de már meglévőt átköttetni lehet.

Online Youtube to mp3 converter

A youtube-on található zenék hangminősége elég kérdéses, de ha valaki csak azért halgat meg egy zenét, hogy megtanulja (tehát a hangminőség nem releváns), arra bőven elég. Sajnos a youtube sok dolgot viszont nem tud, ezért szükségünk lehet a hanganyagra valami “fogyasztható” videó nélküli formátumban. Erre az általam ismert legjobb megoldás:

http://www.dirpy.com/

Online, gyors, és mindent tud, amire csak szüksége lehet az embernek egy ilyen konvertálás során.

Levélküldés tesztelése

Manapság már nem nagy dolog olyan alkalmazást fejleszteni ami emailt tud küldeni. Ellenben fejlesztés alatt egyáltalán nem biztos, hogy szerencsés, ha a valódi felhasználók a fejlesztők viccesebbnél viccesebb tárgyú leveleit kapják kézhez (pl. szerződését díjrendezettség hiányában töröltük, stb). Ezt elkerülendő lehet mindenféle if-eket írni a kódba, de ez sajnos megváltoztatja a program működését, és ezzel a metódussal elég sok potenciális hibaforrást elrejthetünk a kódban. Célszerűbb csinálni egy saját smtp szervert, ami e leveleket fogadja, de nem küldi ki, hanem lementi egy könyvtárba.

Erre a legegyszerűbb megoldás linux alatt a fakemail nevű program, ami a phytonnal együtt jön.

Tehát a telepítés

sudo apt-get install python

Az indítás (pl. init.d-ből)

sudo su -c ‘fakemail.py –host=voji.hu –port=10025 –path=/var/samba/servers/smtp –background’ voji

A lényeg a ‘ ‘ jelek közötti rész, a su -c csak azért felel, hogy voji userként fusson a szerver.

A paraméterek:

  • host – a cím, ahol a szerver fut
  • port – port ahol hallgatózik majd az smtp szerverünk
  • path – könyvtár ahova a leveleket lementi amit a szerveren keresztül küldenek.
  • background – háttérben fusson, ne a konzolon

Symbian developer certificate

Dúl a háború az okostelefonok piacán, és elég letisztult a kép. Harcol az Apple az Android ellen, elviekben ezzel mindenki jól jár, megismétlődik az összecsapás a nem nyílt és a nyílt forráskódú operációsrendszerek között. Szerintem mostmár változott akkorát a világ (és fejlődött a szoftverfejlesztés), hogy a nyílt forráskódú rivális nyerjen. De majd elvállik.

Mindenesetre a futottak még kategóriában harcol a nokia a symbiannal, ami inkább csak vicc. Sajnálnám őket, de nem tudom, volt idejük, sőt, több idejük és pénzük volt mint bárkinek, hogy fejlesszenek egy normális operációs rendszert, meg normális telefonokat… Ha valaki szoftvert szeretne rá telepíteni, akkor szembesül azzal a problémával, hogy a telefonra csak aláírt szoftvert lehet telepíteni. Aláírni csak pénzért lehet. Ezért minden komolyabb szoftverért fizetni kell, legalább a certificate árát. Ki jár ezzel jól? A Nokia. Nem elég hogy eladják a telefont minimum 10x áron, de bárki belefekteti idejét/pénzét hogy fejleszzen valamit, még azután is lehúzzák a sápot. Developer certificatet is csak úgy lehetne szerezni, ha ŐK engedélyezik, és adnak.Szóval nem baj, ha kihal az egész symbian vonal, és a nokia-ért se fogok könnyeket hullatni, ha ilyen pofátlanok megérdemlik. Legalább most, hogy közel a vég, észheztérhetnének.

Addig is amíg ez nem történik meg (a kipusztulás, vagy észheztérés) az alábbi kínai oldalról imei szám megadása után saját fejlesztői certificate-t generálni:

http://cer.opda.cn/en/

Mindenkinek saját dns szervert

Amennyiben az otthoni számítógépünk nem rendelkezik fix ip-címmel, sokat segíthet a DynDNS szolgáltatás. Ennek segítségével beregisztrálhatunk magunknak egy tetszőleges domain nevet (ingyen) és a szolgáltatáshoz adott kis kliens program segítségével (linux alatt ddclient apt-get-tel telepíthető) az otthoni gépünk mindig frissítheti a saját dns-éhez tartozó ip címét (tehát akkor is elérhetjük a gépünket, ha a gonosz szolgáltató más ip-t adott neki).

Tegyük fel, adott Lajos, aki szeretné a számítógépét elérni otthonról. Beregisztrálja magának a lajos.homeip.net címet. Ezek után az otthoni számítógépét mindig eléri ezen a címen, aminek nagyon örül. Ellenben ha Lajos belső hálózatot is használ, akkor két dolgot tapasztalhat:

1. Olyan szerencsés, hogy a routere támogatja a nat loopback funkciót, és ha beírja otthon, hogy lajos.homeip.net akkor minden működik

2. Nem szerencsés

A nem szerencsés esetet két féle képpen orvosolhatjuk. Ha beírjuk a hostfile-ba, hogy lajos.homeip.net az a szerver lokális ip címe (pl 192.168.2.1). Ez jó, de ha Lajos hazamegy, midnig át kell írnia a host-fájlt, ha meg elmegy otthonról midnig vissza kell írni. Lássuk be ez nem a legelegánsabb megoldás.

Másik alternatíva, hogy Lajos saját dns szervert csinál. Ez azért is hasznos, mert megismeri a DNS szerverek működését, és felépítését (persze csak nagyon felületesen) és mert lát ilyet is…

Linux alatt dns szerverre a bind nevű csomagot szokták használni, amit az alábbi módon telepíthetünk:

sudo apt-get install bind9

Ezekután már van jól működő DNS szerverünk, ami a 67-68 udp portokon üzemel már csak konfigurálni kell. A dns szerver konfigurációját az alábbi helyen találjuk: /etc/bind

Ide kell két fájlt létrehoznunk, ami alapján a dns szerver megoldja majd a név-ip és ip-név fordítást.
db.1.168.192
;
$TTL 604800
@ IN SOA localhost. lajos.homeip.net. (
28 ; Serial
604800 ; Refresh
86400 ; Retry
241920 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
2 IN PTR lajos.homeip.net.

db.homeip.net
;
$TTL 604800
@ IN SOA homeip.net. lajos.homeip.net. (
28 ; Serial
604800 ; Refresh
86400 ; Retry
241920 ; Expire
604800 ) ; Negative Cache TTL
;

@ IN NS dns1.hu.
@ IN NS dns2.hu.

@ IN A 204.13.248.119
www IN A 204.13.248.119
lajos IN A 192.168.1.2

Az db.1.168.192 nevű fájl megmondja, hogy a 192.168.1 tartományban a 2 ip cím (192.168.1.2) az nem más mint a lajos.homeip.net.

A második db.homeip.net nevű fájl pedig megmondja, hogy a homeip.net domainban a sima hivatkozás nemmás mint a homeip.net szerver neve (ezt ping homeip.net-el meg lehet tudni), és a lajos.homeip.net pedig nemmás mint a 192.168.1.2 ami a szerverünk címe…

Ezek után már csak használni kell ezeket a fájlokat, a named.conf.local fájlba fel kell venni az alábbi két sort:

include “/etc/bind/zones.rfc1918”;

zone “1.168.192.in-addr.arpa” {
type master;
file “/etc/bind/db.1.168.192”;
};

zone “homeip.net” {
type master;
file “/etc/bind/db.homeip.net”;
};

Ezek után kell egy bind újraindítás (/etc/init.d/bind9 restart), ha elrontottunk valamit arról a var/log/syslog-ban fogunk kapni infót.

Az eredményről magunk is meggyőződhetünk:

dig @localhost lajos.homeip.net

Értelemszerűen a dhcp szervernek meg kell adni, hogy a DNS szerver címe a lokális szerver (192.168.1.2) legyen.

Vnc ubuntu alatt

Sokszor kell, mindig elfelejtem, most már leírom ide is:

Telepítés:
sudo apt-get install vnc4server

ezekután elindítjuk a vnc4servert (létrehoz mindenféle konfigokat, bekéri a jelszót, stb)
vnc4server

ezekután lelőjjük:
vnc4server -kill :1

kicsit átírjuk a konfigurációt ami az alábbi helyen található:
nano ~/.vnc/xstartup

A fájl tartalma ez legyen:
#!/bin/sh
unset SESSION_MANAGER
exec /etc/X11/xinit/xinitrc
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources

Biztos ami biztos adjunk jogot az xinitrc-re:
sudo chmod 755 /etc/X11/xinit/xinitrc

Csatlakozhatunk a host:5901 porton… (ahány példányt indítunk annyiszot emelkedik a portszám 1-el)

Az UltraVNC ha kis porotot adunk meg alapból hozzáad 5900-at, tehát ott elég megadni így: host:1