Konwersja cdr, ai, eps do svg

Nie jestem grafikiem, a do tego pracuję na Linuksie. Nie mam tej całej palety programów graficznych jak Photoshop, Adobe Illustrator czy CorelDRAW. Zazwyczaj mi to nie przeszkadza bo jeśli nawet dostaje jakiś layout do pocięcia to zlecam tę robotę innym. Do drobnych prac graficznych starcza mi Gimp, a niekiedy nawet edytor grafiki online Pixlr.

Niekiedy jednak trafiają mi się logotypy w formacie pliku AI (Adobe Illustrator Artwork), EPS (Encapsulated PostScript – Photoshop), CDR (CorelDRAW), a nawet PDF (Portable Document Format). Gimp poradzi sobie z plikami EPS choć nie najlepiej? Lepiej w tym wypadku sprawdzi się edytor grafiki wektorowej Inkscape, który zaimportuje pliki we wszystkich wyżej wspomnianych formatach i umożliwi ich zapisanie w domyślnym formacie SVG (Scalable Vector Graphics) lub też jako PNG albo XCF (natywny format Gimpa). Export do formatu XCF – co ważne – wykonywany jest z zachowaniem warstw. Inkscape umożliwia zapis pliku w wielu jeszcze innych formatach i jest dostępny w wersjach na Linuksa, Windowsa i Mac-a.

Jeśli mamy do czynienia z większą liczbą plików do przekonwertowania to wygodniejszym rozwiązaniem okazuje się skrypt uruchamiany z linii komend. Niestety funkcjonalność Inkscape-a jest ograniczona z poziomu konsoli dlatego warto sięgnąć do innych wyspecjalizowanych w tym względzie narzędzi takich jak uniwersalny translator grafiki wektorowej – Uniconvertor lub też translator plików Post Script i PDF do innych formatów grafiki wektorowej – Pstoedit. W Ubuntu oba programy dostępne są w repozytoriach i można je zainstalować za pośrednictwem apt-get -a

sudo apt-get install python-uniconvertor pstoedit

Ich użycie jest najprostsze z możliwych i ogranicza się do podania kolejno ścieżki do pliku źródłowego i ścieżki wynikowej.

uniconvertor logo.cdr logo.svg

i analogicznie dla pstoedit

pstoedit logo.eps logo.svg

Bazaar uzupełnieniem SVN-a

Subversion – jeden model pracy
=======================

Najbardziej popularnym systemem wersjonowania jest [Subversion](http://subversion.tigris.org/). Został on zaprojektowany do pracy w sposób scentralizowany. Działa to tak, że gdzieś na serwerze znajduje się centralne repozytorium z którego programista pobiera kopię roboczą na swój lokalny komputer. Dokonuje modyfikacji plików po czym zatwierdza dokonane zmiany w repozytorium centralnym. Taki model pracy ma swoje zalety jednak zdarzają się sytuacje kiedy przydała by się lokalna wersja repozytorium. Poczciwy SVN nie daje jednak możliwości pracy w sposób rozproszony co jest jego wielką słabością w stosunku do np. [Gita](http://git-scm.com/) czy [Bazaar-a](http://bazaar.canonical.com/en/), które dzięki swojej elastycznej architekturze oferują wiele przeróżnych sposobów organizacji pracy z repozytorium.

Modele pracy są jednym z wielu argumentów, dla których warto rozważyć przesiadkę na inny system kontroli wersji. Polecam zapoznać się z artykułami [Why Switch to Bazaar? – Any Workflow](http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html#any-workflow) albo [Workflows – Bazaar Version Control](http://wiki.bazaar.canonical.com/Workflows) oraz [Why Git is Better than X – Any Workflow](http://whygitisbetterthanx.com/#any-workflow).

Ja pracuję już kilka lat z Subversion i większość firm z którymi współpracuję lub też współpracowałem też używa SVN. Dlatego decyzja o zmianie systemu wersjonowania najczęściej nie leży w mojej gestii.

Co mogę zatem zrobić? Zarówno Bazaar ([bzr-svn](https://launchpad.net/bzr-svn)) jak i Git ([git-svn](http://www.kernel.org/pub/software/scm/git/docs/git-svn.html)) mają narzędzia umożliwiające współpracę z Subversion.

Po co łączyć Subversion z Bazaarem lub Gitem
==================================

Model pracy rozproszonej oferuje kilka możliwości stanowiących doskonałe uzupełnienie modelu scentralizowanego.

* Słabe połączenie internetowe albo jego brak nie jest problemem ponieważ wszelkie zmiany dokonywane są lokalnie. Połączenie z serwerem centralnym potrzebne jest jedynie raz na jakiś czas.
* Niezależne repozytorium, odseparowane i nienarażone na zmiany czynione przez innych użytkowników daje możliwość eksperymentowania. Dokonane zmiany w przypadku powodzenia można później scalić z główną gałęzią lub też usunąć nie zaśmiecając historii zmian centralnego repozytorium.
* Można ustalić procedurę zgodnie z którą zmiany dokonane w projekcie przez developera trafiają najpierw do osoby nadzorującej projekt, która je sprawdza, testuje i dopiero po akceptacji pcha da SVN-a. W ten sposób do centralnego repozytorium trafią jedynie zmiany stabilne.
* Warto też wspomnieć o takim prozaicznym powodzie jak brak upierdliwych katalogów „.svn” w katalogu roboczym projektu – małe a cieszy :D.

Praca z Bazaarem jako uzupełnieniem Subversion
======================================

Importowanie repozytorium
————————–

Ja wybrałem Bazaar z uwagi na moje większe doświadcznie z tym systemem kontroli wersji.

Dla tych, którzy nie mieli jeszcze styczności z Bazaarem proponuję na start prosty tutorial [Bazaar in five minutes](http://doc.bazaar.canonical.com/bzr.2.1/en/mini-tutorial/index.html). Jeśli chodzi o naukę to Bazaar ma tę przewagę nad Gite, że większość jego komend jest identyczna z tymi znanymi z SVN.

Jeśli nie mamy jeszcze zainstalowanego Bazaara (bzr) oraz wtyczki umożliwiającej współpracę z Subversion bzr-svn to w przypadku Ubuntu wystarczy jedynie pobrać wyżej wspomniane z repozytorium i zainstalować.

sudo apt-get install bzr bzr-svn

W przytoczonym wyżej tutorialu nowe repozytorium tworzy się poprzez komendę bzr init. W tym przypadku nie ma takiej potrzeby. Aby „zaimportować” repozytorium SVN do Bazaara należy utworzyć tzw. brancha. Zakładam że znajdujemy się w katalogu roboczym, w którym trzymamy projekty (workspace). Wywołujemy komendę bzr branch i podajemy jako parametry url repozytorium svn oraz nazwę katalogu jaki zostanie stworzony na naszym komputerze i w którym zostanie utworzone lokalne repozytorium Bazaara.

bzr branch svn+http://svn-repository.example.com/project/trunk ./project

Od tego momentu można już pracować z Bazaarem. Dostępna jest pełna historia zmian i jakby się uprzeć to można zapomnieć o SVN-ie 😉 (choć do właściwego importu SVN do Bazaar służy komenda bzr svn-import) Dostępne mamy zarówno narzędzia konsolowe, jak też całą kolekcję GUI z których niejako firmowym jest multoplatformowy [Bazaar Explorer](http://doc.bazaar.canonical.com/explorer/en/). Fanom Eclipse polecam z kolei [plugin do obsługi Bazaara](https://launchpad.net/bzr-eclipse), który niczym nie ustępuje swojemu odpowiednikowi dla Subversion.

Pracujemy w ten sposób, że wszelkie zmiany w plikach zatwierdzamy (commit) do lokalnego repozytorium. Kiedy zmiany w projekcie przyjmują już stabilną postać jesteśmy gotowi do zarejestrowania wprowadzonych poprawek w centralnym repozytorium SVN. Zanim to jednak zrobimy należy najpierw sprawdzić czy od czasu ostatniego pobrania zmian z SVN coś się nie zmieniło. W końcu najczęściej nie pracujemy sami. Wchodzimy do katalogu naszego projektu i wywołujemy:

Warto sprawdzić czy coś się zmieniło?
————————————

bzr pull svn+http://svn-repository.example.com/project/trunk

Jeśli pracujesz w zespole, a poprawka którą miałeś zrobić nie była mała to najprawdopodobniej otrzymasz komunikat, że w repozytorium dokonano zmian. Trzeba je będzie sprawdzić, scalić z lokalnymi zmianami i ponownie zatwierdzić. Bazaar podpowie Ci co masz zrobić.

bzr: ERROR: These branches have diverged. Use the missing command to see how.
Use the merge command to reconcile them.

Scalanie różnic jest proste
————————-

Jeśli inni developerzy nie edytowali tych samych plików co ty to zazwyczaj wystarczy:

Do podejrzenia różnic

bzr missing

Do scalenia zmian

bzr merge

Następnie przydałoby się sprawdzić jakie pliki różnią się względem lokalnego repozytorium po scaleniu ze zmianami dokonanymi w repozytorium centralnym

bzr status

Po ich zatwierdzeniu

bzr commit -m 'Treść komunikatu'

Zostaje już tylko wysłanie wszystkiego do svn.
——————————————–

bzr push svn+http://svn-repository.example.com/project/trunk

UWAGA! append_revisions_only error
———————————–

W tym momencie najprawdopodobniej wyskoczy Ci mały Zonk i otrzymasz taki niemiły komunikat

Using saved push location: svn+http://svn-repository.example.com/project/trunk
bzr: ERROR: Operation denied because it would change the mainline history. Set the append_revisions_only setting to False on branch "svn+http://svn-repository.example.com/project/trunk" to allow the mainline to change.

Niestety komunikat Bazaar nie jest w tym wypadku wyczerpujący gdyż nic nie mówi na temat tego gdzie ustawić append_revisions_only na false.

W Ubuntu wyedytuj plik ~/.bazaar/subversion.conf i dodaj wspomnianą dyrektywę pod adresem repozytorium SVN

[4ef181b9-d188-42c4-ae88-58g6dfg8760b]
locations = svn+http://svn-repository.example.com/project/trunk
append_revisions_only = False

To powinno załatwić sprawę.

Uwaga konflikt!
————–

To był optymistyczny scenariusz. W mniej pomyślnej sytuacji dokonasz zmian w tym samym pliku w którym ktoś inny grzebał i to najprawdopodobniej w tych samych liniach. Automat tego nie rozwiąże. Załóżmy, że chodzi o plik „foo.py”. Pojawia się konflikt a problematyczny plik doznaje cudownego rozmnożenia.

1. foo.py.BASE – plik w wersji pozbawionej zmian powodujących konflikt (w svn foo.py.rOLDREV)
2. foo.py.OTHER – plik ze zmianami dokonanymi przez innego użytkownika (w svn foo.py.rNEWREV)
3. foo.py.THIS – plik z moimi lokalnymi zmianami (w svn foo.py.mine)
4. foo.py – zawiera to samo co foo.py.THIS

Kilka słów od Kdiff3 – bez niego moje życie było by o wiele bardziej skomplikowane
——————————————————————————

Każdy ma swoje ulubione narzędzie do scalania różnic. Ja preferuję Kdiff3 – dostępny na Linuksa i Windowsa. Mimo, że zarówno Eclipse jak i Bazaar Explorer mają swoje narzędzia do porównywania zmian ja staram się użyć Kdiff3 którego interfejs jest mi dobrze znany.

Edycja konfliktu przy użyciu Kdiff3 wymaga wywołania w konsoli komendy

kdiff3 foo.py.BASE foo.py.OTHER foo.py.THIS -o foo.py

Oczywiście nie wszyscy lubią konsolę. Aby np. Bazaar Explorer korzystał z Kdiff3 należy wyedytować plik ~/.bazaar/bazaar.conf i w sekcji DEFAULT dodać.

external_merge = kdiff3 %b %o %t -o %r

Jako ciekawostkę kierując się zawodową uprzejmością podaję też sposób wywołania tortoisemerge.

external_merge = tortoisemerge /base:%b /theirs:%o /mine:%t /merged:%r

Kdiff3 można też zintegrować z Eclipse jednak opcję taką znalazłem jedynie dla Subversion. Należy otworzyć Preferencje->Team->Diff/Merge. W sekcji „Conflict Resolution Program” wybrać opcję „External” i wskazać gdzie leży Kdiff3 (u mnie /usr/bin/kdiff3). W polu parameters należy podać

${base} ${yours} ${theirs}  -o ${merged}

Rozwiązaniem konfliktu należy się pochwalić
—————————————–

Po ręcznym rozstrzygnięciu konfliktów należy Bazaar poinformować o tym – analogicznie jak w svn.

bzr resolve foo.py

Komenda „resolve” usuwa przy okazji pliki foo.py.BASE, foo.py.OTHER oraz foo.py.THIS. Teraz wystarczy już tylko zatwierdzić zmiany (commit) oraz pchnąć do centralnego repozytorium (push).

Dobra rada na koniec
================

Bazaar czy Git to systemy kontroli wersji stworzone do pracy rozproszonej oraz dopracowane pod kątem łączenia osobnych repozytoriów. Mają pod tym względem znaczną przewagę nad Subversion. Model pracy będący mixem korzystającym z rozproszonego repozytorium np. Bazaar oraz centralnego SVN ma swoje zalety jednak stanowi dodatkowy narzut pracy związany z koniecznością dublowania pewnych czynności. Nie należy na siłę wdrażać rozwiązań, które nie są efektywne lub wręcz zbędne. Dlatego jeśli w firmie używającej Subversion stosuje się dopracowane procedury zatwierdzania zmian w repozytorium, nie ma problemów z połączeniem, a modyfikacje w projekcie nie mają charakteru rewolucji będącej jednym wielkim eksperymentem wymagającym tworzenie piaskownicy, być może funkcjonalność Subversion jest w zupełności wystarczająca.

Aktualizacja Kubuntu do wersji 9.10 Karamic Koala

Zwykle podejmuję ryzyko aktualizacji systemu do nowszej wersji choć zawsze wtedy drżę czy wszystko pójdzie dobrze i czy znów nie spędzę paru godzin do doprowadzenia systemu do pełnej używalności.

Ostatnio tj. po aktualizacji do wersji 9.10 Jaunty Jackalope obyło się bez przygód. Byłem w niebo wzięty. Liczyłem, że i tym razem będzie podobnie. Niestety nie. Zaczęło się od tego, że nie mogłem nawiązać połączenia z netem. Nie bardzo rozumiem dlaczego system po aktualizacji gubi wszystkie dotychczasowe ustawienia, ale widać taki jest koszt aktualizacji KNetworkManagera. Niby pojawiło się w tym programie więcej opcji, niby zwiększyła się jego funkcjonalność, ale naprawdę nie wiem od czego zależy jego działanie. Nie dość że raz pokazuje wykryte sieci a innym razem nie to jeszcze już się skonfiguruje połączenie człowiek nie zawsze wie czy już się połączył czy jeszcze nie. Nie wspomnę, że KNetworkManager nie wykrywa rodzaju zabezpieczeń i nie potrafi połączyć się z siecią bezprzewodową z ukrytym SSID. Nie udało mi się skonfigurować połączenia przy zabezpieczeniu WPA2 Personal. Byłem już bliski sięgnięcia po wypróbowanego [WICD](http://wicd.sourceforge.net/) tyle, że bez netu nie mogłem go zainstalować 😉 W końcu udało mi się skonfigurować połączenie na WPA.

Przy wcześniejszych aktualizacjach zdarzało mi się, że musiałem na nowo konfigurować Apache-a lub też PHP. Widać, poradzono sobie z tym jednak ku mojemu zaskoczeniu problem pojawił się w miejscu, w którym absolutnie bym się go nie spodziewał. Po uruchomieniu [Eclipse-a](http://www.eclipse.org/) nagle przestało mi działać wyszukiwanie. Dokładniej rzecz biorąc to przyciski okien dialogowych przestały reagować na kliknięcie całkowicie je ignorując. Zrestartowałem Eclipse-a i nic. Zaciągnąłem sun-owskie środowisko uruchomieniowe sun-java6-jre i też to nic nie dało. W końcu (może powinienem od tego zacząć) sięgnąłem do googla i na [forum Ubuntu](http://forum.ubuntu.pl/) znalazłem [rozwiązanie](http://forum.ubuntu.pl/showthread.php?t=112148&highlight=eclipse). Dlatego właśnie używam tej dystrybucji. Wszelkie problemy szybko znajdują rozwiązanie.

Wracając jednak do Eclipse-a. Do czasu poprawienia błędu napisałem sobie skrypcik **eclipse.sh** ułatwiający uruchamianie eclipsa

export GDK_NATIVE_WINDOWS=1
/opt/eclipse/eclipse

Puki co więcej niespodzianek nie stwierdziłem i ogólnie rzecz biorąc jestem zadowolony z aktualizacji.

Nie wiem czy to tylko subiektywne wrażenie bo nie dokonywałem pomiarów, ale wydaje mi się, że system startuje szybciej. Po uruchomieniu pierwsze co się rzuca w oczy to poprawiony wygląd i usprawnienia w KDE 4.3.

Z dużym zadowoleniem przyjąłem ikonkę powiadomień, która na stałe zagościła na tatce systemowej. Teraz już nie ma problemu z przejrzeniem komunikatów o zdarzeniach mających miejsce w naszym systemie. Można je obejrzeć kiedy już znikną i samodzielnie zadecydować o ich usunięciu. Tego mi brakowało czemu dałem wyraz w jednym z wcześniejszych wpisów.

Cieszy też aktualizacja firefoxa do wersji 3.5, która nota bene powinna nastąpić już parę tygodni temu.

Czytałem, że zmiany nastąpiły co do wyboru domyślnego komunikatora. Ja mam to osobiście gdzieś gdyż używam tlen-a. O ile na Ubuntu nie miałem z nim nigdy większych problemów (nie licząc niedoskonałości wersji beta) o tyle na Kubuntu miałem wręcz permanentny kłopot, kiedy przychodziło do aktualizacji. Zwyczajnie po wpisaniu hasła nic się nie działo i trzeba było ręcznie ściągać nową wersję komunikatora – wiem, że to nie wina programistów Cannonical. Teraz ku mojemu zaskoczeniu aktualizacja po prostu się wykonała :D.

Zauważyłem parę zmian w menadżerze pakietów KPackageKit – zwłaszcza przy aktualizacji. Doceniam przede wszystkim możliwość sortowania wyników alfabetycznie. Do instalowania nowego oprogramowania jakoś mi ten program jednak nie pasuje i dalej sięgam do konsolowego aptitude.

To paradoks ale im dłużej używam Linuksa tym częściej sięgam do konsoli.

Upierdliwości KDE

##Zablokowane aktualizacje w Kubuntu

Komunikat o zablokowanych aktualizacjach w KPackageKit miałem od samego początku. Strasznie mnie irytował, ale ponieważ wszystko co chciałem działało odsuwałem tę drobną niedogodność na później licząc, że w końcu problem sam się rozwiąże. Wiem to naiwne i nieprofesjonalne podejście, ale co dziwne parę razy już się sprawdziło :D.

Minęło już kilka miesięcy (od czerwca), sprawa dojrzała i w końcu wpisałem w googlach „zablokowane aktualizacje”. Rozwiązanie otrzymałem, jak na tacy otwierając już pierwszy link. Wystarczyło wpisać:

sudo aptitude update
sudo aptitude safe-upgrade

Teraz wszystko działa jak trzeba.

##Znikające powiadomienia

W domu używam Kubuntu, ale na komputerze w pracy mam Ubuntu i muszę przyznać, że coraz bardziej się do niego przekonuje. Jakoś ta plasma w KDE4 mnie nie przekonuje. Mimo, że pracuję na tej wersji okien już całkiem sporo to jak muszę coś ustawić to zawsze szukam. Niby wszystko powinno być w settings ale te ustawienia wydają mi się wyjątkowo ubogie. Ostatnio działa mi na nerwy system powiadomień. Informacje pokazują się w jednym miejscu nad tray-em i są grupowane. Przeczytałem gdzieś, że powinna się cały czas pokazywać ikona powiadomień, i że można je jakoś skonfigurować wpływając m.in. na długość wyświetlania. U mnie nie dość, że taka ikona się nie pokazuje to zazwyczaj jak już jakieś info wyskoczy to nim zdążę je przeczytać znika i ni jak nie mogę go wywołać. Jak mnie to wkurza.

##Kopiuj wklej

Kolejną upierdliwością, która negatywnie wpływała na komfort pracy na KDE był problem z kopiowaniem fragmentów tekstów. Jako że programuję, często zdarza mi się zaznaczać fragment tekstu, wciskać Ctrl+C, a następnie stawiając w innym miejscu kursor wklejać tekst za pomocą skrótu Crl+V. Wszystko fajnie tylko, że niekiedy zanim wcisnę to Ctrl+V zaznaczam jeszcze fragment tekstu, który ma zostać nadpisany. I tu wyskakiwał zonk bo zaznaczony tekst automatycznie kopiował się do schowka i po wywołaniu akcji wklejania dostawałem nie to co chciałem. Początkowo myślałem, że to coś nie tak z eclipsem, ale pracując na Ubuntu nic takiego się nie dzieje. Winnym okazał się aplet Klipper. Na [dev.eclipse.org](http://dev.eclipse.org) udało mi się szybko znaleźć odpowiedź:

*You should either deactivate Klipper or uncheck ‚Prevent empty clipboard’ in Klipper’s settings.*

Szerzej problem ten jest opisany w artykule [Fixing Copy-Paste issues on Eclipse and KDE](http://techtavern.wordpress.com/2008/08/10/fixing-copy-paste-issues-on-eclipse-and-kde/)

KVM

Drążąc dalej temat wirtualizacji odkryłem – piszę tak wcześniej zagadnienie to mnie nie interesowało – że w Ubuntu dostępne jest środowisko wirtualizacyjne KVM (Kernel-based Virtual Machine). Oprogramowanie to oparte jest o Qemu z tym, że wkompilowane w jądro Linuksa. W połączeniu z Menadżerem Maszyn Wirtualnych (ang. Virtual Machine Manager) będącym graficznym gui ułatwiającym zarządzanie KVM oraz innymi kompatybilnymi systemami wirtualizacyjnymi, stanowi całkiem przyjemny zestaw narzędzi.

Niestety nie udało mi się z poziomu Menadżera uruchomić wirtualki utworzonej przy pomocy Qemu i musiałem tworzyć dysk na nowo i instalować system od początku. Nie zbadałem jeszcze czy tak jak w przypadku samego Qemu wirtualne dyski da się po prostu kopiować, konwertować i co tam nam jeszcze przyjdzie do głowy. Jedno co fajne to możliwość bieżącego monitorowania poziomu zajęcia pamięci RAM lub obciążenia procesora.

Testy trwają dalej i zobaczymy co z tego wyniknie. Na celowniku mam jeszcze virtual boxa.

Eclipse Galileo

Przesiadka na Eclipse 3.5 Galileo była szybka, prosta i przyjemna. Developerzy eclipsa wpadli na świetny pomysł przygotowując specjalne pakiety dedykowane dla różnych grup programistów. Jeszcze nigdy przygotowanie eclipsa do pracy z PHP nie było tak proste. Wystarczy ściągnąć [Eclipse for PHP Developers](http://www.eclipse.org/downloads/) i mamy od razu do dyspozycji PHP Development Tools (PDT), Web Tools Platform, Mylyn.

Po uruchomieniu Galileo nie dojrzałem jakoś na pierwszy rzut oka wielkich zmian. Pierwsza różnica z jaką będziemy mieli okazję się zapoznać to zmiana w interfejsie do instalacji i aktualizacji nowego oprogramowania. 5 sek. konsternacji i już po chwili wiedziałem co i jak.

Ja osobiście do pracy potrzebuję jeszcze kilku innych plugin-ów. Do najważniejszych z nich należą:

[Subclipse](http://subclipse.tigris.org/servlets/ProjectProcess?pageID=p4wYuA) (http://subclipse.tigris.org/update_1.6.x), bez którego praca z svn jest nieco mniej przyjemna.

[Bazzar](http://bazaar-vcs.org/BzrEclipse/Installation) (http://bazaar-vcs.org/releases/3rd-party/bzr-eclipse/) – nie samym svn-em człowiek żyje.

[Target Management](http://www.eclipse.org/dsdp/tm/) (http://download.eclipse.org/dsdp/tm/updates/3.1/) projekt umożliwia m.in. pracę bezpośrednio na serwerze FTP. Wcześniej z tego powodu zainstalowałem Aptane, ale strasznie muliło mi eclipsa, poza tym powielało niektóre funkcjonalności PDT i WST. Parę spraw było tam lepiej rozwiązanych, a kilka gorzej poza tym było wszystkiego za dużo.

[Azzurri](http://www.azzurri.jp/eclipse/en/index.html) (http://www.azzurri.co.jp/eclipse/plugins) – modelowanie baz danych, synchronizacja schematu bazy z modelem, generowanie kodu SQL na podstawie modelu.

Wirtualne Internet Explorery

Wolę klepać kod w php niż bawić się w stylowanie stron lub projektowanie grafik. Dzięki temu nie potrzebuję w zasadzie Windowsa, a Linux zaspokaja wszystkie moje softwarowe potrzeby. Niestety czasami jednak muszę wklepać kilka reguł css-owych. W końcu nie mogę się z każdą pierdołą zwracać do znajomego web-developera. W takich, rzadkich przypadkach pojawia się potrzeba uruchomienia Windowsa choć by po to aby sprawdzić jak dana strona wygląda w Internet Explorerze 6. Aż dziw bierze, że niektórzy jeszcze tego używają?

Powiecie, że jest coś takiego jak [IE4Linux](http://www.tatanka.com.br/ies4linux/), a ja wam odpowiem, że strony w IE4Linux nie wyglądają tak samo jak w IE zainstalowanym na Windowsie 😉 Jeśli jesteście „zawodowcami” możecie podarować sobie IE4Linux podobnie zresztą, jak używający Windowsa mogą sobie podarować IETestera. To są niuanse, drobne różnice w renderowaniu czcionek, marginesów, dopełnień itp., nie mniej każdy kto toczył kiedyś bój o 2px wie o co chodzi. Tak na marginesie wspomnę, że ciekawie zapowiada się projekt [Expression Web SuperPreview](http://blogs.msdn.com/xweb/archive/2009/03/18/Microsoft-Expression-Web-SuperPreview-for-Windows-Internet-Explorer.aspx), ale nie miałem z nim dotychczas w praktyce do czynienia więc powstrzymam się od opinii.

Czyli zostaje Windows, a najlepiej trzy Windowsy z trzema wersjami Internet Explorera. Powiedzmy, że wersje < 6 można sobie podarować. Jak większość posiadaczy laptopów, również ja mam oryginalnego Windowsa, jednak mam na nim zainstalowaną tylko jedną wersję IE, a do tego nie lubię być zmuszany do wylogowywania się z Linuxa i uruchamiania microsoftowego systemu tylko po to aby zobaczyć jak wygląda strona www, nad którą aktualnie pracuję. Idąc z duchem czasu postanowiłem wiec wypróbować wirtualizacji. Swego czasu Microsoft udostępnił [obrazy wirtualnych maszyn ze specjalnie przygotowanymi wersjami Windowsa XP dla webdeweloperów](http://blogs.msdn.com/ie/archive/2007/04/17/ie7-virtual-pc-image-and-ie6-virtual-pc-image-refresh.aspx). Uruchomić je można korzystając z oprogramowania Virtual PC. Będąc szczęśliwym posiadaczem mało używanego Windowsa zapragnąłem stworzyć swoją wirtualkę i uruchomić "okna" pod Linuxem. Poczytałem troszkę o różnych narzędziach do wirtualizacji i ostatecznie postanowiłem użyć [qemu](http://www.nongnu.org/qemu/) akceleracją kqemu. Do uruchomienia przydatne okazały się [dokumentacja qemu](http://calamari.reverse-dns.net:980/cgi-bin/moin.cgi/QuickStartGuide) oraz tutorial [QEMU - HowTo](http://kaka.ovh.org/howto/qemu/) opisujący krok po kroku instalację i "aktywację" kqemu. Poszukując informacji na temat możliwości zwiększenia pojemności wirtualnego dysku trafiłem też na ciekawy artykuł [qemu i WindowsXP dysko żerca edition](http://wariat.jogger.pl/2007/06/21/qemu-i-windowsxp-dysko-zerca-edition/). Pewien problem sprawiło mi zagadnienie wymiany danych między systemem gospodarzem, a wirtualnym gościem, ale tylko dlatego, że nie mogłem się zdecydować czy wybrać sambę, ftp-a, czy może współdzielenie jakiegoś wirtualnego dysku wymiany. Najłatwiejsze okazało się postawienie serwera ftp na Linuksie i łączenie z nim za pomocą ftp.