Piotr Wardyński certyfikowanym programistą Java

Maj 5th, 2011 by vezyr | Permalink

Minęło już kilka dni, chyba więc czas się pochwalić. Tuż przed długim majowym weekendem podszedłem do egzaminu OCJP – Oracle Certified Java Programmer (dawne SCJP, czyli Sun Certified Java Programmer). Po pewnym czasie przygotowań i rozwiązywania testów, udało mi się zdać wspomniany przed chwilą egzamin, myślę że z nie najgorszym wynikiem ogólnym (91% poprawnych odpowiedzi). Egzamin, jak pewnie każdy zainteresowany wie, nastawiony był nie tylko na sprawdzenie mojej wiedzy z samej Javy, ale także z zasad programowania obiektowego czy zwykłej spostrzegawczości i umiejętności analizy kodu źródłowego. Na egzamin przeznaczone są 3 godziny, choć jak ktoś zna Javę i ma trochę praktyki w programowaniu, powinien skończyć szybciej – ja wyszedłem już po 2 godzinach. Dla potwierdzenia wrzucam wydruk jaki otrzymałem w ośrodku certyfikacyjnym, na którym widać ogólny wynik z egzaminu, jak również wyniki z poszczególnych zagadnień.

Wyniki egzaminu OCJP

Wyniki egzaminu OCJP

Idea rozmytego perceptronu jako ogólnego modelu dla systemów neuronowo – rozmytych

Kwiecień 17th, 2011 by vezyr | Permalink

 

W ten niedzielny poranek, chciałbym podzielić się kolejnym napisanym przeze mnie artykułem, na temat sieci neronowo-rozmytych. Opracowanie przedstawia ideę rozmytego perceptronu zaproponowaną przez Detlefa Nauck oraz Rudolfa Kruse z Uniwersytetu Technicznego w Braundschweig. W pierwszej części sprecyzowane zostało pojęcie systemów neuronowo – rozmytych, w kolejnych zaś przedstawiony został model rozmytego perceptronu, jako trójwarstwowa sieć neuronowa ze zbiorami rozmytymi do modelowania wag, który może posłużyć do zaprezentowania ogólnej idei systemów neuronowo – rozmytych oraz ułatwić porównanie różnych wypracowanych do tej pory rozwiązań. W niniejszym opracowaniu zaprezentowano podstawowe informacje na temat tego perceptronu, a także przedstawiono jedną z jego implementacji. Cały artykuł w formacie pdf załączony został do wpisu.

Wykorzystanie algorytmów genetycznych w procesie komponowania muzyki

Kwiecień 16th, 2011 by vezyr | Permalink

 

Jakiś czas temu odnalazłem płytę z kopią zapasową materiałów, jakie uzbierałem w czasie studiów. Postanowiłem więc podzielić się częścią z nich. Na pierwszy ogień pójdzie artykuł, który napisałem w ramach seminarium z przedmiotu związanego z Algorytmami genetycznymi. W artykule przedstawiono sposób wykorzystania algorytmów genetycznych w procesie komponowania muzyki, na przykładzie działającego systemu GenJam. System GenJam został stworzony przez profesora Ala Bilesa. Służy do prowadzenia swego rodzaju potyczki pomiędzy dwoma muzykami grającymi muzykę jazzową. Zasada takiej potyczki polega na odgrywaniu improwizowanych fragmentów utworu naprzemiennie przez dwie osoby. GenJam zastępuje jedną z tych osób – „pojedynek” prowadzą więc człowiek i komputer. System analizuje otrzymywane dane podczas gry człowieka, a następnie z wykorzystaniem algorytmów genetycznych, komponuje (improwizując) kolejny fragment utworu, odmienny od dotychczasowego, zagranego przez człowieka, ale także podobny, pasujący do całości utworu. Cechą szczególną jest fakt, że jest to muzyka jazzowa, znacznie trudniejsza do skomponowania i zagrania, niż muzyka elektroniczna czy techno – a raczej systemów komponujących taki rodzaj muzyki spodziewałem się spotkać, gdy zabierałem się do zgłębiania tego tematu. Artykuł polecam przede wszystkim osobom zainteresowanym sztuczną inteligencja i algorytmami genetycznymi, gdyż przedstawia sposób wykorzystania i implementacji algorytmów genetycznych w systemie GenJam. Zachęcam także, już nie tylko osoby fascynujące się sztuczną inteligencją, do obejrzenia krótkiego, 5 minutowego filmu, przedstawiającego działanie systemu GenJam – można przekonać się na własne uszy, do czego można wykorzystać algorytmy genetyczne i jak wspaniałe efekty można dzięki nim uzyskać. Cały artykuł dołączony do tego wpisu w postaci pliku pdf.

Długość i koszty produkcji gier komputerowych

Kwiecień 13th, 2011 by vezyr | Permalink

Trend znacie i pewnie go nie kochacie. Kampania dla pojedynczego gracza na kilka godzin mało komu wystarcza. Mówi się ogólnie o tym, że to już taki nowy standard. Cóż, zależy gdzie spojrzeć i jak spojrzeć…

Każdy zna trend coraz krótszych gier komputerowych. Sam jakiś czas temu pisałem o tym, dokąd zmierzają obecne gry. Dziś natknąłem się na dwa ciekawe artykuły (a może raczej jeden, tylko złożony z dwóch części), którymi chciałbym się podzielić (tak, to z jednego z nich pochodzi powyższy cytat) – W samo południe z coraz krótszymi grami oraz W samo południe z grami coraz droższymi w produkcji. Oba artykuły, umieszczone w serwisie gram.pl, przedstawiają bardzo ciekawe i obiektywne opinie – szczególnie jeżeli chodzi o długość obecnych produkcji, a także dlaczego w niektórych gatunkach trend do skracania gier jest większy, niż w innych. Polecam przeczytanie obu, a następnie refleksję, czy droga obrana przez twórców, polegająca na rozwijaniu m.in. grafiki kosztem skracania fabuły, jest drogą dobrą, a także czy to nie my, gracze, jesteśmy trochę winni takiego podejścia.

Java, OS X, com.sun.tools i tools.jar

Marzec 17th, 2011 by vezyr | Permalink

Używam swojego MacBooka, pracującego w tej chwili pod kontrolą OS X 10.6.6 Snow Leopard, już ponad rok. Nigdy nie było z nim problemów, jednak ostatnio natknąłem się na dość dziwny problem, którego rozwiązania nie udało mi się odnaleźć w zasobach internetu. Pracując nad projektem, pojawiła się w nim pewna zależność Mavena, która spowodowała błędy w czasie uruchomienia aplikacji. Okazało się, że zależność ta posiadała powiązanie bezpośrednio do pliku tools.jar. Plik ten jest dostarczany standardowo wraz z Javą i zawiera w sobie pakiet com.sun.tools. Wszystko byłoby dobrze, gdyby Java pod OS X nie była specjalnie przygotowaną wersją, w której wszystkie standardowe pakiety, w przeciwieństwie do normalnej dystrybucji Java, zostały zamknięte w jeden plik – classes.jar. Efektem tego było, że projekt przestał się uruchamiać pod OS X, gdyż szukał pakietu com.sun.tools bezpośrednio w pliku tools.jar, który w Snow Leopard po prostu nie istnieje. Niestety, zależność Mavena, która spowodowała takiego problemy, była konieczna w projekcie i nie zdawała się zauważać, że wymagany pakiet klas ładowane jest do wirtualnej maszyny z innego pliku jar. A wystarczy podejrzeć plik /Library/Java/Home/bundle/Classes/classes.jar poleceniem:

jar -tf /Library/Java/Home/bundle/Classes/classes.jar

aby przekonać się, że zawiera w sobie com/sun/tools. Pierwszą myślą było utworzenie dowiązania symbolicznego z nazwą tools.jar, które wskazywałoby na plik classes.jar. Pomysł nie okazał się jednak najlepszy, a Java zaczęła narzekać, że posiada dwa pakiety o identycznej nazwie i z identycznymi klasami w dwóch różnych plikach jar. Po chwili namysłu wpadł mi do głosy jednak inny, trochę szalony pomysł. Skoro pakiet com.sun.tools, wraz ze wszystkimi jego klasami, jest ładowany przez wirtualną maszynę, nie ma potrzeby, aby klasy te znajdowały się faktycznie w pliku tools.jar (wirtualną maszynę nie interesuje z którego archiwum załadowała klasę, musi tylko istnieć w systemie). Problemem jest brak pliku tools.jar, a nie brak odpowiednich klas. Wystarczy więc przygotować pusty plik tekstowy, spakować do przy pomocy ZIPa do pliku tools.zip, a następnie zmienić nazwę na tools.jar (pliki jar to po prostu specjalna wersja zipów, nawet można je rozpakować korzystając ze zwykłego zipa). Tak przygotowany plik należy skopiować jeszcze w odpowiednie miejsce:

/Library/Java/Home/bundle/lib/tools.jar

i wszystko zaczyna działać jak należy. Najprawdopodobniej powyższy sposób pomoże każdemu, kto z jakiś powodów napotyka błędy w Mavenie informujące o brakującym pakiecie com.sun.tools. Tak naprawdę to nie brak pakietu, a brak fizycznego pliku tools.jar jest problemem. Jedyną wadą powyższego obejścia jest fakt, że trzeba je wykonywać po każdej aktualizacji Javy dla OS X – na szczęście zdarzają się one stosunkowo rzadko.

Najnowsze komentarze