Mire készülj, ha érzed: Kell egy weblap!

Az ember fia felébred és arra gondol: Kell nekem egy weblap! Igen ám de rögvest ezután egy kétségekkel teli feneketlen vermében találja magát. Innen nincs kiút, nincs kegyelem. Merre induljak, hova forduljak? Sokan, köztük Konrád is azt kérdezi, hogy ha az ember nem ért mindenhez: Kivel dolgoztasson? Vajon milyen eszközt válasszon? Ezek a kérdések helyénvalóak, de mielőtt megválaszolnánk ezeket fel kell készülnünk valamire:

Weblapot nem lehet készíteni!

El lehet kezdeni működtetni és abba lehet hagyni a gondozását, de elkészíteni nem lehet. Nincs olyan, hogy az ember beletesz egy kis vagy rettentő nagy pénzt/energiát/időt és onnantól csak dől a lé. Csak ki kell tárnunk a zsebünket, hogy legyen hova guruljon be a sok Forint. Alapvető hibás hozzáállásunkat kell először levetkőznünk, hogy tudjunk felelni bármilyen kérdésre is a témával kapcsolatban.

Kit válasszak amikor nekikezdek és nincs meg a megfelelő szakértelmem? Egy embert, egy csapatot? Tök mindegy. Az a kérdés kivel fogok tudni hosszú távon együttműködni és hogyan fogom lecserélni egy másik emberre vagy csapatra az eddig velem dolgozókat. Mert a szakításra sor kell, hogy kerüljön ha valami megváltozik. És - mint ahogyan a Tao mondja - csak egy dolog örök a változás. Nem kell összeveszni, nem kell ordibálni, de ha a két csapat (mi és ők) szekerének rúdja más irányba fordul, hát váltani kell. A legtöbb amit tehetünk felkészülünk erre a váltásra. Mert ez bizony nem egy könnyű dolog! Akkor különösen nem, ha ez felkészületlenül ér minket. Persze a legjobb ami velünk történhet, hogy húsz év múlva egy hűvös pince mélyén, nagyszerű borokat torkunkon lecsorgatva sztorizgatunk a hihetetlenül jól működő kapcsolatunkról. Kívánom legyen így, de készüljünk fel hátha máshogy alakulnak a dolgok.

A másik kérdés, hogy milyen eszközt válasszunk? Könnyű a válasz, ha megvan a csapat. Olyan eszközt válasszunk, amihez a csapat ért. Legjobb ezt rájuk bízni. Azonban ne felejtsük egyszer eljön a szakítás pillanata. Ekkor nekünk tovább kell mennünk és egy másik csapattal kell folytatnunk a munkánkat. Ha nyílt forrású rendszert választottunk és - figyelj mert itt jönnek a fontos dolgok - a változtatások, fejlesztések jól dokumentáltak, megfelelnek az adott projekt kódolási szabályainak bízhatunk benne, hogy a következő csapat folytatni tudja majd a munkát. Azonban hiába nyílt a forrás, ha egy átláthatatlan összegányolt valamibe kell belenyúlnunk. Gondolj egy szépen karbantartott kertre és gondolj egy elhanyagoltra. Vajon melyik az amelyik gondozását szívesen elvállalnád. Vajon melyiknél fogsz úgy indítani, hogy tavasszal felgyújtod az egészet és inkább újraülteted? Mérlegelni fogod - mint ahogyan az új csapat teszi majd - melyik nagyobb munka: Újrakezdeni vagy rendbe rakni?
Ha zárt forrást választasz ezzel nem lesz gondod, marad az újrakezdés.
A legfontosabb, hogy a saját munkád eredményét megőrizd. Kell tehát valami olyan adathalmazzal rendelkezned - hívjuk rendszeres mentésnek - , melyből újraépítheted az oldalad. Ehhez ragaszkodj, így érhet a legkisebb kár. Mindegy mi történik az új csapat fel fogja tudni építeni az oldalad az új rendszerrel, ha a régi már nem használható.

A legfontosabb tehát, amit nem győzök hangsúlyozni, hogy készülj fel a változásra. Vezérelje ez a gondolkodásodat. Ha ezt megérted tudni fogod miért az a legfontosabb kérdés:
Hogyan fogom lecserélni a csapatot?

Hozzászólások

Korábban még sose szóltam hozzá, de ennek örömére én is regisztráltam. :) Sajnos még Konrád szintjén működő webes szakemberektől is lehet hallani, hogy a zárt kód alapvetően biztonságosabb.

Tervezek írni erről is szintén, ez most nem fért bele. Előjáróban annyit, hogy a biztonság mint olyan nem egy ilyen egyszerű kérdés. Arról most nem beszélek, hogy ez a fajta általánosítás mennyire káros és inkorrekt.

pp

Pár napja jelent meg: http://crackingdrupal.com/

Fején találtad a szöget, pp! De tényleg...gratulálok! ez a legjobb cikked!
Kapcsolódó írások -> http://adaptiveproject.blogspot.com/

"Olyan eszközt válasszunk, amihez a csapat ért."
Ezzel sajnos nem tudok egyetérteni. Rengeteg kisvállalkozás esik bele abba a csapdába, hogy több százezer forintot fizet ki egy weboldalért, valamint több tízezret annak karbantartásáért havonta. Mikor rájönnek hogy nagyon sokat fizetnek, akkor jön a szakítás. Igen ám, azonban a fejlesztő nem adja a kódot, mivel a weboldalt az ő tulajdonosi kódjára épülő portál motor hajtja. Így két-három év együttélés után kezdődik az egész weboldal fejlesztés elölről. Egyébként érdekes lehet, hogy akkor a weboldal kifejlesztése címén kifizett több százezer forintot mire is fizette ki a megrendelő?
Ha weboldalt fejlesztetsz valakivel, akkor csak nyílt forrású alapokon, illetve a szerződésben feltüntetve, hogy a kifejlesztett weboldalt tárhely szolgáltatótól függetlenül működőképes és a fejlesztő cég weboldal átadásával lemond a vagyoni jogairól a megrendelő részére. Magyarul viheted tovább a fejlesztőtől függetlenül az oldaladat és tovább is fejlesztheted ha neked úgy tetszik.

Én azt nem értem, hogy kiragadsz egyetlen egy mondatot egy szövegkörnyezetből és arra reagálsz. Tovább olvastad amit írtam?

Szerinted értelmes dolog megbízni valakit és egy olyan eszközt a kezébe adni amit aztán nem fog tudni használni? Ekkor hogyan teljesíti az elvárásokat?

Miért mosod össze a nyílt forrás/zárt forrás fogalmát az egyedi/nem egyedi fejlesztéssel?

Miért hiszed azt, hogy egy nyílt forrású program nem lehet összegányolt szeméthalom? Volt alkalmam többször olyan már majdnem kész munkát átvenni amit kénytelen voltam újraírni. Pedig ott volt a forrás.

Volt olyan zárt forrású program aminél csak az adatbázist és az eredeti oldal wgettel leszedett verzióját kaptam meg. Minimál programozással importáltam az adatokat az általam használt rendszerbe.

A cikk pont arról szól, hogy a döntést nem olyan alapon kell meghozni, hogy nyílt vagy zárt, mert azon csak a flame megy. A cikk arról szól hogyan lehet gördülékenyen csinálni és mire kell felkészülni a megrendelőnek.

Mert a megrendelőnek fel kell készülnie hisz csak így kerülheti el a legnagyobb hibát:
Kiszolgáltatni magát a megbízottai kénye/kedvének. Akkor fog nagyot pofára esni, hogy ha a te általad terjesztett téveszmék alapján dönt majd.

Részemről pedig aki saját tartalom kezelő motor fejlesztésébe kezd az a legdrágább és legmegbízhatatlanabb megoldást választja.

Értsük meg nem lehet weboldat fejleszteni, készíttetni, készíteni. Weboldalt csak működtetni lehet. A tartalmak importálásáról és exportálásáról pedig a működtető csapatnak kell gondoskodnia. Ráadásul ezek a tartalmak mindig az azt előállító, vagyis a megrendelő tulajdonában maradnak.

Új hozzászólás