Scala

[Grzegorz Balcerek]

Drodzy WJUGowcy,

 

Nazywam się Grzegorz Balcerek. Jestem autorem książki o języku Scala
(http://www.grzegorzbalcerek.net/jps.html)
Chciałbym się Was spytać, czy bylibyście zainteresowani jakąś
prezentacją/spotkaniem na temat języka Scala.
W przypadku zainteresowania, ze swojej strony chciałbym oprócz propagowania
Scali pokazać swoją książkę i może skłonić kogoś do jej kupna.

 

Nie proponuję jakiegoś konkretnego, jednego tematu, a raczej kilka do
dyskusji - nie wiem co Wam najbardziej odpowiada, co Was interesuje.

 

Najbardziej mi odpowiadającą formą (ze względu na konieczność
przeznaczenia dodatkowo czasu na dojazd i powrót do Poznania) byłyby
jakieś warsztaty w ciągu dnia, pewnie jakąś w
sobotę. Takie spotkanie może być dłuższe niż zwykłe JUGowe.
Pytanie tylko, czy coś takiego wchodzi w grę ze względów organizacyjnych -
to zdaje się nie jest standardowa forma Waszych spotkań; potrzebna, by była
jakaś sala.

 

Alternatywą jest zwykła prezentacja na spotkaniu w normalnym terminie. Może
być wprowadzenie do Scali, może być coś bardziej zaawansowanego - ale wtedy
raczej dla osób które już coś wiedzą o Scali, przynajmniej podstawy, żeby
nie tracić czasu - np. o DSLach, o wtyczkach kompilatora, o bibliotece
"parsers combinators". Może macie jakieś inne sugestie tematu?

 

Pozdrawiam,
Grzegorz Balcerek

[Paweł Cesar Sanjuan Szklarz]

Czesc

Super!!!. Ja chetnie wezme udzial w dluzszym spotkaniu i warsztaty.

Mnie osobiscie interesuje integracja z java, miedzy innymi jak
obslugiwac injectowanie zaleznosci pomiedzy java i scala.

Pawel Cesar Sanjuan Szklarz.

2012/4/26 Grzegorz Balcerek <gbalc...@gmail.com>:

> --
> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
> Więcej informacji na stronie
> http://groups.google.com/group/warszawa-jug?hl=pl
> Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
> Oferty pracy dozwolone zgodnie z zasadami na
> http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

[Bartek Zdanowski]

Chetnie wezme udzial w warsztatach. Scali bym sie chetnie nauczyl.

> --
> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
> Więcej informacji na stronie
> http://groups.google.com/group/warszawa-jug?hl=pl
> Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
> Oferty pracy dozwolone zgodnie z zasadami na
> http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie
>

--
Sent from my mobile device

Pozdrawiam,
Bartek Zdanowski

Bloguję http://blog.bartekzdanowski.pl i twittuję
http://twitter.com/bartekzdanowski
Confitura 2012 - największa bezpłatna konferencja programistyczna -
http://confitura.pl
KO Warsjawa 2012 - warszawskie jesienne warsztaty javowe -
http://warsjawa.pl

[Krzysztof Miksa]

Ja również z chęcią bym wziął udział w warsztatach :)

W dniu 26 kwietnia 2012 18:41 użytkownik Bartek Zdanowski
<bartek.z...@gmail.com> napisał:

[Krzysztof Nielepkowicz]

Ja r�wnie� si� pisz� :) I na warsztaty te�.

Ja ( i pewnie nie tylko) ch�tnie bym zobaczy� jak si� sprawuje scala w aplikacjach enterprise.� Do�� wa�nym aspektem jest pokrycie testami kodu w scali (nie znam scali i narazie ci�ko mi sobie wyobrazi� czy si� da ;p ) Inna sprawa to integracja z kodem w javie (kt�rego pewnie b�dzie sporo wi�cej) i testowanie stabilno�ci tego rozwi�zania - ponownie temat test�w.� Kolejna rzecz - jako� na pocz�tku roku by� temat o scali i.... nie zaprezentowa�a si� jako wiarygodna technologia bo... prowadz�cy opowiada� �e nierzadko mu si� zdarza�o zostawia� dzia�aj�cy projekt, nast�pnego dnia bez wprowadzenia zmian, w spos�b magiczny si� popsu� i nie chcia� si� kompilowa�, eclipse strajkowa� (pokazywa� �rodkowy palec) i pomaga�o albo stworzenie projektu na nowo, a tak w og�le to odradza� eclipse i zaleca� prac� z linii polece� i mavenem ;p

og�lnie wtedy uzna�em �e temat powrotu do linii polece� mnie przerasta :P

--
Serdecznie Pozdrawiam,
Krzysztof Nielepkowicz
fotografia : fotomilo.pl
m�j programistyczny blog : http://kyniek.blogspot.com/

Drodzy WJUGowcy,

ďż˝

Nazywam si� Grzegorz Balcerek. Jestem autorem ksi��ki o j�zyku Scala
(http://www.grzegorzbalcerek.net/jps.html)
Chcia�bym si� Was spyta�, czy byliby�cie zainteresowani jak��
prezentacj�/spotkaniem na temat j�zyka Scala.
W przypadku zainteresowania, ze swojej strony chcia�bym opr�cz propagowania
Scali pokaza� swoj� ksi��k� i mo�e sk�oni� kogo� do jej kupna.

ďż˝

Nie proponujďż˝ jakiegoďż˝ konkretnego, jednego tematu, a raczej kilka do

dyskusji - nie wiem co Wam najbardziej odpowiada, co Was interesuje.

ďż˝

Najbardziej mi odpowiadaj�c� form� (ze wzgl�du na konieczno��
przeznaczenia dodatkowo czasu na dojazd i powr�t do Poznania) by�yby
jakie� warsztaty w ci�gu dnia, pewnie jak�� w
sobot�. Takie spotkanie mo�e by� d�u�sze ni� zwyk�e JUGowe.
Pytanie tylko, czy co� takiego wchodzi w gr� ze wzgl�d�w organizacyjnych -
to zdaje si� nie jest standardowa forma Waszych spotka�; potrzebna, by by�a
jakaďż˝ sala.

ďż˝

Alternatyw� jest zwyk�a prezentacja na spotkaniu w normalnym terminie. Mo�e
by� wprowadzenie do Scali, mo�e by� co� bardziej zaawansowanego - ale wtedy
raczej dla os�b kt�re ju� co� wiedz� o Scali, przynajmniej podstawy, �eby
nie traciďż˝ czasu - np. o DSLach, o wtyczkach kompilatora, o bibliotece
"parsers combinators". Mo�e macie jakie� inne sugestie tematu?

ďż˝

Pozdrawiam,
Grzegorz Balcerek

--
Wiadomo�� z grupy Warszawa Java User Group (Warszawa JUG).
Wi�cej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zach�camy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

[Andrzej Dubaj]

Witam 

ja również jestem zainteresowany 

W dniu 26 kwietnia 2012 21:20 użytkownik Krzysztof Nielepkowicz <k.p.niel...@gmail.com> napisał:

Ja również się piszę :) I na warsztaty też.

Ja ( i pewnie nie tylko) chętnie bym zobaczył jak się sprawuje scala w aplikacjach enterprise.  Dość ważnym aspektem jest pokrycie testami kodu w scali (nie znam scali i narazie ciężko mi sobie wyobrazić czy się da ;p ) Inna sprawa to integracja z kodem w javie (którego pewnie będzie sporo więcej) i testowanie stabilności tego rozwiązania - ponownie temat testów.  Kolejna rzecz - jakoś na początku roku był temat o scali i.... nie zaprezentowała się jako wiarygodna technologia bo... prowadzący opowiadał że nierzadko mu się zdarzało zostawiać działający projekt, następnego dnia bez wprowadzenia zmian, w sposób magiczny się popsuł i nie chciał się kompilować, eclipse strajkował (pokazywał środkowy palec) i pomagało albo stworzenie projektu na nowo, a tak w ogóle to odradzał eclipse i zalecał pracę z linii poleceń i mavenem ;p

ogólnie wtedy uznałem że temat powrotu do linii poleceń mnie przerasta :P

--
Serdecznie Pozdrawiam,
Krzysztof Nielepkowicz
fotografia : fotomilo.pl

mój programistyczny blog : http://kyniek.blogspot.com/

Drodzy WJUGowcy,

 

Nazywam się Grzegorz Balcerek. Jestem autorem książki o języku Scala
(http://www.grzegorzbalcerek.net/jps.html)
Chciałbym się Was spytać, czy bylibyście zainteresowani jakąś
prezentacją/spotkaniem na temat języka Scala.
W przypadku zainteresowania, ze swojej strony chciałbym oprócz propagowania
Scali pokazać swoją książkę i może skłonić kogoś do jej kupna.

 

Nie proponuję jakiegoś konkretnego, jednego tematu, a raczej kilka do

dyskusji - nie wiem co Wam najbardziej odpowiada, co Was interesuje.

Najbardziej mi odpowiadającą formą (ze względu na konieczność
przeznaczenia dodatkowo czasu na dojazd i powrót do Poznania) byłyby
jakieś warsztaty w ciągu dnia, pewnie jakąś w
sobotę. Takie spotkanie może być dłuższe niż zwykłe JUGowe.
Pytanie tylko, czy coś takiego wchodzi w grę ze względów organizacyjnych -
to zdaje się nie jest standardowa forma Waszych spotkań; potrzebna, by była
jakaś sala.

 

Alternatywą jest zwykła prezentacja na spotkaniu w normalnym terminie. Może
być wprowadzenie do Scali, może być coś bardziej zaawansowanego - ale wtedy
raczej dla osób które już coś wiedzą o Scali, przynajmniej podstawy, żeby
nie tracić czasu - np. o DSLach, o wtyczkach kompilatora, o bibliotece
"parsers combinators". Może macie jakieś inne sugestie tematu?

 

Pozdrawiam,
Grzegorz Balcerek

--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

[Jacek Laskowski]

On Thu, Apr 26, 2012 at 3:57 PM, Grzegorz Balcerek
<gbalc...@gmail.com> wrote:

> W przypadku zainteresowania, ze swojej strony chciałbym oprócz propagowania
> Scali pokazać swoją książkę i może skłonić kogoś do jej kupna.

Ja ustawiłbym konieczność kupna książki jako warunek konieczny udziału
w warsztacie.

> Najbardziej mi odpowiadającą formą (ze względu na konieczność
> przeznaczenia dodatkowo czasu na dojazd i powrót do Poznania) byłyby
> jakieś warsztaty w ciągu dnia, pewnie jakąś w
> sobotę. Takie spotkanie może być dłuższe niż zwykłe JUGowe.
> Pytanie tylko, czy coś takiego wchodzi w grę ze względów organizacyjnych -
> to zdaje się nie jest standardowa forma Waszych spotkań; potrzebna, by była
> jakaś sala.

To jest do załatwienia. Sal na MIMUWie jest dosyć, aby uruchomić
warsztaty. Powiedz, ile osób zaakceptowałbyś na warsztatach i kiedy, i
załatwiamy.

> Alternatywą jest zwykła prezentacja na spotkaniu w normalnym terminie.

Ująłbym to jednak tak: s/Alternatywą/Dodatkowo. Proponuję 19.06.2012 w
godzinach 18:00 - 20:30. Możemy dopasować spotkanie godzinowo do
Twojej wizyty w Warszawie, np. rozpocząć wcześniej, np. 17:00. W końcu
nie codzień mamy takiego gościa i temat!

Jacek

--
Jacek Laskowski
Functional languages (Clojure), Java EE, and IBM WebSphere -
http://blog.japila.pl
"Never discourage anyone who continually makes progress, no matter how
slow." Plato

[Jakub Nabrdalik]

On 26.04.2012 21:48, Jacek Laskowski wrote:
> On Thu, Apr 26, 2012 at 3:57 PM, Grzegorz Balcerek
> <gbalc...@gmail.com> wrote:
>
>> W przypadku zainteresowania, ze swojej strony chciałbym oprócz propagowania
>> Scali pokazać swoją książkę i może skłonić kogoś do jej kupna.
>
> Ja ustawiłbym konieczność kupna książki jako warunek konieczny udziału
> w warsztacie.

Dzięki Jacek. W imieniu wszystkich którzy mieli nadzieję na darmowe
szkolenie ze Scali i ewentualne PÓŹNIEJSZE podjęcie decyzji czy warto
inwestować w technologię i książkę, pobożne bóg zapłać :]

--
Jakub Nabrdalik
blog.solidcraft.eu

[Jakub Nabrdalik]

On 26.04.2012 15:57, Grzegorz Balcerek wrote:
> Drodzy WJUGowcy,
> Nazywam się Grzegorz Balcerek. Jestem autorem książki o języku Scala
> (http://www.grzegorzbalcerek.net/jps.html)
> Chciałbym się Was spytać, czy bylibyście zainteresowani jakąś
> prezentacją/spotkaniem na temat języka Scala.

Jak najbardziej.
+1

--
Jakub Nabrdalik
blog.solidcraft.eu

[Łukasz Żuchowski]

+1

W dniu 26 kwietnia 2012 22:13 użytkownik Jakub Nabrdalik
<jak...@gmail.com> napisał:

> --
> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
> Więcej informacji na stronie
> http://groups.google.com/group/warszawa-jug?hl=pl
> Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
> Oferty pracy dozwolone zgodnie z zasadami na
> http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie



--

Pozdrawiam,

Łukasz

[Marcin Zajączkowski]

On 2012-04-26 15:57, Grzegorz Balcerek wrote:
> Drodzy WJUGowcy,
>
> Nazywam się Grzegorz Balcerek. Jestem autorem książki o języku Scala
> (http://www.grzegorzbalcerek.net/jps.html)
> Chciałbym się Was spytać, czy bylibyście zainteresowani jakąś
> prezentacją/spotkaniem na temat języka Scala.
> W przypadku zainteresowania, ze swojej strony chciałbym oprócz propagowania
> Scali pokazać swoją książkę i może skłonić kogoś do jej kupna.
>
> Nie proponuję jakiegoś konkretnego, jednego tematu, a raczej kilka do
> dyskusji - nie wiem co Wam najbardziej odpowiada, co Was interesuje.
>
> Najbardziej mi odpowiadającą formą (ze względu na konieczność
> przeznaczenia dodatkowo czasu na dojazd i powrót do Poznania) byłyby
> jakieś warsztaty w ciągu dnia, pewnie jakąś w
> sobotę. Takie spotkanie może być dłuższe niż zwykłe JUGowe.
> Pytanie tylko, czy coś takiego wchodzi w grę ze względów organizacyjnych -
> to zdaje się nie jest standardowa forma Waszych spotkań; potrzebna, by była
> jakaś sala.

Szkoda, że Jesienne Warsztaty Javowe (JVMowe ;) ) są dopiero na jesieni.
Wtedy pewnie bezproblemowo mógłby się odbyć całodniowy warsztat o Scali.

Niemniej jeżeli teraz udałoby się coś zorganizować, to również byłoby
ciekawie.

Pozdrawiam
Marcin

> Alternatywą jest zwykła prezentacja na spotkaniu w normalnym terminie. Może
> być wprowadzenie do Scali, może być coś bardziej zaawansowanego - ale wtedy
> raczej dla osób które już coś wiedzą o Scali, przynajmniej podstawy, żeby
> nie tracić czasu - np. o DSLach, o wtyczkach kompilatora, o bibliotece
> "parsers combinators". Może macie jakieś inne sugestie tematu?
>
> Pozdrawiam,
> Grzegorz Balcerek
>

--
http://blog.solidsoft.info/ - Working code is not enough

[Dawid Bielecki]

+1
--
Regards/Pozdrawiam,

Dawid Bielecki
http://www.dawciobiel.com
e-mail: dawciobiel AT gmail DOT com

[Grzegorz Balcerek]

Cze��,

Skoro jest zainteresowanie i mo�liwo�� przeprowadzenia warsztat�w, to
wobec tego proponujďż˝ termin sobotni, najlepiej z mojego punktu
widzenia 12 maja (lub nawet ju� 5 maja). Troszk� mniej ch�tnie, ale te� jak
najbardziej mogďż˝ przyjechaďż˝ w kolejne soboty: 19, 26 maja, 2 i
ewentualnie 9 czerwca. Potem ju� jest EURO, a proponowa�bym warsztaty
zrobiďż˝ zanim siďż˝ mistrzostwa zacznďż˝.

Proponuj� rozpocz�� o 10:30 i zaplanowa� wst�pnie 4 godziny. Wolicie d�u�ej?

Nie, nie chc� wymaga� kupna ksi��ki od uczestnik�w i mo�e kogo� w ten
spos�b zniech�ci�. Mo�e kto�, kto ma ju� ksi��k� te� zechce
uczestniczy�? Ale oczywi�cie ch�tni do kupna ksi��ki b�d� mile widziani.

Nie chc� nak�ada� g�rnego limitu na liczb� os�b. Z mojego punktu widzenia
ile sala pomie�ci tyle mo�e przyj��. Setek uczestnik�w si� nie
spodziewam przecieďż˝.

Jak macie jakie� sugestie dotycz�ce przebiegu warsztat�w to piszcie. Ale
chyba m�g�bym rozpocz�� od podstaw, co� omawia� i pokazywa�, a potem te�
reagowaďż˝ juďż˝ dynamicznie na wasze pytania i sugerowane tematy dalsze.
Nale�a�oby przyj�� z w�asnym komputerem, �eby samemu te� mie� mo�liwo��
kodowania.

Co do ewentualnego kolejnego spotkania 19 czerwca to jeszcze mo�emy
podyskutowaďż˝. Widzďż˝ zainteresowanie warsztatami i to mi teďż˝ bardziej pasuje.

Pozdrawiam,
Grzegorz

[Krzysztof Miksa]

-1 dla 5 maja
+1 dla 12 maja ;)

4h? tak krótko ? :P

Pozdrawiam
Krzysztof Miksa


W dniu 26 kwietnia 2012 23:39 użytkownik Grzegorz Balcerek
<gbalc...@gmail.com> napisał:
> Cześć,
>
> Skoro jest zainteresowanie i możliwość przeprowadzenia warsztatów, to
> wobec tego proponuję termin sobotni, najlepiej z mojego punktu
> widzenia 12 maja (lub nawet już 5 maja). Troszkę mniej chętnie, ale też jak
> najbardziej mogę przyjechać w kolejne soboty: 19, 26 maja, 2 i
> ewentualnie 9 czerwca.  Potem już jest EURO, a proponowałbym warsztaty
> zrobić zanim się mistrzostwa zaczną.
>
> Proponuję rozpocząć o 10:30 i zaplanować wstępnie 4 godziny. Wolicie dłużej?
>
> Nie, nie chcę wymagać kupna książki od uczestników i może kogoś w ten
> sposób zniechęcić. Może ktoś, kto ma już książkę też zechce
> uczestniczyć? Ale oczywiście chętni do kupna książki będą mile widziani.
>
> Nie chcę nakładać górnego limitu na liczbę osób. Z mojego punktu widzenia
> ile sala pomieści tyle może przyjść. Setek uczestników się nie
> spodziewam przecież.
>
> Jak macie jakieś sugestie dotyczące przebiegu warsztatów to piszcie. Ale
> chyba mógłbym rozpocząć od podstaw, coś omawiać i pokazywać, a potem też
> reagować już dynamicznie na wasze pytania i sugerowane tematy dalsze.
> Należałoby przyjść z własnym komputerem, żeby samemu też mieć możliwość
> kodowania.
>
> Co do ewentualnego kolejnego spotkania 19 czerwca to jeszcze możemy
> podyskutować. Widzę zainteresowanie warsztatami i to mi też bardziej pasuje.
>
> Pozdrawiam,
> Grzegorz

[Łukasz Żuchowski]

Proponuję wcześniej udostępnić wymagany setup i przykłady. Ułatwi to
sprawne przeprowadzenie szkolenia.

W dniu 27 kwietnia 2012 00:01 użytkownik Krzysztof Miksa
<k.m...@blogu.pl> napisał:

--
Pozdrawiam,

Łukasz

[Jacek Laskowski]

On Fri, Apr 27, 2012 at 12:02 AM, Łukasz Żuchowski
<lukasz.z...@gmail.com> wrote:
> Proponuję wcześniej udostępnić wymagany setup i przykłady. Ułatwi to
> sprawne przeprowadzenie szkolenia.

Słusznie. Projekt na githubie powinien znacząco usprawnić warsztaty.

[Michał Karolik]

świetna inicjatywa. Myślę, że możesz się zdziwić zainteresowaniem bo dużo javowców chce zajrzeć do scali na poważniej, ale jakoś zawsze coś ważniejszego się pojawia :)

5 maja według mnie nie pasuje - sporo osób będzie jeszcze na wyjeździe majowym.

[Sławek Turowicz]

Z chęcią wezmę udział w warsztatach.

--
Sławek Turowicz.
http://slawekturowicz.blogspot.com/

[Jacek Laskowski]

On Thu, Apr 26, 2012 at 11:39 PM, Grzegorz Balcerek
<gbalc...@gmail.com> wrote:

> Skoro jest zainteresowanie i możliwość przeprowadzenia warsztatów, to
> wobec tego proponuję termin sobotni, najlepiej z mojego punktu
> widzenia 12 maja (lub nawet już 5 maja). Troszkę mniej chętnie, ale też jak
> najbardziej mogę przyjechać w kolejne soboty: 19, 26 maja, 2 i
> ewentualnie 9 czerwca.  Potem już jest EURO, a proponowałbym warsztaty
> zrobić zanim się mistrzostwa zaczną.
>
> Proponuję rozpocząć o 10:30 i zaplanować wstępnie 4 godziny. Wolicie dłużej?

Tak, zdecydowanie dłużej - więcej poniżej. Odnośnie daty - już pytam.
Zacznę od załatwienia 5 maja, z możliwością przesunięcia na kolejne
soboty.

> Jak macie jakieś sugestie dotyczące przebiegu warsztatów to piszcie. Ale
> chyba mógłbym rozpocząć od podstaw, coś omawiać i pokazywać, a potem też
> reagować już dynamicznie na wasze pytania i sugerowane tematy dalsze.
> Należałoby przyjść z własnym komputerem, żeby samemu też mieć możliwość
> kodowania.

Doświadczenie pokazuje, że należałoby wcześniej samodzielnie ustawić
agendę i podać ją do publicznej wiadomości. W końcu zakładamy
nowicjuszy, którzy nie wiedzą, co miałoby być wartościowe.

Dla mnie odpowiednią agendą byłoby przejście przez kolejne rozdziały
Twojej książki - http://www.grzegorzbalcerek.net/jps/toc.html. Do
rozdziału 21 włącznie poświęciłbym po 10 minut + 5 minut
dyskusji/przerwy/cokolwiek, co już daje 5,25h. Na ostatnie 0,75h
dałbym tworzenie aplikacji - podobnie do rozdziału 28.

[Adam Pierzchała]

On 26 April 2012 23:39, Grzegorz Balcerek <gbalc...@gmail.com> wrote:

Cześć,

Skoro jest zainteresowanie i możliwość przeprowadzenia warsztatów, to

wobec tego proponuję termin sobotni, najlepiej z mojego punktu

widzenia 12 maja (lub nawet już 5 maja). Troszkę mniej chętnie, ale też jak

najbardziej mogę przyjechać w kolejne soboty: 19, 26 maja, 2 i

ewentualnie 9 czerwca.  Potem już jest EURO, a proponowałbym warsztaty
zrobić zanim się mistrzostwa zaczną.

+1 dla 19.05

-1 dla 5.05 i 12.05 :(

-- 
Pozdrawiam / Best Regards

Adam Pierzchała 

[Bartek Kuczyński]

+1 dla 19.05


Pozdrawiam
Bartek "Koziołek" Kuczyński
http://koziolekweb.pl
Lepiej pomyśleć dwa razy i zacząć programować
niż dwa razy programować i potem zacząć myśleć
 \     /
 ~00~
  \_/
   |||


W dniu 27 kwietnia 2012 10:01 użytkownik Adam Pierzchała
<pierzch...@gmail.com> napisał:

[Agnieszka Sujewicz]

+1 na każdy termin późniejszy niż 5.5.12



W dniu 27 kwietnia 2012 10:03 użytkownik Bartek Kuczyński
<bjkuc...@gmail.com> napisał:

[Dominik Wiernicki]

+1 dla warsztatów 

-1 dla 12.05

[Bartek Zdanowski]

Jeśli będziecie wspólnie ustalać termin, to prawdopodobnie nigdy się
nie spotkamy. Fajnie jest uwzględnić termin większości.

2012/4/27 Dominik Wiernicki <dmn...@gmail.com>:

[Radosław Szmit]

W dniu 27 kwietnia 2012 10:53 użytkownik Bartek Zdanowski <bartek.z...@gmail.com> napisał:

Jeśli będziecie wspólnie ustalać termin, to prawdopodobnie nigdy się
nie spotkamy. Fajnie jest uwzględnić termin większości.

Może by tak, skoro to Grzegorz będzie prowadził warsztaty na które specjalnie przyjeżdża do Warszawy, zdecydować się na dzień przez Niego samego zaproponowany, czyli 12 maja? Przy każdym terminie komuś będzie nie pasować, a ten będzie najbardziej pasował Grzegorzowi. Jedynie drugi termin; 5 maja, może być gorszy jeśli chodzi o frekwencję bo sporo osób z Warszawy wyjeżdża na 9 dniowy urlop w pierwszym tygodniu maja ;)

--
Pozdrawiam serdecznie
Radosław Szmit

[Jakub Nabrdalik]

On 27.04.2012 11:22, Radosław Szmit wrote:
>
> W dniu 27 kwietnia 2012 10:53 użytkownik Bartek Zdanowski

> <bartek.z...@gmail.com <mailto:bartek.z...@gmail.com>> napisał:

>
> Jeśli będziecie wspólnie ustalać termin, to prawdopodobnie nigdy się
> nie spotkamy. Fajnie jest uwzględnić termin większości.
>
>
> Może by tak, skoro to Grzegorz będzie prowadził warsztaty na które
> specjalnie przyjeżdża do Warszawy, zdecydować się na dzień przez Niego
> samego zaproponowany, czyli 12 maja? Przy każdym terminie komuś będzie
> nie pasować, a ten będzie najbardziej pasował Grzegorzowi. Jedynie drugi
> termin; 5 maja, może być gorszy jeśli chodzi o frekwencję bo sporo osób
> z Warszawy wyjeżdża na 9 dniowy urlop w pierwszym tygodniu maja ;)

+1 Mądrze prawisz.

--
Jakub Nabrdalik
blog.solidcraft.eu

[czarny_sp]

On 27/04/2012 11:38, Jakub Nabrdalik wrote:
> On 27.04.2012 11:22, Rados�aw Szmit wrote:
>>
>> W dniu 27 kwietnia 2012 10:53 u�ytkownik Bartek Zdanowski
>> <bartek.z...@gmail.com <mailto:bartek.z...@gmail.com>>
>> napisaďż˝:
>>
>> Je�li b�dziecie wsp�lnie ustala� termin, to prawdopodobnie nigdy si�
>> nie spotkamy. Fajnie jest uwzgl�dni� termin wi�kszo�ci.
>>
>>
>> Mo�e by tak, skoro to Grzegorz b�dzie prowadzi� warsztaty na kt�re
>> specjalnie przyje�d�a do Warszawy, zdecydowa� si� na dzie� przez Niego
>> samego zaproponowany, czyli 12 maja? Przy ka�dym terminie komu� b�dzie
>> nie pasowa�, a ten b�dzie najbardziej pasowa� Grzegorzowi. Jedynie drugi
>> termin; 5 maja, mo�e by� gorszy je�li chodzi o frekwencj� bo sporo os�b
>> z Warszawy wyje�d�a na 9 dniowy urlop w pierwszym tygodniu maja ;)
>
> +1 M�drze prawisz.
>
+1 !!!!

[Jacek Laskowski]

On Fri, Apr 27, 2012 at 11:22 AM, Radosław Szmit
<radosl...@gmail.com> wrote:

> Może by tak, skoro to Grzegorz będzie prowadził warsztaty na które
> specjalnie przyjeżdża do Warszawy, zdecydować się na dzień przez Niego
> samego zaproponowany, czyli 12 maja? Przy każdym terminie komuś będzie nie
> pasować, a ten będzie najbardziej pasował Grzegorzowi. Jedynie drugi termin;
> 5 maja, może być gorszy jeśli chodzi o frekwencję bo sporo osób z Warszawy
> wyjeżdża na 9 dniowy urlop w pierwszym tygodniu maja ;)

Spoko, spoko, społeczność w tym przypadku jest na równi z jednostką
(Grzegorz). Już dostałem aplauz z MIMUWu. Sala będzie!

[Piotrek]

> Mnie osobiscie interesuje integracja z java, miedzy innymi jak
> obslugiwac injectowanie zaleznosci pomiedzy java i scala.

ja tez uwazam, ze to bardzo dobry pomysl. tylko moze jednak warto
najpierw ustalic dla kogo jest wyklad i jaka ma mysl przewodnia. skoro
pytasz co nas interesuje to:
ja nie znam scali ale nie bardzo chce ogladac implementacje liczb
fibonacciego w kolejnym jezyku funkcyjnym. ale bardzo chetnie
poslucham o integracji z java, praktycznych zastosowaniach w
komercyjnych projektach, gdzie jest miejsce scali w projektach
enterprise, jak rozwijac projekt zawierajacy oba jezyki (problemy z
cyklicznymi zaleznosciami w IDE itp)

[Łukasz Siwiński]

Również jestem zainteresowany warsztatami.

- 4h to moim zdaniem za mało czasu
- 12 lub 19.V. wydaje mi się bardziej odpowiedni niż 5.V. (majówka)
- w scali nie napisałem jeszcze nawet hello world, miałem okazję wysłuchać jednej prezentacji, mam trochę doświadczenia w jee
- interesują mnie tematy związane wykorzystaniem możliwości Scala w środowisku JEE/ pokazanie na działającym kodzie jakie mogą być korzyści z korzystania z tego języka w projektach
- pomysł z wystawieniem wcześniej zajawki/kodu na github/google code jest ok

[Łukasz Siwiński]

PS : 19.V. niektóre osoby mogą być jeszcze w Poznaniu ;)

[Grzegorz Balcerek]

> ja nie znam scali ale nie bardzo chce ogladac implementacje liczb
> fibonacciego w kolejnym jezyku funkcyjnym. ale bardzo chetnie

Miejmy to już za sobą :)

scala> def fib = {
     |   def f(n1:Int,n2:Int):Stream[(Int,Int)] = (n1,n2) #:: f(n2,n1+n2)
     |   f(0,1).map(_._1)
     | }
fib: scala.collection.immutable.Stream[Int]

 

scala> fib.take(15).toList
res0: List[Int] = List(0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377)

 

Grzegorz

[Jacek Laskowski]

2012/4/28 Grzegorz Balcerek <gbalc...@gmail.com>:

>      |   f(0,1).map(_._1)

I tu raczej *oczekiwałbym* funkcji first/second/last. Jest coś
takiego? Nie podoba mi się mechanizm dostępu do listy przez ._n.

p.s. I niech mi ktoś powie, że Clojure to za dużo nawiasów i że ciężko
się przestawić, kiedy w Scali mamy _._1. Trochę czasu należy spędzić,
aby przywyknąć do możliwości składni obu języków. Zresztą dowolnego
języka.

[Grzegorz Balcerek]

Akurat chodzi o krotk�, a nie list�. _1 daje dost�p do pierwszego elementu
krotki (nie listy).
Mo�e wolisz poni�sz� sk�adni�?

scala> def fib = {
| def f(n1:Int,n2:Int):Stream[(Int,Int)] = (n1,n2) #:: f(n2,n1+n2)

| f(0,1).map{ case (n,_) => n }

| }
fib: scala.collection.immutable.Stream[Int]

scala> fib.take(15).toList

res1: List[Int] = List(0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233,
377)

Grzegorz

----- Original Message -----
From: "Jacek Laskowski" <ja...@japila.pl>
To: <warsza...@googlegroups.com>
Sent: Saturday, April 28, 2012 6:49 AM
Subject: Re: [warszawa-jug] Re: Scala


2012/4/28 Grzegorz Balcerek <gbalc...@gmail.com>:

> | f(0,1).map(_._1)

I tu raczej *oczekiwa�bym* funkcji first/second/last. Jest co�
takiego? Nie podoba mi si� mechanizm dost�pu do listy przez ._n.

p.s. I niech mi kto� powie, �e Clojure to za du�o nawias�w i �e ci�ko
si� przestawi�, kiedy w Scali mamy _._1. Troch� czasu nale�y sp�dzi�,
aby przywykn�� do mo�liwo�ci sk�adni obu j�zyk�w. Zreszt� dowolnego
j�zyka.

Jacek

--
Jacek Laskowski
Functional languages (Clojure), Java EE, and IBM WebSphere -
http://blog.japila.pl
"Never discourage anyone who continually makes progress, no matter how
slow." Plato

--
Wiadomo�� z grupy Warszawa Java User Group (Warszawa JUG).
Wi�cej informacji na stronie
http://groups.google.com/group/warszawa-jug?hl=pl
Zach�camy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

[Bartek Kuczyński]

Jacku tu akurat jest po prostu niekonsekwentnie oznaczono element
krotki. Bardziej przyjaznym i zrozumiałym zapisem było by

(1, 2).map(_.$1)

ponieważ nie myliło by się _ oznaczające bieżący element mapy i _ od
którego zaczyna się nazwa elementu krotki.

Pozdrawiam
Bartek "Koziołek" Kuczyński
http://koziolekweb.pl
Lepiej pomyśleć dwa razy i zacząć programować
niż dwa razy programować i potem zacząć myśleć
 \     /
 ~00~
  \_/
   |||

W dniu 28 kwietnia 2012 11:14 użytkownik Grzegorz Balcerek
<gbalc...@gmail.com> napisał:
> Akurat chodzi o krotkę, a nie listę. _1 daje dostęp do pierwszego elementu
> krotki (nie listy).
> Może wolisz poniższą składnię?

>
>
> scala> def fib = {
>    |   def f(n1:Int,n2:Int):Stream[(Int,Int)] = (n1,n2) #:: f(n2,n1+n2)
>    |   f(0,1).map{ case (n,_) => n }
>
>    | }
> fib: scala.collection.immutable.Stream[Int]
>
> scala> fib.take(15).toList
> res1: List[Int] = List(0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233,
> 377)
>
> Grzegorz
>
> ----- Original Message ----- From: "Jacek Laskowski" <ja...@japila.pl>
> To: <warsza...@googlegroups.com>
> Sent: Saturday, April 28, 2012 6:49 AM
> Subject: Re: [warszawa-jug] Re: Scala
>
>
>
> 2012/4/28 Grzegorz Balcerek <gbalc...@gmail.com>:
>
>> | f(0,1).map(_._1)
>
>

> I tu raczej *oczekiwałbym* funkcji first/second/last. Jest coś
> takiego? Nie podoba mi się mechanizm dostępu do listy przez ._n.
>
> p.s. I niech mi ktoś powie, że Clojure to za dużo nawiasów i że ciężko
> się przestawić, kiedy w Scali mamy _._1. Trochę czasu należy spędzić,
> aby przywyknąć do możliwości składni obu języków. Zresztą dowolnego
> języka.
>

> Jacek
>
> --
> Jacek Laskowski
> Functional languages (Clojure), Java EE, and IBM WebSphere -
> http://blog.japila.pl
> "Never discourage anyone who continually makes progress, no matter how
> slow." Plato
>
> --

> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
> Więcej informacji na stronie
> http://groups.google.com/group/warszawa-jug?hl=pl
> Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

> Oferty pracy dozwolone zgodnie z zasadami na
> http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

> --
> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
> Więcej informacji na stronie
> http://groups.google.com/group/warszawa-jug?hl=pl
> Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

[Grzegorz Balcerek]

Oj poprawiacze :)
Znak $ jest stosowany w identyfikatorach generowanych przez kompilator i zwykły kod nie powinien go stosować.
Jak już ktoś naprawdę nie może znieść nazwy _1, to może zrobić tak:

 

scala> implicit def tuple2conv[A,B](t: Tuple2[A,B]) = new { def mojaUlubionaNazwaPierwszegoElementuKrotki = t._1 }
tuple2conv: [A, B](t: (A, B))java.lang.Object{def mojaUlubionaNazwaPierwszegoElementuKrotki: A}

 

scala> def fib = {
     |   def f(n1:Int,n2:Int):Stream[(Int,Int)] = (n1,n2) #:: f(n2,n1+n2)

     |   f(0,1).map(_.mojaUlubionaNazwaPierwszegoElementuKrotki)
     | }
fib: scala.collection.immutable.Stream[Int]

 

scala> fib.take(15).toList
res0: List[Int] = List(0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377)
 
Grzegorz

[Grzegorz Balcerek]

Cześć,

 

Odpowiadam zbiorczo na różne tematy.

 

> (...) Już dostałem aplauz z MIMUWu. Sala będzie!

 

A w jakim terminie będzie? Odnośnie terminu: zdaję sobie sprawę, że
12 maja nie każdemu może pasować. Czy znacie termin, który każdemu
pasuje? Proponuję ustalić 12 maja, jeśli ten termin jest możliwy.

 

Ja chętnie przyjechałbym ponownie i powtórzył albo kontynuował
warsztaty, z tym jednak zastrzeżeniem/warunkiem, że chciałbym żeby się
dało znaleźć jakąś formułę żebym nie dokładał do interesu (podróże
kosztują). To się tyczy również ewentualnego spotkania 19
czerwca. Jakiś sponsor?

 

> - 4h to moim zdaniem za mało czasu

 

Proponowana data, godzina spotkania i czas trwania są związane z
posiadanym już przeze mnie biletem (karnetem) kolejowym, który mógłbym
wykorzystać oraz z rozkładem jazdy pociągów. Jakby ktoś mógł mnie
dowieźć/odwieźć z/na dworzec to troszkę czasu można by dodatkowo
uzyskać.

 

> ja tez uwazam, ze to bardzo dobry pomysl. tylko moze jednak warto

> najpierw ustalic dla kogo jest wyklad i jaka ma mysl przewodnia. (...)

 

Ustalam:
Dla kogo: dla początkujących i nieznających języka
(choć nie mam nic przeciwko przyjściu również zaawansowanych osób)
Myśl przewodnia nr 1: zaprezentowanie języka Scala.
Myśl przewodnia nr 2: zainteresowanie Was tym językiem.
Myśl przewodnia nr 3: umożliwienie samodzielnego kontynuowania tego
zainteresowania (czyli sprzedanie jak największej liczby książek :)

 

Przyjąłem również do wiadomości zainteresowanie integracją z kodem
pisanym w języku Java. Temat możemy poruszyć.

 

> (...) ale bardzo chetnie
> poslucham o (...) praktycznych zastosowaniach w

> komercyjnych projektach, gdzie jest miejsce scali w projektach
> enterprise, jak rozwijac projekt zawierajacy oba jezyki (problemy z
> cyklicznymi zaleznosciami w IDE itp)

 

Może kogoś rozczaruję, ale nie zajmuję się pisaniem w Scali w
komercyjnych projektach enterprise. (Czy ktoś chciałby to zmienić?)
Więc mogę nie być najlepszą osobą do tego rodzaju rozważań.

 

> interesują mnie tematy związane wykorzystaniem możliwości Scala w środowisku JEE

 

Nie znam JEE w najnowszym odsłonach. Więc, jak wyżej.

 

> Ja ( i pewnie nie tylko) chętnie bym zobaczył jak się sprawuje scala w
> aplikacjach enterprise. (...)

 

Patrz wyżej.
Oczywiście podyskutować o różnych sprawach możemy, nawet jeśli ja nie znam się na wszystkim.
Czy nie macie czasem przesadnych obaw przed zastosowaniem Scali w projektach? :)
Przecież nawet w języku Java ludzie piszą i jakoś im się udaje lepiej
lub gorzej! :)

 

> Dla mnie odpowiednią agendą byłoby przejście przez kolejne rozdziały
> Twojej książki - http://www.grzegorzbalcerek.net/jps/toc.html. Do
> rozdziału 21 włącznie poświęciłbym po 10 minut + 5 minut
> dyskusji/przerwy/cokolwiek, co już daje 5,25h. Na ostatnie 0,75h
> dałbym tworzenie aplikacji - podobnie do rozdziału 28.

 

Nie wydaje mi się, że taki sztywny dosyć plan to realistyczny
pomysł. Chyba, że nie będziecie zadawać pytań. Poza tym myślę, że przy
spotkaniu na żywo nie trzeba się tak ściśle trzymać określonej
kolejności, jak to jest w przypadku książki. Po zastanowieniu tak bym
to widział: Pokazywałbym na rzutniku i omawiał różne rzeczy (myślę, że
z preferencją kodowania i pokazywania przykładów na żywo raczej niż
slajdów).  Wybierałbym kolejne tematy według własnego
rozeznania/uznania i/lub uwzględniał/reagował na Wasze pytania i
sugestie na bieżąco.  Sugeruję raczej kodowanie "wspólne" - czyli ja
piszę na moim komputerze, a Wy to oglądacie na rzutniku i
komentujecie/pytacie/rzucacie pomysłami/uwagami. Wtedy wszyscy mogą
korzystać z wyjaśnień.  W związku z tym nie byłoby wymagane
przyniesienie własnego komputera, ale jakby ktoś miał i chciał sam
próbować na swoim, a potem dopytywać o coś, to też nie mam nic
przeciwko.

 

> Proponuję wcześniej udostępnić wymagany setup i przykłady. Ułatwi to
> sprawne przeprowadzenie szkolenia.

 

W związku z powyższym nie ma wymaganego setupu.

 

> (...) Dość ważnym aspektem jest pokrycie testami
> kodu w scali (nie znam scali i narazie ciężko mi sobie wyobrazić czy
> się da ;p )  (...)

 

O co chodzi? Czy co się da? Czy da się kod testować?

 

> (...) Kolejna rzecz - jakoś na początku roku był
> temat o scali i.... nie zaprezentowała się jako wiarygodna technologia
> bo... prowadzący opowiadał że nierzadko mu się zdarzało zostawiać
> działający projekt, następnego dnia bez wprowadzenia zmian, w sposób
> magiczny się popsuł i nie chciał się kompilować, eclipse strajkował
> (pokazywał środkowy palec) i pomagało albo stworzenie projektu na
> nowo, a tak w ogóle to odradzał eclipse i zalecał pracę z linii
> poleceń i mavenem ;p

 

Czy mówił którą wersję wtyczki do eclipse używał?  W grudniu została
opublikowana wersja 2.0.
http://scala-ide.org/blog/release-notes-2.0.html
Może używał wcześniejszej?  No, a jeśli projekt rzeczywiście psuł się
w sposób "magiczny" to nawet najnowsza wersja wtyczki może nie dać
rady....

 

> p.s. I niech mi ktoś powie, że Clojure to za dużo nawiasów (...)

 

Raczej nie narzekałbym na liczbę nawiasów, ale jeśli już to na to, że
zbyt często są używane kwadratowe, zamiast trzymać się okrągłych. Ale
to nie takie ważne.

 

Pozdrawiam,
Grzegorz

[Jacek Laskowski]

2012/4/28 Grzegorz Balcerek <gbalc...@gmail.com>:
> Akurat chodzi o krotkę, a nie listę. _1 daje dostęp do pierwszego elementu
> krotki (nie listy).

Ach, racja. Dla mnie krotka to nic innego jak dwuelementowa lista.

> scala> def fib = {
>    |   def f(n1:Int,n2:Int):Stream[(Int,Int)] = (n1,n2) #:: f(n2,n1+n2)
>    |   f(0,1).map{ case (n,_) => n }
>
>    | }
> fib: scala.collection.immutable.Stream[Int]

Powiedzmy, że muszę do tego przywyknąć. Trochę za wiele tych nawiasów
:) Skoro mogłem w Clojure, to mogę i w Scali.

[Jacek Laskowski]

2012/4/30 Grzegorz Balcerek <gbalc...@gmail.com>:

>> (...) Już dostałem aplauz z MIMUWu. Sala będzie!
>
> A w jakim terminie będzie? Odnośnie terminu: zdaję sobie sprawę, że
> 12 maja nie każdemu może pasować. Czy znacie termin, który każdemu
> pasuje? Proponuję ustalić 12 maja, jeśli ten termin jest możliwy.

Zgodnie z życzeniem. Mamy 3180, 12 maja w godzinach 10-18 do naszej dyspozycji.

Przy okazji: "(Aktualny stan zajętości sal można sprawdzić na stronie
srs.mimuw.edu.pl )"

Proszę potwierdź Twoją dostępność i zaczynamy nagłaśnianie. Pewnie
należałoby uruchomić rejestrację na oiola czy podobnie (chyba, że nie
ma znaczenia, ile osób przyjdzie). Należałoby znaleźć sponsora. Na
pewno przydadzą się napoje.

Wszyscy: znamy firmę, której zależy, aby jej nazwa widniała przy
wjugowym warsztacie Scala? Kto mógłby poprowadzić dyskusję z nią?

[Grzegorz Balcerek]

Tak, potwierdzam 12 maja i nie uzale�niam pojawienia si� w tym terminie od
sponsora. Je�li mnie nie przekonacie skutecznie do zmiany plan�w, to planuj�
przyjecha� poci�giem, kt�ry przyje�d�a na centralny o 10:06 (o 10:00 na
dworzec zachodni), a wyje�d�a� pociagiem o 15:09 z dworca centralnego (lub
15:14 z zachodniego). Odpowiednio do tego trzeba dostosowaďż˝ godziny
spotkania. Zdaje si�, �e nie jest bardzo daleko od tych dworc�w do miejsca
spotkania. Nie mam wymaga� co do maksymalnej liczby uczestnik�w, nie znam
zreszt� wielko�ci sali. Z mojego punktu widzenia im wi�cej os�b tym lepiej.
Pozdtawiam,
Grzegorz Balcerek

----- Original Message -----
From: "Jacek Laskowski" <ja...@japila.pl>
To: <warsza...@googlegroups.com>
Sent: Tuesday, May 01, 2012 8:21 PM
Subject: Re: [warszawa-jug] Re: Scala

2012/4/30 Grzegorz Balcerek <gbalc...@gmail.com>:

>> (...) Ju� dosta�em aplauz z MIMUWu. Sala b�dzie!
>
> A w jakim terminie b�dzie? Odno�nie terminu: zdaj� sobie spraw�, �e
> 12 maja nie ka�demu mo�e pasowa�. Czy znacie termin, kt�ry ka�demu
> pasuje? Proponuj� ustali� 12 maja, je�li ten termin jest mo�liwy.

Zgodnie z �yczeniem. Mamy 3180, 12 maja w godzinach 10-18 do naszej
dyspozycji.

Przy okazji: "(Aktualny stan zaj�to�ci sal mo�na sprawdzi� na stronie
srs.mimuw.edu.pl )"

Prosz� potwierd� Twoj� dost�pno�� i zaczynamy nag�a�nianie. Pewnie
nale�a�oby uruchomi� rejestracj� na oiola czy podobnie (chyba, �e nie
ma znaczenia, ile os�b przyjdzie). Nale�a�oby znale�� sponsora. Na
pewno przydadzďż˝ siďż˝ napoje.

Wszyscy: znamy firm�, kt�rej zale�y, aby jej nazwa widnia�a przy
wjugowym warsztacie Scala? Kto m�g�by poprowadzi� dyskusj� z ni�?

Jacek

--
Jacek Laskowski
Functional languages (Clojure), Java EE, and IBM WebSphere -
http://blog.japila.pl
"Never discourage anyone who continually makes progress, no matter how
slow." Plato

--
Wiadomo�� z grupy Warszawa Java User Group (Warszawa JUG).
Wi�cej informacji na stronie
http://groups.google.com/group/warszawa-jug?hl=pl
Zach�camy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

[Jacek Laskowski]

2012/5/2 Grzegorz Balcerek <gbalc...@gmail.com>:
> Tak, potwierdzam 12 maja

Niestety, już wiem, że mnie nie będzie, bo będę w...Poznaniu jako
prowadzący studia podyplomowe. W końcu bilans musi być zachowany :)

Kto mógłby zająć się prelegentem i wydarzeniem? Pomogę zdalnie
oczywiście, ale fizycznie mnie nie będzie :(

[Grzegorz Balcerek]

> Ach, racja. Dla mnie krotka to nic innego jak dwuelementowa lista.

Natomiast dla Scali to co� zupe�nie innego.

Grzegorz

[Jacek Laskowski]

2012/5/2 Grzegorz Balcerek <gbalc...@gmail.com>:

> Natomiast dla Scali to coś zupełnie innego.

Rozumiem, że obie struktury danych mogę potraktować jak sekwencje,
więc first, second, last, rest dostępne?

[Grzegorz Balcerek]

Nie, krotka nie jest sekwencjďż˝.

scala> val a: Seq[Int] = List(1,2)
a: Seq[Int] = List(1, 2)

scala> a.head
res0: Int = 1

scala> a.last
res1: Int = 2

scala> a.tail
res2: Seq[Int] = List(2)

scala> val b: Seq[Int] = (1,2)
<console>:7: error: type mismatch;
found : (Int, Int)
required: Seq[Int]
val b: Seq[Int] = (1,2)
^

Grzegorz

----- Original Message -----
From: "Jacek Laskowski" <ja...@japila.pl>
To: <warsza...@googlegroups.com>
Sent: Wednesday, May 02, 2012 7:57 PM
Subject: Re: [warszawa-jug] Re: Scala

2012/5/2 Grzegorz Balcerek <gbalc...@gmail.com>:

> Natomiast dla Scali to co� zupe�nie innego.

Rozumiem, �e obie struktury danych mog� potraktowa� jak sekwencje,
wi�c first, second, last, rest dost�pne?

Jacek

--
Jacek Laskowski
Functional languages (Clojure), Java EE, and IBM WebSphere -
http://blog.japila.pl
"Never discourage anyone who continually makes progress, no matter how
slow." Plato

[Jacek Laskowski]

2012/5/2 Grzegorz Balcerek <gbalc...@gmail.com>:
> Nie, krotka nie jest sekwencją.
...

> scala> val b: Seq[Int] = (1,2)
> <console>:7: error: type mismatch;
> found   : (Int, Int)
> required: Seq[Int]
>      val b: Seq[Int] = (1,2)
>
>                        ^

Potrafiłbyś to wytłumaczyć? Oczywiście proszę o wytłumaczenie ideowe
nie techniczne (coś ala "bo nie realizuje interfejsu/trait'a"). W
końcu na krotkę również moglibyśmy patrzeć przez pryzmat sekwencji.
Tego bym oczekiwał. Co jest szczególnego w krotce, aby ją aż tak
odseparować od reszty (kolekcji?) ? Do czego główne stosowana?

[Grzegorz Balcerek]

Sekwencja: ci�g warto�ci okre�lonego typu o nieokre�lonej przez typ
d�ugo�ci.
Krotka: zestaw warto�ci r�nych (potencjalnie) typ�w o zdefiniowanej przez
typ d�ugo�ci (krotno�ci).
Typ sekwencji nie okre�la jej d�ugo�ci, a typ krotki tak.
Krotka ma tyle parametr�w typu jaka jest jej krotno��. Sekwencja ma jeden
parametr typu.

Grzegorz

----- Original Message -----
From: "Jacek Laskowski" <ja...@japila.pl>
To: <warsza...@googlegroups.com>
Sent: Thursday, May 03, 2012 12:17 AM
Subject: Re: [warszawa-jug] Re: Scala

2012/5/2 Grzegorz Balcerek <gbalc...@gmail.com>:
> Nie, krotka nie jest sekwencjďż˝.

...
> scala> val b: Seq[Int] = (1,2)
> <console>:7: error: type mismatch;
> found : (Int, Int)
> required: Seq[Int]
> val b: Seq[Int] = (1,2)
>
> ^

Potrafi�by� to wyt�umaczy�? Oczywi�cie prosz� o wyt�umaczenie ideowe
nie techniczne (coďż˝ ala "bo nie realizuje interfejsu/trait'a"). W
ko�cu na krotk� r�wnie� mogliby�my patrze� przez pryzmat sekwencji.
Tego bym oczekiwa�. Co jest szczeg�lnego w krotce, aby j� a� tak
odseparowa� od reszty (kolekcji?) ? Do czego g��wne stosowana?

Jacek

--
Jacek Laskowski
Functional languages (Clojure), Java EE, and IBM WebSphere -
http://blog.japila.pl
"Never discourage anyone who continually makes progress, no matter how
slow." Plato

[Jacek Laskowski]

2012/5/3 Grzegorz Balcerek <gbalc...@gmail.com>:
> Sekwencja: ciąg wartości określonego typu o nieokreślonej przez typ
> długości.
> Krotka: zestaw wartości różnych (potencjalnie) typów o zdefiniowanej przez
> typ długości (krotności).
> Typ sekwencji nie określa jej długości, a typ krotki tak.
> Krotka ma tyle parametrów typu jaka jest jej krotność. Sekwencja ma jeden
> parametr typu.

Jak rozumiem, typ elementów kolekcji wyznacza, czy mamy do czynienia z
listą czy krotką? W przeciwieństwie do Clojure, gdzie nie ma to
znaczenia. Tutaj widziałbym dyskusję, kiedy byłoby to pomocne. Masz
jakiś pomysł? Na chwilę obecną stoję na stanowisku, że więcej
przeszkadza niż pomaga (podobnie jak w Javie z typami generycznymi).

BTW, dzięki za uzmysłowienie mi różnicy między językiem statycznie
typowanym, a dynamicznie! Potrzeba mi było tego.

[Grzegorz Balcerek]

No i tu otwierasz nowy w�tek dyskusji: na temat r�nic mi�dzy j�zykami
typowanymi statycznie i dynamicznie.
Og�lnie: te pierwsze daj� pewne gwarancje sprawdzane automatycznie przez
kompilator, czego nie dajďż˝ te drugie.
To si� przek�ada na testy (kt�rych nie trzeba wykonywa�) i dokumentacj�
(kt�rej nie trzeba osobno pisa�).
Moje stanowisko jest takie �e to si� przydaje.

Jedno zastosowanie krotek podawa�em: w podanym przyk�adzie z liczbami
Fibonacciego (cho� na przyk�ad list� te� by si� da�o zastosowa�; obie
warto�ci by�y tego samego typu).
Og�lne zastosowanie: prosty pojemnik na kilka warto�ci.
My�l�, �e typowym zastosowaniem krotki mo�e by� sytuacja, w kt�rej chcemy
zwr�ci� z metody/funkcji dwie(wi�cej) warto�ci.
Krotka wraz ze statycznym typowaniem pozwala okre�li� osobno typ ka�dej z
warto�ci.
Kompilator te typy sprawdza i gwarantuje. Ponadto kompilator gwarantuje
liczb� zwracanych warto�ci.

scala> def dwieWartosci() = (1234, 'symbol)
dwieWartosci: ()(Int, Symbol)

scala> val (wartosc1, wartosc2) = dwieWartosci()
wartosc1: Int = 1234
wartosc2: Symbol = 'symbol

W przypadku listy typy w tym przyk�adzie s� zamieniane na Any (czyli wsp�lny
nadtyp Int i Symbol).

scala> def dwieWartosci2() = List(1234, 'symbol)
dwieWartosci2: ()List[Any]

scala> val List(wartosc1any, wartosc2any) = dwieWartosci2()
wartosc1any: Any = 1234
wartosc2any: Any = 'symbol

Grzegorz

[Grzegorz Balcerek]

> (...) Na chwil� obecn� stoj� na stanowisku, �e wi�cej
> przeszkadza niďż˝ pomaga (...)

Mo�esz prosz� poda� przyk�ad kiedy to przeszkadza?
Grzegorz

[Bartek Kuczyński]

Krotki przydają się chyba najbardziej jak masz jakieś zapytanie w SQL,
które nie za bardzo idzie zmapować na obiekt. Wtedy wrzucasz wyniki do
krotki i finito. Zresztą krotki są też obecne w specyfikacji JPA2 i
zazwyczaj przykłady ich użycia dotyczą obróbki wyników z Native Query.

Pozdrawiam
Bartek "Koziołek" Kuczyński
http://koziolekweb.pl
Lepiej pomyśleć dwa razy i zacząć programować
niż dwa razy programować i potem zacząć myśleć
 \     /
 ~00~
  \_/
   |||

W dniu 3 maja 2012 10:40 użytkownik Grzegorz Balcerek
<gbalc...@gmail.com> napisał:
>> (...) Na chwilę obecną stoję na stanowisku, że więcej
>> przeszkadza niż pomaga (...)
>
>
> Możesz proszę podać przykład kiedy to przeszkadza?
> Grzegorz
>
>
> --
> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
> Więcej informacji na stronie
> http://groups.google.com/group/warszawa-jug?hl=pl
> Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

[Jakub Nabrdalik]

On 03.05.2012 10:37, Grzegorz Balcerek wrote:
> Ogólne zastosowanie: prosty pojemnik na kilka wartości.
> Myślę, że typowym zastosowaniem krotki może być sytuacja, w której
> chcemy zwrócić z metody/funkcji dwie(więcej) wartości.

+1

--
Jakub Nabrdalik
blog.solidcraft.eu

[Jacek Laskowski]

2012/5/3 Grzegorz Balcerek <gbalc...@gmail.com>:
> No i tu otwierasz nowy wątek dyskusji: na temat różnic między językami
> typowanymi statycznie i dynamicznie.

Taki był mój zamiar. W końcu nauka Scali była jedynie tłem do moich
rozważań funkcyjnych :) Wybacz, że traktuję ją jako język do
doświadczeń, a Ciebie jako uczestnika.

> Ogólnie: te pierwsze dają pewne gwarancje sprawdzane automatycznie przez
> kompilator, czego nie dają te drugie.

Pełna zgoda.

> To się przekłada na testy (których nie trzeba wykonywać) i dokumentację
> (której nie trzeba osobno pisać).

Rozumiem, że piszesz o testach dot. typów, bo w Javie, Scali od testów
aż kipi. Nie inaczej jest z dokumentacją, którą zwykle są właśnie
testy. Nie inaczej będzie w językach dynamicznych. Testy będą
przydatne w obu przypadkach.

> Jedno zastosowanie krotek podawałem: w podanym przykładzie z liczbami
> Fibonacciego (choć na przykład listę też by się dało zastosować; obie
> wartości były tego samego typu).

> Ogólne zastosowanie: prosty pojemnik na kilka wartości.
> Myślę, że typowym zastosowaniem krotki może być sytuacja, w której chcemy
> zwrócić z metody/funkcji dwie(więcej) wartości.

> Krotka wraz ze statycznym typowaniem pozwala określić osobno typ każdej z
> wartości.

> Kompilator te typy sprawdza i gwarantuje. Ponadto kompilator gwarantuje

> liczbę zwracanych wartości.

Tu jednak przykład uważam za uzasadnienie sprawdzenia przez
kompilator, które podawałeś wyżej. Fibonacci oraz kontener to
przykłady równie dobre dla listy, co dla krotki. Krotka narzuca
dodatkowo jednolitość typów oraz jedynie 2 elementy.

> scala> def dwieWartosci() = (1234, 'symbol)
> dwieWartosci: ()(Int, Symbol)

Przy okazji nauczyłem się, że istnieje typ Symbol jak w Clojure.

Z kompilatorem żyłem przez lata w Javie i rozumiem jego zalety/wady.
Po ostatnich pracach teoretycznych z Clojure i F# widzę jednak, że nie
ma potrzeby pakować typów, gdzie ich nie potrzeba, bo kompilator
samodzielnie potrafi to wydedukować (w znaczącej większości
przypadków).

Scala ze swym systemem typów jest zbyt nachalna dla mnie - jakby jej
intencją było jeszcze bardziej wzmocnić pozycję kompilatora, bo w
końcu możnaby powiedzieć, że tylko wtedy system typów jest najbardziej
istotny.

W języku Dart, typy są jedynie dokumentacją i nie mają żadnego
znaczenia - są jedynie dla ludzi, a zakłada się, że jeśli kompilator
ma sprawdzać poprawność typów-dokumentacji, to po prostu taki
kompilator należy napisać. Domyślnie, go nie ma. Podobnie w F#, gdzie
nie ma takiego nacisku na typy, a jest równie statycznie/silnie
typowany co Scala. W Clojure, typy są opcjonalne i jeśli kompilator ma
problem z ich wyłuskaniem, będzie refleksja i Object (można wtedy
włączyć informowanie o tym i poprawić krytyczne miejsca).

Do czego zmierzam z moimi wynurzeniami, to wniosek, że Scala == Java++
(w obszarze kompilatora/typów) + Clojure (w obszarze programowania
funkcyjnego). Dodam, że moja znajomość Scali i F# pozwala na
stwierdzenie, że Scala == F#--.

Na chwilę obecną, jedynym przewagą Scali jest to, że jest utrzymuje
kanon programowania javowego (OO, notacja infiksowa i JVM), bez
konieczności instalowania biblioteki Guava, aby programować
funkcyjnie. Pozostałe języki skreślają się właśnie przez wymienione
powody, które właśnie są na plus i promują Scalę.

Stąd też taki oporny jestem na zrozumienie rozróżnienia między krotką
a listą, bo ostatnio głównie żyję bez jawnych typów.

[Grzegorz Balcerek]

> testy. Nie inaczej b�dzie w j�zykach dynamicznych. Testy b�d�
> przydatne w obu przypadkach.

Oczywi�cie nie twierdz�, �e testy s� zb�dne, raczej �e jest szansa na
ograniczenie ich liczby.
Kompilator sprawdzaj�c pewne w�a�ciwo�ci programu powoduje, �e testowanie
tych w�a�ciwo�ci jest niepotrzebne.

> Scala ze swym systemem typ�w jest zbyt nachalna dla mnie - jakby jej
(...)
> kompilator nale�y napisa�. Domy�lnie, go nie ma. Podobnie w F#, gdzie
> nie ma takiego nacisku na typy, a jest r�wnie statycznie/silnie
> typowany co Scala. W Clojure, typy s� opcjonalne i je�li kompilator ma

To ja poprosz� jaki� silnie typowany, ale nie "nachalny" przyk�ad w F#, �eby
zrozumieďż˝ o co chodzi.

> funkcyjnie. Pozosta�e j�zyki skre�laj� si� w�a�nie przez wymienione
> powody, kt�re w�a�nie s� na plus i promuj� Scal�.

Zdecydowanie nie skre�la�bym j�zyk�w bez OO.

Grzegorz

[Jacek Laskowski]

2012/5/3 Grzegorz Balcerek <gbalc...@gmail.com>:

> Oczywiście nie twierdzę, że testy są zbędne, raczej że jest szansa na
> ograniczenie ich liczby.
> Kompilator sprawdzając pewne właściwości programu powoduje, że testowanie
> tych właściwości jest niepotrzebne.

Moje skromne doświadczenie z testami w jakiejkolwiek formie podpowiada
mi, że w żadnym języku nie testujemy typów, ani ich utrzymania, a
jedynie funkcjonalność oferowaną przez publiczne API.

> To ja poproszę jakiś silnie typowany, ale nie "nachalny" przykład w F#, żeby
> zrozumieć o co chodzi.

Za słabym w F#, aby cokolwiek zaproponować pisane własnoręcznie, ale
posłużę się przykładem z sieci http://www.fssnip.net/3h.

> Zdecydowanie nie skreślałbym języków bez OO.

Jedną z cech języków obiektowych jest dodatkowa warstwa organizacji
kodu - klasa. Choćby z tego powodu nie skreślałbym ich :)

A poważniej, wciąż zarabiam Javą, więc niech OO się trzyma, aby mnie utrzymać :)

[Grzegorz Balcerek]

Zdaje si�, �e obiektowo�� z dziedziczeniem i przeci��aniem metod ma
wp�yw na dzia�anie algorytmu wnioskowania typ�w - patrz komentarz
Martina Odersky'ego do wpisu tutaj:
http://www.codecommit.com/blog/scala/universal-type-inference-is-a-bad-thing

Czy w F# sďż˝ klasy i dziedziczenie?

> > To ja poprosz� jaki� silnie typowany, ale nie "nachalny" przyk�ad w F#,
> > �eby
> > zrozumieďż˝ o co chodzi.
>

> Za s�abym w F#, aby cokolwiek zaproponowa� pisane w�asnor�cznie, ale
> pos�u�� si� przyk�adem z sieci http://www.fssnip.net/3h.

>
> > Zdecydowanie nie skre�la�bym j�zyk�w bez OO.
>

> Jedn� z cech j�zyk�w obiektowych jest dodatkowa warstwa organizacji
> kodu - klasa. Cho�by z tego powodu nie skre�la�bym ich :)

Grzegorz

[Piotrek]

> > Ja ( i pewnie nie tylko) chętnie bym zobaczył jak się sprawuje scala w
> > aplikacjach enterprise. (...)
>
> Patrz wyżej.
> Oczywiście podyskutować o różnych sprawach możemy, nawet jeśli ja nie znam się na wszystkim.
> Czy nie macie czasem przesadnych obaw przed zastosowaniem Scali w projektach? :)

a bo to zalezy kogo pytasz. jesli zwracasz sie do tych, ktorzy patrza
na scale z ciekwosci/dla rozrywki intelektualnej, to nie. oni nie maja
zadnych obaw. jesli jednak pytasz tych, ktorzy dzieki javie maja co
jesc to oni juz sie bardzo boja :) Mysla o scali bo zastanawiaja sie
czy uda im lepiej/szybciej/czytelniej rozwiazac ich codzienne problemy
i czy dzieki temu beda mogli wyjsc godzine wczesniej do domu. ale oni
nie tkna scali nawet metrowym kijem jesli ona nie zadziala z ich
ulubionym ide, frameworkiem do testow, narzedziem do budowania i
oprogramowaniem QA

> Przecież nawet w języku Java ludzie piszą i jakoś im się udaje lepiej
> lub gorzej! :)

jakos sie udaje bo przez lata java dorobila sie olbrzymiego zaplecza
wspomagaczy. IDE, QA, frameworki, debuggery, clean code best practices
itp. dzieki temu piszac w javie stajemy na barkach gigantow. a tam na
gorze jest na tyle wygodnie, ze nie chcemy schodzic dla samego uzycia
innego jezyka. nawet jesli niektore petle da sie zapisac krocej.
swietnym przykladem jest powyzsza implementacja liczb fibonacciego.
pewnie duza krotsza niz wiekszosc implementacji obiektowych/
proceduralnych. ale ile czasu zajelo wam zrozumienie tego kodu? jego
zlozonosci, dzialania dla liczb w okolicy +-0, analizy poprawnosci
itp. a ile razy czesciej czytamy kod niz go piszemy? :)

> > (...) Dość ważnym aspektem jest pokrycie testami
> > kodu w scali (nie znam scali i narazie ciężko mi sobie wyobrazić czy
> > się da ;p )  (...)
>
> O co chodzi? Czy co się da? Czy da się kod testować?

chodzi wlasnie o to czy mozna wpiac scale w typowy cykl wytwarzania
komercyjnego oprogramowania. czy mozna latwo zmierzyc jakosc
oprogramowania stworzonego w scali (m.in. poprzez zmierzenie
pokrycia)?

to chyba wlasnie dlatego takie zainteresowanie integracja z
pozostalymi narzedziami developerskimi. wydaje mi sie, ze dopoki scala
nie zmierzy sie z tym tematem, pozostanie przy bardzo niszowych
zastosowaniach

[Grzegorz Balcerek]

> From: "Piotrek" <piotr....@gmail.com>

Dzi�kuj� za te uwagi.

Zach�cam do zej�cia na chwil� z tej "g�ry" narz�dzi i spojrzenia na
ni� z boku :) Cho�by dla nabrania innej perspektywy, nawet je�li si�
nie zdecydujecie na komercyjne zastosowanie Scali. Kompilator j�zyka
Scala jest zreszt� te� jednym z narz�dzi (do generacji kodu
bajtowego).

Zapraszam na warsztaty, gdzie mo�e uda si� rozja�ni� pewne kwestie.
Natomiast mogďż˝ nie byďż˝ odpowiedniďż˝ osobďż˝ do odpowiedzi na wszystkie
pytania. Pozwol� sobie wobec tego zwr�ci� uwag� na nast�puj�c�
prezentacjďż˝: http://scala.net.pl/martin-odersky-whats-next-for-scala/
Tych z was, kt�rych ciekawi� zagadnienia wtyczki do Eclipse, mo�e
zaciekawi� fragment od ok 15. do 28. minuty. Tych, kt�rzy chc� mie�
jakie� poj�cie o tym jak post�puje komercyjna adopcja j�zyka mo�e
zaciekawiďż˝ pierwsze kilka minut.

Pozdrawiam,
Grzegorz

[Olaf Matyja]

> > Ja ( i pewnie nie tylko) ch�tnie bym zobaczy� jak si� sprawuje scala w
> > aplikacjach enterprise. (...)
>
> Patrz wy�ej.
> Oczywi�cie podyskutowa� o r�nych sprawach mo�emy, nawet je�li ja nie znam
siďż˝ na wszystkim.

> Czy nie macie czasem przesadnych obaw przed zastosowaniem Scali w
projektach? :)

A owszem, mam, ale w og�le nie z powodu w�a�ciwo�ci samego j�zyka.
Merytorycznie to Scala ca�kiem mi si� podoba, nawet co� tam sobie w niej
d�uba�em.
Ale tu nie tylko o to chodzi, czy sama Scala jest efektywniejsza od Javy.
U�ycie nietypowych j�zyk�w ma spore konsekwencje dla firmy:


Klient chce dosta� kod �r�d�owy, i konserwowa� go ta�szymi si�ami...
Buhaha, ok, piszemy w Scali.
(...)
Klient uzale�ni� si� od nas z tym systemem. Super.
Tylko dlaczego kolejne zamawia u konkurencji?


Napisa�em wszystko w Scali. Ekstra j�zyk.
(...)
Szef mi nie chce daďż˝ urlopu, bo tylko ja jestem w stanie wprowadziďż˝ do kodu
te poprawki.
Wrrr. Hmm, chyba czas prosi� o podwy�k�.


Scala jest super! Piszemy w Scali!
(...)
Napisali�my wszystko w Scali, a teraz Maciek chce odej��.
Cholera, sk�d ja wezm� do�wiadczonego programist� Scali?
Maciek, nie odchod�, dam ci podwy�k�...



Pozdr.
Olaf

[Jacek Laskowski]

2012/5/8 Olaf Matyja <ola...@gmail.com>:

> Napisałem wszystko w Scali. Ekstra język.
> (...)
> Szef mi nie chce dać urlopu, bo tylko ja jestem w stanie wprowadzić do kodu
> te poprawki.
> Wrrr. Hmm, chyba czas prosić o podwyżkę.

>
> Scala jest super! Piszemy w Scali!
> (...)

> Napisaliśmy wszystko w Scali, a teraz Maciek chce odejść.
> Cholera, skąd ja wezmę doświadczonego programistę Scali?
> Maciek, nie odchodź, dam ci podwyżkę...

Te argumenty nie stanowią o wyższości/niższości języka nad innymi
rozwiązaniami, które obecnie przynoszą krocie (na chwilę załóżmy, że
tak jest). Powiem więcej, praca w takiej firmie, w której wprowadzenie
nowego nie idzie w parze z pewną kulturą troski o "obsługę" tych
kwestii, uważam za czas stracony, bo wyrabia się w nas bardzo
zachowawcze podejście do zmian, a w konsekwencji stagnacji. Zaryzykuję
nawet stwierdzenie, że w takich zespołach, wprowadzenie nowego
podejścia w obowiązującym języku może spotykać się z podobnymi
wątpliwościami. I co wtedy? Czy po 2 latach stosowania języka, nowe
traktowane jest jako argument przetargowy w dyskusji o podwyżce czy
zwolnieniu. Nie mieszajmy tego - oddzielmy poziom technologiczny od
socjalnego.

Nikt nie nalega, aby przewalić warsztat pracy do góry nogami, a
jedynie rozważyć zastosowanie pewnych cech nowego języka, w których
może owe już wpływające krocie potroić. Uważam również, że zabawa z
nowym pozwala na dotknięcie nowych obszarów (np. obsługa nowych
problemów biznesowych), których w obecnej technologii byłoby
karkołomne.

Zresztą, czy nauka nowego musi wiązać się w natychmiastowym wdrożeniem
w projekt? A niechby tylko odświeżyło umysł? Czy to nie ma już
wymiernego wpływu na niego? Czy osoba emanująca zapałem poznawania
nowego i kwestionująca wszystko i wszystkich nie jest wartościowa w
zespole? Mam wrażenie, że próbowanie się z nowym mamy we krwi w naszej
branży.

Dodatkowo, wyobraźmy sobie, co byłoby, gdybyśmy wciąż programowali w
Cobolu, albo Fortranie, albo C. Byłoby fajnie, ale czy z Javą nie jest
fajniej, albo po prostu inaczej? Chcą nas zaszufladkować i zmierzyć,
ale nie dajmy się!

[Jacek Laskowski]

2012/5/3 Grzegorz Balcerek <gbalc...@gmail.com>:
> Zdaje się, że obiektowość z dziedziczeniem i przeciążaniem metod ma
> wpływ na działanie algorytmu wnioskowania typów - patrz komentarz

> Martina Odersky'ego do wpisu tutaj:
> http://www.codecommit.com/blog/scala/universal-type-inference-is-a-bad-thing
>

> Czy w F# są klasy i dziedziczenie?

Klasy i dziedziczenie to cechy języków obiektowych, a F# jest
funkcyjny, więc tego typu konstrukcje nie są dostępne (na tyle, na ile
jest mi to wiadome).

[mproch Gazeta.pl]

1. http://www.infoq.com/articles/guardian_scala - tu jest całkiem fajna prezentacja jak w guardianie stopniowo przechodzili na scalę - zaczynając właśnie od pisania testów w scali żeby się jej nauczyć i nie zepsuć kodu produkcyjnego ;)

2. IMHO to scala świetnie się nadaje do sytuacji kiedy chcemy wprowadzić nowy język ale nie chcemy wywracać wszystkiego do góry nogami. 

Ponieważ scala nie jest taka całkiem funkcyjna to kiedy nie bardzo wiemy jak coś zrobić 'tak jak być powinno' a terminy gonią ;) - to możemy napisać ten kawałek prawie jak w javie (no i oczywiście potem zrefaktorować jak już będziemy mądrzy... )

U nas mamy springa, mavena i czujemy się w miarę bezpiecznie ;)

3. Co do zastrzeżeń Olafa to wydaje mi się, że wszystko to można odnieść także do różnych frameworków javowych.

Jak z np. spring-mvc+jsp przejdziemy na play(1) albo wicket to zamęt może być chyba jeszcze gorszy...

W obecnym projekcie chcieliśmy wykorzystać trochę nowych i modnych rzeczy: cqrs/es,nosql i scalę i wg mnie to z tego wszystkiego przejście na scalę jest najmniej bolesne. Tak jak pisałem wyżej to nie jest taka całkiem 'idiomatyczna' scala, no ale przecież słonia je się po kawałku...

4. IDE,debug,testy - ja mogę mówić tylko o intellij. I uważam że jeśli chodzi o testy (np. pokrycie) i debug to jest całkiem dobrze - tzn. nie mam jakiś strasznych zastrzeżeń. Natomiast kompilacja bez FSC (kompilator działający w tle) jest IMO koszmarnie wolna (ale coraz szybsza ;)). Także podpowiedzi i np. refaktoring w Idei pozostawiają sporo do życzenia - ale cały czas się poprawiają

pzdr,

maciek

[Wojciech Erbetowski]

Olaf, tu właśnie o to chodzi, że większość z nas (mam nadzieję) nie jest ludźmi, którzy chcą skończyć wcześniej i wyjść godzinę wcześniej do domu.

Niewielu znam programistów, którzy złapali się tego fachu z rozsądku, a nie pasji.

My właśnie zostaniemy kilka godzin dłużej, żeby coś poznać, czegoś się nauczyć i się tym później podzielić. Nie chodzi nam tylko o podwyżki.

Jeśli weźmiemy takiego gościa o którym piszesz, to jesteśmy w stanie na jego przykładzie obalić potrzebę jakichkolwiek zmian, które nie dają rezultatu natychmiast. 

I dlatego właśnie jest wiele korporacji, które świetnie płacą w zamian, za babranie się w ich ...

Pozdrawiam,

Wojtek

[Olaf Matyja]

Jasne, zgadzam się, że wprowadzanie nowych rzeczy jest zarówno fajne jak i niezbędne, żeby nie doprowadzić do stagnacji.
Macie też racje że to samo dotyczy frameworków, świat javy jest bardzo podzielony, co jest jego pięknem i przekleństwem zarazem.

Też lubię się jako programista bawić nowymi zabawkami, z pewnością jest to ciekawsze niż ciągłe klepanie tego samego. Inaczej bym się zresztą nie zapisywał do JUGu.

Natomiast moi przełożeni woleliby, żeby praca była może mniej ciekawa a bardziej przewidywalna i trochę ich rozumiem, zwłaszcza że jeden z opisanych przeze mnie przypadków autentycznie miał miejsce. I muszę to brać pod uwagę. Czy to powód do zmiany firmy jak sugerował Jacek? Może...

Ponieważ dyskusja zeszła na użycie Scali w projektach enterprise i nie wynikało z niej w ogóle, dlaczego ktoś miałby mieć jakikolwiek wątpliwości, postanowiłem podać też argumenty z drugiej strony.

Wydaje mi się że każda nowość jest z punktu widzenia managementu zarówno pociągająca jak i ryzykowna, nie należy ani zamykać się ani wdrażać wszystkiego jak leci tylko rozważać za i przeciw.

Z punktu widzenia programistów ryzyka nie ma, nam to się nie może nie opłacić, będziemy mieli wyższe kompetencje i ciekawszą pracę. Ale rozumieć należy wszystkie aspekty a nie tylko pozytywne.

Pozdrawiam,
Olaf

On 8 May 2012 11:54, "Wojciech Erbetowski" <wojc...@erbetowski.pl> wrote:

Olaf, tu właśnie o to chodzi, że większość z nas (mam nadzieję) nie jest ludźmi, którzy chcą skończyć wcześniej i wyjść godzinę wcześniej do domu.

Niewielu znam programistów, którzy złapali się tego fachu z rozsądku, a nie pasji.

My właśnie zostaniemy kilka godzin dłużej, żeby coś poznać, czegoś się nauczyć i się tym później podzielić. Nie chodzi nam tylko o podwyżki.

Jeśli weźmiemy takiego gościa o którym piszesz, to jesteśmy w stanie na jego przykładzie obalić potrzebę jakichkolwiek zmian, które nie dają rezultatu natychmiast. 

I dlatego właśnie jest wiele korporacji, które świetnie płacą w zamian, za babranie się w ich ...

Pozdrawiam,

Wojtek

W dniu 8 maja 2012 11:42 użytkownik mproch Gazeta.pl <mpr...@gazeta.pl> napisał:

>
> 1. http://www.infoq.com/articles/guardian_scala - tu jest całkiem fajna prezentacja jak w guard...

--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).

Więcej informacji na stronie http://g...

[Olaf Matyja]

Chyba jednak w f# jest dziedziczenie.

http://en.wikibooks.org/wiki/F_Sharp_Programming/Inheritance

Prawiam,
Olaf

On 8 May 2012 10:04, "Jacek Laskowski" <ja...@japila.pl> wrote:

2012/5/3 Grzegorz Balcerek <gbalc...@gmail.com>:

> Zdaje się, że obiektowość z dziedziczeniem i przeciążaniem metod ma

> wpływ na działanie algorytmu...

Klasy i dziedziczenie to cechy języków obiektowych, a F# jest
funkcyjny, więc tego typu konstrukcje nie są dostępne (na tyle, na ile
jest mi to wiadome).

Jacek

--
Jacek Laskowski
Functional languages (Clojure), Java EE, and IBM WebSphere -

http://blog...

[Piotrek]

W dniu czwartek, 3 maja 2012 15:53:33 UTC+2 użytkownik Jacek Laskowski napisał:

Moje skromne doświadczenie z testami w jakiejkolwiek formie podpowiada
mi, że w żadnym języku nie testujemy typów, ani ich utrzymania, a
jedynie funkcjonalność oferowaną przez publiczne API.

jestem sklonny sie zgodzic, ze typow jako takich sie nie testuje. czesto tez wygodniej sie pisze bez koniecznosci jawnego deklarowania typow ale potem czasami trzeba za to zaplacic. dwa przyklady.
1. wczoraj, slabo typowany (jak na jave), fest assert powiedzial mi:
"java.lang.AssertionError: <[2, 4, 5, 7, 8]> does not contain element(s):<[2, 4, 5, 7, 8]>"
po sprawdzeniu czy uzylem wlasciwej asercji, kilkukrotnym przeliczeniu palcem po ekranie, przypomnieniu sobie kiedy i ile ostatnio pilem, w koncu mnie oswiecilo: int vs long
z ciekawosci postanowilem napisac ten sam test przy uzyciu silne typowanego hamcresta. nie udalo sie - kompilator nie pozwolil na taka pomylke
2. pamietam jeszcze moje poczatki z javascript na studiach. to naprawde boli kiedy debugujesz i nie wiesz jaki typ jest na zmiennej

konkludujac: faktycznie, typow sie raczej nie testuje. wygodniej tez pisze sie kod bez typow. ale znacznie latwiej utrzymuje sie kod silnie typowany. przyznaje natomiast, ze czasem kod bez typow jest bardziej zwiezly i dlatego latwiej sie go czyta. i to sprawia, ze warto go stosowac do rzeczy prostych a czesto powtarzalnych, np ognl. ale, tworzenie i utrzymywanie w tym duzych i zlozonych systemow jest po prostu trudne

[Piotrek]

fajny, rzeczowy post. dwa pytania:
1. dlaczego przerzuciliscie sie na scale? dla zrobienia czegos nowego czy pewne rzeczy pisalo sie lepiej w jezyku funkcyjnym? jakie?
2. moze chcialbys poopowiadac o waszych doswiadczeniach na ktoryms jugu? :) ja chetnie poslucham

[mproch Gazeta.pl]

W dniu 8 maja 2012 13:50 użytkownik Piotrek <Piotr....@gmail.com> napisał:

fajny, rzeczowy post. dwa pytania:
1. dlaczego przerzuciliscie sie na scale? dla zrobienia czegos nowego czy pewne rzeczy pisalo sie lepiej w jezyku funkcyjnym? jakie?

hmmm... na pewno chęć zrobienia czegoś nowego była istotna. Ja już od dość dawna chciałem przypomnieć sobie swoje studia na których więcej chyba pisałem funkcyjnie niż obiektowo ;) 

ostatnio sporo pisaliśmy w groovym - i pod pewnymi względami (dużo lukru syntaktycznego + funkcje/domknięcia itd) są pewne podobieństwa. Natomiast ja tam jakoś wolę - zwłaszcza przy większej ilości kodu w be - jak mam statyczne typowanie. Co innego bliżej frontendu - o tym na 33rd degree w którymś momencie ładnie Venkat powiedział. 

 

poza tym jednak w moim odczuciu groovy jest wolniejszy i gorzej się go debuguje

2. moze chcialbys poopowiadac o waszych doswiadczeniach na ktoryms jugu? :) ja chetnie poslucham

mam nadzieję o tym opowiedzieć - gdzie i kiedy to się okaże ;)

maciek 

W dniu wtorek, 8 maja 2012 11:42:32 UTC+2 użytkownik mproch napisał:

1. http://www.infoq.com/articles/guardian_scala - tu jest całkiem fajna prezentacja jak w guardianie stopniowo przechodzili na scalę - zaczynając właśnie od pisania testów w scali żeby się jej nauczyć i nie zepsuć kodu produkcyjnego ;)

2. IMHO to scala świetnie się nadaje do sytuacji kiedy chcemy wprowadzić nowy język ale nie chcemy wywracać wszystkiego do góry nogami. 

Ponieważ scala nie jest taka całkiem funkcyjna to kiedy nie bardzo wiemy jak coś zrobić 'tak jak być powinno' a terminy gonią ;) - to możemy napisać ten kawałek prawie jak w javie (no i oczywiście potem zrefaktorować jak już będziemy mądrzy... )

U nas mamy springa, mavena i czujemy się w miarę bezpiecznie ;)

3. Co do zastrzeżeń Olafa to wydaje mi się, że wszystko to można odnieść także do różnych frameworków javowych.

Jak z np. spring-mvc+jsp przejdziemy na play(1) albo wicket to zamęt może być chyba jeszcze gorszy...

W obecnym projekcie chcieliśmy wykorzystać trochę nowych i modnych rzeczy: cqrs/es,nosql i scalę i wg mnie to z tego wszystkiego przejście na scalę jest najmniej bolesne. Tak jak pisałem wyżej to nie jest taka całkiem 'idiomatyczna' scala, no ale przecież słonia je się po kawałku...

4. IDE,debug,testy - ja mogę mówić tylko o intellij. I uważam że jeśli chodzi o testy (np. pokrycie) i debug to jest całkiem dobrze - tzn. nie mam jakiś strasznych zastrzeżeń. Natomiast kompilacja bez FSC (kompilator działający w tle) jest IMO koszmarnie wolna (ale coraz szybsza ;)). Także podpowiedzi i np. refaktoring w Idei pozostawiają sporo do życzenia - ale cały czas się poprawiają

[mproch Gazeta.pl]

Jacku,

http://stackoverflow.com/questions/2905081/scala-versus-f-question-how-do-they-unify-oo-and-fp-paradigms

- tu jest IMHO dość ciekawa dyskusja o F# (o którym nie mam niestety zbyt wielkiego pojęcia...) vs Scala
z uwzględnieniem cech obiektowości i inferencji typów w obu językach.

maciek

[Jacek Laskowski]

2012/5/8 Piotrek <Piotr....@gmail.com>:

> konkludujac: faktycznie, typow sie raczej nie testuje. wygodniej tez pisze
> sie kod bez typow. ale znacznie latwiej utrzymuje sie kod silnie typowany.
> przyznaje natomiast, ze czasem kod bez typow jest bardziej zwiezly i dlatego
> latwiej sie go czyta. i to sprawia, ze warto go stosowac do rzeczy prostych
> a czesto powtarzalnych, np ognl. ale, tworzenie i utrzymywanie w tym duzych
> i zlozonych systemow jest po prostu trudne

Eee tam, gadanie. Niestety nie poprę tego żadnym przykładem, ale co
powiesz na taki odpowiednik, który nasunął mi się po przeczytaniu
Twojej wypowiedzi:

"Czy uważasz, że uczyłbyś się gorzej, gdybyś zamiast klasy i belfra
miał łączkę, słoneczko i miłą panią nauczycielkę?"

Wolisz dostawać po łapach i myśleć, czy myśleć i nie dostawać po
łapach? :) Trochę przesadzam, ale coś mi mówi, że za bardzo
przyzwyczailiśmy się do naszego ulubionego kompilatora, który całkiem
nieprzypadkiem zwolnił nas od myślenia. Przypominam, że doświadczenia
projektowego w zespole to u mnie jak na lekarstwo. Może to i dobrze,
bo pozwala na myślenie bardziej wyidealizowane?!

A wracając do przykładu z testem - błąd nie pojawiłby się, gdyby
właśnie nie sprawdzanie typów. Potrzebne Ci to było w teście?!

[Jacek Laskowski]

2012/5/8 mproch Gazeta.pl <mpr...@gazeta.pl>:

> http://stackoverflow.com/questions/2905081/scala-versus-f-question-how-do-they-unify-oo-and-fp-paradigms
> - tu jest IMHO dość ciekawa dyskusja o F# (o którym nie mam niestety zbyt
> wielkiego pojęcia...) vs Scala
> z uwzględnieniem cech obiektowości i inferencji typów w obu językach.

Dzięki, ale to jeszcze nie ten poziom dla mnie. Gdyby chociaż
wzmiankowano Clojure, ale Scala i F# są zbyt nowe dla mnie, abym
połapał się w temacie, a dodatkowo inferencja typów dotarła do mojej
przysadki całkiem niedawno :)

[Jacek Laskowski]

2012/5/8 Olaf Matyja <ola...@gmail.com>:

> Chyba jednak w f# jest dziedziczenie.
>
> http://en.wikibooks.org/wiki/F_Sharp_Programming/Inheritance

Ech, racja! Coś mi mówiło, uważaj nie pchaj się tutaj :)

Jacek

--
Jacek Laskowski
Functional languages (Clojure), Java EE, and IBM WebSphere -

[Grzegorz Balcerek]

Kontynuuj�c dyskusj� na temat systemu typ�w (tak og�lnie, nie
konkretnie w j. Scala), zwracam uwag� na znakomity przyk�ad, kt�ry
niniejszym wykorzystam w tej dyskusji. Przyk�ad jest na blogu Jacka
(nie trzeba klika�; poni�ej podsumowuj� to co z niego tutaj dla mnie wa�ne):
http://jlaskowski.blogspot.com/2012/05/asynchroniczne-przetwarzanie-w-servlet.html

Podsumowuj�c: jest tam wiersz kodu:
AsyncContext asyncCtx = request.getAsyncContext();

Wykonanie tego wiersza skutkuje wyj�tkiem IllegalStateException. Czyli
mamy tu do czynienia z sytuacj�, w kt�rej na obiekcie jest dost�pna
metoda, ale wywo�anie tej metody nie zawsze jest "legalne". W
zale�no�ci od stanu obiektu, wywo�anie metody mo�e skutkowa�
wyj�tkiem IllegalStateException. Ale mo�e te� nie skutkowa� takim
wyj�tkiem w innej sytuacji (jak obiekt b�dzie w innym stanie). Czy
dobrze zrozumia�em?

Teraz do rzeczy, czyli na temat typ�w. Czy nie lepiej by by�o gdyby w
u�ytym API by� wykorzystany system typ�w i pr�ba wywo�ania metody w
"nielegalnym" kontek�cie skutkowa�a b��dem kompilacji? (albo do takiej
pr�by, by w og�le nie dosz�o, bo IDE nie znalaz�by "nielegalnej"
metody w klasie i w og�le nie dosz�oby do pr�by kompilacji nawet)
Oczywi�cie sam system typ�w nie wystarczy, trzeba go jeszcze
wykorzystaďż˝, czyli w tym przypadku inaczej zaprojektowaďż˝ API. Tak na
marginesie, nie chodzi mi tutaj o akurat krytykowanie API serwlet�w
3.0, bo go nie znam i nie wiem dlaczego tak zosta�o
zaprojektowane. Bardziej chodzi mi o og�lne rozwa�ania o projektowaniu
API z wykorzystaniem systemu typ�w.

Oczywi�cie wg. mnie odpowied� jest twierdz�ca: lepiej jest jak taki
b��d wy�apie kompilator ni� jak si� on ujawni w testach (lub co gorsza
po testach, "na produkcji").

A co zrobi� w j�zyku bez statycznego systemu typ�w? Nie ma takiej
opcji �eby kompilator co� sprawdzi�, bo w�a�nie z definicji nie
sprawdza.

Pozdrawiam,
Grzegorz
http://www.grzegorzbalcerek.net

[Bartek Kuczyński]

Zwróć uwagę, że kompilator nie zawsze może wyłapać tego typu błędy.
Szczególnie jeżeli są to błędy, które mogą ale nie muszę pojawić się w
trakcie działania programu.

IllegalStateException należy do takich właśnie błędów.


Przykład:


public class MyClass{

private boolean isInValidState = true;

public void brokeMe(){
isInValidState = false;
}

public void callMe(){
if(!isInValidState) throw new IllegalStateException();
}

}

I teraz kompilator ma zgaduj zgadulę czy wywołanie callMe spowoduje
wyjątek czy też nie. Teoretycznie może sprawdzić odwołania i
zweryfikować kolejność wywołania metod. Jednak tylko teoretycznie
ponieważ obie metody są publiczne i mogą zostać wywołane z poza
dostępnego dla kompilatora kodu.

Zresztą analiza statyczna kodu pod względem wykrywania błędów to dość
obszerny temat. Warto zobaczyć np. jak opisują to ludzie z ekipy
findbug[1].

W takim wypadku znacznie lepszym rozwiązaniem niż przerzucanie pracy
na kompilator może okazać się
1. dodatkowa metoda sprawdzająca stan, którą należy wywołać przed
właściwą metodą i ma to zrobić użytkownik
2. weryfikowalny wyjątek



[1] http://findbugs.sourceforge.net/

Pozdrawiam
Bartek "Koziołek" Kuczyński
http://koziolekweb.pl
Lepiej pomyśleć dwa razy i zacząć programować
niż dwa razy programować i potem zacząć myśleć
 \     /
 ~00~
  \_/
   |||

W dniu 8 maja 2012 21:52 użytkownik Grzegorz Balcerek
<gbalc...@gmail.com> napisał:
> Kontynuując dyskusję na temat systemu typów (tak ogólnie, nie
> konkretnie w j. Scala), zwracam uwagę na znakomity przykład, który
> niniejszym wykorzystam w tej dyskusji.  Przykład jest na blogu Jacka
> (nie trzeba klikać; poniżej podsumowuję to co z niego tutaj dla mnie ważne):
> http://jlaskowski.blogspot.com/2012/05/asynchroniczne-przetwarzanie-w-servlet.html
>
> Podsumowując: jest tam wiersz kodu:
> AsyncContext asyncCtx = request.getAsyncContext();
>
> Wykonanie tego wiersza skutkuje wyjątkiem IllegalStateException. Czyli
> mamy tu do czynienia z sytuacją, w której na obiekcie jest dostępna
> metoda, ale wywołanie tej metody nie zawsze jest "legalne". W
> zależności od stanu obiektu, wywołanie metody może skutkować
> wyjątkiem IllegalStateException. Ale może też nie skutkować takim
> wyjątkiem w innej sytuacji (jak obiekt będzie w innym stanie). Czy
> dobrze zrozumiałem?
>
> Teraz do rzeczy, czyli na temat typów. Czy nie lepiej by było gdyby w
> użytym API był wykorzystany system typów i próba wywołania metody w
> "nielegalnym" kontekście skutkowała błędem kompilacji? (albo do takiej
> próby, by w ogóle nie doszło, bo IDE nie znalazłby "nielegalnej"
> metody w klasie i w ogóle nie doszłoby do próby kompilacji nawet)
> Oczywiście sam system typów nie wystarczy, trzeba go jeszcze
> wykorzystać, czyli w tym przypadku inaczej zaprojektować API. Tak na
> marginesie, nie chodzi mi tutaj o akurat krytykowanie API serwletów
> 3.0, bo go nie znam i nie wiem dlaczego tak zostało
> zaprojektowane. Bardziej chodzi mi o ogólne rozważania o projektowaniu
> API z wykorzystaniem systemu typów.
>
> Oczywiście wg. mnie odpowiedź jest twierdząca: lepiej jest jak taki
> błąd wyłapie kompilator niż jak się on ujawni w testach (lub co gorsza

> po testach, "na produkcji").
>

> A co zrobić w języku bez statycznego systemu typów? Nie ma takiej
> opcji żeby kompilator coś sprawdził, bo właśnie z definicji nie

> sprawdza.
>
> Pozdrawiam,
> Grzegorz
> http://www.grzegorzbalcerek.net
>
>

[Grzegorz Balcerek]

No i mamy r�nic� zda�.

> I teraz kompilator ma zgaduj zgadul� czy wywo�anie callMe spowoduje
> wyj�tek czy te� nie. Teoretycznie mo�e sprawdzi� odwo�ania i
> zweryfikowa� kolejno�� wywo�ania metod. Jednak tylko teoretycznie
> poniewa� obie metody s� publiczne i mog� zosta� wywo�ane z poza
> dost�pnego dla kompilatora kodu.

Mo�na r�wnie� przeprojektowa� klas� i unikn�� takich zagadek. Przyk�adowy
szkic:

public class MyClass{
public static class MyClassBroken extends MyClass {
public MyClassRepaired repairMe() { return new MyClassRepaired(); }
}
public static class MyClassRepaired extends MyClass {
public MyClassBroken brokeMe(){ return new MyClassBroken(); }
public void callMe(){ System.out.println("No illegal state here;
always valid."); }
}
}

> W takim wypadku znacznie lepszym rozwi�zaniem ni� przerzucanie pracy
> na kompilator mo�e okaza� si�
> 1. dodatkowa metoda sprawdzaj�ca stan, kt�r� nale�y wywo�a� przed
> w�a�ciw� metod� i ma to zrobi� u�ytkownik
> 2. weryfikowalny wyj�tek

Ja jednak od 1 i 2 wolďż˝ przerzuciďż˝ pracďż˝ na kompilator.

Pozdrawiam,
Grzegorz
http://www.grzegorzbalcerek.net

[Bartek Kuczyński]

Zgoda można przeprojektować klasę, ale nadal pozostaje pytanie kto ma
decydować o tym której wersji klasy użyć.

To jest właśnie drobny problem. Kompilator raczej nie powinien takich
rzeczy robić ponieważ nie posiada wiedzy o wszystkich kontekstach w
jakich używana jest dana klasa/metoda i może nas wprowadzić na niezłą
minę.

Pozdrawiam
Bartek "Koziołek" Kuczyński
http://koziolekweb.pl
Lepiej pomyśleć dwa razy i zacząć programować
niż dwa razy programować i potem zacząć myśleć
 \     /
 ~00~
  \_/
   |||


W dniu 8 maja 2012 22:33 użytkownik Grzegorz Balcerek
<gbalc...@gmail.com> napisał:

> No i mamy różnicę zdań.

>
>
>> I teraz kompilator ma zgaduj zgadulę czy wywołanie callMe spowoduje
>> wyjątek czy też nie. Teoretycznie może sprawdzić odwołania i
>> zweryfikować kolejność wywołania metod. Jednak tylko teoretycznie
>> ponieważ obie metody są publiczne i mogą zostać wywołane z poza
>> dostępnego dla kompilatora kodu.
>
>

> Można również przeprojektować klasę i uniknąć takich zagadek. Przykładowy

> szkic:
>
> public class MyClass{
>  public static class MyClassBroken extends MyClass {
>      public MyClassRepaired repairMe() { return new MyClassRepaired(); }
>  }
>  public static class MyClassRepaired extends MyClass {
>      public MyClassBroken brokeMe(){ return new MyClassBroken(); }
>      public void callMe(){ System.out.println("No illegal state here; always
> valid."); }
>
>  }
> }
>

>> W takim wypadku znacznie lepszym rozwiązaniem niż przerzucanie pracy
>> na kompilator może okazać się
>> 1. dodatkowa metoda sprawdzająca stan, którą należy wywołać przed
>> właściwą metodą i ma to zrobić użytkownik
>> 2. weryfikowalny wyjątek
>
>

> Ja jednak od 1 i 2 wolę przerzucić pracę na kompilator.
>
>
> Pozdrawiam,
> Grzegorz
> http://www.grzegorzbalcerek.net
>

[Grzegorz Balcerek]

> Zgoda mo�na przeprojektowa� klas�, ale nadal pozostaje pytanie kto ma
> decydowa� o tym kt�rej wersji klasy u�y�.

Decydowa� ma pewnie projektant API i potem u�ytkownik API, kompilator
mo�e natomiast pom�c wyeliminowa� b��dne �cie�ki wywo�a�, jakie�
niesp�jno�ci.

Jeszcze wracaj�c do poprzedniego maila:

> W takim wypadku znacznie lepszym rozwi�zaniem ni� przerzucanie pracy
> na kompilator mo�e okaza� si�
> 1. dodatkowa metoda sprawdzaj�ca stan, kt�r� nale�y wywo�a� przed
> w�a�ciw� metod� i ma to zrobi� u�ytkownik
> 2. weryfikowalny wyj�tek

Ja bym raczej 1 i 2 umieszcza� pod has�em "jak nie nale�y projektowa� API".
Co s�dzicie?

Pozdrawiam,
Grzegorz
http://www.grzegorzbalcerek.net

[Jacek Laskowski]

2012/5/8 Grzegorz Balcerek <gbalc...@gmail.com>:

> Czy dobrze zrozumiałem?

Tak. Doskonale.

> Teraz do rzeczy, czyli na temat typów. Czy nie lepiej by było gdyby w
> użytym API był wykorzystany system typów i próba wywołania metody w
> "nielegalnym" kontekście skutkowała błędem kompilacji? (albo do takiej
> próby, by w ogóle nie doszło, bo IDE nie znalazłby "nielegalnej"
> metody w klasie i w ogóle nie doszłoby do próby kompilacji nawet)

> Oczywiście sam system typów nie wystarczy, trzeba go jeszcze
> wykorzystać, czyli w tym przypadku inaczej zaprojektować API.

Podoba mi się pomysł. Zapewne rozmawiamy o tych kryteriach, które daje
się użyć w trakcie kompilacji (czyli podobnie jak makra w Clojure) i
ciekawym Twojej propozycji rozwiązania w Scali, które umożliwiłoby to.
Rozpaliłeś moją żądzę wiedzy do czerwoności!

p.s. Nie sądziłem, że wpis "na kolanie" spotka się z takim
zainteresowaniem - najpierw Tomek z komentarzami, a teraz Grzesiek.
Cudo!

[Grzegorz Balcerek]

> ciekawym Twojej propozycji rozwi�zania w Scali, kt�re umo�liwi�oby to.
> Rozpali�e� moj� ��dz� wiedzy do czerwono�ci!

A przyk�ad z klas� MyClass w kolejnych mailach nie wyja�nia o co chodzi?

Grzegorz
http://www.grzegorzbalcerek.net

[Adam Lider]

On May 8, 2012, at 10:55 PM, Grzegorz Balcerek wrote:

>> Zgoda można przeprojektować klasę, ale nadal pozostaje pytanie kto ma
>> decydować o tym której wersji klasy użyć.
>

> Decydować ma pewnie projektant API i potem użytkownik API, kompilator
> może natomiast pomóc wyeliminować błędne ścieżki wywołań, jakieś niespójności.
>
> Jeszcze wracając do poprzedniego maila:

>
>> W takim wypadku znacznie lepszym rozwiązaniem niż przerzucanie pracy
>> na kompilator może okazać się
>> 1. dodatkowa metoda sprawdzająca stan, którą należy wywołać przed
>> właściwą metodą i ma to zrobić użytkownik
>> 2. weryfikowalny wyjątek
>

> Ja bym raczej 1 i 2 umieszczał pod hasłem "jak nie należy projektować API". Co sądzicie?

Czasem lepiej czuc niebezpieczenstwo niz slepo zakladac ze wszystko jest ok. Pierwsza wersja, sugerujac mozliwosc wystapienia IllegalStateException daje nam ostrzezenie, ze w cos w pewnej sytuacji moze nie zagrac. Druga natomiast, mocno twierdzi ze jesli wywolalismy metode repairMe to jestesmy w pelni bezpieczni wywolujac callMe. Czy na pewno i zawsze?
Oba rozwiazania dotycza modyfikacji pewnego stanu (chociaz to drugie nie ma tego zaimplementowanego). Tym stanem moze byc zwykla zmienna, ale nie musi. Moze to byc rowniez cos co dotyka IO lub opiera sie na jakims innym zasobie systemowym. Wtedy nasz stan moze sie zmienic pomiedzy wywolaniem repairMe i callMe niezaleznie od nas i w drugim przypadku zostaniemy bardzo zaskoczeni zupelnie nieprzewidziana sytuacja.
Sytuacja staja sie bardziej skomplikowana jesli nasz obiekt moze byc uzyty przez kilka watkow. Pierwsza wersja po dodaniu synchronizacji moze byc tak uzyta. Druga natomiast nie bardzo, chyba ze uzyjemy lokalnych kopii stanu, ale to nie zawsze jest to czego chcemy.
Z reszta, od wyjatkow w API nie uciekniemy, bo co powinna zwrocic nasza metody repairMe jesli naprawa nie jest mozliwa?

Adam.

[Bartek Kuczyński]

> Decydować ma pewnie projektant API i potem użytkownik API, kompilator
> może natomiast pomóc wyeliminować błędne ścieżki wywołań, jakieś niespójności.
>

Słowo klucz pomóc. Zwrócić uwagę, czy podpowiedzieć, ze coś może być
nie tak. Jednak mówienie wprost "to se ne da" jest nie dobre.
Kompilator nie może zacząć myśleć za programistę. To co Adam pisze
jest słuszne czasami warto poczuć trochę niebezpieczeństwa niż ślepo
ufać w to że inni przygotowali coś co nas zabezpieczy.

Silna kontrola typów TAK
Zbyt cwane kompilatory NIE.

Pozdrawiam
Bartek "Koziołek" Kuczyński
http://koziolekweb.pl
Lepiej pomyśleć dwa razy i zacząć programować
niż dwa razy programować i potem zacząć myśleć
 \     /
 ~00~
  \_/
   |||

W dniu 8 maja 2012 23:21 użytkownik Grzegorz Balcerek
<gbalc...@gmail.com> napisał:
>

>> ciekawym Twojej propozycji rozwiązania w Scali, które umożliwiłoby to.
>> Rozpaliłeś moją żądzę wiedzy do czerwoności!
>
>

> A przykład z klasą MyClass w kolejnych mailach nie wyjaśnia o co chodzi?
>
> Grzegorz
> http://www.grzegorzbalcerek.net
>
>

[Bartek Zdanowski]

To ja tylko zadam pytania, może trochę niepopularne w kontekście
przebiegu dyskusji,
- czy spotkanie jest w sobotę, 12.05
- czy znamy godziny
- czy jest zarezerwowana sala


2012/5/9 Bartek Kuczyński <bjkuc...@gmail.com>:

--
Pozdrawiam,
Bartek Zdanowski

Bloguję http://blog.bartekzdanowski.pl i twittuję
http://twitter.com/bartekzdanowski
Confitura 2012 - największa bezpłatna konferencja programistyczna -
http://confitura.pl
KO Warsjawa 2012 - warszawskie jesienne warsztaty javowe - http://warsjawa.pl

[Jacek Laskowski]

2012/5/8 Grzegorz Balcerek <gbalc...@gmail.com>:

> A przykład z klasą MyClass w kolejnych mailach nie wyjaśnia o co chodzi?

Nie bardzo wiem, jak z tego korzystać, tzn. wiem, jak dostać się do
statycznych klas, ale przykład, który mi wyszedł wcale nie zachęca do
skorzystania z niego. Brakuje mi kropki nad i, gdzie zobaczę, dlaczego
(oporny) programista poczułby się przekonany do zalet takiego
podejścia.

[Jacek Laskowski]

2012/5/9 Bartek Zdanowski <bartek.z...@gmail.com>:

> - czy spotkanie jest w sobotę, 12.05
> - czy znamy godziny
> - czy jest zarezerwowana sala

3 x TAK

Należałoby jeszcze przekonać Grzegorza o podsumowaniu całości w
postaci jakiegoś "folderu reklamowego". Pracuję nad tym.

[Adam Lider]

class ServletRequest {
...
AsyncServletRequest startAsync(...) {...}

static class AsyncServletRequest extends ServletRequest {
AsyncContext getAsyncContext() {...}
}
...
}

ServletRequest.AsyncServletRequest asyncRequest = request.startAsync();
...
asyncRequest.getAsyncContext();

gdzie AsyncServletRequest jest wrapperem lub kopia danego obiektu klasy ServletRequest.

Cos w tym stylu?

[Bartek Zdanowski]

2012/5/9 Jacek Laskowski <ja...@japila.pl>:

> 2012/5/9 Bartek Zdanowski <bartek.z...@gmail.com>:
>
>> - czy spotkanie jest w sobotę, 12.05
>> - czy znamy godziny
>> - czy jest zarezerwowana sala
>
> 3 x TAK

W jakich godzinach?

>
> Należałoby jeszcze przekonać Grzegorza o podsumowaniu całości w
> postaci jakiegoś "folderu reklamowego". Pracuję nad tym.
>
> Jacek
>
> --
> Jacek Laskowski
> Functional languages (Clojure), Java EE, and IBM WebSphere -
> http://blog.japila.pl
> "Never discourage anyone who continually makes progress, no matter how
> slow." Plato
>

[Jacek Laskowski]

2012/5/9 Bartek Zdanowski <bartek.z...@gmail.com>:

> W jakich godzinach?

http://warszawa.jug.pl :P

[Adam Lider]

tylko (tak na marginesie) na ile AsyncServletRequest extends ServletRequest jest poprawne? czy obiekt ASR moze byc uzyty kontekscie oczekujacym SR bez wplywu na ten kontekst (liskov substitution)?

[Grzegorz Balcerek]

> > A przyk�ad z klas� MyClass w kolejnych mailach nie wyja�nia o co chodzi?
>
> Nie bardzo wiem, jak z tego korzystaďż˝, tzn. wiem, jak dostaďż˝ siďż˝ do
> statycznych klas, ale przyk�ad, kt�ry mi wyszed� wcale nie zach�ca do
> skorzystania z niego. Brakuje mi kropki nad i, gdzie zobaczďż˝, dlaczego
> (oporny) programista poczu�by si� przekonany do zalet takiego
> podej�cia.

Og�lnie w tym prostym przyk�adzie wyeliminowa�em zmienny
stan (zmienna) i mo�liwo�� wyst�pienia wyj�tku. Czyli projekt
mo�na napisa� sta� si� bardziej funkcyjny. Poza tym kompilator
ma mo�liwo�� sprawdzenia, czy u�ywamy metody callMe na obiekcie na,
kt�rym jej u�ycie jest bezpieczne. W pierwszej wersji kompilator
nie m�g� tego sprawdzi�. Oczywi�cie m�j przyk�ad to by� tylko
szkic rozwi�zania.

Jaki Ci przyk�ad wyszed�? Dlaczego Tw�j przyk�ad nie zach�ca do
korzystania z niego?

Wska�� inny przyk�ad, z mojej ksi��ki o Scali:
http://www.grzegorzbalcerek.net/jps/chess_game.html
Jest tam implementacja partii szachowej. Zwr�� uwag� na sk�adow�
lastMove. Obiekt GameStart reprezentuje pocz�tkowy stan gry, a
klasa OngoingGame stany niepocz�tkowe i zauwa�, �e
lastMove (ostatni/poprzedni ruch w danej partii) jest dost�pny
tylko z tej drugiej klasy. Na pocz�tku partii nie ma sensu bo
zanim nie zosta� zrobiony �aden ruch, nie ma sensu m�wi� o
poprzednim ruchu. No i zauwa�, ze nie jest tak, �e na obiekcie
GameStart by�aby dost�pna metoda lastMove zwracaj�ca wyj�tek,
tylko zamiast tego w og�le nie ma takiej metody, ani warto�ci,
wi�c ewentualna pr�ba odwo�ania si� do niej z programu
skutkowa�aby b��dem kompilacji (a nie wyj�tkiem w czasie
wykonania)

Grzegorz

[Bartek Kuczyński]

> Poza tym kompilator
> ma możliwość sprawdzenia, czy używamy metody callMe na obiekcie na,
> którym jej użycie jest bezpieczne. W pierwszej wersji kompilator
> nie mógł tego sprawdzić. Oczywiście mój przykład to był tylko
> szkic rozwiązania.

Jeżeli zahardkodujesz konkretną klasę jako zależność to tak... jeżeli
używasz luźnych powiązań np. kontenera IoC, albo ogólniejszego typu
(nadklasy, interfejsu)?

Pozdrawiam
Bartek "Koziołek" Kuczyński
http://koziolekweb.pl
Lepiej pomyśleć dwa razy i zacząć programować
niż dwa razy programować i potem zacząć myśleć
 \     /
 ~00~
  \_/
   |||

W dniu 9 maja 2012 11:05 użytkownik Grzegorz Balcerek
<gbalc...@gmail.com> napisał:
>

>> > A przykład z klasą MyClass w kolejnych mailach nie wyjaśnia o co chodzi?
>>
>> Nie bardzo wiem, jak z tego korzystać, tzn. wiem, jak dostać się do
>> statycznych klas, ale przykład, który mi wyszedł wcale nie zachęca do
>> skorzystania z niego. Brakuje mi kropki nad i, gdzie zobaczę, dlaczego
>> (oporny) programista poczułby się przekonany do zalet takiego
>> podejścia.
>
>

> Ogólnie w tym prostym przykładzie wyeliminowałem zmienny
> stan (zmienna) i możliwość wystąpienia wyjątku.  Czyli projekt
> można napisać stał się bardziej funkcyjny.  Poza tym kompilator
> ma możliwość sprawdzenia, czy używamy metody callMe na obiekcie na,
> którym jej użycie jest bezpieczne.  W pierwszej wersji kompilator
> nie mógł tego sprawdzić.  Oczywiście mój przykład to był tylko
> szkic rozwiązania.
>
> Jaki Ci przykład wyszedł? Dlaczego Twój przykład nie zachęca do
> korzystania z niego?
>
> Wskażę inny przykład, z mojej książki o Scali:
> http://www.grzegorzbalcerek.net/jps/chess_game.html
> Jest tam implementacja partii szachowej. Zwróć uwagę na składową
> lastMove.  Obiekt GameStart reprezentuje początkowy stan gry, a
> klasa OngoingGame stany niepoczątkowe i zauważ, że
> lastMove (ostatni/poprzedni ruch w danej partii) jest dostępny
> tylko z tej drugiej klasy. Na początku partii nie ma sensu bo
> zanim nie został zrobiony żaden ruch, nie ma sensu mówić o
> poprzednim ruchu. No i zauważ, ze nie jest tak, że na obiekcie
> GameStart byłaby dostępna metoda lastMove zwracająca wyjątek,
> tylko zamiast tego w ogóle nie ma takiej metody, ani wartości,
> więc ewentualna próba odwołania się do niej z programu
> skutkowałaby błędem kompilacji (a nie wyjątkiem w czasie
> wykonania)
>
> Grzegorz

[Jacek Laskowski]

2012/5/9 Grzegorz Balcerek <gbalc...@gmail.com>:

> Jaki Ci przykład wyszedł? Dlaczego Twój przykład nie zachęca do
> korzystania z niego?

Adam Lider mnie zdopingował do intensywniejszego myślenia i wyszło jak poniżej:

package helloworld;

public class MyClass {
public static class ServletRequest extends MyClass {
public/* static */AsyncServletRequest startAsync() {
return new AsyncServletRequest();
}
}

public static class AsyncServletRequest extends MyClass {
public ServletRequest getRequest() {
return new ServletRequest();
}

public String getAsyncContext() {
return "No illegal state here; always valid.";
}
}

public static void main(String[] args) {
ServletRequest req = new ServletRequest();
AsyncServletRequest asyncReq = req.startAsync();
asyncReq.getAsyncContext();
}

}

Teraz czuję się usatysfakcjonowany! Dzięki!

Ciekawym zagrożeń takiego podejścia. Chciałbym usłyszeć, że nie
zauważa się żadnych, bo zamierzam wdrożyć to podejście w najbliższych
moich javowych wyprawach :)

[CzArNy]

Witam,

by� mo�e mi umkn�o.
Grzegorzu czy rozsy�a�e� jakie� instrukcje przygotowawcze (IDE. pluginy, projekt na Git) ??
Tak �eby nie marnowa� cennego czasu na zestawianie �rodowiska ??

Pzdr

W dniu 2012-04-26 15:57, Grzegorz Balcerek pisze:

Drodzy WJUGowcy,

ďż˝

Nazywam si� Grzegorz Balcerek. Jestem autorem ksi��ki o j�zyku Scala
(http://www.grzegorzbalcerek.net/jps.html)
Chcia�bym si� Was spyta�, czy byliby�cie zainteresowani jak��
prezentacj�/spotkaniem na temat j�zyka Scala.
W przypadku zainteresowania, ze swojej strony chcia�bym opr�cz propagowania
Scali pokaza� swoj� ksi��k� i mo�e sk�oni� kogo� do jej kupna.

ďż˝

Nie proponujďż˝ jakiegoďż˝ konkretnego, jednego tematu, a raczej kilka do
dyskusji - nie wiem co Wam najbardziej odpowiada, co Was interesuje.

ďż˝

Najbardziej mi odpowiadaj�c� form� (ze wzgl�du na konieczno��
przeznaczenia dodatkowo czasu na dojazd i powr�t do Poznania) by�yby
jakie� warsztaty w ci�gu dnia, pewnie jak�� w
sobot�. Takie spotkanie mo�e by� d�u�sze ni� zwyk�e JUGowe.
Pytanie tylko, czy co� takiego wchodzi w gr� ze wzgl�d�w organizacyjnych -
to zdaje si� nie jest standardowa forma Waszych spotka�; potrzebna, by by�a
jakaďż˝ sala.

ďż˝

Alternatyw� jest zwyk�a prezentacja na spotkaniu w normalnym terminie. Mo�e
by� wprowadzenie do Scali, mo�e by� co� bardziej zaawansowanego - ale wtedy
raczej dla os�b kt�re ju� co� wiedz� o Scali, przynajmniej podstawy, �eby
nie traciďż˝ czasu - np. o DSLach, o wtyczkach kompilatora, o bibliotece
"parsers combinators". Mo�e macie jakie� inne sugestie tematu?

ďż˝

Pozdrawiam,
Grzegorz Balcerek

--
Wiadomo�� z grupy Warszawa Java User Group (Warszawa JUG).
Wi�cej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zach�camy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

[Grzegorz Balcerek]

Powtarzam wobec tego poniżej to co pisałem w jednym z maili, jakby komuś umknęło. Jakby ktoś miał jeszcze uwagi/pomysły co do sugerowanego przebiegu spotkania to może się jeszcze oczywiście podzielić.

Grzegorz

 

 

> Dla mnie odpowiednią agendą byłoby przejście przez kolejne rozdziały
> Twojej książki - http://www.grzegorzbalcerek.net/jps/toc.html. Do
> rozdziału 21 włącznie poświęciłbym po 10 minut + 5 minut
> dyskusji/przerwy/cokolwiek, co już daje 5,25h. Na ostatnie 0,75h
> dałbym tworzenie aplikacji - podobnie do rozdziału 28.
 
Nie wydaje mi się, że taki sztywny dosyć plan to realistyczny
pomysł. Chyba, że nie będziecie zadawać pytań. Poza tym myślę, że przy
spotkaniu na żywo nie trzeba się tak ściśle trzymać określonej
kolejności, jak to jest w przypadku książki. Po zastanowieniu tak bym
to widział: Pokazywałbym na rzutniku i omawiał różne rzeczy (myślę, że
z preferencją kodowania i pokazywania przykładów na żywo raczej niż
slajdów).  Wybierałbym kolejne tematy według własnego
rozeznania/uznania i/lub uwzględniał/reagował na Wasze pytania i
sugestie na bieżąco.  Sugeruję raczej kodowanie "wspólne" - czyli ja
piszę na moim komputerze, a Wy to oglądacie na rzutniku i
komentujecie/pytacie/rzucacie pomysłami/uwagami. Wtedy wszyscy mogą
korzystać z wyjaśnień.  W związku z tym nie byłoby wymagane
przyniesienie własnego komputera, ale jakby ktoś miał i chciał sam
próbować na swoim, a potem dopytywać o coś, to też nie mam nic
przeciwko.
 
> Proponuję wcześniej udostępnić wymagany setup i przykłady. Ułatwi to
> sprawne przeprowadzenie szkolenia.
 
W związku z powyższym nie ma wymaganego setupu.
 

 

 

 

----- Original Message -----

From: CzArNy

To: warsza...@googlegroups.com

Sent: Thursday, May 10, 2012 10:17 PM

Subject: Re: [warszawa-jug] Scala

Witam,

być może mi umknęło.
Grzegorzu czy rozsyłałeś jakieś instrukcje przygotowawcze (IDE. pluginy, projekt na Git) ??
Tak żeby nie marnować cennego czasu na zestawianie środowiska ??

Pzdr

W dniu 2012-04-26 15:57, Grzegorz Balcerek pisze:

Drodzy WJUGowcy,

 

Nazywam się Grzegorz Balcerek. Jestem autorem książki o języku Scala
(http://www.grzegorzbalcerek.net/jps.html)
Chciałbym się Was spytać, czy bylibyście zainteresowani jakąś
prezentacją/spotkaniem na temat języka Scala.
W przypadku zainteresowania, ze swojej strony chciałbym oprócz propagowania
Scali pokazać swoją książkę i może skłonić kogoś do jej kupna.

 

Nie proponuję jakiegoś konkretnego, jednego tematu, a raczej kilka do

dyskusji - nie wiem co Wam najbardziej odpowiada, co Was interesuje.

 

Najbardziej mi odpowiadającą formą (ze względu na konieczność
przeznaczenia dodatkowo czasu na dojazd i powrót do Poznania) byłyby
jakieś warsztaty w ciągu dnia, pewnie jakąś w
sobotę. Takie spotkanie może być dłuższe niż zwykłe JUGowe.
Pytanie tylko, czy coś takiego wchodzi w grę ze względów organizacyjnych -
to zdaje się nie jest standardowa forma Waszych spotkań; potrzebna, by była
jakaś sala.

 

Alternatywą jest zwykła prezentacja na spotkaniu w normalnym terminie. Może
być wprowadzenie do Scali, może być coś bardziej zaawansowanego - ale wtedy
raczej dla osób które już coś wiedzą o Scali, przynajmniej podstawy, żeby
nie tracić czasu - np. o DSLach, o wtyczkach kompilatora, o bibliotece
"parsers combinators". Może macie jakieś inne sugestie tematu?

 

Pozdrawiam,
Grzegorz Balcerek

--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

[CzArNy]

WOW 03:15 dobrze widz� ???? Napi�cie przed wyst�pem przed tak zacn� WJUG-ow� publik�
sp�dza sen z powiek jak mniemam ;))

Napisa�e�
"ale jakby ktoďż˝ miaďż˝ i chciaďż˝ sam
pr�bowa� na swoim, a potem dopytywa� o co�, to te� nie mam nic
przeciwko."

Ja pewnie bym chcia�!! Z racji, �e przychodz� pozna� troch� nowego i nie mia�em styczno�ci
ze Scala mo�e m�g�by� podpowiedzie� co (IDE/pluginy/cokolwiek potrzebne) sobie "na szybko" zestawi� aby faktycznie
m�c popr�bowa� samemu ???

W dniu 2012-05-11 03:15, Grzegorz Balcerek pisze:

Powtarzam wobec tego poni�ej to co pisa�em w jednym z maili, jakby komu� umkn�o. Jakby kto� mia� jeszcze uwagi/pomys�y co do sugerowanego przebiegu spotkania to mo�e si� jeszcze oczywi�cie podzieli�.

Grzegorz

ďż˝

ďż˝

> Dla mnie odpowiedni� agend� by�oby przej�cie przez kolejne rozdzia�y
> Twojej ksi��ki - http://www.grzegorzbalcerek.net/jps/toc.html. Do
> rozdzia�u 21 w��cznie po�wi�ci�bym po 10 minut + 5 minut
> dyskusji/przerwy/cokolwiek, co juďż˝ daje 5,25h. Na ostatnie 0,75h
> da�bym tworzenie aplikacji - podobnie do rozdzia�u 28.
ďż˝
Nie wydaje mi si�, �e taki sztywny dosy� plan to realistyczny
pomys�. Chyba, �e nie b�dziecie zadawa� pyta�. Poza tym my�l�, �e przy
spotkaniu na �ywo nie trzeba si� tak �ci�le trzyma� okre�lonej
kolejno�ci, jak to jest w przypadku ksi��ki. Po zastanowieniu tak bym
to widzia�: Pokazywa�bym na rzutniku i omawia� r�ne rzeczy (my�l�, �e
z preferencj� kodowania i pokazywania przyk�ad�w na �ywo raczej ni�
slajd�w).� Wybiera�bym kolejne tematy wed�ug w�asnego
rozeznania/uznania i/lub uwzgl�dnia�/reagowa� na Wasze pytania i
sugestie na bie��co.� Sugeruj� raczej kodowanie "wsp�lne" - czyli ja
pisz� na moim komputerze, a Wy to ogl�dacie na rzutniku i
komentujecie/pytacie/rzucacie pomys�ami/uwagami. Wtedy wszyscy mog�
korzysta� z wyja�nie�.� W zwi�zku z tym nie by�oby wymagane
przyniesienie w�asnego komputera, ale jakby kto� mia� i chcia� sam
pr�bowa� na swoim, a potem dopytywa� o co�, to te� nie mam nic
przeciwko.
ďż˝
> Proponuj� wcze�niej udost�pni� wymagany setup i przyk�ady. U�atwi to
> sprawne przeprowadzenie szkolenia.
ďż˝
W zwi�zku z powy�szym nie ma wymaganego setupu.
ďż˝

ďż˝

ďż˝

ďż˝

----- Original Message -----

From: CzArNy

To: warsza...@googlegroups.com

Sent: Thursday, May 10, 2012 10:17 PM

Subject: Re: [warszawa-jug] Scala

Witam,

by� mo�e mi umkn�o.
Grzegorzu czy rozsy�a�e� jakie� instrukcje przygotowawcze (IDE. pluginy, projekt na Git) ??

Tak �eby nie marnowa� cennego czasu na zestawianie �rodowiska ??

Pzdr

W dniu 2012-04-26 15:57, Grzegorz Balcerek pisze:

Drodzy WJUGowcy,

ďż˝

Nazywam si� Grzegorz Balcerek. Jestem autorem ksi��ki o j�zyku Scala
(http://www.grzegorzbalcerek.net/jps.html)
Chcia�bym si� Was spyta�, czy byliby�cie zainteresowani jak��
prezentacj�/spotkaniem na temat j�zyka Scala.
W przypadku zainteresowania, ze swojej strony chcia�bym opr�cz propagowania
Scali pokaza� swoj� ksi��k� i mo�e sk�oni� kogo� do jej kupna.

ďż˝

Nie proponujďż˝ jakiegoďż˝ konkretnego, jednego tematu, a raczej kilka do

dyskusji - nie wiem co Wam najbardziej odpowiada, co Was interesuje.

ďż˝

Najbardziej mi odpowiadaj�c� form� (ze wzgl�du na konieczno��
przeznaczenia dodatkowo czasu na dojazd i powr�t do Poznania) by�yby
jakie� warsztaty w ci�gu dnia, pewnie jak�� w
sobot�. Takie spotkanie mo�e by� d�u�sze ni� zwyk�e JUGowe.
Pytanie tylko, czy co� takiego wchodzi w gr� ze wzgl�d�w organizacyjnych -
to zdaje si� nie jest standardowa forma Waszych spotka�; potrzebna, by by�a
jakaďż˝ sala.

ďż˝

Alternatyw� jest zwyk�a prezentacja na spotkaniu w normalnym terminie. Mo�e
by� wprowadzenie do Scali, mo�e by� co� bardziej zaawansowanego - ale wtedy
raczej dla os�b kt�re ju� co� wiedz� o Scali, przynajmniej podstawy, �eby
nie traciďż˝ czasu - np. o DSLach, o wtyczkach kompilatora, o bibliotece
"parsers combinators". Mo�e macie jakie� inne sugestie tematu?

ďż˝

Pozdrawiam,
Grzegorz Balcerek

--

Wiadomo�� z grupy Warszawa Java User Group (Warszawa JUG).
Wi�cej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zach�camy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

--
Wiadomo�� z grupy Warszawa Java User Group (Warszawa JUG).
Wi�cej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zach�camy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

--
Wiadomo�� z grupy Warszawa Java User Group (Warszawa JUG).
Wi�cej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zach�camy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

[Grzegorz Balcerek]

> WOW 03:15 dobrze widzę ???? Napięcie przed występem przed tak zacną WJUG-ową publiką
> spędza sen z powiek jak mniemam ;))

 

Czas ucieka, wieczność czeka :) Nie ma co tracić czasu :) Raczej
nie robie wielkich przygotowań. Pewien scenariusz
domyślny (zgrubny) mam, ale myślę, że pójdziemy na żywioł i od
Waszych interakcji/pytań będzie też zależeć w którą stronę się
potoczą warsztaty.

 

> ze Scala może mógłbyś podpowiedzieć co (IDE/pluginy/cokolwiek potrzebne) sobie "na szybko" zestawić aby faktycznie
> móc popróbować samemu ???

 

Do poznawania Scali polecam po prostu REPL, czyli taką
interaktywną konsolę z linią poleceń. Wystarczy mieć
zainstalowaną po prostu samą Scalę. Czy to mam opisywać? I jakiś
edytor może się przydać do prostych plików. Skomplikowanych
projektów raczej nie będziemy robić :) Java 1.5 lub wyższa jest
potrzebna do Scali. Ja mam 1.6 i scalę skompilowaną ze
źródeł. Źródła sobie podglądam zresztą czasem. Ale oczywiście nie
trzeba. Jeśli masz 1.6 i Windows to możesz sobie po prostu
skopiować ode mnie odpowiedni katalog i ustawić ścieżkę i powinno działać.

 

Żeby sprawdzić czy działa trzeba po prostu wpisać polecenie "scala" bez argumentów.
Patrz tutaj: http://www.grzegorzbalcerek.net/jps/intro_repl.html

 

Jest nawet coś takiego: http://www.simplyscala.com/ gdzie taki REPL (ale z scalą 2.8) można z przeglądarki używać bez instalacji niczego.

 

IDE to już opcjonalnie. I to już zależy od upodobań Twoich których nie znam.

 

Jeśli chciałbyś konfigurować na przykład Eclipse, to spójrz na przykład tutaj
http://scala-ide.org/download/current.html
albo tutaj na taki krótki filmik: http://scala-ide.org/docs/user/gettingstarted.html
Po prostu trzeba zainstalować wtyczkę.

 

Ale IDE to już niekoniecznie. Jak jest REPL to już można poznawać Scalę.

 

Grzegorz

[Łukasz Lenart]

W dniu 11 maja 2012 09:24 użytkownik Grzegorz Balcerek
<gbalc...@gmail.com> napisał:

> Czas ucieka, wieczność czeka :) Nie ma co tracić czasu :) Raczej
> nie robie wielkich przygotowań. Pewien scenariusz
> domyślny (zgrubny) mam, ale myślę, że pójdziemy na żywioł i od
> Waszych interakcji/pytań będzie też zależeć w którą stronę się
> potoczą warsztaty.

Dobrze abyś nie pozwalał na dłuższą dyskusję czy drążenie tematu. Może
to powodować, że reszta grupy będzie się nudzić. Zapisz pytanie i w
przerwie, czy później na grupie można je omówić. I trzymanie się planu
pozwala przekazać to co sobie zaplnaowałeś, więc ucinanie dywagacji i
pustych dyskusji jak najbardziej wskazne ;-)


Pozdrawiam
--
Łukasz http://www.lenart.org.pl/
mobile +48 606 323 122, office +27 11 0838747
Warszawa JUG conference - Confitura http://confitura.pl/