Boimy się nieznanego, regularny wypoczynek z pływaniem i silnie typizowane zapytania w JPA2

Najbardziej uwielbiam te momenty, w których na usta ciśnie się "Eureka!". To jest ten moment, w którym wszystko układa się w jedną całość i brak w nim niewyjaśnionych miejsc. Można wtedy wygodnie rozłożyć się w fotelu i powiedzieć sobie "Udało się!" Wtedy wiem, że wysiłek nie poszedł na marne.

Uważam, że jest wiele rzeczy, które ostatecznie składają się na ten moment wzniosłości. Sam smak zwycięstwa to za mało, aby ucieszyć ślęczącego nad tematem programistę, który tak trwa w tym stanie ciągle, przez kilka ostatnich dni i zrekompensować mu poniesione straty. Ważne, aby w tym całym szaleństwie znaleźć jeszcze umiar w dążeniu do celu i znaleźć czas na relaks i wypoczynek. Właśnie wtedy, kiedy rozwiązujemy problem najbardziej potrzeba nam wypoczynku.

Spotkałem się z dwoma podejściami do rozwiązania problemu - siłować się z nim do momentu, aż albo on, albo ja, lub też, drugie podejście, gryźć problem kawałek po kawałku, rozkładając go na części pierwsze.

Zakładając, że oba kończą się tym samym - zwycięstwem - nie mam wątpliwości, w której ja chciałbym się znaleźć. Oczywiście w tej drugiej. Ostateczne zwycięstwo będzie dodatkowo udekorowane wieńcem końca zadania i wystarczających sił na kolejne.

Takie coś przytrafiło mi się dzisiaj z rana, kiedy po śniadaniu z Agatką, zasiadłem do pewnego tematu (na razie o nim sza) i wszystko wydało się takie oczywiste. A wystarczyły regularność i spanie > 7h. Rozwiązanie samo do mnie przyszło, zamiast mnie biegającego za nim.

Najbardziej w tym wszystkim zdumiewające było to, że problem był niezwykle błahy i wyłącznie moja nieznajomość tematu robiła z niego większego potwora niż było potrzebne. "Boimy się nieznanego", jak powiadają.

I tu jest właśnie sedno sprawy - ciągłe rozwijanie swojej wiedzy, ciągłe próbowanie się z nowym. Kiedy czegoś nieznamy, kolejne nieznane może nas łatwo sfrustrować, prowadząc do błędnego wniosku, że jedyne, co potrafimy, to odkrywać nieznane. To samo w sobie może być wartościowe, ale niewielu pomyśli o tym pozytywnie. Kiedy jednak owe poznawanie wpiszemy w kontrakt naszego działania i wejdzie nam w krew, przedzieranie się przez nieznane, będzie jedynie odkrywaniem kolejnego nieznanego, co z dobrym wypoczynkiem (!) może dawać satysfakcję jego odkrycia. Idąc dalej, to nieznane może być niezwykle dochodowe (przez "dochodowe" rozumiem nową wiedzę, nowe możliwości, itp.) W końcu może się nawet okazać, że nowe dla nas jest nowym dla większości wokoło, a to stawia nas w szeregu nowicjuszy...eee, raczej...nowatorów!

Zostawiając na boku ten cały bełkot psychologiczny, pamiętajmy o wypoczynku, regularnym wypoczynku. 7h minimum i 3 x 1/2h ciągłego pływania/tydzień, to obowiązek każdego programisty. Tak sobie to dzisiaj wymyśliłem. Siedzenie nas wykańcza, a problemy technologiczne nie pomagają.

Żeby nie było, że wpis taki umoralniający, bez pierwiastka javnego, to napiszę, że właśnie z ukończeniem rozdziału 9-tego "Criteria API" książka Pro JPA 2: Mastering the Java™ Persistence API stała się dla mnie lekturą obowiązkową każdego parającego się JPA czy ORMem w Javie. Jestem na 10 rozdziale (273. strona) i z trudem idzie mi jej czytanie. Nie dlatego, że taka beznadziejna, ale dlatego, że każda strona wypełniona jest wiedzą JPA po brzegi! Rozdział 9. "Criteria API", który właśnie skończyłem zajął mi prawie 4 dni i cały jest zakreślony notatkami. W zasadzie wszystko było nowe (nie dotykałem wcześniej tematu w Hibernate) i niezwykle zapadające w pamięć swoją złożonością (w sensie pozytywnym, bo w końcu wciąż może być jeszcze trudniej, bo wciąż możemy zejść na poziom SQLa i bawić się z przenośnością aplikacji przechodząc ze środowiska lokalnego, najczęściej z jakąś wbudowaną bazą danych typu HSQL, do testowego z DB2, Oracle, MySQL, czy innym SQLowym stworzeniem).

Co mnie najbardziej zainteresowało, to budowanie zapytań SQL z mechanizmem silnie typizowanych (jak ja nie lubię tego słowa) zapytań w JPA2 (ang. strongly typed query definition) z kanonicznym metamodelem. Brzmi wyniośle, a sprowadza się do zmiany nazw pól w mapowaniu ORM (w postaci napisów) na ich silnie typizowane odpowiedniki (w postaci pól w klasie reprezentującej kanoniczny metamodel encji). Zamiast pisać ...get("ksiazka").get("tytul") można ...get(Ksiazka_.tytul). Kiedy dodam, że dostawcy JPA2 generują takie klasy kanoniczne (zwykle zakończone podkreślnikiem po nazwie encji/klasy) i przy pisaniu zapytania pomaga nam każde IDE, bez specjalnego wsparcia dla JPA2, to zysk jest niebagatelny. Można wręcz całkowicie zapomnieć o trzewiach ORMa w postaci relacyjnej bazy danych - same obiekty i silna typizacja. I znowu zaczynam biegać za nowym :) Bawił się tym już ktoś?

Notatnik startuje w "Bloger 2009 roku"

Ci, którzy zaglądają do Notatnika bezpośrednio już zapewne zauważyli, a pozostałych śpieszę poinformować, że mój blog Notatnik Projektanta Java EE został zgłoszony do konkursu Bloger 2009 roku.

Uprasza się wszystkich dbających o moje dobre samopoczucie, co ma niebagatelny wpływ na treść wpisów, o zagłosowanie w konkursie Bloger 2009 roku na mój blog.

Ze swej strony obiecuję poprawę i same wypasione technicznie wpisy :) Wszystkim dziękuję za oddane głosy.

Bajtkod praktycznie z wtyczką Bytecode Outline dla Eclipse

Czasy, kiedy pracowałem wyłącznie w Eclipse IDE dawno minęły i teraz częściej można było mnie spotkać przy NetBeans IDE, a ostatnio nawet przy IntelliJ IDEA (darmowe licencje są dostępne za prezentację podczas spotkań JUGa - chociażby Warszawa JUG).

Bodajże Łukasz Lenart zwrócił mi uwagę na aktualność Zestaw wtyczek Eclipse IDE do sprawnego tworzenia oprogramowania i tak mi jakoś zapadło w pamięci, aby go uaktualnić. W ten sposób szukałem tylko okazji, aby ponownie przysiąść przy Eclipse IDE i niedługo trwało, aż trafiłem na wtyczkę Eclipse Groovy (patrz De gustibus non est disputandum - Eclipse Groovy 2.0.0 dostępny). I tak się dalej potoczyło.

W międzyczasie, zaangażowany byłem w tworzenie poprawki do zgłoszenia OPENEJB-1128 Intercepting generic business method calls fails, które kolejny raz zaprowadziło mnie do org.objectweb.asm.signature.SignatureVisitor. Zawsze marzyło mi się dokładniejsze poznanie projektu ASM, więc kiedy zobaczyłem odnośnik Eclipse plugin na jego stronie głównej, w połączeniu z ostatnim rozpoznaniem wtyczek Eclipse, nie miałem złudzeń, że teraz nadeszła ta chwila. Wchodzę w ASMa!

Na głównej stronie ASM możemy przeczytać:

The best way to learn to use ASM is to write a Java source file that is equivalent to what you want to generate and then use the ASMifier mode of the Bytecode Outline plugin for Eclipse (or the ASMifier tool) to see the equivalent ASM code. If you want to implement a class transformer, write two Java source files (before and after transformation) and use the compare view of the plugin in ASMifier mode to compare the equivalent ASM code.

Nie pozostało mi nic innego, jak rozpoznawać ASM z pomocą wtyczki Bytecode Outline i Eclipse.

Pracuję z Eclipse IDE 3.5 SR1 (edycja Eclipse IDE for Java EE Developers), więc wystarczyło zdefiniować repozytorium wtyczki - http://andrei.gmxhome.de/eclipse/, aby się do niej dobrać. Chwila, dwie i wtyczka była już u mnie.

Niez(wyk)łe jest to, że mimo, że wcześniej czytałem, co daje mi wtyczka, kiedy zobaczyłem te funkcjonalności w działaniu, nie wierzyłem własnym oczom. Niesamowite doznania. Wtyczka Bytecode Outline pozwala na przegląd bajtkodu bez jakiegokolwiek wysiłku (nie wliczając wcześniejszego otwarcia widoku Bytecode :)).

Co mamy każdy widzi, ale widzieć nie oznacza rozumieć, więc warto pobrać wtyczkę i spróbować jej własnoręcznie. W widoku Bytecode otrzymujemy wynik działania ASM na skompilowanej klasie (bardzo podobny wynik otrzymalibyśmy korzystając z javap -c). Jakby tego było mało, w kolejnym widoku Bytecode Reference mamy dokumentację do instrukcji bajtkodu - chociażby w duchu poznawania nowego języka czy też wnętrza Javy, można w prosty sposób rozpocząć jego naukę bez wykrętów w stylu "Nie mam czasu", albo "Eee, to dla zaawansowanych".

Jeśli ktokolwiek mi teraz chociażby nadmieni, że poznawanie bajtkodu to wyzwanie dla najbardziej zaawansowanych (i jeszcze pewnie najmniej obłożonych bieżącym poznawaniem javowych szkieletów aplikacyjnych czy języków alternatywnych na JVM), to będę miał odpowiedź od ręki - wtyczka Bytecode Outline dla Eclipse. Z nią poznawanie rozwiązań typu AspectJ czy mechanizmów instrumentacji (modyfikacji bajtkodu w locie) nie powinien nastręczać problemów. Czyż świat nie wydaje się być prostszy, kiedy znamy klocki, z których jest zbudowany i rozumiemy ich wzajemne interakcje?! Nie mogłem wymarzyć sobie lepszego rozpoczęcia tygodnia!

[Sprostowanie]
Stworzona klasa świadomie upstrzona jest adnotacjami, które semantycznie nie mają większego sensu w tej klasie. Jej celem jest jedynie rozpoznanie tematu wymazywania typów generycznych podczas kompilacji oraz dostępności informacji o adnotacjach w klasach, a adnotacje @WebService i @WebMethod dostępne są w Java SE 6 z pudełka.

p.s. Widok Bytecode dostępny jest w kategorii Java obok kolejnego Bytecode Reference.

61. spotkanie Warszawa JUG - Wojciech Erbetowski z "PlayFramework" i Łukasz Lenart z "Google AppEngine"

Warszawska Grupa Użytkowników Technologii Java (Warszawa JUG) zaprasza na 61. spotkanie, które odbędzie się we wtorek, 9. lutego o godzinie 18:00 w sali 5440 Wydziału MIM UW przy ul. Banacha 2 w Warszawie.

Temat 1: PlayFramework - produktywność szkieletów webowych a'la Django, RoR, Grails
Prelegent: Wojciech Erbetowski

Temat 2: Google AppEngine - chmura na Ja(v)wie
Prelegent: Łukasz Lenart

Tym razem mamy dwie niezależne prezentacje.

Najpierw na scenę wchodzi Wojtek z "PlayFramework - produktywność szkieletów webowych a'la Django, RoR, Grails". Podczas wystąpienia poznamy nowiuteńki szkielet aplikacyjny dla Javy. Zrobiony w pełni w duchu RAD i COC (jeśli ktoś nie wie, o czym mowa, tym bardziej powinien się pojawić).
Ze względu na mechanizm szablonów ma szansę urzec tych, za których wiele może wykonać webmaster (aka pajeńczyniarz). Z drugiej strony, puryści zapewne wyleją na niego wiadro pomyj, bo jeszcze się taki nie narodził, kto by wszystkim dogodził i taka ich rola :)
Uczestnicy zobaczą kilka bardzo przyjemnych mechanizmów przydatnych do tworzenia bardzo typowych serwisów internetowych. Może być niezwykle odświeżająco i zajmie...jedynie 45 minut (!)

Następnie, zobaczymy prezentację "Google AppEngine - chmura na Ja(v)wie" Łukasza Lenarta. Prezentacja wprowadzi uczestników do świata tworzenia aplikacji Java w chmurach (ang. cloud computing), czyli pokaże czym jest Google AppEngine, jak pisać aplikację na tą platformę. W trakcie wystąpienia zostanie zaprezentowana prosta aplikacja korzystająca z dostarczonych usług przez GAE: BigTable - baza danych, Google Accounts czyli usługa zarządzania użytkownikami oraz Mail do wysyłania oraz odbierania poczty elektronicznej.
Na końcu zostanie zaprezentowana konsola dostarczana przez GAE, za pomocą której można zarządzać aplikacjami. Podobnie, wiele w niewiele - jedynie 45 minut (!)

Wojtek Erbetowski jest z wykształcenia matematykiem, a zawodowo programuje w Javie, zwłaszcza takie "typowe" rozwiązania.

Łukasz Lenart - programista z zamiłowania, tworzenie programów od zawsze było jego hobby, aż przerodziło się w zajęcie komercyjne. Uważa, że dobry programista nie powinien być uzależniony od języka, w którym tworzy, a raczej patrzeć w przyszłość i próbować różnych języków i technologii w zależności od wymagań - dzisiaj jest to Java, a co będzie za 10 lat? Równie dobrze może pisać w PHP, C#, Borland Delphi, etc. Ważne, aby przynosiło mu to przyjemność. Prywatnie mąż i ojciec, domator, który lubi czytać i ceni sobie święty spokój! Z przekonań socjalista, z działania kapitalista ;-)

Planowany czas prezentacji to 2x45 minut + 5-10 minut na przełączenie, po których planuje się 15-30-minutową dyskusję.

Wstęp wolny

Zapraszam w imieniu prelegentów i grupy Warszawa JUG!

5ty lutego, to imieniny Agaty od Laskowskiego...

Dziś Agatki są imieniny,
Jacek pośpiesznie przegląda (javowe) nowiny.
Dziś niewiele przy kompie spędzi,
bo go Agatuś zaraz popędzi.

Dzień pracujący, acz wspaniały zarazem,
Jacek i Agatka spędzą go wieczorem razem.
Zero dżawuni i jej enterprajsa,
Jacek Agatce życzy...wszystkiego najlepszego!

Przy końcu się wypaliłem i coś mi nie szło z tą twórczością liryczną. Nic nie się nie kleiło :( Może Wam udałoby się dokończyć życzenia?

p.s. Może ...wielkiego surprajsa? :)

De gustibus non est disputandum - Eclipse Groovy 2.0.0 dostępny

Wszystko zaczęło się od artykułu Groovy 1.7, Grails 1.2 and Groovy Eclipse 2.0 Updates Include Dependency Management,Language Support. Już miałem lekturę zmian w Groovy 1.7 i Grails 1.2 za sobą (nota bene, 1 lutego pojawiło się wydanie 1.2.1), więc pewnie nie dałbym się namówić na jego przeczytanie, ale dodatek w postaci Groovy Eclipse w temacie sprowokował mnie. Szczęśliwie artykuł, a raczej zajawka nowych wydań projektów, nie jest długi, więc wystarczył kwadrans i było po krzyku.

Podobają mi się takie dywagacje nad kodem, co można, a co nie i dlaczego. W tym artykuliku dowiedziałem się o java.util.concurrent.atomic.AtomicInteger (wciąż lektura zmian w Java SE 6 przede mną i tylko tyle wiem, ile się przydaje po drodze - pewnie niejedno przysłowiowe koło odkryłem w międzyczasie) i kolejny raz o Grape. W przypadku Grape, autor ciekawie przedstawia zalety dekorowania importów z adnotacjami, które zwykle trafiają do zewnętrznych plików w Maven czy Ant. Ciekaw jestem, ilu z Was podziela zdanie o "This in turn triggers the download of the dependency and makes your code's build more self-documenting." Mam wrażenie, że autor przekonuje, że użycie wszystkiego, co związane z klasą, bezpośrednio w niej, to dobra rzecz. Moje skromne doświadczenie programistyczne nie pozwala mi dostrzec tych zalet, bo jakkolwiek korzystam z adnotacji Java EE 5+, to tylko i wyłącznie w fazie prototypowania czy wczesnego rozwoju aplikacji. Później, preferuję podejście czysty technologicznie kod źródłowy ze wszelkimi dodatkami technologicznymi w postaci plików XML i to jeszcze w osobnych modułach projektowych. Stawiając sprawę jasno, adnotacje w kodzie dobre, ale docelowo nalegałbym, aby się ich stamtąd pozbyć i wynieść na zewnątrz, np. do plików XML.

O Grails 1.2 jedynie się wspomina, więc nie ma co liczyć na chociażby taki przekrój wiedzy, jak to ma miejsce w przypadku Groovy 1.7. Podobnie z Groovy Eclipse. Zdaje się, że autorowi bliżej do Groovy niż do pozostałych produktów i dodał je, bo...kazano (?). Początek (o Groovy) był świetny z końcówką (o Grails i Eclipse Groovy) do kosza. Można skończyć czytać na akapicie o Grails 1.2.

Gdyby ktoś mogł mi jeszcze wyjaśnić, co autor zamierzał wyrazić przez dwukrotne użycie angielskiego słowa 'sport' w artykule, byłoby cacy. Kompletnie nie mogę docieć, co to słowo znaczy w tym artykule.

Po artykule, zabrałem się za instalację wtyczki Eclipse Groovy. Instalacja zabrała niespełna kilka minut. Wystarczyło pobrać aktualną wersję Eclipse IDE for Java EE Developers 3.5 SR1 (3.6m4 nie działała) i dopisać http://dist.springsource.org/release/GRECLIPSE/e3.5/ jako stronę z aktualizacjami Eclipse Groovy (zainteresowani skrinkastem nt. tej instalacji, proszeni są o komentarz do wpisu). Po instalacji, chwila na restart Eclipse i miałem go uzbrojonego o wtyczkę Eclipse Groovy 2.0.0.

Przejrzałem kilka nowości, które oferuje i wybrałem najważniejsze z mojego punktu widzenia (pisanie dokumentów typu "New and Noteworthy" to wielka odpowiedzialność, bo ma tę wadę/zaletę, że "rozleniwia" potencjalnych użytkowników do badania tylko tych funkcjonalności, które zostały przedstawione w dokumencie - wiele ciekawostek może zostać nieodkrytych do czasu przypadkowego trafienia podczas pracy, a wciąż mogą być interesujące dla szerokiej publiczności):

- z Groovy-Eclipse 2.0.0M1 New and Noteworthy:

Incremental compilation, co zgodnie z nazwą sprowadza się do kompilacji jedynie tych elementów projektu, które zostały zmienione bez względu na język, w jakim zostały napisane - Java czy Groovy. Innymi słowy, ma być szybciej, dzięki integracji kompilatora Eclipse JDT i Groovy.

JUnit Monospace font do wyświetlania wyników uruchomienia testów z Spock Framework. Nigdy nie używałem go wcześniej, a jedynie słyszałem wzmianki o nim, więc teraz chociażby z ciekawości, ile będzie mnie kosztowało uruchomienie go w Eclipse i docenienie zmian we wtyczce Eclipse Groovy znajdę czas dla niego.

Wyłączanie Groovy Script z kompilacji przy budowaniu/uruchamianiu projektu. Wystarczy wybrać opcję Build Path > Exclude z menu kontekstowego na wybranym skrypcie groovy.

Breakpoints and debugging - mamy możliwość ustawiania miejsc zatrzymania (ang. breakpoints) debugera i podejrzenia stanu zmiennych skryptu/aplikacji napisanej w Groovy.

Runtime evaluation of Groovy code - wyliczanie wyniku uruchomienia wycinków kodu Groovy.

- z Groovy-Eclipse 2.0.0M2 New and Noteworthy:

Refactoring Support - zmieniamy zmienną/metodę/klasę w Javie i zmiany propagują się do kodu Groovy, i na odwrót.

Task Tags - znamy i używamy - TODO, FIXME i XXX w kodzie Groovy rozpoznawane są dokładnie jak w Javie.

Wszystkie ze zmian opisane są dokładniej na blogu autora wtyczki Contraptions for programming, więc spragnieni wiedzy (a tylko tacy tutaj zaglądają :)) mogą pozwolić sobie na więcej...wiedzy.

- z Groovy-Eclipse 2.0.0RC1 New and Noteworthy:

Jars from .groovy/lib directory added to classpath - dodajemy wybrane jary do katalogu ~/.groovy/lib i automatycznie trafiają do ścieżki klas (CLASSPATH) naszego projektu. Niekoniecznie potrzebne biorąc pod uwagę możliwość skorzystania z Apache Maven 2, ale...nie wszyscy z niego korzystają (= straceńcy :))

To tylko wybrane usprawnienia we wtyczce Eclipse Groovy i zostały przeze mnie namaszczone mianem tych ważniejszych, co niekoniecznie musi spełniać kryteria Waszej ważności. Szczegółów należy szukać bezpośrednio u źródła - na stronie wtyczki Eclipse Groovy.

Interesujący jest fakt, że mamy publicznie dostępną wersję finalną wtyczki, a w JIRA jest 1 otwarte zgłoszenie na poziomie Major. Widać JIRA swoje, a wtyczka swoje. I tak, głównymi i jedynymi opiniodawcami są sami użytkownicy i bez względu na ilość włożonej pracy nawet największe dzieło może nie doczekać się właściwego poszanowania. W końcu piękno to kwestia gustu, a o nim się nie dyskutuje...De gustibus non est disputandum, albo Beauty is in the eye of the beholder. Wspaniale pasuje jako podsumowanie dyskusji nt. assert w komentarzach do Niemy film(ik) na weekend - Java Persistence (JPA) 2.0 praktycznie - zestawienie środowiska z EclipseLink i Apache Maven 2. Dzięki Wujek za "uzyles asercji bo chciales i tyle." Właśnie! ;-)

Niemy film(ik) na weekend - Java Persistence (JPA) 2.0 praktycznie - zestawienie środowiska z EclipseLink i Apache Maven 2

Spisałem scenariusz (artykuł Java Persistence (JPA) 2.0 praktycznie - zestawienie środowiska z EclipseLink i Apache Maven 2) i kolejnego dnia przyszło do kręcenia filmiku.

Mimo swoich wad reżyserskich, miernej gry aktorów (poza tymi technologicznymi) i jego dopadło światło dzienne. Na YouTubie pojawił się bez fanfar, nagrody Grammy, Złotych Lwów, czy Oscara, ale doświadczenie jest zdecydowanie większe. Scrinkast można podziwiać na deskach YouTube - Java Persistence (JPA) 2.0 praktycznie - zestawienie środowiska z EclipseLink i Apache Maven 2.

Wiele w nim niedoskonałych cięć, ale z samego produktu jestem niezwykle zadowolony, bo jest to pierwsza edycja, która ujrzała światło dzienne z gadżetami w stylu podświetlanie, spowalnianie, wstawki tekstowe na rozpoczęcie odpowiedniej sesji nagranionej, więc dużo było przy tym pracy edycyjnej, ponagraniowej. Teraz pozostaje zrobić ostatni krok - podłożyć głos narratora, aby poza oglądaniem było trochę życia w nagraniach. Kiedy będzie głos w skrinkastach, będzie mi bliżej do zrealizowania jeszcze jednego pomysłu - podkastów. To takie połączenie przyjemnego z pożytecznym (co jest czym pozostawiam Waszej ocenie). W przypadku skrinkastów, ja kontroluję, co będzie powiedziane, a podkast uważam za ewaluację głosową, gdzie tych rozmówców oczekuje się więcej.

Komentarze odnośnie mojej dotychczasowej pracy nagraniowej są bezcenne na tym etapie, więc śmiało! Potrzeba mi wrażeń w stylu - co było denerwujące, czego za mało/dużo, długość nagrania i sam sposób przedstawiania - wklejanie kawałków kodu zamiast ich wpisywanie. Więcej ich, to mniej Waszego cierpienia później. To tak, jakby powiedzieć "Jak sobie pościelesz, tak się wyśpisz", co oznacza, że jeśli teraz pojawią się (dobre?) rady, to ich wdrożenie na tym etapie będzie przyczynkiem do moich przyzwyczajeń później. Nie ma obawy o mój stan psychiczny. Dam sobie radę nawet z komentarzami w stylu "Do kitu! Zajmij się lepiej hotdogami.", aczkolwiek preferowałbym w takiej sytuacji więcej argumentów.

Przydałaby się jakiś akompaniament muzyczny na podkład, coś w stylu muzyki poważnej, ale delikatnie. Propozycje propozycji pozbawionych praw autorskich, tj. możliwych do użycia bezpłatnie, mile widziane. Ten sam problem będzie i przy podkastach.

A teraz do skrinkasta...