Onlinemarketing blog

Az Onlinemarketing blogon a hazai és külföldi online marketing hírekből, információkból merítek. Ha érdekeset látok, hallok, olvasok, arról elmondom a véleményem. Néha pedig csak leírom, amit szerintem érdemes tudni az internetes, online, digitális marketingről.

Berényi Konrád, tanácsadó

Levél a blognak

Legfrissebbek

Nincs megjeleníthető elem

Fontos dolgok


etarget

Nomen Est Omen

A Konrád férfinév a német Kuonrat névből származik. Elemeinek jelentése: merész és tanács.
Forrás

A Cég

Az Onlinemarketing blogot az Onlinemarketing.hu Kft., mint online marketing és kommunikációs ügynökség vezető tanácsadója és ügyvezetője írja.

Onlinemarketing.hu Kft.

 

Fontos dolgok

Add to Google

Add to Netvibes

Twitteren. Vigyázat, mély víz!

Hirdetések

Közösségi média alkalmazás partnerünk a
pagerider-logo_1.png




Virágcseppek - Bach virágterápia tanácsadás

Utolsó kommentek

  • Konrad: Itthon én elsősorban Koren Balázsnál láttam ezt a témát: kobak.org/blog/ (2023.10.25. 19:37) Tanulj dolgozni az MI-vel
  • pcmentor: Tudsz esetleg ajánlani olyan blogot, videósorozatot, ahol ezt meg lehet tanulni? (2023.10.24. 23:33) Tanulj dolgozni az MI-vel
  • Aztapaszta: Mindig nagy izgalommal vártam a podcast adását a Meti Heteor-t. Nagyon fog hiányozni. (2023.09.05. 06:45) Jó utat, Kelt!
  • Konrad: @Androsz: valójában számos más téma is van viccelni, és pont azért nem jók az általad sorolt témák... (2023.05.02. 18:17) Mivel viccelj?
  • Androsz: Hát, sajnos a legjobb ma semmivel sem viccelni. Valaki biztosan megsértődik rajta, és ma már minde... (2023.05.01. 15:40) Mivel viccelj?
  • Utolsó 20

MUNKA!

Nincs megjeleníthető elem

Tagek

8x80 (3) adatbázis építés hónap (5) adblock (15) adverticum (4) AI (5) ajánló (596) analytics (7) apple (3) arukereso (84) arukereso toplista (72) banner hónap (8) blog (233) blogmarketing (64) blogring (97) business blog (40) céges weboldal (14) e-business (10) ebusiness (108) ekormányzat (3) előadás (25) email marketing (47) érdekes (212) etarget (207) etarget qa (4) etarget tippek (33) etarget toplista (128) facebook (182) fórum (6) gépház (100) gerillamarketing (10) google (119) hiba (113) hírek (36) humor (31) iab (4) index (33) instagram (7) internetes fejlesztések hónap (4) internetes stratégia 2007 (8) internethungary2006 (16) internethungary2007 (6) internethungary2008 (4) internethungary2009 (5) internethungary2010 (6) internet hungary 2011 (3) iwiw (74) jog (31) kampány (398) kérdés (7) kereső (62) keresőmarketing (233) keresomarketing nap 2007 (7) keresomarketing nap 2008 (7) keresomarketing nap 2009 (8) keresomarketing nap 2010 (3) keresomarketing nap 2011 (6) keresomarketing nap 2012 (5) keresőoptimalizálás (51) keresőoptimalizálás tematikus hónap (5) kkvmarketing (9) Klub (19) közösség (251) közösségi média (32) kreatív (140) kutatás (100) látogatottság (28) laza (10) LinkedIn (5) Marketing és környezetvédelem (6) mediahungary (3) mediahungary2010 (4) mesterséges intelligencia (4) minicrm (7) mobil (34) mobil marketing (23) msn (10) oktatás (42) om eloadasok (4) om tanacsadas (3) onlinemarketing (1364) online kutatas 2007 (7) online marketing tippek (366) polblog (57) pr (29) reklamkonferencia eger (6) reklám célzás hónap (6) rss (23) sem (201) seo (50) smo (47) spam (32) startup (9) startup 2008 (4) startup 2009 (4) startup 2012 (5) statisztika (324) stratégia (23) szakcikk (6) szövegírás (45) tabu (5) támogatott bejegyzés (43) tanácsadás (22) tanácsadás hónap (4) tartalom (83) tartalommarketing (4) telefon (3) TikTok (3) turizmus online (5) twitter (13) üzlet (435) üzleti kommunikációs hónap (4) video (117) viral (25) vírusmarketing (30) vlog (4) web2 (142) web22 symposium (7) web2 symposium (17) webáruház (4) weboldal (259) webshop (5) website ergonómia hónap (4) wiki (4) wom (35) www.fenyek.hu (5) yahoo (13) [origo] (15) Címkefelhő

Hirdetési partner


Infinety Online Média és Marketing Kft.

Tel: +36-1-326-0065
E-mail: sales@infinety.hu
Web: infinety.hu
Blog: infinety.blogspot.com

Mondd, te kit választanál?

Címkék: internetes fejlesztések hónap

2009.05.21. csütörtök 23:59 Konrad

Egy portál építésénél a legnehezebb kérdés az, hogy kinek a kezébe rakjuk a sorsunk, vagyis ki legyen az, aki a programozást megcsinálja. Ugyanis változtati, módosítani jellemzően az tud, aki készítette az oldalt. Ha el akarunk szakadni az "ősforrástól", akkor szinte mindig egyszerűbb újraíratni az egészet, vagyis (programozásilag) előlről kezdeni a melót.

A döntési helyzet minimum kettős. Most két szempontot fogok bemutatni, de tudom, sokan vitatkoznak majd ezekkel, illetve a válaszaimmal is. Ez nem baj, az egyik célom is az, hogy valamiféle vita alakuljon ki, ugyanis ebből én is sokat tanulhatok. Tehát hajrá, az alábbiakra várom a kritikát vagy egyetértést:

Kivel dolgoztassunk?

Az alapvető kérdés az: legyen egy szabadúszó, egyszemélyes cég a fejlesztő, vagy bízzunk meg egy komoly(abb) céget a munkára?

Az egyszemélyes fejlesztő jellemzően olcsóbb. Előnye a kialakuló pozitív kapcsolat, a félszavakból is megértjük egymást munkaszervezés. Ha specialista, akkor zseniális dolgokra képes.

Hátránya elsősorban az, hogy egyedül van. Ha elutazik két hétre, akkor két hétig nincs, aki hozzá tudna nyúlni az oldalhoz. Ha összeveszünk vele, nem véd semmilyen szerződés, bukhatunk mindent. Ha specialista, akkor sok esetben ő formálja az oldalt és nem mi. Ráadásként zsarolási pozícióba is kerül, vagyis ha emeli az árakat, akkor mi kénytelenek vagyunk azt megadni neki.

A céggel való fejlesztés jellemzően azért drágább. Ráadásul vagy egy kapcsolattartóval kell egyezkedni, vagy akár több programozóval is. Ugyanakkor ha cserélődik a programozó, attól még a munka elkészül. És ha valaki szabadságra megy, attól még elkészül a kívánt feladat. A specialisták közül több is bevonható a munkába, az igényeinknek megfeleleően. A szerződés jobban véd bennünket, bár a zsarolási pozíció itt is megmarad. Mindent összerakva stabilabb, megbízhatóbb hátteret kapunk.

Egy dologról nem beszéltem: a munka minősége. Furcsa, nem furcsa, de mindkét választás esetében kaphatunk kiváló eredményt, átlagosat és csapnivalót is.

Az egy emberes fejlesztés eredménye is lehet nagyon jó, és a cég is csinálhat iszonyúan rossz melót. Vagyis a fenti szempontokon túl egyik megoldás sem adja a kezünkbe a weboldalkészítés Szent Grálját.

Milyen környezetben működjön a weboldal?

Azt mondják, ahány webfejlesztő cég(ecske), annyi tartalomkezelő rendszer van a piacon. Vagyis mindenki elkészítette a saját programozói környezetét, és azt adja el, mint egyedi fejlesztést. Én négy céggel dolgozok több-kevesebb rendszerességgel, közülük kettőnek megvan a saját rendszere.

Mert a saját rendszer mellett van egy másik megoldás: a már kész, moduláris rendszerekből, vagy félkész portál programokból való építkezés. Ez az, amikor röpködnek a nevek: Microsoft IIS SharePoint (köszi, Ádám!), Drupal, Joomla, Wordpress stb.

Alapvetően a cégválasztással egyben tehát platformot is választunk, de a döntésünk lehet itt is megfontolt. Lássuk, melyik mivel jár!

A saját rendszerek előnye a viszonylagos biztonság: mivel kevesen ismerik a forráskódot, így sokkal nehezebb feltörni. Viszont fejleszteni csak az tud bele, aki készítette, esély sincs arra, hogy valaki más átvegye. Ugyanakkor jellemzően nagyon jól testreszabhatóak az ilyen rendszerek: szinte bármit meg lehet valósítani, amit ép ésszel kitalálunk.

Ugyanakkor a kész rendszer jellemzően egyfajta szabványt jelent. Ha programozót cserélnénk, van arra esélyünk, hogy ne kelljen újraírni az oldalunkat. Cserébe illik folyamatosan karbantartani a rendszert, és legalább a biztonsági frissítéseket követni.

Sajnos a kész rendszereknek megvan az a hátrányuk, hogy néha sikerül olyat kérni, ami vagy nem valósítható meg, vagy csak nagyon körülményesen. De összességében mégis egy alapszintű függetlenséget fogunk kapni azzal, ha ilyeneket használunk.

A fenti két szempont tehát fel fog merülni, amikor programozásra kerül a sor. Jó válasz láthatóan nincs, inkább döntési helyzet van. Ki-kik élhet ezzel a lehetőségei szerint.

34 komment

A bejegyzés trackback címe:

https://onlinemarketing.blog.hu/api/trackback/id/tr251136584

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Aadaam 2009.05.22. 00:41:17

Az egyszemélyes céggel a motiváció a marha nagy veszélyhelyzet: magamról is, és nagyon sok programozóról tudom, hogy hajlamosak vagyunk fókuszt veszíteni, ha nincs feedback. Ettől még lehet jó a megoldás, de ha határidők kellenek, akkor jobb, ha team van, méghozzá jól szervezett.

A másik irány a nagy cég. Nem tudom. Bár látok sok nagyobbacska fejlesztőcégtől iszonyat jó szakmunkát, azért sokszor van az, hogy a fejlesztőcég valójában nincs képben az adott területen, esetleg pár pillanatra kifogtak egy jó programozót, és az csinált valamit, de már lelépett a cégtől. Kell egy olyan ember, aki meg tudja állapítani a referenciák kódminőségét, értia cég módszertanát, és aszerint választani.

Én a kettő közti megoldás híve vagyok: a kis fejlesztőcsapat nagyon hatékony tud lenni. Igazából a nagy cég is sok esetben verbuvál egy kis csapatot magán belül, rosszabb esetben meg a nagy cégen belül is csak egyetlen emberre lesz bízva a feladat. Módszertanfüggő, cégfüggő.

Minden esetben nézzünk referenciákat. Keressünk olyan embereket, akik kompetensek annak eldöntésében, ezek a referenciák milyen kódminőségűek. Hagyjuk beszélgetni ezt az embert, és engedjünk alternatívákat: csak azért, mert szimpi a titkárnőjük, még lehet, szakmailag másik cég a jobb.

Az is külön tudomány, milyen kész rendszer. Mindig lesznek kész komponensek, mert alapjaitól nem írunk számítógépes programokat a hetvenes évek óta. Az az igazság, hogy minden cég arra fog esküdni, amihez ért ezek közül. Egy picit érdemes előre gondolkozni, és a teljes szolgáltatáskészletre kérni az ajánlatot, azokra is, amiket nem tervezünk induláskor, hogy lássuk, hogy lennének képesek megírni. Nem árt, ha mindegyikről megkérdezzük, hogy tervezik implementálni. Lehet, ötletük se lesz rá... Gondoljuk végig, mi éri meg.

Konrád: az IIS, az a webszerver, minden XP-hez adják, éppúgy, mint almához az Apache-ot (meg linuxhoz is azt). A szó amit kerestél valószínűleg a SharePoint.

dezo · http://devaizoltan.hu/blog 2009.05.22. 07:45:48

Kis kiegészítés.
Nézzük meg kicsit, hogy mi a helyzet a megrendelő oldalán!
Ki mondja meg a programozónak, hogy mit kell programoznia? Van egyáltalán olyan ember a megrendelői oldalon, aki beszéli a programozók nyelvét? Melyik oldalon legyen az a szereplő, aki az üzlet által megfogalmazott igényeket "lefordítja" a technológi nyelvére?
Ha a fejlesztői oldal felajánlja ezt a funkciót, annak egyrészt megkéri az árát, másrészt még mindig ott motoszkálhat az Üzleti oldal fejében a kétség: Tényleg az lesz, amit szeretnénk, vagy az, amit a fejlesztők tudnak?
(Kicsit más téma, de azért kapcsolódik jó erősen)

2009.05.22. 08:34:00

@dezo: "Van egyáltalán olyan ember a megrendelői oldalon, aki beszéli a programozók nyelvét? "

Sokszor fel lehet tenni a kérdést, hogy van olyan ember a megrendelői oldalon, aki tudja egyáltalán mit akar?

Nekem pl elég elmondani, hogy nézzen ki, hogy mukodjon, ha doksi van hozzá még jobb, meg lehet csinálni. Az a baj, hogy sokszor a doksi csak bullshittel van tele, konkrétumok nélkül, abszolut használhatatlan. Mert gőzük sincs mit hogy kell, mit hogy lehet. Az nem is baj, de ha visszakérdezek, hogy hogy gondolta ezt, akkor "én nem értek hozzá, oldd meg". pl: kapcsolodo termékek. ez szép, és jo, de semmit nem ér. Miért nem lehet odaírni, hogy kapcsolodo termékek szag alapján. vagy a kategoriábol a legtöbbet kattintott pirost kell odatenni. Nem kell nekem a marketingpiacelemzéstrendgörbéjének a nemtommije.

Nem kell a programozonak külön tolmács, szöveges algoritmust mindenki írt már, érthető magyar, csak tudnia kéne a megrendelőnek mit akar.

Egyszer volt, hogy végighallgattam ilyen beszédet, majd visszakérdeztem, hogy értem én, de konkrétumot nem lehetne mondani, mert ebből nem lehet csinálni semmit. "jaaaa, azt én nem tudok, majd az xy elmondja." ez így jó? plusz egy ember aki a konkrétat tudja?

"Tényleg az lesz, amit szeretnénk, vagy az, amit a fejlesztők tudnak?"

Ha oltári baromságot akarnak, nyilván nem, de én ezt mondom, "bármit" kivitelezek.

2009.05.22. 08:41:02

@cadmagician: ugyértem, hogy akinek a feladata a weboldal doksiját elkészíteni, az tudja mire van szükség a működéshez. tehát a koder hozzáértővel beszéljen, aki részleteiben tudja mint akar. tehát nem programozoi nyelven kell beszéljen, hanem legyen tényelgesen tisztába a saját dolgaival. sokminden megsporolhato lenne.

perger.laszlo · http://www.rejtelmek.hu 2009.05.22. 09:15:18

Sajnos nagyon egyetértek, valahogy a lakásfelújítás ugrik be analógiaként, azaz a webfejlesztés is folyamatos szívás.

A kész rendszer is lehet rémálom, a rengeteg plugin által generált biztonsági kérdés, a magyarítás nehézségei. És a verzióváltáskor lehet kezdeni a molyolást előröl.

A nagy webfejlesztő cégekről szerintem mindenkinek van horrorsztorija: minden programozó saját módszertannal dolgozik, nincs verziókövető rendszer, a frameworköt nem változtatják meg az ügyfél kedvéért, mert akkor mi lesz a többi ügyféllel, kavarognak a verziók, ügyfél szerverén adatvesztés okozása stb. Cégnevek a szerkesztőségben.

Az egyszemélyes fejlesztő is veszélyesek, nem ért a projektmenedzsmenthez, csúszik, túlvállal, tisztára mint a kőművesek, asztalosok.

Ja, a Joomla az J, nem Y.

adManiac · http://admaniac.blog.hu 2009.05.22. 09:51:06

mindenképpen hasznos az, ha van egy olyan "köztes ember", aki érti a programozók nyelvét és átlátja az üzleti elvárásokat. személye nagyon sokat lendít a folyamaton, de sajnos kevés ilyen szakember van az országban...

2009.05.22. 10:21:08

@adManiac: a programozók nyelvét a programozok értik. mindössze tényeket kell átadni, nem rizsát, és le lehet kodolni.

Novák Ákos · http://boldogsagprojekt365.hu 2009.05.22. 10:31:07

A saját tapasztalataim a témával kapcsolatban:
Először egyszemélyes "céggel" csináltattam a rendszerem, az elején ment is, de aztán valami okból tarthatatlanná vált a kapcsolat. Nem igazán tudtunk megérteni egymást. Legalábbis nem azok a fejlesztések köszöntek vissza, amiknek kellett volna. Éppen most váltok egy cégre, ahol - bár még nem tudok véleményt mondani - biztosan többen és többet tudnak dolgozni a rendszeren. Árban viszont teljesen más lesz.
Én nyílt forráskóddal dolgozok/dolgoztatok, de ez a mai világban teljesen csak felfogás kérdése véleményem szerint. Találkoztam már ócska minőségű saját rendszerrel, hiába volt biztonságos, oda-vissza működik ez is. Mondták nekem igen csak nagy cégnél hogy hagyjam el a nyílt forráskódot, merthogy egyáltalán nem biztonságos...Ezzel nem is lenne baj, ha közben nem a milliós rendszerüket próbálnák rámsózni. A technológia mindenképpen a nyílt forrás felé megy, ha tetszik, ha nem, visszafelé nem fogunk fejlődni. Egy rendszert pedig így is-úgy is karban kell tartani.
Előttem már szóltak arról hogy egy köztes emberre szükség lehet, az üzlet és a fejlesztés között. Ezzel teljesen egyetértek, a bejegyzés olvasása közben egyértelműen éreztem hogy szüksége lehet egy "vállalkozónak" egy ilyen emberre, ha ő nem képes így átlátni a koncepciót.
Előnyben vannak az olyan emberek akik az üzlet és a webtrendek mellett a fejlesztési folyamatba is belekóstoltak már. Bevallom ez tényleg ritka :)

kohana · http://kisviraginitaly.freeblog.hu 2009.05.22. 10:56:17

@cadmagician: a programozók nyelvét nem programozók is értik/érthetik :)
Egy teljesen laikus, aki most akar belépni a "honlappiacra" szinte biztos, hogy nem fogja tudni megfogalmazni, mit akar, azon túl, hogy jót, meg működőt. Arról meg pláne nem lesz fogalma, hogy mit lehet, meg mi kell.
Én, mint ilyen "köztes szakember", létjogosultságát látom ennek.
Persze, ha a megrendelő tudja és érti miről van szó, akkor nem biztos, hogy szükség ránk.
Viszont visszafelé is nézzük: ismerek olyan programozót, aki fanasztikusan kódol, de egyszerűen képtelen "normális" nyelven megfogalmazni, mikor valami többféleképp megoldható, és a döntést a megrendelőre akarja bízni. (néha még nekem is nehéz, hogy mit is szeretne)
Szóval egy bizonytalan, épp elinuduló, a témáról semmit nem tudó mellé nagyon jól jön. pénzt és időt spórolhat meg, mert képes kihúzni az illetőből, mit akar, és azt kommunikálni a programozó felé.

tanarurkerem · http://palocz.hu 2009.05.22. 11:24:30

Egy kis bejegyzést írtam a témához kapcsolódóan:
http://palocz.hu/node/207

"A saját rendszerek előnye a viszonylagos biztonság"

Ilyen kijelentést úgy tenni, hogy hallottam valakitől aki látott már olyat aki olvasott valahol egy olyan elemzést... Elég nagy bátorságra vall! Pont egy reklámmal foglalkozó embertől elvárná az ember azt, hogy átlásson az intelligens mosópor mítoszán.

Néztél már bele valaha is ilyen saját rendszerbe? Én néztem és nem láttam összefüggést a rendszer biztonsága és zártsága között. Mielőtt flémelsz figyelj! Én nem azt írtam, hogy az ellenkezője az igaz, hanem azt nincs összefüggés azért hülyeség az állítás.

pp

2009.05.22. 11:31:06

@kohana: mint írtam, olyanra gondolok, mint pl a kapcsolodó termék. és? miért kell ilyenhez külön ember, hogy az szedje ki a másikbol, hogy mi alapján. ha egy marketinges (gondolom én) kitalál egy weblapot, az tisztában vele, hogy bizonyos dolgokat miért tett oda ahova tett, mi a célja vele, az mi alapján kerül oda a programban. pl releváns cikkek, egy dobozba mi alapján kerülnek a hírek: automatikus, vagy a gyalog állítja be, mert ki akar emelni valamit. sokszor ezeket hiányolom, hogy nincs leírva. feleslegesnek tartok erre külön embert.

mondjuk ez az én véleményem, mert nekem ennyi elég ahhoz, hogy el tudjak indulni. de jo lenne példát látni, amikor nincs igazam. írj egyet.

a normális nyelven valo megfogalmazás áltálnos iskolai probléma szerintem. :)

Konrad · http://onlinemarketing.blog.hu 2009.05.22. 11:39:51

@tanarurkerem: vártam már :)
A nyílt rendszerek - ha nem frissítjük őket rendszeresen - veszélyesebbek lehetnek. Lásd tavalyi Joomla-törések.
A zárt rendszerek viszont ettől védettek, hiszen kód szinten kevesebben ismerik azokat.
Így sem tudod még elfogadni?

cserepj · http://latinpince.blog.hu 2009.05.22. 11:44:19

Ajánlom mindenkinek, hogy ezeket kérdezze meg a kiválasztandó egyszemélyes vagy nem egy személyes partnerétől:

http://www.joelonsoftware.com/articles/fog0000000043.html

Ha nincs legalább 10 igen válasz, köszönje meg az eddigieket és búcsúzzon el tőlük.

A Szeretgomot kvázi egyszemélyesen fejlesztettem (ma lett 3 éves), mellette több komoly projekten is részt vettem csapattagként (elsősorban a banki szektorban), az utóbbi időben meg főleg tengerentúlra dolgoztam távmunka jelleggel egyszemélyesen, de egy több időzónás csapat részeként. A kód minőségén nagyon sokat tud dobni ha a fenti 13 good practice-ből minél több megvan egy adott környezetben - legyen akár egyszemélyes, akár többszemélyes a projekt.

tanarurkerem · http://palocz.hu 2009.05.22. 12:10:38

@Konrad Én az ok okozatot vitatom: Állításunk mely szerint egy nyílt forrású(vagy bármely érted, bármely!) rendszer nyilvánosságra kerülő hibáit nem foltozzuk akkor a rendszerünkben mindenki számára elérhető hibák lesznek. Ez igaz.

Ebből viszont nem következik, hogy a zárt(vagy bármely más, érted!? bármely) rendszerek védettek lennének. Egy nyilvánosságra került hibát minden rendszerben ki lehet próbálni, lásd XSS, SQL injection, stb támadások. Ezektől nem véd meg az, hogy nem ismerem a forrást. Hisz ezek olyan támadások, melyek a forrás ismeret nélkül, de megfelelői programozói tapasztalattal kihasználhatóak. Vagyis itt a hibás programozói megoldásokat, melyek ismertek használjuk ki.

Tehát nem igaz az az állításod, hogy a zárt forrás csak olyan hibákat tartalmaz amit kevesek ismernek. Ez hülyeség.

És most azért nem sorolok példákat mert nem azt akarom mondani, hogy rosszak lennének a zárt/nyílt forrású rendszerek, egyszerűen csak azt, hogy nincs ilyen irányú összefüggés. Szóval ez ellen úgy érvelni, hogy felhozol egy olyan példát ami igaz az első állításra nem túl korrekt dolog. (vagy nem érted mit írok. ;))

A barna sapkás hegymászó aki biztosítás nélkül mászik a sziklán, nagy eséllyel meghal.
-> A kék sapka biztonságos.

Te is érzed ugye, hogy ez utóbbi baromság?

pp

Konrad · http://onlinemarketing.blog.hu 2009.05.22. 12:26:32

@tanarurkerem: értem, mit szeretnél. Valóban nem attól biztonságos vagy nem biztonságos egy rendszer, hogy zárt-e. De a nyílt rendszerek esetében máshogy, jellemzően jobban jelentkezik a biztonsági kockázat. Egy zárt rendszer esetében is lehetnek hibák, de azok kiderülése sokkal nehézkesebb, ráadásként sokkal lassabban terjed.

kohana · http://kisviraginitaly.freeblog.hu 2009.05.22. 12:50:41

@cadmagician: talán kicsit elbeszélünk egymás mellett. a marketinges nem a megrendelő, hanem már egy köztes ember (kivéve, ha saját magának csináltat oldalt).
a megrendelő egy kispista, aki akar egy honlapot a szolgáltatásának.
Ő nem fogja tudni, hogy mit miért kell hova tenni.
Ezért vagy keres egy marketingest, SEOst, ergonómust vagy valami hasonlót (engem a diplomám szerint médiainformatikusnak hívnak), aki segít neki ezt megcsinálni. Ennek az embernek meg már illik tudni, mit, hova, miért, tehát mellé már tényleg nem kell plusz szakember, hiszen ő maga az...

2009.05.22. 13:10:52

@kohana: egyre gondolunk. tehát aki a marketinget csinálja, az tudja, hogy mi miért van ugy, tudja, hisz ő csinálja. tehát oda tudja írni, mi hogy működjön, hisz annak ugy kell működni, hisz akkor jo. az ergonomus nem feltétlenül tudja marketingileg mi a jo, meg fordítva, de ez a programozot nem érdekli. de az ergonomus meg marketinges le tudja írni, hogy működjön. ez szvsz egy értő programozonak elég. nem? az algoritmus írás más tészta, az más programozási kérdés...

llyes Edit (törölt) 2009.05.22. 13:37:57

@Konrad: "Egy zárt rendszer esetében is lehetnek hibák, de azok kiderülése sokkal nehézkesebb"

Nem. Kérlek olvasd el újra tanarurkerem hozzászólását.

Még egy érvet mondanék a nyílt forráskódú, kész rendszerek mellett: többnyire könnyebb egyikről a másikra váltani, mint zárt kódúról egy másik zárt kódúra, vagy zárt kódúról nyílt kódúra. A külső megfelelési kényszer - ti. hogy pár hónapon belül fel kell tenni a következő frissítést, tehát nem hegeszthetem össze-vissza a rendszert - a gyakorlatban _általában _ fegyelmezettebb fejlesztői magatartást eredményez.

Ez pedig azt jelenti, hogy ha csapatot váltunk, és a másik csapat másik technológiával szeretne dolgozni, akkor egy junior programozó egy-két nap alatt át tudja mozgatni az adatainkat a másik rendszerbe. (Ráadásul erre vannak kész migráló megoldások is, Wordpress -> Drupal, Drupal -> Wordpress, stb.)

Nem állítom, hogy minden zárt rendszer kusza, csak azt, hogy ott nincs _külső_ fegyelmező eszköz - sőt, ellenérdekeltség van (minél kuszább a kód és az adatbázis, annál nehezebben fog lecserélni a megrendelő).

kohana · http://kisviraginitaly.freeblog.hu 2009.05.22. 13:41:13

@cadmagician: igen. marketinges/ergonomus/hasonszőr le (kéne) tudja írni.
Arról nem volt szó, hogy a köztes, hozzáértő ember konkrét szakmája mi. Csak arról, hogy jellemzően szükséges egy a megrendelő-programozó közé. (és ahogy látom, ezzel te is absz. egyetértesz :) )
a normális megfogalmazás egyébként nem az ált. iskolai problémára utalt, hanem arra, hogy a srác nagyon nem, vagy nehezen tud elvonatkoztatni a szaknyelvtől, és amikor pl ilyeneket kérdez, hogy a keresésnél metszet vagy úniós megoldás legyen (tudom h ez így furán hat, de nincs kedvem kifejteni), ott egy átlagember pislogni fog, és feldereng neki valami halmazos húlyeség a középiskolából, de ennyi...

Alex_79 2009.05.22. 20:56:20

Szerintem néha érdemes megnézni az ár/érték arányt is.

cserepj · http://latinpince.blog.hu 2009.05.22. 23:20:30

@Illyés Edit:

"(minél kuszább a kód és az adatbázis, annál nehezebben fog lecserélni a megrendelő)."

Akinek ez kell egy ügyfél megtartásához, attól tényleg menekülni kell.

Fogadjátok el légyszíves, hogy a kód minősége elsősorban módszertani, másodsorban humán kérdés és se a zárt forrás, se a nyílt licencelés nem biztosít előnyöket a biztonság területén.

Ennek igen egyszerű oka van: a biztonság nem tulajdonsága egy rendszernek, hanem állapota, egy folyamatosan változó, a külső körülmények által változtatott metrika. Gondoljatok a hidegháborús amerikai filmekre ahol a hegy gyomrában ülnek a katonák és állítgatják a DEFCON szinteket - na valami hasonló az informatikai biztonság kérdésköre is. Kockázatok és költségek kusza hatásrendszere húzódik a háttérben, ahol mindig azt kell mérlegelnünk, hogy egy adott pillanatban milyen kockázati tényezők vannak az üzemeltetett rendszerrel kapcsolatban és azok csökkentése milyen módszerekkel lehetséges a megadott büdzsénk keretein belül.

Az adatmigráció kérdésköre meg teljesen irreleváns ebből a szempontból: migráltam én már több százezer banki ügyfél- és egyéb pénzügyi adatot zárt forrású, AS400-akon futó alkalmazások között. Megfelelő odafigyeléssel, tervezéssel és nem utolsó sorban csapattal nincs lehetetlen feladat.

A nyílt forrású termék is csak egy termék - lehetnek pozitív és negatív tulajdonságai. Ha baj van vele, akkor egyrészt valóban egyszerre válik sebezhetővé sok oldal, amit black hat eszközökkel akár igen gyorsan ki is lehet használni (worm-okat lehet írni). És hiába van fent a legfrissebb verziód, ha 0 day exploit-ot kihasználó worm jelenik meg az interneten az adott technológiát kihasználva.

Ugyanakkor megfelelő mennyiségű pénzzel és szaktudással egy zárt, egyedi rendszer gyenge pontjait is igen könnyen fel lehet térképezni. Az egyik oldalunkon például sokáig a regisztrációnál nem volt Captcha image - egy magyar nyelvű weboldalt máig nem értem, hogy ki és miért térképezett fel -, de egyszer csak azt vettük észre, hogy beregisztrált elefántcsontparti ip címről valaki és belépés után az oldal üzenetküldő belső rendszerével nekiállt végigspam-elni a felhasználókat. Kb 2 tucatnál tartott, amikor észrevettük, igen gyorsan letiltódott és nem tudta folytatni a tevékenységét, de akkor is jó lecke volt.

umcaumca 2009.05.22. 23:41:59

További nehézség a Joomla-val, Drupallal, hogy egy-egy upgrade után a régi modulok nem igazán működnek az új verzióban...

tanarurkerem · http://palocz.hu 2009.05.23. 08:57:22

@cserepj:
"Ha baj van vele, akkor egyrészt valóban egyszerre válik sebezhetővé sok oldal, amit black hat eszközökkel akár igen gyorsan ki is lehet használni (worm-okat lehet írni). És hiába van fent a legfrissebb verziód, ha 0 day exploit-ot kihasználó worm jelenik meg az interneten az adott technológiát kihasználva."

Ez tipikusan igaz minden rendszerre. Ha egy rendszer megfelelően nagy elterjedtséggel rendelkezik akkor megéri rá wormot/vírust írni, már ha a hiba olyan. Egy két-három ember által használt akármilyen szoftverre nem fog ilyet írni senki. Egy elterjedtre meg igen, de ez meg független attól, hogy a program nyílt vagy zárt forrású. Mindenki tudna pro és kontra tapasztalatokat mondani nyílt és zárt rendszereket, csak éppen ezzel az a baj, hogy az egyik vagy másik oldal tévhitét erősíti csupán és nem vezet közelebb az igazsághoz.

Mint ahogyan Te is írod abból a tulajdonságából, hogy nyílt vagy zárt egy szoftver nem lehet levonni következtetéseket a rendszer biztonságára vonatkozólag és nem lehet beszélni biztonsági kockázat létéről/nemlétéről sem.

pp

llyes Edit (törölt) 2009.05.23. 13:02:56

@cserepj: Arra próbáltam felhívni a figyelmet, ezek szerint sikertelenül, hogy egy nyílt forrású rendszer használata esetén sokkal nagyobb a külső megfelelési kényszer. Azt látom, hogy zárt rendszereknél sokkal könnyebben megy a gányolás, például mert senki se látja, vagy mert nem kell tartani attól, hogy a következő biztonsági frissítést nem tudjuk rátenni a rendszerre. Ezért ha váltani kell valami másra, _nagy valószínűséggel_ könnyebben fog menni, mint egy olyan rendszer esetében, ahol a fegyelmezetlenségnek esetenként nincsenek azonnal érzékelhető negatív következményei.

Konrád cikke nem azokról az ügyfelekről szólt, akik "banki adatokat" akarnának migrálni. Olyan kis- és középvállalkozásokról lehet itt szó, ahol nincs házon belül programozói erőforrás, a megrendelő pedig nincs abban a helyzetben, hogy megítélje a fejlesztés minőségét. Kénytelen rábízni magát a fejlesztő lelkiismeretére - és nyílt forrás esetén emellett számíthat a külső kényszerre is, amit egy közösségi fejlesztésű rendszer jelent. (Természetesen ez sem 100%-os garancia, olyan egyáltalán nincs.)

Atisp · http://www.netgo.hu 2009.05.23. 13:32:37

Hát, ha egy sablon keretrendszerbe bele kell fejleszteni dolgokat, akkor onnantól az már egyedi szoftver lesz. Persze egy-egy dolog belefejelesztése sokkal körülményesebb és drágább lehet vagy egyszerűen racionálisan kivitelezhetetlen. Igazából én nem nagyon ismerek olyan nagy népszerű oldalt, ahol tisztán csak egy keretrendszer beépített funkcióit használnák és ne programozták volna át részben vagy egészben a siteot vagy a shopoz-

A támadások alatt nem azt kell érteni, hogy a hacker egy élő ember, aki épp XY kisvállalkozó honlapját akarja feltörni. Hanem a legtobb esetben egy program, ami akár több tízmillió oldalon végigfut és kihasználja a biztonsági réseket. Lelopja az ügyféladatokat és aztán majd pl. spameket küld az ügyfeleknek, stb. Gyakran tudatosan írnak ilyen hack programokat egyes keretrendszerek biztonsági hibáira. Ettől viszont még lehet, hogy sokkal biztonságosabb egy keretrendszer, mint egy egyedi szoftver. Az utóbbira viszont kevésbé vadásznak, mert nem tudják, hogy létezik :)

llyes Edit (törölt) 2009.05.23. 14:02:56

@Atisp:

"Persze egy-egy dolog belefejelesztése sokkal körülményesebb és drágább lehet"

Vagy olcsóbb, és pár sor kóddal megoldható.

"Gyakran tudatosan írnak ilyen hack programokat egyes keretrendszerek biztonsági hibáira."

Még gyakrabban meg csak mennek végig az oldalakon, és minden űrlapnál bepróbálkoznak. És teljesen mindegy, hogy az űrlapot nyílt vagy zárt program állítja elő, ha lyukas, akkor fel fogják törni.

xsolutions · http://blogvilag.hu 2009.05.23. 16:19:30

"Van egyáltalán olyan ember a megrendelői oldalon, aki beszéli a programozók nyelvét?" Nincs rá szükség. A nagykönyv szerint egy fejlesztési feladat során a következő kommunikációs csatornát kellene használni:

megrendelő -> consultant -> architect -> programozó

A tanácsadó a megrendelő igényeit gyűjti össze és rendszerezi. Jellemzően "emberi" nyelven írják, a megrendelőnek kell leokéznia, hogy azt kéri, ami a dokumentumban szerepel. Az architect lefordítja a programozó nyelvére, valamint kiegészíti a használandó technológiákkal. A programozó lekódolja. (Vannak párhuzamos események is, mint pl. hardware architektúra építése, tesztelés stb, de ezt most kihagyom.)

Ebből azért már látszik, hogy sok emberre van szükség, ha jó végterméket akarunk, illetve ha az a cél, hogy a vevő valóban azt kapja, amit akar.

Ahogy a webes fejlesztéseknél, úgy a "hagyományos" területre is igaz, hogy hamarabb szalad a vásárló a sufnituninghoz, mint hogy megfizesse a megfelelő szaktudású embereket. (Tisztelet a kivételnek, ahol kevés emberrel nagyon jó minőségű munkát tudnak elérni.)

cserepj · http://latinpince.blog.hu 2009.05.24. 00:18:09

@xsolutions:

Abszolúte nem értek egyet szinte egyetlen mondatoddal sem, remélem nem baj:)

A megrendelő oldalán, vagy legalább zsoldjában kell lennie egy informatikusnak, aki minőségbiztosítási tevékenységet végez. Optimális esetben ez az illető sikerdíjat kap a projekt sikeres lezárásakor, és nem folyamatos nagy pénzeket nyúl le, tehát érdeke lesz valóban részt venni a projekt működésében. Hívhatjuk tanácsadónak, ha akarjuk, de egyáltalán nem az a dolga, hogy "emberi nyelven leírja a megrendelő igényeit". Sokkal inkább az, hogy folyamatosan kövesse a szakmai munkát és közvetítsen az üzleti oldal és a műszaki oldal között.

Normális ember a mai világban már nem csinál waterfall jellegű projektet, egyszerűen nem éri meg, túl nagy a kockázata és túl kicsi a siker valószinűsége.

Az architect pozíció is csak egy bullshit - az az architect aki az ideje 50%-ban nem programoz legalább, az fél év után alkalmatlan architecti feladatok ellátására.

Attól, hogy sok ember van egy projekten még nem biztos, hogy jó végtermék lesz. Mint mondtam SOKKAL fontosabb az a módszertan, azon gyakorlatok összessége amiket a fejlesztőcsapat végez. Sokkal fontosabb a folyamatos kommunikáció, visszajelzések illetve az, hogy a specifikációban illetve a feladatban bekövetkező változást a csapat bármikor kész legyen elfogadni és belefogalmazni a munkába. És végül a legfontosabb, hogy jó szakemberekkel dolgozzunk.

Ennyi a titok.

kM 2009.05.25. 12:42:34

Az ilyen jellegű kérdések mindig hitvitába torkollanak. Győzz meg egy Fedora-usert, hogy az Ununtu sokkal jobb - a Fedorás a biztonságra esküszik, az Ubis meg a használhatóságra.

Ugyanez igaz a Drupal, Typo, WP vs. saját keretrendszer választása között.

Nekem az a személyes tapasztalatom, hogy míg versenytársaink százezreket és milliókat ölnek a saját CMS-ük megíratásába, szervizelésébe, addig mi olyan oldalakat készítünk, amikhez elég a WP vagy a Drupal. És közben tiszta, jó, keresőbarát kódunk van, nem úgy, mint egyik versenytársunknak, akinek a saját keretrendszere nem engedi, hogy a google beindexelje az oldalát, ezért nincsenek keresőtalálatai, ami manapság elég nagy luxus, akárhonnan is nézzük. Ja, és ez a gányolás még pénzbe is került.

Szerintem aki nem akar hóbortos scriptkiddykkel dolgoztatni, "ezt ezért, ezt meg ezért nem lehet megoldani" játékot játszani, az húzzon fel egy drupalt vagy egy WP-t a tárhelyére és ugorjon neki a feladatnak, a net tele van megoldásokkal, pluginekkel, modulokkal.

xsolutions · http://blogvilag.hu 2009.05.27. 22:54:38

@cserepj: Nem baj ha nem értünk egyet, főleg, hogy teljesen másképp értelmezzük azt, amit írtam.
Én az alvállalkozó oldaláról beszélek, az ott felépítendő hierarchiáról. Egyébként írtunk már olyan programot, ahol a minőségi kapcsolattartó egy jogász volt. Megjegyzem a megrendelő részéről jobb anyagot azóta se kaptunk.
Az architect - legalábbis nálunk - az ideje < 50%-ban programozik. Főleg azért, mert nincs olyan cég, amelyik hajlandó lenne megfizetni az óradíját. Viszont az indián programozóink nem ismerik a vállalati architectúrát, és nincs meg az a tapasztalatuk, ami alapján megtervezhetnék a programot. Igen, a programozókból lettek az architectek. Evolúció.

Mindettől függetlenül, erről az egészről Hoffi jut eszembe. Kis pénz, kis foci. Aki nem fizeti meg a szükséges szakembereket, annak a programja is inkább csak sufnituning. Saját szememmel láttam már ilyet, nem a kisujjamból szedem :)
És még egyszer, tisztelet a kivételnek, ahol kevés ember piszok jó melót végez.
(Rossz vállalati felépítés esetén pedig sok bába között elvész a gyerek. A waterfall felépítésnek is megtalálhatjuk a maga nyomorát.)

Bond, JamesBond · http://twitter.com/fisssi 2009.05.28. 14:03:43

@adManiac: Én is azon a véleményen vagyok, hogy a "köztes embernek" nem kell programozónak lennie, sőt. A programozók általában jó képességű emberek (azért erre is van kivétel...), amire nekik szükségük van, az egy részletes, normális specifikáció.
Ez lehet írásos, vagy akár szóbeli is, a lényeg, hogy a megrendelői oldalon olyan szinten letistuljon az elképzelés, hogy milyen funkciókat, milyen folyamatokat szeretne. Minnél konkrétabb, annál jobb.
Ennek megértésére és szavakba-mondatokba-bekezdésekbe öntésére jöhet jól az a bizonyos "köztes ember", aki ideális esetben több fejlesztési projektben részt vett már, még ideálisabb esetben ismeri a megrendelő által képviselt iparágat/piacot.
A programozók mindent meg tudnak csinálni, ha kellően erőszakos az ügyfél, akkor egy baromi rossz megoldást is elkészítenek (az ügyfél kérése szent). Optimális esetben értelmes párbeszéd alakul ki a két (három) fél között, a fejlesztők értékes véleménnyel, tapasztalattal segíthetik a megrendelőt, aki esetleg nem is gondol bizonyos probléma eshetőségekre, lehetőségekre, stb.

birotom 2009.05.29. 14:21:55

Sziasztok. Látom érdekes beszélgetés alakult ki. Az én tapasztalatom az, hogy csak az ember számít. Ha az ember, emberek, akikkel dolgozol passzolnak a stílusodhoz, akkor minden ok, ha nem, akkor nagy gebasz van. Az, hogy ezek az emberek szabdúszók, vagy egy nagy cég emberei, kevéssé számít. Eg yköny szerint az együtt dolgozás olyan, mint a párkapcsolat, néha nem tudod miért, de nem megy és kész. Máskor meg szerelem első látásra.

Az persze egyértelmű, hogy ha egy ember dolgozik egy projekten, és azt elüti egy autó, akkor a projektnek annyi. Ez mondjuk igen ritka, de egy jól elhúzúdó nátha vagy egy síbaleset is okozhat 6 hetes csúszást. Síbalesetes projektet már kellett kihoznom a trutyiból, tehát tapasztalatból beszélek: egy spéci hardver elem tervezője került hetekre kórházban valahol franciahonban - szerintetek volt dokumentáció? ;-)

A cég tehát jobb, ha meg van szervezve a helyettesítés. A legtöbb cégnél, akit ismerek, nincs igazi szervezet, olyan, mintha sok kis szabadúszó lenne egy teremben, közös titkárnővel és könyvelővel. Ha a cég nincs rendsen vezetve, nincs módszertan, minőségbiztosítás, akkor az emberek ugyanúgy nem tudják egymást helyettesíteni. Nálunk ez mind megvan, és így is állati nehéz, ha valaki kidől, nem beszélve egy influenza járványról, ami persze mindig télen van, amikor a legtöbb a határidő... no comment.

Az open vagy zárt forrásnál én az openre szavazok, de ott sem mindegy melyikre. De itt legalább bele tudsz túrni, ha cserben hagynak, vagy bele tudsz nézni, mielőtt használni kezded. És általában az openhez sokkal többen értenek, ha cserélni kell. Mi csak 2008-ban tértünk át openre, de azóta megtöbszöröződött a mi szoftverünkhöz értők száma. (Jut eszembe, kedves Konrad, a SharePoint mellé berakhattad volna a DNN-t, Umbraco-t, Sense/Net ECMS-t is, ne árválkodjuk szegény Sharepoint a .NET platformon...)

Ennyi voltam, persze órákig tudnék írni a témáról...ha lenne időm. Szerencsére az én időmet elég jól lekötik azok, akik minket választottak szállítónak. :-)

TF112 2009.10.11. 21:15:31

A megrendelő nyilván tudja mit szeretne, legfeljebb nem tud specifikációt összeállítani, illetve nem is érdemes neki, mert nem portálkészítéssel foglalkozik nap mint nap, nem ért a seohoz, a usabilityhez, marketinghez. Érdekelne, hogy ki az aki ezzel foglalkozik magyarországon, hogy a megrendelő elképzeléséből, meg tudja csinálni a terveket?

www.vancebell.com/information-architecture-user-experience-design.php


süti beállítások módosítása