Showing posts with label Ruby. Show all posts
Showing posts with label Ruby. Show all posts

Saturday, November 19, 2011

Scala - scratch the surface

Nareszcie! Trafiłem na naprawdę fajne wprowadzenie do języka Scala, które ostatecznie dało mi posmak tego języka, zobligowało do za instalowania Scala IDE na komputerze i napisania kilku prostych klas, oraz fragmentu kodu.

Mowa oczywiście o Scala for Java Refugees Daniela Śpiewaka, żałuję tylko, że nie trafiłem na to trzy lata temu (wpisy są z 2008 roku), ale może to była też kwestia dojrzewania do tego języka? Nie wiem. Wiem jedno, że język jest naprawdę fajny, chociaż w przeciwieństwie do Rubego - to co napiszę zdarza się nie działać.

Język jest ogromny i jego poznawanie może mieć wyłącznie charakter stopniowy. Jest tego po prostu za dużo. Zresztą, każdy język programowania ma obszary, których nigdy nie potrzebowałeś, nie używałeś - Scala ma ich po prostu więcej.

Na razie jednak zaczynam pisać projekt w Rails-ach, a w świecie JVM przygotowuję się do Certyfikatu wydawanego kiedyś przez Sun, a teraz Oracle, dla programistów Java. Tak więc "mieszanie" sobie Scali z Javą może być niebezpieczne na tym etapie. Do następnego razu.

Thursday, November 17, 2011

PhantomJS i Ruby - czyli przygody małe i duże

No więc stało się. Jestem programistą Javy. I co z tego? A no trzeba w domu jakoś odreagować.
Na pierwszy ogień poszedł Ruby i to nie byle jaki jak 1.9.3-p0. Windowsowa paczuszka ściągnięta wprost z RubyInstaller ślicznie zadomowiła się w moim systemie operacyjnym, dając mi nawet w trakcie instalacji dodać poleceni ruby do ścieżki systemowej.

No ale nie o Rube-go chodzi tylko o chęć napisania jakiegoś drobiazgu z meta-programowaniem. No więc potrzebny jest edytor.

gem install redcar
redcar install
redcar
I moim pięknym oczom ukazał się turbo edytor RedCar - i od razu zrezygnowałem nawet z myśli o płaceniu za TextMate na Mac-u. Napisałem sobie bardzo prosty program, który pozwolę sobie dumnie nazwać klient "REST". Tak naprawdę to prawie na jedno by wyszło jakby podziedziczył po Net::HTTP, ale że miało być "meta-programowanie" to wyszło tak:


require 'net/http'
require 'uri'

class REST
def self.method_missing(m, *args, &block)
uri = URI(args[0])
Net::HTTP.start(uri.host, uri.port) do |http|
puts "Calling #{m} REST call."
return http.send(m.downcase.to_sym, uri.path)
end
end
end

res = REST.GET("http://www.google.pl/")
puts res.body


Nikt, nie mówił, że jest się czym chwalić, ale coś mnie tchnęło, żeby pobrać (a co) zawartość wyżej wymienionej strony w PhantomJS. Trwa to wieki i gdyby tak działała przeglądarka to pewnie zrezygnowałbym z Internetu, albo kazał, za korzystanie z niego, sobie płacić, ale ... na szczęście Google Chrome ładuje WebKit raz a nie za każdym razem gdy otwieram zakładkę - więc da się żyć. Na stronie projektu, gdy napisałem już skrypt w JavaScript zauważyłem, że mogę też podawać skrypty w CoffeeScript pominę więc moje wypociny w JS i podam odrazu wersję Coffee, a jak interesuje Cię co napisałem w JS to wklej sobie poniższą zawartość na stronie Try CoffeeScript i będziesz wiedział.

page = new WebPage()

if phantom.args.length == 0
console.log 'Usage: google.coffee some-url'
phantom.exit()
else
t = Date.now()
address = phantom.args[0]
page.open address, (status) ->
if status != 'success'
console.log 'FAIL to load the address'
else
t = Date.now() - t
console.log 'Loading time ' + t + ' msec'
console.log 'Page content is \n' + page.evaluate () ->
document.documentElement.innerHTML
phantom.exit()


Edytor kodu na Blogger jak zwykle daje ciała nie wspierając wstawek kodu źródłowego, ale co tam. Najgorsze, że RedCar nie ma wsparcia dla CoffeeScript, ale może się dorobi jak skończy być Alphą. No nic, czas kończyć. Na dziś starczy już tego dobrego wracamy do Thinking in Java, którego autor i tak co 100 zdanień kończy stwierdzeniem w stylu "Java to ogromny krok na drodze postępu w tej dziedzinie, ale Python i tak robi to lepiej."

P.S. Moim ogromnym odkryciem w Ruby było odkrycie, że każdy operator to metoda. Kiedyś nie mogłem znaleźć w dokumentacji co dokładnie robi ~= (czy tam =~) bo szukałem jakiegoś działu dokumentacji Ruby-Doc, który definiowałby operatory zamiast sprawdzić metodę =~ klasy String albo RegExp.

Saturday, September 3, 2011

Ruby On Rails 3.1 - dzień pierwszy

Zawsze uważałem, że najlepszy poradnik, to zbiór wskazówek pisanych przez początkującego, nie koniecznie zaś zapełniane przez mądrego człowieka annały, które jak na początek, mogą być za mądre. Równocześnie, najlepiej aby początkujący miał już doświadczenie z innymi podobnymi zagadnieniami  jednak w danej technologii był początkujący. Taki układ daje duże szanse, że poradnik będzie profesjonalny, pisany prostym językiem i zrozumiały dla maluczkich, którzy oczekują prowadzenia krok po kroku. Mam nadzieję, że moje wpisy o Ruby On Rails 3.1 takie właśnie będą.

Dlaczego?

Mam za sobą już, od jakiegoś czasu, Rails for Zombies, czytałem o Ruby On Rails i jeszcze nigdy nie spotkałem się z osobą, która zaczęłaby kurs Railsów od RVM. Podstawy podstaw - jak na mój gust.

Gdy piszesz jakikolwiek program, aplikację musisz zdecydować się na dwie rzeczy: wersję języka programowania i wersję pozostałych bibliotek, które używasz. U mnie to wygląda tak: zaglądam na stronę języka programowania (w tym przypadku języka Ruby), zaglądam na stronę biblioteki (w tym przypadku Railsów) i nakręcam się na napisanie aplikacji w najnowszej wersji, która wprowadza najświeższe udogodnienia, nowości, nowatorskie technologie i wszystko co sprawia, że bycie geekiem jest piękne i pełne wrażeń jak przejażdżka górską kolejką w parku "Six Flags Great Adventure".

Później przychodzi faza druga, która nazywa się "sprawdźmy co jest na serwerze" i ta przynosi znacznie więcej rozczarowań, niż radości dopóki nie używasz ArchLinux lub nie jesteś twórcą biblioteki, której właśnie zamierzasz użyć. Wtedy klniesz pod nosem, że "przecież administrator mógł przejść na sida" i jakbyś tylko miał uprawnienia użytkownika root!
I tutaj właśnie objawia się piękno RVM. Pozwala ono bowiem bez uprawnienia super-użytkownika zainstalować dowolne wersje języka Ruby, w locie podmieniać interpreter oraz wersje używanych bibliotek, które w wielu różnych kombinacjach mogą koegzystować w wirtualnych środowiskach zwanych gemsetami. Wszystko bez wychodzenia poza katalog domowy.

Sunday, May 16, 2010

Fabric - Pythonowe Capistrano

Wczoraj trafiłem na Fabric - Pythonowy odpowiednik Capistrano. Już czuję, że je polubię :] Zapowiada się naprawdę świetnie! Na znalezisko natknąłem się buszując po Rubo-wych narzędziach do pracy z kodem równocześnie porównując z Jarkiem Zabiłłą Ruby Python. Ruby: Rack, Python: WSGI, Ruby: Sinatra, Python: WerkZeug, Ruby: Rubinius(wyszła wersja 1.0), Python: PyPy, Ruby: Merb(byłem w szoku, że nadal jest rozwijany), Python: Pylons(jest wersja 1.0 beta 1!), Ruby: Capistrano ... Python? Tak jest Fabric!
Narzędzie jest bardzo młode (takiego wrażenie sprawia) i nie trafiłem w nim na żadne opcje związane z konkretnym systemem wersjonowania (jak w Capistrano), ale to nic :) bo może być to kwestią czasu a jeżeli nie to konwencji - wszak można użyć poleceń systemowych :]
Co do kolejności - tutaj było różnie. Rack powstał bo Rubowcy pozazdrościli Pythonowi WSGI, Fabric bo nie było odpowiednika Capistrano w Pythonie. Nie ma to jednak większego znaczenia :) Dobrze, że oba języki programowania dobrze radzą sobie w szerokim spektrum zagadnień i udostępniają wygodne narzędzia :] Ja się cieszę.

Thursday, May 13, 2010

Przygoda z Merbem i jak przeszedłem na Sinatrę

Dzisiejszej nocy nadszedł czas, gdy miałem okazję zmierzyć się wreszcie z Merbem. Znany mi świat frameworków to raczej rozwiązania typowe dla Pythona. Byłem bardzo mile zaskoczony poznając świat frameworków Ruby.
Do tej pory nie było żadnego małego projektu, od którego można byłoby zacząć naukę. Stworzenie wyszukiwarki dla kampani 1% dla ZHR.pl było fantastyczną okazją do liźnięcia Merba.
Pierwszym rozczarowaniem, była walka z samym Merbem. Zainstalowałem nowe gemy Merba 1.1.0. Pamiętał, że jest coś takiego jak wersja flat aplikacji. Bardzo zależało mi na tym właśnie modelu. Już na samym początku trafiłem na bug Merba #712. To było niestety bardzo bolesne spotkanie z rzeczywistością, które pozostawiło mnie bez złudzeń - Merb nie jest już rozwijany.
Kolejną niemiłą niespodzianką było odpalenie mongrela. Na szczęście tutaj pomogło dodanie require 'mongrel' do skryptu merb w katalogu bin projektu i skorzystanie z tak zmodyfikowanej binarki. Co gorsza, wcześniej straciłem kilkadziesiąt minut na odpalaniu webricka, który w ogóle nie łykał urlsów.
Skoro już jesteśmy przy dodatkowym sofcie. Najnowsza wersja Haml 3.0.2 nie radzi sobie z renderowaniem SASS, który kończy się błędem jak w issue #163. Wszystko działa natomiast bez problemu z najnowszą wersją Haml z gałęzi 2. Aha. Najlepsze jest to, że istnieje masa nieaktualnej dokumentacji. Szczególnie bolesne gdy chodzi o włączenie SASS. Nawet dokumentacja SASS podaje jakieś lewe informacje. Dopiero ten wpis pozwolił mi prze konwertować SASS do CSS.
Takie przygody to chleb powszedni, jeżeli oprogramowanie nie jest rozwijane od ponad roku. Nie ma się co dziwić. Najgorsze jest dla mnie to, że w Rails 3 nie ma czegoś takiego jak merb-gen flat czy merb-gen very_flat. Można obciąć to co generuje Rails 3 ale to wciąż nie jest minimalna aplikacja z własną konfiguracją. Trochę pocieszyła mnie Sinatra. Kiedy w niej kodowałem to przypomniał mi się Pythonowy WerkZeug, z tym, że w przeciwieństwie do tego drugiego Sinatra działa :P Ciekawe, że Sinatra to DSL :) co daje bardzo miłe wrażenie kodowania w zetknięciu z nią :]
Kiedy przenosiłem aplikację z Merba na Sinatrę to właściwie jedyne co musiałem zrobić poza przekopiowaniem plików statycznych i widoków to zmienić rozszerzenie widoków HAML. Reszta sama poszła. Bardzo spodobał mi się minimalizm Sinatry, który w przypadku wyszukiwarki jaką piszę był w dziesiątkę! Niestety to nie to samo co modularny Merb, który jak trzeba było to poza wygenerowanie małej aplikacji potrafił i kapcie przynieść i kawę zaparzyć. Rails nie posiada tak rozwiniętej modularności w stopniu w jakim została stworzona w Merbie - a szkoda.
Jeżeli miałbym porównać świat frameworków Pythonowych i Rubowych to tutaj jest jak z językiem - Python prosto, Ruby z dużo bogatszym wachlarzem możliwości. Mam wrażenie, że deweloperzy Pythona skupili się na prostocie jako celu, gdzie w Rubym widać dążenie do niej ale przez wszystkie etapy ogólności, które widać w wielu narzędziach.
Na tle tych przygód jest jeszcze gdzieś Scala, która wydaje mi się tak zaawansowana, że aż nie widzę dla niej zastosowania w projektach, które tworzę. To jest chyba jakiś target heavy enterprise a ja jeszcze w tych kategoriach nie myślę. Szalenie podoba mi się tutaj Merb, w którym możesz zacząć sobie dewelopować aplikację od jednoplikowej wersji very_flat po typowo railsowym bufoniastym systemie układu katalogów skończywszy. Szkoda, że Rails 3 nie daje takiego wyboru. Na szczęście jest Sinatra :) jednak jak już pisałem, Merb był gdzieś pomiędzy i szkoda, że go już nie ma.

Tuesday, March 2, 2010

Gdyby pieniądze Microsoftu ...

Ostatnio kolega podesłał mi ciekawy artykuł Python + Django vs. C# + ASP.NET: Productivity Showdown. Złożyło się to z rozmową z jednym z moich współlokatorów o doświadczeniu pisania w .NET aplikacji webowych.

Przytoczny artykuł pokazuje w skrócie, że kilku niedoświadczonych programistów zaczynających swoją przygodę z Django może pobić wydajnością większą grupę doświadczonych C# piszących ten sam projekt w ASP.NET. To pokrywa się z moimi doświadczeniami z pracy. Jednak w tym wpisie chciałem zwrócić uwagę na coś innego.

Model MVC - pierwszy raz opisany w 1797 został zastosowany we wszystkich znanych mi frameworkach i okazał się dobrym rozwiązaniem. Microsoft dopiero w 2009 r. wypuścił stabilną wersję MVC.NET. Iron Python i IronRuby to próba nadgonienia przepaści pomiędzy ASP.NET a światem rozwiązań Open Source, w końcu umożliwienie wchłonięcia dobrodziejstw wszystkich projektów typu Django czy Ruby On Rails.

Ilość pieniędzy wpakowana w ASP zapewne jest ogromna. Zastanawiam się w jakim miejscu bylibyśmy dzisiaj gdyby te same środki przeznaczyć na rozwój takich projektów jak Ruby On Rails, Django, Pylons, Web2Py, Lift ,Merb czy chociażby Drupal.

Są to projekty o skromnych funduszach lub powstające niemalże wyłącznie dzięki dobrej woli wolontariuszy. Niemniej łamią stereotypy, wyznaczają nowe trendy w tworzeniu aplikacji sieciowych, są ponadczasowe a rozwiązania w nich zastosowane wyprzedzają swoją epokę. Gdzie byłby dzisiaj świat gdyby przeznaczyć na tego rodzaju projekty pieniądze jakie Microsoft zainwestował w ASP?

Odpowiedź na to pytanie istnieje. Masz ją nawet "przed oczami" lub na stronie startowej twojej przeglądarki. Tak jest! Zgadłeś! Odpowiedzią jest - Google.
Google jest jedyną znaną mi firmą, która powszechnie na dużą skalę korzystała z dobrodziejstw rozwiązań Open Source i inwestowała w nie pieniądze. Adaptacja jądra Linuksa w projekcie Android, własne patche do MySQL czy zmodyfikowany Python to tylko niektóre przypadki sukcesu Google w wykorzystywaniu tego co już zrobiono i udostępniono za darmo.

Wiele firm z powodzeniem korzysta z całych środowisk, ekosystemów udostępnianych przez Microsoft: serwery, usługi, fora, wiki, blogi, platformy multimedialne, narzędzia do pracy zdalnej i grupowej, aplikacje biurowe. Przykładów można byłoby mnożyć i mnożyć. Wtedy tworząc narzędzie dla firmy jesteś "zmuszony" tworzyć go w .NET. Być może nie jesteś zmuszony wprost ale jednak aplikacje pod produkty Microsoft pisze się najlepiej właśnie z użyciem tych technologii. Ba! Wyobraź sobie reakcje wyższego managementu na zażądanie Apache 2 i Python bo chcesz pisać coś w Django - kiedy oni wydali setki tysięcy dolarów na produkty firmy Microsoft. A Ty chcesz im powiedzieć, że niepotrzebnie - bo użyjesz sobie darmowego softu? Zbrodnia!

Może troszkę udemonizowałem scenariusz w poprzednim akapicie, ale to wyjaskrawienie jest moim zdaniem potrzebne. Google jest jedynym przedsiębiorstwem, w którym nie widać wszechobecności technologii Microsoftu. Z mojego punktu widzenia wygląda to tak, że Google chce wciąż mieć wybór w tym czego i jak używają. Czuć się dzięki temu wolnym i nieskrępowanym co czyni z nich niesamowicie elastyczną i innowacyjną firmę.

Mam wrażenie, że języki programowania znane ze świata Open Source ukierunkowują "na zewnątrz" zaś języki Microsoft "do wewnątrz". Python, Ruby czy Scala nie są związane z żadną konkretną technologią i dlatego powstające na ich bazie rozwiązania ukierunkowane są na nowe cele wyznaczające nowe kierunki. Tak robi Google i wiele innych firm kiedy tworzy coś nowego: Gmail, Google Docs, Youtube, Facebook, Twitter.
Platformy programistyczne Microsoft wymagają zawsze włożenia gro wysiłku w opracowaniu ich "pod systemu Microsoftu". Są więc ukierunkowane "do systemów Microsoft" działania z nimi, stworzenia API i do tego najlepiej się nadają - tworzenia własnych narzędzi dobrze zintegrowanych z ekosystemem ze stajni Billa Gatesa.

Myślę, że właśnie to "przywiązanie", to "zaplecze" jakie musi posiadać każda nowo powstała technologia wytwarzania oprogramowania z Microsoft sprawia, że nie starcza już tym technologiom "pary" aby stać się technologią, w której powstanie coś ponad epokowego i łamiące współczesne standardy.

Jak już wspominałem przywiązaniu temu nie podlega Google, wybierające do realizacji projektów technologie, które pozwalają rozwinąć skrzydła programisto i stworzyć coś - co jeszcze nie istnieje. Nie ograniczając ich ale dodatkowo dając wsparcie ich innowacyjnym pomysłom w stosowanej technologii.

Co więc byłoby gdyby Microsoft wkładał swoje pieniądze w rozwój Ruby On Rails, Django czy innych projektów Open Sourcowych? Mielibyśmy Google świata Open Source :] Czyż nie byłoby to piękne?

Tuesday, February 23, 2010

Rok 2010 rokiem przełomów w aplikacjach sieciowych

To wręcz niesamowite jak wiele dzieje się w tym roku w dziedzinie aplikacji sieciowych. Być może to tylko wrażenie, jakie można mieć co roku ale moim zdaniem jest to rok przełomowy.

Dzisiaj po 2 w nocy wyszła wersja Release Candidate 1 Gallery 3. Jest to ogromny krok w dziedzinie aplikacji do przetrzymywania zdjęć. Większość dostępnych w sieci skryptów zakłada, że istnieje jeden właściciel galerii, który publikuje w niej zdjęcia. Gallery to jedyny znany mi do tej pory system pozwalający w ramach jednej galerii tworzenie wielu albumów i przydzielania uprawnień do nich wielu użytkownikom.

Gallery posiada pewne bardzo proste - acz daleko idące w skutkach założenie - jeżeli nie masz dostępu do zdjęcia - nie masz do niego dostępu wogóle, nawet poprzez bezpośredni link. Gallery w wersji 2 realizowało to poprzez przetrzymywanie obrazków poza folderami dostępnymi przez Apache zaś każde żądanie pliku PNG, JPG czy innego było tłumaczone przez mod_rewrite na wywołanie skryptu PHP, który sprawdzał uprawnienia do pliku i ewentualnie zezwalał na jego wyświetlenie.

Niestety - przy galeriach dużych rozmiarów całość znacznie rzutowała na wydajność, wygodę i szybkość korzystania.

Gallery 3 to krok milowy w każdej tych dziedzin. Dzięki modelowaniu uprawnień na poziomie plików .htaccess udało się otrzymać wydajny i szybki mechanizm bezpieczeństwa. Celem stało się utrzymanie aplikacji sprawną, lekką i wydajną. Dołożono do tego interfejs oparty o jQuery. Całość zaś oparto na fantastycznym frameworku Kohana.

Kolejne zaskoczenie to milowe w dzidzinie od lat zgłaszanych braków Django 1.2. W końcu poprawki w dziedzinie modeli, obsługa wielu baz danych, zamknięcie wielu ticketów, które od lat straszą na Djangowym bug tracku. Django w końcu przełamuje barierę "argumentu za użyciem Pylons" jakim był brak możliwości obsługi wielu baz danych co czyni go znacznie bliższym zastosowań enterprise.

Skoro już przy Pylons jesteśmy. Nigdy nie wierzyłem, że dożyję dnia kiedy zostanie wydana publicznie wersja Pylons 1.0 beta. Jednak stało się. Pylons pretenduje do wersji stabilnej z niezmiennym API i w końcu może zacząć być używany w projektach gdzie liczy się stałość i ciągłość wersji w aktualizacji 3rd party components.

Nie można też pominąć Rails 3 - chociaż tutaj nie chcę się wypowiadać to z oglądanych przeze mnie prelekcji, wypowiedzi Yehudy Katz oraz wpisów na blogach Polskich Rubystów widać, że Rails 3 jest krokiem milowym w jakości tego frameworka ku doskonałości.

Wszystko wskazuje na to, że również Drupal 7 pojawi się w tym roku. Dwa dni temu została wypuszczona wersja Alpha 2 - co oczywiście w przypadku Drupala kompletnie o niczym nie świadczy - ale zawsze to jakiś krok do przodu. Oby prace poszły szybko - bo zapowiada się naprawdę fantastyczny framework.

Prawdopodobnie jeszcze wiele zaskoczeń czeka nas w dziedzinie aplikacji sieciowych - jednak Luty i Marzec to prawdziwy wysyp. Dzisiejszy dzień to jeden z tych, w których nie mogę uwierzyć, że jest aż tak dobrze. Oby więcej takich postępów i dobrze wykonanej pracy!

Tuesday, November 24, 2009

Ruby on V8, Python on V8? Koniec ery JavaScript?

To nieźle zabiło mi klina. Od tygodnia trafiam na linki związane z odpaleniem jakieś skryptu napisanego w Pythonie czy Ruby na V8.

Ruby on V8
Binding Python to V8
PyV8

Projekty wyglądają raczej na próby i eksperymenty niż realnie zarysowującą się perspektywę wykorzenienia JavaScript. To jednak dobry znak. Wiadomo - V8 pisane jest z myślą o zwiększeniu wydajności JS i jakby "pod JS" dlatego inne języki mogą sobie radzić na tej wirtualnej maszynie różnie, raz znacznie lepiej innym razem gorzej, jednak sam fakt istnienia wirtualnej maszyny w przeglądarce, uświadomienie sobie tego i próby odpalenia tam współczesnych dzisiejszemu światu języków programowania daje nadzieję na przyszłość.

Nie potrafię opisać emocji jakimi napawa mnie myśl wykorzystywania pQuery albo rQuery :) w kombinacji z genialną składnią Pythona czy klasami Rubego. Może dla naszych dzieci


<script src="script.rb" type="text/ruby"></script>
<script src="script.py" type="text/python"></script>


będzie już czymś normalnym:) Pożyjemy zobaczymy! Trzymam kciuki za eksperymenty i żywię głęboką nadzieję na prezentowany w tym wpisie obrót spraw!

Monday, October 19, 2009

Trendy polskie a praca na świeci

Nie wiem co mnie dziś tknęło ale postanowiłem sprawdzić pewną rzecz.
Przeczesując zasoby polskiej sieci, w poszukiwaniu informacji na temat tworzenia witryn internetowych, trafiamy głównie na kursy Ruby On Rails albo Django. Dzisiaj postanowiłem zobaczyć jak sprawa się ma jeżeli chodzi o "jobtrends" na świecie. Wyniki z serwisu Indeed.com/jobtrends poniżej.


O ile popularność Railsów mnie nie zszokowała (może co najwyżej jej skala) o tyle fakt iż Drupal stoi znacznie wyżej niż dziesiątki razy opisywany w polskiej sieci Django - mocno mnie zdziwiło. Czyżby Django przegrywało w świecie biznesu z Drupalem? Może to jakaś wskazówka? Szczególnie, jeżeli planujemy naszą przyszłość w perspektywie pracy programisty. I jak sytuacja ta ma się do polskich warunków pracy? Pytania pozostawiam bez odpowiedzi.

Wednesday, July 29, 2009

Python i Ruby w jednym stali domu ...

... o ASP.NET C# nie mówiąc nikomu.

Bolączki początkującego w ASP.NET

Może to bolączki początkującego programisty a może rozpieszczenie. Nie wiem. Wiem jedno - ASP.NET to "pain in the ass". Ale od początku.
Interfejs stworzył kolega. Tyle wiem o tym jak to się robi. Mu się udało. Ja miałem zacząć wypakowywać go treścią z bazy danych. To co oferuje C# w tym zakresie jakoś nie zachwyca. Zacząłem od tworzenia zapytań w "stringu" i podpinania pod kontrolkę. No i działało... Kiedy już byłem zadowolny ... przypomniałem sobie o SQLInjection :/ Oczywiście funkcji do escapowania nie zaświadczysz w tak nowoczesnym języku jak C#.
Zaświtała mi myśl, aby zobaczyć czy może nie warto (póki czas) przerzucić się na MVC. Składnia SQLowata wbudowana w język programowania fajna, ale totalnie biedna. Bez joinów nie pakuję się w tą zabawę.
Wróciłem więc do zwykłego ASP.NET. Skoro już muszę w tym programować to może stworzę sobie fajną abstrakcję dla bazy danych. Zleciała mi na tym większość dnia. Niestety wybrałem ślepą uliczkę. Tylko dlaczego tak cudowne środowisko jak Visual Studio nie powiedziało mi, że wybierając na target SqlDataReader nie uda mi się go podpiąć jako DataSource do GridView z paginowanie. Nie wiem. A może po prostu nie wiedziało. Tak więc w cudowny sposób stanąłem z gotową, ładną acz kompletnie nieużyteczną klasą do obsługi bazy danych i straconymi 10 godzinami roboczo godzin. Dobrze, że chociaż mi za nie zapłacą.

Maszyna czasu - wskazówka cofa się

Mój dzisiejszy dzień i w ogóle całe programowanie w ASP.NET przypominają mi młodość. Czasy, w których nie wiedziałem co to framework. Czas, w którym wymyślało się koło na nowo. Czas, w którym tworzyło się mnóstwo autorskich rozwiązań.
W ASP.NET to nieunikonione. Nie jeżeli choć troszkę próbujemy dorównać wygodzie oferowanej przez takie technologie jak Django, Pylons, Symfony czy "Drupal Framework". A chyba nie umiem już zaakceptować faktu, że "coś jest źle zrobione".
Pomimo braku wygodnych i dobrze przemyślanych mechanizmów nie natrafiłem na jakiś wysyp "gotowców", które ułatwią Ci życie w sieci. A szkoda. Klasa do porządnej obsługi bazy danych by się przydała. Obecnie - wygląda to dziwnie.
Przyglądając się technologiom stosowanym w ASP.NET mam wrażenie, że tym co tam się znalazło rządziła "burza mózgów". 30 pomysłów, które po prostu zaimplementowano a potem zaczęto się zastanawiać jak to ma razem działać. I coś tam "sklecono". Szalenie niewygodne, nieelastyczne i dziwnie niskopoziomowe.

Pokolenie RuPy

Możemy kłócić się całymi latami o wyższość jednej technologii nad drugą. Idealizować Scalę, krytykować Pythona za niekonsekwencję, Rubego za "abstrakcję". Jednak po dzisiejszym dniu mam to po raz kolejny w nosie. W każdym z tych języków tworzenie witryn to bajka. Żal mi całych mas ludzi, którzy myślą, że ASP.NET to szczyt możliwości. Zarazem zaczynam z każdą chwilą doceniać każdy kolejny projekt, który przyjdzie mi tworzyć z użyciem, którejkolwiek z tych technologii.
Wszystkim, którzy cierpią na bezsenność z powodu wymyślania argumentów na korzyść/niekorzyść jakiegoś języka programowania - daję receptę. Zaprojektujcie w ASP.NET system newsów z komentarzami i bazą użytkowników. Spróbujcie zabezpieczyć aplikację przed XSS, CSRF, SQLInjection z użyciem C# i zróbcie to równie ładnie jak w Python'ie czy Ruby'm. Efekt - gwarantowany: "No more tears".

Podsumowanie

Część artykułów robiących wielkie halo wokół Iron Ruby i Iron Python to mydlenie oczu. Odniosłem kiedyś wrażenie, że Microsoft "robi łaskę", że implementuje te dwa świetny języki na swojej platformie. Może być tylko inaczej. MS idzie po najniższej linii oporu. Stara się zapewnić, godne porządnego, szanującego się programisty, (sic!) środowisko. Środowisko, które zacznie zbliżać się możliwościami do obecnych trendów. Jednak moim zdaniem jeszcze daleko do tego. Oczywiście. Elastyczność Ruby'go i Python'a będzie biła na głowę C# w każdym miejscu i usprawni tworzenie witryn o 150%. Jednak dopiero zastosowanie frameworków znanych ze świata CPython'a czy CRube'go sprawi, że będzie to opcja do rozważenia.

Prawda jest taka, że Microsoft ma problem. Ten problem nazywa się IIS. Jak widać doszli do wniosku, że jedynym wyjściem z niego to zrobić działające z nim implementacje tego co dobre. Oby tylko nie "ulepszyli" całości po swojemu robiąc z genialnych technologii kolejną, której nie da się używać.

P.S. Autor podkreśla na koniec, że w ASP.NET programuje bardzo krótko i negatywne zdanie o technologii może wynikać ze słabej znajomości języka.

Wednesday, June 17, 2009

Express yourself - dlaczego kłócimy się o wyższość języków programowania

Na co dzień używamy jakiegoś języka. W naszym przypadku jest to język polski. Nikt nie narzeka na to iż nauczono go akurat tego języka i akurat w nim się wychował. Używamy go jak potrafimy najlepiej. Kiedy z czasem zaczynamy zagłębiać się w meandry języka angielskiego zauważamy iż jest niezrównany w opisie i pojemności leksykalnej gdy chodzi o żargon techniczny. Jego wykorzystanie w tej dziedzinie daje nam ogromne możliwości i otwiera wiele zamkniętych drzwi, które gdy władaliśmy jeszcze wyłącznie polskim, stały przed nami zamknięte. Nikt nie narzeka jednak i nie krytykuje języka polskiego, nie przestaje go nagle używać twierdząc, "że jest gorszy". Następuje raczej zapożyczanie, mieszanie i ewentualne spolszczanie wyrazów angielskich w gronie osób "technicznych".

Również będąc fizykiem czy biologiem ciężko mieć pretensje do ilości łaciny z jaką się stykamy. Ten źródłosłów po prostu w najlepszy sposób opisuje istotę zagadnienia i nie ma od kilkunastu tysięcy lat lepszego języka aby wyrazić to wszystko co opisuje.

Należy również dodać, że każdy język ulega z czasem czemuś co puryści nazwali by "skażeniem". Chodzi o przekręcanie i dodawanie nowych wyrazów i sformułowań, często w danym okresie czasu kompletnie nie poprawnych gramatycznie. Takich wyrazów "ułomnych". Zjawisko to występowało i występuje w wielu językach nie tylko w języku polskim ale również i w angielskim i zapewne każdym innym.

O co się właściwie kłócimy ?


Do tego wpisu sprowokowały mnie kłótnie, które systematycznie wywiązują się pod moimi artykułami publikowanymi na Webhosting.pl. Który polak (który chce aby oświadczyny wypadły pięknie) wybrałby do nich język niemiecki (szorstki i suchy) mogąc wykorzystać piękno i urok choćby języka francuskiego lub mając do dyspozycji całą gamę poezji śpiewanej Erotyków Krzysztofa Kamila Baczyńskiego ?

Języki programowania są różne. Na początku, gdy zaczynamy przygodę z programowaniem, używamy ich aby wklepać ciąg instrukcji, które ma dla nas wykonać komputer. Z czasem zaczynają nam służyć do czegoś więcej. Programując, po kilku latach, zaczynamy pisać kod tak aby wyrazić swoją intencję - zupełnie jak w języku naturalnym.

Czasem możemy pisać coś w Pythonie i myślimy: no nie, tutaj to idealnie, no po prostu idealnie użyłbym domknięcia (z języka Ruby), a tutaj .... kurcze - genialna sytuacja do wykorzystania modułów (z języka Ruby). Stajemy przed wyborem: zmieniamy język programowania albo spędzamy więcej czasu jak bez użycia tych mechanizmów równie dobrze wyrazić naszą intencję konstruując poprawnie kod.
Myślę, że właśnie w tym momencie u wielu osób zaczyna zapalać się lampka "może język XYZ jest lepszy od ABC ?".

Co to znaczy lepszy język ?

Co to znaczy lepszy język ? Czy angielski jest lepszy od polskiego ponieważ w znacznym stopniu (jest wszak źródłosłowem) składa się na nomenklaturę techniczną ? Czy francuski jest lepszy od polskiego ponieważ oświadczyny, czy przysięga małżeńska ma w nim tak szalenie uroczy wydźwięk i oszałamiające brzmienie ?

Do tej pory w Polsce funkcjonują wydziały, gdzie wykłada się informatykę, na których obowiązuje ochrona języka Polskiego czytaj - nie używa się nomenklatury anglojęzycznej. A więc się da :) Jak to naprowadziło mnie na pewne odniesienie do języków programowania ?

Kiedy czyta się książkę o C pisaną przez entuzjastycznego programistę lat 90tych nie raz i nie dwa razy, ale niemalże, co publikację, można trafić na stwierdzenie, że "wskaźniki to potężne narzędzie" i można je wykorzystać na tak wiele sposobów. Sam kiedy zaczynałem studia - a programowaliśmy pierwszy rok w C - używałem ich namiętnie i z niemałym zachwytem podziwiałem kunszt ich wykorzystywania. Nastąpił czas gdy wskaźniki zaczęto krytykować. Świetnie opisuje to w swojej książce "Inżynieria Oprogramowania C++" Victor Shtern. Jednak były tak silnie zakorzenione w mentalności programistów czasów języka C iż wielu nie wyobrażało sobie nowoczesnego języka ich pozbawionych. Myśl o ich nieobecności budziła w wielu lęk, obawy. Nie potrafili myśleć w perspektywie pozbawionej takiego mechanizmu. I na tym chciałem się skupić.

Wiele współczesnych języków programowania pokazuje, że w przypadku znacznej klasy zagadnień, da się programować bez wskaźników. Młode pokolenie programistów-samouków, które zaczęło swoją przygodę z językami wyższego poziomu niż C++, może nigdy się nie dowie co to wskaźnik i, że coś takiego w ogóle istniało. To co najważniejsze w tym wydarzeniu to fakt iż to jak postrzegamy język programowania zależy od tego jak bardzo w funkcji charakterystycznych dla niego struktur myślimy.

Python jest językiem o pewnych cechach. Na pewno jest językiem prostym (jak na przykład angielski). Anglicy dobrze rozumieją się ze sobą i posługują swoim językiem od kilkunastu setek lat. Żaden z nich nie narzeka na jakieś "braki". Tak samo programiści Pythona. Jeżeli potraktować kod języka jako "ja piszę kod daję komuś innemu aby go zrozumiał on go czyta i rozumie albo nie" to i Pythonowcy bardzo dobrze się rozumieją. Równie dobrze rozumieją się ludzie piszący w Pascalu, Ruby, czy każdym innym językiem programowania.

Bardzo nie lubię kłótni o wadach czy o rzekomych ułomnościach jakiegoś języka czy jego wyższości nad innym. Lambda w Pythonie. Podobno ułomna - spełnia wspaniale szereg zadań i jest nieocenioną pomocą w wielu przypadkach. Ktoś ma lepszą lambdę - fantastycznie, jeżeli będę jej potrzebował na pewno użyję jego języka. A jak bardzo chcą to niech ją wdrożą i w Pythonie, tylko, żeby nie popsuli języka. Nikt im nie broni. Zapytajcie jednak świeżo upieczonego programistę Pythona (wcześniej powiedzmy PHP) o wrażenia - powie, że język jest świetny. Mechanizmy zaprezentowane w kursie przyjmie do wiadomości takimi jakimi są i takimi zacznie je lubić, stosować i będzie robił to dobrze. Tak samo będzie gdy ktoś nauczy się Rubego czy Scali - oczywiście wciąż tylko jednego z nich. Chodzi o to, że nauczeni dobrze myśleć w jakiś ramach możemy pisać z nich naprawdę dobre programy. Ktoś kto dobrze umie Pythona nie będzie miał problemu z wyrażeniem siebie w kodzie - zrobi to tak jak pozwala mu na to język i zrobi to dobrze.

Kiedy zaczynamy się kłócić ?

Wszystko zaczyna się psuć gdy znamy np. i Pythona i Rubego. Nie uważam broń Boże, że to złe. Uważam, że to fantastyczne. Jednak wciąż denerwują mnie ludzie, którzy znają oba te języki i zaczynają narzekać, że "Python nie jest Rubym", a "Ruby nie jest Pythonem" w zależności od sytuacji. Najbardziej na tym cierpią nowi programiści, którzy właśnie zastanawiają się nad przejściem, na któryś z tych świetnych języków i trafiają na tego rodzaju dyskusje. Po prostu beton. I wcale się nie dziwie ludziom, którzy po wejściu na 5 pierwszych stron i przeczytaniu komentarzy tego rodzaju rezygnują i zostają np. przy PHP rezygnując z dalszego rozwoju w kierunku, który naprawdę może dać wiele zabawy, satysfakcji i nowych, ekscytujących doświadczeń.

Całe filozofowanie zaczyna się chyba przez to, że ulegliśmy "reklamie" i marketingowi jakiegoś języka programowania i przez jakiś czas uważaliśmy go za "naj" a teraz gdy poznajemy kolejny to nagle ten poprzedni wydaje nam się jakiś taki... nie za bardzo "naj".
Wszystko przez to, że daliśmy się złapać na prosty chwyt. Chwyt polegający, że za "naj" nie było już żadnego słowa, które powiedziałoby najjaki jest ten język programowania, który zamierzamy poznać.

Piszmy o pozytywach !

Python jest najprostszy - zwięzłością, oszczędnością i czytelnością bije po oczach
Ruby jest najekspresywniejszy - powala pisać developerski poematy
Scala jest najczystsza - purystyczna koncepcyjnie, paradygmatowo i składniowo

Czy nie jest to obiektywną prawdą ? Czy takie ujęcie tematu nie jest prawdziwsze ? Oczywiście rozumiem, że jakaś struktura w jednym języku programowania została zaprojektowana lepiej niż w innym. W porządku. Języki naturalne ewoluują, na ile jest to możliwe. Na pewno lata świetlne trudniej ewoluują też i języki programowania. Nikt nie broni wprowadzić do języka dobrych zmian i go unowocześniać. Wiadomo jednak, że pewne zmiany nie będą mogły być wprowadzone, inne będą kosztowały nie wiadomo ile wysiłku aby ich dokonać. Języki obecnie istniejące są ulepszane na ile to tylko możliwe i należy się z tego cieszyć, wspierać ich rozwój (choćby duchowo) i korzystać z ich zalet - nie skupiać się zaś na wadach szczególnie tych, z którymi nic nie można zrobić - bo po co o nich pisać skoro nie można ich naprawić. Należy te wady znać, pokazać język, których nie posiada ale nie wciąż krytykować.

Jeżeli język naturalny pozwala nam na rozbudowanie go o zaporzyczenia angielskie, łacińskie czy francuskie - korzystajmy z nich. Jeżeli pozwala to robić w znacznym stopniu - róbmy tak, jeżeli w mniejszym, wykorzystujmy to nadal na ile się da. Ale nie mówmy, że nasz język jest zły. Jest piękny, ma pewną historię i z pewnych przyczyn brzmi i wygląda tak a nie inaczej. Jako Polacy nie obrażamy się na naszą gramatykę i ortografię, gremialnie nie zaczynamy, rezygnować z naszego nadwiślańskiego narzecza, na rzecz angielskiego. Część z nas czyni zaporzyczenia inni uczą się władać innym językiem (bo muszą albo dziedzina ich do tego zmusza) - nikt jednak nie robi afery z tego iż język polski jest jaki jest.

Bądźmy mistrzami w kunszcie :)

Sztuka bycia człowiekiem elokwentnym polega między innymi na wykorzystaniu tego co się zna tak jak tylko najlepiej się potrafi w sytuacji, z którą się spotyka a gdy trzeba, douczenia się czegoś nowego. Człowiek inteligentny zna zarówno zalety jak i wady narzędzi, którymi się posługuje - bo to jest potrzebne aby dobrze ich używać - jednak nie wytyka ich "gdzie popadnie" i "jak tylko nadarzy się okazja". Zarówno jedne jak i drugie informacje służą ku lepszemu użytkowaniu i znacznie bardziej precyzyjnemu doborowi potrzebnej aparatury niż krytyce. Nikt nie narzeka na młotek, że ciężko się nim wkręca śrubki i nikt na piłę, że słabo się nią wbija gwoździe.

Chciałem wszem i wobec zaznaczyć, że tekst nie jest skierowany przeciwko jakiejś konkretnej osobie. Jest wyłącznie zbiorem moich przemyśleń.

Friday, November 7, 2008

Merb - i propaganda Railsowców

To już kolejny raz kiedy napatocza mi się ktoś ze znajomych, który mówi "Widziałeś Railsy jaaa - fantastyczne !", albo "Będę się uczył Railsów", albo "Właśnie skończyliśmy projekt w Railsach, który robiliśmy z kolegami.". Kurcze belek. Bawiłem się w Railsach, używałem też kilku innych frameworków takich np. jak CakePHP, CodeIgniter, Symfony czy Pylons a także jestem wciąż naocznym świadkiem wszystkich odkryć współlokatora, który zgłębia Django i nie rozumiem - czym się ludzie zachwycają. Rails - przereklamowany, z tego co czytałem, bezmyślnie zaimplementowany, niewydajny, posidający błędy framework, który jak widać pomimo swoich wad wciąż robi wielki show więc do listy dodałbym jeszcze podkreślając  po raz kolejny przereklamowany framework.

W przyszłym miesiącu premiera Merba. Śledzę jego karierę od czasu gdy wpisy zaczęły pojawiać się na blogu Zabiello, później zaimportowałem sobie kanał RSS z Merbist, przeszukałem sieć pod kątem materiałów na jego temat, pooglądałem slajdu z MerbCamp... i wciąż zastanawiam się co jest z ludźmi zafascynowanymi Railsami nie tak.  Żadne argumenty nie przemawiają do osób, które zamierzają się uczyć Railsów, aby spróbować z Merbem. Nie ważne czy powiem: "jest szybszy", "jest przemyślanie zaimplementowany", "uczy się na błędach railsów", "jest napisany przez fachowców od Rubego" - argument zawsze jest ten sam: "Do Railsów jest więcej książek, Railsów jest się łatwiej nauczyć". Ludzie - co z tego, że jest do nich 2,5 miliona książek. Do Merba jest kilka 5,3 GB filmów. Natrafiłem również na ciekawy - wyglądało na to całościowy - kurs Merba [http://merb.4ninjas.org/] choć jeszcze nie dokończony  - cóż więcej można chcieć ?

Nadal będę próbował propagować ideę Merba, przekonywać do niego railsowców. Może zrobię do niego slajdy. Uważam, że jest to fantastyczny framework. Używałem w nim wyłącznie templatów i kontrolerów, ale już samo HAML i SASS mnie tak użekło iż stwierdziłem, że ten framework to numer 1 :) i basta !

Z pozdrowieniami dla wszystkich railsowców jadących wciąż lokomtową parową w czasach ażewe :) Merb propagator :P

Ruby on Rails vs .... series

Dziś kolega, zafascynowany Ruby on Rails, pokazał mi filmiki z serii Ruby on Rails vs .... http://pl.youtube.com/results?search_query=Ruby+On+Rails+vs&search_type=&aq=f

Na starcie zapytałem: "A jak wygląda filmik z Django" [http://pl.youtube.com/watch?v=PLUS00QrYWw] Chyba musieli się naprawdę wysilić żeby coś takiego wymyślić. Moim zdaniem - śmiech na sali. W momencie, w którym to obejrzałem twórcy wydali mi sie śmieszni i w gruncie rzeczy - sami ośmieszyli Railsy.

Przy informacjach, jakie można znaleźć na blogach, w których zarzutami przeciwko railsom jest wydajność (tutaj Django pokazuje klasę że hoho) czy też błędy znane od lat, czy chociaż kiepski sposób implementacji porównywanie siebie z Django z góry z założeniem "Railsy muszą wypaść na plus" - jest bez sensowne.

Monday, June 23, 2008

Geany - ciekawy edytor

Kolega pokazał mi swojego czasu edytor Geany. Pisze, albo pisał swojego czasu, w nim programy do Pythona. Edytor przypomina troszkę zwykły edytor spod Gnome. Szalenie użyteczną opcją jest moim zdaniem, opcjonalnie włączane, okienko plików w prawym panelu oraz "konsola" w jednej z dolnych zakładek, z której możemy podręcznie korzystać lub zarzyczyć sobie aby w niej były wykonywane skrypty. Program posiada system wtyczek i chyba tyle. Jest prosty, przejrzysty a praca z nim to naprawdę przyjemność. Polecam każdemu kto szuka lekkiego, prostego, schludnego środowiska.

Sunday, June 22, 2008

Ruby i Python w jednym żyli domu ...

Kolega, z którym przez ostatni rok miszkałem, zaczął pisać swoje projekty w Pythonie. Mnie natomiast, choć i ja w pythonie coś pisałem, wzięło na Rubego. Miałem więc w różny sposób styczność z obydwoma języka programowania. Chciałem napisać dwa zdania o moich przemyśleniach.

Chciałbym zacząć od tego, że kiedy zabierałem się za którykolwiek z tych języków czułem się dziwnie. Wcześniej programowałem w Java, PHP, C, C++ ... i w każdym z nich mogłem szukać jakiś analogii do poprzedniego. Korzystać ze zdobytej wcześniej wiedzy czy też patrzeć na nowe rozwiązania (przykładowo foreach w PHP) jak na załatanie "dziur" niewygody z poprzednich języków (C, C++). Jednak do Pythona i Rubego - po prostu masakra ! Nic nie mogłem z siebie wykrzesać. Nic !  Dla mnie osobiście był to tak "inny świat", że zabierając się za te języki, wciąż miałem jakby umysł na uwięzi. Spętany nawykami sprzed lat obowiązującymi we wszystkich innych języka programowania, które poznałem starałem się przebrnąć, zrozumieć - nie mogłem. Ratunek był tylko jeden: książką lub dobry kurs do języka idący kroczek po kroczku. Musiałem zacząć się uczyć tych języków tak, jakbym nigdy wcześniej nie programował. Potrzebowałem dobrego kursu lub książki oraz społeczności, która pomogłaby w stawianiu pierwszych kroków.

Przygodę z Pythonem zaczęliśmy z kolegą od rozmówek. Pomysł okazał się jednak nie trafiony. Oczywiście rozmów, kiedy już programuje się jakiś czas w pythonie, są świetne - jeżeli zaś chodzi o dobre poznanie języka - okazały się zbyt zwięzłe i ogólnikowe. Potem trafiłem na kurs Jakuba Swacha, który okazał się strzałem w dziesiątkę. Po prostu - z niego nauczyłem się podstaw pythona. Z różnymi zagadnieniami czy problemami pojawiającymi się w trakcie rozwiązywania zadań do kursu zwracałem się do forum polish python coder group, gdzie zawsze mogłem otrzymać wsparcie i pomoc. Później kolega zakupił już sam "Python Podstawy". Książka okazała się rzeczywiście robieniem wszystkiego "krok po kroku". Jednak nawet jako początkujący znaleźliśmy w niej kilka błędów. Omawiająca szeroki zakres zagdanień, od podstaw, do problemów związanych z dystrybucją komercyjnych programów pisanych w pythonie.

Python jest prosty. Nie łatwy (choć może też), ale prosty. Jeżeli w Pythonie coś robi się "tak" to tak się to robi i nie powinno stosować się żadnego innego sposobu aby to wykonać. Programy wyglądają przejrzyście, są logiczne i zrozumiałem. Osobiście przeszkadza mi tylko fakt iż ogólnikowo nie wszystko jest obiektowe. Pojawiające się tu i ówdzie funkcje czasem utrudniają - bo wydają się "nie pasować". Często, wiele funkcji, które sprawdzają czegoś długość, ilość elementów itd ... mogłyby być po prostu metodami obiektu - jednak tak nie jest i często zapędzając się w "obiktówkę"... zastanawiamy się "czemu nie działa ?" a dlatego, że takiej metody nie ma - trzeba użyć funkcji.

Jeżeli o Rubego chodzi na start kupiłem Ruby On Rails. Próba przebranięcia przez tą książkę bez znajomości języka to była porażka. Na urodziny od rodziców dostałem "Ruby. Tao programowania w 400 przykładach". Jestem osobą, kra czyta wstępy do książek. Przeczytałem i tutaj. Na starcie dowiedziałem się, że "książka ta nie nadaje się dla osób, które chciałyby nauczyć się języka Ruby" - bomba ... a po to ją kupiłem. Spróbuję ! Przecież jestem zdolny ... Po siedmiu rozdziałach się poddałem: "Co to za syf ? Ile tu składni ?! Za dużo ! Po co tyle możliwości. O co chodzi !?" ... Zbawieniem okazała się dla mnie książeczka "Ruby. Wprowadzenie". Tutaj autor bardzo powoli zaczął omawiać język - książka okazała się dla mnie idealna... Naprawdę solidnie pozwoliła mi pojąć nie tylko sam język ale również jego "filozofię" i dostrzec w tym całym "bałaganie" pewien sens. Dodatkowo moje wątpliwości szybko rozwiewała społeczność na forum RubyOnRails.pl.

Ruby nie jest językiem prostym. Jest jak system operacyjny. Możesz administrować systemem od 10 lat, spotkać kolegę po fachu i dowiedzieć się, że wykonuje te same czynności w zupełnie inny sposób. Z Rubym jest jeszcze ciekawiej. Posiada on nazwałbym to bardzo rozbudowaną składnię. Twórcy języka jakby dopieścili każdy jego najdrobniejszy element. Nie wystarczyło im że stworzyli już coś co działa, ale z pietyzmem starali się zrobić tego tyle wariantów... na tyle sposobów - ilu programistów na świecie tak, aby każdy znalazł sposób na wykonania swojego zadania tak jak lubi. Nie nazwałbym Rubego językiem programowania - bo języki programowania to język stworzony po to aby maszyna nas rozumiała. Ruby został stworzony nie dla maszyny, ale dla człowieka, aby mógł ekspresywnie, twórczo, kreatywnie oraz precyzyjnie wyrażać swoje myśli i intencje pisząc kod programu. Czytając kod Rubego możesz spojrzeć na niego i zobaczyć coś więcej poza samymi instrukacji - możesz zobaczyć styl, osobę, która pisała ten kod oraz Jej finzję w wyrażaniu myśli.

Wiele osób uważa, że duża ilość możliwości jaką daje Ruby powoduje problemy ze zrozumieniem kodu. Teoretycznie możemy czytać właśnie kod, który czyta plik kompletnie go nie rozumiejąc, bo przez całe życie robiliśmy to inaczej - i nie znamy "tej metody". Jednak moim zdaniem Ruby jest tak skonstruowany, że dzięki samym nazwom metod oraz operatorów - nawet takich, które widzimy pierwszy raz na oczy - będziemy w stanie zrozumieć co wykonuje dany program.

Oczywiście wiele zależy również do programisty. Jakiego zapisu użyje w tej sytuacji, jak ponazywa zmienne, czy to co zrobi będzie miało sens. Święte wojny o to czy klasy w Ruby powinny byc otwarte - czy nie przypominają mi dyskusje związane z bezsensownym przeładowywaniem opratorów różnych obiektów w C++. Moje zdanie jest takie: Dobry programista będzie umiał wykorzystać nawet potencjalnie "niebezpieczne" mechnizmy na rzecz czytelności i zrozumiałości kodu - nie mądry, nawet ograniczony składnią języka może natłóc kod z którego nic nie wynika. Tak więc nie winiłbym języka za to iż przy otwrtych klasach w Ruby można "nieźle nagmatwać", ale raczej składałby odpowiedzialność na barki programistów. Dynamit też był wynaleziony by służyć dobru - tylko od ludzi zależy czemu tak naprawdę będzie służył, sam w sobie - nie jest zły.

Sunday, March 23, 2008

RUBY - Raczej Uporządkowany Bałagan

Zaraz po zapoznaniu się z językiem Python postanowiłem liznąć Ruby ego. Tak się składa, że poprosiłem o"RUBY Tao Programowania w 400 przykładach" książkę na urodziny i dostałem ją od moich kochanych rodziców :]

Wrażenia są mniej więcej takie, że Ruby to Raczej Uporządkowany Bałagan (i w tym bałaganie zaginęła literka "y"). Ponieważ nie pisałem jeszcze żadnego programu w Ruby więc może to tylko wrażenie bałaganu, może wszystko się wyjaśni kiedy zacznę w nim pisać.

Na pewno poznanie języka Ruby to jak poznanie języka jakby 3 razy bardziej obszernego. Ucząc się Pythona masz powiedziane jasno: jak chcesz coś zrobić to użyj XYZ i XYZ wykona dla Ciebie to. A w Ruby masz owszem napisane operator ABC wykonane dla Ciebie to co chcesz, ale masz przy okazji opisane milion innych sposobów jak wykonać tą samą operację w inny sposób a przy okazji omówione drugie tyle newansów, którymi rozwiązania się różnią.

Być może właśnie przez tą różnorodność mam wrażenie bałaganu. Natomiast na pewno jedna rzecz jest szalenie ważna. Obsługa pewnych podstawowych rzeczy w Ruby jest połowiczna. Używanie dodatkowych bibliotek w celu poprawnego obsługiwania łańcuchów kodowanych w UTF8, pisanie w ogóle o WADACH języka i w celu ich "rozwiązywania" używania zewnętrznych bibliotek, nagłe zmiany działania metod (np. przyjmują szerszy zakres zmiennych) po załadowaniu jakiejś biblioteki czy wrażenia braku jednolitości co do stosowanych notacji ... to coś czego w kursach Pythona nie spotkałem. Kurs Pythona to poprostu same superlatywy, opis cech języka bez zagłębiania się w szczegóły. Pokazanie jak działają mechanizmy bez wchodzenia w wady i cechy danych rozwiązań - może też dlatego kursy Pythona, poprzez taki "trik socjologiczny" wydają się prezentować język Python jako lepszy... społeczność mówi jednym głosem pokazuje jego zalety, cechy - a o Rubym to co rusz da się wyczytać o jakiś wadach (powiedziałbym cechach). Moim zdaniem to bardzo negatywnie rzutuje na wrażenie jakie odbiera się podczas czytania o języku.

Myślę, że to dobyr punkt, żeby zacząć tworzyć publikacje nie wgłębiające się w szczegóły, pokazujące język Ruby od tak poprostu w zastosowaniach, w których się sprawdza i już !

Monday, December 3, 2007

Pierwsze wrażenia z programowania w Rails

Powiem od razu nie są najlepsze. Może wpływa na to fakt, że kiedyś na spotkaniu TLUGu jakiś gość zbeształ PHP (porównując go do Rails) więc na dzień dobry podchodziłem do tego zupełnie sceptycznie.

Po pierwsze do tej pory nie udało mi się odpalić procesu i komunikować się z nim na poziomie strumieni 3,4 wykraczających poza standard in/out/err i nikt ze społeczności jak na razie nie jest w stanie mi pomóc.

Kolejna sprawa to dokumentacja. W porównaniu do PHP jest do niczego. Nawet www.noobkit.com czy getapi.com wypada bardzo słabo. Ok - nawet nie porównujemy tego, bo w sumie PHP ma najlepszą dokumentację jaką w życiu widziałem. Ale nawet dokumentacja frameworków PHPowych jest lepsza niż Rails.

Dodatkowo ogromna ilość artykułów niespecjalnie pomaga zorientować się w sytuacji... i odnaleźć drogę do celu :/ co stanowi pewien problem.

To taka pierwsza refleksja - może czas przyniesie zmiany. Zobaczymy.