Path to craftsmanship

Learning
23

De apasat l-am apasat… de zeci de ori, deja… dar nimic… nici butoanele de deasupra (base fork, base, head fork, compare) nu le pot folosi… apas si nu se intampla nimic (cu exceptia animatiei CSS). Am incercat si de pe alt browser (fara pluginuri). Lafel.
Butonul de Fork nu face nimic, meniurile dropdown nu mai merg (inclusiv cel de langa user_image)…

Pe link-ul meu, eu vad asta:

Comparing tekkie master...sapioit master · tekkie path-to-craftshmanship_20160120234442.png1334×1314 98.1 KB

Ar trebui sa ne gandim deja la ce-ar trebui sa contina index-ul (gen adaugam chestii si cand incepem sa lucram la ele, facem un issue sau ceva si tekkie pune un working_on in dreptul chestiei aleia.

24

@flavius & @nush voi 2 tre sa va intalniti la o bere sa va rezolvati divergentele, ca deja unde va vad doar pe voi 2 discutand nici nu mai citesc.

25

Ii dau dreptate lui @flavius pentru ca i-a aratat unde greseste in abordare. Nici mie nu mi-a cazut bine pozitionarea lui @nush pe tema tratata aici, prin atac destul de direct asupra faptului ca am creat doar un cadru si nu am contribuit cu nimic in secunda 2. Dar am considerat ca, in spiritul miscarii lucrurilor inainte si nu al dezbaterii nesfarsite e mai bine sa creez un pull request pe acel repo aratand cum vedeam lucrurile atunci cand ele erau doar in mintea mea, crezand ca acesta e un bun punct de pornire (e drept, s-a petrecut 24 hrs later, who cares).

Anyway, @flavius a reusit sa fie mai aplicat ca mine, si asta e un lucru bun. Imi dau seama ca lui ii pasa de acest proiect si il putem impinge inainte impreuna. @AdrianBasalic nu te adaugi si tu echipei?

26

Eu, sa fiu sincer, n-am inteles exact despre ce e vorba. Ce e, cui se adreseaza si ce problema ar trebui sa rezolve? Daca explicati mai pentru prosti asa, sa inteleg si eu…

27

Multi dintre cei seniori am invatat de-a lungul timpului colegi mai putin experimentati. Ca sa putem pune la comun aceste cunostinte, ideea ar fi sa incepem prin pasul

Apoi sa chiar scriem textul “manualului” pe care doritorii de a fi programatori sa il poata parcurge, sa vada exercitii pe care le pot rezolva, ca sa aiba un castig real, nu doar scop didactic.

Ideea a plecat de la o problema al carei enunt chiar induce in eroare invatacelul si am realizat ca prin indeplinirea unor astfel de cerinte rezolvitorul isi formeaza niste deprinderi proaste, pe car emai apoi o sa le suportam cu totii din perspectiva de colegi. E bine sa invete corect din prima, nu tot, ci doar felii din concepte, pe care mai apoi sa le prelucreze singur, ca sa aiba timp de celebrul “click” (a-ha! am inteles in sfarsit X!) care il face sa stapaneasca respectivul concept.

Ori noi nu putem face doar o culegere de exercitii, deoarece chestiunile practice trebuiesc sustinute si de o fundatie teoretica solida. Stiu ca in scoala romaneasca asta se intampla deja, insa cred ca noi, cei “din industrie”, putem formula lucrurile putin altfel, poate mai pe intelesul cititorului, tocmai pentru a trebuit sa explicam aceste concepte la randul nostru.

^^ Sper ca face sens blocul de text de mai sus.

1 Like
28

Deci practic un ghid despre cum sa inveti corect programare?

Nu vreau sa va sparg bula, dar ganditi-va cum v-ati apucat fiecare de treaba asta: modificand ceva existent, bagandu-va nasul in sursa, incercand un “Hello world” pe un environement instalat de-a gata fara sa-l intelegeti.

Apoi ganditi-va daca inainte sa faceti asta va apucati sa cititi despre HTTP, HTML, principii etc. Pun pariu ca ati fi renuntat pana sa vedeti ceva pe ecran.

Nu neg beneficiile unei invatari corecte, dar nu-mi pare ca un incepator care mai degraba cere o solutie pe un forum decat sa-si bata capul si sa sape Google o sa adopte metoda.

Food for thought.

4 Likes
29

Pentru inceput eu cred ca e bine sa facem un fel de “annotated TOC”, pe parti, capitole, sectiuni, in care doar mentionam terminologia corecta si poate cateva conexiuni importante, fara a ne apuca sa scriem in detaliu vreo carte in adevaratul sens al cuvantului: sa fie mai mult un ghid. Poate includem si link-uri / bibliografie, in loc de textul narativ.

Dupa aceea putem astepta input, intrebari concrete din partea celor care nu au inteles una sau alta. Pe care sa le raspundem gradual.

Intr-un final, speranta mea e ca vom avea destul material (cateva sute, mii de intrebari distribuite destul de uniform), astfel incat sa se cristalizeze un concept / mod de abordare care se potriveste nevoilor.

Deasemenea, vad acest ghid ca poliglot, cu unele parti mai abstracte / generaliste.

O alta treaba pe care o putem face, tot in spiritul pragmatismului / abordarii frontale a problemelor celor care au nevoie de un astfel de material, sunt si proiecte practice facute de cei interesati (prefer ca ei sa formeze echipe, nu cate un proiect pe persoana - nu e economic).

Daca facem proiecte, cel mai bine ar fi si sa transformam proiectul intr-o organizatie - oricum proiectul trebuie redenumit din cauza fix typo by flavius · Pull Request #3 · tekkie/path-to-craftshmanship · GitHub.

Cum va fi concret ramane de dezbatut, si sa luam cele mai bune idei si sa le combinam.

De aceea trebuie sa si definim un scop, un “motto”, din ramele caruia sa nu iesim.

Pentru mine personal, scopul ideal ar fi “eficientizarea procesului de invatare pe termen lung al celor care au nevoie de asta”.

In spiritul celor de mai sus, cred ca ne-am grabi daca am face asta.

Trebuie mai intai sa ne gandim ce vrem sa facem, cum vrem sa facem, de ce vrem sa facem si care sunt consecintele.

Si sa strangem destul input asa incat sa putem iesi cu o masa omogena de idei, cu un corp de idei coerent.

Eu as vrea sa aud orice fel de input din partea celor care cred ca ar folosi acest ghid pentru a invata.

Cred ca doar asa putem aborda pragmatic problema, orientat pe rezultate.

1 Like
30

Am gasit libera denumirile de software-craftsmen si software-craftsmanship pentru organizatie, cum va suna? Primul parca exclude craftswomen :stuck_out_tongue: Sunt unii care spun ca software nu trebuie privit ca un craft

De acord. Putem imbina partile in diferite path-uri, pe care sa le propunem pentru diverse nivele de acces.

Exact. Eu am plecat la drum cu ideea centrata pe drumul in sine, insa mi-e clar ca pana acolo trebuie sa avem pasii individuali (grupele de notiuni care trebuie stapanite), si probabil aceia sunt cei care dicteaza motto-ul in acest stadiu. Cred ca cel mai dificil la inceputul drumului e sa vezi finalitatea, pentru ca nu stii in ce consta ea, iar noi vom putea arata exact acest lucru, unde se va ajunge.

Practic informatiile pe care noi le vom organiza exista deja, insa dificultatea apare in chiar organizarea lor. De aceea eu as fi curioasa de o lista de click-uri pe care le-am avut fiecare din noi in a ajunge la actualul nivel de senioritate, sa vedem care sunt comune, sa le punem separat pe cele optionale, iar apoi aceste doua “liste” sa le supunem feedback-ului celor mai neexperimentati.

31

Uite acest cuvant mi-a generat mie un click acum.

Nu spunem noi programatorii ca trebuie sa invatam incontinuu? Ca oricum nu vom sti niciodata totul, ca mereu ne confruntam cu probleme noi?

Poate ca nu exista finalitate in sensul clasic. Poate ca scopul e sa il aducem pe cel care studiaza in punctul in care nu mai are nevoie de ajutor, in care se poate ajuta singur.

Ce inseamna pentru voi un programator ajuns la maturitate?

Criteriile care imi vin mie in minte sunt:

  • e capabil sa inteleaga un program open-source de cel putin cateva sute de mii de linii de cod si sa il modifice (da, LOCs nu e o masura acurata a complexitatii, eu vorbesc orientativ acum)
  • e capabil sa ii ajute pe altii / sa explice ceea ce stie
  • e capabil sa spuna cu acuratete ceea ce nu stie, si stie unde sa caute si cum sa caute atunci cand se loveste de necunoscut
  • a programat aproape zilnic cel putin cativa ani
  • stapaneste cateva paradigme de programare
  • stie toate structurile de date fundamentale (pana la grafuri)
  • nu vede limbajele de programare si nici librariile / framework-urile ca pe ceva magic, ci ca pe niste instrumente pe care le-ar putea scrie de la zero, insa nu o face din pure motive economice (costa timp)

Astea la nivel tehnic. Plus soft skills.

1 Like
32

Daca imi amintesc bine, la inceput da, asa faceam.

Insa am avut cateva momente repetate de frustrare cam in “anul 1-2 de studiu individual” in care ma tot loveam de probleme frustrante si ma saturasem.

Atunci am decis cu buna stiinta ca vreau sa inteleg mai intai cum functioneaza lucrurile.

Retrospectiv, cel mai mult m-ar fi ajutat atunci daca cineva mi-ar fi spus ce sa incerc sa inteleg si in ce ordine. Nu am avut asta, a fost nevoie de ani de zile de acumulare de cunostinte si de sinteza a unor notiuni aparent disparate pentru a-mi forma un corp de idei omogen pe baza caruia sa imi construiesc “knowledge graph” cu sens.

Cred ca as fi putut reduce acest timp la jumatate daca as fi avut ghidajul corect.

Intrebare: cum convingi si cum entuziasmezi un incepator sa investeasca 1-2 ani in intelegerea modului de functionare a lucrurilor, fara un outcome concret, doar cu mici succese pe ici pe colo?

Ma adresez in special celor care invata intensiv acum: cum te-as putea entuziasma eu pe tine sa nu te mai gandesti la “facutul banilor” timp de 1-2 ani, si sa investesti acest timp, in fiecare zi aproape, in invatarea terminologiei si in intelegerea modului de functionare al unor lucruri?

Daca ti-as spune ca altfel ajungi la acel nivel de cunoastere / intelegere in dublul timpului, if ever?

33

Mi-am permis sa reordonez lista de mai sus pentru a reflecta oarecum o prioritate pe care o vad eu.

Eu abia atunci am putut sa declar ca am inteles un concept, cand am reusit sa fac pe altcineva sa il inteleaga.

Total de acord. Sunt CTO care s-au refugiat in “arhitectura” si care nu mai reusesc sa transmita informatiile corecte catre echipa, pentru ca au pierdut contactul cu dezvoltarea.
Cred cu tarie ca cei seniori sau mai sus trebuie sa ramana hands-on toata viata, chiar daca dupa un anumit punct codul pe care il scriu se foloseste efectiv doar pentru proiecte interne / personale. Mai merge omul in concediu, la ski, pe plaja, deci mici intreruperi acceptate de la “zilnic”, dar nu de ordinul lunilor.

Nu e suficient sa fi programat procedural timp de 15 ani de zile. Clar asta nu e un semn de senioritate, dimpotriva. La fel putem zice si despre OOP, degeaba ai programat doar OOP si Java vreme de 20 ani, trebuie sa mai fi vazut si restul peisajului. Si zic asta nu pentru ca e oarecum la moda programarea functionala. Continuand, OOP poate fi vazut doar ca si “clase si obiecte si patternuri”, iar DDD sa fie scos separat tocmai pt ca e un alt nivel de intelegere/gandire.

Prima parte (cu acuratetea) e fuzzy, e posibil ca tehnologiile sa se schimbe atat de repede in viitor incat sa devina incorecta. Da, azi e aplicabila ideea, dar nu sim inca pt cat timp.
Pe partea de cautare suntem mai mult de acord, eficienta gasirii informatiei lipsa e si pentru mine o unealta in arsenalul programatorului care a depasit stadiul de junior.

Aici m-au pierdut pe mine toat esistemele traditionale de invatare. Ori era prea arida partea de explicare /modul de a face exercitii de acest gen / aratarea finalitatii, ori nu-s eu o persoana careia sa ii placa asa tare partea asta. Dar la mine a functionat vederea de sistem, cam pe acelasi principiu pe care nu mi-a placut niciodata geometria in plan (2D), nu o “vad”, dar am avut o incredibila usurinta la cea in spatiu (3D). Am mai intalnit astfel de oameni, e de dezbatut aici. @iamntz poate spargem un topic numai despre asta cu algoritmii, merita?

E nevoie de timp pentru a face diferenta intre concepte fundamentale si instrumentele care sunt doar “means to an end”. La inceput toate par din categoria conceptelor fundamentale, inclusiv librariile altora.

E bine sa nu fim toti oameni ai cavernelor, sa stam in beci si sa scoatem cod minunat. Dar trebuie avut grija sa nu exageram la cerinta de soft skills prea tare. Asta e una din frumusestile lumii noastre, aceea in care diverse tipuri de personalitati conlucreaza la crearea de soft functional. Pana la urma Linus nu e usa de biserica si e un foarte bun programator.

Da, dar mai “la coada” listei. E mai greu sa ajungi la dedicatia de a studia codul altora.

2 Likes
34

Eu as defalca si patterns, si in OOP as lasa principiile fundamentale.

Tangential cu asta, un exemplu: programatorii care stiu mecanic OOP, dar nu l-au internalizat inca, vor fi cei care vor sustine ca golang nu este un limbaj OOP.

35

O sa incerc sa explic situatia mea actuala in speranta ca este un input de care voi sa il folositi.
Am inceput programarea (procedural) in urma cu foarte multi ani in Pascal, iar mai apoi cu timpul am invatat PHP (automat cu el si MySql/HTML/CSS) tot procedural (oricum pe vremea aceea nu programa nimeni OOP in PHP). Dupa asta a urmat o perioada de aproximativ 10 ani in care am fost destul de rupt de domeniu doar ca sa ma intorc la el acum 3 ani. In acesti 3 ani am realizat o aplicatie destul de complexa pentru firma la care lucrez. Aplicatia este facuta procedural, depinde in 90% pe BD si nu respecta nici un principiu (asta am stiu asta am facut), drept urmare codul arata groaznic si este foarte greu de mentinut. Pentru a rezolva cele 2 probleme dar si pentru a optimiza aplicatia per total incerc rescrierea ei in OOP si in acelasi timp implementand un sistem MVC (fara framework). Problema este ca nu inteleg decat partial OOP si de fiecare data cand caut tutoriale gasesc acelasi lucru, respectv class animal… new cat/dog care nu prea se aplica la mine sau nu sunt eu in stare sa le transpun in ceea ce am nevoie. Atata timp cat eu nu am o intelegere completa asupra OOP nici nu pot sa vorbesc despre principii SOLID sau despre TDD.

PS. Nu dati cu pietre.

4 Likes
36

Mersi @IceRidder pentru input, departe de noi ideea de a da cu pietre. Esential in cazul tau este ca ai acoperit o nevoie a business-ului, iar acum esti in postura in care esti nevoit sa o imbunatatesti. Poate deschizi un topic separat in care sa expui actuala stare de fapt, iar not incercam sa te ajutam cu sfaturi punctuale ca sa atingi acest obiectiv de rescriere, evident fara sa folosim fraze de genul “mergi la scoala prima data, si cand ai terminat de studiat X si Y, adica peste vreo 3 ani, hai inapoi”. Mie mi s-a spus asta de cateva ori, deci inteleg postura in care te afli.

Pe de alta parte trebuie mentionat ca este nevoie sa inveti anumite chestiuni, si ca asta iti va consuma mult timp. Trebuie sa fii dispus sa faci acest efort sustinut, pentru ca altfel comunitatea de aici nu te va ajuta, vazand ca eforturile ei sunt risipite.

37

Deci pentru cazul tau concret:

Constientizezi unde te afli, si vrei sa faci refactoring, dar vrei sa il faci “corect” (TDD de exemplu).

Eu as merge pe doua paliere in paralel in cazul tau, care la un moment dat vor converge, si intre care si exista un oarecare interplay.

Palierul 1: masarea codului

Cand faci un refactoring, te apuci de lucrurile marunte, care pot fi usor facute - si asta indiferent de cate stii sau nu stii. De exemplu, poti incepe prin a extrage valorile constante in constante simbolice - si a le pune in clase.

Daca ai avea experienta, ai avea o sansa mai mare sa construiesti acele clase intr-un mod in care nu va fi nevoie de atat de mult refactoring la ele in viitor. Insa cum nu ai experienta necesara, refactoringul va fi cel mai probabil necesar. DAR asta nu este o problema, imbratiseaza ideea de refactoring continuu (iterative development)

Si aici ne legam de palierul 2: analiza domeniului aplicatiei (si mai tarziu si designul)

Invata despre UML si analiza unui domeniu de business (analiza, nu designul). UML in sinea lui nu este ceva magic, dar este un mijloc bun de comunicare: atunci cand tu vei veni cu diagramele la mine, eu voi intelege din priviri ce idei vrei sa exprimi, deoarece e un limbaj standardizat, mereu consistent.

UML (de fapt, orice limbaj de diagramming, chiar si unul propriu, nu conteaza, atata timp cat e consistent) te va ajuta sa iti aduni si sa-ti sintetizezi gandurile, si sa vezi mai bine cum poti imbunatati acea structura de clase.

Cat despre analiza vs. design: in analiza descrii elemente de business, concepte “de zi cu zi”, nu clase, chiar daca in multe programe de desenat UML va scrie in capul unei diagrame “class diagram”, si in fata chenarelor va scrie “class Foo”.

Acum, ce ma intereseaza pe mine de la tine, si ce ar ajuta acest proiect:

  1. scrie tot ce iti trece prin minte in urma sfatului meu
  2. tine-ne la curent in legatura cu evolutia ta, venind cu feedback la puncte concrete din acest “ghid” care va apare, puncte de care te lovesti si tu in aventura ta

PS: palierul 1 suna a extrem de marunt, dar este de fapt o munca titanica de design, pentru ca tu in acel pas formalizezi conceptele din aplicatie. Critic in acest pas este sa numesti bine clasele si constantele. Modul de abordare, eleganta lui, ma face sa ma gandesc la baby step, giant step, pentru ca pe palierul 1 mergi in baby steps, dar pe palierul 2 in giant steps.

1 Like
39

@nush eu am înțeles că de trei ani lucrează la o aplicație. Undeva, pe parcurs, și-a dat seama că OOP e veriga lipsă :slightly_smiling:

@tekkie @flavius: cred că ghidul/cartea ar avea un pic mai mult succes dacă ar fi în limba română. În limba engleză există deja zeci (sute?) de materiale ce tratează craftmanship-ul din toate punctele de vedere. În română însă… nu prea există. (da, sunt de acord că engleza este un must în domeniu, dar cred toată lumea e de acord că înțelegi mai ușor un material în limba maternă)

2 Likes
40

Din partea mea:

Tradus in romana: da. Exclusiv in romana: nu.

4 Likes
41

De-asta putem pune HTML-ul aproape de inceputul listei, iar CSS-ul destul de aproape de HTML… Nu vrem sa-i speriem inainte sa inceapa.

Ma refeream la un fel de divide-et-impera aplicat procesului de invatare. Ca sa intelegem mai bine CUM sa predam ceva concret, trebuie sa intelegem si CE avem de predat.

Eu cred ca @nush s-a referit la a lua un exemplu crude si, pornind de la putinul pe care il avem, sa modificam, re-scriem, stergem si incepem din nou, pana iese ceva de calitate. Nu cred ca s-a referit strict la un atac la persoana, cat la a incerca un fel de kickstart.

Intr-adevar, de multe ori, cei mai putin experimentati vor sa li-se dea totul pe tava, iar daca @nush a interactionat suficient cu ei, este normal sa-si fi format deprinderea respectiva, pentru a separa persoanele care spun ca vor sa faca, de cele care vor dar nu stiu cum.

Fiindca este mai usor sa modifici si refaci ceva existent si sa extinzi ceva existent, decat sa incepi de la 0, oricat de random ar fi inceputul.

Personal, as merge pe ceva gen art-of-programming, ori temple-of-programming

Invata-ma ceva suficient de usor incat sa pot crea produse utilizabile, insa suficient de in voga incat sa pot catiga bani cu asta. Un exemplu bun ar fi creatul de pagini web cu doar html css (pentru inceput).

Dar aca cum a spus @tekkie, putem sa ne separam in mai multe branches, fiecare fiind axat pe ceva anume, apoi, cand consideram scopul acelui branch pseudo-finalizat, se poate trece la corectare, translatare si un merge with the master branch.

Sau un branch, pe github.

Sunt de parere ca UML-ul ar trebui sa fie destul de sus, intr-un branch. Face minuni, pentru incepatori.

In incheiere, poate, cineva, va rog, sa faca acest Pull Request in locul meu, va rog? Mie inca nu-mi merge… am trimis de aseara mail la github…

42

“craftsmanship” suna deja perfect, e catchy, usor de “vandut”, de marketed. “art of” e ocupat de niste volume de algoritmica foarte renumite, iar “temple” suna prea moale.

“Path to Craftsmanship” este perfect.[quote=“Sapioit, post:41, topic:2502”]
Invata-ma ceva suficient de usor incat sa pot crea produse utilizabile, insa suficient de in voga incat sa pot catiga bani cu asta. Un exemplu bun ar fi creatul de pagini web cu doar html css (pentru inceput).
[/quote]
Buna ideea. Insa nu din toate lucrurile se fac bani direct. Unde se va putea, se va face.

Vrem sa dam calitatea procesului de invatare pe viteza de a pseudo-avansa (pentru ca nu e un avans real)?[quote=“Sapioit, post:41, topic:2502”]
Dar aca cum a spus @tekkie, putem sa ne separam in mai multe branches, fiecare fiind axat pe ceva anume, apoi, cand consideram scopul acelui branch pseudo-finalizat, se poate trece la corectare, translatare si un merge with the master branch.
[/quote]
Bineinteles ca vom folosi ce ne pune git la dispozitie, dar deocamdata ne aflam intr-o supa primordiala. Primi pasi ar fi:

  1. stabilirea “politicii editoriale”
  2. incroparea unui “annotated TOC”, in care continutul se rezuma la terminologie si eventual cateva conexiuni intre notiuni
  3. Strangerea de feedback - imi imaginez ca asta va dura cateva luni bune, un an, pentru a avea un inceput solid?

Felul de continut pana la si inclusiv 3 e pentru a crea o imagine de ansamblu si de sinteza. Fragmentarea pe branches sta in calea formarii unei viziuni coerente.

1 Like
43

In order to pursuit mastery, you need to have your economical needs fulfilelld.