Witam
Tak sie zastanawiam w jakich jezykach sa pisane duze serwisy typu myspace.com, youtube.com, bbc.co.uk, onet, wp, itp
W php? asp.net?
i czy w ogole oplaca sie jeszcze uczyc php, czy to jezyk z przyszloscia? Jak widać ofert pracy dla programistów php co raz mniej...
facebook - php.
gazeta.pl - java
onet.pl - java
yahoo.com - php
Co rozumiesz przez duże?
youtube - python
myspace - zdaje sie asp.net
// źle Ci się zdaje, myspace to coldfusion - Ł
Witam
http://www.orange.pl/ -Java i spółka.
http://www.playmobile.pl/ .NET ( z tego co słyszałem).
Co do PHP to niestety nie słyszałem o wielu bardzo złożonych serwisach opartych na tej technologii jakkolwiek nie zauważyłem aby było coraz mniej ofert pracy dla programistów PHP.
pzdr
http://www.itjobswatch.co.uk/jobs/uk/php.do
Widać liczba ofert pracy dla programistow php wyglada marnie do c#/c++/.net, dlatego jej sens sie uczyc php(dopiero zaczynam) czy lepiej dac sobie spokoj i zaczac sie uczyc c #/++ czy cos innego?
pinger.pl, wrzuta.pl, mixer.pl, proca.pl, najauto.pl, prawie wszystko ze stajni o2 to php, wszelakie ogame, darkpirates i inne gry Gameforge(większość) - php
Ja bardziej bym byl zainteresowany rozwiazaniami uzywanymi przez takie serwisy :) Typu gazeta.pl, wp.pl. Jakie wzorce stosuja, jak wyglada kod, baza danych (technologia oraz rozplanowanie).
BTW: ma ktos fragmenty kodu zrodlowego facebooka ktory wyciekl? Chetnie bym zobaczyl.
zareklamuję coldfusion - niby nikt o tym języku nie słyszał, a używa go mnóstwo witryn: strony unii europejskiej, amazon, myspace, canon, dhl, kodak, nike, casio, dell, hp, stepstone, heineken, siemens, symantec, boeing, caterpillar, goodyear, us bank, pepsi...
@Adam - zdziwiłbyś się niektórymi rozwiązaniami... często za dużymi stronami stoi nie dobrze dopracowany kod, tylko mnóstwo kasy wsadzonej w serwery (będącej mimo to ułamkiem procenta obrotu firmy).
PawelW napisał(a)
http://www.playmobile.pl/ .NET ( z tego co słyszałem).
Nie wygląda na .NET
W ASP.NET to np. http://www.lego.com i https://www.mbank.com.pl oraz oczywiście http://www.codeguru.pl
Jeszcze www.asp.net jest w ASP .NET :)
na tej stronie jest lista najwiekszych serwisów w ASP .NET: http://asp.net/get-started/
microsoft.com też jest w asp.net
Duże kawałki Google to Python
Wykop.pl to PHP
Blip.pl to Ruby
Grono to Python
Twitter to Ruby
Fotka.pl to PHP
Nasza-klasa to też PHP.
A odnośnie działania dużych serwisów:
http://antyweb.pl/jak-zabic-pana-gabke-czyli-o-wydajnosci-slow-kilka/
http://antyweb.pl/zabijamy-pana-gabke-zawodowo-wraz-z-fotkapl/
http://antyweb.pl/mordowanie-pana-gabki-ciag-dalszy/
http://itblog.grono.net/
i świetne wpisy na blogu: http://talen.jogger.pl/kategoria/duze-portale/
Grono.net - python (django)
onet nie tylko java ale rowniez asp
Grono to chyba kiedyś w jsp było, ale nie dali chłopaki rady. MBank stoi na asp (nie .net). Słyszałem, że sporo serwisów internetowych banków w asp.net stoi, ale sam mam konto tylko w jednym więc nie wiem.
PLAY, portal mobilny (w przygotowaniu) - Java J2ME i J2EE
Witcher (duelmail) - Flash + Java
Empik - stanowiska odsłuchowe są we Flashu + backend Java
Odnośnie tych dużych kawałków Googla w Pythonie, to bym miał wątpliwości.
Większośc aplikacji webowych np. gmail jest na GWT (Java).
DzieX napisał(a)
MBank stoi na asp (nie .net).
Takie pytanie (pewno naiwne) z mojej strony. Jakiś czas temu były rozszerzenia asp, teraz są aspx. Nie świadczy to o asp.net?
Wszystkie z tu wymienionych mają duże społeczności. PHP na pewno.
Natomiast pytanie było o DUŻE serwisy.
Moim zdaniem opieranie dużego serwisu na czymś takim jak PHP jest nieporozumieniem, chyba
że jest to jedyny język znany przez twórców i nie mają czasu nauczyć się czegoś innego.
Po prostu przy pewnej skali przedsięwzięcia PHP okazuje się bardzo ograniczone przy ASP.NET / J2EE:
W przypadku Rubyego (zarąbisty język) jest dużo lepiej, ale:
@Krolik z Rubym nie do końca jest tak z prędkością. Można go skompilować do Java Byte Code i ruszać na JVM lub użyć JRuby, czyli javowego interpretera, który dynamicznie zamienia to ja JBC.
Przypomnę tylko, że nadchodzące Ruby 2.0 dostaje wreszcie sensowne VM, z wydajnością będzie całkiem nieźle. Minusem zaś jest brak kompatybilości wstecznej, trochę mechaniki jednak zmieniono.
p.s. i kolejny raz zachęcam do poznany Rubiego, innego tak kochanego języka skryptowego po prostu nie ma.
Teoretycznie tak, ale problem jest w tym, że Java do wersji 6 włącznie nie wspiera czegoś takiego jak invokedynamic. Ogólnie JVM nie było projektowane z myślą o takich językach. Na razie JRuby jest niewiele, jeśli w ogóle cokolwiek szybszy od klasycznego interpretera Rubyego napisanego w C - przynajmniej tak wynika z paru blogów, które czytałem (ale sam nie sprawdzałem jeszcze).
mephir napisał(a)
pinger.pl, wrzuta.pl, mixer.pl, proca.pl, najauto.pl, prawie wszystko ze stajni o2 to php, wszelakie ogame, darkpirates i inne gry Gameforge(większość) - php
Błąd:
pinger.pl - python
wrzuta.pl - C
mixer.pl - php
TomaszSmykowski napisał(a)
Krolik
Nie zgadzam się z tymi punktami:
- kiepska wydajność interpretera
Sam fakt, że PHP jest interpretowane już sprawia, że masz 10x do tyłu względem języków kompilowanych do kodu maszynowego (C++, C#, Java). Nawet przy buforowaniu bytecodu.
- trudne buforowanie różnych rzeczy - jeszcze gorsza wydajność
Skrypt się uruchamia, działa i kończy. A wraz z końcem znikają wszystkie jego dane z pamięci.
Nawet zmienne sesyjne trzeba zapisywać na dysku. Istnieją rozwiązania oparte o pamięć współdzieloną, ale napisałem: trudne, nie niemożliwe.
- trudniejsze debugowanie
Debugowanie to nie tylko kwestia dostępności debuggera. Jak poleci błąd w skrypcie php, dostaniesz ładny stacktrace jak w Javie? Czy enigmatyczny komunikat z JEDYNIE numerem linii?
- mniejsza czytelność kodu - brak jawnej spec. typów
Weź kod jakiejś funkcji ze środka większego systemu, którego nie pisałeś,
i spróbuj zrozumieć, co oznaczają argumenty, jeśli autorowi nie chciało się napisać komentarzy.
A nawet jeśli są komentarze, nie da się sensownie zrobić podpowiadania składni w IDE. No bo skąd IDE ma wiedzieć, co podpowiadać, jak nie zna typu obiektu?
- brak jakiegokolwiek wsparcia dla aplikacji rozproszonych / zrównoleglania
Jest jakiś odpowiednik RMI? Można wygenerować sobie klienta webserwisu na podstawie WSDLa?
Można wrzucić aplikację na jeden węzeł klastra i zmiany się rozpropagują automatycznie?
Można przetwarzać komunikaty asynchronicznie z wykorzystaniem puli wątków i przy zachowaniu ACID?
// dopisane:
www.filmweb.pl - Java
TomaszSmykowski napisał(a)
Krolik
Nie zgadzam się z tymi punktami:
- kiepska wydajność interpretera
- trudne buforowanie różnych rzeczy - jeszcze gorsza wydajność
- trudniejsze debugowanie
- mniejsza czytelność kodu - brak jawnej spec. typów
- brak jakiegokolwiek wsparcia dla aplikacji rozproszonych / zrównoleglania
Reszty nie zdazylem jeszcze zweryfikowac ;)
Polecam lekturę tych linków:
http://www.plentyofcode.com/2007/07/j2ee-vs-aspnet-vs-php.html
Stronnicze porównania (na korzyść ASP.NET):
http://www.promoteware.com/Module/Article/ArticleView.aspx?id=10
http://www.sitepoint.com/article/v-php-top-6-reasons-use-net
http://www.sitepoint.com/article/php-top-10-net-myths-exposed
Polecam wykonanie następujących zadań:
i zweryfikowanie swojej weryfikacji.
Krolik napisał(a)
- trudniejsze debugowanie
Debugowanie to nie tylko kwestia dostępności debuggera. Jak poleci błąd w skrypcie php, dostaniesz ładny stacktrace jak w Javie? Czy enigmatyczny komunikat z JEDYNIE numerem linii?
http://pl.php.net/manual/pl/function.debug-backtrace.php
+
http://pl.php.net/manual/pl/function.set-error-handler.php
Dają niezłe możliwości. Poza tym obsługa wyjątków i fakt, że PHP jest interpretowany pozwalają na rozwijanie na ich rozwijanie.
Natomiast to co na pewno można zarzucić tej technologii to słaba obiektowość i dość zamotane wskaźniki.
Krolik napisał(a)
Sam fakt, że PHP jest interpretowane już sprawia...
PHP jest kompilowane w locie i potem 'maszyna wirtualna' go wykonuje. widzialem kiedys nawet projekt JIT'a na maszynowy dla PHP, ale to bylo dawno i nie wiem co sie z nim faktycznie stalo..
Skrypt się uruchamia, działa i kończy. A wraz z końcem znikają wszystkie jego dane z pamięci.
Nawet zmienne sesyjne trzeba zapisywać na dysku
zupelnie jak w asp.net! pierwszy lepszy tutorial asp'a pokazuje jak korzystac z viewstate oraz sesji in-memory i in-database. viewstate=input/hidden na formularzu (proste w PHP), in-database nie trzeba opisywac (w php proste) gorzej z in-memory, ale tez sie da i nie tak trudno
Debugowanie to nie tylko kwestia dostępności debuggera. Jak poleci błąd w skrypcie php, dostaniesz ładny stacktrace jak w Javie? Czy enigmatyczny komunikat z JEDYNIE numerem linii?
oj, widze ze w php chyba nie bawiles sie nigdy rzeczami niskopoziomowymi.. jedna z pierwszych rzeczy jakie zrobilem to bylo dodanie ladnego parsera wyjatkow - stack trace+podglad parametrow. zajelo paredziesiat lini. masz w Javie/Aspie komunikat bledu ze stracktracem i mozliwoscia podejrzenia co bylo w parametrach wywolania metody w 30stej ramce ? :)
Weź kod jakiejś funkcji ze środka większego systemu, którego nie pisałeś,
i spróbuj zrozumieć, co oznaczają argumenty, jeśli autorowi nie chciało się napisać komentarzy.
A nawet jeśli są komentarze, nie da się sensownie zrobić podpowiadania składni w IDE. No bo skąd IDE ma wiedzieć, co podpowiadać, jak nie zna typu obiektu?
punkt. ale to punkt w odwiecznej batalii miedzy luzna/silna typizacja, wiec moze pozostawmy na boku
Jest jakiś odpowiednik RMI? Można wygenerować sobie klienta webserwisu na podstawie WSDLa?
Można wrzucić aplikację na jeden węzeł klastra i zmiany się rozpropagują automatycznie?
Można przetwarzać komunikaty asynchronicznie z wykorzystaniem puli wątków i przy zachowaniu ACID?
rmi - nie tyczy sie aplikacji webowych, tylko komunikacji miedzyprocesowej/aplikacyjnej. bacz ze PHP sluzy do pisania stron, rzeczy ala rmi sa bardziej general-purpose..
klient WS - nie mialem potrzeby, ale glowe dam ze juz ktos to napisal
propagacja zmian - to mowimy w koncu o jezyku czy o architekturze/jakosci farm serwerow? to ze (nie?)ma takiej opcji na obecnych farmach z PHP to ulomnosc tych farm a nie jezyka/platformy. to tak jakbys mowil ze Java jest fajniejsza niz C++ bo Eclipse pozwala Ci wskazac gdzie ma umiescic wyniki kompilacji a makeall nie..
ostatnie - niespecjalnie widze do czego multithreading bylby w php potrzebny
to tak jakbys mowil ze Java jest fajniejsza niz C++ bo Eclipse pozwala Ci wskazac gdzie ma umiescic wyniki kompilacji a makeall nie..
Skoro mówimy o praktycznych zastosowaniach języka to przykład, który podałeś jak najbardziej przemawia na korzyść Javy. Dyskusja, który język jest lepszy biorąc pod uwagę tylko jego składnie + wewnętrzene mechanizmy jest raczej akademicka.
<font size="3">dyskusja nie jest na ten temat! </span>
Koziołek, Królik - duet od pieprzenia o Javie już w drugim wątku, kiedy nikt ich o zdanie nie pyta.
Dokładnie tak samo flame'owaliście w wątku, w którym gość pytał o popularność C, a wy wsadziliście tam swoją javę, zaczynając największy offtop-flame, w ciągu ostatnich miesięcy.
Wierzę, że się znacie na Javie którą kochacie i ubóstwiacie, ale o reszcie macie nikłe pojęcie, w dodatku najpewniej świadomie manipulujecie tym, co wam wiadome, coby wyszło na wasze, że "Java jest najlepszym językiem na świecie" (czy jakoś tak to szło)
po kolei,
- brak puli połączeń z bazą danych
zajrzyj do PECL, kiedykolwiek zaglądałeś?
- bardzo słabe frameworki do mapowania O/R
- brak frameworków do IoC
bzdura tak wielka, że tylko google mogę polecić
- kiepska wydajność interpretera
która, jak jesteś taki ekspert, ma najmniejszy wpływ na wydajność dużych serwisów, prawo Amdahla znasz?
Sam fakt, że PHP jest interpretowane już sprawia że masz 10x do tyłu względem języków kompilowanych do kodu maszynowego (C++, C#, Java).
OMFG! to teraz Java latająca na VM nagle do kodu maszynowego jak C++ jest kompilowana? Nawet nie wspominaj o JIT, nic to nie ma do kuriozalnego wrzucenia C++ do tego samego worka co C# i Java.
- trudne buforowanie różnych rzeczy - jeszcze gorsza wydajność
dla ciebie trudne, bo nie masz pojęcia o języku. znowu, taki idiotyzm, że nawet mi się nie chce pisać więcej niż: książkę George'a Schlossnagle - książka elementarna, 100 stron o buforowaniu na wszystkie sposoby
Skrypt się uruchamia, działa i kończy. A wraz z końcem znikają wszystkie jego dane z pamięci.
Nawet zmienne sesyjne trzeba zapisywać na dysku.
Znowu chyba o PECL nie słyszałeś, jest multum rozwiązań, które to rozwiązują w PHP szybko prosto i przyjemnie. Nic w tym dziwnego - napisanie takiego modułu do Zend to mniej niż 100 linii w C, więc się mądrzy ludzie za to dawno zabrali. Znowu w elementarnym podręczniku jest o tym mowa.
- trudniejsze debugowanie
Jak poleci błąd w skrypcie php, dostaniesz ładny stacktrace jak w Javie? Czy enigmatyczny komunikat z JEDYNIE numerem linii?
j/w - dla ciebie trudne, bo nie masz pojęcia o języku. Oczywiście, że jest dostęp do stacktrace. Ślad wywołań można śledzić zarówno przy otrzymaniu błędu interpretera PHP, jak i przy wyjątkach rzuconych w przestrzeni użytkownika. Czy wspominałem już może o podstawowej książce George'a Schlossnagle?
- mniejsza czytelność kodu - brak jawnej spec. typów
idiotyzm z której strony by nie patrzeć. Z jednej strony, głupotą do potęgi jest zarzucanie językowi z dynamicznym typowaniem, że nie ma statycznej kontroli typów argumentów... Z drugiej: funkcje builtin mają specyfikacje określane, w podpowiadaniu składni można używać. Funkcje użytkownika oczywiście mogą specyfikować typy argumentów, i jak będzie niezgodność, to poleci błąd. Jezu, czyli się da, nawet w dynamicznym! Ale to trzeba COKOLWIEK wiedzieć o czym się mówi.
- brak jakiegokolwiek wsparcia dla aplikacji rozproszonych / zrównoleglania
taki brak, że znowu podręcznik elementarny poświęca aplikacjom rozproszonym ponad 100 stron.
- są jakieś frameworki do tworzenia stron z komponentów porównywalne z JSF?
nie mam pojęcia, nie znam JSF, w zamierzeniu miało to być pewnie pytanie retoryczne, ale w zestawieniu z twoją znajomością języka, można to chyba tylko traktować jako dodatkową nieznajomość frameworków dla PHP(nic dziwnego, skoro go nie używasz)
- jak w tym robić porządne unit testy z mockami?
boże, znowu podstawy? no fakt, tylko jeden rozdział jest o unit testach, och ach. Niemniej gwarantuję, że po jego przeczytaniu nie powinieneś mieć żadnych problemów z napisaniem własnego systemu, systemy zresztą są gotowe, wystarczy 1 minuta w google!!! (dopisane: i mówię tu oczywiście o unit testach z mockami właśnie)
Koziołek: 3/4 twoich "polecanych zadań" jest omówiona... czekaj, czyżby w nieśmiertelnym elementarnym podręczniku? A jednak, są.
Moja odpowiedź i Koziołka jest na temat, bo temat był o tym jakie języki stosować do dużych serwisów.
Więc dyskusja C#/Java vs PHP w kontekście dużych serwisów jest jak najbardziej w temacie.
Jako duże rozumeim duże nie tylko w sensie ilości danych (np. obrazków / stron), ale też złożone w sensie logiki biznesowej.
Odnosnie mocków, Ranides - punkt dla Ciebie.
Wprawdzie ten framework nie jest tak zaawansowany jak frameworki dla Javy (m.in. brak kontroli typów, brak matcherów dla argumentów, nie dopatrzylem sie też wyjatkow), ale i tak nieźle. Zresztą podobnie jest z pozostałymi rzeczami. Jak się długo poszpera, to owszem znajdzie się odpowiedniki w PHP, ale one są o klasę słabsze niż to co dostepne w C#/Java. Np. obsługa XML też jest, ale zaraz... a gdzie walidacja XMLSchema i DTD? Pooling połączeń baz danych? No jak to? Przecież też jest! Można mieć pule składającą się z JEDNEGO połączenia :D Notanene w PECL jakoś puli połączeń nie znalazłem... Wystarczy tez poczytać posty na php.pl, żeby zobaczyc, że np. goście, którzy spróbowali kiedyś coś robić w Hibernate jakoś nie chcą wracać do PHPowego Propela.
Odnosnie stosowania innych frameworków (np. MVC, lub czegoś w stylu JSF co być może istnieje), to jest jeszcze jeden DUŻY problem natury architektonicznej, wynikający z modelu wykonawczego PHP:
Wczoraj dostałem do rozwiązania problem z pewnym portalem pisanym w PHP, który ma 10 tys. użytkowników (pikuś, nie?), a pojedyncza strona ładuje się w 30-60 sekund (tak! sekund!). Nie wiem jeszcze co tam skopali, raczej nie jest to wina PHP, ale pierwsze co mi się rzuciło w oczy, to że index.php includuje kilkadziesiąt plików jakiegoś obiektowego frameworku MVC. Czyli przy każdym żądaniu system musi przynajmniej sparsować te kilkadziesiąt plików, mimo że nie wywołuje pewnie nawet 1/10 tamtejszego kodu.
Im więcej frameworków i ładnych rozwiązań w swoje skrypty upchniesz, tym większy narzut na ładowanie tych wszystkich klas per request. Nawet stosując cuda wianki z buforowaniem itp i tak czas przetwarzania requesta rośnie proporcjonalnie do wielkości systemu. W Javie/C# tego problemu nie ma - wszystko ładuje się raz na początku.
Nie mam osobiście niec do PHP, sam używam w mniejszych zastosowaniach, ale uważam, że do dużych serwisów jest to gorsze rozwiązanie niż C# czy Java.
BTW. Javę i C# wrzuciłem do tego samego worka co C++, bo w sensie wydajności na serwerze to jest to ta sama liga. O JITted PHP proszę nie mówić, bo ta technologia jest w powijakach [1] Na razie PHP jest na tym poziomie co Java w trybie interpretowanym i to też tylko jeśli zainstaluje się opcode cache.
[1] "The code is definitely not production quality." - http://www.mare.ee/indrek/jphp/
@Koziołek - Twój przykład z wyznacznikiem jest trochę niefortunny. Kto liczy wyznaczniki w serwisach internetowych? ;-)
No, herbatki z hibiskusa sobie łyknąłem, przeczytałem twojego posta i widzę, że jednak normalny poziom może utrzymamy, bez propagandy znaczy. Hm, z tym PECLem się zagalopowałem, bo zarządzanie pulami to faktycznie czytałem szkic realizacji (w wakacje i tak mam zamiar się porządnie Zendem zająć, to może ten szkic zrealizuję osobiście) - gotowego natywnego wsparcia na oficjalnej witrynie nie ma, trochę żal :/
Dyskusja może w tym sensie niepotrzebna, że przez pytanie zrozumiałem chęć poznania realnych zastosowań, komu chce się czytać walki zwolenników jednego lub drugiego i dyskusje 'na sucho'. Realnie najbardziej obciążone serwisy polskie, które tu zresztą wymieniono (nasza klasa, wykop, fotka) wyciągają na PHP, żaden z autorów nie narzeka, nie zapowiada też migracji na C# / Javę w związku z wydajnością. Więc teza, że Java powala PHP na kolana przy dużych serwisach to duża przesada. I mówienie, że PHP brać tylko, jeśli się nie da Javy to hmm... populizm, nie czarujmy się.
Nie wymieniono ogromnego serwisu, jakim jest Wikipedia - duży pod względem danych, ilości odsłon, w sumie logiki też, bo ich system Wiki jest mocno rozbudowany - działa na standardowym LAMP, i to działa ślicznie.
Frameworki dla Javy, generalnie prawda - SĄ lepsze, ale moloch Symphony też jest kochany. I kilka innych aktywnych, których używają nie tylko amatorzy też jest.
O ile narzut z parsowaniem jest eliminowany przez kompilator do byte'codu, to narzut z include'ami dalej zostaje - prekompilator go nie uniknie, bo include to nie jest preprocesor jak w C!, czyli każdy include musi być sprawdzony, czy go już prekompilowano, i dopiero jego kod - nie źródło - może być dołączony.
To jest powód, dla którego w PHP nie sprawdza się "przemodularyzowany" projekt - jeden plik na klasę w PHP to faktycznie morderstwo. Dobrze napisane autoloadery mogą trochę poprawić sytuację, ale tylko trochę. Tutaj racja więc w 100%. Tutaj chyba najbardziej obciąża nie tyle duży rozmiar kodu w 1 pliku, co lawinowe sprawdzanie kilkudziesięciu małych.
Generalnie, to ja PHP nie cierpię jako języka, bo jest w nim okropny burdel: i w języku, i w implementacji Zend, i w tej wielkiej społeczności, która nie potrafi się skonsolidować, co sprawia, że "każdy Kowalski tworzy swojego frameworka".
Po prostu znowu agitujecie, przekłamujecie. No, ostatni post masz bardziej stonowany, uczciwszy w porównaniu z początkiem, i z tego się cieszę. PHP to gorszy wybór niż Java? Subiektywnie może tak, jeśli ktoś np jest przyzwyczajony do języków statycznie typowanych, albo chce liczyć wyznaczniki 100x100. Ale nie jest to zły wybór, nie jest to rzadki wybór, nie prowadzi on też to żadnej katastrofy, jak można byłoby myśleć po tekście zwyczajnie wprowadzającym w błąd:
Moim zdaniem opieranie dużego serwisu na czymś takim jak PHP jest nieporozumieniem, chyba
że jest to jedyny język znany przez twórców i nie mają czasu nauczyć się czegoś innego.
w takim wypadku nieporozumieniem byłyby np niemal wszystkie strony ściśle związane z ruchem GNU, ponieważ opierają się na LAMP.