Spotkanie Poznań JUG: Grizzly [23.11.2010]

[adudczak]

Cześć,

Zapraszamy wszystkich na kolejne spotkanie Poznań JUG, które odbędzie
się we wtorek (23.11.2010) o godzinie 18:00 w siedzibie Cognifide (al.
Wielkopolska 4). Mikołaj Grajek poprowadzi prezentacje dotyczącą
biblioteki "Grizzly". Osoby które chcą uczestniczyć w spotkaniu
powinny się zarejestrować za pomocą tego formularza [1].

A oto streszczenie nadeslane przez Mikołaja:
"Jeśli kiedyś zastanawiałeś się czy jest sens pisać protokoły
komunikacje za pomocą własnego protokołu binarnego, i jak odbija się
to na wydajności... lub podejrzewasz, że spotka cię przyjemność pisania
komunikacji sieciowej w NIO: być może to krótkie porównanie pomoże Ci
podjąć w przyszłości właściwą decyzje (lub przynajmniej wskaże gdzie
jej szukać)."

Mikołaj Grajek - absolwent kierunku Informatyka na Politechnice
Poznańskiej. Jeden z załozycieli firmy City-Nav odpowiedzialnej za
rozwój serwisu jakdojade.pl. Autor ma przyjemność pracować z
frameworkiem Grizzly. Ponieważ znalezienie porządnej dokumentacji i
dobrze objaśnionych przykładów graniczy z cudem (podobnie jak ponoć
uzyskanie odpowiedzi na pytanie zadane na forum jego twórcom) - w
przypływie optymizmu postanowił podzielić się swoimi szczęśliwymi
doświadczeniami.

[1] http://oiola.com/e/659-spotkanie-poznan-jug-grizzly-23112010/reg/

pozdr. Adam

[adudczak]

Cześć,

I jak Wasze wrażenia? Ja musze powiedzieć, że bardzo mi sie podobała
zarówno sama prezentacja jak i piwko po ;-) Mikołaj urzekł mnie
szczerością i poczuciem humoru ("spanikowany miś" po prostu rozłożył
mnie na łopatki). Raz jeszcze dzięki.

Myślę, że pytanie które Mikołaj zadał publiczności po prezentacji
warte jest przeniesienia na listę. Nawet nie wiem czy ktoś porównywał
narzut wydajnościowy związany z EJB w porównaniu z niskopoziomiowym
podejściem prezentowanym przez Mikołaja. Napewno było by to ciekawe.
Tak jak mówiłem my używamy RMI, ale to technologia, która ma już
strasznie długą brodę więc też jestem ciekaw jak wy rozwiązujecie
kwestie komunikacji między rozproszonymi komponentami jednego systemu?
Spring Remoting, SOAPy, RESTy? Gołębie pocztowe? ;-)

pozdr. Adamr

[Dawid Weiss]

> zarówno sama prezentacja jak i piwko po ;-) Mikołaj urzekł mnie
> szczerością i poczuciem humoru ("spanikowany miś" po prostu rozłożył

To pewnie dlatego, że Mikołaj jest po TWO, tam są tylko najlepsi :)
Niestety nie mogłem się pojawić; czy prezentacja będzie dostępna w
wersji wideo?

Dawid

[jmilk...@gmail.com]

Witam

Chętnie też bym zobaczył...

pzdr JM

[adudczak]

Cześć,

Jak zwykle mogę tylko obiecać, że zrobie co się da. Mam już film
zrzucony, musze go jeszcze przekodować i gdzieś wrzucić.

pozdr. Adam

[Konrad Malawski]

Helo,

Jako, że ostatnio za każdym razem jak konwertuje filmy zapominam "tej jednej dobrej komendy" oszczędzę Ci (być może) poszukiwań jak to sprawnie w miarę zrobić (tak poleciały ostatnie nagrania javacamp):

mencoder "../INPUT.mp4" -o "OUTPUT.flv" -of lavf -oac mp3lame -lameopts  abr:br=56 -ovc lavc -lavcopts vcodec=flv:vbitrate=800:mbd=2:mv0:trell:v4mv:cbp:last_pred=3 -vf scale=320:240 -force-avi-aspect 16:9 -srate  22050 -ofps 25 -vf harddup

Wynikiem będzie flv'a prawdopodobnie (przy godzinnych nagraniach) mniejsza niż limity np. parleys etc... :-)

Co do hostingu wideo, testowałem ostatnio jak się do tego nadaje vimeo - nadaje się :-) 

Jeszcze jest blip.tv gdzie też coś dłuższego wrzucałem (jest ftp upload - fun).

Powodzenia z konwertowaniem, jak widać wielu czeka... :-)

-- 
Pozdrawiam,
Konrad Malawski

[Adam Dudczak | Poznań JUG]

Cześć,

Dzieki Konrad, moj .bash_history pamieta wszystkie potrzebne zaklecia ;-).

Mencoder chyba i tak pod spodem uzywa ffmpeg'a? Dlaczego wybrales to narzedzie?

pozdr. Adam

> --
> Otrzymujesz tę wiadomość, ponieważ subskrybujesz grupę dyskusyjną Google o
> nazwie "Poznań Java User Group".
>
> Aby zamieszczać posty w tej grupie, wyślij e-mail na adres
> jug-p...@googlegroups.com.
> Aby anulować subskrypcję tej grupy, wyślij e-mail na adres
> jug-poznan+...@googlegroups.com.
> Aby uzyskać więcej informacji, odwiedź tę grupę pod adresem
> http://groups.google.com/group/jug-poznan?hl=pl.
>
>

--
Wysłane z mojego urządzenia przenośnego

[tomi613]

Witam. Możecie wrzucać na http://javatv.pl:8080 , nie chce tu nic promować itp. ale zawsze dla javy miejsce się znajdzie. Jeżeli się zdecydujecie żeby zamieścić nagranie proszę o meil'a , zrobie wam dostęp do serwera. pozdrawiam. 

[d r]

Fajne miejsce. Dzięki za te filmiki - zawsze czegoś nowego człowiek się dowie.

[Witold Szczerba]

W dniu 24 listopada 2010 23:30 użytkownik Konrad Malawski
<kmal...@project13.pl> napisał:

Ostatnio trafiłem na artykuł, gdzie autor polecał program do
konwertowania materiału audio/video - Arista
http://www.transcoder.org/
Wygląda na przyjazny dla użytkownika. Ciekawie wygląda opcja
'presets', gdzie można przygotować parametry formatu, zapisać je i
umieścić na stronie. Działa to oczywiście też w drugą stronę :)

--
Witek

[Mikołaj Grajek]

Witam,

dziękuje za 'dobre słowo':)
Obejrzałem film nagrany na JUG (ze mną w roli głównej) - niestety nie
przeszedł mojej 'cenzury'.
Przyznam się, że prezentując nie przykładałem wagi do tego że mogę
zostać udostępniony szerszemu gronu (np. wyszukiwarce google).
(gdybym na to uważał prezentacja myślę byłaby inna - lub w ogóle by
się nie odbyła ;) )

Ogólnie - wydaje mi się, że nie było w niej dużo 'mięcha', raczej
wyrażanie moich generalnych opinii.
Poniżej załączam streszczenie, które myślę odda to (od strony
merytorycznej) co powiedziałem w ciągu 1h.

Pozdrawiam,
Mikołaj Grajek

-------
1. Po co NIO (część sieciowa):
- wlasne implementacje serwerów (np strumieniowanie filmu 3h+,
upload pliku 2Gb+)
- protokoły binarne (np. zgodność z istniejącymi, 'starymi'
systemami)
- Google Protocols ('międzysystemowy', wieloplatformowy,
elastyczny protokół optymalizowany z myślą o przesyłaniu danych
binarnych - ale nie tylko)
- wiele otwartych równoległych połączeń (rozwiązane przez
ServletApi 3.0)

2. Wady NIO w Javie:
- napisana analogicznie jak w C++ (szybka, 'niskopoziomowa'
implementacja, ale nie-obiektowo i nie-zdarzeniowo)
- dla niedoświadczonego (w NIO, i rzeczach związanych z
komunikacją) programisty to istne pole minowe (musi stworzyć
wielowątkowe, wydajne środowisko + uważać na techniczne aspekty
związane z warstwą obsługi sieci)

3. Grizzly
- to zestaw klas i narzędzi, które prawdopodobnie
'dobry'(doświadczony w takich rozwiązaniach) programista i tak
napisałby sam:
kolejki, potoki przetwarzania (np. przetworzenie requestu HTTP:
obebranie danych -> zebranie odpowiedniej ilości byte'ów potrzebnych
do odczytania ramki -> deflate -> połączenie 'chuncków' -> obsługa
HttpRequest),
pule wątków i kanałów

4. Wady grizzly:
- brak dokumentacji, kod niestety nadal dosyć niskopoziomowy
(trzeba poznać NIO, i jeszcze dodatkowo Grizzly'ego)
- dojrzały projekt, który już się nie rozwija - a programiści
zostali przeniesieni do innych zadań (lub odeszli)
- niewiele upraszcza, ale zapewnia, że nie wyłożymy się na jakimś
'kruczku' (przynajmniej przy tworzeniu wydajnej architektury), w
zamian za to, niestety, wprowadza nowe pułapki - przez braki w
dokumentacji i przykładach

5. Alternatywa: Netty (pod auspicjami JBoss)
- nowe, zunifikowane, obiektowo-zdarzeniowe API(zastąpienie np.
metody flip() z Buffer, własna abstrakcyjna klasa Channel która jest
'nad' java.nio.Channel i java.net.Socket)
- wspaniała dokumentacja (jak książka), przykłady, rysunki i
profesjonalne testy
- gratisowa implementacja Google Protocol Buffers (i wiele innych
narzędzi)

Jeśli ktoś ma zamiar kożystać z NIO (lub nawet pisać komunikację
własnymi protokołami np. za pomocą Socketów) - to jest to chyba
najlepszy wybór (dobrze udokumentowane, czytelne API + wg. testów -co
prawda ich testów- najszybszy framework dostępny na rynku). Ma bardzo
przystępny i porządny tutorial. Dlatego nie omawiałem specjalnie kodu
- bo ta dokumentacja na pewno zrobi to lepiej (kilka h/może jeden
dzień dla niedoświadczonego w tym temacie programisty).

6. Wnioski:
- do standartowej obsługi HTTP lepiej używać sprawdzonych
rozwiązań (np Jetty)
- Netty jest bardzo szybkie, ale nakład pracy chyba nie uzasadnia
wykorzystania (poza szczególnymi przypadkami opisanymi w 1.)
- jeśli ktoś potrzebuje, żeby jego program obsługiwał dziesiątki/
setki tyś. req. na sekundę to prawdopodobnie powinien zastanowić się
nad architekturą
(i np. sprzętowo rozdzielić ruch na wiele maszyn)