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.
e-lietas 
Iespējams, ka prezentācija bija labi sagatavota.
Nu bet mani saturs neapmierināja. Nožēloju, ka vispār tur iegriezos.
Nepamatoti apgalvojumi, ka ruby lietotāji ir gudrāki. Diez no kuras vietas tāda statistika?
Smukāki kodi (dizaineriem patiks..;)).
Vienkāršāki kodi (tas priekš skolniekiem).
Nav pieejams parastiem lietotājiem (lūdzu http://instantrails.rubyforge.org).
Īsā laikā posmā var salasīt lapu (95% jā, bet 5% – nē. un diemžēl 5% pieder pie nopietnām un sarežģītām lietām).
man būtu pie vienas vietas, ja tikai autors nepieminētu konkrētas valodas (piemēram php un java).
Pats būdams pythona fanāts, nekad vēl nebiju teicis, ka java ir sūds, tāpēc ka to lieto skolēni, kuri ir stulbi.
Bet neņem nopietni, skolotājiem ir raksturīga pārlieka iedomība.
Paldies par viedokli, labprāt būtu arī klātienē padiskutējis par šīm lietām 🙂
Prezentācijas mērķis bija pastāstīt par manu viedokli un vērtībām, kādēļ man patīk Ruby un ja citiem šī vērtības arī ir līdzīgas, tad ieinteresēt par Ruby. Bet ja citiem nepatīk vienkāršs, smuks kods, ja nepatīk test driven development, ja nepatīk DRY un convention over configuration principi, tad droši vien Ruby un Rails nav priekš viņiem.
Un novērojumi par “gudrību” arī ir mani personiskie, balstoties uz blogiem un konferencēm – statistiku neesmu taisījis 🙂
Padiskutētu, ja prezentācija būtu man tuvākā valodā. Angļu valodu saprotu ļoti labi, bet ar runāšanu man ir problēmas.
Nav taču rubis kodu naba, ka tam vienīgajam smuks un vienkāršs kods, TDD un DRY. Manā skatījumā pythons (ar django) pamatīgi ieliek rubiju šajos punktos. Ātrums, piespiedu smuks kods, milzums bibliotēkas un daudz kas vēl.
Diskutēt par java, rubi, php vai pythona programmētāju vidējo gudrības līmeņi, man liekas stulbi.
Rubi ir labs, bet ne pats labākais.
Diemžēl man nesanāca apmeklēt BarCamp un tātad arī redzēt Raimonda prezentāciju, bet esmu redzējis citas viņa prezentācijas par RoR un viņa entuziasms patiešām atstāj iespaidu.
Par to, ka kāda valoda būtu kodu naba manuprāt vispār runāt ir muļķīgi jo visiem un visam neder viens “cimds”. Es arī nedomāju ka Raimonds ar savu prezentāciju gribēja ko tādu pateikt.
Nu par šo jauno un “moderno” tendenci, ka slaidi ir jāpārtaisa par kaut kādu multfilmu vēl var pstrīdēties. Esmu gana daudz bijis uz tehniskiem semināriem un varu tikai apsveikt, ka cilvēki prezentācijas ir veidojuši “pagājušā gadsimta stilā” un nevis ar kaut kādām bildītēm, jo es tos varu paskatīties un atcerēties tos faktus, par ko bija runa. OK esmu gatavs piekrist, ka slaidi nevar būt pārāk sīki, t.i. ne tādi, ka sāk no tiem reāli lasīt, ka tie nevar būt pārbāzti ar info, jo tad tas kļūst apgrūtinoši, var būt kāda bildīte atslodzei, bet viss vienās bildītēs ir 0 info. Protams, perfektā gadījumā būtu viena prezentācija un viens raksts, kurā sīki izklāstīts tas pats, bet tā ir tikai pa retam lielās konferencēs. Ja cilvēks māk stāstīt, tad interesanti var pastāstīt arī bulletus un iebraukt nesaprotamās “auzās” var arī ar bildītēm, kuriem ir nesaprotamas analoģijas utml.
RoR Yeeey
Atļaušos oponēt nedaudz.
Ja gribas ārā-stāvošu veiktspēju un koda skaistumu, tad nekas nav labāks par tīru C/C++. Pat ja iet runa par Web aplikācijām, tas nav šķērslis minēto programmēšanas valodu izmantošanai. RoR, PHP, C# ir vairāk pielāgoti izstrādātāju ērtībām un nodrošina DRY konceptu efektīvu realizāciju jau pašos pamatos. Bet neaizmirsīsim, ka viss ir atkarīgs no gala izstrādātāja, kā viņš spēs izmantot šīs sniegtās iespējas un kā risinās konkrētas problēmas. Protams, trešās puses bibliotēku izmantošana savu risinājumu izstrādāšanā ļauj ievērojami samazināt atsevišķas funkcionalitātes realizācija nepieciešamo laiku, bet, izmantojot trešās puses programmatūru, nedrīkst neņemt vērā papildu riskus, kas tiek radīti gala risinājuma. Jo sevišķi, ja minētie trešās puses risinājumi ir komplicēti un izstrādātājam nav velmēs veikt skurpulozi programmatūras analīzi.
Rezumējot, nevajadzētu RoR pozicionēt ka universālo rīku visa veida programmatūras radīšanai. Vajadzētu tomēr centrā ievirzīt projekta mērķus, biznesa funkcijas, vidi un lietotāju, un, izejot no minētajiem, veikt risinājuma modelēšanu un tikai pēc tam izvēlēties kādu freimworku un programmēšanas valodu/skriptu valodu izmantot mērķu sasniegšanai. Nevajadzētu aizmirst arī par veiktspējīgumu, kas, RoR ne tuvu nav labākais.
Lai veicas
P.s.
Waterfall vs Agile – nevajdzētu teikt, ka waterfall ir novecojusi metode. Tā ir vienīgā metode darbam ar klientiem, kas ir svārstīgi un ir tendēti mainīt domas projekta izstrādes gaitā un nevēlas segt šīs papildu izmaksas. Kā arī, nopietnos projektos, bet waterfall pieejas nekādi nav iespējams iztikt, jo pašos sākumos ir jāparedz visas izmaksas attiecībā uz izstrādājamo risinājumu, kas Agile pieejas gadījumā nav iespējams.
Paldies par ieteikumiem!
Prezentācija iespaidīga!