Share
O stea strălucitoare în comunitatea JavaScript, Addy Osmani a explodat în mare măsură nu numai pentru articolele sale fabuloase JavaScript și contribuțiile open source, ci și pentru a fi unul dintre cei mai prietenoși și apropiați dezvoltatori din întreaga lume.
Blogul său este o treastură de cunoștințe de primă clasă și merită vizita. În acest post, vom vorbi cu Addy despre modul în care i-au fost picioarele umede în JS și au prezentat câteva subiecte dure legate de munca sa în relațiile de dezvoltatori la Google.
JavaScript avea să joace un rol important în a face acest lucru posibil.
Am scris câteva din primul meu JavaScript înapoi când Netscape Navigator a fost browserul dominant. Dezvoltarea dinamică a front-end-ului a început încet să devină din ce în ce mai populară, dar ideea de a putea scrie ceva doar cu HTML / CSS / JS și de a avea loc peste tot a fost puternică. M-am atins de această idee și am continuat. Unele dintre primele mele creații au fost mici lucruri pe care le-ați râde astăzi - calculatoare, generatoare de parole, nimic prea uimitor.
Ca un entuziast de limbă, mi-a plăcut că JavaScript a fost prototip și slab tastat, așa că am decis să-l învăț în continuare alături de alte limbi, cum ar fi C ++. Începând cu începutul anilor 2000, am încercat să îmbinăm limbile scriind un mic interpret pe SpiderMonkey (motorul JavaScript al Mozilla), care mi-a permis să scriu logică pentru aplicațiile mele desktop în JS și să definesc componentele UI folosind C ++. A fost o idee prostească, dar am învățat foarte multe despre internarea motorului JavaScript în acest proces.
Am petrecut mult timp construind mici site-uri de hobby, dar când eram în ultimul an la liceu, m-am hotărât să intru în lumea internă a browser-ului. Am scris un motor de redare ușoară, parseri de bază HTML 4.01 / CSS 2.1 și am înfășurat toate aceste părți în propriul browser mic. Proiectul a fost un coșmar pentru a lucra în mod fiabil, în parte datorită modului în care dezvoltatorii web laxați aveau respectarea standardelor în paginile lor - este amuzant să fiți pe cealaltă parte a gardului acum! Provocările mai mari au fost conformitatea cu speculațiile, efectuarea de mese mari și menținerea performanței, încărcarea pluginurilor video (oricine își amintește bine de ActiveX?).
Am continuat să învăț și să folosesc JavaScript ca dezvoltator de web independent în timpul colegiului, scriind încet site-uri mai complexe și jucând cu Dojo. Cu toate acestea, până în 2006 nu am primit o invitație la GMail, mi sa părut că browserul urma să fie următoarea platformă pentru construirea de aplicații bogate. JavaScript a fost de gând să joace un rol important în a face acest lucru posibil și am decis să plec departe de dezvoltarea aplicațiilor desktop permanent.
De atunci, am încercat să continuu să învăț și unde pot, să împing comunitatea front-end înainte prin scrisul meu și contribuții la open-source. JavaScript este practic peste tot astăzi și este unul dintre motivele pentru care îmi place limba. Dacă vreau să-i învăț pe unul dintre copiii mei cum să scrie un JavaScript, pot să-mi deschid browserul DevTools și să-i arăt. Nu sunt necesare pași suplimentari de compilare - este ceva deosebit.
Dacă intri într-un subiect non-trivial cu acea mentalitate, este necesar să-l descompunem în pași simpli, mai ușor digerabili
Secretul este că mă consider oarecum proastă. Într-adevăr. Dacă intri într-un subiect netrivial cu acea mentalitate, este necesar să-l descompunem în pași simpli, mai ușor digerabili, pentru ca el să facă orice aparență de sens.
Este această perspectivă care cred că face ca scrisul meu să fie accesibil - încerc să înțeleg acele concepte sau instrumente care se pot simți inițial destul de descurajante pentru dezvoltatorul mediu. Este important să puteți aplica acest lucru articolelor și în special documentației. Deci, păstrați-o simplu. Acest lucru face ca articolele să fie mai concentrate. Cum pot genera atât de mult conținut în timp ce înțeleg materialul ?. Ei bine, înțeleg o condiție prealabilă.
În primul rând, faceți bine, apoi faceți mai bine.
Einstein are acest mare citat: "Dacă nu puteți explica pur și simplu, nu înțelegeți suficient de bine" și este adevărat. Nu puteți să învățați sau să revendicați un cadru, un instrument sau o bună practică, cu excepția cazului în care ați avut timp să vă folosiți singur. Găsirea acestui timp este mai ușoară în rolul meu actual, dar din nou în zilele mele ca inginer 9-5, mi-aș petrece timpul peste micul dejun și masa de prânz utilizând în mod activ ceea ce aș scrie mai târziu despre weekend.
Găsirea timpului pentru a face totul este întotdeauna o provocare. În ultimii ani, am această mantra pe care încerc să o aplic pentru fiecare sarcină - "
Puteți apoi să împărtășiți această primă iterație cu colegii dvs. și să vă simțiți dacă mergeți în direcția corectă sau ideea merită urmărită. Pentru mine, acest lucru are mult mai mult sens decât să petreacă săptămâni pe un proiect sau pe un prototip înainte de a cere o contribuție.
Există ceva special în a face parte dintr-o companie cu standarde ridicate.
Atât AOL, cât și Google sunt companii cu echipe inginerești de inginerie, iar oricare dintre reflecțiile mele despre cultura nu se referă la nici un grup specific, mai mult o observație generală.
Cultura de inginerie de la Google este de așa natură încât ne pasă foarte mult de lucrurile poloneze și de transport maritim atunci când simțim că au dreptate. Există ceva special în a face parte dintr-o companie cu standarde ridicate.
La AOL, eram mândru de oricare dintre produsele sau aplicațiile pe care le-am finalizat, dar din cauza naturii rapide a afacerilor și a concurenței, amânarea lansărilor sau lansărilor pentru poloneză nu a fost întotdeauna fezabilă. Cred că este o realitate pentru multe întreprinderi, în ciuda dorinței pe care ar trebui să o aibă pentru a schimba această cultură.
Când este posibil să întârzieți lansările, după cum spune Google, să o faceți "corect", cred că poate face o diferență semnificativă pentru utilizatorii dvs. cu primele impresii ale produsului dvs..
Sunt mulțumit de direcția pe care TC39 le-a preluat în ultimii ani.
Sunt mulțumit de direcția pe care TC39 le-a preluat în ultimii câțiva ani, ceea ce a fost parțial ajutat de implicarea lui Rick Waldron și a lui Yehuda Katz din proiectul jQuery. Ei au acordat o atenție deosebită modelelor și bibliotecilor pe care dezvoltatorii le-au bazat foarte mult și investigând modul în care acestea ar putea fi mai bine rezolvate folosind primitive de platformă. Nu voi comenta în mod special ES6, dar aștept cu nerăbdare să văd module, clase, "să" și " Object.observe () disponibile pe scară mai largă.
În comunitatea JavaScript: suntem într-un loc bun, dar singurul lucru pe care aș dori să-l facem colectiv este să petrecem mai puțin timp creând noi cadre și investiții mai mult timp în eforturile de îmbunătățire a soluțiilor existente. Cred că este fantastic faptul că dezvoltatorii petrec timpul învățând cum să rezolve problemele pe cont propriu - este una dintre cele mai bune modalități de a învăța lucruri noi - dar dacă este un experiment, faceți acest lucru clar, astfel încât alți dezvoltatori să nu vă așteptați să vă mențineți proiect. Acest tip de lucru adaugă doar la zgomot, deci vă rugăm să păstrați sprijinul în minte atunci când eliberează lucrurile!.
Unul dintre miturile mari este că există pentru a înlocui JavaScript.
Am fost de fapt foarte curios să aflu mai multe despre obiectivele pe care Dart le-a avut atunci când m-am alăturat pentru prima oară pe Google. Unul dintre marile mituri este că există pentru a înlocui JavaScript, dar se pare că acest lucru nu este adevărat. Dart este destinat dezvoltatorilor mai familiarizați cu Java, C ++, C #, care încearcă să construiască aplicații web de înaltă performanță; și așa mai departe, au anumite așteptări în ceea ce privește instrumentarea și limba lor. Cred că este un motiv legitim pentru ca ceva ca Dart să existe.
În calitate de companie, JavaScript și Dart sunt tehnologii în care credem și investim. Participăm la TC39, lucrăm la viitorul JavaScript și, de asemenea, continuăm să lucrăm la V8, motorul JavaScript rapid. Inginerii Chrome continuă să lucreze pentru a împinge site-ul web cu noi specificații, cum ar fi componentele Web. Între timp, echipa care a construit inițial V8 construiește acum Dart VM.
Înapoi la întrebarea dvs. originală - Cred că Webking a fost mult mai mult de făcut cu divergența arhitecturii multiproceselor dintre ambele proiecte decât încercarea de a încorpora Dart în Chrome. Dart este un proiect separat cu surse deschise, cu scopuri proprii și puteți obține în continuare Dartium astăzi (construirea Chromium folosind Dart VM).
Când am auzit prima dată despre știrile despre Blink, mi-a fost îngrijorat că acum avem un alt browser care să-l susțină.
Realitatea este însă că au existat deja atât de multe diferențe între diferitele porturi WebKit încât acest lucru nu va avea un impact negativ asupra dezvoltării și testării.
De fapt, Blink ne permite să oferim dezvoltatorilor mai multe instrumente, caracteristici și compatibilitate de care au nevoie pentru a profita la maximum de web ca platformă. Pe termen lung, ne va permite să acordăm prioritate elementelor care vor ușura construirea următoarei generații de aplicații web și în același mod în care V8 ne-a dat o modalitate de a accelera JavaScript, cred că Blink ne va permite să inovăm în moduri care vor beneficia întreaga platformă.
Ne confruntăm destul de des în dezbaterea despre nativul versus web în aceste zile, dar nu vorbim la fel de mult despre nevoia de a pune utilizatorii noștri pe primul loc. Ele se concentrează. Există multe cazuri în care puteți oferi o experiență convingătoare pentru web pe desktop și mobil și va funcționa fantastic. Acestea fiind spuse, există și altele, în care platformele sau browserele mobile au nevoie de lucru. Ca afacere, trebuie adesea să faceți o convorbire asupra a ceea ce face cel mai mult sens pentru utilizatorii dvs. Cred că, în prezent, este foarte util să oferim dezvoltatorilor cele mai bune platforme posibile pentru a face un apel pe versiunea nativă versus web, și asta este ceea ce facem, prin Android și Chrome pentru mobil.
Elemente reutilizabile.
Elemente reutilizabile. În mod tradițional, mulți dintre noi au dezvoltat aplicații destul de vertical, răspândind un singur concept (indiferent dacă este logic sau UI) în câteva părți diferite ale proiectului. Nu numai că acest lucru face mai dificilă menținerea ideii, dar, de asemenea, este dificilă extragerea și reutilizarea ideii în aplicațiile viitoare fără prea mult efort. De asemenea, ne diminuează șansele de a putea împărți componenta cu alții.
Fără a se referi la tehnologii specifice, lucrăm la facilitarea definirii și ambalării componentelor de pe platforma platformei web și acum este un moment minunat să începeți să vă gândiți la modul în care pot fi scrise propriile aplicații, dacă acestea ar fi defalcate în componente specifice.
Front-end-ul se confruntă cu o revoluție în scule, în prezent, cu un număr tot mai mare de dezvoltatori care încep să utilizeze Grunt și explorează unelte de lucru în jurul lui ca Yeoman. Dezvoltatorii plătesc mai multă atenție la ceea ce pot automatiza și cred că acest lucru va contribui la facilitarea mai multor perioade de cheltuieli pentru construirea de aplicații mai bune și a unui timp mai scurt pentru acele procese manuale între.
Revenind la ideea de componente, cred că între componentele web și managementul pachetelor front-end avem o șansă imensă de a schimba într-adevăr modul în care ne dezvoltăm pentru web. AngularJS (și directivele unghiulare) au făcut o treabă excelentă de a reintroduce ideea de blocuri reutilizabile de funcționalitate și lucrurile se uită într-adevăr pe partea de gestionare a pachetelor de lucruri, prin Bower.
Scrierea unei aplicații cu listele pe care doriți să le creați? Grozav. Câteva apăsări de taste de la linia de comandă și tu ai asta. Doriți să faceți articole din această listă persistente atunci când sunteți offline? Nici o problema. Încă câteva apăsări de taste și utilizați un pachet pe care un alt dezvoltator a trebuit să-l scrie pentru a obține acea capacitate. Doriți să vă transformați lista într-o componentă reutilizabilă pe care o poate utiliza oricine altcineva? Asta e ușor. Acesta este viitorul la care lucrăm.
Suntem bucuroși să avem o mulțime de instrumente utile la dispoziția noastră în zilele noastre - instrumente care ne economisesc timp și ne fac viața mai ușoară. Abstracte cum ar fi Sass și CoffeeScript, cadre ca Twitter Bootstrap, încărcătoare de module precum RequireJS, o listă neîntreruptă de MVC și biblioteci de testare unitate ... ar spune că suntem răsfățați de alegere și este interesant să vedem cât timp vă poate lua pentru a obține a început un proiect.
Încă actualizați manual browserul dvs. ori de câte ori faceți o modificare a aplicației dvs.?
În măsura în care aceste instrumente funcționează excepțional de bine pe cont propriu, poate fi un proces obositor care le face să lucreze împreună, mai ales dacă trebuie să realizați un flux de lucru și să construiți un proces în care acestea se compilează și se optimizează în mod succint. Chiar dacă reușiți să obțineți un proces solid de construcție, de multe ori rămâneți nevoit să petreceți mult timp scriind codul de boilerplate pentru aplicația dvs..
Chiar și atunci, trebuie să te întrebi cât de bine se potrivește cu fluxul de zi cu zi. Există câțiva pași mici pe care îi facem în mod repetitiv în timp ce se dezvoltă și care pot fi mai ușor de înmânat la scule. Încercați să actualizați manual browserul ori de câte ori faceți o modificare a aplicației dvs. pentru a previzualiza cum arată? Incearca totusi sa iti dai seama daca folosesti ultimele versiuni ale tuturor dependentelor tale? Vă întrebați dacă a existat doar ceva care vă permite să continuați cu codificarea și să uitați de o mulțime de muncă?
Am fost și noi, motiv pentru care am început să ne uităm dacă am putea oferi dezvoltatorilor o soluție pentru multe dintre aceste probleme comune. Am încercat să le rezolvăm într-un proiect gratuit, deschis, pe care l-am lansat recent, numit Yeoman. Atitudinea oficială a lui Yeoman este că suntem un "stivuitor și plin de încrezători pe partea clientului, care cuprinde instrumente și cadre care pot ajuta dezvoltatorii să creeze rapid aplicații web convingătoare".
Practic, suntem o serie de instrumente și sarcini care vă ajută să obțineți automatizarea unor sarcini mai plictisitoare în dezvoltarea front-end. Suntem compuse din yo (instrumentul pentru schele), grunt (instrumentul de construcție) și bower (pentru gestionarea pachetelor).
Dacă constatați că încă scrieți codul de boilerplate pentru aplicația dvs., gestionați manual dependențele pentru aplicațiile dvs. sau dacă puneți împreună propriul sistem de construire pentru a lucra cu instrumentele pe care le-ați iubit, puteți găsi Yeoman o modalitate frumoasă de a vă salva unele dureri de cap.
Comunitatea dezvoltatorilor de Windows ne-ar putea ajuta cu adevărat aici.
Crearea unui instrument de linie de comandă care funcționează bine pe mai multe platforme poate fi un dans delicat. Una dintre provocările inițiale cu suportul Windows a fost că o mulțime de echipa noastră au fost obișnuiți să utilizeze un sistem * nix și să aibă acces la homebrew / apt-get. Cu toate acestea, nu am reușit să folosim PowerShell sau Chocolatey (Windows-ul bazat pe PowerShell echivalent cu apt-get) și am avut nevoie de timp pentru a înțelege cât de bine aceste soluții au fost comparate cu instrumentele pe care le aveam disponibile în altă parte.
Apoi a luat timp să găsească (sau să obțină) toate pachetele pe care le-am cerut pe Chocolately, deoarece aveam nevoie de git, fantome, opting și multe altele. Situația sa îmbunătățit foarte mult de la prima lansare și Windows este acum oficial susținut de Yeoman folosind instrucțiunile de pe pagina noastră de pornire.
Comunitatea dezvoltatorilor de Windows ne-ar putea ajuta cu adevărat aici, susținând adoptarea pe scară largă a unor instrumente cum ar fi Chocolately și ajutându-ne să ajungem la paritate cu instrumente cum ar fi apt-get. În afară de faptul că au fost fantastice și că am apreciat cu adevărat ajutorul și sprijinul pe care comunitatea de dezvoltatori Windows ni l-au oferit pe parcursul drumului spre compatibilitate.
Trebuie să fac un apel către Sindre Sorhus, Mickael Daniels și Paul Irish, care au contribuit cu adevărat la îmbunătățirea eforturilor Windows în primele zile.
În momentul de față, există o mulțime de instrumente de dezvoltare (fantastice) care sunt scrise care nu sunt doar * nix, ci Mac specific, deoarece le-a face cross-platformă are propriile costuri de dezvoltare și aeriene. Mi-ar plăcea să văd o dezbatere mai deschisă și dezvoltarea de instrumente care pot funcționa peste tot, dar acest lucru nu se poate face fără ajutorul utilizatorilor.
Dacă există o unealtă pe care o doriți pentru Windows, pe care o vedeți doar pe Mac, vă rog să fiți vocal despre aceasta - chiar mai bine, trimiteți o solicitare de tragere!
Încercați să aflați ce ar fi nevoie pentru ao aduce în Windows (și în altă parte) și cine știe? Poate eforturile combinate ale mai multor comunități ar fi de ajuns pentru a face ceva să se întâmple.
Lansarea primei cărți, Învățarea modelelor de design JavaScript (cu O'Reilly) a fost, probabil, realizarea care mi-a dat cea mai mare satisfacție. Acesta a fost cel mai mare proiect de scriere și am luat decizia ca acesta să fie complet deschis de la început - un apel pe care nu-l voi regreta niciodată. Efectuarea de materiale educaționale la dispoziția oricărei persoane, oriunde, dacă își pot permite acest lucru, are potențialul pentru o mulțime de ambele bune.
De asemenea, are potențialul de a crește impactul cărții dvs., deci dacă sunteți autor - vă rugăm să luați în considerare acest lucru. Nu veți regreta!
Accentsconagua