pare ogłoszeń ;-)
Tomasz Szymański
Krzysztof Grajek
z góry dzieki
Pozdrawiam
Krzysztof Grajek
--
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
Adam Warski
Reszty da sie douczyć ;)
Adam
--
Adam Warski
http://twitter.com/#!/adamwarski
http://www.softwaremill.com
http://www.warski.org
Bartek Zdanowski
A możesz cos wiecej napisać na temat 'Starszy programista JEE6' - wymagania, mile widziane, itp..
z góry dzieki
Pozdrawiam
Krzysztof Grajek2011/11/21 Tomasz Szymański <szi...@szimano.org>
Hej Grupo,SoftwareMill pewnie pare osob stad kojarzy - przyszla jesien i poszukujemy ludzi do pracy.Z tego co moze was interesowac, to programista JEE6 i frontendowiec. Firma calkiem fajna (chyba ;-) ), praca z domu. Na grupie sporo osob od nas, mozna sie podpytac co i jak.Osoby z WJUGa maja generalnie wyzszy priorytet :]T.--
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
Pozdrawiam,
Bartek Zdanowski
Bloguję http://blog.bartekzdanowski.pl i twittuję http://twitter.com/bartekzdanowski
Confitura 2011 (dawniej Javarsovia) - http://confitura.pl
KO Warsjawa 2011 - http://warsjawa.pl
Tomasz Dziurko
On 21 Lis, 16:30, Bartek Zdanowski <bartek.zdanow...@gmail.com> wrote:
> 2011/11/21 Krzysztof Grajek <krzysztof.gra...@googlemail.com>
>
> > A możesz cos wiecej napisać na temat 'Starszy programista JEE6' -
> > wymagania, mile widziane, itp..
>
> Chyba opis stanowiska i widełki ;)
Trochę więcej można przeczytać w ogłoszeniach na
https://groups.google.com/group/oferty-pracy-java
--
Pozdrawiam,
Tomek Dziurko
http://tomaszdziurko.pl
Adam Warski
Jak już Tomek napisał opisy i widełki są tutaj:
https://groups.google.com/forum/#!topic/oferty-pracy-java/uIJcknEufyE
https://groups.google.com/forum/#!topic/oferty-pracy-java/Q8DrFJKhPZ0
Adam
--
Jacek Laskowski
To już wiemy, kto sponsoruje przyszłą pizzę :)
Jacek
--
Jacek Laskowski
Java EE, functional languages and IBM WebSphere - http://blog.japila.pl
Warszawa JUG conference = Confitura (formerly Javarsovia) :: http://confitura.pl
"Hoping to save time by spending it" by David Blevins (Apache OpenEJB)
Tomasz Szymański
Jacek Laskowski
> Spoko, da sie zrobic ;-)
O, widzicie! Jak pożądna firma, to o pizzę nie trudno!
Dominik Wiernicki
Jacek Laskowski
> Jak już mowa o Pizzy. Będzie darmowa we wtorek na PW. Jeśli ktoś nie ma nic
> przeciwko Microsoftowi to info na
> stronie http://www.codeguru.pl/kalendarium/podglad-wydarzenia/it-academic-day-politechnika-warszawska,5550
Zabrzmiało, jakbyśmy wszyscy tylko przychodzili na spotkania
dla...pizzy (!) :-) Jak mi to ktoś uzmysłowił, kiedy chce się przyjść
na ciekawy temat na spotkaniu, a jest się po pracy i głodnym jak wilk,
to pizza jest dobrym motywatorem. Mam wrażenie, że w konfiguracji z
Microsoft można nabawić się poważnych niestrawności ;-)
Bartek Zdanowski
2011/11/27 Dominik Wiernicki <dmn...@gmail.com>:
> Jak już mowa o Pizzy. Będzie darmowa we wtorek na PW. Jeśli ktoś nie ma nicZabrzmiało, jakbyśmy wszyscy tylko przychodzili na spotkania
> przeciwko Microsoftowi to info na
> stronie http://www.codeguru.pl/kalendarium/podglad-wydarzenia/it-academic-day-politechnika-warszawska,5550
dla...pizzy (!) :-) Jak mi to ktoś uzmysłowił, kiedy chce się przyjść
na ciekawy temat na spotkaniu, a jest się po pracy i głodnym jak wilk,
to pizza jest dobrym motywatorem. Mam wrażenie, że w konfiguracji z
Microsoft można nabawić się poważnych niestrawności ;-)
Jacek
--
Jacek Laskowski
Java EE, functional languages and IBM WebSphere - http://blog.japila.pl
Warszawa JUG conference = Confitura (formerly Javarsovia) :: http://confitura.pl
"Hoping to save time by spending it" by David Blevins (Apache OpenEJB)
--
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
Krzysztof Nielepkowicz
przyjemniejszy. Jednak nie mog� si� oprze� wra�eniu �e repertuar IT AD
m�g�by by� ciekawszy bo stek marketingowych bzdet�w Normana oraz Kinect
i chwalenie siďż˝ wynikami z Imagine Cup raczej do ciekawych rzeczy nie
nale�y. Najciekawiej z tego wygl�da Expression Blend, tyle �e MS ma
bardzo du�o innych intryguj�cych rzeczy, pierwszy z brzegu, nienowy
LINQ, albo LightSwitch - chwal� si� �e bardzo przy�piesza ca�y proces
tworzenia - ciekawe ile to warte jest.
Pozdrawiam,
Krzysiek
> 2011/11/27 Dominik Wiernicki<dmn...@gmail.com>:
>> Jak ju� mowa o Pizzy. B�dzie darmowa we wtorek na PW. Je�li kto� nie ma nic
>> przeciwko Microsoftowi to info na
>> stronie http://www.codeguru.pl/kalendarium/podglad-wydarzenia/it-academic-day-politechnika-warszawska,5550
> Zabrzmia�o, jakby�my wszyscy tylko przychodzili na spotkania
> dla...pizzy (!) :-) Jak mi to kto� uzmys�owi�, kiedy chce si� przyj��
> na ciekawy temat na spotkaniu, a jest si� po pracy i g�odnym jak wilk,
> to pizza jest dobrym motywatorem. Mam wra�enie, �e w konfiguracji z
> Microsoft mo�na nabawi� si� powa�nych niestrawno�ci ;-)
>
> Jacek
>
Zayl
pomocą tego to przyjemność. Co do samego języka to chociażby wyrażenia
lambda czy klasy częściowe
Expression Blend - GUI Designer z prawdziwego zdarzenia, projekty
WPF,Silverlight,WP7, a w perspektywie Metro App za pomocą jednego
narzędzia. Odpowiednikiem (w pewnym sensie) dla JavaFX będzie
powstający Scene Builder.
Co do innych ciekawych projektów to np Surface:
http://www.microsoft.com/surface/en/us/default.aspx
ags
--
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
Jakub Nabrdalik
AFAIK na rzecz HTML5
Zayl
Desktop'ów, niedługo wyjdzie Silverlight 5 (narazie wersja RC). Słyszy
się że dalej niż 5, nie będzie rozwijany. MS ani zaprzecza, ani
potwierdza. Co nie zmienia faktu że to ciekawa technologia, chociażby
wykorzystanie XAML (coś jak FXML dla JavaFX),wspomniany Blend, Smooth
Streamming, w wersji 5 wsparcie dla 3D i inne rozszerzenia. Z HTML5 u
MS jest tak że sporo na tą technologię stawiają (Windows 8 ? :)).
Jeżeli Silverlight nie będzie wspierany, szkoda, bo mi się podoba. A
HTML5 też jest fajny, ale wszystkiego nie rozwiąże.
Jacek Laskowski
> Eee bez przesady, MS ma sporo fajnych rzeczy a ich...
F# jest ciągle na mojej liście do rozpoznania :( Tyle dobrego słyszę o
tym języku.
Krzysztof Nielepkowicz
czasach po tym jak Sun poczu� si� ura�ony �e uda�o si� komu� innemu
zrobiďż˝ wydajniejszďż˝ implementacjďż˝ VM :P
> 2011/11/28 Krzysztof Nielepkowicz<k.p.niel...@gmail.com>:
>> Eee bez przesady, MS ma sporo fajnych rzeczy a ich...
> tym j�zyku.
>
> Jacek
>
Jacek Laskowski
> OMG! A cóż to? Literek im braknie? Z J# się wycofali w zamierzchłych czasach
> po tym jak Sun poczuł się urażony że udało się komuś innemu zrobić
> wydajniejszą implementację VM :P
F# - język funkcyjny (podobno jakoś związany z OCaml) na .Net. Z tym
językiem jest spore zamieszanie, bo sam Microsoft nie wie, jak go
reklamować i jak mocno. Jest włączony do Visual Studio, ale wciąż obok
C# i VB, więc F# męczy się jak Scala i walczą o swoje miejsce na VM
(pierwszy na CLR a drugi na JVM). W zasadzie tutaj kończy się moja
wiedza.
Irek Matysiewicz
Daniel Janus
Jakub Nabrdalik
Tak, wykorzystując proste biblioteki typu Guava. Od konwersji danych, po
operacje na kolekcjach.
Mały przykład będzie też na Agile Development Day 2011, bo biblioteka
dostępu do cassandry, korzysta właśnie w ten sposób z Guavy.
Ale nie wiem czy o to Ci chodziło, bo to takie "bidne" wykorzystanie
programowania funkcyjnego, lata świetlne od miksowania haskela/scali z
javą :)
Disclaimer: nie umiem "w mojej definicji tego słowa" programować w
żadnym języku funkcyjnym - poznałem tylko jakieśtam podstawowe założenia.
--
Jakub Nabrdalik
http://solidcraft.eu
Adam Jurzyk
2011/11/29 Daniel Janus <d...@danieljanus.pl>:
> A co to są "aplikacje enterprise"?
>
Irek Matysiewicz
http://en.wikipedia.org/wiki/Enterprise_software
Czyli krótko mówiąc, aplikacje enterprise to to co większość z nas ma (nie)przyjemność tworzyć w pracy.
@Jakub
Nie, nie chodziło mi o małe fragmenty funkcyjne robione w Guavie, czy LINQ, tylko o napisanie aplikacji w całości w tym podejściu - jakoś czarniutko to widzę.
Jakub Nabrdalik
> @Jakub
> Nie, nie chodziło mi o małe fragmenty funkcyjne robione w Guavie, czy
> LINQ, tylko o napisanie aplikacji w całości w tym podejściu - jakoś
> czarniutko to widzę.
Heh, ja też, ale nie dlatego że to złe rozwiązanie (to imho bardzo dobre
rozwiązanie pewnej klasy problemów), tylko dlatego, że na 60 osób w
firmie mamy jedną, która kuma programowanie funkcyjne i drugą, która się
uczy.
A ktoś musi potem te aplikacje utrzymywać :]
Krzysztof Nielepkowicz
kiedy mo�e sprosta� wyzwaniom. Dawno temu by� taki j�zyk SmallTalk - dla
ma�om�wnych, czysto obiektowy, reprezentuj�cy pi�kne idea�y. Jednak dzi�
ma�o kto w nim pisze, obecnie jego g��wnym zastosowaniem jest m�czenie
student�w. Przegra� z "brudn�" Jav�, tak� hipokrytk� kt�ra uwa�a si� za
obiektow� a cho�by dost�p do obiekt�w nie jest obiektowy, nie
wspominaj�c o prymitywach takich jak int :P . Czas pokaza� �e to w�a�nie
Java si� przyj�a i p�ki co ma si� dobrze :)
Pozdrawiam,
Krzysiek
> @Daniel
> http://en.wikipedia.org/wiki/Enterprise_software
> Czyli kr�tko m�wi�c, aplikacje enterprise to to co wi�kszo�� z nas ma
> (nie)przyjemno�� tworzy� w pracy.
>
>
> @Jakub
> Nie, nie chodzi�o mi o ma�e fragmenty funkcyjne robione w Guavie, czy
> LINQ, tylko o napisanie aplikacji w ca�o�ci w tym podej�ciu - jako�
> czarniutko to widzďż˝.
> --
> 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
Michal Margiel
<iir...@gmail.com> napisał:
>
> @Jakub
> Nie, nie chodziło mi o małe fragmenty funkcyjne robione w Guavie, czy LINQ,
> tylko o napisanie aplikacji w całości w tym podejściu - jakoś czarniutko to
> widzę.
Ale scala to nie jest czysto funkcyjny język. To jest połączenie
języka funkcyjnego i objektowego, czyli taka jakby java +, wspomniana
przez Kubę, Guava, a ja jeszcze od siebie dorzucę wprost uwielbiane
przeze mnie LambdaJ. Dlatego moim zdaniem Scala to jest dobry
kierunek. Tam gdzie potrzebujesz objektów - używasz obiektów. gdy zaś
potrzebujesz domknięcia/operacji na listach - używasz funkcyjnej
części.
Dlatego tez nie zgadzałem się z tym co, moim zdaniem, próbował
promować Jacek na swoich prezentacjach o clojure - robienie wszystko w
funkcjach.
--
Pozdrawiam/Best regards
Michał Margiel
http://www.confitura.pl (dawniej Javarsovia)
http://www.linkedin.com/in/MichalMargiel
http://www.margiel.eu
Daniel Janus
Michal Margiel
<d...@danieljanus.pl> napisał:
> Irek: Nie jestem pewien czy to podpada pod Twoją definicję, ale silnik
> fablo.pl (w którym miałem przyjemność maczać palce) jest w całości napisany
> w Clojure.
IMHO to jest dość specyficzny projekt, nieporównywalny z projektami
"biznesowymi", które (zapewne) większość z nas tworzy.
>
> Michał: Dlaczego? Bardzo niewiele widziałem obiektowego kodu, którego nie
> dałoby się przepisać równie klarownie bez obiektów.
Naprawdę zamodelowanie np "koszyka na zakupy" wraz z "Zakupami" do
tego dowiaząnego do niego uzytkownika będzie tak samo czytelne w
języku obiektowym jak i funkcyjnym? Proszę zatem o przykład.
Daniel Janus
Naprawdę zamodelowanie np "koszyka na zakupy" wraz z "Zakupami" do
tego dowiaząnego do niego uzytkownika będzie tak samo czytelne w
języku obiektowym jak i funkcyjnym? Proszę zatem o przykład.
Irek Matysiewicz
let product1 = cośtam
let product2 = cośtam innego
let koszyk = Cart (User ...) [(product1, 1), (product2, 5)]
I powiedzmy, że chcesz zmienić nazwę produktu 2. W Javie to byłoby po prostu product2.setName(nowa nazwa), a w czystym podejściu funkcyjnym musisz skopiować product2 zmieniając mu nazwę, skopiować parę zamieniając stary product2 na nowy, potem skopiować listę zamieniając starą krotkę na nową, potem skopiować koszyk zamieniając starą listę na nową, potem skopiować każdy obiekt używający koszyk zamieniając stary koszyk na nowy, i tak dalej aż do obiektu "na wierzchu" ...
Prosta operacja CRUD a doszliśmy do kosztownej i dosyć niewygodnej rekursji.
Jacek Laskowski
> I powiedzmy, że chcesz zmienić nazwę produktu 2.
Bardzo dobry przykład, przy którym zapytam - czy użytkownik kupił
produkt 2 o nazwie starej czy nowej? Czy wolno Ci zmienić nazwę
produktu użytkownikowi? Stąd nowi kupujący mają produkt z nową nazwą a
starzy ze starzą - już trzymają stan z poprzedniej ery.
Zaczyna mi się podobać ten wątek...dodam, że SML wchodzi w pizzę i
informacja już niebawem! Normalnie bajka z tym WJUGiem.
Irek Matysiewicz
Równie dobrze może być tak: gdy użytkownik ma już pełny koszyk i "idzie do kasy" spostrzegł że ma podany już nieaktualny adres i chce go zmienić przed wysłaniem zamówienia, i znowu mamy ten sam problem.
Jacek Laskowski
Naprawdę? Wtedy stary adres, który jest "zafiksowany" odrzucamy
(podobnie jak Clojure, a później GC) i dodajemy do struktury nowy
adres. Podkreślam słowo "struktura", która przypomina obiekt, ale nim
nie jest - podobnie jak struct w C (ale tylko podobnie). Za bardzo
myślisz obiektowo, które służą do schowania zmiennego stanu, a w FP
wszystko jest stałe.
Irek Matysiewicz
Piotrek
wszystkie jezyki sa rownowazne ale kazdy z nich ma jakas swoja nisze.
tak jak trudno mi wyobrazic sobie programowanie mysliwcow w javie tak
samo trudno mi wyobrazic sobie pisanie typowej aplikacji biznesowej w
j funkcyjnym (chociaz moze to tylko problem mojej wyobrazni). co
prawda widzialem takie proby (czy przypadkiem ktos na jugu nawet sie
tym nie chwalil?) ale na razie traktuje to bardziej jako rozrywke
intelektualna niz wydajne tworzenie produkcyjnego kodu.
natomiast jesli do aplikacji trzeba by dolaczyc jakis system regulowy
albo inne AI to wtedy nie zdziwilo by mnie, ze znacznie latwiej /
czytelniej mozna to napisac w jakims prologu, ocamlu czy innych
wynalazkach. inna sprawa to znalezienie czlowieka, ktory zrobilby to w
miare szybko
On 29 Lis, 14:35, Irek Matysiewicz <iir...@gmail.com> wrote:
> @Danielhttp://en.wikipedia.org/wiki/Enterprise_software
Irek Matysiewicz
Jacek Laskowski
> Chyba zupełnie się nie rozumiemy - weź przerób ten mój nieżyciowy przykład
> (jest dobry bo dużo zagnieżdżeń) na funkcyjnie tak jak ty uważasz i wtedy
> pogadamy. :-)
Za słabym w FP. Sam borykam się z ogarnięciem tego wszystkiego i
doświadczenie w OO wcale mi nie pomaga. Sądzę, że do Clojure i FP
wrócę na dobre dopiero w styczniu i wierzę, że wtedy znajdę odpowiedź
na Twoje pytania.
Bartek Kuczyński
FP było, jest i będzie przyszłością IT i stan ten nie zmieni się zapewne nigdy.
Z dwóch powodów:
1. Jest drogie. Specjalistów jest niewielu i się cenią. Programistów OO jest znacznie więcej i są tańsi.
2. FP jest trudne. Trzeba mieć dość dobre podstawy zarówno jako programista jak i jako matematyk zatem ciężko o np. scripting kids piszące w Haskellu.
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~
\_/
|||
--
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
Paweł Lipiński
Irek Matysiewicz
Irek Matysiewicz
Ja najlepsze rozwiązanie tego problemu widzę w dopuszczeniu się drobnego oszustwa: by uniknąć skomplikowanego zmieniania wartości encji, to akurat możemy robić imperatywnie, a wszystko inne funkcyjnie. Wtedy pojedynczy request HTTP w takiej aplikacji by się składał z takich faz:
- imperatywna (np. przepisanie danych z kontrolek do encji, tak jak zmiana czegośtam w przykładzie z koszykiem zakupów)
- funkcyjna (megaskomplikowane obliczenia w stylu Domain Driven Design, korzystalibyśmy tu z zalet kodu funkcyjnego nad imperatywnym)
- imperatywna (np. zapis wyników obliczeń do encji, zapis zmian w encjach do bazy)
Miałoby szanse działać ale nie wiem jak by wyglądało w praktyce. Co o tym myślicie?
Krzysztof Daniel
--
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
Krzysztof Daniel
Irek Matysiewicz
Zawsze lepiej jakąś paskudną operację na URL-ach zaenkapsulować do postaci obiekt.zróbCoś(). Może chciałeś być zbyt dokładny i twoje obiekty były zbyt szczegółowe?
Nie myl programowania obiektowego z programowaniem imperatywnym, to dwie różne rzeczy, programowanie obiektowe jest "nakładką" na programowanie imperatywne (Java, C++) albo funkcyjne (Scala, OCaml), problem w tym wątku to nie jest obiektowe vs funkcyjne, tylko imperatywne vs funkcyjne.
Krzysztof Daniel
Irek Matysiewicz
mproch Gazeta.pl
Prosty algorytm serializacji i deserializacji z użyciem refleksji w Javie można napisać w góra kilka godzin. A jeśli dane do tej bazy są transferowane jako XML czy JSON to gotowe serializatory dla Javy już istnieją (JAXB, Jackson).
Jakub Nabrdalik
<mpr...@gazeta.pl> napisał:
> otóż to...
> jest jeszcze XStream (zarówno do JSON jak i XML)
> a jak się użyje wsparcia Groovy/Grails to już w ogóle nic nie trzeba robić
> ;)
No nie tak nic. "To XML" poszło co prawda w jedną linijkę, ale "from
XML" myślę że z 5 będzie ;)
Piotr Ostrowski
gorzej, jak się chce tworzyć własne aliasy elementów XML i konwertery dla
niektórych obiektów.
Ciekawie wygląda też Simple [1], który dość mocno wspiera adnotacje i
zapewnia podobne możliwości do XStream'a.
[1] http://simple.sourceforge.net
--
Piotr Ostrowski
http://yuppy.pl
Irek Matysiewicz
Vitaliy Oliynyk
W XStream'ie dla toXML i fromXML jest jedna linijka w kodzie. Jest trochę gorzej, jak się chce tworzyć własne aliasy elementów XML i konwertery dla niektórych obiektów.
Ciekawie wygląda też Simple [1], który dość mocno wspiera adnotacje i zapewnia podobne możliwości do XStream'a.
[1] http://simple.sourceforge.net
Dnia 04-12-2011 o 23:10:28 Jakub Nabrdalik <jak...@gmail.com> napisał(a):Piotr Ostrowski
W dniu 4 grudnia 2011 20:38 użytkownik mproch Gazeta.pl
<mpr...@gazeta.pl> napisał:
otóż to...
jest jeszcze XStream (zarówno do JSON jak i XML)
a jak się użyje wsparcia Groovy/Grails to już w ogóle nic nie trzeba robić
;)
No nie tak nic. "To XML" poszło co prawda w jedną linijkę, ale "from
XML" myślę że z 5 będzie ;)
--
http://yuppy.pl
Jacek Laskowski
> Jacku, kończy się styczeń a ja jestem bardzo pamiętliwy: masz już odpowiedź
> na moje pytania? :-)
Dawaj je na tapetę, bo żadnego nie odnotowałem do odpowiedzi. Wybacz,
jeśli musisz je powtórzyć. Nie darowałbym sobie, gdybym nie
odpowiedział Tobie!
Irek Matysiewicz
2012/1/31 Irek Matysiewicz <iir...@gmail.com>:
> Jacku, kończy się styczeń a ja jestem bardzo pamiętliwy: masz już odpowiedźDawaj je na tapetę, bo żadnego nie odnotowałem do odpowiedzi. Wybacz,
> na moje pytania? :-)
jeśli musisz je powtórzyć. Nie darowałbym sobie, gdybym nie
odpowiedział Tobie!
No twój ostatni wpis:
Jacek Laskowski
> No twój ostatni wpis:
>
>
>> Chyba zupełnie się nie rozumiemy - weź przerób ten mój nieżyciowy przykład
>> (jest dobry bo dużo zagnieżdżeń) na funkcyjnie tak jak ty uważasz i wtedy
>> pogadamy. :-)
>
> Za słabym w FP. Sam borykam się z ogarnięciem tego wszystkiego i
> doświadczenie w OO wcale mi nie pomaga. Sądzę, że do Clojure i FP
> wrócę na dobre dopiero w styczniu i wierzę, że wtedy znajdę odpowiedź
> na Twoje pytania.
Ach ten. Szczęśliwie usiadłem do clojure i fp w styczniu, i sądzę, że
czuję problem na tyle, aby go zademonstrować w praktyce. Niech będzie
na żywym organiźmie - librarian-clojure [1]. Rozumiem, że towarem może
być książka, a klientem - Ty, ja, WJUGowicze?
Staram się jeszcze podsumować naszą dyskusję, abym dobrze obsłużył
problem (niech to będzie przyczynek do prezentacji Clojure na WJUGu et
al). Rozumiem, że w:
2011/11/29 Irek Matysiewicz <iir...@gmail.com>:
dopuszczasz sytuację, w której klient kupuje towar o nazwie X i
podchodząc do kasy widzi, że nazwa się zmieniła na Y? Czy dopuszczasz
sytuację, w której liczba 1 będzie dwójką po pewnym czasie?
[1] https://github.com/jaceklaskowski/librarian-clojure
Irek Matysiewicz
> let product1 = cośtam
> let product2 = cośtam innego
> let koszyk = Cart (User ...) [(product1, 1), (product2, 5)]
Chyba dałem zbyt wieloznaczny przykład. Może coś prostszego: przy podejściu do kasy orientuję się że chcę kupić nie jedną a dwie sztuki produktu product1. W Javie to by było (trochę brzydko): koszyk.getProdukty().get(0).setAmount(1).
W podejściu funkcyjnym musisz:
- skopiować krotkę: (product1, 1) -> (product1, 2)
- skopiować listę: [(product1, 1), (product2, 5)] -> [(product1, 2), (product2, 5)]
- skopiować koszyk: Cart (User ...) [(product1, 1), (product2, 5)] -> Cart (User ...) [(product1, 2), (product2, 5)]
Kopiowanie jest kłopotliwe bo:
- spowalnia aplikację - ale tu teoretycznie mądry kompilator nas może wyręczyć przerabiając kod na szybszy odpowiednik: koszyk.getProdukty().get(0).setAmount(1) (czy np. kompilator Scali czy Clojure potrafi to zoptymalizować???)
- spowalnia programistę - wygodniej wywołać setCośtam niż przebudowywać całe drzewo obiektów gdy to przebudowywanie nie jest potrzebne
[1] https://github.com/jaceklaskowski/librarian-clojure
Jakub Nabrdalik
> dopuszczasz sytuację, w której klient kupuje towar o nazwie X i
> podchodząc do kasy widzi, że nazwa się zmieniła na Y?
Wszystkie znane mi sklepy (z jednym wyjątkiem) dopuszczają sytuację, w
której klient przy podejściu do kasy dowiaduje się, że:
- w międzyczasie cena się zmieniła
- w międzyczasie opis/skład produktu się zmienił
- w międzyczasie produkt się zrobił niedostępny
Czy dopuszczasz
> sytuację, w której liczba 1 będzie dwójką po pewnym czasie?
Produkt to raczej nie jest value object :)
--
Jakub Nabrdalik
blog.solidcraft.eu
Irek Matysiewicz
Wszystkie znane mi sklepy (z jednym wyjątkiem) dopuszczają sytuację, w której klient przy podejściu do kasy dowiaduje się, że:dopuszczasz sytuację, w której klient kupuje towar o nazwie X i
podchodząc do kasy widzi, że nazwa się zmieniła na Y?
- w międzyczasie cena się zmieniła
- w międzyczasie opis/skład produktu się zmienił
- w międzyczasie produkt się zrobił niedostępny
Załóżmy że to użytkownik sam chce poprawić wybraną ilość produktu a z zewnątrz nic się nam nie zmieniło.
Produkt to raczej nie jest value object :)
Czy dopuszczasz
sytuację, w której liczba 1 będzie dwójką po pewnym czasie?
Jacek Laskowski
> Wszystkie znane mi sklepy (z jednym wyjątkiem) dopuszczają sytuację, w
> której klient przy podejściu do kasy dowiaduje się, że:
> - w międzyczasie cena się zmieniła
> - w międzyczasie opis/skład produktu się zmienił
> - w międzyczasie produkt się zrobił niedostępny
A jak to jest w życiu? Czy zaakceptowałbyś tę sytuację w sklepie,
kiedy wziąłeś produkt, bo cena była właściwa, podobnie skład, czy w
ogóle jego dostępność? Uważam to za anomalię, że system miałby
pozwolić na wybór, aby później powiedzieć mi...niedostępny. Rozumiem
okres rezerwacji, który mija, ale tak bez ostrzeżenia -
niedopuszczalne.
> Produkt to raczej nie jest value object :)
Myślisz o OO w Javie i Scali. A jak byłoby to w językach funkcyjnych?
Mam wrażenie, że patrzysz na problemy przez pryzmat narzędzia, którym
dysponujesz, a nie odwrotnie (popraw mnie, jeśli się mylę i wybacz
uwagę, jeśli bezzasadna - nie chcę i nie zamierzam zamienić tej
dyskusji w obrzucanie się błotem, a to ostatnio niestety mi wychodzi).
Jacek Laskowski
> Chyba dałem zbyt wieloznaczny przykład. Może coś prostszego: przy podejściu
> do kasy orientuję się że chcę kupić nie jedną a dwie sztuki produktu
> product1. W Javie to by było (trochę brzydko):
> koszyk.getProdukty().get(0).setAmount(1).
> W podejściu funkcyjnym musisz:
> - skopiować krotkę: (product1, 1) -> (product1, 2)
> - skopiować listę: [(product1, 1), (product2, 5)] -> [(product1, 2),
> (product2, 5)]
> - skopiować koszyk: Cart (User ...) [(product1, 1), (product2, 5)] -> Cart
> (User ...) [(product1, 2), (product2, 5)]
>
> Kopiowanie jest kłopotliwe bo:
> - spowalnia aplikację - ale tu teoretycznie mądry kompilator nas może
> wyręczyć przerabiając kod na szybszy odpowiednik:
> koszyk.getProdukty().get(0).setAmount(1) (czy np. kompilator Scali czy
> Clojure potrafi to zoptymalizować???)
> - spowalnia programistę - wygodniej wywołać setCośtam niż przebudowywać całe
> drzewo obiektów gdy to przebudowywanie nie jest potrzebne
Już wiem, gdzie zmierzasz. Pozwól mi odpowiedzieć prezentując kod w
Clojure. Niech to będzie ćwiczenie przed prezentacją.
Michal Margiel
2012/2/1 Jakub Nabrdalik <jak...@gmail.com>:
A jak to jest w życiu? Czy zaakceptowałbyś tę sytuację w sklepie,
> Wszystkie znane mi sklepy (z jednym wyjątkiem) dopuszczają sytuację, w
> której klient przy podejściu do kasy dowiaduje się, że:
> - w międzyczasie cena się zmieniła
> - w międzyczasie opis/skład produktu się zmienił
> - w międzyczasie produkt się zrobił niedostępny
kiedy wziąłeś produkt, bo cena była właściwa, podobnie skład, czy w
ogóle jego dostępność? Uważam to za anomalię, że system miałby
pozwolić na wybór, aby później powiedzieć mi...niedostępny. Rozumiem
okres rezerwacji, który mija, ale tak bez ostrzeżenia -
niedopuszczalne.
--
Pozdrawiam/Best regards
Michał Margiel
http://www.confitura.pl (dawniej Javarsovia)
http://www.linkedin.com/in/MichalMargiel
http://www.margiel.eu
Wojciech Erbetowski
--
Jacek Laskowski
> Także odpowiedź jak zwykle - to zależy :-)
A jak to zamierzasz rozwiązać w środowisku rozproszonym, albo po
prostu wielowątkowym (bardziej realistyczne)? Pewnie transakcja
zostaje wycofana i następuje ponowne włożenie do koszyka (to właśnie
przypadek Michała, gdzie cała transakcja/operacja została jakby
ponownie wykonana).
Ponownie mam wrażenie, że nasze systemy tak działają, bo...takie mamy
narzędzia. Podobnie w sklepie - dlaczego ceny nie są wyświetlane, a
ceny aktualizowane jak w kasie?!
Grzegorz Duda
Grzegorz Duda (http://www.dworld.pl/page/show/Grzegorz_Duda/)
33rd Degree conference for Java Masters (http://33degree.org)
Developers World (http://www.dWorld.pl)
JAVA exPress (http://www.javaexpress.pl)
Jakub Nabrdalik
> 2012/2/1 Jakub Nabrdalik <jak...@gmail.com>:
>
>> Wszystkie znane mi sklepy (z jednym wyjątkiem) dopuszczają sytuację, w
>> której klient przy podejściu do kasy dowiaduje się, że:
>> - w międzyczasie cena się zmieniła
>> - w międzyczasie opis/skład produktu się zmienił
>> - w międzyczasie produkt się zrobił niedostępny
>
> A jak to jest w życiu? Czy zaakceptowałbyś tę sytuację w sklepie,
> kiedy wziąłeś produkt, bo cena była właściwa, podobnie skład, czy w
> ogóle jego dostępność? Uważam to za anomalię, że system miałby
> pozwolić na wybór, aby później powiedzieć mi...niedostępny. Rozumiem
> okres rezerwacji, który mija, ale tak bez ostrzeżenia -
> niedopuszczalne.
Jacku, bardzo to słuszne.
A teraz wracamy na ziemię. Na ziemi, developerzy robią software
spełniający wymagania klienta. Z tych kilku sklepów które zrobiłem, w
prawie wszystkich (w przeciwieństwie do systemów
magazynowo-sprzedażowych/ERP, które robiłem), klient życzył sobie by
towar nie był rezerwowany przy wkładaniu do koszyka i by cenę można
było zmieniać w trakcie godzin pracy i by jej efekty były
natychmiastowe (obejmowały także właśnie kupujących). Jeden wyjątek
jaki miałem, wiosny nie czyni.
Zwróć uwagę, Jacku, że kiedy developer robi sklep, to jego klient
(właściciel sklepu) wyznacza wymagania i powinnością developera jest
zapewnić realizację celów biznesowych właściciela sklepu, a nie
kupującego. Stąd, np. sklepy które znajdują się wysoko w
wyszukiwarkach cen (ceneo, pricegrabber etc.) mają inne ceny, gdy się
wchodzi ze strony wyszukiwarki, a inne gdy z innej strony sklepu (bo
żeby zdobyć klienta trzeba być wysoko w wynikach, a jak już klient
kupuje jedną rzecz, to kupuję często więcej nie porównując cen). A to
bardzo mały przykład funkcjonalności, które pewnie by Ci się nie
spodobała.
Z tego też powodu, w wielu miejscach pojawia się napis "Zawartość
strony WWW pełni rolę informacji handlowej. Nie jest ofertą w
rozumieniu kodeksu prawa cywilnego.". I dobranoc.
Ale to i tak drobnostka w porównaniu do wałków, które odstawiają
sklepy nie-internetowe. Znajdź mi jeden, gdzie wszystkie produkty
posiadają ceny w pobliżu tychże. O niespodziankach w fizycznej kasie,
nawet nie będę wspominał (pani Jadzia nie zmieniła cen? łojezu).
>> Produkt to raczej nie jest value object :)
>
> Myślisz o OO w Javie i Scali. A jak byłoby to w językach funkcyjnych?
Jacku, o to przecież jest cała sprawa i czekamy z niecierpliwością aż
nam na to pytanie odpowiesz, dzięki zdobytej w clojure wiedzy.
> Mam wrażenie, że patrzysz na problemy przez pryzmat narzędzia, którym
> dysponujesz, a nie odwrotnie
Patrzenie na narzędzia przez pryzmat problemów którymi dysponuję?
Stosuję, stosuję :)
Natomiast jeśli chodziło Ci o "Patrzenie na problemy przez pryzmat
narzędzi którymi NIE dysponuję", to... patrzenie na cokolwiek przez
cokolwiek, czym akurat nie dysponuję, jest raczej generalnie trudnie
:)
--
Jakub Nabrdalik
http://blog.solidcraft.eu
Irek Matysiewicz
Zwróć uwagę, Jacku, że kiedy developer robi sklep, to jego klient
(właściciel sklepu) wyznacza wymagania i powinnością developera jest
zapewnić realizację celów biznesowych właściciela sklepu, a nie
kupującego.
Stąd, np. sklepy które znajdują się wysoko w
wyszukiwarkach cen (ceneo, pricegrabber etc.) mają inne ceny, gdy się
wchodzi ze strony wyszukiwarki, a inne gdy z innej strony sklepu (bo
żeby zdobyć klienta trzeba być wysoko w wynikach,
Teraz jak wygooglujesz nazwę produktu który chcesz kupić trafiasz bezpośrednio na stronę sklepu, a nie na Ceneo jak jeszcze było kilka dni temu.
Jakub Nabrdalik
<iir...@gmail.com> napisał:
>
>> Zwróć uwagę, Jacku, że kiedy developer robi sklep, to jego klient
>> (właściciel sklepu) wyznacza wymagania i powinnością developera jest
>> zapewnić realizację celów biznesowych właściciela sklepu, a nie
>> kupującego.
>
> I to chyba błąd, w końcu właściciel sklepu zarabia na klientach, więc sklep
> internetowy powinien jak najbardziej "dogadzać" klientom a dopiero na drugim
> miejscu właścicielowi sklepu.
Zupełnie się nie zgodzę. Popatrz na Amazon - najgorszy pod względem
usability sklep w historii ludzkości.
Gdyby robienie klientowi dobrze się opłacało, twój samochód nie miałby
najwrażliwszych części umiejscowionych dokładnie w miejscu
najczęstrzych stłuczek oraz sprzedawano by psujące się części
oddzielnie, a nie w paczkach wraz z super-drogimi częściami, które nie
są zwykle potrzebne.
Nie znam się na handlu ponad to co było mi potrzebne przy tworzeniu
software'u i prowadzeniu analizy, ale wygląda mi na to, że bardziej
się opłaca żeby klient jęczał z przyjemności, podczas gdy
sklep/producent go "rucha na kasę".
Apple/Sony anybody? [1]
>> Stąd, np. sklepy które znajdują się wysoko w
>> wyszukiwarkach cen (ceneo, pricegrabber etc.) mają inne ceny, gdy się
>> wchodzi ze strony wyszukiwarki, a inne gdy z innej strony sklepu (bo
>> żeby zdobyć klienta trzeba być wysoko w wynikach,
>
> Na szczęście Ceneo i tym podobne serwisy w tym tygodniu wyleciały z
> wysokiego rankingu Google:
> http://antyweb.pl/google-wycielo-z-wynikow-wyszukiwania-najwieksze-polskie-porownywarki-cen-ceneo-nokaut-i-skapca/
> Teraz jak wygooglujesz nazwę produktu który chcesz kupić trafiasz
> bezpośrednio na stronę sklepu, a nie na Ceneo jak jeszcze było kilka dni
> temu.
W Polsce. W stanach, google ma swoją własną wyszukiwarkę cen, która
działa (surprise, surprise), tak samo :)
[1] piszący nie chce wywoływać fanboy'ów z lasu, nie piszę się na
ustawkę i jest szczęśliwym posiadaczem ps3 + Dark Souls, gdzie jęczy z
przyjemności, podczas gdy producent po raz tysięczny morduje go pod
koniec planszy, tuż przed walką z bossem, oraz jedynie przez czyste
skąpstwo nie kupi sobie ipada z Civilization Revolution.
Irek Matysiewicz
Zupełnie się nie zgodzę. Popatrz na Amazon - najgorszy pod względem
usability sklep w historii ludzkości.
Mi usability Amazonu się podoba. Pewnie kwestia gustu i przyzwyczajeń.
Gdyby robienie klientowi dobrze się opłacało, twój samochód nie miałby
najwrażliwszych części umiejscowionych dokładnie w miejscu
najczęstrzych stłuczek oraz sprzedawano by psujące się części
oddzielnie, a nie w paczkach wraz z super-drogimi częściami, które nie
są zwykle potrzebne.
No pewnie że firmy doją klientów jak potrafią bo w końcu są po to by zarabiać. A ty byś nie doił? Jeśli klient nie znajdzie tańszej alternatywy, albo nie zechce mu się szukać to przeboli cenę i kupi.
Ale mamy wolny rynek: zawsze może się pojawić firma która będzie produkowała te często psujące się części w osobnych paczkach. A jeśli takiej firmy jeszcze nie ma i jest to rzeczywiście problem wielu ludzi, może właśnie odkryłeś niszę rynkową - załóż fabrykę części. :-)
Jakub Nabrdalik
> Gdyby robienie klientowi dobrze się opłacało, twój samochód nie miałby
> najwrażliwszych części umiejscowionych dokładnie w miejscu
> najczęstrzych stłuczek oraz sprzedawano by psujące się części
> oddzielnie, a nie w paczkach wraz z super-drogimi częściami, które nie
> są zwykle potrzebne.
>
>
> No pewnie że firmy doją klientów jak potrafią bo w końcu są po to by
> zarabiać. A ty byś nie doił? Jeśli klient nie znajdzie tańszej
> alternatywy, albo nie zechce mu się szukać to przeboli cenę i kupi.
> Ale mamy wolny rynek: zawsze może się pojawić firma która będzie
> produkowała te często psujące się części w osobnych paczkach. A jeśli
> takiej firmy jeszcze nie ma i jest to rzeczywiście problem wielu ludzi,
> może właśnie odkryłeś niszę rynkową - załóż fabrykę części. :-)
Producentów "zamienników" jest wielu. Osobiście czekam na:
http://www.theoscarproject.org/
The power of Open Source :D
--
Jakub Nabrdalik
blog.solidcraft.eu
Tomek Banach
>
> Zwróć uwagę, Jacku, że kiedy developer robi sklep, to jego klient
> (właściciel sklepu) wyznacza wymagania i powinnością developera jest
> zapewnić realizację celów biznesowych właściciela sklepu, a nie
> kupującego.
>
> I to chyba błąd, w końcu właściciel sklepu zarabia na klientach, więc
> sklep internetowy powinien jak najbardziej "dogadzać" klientom a dopiero
> na drugim miejscu właścicielowi sklepu.
Pff typowe klienckie roszczeniowe podejscie ;) Sklep internetowy ma
przynosić dochód dogadzanie tylko jeżeli mieści się to w strategii
właściela - patrz Alma Biedronka.
--
Tomek
Bartek Kuczyński
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~
\_/
|||
--
Tomek
Jacek Laskowski
> Jacku, bardzo to słuszne.
>
> A teraz wracamy na ziemię.
Muszę się nauczyć akceptować ten sposób dyskusji i *tylko* dlatego, że
Ty jesteś autorem.
Kiedykolwiek słyszę tego typu początek rozmowy, od razu zapala mi się
czerwona lampka z napisem "Chyba mnie ktoś tutaj poważnie nie
traktuje". Być może to tylko ja, ale mam wrażenie, że rozpoczynanie
dyskusji od imienia, to jak klepanie po ramieniu i mówienie "Tak, tak,
będzie dobrze", albo "Tak, tak, gadaj sobie dalej, a i tak wiemy
swoje".
Źle to odczytuję i jeszcze w dodatku obrażam Cię, że tak myślę?
Powiedz, że się mylę (teraz, albo wcześniej).
> Na ziemi, developerzy robią software
> spełniający wymagania klienta. Z tych kilku sklepów które zrobiłem, w
> prawie wszystkich (w przeciwieństwie do systemów
> magazynowo-sprzedażowych/ERP, które robiłem), klient życzył sobie by
> towar nie był rezerwowany przy wkładaniu do koszyka i by cenę można
> było zmieniać w trakcie godzin pracy i by jej efekty były
> natychmiastowe (obejmowały także właśnie kupujących). Jeden wyjątek
> jaki miałem, wiosny nie czyni.
A teraz moje podejście do sprawy (podejście bardziej teoretyczne niż
praktyczne):
Klient: Chcę mieć możliwość aktualizacji ceny w trakcie transakcji
(przez transakcję rozumiemy ciąg następujących po sobie czynności - od
wzięcia towaru z półki do podejścia do kasy)
Ja: Dobrze. Czy w trakcie wykonywania poszczególnych kroków powinienem
informować świat zewnętrzny o potencjalnym zapotrzebowaniu na towar
(wysyłanie komunikatów)? (wersja dla nas, technicznych: czy są jeszcze
nietransakcyjne operacje, których wycofanie nie będzie możliwe
korzystając z monitora transakcji? - tutaj transakcja ma znaczenie
techniczne)
Klient: Nie
W tym momencie nie zakładam jeszcze, że będzie to Java, która da mi
setPrice(...), albo Clojure, który zrobi to inaczej, np. {:cena ...}
(to miałem na myśli pisząc o patrzeniu na problemy przez pryzmat
dostępnych narzędzi - będąc bardziej dosłowny - olewam narzędzia na tę
chwilę). Koncentruję się na wymaganiach.
I dalej rozmowa...staram się być upierdliwy^H^H^Hdociekliwy.
Ja: Co w sytuacji, kiedy podchodząc do kasy klient widzi różnicę
między ceną na/przy towarze, a kasową/systemową? Chyba daje mu to
prawo do pozwania Was?
Klient: ???
Załóźmy, że klient mówi, że olewa to, co klient sobie myśli, albo, że
w większości przypadków nie ma to znaczenia, bo będziemy się martwić
na miejscu.
Wtedy ja, mając tę informację, przy wystąpieniu takiej sytuacji
obsługuję to jako sytuację wyjątkową (nie piszę o wyjątkach w Javie) i
w razie zgłoszenia uwagi przez klienta...już w kodzie...podmieniam
jego towar na nowy z nową ceną (tzn. jest to stary produkt z nową
ceną).
Sytuacja podobna jest do sytuacji, w której wszyscy wiedzą jaka jest
wartość cyfry 8, ale akceptują jej zmianę, bo...cóż takie są realia
aka wymagania klienta. Cóż, ponownie, akceptuję to i jak to
obsłużyłbym w Clojure:
(def basket (list)) ; koszyk jest pusty
;; towar
(def milk {:name :milk :price 10})
;; klient bierze towar z półki
(def basket (conj basket milk))
;; załóżmy, że teraz cena towaru się zmienia
(def milk {:name :milk :price 50})
;; klient ma wciąż starą wersję, bo struktury są niezmienne, stałe
;; My wiemy i chcemy, aby zmiana ceny musiała pociągać za sobą zmianę w systemie
;; najlepszą opcją, jest odłączenie ceny od towaru i wybranie jej z
kasy (odłączamy atrybut cena od fizycznego towaru)
;; nasze rozumowanie wyżej jest niepoprawne
;; jeszcze raz
;; czyścimy koszyk
(def basket '())
;; zależy nam na strukturze, która ma kontrolowany dostęp
(współbieżnie), ale odczyt ma być nieblokujący
;; Clojure STM przychodzi z pomocą, w końcu to malutka biblioteka do
programowania współbieżnego
;; mamy do dyspozycji ref, atom i agent - http://clojure.org/atoms
(def milk-price (atom 10))
;; towar poprawniej
(def milk {:name :milk :price milk-price})
;; jaka jest teraz cena mleka w kasie?
@milk-price
;; a ta na etykiecie, na półce?
@(:price milk)
;; są równe
(= @milk-price @(:price milk))
;; wkładamy mleko do koszyka
(def basket (conj basket milk))
;; sprawdźmy cenę mleka w koszyku (idziemy do czytnika)
;; tutaj wychodzi, że możnaby pomyśleć o koszyku-mapie - identyfikator
produktu i ich lista
;; wybaczcie niedbałość
(map deref (map :price (filter #(= (:name % :milk)) basket)))
;; w naszym przypadku możnaby krócej - duuuuże "skrzywienie" tematu
(def milk-price-in-basket (:price (first basket)))
;; są równe
(= @milk-price @milk-price-in-basket)
;; ZMIANA CENY w kasach
;; o jeden w górę (inc - to +1)
(swap! milk-price inc)
;; od tej pory wszystkie wątki aka klienci oraz kasy widzą to samo
;; to jest przykład uproszczenia współbieżności i cecha Clojure
;; sprawdźmy
@milk-price-in-basket
;; jeszcze podbijamy cenę
(swap! milk-price inc)
;; i jeszcze raz sprawdzmy
@milk-price-in-basket
;; koniec - Ctrl-C
Podsumowanie: All problems in computer science can be solved by
another level of indirection [1]
[1] http://en.wikipedia.org/wiki/Abstraction_layer
Czekam na uwagi. Chciałbym tym samym podziękować wszystkim
zaangażowanym w dyskusję za przedstawienie bardzo ciekawego problemu
do rozwiązania, który zamierzam wykorzystać w moich prezentacjach
programowania funkcyjnego z Clojure. Jak się uda pierwsze będzie
podczas SFI w Krakowie 8-10.03.2012, ale spóźnionym był znacznie z
rejestracją tematu, więc może być ciężko. Ale ciii, nie zapeszajmy :)
Jacek Laskowski
> Też nie tak. Rolą programisty jest zwrócenie uwagi na potencjalne błędy w
> logice biznesowej. Jeżeli jakiś "genialny" pomysł właściciela sklepu jest po
> prostu idiotyczny to warto zwrócić mu uwagę. W przeciwnym wypadku jak sprawa
> się rypnie to winnym będzie informatyk "bo źle zaprogramował", "bo źle
> zrozumiał", "bo to informatyk".
Nieznacznie zmienioną wersję tego poglądu starałem się właśnie zawrzeć
w mojej clojure'owej odpowiedzi. Dzięki Bartek, że podzieliłeś się
swoim zdaniem i pozwoliłeś mi sądzić, że nie jest tak całkiem ze mną
źle (mimo powszechnego przekonania o moim niewielkim doświadczeniu
projektowym w *prawdziwych* i *życiowych* projektach :)).
Jakub Nabrdalik
> 2012/2/3 Jakub Nabrdalik<jak...@gmail.com>:
>
>> Jacku, bardzo to słuszne.
>>
>> A teraz wracamy na ziemię.
>
> Muszę się nauczyć akceptować ten sposób dyskusji i *tylko* dlatego, że
> Ty jesteś autorem.
>
> Kiedykolwiek słyszę tego typu początek rozmowy, od razu zapala mi się
> czerwona lampka z napisem "Chyba mnie ktoś tutaj poważnie nie
> traktuje". Być może to tylko ja, ale mam wrażenie, że rozpoczynanie
> dyskusji od imienia, to jak klepanie po ramieniu i mówienie "Tak, tak,
> będzie dobrze", albo "Tak, tak, gadaj sobie dalej, a i tak wiemy
> swoje".
>
> Źle to odczytuję i jeszcze w dodatku obrażam Cię, że tak myślę?
> Powiedz, że się mylę (teraz, albo wcześniej).
Jezusmaria, Jacku, trochę dystansu do siebie. Jak będę chciał Cię
obrazić, zacznę emaila od Łaciny (a raczej przyjdę osobiście i dam Ci w
mordę, co będę spam rozsyłał). Do tego momentu moje stanowisko brzmi:
lubię Cię i nie chcę Cię obrazić. :) Już Ci to przecież pisałem.
"Wracamy na ziemię", bo mam przykłady wymagań, które uznałeś za błędne
i/lub nierzeczywiste.
Poza tym, obrazić? My nie za starzy jesteśmy?
> A teraz moje podejście do sprawy (podejście bardziej teoretyczne niż
> praktyczne):
> [...]
> Załóźmy, że klient mówi, że olewa to, co klient sobie myśli, albo, że
> w większości przypadków nie ma to znaczenia, bo będziemy się martwić
> na miejscu.
>
> Wtedy ja, mając tę informację, przy wystąpieniu takiej sytuacji
> obsługuję to jako sytuację wyjątkową (nie piszę o wyjątkach w Javie) i
> w razie zgłoszenia uwagi przez klienta...już w kodzie...podmieniam
> jego towar na nowy z nową ceną (tzn. jest to stary produkt z nową
> ceną)
I to jest odpowiedź. Czyli różnica z java/groovy/c#/php/inny język OO w
praktyce jest formalna, bo produkt i tak w sesji/bazie był pewnie
trzymany przez identyfikator. Ilość boilerplate'u to inna sprawa.
Dzięki.
--
Jakub Nabrdalik
blog.solidcraft.eu
Irek Matysiewicz
Podsumowanie: All problems in computer science can be solved by
another level of indirection [1]
No ale przy kasie zapłacę większą cenę niż miałem wkładając do koszyka. Ja bym raczej chciał zobaczyć przynajmniej komunikat w stylu "Cena produktu 'Mleko' zmieniła się od momentu włożenia go do koszyka i teraz wynosi XX zł. Czy kontynuować transakcję?' - czyli coś a'la optimistic locking.
Ludzie, jak tak kiepsko działają sklepy internetowe to ja się zaczynam bać robić zakupy w internecie. :-)
Ale nie o to mi się rozchodzi. Jest też linijka:
- (swap! milk-price inc)
rozumiem to jako coś z grubsza podobnego do Javowego: ++milkPrice. Ale tu masz side effect, a mi chodziło o kod w "czystym" stylu funkcyjnym, czyli bez side effectów, który by wyglądał tak prosto jak ++milkPrice a nie jak naciąganie gaci przez głowę (goto mój kawałek kodu parę postów temu).
Jacek Laskowski
> No ale przy kasie zapłacę większą cenę niż miałem wkładając do koszyka. Ja
> bym raczej chciał zobaczyć przynajmniej komunikat w stylu "Cena produktu
> 'Mleko' zmieniła się od momentu włożenia go do koszyka i teraz wynosi XX zł.
> Czy kontynuować transakcję?' - czyli coś a'la optimistic locking.
A to wtedy zamieniłbym koszyk na zawierający wartość, a przy kasie
porównałbym i voila. Tutaj zastosowałbym funkcję map, która iteruje po
liście i aplikuje funkcję do każdego elementu oraz filter, aby
wyfiltrować produkty zmienione, np.
(map funkcja-informujaca-uzytkownika-o-zmianie
(filter funkcja-zwracajaca-produkty-ze-zmieniajacymi-cenami koszyk))
> Ludzie, jak tak kiepsko działają sklepy internetowe to ja się zaczynam bać
> robić zakupy w internecie. :-)
Cóż zrobić. Robią nas Ci informatycy na każdym kroku, a my za drodzy,
aby nas zatrudnić :)
> Ale nie o to mi się rozchodzi. Jest też linijka:
> - (swap! milk-price inc)
> rozumiem to jako coś z grubsza podobnego do Javowego: ++milkPrice. Ale tu
> masz side effect, a mi chodziło o kod w "czystym" stylu funkcyjnym, czyli
> bez side effectów, który by wyglądał tak prosto jak ++milkPrice a nie jak
> naciąganie gaci przez głowę (goto mój kawałek kodu parę postów temu).
Dobra uwaga! Poważnie. Clojure nie jest językiem czystofunkcyjnym. To
nie Haskell, a język, który został stworzony, aby programiście było
dobrze i niedobrze jednocześnie :) Dobrze, bo ma realizować faktyczne
aplikacje, w których stan jest czymś oczywistym, a niedobrze, bo wielu
nie może znieść liczby nawiasów (która nota bene jest często mniejsza
niż w odpowiednim kawałku kodu w Javie!)
Stąd też w Clojure pozwala się na "nieczyste" zagrania, tj. skutki
uboczne, ale jedynie w kontrolowany sposób. W naszym przypadku użyłem
struktury, która pozwala na wielodostęp bez blokowania odczytu. Bardzo
fajna abstrakcja, która aplikuje szereg funkcji wysłanych do
"przyłożenia" do aktualnej wartości. Funkcje modyfikujące muszą być
pozbawione skutków ubocznych, bo w razie niemożności zmiany wartości,
Clojure STM próbuje ponownie (ma to swoje konsekwencje w systemach, w
których zmiany są częste, a kolizje nieuniknione, ale nie u nas).
Gdybyś chciał to zrobić czysto funkcyjnie pewnie byłby to ciąg wywołań
funkcji z monadami, gdzie się już nie da. To jednak dla mnie zbyt
wysoko postawiona poprzeczka i nie jestem w stanie ogarnąć tego na ten
moment mentalnie. Jeszcze niektóre monady jak najbardziej, ale
myślenie bez skutków ubocznych jest obecnie nie do zaakceptowania
przeze mnie. To wymagałoby ode mnie większej miłości do Haskella
pewnie :)
Twój komentarz mówi mi, że jesteś zaskoczony rozwiązaniem i nie jest
to specjalnie pozytywne i negatywne zaskoczenie jednocześnie.
Pierwsze, pozytywne, bo się da i jest to zrozumiałe stosunkowo i nawet
da się to z czymś porównać, a drugie, negatywne, że są skutki uboczne.
Cóż tego drugiego na razie nie zamienię w pozytyw. Nie dzisiaj i
pewnie nie w tym kwartale, albo nawet roku. Jeśli zabiorę się za
zgłębianie kolejnego języka, to będzie to pewnie F#.
Jacek Laskowski
> I to jest odpowiedź. Czyli różnica z java/groovy/c#/php/inny język OO w
> praktyce jest formalna, bo produkt i tak w sesji/bazie był pewnie trzymany
> przez identyfikator. Ilość boilerplate'u to inna sprawa.
Pełna zgoda.
Co warto jednak podkreślić, że owa ilość kodu faktycznie potrzebna do
rozwiązania problemu jest zwykle mniejsza w językach LISPopodobnych
(wliczając Clojure), bo i składnia jest uboższa - same listy, a
semantycznie wciąż równo bogate. Ciekawym Twojej opinii i wielu tzw.
OOPiarzy, kiedy po dostrzeżeniu możliwości Clojure, skromność
aplikacji napisanych w nim będzie mocno przyciągać, ale zmiana składni
mocno odrzucała (możnaby powiedzieć, że tak nie może być, aby
jednocześnie przyciągało i odpychało, ale sądzę, że tak właśnie jest
przy Clojure, że zespoły javowe nie wchodzą w konstrukcje funkcyjne na
JVM, wliczając Clojure).
Jest takie twierdzenie Churcha kogoś tam, które mówi, że problemy do
obsłużenia przez języki funkcyjne i imperatywne (obiektowe,
proceduralne) są takie same, bo to *chyba* ma związek z problemami
rozstrzygalnymi w ramach modelu maszyny Turinga. I tutaj pamięć o tych
pojęciach się kończy (a chciałoby się inaczej) i raczej już skończę,
aby się nie ośmieszyć...jeszcze bardziej. Właśnie teraz mógłbym
rozpocząć studia :)
Adam Warski
> Jest takie twierdzenie Churcha kogoś tam, które mówi, że problemy do
> obsłużenia przez języki funkcyjne i imperatywne (obiektowe,
> proceduralne) są takie same, bo to *chyba* ma związek z problemami
> rozstrzygalnymi w ramach modelu maszyny Turinga.
To chyba po prostu chodzi o to że język jest turing-complete (http://en.wikipedia.org/wiki/Turing_completeness), czyli że w sumie w każdym języku można napisać to samo ;).
A jeżeli chodzi o tłumaczenie programów imperatywnych na funkcyjne, to zdaje się da się to zawsze zrobić z narzutem czasowym *logn. Zmienne reprezentujemy jako mapę, mapę przechowujemy jako zrównoważone drzewo, a czas jednej operacji na takim drzewie to właśnie logn. Ale nie wiem czy to jest jakieś na to formalne twierdzenie.
Adam
--
Adam Warski
http://twitter.com/#!/adamwarski
http://www.softwaremill.com
http://www.warski.org
Jacek Laskowski
> A jeżeli chodzi o tłumaczenie programów imperatywnych na funkcyjne, to zdaje się da się to zawsze zrobić z narzutem czasowym *logn. Zmienne reprezentujemy jako mapę, mapę przechowujemy jako zrównoważone drzewo, a czas jednej operacji na takim drzewie to właśnie logn. Ale nie wiem czy to jest jakieś na to formalne twierdzenie.
Zakładam, że logn to wysokość drzewa binarnego, a w Clojure podstawa
logarytmu to 32, co baaardzo wypłyca struktury (drzewa, które je
reprezentują) i dlatego nie potrzeba się specjalnie martwić o
tworzenie i porzucanie struktur, które są niezmienne. Zwykle jest to
niemałe zmartwienie dla osób widzących ciągłe porzucanie całych
struktur na rzecz tworzenia nowych, w których jedyna zmiana to dodanie
elementu (choćby niewielkiego rozmiarem).
Przypomniałeś mi tym moje niemałe zdumienie, kiedy logn na MIMUWie
oznaczało logarytm o podstawie 2, w przeciwieństwie do MAT@UMK, na
którym zarezerwowane było to dla podstawy 10, którą zapisywano lgn (!)
Adam Warski
Tymniemniej, różnica w wydajności między zwiększeniem komórki amięci o 1 a stworzeniem paru nowych obiektów (które aż takie małe nie są) na pewno jest.
Adam
> --
> 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
--
Irek Matysiewicz
Gdybyś chciał to zrobić czysto funkcyjnie pewnie byłby to ciąg wywołań
funkcji z monadami, gdzie się już nie da. To jednak dla mnie zbyt
wysoko postawiona poprzeczka i nie jestem w stanie ogarnąć tego na ten
moment mentalnie. Jeszcze niektóre monady jak najbardziej, ale
myślenie bez skutków ubocznych jest obecnie nie do zaakceptowania
przeze mnie. To wymagałoby ode mnie większej miłości do Haskella
pewnie :)
No z monadami albo z przebudowywaniem całej struktury danych - tu i tu naciąganie gaci przez głowę. Co z tego że w matematycznym sensie oba style programowania są równoważne.
Myślałem że ktoś z Was wymyśli jakieś supergenialne soluszyn a tu nic - wygląda na to że wiele rzeczy po prostu trzeba robić nieczysto a 100%-czysty styl proponowany przez Haskella można między bajki włożyć. Pewne rzeczy lepiej zrobić funkcyjnie (np. matematyka, operowanie na kolekcjach a'la LINQ z C#), a pewne imperatywnie (np. to nieszczęsne setCośtam czy ++cośtam).
Adam Warski
> No z monadami albo z przebudowywaniem całej struktury danych - tu i tu naciąganie gaci przez głowę. Co z tego że w matematycznym sensie oba style programowania są równoważne.
> Myślałem że ktoś z Was wymyśli jakieś supergenialne soluszyn a tu nic - wygląda na to że wiele rzeczy po prostu trzeba robić nieczysto a 100%-czysty styl proponowany przez Haskella można między bajki włożyć. Pewne rzeczy lepiej zrobić funkcyjnie (np. matematyka, operowanie na kolekcjach a'la LINQ z C#), a pewne imperatywnie (np. to nieszczęsne setCośtam czy ++cośtam).
To chyba wiadomo, nawet Prolog ma zdaje się jakieś zastosowania, ale przecież nikt w nim nie będzie sklepu internetowego pisał ;)
Irek Matysiewicz
To chyba po prostu chodzi o to że język jest turing-complete (http://en.wikipedia.org/wiki/Turing_completeness), czyli że w sumie w każdym języku można napisać to samo ;).
> Jest takie twierdzenie Churcha kogoś tam, które mówi, że problemy do
> obsłużenia przez języki funkcyjne i imperatywne (obiektowe,
> proceduralne) są takie same, bo to *chyba* ma związek z problemami
> rozstrzygalnymi w ramach modelu maszyny Turinga.
A jeżeli chodzi o tłumaczenie programów imperatywnych na funkcyjne, to zdaje się da się to zawsze zrobić z narzutem czasowym *logn. Zmienne reprezentujemy jako mapę, mapę przechowujemy jako zrównoważone drzewo, a czas jednej operacji na takim drzewie to właśnie logn. Ale nie wiem czy to jest jakieś na to formalne twierdzenie.
Nawet nie musi to być log(n). Istnieje połączenie drzewa trie i hashmapy dające w efekcie mapę immutable o złożoności praktycznie stałej: http://en.wikipedia.org/wiki/Hash_array_mapped_trie
Ale tu nie tyle o złożoność się rozchodzi co o naciąganie gaci przez głowę.
Irek Matysiewicz
To chyba wiadomo, nawet Prolog ma zdaje się jakieś zastosowania, ale przecież nikt w nim nie będzie sklepu internetowego pisał ;)
> No z monadami albo z przebudowywaniem całej struktury danych - tu i tu naciąganie gaci przez głowę. Co z tego że w matematycznym sensie oba style programowania są równoważne.
> Myślałem że ktoś z Was wymyśli jakieś supergenialne soluszyn a tu nic - wygląda na to że wiele rzeczy po prostu trzeba robić nieczysto a 100%-czysty styl proponowany przez Haskella można między bajki włożyć. Pewne rzeczy lepiej zrobić funkcyjnie (np. matematyka, operowanie na kolekcjach a'la LINQ z C#), a pewne imperatywnie (np. to nieszczęsne setCośtam czy ++cośtam).
No tak, ale "It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove."
Fajnie by było powiedzieć "języki XXXX są be i nie warto się nimi zajmować. Niestety tak się chyba nie da...
Jakub Nabrdalik
<iir...@gmail.com> napisał:
>
Khem... Visual Basic? FoxPro?
Tomasz Szymański
Bartek Kuczyński
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~
\_/
|||
Jacek Laskowski
> No z monadami albo z przebudowywaniem całej struktury danych - tu i tu
> naciąganie gaci przez głowę.
Cieszę się, że nie odpuszczasz/-cie, bo wciąż myślę o bardziej
funkcyjnym podejściu, takim zbliżonym do czysto funkcyjnego i mam
wrażenie, że jestem blisko.
Niech za przykład posłuży taki oto tok rozumowania.
Czym jest stan, który jest modyfikowany przez nasze aplikacje? To nic
innego jak mapa (ostatnio podoba mi się określenie tablica
asocjacyjna, które mam wrażenie, że bardzo popularne jest w
środowiskach spod znaku Microsoft).
Co należy zrobić, aby zmienić stan aplikacji zakładając, że to nic
więcej jak struktura typu mapa? Wystarczy po prostu przekazywać ją z
funkcji do funkcji. W końcu jeśli założyć, że funkcja to odwzorowanie
argumentu na wartość (definicja matematyczna), to nasze programowanie
(bez względu na język) to również właśnie zaaplikowanie funkcji. Tutaj
jednak wchodzą na scenę skutki uboczne, ale zakładając, że idziemy do
języków czysto funkcyjnych to w nich tego nie ma.
Aplikacji jeszcze nie mam, ale czuję, że jestem blisko pewnej
propozycji. Muszę ją jeszcze przemyśleć.
A przy okazji, zdefiniuj pojęcie "naciąganie gaci przez głowę".
Jacek Laskowski
> To chyba wiadomo, nawet Prolog ma zdaje się jakieś zastosowania, ale przecież nikt w nim nie będzie sklepu internetowego pisał ;)
Pytanie, które się tutaj nasuwa to, czy wynika to z niedostatecznego
wykształcenia w Prologu, czy istnieje klasa problemów, w których pewne
cechy determinują języki innego typu?
Paweł Cesar Sanjuan Szklarz
Pracowalem z reasoserem wsmo w javie, ktory pod spodem generowal i
uruchamial reguly w prologu zeby ostatecznie realizowac wnioskowanie.
Chyba nie jest tak, ze jestesmy wskazany na jeden jezyk programowania
z zadanym podejsciem programowania.
Referencje:
http://www.wsmo.org/TR/d22/v0.2/
"Run-time Component
The run-time component has the role to retrieve from the storage the
already created mappings, to transform them in rules and finally to
execute them against the incoming instances in order to obtain the
target instances. Since the mappings represents the connection point
between the two sub-components (design-time and run-time) one of the
dependencies for run-time component is on the mapping storage level as
well. Another crucial dependency is the reasoning system used for
executing the rules in the final stage of the mediation process. For
this, Flora2 engine together with its underlying system, XSB Prolog,
are used; they are integrated in Java by using InterProlog, a Java
front-end and enhancement for XSB Prolog. The installation of this
system is completely handled by a set of scripts coming with the
mediation component, without any burdensome from the user side."
Pawel.
2012/2/5 Jacek Laskowski <ja...@japila.pl>:
Irek Matysiewicz
Co należy zrobić, aby zmienić stan aplikacji zakładając, że to nic
więcej jak struktura typu mapa? Wystarczy po prostu przekazywać ją z
funkcji do funkcji. W końcu jeśli założyć, że funkcja to odwzorowanie
argumentu na wartość (definicja matematyczna), to nasze programowanie
(bez względu na język) to również właśnie zaaplikowanie funkcji. Tutaj
jednak wchodzą na scenę skutki uboczne, ale zakładając, że idziemy do
języków czysto funkcyjnych to w nich tego nie ma.
Obiekty możemy rozumieć jako haszmapy (zresztą np. tylko tak da się w JavaScripcie) - nic to nie zmienia, po setCośtam i tym podobnych operacjach trzeba przebudować całą strukturę danych - goto mój wcześniejszy przykład.
To by działało tylko wtedy gdybyśmy nie dopuszczali zagnieżdżeń w mapie, wtedy implementacja takiej haszmapy sama zadbałaby o poprawne przekopiowanie wszystkiego po zmianie mapy. Ale wtedy ilość sztuk pierwszego produktu byłaby dostępna jako mapa["koszyk.produkty[0].ilość"] - znowu naciąganie gaci przez głowę, i do tego problemy wydajnościowe bo obiekty byłyby porozrzucane po całej pamięci i keszowanie procesora by pewnie nie działało dobrze.
A przy okazji, zdefiniuj pojęcie "naciąganie gaci przez głowę".