Kaip mus visus užknisa tie Windows errorai, iš kurių kartais nieko nepagauni.. Tai išmeta neaiškų klaidos kodą, tai programa tiesiog užlūžta su iššokusiu langu "Send/don't send" - HRRRR. Tačiau į visa tai galima pažiūrėti poetiškai: būtų daug gražiau, jei tie patys klaidų pranešimai būtų parašyti japoniškos poezijos Haiku stiliumi (jei nežinote kas tai yra - nuoroda į Wikipedia). Tokį kiek netikėtą ir šmaikštų pasiūlymą radau puslapyje Authorware.com, pabandžiau išversti ir pasiūlyti Microsoftui lietuviškus klaidų pranešimų trieilius.

* * *

Jūsų ieškomas puslapis
Negali būti rastas, bet
Yra beribė edrvė kitokių.

* * *

Chaosas įsiviešpatavo.
Permąstyk, pasigailėk ir perkrauk.
Tvarka bus.

* * *

Windows NT lūžo.
Aš esu mėlynas mirties ekranas.
Niekas negirdi tavo riksmo.

* * *

Vakar tai veikė.
Šiandien tai neveikia.
Susipažink - tai Windows.

* * *

Lūžimas paverčia
Tavo brangų kompiuterį
Į paprasta akmenį.

* * *

Trys dalykai yra tikri:
Mirtis, mokesčiai ir duomenų praradimas.
Spėk, kuris ką tik įvyko.

* * *

Tu įžengei į sraunią upę,
Bet vanduo nutekėjo toliau.
Tokio puslapio čia nėra.

* * *

Na kaip, patiko? O gal jūs turite ką pasiūlyti? Come on, pasitelkite vaizduotę prieš ilgąjį savaitgalį ir parašykite komentaruose vieną-kitą Haiku trieilį iš klaidos pranešimų serijos. Bus smagu

Šaltinis: Abstruse Goose: How to Teach Yourself Programming

Praeitą mėnesį kompanija Google paskelbė apie tai, kad planuoja testuoti savo naują interneto ryšio tinklą, kurio greitis stulbinantis - 1 GB/sek. Tačiau renkantis vietą testavimui, Google iškėlė reikalavimus, kad tai būtų ne mažiau kaip 50 tūkstančių namų ūkių, o dar geriau būtų - apie 500 tūkstančių. Pasakyta - padaryta. Nedidelis JAV Kanzaso miestelis neaiškiu pavadinimu Topeka padavė savo paraišką. Ir labai originaliai - jie pakeitė miestelio pavadinimą į Google!

Miestelio meras pasirašė oficilaų dokumentą, pagal kurį iki kovo pabaigos miestelis bus vadinamas Google, Kansas. Taip taip, tai ne balandžio pirmos pokštas. Na, be abejo, žiūrint iš teisinės pusės, šis veiksmas nėra legalus, ir teisininkai patarė merui atšaukti savo sprendimą. Tačiau net jei sprendimas ir bus atšauktas, valdžia vis tiek prašo miestelio gyventojų kol kas vadinti jį Google. Viena vertus, tai labai kvailas būdas pritraukti kompanijos dėmesį. Tačiau, kita vertus, kodėl ne - juk laimėjimo atveju miestelio gyventojai gautų tokį internetą, apie kurį likusi Amerika gali tik pasvajoti. Ir ko tik pasaulyje išradingi žmonės neprisigalvoja…

Informacijos šaltinis: Washington Post

Po truputį artėja vasara, kai abiturientai laikys brandos egzaminus ir stos į aukštąsias mokyklas. Nors egzaminai jau turėtų būti pasirinkti, bet manau, kad daug iš dvyliktokų blaškosi ir dar nežino, kur stoti. Tai pabandysiu jiems papasakoti apie programuotojo profesiją. Tiksliau tariant, daug kam programavimas atrodo prestižinis darbas, kur reikia tik galvos ant pečių, ir galima užsikalti milijonų. Tai papasakosiu apie realybę, gal privers būsimus programuotojus susimąstyti, ar jie tikrai nori eiti tuo keliu.

1. Programavimo kalbos - tik aisbergo viršūnė

Daug kam iš šalies atrodo, kad programuojant reikia tiesiog gerai išmanyti vieną ar kitą programavimo kalbą. Galbūt to užtenka atskiriems projektams arba paprastiems atsiskaitymams universitete, bet realiame gyvenime programavimas yra sudėtingesnis procesas. Vienas dalykas, kad reikia mokėti programuoti bent keliomis kalbomis. Ir, prireikus, greitai tarp jų persijungti. Pvz, man kasdien darbe tenka panaudoti Web-technologijas (PHP, JavaScript, CSS, HTML), duomenų bazių valdymo žinias (MySQL, Sybase), ir dar Windows taikomojo programavimo kalbą ir aplinką (C#.NET, Visual Studio). Toliau: reikia mokėti bendrauti su klientu/vadovu, efektyviai dirbti komandoje, planuoti savo laiką, greitai mąstyti, mokėti anglų kalbą informacijos paieškai, o ir mokėti ieškoti tos informacijos. Kartais prireikia ir kitų sričių žinių - matematikos, fizikos ir kt. Vienos programos sukūrimas yra sudėtingas mechanizmas ir tikrai neapsiriboja viena programavimo kalba.

2. Susipažinti su programavimu galima per savaitę, išmokti programuoti - per metus

Knygynuose ir internete galima pamatyti daug knygų iš serijos "Išmokite C++ per 14 dienų". Atrodo graži vizija, ir, perskaičius tą knygą bei sąžiningai atlikus joje parašytus pratimus, tikrai galima sakyti, kad jūs SUSIPAŽINOTE su C++. Bet tik ne išmokote. Mokėjimas programuoti yra ne tada, kai mokate visas konkrečios kalbos konstrukcijas (if, while, begin-end ir kt.), o tada, kai su ta kalba kuriate realius gyvenime panaudojamus produktus arba tinklalapius. Na ir, be abejo, tobulumui nėra ribų, ir tada įsigalioja dėsnis - "Jeigu norite išmokti programuoti, reikia tiesiog daug programuoti".

3. Darbas, darbas, darbas

Dar vienas ne visai teisingas žmonių požiūris - kad programuoti yra labai įdomu, kad tai yra laisva kūryba. Pavydžiu tiems, kurie gali sau leisti taip kurti, pats laisvalaikiu mėgstu suprogramuoti ką nors "sau ar draugams". Tačiau bendrai paėmus, ypač Lietuvoje, programavimas yra sunkus protinis darbas, kai daug valandų iš darbo dienos nueina visai neįdomių funkcijų rašymui, klientų poreikių pildymui (kartais labai nesąmoningų), ir tokioms veikloms, po kurių po darbo išeini iš ofiso ir kompiuterio nesinori akyse matyti.

Dar pamiršau - viršvalandžiai. Kadangi programuotojo darbas negali būti vienareikšmiškai apibrėžtas kažkokiais skaičiais, tai darbdavys gali tai puikiausiai išnaudoti, apkraudamas jus darbais ir pagrįsdamas tuo, kad "man vienodai, kiek tu dirbi, tu gali iš viso nedirbti ar alų gerti, svarbu, kad rezultatai būtų". O su tokiu požiūriu programuotojas po to sėdi vakarais/savaitgaliais…

Bet - ne viskas taip blogai

Na va, lyg ir aprašiau viską tamsiausiomis spalvomis. Išsigandote? Jei ne, tada pirmyn į programavimo pasaulį, tai jums bus geras iššūkis su potencialiai gera darbo vieta neblogu atlyginimu. Taip sakant, jei praeisite tą sunkų kelią iki realios geros darbovietės, tada galite savimi didžiuotis.

Kolegos programuotojai, o gal jūs turite patarimų tiems, kurie tik dabar nori žengti į tą patį pasaulį ir vis dar dvejoja?

Ar jums teko kada priimti į darbą programuotoją? O gal pats buvote dalyvavęs interviu, siekdamas tokio darbo? Jeigu bent viena iš šių medalio pusių jums pažįstama, tai manau, kad bus įdomu paskaityti vertimą iš straipsnio 3 tips to know how good is the candidate you are interviewing, pravers tiek būsimiems programuotojams, tiek personalo valdymo specialistams.

1. Tegul kandidatas nubraižo kokio nors sudėtingesnio projekto schemą

Šis punktas jums padės suvokti programuotojo mąstymo lygį ir sugebėjimą tinkamai projektuoti informacines sistemas.

Paprašykite kandidato nubraižyti ir paaiškinti architektūrą ir veikimo principą iš kokio nors jo praeityje daryto projekto. Tai jums leis užmegsti atvirą dialogą, kartais net diskusiją, kurios pabaigoje galėsite sau atsakyti į klausimus:

a ) Kaip gerai jis paaiškino veikimo procesą?
Viena iš svarbesnių programuotojo savybių yra jo komunikabilumas. Jei jis deramai nesugeba paaiškinti proceso ar išdėstyti žodžiais esminių savo minčių, kaip jį galės suprasti kiti komandos nariai ir kolegos?

b) Ar gera buvo pati projekto architektūra?

c) Ar jis deramai atsakinėjo į jūsų klausimus?
Čia jau panašu į darbo atsiskaitinėjimą universitete. Iš atsakymų į klausimus galima spręsti, ar jis pats yra schemos autorius, ir ar jis sugeba atlaikyti klausimų laviną, ar pasiruošęs improvizuoti atsakydamas.

2. Tegul kandidatas parašo kažkiek programinio kodo

Duokite kandidatui minimalią, bet realistinę užduotėlę ir palikite jį kokiai valandai vieną su kompiuteriu. Grįžkite po kažkiek laiko ir pažiūrėkite rezultatus – tai leis jums pajausti, ar programuotojas sugeba dirbti ir atlikti užduotį realioje aplinkoje.

Čia reikia turėti omenyje keletą dalykų:

a) Leiskite jam koduoti būtent su tomis technologijomis ir su tais įrankiais, kuriuos jis naudos realiai, jeigu bus priimtas į darbą.

b) Nestatykite jo į neįmanomus laiko rėmus. Parinkite daugmaž realias sąlygas, netgi sakyčiau duokite šiek tiek daugiau laiko, negu reikėtų, nes kažkiek minučių gali nueiti veltui vien dėl streso (juk ant kortos pastatyta darbo vieta)

3. Tegul kandidatas paaiškina ir įvertiną kažkieno programinį kodą

Tai jums padės sužinoti, ar kandidatas žino, kas yra geras ir kokybiškas kodas, bei nustatyti, kaip jis sugeba skaityti ir suprasti kažkieno kito parašytą kodą.

Duokite jam nelabai geros kokybės kodo gabaliuką popieriuje ir palikite jį keliolikai minučių viską išanalizuoti. Be abejo, kodas turi būti parašytas ta programavimo kalba, į kurios darbą jis taikosi. O tada užduokite jam keletą klausimų:

a) Kokia yra šio kodo paskirtis, ką jis atlieka?

b) Ką jūs galvojate apie kodą, ar jis „švarus“ ir kokybiškas?

c) Ką jūs norėtumėte pakeisti, kad kodas taptų kokybiškesnis?

—

Tai tokia yra programuotojo darbo interviu vizija iš straipsnio autoriaus. Prie jo žodžių pridėčiau tai, kad pats procesas labai priklauso nuo darbo specifikos, nuo kompanijos masto, nuo galimo atlyginimo dydžio, personalo valdymo kompetencijos ir dar daug faktorių. Šiame straipsnyje aprašytas tik bendras atvejis iš serijos „jei norite savo kompanijai gero programuotojo rimtam projektui“. Ar sutinkate su aukščiau išdėstytomis mintimis?

Originalus straipsnis: 3 tips to know how good is the candidate you are interviewing

Google ir Apple yra ne tik turi savo prekybos ženklus ir įtaką rinkoje, bet ir savo produktų stilių. Abi kompanijos stengiasi, kad jų programomis naudotis būtų lengva, patogu bei intuityviai suprantama. Siekdami to tikslo, programuotojai ir dizaineriai pasiūlo kartais šiek tiek net revoliucinius sprendimus. Pažvelkime į šią situaciją su humoru - štai jums komiksas, labai trumpai aprašantis, kuom skiriasi Google produktai, Apple produktai ir dažniausiai kuriami mažesnių kompanijų produktai.

Štai taip gali atrodyti vienas iš, pavyzdžiui, Microsoft atstovų, siekiantis kuo labiau sumažinti piratavimo lygį ir tam pasitelkiantis DRM technologiją. Bet tai yra tik pirma komikso dalis. Kas gi gaunasi realiame gyvenime tiems žmonėms, kurie iš tikrųjų sumoka už programinę įrangą? Arba, dar įdomiau - įsivaizduokime paauglius, kuriems už žaidimą sumoka tėvai, vaikučiai įsijungia žaidimą ir… žemiau žiūrėkite kitas dvi komikso dalis.

Šaltinis: The Mouse Trap

Daugumoje šiuolaikinių tinklalapių yra bent viena duomenų įvedimo forma. Registracija, prisijungimas, kontaktų forma, anketa, kažkokio objekto įkėlimas į puslapį – visa tai jau tapo įprasta. Tačiau atskiras klausimas programuotojams yra duomenų patikrinimas. Tai yra, ar žmogus viską įvedė teisingai ir pagal taisykles. O kas galvoja tas taisykles? Būtent programuotojai. Tai vat jiems keletas draugiškų patarimų su pavyzdžiais.

1. Kai kuriuose tinklapiuose neįmanoma užsiregistruoti su el.pašto adresu vardas.pavarde@gmail.com arba vardas.pavarde+kazkas@gmail.com, nes programuotojai kažkodėl nusprendė, kad taško ar pliuso adrese būti negali.

2. Kartais vedant pavardę į formą galima susidurti su problemomis, nes kažkodėl, programuotojų manymu, pavardė negali būti trumpesnė už tris simbolius.

3. Nori persiųsti draugui informaciją per formą „Siųsti draugui“? Neskubėk. Nes jeigu tavo draugas turi el.paštą pvz a@***.mp, tai gali ne viskas praeiti sklandžiai. Programuotojams net į galvą neateina, kad pirmoji el.pašto dalis gali susidaryti iš vieno simbolio, o domenas „mp“ realiai egzistuoja.

Na čia bendrai gal kažkiek ir perdėti pavyzdžiai, bet ką aš tuom norėjau pasakyti – kad kartais geriau leisti lankytojui suklysti ir įvesti nesąmonių, o po to tas nesąmones prafiltruoti, negu jį supykdyti ir prarasti potencialų vartotoją/klientą.

Kiekvienas save ir kolegas gerbiantis programuotojas žino, kad kodą reikia komentuoti. Visų pirma, tam, kad jį galėtų suprasti bet koks kitas prisėdęs programuotojas, o dar svarbiau tai, kad po pusės metų savo parašytą kodą galėtum suprasti ir pats. Nes dažnai būna taip, kad atsiverti prieš metus parašytą kodą ir „Emmm… čia aš rašiau? O ką šitas reiškia, o kodėl aš taip parašiau?…“ Bet ne viskas taip gražu su tais komentarais, papasakosiu apie tris komentarų „mitus“, su kuriais susidūriau per gyvenimą.

1. Parašyti komentarą nieko nekainuoja

Daug kas sako kažką panašaus į „Tai negi tau sunku pridėti porą eilučių paaiškinamojo teksto“. Iš esmės, tai tiesa, bet ne šimtu procentu. Juk kad parašytum komentarą, reikia atsitraukti nuo programavimo darbų, o jei projektas yra labai degantis ir būtina jį užbaigti šiandien-ryt-poryt, tai jau ne komentarai galvoje, tada kiekviena minutė svarbi. Vat tokiais momentais ir atsiranda komentarų rašymo kaštai – eikvojamas brangus laikas. Be abejo, viskas priklauso nuo projekto: jei dirba didesnė komanda ir yra tikimybė, kad į jūsų kodą dažnai kas nors žvilgtels, tada gal ir verta sugaišti papildomų minučių net ir degant darbams.

2. Komentarai padaro kodą lengviau suprantamą ir lengviau skaitomą

Tai yra bene labiausiai paplitęs mitas. Nors ir jame yra tiesos. Kai tu žiūri į programos kodą su komentaru ir be komentarų, tai be abejo pirmu atveju galima suprasti daugiau. Tačiau yra ir kita medalio pusė. Pats KODAS turi būti suprantamas ir skaitomas: kintamųjų ir funkcijų vardai, atitraukimai nuo krašto, kodo rašymo stilius ir t.t. Iš viso to ir susideda bendras kodo suprantamumas. Kitais žodžiais, jei pats kodas parašytas tvarkingai – jam dažniausiai nereikia papildomų tekstinių komentarų. O jei programuotojas priprato programuoti stiliumi „ai, bile veiktų ir gerai“, tai tada jau kartais ir tekstiniai komentarai mažai ką padės, vis tiek kiti programuotojai į jo kodą žiūrės su žodžiais WTF.

3. Reikia komentuoti kiekvieną funkciją, metodą, klasę

Čia mitas, kažkiek išplaukiantis iš praeito punkto. Bendru atveju – taip, reikėtų prie kiekvienos funkcijos parašyti, kam ji skirta, ką atlieka, kokius parametrus priima ir ką gražina. Tačiau, mano galva, toks principas galioja tik sudėtingesniems metodams, kurių neįmanoma intuityviai suprasti iš parašyto kodo. Nes dažnai kode tekdavo pamatyti kažką panašaus:

// Funkcija grąžina dviejų skaičių sumą
function Sudeti($x, $y) {
  return $x + $y;
}

Na čia, be abejo, supaprastinau variantą, bet esmė – kad neverta eikvoti laiko komentuojant ir taip aiškius dalykus.

Tai vat tiek pamąstymų trumpai apie komentarus. Gali susidaryti įspūdis, kad aš agituoju iš viso nekomentuoti savo kodo, tačiau priešingai – komentarai yra labai naudingi. Tačiau kaip sakoma, viskam turi būti savo ribos, ir gerbiu tuos programuotojus, kurie sugeba rasti tą ploną liniją tarp nekomentavimo ir per didelio komentarų skaičiaus.

Ne paslaptis, kad dauguma web-programuotojų dirba su technologijomis PHP+MySQL. Jos dažniausiai puikiai tinka smulkesniems ir vidutiniams projektams, tačiau rimtesniems tinklalapiams jų gali neužtekti. Bet vienas garsiausių pastarųjų metų web-projektų Twitter ilgą laiką veikė ant tos pačios MySQL duomenų bazės pagrindo, ir dabar, kai Twitter duomenų kiekiai auga kosminiais greičiais, žengiamas žingsnis prie kitos duomenų apdorojimo sistemos Cassandra. Kas, kaip ir kodėl - viską skaitykite žemiau.

Prasidėjo šurmulys galbūt nuo to, kai Oracle nusipirko Sun'ą, kas kažkiek palietė MySQL duomenų bazių valdymo sistemos ateitį. Ir nors rinkoje buvo kalbama, kad pastarajai sistemai nieko blogo negresia, bet IT pasaulis kažkiek kitaip pradėjo žiūrėti į MySQL. Anksčiau šios sistemos atsisakė tokie gigantai kaip Facebook ir Digg, o dabar atėjo eilė ir Twitteriui.

Kas yra Cassandra?

Cassandra yra sistema, kuri gali veikti dideliuose serverių klasteriuose ir sugeba apdoroti labai didelius duomenų kiekius vienu metu, atlikti rūšiavimą ir filtravimą greitai. Tai yra pavyzdys naujos duomenų saugojimo sistemų kartos, dažnai naudojamos didelėse Web aplikacijose - socialiniuose tinkluose ir kituose tinklalapiuose su šimtais tūkstančių ar milijonais vartotojų.

Cassandra kartu su dar kitokiomis giminingomis sistemomis reprezentuoja taip vadinamą "NoSQL" judėjimą, kuris atsirado 2009 metais ir vadovaujasi filosofija, kad tradicinė ir visiems įprasta SQL kalba netinkama super dideliems informacijos kiekiams apdoroti.

Ryan King, Twiterio specialistas, teigia: "Mes turime labai daug duomenų. Augimo faktorius yra milžiniškas, ir augimo tempai vis greitėja".

Plačiau apie šią naujieną skaitykite: InformationWeek.com: Twitter Drops MySQL For Cassandra