Gal ir neblogai būtų, tačiau chebra iš Drupal.org kreivais keliais pasuko, galbūt dėl to kad Joomla išleido nauja versiją savo CMS arba velniai žino kodėl paskubomis pradejo developinti D7 kuomet D6 neturi nei pusės portintų modulių iš D5. Tik prieš savaitę pasirodė pranešimas kad Views2 RC for D6 (release candidate) versija pasirodė, kas yra ganėtinai per vėlu ir Drupal 6 kaip projektas, mano nuomone, beveik mires.
Vienintelis dalykas ką chebra daro iš Drupal komandos tai reguliarios konferencijos ir oro judinimas.
Paskutiniu metu Drupal tapo tik lengvų svetainių CMS, kur nereikalaujama daug specifinio funkcionalumo. Aišku šitas galioja ne visais atvejais. Tie kurie turi supratimo apie Drupal API ir gilinasi į tai, tikrai pasidarys ko jiems reikia, tačiau vidutiniams vartotojams, visai ne guru tampa vis sunkiau.
Na dėl D6 tai taip sutinku. Neturi dalies pagrindinių ir svarbių modulių, drupal komanda rodos juos ir pamiršo ir pasinėrė į D7 kūrimą.
Aš pvz kai ką nors darau su Drupalu tai renkuosi D5.7 ir pasidarau ka reikia. Tačiau iškyla kitokių problemikių. Keletas modulių tokių kaip Advertisement ir pan. labai apkrauna Drupal'ą ir stabdo darbą. Tokios tendencijos, kad kuo tolyn į mišką, tuo daugiau medžių ir querių.
Kiek skaitinėjau Dries Buytaert straipsnių apie D7 tai turetų būt išsprestos tokios problemos kaip SQL querių stabdymas ir pan. Tik va vėl modulių klausimas. D7 turetų būti šiek tiek perrašytas ir skirsis API. Ar nebus D6 likimas? :)
Nereikia čia apie drupal mirtį. Taip, D6 panaudojimas dar nėra įsibėgėjęs. Bet dėl tų pačių priežasčių dabar buvo nukeltas D7 code-freeze. Būtent minėtos problemos su užklausų skaičiumi ir verčia tobulinti sistemą.
Plius reikia kiek profesionaliau žiūrėti ir atskirti drupal core ir modulius. Šerdies kodo kokybė yra gera eile aukštesnė nei daugumos modulių. Be to, tai yra atviras kodas - matai problemas su moduliu, sėsk, žiūrėk kodą, taisyk, siūlyk patch'us. Norint ką nors rimčiau su drupal daryti neužtenka mokėti diegti modulius, vertimus ir dar gal dirbti su cck bei views (ir geriausiu atveju - panels). Dirbdamas vien pele, aišku, aukščiau minimalių štampuojamų svetainių nepakilsi. Kad rimti projektai su drupal nedaromi, irgi netiesa. Pasidomėt reik prieš skambinant puodais.
Nu čia galima dar kariauti ir ginčytis, ir pyktis.
Viena tai tikrai reikia pripažinti, kad rimtiems projektams Drupal kaip framework'as yra kiek per sudėtingas dalykas. Praeina šiek tiek laiko kol įsigilini ir pradedi suvokti kas ir kaip aplinkuj dedasi. Tenka man pačiam su komanda dabar daryti vieną rimtą užsienio rinkai projektuką su Drupal sistema. Na ką, praejo beveik 9 mėnesiai, projektas dar vis daromas ir vystomas. Apimtis nėra didelė, funkcionalumas vidutinis. Iškyla tos pačios problemos su letomis SQL užklausomis, sistemos darbu (šerdies funkcionalumas), tenka perrašinėti ar pataisyti keleta modulių.
Tačiau naujiems projektams aš linkęs naudoti kažką kas lengviau valdosi kai reikia specifinio funkcionalumo ar netgi visiškai naujo produkto, pvz: CodeIgniter iš ElisLabs, t.y. frameworkas paremtas OOP (Object oriented programming) PHP.
P.S. mano nuomonė nebūtinai turi sutapti su bet kuriuo iš jūsų.
P.p.S.s. Jeigu čia 'tasdomas' savo paskutinius du sakinius taikai man, tai tu nė velnio apie mane nežinai.
Na memcached irgi ne visada padeda.. t.y. padeda tik tuo atveju jeigu yra tikrai daug vartotojų ir loadas didelis. Veikimo principas ir yra tas, kad visą informaciją užkrauna į RAM ir po to sušeria vartotojams. Tai šiuo taveju neišsprendžia lėtų užklausų problemos.
Gal ir aiški ar logiška API drupalo, bet tikrai ne geriausia.
Geriausias API - labai reliatyvus dalykas. Taip, kartais drupal procedūriškumas trukdo, bet yra daug stiprių pusių. O šiaip, įdomumui, kokios sistemos pačiam labiau prie širdies?
Kas dėl memcache, tai jis ir skirtas lėtų užklausų problemai spręsti. O šiaip pats sprendimas labai priklauso nuo to, kokios būtent užklausos reikalingos. Kartais gali išgelbėti tinkamai sudėti indeksai, kartais - kodo perrašymas (ypač kai daromi dvigubi select'ai sąrašui ir pačiam objektui, kas greit virsta O(n^2) problema).
Pasidalink patirtimi, kokių modulių, kokios užklausos kelia problemų. Bus vertinga informacija kitiems + gal pavyks rast sprendimą. Drupal.lt per didelę turinio dalį sudaro primityvūs klausimai - laikas augt ;-].
Na kad API reliatyvus dalykas tai taip sutinku, kas gero vienam, nebutinai tinka kitam. Drupal procedūriškumas nėra lengvas dalykas bet taip.. kartais turi savo pliusų pvz 'form alter' ar kitokie niekučiai kurie vienaip ar kitaip padeda. Man tai 'prie širdies' pure OOP PHP frameworkai tokie kaip CodeIgniter ir CakePHP. Nedaug ką čia ir pasakysi.
Dėl modulių kurie kelia daugiausia problemų gal greičiau reikėtų paminėti visų pirma kreivas vartotojų rankas ir truputėlį akmenukų į developerių daržus. O pats pagrindinis stabdys yra Views. Nemoksiskai ar dėl žinių trūkumo sudaryti Viewsai (filtrai) užkrauna bereikalingomis SQL užklausomis visą svetainę, kiek teko pastebėti, nesvarbu kuriame pusapyje sėdi views užklausos, jos executinamos bet kur ir visada, kas kiek keistoka pasirodė. Kad pamatyti viską, galima butų naudoti server-side įrankius užklausoms gaudyti arba Devel modulį Drupalui. Kitas nemažiau populiarus modulis yra Advertisement.. kuris duoda viso labo ~8 užklausas per aktyvų reklamos bloką.
Labas, visai neblogai būtų
Labas,
visai neblogai būtų nuvykti, bet tuo metu busiu kitur..
Gaila
Gaila, aišku. Reikėtų kada susipažinti - nedaug pažįstu su drupal Lietuvoje dirbančių žmonių.
Gal ir neblogai būtų,
Gal ir neblogai būtų, tačiau chebra iš Drupal.org kreivais keliais pasuko, galbūt dėl to kad Joomla išleido nauja versiją savo CMS arba velniai žino kodėl paskubomis pradejo developinti D7 kuomet D6 neturi nei pusės portintų modulių iš D5. Tik prieš savaitę pasirodė pranešimas kad Views2 RC for D6 (release candidate) versija pasirodė, kas yra ganėtinai per vėlu ir Drupal 6 kaip projektas, mano nuomone, beveik mires.
Vienintelis dalykas ką chebra daro iš Drupal komandos tai reguliarios konferencijos ir oro judinimas.
Paskutiniu metu Drupal tapo tik lengvų svetainių CMS, kur nereikalaujama daug specifinio funkcionalumo. Aišku šitas galioja ne visais atvejais. Tie kurie turi supratimo apie Drupal API ir gilinasi į tai, tikrai pasidarys ko jiems reikia, tačiau vidutiniams vartotojams, visai ne guru tampa vis sunkiau.
d6 taip ir liks nenaudotas,
d6 taip ir liks nenaudotas, nors kiek žiūrėjau neką naujo ir d7 siūlo tik smulkmenos, tiesa neįsigilinau labai
Na dėl D6 tai taip sutinku.
Na dėl D6 tai taip sutinku. Neturi dalies pagrindinių ir svarbių modulių, drupal komanda rodos juos ir pamiršo ir pasinėrė į D7 kūrimą.
Aš pvz kai ką nors darau su Drupalu tai renkuosi D5.7 ir pasidarau ka reikia. Tačiau iškyla kitokių problemikių. Keletas modulių tokių kaip Advertisement ir pan. labai apkrauna Drupal'ą ir stabdo darbą. Tokios tendencijos, kad kuo tolyn į mišką, tuo daugiau medžių ir querių.
Kiek skaitinėjau Dries Buytaert straipsnių apie D7 tai turetų būt išsprestos tokios problemos kaip SQL querių stabdymas ir pan. Tik va vėl modulių klausimas. D7 turetų būti šiek tiek perrašytas ir skirsis API. Ar nebus D6 likimas? :)
Nereikia
Nereikia čia apie drupal mirtį. Taip, D6 panaudojimas dar nėra įsibėgėjęs. Bet dėl tų pačių priežasčių dabar buvo nukeltas D7 code-freeze. Būtent minėtos problemos su užklausų skaičiumi ir verčia tobulinti sistemą.
Plius reikia kiek profesionaliau žiūrėti ir atskirti drupal core ir modulius. Šerdies kodo kokybė yra gera eile aukštesnė nei daugumos modulių. Be to, tai yra atviras kodas - matai problemas su moduliu, sėsk, žiūrėk kodą, taisyk, siūlyk patch'us. Norint ką nors rimčiau su drupal daryti neužtenka mokėti diegti modulius, vertimus ir dar gal dirbti su cck bei views (ir geriausiu atveju - panels). Dirbdamas vien pele, aišku, aukščiau minimalių štampuojamų svetainių nepakilsi. Kad rimti projektai su drupal nedaromi, irgi netiesa. Pasidomėt reik prieš skambinant puodais.
Nu čia galima dar kariauti
Nu čia galima dar kariauti ir ginčytis, ir pyktis.
Viena tai tikrai reikia pripažinti, kad rimtiems projektams Drupal kaip framework'as yra kiek per sudėtingas dalykas. Praeina šiek tiek laiko kol įsigilini ir pradedi suvokti kas ir kaip aplinkuj dedasi. Tenka man pačiam su komanda dabar daryti vieną rimtą užsienio rinkai projektuką su Drupal sistema. Na ką, praejo beveik 9 mėnesiai, projektas dar vis daromas ir vystomas. Apimtis nėra didelė, funkcionalumas vidutinis. Iškyla tos pačios problemos su letomis SQL užklausomis, sistemos darbu (šerdies funkcionalumas), tenka perrašinėti ar pataisyti keleta modulių.
Tačiau naujiems projektams aš linkęs naudoti kažką kas lengviau valdosi kai reikia specifinio funkcionalumo ar netgi visiškai naujo produkto, pvz: CodeIgniter iš ElisLabs, t.y. frameworkas paremtas OOP (Object oriented programming) PHP.
P.S. mano nuomonė nebūtinai turi sutapti su bet kuriuo iš jūsų.
P.p.S.s. Jeigu čia 'tasdomas' savo paskutinius du sakinius taikai man, tai tu nė velnio apie mane nežinai.
Na, paskutiniai du sakiniai
Na, paskutiniai du sakiniai labai bendri - tiesiog yra daug rimtų projektų, daromų su drupal. Asmeniškumų čia jokių.
Su lėtomis užklausomis kovoti yra ne vienas būdas. Kai apkrovos tikrai didelės, nereikia pamiršti ir memcached panaudojimo galimybės.
Kas dėl sudėtingumo, tai drupal API nėra nesuprantama. Anaiptol. Visa architektūra yra pakankamai aiški ir logiška.
Na memcached irgi ne visada
Na memcached irgi ne visada padeda.. t.y. padeda tik tuo atveju jeigu yra tikrai daug vartotojų ir loadas didelis. Veikimo principas ir yra tas, kad visą informaciją užkrauna į RAM ir po to sušeria vartotojams. Tai šiuo taveju neišsprendžia lėtų užklausų problemos.
Gal ir aiški ar logiška API drupalo, bet tikrai ne geriausia.
Geriausias API
Geriausias API - labai reliatyvus dalykas. Taip, kartais drupal procedūriškumas trukdo, bet yra daug stiprių pusių. O šiaip, įdomumui, kokios sistemos pačiam labiau prie širdies?
Kas dėl memcache, tai jis ir skirtas lėtų užklausų problemai spręsti. O šiaip pats sprendimas labai priklauso nuo to, kokios būtent užklausos reikalingos. Kartais gali išgelbėti tinkamai sudėti indeksai, kartais - kodo perrašymas (ypač kai daromi dvigubi select'ai sąrašui ir pačiam objektui, kas greit virsta O(n^2) problema).
Pasidalink patirtimi, kokių modulių, kokios užklausos kelia problemų. Bus vertinga informacija kitiems + gal pavyks rast sprendimą. Drupal.lt per didelę turinio dalį sudaro primityvūs klausimai - laikas augt ;-].
Na kad API reliatyvus
Na kad API reliatyvus dalykas tai taip sutinku, kas gero vienam, nebutinai tinka kitam. Drupal procedūriškumas nėra lengvas dalykas bet taip.. kartais turi savo pliusų pvz 'form alter' ar kitokie niekučiai kurie vienaip ar kitaip padeda. Man tai 'prie širdies' pure OOP PHP frameworkai tokie kaip CodeIgniter ir CakePHP. Nedaug ką čia ir pasakysi.
Dėl modulių kurie kelia daugiausia problemų gal greičiau reikėtų paminėti visų pirma kreivas vartotojų rankas ir truputėlį akmenukų į developerių daržus. O pats pagrindinis stabdys yra Views. Nemoksiskai ar dėl žinių trūkumo sudaryti Viewsai (filtrai) užkrauna bereikalingomis SQL užklausomis visą svetainę, kiek teko pastebėti, nesvarbu kuriame pusapyje sėdi views užklausos, jos executinamos bet kur ir visada, kas kiek keistoka pasirodė. Kad pamatyti viską, galima butų naudoti server-side įrankius užklausoms gaudyti arba Devel modulį Drupalui. Kitas nemažiau populiarus modulis yra Advertisement.. kuris duoda viso labo ~8 užklausas per aktyvų reklamos bloką.
back to the topic
Ar pavyko nuvaziuoti i Drupalcon 2008 Szeged? Kokie ispudziai?