Innovatív webalkalmazás fejlesztés Heroku platformra

Webalkalmazás Heroku-n magánügyfeleknek

A Webalkalmazás Heroku-n akkor jó választás, ha egy böngészőből használható megoldást szeretnél gyors indulással, távoli fejlesztéssel és külön szerverüzemeltetés nélkül. A lényeg egyszerű. A fejlesztő elkészíti vagy átalakítja az alkalmazást, beállítja a futtatási környezetet, kezeli az adatbázist, majd átadja a működő rendszert és a hozzáféréseket. Magánügyfélként ez akkor hasznos, ha nem nagy céges folyamatot akarsz, hanem érthető megoldást egy konkrét feladatra.

Én azt látom, hogy sok ügyfél nem magát a felhőt keresi, hanem azt, hogy a projekt végén legyen egy stabilan elérhető felület. Lehet ez foglalási rendszer, belső nyilvántartás, ügyfélkapu, egyszerű rendeléskezelő, adatbekérő oldal vagy egy kisebb üzleti eszköz. A Heroku alapú webes alkalmazás előnye, hogy a fejlesztés, a próba és az élesítés jól elkülöníthető. Nem kell személyes találkozó. A megbeszélés, a fájlátadás, a próba és a javítás is online történik.

A Qjob.hu felületén magánszemélyek is találhatnak olyan szabadúszó fejlesztőt, aki nem általános ígéretekkel dolgozik, hanem konkrét feladatot vállal. Szerintem ez ennél a témánál különösen fontos. A Heroku sok mindent leegyszerűsít, de nem oldja meg helyetted a rosszul megírt kódot, a hiányos adatmodellt vagy a pontatlan igényeket.

Heroku webalkalmazás felhasználási helyzetek

A Heroku webalkalmazás főleg akkor praktikus, ha a projektnek gyorsan kell elindulnia, de később is maradjon mozgástér. Egy magánügyfél gyakran nem teljes vállalati rendszert kér. Inkább egy pontosan körülírt eszközt, amely megspórol napi kézi munkát. Például űrlapból adatbázisba mentett kéréseket, belépéshez kötött tartalmat, e mail értesítéseket, egyszerű irányítópultot vagy külső szolgáltatások összekötését.

Tapasztalatom szerint a legjobb indulás az, ha a feladat nem túl nagy, de mérhető. Egy fejlesztő könnyebben ad jó árat és határidőt, ha látja, milyen oldal kell, hány szerepkör lesz, milyen adatokat kell tárolni, és mi számít kész eredménynek. Sokan ott hibáznak, hogy csak annyit írnak, kell egy webalkalmazás. Ez kevés. A szakember ilyenkor vagy sokat kérdez, vagy túl általános ajánlatot ad.

A távoli munka itt nem hátrány. Sőt, gyakran tisztább. A fejlesztő megosztott dokumentumban kapja meg az igényeket, képernyőképen mutatja a tervet, próbakörnyezetben ad hozzáférést, majd javítási köröket egyeztet. Így látszik, hol tart a munka. A megrendelő sem csak a végén szembesül az eredménnyel.

Webalkalmazás Heroku-n árak

A Webalkalmazás Heroku-n ára erősen függ attól, hogy új fejlesztésről, javításról, költöztetésről vagy üzembe helyezésről van szó. A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent, mert kimarad a hibakezelés, a jogosultságok ellenőrzése vagy a dokumentálás. De a drága ajánlat sem mindig jobb. A jó ár mögött érthető feladatleírás, reális óraszám és tiszta átadás van.

Az áraknál számolni kell azzal is, hogy a platformnak lehet saját havidíja. Ezt a fejlesztői munkadíjtól külön érdemes kezelni. Magánügyfélként kérj külön bontást. Legyen világos, mi egyszeri költség, mi havi díj, és mi az, ami csak akkor jelenik meg, ha nő a forgalom vagy bővül az adatbázis.

Heroku fejlesztő kiválasztása

A Heroku fejlesztő kiválasztásánál nem az a legfontosabb, hogy hány technológiát sorol fel. Inkább az számít, hogy érti e a telepítést, az adatbázist, a naplózást, a verziókezelést és az átadás felelősségét. Egy jó szakember nem csak kódot ír. Megkérdezi, ki fogja használni a rendszert, milyen adat kerül bele, mi történjen hiba esetén, és kihez tartozzanak a hozzáférések.

Érdemes portfóliót kérni, de nem kell minden munkának nyilvánosnak lennie. Sok online alkalmazás belső célra készül. Ilyenkor elég lehet egy rövid leírás arról, milyen problémát oldott meg a szakember. Kérdezz rá arra is, hogyan adja át a munkát. Lesz e rövid kezelési útmutató. Megkapod e a forráskódot. Kié lesz a Heroku fiók. Ezek apró kérdéseknek tűnnek, de később komoly vitákat előznek meg.

Szerintem az is jó jel, ha a fejlesztő nem vállal mindent azonnal. Ha előbb látni akarja a jelenlegi kódot vagy pontosítani akarja a folyamatot, az nem akadékoskodás. Inkább azt mutatja, hogy nem becsül vaktában.

Webes alkalmazás távoli munkafolyamata

Egy webes alkalmazás távoli fejlesztése általában rövid igényfelméréssel kezdődik. A megrendelő leírja, mit szeretne elérni, milyen felhasználók lesznek, milyen adatokat kell kezelni, és mi a határidő. Ezután jön a feladat bontása. Nem minden kerül az első verzióba. Tapasztalatom szerint a túl nagy első kör gyakran csúszáshoz vezet.

A következő lépés a technikai döntés. Milyen keretrendszer legyen, kell e adatbázis, szükséges e belépés, lesz e külső kapcsolódás, és hogyan történik a Heroku beállítása. Ezután készülhet próbakörnyezet. Itt az ügyfél már rákattinthat az oldalra, kipróbálhatja a folyamatot, és jelezheti, ha valami nem érthető.

Volt olyan eset, amikor egy ügyfél egy egyszerű belső jelentéskészítő felületet kért. Elsőre csak adatfeltöltést és táblázatos nézetet szeretett volna. A próba után derült ki, hogy kétféle jogosultság is kell, mert nem mindenki láthat minden sort. Mivel a feladat részekre volt bontva, nem kellett újrakezdeni a projektet. Csak a következő ütembe került a jogosultsági rész.

Az átadásnál legyen lista. Milyen linkeken érhető el a rendszer, milyen fiókok vannak, hol vannak a környezeti változók, hogyan lehet új verziót feltölteni, és ki végzi a későbbi karbantartást. Egy magánügyfélnek nem kell mindent műszaki mélységben értenie, de az alapoknak átláthatónak kell lenniük.

Heroku alapú fejlesztés gyakori hibái

A Heroku alapú fejlesztés egyik gyakori hibája, hogy a megrendelő csak a kész felületet nézi, a háttérfeltételeket nem. Pedig fontos, hogyan indul újra az alkalmazás, hol tárolódnak az adatok, hogyan kezeli a rendszer a fájlokat, és van e tartalék megoldás hiba esetén. Egy szép belépőoldal önmagában nem jelent stabil működést.

Sokan ott hibáznak, hogy nem különítik el a próba és az éles környezetet. A tesztadatok összekeverednek a valós adatokkal, a javítás pedig közvetlenül az éles rendszerben történik. Ez kockázatos. Egy figyelmes szakember legalább alap szinten külön kezeli a fejlesztési és az éles állapotot.

Másik gond a homályos határidő. A lehető leghamarabb nem határidő. Jobb megadni egy napot, és mellé azt, hogy melyik funkció a legfontosabb. Így a fejlesztő tud dönteni, mit kell előre venni. Én azt látom, hogy a jó sorrend sokszor többet ér, mint a hosszú kívánságlista.

Heroku webalkalmazás átadás és minőség

A Webalkalmazás Heroku-n akkor tekinthető késznek, ha nem csak elindul, hanem használható is a megbeszélt célra. A megrendelőnek meg kell kapnia a belépési adatokat, a fő linkeket, a rövid kezelési leírást és a javítási körök lezárását. Nem elég annyi, hogy működik nálam. Online munkánál különösen fontos, hogy az ügyfél a saját eszközén is kipróbálja a rendszert.

A minőség nem mindig látványos. Néha abban jelenik meg, hogy a hibás adat nem töri el az oldalt, a rendszer érthető üzenetet ad, a lassú kérés nem okoz teljes leállást, és a fejlesztő jelzi, ha egy ötlet túl költséges lenne az első verzióhoz. Szerintem ez korrekt hozzáállás. Nem minden igényt kell azonnal megvalósítani. De amit elkészítenek, annak követhetően kell működnie.

Ha később bővítés kell, a korábbi döntések sokat számítanak. Egy rendezett forráskód, tiszta beállítás és rövid dokumentáció megkönnyíti a folytatást. Egy gyorsan összerakott, de át nem adott rendszer viszont később drágább lehet, mint amennyit az elején megtakarítottál.