Rafał na moje pytania odpowiedział bardzo konkretnie, bardzo szczegółowo i dodał również wiele ciekawych informacji o tym jak zbudowana jest fotka.pl od środka. Mimo, iż tekst jest dość długi to jednak dla każdego kto chce dowiedzieć się wielu ciekawych informacji na temat walki z wydajnością będzie on z pewnością bardzo ciekawy i pouczający.
Czy tak zwana “wydajność” to duży procent w budżecie takiego serwisu jak twój?, jak dużo wydajesz na utrzymanie infrastruktury (mogą to być przybliżone kwoty lub widełki)
Z biegiem czasu na infrastrukturę wydajemy proporcjonalnie coraz mniej pieniędzy. Oczywiście ilość potrzebnych serwerów i łącz ciągle rośnie, ale przychody Fotka.pl zwiększają się zdecydowanie szybciej. W tej chwili myślę, ze koszty te nie przekraczają 20% przychodów. W ciągu roku chcemy zejść do poziomu 10% – to branżowy standard. Warto tu zauważyć, że rozwijamy infrastrukturę w większym komforcie niż 2-3 lata temu. Nie kupujemy już sprzętu potrzebnego “na wczoraj”, ale z wyprzedzeniem i w ilościach pozwalających nie martwic się o to, na jakie funkcjonalności w serwisie możemy sobie pozwolić, a na jakie jeszcze nie.
Jak radzisz sobie z utrzymanie odpowiedniej wydajności serwisu, czy zatrudniałeś (zatrudniasz) specjalistów w tej dziedzinie?
W elblaskim biurze mamy cale IT w tym 5 administratorów, kilku programistów i Andrzeja, który od początku istnienia serwisu dba o to, żeby wszystko działało jak należy. Cala wiedza na temat utrzymywania takiego dużego serwisu jest efektem wewnątrz firmowej pracy nad optymalizacja. To setki godzin podczas których sprawdziliśmy na żywym organizmie dziesiątki rozwiązań – tego nie da się wyczytać z prezentacji dostępnych w sieci.
Czy w tych czasach (dostępnych technologii i taniejących serwerów, łączy itp) wydajność może być permanentnym problemem – czy też powinna być rozwiązywana wraz z “kolejną dostawą serwerów”
Serwery i łącza już jakiś czas temu przestały być problemem. Nie trzeba inwestować dużych pieniędzy na starcie – można wynająć serwery w zachodnich datacenter wraz z łączami w przyzwoitej cenie zamiast zamawiać “kolejna dostawę serwerów” do swojej kolokacji. Do tego dostępność sprzętu została skrócona do kilku godzin /duże datacenter w USA/ lub nawet minut /odpalenie zwirtualizowanego serwera na Amazon EC2/. Problemem nie jest wiec sprzęt i łącza ale rozwiązania. O ile serwowanie obrazków można wydzielić do zewnętrznej firmy, o tyle sam serwis WWW trzeba utrzymywać samemu co przy dużej skali staje się problematyczne. Jest, bowiem duża różnica miedzy infrastrukturą złożoną z kilku, kilkunastu maszyn, a ta liczoną w setkach czy tysiącach. Pewne elementy serwisu jak bazy danych są trudno skalowane i kluczem do rozwiązania problemu jest nie tylko odpowiednie zastosowanie dostępnych narzędzi, ale tez wiedza i zdobyte doświadczenie. Jeśli ktoś tej wiedzy nie posiadł to rzeczywiście może mięć permanentny problem, bo skalowanie to nie jest zwykle dodawanie kolejnych klocków – najpierw trzeba wymyślić w jaki sposób te klocki powinny współgrać.
Serwery Fotka.pl
Twitter to już chyba symbol problemów z dostępnością serwisu internetowego w tych czasach – co według Ciebie może być główną przyczyną tych problemów i jaka kwota pieniędzy powinna je definitywnie rozwiązać?
Odpowiedz jest prosta i skalda się tylko z 3 liter: RoR. Ruby to coraz popularniejszy i “modny” język ale jego wydajność i skalowalność nadal pozostawia wiele do życzenia. W porównaniu do konkurencyjnej kombinacji czyli Python i framework Django to znacząca różnica. Oczywiście znajda się tacy, którzy powiedzą, że to tylko wina kiepskich programistów, a nie języka jednak nie da się zaprzeczyć, ze nawet DHH /twórca Ruby on Rails/ do niektórych swoich projektów uzywa PHP bo uznaje to za lepsze rozwiązanie. W przypadku Twittera nie winiłbym ani administratorów /nawet świetny nie zdziała cudów musząc optymalizować nieprzemyślane oprogramowanie/ ani Joyent /to do niedawna ich firma hostingowa udostępniająca zwirtualizowane boxy na Solarisie, dostawiane na zawalanie i loadbalancowane przez F5 BigIP/.
Z całym szacunkiem do wszystkich wyznawców RoR – to nie jest dobra platforma na miliardy odsłon. Stare, poczciwe PHP radzi tu sobie dużo lepiej, a dla entuzjastów nowości rozsądna alternatywa to Python/Django, szczególnie po wprowadzeniu Google App Engine. GAE to oczywiście środowisko dla aplikacji webowych oparte o rozwiązania Google. To zupełnie nowe, rewolucyjne podejście do tematu infrastruktury, w założeniu bliższe platformie Facebooka niż typowym platformom hostingowym. Nie jest jednak tak pięknie jak można by się spodziewać – Jaiku, konkurent Twittera tuz po premierze GAE zadeklarowal przeniesienie serwisu na platformę jako jeden z pierwszych na świecie. Minął miesiąc, a Jaiku nadal leci z Finlandii – widać wiec, ze to nie takie proste. Tylko “specjaliści” w komentarzach maja doświadczenie w optymalizacji wszystkiego i na dowolna skale – niestety nie chcą się dzielić wiedza ;).
Jakieś rady dla tych, którzy właśnie zauważyli, że ich popularny startup zaczyna wolno działać?
Jeśli jakiś “popularny startup” zaczyna wolno działać to znaczy, ze należy wymienić zagraniczny hosting za 7 dolarów na cos bardziej profesjonalnego za 500-600 złotych, najlepiej w Polsce. Mowie całkiem poważnie – duża cześć seriwsów jest po prostu żle napisana i wystarczy dobra optymalizacja kodu aby nigdy nie zaznać problemów typowej skalowalności. Powiedzmy sobie jasno: serwisów, dla których skalowalność jest wyzwaniem mamy w kraju raptem ze 20-cia, to te mające powyzej 200 mln odsłon miesięcznie. Reszta to tzw. bulka z masłem wymagająca co najwyżej kilku mocniejszych serwerów, myślącego admina i znajomości kombinacji paru magicznych haseł w stylu Ngnix, Lighttpd, Memcached, Pound, Squid, Varnish, HAproxy, round robin DNS, replikacja master/slave itp. Bawią mnie wiec rady tych, co radzą np. Naszej-Klasie jak sobie poradzić z ich popularnością. To tak jakby kierowca z prawem jazdy kategorii B, któremu udaje się prowadzić dostawczaka z przekonaniem twierdził, ze kierowanie 24-tonowego TIRa jest tak samo proste. Nie ma wiec chyba sensu rozpisywać na czynniki pierwsze jak z kilku klocków poukładać coś, co się nie rozpadnie przy kilkudziesięciu tysiącach wizyt dziennie – liczba prezentacji na ten temat jest dość duża.
W zamian, pewnie bardziej w kategoriach ciekawostki, mogę opowiedzieć jak funkcjonuje Fotka.pl /70-80 milionów odsłon i 3 miliony wizyt każdego dnia/. Otóż podstawa to bazy danych, tutaj mamy autorskie rozwiązanie nazywane przez nas Gridem gdzie dane użytkowników dzielone są na poszczególne nody, każdy składający się z 2 serwerów /po to aby w każdej chwili można było wyłączyć jeden z nich lub przetrwać awarie dociążając druga maszynę/. Dodatkowo skalujemy się na poziomie “serwerów cronowych” wykorzystywanych do skalowania zdjęć, sprawdzania wiadomości w Gmailu, wysyłania powiadomień itd – tutaj mamy wydzielone narzędzie pozwalające na płynne dokładanie nowych maszyn w zależności od aktualnego obciążenia.
Kolejna rzecz to serwowanie zdjęć: te większe serwujemy z Amazon S3, a mniejsze /w celu zredukowania zapytań radykalnie podnoszących koszty/ serwujemy ze swoich serwerów opartych na rosyjskim serwerze Ngnix. Jako pośrednika wykorzystujemy farmę serwerów proxy wraz z load-balancingiem o URL-ach, dzięki czemu zapytanie o ten sam plik trafia zawsze do tego samego serwera. Takie rozwiązanie pozwala na znaczne zwiększenie liczby danych magazynowanych przez proxy, gdyż jeden plik keszowany jest tylko na jednym serwerze, a dodatkowo w razie awarii któregoś z proxy ruch automatycznie kierowany jest na pozostale. Taka funkcjonalność jest istotna z racji serwowania zdjęć bezpośrednio z pamięci RAM – kilkudziesięciokrotnie szybszej od dysków ale tez stanowczo droższej przez co oszczędniej eksploatowanej. Najmniejszy problem to skalowanie serwerów www, tutaj wystarcza dobry hardware-owy load balancer /używamy izraelskiego Crescendo/ i można dostawiać maszyny w nieskończoność. Optymalizacja to również konieczność gzipowania serwowanych danych – często zapomina się tutaj o CSS i JS, a dzięki kompresji możemy zmniejszyć zapotrzebowanie na łącze i czas dostarczenia strony o kilkadziesiąt procent.
Fotka jako jedyna w Polsce na taka skale stosuje sprzętowe gzipowanie plików i serwuje strony w XMLu, dzięki czemu dopiero na komputerze użytkownika następuje tworzenie wyglądu strony na podstawie szablonu XSL. Szacujemy, ze tylko dzięki temu rozwiązaniu oszczędzamy około 400-500Mbit łącza.
Cala infrastruktura jest tez zoptymalizowana pod katem pracy osób dbających o rozwój i utrzymanie serwisu. Przykładowo Grid jest tak napisany, ze z punktu widzenia programisty nie jest istotne, na jakim nodzie znajdują się dane – po prostu wykonuje zwykle zapytania do bazy. Dodatkowo jesteśmy w stanie wydzielić np. popularne lub dowolnie wybrane profile na odrębne maszyny. Grid pozwala również na łatwą zmianę struktur tabel np. indexow, bez konieczności wyłączania serwisu. W przypadku optymalizacji jest to dość istotne, gdyż możemy dowolnie testować rożne sposoby indexowania danych. Oprócz tego stosujemy oczywiście powszechnie znane rozwiązania typu memcached, które pozwala na keszowanie stron w RAMie i dzieki temu szybkie serwowanie ich uzytkownikom.
Sprzęt serwisu fotka.pl
Przy kilku szafach sprzętu istotne jest tez zbieranie danych o działaniu poszczególnych maszyn – wykorzystujemy do tego wydzielony serwer i oprogramowanie Cacti. Możemy uzyskać wykres informacji o obciążeniu dysków, procesorów, zajętości pamięci, temperatur, operacji w bazach, ruchu sieciowego i wielu innych z każdego serwera w naszej sieci.
Dodatkowo do monitoringu działania używamy Naigosa, który powiadamia nas o możliwych zwiększeniach obciążenia lub tez o awariach – alerty docierają za pomocą SMSow lub Jabbera jeżeli dany administrator jest obecnie online. Już nie dla wygody ale z konieczności automatyzujemy praktycznie wszystkie możliwe zadania. Optymalizacja wymaga bardzo wielu zmian w serwisie, dlatego np. zmiana czegokolwiek np. w cfg PHP na 40 maszynach będzie udręką, jeśli nie będziemy mieli skryptów które wykonają to za nas.
Na koniec dodam, ze optymalizacja ma tez miejsce na poziomie ustawienia i połączeń miedzy serwerami – przy dużym ruchu np. backupy czy instalacje upgradow mogą znacznie wpływać na działanie serwisu, dlatego tez stosujemy politykę 3 fizycznie wydzielonych sieci: publicznej gdzie serwowane są dane do użytkowników, prywatnej gdzie odbywa się np. ruch związany z instalacja, backupami oraz sieci managementu, gdzie mamy dostęp do wirtualnych KVMow, pozwalających np. wejście do biosa czy wyłączenie serwera. Dodatkowo poszczególne szafy sprzętu są zduplikowane sprzętowo, aby bez przerw w działaniu serwisu można było wyłączać niektóre z nich i np. zaktualizować hardware lub przenieść do innej lokalizacji.
Obecnie pracujemy nad zwiększeniem wydajności serwowania małych plików. Mimo limitu zdjęć na jednym profilu użytkownicy dodają ich 200-300 tysięcy każdego dnia. W szczycie oznacza to ponad 10.000 zapytań na sekundę. Problemem nie jest tutaj zapotrzebowanie na powierzchnie /wystarczy kilka SUNow x4500 z 48 dyskami i powierzchnia 24TB/ ale ogromna liczba zapytań..
Witaj, nazywam się Grzegorz Marczak i jestem autorem tego bloga. Piszę tutaj o serwisach społecznościowych, nowych technologiach i nowych trendach w internecie.
xml + xslt po stronie przegladarki? a jak? :)
wypas (konkrety). czekam na flejma RoRowców :P
Chciałbym podziękować Agnieszczakowi za ten wywiad i powiedzenie czegoś więcej. :)
bardzo fajny i konkretny wywiad.
ps. od Izraelskiego Crescendo o niebo lepszy jest dumpowalny z RX na RZ5 Bialoruski TrioDi – polecam!
No! Wreszcie jakieś konkrety. Zdecydowanie najlepszy wpis na tym blogu ever :)
Panie Agnieszczak, chylę czoła za te słowa…!
Normalnie pod warunkiem, że nie jest to IE. ;]
Dla badzIEwca trzeba preparsować i wysyłać czysty HTML…
> Z całym szacunkiem do wszystkich wyznawców RoR – to nie jest dobra platforma na miliardy odsłon. Stare, poczciwe PHP radzi tu sobie dużo lepiej, a dla entuzjastów nowości rozsądna alternatywa to Python/Django,
Hm, Ruby 1.9 jest już ponoć szybsze od Pythona, a i warto wspomnieć o bazującym na Railsach, szybszym od nich, frameworku Merb.
No i się wydało – Ruby i RoR się nie skalują – do kosza z tym szmelcem. A może PHP też się skaluje tylko do pewnego stopnia i powyżej określonej liczby req/sec przestaje się skalować, bo taka nasza-klasa ma permanentne problemy z wydajnością, a to przecież portal “nieco” większy niż fotka? Co wtedy pozostaje? Chyba tylko Java, reklamowana jako naprawdę skalowalny język. A może ktoś wie, co zrobić, żeby język zaczął się skalować albo gdzie się ukrywa w Javie ta skalowalność? Może chodzi tu o konwencję typu “camel style” w nazwach metod i klas np. jakaśMetoda, a nie jak w nieskalowalnym Ruby z podkreślnikiem (jakaś_metoda). W PHP za skalowanie mogą odpowiadać dolary w nazwach zmiennych. Ola Bini też nie wie, gdzie się ukrywa skalowanie, a Dan Henderson w swoje książce pt. “Skalowalne witryny internetowe” (Helion) pisze, że skalowanie w ogóle nie jest związane z językiem użytym po stronie serwera i mówienie, że język A się skaluje a B nie to bzdura. Ale co on tam może wiedzieć, za jakiś Flickr odpowiada, zna ktoś adres do tego w ogóle? Warto jeszcze się zastanowić, dlaczego nasza-klasa miała takie problemy z “Panem Gąbką”. Może wykres przedstawiający wzrost popularności w czasie w porównaniu z Allegro czy Fotką dla przykładu, może być dla nich częściowym usprawiedliwieniem..
Super :) Miło poczytać wypowiedź kogoś, kto wie o czym mówi :)
Hazan, to chyba najlepszy wywiad tutaj opublikowany.
Ragni, dzięki za wyczerpujący opis. Choć to nie moja działka, to z przyjemnością się tego czytało.
Hazan, świetny wywiad!
@PR: Normalnie. Tworzysz plik XML, tworzysz arkusz XSLT, otwierasz w przeglądarce XMLa i pojawia się sparsowana strona.
@eRIZ: nie prawda, do IE wysyłasz normalnego XMLa i on buduje stronę na podstawie arkusza XSLT. Co więcej, o ile się nie mylę, Internet Explorer jako pierwszy obsługiwał tą technologię.
A najlepiej, to po prostu obejrzyjcie sobie źródło serwisu forka.pl i zobaczycie jak to wygląda. :)
wielkie dzieki za taki zbior rzeczowych informacji!
No to Ragni pocisnął. Hazan więcej takich rzeczowych wywiadów, więcej!
RoR nie jest demonem prędkości wszyscy to przyznają. Samo Ruby nie jest aż tak wolne. Ale nie ma co tutaj wspominać o 1.9 bo on _nigdy_ nie będzie używany produkcyjnie. Jeśli coś miałoby przyśpieszyć aplikacji napisane w Ruby to może JRuby, Rubinius. Nie ma co narzekać, nic nie jest doskonałe.
Takich wpisów nam potrzeba
na to czekalem, swietny tekst, o niebo lepszy od poprzedniego!
Super! Na to czekaliśmy. Dzięki za ten wywiad!
[...] umieścił na swoim blogu ciekawy wywiad z Rafałem Agnieszczakiem o architekturze fotka.pl. Polecam [...]
Bardzo dobry wywiad, podzięki dla autora, no i oczywiście dla pana Rafała Agnieszczaka który udzielił bardzo wyczerpującego wywiadu :)
Dzięki za wywiad. O kilku wspomnianych rozwiązaniach nawet nie wiedziałem że istnieją :)
.. ale coś mało flamewars nt. RoR ;-) (btw PHP5 rulez)
Popieram, nareszcie można poczytać konkrety w jednym miejscu, a kombinować ze strzępków informacji.
@Michał, miło wiedzieć. ;]
A od wersji 6. namespace’y. ;]
Super wywiad, dzięki!
…ale mam pytanie może trochę z innej dziedziny – dlaczego kod html fotki jest tak słaby? Przecież takie rzeczy:
…to wstyd. Poza tym strasznie dużo CSS inline – przecież można to wrzucić w osobne pliki i do cache przeglądarki…
Wydawanie kasy na nowy sprzęt, zaawansowane rozwiązania a na starcie takie kwiatki :)
@LK — najpierw optymalizuje się to co przynosi naszym zdaniem najszybsze efekty najmniejszym kosztem :).
LK wrote: “strasznie dużo CSS inline – przecież można to wrzucić w osobne pliki i do cache przeglądarki… ”
Jak masz XSLa, to CSSy inline są keszowane razem z XSLem ;)
Panu Rafał Agnieszczak serwuje nam tu jakieś mocno nieświeże informacje z czasow Rails 1.x. Aktualnie Rails 2.2.x jest szybszy od analogicznych frameworków w PHP, a (napisany w Ruby) framework Merb ((http://merbivore.com)) kompletnie deklasuje rozwiązania w PHP (http://www.slideshare.net/mattetti/merb-presentation-at-orug-presentation). Różnica staje się jeszcze większa w wypadku użycia JRuby (http://jruby.codehaus.org) dzięki któremu Rails i Merb mają pełny dostęp do całej architektury Javy. JRuby z wersji na wersję staje się coraz szybszy. A dzięki temu, że wykorzystuje agresywną kompilację inline JIT’a w wirtualnej maszynie Javy, może rozpędzić się do szybkości zupełnie poza zasięgiem PHP. Merb odpalony na JRuby, Glassfishu i pojedyńczej maszynie z procesorem Intel Quad Q6850 osiąga ponad 9 tys. req/s (http://blogs.sun.com/Jacobkessler/entry/it_s_over_9000) zostawiając daleko za sobą PHP czy Django.
Co do PHP, to jest powszechnie krytykowany za fatalną niespójność języka, słabe możliwości i ostatnio coraz bardziej za słabą wydajność. Żaden akcelerator do PHP nie jest w stanie zmienić zasadniczej filozofii pracy PHP, który za każdym przeładowaniem strony musi tworzyć od nowa wszystkie obiekty. Python i Ruby tego nie potrzebują, bo działają tu podobnie jak serwlety Javy, część obiektów żyje cały czas w pamięci i nie trzeba ich co chwilę tworzyć. To w efekcie oznacza, że im większa i bardziej złożona aplikacja, tym bardziej PHP będzie zwalniał przy analogicznym projekcie w Pythonie czy Ruby.
Być może Twitter używa jakąś starą wersję Rails (wersja 1.x była wolna i jest odpowiedzialna za mity jakie teraz się ciągną za RoR). Zdaje się, że Twitter używa również klasterow opartych na wolniejszym Mongrelu zamiast na szybszym Thin (http://code.macournoyer.com/thin/), lub znacznie szybszym, napisanym w C – Ebb (http://ebb.rubyforge.org). Być może powinni przesiąść się na JRuby i/lub Merba, który jest średnio jakieś 3-5x szybszy od Rails.
Najbardziej irytujące w tym wszystkim nie jest bazowanie na archaicznych danych odnośnie wydajności. Wkurzyć tylko może wprowadzanie dezinformacji, które potem powodują że ludzie mylą Ruby z RoR, (coś jak laicy twierdzący że komputer to windows).
Panie Grzegorzu. Pisze pan obok swojego avatara poniżej, że pisze o nowych technologiach i nowych trendach. Niech więc będzie Pan na bieżąco z tym jak wygląda sprawa Ruby dzisiaj. (na bierząco powinno się być w tematach o których się ktoś głośno wypowiada, prawda?)
Powstał nowy framework: Merb, który deklasuje pod względem wydajności (jak i łatwości tworzenia aplikacji) nie tylko RoR’a ale też wszelkie frameworki czy też czyste spaghetti-PHP. O nim też wypadałoby wspomnieć.
Bardzo ciekawy artykuł. Jestem pod wrażeniem zastosowanych rozwiązań. Nie przypuszczałem, że fotka.pl to tak profesjonalnie przygotowany portal.
Tekst został opublikowany dość dawno i nasuwa mi się jedno pytanie. Czy fotka zrezygnowała z XSLT po stronie przeglądarki? U mnie (FF3 na ubuntu) strona jest w XHTML. Jeśli zrezygnowano to warto napisać tu czemu. Jeśli nie, to warto napisać czemu moja przeglądarka nie jest obsługiwana w ten sposób.
PS. Wydaje mi się, że w kilku miejscach zabrakło przecinków.
tylko na glownej wypluwamy HTMLa, na profilach gdzie jest 90% ruchu nadal jest xslt.
Bardzo dobrze, że używacie XSLT, ale bardzo źle, że nie przewidzieliście obsługi przeglądarek nie obsługujących XSLT oraz niektórych screen readerów. Myślę, że i tak dla googli wysyłacie HTML, więc wystarczy zrobić parę wyjątków i opcję przełączenia się na HTML. Dziwna bardzo jest generacja CSS i JS przez XSLT. W przypadku JS raczej generuje się pliki JSON (tak jest bezpiecznie), a CSS wystarczy dobrze opisać w plikach CSS. Nie to żebym się mądrzył, ale nie tylko moim zdaniem rozdzielenie trzech części przeglądarki na JS, CSS i DOM znacząco zmniejsza nakłady na utrzymanie kodu (wiadomo gdzie co jest i definicje się nie nadpisują).
Widzę, że XSLT wypluwa XHTML. Czy nie ma problemów z programowaniem w JS i CSSw tej sytuacji? Z tego co pamiętam w FF wszystkie tagi w zapisie były zamieniane na , co oznaczało nie zamknięty tag do końca pliku.
Jakiego generatora XML używacie lub jakich wytycznych się trzymacie przy pisaniu własnego? Czy używacie namespaceów (wewnętrznie bo na zewnątrz ich nie ma)? Czy istnieje ścisła specyfikacja plików XML pozwalająca na automatyczną walidację tych plików?
Trochę się rozpędziłem z pytaniami, ale dla mnie jest to bardzo ciekawy temat ponieważ jestem w trakcie planowania frameworka XML i chcę to zrobić najlepiej jak się da. Architektura będzie opublikowana jako LGPL, implementacja będzie komercyjna lub BSD (zależy to od tego czy ludzie będą zainteresowani rozwijaniem projektu).
@Adrian – chyba nie dosc szczegolowo przygladales sie dzialaniu tego mechanizmu:
- strony sa serwowane w HTMLu, glownie dla starszych przegladarek czy tez komorek,
- JSON jest uzywany ale nie gwarantuje on 100% bezpieczenstwa,
- idealne trzymanie sie standardu jest jak jazda 3 pasmowa droga 50km/h, wiec czasami warto dac CSS i JS XSLu/HTMLu,
Tzn jakiego mechanizmu? Ja mówiłem o konwencjach (http://developer.yahoo.com/yui/ – tam jest mnóstwo materiałów o tym jak pisać front-endy i nie tylko)
- strony fotki w konquerorze i linksie są nieczytelne
- nic nie gwarantuje 100% bezpieczeństwa, JSON natomiast daje istotne zwiększenie przejrzystości kodu
- i znowu konwencje a nie standardy. Owszem są miejsca gdzie warto wrzucić CSS/JS do HTML ale nie ma takich miejsc gdzie trzeba je generować.
Pozdrawiam
@Adrian widze ze duzo teoretyzujesz, chetnie zobacze co wg tej teorii wyjdzie Tobie w praktyce, ktorej nie da sie opisac tutorialami “o tym jak pisać front-endy”
- wg. http://www.ranking.pl/index.php?page=Ranks:RanksPage&stat=22|OW&details=1 konqueror 0,00% odwiedzin, linksa nie ma nawet na liscie, rownie dobrze mozna robic strony dzialajace w DOSie
- za wiki: “JSON jest tekstowym formatem wymiany danych” daje zwiekszenie przejrzystosci danych, kod i tak zalezy od programisty
- nalezy wypracowac sobie takie zasady tworzenia, ktore daja jak najszybszy efekt, w najkrotszym czasie, zbyt szybko wszystko sie zmienia
@Andrzej Przepraszam, ale treść Twojego komentarza, jak dla mnie, nie ma żadnego związku z tematem. Mam nadzieję, że uzyskam odpowiedzi na moje pytania dotyczące XML. :)
Zauważyłem natomiast, że w moim poście z pytaniami nie pokazały się tagi HTML:
Widzę, że XSLT wypluwa XHTML. Czy nie ma problemów z programowaniem w JS i CSSw tej sytuacji? Z tego co pamiętam w FF wszystkie tagi w zapisie były zamieniane na , co oznaczało nie zamknięty tag do końca pliku.
miało być: w zapisie (br/) były zamieniane na (br), gdzie “(” to “mniejsze”, “)” to “większe”.
JSy i CSSy operuja juz na wygenerowanym kodzie HTML, wiec nie widac tutaj wiekszych roznic w stosunku do tradycyjnego serwowania HTMLa.
Jedyna roznica jest taka, ze nie ma mozliwosci “pisania” przez “document.write” z JS. Strona utworzona za pomoca XSTL jest z zalozenia wygenerowana/zamknieta (document.close), przez cos “pisanie” na niej w FF konczy sie bledem. Oczywiscie modyfikowac samego DOMa jak najbardziej mozna.
Na ten problem mozna napotkac przy reklamach np. Googla wtedy jedynym obejsciem jest wstawienie ich do IFRAME.
document.write=function(s)
{
alert(s)// lub cokolwiek innego
}
document.write(“xxx”)
Testowałem w FF3 i IE6.
@Adrian – owszem, wywolanie funkcji zadziala ale nie da sie jej uzyc, wiecej masz tutja https://developer.mozilla.org/en/XSL_Transformations_in_Mozilla_FAQ pod naglowkiem “What about document.write?”
Jeśli chodzi o JS to wolałbym porozmawiać o zakresach zmiennych, wielodziedziczeniu przez kopiowanie, lambdzie albo o paradygmacie programowania zorientowanego na zdarzenia.
Szkoda, że nie uzyskałem odpowiedzi na pytania dotyczące XMLa. Widać muszę zapytać w innym miejscu.
Pozdrawiam
Najlepszy artykuł z tej serii. Szereg informacji i niezasłanianie się know-how, jak w przypadku patrz.pl. W sumie nie ma co się dziwić, bo fotka jest jednym z najpopularniejszych polskich serwisów i co ważne w tym temacie, jest w sieci już od wielu lat, nie tak jak n-k (choć artykuł o nich też był ciekawy). Ciekawe czy Allegro.pl, lub któryś z polskich portali zechciałby się tak fachowo, dokładnie wypowiedzieć. Wymienione serwisy to już poważne, komercyjne strony, więc ciężko by było pogadać o nich z ich założycielami-technikami, ale z drugiej strony, zawsze jest jakiś pracownik działu IT, który wie o co w tym chodzi. Szczególnie warto zapytać Onet.pl, bo niedawno zmieniali swoją serwerownię.
W Firefoksie absolutnie nie może być mowy o niezamkniętych tagach do końca pliku z tej prostej przyczyny, że FF nie dokonuje transformacji XMLa na kod (X)HTML, ale bezpośrednio na drzewo DOM dokumentu. Tak więc jeśli XSLT definiuje, że w danym miejscu pojawia się , to będzie to w drzewie pusty znacznik BR, natomiast jego zapis w XHTMLu bądź HTMLu jest już czymś wtórnym.
Oczywiście takie podejście ma tę wadę, że nie można mieć w XMLu w CDATAch kodu HTML, który miałby trafić nieprzetworzony do kodu wynikowej strony i trzeba robić obejścia z użyciem JS (podstawianie textContent pod innerHTML), co z tego co kiedyś patrzyłem, Fotka robi.
W innych przeglądarkach z tego co pamiętam takich sztuczek robić nie trzeba było.
[...] serwisów o bardzo dużym ruchu można w nich składować na przykład zdjęcia i pliki graficzne (na przykład fotka.pl intensywnie korzysta z usług Amazon). Odciąża to nasz serwer i jednocześnie pozwala [...]