🚀 go-pugleaf

On Sat, 17 May 2008 19:05:27 +0200, Marcin Gryszkalis <mg@fork.pl> wrote:
>
>> zapomnij o IDE (ja uzywalem Eclipse). najlepszy jest dobry, lekki edytor
>> (w pracy uzywamy TextMate) plus porzadne srodowisko z linia polecen  
>> (czyli
>> bash z odpowiednimi skrotami, aliasami itp.) im szybciej pozbedziesz sie
>> naiwnej wiary, ze IDE jest Ci do czegos potrzebne w Rubym, tym lepiej :)
> Prawdę mówiąc w aktualnych wersjach nie narzekam na ciężkość NB, ale
> faktycznie sam zazwyczaj piszę w lekkim edytorze opartym na Kate-part z  
> KDE
> (szczególnie w perlu). Natomiast IDE używam ze względu na
>  - debugger (do dyskusji niżej ;) )
>  - refactoring (tutaj odpada jak rozumiem)

dlaczego mialby odpadac? podstawowe rzeczy (rename method czy rename  
class) jestes w stanie zrobic dobrym edytorem. NB i Eclipse daja tez  
troche bardziej zaawansowane funkcje. rzeczy typu extract variable czy  
extract method mozna zrobic makrem w TextMate. w czym problem?

>  - podpowiedzi (tutaj odpada niestety)

ale, jak pisalem, sa inne mozliwosci. Ruby to nie Java i na prawde latwiej  
sie w nim polapac.

>  - ładne wsparcie dla subversion czego Kate nie ma

ale bash ma :) ja sobie porobilem aliasy na najczesciej uzywane funkcje i  
nie narzekam. z tego co wiem, koledzy z zespolu uzywaja tez obslugi SVN  
wbudowanej w Textmate.

w codziennej pracy uzywam 5 funkcji SVN: status, update, commit, add,  
remove. dodatkowo w Textmate od czasu do czasu: blame, diff, log. czy  
naprawde trzeba miec do tego jakies wodotryski?

>> podpowiadanie metod - zapomnij o tym :) nie potrzebujesz tego.
>> potrzebujesz tylko dobrego helpa z lista wszystkich metod (polecam
>> gotapi.com)
> trochę mi to wygląda na "nie możemy tego mieć to powtarzajmy wszyscy  
> razem
> głośno >>podpowiedzi są niepotrzebne<< - może uwierzymy" :)

nie, to brzmi jak: Ruby jest prostszy od Javy :)

> Biblioteka
> standardowa JDK zawiera prawie 3500 klas,

Ruby jest prostszy od Javy :)

> większości z nich nie uzywasz na
> codzień - naprawdę jest to przyjemne jeśli nagle potrzbujesz użyć jakies
> URLConnection i nie musisz szukać po dokumentacji czy metoda  
> getHeaderField
> bierze jako argument int czy String

"int czy String" to jest dokladnie 0 informacji. powinienes pytac, "co" ma  
byc argumentem (np. host albo nr portu), a nie "jakiego to jest typu". jak  
bedziesz wiedzial "co", to typ bedzie mniej lub bardziej oczywisty.

> i co zwraca

j/w

> - bo po ctrl-spacja masz
> przed nosem opis właśnie tej metody.

masz opis jak masz kod zrodlowy do jara podpiety w odpowiednim miejscu w  
IDE, a w nim javadoce. jak nie masz, to widzisz tylko typy. czyli jak  
pisalem wyzej, masz tylko tyle informacji, zeby zadowolic marudny  
kompilator. ale to jeszcze nie znaczy, ze program bedzie dzialal tak, jak  
bys chcial.

> Nie mówie, że jest to niezbędne bo w perlu pracuję w oparci o podpowiedzi
> oparte na wystąpieniach stringów w otwartch plikach (chyba to to samo o
> czymi pisałeś w kontekście textmate) i też da się żyć :)

no widzisz. IMHO czesto jest to lepsze, niz podpowiadanie metod w IDE, bo  
w kodzie czesto powtarzaja sie te same identyfikatory, i to nie tylko jako  
nazwy metod.

>> zapomnij o debuggerze :) w czasie roku pracy z Rubym nie uzylem go ani
>> razu. testy, irb i p Twoimi przyjaciolmi. prawdziwymi przyjaciolmi.
>> debugger nie jest Twoim przyjacielem. bedzie Ci wmawial ze jest, ale tak
>> na prawde jest jak diler narkotykow :)
> eee... w czym ci zawiniły biedne debuggery, że masz o nich takie złe
> zdanie? :)

mi w niczym, bo nigdy nie dalem sie uzaleznic :) ale jak czasem czytam, co  
inni wypisuja o debuggerach, to mam podejrzenie, ze sie uzaleznili.

dla mnie antidotum jest proste: testy jednostkowe, czytanie stacktrace'ow,  
prosty kod (nie za dlugie metody, nie za duzo zmiennych, nie  
kombinowanie), w ostatecznosci "p zmienna" i jazda. dobre pokrycie testami  
czesto zastepuje debugger, gdyz odpalajac jedna metode od razu wchodzisz  
do kodu, ktory chcesz sprawdzic. kilka prob z p i wiesz o co chodzi.

>> i znow: w czasie roku pracy z Rubym chyba nigdy nie zastanawialem sie
>> "wlasciwie jakiego typu jest dany obiekt?". w 99% to albo jest  
>> oczywiste z
>> kontekstu, albo nie ma znaczenia.
> A widzisz, ja się zastanawiałem, bo na przykład moja klasa serwera
> dziedziczy z SOAP::RPC::HTTPServer, który ma jako parent
> napisany "Logger::Application" - a faktycznie jest oparty na na Webricku.
> Dokumentacja konstruktora jest porażająca wręcz:
> http://www.ruby-doc.org/core/classes/SOAP/RPC/HTTPServer.html

no rzeczywiscie, dokumentacja do tej klasy jest fatalna. i to jeszcze jest  
klasa ze standardowej biblioteki, jezeli dobrze rozumiem? jak juz pisalem:  
SOAP - bleeee :)

> To akurat jest całkiem fajne :) A już najbardziej mi się podoba z takich
> bazowych rozwiązań, że fałsz to fałsz i nie ma nic wspólnego z 0 albo 1
> (tak na marginesie).

a wiekszosci sie nie podoba :) ale zawsze mozna sie pobawic w  
przedefiniowanie operatorow logicznych dla 0 :P

>> musisz pozbyc sie podejscia typowego dla javowcow, czyli "wszyscy
>> programisci (poza mna) chca mi (i/lub sobie) zrobic krzywde".
> Na szczęście nie jestem typowym javowcem i robię też duże rzeczy w perlu
> gdzie bez przerwy robimy sobie na wzajem krzywdy i nadal jest fajnie ;)

LOL

pzdr
	szeryf

-- 
Przemysław ,,Szeryf'' Kowalczyk :: http://szeryf.wordpress.com/