ugrás a tartalomhoz

Nem opeszósz

tolmi · 2007. Aug. 2. (Cs), 18.14
Az imént akadtam bele ebbe a hirdetésbe. A beküldő explicit kinyílvánítja, hogy nem kíván nyílt forrású megoldást látni a munka során (hjaj), de ezt megfejeli egy magyarázattal is: "biztonsági okokból". (Khm. Tudtommal a PHP futtatókörnyezet is open source :) )
Mivel az elmúlt két hónapban 10x legalább hallottam potenciális magyar kliensektől(nagyobbacskák meg kissebbecskék is), felmerül bennem a kérdés: Miért? Mi a rákfenéje ezen emberek szerint a nyílt forrású dolgoknak?
Az hogy nyílt forrás, tudtommal nem szinonímája az "ementáli kód"-nak. Tehát attól hogy valami open-source, lehet nagyon robusztus, biztonságos és stabil(És egyre többször az is. Rengeteg pozitív példa van!).
Egy tapasztalt megoldásszállító nyílt forrású szoftverekkel a következő előnyöket tudja kínálni az ügyfeleinek:
- Biztonság (Igen, tényleg. A kiforrott megoldásoknak bizony több ezres aktív közössége van, ebből 140-50 a kódot nézi szinte minden nap, ugyanis valószínüleg az a munkája hogy ezt fejlessze vagy ezen munkáját értékesíti ;))
- Rugalmasság (Gyorsabban lehet változtatni a felépítményen, mivel a fent említett komponensek flexibilisek)
- Nincs fejlesztőhöz kötés (Bárki megtanulhatja, a kliens nem függ a fejlesztőtől)
- Rövid fejlesztési/bevezetési idő
- Költséghatékonyág (Nyilván csak a bevezetési és tanácsadási díjat kell megfizetni, ellentétben a bevezetési, tanácsadási és fejlesztési díjjal. Vagy ha komponensről van szó, akkor sem kell az egész díjat kifizetni.)

Ehhez képest mit kap egy egyedi fejlesztéstől:
- Hosszabb fejlesztési idő (Oké, nyílván belső komponensekkel ez nem annyira áll)
- Fejlesztőhöz kötés
- Nagyobb hibavalószínüség (Nem használják sok helyen, nem olyan mennyiségű felhasználó tesztelte)
- Drágább
- Rugalmatlan (Egyedi fejlesztésnél a kivitelező hajlamos csak a kitűzött feladatot megoldani. Isten óvjon a változásoktól :) )
- Nagyobb bukási valószínüség (Ezek összessége miatt)

Szóval akkor hogy is van ez? Az emberek mazohisták? :)
 
1

Van alapja

janoszen · 2007. Aug. 2. (Cs), 18.34
Egyetlen egy érv szól az open source szoftverek ellen: van kód, tesztkörnyezet amin ki tudod próbálni a töréseidet. Talán még egy nagyon kicsi apróság, hogy sokszor nem akkora léptékű szoftvernek indultak, mint amekkorák lettek és néha a tervezés totális hiánya ott van rendesen a dologban. Próbálj meg például kapásból kiigazodni a Wordpress forráskódjában.

Vonal alatt: az open source szoftverek tudnak eléggé összegányoltak lenni, de még mindig kevésbé mint egy-két fura hajlam által vezérelt szekuriti mániás webfejlesztőé. Láttam pl olyat, hogy saját escapelő függvényt használ mert nem bízik meg a beépítettben, de ugyanúgy AUTO_INCREMENTez se használ hanem saját maga keresi ki. Amikor a hülyeség a magabiztossággal párosul, na az a veszélyes.
2

Wordpress?! :)

tolmi · 2007. Aug. 2. (Cs), 18.53
Mi az a Wordpress?! Számomra nem létezik. Ami nekem open source szoftver:
- Zend Framework
- CakePHP / Symfony
- easyPDO, Propel
(sajnos a PHP futtatómotor nem tartozik ide :))
- J2SE
- Alfresco
- JBoss cuccai
- TurboGears
- Drupal
...óóóó és még sorolhatnám a jobbnál jobb nyílt forrású megoldásokat. Persze, lehet kiemelni a használhatatlan szemétbányákat, de nem látom miért szükséges azonosítani velük magát a modellt. Főleg azért, amit te is írtál. IQ huszárok tudnak 100x sz*rabbat produkálni mint a bughalmaz Wordpress.
5

Az is OS

janoszen · 2007. Aug. 2. (Cs), 22.57
Hiába nem azonosítod vele, a Wordpress és *nagyon* sok más bugware is open source. Úgyhogy valahol azért van alapjuk az előitéleteknek. Az érem másik oldala természetesen az, hogy pl a saját oldalamon is WP fut egész egyszerűen azért, mert nem volt időm és kedvem egy olyat keresni amihez megközelítőleg annyi téma és plugin van.

/off: Amúgy a pl a Drupal sem maga a tökély, nagyon csúnya limitációi vannak, többek között az hogy a sablonozás ott kezdődik hogy PHP kódot kell írni és a logikája sem éppen emberközeli első ránézésre. Próbálj meg vele igazi URL-szintű egymás alá rendelést csinálni, biztos fogsz vele szívni egy kicsit.
7

Drupal

tolmi · 2007. Aug. 3. (P), 10.34
Én régóta dolgozom Drupallal és nekem egy sor PHP kódot nem kell írnom a template-be az esetek 99%-ában :)
Magyarázat. Tetszőlegesen lehet választani a célnak legjobban megfelelőt. (Nekem a PHPTemplate és a Smarty szokott a leggyakoribb lenni).

URL egymás alá/mellé rendelés: Nem hiszem hogy ez gondot okozna vagy akár szivatós lenne. Ezt villámgyorsan meg lehet oldani URL alias-okkal és/vagy taxonomy segítségével.

Persze a Drupal sem univerzális eszköz. Valóban vannak limitációi, de az esetek 95%-ában precízen és pontosan meg lehet vele oldani a feladatot zéró fejlesztéssel, ami nem kis hátrány. Ráadásul ezredannyira bugos, mint a Wordpress és világos, áttekinthető kódja van, dokumentációval. Szóval a Drupal sokkal kissebb rossz, mint mondjuk egy Nuke vagy Wordpress. Szerintem.
11

Egymás alá

janoszen · 2007. Aug. 3. (P), 14.18
Tök offtopic, de pont ez lenne a vágyam, hogy a logikailag alá-fölé rendeltségi viszonyokat ne aliasokkal kelljen megcsinálni, mert ha változtatok akkor módosíthatom át az összes aliast is... Ahogy fogalmaztál, a Drupal a kissebb rossz a sok nagyon rossz között... Sajnos eddig egyetlen rendszert sem találtam, ami támogatná a módszertan alapú fejlesztést... :(
12

Módszertan

tolmi · 2007. Aug. 3. (P), 15.43
Melyik módszertanban kívánsz fejleszteni? Hátha tudok segíteni egy tippel.
13

UML?

janoszen · 2007. Aug. 3. (P), 16.20
Hát mondjuk úgy kezdésnek nem lenne rossz, ha egyáltalán UML-t/OOP-t lehetne használni. Nyilván a PHP 4-es gyökerek miatt eléggé kötöttek az ilyen irányú törekvések.
14

PHP?

tolmi · 2007. Aug. 4. (Szo), 10.00
A PHP-t nem ilyesmire találták ki és nem is ilyen célközönséget kerítettek hozzá. Ettől függetlenül lehet nagyméretű projekteket csinálni PHP-ban, pusztán néhány funkcionalitást nélkülözni kell, vagy hozzá kell fejleszteni. Nyilván ha ilyet akarsz, nem javaslom a PHP (Ruby, Python) erőltetését(vagy fejleszd le magadnak/magatoknak az ilyen eszközt ;) ). Ellenben például Java-ban van UML módszertanú fejlesztőeszköz:
http://www.openbluelab.org/content/portal@@pageLabel=Welcome
Lényegében UML-ben "kódolsz" és az működik. Ráadásul GPL a szoftver, szóval semmi akadálya hogy alkalmazd akár fizetős ügyfeleknél is.
15

módszertan?

Hodicska Gergely · 2007. Aug. 6. (H), 03.09
Mi hiányzik a "rendszerekből" ehhez? Szerintem a módszertan inkább feléd jelentene "kötöttségeket".


Üdv,
Felhő
16

Kötöttségek?

janoszen · 2007. Aug. 6. (H), 07.57
Őőőő miért is jelentene a módszertan használata kötöttségeket? Annyiban természetesen, hogy nem nagyon van mód gányolásra, de más tekintetben?

Például az egy nagyon fontos alapelem lenne hogy az URL kezelés ne legyen alapvetően beégetve, ne kelljen teszem azt alias-okkal játszani. Vagy az, hogy alapvetően normálisan le legyenek dokumentálva a dolgok (ami a legtöbb OS projektnél sajnos nagyon nem igaz), de vehetném azt is hogy OOP alapú legyen a rendszer...
17

Headscratch

tolmi · 2007. Aug. 6. (H), 08.38
De ilyen rendszerek, keretrendszerek léteznek PHP-ban is!
Pl. a Zend Framework tudja azt amit te szeretnél és nagyon bölcsen van megtervezve. Ha nem ismered és tényleg keresel egy ilyen rendszert, vess rá egy pillantást, nem fogod megbánni!
18

rere

Hodicska Gergely · 2007. Aug. 6. (H), 17.54
Őőőő miért is jelentene a módszertan használata kötöttségeket?
Arra szerettem volna utalni, hogy szerintem jóval kevesebb igényt támaszt egy módszertan használata a rendszerrel szemben, mint feléd. A nagyobb feladat az az lesz, hogy a munkamódszereid ehhez igazítsd.

Például az egy nagyon fontos alapelem lenne hogy az URL kezelés ne legyen alapvetően beégetve, ne kelljen teszem azt alias-okkal játszani.
Elég sok keretrendszer van, ami támogatja, hogy tetszőleges Controller mechanizmust használj.

Vagy az, hogy alapvetően normálisan le legyenek dokumentálva a dolgok
Szintén elég sok keretrendszer van, ami elég rendesen le van dokumentálva.

de vehetném azt is hogy OOP alapú legyen a rendszer...
Szintén elég sok rendszer van, ami OOP, sőt igazából ez az elterjedt, és a Drupal féle megoldás az, ami elég ritka a frameworkök esetében.

Csak pár jó példa: Zend Framework, CakePHP, symfony, Solar (ez utóbbiban szerintem nagyon szép megoldások vannak, mellesleg ugyanaz a fickó csinálja, aki lerakta a ZF alapjait).


Üdv,
Felhő
9

Nincs összefüggés

nanofish · 2007. Aug. 3. (P), 10.45
A nyílt forráskód semmiképpen nem növeli anak esélyét, hogy rossz minőségű lesz a szoftver. Több zárt forráskódú szoftver karbantartásában is részt vettem már, ahol olyan mértékű gányolás volt tapasztalható, amilyet nyílt forráskód esetén csak nagyon ritkán látni.

Én úgy látom, hogy a kód széleskörű publicitása inkább igényességre ösztönzi a fejlesztőt. Szerintem a nyílt forráskód egyik legnagyobb előnye, hogy az adott nyelvet jól ismerő fejlesztő ránézésre, a kód részletes megértése nélkül is meg tudja állapítani, hogy a szoftver minősége megüti-e a mércét.
10

Sarkítás

janoszen · 2007. Aug. 3. (P), 14.16
Ha most szarkasztikus akarnék lenni, zárt forrás esetén nem veszed észre annyira a hibákat mert senki nem küld egy vagon bugreportot.
3

A félműveltsség tipikus esete

nanofish · 2007. Aug. 2. (Cs), 19.31
Úgy látszik még vannak, akik hisznek abban, hogy a kód elrejtése növeli a biztonságot. Én is találkoztam már elég sok ilyennel. Szerencsére úgy látom, hogy a vezetők többsége azért hajlandó némi új ismeret befogadására.

Ezek biztos ugyanabból a manager-magazinból szerzik az ismereteiket :).
4

FUD

Ajnasz · 2007. Aug. 2. (Cs), 20.15
Egyszerűen a FUD miatt, néha eléri a célját a negatív marketing is. :)
6

Eltűnt

sly · 2007. Aug. 3. (P), 03.36
Khhmmmm... Úgy veszem észre eltűnt a hirdetés. Egyébként szintén a nyílt forráskód híve vagyok.
8

Kapcsolat

tolmi · 2007. Aug. 3. (P), 10.41
Nem tudom miért. Én felvettem a címmel a kapcsolatot és rákérdeztem a dologra. Egy korrekt választ kaptam, amelyben beszámolt az uriember az eddigi rossz tapasztalatairól egy nyílt forrású portállal kapcsolatban, de ami még elkeserítőbb, rossz tapasztalatairól a hanyag, nemtörődöm és hozzá nem értő fejlesztőkre vonatkozólag. Ezen pedig tényleg csak úgy lehet segíteni, ha a fejlesztőket, tanácsadókat kereső cégek/személyek szemléletén változtat az ember. Sajnos nem lehet egy kicsit hozzá-nem-értés nélkül ma megfinanszírozni egy IT projektet. Erre vonatkozólag viszont semmi ötletem sincs. :(