poniedziałek, 20 grudnia 2010

Wewnętrzne frameworki

Musiałem właśnie coś zmienić w projekcie, w którym ktoś wpadł na pomysł aby rozwiązać pewne problemy za pomocą wewnętrznego frameworka. A raczej stworzyć całą aplikację w oparciu o nigdzie nikomu nieznany framework. Na mojej prywatnej liście programistycznego zła wewnętrzne frameworki zajmują zasłużone wysokie miejsce. Nie twierdzę tu oczywiście, że nie ma dobrych wewnętrznych frameworków, ale ja się z takimi jeszcze nie spotkałem (a dawno temu sam jeden popełniłem zamiast poszukać czegoś uniwersalnego).

Wszystko zaczyna się od tego, że ktoś wpada na pomysł by coś przyspieszyć. "Zamiast pisać kod zróbmy sobie framework. Będziemy mogli łatwo dodawać kolejne funkcjonalności i w ten sposób oszczędzimy czas. I wszystko będzie uniwersalne i będziemy mogli to wykorzystać w kolejnych projektach".  Najczęściej żadne z założeń się nie sprawdza, funkcjonalności wykraczają poza możliwości frameworku co dodaje do niego kolejne narośle mające rozwiązywać nieprzewidziane wcześniej problemy. W ten sposób zamiast tworzyć kod aplikacji rozwijamy framework (który najczęściej jest w stanie zrozumieć tylko jego twórca), aby z satysfakcją dodać do naszej aplikacji jedną linijkę XML-a, tudzież jakiegoś wewnętrznego języka.Frajdy dodaje fakt, że tworzenie frameworku jest najczęściej zadaniem bardzo twórczym i przyjemnym. O wiele przyjemniejszym niż późniejsze korzystanie z niego.

Jak dla mnie największymi wadami wewnętrznych frameworków są:
- Brak jakiejkolwiek dokumentacji, co powoduje, że nowa osoba dowiaduje się o różnych smaczkach utykając na głupim błędzie, przez który pozostali programiści zdążyli już przebrnąć. W tym momencie Google, standardowe narzędzie programisty na nic się nie zdaje.
- Uzależnienie firmy, dla której tworzy się oprogramowanie od frameworku. Najczęściej jest to dla niej bilet w jedną stronę, bo znalezienie programistów, którzy chcieliby się babrać w utrzymywaniu cudzego frameworku... no cóż, graniczy z cudem
- Ograniczenie rozwoju programisty, który jest zmuszony pisać w nigdzie nie znanym frameworku. Po pewnym czasie faktycznie zaczyna rozumieć framework, ale wiedza ta jest kompletnie nieprzenośna. W żaden sposób nie poprawia to jego ogólnego technicznego obycia, bo co z tego, że jest frameworkowym ekspertem jeżeli nie jest w stanie tej wiedzy nigdzie indziej zastosować. Słowem, z każdą chwilą szanse na zmianę pracy maleją a frustracja rośnie.
- Brak 100% zaufania do frameworku - skoro powstał tylko na potrzeby danego projektu, to jesteśmy jego jedynymi użytkownikami. Niby są testy, ale skoro nawet w Hibernate mającym tysiące użytkowników znajdują się okazjonalne błędy, to możemy podejrzewać że w naszym też się znajdą, wtedy gdy się tego nie spodziewamy.

Z pewnością są sytuacje, w których napisanie frameworku w jakiś sposób się zwraca, jednak z tego co zaobserwowałem, najczęściej rodzi to frustracje ponieważ czegoś się po prostu zrobić nie da. Nauczka dla samego siebie, jeżeli kiedykolwiek będę miał możliwość wyboru czy tworzyć frameworki czy korzystać nawet ze skomplikowanych rozwiązań, które są ogólnodostępne, zdecydowanie wybieram to drugie.

niedziela, 12 grudnia 2010

Synergy, czyli wielki pulpit

Dostałem ostatnio zadanie aby rozwiązać pewien uciążliwy problem Javascriptowy z IE7. Jak to w korporacji bywa, zamiast zainstalować wszędzie Firefoxa, zgodnie z polityką firmy program ma działać na Internet Explorerze. Mniejsza o sam problem, bo i do tej pory leży nierozwiązany, ale do pracy niezbędny był mi drugi komputer (aby nie stracić IE6 zainstalowanego na moim). Dostałem więc drugiego laptopa, który wylądował obok aktualnego. Praca na dwóch ekranach jest bardzo wygodna, szczególnie jeżeli na jednym mamy np. Eclipse, a na drugim przeglądarkę, w której oglądamy efekty naszej pracy. Dostawienie kolejnego komputera, i konieczność naprzemiennego korzystania z dwóch klawiatur, aby przetestować co napisaliśmy jest jednak wyjątkowo uciążliwa.

I tu z pomocą przychodzi Synergy. Program w prosty sposób umożliwia utworzenie wielkiego wirtualnego pulpitu pomiędzy kilkoma komputerami. Współpraca ogranicza się co prawda do automatycznego przełączania kursora myszy w momencie osiągnięcia krawędzi ekranu. Jednocześnie klawiatura jest przełączana na ekran, na którym kursor myszy jest aktywny, co powoduje, że nie musimy odrywać rąk od jednego zestawu klawiatura+mysz.

Od razu powiem, że chociaż program jest niemalże bezobsługowy, to niekiedy po prostu nie działa (na niektórych komputerach nie udało mi się go zainstalować). Ale jak już działa, to sprawia, że zupełnie zapominamy o tym, że tak naprawdę pracujemy na dwóch komputerach. No, może poza tym, że nie da się przeciągać ikon i okien, ale ciężko tego oczekiwać, jeżeli program obsługuje jednocześnie Windowsa, MacOSX i Linuxa. Możemy więc stworzyć sobie wirtualny pulpit, składający się z dwóch systemów operacyjnych. Pracę ułatwia też współdzielony schowek, tak więc wystarczy skopiować coś na jednym komputerze, przeciągnąć kursor myszy na drugi i wkleić. Po prostu działa.

Aby uruchomić Synergy na każdym komputerze podajemy nazwę ekranu:


Następnie na Serwerze, czyli komputerze, którego klawiaturę i mysz chcemy współdzielić dodajemy wszystkie ekrany, które zostaną podłączone. W tym przypadku "1" to Serwer, a "2" to klient.


Musimy określić położenie dwóch ekranów. To co widać powyżej wydaje się w jakimś stopniu nadmiarowe, bo skoro 2 jest na prawo od 1 to logicznie rzecz biorąc 1 jest na lewo od 2.  Chodzi tu jednak o skonfigurowanie warunków przejścia kursora pomiędzy ekranami. W tym przypadku po dojechaniu do prawej krawędzi 1 przechodzimy na 2 i odwrotnie. Opcja ta jest szczególnie użyteczna gdybyśmy mając np. 3 ekrany chcieli się przełączyć z 3 na 1. Można tak skonfigurować Synergy by po znalezieniu się na krawędzi trzeciego ekranu automatycznie przełączał się na pierwszy.

Musimy też określić na jakiej wysokości będzie następowało przełączanie ekranu - najprawdopodobniej będzie to cała jego wysokość (0-100%). Ale można sobie wyobrazić, że dla laptopa postawionego obok dużego monitora będą to inne wartości (tak aby przeciągnięcie kursora na wysokości 50cm nad biurkiem nie powodowało jego pojawienia się na górze drugiego mniejszego ekranu, który znajdowałby się niżej). Na początek najlepiej ustawić od 0 do 100% na każdym z ekranów i eksperymentować, dość łatwo zauważyć jak to działa.