Paradoks czasowo-przestrzenny

No i jeszcze z ciekawostek dzisiejszego dnia: dostałem informację od recenzenta, że praca magisterska jest już oceniona, po czym godzinę później dowiedziałem się od kolegi, że mój promotor mnie szuka,ponieważ moja praca magisterska jest jeszcze nie skończona...

Hmm....

Nie wiem do końca jak, czemu i w jaki sposób, ale jest jak jest. Mam ocenioną pracę, która podobno jeszcze nie jest skończona :) W poniedziałek czeka mnie wycieczka (hurra...) na Politechnikę, żeby sprawę wyjaśnić.

Ps. Dostałem 5.0 z recenzji :)

Rozmowy rekrutacyjne - esencja cz. 2

Kolejna ciekawą sprawą jest fakt, że na rozmowach rekrutacyjnych nie za wiele osób sprawdza wiedzę praktyczną. Zwykle osoba rekrutująca pyta się o poszczególne etapy kariery wypisane w CV, zadając pytania typu "Co było największym osiągnięciem w firmie X", "Jakie były Twoje zadania, gdy pracowałeś w Y". Udzielając odpowiedzi na nie pokazujemy rekrutującemu czy po pierwsze na prawdę tam pracowaliśmy (można być zatrudnionym jako programista, a w praktyce podawać kawę przez większość dnia). Poza tym sprawdzane jest jaki był nasz zakres kompetencji, jakie były stawiane przed nami problemy i co takiego tak na prawdę wnieśliśmy do firmy. Wszystko fajnie, z tym, że uważam, że dobry ściemniacz i lawirant, poradziłby sobie bez problemu w opowiadaniu czego on nie zrobił i jak pięknie to nie działało. Każdy może przecież upiększać i koloryzować swoje osiągnięcia. Dlatego dziwi mnie fakt, że na rozmowach o pracę nie proszono mnie o pisanie choćby kawałka kodu. A to przecież kod tak na prawdę świadczy o programiście.
Często pojawiają się pytania z dziedziny informatyki, Javy, wzorców projektowych. I to już jest rzeczywiście fajnie, ale uważam, że to wciąż za mało i choćby kawałek kodu do napisania mówił by o wiele więcej, niż tysiące sztampowych, powtarzających się w kółko pytań. W idealnym układzie powinno się prosić o napisanie choćby kawałka kodu, lecz nie zostawiać programisty samemu sobie, a patrzeć jak podchodzi do problemu. Ocenić logiczne myślenie, (nie)szablonowość, radzenie sobie z problemami. Żywe zadanie, żywy problem - to powinno być esencją rozmowy rekrutacyjnej. Chyba tylko w czasie jednej rozmowy o pracę poproszono mnie o napisanie kawałka kodu.

Można zadać sobie pytanie - a co mnie to obchodzi, przecież to nie ja rekrutuje. Niby tak i też nie do końca. Zakładając, że idę do pracy do takiej firmy, gdzie rekrutacja była poprowadzona po łebkach, mogę się spodziewać, że do mojego zespołu trafią: lawiranci, lenie, ściemniacze, cieniasy (lub hybrydy powyższych). O atmosferze pracy świadczy team! Chce pracować z ludźmi fajnymi, ale również osobami, które coś ze sobą wnoszą, kompetentnymi.
Oczywiście jest okres próbny, w praniu wychodzi, kto tak naprawdę się nadaję i każde kłamstewko wypowiedziane w czasie rozmowy o pracę wyjdzie na jaw. Dziwi mnie tylko fakt, że pracodawcom nie przeszkadza taki tryb. Osobiście uważam, że rekrutacja na stanowisko programisty powinna sprawdzać wiedzę kandydata rzetelnie, dokładnie i do bólu. Przynajmniej na to byłem przygotowany, a w kilku firmach nawet nie słyszałem pytań sprawdzających wiedzę, pracodawca brał wszystko na słowo. Dziwi mnie to, ale może rzeczywiście nie mnie to osądzać.

Oczywiście nie powinienem też dramatyzować. Kilka firm przeprowadziło rzetelne rozmowy rekrutacyjne i jeśli kiedykolwiek miałbym usiąść po drugiej stronie stołka, być osobą zadającą pytania, na pewno korzystałbym z doświadczenia z tamtych spotkań, które uważam za naprawdę udane.

Rozmowy rekrutacyjne - esencja cz. 1

Jestem obecnie w trakcie poszukiwania pracy. Jakieś 10 dni temu porozsyłałem moje CV po różnych firmach IT we Wrocławiu, a później po krótkim okresie oczekiwania zostałem zapraszany na kolejne rozmowy o pracę. Odwiedziłem kilka(-naście) większych i mniejszych firm IT i z wnioskami z tych spotkań chciałbym się z Wami podzielić. Jeśli szukacie lub planujecie szukać pracy w najbliższym czasie potraktujcie ten wpis jako pewnego typu przewodnik po procesie rekrutacji.
Zacznę na początek od pytań, które pojawiają się zawsze lub prawie zawsze.

"Kim jest Paweł Szulc?"

To pytanie rozwala i niszczy. Pojawia się na samym początku rozmowy rekrutacyjnej i wydaje mi się, że zadawane jest po to, aby już na samym początku zbić nas z tropu. No bo słyszycie takie pytanie i co w ogóle wtedy myślicie? Co to jest za pytanie, jaki jest jego sens? Czy mam teraz w 15 zdaniach opisać swoją osobowość, charakter, życiorys a na końcu odnieść się do tego wszystkiego w pięknym podsumowaniu? Czy może pytają się kim jest Paweł Szulc jako programista, co umie, co potrafi, gdzie zdobył szlify i doświadczenie. Moją pierwszą reakcją było zadanie sobie samemu pytania, jakiej odpowiedzi oni oczekują. Ponieważ nie byłem sobie w stanie na to pytanie sam odpowiedzieć, spytałem się ich: w jakim sensie, w jakim kontekście zadane jest to pytanie. Odpowiedź powala na kolana: "Dowolnym".
Musicie sobie zdać sprawę, że jest to pytanie na krasomówczą pułapkę. Wydaje mi się, że to pytanie zadawane jest po to, żeby tak naprawdę usłyszeć co ciekawego opowie nam ta osoba o sobie. Nie chcą wiedzieć, kim jest Paweł Szulc. W 15 zdań nikt nie jest w stanie siebie opisać i pracodawcy dobrze o tym wiedzą. To pytanie z samej natury ma być enigmatyczne, ma lekko zagiąć, zdziwić. Chodzi o sprawdzenie jak osoba poradzi sobie w takiej sytuacji, czy umie coś o sobie powiedzieć i jeśli tak to w jaki sposób. Ponieważ usłyszałem to pytanie na 90% rozmowach rekrutacyjnych, szanse są, że i wy je usłyszycie. Warto być tego świadomym i mieć przynajmniej szkielet jakieś gadki gotowy na poczekaniu.

"Czemu wolałby Pan pracować w mniejszej firmie?"

Na początek, żeby coś sobie wyjaśnić. Nie aplikowałem mojego CV do żadnej z firm typu Siemiens, Comarch czy innych większych korporacji. Nie ma w tym jakieś konkretnej przyczyny. Po prostu nie bawi mnie praca w firmie, gdzie struktura pracy nakazuje raportowanie do czterech rożnych szefów, gdzie przychodzę pracować jako programista Java kończę jako programista C++. Słyszałem różne historie i jakoś się zraziłem. W życiu zawodowym otarłem się o mniejsze firmy (w sensie mniej niż 100 osób) i z każdą doświadczenie mam jak najbardziej pozytywne. Ja WIEM, że 3/4 studentów po informatyce rzuca się na większe firmy. Jestem tego świadomy. Osobiście się temu dziwie, bo chyba jeśli w takich firmach jest taka rotacja pracowników, że cały czas kogoś nowego przyjmują, bałbym się trochę składać tam papiery.
No ale mam świadomość, że tak jest. Pracodawcy mniejszych firm jak widać też mają. Praktycznie na każdej rozmowie, na której byłem pytano się mnie: "A czemu nie korporacja?". Po trzeciej takiej rozmowie miałem już gotową gadkę i byłem na to pytanie przygotowany, ale z początku w sumie było jedno z tych pytań, które mnie dziwiło, nie dlatego, że nie wiedziałem jak na nie odpowiedzieć, a dlatego, iż dziwiłem się, że w ogóle było zadawane. Dla mnie naturalnym był fakt, że najpierw szukam zatrudnienia przede wszystkim w mniejszych firmach IT. Jak widać nie dla wszystkich jest to naturalne.

"Ile chciałby Pan zarabiać?"

Nie powinno nikogo dziwić, że pytanie to będzie zadane. Osobiście uważam, że trzeba przed rozmową rekrutacyjną dokładnie wiedzieć, ile się chce zarabiać w danej firmie i kwotę to podać natychmiast, po zadaniu pytania. Na jednym wydechu, bez zająknięcia. Wtedy pracodawca widzi, że sprawę mamy przemyślaną, wiemy dokładnie czego chcemy. To pytanie nigdy nie jest negocjacją. Pracodawca odpowie "aha" lub "yhmmm", zapisze sobie kwotę na papierze i o tym czy mu kwota ta pasowała dowiemy się dopiero, po kilku dniach od rozmowy. W całym moim życiu miałem dwa wyjątki od tej reguły: raz osoba rekrutująca spytała się czy nie da się mniej, innym razem rekrutująca osoba powiedziała, że im to odpowiada i czy się decyduje na pracę (tak tak, miałem się określić w dniu rozmowy rekrutacyjnej - rekord świata moim skromnym zdaniem ;) ).
Dlatego powtarzam, na to pytanie trzeba być przygotowanym. Osobną sprawą jest kwestia ile powiedzieć, że chce się zarabiać. To wszystko zależy. Jak już pisałem jakiś czas temu, w Polsce nie obowiązują zachodnie standardy podawania widełek płacowych. Szkoda, naprawdę, ale takie są realia. Sprawę pogorsza fakt, że na takich serwisach jak ocenpracodawce.pl, zwykle piszą albo frustraci, których wywalono z roboty, albo sami pracodawcy, żeby podnieść sobie rankingi. Nie istnieje nic takiego jak średnia dolnośląska czy średnia wrocławska. U jednego pracodawcy X złotych może zarobić już początkujący programista, u innego na start można otrzymać co najwyżej 2/3 tej sumy. Osobiście wydaje mi się, że należy przekalkulować ile się wie i jak się samego siebie ocenia, następnie zrobić research wśród znajomych i kolegów ile zarabiają i odnosząc się do ich wiedzy i umiejętności odnaleźć, gdzieś tam swoją średnią.

Najważniejsze jest jednak, żeby się CENIĆ. Warto to powtórzyć dwa razy: najważniejsze, żeby się cenić. Znam przypadki kolegi, który pracował w firmie IT we Wrocławiu za 1600zl na rękę. Przepraszam, ale w obecnej dobie to się robi po prostu śmieszne. Albo przykład, o którym już kiedyś pisałem, chłopaka, który przez 3 miesiące pracował za darmo na "praktykach" mimo, że wykonywał robotę taką jak wszyscy inni w firmie. Pracodawcy widząc osobę, która aż się prosi, żeby ją wykorzystać, zrobią to, bez wahania. Nigdy, prze nigdy, nie bądźcie takimi osobami! Ceńcie się za swoją wiedzę i doświadczenie. Dla dobra swojego i naszego ogółem.

ciąg dalszy nastąpi....

Porsche nie w najbliższym czasie...

W najbliższym czasie na Porsche raczej mnie nie będzie stać. Wydawać się by się mogło oczywistość - mam 24 lata, na Porsche przyjdzie jeszcze czas... jeśli w ogóle.

Ale ja miałem plan!! Piękny, genialny, plan. Oczywiście serwis (praktycznie nie)społecznościowy, no bo cóż innego mógłbym wymyślić? Jestem informatykiem, od czasów naszej-klasy, każdy z mojej branży pluje sobie w brodę - "przecież ja to mogłem zrobić". Ale ten pomysł był naprawdę świeży, oryginalny. Czegoś takiego na świecie nie było.

No i pielęgnowałem tą ideę, liczyłem dni do końca pracy magisterskiej. Pomysł powstał rok temu, a ja spokojnie sobie czekałem. Plan był prosty: skończyć studia, a następnie zabrać się za to z kopyta i po dwóch latach jeździć nowiutkim Porsche :)

Co się okazało? Pracę oddałem do recenzji 8 czerwca, 2 tygodnie wcześniej powstał portal, w założeniach identyczny do mojego pomysłu. Po prostu taka kopia jeden do jednego. Grrrrr.... jestem zły, wściekły i wkurzony. Jak jeszcze im to wyjdzie, serwis wypali, zdobędą sławę, kobiety i pieniądze, to się chyba po prostu potnę ;).

Rada dla wszystkich: uczcie się na moich błędach. Zwlekanie nie popłaca. Jak coś Was natchnie, bierzcie się od razu do roboty. W innym wypadku będziecie potem tak jak ja, przez dwa dni gryźć klawiaturę, a trzeciego dnia wylewać swoje frustracje na blogu.

Rails 2.1

Jeszcze niedawno pisałem o problemie jaki stawia przed młodym adeptem Railsów wybór wersji (1.2.6 vs 2.0.2), a już zdążyła wyjść kolejna wersja RoR opatrzona numerkiem 2.1. Z taką prędkością z jaką rozwija się się framework (półroku kolejne wydanie) trudno będzie nadążyć chyba jakiemukolwiek autorowi książki. Nie mamy jeszcze książki na świecie o Rails 2, (bo nawet The Rails Way opisuje wersję edge) a tu już ogłoszono Railsy w wersji 2.1.

Oczywiście wszystko to ma swoją logikę, w Portland odbywa się teraz konferencja RailsConf i jak to bywa na konferencjach, trzeba coś ogłosić - taka już natura chyba każdej większej konferencji :). Ale fakty pozostają mimo wszystko te same: framework się rozwija, co cieszy niezmiernie.

Jeśli ktoś jest żądny wiedzy co nowego w najnowszych railsach, może przeczytać wpis na oficjalnym blogu frameworka. Ja narazie w szczegóły wdawać się nie będę, bo po prostu nie czuję się kompetentny. Gorąco zachęcam natomiast do obejrzenia RailsCast'ów poczynając od #106 do #109 włącznie, gdzie Ryan Bates opisuje najnowsze featury w Rails 2.1. Warto obejrzeć wszystkie, nawet jeśli jesteś takim newbs'em jak ja ;).

Java Killers #007

Witam na kolejnej odsłonie cyklu Java Killers. Dzisiejszy przykład jest hybyrdą przykładu nadesłanego przez Damiana Szczepanika oraz małego triku, który znalazłem na sieci (niestety źródło zapodziałem :( ). Myślę, że dzisiejszy JK nie powinien sprawić kłopotu nikomu, kto zdawał SCJP, ale kto wie, moze się mylę?
Zatem spojrzmy na naszych bohaterów, trzy klasy: Matcher1, Matcher2 oraz Matcher3.

 1 package javakillers.part007;
 2
 3 /**
 4  * @author pawel
 5  */
 6 public class Matcher1
 7 {
 8        void g(int x)
 9        {
10                System.err.print("int ");
11        }
12
13        void g(long x)
14        {
15                System.err.print("long ");
16        }
17
18        void g(Integer x)
19        {
20                System.err.print("Integer ");
21        }
22 }
23
24

 1 package javakillers.part007;
 2
 3 /**
 4  * @author pawel
 5  */
 6 public class Matcher2
 7 {
 8        void g(short x)
 9        {
10                System.err.print("short ");
11        }
12
13        void g(byte x)
14        {
15                System.err.print("byte ");
16        }
17
18        void g(long x)
19        {
20                System.err.print("long ");
21        }
22
23        void g(Integer x)
24        {
25                System.err.print("Integer ");
26        }
27 }
28
29

 1 package javakillers.part007;
 2
 3 /**
 4  * @author pawel
 5  */
 6 public class Matcher3
 7 {
 8        void g(int x)
 9        {
10                System.err.print("short ");
11        }
12
13        void g(Integer x)
14        {
15                System.err.print("Integer ");
16        }
17 
18        void g(Object x)
19        {
20                System.err.print("Object ");
21        }
22 }
23
24

I na koniec metoda, która to wszystko uruchomi:

 9     public static void main(String[] args)
10     {
11         int prim = 10;
12         Object obj = prim;
13         Integer intObj = (Integer) obj;
14    
15         new Matcher1().g(prim);
16         new Matcher2().g(prim);
17         new Matcher3().g(obj);
18         new Matcher3().g(intObj);
19     }

Pytanie, które pozostaje otwarte, to co zwróci nam wywołanie tej metody? Odpowiedzi do wyboru aż sześć:

A) int Integer Object Integer
B) int long Object Integer
C) int Integer Integer Integer
D) int long Integer Integer
E) Integer Integer Integer Integer
E) Integer Integer Object Integer

Zanim przeczytasz rozwiązanie, spróbuj pomyśleć nad odpowiedzią.

Prawidłowa odpowiedź to oczywiście B) int long Object Integer. Aby zrozumieć czemu tak a nie inaczej należy wiedzieć, że przekazując metodzie wartość typu innego niż się spodziewała, dokonana zostaje konwersja typów (method-call conversion jeśli chcemy się trzymać terminologii). Konwersja jest możliwa tylko, jeśli typ metody jest "szerszy" (ang. widening conversion) od typu przekazywanego. Tak więc int'a przekażemy do metody z longiem ale nie na odwórt. Typy od "najwęższych" do "najszerszych" uszeregowane są następująco:

byte -> short -> int -> long -> float -> double

Ot i cała filozofia. Odnośnie ostatniego Matchera3, w pierwszym przypadku spodziewamy się obiektu klasy Object i ją dostajemy, w następnym wywołaniu obiektu klasy Integer i ją dostajemy. Mimo że jest to wciąż jeden i ten sam obiekt, to jednak kontekst wywołania jest różny, stąd i inne dopasowanie typów podczas wywoływania metody.

Nauka Rails - 1.2.6 vs 2.0.2

Railsy mają coś w sobie! Kropka. Nikogo przekonywać nie będę. Sam widziałem po prostu kilka prezentacji, poczytałem kilka blogów, widziałem Railsy oraz Rubiego w akcji na videotutorialu, wygenerowałem sobie kilka prostych aplikacji i jestem zdeterminowany aby język Ruby oraz same Railsy poznać dokładnie.
Myślisz jak ja? Chcesz nauczyć się Railsów? Widzisz, mamy problem. Kilka miesięcy temu wyszła nowa wersja frameworka opatrzona numerkiem 2. Rails 2.0.x wprowadza trochę zmian, kilka nowości, trochę usprawnień i nie byłoby w tym nic strasznego, gdyby nie fakt, że parę rzeczy zostaje przeniesionych, inne się dewaluują, jeszcze inne całkowicie znikają. Framework nie do końca wierzy w ideę kompatybilności wstecznej. Problem jest, bo bodaj najlepsza dostępna obecnie na rynku książka "Agile. Programowanie w Rails" traktuje o Railsach w wersji 1.2.6. Początkujący programista może się zdziwić, że przykłady z pierwszych 170 stron książki w ogóle nie działają (dynamiczny scaffolding został usunięty z Railsów 2).

Pytanie pozostaje co zrobić? Na forum http://www.rubyonrails.pl temat był poruszony i większość osób zgodnie stwierdziła, że warto uczyć się Railsów z książek w wersji 1.2.6 i potem doczytać o zmianach, które zaszły w wersji drugiej. Myślę, że podejście to nie jest złe. Aby zainstalować Railsy w starszej wersji należy dodać jedną opcję więcej podczas instalacji:

gem install rails --version 1.2.6

To było proste. Jest jednak jeszcze jeden mały szczegół, o którym można zapomnieć. Tworząc nową aplikację railsową należy uwzględnić wersję. Tworząc przykładową aplikację Składnica (składnica = depot :) ) z książki "Agile. Programowanie w Rails", należy wywołać komendę rails z dodatkową opcją:

rails _1.2.6_ depot

Ja osobiście postanowiłem się uczyć Railsów z książki "Agile. Programowanie w Rails", z zainstalowanymi Railsami w wersji 2.0.2. Z większość zmian, które zaszły i o których mi wiadomo, jestem sobie w stanie poradzić:

* sqlite3 domyślną bazą danych zamiast mysql - wystarczy zainstalować sqlite3 i gotowe, nic strasznego

* brak scaffolding'u - dynamiczny scaffolding nie został tyle usunięty co przeniesiono go jako osobny plugin. Wystarczy uruchomić

script/plugin install scaffolding

aby przykład Składnica z książki APWR działał.

Zmian jest jeszcze zapewne trochę, ale myślę ze z pomocą google, poradzę sobie w trakcie napotykania problemów. Po przerobieniu APWR z pewnością przeczytam "The Ruby Way" autorstwa Obie Fernandez'a. Jedna z niewielu książek wchodząca daleko w szczegóły działania frameworka, a co ważniejsze opisującą Railsy w wersji 2.0.2.

Instalowanie Ruby oraz Ruby on Rails na Ubuntu 8.04 Hardy Heron

Poniżej zamieszczam instrukcję instalacji języka Ruby (w wersji 1.8) oraz frameworka Ruby on Rails na najnowszej wersji Ubuntu 8.04 Hardy Heron. Podstawowa zasada (powołując się tutaj na wiki.rubyonrails.org) to instalacja Rubiego prosto z repozytorium Ubuntu, zainstalowanie gem'ów (będących repozytorium Rubiego) ze źródła, a na końcu zainstalowanie Railsów z użyciem gemów. Każda inne podejście obarczone jest jakimś problemem czy innym ryzykiem. Nie będę się wdawać w szczegóły (bo ich po prostu nie znam) i podam od razu gotowy przepis:

1. Instalacja Ruby w wersji 1.8

~$ sudo apt-get install ruby irb ri rdoc ruby1.8-dev libzlib-ruby libyaml-ruby libreadline-ruby libncurses-ruby libcurses-ruby libruby libruby-extras libfcgi-ruby1.8 build-essential libopenssl-ruby libdbm-ruby libdbi-ruby libdbd-sqlite3-ruby sqlite3 libsqlite3-dev libsqlite3-ruby libxml-ruby libxml2-dev

2. Ściągniecię i rozpakowanie źródeł, a następnie instalacja gems

~$ sudo ruby setup.rb

3. Aby mięć dostęp do komendy gem, wystarczy zwykły softlink

~$ sudo ln -s /usr/bin/gem1.8 /usr/bin/gem

4. Instlaujemy Rails'y z użyciem gems

~$ sudo gem install rails


Ot i cała magia. Tyle wystarczy aby rozpocząć swoją przygodę z Rubym i Railsami pod Ubuntu.

0 days left...

Dziś oddałem ostatni rozdział pracy magisterskiej na ręce mojej Pani Promotor. Uff... Czeka mnie teraz jeszcze cztery dni wprowadzania poprawek, zmian i sklecenie "Wstępu". Jeszcze łącznie 4 dni i po krzyku. Nie zmienia to faktu, że w końcu mogę troszkę odetchnąć i do łask (po tygodniach przerwy) wraca blog. Strona zalicza obecnie 50 wejść dziennie, co przy ostatnim braku aktualizacji cieszy mnie niezmiernie. Największą popularnością cieszy się wciąż Java Killers oraz (o dziwo?) posty o Lyx'sie - jak widać nie tylko ja doceniłem piękno tego programu:).

W każdym razie po miesiącu męczarni (nadrobieniu ostatnich 4 miesięcy pracy w ciągu zaledwie 4 tygodni) wracam do świata żywych, a wraz ze mną ten blog.

Happy :) :P ?

Back in Black!

Właśnie, po 3 miesiącach przerwy spowodowanej wiadomo czym, wróciłem ponownie na zajęcia YMAA. Trener się zdziwił jak mnie zobaczył i tym mocniej polał niemiłosiernie, jak usłyszał powód mojej absencji. Nie mniej jednak pamiętał kim jestem, a to chyba najważniejsze ;)
A trening jak to trening. Po długiej nieobecności nic się nie pamięta, formę ma się słabą, wylewa się 6 milionów litrów potu z siebie i ogrania Cię takie wszechobecne 'ale-ja-jestem-do-dupy'... Jednak nie ma nic piękniejszego jak powrót (lub próba powrotu) do domu, człowiek jest wtedy jakiś taki zmęczony, ale i rozradowany zarazem. Idzie się może włócząc trochę nogami, ale to uczucie zajechania organizmu wysiłkiem fizycznym jest po prostu tego warte.
Świat jakiś od razu wydaje się piękniejszy i to krzesło przy biurku, które jeszcze 3 godziny wcześniej właziło Ci w dupę, nagle staje się jakieś takie wygodne, miłe i przytulne... Tak tak moi mili, nie ma nic przyjemniejszego jak powrót z treningu. Wszystkim serdecznie polecam!