Adatok
develop
34 bejegyzést írt és 8 hozzászólása volt az általa látogatott blogokban.
Projektmenedzsment, alkalmazásfejlesztés
Online feladat- és projektmenedzsment rendszer
2014.06.03 23:28:21
Frissítésre került a demo.evolutionsuite.hu címen elérhető online feladat- és projektkezelő alkalmazás, mely hasznos segítség lehet a néhány fős fejlesztőcsapatoktól, a 15-20 fős cégek részére is, akik akár 3-5 projektmenedzser kollégával is rendelkeznek.
A fejlesztők és a…..
Hosszú kihagyás után újra billentyűzetet ragadok. 7 és fél év után új, motiváló és inspiráló munkahelyet kerestem magamnak. Szakmailag az utolsó 1-2 év langyos víz volt, ezért is örülök, hogy váltottam. Az új helyen újra fejlesztek, tervezek, kódot elemzek.
A váltással…..
Készítettünk egy internetes oldalt, ahol egyszerűen, gyorsan és ingyenesen tudsz online űrlapokat és kérdőíveket készíteni - ezt szeretném most a figyelmetekbe ajánlani.
Az volt a célunk, hogy egy általánosan és széleskörűen használható megoldást készítsünk, aminek a…..
Csapatunk töretlen lendülettel fejleszti az online projektmenedzsment szoftverünket, amihez most Te is hozzájárulhatsz! Munkánk segítése érdekében kérjük, töltsd ki a kérdőívünket!
Ez neked csak 3 perc, nekünk viszont felbecsülhetetlen segítség...
Projektmenedzsment, alkalmazásfejlesztés
Ön mennyi időt tölt a szükséges dokumentumok és e-mailek keresgélésével?
2012.12.15 23:24:30
Bármilyen precízen is kezeljük az irodai vagy az ügyfeleinkkel folytatott kommunikációnkat, gyakran előfordul, hogy nem találjuk meg azonnal a szükséges anyagokat a számítógépünkön, vagy azt az e-mailt, amiből visszakereshetnénk egy ügyfél válaszát, esetleg valamilyen…..
Projektmenedzsment, alkalmazásfejlesztés
Legyen teljes ellenőrzése projektjei felett!
2012.11.26 22:45:29
Egy vállalkozás sikeres működéséhez kiemelkedően fontos az értékesített termék vagy szolgáltatás minősége. Van azonban egy másik kulcsfontosságú tényező is, amiről néha hajlamosak vagyunk megfeledkezni: alkalmazottaink munkájának minősége és hozzáállása a cég…..
Feladatok és projektek az ipar számos területén előfordulnak, legyen az webes fejlesztés, építészeti tervezés vagy éppen ipari szerkezetek gyártása.
A cél minden esetben a folyamatok optimalizált elvégzése, a határidők- és költségkeretek betartása, valamint az…..
Bár őszintén szólva a grid téma kapcsán arra számítottam, hogy a hazai webdizájnerek, sitebuilderek közül 3-nál többen elmondják szakmai véleményüket, és ezzel egy elég fontos alapkérdésben láthatunk tisztábban, végül ez mégsem következett be. Igaz ugyan, hogy páran…..
A belső folyamatok menedzselésén túl a projektvezető feladatai közé tartozik az ügyfelekkel való kapcsolattartás is, aki a beérkező kéréseket továbbítja a kollégáknak, és az elkészült munkákról értesítést küld az ügyfélnek.
A kommunikációk általában e-mailes és…..
A több részvevős feladatok vagy projektalapú munkák során több munkatárs együttes, összehangolt munkájára van szükség. A projektvezető törekszik a feladatokat úgy kiadni, hogy az a teljes csoportra nézve a leghatékonyabb legyen. Fontos szempont a feladatok felügyelete és…..
Új funkciókkal és megújult felülettel elérhető a PM projekt menedzser új változata.
Tesztelési lehetőség a http://demo.evolutionsuite.hu/project oldalon...
A projektmenedzsment rendszer új funkcióiról és fejlesztéseiről folyamatosan értesülhetsz a http://pm.ahaa.hu/changes címen.Próbáld ki Te is a PM új lehetőségeit! Ha saját környezetet szeretnél, írj a pm@ahaa.hu címre...
2012. február 28-án, a SzegedTech rendezvénysorozat februári állomásán Projektmenedzsment a gyakorlatban című előadáson mutattam be az általam fejlesztett projektmenedzsment eszköz lehetőségeit és alkalmazásának előnyeit.Az előadáshoz készített bemutató anyag…..
SzegedTech Meetup Hallottál már a SzegedTech meetupról? Nyílt forráskódú technologiákkal foglalkozó webfejlesztők gyülnek össze minden hónapban, előadásokat szervezünk, szakmai dolgokról beszélgetünk, ahol a megannyi szakmai rész mellett új ismeretségek, baratságok születnek.…..
A hozzánk küldött észrevételek alapján új felhasználói felületet kapott a PM!Segítsd Te is az alkalmazás elkészítését, hogy mi is segíthessük a munkádat! Próbáld ki a DEMO változatot a pm.ahaa.hu/project címen, és írj a pm@ahaa.hu címre.Küldd el a hibákat, az…..
Projekt menedzselés gyorsan és egyszerűen: pm.ahaa.hu..
Az előadás anyaga a http://develop.blog.hu/media/2011-03-22_refactoring_eloadas_szabo-gabor.pdf címen tölthető le...
Projektmenedzsment, alkalmazásfejlesztés
Refactoring előadás a Szeged Tech Meetupon
2011.03.06 14:17:00
A 2011. március 22-én 17-órai kezdettel megrendezésre kerülő Szeged Tech Meetupon előadást tartok a Refactoring, avagy a forráskód minőségének javítása címmel.Az előadásra a rendezvény oldalán, a http://szegedtech.org/ címen lehet jelentkezni.Az előadással…..
Projektmenedzsment, alkalmazásfejlesztés
A paraméterátadás egyszerűsítése objektumparaméter használatával (2. rész)
2011.03.02 23:35:00
pre.code {
background-color: #eee;
border: 1px solid #CCC;
color: #333;
display: block;
margin: 20px 25px;
padding: 10px 10px 10px 21px;
font-family: courier;
}
pre.code strong {
font-family: courier;
background-color: #ddd;
}
}
A 2. részben a paraméterek számának…..
Projektmenedzsment, alkalmazásfejlesztés
Refactoring, avagy a forráskód minőségének javítása
2010.07.25 15:24:00
Az alkalmazások fejlesztése során utasításokat, parancsokat írunk le. Ezekből állítjuk össze a kívánt algoritmust, amiből aztán az üzleti logikának megfelelő folyamat keletkezik. Ugyanakkor nem mindegy, hogy a keletkezett forráskód milyen minőséget képvisel. Az…..
develop
2011.02.05 15:26:50
@deejayy:
Robert C. Martin Tiszta kód című könyve azt írja, hogy legjobb, ha nincs szükség paraméter átadására. Az 1, 2 - esetleg 3 - paraméter átadása még megengedett, de ha több paraméterre van szükség, akkor ott nyomós oknak kell lenni.
Azt gondolom, hogy ha a kód nagy része betartja ezt a szabályt (max 3 paraméter), akkor annyira nincs nagy baj a hívásokkal.
Ha egy hívás során sok (4, 5, ...) paraméter átadására van szükség, akkor ott már a kód többi része sincs rendben.
Robert C. Martin Tiszta kód című könyve azt írja, hogy legjobb, ha nincs szükség paraméter átadására. Az 1, 2 - esetleg 3 - paraméter átadása még megengedett, de ha több paraméterre van szükség, akkor ott nyomós oknak kell lenni.
Azt gondolom, hogy ha a kód nagy része betartja ezt a szabályt (max 3 paraméter), akkor annyira nincs nagy baj a hívásokkal.
Ha egy hívás során sok (4, 5, ...) paraméter átadására van szükség, akkor ott már a kód többi része sincs rendben.
develop
2011.02.23 23:16:47
@deejayy: A paraméterek számának csökkentése miatt nem a legjobb megoldás, ha egy tömbbe gyömöszöli az ember az értékeket. :)
Az első kommented alapján született meg ez a post:
develop.blog.hu/2011/02/05/parameteratadas_egyszerusitese_a_parameterek_szamanak_csokkentesevel
Ami az 5 (vagy több) paraméteres hívásokat illeti, ha találkozol ilyennel, küldd el (szabo.public@freemail.hu), szívesen megnézem. Ha publikus, egy cikkben is megírhatjuk.
Az első kommented alapján született meg ez a post:
develop.blog.hu/2011/02/05/parameteratadas_egyszerusitese_a_parameterek_szamanak_csokkentesevel
Ami az 5 (vagy több) paraméteres hívásokat illeti, ha találkozol ilyennel, küldd el (szabo.public@freemail.hu), szívesen megnézem. Ha publikus, egy cikkben is megírhatjuk.
Projektmenedzsment, alkalmazásfejlesztés
A paraméterátadás egyszerűsítése a paraméterek számának csökkentésével (1. rész)
2011.02.05 15:27:00
pre.code {
background-color: #eee;
border: 1px solid #CCC;
color: #333;
display: block;
margin: 20px 25px;
padding: 10px 10px 10px 21px;
font-family: courier;
}
pre.code strong {
font-family: courier;
background-color: #ddd;
}
}
Az üzleti logika megvalósítása során a…..
Projektmenedzsment, alkalmazásfejlesztés
Új alkalmazott felvétele, fejlesztő munkakörbe
2011.01.23 21:24:00
Egy új kolléga foglalkoztatása mindig több erőforrást igényel a cégektől, mint egy régi, rutinos kolléga folyamatos feladattal való ellátása. Ügyelnünk kell arra, hogy az új elvárásokat minél pontosabban ismertessük meg az új alkalmazottal, ugyanakkor fontos szempont, hogy a…..
develop
2011.01.25 22:02:16
@GregM: Bizonyos esetekben lehet, hogy tényleg túlzó a 10-16 óra.
Azt gondolom, hogy egy nagyobb feladattal talán jobban lemérhető egy jelentkező felkészültsége, illetve egy ekkora feladat láttán egy gyengébb képességű jelentkező bizonyára már az első lépésnél elbukik. (Utóbbi esetben a cég is időt spórol azzal, hogy feleslegesen nem kell átnézni egy gyenge minőségű munkát.)
Másik gondolatom, hogy a jelentkező a kiírt feladat alapján is prioritizálni tudja a céget. Valószínűleg oda fogja inkább beadni a jelentkezését és az elkészült munkát, ahol szakmailag várhatóan nagyobb kihívások elé fogják állítani.
Ha egy programozó által elkészült munka áttekinthető, rugalmasan módosítható és nem utolsó sorban belefér a kiadott óraszámokba, akkor tényleg nem kell tudnia vakon gépelni.
Bár továbbra is azt gondolom, hogy az segít. :)
Mindenképpen valamilyen framework-öt kell használni, de ezek nem minden igényre nyújtanak megoldást.
Ilyenkor viszont maradnak az osztálykönyvtárak.
Azt gondolom, hogy egy nagyobb feladattal talán jobban lemérhető egy jelentkező felkészültsége, illetve egy ekkora feladat láttán egy gyengébb képességű jelentkező bizonyára már az első lépésnél elbukik. (Utóbbi esetben a cég is időt spórol azzal, hogy feleslegesen nem kell átnézni egy gyenge minőségű munkát.)
Másik gondolatom, hogy a jelentkező a kiírt feladat alapján is prioritizálni tudja a céget. Valószínűleg oda fogja inkább beadni a jelentkezését és az elkészült munkát, ahol szakmailag várhatóan nagyobb kihívások elé fogják állítani.
Ha egy programozó által elkészült munka áttekinthető, rugalmasan módosítható és nem utolsó sorban belefér a kiadott óraszámokba, akkor tényleg nem kell tudnia vakon gépelni.
Bár továbbra is azt gondolom, hogy az segít. :)
Mindenképpen valamilyen framework-öt kell használni, de ezek nem minden igényre nyújtanak megoldást.
Ilyenkor viszont maradnak az osztálykönyvtárak.
develop
2011.01.27 00:03:19
@LevelUP:
Tegyük fel, hogy valóban azonos fizetést kínálnak.
Én a példa alapján az összes helyre beadnám. (Lévén Mo.-on vagyunk, nem válogathatunk. :)
Viszont a második esetben is mindhárom helyre beadnám. Bár szakmailag az első a kihívás, de a többit sem szabadna veszni hagyni.
Mivel a példa szerint profi a jelentkező, így mindhárom helyre felvennék. :) Ekkor már azt gondolom, hogy a szakmai kihívás fogja eldönteni a sorrendet.
(Hacsak nem éppen a szomszédban van a másik munkahely. Mert ugye akár ez is szempont lehet.)
Én nem érzem magam profinak, mégis fontos számomra a szakmai kihívás.
De ugye nem vagyunk egyformák. :)
Tegyük fel, hogy valóban azonos fizetést kínálnak.
Én a példa alapján az összes helyre beadnám. (Lévén Mo.-on vagyunk, nem válogathatunk. :)
Viszont a második esetben is mindhárom helyre beadnám. Bár szakmailag az első a kihívás, de a többit sem szabadna veszni hagyni.
Mivel a példa szerint profi a jelentkező, így mindhárom helyre felvennék. :) Ekkor már azt gondolom, hogy a szakmai kihívás fogja eldönteni a sorrendet.
(Hacsak nem éppen a szomszédban van a másik munkahely. Mert ugye akár ez is szempont lehet.)
Én nem érzem magam profinak, mégis fontos számomra a szakmai kihívás.
De ugye nem vagyunk egyformák. :)
develop
2011.01.29 11:43:36
@fchris82:
Projektvezetőként sajnos kevés beleszólásom van az új emberek felvételébe. (A mai napig ugyanazt a teszt feladatot szoktuk kiadni, mint amivel annó én kerültem fejlesztőként a céghez.)
Teljesen egyetértek azzal, amit leírtál. Nem is kommentálom, magáért beszél. :)
Azt gondolom, hogy a Ti módszeretek valóban "fájdalommentesebb", mintha csak a próbaidő alatt derülne ki egy fejlesztőről, hogy nem üti meg a mércét.
Tapasztalatból mondom. :(
Projektvezetőként sajnos kevés beleszólásom van az új emberek felvételébe. (A mai napig ugyanazt a teszt feladatot szoktuk kiadni, mint amivel annó én kerültem fejlesztőként a céghez.)
Teljesen egyetértek azzal, amit leírtál. Nem is kommentálom, magáért beszél. :)
Azt gondolom, hogy a Ti módszeretek valóban "fájdalommentesebb", mintha csak a próbaidő alatt derülne ki egy fejlesztőről, hogy nem üti meg a mércét.
Tapasztalatból mondom. :(
Projektmenedzsment, alkalmazásfejlesztés
Céges tudásbázis, osztálykönyvtárak építése
2011.01.25 22:40:00
Nap mint nap találkozhatunk olyan feladattal, aminek az elkészítése - rajtunk kívül álló okok miatt -, több időt igényel a tervezett óraszámnál. Belefuthatunk egy nem ismert - pl. PHP - bugba, vagy akár a saját kódbázisunk is olykor megviccelhet minket.Az is…..
A szinte mindig szoros fejlesztési időket tekintve jogosan merül fel a kérdés, hogy a kód refaktorálása nem igényel-e plusz erőforrásokat, és nem veszélyezteti-e a projekt határidejét? Azt gondolom, hogy rutinos fejlesztők esetében a refaktorálás nem okozhatja a fejlesztés…..
develop
2010.08.30 22:24:53
@ALW: Kedves ALW!
Egy webes alkalmazásokat fejlesztő cégnél dolgozom alkalmazásfejlesztési projektvezetőként, lassan 4. éve.
A fejlesztés ideje alatt törekedni kell a veszteségek minimalizálására, vagyis a felesleges plusz idők elkerülésére.
Emiatt pontosan az ügyfél igényeit kell kielégítenünk (ne fejlesszünk többet, mint amit kifizet), ne legyen szükség utólagos módosításra, és csökkentsük a hibajavítások számát.
Ezeket korrekt specifikációval, megbeszélésekkel, rutinos fejlesztőkkel, és a kód megfelelő minőségével tudjuk elérni.
Ez utóbbit pedig refaktorálással igyekszünk biztosítani.
Tapasztalatom szerint egy megfelelően refaktorált kódot rugalmasabban, gyorsabban lehet az újabb igényekre szabni, könnyebb új funkciókkal kiegészíteni.
Emiatt kevesebb időt igényel az elkészítése is.
(A fejlesztési folyamatok optimalizálásával is tudunk faragni az időkön.)
Abban igazad van, hogy a refaktorálást nem lehet "beletervezni" a projektbe.
Veled ellentétben viszont úgy gondolom, hogy nem is kell!
(Persze ez csak akkor biztosítható, ha a kód már az elkészültekor "refaktorált".)
Van egy másik dolog is, amivel nem értek Veled egyet.
Szerintem hibásan gondolod, hogy a projekt végén kellene refaktorálni.
Véleményem szerint refaktorálni a (rész)feladat elkészülte és a tesztelésre való átadása előtt kell, vagyis jóval a projekt lezárása előtt.
Így az egymásra épülő funkciók elkészítése során is lehetőséged van időt megtakarítani.
(Ráadásul, így könnyebben tudsz reagálni az esetlegesen megváltozott ügyfél-igényekre.)
Felszabaduló idő alatt pedig olyan idő értek, amit a veszteségek felszámolásával "spóroltál" meg a fejlesztésen.
Ilyen lehet a projekten lévő fel nem használt tartalék, a garanciális időre kalkulált idő (persze, ha nem emészted fel a hibák javításával), illetve a fent is említettek.
Egy webes alkalmazásokat fejlesztő cégnél dolgozom alkalmazásfejlesztési projektvezetőként, lassan 4. éve.
A fejlesztés ideje alatt törekedni kell a veszteségek minimalizálására, vagyis a felesleges plusz idők elkerülésére.
Emiatt pontosan az ügyfél igényeit kell kielégítenünk (ne fejlesszünk többet, mint amit kifizet), ne legyen szükség utólagos módosításra, és csökkentsük a hibajavítások számát.
Ezeket korrekt specifikációval, megbeszélésekkel, rutinos fejlesztőkkel, és a kód megfelelő minőségével tudjuk elérni.
Ez utóbbit pedig refaktorálással igyekszünk biztosítani.
Tapasztalatom szerint egy megfelelően refaktorált kódot rugalmasabban, gyorsabban lehet az újabb igényekre szabni, könnyebb új funkciókkal kiegészíteni.
Emiatt kevesebb időt igényel az elkészítése is.
(A fejlesztési folyamatok optimalizálásával is tudunk faragni az időkön.)
Abban igazad van, hogy a refaktorálást nem lehet "beletervezni" a projektbe.
Veled ellentétben viszont úgy gondolom, hogy nem is kell!
(Persze ez csak akkor biztosítható, ha a kód már az elkészültekor "refaktorált".)
Van egy másik dolog is, amivel nem értek Veled egyet.
Szerintem hibásan gondolod, hogy a projekt végén kellene refaktorálni.
Véleményem szerint refaktorálni a (rész)feladat elkészülte és a tesztelésre való átadása előtt kell, vagyis jóval a projekt lezárása előtt.
Így az egymásra épülő funkciók elkészítése során is lehetőséged van időt megtakarítani.
(Ráadásul, így könnyebben tudsz reagálni az esetlegesen megváltozott ügyfél-igényekre.)
Felszabaduló idő alatt pedig olyan idő értek, amit a veszteségek felszámolásával "spóroltál" meg a fejlesztésen.
Ilyen lehet a projekten lévő fel nem használt tartalék, a garanciális időre kalkulált idő (persze, ha nem emészted fel a hibák javításával), illetve a fent is említettek.
develop
2011.01.25 21:41:44
@ytg: A magyar megfelelő használatával kapcsolatban igazad van.
Mint ahogy a kód elkészítésével kapcsolatosan is.
Szerencsére szabotázzsal még nem találkoztam, új, rossz kóddal viszont már igen.
Közrejátszhat - amit írtál is -, hogy a fejlesztő nem tudja jól megírni, illetve nem látja, hogy ha jól írja meg, mennyi előnye származik belőle. (Nem csak neki, hanem a kollégának, aki utána nyúl esetleg hozzá.)
Ha nem ismeri az előnyöket, nem is lesz igénye rá, hogy jobb kódot írjon.
Én most is azt mondom, hogy meg kell előzni a "bajt", és fel kell készíteni a kollégákat, hogy jó és rugalmas kód kerüljön ki a kezük közül. (Ne utólag kelljen faragni.)
Mint ahogy a kód elkészítésével kapcsolatosan is.
Szerencsére szabotázzsal még nem találkoztam, új, rossz kóddal viszont már igen.
Közrejátszhat - amit írtál is -, hogy a fejlesztő nem tudja jól megírni, illetve nem látja, hogy ha jól írja meg, mennyi előnye származik belőle. (Nem csak neki, hanem a kollégának, aki utána nyúl esetleg hozzá.)
Ha nem ismeri az előnyöket, nem is lesz igénye rá, hogy jobb kódot írjon.
Én most is azt mondom, hogy meg kell előzni a "bajt", és fel kell készíteni a kollégákat, hogy jó és rugalmas kód kerüljön ki a kezük közül. (Ne utólag kelljen faragni.)
Ismét egy olyan problémát veszek elő, ami miatt nehezebb lehet a kód olvasása, az algoritmus megértése. Ez pedig az, ha az elnevezés, a típus és az érték nincs szinkronban egymással. Vagyis ha az elnevezésben van utalás a tárolt/visszaadott érték típusára, akkor az…..
Belépve többet láthatsz. Itt beléphetsz
A Trellot én is kipróbáltam. A Kanban táblája is könnyen használható, de nagy hiányossága volt, amikor néztem, hogy nem találtam benne olyan megoldást, ami az elszámolást, vagy az egy feladatra fordított idő rögzítését segítette volna.
Mivel magáncélra (is) kerestem PM megoldást így mindenképpen olyat szerettem volna, ami minden - a cégnél eddig felmerült-, és a magánjellegű igényeimet is kielégíti.
A nagy keresgélésnek az lett a vége, hogy elkezdtem magam írni egy alkalmazást, amit saját célra már a kezdetektől fogva használok. Cél volt, hogy a feladatokat folyamatokban tudjam kezelni (teendő-folyamatban-készre jelentett-ügyfélnél-lezárt), és ezeket vizuálisan, kanban táblában is lássam.
Persze ennek a saját megoldásnak is megvannak még a gyerekbetegségei meg a hiányosságai, pláne egy több éve, nagy csapat által fejlesztett alkalmazásokhoz képest, de a lendület és a fejlődés töretlen. :)
A PM-ről bővebben: evolutionsuite.hu/
(A keresgéléseim közepette viszont a több tucat külhoni megoldás mellett nem találtam szinte semmilyen magyar, még aktívan fejlesztés alatt lévő eszközt.)