Smagu, kai naršyklėje įvedant kokią nors informaciją į užpildomą formą, automatiškai pasiūlo tekstą iš tų, kurie kažkada jau buvo įvesti. Kitaip tariant, naršyklė “įsimena” visas mūsų įvestas formos reikšmes ir tada gali užpildyti formas už mus. Bet ne visada to reikia – būna atvirkštinis tikslas: bankinėse sistemose, įvedant savo kortelės numerį ar asmens kodą, kaip tik būtų gerai, kad “auto-complete” funkcija būtų išjungta. Kaip tai padaryti?

Atsakymas slypi pačios funkcijos veikimo principe. O jis labai paprastas – naršyklė įsimena tekstinio lauko pavadinimą, kuris slepiasi po <input name=”pavadinimas” /> – ir tada pildant kitame puslapyje formą, istorijoje ieškoma visų įmanomų reikšmių, kurios buvo įvestos į laukus su tuo pačiu pavadinimu. Tai net nebūtinai turi būti tas pats tinklalapis – paieška vyksta būtent pagal “input” pavadinimą.

Bloga naujiena yra ta, kad tokia savybė kaip “autocomplete” on/off nėra apibrėžta HTML standarte, nors kai kuriose naršyklėse ir yra palaikoma. Tad nėra tokio paprasto būdo, kad nustatytumėte vieną savybę ir “auto-complete” būtų išjungtas visose naršyklėse. Iš dalies gali padėti ir HTTPS protokolo naudojimas – vėlgi kai kuriose naršyklių versijose šio protokolo puslapiuose “auto-complete” išjungiamas automatiškai.

Bet nenusiminkite – išeitis yra. Prisiminkime – juk funkcija suveikia būtent pagal lauko pavadinimą. O kodėl mes negalime jo padaryti unikaliu? Kad kiekvieną kartą atėjęs pildyti formos, vartotojas gautų lauką su pavadinimu ne “vardas”, o, sakykime, “vardasXXXXXXX”, kur XXXXXXX būtų automatiškai sugeneruotas atsitiktinis simbolių rinkinys. Turbūt, kyla klausimas, o tai kaip tada formos apdorojimo skriptas turės “pagauti” tą atsitiktinį lauko pavadinimą? Ogi labai paprastai – kartu su forma galima paduoti “hidden” parametrą, kuris ir bus tas paslaptingas simbolių rinkinys. O iš apdorojimo pusės galima bus paimti reikšmę kaip $_POST['vardas'.$_POST['parametras']].

Štai toks trumpas patarimas web-meistrams. Beje, būtent šis būdas naudojamas “Swedbank” internetinės bankininkystės prisijungimo formoje, tik ten dar sudėtingiau – laukų pavadinimai ir “hidden” reikšmės dar papildomai užšifruojamos.

Dar viena reali istorija iš mano gyvenimo, privertusi susimąstyti apie vieną tinklalapių kūrimo aspektą. Žodžiu, buvo taip, kad sekmadienį užėjau į Tiketa.lt svetainę, norėdamas atspausdinti savo nupirktus bilietus į “Lietuvos talentų” finalą. Užeinu, o puslapyje… nėra teksto.

Tiksliau, situacija buvo dar įdomesnė – pats puslapis užsikrovė tvarkingai ir gražiai, be jokių klaidų, išskyrus tai, kad visur, kur buvo bendro pobūdžio tekstai ir stulpelių pavadinimai vietoj jų buvo tiesiog dvi raidės: NA.

Kas įdomiausia, visos nuorodos veikė ir puslapiai vartėsi tvarkingai, tik kad visur, kur buvo kažkokie tekstai ar pavadinimai, buvo NANANA. Gerai, kad iš ankstesnių apsilankymų gerai atsiminiau Tiketos tinklalapio struktūrą ir be didelio vargo prisiminiau, kokias nuorodas spausti ir kur vesti savo vartotoją ar slaptažodį – kitaip tariant, iššifravau visus NA kodus ir sėkmingai atspausdinau bilietą Bet susimąsčiau, kas čia galėjo nutikti – greičiausiai tiesiog nesikrovė kurios nors kalbos failas arba tekstai iš duomenų bazės. Ir čia dar gerai, kad buvo “NA”, o ne tiesiog tuščias laukas, nes bent jau buvo kur paspausti nuorodą.

Tad ta proga pamąstykime apie daugiakalbystę tinklalapiuose – Tiketa yra tik vienas iš pavyzdžių. Jeigu jūsų svetainėje naudojamos dvi kalbos ar daugiau, neišvengiamai kyla bendrųjų tekstų ir pavadinimų klausimas – kur saugoti visus meniu pavadinimus, bendrus tekstus ir kt. Pažiūrėkime, kokie yra variantai iš PHP ar HTML pusės:

1. Atskiri HTML šablonai

Visą HTML tekstą saugoti atskiruose šablonų failuose ir atskirti juos pagal kalbą į atskirus katalogus arba pagal prefiksus. Ar naudojamas koks nors “Smarty”, ar tiesiog paprastai viskas daroma su include() funkcija, čia nėra svarbu – su visais variantais suveiks.
Pliusas: galima daryti šiek tiek skirtingus šablonus pagal kalbą ir apdoroti juos atskirai.
Minusas: jeigu ką nors reikės pakoreguoti pačioje HTML struktūroje arba, neduok Dieve, keisti dizainą, tai kiek kalbų – tiek kartų padidėja pakeitimo darbai.

2. Kalbų failai

Gana populiarus sprendimas turinio valdymo sistemose – tiesiog turėti katalogą “language”, kuriame jau atskirai saugomi visų reikalingų kalbų failai. Aišku, klausimas dar ir toks, kaip tie failai bus “parsinami” (apdorojami) – ar ten tiesiog aprašomi tekstai kaip konstantos, ar aprašomas kažkoks kalbos masyvas, ar tiesiog kalbos reikšmės surašomos kažkokiu pseudo-tekstiniu failu, kuris vėliau apdorojamas iš PHP pusės. Teko matyti visus šiuos išvardintus variantus – matyt, visi jie turi teisę į gyvavimą, kuris geresnis – spręsti jums.
Pliusas: patogumas – galima tiesiog įkelti katalogą su savo kalbos failais ir vėliau katalogus papildyti.
Minusas: tuos failus reikia specialiai apdoroti ir pasirūpinti, kad jų struktūra būtų tokia, kad nebūtų problemų juos “parsinant”.

3. Tekstai duomenų bazėje

Ir dar vienas būdas, kur saugoti tekstus. Irgi neretai naudojamas didesniuose projektuose – tiesiog padaryti tekstų lentelę duomenų bazėje, kur pagal jos struktūrą galima būtų numatyti ir kalbų plečiamumą ateityje. Iš esmės, reikėtų dviejų lentelių – “languages” (id, title) ir “languages_text” (id, lang_id, text_title, text_keyword, text_text). Pavojus dėl šio tekstų saugojimo būdo yra lėtas tinklalapio veikimas – jeigu užsikraunant kiekvienam puslapiui, bus vykdoma užklausa į DB, tai gali atsiliepti papildomoms užsikrovimo sekundės dalims. Bet ir čia sprendimų – juk galima daryti įvairius kešavimus.
Pliusas: galimybė padaryti patogią administravimo sąsają, kur vėliau kalbų tekstus galėtų saugiai papildyti ir programavimo nenusimanantys žmonės.
Minusas: gali tekti pasirūpinti DB greičio klausimu arba įgyvendinti kažkokį duomenų kešavimą.

* * * * *

O kaip jūs sprendžiate daugiakalbystės problemą savo projektuose? Kur saugote tekstus?

Reali istorija iš gyvenimo, kuri privertė susimąstyti apie tinklalapių “call-to-action” strategiją. Užsakinėjau bilietus į skrydį per Ryanair.com. Pasirinkau viską, užsakiau, netgi sumokėjau, viskas pavyko sėkmingai, ir tada ekrane pasirodo langas, kuris, tiesą pasakius, sutrikdė.

Pažiūrėkite – langas, kuris pasirodo kaip sluoksnis ant puslapio viršaus (tinklalapis visas tampa neaktyvus), ir to lango neįmanoma išjungti: nėra nei kryžiuko, neveikia ir paspaudimas ant neaktyvios ekrano dalies.

Štai taip – siūlo man įsigyti papildomai kelionės draudimą. Ačiū, ne. Bet kaip paspausti tą “NE”? Kur mygtukas?

Tik įsižiūrėjęs, supratau, kur kampas. Mygtukas “Yes, please” yra padarytas kaip gražus mygtukas su atitinkama forma is spalva, o tekstas “No thanks, I will take a risk” yra visai ne mygtukas, o paprasčiausia nuoroda ir dar blankia spalva. Pagal visą lango dizainą tas tekstas visai iškrenta iš konteksto ir manau, kad aš ne vienintelis, jo iš karto nepastebėjęs.

Štai jums ir pavyzdys, kaip galima didinti pardavimų skaičių – tiesiog mygtuka “Pirkti” darykite didelį ir ryškų, o “Atsisakyti” – paslėpkite, kiek tik tai leidžia padorumo ribos. Ką manote apie tokį pelno gavimo būdą? Ar efektyvus?

Kuriant tinklalapį, reikia pasirūpinti ir prezentacine dalimi, tame tarpe ir rekvizitais. Ar tai būtų kompanijos svetainė, ar interneto tarnyba, ar asmeninis tinklaraštis – manau, visiems šiems tinklalapiams reikia nustatyti datą puslapio apačioje. Dažniausiai ten būna (c) ženklas, metai ir tekstas apie autorines teises. Bet dabar, kai įžengėme į 2012 metus – ar visur turi atsidurti apačioje 2012 metai? Ir ar automatiškai? Pamąstykime.

Pradėkime nuo to, ką tie metai reiškia. Iš pirmo žvilgsnio, jeigu tinklalapis sukurtas 2008 metais ir nuo tada nebuvo atnaujinamas, tai gal ir logiška ten palikti 2008 metus? Bet, kita vertus – gal šie metai nusako apskritai tinklalapio egzistavimą tinkle, ir pagal tokią logiką reikėtų rašyti 2008-2012. Čia galima ilgai ginčytis, ir abi pusės bus savaip teisios. Bet manau, kad paprasčiausias variantas iš programuotojo pusės – tiesiog nustatyti automatinį einamųjų metų rodymą.

Paprastas PHP kelių eilučių skriptukas:

$year = 2008;
if (date("Y") > $year) {
  echo $year . "-" . date("Y");
} else {
  echo $year;
}

Tokiu būdu neliks jokio galvos skausmo dėl to, kad atsikėlus sausio pirmąją dieną reikia pulti prie visų savo sukurtų ar prižiūrimų svetainių, kad pakeistumėte metus, o tuo pačiu išvengsite ir buvusių seniai pamirštų klientų skambučių dėl to paties klausimo.

Dar vienas svarbus dalykas – pasirūpinkite, kad toks “footerio” kodas krautųsi iš vieno failo. Jeigu jūsų tinklalapis turi keletą šablonų – sakykime, pagrindinė svetainė, tada versija spausdinimui, tada “popup” langų šablonas ir dar keletas, tai reikia pasirūpinti, kad apatinės dalies kodas būtų vienoje vietoje, kad jeigu ir prireiks pakeisti – tai galima būtų daryti vieną kartą.

Štai toks trumpas patarimas ir pamąstymas. O ar jūs pritariate, kad reikia metus nustatinėti automatiškai, nepriklausomai nuo to, ar svetainė atnaujinama?

Dirbdamas prie vieno projekto, turėjau suimportuoti į DB pasaulio šalis lietuvių kalba. Kadangi po ranka tokio sąrašo, o tuo labiau SQL užklausos neturėjau, tai pradėjau ieškoti “Google”. Ir, tiesą pasakius, SQL paruošto sprendimo neradau – gal blogai ieškojau? Tad paėmiau tiesiog internete rastą lentelę ir iš jos pasidariau SQL skriptą. Pateikiu jį jums, gal prireiks.

Ten nėra nieko stebuklingo – tiesiog INSERT sakiniai.

Duomenų bazės lentelės struktūra jau yra jūsų fantazijos reikalas. Mano atveju – MySQL lentelė, kur yra ID laukas su auto_increment ir VARCHAR tipo laukas, pavadintas “title_lt”. Nemanau, kad, prireikus, bus sudėtinga modifikuoti ir pritaikyti jūsų DB struktūrai.

Nuoroda parsisiuntimui: lt_countries.sql

Tobulėjant tinklalapių kūrimo technologijoms, web-meistrai skuba jas panaudoti praktikoje – dabar mūsų nebestebina HTML5 naujovės, JQuery efektai ar CSS gudrybės. Bet tuo pačiu svetainės tampa lėtesnės, ir tai rodo statistikos skaičiai – apie juos ir kalba straipsnis iš Webmonkey, kurį išverčiau jūsų dėmesiui.

Internetas storėja, pokytis vien tik per pastaruosius metus sudarė 25 procentus. Taip taip, nagrinėjant 1000 lankomiausių svetainių, vieno puslapio vidutiniškas “svoris” pakilo ketvirtadaliu – nuo 626 kB iki 784 kB. Tai gana ženklus padidėjimas – o, be abejo, kuo sunkesnis puslapis, tuo jis lėčiau kraunasi.

Naujausi duomenys ateina iš HTTP archive tarnybos, kuri pateikia duomenis apie tinklalapių svorį.

Kaip turbūt galima tikėtis, didžiausią naštą sudaro paveiksliukai – 451 iš minėtų 784 kB. Tačiau vien tik iliustracijų negalima kaltinti staigiu puslapių pasunkėjimu.

Pingdom tarnybos atstovai išnarstė duomenis iš HTTP Archive ir pateikė išvadą – pagrindinis lėto užsikrovimo kaltininkas yra JavaScript kodas. CSS failai irgi didėja gana sparčiai, bet kadangi jie bendrai yra gana maži, tai jų procentinis pailgėjimas nesudaro kritinės masės.

Citata iš minėtųjų Pingdom:

Jeigu žiūrėtume paprastai į svorį, tai didžiausia jo dalį sudaro paveiksliukai, bet greičiausiai augantis turinys yra tikrai JavaScript. Pagal užimamą vietą JavaScript užima antrąją vietą po paveiksliukų.

CSS turinys per metus padidėjo 25 procentais – tai gali atrodyti gana daug, bet čia kalba eina apie sąlyginai nedidelius failiukus. Tačiau svarbu visgi ir tai, kad absoliučiai visi turinio tipai auga pagal savo vidutinį svorį. Panašu, kad šio aspekto optimizavimas yra pamirštas arba nustumtas į antrą planą.

Pingdom ir toliau dramatizuoja padėtį – jie teigia, kad išplėtus tyrimą už top1000 tinklalapių ribų, vidutinis svoris išauga net iki 1 megabaito.

Taigi, tinklalapiai tampa sunkesni ir lėtesni, ir natūraliai kyla klausimas – ar tai tikrai svarbu? Visgi, interneto ryšys visame pasaulyje greitėja, o mobilieji 3G ir 4G tinklai vis labiau plečiasi. Taip pat reikia paminėti ir interneto naršyklių gamintojų pastangas tobulinti puslapių apdorojimo varikliukus. Tad ar tikrai reikia rūpintis tais kilobaitais?

Didesni ir sunkesni puslapiai tampa problema tik tada, kai jų procentalus didėjimas aplenkia atitinkamą interneto greičio bei naršyklių gamintojų tobulėjimą. Juk tokie tinklalapiai gimsta neatsitiktinai – tai natūrali evoliucija, rezultatas besiplečiančių funkcijų rato. Bet teigti, kad visi jūsų lankytojai turi greitą internetą, tikrai nereikėtų, ypač globaliame pasaulio kontekste, kur Pietų Korėjos gyventojams tinklalapiai kraunasi akimirksniu, o tų pačių Jungtinių Valstijų mažesniems miesteliams tenka vargti su lėtesniu ryšiu.

Kas labiausiai neramina, žvelgiant į pateiktus duomenis, yra procentalus pastovus augimas. Jeigu 25 procentų šuolio tendencija išliks, tai jau po penkerių metų vidutiniškas puslapis svers net 2.5 MB. Ir atkreipkite dėmesį – tai yra vidurkis: daug puslapių bus žymiai žymiai didesni. Tikėtis, kad interneto greitis didės atitinkamai kartu su tuo svoriu, yra gana rizikinga.

Tuo pačiu metu iš savo tinklalapių išmesti pažangias JavaScript technologijas būtų taip pat neteisinga. Bet didžiausia keistenybė yra klausimas, kodėl rimtų ir įtakingų tinklalapių kūrėjai nevengia apkrauti savo puslapių sunkiomis funkcijomis, nuo kurių vartotojų pasitenkinimas mažėja – tyrimais įrodyta, kad lankytojai dažnai nebesugrįžta į svetaines, kurios pastoviai kraunasi ilgiau negu kelias sekundes.

Kyla klausimas – o ką gi daryti? Siūlome Web Page Test tarnybą, kurios pagalba gausite pradinį supratimą, kaip kraunasi jūsų svetainė bei ką galima joje optimizuoti. Taip pat naudingas įrankis tuo požiūriu yra Google Page Speed. Dar vienas neįkainojamas pagalbininkas – įskepis YSlow.

Galite taip pat pabandyti naudoti CSS3 vietoj fono paveiksliukų, užtikrinti, kad jūsų skriptai kraunasi per CDN bei optimizuoti svetainę mobiliems įrenginiams.

Straipsnio originalas: WebMonkey

* * *

Pastaruoju metu Lietuvoje išpopuliarėjo visokie „startup“ tipo renginiai, kur iniciatyvūs žmonės susiburia į komandas ir bando per savaitgalį paversti savo idėją kažkuo apčiuopiamu. Ir ten iš karto programuoti niekas nepradeda, viskas prasideda nuo taip vadinamo „idėjos išgryninimo“. Ir vienas konkretus šio proceso etapas yra rinkos tyrimas. Jo metu reikia atsakyti į tokius klausimus:

• Ar yra panašių projektų toje rinkoje, į kurią taikaisi?
• Ar stipri konkurencija toje nišoje, ar nebus per sunku/brangu „įeiti“ į rinką?
• Jeigu konkurencijos nėra, tai gal idėja neturi perspektyvos?
• Kuo tavo projektas išsiskirs iš rinkoje esančių sprendimų?
• Ko būtent tos rinkos klientai potencialiai nori? Kaip galima patenkinti jų poreikius?
• Kokiais būdais galima bus nugalėti konkurentus ar bent jau su jais susilyginti?
• Gal verta kiek pakeisti projekto idėją ir taikyti į siauresnes nišas?
• Kokius sprendimus verslo ir technologijų atžvilgiu taiko potencialūs konkurentai?

Klausimų galima sugalvoti ir daugiau, būtent krypties parinkimui tuose renginiuose dalyvauja taip vadinami „mentoriai“ – įvairių sričių specialistai, kurie gali patarti ar tiesiog užduoti teisingus klausimus. Jeigu tu, kaip dažniausiai būna, tokių pagalbininkų „po ranka“ neturi, tai su savo komanda turi viską ištyrinėti pats.

Nuo ko pradėti?
Elementariausiai – nuo „Google“ paieškos. Tiesiog įvesk į paieškos laukelį keletą frazių, kurios, tavo manymu, labiausiai ieškomos toje nišoje. Pagal tai pažiūrėsi, ar apskritai ką nors galima rasti, tuo pačiu ir „susižvejosi“ konkurentus – tam gali sudarinėti atskirą sąrašą ir prieš kiekvieną iš jų ruošti strategiją (arba bendrai prieš visus, čia jau galima įvairiai).

Tokio tyrimo rezultatų variantai:

• Geriausias: „Google“ suranda daug įvairių tinklalapių, bet jie visi nekokybiški ir vis tiek pilnai nepatenkina ieškančių žmonių poreikio, aš su savo projektu galėčiau padaryti geriau;
• Blogiausias: „Google“ suranda daug geros kokybės tinklalapių, kurie yra populiarūs ir išties naudingi. Gal tada man su savo idėja neverta bandyti jų „perspjauti“?
• Neutralus ir neaiškus: „Google“ praktiškai nieko neranda pagal mano raktažodžius. Hm, arba raktažodžiai parenkami netinkamai, arba iš tikro nėra tokio pobūdžio tinklalapių. Bet jeigu jų išties nėra, ar to priežastis negali būti tai, kad žmonėms tiesiog nereikia tokio projekto?

Toliau. Pakilk nuo kėdės, išjunk kompiuterį ir nueik pas draugus. Taip, perskaitei teisingai. Begurkšnodamas alų, gali neformalioje aplinkoje paklausti draugų nuomonės apie tavo idėją. Papasakok, kokia nauda būtų jiems iš tavo būsimo tinklalapio, ir stebėk, ar jie „užsikabliuoja“. Ar gal jie jau naudojasi konkurentų paslaugomis ir papasakos apie jas? Pagal tai galbūt irgi turėsi, apie ką pamąstyti dėl tolimesnės idėjos krypties.

Ir paskutinis etapas – paklausinėk neutralių žmonių. Nes draugai dažnai pataikauja ir viską vertina teigiamai, o šiuo atveju reikia nešališko šalto proto. Aišku, į gatvę eiti nebūtina, bet esmė – surask žmones, kurie galėtų tau papasakoti savo poreikius.

Nepamiršk, kad reikia užduoti teisingus klausimus. Žiūrėk iš verslo perspektyvos: ar žmonės mokėtų pinigus už tavo tinklalapio lankymą ar funkcijų naudojimą? Tada atsakymai iš karto bus daug „blaivesni“.

* * *

Jeigu galvoje turi idėją, kuri, tavo manymu, yra kieta ir sulauks pasisekimo, tai užduok sau klausimą – kodėl žmonės turės užeiti į tavo tinklalapį? Vardan ko? Kokią gyvenimišką funkciją jiems padės atlikti tavo šedevras? Ar tikrai tam yra poreikis? Kitaip suformuluojant klausimą: kas būtų, jeigu tavo sistemos nebūtų – ar tai trukdytų žmonėms gyventi?

Konkretūs pavyzdžiai – kokias problemas sprendžia garsūs tinklalapiai:

Facebook ir kiti soc.tinklai. Patenkina bendravimo su nutolusiais draugais poreikį, taip pat patogūs informacijos pasidalinimui ir nuotraukų peržiūrai. Jeigu jų nebūtų – tada žmonės vis dar daugiau naudotųsi telefonais, žymų (bookmarks) tarnybomis, o nuotraukas talpintų kur nors į Picasa ir siųstų daug informacijos el.paštu. Anksčiau taip ir darydavo – bet dabar niekas prie tokios senos sistemos nenorėtų grįžti.

DELFI ir kiti naujienų portalai. Patenkina žingeidumo poreikį ir leidžia žmonėms greitai sužinoti naujausią informaciją. Jeigu tokių portalų nebūtų, būtų daug populiaresni laikraščiai ir žurnalai. Bet tie, kurie naujienas skaito internete – dažniausiai laikraščius perka jau labai nenoriai.

Google. Problema aiški – informacijos paieška. Įsivaizduokite pasaulį, kuriame nėra internetinių paieškos sistemų. O mūsų tėvai taip ir gyveno – bibliotekos būdavo perpildytos…

Čia, be abejo, yra globalūs pavyzdžiai. O lokalioje sistemoje tu turi pagalvoti, kaip žmones „užkabinti“ taip, kad jie pajaustų palengvėjimą dėl kažkokio savo aiškaus poreikio patenkinimo. Kad nebenorėtų atsisakyti ir išeiti iš tavo būsimos svetainės. Tada tai bus tikra pergalė.

Konkretus e-verslo idėjos pavyzdys. Sakykime, lokalus tinklalapis, skirtas vieno namo butų savininkų informavimui. Kur galėtum pasižiūrėti, kaip ir kiek mokėti už komunalines paslaugas, galima būtų spręsti bendrijos valdymo klausimus, informuoti apie remontus ir t.t. Įsivaizduokite, kiek žmonių dabar blaškosi ir nežino visos šios informacijos, o jie tikrai nori tai sužinoti – ypač, kai ateina laikas mokėti mokesčius mėnesio pabaigoje. Ir jeigu tokia sistema būtų sukurta ir palaikoma, tada vargu, ar žmonės norėtų jos atsisakyti. Be abejo, tokį tinklalapį galima sukurti su elementariu „Wordpress“ ir didesnė problema yra informacijos talpinime, negu technologinėje platformoje, bet idėja ir problematika, mano galva, labai aiški. Tam specialiai sukurtų sistemų matyti neteko, bent jau Lietuvoje.

Jeigu, galvodamas apie savo būsimą sistemą, negali įsivaizduoti, kad žmonės į tavo tinklalapį tiesiogiai kreiptųsi dėl savo kažkokios problemos sprendimo ar poreikio patenkinimo, tai tada bus sunkiau. Reikės tuo atveju juos įtikinti užeiti arba atvesti lankytojus per paieškos sistemas – o tai jau daug sudėtingiau. Tad kartais geriau laiku sustoti ir atsisakyti idėjos, kurios poreikis žmonėms nėra vienareikšmiškai aiškus.

Pagalvok pats apie svetaines, kuriose dažniausiai lankaisi. Kodėl pasirenki būtent jas? Atsakyk sau į klausimą, kokias TAVO problemas sprendžia tie tinklalapiai.

Dar vienas penktadienis – ir dar vienas naudingų nuorodų penketukas, surinktas pagal jūsų peržiūrėtas populiariausias nuorodas už praėjusią savaitę. Pastarosios septynios dienos buvo visai derlingos šia prasme, tad jei ką praleidote – nepamirškite apsilankyti ir Archyve. O kol kas – žadėtas penketukas.

1. Talking to Facebook’s Social Graph with PHP [PHPbuilder.com]
“Facebook” platformoje numatyta gana nemažai funkcijų, kurias programuotojai gali naudoti savo projektuose. Štai jums pavyzdžiai, kaip galima su PHP kalba paimti duomenis iš Facebook duomenų bazės.

2. ReCaptcha in ASP.NET MVC3 [Beyondrelational.com]
“Google” suteikia programuotojams “ReCaptcha” sprendimą laisvam naudojimui. Kaip jį pritaikyti ASP.NET projekte – skaitykite šiame straipsnyje.

3. How To Set Up A Print Style Sheet [SmashingMagazine.com]
Puslapio versija spausdinimui dažnai būna galvos skausmas. Bet sprendimas yra visai paprastas – atskiras CSS failiukas spausdinimo versijai, būtent apie jį eina kalba šiame straipsnyje.

4. Instant CSS Documentation – InstaCSS [Webification.com]
Jeigu neturite po ranka CSS dokumentacijos, o jums staiga prireikia sužinoti kokios nors savybės reikšmę ir ypatybes, nebūtina ieškoti per Google. InstaCSS yra pilnavertė reikalinga dokumentacija su paieškos galimybe.

5. Web Development- Choose LAMP Development to Create Fascinating and Dynamic Websites [Quality-web-programming.com]
Vienas iš būdų paruošti web-serveriui yra populiarusis XAMPP. Bet Linux operacinei sistemai yra atskiras variantas LAMP – paskaitykite trumpai apie jo galimybes ir privalumus.

* * *

Štai toks penketukas. Primenu, kad naudingų nuorodų web-meistrams galite rasti praktiškai kasdien SkaitykIT.lt puslapio dešinėje pusėje, o jeigu nenorite kiekvieną dieną lankytis šiame tinklalapyje, galite nuorodas tiesiog užsiprenumeruoti el.paštu, kasdien apie 15 valandą gausite naudingų skaitinių porciją.

Gero artėjančio savaitgalio!

Ar girdėjote apie visai naują loteriją Lietuvoje? “10 milijonų” startavo lapkričio pradžioje ir pamažu didina savo žaidėjų būrį. Kadangi man kaip programuotojui įdomu yra modeliuoti panašius lošimus, tai pratęskime tradiciją: analizavau laimėjimo tikimybę tokių loterijų kaip Vikingų Loto, Teleloto, Keno loto, Tuzinas, Jėga, Auto loto, Loto 6, o dabar atėjo laikas ir naujajai “Nacionalinei loterijai”. Pažiūrėkime, ar dideli yra šansai laimėti.

Visų pirma, apie pačios loterijos esmę. Taisyklės yra ne pačios paprasčiausios, tad dėmesio.

Bilietas ir skaičiai

Loterijos biliete, kuris kainuoja 2.50 Lt, yra 30 skaičių iš intervalo nuo 1 iš 90, suskirstytų į tris dalis.

Skaičius galite nurodyti patys arba pasirinkti “BIM-BAM” variantą – kad skaičius sugeneruotų kompiuteris. Bet yra keletas įdomių taisyklių:

• Skaičiai biliete negali kartotis;
• A dalyje gali būti tik vienas skaičius iš to paties dešimtuko (31-40, 01-10 ir pan.)
• B dalyje negali būti daugiau nei du skaičiai iš to paties dešimtuko;
• B dalyje negali būti daugiau nei trys skaičiai iš to paties dešimtuko;

Štai toks bilietas. O lošimo metu – tiesiog išridenama 30 skaičių iš to paties intervalo nuo 1 iki 90. Panašų į seną gerą LOTO žaidimą, nežinau ar sutapimas – bet tiražų vedėjas per televiziją yra tas pats Gintaras Mikalauskas, kuris kažkada vedė “Sekmadienio loto”. Čia galite pažiūrėti pirmojo tiražo video:

Laimėjimai ir tiražų eiga

Kaip jau minėjau, išridenama 30 skaičių, ir laimėti galima tris skirtingus prizus: už A dalį, B dalį ir C dalį – tiesiog užbraukti visus toje dalyje esančius skaičius. Kalbant apie pinigus, tai laimėjimo sumos yra besikeičiančios, priklausomai nuo to, kiek žaidėjų pasidalina tos dalies piniginį fondą:

• už A dalį piniginis fondas yra 15% nuo parduotų bilietų sumos;
• už B dalį – 2.5% nuo parduotų bilietų sumos;
• už C dalį – 10 milijonų litų (arba atskiru atveju 1 milijonas, apie tai skaitykite žemiau).

Iš milijoninių laimėjimų yra du skirtingi variantai. Jeigu tiražo metu niekas nelaimėjo C dalies fondo, tada kitą tiražą yra ridenama vienu kamuoliuku daugiau – 31. Kitą savaitę – 32, tada 33, 34 ir taip toliau, kol kas nors visgi užbraukia visą C dalį. Ir jeigu tai padaro iki 33 kamuoliuko, tada laimi 10 milijonų, jeigu vėliau – 1 milijoną litų.

Skamba viliojančiai ir gana paprastai – atrodo, kas čia yra, užbraukti 15 skaičių, kai jų ridenama net 33. O dabar pažiūrėkime jau į tikimybę laimėti.

Oficiali statistika

Loterijos oficialiajame tinklalapyje yra pateiktos loterijos taisyklės PDF formatu, kuriose, be kitos informacijos, nurodytos ir tikimybės skaičiavimų formulės:

Tiems, kad nelabai draugauja su tikimybių teorijos formulėmis, organizatoriai pateikia paprastesnę informaciją – tikimybių lentelę:

Kas šioje lentelėje svarbiausia? Atkreipsiu dėmesį į tai, kad:

• Ridenant 30 kamuoliukų viename tiraže, A dalį laimi tik kas 308-tasis bilietas, o B dalį – tik kas 192308-tasis;
• Laimėti C dalies prizą tikimybės iš viso yra kosminės, net ir su 42 kamuoliukais;
• Pagal loterijos taisykles, žaidėjams išmokama ne mažiau nei 50 procentų bilietų pirkimo sumos – organizatoriai taip ir suskirstė: 15% už A, 2.5% už B ir likusieji 32.5% arba 1/10 mln. litų, kuriuos galbūt kada nors kas nors laimės.

Ką gi, viskas aišku? O dabar judėkime prie linksmiausios dalies – tiražų modeliavimo ir tikimybių išbandymo su atsitiktinai sugeneruotais skaičiais – tam parašiau skriptą su PHP programavimo kalba.

Praktika: bilietų ir tiražų generavimas

Mano parašytas skriptas susideda, iš esmės, iš keturių dalių:

• Bilietų su atsitiktiniais skaičiais generavimas;
• Tiražo kamuoliukų generavimas;
• Laimėtojų paieška tarp sugeneruotų bilietų;
• Laimėjimo sumų nustatymas pagal parduotų bilietų ir laimėtojų skaičių.

Sugeneruoti bilietą gavosi kiek keblu, nes reikėjo patikrinti, ar vienoje dalyje nėra daugiau nei kažkiek skaičių iš vieno dešimtuko – tai nurodo aukščiau jau paminėtos loterijos taisyklės. Bet gavosi viskas tvarkingai – 1000 bilietų buvo sugeneruojama per 0.2 sekundes. Tiražo kamuoliukų sugeneravimas yra labai paprastas procesas – tiesiog sugeneruoti 30 ar kiek daugiau skaičių (priklausomai nuo sąlygų) iš 90. O laimėtojų paieška susiveda į ciklišką kiekvieno bilieto ir kiekvienos jo dalies patikrinimą bei laimėtojų atrinkimą.

Paleidžiame skriptą pirmą kartą su 1000 bilietų ir 30 ridenamų kamuoliukų – vaizdas toks:

Hm, iš 1000 – tik 4 laimingi bilietai? Nesąmonė. Leidžiame dar kartą:

Dar mažiau? Trys laimėtojai? Hm, gal tada ir tiesa. Na, įsitikinkime trečią kartą:

Šioje vietoje kruopščiai pertikrinau savo parašytą skriptą ir sugeneruojamus skaičius – ar tikrai rezultatai teisingi. Klaidų neradau. O po to suvedžiau juos su jau minėtomis oficialiomis taisyklėmis – priminsiu:

Taip kad mano sugeneruoti skaičiai nemeluoja – juk iš tikro laimi kas 308-tasis bilietas, tai iš tūkstančio nupirktų laimingi būna tikrai vidutiniškai 3 bilietai, kai sugeneravo 4 – tai čia dar pasisekė

Kita vertus, laimėjimo suma visai nebloga – palyginus su Teleloto, kur už kampus gauni vos porą litų, čia galima laimėti visai neblogai – keliasdešimt ar net kelis šimtus litų vien už A dalies užbraukimą.

Kalbant apie B dalį, tai kiek bebandžiau su šitomis sąlygomis – nepavyko laimėti. Bet iš tikro čia labai maža bilietų skaičiaus imtis ir per griežtos sąlygos – 30 kamuoliukų. Ok, pabandykime pagerinti sąlygas – 10 000 bilietų ir 33 kamuoliukai. Rezultatas toks (taupant ekrano vietą, pačių laimėtojų derinių neberodysiu):

Vėlgi lyginame su teorine tikimybe – ji A dalyje yra 1 iš 185. Mano atveju yra 49 iš 10 000 arba apytiksliai 1 iš 204. Panašu į tiesą. Bet B ir C dalys kol kas tuščios.

Gerai, tada imame kosminį variantą ir paleidžiame lošimą su tais pačiais 10 000 bilietų tris kartus su 42 kamuoliukais.
Rezultatai:

Jau smagiau – yra ir B dalies laimėtojų, nors ir nedaug. Čia matome, kad keičiasi ir laimėjimo sumos – už A dalį laimėtojai pasidalina “vos” po 20 Lt, o už B dalį, kurią laimėti yra labai sudėtinga, atlygis – tik pora šimtų litų. Bet tikimybės iš praktinės pusės yra beveik tokios pačios, kokios ir nurodytos oficialiose taisyklėse.

Išvados?

Na ką gi, prigeneravome, pasinagrinėjome, patestavome. Ką galima iš viso to pasakyti?
Visų pirma, tikimybė laimėti yra maža. Ta prasme, LABAI maža. Jeigu TELELOTO laimi kas kelioliktas bilietas, tai čia kas šimtasis ar dar mažiau. Tačiau, kita vertus, “Nacionalinės loterijos” laimėjimo sumos yra kiek didesnės. Kalbant apie piniginę strategiją, loterijos organizatoriai nieko nepažeidžia – bendrai išdalinamos sumos yra tikrai mažos, bet jeigu kas nors “netyčia” laimėtų didžiausią prizą – jie patirtų nemažą nuostolį. Na, čia juk ir yra žaidimo smagumas – rizika tiek žaidėjams, tiek kažkiek ir organizatoriams.

Taigi, ar žaisti “Nacionalinę loteriją 10 milijonų”- spręsti jums. Maža laimėjimo tikimybė, bet prizai visai vilioja – organizatoriai žada ateityje dalinti ir daiktinius prizus. O be to, juk vis tiek vilioja milijonas ar netgi 10 milijonų litų – juk, kaip teigiama reklamoje, tokie pinigai iš tikro gali pakeisti jūsų gyvenimą.

Svarbi pastaba: Tokie praktiniai generavimai yra tik “pažaidimo” pobūdžio ir nepretenduoja į rimtus mokslinius tyrimus. Tikslas nebuvo toks, kad įtikinčiau skaitytojus pirkti arba nepirkti šios loterijos bilietus, greičiau norėjau sumodeliuoti ir ištestuoti patį mechanizmą, kad pats giliau suprasčiau, kaip vyksta loterija, tuo pačiu ir pasidalinau su jumis.