Două întrebări „tehnice” pentru IT-iști

Râdem, ne hlizim, ne-njurăm, dar eu chiar am două întrebări serioase (mă rog, idei, că întrebări sunt mai multicele) pentru comunitatea des criticată pe-aici. Motivele sunt două: primul e că m-aș apuca să învăț ceva nou și nu știu în ce direcție să merg, al doilea e că mi-e lene mie să caut mai multe detalii – în genere, articolele de pe net sunt cam ca tutorialele de React pe care le citeam acu’ vreo doi ani jumate, „hai să facem un to-do app„.

  1. Are sens să dau mai multă atenție TypeScript sau pot să rămân la JS chior? M-am uitat un pic, extrem de superficial, acu’ ceva vreme, și nu m-a convins (pe șantier încă nu s-a aprobat TS, deci n-am avut nevoie), am considerat la vremea aia că mai mult mi-ar complica existența. Deci: care ar fi principalele beneficii ale TS? Ce a fost selling point pentru voi?
  2. Am zero experiență cu aplicațiile mobile (m-am uitat vag pe documentația React Native, asta e singura tangență pe care am avut-o cu domeniul), dar mă tentează să-mi bag nasul prin Swift, să mă joc de-a aplicațiile de iPhone. Dacă sunteți pe-aici cu experiență pe zona asta, având în vedere că eu pornesc cu un background de JS, care-s conceptele care mi-ar fi străine, respectiv care-s alea mai dureroase de care v-ați lovit sau m-aș lovi? Ce v-ați fi dorit să știți înainte de a vă apuca de Swift? Cât de tare v-a enervat sintaxa când ați trecut de la un limbaj la altul? Cum te raportezi la baze de date și cache on device?

Shoot.

Mulțumesc că ai citit acest articol.
Dacă vrei să susții acest blog, cumpără un abonament de 5$

64 comentarii

  1. Principalul lucru pe care îl apreciez eu unul la TS este că face codul mult mai ușor de navigat și „descoperit”, pentru că folosirea unor tipuri de date fac și găsirea utilizării lor mult mai ușoară. TS combinat cu un linter poate preveni tot felul de clase de buguri rezultate din neatenție sau bad practices. Pentru mine cam la asta e util.

    00
  2. Nu am înțeles motivația ta de a învața lucruri noi. E din plictiseala, din dorința de a schimba job-ul, de a porni o afacere, de a găsi de munca în alta tara și lista poate continua?

    00
    • Vreau să mă las de băut și tre’ să-mi ocup timpul cu ceva. Gluma deoparte, motivația e irelevantă cînd vrei să înveți ceva nou. Dar dacă ții morțiș, am niște timp liber și o serie de idei pe care aș vrea să le testez, iar un web app limitează foarte mult experiența utilizatorului – asta apropo de Swift. Legat de TS, ideea e cam așa: dacă oamenii spun că le ușurează viața, atunci investesc niște timp și m-apuc de citit documentația.

  3. Nu-i ca la filme sa stai mai mult sa culegi opinii de pe imdb decat sa vezi un film cap coada.

    Pui mana si inveti. Daca n-ai tragere de inima, macar dai vina pe sotie/copil/vecini, in loc sa-ti apui ca ai invata tu ceva, dar nu eati convins ca e viitorul, man.

    00
  4. Typescript e front-end pentru programatorii de back-end: dupa 10 ani de Java mi-a fost usor sa lucrez si cu TS. Insa pentru un profesionist al front-end-ului nu aduce nimic in plus față de React.

    00
    • Vezi, Vali, de ce nu e frumos sa bagi toti „ITistii” in aceeasi oala? :)

      00
    • Ce zici tu, Merline??!

      00
    • Typescript aduce in JS strong typing si separarea componentelor in fisiere separate – cod, html, css. Pentru cineva care a codat Java/C# fara prea mult js la viata lui e facil de inteles/debug-uit. Insa pentru cineva fluent deja in js aduce doar boilerplate – un limbaj si o organizare stricta – pentru ceva mai simplu de scris de exemplu in React, care ofera performanta si o bogatie de librarii cel putin echivalente.
      Am reformulat, asta era cauza minusurilor?

      00
    • N-are treabă Typescript cu „separarea componentelor in fisiere separate – cod, html, css”.

      00
    • wat

      00
    • n-am traba cu astea dar macar omul a argumentat, voi ati venit doar cu ‘wat’ca gastele..programatorii plii

      00
  5. TypeScript ca si limbaj este ceva peste javascript ce iti da niste chestii simple ce introduce tipurile de date si clasele la nivel javascript. Pe foarte scurt daca in js aveai o foarte mare libertate cand defineai un obiect, daca folosesti typescript si un linter obtii o oarecare siguranta la tipuri de date specifica limbajelor ce au aceste lucruri: Java, C#.
    Un alt avantaj major al acestui limbaj ar fi ca daca il stapanesti si mai sti si javascript poti foarte usor sa-ti faci un client in Angular, respectiv un server in NestJS.
    Referitor la aplicatii mobile daca iti doresti sa incerci orice platforma ce ofera cross-platform compatibility(React Native, Nativescript) fi pregatit de un tooling foarte nasol si in care o sa-ti blestemi zilele. Referitor la Swift pot doar sa spun ca intre Objective-C si Swift este o diferenta colosala, si daca vi din lumea js timpul de invatare nu ar trebui sa fie foarte mare, atata timp cat intelegi conceptele de programare orientata spre obiect(oop). Adevarata problema in ecosistemul Apple o reprezinta faptul ca informatiile nu sunt atat de imprastiate ca la Android de exemplu, iar Apple are pretentia ca dezvoltatori de ios-macos sunt mai inteligenti fata de restu. De asemenea sper ca au scos idiotenia prin care trebuiai sa ai cont de apple developer pentru a putea pune aplicatia pe dispozitiv.

    00
    • Aparent omul asta stapaneste limbajele de programare mai bine decat gramatica limbii romane si nu e de blamat, clar face mai multi bani decat cu limba romana.

      00
    • E clar că știe muul mai bine programare decât știe limba română. Bine, o să îți spună că el vorbește mai mult în engleză și nu îl interesează româna. Deși, dacă îl cauți, are și engleza praf. Muult mai praf decât româna.

      Eu am o reținere în a lucra cu colegi care nu reușesc să aibă clară gramatica limbii materne. Dacă nu au înțeles-o înseamnă că au niște lacune uriașe în educația tehnică.

      00
    • nu stiu, nu pot sa garantez doar intreb daca esti agramat nu inseamna ca in orice limba(aj) tot la fel esti? ce-i drept cu atat autocorect la ora actuala e cam lame ..

      00
  6. Două întrebări pentru „Code Monkeys”

    Fixed it for you.

  7. Urmatoarele opinii sunt bazate pe faptul ca ma pasioneaza limbajele de programare, nu am lucrat efectiv cu cele nominalizate de tine, doar m-am jucat. Experienta mea sunt compilatoarele, linterele si alte tool-uri asociate, deci ma invart in familia C/C++/C# si uneori chiar good old assembly. Fac aceasta precizare ca sa iei cu un pic de lamaie ce spun.

    Eu zic ca e spre binele tau sa inveti TypeScript. Un framework js se bazeaza doar pe conventii, un limbaj cu static typing iti da peste des’te cand nu esti cuminte.

    La mobil, inteleg ca te intereseaza doar lumea Apple, atunci nu ai foarte multe optiuni ca incepator in afara de Swift, asumand ca nu vrei sa intri in Objective-C. Cel mai apropiat limbaj e Kotlin, daca ai avut de a face cu familia Java/C# cam pe acolo se situeaza din punct de vedere al sintaxei. E un pic dificila situatia, in funcție de genul de aplicatie pe care doresti sa o dezvolti, s-ar putea sa ai nevoie si de un backend, iar aici sunt deja foarte multe optiuni.

    00
    • Mă interesează Apple pentru că nu prea-mi arde să mă arunc prea mult în lumea C. De Android se poate ocupa altcineva după ce am un proof of concept, iar cu un backend web based mă descurc, că-n esență n-ar fi decît niște call-uri către o bază de date. De fapt, cam ăsta e și motivul pentru care m-am uitat la un moment dat la React Native, c-am zis c-aș putea fenta niște muncă suplimentară pe Android, dar e un pic mai complicat de-atît. M-am gîndit la Swift pentru că din prezentările lor părea mai prietenos decît C.

    • Singura legătură intre Swift si C sunt cuvintele cheie. Swift e foarte user friendly, are management automat al memoriei (ARC) și are un mare avantaj, folosește LLVM ca backend de compilare, ceea ce inseamna ca vei beneficia inplicit de ultimele „descoperiri” in domeniu, asta traducandu-se in special in performanta. Singurul lucru ciudat la Swift mi se pare conceptul de enum care iese din paradigma limbajelor uzuale.

      Pentru Android se folosește Kotlin, nu C.

      O alta optiune pentru crossplatform ar fi Xamarin (C# based). Asa poti folosi acelasi limbaj de programare indiferent de platforma si indiferent de destinatie (frontend sau backend). Depinde foarte mult de tipul de aplicatie ce solutie alegi.

      00
    • Daca stii JS, te poti uita si la framework-ul de la Ionic care stie sa iti genereze aplicatii de IOS – ideea fiind ca poti scapa invatand doar un singur limbaj :)

      00
  8. Pentru mobil as recomanda flutter. Odată pentru faptul ca este cross platform, apoi pentru ca face parte din ecosistemul google și poți integra destul de facil serviciile lor de cloud. Găsești tutoriale pentru începători destul de bune aici: https://youtube.com/c/CodeWithAndrea

  9. ce inseamna js chior? es5, es6?
    baga ts si incearca ionic
    bafta

    00
  10. Boss, pui problema dubios. Scopul tau e sa fii platit ca sa inveti. Altfel devii irelevant peste X ani. Prin urmare, nu exista „pe șantier încă nu s-a aprobat X, deci n-am avut nevoie”. Vezi ce faci tu pe acolo pe santier, propune chestii ce implica alte tehnologii (nici nu-i greu in cazul tau, daca zici ca lucrati in vanilla JS). Fa cumva sa te plateasca aia ca sa inveti chestii care ti-ar folosi si-n alta parte in timp ce le construiesti un POC in alta tehnologie. Efectiv n-are importanta (ca incepator) care-s beneficiile TS-ului. N-au aia de pe santier nevoie de ceva pe mobile?

    00
    • La mine pe șantier e cu dashboard-uri de monitorizare, nici dac-ai vrea n-ai putea dezvolta pentru mobil mai mult de-o aplicație care să-ți trieze niște notificări care să te ducă tot pe un monitor mare.

  11. kernel panic.

    00
  12. Dupa articolul asta, o sa-i putem injura nominal. Luminati-va fața !

    00
  13. Toti ce „vor sa invete” :D se reped ca rata la muci sa citeasca tot ce e nou aparut pe piata. Baga tutoriale de react, nosql, unity, JS si ei nu stiu nici structuri banale de date. Daca vrei te ghidez putin. Uita prima data de tehnologii, hai sa vb despre ce vrei sa faca aplicatia. Gandeste-te la 3 componente mari: 1) baza de date, 2) procesele(logica, ce face) si 3 )interfata, cum arata. Baga la fiecare o descriere sa ne prindem ce ai vrea sa faci.

    00
    • Dacă voiam feedback pe idee, îl ceream, that’s not the point. Mă interesează ca investiția mea să se rezume la timp, că nu duc lipsă de el. În esență, nu face mare lucru, utilizatorul introduce niște date la care primește un feedback de la un alt utilizator, iar în spate se mai întîmplă niște algoritmi care analizează o parte din datele respective și produc niște rapoarte. Nu mă interesează consultanță pe partea de arhitectură, că are cine să mi-o ofere, mă interesează să minimizez costurile și să pot produce un proof of concept. Asta e tot.

    • Bai asta vroiam sa întreb și eu, nu sunt limbajele de programare un tool care ar trebui sa iti facă viață mai ușoară ? Gen, eu sunt contabil, nu știu ce e aia programare, dar îmi trebuie sa extrag date din baza de date și sa le afisez boboc, pentru asta îmi trebe sql python și react. Acuma, nu e mai important de învățat bazele, adică ceva algoritmi dupa care, cu bazele acestea solide sa te apuci sa faci chestii ? Întreb, nu dau cu paru?

      Mai mult, în opinia mea un limbaj de programare e ca un topor – unu are coada mai lunga altu mai scurta, unul e galben unul ros, unu are coada din lemn altu din sticla etc. La fel cum când alegi un topor conteaza pentru ce iti trebe, așa și aici… De asemenea poți sa alegi cel mai fain topor, dacă nu știi sa crapi lemne… degeaba. Ce ziceți am dreptate sau sa mă limitez la topoare?

      00
    • pentru asta îmi trebe sql python și react

      De ce dracu’ iti trebuie React pentru asa ceva?

      Conectează Excel direct la *SQL si gata.

    • @znuff ai fi surprins sa vezi cât de greu se mișcă excel când vrei sa faci ceva care Implica mai mult de 10 rânduri și 3 coloane

      00
    • „@znuff ai fi surprins sa vezi cât de greu se mișcă excel când vrei sa faci ceva care Implica mai mult de 10 rânduri și 3 coloane”

      pai de aia iti trebuie python, o baza de date si cod in spate, ca sa nu sughite cand ai mii/milioane de inregistrari.

      Un limbaj de programare e un mod in care iti faci tooluri mai performante, altfel ramai la ce gasesti pe piata, adica Excel.

      00
    • Nu conteaza ce face aplicatia sau ce trebuie sa faca, asta e planul 14-pe. Consultantii de pe arhitectura avem. Arhitectura e banala. Important e sa ne umflam cu ultimele chestii citite. :) Nu ai sa produci nici un proof of concept. Cea mai importanta parte este arhitectura, nu tool-ul cu care faci. Cand ai o viziune clara a ce vrei sa faca aplicatia(cerintele), ai clar in minte arhitectura(sv de BD, tabelele, legaturile intre tabele, procese(unele sincrone, altele asincrone), fluxul de date, cum se baga datele, in ce tabele ajung, ce calcule se fac, ce restrictii, comunica cu alte sisteme ? ce date extrag ? Am drepturi pe ferestre si butoane, am policy pe date ? Apoi vin rapoartele si iti zic ce sa genereze, ce vreau sa vad, cand, sincron, asincron. Arhitectura e mama aplicatiei, e TOT. Apoi vin tool-urile si intrebarile de genul cu ce desenez pishatul pe ecran. Ce server folosesc ca BD. In ce scriu backed-ul, in ce scriu front end-ul. E ok ca macar discutiile astea aduc putina lumina asupra domeniului. Nu o sa faci nimic, o sa abandonezi ideea, pot pune pariu pe o lada de bere. :D

      00
  14. Raspunsul corect la ambele intrebari: “Da”.

    00
  15. La fel ziceam și eu despre TS: că pare mișto, dar că nu văd utilitatea lui. Cel mai bine este să lucri la ceva proiecțele mici până începi să prinzi gustul. Asta este una dintre chestiile alea pe care trebuie să o simți tu cu mâna ta până să îți poți da o părere pe măsură.

    După ce 1-2 oameni din echipa noastră a început să lucre cu Typescript restul au fost curioși să vadă cu ce se mănâncă și acum avem proiecte de NodeJS, React, chestii simple de front-end JS făcute în TS sau în curs de conversie.

    Gândește-te la JSDoc: aia e documentație a funcțiilor direct în fișierul JS. Acum ia aia, dar compacteaz-o și, folosindu-te de eslint, permite-i să îți arate ce parametrii acceptă o funcție și ce tip de rezultat așteaptă. Oricum, este ca mâncarea pe care trebuie să o mănânci puțin până îi prinzi gustul.

    Also, uite aici o serie de mini-tutoriale super mișto de TS:https://www.youtube.com/watch?v=LKVHFHJsiO0&t=2s

    00
  16. Asta e honeypot article, nu? ii prinde vali pe toti si ii baneaza?

    00
  17. 1. Nu stiu ce faceti acolo pe santier, dar daca nu scrieti teste si nu aveti un codebase de cateva mii de linii, nu are sens sa te obosesti cu TS.
    2. Threads, queues and concurrency. Dar daca stii numai JS mult succes. Dar s-ar putea nici sa nu ai nevoie.

    00
  18. Mai bine inveti React Native decat Swift. JavaScript stii, React Native e si cross-platform si mi se pare destul de usor de invatat – eu in 3 saptamani am facut o aplicatie destul de complexa, desi nici JS nu stiam.

    00
  19. Oricand ramai fara inspiratie vizavi de ce sa inveti mai departe, doua resurse:

    Web Development Roadmap – Frontend / Backend/ DevOps – choose your poison.

    Video-ul lui Brad Traversy pentru web developeri

    TS ca static type checker pentru aplicatii JS mari (sa le spunem „enterprise”, desi sunt web) e cam un must, o alternativa fiind Flow dar care este mai putin popular; ambele se invata usor si on the job cand / daca vei avea nevoie de ele. Poti sa te uiti si pe Elm daca vrei un flavour de JS mai exotic, din curiozitate mai mult didactica decat ca uz practic.

    La mobile apps nu ma pricep. Spor la treaba.

    00
  20. Eu in 3 săptămâni, dupa 16 anibde programare, inca ma uitam la Aurelia ca la poarta noo. Magar stie toata lumea ca sunt.
    3 săptămâni ii un sprint jumate. „complex”

    00
  21. Same problem here. Am refacut un site in cateva luni in NodeJS, Mongo si Express.

    Daca vrei sa faci repede o aplicatie, react e chiar simplu. Daca vrei sa inveti ceva nou, typescript e mai destept ( eu nu pot sa inteleg inca de ce ai programa fara sa declari tipul datelor, dar who am I). Folosesc typescript acum si nu mi se pare vreo diferenta, dar parca imi vine mai ok declaratul de variabile.

    Overall, eu nu sumt programator desi am programat in toate limbajele si parerea mea personala e ca toate’s la fel in mare masura. Depinde ce vrei sa faci.

    La un webapp poti sa controlezi ce e in cache din server, dar nu inteleg exact ce/cum vrei sa cachuiesti. Nu cred ca are relevanta JS/typescript in contextul asta.

    Node si redis cred ca merg bine impreuna pt server side caching. React are si components de mobile nativa deci ai putea sa simplifici stackul daca nu folosesti si Swift.

    • Întrebările n-aveau legătură una cu alta. Aia legată de TS era din categoria „are sens să-mi pierd vremea sau mai bine aștept pînă cînd o să am nevoie să bag un ochi?”. Legat de cache local, ăla e un fix al meu pe care nu-l mai detaliez acum. Ai și tu dreptate, poate n-are sens să mă arunc în Swift, ci ar trebui să mă uit mai atent la React Native pentru început.

    • @alex jurnalistul

      Ia-o cu un singur limbaj, gen react, care o fi el.

      Dacă te apuci de 10 chestii odată nu o să prinzi mai nimic.
      După, avansează la altceva.

      Prinde bazele mai întâi și apoi o să avansezi.
      Și aici nu este locul pentru a cere sfaturi despre IT.

      Încearcă ceva canal de Youtube sau devforum.

      Sau îmi dai add pe LinkedIn.
      Presupun că îmi vezi adresa de email.

      00
  22. Wow, ce ciorbă de cuvinte.

    Nu înțelege omul nimic de aici.

    00
  23. 2. Mai există și varianta de Progressive Web App, cu limitările aferente, dar pentru multe aplicații mobile nu ai nevoie de cine știe ce capabilități hardware care nu sunt expuse deja în browser.

    00
  24. Daca îți dorești să dezvolți un proof un concept și bugetul e limitat, de ce te chinui sa înveți programare și nu încerci o platformă de no-code?

    De pildă bubbleio. Costurile sunt absurd de mici, chiar 0, tutoriale găsești cat cuprinde, nu ai nevoie să știi să scrii linii de cod și, probabil, in doua săptămâni ai isprăvit.

    Mai departe vezi tu ce faci, le arăți șefilor ce ai făcut și poate primești buget să faci o aplicație mai matură.

    00
  25. Salut. Am vreo 15 ani experiență pe chestii Microsoft (C#) și Web, și am început recent (acum un an) o aplicație de mobil, cu Swift. Swift-ul în sine e foarte similar cu C# și Java, chiar JavaScript în unele instanțe. Mai high-level și mult mai ușor de folosit decât ciudățenia aia de Objective-C care se folosea înainte. Mai ușor de folosit decât JavaScript, după părerea mea, pentru că e type-safe, adică nu te lasă compilatorul să scrii chestii aiurea, ca și în JS.

    Pentru interfață, dacă nu ai nicio experiență cu Apple, îți recomand să începi cu SwiftUI – e noul mod de a construi interfețe pentru aplicațiile de iOS. Un framework relativ nou, abia-abia gata pentru aplicații serioase, dar Apple a investit timp mult în implementare. E absolut intuitiv, limbaj oarecare normal, ierarhii aproximativ ca și în HTML, animații, navigații etc. E mult, mult mai ușor de folosit decât ce era înainte cu storyboards. Ca idee, clientul cu care am început proiectul (un individ trecut de 60 de ani, al cărui background e că a lucrat cu baze de date Oracle prin anii 90-2000) a început să se joace și el cu SwiftUI să vadă cum merge treaba, și după 2-3 săptămâni scria el interfața de la zero pentru unele screen-uri, eu trebuia doar să atașez funcționalitatea.

    Există suport foarte bun pentru baze de date pe mobil, sub forma Core Data, care e un fel de Object Database, din nou, destul de ușor de folosit, dacă ai mai lucrat cu baze de date.

    Dacă ai întrebări sau nelămuriri, poate te pot ajuta.

    00
  26. Pentru aplicatiile mobile iti recomand Swift, si mai ales SwiftUI. e deja la 3 iteratie si de pe stilul de declarative interface. Mai nou, pe noul iPadOS 15 poti da chiar submit in store direct din iPad. Ai nevoie de un mac destul de nou (2015+ macar), daca vrei sa faci mai mult decat 2 ecrane cum poti sa faci pe iPad. Am trecut de la C -> ObjcC -> Swift si acum la joc si cu Swift UI. Aici nu are legatura cat m-a enervat sintaxa pentru ca in momentul in care vrei sa faci si intelegi conceptul e ok. Bazele de date sunt de multe feluri dar ca idee tot un SqlLight vei avea pe device. Aici ai mai multe wrappere pe care le poti folosi: CoreData (de la apple), Realm (third party app) chiar si sqllight direct. Asta pentru date mai mari. pentru date mai light poti folosi plisturi (fisier “text” – de ex setari ale userului – enable la nu stiu ce filtru) sau chiar keychain (unde poti face store la parole, la biometrics).
    Eu zic ca ti s-ar potrivi ca si limbaj swift cu framework-ul swift ui. Ca si avantaje swift-ul e portat pe orice, de la android (e inca in stadiul de incercare) pana la aplicatii web. Ca si dezavantaje e un drum destul de lung, de la memory management pana la semnarea aplicatiile sau distribuilrea lor. e prea lunga discutia dar ca idee

    00
  27. Cum s-a mai scris, si eu vin de pe backend, pentru mine selling point la TypeScript a fost nevoia unui cod mai curat, mai familiar. JS-ul mi s-a parut mereu haotic, asa ca lucrul in TS a fost mai natural pentru mine. Eu si in python folosesc type hinting.

    Nu stiu Swift, nu pot sa zic nimic despre asta.

    00
  28. Daca te intereseaza partea de Front-End ti-as sugera sa nu cauti neparat sa inveti un framework nou ci conceptele. In cazul js, Declarative vs Imperative programming, o sa intelegi un pic mai bine cum functioneaza si cum sa scrii o aplicatie mai mare decat un To Do app in cam orice js framework modern fie ca vorbim de Vue, React sau AngularJS. Si viitorul pare sa fie SPA si PWA care cam depind de framework-uri declarative. vanilla js e imperios necesar dar ai nevoie de mai mult in lumea moderna.

    Sincer, dupa 20 de ani in domeniu sunt mai suparat pe „programatori” decat Vali. Cel putin in ultimii ani, vad tot mai multi oameni care sar peste chestiile de baza, se apuca si scriu direct chestii in React dar nu sunt in stare sa scrie o functie vanilla js. Mari experti in plugin-uri WP si habar n-au sa scrie un mic script in PHP chior. Si tot asa…

    00
  29. Programare? E directia gresita: ITiștii trebuie să înțeleagă că ei sunt mijlocul și nu scopul.

    Oamenii adevarati sunt aia care impart pliante. Aia fac economia sa zboare.

    00
  30. Nu-mi vine sa cred ca nu face nimeni code review la codul din imagine.

    Functia buy trebuie refactorizata sa primeasca o lista de cumparaturi.

    In al doilea rand trebuie tratat cazul in care nu nu are lapte. Atunci trebuie sa cumperi un ou.

    00
  31. E bine sa stii mai multe, scuza cu „poate nu am nevoie” e pentru lenesi. Daca vrei sa progresezi in cariera si sa nu ajungi un code monkey depasit de tinerii cum mult mai mult timp ca tine din viitor, invata tot ce prinzi. Te poate ajuta pe viitor daca vrei avea o pozitie mai sus, de arhitect/ product manager / lead => poti sa iti dai cu parerea fara sa te faci de ras si sa iti pierzi respectul in fata echipei.

    00
  32. De ce să pierzi timpul cu JavaScript sau TypeScript când poți programa direct în assembler?

    00
  33. Are TL;DR la final.

    În cariera mea de IT am întâlnit foarte des valuri tehnologice în care am avut impresia că s-a aruncat toată lumea și pe care am putut să le evit. Când am intrat eu în programare baza era C++, design patterns, UML (Rational Rose), COM/DCOM (de la Microsoft). Știam ceva C++, m-au angajat că aveau nevoie de mine că știam să lucrez pe Linux – toată firma însă era pe soluții Microsoft. Era 2000, anul de vârf al lui Microsoft, cam cum Apple vrea să fie acum dar nu reușește pentru că nu sunt suficient de capabili. Am ignorat valul Microsoft și m-am concentrat pe ce îmi plăcea mie/ce îmi doream eu – m-am concentrat pe structuri de date, pe elemente de bază de programare, nu pe „ce trebuie”. Pentru mine a fost o soluție de succes în primii 20 de ani de carieră.

    De ce ți-am zis chestia asta: pentru tine Typescript sună ca acel „COM/DCOM” pe care toată lumea trebuia să-l știe la sfârșitul anilor ’90. Dacă nu ai nevoie de ceva, poți sări peste. Eu mențineam la un moment dat o listă a tehnologiilor „must-know” pe care am reușit să le evit. Eram mândru de ea, încă am pe lista aia chestii ca *orice Java*, a trebuit să scot Javascript de pe lista respectivă, dar încă mai am acolo jQuery și Typescript.

    Acum, să-ți zic și de ce ai vrea să înveți typescript. JS este un limbaj mizerabil pentru că ceea ce funcționează la nivel micro – ai o tonă de libertate de mișcare, poți să faci tot felul de trucuri și improviații – nu funcționează pe proiecte mari. Ajută foarte mult ce aduce Typescript: rigurozitate, type-checking. Eviți o sumedenie de erori, mai ales erori care apar din colaborarea mai multor oameni pe proiect. Când un proiect e făcut de un singur om e ok să folosești JS gol, când mai mulți oameni colaborează poate deveni foarte complicat în funcție de cât de izolat lucrează. Typescript aduce tipuri de date ceva mai inflexibile, nu îți mai permite (dacă țin bine minte) să pasezi un string acolo unde aștepți o structură cu patru membri, etc. That’s a good thing, dar cât timp nu îți folosește și nu e ceva ce-ți dorești să cunoști, dacă nu plănuiești să-ți faci un portofoliu ca să cauți proiecte pe cont propriu, evită.

    Swift pare să fie în cealaltă categorie, de chestii pe care vrei să le-nveți pentru că îți place. Go for it. Poți să-ți construiești un portofoliu, să găsești proiecte noi, sau pur și simplu să-nveți pentru că e mișto de tot să faci ceva în limbajul ăla. Îți recomand pentru că Swift e un limbaj din categoria celor serioase – o să te-ajute să înveți mult mai multe despre programare decât copy-pasta Javascript. Ca și tehnologie e o chestie solidă. Foarte important: încearcă să nu te concentrezi doar pe făcut interfețe superficiale pentru iPhone sau pentru ce vrei tu. Încearcă să devii intim cu limbajul – să rezolvi probleme dincolo de o simplă folosire a unei biblioteci de UI pe care ți-o pune la dispoziție Apple. Swift e, cum ziceam, un limbaj de programare serios și merită să-l tratezi serios. Încearcă, de exemplu, să-ți construiești cu el ceva unelte care să-ți facă automatizări prin casă. Ideea e că Swift e un limbaj mult mai curat și mai riguros, și te va ajuta în cele din urmă să scrii chiar și JS mai de calitate.

    Foarte des tehnologiile pe care lumea le tot proclamă „must-know” dispar în vreo cinci ani. jQuery, Angular, chiar și React sunt chestii care o să dispară. Typescript poate fi util, dar poate că în 5 ani nu o să îl mai folosească nimeni, pentru că se va folosi god-knows-what. Deocamdată în programare ai privilegiul de a-ți alege otrava. Asta în afară de cazul în care cineva îți cere un proiect într-o tehnologie care-ți displace, caz în care ai de ales dacă pleci sau înghiți otrava.

    Dar chiar dacă nu înveți o anumită tehnologie, un grad de familiaritate cu „ce probleme rezolvă și cum le rezolvă” te-ar ajuta să ai. Așa ar fi rămas pentru mine orice JS related dacă nu m-ar fi obligat la un moment dat un proiect să-l folosesc. Pățăști. Oricum, orientează-te spre chestiile fundamentale din programare. Cum rezolvi probleme. Structuri de date. Cum faci design-ul unei aplicații mai mari, cum construiești proiecte mai mari de 3 clase și șase funcții. Cum rezolvi probleme fără să întrebi pe stack overflow – doar folosind documentația de bază a tehnologiei pe care o folosești.

    TL;DR: Dacă nu îți dorești Typescript sari peste el; deși pare că e tehnologie pentru eternitate, eternitatea e destul de scurtă în programare. Învață Swift pentru că e un limbaj mai inteligent și mai riguros decât Javascript. Rigoarea aia o să-ți ajute în abordarea problemelor de rezolvat cu orice limbaj de programare. Și învață să nu faci copy-pasta ci să rezolvi tu problemele: fără stack-overflow, doar tu și codul tău.

    00
  34. NOU
    #64

    9/10 programatori nu stiu sa faca un „program” care sa rezolve problema celor 8 regine

    9/10 programatori sunt „code monkeys”

    00

Adaugă un comentariu

Câmpurile marcate cu * sunt obligatorii! Adresa de email nu va fi publicată.

1. Linkurile utile în context sunt binevenite.
2. Comentariile asumate fac bine la blăniță.
3. Șterg comentariile care îmi strică buna dispoziție.
4. Nu fiți proști, agramați sau agresivi la primele 50 comentarii aici.

Susținere

Susține acest blog cumpărând de la eMAG sau de la Finestore.