Az október a céges ügyeimtől kaotikus, de érezhetően tisztább napról napra a helyzet. Ma nekiültem, hogy megfogalmazzam, és lerajzoljam az idealap.kft-t, a tevékenységeket, a "lábakat" és azt, hogy miből fogunk megélni.

Az alábbiakban az első két egységet adom közre ebből a credo-szerű anyagból.

Alapkövek

Csapatunk hisz abban, hogy partnerei is abban érdekeltek, hogy egységnyi idő alatt a legjobb munka szülessen. Ezért az idealap.kft nem megy bele kétes kimenetelű árversenyekbe, és nem kerekíti pofátlanul felfelé a végösszeget, amikor megbízási díjas projekteken dolgozik.

Hogy ez tartható legyen, együttműködéseinkben arra törekszünk, hogy az egységáras projekt alapú megbízások helyett kisebb részekre osztott munkafolyamatokat rendeljenek meg tőlünk, amelyek egyrészt azonnali és látható eredményeket hoznak, másrészt könnyebben felmérhető a munkaidő. Így a megvalósításra koncentrálhatunk és nem a rosszul belőtt keretek miatt görcsölünk. Folyamatos kommunikációval és transzparens projektmenedzsmenttel minden percben átlátható, hogy mibe kerül a munkánk és hol tartunk a feladatok elvégzésében.

Erre a Projektivo CPM technológiát és keretrendszert használjuk. Ez egyrészt jelenti az előzőekben ismertetett felfogást, másrészt egy online projekt-kezelő felület használatát is magában foglalja, amit minden partnerünkkel megosztunk.

Küldetésünk

Minőségi és korszerű webes megoldások tervezése és kivitelezése partnereink számára.

Olyan partnerkapcsolatok kiépítése, amelyeken keresztül a csapatunk számára fontosnak tartott Not-For-Profit területek is nyernek.

Célunk egyrészről a köztéri művészettel, másrészről pedig a pénzügyi kultúrával kapcsolatos széles ismeretátadás és valódi értékek megteremtése, amelyekkel óvjuk, gyarapítjuk és népszerűsítjük ezeket a területeket.

Most nem annyira szakmai, inkább mérföldköves életesemény-összegző írás következik. Történetesen csütörtökön alapítottam meg a cégemet, idealap kft. néven. Október egytől otthagyom jól fizető és elsősorban rettentő stabil állásomat, hogy felcseréljem egy bizonytalan, lényegesen több munkával járó környezetre.

Otthon fogok dolgozni, nem körúti kávézókban vagy a Colabs-ben, és egyébként sem akarok a freelancer csöbörbe zuttyanni rögtön. Már csak azért sem, mert van MUNKÁM. Vannak megbízásaim és van egy rakat ötletem, amihez csend kell, és tökéletes körülmények (folyamatosan megfelelő minőségű zöld tea).

Igen, azt is tudom, hogy divatos és népszerű dolog mostanában panaszkodni, hogy mennyire lehetetlen vállalkozni, hogy ki kinek mennyi nem adna munkát. Ezt most nagyon messze teszem félre, aztán meglátjuk, hogy tényleg sikerül-e.
5 éve elkerülöm a tévét, fél éve a netes híreket sem követem - legalábbis a politikai és egyéb gány-aktualitásokat (webes dolgokban otthon próbálok lenni folyamatosan). Ennek köszönhetően teljesen semlegesnek érzem a piaci helyzetet, ami ugye tuti, hogy téves észlelés, de ha máskor igazat adunk a nem-látom-nem-fáj elvnek, akkor itt is be kell jönnie annak, hogy szellemileg meglehetősen szabad vagyok ezektől a pillanatnyi világvégeszaroktól.

A szoborlap külföldre költözött. Egy brit szerverfarmon feleannyi pénzért kétszer akkora tárhelyet vettem. Ámulatba ejt, hogy itthon mennyi mindent el lehet adni annyiért, amennyi. Hamarosan tömeges emailt fogok küldeni az Amazon Cloud szolgáltatásán keresztül. Ezt is töredékéért annak, amennyiért itthon mérik a mailküldő rendszerek a leveleket - azt is belekalkulálva, hogy fejlesztenek hozzá olyan amilyen kampánykezelő rendszereket. Itthon minden szart el lehet adni...

Pár hete nekiültem nemaludni és készítettem egy tőzsdei szimulátort, egy valóságos árakon alapuló játékot, ami olyan, mintha egy részvénykereskedő rendszerben nyomogatnád a vétel és az eladás gombokat. Összevetve az itthon elérhető kereskedési rendszerekkel sem számít rossznak a felület, én már rákattantam. Jobb itt bukni DAX-on, mint valóságban :]

Összefoglalva, beindultak dolgok. Hét év telt el azóta, hogy egyszer már megpróbáltam saját lábamra állva boldogulni. Szinte minden életösszetevő más volt akkor, így remélem, hogy most nem ugyanaz lesz az eredmény (lassú megéhezés).

Félreértés ne essék, nem arról van szó, hogy nem szeretek dolgozni. A probléma az, hogy most már lassan 10 éve a piálós buliktól eltekintve minden éjjel ülök a gép előtt és püfölöm a billentyűzetet. Weblapokat, projekteket és álmokat hozok létre. És ez nem OK így. Nappal van agyam, éjjel már csak a felét, vagy annyit sem adom annak, amire képes vagyok. Hát akkor neki kell állni, és át kell szervezni. Ki kell próbálni, milyen lenne, ha a hobbi lenne a hivatalos munka.

Eljön mindenkinek egy olyan pillanat az életében, amikor azt érzi, hogy most vagy soha: ki kell próbálni, hogy bejön-e valami a millió ötletből, amelyek egy része már amúgy is óriásira dagadt, és nem lehet tőle aludni.
És azt hiszem, hogy nekem ez most jött el. Nem akarom bánni később, hogy kihagytam, vagy ilyesmi. Akárhogy sikerül, mindenképpen meg fogja érni, mert a legrosszabb dolgokból szoktam a legtöbbet tanulni. De a legrosszabbakon most már túl vagyok, tudom. Úgyhogy nincs más hátra, mint előre - vállalkozzunk! :)

Vajon mindenki jól csinálja, csak én vacakolok azzal, hogy megtaláljam a megfelelő technikát, és keretet arra, hogy megfelelő hatékonysággal menedzseljem a feladataimat, a projektjeimet és végső soron az időmet? Ilyen kérdések jártak a fejemben két hónapja. Hogy választ kapjak, kérdőívben interjúvoltam meg valamivel több, mint 100 ismerősömet.

Kérdőívből derülünk ki

Nagyjából 2 hét állt rendelkezésre a kitöltésre, és ez idő alatt több, mint 50 százalék válaszolt.
A válaszok alapján a következő érdekességek (is) kiderültek:

 - A válaszadók 20 százaléka használja a Gmail piszkozatot (is), mint feladatnyilvántartási eszközt
 - Szintén 20 százalék mondta, hogy okostelefonos szoftvert (is) használ erre a célra, vagyis komoly a penetráció!
 - 65% füzetbe is jegyzetel, de egyébként ezzel a legelégedetlenebb minden ezt is válaszoló
 - Amire a saját technika nem képes, de igény lenne rá: feladatok súlyozása, áttekintő nézet, csoportosítás/címkézés

El is érkeztünk a kulcsszavakhoz: áttekinthetőség, csoportosítás, címkézés, súlyozás, időigény.
Az utolsót a válaszokból csak áttételesen lehetett kihámozni, de általános problémának látszik, hogy az egyes teendőink időigényét előre megsaccoljuk, vagy utólag rögzítsük.

Kutatásaim során fény derült arra, hogy szinte senki sem elégedett teljes mértékben, és sokan rendszeresen ugrándoznak az egyes alkalmazások között, hogy megtalálják az igazit. Magyar nyelvű vagy hazai online szolgáltatás nem jelent meg a válaszokban.

Köszönöm, csinálom!

A közös diskurzus csak megerősítette bennem, hogy mindennél értékesebbek a visszajelzések. Számos szoftvert vagy online platformot ajánlottak ismerőseim, és ezek alapján még inkább kivilágosodott az irány, amerre tovább kell vinnem a fejlesztéseket. Mert idő közben elindítottam a tényleges munkát, és várhatóan szeptemberben béta verzióban elérhetővé is teszem a Projektivo névre keresztelt felületet, ahol egyszerű feladatkezeléstől, bonyolult projektmenedzsmentig, mindenféle igény megoldásra találhat.

A fejlesztés dilemmáiról és azok valamilyen megoldásáról szívesen beszámolnék, de még mindig erőteljes időhiánnyal küzdök... Azt hiszem, hogy leghamarabb a saját viszketéseimet kell megvakarnom, aztán jöhet a többieké. De talán így a legegyszerűbb, mert ha nem viszketne, honnan tudnám, hogy a legjobb a vakarás?Tisztábban fogalmazva: saját projektmenedzsment problémáim sikeres megoldása után remélem, hogy neked is ügyesebben segítek majd!

Minden cégnek CRM rendszert kellene használnia! - állítanám, ha CRM rendszerekkel lenne tele a kirakatom, de egyrészt jelenleg még nem üzemeltetek kirakatot, másrészt pedig nem hiszek abban, hogy mindenféle fájdalomra lehet gyógyír valamely piacon kapható megoldás. De miért gondolom ezt, és írom le ilyen nagyképűen?

Valós tapasztalatokra kell, hogy hivatkozzak, amikor azt állítom, hogy a cégek nagy része akkor képes ügyfélmenedzsment megoldást bevezetni, ha informatikailag és szervezetileg is készen áll a használatra. Ez azt jelenti, hogy 1.) tudja, hogy mi kell neki; 2.) valós igényekben és munkafolyamatokban segítene a CRM; 3.) a kollégák is kellően motiváltak a rendszer használatában.

Ahogy előző írásomban is említettem már, a CRM nem csak egy IT rendszer, hanem egy teljes vállalati filozófia. Ennek ellenére sok cégvezető mégiscsak egy IT valamit lát benne, és így is viszonyul hozzá. Vagyis fókuszba kerül a rendszer tökéletességének elérésére való törekvés, és sajnos sokszor háttérbe szorul a tényleges munkafolyamatok vizsgálata és az, hogy azokkal összhangban valósuljon meg a fejlesztés.

Racionális elvárás egy cégvezetőtől, hogy a fejlesztőkkel addig üljön a tervezőasztal mellett, amíg minden elvárásnak megfelelő rendszert nem terveztet meg. Ezt követőan szintén reális elvárás az, hogy egy kezdeti - oktatással egybekötött - bevezetési időszakban elfogadtassa az alkalmazást a kollégákkal. De egyenes következménye ezeknek az is, hogy az időközben módosult működési preferenciák, vagy épp a megváltozott szabályozási / technológiai háttér miatt bizonyos részleteiben a rendszer már induláskor is elavult lesz, egyes részeit egyáltalán nem fogják használni a kollégák. A kényelmetlenül használható modulok, amelyek lassítják a munkafolyamatokat, végső soron elégedetlenséget váltanak ki, amit a munka minőségének és esetleg a munkakedvnek a romlása is követhet.

Válasz lehetne erre az, hogy rettentő nagy anyagi forrás kell ahhoz, hogy egy ilyen komplex és a többi vállalati rendszerbe integrált megoldást készítsünk úgy, hogy folyamatosan, modulról modulra vizsgáljuk a tényleges munkafolyamatokat, majd megalkotunk egy demo-szintű vázat, azt tovább teszteljük, közben hozzá igazítjuk a működési szabályokat, a folyamatokat, stb. Így haladva osztályról osztályra akár egy éven belül is megszülethet a tökéletes CRM. De kinek van erre ideje és pénze? Nem is beszélve az érintett alkalmazottak extra terheléséről.

A másik égető kérdés az, hogy ténylegesen növeli-e a hatékonyságot egy CRM-rendszer, ami látszólag a vezetőség vágyait valósítja meg? Amennyiben nem középúton halad a projekt, esélyes, hogy "nem" lesz a válasz. Középutat jelenthet az, hogy a vezetőség folyamatosan a beosztottak tényleges munkafolyamatait vizsgálja, azokból indul ki, és azokat csiszolja olyanná, ami neki is tetsző eredményt hozhat. Ez az osztályonként zajló racionalizálás olyan CRM-logikát eredményezhet, ami hatékonyan és hosszú távon tudja szolgálni a működést.

Másrészről szintén lényeges szempont, hogy a rendszer folyamatos evolúcióban legyen, együtt változzon és növekedjen a szervezettel, idomuljon annak valós igényeihez és az esetleges jogszabályi, szervezeti változásokhoz.

(folyt.köv.)

Ez egy kick-off jellegű bejegyzés, ha lehet ilyet írni. Persze lehet, mert ezek a trendi szavak bármire bármikor használhatóak, ahogy látom. Tehát Customer Project Management, vagyis projekt alapú ügyfélkezelés. Vagy ügyfélkozpontú projekt menedzsment, vagy ügyfél-projekt-menedzsment. Divatosan, rövidítve: CPM. Azt hiszem, hogy ezzel ki is merítettük a lehetőségeket. Ebben a bejegyzésben egy még nem létező fogalom szülését szeretném megindítani. Megpróbálok fájdalommentesen rövid lenni, és arra is koncentrálok, hogy lásd a bejegyzés értelmét.

Mi az a CPM?

Rákerestem, más még nem mondta meg, így hát megmondom én! Ha kettészedjük, akkor így értjük: ügyfélmenedzsment koncepció + projektmenedzsment. Ha ezt összeforrasztjuk, akkor egy olyan jellegű - szintén koncepcionális - intézményt kapunk, ami meghatározza, hogy hogyan nyúlunk egy ügyfélhez, hogyan kommunikálunk vele, hogyan szervezzük meg a saját munkánkat, amelynek során az ügyfél számára eredményt szállítunk - mindezt projekteken keresztül. Mert végső soron minden akció egy projekt.

A szülők öröksége

A CRM egy vállalati filozófia, és meghatározza minden, ügyfelekkel kapcsolatos lépésünket az ügyfél teljes életpályája során (és még az előtt és után is). A CRM nem csak egy IT rendszer, hanem kommunikációs, vállalatszervezési és filozófiai keretrendszer is. Ilyenformán a CPM megörökli mindennek a rendszernek az univerzalitását, vagyis azt, hogy az ügyfélre nagytotálban nézünk és nem apró élet-szakaszokra, speciális helyzetekre koncentrálunk.

A CPM tehát egy komplex filozófiai rendszer, és ezt kiegészítendő, megörökli a projektmenedzsment szemléletet is, abból is az agilis változatot. Ez tovább színezi a koncepciót a SCRUM projektkezelés elemeivel és ismérveivel, vagyis mérföldkövekre bontott projektekkel, a sprintekkel és a gyors megbeszélésekkel.

De mi ennek az egésznek az értelme?

Úgy látom, hogy a mai kis és középvállalati szférában, kiemelten az IT környezetben működő/alkotó cégek esetében nem eléggé hatékony az ügyfélkezelés. A klasszikus CRM szabályok és rendszerek túl bonyolultak, és nem eléggé integrálják magukba a projektmenedzsmentet. Vagyis az ügyfélszerzés és megtartás egyre inkább elszakad az ügyfél által adott feladatok, a részére szállítandó fejlesztések menedzselésétől. Nincs egy olyan egységes filozófia és iránymutatás, ami összeolvasztja ezt a két területet és igazán segíti a hatékonyságot.

A CPM-ről azért szeretnék hangosan gondolkodni, mert magam is a fenti probémáktól szenvedek. Rendelkezésemre áll több tucat alternatíva a két terület megfelelő kezelésére szoftveresen és könyvekben leírt tanként is. De valahogy hiányzik az egyensúly. Bízom benne, hogy ez a gondolkodás megszül rövid távon egy olyan lehetőséget, ami az én és a ti életeteket is könnyebbé teheti. Fejlesztési kényszerem van ;]

November tizedikén írtam egy bevezetést egy gondolatfolyamhoz, ami azt hivatott bemutatni, hogy hogyan is látom a közösségi web speciális szeletét: a közösségi adatbázisok működését, lélektanát; a tagok viselkedésében megmutatkozó és a teljes oldal erővonalait.

Sokat agyaltam és érleltem magamban a témákat, és arra jutottam, hogy az egész gondolatfolyamot problémákra kihegyezve fogom levezetni. A kérdéskörökben megpróbálok állást foglalni, ami talán többeket gondolkodásra késztet, segíthet abban, hogy hogyan működtessék saját közösségeiket. Na de, kezdjünk bele az első témába.

Hogyan érhetjük el, hogy tagjaink folyamatos aktivitást mutassanak fel. Mit kell tennie az üzemeltetőnek, hogy ez hosszú távon fenntartható legyen?

A legfontosabb az, hogy nem kell erőltetni semmit. Fontos, hogy mindenki jól érezze magát a közösségben, de egy-egy személy akarata alapján nem módosítható a szájt koncepció-rendszere. Mindenkit meg kell hallgatni, biztosítani kell a fórumot a beszélgetésre és véleményezésre - de végső soron az üzemeltető dönti el, hogy mi történik a lapon.

Ez nem azt jelenti, hogy az eredeti felállás bármikor megváltoztatható. A tagok rühellik a nagy váltásokat. A folyamatos, apró módosításokban megnyilvánuló, akár dizájn-beli, akár funkcionális átalakulás sokkal elfogadottabb, és mindeközben a tagok tesztelőként viselkedve segítenek abban, hogy sikeres legyen az alakulás.

Az üzemeltető emellett csapdába eshet, ha az eredeti koncepció kidolgozatlansága, vagy a hiányzó üzleti modell miatt egy felfuttatott, hangulatos és népszerű pillanatában kezdi olyan formán alakítani a rendszert, hogy abból bevétele származzon.
Sok példát láthatunk balul elsült átalakításokra, amelyek mögött anyagi haszonszerzés állt. Holott ez a motiváció egyáltalán nem elítélendő, hiszen az üzemeltető valamiből fenn kell, hogy tartsa a vasat - de mégis sokan esnek át a ló túloldalára. A közösség pedig rettentő érzékeny, és bosszúálló. Egy-két véleményvezér is könnyen felnyitja a szemét, ami után gyakorlatilag menthetetlenül elfajulhatnak a dolgok és tömeges elpártolás zajlik le. Ez persze lehet megfelelő időpont a nagyszerű megújulásra, de ez talán még nehezebb feladat. Így születnek a század szellem-szájtjai: 5-10 éven belül szerintem már tucatjával botlunk majd ilyen lapokba.

Persze a közösséggel való együttműködést sem lehet minden határon túl, ész nélkül művelni. Soha nem lesz tökéletesen közös álláspont, így egy-egy kisebb csoport véleményére adva meglépni gyökeres átalakításokat a fentiekhez hasonló elpártolást eredményezhet. Erős, lehetőleg előre végiggondolt, hosszútávú koncepcióval érdemes nekilátni egy közösségi szájtnak. Persze minden változik, és alakul eközben, de szükség van a határozott alapok lefektetésére. Fontos eldönteni az elején, hogy pénzt akarunk keresni, vagy társadalmi jóság a cél. Előbbinél kidolgozott üzleti modellel vágjunk bele, utóbbinál pedig fogadjuk el a jóság minden nehézsgét, szenvedését és értsük meg, hogy a felhalmozott tapasztalat hozhat hasznot számunkra, az adott nonprofit szájt közvetlenül nem. Ez utóbbi elfogadás garantálja a nonprofit közösségi adatbázisok hosszútávú, sikeres és minőségi anyagot eredményező működését.

Óriási megkönnyebbüléssel és enyhe kudarcérzéssel jelentem be kitartó olvasóimnak, hogy a Statuemap.com újraírását Ruby on Rails keretendszer helyett PHP alatt folytatom (kezdem újra). Ennek egyszerű és prózai oka az, hogy jelen életembe egyszerűen sehogy sem fér bele az, hogy megismerkedjek eme nagyszerű környezettel. Este nyolctól egyig egyszerűen nem lehet világot váltani úgy, hogy közben nem ismered 100 százalékosan az adott környezetet.

A tökéletes csaj

Kicsit úgy éreztem magam, mintha meg próbálnám szerezni a nagyon tökéletes csajt, mert azzal végigmenni az utcán igazi büszkeség. Mert, valljuk be, ma RoR programozónak lenni menő, sőt mi több igazán hekker dolog. Nekem most ez mégsem fér bele, egyszerűen azért, mert az alábbi rendszert nem merem elindítani ingoványos talajra építkezve:

• ~12 ezer szobor ~70 ezer fotója induláskor (szoborlap.hu migráció)
• user kezelés, követés, kommentelés
• amazon s3 cloud használata a képek tárolására
• számtalan időzített feladat
  
• mail küldés (hírlevelek, user események, stb.)
• google maps erős bedrótozása
• ajax, jquery aktív használata
• fb, twitter, flickr apizás
  

Ha most lennék 16

Mindezekben persze elvileg nagyon király a Rails keret, mert ami PHP alatt 100 sor, az itt 3. Rengeteg függvény előre meg van írva, gyönyörűen. És itt is van a legnagyobb probléma számomra. Az előre megírt (GEM-eknek nevezett) összetevők zárt dobozok, én csak installálom őket. Megpróbálom betuszkolni mindet a logikámba, és egymáshoz is kell passzolniuk. Mindeközben Linux-guruvá is válsz egy picit, mert egy kész szerveren normálisan elképzelhetetlen a dolog (megfizethető áron). A külföldi szolgáltatóknál pedig azonnal jelentkezik az olcsóság ára, ezt persze a cloud-terjedés számlájára kell írnom. Egy pici plussz fícsör, +20USD, nem elég az email kvóta, +50; kicsi a forgalom-keret? +30, esetleg kevés a memória? +50; beszakadt minden és valós segítség kell? +25/óra... stb. Azt még nem is mondtam, hogy a hazai virtuális hosztomon 1mp alatt 2 emailt enged át az SMTP, míg slicehost.com-os szeletemen egy emailnek kell 27mp - vagyis rá vagy kényszerítve valamilyen email plugin igénybevételére. Ami ettől még nem biztos, hogy whitelist-es.

Opensource business modell

Sajnos ez az egész szellemiség nem passzol össze sehogysem az én kis szerelem-startupommal. Ebből kifolyólag tegnap este egy hirtelen döntés által vezérelve letöltöttem a legfrissebb CakePHP verziót, újraindítottam a projektet és 3 óra után kb. ugyanott tartottam, mint amennyit az első 3 hétben csináltam meg Rails alatt. A CakePHP keretrendszer sokak szerint a RoR koppintása. Az tény, hogy első ránézésre is látszik egy-két komoly hasonlóság a szerkezetben, logikában és elnevezésekben, de amellett, hogy mindig minden sok más dologból tud csak születni, nem a semmiből, azért valljuk be azt is, hogy az objektumorientáltság nem a Railsben született; az MVC logika már korábban is adott volt. A RoR ennek egyszerű kommunikálásában és "eladásában" jó, opensource/közösségi keretek között. De miért van mégis egy olyan érzésem, hogy a RoR mégiscsak a dollárok felé lejt, míg PHP alatt valóban szabadnak, platform- és szerverfüggetlennek érzem magam?

Természetesen nem adom fel végérvényesen. van egy olyan mondás, hogy amíg gyökeresen nem változik a helyzetem munka/szabadidő/tanulmányok relációban, addig nem kezdek komolyabb RoR projektbe. Ha pedig igen, akkor viszont tudom is, hogy mi a következő terület, amit ezzel a csúcsfegyverrel fogok meghódítani! ;]

Ahogy haladok a Ruby on Rails tanulással, egyre izgatottabb vagyok. Tegnap fejeztem be ezt a rails 3-ra optimalizált segédletet, amit mindenkinek ajánlani tudok csak. A tutoriált végigkövetve egyszerű lépések sorozataként nettó 6 óra alatt építettem egy twittert, pontosabban annak kb. 2 évvel ezelőtti, fapados változatát.

Ez azt jelenti, hogy működik benne a posztolás, a követés, van (gr)avatar-kezelés, és persze az alapvető dolgok: regisztráció, ki-belépés, adatváltoztatás, autentikációhoz kötött oldalak. Michael Hartl az utolsó fejezetben bemutatja az ajax submitot is, ami RoR alatt még egyszerűbb, mint ahogy gondoltam. 

Most, hogy végeztem, kijelenthetem, hogy a már középsuliban is sulykolt elmélet alapján felrajzolt programozástechnika-fejlődési úton komoly távolságot teszünk meg a ruby programnyelv segítségével. A szintaktikát nézve elgondolkodtató, hogy mennyire távol vagyunk már a gépi kódoktól. Anno a pascalra mondták, hogy magas szintű és éreztük is, hogy azért ott nem tudunk bármit megcsinálni, és sok finomsághoz assembly kellett. Most a rubynál érzem azt, hogy - főleg a rails keretrendszer miatt - még távolabb kerültünk a vastól, és így még inkább emberi nyelvvé válnak a programnyelvek. Ez persze még robosztusabb és komplexebb rendszerek tervezését és készítését teszi lehetővé, ami ebben a webkettes világban amúgy is alapkövetelmény.

Nem mondom, hogy nem ijesztő egy picit, mert amíg a PHP-ban közelebb éreztem magamhoz a class-okat és a function-öket, és így saját képemre szabásukat is elérhetőnek láttam, most távoli és misztikusabb a dolog magja, ami egy picit azt az érzetet kelti, hogy nem nálam van a gyeplő.

A szerverkörnyezetre ugyanez igaz. A (RoR) cloud lényege, hogy ne te cseszelődj a szerverbeállítással és skálázással, hanem egyszerűen nyomd fel a herokura (pl.) a cuccodat és ott majd minden elfut, ha meg kell, akkor kis dolláregységenként, havidíjasan bővíted a cuccot egy csúszka feljebb húzásával.

Persze mindent magamhoz ragadhatnék és a github rails repository módosításával saját keretet gyárthatnék, de minek? Ma már nincs időnk arra, hogy minden területen magunk tapossuk ki az ösvényt. Túl nagyok az elvárások - de nem is baj: izgalmas dolgok születnek néha és a webnek köszönhetően a csapatmunka globális és súrlódásmentes lehet.

Szenzációhajhász és félrevezető szalagcím odafent. A cikk persze nem ilyen harcias. A rövid bevezető annyi, hogy kristályosodik bennem egy vitatéma, ami a közösségi weboldalak speciális, nonprofit célért megvalósított, össznépileg szerkesztett adatbázisokkal foglalkozik.

Történetesen a szoborlap pont egy ilyen adatbázis. Ez azt jelenti, hogy közösségileg bővített, és nem termel semmilyen közvetlen anyagi hasznot. Közvetettet persze annál inkább, hiszen egyrészt reklám a tagoknak, akik saját fotókkal, saját blogbejegyzéseikkel és saját kutatómunkájukkal/helyismeretükkel hívhatják fel magukra a figyelmet. Az ügyesebb és aktívabb regisztráltak a lapon kifejtett áldásos erőfeszítésüknek köszönhetően tapasztalataim szerint sokszor találnak új és hálás offline célközönségeket, akiken keresztül saját referenciájukat tudják mélyíteni és fejleszteni.

Emellett közvetlen hasznot hajthat a lap az üzemeltetőnek is, hiszen az a rengeteg tapasztalat, ami az idő során az emberre rakódik, sok helyen és irányban gyümölcsöztethető. Engem az utóbbi hónapokban mégis leginkább a pszichológiai és szocilógiai kérdések foglalkoztatnak.

Az alábbiakban összeírtam pár kérdést, ami beszélgetésre adhat alapot.

1. Folyamatos aktivitás. Mi motiválja az embereket arra, hogy heti 3-10 órát, vagy még többet is feláldozzanak szabadidejükből, és egy olyan közösségi adatbázis építésében vegyenek részt, amely közvetlenül nem kárpótolja anyagi áldozatvállalásukat?
2. A közösség szerkezete. Hogyan épül fel egy ilyen szájt közössége? Kik azok a kemény mag, kik az aktív tagok és kik a csendes, láthatatlan pártolók?
3. Fenntartható evolóció. Hogyan fejleszthetjük úgy a weboldalt, hogy ne sérüljön az eredeti közösség, de közben bővítsük és szinesítsük a látogatók körét? Milyen kompromisszumokat vállalhatunk be, és mennyire lehetünk forradalmiak, amikor új szolgáltatásokat vezetünk be?
4. Hiszel a Wikipédiának? Mennyi kell precíznek lennie, és végső soron mennyire lehet pontos és helytálló információk tárháza egy önkéntesen és nem szakmabeliek által szerkesztett szakmai tematikát követő adatbázis?
5. Összegzés. Mire figyelnék, ha most kezdeném el a közösségi szájt projektemet?

A következő hetekben a fenti 5 pontot veszem sorra és vesézem ki. Az egységeket végigfutva láthatjuk, hogy egy személyes vonalvezetés ez, és korántsem lehet univerzális tanulságokat levonni belőle. Tekintettel arra, hogy a legtöbb közösségi startup elkerüli az ilyen mély közszolgálatot, tényleg piacidegen leszek; emellett viszont kijelenthetem, hogy az elmúlt négy és fél év tapasztalatai többet segítettek megérteni ezeket a folyamatokat, mint amit a marketing szakirányon tanultam.

Siker, rubyban írom. A hétvége két dologgal is gazdagított. Egyrészt sikerült végre összeraknom a Ruby on Rails fejlesztői környezetemet, másrészt a Minerva barátném Szoborlap hírlevele is elindult. 

Kis sztorizás még. A szoborlap angol verziója, amin dolgozni fogok egyébként "statuemap" névre hallgat. Közvetlenül a szoborlap indulása (2006) után már elkezdtem foglalkozni azzal, hogy nemzetközi legyen a történet, és 2007 végén el is indult az oldal a statuemap.com címen. A lap egyszerű és áttekinthető volt, 2010 első negyedéig működött kb. Azért is fontos, mert az első php munka, amit tök egyedül, VG barátom hathatós segítsége nélkül írtam az elsőtől az utolsó karakterig.

A mostani verzió (nevezzük 1.0-nak) annyiban lesz más, hogy az eltelt években rohamosan terjedtek a lokalizációs élményre, helyzetmegosztásra gyúró webalkalmazások, ami még inkább életképessé tette az anno 2006-ban megálmodott logikámat, miszerint fogom a mobilt, sétálok a városban, és ha egy szobrot látok, máris tudom, hogy mi a sztorija, mi az, mert a GPS-szel összedrótozott szoborlap jól megmondja. Ha meg nincs fent még, hát klikk-klakk, és már töltöm is felfelé.

Hol futtatom majd: Slicehost. A lényeg, hogy kapsz egy darab tárterületet (a legolcsóbb 20USD/hó), ahová kb 10 féle Linux disztró közül választhatsz oprendszert (Ubuntu Maverick volt nálam a nyerő). Egy legördülőlistából választod a verziót, submit és 1 perc múlva már SSH belépésed van. Ezután jön a játszadozás, ami nekem kb. 2 hétig tartott, mondjuk minden szabad percemben. 

A linux beállítgatások (apache, mysql, mc, git-core, ftp, stb.) után jön a ruby telepítés, aztán rubygems, aztán rails és a többi, ami kellhet. MySQL gem is kellhet, ha abban gondolkodsz. Kiváló leírás ez pl. Ezután jön a futtatókörnyezet, amihez a Phusion Passenger tökéletes.

Aki nem akar annyit bénázni, és egybecsomagot akar, annak a Ruby Enterprise Edition is megfelel, nekem valami miatt nem jött be (ja igen, bizonyára túl egyszerű lett volna, haha). Ezek után már sikerült összeraknom egy appot, ami futott is... Összefoglalva kimondhatjuk, hogy döntöttem a fejlesztői környezetet illetően. December 20-ra tűztem ki az erős béta indulást, és kb. másfél évre előre látom a verziózást :]