„Norėdami tęsti, paspauskite bet kurį mygtuką“ - kam buvo sukurta ši kompiuterių keistenybė?

Bent jau pascal kalboje tai buvo vienas lengviausių būdų perimti vartotojo inputą - funkcija. C turėjo getchar() ir getc(stdin). Tokią funkciją tiesiog numeti bet kur, ir visas sprendimas. Realiai ankščiau daug programuotojai nesivargindavo, kad žmonėms būtų patogu, nes ne pensininkai ir angliakasiai prie kompų sėdėdavo. Pagrindinis dėmesys būdavo skirtas algoritmui, o ne vartotojo sąsajai. Dabar laikai kiti, ir dažnai sąsaja kuri prašo paspausti "OK" mygtuką užima šimtus eilučių kodo. O jei ne naudoja papildomą biblioteką tam, kuri užima tūkstančius eilučių kodo. Aišku galime sau tai leisti nes kompiuteriai nėra tokie lėti kaip tais laikais kai tik atsirado ekranai.

Jei tau atrodo, kad dabar interfeisas patogesnis - nematei enterprise lygio programinės įrangos. pigūs appsai po 1$ daromi patogiai, nes vartotojas jų nenaudos. Korporatyviniuose sprendimuose niekas nesivargina dėl to + pati logika sudėtinga. Tai išeina kažkokia painiava.

Visokių būna. Daug kas naudoja google docs. Kiti kas turi pinigų, nusiperka microsoft office, o tie kas turi proto naudoja Libreoffice. Bet kalbant apie programinę įrangą skirtą dirbti su specifiniais duomenimis, specifinėmis duombazėmis, tai taip įsivaizduoju, kad interfeisa gali būt užsilikę nuo praeito tūkstantmečio. Tam tikra prasme yra pigiau apmokinti žmones dirbti komplikuota programine įranga, nei tą įrangą padaryti patogesnę. Žmones ar šiap ar taip reikės mokinti, o programuoti labai patogius interfeisus užima daug laiko, ir varžo vėlesnių funkcijų kūrimą. Be to senesnės programos, be krūvos modernių UX sprendimų dažnai veikia greičiau, ir tai yra vienas iš tikslų, kai nori didinti darbo efektyvumą. Jei darbuotojas turės laiko atsidaryti facebook, kol programos interfeisas dirbs, tai jis gali per ilgai užsiskrūlinti tenai. Kita vertus tu gauni pinigus už tai kad dirbi "coorporate" programine įranga. Ir tu moki pinigus kad galėtum naudotis patogia programine įranga.

Kalba eina ne apie wordą, bet aukštesnio lygio sistemas - dokumentų valdymą (aka sharepoint sprendimus kuriuose gyvena tie dokumentai), visokias elektronines paslaugas, ypač iš institucijų pusės (epaslaugos, sodros portalai, elektroniai receptai) ir t.t. Kažka konkrečiau nebent pm papasakosiu na... korporatyviniai sprendimai turi reikalavimus, kuriuos reikia tenkinti, jeigu kažkas nereikalavo patogaus UI o tik galimybę atlikti darbą, dažniausiai tuo ir pasibaigia. Esu dirbęs prie ne vieno vidutinio/didelio projekto, tame tarpe visiškai naujo. Galutinio vartotojo poreikiai yra kažkelintoj vietoj. Svarbiausia biznio logika ir pakenčiama greitaveika. Klientas tam neskiria pinigų, o gamintojas - laiko. Yra kontraktai kas turi veikti ir valio. Šiuo atveji vartotojai - vidine sistema dirbantys įmonės darbuotojai, tai nėra civiliai klientai naudojantys sistemą. Ir visa tai +/- apibūdina situaciją dokumentų valdymo, sveikatos, transporto, telekomunikacijų sektoriuj. Beveik be išimčių. Aišku padaryti didelę sistemą jau savaime iššūkis. Padaryti didelę ir stabiliai veikiančia - pastangų reikalaujantis darbas. O jei dar nori patogios... Niekas neįperka tokio lygio personalo su projekto biudžetu Tuo pačiu į galutinius klientus orientuotos sistemos kažkaip sugeba būti naudotinis (banko portalai ir t.t.).

Kas galit parekomenduot online programavimo kursa arba knyga? Ketinu turet bishki laisvo laiko neuzilgo, gal reiketu tam isnaudot. As kazkiek kodinu, pagrinde C++ ir tam, kad butu galima is PC valdyt tai kas sukonstruota (ne, omenyje turiu ne arduino). Su algoritmu logika ir su sintakse viskas gal ir OK. Problema ta, kad mano kodinimas greiciau yra monkey see monkey do, as neturiu supratimo kaip turi but daroma tvarkingai, kaip kodint kad veiktu stabiliai ir t.t. I programuotojus nei dabar nei po to kandidatuot neketinu lyg ir, tiesiog noretusi turet bent koki supratima kaip turi atrodyt normalus kodas, kas yra gera praktika ir t.t.

O ką konkrečiai nori daryt? Gali viską daryti su C arba C++, bet kiekvienam dalykui yra geriausiai tinkanti aukštesnio lygio programavimo kalba. Jei nori kažką automatizuoti visada patogiau dirbti su interpretuojamom kalbom.

Visu pirma noriu turet daugiau ziniu nei turiu dabar turbut... ir gal turet ju bent tiek, kad savo koda negeda kam nors parodyt butu, jei kada prisireiks. C++ naudoju aplinkybiu priverstas, visokie sensoriu, servo kontroleriai, testavimo iranga dazniausiai turi C++ library, puse tik C++. Kazka esu viena ausim girdejes, kad cia ne visada geriausias pasirinkimas. Viena ausim esu girdejes ir kuo skiriasi interpretuojama ir kompiliuojama kalbos. Kiek suprantu, interpretuojama labiau pritaikyta konkreciam tikslui, letesne. Man tas nera labai patrauklu, mano situacijoj kuo universaliau ir greiciau tuo geriau. Kad iliustruot koks mazdaug mano taskas, siuo metu salia lovos turiu (vieta kur as paprastai "gyvenu" nuo 8 iki 5 uzdaryta jau kelis menesius, atidarys gal rugseji, jei covid neisisiautes): Endoskopo sviesos saltini Judesio sekimo kamera Toki CCS sensoriu, su kontroleriu Signalu generatoriu Osciloskopa Visi programuojami/duomenys loginami skaitmeniu budu, visi turi nors C++ library. Iskyrus judesio sekimo kamera, nei vienas nenaudojamas pagal pirmine paskirti:) Paprastai prie sito bardako priklauso dar 3-5 servo, keli atskiri encoderiai ir t.t.(likes hardas per sunkus ir uzima per daug vietos kad parsitempciau namo). Viskas veikia vienoj dalinai automatizuotoj sistemoj. Sistema custom, pirma ir greiciausiai paskutine. Mano taskas yra kad visa tai veiktu kaip as noriu, logintu duomenis kuriu man reikia, skaiciuotu visokias dinamikas kinematikas, interpoliuotu, kad butu galima valdyt is klavos, kalibruot, keist parametrus ir t.t. Siaip viskas veikia, bet mazai vilties, kad as, neturedamas net baziniu ziniu (paskutinis kodas kuri rasiau pries sita buvo turbo Paskaly, vidurinej mokykloj, daug metu atgal) visa tai darau kaip priklauso. Pats esu kitos srities inzinierius, tai zinau puikiai, kad tarp "siaip taip funkcionuoja" ir "padaryta kaip priklauso" yra didelis skirtumas. Tai as noreciau bent suprast, kas pas mano programinime yra tinkama praktika, o kas - kolhozinimas. To kas jau sukodinta as keist neketinu, bet ateity noreciau turet apie tai supratima.

. Nėra nieko geriau, o savadarbiai sprendimai dažnai turi visas tris problema kurias gettext sprendžia - veikia lėtai, nepalaiko skirtingų daugiskaitos formų, yra nepatogūs versti. Sakyčiau čia yra pagrindiniai dalykai. Visa kita jau kalbos niuansai. Pythonas tave verčia rašyti gražų kodą, nes jis kitaip neveikia. Ruby verčia tave kurti kodą taip kaip kuria kiti nes tokia jo filosofija (praktiškai religija). PHP yra visiškas bardakas, ir jame gerą kodą parašyti yra sunkiausia. Kai dirbi su C/C++ gerą kodą sunku parašyti, nes ne visada panaudosi geriausią algoritmą. Dėl to kartais viena integruota php funkcija geriau veiks, nei neoptimalus algoritmas parašytas su C. Kol įsigilini į funkciją kurią darai, ir randi visas alternatyvas, ir išsirenki geriausią, tavo kodas bus geras.

skamba pazystamai. Maza dali is to ka parasei esu girdejes, kai ka uzteko ziniu suprast, likusia dali pagooglinsiu. Dekui, kad nepatingejai parasyt, bandysiu gilintis ir vadovautis.

Dar vienas pastebėjimas gero programavimo: netikėk kitais programuotojais. Ne karto teko skaityti komentarus kuriuose yra ginčijamasi ar "tas dalykas" yra gerai ar blogai. Pav.: buvo ginčas, ar galima naudoti "unsignet int" ar geriau visur naudoti "int". Kai kas net kratosi pamatęs "unsignet int", kitas programuotojas kaip tik jį dažnai naudoja. Mano nuomone "unsignet int" yra įrankis tinkantis tam tikram darbui. Jei tu juo nemoki naudotis tai nėra įrankio problema. Dažnai net nėra realaus skirtumo ar tu naudosi "int" ar "unsignet int". Viskas priklauso nuo konkrečios situacijos, o ne nuo įrankio. Bet ginčai čia nesustojantys ir be atsakymo.

, kuri atsiranda dėl signed int 32 naudojimo. Dėl to 2038 metų sausio devynioliktą dieną prasideda 1901 metų gruodžio trylikta. Tai atsitinka dėl "integer overflow", kuris pasikeičia į pačia ankščiausią datą, kurią galima išsaugoti 32 bitų singned integeriu. Taigi šiuo atveju norint padaryti kompiuterius ilgiau veikiančius būtų gerai tą integerį pakeisti į unsigned, bet tada ankčiausia data kurią galime aprašyti bus 1970 sausio pirma. Taigi abu variantai gana absurdiški, bet unsigned ilgiau veiks (iki 2106 vasario), ir kai kas tai gali naudoti kaip sprendimą. Labiau verta pereiti prie 64 bitų integerio. Bet šiuo atveju net neverta žiūrėti į unsigned, nes tai būtų gana kvailas sprendimas - datas galėtum aprašyti tik nuo 1970 metų, nors ir labai toli į ateitį. Jei turi signed 64 bitų integerį, gali aprašyti datas senesnes nei spėjamas visatos amžius, ir tokias kurių saulės sistema neišgyvens. Taigi to kaip ir užtenka. Kitas dalykas yra kai tu sukuri sistemą su produktais, ir produktai turi savo ID, kas yra skaitinė reikšmė. Tokiu atveju aš visom keturiom esu už unsigned, nes neigiamų nenaudoji, ir gauni dvigubai daugiau skaičių saugoti produkto ID. Bet visgi nesuprantu kaip dėl to galima ginčytis. Situacija diktuoja ko tau reikia. Aišku tie kas nesupranta skirtumo, jiems geriau rašyti tik "int", kas standartiškai turi ženklą. Nors mano nuomone, jei nesupranti tokio skirtumo, naudok aukšto lygio kalbą, kuri įvertina tai ką tu darai, ir pataiso tavo klaidas. Pvz PHP susikuri bet kokį kintamąjį, grūdi į jį ką nori, kiek nori. Svarbu php konfigūracijos parametro "memory_limit" neviršyji.

coursera neblogas python kursas yra. Šiuo metu rekomenduočiau mokytis programuoti būtent pytonu, be rimtų argumentų,tiesiog mano tokia nuomuonė. Pakankamai lankstus, funkcionalus ir tuo pačiu paprastas. clean code - klasikinė knyga, kurią perskaitęs ar šiaip pavartęs pradėsi rašyti truputį gražesnį kodą. Turbūt verta paskaityti, nepaisant kokia kalba programuoji. taip pat siūlyčiau paskaityti kažką apie testavimą, ypač test driven development. Jeigu atrodo perdaug sudėtinga, gal tada ir neskaityk, nežinau koks tavo programavimo lygis. Bet gyvenimą tai palengvina. Pvz: https://books.google.se/books/about/Tes ... edir_esc=y Jeigu trumpai, tai iš kur žinai, kad veikia, ką parašei? TDD nors ir atrodo sudėtinga, bet labai labia paspartina darbo procesą, kai įvaldai mąstymą. Ypač lengva bus pereiti, jeigu dirbi prie projekto vienas, be kolegų. Sakai bibliotekos C/C++? Nežinau ką tiksliai darai, kaip pavizdį paimsiu arduino. Arduino gali susiprogramuoti su C, pasijungti visus sensorius ir t.t., tada paleisti duomenis per UART protokolą į kompą, o kompe tavęs niekas nebeverčia naudoti C. Gali imti python ir ateinančius duomenis interpretuoti, analizuoti. C palik tik tai daliai, kur tikrai jos reikia. ai dar aip conjurer rašė, GIT yra privaloma. Kažkaip net nepagalvojau apie galimybę gyventi be jo. Tiesa intelliJ (JAVA redaktorius) turiu vietinę įstoriją, bet GIT`as (mercurial, SVN, CVS) yra gėris, ypač kol mokaisi.

Kiek aš pastebėjau, su unsigned dažniausiai problemų bando rasti tie kas į c++ ateina iš c kalbos, nes c kalboje yra įprasta apie klaidas informuoti neigiamais skaičiais. Pav. jei funkcija turi gražinti kažkieno dydi, o dydis visados bus teigiamas skaičius, tai tada gražina neigiamus skaičius jei negali gražinti dydžio. Todėl jie praktiškai nenaudoja unsigned ir nėra įpratę jo naudoti ir jei jų paklausi apie gera programavimą jie visais dievais prisiekinės kad negalima naudoti unsigned. Bet skirtingai nuo c kalbos c++ turi Exception klase pranešimams apie klaidas, bet dauguma ateinančių iš c kalbos nemoka ir dėl to nenori jos naudoti. Ne karta mačiau blogų kuriuose teigia, kad Exception naudojimas yra blogas programavimo stilius arba šiaip yra blogis. Dabar baigiau žiūrėti šituos video apie taip pat daugiau stiliaus reikalas, bet labai dažnai C++ bibliotekos naudoja .h, o ne .hpp

.

Nuo 26 iki 31 sekundės, vienas geriausių patarimų tiem kas mokinasi programuoti:

šiaip pagrindinis dalykas su progarmavimu, tai reikia skirti kažkiek valandų, kad persilaužti su mąstymu. Vieniem bus greičiau, kitiem lėčiau, bet visiem +/- tos pačios problemos iškyla. Bent man taip pasirodė, kai žmona bandė truputį programuoti pytonu neseniai ir erzinosi lygiai tose pačiose vietose kaip aš vaikystėje su paskaliu. Įvedimas išvedimas, kelių matmenų masyvai ir t.t. Taigi nebijok, jei nesiseka. Jeigu tęsi, tai kas sunku šiandien bus lengva po mėnesio.

Matai, jei jau kazkas, ka turi sistemoj turi gamintojo kontroleri ir biblioteka jam, tai kazin, ar tai bus daiktas, kuri tiesiog gali pajungt prie kazko panasaus i arduino ir isnaudot visa jo funcionaluma:) Jei ir galesi, tai jauciu nebus lengviau nei kontroliuot tiesiai is PC. Plius, toks (PC-PLC-PLC+sensorius?) komponavimas apsunkina to pacio kontroles kodo modifikavima, daug patogiau kai viskas yra vienoj vietoj. Aisku, jei naudosi koki prietaiseli, su tarkim, analoginiu outputu ar kokiu I2C, tai nelabai kas daugiau ir lieka nei taip daryt. Kalbant apie tavo pavyzdyje minima arduino... Kaip ir didzioji dalis musu turbut su juo as pazaidziau kuri laika, net naudojau kokius pirmus puse metu manipuliatoriaus kontrolei. Mano manymu didziausias jo trukumas yra debugerio nebuvimas. Antras pagal diduma - UART su savo 5Mbps greiciu, labai daug kam to tikrai neuzteks. Rezultate as jo atsisakiau ir gerai padariau, gavosi greiciau, patikimiau, modifikavimas patogesnis, maziau laidu, jungciu ir t.t. Plius ismokau kazko naujo.

Tavo atveju kai naudoji Visual studio, ir kodo su niekuo nesidalinsi, tik exe failą, makefile yra beprasmis. Jis reikalingas tada kai nori dalintis kodą, nes ne visi turi prabangą pirktis brangius kodinimo toolsus. Kol univeras duoda licenciją, ar nusipiratauji asmeniniam naudojimui viskas pakenčiama, bet kai dirbi įmonėje, kartais būna per brangu naudotis mokamu softu, ypač kai yra nemokamos alternatyvos. Make file veikimas yra paprastas. Tu nueinį į katalogą kuriame yra kodas, ir parašai "make". Komanda "make" susiranda "makefile" failą, ir vykdo standartinį scenarijų. Gali apsirašyti papildomus scenarijus. Dažnai būna aprašoma "clean" scenarijus, kuris išvalo ".o" failus. Linuxe beveik visos programos kurios yra kompiliuojamos iš kodo, susikompiliuoja tokius principu. Parašai "make" - sukompiliuoja kodą, parašai "make install" - įdeda sukompiliuotus failus ten kur jie turi būti. Bet čia yra linuxų dalykas, jei naudoji windows, to nelabai turi. Realiai tavo visual studio išsaugotas projektas turi kažkokią alternatyvą to makefile.

Radau C++ kalbos vietą kurioje 90% programuotojų "klysta". Tai yra pointeriai. Pointeriai turi tris užrašymo stilius. 1) int* p1; 2) int *p2; 3) int * p3; Didžioji dauguma naudoja 1 stilių (bent aš internete mačiau dažniausiai šį stilių), bet šis stilius iš visu trijų stilių yra pats neteisingiausias. Pirmu atvejų atrodo, kad čia yra užrašytas kad kuriamas int tipo poineris, bet taip nėra. Pav.: dažnai vienoje eilutėje yra sukuriamas ne vienas to pačio tipo kintamasis. 1. int p1, p2, p3, p4; Šiame užrašyme visi kintamieji yra int tipo. Bet kas bus jei bandysime taip sukurti pointerius? 2. int* p1, p2, p3, p4; Naujokas galvos kad visi kintamieji yra int tipo pointeriai, bet ištiesų tik p1 yra pointeris. p2, p3, ir p4 yra paprasti int tipo kintamieji, o ne pointeriai. Norint kad visi kintamieji butu pointeriai reikia rašyti taip: 3. int* p1, *p2, *p3, *p4; Man šitoks užrašymas negražiai atrodo. Kodėl p1 be žvaigždutės, kai visi kiti su žvaigždutėmis? Nevienodas stilius vienoje eilutėje. Bei šitas pavyzdys rodo kad žvaigždutė ir int neturi jokio ryšio ir žvaigždutė nepriklauso prie int. Jį yra kintamojo dalis. Todėl geriau butu užrašyti šitaip. 4. int *p1, *p2, *p3, *p4; Todėl antras stilius yra tikslesnis nei pirmasis, bet jis taip pat nėra tikslus. Kintamasis turi viena kintama savybę, tai yra kintamojo reikšmė. Kaip rašiau pradžioje pirmasis stilius yra netinkamas, nes juo negalime vienodai aprašyti dviejų ir daugiau pointerių. Todėl čia apie jį daugiau nerašysiu ir dėl to naudosiu "int const" užrašymą. p1 ir p2 pointerius galima užrašyti tiek antru, tiek trečių stiliumi, bet p3 ir p4 galima užrašyti tik trečių stiliumi. Išvados: 1) Pirmas stilius netinka nes juo negali aprašyti daugiau nei vieno kintamojo vienoje eilutėje ir žvaigždutė neturi nieko bendro su informacijos tipu. 2) Antras stilius netinka nes su juo nepadarysi pointerio kad butu galima pakeisti pointerio adresą. 3) Tik trečias stilius tinka visais atvejais. Bet kažkodėl dažniausiai naudojamas pirmasis stilius, nors jis mažiausiai tikslus ir pradedančiuosius klaidinantis. Tai rodo, kad net profesionalus programuotojas ne visada gali išmokinti teisingai. Žinoma, jis vis tiek išmokins geriau nei pats išmoksi iš knygų ar interneto.