Temat: Node.js czy Apache/PHP
Maciej Sikora:
Jakub L.:
E tam, będzie tak jak teraz.
Hehe, no no i co myślisz, że internet to zawsze będą strony internetowe. Grubo się mylisz, a ja już widzę, że desktopowe aplikacje idą do lamusa. Ile to już mamy webowych odpowiedników, nawet microsoft rusza z officem w chmurę. Nie obronisz się od tego chodź byś chciał. Websockety są dużym krokiem w rozwoju oprogramowania serwerowego, a takie firmy jak apple, mozilla, google czy microsoft nie mogą się mylić.
Nieco odbiegamy od tematu :)
Znasz wielu biznesmenów którzy z radością powierzą dokumenty swojej firmy jakiejś bliżej niezdefiniowanej "chmurze"?
Może wrócić idea terminali z początków informatyki, albo cienkich klientów, ale własna infrastruktura nie jest do przecenienia. Tak samo jak to stało się kilkadziesiąt lat temu, gdy okazało się, że ludzie wolą mieć cały komputer w domu.
Dwa: to, że dzisiaj kilkaset milionów ludzi radośnie przeprowadza wiwisekcję swojej prywatności oddając za garść paciorków coś, na co inaczej Wielki Brat musiałby wysupłać straszną kabonę nie oznacza, że tak będzie zawsze, tak samo z dokumentami - chciałbyś żeby bliżej niesprecyzowane organizacje miały potencjalny dostęp do na przykład twoich pism do banku?
Nawet ustawa o ochronie danych osobowych jest dość pouczającą lekturą, postępowanie GIODO dorzuca swoje i przeciąga punkt ciężkości w kierunku tragifarsy, a miliardy much i tak robią swoje, wystawiając się na kradzieże tożsamości, phishing i tym podobne.
Chmura jest fajną zabawką jak się chce coś pokazać znajomym, albo w intranecie jakiejś organizacji, ale do poważnych zastosowań gdzie w grę wchodzą pieniądze jest jakby mało masywna.
Od strony programistycznej - websockety są kolejnym poszukiwaniem srebrnej kuli - próg wejścia do dewelopowania w HTMLu i JavaSkrypcie jest absurdalnie niski - potrzebujesz jedynie edytora tekstowego i przegladarki, przeglądarka odwala cała robotę typu kompilacja i wykonanie.
Kolejny poziom to serwer z którym przeglądarka się będzie komunikowała. Do tej pory taka komunikacja kulała - najpierw były POST i GET, później ramki, potem ktoś rzeczywiście łebski wykombinował AJAX, ale nadal to było upierdliwe - AJAX sprowadza się do programowania równoległego, a to jest jedną z trudniejszych rzeczy do oprogramowania, i pojawiły się websockety, jako transplantacja czegoś, co się sprawdziło (czyli socketu) z poziomu systemu operacyjnego na poziom dostępny dla JS - przeglądarki.
Z niskiego progu wejścia i z faktu że przeglądarki powoli stają się platformami uruchomieniowymi nie ustępującymi programom chodzącym bezpośrednio w systemie operacyjnym (albo maszynach wirtualnych, jeden pies), wykiełkowała idea, że skoro jest to takie łatwe i dostępne, to masa ludzi będzie mogła robić masę softu, tanio, bo tych drogich się nie zatrudni.
Problem w tym, że ta masa jest najczęściej niedoedukowana i robi krap, i dlatego jest tania, a drodzy wiedzą dlaczego są drodzy.
W probówce taka katastrofa nazywała się JIL, Bondi i WAC - miało być tak pięknie, wyszło jak zwykle (jak na przykład wyszło lata wcześniej z WAPem).
Różnica jest taka, że serwerowi zajedno, czy serwuje HTML 1, 4, 5 czy xhtml, tak samo z cssem, natomiast w przypadku websocketów wpływają one na sam serwer i jego zachowanie - Apaczem zaserwujesz normalnie HTML 5 czy css3, a do websocketów go już nie nakłonisz, i tu jest różnica.
A kto mówi o Apache. Wybrałem node.js bo nadaje się do tego, a Apache pozostaje do standardowego PHP i zwykłych aplikacji. Nakłonić to go nakłonisz, ale przez swoją wątkowość nie jest preferowanym rozwiązaniem.
Ogólnie dla masowego wdrożenia websocketów musisz przebudować sporo obecnej infrastruktury przystosowanej do HTMLa, css i JS, a jak to się będzie skalowało, to dopiero przyszłość pokaże.
пропозиції роботи
