#!/bin/nwkr devblog

Moi znajomi znali mnie dotychczas z tego, że lubiłem system Windows do tego stopnia, że nigdy nie przesiadłbym się dobrowolnie na Linuksa do codziennej pracy. Cóż mogę mieć na Linuksie, jeśli tylko kłopoty z niedziałającymi urządzeniami oraz konfigurowaniem wszystkiego w plikach konfiguracyjnych o zakręconej składni.

Pierwszy kontakt z Linuksem na desktopie miałem około 7 lat temu. Był to Aurox Linux, dystrybucja ponoć dostosowana do polskich realiów. Tę przygodę zapamiętałem za sprawą problemów ze sprzętem. Myszka i inne urządzenia USB przestawały działać po wejściu w program wyświetlający graficznie podział dysku na partycje. Po roku miałem też kontakt z Red Hatem, który również mnie nie poruszył. Wtedy ostatecznie pożegnałem się z Linuksem na moim domowym komputerze, uznając go za system dla ludzi, którzy lubią tracić czas na robienie czegoś, co w Windowsie działa od początku albo można bardzo prosto osiągnąć.

Nadmienię, że uznając Linuksa jako system nienadający się na komputer domowy, nie odrzuciłem go jako systemu na serwery. Przeciwnie, na kupionym przeze mnie serwerze rackowym (połowa roku 2007) zainstalowałem Slackware Linux. Poruszałem się w mrocznych klimatach basha (później zsh) dość dobrze i ceniłem sobie stabilność i przewidywalność takiego „serwerowego” Linuksa. Windows byłby ostatnim systemem, jaki postawiłbym na serwerze. Niemniej jednak, na komputer domowy Linuksa nie uznawałem.

Niespodziewany zwrot akcji

Historia zaczęła pisać się na nowo wraz z rozpoczęciem pracy w firmie Spartez. Dostałem jakiegoś blaszaka oraz polecenie przygotowania sobie środowiska pracy. Początkowo chciałem sobie zainstalować FreeBSD, które to kolega kwiat wręcz miłuje, lecz poszedłem łatwiejszą drogą. Jeden z kolegów w pracy miał przy sobie płytę instalacyjną Ubuntu 9.04, więc nie kombinowałem i zainstalowałem, co było.

Pierwsze wrażenie było pozytywne, ale ono jest tak naprawdę najmniej znaczące – liczy się to, co będzie później. Nie miałem czasu na zbytnie dostosowywanie Gnoma do swoich potrzeb i przyzwyczajeń. Przeleciałem szybko po wszystkich apletach w preferencjach i ustawiłem najważniejsze rzeczy. Potem zainstalowałem dodatkowe oprogramowanie, głównie z repozytorium, ale też trochę zewnętrznego. I zacząłem pracę.

Miesiąc później…

Kolejny dzień w pracy, kolejne rzeczy do zrobienia. Linux sobie nadal stoi i w pełni zastępuje mi Windowsa. Nie powoduje mi przy tym żadnych problemów. W domu zaś troszkę brakuje mi fajnych apletów z Gnoma, apt-geta jako banalnego sposobu na szukanie i instalowanie oprogramowania oraz konsoli, w której można wykonać rzeczy, które graficznie robiłoby się kilka razy dłużej. Coraz bardziej myślałem o migracji…

Linux w domu

Po 1,5 miesiąca praktycznie codziennej pracy z Ubuntu 9 byłem już na tyle przekonany do tego systemu, że zdecydowałem się na migrację na Linuksa w domu. W domu mam dość nowoczesny sprzęt i obawiałem się, że może nie być tak kolorowo, jak było w pracy. Uruchomiłem więc najpierw system z LiveCD, jednak wszystko wydawało się poprawnie działać. Natrafiłem tylko na jeden problem – przy pracy z dwoma monitorami okienka działały dość wolno. Porównywalnie do Windowsa bez sterowników karty graficznej. Nie przejąłem się tym jednak – myślałem, że może to być wina odpalenia systemu z płyty CD. Po instalacji problem nadal występował, jednak dzięki pomocy kolegi whr-a, zapalczywego maniaka Emacsa, zainstalowałem najnowszy sterownik Intela, dostowałem xorg.conf i na tym skończyły się problemy.

W domu Linux również się sprawdza. Oprogramowania zastępczego również jest dużo, znakomitą większość udało mi się zastąpić równoważnym pod względem funkcjonalności oprogramowaniem. Tylko dla jednego programu nie znalazłem substytutu – programu pocztowego The Bat!, który towarzyszy mi już co najmniej 10 lat, i oferuje funkcjonalność, o jakiej KMail, Evolution i Thunderbird nawet nie śniły. Program pocztowy to w zasadzie wrota do mojego miasta, krytyczny element. Z tym fantem poradziłem sobie za sprawą VirtualBoksa i na trzecim obszarze stoi sobie uruchomiony Windows z moim The Batem.

Dodatkowo, dzięki repozytorium i menedżerowi pakietów Synaptic znalazłem kilogramy dodatkowego oprogramowania, o którym nawet nie myślałem wcześniej, a wpadłem na nie przez przypadek. Przykłady: klient Twittera Gwibber, ekranowa linijka, czy program do zaparzania herbaty ;-)

Podsumowanie

Osobista lekcja: Jeśli coś banujesz, banuj na określony czas – nigdy permanentnie – możesz dużo stracić. Przez 7 lat różnica między Linuksami okazała się być ogromna. To, co kiedyś słabo działało, teraz działa dobrze, a przy okazji jest bardziej funkcjonalne i elastyczne. Jeśli więc Linux na biurku nie spodobał Ci się kilka lat temu, wypróbuj go teraz. Jeśli teraz Ci się nie spodoba, wypróbuj za kilka lat.

Niewiele osób wie, jakie są ich prawa jako właścicieli domeny. Znajomość tych praw przydaje się w krytycznym momencie – gdy zbliża się koniec ważności domeny, a koszt przedłużenia u innego rejestratora jest znacznie niższy.

Nabywca po kupnie domeny staje się jej właścicielem. Oznacza to, że ma wyłączne prawo dysponowania nią. Rejestrator jest tylko odpowiedzialny ze techniczną obsługę jego domeny i właściciel domeny w każdej chwili może go zmienić. Najczęściej do transferu domeny do innego rejestratora potrzebny jest tzw. kod authinfo. Wydaje go rejestrator na wniosek właściciela. U tutaj zaczynają się schody – niektórzy rejestratorzy próbują różnych zagrywek, aby nie wydać Ci tego authinfo. Liczą na to, że właściciele nie znają przysługujących sobie praw lub grają na zwłokę, by w końcu właściciel był zmuszony przedłużyć domenę u niego.

Polskie domeny z NASK

Polskimi domenami zarządza NASK. Każdy rejestrator domen jest de facto pośrednikiem między właścicielem, a NASK. Rejestrator w umowie z NASK zobowiązuje się przestrzegać pewnego regulaminu, który określa m.in. prawa i obowiązki zarówno rejestratora, jak i właściciela domeny. Można tam znaleźć m.in. warunki wydawania authinfo. W skrócie:

1) Partner nie może uzależniać wydania kodu od dodatkowych warunków.

2) Dla swojego bezpieczeństwa sprawdź, czy w danych, służących do kontaktu pomiędzy NASK a Tobą jest wpisany poprawny adres e-mail. W przypadku istotnych zmian dotyczących nazwy domeny, wysyłane jest potwierdzenie ich dokonania na Twój adres poczty elektronicznej (e-mail) np. zmiana danych abonenta nazwy domeny.

Tutaj za typowy przykład może posłużyć CAL.PL. Aby przetransferować domenę każą sobie wysłać faks. Jaki faks? Dyspozycja wydana z adresu e-mail, którym zawsze kontaktuję się z rejestratorem oraz na który zarejestrowana została domena jest wiążąca i wystarczająca.

Domeny ICANN (domeny globalne .COM, .NET, .ORG i inne)

W przypadku domen globalnych, rejestratora obowiązuje Uniform Domain Name Dispute Resolution Policy. Czytamy:

3) Cancellations, Transfers, and Changes. We will cancel, transfer or otherwise make changes to domain name registrations under the following circumstances:

a) subject to the provisions of Paragraph 8, our receipt of written or appropriate electronic instructions from you or your authorized agent to take such action;

Reasumując, wystarczy pisemna lub, co nas bardziej interesuje, elektroniczna dyspozycja.

Domeny IANA (.US, .BIZ i inne)

Domeny amerykańskie są zarządzane przez firmę NeuStar na zlecenie IANA. Zasady transferu tych domen można przeczytać w tym pliku PDF, zaś zasady autoryzacji tutaj. Swoją uwagę należy zwrócić na drugi dokument, który opisuje, w jaki sposób można stwierdzić, że dyspozycja wydania kodu authinfo pochodzi od właściciela domeny. Interesuje nas ten fragment:

In the event that the Gaining Registrar relies on an electronic process to obtain this authorization the acceptable forms of identity would include:

• [...]

• Consent from an individual or entity that has an email address matching the Registered Name Holder’s email address.

Registered Name Holder to, po prostu, dane właściciela domeny – w tym jego adres e-mail. Dyspozycje wydawane z tego adresu e-mail uważa się więc za dyspozycje właściciela domeny.

Kilka porad

Sprawdź, czy firma, która obsługuje Twoje domeny rzeczywiście jest rejestratorem (poleceniem whois). Często zdarza się, że firmy hostingowe nie mają na początek tyle pieniędzy, aby stać się autoryzowanym partnerem NASK (czy też innego zarządcy domen). Jeśli nie jest, w sprawie transferu nawet nie kontaktuj się z tą firmą. Formalnie – obsługuje Cię tamten rejestrator.

Taki przypadek spotkał mnie z CAL.PL i transferem domeny US. Firma INFO-CAL, standardowo, wymaga wysłania faksu w celu transferu domeny. Ja zaś faksu nie posiadam, a biegać na pocztę albo do znajomych zamiaru nie miałem. Mimo moich dosadnych próśb o wydanie kodu authinfo i popartych zasadami rejestratora, kodu authinfo wydać nie chcieli.

Narzędzie whois wskazało, że rejestratorem jest ResellOne.net. W takim wypadku rzeczywiście nie mieli nic do stracenia – wszak nie są rejestratorem, tylko pośrednikiem. Skontaktowałem się więc bezpośrednio z ResellOne.net z prośbą o wydanie kodu authinfo – oczywiście pisałem z adresu, na który zarejestrowana była domena. Kod authinfo otrzymałem tego samego dnia, wysłany był o godzinie 9:30 czasu amerykańskiego. Nikt nawet nie pytał o zdanie CAL.PL – to ja jestem właścicielem domeny.

Dzisiaj w trakcie pracy nad Scrumowym pluginem dla Atlassian JIRA odczułem głęboką potrzebę skonfigurowania Mavenowego skryptu budowania w taki sposób, aby wszystkie wystąpienia tokena ${plugin.version} zostały zamieniane na pewien ciąg znaków jeszcze przed kompilacją.

Moim celem jest stworzenie paczek JAR dwóch różnych wersji JIRA Scrum Cards Print Plugin – jednej freeware’owej i drugiej – komercyjnej. Różnica między nimi jest taka, że komercyjna ma więcej możliwości, m.in. na karteczkach można wstawić logo swojej firmy. Od strony kodu wygląda to tak, że wywołuję Config.getInstance(“freeware”), aby otrzymać konfigurację dla wersji darmowej oraz odpowiednio Config.getInstance(“commercial”) dla wersji płatnej. Wersja darrmowa ma zaszyte w konfiguracji logo firmy Spartez na stałe, zaś komercyjna wyciąga logo klienta z konfiguracji pluginu w administracji Atlassian JIRA.

Jako, że nie chcę tworzyć dwóch osobnych projektów tylko z powodu zmiany w jednej linii kodu, podmiana tokena przed kompilacją wydaje się być najrozsądniejsza. Można co prawda kombinować z nadaniem svn:external i ustawieniem zależności na część wspólną kodu, ale jest to rozwiązanie trudniejsze. I chyba nawet niedostosowane do niewielkiego rozmiaru problemu.

Ostatecznie, token ${plugin.version} w linii Config.getInstance(“${plugin.version}”) zostanie zamieniony na pożądany tekst, freeware lub commercial, w zależności od tego jaką paczkę JAR chcę w danej chwili otrzymać.

Rozwiązanie

<project ...>

    [...]

    <properties>
        [...]
        <token.example>Atlassian JIRA</token.version>
        <token.nwkr>Damian Nowak</token.nwkr>
    </properties>

    <build>
        <resources>
            <!-- Nie możemy porzucić wartości z parent pom-ów, dlatego trzeba prześledzić rodziców i umieścić ich zawartość tutaj. -->
            <!-- W moim przypadku zawartość ~/.m2/repository/com/atlassian/pom/atlassian-plugin-pom/9/atlassian-plugin-pom-9.pom poniżej. -->
            <resource>
                <directory>src/main/resources</directory>
                <filtering>true</filtering>
                <includes>
                    <include>atlassian-plugin.xml</include>
                </includes>
            </resource>
            <resource>
                <directory>src/main/resources</directory>
                <filtering>false</filtering>
                <excludes>
                    <exclude>atlassian-plugin.xml</exclude>
                </excludes>
            </resource>
            <!-- Koniec -->
            <resource>
                <directory>src/main/java</directory> <!-- Ścieżka, wewnątrz której wszystkie wystąpienia zostaną zamienione -->
                <filtering>true</filtering>
                <targetPath>../filtered-sources/java</targetPath>
            </resource>
        </resources>
        <sourceDirectory>target/filtered-sources/java</sourceDirectory>
    </build>
</project>

Teraz każde wystąpienie ${token.example} zostanie zastąpione przez Atlassian JIRA, a ${token.nwkr} przez Damian Nowak. Trzeba tylko uważać, by przypadkiem nie wskazać ścieżki, wewnątrz której znajdują się dane binarne. Może to skutkować ich uszkodzeniem. ;-) Nie zapomnij też dodać ścieżki target/filtered-sources na listę wykluczeń z buildu. Jeśli tego nie zrobisz, IntelliJ IDEA będzie zgłaszała błąd o duplikujących się klasach.