Kaip ir buvo skelbta, konferencija prasidėjo 17 valandą. Sergejus pasidžiaugė, jog didžioji dalis žmonių yra nauji ir nedalyvavę pirmojoje konferencijoje. Aš ne taip optimistiškai interpretuočiau šį faktą: tiems, kurie buvo pirmoje konferencijoje, ji taip nepatiko, kad į antrą net nesiregistravo…
Kita vertus, 30 iš 40 konferencijos vietų buvo užimtos praėjus dviems valandoms, nuo paskelbimo apie registraciją, tai visai tikėtina, kad dalis žmonių tiesiog nespėjo sureaguoti. Kaip sakant, tų kurie ilgai kompiliuoja niekas nelaukia.
Pirmąją temą - dinaminis tinklalapių kūrimas su Silverlight pristatė Sergejus. Jis perspėjo visus, jog tai tos pačios skaidrės, kurias pristatinėjo MIDI konferencijoje, tiesa, ten jos vadinosi “Papimpink savo tinklalapį su Silverlight“.
Kas yra Silverlight? Originalus apibūdinimas paimtas iš Wikipedia:

Microsoft Silverlight is a web browser plugin that provides support for rich internet applications such as animation, vector graphics and audio-video playback.

Kažką primena? Galbūt Flash?
Tačiau kaip teigė Sergejus, tai daugiau negu Flash. Jau vien dėl to, kad logika programuoja .NET platformoje, reiškia, kad jūs galite logiką kurti su C#, Visual Basic, IronRuby, IronPython (ir galbūt IronPhp?). O gražius vaizdus galima atvaizduoti su WPF (Windows Presentation Foundation) WMF (windows media foundation). Be to, šis Microsoft produktas veikia ant daugelio standartinių OS (Windows, Mac, Linux), o taip pat ant Windows mobile bei artimiausioje ateityje ant Symbian OS. Taip pat palaiko ne tik Internet Explorer, Firefox, Opera, Safari, bet ir Konqueror ir daugelį kitų.
O sakyti, kad .NET programuotojų yra gerokai daugiau nei Flash, turbūt neverta, juk mes čia ne propagandą varom.
Viską susumavus, Silverlight laukia gražios perspektyvos.
Tiesa, yra ir keletas trūkumų, šiuo metu naujausioje versijoje Silverlight2beta1 nėra iškrentančio meniu (DropList).
Po trumpos įžangos Sergejus pateikė labai praktišką pavyzdį, kuris pakerėjo mane. Turbūt nereikia aiškinti kaip atrodo teksto įvedimo laukas, jeigu kas nors nežinote, tai pelės žymekliu užeikite ant šliužtės esančios dešinėje pusėje ir slenkamuoju pelės judesiu nutraukite ją žemyn iki komentarų formos. O dabar įsivaizduokite, kad komentarų formos fone paleidžiate kokį nors video. Tiems, kurie buvo konferencijoje įsivaizduoti nereikia, nes jie matė tai realiai. Aišku jūs paklausite manęs, kas tokio praktiško šitame pavyzdyje, aš, žinoma, atsakysiu - pagalvokite apie ateities reklamas. Reklamos efektyvios, tiek kiek jas pamato vartotojai, o kur geriau dėti reklamą, jeigu ne į komentarų formos foną?
Vėliau tą įvedimo lauką Sergejus patobulino priversdamas jį suktis. Na kokia nauda iš besisukančio teksto įvedimo lauko, net jeigu ir gali įvedinėti tekstą, man visiškai neaišku. Bet gražu.
Antrajame pavyzdyje mes kūrėme video pateikimo puslapį, kurio pagrindinės funkcijos: kairėje pusėje 10 atsitiktinių video failų, dešinėje video peržiūra ir paieška.

Detalų paaiškinimą kaip sukurti tokį puslapį galite rasti Sergejaus puslapyje (1,2,3,4,5,6,7 dalys).

Antrąją temą pristatinėjo Donatas Mažionis Mačionis ir ji vadinosi WCSF. Aišku į WCSF jūs man greičiausiai atsakytumėte WTF. Taigi tikrasis temos pavadinimas buvo Įvadas į Web Client Software Factory.
WCSF yra geriausių praktikų ir šablonų rinkinys, kuris padeda greičiau atlikti standartinius sprendimus, automatizuodamas kodo generavimą. Vienas didelis privalumas, kad kartu jis sugeneruoja ir Unit testus. Deja, jis nėra vaistas nuo visų ligų, geriausiai tinka Krioklio (Waterfall) modeliui, ar šiais laikais kas nors programuoja tokiu modeliu (apie bakalaurinių ir magistrinių darymą universitetuose aš nekalbu)?
Šis pristatymas atrodė kiek trumpesnis. Donatas priešingai nei Sergejus nerašė kodo kartu su visais, tiesiog parodė sukurtos programos pavyzdį ir jį paaiškino. Didžiausiu tokio pristatymo trūkumu aš laikyčiau, jog paskui pasidaro neaišku, kokį kodą WCSF sugeneruoja automatiškai, o kokį tenka pasirašyti pačiam.

Apibendrinus galima pasakyti, kad renginys labai šaunus ir nekantriai lauksim trečio. Tuo tarpu organizatoriai nori paprašyti visų, pasiūlyti kokias temas norėtų išgirsti, o galbūt ir patys paskaityti. Todėl nesvarbu jūs buvote ar ne būtinai pareikškite savo pageidavimus čia. Tuo tarpu aš tikiuosi, kad .NET bendruomenė suaktyvės ir norės pasidalinti savo patirtimi su kitais - Pixel.lt tam labai patogi vieta: labai paprasta prisiregistruoti, patogus teksto redaktorius, (ilgą kodą galima talpinti į paste.lt), o mūsų redaktorė ištaiso gramatines klaidas.

Konferencijos medžiagos ieškokite čia.

Gero savaitgalio ir išjunkit kompiuterius!

• reikalavimų minimumas; portabilumas - kad nereikėtų įdiegti papildomos programinės įrangos, kad veiktų kuo įvairesnėse aplinkose, nereikalautų didelio paruošimo bei palaikymo;
• resursų taupymas

Kaip gali būti realizuota tokia funkcija? Atrodo pakankamai paprastai - tereikia žinoti duombazės dydį (esamą.. bet geriau tą, kuris būtų po užklausos įvykdymo) ir jei tas dydis viršija mūsų nustatytą limitą tai atitinkamai arba leidžiama įvykdyti užklausą arba ne.

Bet yra ir kitas būdas. Žinome, kad MySQL kiekvieną duombazę saugo atskirame kataloge. Taigi tereiktų failų sistemos lygyje nustatyti apribojimą tam katalogui, kad nesipūstų per daug. GNU/Linux sistemoje yra tokia galimybė nustatyti limitą konkrečiam naudotojo namų katalogui. Taigi:

• sukuriam naują vartotoją (tebūnie ‘manovardas’) serveryje ir nustatom limitą jo namų katalogui.
• sukuriam naują duombazę:

  CREATE TABLE manodb

• sustabdom MySQL servisą - nebūtina, bet labai rekomenduojama!
• perkeliam duombazės katalogą pas naudotoją “į namus”:

  mv /var/lib/mysql/manodb /home/manovardas

  (gal reikia “-R” rakto, nepamenu)

• sukuriam nuorodą:

  ln -s /home/manovardas/manodb /var/lib/mysql/manodb

• paleidžiam MySQL servisą.

Viskas. Ar šis sprendimas tinka visada? Nemanau. Pavyzdžiui, mes nežinom, kas bus, kai duombazė pasieks tą nustatytą limitą? Ar mums vykdant “insert” užklausą bus išmesta klaida? Ar viskas užstrigs? Servisas nulūš? Internete radau kažkieno pasakymą, kad tokiu atveju lūžta einamoji MySQL serviso gija. Visgi man sunku tuo patikėt - kai man pačiam buvo pasibaigus vieta particijoj ir įterpinėjau duomenis tai tiesiog mano užklausa užšaldavo. Kiti susijungimai toliau leisdavo vykdyt SELECT užklausas. Sako, tyla gera byla, bet mūsų atveju geriau būtų klaida :) dabar sėdi naudotojas ir nežino kas vyksta. Kita problema - reikia turėti teises į failų sistemą. Dar reikia kurti papildomą sistemos naudotoją… taigi, man šis sprendimas netiko, todėl ieškojau kaip realizuot pirmu minėtu metodu (patikrinant DB dydį).

Duombazės dydis - kaip jį sužinoti?

Turbūt paprasčiausia būtų pažiūrėt, kiek užima duombazės failai. Bet ne visada galim turėt galimybę tai atlikt. Pavyzdžiui, jei jungiamės prie nutolusio MySQL serverio. Arba net jei tai vietinis serveris, vis tiek galime neturėti teisių tokiam veiksmui.

Suskaičiuoti visus įrašus… mm.. būtų galima bandyt, jei kiekvienas įrašas užimtų tiek pat vietos - tada apskaičiuotume įrašo dydį, sudaugintume su eilučių skaičiumi lentelėje ir tai pakartotume visoms lentelėms. Bet, deja, ne visi įrašai yra fiksuoto dydžio - kaltininkai čia būtų VARCHAR (ir kt.) laukai. Taigi, pamirštam.

Atrodo yra paprastesnis būdas. Tai, ko mums reikia, grąžina užklausa:

SHOW TABLE STATUS;

Kad nesikartočiau, ką jau kažkas parašė, siūlau tiesiog užeit šiuo adresu:
http://www.drquincy.com/resources/tutorials/webserverside/getthesizeofamysqldatabasewithphp/

Limitai

Žinom duombazės dydį - kas dabar? Sakykim, mūsų sistema, kuri naudos duombazę, yra svetainė rašoma su PHP. Tai nejau prieš kiekvieną užklausą vykdysim tą kodą, kuris tikrina DB dydį? Jei mums reikės padaryt 10 000 įterpimų, tai tiek kartų tikrinti būtų neracionalu. Ypač jei DB klientas ir DB serveris yra nutolę. Kita problema - gal mes norime kad ne tik php skriptas įterpinėjant duomenis neperžengtų ribos, bet kad niekaip nebūtų įmanoma apeiti limito (net tiesiai prisijungus iš konsolės)? Tada reiktų tikrinimą kažkaip “įklijuoti” į patį MySQL. Taip ir padarom:

• sukuriam funkciją (kažkas tokio kaip STORED PROCEDURE, tik grąžins skaičių) kuri nustato DB dydį
• ant kiekvienos lentelės sukuriam trigerius, kurie suveiktų, pavyzdžiui, prieš įterpimą; trigeris turėtų patikrinti ar galima įterpti, ar ne.

Atrodo gražu, bet viena problemėlė. O kaip mes trigeryje pasakysim “žinai, nebedarom įterpimo nes pasiektas limitas”? MySQL neturi tokios galimybės kaip kad “raise_error” ant Microsoft SQL Server. Sako, kad nuo MySQL 5.2 gal jau bus “signalai”, kurie leis padaryt tai, ko mums reikia.. bet mums reikia dabar. Visgi yra sprendimas:
http://www.brokenbuild.com/blog/2006/08/15/mysql-triggers-how-do-you-abort-an-insert-update-or-delete-with-a-trigger/
Siūlo tiesiog sukelti bet kokią kitą klaidos situaciją, pvz “unknown column”.

Beliko viską realizuot. Kadangi aš beveik nesu rašęs MySQL saugomų procedūrų (”STORED PROCEDURE“), funkcijų tai neišsiverčiau be MySQL dokumentacijos ir kodo pavyzdžių, rastų internete. Pavyzdžiui, štai kaip reiktų prasukt ciklą pasinaudojant kursoriais:
http://dev.mysql.com/doc/refman/5.0/en/cursors.html
Man šitas ciklas pasirodė keistokas, todėl dariau taip kaip parodyta čia:
http://www.futhark.ch/mysql/130.html

Viskas, daugiau paaiškinimų nebebus.

Funkcijos, nustatančios DB dydį, kodas:

delimiter //
CREATE FUNCTION dbsize () RETURNS integer
READS SQL DATA
BEGIN
  DECLARE size integer DEFAULT 0;
  DECLARE c1, c2, c3, c4, c5, c6,
    datalength, c8, indexlength,
    c10, c11, c12, c13, c14, c15, c16,
		c17, c18 integer;
  DECLARE done BOOLEAN DEFAULT FALSE;
 
  DECLARE curr CURSOR FOR SHOW TABLE STATUS;
  DECLARE CONTINUE HANDLER FOR SQLSTATE '02000' SET done = TRUE;
 
  OPEN curr;
 
  loop1: LOOP
 
    FETCH curr INTO c1, c2, c3, c4, c5, c6, datalength, c8, indexlength, c10, c11, c12, c13, c14, c15, c16, c17, c18;
    IF done THEN LEAVE loop1; END IF;
    SET size := size + datalength + indexlength;
 
  END LOOP loop1;
 
  CLOSE curr;
 
  RETURN size;
 
END;
//
delimiter ;

Trigerio kodas:

delimiter //
CREATE TRIGGER t1bi
BEFORE INSERT ON t1
  FOR EACH ROW
BEGIN
  SET @dummy = 0;
  IF dbsize() > 20000 THEN
    SELECT Database_size_limit_reached INTO @dummy FROM t1;
  END IF;
END;
//
delimiter ;

Čia:

• 20000 - skaičius 20000 rodo baitų kiekį, kurio negali peržengti duombazės dydis.
• t1 - lentelė, kuriai kuriamas trigeris; reikėtų sukurti kiekvienai lentelei.
• t1bi - kuriamo trigerio vardas (lentelės vardas plius pirmosios raidės iš “BEFORE INSERT”)

Dabar beliko sutvarkyt leidimus (angl. permissions). Naudotojui leisti tik SELECT, INSERT, UPDATE, DELETE, bet neleisti kurti/trinti (būtent trinti) funkcijų ir trigerių.

Išvados

Man šis sprendimas labai tinka nes:

• nėra jokių papildomų reikalavimų, nereikia nieko papildomai įdiegti, kurti papildomų lentelių. Na gerai, yra reikalavimai - būtinas trigerių palaikymas bei lentelėse negali būti stulpelis pavadinimu “Database_size_limit_reached” :)
• nors tenka kiekvienu įterpimu iš naujo patikrinti DB dydį, bet tai sąlyginai mažai resursų reikalaujantis procesas (pas mane tik ~10 lentelių o ne 200+), ir pasitelkus “STORED PROCEDURES” tikrinimas vyksta ne pas klientą o pačioje DBVS, nenaudojamas tinklo srautas.

Norint pradėti realizaciją mums būtina susigeneruoti sertifikatą ir privatų raktą.
Taigi pradedam:

openssl req -new -out cert_request.pem -keyout private_key.pem

Generacijos metu reikės įvesti informaciją, kaip elektroninio pašto adresas kompanijos pavadinimas ir t.t. Iš esmės vienintelė bankui rūpima informacija - tai elektroninio pašto adresas. Po šios operacijos bus sugeneruoti du failai:

• cert_request.pem
• private_key.pem

Pirmasis failas tai mūsų viešas raktas, kurio informaciją galime peržiūrėti komanda:

openssl req -text -noout -in cert_request.pem

Antrasis bus naudojamas susigeneruoti parduotuvės sertifikatą. Tačiau dabartinis privatus raktas yra apsaugotas slaptažodžiu, o mums reikia privataus rakto neapsaugoto slaptažodžiu. Taigi susigeneruojam privatų raktą neapsaugotą slaptažodžiu, kuris bus naudojamas taip ogo parduotuvės siunčiamiems duomenimis pasirašyti.

openssl rsa -in private_key.pem -out new_private_key.pem

Šio proceso metu reikės įvesti anksčiau įvestą slaptažodį, kuris buvo panaudotas generuojant privatų raktą pirmąja komanda. Taigi kai turime privatų raktą neapsaugotą slaptažodžiu galime sugeneruoti parduotuvės sertifikatą:

openssl req -new -x509 -days 720 -key new_private_key.pem -out rsa_new.crt

Bus sugeneruotas naujas failas rsa_new.crt tai ir bus mūsų sertifikatas. Kuris sutarties pasirašymo metu yra siunčiamas bankui. Bankas visus siunčiamus mūsų pranešimas patikrina remiantis šiuo sertifikatu.
Kai turim parduotuvės sertifikatą galime judėti toliau. Standartiškai testuojant bankas duoda kažkokį savo sertifikatą. Šiuo atveju kadangi jo neturim susigeneruojam jį tokia pat tvarka kaip ir generavom parduotuvės sertifikatą.

openssl req -new -out cert_request.pem -keyout private_key.pem
openssl rsa -in private_key.pem -out new_private_key.pem
openssl req -new -x509 -days 720 -key new_private_key.pem -out rsa_new.crt

Kad būtų aiškiau pasidariau tokią katalogų struktūrą:

• seb
  • crtshop
  • crt
• hanza
  • crtshop
  • crt
• classes
  • hanza.php
  • hanzatest.php
• index.php
• verify.php
• server.php

Kai turime sertifikatus atitinkamuose kataloguose crtshop - parduotuvės sertifikatas, crt - tariamo banko sertifikatas. Galime pradėti realizaciją. Realizacija iš esmės nėra sudėtinga. Visas veiksmas vyksta daugmaž tokia tvarka:

Taigi visas mechanizmas gan paprastas.
Kadangi pagrindinė problema susijusi su testavimu, kuris įmanomas tik kai bankas įjungia sąsaja. Sukūriau šiokį tokį frameworką testavimui. Iš esmės jo veikimas identiškas bankų veikimui.
index.php failas sugeneruoja parduotuvės užklausą bankui.
server.php patikrina ar atėję parametrai buvo pasirašyti parduotuvės
verify.php ar atsakymas atėjo iš serverio.

Iš esmės dabar turėtų eiti php kodo dalis, bet jo pastinimas manyčiau būtų netikslingas - tai pateikiu realizuotą sistemą, kurią galite parsisiųsti iš čia

Realizacija nėra sudėtinga, kai žinai ką reikia daryti. Pateiktame pavyzdyje realizacija pritaikyta Hanza bankui, bet SEB bankui viskas vyksta taip pat. Kodas gal ir nėra idealiai švarus, tačiau man ir tokio būtų užtekę, kai ieškojau informacijos apie banklink realizaciją. Trumpai tariant gal pravers kam nors. :)

Po kelių Install Fest renginių Kaune, pagaliau kažkas panašaus vyks ir Vilniuje. Todėl visi vilniečiai neturėję galimybių atvykti į Kauną, dabar galės susipažinti su Linux ir savo mieste. Renginys vyks VU Matematikos ir Informatikos fakultete.

Mintis apie šį renginį kilo planuojant „Hardy Release Party“, kuris anksčiau apsiribodavo pasisėdėjimu Forto Dvare. Šį kartą sumąstėme padaryti kažką įdomiau ir visa tai išsirutuliojo iki Ubucon’08.

Renginio metu prieš diegynę išgirsite kelis pranešėjus, kurie papasakos, kas yra atviras kodas, Linux, Ubuntu ir Baltix. Sužinosite nuo ko visa tai prasidėjo ir į ką išaugo. Po pranešimų vyks du diegynės etapai. Pirmajame etape, pažingsniui bus aiškinama kaip diegti Ubuntu, visa tai matysite dideliame ekrane, kur pranešėjas sustos ties kiekvienu žingsniu ir papasakos detaliau apie tai kas daroma. Po to prasidės antrasis etapas, kurio metu sužinosite kaip pritaikyti savo poreikiams naujai suinstaliuotą sistemą. Sužinosite apie dažniausiai naudojamas programas ir jų privalumus. Žinoma patys taip pat galėsite užduoti klausimus.

Visus norinčius renginio metu įsidiegti Ubuntu į savo kompiuterius prašome užsiregistruoti Ubucon’08 svetainėje. Registracija reikalinga tam, kad žinotume su kokia kompiuterio technika turėsime reikalų ir galėtume tam pasiruošti.

Tiksli informacija apie renginį.

• Renginio svetainė: ubuntu.lt/ubucon
• Laikas: 2008 m. gegužės 17 d. šeštadienį, 11:00
• Vieta: VU Matematikos ir Informatikos fakultetas, 101 auditorija (Naugardugo g. 24, Vilnius)

Renginį organizuoja Lietuvos Ubuntu bendruomenė.

Aš tikrai čia nesukūriau dar vieno super magiško geresnio būdo integruoti Zend framework bei Smarty, aš tiesiog remdamasis tuo, ką perskaičiau pabandžiau sukurti puslapį, kad nereiktų sukti galvos kokį tinklalapį kurti, pasinaudojau mūsų anksčiau sukurtu notebook, apie kurį buvo rašyta čia ir čia.
Ilgai negalvodamas griebiau pirmą pavyzdį ir pabandžiau pritaikyti. Kas gavosi? Ne kas…
Pirmiausia tai norit daryti include reikia nurodyti absoliutų kelią, kas atrodytų maždaug taip:

require_once("./application/smarty_view.php");

Taip greičiausiai atsitiko dėl to, kad aš kažko prikodinau kurdamas notebook projektą. Toliau pastebėjau, jog metodo setScriptPath neužtenka, pasirašiau tokį patį kuris nustato kelią iki compile_dir. O pats įdomiausias dalykas, kad po to jis vis tiek kreipiasi į view/index.phtml… Ką aš dar galiu pasakyti…
Patyrinėjęs atidžiau tą pavyzdį supratau vieną dalyką, pažiūrėkite patys:
Pirma dalis

$rendered = $view->render('bookinfo.tpl');

Antra dalis

    public function render($name)
    { 
        return $this->_smarty->fetch($name);
    }

Kaip jūs manote kokia bus $rendered reikšmė? O gi visas išspausdintas template ir ką man su juo daryti?
Tiesa, return galima pakeisti į echo, arba fetch į display. Bet šitas pakeitimas vis tiek neišsprendžia vieno dalyko: vis tiek reikia kiekvienam controler‘ui kurti po vaizdinį, nors ir tuščią. Koks mulkis, kurtų daug tuščių view failų, tam kad jo sistema veiktų?
Po ilgų instrukcijų skaitymo pagaliau įrašiau tokią eilutę:

$this->_helper->viewRenderer->setNoRender();

Ir mano nuostabai jinai suveikė, nors nelabai supratau kodėl. Tiesa, remiantis instrukcija, ta eilutė išjungia view failo generavimą tik vienam action, bet tai jau pradžia, kas nors žino geresnį variantą?

Apibendrinkime, ką per ilgas kančias pavyko pasiekti: mes galim pakeisti vieną action ir vietoj standartinio zend_view, visa bėda, kad jeigu norėsime pakeisti vietoj visų, teks kopijuoti daug kodo, kas man visai nėra miela… Pabandysiu padaryti kas išeis, bet labai tikiuosi ir jūsų pagalbos.

Dabar susimąsčiau, o kam man tas smarty… Matote iki šiol dirbom teoriniame lygyje tikėdamiesi, jog praktikoje viskas su realiais duomenimis veiks puikiai… Nė velnio! Pasirodo, anksčiau parašytas projektas notebook duomenis grąžina Zend_Db_Table_Rowset, kuris paprastai nenori būti masyvu.

Tiek to sureagavau per daug karštai, tiesiog jau nusibodo knistis po instrukcijas, problema išsisprendžia gana lengvai:

$note->fetchAll()->toArray();

Kaip matote paversti į masyvą viską labai lengva.

Kad nereiktų šimtus kartų kurti objekto, kuris dirba su smarty, visą kūrimą iškeliam į index.php failą, o sukurtą objektą užregistruojam.

$view = new Zend_View_Smarty();
$view->setScriptPath('./smarty/templates');
$view->setCompilePath('./smarty/templates_c');
Zend_Registry::set('view', $view);

Toliau kiekviename action tereikia išsitraukti $view iš registro ir galima su juo dirbti

$view = Zend_Registry::get('view');

Kažkoks Emo įrašas gavosi, bet, rodos, tai svarbiau negu ką norėjau pasakyti, daugiau pamatysite parsisiuntę kodą.

Tiesa, originalus notebook projektas buvo sukurtas ant zend framework 1.0.3 versijos, ar jis veiks ant naujesnės 1.5.1? Patikrinkim.
Deja, atrodo atsirado kai kurių pakeitimų, bibliotekų užkrovime. Hm… kažkaip einam tolyn, bet gaunasi ne progresas, o regresas. Anksčiau visas direktorijas buvo galima nurodyti su komanda set_include_path, tačiau 1.5.1 versija kažkaip įsigudrino ignoruoti šį parametrą, todėl dabar prie savo sukurtų klasių reikia nurodyti ir direktoriją, kuriose jos yra, atrodo šitaip

Zend_Loader::loadClass('Zend_View_Smarty','./library/');

Kodas su viena pataisyta eilute.

Ką manote apie tokį Zend framework ir Smarty apjungimą? Ar galite pasiūlyti ką patobulinti esamame būde, ar geriau pabandyti kurį nors kitą?

Laukiami ne vien “web developeriai”, tačiau ir žmonės norintys susipažinti su kalba, jos ideologija ir principais stovinčiais už jos.

Temos:

• Artūras ‘arturaz’ Šlajus
  • How I fell in love (and started abusing) Ruby
  • Rails? Čia tas naujas serialas iš Meksikos?
  • (Į)skiepai nuo galvasopio
  • Pažintis su CRUD-oriented architektūros kūrimu
  • Rails profilingas ir optimizavimas
• Eimantas ‘enc’ Vaičiūnas
  • UJS: nepiktas HTML tiuningas su unobtrusive Javascript
• Saulius Grigaitis
  • Testavimas su RSpec/Selenium/Watir
  • Saugus seksas su Rails
  • Rails “deploy’inimas” lengvai
• Fiodor Vereščiaka
  • MERB: WEB’as su Ruby tai ne tik Rails (+ data_mapper)
• Laurynas Liutkus
  • Ruby and C - make love, not war

Trumpa programėlė:

1. Įžanginės temos
2. Pertraukėlė kavai/picai/sumuštiniams
3. Tęsiam konferenciją toliau
4. Atvira diskusija - jūs klausiat, mes atsakom (o gal geriau atvirkščiai?)

Taigi lauksime klausytojų, o taipogi gal ir atsiras kas nors dar norintis paplepėti? :)

Konferencijos stilius: neoficialus ir linksmas. Ruby tai ne Java, su Ruby reik programuot linksmai ;)

Vieta: KTU Informacinių Technologijų Plėtros Institutas (ITPI, dar žinomas kaip Skaičiavimo Centras (SC)), Studentų g. 48A, Kaunas.
Pradžia: 2008 m. balandžio 13 d., sekmadienis, 11:00.
Įėję į pastatą rasite rodykles vedančias jus į patalpas, kuriose ir plepėsim.
Kaip nusigauti iki pastato? Na yra du būdai: su mašina arba su autobusu. Su traukiniu nepažįstantiems Kauno nelabai rekomenduoju, mat traukinių stotis (nuo Vilniaus pusės yra uždaryta, nes remontuojamas tunelis, ir tektų įdomiai po Kauną pasibaladoti, jog nusigauti iki SC)
Taipogi galite pasinaudoti šiais nuostabiais įrankiais: optimalaus maršruto paieška ir trumpiausio kelio paieška.
DĖMĖSIO: jeigu sugalvotumėte atvykti, būtų malonu, jog užpildytumėte šią trumpą formą.
Daugiau (pabiros) informacijos:

• RubyConfLT spoiler!
• RubyConfLT 1 - šiek tiek info

Konferencijos pradžia: 10:00, Balandžio 12 d.

Vieta, kaip visad - KTU Informacinių Technologijų Plėtros Institutas, Studentų g. 48A, Kaunas

Registracija

Turit klausimų? Rašykite.

Konferencijos rėmėjai -

Kompanija ieškanti patyrusių programuotojų.

Esu matęs ne vieną turinio valdymo sistemą ir mane labiausiai trikdydavo tai, kad kiekvienam moduliui būdavo mažiausiai po kelis vienodus failus. Įsivaizduokite, kad turime naujienų modulį tuomet mes greičiausiai turėsime news.php ir news.class.php, manote jog tai viskas? Klystate, tokius failus turėsime kliento ir administratoriaus dalyje, nesuprantu, kam reikalingas tų failų, tų pačių funkcijų dubliavimas.
Kitas man nesuprantamas dalykas, tai kodėl norėdamas parašyti naują straipsnį turiu jungtis prie administravimo? Kodėl negalėtų būti tiesiog meniu punktas “rašyti” vartotojo dalyje? Ar tikrai reikia atskirti vartotojo ir administratoriaus dalis?
Taigi, kuriam savo TVS. Nuo ko turėtume pradėti? Gal nuo failų struktūros. Šia tema Pixel.lt buvo vienas straipsnis, tačiau labai sukritikuotas. Todėl, matyt, reikėtų pradėti nuo pradžių.
Greičiausiai CSS failus saugosime direktorijoje css, js - scripts, paveikslėlius - images, vartotojo įkeliamus failus - files. Gerai?
O puslapio dizaino paveikslėlius kur saugoti css/images ar tiesiog images?
Ar reikalinga galimybė lengvai pasikeisti puslapio dizainą? Jeigu taip, tai galbūt reiktų dizainus saugoti direktorijoje themes/dizaino_pavadinimas? Atitinkamai persikels ir css bei dizaino paveikslėlių failai į themes/dizaino_pavadinimas/css bei themes/dizaino_pavadinimas/images. Kita vertus, kaip dažnai jūs keičiate savo puslapio dizainą?
Aš esu didelis Smarty šalininkas, tačiau ar tikrai verta naudoti šablonų variklį? Jeigu taip, tai gal yra kas nors geriau už Smarty?
Pakalbėkime apie TVS varikliuką. Jeigu kalbėsim sąžiningai, tai funkcinis kodas veikia greičiau, tačiau ar 0.001 sekundė mums svarbi? Jeigu rašome objektiškai tai greičiausiai klases saugosim direktorijoje classes, o modulius - modules. Gerai?
Duomenų bazė. Naudosime Mysql? O gal geriau susikurti failinę struktūrą ir viską saugoti xml, csv, ar kitokio tipo failuose?
Dar vienas dalykas - kalbos, ar reikia daryti daugiakalbę sistemą ar užteks vienkalbės? Jeigu darome daugiakalbę, kaip tuomet daryti su vertimais? Talpinti duomenų bazėje? O gal geriau failuose? Kaip lengviausiai ir geriausiai padaryti vertimus, kad nereiktų vėliau dėl to gaišti daug laiko?
Moduliai. Kokių modulių jums reikia? Man asmeniškai užtenka naujienų su komentavimo galimybe ir RSS, o jums?
Niekada nesupratau, kam reikalingi tokie moduliai, kaip sistemos statistika arba naujienų prenumerata. Jeigu norite statistikos įsidedate Google Analytics, jis tikrai nėra vienintelis šioje srityje, tiesiog geriausiai žinomas. Jeigu norite naujienų prenumeratos, tai tuomet savo RSS paleidžiate per FeedBurner ir valio. O gal vis dėl to yra priežastys, kurti tokius modulius?
Atrodo būsiu praleidęs vieną labai svarbią dalį: visą kodą rašyti savo ar galbūt naudotis kokiomis kodo bibliotekomis? Zend Framework, prototype.js, jquerry, žinote dar kokią nors gerą?
Ar projektui reiktų naudoti MVC, o gal yra kokia nors geresnė alternatyva?
Tikiuosi išsamios diskusijos, pasiūlymų, idėjų, klausimų. Rėžkit viską nuo liežuvio galo, negailėkit klaviatūrų. Jeigu diskusija pavyks, pabandysiu parašyti dar vieną apibendrinantį straipsnį. O dabar laukiu jūsų komentarų.

Taip pat šiemet vėl rengiami geriausių tinklaraščių rinkimai. Kadangi pernai mes jau laimėjome technologijų kategorijoje, šiemet nebeagituojam balsuoti už šį tinklaraštį. Tačiau visgi, noriu pasiūlyti balsuoti ir pareikšti nuomonę apie geriausius tinklaraščius. Kai kam tai bus motyvacija pasistengti labiau. Tai atlikti galima Alfa.lt portale - “BLOGin 2008: Geriausių tinklaraščių rinkimai“.
Taip kaip ir kitos tematikos blogas - Dievų Žiniasklaida, norėčiau pristatyti kolegas iš technologijų kategorijos.

• A. Aleksandravičius http://www.nejau.net - asmeniškai šio blogo neskaitau, tačiau jis turi beveik 100 prenumeratorių.
• Aurimas Online www.aurimas.eu - šiuo metu aprimęs, tačiau rašo įdomiai.
• Blogas.lt/Internetas - pristatyti šio blogo turbūt nereikia. Jį privalote skaityti visi. Įvairios “slaptos” naujienos/gandai, kurie būna tikslūs. Ir stebėtinas anonimiškumas.
• http://boom.lt/ - programinės įrangos blogas. Jame rašyti galite visi, lygiai taip kaip ir Pixel.lt. Asmeniškai aš balsavau už jį (aišku, todėl, kad esu administratorius :) ).
• InformacijosApsauga.lt - įdomus tinklaraštis apie informacijos apsaugą Lietuvoje. Jeigu turėčiau tris balsus - trečiasis būtų atitekęs jam.
• www.nezinau.lt - vėlgi, šio tinklaraščio pristatinėti turbūt nereikia. Pernai metais jam nepasisekė laimėti, šiais metais jis yra ryškus lyderis (bent jau šio straipsnio rašymo metu).
• Povilas Balzaravičius http://pawka.linija.net/ - šis žmogus rašo nedažnai, bet jo pamąstymai ir straipsniai verti dėmesio. Beje, jis yra parašęs ir į Pixel.lt
• www.radiocool.lt - puiki gizmodo.com alternatyva Lietuvoje. Netgi geresnė - ne toks didelis srautas, o sužinai daug.
• http://tikra.info - “tik tikra informacija”. IT naujienos ir pan. Kada nors tokie blogai nukonkuruos Delfi`us :)
• Vaidas Žilionis http://www.zilionis.net/ - be komentarų. Daug kam žinomas - rašo aktualiai ir pateikia įdomią informaciją.
• Vidmantas // emptydot.com - programuotojas, įdomus žmogus ir tikrai vertas dėmesio blogeris. Bei vienas iš tų kelių lietuvių blogerių, kurie yra mano prenumeruojamų RSS sąraše.

Ką gi, pasirinkimas didelis. Pareikškit savo balsą - blogeriams jo reikia. P.s. palaikyti galite ir vieno iš mūsų administratorių, NePo, komiksų tinklaraštį Co.Nepo.lt kategorijoje “Medijos”. :)

Susitiksim BLOGin 2008!

Atnaujinimas 2008-03-39 17:05: už pixel.lt balsuojama nesąžiningai. Gavome informacijos iš organizatorių, jog panaudoti ir užsienio IP adresai. Pixel.lt nepritaria tokiems žingsniams ir jau yra sprendžiami tolimesni veiksmai. Pirmadienį organizatoriai nuspręs ar pixel.lt pasitrauks iš balsavimo, ar bus imtasi kitų priemonių.
P.s. kad ir kas taip elgiasi, žinokite, jog tai mums naudos neduoda.