Silke

Panašu, kad parametrų bindinimas yra tik insert'uose, bet ne select'uose? :/
 
Templeitų sistema irgi lyg kažkokia yra, bet kai kur vis tiek spjaudomas HTML iš PHP.

Matyt kažkur dinamiškai išskiri atmintį, tik vietoj elementų kiekio paduodi -1. Tau tą -1 verčia į unsigned int ir gauna būtent 4,294,967,295.

Nusprendžiau su Uždarbio auditorija pasidalinti savo straipsniu (originalas čia) apie efektyvų bendravimą su klientais. Pats esu tinklalapių kūrėjas, bet manau, kad šios tiesos gali būti pritaikomos daugeliui freelance tipo profesijų.
 
* * * * *
 
Bendravimas yra neatsiejamas bet kokio projekto procesas – dažnai ne mažiau svarbus, negu realus techninis darbas. Tad šiandien nusprendžiau pasidalinti patarimais ta tema – bet ne šiaip “ką reikia daryti”, o ką pats asmeniškai darau, kad bendravimas tarp manęs (programuotojo) ir kliento vyktų kuo sklandžiau. Taigi, mano paties darbo principai:
 
1. Filtruoju klientus
 
Straipsnio pavadinime minimi “normalūs klientai” – ką tai reiškia? Dažnai manoma, kad reikia dėti visas pastangas, kad gautum užsakymą. Nė velnio – kai kurie užsakovai atneš tik nuostolių ir nervų karą. Kaip tokius atpažinti – atskiro straipsnio klausimas, bet bendrai tai tikri specialistai renkasi užsakovus net labiau, nei pastarieji juos.
 
Mano praktikoje, atkrenta apie 2/3 visų klientų, kurie kreipiasi. Priežastys įvairios, bet kokia pusė iš jų tiesiog “nepraeina atrankos”. Gali pasirodyti, kad aš pasikėlęs ir arogantiškas, bet iš tikro tai tie klientai tada nueina pas mažiau kvalifikuotus žmones, kurie pasiruošę dirbti jų sąlygomis. Win-win.
 
2. Bandau giliau suprasti klientą
 
Niekada nepuolu rašyti kodo ar diegti kokios TVS iškart: pirmas tikslas yra suprasti klientą. Iš verslo tikslų pusės – suprasti, ne kokios spalvos logotipo jis nori, o kokie jo tikslai ir lūkesčiai projektui, ką jis laikytų sėkme.
 
Būtent nuo to atsispiriu viso darbo eigoje, ir šiame etape aš pasiūlau klientui techninius sprendimų variantus, kurie padės pasiekti tikslų. Ir, kas galbūt dar svarbiau, siūlau atsisakyti kai kurių funkcijų, jei jos neveda prie tikslo.
 
3. Užduotis – tik raštu
 
Dažnas užsakovas patingi skirti laiko ir detaliai surašyti užduotį bei visas funkcijas. Maždaug, eigoje bus matyti. Kai kurie iš tokių jau iškart gauna atsisakymą dirbti, bet kai kuriuos kitus galima priversti padirbėti.
 
Mano dažna frazė: “Ar jūs turite detaliai aprašytą užduotį? Jums to reikės, nepriklausomai nuo to, ar samdysite mane, ar kitą programuotoją/įmonę”. Veikia 100%.
 
Taip pat bandau atpratinti klientus siųsti užduotį dalimis el. paštu. Viename laiške penki punktai, po to “o pala, dar prisiminiau” penki punktai, ir tada be galo. Turi būti centralizuota vieta, kur saugoma pilna užduotis – pats tam naudoju Asana, bet iš esmės priklauso nuo kliento, svarstau pagal žmogų, ar papildomas projektų valdymo įrankis neapsunkins proceso.
 
4. Užduotis ir planas – du skirtingi dalykai
 
Vienas iš pirmųjų dalykų, kurį reikia padaryti, gavus užduotį iš užsakovo – paversti ją realiu planu. Sakote – kur skirtumas? Mano praktikoje yra taip: užduotis nusako ką reikia padaryti, o planas – tai konkrečių darbų/etapų sąrašas su tarpiniais laiko terminais, kas ir kada bus užbaigta ir kas nuo ko priklauso.
 
Pradėti dirbti be chronologinio plano yra lengva, bet po to eigoje labai nepatogu sekti, kas padaryta, o taip pat galima ir pražiopsoti, kad kažkokią dalį reikėjo daryti anksčiau nei kitą dalį, nes tarp jų yra priklausomybė.
 
5. Aptariu sąlygas iš anksto, kad nekiltų klausimų
 
Galiu pasakyti drąsiai: didžiausia visų projektų visų problemų priežastis – nesusikalbėjimas tarp šalių. Projekto eigoje/viduryje/pabaigoje dėl to po to kyla nesklandumų, nepagrįstų kaltinimų ir t.t. Dėl to, kaip sakoma, dėl visko kiek įmanoma reikia susitarti “dar ant kranto”, prieš plaukiant kartu valtyje.
 
Ką būtinai-būtinai reikia aptarti (ir aprašyti):
- Darbo etapai ir jų atlikimo terminai
- Apmokėjimas: jo formos, jo dalys, avansas, delspinigiai ir kt.
- Visi projekte dalyvaujantys žmonės ir jų svarba: kas ką sprendžia
- Galimi papildomi darbai ir jų galima kaina
- Palaikymas po projekto pridavimo – ar už jį bus mokama ir kokiomis sąlygomis
- Jei pasitaikys klaidų ar smulkių patobulinimų – kiek laiko truks garantija
 
Turiu vieną strategiją, kad apsisaugočiau nuo mokėti nenorinčių užsakovų – laikau visus projektus savo serveryje, ir perkeliu juos pas užsakovą tik po pilno apmokėjimo (su sąlyga, kad pats projektas veikia ir jį belieka tik fiziškai perkelti).
 
6. Dažnai bendrauju su klientu
 
Šiuolaikinis madingas “agile” principas ir jo “sprintai” gali būti pritaikyti daug kur – kažkiek tos filosofijos taikau ir savo darbe. Klientams darbo rezultatus pateikiu porcijomis, kur bent po kažkiek naujovių atsiranda nuolat – taip vyksta aktyvus bendravimas, aptarimas, nuomonių apsikeitimai. Taip nesklandumai pastebimi anksčiau, o ne tada kai jau per vėlu/brangu perdarinėti visą darbą.
 
Tas dažnas bendravimas turi dar kelis šalutinius poveikius. Vienas iš tokių – “šiltesnių” santykių su klientu užmezgimas, kas reiškia kad teoriškai didesnė tikimybė, kad mane prisimins labiau, kai kas nors iš kliento draugų ieškos programuotojo. Nes su manimi N kartų susirašinėjo ir atsiminė.
 
Kitas dalykas – dažni pokalbiai verčia ir patį užsakovą pasitempti, nuolat stebėti projekto eigą, ruošti reikalingą informaciją iš anksto, analizuoti projekto būklę ir šiaip aktyviau dalyvauti.
 
7. Darbai laiku, jei įmanoma – anksčiau
 
Čia kaip ir savaime suprantamas dalykas, ar ne? Kad jeigu reikia darbą ar jo dalį padaryti iki dienos X, tai stengiamasi spėti iki dienos X. Bet aš stengiuos suspėti iki kokios (X-2) dienos – iš dalies, kad būtų laiko visokiems smulkiems pataisymams, o tuo pačiu kad maloniai nustebinčiau klientą – jie, patikėkite, to nepamiršta.
 
Kitas dalykas – iššūkis pačiam sau: ar įmanoma padaryti darbą greičiau negu yra sutarta, tai priduoda papildomos motyvacijos.
 
Tiesa, reikia pridurti, kad tai nereiškia, jog dirbu belekaip, kad tik suspėčiau greičiau. Kokybė turi išlikti. Kita vertus, čia kartais taikau “lean” principą – kuo anksčiau užsakovui parodyti bent kažkokį pusiau veikiantį variantą ir tada jau daryti tobulinimų iteracijas.
 
Dar vienas momentas – jeigu jau matau, kad niekaip nesigauna tilpti į laiko terminus, apie tai pats pranešu užsakovui, nedelsiu iki to momento kai manęs ieškos su klausimu “kur dingęs”. Geriau nuoširdžiai prisipažinti ir išlaikyti gerus santykius, tuo pačiu informuojant kitą pusę, kad ji savo ruožtu planuotų savo veiksmus atitinkamai.
 
8. Šalutinis tikslas – rekomendacija
 
Jei dirbu su žmogumi ar įmone pirmą kartą, tikslas nėra tik šis konkretus projektas ir sutarti pinigai. Aš žiūriu plačiau – jei kita pusė liks patenkinta, tada tikėtina, jog sugrįš dar ar bent jau rekomenduos mane, jei kažkam iš aplinkos prireiks programuotojo pagalbos.
 
Dėl to daryti “belekaip, kad tik veiktų, o užsakovas gal nepastebės” – nepateisinamas variantas. Nes vėliau gali išlysti visokių netikslumų ir nesklandumų, ir už kiekvieną iš jų gausite vis mažiau karmos taškų užsakovo akyse.
 
* * *
 
Čia yra tik dalis principų, kurių stengiuosi laikytis, kurdamas projektus kitiems. Bendrai visus juos galima apibūdinti taip – kad tam laikui tas projektas tampa ir jūsų kūdikiu, reikia žiūrėti taip tarsi kurtumėte jį sau ir bandyti parodyti rezultatą. Tada užsakovai tai vertins ir sugrįš.
 
O gal jūs turite kažkokių tips’ų, kaip efektyviau bendrauti ir dirbti su užsakovais?

Nereik būt radikalu. :D MySQLi yra okay, tiesiog PDO yra dar kiek naujesnis už mysqli ir ne specifinis vienai duomenų bazei.
 
Aišku, čia tai irgi nesąmonė daroma:
Tik tiek, kad dabar yra saugi reikšmė, paprasčiausias int'as iš duomenų bazės. Bet vis tiek skauda žiūrėti :D

math.h turi trigonometrines funkcijas. Reik tik atsimint, kad radianais ima, ne laispniais. Visa kita – matematika :)

http://nfader.su/ čia galima pasiskaičiuoti pagal IMEI Mastercode, kurį galėsi įvesti vietoj apsaugos kodo. 3310 tinka, dėl kitų nokių - žiūrėk FAQ.

Dėkui už atsakymą. Na kaip ir minėjai, ebook skaitymas yra kiek varginantis (nebent skaitai ber kokį kindle'ą), bet mano atvėju, labiau tiesiog smalsu ką siūlo lietuviai autoriai. Skaitau, žinoma, ir daug išmokstų būtent iš el. knygų, niekur net nežadu nusisukti nuo ebook'ų, nes visi tavo išvardinti privalumai tikrai puikiai suvokiami ir suprantami.
 
Kitas dalykas, tai ne tik dėl smalsumo. Gal lietuviai yra rašę kažką kokybiško iš tokių temų, kurios yra kiek stabilesnės ir taip greit nesikeičia (tiesiog ieškau geros knygos kurios nebūtų gaila nusipirkti, paremti lietuvį kūrėją) kaip skirtingų platformų suderinamumas, duombazės, operac sistemos, OOP basic'as ir t.t. Bet kadangi ir į tai jau atsakei ("Kokybiškų tikrai nėra"), tai case closed, I suppose :)
 
Dėl visų el. akademijų - ten susimoki už laiką, tarkim mėnesį ir tą mėnesį gali naudotis jų visais tutorialais? Ar perkiesi kažkokį kursą ir turi neribotą laiką?
Matai, mano atvejis toks, jog studijuoju VU MIF, ir šis semestras vienas sunkiausiu mano studijų programoje. Taigi jei tose el.mokyklose ribojamas laikas, dėja, bet pirkti jų produkciją man būtų beveik tolygų pinigų išmetimui.

Tai pas tave ImtiKiekis() tik grazina kieki, turi parasyti kita klases metoda, pvz. DetiKiekis(), kuris per parametrus paimtu c, ir ji priskirtu kiekiui.

package main import "fmt" func main() { fmt.Println("Hello!") }
Viena tema paskatino sukurti kitą, apie kitą su Google pagalba vystoma kalbą – Go.
 
Pastaruoju metu ypač ja susižavėjau. Tiesiog aukso viduriukas tarp C ir aukštesnio lygio kalbų. Sunku netgi racionaliai paaiškinti, bet tiesiog neįprastai malonu programuoti.
 
Kūrėjai teigė, kad iš esmės norėjo pervilioti programuotojus nuo tokių kalbų kaip C, C++, Java, tačiau efektas kiek kitas – Python, Ruby naudotojai mielai ima Go į rankas, kadangi skirtumas tarp jų ir Go nėra toks, kaip pereinant prie kitos kalbos, o vietų, kur Go stipresnė, tikrai yra.
 
Pagrindiniai Go aspektai, šaunantys į galvą:
 

Statinis tipizavimas (tačiau interfeisų dėka ir savotiškas Duck typing, labai praverčia)
Tam tikras OOP, bet ne toks, koks įprasta (interfaces, structs, composition vs. classes and inheritance)
Paprastas concurrency – vadinamosios "Goroutines", panašios į green threads, automatiškai paskirstomos per keletą OS lygio thread'ų ir procesų
"Don't communicate by sharing memory, share memory by communicating" – bendravimas tarp atskirų funkcijų ar goroutines įgyvendinamas kanalais.
Plati standartinė biblioteka: nuo JSON paketo, HTTP kliento/serverio iki šifravimo įrankių...
Kompiliavimasis į statinį binary – geri greičiai, portability
Protingas Go runtime su Garbage Collectoriumi, reflectionu ir t.t.
Aiškus tipų formatas: kai C reikia netgi tam tikros taisyklės tam, kad suprastum sudėtingesnius tipus (:lol:), GO viskas nurodoma paprastai ir aiškiai.

Tiesa, yra ir minusų, bet tai daugiausiai dėl kalbos jaunumo. Pavyzdžiui, neišsivysčiusi paketų ekosistema – nėra aiškių lyderių tam tikrose srityse (kad ir tokiose dažnose, kaip web frameworkai), kaip kitose kalbose. Taip pat literatūros, blogų, planetų, naudotojų bazės trūkumas – vėlgi, per laiką tai atsiras.
 
Kam galima pritaikyti? Ogi labai daug kam. Serveriai (ypač stipri Go vieta dėl gero concurrency palaikymo), sistemos įrankiai, desktop aplikacijos (kol kas čia Go tik pradeda, nes nėra gerų portų, tarkim, GUI toolkitams, SDL ir pan. – bet viskas juda į priekį, pagrindas yra.) ir t.t.
 
Google sako, kad Go naudojama viduje „for real things“ (vienoje kalboje sakė perrašę, pavyzdžiui, download serverį ir kitus panašius dalykus iš C++ į Go). Canonical (Ubuntu kūrėjų) įrankis Juju parašytas Go, DotCloud naudoja savo įrankiui Docker, ir t.t. Daugiau pavyzdžių galima rasti čia.
 
Susidomėjusiems:
 
Oficialus tinklalapis
Go turas –kalbos pradmenys jau mokantiems programuoti kitomis kalbomis, ypač iš C-like sintaksės. Tolesniam mokymuisi rekomenduočiau "How to write Go code", "Effective Go", "Go references" iš oficialaus tinklalapio.
Go Playground – išbandykite tiesiog naršyklėje
Go resursai – programos, parašytos Go, bibliotekos, tinklalapiai, ir t.t.
 
––
 
Būtų įdomu išgirsti jūsų nuomones. Sudomino? Galbūt jau bandėte?

#include įtraukia tik apibrėžimus klasės ar kitų struktūrų, funkcijų, bet tam, kad jos būtų įkompiliuotos į programą, reikia kompiliuoti ir klase.cpp. Pvz.:

gcc klase.cpp main.cpp
 
Kitaip kompiliatorius skundžiasi dėl to, kad apibrėžimas klasės yra, bet jos pačios nėra, o ją bandai naudoti.

Ne, ant popieriaus lapo programos nerašom. Nesąmonė iš esmės su lietuvišku programavimo kursu taip. Rašydavom nebent 10 klasėj. Ir, kaip sakei, programos dalis (ciklus pvz.).
 
Void tipas nuskaitymui nėra taip jau blogai. Nors daugeliu atvejų ir būtų galima argumentą grąžinti ne per reference, o per normalų return'ą. Na, bet mokykliniam kurse daug kvailų nesąmonių – susitaikyk :)

Na ir kas? Jei savo appsą rašysi 10000 eilučių, tai 5 eilutės pamodifikuoti frameworko veikimą yra labai daug? :D Kodavimo stilius išvis beveik ne prie ko. Lipdyti savo dauguma atvejų nėra reikalo ir tik padidina pavojų kiekį :)
 
Oi, ir turbūt kiek apie atskirus dalykus šnekam... Iš apklausos akivaizdu, kad kalbama apie kliento pusės JS MVC, o tu papasakojai apie savo serverio pusę :) Tik nežinau, ką tada reiškia „M apima ir backend duomenų bazę, todėl mano darbai yra tokios struktūros“ ir kaip modelis apskritai gali neapimt duomenų bazės...
 
Galiausiai, net ir kalbant apie serverio pusę, frameworkų yra visokių: micro, full-stack, tradicinių, įdomesnių, kaip Meteor (kad jau kalbam apie JS)... Nereikia nurašyti visko, kas po viena etikete.
 
---
 
Aš sakyčiau, kad kalbant apie JS MVC labai verta atskirti du atvejus: kai dauguma renderinimo yra serverio pusėje, ir kai kliento.
 
Pirmuoju atveju JS MVC, manau, nebūtinas – tada JS atliksi tik kažkokias minimalias manipuliacijas, ir tiek. Tuo tarpu kai dauguma renderinimo yra kliento pusėje, tada jau verta naudoti JS MVC, o serveriui palikti tik tam tikro API ir HTML rėmų išspjovimo vaidmenį :)
 
Bet nereiktų daryti ir to, ir to – kam taip kankintis? Tiesiog pasverti, kas geriausia tavo aplikacijai. Pavyzdžiui forumas ar blogas nėra tokia jau dinaminė ir greita aplikacija, kuriai reiktų kliento pusėje renderinti ar ką nors gyvai daryti. O kita vertus, tarkim, Gmail, pagrinde dirba kliento pusėje, ir tai visiškai normalu: jokio SEO ar kitokio priėjimo mašinoms prie asmeninio pašto juk nereikia, aplikacija ypač dinamiška, kodėl gi ne :)
 
---
 
Nusimetant žinovo kaukę – dar nei karto neteko realiai bandyti JS MVC, kadangi tiesiog nedarau tokio tipo projektų. Bet jei kada prireiktų, gali būti, kad pirmiausiai žiūrėčiau į Angular.js – tiesiog labai daug hype pastaruoju metu įvairiose bendruomenėse būtent dėl jo. :)

Sveikas, pasidomek gearman:)

Tai čia išvis kodas ne visai teisingas, nes prie recursion() kvietimų nėra return. T.y., jei n == 0, grąžins 1, kitokiu atveju negrąžins nieko apskritai...

Tai čia išvis kodas ne visai teisingas, nes prie recursion() kvietimų nėra return. T.y., jei n == 0, grąžins 1, kitokiu atveju negrąžins nieko apskritai...

Melagingas žinias reklamoms socialiniame tinkle „Facebook“ naudojantis interneto sukčius gali sėsti už grotų. Tokia bausmė gresia už tai, kad apgaulėms naudotame tinklalapyje buvo talpinama pornografinė nuotrauka, kurioje vaizduojamas vaikas.
 
Policija patvirtino atliekanti tyrimą dėl tinklalapio Demesio.net. Jame buvo talpinama nuogos mažametės nuotrauka.
 
Į šią interneto svetainę taip pat buvo nukreipiami „Facebook“ reklamomis, pranešančiomis apie tariamus skandalingus įvykius, susidomėję internautai. Melagingose reklamose, prisidengiant Lrytas.lt vardu, skelbta apie tariamas Natalijos Bunkės ir Ramūno Rudoko mirtis, mažametės lietuvės išnaudojimą.
 
Kadangi puslapį buvo užregistravęs lietuvis, o svetainės informacija saugota lietuvių kompanijos serveryje, atsakomybė už tai būtų taikoma pagal Lietuvos įstatymus. Atsakomybė grėstų asmeniui, kuris patalpino neteisėtą turinį.
 
Pagal Lietuvos Baudžiamojo kodekso 162 straipsnį, už vaiko išnaudojimą pornografijai arba pelnymąsi iš tokios veiklos gresia bauda arba areštas arba laisvės atėmimas iki penkerių metų. O 309 straipsnyje nurodoma, kad už pornografinio turinio, kuriame vaizduojamas vaikas, laikymą gresia bauda arba kalėjimas iki dvejų metų.
 
 
visas tekstas http://it.lrytas.lt/ismanyk/melagingu-facebook-reklamu-skelbejui-gresia-kalejimas.htm

Nu jau taip :D
 
Visų pirma, reikia suvokti, kas už ką atsakingas. HTML, CSS yra išdėstymo, atvaizdavimo dalykai. Čia rinktis nelabai turi iš ko, vis tiek naršyklė norės būtent tų dviejų. Jie ir yra tai, ką vadini dizainų kodavimu.
 
Dar yra Javascript (naršyklinis, nors gali būti ir serveryje). Tai – visokia dinamika, reagavimas naršyklėje į vartotojo veiksmus, AJAX, ir pan.
 
O dar dažniausiai būna serverio pusės kalba: PHP, Python, Ruby, Java, Scala, Go, tas pats Javascript... Kas tik nori. Čia vyksta visas duomenų saugojimas, mąstymas, ir t.t. T.y. turėk tu HTML, CSS kiek nori, tokio forumo kaip šitas be kažkokio backendo nesukursi :)

Nu jau taip :D
 
Visų pirma, reikia suvokti, kas už ką atsakingas. HTML, CSS yra išdėstymo, atvaizdavimo dalykai. Čia rinktis nelabai turi iš ko, vis tiek naršyklė norės būtent tų dviejų. Jie ir yra tai, ką vadini dizainų kodavimu.
 
Dar yra Javascript (naršyklinis, nors gali būti ir serveryje). Tai – visokia dinamika, reagavimas naršyklėje į vartotojo veiksmus, AJAX, ir pan.
 
O dar dažniausiai būna serverio pusės kalba: PHP, Python, Ruby, Java, Scala, Go, tas pats Javascript... Kas tik nori. Čia vyksta visas duomenų saugojimas, mąstymas, ir t.t. T.y. turėk tu HTML, CSS kiek nori, tokio forumo kaip šitas be kažkokio backendo nesukursi :)

O skauda, kad turi daug galimybių? Neįjungiami tie sunkieji agregatai defaultu. Nenori – nereikia. Galiausiai yra mažesnių frameworkų...
 
Ai, tai tipo parašyt tą patį, ką kiti jau parašė, tik su tomis pačiomis klaidomis, kurias kitas darė prieš x metų ir testuotą vieno žmogaus, o ne tūkstančių :D
 
Frameworkas: greitas startas, tam tikros struktūros normos, daug paruoštų dalykų (kam šimtajam projektui vėl rašyti auth pačiam?), ir t.t. Tuo labiau:
Krūviai nedideli, tai tikrai ne frameworkas bus bottleneck'as. :)

Kuria naują frameworką ne tam, kad ištaisytų akivaizdžias klaidas, o dėl įvairių kitų priežasčių. Skiriasi filosofija, modelis (micro vs. full-stack, old-school-synchronous vs. websocket-async-hot-sh1t...), galbūt esamas frameworkas nebevystomas (CodeIgniter?), nepalankiai pasikeitė licenzija ar savininkas (ne frameworkai, bet MySQL vs. MariaDB) ir t.t.
 
Neiškreipinėk žodžių. :) Tame ir skirtumas, kad populiaraus frameworko klaidos pataisomos ir, svarbiausia, pastebimos greitai (vėlgi, dėl tos milžiniškos masės naudotojų ir vystytojų). Taviškio – nelabai :)

Kuria naują frameworką ne tam, kad ištaisytų akivaizdžias klaidas, o dėl įvairių kitų priežasčių. Skiriasi filosofija, modelis (micro vs. full-stack, old-school-synchronous vs. websocket-async-hot-sh1t...), galbūt esamas frameworkas nebevystomas (CodeIgniter?), nepalankiai pasikeitė licenzija ar savininkas (ne frameworkai, bet MySQL vs. MariaDB) ir t.t.
 
Neiškreipinėk žodžių. :) Tame ir skirtumas, kad populiaraus frameworko klaidos pataisomos ir, svarbiausia, pastebimos greitai (vėlgi, dėl tos milžiniškos masės naudotojų ir vystytojų). Taviškio – nelabai :)

Tu moduliu ant php yra N, jei nesigaudai situacijoje, tai geriau is vis nekomentuok :) rodai cia pear, kuris yra jau atgyvenes savo ir visi sekmingai siadnien naudoja composer packages. O del viso kito pilnai pritariu ModesetasV ir Silke (y)
EDIT: o ka tau teko matyt, tai cia is vis ne rodiklis :)

O skauda, kad turi daug galimybių? Neįjungiami tie sunkieji agregatai defaultu. Nenori – nereikia. Galiausiai yra mažesnių frameworkų...
 
Ai, tai tipo parašyt tą patį, ką kiti jau parašė, tik su tomis pačiomis klaidomis, kurias kitas darė prieš x metų ir testuotą vieno žmogaus, o ne tūkstančių :D
 
Frameworkas: greitas startas, tam tikros struktūros normos, daug paruoštų dalykų (kam šimtajam projektui vėl rašyti auth pačiam?), ir t.t. Tuo labiau:
Krūviai nedideli, tai tikrai ne frameworkas bus bottleneck'as. :)

O skauda, kad turi daug galimybių? Neįjungiami tie sunkieji agregatai defaultu. Nenori – nereikia. Galiausiai yra mažesnių frameworkų...
 
Ai, tai tipo parašyt tą patį, ką kiti jau parašė, tik su tomis pačiomis klaidomis, kurias kitas darė prieš x metų ir testuotą vieno žmogaus, o ne tūkstančių :D
 
Frameworkas: greitas startas, tam tikros struktūros normos, daug paruoštų dalykų (kam šimtajam projektui vėl rašyti auth pačiam?), ir t.t. Tuo labiau:
Krūviai nedideli, tai tikrai ne frameworkas bus bottleneck'as. :)

Nu pamoka tai čia nelabai :) Kodo gabalai ir „nesidomėjau kaip veikia“. Bet pats uploadify toks atrodo OK, jei reikia palaikyti senoviškas naršykles.
 
Pats HTML5 turi XMLHttpRequest 2 ir FormData, kurie pagaliau leidžia per AJAX lengvai išsiųsti formą netgi su multipart failais. Na, aišku, IE palaikymas vargingas :)
 
https://developer.mozilla.org/en-US/docs/Web/API/FormData
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest