Tak jak Jacek prosił chciałem zacząć temat "wrażeń po".
Konferencja całkiem udana była, ale nie ustrzeżono się kilku potknięć.
Plusy:
- tematyka, dobór tematów był całkiem niezły, do teraz jestem pod
wrażeniem prezentacji Wiktora. jRoR wymiata :D
- forma, czyli pisanie kodu na żywca. Od razu widać jak rodzi się
soft, jakie elementy spowalniają, a jakie przyspieszają ten proces.
Minusy:
- forma, czyli brak dostępnych wcześniej fragmentów. Warto by było
umieścić szkielet przykładowego kodu na stronie przed konferencją.
Znaczna część kodu powstawała z pluginów lub była bardzo oklepanym
standardem (konfiguracja webaplikacji ze springiem). Powodowało to
rozjazd pomiędzy tempem pisania prelegenta, a audytorium.
- brak nagłośnienia. Szczególnie widoczny jak porównywało się sposób
mówienia Jacka i innych. Po prostu ten mały gość był słyszalny na
końcu sali, a prelegenci już nie. Wniosek racjonalizatorski o
nagłośnienie lub przymus mówienia "większą czcionką". Podejrzewam że
MiMUW ma nagłośnienia, a jak nie to może ktoś by mógł przywieść piecyk
+ mikrofon?
Zgadzam się z Koziołkiem w wielu miejscach jego wypowiedzi:
Jednak nim zacznę o mniej miłych elementach konferencji chciałbym
wyraźnie podkreślić że
organizatorom należą się podziękowania za to że chciało im się chcieć
i że dzięki temu
mieliśmy okazję do spotkania, dowiedzenia się o kilku ciekawych
sprawach czy wreszcie mieliśmy
okazję podyskutować i wymienić między sobą swoje opinie. :)
Jednak nie wszytko było świetne więc zastanówmy się jak nie popełnić
tych błędów następnym razem :)
podzielę to na dwie części:
częśc I - zaplecze
1) brak dobrego nagłośnienia
2) brak stolików na których można byłoby wygodnie rozłożyć laptopy (+
brak zasilania dla laptopów), owszem
goście przynieśli niewiele laptopów, ale nie wiem co by było gdyby
tak się stało
3) za dużo ludzi w niezbyt dużej sali (to bardzo subiektywna opinia)
część II - merytoryczna
1) uważam że
Choć Koziołek poruszył najistotniejsze kwestie, chciałbym
"uszczegółowić" jego wypowiedź :)
On 19 Lis, 00:50, koziolek <bjkuczyn...@gmail.com> wrote:
> Tak jak Jacek prosił chciałem zacząć temat "wrażeń po".
> Konferencja całkiem udana była, ale nie ustrzeżono się kilku potknięć.
> Plusy:
> - tematyka, dobór tematów był całkiem niezły, do teraz jestem pod
> wrażeniem prezentacji Wiktora. jRoR wymiata :D
> - forma, czyli pisanie kodu na żywca. Od razu widać jak rodzi się
> soft, jakie elementy spowalniają, a jakie przyspieszają ten proces.
> Minusy:
> - forma, czyli brak dostępnych wcześniej fragmentów. Warto by było
> umieścić szkielet przykładowego kodu na stronie przed konferencją.
> Znaczna część kodu powstawała z pluginów lub była bardzo oklepanym
> standardem (konfiguracja webaplikacji ze springiem). Powodowało to
> rozjazd pomiędzy tempem pisania prelegenta, a audytorium.
> - brak nagłośnienia. Szczególnie widoczny jak porównywało się sposób
> mówienia Jacka i innych. Po prostu ten mały gość był słyszalny na
> końcu sali, a prelegenci już nie. Wniosek racjonalizatorski o
> nagłośnienie lub przymus mówienia "większą czcionką". Podejrzewam że
> MiMUW ma nagłośnienia, a jak nie to może ktoś by mógł przywieść piecyk
> + mikrofon?
niestety coś mi „przerwało" i teraz ciąg dalszy ;)
część II - merytoryczna 1) uważam że wszystkie elementy polegające na przygotowaniu i zbudowaniu projektów powinny być opisane i udostępnione przed konferencją. Są to elementy czasochłonne zaś na konferencji jest na to po prostu szkoda czasu. Czyli za Koziołkiem: „Warto by było umieścić szkielet przykładowego kodu na stronie przed konferencją."
2) prelegenci każdą prezentację powinni poprzedzić krótkim: 10-15 minutowym wykładem nt. prezentowanej technologii w czasie którego pokazali by o co w danej technologii chodzi (jak działa) i które jej elementy będą wykorzystywane w prezentacji.
To tyle odnośnie „minusów" sobotniej konferencji. Proszę je traktować nie jako krytykę lecz jako punkty do poprawienia na następnej konferencji :)
Na koniec chciałbym poddać ogólnemu zastanowieniu się kwestię związaną z formą konferencji. Dla mnie osobiście, pisanie kodu przy dużej publiczności jest mało atrakcyjne. Myślę że było to widać w sobotę. Z jednej strony prezenterzy dwoili się i troili żeby przyspieszyć tworzenie prezentowanego kodu. Zaś z drugiej strony nieco znudzona publiczność czekająca aż coś zacznie działać albo przysypiała albo rozmawiała między sobą co oczywiście sprowadzało się do przeszkadzania innym.
Zapewne nagłośnienie w części zminimalizowałoby powyższe „efekty". Uważam jednak że ciekawsza jest forma laboratorium: mniejsza ilość uczestników którzy współtworzą kod a nie tylko odwzorowują to co prezentuje prelegent.
Oczywiście stajemy tu przed problemem dla którego na razie nie widzę rozwiązania: wybór pomiędzy większą ilością uczestników którzy maja wolny wstęp a ograniczeniem liczby uczestników na rzecz pójścia w kierunku „laboratorium".
I jeszcze taka luźna myśl: w medycynie rozwiązują to tak że na sali operacyjnej gdzie odbywa się „prezentacja" jest kilku, kilkunastu aktywnych uczestników zaś reszta ogląda to zza szyby lub w sali obok do której transmitowany jest obraz i dźwięk. Niestety pociąga to za sobą bardziej skomplikowana organizację konferencji.
pozdrawiam wszystkich i jeszcze raz dziękuję organizatorom sobotniej konferencji - wielkie dzięki! :)
Pomysł tworzenia kodu razem z prelegentem zachęcił mnie do
przyniesienia laptopa, niestety zrezygnowałem z klepania w czasie
pierwszej prezentacji. Powód - trudno było nadążyć za prelegentem.
Prezentacja była w sumie ciekawa, tym bardziej, że nie znałem tematu,
widać było, że Łukasz jest obyty w temacie. Prowadzący pokazał, że zna
mnóstwo skrótów klawiszowych Eclipse'a, ale zapomniał o tym, że:
- nie wszyscy je znają, bo np. używają innego IDE albo jeszcze nie
opanowali Eclipse'a w takim stopniu - tak czy inaczej nie pozwala to
słuchaczom pisać równie szybko jak prelegent
- słuchacze nie są merytorycznie przygotowani do pisania kodu;
prowadzący wie, co chce napisać, co napisze za chwilę i co będzie
musiał w związku z tym napisać w dalszej kolejności; słuchacze tej
wiedzy nie mają, więc należy wziąć pod uwagę, że chwilę dłużej zajmie
im pisanie (zwłaszcza, jak ktoś lubi wiedzieć, co pisze :))
- prelegent musi objąć wzrokiem tylko swój ekran, zaś słuchacze -
ekran swojego laptopa oraz obraz z rzutnika; tak więc w dużym
przybliżeniu słuchacz potrzebuje na napisanie danego fragmentu kodu
dwa razy tyle czasu, co prelegent.
Wydaje mi się, że warto się zjawić na miejscu prezentacji odpowiednio
wcześniej, a nie tuż przed planowanym rozpoczęciem, aby uniknąć
opóźnień spowodowanych kłopotami ze sprzętem. Wiadomo, sprzęt to
sprzęt, niedziałanie leży w jego naturze, ale warto się na tę
okoliczność przygotować, bo występuje zazwyczaj w najmniej pożądanych
momentach :)
Bardzo podobała mi się prezentacja Wiktora. Pomijając świetne
przygotowanie prelegenta, prezentacja w naturalny sposób szła w parze
ze swoim mottem, pokazując, że faktycznie w jRoR można szybko
programować.
Dodam swoje pięć groszy. Jak dobrze przeprowadzić warsztat myślałem od jakiegoś czasu. Mimo poślizgu udało mi się skończyć całą prezentację w godzinę przewidując, że pytania później mogą długo zająć.
Kodowanie może być nudne, ale nie musi. Moje uwagi: - przed i po zabawą z komputerem opowiadałem o JRubim, czyli zwykła prezentacja, aby złapać kontakt z widownią, - cisza... najgorsza wg mnie rzecz, jaka może się zdarzyć, trzeba gadać i gadać, - scenariusz - trzeba mieć gotowy scenariusz i przećwiczyć go porządnie (uwaga do Łukasza: zadawanie pytań publiczności, co dalej robimy, zawsze kończy się krępującą ciszą ;)), - ciche mówienie: nie wszyscy dysponują donośnym głosem, więc faktycznie zestaw nagłaśniający mógłby się przydać albo... albo prowadzić w 2 osoby: jedna koduje a druga mówi, - plan B: zawsze wyskoczy jakiś chochlik, więc warto w razie czegoś mieć pod bokiem przygotowaną działającą wersję :).
Radek Holewa spytał się mnie dzień wcześniej jakie środowisko ma sobie przygotować. No właśnie... z premedytacją zrezygnowałem z formuły "kodujemy razem". Dlaczego? - nie sprawdza się przy dużej widowni, lepsze do tego są małe laboratoria, - ogranicza prowadzącego, nie może on przedstawić tyle, ile by chciał, - jeśli uważnie się przyglądaliście mojej prezentacji to używałem pewnej ilości skrótów klawiaturowych do generowania kodu i przechodzenia między plikami - osobiście ciężko mi z tego zrezygnować :),
pozdrawiam, Wiktor
On Nov 19, 2007 4:12 AM, Andrzej Porażyński <a.porazyn...@gmail.com> wrote:
> niestety coś mi „przerwało" i teraz ciąg dalszy ;)
> część II - merytoryczna > 1) uważam że wszystkie elementy polegające na przygotowaniu i zbudowaniu > projektów powinny być opisane i udostępnione przed konferencją. Są to > elementy czasochłonne zaś na konferencji jest na to po prostu szkoda czasu. > Czyli za Koziołkiem: „Warto by było umieścić szkielet przykładowego kodu na > stronie przed konferencją."
> 2) prelegenci każdą prezentację powinni poprzedzić krótkim: 10-15 > minutowym wykładem nt. prezentowanej technologii w czasie którego pokazali > by o co w danej technologii chodzi (jak działa) i które jej elementy będą > wykorzystywane w prezentacji.
> To tyle odnośnie „minusów" sobotniej konferencji. Proszę je traktować nie > jako krytykę lecz jako punkty do poprawienia na następnej konferencji :)
> Na koniec chciałbym poddać ogólnemu zastanowieniu się kwestię związaną z > formą konferencji. Dla mnie osobiście, pisanie kodu przy dużej publiczności > jest mało atrakcyjne. Myślę że było to widać w sobotę. Z jednej strony > prezenterzy dwoili się i troili żeby przyspieszyć tworzenie prezentowanego > kodu. Zaś z drugiej strony nieco znudzona publiczność czekająca aż coś > zacznie działać albo przysypiała albo rozmawiała między sobą co oczywiście > sprowadzało się do przeszkadzania innym.
> Zapewne nagłośnienie w części zminimalizowałoby powyższe „efekty". Uważam > jednak że ciekawsza jest forma laboratorium: mniejsza ilość uczestników > którzy współtworzą kod a nie tylko odwzorowują to co prezentuje prelegent.
> Oczywiście stajemy tu przed problemem dla którego na razie nie widzę > rozwiązania: wybór pomiędzy większą ilością uczestników którzy maja wolny > wstęp a ograniczeniem liczby uczestników na rzecz pójścia w kierunku > „laboratorium".
> I jeszcze taka luźna myśl: w medycynie rozwiązują to tak że na sali > operacyjnej gdzie odbywa się „prezentacja" jest kilku, kilkunastu aktywnych > uczestników zaś reszta ogląda to zza szyby lub w sali obok do której > transmitowany jest obraz i dźwięk. Niestety pociąga to za sobą bardziej > skomplikowana organizację konferencji.
> pozdrawiam wszystkich i jeszcze raz dziękuję organizatorom sobotniej > konferencji - wielkie dzięki! :)
> Dodam swoje pięć groszy. Jak dobrze przeprowadzić warsztat myślałem od > jakiegoś czasu. Mimo poślizgu udało mi się skończyć całą prezentację w > godzinę przewidując, że pytania później mogą długo zająć.
> Kodowanie może być nudne, ale nie musi. Moje uwagi: > - przed i po zabawą z komputerem opowiadałem o JRubim, czyli zwykła > prezentacja, aby złapać kontakt z widownią, > - cisza... najgorsza wg mnie rzecz, jaka może się zdarzyć, trzeba gadać i > gadać, > - scenariusz - trzeba mieć gotowy scenariusz i przećwiczyć go porządnie > (uwaga do Łukasza: zadawanie pytań publiczności, co dalej robimy, zawsze > kończy się krępującą ciszą ;)), > - ciche mówienie: nie wszyscy dysponują donośnym głosem, więc faktycznie > zestaw nagłaśniający mógłby się przydać albo... albo prowadzić w 2 osoby: > jedna koduje a druga mówi, > - plan B: zawsze wyskoczy jakiś chochlik, więc warto w razie czegoś mieć > pod bokiem przygotowaną działającą wersję :).
> Radek Holewa spytał się mnie dzień wcześniej jakie środowisko ma sobie > przygotować. No właśnie... z premedytacją zrezygnowałem z formuły "kodujemy > razem". Dlaczego? > - nie sprawdza się przy dużej widowni, lepsze do tego są małe > laboratoria, > - ogranicza prowadzącego, nie może on przedstawić tyle, ile by chciał, > - jeśli uważnie się przyglądaliście mojej prezentacji to używałem pewnej > ilości skrótów klawiaturowych do generowania kodu i przechodzenia między > plikami - osobiście ciężko mi z tego zrezygnować :),
Witam,
niestety nie moglem byc na konferencji ale mimo to mam równiez kilka spostrzeżeń dotyczacych takiej formy prezentacji.
Ogólnie rzecz ujmując to zgadzam się z powyższą wypowiedzią Wiktora. Mowicie, że za szybko, że sie nie dało nadązyć za prelegentami. Ale spójrzmy prawdzie w oczy - z taką grupa ludzi i z takim czasem (póltorej godziny) takiej formy przeprowadzić się nie da. Jesli mialo by to mieć jakiś sens - to jedna taka prezentacja powinna trwac kilka godzin, a może nawet cały dzień. Zrezygnowanie ze skrótów? osobiście twierdze że jest to niemożliwe - zawsze można zapytać o używane skróty klawiszowe - ale ponownie - ograniczy to czas prezentacji, i skonczy sie na wspólnyum skonfigurowaniu środowiska.
Takie moje przemyslenia - chodź może nie mam za bardzo do nich praw.. bo tak jak napisalem - inne obowiązki nie pozwoliły mi na udział.. czego notabene bardzo żałuje.
Proponuję aby przed prezentacją udostępnić kod który później jest "tworzony" w czasie prezentacji. W ten sposób uczestnicy będą wiedzieć do czego zmierzać. Dokładając do tego kwestie konfiguracji itd. każdy bez względu na IDE jakiego używa będzie mógł przygotować się.
Myślę że dodatkowym plusem tego byłaby bardziej merytoryczna dyskusja.
On 11/20/07, ma.zi...@gmail.com <ma.zi...@gmail.com> wrote:
> jeden duży minus to wielkość czcionki. Poza pierwszymi rzędami nie > było widać co, prelegent pisze w Eclipsie (nie mówiąc już o konsoli)
> i dużo dużych plusów dodatnich za całą resztę.
Szczerze mówiąc to nie jest to minus dla prelegentów ale dla słuchaczy - że nie zwrócili na to uwagi "wygłaszacza" (jeśli nie zwrócili - bo na jugu jakoś nigdy nie zapominają by przypomnieć o zwiększeniu czcionki ;) )
Owszem kwestia widoczności kodu jest ważna, Jednak uważam że tym razem były to raczej ograniczenia wielkościowe białego ekranu na którym wyświetlano obraz. Pytanie czy w ogóle można zorganizować większy (albo postawić dwa obok siebie?!?). W każdym razie ja bym tu nie szedł w kierunku powiększania czcionki bo dojdziemy do momentu w którym będziemy widzieli 1/3 szerokości 5-8 linijek ;)
Tak sobie myślę czy nie można byłoby tego zrobić tak (kto zna się na tym sprzęcie?!?!) żeby były 2 rzutniki i 2 ekrany. Pierwszy ekran tradycyjnie z przodu sali, drugi gdzieś pośrodku (z lewej albo z prawej strony). Ale to tylko jakaś nieokrzesana moja myśl ;)
On Nov 20, 2007 11:57 PM, Andrzej Porażyński <a.porazyn...@gmail.com> wrote:
> Owszem kwestia widoczności kodu jest ważna, Jednak uważam że tym razem były > to raczej ograniczenia wielkościowe białego ekranu na którym wyświetlano > obraz. Pytanie czy w ogóle można zorganizować większy (albo postawić dwa > obok siebie?!?). > W każdym razie ja bym tu nie szedł w kierunku powiększania czcionki bo > dojdziemy do momentu w którym będziemy widzieli 1/3 szerokości 5-8 linijek > ;)
> Tak sobie myślę czy nie można byłoby tego zrobić tak (kto zna się na tym > sprzęcie?!?!) żeby były 2 rzutniki i 2 ekrany. Pierwszy ekran tradycyjnie z > przodu sali, drugi gdzieś pośrodku (z lewej albo z prawej strony). > Ale to tylko jakaś nieokrzesana moja myśl ;)
Właśnie takich myśli nam trzeba! Na ostatniej mojej prezentacji, gdzieś tam, były dwa duuuuże ekrany, gdzie widać było wszystko na moim 1600x1200 pulpicie. Chciałbym, aby tego typu sugestie/uwagi/itp pojawiały się tutaj, a ja na razie cichutko sobie je zbieram i notuję, aby na ich bazie stworzyć dokument do rozesłania do sponsorów w celu negocjacji potencjalnych kosztów przyszłych warsztatów-konferencji. Chciałbym, abyśmy doczekali się tak dużej sali, aby można było zgromadzić 150-200 osób i prezentacje prowadzić na 2 ekranach o dużej widoczności. Mam kilka pomysłów, ale na razie włączyłem stan nasłuchiwania.
On 20 Lis, 23:57, "Andrzej Porażyński" <a.porazyn...@gmail.com> wrote:
> Tak sobie myślę czy nie można byłoby tego zrobić tak (kto zna się na tym
> sprzęcie?!?!) żeby były 2 rzutniki i 2 ekrany. Pierwszy ekran tradycyjnie z
> przodu sali, drugi gdzieś pośrodku (z lewej albo z prawej strony).
