luknei

Aš suprantu, kad gal dalis tavo draugų, o gal net ir tu esi nusivylęs, kai po studijų su beverčiu popierium patekai į realybę, kur niekam nėra reikalingos nei tavo žinios, nei diplomas. Aš pats sutinku, kad popierius, gautas lietuvos univeruose yra š*do vertas, tikėtina, kad maniškis bus toks pats. Kaip ir sakei, ekonomistai šiais laikais plauna tūlikus. Bet esmė ta, kad man visiškai nerūpi kitų likimai - aš jau dirbu versle ir jau neplaunu tūlikų. O kad bazinės žinios, įgytos tokiuose dalykuose kaip finansų apskaita, finansų valdymas, ekonometrija yra bevertės versle teigti gali tik labai neišsilavinęs, siauro mastymo žmogus ;)

Rudens ir pavasario semestrai būna :)

1. Labai sunku skaityt kodą, kai kintamųjų pavadinimai tokie netvarkingi. Vienur lietuviškai, kitur angliškai. Kas per kintamojo pavadinimas $masyvas? :) Tai pats pirmas dalykas, kuris krenta į akį. Tai yra labai svarbu kodo tvarkingumo atžvilgiu. Kintamųjų pavadinimai turi būti informatyvūs. Geriau naudok angliškus pavadinimus (ne tik kintamiesiems, bet ir modeliams, kontroleriams - visur).
 
2. Modelių pavadinimai turi būti vienaskaitoje, tada nereikės visur setinti properčio $table (ir vėl gi - angliški).
 
3. https://github.com/uikolas/Simple-Laravel-eshop/blob/master/app/controllers/KrepselisController.php#L36 . Gali naudoti metodą fill, kuris iškarto užsetins reikiamus atributus, o ne po vieną setinti ir pastoviai kviesti Input::get(). Tam, kad galėtum atlikti mass assignment, modelyje turi nurodyti, kuriuos laukus leidi settinti tokiu budu (pasinaudojant properčių $fillable).
 
Ir šiaip daug kitų dalykų yra. Gal pažiūrėčiau įdėmiau, bet neužtenka kantrybės skaityti pusiau lietuvišką kodą :D

Kas cia per požiūris 1000Lt po univero? 1000Lt be univero maximos kasoje.

Iš kur tu toks išlindai? :D
 
Man tik įdomu ar pats esi dirbęs su tais pačiais web'ais ir ką tu tokio jau sukūrei, kad čia gali skiesti :) Pažiūrėkim rimtai į tavo argumentus, kurie yra visiškas nulis:
Kodėl visi renkasi php?
Didžiausia bendruomenė ir daugiausiai serverių stovi su php. Taigi, kodėl verslas turėtų imtis ruby ar dar ką nors tam, kad vargtų ieškant serverio, už jį mokėtų šimtus, kai jiems reikia vizitinės principo internete? Taip, tai yra tavo "šūdwebis", bet iš kitos pusės - 90% žmonių to užtenka. Atėjau, pamačiau ir sužinojau. Elementarus principas, o tokiam principui visiškai dzin kokia kalba parašytas web'as, nes svarbu jo išlaikymo kaina.
 
Kitas dalykas, tai php tikrai nėra skirtas sudėtingiems skaičiavimams ir t.t., tačiau vėlgi - kas tau draudžia php prasiplėsti su c++? Jeigu rankos kreivos tai taip - nelįsk geriau, bet jeigu turi geras rankas - išspausi daug daugiau.
 
Asmeniškai mes naudojame dabar tokį variantą - php web'o atvaizdavimui ir socket veikimui, o linux programas susisiekimui su database ir dideliai daliai logikos įgyvendinti. Taigi vargo nematome, resursų nenaudojame, o rasti kas tokį projektą galės toliau prižiūrėti yra lengviau negu lengva :) ( ps. čia specifinis atvėjis, nes paprastam web'e to nebus ) :)

Sveiki,
Nesenai publikavau savo straisnį web optimizacijos tema, anglų kalba.
Manau, jog nuodėmė būtų nepasidalinti juo kartu su Jumis, juo labiau, jog turiu jo draft'ą lt kalba :)
Tikrojo straipsnio adresas: http://bit.ly/1mLtvj9
 
Visais laikais žmones žavėjo greitis. Greičiausia mašina, greičiausias bėgikas, greičiausias žveris, greičiausias procesorius... Greitis, tai magija, kuri iš pradžių atrodo vulgari ir paprasta, tačiau, kad taptum tikrai greitu, visose srityse turi įdėti nemažai darbo. Kaip ir vaikinas, laisvalaikiu paspardantis kamuolį su draugais futbolo stadione netaps profesionaliu futbolininku, uždirbančiu milijonus, taip ir Jūsų programinė įranga netaps ypatingai greita be tam tikrų optimizacijos procesų.
Jau tampa aišku, jog web technologijų srityje responsive dizainas yra „must have“. Ir ne be reikalo, nes mobiliųjų įrenginių skaičius, kurie naudojasi mobiliu internetu, pasaulyje jau pasiekė penktadalį visos populiacijos, tad web‘ui tenka taikytis prie įvairių įrenginių (šaltinis: http://www.dekh.com/blog/post/the-mobile-web-will-it-replace-desktop-use). Prisitaikymas kainuoja. Daugiausia kenčia našumas, kurį galėčiau išskirti į tris dalis: „loado“ (krovos), grafinį (rendering) ir nematomoji dalis – programavimo našumas (executing). Apie našumo svarbą verslui plačiau galite pasiskaityti čia: http://www.tagman.com/mdp-blog/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/ . Rezultatai gana įdomūs – 1 papildoma sekundė kainuos Jums 7% konversijų.
Šiame straipsnyje pabandysiu aptarti pagrindines klaidas ir duoti gerų patarimų, kaip svetainę padaryti greitesnę, tačiau prieš pradedant, norėčiau supažindinti su nerašytomis taisyklėmis, kada web aplikacija gali būti laikoma „greita“:
• Time To First Byte: 200ms - 350ms
• DOM Content Loaded: 1000ms - 2000ms
• JS Load Event Fired: 900ms - 2200ms
• Total Download Size: 1MB - 2MB
• DNS Lookup: 10ms - 20ms
• HTTP Requests per page: 50 - 75
Tad, pradedam:
 
Sulieknėk greitai arba kai reklama tampa realybe
Tikriausia esate matę tas reklamas, kuriose moteris numeta 15 kilogramų per tris dienas naudodama stebuklingus patarimus? Ši reklama gali būti teisinga web optimizacijos atveju. Jūs galite turėti didelę aplikaciją, su daug įvairiausio kodo, tačiau dažniausia turėsite bėdų su paveiksliukais, kurie kels krovos laiką, o jeigu naudosite dar ir transparent png – tai bus didelis galvos skausmas... iki tol, kol naudosite reikiamus įrankius ir mokėsite juos organizuoti.
• Visų pirma rekomenduočiau tinkamai paruošti paveiksliukus. Dažniausia girdžiu, jog png optimizuoti beprasmiška, nes labai kenčia kokybė, tačiau geresnio įrankio, nei daug kam nežinomas, kuklus ir nemokamas „Color quantizer“ (http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Color-quantizer.shtml) – neteko sutikti, o ir problemas jis sprendžia puikiai. Yra tekę matyti pavyzdžių, kai transparent png neoptimizavusios svetainės, turėjo vieną, riebų paveikslėlį, kurio dydis viršijo pusę megabaito. Su šiuo įrankiu tokį paveikslėlį nesunkiai sumažinsite bent kelis kartus, o kokybės skirtumas bus sunkiai įžvelgiamas. Tiesa, gradient paveikslėlių optimizuoti nepatariu.
Keletas PNG optimizacijos pavyzdžių:
1. http://www.htc.com/www/smartphones/ - atvaizduojama 12 telefonų paveiksliukų ir nuo kiekvieno vidutiniškai galima sutaupyti 20KB. 12 * 20KB = 140KB
2. Vienas iš awwwards nugalėtojų: http://epic.net/mmxiv/
Suoptimizavus titulinio puslapio png laimima ~75KB.
3. Neabejotinas nugalėtojas: http://www.olympicstory.com/ - 190KB loss nuo vieno paveiksliuko.
 
• Sprite‘ai – naudokite sprite‘us krauti paveikslėliams. Tai kardinaliai sumažins requestų skaičių, kas žymiai pagreitins bendrą svetainės krovimasi. Automatizuotam sprite‘ų generavimui mano kolega, Paul Gabronis yra parašęs SASS biblioteką (https://github.com/paulgabronis/Easy-Sprites ), kuri leis pilnai automatizuoti sprite‘ų generavimą ir pagreitins ne tik krovimosi laiką, bet kartu ir leis pagreitinti gamybos procesą.
Drąsiausieji gali pabandyti netgi SVG sprite‘us: http://css-tricks.com/svg-sprites-use-better-icon-fonts/
• Labai dideliems background images naudokite jpg progressive arba preloaderius, tai leis neturėti didelių pokyčių svetainėje ir neprivers vartotojo ilgai laukti.
• Jei dėl vienokių ar kitokių priežasčių negalite naudoti sprite paveiksliukų, galite naudoti inline base64 paveiksliukus. Sumažinsite request skaičių, tačiau patys paveiksliukai gali būti šiek tiek didesni, nei įprasto formato (prieš versdami į base64 formatą, patariu juos optimizuoti).
Jeigu naudojate SASS + Compass, tai padaryti galite labai lengvai:

.test-class { background:inline-image("test-image.png") no-repeat 0 0; }
Jeigu naudojate CSS ir koduojate su Visual Studio, Jums padės šis papildinys:
http://visualstudiogallery.msdn.microsoft.com/a56eddd3-d79b-48ac-8c8f-2db06ade77c3
CSS optimizacija
1. Magiškasis Transform:translateZ(0). Naršyklių kurėjai dažnai nesutaria įvairiausiais klausimais, tad nieko nuostabaus, jog nuomonės dėl gpu akseleracijos naršyklėse skirtingos stovyklose išsiskyrė. Jeigu FireFox kūrėjai akseleruoja viską, kas pasitaikė po ranka, webkit varikliuko kurėjai davė laisvę pasirinkti. Ir tai yra gana logiška, nes:
a) Suteikiama resursų skirstymo laisvė
b) Leidžia taupyti įrenginio bateriją
Būtent minėtasis translateZ(0) leis „paforsinti“ gpu akseleraciją elementui, tačiau būkite atsargūs, kadangi tai nėra galutinis sprendimas ir ateityje planuojama įvesti tam dedikuotą css property: „will-change“. Daugiau pasiskaityti galite čia: http://tabatkins.github.io/specs/css-will-change/ .
2. CSS animacijos/tranzicijos. Stenkitės kiek įmanoma daugiau javascript animacijų pakeisti css animacijomis/tranzicijomis, ypač kai Jūs turite animuoti kelis elementus vienu metu.
Paskaityti apie tai ir pajusti skirtumą galite čia: http://css3.bradshawenterprises.com/blog/jquery-vs-css3-transitions/
Tik nepamirškite, jog FireFox naršyklė sunkiai susitvarko su css animacijomis/tranzicijomis, kai vienu metu animuojama daugiau nei 150 elementų.
3. Stenkitės optimizuoti „brangius“ css properties. Tokie stiliai kaip box-shadow, gradient, border-radius, outline, opacity turi įdomių savybių renderinant ir gali žymiai sulėtinti Jūsų UI.
Keli pavyzdžiai, kaip renderinamas box shadow:
Imkime tris scenarijus (A, B ir C), kai:
A - elementas turi tik box shadow.
B - kai turi tik border radius
C - kai turi abu šiuos stilius.
 
Kaip pasikeis renderinimo laikas?
A renderinimo laikas 0,19ms
B renderinimo laikas – 0,16ms
C renderinimo laikas – 0,73ms
 
Dar vienas įdomus testas palyginimui, box-shadow reikšmės
box-shadow: 1px 1px = 0.28ms
box-shadow:1px 2px 3px red = 0.16ms
box-shadow: 1px 2px 3px 4px = 0.76ms
 
Tai jokiu būdų nereiškia, jog reikia atsisakyti šių stilių naudojimo, tačiau jei iškyla tam tikros bėdos su UI greičiu, šią informaciją svarbu žinoti.
Plačiau šia tema: http://nerds.airbnb.com/box-shadows-are-expensive-to-paint/
 
4. Naudokite automatizuotus testus, kad aptiktumėte blogiausiai performinančius selectorius. Vienas naudingesnių testų, kuris leis nustatyti blogiausiai peforminančias klases scrollinant:
http://andy.edinborough.org/CSS-Stress-Testing-and-Performance-Profiling
Keep things simple
• Kurkite gracefully degrading tinklalapius. Galbūt metas atsisakyti javascript select‘o librario, o checkbox‘us ir radio buttonus sustailinti su plain css‘u? Taikydamiesi prie mažumos browserių, tokių kaip ie8 ar žemiau, palaikydami 2 metų senumo opera naršykles Jūs tiesiog apsunkinate tiek savo darbą, tiek svetainės performance, o lopomos vietos vis sunkėja, kol tampa nebepakeliamos ir tampa visiškai nebenaudojamos. Taip, IE8 dar gana plačiai naudojamas, tačiau 1-5% vartotojų tikrai nenusimins, jog tam tikri elementai tiesiog turi defaultinį stilių, o tinkalapis veikia nepalyginamai greičiau.
Custom select: http://jsfiddle.net/TKE6g/
Custom checkbox and radio: http://jsfiddle.net/t7jCL/
• Nepersistenkite su Web font‘ų įvairove. Pasirinkite tik būtinus fontus ir jų variacijas ir nekraukite nenaudojamų, tai leis pastebimai sumažinti krovos laiką.
 
Optimization Essentials
Jeigu norite, jog web aplikacija veiktų greitai, Jūs tiesiog privalote:
1. Minifikuokite CSS failus ir sumažinkite jų kiekį iki minimumo.
2. Jokiu būdu nenaudokite @import css failuose, juo labiau, kai dabar galite lengvai failus importuoti SASS pagalba.
3. Javascript failus krauti tik prieš užsidarant body tag‘ui ir šios taisyklės galima nepaisyti tik labai išskirtiniais atvejais
4. Minifikuokite javascript failus ( Automatizuotam minifikavimui galite naudoti: https://www.npmjs.org/package/grunt-contrib-uglify )
5. Naudokite „up to date“ jquery versiją kartu su jquery migrate, tai leis sėkmingai palaikyti kodą, rašytą su senomis jquery versijomis, tačiau kartu veiks sparčiau ir pati biblioteka užims žymiai mažiau vietos.
6. Kraukite pakopinius stilius tik head dalyje ir kaip įmanoma anksčiau
7. Naudokite resursus iš CDN (Content Delivery Network). Jei naudojate require.js, cdn naudoti galite taip:

requirejs.config({ baseUrl: "Scripts", paths: { /* Load jquery from google cdn. On fail, load local file. */ 'jquery': ['//ajax.googleapis.com/ajax/libs/jquery/2.0.3/jquery.min', 'libs/jquery-min'], } });
8.
MISC optimizacija
• Dažnai socialinių tinklų ikonos tinklalapyje nugrūdamos į footer dalį. Ar jos tikrai vertos savo vietos po saule? Spręsti Jums, o perskaityti ką galite sutaupyti jų atsisakydami, galite čia:
http://zurb.com/article/883/small-painful-buttons-why-social-media-bu
http://lastdropofink.co.uk/market-places/the-true-cost-of-adding-social-buttons/
• Vietoje strandatinio „on resize” jquery event’o, naudokite šį: http://www.paulirish.com/2009/throttled-smartresize-jquery-event-handler/
Praktinis pavyzdys: http://jsfiddle.net/c9Dfm/
• Iframe – didelis galvos skausmas, jeigu jame pateikinėjate informaciją iš nutolusių šaltinių. Tokių iframe krovimas kaip youtube, vimeo, gali kardinaliai pakeisti Jūsų krovos laikus ir window loaded, bei js first event fire eventų gali tekti laukti labai ilgai. Pateiktas snippet‘as padės Jums išvengti šių bėdų:
 

<iframe width="780" height="440" data-src="//player.vimeo.com/video/54638896" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen class="vimeo-video"></iframe> $(document).ready(function () { $('iframe').each(function() { $(this).attr('src', $(this).data('src')); }); });
• Tiems kam patinka skaičiai – neprošal perskaityti šį straipsnį: https://developers.google.com/speed/articles/web-metrics
 
Pabaigai – palyginimas
 
Pabaigai - tiesiog norėčiau palyginti dvi visiškai paprastas aplikcijas. Viena aplikacija bus be optimizacijos, kita – su ir palyginsime jų performance.
Parašius tik labai paprastutę aplikaciją ir pritaikius paprasčiausius optimizacijos veiksmus, mes gavome tokius rezultatus (testuota esant prisijungus prie mobilaus interneto ir išvestas vidurkis iš 10 kartų):
 
1. Neoptimizuota versija:
Užklausų skaičius: 88
Dom ready event fire: 2,24sec
Window loaded event: 8,21sec
Data transfered: 3,2MB
 
2. Minimaliai optimizuota versija
Užklausų skaičius: 74
Dom ready event fire: 1,07sec
Window loaded event: 6,63sec
Data transfered: 2,2MB
 
 
Tai tiek :) tikiuosi, jog patiko :)

Na facbook pasirinko tai kas padėjo jiems pasiekti pagrindinį business development tikslą toje stadijoje - greit išeiti į rinką. O projektui pasiekus kritinę masę žinoma kad tenka rinktis tinkamesnes technologijas ir pradėti migruoti kodą.
 
Mano pagrindinis argumentas prieš visus kurie keikia PHP yra labai paprastas ir aiškus - kiekvieną įrankį reikia naudoti pagal paskirtį. PHP nėra skirtas kurti paskirstytų skaičiavimų sistemas ir globalius socialinius tinklus, tačiau jis yra tikrai patogus įrankis mažo ir vidutinio dydžio projektams, turi labai didelę programuotojų bendruomenę ir tam tikrą filosofiją orientuotą į www.
 
O tamstos paskutinis argumentas.. Na čia ne Samsung vs Apple tema ok? Čia tas pats kaip paklausti 'Mammals will breathe?' Sure they will. What's your point?

Vakar pradėjau seriją nuorodų back-end programuotojams (daugiausiai PHPistams), o šiandien kitas sąrašas - tiems, kas dirba su HTML/CSS/JavaScript/dizainu. Jei norite kiekvieną savaitę gauti po tokią porciją, prenumeruokite naujienlaiškį (jį prenumeruoja jau 120 žmonių).
 
- 28 Free jQuery Plugins For March 2014
- YAMM3 – Build Megamenu For Bootstrap 3
- 6 Reasons Why Flat Design Will Die Soon
- Everyday Helpers: Fresh Free CSS Tools GenerateCSS and Gradientoo
- pNotify : JavaScript Notifications for Bootstrap
- Responsive Full Width Tabs
- How to Debug Website in iPad
- Beautiful Examples of Vivid Dashboard Designs
- Best Free Website Speed Testing Tools
- Responsive CSS Keyframe Animations
- 14 UI Wireframe Stencils For Quick Prototyping
- Create Drop-Down Menu Using CSS Only
- Mobile friendly / Responsive jQuery date & time input picker
- Collective #108
- HTML, CSS, PSD and More: 18 Free Design Resources from February/March 2014
- How to convert Font Awesome to png icons

Įdomus tu programuotojas, jeigu a) pats negali įvertinti savo projekto, b) nesupranti, kad tavo klausimas su tiek pateiktos informacijos yra kaip minimum kvailas :) Linkiu sėkmės ieškant.

Pirmas dalykas, ką turi padaryti norint išsiaiškint tikslesnę, nei preliminarią kainą, tai yra:
DETALUS SPECIFIKACIJOS APRAŠYMAS. Turi ant balto lapo surašyti ko tiksliai reikės (vėliau žinoma viską galima tobulint, arba dadėti jeigu kažką prameti), aprašyti detaliai visų reikalingų f-jų aprašymus ir t.t., jei tai kažkas sudėtingiau, net sukurti kažkokias sąryšių lentas kurios padėtų produkto kūrėjui įsivertinti laiko bei piniginiu atžvilgiu, bei įgyvenditi tavo idėją.
 
O pasakymas, reikia kažko panašaus į linkedin, su prezi.com elementais, tai tas pats, kas paskambintum į statybininkų įmonę ir sakytum: už kiek pastatytumėt kažką panašaus į akropolį, būtų apie 6-8 įėjimai, ir garažai su internetine rezervacine sistema.
 
Manau neišsigąsk ir nemesk idėjos jeigu ją turi, tačiau jei neturi kosminių lėšų, turėtum pradėti nuo "mažai" ir vėliau tobulint iki "daug", o ne iš karto "dinozaurus" eit medžiot.

Gal kas nors jau matė mano kasdienį naujienlaiškį web-meistrams - nuo šios savaitės pakeičiau formatą, ir viena diena per savaitė bus skirta būtent back-end programuotojams, daugiausiai PHPistams. Tai noriu su uždarbio auditorija pasidalinti pirmąja serija, jeigu patiks galėsite prenumeruoti.
 
- Facebook oficialiai pristatė Hack programavimo kalbą HHVM sistemai: Hacklang.org
- Nauja versija: Zend Framework 2.3.0 Released
- Masyvų optimizavimas ir duomenų struktūros: Favor Hash Lookups Over Array Searches
- Konferencijos video:
- Trumpai apie ateitį: Developing Apps for Wearable Devices (Glass/Watches)
- Tiems, kas mėgsta klausyti: The Ultimate List Of Developer Podcasts
- Simfonistams: Manage your assets using Symfony2 Assetic Bundle
- Savaitinės WP naujienos: The Weekly WordPress News, Tutorials & Resources Roundup No.62
- Tiems, kas dar nesinaudoja Composer – pagrindai: Composer 101
- Kaip manote – kas geriau: PHPStorm, Sublime ar Netbeans? Best PHP IDE in 2014 – Survey Results
- Pratęsiant kalbą apie PHPStorm: PhpStorm 8 To Add Official Support for WordPress

Nelabai suprantu tokios uzsakovo pozijos, kad jeigu esu laisvai samdomas programuotojas, tai turiu dirbti uz tiek, kiek dirba maximos sandelyje krovejas. Ypac, kai programuotojo specialybe yra viena is geriausiai apmokamu poziciju darbo rinkoje visame pasaulyje. Kaip suprantu tokius dalykus, kad 40lt/val yra kosmine kaina, kalba zmones, kurie realiai net nesuvokia kam jiems reikalingos programuotojo paslaugos. Jei gabus programuotojas dirba freelance principu, tai kodel jo kaina turetu buti 10 kartu mazesne uz tokios pat kokybes paslauga, nei imoneje?
 
Kalbant apie tai, koks uzmokescio skaiciavimo budas geriausias, tai galiu pasakyti tik tiek, kad visur yra paskaiciuojamos darbo valandos, tada pridedami papildomi mokesciai i kuriuos ieina tokie dalykai, kaip iskilusios nenumatytos problemos. Ir tada pasakoma ta jusu kaina uz projekta.
 
Ir galiausiai patarimas tiems, kurie gerai atlieka savo darba, bet sunkiau sekasi deretis su klientais. Jei uzsakovas kategoriskai sako, kad jusu kaina yra zenkliai per didele, tuomet kuo greiciau jo atsikratykite. Taupydamas pinigus, jis taip pat nores sutaupyti projekto kurimo trukme. Ir apskritai, jei uzsakovas labiausiai domisi paslaugos kaina, jis yra ne perspektyvus klientas ir vargiai supranta kam tos paslaugos jam reikalingos.

Išmokite kelti į GitHub, o ne į kažkokį tai Rara.

Kai žmonės kartais pasako jog freelancinimo rate'as kokie 50LT/h dar daugiau jie iškarto daugina iš 160 ir mano jog tiek gaunasi į rankas....
Bet niekas nepagalvoja, jog kai freelancini, tai
1) turi mokėti mokesčius
2) nesi garantuotas jog turėsi darbo toms 160 val.
3) Gal dar ir buhalterį reik samdytis
4) Atostoginių irgi negauni (galima sakyti 10% rate'o)
5) Susirgus irgi niekas nemokės....
:)

ir kiek jau tu resursu ryja pvz wordpress ? :)
 
mokymosi tikslais kaip kurti TVS'us sitas yra labai gerai, aciu pasidalinusiam, kas nors gal paims ir pasitobulins...
ant producion puslapio bijociau toki paleist ;)

naudinga tema, pasigyrei kad zinai taisykles kuriu nesiruosi sakyti ir parodei kiek uzdirbai (y)

Pagal tai, kad po to dažnai grįžta pas mane ir prašo pataisyti darbą bei sutinka mokėti daugiau ir dirbti mano sąlygomis :)
 
 
Uždarbyje tai žinok specifinė liaudis iš abiejų pusių - ypač užsakovų čia didelė dalis tokių, kurie nori stebuklų už 20 Lt :) Dėl to per daug savo paslaugų šiame forume ir nereklamuoju.

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?

Visų pirma tai netbeans yra lėtas. PHPStorm turi daug formating ir navigacinių funkcijų, greitas, patogus interfeicas, labiausiai patinkanti funkcija tai lango dalijimas į kelias dalis. Taip pat svarbesni dalykai tai framework'ų integracija (ir daug įvairių modulių pvz. twig), navigacija per funkcijas (paspaudus ant funkcijos suranda kur ji yra aprašyta) galimybė integruoti išorinius modulius kaip pvz. composer , vagrant, namespace palaikymas ir daug visokių dalykų. Pamiršau paminėti svarbiausia, PHPStorm mokamas, kas reiškia, kad aš dažnai gaunu bug fix'us, naujinimus ir motyvuotą supportą.
 
 
 

Bet kokiu atveju Ilja šaunuolis, parodęs, kad ir Lietuviai silicio slėnyje kažką gali :)

kai nemokat skaityti, tai niekas nepagelbės: margin, position, !important google it

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:)

Sveikas, pasidomek gearman:)

Kadangi neparašei mokamą ar ne, tai: phpStorm
Iki jos naudojau Netbeans