Ieškoma

Cron geriausios praktikos

Praleidęs daugiu nei 10 metų administruodamas serverius ir įrangą juose nusprendžiau pasidalinti patirtimi ir geriausiomis praktikomis kaip administruoti Cron darbus. Periodinių užduočių valdymo sistema - Cron - viena populiariausių programinių įrangų Linux sistemose. Apie ją turėti žinoti kiekvienas IT srityje dirbantis žmogus. Sunkiai rastume projektą kuris kaip nors išgyventų be periodinių užduočių: el. laiškų siuntimo, naujienlaiškių siuntimo, laiškų tikrinimo, duomenų generavimo, duomenų importavimo, duomenų siuntimo ar kito darbo su trečiųjų šalių sistemomis (tarkime API). Išmokti valdyti Cron nėra sudėtinga, o žinios, kuriomis pasidalinsiu, galėtų padėti išvengti dažnai pasitaikančių bėdų ar nesusipratimų. Susipažinkime kas yra Cron Cron yra paprasčiausia programa (demonas, jeigu tiksliau) kuris nuolat veikia operacinėje sistemoje ir laukia nurodyto laiko kada bus galima pavykdyti komandą. Labai svarbu pabrėžti, kad Cron yra tik programinė įranga. Tai nėra operacinės sistemos dalis. Dėl to, kad tai tik programa, ją galima išdiegti (apt uninstall cron) arba jos vietoje įdiegti kitą periodinių užduočių valdymo programą. Programų / konkurenčių yra tikra gausybė. Bet šis straipsnis nebus apie tai. Kaip pavyzdys - jeigu parašėte programą, kuri patikrina elektroninius laiškus ir jeigu yra naujų - apie tai informuoja savininką SMS žinute, tai Cron yra būtent tai ko Jums reikia. Tokiu atveju greičiausiai norėsite, kad programa veiktų tarkime kas 15 minučių. Būtent Cron ir bus ta sistema kuri paleis komandą nurodytu intervalu. Cron konfigūravimo pradžia Iš esmės viskas ko reikia, tai pavykdyti redagavimo komandą crontab -e, nustatyti laiką kada komanda turi būti vykdoma ir įrašyti komandos aprašą. Tipiškai po šios komandos įvykdymo atsidaro tekstų redaktorius (nano arba vim) kuriame rašysite kažką panašaus: * 0 * * * komanda Pirmi penki skaičiukai reiškia laiką kada vykdyti komandą: minutės (0 - 59), valandos (0 - 23), mėnesio diena (1-31), mėnuo (1 - 12) ir savaitės diena (0 - 7, kur tiek 0 tiek 7 reiškia sekmadienį). Tokios laiko konfigūracijos užtenka suplanuoti užduotį pavykdyti praktiškai bet kada. Žemiau keli praktiniai konfigūravimo pavyzdžiai. Importuoti prekes iš kitos sistemos penkios minutės po vidurnakčio: 5 0 * * * importuoti-prekes. Kiekvieno mėnesio dešimtą dieną ir 9:45 min. išsiųsti algalapius: 45 9 10 * * siusti-algalapius Sudėtingesnius laiko intervalus nurodyti taip pat galima. Pavyzdžiui kiekvieną pirmadienį 9 ryto tikrink ar „įkrito“ naujas užsakymas kas 5 minutes: */5 9 * * 1 kur-uzsakymai Kas pusvalandį išsiųsk šimtą naujienlaiškių (kiekvieną penkioliktą ir keturiasdešimt penktą minutę): 15,45 * * * siusk-100-naujienlaiskiu Arba tik darbo metu tikrink ar yra pranešimų iš klientų kas penkiolika minučių: */15 8-17 * * * ar-yra-laisku O jeigu leidžiate darbuotojams atsikvėpti ir jie gali per pietų pertraukas nedirbti, tai: */15 8-12,13-17 * * * ar-yra-laisku Daug kas nežino, tačiau žvaigždutė Cron nėra reikšmė „visada“. Žvaigždutė reiškia intervalą nuo mažiausios iki didžiausios reikšmės. Tarkime žvaigždutė (*) minutėse reikštų 0-59 intervalą. Cron sintaksė Tuščios eilutės, be reikalo palikti tarpai ir tabuliacijos ženklai yra ignoruojami. Todėl jų galite palikti kiek tik norite. Todėl dvi eilutės žemiau darys lygiai tą patį: */5 9 * * 1 kur-uzsakymai */5 9 * * 1 kur-uzsakymai Geriau tuo nepiktnaudžiauti, o pasinaudoti praktiškesniu būdu tvarkingai komentuojant savo aprašus: # minutės valandos diena mėnuo sav. diena komanda */5 9 * * 1 kur-uzsakymai Kai turėsite labai daug eilučių - tikrai pravers. Cron trumpiniai Standartinis Cron taip pat duoda galimybę naudoti trumpinius, kurie yra labai patogūs tais atvejais, kada nereikia itin didelio tikslumo: @hourly, @daily, @weekly, @monthly, @annually, @yearly. Tarkime kasdien komandą galima sutrumpinti su @daily (abi eilutės darys tą patį): 0 0 * * * komanda @daily komanda Cron trumpinys - @reboot Yra dar specialus trumpinys @reboot - komanda bus įvykdyta tik vieną kartą po mašinos įjungimo. Tai gali būti naudinga paleisti kokius servisus ar pranešimus tik kartą. Arba jeigu neturi disciplinos - @reboot sleep 8h && poweroff - kompiuterį išjungti po 8 valandų darbo. Specialūs Cron simboliai Nors komandos pavadinimą gali sudaryti bet kokie simboliai, labai svarbu žinoti, kad paprastai procentų simbolio naudoti negalite (%). Prieš jį naudojant reikia pasvirojo brūkšnelio \ simbolio. Šis simbolis Cron atitinka naujos eilutės simbolį. Ši problema gali lengvai atsirasti jeigu naudojate date komandą, pvz: @daily siusti-naujienlaiski > $(date '+%F').log Tokią komandą Cron nukirps, ir ji taps: @daily siusti-naujienlaiski > $(date ' Ir nesuveiks. Žemiau komanda darys ką Jūs norite: @daily siusti-naujienlaiski > $(date '+\%F').log Komentarai Visada šaunu savo Cron įrašuose palikti komentarus. Juos galite palikti eilutę pradėję su # simboliu: # Siunčia reklamą kas savaitę @weekly siusti-naujienlaiski Verta žinoti, kad komentarų, priešingai nei programavimo kalbose, negalima niekur kitur rašyti. Pavyzdžiui žemiau esanti eilutė neveiks: @weekly siusti-naujienlaiski # Siunčia reklamą kas savaitę (ši eilutė neteisinga) Cron komandų vykdymo laikai žmonių kalba Pradedančiąjam gali būti sunku konfigūruoti Cron laikus. Laimei, yra įrankių internete, kurie gali konvertuoti į žmonių kalbą Cron išraiškas (jeigu tiksliau - į anglų kalbą): www.freeformatter.com/cron-expression-generator-quartz.html. Cron standartinė aplinka Cron visada savo komandas pradeda su /bin/sh aplinka. Kas čia yra gerai, kad taip taupoma atmintis ir greitis. Antras didžiulis privalumas - sh yra visose Linux sistemose. Todėl Jūsų komandos tikrai veiks visur. Kas blogai, kad tikrai ne kartą susidursite, jog kažkokia komanda neveiks, nes greičiausiai tikitės kažko daugiau nei sh gali pasiūlyti. Juk /bin/bash yra naujesnė sh versija. Skirtumų tarp sh ir bash yra labai daug. Dėl įdomumo tik kelis galima paminėti: sh neturi masyvų. Daugelis tipinių bash komandų neveiks: source, function, let, declare… Išvesties palaikymas su <<<SKYRIUS Ir daug daugiau. Todėl jeigu reikia Cron skriptuose bash aplinkos, galite įjungti ją visoms komandoms: SHELL=/bin/bash # Siunčia reklamą kas savaitę @weekly siusti-naujienlaiski Prieš ir po lygybės simbolio (=) gali būti tarpai. Deja tik keletas aplinkos kintamųjų šioje aplinkoje leidžiami: LOGNAME (prisijungusiojo vardas), HOME (kelias iki namų katalogo), SHELL (aplinka kurią ką tik nagrinėjome), MAILTO (skaitykite skyrių žemiau). Laiškai apie klaidas - MAILTO Greičiausias būdas gauti pranešimus kai kažkas blogai sistemoje - registruoti paštą su aplinkos kintamuoju MAILTO: MAILTO=klaidos@example.com @weekly siusti-naujienlaiski Čia reikėtų žinoti du dalykus. Be jokios konfigūracijos ir be jokio MAILTO= sakinio, Cron visas išvestis išsiųs Cron komandų savininkui (tam kas sukūrė / įrašė komandas). Išsiųsti laiškus į „išorę“ galima tik jeigu sistemoje yra įdiegtas ir sukonfigūruotas toks siuntimas (smtp). Komandų standartinis žurnalas Visos komandos kurios bus paleistos galima rasti standartiniame syslog žurnale: grep CRON /var/log/syslog Išvestis bus kažkas panašaus į tai: Feb 12 13:17:01 server CRON[8029]: (root) CMD (cd / && run-parts --report /etc/cron.hourly) Feb 12 13:30:01 server CRON[8292]: (root) CMD (docker exec -i grafikas-prod-web python manage.py send_pending_replacement_alerts) Feb 12 13:45:02 server CRON[11724]: (root) CMD (docker exec -i grafikas-prod-web python manage.py send_email_about_coming_duties) Deja, iš žurnalo bus ne tiek ir daug naudos. Matysite kada komanda buvo paleista, koks naudotojas paleido (šiame pavyzdyje root) ir kokia komanda paleista. Komandų išvesties žurnalas Tai dalykas kuriuo teks pasirūpinti patiems. Cron nuostabus įrankis, tačiau didelę bėdą Cron atneša, kada reikia aiškintis kas įvyko konkrečiai. Komanda gal ir buvo paleista norėtu laiku, bet ar ji padarė būtent tai ko norėjote? Tipinė Cron eilutė (su crontab -l pagalba) iš mano serverių: @daily /siusti-naujienlaiski >> /logs/siusti-naujienlaiski.$(date '+\%F').log 2>&1 Iš pavadinimų bus aišku, kad: Komanda paleidžiama kiekvieną dieną (@daily). Komanda siunčia naujienlaiškį (/siusti-naujienlaiski). Visada verta laikyti žurnalą ir jį pildyti. Dėl to naudojamas peradresavimas su >> kuris sukuria naują žurnalo failą jeigu jo nėra arba papildo egzistuojantį žurnalą / failą. Žurnalas su komandos išvestimis bus pildomas į /logs/siusti-naujienlaiski.2019-01-01.log failą (failo vardo pavyzdys su data). Taip bus išsaugoma visa, su komanda susijusi, istorija: dienos data ir komandos išvestis. O su logrotate pagalba tokius failus galima automatiškai archyvuoti. Pavyzdžiui paliekant tik paskutinius 7 žurnalus ar pan. Asmeniškai aš žurnalus dar ir saugoju į atsarginių kopijų diską. Šią informaciją tikrai versta saugoti - kas jeigu paaiškėtų, kad Cron komanda (šiuo atveju /siusti-naujienlaiski) veikė nekorektiškai jau kurį laiką? Žurnalų failas būtų viena iš vietų kur galima būtų tikrinti pasekmes. Būtina tiek stdout tiek stderr išvestis nukreipti į tą patį failą su 2>&1 komandos gale - kad žurnale būtų įrašas jeigu įvyko kokios problemos. Nenurodžius 2>&1 klaidos bus pristatomos į Linux naudotojo paskyrą su kuria vykdoma Cron komanda. Todėl patogu nurodyti administratoriaus el. pašto adresą (tikrą) jeigu sistemoje yra įdiegtas SMTP. Tą galima padaryti su MAILTO apie kurį rašiau anksčiau. Laiko juosta žurnaluose Jeigu sistema sukonfigūruota kažkokiai laiko juostai (arba tiesiog standartiškai UTC) ir neturite galimybių pakeisti jos operacinėje sistemoje, gali būti pravartu panaudoti CRON_TZ aplinkos kintamąjį. Cron gerbs laiko nustatymą ir tas laikas bus matomas žurnale. Tai gali būti labai svarbu, jeigu sistemos laiko juosta yra UTC, o Jūsų paties juosta yra Lietuvos, tai žurnaluose turėsite 2-3 valandų skirtumą priklausomai nuo to kaip pasuktas/atsuktas laikrodis tam sezonui. Laiko juostų vardus Linux sistemose sužinoti galima su komanda timedatectl list-timezones. Lietuvos laiko juosta apsirašytų: Europe/Vilnius. Gerai ir tai, kad sistema sureaguos į valandų pasukimus / atsukimus ir nieko papildomai konfigūruoti nereikės. Komandų išvesties žurnalas (2 dalis) Praeitame skyriuje minėtas žurnalų kūrimas patogus tik tada, kai galite sau leisti žurnalus įrašinėti į diską ir turite laiko sukonfigūruoti logrotate, kad tie žurnalai neužimtų disko vietos. Disko vieta ypač svarbus kriterijus kuriant mikroservisus. Todėl jeigu norite komandų išvestį registruoti tame pačiame syslog faile, tuomet padės komanda logger: @hourly tikrinti-pasta 2>&1 | logger Visas komandų klaidas rasite /var/log/syslog. O Linux, be jokių konfigūracijų rotuos tą failą ir taip neužkimšite disko vietos. Kur nutrūko bash skriptas? Jeigu esate bash mylėtojas kaip aš, tai greičiausiai ne viena Jūsų komanda bus bash skriptas. Deja, kartais neaišku kas su skriptu negerai atsitiko ir kur/kodėl jis nutrūko. Laimei, kiekvieną įvykdytą eilutę galima atspausdinti į išvestį jeigu skriptas turės set -x nustatymą skripto pirmose eilutėse. Pavyzdžiui: #!/bin/bash set -x echo Testas | mail -s "Laiško tesstas" dev@example.com Savo žurnaluose pamatysite eilutes kurios buvo vykdomos: + echo Testas + mail -s 'Laiško tesstas' dev@example.com Taip galėsite greičiau atsekti kur programa nutrūko. Komandų žudymas Cron konfigūravimas iš esmės turi du iššūkius - žurnalų laikymą (rašiau apie tai aukščiau) ir komandų vykdymo „perlipimus“. Kad viena komanda neprasidėtų kai kita dar nebaigė darbo, būtina nustatyti rėžius ir „užmušti“ komandų procesus jeigu komanda nespėjo padaryti savo darbo. Praktikoje tai dažniausiai sutinkama su naujienlaiškių siuntimais. Tarkime kas 2 minutes siunčiate 100 el. laiškų. Cron aprašas galėtų būti toks: */2 * * * * siusti-naujienlaisius Ir kaip dažnai atsitinka, kad komanda nespėja užbaigti savo darbo per planuojamą laiką. Tarkime praktikoje išsiųsti 100 laiškų per 2 minutes neturėtų būti problema ir dažnu atveju tai veiks. Tačiau bus dienų kai viskas veiks daug lėčiau arba pasieksite kažkokius el. laiškų siuntimo limitus kurie neleis per 2 minutes tiek išsiųsti. Todėl jeigu parašyta komanda neužtikrina „persipynimo“ ir dvi komandos įvykdytos vienu metu sudubliuos darbą - greičiausiai papulsite į bėdą. Čia nesusipratimų išvengti padės timeout komanda, kuri irgi dažnai randama tarp standartiškai įdiegtų Linux komandų. Naudojimosi aprašas būtų toks: timeout LAIKAS KOMANDA. Pavyzdžiui: timeout 2m siusti-naujienlaiski. Cron apraše tai atrodytų taip: */2 * * * * timeout 2m siusti-naujienlaisius Naudojantis timeout reikia žinoti, kad sistemos žurnale syslog rasite eilutę kuri pasakys, kad Cron komanda buvo nutraukta. Iš patirties rekomenduočiau nenustatinėti timeout ir Cron reikšmių santykiu 1:1. Nes jeigu komanda vykdo kažką kas stipriai apkrauna CPU (tarkime iš kitos sistemos importuoja didelį srautą duomenų), tai nužudžius komandą ir vėl paleidus CPU vėl turės dirbti dideliais apkrovimais dar nespėjus tvarkingai išsivalyti savo atmintį ar Swap. Turbūt geriausias variantas būtų turėti kažką panašaus: */5 * * * * timeout 2m siusti-naujienlaisius O pritaikius skyrių apie žurnalus: */5 * * * * timeout 2m siusti-naujienlaisius >> /logs/siusti-naujienlaiskius.$(date '+\%F').log 2>&1 Cron savininkas Geriausiai būtų, kad savo komandų neaprašinėtumėte kaip root (tarkime sudo crontab -e), nes taip sudarysite tikrai daug sąlygų saugumo spragoms atsirasti. Tarkime jeigu Cron aprašas root naudotojo paskyroje yra toks: @hourly /usr/bin/siusti-naujienlaiski Tai užtektų kam nors rašymo teisių į /usr/bin/siusti-naujienlaiski ir viskas, šis žmogus galėtų lengvai pats tapti root naudotoju. O tada - galėtų prieiti prie visko sistemoje. Taigi visada Cron aprašinėkite su paprasto naudotoju ir nenaudokite jokių sudo (nei komandoms aprašuose, nei paties Cron neredaguokite). Cron atmintinė Tikiuosi straipsnis buvo naudingas. Jeigu reikėtų atmintinę parašyti („špargalkę“), tai atrodytų taip: # Failas redaguojamas su: crontab -e # Standartinis `sh` pakeičiamas į `bash` nes reikia spec. funkcijos `source` SHELL = /bin/bash # Naudoti lietuvišką laiko juostą CRON_TZ = Europe/Vilnius # Apie nesėkmes siųsti laišką sistemų administratoriui MAILTO = dev@domenas.lt # Importuoti prekes kartą į dieną (bet kada) @daily importuoti-prekes # Siųsti savaitės naujienlaiškį kiekvieno mėnesio pirmą dieną, o # visus gavėjus išsaugoti /var/log/syslog faile * * 1 * * siusti-savaitini-naujienlaiski | logger # Tikrinti ar yra naujų užsakymų darbo laiku *, 8-12,13-17 * * * ar-yra-uzsakymu > /logs/uzsakymai.log 2>&1 # Paleisti Django komandą dėl kurios reikia bash @hourly source .virtualenv/bin/activate && python manage.py siusti-naujienas Jeigu patys naudojate Cron alternatyvas (anacron, fcron, hcron ar kažką kito) - būtų smalsu sužinoti dėl ko juos naudojate.

Pomodoro technika ir patirtis po 7+ metų naudojimo

2012 metais pirmą kartą perskaičiau apie Pomodoro techniką. Tais laikais, lyginant su dabar, technika tikrai nebuvo populiari. Ir žmonių rašančių apie tai buvo vienetai. Kadangi esu mėgėjas visokių straipsnių / knygų / seminarų apie produktyvumą - nekantravau išbandyti. Dabar, panaudojus daugiau nei 7 metus dažnai norisi su kitais pasidalinti, kad tai yra bene pats geriausias produktyvumo įprotis kurį išsiugdžiau. Prie kompiuterio praleidžiu tikrai daug laiko. Kaip atrodo mano tipinis darbo mėnuo galima pamatyti nuotraukoje žemiau. Ekranas iš mano Toggl paskyros kur laiką seku pagal Pomodoro metodo dėka Laiko apskaitą su Toggl įrankiu seku nuo tada kai pradėjau naudoti patį Pomodoro. Turiu virš 7 metų duomenų kuriuos bet kada galiu analizuoti. Mano darbe - laiko vadyba (ar „valdymas“ kaip sako kiti) yra vienas iš būtinųjų dalykų kuriuos reikia išsiugdyti, jeigu nori pasiekti gerų rezultatų. Arba tie rezultatai gali būti paprasčiausiai pinigai / pelnas / atlyginimas. Šis straipsnis apie tai, kaip Pomodoro man padeda pasiekti tikslus ir užsigugdyti tikrai geležinę laiko vadybą. Pomodoro technikos paaiškinimas Tai labai paprasta technika. Nereikės nei daug mokytis nei daug apie ją skaityti. Dažniausiai vieno internetinio straipsnio pilnai pakanka. Arba Wikipedia puslapio. Technika sukurta 1980 metais (autorius Francesco Cirillo) ir neturi nieko daugiau, kaip tik laiko paskirstymą intervalais. Tradiciškai 25 minutės darbo susikaupus, su trumpom, tarkime 5 minučių, pertraukėlėmis. Taip pat tradiciškai, 4 Pomodoro (tos minėtos 25 min.) užbaigiamos ilgesne pertrauka - 15 min. arba panašiai. Ir pabaigai - ši technika dar turi „Pomodoro ciklo“ sąvoką. Tai yra 4 Pomodoro baigimo ciklas, iliustruotas žemiau: Pomodoro ciklas Štai kaip tai atrodo mano tipinėje dienoje: Darbą pradedu 5 ryto kasdien. Su Toggl Chrome Extension pasileidžiu laikmatį 25 minutėms. Dirbu prie vienos užduoties vienu metu. Jokių Facebook, kitų socialinių tinklų ar RSS skaitymo. Suskambus laikmačiui darau kelių minučių pertraukėlę. Ką daryti per pertraukėles Bet kuris gydytojas tikriausiai pasakytų, kad jeigu darbas yra prie kompiuterio ar šiaip sėdimas (rašomas kursinis, skaitoma knyga ar pan.) - reikėtų atsikelti, pajudėti, prasimankštinti. Ką daro programuotojai? Jie pasitikrina el. paštą, socialinius tinklus, paskaito RSS ar kitokius informacinius srautus. Aš ir pats taip darau. Tačiau pertraukas daryti yra labai svarbu. Tikrai ne visos pertraukos turi baigtis nuo užduoties kompiuteryje iki kažkokios veiklos kompiuteryje. Taip tik pavargs akys, nugara, rankos. Todėl pavaikščioti, atsitraukti - yra labai svarbu. Ir ne tik per ilgąją pertrauką. Biuruose rekomenduoju daryti dažną „kavos pertraukėlę“. Namie galima užsiimti įvairia veikla - minimaliai apsitvarkyti, palaistyti gėles, ką nors pasiruošti rytojui ar pan. Darbo biure problemos Yra labai daug studijų apie „darbą“ biure ir dar daugiau (nebūtinai pagrįstų) komentarų ar straipsnių, kad tradiciškai darbuotojas per 8 val. dirba tik daugiausiai 6 valandas. Visos kitos valandos „išmetamos į balą“: kavų pertraukėlėms, pasišnekėjimams, susirinkimams, darant ne su darbu susijusią veiklą (kalbėjimas telefonu, naršymas Facebook). Ir tokiems darbams Pomodoro technika vistiek greičiausiai netinka. Trumpai tariant, gi mokama už buvimą darbe. Skamba labai žiauriai, bet tai yra tiesa, jeigu darbo įvertinimas nepriklauso nuo kažkokių rezultatų. Tačiau kai darbas yra priklausantis nuo rezultatų - labai svarbu dirbti susikaupus. Todėl viena iš būtinybių - dirbti tokioje aplinkoje, kur gautumėte tą ramybę. Triukšminguose biuruose tai šiais laikais nesunkiai ištaisoma - ausinėmis arba ausinukais. Aišku, jeigu leidžia galimybės. Ne visose darbo vietose užsidėti ausines yra mažų mažiausiai mandagu. Kitas trikdis gali būti reiklūs kolegos ar vadovai. Tai viena bėdų labai aktyviose IT įmonėse. Man yra tekę dirbti tokiose. Čia projektų vadovų priėjimai kas 5 minutes būtų stipriai prieš Pomodoro. Universali technika Apskritai, kalbant apie IT, tai Pomodoro yra pirmas dalykas ką rekomenduočiau freelanceriams. Jų darbas 100% priklauso nuo rezultatų, ne sedėjimo. Tokia technika man pačiam gerokai atsipirko. Ši technika puikiai veikia prie kompiuterio sėdintiems darbuotojams - ypač programuotojams, dizaineriams, marketingistams, pardavimų vadybininkams, straipsnių rašytojams, tyrėjams ir pan. Taip pat tai tobula technika studentams - žmonėms kuriems dažniausiai reikia prisiversti prisėsti prie studijų. Dabar žiūrint į praeitį labai gaila, kad tada apie tai nieko nežinojau. Net ir prasčiausiai besimokantiems studentams skirti vieną Pomodoro kartą į dieną greičiausiai duotų naudos. Tiesiog atsisėsti ir studijuoti būna sunku. O nusibrėžus labai aiškią ribą kiek ir ko daryti - tarkime 25 minutes - pasiekti galima nesunkiai. Man po 7+ metų naudojimo šios technikos tos 25 minutės pralekia dažnai kaip kokios 5. Greičiausiai ši technika netinka fabriko darbuotojams arba žmonėms kurie turi daug pasikartojančio darbo. Tokia technika tik išsekintų smegenis. Bet gali būti labai geras įrankis kovoti su tingumu. 25 minutės darbo ir einame „apdovanojimo“ - kavos, pasidaryti pertraukėlę ar prasimankštinti. Originalios technikos eiga Minėjau, kad šis „laiko valdymo“ metodas / technika buvo sugalvota 1980 metais. Ją „sukūrė“ Francesco Cirillo. Jo originalų metodą sudaro 6 žingsniai. 1) Reikia tiksliai žinoti kas norima padaryti. Arba ką per būsimą Pomodoro laiką norima pasiekti. Todėl greičiausiai reiks su savimi turėti kažkokią užrašų knygutę ar tiktų koks elektroninis darbų sąrašas (angl. „todo list“). 2) Laiko intervalo nustatymas darbui. 25 minutės - kaip minėjau yra tradicinis laikas. Internete galima rasti ne vieną variaciją: 30 minučių, 60 minučių, 90 minučių. Nesu matęs, kad kas nors darytų ilgesnius intervalus nei pusantros valandos. Bet esu bandęs ilgesnius intervalus nei 90 minučių (skaitykite toliau). 3) Darbas arba bandymas atlikti užduotį. Originalioje technikoje, mano kelis kartus minėto, „susikaupimo“ nėra. Sakyčiau tai nauja tradicija. Juk 1980 metais nebuvo tokių laiko švaistytojų kaip telefonai su pranešimais, el. pašto dėžutės ir pan. 4) Atliktų Pomodoro pasižymėjimas. Programinė įranga čia tiktų geriausiai. Be minėtų Toggl yra daugybė kitų (ir nemokamų) įrankių tiek kompiuteryje, tiek mobiliame telefone. Daug kas šiais laikais turi išmaniuosius laikrodžius. Ir ten tai būtų pasiekiama. Labai gerai, kad internete yra ne vienas nemokamas įrankis kurio net diegti į kompiuterį nereikia. Ar registruotis. Vienas tokių būtų Tomato.es kuris veikia tiesiog naršyklėje ir net nereikia registruotis. 6) Po pilno ciklo (4 Pomodoro) daroma ilgesnė, 15-30 minučių pertrauka. Originalioje technikoje čia žymėjimo ciklas (4 punktas) pradedamas nuo 0. Sprendžia atidėliojimo problemas Per daug metų atradau, kad tai labai gerai išsprendžia atidėliojimo problemą. Iš dalies dėl to ir minėjau studentus - atidėlioti studijų dalykus yra bene įprastas dalykas. Visi turime darbų kuriuos anksčiau ar vėliau atidedame ir dėl to, žinoma, gailimės. Aš su šia bėda jau gana anksti pradėjau kovoti taip: kiekvieną dieną skirdamas vieną ar kelias Pomodoro sesijas. Ir taip, 1-2 Pomodoro kasdien yra ženkliai geriau nei žadėjimas sau, kad RYTOJ kelioms valandoms prisėsite prie to ko reikia. Tai ypač tinka programuotojams kurie be savo standartinio darbo dar nori kažką padaryti savo, bet sunkiai sekasi tą padaryti po darbo. Turiu omeny, kad pats sunkumas yra ne tiek, kad rasti laiko, o rasti jėgų ir noro. Pomodoro čia labai gerai veikia. Kitoks laiko intervalas - be pertraukų Nors keletą kartų eksperimentavau su laiko nustatymais (mėgindamas didesnius nei 25 min. ruožus) - visgi pats geriausias pasirodė standartiškai rekomenduojamos 25 minutės. Bet su pertraukomis taip gerai nesielgiu. Esu bandęs padirbti 2 pomodoro iš eilės (viso 50 min.) ir tada tik daryti pertraukėlę iki 10 min. Tai veikė gerai ir tokie eksperimentai gali įnešti šiek tiek naujumo į ilgai daromą rutiną. Turbūt po standartinių 25 minučių šis laiko intervalas yra bene populiariausias sutinkamas internete. Esu bandęs dirbti 4 pomodoro iš eilės (viso 1 val. 40 min) ir tada daryti ilgesnę pertrauką, bet taip darant daug greičiau pavargsti. Limitas kiek Pomodoro gali padaryti per dieną Turiu viešą profilį su Pomodoro sekimu - Tomato.es . Jame galima pažiūrėti kaip maždaug atrodė mano tipinės dienos. Nuotrauka iš mano Tomato.es profilio - pomdoro pagal dienas Mano diena rekordininkė - 31 pomodoro per dieną. Kai buvau daug jaunesnis (ir kvailesnis), tai dažnai tiesiog persidirbdavau. O iš tokio pomodoro kiekio galima suprasti, kad pertraukų daug nedariau. Tikrai tokių skaičių niekam nerekomenduoju. Viskas kas yra virš turbūt 20 Pomodoro per dieną (jeigu laiko intervalas yra 25 min.) jau turbūt būtų per daug žalinga. Reikia tikrai neužmiršti daryti pertraukas. Be pertraukų greičiau ateina nuovargis, produktyvumas ir susikaupimas mažėja. Todėl daugiau Pomodoro - nebūtinai geriau atsispindi rezultatuose (vėliau). Pomodoro technika vaikams Turiu du vaikus, tačiau Pomodoro su jais dar neeksperimentavau. Jie tam dar per maži. Bet manau, kad ateityje tikrai išmėginsiu. Internete yra ne vienas straipsnis apie tai, kaip ši technika gelbsti į mokyklą einantiems vaikams. Tačiau vaikams 25 minutės - tai amžinybė. Priklausomai nuo amžiaus, bet 25 minutės galėtų atrodyti kaip kokia suaugusio valanda. Todėl čia gelbėtų 15 minučių intervalai ir pertraukėlės. Net neabejoju, kad įpratinus vaiką skirti kokius 4 tokius Pomodoro kasdien mokslams - mokymosi rezultatai gerokai pagerėtų. Pomodoro ataskaitos Mano rekomendacija - visada sekti savo Pomodoro. Programinės įrangos ta tema - gausybė. Nesunkiai rasite ką naudoti. Tiek telefone, tiek naršyklėje, tiek kompiuteryje. Net išmaniam laikrodžiui tikrai rasite programėlę. Paėmus neilgą (pusmečio) intervalą iš ataskaitų galima pamatyti įdomių dalykų. Nuotrauka iš mano Tomato.es profilio ataskaitos Iš nuotraukos aukščiau matyti, kad per dieną turėdavau net 11 valandų per kurias darbo padarydavau daugiausiai (užregistruodavau daugiausiai Pomodoro). Taip, iš tiesų dirbdavau po 10-12 valandų tipiškai. Tada darbą pradėdavau nuo 6 ryto. Nors nuotraukoje matosi laikas registruotas nuo 4 ryto, manau, kad tai dėl programos laiko juostų skirtumo. Ir akivaizdu, kad tas kėlimasis nuo 6 nebūdavo produktyviausias dalykas - nes tam laikui registruotų Pomodoro - sąlyginai mažai. Taip buvo dėl to, kad ryte atsikėlęs darydavau planavimo fazę. T.y. susiplanuodavau dienos darbus, pasitikrindavau el. paštą, RSS srautą, Facebook. Tik po kažkur pusmečio paanalizavęs nusprendžiau, kad tai - blogas dalykas. Todėl šios fazės ryte - savo „brangiausio“ laiko metu - visiškai atsisakiau. Planavimą atlikdavau vakare (dieną prieš), o visokius RSS srautus, Facebook ir el. paštą pasitikrindavau per pertraukas. Privalomos 8 valandos - niekaip Biure būti reikia 8 valandas. Jeigu galvosite pritaikyti savo darbo eigoje Pomodoro, tai turbūt greitai išskaičiuosite, kad jeigu per valandą turėtumėte turėti 2 pertraukas po 5 min. (viso 10 minučių), tai per 8 valandas tų pertraukų bus mažiau nei pusantros valandos. Tai - labai daug. Ir jeigu su šia idėja pasidalintumėte su savo vadovu, greičiausiai tokiam darbo metodui jis nepritartų. Deja, realybė dažniausiai (beveik visada) tokia, kad net per pus mažiau laiko skiriant su Pomodoro padaroma daugiau nei tiesiog būnant biure 8 valandas. Tai viena iš priežasčių ką stebėdamas Tomato.es ataskaitas pastebėjau. Dirbau prie IT projektų („freelancinau“) turėdamas normalų darbą. Atradęs Pomodoro ir kelis mėnesius prie jo pasipratinęs pamačiau, kad tas pats „freelance“, kur mokama už rezultatą, o ne už dirbtas valandas, atneša daugiau pelno. Taip atsitiko dėl kelių priežasčių. Pirmiausiai turėjau tikslą kasdien po tam tikrą kiekį Pomodoro atlikti. Ir retai kada atlikdavau mažiau. Tai padėjo išspręsti atidėliojimų problemą - kai kaip koks studentas užduotį „stumi“ iki paskutinės savaitės ar net dienos. Antra - dėl to, kad per mėnesį skirdavau sąlyginai daugiau laiko susikaupus - padarydavau daugiau. O daugiau padarymas konvertavosi į didesnį atlygį. Pomodoro technika tai technika prieš „multitaskinimą“ Anglų kalboje yra labai populiarus terminas - „multitasking“. Yra labai daug tyrimų padarytų ta tema, kur paaiškinta, jog kelių darbų bandymas atlikti vienu metu neigiamai veikia ir kūną (greičiau pavargstama) ir tik atitolina rezultatus. Nors iš pirmo žvilgsnio tikrai atrodytų, jog du darbus vienu metu dirbant - daugiau padaroma. Tai didelis melas. Todėl modernaus (šiuolaikinio) Pomodoro būtinybė - dirbti be trikdžių. Tie kas dirba prie kompiuterio, turėtų uždaryti visas ne su užduotimi susijusias programas, atsitraukti nuo socialinių tikslų, nežiūrėti ar neklausyti foninio triukšmo (pavyzdžiui kalbančio radijo). Aš pats muzikos klausausi (bet ne radijo). Triukšminguose biuruose muzika gali padėti labiau susikaupti. Ją daug kur galima klausyti tiesiog per ausines. Dėl to, ar muzikos klausimas yra „multitaskinimas“ ar ne - labai daug ginčijamasi. Yra padaryta tyrimų, kurie sako, kad darbas tyloje yra produktyvesnis už darbą klausant muzikos per ausines. Net jeigu teorija yra tokia, praktiškai kai kam tai veikia atvirkščiai. Anksčiau gal kokius 5 metus dirbdavau tyloje, dabar - reikia muzikos. Reikia pabrėžti, kad ne visuose biuruose galima užsidėti ausines. Daug kur tai gali trukdyti kolegoms. Todėl prie šito reikia prisitaikyti pačiam, pagal situaciją. Pomodoro įrankiai Tas pats Tomato.es yra visiškai nemokamas ir atviro kodo. Man yra tekę jį parsisiųsti ir modifikuoti pagal savo norus - kodo bazė nesudėtinga, todėl galima prasiplėsti įrankį. Esu naudojęs Gnome Pomodoro - super įrankis, jeigu naudojate Linux. Gnome Pomodoro UI ant Linux Turbūt populiariausias laiko apskaitos įrankis internete yra Toggl . Jis duoda šią galimybę per tokius įrankius (nemokamus) kaip Chrome Extension. Nors ir veikia ne 100%, bet aš pats naudoju jau virš 5 metų ir iš esmės galima susitaikyti su nedidelėmis klaidomis. Visiškiems geek’ams galėtų patikti Pomodoro BASH skriptas - irgi naudojau ilgiau nei metus. Pabaiga - kaip išmėginti Dabar žinodami mano 7 metų patirtį galite patys išmėginti Pomodoro. Tikrai labai rekomenduoju visiems. Jokių įrankių nereikia. Šiais laikais laikmatį turi visi - išmaniajame telefone. Todėl nieko siųstis, nieko pirkti ar registruotis - nereikės. Susiraskite užduotį kurią norėsite atlikti. Ir nesvarbu ar ta užduotis yra namų tvarkymas, kursinio rašymas, IT projektas ar kažkas kito. Geriausiai čia tiktų koks nors darbas, kurį nuolat atidėliojate. Nusistatykite laiką ir pirmyn!

Knygos „TED Talks - The Official TED Guide to Public Speaking“ apžvalga

Nesu TED prezentacijų mėgėjas, tačiau ši knyga (tiek audio, tiek popieriniame variante) yra tikrai geriausia ką galima rasti viešojo kalbėjimo tematika. Pati knyga prasideda įdomia istorija kaip TED vos “nemirė” vos tik šiam renginiui/idėjai prasidėjus. Ar žinojote, kad organizatoriai ir šio renginio vedėjai padeda pasiruošti ir praktikuojasi su būsimais pranešėjais? Kiek tekę yra dalyvauti/pranešinėti visokiuose PyCon, GIT, Ubuntu ar kitose konferencijose - dar neteko matyti nieko panašaus. Dažniausiai į prezentacijas pakviečiami pranešėjai, o jau kas bus prezentacijos pristatymo metu - tas bus. Tie patys TED organizatoriai turi sukaupę didelį žinių bagažą ir dalinasi šimtais vertingų patarimų kaip savo prezentacijas pagyvinti, padaryti įdomesnėmis ir sklandesnėmis. „TED Talks: The Official TED Guide to Public Speaking“ knygos viršelis Tarp visokių minčių galima rasti: Yra vienas dalykas ko niekas kitas neturi pasaulyje: tai būtent Jūsų patirties/patyrimo kai kažkas vyko apie ką pasakojate”. “Žmonės mėgsta istorijas ir kiekvienas gali išmokti jas pasakoti”. “Mažas-geras pristatymas užima labai daug laiko pasiruošti, ilgas-geras pristatymas užima daug mažiau”. Knygoje yra ir ne vienas „planas“ ar „sistema“ kaip savo prezentaciją galima perskelti į tam tikras dalis ir šias dalis gerokai pagerinti. Turinio, patarimo, istorijų ir pavyzdžių šimtais. Sunku tiek „suvirškinti“, tačiau tai tikrai geriausia ką esu iki šiol skaitęs šia tema. Anksčiau esu rašęs apie dar vieną naudingą knygą apie viešojo kalbėjimo meną kuri gali taip pat būti naudinga - Knygos Čerčilio iškalba, Linkolno tvirtybė apžvalga.

BASH skriptų kompiliavimas į binarinius paleidžiamuosius failus

Namų kataloge turiu bin/ katalogą kuriame per daug metų sukaupiau gausybę skriptų. Tarp jų yra skriptų visokiomis kalbomis: BASH, SH, Ruby, PHP, Python, JavaScript (Node). Šis katalogas auga ir per Dropbox yra perduodamas kitiems mano kompiuteriams. Dauguma kalbų, tokių kaip Ruby ar Python, leidžia sukompiliuoti savo skriptus. O šiuos - galima dalinti kitiems. Tačiau ar žinojote, kad tą patį galima padaryti ir su BASH? T.y. pasidaryti binarinį paleidžiamą failą? SHC paketas Jeigu nesinori perduoti pliko ir visiem perskaitomo BASH skripto, įdiekime shc. Naujuose Ubuntu tai galima padaryti su: apt install shc Debian arba senesniuose Ubuntu OS: apt-get install shc Fedora ir Centos OS: yum install shc MacOs: brew install shc Skriptų kompiliavimas Kompiliavimas vyksta labai paprastai ir vos viena komanda: shc -f bash_skriptas.sh -o sukompiliuotas_skriptas Vėliau, savo skriptą galima paleisti su komanda: ./sukompiliuotas_skriptas. Tiesa, kažkam jį perdavus / nusiuntus gali reikėti pakeisti paleidimo teises: chmod +x sukompiliuotas_skriptas Sukompiliuoto skripto tikrinimas Patikrinti ar tai tikrai sukompiliuotas failas galima keliomis komandomis: $ file sukompiliuotas_skriptas sukompiliuotas_skriptas: Mach-O 64-bit executable x86_64 Arba tiesiog pažiūrėjus jo turinį su less sukompiliuotas_skriptas. Ką daugiau gali ši komanda galite perskaityti shc žinyno puslapyje .

FTP su Docker

Kažkada užsiiminėjant savanoriška veikla teko bendrauti su Lietuviška IT įmone kuri viename projekte turėjo ištaisyti kelias savo klaidas. Na, gal ne tiek, kad kelias klaidas, veikiau jau visiškai neveikiantį projektą sutaisyti. Tačiau įmonė buvo iš tų dinozauriškų laikų, kur support’ą savo neveikiantiems projektams darė per… FTP :( Ir žinoma, kas šiais laikais nori į serverius diegti FTP? Laimei, žinojau, kad prieigos reikia 1-3 dienoms - kol projektas bus pataisytas. Taigi FTP pakūriau su Docker pagalba. Sukurkime FTP serverį su Docker Vos viena komanda ir ant standartinio prievado (angl. „port“) bus pakurtas FTP servisas / demonas kuris turės vieną vartotoją ir galės vaizduoti tik vieną FTP katalogą: docker run -d -v /kelias/iki/projekto:/home/vsftpd \ -p 20:20 -p 21:21 -p 47400-47470:47400-47470 \ -e FTP_USER=VARTOTOJAS \ -e FTP_PASS=SLAPTAŽODIS \ -e PASV_ADDRESS=SERVERIO-IP \ --name ftp \ --restart=always \ bogem/ftp Panaudotas Docker atvaizdas - bogem/ftp Kodėl ne ProFTPd ar kita įranga? Iš esmės gali kilti klausimas kam reikia Docker’io čia, kai nuo to paties skiria vos viena komanda: apt-get install proftpd yum install proftpd [..] Pirmiausiai tai, kad gyvename jau ne dinozaurų laikais ir Docker jau turėtų tapti vos ne būtinybė serveriuose. Arba kitokios, konteinerizuotos, Docker alternatyvos. Antra - Docker duoda tiek pat kontrolės kaip ir įdiegtos specializuotos programinės įrangos. Trečia - Docker daugeliu atveju išsprendžia poreikį konfigūruoti programinės įrangos nustatymus. Vos viena komanda - ir FTP servisas jau pilnai veikiantis, turi vartotojus ir gali būti bet kada lengvai atjungtas. FTP sustabdymas Ar veikia ar neveikia Docker FTP atvaizdas/konteineris matysite su docker ps komanda. Jeigu nėra FTP įrašo - vadinasi konteineris neveikia ir FTP neveikia. Jeigu įrašas yra, reiškia FTP vis dar veikia. Išjungti konteinerį galima su tokia Docker komanda: docker stop ftp FTP pašalinimas iš sistemos Sustabdžius konteinerį galima jį pašalinti: docker rm ftp Docker konteinerio nebematysite: docker ps -a | grep ftp Jeigu žinote, kad FTP tikrai daugiau nebereikės, tuomet galite pašalinti ir patį atvaizdą kuris yra vis dar Jūsų diske. O diske jis todėl, kad kitą kartą paleidus FTP kūrimo komandą - viskas suveiks žaibiškai, nes atvaizdas užkešuotas ir siųsti iš interneto jo jau nereikės. Pašalinkite atvaizdą ir atlaisvinkite disko vietą: docker rmi bogem/ftp

Kaip su Pygame varžiausi Pyweek

2018 spalį vyko jau 26 Pyweek turnyras. Tai trečiasis turnyras kuriame spėjau sudalyvauti. Turnyro tema buvo „tekmė“ (angl. flow). Žinoma, šį žodį galima versti į kokius tik nori sinonimus. Gaila, kad po truputį blėsta žaidimų kūrėjų gretos kasmet šiame turnyre - kiekvienais metais žaidimus pabaigia vis mažiau kūrėjų. Jeigu įdomu kas tai per turnyras - galite pasiskaityti daugiau praėjusiame straipsnyje: Pyweek turnyras - kas tai? Su kokiu žaidimu startavau aš Su Pygame varikliu kūriau piratų mūšio žaidimą: Pyweek #26 žaidimo 'Pirate Flow' ekrano vaizdas Per 19 valandų pavyko sukurti žaidimą kuriame galima šaudyti priešus (laivus ir patrankas), plaukioti po didžiulį pasaulį, rinkti taškus, gyvybes ir atlikti kelias misijas. Deja, nors ir skyriau tikrai daug valandų - tai ką buvau sumąstęs savaitės pradžioje - nepavyko padaryti. Bet dėl to neverta nusiminti. Tai buvo gal jau penktas mano Pygame žaidimas (ir trečiasis kurį dariau Pyweek turnyrui) ir aš vis dar stebiuosi, kad nepamėginau kitos platformos / framework’o. Bet gal kada nors. Kaip visada sunkiausiai sekėsi ne sugalvoti kas atitiktų temą, bet padaryti patį žaidimą smagų. Tai iššūkis kuriam tikrai reikia labai daug praktikos. Kurią vietą laimėjau Su šiuo žaidimu laimėjau 14 vietą. Praėjęs mano žaidimas laimėjo 19 vietą, o pats pirmasis Pyweek žaidimas - 32. Išeities kodas Parsisiųsti ir pažaisti žaidimą galima iš Github repozitorijos: Pirate Flow žaidimo išeities kodas. Pasileidimo instrukcijos yra Readme faile ir neturėtų užimti daugiau nei kelių minučių. Kokia prasmė dalyvauti Kai kam svarbiausia bus azartas konkuruoti arba azartas užbaigti žaidimą per savaitę. Nors man azartas buvo svarbus, bet daugiausiai motyvavo galimybė ir vėl ko nors naujo išmokti. Taip ir buvo! Ar galima ko išmokti iš kitų kūrėjų? Pasibaigus Pyweekui būtinai pažaidžiu ir kitų kurtus žaidimus. Ir bandau atspėti kas kelintą vietą užims. Dažniausiai būnu arba visiškai teisus arba labai arti tiesos. Ir visus visus žaidimus apžiūriu kaip jie suprogramuoti. Kadangi Pyweek’e gauni kiekvieno žaidimo išeities kodą (kurį ir paleidinėji, o ne kokius binarinius nesaugius failus) - pažiūrėti į žaidimus iš jų pačių „virtuvės“ nebus sunku. Būna įdomu pažiūrėti ir palyginti su savo žaidimo logiką: lengva rasti optimizacijų, geresnių praktikų arba tiesiog kaip geriau daryti žaidimo architektūrą. Patarimai iš patirties Niekada nekūrėte žaidimų? Tai Pyweek kaip tik Jums! Čia pirmieji startuoliai labai laukiami. Bijote, kad nesugebėsite? Tai nesvarbu. Padarykite kažką kas bent jau judėtų ar reaguotų ir viešinkite. Vėliau tikrai rasite noro ir jėgų patobulinti. Neturite laiko tokiems dalykams, bet patinka žaidimų kūrimas? Tai Pyweek kaip tik Jums! Tik viena savaitė ir viskas. Kiek spėsite - tiek spėsite. Greičiausiai tiek turėsite daug motyvacijos, kad negalėsite atsiplėšti ir sėdėsite vakarais / naktimis. Atsimenu pirmasis-antrasis Pyweek’as man buvo šiek tiek su stresu, kadangi norėjosi tarsi nesusimauti. Susimauti - čia nėra kur. Kolektyvas kuris kuria ir vertina žaidimus priims labai nuoširdžiai ką Jūs padarėte ir negausite piktų žinučių vertinimo metu. Todėl tikrai siūlau pamėginti!

Pyweek turnyras - kas tai?

Du kartus per metus Python žaidimų kūrėjai renkasi Pyweek turnyre kurti ir varžytis su savo žaidimais. Turnyro esmė - per vieną savaitę sukurti žaidimą atitinkantį nurodytą temą. Tuomet vyksta „varžybos“ - balsavimas - ir išrenkamas geriausiai padarytas žaidimas. Pyweek turnyro eiga Turnyras vyksta du kartus per metus - kas pusmetį. Bet reikia nuolat tikrintis tikslesnę datą. Prieš pat turnyrą žmonės balsuoja kokia bus tema. Balsuojama iš maždaug 5-7 pasiūlytų temų. Už temą ir patys balsuoti galite. Sulaukus starto dienos - paskelbiama nubalsuota tema. Žaidimai turi būti kuriami su Python programavimo kalba, tačiau aplink ją galima naudoti bet kokius formatus ar resursus (ikonas, audio failus, 3D maketų failus). Žaidimui kurti taip pat galima naudoti bet kokį žaidimų variklį: Pyglet, Pygame Zero, Pygame, Pandas3D, Cocos2D ir pan. Anksčiau stipriai dominavo Pygame variklis - jį galima buvo rasti turbūt 60-80% žaidimų. Dabar Pygame Zero skinasi kelią ir drąsiai paima 30-40% kuriamų žaidimų. Jeigu pasidomėsite Pygame Zero greičiausiai greitai suprasite kodėl jis taip populiarėja - jis skirtas žaidimus pradedantiems kūrėjams: čia gausu pagalbinių priemonių startuoti žaidimų kūrimą ypatingai greitai. Ko tau reikia, kad galėtum dalyvauti Iš esmės tik Python bazinių žinių (kaip rašyti ciklus, deklaruoti kintamuosius, aprašinėti logines sąlygas). Bazinių žinių užteks norint kažką sukurti - todėl pradedantieji turnyre tikrai laukiami. Jeigu žaidimą kuriate pirmą kartą, tuomet rinkitės Pygame Zero arba Pygame framework’ą. Su Pygame Zero žaidimų kūrimas bus išties paprastas. Sudėtingesni žaidimai dažniausiai kuriami su Pandas3D, Cocos2D ar pan. framework’ais. Kaip vyksta vertinimas Turnyrui pasibaigus (tiksliau - programavimo savaitei pasibaigus) galėsite parsisiųsti kiekvieną sukurtą žaidimą (jo išeities kodą) ir pasileisti jį. Paleidimo instrukcijos dažniausiai būna Readme faile. Vertinimo kriterijai Pirmiausiai - ar žaidimas pasileidžia? Tikrai labai dažnai būna taip, kad žaidimas nepasileidžia / neveikia. Mano rekomendacija - pamėginti patiems pataisyti vieną kitą klaidą kitų kurtame žaidime - galbūt nesunkiai pataisysite paprasčiausias bėdas. Tikrai kiekvieno Pyweek turnyro balsavimo metu tenka taisyti kitų žaidimus. Tarp klaidų būna - nepaminėti moduliai kuriuos reikia įdiegti (pvz. žaidimas sukurtas su Pygame, bet kode dar naudojamas Pyglet kuris nepaminėtas); visokios UTF8 bėdos arba paprasčiausi įhardcodinti failo keliai iki žaidimo. Pasitaisykite, bus smagu pataisytą žaidimą paleisti. Žaidimus taiso ir kiti. Daug komentarų ir pats esu gavęs, kad mano žaidimai neveikė Windows platformoje, todėl žmonės tą arba aną pataisydavo. Smagu, nes tik veikiantys žaidimai gali būti vertinami. Jeigu žaidimas pasileido, tada balsuojama ar žaidimas yra smagus, ar sukurtas kaip nors įmantriai/įdomiai, ar atitinka temą. Prizai Jokių piniginių ar kitų materialių prizų šiame turnyre nėra. Bet laimėtojų laukia šlovė ir pasaulis pripažinimas! :) Sudalyvaukite, tikrai verta!

1000 knygų tikslas

Kartą lankydamasis knygyne ir ieškodamas sekančios knygos skaitymui, pamačiau kažkokią keistą knygą pavadinimu „1001 knyga kurią privalai perskaityti per savo gyvenimą“. Pati knyga yra turbūt skirta tiems, kas mėgsta sąrašus ir skaitymą pagal juos. Ir tai tinka labiau tiems, kas mėgsta tam tikrą knygų žanrą - detektyvus, romanus ir pan. Arba tiems, kurie nori turėti kažkokį skaitymo tikslą… Knygos „1001 knyga kurią privalai perskaityti per savo gyvenimą“ viršelis Ir tada toptelėjo - perskaityti tūkstantį knygų per gyvenimą atrodo visai neblogas tikslas! Minėtos knygos nepirkau ir nesigilinau kas joje - grožinė literatūra man ne prie širdies. Tik knygos pavadinimas buvo naudingas - aš pats nuspręsiu ką man skaityti. Kiek perskaičiau iki dabar Šį tikslą jau tęsiu 6 metus. Per juos perskaičiau daugiau nei 220 knygų. Tokiais greičiais tūkstantį perskaityti nebus lengva / greita. Tačiau skaitau savo malonumui - todėl skubėti nėra kur :) Ar verta turėti knygų skaitymo tikslą? Skaitau tik asmeninio tobulėjimo knygas. Todėl perskaityti tokį didelį kiekį knygų atrodo labai gera mintis - puiki vieta sužinoti apie laiko valdymą, pinigų kontrolę, plėsti požiūrį ir tobulinti filosofiją į gyvenimą. Literatūrinių knygų (detektyvų, romanų ir pan.) neskaitau. Tačiau pažįstu daug žmonių, kurie tik tokias knygas ir mėgsta. Pavyzdžiui mano žmona. Neturiu nieko prieš, svarbiausiai - kad tokios knygos būtų skaitomos savo malonumui. Tiksliai nežinau ar būtų koks nors tikslas turėti skaitymo tikslą kalbant apie literatūrines knygas. Šioje situacijoje, jeigu mėgčiau grožinę literatūrą, gal tiesiog imčiau ir mėginčiau perskaityti pačias populiariausias mėgstamo žanro knygas. Internetas pilnas TOP XYZ literatūrinių knygų sąrašų. O kam išvis skaityti? Turiu ne vieną draugą kurie „giriasi“, kad knygų neskaito. Niekada nesakau to garsiai, bet pirma mintis šaunanti į galvą būna - „matosi, kad neskaitai“. Yra toks populiarus posakis „apsiskaitęs žmogus“. Tokio žmogaus akiratis būna platesnis ir požiūris ne toks kategoriškas, lankstesnis. Tuo pačiu dažniausiai dėl plataus akiračio žmogus tampa daug įdomesnis ir atrodo protingesnis. Tikrai teko ne kartą sutikti tokių žmonių ir įsitikinti, kad žmogus tikrai daug skaitantis. Neskaitymas - rimta problema Mokiniai skaityti dažniausiai nemėgsta. Tai daroma labiau per prievartą / vertimą. Buvau ten. Štai kaip atrodo kelių metų senumo Delfi naujienų portalo antraštė: 52 proc. suaugusiųjų teigia, per savaitę visiškai neskiriantys laiko skaitymui, tuo tarpu televizoriaus nežiūri tik 2,5 proc. gyventojų. Pats papuolu prie tų skaičių kurie televizoriaus išvis neturi. Bet esu turėjęs prieš ~10 metų ir tikrai žinau, kad lengva išugdyti rutiną grįžus po darbo ir prisėdus bukai spoksoti į ekraną. Tačiau vakaras gali būti produktyvesnis jeigu paimsite knygą. O jeigu knygų nemėgstate - internete pilna kursų kurių dėka galite ko nors naujo išmokti, ko nors naudingo. Kas galbūt ir karjeroje praverstų kopiant į viršų. Kokias knygas rekomenduočiau 2018 metais (po 6 metų skaitymo) geriausias knygas sudėjau į vieną sąrašą kurį pavadinau - knygos kurias būtina perskaityti O specialioje knygų kategorijoje rasite nemažai įvairių knygų apžvalgų.

Kokių klaidų nepadaryti perkant kompiuterį?

Kompiuterį keičiame pakankamai retai, todėl labai svarbu pasirinkti kokybišką ir funkcionalų jo modelį. Visgi, net ir tuomet, jei jis perkamas ne pirmą kartą, pasitaiko klaidų, lemiančių nusivylimą – jei norisi, kad šis prietaisas atitiktų visus Jūsų lūkesčius, vertėtų jas įsiminti ir nebekartoti. Neatsižvelgiama į asmeninius poreikius Pirmas klausimas į kurį turite atsakyti - kam bus naudojamas kompiuteris. Jeigu tai yra laisvalaikio kompiuteris, naudojamas internetui naršyti, susirašinėti su draugais ir artimaisiais - greičiausiai pretenduosite į mažiausio biudžeto kompiuterį. Čia vertėtų susimąstyti ar šiuo atveju ne geriau planšetė kurią su savimi galėsite pasiimti ant sofos ar su ja išeiti į lauką. Vidutinėje kainų kategorijoje būtų darbo kompiuteriai. Čia Jums vėlgi nereikės labai galingo varianto, bet greičiausiai turėsite susimąstyti apie tai kiek reikės disko vietos ar kokio dydžio ekranas turėtų būti. Brangesni yra žaidimų kompiuteriai. Dažniausiai juos perkantys jau žino kokių minimalių parametrų jiems reikės - juos galima rasti žaidimų specifikacijose. Darote labai didelę klaidą, jei susižavite daugiausiai reklamuojamais ir giriamais kompiuteriais – net ir turėdami aukščiausias specifikacijas, jie gali nepateisinti asmeninių lūkesčių, todėl Jūs tiesiog permokėsite. Geriausia, jei tiksliai žinotumėte, kokiems tikslams jį naudosite ir kokios funkcijos yra svarbiausios. Pagal tai galėsite susidaryti kompiuteriui skirtą biudžetą, žinosite kokių maždaug pajėgumų kompiuterio Jums reikia ir galėsite pasirinkti ne iš vieno varianto. Pavyzdžiui, jei ieškote paprasto, kasdienėms užduotims skirto įrenginio, puikiai pasitarnauti gali ir galingų specifikacijų nesiūlantys pigūs nešiojami kompiuteriai ar planšetiniai kompiuteriai Nepagalvojama apie ateitį Manote, kad kompiuteris Jums yra tinkamas šiuo metu, tačiau ar dažnai pagalvojate apie tai, kas Jūsų laukia ateityje? Galbūt tikitės, jog greitu metu turėsite daugiau laisvo laiko žaidimams, o gal svajojate išmokti dirbti su grafikos programomis? Net ir tuomet, jei tai kol kas tik neaiškūs ateities planai, pasikeitus situacijai Jums gali prireikti galingesnio kompiuterio modelio. Žinoma, iš anksto nuspėti tam tikrus dalykus neįmanoma, tačiau bent jau turėtumėte įsitikinti, jog esant poreikiui, tam tikrus kompiuterio komponentus bus galima patobulinti. Dažniausiai sutinkamos bėdos būna disko dydžio trūkumas arba atminties trūkumas. Žaidimų kompiuteriams gali neužtekti 1 TB ar daugiau disko, bet darbo kompiuteriui gali užtekti bene standartu tapusiu 120 GB disko. Todėl reikėtų iš anksto įsivertinti ar savo kompiuteryje nelaikysite daugybės failų ar nuotraukų - tokiu atveju reikės didesnio disko. Susikoncentruojama tik į parametrus Puiku, jei domitės tikslesnėmis kompiuterių specifikacijomis, tačiau jei aklai tikėsite, jog, pavyzdžiui, Intel Core i7 procesorius yra ženkliai geresnis nei i5, nepastebėsite kitų svarbių aspektų. Kompiuteris atitiks Jūsų poreikius tik tuomet, jei Jus tenkins bendra jo komplektacija ir galimybės, todėl pravartu pasidomėti, kaip skirtingi parametrai sąveikauja vieni su kitais. Nors tai gali šiek tiek užtrukti, paskyrę daugiau laiko, būsite tikri, jog pasirinkote teisingai. Vertinamas tik monitoriaus dydis Žinoma, dydis iš tiesų yra labai svarbus parametras, kadangi nuo jo priklauso mūsų kasdienės patirtys ir komfortas. Didesnis ekranas leidžia dirbti patogiau, tačiau tuomet kompiuterį sunkiau nešiotis kartu su savimi, tad jei būtent toks yra Jūsų tikslas, labiau praversti gali ir planšetiniai kompiuteriai. Visgi, nepamirškite, jog puikų vaizdą užtikrina ne tik ekrano dydis, bet ir kitos specifikacijos (maksimali raiška, vaizdo plokštė ir t.t.), todėl kartais mažesnis ekranas gali būti geresnis pasirinkimas. Pastebėkite, kad mažesnius ekranus turintys kompiuteriai dažniausiai turi ilgiau laikančią bateriją. Taip yra todėl, kad ekrano apšvietimui yra mažiau išeikvojama energijos. Stengiamasi per daug sutaupyti Pigūs nešiojami kompiuteriai visuomet pirmiausia atkreipia mūsų dėmesį, tačiau klausimas, ar jie visada atitinka mūsų lūkesčius? Todėl šiuo atveju rekomenduotina ieškoti ne pigiausio, bet geriausio modelio: jei iš anksto nuspręsite, kokią sumą galite skirti šiam pirkiniui, palyginę skirtingus kompiuterius toje pačioje kainų kategorijoje, surasite tą, kuris tinka būtent Jums. Gausų kompiuterių pasirinkimą rasite Pigu.lt el. parduotuvėje. Neatsižvelgiama į jungtis Susižavėjus kompiuterio techniniais parametrais, dažnai pamirštama atkreipti dėmesį į jungčių tipus ir jų skaičių – nuo to iš esmės priklauso tiek Jūsų, tiek šio įrenginio galimybės. Lengviausia suklysti tuomet, jei Jus domina itin ploni, stilingo dizaino kompiuteriai – būtent tokiuose modeliuose dažniausiai pritrūksta funkcionalių jungčių. Žinoma, visuomet yra išimčių, tačiau turėtumėte tuo įsitikinti. Taigi galima teigti, jog renkantis kompiuterį, svarbu žinoti, kokios jo galimybės ir kaip jas galėsite pritaikyti praktikoje. Išvengę visų šių klaidų, kur kas paprasčiau išsirinksite visus poreikius atitinkantį įrenginį!

Trūksta RAM, bet turite disko vietos?

Įsigijote mažą serveriuką savo mikroservisui, tačiau jam karts nuo karto neužtenka RAM? Dažniausiai tai lengvai išsprendžiama, nes mikroservisams disko vietos dažniausiai būna per akis. Tuo pasinaudojus galima gauti netikros RAM atminties, kuri nors bus lėtesnė, bet vistiek labai naudinga. Taip, kalbu apie SWAP skirsnius. SWAP skirsniai, grubiai tariant, veikia taip: jeigu operacinė sistema savo atminties neišlaiko RAM’uose, tai dalį tos atminties gali įrašyti į diską, kad ji nepasimestų. Didžiausias minusas yra tas, kad RAM’ai yra N kartų greitesni už diskus, todėl to pasekoje atminties skaitymas ir rašymas šiek tiek kentės. Bet tai vistiek geriau nei išvis neturėti galimybės paleisti mikroserviso ar mokėti už didesnį serverio planą kai jo tikrai nereikia. Tikriname ar turite SWAP skirsnių Dažniausiai jokiuose serveriuose (serveriai.lt, EC2, DigitalOcean) neturėsite SWAP’o. Tą galite pasitikrinti su komanda: sudo swapon --show Jeigu komanda neišvedė jokio turinio - vadinasi SWAP’o nėra, o tai yra gerai. Kadangi naudosime disko vietą, tai reikia žinoti kiek jos turime ir nuspręsti kiek iš turimo kiekio galima rezervuoti: $ df -h udev 968M 0 968M 0% /dev tmpfs 200M 2.3M 198M 2% /run /dev/sda1 40G 28G 9.4G 75% / tmpfs 997M 0 997M 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 997M 0 997M 0% /sys/fs/cgroup Iš pavyzdžio aukščiau matosi, kad turime 9GB laisvos vietos. Todėl RAM’ams galėtume skirti kokius 2GB. Tai reiškia, kad tik 7GB disko vietos liks po rezervacijos. SWAP sukūrimas Sukurkime SWAP failą į kurį operacinė rašys atminties informaciją: sudo fallocate -l 2G /swapfile Ties 2G galite nurodyti norimą dydį. Ši komanda sukurs pasirinkto dydžio failą - taip vyksta disko vietos rezervacija. Toliau, saugumo sumetimais, SWAP failą padarykime skaitomą tik root naudotojui, kad kiti negalėtų skaityti atminties turinio: sudo chmod 600 /swapfile Ir dabar galime užregistruoti failą kaip SWAP skirsnį: sudo mkswap /swapfile sudo swapon /swapfile Pasitikriname ar turime daugiau atminties Pasitikrinti savo naują atmintį galima su: $ sudo swapon --show NAME TYPE SIZE USED PRIO /swapfile file 2G 839.8M -2 Atmintis dingsta po perkrovimo Jeigu tokio atminties padidinimo reikia tik vienam kartui (tarkime turite procesą kurį leisite tik kartą ir jis naudoja daugiau RAM atminties nei turite), tai bus džiugu, kad po serverio perkrovimo SWAP’o neliks, o SWAP failą galėsite ištrinti ir taip atgauti disko vietą. Tačiau jeigu norite, kad mikroservisai (kaip pavyzdys) nuolat turėtų RAM’ą, tuomet užteks skirsnių registracijos metu užregistruoti ir SWAP’ą keliomis komandomis: echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab Failo /etc/fstab atsarginę kopiją visada pravartu turėti.

Atvaizdai užimantys daugiausiai disko vietos Dockeryje

Dirbant su Docker gali ne kartą kilti klausimas kur dingsta disko vieta. Jeigu žinote ar skaitėte anksčiau kaip veikia Docker, tai jis kiekvienam Dockerfile žingsniui kuria kešavimo atvaizdą. Vėliau kešavimo atvaizdas pernaudojamas dar kelis kartus kol galop sukuriamas norimas atvaizdas kurį jau leisite konteineryje. Tačiau kešas vistiek užsiliks. Kiek užima atvaizdai Pažiūrėti kiek užima Docker atvaizdai galima su komanda: $ docker images REPOSITORY [..] SIZE apikaupyklalt_kaupykla.lt-api [..] 670MB jarmalaviciuslt_jarmalavicius.lt-web [..] 1.4GB python [..] 918MB quizaminacom-api_quizamina.com-api [..] 1.01GB imagemizecom-api_imagemize.com-api [..] 1.04GB python [..] 74.3MB Atvaizdų dydžiai pagal TOP’ą Jeigu domina išsirikiuoti atvaizdus pagal dydį, kad identifikuoti kas daugiausiai vietos užima ir ką galima optimizuoti: $ docker images | awk 'NR!=1 {print $7"\t"$1}' | sort -rh 1.4GB jarmalaviciuslt_jarmalavicius.lt-web 1.04GB imagemizecom-api_imagemize.com-api 1.01GB quizaminacom-api_quizamina.com-api 990MB adminkaupyklalt_kaupykla.lt-admin 918MB python 783MB docker.elastic.co/elasticsearch/elasticsearch 703MB services_apache 670MB apikaupyklalt_kaupykla.lt-api Trumpas komandos awk 'NR!=1 {print $7"\t"$1} paaiškinimas: NR!=1 - praleidžia pirmą eilutę kurioje yra antraštės juosta (stulpelių pavadinimai). {print $7"\t"$1} - sukeičiame pirmą ir paskutinį stulpelį, kad vėliau rikiavimo komanda galėtų išrikiuoti gražų sąrašą su TOP’ais. Trumpas sort -rh komandos paaiškinimas: -r - reiškia angl. reverse. Paprastas rikiavimas su sort būna didėjančiai, o mums reikia mažėjančio (todėl -r), kad viršuje matytume pačius didžiausius, apačioje - pačius mažiausius atvaizdus. -h - reiškia angl. human numeric. Rikiuoja pagal pagal skaičius, tačiau žiūri ir prie jo esančią raidę M (MB), K (KB), G (GB) ir t.t. Kaip pašalinti atvaizdus ir gauti daugiau disko vietos Kaip atsilaisvinti disko vietos su Docker jau rašiau praėjusiame straipsnyje.

Įdomiausi 2018 metų technologiniai sprendimai

Jeigu esate toks užkietėjęs elektroninių smulkmenų ir įrankių entuziastas kaip aš tai Jums tikrai patiks gausybė dalykų kuo nuolat stebina naujųjų technologijų kūrėjai. Trūksta idėjų ką galima dar išbandyti? Žemiau nedidelis sąrašas technologinių sprendimų kurie yra „ant bangos“ ir tokie populiarūs, kad greičiausiai patiems norėsis vieną ar kitą smulkmeną išmėginti. Smagu ir tai, kad šių naujovių nereikia ieškoti labai toli - jas galima rasti ir per kelias dienas turėti savo namuose iš lietuviškų el. parduotuvių. 1) Dronai. Šie įrenginiai patinka tiems, kurie nori praturinti savo laisvalaikį – jų pagalba galima nufotografuoti ar nufilmuoti įspūdingus kadrus iš oro ar tiesiog išmokti valdyti šį bepilotį orlaivį. Tokia veikla sudomina ne tik suaugusius, bet ir vaikus, tad gamintojai siūlo pačius įvairiausius šių prietaisų modelius: pats paprasčiausias dronas kaina yra prieinamas kiekvienam, tačiau jei norėsis daugiau galimybių, už jas teks susimokėti papildomai. 2) Virtualios realybės akiniai. Trokštantiems neįprastų pojūčių – virtualios realybės akiniai nukels Jus į neatrastus pasaulius ir suteiks galimybę juos pažinti iš arčiau. Šią technologiją galima pritaikyti patiems įvairiausiems tikslams: žaidimams, naujų vietovių pažinimui ar net mokymuisi. 3) Išmanieji laikrodžiai ir apyrankės. Šie technologiniai sprendimai ypač išpopuliarėjo aktyviai sportuojančiųjų tarpe, tačiau jų rodoma informacija ir funkcionalumas gali būti naudingas kiekvienam, norinčiam sekti savo fizinę būklę. Jie ne tik nurodys per dieną įveiktus kilometrus ar sudegintas kalorijas, bet ir seks miego kokybę, širdies ritmą, kvėpavimą bei žinoma – taps dailiu stiliaus akcentu. Šiuos ir kitus išmaniuosius įrenginius galite įsigyti Pigu.lt el. parduotuvėje. 4) Elektroniniai knygų skaitytuvai. Šie prietaisai mažiau nei kompiuteriai kenkia akims ir yra gerokai lengvesni nei Jūsų sukaupta knygų kolekcija (ar namų biblioteka), tad jeigu mėgstate skaityti ir keliauti, vargu, ar pavyktų surasti geresnį sprendimą nei elektroninis knygų skaitytuvas. Dažniausiai tokie gaminiai gali pasiūlyti pakankamai didelę atmintį, todėl nebereikės svarstyti, kokius leidinius pasiimti su savimi. 5) Dulkių siurbliai – robotai. Toks sprendimas ypatingai žavi tuos, kuriems namų ruošos darbai yra pareiga, o ne malonumas: kol Jūs ramiai ilsėsitės po sunkios darbo dienos, dulkių siurblys robotas pats pasirūpins švaria grindų danga. Nors sunku patikėti, tačiau šie prietaisai puikiai išvengia kliūčių, gali pasiūlyti net kelias skirtingas valymo programas bei daugybę kitų naudingų funkcijų, o svarbiausia – jų galimybės iki šiol plečiamos ir tobulinamos! 6) Belaidės ausinės. Daugeliui toks variantas jau nėra naujiena, tačiau jei iki šiol vargstate su nuolat susipainiojančiais ausinių laidais, šiuos rūpesčius jau galite pamiršti – dabar prekyboje siūlomos ausinės, dažniausiai veikiančios Bluetooth ryšiu. Šie gaminiai užtikrina komfortą ir stabilumą, todėl yra itin mėgstami tarp sportuojančių – dėl to treniruotės tampa tik dar efektyvesnės. Tai tik keletas populiariausių naujų technologijų sprendimų, tad jeigu atidžiau panagrinėsite išmaniosios technikos asortimentą, jų pavyks surasti ir kur kas daugiau. Galima tik spėlioti, kas mūsų laukia ateityje – tikėtina, jog įdomių ir gyvenimą lengvinančių įrenginių dar tikrai pavyks sulaukti. Labai džiugu, kad visa tai lengvai randama Lietuvoje!

Vietos atlaisvinimas po darbo su Docker

Kad ir kaip efektyviai dirbsite su Docker - neišvengsite to, kad jis „suvalgys“ daug disko vietos. Dabar mano projektų kataloge galima suskaičiuoti šimtus docker-compose.yml ir Dockerfile failų. Kai kurie projektai programuojami dažniau - kiti rečiau. Tie, kurie jau visai užmiršti, guli tiesiog eikvodami disko vietą ir nieko naudingo nedaro. O disko vieta šiais laikais brangus resursas, jeigu kalbėti apie serverius. Štai keletas komandų kurios padės atlaisvinti diską. Paprastas apsikuopimas viena komanda Jeigu norite tik prasivalyti nuo šiukšlių, lengviausiai pavykdyti vieną komandą ir to užteks: $ docker system prune WARNING! This will remove: - all stopped containers - all networks not used by at least one container - all dangling images - all build cache Are you sure you want to continue? [y/N] y [..] deleted: sha256:444ff179082f40ce3b53de4 deleted: sha256:5554d3b9257f76349ec2642 deleted: sha256:d93d2a5931da6a282368079 Total reclaimed space: 2.408GB Kaip matote iš išrašo aukščiau - pravalys kešą, nebenaudojamus atvaizdus, interneto prieigas ir išjungtus konteinerius. Tie, kas nenori valyti konteinerių, gali pasinaudoti pavienėmis komandomis žemiau. Kaip išvalyti nebenaudojamus atvaizdus? Išvalyti nenaudojamus atvaizdus galima taip: $ docker image prune -a WARNING! This will remove all images without at least one container associated to them. Are you sure you want to continue? [y/N] y [..] untagged: redis:latest untagged: ubuntu@sha256:91680dba9ee085 untagged: redis@sha256:fb38b203a9488b1 Total reclaimed space: 5.514GB Kaip išvalyti neveikiančius konteinerius? Čia padės šiek tiek daugiau bash magijos: docker ps -a | grep Exit | cut -d ' ' -f 1 | xargs docker rm Trumpas paaiškinimas: docker ps -a - parodys visus veikiančius ir neveikiančius konteinerius; grep Exit - neveikiančių konteinerių sąraše gale bus užrašas Exited DATA; cut -d ' ' -f 1 - iš konteinerių sąrašo iškerpame pirmą žodį - tai bus konteinerio ID; xargs docker rm - konteinerių ID perduosime xargs komandai kuri prie kiekvieno pavykdys docker rm KONTEINERIO-ID. Kaip išvalyti nenaudojamus skirsnius (volumes)? Tai padės padaryti viena komanda: $ docker volume prune WARNING! This will remove all local volumes not used by at least one container. Are you sure you want to continue? [y/N] y [..] faf4ccf09ddff08a11e2527f480d4878619 046006d6601fe4929a0272e218a00e55374 629a4cb272f3913e0c1b5dc3f5d74be343f Total reclaimed space: 2.179GB Ar trinti yra saugu? Konteinerius, kaip ir atvaizdus, trinti yra saugu. Jeigu vėl mėginsite leisti projektą, tai Jums Docker per naujo parsiųs atvaizdus (jeigu to reikia) ir per naujo sukurs konteinerius. Valydami skirsnius būkite atsargūs - tai Jūsų sukaupti duomenys. Aukščiau aprašyta komanda docker volume prune išvalys tik neprijungtus prie nieko skirsnius (nenaudojamus), todėl komanda yra saugi. Tokius skirsnius visada galite pasitikrinti su docker volume ls -f dangling=true. Po pusės metų intensyvaus darbo su Docker keliomis komandomis pavyko atlaisvinti daugiau nei 13GB disko vietos.

Knygos Čerčilio iškalba, Linkolno tvirtybė apžvalga

Nors pačią Jameso C. Humes knygą „Čerčilio iškalba, Linkolno tvirtybė“ įvertinčiau kokiais gal 4 iš 5 balų, bet vistiek nusprendžiau jai skirti straipsnį, kadangi geresnių knygų apie viešą kalbėjimą kol kas mano arsenale nėra. „Čerčilio iškalba, Linkolno tvirtybė“ knygos viršelis Kam skirta knyga Praktiškai visiems žmonėms. Jeigu nekalbate viešai prieš žiūrovus, tai tikrai kalbate susirinkimuose, prieš klasę, nepažįstamus žmones, darbo pokalbyje ir pan. Ir čia knyga tikrai Jums pravers su daugybe pavyzdžių iš labai gerai žinomų oratorių: Vinstono Čerčilio, Abraomo Linkolno, Margaret Tečer, Napoleono ir pan. Netgi Hitleris minimams gana dažnai. Oratoriai ir jų kalbos naudojami kaip pavyzdžiai įprasminti aprašytoms pamokoms. Kokios tos pamokos Perskaitę išmoksite daryti trumpas įžangines pauzes, darysite stiprų pradžios įvadą, mokėsite užduoti klausimus, mokėsite atsakyti nepatogius klausimus ir pan. Skiriamas dėmesys ir kitoms detalėms, tokioms kaip išvaizda ar kūno kalba. Knyga tikrai bus naudinga net ir ne vieną kartą šnekėjusiam viešai prieš salę.

Kas naujo Raspberry Pi 3 B+ modelyje?

Nedidelę mano namų elektronikos dalį sudaro Raspberry Pi (2 ir 3 modelio) elektronika surišta su keliais davikliais ir rėlėmis, aukštos įtampos reikalaujantiems įrenginiams kontroliuoti. Todėl labai nudžiugau neseniai pamatęs, kad kūrėjai išleido dar vieną versiją - Raspberry Pi 3 B+. Kodėl namų automatizavimui Raspberry? Kodėl namų elektronikai nenaudoju daug pigesnio ir tam reikalui sukurtą Arduino? Dėl to, kad kompiuterį ir jo išvestis daug lengviau programuoti nei kažkokį lust’ą kuris pririša ne tik prie C kalbos, bet dar ir reikalingo atskiro išmanymo tūkstančiams daviklių. Su Raspberry Pi viskas paprasčiau - atidarei prievadą (angl. „port“) ir bendrauji su kitais įrenginiais. Taip pat ir GPIO (jungtys ant Raspberry platformos kuriomis gali paduoti srovę įrenginiams arba nuskaityti jų duomenis) kontroliuoti kur kas paprasčiau. Kažkas neveikia korektiškai - prisijungi per „ssh“ prie Raspberry Pi įrenginio ir sutvarkai bėdas. Kadangi Raspberry Pi dažniausiai būna prijungtas prie interneto (nes kokia prasmė automatizuoti namus ir nekontroliuoti jų iš išorės) - lengva pasidaryti monitoringą kur atsidaręs kažkokį web puslapį matytum kaip keičiasi temperatūra name ar garaže. Kas pasikeitė nuo versijos be pliuso? Pažiūrėkime kaip atrodo naujasis modelis su pliuso ženklu: Raspberry Pi 3 PoE Jeigu turite senesnį modelį, tai iškart į akis kris metalinis logotipas ir šiek tiek pasikeitęs procesoriaus čipas. Kas domisi įranga, tai yra Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC @ 1.4GHz čipas. Šiame įrenginyje yra 1GB RAM, LAN palaikymas, Wifi ir Bluetooth (v4.2). Taip pat yra ir Bluetooth Low Energy (BLE) palaikymas. Dalykai kurie visiškai nepasikeitė: HDMI jungtis ir vieta. AUX jungtis ir vieta. Micro SD jungtis ir vieta (tam, kad galima būtų iš jos paleisti operacinę sistemą). Keturios USB 2 jungtys. Nors turėsime tą patį 5V ir net 2.5A pakrovėją, galiu pagirti, kad tai vienas geriausių sprendimų iš autorių pusės. Teko susidurti, kad visokioms FHD kameroms prijungtoms prie Raspberry Pi reikia tikrai nemažai amperų. Tipinis 1A pakrovėjas gali nepavežti prijungtų įrenginių. Dėl vos vos pasikeitusio procesoriaus greičio (nuo 1.2GHz iki 1.4GHz) turėtume greičio nepajusti. Tą patvirtina ir daug internete padarytų benchmarking’ų. Didžiausia naujovė - PoE Naujame Raspberry Pi rasime ir tokią jungtį: Raspberry Pi 3 PoE Kai kurie routeriai vaizdo kameroms elektros srovę perduoda LAN kabeliu ir tai vadinama Power over Ethernet. Iš to laimima, kad įrenginiui nereikia dar kažkokio lizdo maitinimui, kurį dėtumėte į elektros lizdą. Tokią galimybę ir Raspberry Pi 3 B+ turi. Tačiau tam, kad per LAN laidą užmaitintumėte Raspberry dar reikės nusipirkti šiam lizdui (nuotrauka viršuje) PoE Hat įrenginį. Pastarasis kainuoja kažkur 17€. Kiek kainuoja Raspberry Pi 3 B+? Kaip ir anksčiau, Raspberry kainos išlieka labai panašios. Šis įrenginys turėtų kainuoti apie 30 eur. Kiek brangiau iš oficialių parduotuvių (kaip Element14) ir kiek mažiau iš Ebay / Aliexpress. Ar verta atsinaujinti? Jeigu automatizuojate namus - tikrai taip. PoE palaikymas geriausias dalykas kas nutiko šiam įrenginiui! Po Wireless ir Bluetooth palaikymo, žinoma. Jeigu kitoms reikmėms - tikrai ne. Naujovės buvo skirtos su IT susijusioms reikmėms. Namų vartotojai negauna jokio greičio ar kitų privalumų.

GIT patch'ų siuntimas ir jų pritaikymas

Laikais, kada į GitHubą galima tiesiog supushint’i savo branch’ą ir nesukti sau galvos, turbūt retai kada tenka kam nors generuoti GIT Patch’ą ir jį kur nors siųsti. Taip retai, kad toks siuntimas tampa galvos skausmu - reikia prisiminti kaip tą daryti (produktyviai) ir kaip vėliau tuos patch’us applyint’i. Taip nutiko ir man, kai beveik dienai užlūžo Gitlab’as ir reikėjo kažkur pasidėti pakeitimus nes dirbu per kelis kompiuterius. Gitlab paslaugos neveikimo langas Kur pasidėti - labai paprasta - Dropbox. Bet kaip juos sugeneruoti ir kaip juos vėliau applyint’i - teko prisiminti. Toliau - trumpa atmintinė visiems (ir sau). Patch’ų generavimas Jeigu pirmiausiai šovė į galvą: git diff > failas.patch Tai iškart galiu pasakyti, kad toks generavimas turi krūvas minusų: Neproduktyvu, jeigu norėsite tą atlikti ant kelių ar daugiau komitų. Prarasite binarinius failus (jie nebus įtraukti). Prarasite naujus failus kurie nepridėti su git add. Taip pat galite įtraukti tik dalį pakeitimų, nes yra skirtumas tarp git diff ir git diff --cached. Todėl produktyviausiu būdu tampa: standartinis darbas (kada komitinat daug mažų pakeitimų) ir: git format-patch origin/master -o pakeitimai Viena komanda, o daro daug: Sukurs katalogą pakeitimai/ kuriame sudės patch’us. Kiekvienas patch’as turės numeraciją: 0001, 0002, … Kiekvienas patch’o failo pavadinimas bus sugeneruotas iš komito teksto, pavyzdžiui: 0001-use-staging-api-for-staging-env.patch O dėl origin/master ar nereikia repozitorijai būti pasiekiamai? Ne, nes siunčiantis pakeitimus (git fetch ar git pull) GIT’as pasižymi kokie komitai yra kokiose atšakose. Patch’ų pridėjimas Applyint’i pakeitimus labai lengva: while true do git apply pakeitimai/* done Shell’as turėtų paduoti git apply išrikiuotus failų vardus.

Knygos „Essentialism“ apžvalga

Dar viena filosofinė knyga mano perskaitytų knygų sąraše - „Essentialism: The Disciplined Pursuit of Less“ (autorius Greg McKeown). Skiriu jai straipsnio įrašą, nes šių dienų verdančiame gyvenime knyga galėtų būti naudinga ne vienam kuris skuba ar bando uždirbti viską. „Essentialism“ knygos viršelis Kalbant ypatingai apie programuotojus, natūralu, kad diena yra pilna streso, mėginimo padaryti kiek įmanoma daugiau ir gauti kaip įmanoma daugiau. Taip pat atrodo beveik natūralu nespėti į terminus, daryti ne visai prioritetinius darbus arba vienu metu daryti ne vieną užduotį. Ši knyga tai tokio gyvenimo filosofijos priešingybė: koncentruotis tik ties svarbiais dalykais atsikratant nesvarbių. Skaitant knygą dažnai pagalvojau, kad čia viską apibendrintų tiesiog paprasčiausias Pareto dėsnis (apie kurį taip pat yra aprašyta). Bet dėl praktinių pavyzdžių gausos - sunku buvo atsitraukti. Knygos autorius gyvenimiškų pavyzdžių tikrai nepagailėjo. Tai yra vienas iš dalykų kurie man labai patinka skaitant knygas - praktinė / gyvenimiška patirtis. Keletas man labiausiai patikusių šios knygos frazių: Daugiau streso - mažiau kokybės. Nuolat savęs klauskite - ar tai tikrai TOP svarbiausias dalykas ką galėčiau daryti? Galvokite mažiau - bet geriau. Žodis „prioritetas“ daugiau nei 500 metų buvo vartojamas vienaskaita. Tik prieš šimtą metų šis žodis buvo pradėtas naudoti daugiskaita. Kada paskutinį kartą tiesiog sėdėjote ramiai ir galvojote? Sunku išsirinkti ką norisi veikti ar turėti? Knygoje pateiktas 90-10 modelis - manau, kad kiekvienas stipriai užsiėmęs žmogus galėtų pritaikyti šią vertinimo sistemą gyvenime ar karjeroje. Šioje knygoje rasite tikrai daug patarimų kaip „išsivalyti“ savo užimtą gyvenimą: kaip planuoti susitikimus ar pasitarimus, kaip įprasti sakyti „ne“, kaip vertinti materialius dalykus, kaip branginti laiką ar miegą, kokiais kriterijais samdyti žmones ir taip toliau.

Spalvota cat komandos išvestis

Visi yra susipažinę su cat komanda ir nerasi turbūt nei vieno prie Linux dirbančio žmogaus kuris tos komandos nebūtų panaudojęs. Vienas iš dalykų kuris man labai patinka ir labai seniai naudoju - tai cat komanda su teksto spalvinimu kurį duoda Pygments biblioteka. Pirmiausiai įdiegiame Pygments Tai viena populiariausių Python bibliotekų, tai ją įdiegsite taip: sudo pip install Pygments Komandos aliasas Aliasą teisingiausiai būtų įsirašyti į .bash_aliases arba .zsh_aliases, tik prieš tai įsitikinkite, kad šie failai yra source’inami. alias cat="pygmentize -g" Jeigu esate patyręs Linux naudotojas ir su BASH dirbate tikrai daug, tuomet cat komandą reikėtų palikti ramybėje ir susikurti kažkokį kitą aliasą, pavyzdžiui ccat ar hcat, nes cat perrašymas turi trūkumų. Pavyzdžiui: cat ~/.vimrc | head -n 2 " No compatible mode makes VIM more friendly than old VI set nocompatible *** Error while highlighting: IOError: [Errno 32] Broken pipe (file "/usr/lib/python2.7/codecs.py", line 370, in write) *** If this is a bug you want to report, please rerun with -v. Štai kaip tai atrodo su kodo gabalu: Spalvotas cat komandos turinys Nuotraukoje gal ne pats geriausias pavyzdys, nes su visokiais nestandartiniais formatais kaip JSX ar pan. Pygments biblioteką galima apkvailinti. Bet daugeliui įprastinių formatų - veikia tikrai neblogai. Ne taip seniai esu rašęs, kad tą pačią Pygments biblioteką dar galima panaudoti ir API išvestims spalvinti terminale.

Paveiksliukai ir ikonėlės el. laiškuose

Turbūt kiekvienam web programuotojui ne kartą yra tekę siųsti paveikslėlius, nuotraukas ar ikonėles el. laiškuose. Jokia čia naujiena. Deja, pats paveiksliukų procesas vistiek yra labai problematiškas, nes yra trys būdai kaip paveiksliukai gali būti išsiųsti ir kiekvienas turi savo trūkumų. Paveiksliukai iš interneto Pats paprasčiausias ir lengviausias būdas, tai dėti el. laiškuose nuotraukas su nuorodomis į internetą: <img src="http://example.com/nuotrauka.png" alt="Logo" /> Paprasčiausias būdas turi daugybę trūkumų: Paveiksliukams būtinai turite nurodyti protokolą (HTTP arba HTTPS) ir domeno adresą. Paveiksliukai visada turi būti prieinami. Jeigu kažkas laišką žiūrės iš archyvų, tarkime po kelių metų, turite užtikrinti, kad tas kelias vis dar pasiekiamas. Gmail ir kiti pašto klientai pirmiausiai paklaus laiško skaitytojo ar rodyti nuotraukas. Šis tikrinimas daromas, nes paveiksliukuose dažnai slepiami „tracking pikseliai“ arba kitos blogybės. Šį būdą rekomenduočiau mažiausiai. Paveiksliukai iš prisegtuko Kitas dažnas būdas siųsti media yra prikabinant ją prie laiško, kaip prisegtuką. Toks būdas turi tokius trūkumus: Skaitytojas laiškų sąraše mato, kad el. laiške yra prisegtų failų, kas nėra korektiška. Turite būti atsargūs kaip tuos failus vadinate, nes galite nepraeiti pro el. pašto filtravimo programą. Tai papildomas vargas jeigu susirašinėjate toliau. Kad laiško istorija būtų tvarkinga, turėsite tuos paveiksliukus persiųsti ir kitiems. Jeigu nepersiųsite, tai kažkas kam rodote laišką gali nematyti ekrano nuotraukų ar kitų svarbių dalykų kurie buvo originaliame laiške. Paveiksliukai iš base64 reikšmės Tai labai populiarus būdas visą nuotraukos turinį užkoduoti ir prikabinti standartiniais būdais prie laiško: <img src="data:image/png;base64,iVBORw0KGgoAAAANS...." alt="Logo" /> Tokiu būdu laimėsite: Skaitytojas nematys, kad el. laiške yra prisegtukų. Persiunčiant laiškus jie - neišsikraipys. Šiuo būdu HTML elementai taip pat gali būti fonui naudojami (kaip background-image: ...). Nereikia rūpintis paveiksliukų atnaujinimu kai naršyklė ar pašto klientas juos užkešuoja. Nors internete base64 nuotraukų konvertavimų yra be galo daug, bet ar žinojote, kad viską galite padaryti standartinėmis Linux komandomis? echo "data:image/png;base64,$(base64 -w 0 ikonele.png)" Šis būdas taip pat veiks ir Macos. Tiesa, trūkumų taip pat yra: Sunku suprasti koks paveiksliukas ir kurioje vietoje panaudotas (nes nėra failo vardo). Visokie redaktoriai gali supykti už itin ilgas eilutes, jeigu paveiksliukas sveria tikrai daug. Bet ignoruoti šias bėdas verta, nes klientai turės korektišką media.

Knygos „Automate it!“ apžvalga

Nors mano tinklaraštis labiau skirtas patyrusiems programuotojams ir retai kada rašau profesijos pradedančiųjų temomis, bet šį kartą tiesiog nesusilaikiau. Jeigu tik man kas būtų parodęs šią knygą prieš 10 metų! Gaila, tada ji nebuvo išleista. Humble Book Bundle kartu su kitomis knygomis įsigijau - „Automate it!“ (aut. Chetan Giridhar). Knygos „Automate it!“ viršelis Kam skirta knyga Mokamųjų resursų, taip vadinamųjų „tutorial“, internete rasite pilna. Tiek knygų pavidalu, tiek interaktyvių interneto svetainių, tiek mokomųjų video. Bet va knygų su darbo eigomis, tikro gyvenimo pavyzdžiais ir tikra apčiuopiama nauda - surasti bus sunku. Čia - viena jų. Iš esmės užtenka vos paviršutiniškai mokėti Python programavimo kalbą (nes visos problemos sprendžiamos su ja) ir galima kapstyti gilyn! Puiki knyga ruoštis Python darbo pokalbiui Laukia pirmojo darbo paieška? Ši knyga turbūt pirmoji kuri turėtų būti atversta. Tokio pokalbio metu, neturint didelio portfolio į daug klausimų gali tekti atsakyti neiginiais: „nemoku“, „nebandžiau“, „neteko“. Perskaičius ir kiek susipažinus, galima to išvengti. Žinoma, ši knyga nėra kažkoks garantas, kad Jus priims. Per darbo pokalbį būtina „save parduoti“. Todėl kuo daugiau paliesite tikro gyvenimo IT problemų, tuo didesni šansai gauti darbą. O visa kita - per 10 metų išmoksite. Svarbiausia, kad priimtų. Ką galima rasti knygoje ir ko išmokti? Gerai, trumpais skyriais ir nenuobodžiai aprašyta knyga Jus supažindins su tokiais dalykais: Web scraping’u - duomenų iš interneto parsisiuntimu ir analizavimu. Resursų iš interneto parsisiuntimu (pavyzdžiui nuotraukų iš „Google Images“). REST API (pavyzdžiams naudoti tokie kaip Gihub REST API). Interneto puslapių naršymas su Selenium. Darbas su CSV ir Excel failais. Duomenų pildymas, formulės, skaitymas, grafikų darymas. Darbas su PDF failais (kūrimas ir skaitymas). SMS siuntimai ir balso pranešimai per Twilio sistemą. Itin populiarių Python bibliotekų, kaip Flask ar Tornado, praktiniai panaudojimai. El. laiškų siuntimas ir skaitymas iš Gmail. SMTP, TXT/HTML el. laiškų formatų ir kitų dalykų / problemų paaiškinimai. PowerPoint prezentacijų kūrimas (verslo ataskaitoms rengti). Savo API kūrimas. Jinja2 šablonų sistema. Twitter aplikacijos kūrimas automatiniam žinučių rašymui. Zapier pajungimas į automatizavimo procesą. Bot’ų kūrimas. Darbas su paveiksliukais (pvz. vandens ženklo kūrimas). Veidų atpažinimas. Duomenų analizė ir vizualizavimas su Pandas biblioteka. Laiko juostos. Turinio tikrai daug. Per daugiau nei 10 programavimo metų su visomis išvardintomis problemomis yra tekę dirbti. Ir turbūt retas web programuotojas tokių pačių dalykų išvengė. Man patiko, kad pavyzdžiai gana šiuolaikiški ir naudojami dalykai yra tokie kuriuos tikrai panaudosi gavęs darbą rimtoje įmonėje. Taigi, 10 balų, tikrai rekomenduočiau!

Statiniai puslapiai su Docker

Šių laikų IT tendencija - mikroservisai. Todėl net paprasčiausius projektus bandoma konteinerizuoti. Net statinius projektus. Kaip tik tokie yra visi mano projektai. Ne išimtis ir šis tinklaraštis. Konteinerizuotus projektus lengviau deploy’inti, monitorinti, daryti atsargines kopijas ir svarbiausia priežastis - plėsti (angl. „scale“). Paversti savo statinę svetainę į konteinerizuotą mikroservisą yra itin lengva kai tai darai su Docker. Įsivaizduokime, kad mūsų projektas guli src kataloge. Tuomet kataloge virš jo susikurkime Dockerfile: FROM nginx ENV APP_HOME /usr/share/nginx/html WORKDIR $APP_HOME COPY src $APP_HOME EXPOSE 80 Tiek nedaug reikia nurodyti nginx, kad mūsų projekto katalogą įkeltų į tipinę nginx vietą - /usr/share/nginx/html. Pagal nutylėjimą nginx rodys viską iš šio katalogo (paveiksliukus, media, HTML ir pan.). Viską galėtume gerokai sutrumpinti, pavyzdžiui neturėti $APP_HOME env kintamojo kūrimo - bet tada teks ilgą kelią rašyti kelis kartus. Todėl vadovaukitės DRY principu. Galima neturėti WORKDIR $APP_HOME sakinio, bet jis labai gelbėja, kada norite prisijungti prie Docker konteinerio ir pažiūrėti ar yra ten kažkokių problemų. Tuomet komanda docker exec -it svetaine bash Jus nukels tiesiai į /usr/share/nginx/html - sutaupysite laiko. Sukurti atvaizdą galima su: docker build -t svetaine . O pasinaudoti juo taip: docker run -p 8001:80 svetaine Ir naršyklėje surinkę adresą http://127.0.0.1:8001 matysite savo svetainės turinį. Tą patį galima padaryti ir produkcinėje sistemoje. Tuo pačiu tai dar viena puiki alternatyva Python SimpleHTTPServer arba Node http-server moduliui.

Geriausi patobulinimai Django 2 versijoje

Django programuotoju tapau dar 2009 metais, kada kūrėjai turėjo tik 1.1 platformos versiją. Tada, be eilinio ir dar vieno framework’o pasaulyje, Django išsiskyrė puikiu scaffolding’u - Django administracija. Aišku, per kelis metus konkurenciniai framework’ai šį privalumą tiesiog „suvalgė“. Per devynis metus pasikeitimų šiame framework’e įvyko tikrai daug. 2017 metų gruodį buvo išleista dar viena versija, pagrindinė, Django 2.0. Po keleto mėnesių migravau į šią versiją projektą iš 1.11 (kurį pradėjau nuo 1.4 versijos) į Django 2.0. Po šiokios tokios praktikos išrinkau geriausius šios versijos patobulinimus. Python 3 palaikymas Net ne palaikymas, o privalomybė. Nauja Django versija veikia tik su Python 3.4 arba aukštesnėmis versijomis. Tokiose situacijose labai praverčia konteinerizavimai - man užteko Dockerfile pakeisti Python versiją ir viską supushint’i į produkcinę sistemą. Išties gera naujovė. Kiek matau iš operacinių sistemų priklausomybių ir atviro kodo projektų - Python 2 labai sunku atsikratyti, nors praėjo daug metų kada Python 3 buvo išleistas. Draugiška mobiliems administracija Šio pakeitimo labai laukiau ne vienus metus. Yra tekę ne vieną kartą dėti ant Django administracijos temą, kuri paverčia administraciją draugiška mobiliems įrenginiams. Dabar to daryti nereikės, viskas - standartiniais būdais. Django 2.0 su mobilios versijos palaikymu Draugiškas adresų rašymas Regexp’as adresuose man atrodė kaip vienas nepraktiškiausių dalykų Django framework’e. Dabar adresus galima aprašinėti gana gražiu formatu: # senas variantas: url(r'^straipsniai/(?P<year>[0-9]{4})/$', views.artcles), # naujas variantas: path('straipsniai/<int:year>/', views.artcles), Autocomplete laukai administracijoje Tai itin patogu kada kažkoks turinys yra grupėse ir ieškote grupės pavadinimo. Pavyzdžiui prekių grupės, puslapių kategorijos, naudotojų tipai. Daugiau apie autocomplete laukus Django dokumentacijoje. Metodas values_list() Šio patobulinimo turbūt laukiau labiausiai. Dažnai iš duomenų bazės reikia sąrašo tik su tam tikrais laukais. Rails’ai turi pluck komandą - tai čia praktiškai ta pati Django alternatyva. Pavyzdžiui jeigu <select> HTML elementui ruošite duomenis iš duomenų bazės, tai juos galite paimti tokiu formatu: >>> Modelis.objects.value_list('id', 'year') <QuerySet [(1, '2016'), (2, '2017'), ...]> Turbūt dažniausiai naudojama mano operacija programuojant. Puslapiavimas kai išeinama iš rėžių Anksčiau tokius dalykus darydavau rankiniu būdu: žinodamas kiek yra puslapių patikrindavau ar norimas puslapis nėra už jo ribų ar prieš (dabartinis puslapis didesnis už 0, bet mažesnis arba lygus viso puslapių skaičiui). Dabar Paginator.get_page() gali „išmesti“ klaidą EmptyPage ir informuoti kada tai įvyksta. Pavardė gali būti 150 simbolių Kvaila, bet daug kartų teko taisyti šį limitą, kai standartinių 30 simbolių nepakakdavo. Dabar, net 150 simbolių! Daugiau pakeitimų Čia tikrai ne viskas. Čia tik geriausi, mano manymu, patobulinimai. Pats patobulinimų sąrašas įspūdingai ilgas, jį galite rasti Django oficialiame pranešime. Į ką visada verta atkreipti dėmesį, tai į žemiausiai aprašytą skyrelį „Features removed in 2.0“. Beveik visada tokiuose skyriuose rasdavau ką nors ką naudodavau projekte. O tai labai praverčia, prieš migruojant versiją.

Kompiuterių administravimas su Ansible

Būdamas tinklapių programuotojas (pagrinde) jau porą metų neturiu savo kompiuteriuose LAMP stack’o (taip vadinamas derinys su programine įranga: apache + php + mysql). Ne dėl to, kad PHP programuoju retai, bet tiesiog naujosios technologijos pakeitė požiūrį į kaip turi būti konfigūruojama darbo aplinka. Iš esmės LAMP’ą pakeitė Docker. Tinklaraštyje galima rasti straipsnių kaip pasikeisti LAMP’ą į Docker arba kaip kai kuriuos elementus pakeisti su juo, pavyzdžiui rašiau apie Mysql paleidimą su Docker. Tačiau anksčiau ar vėliau kiekvienas IT žmogus susidurs su ta pačia problema kurią reikės išspręsti - naujas kompiuteris ar serveris. Man, turinčiam 4 kompiuterius ir 3 serverius diegimas ir konfigūravimas rankiniu būdu užimtų per daug laiko. Todėl jau labai seniai sistemų automatizavimą atlieku su Ansible. Kaip visada tokias konfigūracijas būtinai paviešinu savo Github profilyje. Taip ir Ansible konfigūracijas galima rasti Github platformoje. Iš esmės turint viename kompiuteryje Ansible paketus aš galiu pilnai sutvarkyti kitas mašinas. Ansible diegimas Ansible įdiegti galima iš paketų valdiklio. Atitinkamai viena iš šių komandų: sudo apt-get install ansible # Ubuntu sudo aptitude install ansible # Debian sudo yum install ansible # Centos sudo dnf install ansible # Fedora sudo brew install ansible # Jeigu esi turtingas Ko gali reikėti naujuose serveriuose / kompiuteriuose Sąrašas būtų begalinis, todėl pademonstruosiu kaip atrodo realus diegimas / konfigūravimas. Jeigu dirbčiau su diagiakalbyste reikalaujančiais projektais, tai norėčiau visų kalbų sistemoje palaikymo. Jas įdiegčiau taip: ansible-playbook -i 12.34.54.78, locales.yml Kur 12.34.54.78 yra IP adresas. Kablelis reikalingas atskirti „inventorių“ nuo mašinos adreso. Apie tai čia nerašysiu - reikėtų atskiro straipsnio. Komandos gale paduodu konfigūracinį failą kurį esu išdirbęs ir kuriame yra instrukcijos surašytos lokalių diegimui, priklausomai nuo to kokią OS turite. Priminsiu, kad šį ir kitus failus galite rasti mano Ansible Github repozitorijoje. Praktiniai pavyzdžiai Noriu, kad nauja mašina turėtų mano namų katalogo konfigūracijas: ansible-playbook -i $IP, dotfiles.yml Reikia įdiegti docker ir docker-compose? Paskaitykite abiejų diegimo instrukcijas - belekiek darbo. O čia, tik viena komanda: ansible-playbook -i $IP, docker.yml ansible-playbook -i $IP, docker-compose.yml Tingite tvarkyti Python Pillow palaikymą visiem failų formatams? Ranka darant sutvarkyti be StackOverflow - neįmanomas darbas. Bet su viena Ansible komanda: ansible-playbook -i $IP, pil.yml Reikia įrankių programavimui? Priklausomai nuo to kokia kalba dirbate: ansible-playbook -i $IP, ruby_dev.yml ansible-playbook -i $IP, python_dev.yml ansible-playbook -i $IP, php_dev.yml ansible-playbook -i $IP, javascript_dev.yml Šis ir daugiau konfigūracijų yra mano Ansible konfigūracijų Github repozitorijoje. Išmėginkite, pasitobulinkite pagal savo poreikius ir liaukitės švaistyti laiką neautomatizuotoms problemoms spręsti. Serverių atnaujinimas (video) Kai Nagios’as praneša, kad vienas ar kitas serveris turi programinės įrangos atnaujinimų, kuriuose ištaisytos saugumo problemos, atnaujinu juos su Ansible: Serverių atnaujinimas su Ansible Jeigu svarstote automatizuoti savo kompiuterių ir serverių priežiūrą - Ansible tikrai rekomenduoju.

Redis ant Docker

Jau esu rašęs ne vieną straipsnį apie tai koks geras dalykas yra Docker. Taip pat minėjau kaip lengva įsidiegti Mysql su Docker. Bet ar žinojote, kad kokį Redis pasikurti yra žymiai lengviau? Šiuolaikiniai web’ai, ypač turintys daugiau lankomumo, tikriausiai neišgyventų be Redis. Ypač kai kalbame apie visokius banerius, statistikos rinkimus, A/B testavimą. Ubuntu operacinėje sistemoje Redis įdiegti labai lengva su paketų valdikliu: apt-get install redis-server Tai tikrai nėra blogas variantas ir galbūt nėra didelio tikslo užkrauti viską ant Docker. Bet ant Docker pats diegimas taip pat ypatingai paprastas: docker run --name redis-serveris -p 8000:6379 -d redis Prisijungti prie Redis galima dviem būdais. Jeigu turite redis-cli (įdiegti galima įdiegus redis-tools): redis-cli -p 8000 Arba pasinaudojant tuo pačiu Docker: docker exec -it redis-serveris redis-cli Praktinis išbandymas Redis su Docker: Redis išbandymas su Docker Produkcinėje sistemoje vienas iš Redis privalumų ant Dockerio būtų tai, kad skirtingiems projektams (arba mikro projektams) galima turėti skirtingus Redis konteinerius. Taip ne tik duomenys nesusimaišytų, bet ir saugiau būtų.

Kokias programas naudoju 2018 metais

Anksčiau labai mėgdavau skaityti kitų tinklaraščių post’us kur autoriai rašo kokią programinę įrangą naudoja. Patikdavo, nes vis rasdavau kokių nors geresnių įrankių kurie didindavo produktyvumą. Ankstesniuose mano straipsniuose galima rasti kokias programas naudojau 2013 metais arba kokias programas naudojau 2010 metais. Dabar, po daugiau nei 10 metų programavimo, lyginant praėjusius įrašus mano programų stackas labai minimalistinis. Ką darau tik įdiegęs OS Pats pirmas dalykas ką visada padarau įdiegęs operacinę sistemą - ištrinu daugybę nereikalingų programų. Taip ne tik taupau disko vietą (neženkliai), bet ir internetą (nes nereikia siųsti atnaujinimų), laiką (nereikia laukti kol atnaujinimai parsisiųs ir įsidiegs), bet dar programos neatsiranda šian bei ten (pavyzdžiui launcher’iuose). Taigi - įdiegiam OS ir ištrinam visokius Thunderbird, žaidimus, muzikos grotuvus ir įrankius kurie nereikalingi. Kokias operacines sistemas naudoju Pirmiausiai turiu kelis kompiuterius. Macbook’ą nes reikia PixelMator ir jokia kita programinė įrango jo formato neatidaro. Na ir kiek rečiau - Photoshop. Turiu stacionarų kompiuterį ir keturis ekranus prie jo. Jame - naujausias Ubuntu. VIM iškeičiau į Sublime Turiu žaidimų kompiuterį su Windows 10. Tik žaidimams skirtą. Per 10 metų išbandžiau labai daug operacinių sistemų: Windows Xp / Vista / 7 / 10, Ubuntu pradedant 9 ir baigiant 17, Gentoo, Redhat, Fedora, Elementary OS, Debian. Neturiu operacinėms sistemoms priekaištų ir niekam nieko rekomenduoju. Verta visas išmėginti, tikrai. Dedikuota programinė įranga Ko stengiuosi nenaudoti tai dedikuotų programų. Tokios programos, kurių WEB išvaizda perkelta į Desktop programas: Trello, Todoist, Skype ar kt. O minusų tikrai daug. Disko vieta, interneto srautas, atnaujinimai ir pan. Vienintelis tokių programų privalumas greičiausiai yra offline režimas. Bet daugelis SAAS’ų jau turi ir offline režimą. Beveik viskas telpa į naršyklę Daug kas dedikuotas programas naudoja, kad naršyklėje sumažinti vienu metu atidarytus tab’us. Aš kitaip sprendžiu šią bėdą - uždarau ko tai akimirkai nereikia. Dažniausiai naršyklėje yra trys-šeši vienu metu atidaryti tab’ai. Bene pagrindinė, mano, kaip programuotojo, programinė įranga - naršyklė. Tenka naudoti Chrome, Firefox, Safari naršykles. Pagrinde naudoju Chrome. O jame jau pasileidžiu kada ką reikia: Trello (praėjusiame straipsnyje rašiau kaip aš naudoju Trello), Todoist, Google Calendar, Gmail, Gitlab, PivotalTracker ir pan. El. pašto klientas Kodėl nenaudoju el. pašto kliento? Nes naudoju kelis kompiuterius ir atrodo neprotinga visur diegti pašto klientą, prisijungimus išsaugoti. O Gmail’ą galima atsidaryti iš bet kur. Tuo pačiu visas pašto dėžutes nukreipiu į vieną pašto dėžutę, kad nieko tikrintis papildomai nereikėtų. O ir patį paštą stengiuosi tikrinti tik kokius 2-3 kartus per dieną. Anksčiau turėjau jam didelę priklausomybę. Ir žinoma, būtinai reikia laikytis Inbox Zero principo. Biuro programinė įranga LibreOffice tenka atsidaryti labai labai retai. 95% laiko užtenka Google Drive ir esu juo labai patenkintas. Kartais tenka dokumentus tvarkyti / patobulinti per mobilų įrenginį. O čia Google Drive yra puikus įrankis. Google Drive laikau sutartis, finansų apskaitą, visokius planus, ataskaitas, dokumentacijas. VIM iškeičiau į Sublime Vienas labiausiai atsipirkusių dokumentų - pavadinimu „Rekvizitai“. Labai patogu į vieną dokumentą surašyti savo banko sąskaitos numerį, individualios veiklos pažymėjimo numerį, adresus su pašto kodais ir pan. Praktiškai kas savaitę tenka atsidaryti šį dokumentą, kad kažkam tuos duomenis duoti. Programavimui skirta programinė įranga Terminalas - antra labiausiai naudojama programinė įranga. Apple Terminal arba Gnome Terminal čia pas mane visada atidarytas. Reikia paskaityti naujienas? Surenku curl delfi.lt:80 | less ir… Ne ne, juokauju. VIM iškeičiau į Sublime O terminale jau sukasi Tmux, Tmuxinator, Docker (su ElasticSearch, Redis, Memcached, Mysql ir Postgres), Zsh, VIM. Redaktorius VIM? Ne. Po 7 metų programavimo su VIM iškeičiau šį į kiek modernesnį - Sublime. VIM yra super redaktorius! Ir tikrai jį naudoju gana stipriai serveriuose. VIM iškeičiau į Sublime Man patinka, kad Sublime laikosi Ruby appsų principo - naudingas ir be nieko (angl. „useful by default“). Tik įdiegi Sublime ir turi absoliučiai viską. Reikia kokio specifiškesnės sintaksės? Gali neišeidamas iš Sublime viską turėti. VIM’e teks eiti Github’o paieškų keliu. Taip pat jeigu Sublime reikia kitokios temos ar kokio linter’io - vėlgi, viską gali turėti nepalikus redaktoriaus. Todėl čia ir atsiranda didelė praraja - VIM yra superinis redaktorius, bet kad paversti jį produktyviu - reikės labai daug produktyvaus laiko išmesti konfigūracijai, paieškoms, tobulinimui. Kaip ir daugelis, savo VIM konfigūracijas laikau GitHub’e. Su Sublime tokių dalykų daryti nereikės. Net ir labiausiai vaizduotę skatinančią platformą ant Sublime galima turėti per kelias minutes. Tūkstantis BASH skriptų Savo bin/ kataloge turiu kokį tūkstantį privačių ir viešų Bash skriptų. Mėgstu viską automatizuoti ir pamiršti. Žinoma, stengiuosi ir serveriuose kuo daugiau visko automatizuoti. Pavyzdžiui asmeniniai projektai deployinasi automatiškai Gitlab’o pagalba, jeigu testai praeina. Arba Nagios’as prižiūri daugiau nei 120+ taisyklių: serverius, svetaines, servisus ir pan. Man visada įdomu paskaityti kitų žmonių tokius straipsnius. Taigi jeigu turite savo sąrašą - būtų įdomu sužinoti.

Praktiškai patogi darbo eiga su Trello

Trello pradėjau naudoti 2012 metais. Naudoju iki šių dienų. Praėjo tikrai nemažai metų. Per tą laiką spėjau išbandyti kokį šimtą darbo eigų kurias galima rasti oficialiame Trello tinklaraštyje. Nuolat keisdavau darbo eigas nes, tai vienas, tai kitas, dalykas atrodė nepatogus arba gaišinantis laiką. Šiai dienai esu išgryninęs sistemą kuri yra be galo patogi, nereikalauja daug laiko ir svarbiausiai - galiu matyti visus projektus iš šalies (populiarus angliškas terminas „big picture“). Trello spalvų paletė Kiek tai kainuoja? Čia turbūt tinka pasakymas, kad Trello yra nemokamas kaip ir Gmail. Tačiau ir vienas ir kitas - siūlo papildomų funkcijų už gana nedidelį mokestį, siekiantį apie 10€ per mėnesį. Aš naudoju nemokamą planą, nes nėra poreikio Trello integruoti į kitas sistemas - jų nenaudoju. Darbo eigos taisyklės Turiu vieną lentą pavadinimu „Projektai“, kitą „Marketingas“ ir pan. Vienoje lentoje, vienas stulpelis yra vienas projektas (pažymėta raidėmis P1, P2 nuotraukoje aukščiau). Galėčiau pasakyti, kad toks išdėstymas Trello yra vos ne vienintelis norint matyti „big picture“. Įmonėje dirbant patogu skirti vieną lentą vienam projektui. Dirbant su asmeniniais projektais ir su nedidele komanda - tai yra ne tik nepatogu, bet ir daug laiko reikalauja. Kiekviena užduoties kortelė turi spalvą: Trello spalvų paletė Prioritetus peržiūriu dažnai - bent kartą dienoje. Klaida pažymėta kortelė - visada aukščiausias prioritetas, nesvarbu didelė ta klaida ar ne. Na, ir dirbant su komanda labai svarbu naudotis sąrašais (angl. „checklist“) ir komentarais kortelėje. Kas jeigu projektas turi šimtus užduočių? Pripažinkite - visų jų vistiek nepadarysite, norite to ar nenorite. Turite tam to laiko ar ne. Tokiu atveju (matyti nuotraukoje), sukuriu kortelę „Darbų rezervas“ ir į sąrašą sudedu viską ką galvoju apie projektą. Dažniausiai tai tokie darbai, kuriuos būtų smagu matyti, bet realybėje jie nei neša naudą nei didelės prasmės turi. Angliškai tai dar vadinama „icebox“. Kaip prasideda mano rytas Šeštą ryto (tada mane pažadina „Xiaomi Band 2“ apyrankė) pradedu dieną. Nusiprausęs pasidarau pusryčius, kavos puodelį ir oficialiai pradedu darbo dieną (maždaug 06:20). Pasitikrinęs el. paštą susidedu visus komentarus į Todoist (tik asmeniniai dalykai - jokių IT projektų) ir Trello (tik su klientais ir projektais susiję dalykai). Ir visus el. pašte esančius laiškus suarchyvuoju, kad žinočiau, jog nieko nepraleidau. Tada prioritizuoju pačius darbus. Iš pradžių peržiūriu kiekvieno projekto stulpelį ir perrikiuoju darbus, nes naujausi dažnai būna pačioje apačioje. Surikiavęs darbų svarbą pagal projektą imuosi kitos planavimo dalies - dienos planavimo. Prie kiekvienos kortelės pasižymiu vieną arba dvi to projekto užduotis kurias norėsiu atlikti šią dieną. Kadangi užduočių kiekis nėra didelis (tik viena arba dvi smulkios užduotys) - tai planą praktiškai visada įvykdau iki dienos pabaigos. Čia bene pats svarbiausias ir pats produktyviausias dalykas ką galite padaryti bet kur - planuokite itin smulkiai. Neturėkite užduočių kurios trunka 2 ar daugiau valandų. Suskaldykite taip smulkiai, kad darbo būtų vos 10-15 minučių. Tokiu būdu įveiksite net ir didžiausius kalnus. Ar toks mėtymasis nuo projekto ant kito projekto yra produktyvus? Jeigu skaitytumėte knygas, tai daugiau nuomonių rastumėte, kad - ne. Man pačiam jis atrodo tikrai produktyvus, nes tada nei vienas projektas nėra lėtinamas, visuose projektuose matau progresą, visi projektai progresuoja vienodai, nėra numestų ar ignoruojamų projektų. Kaip vertinu Trello? Jeigu jis būtų mokamas - tai greičiausiai apsistočiau pas šio konkurentus. Konkurentai, kiek teko matyti, turi daug daugiau galimybių. Kadangi įrankis nemokamas, patogus ir velniškai greitas - naudoti tikrai verta. Naudoju ir Trello API, kad automatizuoti kai kuriuos darbus arba „apskaičiuoti produktyvumą“. Gali būti labai smalsu kaip kiti naudoja šį įrankį - pažiūrėkite oficialų Trello tinklaraštį. Jame labai daug įmonių ir samdomų darbuotojų dalinasi savo įspūdžiais, darbo eigom ir pan. Tikrai ką nors rasite. Būtinai išbandykite ;)

Praktinis Docker panaudojimas su Mysql

Į Docker’į pereina tikrai ne kiekvienas programuotojas. Keista, nes praktiškai jiems ir buvo sukurta ši platforma. Ir dažnai kalbėdamas su programuotojais girdžiu kaip jie „šiukšlina“ savo sistemas / kompiuterius, kovoja su paketų priklausomybių problemomis, senoje operacinėje sistemoje bando įdiegti naujus paketus ir pan. Visas šias problemas turėtų išspręsti Docker. Štai kaip galima turėti vieną populiariausių duomenų bazių sistemų kompiuteryje be jokio vargo: vos vienos eilutės dėka. Docker su Mysql - tik viena eilutė! Docker Mysql diegimas Galima įdiegti Mysql su apt-get install mysql-server (arba bet kuriuo paketų valdikliu), bet galima visa tai padaryti daug lanksčiau, su Docker: docker run --name vietinis-mysql \ -v ~/saugykla/mysql:/var/lib/mysql \ -e MYSQL_ROOT_PASSWORD=root \ -p 127.0.0.1:3306:3306 \ -d mysql:latest Ir tada turint mysql-client paketą, galima prisijungti prie naujai sukurtos duomenų bazių sistemos: mysql -h 127.0.0.1 -u root -p Be mysql-client į duomenų bazę galima patekti su: docker exec -it vietinis-mysql mysql -u root -p Kuo tai geriau nei sisteminė biblioteka? Jeigu kalbėti tik apie vieną įrangą Dockeryje - Mysql - tai niekuom. Tačiau programavime dažniausiai su viena programine įranga neišsiversite, o čia - Docker jau turi labai daug privalumų. Jeigu esate Linux „senbuvis“, tai tikrai žinosite, kad įdiegti senesnę programinę įrangą į sistemą yra labai sunku. Su Docker - jokių problemų įdiegti bet kurią Mysql versiją. Sistemoje ne visada turėsite naujausią Mysql versiją. Turėsite tokią, kokią operacinės sistemos programuotojai pažymi kaip „stabilią“. Jeigu esate tinginys ir operacinės sistemos dažnai neatnaujinate - įdiegti kažkokį paketą be priklausomybių problemų bus tikras galvos skausmas. Taip pat yra ir su Docker konteinerių pašalinimu. Pabandėte ir jau nebereikia? Tiesiog ištrinate konteinerį su docker rm. O kas jeigu vienu metu reikia turėti net kelias Mysql versijas? Kadangi Mysql yra ganėtinai „backwards-compatible“ tai poreikis gali būti mažas. Labiau tokių problemų iškiltų su ElasticSearch arba Postgres.

Xiaomi Mi Mix 2 telefono apžvalga

2017 Rugsėjo mėnesį Xiaomi kompanija išleido labai gerai atrodantį Xiaomi Mi Mix 2 telefoną. Tokį ir pats įsigijau praėjus vos mėnesiui nuo išleidimo. Išsamią specifikaciją galima rasti internete, o svarbiausios charakteristikos būtų tokios: Ypatybė Reikšmė Ekranas Beveik 6" (coliai) SIM 2 SIM kortelės Operacinė Sitema MIUI 9(galvokit kaip naujausias Android'as, tik geriau) Kamera galinė 12 MP Kamera priekinė 5 MP Bluetooth 5 versija Baterija 3400 mAh Kaina 400-500 €(arba pigiau, jeigu iš skelbimų) Ir atrodo stilingai: Xiaomi Mi Mix 2 - protingesnis net už savininką! Visa komplektacija su dėžute atrodo taip: Xiaomi Mi Mix 2 dėžutė ir priedai Kamera Pirmiausiai labiausiai nuvylęs dalykas ne tik mane, bet ir tūkstantį komentatorių internete - prastos kokybės kamera. Nufotografavus dienos šviesoje žmogų jo plaukai tampa sulipę, oda atrodo taip, tarsi būtumėte nuotrauką išsaugoję su kokia 70% JPEG kokybe. Deja, kiek teko bandyti programinės įrangos, kuri šią bėdą sprendžia - pagerinti nuotraukų kokybę, darytų su Xiaomi, nepavyks. Video įrašymo kokybė tikrai nebloga. Įrašomas garsas irgi neblogas. AUX Nebėra ausinių jungties. Bet turbūt jau seniai laikas pereiti prie belaidžių ausinių? Su standartine dėžute gausite USB C į AUX adapterį. Veikia puikiai ir iškart, vos įkišus adapterį. Baterija Gal dėl pačios operacinės sistemos optimizacijų, o gal dėl baterijos - veikia išties ilgai. Net ir daugiau naudojantis galit naudotis telefonu 2 dienas be stabdžių. Mažiau naudojantis gali ištemti 4-5 dienas. Baterija yra nekeičiama (priklijuota). Todėl ją pasaugoti vertėtų - internete yra straipsnių / video kaip rūpintis įrenginių baterijomis. Ekranas Dūžta. Ganėtinai lengvai. Numesite ant asfalto ar betono iš 1M aukščio ir greičiausiai turėsite skilusį telefoną. Iš patirties - taip vargu ar atsitiktų su Samsung Note ar Sansung S telefonais. Prie telefono ateina ir dėkliukas. Iš išvaizdos - labai geros kokybės. Bet jo plastmasė tokia, kad neatlieka didelio apsaugos vaidmenio ir numetus vos iš 1M - rasite ant dėkliuko įskilimus. Ekranas susibraižo ypatingai lengvai. Numesite ant smelėto grindinio ir pakelsite - greičiausiai turėsite telefoną su įbrėžimais. Dėl savo pločio ir vietos išnaudojimo ekranas yra ypatingai patogus, jautrus, malonus liesti, žiūrėti. Išnaudota praktiškai visa erdvė (gal 95%) vien ekranui. Ekraną pakeisti gana sunku. Ne tik dėl naujo telefono modelio, bet ir dėl klijų kiekio reikalingo įsibrauti į telefoną. Kaip ir dauguma telefonų turi apačioje mirksintį LED’ą, todėl žinosite jeigu telefone iššoko koks nors pranešimas. Keramika Šio telefono didžiausias marketinginis triukas - keraminis telefonas. Tikrai nepajusite tos keramikos, telefonas atrodo kaip koks stiklinis ir tiek. Nėra kuo ir žavėtis. Deja. Pakrovėjas ir pakrovimas Šiame telefone yra USB C jungtis. Todėl iš senesnių įrenginių pakrovėjas netiks. Telefonas pilnai pasikrauna per 30 minučių ir nustoja krautis. Kad nustoja krautis rodo tai, kad tiek telefonas tiek pakrovėjas vėl tampa šaltas. Ar labai įkaista telefonas kraunamas? Visiškai ne. Labai nežymiai įšyla tiek pakrovėjas, tiek telefono galas. Skambučiai, SMS, naršymas Skambinimas, žinučių rašymas ir naršymas internete labiau yra operacinės sistemos nuopelnas. Viskas patogu, greita. Gal tik galerijos standartinė programa yra nepatogi lyginant su tipine Android galerija. Apskritai šnekant MIUI operacinė sistema (ar apvalkalas) yra daug kartų patogesnis už tipinį Android apvalkalą (angl. „launcher“). Atrakinimas piršto antspaudu Veikia įspūdingai gerai ir greitai. Piršto skaitytuvas yra telefono gale-centre, labai patogioje vietoje. Telefoną atrakinsite akimirksniu. Tai sakyčiau vienas geriausių dalykų (po baterijos) telefone - telefonas ne tik išlieka saugus (nes užrakintas), bet atrakinimui nesugaišite nė sekundės! Dizainas Telefonas tikrai atrodo kokybiškas, gražus ir patogus. Dėl savo stiliaus kuris neturi jokių spec. žymeklių ar logotipų net labai sunku yra pasakyti iš toliau koks tai telefonas. Gal net kažką pavyktų apgauti, kad čia naujasis Iphone X. Išvados Trumpai tariant - už 500 € - tikrai neverta. Trapus ekranas ir prasta fotografavimo kokybė didžiulis minusas. Todėl už tokią sumą geriau žiūrėtis Samsung produkcijos. Arba Apple - jeigu įperkat. Visa kita labai puikiai padaryta, nors to marketinginio dalyko nelabai pajusite - keramikos. Be to, gi nežiūrėsit į telefono galą vien dėl to, kad ten yra keramika? Greičiausiai turėsite dėkliuką telefonui, kuriuo uždengsite visą marketingo rezultatą.

Knygos kurias būtina perskaityti

Esu išsikėlęs tikslą perskaityti 1000 knygų per gyvenimą. Perskaičius penktadalį, virš 200 knygų, skubu pasidalinti geriausiomis. Tokiomis, kurios mano manimu prentenduotų į „būtina perskaityti“. Ką reiškia „būtina“? Skaitau tik asmeninio tobulėjimo knygas. Todėl sakydamas „būtina“ turiu omeny, kad perskaitytos knygos atnešą vertę gyvenimui, mąstymui ar praktinę naudą. Perskaitęs tokią knygą kažkuo tampi pranašesnis. Ir aišku, labai smagu, kai nupirkta knyga yra naudinga, o ne šiaip - laiko praleidimas. Knygų sąrašas kurias būtina perskaityti Rekomenduočiau perskaityti tokias: Pavadinimas, Autorius Puslapiųskaičius Never Be Lied to AgainLieberman, David J. Ph.d. & Davidson, Richard M.144 Linux Administration HandbookNemeth, Evi & Snyder, Garth & Hein, Trent R.1041 Protokolo PagrindaiLydeka, Arminas343 Head First Design PatternsFreeman, Elisabeth & Freeman, Eric & Bates, Bert & Sierra, Kathy & Robson, Elisabeth691 1001 Motivational Quotes for Success: Great Quotes From Great MindsVilord, Thomas J.264 Understanding StocksSincere, Michael210 Strength Training Anatomy-3rd EditionDelavier, Frederic151 Moterų fotografavimo menasAmes, Kevin386 Laisvieji informaciniai sprendimaistrong>Žilvinas Jančoras, Mykolas Okulič-Kazarinas275 Dont Make Me ThinkKrug, Steve191 Pro GitChacon, Scott279 Agile Web Application Development With Yii 1.1 and PHP5Winesett, Jeffrey368 1,001 Facts that Will Scare the Shit Out of YouMcneal, Cary359 How Math Can Save Your LifeStein, James D.260 Happy Together 500 Things to Do for and with Your SweetheartShafer, Ken206 Preparing For The Project Management Professional (Pmp) ExamMichael W. Newell, PMP, ENP430 Improving Your Project Management SkillsRichman, Larry221 Simply a Great Manager: The 15 Fundamentals of Being a Successful ManagerHoyle, Mike & Newman, Peter194 Kelias į pasisekimąMarden, Orison Swett172 Getting real37signals177 How To Make People Like You In 90 Seconds Or LessBoothman, Nicholas185 The Definitive Guide to Django: Web Development Done RightHolovaty, Adrian & Kaplan-Moss, Jacob481 Getting Things DoneAllen, David278 LifehackerPash, Adam & Trapani, Gina281 Kaip įsigyti draugų ir daryti įtaką žmonėmsKarnegis, Deilas142 What Every BODY Is SayingJoe Navarro, Marvin Karlins250 Two Scoops of Django: Best Practices for Django 1.5Daniel Greenfeld, Audrey Roy297 Ready for anything: 52 productivity principles for GTDAllen, David164 Hacking secret ciphers with PythonSweigart, Al436 Extreme Productivity: Boost Your Results, Reduce Your HoursPozen, Robert C.304 Think and Grow Rich WorkbookO’Bryan, Pat52 Thinking in C++: Practical ProgrammingEckel, Bruce & Allison, Chuck832 Thinking in C++: Introduction to Standard C++, Volume OneEckel, Bruce814 Programming PythonLutz, Mark1632 Applied Operating System ConceptsGagne, Greg & Galvin, Peter B. & Galvin, Peter & Silberschatz, Avi780 Pagalbos - tapau tėčiu!Talko, Leszek K.284 Electronics for dummiesLowe, Doug185 Working with Basic Electronic ComponentsTennant, Rich162 Working with Integrated CircuitsTennant, Rich72 Working with Radio and InfraredTennant, Rich50 Getting into Alternating CurrentTennant, Rich40 7 Winning Strategies for Trading ForexCheng, Grace261 Arkliai. Enciklopedinis žinynasJosee Hermsen300 Day trading & swing trading the currency marketWiley Trading307 How to make money in stocksWilliam J. Oneil143 Rich Dad's: You Can Choose To Be RichRobert Kiyosaki200 Rich Dad, Poor Dad: What the Rich Teach Their Kids About MoneyRobert T. Kiyosaki128 Ekonomikos terminų žodynasRūta Vainienė327 Vėžlių keliasCurtis M. Faith267 Project Management: A practical ApproachRoel Grit175 Lean UXEric Ries165 Practical VIMDrew Neil411 The Lean StartupEric Ries336 Food for fitnessAnita Bean209 7 habits of highly successful tradersMark Crisp31 The Market WizardsJack D. Schwager215 Perfect sellingLinda Richardson210 You Are Not So SmartDavid McRaney320 Trade our way to financial freedomVa K. Tharp342 Dalykinės išvaizdos vadovasAlvyda Jasilionytė404 The E-myth revisedMichael Gerber268 Tobulas kūnasAndrius Pauliukevičius384 A guide to the good lifeWilliam B. Irvine329 Man Search for MeaningViktor Frankl184 Prekybos keliasTadao Yamaguchi239 The productivity projectChris Bailey304 The personal MBAJosh Kaufman464 The Giants of Philosophy SeriesVarious authorsCD 59 Seconds: Change Your Life in Under a MinuteRichard Wiseman 336 A new earthEckhart Tolle336 PypliotyraJūratė Jadkonytė Petraitienė333 How to Win Friends & Influence PeopleDale Carnegie288 Ką turi žinoti kiekvienas išsilavinęs žmogusDietrich Schwanitz546 Net 83 „būtina perskaityti“ knygų sąraše iš 200? Sakyčiau neblogai. Knygos kurias privalo perskaityti kiekvienas programuotojas Kalbėdamas su programuotojais išskirčiau tris knygas kurias kiekvienas turėtų mintinai žinoti: Pavadinimas, Autorius Puslapiųskaičius Code Complete, 2nd EditionMcConnell, Steve898 97 Things Every Programmer Should Know: Collective Wisdom From the ExpertsHenney, Kevlin257 Clean Code: A Handbook of Agile Software CraftsmanshipMartin, Robert C.462 Įdomiausios knygos Nebuvo naudingos, tačiau buvo labai įdomu skaityti: Pavadinimas, Autorius Puslapiųskaičius 4 valandų darbo savaitėFerriss, Timothy269 Vyrai kilę iš Marso, Moterys - iš VenerosGray, John178 AlchemikasCoelho, Paulo118 Geriausios populiariosios psichologijos knygos Mėgstu psichologiją / filosofiją, todėl ir šioje kategorijoje radau įdomių knygų: Pavadinimas, Autorius Puslapiųskaičius Melas prie altoriausRobin L. Smith260 Psichologinis konsultavimasRičardas Kočiūnas191 Pas kunigą ir detektyvą – psichologo kabineteGenovaitė Bončkutė-Petronienė224 Bendravimo psichologijaAlmonaitienė, Junona224

Didelių Mysql duomenų bazių parsisiuntimas

Duomenų bazių dump’ų parsisiuntimas yra dažniausiai normali praktika dirbant su projektais. Kartais tie duomenų bazės dump’ai užima labai daug. Rašysiu apie kokius 100GB - tuo pačiu nedidelis ir didelis duomenų bazės archyvas. Iš mano praktikos, parsisiųsti 100GB ir įdiegti trunka ne trumpiau nei 4 valandas. Net ir galingose/greitose sistemose. Bet čia kalbu tik apie serveris -> kompiuteris persiuntimą/diegimą. Kiek tiksliai trunka 100GB priklauso ne tik nuo sistemų, diskų, interneto greičio, užimtų resursų bet ir būdo kuriuo tai darote. Kaip sužinoti kiek užima duomenų bazė? Sužinoti kiek maždaug sveria duomenų bazė galite su SQL užklausa: SELECT table_schema AS "Database", Round(Sum(data_length + index_length) / 1024 / 1024 / 1024, 1) AS "Size in GB" FROM information_schema.tables GROUP BY table_schema Atspausdins kažką panašaus į tai: +--------------------+------------+ | Database | Size in GB | +--------------------+------------+ | project1 | 119.1 | | project2 | 82.8 | | project3 | 35.6 | | mysql | 10.0 | +--------------------+------------+ 4 rows in set, 0 warning (0.45 sec) Visada prieš dump’inant pasitikrinkite kiek sveria duomenų bazė, kad galėtumėte kuo greičiau tai padaryti. O kas jeigu yra maža duomenų bazė? Mažiau sveriančias duomenų bazes (iki 5GB) galite dump’inti gana paprastai: ssh example.org 'mysqldump nuotoline-duombaze | gzip -c' \ | gzip -d \ | mysql lokali-duombaze Gzip glaudinimą naudokite visada. Įprastai 5GB gali tapti kokiais 1GB ar mažiau. Verta pabrėžti, kad tokį siuntimą greičiausiai pajus tame pačiame tinkle sėdintys kolegos. Bet srauto ribojimas - kita tema. Didelės duomenų bazės parsiuntimas Turbūt neverta kalbėti, kad siųstis produkcinės sistemos dump’ą yra prasta mintis saugumo prasme. Programavimui dažnai nereikės labai senų įrašų, todėl greičiausiai užteks iš kiekvienos lentelės pasiimti N tūkstančių paskutinių įrašų. Nudumpinti didelę sistemą galima skripto pagalba: #!/bin/bash if [ -z "$1" ] then echo "ERROR: Missing required arguments" echo "USAGE: $0 ssh-hostname-params remote-db-name local-db-params" exit 1 fi MAX_ROWS=100000 COMMIT_COUNT=0 COMMIT_LIMIT=10 for TABLE in `ssh $1 "mysql $2 -N -e 'SHOW TABLES'"` do ROWS=$(ssh $1 "mysql -N $2 -e 'SELECT COUNT(*) FROM $TABLE'") if [ $ROWS -lt $MAX_ROWS ] then echo "Getting all $ROWS rows from table $TABLE..." ssh $1 "mysqldump --hex-blob --routines --triggers $2 --tables $TABLE | gzip -c" \ | gzip -d \ | mysql $3 & else echo "Getting last $MAX_ROWS out of total $ROWS rows from table $TABLE..." FROM_ROWS=$(($ROWS-$MAX_ROWS)) ssh $1 "mysqldump --hex-blob --routines --triggers $2 --tables $TABLE --where='1 LIMIT $FROM_ROWS, $MAX_ROWS' | gzip -c" \ | gzip -d \ | mysql $3 & fi (( COMMIT_COUNT++ )) if [ ${COMMIT_COUNT} -eq ${COMMIT_LIMIT} ] then COMMIT_COUNT=0 echo "Waiting for $COMMIT_LIMIT processes to finish..." wait fi done if [ ${COMMIT_COUNT} -gt 0 ] then wait fi Paleidimas turėtų būti gana aiškus: ./skriptas serveris nuotoline-duombaze lokali-duombaze Kuo šis skriptas sprendžia problemą didelėms duombazėms: Siunčiami tik paskutiniai MAX_ROWS lentelių įrašai. Kaip matote, kad parsiųsti paskutinius reikia dar ir paskaičiuoti kiek tų įrašų yra. Vienu metu daromi iki 10 siuntimų ir tuomet palaukiama kol 10 segmentas baigsis ir tada siunčiama dar 10 vienu metu. Skaičių galite padidinti/sumažinti pakeitę COMMIT_LIMIT konstantą. Skriptas praneša kokios lentelės, kiek juose yra įrašų ir ar siunčiama visa lentelė ar tik jos dalis. Naudojamas gzip suglaudinimas kad pataupyti visų pusių resursus. Praktinis pavyzdys Teko parsisiųsti 116GB (staging) duomenų bazės dump’ą - parsisiuntus tik paskutinius šimtą tūkstančių įrašų pats dump’as virto 15GB duomenų baze. Parsisiuntus 36GB (staging) archyvą - duomenų bazė užėmė 2.6GB. Privalumai ir trūkumai Privalumai turbūt akivaizdūs: greitas parsisiuntimas, mažai išnaudoto interneto srauto, greita darbo pradžia. Tačiau už to, žinoma, slypi ir trūkumų lavina - sąryšiai tarp lentelių. Dėl tokio parsisiuntimo kai kurie įrašai turės trūkstamų sąryšių. O tai nuves į tai, kad programinė įranga veiks ne korektiškai arba kai kurie komponentai neveiks visai. Ar mano praktikoje tai kada nors pakenkė? Ne, nes visada suradus ko trūksta (greičiausiai bet koks framework’as praneš, kad toje ir toje lentelėje trūksta sąryšio) galima parsisiųsti tam tikrą lentelę. Kitas didelis trūkumas ir ko reikia saugotis - CPU išnaudojimas. Tokio parsisiuntimo metu naudosite labai daug CPU resursų tiek nuotoliniame serveryje, tiek lokaliai. Taip irgi galite sutrikdyti kitų kolegų darbą. Priminsiu, kad toks dump’inimas yra skirtas tik programavimo tikslams.

Pirmasis Docker konteineris

Skaitydami šį straipsnį tikriausiai jau žinote kas yra Docker, o galbūt jau yra tekę išbandyti kokį nors konteinerį. Naudotis kitų sukurtais konteineriais taip pat smagu kaip ir pačiam juos kurti. Įprastai Docker instaliacija tikrinama paleidžiant anglišką „sveikas pasauli“ konteinerį: $ docker run hello-world Unable to find image 'hello-world:latest' locally [..] Status: Downloaded newer image for hello-world:latest Hello from Docker! This message shows that your installation appears to be working correctly. Tokį testinį konteinerį lengva susikurti ir patiems. Operacinės sistemos pasirinkimas Kiekvienas Docker konteineris prasideda eilute apie operacinę sistemą - su kokia turėtų startuoti. Dažniausiai (arba paprasčiausiai) tam pasirenkama kokia nors Ubuntu versija vien dėl jos populiarumo. Susikurkime failą Dockerfile ir visus tolimesnius veiksmus atlikime šiame faile. Jo pirmoje eilutėje nurodykime, kad naudosime Ubuntu operacinę sistemą: FROM ubuntu:latest Super yra tai, kad Dockerfile palaiko komentarus: # Rinktis pasenusią operacinės versiją - nerekomenduojama FROM ubuntu:16.04 Komandų vykdymas IT pasaulis labai daug diskutuoja apie mikroservisų architektūras. Gal dėl to Docker’is taip stipriai ir išpopuliarėjo, kadangi čia labai įprasta, kad vienas konteineris daro tik vieną darbą. Kadangi jau operacinę sistemą turime - dabar galime leisti komandas. Komandų aprašai daromi su CMD iškvietimu iš argumentai paduodami masyvo principu: CMD ["echo", "Sveikas pasauli!"] Konteinerio kompiliavimas Visus Docker konteinerius reikia pirmiausiai sukurti: docker build -t sveikas-pasauli . Žymės argumentų (-t sveikas-pasauli) naudoti nebūtina, bet jie padeda lengviau atpažinti savo sukurtus konteinerius. Kai atvaizdas bus sukurtas, jį galėsite pamatyti docker images išvestyje: $ docker images REPOSITORY IMAGE ID CREATED SIZE sveikas-pasauli 94efed708db0 12 minutes ago 112MB 112 MB sveria „sveikas pasauli“ atvaizdas? Wow! Konteinerio paleidimas Sukurtą konteinerį galime paleisti ir išbandyti: $ docker run sveikas-pasauli Sveikas pasauli! Fone veikiantys konteineriai Galime patikrinti ar mūsų Docker konteineris veikia fone su docker ps. Deja, ten šio konteinerio nerasite. Taip yra todėl, kad mūsų parašyta komanda išvedė tekstą ir sėkmingai baigė darbą. Tuo galite įsitikinti pažiūrėję ką rašys docker ps -a kuri rodo informaciją apie visus konteinerius: $ docker ps -a CONTAINER ID IMAGE COMMAND STATUS fbd3ccb23e41 sveikas-pasauli "echo 'Sveikas pasau…" Exited (0) 10 minutes Konteinerį su Docker pasileidome per kelias minutes. Kituose straipsniuose pakalbėsime apie kokio nors framework’o paleidimą per Dockerį.

Spalvota BASH išvestis API testavimui

Daug dirbant su API tokie įrankiai kaip Postman yra nepakeičiami. Tačiau jeigu reikia vieno-kito API pabandymo ar „testinio važiavimo“, tai surinkti curl sakinį terminale - paprasčiau. Pats dažnai pasiduodu darbui su API terminale, todėl čia ypatingai svarbu matyti kuo patogesnį vaizdą. Panagrinėkime labai nedidelį pavyzdį: $ curl -X POST 'https://example.com/api/v1/users/token' {"error":"UNAUTHORIZED","message":"Invalid username / password"} Kai nedaug turinio - viskas labai paprasta. Formatavimas Turint daug daugiau turinio/išvesties - skaityti bus nepatogu. Todėl formatavimui galima pasitelkti Python pagalbą: $ curl -qs -X POST 'https://example.com/api/v1/users/token' | python -m json.tool { "error": "UNAUTHORIZED", "message": "Invalid username / password" } Verta pastebėti, kad pridėjau -qs parametrus kurie paslėps nereikalingą curl progresijos informaciją. Kiti įrankiai, be Python Žinoma, yra visokių įrankių, kaip JQ, kurie gali suformatuoti json išvestį, tačiau Python’as tam turi standartinę biblioteką. O Python’ą galima rasti praktiškai visur. Didelis tokio įrankio kaip JQ privalumas yra tas, kad jis gali tekstą ne tik gražiai suformatuoti, bet jį dar ir atfiltruoti. Pavyzdžiui jeigu API išvardina visus miestus, koordinates ir šalis kurioms jie priklauso - galite atsifiltruoti viską išskyrus koordinates jeigu jų nereikia. Didelis šio įrankio minusas: labai prasta dokumentacija ir velniškai sunku naudotis. Ne kartą teko pasiduoti bandant per daug gudriai išfiltruoti duomenis. Todėl paprastiems dalykams puikiai tiks python -m json.tool, o sudėtingesniems, kai reikia dar ir su duomenimis dirbti - teks Google’inti. Spalvos Jeigu duomenų tikrai daug - būtų patogiau juos matyti dar patogiau - su spalvomis. Įdiekime Pygmentize biblioteką: sudo pip install Pygments Ir tada prie python -m json.tool pridurkime pygmentize -l json. Pavyzdys kaip tai atrodo mano terminale: curl API | python -m json.tool | pygmentize -l json Aliasas pagalbai Kad nerašyti tos ilgos komandos kaskart kai reikia, bash ir zsh esu pasidaręs alias’ą: alias json="python -m json.tool | pygmentize -l json" Todėl galiu rašyti trumpiau komandas: $ curl -X POST 'https://example.com/api/v1/users/token' | json Ir taip greitai gauti patogią išvestį.

Alternatyva python -m SimpleHTTPServer

Kiekvienas programuotojas bus ne kartą susidūręs su tuo, kad reikia kažkam parodyti failus jų nekeliant į serverį. Būnant ant to paties tinklo lengviausias būdas pasidalinti failais yra: $ python -m SimpleHTTPServer Serving HTTP on 0.0.0.0 port 8000 ... Kitam žmogui tereikės atidaryti naršyklėje IP-ADRESAS:8000 ir galės pažiūrėti maketą arba tiesiog parsisiųsti failus. Labai paprastas būdas pasidaryti statinių failų web server - laikinai. IP adresas turi būti to kompiuterio iš kurio leidžiate šią komandą. SimpleHTTPServer trūkumai Šį Python modulį panaudojau kokį tūkstantį kartų savo karjeroje. Labai patogu kai nori pasidalinti vienu ar keliais failais. Esi priekinės sąsajos programuotojas (angl. „frontend developer“) ir nori parodyti padarytą svetainės prototipą ar maketą? Deja, čia SimpleHTTPServerpasireiškia su dideliu trūkumu - failų siuntimasis nėra asinchroniškas. Todėl tam, kas juos bando pažiūrėti ar parsisiųsti - viskas bus siunčiama po vieną failą vienu metu. Ir užkrauti tipinį svetainės puslapį užtruks N sekundžių. Kitas minusas - paleidai statinį serverį - o koks tavo IP adresas? Reikės ieškoti savo IP adreso (taip, su ifconfig). NodeJs alternatyva Internete yra pavienių skriptų kurie gali išspręsti SimpleHTTPServer lėtumą, bet NodeJs alternatyva tiesiog reikalauja mažiau darbo. O ir prisėdus prie kito kompiuterio lengviau tą patį gauti su: $ sudo npm install http-server -g $ http-server Starting up http-server, serving ./ Available on: http://127.0.0.1:8080 http://192.168.8.101:8080 http://172.18.0.1:8080 Hit CTRL-C to stop the server IP ieškoti nereikės - jis jau Jums po ranka. Aišku ir vienas (SimpleHTTPServer) ir kitas (http-server) veiks tik tuomet jeigu sistemoje jau yra Python/NodeJs/NPM. Bet kas gi šiais laikais neturi Python ar NodeJs, tiesa?

Docker konteinerių monitorinimas su CAdvisor

Kaip Linux’ai turi populiariuosius top arba htop, taip ir Docker turi ne vieną monitorinimo galimybę. Dockeryje integruota komanda docker stats kuri gali parodyti tokią informaciją: CONTAINER CPU % MEM USAGE / LIMIT MEM % cfde60835a60 0.19% 19.79MiB / 7.796GiB 0.25% 072b20df4039 0.00% 47.99MiB / 7.796GiB 0.60% f0f8472aa16d 0.00% 74.02MiB / 7.796GiB 0.93% b102eb4871da 0.00% 146.9MiB / 7.796GiB 1.84% f9d27274be54 0.00% 57.61MiB / 7.796GiB 0.72% a3a0150fc364 0.01% 84.37MiB / 7.796GiB 1.06% 2d618fc570a7 0.01% 101MiB / 7.796GiB 1.26% 2d9ce919a48f 0.00% 6.93MiB / 7.796GiB 0.09% c33f4ea47585 0.01% 26.95MiB / 7.796GiB 0.34% d567dc6d669f 0.11% 6.297MiB / 7.796GiB 0.08% 49c51b26cc8c 0.01% 95.32MiB / 7.796GiB 1.19% ad360d4dea78 0.00% 656KiB / 7.796GiB 0.01% 26f63800f241 0.06% 273.3MiB / 7.796GiB 3.42% 42ee0daf4603 0.47% 43.13MiB / 7.796GiB 0.54% ebf21865eaf1 0.02% 94.73MiB / 7.796GiB 1.19% 43e0db76df21 0.01% 888KiB / 7.796GiB 0.01% Tai labai patogu norint nustatyti ar kuris nors konteineris „nevalgo“ per daug Jūsų sistemos resursų: atminties, CPU laiko, disko naudojimo. O jeigu šiai informacijai būtų grafinė aplinka? Mėgstantiems statistikas stebėti grafinėje aplinkoje (GUI), galima įsidiegti CAdvisor. Ją išbandyti galima labai greitai ir vos viena komanda: sudo docker run \ --volume=/:/rootfs:ro \ --volume=/var/run:/var/run:rw \ --volume=/sys:/sys:ro \ --volume=/var/lib/docker/:/var/lib/docker:ro \ --volume=/dev/disk/:/dev/disk:ro \ --publish=8080:8080 \ --detach=true \ --name=cadvisor \ google/cadvisor:latest Naršyklėje įrašome http://domenas-arba-ip:8080 ir pamatysite visą CAdvisor aplinką. Svarbiausia, kad viskas realiu laiku, todėl naršyklės lango nereikės nuolat naujinti. Informacijos bus pateikta daug. Pastebėsite, kad daug jos gausite iš standartinės docker stats komandos išvesties. Dar matysite ir grafikus ir kaip naudojami Jūsų sistemos resursai: CAdvisor grafinė aplinka Kaip išbandyti? Jeigu tik pradedate naudoti docker ir trūksta idėjų ką su juo daryti, tai patarčiau išmėginti mano programavimo platformą kuri padaryta su Docker. Platformoje rasite apache2, php, mysql, memcached, redis, elasticsearch, postgres. Paketas su populiariausia programine įranga WEB programavimui. Nebūtina šią platformą naudoti, bet galima panaudoti CAdvisor išmėginimui.

Kas yra Docker?

Žmonėms kurie nors kiek matę Virtualbox’ą paaiškinti nesunku - tai kažkas panašaus, tik be grafinės aplinkos. Pasileidžiate per komandinę eilutę kažkokią operacinę sistemą, programinę įrangą joje ir dirbate. Tačiau tam yra Vagrant’as, pasakys daugelis! Viena iš priežasčių dėl ko apskritai toks dalykas kaip Dockeris buvo sukurtas - tai resursų pernaudojimas. Vagrant’as paleisdavo visą operacinę sistemą ir tik tada norimą programinę įrangą. Todėl įrangos paleidimas trukdavo bent kelias minutes. Tuo tarpu Docker’is paleidžia viską per kelias sekundes. Taip yra todėl, kad daugelis resursų, tokie kaip Kernelio moduliai, yra pernaudojami iš vykdančiosios sistemos. Kaip pavyzdys, jeigu norėtume paleisti web servisą nuo nulio - apache/nginx - tai: Virtualbox’e užkrautume kokią nors OS, kaip Ubuntu, tada įdiegtume web servisą ir jau pusvalandžio bėgyje galima būtų dirbti. Vagrantui reikėtų parašyti konfigūracijų failą, kuris užkrautų OS ir paleistų web servisą. Jau po 5-15 minučių galėtume dirbti. Dockeriui reikėtų parašyti konfigūracijų failą ir jis pernaudojęs esamos sistemos resursus paleistų web servisą kelių minučių bėgyje. Svarbu pabrėžti, kad Docker’is šiuo metu yra populiariausia konteinerių (taip vadinami operacinių sistemų / programinės įrangos atvaizdai) sistema. Todėl jeigu esate programuotojas, išmokti anksčiau ar vėliau tikrai bus verta. Susidomėjimas Docker sistema pagal Google Trends Nuotraukoje viršuje matyti kaip stipriai Docker susidomėjimas augo nuo 2013 metų. Docker diegimas Kaip įdiegti - atskirai rašyti neverta, nes kartais informacija keičiasi. Užteks atsidaryti oficialų diegimo puslapį. Iš dokumentacijos verta paminėti, kad reikėtų nepraleisti tos dalies kur paprastam vartotojui suteikiamos teisės valdyti Docker konteinerius. Praleidus šią vietą vėliau visas komandas susijusias su Docker’iu teks leisti per sudo. Laiko gaišimas. Kaip išbandyti? Sekančiuose straipsniuose daugiau aprašysiu apie Dockerio komandas. Labai smalsiems patarčiau įsidiegti docker-compose ir pasileisti mano programavimo platformą kuri padaryta su Docker. Platformoje rasite apache2, php, mysql, memcached, redis, elasticsearch, postgres. Žodžiu visko ko standartiniam web programuotojui gali prireikti.

OpenSSL paketas sertifikatų informacijai tikrinti

Let’s Encrypt išgelbėjo daugelį svetainių turėtojų nuo mokamų HTTPS sertifikatų. Jeigu anksčiau sertifikatą domenui pirkdavau už 60€ metams, tai dabar jį galima susigeneruoti nemokamai tiesiog turinti prieigą prie serverio. Let’s Encrypt sertifikato galiojimo problema Let’s Encrypt sertifikatai galioja tik 90 dienų. Juos reikia atnaujinti prieš galiojimo pabaigą, kitaip svetainės lankytojai negalės patekti į Jūsų svetainę. Laimei pats Let’s Encrypt atsiųs Jums laišką-įspėjimą (laiškas siunčiamas į pašto dėžutę su kuria registruotas sertifikatas): Hello, Your certificate (or certificates) for the names listed below will expire in 9 days (on 20 Dec 17 08:22 +0000). Please make sure to renew your certificate before then, or visitors to your website will encounter errors. www.jarmalavicius.lt [..] Sertifikato problemų monitorinimas Su laiškais būna daug problemų - jie pasimeta, nueina į Spam’ą ir pan. Todėl tikrai rekomenduočiau pasirūpinti monitorinimo sistemą. Apie vieną monitorinimo būdą esu jau rašęs, jį galite rasti straipsnyje - kaip tikrinti HTTPS sertifikatus su Nagios. Tipinės sertifikatų bėdos Nereikia ieškoti internete įrankių su kuriais galima būtų spręsti arba surasti sertifikatų bėdas. Linux aplinkoje užteks vieno - openssl. Detalią informaciją apie sertifikatą gausime taip: openssl s_client -showcerts -connect www.jarmalavicius.lt:443 Ar serverio sertifikatas tvarkingas matysite paskutinėje eilutėje: Verify return code: 0 (ok) Apie įvairias problemas galima sužinoti taip pat iš paskutinės eilutės, pavyzdžiui: Verify return code: 21 (unable to verify the first certificate) Ar atsinaujino serverio sertifikato data? Atnaujinus sertifikatą ir mėginant pažiūrėti jo galiojimo pabaigos datą per naršyklę galite pamatyti seną datą. Taip yra dėl to, kad net ir sertifikatų informacija yra kešuojama ir bent jau ant Chrome naršyklės, tipinis CTRL+F5 nepadės. Sertifikato datas galima pasitikrinti su: $ openssl s_client -servername NAME -connect jarmalavicius.lt:443 2>/dev/null | openssl x509 -noout -dates notBefore=Jan 24 12:23:39 2018 GMT notAfter=Apr 24 12:23:39 2018 GMT Neatsinaujino sertifikato data? Po sertifikatų atnaujinimo web serverio perkrovimas yra būtinas. Konfigūracijoms užtenka nginx reload arba apache2ctl reload. Kartais Let’s Encrypt Jūsų sertifikatą padės į /live/domenas.lt-001 ar kitokį katalogą, todėl reikėtų įsitikinti ar serverio konfigūracijoje nurodytas tas pats kelias. Pažiūrėti kuriame kataloge yra naujesnis sertifikatas galite paėmę pasinaudoję pem failu: $ openssl x509 -enddate -noout -in cert.pem notAfter=Mar 20 03:11:24 2018 GMT

Sertifikatų problemų tikrinimas su Nagios

Kai turite daug HTTPS domenų, tai jiems stebėti verta turėti monitorinimo sistemą, tokią kaip Nagios. Vienas iš darbų kurį turėtų atlikti bet kuri monitorinimo sistema - stebėti Jūsų turimų projektų sertifikatus. Sertifikatui tikrinti Nagios’e galima susikurti komandą (faile commands.cfg): define command { command_name check_https_cert command_line /usr/nagios/[..]/check_ssl_cert -w 14 -c 7 -H $HOSTADDRESS$ -r /etc/ssl/certs/ } Argumentų aprašymas: -w 14 Nagios uždės ‘Warning’ būseną, kai iki sertifikato galiojimo pabaigos lieka 14 dienų. -c 7 Nagios uždės ‘Critical’ būseną, kai sertifikato galiojimas baigsis už 7 dienų. Ir tuomet jau priskiriant komandą servisui (faile services.cfg): define service{ hostgroup_name https-websites use generic-service service_description HTTPS Cert check_command check_https_cert } Ir pačiame Nagios’e gausime HTTPS sertifikato tikrinimui skirtą taisyklę: Nuotrauka iš asmeninio Nagios puslapio Nurodytų failų reikėtų ieškoti /etc/nagios/conf.d/ kataloge. Tačiau priklausomai nuo sistemų, galima rasti ir /usr/local/nagios. Kokių pranešimų galima tikėtis? Nagios’as praneš apie sertifikato pasiekiamumą ir jo galiojimo datos pabaigą. Ne kartą buvau papuolęs į konfigūracijų copy-paste būseną, kuomet kažkuri svetainė gaudavo kitos svetainės sertifikatą. Vėlgi - Nagios praneš ir apie tai. Daugiau galima paskaityti angliškame tikrinimo komandos apraše.

Atnaujiname NodeJs versiją

Net ir 2018 metais įdiegus NodeJs versiją iš Ubuntu/Debian atviro kodo repozitorijų gausite versiją kuri nors ir stabili, bet yra gerokai pasenusi, kad be problemų galėtumėte dirbti su naujausiais framework’ais. Pavyzdžiui Ubuntu 17.04 oficialiose repozitorijose turi versiją 4.7.*. Atnaujinti sisteminę versiją galima iš tiesioginių NodeJs saugyklų. Išvalykime sisteminį kešą (kad kitų komandų diegimo metu negautume senų paketų): sudo npm cache clean -f Įdiekime naujausią nodejs versijų valdytoją: sudo npm install -g n Įdiekime naujausią nodejs versiją: sudo n stable Nurodykime sistemai vietoje senojo nodejs ir node naudoti naująjį: KELIAS=/usr/local/n/versions/node; sudo ln -sf $KELIAS/<VERSIJA>/bin/node /usr/bin/nodejs; sudo ln -sf $KELIAS/<VERSIJA>/bin/node /usr/bin/node; Versiją po įdiegimo galite pasitikrinti komanda: $ node -v v9.2.1

Kuom skiriasi Raspberry Pi 2 nuo Pi 3?

Planuojate įsigyti? Jeigu dar tik galvojate įsigyti Raspberry Pi ir jau žinote kiek toks įrenginys kainuoja - tuomet pravers žinoti kuo viena versija nuo kitos skiriasi. Kadangi šio įrenginio kūrėjai naują versiją išleidžia beveik kas metus, tai senesnės versijos su laiku šiek tiek atpinga. Žinoma, kaina gali būti ne pagrindinė priežastis pasirinkti konkrečią versiją. „Oficialus“ skirtumas Šio įrenginio kūrėjai Raspberry Pi 3 nuo Raspberry Pi 2 skirtumus apibūdina taip: „atrodo taip pat, kainuoja taip pat, bet tai ne tas pats“. Daugiau skirtumų pagal specifikacijų grupes rasite žemiau. Išvaizdos pokyčiai Kreditinės kortelės dydžio kompiuteris. Tokia pradinė idėja. Ji 100% išlieka ta pati, todėl išvaizdoje pokyčių labai mažai. Verta pabrėžti apskritai didelį privalumą šių įrenginių - turėdami HDMI, GPIO, LAN laidą ir ausinių/mikrofonų kištukus jie aprėpia tiek galimybių, kaip šių laikų standartinis nešiojamas kompiuteris. Tik kompiuterio, kaip šio, į kišenę neįsidėsi. Na, o GPIO yra priedas šiam įrenginiui tapti IoT. Tikriem elektronikos entuziastams. Techninė įranga (angl. „hardware“) Antroji versija turėjo keturių branduolių 900MHz CPU, naujesnė, trečioji, turi 1.2Ghz, taip pat keturių branduolių. Kaip namų vartotojas - skirtumo tikrai nepajusite. Abu turi 1GB RAM atminties. Trečioji versija turi vietoje 450MHz net 900MHz greičio atmintį, o tai - kaip namų vartotojas - pajusti jau galite. Tiesa, šiais laikais vienas GB RAM’ų yra ne toks jau ir didelis kiekis, todėl tai labai bus svarbu ką su šiuo įrenginiu darysite. Wireless - štai kur privalumas. Raspberry Pi 3 turi integruotą Wifi, todėl nereikės kabelių ir kitokių laidų norint mėgautis naršymo patirtimi. Greitis Nesu daręs jokių greičio testavimų, nes jų pilnas internetas. Žiūrint įvairius straipsnius lengvai būsite įtikinti, kad Raspberry Pi 3 yra beveik 2 kartus pranašesnis greičio/pajėgumo prasme. Asmeninė patirtis Dėl tikrai gero Full HD vaizdo palaikymo - geros kokybės filmų peržiūra tikrai nestrigs. Nestrigs nei garsas nei vaizdas. Deja, bet strigs visa kita - tarkime filmų perjungimas (filmo rodymo metu) ar garso reguliavimai. Ši bėda ant Raspberry Pi 3 jau vos vos jaučiama. RetroPie abiejuose veiks tiesiog idealiai. Tiesa, visokie Sega žaidimai ir pan. veiks žymiai geriau ant Raspberry Pi 3. Debian/Ubuntu operacinės veiks tikrai labai gerai. Todėl paprastam namų naudotojui (tėvam/seneliam) čia idealus kompiuterio variantas. Aišku, tektų pasirūpinti ekranu ir įvesties įrenginiais. Daugiau Raspberry Pi straipsnių? Jeigu domina informacija apie įrenginį, būtinai pažiūrėkite kitus Raspberry Pi straipsnius.

Paketų, esančių requirements.txt, automatinis atnaujinimas

Bene kiekvienas projektas Python kalboje turi requirements.txt failą, kuriame surašyti paketų pavadinimai ir jų priklausomybės (versijos, su kuriomis programa turėtų veikti). Tiesa, pastarųjų, versijų, gali ir nebūti. Tuomet sistema turėtų įdiegti naujausias tuo metu paketų versijas. Dirbant ilgiau su projektu - reikės šias versijas atnaujinti. Tą daryti verta bent dėl kelių priežasčių: Paketai gali turėti saugumo spragų (pavyzdžiui OpenSSL susiję paketai jų turi dažniausiai); Senesni paketai gali turėti neištaisytų programinės įrangos klaidų (ypatingai naudojant frameworkus, tokius kaip Django); Naujesni paketai gali būti optimizuoti. Kaip atnaujinti paketus? Jeigu turime kažką panašaus į šį requirements.txt: django-admin-jqueryui==1.8.22 django-admin-shortcuts==1.2.5 django-appconf==0.6 django-awesome-bootstrap==3.0.3 django-compressor==1.3 django-debug-toolbar==0.11.0 django-extensions==1.3.3 django-imagekit==3.2.2 Tuomet greičiausiai atnaujinti paketus bus su pur įrankiu. Pur įdiegimas Įdiegti galima pasinaudojus pip įrankiu: pip install pur Arba, jeigu nenaudojate virtualios aplinkos, tuomet prie komandos prirašykite sudo, kad įdiegti į sistemą. Atnaujiname paketų versijas Paprasčiausiai duokime šiai komandai requirements.txt failą: pur -r requirements.txt Jeigu esate tame pačiame kataloge kur ir šis failas, tuomet užtektų ir pur komandos pakvietimo be jokių argumentų. Jis atnaujins requirements.txt failą su naujausiomis versijomis ir parodys atnaujinimų sąrašą: Updated django-admin-shortcuts: 1.2.5 -> 1.2.7 Updated django-awesome-bootstrap: 3.0.3 -> 3.2.0 Updated django-compressor: 1.3 -> 2.1.1 Updated django-debug-toolbar: 0.11.0 -> 1.7 Updated django-extensions: 1.3.3 -> 1.7.8 Updated django-jquery-js: 2.0.3 -> 3.1.1 Updated django-jquery-ui: 1.10.3.1 -> 1.11.4.1 Updated django-model-utils: 2.0.3 -> 3.0.0 Updated django-ordered-model: 0.3.0 -> 1.4.1 Updated django-select2: 4.2.2 -> 5.10.0 Updated django-tastypie: 0.11.1 -> 0.13.3 Updated django-webtest: 1.7.5 -> 1.9.1 Atnaujiname paketus Tik nepamirškite, kad šis įrankis neatnaujina paketų. Jis tik atnaujina jų versijas į naujausias requirements.txt faile. Todėl atnaujinti paketams reikės dar pavykdyti: pip install -U -r requirements.txt

Kiek kainuoja Raspberry Pi?

Planuojate įsigyti? Galvojant įsigyti Raspberry Pi, vienas iš pirmųjų klausimų bus apie jo kainą. Kiek šiais laikais kainuoja Raspberry Pi ir skirtingos jo versijos? Kadangi šio įrenginio kūrėjai naują versiją išleidžia beveik kas metus, tai senesnės versijos su laiku šiek tiek atpinga. Kaina Lietuvoje Nereklamuosiu kiek šis įrenginys kainuoja Lietuvoje, nes greičiausiai iškart atsirastų el. parduotuvių, kurių patikimumo negalima būtų patikrinti, siūlančių šį įrenginį įsigyti dar pigiau nei parašysiu. Kadangi Ebay ir Aliexpress Lietuvoje puikiai žinomi (greičiausiai net labiau nei „apsipirkimas Lenkijoje“), ir konkuruoti su jais būtų sunku Lietuviškoje rinkoje, tai pateiksiu vidutines kainas iš šių elektroninių parduotuvių. Kainos Ebay parduotuvėje Raspberry Pi Zero W šioje parduotuvėje kainuoja apie 20€. Raspberry Pi 2 parduotuvėje Ebay kainuoja apie 35€. Raspberry Pi 3 parduotuvėje Ebay kainuoja apie 40€. Visos kainos yra įskaičiuojant pristatymo kainą bei muito mokesčius. Muitas šioms prekėms taikomas itin retai. Kainos Aliexpress parduotuvėje Visi šie įrenginiai vidutiniškai ten kainuoja 1-3€ pigiau nei Ebay parduotuvėje. Aliexpress siuntimas dažniausiai būna bent savaite greitesnis. Perkant šioje parduotuvėje rekomenduočiau atkreipti dėmesį į kiek šių įrenginių pardavė pardavėjas iš kurio ruošiatės pirkti ir kokį reitingą jis turi. Šioje parduotuvėje apgavysčių yra kiek daugiau nei Ebay. Kokios yra Raspberry Pi priedų kainos? Skaitykite sekantį straipsnį jeigu domina Raspberry Pi priedų kainos internetinėse parduotuvėse.

Kiek kainuoja Raspberry Pi priedai?

Planuojate įsigyti? Jeigu galvojate įsigyti Raspberry Pi ir smalsu kiek jis gali kainuoti - tuomet pravers kitas straipsnis apie Raspberry Pi kainą. O jeigu domina priedų kainos - skaitykite toliau. Priedai Raspberry Pi pasaulyje taip stipriai išpopuliarėjo, kad tuoj pat jam pasipylė tūkstančiai priedų. Trumpai apie populiariausius priedus ir jų kainas elektroninėse parduotuvėse. Nereklamuosiu kiek šie priedai kainuoja Lietuvoje, nes greičiausiai iškart atsirastų el. parduotuvių, kurių patikimumo negalima būtų patikrinti, siūlančių šį įrenginį įsigyti dar pigiau nei parašysiu. Kadangi Ebay ir Aliexpress Lietuvoje puikiai žinomi (greičiausiai net labiau nei „apsipirkimas Lenkijoje“), ir konkuruoti su jais būtų sunku Lietuviškoje rinkoje, tai pateiksiu vidutines kainas iš šių elektroninių parduotuvių. Priedas prie Raspberry - pakrovėjas Pakrovėjų šiam įrenginiui pirkti nesiūlyčiau. Nebent esate Apple fanas, tuomet galbūt ir reikėtų nusipirkti. Kodėl taip sakau? Raspberry Pi reikia micro USB maitinimo šaltinio. Greičiausiai namie jau turite N įrenginių su šiuo laido tipu. Tai gali būti: Android telefonai (kurie bent truputį naujesni nei 2013 metų gamybos), belaidės ausinės, navigacijų įrenginiai ir pan. Apple įranga greičiausiai jokia neturi micro USB (pataisykite, jeigu klystu). Pakrovėjas dažniausiai kainuoja vos daugiau nei 2€. Mano rekomendacija - pirkti daugiau amperų turintį pakrovėją. Bent 1A ar 2A. Tokiu būdu, darant projektus kaip RetroPie (pažiūrėkite internete) neturėsite bėdų „užmaitinant“ valdymo įrenginius. Perkant pakrovėją įsitikinkite ar jo kaištukai yra EU tipo, nes kitaip, dar turėsite adapterį nusipirkti, kuris, nors kainuoja vos kelis €, yra tik bereikalingas įrankis. Priedas prie Raspberry - dėžutė Dėžutės (angl. „case“) nėra būtinos. Jeigu galvojate apie izoliavimą nuo kitų įrenginių ar vaikų, tai šis įrenginys visiems turėtų būti gana saugus, nes visas jo vidus „varomas“ vos 5V, kurie žalos nepridarys. Bet jeigu naudosite jį atvirai, greičiausiai norėsite dėžutės. O pasirinkimo tose pačiose parduotuvėse yra kiek tik sugalvosite. Štai tokią aš turiu vienam iš savo įrenginių (labai rekomenduoju): Prieš pirkdami pasitikrinkite kokį modelį Raspberry Pi turite. Pavyzdžiui jeigu turite Raspberry Pi 2 ir pirksite Pi 3 dėžutę - turėsite dideles skyles USB pusėje. Geriau turėti pilnai apdengtą įrenginį. Priedas prie Raspberry - papildomas ventiliatorius Jums jo greičiausiia nereikia. Nebent mėginsite su šiuo įrenginiu siųstis kiaurą parą Torrent’us arba hash’inti Bitcoin’us. Raspberry Pi puikiai veiks Jums laikant kiauras savaites įrenginį įjungtą (net su Torrent’ais). GPIO ir kiti priedai prie Raspberry Yra visokių „starter kit“ ir pan. paketų, kurie kainuoja tikrai nedaug (tarkime iki 100€) ir juose galite rasti visokių papildomų elektroninių prietaisiukų. Pavyzdžiui atstumo ar garso matuoklius ir pan. Taip pat visokius laidus, rezistorius ir kitką. Jeigu norite Raspberry Pi pirkti, bet 100% dar nenusprendę kam jis Jums reikalingas, bei negaila pinigų - tuomet siūlyčiau imti šiuos „starter kit’us“. Dažnai jie su savimi turi Raspberry Pi įrenginį, bet - ne visada. Todėl būtinai pasitikrinkite ką perkate. Šie „starter kit’ai“ yra puiki pramoga ir dovana vaikams. Prietaisas gana saugus daryti eksperimentus net esant mėgėjui. Blogiausiai kas galėtų atsitikti - sugadinsite vieną ar kitą dalyką nepridarydami per daug žalos. Pavyzdžiui koks atstumo matuoklis kainuoja vos 2€ - sugadinus tiesiog nusipirktumėte kitą. Daugiau Raspberry Pi straipsnių? Jeigu domina informacija apie įrenginį, būtinai pažiūrėkite kitus Raspberry Pi straipsnius.

Decentralizuota versijavimo sistema. Kas tai?

Trumpai tariant, decentralizuota versijavimo sistema (netiesioginis vertimas iš populiaraus angliško teksto „distributed version control“) - yra tokia versijavimo sistema, kuri leidžia daugeliui su ja dirbančių žmonių sistemų dirbti taip, kad jiems visiems nereikėtų vieno išeities taško. Pavyzdžiui centralizuota versijavimo sistema SVN „priverčia“ jos naudotojus dalintis vienu išeities tašku - kodą ar kitokius resursus kelti į vieną, sutartą, serverį. Iš to seka tokios problemos, kad tam, kad dalintis išeities kodu, reikia turėti skaitymo/rašymo teises į tą vieną serverį. Dalijimasis kodu tuomet tampa apsunkintas. GIT šiuo atveju neprašo savo išeities kodą kam nors siųsti. Čia puikus pavyzdys būtų github.com projektas. Tai vienas populiariausių projektų laikantis milijonus atviro kodo išeities kodų, kuriuos bet kada galima parsisiųsti. Visos repozitorijos (išeities kodo saugyklos) yra viešai prieinamos (t.y. bet kuris žmogus turi repozitorijos skaitymo teises). Tačiau rašymo teises į repozitoriją turi tik jos savininkas ar įgaliotas asmuo. Dėl šios priežasties, norint paskelbti oficialioje repozitorijoje savo pakeitimus teks gauti leidimą arba siųsti autoriui pakeitimus ir prašyti juos įkelti. Kas šioje situacija vaizduoja „decentralizavimą“? Ogi tai, kad iš vienos vietos gautą kodą Jūs neprivalote su niekuo dalintis. Galite kodą modifikuoti (jeigu leidžia licencija), platinti (jeigu leidžia licencija) tarp savo draugų ar įmonės kolegų. Realus decentralizuotos sistemos pavyzdys Asmeniškai aš kuo daugiau projektų stengiuosi viešinti atviram kodui. Kaip pavyzdys, GitHub projektas - geriausia vieta. Štai viena iš mano repozitorijų ReekenX/dotfiles laiko mano namų katalogo failus. Tai yra konfigūraciniai failai, kuriuos aš visada „įmetu“ į savo asmeninius kompiuterius ar serverius. Tą darau tam, kad visokie komandinės eilutės įrankiai veiktų su mano numatytomis konfigūracijomis. Pavyzdžiui tekstų redaktorius VIM yra paruoštas startuoti su mano konfigūracijomis, todėl visuose kompiuteriuose šis redaktorius veikia ir atrodo taip kaip ir kituose. Šią repozitoriją gali parsisiųsti visi ir modifikuotis pagal poreikius. Šią repozitoriją gali naudoti jūsų draugai ir pakeitimus taip pat galite keistis nesunkiai vien todėl, kad GitHub palaiko decentralizuotos GIT versijavimo sistemos įrankį. Decentralizuotos sistemos privalumai Dažniausios operacijos (commit’ai, istorijos peržiūra ir pan.) yra labai greiti, nes nereikia komunikuoti su centriniu serveriu. Komunikacija yra reikalinga nebent kai atliekamos informacijos dalijimosi procedūros (pavyzdžiui modifikuotas išeities kodas). Galima turėti ne vieną saugyklą kurioje galite saugoti repozitoriją. Viešoms saugykloms galite turėti privačią repozitorijos saugyklą. Tarkime jeigu GitHub puslapis būtų nepasiekiamas (būna ir tokių įvykių). Vienu metu gali dirbti didelis kiekis žmonių netrikdant komunikacijos kanalų (primenu, kad dažniausioms operacijoms komunikacijos nereikia). Decentralizuotos sistemos trūkumai Dėl to, kad sistema yra decentralizuota, reiškia, kad po kurio laiko darbo su repozitorija teks apsikeisti informacija (tarkime su savo kolegomis). Dėl šios priežasties kaip dirbti su decentralizuota sistema yra sukurta ne viena sisteminė darbo eiga („git-flow“ pavyzdžiui). Tai dar vienas dalykas ką reikėtų išmokti studijuojantiems programavimą. Sunkiai įgyvendinama priėjimų kontrolė. Jeigu kodas paimtas, tarkime iš GitHub, tai nebūtinai reiškia, kad tolimesni patobulinimai ten ir liks. Dažnai būna, kad patobulinus programinę įrangą, jos patobulinimai nėra grąžinami atgal.

Kas tai yra - versijavimo sistema?

Versijų kontrolės sistema - yra programinė įranga, kuri išsaugo itin detalius failo arba failų pakeitimus, laiko šių pakeitimų istoriją atstatymui ir analizei ateityje. Jeigu startuojate su programavimu, studijuojate programavimą, tuomet turite žinoti, kad tai yra vienas iš svarbiausių dalykų ką reikėtų šiais laikais labai gerai išmanyti. Greičiausiai neteks susidurti su įmone kuri nenaudotų nei vienos versijos kontrolės sistemų. Kodėl GIT? Kategorija straipsnių yra specialiai dedikuota GIT versijavimo kontrolei. Taip yra todėl, kad ši versijavimo sistema yra populiariausia pasaulyje. Kiek tai yra populiariau už kitas sistemas? Jeigu tikėti Google Trends sistema, tai 2017 metais grafikas būtų štai toks: Mėlyja linija (viršutinė) yra GIT sistema. Raudona linija (vidurinė) yra HG (dar kitaip vadinama Mercurial) sistema. Oranžinė linija (apatinė) yra SVN sistema. Ar teisinga spręsti vien tik pagal populiarumą? Ir taip ir ne. Jeigu kažkas populiaru, tai dar nereiškia, kad gerai. Tikrai pažįstu daug žmonių, kurie yra užkietėję Mercurial (HG) versijavimo sistemos naudotojai ir tai yra gerai. Svarbu, kad įrankis būtų naudingas ir netrukdytų produktyviam darbui. Pavyzdžiui jeigu lyginti su SVN, viena populiariausių sistemų prieš 10 metų, tai skirtumų tarp GIT ir SVN rastumėte daugybę. Ir tikrai ne SVN naudai. Vien tai, kad GIT yra decentralizuota sistema yra kertinis dalykas. Šiuo atveju GIT populiarumas auga kaip ant mielių. Paaiškinti tą turėtų būti sunku, nes kaip versijavimo sitema - jinai neturi kažkokių pranašumų prieš kitas sistemas.

SD kortelių greičio tikrinimas prieš naudojant

Visai neseniai teko „pakurti“ dar vieną projektą su Raspberry Pi. Tvarkiau namų zonos filmavimo įrangą ir kadangi buvo labai svarbu turėti greitą SD kortelę teko tikrinti N tokių kortelių iš savo stalčiaus, kuriame jų prikaupiau per N metų. Laimei su Linux tai padaryti nėra sunku, nes yra ne viena programa kuri netrunka laiko įsidiegti ir panaudoti. Surasti kokiu greičiu dirba SD (micro SD ar USB) kortelė yra lengva. Pirmiausiai įdėjus ją į kitą kompiuterį reikėtų sužinoti kuriame Linux įrenginyje kortelė buvo priregistruota. Tą padaryti galima pasižiūrėjus komandos fdisk -l išvesties skirtumą prieš kortelę įdedant ir po įdėjimo. Žinant, kur priregistruotas naujas įrenginys, pasižiūrėti jo įrašymo ir skaitymo greitį galima pasinaudojus hdparm programa. Praktinis panaudojimo pavyzdys: $ sudo fdisk -l [..] Device Boot Start End Sectors Size Id Type /dev/sdb1 * 63 7897086 7897024 3,8G 83 Linux $ sudo hdparm -t /dev/sdb1 /dev/sdb1: Timing buffered disk reads: 48 MB in 3.06 seconds = 15.68 MB/sec Patarimas - greitį pasitikrinkite kelis kartus. Jis gali nežymiai kisti. Taip yra dėl daugelio priežasčių. Kadangi turėjau ne vieną kortelę - lengvai išsirinkau greičiausią. Naujos pirkti nereikėjo. Jau anksčiau esu rašęs, kad kuo greičiau duomenis skaito Jūsų SD (ar microSD) kortelė, tuo greičiau veiks Raspberry Pi operacinė sistema ir joje esančios programos, kurios naudoja tą diską.

Kai tingisi skaityti manual puslapius

Kiekvienas programuotojas (arba informacinių technologijų fanas) tikriausiai ne kartą skaitė man puslapius vienai ar kitai komandai. Dažnai nutinka, kad dirbti reikia kuo greičiau, o per naujo skaityti man puslapius nėra laiko. Tuo labiau, kai Linux komandos dažnai nebūna vienodo formato. Pažiūrėkite į find komandą. Jeigu teko ją daug naudoti - žinosite, kad joje itin svarbus komandos argumentų eiliškumas. Paprastesnis būdas daryti darbus Linux terminale yra naudoti tldr komandą. Programos nebūtina diegti. Taigi, jeigu sėdite ant kokio Chromebook’o, ant kurio nesinori diegti paketų, galima pasinaudoti web puslapiu. Ką ši komanda daro? Vietoje nuobodžių tekstų ir didelio turinio pateikia pavyzdines komandos panaudojimo eilutes su trumpais komentarais: Nežinote kokia eilės tvarka komandos argumentus parašyti, kad suarchyvuoti failus arba išarchyvuoti vieną ar kelis failus iš archyvo? Pasinaudokite tldr. Dar naudingiau šią komandą turėti terminale. Įdiegti galite labai paprastai. Instrukcijos tiesiai iš oficialaus GitHub puslapio: npm install -g tldr Ir tuomet galite rašyti tldr <jūsų komandos pavadinimas>. Pavyzdžiui: jeigu tenka tik kartą per mėnesį naudotis dd komanda, bus lengva pamiršti kur ir ką rašyti. Su tldr bus labai paprasta (žr. nuotrauką aukščiau). Kartais bus naudinga atnaujinti komandų trumpinių duombazę su: tldr --update

Kaip pagreitinti HDD disko darbą

Daug anksčiau, kai dar mano asmeniniai kompiuteriai turėjo lėtus HDD diskus, ne kartą tekdavo susidurti su disko greičio bėda. Dabar SSD diskai yra velniškai pigūs todėl nėra nė kalbos apie jų atsinaujinimą. Tuomet, tokias „lėtumo“ problemas spręsdavau disko katalogą (Linux sistemose) perkeldamas į atmintį (RAM). Tą padaryti galima keliomis komandomis ir net nereikia perkrauti kompiuterio, kad tai išmėginti. Pavyzdžiui jeigu Jūs savo visus laikinus failų parsisiuntimus keltumėte į /tmp/ katalogą, tai viskas vyktų greičiau jeigu jį perkeltumėte į RAM. Tokio failo skaitymas ir vykdymas būtų ženkliai greitesnis, nei HDD (pavyzdžiui nešiojamo kompiuterio, kuris veikia 5 tūkstančių apsisukimų greičiu). Komanda: sudo mount -o size=1G -t tmpfs none /tmp Viena komanda perkelsite katalogo /tmp/ turinį į RAM atmintį, kurioje rezervuosite 1GB vietos. Tai reiškia, kad turėsite 1GB atminties tuo metu mažiau. Tai anokia bėda, jeigu turite nemažai vietos (bent 4GB ar 8GB). Tokia komanda gali būti perkelta į /etc/fstab failą ir tuomet, startuojant Linux, automatiškai bus prijungtas katalogas. Savo prijungtus katalogus galite matyti parašę: mount # nereikia `sudo` Bet kaip minėjau, perėjus į SSD toks poreikis dingo. Tačiau komandą vis dar naudoju iki šiol. Kodėl? Nes dažnai būna tokių situacijų serveriuose, kai pritrūksta inodes. O su tokia situacija tikrai galima susidurti kai tenka atnaujinti operacinę sistemą kokiame sename serveryje neturinčiame daug resursų. Mažas pastebėjimas, kad mount’inimas neištrina Jūsų failų. Katalogas, žinoma, bus tuščias, tačiau iki tol, kad atsisakysime mount operacijos: sudo umount /tmp Ir matysite senus failus.

VDS tiekėjas negali atstatyti tavo serverio?

Istorijos apie tai, kad kartais, Virtualių Dedikuotų Serverių (toliau - „VDS“) tiekėjai susimauna, ir neturi galimybės atstatyti serverio ir/arba atsarginių kopijų, yra gana retos. Tačiau akivaizdu - vis dar pasitaiko. Taip nutiko ir man, deja, su vienu populiariausiu Lietuvoje tokių paslaugų tiekėju Interneto Vizija (labiau žinomas adresais serveriai.lt ar dedikuoti.lt). Sisteminė klientams.iv.lt klaida - serveris perkrautas? Tai ši istorija apie tai, kaip reaguoti į tokias situacijas, kaip tvarkytis su jomis ir jų problemų sprendimo būdus. Viskas prasideda nuo monitorinimo Kiekvienas, be išimties, serveris ar paslauga privalo turėti monitorinimą. Nesvarbu ar Jūsų paslaugų tiekėjas tokį turi - privalote turėti ir Jūs. Nes kitaip, apie problemas - sužinosite paskutinis. Taip, tokį monitorinimą pats turiu - Nagios3. Jis tikrina kelis serverius, daugybę projektų jose, el. paštą, kai kurių svetainių SEO ir kitas tarnybas. Sisteminė klientams.iv.lt klaida - serveris perkrautas? Taigi, 05:45 vienas iš serverių nustoja veikti. Gaunu daug el. laiškų apie neveikiančias paslaugas. 49 interneto projektai neveikia, el. paštas ir kai kurios kitos smulkios paslaugos. Pirma mintis kurį šauna į galvą, po to, kai nepavyksta prisijungti prie ssh tarnybos - perkrauti serverį. Aiškintis kodėl taip atsitiko - vėliau. Jungiamės prie klientams.iv.lt ir perkrauname serverį per jų sistemą. Žinutė, kad tokia operacija bus įvykdyta per 5-10 minučių - nuramina, todėl galima eiti ramiai miegoti. 07:00 Nagios vis dar nepatenkintas Kadangi Nagios nepraneša apie sėkmingai veikiantį projektą, tikrinam klientams.iv.lt statusą ir gauname maždaug tokią žinutę: Sisteminė klientams.iv.lt klaida - serveris perkrautas? Taigi, kadangi jų vidinė sistema neveikia ir problemos sutvarkyti negalima, belieka kreiptis pas paslaugų tiekėją tiesiogiai - rašyti el. laišką. Laiškas išsiųstas su prašymu paleisti serverį. Kadangi jų darbo laikas prasideda 08:30, profesionaliausias daly ką galima šiuo atveju padaryti - įspėti visus klientus kurių projektai/paslaugos yra nepasiekiamos. Juos reikėtų informuoti apie tai, kas vyksta, kodėl įvyko, kada greičiausiai viskas startuos ir, aišku, atsarginį planą, kad esant rimtai bėdai - projektai po pietų veiks iš atsarginio serverio. 08:50 Vis dar nieko iš Interneto Vizijos Siunčiam dar vieną laišką. Kaip ir pirmame, pažymim - kad skubu. 09:00 Vis dar jokio atsako iš Interneto Vizijos Tikriausiai vieno sakinio laišką parašyti jiems, kad bėda tvarkoma, buvo per sunku. Nesulaukus jokios paslaugų tiekėjo reakcijos - skambinam. Patikina, kad problema kaip tik sprendžiama. Profesionaliausias dalykas ką galima padaryti šioje situacijoje - informuoti klientus, kad bėda tikrai sprendžiama arba bent jau bus sprendžiama po kažkurio laiko tarpo. Tą padariau visiems klientams kuriuos ši bėda taip pat palietė. 10:00 „Priežasties dar neradome“ - dedikuoti.lt Pirmoji reakcija, vieno sakinio, iš jų pusės. Kaip pirmas informavimas po 1.5 valandos - gana prastai. Ne tik neaišku kas buvo daroma, kiek tai laiko truko, bet tuo labiau kas toliau bus daroma ir kiek tai truks. Žinoma, situacija bloga. Komunikacija iš paslaugų tiekėjo siaubinga. Dar kartą informuojame klientus apie tai kas vyksta ir apibrėžiam viską laiko rėžiais. Tai yra, jeigu iki pietų Interneto Vizija taip graudžiai spręs problemas, tai kursime naują serverį, ir kelsime atsarginę versiją. Rankomis, žinoma. Atsarginių kopijų turiu kiekvieno serverio kiekvienos metų dienos (archyvą retokai trinu). Visgi, ankstesnės dienos projekto versija yra ne taip blogai kaip visiškai neveikiantis projektas, tiesa? 11:00 Vis dar jokios reakcijos Rašome laišką su prašymu patikslinti kas vyksta. Tuo metu, pasiruošiame atsargines kopijas (failų ir duomenų bazių) dėl viso pikto. Visgi, praėjo jau 2.5 valandos nuo jų darbo pradžios, o komunikacija iš jų pusės visiškai nevyksta. 11:50 Serverio atkurti nepavyks Ir gauname pagaliau laišką iš paslaugų tiekėjo: deja, tačiau serverio paleisti nėra įmanoma. Šiuo atveju branduolio (angl. kernel) atnaujinimo metu buvo perkrauti visi mūsų klientų serveriai, tačiau po perkrovimo Jūsų serveris visiškai neatsako į paleidimo komandą. Administratoriams peržiūrėjus situaciją nustatėme, kad serveris po perkrovimo nepasileidžia dėl nekorektiškai įdiegtų paketų su “force-confdef” parametru: Start-Date: 2016-06-17 09:45:52 Commandline: /usr/bin/apt-get -y -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold install libapache2-mod-php5 Upgrade: [..] End-Date: 2016-06-17 09:46:03 Start-Date: 2016-06-17 09:49:26 Commandline: /usr/bin/apt-get -q -y -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold remove samba-libs Remove: [..] End-Date: 2016-06-17 09:49:27 Šiuo atveju galėtume Jums pasiūlyti perrašyti serverio operacinę sistemą ir atstatyti serverio duomenų kopiją į serveryje esančią direktoriją. Kad serverio paleisti nepavyks - viskas aišku. Kritinė situacija. Dabar ją reikia spręsti. Kaip Kernelio paketai susiję su prieš 2 mėnesius įdiegtais PHP paketais nelabai aišku. Dėl to galima ginčytis iki nukritimo, ypač kai visa programinė įranga yra diegta iš Debian oficialių šaltinių. Bet ginčas - problemos neišspręs. Interneto Vizijos pasiūlytas sprendimas - perrašyti serverio operacinę sistemą, o atsarginę kopiją visų failų sumesti į kažkokį atskirą katalogą. Iškart akyse pasirodė kiek darbo gali užtrukti programinės įrangos diegimas. 49 projektai, Ruby / Python / PHP projektai, duomenų bazės, el. paštas ir kitos tarnybos. Viską teks įdiegti ranka. Turbūt pats neprofesionaliausias sprendimo būdas šioje situacijoje, kurį padarė Interneto Vizija, nusimesti visą atsakomybę ir problemos sprendimo būdus nuo savęs - parašyti laišką apie problemą, pasiūlyti vieną iš sprendimo būdų ir… Pamiršti apie problemą. 11:55 Skubiai atrašau, kad - NE! Skubiai atrašau, kad toks sprendimo būdas nepriimtinas. Kad jie nepateikė nei galimų alternatyvų, nei kokios to pasėkmės gali būti - patyliu. Laiške pasiūlau savo sprendimo būdą, kuris jau yra blogas - atstatykite vakar dienos atsarginę kopiją. Su padariniais pats tvarkysiuosi. 12:20 IV - pietauja? Negaudamas jokio pranešimo iš Interneto Vizijos skambinu jiems jau trečią kartą ir prašau nukreipti pas žmogų, kuris pasiūlė viską pradėti iš naujo. Deja, bet šiuo metu su juo pakalbėti nepavyks. Paklausus kada galima pasikalbėti - neaišku ir atsakyti negali. O siaube! Taip, visi mes žmonės ir galim turėti asmeninių reikalų. Taigi, valandai laiko problema nebus sprendžiama. Siunčiu laišką, kad man patys paskambintų, nes toks sprendimo būdas jų pasiūlytas - visiškai netinka. 13:00 IV skambutis Pagaliau man paskambina ir pradeda pasakoti situaciją. Yra kažkokios Open VZ bėdos (technologija kurią jie naudoja). Pasiūlau atstatyti atsarginę kopiją - sakė, kad bandė, bet paleisti ir jos nepavyko. Jeigu būčiau apie tai jau žinojęs anksčiau - greičiausiai per jų pietų pertrauką būčiau startavęs su kitu serveriu ir projektais. Dabar, dėl tokios komunikacijos - sugaišta valanda per kurią niekas nebuvo daroma. Taigi, reziume - jokio serverio ir jokių atsarginių versijų. Jokios ir komunikacijos. Pats blogiausias variantas, kurį tenka priimti buvo jų siūlytas - perrašyti serverį ir kažkur kataloge patalpinti seno serverio failus. Paklausus, kiek tai užtruks, išgirdau, kad apie pusvalandį. Nieko nepadarysi - tenka rinktis blogiausią variantą. Taigi, informuojame savo klientus, kas vyksta ir, kad po kelių valandų projektai vėl veiks. 13:50 „Ilgesnis pusvalandis“ Gaunu laišką, kad serveris buvo perrašytas ir failai kopijuojami. Mažiau nei pusė failų jau perkopijuota :( 15:00 ? Jokios informacijos, kad failai jau baigti kopijuoti negavau. Įprasta, iš Interneto Vizijos, tikriausiai. Diena parodė, kad komunikacija vienkryptė - tau reikia - tu ir skambink. Panikuoti nereikia, kaip yra taip. Sprendžiam problemą - reikia kuo skubiau paleisti visus projektus. Profesionalus sprendimo būdas šioje situacijoje - automatizuotas programinės įrangos įdiegimas. Parsisiunčiame „paruoštuką“ programinei įrangai diegti su Ansible arba saltstack ir per mažiau nei 10 minučių sudiegiame visą programinę įrangą į serverį. Atsargines kopijas pats turiu. Jeigu skaitėte mano ankstesnius straipsnius, tai yra ne vienas būdas kaip jas daryti. Šioje vietoje „paėmiau“ tai, ką IV sukrovė į /mnt/ katalogą. Pereiname per /etc, /var, /usr, /home katalogus ir sukilnojame failus/konfigūracijas. Pasitikriname su apache2ctl -t arba nginx -t konfigūracijas ir jeigu viskas gerai - perkrauname servisus. 15:40 Projektai ir vėl „online“ Profesionalus veiksmas šioje situacijoje - greitai informuojame klientus, kad projektai gyvi; kad imsimės priemonių, kad kitą kartą taip nenutiktų; paaiškiname situaciją ir primename, kad gali būti laikini sutrikimai. Juk negalima pasitikėti automatiniais įrankiais - viską **būtina#### pasitikrin Aišku, visko tikrinimas - trunka labai ilgai. 10 valandų „downtime“ Prisipažinsiu, kad tiek „downtime“ laiko per pastaruosius 5 serverių administravimo metus - neturėjau. Apmaudu, kad taip nutiko. Bet dar apmaudžiau, kad Interneto Vizija, tokia žinoma kompanija, visiškai pro pirštus žiūri į kritiškas situacijas. Ir dar apmaudžiau, kad taip nuvilia paslaugų tiekėją kurio paslaugomis naudojuosi kokius 7 metus. Pabaigai - viską vainikuoja Interneto Vizijos mandagus atsiprašymo laiškas. Kurį galėjau susikurti savo vaizduotėje. Aš, kad ir kaip vertinti situaciją - atsiprašiau klientų. Laikas keisti paslaugų tiekėją? Žinoma, kad ne. Nusivyliau labai komunikacija ir tuo, kad problema buvo sprendžiama kaip kokioje „praktikantų“ firmoje. Kažkurioje savo skaitytų knygų perskaičiau tokią frazę: “protingas žmogus išspręs problemą jai jau susidarius, išmintingas pasiruoš problemai, kad ji - nesusidarytų“. Svarbu ne tai, kaip pasiruošę kiti - o kaip pats pasiruošęs. Pamokos Nors pats tokiam duomenų dingimui buvau visai neblogai pasiruošęs (neskaitant to fakto, kad paslaugų tiekėjas sugaišo brangias 6 valandas, o man pačiam viską atstatyti truko 40 minučių) priminsiu kaip pasiruošit tokioms katastrofoms. Visada turėkite atsargines kopijas. Ne mėnesio ar savaitės senumo. Jau dienos - yra blogai. Turėkite bent 2 kartų dienoje kopijas. Nesaugokite kopijų tik viename archyve. Įprastai, aš turiu 3 vietas saugoti duomenis. Pasitikrinkite savo atsargines kopijas karts nuo karto. Ar jos nėra tuščios (0 baitų), ar jas galima išarchyvuoti. Pasitikrinkite ką Jūs saugojate. Nearchyvuokite savo kopijų tokiu suglaudinimo lygiu, kad po to išarchyvuoti truktų labai ilgai. Naudokite greičiausią/mažiausią archyvavimo lygį - taip jas galėsite atstatyti greičiausiai. Būtinai turėkite įrankį, su kuriuo įrašytumėte programinę įrangą per kelias minutes. SaltStack, Ansible ir daug kitų sistemų lengvai tą padės padaryti. Tuo labiau, nebūtina viską daryti patiems - pasinaudokite atviro kodo privalumais. Pasiimkite kieno nors konfigūracijas ir pritaikykite pagal save. Visada komunikuokite. Būtinai informuokite apie situacijas, net jeigu ir rašyti/skambinti nemalonu. Nepamirškite, kad gera komunikacija tokiose situacijose susideda iš: paaiškinimo, galimų sprendimo būdų, laiko apimties. Kaip Interneto Vizija komunikavo šioje situacijoje - puikus pavyzdys ko nedaryti. Būtinai turėkite monitorinimo sistemą. Ne Interneto Vizija mane pakėlė anksti ryte - bet mano paties monitorinimo serveris. Monitorinkite viską ką tik galite. Tvardykitės. Rėkti į ragelį gali visi. Piktai rašyti laiškus - gali visi. Turite būti ne aiškintojais, o problemų sprendėjais.

Ką galima nuveikti su Raspberry Pi 3

2016 metų vasario 29 dieną Raspberry Pi kūrėjai nustebino mus jau trečia Raspberry Pi versija. Kaip visuomet bazinė struktūra išlieka ta pati - kreditinės kortelės dydžio ir labai lengvas kompiuteris, turintis vieną GB RAM atminties, bei atrodantis labai panašiai į savo ankstesnes versijas. Tai mano jau ketvirtas Raspberry Pi kurį turiu. Kadangi jis tik neseniai pasirodė, Lietuvoje jį rasti yra keblu, tačiau tikrai galima: pavyzdžiui RS elektroninėje parduotuvėje. Perkant Raspberry dar rekomenduočiau būtinai jam nupirkti kažkokią dėžutę. Nors ši Raspberry Pi versija neturi tokių pavojingai išsikišusių kondensatorių kaip turėjo, tarkime, pirma versija, bet vistiek, kuo nors aplieti, numesti ar užmesti ant šio kompiuterio, tikriausiai, nenorėsite. Ir aišku, labai geram-greitam veikimui nepagailėkite pinigų nusipirkti itin greitą micro SD kortelę. Kuo greitesnį įrašymo ir skaitymo greitį jį turės - tuo greičiau viskas veiks Jūsų Raspberry. Nors Raspberry Pi ir greitas ir turi tikrai nemažai resursų, bet darant veiksmus operacinėje sistemoje bus labai daug kreipinių daroma paimti informacijai iš SD kortelės. Labai daug. Taigi, lėta kortelė gali tiesiog sugadinti Jūsų požiūrį į šį kompiuterį. Ši nauja versija siūlo jos turėtojams galingesnį CPU - 1200 Mghz, lyginant su ankstesne versija kuri turėjo 900 Mghz, ar su dar ankstesne kuri turėjo 700. Didesnės naujovės šioje versijoje - net 4 USB prievadai. Tai itin svarbu, jeigu savo Raspberry norėsite paversti žaidimų stotimi. Anksčiau, pasijungti vairalazdę ar kelis valdymo pultelius buvo itin sudėtinga be USB šakotuvų. Ši naujoji versija palaiko net ir Windows operacinę. Tiesa, kaip ir anksčiau, Raspberry operacinių sistemų distribucijos yra atskiros dėl savo arm procesoriaus architektūros, todėl tiesiog diegti Ubuntu ar kokią nors kitą operacinę sistemą nepavyks. Būtina ieškoti arm architektūros operacinių sistemų. Jų, net ne viena, yra Raspberry Pi parsisiuntimų svetainėje. Naujovė - jeigu norite naujinti savo Raspberry į Raspberry Pi 3 - reikės keisti savo SD / MMC / SDIO į MicroSDHC kortelę. Kadangi jos nebrangiai kainuoja, didelės problemos greičiausiai nebus. Ypatingai gera žinia - Raspberry Pi 3 turi integruotą Wifi. Viena iš problemų jau minėjau - kad anksčiau Raspberry Pi turėjo tik 2 USB. Taigi, įkišate į vieną iš jų wifi adapterį, ir turite tik vieną laisvą USB. Bluetooth ryšys yra taip pat svarbi gera naujovė. Ypatingai jeigu naudositės failų perdavimais, kokiomis belaidėmis Bluetooth ausinėmis ar kokiais nors valdymo kontroleriais (pavyzdžiui belaidžiais žaidimų pulteliais). Kur galima panaudoti Raspberry Pi 3 Jeigu ieškosite informacijos internete, tai pirmoje vietoje sutiksite du dalykus: Retro žaidimų kompiuterio gaminimą arba Media centro kompiuterį. Ir vieną ir kitą turiu savo namuose. Retropie - žaidimų kompiuteriui Jeigu prisimenate tokius senus žaidimus ant Nintendo (arba senesnių konsolių) kaip Mario, Battle City ar pan., tai tikriausiai kils noras realiai pabandyti. Laimei, čia jokių techninių žinių nereikės norint tai įgyvendinti. Pagal savo Raspberry Pi versiją užteks parsisiųsti SD kortelės atvaizdą, jį įsirašyti į SD kortelę ir pasileisti. Žinoma, Jums reikės kažkokios išvesties, tarkime dviejų žaidimų pultelių arba bent jau klaviatūros. O pačių žaidimų, nemokamai ir legaliai galima susirasti tiesiog internete (vienas pavyzdžių yra pdroms.de jeigu neklystu). Verta paminėti, kad anksčiau norint turėti Retropie ant savo Raspberry Pi B modelio (pirmos versijos) reikėdavo laukti net 16 valandų kol viskas įsidiegs. Dabar, dėl atvaizdų pagalbos įsidiegti viską galima per kelias minutes per daug nelaužant galvos techniniais dalykais. Kodi - media centras Labai populiarus Raspberry Pi panaudojimas yra media centro pakūrimas. Esu gavęs komentarų, kad kaip toks kompiuteris gali pavežti didelės raiškos filmus. Tikrai gali. Tiesa, senesnės Raspberry Pi versijos nors ir rodydavo filmus geros raiškos, be jokių vaizdo ir garso trikdžių, bet kitais dalykais, tokiais kaip naudotis pele, arba naršyti po nustatymų meniu žiūrint filmus - naudotis be strigimo vargu ar pavyks. Tai itin erzina, kai reikia su pele išjungti filmą, bet pelė stipriai „pristabdo“. Dėl Raspberry Pi 3 patobulinimų, džiugu pranešti, kad šios bėdos pagaliau jau nėra. Tikriausiai dėl procesoriaus patobulinimo, nes nudžiugau pamatęs, kad didelės raiškos filmo leidimo metu ką nors papildomai darant niekas nestringa. Vėlgi, media centrą įdiegsite tikrai lengvai. Parsisiųskite kortelės atvaizdą, įsirašykite į SD kortelę ir pasileiskite. Taip, tikriausiai į galvą šaus mintis - bet man dar reikia ir filmų! Laimei, media centras turi labai daug papildinių. Kadangi Raspberry Pi 3 turi Wifi palaikymą, tai jis per papildinius galės Jums rodyti įvairius filmus, juokelių video, žinias ar pan. Įskiepių tikrai labai daug, tai net jeigu ir Youtube yra Jums ne prie širdies, vistiek rasite daug kitų dalykų į kuriuos galima „pavėpsoti“. Panašiai kaip ir Chromecast, savo media centrą galėsite valdyti ir per išmanųjį telefoną. Kiti panaudojimo būdai Tikriausiai ne vieną kartą dalyvausite (ar jau dalyvavote) kokioje nors diskusijoje kurioje išgirdote „man reikia kompiuterio naršyti internete“. Jau ir anksčiau siūliau Raspberry Pi tokiems žmonėms, tik tiek, kad anksčiau dar tekdavo pridurti, kad reikės nusipirkti Wifi adapterį arba LAN kabelį nutiesti iki Raspberry Pi. Patikėkite, tai greitai atbaido tokius žmones. Na, dabar dėl to rūpintis nereikia. Kas dar smagu, kad daugelis šiuolaikinių monitorių ar televizorių turi USB prievadą kurį galima panaudoti Raspberry Pi „maitinimui“. Tiesa, ankstesnės versijos neturėjo Windows palaikymo. O čia naujovė su šia versija, taigi nereikės gąsdinti žmonių su Linux’ais. Labai populiarus panaudojimas Raspberry yra elektronikoje. Tie kas yra susidūrę, tikriausiai pasakys, kad tam labiau skirtas yra Arduino. Deja, turėdamas abu, galiu pasakyti, kad testuoti savo padarytas elektronines sistemas su Raspberry yra N kartų lengviau. Vien dėl to, kad be jokio programavimo galima valdyti GPIO kontaktus (kas tai yra rasite čia. O Arduino turi programuoti, kompiliuoti, įrašinėti į atmintį… NAS serveris dar vienas itin populiarus panaudojimas. NAS (Network Attached Storage - angl.) yra toks Raspberry Pi pajungimo būdas, kuriuo metu failus prijungtus prie jo pasieksite per internetą. Greičiausiai pagalvosite, kad kam tai daryti, kai dabar visokie Google ar Dropbox siūlo įspūdingai dideles nemokamas talpyklas. Deja, bet į tas talpyklas siųsti Torrent’ų negalėsite. O su Raspberry Pi pasidaryti daug didesnės talpyklos sistemą panašią į Dropbox su Owncloud galėsite tikrai nesunkiai. Kiek sudėtingesni dalykai reikalaus daugiau laiko. Pavyzdžiui buvau pasidaręs namų apsaugos sistemą su Raspberry Pi, kuri filmuoja namus ir praneša, jeigu yra judesiai. Taip pat ir vaizdo kamerų peržiūra su telefonu. Tą galima susikonfigūruoti įrašius į operacinę sistemą Motion programinę įrangą (atviro kodo). Skraidantys dronai, namų automatizavimo įranga, klusteriai (clusters - angl.) pareikalaus daugiau naršymo internete, konfigūravimo ir priežiūros. Apibendrinimas Ši Raspberry Pi 3 versija tikrai gerokai patobulėjo lyginant su senesne versija. Kai toks jos pritaikymo spektras platus - nuo paprastų personalinių kompiuterių iki elektroninių sistemų, tai tikriausiai dar teks įsigyti ateityje daugiau šių kompiuterių. Taigi, nepraleiskite progos išsibandyti ir jeigu kažką neįprasto ar įprasto, bet naudingo, pavyks pasigaminti - būtinai duokite žinoti.

HTTPie - CLI įrankis žmonių kalba

Programuojant ne kartą teks imti duomenis iš kokios nors API arba tiesiog atlikinėti kokias nors HTTP užklausas. Aišku, į galvą šaus pati populiariausia programinė įranga - curl. Nors su ja galima padaryti stebuklus, bet dažnam naudojimui ji yra ganėtinai nepatogi. Iš pradžių kliūva curl komandos argumentų dydis paprastiems dalykams (jis dažniausiai labai ilgas kai tenka paduoti ne vieną duomenį, argumentą ar siųsti kokias nors antraštes), bet dar ir sunku prisiminti kai kuriuos komandinės eilutės argumentų aprašus. Jeigu šiuo reikalu dirbate dažnai, čia labai stipriai pagelbės HTTPie. Įdiegti ją labai paprasta (Debian operacinių šeimose): apt-get install httpie Arba bet kurioje kitoje sistemoje galima atsisiųsti tiesiai iš pypi repozitorijos: pip install httpie Tiesa, pastarasis variantas gali būti geresnis, nes didesnė tikimybė gauti naujesnę versiją. Paprastam turiniui ir antraštėms gauti užteks tik adreso: $ http www.jarmalavicius.lt HTTP/1.1 301 Moved Permanently Content-Encoding: gzip Content-Length: 196 [..] <html> [..] Testuojant API (pvz. man ne kartą pravertė testuojant Trello API) galima paduoti HTTP metodo tipą ir argumentus: http PUT example.org key=value Arba praverčia testuojant formas: http POST example.org username=example Ypatingai patiko debug režimo palaikymas: $ http -v POST example.org key=value | head POST / HTTP/1.1 Content-Length: 16 Accept-Encoding: gzip, deflate Accept: application/json User-Agent: HTTPie/0.8.0 Host: example.org Content-Type: application/json; charset=utf-8 &#123;"key": "value"&#125; <html> [..] Žinoma, ir failų įkėlimas į internetą veikia: http example.org < failas.txt Bei failų parsisiuntimas: http example.org/norimas/failas > failas.txt Na, o „killer“ funkcionalumas - galimybė išlaikyti sesijas tarp užklausų. Tiesiog sesijoms vardus duodant. Ypatingai pravers, tokiose svetainėse, kur kartą per dieną būtina užeiti, kad kažką gauti ;) Kaip HTTPie veikia, galima patestuoti su atviro kodo interneto paslauga: $ http --session=sesija -a username:password httpbin.org/get API-Key:123 $ http --session=sesija httpbin.org/headers Trumpai tariant HTTPie puikus, paprastas, lengvai naudojamas HTTP užklausų valdiklis galintis pagelbėti tikrai ne vienam programuotojui tiek testuojant programinę įrangą, tiek ją programuojant. Man sunku būtų įsivaizduoti PHP ar Python interneto projektų ar API testavimą su curl. Aišku, tas įrankis ne visai skirtas tokiems dalykams. Bet problemų diagnozavimui curl ar HTTPie yra nepakeičiamas įrankis.

GIT Hook'o paleidimas pasikeitus failams

Anksčiau rašiau kaip su GIT PUSH komanda atnaujinti projektus ir serveryje įvykdyti automatinius veiksmus. Dažniausiai tai: Python, PHP ar kitokio programinio kodo atnaujinimas; duomenų bazės migracijos; media ir kitų statinių failų atnaujinimai; duomenų valymo operacijos (sesijų, kešo); trečios šalies programinės įrangos konfigūracijos (pvz. apache/nginx perkrovimas). Produkcinėje sistemoje norėsis ne tik „atominių“ operacijų (čia pagelbės tik nebent load balancer’ų panaudojimas), bet ir kuo optimaliau atlikti šias operacijas. Nes laikas ypatingai brangus dalykas, tuo labiau produkcinėje sistemoje. Vienas iš patarimų kaip daryti tokius deployment’us greičiau - vykdyti komandas tik kai tam tikri failai buvo keisti. Pavyzdžiui nenaujinti duomenų bazės, jeigu tarp pakeistų failų nėra migracijų katalogo redagavimų. O padaryti tokį tikrinimą nėra sunku su post-rewrite hook’u kurį aprašytume .git/hooks/post-rewrite faile: #!/bin/bash changedfiles=( $(git diff --name-only HEAD@&#123;1&#125; HEAD) ) if [[ "$&#123;changedfiles[*]&#125;" =~ "bower.json" ]]; then bower install && bower update fi if [[ "$&#123;changedfiles[*]&#125;" =~ "package.json" ]]; then npm install fi if [[ "$&#123;changedfiles[*]&#125;" =~ "migrations/" ]]; then python manage.py migrate fi if [[ "$&#123;changedfiles[*]&#125;" =~ "migrations/" ]]; then php vendors/phpmigrations/manage.py migrate fi Ir jeigu esate pastabus programuotojas, žinosite, kad reikia suteikti šiam failui vykdymo teises su chmod +x .git/hooks/post-rewrite. Trumpi paaiškinimai. Kintamajam changedfiles priskiriame masyvą pakeistų failų (dėl to ir yra skliaustai apie komandą git diff --name-only HEAD@&#123;1&#125; HEAD). Vėliau if sąlygomis tikriniame ar jis turi bent vieną elementą kuris gali atitikti užklausą (operatorius =~). Ir jeigu atitinka - vykdome komandas. Aukščiau pateikiau ne vieną variantą kuris gali praversi JavaScript, PHP ar kitų kalbų programuotojams. Žinoma, nenaudokite to vien tik migracijoms - panaudokite ir kitoms operacijoms. Šis post-rewrite hook’as vykdomas kai vyksta istorijos redagavimas. Jis pavykdys „commit“ žinutės keitimo (git commit --amend) ar istorijos medžio lipdymo/konstravimo metu (git rebase). Jums gali praversti angliškas hook’ų aprašymas GIT dokumentacijoje.

Logcheck ignoruojamų taisyklių tikrinimas

Neįsivaizduoju serverio kuriame neveiktų Logcheck. Kas dar neturėjo progos patyrinėti šios programinės įrangos - pasakysiu, kad tai tiesiog paprasta programėlė kuri pasirūpina, kad būtumėte informuotas kai klaidų žurnalas pasipildo. Kaip ir WEB programuotojui taip ir serverių administratoriui, kuris nori žinoti kas vyksta serveriuose, logcheck yra tikras išsigelbėjimas. Tik įdiegus (užteks paprasto apt-get install logcheck) reikės susikonfigūruoti apie ką norėsite būti informuotas. Faile /etc/logcheck/logcheck.conf rasite ne tik konfigūracijos nustatymus, bet ir jų aprašymus komentaruose. Todėl atskirai jų nenagrinėsiu. Logcheck konfigūracijų rekomendacijos Mano pirma rekomendacija būtų nusistatyti paranoid pranešimų lygį. Žymiai geriau gauti labai daug žinučių ir atsifiltruoti ko nereikia, negu kažką pražiopsoti. Tą padarysime konfigūracijų failą nustatę: REPORTLEVEL="paranoid" Ir būtinai įsirašykite savo el. pašto adresą kur norėsite gauti pranešimus: SENDMAILTO="sysadmin@example.org" Visa kita, ne tiek ir svarbu. Kada pranešimus gausite galite pasitikrinti cron faile /etc/cron.d/logcheck (greičiausiai pagal nutylėjimą tai bus kas valandą). Žinučių ignoravimas su Logcheck Susikurkite nuosavą failą kataloge /etc/logcheck/ignore.d.paranoid ir jame aprašykite ignoravimo taisykles. Štai kaip atrodytų tipinis, tingių PHP programuotojų, ignoravimo failas /etc/logcheck/ignore.d.paranoid/php-errors: ^.*Client sent malformed Host header ^.*Directory index forbidden by Options directive: .* ^.*Invalid Content-Length.* ^.*Invalid URI in request POST TP.* ^.*Invalid URI in request.* Kaip matome - regexp. Tiesa, nebūtinai. Galite tiesiog dalį teksto įrašyti - taip pat suveiks. Logcheck ignoravimo komandų testavimas O kaip patestuoti logcheck išvestį po ignoravimo komandų jeigu ten aprašėte labai sudėtingą regexp’ą? Su kita komanda! cat /var/log/apache2/error.log | egrep -v -f /etc/logcheck/ignore.d.paranoid/php-errors Ir gausime tokias žinutes kurios yra /var/log/apache2/error.log faile, tačiau nesutampa su faile /etc/logcheck/ignore.d.paranoid/php-errors aprašytomis išraiškomis. Priešingą paiešką mums duoda egrep -v komanda. Logcheck praktinis panaudojimas Man, kaip Python ir PHP programuotojui, yra svarbu žinoti kas vyksta ne tik pačiuose serveriuose kuriuos turiu, bet ir sukurtoje programinėje įrangoje. Tokios žinutės iš sisteminių failų dažnai yra pravertusios sutvarkyti ne vieną rimtą bėdą, kol ji netapo rimtesnė. Pavyzdžiui programuojant PHP drąsiai galiu rašyti visokias loginimo sąlygas su paprastu error_log() ir tikrai žinau, kad logcheck pasirūpins, jog nepraleisčiau tokių žinučių. Programuojant Python greičiausiai jau teks konfigūruoti logging paketą. Žinutes nukreipti į atskirą klaidų žurnalo failą ir logcheck pasakyti, kad jis iš jų skaitytų. Kalbant apie gerąsias praktikas, siūlau nenustatinėti logcheck laiškų siuntimo „realiu laiku“ (tarkime kas dvi minutes), nes galite gauti labai daug spam’o į savo pašto dėžutę.

Kaip terminale dirbti su CSV failais

Labai mėgstu CSV failo formatą kai kalba eina apie išvestį terminale. Jis patogus skaitymui, jį lengvai supranta GUI programos, o ir didelį failą atsidaryti - jokia bėda. Aišku, kalbame apie darbą su duomenimis terminale. Pirmiausiai tai trumpai kas yra CSV failo formatas, jeigu yra dar nežinančių apie ką eina kalba: tai paprastas tekstinis failo formatas tekstiniams duomenims laikyti; pirmoje failo eilutėje gali būti (gali ir nebūti) išvardinti duomenų stulpeliai; kitose eilutėse arba nuo pat pirmos gali būti išvardinti duomenys - vienas duomenų masyvas per eilutę; stulpeliams atskirti naudojami kableliai (iš to kilęs formato pavadinimas - kableliu atskirtos reikšmės); reikšmės turinčios kablelį turi būti apskliaudžiamos kabutėmis; kabutės reikšmėse turi būti aprašomos dviem kabutėmis arba dedamas ‘' simbolis prieš jas. Jeigu kartais prireikia dirbti su CSV failu terminale, tai puikiai pravers atviro kodo miller programa. Kadangi kūrėjai instrukcijų (dar?) neparašė, tai įdiegsime ją taip paprastai: git clone https://github.com/johnkerl/miller.git cd miller autoreconf -if ./configure make Sutinku, ne pats gražiausias diegimo procesas, bet ką jau padarysi. Yra kur tobulėt programos autoriams. Ir Jūsų kompiuteryje bus įdiegta mlr komanda, kurią galėsite pasinaudoti darbui su CSV failais. Programos pagalbos apraše rasite krūvas panaudojimo pavyzdžių. Pasižiūrime CSV failo turinį: $ mlr --csv cat Managers.csv playerID,yearID,teamID,lgID,inseason,G,W,L,rank,plyrMgr wrighha01,1871,BS1,NA,1,31,20,10,3,Y woodji01,1871,CH1,NA,1,28,19,9,2,Y paborch01,1871,CL1,NA,1,29,10,19,8,Y lennobi01,1871,FW1,NA,1,14,5,9,8,Y Rodome tik kai kuriuos stulpelius: $ mlr --csv cut -f playerID,yearID Managers.csv playerID,yearID wrighha01,1871 woodji01,1871 paborch01,1871 lennobi01,1871 Darome tikrą CSV failo duomenų filtravimą: $ mlr --csv filter '$yearID > 1871' Managers.csv playerID,yearID,teamID,lgID,inseason,G,W,L,rank,plyrMgr cravebi01,1872,BL1,NA,1,41,27,13,2,Y millsev01,1872,BL1,NA,2,17,8,6,2,Y clintji01,1872,BR1,NA,1,11,0,11,9,Y woodji01,1872,BR1,NA,2,18,3,15,9,Y Išrikiuojame duomenis pagal stulpelį: $ mlr --csv sort -f playerID Managers.csv playerID,yearID,teamID,lgID,inseason,G,W,L,rank,plyrMgr actama99,2007,WAS,NL,1,162,73,89,4,N actama99,2008,WAS,NL,1,161,59,102,5,N actama99,2009,WAS,NL,1,87,26,61,5,N actama99,2010,CLE,AL,1,162,69,93,4,N Darome aritmetines operacijas: $ mlr --csv put '$years = $yearID + 1000' then cut -f playerID,years Managers.csv playerID,years wrighha01,2871 woodji01,2871 paborch01,2871 lennobi01,2871 Trumpai tariant - įspūdinga biblioteka. Lengvai eksportuoti duomenys į CSV failą gali virsti tikra duomenų baze su daugybe galimybių. Žinoma, gerai išmanant awk galbūt ir nesinorės mokytis naudotis dar viena programa, bet man, asmeniškai, po awk ši komanda pasirodė kaip produktyvesnis būdas tai daryti. Išbandykite patys. O programos pagalbos apraše rasite dar daugiau naudingų pavyzdžių.

GIT HOOK'as tikrinantis pavojingus žodžius kode

Nebe pirmas mano straipsnis apie versijavimo sistemų papildomą pagalbą dirbant. Labai daug darbo nusiimu nuo savo galvos pasinaudojus šiais pagalbininkais: Git hook’u įrašančiu užduoties ID automatiškai Branch’o vardo tikrintoju Git push komanda projektui atnaujinti Arba kitais iš kategorijos versijavimo sistemos Šiandien tęsiant šią temą (tikiuosi pravers ne vienam), pakalbėsiu apie pavojingų žodžių tikrinimą prieš darant commit. Per daugelį darbo metų tiek pats ne kartą buvau išsiuntęs į repozitoriją (ar net į produkcinį serverį) įvairų „debuginimo“ kodą, tiek labai daug kartų buvau matęs, kaip tai kiti padaro. Išvengti to galima ir tikrai nėra sudėtinga. Pasikurkime failą .git/hooks/pre-commit su turiniu: #!/bin/bash test_words_existance() &#123; if git diff --cached -U0 "$1" | grep -P '^\+' | grep -q "$2" then echo "Rastas įrašytas naujas pavojingas žodis $2 faile $1!" fi &#125; while read st file do # Praleisti ištrintus failus if [ "$st" == 'D' ] then continue fi # Bendriniai žodžiai test_words_existance "$file" TODO test_words_existance "$file" FIXME test_words_existance "$file" XXX done < <(git diff --cached --name-status) Ir būtinai šiam failui skirkite vykdymo teises su chmod +x .git/hooks/pre-commit. Panagrinėkime ko galima tikėtis. Pradėkime nuo while ciklo. Į jį iš subproceso paduosime git diff pakeistų failų sąrašą, kuris bus tokiu pavidalu: [STATUSO RAIDĖ] [FAILO VARDAS]. Visa išvestis be laužtinių skliaustų. Ir per šiuos failus darysime žodžių tikrinimą, jeigu to failo būsena nėra ištrinta (statuso raidė ‘D’). Didelis grep sakinys git diff --cached -U0 "$1" | grep -P '^\+' duos mums pakeistų eilučių išvestį (jos prasidės + simboliu). Būtent šiose eilutėse ir ieškome tų „pavojingų“ žodžių. O kas galėtų būti „pavojingi“ žodžiai? Priklauso nuo programavimo kalbos. Pavyzdžiui PHP jie galėtų būti: var_dump, print_r arba debug_backtrace. Javascripte paliktas console.log arba debugger. Tai tokios komandos, kurios galėtų sukelti nekorektišką programos veikimą. Man, prie to paties, pavojingi žodžiai yra TODO, FIXME ir pan. Jų commit’inimas reikštų, kad dabar kas commit’inama - jau veikia nekorektiškai ir reikalauja kažkokio darbo. Arba tai puikus būdas pasižymėti, jog kažkas nebaigta ir netyčia nesukomitinti. Žinoma, kitiems toks dalykas galbūt pasirodys per daug destruktyviu. Daugiau pavyzdžių rasite mano GitHub faile.

GIT HOOK'as įrašantis užduoties ID automatiškai

Jeigu darbui naudojate Git Flow Jums bus pažįstamas branchų versijavimas ir kam ir kodėl jis reikalingas. Jeigu nenaudojate - siūlyčiau pasekti nuorodą ir susipažinti. Ši darbų eiga tikrai gali Jums padėti pasidaryti tokią programavimo darbų eigos architektūrą, kuri gerokai patobulintų darbo kokybę ir sudarytų tinkamą, šiuolaikišką ir patogią struktūrą versijuojant projektus. Daug kam bus nesvetimas ir užduoties ID rašymas commit žinutėse. Kaip užtikrinti, kad visos commit žinutės turėtų užduoties ID - jau rašiau praėjusiame straipsnyje. Kad nereiktų ilgai galvosit, atsidarinėti naršyklės ir ieškoti savo „track’o“ su užduoties ID siūlau jį rašyti branchų varduose, pavyzdžiui: git branch feature/2911-users-api git branch hotfix/3341-aws-sync-large-files Na, ir galiausiai susikurkime tokį Hook’ą faile .git/hooks/prepare-commit-msg: #!/bin/bash # if it contains some number in branch name - use it as ticket ID TICKET=$(git symbolic-ref HEAD | sed 's/[^0-9]*//') if [ -n "$TICKET" ] then mv "$1" "$1.bak" echo "#$TICKET " > "$1" cat "$1.bak" >> "$1" rm -f "$1.bak" fi Ir būtinai suteikime šiam failui vykdymo teises su chmod +x .git/hooks/prepare-commit-msg. Aiškinti šiame hook’e nelabai yra ką. Komanda git symbolic-ref HEAD yra viena iš daugelio, kurią galima panaudoti brancho vardui išgauti. Šiame skripte “$1” yra laikinas failo vardas kurį sukuria GIT tam, kad vėliau atidarytų jį su redaktoriumi ir lauktų, kol redaktorius užsidarys, kad galėtų pratęsti commit’ą. Taigi, jeigu Jūsų branch’o vardas turi savyje skaičius, jie bus panaudoti kaip užduoties ID ir prirašyti commit žinutėje kai atidaromas redaktorius (taigi, git commit -m čia netiks - šiai komandai kada nors vėliau parodysiu kitą skriptą). Pavyzdžiui esant branche feature/6544-allow-login-using-fb po pakeitimų parašius git commit bus matoma redaktoriuje: #6544 * Please enter the commit message for your changes. Lines starting * with '*' will be ignored, and an empty message aborts the commit. [..] Per kelis metus šis hook’as man sutaupė rekordiškai daug laiko. Tikrai siūlau išbandyti.

Tikriname commit žinutes dėl užduoties ID

Pratęsiant praėjusį naudingą straipsnį apie Brancho vardo tikrinimą GIT Hook’e norėčiau papasakoti apie dar vieną labai naudingą tikrinimo hook’ą kuris tikrina mano darbus daugelį kartų per dieną. GIT hook’as kuris praneša, jeigu netyčia commit žinutė neturi savo pradžioje užduoties ID. Tipinė commit žinutė mano projektuose būtų tokia (paėmiau iš vieno iš savo projektų git log): #7264 Improve Dropbox cleanup Dropbox complains when removing folders which has too many files inside. This fixes by splitting files queue to smaller pieces and making more requests to Dropbox API. Aišku, detalesnį aprašymą rašau daug rečiau, bet tik labai retais atvejais žinutės būna be užduoties ID. O tam, kad nereikėtų daryti savo pačio žinutėse revizijos, susikūriau GIT Hook’ą, kuris neleistų sukomitinti jeigu užduoties ID pamirštas. Tą galime pasidaryti paprastai sukūrę failą .git/hooks/commit-msg ir jame įrašę: #!/bin/sh if head -n 1 "$1" | grep -Pvq "^#[0-9]+" then echo >&2 "ERROR: Ticket number is missing in commit message" exit 1 fi Ir aišku, suteikime šiam failui vykdymo teises su chmod +x .git/hooks/commit-msg. Trumpai apie šio hook’o aspektus. Pirmiausiai jame pamatysite komandinės eilutės argumentą $1. Jis savyje laiko laikino failo vardą kurį sukūrė GIT konstruodamas pradinį žinutės tekstą ir ką vėliau išsaugosite redaktoriuje (jeigu nenaudojate git commit -m). Eilutė head -n 1 "$1" iš šio failo paims tik vieną - pirmą - eilutę. Čia tam, kad išvengti „galvojimo“, kad kur nors žinutės aprašyme bus eilutė prasidedanti grotelėmis ir skaičiais. Eilutė grep -Pvq "^#[0-9]+" atrodo gana baisiai. Čia su grep ieškome eilučių su regexp (dėl to ir yra argumentas -P) kurios prasideda grotelėmis ir skaičiais (pvz.: „#1234 Užduoties aprašymas“). Argumentas -v yra tam, kad if sąlyga „suveiktų“ jeigu teksto ieškomo nerado, o -q argumentas, kad į komandinės eilutės išvestį neišvestų surasto rezultato, jeigu toks būtų. Na ir eilutės: echo >&2 "ERROR: Ticket number is missing in commit message" exit 1 Turėtų būtų gana suprantamos: išvedamas tekstas į stderr išvestį ir su exit 1 nutraukiamas tikrasis commit’as, dėl surastos klaidos. Kitame straipsnyje parodysiu kaip galima iš brancho vardo išgauti užduoties ID, kad jo ranka nereikėtų rašyti.

Yank komanda terminalo išvesčiai kopijuoti

Daug dirbant su komandine eilute tikrai ne vieną kartą tenka kažką persikopijuoti. Ypač dažnai iš kažkokios komandinės eilutės rezultato gali prireikti persikopijuoti kažką. Taigi tokiems kopijavimams tikrai pravers komanda yank. Paleiskite komandą kurios išvestį norėsite persikopijuoti (jos dalį) ir tuomet perleiskite per yank komandą. Ją parsisiųsti galite iš Yank Github puslapio. Diegimo instrukcijas rasite repozitorijoje. O greitam išbandymui tiesiog „klonuokite“ repozitoriją, ir paleiskite komandą make. Pavyzdžiui persikopijuoti kažkurio proceso PID galite su: pgrep -f chromium | yank Ir galėsite klaviatūros rodyklių pagalba pasirinkti ką persikopijuoti. Vėliau perkopijuotą informaciją galėsite įsiterpti su shift+insert klavišais klaviatūroje. Dar vienas smagus panaudojimas yra IP adreso persikopijavimas iš ifconfig: ifconfig | yank -d " :" Atkreipkite dėmesį į -d („delimiter“ angliškai) argumento panaudojimą. Jis leidžia skaldyti išvestį į tam tikrus skirtukus. Labai panašiai veikia awk -F komanda. Mums reikia dviejų skirtukų šioje komandoje - dvitaškio kuris būna prieš ip tekstą ir tarpo kuris bus po jo. Būtent šios formuluotės sąlyga ir yra “ :”. Kaip viskas veikia galite pasižiūrėti trumpoje animacijoje: O daugiau informacijos apie iškarpinės konfigūracijas ir komandos panaudojimo būdus rasite GitHub puslapyje.

Branch'o vardo tikrinimas GIT Hook'e

Praėjusiame straipsnyje rašiau apie GIT PUSH komandą projektui atnaujinti. Pratęsiant temą, šiame straipsnyje aprašysiu kaip į Hook’ą įvesti tam tikros (kokybės?) kontrolės. Labai svarbu kas yra įkeliama į projektą. Galbūt „testing“ ir „development“ aplinkose galėsite sau leisti turėti bet kokį branch’ą, bet pavyzdžiui „staging“ tikriausiai norėsite tik master (ar kitokio, iš anksto numatyto, branch’o). Todėl bus svarbu užtikrinti, kad niekas į tą versiją nepakliūtų, o programuotojai būtų informuoti apie tai, kas bandoma padaryti. Tą nesunkiai užtikrinsite dar vieno GIT Hook’o pagalba: pre-receive (failas .git/hooks/pre-receive): #!/bin/bash while read oldrev newrev ref do if [[ $ref =~ .*/master$ ]] then git checkout -f else echo "Klaida - įkeliamas branch'as turi būti master." exit 1 fi done Būtina atkreipti dėmesį, kad Hook’ai nėra pašalinės komandos (angl. „external source“), o įterptinės. Dėl to, negalėsite pasiekti komandos argumentų iš komandinės eilutės, bet reikės naudotis trimis kintamaisiais iš kvietimo pusės. Šiame pavyzdyje tai oldrev, newrev ir ref. Pavadinimai turėtų būti pakankamai suprantami, kad suprasti ką jie savyje laiko. Ir aišku, pasinaudodami ref nesunkiai galėsime patikrinti ar pakeitimai ateina į tą branch’ą į kurį tikimasi. Jeigu ne, tai programuotojui bus parodomas pranešimas (net ir tada, kai vykdoma „tyli“ komanda git push -q). O exit 1 pasirūpina, kad GIT nepriimtų pakeitimų į nuotolinę repozitoriją.

Atsarginių kopijų atstatymas su tar komanda

Atsargines kopijas, tikriausiai, daro daugelis. Taip pat ir jas atstatinėja. Man, asmeniškai, tenka tai daryti gal iki 4 kartų per metus. Nedažnai, bet tenka. Tokiais atvejais labai svarbu tinkama reakciją į jų atstatymą: iš anksto suplanuota schema kaip jie bus atstatomi ir aiški sistema kaip tos atsarginės kopijos kaupiamos. Atsarginių kopijų kaupimui galima naudoti iš esmės bet ką: specializuotas saugyklas (pvz. S3 storage), Googlea Storage (kokį „Nearline“ ar pan.), rašyti į atskirą dedikuotą serverį-kaupyklą arba tiesiog saugoti kokioje nors atmintyje - tarkim dedikuotame HDD/SSD. Formatas saugojimo taip pat nėra svarbus, svarbiausiai tik tai, kad jis užtikrintų duomenų saugojimą, paprastą-greitą atstatymą ir būtų galimybė patogiai indeksuoti. Daugiau nei penketą metų atsargines kopijas laikau .tar.gz failuose. Formatas yra atviro kodo, patikimas, jo rezultatai užima mažiau disko vietos. Atsargines kopijas darau pagal tokias taisykles kurias išgryninau per daugelį metų: Į vieną archyvą atskirai dedu „vieną projektą“. Tai gali būti interneto svetainės turinys su kodu, arba duomenų bazė, arba kažkoks katalogas. Čia naudojau jungtuką „arba“, nes niekada į vieną archyvą nededu kelių: ir duomenų bazės ir kitų failų. Archyvuotą .tar failą visada „suzipuoju“, kad užimtų mažiau vietos (su tar -cZ). Atsargines kopijas reikia daryti kaip įmanoma dažniau - geriausiai net po kelis kartus per dieną. Išmokta pamoka - vienas sunkiausių dalykų darant atsargines kopijas yra patogus saugojimas (failų pavadinimai). Indeksuoju archyvus katalogais. Pirmas katalogas būtų „mašinos vardas“, vėliau sektų informacijos tipas, vėliau metai ir viduje archyvai pagal mėnesius ir datas. Taigi, kaip atrodo kelias iki pavienes saugyklos: /backups/serveris-1/websites/2015/2015-10/2015-10-01_13:59_example.org.tar.gz Oh, kiek metų dubliavimo! Taip. Ir patikėkite, jis labai reikalingas (skaitykite toliau). Pavyzdžiui svetainės example.org visų archyvų paieškai galime panaudoti: find -iname '*example.org.tar.gz' Arba saugyklai labai išsipūtus, galima paimti ir ankstesnius metus, pavyzdžiui /backups/serveris-1/websites/2014 perkelti į Amazon Glacier kur jie bus pigiai saugomi. Aišku, tokia saugykla, jeigu Jums teko kada naudotis, turi minusą, kad prie failų prieisite tik po kelių valandų, jeigu bus poreikis. Bet čia ir esmė saugoti juos tik tam, kad turėti (turiu omeny „tokius senus archyvus“). O pinigine prasme tikrai verta! Labai panašiai veikia ir Google Nearline tik jos duomenų atidavimas yra greitesnis. Na, ir keletas tipsų apie greitą duomenų atstatymą. Pirmiausiai, tai turint .tar.gz Jums nereikės gunzip pavykdyti prieš dirbant su atsargine kopija. Čia užteks tar -z pagalbos. Pradžiai tikriausiai visada reikės pasižiūrėti kas yra archyve: tar -tvzf 2015-10-01_13:59_example.org.tar.gz | less Suradus tam tikrą failą ar katalogą galime jį atstatyti: tar -xzfv 2015-10-01_13:59_example.org.tar.gz kelias/iki/katalogo/ar/failo Užrašymui „ant viršaus“ naudojame („tikras atstatymas“): tar -xzfv 2015-10-01_13:59_example.org.tar.gz -C /var/www Mano aukščiau naudotų komandų argumentų paaiškinimai: -t -v - atspausdina kas yra archyve. -f - išveda failus į failų sistemą. -z - reikalingas dirbti su „zipuotais“ failais. Turint tik .tar plėtinį šios komandos nereikia. -x - yra išarchyvavimo komanda.

VIM autosave

VIM mylėtojų Lietuvoje tikrai daug. Aš pats perėjęs ne vieną redaktorių (tikriausiai kaip ir visi kiti programuotojai) ir tie kurie prijaučia VIM (arba Emacs) tikrai supras skirtumą tarp pastarųjų ir tokių kaip Eclipse ar Notepad++. Kaip ten bebūtų, šis straipsnis ne apie bandymą įrodyti kodėl vienas ar kitas geriau - ganėtinai sunku apie tai ginčytis. Sentimentai irgi stiprus dalykas. Straipsnis apie automatinį failų išsaugojimą su VIM redaktoriumi. Taip, aš jau seniai :wq (arba ZZ arba tiesiog :w) komandos nenaudoju, nesvietiškas laiko švaistymas. Tokios komandos naudingos vienkartiniams dalykams, bet aktyviam darbui - ne. Kad nespaudėlioti šių klavišų teks atlikti vieną iš dviejų dalykų - pasidaryti kokį nors maping’ą arba naudoti įrankius kurie kas tam tikrą laiką išsaugotų pakeitimus faile. Vienas iš tokių įskiepių VIM’ui yra vim-auto-save. Pats jį naudojau pusmetį, tačiau „atsimušiau“ į kelis bjaurius dalykus: Jeigu šį įskiepį naudosite su automatiniais linter’iais - turėsite labai stipriai stabdantį redaktorių. Jis visada saugo duomenis kas tam tikrą laiko tarpą. Tai reiškia, kad jeigu aktyviai „refaktorinat“, tai išsaugojimas įvyks iškart kai tik paspausite „ESC“ klavišą. Taigi, sintaksės klaidos pasikartos tikrai labai dažnai Jūsų kode. Dėl pastarojo dalyko naudoti tokį dalyką kaip „grunt watch“ tampa neįmanoma, nes grunt pamatęs pakeitimus mėgins atlikti savo darbus ir „nusikeiks“ pamatęs, jog kažkokie failai turi sintaksės klaidų. Taigi, ėmiau ir pasirašiau aš patobulinimą šiam įskiepiui. Ne ne, iškart pasakysiu, kad straipsnis ne apie savo įrankio reklamavimą. Taigi, skaitom toliau. Sugaišus daug laiko ir turint truputėlį pahakintą kodą pasidomėjau kas vyksta kai VIM’as saugoja failus ir priėjau prie išvados, kad visas šis tobulas funkcionalumas gaunamas vos kelioms eilutėm kodo .vimrc faile: set updatetime=1000 autocmd CursorHold,CursorHoldI * silent update Paaiškinimas labai paprastas: jeigu vieną sekundę ekrane nieko nevyksta, tuomet VIM gauna update komandą ir jos metu atnaujinamas failas. Tiesioginė paskirtis updatetime yra swap failo sukūrimui, jeigu redaktorius nieko nedaro ilgiau nei nurodytą laiko tarpą milisekundėmis. Tai išsprendžia ir bėdas apie kurias esu rašęs anksčiau. Jeigu aktyviai dirbate prie kodo, tai išsaugojimas nebus vykdomas tol, kol neduosite klaviatūrai laiko pailsėti nuo paspaudimų. Vienas iš didelių privalumų yra tai, kad, priešingai nei vim-auto-save, galite nustatyti savo laiką kada išsaugoti pakeitimus. Jeigu rašote greičiau, tikriausiai norėsite turėti updatetime reikšmę 500 ar net mažiau, jeigu rašote lėčiau - 2000 ar daugiau.

Vykdome komandas po failų pakeitimo su Entr

Daugelis tikriausiai žino grunt watch komandą kuri naudojama stebėti failus ir pavykdyti nurodytas komandas tiems failams pasikeitus. Dažnai šio funkcionalumo reikia ir kitiems dalykams, nebūtinai projektų failams. Anksčiau naudojau inotifywait kurį galite gauti įsidiegę operacinėje sistemoje inotify-tools paketą. Naudojimo pavyzdys: while inotifywait -e close_write failas.txt; do ./komanda.py; done Viena iš didelių bėdų kurią reikia išspręsti yra failų pakeitimas kitu failu. Dauguma teksto redaktorių išsaugant failą tiesiog užrašo failą vietoje kito failo ir inotifywait komanda nustoja veikti - nes tokio failo kurį tikrinate - jau nebėra (linksinio „node“, jeigu tiksliau). Šią problemą tenka spręsti sukant ciklą while true ir tokiu būdu tikrinant ar failas keitėsi. Tai ne pats gražiausias ir patogiausias būdas tą daryti. O sprendimų tam tikrai yra. Vien GitHub ką Jums gali pasiūlyti: filewatcher ar when-changed O aš tokiems dalykams naudoju labai primityvią komandą entr. Įdiegiame labai paprastai: apt-get install entr Jai paduosime failą/failus kuriuos norime stebėti ir komandą kurią norime vykdyti. Gerai tai, kad ji neturi inotifywait aprašyto apribojimo. Taigi, failai gali būti perrašomi. Štai pavyzdys kaip ją panaudojau rašant šį straipsnį: ls vykdome-komandas-po-failu-pakeitimo-su-entr.md | entr pelican content Taigi, tik pakeičiu nurodytą failą ir entr automatiškai pavykdys pelican turinio konstravimo komandą. Kadangi failus nurodome terminalo „globingo“ (neįsivaizduoju kas arčiausiai būtų lietuviško atitikmens) pagalba, tai galima nurodyti ir ne vieną failą: ls content/* | entr pelican content Aišku, gali tekti susidurti su situacija kada reikia kelių komandų pavykdymo. Į pagalbą ateina bash -c ar bet kokio kito shell’o komandų vykdymo programa. Štai kaip perkuriu statinį tinklaraščio turinį ir atnaujinu naršyklės langą kai rašau straipsnį: ls content/* | entr bash -c "pelican content; bash browser-refresh.bash Vykdome"

GIT PUSH komanda projektui atnaujinti

Nors dažniausiai savo projektus deployin’u Jenkins pagalba (kai sėkmingai pasileidžia visi testai ir linter’iai neaptinka klaidų), kartais leidžiu sau šiek tiek tingesnę darbo aplinką - deployment’ą tiesiai į produkcinį serverį. Vienas iš tokių projektų yra šis statinis tinklaraštis. Nors jame testuoti būtų ką, tačiau to daryti prasmės nėra. Todėl iškart parašęs straipsnį ar šiaip ką atnaujinęs sakau git push production ir GIT HOOK’ai pasirūpina visais kitais reikalingais dalykais. Taigi, šis straipsnis apie tai, kaip susikonfigūruoti tokią aplinką darbui. Pirmiausiai reikėtų suprasti kaip tai turėtų veikti. Savo darbo aplinkoje, kur dirbate, konfigūruoti praktiškai nieko nereikės. Užtenka turėti tik saugyklos ir produkcinio serverio remote įrašus. Pavyzdžiui tipiniai mano ‘remote’ yra: $ git remote -v origin saugykla.example.org:personal-projects/www.jarmalavicius.lt (fetch) origin saugykla.example.org:personal-projects/www.jarmalavicius.lt (push) production server.example.org:www.jarmalavicius.lt (fetch) production server.example.org:www.jarmalavicius.lt (push) staging staging.example.org:www.jarmalavicius.lt (fetch) staging staging.example.org:www.jarmalavicius.lt (push) Kaip iš pavadinimo turėtų būti aišku, kad origin saugykla saugoja privatų repozitorijos turinį (čia veikia prieigos teisės ir saugoma visa istorija tarsi centriniame repozitoriume), production yra ssh kelias iki projekto failų, staging yra testavimo versijos ssh kelias iki failų. Kaip prisidėti remote tikriausiai žinosite: git remote add origin saugykla.example.org:personal-projects/www.jarmalavicius.lt Taigi, susikonfigūravę teisingus remote sąrašus reikėtų eiti į serverius ir susikurti labai paprastą GIT HOOK’ą automatiniams atnaujinimams padaryti. Analizuokime šį užrašą iš git remove -v komandos: production server.example.org:www.jarmalavicius.lt (fetch) Keliaujame į server.example.org ir jame esantį namų katalogą www.jarmalavicius.lt. Susikurkime failą .git/hooks/post-receive su turiniu: #!/bin/sh cd .. git checkout -q -f master Ir, aišku, jam suteikiame vykdymo teises su chmod +x .git/hooks/post-receive. Toks kodo gabaliukas atrodo gana grubiai. Pirmoji eilutė cd .. yra naudojama todėl, kad git skripto vykdymo metu bus .git kataloge. Todėl jame būnant įvykdžius git checkout komandą gautume klaidos pranešimą: fatal: This operation must be run in a work tree. Taigi, teisingam keliui gauti arba naudojame cd .. arba git --work-tree=../ komandas. Tiesa, Jūsų .git katalogas nebūtinai privalo būti ten pat kur ir pats projektas guli. Jeigu taip nėra, tai reikėtų antrą eilutę pakeisti į git --work-tree=/kelias/iki/projekto. Kita eilutė git checkout -q -f master yra savaime suprantama. Čia reikėtų atkreipti dėmesį į kelis dalykus: -q tylusis režimas. Čia tam, kad po git push nematytume kas vyksta serveryje. Kadangi klaidos, jeigu jų būtų, būtų išvestos, tai nėra reikalo matyti „sėkmės pranešimų“. -f nurodo failų perrašymą net jeigu serveryje yra yra keistų failų. Gal toks režimas atrodo kiek agresyvus, bet patikėkite, išvengsite žymiai daugiau bėdų jeigu jį naudosite failų perrašymui, nei nenaudosite. Ir be to - neprofesionalu dirbti tiesiogiai produkciniame serveryje (tuo labiau ten palikti pakeistų failų). master nurodo kurį branch’ą naujinti. Čia galima rinktis branch’ą arba išvis jo nerašyti. Taigi, kai sekantį kartą kažką sukursite ir norėsite tuoj pat pamatyti pakeitimus produkciniame serveryje - galėsite pavykdyti komandą git push production ir vos po kelių sekundžių turėti pakeitimus. Tikriausiai patys turėtumėte įvertinti rizikas ir tokį dalyką naudoti labai protingai. Kitame straipsnyje aprašysiu kaip nustatyti pagal modifikuotą kodą: ar pavyzdžiui jūsų projektui reikia pavykdyti kažkokias migracijas (ar kitą verslo logiką); kaip apsisaugoti nuo kitų branchų kodo gavimo serveryje; kaip užtikrinti lengvą duomenų atstatymą jeigu kažkas įvyko blogai; kaip užtikrinti tam tikrą kokybės kontrolę ir užkirsti kelią atnaujinimams jeigu push’inamas kodas neatitinka kai kurių standartų.

VIM Plugged paketų valdiklis

Vargu ar šiais laikais kas nors programuoja „pliku“ VIM’u (arba vi) ir nesinaudoja jokiais įmantriais įskiepiais produktyviai darbo aplinkai sukurti. Dar prieš 3-5 metus, kai automatinių įskiepių tvarkyklių fronte buvo nematyti, teko visus įskiepius diegti ranka: dėti konfigūracijas atskirai į docs/, colors/, ftplugin/ ir t.t. direktorijas. Vėliau atsiradus keliems įrankiams išbandžiau VIM Pathogen. Nors tada, tai atrodė kaip patogesnis įrankis nei diegimas ranka, tačiau šiais laikais vargu ar būtų produktyvu tokiu įrankiu naudotis. VIM Pathogen įdiegimas nėra sudėtingas, tačiau palyginti su kitais įrankiais - reikalaujantis daugiau darbo. Jo diegimo instrukcija reikalauja indentavimo parinkčių (laikino) išjungimo - kas, iš praktikos pasakysiu, vėliau gali stipriai pagadinti kitus dalykus. Taip pat VIM Pathogen paketų diegimas vistiek vyksta rankiniu būdu - tenka „klonuoti“ projektus į specialią direktoriją, kad tai veiktų ir rūpintis rankiniu įskiepių atnaujinimu. Taigi, ieškom geresnių alternatyvų! Įrašius į Google „vim plugin manager“ rastume ne vieną įrankį. Populiariausias turbūt būtų Vundle. Peržiūrėjus jo README aprašymą nusprendžiau dar paieškoti ir sustojau su sekančiu sąraše - VIM Plug. Nieko ypatingo negaliu pasakyti, bet pasirinkau tik todėl, kad jo diegimo instrukcija ir priežiūros aprašymas buvo trumpiausi. Didelis privalumas yra jo įdiegimas. Viena komanda ir viskas: curl -fLo ~/.vim/autoload/plug.vim --create-dirs \ https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim Paketų valdymas ypatingai paprastas, vos trys eilutės kodo ir važiuojam! call plug#begin('~/.vim/plugged') Plug 'autorius-1/pavadinimas-1' Plug 'autorius-2/pavadinimas-2' call plug#end()<F37> Užrašas ‘autorius-1/pavadinimas-1’ nurodo, kad tokią repozitoriją „klonuos“ iš GitHub. Pavyzdžiui ‘ReekenX/vim-rename2’ reikštų repozitorijos vim-rename2 klonavimą. Žinoma, prievartos GitHub naudotis nėra - galite rašyti ir pilnus/kitus adresus. Taigi, susirašom įskiepius kuriuos naudosime. Puikų sąrašą galite rasti čia. Paleidžiame VIM’ą ir jame komandą :PlugInstall. Ir viskas - visi įskiepiai per kelias sekundes bus sudiegti. Pažiūrėkite oficialiame aprašyme diegimo paveiksliuką - atrodo tikrai įspūdingai! Didžiausi VIM Plug privalumai: Labai paprastas įdiegimas (vos kelios komandos). Lygiagretus komandų vykdymas leidžia greitai viską įdiegti. Įskiepius galima pakrauti esant poreikiui (žiūrėkit oficialią dokumentaciją). Komandos atnaujinimams, valymui, statusams ir pan.

Komandų lygiagretus paleidimas su GNU Parallel

Ypatingai dažnai tenka susidurti su komandų gausa kurios trunka ilgai, tačiau nėra galimybių išnaudoti kelių procesorių vienu metu. Į pagalbą kviečiam GNU Parallel kuris komandas padės paleisti lygiagrečiai. Nors oficialioje dokumentacijoje rasite gausybę panaudojimo pavyzdžių - praktikoje užteks greičiausiai žinoti tik kelis panaudojimo būdus. Pirmiausiai įdiekime GNU Parallel (Debian paremtose sistemose): apt-get install parallel Viena iš vykdymo sintaksių GNU Parallel yra gana neįprasta palyginus ką tenka matyti kitose komandose: parallel komanda ::: [argumentas1] [argumentas2] [..] Išsibandykime: parallel sleep ::: 3 2 4 Toks aprašas reikštų, kad vykdysime tokias komandas: sleep 3 sleep 2 sleep 4 Visas vykdymo laikas nuosekliai truktų 3 + 2 + 4 = 9 sekundes. Su GNU Parallel komandos būtų įvykdytos lygiagrečiai, taigi, užtruktų šiek tiek ilgiau nei 4 sekundes. GNU Parallel leidžia komandas apsirašyti ir ne su vienu argumentu. Tokiu atveju sintaksė būtų tokia: parallel komanda ::: argumentas1-1 argumentas1-2 ::: argumentas2-1 argumentas 2-2 [..] Pavyzdžiui: parallel echo ::: 0 1 ::: 0 1 Galima tikėtis, kad bus įvykdytos tokios komandos: echo 0 1 echo 0 1 Tačiau iš tikrųjų, GNU Parallel pavykdys komandas su argumentų kombinacijomis, taigi, išvesties rezultatas gausis toks: 0 0 0 1 1 0 1 1 Kitame straipsnyje parodysiu kaip vykdyti komandas iš tekstinio failo ir daugiau pavyzdžių iš tikro gyvenimo (prie kompiuterio) situacijų.

Laikinas pakeitimų ignoravimas su GIT

Baisu būna, kai atviro kodo projektai turi kažkokį konfigūracinį failą išsaugotą repozitorijoje ir kurį būtinai reikia pasikeisti pagal savo poreikius. Aišku, projektai tobulėja ir anksčiau ar vėliau atsiranda „lokalių konfigūracinių failų“ palaikymas. O ką daryti kai jų nėra? Paprasta - GIT leidžia mums laikinai ignoruoti failus ir paslėpti jų modifikacijas nuo git status ar git diff komandų. Tarkime modifikavome konfigūracijų failą config.py ir dabar jį matome įvykdę git status komandą: $ git status -sb master...origin/master MM config.py Ir žinoma situacija - mes nenorime šių pakeitimų commit’inti, nes tai gali būti laikinas duomenų bazės testavimas, laikinas debug režimo įjungimas ar pan. Taigi, praneškime GIT’ui, kad šio failo pakeitimus kol kas ignoruosime: git update-index --assume-unchanged config.py Ir dabar paklausus GIT pakeitimų gautume tokią išvestį: $ git status -sb master...origin/master Jokių pakeitimų. Nors mūsų pakeitimai tikrai egzistuoja tame faile. Jokios „magijos“ čia nėra. GIT’as savo pakeitimus įsirašo į savo lokalų index failą ir užkešuoja šias nuostatas. Vėliau, nusprendę atstatyti failą į originalų failą (pavyzdžiui po keleto komitų): git update-index --no-assume-unchanged config.py Reikėtų nepamiršti keleto dalykų: Toks sprendimas turėtų būti laikinas. Persijunginėjant tarp branch’ų toks sprendimas neveiks nes bus naujinamas index failas ir valomas kešas. Jūsų pakeitimai gali įtakoti programos rezultatą, tai yra tikimybė, kad susidursite su “o man tai veikia“ situacija. Ši komanda jau yra pravertusi ne vieną kartą programuojant, tikiuosi pagelbės ir Jums.

Tmuxinator aliasai / greitos darbų aplinkos

Ne taip seniai esu rašęs ciklą straipsnių apie tmuxinator, kurios dėka pasikartojančius darbus pasidarysite žymiai lengviau. Tai ne automatizavimo įrankis darbui, tai automatizavimo įrankis darbo aplinkai. Panaudojimo spektras gali būti tikrai gana platus: nuo darbo rašant kursinį, eksperimentuojant su operacine sistema iki rimto projektavimo ar programavimo. Kas dar neskaitė ankstesnių straipsnių serijos, patarčiau peržiūrėti, galbūt įrankis tikrai bus naudingas: Automatizuokite tmux su tmuxinator, 1 dalis Automatizuokite tmux su tmuxinator, 2 dalis Automatizuokite tmux su tmuxinator, 3 dalis Na, o šiandien trumpai apie tai, ko nepapasakojau pirmame straipsnyje - apie tai, kad tmuxinator turi aliasus, kurių dėka galima turėti universalias aplinkas. Anksčiau, tmuxinator konfigūracijas kurdavau konkrečiai projektams. Tuomet ir komanda būdavo: tmuxinator new PROJEKTO-VARDAS Šioje komandoje tmux buvo sukuriama sesija pavadinimu PROJEKTO-VARDAS. Tačiau kiekvienam projektui sukurti po konfigūracinį failą yra išties nemažai darbo. Tai ypač daug laiko reikalauja jeigu dirbi kokioje „svetainių kepykloje“ (įmonėje kurioje kas mėnesį ar dažniau tenka pabaigus vieną projektą pereiti prie kito). Taigi prieikime prie aliasų. Kaip ir anksčiau, susikurkime universalias aplinkas. Aš jas turiu maždaug tokias: aplinką PHP projektams, aplinką Django projektams, aplinką konkrečiam projektui - tinklaraščiui ir t.t. Visos aukščiau išvardintos aplinkos buvo sukurtos tmuxinator new APLINKOS-VARDAS komandos dėka. Taigi, pradedant dirbti prie kokio Django projekto, užtenka nueiti iki jo katalogo ir startuoti aplinką: cd /kelias/iki/projekto tmuxinator start django projekto-vardas Čia tmuxinator sukurs pagal django konfigūraciją tmux sesiją pavadinimu projekto-vardas. Labai paprasta, bet labai ir patogu. Trūksta idėjų? Github konfigūracijų yra daugybė.

Nepraleiskite pakeitimų su GIT RIBBON

Ir vėl grįžus iš atostogų tenka prisiminti prie ko dirbau, planuotis ką turėčiau daryti toliau ir sužiūrėti kas gero nutiko ankščiau. Laimei, kalbant ne apie įmonės viduje esančius dalykus, o apie programavimo kodą - tą padaryti nėra sunku. Tokiems kaip aš, kuriems smalsu kas per keletą atostogų savaičių pasikeitė, yra labai geras įrankis pavadinimu git ribbon. Jis iš esmės išsprendžia keletą problemų: Norą peržiūrėti pakeitimus eilės tvarka kaip jie buvo įgyvendinti. Norą „pasivyti“ kitus kolegas projekto tobulinime. Patogesnę peržiūrą nei, tarkime, git log komanda. Įdiegti nebus sunku: git clone https://github.com/kablamo/git-ribbon.git cd git-ribbon ln -s bin/git-ribbon /usr/local/bin/git-ribbon Ir toliau naudosimės tokiu formatu: git ribbon [KOMANDA] Veikimo principas paprastas - pasižymite vieną kartą vietą iki kurios žinote kas įvyko. Tą padaro komanda: git ribbon --save Tuomet parsisiunčiame pakeitimus: git pull Ir tikriname kas įvyko tame tarpe nuo pasižymėjimo iki dabartinių pakeitimų su: git ribbon Peržiūrėjus vėl pažymime, kad iki šios vietos viskas peržiūrėta: git ribbon --save Taigi, iš esmės grįžęs po atostogų, atlieku tokius veiksmus: git ribbon --save git up # arba git pull, kam patogiau git ribbon git ribbon --save Tiesa, praverstų susikonfigūruoti savo diff redaktorių, kad peržiūra nebūtų tokia sunki ir taupytų brangų laiką. Tai .gitconfig faile atrodytų taip: [diff] tool = vimdiff Daugiau visokių „tipsų“ galima būtų rasti mano asmeniniuose konfigūracijų failuose.

Ranka įdiegtų paketų sąrašo gavimas

Anksčiau, kai dar nenaudojau nei ansible nei salt automatizuotoms sistemoms kurti, dažnai įvairius dalykus tekdavo atlikti ranka. Vienas dažniausių veiksmų būdavo įdiegti programas kurias dažniausiai naudoju. Kam įdomu, mano dažniausiai naudojamų programų sąrašus galima rasti senesniuose straipsniuose: 2013 metų straipsnyje ir 2010 metų straipsnyje. Taigi, o kaip rasti įdiegtų programų sąrašą? Komanda dpkg -l čia nelabai padės, nes ji išves tokį ilgą sąrašą, su tiek daug bibliotekų, kad gali būti per sunku atsifiltruoti. Arba daug darbo. Laimei, Debian operacinės sistemos šeimose, tą gana nesunkiai galima pasidaryti su apt-mark komanda. Gaukime ranka įdiegtų programų sąrašą: apt-mark showmanual Rezultatas yra tik „dag maž“ ranka įdiegti failai. Šiame sąraše rasime ne vieną „priklausomą“ paketą, tuo pačiu ir bibliotekas (paketai prasidedantys arba turintys savyje anglišką žodį „lib“). Norint šį sąrašą patrumpinti, teks papildomų komandų: comm -23 <(apt-mark showmanual | sort -u) <(gzip -dc /var/log/installer/initial-status.gz | sed -n 's/^Package: //p' | sort -u) Iš pradžių gali pasirodyti kiek per sudėtinga, bet jeigu analizuotume kiekvieną komandą iš dešinės, viskas atrodytų labai paprasta. Taigi: gzip -dc /var/log/installer/initial-status.gz | sed -n 's/^Package: //p' | sort -u Išarchyvuoja failą /var/log/installer/initial-status.gz. Jame bus surašyta meta informacija tų paketų, kurie pateko diegiant operacinę sistemą. Su sed komanda išrenkame jų pavadinimų eilutes, tik prieš tai pašaliname tekstą „Package: “. Vėliau surūšiuojame abėcėlės tvarka (bus svarbu kiek vėliau). Antra komandos dalis yra: apt-mark showmanual | sort -u Kaip jau minėjau anksčiau - gauname ranka įdiegtų programų sąrašą ir vėlgi - išrikiuojame abėcėlės tvarka. Lieka paskutinė baisi dalis: comm -23 Kadangi jau iš praėjusių dviejų komandų turėsime du sąrašus - ką įdiegėme ranka ir kas jau buvo įdiegta su operacine sistema - beliko tik šiuos sąrašus sulyginti išrinkti tai, kas unikalu. Komanda comm skaičių argumentai mums duotų: -1 - neatvaizduoti pirmo sąrašo elementų -2 - neatvaizduoti antro sąrašo elementų -3 - neatvaizduoti tokių elementų, kurie pasikartoja sąrašuose Taigi, mūsų atveju mums nereikia matyti viso sąrašo kas buvo įdiegta startuojant operacinei sistemai (argumentas -2) ir to, kas tuose sąrašuose buvo vienoda (argumentas -3). Jeigu viską išsaugosite į failą, įdiegti bus labai paprasta: apt-get install $(cat ranka_idiegti_paketai.list) Prieš daugelį metų tokį komandų sąrašą galima buvo gauti tik su dpkg --get-selections komanda. Ši komanda veikia ir dabar. Kadangi ji grąžina sąrašą įdiegtų programų (nebūtinai rankiniu būdu), tad su keleta komandų galima būtų lygiai taip pat atsirinkti ranka įdiegtas programas. Tie, kas naudojasi grafine aplinka ir, pavyzdžiui, programa Synaptic, tai tokį sąrašą gali gauti ir be jokių komandų. Yra Debian, bet nėra apt-get? Ir nenorite jo įdiegti? Laimei, sąrašą nesunkiai susikursite su aptitude programa: aptitude search '?installed ?not(?automatic)' -F '%p' Komanda suras įdiegtas programas, kurios nebuvo įdiegtos automatiškai. Jeigu nepaduosite argumento -F (kaip parodžiau pavyzdyje) tai aptitude išves daug informacijos sąraše: paketų būsenas, pavadinimus ir aprašymus. Taigi ‘%p’ užtikrina tik paketų vardų išvedimą.

Kaip sužinoti turimo HDD disko būklę

Natūralu, kad nuolat dirbant kompiuteriu jo dalys po truputį dėvisi. Dauguma (jei ne visi) kompiuterio komponentai turi savo gyvenimo trukmę. Neseniai susidūriau su per stipriai sulėtėjusio disko bėda. Gal ir nieko keisto, nešiojami kompiuteriai, dažniausiai, turi žymiai lėtesnį kietąjį diską nei stacionarūs. Kalbu apie pasenusius HDD, ne greituosius SSD. Linux duoda keletą įrankių pasitikrinti savo HDD būklę. Galima įdiegti gsmartcontrol GUI programą ir greitai ir lengvai pasitikrinti diską. Nepatyrusiems šiuose dalykuose rekomenduočiau ją įsidiegti, nes jos išvestyje galėsite pamatyti ką reiškia kai kurie būsenų statusai. Ją įdiegti Debian sistemose galima šia komanda: apt-get install gsmartcontrol O neturint galimybių arba nenorint diegti GUI programos, užteks pasinaudoti smartctl komanda. Pavyzdžiui raskime pažeistus sektorius: smartctl -a /dev/sda smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.13.0-54-generic] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org [..] SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f Pre-fail Always - 1 3 Spin_Up_Time 0x0027 Pre-fail Always - 1958 4 Start_Stop_Count 0x0032 Old_age Always - 22190 5 Reallocated_Sector_Ct 0x0033 Pre-fail Always - 8 7 Seek_Error_Rate 0x002e Old_age Always - 0 9 Power_On_Hours 0x0032 Old_age Always - 19639 10 Spin_Retry_Count 0x0032 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 Old_age Always - 0 12 Power_Cycle_Count 0x0032 Old_age Always - 4934 191 G-Sense_Error_Rate 0x0032 Old_age Always - 12765 192 Power-Off_Retract_Count 0x0032 Old_age Always - 559 193 Load_Cycle_Count 0x0032 Old_age Always - 1486756 194 Temperature_Celsius 0x0022 Old_age Always - 38 196 Reallocated_Event_Count 0x0032 Old_age Always - 2 197 Current_Pending_Sector 0x0032 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 Old_age Offline - 0 240 Head_Flying_Hours 0x0032 Old_age Always - 18501 241 Total_LBAs_Written 0x0032 Old_age Always - 45449537240 242 Total_LBAs_Read 0x0032 Old_age Always - 57731698047 254 Free_Fall_Sensor 0x0032 Old_age Always - 0 [..] If Selective self-test is pending on power-up, resume after 0 minute delay. Išvestis gana didelė ir teks pasikonsultuoti su man smartctl arba tiesiog gsmartcontrol GUI programoje (joje ši informacija pateikta prie kiekvienos eilutės). Vienas svarbiausių punktų yra Reallocated_Sector_Ct kuris nusako kiek perskirstytų sektorių yra Jūsų diske. Kada diskas geros kokybės, šis skaičius turėtų būtų 0 (jokių pažeistų sektorių). Kai skaičius didesnis - blogai. Šis skaičius nereiškia, kad tai sugadinti fiziškai sektoriai, tačiau puikus požymis, kad kažkas gali būti blogai. Apie tai kaip surasti kaltininkus teks pasikonsultuoti su man smartctl arba laukti kitų straipsnių. Ši programa duoda ir daugiau galimybių, kaip pavyzdžiui HDD disko testavimą. Tačiau apie tai - kituose straipsniuose.

Komandų progresijos sekimas su pv komanda, II dalis

Praėjusiame straipsnyje papasakojau apie pv komandą ir parodžiau keletą jos panaudojimo būdų. Štai dar keletas pavyzdžių kaip naudoti komandą pv kasdieniniams darbams. Archyvuokime katalogą ir stebėkime jo progresą: $ tar cjf - katalogas | pv > archyvas.tar.bz2 3.55MB 0:00:02 [ 1.2MB/s] [ <=> ] Kaip pastebėsite, kad progresijos juosta nieko nerodys, tiesiog ves nuo vieno iki kito galo. Taip yra todėl, kad pv komanda nežino koks bus katalogo turinio dydis. Jį teks nurodyti atskira komanda, pavyzdžiui: $ tar -cf - katalogas | \ pv -s $(du -sb katalogas | awk '&#123;print $1&#125;') | \ bzip2 > archyvas.tar.bz2 1.39MB 0:00:03 [ 929kB/s] [==> ] 6% ETA 0:00:45 Šiame pavyzdyje mes komandai pv nurodome katalogo dydį kurį suskaičiuojame su kita bash komanda. Pavyzdyje tai yra du -sb some_directory | awk '&#123;print $1&#125;', kuri išves mums katalogo dydį baitais (-s argumentas sumai, -b argumentas išvedimui baitais). Aišku, taip rašyti komandas nėra labai patogu. Taigi, dažnai naudojant teks pasirašyti bash alias ar kokį bash skriptą. Dar vienas naudingas pavyzdys naudojantis komanda dd, kuri taip pat neturi jokių galimybių stebėti kiek darbo jau atlikta. Taigi, pasinaudojame pv: dd if=/mnt/mylargefile.img | pv | dd of=~/mycopy.img Priminsiu, kad vėlgi egzistuos bėda, kad pv komanda nežino tikslaus turinio dydžio, todėl reikės arba jį perduoti su pv -s arba apseiti be progresijos išvesties (naudingos informacijos gali ir taip pakakti, nes rodomas srauto greitis ir praėjęs laikas). Reikia failą perduoti vietiniame tinkle ir stebėti kaip vyksta darbas? Ne bėda. Štai kaip atrodytų siuntėjo komanda: cat backup.iso | pv -b | nc -l 3333 Štai kaip atrodytų gavėjo komanda: nc 192.168.0.1 3333 | pv -b > backup.iso Taip pat pv naudoju ir dump’inant duomenis iš duomenų bazių. Tiesa, tai ne visai lankstus dalykas dėl apribojimų kurie kliudo sužinoti siunčiamo srauto dydį. Bet užtenka žinoti apytikslį dydį, kad pateiktas rezultatas būtų tikrai geras: mysqldump -h produkcinis_serveris duombaze | pv -s 3g | mysql -h kitas_serveris duombaze Sužinoti kiek apytiksliai duomenų bazė užima vietos teks pasikreipti į oficialią dokumentaciją. Mysql variklyje galima: SELECT TABLE_NAME, table_rows, data_length, index_length, round(((data_length + index_length) / 1024 / 1024),2) "Size in MB" FROM information_schema.TABLES WHERE table_schema = "schema_name"; Komanda pv tikrai gali praversti tokiais atvejais kai svarbu (arba bent jau „būtų gerai“) žinoti kiek darbo komandai liko atlikti. Labai praverčia kai dirbama tiesiogiai su failais, nes nereikia rūpintis teisingu dydžiu nustatymu pv komandoje. Bet išsiaiškinus srauto dydį, nesunkiai komandą galima pritaikyti rodyti tikrai naudingą informaciją. Taip pat siūlyčiau pasižiūrėti aprašymo puslapį dėl komandos papildomų parinkčių ką rodyti, kaip rodyti ir ko nerodyti.

Komandų progresijos sekimas su pv komanda, I dalis

Tikriausiai ne vienam yra ne kartą tekę susidurti, kai vykdoma ilgos trukmės komanda ir sunku nuspėti apie jos vykdymo trukmę. Laimei, atviras kodas ir čia nepagailėjo įrankių. Vienas iš jų - pv komanda. Jos dėka savo vykdomose komandose galite stebėti tokią informaciją: Kiek laiko praėjo. Kiek procentų komandos jau įvykdyta. Komandos įvesties/išvesties greičius. Viso duomenų perduotų kiekis. Kiek laiko liko iki apytikslės pabaigos. Tiesa, ne visais atvejais visa informacija rodoma, bet ją galima atskirai išjungti / įjungti. Pradžiai įsidiegiame (Debian sistemose): sudo apt-get install pv Įdiegimo komanda Centos ir Fedora sistemose: yum install pv Trumpai apie komandų užrašymo formatą. Jis dažniausiai toks: pv [argumentai] duomenu_failas | kita-komanda Pavyzdžiui norime į serverį įkelti nemažą tekstinį failą. Šią užduotį naudosime kaip pavyzdį, nes tokius reikalus tikriausiai norėsime tvarkyti su rsync arba scp: pv /mano/didelis/failas | ssh example.org 'cat - > /dev/null' Ir matysime kažką panašaus: 335mB 0:00:11 [ 329kB/s] [================================>] 100% Bet toks komandos panaudojimas yra gana paprastas. Prisiminkime komandą tar kuri mums neduoda jokių parinkčių numatomam vykdymo laikui stebėti. Pamėginkime išarchyvuoti didelį failą: pv archyvas.tar.gz | tar xzf - -C /tmp Gausime išvestį: 12.5MB 0:00:00 [13.8MB/s] [===============================>] 100% Gali susidaryti įspūdis, kad pv komanda veiks tik tada, kai jai paduosime failą. Tačiau tai netiesa. Kitame straipsnyje parodysiu įdomesnių panaudojimo atvejų, ne tik su darbu su failais.

Postfix laiškų siuntimų statistika

Ėmė ir atsitiko, kad teko pasitikrinti ar kartais serveriuose nesiunčiamas šlamštas (angl. spam) ar kokie masiniai laiškų siuntimai (angl. bulk mailing). Žinoma, pirma mintis šovusi į galvą - paprasčiausiai patikrinti klaidų žurnalus serveryje. Tačiau juose tiek daug įrašų, kad rasti „kaltininkus“ gali būti sunku. Čia į pagalbą atskuba programinė įranga - pflogsumm. Įdiegiame (Debian sistemose): sudo apt-get install pflogsumm Įdiegiame (jeigu Red Hat sistemose): sudo yum install pflogsumm Ir be jokio konfigūravimo galime pasižiūrėti statistiką iš vieno failo: cat /var/log/mail.log | /usr/sbin/pflogsumm Ir gausime kažką panašaus: Grand Totals ------------ messages 45 received 43 delivered 0 forwarded 4 deferred (65 deferrals) 1 bounced 2 rejected (4%) 0 reject warnings 0 held 0 discarded (0%) 8361k bytes received 8355k bytes delivered 34 senders 22 sending hosts/domains 7 recipients 4 recipient hosts/domains [..] Statistikos gausite tikrai daug: kaip „sėkmingai“ vyko laiškų siuntimas ir gavimas, kokie domenai gavo daugiausiai laiškų, kokie el. pašto adresai jų gavo, dažniausi sistemų klaidų pranešimai (pvz. jeigu kokie laiškai buvo atmetami). Ir dar daugiau, sunku net išvardinti - pasižiūrėkite patys. Kadangi statistika išskirta grupėmis (įeinantys laiškai ir išeinantys laiškai) lengva bus rasti kaltininkus kurie galbūt siunčia per daug arba kai yra kas nors konfigūracijose blogai (pvz. ar smtp leidžia siųsti laiškus be autorizacijos - vis dar populiari tingių serverių administratorių klaida). O paranoja sergantiems tikriausiai pravers tokios statistikos siuntimas į paštą: cat /var/log/mail.log | /usr/sbin/pflogsumm | mail -s "Postfix statistika" vardenis@example.org Pavyzdžiui dienai baigiantis, crontab -e: 59 23 * * * cat /var/log/mail.log | /usr/sbin/pflogsumm | mail -s "Postfix statistika" vardenis@example.org

Duomenų šifravimas su ssh viešu raktu

Nesu GnuPG (dar žinomo kaip GPG) mylėtojas, todėl šiame straipsnyje greitai parodysiu kaip užšifruoti kažkokius duomenis turint (gavus) žmogaus viešą raktą. Viešasis ssh raktas, toks kaip manasis, kurį galite parsisiųsti iš Launchpad yra netinkamas openssl programai, todėl teks susigeneruoti atitinkamo formato raktą-sertifikatą. Tai galima padaryti su openssl komanda: openssl rsa -in ~/.ssh/id_rsa -out /tmp/viesas_raktas.pub -outform PEM -pubout Būsite paprašytas įvesti savo privataus rakto slaptažodį jeigu tokį turite. Mano sugeneruoto rakto turinys: -----BEGIN PUBLIC KEY----- MIICIDANBgkqhkiG9w0BAQEFAAOCAg0AMIICCAKCAgEAyul8GjRteUYK7fSqKYEI q1yQasYROEfqBe13gPmYiXscmduK/VqlMfyj39F+3r7MvMHsnA9TA03oJi521cjX bi8KeFYLmyzJr0zZrb/pUo1txzeEDP6nPG7pDen4lDX7Sgcn9t6aqfxG8XvZ58Ge /eAQw0Gxunz3Dw1/JrOXE4B0R2bKODBV4QFPZXUA+BZF5X5Lmc9JILHef25hvBQR rgpyKz6p5nvGyiBFX+KvWe8DFKtX9JkMG1toKYjHv/CycCCY7SJMDIigPZ5+EaRT HKyHl2i43uRdu89/2UD06+6dcLOAlThVnqghVKH+Empm3Ot349V9vhCiyAHFohHi OXmxLpsO2q5mY0ciiMEMTChSf3EnkFGi9OyhGf8by4EelSpg9S9X+wKdfe/Mq/jD FTCxl8I13O9u0zwxJtpsKAMnrxP8UT3zuIU83+YPPvTJqGxIqybgb8/aCnViaMi3 xXhnikiJ0U3V2GuJPHCv1BOSfx+Paa6V5tgk7bVkrwIA1fgTGweExDRudgCN/Vzp OiMYipvWu815tRc1x3ahZhLjBvMq/0z3iM5GBwRBE4j6GgBxxK+Ojf6+bXwdRF1K VS+FO5yyZG9SNfKkNHlZztQG+g3h6Uvxgl30U5eZrHAcgYncOYaMXG4PWLehLQBR XM8hX01gV+tv8SChFxIfmNMCASM= -----END PUBLIC KEY----- O dabar, imkimės šifravimo darbų! Pradžiai turėkime ką užkoduoti. Tam galime panaudoti kokį nors jau seniai turimą failą. Kaip pavyzdį tokį galime lengvai susikurti: echo 'Mano slapta žinutė čia.' > /tmp/failas.txt Ir užkoduokime žinutę: openssl rsautl -encrypt -inkey /tmp/viesas_raktas.pub -pubin -in /tmp/failas.txt -out /tmp/uzkoduotas_failas Programa openssl sukurs užkoduotą failą /tmp/uzkoduotas_failas kurį galima bus atsikoduoti tik turint privatų raktą (tokį, kurį turite tik Jūs). Tą galima pasidaryti taip: openssl rsautl -decrypt -inkey ~/.ssh/id_rsa -in /tmp/uzkoduotas_failas -out /tmp/atkoduotas_failas Dešifravimui būsite paprašytas įvesti savo privataus rakto slaptažodį jeigu tokį turite. Atspausdinkime atkoduoto failo turinį: cat /tmp/atkoduotas_failas Ir gausime: Mano slapta žinutė čia. Tikrai paprasta, greita ir sakyčiau patogu!

Python debugerio PDB autocompletion

Sunkiai savo programavimą Python kalba įsivaizduočiau be seno gero pdb, kaip ir PHP kalboje be xdebug. Daug laiko susitaupo kai komplikuotą kodo vietą galima taip sakant „padebuginti“. Tiesa, kiek teko pastebėti, tai daug kas nežino, jog šis įrankis gali ištiesti dar ir papildomą pagalbos ranką leisdamas panaudoti tabuliacijos simbolį „autocompletionui“. Įjungti šią galimybę galima įrašius į failą ~/.pdbrc tokį turinį: import rlcompleter pdb.Pdb.complete=rlcompleter.Completer(locals()).complete Šį modulį rasite tiek Python 2, tiek Python 3 versijose. Ir viskas! Aišku, jeigu tenka labai daug „debugintis“, tai galbūt verta pagalvoti apie kažką panašaus kaip pudb modulį?

Instapaper pakeitimas į Google... naršyklę!

Du metus buvau Instapaper „klientas“. Patiko paslauga, kurios dėka galima susikelti įvairius internetinius straipsnius į archyvą ir juos vėliau perskaityti turint laisvą minutę arba prie kavos. Tačiau Instapaper pakeitus dizainą atsirado didelių problemų naudojantis kitais įrenginiais (ne kompiuteriu). Pavyzdžiui, viena iš jų buvo negalėjimas ištrinti straipsnių naudojantis planšete. Paieškojus šiai paslaugai alternatyvų - jų yra ne viena. Pavyzdžiui Pocket, Evernote Clearly ar ReadKitApp. Tikriausiai daugiau paieškojus jų rastumėte ir daugiau. Ir ne taip ir seniai atradau, kad Google naršyklės (konkrečiai Chrome) duomenis sinchronizuoja tarp įrenginių. Užtenka susikurti „bookmarkuose“ katalogą nuorodoms kurias norite skaityti vėliau. Ir radus, ką norėsite išsisaugoti vėlesniam skaitymui, užteks nutempti iš adresų juostos nurodą į sukurtą katalogą. Ir šitas katalogas, pakeitus įrenginį bus iškart matomas! Taigi, ištryniau Instapaper paskyrą ir perėjau prie šio varianto. Juo jau naudojuosi daugiau nei pusę metų. Tikiuosi kam nors pravers (jeigu teko susidurti su šia problema). Žinoma, Firefox mylėtojams šis dalykas netiks, bet ir jiems tokia galimybė atsiveria pasinaudojus įvairiais papildiniais. Apie tai galima perskaityti oficialiame Mozilla puslapyje.

Weechat - puiki alternatyva irssi, 1 dalis

Irssi naudojau ne vienus metus, bet vien tik todėl, kad anksčiau nesugebėjau surasti geresnių, terminale veikiančių, alternatyvų. Trumpai apie tai ką gali/turi atviro kodo IRC klientas irssi: Automatinį prisijungimą prie kanalų. Automatines komandas po prisijungimo (naudinga norint prisijungti prie registruotų kanalų). Žinučių ir kitokių tekstų formatavimus. Perl skriptų palaikymą. Langų skaldymą. Irssi turi didžiulę išvaizdų bazę. Vienas pavyzdžių, demonstruojantis irssi galimybes formatuoti išvestį: Galimybių tikrai daug. Ypač gerai, kad irssi turi labai didelį įskiepių sąrašą. Kam tada ieškoti kitos alternatyvos? Praleidę ne vienus metus prie irssi pastebėsite, kad įskiepius nors rašyti nesunku, bet testuoti juos ar padaryti minimalias korekcijas kartais būna per didelis vargas. API visai nėra tokia lengvai perprantama ir naudojama, kaip dokumentacijose galima perskaityti. Vienos problemos kurios nesugebėjau niekada sutvarkyti: prisijungimas prie kanalų eilės tvarka. Nors ir nurodydavau eilės tvarką, net sudėjau pauzes, bet vistiek: irssi kanalus rasdavau išmėtytus atsitiktine tvarka. Irssi konfigūracijų - reikia ieškoti. Jeigu galvojat, kad po įdiegimo rasite kažkokius failus, kurie padėtų susikonfigūruoti prisijungimą prie populiariausių IRC serverių (pavyzdžiui freenode), tai deja - teks naudoti Google, teks eksperimentuoti. O jeigu reikės susikonfigūruoti SSL prisijungimus (juk būtina!), tai… Sėkmės! :) Ir pats baisiausias dalykas yra nuotoliniai pranešimai. Mėgstu IRC pasileisti serveryje ir laikyti, tam, kad visada galėčiau pasiskaityti kas įvyko. Taip pat, gerai, kai darbo metu ekrane iššoka pranešimas, kai kas pamini mano vardą. Išbandžiau tikrai ne vieną populiarų sprendimą, bet nei vieno neradau tokio, kuris po 4-6 dienų veikimo dar veiktų. Kol kas tiek gero ir blogo apie irssi. Kitame straipsnyje papasakosiu apie weechat ir kodėl jis gali būti geresnis/produktyvesnis IRC klientas.

Weechat - puiki alternatyva irssi, 2 dalis

Praėjusiame straipsnyje paminėjau, kad irssi IRC klientą naudojau ne vienus metus kol nusprendžiau jį pakeisti. Pratęsiant praėjusį straipsnį papasakosiu apie weechat. Nors irssi įdiegus gausite nemažai privalumų ir trūkumų (apie juos skaitykite praėjusiame straipsnyje), weechat „ateina“ su pataisymų krūva. Didžiausi privalumai: Galimybė rašyti skriptus/įskiepius daugybe programavimo kalbų. Palaiko ne vien tik IRC protokolą. Gerai dokumentuota (kaip irssi). Tačiau didžiausi privalumai buvo tokie, kad dokumentacijoje susiradęs freenode konfigūraciją iškart galėjau viskuo naudotis. Be jokių įskiepių jau turėjau spalvotus vardus, šoniniame meniu mačiau žmonių kurie prisijungę prie chat’o. Labai patogi apatinė informacinė juosta (angl. „status bar“), kurioje pagaliau galima suprasti kiek yra JOIN/QUIT žinučių, o kiek tikrų. Apačioje matėsi kanalo, kur esu prisijungęs, pavadinimas. Taip pat ir laikrodis buvo apatinėje juostoje. Sakysite - jis niekam nereikalingas? Jeigu naudosite irssi ar weechat per ssh, pamatysite, kad dažnai po tam tikro laiko pasibaigia sesija ir būsite atjungtas. Taip yra todėl, kad ssh pamačiusi, jog nėra jokio tarpininkavimo protokole, atjungia jį. Laikrodis būtinas, kad ssh „manytų“, jog komunikacija vyksta. Viena maloni smulkmena - sulygiuoti vardai. Aišku, visi aprašyti privalumai gali būti pasiekti ir irssi, bet tik per papildomus įskiepius. Realiai weechat gaunate „out of the box“ klientą kuris iškart bus patogus naudoti. Nuotoliniams pranešimams yra ne vienas sprendimas. Pats asmeniškai naudoju tobulintą kažkieno parašytą versiją, kurią galite rasti Github paskyroje. Oficialioje weechat svetainėje galite rasti labai puikią dokumentaciją, o nuotraukas kaip gali atrodyti Jūsų weechat galite rasti kūrėjų nuotraukų puslapyje.

Automatizuokite tmux su tmuxinator, 2 dalis

Praėjusiame straipsnyje trumpai pristačiau tmuxinator ir parodžiau kaip susikurti mažą projektą. Šiandien aprašysiu galimas tmuxinator komandas ir parodysiu kaip vienas langas gali pavykdyti ne vieną bash komandą. Pirmiausiai dirbant su tmuxinator pilnai užteks dviejų komandų kurias aprašiau anksčiau: new ir start. Nes visa kita susiję su redaguojamu failu, kurį galite tiesiog valdyti per savo teksto redaktorių. Programa tmuxinator visas konfigūracijas išsaugo ~/.tmuxinator/ kataloge. Trumpai apie tmuxinator komandas: $ tmuxinator copy SENAS-PROJEKTAS NAUJAS-PROJEKTAS Nukopijuoja projekto failą į kitą vardą. Tą galite padaryti tiesiog ~/.tmuxinator kataloge. $ tmuxinator debug PROJEKTAS Kai kuriate langus su sudėtingomis komandomis tai naudinga pažiūrėti ką ir kaip tmuxinator vykdo. Pavyzdžiui labai naudinga gali būti, kada bandote vieną langą suskaldyti į kelias dalis. $ tmuxinator doctor Tiesiog patikrina Jūsų konfigūracijų sintaksę. $ tmuxinator help KOMANDA Duoda daugiau informacijos apie aukščiau aprašytas komandas. $ tmuxinator implode Ištrina projektus. Nenaudokit geriau ;) $ tmuxinator list Išveda į ekraną visą sąrašą projektų kuriuos galite paleisti. $ tmuxinator new PROJEKTAS Sukuria naują projektą. Realiai tai YAML failas ~/.tmuxinator kataloge. $ tmuxinator start PROJEKTAS Paleidžia projektą. Atsidarys tmux su jame užregistruotomis sesijomis ir langais. $ tmuxinator version Leidžia pažiūrėti kokią versiją naudojate. Rašant straipsnį buvo 0.6.6 (įvertinčiau kaip stabilią). Taigi, jau turėtų būti aišku, kad tmuxinator realiai sukuria kažkokį YAML failą, kurį laiko ~/.tmuxinator kataloge, ir pagal kurį kuria sesijas ir jose langus. Tai sutaupo daug laiko kai reikia sukurti ne vieną sesiją ir/ar ne vieną langą. Ypatingai programuotojams dirbantiems visą laiką ne prie vieno projekto - labai naudinga ir produktyvu. O dabar trumpai apie kelių komandų paleidimą viename lange. Naudokite tokią YAML sintaksę: windows: - lango-vardas: panes: - skydelio-pavadinimas: - komanda 1 - komanda 2 - komanda 3 - kitas-skydelis - komanda 1 - komanda 2 Kaip minėjau, langus dažnai perskeliu į kelis skydelius. Didžiausias skydelis būna redaktoriaus VIM, tuomet apačioje vienas langas web-servisui ir dar vienas nedidelis langas visokioms su projektu susijusioms bash komandoms vykdyti. Šiuo atveju tmuxinator suskaldys langą proporcingai (du langus po 50%, jeigu langai trys, tai po 33% ir t.t.). Klaviatūros pagalba galima lengvai perstumdyti langų dydžius. Bet pala! Mes juk siekiame automatizuoto proceso! Tai taip, su tmuxinator galima ir tai. Galima nustatyti langų išsidėstymą, jų dydžius ir aukščius. Būtent taip ir esu pasidaręs priklausomai nuo to ko reikia konkrečiam langui. Bet apie tai - kitame straipsnyje.

Automatizuokite tmux su tmuxinator, 1 dalis

Screen? Oi, tikrai ne. Nors, serveriuose, kur galbūt neturiu root ir negaliu įsidiegti, tai taip. Bet visais kitais atvejais - tmux. Kuom gi jis geresnis: Leidžia keliems klientams prisijungti prie vienos sesijos. Visai neblogai aprašytos konfigūracijos. Labai patogi teksto kopijavimo iš terminalo paslauga. Ypatingai lengvai galima keisti langų dydžius ir vietas. Statuso eilutė be jokių konfigūracijų! Tiesa, screen turi savų privalumų, kurių niekada neteko panaudoti dėl technologijų senumo: visokie telnet ir serial palaikymai. Kam dar jų gali reikėti? Kaip ten bebūtų, įdiegti tmux ir screen yra paprasta (apie tai rašyti tikriausiai neverta). Aš dažniausiai naudoju tokį darbo modelį: Turiu vieną sesiją su keliais langais kurią vadinu „kompiuteris“. Tai vienas root langas, finansų apskaita, laiko apskaita, muzika. Kiekvienam klientui skiriu po vieną sesiją su X kiekiu langų. Vienas langas = vienas projektas. Ir tas langas dažnai perskeltas į bent dvi dalis. Viena sesija su IRC langu. Pati sesija kitame terminale rodoma, nes ją noriu matyti kitame ekrano lange. Taigi, gaunasi ~5 sesijos su daugiau nei 30 langų jose. Kiekis gal ir nėra didelis, bet kai įjungus kompiuterį tenka viską pasileisti, tai… Erzina. Bet jau prieš daugiau nei pusmetį suradau tikrai vertą dėmesio programą pavadinimu tmuxinator. Ji leidžia automatiškai sukurti sesijas su langais. Tai vyksta per konfigūracijų failus. Sukurti naują failą galime su komanda: tmuxinator new PROJEKTO-VARDAS Atsidarys YAML failo redagavimo langas, kuriame turėsite aprašyti kaip vadinsis sesija ir ką konkreti sesija turėtų paleisti (tokius langus su kokiomis komandomis). Pavyzdžiui štai kaip atrodo mano pirmoji aprašyta sesija: name: computer windows: - root: su - root - mc: mc - earnings: time watch -n 5 nice -n19 earned-history.awk - finances: watch -n 5 finances.bash - music: ncmpcpp Sintaksė velniškai paprasta: vienas windows elementas laiko savyje bash komandą. Susikūrus reikiamus tmuxinator projektus bet kada galime juos paleisti: tmuxinator start computer Pradžiai tiek. Kitame straipsnyje aprašysiu kaip vienas langas gali pavykdyti kelias komandas. Programa tmuxinator labai paprasta, bet galimybės tikrai stebina!

Automatizuokite tmux su tmuxinator, 3 dalis

Jeigu šiek tiek primiršote ar neskaitėte praėjusių straipsnių, tai trumpai paminėsiu, kad pasakojau apie tmux programą, kuri iš esmės yra geresnė screen alternatyvą - automatizavimą. Kodėl geresnė nei screen? Siūlau pasiskaityti pirmame straipsnyje. O antrame straipsnyje pasakojau, kad tmuxinator gali atlikti ne vieną komandą kažkuriam langui, bet kelias. Kas dar gerai, kad iš esmės į langus siunčiamos ne komandos, o klavišų paspaudimai. Taigi, dabar magijos gali būti dar daugiau! Šiame straipsnyje papasakosiu apie labai naudingą dalyką - automatinį langų skaldymą. Standartiškai tokia konfigūracijos sintaksė: windows: - lango-vardas: panes: - skydelio-pavadinimas: - komanda 1 - komanda 2 - komanda 3 - kitas-skydelis - komanda 1 - komanda 2 Suskaldo langą į dvi lygias dalis. Pagal nutylėjimą skaldymas įvyks per lango aukštį. Dar vienas skydelis įrašytas žemiau suskaldytų langą į tris dalis. Tai tikrai patogu, jeigu patinka toks išdėstymas. Dirbdamas su Django langą dalinu taip: 80% lango VIM redaktoriui, o apačioje du langai python manage.py runserver ir dar vienas langas kokiems nors sass ar TODO sąrašui skaityti. Išbandykit, tikrai patogu! Deja, bet tmuxinator nėra labai draugiškas langų skaldymui. Ši galimybė realiai egzistuoja tik neapsikentusių naudotojų dėka (kaip supratot - per „hack’us“). Pirmiausiai teks atsidaryti tuščią tmux langą ir susiskaldyti į taip kaip Jūs norite. Sukurti skydeliai gali būti tušti, mums aktualus tik skydelių dydis. Lango skydelių dydį galite sužinoti komandos pagalba: $ tmux list-windows Gausite kažką panašaus į: 0: blog* (3 panes) [175x53] [layout 6535,175x53,0,0[175x43,0,0,8,175x9,0,44&#123;65x9,0,44,14,109x9,66,44,15&#125;]] @6 (active) Iš šio painaus užrašo mums reikalinga tik layout dalis. Ją nukopijuosime į savo lango konfigūracijos YAML dalį: windows: - lango-vardas: layout: 6535,175x53,0,0[175x43,0,0,8,175x9,0,44&#123;65x9,0,44,14,109x9,66,44,15&#125;] panes: - skydelio-pavadinimas: komanda - kitas-skydelis: komanda - trecias-skydelis: komanda Viską sukonfigūravus galime leisti savo automatizuotą kūrimą: $ tuxinator start projekto-vardas Iš patirties galiu pasakyti, kad sugaištas laikas su tmuxinator atsiperka labai greitai, jeigu dažnai programuojate tą patį. Ypatingai kai kalbame apie programavimą, tai laiko sutaupyti galima labai daug: Galima pasiruošti greitai sluoksnius su kuriais patogu dirbti prie vienų projektų, kitus prie kitų. Galima paleisti projektui startuoti reikalingas komandas. Galima atsinaujinti projektą prieš pradedant su juo dirbti. Na, o jeigu yra kažkokių klausimų, galbūt padėčiau atsakyti. Tai paskutinis straipsnis apie tmuxinator. Projekto kodą galima rasti Github, o dokumentacijos dar teks palaukti ;)

Priežiūros režimo efektyvus įjungimas svetainėse

Jeigu programuojate interneto svetaines turbūt ne kartą tekdavo atnaujinimo darbus atlikti klientų darbo metu. Ir atnaujinimai ne visada tokie jau „nepastebimi“ kaip mes bandome padaryti… Ypatingai gerai, kad galite savo klientams pasakyti, kad kelioms minutėms kažkas neveiks. Jeigu to nedarote, pagalvokite, ar tikrai gerai atrodo, kai bandote „tyliai“ ir nepastebimai atlikti visus atnaujinimo darbus, bet susimaunate? Todėl mokėti teisingai/greitai/produktyviai įjungti priežiūros režimą („maintenance mode“ - angl.) yra tikrai didelis profesinis privalumas. Tiesa, tą padaryti yra tikrai ne vienas būdas. 1. Framework’ų siūlomi sprendimai Tokie framework’ai kaip Django ar Symfony (ar daugelis kitų) jau pasiruošę priežiūros būsenai: jie turi tam tikrus modulius ar nustatymuose specialias reikšmes šiam režimui įjungti. Deja, tokie sprendimai turi tokius trūkumus: Reikia keisti nustatymuose reikšmes. Python atveju reikia perkrauti web servisų konfigūracijas. Ir vistiek ne pats greičiausias sprendimas. Kaip tą padaryti? Galite paieškoti Google prie savo framework’o pavadinimo prirašę „maintenance mode“. Štai keli atsitiktinių framework’ų pavyzdžiai: django-maintenancemode (pirmiausiai reikia susikonfigūruoti prieš naudojant) Prestashop atveju tą reikia padaryti per web administraciją. 2. Apache ir mod_rewrite Vienas iš dažniausiai pasitaikančių sprendimo būdų yra perrašyti Apache VirtualHost direktyvą, kuri turėtų kitą DocumentRoot kuriame būtų koks nors index.html failas su priežiūros pranešimu. Tačiau tai turi keletą minusų: Reikia atkomentuoti/užkomentuoti jau parašytą Apache konfigūraciją. Būtina patikrinti apache su apache2ctl -t, kad neatsitiktų taip, kad perkrovimo metu niekas nepasileistų dėl klaidos. Reikia greičiausiai root teisių. 3. Efektyvus ir greitas apache ir mod__rewrite būdas Efektyviausias (turbūt) būdas panaudoti tokią VirtualHost konfigūraciją, kuri priežiūros režimą („maintenance mode“ angl.) įjungtų tik esant maintenance-on failui. Jį pašalinus, apache šio režimo nepaisys. Kodas: <IfModule mod_rewrite.c> RewriteEngine On RewriteCond %&#123;DOCUMENT_ROOT&#125;/maintenance-on -f #RewriteCond %&#123;REMOTE_ADDR&#125; !^TAVO.IP.ADRESAS.CIA$ RewriteRule !^down-for-maintenance/.*$ /down-for-maintenance/ [R,L] </IfModule> Tikrinimai su IfModule reikalingi jeigu kartais darote kažkokius atnaujinimus web servisų programinėje įrangoje ir yra galimybė sugadinti/nepaleisti mod_rewrite modulio. Taigi šiomis eilutėmis apsidraudžiate, kad apache vistiek startuotų: blogai galėtų veikti tik viena svetainė (ši), bet ne visos kitos tame serveryje. Kodas išties paprastas. Eilės tvarka daromi tokie tikrinimai: JEIGU egzistuoja maintenance-on failas; IR JEIGU IP adresas nėra toks kaip nurodytas (galite išvardinti kelias eilutes su skirtingais IP); IR JEIGU klientas dar nėra atidaręs naršyklėje tokio adreso; Nukreipk jį į priežiūros režimo puslapį. Įjungiam priežiūros režimą: cd /kelias/iki/docroot touch maintenance-on Išjungiam priežiūros režimą: rm maintenance-on Na, o sukurtame index faile kataloge down-for-maintenance galite parašyti pranešimą ir pranešti kiek truks atnaujinimai, kokie atnaujinimai daromi ir pan. Akivaizdu, jog tą reikėtų padaryti dar prieš įjungiant aptarnavimo režimą. O vėliau, kai viską ištestuosite, galima tiesiog įdėti kokį JavaScript nukreipimą į svetainę ir tiek (fantazijos dalykas). 4. Bendrai Kaip ten bebūtų, priežiūros režimas visada nėra geras sprendimas: Prarandate lankytojų srautą tam tikrą laiką… Klientai gali pildyti formas ir… Bus nukreipti į priežiūros režimą - nebus išsaugotos jų pildytos formos. Kalbant apie visokias užsakymų sistemas, kur dirbama su pinigais - visokius aptarnavimo režimus sunku toleruoti klientams. Bet pagalvokite, kas geriau: suklysti darant atnaujinimus ar pranešti klientams iš anksto ko tikėtis? Tiesa, labai dažni pranešimai tikrai galėtų erzinti. Greičiausiai idealiausias būdas būtų „load balancing“. Nors tema jau už paprastų web-projektų ribų, dažniausiai. Arba bent jau ne svetainėms, kurios turi tik FTP valdymą.

Kodo formatavimo įrankiai internete

VIM redaktoriaus kodo formatavimo galimybė tikrai niekam tikusi. Retai veikia taip, kad galima būtų suformatuotą kodą išsaugoti. Dėl to esant reikalui visada bėgu į internetą ir suformatuoju kokį kodo gabalą ar visą failą nemokamais įrankiais. Tiesa, dar tų įrankių, gerų, kartais paieškoti reikia. Bet, atsirinkęs nusprendžiau pasidalinti, tikrai išbandytais įrankiais: HTML kodo formatavimas. SQL kodo formatavimas. CSS kodo formatavimas. PHP kodo formatavimas. Python kodo formatavimas. Vienas universalesnių, bet nebūtinai geresnių, tinka PHP, Java, C++, C, Perl, JavaScript, CSS kalboms, bet - būtina susikonfigūruoti yra prettyprinter.de. Aišku, galima susirasti komandinės eilutės įrankių kurie atliktų tą patį darbą. Vienas iš pavyzdžių Python kalbai būtų autopep8 įrankis. Tačiau surasti įrankius, įdiegti ir išmokti jais naudotis - užima laiko. O pasinaudoti Web įrankiais galima per kelias sekundes. Žinote daugiau/geriau?

Knyga „Practical VIM“ - 10 balų!

Seniai seniai užmatęs Povilo Balzaravičiaus (dabar neveikianti nuoroda http://pawka.linija.net/) straipsnį „Kodėl neįveikiau 2013-ųjų knygų iššūkio ir tuo esu patenkintas“ nusprendžiau perskaityti ten paminėtą ir išgirtą knygą apie VIM’ą. Vadinasi „Practical VIM“ (parašė Drew Neil). Dešimt balų, tikrai! Esu jau VIM naudotojas N metų ir nors labai labai retai apie VIM parašydavau, bet po šios knygos nusprendžiau - neverta. Viskas, ko kada nors gali reikėti, ir ką galima padaryti su VIM, aprašyta 411 knygos puslapiuose. Savo žinių bagažą tikrai padidinau, nors ir galvojau, kad apie VIM žinojau tikrai daug. Taigi, jeigu naudojate VIM, tikrai rekomenduočiau perskaityti nepriklausomai nuo Jūsų lygio. Joje rasite: Patarimus kaip atsikratyti bjaurių rodyklių naudojimo. Kelis įskiepių aprašymus - privalote turėti. Daug daug daug pavyzdžių optimaliam darbui. Šimtus naudingų patarimų.

PDF, DOC, ODT, HTML ir kitų dokumentų konvertavimas

Visai neseniai teko konvertuoti didžiulę DOC failų bazę į PDF formatą. Laimei komandinės eilutės įrankiai jau seniai tam sukurti, todėl neteko atidarinėti kiekvieno failo ir išsaugoti. Tie, kas turi įdiegę LibreOffice, gauna ir įrankį kuriuo komandinėje eilutėje gali konvertuoti failų tipus - lowriter. Paprasčiausias būdas konvertuoti daug failų į PDF formatą: lowriter --nologo --convert-to pdf *.doc OpenOffice taip pat turi šią galimybę, tiesa komanda šiek tiek skiriasi: oowriter -t pdf *.doc Taigi pasinaudoję komandomis aukščiau galite lengvai konvertuoti populiariausius formatus kuriuos palaiko LibreOffice: odt, doc, pdf ir net html. Formatų yra kiek daugiau nei aš aprašiau. Paprasčiausias būdas juos visus susirasti - pažiūrėti GUI aplikacijos išsaugojimo lange, nes savo dokumentacijose LibreOffice to neaprašo. Dar vienas įrankis, kurį galite įsidiegti atskirai, tačiau jis taip pat yra LibreOffice dalis - pavadinimu unoconv. Jo pagalba galite daryti tą patį: unoconv -fpdf *.doc Daugiau šių komandų argumentų neminėsiu, nes jie - nesusiję su pačiu konvertavimo procesu (daugiausiai tai GUI nustatymai). Tačiau apie visus argumentus ir jų reikšmes galite pasiskaityti komandų pagalbos išvestyse: lowriter -h oowriter -h unoconv -h Reikėtų paminėti, kad nereikėtų 100% pasikliauti uždaro kodo formatų konvertavimu į atviro kodo. Pavyzdžiui konvertuojant iš doc į odt vaizdas gali atrodo kiek kitaip nei originaliame faile. Bet, kiek turėjau praktikos, veikdavo tikrai gerai. Nereikėtų naudotis įrankiais kurie konvertavimą atlieką netikru spausdinimo būdu. Tai yra kai konvertuojant failą iškviečiamas spausdinimo langas ir spausdinama į netikrą spausdintuvą, kuris atlieka konvertavimo darbus. Tokiu būdu prarasite meta duomenis failų. Tokius kaip autorystę, antraštes ir kita.

Mano Raspberry Pi - jau metai!

Raspberry PI kompiuterį, B versijos, gavau prieš metus laiko (2013 metais, sausį). Tai buvo labai puiki, mano įmonės, kurioje dirbu, dovana. Tiesa, tada nuspręsti kam jį panaudosiu buvo ypatingai sunku. Nors, aišku, internete tai tikrai pilna straipsnių apie panaudojimą. Ir kai kiti kolegos gavo šią dovaną, tai girdėjau pačius populiariausius panaudojimus: daryti NAS serverį failams talpinti, senų žaidimų konsolę arba media centrą. Žodžiu, nieko originalaus. Bet aš išbandžiau ir tai! Taigi, mąstote pirkti bet pirmiau norite gauti šiek tiek atsiliepimo ir apžvalgos? Skaitom! 1. Populiariausi projektai Pasidaryti NAS serverį nėra sunku. Tiesa, mane tai žudo kariavimas su Samba, bet iš esmės, tai per kelias valandas prijungus kokią talpyklą (HDD išorinį) galėsite failais keistis ne tik vidiniame, bet ir išoriniame tinkle. Išoriniam tinklui labai puikiai veikia OwnCloud programa. Media centras vienas populiariausių projektų internete. Aš buvau nustebintas labai paprastu įdiegimu. Media centro programinei įrangai naudojau XMBC. Tiesa užtruko kelias valandas, juk tai Raspberry Pi! Dar labiau buvau nustebintas, kai jis neužlūžo žiūrint beveik 8GB filmą ant didelio ekrano. HD kokybė tikrai puiki, persukti filmą ar atsukti/pakeisti - tikrai nesudaro jokių problemų. Plius, dar įsirašius programą telefone, labai lengvai galima buvo media centrą valdyti tiesiog telefone. Tiesa, norint turėti Media centrą teks įsigyti keletą daiktų, o tai - papildomos lėšos. Savaime suprantama, kad reikalingas monitorius, HDMI kabelis, kolonėlės ir LAN laidas arba WiFi adapteris. Jeigu tokią įrangą reikia įsigyti, tai jau nemažai išlaidų. Bet, manau, kad tai mano sekantis pirkinys. Turiu omeny, kad planuoju įsigyti dar vieną Raspberry PI būtent šiam tikslui. 2. GPIO PI turi dar tokius antgalius su kuriais gali daryti elektronines magijas. Pavyzdžiui kokius valdiklius. Tiesa, susipirkti visokius lituoklius, laidus, rezistorius, kondensatorius ir visa kita, tai kainavo. Bet šiaip, smagu, kad gali valdyti elektros energiją, žiūrėti rezultatus ir taip domėtis elektronika. Tikrai daug apie tai sužinojau Raspberry PI dėka. Perspėsiu, kad tie kas užsiima elektronika ir bando GPIO, tai persiskaitykit kurių išeinančių jungčių geriau nesuliesti, kad PI nesudegtų. Google apie tai tikrai daug aprašyta. Gaila žmonių, kurie tą patyrė. 3. Kam aš dabar naudoju Raspberry PI? Taigi, praėjus metams, mano Raspberry labiau tapo barbe-devindarbe. Pirmiausiai, tai Raspberry Pi filmuoja butą motion programos dėka. Ji vaizdą saugo tada, kai kažkas pradeda judėti. Paprasta USB kamera prijungta prie Raspberry PI. Vaizdą realiu laiku galiu visada pažiūrėti per internetą (pvz. telefone surinkus tam tikrą URL adresą). Nors galima daryti video archyvus, bet aš pasidariau, kad įrašinėtų į diską tik tai, kas juda. Veikia puikiai tikrai. O vaizdų kokybė, savaime aišku, priklauso nuo kameros. Tiesa, senos kameros su 1.3 man neveikė niekaip. Tik naujoviškesnės. NAS serveris - antras panaudojimo būdas. Pasinaudojus btsync aš turiu nemokamą ir neribotą Dropbox’ą. Labai smagu, kad tokia programinė įranga buvo sukurta. Ji veikia pasakiškai, ne kartą universitete išgelbėjo, kai namie pamiršdavau kokius darbus kuriuos turėjau nunešti pristatyti. Cron’as - tai tokia programa, kuri reguliariai gali paleisti tam tikras komandas. Pavyzdžiui padaro atsargines kopijas serveriams, parašo laiškus kur kam reikia, aplanko svetaines kur būtina atidaryti kasdien, kad gauti taškų ir pan. 4. Verdiktas Eh, jau išsidaviau, kad planuoju dar vieną pirkti dėl namų kino centro. Bet vistiek pasakysiu, kad Raspberry Pi - tikrai apsimoka. Tiesa, jis lėtas IO funkcijoms, kartais tai net erzina. Tai bus aktualu, kai norėsite įsirašyti programas. Bet tai ne priežastis jo nepirkti. Gal kas bandėsi kitokias alternatyvas ir parekomenduotų geriau?

Muzikos failų tikrinimas

Jau esu rašęs straipsnį apie savo nekuklią muzikos galeriją. Tai štai dar vienas! Šį kartą bėda kitokia. Po praėjusio straipsnio jau turiu švarią galeriją - be jokių pasikartojančių dainų. Deja, ne visa muzika yra klausoma - dažnai tenka paspausti mygtuką „kita daina“. Kad to nebūtų, nusprendžiau pasirašyti labai paprastą programėlę su bash, kuri paleistų visas dainas po vieną einamąjame kataloge. Dainų grojimo metu galėčiau nuspręsti dainos likimą: jeigu išklausau ją iki galo - vadinasi daina patinka ir šalinti jos nereikia. Priešingu atveju - keliauja į šiukšlių dėžę. Nepasakosiu kaip ją pasirašyti, nes kiekvienas turintis šią bėdą ją spręstu kitaip. Štai mano variantas: #!/bin/bash SAVEIFS=$IFS IFS=$(echo -en "\n\b") for f in ./* do if [ -f "$f" ] then mplayer -really-quiet "$f" if [ $? -eq 0 ] then echo "OK" else mv "$f" ~/Muzika/Trash/ echo "Moved to ~/Muzika/Trash/$f" fi fi done IFS=$SAVEIFS Jeigu nuspręsite pasinaudoti šia programėle tai verta išsiaiškinti ką ir kaip ji daro. Pirmiausiai į akį kris $IFS kintamasis. Jeigu mėginsite tiesiog naudoti sintaksę for file in $(ls) tai susidursite su bėda, kad kiekvienas žodis bus traktuojamas kaip failas. Taip yra dėl šio magiško Internal File Separator kintamojo bash kalboje. Labai sunku paaiškinti šį kintamąjį (bent jau man), čia Jums padės šie atsakymai. Kaip matote, muziką leidžiame per mplayer programą. Galima leisti per bet kurią, kuri tik pagrojus dainai grąžina teisingą rezultatą: 0 - kai daina pagrota, 1 - kai įvyko klaida ją grojant (pvz. klausytojas nutraukė grojimą). O aš mplayer myliu už tai, kad: Galiu neišklausęs dainos paspausti ENTER klavišą - komandos rezultatas bus 0. Galiu išklausyti visą dainą - komandas rezultatas bus 0. Galiu nutraukti dainą paspaudęs CTRL+C - komandos rezultatas bus 1. Pagal vėliau esančią sąlygą (išraiška $? reiškia buvusios komandos išeities rezultatą - 1 (vienetą) arba 0 (nulį)) galiu nuspręsti grojamo failo likimą. Kodėl netrinu failų? Nes kas būtų jeigu pašalinčiau jį netyčia? Šio paprasto skriptuko pagalba perėjau per visą muziką ir pasišalinau ko nereikia. Tikiuosi kam nors tai bus naudinga.

Pomodoro BASH skriptas

Kadangi dirbu prie rimtų internetinių projektų, už kuriuos vėliau net gaunu pinigus, svarbu labai rimtai sekti savo laiką. Toks laiko žurnalo turėjimas yra naudingas dėl kelių priežasčių: Dažnai klientai moka už sugaištą laiką po atlikto darbo. Galiu įvertinti ar mano laiko planavimas tikslus. Pats žinau kiek praleidžiu laiko dirbdamas. Pavyzdžiui ar išdirbau savaitėje standartines 60 valandų. Taip pat žinau kiek dirbu prie savo projektų, todėl galiu skaičiuoti savikainą. Esu išnagrinėjęs daugybę tokių programų: Hamster, KTimeTracker, tomato.es ir pan. Pastarosios sistemos net rekordininkas esu. Nors išvardinta programinė įranga tikrai gera ir skųstis nėra ko, bet po ilgo laiko nusprendžiau persimesti prie labai primityvios sistemos. T.y. kad laiką sektų paprasta BASH programėlė, kuri savyje turėtų sleep 60 ir kas minutę išvestų į ekraną apie praėjusį laiką, o surinkus tam tikrą sumą, ją išsaugotų ataskaitos faile, kad nepasimestų. Kas yra Pomodoro technika? Tai tokia darbo metodika, kad yra susikoncentruojama tam tikro laiko tarpą į darbą ir daroma tik tai. Vėliau praėjus šiam laikui daroma mažytė pertrauka. Toks ciklas kartojamas kelis kartus, daroma ilgesnė pertrauka. Ir vėl viskas iš pradžių. Žinoma, toks apibūdinimas yra mano žodžiais (internete galima rasti geresnių ir tikslesnių). Dažniausiai minint Pomodoro yra naudojami tokie laiko tarpai: 25 minutes susikoncentruojama į darbą, 5 minutės pertrauka. Toks ciklas daromas 4 kartus. Tuomet pertrauka 20-25 minutes. Ir vėl viskas iš pradžių. Pati Pomodoro technika tikrai veikia man, veikia milijonams žmonių pasaulyje, išmėginkite ir Jūs! Pomodoro programa Skriptą rasite Github gist’e. Veikimas tikrai paprastas: rašote komandos vardą ir darbo aprašymą. Darbo aprašymui pats naudoju projekto pavadinimą, ar milestone (nežinau, kaip šis terminas lietuviškai) pavadinimą. Pavyzdžiui: pomodoro "blog entry writing" Taip pat matysite kiekvieną minutę progresą šios komandos, pavyzdžiui: Working on blog entry writing Today: 1 blog entry writing Progress: [XX ] 2/25 Pirma eilutė - priminimas prie ko dirbama. Antra dalis (rodoma „surinkus“ bent vieną Pomodoro) - šios dienos Pomodoro skaičiai prie kiekvienos užduoties (susumuoti). Ir paskutinės eilutės - dabartinės užduoties progresas. Paleidus programą savo kompiuterio lango krašte pamatysite užrašą, kad Pomodoro darbo sesija sėkmingai pradėta (tekstas bus tik kelias sekundes). O pasibaigus sesijai, bus atspausdintas dar vienas pranešimas. Na, jeigu sumąstysite šiuo pagalbininku pasinaudoti, tai tikrai sugebėsite pakoreguoti laikus ir tekstus pagal save :) Man visada smalsu ką kiti naudoja laiko sekimui. Šiuo metu pasaulyje programų yra sukurta tūkstančiai, pasiūla tikrai didelė. Be to, būtų keista išgirsti iš programuotojo sakant, kad jis neseka savo laiko :)

Randame vienodus failus su BASH

Susidūriau visai neseniai su situacija, kai dideliame muzikos archyve buvo daugybė pasikartojančių dainų (failų). Juk erzina kartais, kai pasileidi savo didžiulę muzikos kolekciją ir dažnai pasikartoja tos pačios dainos kurias tenka persukti. Todėl nusprendžiau tokius failus išrinkti (pirmiausiai), o vėliau ir pašalinti. Kai pamačiau savo komandos eilutės rezultatą nusprendžiau, kad derėtų juo pasidalinti ir su kitais. Bei, paaiškinti kas ką daro (galbūt tai kam nors bus naudinga besimokant BASH). Be to, tai gali būti naudinga ne tik kai turite didelę muzikos kolekciją, galbūt ir kitų failų kolekciją: išeities kodo, paveiksliukų, nuotraukų ir pan. Kaip sakiau, nagrinėsime patį rezultatą - eilutę, kuri dar nieko netrina, kuri tik parodo vienodo turinio failus: find -type f -exec md5sum '&#123;&#125;' ';' | sort | uniq --all-repeated=separate -w 33 | cut -c 35- Pati komanda velniškai paprasta. Pirmiausiai randame visus failus (failus, bet ne katalogus) su find -type f. Tuomet su kiekvienu failo pavadinimu įvykdome md5sum <failo vardas> komandą, kuri išves eilutes tokiu formatu: <md5 reikšmė 32 simbolių> ./pilnas/kelias/iki/failo.vardo Štai čia dar galime panaudoti keletą komandos find variacijų. Pavyzdžiui galime praleisti tuščius failus su find -not -empty arba galime ieškoti ne dabartiniame kataloge, o konkrečiame, pavyzdžiui: find Darbas/Klientai/Nelegali-Muzika/. Turėdami šiuos duomenis galime juos išrikiuoti abėcėlės tvarka (komanda sort be jokių argumentų). Pasikartojančių failų (kurių turiniai vienodi ir nesvarbu kokioje disko ar katalogo vietoje jie yra) MD5 reikšmės bus vienodos, todėl išrikiavus sąrašą MD5 reikšmės atsidurs šalia. Pavyzdžiui jeigu gavome tokį sąrašą: abcd12345 ./kelias/iki/rihannos-dainos.mp3 sadf33515 ./kelias/su/kita/daina.mp3 abcd12345 ./kelias/iki/kitos/rihannos-super-mega-mix-dainos.mp3 Tai po rikiavimo turėsime tokį: abcd12345 ./kelias/iki/kitos/rihannos-super-mega-mix-dainos.mp3 abcd12345 ./kelias/iki/rihannos-dainos.mp3 sadf33515 ./kelias/su/kita/daina.mp3 Kai turime visą tokį sąrašą, jau galėsime surasti vienodus failus tiesiog peržiūrėjus tokį sąrašą. Bet juk tai laiko švaistymas, nes Jūsų sąraše gali pasitaikyti daug ne vienodų failų. Todėl su sekančia komanda pašalinsime iš sąrašo tokias MD5 reikšmes kurios faile nepasikartoja. Tą padarysime su komanda uniq –all-repeated=separate -w 33. Pirmas argumentas nustato, kad komanda atspausdintų tik pasikartojančias eilutes, antrasis argumentas nurodo, kad tikrinimą ar eilutės vienodos daryti tik su pirmais 32 simboliais (iki 33 simbolių). MD5 reikšmė yra visada 32 simbolių. Dabar jau turėsime visą sąrašą TIK su pasikartojančiais failais. Jų MD5 reikšmėmis ir failo pavadinimais. Jeigu naudoti aukščiau parašytą sąrašą, tai gausime tik tai: abcd12345 ./kelias/iki/kitos/rihannos-super-mega-mix-dainos.mp3 abcd12345 ./kelias/iki/rihannos-dainos.mp3 Toks sąrašas yra nepatogus, nes turime teksto kuris ne tik mums nieko nesako, bet ir „šiukšlina“ išvestį. Apkirpsime eilutes su komanda cut -c 35-. Tikriausiai smalsu kodėl skaičius 35 yra panaudotas? Prisiminkite mūsų išvesties formatą: 32 simboliai MD5 reikšmei, du tarpai ir toliau failo vardas. Internete, tiesa, radau ne vieną būdą išspręsti šiai problemai. Na, o va šitame taške jau sužinojau apie jau egzistuojančią programą kuri daro viską ką aprašiau aukščiau: fdupes. Įdiegiam: sudo apt-get install fdupes Naudojam: fdupes -r . Pirmiausiai ieškos pagal dydį, vėliau pagal MD5 išraišką. Komanda tikrai greitai veikia (kadangi kitoks rūšiavimas vyksta, tai greičiau nei mano aprašytas būdas). Kadangi jau neproduktyviai išleidau laiką savo komandai, tikiuosi kam nors besimokančiam BASH tai pasirodys naudinga.

Kokias programas naudoju (2013 m.)

Prieš du metus rašiau straipsnį kokias programas naudoju. Per tą laiką daug kas pasikeitė. Dažnai kalbant su draugais arba susipažinus su naujais programuotojais (galbūt net ką tik „iškeptais“) daug kas manęs klausia kokius įrankius naudoju, kam, kodėl, kaip. Taigi, nusprendžiau dar kartą atnaujinti šį seną straipsnį ir pasidalinti kai kuriais patarimais. Operacinė sistema Tris metus naudojau Ubuntu, metus Kubuntu ir dabar jau geri metai prie tiesiog Debian (visų *buntu tėvinė operacinė sistema). Kodėl būtent ją? Ubuntu išmečiau, nes jie tais laikais pristatė Unity grafinę aplinką kuri nemokėjo dirbti su keliais monitoriais. Tai buvo kritinis dalykas man, kaip programuotojui, todėl teko rinktis kažką kito. Tik užuot perėjęs į kokį Gnome, perėjau į Kubuntu operacinę sistemą su KDE. Tikrai buvau patenkintas, ir šia sistema ilgai ir produktyviai naudojausi ir net geriau jautėsi man nei Gnome (daugiau galimybių, gražiau atrodė, daugiau funkcijų ir nustatymų, išdirbti įrankiai darbui su ja). Na, o Gnome pristatė labai puikią Gnome 3 išvaizdą, tačiau mano kompiuterio grafinė plokštė nepalaiko kai kurių WebGL funkcijų, tai jos darbiniame kompiuteryje įdiegti negalėjau. Vėliau įsidarbinęs labai puikioje įmonėje buvau „paskatintas“ pakeisti grafinę aplinką iš KDE į Awesome. Tai daug produktyvesnė grafinė aplinka daug dirbančiam žmogui. Taigi, tuo metu nusprendžiau, kad čia Kubuntu jau nebereikia, reikia grįžti prie „nieko“ - Debian. Programavimas Aišku, didžiausią dalį laiko kurį prie kompiuterio praleidžiu tai programuodamas pačius nuostabiausius projektus pasaulyje! Taigi, programavimo įrankių patirtį tikrai turiu. Programuoju su VIM ir ne kitaip. Nenaudoju ir nenaudosiu greičiausiai nieko (iš redaktorių) daugiau. Tai labai greita, super lanksti ir programuojama IDE. Turi tikrai viską: spalvinimą kodo, daugybę daugybę daugybę galimybių, visur palaikoma, visur paleidžiama. Pirmasis mano terminalas buvo gnome-terminal. Skundžiausi, kad jis yra labai lėtas ir praktiškai jo negalima naudotis. Bet kiek bebandžiau kitų, greitesnių terminalų, visgi savo išvaizda ir paprastumu šis buvo patogiausias. Ir dabar jo lėtumo problema kaip ir išspręsta, tai neturiu kuom skųstis. Screen programos jau nebenaudoju. Naudoju tmux, kuris yra daug pranašesnis už savo „tėvą“ screen. Daugiau galimybių, paprasčiau naudotis, daugiau funkcijų. Be konfigūracijų screen’u praktiškai neišeina naudotis, o tmux jau veiktų ir atrodytų gerai out of the box, kaip sakant… Tiesa, screen nutolusiuose serveriuose jau būna, o tmux reikia įdiegti. čia galbūt vienintelis jo minusas. Dreampie nebenaudoju. Jeigu reikia parašyti kažkokį kodą, darau tiesiog konsolėje arba produkcinėje svetainėje (joke :D). Mėgstu sudėtingesnių algoritmų prototipus pasidaryti tiesiog python komandoje. Skirtumams tarp failų pamatyti naudoju meld. Tai pats paprasčiausias įrankis ir savo išvaizda pats gražiausias iš visų savo konkurentų (kdiff3, vimdiff, daugiau nežinau). Gimp grafikos programos nenaudoju. Vietoje to naudoju tam „skirtą“ programinę įrangą visiškai kitoje operacinėje sistemoje ;))) Dabar priešingai nei seniau, projektus planuojuosi tiesiog popieriaus lape. Tai greita ir patogu. Tokia programinė įranga kaip DIA tik lėtina procesą. Nors ją ilgai naudojau, metus tai tikrai. Nebenaudoju Hamster. Nors tai superinė programa, bet dabar darbo laiką seku su paprasčiausiai savo sukurtu bash skriptu. Vėliau jį paskelbsiu. Sqlbuddy deja nebetobulinama, adminer neturi dar kai kurių valdymo funkcijų, tai grįžau prie seno PhpMyAdmin. Nors daug daugiau naudoju tiesiog mysql, bet PhpMyAdmin kartas tikrai praverčia, kai projektuose reikia aiškintis ir daug nagrinėti. Finansams valdyti GnuCash pasirodė per didelė „pramoga“. Tai velniškai sudėtinga programinė įranga kuri asmeniniams finansams yra tiesiog per didelė. wxBanker irgi verta paminėjimo programa, ilgai ją naudojau iki perėjimo į Kubuntu. Kubuntu operacinėje sistemoje naudojau KMoney, tačiau vėlgi, ji sudėtinga, reikia tikrai pasiskaityti apie ją prieš bandant naudotis. Jau kuris mėnesis naudojuosi tiesiog komandinės eilutės įrankiu - clipf. Paprasta, neturi nieko ko nereikia: yra sąskaitos, grupės ir operacijos. Trys dalykai, nieko daugiau. Visa kita, jeigu reikia, galima pasidaryti pačiam. Naudojau Thunderbird ir Evolution. Bet dažnai matau, kad VIM naudojantys žmonės naudoja mutt. Taigi, pabandęs, pamačiau koks tai kartu ir paprastas ir galingas dalykas. Praleidus kelias dienas jį konfigūruojant dabar turiu tikrai puikų pašto klientą. Iš seniai naudojamų programų dar liko nepakeičiamas Parcellite. Jis laiko kopijuojamų tekstų istoriją. Tai ypač naudinga, kai kopijuojamą tekstą pamirštu išsaugoti kur nors, visada galiu net ir po kelių dienų grįžus jį atrasti iš Parcellite programos. Naudojau Firefox ilgą laiką, bet vėliau pakeičiau į Chrome dėl greičio. Tiesa, dabar būtų labai sunku pasakyti kuri naršyklė veikia greičiau, bet vistiek. Naudoju Chrome kaip pagrindinę, o visas kitas kaip testavimo naršykles. Nors biuro įrangą naudoju retai, tačiau užuot tai daręs OpenOffice programoje dabar tą darau tiesiog Google Drive. Taip įrašai išlieka saugūs (praradus galima atstatyti), yra dokumentų istorijos, yra galimybė pasiekti dokumentus telefone arba planšetėje. Naudojau ilgą laiką Banshee programą muzikai klausyti, bet kažkuri jos versija man tiesiog nepasileisdavo. Taigi, pakeičiau ją į mpd programą, tačiau ši nuolat pridarydavo bėdų su garso nustatymais. Kartais paklausus muzikos per mpd programą negalėdavau žiūrėti Youtube įrašų (neturėdavau garso). Taigi, cmus programa pakeitė pastarąją ir dabar esu patenkintas. Filmus pradėjau žiūrėti per mplayer programą. Tai labai mažai resursų reikalaujanti programa kurią labai paprasta valdyti nuotoliniu būdu. Deja, bet kažkaip VLC programos nuotoliniu būdu valdyti nepriverčiau. Kokias programas Jūs naudojate? Gal manote, kad kai kurios mano programos gali būti pakeistos kitomis, geresnėmis?

Dažniausiai naudojamos komandos

Jau kelintą kartą manęs klausia kaip gauti dažniausiai naudojamų komandinėje eilutėje komandų sąrašą. Nors tokių skriptukų galima tikrai rasti daugybę internete ir nieko čia naujo, tačiau surasti tų komandų paaiškinimus būna sunku. Todėl šį straipsnį skiriu tiems, kas ne tik nori pažiūrėti populiariausių komandų sąrašą, bet ir suprasti kaip tai daroma. Kaip minėjau, skriptų galite rasti internete daugybę. Laimei, kad dauguma jų bus panašios į šią, todėl supratus mano pavyzdinę eilutę - tikrai suprasite ir kitas. Taigi turime tokią komandinę eilutę kuri duoda rezultatą visų komandų pagal panaudojimų kiekį sąrašą. Norint atrinkti tik 10 populiariausių, užtektų prirašyti gale: | head -n 10. Gauname išvestį (pavyzdys): 26 ls -alh 20 cd Parsiuntimai 17 ssh localhost 'mysqldump' Kaip jau akivaizdu, pirmiausiai gauname visą istoriją su komandomis komandos history dėka. Ši istorija yra pagal datą (paskutinis įrašas išvestas šios komandos rodo paskutinę vykdytą komandą). Tačiau visos šios komandos yra prefiksuotos numeriu. Šis numeris reiškia komandos panaudojimo numerį. 3 ls reikštų, kad komanda ls buvo trečia istorijoje (trečia komanda kurią rašėte). Tačiau mums numerių nereikia. Kadangi history nepateikia jokių pagalbinių argumentų, kurie leistų matyti tik komandų sąrašą, tai tokį komandų filtravimą padarysime patys su awk {print $2} komanda. Taigi jau turėsime tokį sąrašą (pavyzdys): cd Parsiuntimai ls -alh ls -alh [..] Komandos mūsų istorijoje gali būti sudėtinės. T.y. galime turėti komandą kuri susideda iš kitokių komandų, pavyzdžiui: Kaip matote, komanda įvykdo mysqldump komandą nutolusiame serveryje ir rezultatą perduoda į vietinę komandą mysql. Taigi, mūsų trečioji komanda awk 'BEGIN &#123;FS="|"&#125;{print \$1}' leidžia atfiltruoti tokias sudėtines komandas ir palikti tik pirmąsias (jų „pradžias“). Jeigu žiūrėti tik į pavyzdį, tai būtų prisijungimas prie nutolusio serverio ir mysqldump įvykdymas. Jeigu savo TOP’e norite matyti pilną komandą (su visomis sudėtinėmis logikomis), tai tiesiog pašalinkite šio filtravimo komandos dalį. Vėliau atfiltruotą komandų sąrašą išrikiuojame pagal pavadinimą sort pagalba. Norėdami sužinoti kiek komanda kartų buvo minėta išrikiuotame pagal pavadinimą sąraše, paleidžiame uniq -c komandą. Ji duos komandos pakartojimų skaičių ir komandos pavadinimą. Rezultatas kurį turėsime (pavyzdys): 17 ssh localhost 'mysqldump' 26 ls -alh 20 cd Parsisiuntimai Kadangi toks sąrašas bus išrikiuotas pagal pavadinimą, bet ne pagal skaičių kiek kartų jis pasikartojo, tai jis mums jokios naudos neduos. Taigi, sąrašą galime dabar išrikiuoti komandos sort -rn pagalba. Argumentas -n nurodo, kad rikiuojama bus ne abėcėlės, bet skaičių tvarka. Kadangi mūsų visa išvestis prefiksuota skaičiais, tai komanda pagal tą skaičių išrikiuos visas eilutes. Rikiavimas bus atliktas didėjimo tvarka (viršuje bus rečiausiai pasikartojančios operacijos, o apačioje dažniausiai), o pridėjus argumentą -r šį sąrašą apversime aukštyn kojomis. Galbūt žinote paprastesnį ir trumpesnį komandos užrašą? Jeigu taip, tai pasidalinkite su kitais!

Atsarginių kopijų darymas su komanda - dd

Praėjo labai daug laiko po mano pastarojo straipsnio apie atsarginių kopijų darymą su tar komanda. Nors anksčiau jas darydavau būtent šiuo įrankiu, dabar darau su kitu. Kodėl buvau pasirinkęs būtent tar? Pirmiausiai dėl naudojimo paprastumo. Taip pat dėl to, kad tar komanda yra bet kuriuose Linux’uose. Toks atsarginių kopijų darymas yra labai primityvus, todėl lengva išmokti ir naudotis. Šiandien kalbėsiu apie kiek sudėtingesnį įrankį, tačiau su juo atsargines kopijas darausi ne tik savo kompiuterių ar serverių, bet dar ir įvairių įrenginių, kaip pavyzdžiui Ipod ar tiesiog USB atmintinių. Kalbu apie komandą kurią rasite savo Linux’uose - dd. Komanda dd, priešingai nei tar kuria ne failų archyvą, o visą particijų lentelę sukiša į norima išvestį (dažniausiai failą). Pavyzdžiui jeigu su fdisk -l matome savo USB įrankį su jame esančiomis particijomis: $ fdisk -l Device Boot Start End Blocks Id System /dev/sde1 63 7887914 3943926 b W95 FAT32 Tokios particijų lentelės atvaizdą galime išsaugoti lengvai į failą: dd if=/dev/sde of=kopija.img Čia turėčiau paminėti jog yra skirtumas tarp užrašų /dev/sde1 ir /dev/sde. Jeigu Jūs į vieną kopija.img norite sukišti kelias to įrenginio particijas, tai reikėtų saugoti visą medį. Tokiu atveju reikėtų rašyti tiesiog /dev/sde. Tačiau jeigu iš viso medžio reikia Jums tik vienos particijos, rašykite /dev/sde1. Įrenginio ID (mano atveju sde ir sde1) pas Jus gali skirtis, todėl atidžiai peržiūrėkite koks Jūsų ID prieš ką nors darant. Galbūt kuriant atsarginės kopijos atvaizdą ir nėra baisi klaida suklysti, bet suklysti atstatinėjant - siaubinga. Netgi gali baigtis labai svarbių dokumentų praradimu. Nors pats tokias atsargines kopijas darausi jau gana seniai (bent metus tikrai), bet turiu paminėti keletą minusų. Pirmiausiai dėl to, kad kopijuojama visa particija (ar visas medis), atvaizdo dydis tampa laibai didelis. Jeigu particija užima 10 GB, o joje yra failų 2 GB - sukurtas failas kopija.img svers vis tiek 10 GB. Kadangi į failą reikia įrašyti/perkopijuoti visus baitus, tai toks duomenų kiekis trunka pakankamai ilgai. Pvz viename iš kompiuterių Debian sistemą su 10 GB archyvuoja ~14 minučių (daug!), tiek pat laiko ir atstatinėja. Kitas minusas - nelabai išeina daryti versijavimo. Tarkime laikyti laikyti kelių dienų atvaizdus dar nieko, bet ilgiau - užims labai daug disko vietos. Rezultate - komanda trunka lėtai ir jos išvestis dažnai užima labai daug. Kam tada išvis tokias kopijas darytis? Pirmiausiai darydamas Debian sistemos atsarginę kopiją esu 100% tikras, kad atstatęs gausiu 100% tokią sistemą, kurią turėjau šios kopijos darymo dieną. Tokias atsargines kopijas jau tikrai bent 15 kartų atstatinėjau įvairiems įrenginiams. Labai praktišką panaudojimą atradau, kai viename iš draugo USB buvo įrašyta Suse, o man į USB reikėjo įrašyti Debian’ą ir po to atgal Suse. Toks rankinis kopijavimas (pvz. rsync pagalba) būtų velniškai ilgai trukęs, o dd komandos pagalba per kelias minutes viską sutvarkiau. Pasidariau Suse atsarginę kopiją, pasidariau ko reikia ir atstačiau ją atgal. O atstatyti padarytą kopiją labai paprasta: dd if=kopija.img of=/dev/sde Čia vėlgi - prisiminkite ką rašiau apie skirtumą tarp /dev/sde ir /dev/sde1. Tiesa, dd komanda turi labai daug argumentų ir panaudos atvejų. Būtinai paskaitykite apie ją man dd. Parašęs šį straipsnį supratau, kad ši komanda verta dar vieno, nes panaudos atvejų tikrai daug.

Django framework - kas tai?

Pradėsiu ilgą ir nebūtinai nuobodžią straipsnių seriją apie Django framework. Kaip ją įdiegti, naudotis, kokie jos privalumai ir kodėl verta ją mokytis. Django web framework yra atviro kodo Web 2.0 aplikacijų framework’as parašytas su Python programavimo kalba. O jos programavimas buvo pradėtas kuriant naujienų svetaines. Tiesa, kurį laiką ši sistema dar buvo uždaro kodo, bet 2005 metų liepos mėnesį ji buvo išleista BSD licencija. Pavadinta Django vardu gitaristo Django Reinhardt garbei. Ir jau po trijų metų, 2008 metais pasauliui buvo pranešta kad naujai susikūrusi organizacija Django Software Foundation nuo šiol programuos Django. Bet kas visgi tai per dalykas? Pirmiausiai šis framework’as sukurtas palengvinti programuoti sudėtingus sprendimus naudojant duomenų bazę. Nors šiuo metu sistema leidžia net turėti projektus kurie veikia be duomenų bazės. Programuota laikantis MVC architektūros (apie tai kitame straipsnyje). Nors dabartiniais laikais kyla pakankamai daug ginčų dėl kai kurių sistemos vietų, bet šis projektas stengiasi išlaikyti pernaudojamumo ir priderinamumo principus. Todėl Django ateina kaip framework’as ant kurio gali programuoti bet ir prie kurio gali prijungti įvairius komponentus. O jų tikrai daug (apie atskirus komponentus parašysiu vėliau). Taip pat vienas iš svarbių programavimo principų tapo DRY (don’t repeat yourself). Šiuo metu interneto svetainių sukurtų su Django yra ne tik užsienyje daug, bet ir toje pačioje Lietuvoje. Žymiausios pasaulio svetainės naudojančios Django yra Pinterest, Instagram, Dpaste. Daugiau svetainių rasite DjangoSites.org svetainėje. Tiesa, toje pačioje svetainėje lietuviškų svetainių buvo bent kelios. Šiuo metu - tik viena. Pats jau daugiau nei 3 metus šiuo framework’u naudojuosi ir galiu pasakyti, kad tai yra velniškai greitas, lankstus ir patogus framework’as. Įgyvendinti kritiniai dalykai kuriuos dažnai tenka tvarkyti patiems naudojant kitus frameworkus: apsauga nuo XSS, clickjacking, SQL injections. Duomenų migracijų komponentai, thumbnail komponentai, NoSQL moduliai. Komandinės eilutės programos greitai ir lengvai padės pasiekti maksimalių rezultatų. Šiam framework parašyta nemažai ir knygų (kelias kurias perskaičiau būtinai parekomenduosiu vėliau). Pradžiai trumpai tiek. Tie kurie nekantrauja daugiau sužinoti ar išbandyti siūlau oficialioje svetainėje djangoproject.com pereiti per 4 dalių žinyną. Jame tikrai labai daug visko apie Django.

Kaip pranešinėti apie programinės įrangos klaidas?

Programinės įrangos klaidų pranešinėjimas yra labai įprastas dalykas. Praktiškai visoje programinėje įrangoje būna klaidų/defektų, kurie buvo nepastebėti laiku iki jos išleidimo. Gerai bent jau tai, kad dažniausiai šios klaidos taisomos nemokamai. Tačiau čia labai svarbu padėti patiems programuotojams greičiau išspręsti šias problemas. Man gaila įmonėse dirbančių support žmonių kurie dažnai susiimdavo už galvos pamatę kokį klientas atsiuntė klaidos pranešimą ir bebandydami su piktu klientu išsiaiškinti kas negerai. Iš tiesų, šis straipsnis skirtas būtent jų klientams :) Tvarkinga PĮ - klientų pagalba. Klaidų programinėje įrangoje dažniausiai būna visada, jokia nuostaba. Jos nebūtinai atsiranda dėl darbuotojų kompetencijos trūkumo. Tai gali būti laiko, testavimo ar išsiblaškymo problema. Bet jeigu norite gauti tvarkingą PĮ - privalote gerai aprašyti kas konkrečiai veikia nekorektiškai. Taip darbuotojai nepraleis laiko ieškodami kas prastai veikia, nereikės papildomai komunikuoti dėl to paties. Taigi - laikas bus sutaupytas abiems šalims. Atminties trūkumas? Dažnai pasitaikydavo praktikoje ir matydavau kitų projektuose, kad patys klientai mano, jog Jūs puikiai žinote apie ką eina kalba ir į detales nereikia smulkintis. Todėl klientai vienu dar dviem žodžiais nusako problemą. Tačiau dažnai tie patys programuotojai turi net ne vieną projektą, arba per pastarąjį pusmetį dirbo prie kelių, todėl gali tiesiog neatsiminti smulkių detalių apie Jūsiškį. Neaiškios nuotraukos. Esu ne kartą matęs, kaip klientai atsiųsdavo langą, kuriame nieko blogo iš pirmo žvilgsnio nesimatė. Ir pasirodo: klientas pamatydavo, kad vienoje eilutėje šriftas kitoks, arba kad kur nors mažytės linijos neprasitęsia per visą reikalingą bloką. Neaiški problema. Dar viena didžiulė bėda - nepaaiškinimas kur yra problema ir kokia. Tikrai ne kartą esu matęs tokį klaidos pranešimą kaip „Blogai veikia X.“, o atidarius „X“ nerasdavai nieko blogo. Tai kaip apie jas pranešinėti? Man visada patiko „bug trackeriai“ atviro kodo pasaulyje. Jų formose dažniausiai prašoma tokios informacijos, kas mano manymu, jeigu šią pildytų visi klientai ir formato laikytųsi, klaidos būtų taisomos žymiai greičiau. Ten prašoma atsakyti į tris klausimus prieš pildant klaidos pranešimą. Manau, kad ši informacija yra labai reikalinga efektyviai ir greitai išspręsti problemas. Plačiau apie juos. Kokie veiksmai iki klaidos buvo vykdomi? Dažnai tai būna operacijų sąrašas iki pamatant klaidos pranešimą. Kokie buvo veiksmai vykdomi, kokiu klientu buvo prisijungta prie PĮ, kokia tvarka buvo vykdomos operacijos, kokia informacija buvo pildyta formose ir pan. Tai turi būti nuoroda kokius veiksmus reikėtų atlikti, kad atkartoti klaidą. Kokio rezultato tikėtasi? Būtina nusakyti, kad programa atliktus prieš tai išvardintus veiksmus turėjo lankytojui gražinti konkretų rezultatą X, tačiau… Koks rezultatas buvo gražintas? Klientas pastebėjęs nekorektišką vietą privalo kuo detaliau ją aprašyti: kas ir kurioje vietoje neteisingai atvaizduojama. Galbūt toks atvaizdavimas nekorektiškas būna ne visada, o tik atliktus kažkokius konkrečius išskirtinius veiksmus? Kartais klaidos pasirodo tik naudojant tam tikrą operacinę sistemą, kokią nors naršyklę (arba net jos versiją), Internet Explorer (Internet Explorer nėra naršyklė, tai programa neteisingai atvaizduojanti interneto puslapius) arba į kompiuterį įdiegus įvairias programas (pavyzdžiui antivirusines), kurių „pagalba“ blokuojamas kažkoks funkcionalumas. Klaidų neturi būti. Esu nusistatęs, kad klaidų neturi būti tuo metu, kai kažką darai naujo. Pirmiausiai reikia ištaisyti klaidas - vėliau kurti funkcionalumą. Čia daugumos Lietuvos įmonių, su kuriomis teko susidurti, problema. Persipildę „bug trackeriai“ dažnai įmonės vardą neša žemyn, klientai būna nepatenkinti, o ir pati įmonė nespėja visko laiku. Taigi, pagailėkite support žmonių. Padėję jiems, padėsite greičiau savo projektams korektiškai veikti.

Knyga „Code Complete“. Įvertinimas 10/10!

Visada maniau, kad komentarus kode rašo tik pradedantys arba prasti programuotojai. Mano akimis komentarai kode dažniausiai parodo kokia prasta yra projekto architektūra. Nes gero kodo dažniausiai komentuoti nereikia. Tik išskirtiniais atvejais. Po šios knygos nuomonė ne tik, kad nepasikeitė, tačiau tik dar daugiau priežasčių radau jų nerašyti. Taigi apie ką aš? Ogi apie labai nuostabią knygą „Code Complete“. Ji tikrai nėra dar vienas pradžiamokslis ateinantiems į pasaulį programuotojams. Tikrai nerekomenduočiau jos skaityti programuotojui kurio patirtis dar nesiekia kokių 3 metų. Nes tokiam žmogui, mano akimis, „pro vieną ausį įeis, pro kitą išeis“. Nuostabi knyga supažindinanti kaip spręsti daugybę problemų ir labai svarbu, kad ją skaitantys būtų bent kartą dirbę komandoje, būtų pamėginę bent kelis programavimo įrankius ar planavimo technikas, „žinotų“, kad programinės įrangos kūrimą sudaro ne vien tik programavimas ir testavimas. Bet tie kas dar tik to mokosi - knyga tikrai ne jiems. Ši knyga (1 pav.) yra tikrai bent jau dešimtuke labiausiai rekomenduojamų knygų IT specialistams. Ją parašė autorius Steve McConnell. Jeigu skaitėte bent vieną jo knygą, tikrai manau norėsite perskaityti ir kitas. Mano knygos vertinimas iš 10 balų visi 10 su pliusu. Tiesa, 900 puslapių rimtomis temomis buvo iššūkis. Greitai knyga tikrai nesiskaitė, nes daugelyje vietų reikėjo įsigilinti į skaičius. Ir statistika buvo tikrai vienas įdomiausių dalykų šioje knygoje. O Jūs ar žinojote, kad lėčiausiai ir greičiausiai taisantys klaidas programuotojai jų pridaro daugiausiai? Programinės įrangos kūrimas neapsiriboja vien tik vienu programavimo etapu. O kokie dar yra etapai? Kokių veiksmų imtis, kad programinė įranga bėgant metams netaptų dideliu ir sunkiu iššūkiu? Ar žinote kiek daug būdų yra valdyti projektų tobulinimo darbus? Ir iš tikrųjų, knyga mane šokiravo savo „gerų praktikų“ ir įvairios programavimo statistikos kiekiais. Šią knygą perskaityti tikrai rekomenduočiau kiekvienam įgudusiam programuotojui. Tikrai nepatingėkite praleisti daugybės valandų lėto skaitymo, jis tikrai atsipirks su kaupu.

PyCon LT 2012 konferencija

2012 metų balandžio 28 dieną Vilniuje įvyko PyCon LT 2012 konferencija. Jos metu konferencijos dalyviai pristatė kaip Python gali būti naudojamas įvairiose platformose, kaip gali būti naudojama mokyti kitus, kas yra Python paketai ir kaip galima gauti neblogų rezultatų panaudojus tam tikrus, atviro kodo, Python modulius. Vilniaus kolegijos patalpose vykusi konferencija visgi sulaukė tikrai nemažai dalyvių. Nors konkretaus dalyvių skaičiaus pateikti negaliu, tačiau ne tokia jau ir kukli salė buvo užimta pilnai. Ir nors konferencija jau yra praėjusi, bet renginių organizatoriai suteikė galimybę jas peržiūrėti internete. Tiesa, dėl techninių priežasčių viena prezentacija nebuvo įrašyta - „Django, nuo ko pradėti, kaip pabaigti“, kurią pasakojo renginio organizatorius Mantas Zimnickas. Bet nieko nepadarysi, tenka džiaugtis tuo ką turim. Tad ačiū organizatoriui, Mantui Zimnickui, kuris po labai ilgų kalbų įgyvendino šią idėją. Ir, žinoma, žmonėms kurie prisidėjo įrašinėdami ir montuodami video, bei tiems kurie be manęs taip pat pristatė Python temas. Tie, kas neturėjo progos pasiklausyti nemokamos konferencijos siūlau pirmiausiai susipažinti su buvusia programa, kurią rasite čia ir po jos peržiūrėti video pranešimus Youtube PyCon LT 2012 kanale. Skaidres Open Office formatu rasite failų saugykloje. Daugiau skaidrių iš visokių metų prezentacijų galima rasti GitHub repozitorijoje.

ImageMagick - paveiksliukų klijavimas (CSS Sprite)

Tikrai ne vieną kartą teko „klijuoti“ kelis paveiksliukus į vieną tam, kad sumažinti iš svetainės siunčiamų resursų kiekį. Vieni tai daro pasinaudoję kokiu nors paveiksliukų redaktoriumi (čia pirmiausiai į galvą šauna mokama programinė įranga Photoshop), kiti tą daro pasinaudoję kokiais nors į kompiuterį įrašytais įrankiais arba internete esančiomis paslaugomis. Tačiau atidarinėti didžiulę programą paveiksliukų redagavimui arba ieškoti serviso dažnai kainuoja laiko. Juk darbas toks paprastas: tiesiog sujungti kelis paveiksliukus į vieną. Taigi šiandien parodysiu kaip tai galima padaryti ImageMagick įrankio pagalba tiesiog komandinėje eilutėje. Pirmiausiai pasitikrinkite ar Jūsų kompiuteryje tokia programinė įranga apskritai egzistuoja. Jeigu ne, įsidiekite ją: apt-get install imagemagick # Debian šeimos OS Atidarykite katalogą kuriame yra Jūsų paveiksliukai kuriuos norite sujungti ir paleiskite sekančią komandą: montage -background transparent -geometry +0+0 *.png rezultatas.png Argumentų paaiškinimai: -background transparent # peršviečiamas fonas tarp paveiksliukų -geometry +0+0 # kokius tarpus padaryti tarp paveiksliukų Dažnai pasitaiko, kad kataloge būna šimtai paveiksliukų ir jų visų sujungti į vieną dažniausiai nenorėsite. Todėl atsirinkite juos pavadinimą pakeisdami į tokį, kuris rastų Jūsų jungiamus paveiksliukus kataloge. Pavyzdžiui slider_*.png nurodo, kad jungsime tik tuos paveiksliukus, kurie turi pavadinimo pradžią slider ir baigiasi formatu PNG. Taip pat, kad nekiltų problemų, stenkitės išlaikyti vienodą visų jungiamų paveiksliukų rezoliuciją. Faile rezultatas.png matysite norimą rezultatą: sujungtus paveikslėlius į vieną failą. Trumpai priminsiu kaip naudoti CSS kode CSS sprite: background: url('rezultatas.png') no-repeat 32px 0; width: 32px; height: 32px; Vietoje 32px 0 įrašykite koordinates kurį kvadratą tuo metu rodyti pagal situaciją.

BASH - Linksmasis traukinukas

Ši programa apčiuopiamos naudos Jums neatneš, tačiau bent jau šyptelėsite pamatę jos rezultatą. Tuo labiau, juk tokių įdomybių kaip Star Wars žiūrėjimas per telnet’ą nėra daug: telnet towel.blinkenlights.nl Pristatau sl komandą - paprasčiausią traukinuką pralekiantį per ekraną NCurses pagalba su keleiviais prašančiais pagalbos. Tačiau norint pradėti naudotis šia komanda, pirmiausiai teks ją įsidiegti. Tą Debian šeimos operacinėse sistemose galite padaryti labai paprasta komanda: apt-get install sl Ir rezultatą galite išvysti savo ekrane iškvietę sl komandą su kažkuriuo argumentu (arba be jo): sl -a sl -l sl -f Kaip gyvai atrodo, galite pamatyti Youtube filmuke: <iframe width="480" height="360" src="http://www.youtube.com/embed/BPMd2dsSVR0" frameborder="0" allowfullscreen></iframe> Tikriausiai kiekvienas su BASH dirbantis žmogus ne kartą buvo vietoje komandos ls parašę sl. Kitą kartą taip suklydus šyptelėsite pamatę traukinuką, o ne failų sąrašą.

VIM - didinam ir mažinam skaičius

Ne kartą teko matyti kaip programuotojai su VIM redaktoriumi keisdami kode masyvus ar kitokius duomenis ranka didindavo/mažindavo skaičius. Nors, tikriausiai, praktika reta, tačiau tą daryti tikrai tenka. Žinoma, nieko blogo viską daryti ranka, bet tikriausiai kaip kiekvienas save gerbiantis programuotojas - pirmiausiai pamąstysite kaip tą padaryti kuo mažiau paspaudimų. Tad tiems, kas naudojasi VIM redaktoriumi programuojant, tikrai pravers keli patarimai. Pirmiausiai pradėkime nuo pavyzdinės situacijos. Tarkime turime tokį masyvą: $masyvas[1] = $vardas; $masyvas[2] = $pavarde; $masyvas[3] = $salis; $masyvas[4] = $miestas; $masyvas[5] = $adresas; Ir norime į pirmąjį elementą įkišti pilną vardą ir pavardę, o vėliau, kad viskas būtų kaip buvę ($masyvas[1] = $vardas . TARPAS . $pavarde). Mums padės VIM klaviatūros spartieji klavišai. Norėdami padidinti skaičiuką (nesvarbu iš kelių simbolių jis yra) spausime CTRL+a arba CTRL+x skaičiaus reikšmės sumažinimui. Trumpai tariant: užėjus ant skaičiaus 321 ir paspaudus CTRL+a gausime skaičių 322 užėjus ant skaičiaus 321 ir paspaudus CTRL+x gausime skaičių 320 Viską atliekame normal režime. Taigi, norint padidinti/sumažinti visus ar dalį viršuje rašyto masyvo elementų raktus, pirmiausiai atsistosime ant skaičiaus 1 ir pasinaudosime makro komanda: qq # pradedame įrašinėti makro komandą CTRL+a # padidiname skaičių j # žengiame žemiau masyvo q # išjungiame makro komandą Įsirašius makro komandą, galime pavykdyti ją norimą kiekį kartų. Kadangi masyve yra penkios eilutės, o vieną jau pakeitėme, užteks parašyti: 4@q # Vykdys makro komandą 4 kartus Ir rezultatas mūsų bus toks: $masyvas[2] = $vardas; $masyvas[3] = $pavarde; $masyvas[4] = $salis; $masyvas[5] = $miestas; $masyvas[6] = $adresas; $masyvas[1] = $vardas . TARPAS . $pavarde; # žiūrėti aukščiau Tikiuosi pravers :)

Knyga „97 things every programmer should know“

Visai neseniai pabaigiau skaityti knygą „97 things every programmer should know“. Ir tikrai, knyga verta dėmesio. Joje nėra jokių konkrečios programavimo kalbos pavyzdžių ir apie programavimą kalbama labai abstrakčiai. Tai knyga, kuri galėtų supažindinti jaunąjį programuotoją to, kas jo tikrai lauks ateityje. Ir manau pasinaudojus šios knygos patarimais ateityje galima išvengti labai daug rimtų problemų. Tie 257 puslapiai persiskaitė tikrai greitai, nors galbūt pati pradžia galėtų būti pradėta kitais straipsniais iš šios knygos. Nes pradžia, tikrai „neužkabliavo“. Aišku, galbūt kitiems pradžia nepasirodys nuobodi. Tai apie ką ši knyga? Trumpai - apie viską kas susiję su IT. Apie kodo standartus, paprastumą, refactoring’ą, įrankius, code review’us, komentarus. Beje, dėl komentarų, labai patiko ir labai pritariu - jų geriau vengti. Kodėl? Paskaitykite knygą :) Žinoma, patys populiariausi programavimo terminai „KISS“ ir „DRY“ taip pat bus aptarti. Ypatingai patiko, kad šios knygos 97 straipsnius parašė skirtingi žmonės, dirbantys skirtingose įmonėse, turintys ne vienerių metų patirtį. O pasiklausyti patyrusių žmonių patarimų - labai naudinga kiekvienam. Na, siekiant pagerinti savo kodo kokybę programuojant bet kuria programavimo kalba, tai perskaityti šią knygą yra tiesiog būtina. Jeigu skaitėte, parašykite komentaruose savo nuomonę.

Django GIT CMS

Tai - tikrai neeilinė turinio valdymo sistema. Tuoj suprasite kodėl. Pirmiausiai Django GIT CMS neturi jokios administracijos. Visas turinio valdymas šioje TVS 1 atliekamas per failus. Taip, perskaitėte teisingai. Atrodo gana neprofesionaliai? Klystate. Tokia šios sistemos idėja - būti paprastai, lanksčiai ir valdomai ne naršyklės pagalba. Su Python parašyta sistema, kuri veikia tik ant Django framework (veikia puikiai tiek su 1.1, tiek su 1.3 versijomis). Taip, ji skirta manyčiau IT žmonėms, bet… Viskam yra išimtys. Kodo paryškinimams tekste naudoja populiariausią Pygments biblioteką (Python kalbai). Jums nereikės instaliuoti įskiepių (plugins) nes… Jų čia paprasčiausiai nėra! Todėl jeigu užsimanysite kontaktų formos - teks pasitelkti į pagalbą Django aplikacijos, kurių yra tūkstančiai (o gal ir net daugiau). Kaip vyksta turinio administravimas? Šios sistemos valdymas vyksta viename kataloge - content. Katalogų struktūra tokia: Perspėjimas: čia išvardinti ne visi katalogai, kuriuose galima valdyti tam tikrą turinį. Daugiau informacijos rasite pačios sistemos kode. Nuoroda žemiau. Kiekviename kataloge galima valdyti tam tikrą svetainės turinį: blog - tinklaraščio straipsnių (tokių kaip šis) valdymas. files - katalogas failams laikyti (bet kokio tipo failai). simplecms - įvairūs (ne straipsnių) puslapiai, pavyzdžiui: apie mane, autorinės teisės ar pan. simplemenus - meniu, kuris vėliau gali būti atvaizduojamas kaip tik pageidaujama. simpletagging - žymų medis. Meniu ir žymų valdymą atliksite sukūrę YAML tipo failą. Taip maždaug atrodo meniu failo pavyzdys: O straipsnių ir puslapių valdymas restruktūrizuoto teksto pagalba (restructured text): Taigi, prikūrę tokių failų paleidžiame python manage.py gitcmsload ir visi duomenys iš failų bus sudėti į duomenų bazę. Taip, būtent į duomenų bazę. Django GIT CMS nėra statinio turinio generatorius (kaip pvz.: hyde, pelican), veikiau dinaminio. Django GIT CMS istorija Šią sistemą sukūrė Luis Pedro Coelho. Jo tinklaraštį, taip pat padarytą su šia sistema galite pamatyti čia. Paskutinis šio žmogaus įnašas į šią sistemą buvo 2011 metų sausio 24 dieną. Bent jau tokia data buvo, kai rašiau šį straipsnį. O pats pirmas commit’as buvo 2009 metų Rugsėjo pabaigoje. Tad sistema tikrai nėra nauja. Sistema su Affero 3 (GPL - interneto svetainėms) licenzija yra pasiekiama jo asmeninėje GitHub paskyroje. Bonus Ne paslaptis, kad šią sistemą panaudojau savo tinklaraštyje. Ir naudoju daugiau nei kelis mėnesius. Per tą laiką, pastebėjau kelis trukdančius naudotis šia sistema, dalykus. Todėl teko patobulinti šią sistemą. Visus pakeitimus rasite mano GitHub repozitorijoje Atsirado informacija kaip įdiegti šią sistemą, kokių ir kodėl reikia paketų. Tai palengvins sistemos įdiegimą, nes anksčiau reikėdavo gerokai įsigilinti į klaidų pranešimus kol buvo galima paleisti šią CMS. Parašyti Unit testai. Jų dėka pastebėtos labai senos klaidos buvo lengvai pataisytos. Taigi, nauji pakeitimai greičiausiai „neatkirs“ visos sistemos ;) Tie, kas mėgsta ne tik gerą programą, bet ir švarų kodą, ras validų PEP8 2 kodą :) Restruktūrizuoti failai dabar reaguos į statusą. Tai reiškia, kad nustačius straipsniui ‘unpublished’ Jūsų straipsnis nepasirodys svetainėje. Taip pat patobulinta komanda turinio perkėlimui iš failų į duomenų bazę ir pats procesas optimizuotas. Kodėl rekomenduočiau šią, o ne kitą sistemą Pirmiausiai, ji parašyta su Python (o aš Python kalbos mylėtojas). Ji naudoja vieną populiariausių framework’ų - Django. Nedidelis funkcionalumas atveria duris į platų vaizduotės pasaulį. Man, populiariausios sistemos kaip Wordpress ir pan. nepatinka dėl per didelio funkcionalumo ir „griozdiškumo“. Kam reikalinga administracija, juk galima naudoti kokį nors mylimą redaktorių, kaip VIM ar Emacs. Kam paklūsti bandos instinktui rinktis jau sukurtą įprastą Wordpress ar Drupal? :) Jeigu sumąstysite rinktis panašios paskirties sistemą, būtinai užmeskite akį. O jeigu kas jau tokia naudojasi, būtinai brūkštelėkite komentare. Įdomu pamatyti daugiau tokių sistemų entuziastų :) TVS - Turinio Valdymo Sistema. ↩ PEP8 - Python kodo standartų rekomendacija, apie kurią paskaityti galite čia. ↩

Knyga Don't make me think

Visai neseniai baigiau skaityti knygą apie “usability”. Tiesa, pastarojo žodžio ieškojau lietuviško vertimo, bet net ir usability.lt svetainėje jo neradau (tiksliau radau daug, nežinau kurį pasirinkti). Tad visas šis lietuviškas straipsnis bus apie anglišką žodį (atsiprašau dėl to iš anksto). Tad labai trumpai papasakosiu apie šią knygą. Jos pavadinimas “Don’t make me think” ir ją parašė “usability” testuotojas Steve Krug. O čia Steve Krug asmeninė svetainė, jeigu kam įdomu. Kodėl “usability” kam nors turi rūpėti? Pirma priežastis - internetas auga neapskaičiuojamu greičiu. Jeigu šiandien Jūs sugalvojote genialią idėją, kuri atneš Jums milijonus, tai vakar ji jau buvo įgyvendinta. Todėl greičiausiai kursite projekto kopiją su keliais išlinkimais. Tad tikrai norėsite pritraukti ne tik lankytojus, bet ir klientus ir žinoma, juos vilioti į savo svetainę. Tam, kad pritraukti lankytoją į svetainę reikės SEO žinių. Tačiau tam, kad žmogus pasiliktų svetainėje, šių žinių nepakaks. Juk niekas nenori, kad vartotojai išeitų iš svetainės, kai joje yra tikimybė parduoti reklamą ar kažkokias prekes/paslaugas internetu? Šiuo metu tai labai populiaru. Kita priežastis: jeigu vartotojai ateis ir dėl painiavos svetainėje jie pradės galvoti apie savižudybę, kalti būsite Jūs. Ką galite rasti šioje knygoje? Pirmiausiai autorius pradėjo su istorija kaip ši knyga apskritai atsirado, kas paskatino ją rašyti ir kaip jis bijojo, kad knyga gali pakeisti autoriaus teikiamas paslaugas (apie tai tik vienas sakinys, bet verta paminėti). Na, ir po to seka skyrius apie tai, apie ką bus ši knyga. Autorius ypatingai pabrėžia, kad ši knyga ne apie žmogaus dėmesio sutelkimo ties kažkokiais dalykais svetainėje (focus group control), bet apie dalykus, kurie nesupainiotų žmonių. Kaip žmogų nuvesti į tam tikrą puslapį, skyrių ar dalį svetainėje vos su keliais paspaudimais. Pavyzdžių knygoje labai daug. Pačių įžymiausių svetainių internete (pavyzdžiui amazon.com). Aišku, autorius ne tik nurodo svetainių blogybes, ne tik parodo ką reikia pakeisti, bet ir paskelbia savo pakeitimo variantus. Ir tikrai, pažiūrėjus į “prieš ir po” variantus kartais galima net išsižioti. Visas turinys svetainėje dažniausiai paliekamas (kartais pašalinamas reklamos perteklius) ir vualia! Nauja velniškai patogi sistema! Na, o žemiau tikrai prajuokinęs pavyzdys iš knygos. Knyga tikrai vertinga. Daug pavyzdžių, paaiškinimų, tikrų situacijų iš gyvenimo. Pavyzdžiai ko geriau atsisakyti, ko neturėti arba ką reikia sumažinti svetainėse. Skaityti nebus nuobodu, teksto iš tikro nėra labai daug. Paveikslėlių su maketais yra žymiai daugiau. Įdomiai ir su humoru aprašyta knyga neleido nuobodžiauti ją skaitant. Kam ši knyga? Ši knyga labiausiai turbūt skirta būtent svetainių savininkams, vadovams arba marketingo skyriui. Žinoma, labai daug naudingo ją perskaitę sužinotų tiek dizaineriai tiek programuotojai. Kartais tiek vieni, tiek kiti truputį nuklysta nuo “patogumo” pridėdami įvairių dalykų į svetainę. Aišku, net nepagalvodami, kaip į tai reaguos paprastas žmogus. Tad ši knyga pamoka visiems turintiems ar besiruošiantiems turėti svetainę. Kokia Jūsų nuomonė apie knygą? Gal skaitėte geresnių šia tema?

Mes esam žmonės, ne mašinos

“We are people, not machines” - būtent taip skamba šūkis šios idėjos internetinėje svetainėje. Taigi, kas čia per sukilimas? Šios idėjos autoriai siekia, kad žmonės galėtų sužinoti ne tik apie svetainės savininką ar svetainę suprogramavusią įmonę/žmogų, tačiau ir apie visus prisidėjusius prie tam tikro internetinio projekto: dizainerius, programuotojus, rašytojus, projektų vadovus, testuotojus, draugus, tėtį, mamą ar pan. Dažniausiai kol projektas “gimsta”, prie jo vienaip ar kitaip prisideda daugybę žmonių, tačiau svetainių savininkai nė už ką nenori išduoti pavardžių kas prisidėjo dėl vienų ar kitų priežasčių. Aišku, dažnai žmonės samdo įmones, kuriose dizaineriai ir programuotojai “iškepa” visą projektą, o svetainės savininkas dažniausiai būna matęs vos vieną projektų vadovą, o kas vyko kol buvo darbas padarytas - jis nežino. Tačiau tai galima labai lengvai išspręsti! Sukūrus svetainėje humans.txt failą ir jame visa tai surašius. Tokio failo turinys gali būti rašomas kaip Jums patinka. O štai tokį pavyzdį pateikia humanstxt.org svetainė. Tiesa, nors nebūtina, tačiau galima į savo svetainės HTML kodą įrašyti ir specialų <link> tag’ą: <link type="text/plain" rel="author" href="http://domain/humans.txt" /> Tad prisidėjęs prie šios akcijos noriu paskatinti ir kitus prisijungti. Kodėl gi ne? Juk tai greitas, patogus, netrukdantis paieškų sistemoms, būdas aprašyti visus pagalbininkus. O ką Jūs manote apie šią idėją? Ir galbūt jau prisidėjote? :)

13 priežasčių pasirinkti Gimp vietoje Photoshop

Diskusija kas geriau - Gimp ar Photoshop - begalinė. Nors Photoshop pasaulyje gerokai populiaresnė programinė įranga, tačiau Linux operacinėse sistemose numeris vienas - Gimp. Photoshop visada siūlė daugiau galimybių, nes ji yra brangi komercinė programinė įranga, tačiau verta paminėti 13 priežasčių, dėl kol kartais pasirinkti Gimp yra vertingiau. 1. Standartinės redagavimo galimybės vienodos Tiek Photoshop, tiek Gimp nuotraukoms valdyti siūlo vienodas standartines nuotraukų redagavimo galimybes: nuotraukų pasukimus, atspalvius, karpymą, įrankius piešimui ir kita. Iš to seka išvada, kad su Gimp galima padaryti lygiai tą patį ką ir su Photoshop, tol, kol nuotraukoms neatliekamas sudėtingesnis nuotraukų redagavimas. Žinoma, tikrai negalima sakyti, kad Gimp daug ko nesugeba. Ši programinė įranga tikrai turi daug galimybių ir papildymų. 2. Ar jums tikrai reikia sudėtingesnių įrankių? Ir visgi, jeigu Jūs nesate dizaineris ir neuždirbate iš to duonos, tuomet sudėtingų galimybių, filtrų ir papildinių kuriuos rasite Photoshop programoje - Jums nereikia. 3. Programinės įrangos dydis Photoshop programa užima daug. Tiksliau tariant, ją parsisiųsti, teks atsisiųsti bent vieną kompaktinio disko dydžio failą (700 MB)! O Gimp vos iki 20 MB, tad ją parsisiųsite kur kas greičiau. Verta pastebėti, kad siunčiantis Photoshop nelegaliai galima užkrėsti savo kompiuterį bebandant atsisiųsti serijinius numerius (juk mes visi žinome, kad Lietuvoje piratavimas yra populiarus). 4. Sistemos reikalavimai Photoshop programinei įrangai reikia daug resursų, todėl net ir nenaudodami daug Photoshop galimybių ant “silpnesnio” kompiuterio galite pajusti, jog sistemai neužtenka resursų ir programa veiks lėtai arba kartais “lūžinės”. Su Gimp to nebus, resursų ryja jis tikrai nedaug. 5. Vieta diske Gimp užims iki 20 MB, o Photoshop programai reikės 1 GB vietos diske ir dar beveik tiek pat instaliacijos metu, kol bus kopijuojami failai. 6. RAM Gimp užtenka turėti vos 128 MB RAM’o. Tad net ir ant labai seno kompiuterio, ši programinė įranga turėtų veikti be problemų. O Photoshop reikalauja net 1 GB RAM! 7. Platformos Gimp galima pasileisti daugelyje operacinių sistemų. Photoshop - tik dvejose: Windows ir Mac OS. 8. Portatyvumas Gimp yra kompaktiškas ir gali būti lengvai įrašytas į USB. 9. Failų palaikymas Su Gimp lengvai atidarysite ir redaguosite PSD plėtinio failus. Su Photoshop XCF failų neatidarysite. 10. GUI pasitobulinimas pagal poreikius Gimp gali būti įvairiai pertvarkytas. Perstumdžius mygtukus, susidėliojus sparčiuosius klavišus Gimp galima padaryti minimalistinį (jeigu juo nori naudotis nepatyręs kompiuterių naudotojas) arba vienas prie vieno kaip Photoshop! 11. Palaikymas Priešingai nei Photoshop, Gimp suradus klaidą ir apie ją pranešus, ji bus pataisyta vos ne akimirksniu. Kadangi programuotojų daug, programinė įranga yra atviro kodo, o ir irc kanalų pilna kur galite sulaukti pagalbos. 12. Pastoviai tobulėjanti Tiek Gimp, tiek Photoshop pastoviai stipriai tobulėja. Jeigu kažkokios galimybės nėra naujausiame Photoshop leidime, ji tikriausiai bus sekančiame Gimp leidime. 13. Kaina Kiek kainuoja Photoshop’as reikėtų žiūrėti oficialioje kūrėjų saite - Adobe produktų puslapyje Informacija šiame straipsnyje paimta iš Ayesha Ahmed tinklaraščio, išversta bei truputį pakeista.

Vienas CSS ir JS failas visame projekte

Esu matęs ne vieną projektą (ir tiesą pasakius ne vieną tokį daręs) kuriame CSS ir JS (JavaScript) failų yra kartais net per daug. Arba jie užima per daug. Jau baigėsi tie laikai, kada IT tinklaraščiai mirgėte mirgėdavo visokiomis temomis kaip kad: “vienas puslapis su HTML, CSS ir JS failais turėtų užimti iki 30 KB” ir pan. Tinklapiai jau pasiekė tokius laikus, kad parodyti vien paprastą HTML puslapį su geru turiniu kartais neužtenka. To pasekoje kartais nukenčia vartotojai ir svetainės savininkas. Savininkas nukenčia nereikalingu serverio apkrovimu. Kuo mažiau klientai padaro request’ų, tuo didesnį lankytojų srautą svetainė galėtų atlaikyti, tad reklamos kompanijos mažiau pakenktų atėjusiems klientams, kai dėl serverio apkrovimo svetainės tampa nepasiekiamos. Visi tikriausiai žinome bent kelis tokius projektus kurie reklamos dėka negalėjo “aptarnauti” atėjusių lankytojų. Štai du pavyzdžiai: Abiturientus pravirkdė apkrovos neatlaikę LAMA BPO serveriai Visuotinis gyventojų surašymas stringa nuo pirmos dienos Rašydamas straipsnį “užmečiau” akį į esurasymas2011.stat.gov.lt svetainę (jeigu skaitėte nuorodas aukščiau, tai ši svetainė yra viena iš aprašytų) kurios HTML kode panaudoti resursai truputį nustebino: 9 CSS failai. 16 JS failų. Daugokai. Laimei, naršyklės vartotojus “saugo” ir dažniausiai nesiunčia šių failų kiekvieno puslapio atidarymo metu. Tačiau faktas, kad svetainė būtų atlaikiusi truputį daugiau jeigu 25 failus būtų pakeitusi 2 failais. Tačiau žinoma, ne visada tai supranta tiek programuotojai, tiek patys klientai, kurie pirko prekę (web projektą). Ir aišku nei vieni, nei kiti, tikriausiai apie tai net nepagalvojo. Tad šiame straipsnyje papasakosiu apie Django paketą pavadinimu django-compress. Jo pagalba savo Django svetainėse galima naudoti tik vieną JS ir CSS failą ir taip taupyti tiek naršytojų laiką tiek savo hostingo kainą. Paketas gali būti parsisiunčiamas per buildout’ą į eggs įrašius: eggs = django-compress Tie, kurie nenaudoja buildout’o (tikrai verta, pamėginkit) galima jį parsisiųsti į pypi.python.org svetainės: pip install django-compress Įsirašykite compress į savo projekto settings.py failą: INSTALLED_APPS += ('compress',) Ir paketas sėkmingai veiks Jūsų projekte. Dabar tik reikia nurodyti CSS ir JS grupes, suspaudimo lygį savo nustatymuose (tame pačiame projekto settings.py faile): COMPRESS = True COMPRESS_VERSION = True COMPRESS_CSS = &#123; 'grupė': &#123; 'source_filenames': ('css/style.css', 'css/pagination.css', 'css/calendar.css', 'css/forum.css', 'css/gallery.css', ), 'output_filename': 'c/main.css', &#125;, &#125; Daugiau apie konfigūracines reikšmes galite paskaityti šioje nuorodoje. Lygiai tokiu pačiu principu pasidarome ir JavaScript failų grupes. Savo šablonuose, kuriuose anksčiau rašėte tiesioginius adresus į CSS ir JS failus pakeiskite šiomis šablono žymėmis (template tags): &#123;% compressed_css 'grupė' %&#125; &#123;% compressed_js 'grupė' %&#125; Ar jau spėjote pasinaudoti django-compress paketu? Gal radote geresnę alternatyvą (galbūt net ne Django framework’ui)? Pasidalinkite :)

Knyga Laisvieji informaciniai sprendimai

Per Ubuntu release party vienas iš Romerio universiteto dėstytojų (Mykolas) papasakojo apie knygą, kurią pats ir su dar vienu autoriumi parašė: “Laisvieji informaciniai sprendimai”. Tiesą pasakius mane nustebino tokia iniciatyva išleisti knygą ir jos skaitmeninį formatą tiek pdf tiek odt… Viešai ir be jokio užmokesčio. Tiesa, knyga pati nėra nemokama, tik elektroninis variantas (savaime aišku, kodėl). Nesu girdėjęs, kad Lietuvoje kas nors yra padaręs panašaus (tačiau, žinoma, galiu ir klysti). Taigi, kai tik baigiau skaityti Timo Feriso “4 valandų darbo savaitė” iškart ėmiausi šios knygos. Apie ją labai trumpai norėčiau papasakoti ir tiems, kas domisi atviru kodu (arba tik Linux’ais – apie juos knygoje daug parašyta) rekomenduoju perskaityti. Knyga laisvai platinama skaitmeniniu formatu ir surinkus per Google pavadinimą galima rasti ir atsisiųsti. Taip ir aš padariau šiuo adresu: Laisvieji informaciniai sprendimai Kaip supratau, knyga labiau orientuota į studentus, nes kiekvieno skyriaus pabaigoje pateikiamos užduotys iš perskaityto skyriaus. Tiesa, aš skaičiau savo malonumui ir ką įsiminiau, tą įsiminiau – užduočių nesprendžiau :) Kadangi knyga didelė (~280 psl) tai tikrai nebėgsiu per turinį ir trumpai nemėginsiu papasakoti apie ką joje rašo (geriau perskaitykite patys). Pateiksiu tik kelis dalykus, kurie mane labiausiai sudomino ir “užkabino”. Anksčiau atidaręs GNU tinklapį (www.gnu.org) manydavau, kad frazė “Free software” reiškia “Nemokama programinė įranga”. Žinojau, kad šios įrangos išeities kodai viešai platinami (ir taip pat – nemokamai). Tačiau angliškas žodis “free” reiškia ne nemokamą, bet “laisvą programinę įrangą”. Knygoje tas paminėta ne kartą ir, manau, ne be reikalo. Kaip susidūriau gyvenime – tikrai yra žmonių kurie mano jog: atviras kodas = nemokama programinė įranga Bet tai nebūtinai tiesa. Kad atviras, nebūtinai nemokamas. Ir atvirkščiai: nemokamas nebūtinai atviras kodas. O seniau ir aš painiojau žodį “free”. Programinės įrangos licencijos, jų atsiradimai ir faktai susiję su jomis – man be galo įdomi tema. Taip pat ši knyga, turbūt pirmoji Lietuvoje, kurioje licencijos kodas pateikiamas… Knygos pabaigoje atspausdintu anglišku tekstu! Iki šiol esu matęs taip darant programinės įrangos kode, LICENSE failuose, bet ne knygoje! Sveikintina iniciatyva. Na, o kiek valstybių yra pastūmėjusios atvirą kodą į savo privačius ir viešuosius sektorius… Ir kaip to velniškai bijo Microsoft kompanija – buvo juokinga skaityti, nors tai grynų gryniausia tiesa. O ar žinojote, kad Miunchenas gavo pasiūlymą už 14 tūkstančių kompiuterių aprūpinimą operacine sistema ir biuro programine įranga iš Microsoft už 37 mln. dolerių? Bet kai miestas apsisprendė pereiti prie atviro kodo Microsoft suteikė net 35% nuolaidą ir pasiūlė viską už 24 mln. dolerių padaryti ką žadėjo anksčiau. Tačiau Miunchenas atsisakė priimti Microsoft įrangą ir atviro kodo įranga kainavo 36 mln. dolerių, tačiau Miunchenas tuo netgi džiaugėsi? Kodėl? Sužinosite perskaitę :) Nors čia paminėjau konkretų miestą, tačiau knygoje buvo daug kalbama apie šalis kurios savo vyriausybėse (ir ne tik) priimė atviro kodo sprendimus ir manau tikrai nesigailėjo. Na, ir praktiškai kiekvienu atveju minimas… Microsoft :) Esate įmonės direktorius ir norte aprūpinti darbuotojus Windows operacinėmis sistemos, antivirusinėmis, Office biuro įranga? Gal geriau dar kartą pagalvokite ir paskaitykite skyrių apie tai. Konkrečios lietuviškos sumos ir palyginimai su atviro kodo (dažniausiai nemokama, bet tikrai ne visada) įranga. Tiesą pasakius – skaičiai pribloškė. Taip pat dar viena arši tema pasaulyje – programinių įrangų patentai – aptarti šioje knygoje. Šiuo metu patentų problemos yra tokios dažnos, kad ir čia svarbu žinoti kas ir kur ir taip save apsaugoti. Paskaitykite, tikrai įdomu. O tu jau perskaitei šią knygą? Jeigu taip, pasidalink mintim, o jei ne, migam į biblioteką! O jeigu kas perskaitė, pasidalinkite komentarais :)

VIM kaip skaičiuoklė

Ne kartą yra tekę su VIM’u atidarinėti įvairius ne tik programavimui skirtus failus, bet ir CSV, XML ir kitus dokumentus, kuriuose būdavo tekstai su įvairiais skaičiais, sumomis, kiekiais, PVM’ais. Taip pat ir iš interneto atsiųstas HTML ataskaitas, kuriose kartais tam tikrus duomenis tekdavo pačiam paskaičiuoti. Dažnai tokius dokumentus sunku įkelti į Excel/Spreadsheet programas, ir ten dar kartą perskaičiuoti, palyginti skaičius. Tad vieną dieną pasidomėjau ar pats VIM’as neturi tokių skaičiavimų galimybių tiesiog rašyti lygtis ir gauti atsakymus. Ir pasirodo turi! Labai paprastus ir nesudėtingus skaičiavimus galima padaryti su VIM rašymo režime (insert mode) paspaudus Control+R ir = simbolį. Tuomet galima įvesti nesudėtingą lygtį ir VIM’as parodys atsakymą (pvz 20+180*2 parašys į kursioriaus poziciją atsakymą 380). Tačiau tokie skaičiavimai per daug paprasti ir kartais sudėtingesnėms operacijoms to neužtenka. Tačiau sudėtingesniems skaičiavimams panaudosime VIM’ą ir bc komandą. Prieš pradedant, pasitikrinkite, ar tikrai pas jus instaliuota bc programa (bc – An arbitrary precision calculator language). Su ja galima paskaičiuoti labai tiksliai po kablelio, jeigu reikia, žinoma. Ubuntu operacinėje instaliuoti galite pasinaudoję “Ubuntu Software Center” arba komandinėje eilutėje parašę: apt-get install bc Pirmiausia pradėkime nuo paprasto uždavinuko kaip ir prieš tai turėjome (tik kitais skaičiais): (2 * 250) + 100 Pažymėkime su ‘v’ komanda visą operaciją ir paspauskite ‘!bc’. Tuomet pažymėtas tekstas bus perduotas į bc komandą kuri grąžins mums atsakymą vietoje pažymėto teksto: 600 Internete taip pat esu radęs labai įdomią komandą, kuri gali suskaičiuoti visą eilutę ir parašyti atsakymą nieko nepažymint ir po lygybės ženklo (šią komandą įveskite VIM redaktoriuje): map gbc yypkA = <Esc>jOscale=2<Esc>:.,+1!bc<CR>kJ Tarkime turime: 10 + 20 + 30 + 40 + 50 Kursorių palikite bet kur eilutėje kurioje norite atlikti skaičiavimus ir paspauskite ESC klavišą, dvitaškį ir gbc. Jums iš kart bus duotas rezultatas: 10 + 20 + 30 + 40 + 50 = 150 Mano duoti pavyzdžiai yra patys paprasčiausi. Šios komandos gali suskaičiuoti daug rimtesnius uždavinius: 2 * sqrt (2) = 2.82 3 * (2 - 1) + 4.0 ^ 6 = 4099.00 4 / 3 = 1.33 3 + 4 - 2 * (1 / (3 + 2)) = 6.60 Kadangi net pačiame programavime tenka milijonus kartų atsidaryti skaičiuoklę, tai manau man ir tiems kurie programuoja su VIM’u naudinga žinoti, kaip išsisukti be jos.

Kokias programas naudoju

Tik vakar instaliavau Ubuntu 10.10 Beta versiją ir nustebintas tobulos operacinės sistemos funkcionalumu ir naujomis galimybėmis, nusprendžiau pasidalinti kokias programas naudoju šioje operacinėje sistemoje. Jau tapo jau tradicija: blogeriai kurie rašo apie IT labai dažnai paskelbia savo naudojamų programų sąrašą. Ši informacija man yra ne kartą pravertusi. Kartais perskaitęs tokį straipsnį nusprendžiu pasimėginti ką nors naujo, o taip atrandu ką nors naudingo. Visa mano aprašyta naudojama programinė įranga yra nemokama ir dauguma jų – atviro kodo. Programavimas Pirmiausiai pradėsiu nuo programavimo įrankių. Kadangi pats esu programuotojas, tad ši tema man aktualiausia. Po 2 metų Eclipse naudojimo ant Windows XP, po metų Netbeans naudojimo ant Windows Xp ir Ubuntu, apsistojau ties… VIM redaktoriumi. Kodėl? O priežasčių tikrai daug: greita IDE, kaip ir kitos mano išvardintos turi milijonus įskiepių ir taip pat turi standartines funkcijas: sintaksės paryškinimus, failų naršyklę ir pan. Labai didelis privalumas – RAM’o vartojimas. Jeigu programuojate (programavote) su Netbeans ar Eclipse, tai tikrai žinote, kad RAM’o šios IDE naudoja tikrai nemažai. Tačiau VIM’o man didžiausias privalumas – gali pasidaryti tokią IDE, kokią tik nori! Greitieji klavišai (keyboard shortcuts), snippetai, PHP ir Python sintaksės klaidų paryškinimai (šiuo metu tik su PHP ir Python dirbu). Taip pat į akis nelenda nereikalingos meniu juostos, būsenos juosta (status bar) ir šoninis failų medis – visa tai yra Netbeans ir Eclipsee – man tai pasirodė tikrai nereikalinga, tik be reikalo vietą užima. O tai, kad VIM’e yra milijonai greitųjų klavišų, man patiko. Bet to, komandų pakartojimai (kai nuspaudi skaičių kiek kartoti komandą ir po to pačią komandą), man tikrai patiko. Pradedančiajam VIM gali pasirodyti per sudėtingas truputį, tačiau pamėginkite lygiai 2 savaites ir aš Jums garantuoju, į kitą redaktorių žiūrėt nenorėsit :) Anksčiau naudojau Gnome-Terminal (bet jis labai lėtas, ir tas kartais pasijaučia), vėliau perėjau prie Terminator, kuris buvo šiek tiek greitesnis ir labai patiko jo lango skaldymas, į vertikalę ir horizontalę poziciją, režimas. Lėtumas atsirasdavo, kada kurdavau naujus tab’us arba paleisdavau bet kurią iš šių programų. Tuomet kelias sekundes vyksta krovimasis, o laukti net ir tas kelias sekundes taip nesinori. Taip pat, kai renki tekstus, kartais mano rašomas tekstas jausdavosi, kad atsilieka. Na, o dabar naudoju Xterm’ą, kuris yra labai greitas. O programavimą šiuo metu vykdau Screen’e, nes tas privalumas, kad uždarius terminalą gali vėliau vėl lengvai grįžti prie to pačio darbo – tikrai naudingas. Tad tab’ai dabar nereikalingi :) Kartais tenka ką nors greito padaryti su Python. Pavyzdžiui suskaičiuoti kada uždirbsiu milijoną jeigu įdėsiu 100 lt indėlį į Snorą. Tam naudoju labai nerealią programą Dreampie, kuri leidžia parašyti kodą ir iškart jį pavykdyti. Tikrai sutaupo daug laiko negu rašant viską per konsolę. Skirtumams tarp failų arba programų kodo modifikacijoms tikrinti naudoju Meld’ą. Nors Kdiff3’as turi vieną labai didelį pranašumą: geba pats sutvarkyti konfliktus, bet Meld’ą naudoju dėl jo labai gražaus dizaino. Be to, pavykdžius Meld’ą tame kataloge, kur yra repozitorija, jis geba nustatyti kokia tai repozitorija ir parodyti skirtumus kode. Programuojant tenka ne tik rašyti kodą, žiūrėti ką apkaltinti (juk žinot patarlę: jeigu žinai kas kaltas – neišsiduok!) su ‘blame’ komanda bet dar ir koreguoti paveiksliukus. Tam šiuo metu naudoju Gimp’ą. Tiesa, buvo labai gaila po daug perskaitytų knygų ir peržiūrėtų kelių šimtų tutorial’ų apie Photoshop’ą išmesti šias žinias į… niekur. Nors ir buvau suinstaliavęs šią programą į Ubuntu (taip, nelegaliai), bet nebuvo tai tas pats kas ją naudotis Windows aplinkoje. Labai tikiuosi, kad šios programos versija pasirodys ir Linux operacinei sistemai. Kadangi GIMP’ą naudoju tik darbiniams tikslams (būtent programavimui) todėl jį priskiriu programavimo kategorijai. Programų nerašau iš oro. Jeigu yra panaši programa kurią noriu padaryti ir ji atviro kodo, tuomet ją patobulinu ir naudoju. Žinoma, pakeitimus nusiunčiu autoriui, kuris sprendžia jie naudingi ar ne. Tačiau kartais tokių sugalvotų idėjų nebūna padarytų arba jos labai skiriasi nuo mano sugalvotų. Tad, kad darbas vyktų sklandžiai pirmiausia viską planuoju. Pirmiausia pradedu su Dia paišyti Usage Case diagramas, o darbus susirašau Gnome Planner programoje (ją naudoju jau kelis metus). Seniau naudojau Excel’į, bet kai radau tam skirtas programas, planavimai pasidarė ne tik greitesni, bet ir malonesni. Kiek trunka programavimo darbai – seku su Hamster. Tikrai įdomu žinoti savo programavimo tempą. Duomenų bazei valdyti šiuo metu kolegos supažindintas naudoju SqlBuddy. Kodėl nenaudoju PhpMyAdmin? Todėl, kad šios programinės įrangos programuotojai jau visiškai “nusivažiavo”. Bandymas padaryti PhpMyAdmin greitą, su AJAX valdymu ir jQuery Dialog – užmušė visą norą naudotis šia programa. Tikra tragedija dabartinė naujausia versija: neskaitant, kad yra daug klaidų pačioje sistemoje (ne visada veikia pažymėjimai, trynimas arba rodo ne visus įrašus) tai dar žiaurios klaidos atsiranda dizaino pusėje kurios trukdo naudotis. Pavyzdžiui vos prieš du mėnesius buvo atsiradusi problema, jog negalima buvo paspausti checkbox’ų, todėl negalima buvo ištrinti jokių įrašų juos pažymėjus… Reziume: apsistojau šiuo metu ties SqlBuddy. Labai greitas, dizainas tikrai puikus, nors ir minimalistinis. Funkcionalumo turi mažiau nei PhpMyAdmin, bet bent jau kol kas turi būtent tai ko reikia. Eksportavimus ir importavimus darau su mysqldump programa. Duomenų bazei valdyti taip pat esu naudojęs Mysql Administrator. Nors priekaištų jai neturiu, tačiau ši programa tinka tik asmeniniame kompiuteryje naudotis. Į serverį jos neįkelsi ir per naršyklę neparodysi :) Kartais tenka nušokti nuo darbo ir mesti viską. Ir pavyzdžiui lieka dar nebaigtas SQL’as, ką tuomet? Tuomet pasinaudoju Tomboy programa. Įrašau savo darbą ir ramiai galiu eiti kur reikia. Finansai Finansams daugiau nei pusmetį naudojau GnuCash. Viskas šioje programoje yra gerai. Tiesa, tik pradėjus naudotis teko perskaityti nemažą tutorial’ą, nes ne tokia jinai ten paprasta. Bet buvo verta, idėja tikrai nuostabi. Tačiau vieną dieną išbandžiau visai neseniai sukurtą wxBanker ir nusprendžiau migruoti dėl jos paprastumo ir patogumo. Tam, kad užsikrautų GnuCash ir viską suvestum reikia nemažai laiko. O wxBanker ne tik veikia labai greitai, bet ir įvedimas duomenų yra labai paprastas. Paštas Anksčiau naudojau Evolution. Bet jo viena klaida mane labai erzino daugiau nei metus: trumpam dingus internetui tekdavo slaptažodžius per naujo suvesti visoms pašto dėžutėms. Ir nors buvo nuspausta “Remember password”, tačiau slaptažodžių vistiek reikalavo. Turint 6 pašto dėžutes, tai buvo didžiulė kančia. Šiuo metu naudoju Claws Mail. Nors ši programa taip pat turi savo minusų, tačiau man jie neatrodo tokie dideli. Pavyzdžiui skaitant laišką jeigu bus tikrinamos pašto dėžutės tuo metu, tai permeta ant pirmo laiško pirmoje dėžutėje. Privalumas ir tas programos, kad jeigu turi kelis vieno serviso el. pašto dėžutes (pvz gmail) tai gali susikurti vieną, susikonfigūruoti pilnai ir kai norėsi sukurti kitą, tiesiog galima paspausti “Copy” mygtuką ir jis sukurs antrą paskyrą / profilį. Telieka pasikeisti slaptažodžius ir vualia! Privatumas Jeigu užsiminiau apie slaptažodžius, tai jau gal 4 metus naudoju KeepassX, ir nusiskundimų nuturiu. Nelegaliai įrangai laikyti (šiuo metu jos jau nebeturiu) naudojau Cryptkeeper. Jeigu kam reikia, siūlau pasinaudoti šia programa. Jinai yra tokia minimalistinė, kad su TrueCrypt nėra ką lyginti. Bet tikrai gera. Produktyvumas Naudoju Parcellite, kuris saugo visus tekstus kuriuos kopijuoju. Kasdien to reikia, tad ši programa daug laiko man sutaupo. Apie Hamster – rašiau aukščiau. Naršyklės Naudoju Firefox (o kur gi dar patikrinsi savo Python ir/arba PHP parašytas svetaines?), Opera (gera naršyklė svetainėms su galerijomis), Chrome (paštui). Dažniausiai naudoju Firefox, dėl programavimo įrankių. O nenaudoju Internet Explorer, nes šioje operacinėje sistemoje tokios padarytos klaidos nėra :) Biuras Tekstams ir pateiktims naudoju senąjį gerąjį Open Offfice. Programų, su gettext, vertimui naudoju Poedit. Tikrai geriau negu versti su tekstų redaktoriumi, nes Poedit programoje gali susikurti vertimų duomenų bazę kuri pasiūlys naujai verčiamą tekstą išversti pagal vertimų duomenų bazę. Sutaupo laiko, tikrai verta išmėginti jeigu dar nenaudojate. Media Muzika groja su Banshee. Esu bandęs Amarok ir Rythmbox, bet Banshee pasirodė patogiausias ir greičiausias. Ir įskiepiai kurie „ateina“ iškart įdiegus man patiko. Bei Equalizer’į turi. Filmus žiūriu per VLC. Nes garsą galima iki 300% padidinti. Ant nešiojamo kompiuterio būtinas funkcionalumas. Be to greitas, turi minimalistinį režimą ir turi nemažai konfigūracijų. CD ir DVD Informacijai į kompaktinius diskus įrašyti naudoju GnomeBaker. Naudojau Brasero labai neilgai, nes nuolat gadindavo kompaktinius diskus. Įrašinėjant pakibdavo, arba parašydavo, kad negalima įrašyti proceso eigoje. Su GnomeBakar tokių problemų kol kas nebuvo. Operacinės sistemos išvaizda Naudoju Elegant temą. Mano motyvuojantis ekrano logotipas. Ubuntu nustatymams tvarkyti pasinaudoju Ubuntu Tweak. Nereali programa su nemažai konfigūracijų. Tikiuosi ateityje sąrašas dar išsiplės. Šitoks tikrai nedidelis programų sąrašas manau padaro darbą daug produktyvesnį.

Glaudink CSS failus su CSStidy

CSS failai neatsiejami kiekviename tinklapyje. Jų puslapių peržiūros metu vartotojai atsiunčia labai daug. Dažniausiai naršyklės juos kešuoja, bet ne visos, kai kurios to nedaro. Kiekvienas naujas vartotojas užsukęs į tinklapį iškart gauna “porciją” CSS failų (pakankamai dažnai jų puslapyje būna ne vienas). Tad daug atsiunčiamų tokių failų yra bereikalingas Jūsų serverio srauto ir resursų naudojimas. Tikrai ne viena kompanija siūlo įvairių būdų šiems resursams sumažinti, bet apie juos dabar nekalbėsiu. Pakalbėsiu apie CSStidy. Atviro kodo programą, kurią galima naudoti bet kurioje operacinėje sistemoje. Nors jos paskirtis tvarkyti CSS failo turinį pašalinant nereikalingu aprašus, tačiau ji atlieka daug daugiau nei panašaus pobūdžio programos: Spalvų pavadinimus paverčia į šešioliktaines išraiškas (spalva “red” tampa #FF0000). Pašalina nereikalingus ir save perrašančius dublikatus. Pagal kompresijos lygį šalina tarpus ir tuščias eilutes. Trumpina aprašus, pavyzdžiui “padding: 10px 10px 10px 10px” tampa “padding:10px”. Trumpina spalvų kodus: #000000 tampa #000. Na, pirmiausia tai tikriausiai turėtumėte pradėti nuo šios programos įdiegimo. Ubuntu operacinėje sistemoje (o taip, aš jos mylėtojas) tai galite padaryti taip: csstidy css/style.css css/style_optimized.css Jeigu nenaudojate šios operacinės sistemos, parsisiųskite programos versiją iš sourceforge.net svetainės. Yra *.exe failas (kaip matote, Windows vartotojai tikrai neužmiršti). Kas įdomiausia, kad CSStidy parašytas dviem kalbomis: PHP ir C++. Kadangi Lietuvoje labai daug PHP fanų, tai galbūt atsiras norinčių padėti šiai programinei įrangai vystytis :) Trumpai parodysiu, kaip programa naudotis terminale. Komandos pavyzdys: csstidy css/style.css css/style_optimized.css Čia css/style_optimized.css yra failas, į kurį bus išsaugotas naujas CSS failas. Tiesa, keli naudingi parametrai šiai komandai (jie rašomi po failų vardų): —sort\_properties=true|false ir —sort\_selectors=true|false: gražiai išrikiuos CSS kodą pagal abėcėlę. Jeigu CSS nėra blokais aprašytas (pavyzdžiui: tam tikra sekcija CSS kodo aprašo viršutinę puslapio dalį (angl. header), kitas CSS blokas aprašo kokią nors kitą puslapio dalį) tai šie parametrai turėtų būti įjungti. —compress\_colors=true|false: nors tai daroma automatiškai, tačiau verta žinoti, kad su šia komanda suglaudinami spalvų aprašai. —preserve\_css=true|false: pavojingas parametras, nes jis šalina komentarus ir dažniausiai naudojamus “hackus” naršyklėms. Štai pavyzdys terminale kaip vesti parametrus (skirta tiems, kas tikrai nežino): csstidy css/style.css css/style_optimized.css --compress_colors=true Oficiali svetainė CSStidy projekto: csstidy.sourceforge.net

Visos sistemos atsarginės kopijos darymas

Pastoviai daryti atsargines kopijas yra atsakingų ir protingų žmonių darbas. Tikrai ne visi, kiek man teko susidurti, daro visos sistemos (savo failų + operacinės sistemos konfigūracijų) atsargines kopijas. O kodėl derėtų daryti atsargines kopijas operacinės sistemos konfigūracinių failų? Todėl, kad kada nors galite ką nors sugadinti instaliavę naują programą ar keičiant kai kuriuos nustatymus. Pvz viena iš tokių kritinių vietų yra X nustatymai. Todėl šiame straipsnyje pateiksiu savo rekomenduojamą būdą kaip tokias kopijas pasidaryti. Praktiškai visada naudoju vos vieną komandą kuri paleidžiama kas tam tikrą laiko tarpą (dažniausiai kas naktį): tar -cvpzf backup.tar.gz \ -–exclude=/backup.tar.gz \ --exclude=/proc \ --exclude=/lost+found \ --exclude=/sys \ --exclude=/mnt --exclude=/media \ --exclude=/dev \ / Kaip matote, be archyvuojamo failo vardo (failų archyvavimas nepavyks, jeigu archyvuojamas failo vardas bus nukreiptas į tą pačią direktoriją kuri ir bandoma archyvuoti) nearchyvuoju dar kai kurių katalogų, nes: /proc katalogas skirtas procesų informacijai saugoti. Kadangi ji pastoviai kinta, todėl jos nearchyvuojame. /lost+found katalogas kuriame saugomi failai rasti sistemos tikrinimo metu./sys katalogas skirtas informacijai apie pačią sistemą laikyti. /mnt katalogas skirtas laikyti failams, kurie riša kitas failų sistemas. /media katalogas skirtas laikyti failams, kurie riša medias: CD diskus, USB, video kamera ir pan. /dev katalogas skirtas tvarkyklėms saugoti. Taigi, paleidžiame komandą, ilgai palaukime ir būkime ramūs dėl atsarginės kopijos. Šiek tiek apie panaudotus komandinės eilutės argumentus: -c sukurti archyvą -v spausdinti archyvuojamų failų sąrašą. -p išsaugoti informaciją apie failų autorius ir failų skaitymo, rašymo ir paleidimo teises. -z archyvuoja per gzip komandą.-f nurodymas archyvuoti į failą. Atsarginės kopijos atstatymui pasinaudokite komanda: tar -xvf backup.tar.gz -C / Argumentas -C reiškia, kad nesvarbu kokiame kataloge yra pats archyvas, viskas bus išpakuojama į aukščiausią direktoriją. Na, o kitame straipsnyje papasakosiu kaip atsargines kopijas pasidaryti GUI (desktopinių programų) pagalba. Tačiau tai bus labiau apie asmeninių failų atsarginių kopijų saugojimą (aišku, drąsiai galima naudoti ir operacinės sistemos kopijoms).

Įspūdžiai perskaičius Pro GIT knygą

Neseniai baigiau skaityti knygą “Pro Git”. Perskaityti rekomenduoju visiems GIT mylėtojams. Kadangi aš vienas iš tų mylėtojų - teko paimti ją į rankas. Nors knyga vadinasi “Pro Git”, tikrai rekomenduoju ją perskaityti net tiems, kas tik planuoja ją kada nors išmokti. Kokios naudos ji man davė ir ką toje knygoje galite rasti aprašysiu plačiau. Knygos el. variantas yra nemokamas, tad nevarkite prie torrent’ų. Elektroninis variantas gali būtų rastas šioje interneto svetainėje. Knygoje nėra vien tik sausas tekstas. Daugybė grafikų, planų ir kitokių grafinių priemonių padės nenuobodžiauti. 1 dalis. Pasakojama iš šalies apie patį GIT, kas tai yra, trumpa versijavimo sistemų istorija, nuo ko viskas prasidėjo. Skirtumai tarp centralizuotų ir decentralizuotų versijavimo sistemų. Pradmenys kaip pasileisti GIT (viskas tikrai labai paprasta). Naudingiausias dalykas pirmos dalies tikriausiai yra tas, kad paaiškinama kaip pradedančiajam galima rasti pagalbą tam tikrose komandose, kas praktikoje tikrai man dar dažnai būna reikalinga. Bei, aišku, nepamiršta tema: kuo ypatingas GIT. 2 dalis. GIT versijavimo sistemos pradmenys. Dalis kurios tikrai negalima praleisti pradedančiajam. Čia pasakojama kaip veikia GIT ir kaip juo reikėtų naudotis. Kaip išsaugoti savo programinės įrangos (ir ne tik) failų versijas, kaip žiūrėti versijavimo istoriją, kaip versijuoti savo programinę įrangą ir pan. 3 dalis. Branch’ų kūrimo ir kas tai yra – dalis. Konfliktų sprendimo variantai ir sudėtingesnės operacijos. Tiesiog būtina perskaityti! 4 dalis. GIT serverio pusėje. Asmeninis serveris gali atstoti repozitorijų saugyklą, tiek viešų, tiek privačių repozitorijų. GitWeb paleidimas (galime pamatyti užėję į git.kernel.org). Bei kitokia serverio programinė įranga be Gitosis (kitų neminiu, geriau pasiskaitykite knygą, tikrai įrangos naudingos yra). 5 dalis. Man buvo pats įdomiausias skyrius – kaip prisijungti prie kitų projektų ir nesugriauti kitų programuotojų versijavimo tvarkos. Kadangi kalba yra apie tai, kaip prisijungti prie pasaulinių atviro kodo projektų ir juos fork’inti arba tiesiog gavus rašymo teises į repozitoriją, tobulinti. 6 dalis. Submoduliai. Dalykas, kurio, tiesą pasakius, nežinojau kol neperskaičiau šios knygos. Submoduliai leidžia turėti projektą, kuriame naudojamos įvairios bibliotekos iš kitų repozitorijų ir pan. Tikrai įdomu, tikimybė, kad praktikoje teks susidurti, gana didelė. 7 dalis. GIT konfigūracija. Pasakojama apie gilesnę konfigūraciją, hooks’us ir pan. Kadangi GIT garsėja savo konfigūracijos galimybių gausa - jokiu būdu nepraleiskite šio skyriaus. 8 dalis. Migravimas į GIT ir kitokių sistemų aprašymas. Įdomu, kad aprašytas migravimas iš SVN, bet ne iš kokio, pavyzdžiui, Mercurial’o (juokauju, nes toks migravimas būtų kelių minučių reikalas, daug panašumų tarp šių sistemų). 9 dalis. Kur GIT viską saugo, bei kokia tvarka, saugo. Labai pravertė skyrelis apie duomenų atstatymą. Kadangi su tuo praktikoje teko susidurti su netyčiniais repozitorijų pagadinimais. Naujos žinios pravertė. Perskaičius knygą turbūt žinosite viską apie šią versijavimo sistemą. Na, o praktiškai susidūrus su problemomis, bent jau žinosite kur ieškoti informacijos, kadangi šis kūrinys kiaurą parą atviras. Tad nepatingėkite sugaišti laiko, gal Jūs irgi “užsikabliuosite” kaip aš :)

Linksmi bash aliasai

Mano kursiokas Arminas pasidalino su manimi labai originalia idėja – pasidaryti linksmus alias’us savo terminalo lange. Tai tikrai gali truputį paskaidrinti rutiną dirbant su terminalu. Kaip tai atrodo, pateikiu žemiau.: alias please='sudo' alias wtf='man' alias dog='cat' Na, o kad prisiversti save naudoti šias juokingas komandas jis pasiūlė dar joms ir plėtinį: alias sudo='echo Polite peoples say - please' alias man="echo You don\'t know this command? Say - wtf" Nežinau, ar jis pats sugalvojo šią idėją, bet originalumą aš užskaitau ;)

Mano repozitorijos

Ne taip seniai pradėjau “žaisti” su atviru kodu, tačiau jau spėjau padaryti nemažai darbų. Nusprendžiau net ir tuos darbus, kur kažkada dariau komerciniams tikslams, paviešinti, taip plėsdamas Lietuvoje stipriai plintančią atviro kodo bendruomenę. Taigi, pasistengsiu truputį papasakoti apie versijavimo sistemas, jų sukeltas problemas, o pabaigai, mano programinės įrangos išeities kodai. Kol kas gyvenime teko išmokti tik tris versijavimo sistemas, tačiau patikėkit, jų per akis: CVS – nepatiko Windows klientas (taip, labai seniai dirbau su Windows) WinCVS, kuris kėlė daugiau bėdų nei davė naudos. Lėta versijavimo sistema, praktikoje net kelis kartus sukėlė rimtų problemų, nes kelis kart kažkaip sugebėjau užrašyti savo pakeitimus taip, kad dingo kitų programuotojų pakeitimai. Patikėkit, to paaiškinti nesugebėjo net ir tas, kas gerai CVS išmanė… GIT – lengva tik kol atlieki nesudėtingus versijavimo reikalus, kai atėjo laikas sudėtingesnėms užduotims – buvo nelengva. Laimei, galima girtis, kad šią sistemą net Kernel’iui naudoja programuotojai. O šiaip – greitumas ir stabilumas ima viršų. Tiesa, jeigu per sudėtinga naudotis šia sistema, galima pasinaudoti Easy GIT programa, kuri palengvina darbą (padaro GIT draugiškesnį). Mercurial – teko išmokti naujame darbe, tačiau visiškai nesiskundžiu. Nėra sudėtinga, lengva mokytis, problemas išspręsti nesunku, stabili sistema. Tiesa, nors parašyta su Python, tačiau API dokumentacija (jeigu bandai parašyti kelis papildomus įskiepius) labai silpna… Na ir dar bonus: vidutinės žinios su SVN ir Bazaar versijavimo sistemomis. Tiesa, su Bazaar labiausiai teko susipažinti per akl.lt svetainės sprintą. Kadangi jau pasinešiau ant šių sistemų, nusprendžiau versijuoti savo kodą ir pateikti jį žmonėms. Šiaip aš esu GIT versijavimo sistemos mėgėjas, todėl GitHub’e repozitoriją turiu gan seniai. Kelis kartus iš neturėjimo ką veikti, buvau pratrynes savo projektus, tačiau greit viską atgal sudėsiu ką esu su PHP ir Python programavęs. Prižadu, daugiau nieko netrinsiu :) Taigi, mano repozitoriją galite pasiekti šiuo adresu: github.com/reekenx Na, daugiau kaip ir neplanuoju turėti repozitorijų, nes šių tikrai užtenka. O keliems privatiems projektams naudoju privačią repozitoriją savo serveryje. Tiesa, jeigu norėsit man pasiūlyti prisidėti prie kokio nors atviro kodo projekto, būtinai parašykit. Domintų projektai su Python, C ir PHP :)

Kodėl tau reikia versijavimo sistemos?

Ne kartą esu susidūręs, kad žmonės savo failus ir katalogus versijuoja taip: Paveikslėlis kurį čia matote yra labai blogo versijavimo pavyzdys. Užduotis Jums: kaip iš failų pavadinimų (bet ne sukūrimo datos) nuspręsti, kuri versija yra prieš paskutinė? Tai humoristinis požiūris į „versijavimą“ kuris tikrai paplitęs pasaulyje. Tačiau net ir tvarkant tik asmeninius failus tai gali privesti prie nesusipratimų. Turėdami bet kurią versijavimo sistemą (GIT, Mercurial, SVN, CVS ar pan.) išvengsite daug nesusipratimų. Versijavimas programuotojams Tikriausiai nerasite IT įmonės tiek Lietuvoje tiek pasaulyje, kuri nenaudotų versijavimo sistemų. IT įmonėms versijavimo poreikis yra labai didelis. Dirbant komandoje Dirbant komandoje būtinai reikia dalintis išeities kodu ar kitais resursais. Dirbant komandoje greičiausiai karts nuo karto reikės pažiūrėt ką vienas ar kitas kolega padarė. Dirbant komandoje kada nors gali prireikti tam tikro kodo gabalo ar kitokio resurso (pavyzdžiui logotipo) ankstesnės versijos. Tai tipiniai poreikiai išsprendžiami versijavimo sistemomis. Dirbant vienam Jeigu dirbate vienas ar prie asmeninių projektų, gali pasirodyti, kad to poreikio visai nėra. Arba, kad versijavimo sistemos naudojimas ir mokymasis ja naudotis gali švaistyti brangų laiką. Taip tikrai nėra. Jums greičiausiai irgi reikia versijavimo sistemos, jeigu prie kažkokio projekto dirbate bent kiek ilgesnį laiką. Greičiausiai Jums nereikia dalintis resursais su kitais, bet gali reikėti tą patį projektą kelti į kitus kompiuterius ar serverius. Jeigu darysite tai tiesiog kopijuojant katalogus, tai anksčiau ar vėliau - neišvengsite susipratimų. Versijavimo sistema gali būti puikus atsarginių kopijų laikymo įrankis. Labai dažna situacija - Jūs atsimenate, kad kažką turėjote prieš kelias savaites ar mėnesius, bet dabar šis dalykas yra pašalintas. Versijavimo sistema saugo visų pakeitimų istorijas, todėl atstatyti turėtų būti nesunku. Nežinote ar turite naujausią projekto versiją? Vėlgi, versijavimo sistema praneš ji yra naujausia ar ne. Verta išmokti Jeigu studijuojate IT (ypatingai programavimą), tai versijavimo sistemos yra vienas svarbiausių įrankių, kuriuos privalote mokėti dar prieš ieškant darbo. O išmokti bus paprasta. Perskaitykit straipsnius GIT kategorijoje ir turėtumėte nesunkiai startuoti.