Eclipse + Aptana Studio + jQuery

Witam ponownie w ten ciepły i przyjemny wieczór :)

Dzisiaj jest dobry dzień na blogowanie :) Po spisaniu kolejnych przemyśleń z praktyk postanowiłem podzielić się kolejną rzeczą, która de facto jest z nimi związanymi, ale najpierw dwa zdania wyjaśnienia. Bardzo często spotykam się w rozmowach z developerami z opinią, że "Eclipse śmierdzi". Przykładem jest komentarz Henryka Konska pod postem o m2eclipse. Podobnie mam w pracy, gdzie pewna osoba korzystająca z NetBeans/IDEA bardzo stwierdza w ciemno "w Eclipse tego nie ma" albo "w Eclipsie to nie działa". Dlaczego tak mnie to denerwuje? Ponieważ wydaje mi się, że każdy IDE ma swoje wady i bugi, ale każdy jest też dla innego typu programisty, z innym nastawieniem do pracy. Dla mnie Eclipse jest bardzo dobry z kilku prostych przyczyn:

• przy podstawowej pracy (moja praca najczęściej nie jest wielce skomplikowana) Eclipse w czystej postaci jest zwyczajnie szybki, to taki notatnik na sterydach
• jeśli potrzebuję dodatkowej funkcjonalności (jak w dalszej części tego postu zostanie opisane) zwyczajnie znajduje link, wybieram komponent i instaluję (dla tych, którzy zaatakują mnie pluginem typu m2eclipse -> zobaczcie czy plugin do GAE w NetBeans 6.9 działa tak jak w Eclipse)
• jeśli wziąć pod uwagę Eclipse, NetBeans i IntelliJ IDEA - dla początkującego Eclipse jest najprostszy - takie jest bynajmniej moje zdanie :)

Wracając do tematu postu - jQuery w Eclipse - standardowo w Eclipse JEE mamy podstawowe wsparcie dla JavaScriptu, ale dla jego biblotek (jak jQuery, Prototype itp.) nie. Bardzo dobrym zapełnieniem tej luki jest Aptana Studio. Jest to rozbudowane środowisko do tworzenia aplikacji webowych pracujące samodzielnie lub jako plugin Eclipse. W momencie moich pierwszych zabaw z AS musiałem zadowolić się konfiguracją Eclipse Galileo (3.5) i Aptana Studio 2.0.5 Stable - wersja 3 ciągle była (i jest) w fazie beta i nie współpracowała z Eclipse Helios (3.6). Dało się zainstalować Studio 2.0.5 na Heliosie, ale był to wielki błąd z mojej strony - nie mogłem uruchomić Menadżera Rozszerzeń właśnie przez brak wsparcia dla nowego wydania Eclipse.

Samego procesu instalacji pluginu nie będę tu przedstawiał, gdyż jest bardzo prosty. Zwrócę tylko uwagę na instalację pluginu jQuery w Aptanie. Po zainstalowaniu dodatku i ponownym uruchomieniu całego środowiska naszym oczom powinna się ukazać strona startowa My Studio:

Wybieramy Plugins -> AJAX i z długiej listy możliwych bibliotek wybieramy jQuery Support (wciskamy Get it):

Z listy, która się pojawi wybieramy obie wersje biblioteki jQuery: 1.3.2 oraz 1.4.2:

Dalej instalacja przebiega standardowo. Dzięki tandemowi Aptana Studio + jQuery Support możemy w pełni cieszyć się z wsparcia dla jQuery (jak i czystego JavaScript'u) w Eclipse :)

Na sam koniec chciałbym podzielić się dwoma wskazówkami do używania pluginu do jQuery - Autocomplete:

1) Bezpieczniejsze wyświetlanie podpowiedzi - ponieważ Autocomplete w żadnej mierze nie zabezpiecza wyświetlanych podpowiedzi, musimy to zrobić za niego. W tym celu jako drugi argument metody autocomplete musimy przekazać taką strukturę:

$("#autocompleteDOMObject").autocomplete(data, {
  formatItem: function(row, i, max) {
    return "" + new String(row[0]).replace(/&/g, '&').replace(//g, '>') + "";
  },
  formatMatch: function(row, i, max) {
    return row[0];
  }
}

Funkcja formatItem odpowiada za wyświetlanie kolejnych podpowiedzi, dlatego musimy zastąpić znaki '<', '>' oraz '&' odpowiednimi kodami, aby były one wyświetlane zamiast interpretowane. Metoda formatMatch musi natomiast zwracać kolejne pozycje bez zamiany znaków, gdyż po tych znakach (które wprowadził użytkownik) każemy pluginowi wyszukiwać.

2) Wyszukiwanie nie tylko od początku zdania - jeśli chcemy, aby plugin wyszukiwał także dopasowania słów, które nie są pierwszymi słowami w danym zdaniu/łańcuchu, musimy jako drugi argument autocomplete podać:

$("#autocompleteDOMObject").autocomplete(data, {
  matchContains: "word",
  autoFill: false
}

oraz wyedytować plik zawierający skrypt autocomplete:

function matchSubset(s, sub) {
  if (!options.matchCase)
    s = s.toLowerCase();
  var i = s.indexOf(sub);
  if (options.matchContains == "word"){
    i = s.toLowerCase().search("\\b[^0-9a-zA-Z]" + sub.toLowerCase());
  }
  if (i == -1)
    return false;

  return i == 0 || options.matchContains;
};

Parametr matchContains z wartością "word" mówi pluginowi, że ma wyszukiwać także słów wewnątrz łańcucha znaków. To, co zrobiliśmy w pliku ze skryptem pluginu to zamieniliśmy wyrażenie regularne na takie, które zapewnia nas, że brane będą pod uwagę jedynie "słowa", które nie zaczynają się żadnym znakiem specjalnym.

Na dzisiaj to tyle. Drugi post może nie jest tak bogaty jak poprzedni, ale mam nadzieję, że znajdzie się ktoś, komu zawarte tutaj informacje się przydadzą :)

Pozdrawiam i do następnego razu!

Przemyślenia praktykanta #3

Witam!

Moje praktyki trwają już ponad miesiąc (pozostały jeszcze dwa) i był to wspaniały okres, który oprócz ogromnej porcji wiedzy, doświadczenia i przyjemnej pracy dostarczył mi wiele powodów do zatrzymania się i porządnego zastanowienia (o czym można już było przeczytać już tutaj i tutaj). Sądzę, że jest to najlepszy moment na podzielenie się kolejną porcją przemyśleń. A więc do dzieła :)

10) Nie bójmy się porażek - stare przysłowie mówi: "Kto nie gra, ten nie wygra" i uważam, że idealnie pasuje ono do okresu praktykowania. Jeżeli nie będziemy próbowali sparaliżowani perspektywą porażki lub (co jest niedorzecznością w trakcie praktyk, ale i później także w dużym stopniu) ośmieszenia się przed resztą zespołu to nigdy nie dowiemy się, czy nasz pomysł jest dobry, czy zły, nie będziemy wiedzieli wiedzieli w przyszłości, czy tego typu rozwiązań powinno się unikać, jakie niosą za sobą konsekwencje etc. Nie wierzmy na słowo, sprawdzajmy swoje pomysły, bawmy się przy metodzie prób i błędów.

11) Nie bójmy się zmian - po jakichś 3 tygodniach pracy nad projektem, który przydzielono mi na samym początku praktyk odbyłem bardzo długą rozmowę z opiekunem praktyk, każdy z nas podzielił się z drugim wrażeniami odnośnie wykonywanego projektu, jego szans, moich dotychczasowych umiejętności, priorytetów firmy i wielu, wielu innych spraw. Jaki był skutek tej rozmowy? Postanowiliśmy zarzucić obecnie wykonywany projekt i przejść w trochę inny rodzaj, w dodatku już w trakcie tworzenia przez pewną grupę. Z początku było mi ciężko dopisywać ostatnie linijki kodu do starego projektu (ustaliliśmy, że nie zostawiamy nieskończonych task'ów i że przejdę dopiero po wykonaniu wszystkich zadań jakie mi opiekun wcześniej wyznaczył), ale potem doszło do mnie, że ta zmiana może okazać się dużą szansą - i tak faktycznie było! Mam okazję na co dzień współpracować z grupą (małą, ale dzięki temu nie czuję się przytłoczony) doświadczonych developerów i podpatrywać ich w akcji :)

12) Nie jesteśmy robotami - Tamtego dnia, gdy postanowiliśmy ze Sławkiem, że kończymy pracę nad jednym projektem, a zaczynami nad drugim, nasza rozmowa była najdłuższą czynnością jaką wykonałem, ale okazała się najbogatsza w wiedzę, możliwość spojrzenia na projekt okiem kogoś, kto nim zarządza. Do czego zmierzam? Do tego, że nikt nie oczekuje, iż będziemy siedzieli przed komputerem pełne 8 godzin od 9 do 17, nie wytykając nosa poza box poza krótką przerwą na drugie śniadanie. Czasem krótki czas spędzony daleko od biurka może przynieść więcej korzyści, niż kilka godzin siedzenia na tyłku męcząc się z jakimś zagadnieniem. Dla mnie takim miejscem odsapnięcia jest kuchnia (z uwagi na ekspres do kawy ;) ) i muszę przyznać, że rozmowy tam (a także ich brak, gdy nikogo w kuchni nie ma) potrafiły przybliżyć mnie do rozwiązania problemu bardziej niż siedzenie z tym problem tête à tête przez pół dnia.

13) You Ain't Gonna Need It - czyli w skrócie YAGNI, jest zasadą mówiącą, że powinniśmy dodawać do projektu nową funkcjonalność dopiero w momencie, gdy ta funkcjonalność jest niezbędna. Dzięki temu unikamy nadmiernego rozrostu projektu i koncentrujemy się (a co za tym idzie lepiej wykonujemy) na tym, co najważniejsze. Osobiście miałem ten problem przy swoim pierwszym samodzielnym projekcie na praktykach - zacząłem dodawać nowe funkcjonalności nie pokrywając dostatecznie testami już stworzonych i po niedługim czasie mój system był dziurawy jak ser szwajcarski, duży, ale z małą ilością prawdziwej funkcjonalności. Na całe szczęście mam opiekuna, który w każdej chwili jest gotów ściągnąć mnie na ziemię i wskazać najodpowiedniejszy kierunek działań :) Jest to bardzo dobre, póki jeszcze sami nie jesteśmy w stanie dostrzegać i wykonywać najistotniejszych zadań w pierwszej kolejności. Wydaje się, że stoi to w sprzeczności z podchodzeniem do pracy z postawą eksperymentatora i metodą prób i błędów? Nie będę sam wynajdywał koła i powołam się na artykuł kogoś, kto umie to wytłumaczyć znacznie lepiej ode mnie - mówię tu o artykule "Bo w życiu trzeba... być Agile:)" Sławomira Sobótki.

14) Nie taka dokumentacja zła jak ją malują - w obecnych czasach podobno zaledwie kilka firm na świecie przyznaje się do tego, że nie jest "zwinna", raptem jedna indyjska firma oficjalnie ogłosiła, że nie jest firmą pracującą w oparciu o zwinne metodyki. A z czym ludziom kojarzy się zwinna firma? Z brakiem dokumentacji, z końcem biurokracji itp. Ale czy naprawdę dokumentacja jest takim złem? Kiedy w zeszłym tygodniu zmieniłem projekt, za zadanie miałem (i nadal mam) uzupełnienie i aktualizacja dokumentacji tegoż projektu. Z początku bardzo mi się to nie spodobało, ale po kilku godzinach badania projektu zdałem sobie sprawę, że jest to idealna okazja na dogłębne poznanie obszaru, nad którym mam pracować. Daje mi to też możliwość zadawać trudne pytania autorom konkretnych fragmentów kodu, jeżeli jakieś zachowanie jest niejasne lub zwyczajnie nie działa tak jak do tej pory było to opisane. Po dwóch dniach spędzonych nad dokumentacją dostałem do wykonania proste zadanie poprawy drobnego kawałka kodu i dzięki zdobytej wiedzy rozwiązanie problemu zajęło (dosłownie!) 5 minut wraz z przetestowaniem.

Na razie to wszystko. Pozdrawiam i do następnego razu! :)

Duża porcja filmików

Witam!

Ostatnio zastanawiałem się czemu Miško Hevery nie publikuje nic na swoim blogu, gdy w tym momencie pojawiła się wiadomość w czytniku RSS o jego nowej publikacji. Miško jest bardzo utalentowanym, chętnym do dzieleniem się swoją wiedzą i rozmowy programistą, który od jakiegoś czasu dosyć często pojawia się w cyklu Google Tech Talks. Nie inaczej było tym razem - Miško Hevery wygłosił prezentację na temat "How JavaScript works", która jak dla mnie jest rewelacyjna, gdyż dopiero teraz zaczynam zabawę z JavaScript. Nie jest to prezentacja, która ma za zadanie nauczyć nas pisać skrypty JS, ale wytłumaczyć czemu pewne rzeczy się dzieją i co może być często problemem wynikającym z nierozumienia samej zasady działania języka. Film trwa godzinę, ale naprawdę dobrze się go ogląda - gorąco polecam:

Dodatkowo rozmawiałem ostatnio z Leszkiem Gruchałą, organizatorem konferencji java4people w Szczecinie na temat filmików z ostatniej edycji. Konferencję tą darze szczególnym sentymentem, gdyż była to moja pierwsza konferencja dla developerów w życiu, a wrażenia i wiedza z niej wyniesiona do tej pory procentują :) Okazało się, że są one dostępne na łamach portalu Parleys.com (należy przejść do działu Spaces -> Only JUGs -> Szczecin JUG). Oto kilka najciekawszych moim zdaniem:

"Comet & Beyeux" autorstwa Waldemara Kota:

"Zwinne i lekkie aplikacje webowe z Grails" Jacka Laskowskiego (jeszcze bez swojego śrebrnego MacBook'a ;)):

"System kontroli wersji GIT" Andrzeja Śliwy

To na dziś tyle. Czas iść spać, żeby jutro wypoczętym przyjść na praktyki i zgłębiać się w temat RESTful Services :) Do następnego razu!

Przemyślenia praktykanta #2

Witam!

Od mojego ostatniego postu minęło raptem cztery dni, ale nawet w tak krótkim czasie pojawiło się kilka przemyśleń, olśnień, a także postanowień. To jest dla mnie kwintesencja praktyk - zmuszają nie tylko do działania (w moim przypadku kodowania), ale w większym stopniu do myślenia, stawiania czoła problemom i otwieraniu się na nowe (choć z pewną dozą zdrowej podejrzliwości).

7) Nie zabieraj pracy do domu! - przez pierwsze dni była to moja zmora. Siedziałem w firmie po 9 godzin, a po przyjściu do domu zamiast się zrelaksować, siadałem nad problemem by do późnych godzin tak naprawdę niewiele posunąć się do przodu. Dlaczego tak było? Ponieważ nie miałem w koło siebie grupy fachowców w każdej chwili gotowej mi pomóc, ponieważ nie zapewniłem sobie należytego relaksu. Po kilku dniach i lekturze Rework (znów ten Rework :)) uświadomiłem sobie, że jeżeli wszystkie zmartwienia i problemy związane z praktykami będę zostawiał w firmie, po pracy będę w stanie naładować swoje akumulatorki, aby następnego dnia stawić czoła wyzwaniu/przeciwności z pełnią sił i determinacji. Robiąc inaczej tylko podcinamy sobie skrzydła i w naprawdę krótkim czasie skazujemy siebie samych na wypalenie, po którym z odpowiedniego "chce" zrobi się śmiercionośne "muszę". Od kiedy wprowadziłem do życia tę zasadę osiągam więcej i szybciej, a najlepsze jest to, że robię to z przyjemnością!

8) Nawet najmniejszy unit test może rozjaśnić Twój dzień - dwa dni straciłem nad pewnym zagadnieniem numerycznym. Męczyłem się z doborem odpowiedniej biblioteki, potem z jej integracją, by na końcu zawsze okazywało się, że nie spełnia ona naszych wymagań. Zamiast iść do przodu, stałem w miejscu i przestawało mi się chcieć. Trzeciego dnia zmagań poszedłem do Sławka i namówił mnie do napisania swojego rozwiązania, ale z możliwie najmniejszą funkcjonalnością. Po jakiejś pół godzinie, gdy uruchomiłem pierwszy test i zobaczyłem wiadomość "Failure: 0" od razu się uśmiechnąłem i nabrałem chęci do pracy. Tak napędzony przez kolejne kilka godzin pracowałem dodając nowe testy i przez większość czasu uśmiechając się do siebie samego, nawet wtedy gdy nie wiedziałem jak mam to, czy tamto poprawić. Starałem się nie wprowadzać zbyt wielu modyfikacji naraz, aby móc dobrze przetestować całość. Efekt? Pod koniec dnia przyszedłem do Sławka z gotowym rozwiązaniem, pokrytym testami i spełniającym wszystkie nasze wymagania. Od tej pory staram się wyszukiwać nawet najmniejsze rzeczy, które wiem, że uda mi się zrobić szybko i poprawnie, co doda mi sił i motywacji do pracy - to naprawdę działa :)

9) Utrzymuj rzeczy możliwie najprostszymi - jednym z problemów, który miałem przy zagadnieniu, o którym pisałem wcześniej było to, że zbytnio chciałem je rozbudowywać i to od samego początku. Brało się to z nauki, którą wpaja się na uczelniach wyższych (a przynajmniej na obu kierunkach, na których byłem - mam nadzieję, że gdzieś jest inaczej) - od samego początku myśl i projektuj i koduj z myślą o pełnej funkcjonalności systemu. Ten prosty problem pokazał mi, że oczywiście należy przewidywać możliwą rozbudowę systemu, ale nie należy jej wprowadzać od pierwszych chwil jego życia. Kiedy mój opiekun wskazał mi kluczowe zagadnienia, którymi musi zając się moja biblioteka sprawa nagle stała się kilkakrotnie prostsza i możliwa do zaimplementowania w ciągu jednego dnia. Dzięki temu mam gotowy szkielet, który w niedługiej przyszłości mam zamiar rozwijać, ale na dzień dzisiejszy jest już działający i jest wykorzystywany. Gdybym zabrał się za pełną (lub choćby połowiczną) potencjalną funkcjonalność od pierwszych chwil nie miałbym tego gotowego przed końcem roku, a co dopiero końcem praktyk.

Na dzisiaj to tyle. Czas się wyspać, jutro też jest dzień (może na napisanie kolejnego postu? :)).

Pozdrawiam i do następnego razu!

Przemyślenia praktykanta #1

Witam!

Ostatni okres nie był dla mnie łatwy. Zacząłem praktyki i tak jak na samym początku sądziłem, że będzie super produktywnie, pracowicie i entuzjastycznie, tak po niecałych dwóch tygodniach jedyne co bym z tego zdania pozostawił to pracowicie. A co z resztą? To trudne pytanie, na które cały czas nie znalazłem (i pewnie długo jeszcze nie znajdę) pełnej odpowiedzi. Do przemyśleń skłoniła mnie książka, którą właśnie czytam - Rework - Jasona Fried'a oraz Davida Heinemeier Hansson'a (z firmy 37signals - twórców m.in. Ruby on Rails), o której niedługo trochę szerzej napiszę na blogu. Ale do rzeczy:

1) Są wakacje! - nim jeszcze zacząłem praktyki miałem wielkie plany na wakacje: bieganie z samego rana, praktyki od 8 do 16, potem coś zjeść, praca inżynierska oraz jeden z 2 projektów, w których mam brać udział i spać - idiotyzm. Czas wakacji to przede wszystkim czas odpoczynku, relaksu, nabrania sił na boje kolejnego roku akademickiego. Bardzo dobrze podchodzą do tego panowie od marketingu w wydawnictwie ISA - w swoim newsletterze piszą:

Wakacje, to czas wytchnienia od nauki i pracy. Wolny czas można zagospodarować na 1001 sposobów. Proponujemy, aby część tego czasu spędzić z ciekawą lekturą.

To nie musi być książka, równie dobrze można iść na plażę, do lasu, na rower i etc. etc. Sens jest w tym, by znaleźć coś, co nas relaksuje i pomaga się odprężyć.

2) Jesteś na praktykach, nie w pracy - Mateusz bez przerwy mi to powtarza. Praktyki to czas nauki, nikt nie oczekuje, że w ciągu miesiąca (czy jak w moim przypadku trzech) praktykant zbuduje "nowe, lepsze Google". Oczywiście większość praktykantów, którzy zaczynają w dobrej firmie, chciałaby po skończeniu praktyk dalej współpracować z firmą - ja sam tak miałem/mam. Ale bardzo szybko okazuje się to bardzo zgubne. Przy każdej rzeczy, jaką się wykonuje myślenie zamiast kierować się ku rozwiązaniu idzie w kierunku zadowolenia szefa, czy się przypadkiem nie ośmieszymy etc. Tak jest często, jeśli nie jesteśmy pewni swojej wartości na rynku, a bardzo byśmy chcieli być widziani jak najlepiej. Takimi sprawami powinniśmy się martwić dopiero pod koniec lub na sam koniec praktyk, a do tej pory starać się robić zwyczajnie swoje i uczyć się przy tym jak najwięcej. Czy będziemy dalej pracować w tej firmie, czy nie - doświadczenie i tak wyniesiemy, a przecież po to idziemy na praktyki, prawda? :)

3) Refaktoryzacja - oto klucz do łatwiejszej nauki. Bardzo często łapie się na tym, że chce wykonać dane zadanie tak dobrze, że już nie wiem jak do tego podejść. Liznąłem temat TDD - no to piszemy testy, poznałem metodę DRY/KISS/itp. - od samego początku piszę kod zgodny z nimi wszystkimi etc. Przykładów można wymieniać mnóstwo i oczywiście przesadzam, ale mam nadzieję, że idea jest jasna. Dopiero dzisiaj uświadomiłem sobie, że moje podejście jest błędne. Brak mi doświadczenia, żeby pisać ładny, dobry produkcyjny kod. Dlatego zacząłem robić coś innego, za namową bardziej doświadczonych ode mnie - tworzę jakieś rozwiązanie, najłatwiej jak się da. Potem gdy już osiągnę cel zastanawiam się (jeśli jest na to czas oczywiście), czy da się to zrobić lepiej i jeśli tak, próbuje tak zrobić, ale nie wkładając w to za dużo czasu/wysiłku, tak by znajdywanie tego rozwiązania nie było męką, tylko przyjemnością. Jeśli jestem zadowolony z rozwiązania (a u mnie to oznacza możliwość "łatwej" integracji z całością, którą tworzę) zostawiam temat i przechodzę do następnego zagadnienia. Na artyzm przyjdzie jeszcze czas, a jest tyle do nauczenia się :) Bardzo często w nauce danego tematu nie chodzi o poznanie konkretnej technologii, ale bardziej o ideę, którą ona realizuje - wtedy nie ma sensu zbytnio się przejmować pięknem rozwiązania. Dużo czasu przez to straciłem, ale mam nadzieję, że wreszcie przejrzę na oczy :)

4) Nie wszystko naraz! - kiedy idzie się na praktyki bardzo często ma się wrażenie, że od samego początku będzie się uczyło nie wiadomo ilu i jak wysublimowanych technik/narzędzi/ideologii/metodyk. Przez takie podejście bardzo łatwo utknąć w martwym punkcie, gdzie nie wiadomo czego się chwycić. Ja sam tak często miałem przed praktykami, ale na szczęście mój opiekun w Spartezie (Sławek) bardzo szybko sprowadza mnie na ziemię. Najczęściej idziemy sobie zrobić kawkę i dyskutujemy o tym co można by było zrobić dalej, wybierając jedną ze ścieżek. Nie ma tak, żeby łapać się kilku rzeczy naraz - w ten sposób w jednostce czasu nie zrobisz tak naprawdę nic, a jeśli będziesz robić po kolei, każdej z tych rzeczy nauczysz się lepiej i dokładniej.

5) Jeśli naprawdę nie masz co robić, idź do domu - często znajomi opowiadają mi jak to na praktykach siedzieli 8h bezczynnie, tępo oglądając filmiki na YouTube lub grając w gierki na Facebook'u - to totalnie bez sensu. Jeśli w danym dniu zrobiło się już wszystko, co zostało zaplanowane, a następny krok jest na tyle obszerny i trudny (nieprzyjemny?!), a czasu stosunkowo za mało, tak że musielibyśmy jutro zaczynać i tak od nowa - poprośmy szefa o możliwość pójścia do domu. Lepiej wypocząć w domu, nabrać sił na kolejny dzień, niż męczyć się ciągnąć do tych 8 godzin dla samej zasady i skazując się na zmęczenie czy też brak pozytywnego podejścia następnego dnia. Na moich praktykach nie mam rygoru przychodzenia na konkretną godzinę. Mamy ustalony plan działań i w pewnym przedziale trzeba to zrobić. Dzięki luźniejszemu podejściu w momencie gdy czułem się gorzej mogłem spokojnie poleżeć w łóżku, by przyjechać do firmy wypoczęty. Nie miałem stresu, więc i robota szła lepiej. Dla samokontroli zapisuje sobie godziny przyjścia i wyjścia (oczywiście mniej więcej) i ku mojemu zdziwieniu przesiedziałem od początku praktyk więcej godzin, niż wynosi pracownicze minimum, a zrobiłem to z chęcią i nawet tego nie poczułem.

6) Kiedy masz problem - nie bój się zapytać innych - nic nie jest lepszym źródłem wiedzy niż doświadczenie starszych stażem! Już na samym początku praktyk dowiedziałem się, że będę musiał nauczyć się zagadnień z wielu dziedzin. Wiadomo, że nie każdy zna się na wszystkim, tak więc trzeba próbować aż do skutku. Nie mówię, że należy z najmniejszą rzeczą biegać po całym biurze siejąc popłoch. Mam to szczęście, że choć w firmie, w której robię praktyki każdy ma bardzo solidne podstawy z wiedzy ogólnej, już po chwili udało mi się rozpoznać kogo mogę o co pytać. Jedni podpowiedzą jak czegoś wyszukać, inni usiądą i zrobią z Tobą krótkie Code Review, jeszcze inni naprowadzą na rozwiązanie samymi pytaniami na temat problemu, ale wszyscy wyznają jedną zasadę - jeśli ktoś poprosi o pomoc - nie odmówią. Co jeszcze lepsze - kiedy już pomogą Ci znaleźć rozwiązanie będą ciekawi jak Ci poszło. Ostatnio w ten sposób bardzo miło zaskoczył mnie jeden z członków zespołu - dopytywałem się go o RESTful Services budowane w oparciu o framework Jersey i tego samego dnia, a także następnego przez pytania o to, czy udało mi się rozwiązać problem dowiedziałem się masy nowych rzeczy (nie dziwota, bo temat dla mnie całkowicie nowy) i to w jednym z najprzyjemniejszych sposobów - przez rozmowę. Tak więc nie należy bać się zadawać pytań, bo w ten sposób może umknąć nam wiele niuansów, których próżno szukać w (nie)oficjalnych dokumentacjach.

Trochę przydługi wpis mi wyszedł, ale przynajmniej znalazłem formę na wyrażenie swoich myśli :) Pozdrawiam i do następnego razu!

Problem z m2eclipse

Witam!

Jaki Eclipse jest - każdy widzi i większość wie. W trakcie niedawno rozpoczętych praktyk często spotykam się z opinią, że Eclipsem nie warto sobie w ogóle głowy zawracać, że jest kompletnie bezużyteczny etc. etc. Osobiście twierdzę, że mając na głowie mnóstwo rzeczy, których muszę się nauczyć "na wczoraj" (lista postanowień noworocznych to przy tym pikuś ;)), zawracanie sobie głowy nauką i przyzwyczajaniem się do nowego IDE było by mało efektywne. Dlatego uparcie trzymam się Eclipsa i prę dalej. Miało być o problemie z integracją Eclipse Galileo z Mavenem, ale najpierw jeszcze sam nawrzucam na moje ukochane IDE. bo co za dużo, to niezdrowo:

• Eclipse Helios po wielu próbach i ogromnej ilości dobrych chęci okazał się totalnie bezużyteczny do pracy z Google App Engine, AJAX'em, jQuery etc. Pluginy odpowiedzialne za wsparcie dla tych technologii/narzędzi zwyczajnie nie są kompatybilne z najnowszą wersją Eclipsa...
• Na potrzeby napisania tego postu wróciłem dzisiaj na chwilę do Eclipse Galileo na Windows 7 i oto jaki komunikat otrzymałem przy starcie aplikacji (nie wymaga chyba komentarza):

A teraz wracając do integracji Mavena z Eclipse Galileo (na Heliosie nawet nie pomyślałem, żeby to sprawdzić) - prostym rozwiązaniem wydawać by się mógłby się wydać wybór wtyczki m2eclipse. I tak jest, ale osobiście srodze się zawiodłem już na samym początku. Pierwszy problem to fakt, że Eclipse z natury uruchamia aplikacje za pomocą JRE, a nie JDK. Aby to zmienić musimy w Window -> Preferences -> Java -> Installed JRE's ustawić jako domyślne JRE z JDK. Klikamy Add ...

... wybieramy Standard VM ...

... i w Directory wpisujemy adres zainstalowanego w systemie JDK

Potem wybieramy go jako domyślny na liście JRE i klikamy OK:

Wyłączamy Eclipse i otwieramy plik konfiguracyjny eclipse.ini (w głównym katalogu Eclipse). PRZED parametrem -vmargs dodajemy parametr -vm, a linijkę niżej podajemy ścieżkę do JRE. U mnie wygląda to następująco:

Pamiętajmy, by nie podawać ścieżek ze spacjami oraz używać '\\' lub '/' zamiast standardowego '\' Windowsa! Uruchamiamy Eclipse i cieszymy się wtyczką m2eclipse :)

Jeśli zaimportujemy projekt stworzony już wcześniej (File -> Import -> Existing Maven Projects) i spróbujemy wykonać Maven install z menu rozwijanego Run as możemy otrzymać taki oto komunikat:

Could not calculate build plan: Missing:
----------
1) org.apache.maven.plugins:maven-resources-plugin:maven-plugin:2.4.1
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.maven.plugins -DartifactId=maven-resources-plugin -Dversion=2.4.1 -Dpackaging=maven-plugin -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=org.apache.maven.plugins -DartifactId=maven-resources-plugin -Dversion=2.4.1 -Dpackaging=maven-plugin -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
----------
1 required artifact is missing.
for artifact:
org.apache.maven.plugins:maven-resources-plugin:maven-plugin:2.4.1
from the specified remote repositories:
central (http://repo1.maven.org/maven2, releases=true, snapshots=false)

Aby temu zaradzić musimy do POM'a dodać w sekcji build taki oto wpis o używaniu resource-plugin w nowszej wersji (np. 2.4.2). Całość wygląda następująco:

Teraz po wykonaniu komendy install w katalogu target znajdziemy nasz "wymarzony" plik JAR. Trochę (za)dużo zachodu, prawda? Niestety, takie właśnie są uroki używania Eclipse...

Mam nadzieję, że komuś przyda się ta informacja. Ja walczyłem ponad godzinę z Eclipse nim Maven zaczął mi w nim "działać". Bardzo pomocne okazały się wpis na Victoria's blog, Stackoverflow oraz komentarz Nikola na blogu Bright Side.

Pozdrawiam i do następnego razu!

Cytaty #4

Witam!

Trafiłem dzisiaj na bardzo ciekawy i bardzo trafny artykuł Sławka Sobótki na temat podejścia Agile, w którym to napisał:

Gdy jednak przyjrzeć się bliżej, to z tym Agile jest jak z seksem u nastolatków - każdy o tym mówi ale niewielu tak na prawdę to robi (a przynajmniej tak było kilkanaście lat temu w klasach mat-inf;).

Jeśli sam autor nie zachęcił Was do przeczytania tego niedługiego (wyjątkowo :P) wpisu, to może ten cytat to zrobi :)

Pozdrawiam i do następnego razu!

Pierwszy dzień praktyk

Witam!

Właśnie wróciłem z pierwszego dnia praktyk wakacyjnych w firmie Spartez.com :) Wrażeń było co niemiara, ale od początku :)

Przyjechałem do firmy punktualnie o 8 (sam jestem zdziwiony, że udało mi się wstać :D) i narobiłem tym trochę zamieszania, bo nie było nikogo, kto by wiedział co mam robić albo gdzie siedzieć. Ale szybko udało się temu zaradzić i przyszedł czas na pierwsze zadanie - przygotowanie miejsca pracy. Byłem tak zestresowany pierwszym dniem, że do złożenia biurka podchodziłem 3 razy - ponoć do trzech razy sztuka... Gdy biurko w końcu stało trzeba było złożyć fotel (który nawiasem mówiąc spowodował wiele wiązanek, gdyż jest skórzany i wygląda jak fotel jakiegoś prezesa w banku :)) i tu znów pojawiły się problemy, ale metodą "małych kroczków i dużego młotka" udało się i z tym poradzić (choć ręce nadal mi dygotały). W czasie składania przyszła kolejna nowa osoba w zespole - student ETI imieniem Krzysiek.

Około godziny 10 przyszedł czas na Standup Meeting - mój pierwszy meeting scrumowy :) Wrażenia bardzo pozytywne i nie mogę się doczekać kolejnego :D Spotkanie było wyjątkowe, bo cała firma się zebrała, a to dlatego, żeby łatwiej nas (nowych) poznać z resztą zespołu.

Po standup'ie dowiedziałem się nad czym będę pracować przez najbliższe 3 miesiące i muszę powiedzieć, że projekt nie dość, że jest ciekawy technologicznie to w dodatku mi się spodobał i od samego początku przyjemnie mi się nad nim pracowało :) Reszta dnia upłynęła na robieniu ogromnego sajgonu na wirtualnej maszynie (Ubuntu + Eclipse x4 + Google App Engine Plugin to jakby samemu prosić się o kłopoty :D) i poznawaniu podstaw pracy z Google App Engine. W jednym z moich poprzednich wpisów pisałem o Eclipse Helios. Przygotowałem sobie specjalnie na dzisiaj czystą wersję, aby móc na nim pracować, ale spotkało mnie ogromne rozczarowanie - Google App Engine Plugin nie współpracuje z wersją Eclipse wyższą niż 3.5.x i trzeba było wrócić szybko do Galileo, a szkoda. Ale nawet to nie ostudziło mojego zapału do pracy :) Niestety o godzinie 15:30 padł prąd w całym budynku (awaria w Enerdze jak się później dowiedzieliśmy), która trwała prawie godzinę, tak więc po pewnym czasie zwinąłem się już do domu, bo nawet sieci nie było (a bez niej i tutoriali).

Podsumowując: tak jak byłem przerażony wizją praktyk wakacyjnych, tak teraz nie mogę się doczekać kiedy znów usiądę znów przy swoim biurku i będę mógł dalej pracować nad projektem! Ciekawe tylko jak długo takie nastawienie mi się utrzyma ;)

Pozdrawiam i do następnego razu!