🚀 go-pugleaf

Luk6Man pisze:
> Witam
> Od niedawna zainteresowałem się pythonem, najbardziej interesuje mnie
> zastosowanie go do pisania aplikacji webowych. Czy ktoś mógł by pomóc
> i podać linki do jakiś dobrych tutoriali/dokumentacji z tej
> dziedziny ? Niestety poszukiwania przez google nie były zbyt
> efektywne. We wszystkich materiałach natykałem się na stwierdzenie, że
> mogę użyć albo cgi albo mod_python albo wsgi. 

W zapytaniu domniemuję, że wykluczasz istniejące frameworki?
Masz jakieś powody, by patrzeć niskopoziomowo?

> ps. czy ktoś z was zajmował się jPythonem ? czy za jego pomocą można
> np tak jak w jRuby tworzyć .wary i deployowac np na Tomcata ?

ciekawe pytanie, chętnie posłucham...

Luk6Man wrote:
> i podać linki do jakiś dobrych tutoriali/dokumentacji z tej
> dziedziny ? Niestety poszukiwania przez google nie były zbyt
??
Zartujesz, tego jest na tony :)
Najczesciej pod Pythonem korzystasz z gotowego frameworku bo raczej nikt
sie nie bawi w gniazdka jak chce pisac wygodnie.
Z najpopularniejszych frameworkow pod Pythona masz: Django, Pylons,
CherryPy, TurboGears, web2py, etc... Jest tez Zope ;)
Wszystkie z powyzszej listy korzystaja z nadbudowy na protokol TCP/IP
ktory nazywa sie WSGI. Dzieki czemu mozna dosc wygodnie laczyc rozne
frameworki albo je rozbudowywac.

> mogę użyć albo cgi albo mod_python albo wsgi. O ile CGI odrzucam już
To w jaki sposob bedziesz hostowal aplikacje to kwestia drugorzedna.
Generalnie masz tutaj ogromny wybor w zaleznosci do czego to
potrzebujesz, IMHO bedziesz dzieki temu bardziej swiadom jak dziala
aplikacja internetowa w przeciwienstwie do typowego programisty Javowego
dla ktorego to magia.
Z popularniejszych "bram" polecalbym Ci przynajmniej na poczatek uzycie
natywnego serwera na ktorym dziala dany framework (czesto to popularny
paster) i schowanie go za jakims serwerem WWW jak Apache (sredni
pomysl), nginx, lighttpd, etc...
Mozesz uzyc oczywiscie Tomcata jak masz doswiadczenie w tej materii
(sredni pomysl).

> serwer ??? ) 2. zainstaluj mod_python/mod_wsgi 3. <instrukcja w stylu
Taki opis znajdziesz dla kazdego frameworka i to krok po kroku:
Np mod_python dla Pylons:
http://wiki.pylonshq.com/display/pylonscookbook/Production+deployment+using+mod_python
nginx dla Pylons:
http://wiki.pylonshq.com/display/pylonscookbook/Running+Pylons+with+NGINX
nginx dla Django:
http://www.rkblog.rk.edu.pl/w/p/django-nginx/
reszte znajdziesz juz bez problemu sam...

> ps. czy ktoś z was zajmował się jPythonem ? czy za jego pomocą można
Tak, do automatycznych testow. Na razie to tylko i wylacznie zabawka.
Z tego co wiem grupa maniakow odpala na tym Django a wkrotce i Pylons.
Z drugiej strony powiedz mi po jaka anielke chcesz kalac dobry jezyk tym
przedrostkiem na "J" ?
Chcesz sie bawic Java mecz sie z Tomcatem, GlashFishem, JBossem, EJB,
OAS, etc...
Chcesz sie bawic Pythonem - zobacz rozwiazania stricte Pythonowe - jest
ich na prawde duzo i sa takze sprawdzone w olbrzymich produkcyjnych
zastosowaniach. Wbrew pozorom Java nie ma wylacznosci na slowa bussines
i industrial ;)
No chyba ze masz mase bibliotek w Javie i chcesz sie przesiasc na
Pythona - to jedyny logiczny argument uzycia mutanta Jythona.
Ale i tutaj takze mozesz zobaczyc PyPi i sprawdzic czy w swiecie na "P"
ktos juz tego nie zrobil :)

-- 
Pozdrawiam
Artur Lew
arturdotlewatgmaildotcom

Jeżeli chodzi o frameworki to faktycznie jest tego sporo. Może
wyszedłem, ze złego założenie, że na początek żaden framework jest mi
nie potrzebny. Może to przez to,  że podszedłem do Pythona z bagażem
doświadczeń z javy czy też php i spodziewałem się czegoś podobnego.
Czy dobrze wnioskuję, że czegoś w stylu stronki php czy jsp/servlet w
pythonie nie uświadczę ?

Jeżeli chodzi o Jythona to wydało mi się to dość ciekawe, tak same jak
jRuby i Groovy. Idea pisania aplikacji w wielu językach wydaje mi się
nie tylko ciekawe ale i w miarę słuszna. Stosując jedną platformę
uruchomieniową można teoretycznie każdy moduł aplikacji napisać w
języku który bardziej się do danej czynności nadaje ewentualnie który
lepiej znamy. No ale nie wykluczone też, że moja fascynacja językami
na j wiąże się z tym że przez długi okres czasu chciałem być właśnie
programistą javowym.

aha jak kogoś interesuje temat jython, a jak ja nie za wiele jeszcze o
nim wie, to znalazłem coś takiego:
http://seanmcgrath.blogspot.com/JythonWebAppTutorialPart1.html
Artykuł nie najświeższy już ale dla mnie na początek był fajny.

Łukasz Mańkowski pisze:
> aha jak kogoś interesuje temat jython, a jak ja nie za wiele jeszcze o
> nim wie, to znalazłem coś takiego:
> http://seanmcgrath.blogspot.com/JythonWebAppTutorialPart1.html
> Artykuł nie najświeższy już ale dla mnie na początek był fajny.
> 
Eeeee no fajnie sobie szukasz, nie wiedziałem o takich opcjach.
Kierunek poszukiwań na wielość języków oraz integrację jest jak 
najbardziej ok (ja ostatnie miesiące bywam na połączeniu Java + coś, 
przy czym 'cosiem' z testów został Groovy; akurat to nie web bo bym 
pewnie sprawdzał Grails), ale ciągle patrzysz niskopoziomowo ...

Tym 'servletem' z poprzedniego poczułem się wywołany do tablicy.

Są w branży pythona takie podstawowe sample, jakby zacząć czytać coś z 
kręgów mod-python tam były takie tutoriale. Są to skrypty, więc z punktu 
widzenia dynamiki (czasu życia, ładowania obiektów itd) bliżej im do php 
niż servletu.

Javowski servlet, jak postrzegam i nie jestem osamotniony, jest po to 
żeby owszem się z nim zapoznać, poczuć jak to działa, ale zaraz po hello 
world i 2-3 próbach przenieść się wyżej.
Na gołym servlecie programuje się bardzo rzadko, jak są ku temu jakieś 
wyraziste powody, lub się jest twórcą frameworka.

Podobnie JSP nie ujęte w jakieś zasady architektury, najczęściej 
widziane jest negatywnie, bo zwykle wychodzą koszmarki. Powiedzieć, ze 
aplikacja jest zrobiona w JSP, to nic nie powiedzieć. (Nawiasem mówią 
któryś z modułów template chwali się podobieństwem do JSP).

Jakie **naprawdę** są twoje doswiadczenia w Javie, może znajdziemy 
pythonowy odpowiednik (chłopcy z załogi bardzo starają się by było to 
porównywalne)

Odnieść się do twoich doświadczeń w PHP nie potrafię, ale jak znów 
milczysz o frameworkach, obawiam się że trafiałeś w życiu na same 
niskopoziomowe doświadczenia. Dla mnie to jest krąg, że złych zwyczajów 
jest więcej niż dobrych.

Łukasz Mańkowski wrote:
> nie potrzebny. Może to przez to,  że podszedłem do Pythona z bagażem
> doświadczeń z javy czy też php i spodziewałem się czegoś podobnego.
> Czy dobrze wnioskuję, że czegoś w stylu stronki php czy jsp/servlet w
To czesty "bagaz" wiec wybaczamy ;)
Oczywiscie mozesz w Pythonie pisac strony w stylu JSP - beda mialy
odpowiednio rozszerzenie PSP i jest to standardowa funkcjonalnosc
zapewniona przez mod_python.
W praktyce wyglada to byle jak, podobnie jak strona z JSP - tylko
skladnia lepsza (gole JSP bez JSTL to koszmarek)
Wybierajac Pythona warto wybrac gotowy framework ktory zalatwia za ciebie
mnostwo typowych zadan dzieki czemu pisanie takiej aplikacji to poezja
(w porownaniu np do Javy).
Podejscie jest oczywiscie inne.
W swiecie Javy byles uzalezniony od gotowych kreatorow generujacych za
Ciebie tony geterow, seterow i anotacji. Wmawiano Ci ze takie podejscie
jest cool i rapid.
W porownaniu z tym co oferuje framework w stylu Django czy Pylons moze
na poczatku wyda co wszystko prymitywne - dopoki nie okaze sie ze
stworzenie prostej aplikacji to pestka i nie bedzie to wynikalo z
zbajerzonych kreatorow pod Netbeans czy Eclipse generujacych megabajty
ciezkiego kodu.
Odczujesz zapewne tez pewien dyskomfort wynikajacych z faktu ze ten
cudowny "XML" tak na prawde nie jest taki idealny i ze Java go uzywa
zeby ukryc swoja brzydote i brak elastycznosci. Bedziesz mial pewnie
problem z odnalezieniem sie posrod czegos takiego jak request czy kody
bledow HTTP (bo w "webservice" byl wyjatek...). Bo w Javie to wszystko
bylo persistent albo industrial ;)
Tutaj ten "prymitywizm" frameworka w Pythonie (albo tez w Rubym bo jest
wiele podobienstw np RoR vs Pylons) okaze sie zaleta bo narzut gotowych
narzedzi jest minimalny i w latwy sposob kontrolujesz wszystko co sie
dzieje w Twojej aplikacji. I co najwazniejsze w latwy sposob umiescisz
go na w miare byle jakim serwerze (haczyk - dostep do shella).
Aha i jeszcze jedno.
Zauwazysz ze Twoja nawet dosc zbajerzona aplikacja ma problem z
przekroczeniem 40 MB pamieci podczas gdy prosta aplikacja webowa w Javie
w zaleznosci od mnogosci parametrow uruchomieniowych to nawet 400 MB
RAMu. Wiem co mowie bo w pracy czesto prototypuje w Pythonie a musze
zobaczyc to w Javie i roznica jest kolosalna.
Oczywiscie winna jest moja lameriada bo JVM musi sie rozbujac...
;)

> Jeżeli chodzi o Jythona to wydało mi się to dość ciekawe, tak same jak
Jest cala masa takich dziwnych mixow. Tak jak pisalem wczesniej -
wygodnie jest tego uzyc gdy nie chcesz przenosic masy bibliotek z Javy
na Pythona. Z drugiej strony jak Ci tak dobrze bylo pod Java to po co
migracja na Pythona ?

> jRuby i Groovy. Idea pisania aplikacji w wielu językach wydaje mi się
To fajne jezyki, fajny element dydaktyczny.
W praktyce gdy chcesz napisac cos o czym chcesz po skonczeniu umowy z
klientem zapomniec to warto uzyc czegos bardziej rozpowszechnionego lub
chociazby sprawdzonego w srodowisku live.

> języku który bardziej się do danej czynności nadaje ewentualnie który
> lepiej znamy. No ale nie wykluczone też, że moja fascynacja językami
To fajne, akademickie zalozenie. Bardzo podobny argument byl wytaczany
przy idei .NET.
W praktyce pomost pomiedzy technologiami czy implementacjami skutecznie
wyklucza wygodne i efektywne uzycie takiego mechanizmu co widac po braku
zalewu aplikacji z czescia webowa w Erlangu, GUI w C#, obsluga XMLa w
Javie a zapisem pliku w Rubym ;)

> programistą javowym.
Warto umiec kilka jezykow i technologii.
Programujac w Pythonie nauczysz sie zupelnie inaczej podchodzic do
pewnych problemow w Javie. Decyzje o tym czy i kiedy migrowac calkowicie
okresli Twoj pracodawca lub rynek.

-- 
Pozdrawiam
Artur Lew
arturdotlewatgmaildotcom

>Użytkownik "Łukasz Mańkowski" <Lukasz.Mankowski@gmail.com> napisał w 
>wiadomości 
>news:03eaea1b-e051-4cbc-92af-b88562e9ff3d@3g2000yqk.googlegroups.com...
>Jeżeli chodzi o frameworki to faktycznie jest tego sporo. Może
>wyszedłem, ze złego założenie, że na początek żaden framework jest mi
>nie potrzebny. Może to przez to,  że podszedłem do Pythona z bagażem
>doświadczeń z javy czy też php i spodziewałem się czegoś podobnego.
>Czy dobrze wnioskuję, że czegoś w stylu stronki php czy jsp/servlet w
>pythonie nie uświadczę ?

IMHO mod_python + jego standardowe handlery (publisher i psp) dostarczają ci 
tego właśnie poziomu. Czystego mod_pythona dedykowałbym ci jeśli chcesz 
zrobić coś mocno zoptymalizowanego lub specjalizowanego np. wydajny 
uploadler / downloader do plików lub strumieni, handler autentykacji i 
autoryzacji itp. Do klasycznego "contentu" html lepszy zapewne będzie 
framework współpracujący z serwerem serwerem po wsgi.

Artur Lew pisze:
> To czesty "bagaz" wiec wybaczamy ;)
Bardzo ciekawe twoje porównanie i z większością się zgodzę. W kilku 
punktach sprostowania.

Na potrzeby felietonistyczne można użyc słowa Java w sensie ogólnym, 
jednak jak przychodzi do szczegółów może to zawieść. Czym innym jest 
język (definicja, syntax, semantyka, kontrola, bibl. standardowa itd.), 
nieco czym innym promowane w okolicy języka wzorce i tradycje. Czym 
innym konkretne realizacje.

Ja tam za full-time javowca się nie uważam, webem zająłem się stosunkowo 
późno, pewne doświadczenia (Struts, stare JSP) na szczęscie pominąłem 
itd. Ostatnimi czasy niewiele z pythonem ale ciągle sympatyzuję.


> W swiecie Javy byles uzalezniony od gotowych kreatorow generujacych za
> Ciebie tony geterow, seterow i anotacji. Wmawiano Ci ze takie podejscie
> jest cool i rapid.
Dajmy inne prawo językowi kompilowanemu, inne intepretowanemu. W Javie 
zwykle wychodzi 2x (?) więcej linii, ale jak już się skompiluje, ma duże 
szanse chodzić. Dodajmy do tego konwencję JavaBean - nie jest to cecha 
tylko apliakcji webowych - po prostu 'tak to jest' (nie wnikam). 
Dostosowanie do koncepcji 'corpo' czyli podatność na bezpieczne łączenie 
różnych softwarów różnych dostawców przez wspólne standardy swoje 
pozytywy ma, ale koszty i minusy też. (nie ukrywajmy, ze 'standardowym 
robotnikiem programistą po standardowych egzaminach' również.

> W porownaniu z tym co oferuje framework w stylu Django czy Pylons moze
> na poczatku wyda co wszystko prymitywne - dopoki nie okaze sie ze
> stworzenie prostej aplikacji to pestka i nie bedzie to wynikalo z
> zbajerzonych kreatorow pod Netbeans czy Eclipse generujacych megabajty
> ciezkiego kodu.
Ja tam robie sobie weba bez w/w generowanych megabajtów.

> Odczujesz zapewne tez pewien dyskomfort wynikajacych z faktu ze ten
> cudowny "XML" tak na prawde nie jest taki idealny i ze Java go uzywa
> zeby ukryc swoja brzydote i brak elastycznosci. 
Ooo tu to mocny skrót myślowy. Jest wewnątrz środowisk javy mocna 
opozycja antyxml-owa. Osobiście tworzę w Wicket fw który jest bez XML-i. 
Uzycie XML w wielu (nawet wiodących) fw nie dowodzi że tak musi być.

Z kolei obecność XML w IoC, dynamicznym ładowaniu klas (EJB itd) troche 
potwierdza twoje zdanie: język kompilowany o pewnej sztywności (np. 
typów), w ten sposób przenosi się na runtime pewne decyzje - w 
kompilowanym być może nie istnieje radykalnie inne filozofia (ale to nie 
stricte warstwa www). Teoretycznie mogłyby to być inne pliki niż XML, 
ale czytane na runtime.
Tu rzeczywiście powtarzam przykład z Pythona: da się drukować na 
cokolwiek, co ma metodę 'write': jest bardzo elastyczne ale nie 
ukrywajmy, może szokować rygorystów OOP.


> Bedziesz mial pewnie
> problem z odnalezieniem sie posrod czegos takiego jak request czy kody
> bledow HTTP (bo w "webservice" byl wyjatek...). 
Tego nie zrozumiałem. Znaczy poziom 'request' to dobrze czy żle?

> Bo w Javie to wszystko  bylo persistent albo industrial ;)
Tu też nicht verstehen

> Tutaj ten "prymitywizm" frameworka w Pythonie (albo tez w Rubym bo jest
> wiele podobienstw np RoR vs Pylons) okaze sie zaleta bo narzut gotowych
> narzedzi jest minimalny i w latwy sposob kontrolujesz wszystko co sie
> dzieje w Twojej aplikacji. 
To dorzucę jeszcze jednego klona RoR czyli Grails. Mądrzę się bo 
czytałem z nie używałem ;)

Zasadniczo znów fakt interpreterów ułatwia wiele rzeczy (znów: niektóre 
utrudnia).

> Aha i jeszcze jedno.
> Zauwazysz ze Twoja nawet dosc zbajerzona aplikacja ma problem z
> przekroczeniem 40 MB pamieci podczas gdy prosta aplikacja webowa w Javie
> w zaleznosci od mnogosci parametrow uruchomieniowych to nawet 400 MB
> RAMu. Wiem co mowie bo w pracy czesto prototypuje w Pythonie a musze
> zobaczyc to w Javie i roznica jest kolosalna.
> Oczywiscie winna jest moja lameriada bo JVM musi sie rozbujac...
> ;)
Z jednej strony zależy od serwerów (nie precyzujesz), z innej kawał tego 
RAM-u to długotrwałe bufory i cache danych, czyli miejsce gdzie 
odzyskujemy to w postaci szybkości później.

 > Warto umiec kilka jezykow i technologii.
 > Programujac w Pythonie nauczysz sie zupelnie inaczej podchodzic do
 > pewnych problemow w Javie.

święte słowa.

W konkluzji: dla mnie jest sympatyczny taki folklor:  ciągłe 
porównywanie sie środowisk pythonowych z javą (jednak równanie w górę?), 
charakterystyczny niemal brak liczniejszych polemik z pozornie jakby 
najbardziej 'oczywistym' konkurentem czyli php.
I na pewno życzę Pythonowi w webie jeszcze lepszej pozycji niż ma.

On 15 Cze, 10:07, Jacek Czerwinski <x...@y.z.pl> wrote:
> Artur Lew pisze:> To czesty "bagaz" wiec wybaczamy ;)
>
> W konkluzji: dla mnie jest sympatyczny taki folklor:  ciągłe
> porównywanie sie środowisk pythonowych z javą (jednak równanie w górę?),
> charakterystyczny niemal brak liczniejszych polemik z pozornie jakby
> najbardziej 'oczywistym' konkurentem czyli php.
> I na pewno życzę Pythonowi w webie jeszcze lepszej pozycji niż ma.

Według mnie jednak bliżej pythonowi do javy niż do php. Może trochę
uogólniam ale jak dla mnie php to język skryptowy przeznaczony do
pisania skryptów webowych.
Python może i jest interpretowany i dynamiczny ale jest językiem
bardziej ogólnego zastosowania co według mnie czyni go bliższym javie
niż php. Dodatkowo o ile czegoś źle nie wyczytałem to kod python po
cichu jest kompilowany do postacie kodu pośredniego który jest
wykonywany na maszynie wirtualnej pythona - co mi osobiście już w
ogóle kojarzy z Javą ( dokładnego źródła nie pamiętam, ale wydaje mi
się że wyczytałem to w książce Python. Wprowadzenie - O'REILLY )

Wracając dość do głównego nurtu dyskusji, czy któryś z frameworków
jest jakoś znacząco prostszy trudniejszy ? Czy coś specjalnie
przemawia za tym żeby na początek wybrać powiedzmy Django a nie Pylosa
czy nie wiem TurboGears ?

Łukasz Mańkowski pisze:

> 
> Według mnie jednak bliżej pythonowi do javy niż do php. Może trochę
> uogólniam ale jak dla mnie php to język skryptowy przeznaczony do
> pisania skryptów webowych.

No ale na pocieche na Onecie jest artykuł o alternatywach do PHP.

> Python może i jest interpretowany i dynamiczny ale jest językiem
> bardziej ogólnego zastosowania co według mnie czyni go bliższym javie
> niż php. Dodatkowo o ile czegoś źle nie wyczytałem to kod python po
> cichu jest kompilowany do postacie kodu pośredniego który jest
> wykonywany na maszynie wirtualnej pythona - co mi osobiście już w
> ogóle kojarzy z Javą ( dokładnego źródła nie pamiętam, ale wydaje mi
> się że wyczytałem to w książce Python. Wprowadzenie - O'REILLY )
Dobrze kojarzysz. ja to poznawałem od strony interfejsowania z C. Dobrze 
przemyślana struktura typów, obiektów itd. Do 2.2 chyba było inaczej, od 
2.3 2.4 jakieś zmiany koncepcji obiektów tzw. nowe klasy.
Dojrzałe to to i dobrze udokumentowane, choć kod C z lekka stare 
konwencje z makrami, ale w rzeczywistości rzetelna obiektówka. (Tak jak 
na odwrót w hipersuper OO Language 7-mej generacji można pisać debilizmy)


> 
> Wracając dość do głównego nurtu dyskusji, czy któryś z frameworków
> jest jakoś znacząco prostszy trudniejszy ? Czy coś specjalnie
> przemawia za tym żeby na początek wybrać powiedzmy Django a nie Pylosa
> czy nie wiem TurboGears ?

Ja tu (www+python) jestem cienki, ale w Django wszedłem w 2h gdy w coś 
innego (to 2 lata temu nie pamiętam czy Pylonsy) "aż" 5h. Mocno 
nieaktualna wiedza.

O frameworkach myślę tak (obojętnie Java/Python). Pierwszy projekt we 
fw. to rozpoznanie walką, trzeba mieć postanowienie niekontynuowania na 
siłę tego w razie nieoptymalnej decyzji. Zrobić coś dla swojego biura, 
niewymagającego wieloletniego supportu klienta itd. Np. do dziś uważam 
dobrze że pierwsze zabawy w J zrobiłem w Maverick (leciutki fw typu 
request/action, taka propedeutyka Strutsa) choć nie kontynuowałem - nie 
uważam za zmarnowany czas.

Myślę, że na 2-gi projekt trzeba by popatrzeć już mądrzej, czy bardziej 
dobra wędka czy smaczna ryba potrzebna itd. Ile tych ryb chcemy w ciągu 
roku itd.

Oczywiście w realiach umowy o pracę, szef kazał,  itd może to być inaczej ;)

Jacek Czerwinski wrote:
> zwykle wychodzi 2x (?) więcej linii, ale jak już się skompiluje, ma duże
hmm chocbym nie wiem jak naginal chlopakow w zespole to wychodzi okolo
15 - 16 razy wiecej.
Mowie oczywiscie o kodzie klepanym a nie z kreatorow czy np z Hibernate.

> Dostosowanie do koncepcji 'corpo' czyli podatność na bezpieczne łączenie
> różnych softwarów różnych dostawców przez wspólne standardy swoje
Z tym bezpiecznym laczeniem to takze mit.
Specyfika aplikacji ktore pisze wymusza niejako uzywanie roznych
serwerow aplikacyjnych. Tak chce klient i kropka.
Najwygodniej powiem szczerze dzialalo mi sie na Tomcacie - w miare
szybki development, 5-10 minut czekania (vs 1-2 sekundy w Pylons czy
czyms podobnym) i widzialem swoje zmiany na live. I wymagania pamieciowe
takze najmniejsze.
Klient zazyczyl sobie migracje wiec byl JBoss. Po sumarycznie kilkuset
godzinach pracy migracja skonczona. To nic ze w realu classloadery
ladowaly inny parser XML-s.
To podobno znany blad. Pomoglo zapoznanie sie z endorsed libs i voila.
Tylko to jednak taka migracja z tego samego w sumie na to same a koszt
ogromny. Kolejny problem - u klienta bedzie tylko OAS.
Wiec kolejna migracja. Problemy z watkami, timerami, w/w class
loaderami, logami, itd...
Slowo industrial w odniesieniu do Javy jest tak wielokrotnie powtarzane
ze ludzie zapomnieli chyba o genezie tego slowa w odniesieniu do tego
jezyka.
Nie umniejszam mu oczywiscie roli - we wprawnych rekach, duzym/ogromnym
kosztem da sie w tym zrobic cos bardzo sensownego.
Taka historyjka:
Kiedys pamietam znalazlem na smietniku kilkudziesieciostronnicowy
listing w Pascalu :) Powiem szczerze z nudow nauczylem sie wlasnie
Pascala z tego listingu.
Z racji ze kod byl idealnie napisany mniemam zw wg wiedzy autora po
prostu nie dalo sie zakodowac tego problemu lepiej.
Tak samo z punktu widzenia osoby ktora widzala tylko Jave na oczy i
twierdzi ze to jest idealne rozwiazanie.
Uszanuje taka decyzje gdy bede wiedzial ze jego opinia bedzie bazowala
przynajmniej w oparciu o kilka platform i jezykow programowania.

> robotnikiem programistą po standardowych egzaminach' również.
A to niestety jest bardzo duzy problem.
Przyjmowalem wiele osob do firmy w ktorej pracuje i znam mozliwosci
typowego kandydata. Duzo niestety zna Jave na poziomie Jan Bielecki albo
Thinking in Java. A za dodatkowy atut biora to ze lizneli PHP.

> Ja tam robie sobie weba bez w/w generowanych megabajtów.
Porownaj kod wygenerowany dla prostej aplikacji z paroma tabelami w
sytuacji kiedy mapujesz obiekty przez hbn-y.

> Ooo tu to mocny skrót myślowy. Jest wewnątrz środowisk javy mocna
Fakt, porownywanie frameworka do Javy ktore tutaj wynika jest
naduzyciem. Mi chodzilo raczej o typowe patterny wynikajace raczej z
promowania pewnych rozwiazan w Javie bez glebszej analizy po co to tak
na prawde potrzebne albo czy mozna inaczej.
Fakt jest jednak tez taki ze kiedy Java zabrala sie za XML-a ja
grzebalem sie dopiero z pierwszymi mocno nieudolnymi bibliotekami do
niego pod C++.

> opozycja antyxml-owa. Osobiście tworzę w Wicket fw który jest bez XML-i.
Wiem tez slyszalem o niej ale niestety zobacz jaki jest trend.
Nie chodzi mi o przechowywanie konfiguracji aplikacji bo to nie jest
problem. Chodzi mi o promowanie rozbudowanych rozwiazan zeby zabic muche
tj przeslac zwyklego int-a przez web service.
Javowiec zaklada cos w rodzaju: mamy serwer na ktorym dziala webservice,
generujemy "szybciutko" WSDL-a, wrapujemy go, o sa anotacje do tego ;),
uruchamiamy serwer i "szybciutko" zwracamy wynik.
Podczas gdy ja robie:
@jsonify
def wynik(self):
    return 1
a przesylany jest fizycznie tylko tyle ile na prawde potrzeba.

> Z kolei obecność XML w IoC, dynamicznym ładowaniu klas (EJB itd) troche
EJB w nowej wersji nie jest zly podobnie jak pare dosc fajnych rzeczy
jak np Struts :) Ale to juz inny swiat i tylko Javowy.

> ukrywajmy, może szokować rygorystów OOP.
A to fakt. W praktyce ja jako w sumie purysta C++ bo spedzilem z tym
jezykiem kilkanascie lat powiem ze ta akademicka hermetyzacja jest o
kant du... Bledy sa gdzie indziej co powie Ci kazdy tester :)

> Tego nie zrozumiałem. Znaczy poziom 'request' to dobrze czy żle?
Chodzi mi o taka kwestie ze typowy programista Javowy niestety zyje w
swiecie pstrokatych IDE i tak na prawde do konca nie wie jak to dziala.
Wiem ze to naduzycie ale biore opinie po ludziach z ktorymi pracuje.
W praktyce w aplikacji Javowej nie ma jakiejs automagii, tez sa
requesty, magiczna sesja to tak na prawde jakis slownik identyfikowany
po ciasteczkach itd

>> Bo w Javie to wszystko  bylo persistent albo industrial ;)
> Tu też nicht verstehen
A tutaj parafrazuje mojego kolege :)
Ale wez sobie byle jaki artykul o Jave (np nowy Software, tj DJ) i
poczytaj jakis artykul. 1/4 tekstu sklada sie wlasnie z takich slow.
Jak to odfiltrujesz zostanie tak na prawde niewiele ponad to co oferuje
kazdy inny jezyk z VB wlacznie.

> Z jednej strony zależy od serwerów (nie precyzujesz), z innej kawał tego
tak jak wyzej z zachowaniem nastepujacej kolejnosci:
tomcat < jboss < oas

> RAM-u to długotrwałe bufory i cache danych, czyli miejsce gdzie
Nawet rozbudowany memcache nie zbliza sie do polowy tego limitu.

> odzyskujemy to w postaci szybkości później.
Ehh na prawde ciezko mi to zauwazyc.
Wiem ze mowie troche z persektywy narzekacza ale to specyfika pracy
ktora wykonuje (bynajmniej nie narzekacz ;)).
W praktyce jednak mamy w swoich aplikacjach bardzo duzy problem z
wydajnoscia oraz zasobozernoscia. Fakt faktem ze jest pewna korelacja.
Tj lepiej jest uzywac gotowcow w stylu OAS-a bo jednak zintegrowany
system przeklada sie na sumaryczne lepsze wykorzystanie zasobow.

> najbardziej 'oczywistym' konkurentem czyli php.
hmm a co to porownywac :)

> I na pewno życzę Pythonowi w webie jeszcze lepszej pozycji niż ma.
Niestety to kolejna wada Pythona - marketing.
Smiem twierdzic ze gdyby Python zostal wynaleziony przez Sun-a i poszlo
w jego promocje tyle dudkow co do tej pory na JAve to nikt by tego
jezyka z mikrofalowek czy pilotow TV nie wydzieral :)
Malym pocieszeniem moze byc ostatnie poprawienie statysyk dzieki dosc
agresywnej promocji IronPythona przez MS oraz Pythona jako jezyk przez
okologooglowe otoczenie.

-- 
Pozdrawiam
Artur Lew
arturdotlewatgmaildotcom

Dnia 14-06-2009 o 17:40:06 Łukasz Mańkowski <Lukasz.Mankowski@gmail.com>  
napisał(a):

> Czy dobrze wnioskuję, że czegoś w stylu stronki php czy jsp/servlet w
> pythonie nie uświadczę ?

Jak chcesz tak, to też coś jest (choć te rozwiązania niespecjalnie się  
przyjęły):

http://spyce.sourceforge.net/
http://nick.borko.org/pse/

Ale najpopularniejsze jest Django, a najprostszy jest web2py  
(http://web2py.com/). Najpotężniejszy jest Zope3 (zobacz nadbudowany na  
nim framework Grok http://grok.zope.org/) Jest oczywiście świetny Plone -  
bardzo dobry CMS, choć technicznie rzecz biorąc, to "produktem" (plugin)  
do serwera aplikacyjnego Zope.

> No ale nie wykluczone też, że moja fascynacja językami
> na j wiąże się z tym że przez długi okres czasu chciałem być właśnie
> programistą javowym.

Skoro lubisz technologię JV... próbowałeś może webowy framework Lift[1] ?  
Jest bapisany w Scali[2]?  Scala jako język (nie licząc tego że jest  
szybszy i bardziej przezroczyście integruje się z bibliotekami Javy od  
Jython, czy JRuby) ma dużo większe możliwości. Można tworzyć biblioteki w  
użyciu wyglądające jak rozszerzenie języka (tak np. stworzono w Scali  
obsługę aktorów a'la Erlang) Ma silne wsparcie funkcyjne i pozwala na  
pisanie dużo bardziej zwartego kodu od Javy

Zobacz też zobacz http://blog.zabiello.com/2009/03/28/scala-lang.

[1] http://liftweb.net, darmowa książka online:  
http://groups.google.com/group/the-lift-book
[2] http://scala-lang.org


-- 
Jarosław Zabiełło
http://blog.zabiello.com

On 16 Cze, 11:49, "Jaroslaw Zabiello" <hipertrac...@dzimail.dot.com>
wrote:
> Dnia 14-06-2009 o 17:40:06 Łukasz Mańkowski <Lukasz.Mankow...@gmail.com>  
> napisał(a):
>
> Skoro lubisz technologię JV... próbowałeś może webowy framework Lift[1] ?  
> Jest bapisany w Scali[2]?  Scala jako język (nie licząc tego że jest  
> szybszy i bardziej przezroczyście integruje się z bibliotekami Javy od  
> Jython, czy JRuby) ma dużo większe możliwości. Można tworzyć biblioteki w  
> użyciu wyglądające jak rozszerzenie języka (tak np. stworzono w Scali  
> obsługę aktorów a'la Erlang) Ma silne wsparcie funkcyjne i pozwala na  
> pisanie dużo bardziej zwartego kodu od Javy
>
> Zobacz też zobaczhttp://blog.zabiello.com/2009/03/28/scala-lang.
>
> [1]http://liftweb.net, darmowa książka online:  http://groups.google.com/group/the-lift-book
> [2]http://scala-lang.org
>
> --
> Jarosław Zabiełłohttp://blog.zabiello.com

Zainteresowałeś mnie tym. Przyznam się, że wcześniej się z scala nie
spotkałem.
Jak z jego popularnością u nas w kraju ? Jakieś comunnity,
pracodawcy ??

Łukasz Mańkowski powiada:
> On 16 Cze, 11:49, "Jaroslaw Zabiello" <hipertrac...@dzimail.dot.com>
> wrote:
>> Scala jako język (nie licząc tego że jest szybszy i bardziej 
>> przezroczyście integruje się z bibliotekami Javy od Jython, 
>> czy JRuby) ma dużo większe możliwości. Można tworzyć biblioteki 
>> w użyciu wyglądające jak rozszerzenie języka (tak np. stworzono 
>> w Scali obsługę aktorów a'la Erlang) Ma silne wsparcie funkcyjne 
[...]
> Zainteresowałeś mnie tym. Przyznam się, że wcześniej się z scala 
> nie spotkałem. Jak z jego popularnością u nas w kraju ? Jakieś 
> comunnity, pracodawcy ??

Nijak, po prostu dla ewangelizatora nawet przeciążanie operatorów
znane jeszcze z c++ da się nazwać możnością tworzenia bibliotek 
w użyciu wyglądających jak rozszerzenie języka. Funkcyjna też Scala
nie jest, ale ,,silne wsparcie'' to postęp w stosunku do poprzednio
promowanego przez przedpiścę określenia pure FP (takoż niemal brak 
składni na podobieństwo lispa okazał się po sprawdzeniu 6 stronami 
opisu jak najbardziej klasycznej gramatyki z 40 słowami kluczowymi).
Języków jest zbyt wiele żeby uczyć się wszystkich, najważniejsze 
jest zapoznanie się z kluczowymi paradygmatami programowania
i najistotniejszymi (względem wpływu na styl pisania) ficzerami.

Piotr Sawicki

Dnia 17-06-2009 o 20:41:17 Piotr Sawicki <ps171721@students.mimuw.edu.pl>  
napisał(a):

> Funkcyjna też Scala nie jest

Ty tak na poważnie, czy jaja sobie robisz? Dlaczego uważasz że Scala nie  
jest funkcyjna?

-- 
Jarosław Zabiełło
http://blog.zabiello.com

Jaroslaw Zabiello pisze:
> Dnia 17-06-2009 o 20:41:17 Piotr Sawicki 
> <ps171721@students.mimuw.edu.pl> napisał(a):
> 
>> Funkcyjna też Scala nie jest
> 
> Ty tak na poważnie, czy jaja sobie robisz? Dlaczego uważasz że Scala nie 
> jest funkcyjna?
> 

Rozumiem, że jesteś "podjarany" nową zabawką ale to jest grupa 
pl.comp.lang.python i zwracam się z uprzejmą prośba abyście bawili się 
gdzie indziej.

-- 
Tomasz Drobiszewski

Luk6Man pisze:
> Witam
> Od niedawna zainteresowałem się pythonem, najbardziej interesuje mnie
> zastosowanie go do pisania aplikacji webowych. Czy ktoś mógł by pomóc
> i podać linki do jakiś dobrych tutoriali/dokumentacji z tej
> dziedziny ? Niestety poszukiwania przez google nie były zbyt
> efektywne. We wszystkich materiałach natykałem się na stwierdzenie, że
> mogę użyć albo cgi albo mod_python albo wsgi. O ile CGI odrzucam już
> na samym początku, to dalej mam wątpliwości. Nie wiem czy powinienem
> szukać więcej informacji na temat mod_python czy na temat wsgi.
> Idealne był by poradnik w stylu: 1. Zainstalują Apache ( jakiś inny
> serwer ??? ) 2. zainstaluj mod_python/mod_wsgi 3. <instrukcja w stylu
> hello wordl>

Na początek daj sobie spokój z Apche,Lighhtpd czy Nginx, Tomcat czy 
czymkolwiek innym, użyj serwerów wbudowanych we frameworki.

Najlepiej zacząć od Django bo ma duża i skutecznie działającą 
społeczność. Zainstaluj sobie Django. Napisz aplikację na podstawie 
tutoriala z oficjalnej strony projektu. Jak już poznasz ograniczenia 
Django możesz zacząć szukać czegoś innego - tylko wtedy już będziesz 
wiedział czego szukasz.


Jeśli chcesz napisać własny framework to przejrzyj sobie web2py. Jest 
najmniej skomplikowany i na dodatek ładnie napisany.

-- 
Tomasz Drobiszewski

Jaroslaw Zabiello powiada:

> Dlaczego uważasz że Scala nie  jest funkcyjna?

Jakby była funkcyjna to by jej podprogramy spełniały matematyczną 
definicję funkcji. A tak to ma liczne zapożyczenia z ML i Lispa,
podobne zresztą jak Python (choć pythonowskie są pozbawione
specjalnego wsparcia składni, np. currying jest dostarczony jawną
klasą). Natomiast wymyśloną na potrzeby scala advocacy definicję 
funkcyjności ,,Scala is also a functional language in the sense that 
every function is a value'' spełnia nawet makroasembler w stylu C.


Piotr Sawicki

Dnia 18-06-2009 o 15:15:22 Piotr Sawicki <ps171721@students.mimuw.edu.pl>  
napisał(a):

>> Dlaczego uważasz że Scala nie  jest funkcyjna?
>
> Jakby była funkcyjna to by jej podprogramy spełniały matematyczną
> definicję funkcji.

O co ci konkrenie chodzi? O to, że funkcja nie ma stanu ani efektów  
ubocznych? Przecież Scala umożliwia pisanie kodu w taki sposób. Aczkolwiek  
nie jest językiem "pure FP" w tym sensie, że Scala pozwala także na  
pisanie kodu w sposób imperatywny. Scala jest po prostu językiem  
hybrydowym FP + pure OOP. Nie tylko każda funkcja jest wartością, ale też  
każda wartość jest obiektem, stąd każda funkcja w Scali jest też obiektem.  
Już pomijam to, że Scala ma typowe dla języków funkcyjnych rozwiązania jak  
pattern matching, tail recursion, immutable (nie wiem jak to lepiej  
nazwać, vals?) pozwalające na pisanie kodu bez zmiennych, tak typowych dla  
podejścia imperatywnego.

> Natomiast wymyśloną na potrzeby scala advocacy definicję
> funkcyjności ,,Scala is also a functional language in the sense that
> every function is a value'' spełnia nawet makroasembler w stylu C.

Wymyśloną?? Żartujesz. Powszechnie przyjmowana def. FP jest określona np.  
tu http://en.wikipedia.org/wiki/Functional_Programming. Może masz swoją  
własną?

A jest w ogóle jakiś język który byś nazwał funkcyjnym??

-- 
Jarosław Zabiełło
http://blog.zabiello.com

Dnia 18-06-2009 o 15:15:22 Piotr Sawicki <ps171721@students.mimuw.edu.pl>  
napisał(a):

> A tak to ma liczne zapożyczenia z ML i Lispa,
> podobne zresztą jak Python (choć pythonowskie są pozbawione
> specjalnego wsparcia składni,

Python ma niewiele wspólnego z programowaniem funkcyjnym. Poza swoją  
słabiutką (bo ograniczoną do jednego wyrażenia) lambdą, to co ma? Nie ma  
pattern matching ani tail recursion, nie ma charakterystycznych dla FP  
immutable vars (nawet klasy nie mogą być final) ani nawet pełnych closures  
czy aktorów. Python nie jest językiem ani full OOP ani FP, to język  
obiektowo-proceduralny. Więc raczej nie ma co go porównywać.

-- 
Jarosław Zabiełło
http://blog.zabiello.com

W dniu 18.06.2009 16:56, Jaroslaw Zabiello pisze:

> immutable (nie wiem jak to lepiej nazwać, vals?) pozwalające na
> pisanie kodu bez zmiennych, tak typowych dla podejścia
> imperatywnego.

http://en.wikipedia.org/wiki/Single_assignment

Jaroslaw Zabiello powiada:

>>> Dlaczego uważasz że Scala nie  jest funkcyjna?
>>
>> Jakby była funkcyjna to by jej podprogramy spełniały matematyczną
>> definicję funkcji.
>
> O co ci konkrenie chodzi? 

O przezroczystość odwołań.

> O to, że funkcja nie ma stanu ani efektów ubocznych? 
> Przecież Scala umożliwia pisanie kodu w taki sposób. 

Praktycznie każdy język ogólnego zastosowania to umożliwia.
Jedne taki styl bardziej ułatwiają, inne mniej (Scala bardziej).

> Scala jest po prostu językiem  hybrydowym FP + pure OOP. 

Pure OOP też nie jest (wykonanie programu nie ogranicza 
się do przesyłania komunikatów między obiektami).

> każda wartość jest obiektem, 

Albo ma tożsamość albo nie.

> Już pomijam to, że Scala ma typowe dla języków funkcyjnych 
> rozwiązania jak pattern matching, tail recursion, immutable 

O zapożyczeniach pisałem. Tail recursion to nie cecha języka
tylko kompilatora, a stałe pojawiają się również w językach 
niefunkcyjnych. Natomiast pattern matching jest w rzeczy 
samej świetny - i kto go nie odróżnia od switcha ten trąba.

>> Natomiast wymyśloną na potrzeby scala advocacy definicję
>> funkcyjności ,,Scala is also a functional language in the sense that
>> every function is a value'' spełnia nawet makroasembler w stylu C.
>
> Wymyśloną?? Żartujesz.

Owszem, użyłem eufemizmu - tak naprawdę to ta definicja jest niemądra.

> Powszechnie przyjmowana def. FP jest określona np.  
> tu http://en.wikipedia.org/wiki/Functional_Programming. 
> Może masz swoją własną?

Podałem warunek konieczny (funkcja matematyczna) - na wiki
jest o nim mowa od razu w pierwszym zdaniu. Natomiast first
-class functions nie są tam bynajmniej podane jako warunek 
wystarczający (taki feature mają np. Algol czy Javascript). 

> A jest w ogóle jakiś język który byś nazwał funkcyjnym??

Rodzina ML na przykład, wskazałem przecież źródło zapożyczeń.


Piotr Sawicki

Piotr Sawicki pisze:
> Jaroslaw Zabiello powiada:
> 
> 
> Pure OOP też nie jest (wykonanie programu nie ogranicza 
> się do przesyłania komunikatów między obiektami).
> 

Pure OO nie mówi nic o komunikatach i według tej definicji nawet 
Smalltalk nie jest pure OO, bo umożliwia np definicję metody przez 
specjalną składnię. Każda wartość ma być obiektem i tyle.


>> A jest w ogóle jakiś język który byś nazwał funkcyjnym??
> 
> Rodzina ML na przykład, wskazałem przecież źródło zapożyczeń.
> 

Z innej beczki, Haskell też nie jest funkcyjny bo posiada monady i akcje ?

Scala posiada zbyt mocne wsparcie dla FP (i wcale nie musi być pure FP 
aby ją nazwać językiem funkcyjnym, NIE jest to wymagany ficzer, chodzi o 
wsparcie konkretnego paradygmatu) i dlatego zdecydowanie jest językiem 
funkcyjnym.

http://www.reddit.com/r/programming/comments/8kl8l/scala_is_not_a_functional_programming_language/

lopex

Jaroslaw Zabiello powiada:

>> A tak to ma liczne zapożyczenia z ML i Lispa,
>> podobne zresztą jak Python (choć pythonowskie są pozbawione
>> specjalnego wsparcia składni,
>
> Python ma niewiele wspólnego z programowaniem funkcyjnym. 
[...]
> Python nie jest językiem ani full OOP ani FP, to język  
> obiektowo-proceduralny. Więc raczej nie ma co go porównywać.

Jeśli nie chcesz zaprzeczać tezie, że python ma zapożyczenia
funkcyjne, to boksujesz się z chochołem zupełnie po próżnicy.

> Poza swoją słabiutką (bo ograniczoną do jednego wyrażenia) lambdą,

Możesz uściślić?

> to co ma? 

Np. filter/map/reduce (zgoda, słabe). Z rzeczy opisanych
w ,,A Tour of Scala'' jako cechy funkcyjne Scali, Python 
posiada funkcje pierwszoklasowe, anonimowe, wyższych 
rzędów, zagnieżdżane, currying i sequence comprehensions
(z całej listy brakuje tylko pattern matchingu, tu wtopa).

> nie ma charakterystycznych dla FP immutable vars 

Błąd: charakterystyczne dla FP jest to, że nazwy dla wartości
są tam tworami syntaktycznymi a nie semantycznymi. Zastrzeganie 
niemutowalności fragmentów pamięci występuje w różnych formach 
w wielu językach (Python też do tej koncepcji jakoś nawiązuje).

> (nawet klasy nie mogą być final) ani nawet 
> pełnych closures czy aktorów. 

Domknięcia nie są cechą wyłącznie języków funkcyjnych.
A klasy final i aktorzy to już całkiem inna bajka.


Piotr Sawicki

Marcin Mielżyński powiada:

>> Pure OOP też nie jest (wykonanie programu nie ogranicza 
>> się do przesyłania komunikatów między obiektami).
>> 
>
> Pure OO nie mówi nic o komunikatach [...]
>Każda wartość ma być obiektem i tyle.

Nie znam Twojej prywatnej definicji, ale skoro już przywołano
wikipedię, to nawet tam opisuje się OOP jako modelowanie
programu przy użyciu obiektów oraz ich interakcji.

> według tej definicji nawet Smalltalk nie jest pure OO, 
> bo umożliwia np definicję metody przez specjalną składnię. 

Nie potrafię dociec o jaką specjalną składnię Ci chodzi.
Metody się tam definiuje statycznie, runtime'u mogą najwyżej
dotyczyć domknięcia - ale one są w Smalltalku realizowane
właśnie poprzez przesyłanie komunikatów między obiektami.

> Z innej beczki, Haskell też nie jest funkcyjny bo posiada monady i akcje ?

Podałem warunek konieczny (na czystość funkcji) i Haskell go spełnia.

W monady widzę że się nie wgryzałeś, skoro uważasz je za specyficzną
cechę języka - monady to po prostu pewne abstrakcyjne struktury danych,
są możliwe do zbudowania w każdym języku wspierającym funkcyjność.
Haskell je ,,posiada'' jedynie w takim sensie, że są już w bibliotece
(głównie z powodów standaryzacyjnych, bo same definicje są krótkie
i proste), oraz dla zwiększenia czytelności istnieje specjalny lukier
syntaktyczny na dowiązywanie (a <- b c zamiast b c >>= \a ->).

Możliwość budowania struktur noszących ze sobą w garbie własny
stan nie psuje funkcyjności - bo efekty uboczne są pochowane 
w ogrodzonych konstrukcjach zamiast bełtać w globalnym środowisku
(kluczową różnicą jest rozstrzygalność tych problemów dla kompilatora). 
Oczywiście teoretycznie możliwe jest wpakowanie całego programu 
w monadę - ale na złość mamie odmrozić uszy zawsze się da, tak samo 
w Javie można pisać strukturalnie w jednym obiekcie z metodą run. 

> Scala posiada zbyt mocne wsparcie dla FP (i wcale nie musi być pure FP 
> aby ją nazwać językiem funkcyjnym, NIE jest to wymagany ficzer,

Nie twierdzę że musi być pure - tylko że język funkcyjny na 
początek powinien mieć prawdziwe funkcje, to chyba elementarne.

> dlatego zdecydowanie jest językiem funkcyjnym.
>
> http://[...]/scala_is_not_a_functional_programming_language/
                        ^^^
:) Przyznam że nie grokuję Twojego punktu. Pomyliłeś linki?


Piotr Sawicki

Ja chciałbym wrócić do źródłowego pytania i odpowiedzieć opisując
swoje doświadczenie.

1) Hostowanie: mod_wsgi vs mod_python
  Pod serwerem Apache wyszedł ciekawy problem z mod_pythonem. Obie
korzystają z pewnej biblioteki jednak najnowszy Apache :] używa
najnowszej jej wersji a najnowszy mod_python trochę starszej i na
najnowszej się segfaultuje :) Zaznaczam tylko problem :]
  Na tle tego wyłania się protokół WSGI, który jest rozwiązaniem nie
działającym aż tak w łonie serwer jak mod_python ale raczej
rozwiązaniem z tym serwerem się komunikującym. Ta odrębność bardzo
dobrze służy jego uniwersalności i jak widać stawia go w znacznie
lepszym świetle względem sprawiającego problemy mod_pythona

2) Od WSGI do frameworka
Kilka dni temu zacząłem pisać prosty skrypt WSGI w Pythonie, który
miał wypluć stronkę. Na początku stronka, potem stwierdziłem, że to
trochę syf więc zaimportowałem system szablonów Mako, aby móc
oddzielić logikę od prezentacji. Później okazało się, że muszę sobie
zarządzać końcówkami adresów URL czyli w sumie stworzyć takie mini
routes i w gruncie rzeczy po dni developerki wyszedł mi taki Pylons.
Gdybym zdecydował się jeszcze skorzystać z gotowych biblioteki jak
właśnie: Routes, Baker czy innych - to miałbym mojego własnego Pylons
a skoro tak to po co wymyślać koło na nowo ?
Szczerze mówiąc po tym doświadczeniu zastanawiam się czy tworzenie
skryptów w Pythonie na sucho w ogóle ma jakąkolwiek rację bytu i sensu
bo co by się nie chciało zrobić to zaczyna się robić własny framework.
Ciekawy temat na bloga swoim zdaniem :D Dziwne, że w PHP ludzie ze
znacznie większą lubością piszą skrypty na sucho a w Pythonie już po
dniu developerki zaczyna się widzieć pewien paradoks takiego
podejścia.

3) Materiały: Django, Pylons others...
W Polsce najwięcej materiałów znajdziesz o Django. Najlepszy (serio)
kurs Django z jakim kiedykolwiek się zetknąłem widziałem chyba na
webhosting.pl
Ponieważ w sercu jestem z jakiś przyczyn zwolennikiem modularności
polecam Pylons a przy tym swój poradnik do niego, który znajdziesz
tutaj: http://tiny.pl/vn2t

Pozdrawiam !
--
Jan Koprowski

On 27 Cze, 08:41, Jan Koprowski <jan.koprow...@gmail.com> wrote:

> routes i w gruncie rzeczy po dni developerki wyszedł mi taki Pylons.
> Gdybym zdecydował się jeszcze skorzystać z gotowych biblioteki jak
> właśnie: Routes, Baker czy innych - to miałbym mojego własnego Pylons
> a skoro tak to po co wymyślać koło na nowo ?

i to jest wlasnie normalne podejscie. uzywasz gotowych rozwiazan.
jesli potrzebujesz, to je rozszerzasz. w skrajnych przypadkach
rozwijasz soft 3rd-party wspolpracujac z autorami (bugfixes/features)

> Szczerze mówiąc po tym doświadczeniu zastanawiam się czy tworzenie
> skryptów w Pythonie na sucho w ogóle ma jakąkolwiek rację bytu i sensu
> bo co by się nie chciało zrobić to zaczyna się robić własny framework.

odpowiedz jest oczywista - nie ma sensu. pakiet/modul/klasa powinna
wykonywac tylko to, co do niej nalezy. dzieki temu mozesz zbudowac
swoje narzedzie z wielu malych "klockow", ktore ze soba zintegrujesz,
albo uzyjesz gotowych rozwiazan - pylons, tg, itd.

> Ciekawy temat na bloga swoim zdaniem :D Dziwne, że w PHP ludzie ze
> znacznie większą lubością piszą skrypty na sucho a w Pythonie już po
> dniu developerki zaczyna się widzieć pewien paradoks takiego
> podejścia.

Bo w php sie nie programuje, tylko (przepraszam za wyrazenie, ale nie
ma innego) nap***dala (mowie o produkcji duzego softu, nie stronki
html z osadzonym licznikiem). Rozwiazania dostarczane przez community
sa czesto zle opracowane i albo je przerabiasz, albo wkurzasz i
piszesz swoje (nie mowiac o problemach z konfliktami nazw klas). Jest
oczywiscie kilka rodzynkow, najczesciej sa to klony rozwiazan ze
swiata Javy.

> 3) Materiały: Django, Pylons others...
> Ponieważ w sercu jestem z jakiś przyczyn zwolennikiem modularności
> polecam Pylons

Uzywalem Pylons ze wzgledu na modularnosc. Zrazil mnie iloscia
konfiguracji do przygotowania i problemami z authkit.
Dlatego polecam raczej Turbogears2 - rownie modularny, opiera sie na
Pylons ale ma lepiej dobrany toolkit i nie wymaga tyle klepania kodu
(wprowadzili wiecej klas bazowych dla konfiguracji, kontrolerow)
Aczkolwiek w TG obecnie tez nic nie realizuje, bo mam bardzo malo
czasu, i wszystko prototypuje w Django.

Marcin Nowak

marcinn pisze:

> 
>> 3) Materiały: Django, Pylons others...
>> Ponieważ w sercu jestem z jakiś przyczyn zwolennikiem modularności
>> polecam Pylons
> 
> Uzywalem Pylons ze wzgledu na modularnosc. Zrazil mnie iloscia
> konfiguracji do przygotowania i problemami z authkit.
> Dlatego polecam raczej Turbogears2 - rownie modularny, opiera sie na
> Pylons ale ma lepiej dobrany toolkit i nie wymaga tyle klepania kodu
> (wprowadzili wiecej klas bazowych dla konfiguracji, kontrolerow)
> Aczkolwiek w TG obecnie tez nic nie realizuje, bo mam bardzo malo
> czasu, i wszystko prototypuje w Django.

Miałem bardzo podobnie, Django rządzi jeśli chodzi o technikę 
prowadzenia prowadzenia projektu "deadline is coming soon" ;-)
W 99% przypadków jeśli wydaje mi się, że nie można czegoś zrobić w 
Django to znaczy, że projekt był  przekombinowany a funkcjonalność wydumana.

Django nie nadaje się tam gdzie jest potrzebna integracja z już 
istniejącymi rozwiązaniami bo monolityczność frameworka daje się mocno 
we znaki :-(.

-- 
Tomasz Drobiszewski

On 29 Cze, 09:40, Tomek <to...@wp.pl> wrote:

> > Aczkolwiek w TG obecnie tez nic nie realizuje, bo mam bardzo malo
> > czasu, i wszystko prototypuje w Django.

> Miałem bardzo podobnie, Django rządzi jeśli chodzi o technikę
> prowadzenia prowadzenia projektu "deadline is coming soon" ;-)

zwykle prototyp staje sie finalnym produktem i jedynie musze robic
drobne korekty oraz zajac sie wsparciem produktu.
to znaczy tyle, ze rozwiazania standardowe sa wystarczajaco dobre.

> Django nie nadaje się tam gdzie jest potrzebna integracja z już
> istniejącymi rozwiązaniami bo monolityczność frameworka daje się mocno
> we znaki :-(.

integracja na poziomie kodu jest faktycznie trudniejsza, ale nie
zawsze konieczna.
ja integrowalem projekt django z produktem napisanym w php.
wystarczyło przygotować api zdalnych usług.

jednak mam opór przed użyciem django do zastosowań enterprise -
najbardziej drażni mnie słaby mechanizm persistence.


marcin