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:

Esmu jau agrāk rakstījis par maniem piedzīvojumiem ar e-me jeb e-paraksta sertifikācijas pakalpojumu sniedzēju. Kā daudzi no jums jau droši vien zin, tad nesen e-me ir mainījis īpašnieku un tagad tas ir LVRTC. Gribētos cerēt, ka šīs izmaiņas mainīs ar e-paraksta izplatību Latvijā, bet diemžēl pirmās aktivitātes neko labu neliecina.

Komunikācija ar klientiem

Ja gadījumā kāds no e-me lietotājiem nebija pamanījis, ka e-me īpašnieks tagad ir LVRTC, tad viņi parūpējās par šiem klientiem izsūtot e-pasta vēstuli ar sekojošu saturu:

Nosūtu Jums dokumentu, kas parakstīts ar drošu elektronisko parakstu (paplašinājums- *.edoc), kas apliecina tā juridisko spēku.

Ievērojot Ministru kabineta 28.06.2005. noteikumu Nr. 473 “Elektronisko dokumentu izstrādāšanas, noformēšanas, glabāšanas un aprites kārtība valsts un pašvaldību iestādēs un kārtība, kādā notiek elektronisko dokumentu aprite starp valsts un pašvaldību iestādēm vai starp šīm iestādēm un fiziskajām un juridiskajām personām” 17. punkta prasības, VAS Latvijas Valsts radio un televīzijas centrs lūdz Jūs vienas darbdienas laikā nosūtīt paziņojumu par elektroniskā dokumenta saņemšanu.

Pirmajā brīdī šāda vēstule izskatās pēc izsaukuma uz policiju vai tiesu. Un papildus pieminētie noteikumi attiecas tikai uz valsts vai pašvaldību iestādēm un man tie nekādus pienākumus neuzliek atbildēt vienas dienas laikā. Un pašā pievienotajā dokumentā (kuru man jāatver vispirms ar eParakstītāja aplikāciju un pēc tam ar MS Word, ir tikai informācija par to, ka ir nomainījusies līguma kontakpersona).

Nākamā “laža” ir tāda, ka e-pasts ir izsūtīts iekļaujot pārsimt klientu e-pasta adreses To: laukā, kā rezultātā visi saņēmēji redz visu pārējo saņēmēju e-pasta adreses. Tas gan ir nezolīdi no personas datu aizsardzības viedokļa, gan arī šādi e-pasti ir kandidāti automātiskai nokļūšanai e-pastu “spam” mapēs.

Nosūtīju atbildi uz šo e-pastu norādot šos trūkumus, diemžēl atbildi nesaņēmu.

Padoms: Lūdzu iemācieties Interneta komunikāciju “netiķeti” pirms izsūtiet šādus masveida e-pastus. Un lūdzu iemācīties klientiem draudzīgu komunikācijas veidu, nevis lietojiet stīvo, formālo un atbaidošo stilu.

Grib samaksu gan par vistām, gan olām

E-paraksta projekta neveiksmes cēlonis pēdējā gada laikā tika raksturots kā “vistas un olas” problēma – 1) nav pietiekoši daudz e-paraksta lietotāji, kas būtu gatavi maksāt par pakalpojumu, jo nav pietiekoši daudz e-pakalpojumi, 2) nav pietiekoši daudz e-pakalpojumu, jo potenciālie pakalpojumu sniedzēji neredz ieguvumu no tik maza lietotāju skaita.

Tādēļ patlaban e-paraksta lietotāji nav kļuvuši vairāk par tiem pārdesmit tūkstošiem, kuriem e-paraksta kartes iegādājās ar valsts pasūtījumu. Savukārt e-pakalpojumu sniedzēju saraksts, kur var izmantot e-parakstu, tā arī ir palicis ļoti neliels (daži, piemēram, Swedbank, pat ir pazuduši no saraksta).

Šādos apstākļos būtu jāizvēlas viena no divām stratēģijām:

1. Vai nu ir jāstimulē e-paraksta lietotāju pieaugums, būtiskipazeminot cenas lietotājiem (jo patreizējā cena ne privātajiem, ne biznesa lietotāji nelikās pārāk pievilcīga) un tad domājot kā iegūt ieņēmumus no potenciālajiem pakalpojumu sniedzējiem
2. Vai arī ir jāstimulē pakalpojumu radīšana, nodrošinot izstrādātājiem bez maksas visus nepieciešamos rīkus pakalpojumu radīšanai un mērķtiecīgi strādājot ar potenciālajiem pakalpojumu sniedzējiem, lai panāktu pēc iespējas lielāku pakalpojumu klāstu. Tad arī e-paraksta lietotāji varētu saredzēt ieguvumu no e-paraksta pakalpojumiem un būtu gatavi par to maksāt.

Tā vietā jaunie e-me saimnieki ir izvēlējušies mūsu budžeta lāpīšanas politiku – ja naudas nav, tad jāpaaugstina nodokļi. Nākotnē ir paredzēts, ka par e-paraksta bibliotēku (kas nepieciešama e-paraksta integrācijai trešo pušu sistēmās) izmantošanu būs jāmaksā gan izstrādātāja licence, gan arī lietošanas licence. Un cik ir redzēts, tad šīs summas ir paredzētas diezgan iespaidīgas, lai pēc iespējas atsistu izstrādātāju vēlmi izstrādāt integrāciju ar e-parakstu savās sistēmās.

Ja no nodokļiem izvairīties ir grūtāk, tad no e-paraksta izmantošanas izvairīties cenu celšanas gadījumā ir stipri vieglāk. Un ja vēl ņem vērā, ka parādās arī alternatīvi piedāvājumi ar potenciāli mazākām izmaksām lietotājiem, tad pastāv risks, ka e-pakalpojumu potenciālie sniedzēji var sākt vairāk izmantot šos alternatīvos risinājumus.

Padoms: Ja jums tiešām ir tik dārgi uzturēt šīs e-paraksta integrācijas bibliotēkas, tad pareizāk būtu tās nopublicēt kā atvērtā koda programmatūru un tad izstrādātāji paši veiksmīgi tās varētu uzturēt tālāk un visi būtu laimīgi.

Labā ziņa Mac lietotājiem

Staigājot pa e-me.lv lapām arī atradu ko iepriecinošu – beidzot ir pieejami viedkaršu lasītāju draiveri Mac OS X operētājsistēmai, kā rezultātā kopā ar SignAnywhere Free programmu beidzot ir iespējams lietot e-parakstu arī uz Mac datora.

Diemžēl ar Firefox pārlūkprogrammu un šiem viedkaršu draiveriem nav iespējams autentificēties visās minētajās e-pakalpojumu lapās. Man izdevās veiksmīgi autentificēties Nordea internetbankā, bet e-me.lv un latvija.lv lapās neizdevās – tās izskatās joprojām ir paredzētas tikai izredzētajiem Windows un Internet Explorer lietotājiem. e-me.lv izdod kļūdas paziņojumu

Ja Jūs izmantojiet tīmekļa pārlūku Mozilla Firefox, lūdzu izlasiet informāciju par tā konfigurāciju izmantošanai kopā ar Е-МЕ autentifikācijas sertifikātiem

bet norādītajā saitē nav nekādas informācijas par Mozilla Firefox

Š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ē

27. martā notiks pirmā Latvian Oracle User Group konference. Atšķirībā no Oracle dienas, šis ir Oracle lietotāju un profesionāļu organizēts pasākums, kurā Oracle “spečuki” var atklāti apmainīties gan ar pozitīvu, gan negatīvu pieredzi un viedokļiem par Oracle tehnoloģijām un to praktisku pielietošanu.

Līdzīgi kā Oracle dienās, esmu pieteicies ar prezentāciju arī šajā konferencē un stāstīšu par to, kā man sokas ar Ruby on Rails Oracle adaptera veidošanu. Citas prezentācijas pamatā būs par Oracle datubāzes izmantošanu un tās “advancētajām fīčām”. Kā viesis piedalīsies arī Kuassi Mensah, ar kuru esmu iepriekš ticies Oracle OpenWorld konferencē – viņu starp citu arī interesēja manas aktivitātes Ruby on Rails un Oracle “sadraudzināšanas” jomā.

Tā ka visi Oracle tehnoloģiju interesenti ir gaidīti 27. martā uz šo pasākumu – pasākums ir bezmaksas un reģistrēties var šeit.

Pagājušajā nedēļas nogalē piedalījos BarCamp Baltics 2009 ne-konferencē (tikai pirmajā dienā) un kopumā jāsaka, ka no organizācijas viedokļa viss bija ļoti labi – liels paldies organizatoru komandai par ieguldīto darbu!

Toties no BarCamp apmeklētāju viedokļa gribētos, ka tie būtu sagatavojušies mazliet labāk. Viens no BarCamp noteikumiem ir, ka ja Tu nāc uz BarCamp, tad arī vajag tur aktīvi piedalīties – vislabāk ar savu prezentāciju, vai arī vismaz iesaistoties diskusijās. Uz pasākumu bija ieradušies vairāk nekā 500 dalībnieku, bet pieejamais prezentāciju grafiks tā arī netika pilnībā aizpildīts – uz prezentāciju sākumu bija pieteikušies ap 35 prezentētāji, kas līdz pasākuma beigām palielinājās par vēl kādiem 10.

Tā rezultātā dažos grafika intervālos ar tēmu piedāvājumu bija pašvaki. Kā arī dažas no apmeklētajām prezentācijām īpaši neaizkustināja. Tā kā pašam ikdienā nākas ļoti bieži nodarboties ar prezentēšanu, tad gribēju padalīties ar ieteikumiem, kā sagatavot labu un interesantu prezentāciju, lai nākamajā BarCamp prezentēt gribētāju būtu stipri vairāk

• Izdomājiet, kas ir tas vēstījums (“message”), ko gribat citiem pavēstīt.
  Ja jūs kaut ko stāstīsiet, bet nebūs skaidrs, kādēļ jūs to citiem gribat pastāstīt, tad citiem tas nebūs interesanti.
• Sagatavojieties prezentācijai un to iepriekš izmēģiniet
  Ja jūs kādu tēmu esat stāstījuši jau daudzas reizes, tad varbūt vēl vienu reizi jūs to varat pastāstīt bez gatavošanās. Bet ja tā ir pirmā reize un ikdienā nesanāk nodarboties ar prezentēšanu, tad noteikti vajag prezentāciju izmēģināt – kaut vai mājās spoguļa priekšā.
• Runājiet par tēmu kaislīgi un nebaidities izteikt savu viedokli par to
  Diskusija izvērtīsies tad, ja būs skaidrs prezentētāja viedoklis par kādu tēmu. Ja tikai izklāstīs vispārzināmus faktus, tad diskusijai nebūs pamata.
• Sagatavojiet vizuāli pievilcīgus slaidus
  Tas mani mazliet izbrīnija, redzot, ka jauno mēdiju entuziasti, lieto pagājušā gadsimta stilā veidotus “bullet-point” prezentācijas slaidus. Slaidi nav paredzēti lasīšanai – vārdi būs daudz iedarbīgāki, ja tos pateiks pareizajā intonācijā. Slaidi ir paredzēti, lai vizuālā veidā paspilgtinātu jūsu teikto. Tādēļ nepaslinkojiet un pameklējiet Googlē atbilstošas vizuālas bildes, lai ilustrētu jūsu stāstījumu, vai arī uzzīmējiet kādu vizuālu shēmu, kas palīdzēs uztvert stāstījumu.
  Un vēl – ja izmantojiet agrākas prezentācijas slaidus, tad pārskatiet, vai šajā reizē tiešām visi slaidi tiks izmantoti, vai nevajag kaut ko pamainīt šīs auditorijas specifikai.
• Iemārketējiet savu prezentāciju pareizajai mērķauditorijai
  Sākot no tādas triviālas lietas, ka prezentācijas nosaukumu uzrakstiet tādā valodā, kādā to stāstīsiet (lai nepiečakarētu vāciešus, kas atnāk uz prezentāciju ar virsrakstu angliski, bet konstatē, ka prezentācija notiks krieviski). Ja rakstiet tēmas nosaukumu ar roku, tad rakstiet to ar lieliem, saprotamiem burtiem – ne visi var saprast jūsu mikroskopisko rokrakstu. Un centieties, lai virsrakstā būtu iekļauts jūsu prezentācijas esence.
• Nepārtērējiet laiku un atstājiet vietu diskusijai
  Jo atgriezeniskā saite no auditorijas taču ir galvenais – ja neinteresē, kāds ir auditorijas viedoklis, tad var arī vienkārši palikt pie prezentēšanas spoguļa priekšā
• Nepārcentieties ar sava ego slavināšanu
  Ja prezentācijas laikā tikai slavināsiet sevi, cik jūs kruti kaut ko esat izdarījuši, tad tas visticamāk radīs negatīvu vai labākajā gadījumā vienaldzīgu reakciju no auditorijas. Ja jūs taisat prezentāciju auditorijai, tad primāri domājat, ko jūs varat tai dot, nevis sagaidiet uzslavas no tās.

Pats centos pieturēties pie šiem principiem un spriežot pēc auditorijas jautājumiem un atsauksmēm mana prezentācija “Why I love Ruby on Rails” sanāca tīri laba Ievietoju arī savus slaidus, ko lietoju:

Ja kādam ir vēl kādas rekomendācijas, ka veidot labas prezentācijas, tad labprāt uzklausīšu komentāros.

Pēdējā laikā daudzi ir sākuši runāt par open-source jeb atvērtā koda programmatūru, kur skaļākā diskusija bija par to, vai valsts iestādēs vajadzētu Microsoft Office vietā izmantot OpenOffice.org. Bieži šajās diskusijās open-source termins tiek reducēts uz to, ka tā ir programmatūra par brīvu, vai arī vismaz stipri lētāk nekā Microsoft (jo par atbalstu tāpat kādam būs jāmaksā).

Arī nesen notikušajā LATA konferencē daudzās diskusijās klausītāji uzdeva jautājumus par to, kad tā un tā programmatūra nodrošinās to un to “fīču” un kāpēc nav realizēta tā un tā funkcionalitāte, jo tas taču ir tik svarīgi. Un varbūt kādam var mazliet samaksāt, lai uztaisītu to “mums ļoti svarīgo funkcionalitāti”. Izskatījās, ka liela daļa dalībnieku bija atnākuši ar attieksmi “ko man tā atvērtā koda programmatūra tādu īpašu var dot?”.

Problēma ir tāda, ka viņi nav sapratuši open-source būtību – tas nav “lēts Microsoft”, tās vairs nav klasiskās piegādātāja un klienta attiecības, kur klients samaksā “piķi” piegādātājam un pēc tam par jebkuru problēmu var sūdzēties piegādātājam.

Open-source ir kolektīva programmatūras radīšana un savstarpējā sadarbība, kur katrs dod ieguldījumu atbilstoši savām spējām – vieni var programmēt, citi var testēt, citi var dokumentēt, citi pieredzējušie lietotāji var palīdzēt ar padomu jaunajiem lietotājiem.

Ja kāds liels uzņēmums vai valsts iestāde ir izvēlējusies atvērtā koda programmatūru, tad tā vietā lai meklētu, kurš uzņēmums tagad būs atbildīgs par visām problēmām ar šo programmatūru, vajag drīzāk ļaut saviem darbiniekiem iesaistīties šajā open-source projektā atbilstoši viņu spējām. Ja ir nepieciešama kāda jauna funkcionalitāte, kas pagaidām nav pieejama, tad vajag mēģināt pašiem to arī uztaisīt (un iespējams, ka citur pasaulē atradīsies arī citi, kas palīdzēs ar tās realizāciju). Ja ir atrasta kāda kļūda, tad pašiem arī jāmēģina arī uztaisīt šīs problēmas risinājumu, vai vismaz pietiekoši precīzi jāapraksta, kā šo problēmu var atkārtot. Ja programmatūra nav latviskota, tad pašiem arī vajag ķerties pie latviskošanas (kur parasti nav nepieciešamas īpašas programmēšanas zināšanas). Un protams, ja ir kāda lieka naudiņa, tad var arī finansiāli atbalstīt citus aktīvākos šī open-source projekta attīstītājus.

Šādā veidā arī var piesaistīt organizācijai spējīgākus IT darbiniekus, jo spējīgākajiem darbiniekiem būs stipri interesantāk pašiem iesaistīties open-source projekta attīstībā, nevis tikai būt par problēmziņojumu transportētājiem starp lietotājiem un aizjūras piegādātāju.

Un tā kā šībrīža situācijā ir moderni visos rakstos piesaukt ekonomisko krīzi, tad šajā sakarā var teikt, ka iesaistīšanās open-source projektos ir ļoti labs veids, kā samazināt importu un palielināt pievienotās vērtības radīšanu tepat uz vietas

Vakardien notika LIKTA (Latvijas informācijas un komunikāciju tehnoloģiju asociācija) 10. konference, kurā otro reizi tika pasniegtas “Platīna peles” balvas.

Bija patīkami, ka par vienu no trijiem labākajiem ePārvaldes un e-pakalpojumu projektiem tika atzīts Latvenergo klientu portāls e-latvenergo un man bija tas gods saņemt “atzinības rakstu” kā šīs sistēmas izstrādātāju pārstāvim. Platīna peli kā pats labākais projekts saņēma “Swedbankas ceturtās paaudzes internetbanka privātpersonām” – droši vien žūrija ņēma vērā ilggadējos hanza.net panākumus nevis tikai šogad veikto web dizaina maiņu. Trešais no labākajiem projektiem bija “Trešais tēva dēls”.

e-latvenergo patlabam ir arī lielākā web aplikācija Latvijā, kas izstrādāta ar Ruby on Rails, un man kā Ruby fanam un popularizētājam un prieks, ka izdevies ar to izveidot projektu, kas ieguvis šādu atzinību. Varētu teikt, ka arī e-latvenergo ir 4. paaudzes, jo pateicoties Ruby on Rails ātrajai izstrādes pieejai mēs šī gada laikā esam izstrādājuši vismaz četras jaunas sistēmas relīzes.

Vēl interesanti, ka e-latvenergo projekts aktīvi sadarbojas arī ar pārējiem laureātiem – e-latvenergo iespējams autentificēties un veikt maksājumus ar Swedbankas internetbanku, kā arī sadarbībā ar Trešā tēva dēla projektu tika apmācīti bibliotekāri, lai viņi savukārt varētu apmācīt publisko bibliotēku interneta piekļuves vietu apmeklētājus darbam ar e-latvenergo.

Platīna peli Izglītības, kultūras, veselības aprūpes un sporta projektu kategorijā ieguva “Pasaku portāls www.pasakas.net”. Līdz šim par tādu projektu nebiju dzirdējis, bet tagad radās interese to parādīt saviem bērniem – tas izskatās varētu būt noderīgāks datorlaika izmantošanas veids, nekā spēlēt spēlītes

Tā kā mūsu kompānija bija viens no galvenajiem organizatoriem BibCamp 2 “nekonferencei bibliotekāriem”, tad organizētāji palūdza mani piedalīties un kaut ko noprezentēt. Tā kā runāt par man tuvām lietām man patīk , tad es pieteicos uz veselām trīs prezentācijām.

Tālāk redzami slaidi no manām prezentācijām:

Web 2.0

Web lietojamība

Spējā jeb Agile pieeja

Galvenais “izaicinājums” bija noprezentēt šīs tehnoloģiskās tēmas pēc iespējas ne-tehnoloģiskākā veidā. Kopumā izdevās samērā veiksmīgi, jo auditorijai bija daudz jautājumu. Vislielākā interese bija par web lietojamību, jo šīs idejas var izmantot jebkuršs arī vienkāršu web lapu veidošanā.

Kopumā iespaids par BibCamp palika labs un noteikti rekomendēju arī citās jomās sākt organizēt šāda veida “nekonferences”. Par citiem BibCamp 2 iespaidiem var izlasīt Jāņa un Kristapa blogos.

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.

Vakardien notika ikgadējā Latvijas Oracle diena – konference Oracle klientiem un partneriem, kurā uzstājas gan Oracle, gan arī Oracle partneru pārstāvji.

Arī es izmantoju šo iespēju, lai pastāstītu par to, kā veidot web aplikācijas ar Ruby on Rails un Oracle datubāzi, ar ko mums ir jau diezgan liela pieredze. Šie ir mani slaidi, ko izmantoju prezentācijā:

Prezentācijas izaicinošākā daļa bija tā, kad dzīvajā demonstrēju blog aplikācijas izveidi ar Ruby on Rails 10 minūšu laikā (nu varbūt arī bija mazliet ilgāk, jo vajadzēja ne tikai kodēt, bet arī runāt ). Tiem, kas to neredzēja, esmu sagatavojis “skrīnkāstu”:

Labprāt dzirdēšu komentārus par to, cik labs man tas ir sanācis un vai ir labāks par oriģinālo DHH skrīnkāstu

Vēl pastāstīju un rekomendēju izmantot ar Ruby on Rails un Oracle veidoto e-latvenergo sistēmu. Ja kāds no lasītājiem to vēl nav lietojis, tad noteikti izmēģiniet!

Tā kā arī Oracle daudz runā par Web 2.0, tad mēģināju popularizēt on-line Twitterošanu konferences laikā, kas bija ļoti populāra Oracle OpenWorld konferencē. Kā redzams Latvijas konferencēs ir vēl ļoti maz entuziastu, kas izmanto šīs jaunās e-socializēšanās iespējas. Droši vien dēļ tā, ka vakarā varēja ļoti labi socializēties klātienē pēckonferences pasākumā