Menu

Polski e-commerce i zarządzanie e-firmą

Nazywam się Paweł Fornalski. Jestem założycielem i prezesem IAI S.A., dostawcy rozwiązań e-commerce dla sklepów internetowych i rezerwacji noclegów dla właścicieli apartamentów i hoteli. Na tym blogu piszę, w oderwaniu od oficjalnych poglądów innych właścicieli i pracowników IAI o tym co mnie prywatnie porusza. Gdybyś chciał się skontaktować pisz na pawel(a)fornalski.pl

Wpisy otagowane : serwery

O czym należy wiedzieć wdrażając do swojego sklepu internetowego Magento? [Część 2/4]

pfornalski

Zgodnie z przewidywaniami, poprzednia część, mocno obrazoburcza wzbudziła ogromne zainteresowanie i sądząc po statystykach, mimo publikacji w sobotę, przeczytała go ogromna ilość osób. Sporo ludzi przesłało swoje uwagi, pytania itp. Nie czekam więc tygodnia, tak jak to poprzednio zaplanowałem, tylko już na następny dzień publikuję drugą część, co stanowi około 50% całości materiału. To fajnie, bo nosiłem się z napisaniem tego artykułu ponad rok, układając go w głowie poszczególne jego części i wstępnie weryfikując moje tezy, także w dyskusjach z ludźmi wdrażającymi Magento. Rozumiem, że to co piszę, może się nie podobać wszystkim. Zwłaszcza tym, którzy oczekują naukowych dowodów. Łącznie tekst będzie miał 9 stron maszynopisu, więc i tak całkiem sporo. Staram się też pilnować prostego języka, który zrozumie właściciel biznesu, a nie jego informatyk. Rozwleczenie wszystkiego i wytłumaczenie dokładniej, wymagało by napisania sporej wielkości e-booka. Założyłem też, że dobre rzeczy o Magento powie sam producent i ludzie, którzy sprzedają takie wdrożenia. Dlatego też „O czym należy wiedzieć” odnosi się do tego, czego zazwyczaj klienci nie słyszą. Ale spokojnie. Oddam Magento należną część i będzie trochę dobrych słów. Cierpliwości. Ta seria liczy 4 odcinki :)

Duzi gracze np. Microsoft polecają Magento

Duzi gracze od hostingu polecają Magento. To dlatego, że później sprzedając zasoby w Azure, dopasowane pod Magento, zamiast sprzedać jeden czy dwa serwery, sprzedają ich 10. Wygodnie jest promować hasło, że taniej wynająć serwer niż programistę do optymalizacji kodu. W SaaS jednak zjawisko wygląda inaczej, przy np. 3000 kopii, bardziej opłaca się zatrudnić programistę, niż wynająć 3000 dodatkowych serwerów.

Jakiś czas temu rozważaliśmy w IAI rezygnację z naszej własnej infrastruktury na rzecz Azure i Amazon. To fajne, wysokopoziomowe środowisko, które się wydaje idealne dla takiej firmy jak IAI. Problemem okazuje się być jednak cena. Przy tym samym kodzie, mocno optymalizowanym, wyszło nam i tak, że klient który płaci np. 2999zł abonamentu (to około 40-100Mbit ruchu WWW, czyli całkiem spory sklep) potrzebowałby zakupu instancji i dopłat które by wyniosły około 5000-6000zł (za same serwery). A więc nasza usługa kosztowałaby powiedzmy z 8000zł zamiast 3000zł za to samo. Przy wdrożeniu Magento nie masz wyboru, ale warto przynajmniej wiedzieć za co przepłacasz.

Kolejny aspekt dodatków do Magento (pisałem o nich w poprzedniej części) to sposób ich działania. Po pierwsze, większość pisana jest jako autonomiczna, czyli pobiera komplet informacji, następnie zwraca je do dalszego przetwarzania lub do „jądra”. A ponieważ to jądro to skrypt w PHP, działa to potwornie wolno. Przykład: w Magento jest dodatek do filtrów. Działają bardzo prosto i prymitywnie, więc musisz dokupić kolejne dodatki dodające np. prezentację ilości towarów przy każdym filtrze. To oznacza, że zamiast generując filtry ustalić od razu jednym zapytaniem SQL z bazy danych ile jest towarów (co zadziała nawet kilka tysięcy razy szybciej), wyciągasz te informacje 2 razy, wysoko-poziomowo, stosując iteratory. A to wolne działanie to nie tylko koszty, ale często brak możliwości odpalenia sklepu. W IAI nie raz braliśmy udział w odpalaniu sklepu, który po np. 2 latach wdrażania Magento, wydaniu fortuny, dojściu do 15 serwerów nadal nie mogli odpalić sklepu, bo działał zbyt wolno.

Magento czy Presta dobrze się skalują”

Zastanawiam się, kto jeszcze ma po przeczytaniu tego co napisałem wcześniej, że Magento jest szybsze i bardziej skalowane tak uważa? Wyjaśnię w wielkim uproszczeniu, aby każdy zrozumiał jak budowany jest duży sklep na Magento. A mianowicie, stawia się kilka serwerów na bazę danych i engine, do tego serwery na zapisanie i obsługę obrazów stron. Tzw. worker przegląda każdy URL sklepu i zapisuje obraz jako plik statyczny. Później gdy klient szuka jakiegoś towaru, wyszukuje się zapisany obraz strony i zwraca szybko klientowi. To jeden ze sposobów rozwiązań na problem wolnego działania Magento o którym pisałem wcześniej.

Jeżeli słyszysz od małej agencji lub tzw. „speca-komputerowca”, że Magento się świetnie skaluje (bo używają go duzi) to zwyczajnie nie wierz mu, i sprawdź np. prezentację Divante (jedna z dużych firm wdrażających Magento) pt. „Skalowalność Magento – Teoria i trochę praktyki”. W tej prezentacji bardzo podoba mi się tzw. Nietypowy problem (CRM, ERP, WMS), 37tys. Produktów, 200-250 sesji jednocześnie. A to jest właśnie charakterystyka typowego sklepu internetowego, średniej wielkości. Nie przeczę, że ktoś może z Magento być w stanie zbudować infrastrukturę giganta. Ale to co wymaga już skomplikowanego podejścia, można mieć już do 2000zł na miesiąc za kompletny system, w dużym SaaS.

Wróćmy do technologii workerów. Niektórzy mylnie zakładają, że ta technologia występuje tylko w Magento. Pewnie jest tak dlatego, że bez cache (workerów) na Magento nigdzie się nie zajedzie poza rozwiązanie developerskie. W IAI-Shop.com mamy też funkcjonalność workerów, którą wystarczy włączyć jednym kliknięciem i system działa tak samo (a nawet lepiej o czym za chwilę). Różnica polega na tym, że ta technologia jest niepotrzebna w małym i średnim sklepie, gdyż koszt działania workerów będzie większy niż koszt generowania stron dynamicznie, zwłaszcza że kod jest bardzo mocno zoptymalizowany. Nie trzeba więc kupować Magento aby mieć generator stron statycznych.

Technologia stron statycznych (generowanych przez workery) ma jeszcze jedną dużą wadę. Ogranicza mocno funkcjonalność. Próżno w typowym sklepie Magento szukać takiej funkcjonalności że np. klient wpisuje kod rabatowy i od tego momentu podczas szukania towarów, filtrowania itp. widzi ceny po przeliczeniu rabatu. A przecież brzmi to jak podstawowa funkcjonalność sklepu internetowego typu IAI-Shop.com prawda? No cóż. Jak już się przekonałem, gdy właściciel sklepu internetowego ma zapłacić z własnej kieszeni np. Pareset dodatkowych tysięcy za taką funkcjonalność z własnej kieszeni, nagle przestaje to być takie potrzebne.

To teraz trochę liczb: Największe sklepy internetowe w tzw. standardowych planach abonamentowych na IAI-Shop.com obsługują ruch na poziomie 300Mbit/s i parę tysięcy requestów na sekundę do stron dynamicznych (czyli tylko strona HTML generowana przez skrypt). Do tego potrzeba maszyny 64-rdzeniowej, która z całą opieką i gwarancją mobilności (bo czuwa nad tym duży zespół prawdopodobnie najlepszych adminów), czyli koszt 8999zł/mc. A mamy też w ofercie indywidualnie konfigurowaną infrastrukturę, w której możemy też zastosować parę serwerów.

Jakiś czas temu byłem konsultantem w jednym z 3 najbardziej znanych sklepów internetowych i zdziwiło mnie to, że sklep ten ma 200Mbit/s w okresie świątecznym. Tylko, że koszt IT w tym przypadku wynosił ponad 200 tys. na miesiąc. Wniosek jest taki, że nasi niektórzy klienci mają większy ruch niż jedna z 3 najbardziej znanych marek w polskim e-commerce.

Więc warto patrzeć realnie, jakie liczby będziesz osiągać w swoim sklepie i ile tej skalowalności realnie będziesz potrzebował na najbliższe 3 lata. Bo przecież i tak nie będziesz miał aktualizacji w swoim Magento. Czyli jego cykl życia i tak nie przekroczy 3 lat. Czy potrzebujesz od razu inwestować w system miliony, aby być zabezpieczonym, skoro możesz wybrać SaaS w którym jeżeli biznes wyjdzie, po prostu zapłacisz 8999zł/mc a jak jednak pójdzie trochę słabiej to np. 599Zł/mc?

Duże sklepy potrzebują dedykowanych rozwiązań

Mit o tym, że duże sklepy potrzebują dedykowanych rozwiązań to mój ulubiony mit. Duże sklepy nie potrzebują dedykowanych rozwiązań, tylko dobrego WMSa (system zarządzania procesami magazynowymi), bo inaczej nie da się prowadzić sklepu internetowego, który wysyła już powyżej 10 tys. przesyłek miesięcznie. Czy to oznacza, że sklep musi wdrażać kernel na bazie którego musi wdrażać i przerabiać dodatki do Magento (patrz wcześniej)? Nie, potrzebuje po prostu WMSa, którego w Magento nie ma.

A te WMS które oferują integrację z Magento działają na tej zasadzie, że trzeba w nich umieścić całą bazę towarów, by następnie przez API pobrać informację o zleceniu (dane klienta, ID towarów) i zaimportować to zlecenie do tego WMS. Obsługa całego zamówienia nie odbywa się w Magento tylko w WMS, który to na koniec, po wysłaniu paczki, ustawia przez API status iż zamówienie jest zrealizowane. Czy do tego potrzeba dedykowanego systemu? Każdy, nawet najmniejszy i najtańszy SaaS oferuje taką funkcję, jak udostępnienie przez API informacji o kliencie i ID towarów i pozwala ustawić status, że zamówienie jest wysłane? Czemu więc, sklepy idą na to, wiedzieć że przepłacą? Albo są gotowe to finansować w imię wyższej wyceny przy sprzedaży sklepu, albo zwyczajnie o tym nie wiedzą. I paradoksalnie, częściej po prostu ludzie o tym wszystkim nie wiedzą.

A na koniec rodzynek: Większość WMS, w tym najpopularniejszy polecany do Magento jest oferowany wyłącznie w SaaS. Czyli klient teoretycznie wdraża własny system, by mieć kontrolę nad kodem, tylko po to, aby kluczowa część jego biznesu była i tak w SaaS. Uwielbiam minę ludzi, którym to pokazuję, zwłaszcza tych którzy wydali kilkaset tysięcy na wdrożenie Magento i myśleli że ich dział IT ma pełną kontrolę nad ich biznesem.

Aura tajemniczości

Od tego, dlaczego niektóre tzw. duże sklepy decydują się na Magento i że czasami wcale nie jest to związane z ograniczeniami SaaS czy jego wadami, zaczniemy trzecią część, którą planuję opublikować w przyszły weekend. Jeżeli nie chcesz, jej pominąć i dowiedzieć się tego, czego nikt inny Ci nie powie, dodaj swój e-mail do newslettera. System bloga wyśle Ci wyłącznie informacje o nowych postach, żadnych reklam.

Bezpieczeństwo i włamania do sklepów internetowych

pfornalski

Serwis Aukcje.org przeprowadził ze mną wywiad, który dzisiaj w nocy został opublikowany pod tytułem "Bezpieczeństwo w sklepie internetowym". Polecam lekturę tego artykułu, ponieważ nie przypominam sobie, aby poza banalnymi opracowaniami, zwanymi też raportami na temat bezpieczeństwa (wielu) sklepów internetowych coś w tej sprawie w ciągu ostatnich paru lat napisano w oficjalnych kanałach. Tym czasem podziemie komputerowego świata ciągle przyciąga najinteligentniejszych informatyków i warto o tym pamiętać. Świetnie skomentował to Jacek Strzembkowski, naczelny Aukcje.org "Ktoś odsyła zakupiony towar, poczta gubi przesyłkę, zakup okazuje się niezgodny z deklaracją sprzedawcy i na koniec dostajemy niezasłużonego negatywa - tak na ryzyko i niebezpieczne sytuacje w handlu elektronicznym patrzą aukcjonerzy. Hakerzy, ataki, włamania…? Administracje platform aukcyjnych robią wszystko, aby użytkownicy spali spokojnie. Działania ludzi odpowiedzialnych za bezpieczeństwo są niezauważalne.

Spora część aukcjonerów decydując się na start własnego sklepu żyje w złudnym komforcie bezpieczeństwa, do którego przyzwyczaili się w serwisach aukcji. Cóż złego może się stać? Od 10 lat jestem na Allegro i jedyne niebezpieczeństwo z jakim miałem do czynienia to spam nigeryjski i wirusy w poczcie! Tak, do tej pory ktoś dbał o Twój tyłek. Uwierz, byli to najlepsi fachowcy w branży - raczej nie uda Ci się zatrudnić żadnego z nich. Teraz, kiedy jesteś na swoim - radź sobie sam.

Jaka jest faktyczna skala zagrożenia? Jak może wyglądać atak? Czy bezpieczeństwo w sklepie można sobie kupić? O odpowiedź poprosiłem Pawła Fornalskiego, ceo IAI S.A. - producenta oprogramowania do prowadzenia sklepu internetowego IAI-Shop.com działającego w modelu SaaS:"

Oto pierwsza część wywiadu:

Aukcje.org, Jacek Strzembkowski: Jak wygląda zabezpieczanie aplikacji w chmurze? Czy SaaS upraszcza ochronę danych Waszych klientów?

IAI-Shop.com, CEO IAI S.A. Paweł Fornalski: Zabezpieczanie aplikacji webowych, działających w chmurze nie różni się znacząco od zabezpieczania aplikacji webowych działających w hostingu. Sam SaaS to po prostu model dostarczania aplikacji i rozliczania się z klientami, a nie jakaś zupełnie inna technologia. Nie jest to jakaś specjalna technologia, która zwiększa bezpieczeństwo. W ramach chmury (ang. Cloud) dostarczamy klientom rozwiązanie sprzętowo-programowe. Nie jest tak, że klient kupuje program i musi go zainstalować w środowisku produkcyjnym, do czego najczęściej osoby nie będące ekspertami od bezpieczeństwa po prostu nie mają kwalifikacji. Nawet jeżeli rozwiązania innych firm, nie działające w chmurze, mają jakieś zabezpieczenia to mogą być one nieskuteczne w środowisku produkcyjnym. To trochę tak jak by kupić system alarmowy, przynieść go do domu i będąc z zawodu sprzedawcą w hurtowni motoryzacyjnej, instalować go samodzielnie. Taki system alarmowy sam może działać, ale popełnimy błędy np. w rozmieszczeniu czujek, ich konfiguracji, nie pomyślimy o odpowiednim zabezpieczeniu przed spaleniem przepięciowym itp. Olbrzymie znaczenie w ofercie IAI ma to, że nasi inżynierowie kontrolują środowisko produkcyjne od początku do końca. A zatem klient nie musi myśleć o zgraniu technologii sprzętowej, systemu operacyjnego i programu. Olbrzymie znaczenie ma również jednorodność środowiska, które wystawiane jest na próby z zakresu bezpieczeństwa, ale również stabilności i skalowalności każdego dnia. Jeżeli tylko zostanie coś niepokojącego jest przez nas wychwycone, wprowadzamy zmiany w całej chmurze, a więc dany problem wcale nie musiał być zgłoszony przez danego klienta, aby został u niego usunięty. Podsumowując, nie jesteśmy jak Microsoft który dostarcza Windows, który musisz móc instalować na wszystkim, ale jesteśmy jak Apple, który dostarcza sprzęt i doskonale zespolony z nim system operacyjny i programy. W ten sposób można taniej uzyskać wyższą jakość i większe bezpieczeństwo.

Czy istnieją zagrożenia specyficzne dla systemów w chmurze?

Nie istnieje coś takiego jak zagrożenia specyficzne dla chmur. Oczywistym jest to, że dostawca chmury musi doskonale znać się nie tylko na pisaniu programu, ale również na sieciach, administracji serwerami i wszystkim tym co jest potrzebne aby aplikacja webowa działała. Problem w tym, że większość posiadających sklepy internetowe, a nawet wiele firm piszących soft do prowadzenia sklepu internetowego, nie orientuje się za dobrze w kwestiach bezpieczeństwa. Większość ze sprzedawców internetowych skupia się na rejestracji w GIODO, SSL i wierzy, że firmy hostingowe załatwią za nich te kwestie. Tym czasem dobra firma hostingowa zapewnia bezpieczeństwo na poziomie systemu operacyjnego i usług w rodzaju serwera WWW. A główna słabość leży w budowie programu który instalowany jest w takim środowisku. W dzisiejszych czasach rzadko obserwuję spektakularne włamania, które jak w filmach po wpisaniu magicznej komendy w terminalu dają dostęp do wszystkiego. Dzisiejsze systemy operacyjne i serwery WWW są same w sobie mocno udoskonalone, zwłaszcza te oparte o Linux i Unix. Większość zagrożeń leży w źle napisanych programach.
Wiem, że oczekujesz ode mnie konkretów, więc podam parę popularnych ataków. Po pierwsze proponuję przyjrzeć się w swoich sklepach przyjrzeć protokołom wymiany danych, zwłaszcza komunikacji AJAX. Chociaż ciągle coś takiego jak zabezpieczenia przed SQL Injection czyli spreparowaniem danych wejściowych tak aby zmienić działanie zapytań SQL są aktualne. Jeżeli na tak prosty atak jest podatny kod sklepu internetowego, a dodatkowo użytkownik nie wyłączył wyświetlania błędów serwera WWW w oknie przeglądarki, to włam jest niemal gotowy i nikt nie musi rozgryzać struktury wywołań AJAX czy stosować innych skomplikowanych technik. Inny częsty błąd to nieodpowiednie uprawnienia do plików. W tym przypadku odgadując url np.www.mojsklep.pl/export/ceneo.xml nasz konkurent może śledzić na bieżąco nasze ceny w sklepie. Gorzej jeżeli w pliku który chcemy ukryć jest np. hasło do konta na Allegro. Inny częsty rodzaj błędu to niefiltrowanie danych HTML, przez co atakujący może spreparować np. w zamówieniu, w uwagach odpowiedni kod HTML który pozwoli przejąć mu sesję, a więc być zalogowanym do naszego panelu administracyjnego, aby samodzielnie oznaczyć zamówienie jako opłacone. W ten sposób niezauważenie może kupić np. laptopa wartego 10000zł nic za niego nie płacąc. I teraz niech każdy się zastanowi, czy jest pewien że takich zamówień nie miał? Jeżeli rozważy się taki scenariusz jako prawdopodobny, to wybranie tańszej o 10zł firmy, która nie ma odpowiedniego przygotowania do pisania odpowiednio zabezpieczonych skryptów, jest po prostu żenującą oszczędnością.

W oprogramowaniu o otwartym źródle sporą część wad i podatności odnajdują sami użytkownicy - dłubiąc w kodzie. Jak wygląda testowanie i wyszukiwanie luk w systemach modelu SaaS? Jak wygląda bezpieczeństwo Waszego systemu w porównaniu do rozwiązań „open source” czy „skryptów z pudełka”?

Wtedy gdy błąd został odnaleziony przez użytkowników jest już za późno, bo równie dobrze błąd ten mógł znaleźć wcześniej inteligentniejszy od przeciętnego sprzedawcy haker. Tylko, że on tego producentowi nie zgłosił i wykorzysta lukę do swoich celów. Dlatego nie można publikować słabej jakości kodu i czekać aż użytkownicy zgłoszą błędy. Trzeba śledzić fora hakerów, publikacje internetowe na temat bezpieczeństwa w programach, systemach operacyjnych i usługach. Jednym słowem, trzeba po prostu dbać o kwestie bezpieczeństwa. Każdy sprzedawca internetowy musi albo poświęcać czas na poszerzanie wiedzy w tym zakresie, albo skorzystać z SaaS gdzie płaci za to, aby inni się o to martwili, albo dysponować większym budżetem i zatrudnić specjalistów od bezpieczeństwa.
Innym problemem programów typu open source, jest to, że wielu użytkowników nie instaluje poprawek. Oczywiste dla każdego jest to, że trzeba to robić, ale mało kto to robi. Widzimy to sami nawet u naszych klientów, którzy sami instalują aplikacje pomocnicze dla Windows. Musimy niejednokrotnie przypominać im aby zainstalowali wersję nowszą niż ta sprzed roku. Wtedy gdy dostawca systemu aktualizuje platformę SaaS, wszyscy korzystają z poprawionego kodu. Tym czasem w skryptach open source, szczególnie tych przerobionych, ludzie nie łatają odpowiednio szybko swoich sklepów, o ile w ogóle kiedykolwiek to robią. W tym momencie poprawki do kodu są nanoszone przez producenta programu, ale w konkretnym sklepie tego nie widać. Za to wszyscy wiedzą o tych lukach, bo są publicznie dostępne. Jestem w stanie zaryzykować zakład, że ponad 99% sklepów internetowych działających na pudełkowych programach open source nie jest w najnowszej wersji, przez co znane luki można od ręki wykorzystać do ich skompromitowania.

Czy w Polsce notowane są przypadki cyber-ataków na sklepy internetowe? Czy zagrożenia są na tyle poważne, aby właściciele sklepów zaprzątali sobie nimi głowę?

Polska nie jest innym krajem jeżeli chodzi o bezpieczeństwo niż USA czy Rosja. Myślenie że hakerzy są tylko w amerykańskich filmach, a w Polsce wszyscy są naiwni i nic złego nie może się stać, może nabić sprzedawcy internetowemu wielkie kuku. Mam wrażenie, że wielu sprzedawców bezpieczeństwo mało obchodzi, bo przecież jak ktoś ukradnie dane klientów to im nic nie ubędzie. Bezpieczeństwo traktowane jest instrumentalnie w postaci checklisty rzeczy do zrobienia. Tym czasem o bezpieczeństwie trzeba zawsze myśleć kompleksowo.
Znana nam z ostatnich miesięcy forma ataku jak z filmu o włoskiej mafii. Atak polega na wykorzystaniu botnetu do paraliżowania sklepu atakiem DOS (Denial of Service) czyli wysyłaniem mnóstwa pakietów. Największe ataki, jakie widzieliśmy używały nawet kilku tysięcy komputerów zombie do atakowania. Po krótkiej demonstracji która paliżuje sklep, następuje kontakt ze strony atakującego z roszczeniem przesłania np. 1000$ poprzez Western Union, bo inaczej sklep będzie bombardowany non-stop. Jeżeli sklep nie korzysta z SaaS lub nie ma sztabu fachowców to zwyczajnie nie będzie w stanie obronić się przed takim atakiem i jeżeli chce pozostać w grze, musi płacić. Oczywiście za miesiąc nawet Ci sami sprawcy zażądają ponownego haraczu. W ten sposób sprzedawca internetowy utrzymuje swoimi pieniędzmi organizacje przestępcze, które mają większą motywację do pisania kolejnych wirusów i powiększania wpływów botnetu.
Mniej szkodliwi są atakujący, którzy w zamian za opłatę pomogą nam usunąć lukę w bezpieczeństwie. Zazwyczaj jednak taka „usługa” obejmuje jedną lukę. Jednak sporo to kosztuje i łatanie systemu w ten sposób może sklep słono kosztować. I teraz należy sobie odpowiedzieć na pytanie, czy niewielka opłata dla usługodawcy nie jest lepsza niż liczenie na szczęście i czekanie aż źli ludzie dostrzegą sklep i zaczną wysysać z niego pieniądze?

Reszta do przeczytania na http://www.aukcje.org/archives/2010/09/13/bezpieczestwo-w-sklepie-internetowym.htm

 

 

Technologia SaaS - zalety i potencjalne problemy techniczne

pfornalski

26 stycznia 2010r. występowałem przed kadrą naukową Wydziału Informatyki. Podczas tej specjalnej rady naukowej, starałem się zachęcić do zmiany profilowania nauki na informatyce, aby kierować więcej edukację studentów na problemy cloud computingu. Ponieważ ciągle w głowach wielu profesorów web-aplikacje, to strony HTML, postanowiłem pokazać pewne klasy problemów informatycznych, z którymi nie da się poradzić przy pomocy tego co stosuje się do obliczeń naukowych.

Tak się złożyło, że na tym wystąpieniu był też Maciej Jankowski, któremu prezentacja tak się spodobała, że stwierdził, że koniecznie muszę 3 dni później zaprezentować to samo. I tak oto prawie ta sama prezentacja została pokazana ponownie, tym razem ponad 100 osobom na Netcampie.

Film niestety nie pokazuje wszystkiego, bo "taśma się skończyła". A szkoda, bo w drugiej części prezentacji pada jeszcze więcej technicznych konkretów. Mam nadzieję jednak, że będzie okazja jeszcze w innym mieści powtórzyć ten temat i organizatorzy będą mieli dłuższą taśmę. Swoją drogą cieszę się, że ta prezentacja została przeze mnie przeprowadzona na taki temat, bo od tej pory na Netcampie zaczęło się pokazywać dużo fajnych, technicznych prezentacji. Dlatego polecam przejrzenie także innych materiałów na stronie www.netcamp.net.pl

Poniżej slajdy z prezentacji i nagranie. Enjoy.

i film ... Jeżeli ktoś nie chce dowiadywać się czym jest SaaS, może przeskoczyć o kilka minut do przodu.


Trudności towarzyszące implementacji systemów SaaS
Załadowane przez: netcamp. - Odkryj więcej fajnych wideo technologicznych i naukowych.

© Polski e-commerce i zarządzanie e-firmą
Blox.pl najciekawsze blogi w sieci