Komputery, oprogramowanie, internet i okolice
Kategorie: Wszystkie | Aplikacje | Blog | Dev | Hacks | Linux | Subversion | Varia | gry | khoomei | książki | mjuzik
RSS
niedziela, 30 grudnia 2007
Kompozytor: Terry Riley
Utwór: In C

Tak, chodzi o muzykę poważną. Choć ta akurat kompozycja tak do końca poważna nie jest. Można by nawet pokusić się o stwierdzenie, że jest to tak na prawdę zabawa. Zabawa formą. Czy może Formą (a nawet czystą formą, tylko w odniesieniu do muzyki). Po krótce przedstawię zasady wykonania (pełna informacja i nutki do ściągnięcia):
  • "In C" składa się z 53 krótkich fraz melodyczno rytmicznych
  • kompozycja może zostać wykonana przez dowolną grupę muzyków, na dowolnych instrumentach (lub wokalnie), przy czym optymalna liczba to 35
  • tempo i czas trwania są dowolne
  • frazy grane są po kolei
  • każdy z grających sam decyduje jak długo powtarza daną frazę
  • każdy grający sam decyduje kiedy zacząć grać frazę, ważne by trzymał się rytmu
  • grający może opuścić niektóre frazy, czy też pauzować
  • jednak nikt nie powinien "uciekać" lub "zostawać w tyle" na więcej niż 2-3 frazy
  • można dowolnie transponować frazy w górę i w dół
  • przynajmniej raz lub dwa cała orkiestra powinna grać którąś z fraz unisono
  • jedna osoba (najlepiej ładna dziewczyna) może grać wysokie C równymi ósemkami pełniąc rolę metronomu
Niby proste ale efekt jest powalający. Rytmy, frazy, tekstury, melodie wzajemnie się nakładające i przeplatające. Ciągły ruch na kilku płaszczyznach na raz. Przedziwny puls. Zmieniające się struktury wyłaniające się z pozornego chaosu. Cały czas zostajemy zaskakiwani - ta sama fraza może brzmieć zupełnie inaczej gdy zmienia się cały kontekst.
By rzeczywiście docenić tą kompozycję nie ma innego wyjścia niż wysłuchać wykonania od początku do końca.

Jeśli ktoś chce poznać to wspaniałe dzieło to muszę przyznać, że ma wielkie szczęście. Nie musi od razu wydawać sporych pieniędzy na płyty. Na last.fm można wysłuchać (i ściągnąć na dysk!) nie jedno a trzy wykonania. Po prostu wejdźcie na http://www.last.fm/music/Terry+Riley/_/In+C i kilkakrotnie klikajcie na Download mp3. Dostępne tam wykonania to:
  • 25th Anniversary Concert (amazon) [1h16m] - dosyć monumentalne wykonanie - bogactwo instrumentów, tekstur, zabaw dynamiką.
  • Ars Nova Copenhagen, Percurama Percussion Ensemble, Paul Hillier (amazon) [55m] - niezwykłe wykonanie bo z wykorzystaniem chóru. Całość nabiera dzięki temu zupełnie nowego wymiaru. Na początek jednak radziłbym zapoznać się z bardziej klasycznymi wykonaniami
  • Ensemble Percussione Ricerca, Eddy De Fanti (amazon) [41m] - wykonane przez grupę perkusyjną, niezbyt przypadło mi do gustu
Inne znane mi wykonania to:
  • State University Center of Creative and Performing Arts (amazon) - wykonanie, od którego rozpocząłem moją przygodę z tą kompozycją. Na saksofonie gra tu sam Terry Riley. Jest ona chyba najbardziej niespokojna i zaskakująca, najwięcej tu "pozornego chaosu", bardzo puslująca
  • Bang On Can (amazon) - bogate instrumentarium, bardzo melodyjne.
  • z albumu Reed Streams (amazon) - bardzo ciekawe i zupełnie inne. Wykonane przez big band w sposób jazzująco psychodeliczny.
  • The Freeform Ensemble (podcast na SmallWorld) - niestety nie jest to zbyt dobre wykonanie. Zbyt chaotyczne i mało spójne.
20:07, kosciak1 , mjuzik
Link Dodaj komentarz »
czwartek, 13 grudnia 2007
1. Wersje pod kontrolą - wstęp do wersjonowania plików
2. Subversion - podstawowe pojęcia
3. Subversion - instalacja i tworzenie repozytorium
4. Subversion - podstawy pracy z wersjonowanymi plikami
5. Subversion - zaawansowane komendy
6. TortoiseSVN - graficzny klient SVN
7. RabbitVCS + Meld - integracja Subversion z Nautilusem
8. VisualSVN Server - prosta instalacja serwera Subversion
9. SVN4MSOffice - potęga Subversion w MS Word


Skoro już wiemy jak Subversion zainstalować, skonfigurować lokalny serwer, założyć repozytorium i utworzyć kopię roboczą pora na kolejny temat.

Podstawy pracy z wersjonowanymi plikami

1) Pobranie zmian wprowadzonych przez innych użytkowników
Jeśli korzystamy z lokalnego repozytorium, do którego tylko my mamy dostęp w zasadzie możemy ten krok pominąć. Jeśli jednak pracujemy wraz z innymi zaktualizowanie plików w naszej kopii roboczej jest już koniecznością. Choćby po to by nie pracować nad rzeczami, które ktoś mógł już zrobić.
Wykonujemy to za pomocą komendy:
svn update
Nie musimy już wpisywać adresu repozytorium - wszystkie potrzebne dane siedzą sobie we wspomnianych już katalogach .svn
Po wykonaniu tej komendy wyświetlone zostaną wszystkie zmiany w plikach w postaci:
svn update
A blabla.java
D foofoo.java
U barbar.java
C jakis.java
G zupelnieinny.java
Updated to revision 48.
Gdzie A oznacza dodany plik, D - skasowany, U - zmieniony, C - pliki w konflikcie (gdy pobrane zmiany dotyczą tego samego fragmentu pliku, który był edytowany lokalnie), G - połączony za pomocą komendy merge z innej linii rozwojowej. Dodatkowo otrzymujemy informację o numerze rewizji repozytorium.

2) Wprowadzanie zmian w plikach i folderach
Gdy mamy już najnowszą wersję plików możemy wykonać następujące czynności:

a) Dodanie pliku
Pliki dodajemy za pomocą polecenia:
svn add [plik(i) lub folder(y)]
Po wykonaniu tej komendy pliki zostaną oznaczone jako oczekujące na dodanie. Rzeczywiste dodanie nastąpi w momencie najbliższego commitu. Jeśli wskazany został folder cała jego zawartość również zostanie dodana do repozytorium.
Foldery możemy także utworzyć za pomocą polecenia
svn mkdir [folder]
Jeśli utworzymy pliki normalnymi poleceniami systemu i nie dodamy ich za pomocą svn add nie będą wersjonowane!

b) Usunięcie pliku
Pliki usuwamy za pomocą:
svn delete [plik(i) lub folder(y)]
Jeśli wybrany został plik natychmiast zniknie on z kopii roboczej, jeśli folder to zostanie on (i jego zawartość) oznaczone jako do usunięcia. Rzeczywiste usunięcie plików z repozytorium nastąpi, podobnie jak w przypadku svn add dopiero przy najbliższym commicie.
Jeśli skasujemy plik normalnymi poleceniami systemu a nie za pomocą svn delete zostaną ponownie pobrane z repozytorium przy najbliższym update. Warto o tym pamiętać - jeśli coś solidnie popsuliśmy wystarczy skasować "popsuty" plik lub folder i wykonać update by móc cieszyć się poprzednią wersją pliku.

c) Przenoszenie i kopiowanie plików
Wykonujemy za pomocą poleceń
svn move [źródło] [cel]
svn copy [źródło] [cel]
Co najważeniejsze SVN "pamięta" całą historię kopiowanego pliku. Podobnie jak w przypadku dodawania i kasowania plików trzeba wykonać commit by zmiany zostały zapisane w repozytorium.

d) Dokonywanie zmian w plikach
W wypadku zwykłych zmian w plikach nie musisz używać żadnych specjalnych komend Subversion. Po prostu edytujesz pliki w swoim ulubionym edytorze.

3) Sprawdzenie jakie zmiany zostały dokonane
Przed wysłaniem wyniku swojej pracy do repozytorium warto sprawdzić co tak na prawdę zmieniliśmy. Co najważniejsze wszystkie przedstawione w tym punkcie komendy nie wymagają połączenia z repozytorium. Wszystkie potrzebne dane znajdują się w katalogach .svn
Do tego celu możemy wykorzystać:

a) Wykaz zmian
Wykaz wszystkich zmienionych plików i folderów otrzymamy za pomocą polecenia:
svn status
Zwrócona zostanie lista plików poprzedzona sześcioma kolumnami informującymi o rodzaju zmian. Nas na razie interesuje jedynie pierwsza kolumna zawierająca oznaczenia podobne do tych poznanych w komendzie svn update
I tak: A - element przygotowany do dodania, D - element przygotowany do skasowania, U - element zmodyfikowany, R - zamieniony (element został przygotowany do skasowania a następnie został utworzony nowy o tej samej nazwie), ? - element nie podlegający wersjonowaniu (na przykład plik dodany normalnymi metodami a nie za pomocą svn add), ! - brakujący element (na przykład skasowany normalnymi metodami a nie za pomocą svn delete)

b) Wyszczególnienie zmian w pliku
Czasem może się zdarzyć, że nie pamiętamy jakich zmian dokonaliśmy w pliku. Pomocne wtedy jest polecenie:
svn diff
Zwraca ono listę zmian w plikach w formacie unified diff format

4) Cofnięcie zmian
Dopóki nie dokonaliśmy commitu możemy łatwo cofnąć wprowadzone w kopii roboczej zmiany. Używamy polecenia:
svn revert
svn revert [nazwa pliku]
Polecenie bardzo przydatne jeśli przez pomyłkę skasowaliśmy jakiś plik lub rozmyśliliśmy się jeśli chodzi o zmiany.

5) Pobranie aktualnych wersji plików
Tak, tak. Po raz kolejny wykonujemy update by sprawdzić czy nikt inny nie dokonał zmian w tych samych plikach co my. W większości wypadków Subversion bez problemu poradzi sobie z wprowadzeniem odpowiednich zmian. Problem pojawi się gdy okaże się, że ktoś edytował ten sam fragment pliku co my. Subversion nie jest w stanie samemu zaktualizować pliku i pojawia się konflikt (pamiętacie literkę 'C' w svn update?)

6) Rozwiązywanie konfliktów
W momencie powstania konfliktu Subversion tworzy 3 nowe pliki i modyfikuje plik będący w konflikcie. Trzy nowe pliki to:
plik.mine - wersja pliku z naszymi zmianami
plik.rOLDREV - gdzie OLDREV to numer rewizji sprzed naszych zmian
plik.rNEWREV - gdzie NEWREV to numer rewizji aktualnej wersji w repozytorium (ze zmianami wprowadzonymi przez kogoś innego)
W pliku będącym w konflikcie dopisane zostają dodatkowe linijki z zaznaczonym konflikotwym fragmentem w formie:
linia niezmieniona
<<<<<<< .mine
linia zmieniona przeze mnie
=======
linia zmieniona przez kogoś
>>>>>>> .rNEWREV
linie niezmieniona

Po skontaktowaniu się z osobą, która wprowadziła swoje zmiany poprawiamy plik by zawierał ostateczną wersję (edytując go odpowiednio lub używając jednego z 3 plików jako wzoru) i wykonujemy polecenie:
svn resolved [nazwa pliku]
Subversion przygotuje plik i konflikt zostanie rozwiązany przy najbliższym commicie. Przy okazji skasowane zostaną trzy dodatkowe pliki (.mine, rOLDREV, .rNEWREV)

7) Wysłanie zmian do repozytorium
Gdy mamy już aktualne wersje plików i nie ma konfliktów wreszcie możemy wysłać zmiany do repozytorium za pomocą polecenia:
svn commit
Przy wysyłaniu commitu musimy dodać komentarz z opisem, który zostanie dołączony do logów. Jeśli użyjemy polecenia commit w formie jak powyżej otworzy się domyślny edytor tekstu, w którym możemy wpisać komentarz. Możemy również użyć polecenie w formie:
svn commit -m "treść komentarza"
Rzecz jasna by wykonać to polecenie musimy nawiązać połączenie z repozytorium.

W tym momencie możemy rozpocząć nasz cykl pracy od początku.


O kolejnych, bardziej zaawansowanych funkcjach Subversion w kolejnych odcinkach cyklu.
piątek, 07 grudnia 2007
1. Wersje pod kontrolą - wstęp do wersjonowania plików
2. Subversion - podstawowe pojęcia
3. Subversion - instalacja i tworzenie repozytorium
3. Subversion - instalacja i tworzenie repozytorium
4. Subversion - podstawy pracy z wersjonowanymi plikami
5. Subversion - zaawansowane komendy
6. TortoiseSVN - graficzny klient SVN
7. RabbitVCS + Meld - integracja Subversion z Nautilusem
8. VisualSVN Server - prosta instalacja serwera Subversion
9. SVN4MSOffice - potęga Subversion w MS Word

Instalacja Subversion

By zainstalować Subversion na naszym komputerze wchodzimy na stronę projektu, wybieramy dział download by pobrać i uruchomić instalator dla naszego systemu operacyjnego. Instalator prowadzi za rękę i nie powinno być z tym najmniejszego problemu.

Lokalny serwer Subversion

Mamy tutaj dwie możliwości:
  • dostęp za pomocą protokołu svn bezpośrednio do serwera SVN
  • dostęp za pomocą protokołu HTTP lub HTTPS z wykorzystaniem serwera Apache
Każde z tych rozwiązań ma swoje wady i zalety (są dokładnie opisane w dokumentacji). Ja wybrałem rozwiązanie prostsze czyli dostęp bezpośredni do serwera.
W zasadzie można również wykorzystać bezpośredni dostęp do plików repozytorium, jednak jest to zdecydowanie niepolecane rozwiązanie.

Serwer Subversion jako usługa Windows

Dzięki zarejestrowaniu serwera SVN jako usługi Windows nie musimy pamiętać aby za każdym razem uruchamiać serwer. Uruchomi się wraz ze startem systemu. Wystarczy w konsoli wpisać:
> sc create svn
binpath= "[ścieżka katalogu SVN]\bin\svnserve.exe --service -r [ścieżka do katalogu z repozytoriami]"
displayname= "Subversion Server"
depend= Tcpip
start= auto
Jeśli zainstalowaliśmy SVN w Program Start trzeba wpisać ścieżkę w ten sposób:
binpath= "\"C:\program files\svn\bin\svnserve.exe\" --service -r [ścieżka do katalogi z repozytoriami]"
i gotowe! [ścieżka do katalogi z repozytoriami] to katalog, w którym będziemy tworzyć repozytoria dla poszczególnych projektów, np: D:\SVN-repos

Utworzenie repozytorium

Skoro serwer już działa czas na utworzenie repozytorium. Udajemy się do katalogu w którym będziemy tworzyć repozytoria (tu niech będzie to D:\SVN-repos) i wykonujemy:
D:\SVN>svnadmin create [nazwa repozytorium]
Jeśli wszystko działa jak należy utworzony został folder o nazwie takiej jak nazwa repozytorium. Teraz pora ustawić prawa dostępu do repozytorium. Wchodzimy do katalogu z repozytorium, do katalogu conf i edytujemy następujące pliki:
W pliku svnserve.conf w części [general] powinno się znaleźć:
[general]
anon-access = read
auth-access = write
password-db = passwd
A w pliku passwd dopisujemy:
[login] = [hasło]

Import projektu do repozytorium

Cóż ro za repozytorium bez wersjonowanych plików. Tu pojawia się ważna kwestia układu plików w repozytorium (lub repozytoriach)
1. Wspólne repozytorium dla wielu projektów
To rozwiązanie jest dobre dla projektów, które są ściśle ze sobą powiązane. Pliki w repozytorium mogą być ułożone tak:

Projekt1/
    trunk/
    tags/
    branches/
Projekt2/
    trunk/
    tags/
    branches/

lub tak:

trunk/
    Projekt1/
    Projekt2/
tags/
    Projekt1/
    Projekt2/
branches/
    Projekt1/
    Projekt2/

Trzeba pamiętać, że numery rewizji są wspólne dla całego repozytorium. To znaczy każdy commit zwiększa numer o jeden bez względu na to, którego projektu dotyczy. Z drugiej strony uzyskujemy dużą łatwość w przenoszeniu plików pomiędzy projektami.

2. Osobne repozytorium dla każdego projektu
Rozwiązanie korzystne dla niezależnych projektów. Numery rewizji zmieniają się tylko w obrębie projektu. Tworzymy wtedy repozytorium o nazwie takiej jak nazwa projektu i zaimportujemy katalogi:
trunk/
tags/
branches/

Jeśli chcemy zaimportować do repozytorium istniejący już projekt najlepiej umieścić istniejące pliki w folderze trunk
By zaimportować pliki przechodzimy do katalogu głównego projektu (czyli np: D:\Projekty\projekt1 gdzie znajdują się katalogi trunk\[pliki projektu] , tags\ i branches\) i wykonujemy polecenie:
svn import svn://localhost/[nazwa repozytorium] -m 'Initial import'
gdzie po -m wpisaliśmy komentarz, który pojawi się w logu. Jeśli nie dodamy -m '[Komentarz]' pojawi się okienko Notatnika (lub innego domyślnego edytora tekstu), gdzie będziemy mogli wpisać komentarz.

Utworzenie kopii roboczej

Pliki mamy już w repozytorium. Pora utworzyć kopię roboczą.

UWAGA!
Jeśli nie jesteśmy pewni czy wszystko robimy dobrze najpierw przetestujmy przedstawione komendy na dowolnych plikach a nie od razu na ważnych dla was plikach. Jeśli nie jesteś pewien zawsze możesz wykonać polecenia svn help i svnadmin help by poznać szczegóły działania komend. Żeby potem nie było na mnie jeśli coś pójdzie nie tak i stracicie ważne dane!

Kasujemy folder zawierający projekt. Przechodzimy do folderu, w którym ma się znaleźć kopia robocza (np: D:\Projekty\) i wykonujemy polecenie:
svn checkout svn://localhost/[nazwa repozytorium]/trunk [nazwa projektu]
Utworzony zostanie folder o nazwie [nazwa projektu] zawierający wszystkie pliki z katalogu trunk z repozytorium (czyli wszystkie zaimportowane wcześniej pliki). Warto zauważyć, że we wszystkich wersjonowanych folderach pojawił się ukryty folder .svn zawierający wszystkie dane potrzebne do właściwego wersjonowania plików.


Ufff.... Jako, że wpis zrobił się o wiele dłuższy niż przewidywałem podstawowe komendy i opis sposobu korzystania z wersjonowanych plików w następnym odcinku.
czwartek, 06 grudnia 2007

1. Wersje pod kontrolą - wstęp do wersjonowania plików
2. Subversion - podstawowe pojęcia
3. Subversion - instalacja i tworzenie repozytorium
4. Subversion - podstawy pracy z wersjonowanymi plikami
5. Subversion - zaawansowane komendy
6. TortoiseSVN - graficzny klient SVN
7. RabbitVCS + Meld - integracja Subversion z Nautilusem
8. VisualSVN Server - prosta instalacja serwera Subversion
9. SVN4MSOffice - potęga Subversion w MS Word

Subversion

W jednym z poprzednich wpisów pisałem o pożytkach z systemu kontroli wersji. Dziś, zgodnie z zapowiedzią, słów kilka o Subversion (w skrócie SVN). Dlaczego akurat ten system, a nie któryś ze sporej rzeszy konkurentów? Ponieważ SVN jest:

  • darmowy
  • wieloplatformowy
  • stosunkowo prosty w obsłudze
  • popularny
  • open-source'owy
  • istnieje wiele programów oferujących wsparcie dla SVN i ułatwiających pracę z tym systemem kontroli wersji
  • jest dużo materiałów poświęconych SVN (a ten wpis jest kolejnym z nich)
  • łatwo skonfigurować własny serwer SVN (lub jako rozszerzenie dla Apache'a)

Na początek wypadałoby się zapoznać z terminologią.

Słowniczek podstawowych pojęć

  • Repozytorium (repository) - foldery i pliki znajdujące się na serwerze SVN. Zawiera całą historię zmian (kolejne rewizje). Można powiedzieć, że to taki system plików z dodatkowym wymiarem - czasem.
  • Rewizja (revision) - stan systemu plików po wykonaniu określonej liczby commitów. Oznaczany kolejnymi numerami. Każdy commit powoduje zwiększenie numeru wersji o 1. W celu oszczędzania miejsca i ilości przesyłanych danych wysyłane, pobierane i składowane są jedynie różnice pomiędzy plikami.
  • Head - najnowsza rewizja (powstała po ostatnim commicie).
  • Kopia robocza (working copy) - zestaw plików pobranych z repozytorium, mogą pochodzić z dowolnej gałęzi, czy też rewizji. Zmian na plikach dokonujemy pracując na kopii roboczej, w każdej chwili możemy cofnąć wszelkie zmiany, wysłać je do repozytorium lub pobrać aktualizację plików z repozytorium.
  • Checkout - pobieranie plików z repozytorium w celu utworzenia kopii roboczej.
  • Trunk (gałąź główna) - główna linia rozwojowa projektu. Przyjmuje się, że pliki w głównej gałęzi powinny się kompilować.
  • Branch (gałąź rozwojowa) - kopia plików, która będzie podlegać alternatywnej ścieżce rozwoju. Na przykład chcąc zmodyfikować pojedynczy moduł lub rozwiązując jakiś problem tworzymy osobny branch, a później scalamy dokonane tam zmiany z główną linią rozwojową (trunk).
  • Tag (etykieta) - kopia plików będąca jakby "zdjęciem" (snapshot) systemu plików w określonej wersji. Taguje się na przykład stan systemu dla kolejnych wydań. Zwyczajowo tagi traktuje się jako read-only (tylko do odczytu).
  • Switch - zmiana gałęzi lub wersji plików w kopii roboczej (np z trunk do którejś z gałęzi rozwojowych).
  • Update - pobranie zmian pomiędzy aktualną kopią w repozytorium a kopią roboczą i aktualizacja plików kopii roboczej.
  • Commit - wysłanie do repozytorium lokalnie dokonanych zmian (w kopii roboczej) - aktualizacja plików w repozytorium.
  • Scalanie (merge) - scalanie zmian dokonanych w różnych gałęziach rozwojowych.
  • Kolizja (collision) - sytuacja w której równolegle dokonano różnych zmian w tym samym fragmencie pliku i SVN nie jest w stanie dokonać samodzielnie scalenia plików. Należy wtedy zdecydować, która ze zmian jest właściwa.
  • Właściwości (properties) - dodatkowe właściwości dla plików i katalogów znajdujących się w repozytorium. Przykładem może być atrybut svn:ignore zawierający listę plików/folderów nie podlegających wersjonowaniu, czy też svn:author zawierający autora zmiany.
  • Log - dziennik zmian, wraz z komentarzami. Pozwala na śledzenie kto wprowadził zmiany, jakie i kiedy.

Na dzisiaj chyba wystarczy. W kolejnym odcinku o instalacji Subversion i podstawowych komendach.

Linki:
http://subversion.tigris.org/ - strona główna projektu Subversion
http://svnbook.red-bean.com/ - oficjalny podręcznik SVN
http://en.wikipedia.org/wiki/Revision_control - najważniejsze pojęcia w systemach kontroli wersji
http://en.wikipedia.org/wiki/Subversion_(software) - o SVN w wiki
http://www.gajdaw.pl/varia/subversion-system-kontroli-wersji-tutorial/ - poradnik o SVN oraz TortoiseSVN

niedziela, 02 grudnia 2007
Wczoraj siedząc nad kawałkiem kodu odkryłem coś co mnie zaskoczyło. Nie miałem pojęcia, że coś takiego można zrobić z użyciem Generics'ów
class FooA {
void fooA() {}
}

class FooB extends FooA {
void fooB() {}
}

class Bar < T extends FooA >{
protected T t;

void bar() {
t.fooA();
}
}

class BarB extends Bar < FooB >{

void bar() {
t.fooB(); /* !!! */
}
}
Chodzi mi o wywołanie t.fooB w klasie BarB
Kompilowane w Javie 6 jeśli to ma jakieś znaczenie.
Może to jest oczywiste i jasno wynika ze specyfikacji genericsów, ale jakoś wcześniej o takim zastanowieniu nie myślałem. Głównie korzystałem z genericsów do parametryzowania kolekcji. A to daje całkiem nowe możliwości.
Może komuś się przyda
11:01, kosciak1 , Dev
Link Dodaj komentarz »
Spis Treści
Kanały RSS
Add to Google
Add to Netvibes