ugrás a tartalomhoz

Tartalomkezelés kicsiknek: PyroCMS

Walkman_ · 2012. Szep. 3. (H), 01.26

A PyroCMS egy egyszerű, moduláris felépítésű, MVC alapú, CodeIgniterre épülő tartalomkezelő rendszer. Filozófiája hogy nem akar minden problémára azonnal megoldást nyújtani, inkább kapunk egy könnyen kezelhető alaprendszert, amit modulokkal tovább bővíthetünk, ezért nagyon kis memóriaigényű és gyors.

A fejlesztőket a népszerű ExpressionEngine ihlette, így egy nagyon rugalmas, a végtelenségig bővíthető, mégis megfizethető rendszerről van szó. Maga az alaprendszer bőven alkalmas egyszerű honlapok gyors elkészítésére, ahol csak néhány oldal, esetleg egy egyszerű blog megjelenítésére van szükség, de a store-ban bővebb funckionalitást nyújtó modulokat, témákat is vehetünk. Ilyen például a külön kiegészítőként kapható PyroStreams modul, ami az ExpressionEngine csatornáihoz hasonló funkcionalitást tesz lehetővé.

Alapvetően egy néhány főből álló fejlesztőcsapatról van szó, de a nyilvános fejlesztésnek köszönhetően rengetegen küldenek be hibajavításokat, új feature-öket, fordításokat, melynek köszönhetően a rendszer már 24 nyelven elérhető, és nagyon gyorsan fejlődik. A fejlesztők között van az egyik CodeIgniter reactor fejlesztő is, így a PyroCMS mindig a legújabb CodeIgniterre épül (jelenleg a 3.0-dev-re). Amennyiben segítségre lenne szükség, a tapasztalat alapján a csapat tagjai gyorsan válaszolnak a fórumon.

Felépítés

A bevezető után tekintsük át, hogyan is néz ki az alaprendszer. A telepítés néhány egyszerű lépésben elvégezhető, természetesen magyarul is. Belépés után egyszerű design fogad minket, de ez átállítható, illetve könnyen készíthetünk egyedi témákat is.

Amikor belépünk az adminfelületre, olyan nyelven beszél hozzánk, amit a telepítőben beállítottunk. Ha a Beállítások fülön megfelelően konfiguráltuk a Google Analytics-et, akkor egyből megjelennek a látogatottsági statisztikák.

A Tartalom menüből kezelhetünk mindent ami tartalom: a blogbejegyzéseket, fájlokat, magukat az oldalakat (tehát az oldalak tartalma közvetlenül adatbázisból kerül kiszolgálásra), hozzászólásokat stb. A felület nagyon felhasználóbarát, könnyen eligazodhatnak rajta a számítástechnikához nem igazán értő ügyfelek is (szerintem mindannyian találkoztunk már velük). Az oldalak szerkesztését például a CKeditor WYSIWYG szerkesztő könnyíti meg, de a fájlkezelő használata is hasonlóképpen egyszerű: szimpla jobbklikkel hozhatunk létre könyvtárakat, illetve egy AJAX-os feltöltő könnyíti meg a dolgunkat, amivel egyszerre több fájl feltöltésére is lehetőség van.

A Navigáció menüben létrehozhatunk link csoportokat, melyeket lényegében bárhol megjeleníthetünk.

A Beállítások fülön konfigurálhatjuk, letilthatjuk a modulokat, tölthetünk fel újakat, és számos, haladó beállításra is lehetőség van, például cloud szolgáltatókon tárolhatjuk a feltöltött fájlokat, de a fájlkezelőből ugyanúgy kezelhetjük, mintha helyi fájlok lennének. Vagy akár módosíthatjuk a CKEditor tulajdonságait.

Háttér

Essen néhány szó a rendszer technikai hátteréről. A bevezetőben már említettem, hogy a CodeIgniterre épül. Nos, a PyroCMS nem más, mint egy CodeIgniter alkalmazás, néhány hasznos kiegészítővel és módosított útvonalakkal. Ez adja a rendszer egyszerűségét, könnyű fejleszthetőségét. Emiatt nincsenek függőségi igényei: ahol a PHP fut, ott minden gond nélkül fog a PyroCMS is.

Aki nem ismerné a CodeIgnitert, a keretrendszer lényege egy front controller (index.php), ami az útválasztást végzi, és leképezi a kérést a controllerekre, pontosabban a controller megfelelő metódusaira. A modellek használata nyilván erősen ajánlott, de nem kötelező, mindent elintézhetünk akár a controllerben is. Ezek betöltik a view-t (egyszerű PHP fájlok), ha meg akarunk jeleníteni valamit, de nagyon egyszerű AJAX-os kéréseket is kiszolgálni. Az alapbeállításokat konfig fájlokon keresztül könnyen módosíthatjuk, ily módon létrehozhatunk egyedi útvonalakat is.

A felhasznált kiegészítők közé tartozik például a Wiredesignz HMVC-je, ami a moduláris felépítést teszi lehetővé vagy a Lex parser, egy egyszerű template parser, amit a fejlesztők külön a PyroCMS-hez fejlesztettek (most már a FuelPHP része).

Ez utóbbiban megjeleníthetők egyszerű értékek, de többdimenziós tömbök is:

<h1>{{ title }}</h1>
{{ projects }}
<h3>{{ name }}</h3>
<h4>Assignees</h4>
<ul>
    {{ assignees }}
    <li>{{ name }}</li>
    {{ /assignees }}
</ul>
{{ /projects }}

és egyszerű feltételeket is ágyazhatunk az oldalainkba:

{{ if user.group == 'admin' }}
<p>You are an Admin!</p>
{{ elseif user.group == 'user' }}
<p>You are a normal User.</p>
{{ else }}

A template-ekben / view fájlokban csak ezeket az egyszerűbb vezérlési szerkezeteket használhatjuk, illetve néhány megjelenítést segítő taget, a template-ek túlbonyolítását elkerülendő. Ha több tagre lenne szükségünk, pluginek írásával kiegészíthetjük a template parsert.

Bővíthetőség

A rendszert többféleképpen bővíthetjük. Az első és legnyilvánvalóbb módja téma írása. Ebben az esetben csak HTML-el és egyszerű tagekkel kell foglalkoznunk.

A pluginek egy sztringet adnak vissza, melyet egyszerű tagekkel jeleníthetünk meg az oldalon: {{ plugin:function parameter="value" }}. Itt van például egy rendkívül hasznos plugin, ami megtalálható az alaprendszerben:

class Plugin_Robots extends Plugin
{
    /**
     * Hello
     *
     * Usage:
     * {{ robots:hello }}
     *
     * @return string
     */
    function hello()
    {
        $speech = trim($this->attribute('say', 'I am programmed for good... on week days. Bleep Blurp.'));
        
        $robot = '
                            "' . $speech . '"
                  _____     /
                 /_____\\
            ____[\\\'---\'/]____
           /\\ #\\ \\_____/ /# /\\
          /  \\# \\_.---._/ #/  \\
         /   /|\\  |   |  /|\\   \\
        /___/ | | |   | | | \\___\\
        |  |  | | |---| | |  |  |
        |__|  \\_| |_#_| |_/  |__|
        //\\\\  <\\ _//^\\\\_ />  //\\\\
        \\||/  |\\//// \\\\\\\\/|  \\||/
              |   |   |   |
              |---|   |---|
              |---|   |---|
              |   |   |   |
              |___|   |___|
              /   \\   /   \\
             |_____| |_____|
             |HHHHH| |HHHHH|
        ';
        
        return "<pre style=\"font-family: 'Courier New';\">$robot</pre>";
    }
}

A widgetek kis kódrészletek, amik egy adott funkciót valósítanak meg: például megjelenít egy Google Maps-et a megadott link alapján vagy különböző formokat vagy például megjeleníti a beírt HTML kódot.

A bővítés legösszetettebb módja a modul. Egy modul mindent tartalmazhat: témákat, controllereket, view fájlokat, plugineket, könyvtárakat. Core modulok például a Blog, Users, Files, Navigation, Comments, Sitemap, Templates, Widgets.

Három kiterjeszthető controller segíti a fejlesztést, ezek:

  • Public_Controller: a frontend bővítéséhez. Behúzza és megjeleníti a beállított témát, elérhető benne a template tulajdonság, amivel a böngészőbe írhatjuk a tartalmat stb.
  • Admin_Controller: ha az adminfelületet akarjuk bővíteni új beállításokkal, menükkel stb. Értelemszerűen a beállított admin témát fogja megjeleníteni.
  • REST_Controller: egy olyan osztály, ami a neki POST/GET/PUT/DELETE metódusokkal küldött adatok könnyű elérhetőségét teszi lehetővé. Mindenféle formátumot ismer (XML, JSON, CSV, HTML, PHP, SERIALIZE), Phil Sturgeon cikkében olvashatunk erről bővebben.

Szintén nagyon hasznos feature az events rendszer (a CodeIgneterben ez hooks néven fut, és ez a szemlélet, ha jól tudom jelen van a Drupalban is, de más nagy rendszerben is találkoztam már vele). Lényege hogy a core-ban előre definiált pontok, események segítségével a core fájlok hackelése nélkül változtathatunk a rendszer alapvető működésén. Ilyen események például a „bejelentkezés után” vagy „blogbejegyzés publikálás után” stb. Ha mondjuk a felhasználót egyszerre több rendszerbe is be akarjuk jelentkeztetni, mint egy külső fórum, ezek nagyon hasznosnak bizonyulhatnak.

Néhány hasznosabb modul:

  • Social Integration: a beállított szolgáltatóhoz lekéri az OAuth/Oauth2/OpenID tokent, és eltárolja az adatbázisban, így a többi modul sokkal könnyebben hozzáfér.
  • Fórum: egy nagyon egyszerű fórummotor, lényegében csak egyszerű diskurzusra alkalmaz, semmi összetettebb dolgot nem tud, de azért a 16 dollárért, amibe kerül, azt hiszem nem is várhatunk többet. A pyrocms.com is ezt használja, kipróbálható.
  • WordPress import: egy WordPress blog bejegyzéseit és címkéit tudja importálni PyroCMS-be. Ingyenes.
  • PyroBackup: az adatbázis biztonsági mentését teszi lehetővé, a backupot feltölthetjük akár Amazon S3 bucketre is.

Továbbá lehetőség van a Sparks rendszer használatára is: ez a CodeIgniter PEAR-je. Van itt az egyszerű Gravatar helpertől elkezdve REST API fejlesztést segítő könyvtáron keresztül minden.

A rendszer felülete többnyelvű, egy másik nyelvre való lefordítás annyiból áll, hogy a nyelvi fájlokban lévő változókat átírjuk, és készen is vagyunk.

Ez mind szép és jó, de mennyibe kerül?

A címben arra akartam utalni hogy a rendszer kis költségvetésű projektekhez kiválóan megfelel, ugyanis többféle verzióban kapható. Van egy mindenki által ingyenesen használható és fejleszthető Community verzió. Egyszerű honlapokhoz ez is bőven elegendő. A plusz funkcionalitást nyújtó Professional 90 dollárba kerül. Lehetőséget nyújt egy hoszton lévő bármennyi különálló site telepítésére. A site-ok megoszthatnak addonokat, témákat, és külön tartalommal rendelkezhetnek. Egy adatbázis hozzáférésen osztoznak, különböző prefixekkel választva szét a különböző oldalak tartalmát. A Pro verzióhoz hozzátartozik a PyroStreams modul is, és eltüntethető belőle minden PyroCMS-re vonatkozó márkajelzés, teljesen „white-label”-ezhető, és most már „hosted” verzióban is elérhető. Ezek bármelyikének megrendelése esetén automatikusan jár a Pro licenc is.

Az add-on store-ban a legtöbb termék néhány dolláros áron kapható. Vannak új funkcionalitást kínáló modulok (például egy egyszerű fórum, vagy Facebook bejelentkezést segítő modul), témák, pluginek. Külön megvehetjük a PyroStreams-et is (ha nem akarjuk megvenni a teljes Pro verziót).

Ha lesz rá igény, a következő részben írhatok az utóbbiról, mert az megér egy külön misét, a rendszer nagy rugalmasságát lényegében az adja. Aki dolgozott már ExpressionEngine-nel, tudja miről beszélek.

Összességében, egy nagyon egyszerű, gyors, kicsi, könnyen kezelhető, könnyen fejleszthető, és viszonylag olcsó CMS-ről van szó. Amiben még van hova fejlődni az a naprakészebb és pontosabb dokumentáció, de a tiszta és átlátható kód miatt igazából ez nem olyan nagy probléma. Bátran ajánlom mindenkinek kisebb költségvetésű projektekhez vagy akár személyes honlapok alapjához, blogokhoz is jó szolgálatot tehet.

 
1

Jó kis cucc lehet

Pepita · 2012. Szep. 3. (H), 03.20
Na most kipróbálom, bár nekem az alap fw. jön be nagyon.
A képeid alapján a fordítás nem teljes, ha így akarod - magyar viszonylatban - értékesíteni, lehet nem örülnek ennek.

Szerintem maga a CI megérne egy cikket (ha valaki megírná...:)), és arra épülve a PyroCMS is (mondjuk egy konkrét oldal bemutatásán keresztül, továbbfejlesztéssel). Jó blog, örülök, hogy olvashattam.
2

Magyar fordítás

Walkman_ · 2012. Szep. 3. (H), 03.40
Az első fordítást nem én csináltam, úgyhogy a legutóbbi verzióban még nem teljes (2.1.2), de a közeledő 2.2 verzióhoz küldtem be pull requestet (nem az én keretrendszerem). Még át kell nézni pár dolgot, de a 2.2-ben már teljes lesz a magyar fordítás is !
4

Melyik?

Pepita · 2012. Szep. 3. (H), 05.19
Nem lehet, hogy itt a CI fordításáról írsz? Mert én a PyroCMS-éről.. A CI fontosabb részeit én lefordítottam magamnak, mielőtt megláttam volna, hogy létezik. :)
5

PyroCMS-ről természetesen

Walkman_ · 2012. Szep. 3. (H), 07.09
A git repoban meg tudod nézni:
https://github.com/pyrocms/pyrocms/pull/1598

elkélne egy kis segítség amúgy :) némelyik kifejezés még mindig nagyon furcsán hangzik.
11

Nem tudom

Pepita · 2012. Szep. 7. (P), 16.56
Esetleg, ha jövő héten lesz rá időm, akkor ránézek; de igen szerény angoltudásom miatt nem szoktam "nyilvános" fordításban részt venni. Amiket "magamnak" fordítok le, azokat a pl. hibaüziket pontosan tudom, hogy mi váltja ki, tehát nem az angoltudáson múlik a helyes magyarra fordításuk.
3

Facebook csoport

Walkman_ · 2012. Szep. 3. (H), 03.46
A cikkből kimaradt hogy van egy Facebook csoport külön PyroCMS fejlesztőknek, meglepően barátságos arcokkal :)
Nagyon profi diskurzusok folynak itt néha, a fejlesztők tényleg nagyon segítőkészek.
Ha valaki szeretne bekerülni, szóljon és meghívom !
6

Megnézegettem csak úgy

inf3rno · 2012. Szep. 3. (H), 17.18
Megnézegettem csak úgy érdeklődés szintjén a CI meg a pyro kódját is, és nekem annyira nem jön be. Az a bajom a php-s keretrendszerekkel, hogy a legtöbbjén tisztán látszik, hogy az implementációt akarják nagyon általánosra megcsinálni, pedig az általánosságot az interface-nek kellene adnia, akkor lenne könnyen bővíthető a keretrendszer. CI-ben 1000 sor körüli osztályokat látok, zend2 valamivel jobb, ott 400 sorosak vannak, viszont néha még azokban is elég könnyen elveszti az ember a fonalat...

Ami engem aggaszt, hogy a cms kódjában egyetlen try-catch blokkot sem találtam. Lehet, hogy van valami szuper megoldásuk hibakezelésre, amiről eddig én semmit nem hallottam?!

szerk:
Most nézegetem a CI, Zend2, Symfony2 kódját (kb 1-2 évente megnézem a keretrendszerekét). Az a helyzet, hogy Symfony2 az első értékelhető php keretrendszer, amit eddig láttam. Nagyon hasonlóak a megoldásaik azokhoz, amiket én is használok, csak jóval többet tudnak, mert több emberórájuk volt a fejlesztésre. Szép a kódja, tetszik. Elgondolkodok rajta, hogy áttérek a használatára, ha valami nagyon bonyolult projektbe ütközök bele. Kár, hogy amikor saját rendszert kezdtem fejleszteni, akkor ez a symfony2 még csak nagyon kezdeti stádiumban volt. Csomó plusz munkát megspórolhattam volna... (Tapasztalat szerzésnek mondjuk nem volt utolsó.)

Ahogy nézem Yii sem rossz. Kb zend2 és symfony2 közé tudnám tenni. Ahogy nézem csináltak statePersister-t, ami nálam is tervben van már jó ideje, csak annyira nem volt kritikus, hogy elkészüljön.
7

Teljesen egyetértek veled. A

virág · 2012. Szep. 5. (Sze), 10.36
Teljesen egyetértek veled. A CI-ről eléggé rossz véleményem alakult ki, nem ajánlom senkinek, de nem akarok hosszas negatív kritikába belemenni, akinek megfelel a CI használja. Annyit azért leírnék, hogy én eddig ahány CI-re épülő fejlesztést láttam az mind gányolásba, kapkodásba torkollott, mert a kezdeti gyors használat és az úgynevezett "egyszerűség"-ről utóbb kiderült, hogy például képes akár katasztrófát is okozni, ami súlyos összegekben mérhető. Ez természetesen nem közvetlenül a CI hibája, hanem a felelőtlen tervezésé, amely bedőlt egy ígéretnek és nem volt körültekintő. A mostani cégemben az egyik "vicces" projekt pedig egy régebbi ExpressionEngin-re épített projekt migrálása SF2-re, az összes, projektben résztvevő fogja a fejét, hogy hogy követhettek el akkora hibát, hogy ezt a rendszert választották. Eddig 3 cégben voltak ilyen tapasztalataim CI-re épülő rendszerekkel, ami persze semmit nem jelent, biztosan én vagyok peches :))) Biztosan jónak kell lennie, ha ennyien dícsérik, ennyiféle platformon.
8

Én csak a kód minőséget

inf3rno · 2012. Szep. 5. (Sze), 12.45
Én csak a kód minőséget néztem: mekkorák az osztályok, mennyire érthető a nevükből, hogy mit csinálnak, mekkorák a metódusok, mennyire érthető a nevükből, hogy mit csinálnak, mennyi a felesleges comment (bár arra inkább rátettem egy autofoldot). Csodálkoztam egyébként, hogy van olyan php keretrendszer, ami ezen átmegy, mert néztem symfony1-et, zend1-et régebben, meg egy csomó másik rendszert, és nagyon csúnyán elbuktak ezen. (Ezért kezdtem el saját frameworkot csinálni akkor... A helyzet iróniája, hogy mostanra zf2 is kikerült a teszt fázisból, úgyhogy van egy saját keretrendszerem, amit tudok használni meg van zf2, amit ugyanúgy tudnék használni, mert ugyanolyan jó a kód minősége, csak jóval többet tud. Úgymond nem volt sok értelme a munkámnak, ha a tapasztalat szerzést nem vesszük figyelembe.)
9

Nem vagy egyedül

dropout · 2012. Szep. 7. (P), 10.42
Ugyanezt tapasztalom. Egy tákolt, rozoga valaminek érzem a CI projekjeimet...
10

Pozitív vélemény

Pepita · 2012. Szep. 7. (P), 16.52
Nem akarlak meggyőzni, sem a CI-t védeni, sem vitatkozni róla - de nekem sok szempontból bejön. Kicsi, könnyen kezelhető, könnyen továbbfejleszthető. De sok dologban neked is (és Infernonak is) igazatok van, pl. tényleg vannak "hosszabbacska" osztályok, sok komment (mondjuk az érthetőségét ez nem rontja) és vannak olyan osztályai (helperei) is, amiket én egyáltalán nem használok. De ezek helyett könnyedén írtam (számomra) jobbat. (Pl. webshopban eszembe se jutna session-be tenni kosarat, ...) Az is igaz, hogy amiatt, hogy a "hülye is képes használni", bizony vannak Szomszéd Pistikék is, akik már használták... De ez sem a fw hibája.

Természetesen a megfelelő tervezést ez a framework sem pótolja... Mint ahogy egyik sem. És nem is mondanám, hogy "ez aztán mindenhova / mindenre jó". Mint ahogy a többi sem. Tökéletes fw nincs. (Hacsak nem az enyém lesz az...:))

Szóval én nagyon is arrafelé tendálok, hogy miközben használom, fejlesztgetem tovább-tovább. Még nagyon jó is lehet belőle. De a mások által ráépített CMS-től idegenkedek, az már biztosan nem az, ami nekem kell.
12

Az általad leírt jelenség

Walkman_ · 2012. Szep. 8. (Szo), 13.20
Virág, az általad leírt jelenség (kezdők gányolása) egyáltalán nem a CI hibája, ahogy te is írtad. Ha megnézed mikor egy kezdő leül és elkezdi a PHP-t tanulni, ugyan ez történik, ezért van annyi gány kód PHP-ban, mert iszonyat könnyű elkezdeni, rövid idő alatt viszonylag komplex dolgokat össze lehet tákolni mindenféle programozási előismeret nélkül. A CI-el ráadásul ez ugye még gyorsabban megy és még nagyobb dolgokat lehet gányolni. Szerintem ez minden keretrendszerrel így van ami egyszerű és könnyen tanulható, de a rossz kódról egyáltalán nem a framework tehet, sőt szerintem az egyszerűsége sokkal inkább lehetőséget ad szép kódokat produkálni.

Egyszer olvastam egy cikket amiben a csávó azt írta hogy rossz Python programozó sokkal kevesebb van mint rossz PHP fejlesztő, de ez nem amiatt van mert PHP-ben nem lehet jó kódot írni, hanem inkább az áll a háttérben hogy azok foglalkoznak inkább Pythonnal akiknek már legalább is van némi fogalma a programozásról.

Amúgy szerintem maga a CI nem más mint egy "kiterjesztett" PHP lényegében, plusz néhány osztály amik lehetővé teszik a rapid fejlesztést.
Az ExpressionEngine-t pedig nagyon sokan dicsérik (mondjuk nem tudom azok a programozók milyen szinten vannak) és nagy cégek is használják (pl. Apple) tehát annyira rossz szerintem nem lehet, ott is talán inkább arról lehetett szó hogy kezdő volt aki csinálta és nem gondolta át rendesen.

Minden nyelven lehet szép/jó kódot írni, általában nem a nyelv korlátozza ezt hanem maga a programozó.

dropout: ezzel nem megbántani akarlak de a fenti sorok neked is szólnak. ha gánynak érzed a kódodat az nem a nyelv hibája hanem a sajátod (no offense).

Még annyi hogy szerintem nem kell mindig gyönyörű kódot írni, ez is túl van lihegve. Persze nagy projekteknél elengedhetetlen, de ha gyorsan kell valami, megírod működik és tuti hogy senki nem fogja használni az ég világon akkor minek még több időt ráfordítani csak hogy szép legyen ?
13

Magas a labda, de nem erről van szó

dropout · 2012. Szep. 8. (Szo), 15.17
Én szeretem a CI-t sokat dolgoztam vele, Phil Sturgeon-t is sokat olvastam, ExpressionEngine-t munkahelyen megvetettem projekthez, de ma már mást használnék.
Van egy szubjektív fogalmam a tiszta kódról és jó tervezésről, amibe nem illenek bele a CI-s megoldások.
Lehet, hogy nem nekem van kitalálva, vagy rosszak az elgondolásaim...
Ráadásul van, hogy hónapokig nem kell PHP-znom, és teljesen más érzés visszatérni egy PureMVC vagy Robotlegs AS3 projekthez mint egy PHP-s CI projekthez, persze nehéz összehasonlítani a kettőt, de általánosságban, ha több nyelven több keretrendszerben programozol, akkor feltűnnek problémák hiába más a feladat és a cél. Mind1, hogy numerikus analízishez írsz szűrőt, vagy webservert programozol az OOP elveknek úgyanúgy érvényesülnie kéne. Az egyiknél mindent a helyén érzek a másiknál meg keresgélnem kell, hogy most a helper függvény-ben és/vagy a származtatott core osztályban van a migrálni való funkcionalitás. Szerintem nem különülnek el jól a funkcionalitások CI-ben és sok örökölt PHP4-es megoldást is tartalmaz. Ez az én két centem, de jobban már nem akarok ebbe belemenni mert ez egy PYRO CMS topik, csak láttam, hogy valakinek hasonló tapasztalatai mint nekem és együttérzésemről biztosítottam. Ez nem "Szomszéd Pistike", meg jó nyelv-e a PHP vagy nem kérdése, ezt így fórumozva se lehet rendesen megbeszélni, mert mindenki mást ért bele az írásba, nem ismer, munkáimat se ismeri, nem tudja mire gondolok.
14

Kezdem érteni és sokkal jobb

Walkman_ · 2012. Szep. 8. (Szo), 20.00
Kezdem érteni és sokkal jobb rálátásod van a dologra mint nekem. Abban igazad van hogy a CI PHP4-re épült, ez egy ősrégi rendszer és a fejlesztéseknél is az volt eddig a fő cél hogy az API-t ne rontsák el, mindig csak kis változtatásokkal dolgoztak a frissítéseknél. Valószíűleg még a 3.0 sem fogja levetkőzni a PHP4-et.. ezért is mondják nagyon sokan hogy aki CI-t használna, használjon inkább Kohana-t; "huge improvement over CI". Jah és most már egy kicsit jobban tudjuk mire gondoltál :)
15

Így van

Pepita · 2012. Szep. 9. (V), 19.24
Amúgy szerintem maga a CI nem más mint egy "kiterjesztett" PHP lényegében, plusz néhány osztály amik lehetővé teszik a rapid fejlesztést.
Ezzel kb. 90%-ban egyetértek, emiatt viszont engem nem dob fel egy ráépített CMS. Azt miért nem én csinálom?
Egyébként az alapvető funkciókat (felhasználókezelés, fórum, stb.) nemrég kezdtem el jobban hordozhatóan megvalósítani; egy "Pistike" számára is könnyen telepíthető, összeklattyolgatós CMS szerintem nem emeli a CI megítélését. Legalábbis nekem nincs rá szükségem.
Még annyi hogy szerintem nem kell mindig gyönyörű kódot írni...
Kinek mi a gyönyörű... Nem kell gyönyörűt, de áttekinthetőt, legalább számodra könnyen érthetőt igenis kell. Mindig. Nagy tévedés, hogy "ezt nem kell már továbbfejleszteni". Soha ne mondd: soha.
16

Azt miért nem én

Walkman_ · 2012. Szep. 10. (H), 12.27
Azt miért nem én csinálom?

Mondjuk azért mert amit 3 ember 4 éve fejleszt, az egy embernek 12-be telne...

egy "Pistike" számára is könnyen telepíthető, összeklattyolgatós CMS


ezek szerint nagyon rossz a cikk, mert nem jött át ennek a CMS-nek a lényege. Ez a CMS pont hogy nem az a Wordpress vagy Joomla jellegű "mindenrevanmegoldáscsakösszekattogtatom", hanem fejlesztőbarát; a moduláris felépítés, a PyroStreams adatbázis abasztrakciós modul, a többféle controller típus, a REST API fejlesztést segítő osztályok mind a fejlesztő dolgát megkönnyítő elemek. Nincs annyiféle modul hozzá mint más rendszerekhez, és azok is csak egy-egy kisebb funkciót valósítanak meg (bár már készül két komplett webáruház megoldás is). Magában az alaprendszerben pedig szinte csak olyan modulok vannak amikre mindig szükség van; felhasználókezelő, tartalomkezelő, acces control, filekezelő és ennyi.
Ehhez képest WordPressre fejleszteni valami összetettebbet (én még nem csináltam, nem tudom) azt mondják rémálom.
Nekem bejön, de sokat gondolkoztam amit írtál, mert most kezdek egy nagy projektet és arra jutottam hogy ugyanezeket a funkciókat kéne nekem is megvalósítanom, de mire egy ilyen rendszer lenne belőle, nekem tuti eltartana 12 évig :)
Inkább azt csinálom hogy fejlesztem magát a CMS-t is olyan funckiókkal amik nekem kellenek, küldök be pull requesteket, és úgy alakul ahogy nekem jó. Ha nem, akkor verziókezeléssel még mindig merge-elhetem az ő változtatásaikat amik biztonságosabbá, stabilabbá teszik a rendszert.

Azt gondolom hogy sok ember nem veszi figyelembe azt a tényt hogy egyedül soha az életbe nem fog tudni annyit fejleszteni mint amit többen csinálnak ugyanannyi idő alatt. Ha az alapvető funckiókat meg is lehet valósítani gyorsan, ugyanazokba az apró problémákba, biztonsági lyukakba fog beleütközni, mint amiket a többiek már rég kijavítottak.
17

Mondjuk azért mert amit 3

Joó Ádám · 2012. Szep. 10. (H), 15.12
Mondjuk azért mert amit 3 ember 4 éve fejleszt, az egy embernek 12-be telne...


„A manager is a person who thinks nine women can deliver a baby in one month.”
18

Nem

Pepita · 2012. Szep. 10. (H), 23.19
Mondjuk azért mert amit 3 ember 4 éve fejleszt, az egy embernek 12-be telne...
Ez - ahogy Ádám is írja :) - sok esetben nem igaz. Ha bele kell nyúlni (és szinte minden projektnél bele kell), akkor a sajátomban fele-negyedannyi idő alatt elvégzem a módosításokat az "idegenhez" képest. Az alap felhasználó-, tartalom-, stb. kezelést megvalósítani nem olyan nagy dolog (persze már akinek). Egyszer kell jól megcsinálni, utána percek alatt "újrahasznosítom" a további projektekben. Biztonsági lyukakról meg éppen a CI esetében is beszélhetnénk... Szóval rövid- és hosszú távon nekem ez nem.

Semmi bajom a fejlesztőkkel - nem is ismerem őket -, de egyszerű matematikai levezetést alkalmazni erre a fejlesztési időre enyhén szólva mulatságos. Ha véletlenül én egyedül elkövetek vmi hasonlót egy hónap alatt, akkor én 144-szer jobb fejlesztő vagyok?! Legalább ráfordított munkaórát illik ilyenkor számolni, mert mi van, ha ők 60 óra/fő/év csinálták? Neked akkor is 12 év?
19

Brook törvényét érdemes

Joó Ádám · 2012. Szep. 11. (K), 00.40
Brook törvényét érdemes észben tartani, amikor az elvégzendő munka nagyságát és a fejlesztők számát mérlegeljük. Sosem lesz egyértelmű.
20

Ez tetszett

Pepita · 2012. Szep. 12. (Sze), 02.13
Nem csak szoftverfejlesztésre igaz, hanem kb. mindenre. Ha magamba nézek: nehéz is lenne nekem bekapcsolódnom egy teambe, sokmindent nem is használok (egyedül), amit csoportban kell.