Za możliwość wzięcia udziału w tej konferencji Jest to dla mnie bardzo ważne doświadczenie bo pierwsze!
Coś mocnego na początku
Straty, przestraszyć + konsekwencja + strata możliwości wykorzystania
-
Pytania???
- o framework, czym się różnią?
- internet, Http, czy rozumiesz naturę?
-
growth hacking
-
powerpoint łapie uwagę
-
zlecić prezentację
-
frontend musi być ładna
- kolory
- dźwieki
- nowe doświadczenia
-
zrobić na jLoads interaktywną prezentację, która będzie pokazywała możliwości
zamiast robić fotosy, będę pokazywał rezultaty tego jak on działa
Interakcja, żeby mieć relacje na linkedin po prezentacji
- online
- pierwsza konferencja
- pierwsza publiczna prezentacja na żywo
- mamy dziś trochę do zrobienia
- zrobiłem kilkanaście ticketów
- czas
- deadline jest na 45 MInut, jak sie nie wyrobimy to nie dojdziemy do konca a tam jest nagroda do wygrania
na sam koniec
Nagroda
- Donate (kwotew niespodzianka) dla 10 pierwszych co zrobia pierwsze tickety, każdy kolejny poza dostanie donate (pocieszenia) albo ksiązka
- napisac do ksiegarni, ktora sie zgodzi na takie rozwiazanie bedzie to polegalo na tym, ze kazdy kto zrobi commit/push (kodu/opisu) na jLoads
dostanie rabat na jedną książkę, sponsorwany przez firme Softreck
- O autorze
- O Projektach OpenSource: ApiFoundation
- O Organizacji, Firmie Softreck
Empiryzm, nauka przez doświadczanie Wiedza (o doświadczeniu w sprawdzeniu prawdziwości teorii/informacji)
knwowledge = null;
function experience(byte[] information) {
for(n=0; information[no]no++;){
result[no] = information[no] === true;
knowledge.add({
information: information[no],
result: result[no],
kontekst: ....
});
}
return knowledge;
}
knowledge = experience( information );
- użycie, doświadczenie, zrozumienie, ulepszenie
Po dekadzie developmentu, postanowiłem zebrać razem wszystkie przemyślenia Od kilku lat notorycznie publiuję kod.
Zmiana następuje beze mnie, ale mogę zrozumieć/uchwycić trend wynikający z wielu nieznanych mi czynników
Dlatego ten experyment
Środowisko i jego wpływ
Hobby
Kariera
O firmie
- skillset
- mindset
przedstawienie punktu widzenia osoby, która nie jest rasowym programistą.
Każdy z nas ma w różnych tematach różne punkty widzenia:
- Entuzjasta
- Nauczyciel
- Innowator
Help your engineers become the best version of themselves, grow great teams, have a place people want to work, be the leader people want
- Software development
- DevOps
- Architektura oprogramowania
- Psychologia/Socjologia
- tworzenie abstrakcyjnych modeli rzeczywistosci
- testowanie i proptotypowanie modeli
- poprzez doświadczanie - uczenie sie na modelach
- automatyzacja
- optymalizacja
- Lean Management
- skomplikowane ale procesy
- proste zasady obsługi
-
nauka poprzez uzycie
-
działanie
- "The best way to predict your future is to create it"
-
"Nie chcesz po dobroci? to Ludzie Cię nauczą ..."
-
Development
- Systems and Software Quality
- Wieczorek, Martin, Vos, Diederik, Bons, Heinz
- Systems and Software Quality
-
Lean Management
-
Architecture
- Clean Architecture: A Craftsman's Guide to Software Structure and Design
- Robert C. Martin
- The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations
- Gregor Hohpe, Bobby Woolf
- Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions
- Gene Kim, Patrick Debois, John Willis, Jez Humble
- Clean Architecture: A Craftsman's Guide to Software Structure and Design
-
Startups
-
Architecture
-
Softreck
-
Entuzjasta
-
ApiFoundation
-
jLoads
- Hardware Tools
- Software Tools
- rozbudowa
Help your engineers become the best version of themselves:
- grow great teams,
- have a place people want to work,
- be the leader people want
- skillset
- mindset
Przedstawienie punktu widzenia osoby, która nie jest rasowym programistą.
Każdy z nas ma w różnych tematach różne punkty widzenia:
- Entuzjasta
- Nauczyciel
- Innowator
Cieszy sie wszystkim co nowe w danym obszarze tematycznym dzieli się danymi technicznymi i sposobem użycia Skupienie na innowacyjności
Skupienie na definicji, logice, znaczeniu Czasem to dalszy etap entuzjazmu stara się wytłumaczyć jak można tego używać
Skupienie na miejscu w przestrzeni, jej wykorzystaniu, brakach, możliwościach Mając informacje o tym stara się to zmienić lub zainicjowac zmianę
- plastelina
- klocki w 2d
- klocki w 3d - niekończący się tetris => HTTP i STREAMOWANIE
Eksperyment jako inspiracja do odrywania czegoś poza horyzentom obecnych trendó. Uchwycenie teczhnicznej natury www
- Skupienie sie na tym co zmienne, aby umieć odnaleźć naturę, zrozumieć i wykorzystać jako funkcję
Pierwszy zamysł był taki aby możliwe było uruchomienie na tym samym kodzie aplikcji w różnym środowisku, różnej domenie
- refaktorywzacja -> reużycie
- przejmowanie po kimś projektów, chęć dokoknania drobnych kosmetycznych zmian
- a czasem przemeblowanie cłaościowe, ale z użyciem już napisanego kodu wykorzystując modularyzacje
Z punktu widzenia architektury, ostatnio dużo się w tym temacie zmienia
JS jako monopolista, ucieszka w abstrakcje nie załatwia problemu, Specyfika JS jest niedoceniona to jezyk do prototypowania !
chciałem pozostać natywny w celu zapewnienia Dlaczego chciałem to stworzyć?
- natura świata
- ludzkie modele abstrakcyjne
- postrzeganie
- zastosowanie
- problemy
użycie, doświadczenie, zrozumienie, ulepszenie
Po dekadzie developmentu, postanowiłem zebrać razem wszystkie przemyślenia Od kilku lat notorycznie publiuję kod.
Zmiana następuje beze mnie, ale mogę zrozumieć/uchwycić trend wynikający z wielu nieznanych mi czynników
Dlatego ten experyment
stremowanie
Software devlopment
- HTTP
- protokoły
Wiele protokołów jest ksupionych na dostarczaniu treści do urządzenia a nie jej tworzeniem i dostosowaniem pod klienta.
Punktem wspólnym dla twórcy, nadawcy i jest serwer, gdzie dane są definiowane
Twórca - tworzy -> repozytorium, pakowanie w paczki
- serwer twórcy przygotowuje je pod własną domeną lub dystrybutora do wysyłki w postaci: HTTP Request
Dystrybutor treści zbiera i formatuje, transmituje
Nadawca - nadaje wiadomosć zarządza danymi, planuje przygotowuje je do wysyłki w postaci: HTTP Request
Odbiorca
- odbiera i daje informacje zwrotne: w postaci HTTP Response
Twórca | Nadawca | Odbiorca |
---|---|---|
Cel | Content Cell | Content Cell |
Tech | Content Cell | Content Cell |
technika dostarczania informacji multimedialnej przez Internet, od dostawcy transmisji strumieniowej do użytkownika, w sposób nieprzerywany.
Projektowanie protokół sieciowy do obsługi mediów strumieniowych rodzi wiele problemów.
- UDP
- RTSP
- RTCP
- RTP
protokół datagramów użytkownika
wysyła strumień mediów w postaci szeregu małych paczek. Jest on prosty i skuteczny. Jednak nie ma mechanizmu w protokole, aby zapewnić stały przepływ danych.
Odnosi się to do aplikacji wykrywającej utratę, uszkodzenie oraz odzyskanie danych przy użyciu technik korekcji błędów.
do strumieniowego przesyłania multimediów w sieciach, tj.:
Slides for Conference about jLoads
HTTP (ang. Hypertext Transfer Protocol) – protokół przesyłania dokumentów hipertekstowych to protokół sieci WWW (ang. World Wide Web). Obecną definicję HTTP stanowi RFC 2616 ↓. Za pomocą protokołu HTTP przesyła się żądania udostępnienia dokumentów WWW i informacje o kliknięciu odnośnika oraz informacje z formularzy. Zadaniem stron WWW jest publikowanie informacji – natomiast protokół HTTP właśnie to umożliwia.
Jest zaliczany do protokołów bezstanowych (ang. stateless) z racji tego, że nie zachowuje żadnych informacji o poprzednich transakcjach z klientem (po zakończeniu transakcji wszystko "przepada"). Pozwala to znacznie zmniejszyć obciążenie serwera, jednak jest kłopotliwe w sytuacji, gdy np. trzeba zapamiętać konkretny stan dla użytkownika, który wcześniej łączył się już z serwerem. Najczęstszym rozwiązaniem tego problemu jest wprowadzenie mechanizmu ciasteczek. Inne podejścia to m.in. sesje po stronie serwera, ukryte parametry (gdy aktualna strona zawiera formularz) oraz parametry umieszczone w URL-u (jak np. /index.php?userid=3).
https://pl.wikipedia.org/wiki/Hypertext_Transfer_Protocol
Media strumieniowe – technika dostarczania informacji multimedialnej przez Internet, od dostawcy transmisji strumieniowej do użytkownika, w sposób nieprzerywany. Media strumieniowe opierają się na transmisji skompresowanych danych multimedialnych
Projektowanie protokół sieciowy do obsługi mediów strumieniowych rodzi wiele problemów. Protokoły strumieniowe, takie jak protokół datagramów użytkownika (UDP), wysyła strumień mediów w postaci szeregu małych paczek. Jest on prosty i skuteczny. Jednak nie ma mechanizmu w protokole, aby zapewnić stały przepływ danych. Odnosi się to do aplikacji wykrywającej utratę, uszkodzenie oraz odzyskanie danych przy użyciu technik korekcji błędów. W tym celu zostały zaprojektowane protokoły poziomu aplikacji specjalnie do strumieniowego przesyłania multimediów w sieciach, tj.:
Real-time Streaming Protocol (RTSP), Real-time Transport Control Protocol (RTCP), Real-time Transport Protocol (RTP).
https://pl.wikipedia.org/wiki/Media_strumieniowe
RTSP (ang. Real Time Streaming Protocol) jest protokołem poziomu aplikacji, mającym za zadanie sterowanie dostarczaniem danych czasu rzeczywistego. Mimo że jest on wręcz powszechnie stosowany w aplikacjach związanych z przesyłaniem danych multimedialnych (pierwszy dokument RFC datowany jest na kwiecień 1998), nie jest on jeszcze ustanowionym oficjalnie standardem, lecz jedynie jego propozycją ulegającą ciągłym zmianom i korektom (ang. draft). Protokół RTSP dostarcza użytkownikowi jakby elastycznego szkieletu, bazy, która może być rozwijana i dopasowywana do potrzeb użytkownika, aby umożliwić sterowanie transmisją na żądanie danych czasu rzeczywistego takich jak audio i wideo. Źródła danych mogą zawierać dane dwojakiego rodzaju: materiały odtwarzane „na żywo” oraz gromadzone w bazie danych do późniejszego odtworzenia. Protokół w założeniu jego twórców (m.in. firma RealNetworks) ma służyć kontroli jednocześnie wielu sesji transmisji danych, dostarczając środki do wyboru kanału transportowego jak np. UDP, rozgałęziany UDP i TCP oraz środki do wyboru odpowiednich mechanizmów działania opartych na protokole RTP.
Protokół RTSP steruje strumieniem, który może być przesyłany za pomocą odrębnego protokołu, niezależnego od kanału kontrolnego. Np. sterowanie RTSP może pojawiać się w połączeniu TCP, gdy dane przesyłane są z użyciem protokołu UDP. Tym sposobem dane dostarczane są nieprzerwanie, nawet gdy żądania RTSP nie zostaną odebrane przez serwer mediów. Równocześnie pojedynczy strumień mediów może być kontrolowany przez żądania RTSP wysyłane sekwencyjnie na różne połączenia TCP. Jednakże serwer musi zachowywać tzw. stan sesji, by móc dobrze kontrolować współdziałanie żądań RTSP ze strumieniem.
Poniżej przedstawiono sposoby (komendy) odgrywające główną rolę w definiowaniu przemieszczeń i użycia zasobów strumienia na serwerze:
SETUP – powoduje umieszczenie zasobów serwera w strumieniu i utworzenie sesji RTSP, PLAY – uruchamia transmisję danych zawartych w strumieniu po wcześniejszej komendzie SETUP, PAUSE – okresowo zatrzymuje strumień (transmisję) bez zwalniania zasobów serwera, REDIRECT – wykrywa, że sesja powinna zostać przeniesiona na nowy serwer (do innego miejsca), PING – chroni sesje przed przeterminowaniem (ang. timeout), TEARDOWN – zwalnia zasoby serwera połączone ze strumieniem. Sesja RTSP zostaje przerwana. GET_PARAMETER – pobiera wartości wybranych parametrów dla URI, może być użyte do testowania dostępności klineta lub serwera SET_PARAMETER – ustawia wartości wybranych paramertów dla URI OPTIONS DESCRIBE RECORD ANNOUNCE Komendy używane przez protokół RTSP wykorzystują pola nagłówka sesji, aby zidentyfikować sesję RTSP, której stan jest zmieniany. Serwer generuje identyfikatory sesji w odpowiedzi na żądania SETUP.