SynTAX

Cat de penibil este sa te smardoiesti pe un forum. Plus ca daca vrei sa arzi pe cineva de ce cacat i-ai zice inainte? Legat de ce zice @wirtz treaba este ca eu la Vodafone am fost sa iau un modem din ala, un cacat d-ala de internet mobil pentru cineva de la tara. Proasta aia care mi-a incheiat contractul nu mi-a zis dar mai jos in contract scria ca ti se prelungeste actualul contract la telefon cu inca doi ani pentru acel modem. 1.Citesti cu atentie contractul. 2.Daca te tine buzunarul si ai timp, poti sa dai in judecata. Nu esti singurul caruia i s-a intamplat asta. Sigur mai gasesti inca 100 de pagubiti.

Toata viata o sa faci tranzactii prin intermediul altora? Ori platesti acum 12 milioane, ori mai tarziu 100.

Ce legatura are dislike-ul cu activitatea lui pe forum? ON: Buna idee.

Si dupa gandirea ta de ce nu sparg o banca de pe wi-fi-ul de acasa? Il las neparolat si aia este. A intrat cineva domle, eu nu stiam de parole. Aide plm...

Servere de joace? Metin si cantar straic?

Te-a facut sa razi degeaba. Stiu pe cineva, cred ca aici pe forum are cont, care a fost pus de RDS sa semneze o hartie prin care inceteaza toate atacurile asupra unei adrese IP, altfel nu-i dadea drumul la internet.

E ca si cum ne-ai intreba daca sa-ti iei camion sau masina mica. Unul face ceva, celalalt cu totul altceva. Uite-te pe site-uri de joburi si vezi cum sunt impartite cererile. Pe partea de PHP gaseste mai multe locuri de munca dar pe C++ este mult mai greu si mai bine platit. @MrGrj: :D Mai bine zis fan Boyka.

Nu ai nevoie niciodata in gaming de Quad Core decat daca faci streaming si tu ai acolo 6 core-uri. Daca te intereseaza iti fac eu maine o configuratie. Nu trebuie sa o cumperi, doar sa-ti faci o idee.

Da, dar noi nu aveam probleme cu downloadul. Este clar ca este o problema intre host si domeniu. Si nu ne-ar fi deranjat atat de mult pentru ca a adus discutia de facultati, doar ca este cam deficitar la capitolul gramatica. w/e o sa postez aici cand este up si functional 100%

Face figuri si la mine. Oricum o sa-si revina curand.

Este up.

Intotdeauna imi face placere sa citesc posturile lui @AGSQ. Le scrie din suflet cu dragoste catre voi, useri. ON: Puteai sa-i faci ceva doar daca folosea boti. Asa.... mai greu.

Am zis la plesneala cu garda pentru ca mi se pare mult 2 zile sa stea cazut. Si legat de ce ai zis tu daac ii cauti si pe ei pe acasa, n-au nici un film/joc cumparat cu licenta.

Incearca sa urci altundeva poza.

Mi se pare ca era de pe filelist aici pe forum. Am vorbit odata cu el prin pm-uri, caut si-l taguiesc aici. Totusi tind sa cred ca este ceva cu garda.

Niste carti de motivare sau autobiografii ale unor persoane care au oarecum legatura cu it?

Scuze ca ma bag sa vorbesc pe banii tai dar ce astepti tu de la staff sa faca in legatura cu banii tai. O intrebare absolut normala. Astfel de subiecte nu sunt create pentru a recupera cineva banii. Sunt create pentru a atrage atentia asupra anumitor useri si pentru a se invata din ele. Atat.

Daca te pricepi atat de mult la stiri, de ce nu aduci si tu o contributie la categoria de stiri? Sa criticati stiti. Atat.

Da. Ne plac cei care-?i fut via?a intr-un joc. V-a? bana pe to?i cei care in loc sa posta?i ?tiri, lucruri de programare, securitate, posta?i despre metin.

Poate rugam televiziunile ca alaturi de atentionarile cu sport, apa si ce mai este sa puna si un spot publicitar cu riscurile lipsei de pula. Am un prieten la cancan. Incercam ceva frumos?

In caz ca isi castiga procesul reclamatul este bun de plata si pentru cheltuieli cu judecata, adica onorariu.

Ori de câte ori vorbim despre design în alte domenii decât software-ul, discut?m din punct de vedere orientat c?tre utilizator. Produsele Apple sunt renumite pentru c? se concentreaz? pe experien?a utilizatorului cu dispozitivul: cum se simte, cum arat?, cât de repede r?spunde, sunetele pe care le scoate, etc. . Software Design-ul este singurul tip de design care pare s? nu aib? utilizator. La urma urmei utilizatorul final nu are nici o idee despre cum este organizat? aplica?ia pe care o folose?te ?i nici m?car nu-i pas?. Tot ce conteaz? pentru el este ca aceasta s? func?ioneze bine. ... Software Design-ul are un utilizator: programatorul care va trebui s? schimbe codul scris de echipa ta. Dac? folosi?i collective code ownership (ca majoritatea echipelor Scrum), ar fi bine s? lua?i în considerare user-centric software design (software design orientat c?tre utilizator). Idei precum "Clean Code" ating aceast? abordare dar nu o dezvolt?. În continuare, a? vrea s? explorez acest subiect în detaliu. 1. Dezvoltatorii noi care lucreaz? cu Usable Software Design vor deveni mai productivi mai repede De ce este gradul de u?urin?? în folosire al aplica?iilor web un subiect atât de important ast?zi? A? argumenta c? motivul îl constituie avantajul competitiv pe care îl aduce, deoarece utilizatorii g?sesc mult mai u?or s? înceap? s? foloseasc? o aplica?ie care este construit? având utilizatorul în minte. Niciun utilizator nu are timp s? înve?e un produs nou; vrem s? începem s? îl folosim imediat ?i s? ne aduc? beneficii instant. Noii utilizatori ai software design-ului sunt noii dezvoltatori care se al?tur? echipei. Vom presupune c? ?tiu limbajul de programare, framework-ul principal utilizat ?i au lucrat în domeniul business înainte. Cât timp le ia s? devin? productivi în mediul vostru? Timpul petrecut îi familiarizeaz? cu designul aplica?iei ?i cu modul în care lucrurile se fac în mare parte, dar se traduce prin cheltuieli. În termenii produsului, se nume?te pierdere. 2. Cerin?ele cele mai comune sunt implementate mult mai rapid cu Usable Software Design Gânde?te-te la tipul de activit??i desf??urate pe produsul curent. ?ansele sunt ca multe dintre ele s? fie repetitive. În aplica?ia de eHealth pe care o dezvolt?m, primele func?ionalit??i au luat ceva timp pentru a fi implementate (NB: în acela?i timp înv???m ?i o nou? tehnologie). Privind atent la ceea ce ne-a încetinit lucrul ?i ajustând designul, am optimizat dezvoltarea ?i am ajuns la punctul în care aproximativ 60% din munca este UI / UX design. Acum, dezvoltarea nu mai are bottleneck. Ne-am uitat apoi la optimizarea activit??ilor de UI / UX, dar asta e alt? poveste. Cheia acestei îmbun?t??iri a stat în faptul c? privind în urm?, ne-am dat seama c? dezvoltam func?ionalit??i care corespund câtorva tipuri de munc?: Ad?ugarea unei noi activit??i aplicat? pe situa?ia medical? a pacientului:create, display, change, hide; Legarea unei entit??i medicale de o intrare în jurnalul pacientului; Afi?area unui istoric filtrat dup? diverse criterii; Etc... Din moment ce ?tiam din roadmap-ul proiectului c? vor ap?rea din nou astfel de cerin?e, am început optimizarea pentru aceste tipuri de munc?. Ocazional, trebuia s? facem un nou tip de munc? care dura mai mult. Un exemplu a fost un serviciu de c?utare a unui medicament, care este rapid, scalabil ?i u?or de modificat pentru a func?iona corect cu ultima versiune a bazei de date de medicamente. A trebuit s? înv???m s? folosim vertx ?i mongodb pentru a face lucrul acesta, ?i ne-a luat de 3-5 ori mai mult timp decât o sarcin? normal?. Deoarece aceasta este o situa?ie local?, care este pu?in probabil s? se repete, nu am f?cut nimic pentru a optimiza. Ideea este: ca o aplica?ie care este u?or de folosit pentru taskuri mai comune, Usable Software Design permite implementarea rapid? a celor mai frecvente tipuri de caracteristici. Acestea sunt principalele beneficii pe care le v?d pentru Usable Software Design. Dar cum s?-l ob?inem? Primul lucru este ... 3. M?soar? ?i îmbun?t??e?te Procesul pe care l-am folosit pentru a face designul mai opera?ional a fost destul de simplu: m?soar? cât timp este nevoie pentru a implementa fiecare caracteristic?; discut? devia?iile la retrospectiv?; identific? ce ne împiedic? s? mergem mai repede; define?te ?i pune în aplicare modific?rile; repet?. Noi folosim un proces Kanban / XP, a?a c? am folosit the cycle time distribution diagram ?pentru a identifica punctele de devia?ie. Avem o retrospectiv? recurent? la fiecare dou? s?pt?mâni în care discut?m impedimentele ?i identific?m solu?iile. Implementarea a fost f?cut? în urm?toarele dou? s?pt?mâni, ?i ne-am p?strat un ochi la cycle time distribution în urm?toarele luni. A fost u?or s? vedem îmbun?t??irile deoarece majoritatea task-urilor s-au mutat la stânga. Într-un context Scrum, echipele nu m?soar? cycle time, doar viteza. Problema este c? viteza este un indicator agregat pentru toate func?iile implementate pe durata sprintului. Prin urmare, echipele Scrum au dou? op?iuni pentru a ajunge la usable software design: Cantitativ?: începe m?surarea timpului efectiv petrecut pe user story; Calitativ?: executa o retrospectiv? recurent? pe tema de usable design. Întreab? developer-ii ce le ia mai mult timp decât ar trebui. Într-o echip? în care exist? încredere ?i transparen??, ve?i identifica imediat problemele. Aceasta este metoda de baz? pentru a ob?ine usable software design. Metoda avansat? este preluat? din practicile de usability. 4. Ruleaz? teste de usability pe Software Design-ul t?u Testele de usability pot fi rulate în mai multe moduri. Am g?sit totu?i un format care se potrive?te cel mai bine pentru Software Design: Noteaz? o list? de task-uri pe care utilizatorul trebuie s? le execute. Adu într-o camer? utilizatori care nu au v?zut niciodat? produsul ( sau p?r?i ale produsului pe care vrei s? le testezi). Cere-le s? execute task-urile. M?soar? cât timp le ia s? fac? asta. Noteaz?-?i unde se blocheaz?. Folose?te feedbackul pentru a îmbun?t??i produsul. Iat? câteva exemple de task-uri comune pentru o aplica?ie web: adaug? un nou formular cu un câmp text ?i un buton save; adaug? validari suplimentare unui câmp; schimb? textul unei etichete (pentru o limb? sau toate limbile suportate); adaug? o nou? regul? de business; afi?eaz? o list? de entit??i într-o pagin?. Etc... Enumer?m câteva lucruri importante de ?tiut despre teste de usability: Asigur?-te c? le spui participan?ilor c?, dac? nu ?tiu s? fac? ceva, este vina designului, nu a lor. Încurajeaz?-i s? pun? întreb?ri când se blocheaz?. Un test complet cu o singur? persoan? n-ar trebui s? dureze mai mult de o or?. Începe cu task-urile cele mai comune întâi ?i cu cât mai pu?in? informa?ie posibil?. Ofer? informa?ie doar atunci când cineva se blocheaz? ?i cere ajutor. Preg?te?te cam zece task-uri, dar a?teapt?-te s? finalizezi mai pu?ine. Acum ?tim cum s? identific?m probleme. Sunt sigur c? urm?toare întrebare este... 5. Cum arat? Usable Software Design? Pentru început men?ionez c? ideea de a se centra pe developer, ca utilizator al Software Design-ului, este foarte nou?. Am v?zut discu?ii oarecum în jurul acestui topic, ?i am contribuit ?i eu la unele. Literatura din trecut despre Software Design a atins acest subiect, dar nu în mod explicit. Exist? totu?i foarte mult? literatur? despre usability. Voi men?iona doar trei principii de baz? ale usability-ului care se aplic? în Software Design: Claritate, Consisten??, Reducerea surprizei. Prezentam cateva exemple: Claritate: Nume?te pachetele în func?ie de denumirea func?ionalit??ii (pachete func?ionale) Iat? un screenshot de la o aplica?ie pe care o dezvolt. Po?i spune ce face doar pe baza numelor? Prima oar? l-am auzit pe Sandro Mancuso vorbind despre ideea aceasta la I T.A.K.E. Unconference 2014 (2014.itakeunconf.com) ?i am fost foarte interesat s? încerc. V?d ideea ca pe un bun start în Usable Software Design. Consisten??: P?streaz? o structur? consistent? pentru fiecare pachet func?ional A?a arat? un pachet func?ional când este extins: Fiecare con?ine trei lucruri: o clas? de request, o clas? de controller, o clas? de view. Înc? trebuie s? g?sesc un loc mai bun pentru InvoiceFileNameGenerator, dup? cum pute?i vedea limpede. Aceasta este o înc?lcare a celui de al treilea principiu, reducerea surprizei. Consisten??: Fiecare tip de clas? trebuie s? aib? o interfa?? consistent? Am v?zut mai devreme c? un pachet func?ional const? din trei tipuri de clase: a clas? de request, o clas? de controller ?i o clas? de view. Exist? ?i un nivel mai ridicat de consisten?? la care se poate ajunge, mai specific în interfa?a fiec?reia dintre aceste tipuri de clase. În acest exemplu, toate clasele de Request men?ionate mai sus au o metod?:response()?Toate func?iile controllers au o metod?:render().Fiecare func?ie de controller folose?te un view pentru a reda informa?ia. Aceste interfe?e sunt consistente în toate pachetele func?ionale. Gânduri finale Usable Software Design vor aduce dou? beneficii economice majore: implementare mai rapid? pentru task-urile comune ?i integrare mai u?oar? a oamenilor noi în proiect. Pentru a ob?ine Usable Software Design, avem nevoie de feedback de la utilizatori, mai exact de la dezvoltatori. Exist? dou? metode pentru a ob?ine: prin retrospective ?i rulând teste de usability. Ideea nu este complet nou?. Principiile precum claritate ?i consisten?? au fost folosite mul?i ani la rând pentru a ob?ine Design mai bun. Ideea de usable Software Design este totu?i o schimbare de perspectiv?; a te gândi la dezvoltator ca la utilizatorul software design-ului ?i a încerca activ s? ob?inem feedback de la el sunt demersuri care vor aduce modific?ri în modul în care ne organiz?m codul. Sursa: todaysofmag.ro

Software Design se num?r? printre ultimele trenduri care impresioneaz? domeniul IT. Se pare c? în fiecare an apar alte câteva idei de design. Mai întâi au fost design patterns. MVC este modul în care construim aplica?ii web, în timp ce idei cum ar fi: domain driven design, porturi ?i adaptoare, microservices se bucur? de adop?ie ?i interes crescut. 1. Fiecare decizie de design are avantaje ?i dezavantaje Când facilitez exerci?ii de arhitectur? sau design, cum ar fi Architectural Kata,Code Retreats sau unul dintre workshop-urile de software design, le cer participan?ilor s? creeze un design, fie scriind cod fie sub form? de diagram?. Apoi discut?m ?i oferim feedback solu?iei lor. De multe ori, un participant îmi cere s? dau „cea mai bun? solu?ie” pentru problema respectiv?. R?spunsul nea?teptat este c? nu exist? „cea mai bun? solu?ie”. Realitatea este c? orice decizie de software _design_are avantaje ?i dezavantaje. Dar la urma urmei, iat? o list? succint? a caracteristicilor unui design bun: Dezvoltare rapid?, U?or de schimbat, U?or de g?sit problemele, Sigur, Rapid, Scalabil, Reduce ?ansa de gre?eli. Este imposibil s? scrii cod care ob?ine un 10/10 pentru toate aceste criterii simultan. De aceea avem sloganul „quick and dirty” în loc de „corect ?i rapid ?i scalabil ?i f?r? bug-uri ?i u?or de schimbat ?i ...”. Întrebarea important? devine atunci: pentru care criteriu este acceptabil s? ob?ii un 8/10, 6/10 sau 4/10, în contextul în care te afli. Acest lucru se traduce în „cea mai potrivit?” solu?ie pentru un anumit context; probabil c? nu va ar?ta precum „cea mai bun? solu?ie” la care te gândeai. Iat? o poveste personal? pentru a sprijini acest fapt. Când dezvoltam în C#, am descoperit c? am putea folosi delegates ca expresii lambda, reducând astfel num?rul de linii de cod pe care trebuia s? le scriu. Am rezistat tenta?iei deoarece colegii mei ar fi g?sit acest cod confuz ?i ar fi crescut ?ansa de a face gre?eli. A? fi putut încerca s?-i înv?? acest mod de a scrie cod, dar nu eram atât de bun la instruirea oamenilor pe atunci. A fost o decizie con?tient? pentru binele proiectului. Am dou? moduri de a identifica avantajele ?i dezavantajele, astfel încât s? ob?ine?i software design mai bun. Ori de câte ori evalu?m solu?ii poten?iale pentru o problem?: List?m alternativele, avantajele ?i dezavantajele fiec?reia dintre ele ?i apoi facem o alegere con?tient? pentru una dintre solu?ii. Experiment?m: începem punerea în aplicare a uneia dintre solu?ii, fiind gata s? arunc?m sau s? schimb?m solu?ia dac? nu este destul de bun?. Acest proces nu trebuie s? ia mult timp. De obicei, o jum?tate de or? sunt mai mult decât suficiente pentru prima op?iune ?i maxim dou? ore pentru a doua. Dup? pu?in? practic?, vei începe s? faci aceasta în mod automat pentru cele mai multe decizii. Dac? exist? un lucru pe care îl po?i înv??a din aceast? lege, acesta ar trebui s? fie: Pentru a face software _design_mai bun, identific? avantajele ?i dezavantajele solu?iei pe care o alegi. Întrebarea de reflec?ie: Care sunt dezavantajele clasei la care lucrezi? Ce ar putea merge prost? 2. Programatorii sunt utilizatorii Software Design-ului Ori de câte ori vorbim despre design în alte domenii decât software-ul, discut?m din punct de vedere orientat c?tre utilizator. Produsele Apple sunt renumite pentru c? se concentreaz? pe experien?a unui utilizator cu dispozitivul lui: cum se simte, cum arat?, cât de repede r?spunde, sunetele pe care le face, etc. . Software design-ul este singurul tip de design care pare a nu avea utilizator. La urma urmei, utilizatorul final nu are nicio idee despre cum func?ioneaz? software-ul ?i nici nu-i pas?. Tot ce le pas? utilizatorilor finali este ca software-ul s? func?ioneze cum trebuie. Atunci de ce ar trebui s? ne pese de structura intern? a software-ului? Exist? motive economice foarte bune pentru a face acest lucru. În cazul în care software-ul nu este u?or de schimbat, dezvoltatorii nu vor putea ad?uga caracteristici rapid, ducând la o poten?ial? pierdere a clien?ilor. Atunci când structura software-ului nu este organizat? în mod corespunz?tor, ar putea s? apar? mai multe bug-uri care necesitând mai multe ore de s?pat prin cod pentru a le repara, ar cre?te costurile de între?inere. Acestea nu sunt probleme noi. Designurile ini?iale pentru multe obiecte pe care le folosim acum zilnic au început prin a fi slabe, dar au fost îmbun?t??ite în timp. Cum? Cheia st? în a asculta feedback-ul utilizatorilor. În echipa noastr?, Claudia lucreaz? full-time în timp ce eu lucrez part-time la un produs eHealth. În afar? de sarcinile mele de dezvoltare, ajut ca mentor, coach ?i o ajut cu decizii mai dificile. Una dintre întreb?rile mele recurente este: „Ce a fost greu de schimbat în ultimele dou? s?pt?mâni?”. Pe baza acestei întreb?ri, am îmbun?t??it viteza de modificare a codului în zonele unde se schimb? cel mai mult. Software design-ul are utilizator. Utilizatorul este dezvoltatorul care va trebui s? schimbe codul pe care îl scrii. Dac? folosi?i collective code ownership (ca majoritatea echipelor Scrum), ar fi bine s? lua?i în considerare user-centric software design (software design orientat c?tre utilizator). ?i iat? o idee pentru tine: ce zici despre rularea de teste de usability pe software design pentru a reduce costurile de dezvoltare? Pentru a face software design mai bun, analizeaz?-l din punctul de vedere al altor dezvoltatori. Întrebarea de reflec?ie: Care sunt unele dintre plângerile comune ale colegilor t?i de echip? legate de cod? Ce este dificil s? schimba?i? Cum ai putea s?-l faci mai u?or? 3. Numele conteaz? mult mai mult decât î?i imaginezi Software-ul este cunoa?tere executabil?. De exemplu, când scrii o aplica?ie de contabilitate, se codific? tot ce ?tii despre regulile ?i procedurile de contabilitate. Cum au ajuns aceste cuno?tin?e în aplica?ie? Prin preluarea acestora de la speciali?ti ?i trecerea prin creierul dezvoltatorilor pentru a le transforma în cod. O observa?ie aparte este c? cele dou? caracteristici care diferen?iaz? dezvoltatorii de restul lumii este c? ei în?eleg calculatoarele ?i pot gândi cu un nivel foarte ridicat de precizie. De aceea nu cred în programarea vizual? f?cut? de speciali?ti. Cum înva?? ?i î?i structureaz? cuno?tin?ele oamenii? Prin atribuirea de nume lucrurilor. Dac? te gânde?ti la anii de ?coal?, î?i aminte?ti de înv??area despre numere, opera?ii aritmetice, tabla înmul?irii etc..Acestea sunt doar nume date unor concepte, nume care ne ajut? s? comunic?m unul cu cel?lalt despre idei complexe. V? invit s? realiza?i urm?torul test. Scrie?i unele dintre numele claselor, metodelor ?i variabilelor din codul pe care lucra?i. Apoi nota?i-v? ceea ce face aplica?ia. Apoi num?ra?i câte dintre aceste nume corespund domeniului de aplicare. Sau întreba?i pe cineva care nu ?tie la ce lucra?i s? ghiceasc? ce face aplica?ia doar pe baza listei de nume. În cazul în care au ghicit, atunci v? rog s? m? contacta?i pentru c? vreau s? înv?? de la voi cum face?i. Acest test arat? o deconexiune tipic? între ceea ce aplica?ia face ?i cum î?i structureaz? dezvoltatorii cuno?tin?ele în cod. De ce este acest lucru r?u? Deoarece creierul trebuie s?-?i petreac? timp valoros încercând s? traduc? ceea ce cite?te c?tre ce face aplica?ia. Acest lucru duce la reducerea productivit??ii ?i te obose?te. Nu exist? în acest moment nici un mod definitiv pentru a elimina distan?a dintre cuno?tin?e ?i cod. Aceasta poate fi îns? redus? mult de iterarea prin continuumul numelor definit de JB Rainsberger. Un sfat: ve?i g?si c? este foarte dificil la început, dar devine mai u?or cu exerci?iu. Pentru a face software design mai bun, nume?te clasele, metodele ?i variabilele cât mai aproape de domeniul de business posibil. Întrebarea de reflec?ie: Ce face aplica?ia ta? Care sunt câteva nume specifice businessului? Sunt acestea prezente în cod? 4. Integritatea conceptual? este principiul pierdut pentru software design bun Acum 40 de ani, Fred Brooks a scris o carte pentru dezvoltarea de software numit „The Mythical Man Month”. Cartea con?ine multe constat?ri esen?iale despre dezvoltarea de software ?i inginerie pe care cei mai mul?i oameni care lucreaz? în industrie nu le ?tiu ?i nu le aplic? pentru c? nu au citit cartea. Cea mai important? idee de design din carte este urm?toarea: Voi sus?ine c? integritatea conceptual? este cel mai important aspect în proiectarea sistemului. Este mai bine s? avem un sistem care omite anumite caracteristici anormale ?i îmbun?t??iri, dar care reflect? un set de idei de design, decât de a avea unul care con?ine multe idei bune, dar independente ?i necoordonate. Fred Brooks, The Mythical Man Month Pagina wiki a lui Ward Cunningham pe aceast? tem? ofer? urm?toarele exemple de integritate conceptual?: Putem identifica exemple specifice, binecunoscute de Conceptual Integrity? V? prezint o list? de asemenea exemple specifice, care nu este definitiv?: Unix (bazat pe no?iunea de „dosar” (de exemplu, directoare, dispozitive, sisteme de fi?iere, cu named pipes ?i sockets sunt tot felul de fi?iere); Smalltalk („totul este un obiect”, ?i micul set de alte principii care îl înso?esc); SQL („toate datele se afl? în tabele”, cu chei ?i constrângeri Lisp („totul este o list?”); De ce este util? integritatea conceptual?? Probabil din cauza modului în care creierul nostru func?ioneaz?. Memoria omeneasc? de lucru se limiteaz? la p?strarea a patru articole în paralel, dar exist? o metod? de a o p?c?li: fiecare element poate fi de fapt un set de concepte înrudite (un a?a numit chunk). Când ai de luat decizii de design dificile, cu siguran?? ai nevoie s? iei în considerare mai mult de patru lucruri în acela?i timp. Ajut? dac? sunt similare, deoarece creierul poate s? le prelucreze, permi?ându-?i s? iei decizii mai informate de design. Integritatea conceptual? poate fi aplicat? la diferite niveluri, de la variabile, metode la clase. De exemplu, s? facem urm?torul test. Nota?i numele câtorva clase ?i numele tuturor metodelor lor publice. Arat? interfa?a clasei cuiva care nu ?tie la ce lucra?i ?i întreba?i ce face clasa respectiv?. Întreba?i-i dac? e ceva ce pare c? nu e la locul ei în acea clas?. Dac? ghicesc ?i totul se potrive?te, felicit?ri: a?i realizat integritate conceptual? la nivel de clas?. Acum face?i acela?i exerci?iu la nivel de namespace ?i modul (ar?tând doar interfa?a public? a modulului). La nivel de sistem, lucrurile devin tot mai complexe. Ports and adapters ?i microservices sunt unele dintre modelele care u?ureaz? integritatea conceptual? la nivel de sistem. Dar nici o solu?ie nu este perfect?, fiecare dintre ele are dezavantaje . Un avertisment: integritatea conceptual? este foarte greu de ob?inut, mai greu decât g?sirea de nume potrivite. Cu toate acestea, experien?a m-a înv??at c? atunci când reu?e?ti, integritatea conceptual? este nu numai foarte util?, dar ?i frumoas?. Într-o lume plin? de bug-uri ?i cod urât, frumuse?ea poate face minuni pentru moralul t?u. Pentru a face software design mai bun, str?duie?te-te s? ob?ii integritate conceptual? la nivel de clas?, namespace, modul ?i de sistem. Întrebarea de reflec?ie: Ce p?r?i din aplica?ie au integritate conceptual?? Alege o clas? la care lucrezi; cum o po?i aduce mai aproape de integritate conceptual?? Vrei s? înve?i mai multe despre software _design_?i arhitectur?? E?ti interesat de ultimele practici în industria de IT software precum: DevOps, Microservices, Technical Leadership, Technical Strategy, etc.? Vino pe 28 - 29 Mai, la I T.A.K.E. Unconference s? faci parte din comunitatea european? desoftware craftsmen ?i practicieni experimenta?i. Sursa: todaysoftmag.ro

NOTA* Jonathan Shieber este senior editor la TechCrunch ?i CrunchBase [intrebare]: Apple Watch va fi disponibil în curând; care este perspectiva ta asupra evolu?iei sale, dac? ne gândim la limit?rile sale actuale precum bateria de o zi, dependen?a de un iPhone, noile versiuni care îl vor face dep??it sau concuren?a cu ceasurile clasice? [Raspuns]: Chiar nu sunt persoana cea mai potrivit? pentru a formula o p?rere în leg?tur? cu iWatch de la Apple. Nu este punctul meu forte. Dar critica împotriva iWatch care spune c? este ceva inutil mi se pare corect?. Nu v?d o aplica?ie killer care m-ar putea convinge s? îmi iau unul, dar aceasta a fost ?i critica ini?ial? împotriva tabletei. De fiecare dat? când Apple lanseaz? un nou dispozitiv în ecosistem, oamenii pun la îndoial? utilitatea sa, ?i de fiecare dat? acesta devine, în cele din urm?, standardul implicit de aur în categoria sa. Acesta este unul dintre acele cazuri în care este mai bine s? a?tept?m ?i s? vedem. [intrebare]: Drept redactor ?ef la TechCrunch, ?i se trimit nout??i, iar interesul pentru aceasta este foarte mare. Ce sfat ai da unei persoane care are un startup ?i dore?te s? publice un articol în TechCrunch? Vreun eveniment important la care ar trebui s? participe? [Raspuns]: Am atins acest subiect în cadrul discu?iilor la masa rotund?. Fi?i conci?i, descrie?i punctul dureros pe care îl rezolv? tehnologia companiei, men?iona?i noutatea într-o propozi?ie, vorbi?i despre dimensiunea poten?ial? a oportunit??ii de pia?? ?i cerceta?i cine este reporterul potrivit pe care s? îl contacta?i. Odat? ce un antreprenor identific? reporterii potrivi?i pentru ?tirile pe care le anun??, ar trebui s? fie st?ruitor în contactarea acelor persoane. Începe?i procesul din timp. Dac? exist? reporteri pe care îi respecta?i, l?sa?i-le câteva rânduri ?i ar?ta?i-le asta. Dac? oamenii observ? cum ne facem datoria, atunci este mai probabil ca ?i noi s? observ?m ceea ce fac ei. [intrebare]: Este TechCrunch implicat activ într-un accelerator startup prin CrunchBase? [Raspuns]: TechCrunch nu este afiliat la niciun accelerator sau incubator. Exist? un fond ini?iat de c?tre fondatorul TechCrunch, Michael Arrington, numit CrunchFund, dar nu sunt sigur care este rela?ia dintre acel fond de investi?ii ?i TechCrunch (dintr-o perspectiv? institu?ional?). [intrebare]: Care este opinia ta sincer? în leg?tur? cu startup-urile din România? [Raspuns]: Talentul este abundent în România. Am întâlnit mai mul?i antreprenori pasiona?i care caut? s? înf?ptuiasc? idei interesante, dar ecosistemul este destul de tân?r în România ?i foarte imatur. Exist? o nevoie clar? de mai mult capital ?i mai mult talent opera?ional cu experien?? în dezvoltarea afacerilor. Sursa: todaysoftmag.ro

Eu inca nu am prins ideea dar de ce aveti asa ura pe Aerosol? Adica vad ca omu posteaza la stiri acolo. S-a injurat cu cineva pe aici?