A junior fejlesztő

Másfél évvel ezelőtt a cégnél a főnökömnek támadt egy remek ötlete: vegyünk fel egyetemistát!

A cégnél akkor szinte csak senior, ill. vezető fejlesztők dolgoztak, és akart valakit, akit lehet olcsón dolgoztatni. Az volt az elképzelése, hogy a srác először tesztelő lesz. Hetente egy napot foglalkozhat technológiával, és ha már eléggé megismerte a projektet, akkor kaphat fejlesztési feladatokat is.

A srác a mi projektünkbe került, és engem ért a “megtiszteltetés”, hogy kiképezzem. Mint mondjak, egy kicsit ideges lettem: “Felvesz valakit olcsóért, és még én foglalkozzak vele?! Közben a saját munkámmal sem tudok majd rendesen haladni!” Eléggé kellemetlenül éreztem magam amiatt is, hogy egy leendő fejlesztőnek “klikkelgetős” feladatot kell adnom. (Tudom, hogy egy jó tesztelő felbecsülhetetlen, valahogy mégis úgy gondolom, egy programozó számára a “klikkelgetés” nem egy élvezetes munka.)

Tévedtem.

A srác még egyetemista volt, 0 valós életbeli szoftverfejlesztési tapasztalattal.

Az elején minden nap foglalkoznom kellett vele. Órákat. A hét 5 napjából 4 napján foglalkoztunk azzal, hogy a program hogyan működik a felhasználói felületen keresztül, mit jelentenek az egyes képernyőn megjelenő üzleti fogalmak. A péntekek lettek a technológiai napok (pén-tech), az nekem szabadság volt. A srác nézegethette a kódot, megismerte, milyen technológiákat használunk. Ebben a többiek is besegítettek. Még örültem is neki, hogy végre fejlesztői feladatokat csinálhat.

Aztán eltelt három hónap

A srác már tisztán fejlesztési feladatokat csinált. Megtanulta, hogyan írunk automatizált teszteket, milyen a domain modellünk, hogyan kell a Spring-et, Hibernate-et használni. Ami számomra még fontosabb volt: megértette és megtanulta az üzleti területet. És egyszercsak rájöttem:

A csapat egy új, teljes értékű taggal bővült.

Mivel Scrum-ot használtunk, ő is volt a tervezéseken, a reggeli stand-up-okon és a demókon. Látta, hogy megy az egész csapatjáték. Folyamatosan kapott visszajelzéseket, és szerencsére nem is hagyott békét, ha valamit nem értett (sokszor milyen türelmetlen voltam!). Próbáltam neki mindent megmutatni, a becsekkolt kódját közösen átnéztük, javítottuk.

Mivel 0 tapasztalattal rendelkezett, tudtam, hogy ha nem sikerül neki valami, az csakis az én hibám lehet. Ő mitől tudná, ha én nem mutatom meg és mondom el neki?

Másfél éve van már a csapatban. Igaz, hivatalosan még mindig junior fejlesztő, de olyan tudással rendelkezik, ami miatt nem engedném lecserélni semmilyen senior fejlesztőre. És ami még nagyon fontos: emberileg is ott van.

Mire jók akkor a nagytudású fejlesztők?

Volt jó pár fejlesztővel dolgom a munkám során. Nagyon sok rosszal találkoztam, akikkel állandóan vitáznom kellett. Ha új környezetbe kerülök, előre félek attól, hogy olyanokkal hoz össze a sors, akikkel majd később vitáznom kell, és meg kell győznöm őket a saját igazamról. Mert _ők is értenek_ mindenhez. Belefáradtam.

Rájöttem, hogy sokkal jobban járok a tapasztalatlanabb kollégákkal. Én taníthatom be őket, nem kérdőjelezik meg állandóan, amit mondani akarok. Hallottam már olyanról, hogy más ipari területeken nagy cégek gyakornoki programokat hirdetnek, ahol a saját szájuk íze szerint tanítják be a gyakornokaikat. Végülis én pont ezt csináltam. Annak ellenére, hogy azt hittem, ezzel a módszerrel egy gyakornokot egy meghatározott szűk látókörű pályára kényszerítenek, a mi esetünkben ez biztosan nem így történt. A következőket tanultuk meg:

  • egy JavaScript framework,
  • Java kódolás, refaktorálás, automatizált tesztelés,
  • Continuous Integration,
  • Hibernate, Spring,
  • MS SQL,
  • Domain Driven Design,
  • Scrum,
  • Subversion,
  • manuális tesztelés, issue tracking,
  • rengeteg praktika.

Mindenkinek megérte. Nem jó ez így?

Akar valaki még egyáltalán “sok tapasztalattal” rendelkező, magától elszállt szoftverfejlesztőt felvenni sok pénzért?

Share
This entry was posted in Módszertan and tagged , , , . Bookmark the permalink. Follow any comments here with the RSS feed for this post. Post a comment or leave a trackback: Trackback URL.

Comments

  • a legtöbb csapatban csak juniorok vannak :) ebből kiindulva gondold végig a fentieket mégegyszer ;)

    egyébként veszélyes hozzáállás a “seniorokkal csak vitatkozni lehet de úgyis nekem van igazam tehát csak az időt lopjuk”. sokkal több embertől lehet folyamatosan tanulni seniorként is mint gondolnád.. egyébként ha interjúztatok, seniorokat is junior kérdésekkel szoktam bombázni, iszonyú sok bukik rajtuk (és nyilván sokkal előrébb vagyok egy alapokkal tisztában lévő juniorral mint egy 5-6 éve zavaros fejű seniorral)

  • Marhefka István

    Mar 31st, 2010

    Kristóf: Igazad van. Nem szabad mindent feketének vagy fehérnek gondolni, amit írok:) Tehát amikor azt írtam, hogy belefáradtam, hogy reménytelenül vitatkozzak valakivel, akkor a kezelhetetlen “esetekre” gondolok, nem azokra, akikkel konstruktívan lehet előre haladni és egymástól tanulni.

    Te egységnyi idő alatt több helyen fordulsz meg, ezért több emberrel is találkozol, mint én. A “legtöbb csapatban csak juniorok vannak” állításodnál nem azokra az emberekre gondolsz, akik megragadtak a Te általad gondolt junior szinten, és nem fejlődtek tovább? (Az ilyenekkel nem szívesen dolgozom.)

    Én a cikkben a junioroknál a nagyon kevés tapasztalattal rendelkező fejlesztőkre gondoltam (inkább gyakornokoknak kellene nevezni őket).

    Ilyenek lennének minden csapatban?

  • azokra gondolok akik békésen elmaszatolnak már X éve egy lassan gyakorlati úton összeállt ámde bizonytalan lábakon álló tudással ahol nem tudjuk mi miért hogyan van, de “így szokott működni”, stbstb.. sztm ismered ezt a típust :) igazad van ezek végülis nem juniorok, a tudásuk meg néhol még az alá is megy, de nem tudok rájuk jó nevet..

  • Marhefka István

    Mar 31st, 2010

    Akkor ugyanarra gondoltunk. Angolul mások, ha jól rémlik, “mediocre programmer”-nek, azaz középszerű programozónak hívják őket.

  • Az “igy szokott működni” tipusú programozórol eszembe jutnak egyetemi éveim, mikor analizisből belénkvertek mindent, de csak a ZH-ra koncentráltál, hogy meglegyen. Aztán ha érdekelt, akkor évek alatt ért meg benned a tudás, hogy mi miért hogyan. vagy villanytanból analizis után esett le 2 évvel, hogy mire is jók a diff. egyenletek meg a Laplace/Fourier transzformáció.
    A programozásban is vannak ilyen területek szerintem. Sokminden van, amit csak használsz, de nem érdekel a “lelke” – ha kell, van időd, lehetőséged, majd megnézed.
    (Mostanában futok bele sok ilyenbe, de utánanéz az ember és megtanulja – szerintem ez a fontos, hogy képes-e és hajlandó-e az ember fejlődni)

    A bejegyzésre reagálva, úgy látom (főleg jelenlegi körülményeim közepette, mikor egyedül vagyok java coder, vezető fejlesztő, minden), hogy jó, ha két senior van együtt, akik tudnak is együtt dolgozni (azt, hogy mennyi senior tud együtt működni hatékonyan, nem tudom). Nekem pl. hasznos lenne egy kontroll. Nem azért, mert nem bízom az általam biztosnak vélt tudásomban, de én is lehetek fáradt, kevésbé hatékony. S azt tapasztaltam, hogy nagyon tudja húzni a másikat, ha van egy hasonló kaliberű ember legalább. Ha van 1 senior és csak juniorok, akkor nem fejlődik úgy az ember. Fejlődni meg mindenkinek kell, szükséges. S szerintem elvárt is. Ebben a szakmában különösen.
    Egyedül magamban én sokkal lassabban fejlődök.

  • Marhefka István

    Mar 31st, 2010

    szilsan: Igazad van.

    Már megkaptam a magamét a cikkért, hogy most még sarkosabban fogalmaztam, mint általában :) Arra szerettem volna csupán rámutatni, hogy egy kezdő programozó is lehet hasonlóan hasznos, mint egy senior fejlesztő.

    Mivel mi már jó ideje ugyanazt a terméket fejlesztjük, ezért igazából viszonylag kevésszer fordulnak elő meglepetések. Kihívások azért még így is lehetnek. A junior fejlesztő (gyakornok) kolléga pedig teljesen bevált: megérti a kódot, az üzleti gondolkozást, ellesi az alkalmazott konvenciókat, és alkalmazza is őket. Lenne-e szükségünk senior fejlesztőre most? Nem igazán.

    A junior fejlesztőknek útmutatás kell. Ha van egy biztos alap a projektben, amihez alkalmazkodhatnak, akkor tökéletesen használhatóak.

  • Nekem ilyen kérdéseim lennének, hogy akkor meddig gyakornok a gyakornok? Meddig junior fejlesztő a junior fejlesztő? Meddig fejlesztő a fejlesztő… stb. Mert én saját tapasztalatból azt tudom mondani, hogy az embernek első sorban saját magát kell menedzselni és akkor tud ugrani a képzeletbeli ranglétrán, nyilván más folyamatok is közre játszanak. A “vagy felveszel vagy elmegyek” se egy jó megoldás szerintem. Ti akik már kifutó félben vagytok a szakmából, a BA-ság felé tartva, vezető fejlesztők, architectek, légy szíves osszátok meg velem, hadd tudjam én is, hogy milyen szintek vannak. :D Bocs. Arra gondolok, hogy pl. meddig etikus valakit gyakornokként alkalmazni, amikor már hosszú ideje teljes értékű munkát végez… Egész más dolog junior fejlesztőként alkalmazottnak lenni vagy gyakornokként lógni a levegőben. Szerintem is remek dolog a gyakornokság, akár egy évig is. Abban viszont nem vagyok biztos, hogy így meg lehet tartani az értékes embereket hosszú távon… Tudom, hogy pénzkérdésről beszélünk, de jó lenne szabályozni valahogy ezt a gyakornok és alkalmazott közötti átmenetet… A gyakornokok is motiváltabbak lennének.

  • Marhefka István

    Apr 1st, 2010

    Janó: A junior fejlesztő és senior fejlesztő fogalmat a cégek találták ki, hogy skatulyába rakjanak, és a fizetésedet a skatulyához igazítsák.

    Én, egyszerű szoftverfejlesztőként két fejlesztőt ismerek: akivel szeretek együtt dolgozni és akivel nem szeretek együtt dolgozni.

    Vannak-e szintek a szoftverfejleszők között? Mi a létra vége?

    Reagálva: Nem gondolom magamat “kifutó”-nak a szakmából. Én abban hiszek, hogy akkor lehet jó szoftvert készíteni, ha az ember maga is résztvesz a kódolás folyamatában, és nem pedig felülről osztja az észt. (Én inkább az önfejlesztésben és önszerveződésben hiszek, ahelyett hogy tanácsadó cégek és “kiváló” szakemberek osztanák az észt. Ezzel az ember megteremti magának és a környezetének a motivációt és a fejlődés lehetőségét.)

    Egyszer egy konferencián ezt hallottam, amikor bemutatkozott az előadó: “Először szoftverfejlesztőként dolgoztam a cégnél, majd feljebb léptem a ranglétrán, és most már tanácsadó vagyok, aki napi szinten találkozik az ügyfelekkel.”

    Van egy másik ismerősöm is, aki azt gondolja, hogy a programozás egy beugró szint, utána az embernek természetszerűleg mással (pl. tanácsadással) kell foglalkoznia.

    Úgy gondolom, hogy ezek az emberek soha nem tudták és nem is fogják megtudni, hogy mit is jelent a valódi szoftverfejlesztés. Amikor értéket és minőséget teremtesz.

    Ismeritek Kent Becket? Ő se huszonéves már.

    A közös munka

    Engem nagyon érdekelt mindig az üzleti terület probléma. Próbálom megérteni, és ezt a tudást felhasználom a kód megírásában. Én is sokat beszélgetek az ügyféllel, de nem akarok igazából a BA skatulyába tartozni, akinek az a feladata, hogy beszélget az ügyféllel, leírja az igénytelen doksikat, és odapasszolja a fejlesztőknek, hogy: “Haver! Itt van, csináld!” Ismertek már, és tudjátok, én nem hiszek az ilyen modellekben és attitűdben.

    Igen, vezető fejlesztőként dolgozom (újabb skatulya), és talán a BA skatulyába is beleillek (de én nem gyártom kilóra a doksikat, hanem személyesen megosztom a tapasztaltakat). Egyedül nem tudom olyan jól megcsinálni a szoftvert, mintha Veletek dolgoznék. Nem csak azért, mert rövid az idő, hanem azért is, mert – annak ellenére, hogy sokszor erősen képviselem a saját gondolataimat (igen: makacs, önfejű vagyok) – abban hiszek, hogy a legjobb munka akkor készülhet el, ha egy csapat csinálja. Ha van bizalom, megbeszéljük, és közösen kitaláljuk. Ide egy kedvenc idézetem, amit nemrég ismertem meg:

    “A legjobb vezetők tudják, hogy az eredményeket valamennyi, az adott feladaton dolgozó ember együtt éri el – és nem csak az, az egy valaki, akinek az a kiváltság jutott, hogy épp a csapat vezetője lehet.

    Az ügyfeleiddel elért siker nem rólad szól. Ez a siker azokról az emberekről szól, akik azt választották, hogy Veled dolgoznak.
    A csapatom sikere nem rólam szól. Ez a siker azokról a nagyszerű emberekről szól, akik velem dolgoznak.”

    A szörnyű igazság

    Úgyhogy: igen, ahhoz, hogy a cégben éppen milyen skatulyában vagy, az jelenleg önmenedzselés és politika. De ne ez alapján mérd magad! Úgy gondolom, ha szoftvert fejlesztesz, döntsd el, hogy ez-e a hivatásod. Ha igen, akkor annak nagyon örülök, és valószínűleg Te is örülsz neki.

    Sajnos, a fizetési rendszer olyan, amilyen. Az embert lehúzzák, ahogy tudják, és mindenki a saját életéért küzd.

    Búcsúzóul azért következzék pár cikk Joeltől, hogy létezhet más is:

    Fog Creek Compensation
    Fog Creek Professional Ladder
    Why I Never Let Employees Negotiate a Raise

  • Hesz Roland

    Jul 29th, 2010

    “a BA skatulyába tartozni, akinek az a feladata, hogy beszélget az ügyféllel, leírja az igénytelen doksikat, és odapasszolja a fejlesztőknek, hogy: “Haver! Itt van, csináld!” ”
    Csak szeretnék rámutatni, hogy ez nem BA. Ez nem tudom mi :)

    A cikk amúgy tetszik, meg a blog is.

    Egy új olvasó.

  • Marhefka István

    Jul 29th, 2010

    Roland: BA rövidítéssel a Business Analystre gondoltam. Valószínűleg mindenhol kicsit mást értenek egyes fogalmakon, szerepkörökön. Nevezhetjük tanácsadónak, rendszerszervezőnek is az illetőt. Nálatok kik azok, akik felmérnek, és a felmérések alapján jegyzőkönyveket, követelményspecifikációt gyártanak, és a későbbiekben is az ügyféllel tartják a kapcsolatot, ha egyeztetni szükséges?

    Köszi a biztatást! :)

  • Hesz Roland

    Jul 30th, 2010

    Igen, én a Business Analyst-re gondoltam akinek EGYIK de nem egyetlen feladata a követelményfelmérés (dokumentálás, elemzés, kigyomlálás, öszeegyeztetés, politikai csaták leboxolása stb.)
    És semmiképpen nem úgy, hogy aztán odatolja a fejlesztőnek az igénytelen doksit, hogy hajrá csináld.

    Tapasztalatom szerint – mint BA :) – a jó BA ott ül a fejlesztőkkel és a tesztelőkkel, és folyamatosan dolgozik velük, segít, támogat.

    Amúgy egytértek, sokan itt megállnak mint BA – elment, leírta, fejlesztőnek odaadta, vége -, de azért ennél sokkal több és jobb dolgot is tehet az igazi BA a projektért.
    Én pedig próbálok tenni azért, hogy nálunk, Magyarországon is kicsit többet értsenek a BA alatt. Például a projekt indítása ELŐTT már ott legyen. Enterprise Analysis – vállalkozás elemzés – területen is vegyük igénybe itthon is. És még hosszan sorolhatnám :)

  • Marhefka István

    Jul 30th, 2010

    Roland: Tegnap kicsit kutyafuttában válaszoltam a felvetésedre, utána jöttem rá igazából, mire is gondoltál.

    Tetszik a hozzáállásod, és egyetértek Veled a BA feladatait tekintve. Tapasztalatom szerint sajnos a legtöbbször egyirányú az információáramlás a megrendelő és a fejlesztői csapat között. (Nagyon kevés, a kód implementálásakor kialakuló tudás szivárog vissza a BA felé.)

    Ha viszont a BA benn ül a csapatban, nem jobb-e, ha maga is effektíve kódot ír? A szoftverben létrejövő, az üzleti problémát támogató modell megvalósítása során azonnali visszacsatolást kap, ezáltal a saját mentális modellje is sokkal gyorsabban fejlődik. Arról nem is beszélve, hogy az általa képviselt érdekek – az üzleti megrendelő gondolkozásának, fogalmi rendszerének leképezése – a kódban megfelelően jelenik meg.

    Szoktál kódot is írni?

  • Hesz Roland

    Jul 30th, 2010

    Azért nem feltétlen jó ha maga is kódot ír, mert a BA – ez Magyarországon eretnek gondolat, tudom – nem feltétlenül fejlesztő.
    Sőt, érdekes módon sok BA amúgy nem is szoftver projekteken dolgozik.

    Én sajnos le lettem tiltva a kódírásról – “ha meglátom, hogy kódolsz, letöröm a kezed” mondotta volt főnököm – így kicsit kikoptam belőle.
    Manapság pedig nem annyira szeretnek belevonni a kódolásba, főleg mert mint alvállalkozót, nem nagyon engednek az SVN/CVS közelébe – viszont, bizonyos szempontból aktívan részt veszek benne.

    Kódot saját projekteken írok főleg, ahol én vagyok a minden sapka :)

  • Marhefka István

    Jul 31st, 2010

    Roland: Természetesen csak akkor írjon kódot a BA, ha maga is fejlesztő, de inkább fordítva közelíteném meg a kérdést. Én olyan BA-t alkalmaznék – ha megtehetem -, aki szoftverfejlesztő is egyben.

    Miért tiltott le a főnököd a kód írásától?

  • Hesz Roland

    Jul 31st, 2010

    Mert nem azért vettek fel, hogy kódoljanak. Ez volt az ukáz. :)

    Amit egyébként mondasz egy érdekes megközelítés, és oldalakat lehetne írni róla. Írnak is.
    Egyébként ha lefordítod a BA-t, az üzletelemzőt jelent. Valakit, aki az üzletet elemzi.Biztos, hogy au üzletelemző elsődleges feladata a fejlesztő támogatása?
    Nem véletlen az ügyfélé, hogy az ügyfél rájöjjön, hogy mit is akar? :)
    A BA tevékenységek 70%-ának semmi köze a szoftverhez.
    Az üzlet céljait, folyamatait, tevékenységeit elemzi, és abban segít, hogy a célokat jól érje el az üzlet. Nem a szoftver.

    A szoftver az egy a lehetséges millió megoldás közül. Megkockáztatom, hogy az esetek túlnyomó részében amikor szoftverfejlesztés kezdődik, akkor az a lehető legrosszab megoldás.

    Ha végre talpra állok, akkor már befejezem azt a pár posztot, amit pont erről írok. Mit csinál a BA, mikor lehet alkalmazi, mire lehet alkalmazni, és így tovább.
    Én mondjuk a BA-t pont a fejlesztés megkezdése előtt vonnám be, még mielőtt eldől, hogy kell-e szoftver, hová kell a szoftver, milyen szoftver kell, és egyáltalán.

  • Marhefka István

    Jul 31st, 2010

    Roland: Amit feszegetsz, az már tényleg túl mutat a konkrét szoftverfejlesztési projekten, és nem is tudok (meg nem is akarnék) vitába szállni vele.

    Én – szoftverfejlesztőként – már csak azt az esetet tudom vizsgálni, amikor adott a szoftverfejlesztési projekt, és kell valaki, aki megérti az ügyfelet, jó esetben a szoftverfejlesztőt is, és a kettő között tud hatékonyan fordítani. Én leginkább erre az esetre gondolok, és ilyenkor – szerintem – a legjobb, ha nincs is ilyen “fordítógép”, hanem a fejlesztői csapatban van olyan ember, aki képes arra, hogy teljes egészében megtanulja és átlássa az üzletet. Ő a napi kódolási feladatain túl konzultál is az ügyféllel, ezáltal hatékonyan képes megosztani mindkét oldal irányába az újonnan szerzett ismereteket.

  • Progmatos

    Nov 2nd, 2012

    “Nagyon sok rosszal találkoztam, akikkel állandóan vitáznom kellett. Ha új környezetbe kerülök, előre félek attól, hogy olyanokkal hoz össze a sors, akikkel majd később vitáznom kell, és meg kell győznöm őket a saját igazamról.

    [...]

    Akar valaki még egyáltalán “sok tapasztalattal” rendelkező, magától elszállt szoftverfejlesztőt felvenni sok pénzért?”

    Szóval nem szereted a sok beképzeld fejlesztőt, akik azt hiszik, hogy mindent tudnak, pedig igazából TE tudsz mindent. :) Ez kb. olyan, mint amikor a bolod közli, hogy a másik bolond nem lehet Napóleon, hiszen ő az.

  • Marhefka István

    Nov 2nd, 2012

    programatos: A cikk megírása óta 2 és fél év telt el. Azóta már saját nemzetközi vállalkozásban dolgozom, amibe nem kevés saját pénzt raktam be.

    Az a mostani elképzelésem, hogy a legtöbb “tapasztalt” szoftverfejlesztő nem éri meg a pénzét. Ha saját innovatív vállalkozást építesz, akkor sokszor jobban jársz a fiatalabbakkal. Csomó ötletük van (sok persze nem annyira jó), lelkesek, és a “szakértőkkel” ellentétben nem állandóan ugyanazokat a dogmákat fujják, és fikáznak.

    Ha egy jó környezetet tudsz nekik biztosítani, oda figyelsz arra, amit mondanak, és folyamatosan visszajelzéseket adsz nekik, fejlődési lehetőséget és perspektívát, jobban jársz velük, mint a “nagyokosokkal”, akik csak nagyvállalati környezetben képesek dolgozni, ahol sokszor arról szól a dolog, hogy középszerű munkával, hogyan dolgozunk rahedli pénzért, bonyolult, de érdektelen projekteken. (Én ilyenből láttam sokat.)

    És közben a fiatalok is meg fogják kérdőjelezni, amit mondasz. Csak nekik nincs veszítenivalójuk a megszerzett tudásuk miatt…

Leave a Comment


  • RSS JTechLog – Viczián István java blogja


    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693
  • RSS Tajti Ákos C és Java blogja

  • RSS QualityOnTime

  • RSS Adaptive PM

  • RSS Menedzsmentor blog

  • Shelfari: Book reviews on your book blog