Oracle Magazine’s Developer of the Year

Pēdējos gadus esmu veltījis diezgan daudz laika Ruby on Rails un Oracle integrācijā – tā kā no Oracle puses Ruby netiek īpaši atbalstīts, tad nākas to darīt pašam. Un tā kā Ruby programmētāju kopienā ir izteikta open-source kultūra, tad, protams, arī savu Ruby on Rails Oracle adapteri publicēju kā open-source projektu, kā arī palīdzēju citiem Oracle un Ruby lietotājiem ar padomiem un problēmu risinājumiem.

Biju patīkami pārsteigts, ka mani Oracle paziņas ir novērtējuši šīs aktivitātes un nominēja mani ikgadējajai Oracle Magazine balvai, kas tiek piešķirta dažādās kategorijās. Un tā rezultātā šogad esmu kļuvis par Oracle Magazine’s Developer of the Year

Zemāk var redzēt arī manu bildi un īstu aprakstu no Oracle Magazine pēdējā numura:

Rekomendācijas programmētāju kvalifikācijas darbiem

Šajā nedēļā piedalījos Latvijas Universitātes Datorikas fakultātes programmētāju kvalifikācijas darbu vērtēšanas komisijā – gan recenzēju daudzus darbus, gan arī klausījos un vērtēju klātienē vēl vairāk darbus. Kā jau katru gadu man nepatika vairākas tendences, kas bija sastopamas daudzos darbos, tādēļ gribēju šeit izkratīt sirdi un padalīties ar rekomendācijām, kā vajadzētu labāk rakstīt šos darbus, lai saņemtu labu vērtējumu no manis kā potenciālā vērtētāja

Strādājošs, kvalitatīvs un uzturams programmatūras kods ir primārais mērķis

Kā vienu no pirmajām lietām gribēju uzsvērt šo Agile principu, jo programmēšanas kvalifikācijas darbos galvenais mērķis ir parādīt, ka autors spēj radīt kvalitatīvu programmatūru. Tādēļ:

• Strukturējiet programmatūru saprotamos funkcionālajos moduļos.
• Sadaliet katru moduli nelielās funkcijās vai metodēs – nekādā ziņā viena funkcija vai metode nedrīkst būt pa daudzām lappusēm. Jo tās būs īsākas un saprotamākas, jo labāk.
• Komentāros rakstiet, kāpēc jūs kaut ko dariet, nevis vēlreiz atkārtojiet to, kas redzams kodā.
• Sadaliet biznesa loģiku un attēlošanas loģiku dažādos moduļos (sliktākie piemēri bija, kad vienā failā ir gan PHP, gan SQL, gan HTML, gan Javascript kods sajaukts vienā lielā putrā).
• DRY (Don’t Repeat Yourself) princips – ja kāds kods bieži tiek ar copy-paste dublēts, tad tas nozīmēt, ka šo loģiku vajag izdalīt kādā kopējā funkcijā vai metodē, lai izvairītos no koda dublēšanas.

Vienkārša, saprotama un vajadzīga dokumentācija

Daudzos darbos sliktu kodu centās kompensēt ar lieliem dokumentācijas blāķiem, kas manā vērtējumā darbu var tikai pasliktināt.

• Labāk dokumentāciju rakstiet īsāku un saprotamāku, nevis garu un nesaprotamu.
• Izvairieties no triviālu lietu skaidrošanas un liekvārdības, bet neaizmirstiet paskaidrot lietas, kas ir specifiskas jūsu darbam.
• Arī dokumentācijai ir jābūt DRY – nekopējiet vienus un tos pašus aprakstus uz dažādām dokumentācijas vietām.
• Nemāniet lasītāju, ka vispirms uzrakstījāt visu prasību specifikāciju dokumentu, pēc tam projektējuma aprakstu un tikai tad kodējāt. Ūdenskrituma metode nav vienīgā pieeja – tā ir novecojusi un mūsdienās parasti nepiemērota pieeja. Droši izmantojiet un aprakstiet iteratīvās / inkrementālās / spējās izstrādes pieejas, ja tas ir patiesais veids, kā esat veidojuši savu darbu.

Testējiet ar kodu nevis ar dokumentāciju

Daudziem liekas, ka labākais veids, kā pārliecināt lasītāju, ka viņi ir dikti labi testējuši, ir saproducēt lielu testēšanas dokumentāciju. Bet, manuprāt, liela un sarežģīta testēšanas dokumentācija apliecina tikai to, ka šie testi netika bieži izpildīti.

• Ļoti rekomendēju apgūt jūsu izvēlētās programmēšanas valodas atbilstošo automatīzēto vienībtestēšanas ietvaru. Automatizēti un regulāri izpildīti vienībtesti vienmēr būs labāki nekā gari un manuāli izpildāmi testi.
• Primāri testējiet jūsu darba svarīgāko un potenciāli riskantāko funkcionalitāti, nevis rakstiet daudzus vienkāršus (piemēram, lauku obligātuma pārbaudes) testus.

Drošība

• “Paroļu šifrēšana” nav vienīgā drošības problēma un/vai prasība.
• Ja jūsu programmā ir dažādi lietotāji ar dažādām tiesībām, tad pieejas tiesības ir vienas no primārajām drošības prasībām, kas arī ir jātestē.
• Pirms veidojiet “web” bāzētu sistēmu, iepazīstieties ar biežākajām drošības problēmām “web” bāzētajās sistēmās – sāciet ar SQL injekcijas problēmām.

Konfigurāciju pārvaldība

• Mūsdienās veikt programmatūras koda pārvaldību tikai ar failu rezerves kopēšanas palīdzību profesionālam programmētājam vairs nebūtu pieļaujams.
• Apgūstiet un lietojiet atbilstošus versiju kontroles rīkus, piemēram, Subversion, Git vai citus. Versiju kontroles rīki ir vieni no programmētāju pamatrīkiem.

Darbietilpības novērtēšana

• Darbietilpības novērtēšana ir paredzēta, lai prognozētu potenciālo darbietilpību pirms jūs esat sākuši programmēt sistēmu. Darbietilpības novērtēšana nav paredzēta, lai pamatotu komisijai, ka jūs tiešām esat veltījuši 3 mēnešus darba izstrādei.
• Neizmantojiet sarežģītas COCOMO novērtēšanas metodes, ja jums nav skaidrs, ko tās prognozē un ja jums rezultāti sanāk pavisam savādāki nekā faktiski patērētais darbs. Un netaisnojieties ar to, ka “COCOMO paredzēts lieliem projektiem” – lielie projekti nav nekas tāds briesmīgs, kuros pēkšņi visas vienkāršās lietas ir jātaisa piecreiz sarežģītāk.
• Ja jūs izmantojat iteratīvo / spējo (Agile) pieeju pieeju, tad izmantojiet atbilstošas spējās novērtēšanas tehnikas.

Ceru, ka šīs manas rekomendācijas studenti nākamreiz “uzgooglēs” un ņems tās vērā kvalifikācijas darba izstrādē

Podkāsti programmētājiem

Tā kā ikdienā es daudz laika pavadu automašīnā, tad es cenšos efektīvi izmantot arī šo laiku. Pēdējā laikā visvairāk automašīnā es klausos dažādus podkāstus un tādēļ gribēju padalīties ar informāciju par tiem, kas man liekas interesanti un vērtīgi.

Tā kā strādāju programmatūras izstrādes biznesā, tad lielu daļu sastāda tieši “podkāsti programmētājiem”:

Ruby on Rails podcast

Tā kā Ruby ir viena no manām mīļākajām programmēšanas valodām, tad sākšu ar šo. Šo podkāstu veido Geoffrey Grosenbach un tajā pamatā ir intervijas ar dažādiem Rubyistiem. Geoffrey vēl ir slavens ar to, ka viņš veido PeepCode screencasts, kuri ir ļoti noderīgi Ruby on Rails apgūšanai.

Rails Envy

Šis ir regulārs iknedēļas podkāsts par Ruby un Rails jaunumiem, kuru veido Gregg Pollack un Jason Seifer. Jaunumi tiek pasniegti interesantā veidā ar nelielu (vai dažreiz lielu) humora devu. Popularitāti Ruby kopienā viņi ieguva ar savām Ruby on Rails video “reklāmām”.

Rubyology

Šis ir vēl viens Ruby podkāsts, ko veido Chris Matthieu, kur pēdējā laikā pamatā arī ir intervijas ar citiem Rubyistiem. Šim podkāstam joprojām pieklibo audio kvalitāti, kā rezultātā to ir grūti klausīties ejot pa ielu.

Pragmatic Programmers

Esmu lasījis daudz Pragmatic Programmers grāmatas, tādēļ arī klausos viņu podkāstu, kur ir intervijas ar jauno grāmatu autoriem.

FLOSS Weekly

Šo podkāstu veido Randal Schwartz un Leo Laporte (kurš veido arī ļoti daudz citus podkāstus) un kurš pedējā laikā tiešām ir iknedēļas podkāsts, kurā ir intervijas ar dažādu atvērtā koda jeb opensource projektu veidotājiem.

Stack Overflow

Šo podkāstu veido Jeff Atwood un Joel Spolsky, kas ir plaši pazīstami ar savām iepriekšējām blogošanas un citām publiskajām aktivitātēm. Šajā podkāstā viņi runā gan par kopējo Stack Overflow projektu, gan arī par daudzām citām interesantām programmatūras izstrādes lietām.

Hanselminutes

Šis podkāsts pamatā ir par Microsoft .NET tehnoloģijām, ko veido Scott Hanselman, kas pats nesen ir sācis strādāt Microsoftā. Bet daudzas epizodes skar plašākas web izstrādes tēmas, tādēļ ir interesanti paklausīties arī tiem, kas nepārzin .NET tehnoloģijas.

Alt.NET

Šis ir vēl viens podkāsts par .NET tehnoloģijām, bet to veido Alt.NET grupas entuziasti, kam bieži vien ir savādāks viedoklis nekā Microsoftam. Vairākas epizodes ir par Ruby, JavaScript un Agile tēmām, kas mani interesē.

Agile Toolkit

Šajā podkāstā pamatā ir intervijas ar Agile Software Development teorētiķeim un praktiķiem. Pēdējā laikā jaunas epizodes iznāk reti, bet arhīvos ir pieejamas ļoti daudzas interesantas intervijas.

SPaMCAST

Pilnā vārdā tas ir Software Process and Measurement Cast. Atbilstoši savam nosaukumam liela daļa no podkāsta tiešām ir spams, bet arhīvā var atrast pāris labas intervijas ar Agile klasiķiem – Mike Cohn, Ken Schwaber, Scott Ambler, Kent Beck, Johanna Rothman, Mary Poppendieck.

Technometria

Šo podkāstu veido Phil Windley, kas ir gan profesors, gan viens no IT Conversations producentiem. Šajā personīgajā podkāstā viņš regulāri ar saviem paziņām pārrunā programmatūras izstrādes un IT aktualitātes.

Vai kādam ir vēl kādas labas rekomendācijas par podkāstiem programmētājiem? Labprāt dzirdēšu komentāros.

Ruby muļķu konference Kopenhāgenā

Neesat muļķis, esat Ruby muļķis Šāda devīze ir Ruby Fools konferencei, kas notiek 1. un 2. aprīlī Kopenhāgenā un kura pamatā ir orientēta uz Ruby un Rails iesācējiem.

Tā ka ja kādam ir vēlme ātri “iebraukt” Ruby un Rails pasaulē, tad šī konference varētu labi noderēt un nokļūšana uz Kopenhāgenu ir gana vienkārša. Pats uz šo konferenci gan neplānoju doties, jo plānos ir īstās RailsConf konferences.

Scratch – “objektorientētā” programmēšana bērniem

Nesen pamanīju ļoti interesantu projektu Scratch – vienkāršu, bet vienlaicīgi arī ļoti “spēcīgu” vizuālas programmēšanas vidi, kas pamatā orientēta uz programmēšanas mācīšanu bērniem. Ar Scratch palīdzību var viedot animācijas, spēles, audiovizuālus mākslas darbus un tamlīdzīgus brīnumus.

Šodien ar savu puiku izmēģinājām kopīgi uztaisīt pirmo Scratch projektu un interese bija gan man, gan arī puikam Jebkuru Scratch projektu var arī vienkārši “nošārēt” Scratch web lapā.

Man kā programmēšanas valodu entuziastam likās interesanti, ka Scratch ir izteikti objektorientēta valoda – uz ekrāna izvietotie ķinķēziņi katrs ir objekts ar saviem atribūtiem (atrašanās vieta, virziens, izskats, …) un katram mēs varam vizuāli uzprogrammēt dažāduss skriptus (jeb metodes), kas tiek izpildītas dažādu notikumu gadījumā (nospiesta sākuma poga, saņemts ziņojums, nospiests kāds taustiņš vai kaut kas darīts ar peli, …).

Ja es salīdzinu ar sevi, kā es apguvu programmēšanas valodas, tad tas notika pilnīgi savādāk – vispirms apguvu procedurālo programmēšanu Basicā, C un citās procedurālās valodās, un tikai universitātē sāku apgūt objektorientēto programmēšanu. Bet te Scratchā uzreiz viss ir dabīgi objektorientēts un bērni to uztver ļoti dabīgi. Vēlāk šiem bērniem droši vien būs grūtāk saprast parasto procedurālo programmēšanu

Likās interesanti arī tas, ka Scratch ir veidots ar programmēšanas valodas Squeek palīdzību, kas savukārt ir objektorientēto valodu vecmāmiņas Smalltalk viena no implementācijām. Tā ka Scratch objektorientētība ir dziļi “iedzimta” no tā senčiem.

Rekomendēju visiem vecākiem, kam ir vēlme paprogrammēt kopā ar bērniem

Ruby programmēšanas semināri

Šajā mācību gadā esmu pieteicies katru ceturtdienu organizēt Ruby programmēšanas seminārus Latvijas Universitētes FizMatu Datorikas nodaļā, par kuru apmeklēšanu Datorikas nodaļas studenti var nopelnīt kredītpunktus. Šos seminārus drīkst apmeklēt arī jebkuri citi Ruby interesenti. Vairāk informācijas interesenti var iegūt ruby.lv lapā.

Pirmais seminārs notiek jau rītdien. Ceru, ka kāds/-i atnāks

Nemācieties programmēšanu, izmantojot PHP

Pēdējās dienās man bija tā iespēja piedalīties studentu kvalifikācijas darbu vērtēšanas komisijā. Ja skatās no izmantoto programmēšanas valodu popularitātes, tad laikam PHP bija pirmajā vietā. Bet ja skatās no saņemto atzīmju viedokļa, tad PHP vidēji statistiskais rezultāts bija pēdējā vietā.

Kādēļ tā? Tādēļ, ka PHP dod lielu rīcības brīvību, lai uzrakstītu sliktu kodu un tie, kas mācas programmēt, kā pirmo mācīšanās valodu izmantojot PHP, visbiežāk arī uzrakstīs sliktu kodu. Tipiskās problēmas, ar ko saskāros studentu darbos:

• Lieli gabali ar PHP kodu, bez strukturēšanas funkcijās / procedūrās
• PHP kodā tiek blakus salikta kopā HTML ģenerēšana un SQL datubāzes pieprasījumi
• lielākajā daļā darbu bija SQL injekciju drošības problēmas
• kods bieži vien bija slikti formatēts
• nebija vienoti principi mainīgo / funkciju nosaukumu veidošanai
• parasti netika izmantota objektorientētā pieeja sistēmas veidošanai

Manuprāt, ja kāds ir iesācējs programmēšanā un vēlas to apgūt profesionālā līmenī, tad labāk ir izvēlēties programmēšanas valodas un “freimworkus”, kas uzliek daudz lielāku disciplīnu, lai piespiestu sekot labākajai programmēšanas praksei. Ja sākumā strikti seko stingrai programmēšanas disciplīnai, tad pēc kāda laika arī nāk “apgaismība” par to, kāpēc tas viss ir vajadzīgs un kāpēc tas ir labi. Ja šai disciplinētās programmēšanas stadijai neiziet cauri, tad ir ļoti liels risks palikt stadijā “es esmu kruts programmētājs un rakstu kruto kodu, bet visi pārējie nesaprot, cik es esmu kruts un cik mans kods ir kruts”.

Šis nav tikai mans viedoklis par PHP, bet arī citu “guru” viedoklis. Ar to es negribu teikt, ka jebkurš PHP kods ir slikts un jebkurš PHP programmētājs raksta sliktu kodu, bet vidēji statistiski PHP piemīt šī sliktā “aura”.

Bet ko tad darīt kādam topošajam web programmētājam, kādu programmēšanas valodu tad būtu labāk izvēlēties, lai iemācītos labi programmēt? Nu ja prasa man, tad jau jūs laikam zinat atbildi – paskatieties pāris rakstus iepriekš

ruby.lv

Kā jau rakstīju iepriekš, pēdējā laikā man ir ļoti iepatikusies Ruby programmēšanas valoda un Ruby on Rails web aplikāciju izstrādes freimworks. Šo savu interesi es neturu pie sevis, es to stāstu un rādu arī citiem. Tā kā Ruby interesentu kopienas citur pasaulē izceļas ar savstarpējo izpalīdzēšanu un dalīšanos ar zināšanām, tad man likās, ka vajadzētu arī kādu vietu Latvijas Ruby interesentiem, kur dalīties ar pieredzi un kur savstarpēji sniegt palīdzību un padomus.

Tādēļ esmu izveidojis ruby.lv – Ruby kopienas diskusiju forumu vietu. Esmu tur ielicis pirmās savas rekomendācijas un pieredzi un aicinu visus citus Ruby interesentus (gan esošos, gan topošos) izmantot šos diskusiju forumus gan lai uzdotu jautājumus, uz kuriem nevarat “sagooglot” atbildes citur, kā arī lai dalītos ar savu pieredzi un rekomendācijām. Sākotnēji apsolos sniegt atbildes uz visiem jautājumiem, uz kuriem zināšu atbildes

Pie reizes varu dalīties ar savām pārdomām, kāpēc man patīk Ruby un ar to veidotais Rails:

• Ikdienā es jau labu laiku vairs nenodarbojos ar programmēšanu, bet mani joprojām interesē jaunās programmatūras tehnoloģijas un vienmēr gribu jaunās lietas pamēģināt arī pats. Tā kā laika tam nav daudz, tad mani ir interesējuši tās tehnoloģijas, ar kurām rezultātu var sasniegt ļoti ātri. Programmatūras ziņā mani tādēļ ir interesējušas gatavās ERP sistēmas, ar kuru palīdzību rezultātu parasti var sasniegt ātrāk nekā kaut ko programmējot no nulles.
  Izmēģinot Ruby un uz tā veidoto Rails, man iepatikās šī iespēja sasniegt strādājošu rezultātu stipri ātrākā laikā ar stipri mazāku koda rindiņu skaitu. Un salīdzinot ar gatavu sistēmu ieviešanu, uz Ruby veidotās sistēmas piedāvā stipri plašākas iespējas pielāgot risinājumu konkrētām specifiskām vajadzībām, pateicoties Ruby programmēšanas valodas dinamiskajām iespējām. Un salīdzinot, piemēram, ar gatavām ERP sistēmām, risinājums ir vienkāršāks un bez liekās nevajadzīgās bagāžas, kas bieži ir problēma lielajās sarežģītajās ERP sistēmās.
• Ruby on Rails freimworks seko “convention over configuration” principiem, kas nozīmē, ka visās aplikācijās tiek izmantoti vieni un tie paši aplikācijas veidošanas standarti. Tā rezultātā ir stipri vieglāk saprast kādas gatavas RoR aplikācijas funkcionalitāti un ir viegli vajadzības gadījumā to paplašināt ar kādu papildus funkcionalitāti.
  Agrāk, mēģinot iepazīties ar citu sistēmu funkcionalitāti, esmu juties kā tas vīrs pa kreisi šajā video klipā
• Tā kā dotajā brīdī Ruby vēl atrodas “early adopters” stadijā (bet drīz droši vien vairs tā nebūs), tad parasti Ruby kodu ir rakstījuši labi programmētāji. Tā rezultātā skatoties uz citu rakstīto Ruby kodu bieži var iemācīties kaut ko jaunu. Tam palīdz arī tas, ka Ruby kopienā ir nerakstīts likums, ka Ruby kodam ir jābūt estētiski skaistam, kas motivē refaktorēt slikti uzrakstītu kodu un censties to padarīt vienkāršāku un tā rezultātā arī skaistāku.

Nu un kas jums patīk iekš Ruby?

Vai Mac ir arī programmētāju labākais draugs?

Līdz šim es biju diezgan vienaldzīgs pret Mac fanātiķiem, kas jūsmoja par to, kā viss uz Mac ir labāks. Man likās, ka visbiežāk šie Mac entuziasti bija no grafikas / video / audio dizaineru un mākslinieku loka un es pieņemu, ka viņiem tiešām Mac varētu būt piemērotāks.

Bet pēdējā laikā manu uzmanību ir piesaistījis tas, ka daudzi “top programmētāji” arī ir pārslēgušies uz Mac. Daži no piemēriem:

• Ruby on Rails core team ar David Heinemeier Hansson priekšgalā visi lieto Mac. Viņu labākais draugs uz Mac ir TextMate, kurš tiešām izskatās viens no labākajiem teksta redaktoriem programmētāju vajadzībām. TextMate radītāji arī ir tik fanātiski “makisti”, ka atsakās portēt šo teksta redaktoru uz Windows vai Linux (patlaban izmēģinu tā atdarīnājumu uz Windows – e teksta redatoru – un jāsaka, ka pat atdarinājums ir tīri labs).
• Droši vien ka Ruby kopienas iespaidā arī pragmatiskais programmētājs un daudzu labu grāmatu autors Dave Thomas pirms kāda laika ir pāslēdzies no Linux uz Mac.
• Smalltalk programmētājs un Seaside web applications framework radītājs Avi Bryant lieto Mac.
• Lisp programmētājs un pirmā application service provider radītājs Paul Graham raksta, ka aizvien vairāk viņam zināmie hakeri pārslēdzas uz Mac.
• Atlassian programmētāji arī lieto Mac. Viņi ir radījuši populārās Java bāzētās JIRA issue tracking un Confluence wiki sistēmās.
• Līderu izvēle ietekmē arī sekotājus – skats no RailsConf 2006 Saka, ka arī Java konferencēs parādās arvien vairāk MacBooki.

Kādi varētu būt galvenie iemesli Mac popularitātes pieaugumam “top” programmētāju vidū?

• Pragmatiskais apsvērums ir tāds, ka ne-Microsoftiskie programmētāji visticamāk savas aplikācijas produkcijā darbinās uz Unix/Linux veidīgajiem serveriem, un tādā gadījumā OS X vai Linux uz savas darbstacijas ir daudz noderīgāks, lai topošo sistēmu izstrādes laikā izmēģinātu uz sava datora. Un lai arī cik labi būs wizardi programmēšanas IDE rīkos, vislielāko produktivitāti varēs sasniegt programmētājs, kas pārzinās Unixa komandrindas spēcīgās iespējas.
• Savukārt izvēli par labu OS X nevis Linux var raksturot ar Dave Thomas citātu – “I switched to Macs a couple of years ago after being a Linux person for more than 10 years. The tools are not necessarily better, but they don’t have to be sharpened or maintained as often, which lets be concentrate on just using them.”
• Un papildus, kas man likās būtiski, ir tas, ka izvēli par labu Mac izdara tie programmētāji, kas par būtiskām programmatūras īpašībām uzskata lietojamību un estētisku vienkāršību – iespējams, ka tas, ja programmētājs lieto estētisku un vienkārši lietojamu Macu stimulē viņu radīt arī estētisku un ērti lietojamu programmatūru.

Šo novērojumu rezultātā es vairs neesmu tik skeptisks pret Mac un OS X entuziastiem