Saturday, November 19, 2011
Scala - scratch the surface
Thursday, November 17, 2011
PhantomJS i Ruby - czyli przygody małe i duże
gem install redcar
redcar install
redcarI 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ł.
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."
Saturday, September 3, 2011
Ruby On Rails 3.1 - dzień pierwszy
Sunday, May 16, 2010
Fabric - Pythonowe Capistrano
Thursday, May 13, 2010
Przygoda z Merbem i jak przeszedłem na Sinatrę
Tuesday, March 2, 2010
Gdyby pieniądze Microsoftu ...
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
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?
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
Wednesday, July 29, 2009
Python i Ruby w jednym stali domu ...
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
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.
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ć.
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.
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
Ruby on Rails vs .... series
Monday, June 23, 2008
Geany - ciekawy edytor
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
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
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.