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...
Subskrybuj:
Komentarze do posta (Atom)
"Koń jaki jest, każdy widzi" -
OdpowiedzUsuńjaka technologia jest również.
To twoje cięte komentarze tworzą potęge tego miejsca, więc niemym screencastom mówimy stanowcze NIE!
Komentarz musi być :D inaczej to będzie kolejna forma nudnej dokumentacji ;)
Ps. wracam do przygotowań do sjcp do którego również zmotywował mnie twój blog ;) (i promocja)
Krzysiek.
tak z ciekawosci, czemu nie szukasz tlumaczenia dla slowa screencast? :)
OdpowiedzUsuńtak, jestem ironiczny :)
+ odpowiednia ilość materiału
OdpowiedzUsuń- brak komentarza
- kod wklejany (przy słabej widoczności czcionki i braku komentarza w zasadzie nie wiadomo, co jest wklejane). Moim zdaniem, lepiej, jakby kod był wpisywany w trybie zoom. (z komentarzem co jest wpisywane).
To już jest solidna porcja uwag. Wystarczy na kolejną odsłonę.
OdpowiedzUsuńOdnośnie tłumaczenia screencast to filmik mi pasuje, albo nawet skrinkast. Nic innego nie przychodzi mi do głowy (nietechniczne i dlatego :))
"Zajmij się lepiej hotdogami."
OdpowiedzUsuńArgument:
+ Hot Dogi sa smaczne :)
+ Hot Dogami mozna sie najesc
- Zjedzenie hot doga nie dostarcza wiedzy o JPA 2.0
Widac w skreenkastach coraz wiecej doswiadczenia. Oby tak dalej! Wg mnie wszystko za szybko sie dzialo i trudno bylo ogarnac co sie dzieje. Oprocz tego uwagi takie jak @MZ.
Co do muzyki to podesle Cie linka jak tylko odezwie sie do mnie moj kolega. Znalazl bardzo dobre zrodlo, a poniewaz jest montazysta filmowym to mozna mu zaufac :)
dotrzymuje obietnicy. Prosze Jacku, mam nadzieje, ze znajdziesz cos ciekawego na swoje ...casty :)
OdpowiedzUsuńhttp://www.jamendo.com/pl/
@daytek, super miejsce! Wziąłem pierwszą lepszą kapelkę na odsłuchanie i <a href="http://www.jamendo.com/pl/album/60451>Powerful Water DUBSYNATICX</a> podoba mi się. Zastanawiam się, czy nie nazbyt rytmiczna :) Może znajdę coś z klimatów punk rocka ;-)
OdpowiedzUsuńWitam,
OdpowiedzUsuńMoim zdaniem to taki skrinkast powinien być opatrzony komentarzem słownym autora a nie muzyką. Mam wrażenie, że jakikolwiek podkład rozpraszał by widza.
myślę również, że te tytuły etapów mogły by być delikatniejsze, szczerze mówiąc te przejścia wyglądają dość kiczowato ;)
Ale ogólnie to super, ciesze się, ze w końcu "przeszedłeś od słów do czynów"
A teraz czas na ochrzan :) Jacku tyle osób Cię czyta, więc masz moralny obowiązek nie propagować złych praktyk!
co to za test?
assert costam != null; ??
takiej formie testowania mówimy stanowcze nie :)
zamiast "tego czegoś" powinieneś użyć:
import static org.junit.Assert.*;
assertNotNull(costam);
i ładniej i czytelniej i zgodnie ze sztuką ;)
Moim zdaniem słowa kuczowego "assert" w ogóle nie powinno się używać. usuń je ze swojego warsztatu programistycznego :P
@Michał, nie rozumiem tej sztuki użycia assertNotNull? Słowo kluczowe assert jest w języku, a aNN jest w JUnit. Przypadkiem wybrałem JUnit, bo gdzieś ostatnio czytałem jaki on jest be w stosunku do TestNG. Czy tam też assert byłby ble? Nie. Tam nie ma tego ustrojstwa z import static org.junit.Assert.*;.
OdpowiedzUsuńA teraz czas na ochrzan (niewielu publicznie otrzymuje taki "prezent" ode mnie, ale Tyś już wytrwały w bojach i szastasz sztuką, więc sobie pozwolę):
import static org.junit.Assert.*;
jest niezgodne ze sztuką, bo importujesz wszystkie statyczne metody, które mogą być w konflikcie z innymi o tej samej nazwie (!) Poza tym, znalezienie pochodzenia metody (bez wsparcia IDE) jest nietrywialne. Stąd konieczne jest jawne podawanie metod importowanych statycznie, albo zaniechanie import static.
A tutaj odnośniki do "mojej" sztuki - TooManyStaticImports oraz Imports
Proszę o referencje do Twojej.
Slowo kluczowe assert wymaga abys uruchomil testy z -ea (wzglednie wyspecifikowal pakiety / klasy, a to jeszcze wiecej roboty), jesli o tym zapomnisz to testy nie maja sensu bo nigdy nie dostaniesz bledu.
OdpowiedzUsuń@Wujek, ale -ea jest włączone w mavenie przy wykonywaniu testów. Rozumiem argument, aby nie używać assert w publicznym interfejsie do kontroli parametrów wejściowych (bo domyślnie assert jest wyłączone - patrz Do not use assertions for argument checking in public methods.), ale w testach jednostkowych nie bardzo. Co mnie utwierdza w tym "nie bardzo", to dokumentacja TestNG - 6.1 - Success, failure and assert:
OdpowiedzUsuńYour test methods will typically be made of calls that can throw an exception, or of various assertions (using the Java "assert" keyword).
Za słabym, aby mianować się znającym na sprawie pisania poprawnych testów jednostkowych, ale moja pobieżna wiedza nie pozwala mi przyjąć argumentu za nie stosowaniem assert. Za dużo wokół mnie tych, którzy je promują. Brakuje mi konkretów za "nie". Na razie słyszę o "sztuce" i "bez sensu", ale linków/przykładów brak.
Jacek:
OdpowiedzUsuń"import static org.junit.Assert.*;
jest niezgodne ze sztuką, bo importujesz wszystkie statyczne metody, które mogą być w konflikcie z innymi o tej samej nazwie (!) Poza tym, znalezienie pochodzenia metody (bez wsparcia IDE) jest nietrywialne. Stąd konieczne jest jawne podawanie metod importowanych statycznie, albo zaniechanie import static.
A tutaj odnośniki do "mojej" sztuki - TooManyStaticImports oraz Imports
Proszę o referencje do Twojej."
Wiesz co, moim zdaniem wychodzi tutaj trochę brak doświadzcenia z testaim jednostkowymi.
Piszesz że metody zaimportowane statycznie "MOGĄ" byś w konflikcie z innymi nazwami.
dokładnie w tym przypadku który podałem - to z jaką inna metodą z klasy Assert wchodza w konflikt? wymień chociaż jedną...(czkam, czekam...) no cóż nie doczekałem się się z prostego powodu, Taki konflikt tu nie występuje (i powiem Ci z doświadczenia że jest to 95% przypadków). Jeśli rozważamy jakiś problem to nie w wirtualnej przestrzeni ale w konkretnym kontekście. Tutaj żadne nazwy się nie konfliktują więc powinniśmy zrobić tak jak jest wygodniej. w tym wypadku zaimportować metody statycznie.
Argument z brakiem IDE jest dla mnie kompletnym nieporozumieniem. bo sorry ale kiedy kodowałeś bez IDE? jasne zdarzają się sporadyczne sytuacjew ktorych trzeba spojrzeć na kod w VI ale są to sytuacje których trzeba unikać, a na pewno nie programować z myślą o tym.
Idąc za twoim tokiem myślenia rozumiem, że w swoich aplikacjach stosujesz również notacje węgierską dla wszystkich zmiennych? bo przecież bez IDE trudno sprawdzić czy dana zmienna jest instancji, lokalna, czy też parametrem metody - a jakiego typu to kolejny wielki problem.
jeśli chodzi o referencje, to polecam tak mało znane frameworki jak np:
JUnit,
Mockito
bez statycznych importów w Mockito musiał byś np napisać:
List a = Mockito.mock(List.class);
Mockito.when(a.get(Matchers.anyInt())).thenReturn("B");
Mockito.verify(a).get(Matchers.argThat(new ArgumentMatcher(){}));
a ze statyczymi mamy:
List a = mock(List.class);
when(a.get(anyInt())).thenReturn("B");
verify(a).get(argThat(new ArgumentMatcher(){}));
moim zdaniem jest czytelniej i ładniej - a w testach czytelność odgrywa jedną z najistotniejszycg ról. Ale ostateczną ocenę pozostawiam Tobie - może się mylę.
Co do assertNotNull zamiast assert a!= null;
Widzę że nie dasz się przekonać, ale oprócz tego, że w testach powinniśmy używać frameworku do testowania na który się zdecydowaliśmy to dodatkowo, ponownie, moim zdaniem tak jest dużo czytelniej. Rzut oka na ten DSL (bo jest to właśnie DSL do testów) i wiadomo że nie chcemy żeby a było nullem.
Co do argumentow, to Ty podales 1 cytat z dokumentacji frameworka, ktory dostarcza rowniez dedykowana klase do asercji, oraz dany tekst: An "assert" failing will trigger an AssertionErrorException, which in turn will mark the method as failed (remember to use -ea on the JVM if you are not seeing the assertion errors). Pamietaj, ze nie wszyscy uzywaja mavena (swoja droga nie wiedzialem ze wlacza asercje domyslnie - dzieki za nauke).
OdpowiedzUsuńCo do linkow, to czasami mozna samodzielnie pomyslec i miec zdrowy rozsadek, niz ciagle szukac poparcia wsrod innych, to jest bardzo wazne w tej profesji ;d Nie mam na celu oskarzac Cie o brak pomyslunku, ale stwierdzenie "za duzo osob wokol mnie to promuje" (drugi z Twoich argumentow, niezbyt autorytatywny) brzmi troche dziwnie z ust profesjonalisty - nie masz swoich przemyslen na dany temat?
Popieram argument ze asercje to DSL danego frameworka, i jest duzo czytelniejszy.
Inna sprawa ze atak o blad w sztuce w tym przypadku troche na wyrost, uzyles asercji bo chciales i tyle.
Pax!
Na dzisiaj mi wystarczy argumentów. Przemyślę i wdrożę w życie. Dzięki za wytrwałość w promowaniu "testowego DSLa". Postaram się go mieć w pamięci, a na dodatek zabieram się za jakąś książkę o testowaniu. Propozycje mile widziane.
OdpowiedzUsuń