Silke

(69-asis mano „rant“ iš serijos „programavimo mokymas, kokį turime, čiulpia“)
 
Pradėti programuoti webui (tokį, kokį turime šiuo metu naršyklėje) ir taip yra pakankamai sudėtinga: jei nori kažką matyti ekrane, turi mokėti HTML, jei nori, kad tai būtų gražesnis vaizdas – CSS, jei nenori būti žmogus, nežinantis, ką daro, reiktų bent kiek suprasti ir apie tinklo susijungimus bei HTTP.
 
Tad kai naujokui, besimokančiam PHP (o jei kitą programavimo kalbą – tik dar šauniau), dar tik rašančiam pirmuosius veikiančius kodo gabaliukus, tėškiamas MySQL, norisi verkti.
 
Reliacinės duomenų bazės (ar apskritai DB) – sudėtingi, galingi žvėrys. Jie nėra skirti vien daryti jūsų „login sistemai“. Norite perprasti MySQL? Pradžiai – didelė dokumentacija. Taip pat dar viena kita knyga apie RDBMS apskritai, MySQL ir praktinius jos sprendimus.
 
Sakote, išmokysime padaryti paprastą SELECT ir darbas baigtas? Nė velnio. Mišrainės/nuotrupų mokymasis nėra naudingas – tada bus antras projektas, tada trečias, o žinios liks maždaug tokioje pačioje vietoje, nes MySQL'u nebuvo pasidomėta nei kiek už to, kas buvo „tam kietam kurse, kur išmokė pasidaryt prisijungimą“.
 
Jums reikia laikyti tik vartotojo prisijungimo vardą ir slaptažodį? Naudokite Redis! Sąrašai, key -> value (vadinamieji hashmap/associative array), aibės – tai net daugiau, nei jums reikia. Be jokio My-, Your-, Their- SQL pasidarysite registraciją, prisijungimą, patvirtinimą emailu, slaptažodžio priminimą, ir ką tik norite.
 
Ir žinote ką? Jis turės pakankamai problemų ir be SQL bėdų. Slaptažodžius saugosite nehešuotus, ar hešuotus netinkamai, jūsų registracijos forma ribos jų ilgį, nepriims tam tikrų el. pašto adresų, bus lengvai atakuojama botų... Bet tai yra normalu kiekvienam pradedančiajam. Jūs mokotės programuoti. Kartu su programavimu iškart nesimokykite panaudoti vieną, niekuo neišsiskiriantį iš kitų išorinį servisą.
 
Išmokite programavimo ir pažabosite (iš kliento pusės) MySQL, Postgres, MongoBD, CouchDB, ar bet kokią kitą sudėtingą DB. Išmoksite tai sistemingai, jau žinodami, kaip veikia programos (netgi ir nenaudojančios DB), tai bus atskira tema ir žinosite, kad DB nėra kažkokia PHP dalis.
 
TL;DR: „susikurkite kietą login sistemėlę su php ir mysql“? NE.

(69-asis mano „rant“ iš serijos „programavimo mokymas, kokį turime, čiulpia“)
 
Pradėti programuoti webui (tokį, kokį turime šiuo metu naršyklėje) ir taip yra pakankamai sudėtinga: jei nori kažką matyti ekrane, turi mokėti HTML, jei nori, kad tai būtų gražesnis vaizdas – CSS, jei nenori būti žmogus, nežinantis, ką daro, reiktų bent kiek suprasti ir apie tinklo susijungimus bei HTTP.
 
Tad kai naujokui, besimokančiam PHP (o jei kitą programavimo kalbą – tik dar šauniau), dar tik rašančiam pirmuosius veikiančius kodo gabaliukus, tėškiamas MySQL, norisi verkti.
 
Reliacinės duomenų bazės (ar apskritai DB) – sudėtingi, galingi žvėrys. Jie nėra skirti vien daryti jūsų „login sistemai“. Norite perprasti MySQL? Pradžiai – didelė dokumentacija. Taip pat dar viena kita knyga apie RDBMS apskritai, MySQL ir praktinius jos sprendimus.
 
Sakote, išmokysime padaryti paprastą SELECT ir darbas baigtas? Nė velnio. Mišrainės/nuotrupų mokymasis nėra naudingas – tada bus antras projektas, tada trečias, o žinios liks maždaug tokioje pačioje vietoje, nes MySQL'u nebuvo pasidomėta nei kiek už to, kas buvo „tam kietam kurse, kur išmokė pasidaryt prisijungimą“.
 
Jums reikia laikyti tik vartotojo prisijungimo vardą ir slaptažodį? Naudokite Redis! Sąrašai, key -> value (vadinamieji hashmap/associative array), aibės – tai net daugiau, nei jums reikia. Be jokio My-, Your-, Their- SQL pasidarysite registraciją, prisijungimą, patvirtinimą emailu, slaptažodžio priminimą, ir ką tik norite.
 
Ir žinote ką? Jis turės pakankamai problemų ir be SQL bėdų. Slaptažodžius saugosite nehešuotus, ar hešuotus netinkamai, jūsų registracijos forma ribos jų ilgį, nepriims tam tikrų el. pašto adresų, bus lengvai atakuojama botų... Bet tai yra normalu kiekvienam pradedančiajam. Jūs mokotės programuoti. Kartu su programavimu iškart nesimokykite panaudoti vieną, niekuo neišsiskiriantį iš kitų išorinį servisą.
 
Išmokite programavimo ir pažabosite (iš kliento pusės) MySQL, Postgres, MongoBD, CouchDB, ar bet kokią kitą sudėtingą DB. Išmoksite tai sistemingai, jau žinodami, kaip veikia programos (netgi ir nenaudojančios DB), tai bus atskira tema ir žinosite, kad DB nėra kažkokia PHP dalis.
 
TL;DR: „susikurkite kietą login sistemėlę su php ir mysql“? NE.

Jei ne mokymuisi, o realiam dalykui, tai galbūt išeitų ką nors pritaikyti iš datetime modulio. Pvz., timedelta – tiesa, ten kažkodėl eina sekundės, o po to jau dienos.
 
Bet kokiu atveju:

# valandos h = sec // 3600 # kiek lieka sekundžių sec = sec % 3600 # minutės min = sec // 60 # kiek lieka sekundžių sec = sec % 60

Manau, kad pažiūrėti keletą dešimčių video būtų naudinga, kad bent truputį pačiupinėtum ir suprastum GUI komponentus ir pan. Bet visų 200 video žiūrėti tikrai nesiūlau, nes tam sugaiši labai daug laiko, o supratimas vis tiek bus gana paviršutiniškas. Rekomenduojama literatūra priklauso nuo to, kiek esi susidūręs su programavimu ir JAVA kalba iki šiol, bet vis tiek pritariu wi_lius dėl Android Developers puslapio.
 
Jeigu tau patinka žiūrėt video gali ,,užmesti akį" į neblogą ,,intermediate" tutorial iš mybringback.
 
Bet jeigu esi pasiryžęs ir paskaityti, kas yra tikrai reikalinga, siūlyčiau atkreipti dėmesį į ,,Head First
Android Development" ir Carlos Sessa ,,50 Android Hacks".
O kiti skaitymai priklausys nuo to, ką planuoji daryti. Bet kuriuo atveju linkiu tau sėkmės!

Pagrindinis resursas — Android Developers puslapis. Yra ir įvairių pamokų, ir API aprašymų, ir geriausios praktikos patarimai.
 
Šiaip sakyčiau, pradėk nuo Getting Started. Išmok apie Activity, po to perprask kaip Android'as disponuoja įvairiais programėlės resursais (paveikslėliai, layout, strings, t.t.) bei kaip juos atsirenka esant skirtingiems ekranų dydžiams bei skirtingoms telefonų konfigūracijoms, tada išsiaiškink Fragment veikimą. Toliau jau turbūt seks specifiniai dalykai, daugiau susiję su taviške programėle.
 
Ir žinoma, jei ko nors nerandi Android Developers puslapyje, bandai tai rasti Stackoverflow arba šiaip Google.

Tiesiog patarimas: jeigu nori išmokti ne vien kaip padaryti vieną arba kitą atskirą dalyką, bet ir suprasti kaip bei kodėl tai veikia, siūlyčiau geriau perskaityti normalią Android developinimo knygą negu žiūrėti trumpučius thenewboston video.

Tai kad Notepad++ – vienas prastesnių. Geriau Sublime :)

Sumečiau šį tą prieš naktį, per daug nešlifuodamas. Gavos straipsniukas, kiek užnešantis į naujienų portalų pop-science, bet tikiuosi, kad bent šiek tiek pagrindžia tai, jog jei išsipildytų „oi kaip norėčiau, kad juos keliom savaitėm atjungtų“, daugumai žmonių būtų oi kaip negerai... :)
 
http://justinas.me/it/be-google/

Excel?
 
O šiaip, manyčiau, įgyvendinimas daug sunkesnis šios idėjos :) Kaip sakei pats, kol kas neturi žinių, o kol išmoksi programuoti GUI, specifinėms OS, elgtis su grafika, taip pat reikės nusimanyti matematikoje... Ir t.t. :) Drįsičiau netgi sakyti, kad vienam sukurti ir vystyti tokią programą bus pakankamai sunku.
 
Galima ir lengviau, jei tik atiduoda normalų RSS/Atom – viską susigaudyti iš ten. Bent jau standartizuotas interfeisas. Kitu atveju tikrai reiks specifinio kodo. Bet kokiu atveju, čia tikrai nėra nieko ypač sunkaus. Aišku, programuotojui nieko sunkaus :)
 
Tiesa... http://visosnaujienos.lt/

Viskas ten cool, turi savų gerų funkcijų, bet konteksto supratimas ir visa kita (ką Google iš dalies pasieka „sekimu“) – visai ne tam lygy. Dabar nepamenu, ko tiksliai ieškojau, kai padariau tokią išvadą, bet faktas, kad Google supranta mane iš 1-2 žodžių. Pavyzdys iš labai smagios Reddit temos. :)

Viskas ten cool, turi savų gerų funkcijų, bet konteksto supratimas ir visa kita (ką Google iš dalies pasieka „sekimu“) – visai ne tam lygy. Dabar nepamenu, ko tiksliai ieškojau, kai padariau tokią išvadą, bet faktas, kad Google supranta mane iš 1-2 žodžių. Pavyzdys iš labai smagios Reddit temos. :)

Sveiki,
 
reiktų šiek tiek pagalbos iš pažengusių programuotojų su django. Googlindamas pastebėjau, kad dauguma tutorialų templatus saugo appso folderyje, o ne pagrindiniame. Kodėl taip yra? O gal vienam tinklapiui užtenka vieno appso?
 
Tarkim turiu tinklapį, kuris turi naujienas ar kažką panašaus į blogą ir dar kažkokią atskirą skiltį, kurioje vartotojui teiksiu tam tikras paslaugas. Taigi, mano nuomone reiktų susikurti du appsus:
 
•Naujienos - čia sukiščiau visus naujienų modelius (article, tags, meta info). Būtų atvaizduojamas example.com/ arba example.com/blog
 
•Paslauga - čia sukiščiau visus modelius skirtus paslaugos appsui (pvz: serveris, nustatymai, koks nors paslaugos galiojimo laikas ir visi kiti šū.dai). Būtų atvaizduojama example.com/paslauga
 
Taigi, grįžtant į pradžią, mano projekte abu appsai turėtų generuoti vienodą tinklapio headerį ir footerį, o keistųsi tik vidurinė dalis (contentas). Tai kur reiktų saugoti templato folderį ir apskritai kaip jį struktūrizuoti, kad galėčiau per vieną failą redaguoti viso tinklapio headerį bei footerį?
 
Dėkui

Nes kiekvienas apps'as gali turėti sau skirtų templeitų? Tuo labiau, jei kalbam apie platinamus apps'us, tai kitaip ir nepadarysi – į PyPI nekiši viso projekto, o tik appsą.
 
Iš esmės turėtum daryti taip:
 
templates/base.html

<header> {% block header %} default header {% endblock %} </header> {% block main %} default turinys {% endblock main %} <footer> ...
 
blog/templates/blog/index.html

{% extends "base.html" %} {% block main %} Blogo turinys {% endblock %} {% block header %} blogo headeris woop woop {% endblock %}
 
Esmę, manau, pagauni.
 
blog/templates/blog/index.html yra dėl to, kad visi templeitai logiškai django sumetami į vieną vietą pagal vardus, t.y. jei turėtum tiesiog blog/templates/index.html, tai jis galėtų susiclash'inti su kitu, tarkim paslauga/templates/index.html. Todėl beveik visada daromas dar vienas lygis su app vardu :)
 
Jei dar kokių neaiškumų bus, tai kiek vėliau galėsiu paaiškinti plačiau.

Šaunu :)
 
Oh...

Labai teisingi pastebėjimai, tik nepaminėtas, sakyčiau, pats praktiškiausias variantas - kešuoti tik tam tikrus dalykus, kurie užima daug laiko, tam tikram laiko tarpui, negalvojant apie invalidaciją.
 
O šiaip tai jo, teisingas klausimas būtų ne kaip kešuoti, bet kaip spręsti performanso problemas, nes konkrečioje situacijoje galbūt būtų geriau keisti duombazės struktūrą, sumažinti užklausų skaičių, optimizuoti pačias užklausas, o ne dėti kešavimą.

Šaunu :)
 
Oh...

Šaunu :)
 
Oh...

Pabandyk naudoti exceptionus? Tada jei jų negaudysi, tai turėtų jau niekaip tyliai klaida nepraslįsti.
 

$dbh->setAttribute(PDO:ATTR_ERRMODE, PDO:ERRMODE_EXCEPTION);

Šaunu :)
 
Oh...

Šaunu :)
 
Oh...

Šaunu :)
 
Oh...

Šaunu :)
 
Oh...

Šaunu :)
 
Oh...

Šaunu :)
 
Oh...

Šaunu :)
 
Oh...