Konferencijos Lietuvoje’15

Būdamas „high load strategy“ konferencijoje pagalvojau, jog Lietuvoje vis daugėja konferencijų, kuriose verta sudalyvauti:

  • e-komercija
  • RubyConfLt – informacijos apie konferenciją dar nėra, bet @vidmantas informavo, jog ji vyks kovo 21d. Swedbank’e;
  • login
  • big data – per „high load strategy“ anonsavo, jog ši konferencija turėtų vykti gegužės pabaigoje. Belieka sulautki, kol bus atnaujintas puslapis bei pateikta daugiau info;
  • build stuff – brangoka, bet savo kokybe, mano nuomone, geriausia IT konferencija Lietuvoje;
  • no trolls allowed – „kitokio“ tipo konferencija po atviru dangumi ir plataus spektro temomis;
  • agile turas Vilnius|Kaunas

Web Konferencija

Nežinau ar šiais metais ji bus organizuojama (įrašo rašymo metu info dar nebuvo), bet esu susiformavęs gana skeptišką požiūrį į ją.

Pagrindiniai minusai:

  • konferenciją organizuoja studentai – organizavime profesionalumo nelabai galima tikėtis;
  • metai iš metų jos kokybinis lygmuo nekyla – formatas vienodas, pranešėjai tik vietinai (dažnai netgi tie patys);

Per paskutinius keletą metų susikūrė nemažai įvairių usergroups’ų, kurie organizuoja susitikimus ne ką prastesnius negu konferencija (kuri vyksta kartą metuose). Tad 12 meetup’ų (einant tik į vienos specializacijos) tikrai suteiks daugiau info negu 1 konferencija.

Man, kaip web’o atstovui, ši situacija yra gana liūdna. Galimybių pokyčiams, artimiausiu metu, nelabai matau.

Mano matymu yra keli realūs būdai:

  • usergroups.lt – susės, apsitars ir padarys bendrą jungtinę (web)konferenciją, dirbdami aktyviai bei įtraukdami kuo daugiau įmonių (rėmėjų). Tokiu būdų būtų galima padaryti normalią konferenciją, į kurią būtų galima pakviesti užsienio pranešėjų (pagal finansus) ar suorganizuoti workshop’ą (-us) konferencijos metu.
  • NFQ – pradės patys organizuoti konferenciją taip į Lietuvą pasikviesdami ir užsienio pranešėjų. Didžioji tokios konferencijos problema – rėmėjų trūkumas (manau, jog rems tik NFQ). Tad ilgaamžiškumas abejotinas;

Iš kitos pusės, gal poreikio tokio tipo konferencijai nėra?

p.s. tikiu, jog Lietuvoje vyksta ir daugiau konferencijų, kurios aktualios IT žmonėms. Tad, jeigu kurią praleidau – paminėkite komentaruose 😉

Is TDD dead? Reziumė

Prieš kurį laiką programuotojų internetas buvo pilnas pamąstymų apie tai ar TDD yra miręs?

Visa diskusija kilo dėl to, jog @dhh per RailsConf’14 darydamas keynote apie tai prabilo

Kelių dienų bėgyje sekė jo įrašas „TDD is dead. Long live testing“.

Ir po to prasidėjo virtinė įvairių programuotojų internete žinomų žmonių.

Šiam trumpame įraše pateiksiu trumpą suvestinę viso, kas buvo parašyta (kad būtų galima susidaryti įvairių požiūrio kampų).

Viso šito kulminacija tapo @KentBeck, @martinfowler ir @dhh video hangout’as, kuriame jie diskutavo apie TDD principus.

Mane labai sužavėjo įmonės, kurios visame pasauje stebėjo hangout’ą ir po to turėjo įdomias diskusijas ofise.

Ar jūs diskutavote su kolegomis apie tai? Gal žiūrėjote hangout’ą gyvai?

Marcello Duarte – Test, Transform, Refactor

Puikus video apie TDD. Visi pavyzdžiai yra pateikiami naudojant phpspec, bet principai tinka kitiems testavimo framework’ams bei kitoms programavimo kalboms.

Labai patiko išsakytos programavimo „fazės“ kaip kodas virsta algoritmu:

  1. null to constant
  2. constant to constant+
  3. constant to scalar
  4. statement to statements+
  5. unconditional to if
  6. if to while

Pažiūrėkite ir pasisemkite idėjų kaip tvarkingai rašyti kodą.

Git pradmenys

Vienas iš esminių programavimo uždavinių – kodo versijavimas. Mano suvokimu to reikia, nes:

  • išlaikoma kodo pakeitimo istorija su komentarais. Visada galite pasižiūrėti kodėl ir su kokiais pakeitimais pridėjote konkrečią kodą logiką;
  • naują feature’ą galite rašyti naujame branch’e (ar bent jau lokaliai) ir jeigu kažkas eis ne taip – kaip norite arba suvoksite, jog to visai nereikia – bet kada galėsite pakeitimus atstatyti į pradinę versiją (nuo kurios pradėjote);
  • dažna situacija – esu įpusėjęs naują funkcionalumą ir gaunu iš kliento žinutę, jog sistemoje yra bug’as (arba pats jį pastebiu). Tokiu atveju galiu work-in-progress pakeitimus sukelti į atskirą branch’ą ir švarioje pradinėje kopijoje (master branch’e) sutvarkyti bug’ą bei jį sukelti į sistemą;
  • dirbant komandoje su kolegomis dirbame prie to pačio kodo (skirtingo funkcionalumo) ir nuolat tenka apsikeisti kodo pakeitimais. Kodo versijų sistema sutaupo labai labai daug skausmo, nes viską padaro automatiškai. Net nenoriu įsivaizduoti kaip tai atrodytų rankiniu būdu (kažkada universitete tai teko daryti … :/);

Kodėl Git?

Yra keletas populiarių kodo versijavimo sistemų: cvs, svn, git, mercurial. Tad kodėl reikėtų rinktis git? Savo praktikoje esu susidūręs tik su cvs, svn ir git. cvs ir svn yra kitokio tipo versijų sistemos nei git (bet mes ne apie tai dabar), jų pagrindinis minusas – nepatogus darbus su feature’ais (branch’ais). Kadangi jų merge’inimas į esamą kodą yra skausmingas.

Git turi gan nemažą community už jo. Plius yra gerų SaaS įrankių patogiam darbui.

Mokomės

Yra gerų nemokamų resursų apie git’ą. Mano rekomenduojami:

  • http://try.github.io/ – gyvename praktikų amžiuje. Mažai kas iš mūsų nori pradžioje skaityti ilgas dokumentacijas. Dažniau norime iš pirmo pajusti ar tai limpa ir tik tada pradedame gilintis į tai. Šis resursas kaip tik toks. Interaktyvus gidas.
  • http://gitimmersion.com/lab_01.html – labai trumpi ir paprasti tips’ai, kurie padės susikonfiguruoti git nustatymus (git-config) bei supažindins su dažniausiai naudojamomis komandomis.
  • http://git-scm.com/book – rekomenduočiau perskaityti (ar bent jau praversti) visą knygą ir susipažinti su git veikimu iš arčiau. Knyga nėra didelė, bet sudėta informacija – labai naudinga.
  • http://slides.gediminasm.org/being-dangerous-with-git-rebase/#/ – viename iš @VilniusPHP buvo pranešimas apis git. @l3pp4rd labai smagiai papasakojo apie tai kaip galima grupuoti commit žinutes, kad commit’ų istorija neatrodytų: WIP, debug, debug, fix, debug off 🙂

Pritaikome praktikoje

Įgytas žinias reikia kur nors pritaikyti. Mano siūlymas naudoti vieną iš internete esančių SaaS. Labiausiai paplitę yra GitHub bei BitBucket.

GitHub’as yra laikomas pionieriumi ir dauguma OpenSource projektų guli ten.

Pagrindinis BitBucket privalumas – jis turi nemokamas private repozitorijas (juk nenorite, kad jūsų projektas būtų matomas viešai).

Darbo principai tiek vieno tiek kito labai panašūs.

Tiems, kurie taupo pinigus ir vis dar mano, jog pas save saugoti geriau yra  labai neblogų alternatyvų, pvz. GitLab.

Pabaigai

Kai išsirinksite aplinką, kurioje dirbate ir susidėliosite +/- workflow, pagal kurį dirbate, rekomenduoju peržiūrėti Github’o aprašymus ir siūlomus workflow. Įgausite naują požiūrio kampą.

  • GitHubGuides – į Youtube sudėti videos;
  • Guides – trumpi ir labai gerai vizuališkai išreikti darbo principai su git’u bei github’u (ar kitu git SaaS’u, kuris turi panašų UI);

Klausimai?

Rašykite komentaruose. Mielai į juos atsakysiu, praplėsiu esamą įrašą arba parašysiu naują.

MacOSX: laisvos vietos paieškos

Turiu SSD, kietąjį diską, kuriuo labai džiaugiuosi. Tiksliau džiaugiuosi jo performance’u 🙂 Abejoju ar daugiau kada pirksiu kitokį kietąjį diską.

Tik mano SSD yra 128Gb, tad vis tenka susidurti su problema, kai jame pritrūksta vietos 🙂

Į pagalbą ateina DiskWave įrankis. Jo pagalba matau kas suvalvė visą mano vietą.

DiskWave

Mano atveju dažniausios problemos:

  • didelis Spotify cache katalogo dydis. Yep, aš jo klausau all-day long 🙂
  • filmai – peržiūriu, bei nuvylusius trinu (jeigu dar nebūnu ištrynęs), o geresnius perkeliu į išorinį kietąjį diską (HDD);
  • GarageBand – jeigu nedirbate su muzika. Vargu ar jums jo reikia. Ištrynus apps’ą kartu su libais – atlaisvinsite ~4Gb vietos (~3%, mano atveju);

Mažos talpos SSD pirkau ne dėl to, jog buvau skūpas. Tiesiog mac’e laikau tik tą informaciją, kurios reikia realiuoju momentu.  Visa kita info yra arba kur nors cloud’e arba išoriniame HDD. Tad nedidelis SSD padeda palaikyti tvarką 🙂

Gal ir jūs sprendžiate panašias bėdas? Kokie būtų jūsų patarimai? 🙂