zapis do pliku
Marek
file = open("test.txt", 'w')
file.write("costam")
file.close()
po prostu:
'test.txt'.write("costam")
pewnie już od biedy dało by się stringowi zapodać metodę write tak aby
był traktowany jako nazwa pliku
Piotr Husiatyński
Nie.
Zapisać chcesz do pliku a nie do stringa (ktory to metody write nawet
nie posiada). Od biedy mozesz stworzyc wlasny typ, ale na dodanie lub
przeciazenie metod typow wbudowanych nie ma szans.
Marcin Sztolcman
To by było chore. Napis ma zgadywać że zawiera nazwę pliku etc? :)
W PHP masz do jednolinijkowego zapisu treści do pliku funkcję
file_put_contents ().
MySZ
--
Marcin Sztolcman :: http://urzenia.net/ :: http://sztolcman.eu/
Radomir 'The Sheep' Dopieralski
Marek wrote:
> nie mogę się doczytać ale czy da się zamiast:
> file = open("test.txt", 'w')
> file.write("costam")
> file.close()
> po prostu:
> 'test.txt'.write("costam")
Najblizsze temu byloby:
open('test.txt', 'w').write('costam')
--
Radomir `The Sheep' Dopieralski <http://sheep.art.pl>
On and on until we change / Everything remains the same
On and on until we learn / On and on the wheels will turn
Wojciech Muła
> nie mogę się doczytać ale czy da się zamiast:
>
> file = open("test.txt", 'w')
> file.write("costam")
> file.close()
>
> po prostu:
>
> 'test.txt'.write("costam")
A po co string ma wiedzieć cokolwiek o plikach?
Toż to byłby gwałt na OO.
w.
Janusz A. Urbanowicz
file('eggs.txt','w').write('spam')
--
JID: al...@hell.pl
PGP: 0x46399138
od zwracania uwagi na detale są lekarze, adwokaci, programiści i zegarmistrze
-- Czerski
Marcin Sztolcman
[...]
> W PHP masz do jednolinijkowego zapisu treści do pliku funkcję
> file_put_contents ().
Heheh, aż do ostatniej minuty byłem przekonany że odpisywałem na
pl.comp.lang.php ;)
William
Użytkownik "Marek" <no.e...@no.spam> napisał w wiadomości
news:0kke845ibufm2jqmh...@4ax.com...
> nie mogę się doczytać ale czy da się zamiast:
>
> file = open("test.txt", 'w')
> file.write("costam")
> file.close()
>
Ładniej:
with open( 'test.txt', 'w' ) as file:
print >> file, "Costam"
Jarek Zgoda
Jak to jest ładniej, to ja jestem Humphrey Bogart.
--
Jarek Zgoda
http://zgodowie.org/
"We read Knuth so you don't have to" - Tim Peters
William
Użytkownik "Jarek Zgoda" <jzg...@o2.usun.pl> napisał w wiadomości
news:g69f0n$ism$1...@atlantis.news.neostrada.pl...
> William pisze:
>> Użytkownik "Marek" <no.e...@no.spam> napisał w wiadomości
>> news:0kke845ibufm2jqmh...@4ax.com...
>>> nie mogę się doczytać ale czy da się zamiast:
>>>
>>> file = open("test.txt", 'w')
>>> file.write("costam")
>>> file.close()
>>>
>>
>> Ładniej:
>>
>> with open( 'test.txt', 'w' ) as file:
>> print >> file, "Costam"
>
> Jak to jest ładniej, to ja jestem Humphrey Bogart.
>
ładniej od:
file = open("test.txt", 'w')
try:
file.write("costam")
finally:
file.close()
Marek
>
>file = open("test.txt", 'w')
>try:
> file.write("costam")
>finally:
> file.close()
no ale zaraz zaraz... poszukując rozwiązana na ten problem trafiłem na
rozszerzenie które powoduje że np. przy zapisie do pliku danych
liczbowych nie trzeba stosować str() - i już kod źródłowy jest
mniejszy jest mniej miejsc gdzie mógły czychać błąd
przecież tak samo dało by się przerobić to powyżej, oczywiście taka
funkcja też miała by trochę rzeczy które musiały by być ustawione na
stałe + jakaś dodatkowa logika rządząca otwieraniem / zamykaniem /
blokowaniem / tworzeniem plików
dla mnie ciągle najładniej jest:
'test.txt'.write:'costam'
albo...
'test.txt'.write:314159265
czyli nawet nawiasów nie mamy, nie wiem czy takie coś jest możliwe do
napisania w pythonie, może takie rozszerzenie już ktoś napisał, można
by też było dodać metodę writeln oraz writeb (która zapisywała by
wartość liczbową w bajtach a nie przerabiałą na ascii), co też by
mogło zaoszczędzić parę krzaczków, możliwości jest wiele
oczywiście można by było doprowadzić do tego że taki język nie był by
już pythonem... no ale co z tego, możemy tak wypróbować jak daleko
można się posunąć w rozwiązaniu problemu który twórca pythona miał na
myśli tworząc ten język programowania, kto wie jak daleko można się
posunąć
Grzegorz Staniak
> przecież tak samo dało by się przerobić to powyżej, oczywiście taka
> funkcja też miała by trochę rzeczy które musiały by być ustawione na
> stałe + jakaś dodatkowa logika rządząca otwieraniem / zamykaniem /
> blokowaniem / tworzeniem plików
>
> dla mnie ciągle najładniej jest:
>
> 'test.txt'.write:'costam'
> albo...
> 'test.txt'.write:314159265
Powiem Ci szczerze, że to bez sensu. Cytowanie pojedynczym czy podwójnym
cudzysłowem w wielu językach oznacza literał wartości znakowej i dla wielu
programistów to będzie pierwsze skojarzenie - że wywołujesz metodę stringa.
Jeśli chcesz koniecznie wymyślić coś mylącego, to jesteś na dobrej drodze,
ale biorąc pod uwagę, że w filozofii Pythona czytelność kodu odgrywa ważną
rolę, wątpię żebyś miłośników tego języka zainteresował powyższą propozycją.
Musiałbyś mieć sposób na odróżnianie zwykłego stringu od nazwy obiektu typu
plik, a to już ładnie załatwia podane Ci wcześniej rozwiązanie:
file('test.txt', 'w').write('costam')
- jednolinijkowe, wyraźnie sygnalizujące że chodzi o otwarty plik (dodatkowo
masz na widoku tryb w jakim plik jest otwarty), z nawiasami które jasno
informują, że 'costam' jest argumentem metody. DGCC, ale dla mnie z kolei
"ładniej" natychmiast przegrywa z "czytelniej".
GS
--
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Marek
<gsta...@wp.pl> wrote:
>Powiem Ci szczerze, że to bez sensu. Cytowanie pojedynczym czy podwójnym
>cudzysłowem w wielu językach oznacza literał wartości znakowej i dla wielu
>programistów to będzie pierwsze skojarzenie
[...]
ale ja doskonale rozumiem co masz na myśli, tutaj chodzi tylko o
zmianę priorytetów, gdzie mamy za zadanie doprowadzić do tego aby
ilość kodu źródłowego była jak najmniesza, okazjonalnie łamiąć utarte
schematy
i oczywiście nie rządam aby python obsługiwał następujący sposób
kodowania w swojej standardowej formie - ja jakbym umiał tak porządnie
programować to bym się zajął właśnie w ramach hobby takim
eksperymentalnym przedsięwzięciem budowy jeszcze bardziej kompaktowego
języka na pythonie i oczywiście znowu poświęcając szybkość wykonywania
btw
to można by było rozwinąć bardziej np.
'test.txt'.w?'[tu ma byc regex]':'cośtam'
regex wykonywał by funkcję jeśli string lub liczba przemieniona na
string pasowały by do regexu
Grzegorz Staniak
>>Powiem Ci szczerze, że to bez sensu. Cytowanie pojedynczym czy podwójnym
>>cudzysłowem w wielu językach oznacza literał wartości znakowej i dla wielu
>>programistów to będzie pierwsze skojarzenie
> [...]
>
> ale ja doskonale rozumiem co masz na myśli, tutaj chodzi tylko o
> zmianę priorytetów, gdzie mamy za zadanie doprowadzić do tego aby
> ilość kodu źródłowego była jak najmniesza, okazjonalnie łamiąć utarte
> schematy
No cóż, mam wrażenie że dla całej masy ludzi małe zredukowanie objętości
kodu nie jest warte tego "łamania utartych schematów". To nie perl-golf,
tu się nikt nie bedzie ścigał na liczbę znaczków w one-linerze, czytelność
jest znacznie ważniejsza.
[...]
> btw
> to można by było rozwinąć bardziej np.
>
> 'test.txt'.w?'[tu ma byc regex]':'cośtam'
>
> regex wykonywał by funkcję jeśli string lub liczba przemieniona na
> string pasowały by do regexu
Naprawdę, chyba się za dużo napatrzyłeś na Perla czy inne Ruby.
Marek
<gsta...@wp.pl> wrote:
>Naprawdę, chyba się za dużo napatrzyłeś na Perla czy inne Ruby.
no tak, wcześniej próbowałem swoich sił w ruby, ale z tego co widzę
tej język zostaje raczej w tyle, np. nie mają windowsowej instalki do
najnowszej wersji podlinkowanej z głównej strony... coś na to wygląda
że za mało ludzi + do tego język zaczyna zmieniać swoje zastosowanie
na budowę aplikacji sieciowych (rails), tak więc jeśli chodzi o budowę
aplikacji zawsze będą niedociągnięcia
Grzegorz Staniak
>>Naprawdę, chyba się za dużo napatrzyłeś na Perla czy inne Ruby.
>
> no tak, wcześniej próbowałem swoich sił w ruby, ale z tego co widzę
> tej język zostaje raczej w tyle, np. nie mają windowsowej instalki do
> najnowszej wersji podlinkowanej z głównej strony... coś na to wygląda
> że za mało ludzi + do tego język zaczyna zmieniać swoje zastosowanie
> na budowę aplikacji sieciowych (rails), tak więc jeśli chodzi o budowę
> aplikacji zawsze będą niedociągnięcia
Ruby to fajny język i daj mu [insert your favourite deity] zdrowie, ale
w zakresie składni deklarowane cele są dokładnie odwrotne - Ruby chce być
"Perl done right", Python chce być do Perla jak najmniej podobny. Żadnych
magicznych znaczków, koncentracja na czytelności i jasności kodu nawet
kosztem paru znaków więcej w linii itp. Czytany kod powinien być oczywisty.
Dlatego nie wierzę, żeby w tej społeczności znalazły akceptację tego typu
pomysły jakie podałeś.
Janusz A. Urbanowicz
> On Thu, 24 Jul 2008 11:50:31 +0000 (UTC), Grzegorz Staniak
> <gsta...@wp.pl> wrote:
>
>>Powiem Ci szczerze, że to bez sensu. Cytowanie pojedynczym czy podwójnym
>>cudzysłowem w wielu językach oznacza literał wartości znakowej i dla wielu
>>programistów to będzie pierwsze skojarzenie
> [...]
>
> ale ja doskonale rozumiem co masz na myśli, tutaj chodzi tylko o
> zmianę priorytetów, gdzie mamy za zadanie doprowadzić do tego aby
> ilość kodu źródłowego była jak najmniesza, okazjonalnie łamiąć utarte
> schematy
Ale po co. Explicit is better than implict, a jak chcesz pisać krótkie
programy to pisz w assemblerze.
=alx
Jarek Zgoda
> przecież tak samo dało by się przerobić to powyżej, oczywiście taka
> funkcja też miała by trochę rzeczy które musiały by być ustawione na
> stałe + jakaś dodatkowa logika rządząca otwieraniem / zamykaniem /
> blokowaniem / tworzeniem plików
>
> dla mnie ciągle najładniej jest:
>
> 'test.txt'.write:'costam'
> albo...
> 'test.txt'.write:314159265
>
> czyli nawet nawiasów nie mamy, nie wiem czy takie coś jest możliwe do
> napisania w pythonie, może takie rozszerzenie już ktoś napisał, można
> by też było dodać metodę writeln oraz writeb (która zapisywała by
> wartość liczbową w bajtach a nie przerabiałą na ascii), co też by
> mogło zaoszczędzić parę krzaczków, możliwości jest wiele
>
> oczywiście można by było doprowadzić do tego że taki język nie był by
> już pythonem... no ale co z tego, możemy tak wypróbować jak daleko
> można się posunąć w rozwiązaniu problemu który twórca pythona miał na
> myśli tworząc ten język programowania, kto wie jak daleko można się
> posunąć
1. Metoda write musiałaby otworzyć plik, ale w jakim trybie (binarny,
tekstowy, tekstowy z normalizacją znaków końca linii, tekstowy do
nadpisywania, tekstowy do dopisywania)?
2. Skoro jest to metoda "czegoś na kształt pliku" (nie wiadomo, bo mamy
tylko napis), to w jaki sposób obsłużyć obiekty nie będące plikami, a
oferujące plikowy interfejs (StringIO, gniazdo, etc.)?
Problemów z Twoim rozwiązaniem jest więcej, niż korzyści, więc na
99.999% ("five nines") nikt tego nawet nie będzie próbował
zaimplementować. Jeżeli takie to dla Ciebie ważne, to wybierz sobie inny
język programowania.
Piotr Husiatyński
> Jeżeli takie to dla Ciebie ważne, to wybierz sobie inny
> język programowania.
A w ruby takie cos jest mozliwe
12.megabytes.seconds.meters.write('bla')
;)
Wiem ze dałoby się jeszcze w Lua.
Grzegorz Staniak
>> Jeżeli takie to dla Ciebie ważne, to wybierz sobie inny
>> język programowania.
>
> A w ruby takie cos jest mozliwe
>
> 12.megabytes.seconds.meters.write('bla')
>
> ;)
>
> Wiem ze dałoby się jeszcze w Lua.
Jak to dobrze, że Python to nie Ruby.
Wojciech Muła
> Ale po co. Explicit is better than implict, a jak chcesz pisać krótkie
> programy to pisz w assemblerze.
Krótkie programy w asemblerze? Nie stwierdzono takiego. :)
w.
Janusz A. Urbanowicz
Binarki będą małe, no.
Jaroslaw Zabiello
> no tak, wcześniej próbowałem swoich sił w ruby, ale z tego co widzę
> tej język zostaje raczej w tyle, np. nie mają windowsowej instalki
No tak... Windows (już dawno porzuciłem to badziewie). Jeśli chodzi już o
Javę, to jest dokładnie odwrotnie. Python zostaje w tyle. JRuby jest dużo
szybszy i dojrzalszy od Jythona. Także pod względem wątków Ruby też tłucze
niemiłosiernie Pythona. Zarówno wydajnościowo jak czytelniejszą składnią.
(vide: http://blog.zabiello.com/articles/2008/07/26/threads-ruby-python)
Z kolei MacRuby (chociaż jest we wczesnej fazie) jest implementacją
pozwalającą na pisanie pełnowartociowych aplikacji Mac OS X działających
na pełnej szybkości (typy Rubiego są tam bezpośrednio przekładane na
Objective-C, no i używany jest szybki Ruby 1.9 z wrtualną maszyną YARV).
Nie wiem czy jest jakikolwiek projekt tego typu w Pythonie.
No i oczywiście RSpec (http://rspec.net) i Behavioral & Story Driven
Development (http://goruco2008.confreaks.com/01_helmkamp.html). W
dziedzinie testów behawioralnych Python, z ty swoim starym Test Driven
Development jest 100 lat za Murzynami.
Python ma jeszcze kilka dziedzin w których jest dojrzalszy ale pewnie
szybko je też traci, bo Ruby rozwija się w ekspresowym tempie. To, który
jest z tyłu zależy od dziedziny i cały czas to się szybko zmienia. Także
na rynku pracy sytuacja się szybko zmienia. Ruby zaczyna powoli dominować.
W dziedzinie aplikacji webowych faktycznie już pobił popularnością Pythona.
--
Jarosław Zabiełło
http://blog.zabiello.com
Jaroslaw Zabiello
Nie da się. Python nie umie takich rzeczy. Jak chcesz krótko to zrób tak:
open('test.txt', 'w').write('costam')
Tomasz Elendt
> Dnia 24-07-2008 o 14:59:17 Marek <no.e...@no.spam> napisał(a):
>
>> no tak, wcześniej próbowałem swoich sił w ruby, ale z tego co widzę
>> tej język zostaje raczej w tyle, np. nie mają windowsowej instalki
>
> No tak... Windows (już dawno porzuciłem to badziewie). Jeśli chodzi już
> o Javę, to jest dokładnie odwrotnie. Python zostaje w tyle. JRuby jest
> dużo szybszy i dojrzalszy od Jythona. Także pod względem wątków Ruby też
> tłucze niemiłosiernie Pythona. Zarówno wydajnościowo jak czytelniejszą
> składnią. (vide:
> http://blog.zabiello.com/articles/2008/07/26/threads-ruby-python)
Na samym wstępie wpisu powinieneś był zrobić podobny test, ale bez
użycia wątków. Można by wtedy oszacować, ile zajmuje każdemu z
interpreterów wykonanie kodu z run (stworzenie listy losowych elementów
i posortowanie).
Co oczywiście nie zmienia ogólnie znanego faktu, że implementacja wątków
w Pythonie delikatnie mówiąc ssie.
> Z kolei MacRuby (chociaż jest we wczesnej fazie) jest implementacją
> pozwalającą na pisanie pełnowartociowych aplikacji Mac OS X działających
> na pełnej szybkości (typy Rubiego są tam bezpośrednio przekładane na
> Objective-C, no i używany jest szybki Ruby 1.9 z wrtualną maszyną YARV).
> Nie wiem czy jest jakikolwiek projekt tego typu w Pythonie.
Jest PyObjC. No i niby jest możliwość tworzenia aplikacji w
Pythonie/Rubym w Xcode (Cocoa-Python/Cocoa-Ruby). Apple co prawda
twierdzi, że dla nich zarówno Python jak i Ruby są "first-class
citizens", ale ciężko znaleźć w sieci dobre i aktualne opisy tworzenia w
tym aplikacji lub nawet przykłady samych aplikacji.
> No i oczywiście RSpec (http://rspec.net) i Behavioral & Story Driven
> Development (http://goruco2008.confreaks.com/01_helmkamp.html). W
> dziedzinie testów behawioralnych Python, z ty swoim starym Test Driven
> Development jest 100 lat za Murzynami.
Wierzymy na słowo :)
> Python ma jeszcze kilka dziedzin w których jest dojrzalszy ale pewnie
> szybko je też traci, bo Ruby rozwija się w ekspresowym tempie. To, który
> jest z tyłu zależy od dziedziny i cały czas to się szybko zmienia. Także
> na rynku pracy sytuacja się szybko zmienia. Ruby zaczyna powoli
> dominować. W dziedzinie aplikacji webowych faktycznie już pobił
> popularnością Pythona.
Mówisz o rynku pracy w Polsce (pytanie w kontekście aplikacji webowych)?
Czy o popularności rozumianej jako szum marketingowy?
--
Eluś
Radomir 'The Sheep' Dopieralski
Jaroslaw Zabiello wrote:
Na upratego mozesz sobie zrobic jakis obiekt w rodzaju "disk",
dodac go to builtins, przeciazyc mu operator dzielenia tak, zeby
zwracal obiekt tej samej klasy tylko z inna sciezka bazowa, do
tego moze jeszcze operatory = i +=, a nastepnie pisac:
disk/"home"/"rubylover"/"plik" += "moje dane"
W sumie, to jak juz jedziesz w takie obrzydlistwa, to przeciaz
operator "<<", ludzie ktorzy beda musieli z tego korzystac na
pewno wyraza ci swoja niepohamowna radosc z genialnosci tego
rozwiazania ;)
disk/"home"/"cpplover"/"plik"<<"hello"<<iostream.space<<"world"
Jaroslaw Zabiello
> Na samym wstępie wpisu powinieneś był zrobić podobny test, ale bez
> użycia wątków. Można by wtedy oszacować, ile zajmuje każdemu z
> interpreterów wykonanie kodu z run (stworzenie listy losowych elementów
> i posortowanie).
Slusznie. Przy odkrylem, ze kodzie mialem blad z iloscia elementow do
sortowania (co faworyzowalo Rubiego). Musze poprawic calosc.
> Jest PyObjC.
OK.
> No i niby jest możliwość tworzenia aplikacji w Pythonie/Rubym w Xcode
> (Cocoa-Python/Cocoa-Ruby).
To wiem, każdy Leopard ma zainstalowanego Pythona i Rubiego.
> Mówisz o rynku pracy w Polsce (pytanie w kontekście aplikacji webowych)?
Nie. Moje obserwacje dotyczą bardziej Irlandii i UK.
Jaroslaw Zabiello
> Na samym wstępie wpisu powinieneś był zrobić podobny test, ale bez
> użycia wątków. Można by wtedy oszacować, ile zajmuje każdemu z
> interpreterów wykonanie kodu z run (stworzenie listy losowych elementów
> i posortowanie).
1 thread, 2,000,000 iterations
1. Ruby 1.9 = 1.69 s.
2. Ruby Enterprise = 3.38 s.
3. JRuby 1.1.2 = 7.06 s.
4. Jython 2.2.1 = 17.29 s.
5. Python 2.5.2 = 18.06 s.
6. Ruby 1.8.7 = 22.37 s.
20 threads * 100,000 iterations
1. Ruby 1.9 = 1.54 s.
2. Ruby Enterprise = 3.01 s.
3. JRuby 1.1.2 = 5.82 s.
4. Jython 2.2.1 = 11.86 s.
5. Python 2.5.2 = 12.32 s.
6. Ruby 1.8.7 = 22.68 s.
Widzę, że zysk na wątkach nie jest jakiś wielka. Być może sposób działania
GC jest kluczowy w tym teście. Wiem na pewno że Ruby Enterprise ma tu dużo
usprawnień w stos. do Ruby MRI. Trochę dziwi, że Python 2.5.2 tak cienko
wypadł.
Radomir 'The Sheep' Dopieralski
Jaroslaw Zabiello wrote:
> Dnia 27-07-2008 o 11:54:54 Tomasz Elendt <nie...@maila.pl> napisał(a):
> Trochę dziwi, że Python 2.5.2 tak cienko wypadł.
A mnie dziwi, ze ktos wogole probuje ludziom wmawiac
ze tego typu porownania wogole maja jakis sens. Pomysl
najpierw troche co robi Twoja wersja w Pythonie a co robi
ta w Rubym.
HINT #1: Po wykomentowaniu a.sort() w pythonaie czas sie
nie zmienil za bardzo.
HINT #2: Python uzywa do generacji liczb pseudolosowych
algorytmu Mersenne Twister.
Taaaak, Python jest daleko w tyle za Rubym...
Alek
Użytkownik "Radomir 'The Sheep' Dopieralski" <ne...@sheep.art.pl> napisał w
wiadomości news:slrng8p2d...@atos.wmid.amu.edu.pl...
> At Sun, 27 Jul 2008 15:10:49 +0100,
> Jaroslaw Zabiello wrote:
>
>> Dnia 27-07-2008 o 11:54:54 Tomasz Elendt <nie...@maila.pl> napisał(a):
>
>
>> Trochę dziwi, że Python 2.5.2 tak cienko wypadł.
>
> A mnie dziwi, ze ktos wogole probuje ludziom wmawiac
> ze tego typu porownania wogole maja jakis sens. Pomysl
> najpierw troche co robi Twoja wersja w Pythonie a co robi
> ta w Rubym.
>
> HINT #1: Po wykomentowaniu a.sort() w pythonaie czas sie
> nie zmienil za bardzo.
>
> HINT #2: Python uzywa do generacji liczb pseudolosowych
> algorytmu Mersenne Twister.
>
> Taaaak, Python jest daleko w tyle za Rubym...
>
> --
Racja! Tez tak pomyslalem. To jest test na szybkosc generator liczb
losowych.
Dosc kuriozalnie wyglada tez petla:
while True in [t.isAlive() for t in threads]:
pass
Niech sie specjalisci od Pythona wypowiedza, bo nie wiem czy dobrze mysle,
ale wydaje mi sie, ze w tej petli lista z warunku while jest tworzona przy
kazdym przebiegu. To sie nazywa aktywne czekanie i chyba tez nieznacznie
spowalnia dzialanie calego kodu.
Nie latwiej to zrobic w ten sposob?
for t in threads:
t.join()
Oprocz tego w Test.run() zmienilbym:
a = [rand(0,SIZE) for x in xrange(SIZE)]
a.sort()
na:
a = sorted([rand(0, SIZE) for x in xrange(SIZE)])
Alek
Seweryn Habdank-Wojewódzki
> 20 threads * 100,000 iterations
>
> 5. Python 2.5.2 = 12.32 s.
U mnie na starym lapciaku - Intel 1.4 GHz single core.
Python + Psyco bez sortowania = 3.91
Python + Psyco z sortowaniem = 7.97
Pozdrawiam,
Seweryn Habdank-Wojewódzki.
Ps. Dlaczego Pythona sprowadza się do roli języka aplikacji Webowych?
W rubym np. nie widziałem SciRu. A Scipy służy już całkiem pokaźnej
liczbie naukowców jako substytut drogiego Matlaba.
Piotr Husiatyński
wrote:
Zeby było porównanie, dla kodu który został użyty na samym początku -
skrypt bez żadnych modyfikacji:
real 0m12.689s
user 0m12.129s
sys 0m1.943s
wersja z psyco, czyli dopisanie 2 linijek:
real 0m5.159s
user 0m5.073s
sys 0m0.013s
Nie wiem dlaczego, ale mam tą samą wersję Pythona (2.5.2) i gorszy
komputer (oryginalne testy były robione na macbook pro, a ja robiłem
na zwykłym macbooku)
i zamiast 14.24s mam 12.68s.
Ten przykład i tak jest `z życia wzięty`, ale w innych przypadkach
można przepisać fragment w C++ i użyć boost::Python. Nie trzeba męczyć
się z C API, nie trzeba rwać włosów jak zoptymalizować kod Pythona. W
Ruby tego nie ma :)
Skoro "Który język pozostaje w tyle?" to może warto zwrócić uwagę na
ilość i jakość bibliotek?
Filip Wasilewski
> Użytkownik "Radomir 'The Sheep' Dopieralski" <n...@sheep.art.pl> napisał w
> wiadomościnews:slrng8p2d...@atos.wmid.amu.edu.pl...
>
>
>
> > At Sun, 27 Jul 2008 15:10:49 +0100,
> > Jaroslaw Zabiello wrote:
>
> >> Dnia 27-07-2008 o 11:54:54 Tomasz Elendt <nie...@maila.pl> napisał(a):
>
> >> Trochę dziwi, że Python 2.5.2 tak cienko wypadł.
>
> > A mnie dziwi, ze ktos wogole probuje ludziom wmawiac
> > ze tego typu porownania wogole maja jakis sens. Pomysl
> > najpierw troche co robi Twoja wersja w Pythonie a co robi
> > ta w Rubym.
>
> > HINT #1: Po wykomentowaniu a.sort() w pythonaie czas sie
> > nie zmienil za bardzo.
>
> > HINT #2: Python uzywa do generacji liczb pseudolosowych
> > algorytmu Mersenne Twister.
>
> > Taaaak, Python jest daleko w tyle za Rubym...
>
> > --
>
> Racja! Tez tak pomyslalem. To jest test na szybkosc generator liczb
> losowych.
Słuszna uwaga.
> Dosc kuriozalnie wyglada tez petla:
>
> while True in [t.isAlive() for t in threads]:
> pass
>
> Niech sie specjalisci od Pythona wypowiedza, bo nie wiem czy dobrze mysle,
> ale wydaje mi sie, ze w tej petli lista z warunku while jest tworzona przy
> kazdym przebiegu. To sie nazywa aktywne czekanie i chyba tez nieznacznie
> spowalnia dzialanie calego kodu.
>
> Nie latwiej to zrobic w ten sposob?
>
> for t in threads:
> t.join()
Łatwiej i na dodatek poprawnie. Do tego właśnie służy metoda join,
żeby nie sprawdzać w pętli, czy wszystkie wątki się już zakończyły.
> Oprocz tego w Test.run() zmienilbym:
>
> a = [rand(0,SIZE) for x in xrange(SIZE)]
> a.sort()
>
> na:
>
> a = sorted([rand(0, SIZE) for x in xrange(SIZE)])
Tu niekoniecznie, gdyż sorted tworzy kopię listy wejściowej, podczas
gdy metoda list.sort działa w miejscu.
@JZ: Podstawowe pytania, na które nie znalazłem odpowiedzi w cytowanym
artykule: co jest przedmiotem tego porównania? Szybkość przygotowania
danych wejściowych i implementacja generatora liczb losowych (a co z
jego jakością, która przecież może mieć wpływ na prędkość samego
sortowania?), implementacja algorytmów sortowania, wpływ pętli while-
true na pozostałe elementy programu czy też wreszcie prędkość zapisu
na standardowe wyjście?
Mając zdefiniowany problem należałoby się zastanowić, jaka jest
najlepsza metoda jego rozwiązania i użyć jej.
Wybrany przykład wydaje się dość niefortunny, gdyż nie można
jednoznacznie określić, co ma wpływ na wyniki testu i niestety nie
wnosi nic więcej ponad to, co już przerabialiśmy na tej grupie przy
innych okazjach (no może oprócz porównania różnych implementacji
Rubiego). Co do samej metodologii, to zabrakło również (poza jej
opisem) uzasadnienia wyboru liczby wątków i rozmiaru danych
wejściowych (nie mówiąc już o analizie dla różnych przypadków i
wspólnym zbiorze danych wejściowych) oraz podstawowych danych
statystycznych jak ilość prób, najkrótszy oraz średni czas, odchylenie
standardowe itp. Tyle moich wniosków.
f.
Jaroslaw Zabiello
napisał(a):
>> 20 threads * 100,000 iterations
>>
>> 5. Python 2.5.2 = 12.32 s.
>
> U mnie na starym lapciaku - Intel 1.4 GHz single core.
>
> Python + Psyco bez sortowania = 3.91
> Python + Psyco z sortowaniem = 7.97
Ja mam 64-bitowy system, a Psyco jest dostępne tylko dla 32bit.
> Ps. Dlaczego Pythona sprowadza się do roli języka aplikacji Webowych?
Nikt tego nie robi.
> W rubym np. nie widziałem SciRu.
No tak, ale z 2 strony dzięki JRuby masz dostęp do wszystkiego co jest
dostępne dla Javy.
Jaroslaw Zabiello
napisał(a):
> Nie wiem dlaczego, ale mam tą samą wersję Pythona (2.5.2) i gorszy
> komputer (oryginalne testy były robione na macbook pro, a ja robiłem
> na zwykłym macbooku)
> i zamiast 14.24s mam 12.68s.
Zależy jaki MacBook. Te nowe mają szybszy procesor niż wcześniejsze MBP.
Dlatego podałem zegar 2.16GHz, ja mam jeden z tych pierwszych modeli. No i
mam trochę innych rzeczy działających w tle, różne tam MySQL, Apache i
inne serwery. Dlatego najlepiej robić wszystkie testy na tym samym
sprzęcie a nie porównywać wyniki z różnych maszyn.
> Ten przykład i tak jest `z życia wzięty`, ale w innych przypadkach
> można przepisać fragment w C++ i użyć boost::Python. Nie trzeba męczyć
> się z C API, nie trzeba rwać włosów jak zoptymalizować kod Pythona. W
> Ruby tego nie ma :)
Jak to nie ma? Ty chyba żarty sobie stroisz. W RubyInline napiszesz
rozszerzenie C jeszcze prościej niż ten cały boost.
http://www.zenspider.com/ZSS/Products/RubyInline/
> Skoro "Który język pozostaje w tyle?" to może warto zwrócić uwagę na
> ilość i jakość bibliotek?
Masz na myśli RSpec, którego DSL jest zupełnie poza możliwościami Pythona?
A może wszystkie biblioteki Javy, z których może korzystać JRuby? ;) Tak
naprawdę liczy się to, czy są biblioteki do tego, co potrzebujesz.
Jaroslaw Zabiello
> Nie latwiej to zrobic w ten sposob?
>
> for t in threads:
> t.join()
Tak miałem na początku, ale chciałem upodobnić oba kody.
> Oprocz tego w Test.run() zmienilbym:
>
> a = [rand(0,SIZE) for x in xrange(SIZE)]
> a.sort()
>
> na:
>
> a = sorted([rand(0, SIZE) for x in xrange(SIZE)])
Też tak miałem, ale musiałem z tego zrezygnować, bo taka forma nie działa
w Jythonie.
Jaroslaw Zabiello
napisał(a):
> @JZ: Podstawowe pytania, na które nie znalazłem odpowiedzi w cytowanym
> artykule: co jest przedmiotem tego porównania? Szybkość przygotowania
> danych wejściowych i implementacja generatora liczb losowych (a co z
> jego jakością, która przecież może mieć wpływ na prędkość samego
> sortowania?), implementacja algorytmów sortowania, wpływ pętli while-
> true na pozostałe elementy programu czy też wreszcie prędkość zapisu
> na standardowe wyjście?
OK. Cała historia tego tekstu wygląda tak, że zaczęło się od tego, że na
liście Rubiego padło zdanie, że Ruby MRI ze swymi green threads jest dużo
wolniejszy od JRuby, który ma natywne wątki systemowe. Chciałem więc
sprawdzić jak to jest z tymi wątkami. A że Python też używa podobnego
modelu wątków, więc sprawdziłem przy okazji i Pythona.
Wyniki mnie trochę zdziwiły, bo okazało, że JRuby jest szybszy od Ruby MRI
nie dlatego, że używa systemowych wątków ale dlatego, że jest wewnętrznie
lepiej zoptymalizowany (w tym wypadku). Taka sama przepaść wydajności była
bez względu na ilość równolegle zapuszczonych wątków. A przy okazji wyszło
kilka ciekawostek, np. ci goście od Passengera nieźle poprawili Ruby MRI.
Albo to, że Ruby 1.9 i JRuby potrafią pobić wydajnościowo Pythona i
Jythona.
Dużo się zmieniło odnośnie wydajności Rubiego. I może być jeszcze lepiej,
bo developerzy MagLev (wirtualna maszyna GemStone na Smalltalka
dostosowana do przetwarzania kodu Rubiego) są przekonani, że ze względu na
wielkie podobieństwo Rubiego do Smalltalka, nie ma żadnych przeciwskazań,
aby na maszynie wirtualnej MagLev, Ruby osiągnął wydajność jaką ma
Smalltalk. A to by oznaczało, że Ruby będzie 10x szybszy od Pythona!
No i przy okazji uzyskałby przezroczysty, obiektowy model zapisu danych
jaki ma GemStone. Python straciłby kolejnego asa w rękawie jakim jest
ZODB. MagLev zapewnia bardzo wydajną pracę z obiektami w ilości tysięcy
miliardów. No cóż, GemStone jest używany komercyjnie i optymalizują go od
ponad 20 lat... Jak pojawi się MagLev to będzie mała rewolucja.
Jaroslaw Zabiello
<ne...@sheep.art.pl> napisał(a):
>>> 'test.txt'.write("costam")
>>
>> Nie da się. Python nie umie takich rzeczy. Jak chcesz krótko to zrób
>> tak:
>>
>> open('test.txt', 'w').write('costam')
>
> Na upratego mozesz sobie zrobic jakis obiekt w rodzaju "disk",
> dodac go to builtins, przeciazyc mu operator dzielenia
> disk/"home"/"rubylover"/"plik" += "moje dane"
Obaj się raczej zgodzimy, że to nie ma sensu. Mnie tam pythonowy open()
nie przeszkadza. Choć prawdę mówiąc bardziej podoba mi się składnia
używanie metod klasowych i bloków kodu w Ruby, niż takich nieobiektowych,
funkcyjnych metod. Zauważyłem też u siebie, że po zapoznaniu się z Ruby,
próbowałem później tworzyć w Pythonie więcej klasowych metod niż kiedyś,
ale niestety, nie wygląda to tam już tak ładnie. Ruby jest trochę
ładniejszym językiem.
Arkadiusz 'nare' Kindziuk
>> Nie latwiej to zrobic w ten sposob?
>>
>> for t in threads:
>> t.join()
>
> Tak miałem na początku, ale chciałem upodobnić oba kody.
>
w pythonie z aktywnym czekaniem. To że w pythonie zapis
poprawnego kodu lepiej wygląda to inna sprawa, na siłę
nie możesz psuć kodu aby go upodobnić do rubego w
warstwie wizualnej.
Aby to zaobserwować w swoich przykładach zastąp generację
listy liczbami pseudolosowymi, jej sortowaniem zwykłą
metodą sleep(secs) i przetestuj za pomocą komendy
bashowej time. Zobaczysz, że zapis w rubym i ta
zacytowana pętla nie wykorzystuje procka, Twoja
implementacja zarzyna procka.
>> Oprocz tego w Test.run() zmienilbym:
>>
>> a = [rand(0,SIZE) for x in xrange(SIZE)]
>> a.sort()
>>
>> na:
>>
>> a = sorted([rand(0, SIZE) for x in xrange(SIZE)])
>
> Też tak miałem, ale musiałem z tego zrezygnować, bo taka forma nie działa
> w Jythonie.
Yep, to zaciemnia kod tylko.
Btw testem udowodniłeś, że lepszy generator liczb pseudolosowych
potrzebuje więcej czasu na wygenerowanie liczby (przy porównaniu
python <-> ruby). Jeżeli chcesz mierzyć coś innego (python <-> ruby)
to napisz własną zaślepkę (PseudoGeneratora), nawet w stylu
x = (x^2+1) % modulo. Otrzymasz, że ruby1.9 i python2.5 będą miały
podobne czasy.
ps. Porównując implementacje wątków zrezygnowałbym z sortowania
(wrzuciłbym jakieś czasochłonne obliczenia liniowo zależne od SIZE) i
mierzyłbym jak jakie procentowe przyspieszenia się uzyskuje zmieniając
parametry SIZE, THREADS (gdzie SIZE * THREADS = constans)
--
Arkadiusz Kindziuk
"Zasady zmieniają się całkowicie.
Szachy, nie warcaby. Go, nie szachy.
Rozumiesz?" (c) Neil Gaiman, "Władca Górskiej Doliny"
Radomir 'The Sheep' Dopieralski
Jaroslaw Zabiello wrote:
> Dnia 27-07-2008 o 22:37:16 Filip Wasilewski <filipwa...@gmail.com>
> napisał(a):
> Wyniki mnie trochę zdziwiły, bo okazało, że JRuby jest szybszy od Ruby MRI
> nie dlatego, że używa systemowych wątków ale dlatego, że jest wewnętrznie
> lepiej zoptymalizowany (w tym wypadku).
Jestes calkowicie pewien, ze i tutaj roznica nie wynika z uzycia duzo
prymitywniejsze go generatora liczb losowych, albo tez uzycia generatorow
pisanych w roznych jezykach? To by mi pasowalo: mlodsze, mniej roziwniete
implementacje moga miec prosty, napisany ad hoc generator...
i0cus
> Dnia 24-07-2008 o 14:59:17 Marek <no.em...@no.spam> napisał(a):
>
> > no tak, wcześniej próbowałem swoich sił w ruby, ale z tego co widzę
> > tej język zostaje raczej w tyle, np. nie mają windowsowej instalki
>
> No tak... Windows (już dawno porzuciłem to badziewie). Jeśli chodzi już o
> Javę, to jest dokładnie odwrotnie. Python zostaje w tyle. JRuby jest dużo
> szybszy i dojrzalszy od Jythona. Także pod względem wątków Ruby też tłucze
> niemiłosiernie Pythona. Zarówno wydajnościowo jak czytelniejszą składnią.
> (vide:http://blog.zabiello.com/articles/2008/07/26/threads-ruby-python)
Tak, windows. Może trudno w to uwierzyć, ale w niektórych korporacjach
używa się jeszcze tego przestarzałego systemu na desktopach i
serwerach. Ruby jest pewnie zbyt poważny do takich zastosowań, stąd
olewanie ,,tego badziewia''. Co do wniosku -- sam Pan stwierdził w
linkowanym artykule, że w opisywanym przypadku nie idzie o wątki. Na
moje oko allokacja dużej listy w pythonie ssie. Cóż, poświęciłem
dwadzieścia sekund na sprawdzenie co się dzieje, zanim wziąłem się za
pisanie notki na bloga.
Czytelniejsza składania Ruby? To stwierdzeniu w zasadzie jest dla mnie
zwykle terminatorem dyskusji.
> No i oczywiście RSpec (http://rspec.net) i Behavioral & Story Driven
> Development (http://goruco2008.confreaks.com/01_helmkamp.html). W
> dziedzinie testów behawioralnych Python, z ty swoim starym Test Driven
> Development jest 100 lat za Murzynami.
Ja tam jestem fanem Stupidity Driven Testing i sobie chwalę. Google
jakoś sobie daje radę z TDD w Pythonie (mają swój framework i nie
psioczą), ale pewnie jest znaczna różnica między czymś co działa, a
czymś co jest dżezi (czy jak tam się teraz określa hype). Nie wiem,
nie mam czasu na modę.
> Python ma jeszcze kilka dziedzin w których jest dojrzalszy ale pewnie
> szybko je też traci, bo Ruby rozwija się w ekspresowym tempie. To, który
> jest z tyłu zależy od dziedziny i cały czas to się szybko zmienia. Także
> na rynku pracy sytuacja się szybko zmienia. Ruby zaczyna powoli dominować.
> W dziedzinie aplikacji webowych faktycznie już pobił popularnością Pythona.
Pewnie tak, w końcu Pythonem nikt się nie zajmuje, a już na pewno nikt
go nie używa. Rynek aplikacji webowych? To jeszcze tylko Java i PHP?
Wait, what?
> Jarosław Zabiełłohttp://blog.zabiello.com
--
Pozdrawiam,
SG
Marek
Urbanowicz) wrote:
>Ale po co. Explicit is better than implict, a jak chcesz pisać krótkie
>programy to pisz w assemblerze.
ale im mniejszy kod źródłowy tym mniejsza szansa na błąd, oczywiście
chodzi o to aby zmniejszać tak aby było czytelnie
Janusz A. Urbanowicz
To o co pytałeś znakomicie pograsza czytelność i konserwowalność kodu.
chester
>
> No tak, ale z 2 strony dzięki JRuby masz dostęp do wszystkiego co jest
> dostępne dla Javy.
Jython ?
chester
Sebastian Kaliszewski
> No tak... Windows (już dawno porzuciłem to badziewie). Jeśli chodzi już
> o Javę, to jest dokładnie odwrotnie. Python zostaje w tyle. JRuby jest
> dużo szybszy i dojrzalszy od Jythona. Także pod względem wątków Ruby też
> tłucze niemiłosiernie Pythona. Zarówno wydajnościowo jak czytelniejszą
> składnią. (vide:
> http://blog.zabiello.com/articles/2008/07/26/threads-ruby-python)
Gdyby to tylko miało coś wspólnego z wątkami (a nie szybkością
generatora liczb losowych) -- ale o tym już inni pisali. Ale o i tak bez
znaczenia. Bo takie życiowe inaczej testy są kompletnie bez sensu.
[...]
> No i oczywiście RSpec (http://rspec.net) i Behavioral & Story Driven
> Development (http://goruco2008.confreaks.com/01_helmkamp.html).
Och. A niedługo będzie Bullshit & Nonsense Driven Development albo Smoke
& Mirrors Driven Development, albo...
> W
> dziedzinie testów behawioralnych Python, z ty swoim starym Test Driven
> Development jest 100 lat za Murzynami.
Wiesz, tego typu nowomowa przestała mnie interesować jakieś 15 lat temu...
To dobre dla dzieciaków. Ale jakoś nie widziałem jeszcze dobrego systemu
zrobionego przez dzieciaki...
> Python ma jeszcze kilka dziedzin w których jest dojrzalszy ale pewnie
> szybko je też traci, bo Ruby rozwija się w ekspresowym tempie. To, który
> jest z tyłu zależy od dziedziny i cały czas to się szybko zmienia. Także
> na rynku pracy sytuacja się szybko zmienia. Ruby zaczyna powoli
> dominować. W dziedzinie aplikacji webowych faktycznie już pobił
> popularnością Pythona.
>
LOL!
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
~2x mniej to "dominacja". Ciekawe...
I jeszcze kwiatek z bloga:
[cytat]
Co ciekawe, Python 2.5.2 okazał się najwolniejszy. Im więcej wątków tym
jeszcze wolniej działał. Był wolniejszy nawet od (dziwnie wolnego) Ruby
1.8.6. Ale, być może to jest wina bardzo wolnej biblioteki generowania
losowych liczb. Ech, jak tu cokolwiek porównywać między językami jak
takie odkrywa się takie babole w bibliotece standardowej Pythona.
Jython był jeszcze wolniejszy. Dla 10 mln. iteracji, mimo że nie były
tworzone w pamięci żadne listy, wlókł się tak wolno, że przerwałem test.
Po zmniejszeniu iteracji o rząd wielkości (do 1 miliona) uzyskał wyniki
takie jak Ruby 1.8.6 dla 10 milionów iteracji. Jython jest najwyraźniej
jeszcze bardzo słabo zoptymalizowany. Pomysły aby na nim odpalać
frameworki takie jak Django, to na razie raczej przedwczesny pomysł.
[/cytat]
Jak szanujący się inżynier może napisać coś takiego???
1. To o liczbach losowych to nonsens kompletny. Bez porównania jakości
generoatorów.
2. Co ma mielenie bezsensownych obliczeń do odpalania frameworku webowego?
pzdr
--
"Never underestimate the power of human stupidity" -- L. Lang
--
http://www.tajga.org -- (some photos from my travels)
Sebastian Kaliszewski
> Dnia 27-07-2008 o 17:54:54 Seweryn Habdank-Wojewódzki
> <hab...@gmail.com> napisał(a):
>
>>> 20 threads * 100,000 iterations
>>>
>>> 5. Python 2.5.2 = 12.32 s.
>>
>> U mnie na starym lapciaku - Intel 1.4 GHz single core.
>>
>> Python + Psyco bez sortowania = 3.91
>> Python + Psyco z sortowaniem = 7.97
>
> Ja mam 64-bitowy system, a Psyco jest dostępne tylko dla 32bit.
Na moim 64-bitowym systemie aplikacje 32-bit działają...
>> Ps. Dlaczego Pythona sprowadza się do roli języka aplikacji Webowych?
>
> Nikt tego nie robi.
>
>> W rubym np. nie widziałem SciRu.
>
> No tak, ale z 2 strony dzięki JRuby masz dostęp do wszystkiego co jest
> dostępne dla Javy.
I co jest dopasowane do Javy. Jakoś tak wolę napisać a*b zamiast
a.MultiplyBy(b) w celu pomnożenia macierzy.
Michał Dwużnik
> Jaroslaw Zabiello wrote:
>> No tak... Windows (już dawno porzuciłem to badziewie). Jeśli chodzi
>> już o Javę, to jest dokładnie odwrotnie. Python zostaje w tyle. JRuby
>> jest dużo szybszy i dojrzalszy od Jythona. Także pod względem wątków
>> Ruby też tłucze niemiłosiernie Pythona. Zarówno wydajnościowo jak
>> czytelniejszą składnią. (vide:
>> http://blog.zabiello.com/articles/2008/07/26/threads-ruby-python)
>
> Gdyby to tylko miało coś wspólnego z wątkami (a nie szybkością
> generatora liczb losowych) -- ale o tym już inni pisali. Ale o i tak bez
> znaczenia. Bo takie życiowe inaczej testy są kompletnie bez sensu.
>
Michał
Maciej Piechotka
> On 2008-07-24, Marek <no.e...@no.spam> wroted:
>
>> btw
>> to można by było rozwinąć bardziej np.
>>
>> 'test.txt'.w?'[tu ma byc regex]':'cośtam'
>>
>> regex wykonywał by funkcję jeśli string lub liczba przemieniona na
>> string pasowały by do regexu
>
> Naprawdę, chyba się za dużo napatrzyłeś na Perla czy inne Ruby.
>
> GS
IMHO perla bo open-classes nie mają chyba służyć mieszaniu pojęć (string/plik)
tylko dodawaniu metod pasujących (np. .camelize pasuje do klasy String).
Pozdrawiam
PS.
Co powinna robić metoda 'file'.write('ddd')? Nadpisywać zawartość? Dodawać
na początku końcu? Czego - pliku stringa?
--
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)
Maciej Piechotka
> Wojciech Muła <wojcie...@poczta.null.onet.pl.invalid> writes:
>
>> al...@bofh.org.pl (Janusz A. Urbanowicz) wrote:
>>
>>> Ale po co. Explicit is better than implict, a jak chcesz pisać krótkie
>>> programy to pisz w assemblerze.
>>
>> Krótkie programy w asemblerze? Nie stwierdzono takiego. :)
>
> Binarki będą małe, no.
>
Doświadczenie mówi że mogą być większe i wolniejsze niż analogiczny program
w C/C++...
Pozdrawiam
Jaroslaw Zabiello
<s.bez...@remove.that.informa.and.that.pl> napisał(a):
>> No i oczywiście RSpec (http://rspec.net) i Behavioral & Story Driven
>> Development (http://goruco2008.confreaks.com/01_helmkamp.html).
>
> Och. A niedługo będzie Bullshit & Nonsense Driven Development albo Smoke
> & Mirrors Driven Development, albo...
Widze, ze kolega nie wie nawet o czym mowa. Polecam uzupelnic braki.
"Beyond Test Driven Development: Behaviour Driven Development"
http://www.youtube.com/watch?v=oOFfHzrIDPk
>> W dziedzinie testów behawioralnych Python, z ty swoim starym Test
>> Driven Development jest 100 lat za Murzynami.
>
> Wiesz, tego typu nowomowa przestała mnie interesować jakieś 15 lat
> temu...
Hehe, stary piernik z ciebie. Nie nadazasz za zmianami. Nawet nie wiesz o
czym mowa. TDD to badziewie. Bo niby czym jest "jednostka" w tym unit
testing? To jakas klasa, metoda, modul, fragment kodu? Metne to i bez
sensu. BDD testuje oczekiwania wobec aplikacji, a nie jakies bezsensowne,
blizej nieokreslone, "jednostki". A Story Development to BDD ale podane w
inny sposob, wysokopoziomowe scenariusze zachowan, swietne do
bezposredniego kontaktu z klientem. Tworzy sie to prawie tak jak zdania w
jez. angielskim i jest to w stanie zrozumiec nawet marketingowiec.
>> Python ma jeszcze kilka dziedzin w których jest dojrzalszy ale pewnie
>> szybko je też traci, bo Ruby rozwija się w ekspresowym tempie. To,
>> który jest z tyłu zależy od dziedziny i cały czas to się szybko
>> zmienia. Także na rynku pracy sytuacja się szybko zmienia. Ruby zaczyna
>> powoli dominować. W dziedzinie aplikacji webowych faktycznie już pobił
>> popularnością Pythona.
>>
>
> LOL!
>
> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
W dupie mam teoretyzowanie w tiobe. Widze w ofertach w Irlandii, ze
szukaja osoby znajace Rubiego a nie Pythona. Znajomego javowca odrzucili
bo nie znal Rubiego. Jak widze jakies oferty dla pythonowcow, to glownie
dla administratorow systemu.
> 2. Co ma mielenie bezsensownych obliczeń do odpalania frameworku
> webowego?
A odpal cokolwiek innego madralo. Myslisz, ze biezaca implementacja
Jythona moze rownac sie z JRuby? :)
Jaroslaw Zabiello
<s.bez...@remove.that.informa.and.that.pl> napisał(a):
>>> Python + Psyco bez sortowania = 3.91
>>> Python + Psyco z sortowaniem = 7.97
>
>> Ja mam 64-bitowy system, a Psyco jest dostępne tylko dla 32bit.
>
> Na moim 64-bitowym systemie aplikacje 32-bit działają...
Aplikacje tak, Psyco - nie.
Jaroslaw Zabiello
napisał(a):
>> No tak, ale z 2 strony dzięki JRuby masz dostęp do wszystkiego co jest
>> dostępne dla Javy.
>
> Jython ?
Jython jest duzo mniej dojrzaly.
Sebastian Kaliszewski
> Dnia 06-08-2008 o 15:31:11 Sebastian Kaliszewski
> <s.bez...@remove.that.informa.and.that.pl> napisał(a):
>
>>>> Python + Psyco bez sortowania = 3.91
>>>> Python + Psyco z sortowaniem = 7.97
>>
>>> Ja mam 64-bitowy system, a Psyco jest dostępne tylko dla 32bit.
>>
>> Na moim 64-bitowym systemie aplikacje 32-bit działają...
>
> Aplikacje tak, Psyco - nie.
>
Psyco też działa.
Sebastian Kaliszewski
>>> No i oczywiście RSpec (http://rspec.net) i Behavioral & Story Driven
>>> Development (http://goruco2008.confreaks.com/01_helmkamp.html).
>>
>> Och. A niedługo będzie Bullshit & Nonsense Driven Development albo
>> Smoke & Mirrors Driven Development, albo...
>
> Widze, ze kolega nie wie nawet o czym mowa.
Kolega wie. Tylko kolega ma w nosie nowomodę (i nowomodną nowomowę).
> Polecam uzupelnic braki.
Polecam nie podniecać zbytnio się nowymi pomysłami dzieciaków dla
dzieciaków.
> "Beyond Test Driven Development: Behaviour Driven Development"
> http://www.youtube.com/watch?v=oOFfHzrIDPk
Kolejny link w stylu "dla analfabetów". Młode pistolety nie potrafią już
swoich bajek nawet pisać. Albo nie chcą -- może ze strachu że po odlaniu
wody, odcedzeniu rzeczy znanych od pół wieku i odsianiu machania rękami
nie zostanie NIC.
>>> W dziedzinie testów behawioralnych Python, z ty swoim starym Test
>>> Driven Development jest 100 lat za Murzynami.
>>
>> Wiesz, tego typu nowomowa przestała mnie interesować jakieś 15 lat
>> temu...
>
> Hehe, stary piernik z ciebie. Nie nadazasz za zmianami.
Z nadążaniem za zmianami (których jest zresztą mało) nie mam problemów.
nadążaniem za bzdurami też nie mam problemów -- po prostu mnie nie
interesują.
> Nawet nie wiesz
> o czym mowa.
LOL!
Bullshit & Nonsense Driven Development bije na głowę wszelkie BDD, i
takie tam. To prawidziwy skok w Nową Erę(tm). Tu się już aplikacji w
ogóle nie pisze! W nienapisanej aplikacji nie ma błędów, testy nie mogą
się nie udać. Klient dostaje Kit(tm) A kasa leci.
Jeśli klient będzie tak bezczelny, że się połapie, to mamy zawsze w
zanadrzu Smoke & Mirrors Based Development.
> TDD to badziewie. Bo niby czym jest "jednostka" w tym unit
> testing? To jakas klasa, metoda, modul, fragment kodu?
Jest to logiczny zamknięty fragment kodu aplikacji. A nie machanie
rękami. Test jednostkowy ma pomóc w weryfikacji poprawności konkretnego
zamkniętego fragmentu.
> Metne to i bez
> sensu.
ROTFL!
> BDD testuje oczekiwania wobec aplikacji, a nie jakies
> bezsensowne, blizej nieokreslone, "jednostki".
Ja chcę okienko w kwiatki, i oczekuję, że aplikacja będzie dobrze działać.
Kolego. Jednostki są właśnie dobrze określone. Oczekiwania to jest
właśnie mętne bez sensu.
> A Story Development to
> BDD ale podane w inny sposob, wysokopoziomowe scenariusze zachowan,
> swietne do bezposredniego kontaktu z klientem.
Kolego, scenariusze zachowań to są znane od pół wieku. Zamiast
nowomodnie bajać, warto czasem popatrzeć jak to się robiło przed
swoim/moim/Twoim urodzeniem.
No, ale jak już zauważyłem wcześniej, prorocy nowego idą pełną parą w
analfabetyzm -- nie potrafią już napisać co też takiego "wspaniałego"
wymyślili -- nie należy więc oczekiwać, że będą (w stanie) coś
przeczytać, zwłaszcza jakieś "historyczne dyrdymały kompletnie nie modne".
> Tworzy sie to prawie tak
> jak zdania w jez. angielskim i jest to w stanie zrozumiec nawet
> marketingowiec.
>
>>> Python ma jeszcze kilka dziedzin w których jest dojrzalszy ale pewnie
>>> szybko je też traci, bo Ruby rozwija się w ekspresowym tempie. To,
>>> który jest z tyłu zależy od dziedziny i cały czas to się szybko
>>> zmienia. Także na rynku pracy sytuacja się szybko zmienia. Ruby
>>> zaczyna powoli dominować. W dziedzinie aplikacji webowych faktycznie
>>> już pobił popularnością Pythona.
>>>
>>
>> LOL!
>>
>> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
>
> W dupie mam teoretyzowanie w tiobe.
W dupie mam pomiary, wolę machać rękami. "I nikt mi nie wmówi że białe
jest białe a czarne czarne..."
> Widze w ofertach w Irlandii, ze
> szukaja osoby znajace Rubiego a nie Pythona. Znajomego javowca odrzucili
> bo nie znal Rubiego. Jak widze jakies oferty dla pythonowcow, to glownie
> dla administratorow systemu.
Ach tak więc przeprowadziłeś badania na "szeroką" skalę -- jednego
znajomego javowca odrzucili.
>> 2. Co ma mielenie bezsensownych obliczeń do odpalania frameworku
>> webowego?
>
> A odpal cokolwiek innego madralo.
"Ponieważ nie umiem pływać proszę w ramach sprawdzianu z pływania
zmierzyć mi liczbę podskoków na jednej nodze na minutę".
Jak nie masz pojęcia o testowaniu wydajności to po co się za to bierzesz?
> Myslisz, ze biezaca implementacja
> Jythona moze rownac sie z JRuby? :)
Whatever. Rozumiałbym test wydajności generowania treści, połączenia z
bazą danych, itp. Ale to co Ty, kolego, pokazałeś jest kompletnie w
trzecią stronę. I nawet w tym kilkulinijkowym niby-tescie nie byłeś w
stanie stwierdzić co tak na prawdę testujesz.
A wyciąganie wniosków na temat przydatności do tworzenia aplikacji
webowych na podstawie szybkości generatora liczb pseudolosowych byłoby
komiczne gdyby napisał to gimnazlalista. Ale kiedy takie rzeczy wypisuje
inżynier (i to nie od dziś) to to jest tragifarsa.
Seweryn Habdank-Wojewódzki
> Metne to i bez
> sensu. BDD testuje oczekiwania wobec aplikacji
Hmm... pisze:
Aplikacja Predyktor Kalmana-Bucy'ego.
I mam? Co?
> A Story Development to BDD ale podane w
> inny sposob, wysokopoziomowe scenariusze zachowan, swietne do
> bezposredniego kontaktu z klientem.
Aplikacji webowych to i moze. A na nich swiat sie nie konczy.
Pomysl o serwerach obliczeniowych. Klient tego nawet nie dotyka.
On zazwyczaj nie ma ZIELONEGO pojecia jaka maszyneria za tym siedzi.
Wez poczytaj o wycenie opcji. Klient dostaje liczbe i tyle.
Nic nie wie skad sie wziela. Tak wiec kontakt bezposredni z klientem
nie zawsze ma sens.
> Tworzy sie to prawie tak jak zdania w
> jez. angielskim i jest to w stanie zrozumiec nawet marketingowiec.
O jasne. Nie znam marketingowca, ktory zna rownania rozniczkowe,
a co dopiero giganty matematyczne siedzace za aplikacjami finansowymi
przez duze F.
> W dupie mam teoretyzowanie w tiobe. Widze w ofertach w Irlandii, ze
> szukaja osoby znajace Rubiego a nie Pythona.
O a ta Irlandia to jakis Eden? U mnie w firmie Python jest do uzywania
jako soft do pisania Tooli. Ruby w ogole nie jest uznawany za
jakkolwiek
przydatny jezyk.
Pozdrawiam,
Seweryn Habdank-Wojewodzki.
Seweryn Habdank-Wojewódzki
> "Beyond Test Driven Development: Behaviour Driven Development
> "http://www.youtube.com/watch?v=oOFfHzrIDPk
Super pogadanka. Dowiedziałem się, że prelegent napisał książkę o TDD.
Za chwilę dowiedziałem się, że TDD to "Bullshit", czyli jego książka
jako
podzbiór TDD również.
W aparycji tego preleganta brakowało mi słomy.
Dużo słomy. Słomkowy kapelusz, słoma w głowie, słoma wystająca z
butów.
Dobrze, że istnieje piwo robione ze zborza, bo jakoś mogłem
uzupełnić słomiane braki w specyfikacji tego prelegenta.
Jak już zostało powiedziane prelegent napisał może kilkanaście zdań.
Wykazał się znajomością frameworków, które w całej rozciągłości
skrytykował. Super ja też nie przepadam za setkami frameworków,
bo zamiast koncentrować się na meritum sprawy, trzeba wiedzieć
że I.should.use.the.framework (framework_1).
Bardzo wysoki poziom testów jest przezentowany przez
empty_class.should.be.empty(),
gdzie: "be" is syntactic sugar.
To co potwierdziło moje odczucia, to fakt, że do Javy
jest potrzebny testDox bo
CamelCaseJestNieCzytelny.a.should.be.czytelny().
Zauważyłem jeden bardzo dobry punkt w BDD. Testerzy już
nawet nie muszą umieć pisać assercji. To jest takie uciążliwe,
wymaga przynajmniej Bs.C.. Teraz dzięki BDD możemy potanić
testerow wystarczy
tester.should.write.correctly.the.word(should),
gdzie: "the" jest syntactic sugar.
Natomiat technicznie mnie powalił fakt dowodzenia kiepskości TDD na
podstawie faktu, że prelegent musiał grzebać w prywatnej sekcji
jakiejś klasy. Jeżeli tester to tobił, TO
this.class.should.be.refactored.a.year.ago().
Dodam, że "class", "be" i "a" w tym rSpec-u jest syntactic sugar.
Chyba w fimie mamy przeinwestowaną sekcję QA. Potrzeba nam więcej
słomy.
Dyskusja na temat must vs. should jest wysoce intelektualna i dotyczy
programowania tak jak słoma jest związana w piwem.
W ogolności uważam, że testerom głowach słoma zaczyna zastępować mózg.
No i sukces rubigo polega, na tym, ze mozna dodawac metody do klasy,
ciekawe czy do sekcji prywatnej również, bo prelegent jest specjalistą
od macania prywatnej słomy.
Pozdrawiam,
Seweryn Habdank-Wojewodzki.
Sebastian Kaliszewski
>> "Beyond Test Driven Development: Behaviour Driven Development
>> "http://www.youtube.com/watch?v=oOFfHzrIDPk
>
> Super pogadanka.
ROTFL!
Dawno się tak nie uśmiałem. I jednocześnie podziwiam, że miałeś energię
podziwiać toto w całości.
Ale tak poważniej, bo tę grupę czytają nie tylko stare konie (jak my),
ale i programistyczna młodzież, to warto w ogóle przypomnieć, do czego
służą testy jednostkowe (unit tests dla nie znających polskiej
terminologii) w sesnownie prowadzonym projekcie.
Otóż:
1. Testy jednostkowe to tylko (niewielki) kawałek weryfikacji
poprawności systemu.
2. Testy jednostkowe mają przede wszystkim wyłapywać proste błędy
popełniane podczas rozwoju oprogramowania. Stanowią zwykle jedną z
pierwszych linii weryfikacji i pierwszą linię testowania -- jak coś nie
przechodzi testów jednostkowych, to poza szczególnie uzasadnionymi
przypadkami*), od razu idzie do poprawek bez dalszej zabawy.
2a. W językach dynamicznych są szczególnie istotne, bo translachja
(kompilacja) kodu wcale lub w niewielkim stopniu weryfikuje poprawność
(typo)logiczną.
2b. W wielu zespołach kod przed oddaniem do repozytorium (lub przed
oddaniem do buildu testowego) musi przejść
3. Jak ktoś uważa, że po przejściu testów jednostkowych nietrywialny
program można uznać za poprawny, to ten ktoś jest Mądry Inaczej(tm)
*) W niektórych, podkreślam, niektórych, przypadkach stosuje się
przypadki testowe dla wykrywania konkretnych błędów, które nie są
krytyczne -- duże pakiety (choćby GCC) mają listę known bugs w chwili
ich wypuszczania -- zwykle są na te błedy testy i te testy oczywiście
nie przechodzą.
pzdr
\SK
Seweryn Habdank-Wojewodzki
> Dawno się tak nie uśmiałem. I jednocześnie podziwiam, że miałeś energię
> podziwiać toto w całości.
Wprawiam się w certyfikatach UL na oku mam SIL.
To takie testy z półki nie tyle x.should.be.(5) ale czy,
np. sprzęt jest, np. ognioodporny.
W ogóle z punktu widzenia takich standarów testy x.should.be.(5)
sa smieszne. Testujac czy sprzet jest ognioodporny podpalamy go,
a nie sprawdzamy, czy sam sie nie zapalił się w 25 stopniach :-).
Ciekawi mnie jak prelegent testuje funkcje w jezyku dynamicznym, kiedy
na wejscie podaje obiekty trojany (api podobne funkcjonalność inna),
obiekty nie pasujace. W statycznie typowanych jezykach jest troche
mniejszy klopot, bo zakres hipisowskiej fantazji jest ograniczony i szybko
kompilator weryfikuje palenie marychy w pracy.
Ale w dynamicznych panuje luzik
def fun(x,...)
Kto mi poda kompletny zestaw testow wykazujacy, że taka funkcja
na 100% działa poprawnie i rzuca wyjatki we wszytkich dziwnych sytuacjach?
> Ale tak poważniej, bo tę grupę czytają nie tylko stare konie (jak my),
> ale i programistyczna młodzież,
A co masz przeciwko Amateur Driven Development?
> 1. Testy jednostkowe to tylko (niewielki) kawałek weryfikacji
> poprawności systemu.
No cóz niektorzy uznaja dwa stonie programowania.
Pierwszy jest Pure Development, potem jest TDD (BDD).
Jak to zawiedzie to jest SHDD (Shit Happens Driven Development).
Kiedyś - w dawnych czasach - pisania istniało pojęcie
Impact Programming i Shotgun Debugging.
Dziś many te nowe DD, więc proponuję odkurzyć stare nazwy
oprawić w nową ramę, czyli mamy
Impact & Shotgun Driven Development.
W ogole dla mnie unit testy sprowadzone do rangi kontroli czy
dla poprawnego argumentu mam poprawny wynik jest niekompletne.
Zawsze chciałbym wiedzieć przykłady kiedy jakiś kawalek kodu
ale zachowujacy enkapsulacje mozna podac probie ognia.
Jesli poprawnie zareaguje (np. rzuci wyjatek) to dobrze, jesli nie,
to co?
> 2. Testy jednostkowe mają przede wszystkim wyłapywać proste błędy
> popełniane podczas rozwoju oprogramowania. Stanowią zwykle jedną z
> pierwszych linii weryfikacji i pierwszą linię testowania -- jak coś nie
> przechodzi testów jednostkowych, to poza szczególnie uzasadnionymi
> przypadkami*), od razu idzie do poprawek bez dalszej zabawy.
Dla niektorych to jest koniec. Ciekawi mnie czemu BDD nie
wskazuje na testy (jak sprawdzac) Race Conditions?
Czyzby ta neo-tehnologia nie qmała wątków, czy nie dorosla do wyzszej
abstrakcji? Czy jak juz ustalilismy odkrywa kolo na nowo?
> 2a. W językach dynamicznych są szczególnie istotne, bo translachja
> (kompilacja) kodu wcale lub w niewielkim stopniu weryfikuje poprawność
> (typo)logiczną.
Eee... nie potrzebnie utrudniasz życie ;-).
> 2b. W wielu zespołach kod przed oddaniem do repozytorium (lub przed
> oddaniem do buildu testowego) musi przejść
> 3. Jak ktoś uważa, że po przejściu testów jednostkowych nietrywialny
> program można uznać za poprawny, to ten ktoś jest Mądry Inaczej(tm)
A moze jest BDD?
Pozdrawiam,
Seweryn Habdank-Wojewodzki.
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Jaroslaw Zabiello
<s.bez...@remove.that.informa.and.that.pl> napisał(a):
> Testy jednostkowe to tylko (niewielki) kawałek weryfikacji poprawności
> systemu.
A co się wg ciebie składa na pozostały, ów *wielki* kawałek weryfikowania
poprawności oprogramowania?
Radomir 'The Sheep' Dopieralski
Seweryn Habdank-Wojewodzki wrote:
> Ciekawi mnie jak prelegent testuje funkcje w jezyku dynamicznym, kiedy
> na wejscie podaje obiekty trojany (api podobne funkcjonalność inna),
> obiekty nie pasujace. W statycznie typowanych jezykach jest troche
> mniejszy klopot, bo zakres hipisowskiej fantazji jest ograniczony i szybko
> kompilator weryfikuje palenie marychy w pracy.
>
> Ale w dynamicznych panuje luzik
>
> def fun(x,...)
>
> Kto mi poda kompletny zestaw testow wykazujacy, że taka funkcja
> na 100% działa poprawnie i rzuca wyjatki we wszytkich dziwnych sytuacjach?
Widze, ze kolega z tych, co to pisza kazda funkcje i metode zaczynajac od
dwoch stron asserotw z isinstance i tym podobnymi. Coz, kazdy ma swoje
preferecje, ale w tym przypadku polecilbym koledze Jave.
Ja tam wole jednak pisac kod zakladajac, ze osoby modyfikujace go maja
jednak jakies minimalne pojecie o tym co robia. Jak nie maja, to i tak
zadne testy nie pomoga.
Przy okazji, ta wymiana zdan nie wnosi juz nic nowego od dluzszego
czasu, poza stroszeniem pior i pokazywaniem jakimi koderami jestescie
(i niestety, w nie najlepszym swietle), wiec moze juz pora ukrecic
temu glowe?
Jaroslaw Zabiello
napisał(a):
>> "Beyond Test Driven Development: Behaviour Driven Development
>> "http://www.youtube.com/watch?v=oOFfHzrIDPk
>
> Super pogadanka. Dowiedziałem się, że prelegent napisał książkę o TDD.
> Za chwilę dowiedziałem się, że TDD to "Bullshit", czyli jego książka
> jako podzbiór TDD również.
Masz jakieś problemy z logiką. Książka może być przecież, dobrym,
kompetentnym opisem gównianej metodologii.
> bo zamiast koncentrować się na meritum sprawy, trzeba wiedzieć
> że I.should.use.the.framework (framework_1).
Albo tego w ogóle nie przesłuchałeś tego tekstu, albo masz ciężki problem
z umiejętnością słuchania ze zrozumieniem, albo jesteś tak uprzedzony, że
nic ci nie pomoże.
Po pierwsze, składnia DSL'a używanego w BDD jest drugorzędna. BDD można
uprawiać nawet za pomocą klasycznych assertów (vide Shoulda). Więc się nie
błaźnij.
Po drugie, zasadnicza różnica między TDD a BDD dotyczy metodologii,
określenia tego co właściwie ma być testowane. No bo jak ktoś sam nie wie,
CO testuje, to nie świadczy o jego mądrości. Czym jest np. owa "jednostka"
w "testowaniu jednostkowym"? Kawałkiem klasy, funkcji, skryptu? Wszystkim
i niczym? TDD testuje jakieś fragmenty kodu. BDD proponuje natomiast aby
testować to, czy aplikacja nasze względem niej oczekiwania. Testera nie
powinno obchodzić, czy dany algorytm działa tak czy inaczej. Powinno go
tylko obchodzić to, czy kod realizuje pokładane w nim oczekiwania. BDD
nazywa specyfikacjami (specs). No dobrze. Ktoś powie, że asserty to też
takie same oczekiwania jak te should w RSpec tylko, że wyrażone inną
składnią. Otóż podobieństwo znika, gdy sięgnie się po historie
użytkownika, User Stories. Stały się one podstawą do rozwiniętej części
BDD jako Story Driven Development. W SDD definiuje się listę oczekiwań
wobec aplikacji. Oczekiwania są wyrażane w formie scenariuszy a
scenariusze mogą być gromadzone razem w historie. Innymi słowy, w SDD
testuję to, czy aplikacja spełnia moję, określone oczekiwania. Proste i
logiczne. I także łatwe do wyjaśnienia dla osób nietechnicznych. DSL
używany w RSpec w tym wypadku wygląda tak:
Story: Krótki opis tego co będziemy sprawdzać
As ...
I want to ...
So that ...
Scenario: krótki opis pierwszego scenariusza
Given ...
When ...
Then ...
Scenario: tytuł drugiego scenariusza
Given ...
When ...
Then ...
To, co wpiszemy jako tytuł historii i scenariusza jest zupełnie dowolne,
byle było krótkie i opisowe. Treść szablonu "As, I want to, So that" nie
będzie przetwarzana, więc w zasadzie jest też dowolna. To, co w tym
najciekawsze i czego nie uświadczysz w TDD, to możliwość wielokrotnego
wykorzystania tych samych części zdań.
Aby trochę otworzyć zasklepione umysły (u co niektórych), podam może
konkretny przykład jak wygląda kod takich testów w praktyce. Załóżmy, że
chcę sprawdzić czy działa mi formularz kontaktowy. Na początek stworzę 3
proste scenariusze.
Story: Contact via form
As a potential customer
I want to send a message
So that I could know the message was delivered
Scenario: Send required fields without email
Given 'name' field as 'Joe Doe'
And 'subject' field as 'Feedback'
And 'message' field as 'Hello!'
When I send the form
Then I should see 'thanx'
And fields should be saved in the database
Scenario: Send required fields with invalid email
Given 'name' field as 'Joe Doe'
And 'subject' field as 'Feedback'
And 'message' field as 'Hello!'
And 'email' field as 'joe.doe@gmail'
When I send the form
Then I should see 'invalid email'
Scenario: Send missing fields
Given missing 'name' field
Or missing 'subject' field
Or missing 'message' field
When I send the form
Then I should see 'missing name or subject or message'
Główny kod który przemieli te scenarusze (tu dla Rails) będzie wyglądał
mniej więcej tak:
steps_for(:contact) do
Given "'$what' field as '$value'" do |what, value|
@fields = {} unless @fields
@fields[what] = value
end
Given "missing '$what' field" do |what|
@fields = {} unless @fields
@fields[what] = ""
end
When "I send the form" do
post "/contact", :contact => @fields
end
Then "I should see '$text'" do |text|
flash[:notice].should == text
end
Then "fields should be saved in the database" do
Contact.create @fields
end
end
Oczywiście pomijam tu szczegóły dotyczące kodu szablonu HTML formularza
itp. bo nie chcę się bardziej rozpisywać. Dokładniejszy opis będzie mojej
książce.
Seweryn Habdank-Wojewodzki
Radomir 'The Sheep' Dopieralski <ne...@sheep.art.pl> napisał(a):
> Widze, ze kolega z tych, co to pisza kazda funkcje i metode zaczynajac od
> dwoch stron asserotw z isinstance i tym podobnymi. Coz, kazdy ma swoje
> preferecje, ale w tym przypadku polecilbym koledze Jave.
Na to liczyłem :-).
> Ja tam wole jednak pisac kod zakladajac, ze osoby modyfikujace
Kod się pisze nie pod osoby modyfikujące, ale pod kogoś kto to uzywa.
Do tej pory sprawdzała się zasada, że user/koder korzystający z Twojego kodu
nie czyta instukcji do pierszego exception. User/koder charakteryzuje się
jakąś odmianą pewności siebie, że jak widzi fun (x) to już wszystko wie.
Tak więc nie widzę uzasadnienia dla zasady ufności userowi.
Hasła na serwery tez nie masz, bo ufasz innym userom?
Nie używasz transmisji szyfrowanych?
Karte w kodami do operacji bankowych i haslo tez masz przyklejone
do dowodu osobistego, bo jak ktoś znajdzie dowod to sobie
sam odbierze znaleźne :-).
> go maja
> jednak jakies minimalne pojecie o tym co robia. Jak nie maja, to i tak
> zadne testy nie pomoga.
Właśnie o to chodzi, aby testy wykazały luki. One nie są po to, aby
były one są po to, aby wykazać, że program działa oraz co ważniejsze
jest odporny na błędy wejścia. Jak w polu edycyjnym gdzie ma być wartość
liczbowa wpisze wyraz, to co? Program jak ma się zachować?
To właśnie ma sprawdzić test.
> Przy okazji, ta wymiana zdan nie wnosi juz nic nowego od dluzszego
> czasu, poza stroszeniem pior i pokazywaniem jakimi koderami jestescie
Koderami nie koderami. Nie widze sensu mydlic oczu BDD kiedy to nic nie
wnosi. Potem grupa entuzjastow przyjdzie do "wladzy" i wszyscy będą BDD,
chociaż to będzie "TDD done right". Od tych nowości łeb boli, a manago
zamiast zajmować się zarzadzaniem podkręcani są tym, czy w ich firmie
realizowane jest 30, 50 czy 80% pustosłowia zakończonego na DD.
> (i niestety, w nie najlepszym swietle), wiec moze juz pora ukrecic
> temu glowe?
Zapewne trzeba, chociaż nie rozumiem, czemu krytyka jest "nie najlepszym
światłem". Jeśli każde pusto słowie rozdmuchamy do Driven Development,
każdy kawałek kodu lub pomysł na poranną kawę nazwiemy technologią, to cóż te
słowa będą znaczyć?
Używasz technologii print czy write?
Pozdrawiam,
Seweryn Habdank-Wojewódzki
Seweryn Habdank-Wojewodzki
Jaroslaw Zabiello <hipert...@gmail.com> napisał(a):
> Masz jakie� problemy z logik�. Ksi�şka moşe by� przecieş, dobrym,
> kompetentnym opisem gĂłwnianej metodologii.
Kompletnym opisem to i może, ale "gowno" nigdy nie jest dobre,
chyba, że ktoś ma problemy z kubkami smakowymi.
> z umiej�tno�ci� s�uchania ze zrozumieniem, albo jeste� tak uprzedzony, şe
Tak. Jestem uprzedzony to "technologii" i do "driven development",
które nic nie wnoszą nowego. A tylko mydlą manago w głowach.
> nic ci nie pomoĹźe.
Może.
> Po pierwsze, sk�adnia DSL'a uşywanego w BDD jest drugorz�dna. BDD
Odniosłem wrażenie, że to jest takie c00l, że można pisać "should"
a nie assert? Nawet tam jest taki slajd, jak z ghostbusters:
"assertions" i znaczek zakazu.
> Po drugie, zasadnicza róşnica mi�dzy TDD a BDD dotyczy metodologii,
NIE PRAWDA. Facio nawet sam mowi, że BDD to "TDD done right". Nie wciskaj
mi ciemnoty, bo nie ma tam nic lepszego niż w TDD. Tak naprawdę, to tez nie
lubie okreslenia TDD, bo DD powinni skreślić.
Kiedy w samochodzi jest za dużo kierowców, to samochód źle jedzie -
każdy ma jakieś swoje ale.
> TDD testuje jakie� fragmenty kodu. BDD proponuje natomiast aby
> testowa� to, czy aplikacja nasze wzgl�dem niej oczekiwania.
Hmmm... człowieku facio pokazał x.should.be(5), to jest cała aplikacja?
Ty chyba nie widziałeś aplikacji po za:
10 print Hello
20 goto 10.
Z tego BDD nie wynikała żadna metodologia testowania aplikacji.
Facio pluł na asserty zastępując jest przegadamym syntactic sugar.
> tylko obchodzi� to, czy kod realizuje pok�adane w nim oczekiwania.
No więc jego aplikacje sprowadzają się do x.should.be(5).
Moje nie i dlatego nie widzę, aby BDD cokolwiek nowego wnosiło.
NIC. KOMPLETNIE NIC. Nawet nie podał żadnej dyscypliny,
którą się wymaga od usera kiedy należy sformułować specyfikację,
tgz. System requirements & Software requirements.
> BDD
> nazywa specyfikacjami (specs). No dobrze.
Ale to nie jest żadna specyfikacja.
Specyfikacja klienta dla mnie wygląda tak:
Mamy x kategorii przedmiotow i dla każdej kategorii
jest podana skuteczność jakiegoś algorytmu. Koniec.
Klienta naprawdę nic nie obchodzi x.should.be(5).
Natomiast jestem skory uwierzyc, ze klienta obchodzi co
sie stanie kiedy zamiast liczby poda napis.
> takie same oczekiwania jak te should w RSpec tylko, şe wyraşone inn�
> sk�adni�. Otóş podobie�stwo znika, gdy si�gnie si� po historie
> uşytkownika, User Stories. Sta�y si� one podstaw� do rozwini�tej
> cz��ci
Hmmm... a co kiedy user nie wie co to algorytm, albo nie ma pojęcia
o pomiarach, albo kiedy 5.5 to 5 tylko inaczej.
Na pewnym poziomie user stories w ogole nie istnieją, chyba ze piszesz
tylko i wyłącznie soft do przewalania danych z okienka do bazy danych.
> BDD jako Story Driven Development.
Ale jaja. Zaraz padnę. Na początku było Behaviour Driven Development
potem nastało Story Driven Development -
to chyba dzieci mają w przedszkolu.
> W SDD definiuje si� list� oczekiwa�
> wobec aplikacji.
100 lat temu nazywało się to System Requirements czy tez Software
Requirements. Nawet książeczki z Agile piszą, że to już było znane w epoce
Waterfall.
> Oczekiwania s� wyraşane w formie scenariuszy
To tam macie teatr, czy kino?
> a
> scenariusze mog� by� gromadzone razem w historie.
Story to chyba w tym konekscie tłumaczy się na "bajka".
> Innymi s�owy, w SDD
> testuj� to, czy aplikacja spe�nia moj�, okre�lone oczekiwania.
No super. Ale to już wiedziano za króla ćwieczka. Zapytaj
starych koderów, czy oni nie sprawdzali aplikacji, czy
ona spełnia oczekiwania klienta. Musiała spełniać bo by się nie sprzedała.
> logiczne. I takşe �atwe do wyja�nienia dla osób nietechnicznych.
Hmmm... czyli co? Soft sprzedaje pani handlująca mięsem, czy jak?
Rozumiem, że SDD to jest soft dla mas, ale nie rozumiem naczym ma
polegać nie techniczna specyfikacja oprogramowania.
User story (akt 1):
Nie techniczny projektant:
- ŁE... Panie, a łokienko byś chcioł?
Juzer:
- A chcem!
Nie techniczny projektant:
- Kaj łono ma być?
Juzer:
- A tu.
(pokazał palcem na ekranie z dokładnością do 100 pixeli).
> Story: Krótki opis tego co b�dziemy sprawdza�
[...]
> Then ...
Przestałem qmać. Jak przepraszam ustalisz konstrukcję predyktora Kalmana?
> To, co wpiszemy jako tytu� historii i scenariusza jest zupe�nie dowolne,
> byle by�o krótkie i opisowe. Tre�� szablonu "As, I want to, So that" nie
> b�dzie przetwarzana, wi�c w zasadzie jest teş dowolna.
Ło panie, to lepiej nic nie pisać, bo szkoda łołówka.
> To, co w tym
> najciekawsze i czego nie u�wiadczysz w TDD, to moşliwo�� wielokrotnego
> wykorzystania tych samych cz��ci zda�.
Co Ty palisz/pijesz? Odnoszę wrażenie, że jesteś na innym Marsie
niż moje Wenus.
> Scenario: Send required fields without email
> Given 'name' field as 'Joe Doe'
> And 'subject' field as 'Feedback'
> And 'message' field as 'Hello!'
> When I send the form
> Then I should see 'thanx'
> And fields should be saved in the database
A co zrobisz kiedy juzer przynosi 1TB danych?
Kazdą daną z nim omówisz?
> Scenario: Send missing fields
> Given missing 'name' field
> Or missing 'subject' field
> Or missing 'message' field
> When I send the form
> Then I should see 'missing name or subject or message'
Rozumiem. Tak to ostatnie jest dobre. Kłopot polega na tym, że
ja tak robie bez BDD i SDD zanim znałem TDD itd.
W scenariuszach brakuje mi jeszcze miejsca na podpis i numer dowodu
juzera, bo on i tak za tydzień zapomni, że to było ustalone
i w myśl Agile.continuous.integration.with.user powie Ci, że
on chciał co innego.
Do tego rozważ też przy każdym scenariuszu postawienie ceny, bo user za 3
tygodnie wymysli 1000 nowych sytuacji i powie, że to ma być w cenie.
A za miesiąc przyprowadzi całą rodzinę i każdy opowie swoją historię.
Uznaję Defence Driven Development i wszystko muszę mieć podpisane
i wycenionie i ustalony czas wykonania.
> Oczywi�cie pomijam tu szczegó�y dotycz�ce kodu szablonu HTML
> formularza
> itp. bo nie chc� si� bardziej rozpisywa�. Dok�adniejszy opis b�dzie
> mojej ksi�şce.
Mam nadzieję, że przed wydaniem dasz ją do recenzji komuś kto nie jest
fanatykiem DD, najlepiej jakiś stary dobry koder, który wskaże Ci
jak to się kiedyś robiło.
Pozdrawiam,
Seweryn Habdank-Wojewodzki.
Jaroslaw Zabiello
<sh...@gazeta.skasuj-to.pl> napisał(a):
> Tak. Jestem uprzedzony to "technologii" i do "driven development",
[...]
>> nic ci nie pomoże.
>
> Może.
LOL! No to by było na tyle. Grunt to się zapienić i zapomnieć czym jest
merytoryczna dyskusja. Dobrego samopoczucia życzę.
PS. I ustaw ten swój kulawy czytnik newsów bo nie radzi sobie z utf8.
Jaroslaw Zabiello
<s.bez...@remove.that.informa.and.that.pl> napisał(a):
>>>>> Python + Psyco bez sortowania = 3.91
>>>>> Python + Psyco z sortowaniem = 7.97
>>>
>>>> Ja mam 64-bitowy system, a Psyco jest dostępne tylko dla 32bit.
>>>
>>> Na moim 64-bitowym systemie aplikacje 32-bit działają...
>> Aplikacje tak, Psyco - nie.
>>
>
> Psyco też działa.
Nie działa na systemach 64bitowych.
Jaroslaw Zabiello
napisał(a):
>> A Story Development to BDD ale podane w
>> inny sposob, wysokopoziomowe scenariusze zachowan, swietne do
>> bezposredniego kontaktu z klientem.
>
> Aplikacji webowych to i moze.
Dlaczego uważasz, że tylko webowych? Przecież to się świetnie nadaje do
testowania *dowolnego* kodu. Możesz sobie przygotować setki takich
scenariuszy do dowolnego kodu. Co ważniejsze, składnia tego DSL'a pozwala
na wielokrotne użycie podobnych części zdań. To bardzo skraca ilość
kodowania bez szkody dla czytelności. W sumie nic nie stoi na przeszkodzie
aby napisanop parser tych stories dla Pythona.
>> W dupie mam teoretyzowanie w tiobe. Widze w ofertach w Irlandii, ze
>> szukaja osoby znajace Rubiego a nie Pythona.
>
> O a ta Irlandia to jakis Eden?
Mowię jak jest. Akurat znam ten rynek, bo tu pracuję.
> U mnie w firmie Python jest do uzywania jako soft do pisania Tooli.Ruby
> w ogole nie jest uznawany za jakkolwiek przydatny jezyk.
Widocznie wam to niepotrzebne. U nas jest dokładnie odrotnie. Python jest
nam zupełnie nieprzydatny, bo potrzebujemy czegoś webowego dobrze
integrującego się z Javą. I tu JRuby on Rails sprawuje się całkiem dobrze.
Tak w ogóle, obserwując wypowiedzi i całe środowisko, widzę że kręgach
pythona mało się dzieje. Wygląda tak jakby tam sami emeryci siedzieli.
Mało tam inowacyjności. Wszystkie ciekawsze rzeczy jakie spotykam,
powstają w Ruby. Capistrano, RSPec, smalltalkowy MagLev, nawet Fusion
Passenger który zupełnie rewolucjonizuje sposób wdrażania aplikacji
webowych w Ruby i... Pythonie (bo dodano wsgi) powstał pierwotnie dla
Rubiego. Albo weźmy JRuby. Ma zaimplementowaną Onigurumę, całkiem potężną
maszynę wirtualną do wyrażeń regularnych i wkrótce ma mieć Joni,
najszybszy chyba w ogóle parser regexpa. Sam JRuby bije już w wielu
testach bez problemu Pythona.
Albo weźmy taką kwestię systemu szablonów dla Pythona. Tyle lat się
męczono. Poza ZPT, który jest niezłą próbą wsadzenia logiki między
znaczniki XML, nie potrafiono rozwiązać problemu ożenienia znaczących
wcięć używanych w Pythonie ze znacznikami XML/HTML. Nie, żebym
był przeciwko wcięciom (wręcz przeciwnie), jakoś trzeba było dopiero gości
od Rubiego aby wymyślili Haml'a. Haml używa znaczących wcięć do
generowania XHTML'a i nie musi posiłkować się jakimiś sztucznymi DSL'ami
tak, jak Django czy Cheetah. Jakieś tam endfor, endif, które nie istnieją
w Pythonie... Po co, skoro można prościej?
Nie, żebym chciał udowadniać wyższość Rubiego nad Pythonem. Myślę, że
problemem jest środowisko. Zatęchłe, bufoniaste, nieskore do jakiejkolwiek
nauki, nieświadomie kopiące grób dla potencjalnych miłośników Pythona. A
wystarczy trochę otwartości, ciekawości i oba języki mogą odnieść dużo
korzyści. Bo w obu jest wiele ciekawych projektów. Chyba Ruby ma
społeczność ogólnie młodszą, a na pewno pełną entuzjazmu.
Jaroslaw Zabiello
<s.bez...@remove.that.informa.and.that.pl> napisał(a):
>> Polecam uzupelnic braki.
>
> Polecam nie podniecać zbytnio się nowymi pomysłami dzieciaków dla
> dzieciaków.
Niby dlaczego dzieciaków? Ten autor książki o TDD to dzieciak? To ty chyba
stoisz nad grobem już. Rozumiem że lepiej w ogóle niczym się nie
podniecać, bo jeszcze serce nie wytrzyma. Nie ma to jak grono emerytów.
> Test jednostkowy ma pomóc w weryfikacji poprawności konkretnego
> zamkniętego fragmentu.
A ile tego kodu wystarczy aby był jednostką? Masz jakiegoś RCov'a który ci
automatycznie wyświetli stopień pokrycia kodu testami?
> Kolego. Jednostki są właśnie dobrze określone. Oczekiwania to jest
> właśnie mętne bez sensu.
Co ty pieprzysz za głupoty? Przecież specyfikacje i stories są bardzo
dobrze określone funkcjonalnie. I dużo bardziej naturalnie. W wypadku
stories, traktujesz kod jak black-box. Z pkt. widzenia testów, w dupie mam
to co jest w środku. Chcę aby ta czarna skrzynka dla zadanych wartości
wypluwała oczekiwane rezultaty. Zgrupowanie tego w scenariusze pozwala
dzięki DSL'owi RSpec'a pozwala na (1) WIELOKROTNE wykorzystanie całych
fragmentów zdań różniących się wartością rzeczowników, (2) scenariusze
RSpec'a poprawiają czytelność tego, co jest sprawdzane.
>> A Story Development to BDD ale podane w inny sposob, wysokopoziomowe
>> scenariusze zachowan, swietne do bezposredniego kontaktu z klientem.
>
> Kolego, scenariusze zachowań to są znane od pół wieku.
Co mi tu kolega za pierdoły wciska. Pół wieku? Gdzie? Chyba na papierze
pisane gęsim piórem. Podaj mi jakikolwiek framework podobny do RSpec
istniejący od pół wieku. Jakieś konkretne biblioteki poproszę.
>>> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
>> W dupie mam teoretyzowanie w tiobe.
>
> W dupie mam pomiary, wolę machać rękami. "I nikt mi nie wmówi że białe
> jest białe a czarne czarne..."
Tak naprawdę to wszystko jest gówno warte. Co z tego, że jest nawet trochę
ofert Pythona skoro 95% z nich to oferty dla adminów Linuksa, co mnie w
ogóle nie interesuje? W mojej działce, gdzie nie spojrzę w UK i Irlandii
widzę więcej ofert dla Rubiego, niż Pythona. Wcześniej aż tak nie było. To
się zmieniło. I można znaleźć dobre oferty, nawet takie, co przewyższają
płace javowców.
> Ach tak więc przeprowadziłeś badania na "szeroką" skalę
To nie są żadne badania. To po prostu fakt. Znasz podobny przypadek że
odwalili Javowca bo nie znał Pythona? :)
>>> 2. Co ma mielenie bezsensownych obliczeń do odpalania frameworku
>>> webowego?
>> A odpal cokolwiek innego madralo.
>
> Jak nie masz pojęcia o testowaniu
A ty masz? To pokaż zamiast się zapluwać.
> Rozumiałbym test wydajności generowania treści, połączenia z bazą
> danych, itp. Ale to co Ty, kolego, pokazałeś jest kompletnie w trzecią
> stronę. I nawet w tym kilkulinijkowym niby-tescie nie byłeś w stanie
> stwierdzić co tak na prawdę testujesz.
Akurat nie wiedziałem że Python ma aż tak spieprzony generator losowy.
Poza tym, zbyt poważnie podchodzisz do tego co się wypisuje w prywatnych
blogach. To nie rozprawka naukowa. Celem tekstu było zwrócenie uwagi, że
coś nie gra z tą wydajnością. Nic więcej. Jak ktoś chce to niech porządnie
i dokładnie sobie napisze kilkadziesiąt stron testów z wykresami i
tabelami. Nie to było moim celem. Jak tego nie rozumiesz, to widocznie
masz ogólne problemy ze zbyt spiętym, drętwym podejściem do życia.
forgems
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=jruby&lang2=python
Seweryn Habdank-Wojewódzki
> LOL! No to by było na tyle. Grunt to się zapienić i zapomnieć czym jest
> merytoryczna dyskusja.
Merytoryczna to sie ona skonczyla jak podales link do definicji BDD
poprzez
film z hipisem w roli glownej. Podalem moje przeciw. Ty uwazasz, ze
zjadles
wszelkie rozumy, bo piszesz ksiazke. Rozumiem, ze to guru hipis cie
natchnal.
NIC kompetnie ci nie wnosi taki ciag DD.
Byl waterfall i tam byly specyfikacje. Agile troche dodalo, ale
TDD stalo sie jakby Testing (from waterfall) done right.
BDD to jest "TDD done right", SDD to jest "BDD done right", itd.
NIC nie widze czego by nie bylo, poza tym, ze masz generator
formularzy dla rubiego oparty o wywiad rodzinny z klientem.
Przepraszam jak kazdy generator kodu do kazdego znanego mi jezka
nazwe DD. To sam padniesz pod naporem generatorow kodu,
jako Code Generators Driven Development.
> PS. I ustaw ten swój kulawy czytnik newsów bo nie radzi sobie z utf8.
O jak mi milo. Ten czytnik to portal zapewne napisany w jednym z tych
super dynamicznych jezykow, ktore nie testuja sytuacji, kiedy user
zapoda cos dziwnego.
Uwagi zglaszaj do admina portalu, nie odpowiam za Shit Happens Driven
Development.
Pozdrawiam,
Seweryn Habdank-Wojewodzki.
Seweryn Habdank-Wojewódzki
> kodowania bez szkody dla czytelności. W sumie nic nie stoi na przeszkodzie
> aby napisanop parser tych stories dla Pythona.
Nie szkodzi, tylko nic mi to niedaje. Dostalem od klienta tabele, na
1/3
strony jak soft ma dzialac. Ani ja wiecej nie potrzebuje, ani on.
Wszystko inne jest do ustalenia w obrebie umowy (prawnej), ktorej nik
nie
bedzie parsowal.
> Widocznie wam to niepotrzebne. U nas jest dokładnie odrotnie. Python jest
> nam zupełnie nieprzydatny, bo potrzebujemy czegoś webowego dobrze
> integrującego się z Javą. I tu JRuby on Rails sprawuje się całkiem dobrze.
No wiec dlaczego jakies wynurzenia hipisa nagle maja sie stac Driven
Development.
Podkreslam, wszystko odnosze do tego filmu. Idee specyfikacji juz
dawno
byly znane. Popytaj sprzetowcow, co sadza o Storiesach.
> Wygląda tak jakby tam sami emeryci siedzieli.
Jeszcze pracuje.
> Mało tam inowacyjności.
Znaczy patrzysz na lepfrejmlorki, czy na innowacyjnosc w okolo
Pythonowa.
Ja pracuje ze SciPy i nie narzekam na brak innowacyjnosci.
> Wszystkie ciekawsze rzeczy jakie spotykam,
> powstają w Ruby. Capistrano, RSPec, smalltalkowy MagLev, nawet Fusion
> Passenger który zupełnie rewolucjonizuje sposób wdrażania aplikacji
> webowych
Znowu piszesz o webie. Czyli nagle to jest jakies centrum swiata i cos
co sie
tam robi, nagle ma sie stac jakims objawieniem dla calosci?
Dlaczego jakies story mamy brac jako Driven Development skoro to
dziala
dla lebu, a nikt nie sprawdzil sluszunosci dla innych aplikacji.
> w Ruby i... Pythonie (bo dodano wsgi) powstał pierwotnie dla
> Rubiego. Albo weźmy JRuby. Ma zaimplementowaną Onigurumę, całkiem potężną
> maszynę wirtualną do wyrażeń regularnych i wkrótce ma mieć Joni,
> najszybszy chyba w ogóle parser regexpa.
To znaczy zaszyja parser regexp w VHDL-u?
> Sam JRuby bije już w wielu testach bez problemu Pythona.
Ale mnie rozsmieszyles. A co niby Python to taki High Performance.
> od Rubiego aby wymyślili Haml'a. Haml używa znaczących wcięć do
> generowania XHTML'a i nie musi posiłkować się jakimiś sztucznymi DSL'ami
> tak, jak Django czy Cheetah. Jakieś tam endfor, endif, które nie istnieją
> w Pythonie... Po co, skoro można prościej?
Znaczy co? kolejny generator kodu urosl do rangi jezyka?
> wystarczy trochę otwartości, ciekawości i oba języki mogą odnieść dużo
> korzyści. Bo w obu jest wiele ciekawych projektów. Chyba Ruby ma
> społeczność ogólnie młodszą, a na pewno pełną entuzjazmu.
Szybko sie ustabilizuja, gwarantuje. Albo pojda tylko i wylacznie w
leb
development (co w zasadzie ma juz miejsce).
Pozdrawiam,
Seweryn Habdank-Wojewodzki.
Seweryn Habdank-Wojewódzki
> Akurat nie wiedziałem że Python ma aż tak spieprzony generator losowy.
> Poza tym, zbyt poważnie podchodzisz do tego co się wypisuje w prywatnych
> blogach. To nie rozprawka naukowa. Celem tekstu było zwrócenie uwagi, że
> coś nie gra z tą wydajnością. Nic więcej. Jak ktoś chce to niech porządnie
> i dokładnie sobie napisze kilkadziesiąt stron testów z wykresami i
> tabelami. Nie to było moim celem. Jak tego nie rozumiesz, to widocznie
> masz ogólne problemy ze zbyt spiętym, drętwym podejściem do życia.
Hmm... jednak wnioski wycialgnales pochopne, o czym to swiadczy?
Pozdrawiam,
Seweryn Habdank-Wojewodzki.
chester
> Jaroslaw Zabiello <hipert...@gmail.com> napisał(a):
> Kazdą daną z nim omówisz?
Jak w każdej sytuacji - trzeba znaleźć złoty środek, a 1TB danych to
zazwyczaj n*małoKB danych, gdzie dla każdego zestawu można określić
pewien skończony i niezbyt przerośnięty zestaw reguł walidujących.
>
>> Scenario: Send missing fields
>> Given missing 'name' field
>> Or missing 'subject' field
>> Or missing 'message' field
>> When I send the form
>> Then I should see 'missing name or subject or message'
>
> Rozumiem. Tak to ostatnie jest dobre. Kłopot polega na tym, że
> ja tak robie bez BDD i SDD zanim znałem TDD itd.
>
> W scenariuszach brakuje mi jeszcze miejsca na podpis i numer dowodu
> juzera, bo on i tak za tydzień zapomni, że to było ustalone
> i w myśl Agile.continuous.integration.with.user powie Ci, że
> on chciał co innego.
A przepraszam, ale jak user omawia specyfikację, to jest ona integralną
częścią umowy, w której to umowie znajduje się wycena. Jak user powie,
że chciał coś innego, to jego problem. A jak jest całkowicie
nietechniczny lub czegoś nie zrozumiał, to generalnie jest jego problem.
Małe zmiany oczywiście się robi, bo zadowolony klient przyprowadzi
następnych, ale duże zmiany to duże koszty - klient musi mieć albo mózg,
albo dużo kasy na zachcianki.
> Do tego rozważ też przy każdym scenariuszu postawienie ceny, bo user za 3
> tygodnie wymysli 1000 nowych sytuacji i powie, że to ma być w cenie.
> A za miesiąc przyprowadzi całą rodzinę i każdy opowie swoją historię.
I jak kazdą historię zechce wprowadzić do specyfikacji, to pozostaje
tylko kwestia kasy
> Uznaję Defence Driven Development i wszystko muszę mieć podpisane
> i wycenionie i ustalony czas wykonania.
No ale co w tym dziwnego? Wiadomo przecież, że wszystkie zmiany poza
tymi naprawdę drobnymi generują koszty i jak klient za aplikację nie
płaci naprawdę dużej kwoty, to takie zmiany są osobno wyceniane.
Nie wiem, jakich macie handlowców w firmie, ale moje skromne
doświadczenie pokazuje, że im ogólniejsza specyfikacja (co jest swoją
drogą fajnym oksymoronem, póki nie jest to specyfikacja projektu, który
musisz wdrażać), tym więcej zachcianek zgłasza klient, tym bardziej
wydłuża się czas realizacji i tym mniejszy jest zysk z projektu (bo czas
to pieniądz).
Czas na tworzenie specyfikacji to też pieniądz więc trzeba znaleźć złoty
środek który uwzględni również specyfikę projektu (system płatności
raczej musi mieć bardzo szczegółową specyfikację, a blog raczej
niekoniecznie)
Błędy zawsze jakieś będą, pytanie tylko ile klient chce wydać na
zapobieganie im.
chester
szymon
pisze:
> Witam
>
> > kodowania bez szkody dla czytelności. W sumie nic nie stoi na przeszkodzie
> > aby napisanop parser tych stories dla Pythona.
>
> Nie szkodzi, tylko nic mi to niedaje. Dostalem od klienta tabele, na
> 1/3
> strony jak soft ma dzialac. Ani ja wiecej nie potrzebuje, ani on.
> Wszystko inne jest do ustalenia w obrebie umowy (prawnej), ktorej nik
> nie
> bedzie parsowal.
>
Ale i tak jakieś testy zrobisz, prawda?
> > Widocznie wam to niepotrzebne. U nas jest dokładnie odrotnie. Python jest
> > nam zupełnie nieprzydatny, bo potrzebujemy czegoś webowego dobrze
> > integrującego się z Javą. I tu JRuby on Rails sprawuje się całkiem dobrze.
>
> No wiec dlaczego jakies wynurzenia hipisa nagle maja sie stac Driven
> Development.
> Podkreslam, wszystko odnosze do tego filmu. Idee specyfikacji juz
> dawno
> byly znane. Popytaj sprzetowcow, co sadza o Storiesach.
>
A co sądzą?
Jaroslaw Zabiello
napisał(a):
> Wszystko inne jest do ustalenia w obrebie umowy (prawnej), ktorej nik
> nie bedzie parsowal.
Czyli testy też są niepotrzebne?
No i dlaczego lista stories nie może być częścią umowy tego, czego klient
oczekuje? Są one wystarczająco wysokopoziomowe aby je do tego móc użyć.
> No wiec dlaczego jakies wynurzenia hipisa nagle maja sie stac Driven
> Development.
Zazdrościsz mu fryzury czy co? :) BDD to przecież nie jego wymysł. Ten
termin już od dawna funkcjonuje. On tylko w swoich słowach przedstawił
zalety BDD i Rspec'a w stos. do TDD i UnitTest.
> Idee specyfikacji juz dawno byly znane.
Idee podróży na księżyc też były znane dużo wcześniej. Coś chciałeś
powiedzieć?
> Popytaj sprzetowcow, co sadza o Storiesach.
A co sądzą?
>> Wygląda tak jakby tam sami emeryci siedzieli.
>
> Jeszcze pracuje.
Chyba dużo się nie pomyliłem. :)
>> Mało tam inowacyjności.
>
> Znaczy patrzysz na lepfrejmlorki, czy na innowacyjnosc w okolo
> Pythonowa.
Chcesz może powiedzieć, że Python nie nadaje się do webu? Zaraz cię
djangowcy zjedzą. :) Mam wrażenie, że rozmawiam ze ślepym i głuchym.
Przecież w podanym przykładzie Capistrano nie musi być używany tylko do
webu. To samo dotyczy RSpec. Netbeans 6.5 automatycznie podczas tworzenia
projektu w Ruby (nie w Rails) dodaje folder na specs.
> Ja pracuje ze SciPy i nie narzekam na brak innowacyjnosci.
Nie chodzi o narzekanie. Chodzi ogólnie o nowe pomysły. Akurat ja mam na
celowniku aplikacje webowe i muszę przyznać, że tu jestem rozczarowany
tym, co się dzieje w Pythonie. Generalnie jest jakiś zastój. Nie wspomnę o
kompletnie beznadziejnym marketingu i braku wyczucia aby cokolwiek
wypromować. To jakiś ogólny problem w tych kręgach. Pythonowe community
jest dużo bardziej konserwatywne i zachowawcze, żeby nie powiedzieć -
drętwe.
> Znowu piszesz o webie.
Smalltalk wg ciebie to też technologia czysto webowa, co? Lepiej byś się
zapoznał z terminami zamiast pleść bzdury. MagLev to smaltalkowy GemStone
dla Rubiego. Szybka maszyna wirtualna z przezroczystym, bardzo wydajnym
odpowiednikiem obiektowej bazy danych. BTW, Capistrano, mimo, że napisany
w Rubim, może być używany do dowolnej technologii (Python, PHP, Java,
cokolwiek) i do automatyzowania wszelkich skryptów. Jedynym warunkiem jest
dostęp do SSH na serwerach docelowych.
> Dlaczego jakies story mamy brac jako Driven Development skoro to
> dziala dla lebu, a nikt nie sprawdzil sluszunosci dla innych aplikacji.
To przecież działa do wszelkiego kodu. RSpec staje się głównym
frameworkiem do testowania różnych bibliotek Rubiego.
>> wkrótce ma mieć Joni, najszybszy chyba w ogóle parser regexpa.
>
> To znaczy zaszyja parser regexp w VHDL-u?
Nie znam za dużo szczegółów implementacyjnych. Musiałby się tu
wypowiedzieć Marcin Mielżyński, który portował Onigurumę i teraz zajmuje
się Joni.
>> Sam JRuby bije już w wielu testach bez problemu Pythona.
>
> Ale mnie rozsmieszyles. A co niby Python to taki High Performance.
No wiadomo, że nie. Ale padają stare argumenty o rzekomo dużo większej
wydajności Pythona w stos. do Rubiego.
>> od Rubiego aby wymyślili Haml'a. Haml używa znaczących wcięć do
>> generowania XHTML'a i nie musi posiłkować się jakimiś sztucznymi
>> DSL'ami tak, jak Django czy Cheetah.
>
> Znaczy co? kolejny generator kodu urosl do rangi jezyka?
Taki sam jak Cheetah czy Django templates, tylko bardzie pythonic. Haml ma
dużo prostsze reguły niż te pythonowe DSL'e. Anyway, chodzi o sam fakt, że
to nie pythonowcy, rubiści wpadli na takie "pythonowe" rozwiązanie.
Sebastian Kaliszewski
>>> Polecam uzupelnic braki.
>>
>> Polecam nie podniecać zbytnio się nowymi pomysłami dzieciaków dla
>> dzieciaków.
>
> Niby dlaczego dzieciaków? Ten autor książki o TDD to dzieciak?
Ten pierwszy to dzieciak, ten drugi to typowy zapchajdziura
konferencyjny. Po odolaniu wody pozostają truizmy, rzeczy znane od
dawien dawna z domieszką bzdur.
> To ty
> chyba stoisz nad grobem już. Rozumiem że lepiej w ogóle niczym się nie
> podniecać, bo jeszcze serce nie wytrzyma. Nie ma to jak grono emerytów.
>
>> Test jednostkowy ma pomóc w weryfikacji poprawności konkretnego
>> zamkniętego fragmentu.
>
> A ile tego kodu wystarczy aby był jednostką? Masz jakiegoś RCov'a który
> ci automatycznie wyświetli stopień pokrycia kodu testami?
Ależ oczywiście, że takie rzeczy są. Zapuszczenie jakiegokolwiek
coverage tool podczas testów da mi pokrycie kodu (zarówno instrukcji jak
i ścieżek).
Tylko, kolego, jak już napisałem gdzie indziej, testy jednostkowe służą
do określonego celu -- wstępnej weryfikacji, że kod generalnie działa.
Bo poza testami jednostkowymi robi się testy integracyjne, testy
funkcjonalne, testy wydajnościowe i obciążeniowe testy użyteczności,
testy procedur awaryjnych, itd...
>> Kolego. Jednostki są właśnie dobrze określone. Oczekiwania to jest
>> właśnie mętne bez sensu.
>
> Co ty pieprzysz za głupoty?
Kolego, czy ty widziałeś kiedyś (od środka) jakiś poważniejszy system --
czy tylko kolejny sklep internetowy?
> Przecież specyfikacje i stories są bardzo
> dobrze określone funkcjonalnie.
Masło maślane. Specyfikacja funkcjonalna jest dobrze określona
funkcjonalnie...
> I dużo bardziej naturalnie. W wypadku
> stories, traktujesz kod jak black-box. Z pkt. widzenia testów, w dupie
> mam to co jest w środku.
Kolego, takie rzeczy to wiedziano pół wieku temu.
> Chcę aby ta czarna skrzynka dla zadanych
> wartości wypluwała oczekiwane rezultaty. Zgrupowanie tego w scenariusze
> pozwala dzięki DSL'owi RSpec'a pozwala na (1) WIELOKROTNE wykorzystanie
> całych fragmentów zdań różniących się wartością rzeczowników,
Co to jest wartość rzeczowników? Skończ, kolego inżynierze, z nowomową.
Jak skończysz, to poczytaj sobie trochę o historii swojej własnej
dziedziny. Zorientujesz się wtedy, że twoje nowości to mają po 30 albo
50 lat.
> (2)
> scenariusze RSpec'a poprawiają czytelność tego, co jest sprawdzane.
Guzik z pętelką. To jest mocno ograniczone narzędzie, do prostych testów
prostych produktów jednojęzycznych.
W przypadku bardziej złożonej specyfikacji ten cały przegadany syntax
nic nie wnosi (to tak jakby się kłócić o składnię nagłówków funkcji)
A w czytelności i zrozumiałości dla klienta to jest i tak bardzo słabe.
Przeciętny klient woli sobie nagrać scenariusz np. aplikacji webowej
klikacjąc w sajt i oznaczając które wartości mogą się zmieniać, a które nie.
>>> A Story Development to BDD ale podane w inny sposob, wysokopoziomowe
>>> scenariusze zachowan, swietne do bezposredniego kontaktu z klientem.
>>
>> Kolego, scenariusze zachowań to są znane od pół wieku.
>
> Co mi tu kolega za pierdoły wciska. Pół wieku? Gdzie? Chyba na papierze
> pisane gęsim piórem.
Ty, kolego, jesteś inżynierem?
> Podaj mi jakikolwiek framework podobny do RSpec
> istniejący od pół wieku. Jakieś konkretne biblioteki poproszę.
Kolego, nie epatuj swoją niewiedzą. Testy, kolego, robiło się od dawna
nie biblioteką podobną do RSpec, tylko narzędziami do testów,
dostosowanymi do dziedziny. Dużo lepiej dostosowanymi. Popatrz sobie np
na produkty firmy Rational.
Tyś jest, kolego, poza, oczywiście, ewangelizowaniem ta temat nowomody,
zdaje się programistą od webów różnych. Otóż, kolego, do takich testów
to są od dawna znane wygodne narzędzia, które potrafią wykonać
scenariusze w banalny sposób do nich wklikane (nie spodziewaj się, że
pani Basia, która zna się na bankowości a nie na programowaniu będzie
tworzyła testy w jakimś RSpecu). Pani Basia może bardzo ładnie opisać
scenariusz testujący to co ją interesuje, i może go albo wklikać sama
albo dać koderowi do wklepania w jakimś RSpecu. Tyle, że to pierwsze
wychodzi taniej i pania Basia ma gwarancję że testowane jest to co ona
sama wklikałą a nie to co koder zrozumiał z tego co ona napisała.
>>>> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
>>> W dupie mam teoretyzowanie w tiobe.
>>
>> W dupie mam pomiary, wolę machać rękami. "I nikt mi nie wmówi że białe
>> jest białe a czarne czarne..."
>
> Tak naprawdę to wszystko jest gówno warte. Co z tego, że jest nawet
> trochę ofert Pythona skoro 95% z nich to oferty dla adminów Linuksa, co
> mnie w ogóle nie interesuje? W mojej działce, gdzie nie spojrzę w UK i
> Irlandii widzę więcej ofert dla Rubiego, niż Pythona. Wcześniej aż tak
> nie było. To się zmieniło. I można znaleźć dobre oferty, nawet takie, co
> przewyższają płace javowców.
Och, ach. Przewyższają płace najgorzej opłacanej grupy programistów.
>> Ach tak więc przeprowadziłeś badania na "szeroką" skalę
>
> To nie są żadne badania. To po prostu fakt. Znasz podobny przypadek że
> odwalili Javowca bo nie znał Pythona? :)
LOL! Znam firmę gdzie Javę w ogóle uznano za niewiele wartą (i
słusznie). Powiem ci, kolego, w sekrecie, że Rubiego też nikt tam nie
stosuje.
>>>> 2. Co ma mielenie bezsensownych obliczeń do odpalania frameworku
>>>> webowego?
>>> A odpal cokolwiek innego madralo.
>>
>> Jak nie masz pojęcia o testowaniu
>
> A ty masz? To pokaż zamiast się zapluwać.
Popatrz sobie kolego na jakiekolwiek poważne benchmarki przemysłowe.
Wtedy zobaczysz jak to się robi.
Zresztą napisałem (i jak byk stoi poniżej) co należałoby sprawdzać,
nawet w takim niepoważnym, prościutkim tescie na "prywatnego bloga".
>> Rozumiałbym test wydajności generowania treści, połączenia z bazą
>> danych, itp. Ale to co Ty, kolego, pokazałeś jest kompletnie w trzecią
>> stronę. I nawet w tym kilkulinijkowym niby-tescie nie byłeś w stanie
>> stwierdzić co tak na prawdę testujesz.
>
> Akurat nie wiedziałem że Python ma aż tak spieprzony generator losowy.
Przestań się ośmieszać, inżynierze.
Python ma generator, który jest uznawany za dobry. A nie jakiś badziew
typu linear congruence, który nie przechodzi najprostszych testów
statystycznych.
Zamiast bajać bez sensu, pogooglaj sobie na Mersenne Twister (i na
ISAAC). Poczytaj sobie o tym, co to jest funneling w generatorach
pseudolosowych, przeczytaj o testach statystycznych, itp.
> Poza tym, zbyt poważnie podchodzisz do tego co się wypisuje w prywatnych
> blogach. To nie rozprawka naukowa.
Od inżyniera należy oczekiwać pewnego minimalnego poziomu zrozumienia
rzeczy z jego własnej dziedziny.
> Celem tekstu było zwrócenie uwagi, że
> coś nie gra z tą wydajnością. Nic więcej. Jak ktoś chce to niech
> porządnie i dokładnie sobie napisze kilkadziesiąt stron testów z
> wykresami i tabelami. Nie to było moim celem. Jak tego nie rozumiesz, to
> widocznie masz ogólne problemy ze zbyt spiętym, drętwym podejściem do
> życia.
Test pokazał co najwyżej, że autor nie wie co testuje ani w ogóle jak
wydajność testować.
Co do spiętego podejścia, to nie ja zacząłem używać słownictwa na g. i
d. Cóż, kolego, ja rozumiem, że to boli, gdy ktoś panu magistrowi
inżynierowi z listą referencji niemieszczącą się na ekranie wykazuje, że
pan inżynier nie wie o czym pisze.
Sebastian Kaliszewski
> <s.bez...@remove.that.informa.and.that.pl> napisał(a):
>
>> Testy jednostkowe to tylko (niewielki) kawałek weryfikacji poprawności
>> systemu.
>
> A co się wg ciebie składa na pozostały, ów *wielki* kawałek
> weryfikowania poprawności oprogramowania?
>
Weryfikacja formalna (w systemach krytycznych to się robi)
Automatyczna kontrola źródeł (wszelkie *linty, itp.)
Przeglądy kodu
Testy integracyjne
Testy funkcjonalne
Testy odporności na awarie
Testy użyteczności
Testy obciążeniowe
Testy wydajności (to nie to samo co obciążeniowe)
itd...
pzdr
Sebastian Kaliszewski
> Dnia 11-08-2008 o 14:57:29 Seweryn Habdank-Wojewódzki
> <hab...@gmail.com> napisał(a):
>
>>> A Story Development to BDD ale podane w
>>> inny sposob, wysokopoziomowe scenariusze zachowan, swietne do
>>> bezposredniego kontaktu z klientem.
>>
>> Aplikacji webowych to i moze.
>
> Dlaczego uważasz, że tylko webowych? Przecież to się świetnie nadaje do
> testowania *dowolnego* kodu.
To się jakoś tam nadaje do prostych testów jednostkowych. Do testów
funkcjonalnych dla weba lepsze są roboty, gdzie test się tworzy
nagrywając interakcję użytkownika. Do testów gdzie specyfikacja nie jest
trywialna stosuje się formalizm w którym ta specyfikacja może być
wygodnie wyrażona -- pseudo angielskawe zdania są tu kiepskie.
> Możesz sobie przygotować setki takich
> scenariuszy do dowolnego kodu. Co ważniejsze, składnia tego DSL'a
> pozwala na wielokrotne użycie podobnych części zdań. To bardzo skraca
> ilość kodowania bez szkody dla czytelności. W sumie nic nie stoi na
> przeszkodzie aby napisanop parser tych stories dla Pythona.
Tylko po co?
>>> W dupie mam teoretyzowanie w tiobe. Widze w ofertach w Irlandii, ze
>>> szukaja osoby znajace Rubiego a nie Pythona.
>>
>> O a ta Irlandia to jakis Eden?
>
> Mowię jak jest. Akurat znam ten rynek, bo tu pracuję.
>
>> U mnie w firmie Python jest do uzywania jako soft do pisania
>> Tooli.Ruby w ogole nie jest uznawany za jakkolwiek przydatny jezyk.
>
> Widocznie wam to niepotrzebne. U nas jest dokładnie odrotnie. Python
> jest nam zupełnie nieprzydatny, bo potrzebujemy czegoś webowego dobrze
> integrującego się z Javą. I tu JRuby on Rails sprawuje się całkiem dobrze.
>
> Tak w ogóle, obserwując wypowiedzi i całe środowisko, widzę że kręgach
> pythona mało się dzieje.
ROTFL!
Wysraczy popatrzeć na takie PyPy.
> Wygląda tak jakby tam sami emeryci siedzieli.
> Mało tam inowacyjności. Wszystkie ciekawsze rzeczy jakie spotykam,
> powstają w Ruby. Capistrano, RSPec, smalltalkowy MagLev,
To są sexy nowomodne bajery, które mało wnoszą.
> nawet Fusion
> Passenger który zupełnie rewolucjonizuje sposób wdrażania aplikacji
> webowych w Ruby i... Pythonie (bo dodano wsgi) powstał pierwotnie dla
> Rubiego. Albo weźmy JRuby. Ma zaimplementowaną Onigurumę, całkiem
> potężną maszynę wirtualną do wyrażeń regularnych i wkrótce ma mieć Joni,
> najszybszy chyba w ogóle parser regexpa. Sam JRuby bije już w wielu
> testach bez problemu Pythona.
Nie zauważyłem.
> Albo weźmy taką kwestię systemu szablonów dla Pythona. Tyle lat się
> męczono. Poza ZPT, który jest niezłą próbą wsadzenia logiki między
> znaczniki XML, nie potrafiono rozwiązać problemu ożenienia znaczących
> wcięć używanych w Pythonie ze znacznikami XML/HTML. Nie, żebym
> był przeciwko wcięciom (wręcz przeciwnie), jakoś trzeba było dopiero
> gości od Rubiego aby wymyślili Haml'a. Haml używa znaczących wcięć do
> generowania XHTML'a i nie musi posiłkować się jakimiś sztucznymi DSL'ami
> tak, jak Django czy Cheetah. Jakieś tam endfor, endif, które nie
> istnieją w Pythonie... Po co, skoro można prościej?
Tylko, że tak wcale nie jest prościej. Zaletą języ(cz)ków szablonowych
jest zanużenie kodu w generowanej treści, co poprawia czytelność dla
tych, których to właśnie ta treść głównie interesuje. PHP i różne inne
ASP są tak popularne nie bez powodu (choć mieszanie warstwy logiki i
prezentacji jest powszechnie uznawane za złe).
> Nie, żebym chciał udowadniać wyższość Rubiego nad Pythonem. Myślę, że
> problemem jest środowisko. Zatęchłe, bufoniaste, nieskore do
> jakiejkolwiek nauki, nieświadomie kopiące grób dla potencjalnych
> miłośników Pythona.
Bufona, nieskorego do nauki, opowiadającego bajki to ja tu widzę
jednego... Przyszedł tu zachwalać Rubiego.
> A wystarczy trochę otwartości, ciekawości i oba
> języki mogą odnieść dużo korzyści. Bo w obu jest wiele ciekawych
> projektów. Chyba Ruby ma społeczność ogólnie młodszą, a na pewno pełną
> entuzjazmu.
>
To fajnie że się dzieci dobrze bawią. Ale jak Ruby dorośnie to
społeczność też dorośnie.
szymon
pisze:
> To fajnie że się dzieci dobrze bawią. Ale jak Ruby dorośnie to
> społeczność też dorośnie.
>
To ja poproszę definicję tego, że już jest podrośnięty, tak żebym wiedział kiedy to będzie.
Jaroslaw Zabiello
<s.bez...@remove.that.informa.and.that.pl> napisał(a):
>> Dlaczego uważasz, że tylko webowych? Przecież to się świetnie nadaje do
>> testowania *dowolnego* kodu.
>
> To się jakoś tam nadaje do prostych testów jednostkowych.
Tak się składa że specyfikacjami BDD pokryty jest już prawie cały język i
biblioteka stabdardowa Rubiego (vide Rubinius). Więc, gadanie, że to tylko
do webu, uznaję za żałosne popiskiwanie ignorantów.
> Do testów funkcjonalnych dla weba lepsze są roboty, gdzie test się
> tworzy nagrywając interakcję użytkownika.
Masz na myśli jakieś makra i testowanie tego al'a Selenium? RSpec jest
dużo szybszy niż makra odpytujące zewnętrznie przeglądarkę.
> Do testów gdzie specyfikacja nie jest trywialna stosuje się formalizm w
> którym ta specyfikacja może być wygodnie wyrażona -- pseudo angielskawe
> zdania są tu kiepskie.
Bo nie masz pojęcia "czym to się je". Te zdania potrafią bardzo
precyzyjnie wyrazić to wszystko co potrzebujesz.
>> Tak w ogóle, obserwując wypowiedzi i całe środowisko, widzę że kręgach
>> pythona mało się dzieje.
>
> Wysraczy popatrzeć na takie PyPy.
A coś tam się w ogóle dzieje? Przepisali już na Pythona cała bibliotekę
standardową?
>> Wygląda tak jakby tam sami emeryci siedzieli. Mało tam inowacyjności.
>> Wszystkie ciekawsze rzeczy jakie spotykam, powstają w Ruby. Capistrano,
>> RSPec, smalltalkowy MagLev,
>
> To są sexy nowomodne bajery, które mało wnoszą.
Raczej to jest twoja kompletna ignorancja. MagLev nic nie wnosi? ROFTL! To
może dać Rubiemu 10x większą (w stos. od Pythona) szybkość połączoną z
obiektową "bazą" danych wydajnie operującą na bilionach obiektów naraz.
Jeśli nie wiesz, to Gemstone na którym jest oaprty MagLev jest rozwijaną i
optymalizowaną wirtualną maszyną Smalltalka od mniej więcej 20 lat.
Capistrano nie wnosi? Hehe, ty chyba nie widziałeś jak wygodnie można tym
zautomatyzować synchronizację miedzy serwerami (z rollbackiem włącznie)
> Przyszedł tu zachwalać Rubiego.
Widzisz. Ja mam porównanie, ty - nie. A tak swoją drogą to ten wątek jest
o tym, który język pozostaje w tyle. :P
Sebastian Kaliszewski
> Dnia 12-08-2008 o 22:29:12 Seweryn Habdank-Wojewodzki
> <sh...@gazeta.skasuj-to.pl> napisał(a):
>
>> Tak. Jestem uprzedzony to "technologii" i do "driven development",
>
> [...]
>
>>> nic ci nie pomoże.
>>
>> Może.
>
> LOL! No to by było na tyle. Grunt to się zapienić i zapomnieć czym jest
> merytoryczna dyskusja. Dobrego samopoczucia życzę.
Look in the mirror, sir!
Sebastian Kaliszewski
Odpowiem przez przykład...
Gdy 8 lat temu wybierano u nas w firmie język i technologię do
realizacji dużego projektu rozważane były różne warianty, m.in. Java,
Python i Perl. Java odpadła z uwagi na ociężałość, brak elastyczności i
parszywy deployment. Python był wówczas właśnie zbyt niedojrzały --
brakowało wielu cholernie potrzebnych bibliotek. Wygrał więc Perl, bo
mimo swojej niesłychanej obrzydliwości, był dojrzały, z CPANu można było
ściągnąć biblioteki do praktycznie czegokolwiek, deployment szybki i
lekki (developerski serwery, osobne dla każdego programisty restartował
się 10s i już można było zobaczyć wykonane zmiany -- w Javie nie było co
o tym marzyć -- była szansa na 2 serwery, restartujące się pół godziny).
Nasz projekt wygrał w pojedynku z innym robionym w Javie (dla tego
samego klienta) -- dużo wcześniej osiągnął jakość produkcyjną i miał 2x
większą wydajność.
Co to znaczy dojrzały? Ot klient zarzyczył sobie możliwość wrzucania
przez publicznego Weba plików excelowych (jak też i generowania innych
plików excelowych i nie jakiś CSV, tylko natywnych) i wyciągania z nich
informacji. W Perlu jest oczywiście gotowy moduł który to obsługuje -- w
Pythonie wówczas nie było (dziś oczywiście jest). Na sajcie który ma
kilka milionów użytkowników zabawa ze stawianiem serwerów windzianych i
na nich Excela (coby był COMowy komponent) żeby sparsować głupi plik
jest niezbyt ciekawa i poza kosztami samej instalacji, podnosi istotnie
koszty administracji. Perl sprawę załatwiał stosunkowo małym modulikiem,
wołanym bezpośrednio z logiki serwera aplikacyjnego. Dziś w Pythonie
można zrobić to samo (też małym modulikiem). Oczywiście takich rzeczy
jest więcej, dużo więcej.
Dziś, na bazie doświadczeń z wielu projektów w naszej wewnętrznej
"technologii" Perlowej, powstaje u nas nowa "technologia" -- tym razem
oczywiście w Pythonie :)
Alek
Użytkownik "szymon" <ne...@mabateus.pl_WITHOUT> napisał :
>> To fajnie że się dzieci dobrze bawią. Ale jak Ruby dorośnie to
>> społeczność też dorośnie.
> To ja poproszę definicję tego, że już jest podrośnięty, tak żebym wiedział
> kiedy to będzie.
To bedzie wtedy, gdy uzytkownicy tego jezyka wylecza sie z kompleksow na
jego punkcie i przestana publikowac (nawet na prywatnych blogach) takie
niedorzeczne testy udawadniajace chyba tylko to, ze autor tego pseudotestu
nie rozumie w ogole jak ten jego test dziala, nie zna jezyka ktory chce
testowac i w ogole chyba ma male pojecie o programowaniu.
Alek
Sebastian Kaliszewski
>> Wszystko inne jest do ustalenia w obrebie umowy (prawnej), ktorej nik
>> nie bedzie parsowal.
>
> Czyli testy też są niepotrzebne?
>
> No i dlaczego lista stories nie może być częścią umowy tego, czego
> klient oczekuje? Są one wystarczająco wysokopoziomowe aby je do tego móc
> użyć.
Ale w jakimkolwiek większym projekcie one mają zbyt małą wyrażalność. A
ich język jest zbyt ubogi, żeby uznać go za treść ludzkiej umowy. Kod
interpretujący to też trafi do umowy? Nonsens.
>> No wiec dlaczego jakies wynurzenia hipisa nagle maja sie stac Driven
>> Development.
>
> Zazdrościsz mu fryzury czy co? :) BDD to przecież nie jego wymysł. Ten
> termin już od dawna funkcjonuje. On tylko w swoich słowach przedstawił
> zalety BDD i Rspec'a w stos. do TDD i UnitTest.
>
>> Idee specyfikacji juz dawno byly znane.
>
> Idee podróży na księżyc też były znane dużo wcześniej. Coś chciałeś
> powiedzieć?
Na Księżyc (to się pisze z wielkiej litery) ludzie polecieli w 1969.
Scenariusze przypoadków użycia i testy wg nich to podobne czasy co lot
na księżyc (btw. metody weryfikajci i testowania softu zostały sporo
rozwinięte właśnie przy okazji lotów na Księżyc :) )
[...]
>> Ja pracuje ze SciPy i nie narzekam na brak innowacyjnosci.
>
> Nie chodzi o narzekanie. Chodzi ogólnie o nowe pomysły.
Ale to co ty przedstawiasz jako nowe, to ma taaaaką brodę.
[...]
>> To znaczy zaszyja parser regexp w VHDL-u?
>
> Nie znam za dużo szczegółów implementacyjnych. Musiałby się tu
> wypowiedzieć Marcin Mielżyński, który portował Onigurumę i teraz zajmuje
> się Joni.
To jest kpina, kolego inżynierze. VHDL to wysokopoziomowy język opisu
układów logicznych (scalonych).
>>> Sam JRuby bije już w wielu testach bez problemu Pythona.
>>
>> Ale mnie rozsmieszyles. A co niby Python to taki High Performance.
>
> No wiadomo, że nie. Ale padają stare argumenty o rzekomo dużo większej
> wydajności Pythona w stos. do Rubiego.
Jak pokazują testy, to to jest nadal prawda.
Sebastian Kaliszewski
Działa. Trzeba mieć oczywiście na takim systemie 32bitowego CPythona --
z 64bitowym oczywiście nie pójdzie.
Jaroslaw Zabiello
> To chyba są dobre microbenchmarki ?
>
> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=jruby&lang2=python
Wziąłem pierwszy z brzegu (binary-tries) gdzie rzekomo Python jest ponoć
aż 2.1 x szybszy.
Wyniki dla "stretch tree of depth 17"
Python 2.5.2 => 27.50 s.
Ruby 1.9 => 27.44 s.
JRuby 1.1.3 puściłem w pętli aby rozgrzać JIT'a.
1 iteracja: 32.68 s.
2 iteracja: 28.23 s.
3 iteracja: 27.29 s.
4 iteracja: 27.12 s.
No i gdzie to 2.1 x szybciej u Pythona? :)
Jaroslaw Zabiello
<s.bez...@remove.that.informa.and.that.pl> napisał(a):
>>> Psyco też działa.
>> Nie działa na systemach 64bitowych.
>
> Działa. Trzeba mieć oczywiście na takim systemie 32bitowego CPythona --
> z 64bitowym oczywiście nie pójdzie.
Miałem na myśli 64bit. Pythona rzecz jasna. To, że w systemie 64bit. można
odpalić aplikację 32 bit. to nic odkrywczego.
Tomasz Elendt
> Dnia 13-08-2008 o 08:21:47 forgems <for...@gmail.com> napisał(a):
>
>> To chyba są dobre microbenchmarki ?
>>
>> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=jruby&lang2=python
>>
>
> Wziąłem pierwszy z brzegu (binary-tries) gdzie rzekomo Python jest ponoć
> aż 2.1 x szybszy.
>
> Wyniki dla "stretch tree of depth 17"
>
> Python 2.5.2 => 27.50 s.
>
> Ruby 1.9 => 27.44 s.
eee.. Ruby 1.9 "is not not production ready". Python 2.5.2 jest.
Środowisko Rubiego ma się z czego cieszyć - Ruby *będzie* równie szybki
jak Python.
:)
--
Eluś
Tomasz Elendt
> [...]
> eee.. Ruby 1.9 "is not not production ready". Python 2.5.2 jest.
to podwójne zaprzeczenie to zwykła pomyłka, nie miała nic sugerować :)
--
Eluś
Tomasz Elendt
> [...]
> Albo weźmy taką kwestię systemu szablonów dla Pythona. Tyle lat się
> męczono. Poza ZPT, który jest niezłą próbą wsadzenia logiki między
> znaczniki XML, nie potrafiono rozwiązać problemu ożenienia znaczących
> wcięć używanych w Pythonie ze znacznikami XML/HTML. Nie, żebym
> był przeciwko wcięciom (wręcz przeciwnie), jakoś trzeba było dopiero
> gości od Rubiego aby wymyślili Haml'a. Haml używa znaczących wcięć do
> generowania XHTML'a i nie musi posiłkować się jakimiś sztucznymi DSL'ami
> tak, jak Django czy Cheetah. Jakieś tam endfor, endif, które nie
> istnieją w Pythonie... Po co, skoro można prościej?
Z ciekawości przyjrzałem się Hamlowi. Interesująca koncepcja, ale nie
użyłbym tego w projekcie, w którym jakiś webmaster/designer odpowiada za
szablony. W takich sytuacjach system szablonów powinien spełniać
następujące wymagania:
- powinien być "bezpieczny" (z uwagi, że nad szablonami nie pracują
programiści, szablon powinien możliwie tworzyć ograniczone, zamknięte i
odizolowane od reszty środowisko)
- struktura dokumentu w HTML, bez udziwnień (bo go webmasterzy znają,
nowych rzeczy uczą się niechętnie)
- znaczniki szablonu (tagi, filtry...) najlepiej żeby nie miały składni
XML-a. Spójrzmy prawdzie w oczy - nikt nie lubi XML-a (a ZPT jest
wyjątkowo ohydne) :) Wiem, że są liczne zalety takiej struktury, ale
IMHO niewystarczające, żeby kogokolwiek zmuszać do pisania czegoś
takiego :) Poza tym inne "ograniczniki" tagów szablonu ładnie odróżniają
je od znaczników HTML-a.
Można krytykować system szablonów Django, ale spełnia on wszystkie te
założenia.
> Nie, żebym chciał udowadniać wyższość Rubiego nad Pythonem. Myślę, że
> problemem jest środowisko. Zatęchłe, bufoniaste, nieskore do
> jakiejkolwiek nauki, nieświadomie kopiące grób dla potencjalnych
> miłośników Pythona. A wystarczy trochę otwartości, ciekawości i oba
> języki mogą odnieść dużo korzyści. Bo w obu jest wiele ciekawych
> projektów. Chyba Ruby ma społeczność ogólnie młodszą, a na pewno pełną
> entuzjazmu.
Myślę, że nikt nie kwestionuje entuzjazmu społeczności Rubiego. Da się
też (nawet przez osobę specjalnie nieobeznaną) zauważyć pewną
innowacyjność Rubiego (choć część ze wspomnianej innowacyjności to
zwykły hype).
Prawda wygląda następująco - większość programistów Pythona albo nie
chce migrować na Rubiego, albo nie widzi takiej potrzeby (choć
faktycznie ten stan rzeczy może zmienić sytuacja na rynku pracy). Ale
nie generalizuj i nie pisz, że środowisko Pythona jest do Rubiego źle
nastawione :))
--
Eluś
Jaroslaw Zabiello
> Z ciekawości przyjrzałem się Hamlowi. Interesująca koncepcja, ale nie
> użyłbym tego w projekcie, w którym jakiś webmaster/designer odpowiada za
> szablony.
No tak. Tu Haml się nie różni od JSP, PHP, ERb, Mako czy nawet Cheetah,
gdzie w każdym wypadku szablon ma dostęp do pełnego interpretera.
> - znaczniki szablonu (tagi, filtry...) najlepiej żeby nie miały składni
> XML-a. Spójrzmy prawdzie w oczy - nikt nie lubi XML-a (a ZPT jest
> wyjątkowo ohydne) :)
ZPT nie po to wynaleziono aby było piękne ale aby pozwalało na
przezroczyste umieszczenie logiki w atrybutach tagów XML. Dla webmasterów
używających Dreamweavera ZPT czy Genshi to rozwiązanie idealne. Prawdziwy
designer nie kala się programowaniem. ;)
> Można krytykować system szablonów Django, ale spełnia on wszystkie te
> założenia.
Akurat to jest dobre dla grupy lokującej się gdzieś pomiędzy typowymi
designerami posługującymi się narzędziami takimi jak Dreamweaver a
programistami. Do tej grupy należą też pehapowe Smarty czy pythonowe
(wzorowane na Django) Jinja
> Ale nie generalizuj i nie pisz, że środowisko Pythona jest do Rubiego
> źle nastawione :))
Nie pisałem że do Rubiego, ale ogólnie do czegoś nowego. To środowisko
bardzo konserwatywne i trochę z klapkami na oczach.
Grzegorz Staniak
>> Rozumiałbym test wydajności generowania treści, połączenia z bazą
>> danych, itp. Ale to co Ty, kolego, pokazałeś jest kompletnie w trzecią
>> stronę. I nawet w tym kilkulinijkowym niby-tescie nie byłeś w stanie
>> stwierdzić co tak na prawdę testujesz.
>
> Akurat nie wiedziałem że Python ma aż tak spieprzony generator losowy.
> Poza tym, zbyt poważnie podchodzisz do tego co się wypisuje w prywatnych
> blogach. To nie rozprawka naukowa. Celem tekstu było zwrócenie uwagi, że
> coś nie gra z tą wydajnością. Nic więcej. Jak ktoś chce to niech porządnie
> i dokładnie sobie napisze kilkadziesiąt stron testów z wykresami i
> tabelami. Nie to było moim celem. Jak tego nie rozumiesz, to widocznie
> masz ogólne problemy ze zbyt spiętym, drętwym podejściem do życia.
Innymi słowy: zrobiłem sobie pseudo-test który niczego sensownego nie testuje
(żeby to pierwszy raz zresztą), ogłaszam więc sobie bardzo pochopne wnioski,
a jak się ktoś czepia i krytykuje, to niech drętwiak z klapkami na oczach
zrobi to za mnie profesjonalnie.
Czy mógłbyś sobie pójść z ewangelizacją na jakieś forum pt. "Dlaczego Ruby
to bóstwo wcielone i zbawienie programistów całego świata", albo założyć
jakąś grupę advocacy? Nie każdy musi mieć ochotę po raz kolejny czytać
o testach co niczego nie testują, oczywistej wyższości i strasznej
społeczności Pythona. Jeśli Ci to pomoże w zaprzestaniu takiej działalności
na tej grupie, możesz ten list potraktować jako objaw klapek na oczach,
drętwoty, konserwatyzmu i czego tam sobie jeszcze życzysz.
GS
--
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Rob Wolfe
> Czy mógłbyś sobie pójść z ewangelizacją na jakieś forum pt. "Dlaczego Ruby
> to bóstwo wcielone i zbawienie programistów całego świata", albo założyć
> jakąś grupę advocacy? Nie każdy musi mieć ochotę po raz kolejny czytać
> o testach co niczego nie testują, oczywistej wyższości i strasznej
> społeczności Pythona. Jeśli Ci to pomoże w zaprzestaniu takiej działalności
> na tej grupie, możesz ten list potraktować jako objaw klapek na oczach,
> drętwoty, konserwatyzmu i czego tam sobie jeszcze życzysz.
Amen
RW
Artur M. Piwko
Jaroslaw Zabiello <hipert...@gmail.com> screamed:
>> Rozumiałbym test wydajności generowania treści, połączenia z bazą
>> danych, itp. Ale to co Ty, kolego, pokazałeś jest kompletnie w trzecią
>> stronę. I nawet w tym kilkulinijkowym niby-tescie nie byłeś w stanie
>> stwierdzić co tak na prawdę testujesz.
>
> Akurat nie wiedziałem że Python ma aż tak spieprzony generator losowy.
Możesz napisać czemu uważasz, że jest spieprzony?
Zupełnie jakbyś porównywał /dev/random z /dev/urandom i twierdził, że
ten pierwszy jest spieprzony ponieważ jest wolniejszy.
> Poza tym, zbyt poważnie podchodzisz do tego co się wypisuje w prywatnych
> blogach. To nie rozprawka naukowa. Celem tekstu było zwrócenie uwagi, że
> coś nie gra z tą wydajnością.
Jak się na siłę "rubizuje" rozwiązania w testach i nie używa dostępnych
rozwiązań to potem wychodzą testy, które niczemu nie służą, może poza
wykazaniem braku wiedzy je przeprowadzającego.
> Nic więcej. Jak ktoś chce to niech porządnie
> i dokładnie sobie napisze kilkadziesiąt stron testów z wykresami i
> tabelami.
To co w ogóle było celem? Napisanie testu, który niczego nie testuje?
--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:226B ]
[ 20:25:03 user up 11798 days, 8:20, 1 user, load average: 0.36, 0.89, 0.45 ]
In C++, only friends may touch your private parts.
Tomasz Elendt
>> - znaczniki szablonu (tagi, filtry...) najlepiej żeby nie miały
>> składni XML-a. Spójrzmy prawdzie w oczy - nikt nie lubi XML-a (a ZPT
>> jest wyjątkowo ohydne) :)
>
> ZPT nie po to wynaleziono aby było piękne ale aby pozwalało na
> przezroczyste umieszczenie logiki w atrybutach tagów XML. Dla
> webmasterów używających Dreamweavera ZPT czy Genshi to rozwiązanie
> idealne. Prawdziwy designer nie kala się programowaniem. ;)
>
>> Można krytykować system szablonów Django, ale spełnia on wszystkie te
>> założenia.
>
> Akurat to jest dobre dla grupy lokującej się gdzieś pomiędzy typowymi
> designerami posługującymi się narzędziami takimi jak Dreamweaver a
> programistami. Do tej grupy należą też pehapowe Smarty czy pythonowe
> (wzorowane na Django) Jinja
Eliminując przypadki użycia narzędzi typu WYSIWYG (o których muszę
przyznać mam bardzo złe zdanie) szablony o składni XML-owej są
tragicznie niewygodne.
W "klasycznym" ujęciu rozróżnia się dwie profesje:
- grafika (ten nie musi znać nawet HTML)
- webmastera
Ten drugi zna HTML-a (i przeważnie choć podstawy XML), czasem też ma
jakieś tam podstawy z programowania (w 90% poznane na przykładzie JS).
Np. wie czym jest pętla i umiałby ją zastosować do znalezienia
największego elementu kolekcji. Obciążając takiego człowieka rolą
tworzenia szablonów lepsze wydają się być systemy szablonowe z tej
drugiej grupy. I zgodnie z moimi obserwacjami, takie rozwiązanie jest
popularniejsze.
Chociaż nie oszukujmy się, dość często w przypadku pracy w "webie"
trzeba umieć robić wiele rzeczy jednocześnie, łączy się profesje (stąd
popularny termin "człowiek-orkiestra").
Wynalazki takie jak Haml, gdzie składnię HTML zastępuję się całkiem
nowym językiem celują w jeszcze mniejszy target - w ludzi którzy mimo,
że znają HTML mają chęć nauczyć się nowego języka. Chyba tylko
programiści czerpią przyjemność z nauki nowych języków :)
No i prawie bym zapomniał o lansie. Jaka to frajda oznajmić koledze:
"Patrz, ten serwis zrobiłem w całości sam. I nie napisałem ani jednej
linii HTML"
;)
--
Eluś
Radomir 'The Sheep' Dopieralski
Tomasz Elendt wrote:
> Eliminując przypadki użycia narzędzi typu WYSIWYG (o których muszę
> przyznać mam bardzo złe zdanie) szablony o składni XML-owej są
> tragicznie niewygodne.
>
> W "klasycznym" ujęciu rozróżnia się dwie profesje:
> - grafika (ten nie musi znać nawet HTML)
> - webmastera
>
> Ten drugi zna HTML-a (i przeważnie choć podstawy XML), czasem też ma
> jakieś tam podstawy z programowania (w 90% poznane na przykładzie JS).
> Np. wie czym jest pętla i umiałby ją zastosować do znalezienia
> największego elementu kolekcji. Obciążając takiego człowieka rolą
> tworzenia szablonów lepsze wydają się być systemy szablonowe z tej
> drugiej grupy. I zgodnie z moimi obserwacjami, takie rozwiązanie jest
> popularniejsze.
Tak naprawde, to mozecie sobie tutaj dyskutowac az sie ciemno zrobi,
i kazdy z was bedzie mial racje. Wszystko zalezy od tego, kto sie wam
do zespolu trafi, co juz bedzie umial, z czym bedzie mu wygodnie oraz
czego da sie go wogole nauczyc. Z reszta z jego strony jest podobnie.
Osobiscie jestem wielkim fanem szablonow glownie dlatego, ze wytlumaczenie
"programistom" co to jest poprawny HTML (a jeszcze "semantycznie"
poprawny) najczesciej przekracza moje skromne mozliwosci pedagogiczne,
a takze cierpliwosc. W ktorym miejscu sie dokladnie ciachnie, to zalezy
od kompetencji obydwu stron.
--
Radomir `The Sheep' Dopieralski <http://sheep.art.pl>
On and on until we change / Everything remains the same
On and on until we learn / On and on the wheels will turn
Sebastian Kaliszewski
>>> Dlaczego uważasz, że tylko webowych? Przecież to się świetnie nadaje
>>> do testowania *dowolnego* kodu.
>>
>> To się jakoś tam nadaje do prostych testów jednostkowych.
>
> Tak się składa że specyfikacjami BDD pokryty jest już prawie cały język
> i biblioteka stabdardowa Rubiego (vide Rubinius). Więc, gadanie, że to
> tylko do webu, uznaję za żałosne popiskiwanie ignorantów.
Żałośnie popiskujesz co najwyżej ty, inżynierze. Nigdzie nie pisałem, że
to się nadaje tylko do beba. Bo do weba to to się nadaje średnio.
>> Do testów funkcjonalnych dla weba lepsze są roboty, gdzie test się
>> tworzy nagrywając interakcję użytkownika.
>
> Masz na myśli jakieś makra i testowanie tego al'a Selenium? RSpec jest
> dużo szybszy niż makra odpytujące zewnętrznie przeglądarkę.
Tylko, że kolego inżynierze:
1. RSpec nie sprawdzi mi funkcjonalności wykonywanej dopiero przez
przeglądarkę
2. Co z tego że jest szybszy, skoro istotnych testów funkcjonalnych nie
da się nim wykonać
3. Nawet te testy które da się zaprogramować w RSpec, da się przygotowac
szybciej i taniej (bo bez udziału programisty) innymi narzędziami (i nie
musi to być wcale podczepka pod przeglądarkę). Koszt nawet kiepskiego
programisty to 100000 rocznie. Za tyle to można mieć 5 dedykowanych do
testów serwerów -- więc to że odtwarzanie interakcji z serwerem jest
mniej wydajne jest kompletnie bez znaczenia.
>> Do testów gdzie specyfikacja nie jest trywialna stosuje się formalizm
>> w którym ta specyfikacja może być wygodnie wyrażona -- pseudo
>> angielskawe zdania są tu kiepskie.
>
> Bo nie masz pojęcia "czym to się je".
Kolego, nie ośmieszaj się bardziej.
> Te zdania potrafią bardzo
> precyzyjnie wyrazić to wszystko co potrzebujesz.
Bu, ha ha ha ha!
Wyraź mi w nich choćby wygląd javascriptowego kalendarza podczepionego
pod pole wprowadzania daty.
Wyraź mi w nich wymaganie, że funkcja hashująca nie ma funeli mniejszych
niż 30 bitów...
>>> Tak w ogóle, obserwując wypowiedzi i całe środowisko, widzę że
>>> kręgach pythona mało się dzieje.
>>
>> Wysraczy popatrzeć na takie PyPy.
>
> A coś tam się w ogóle dzieje? Przepisali już na Pythona cała bibliotekę
> standardową?
Działa wystarczająco dużo, żeby uruchomić na tym Django. Na ten rok
planują wersję 1.1
Panowie zajmują się robotą a nie autopromocją.
>>> Wygląda tak jakby tam sami emeryci siedzieli. Mało tam inowacyjności.
>>> Wszystkie ciekawsze rzeczy jakie spotykam, powstają w Ruby.
>>> Capistrano, RSPec, smalltalkowy MagLev,
>>
>> To są sexy nowomodne bajery, które mało wnoszą.
>
> Raczej to jest twoja kompletna ignorancja.
Nie. To jest praktyczne spojrzenie na rzeczywistość.
Po twoim ostatnim "pokazie możliwości" wstrzymaj sieod nazywania innych
ignorantami, bo się coraz bardziej ośmieszasz.
> MagLev nic nie wnosi? ROFTL!
> To może dać Rubiemu 10x większą (w stos. od Pythona) szybkość połączoną
> z obiektową "bazą" danych wydajnie operującą na bilionach obiektów
> naraz. Jeśli nie wiesz, to Gemstone na którym jest oaprty MagLev jest
> rozwijaną i optymalizowaną wirtualną maszyną Smalltalka od mniej więcej
> 20 lat.
Smalltalka. Nie Rubiego. Co z bibliotekami, zwłaszcza tymi "natywnymi"?
To jest bardzo sexy i w ogóle, i benchmarki będą śmigać i super. Tylko,
że to będzie miało wąskie zastosowanie.
> Capistrano nie wnosi? Hehe, ty chyba nie widziałeś jak wygodnie
> można tym zautomatyzować synchronizację miedzy serwerami (z rollbackiem
> włącznie)
Capistrano to jest sobie aplikacja do zdalnej administracji. Jedna z
setek. Ani najlepsza ani najgorsza. Napisano ją w Rubym? To fajnie, że w
języku programowania (podobno uniwersalnym) daje się napisać program
potrafiący wywołać ssh.
>> Przyszedł tu zachwalać Rubiego.
>
> Widzisz. Ja mam porównanie, ty - nie.
Ty? To co pokazałeś to jest kpina. Śmiem wątpić w twoją znajomość
Pythona w ogóle.
> A tak swoją drogą to ten wątek
> jest o tym, który język pozostaje w tyle. :P
Cóż, poza webem to Ruby jest daaaleko. Przy bardziej zaawansowanych
rzeczach webowych (coś więcej niż sklep na Railasch) też jest z tyłu, z
powodu ubóstwa bibliotek. Przy robieniu rzeczy ciekawych z punktu
widzenia informatyki jako takiej także -- PyPy (i wcześnie Psyco) wnosi
coś nowego, *DD nic nie wnosi, bo to są po prostu bzdety połączone z
odkrywaniem na nowo półwiecznej historii...
szymon
pisze:
> Jaroslaw Zabiello wrote:
> >>> Dlaczego uważasz, że tylko webowych? Przecież to się świetnie nadaje
> >>> do testowania *dowolnego* kodu.
> >>
> >> To się jakoś tam nadaje do prostych testów jednostkowych.
> >
> > Tak się składa że specyfikacjami BDD pokryty jest już prawie cały język
> > i biblioteka stabdardowa Rubiego (vide Rubinius). Więc, gadanie, że to
> > tylko do webu, uznaję za żałosne popiskiwanie ignorantów.
>
> Żałośnie popiskujesz co najwyżej ty, inżynierze. Nigdzie nie pisałem, że
> to się nadaje tylko do beba. Bo do weba to to się nadaje średnio.
>
tzn. co się nadaje średnio? ruby jako taki?
>
> >>> Tak w ogóle, obserwując wypowiedzi i całe środowisko, widzę że
> >>> kręgach pythona mało się dzieje.
> >>
> >> Wysraczy popatrzeć na takie PyPy.
> >
> > A coś tam się w ogóle dzieje? Przepisali już na Pythona cała bibliotekę
> > standardową?
>
> Działa wystarczająco dużo, żeby uruchomić na tym Django. Na ten rok
> planują wersję 1.1
>
I to jest ten jedyny i główny powód dlaczego Ruby jest be a Python cacy?
Sebastian Kaliszewski
> Dnia 13-08-2008 o 13:48:23 Sebastian Kaliszewski
> <s.bez...@remove.that.informa.and.that.pl> napisał(a):
>
>>>> Psyco też działa.
>>> Nie działa na systemach 64bitowych.
>>
>> Działa. Trzeba mieć oczywiście na takim systemie 32bitowego CPythona
>> -- z 64bitowym oczywiście nie pójdzie.
>
> Miałem na myśli 64bit. Pythona rzecz jasna. To, że w systemie 64bit.
> można odpalić aplikację 32 bit. to nic odkrywczego.
>
Tyle, że 64bit Python tylko z rzadka jest potrzebny. Kiedy 64bit stanowi
istotną różnicę to zwykle ani Python ani Ruby się do rozwiązania
problemu nie nadają.
Sebastian Kaliszewski
> Dnia 2008-08-14, czw o godzinie 13:03 +0200, Sebastian Kaliszewski
> pisze:
>> Jaroslaw Zabiello wrote:
>>>>> Dlaczego uważasz, że tylko webowych? Przecież to się świetnie nadaje
>>>>> do testowania *dowolnego* kodu.
>>>> To się jakoś tam nadaje do prostych testów jednostkowych.
>>> Tak się składa że specyfikacjami BDD pokryty jest już prawie cały język
>>> i biblioteka stabdardowa Rubiego (vide Rubinius). Więc, gadanie, że to
>>> tylko do webu, uznaję za żałosne popiskiwanie ignorantów.
>> Żałośnie popiskujesz co najwyżej ty, inżynierze. Nigdzie nie pisałem, że
>> to się nadaje tylko do beba. Bo do weba to to się nadaje średnio.
>
> tzn. co się nadaje średnio? ruby jako taki?
Przeczytaj jeszcze raz.
>
>
>>>>> Tak w ogóle, obserwując wypowiedzi i całe środowisko, widzę że
>>>>> kręgach pythona mało się dzieje.
>>>> Wysraczy popatrzeć na takie PyPy.
>>> A coś tam się w ogóle dzieje? Przepisali już na Pythona cała bibliotekę
>>> standardową?
>> Działa wystarczająco dużo, żeby uruchomić na tym Django. Na ten rok
>> planują wersję 1.1
>>
>
> I to jest ten jedyny i główny powód dlaczego Ruby jest be a Python cacy?
Kolego, czy ty umiesz czytać?
Jaroslaw Zabiello
<s.bez...@remove.that.informa.and.that.pl> napisał(a):
> Tyle, że 64bit Python tylko z rzadka jest potrzebny.
Jak mam cały system 64bitowy, procesor 64 bitowy to chyba logiczne, że
będę chciał używać 64bitowych aplikacji jeśli to możliwe.
> Kiedy 64bit stanowi istotną różnicę to zwykle ani Python ani Ruby się do
> rozwiązania problemu nie nadają.
Niekoniecznie.