Komentarze do: Synchroniczna asynchroniczność

Autor: Grzegorz

Grzegorz — Fri, 27 Oct 2017 00:06:12 +0000

W odpowiedzi do Michał Załęcki. FAjnie poczytać komentarze sprzed 4 lat, a mam wrażenie że prehitoria :)

Autor: Przydatne linki | Grzegorz Laszczyk Blog

Przydatne linki | Grzegorz Laszczyk Blog — Tue, 21 Mar 2017 12:55:01 +0000

[…] Van Slaars stoeffel/awesome-fp-js: A curated list of awesome functional programming stuff in js Synchroniczna asynchroniczność – webroad.pl Understanding Asynchronous JavaScript Callbacks Through Household Chores The Evolution of […]

Autor: Eduweb.pl – frontendowy bootcamp — WebKrytyk.pl

Eduweb.pl – frontendowy bootcamp — WebKrytyk.pl — Sun, 06 Nov 2016 12:33:53 +0000

[…] do wytłumaczenia niż jQuery. Pomijam fakt, że nie da się tłumaczyć Ajaksa bez wytłumaczenia asynchroniczności – czego doskonałym dowodem jest twierdzenie, że przypisanie rezultatu $.getJSON do zmiennej nie […]

Autor: Wpadki i wypadki #7 — WebKrytyk.pl

Wpadki i wypadki #7 — WebKrytyk.pl — Fri, 04 Nov 2016 20:05:20 +0000

[…] może Ajax jest zaawansowany? Tutaj mam pewien dylemat: w końcu trzeba zrozumieć asynchroniczność. Z drugiej strony, w dobie Fetch API Ajax stał się niesamowicie prosty. Poza tym tak po prawdzie […]

Autor: Michał Załęcki

Michał Załęcki — Tue, 24 Dec 2013 20:58:00 +0000

W odpowiedzi do Comandeer. No jeżeli zależy nam na relacji to szukamy innego rozwiązania. API serwera mnie nie odrzuca oczywiście, w sumie tylko tak rozwiązuje zapytania związane z AJAXem. Mimo wszystko parę ciekawych zastosowań bym znalazł.

Autor: Comandeer

Comandeer — Tue, 24 Dec 2013 15:43:00 +0000

W odpowiedzi do Michał Załęcki. >No jak każdy ma swoją tabelę i tylko do niej uprawnienia to nie widzę problemu. ale czy to na pewno wówczas jest wciąż relacyjna DB? bo to już mi przypomina model obiektowy/dokumentowy znany np. z MongoDB poza tym - 1k userów = 1k tabel w bazie. nie wygląda to najciekawiej ;) zresztą nie rozumiem co tak bardzo odrzuca Cię w połączeniu się z API serwera? POST /user/id/2 GET /user/id/2 PUT /user/id/2 DELETE /user/id/2 cholernie czytelne i IMO wygodniejsze niźli bezpośrednie babranie się z bazą danych. + uniwersalne - można transparentnie zmieniać leżącą poniżej bazę danych (ba, całą implementację serwera) a przeglądarka dalej po prostu wysyła żądania pod te same adresy.

Autor: Michał Załęcki

Michał Załęcki — Tue, 24 Dec 2013 15:38:00 +0000

W odpowiedzi do Comandeer. No jak każdy ma swoją tabelę i tylko do niej uprawnienia to nie widzę problemu. goto w PHP 5.3 nie jest tym samym goto z Basica, ważny jest kontekst. Doceniam możliwości. Nie jestem przyzwyczajony do używania goto gdzie indziej niż w plikach wsadowych, wiec potraktowałem to jako ciekawostkę. Jednak goto ma już lepsze alternatywy, a bezpośredniego połączenia z bazą danych nie ma :( > jeśli jesteś na tyle szalony, żeby napisać driver dla MySQL, to droga wolna ;) To ja już wolę pisać nowy kontroler :P

Autor: Comandeer

Comandeer — Tue, 24 Dec 2013 15:27:00 +0000

W odpowiedzi do Michał Załęcki. >Zawsze lepiej mieć możliwość i z niej nie skorzystać niż być jej pozbawionym. rozumiem, że dlatego lubisz goto w PHP? ;) >Jak zabezpieczyć? Uprawnieniami. fajnie, tylko, że nawet zwykłe uprawnienie do odczytu może posłużyć co poniektórym do wyciągnięcia nie tylko swoich danych W3C pracuje nad raw sockets, więc jeśli jesteś na tyle szalony, żeby napisać driver dla MySQL, to droga wolna ;) ja jednak z tego na pewno nie skorzystam

Autor: Michał Załęcki

Michał Załęcki — Tue, 24 Dec 2013 15:20:00 +0000

W odpowiedzi do Comandeer. Jak zabezpieczyć? Uprawnieniami. Co za problem, by użytkownik aplikacji mobilnej miał swoje konto i tabelę? Dla aplikacji np. firmy jak znalazł. Zawsze lepiej mieć możliwość i z niej nie skorzystać niż być jej pozbawionym.

Autor: Comandeer

Comandeer — Tue, 24 Dec 2013 14:56:00 +0000

W odpowiedzi do Michał Załęcki. Nie sądzę, żeby się pojawiło. przeglądarka jest zamkniętym środowiskiem, które jedynie komunikuje się z serwerem. poza tym bardzo mnie ciekawi jakbyś taką bazę zabezpieczył w JS ;) przecież w kodzie będą leżeć surowe dane dostępu do bazy a ze specyficzności przeglądarki dostęp musiałby być z każdego możliwego miejsca. bezpieczeństwo jest zerowe. jeśli chodzi o JS z poziomu przeglądarki, ono powinno się komunikować z serwerem tylko przy pomocy API (tu i tak leci autoryzacja choćby przy pomocy OAuth 2.0). REST + JSON są na tyle przyjemne, że dodawanie danych do bazy nie jest szczególnie udziwnione. a na pewno o wiele bezpieczniejsze a jeśli mamy WebSQL lokalnie, to przecież można zmapować odpowiednie fragmenty bazy serwera na kliencie i synchronizować (o czym już wspominałem). zresztą łączenie się bezpośrednio z klienta do bazy danych na serwie moim zdaniem narusza ACID. w przypadku mobilnych jest to tym bardziej widoczne, bo mamy często słabą Sieć, w dodatku często się rozłączającą. de facto bez dodatkowych mechanizmów sprawdzania spójności danych itd (czyli system kontroli wersji) takie rozwiązanie byłoby po prostu głupotą (cały paradygmat offline first, czyli PE 2.1) jak dla mnie bardzo słaby pomysł - zwłaszcza, że istniejące rozwiązania sobie z tym bez problemu radzą, są łatwe w obsłudze i dodatkowo zapewniają większą spójność danych.

Autor: Michał Załęcki

Michał Załęcki — Tue, 24 Dec 2013 14:48:00 +0000

W odpowiedzi do Comandeer. No mam WebSQL, ale ono działa lokalnie. Jeżeli napiszę app w C# na WP to mogę z MySQL się łączyć. Nie widzę więc przeciwwskazań. Nie wiem dlaczego w JS tego brakuję. Liczę, że się w niedalekiej przyszłości taka funkcjonalność pojawi.

Autor: Comandeer

Comandeer — Tue, 24 Dec 2013 14:45:00 +0000

W odpowiedzi do Michał Załęcki. >a ja bym chciał to z browsera :P nie przesadzajmy... poza tym masz ;) WebSQL w webkitach i IndexedDB w reszcie :D >Np. jeżeli mam serwis to nie mogę zrobić appki w HTML5 + JS bez przygotowania backendu. obecnie można już robić appki, gdzie backend służy tylko do inicjalnego wysłania pliku i już. a jeśli musimy mieć dane w bazie na serwie, to są specjalne biblioteki do synchronizacji (de facto takie mini systemy kontroli wersji, cholernie potężne ustrojstwo).

Autor: Michał Załęcki

Michał Załęcki — Tue, 24 Dec 2013 14:41:00 +0000

W odpowiedzi do Comandeer. PDO jest poza SPL, no i jest najwydajniejszym sterownikiem baz danych, wręcz podstawową funkcjonalnością, w końcu to PHP Data Objects, a że kapitalnie działa to tylko oklaski dla autorów. Samo SPL jest małe, głównie iteratory , ArrayObject i wyjątki. No cały czas jesteśmy przy nodzie, a ja bym chciał to z klienta :P, wiec na razie bez mostków się nie obejdę. Szczególnie mnie to boli jeżeli chodzi o urządzenia mobilne. Np. jeżeli mam serwis to nie mogę zrobić appki w HTML5 + JS bez przygotowania backendu. Czyli muszę dodać kontroler specjalnie do obsługi aplikacji mobilnej.

Autor: Comandeer

Comandeer — Tue, 24 Dec 2013 13:51:00 +0000

W odpowiedzi do Michał Załęcki. >nie są wbudowane jak dla mnie PHP ma zbyt rozbudowaną bibliotekę standardową. takie PDO powinno być właśnie "doinstalowalne" osobno, w razie potrzeby. >Brakuje np. odpowiednika PDO w tym, co zalinkowałeś, jest obsługa prepared statements, więc czego chcieć więcej? ;) wystarczy trochę poszperać, żeby znaleźć ORM-y, np. https://npmjs.org/package/anydb-sql >Nie jestem przekonany do wyższości noda.js nad ASP.NET czy PHP5 ale warto go poznać ;) choćby z powodu takich narzędzi jak LESS, Stylus, Grunt, Bower, Yeoman... nawet przecież PHP-owy composer jest wzorowany na menedżerze pakietów node'a

Autor: Michał Załęcki

Michał Załęcki — Tue, 24 Dec 2013 13:40:00 +0000

W odpowiedzi do Comandeer. Z WP, aż tak źle nie jest, wystarczy dokumentacja, pisana z resztą bardzo skrupulatnie, wiem, używam. Poza tym, jedna z najlepszych społeczności w ogóle. Nie jestem przekonany do wyższości noda.js nad ASP.NET czy PHP5 więc, tak, dla mnie pozostanie jeszcze długo (a może krócej niż mi się wydaje) "tylko" browserowy, chodź takie projekty jak Ghost są ciekawymi alternatywami i pokazują, że node.js warto się interesować. Co do rozwiązań osób trzecich. Np. jak chcesz mieć między bazowy mechanizm, dzięki któremu połączysz się z różnymi bazami danych to sięgasz po JugglingDB - rozwijany przez prywatną firmę, nie jak PDO, rozwijany przez samych twórców PHP. Bardzo ciekawy jestem kolejnych artykułów o node.js. Może coś "from scratch"?

Autor: Comandeer

Comandeer — Tue, 24 Dec 2013 13:19:00 +0000

W odpowiedzi do Michał Załęcki. > Z tą hermetyzacją, a już w ogóle natywną, w JavaScript bym uważał. Bardzo fajnie wygląda specyfikacja modułów w ES 6, wyraźnie wzorowana na tej znanej z CommonJS. >nadal brakuję dużo do modyfikatorów dostępu nie byłbym tego taki pewien ;) od dawna szuka się sposobu na protected a w ES 6 nadchodzi Object.observe, które powinno wreszcie problem rozwiązać. >W JS nie jest jeszcze tak źle, szczególnie jeżeli masz doświadczenie z WordPressem. to coś w WP jest tak niemożliwie kalekie... to niby jest system eventowy, ale... no nie da się tego używać ;) >Jednak jak chcesz zrobić coś większego musisz wspomagać się rozwiązaniami osób trzecich. tzn? nie bardzo wiem o czym mówisz >Szkoda, że JS nie dorobił się API, które pozwalało by na efektywne łączenie się z zewnętrznymi bazami danych (bez duetu np. PHP+JSON). przecież powstały pure-JS rozwiązania do pracy z wieloma bazami, m.in. MySQL >Jakieś dobre pomysły na utrzymywanie kodu? choćby już wspomniany wcześniej system modułów z ES6, który obecnie jest "profillowany" przez AMD i moduły CommonJS. mam wrażenie, że dla Ciebie JS to wciąż głównie język browserowy. dla mnie już od dawna nie >Miło przywitać nowego redaktora :) nie chwalmy dnia... ;) to dopiero jeden artykuł.

Autor: Comandeer

Comandeer — Tue, 24 Dec 2013 13:03:00 +0000

W odpowiedzi do Mr.Mr. Niestety, druga część skupi się na node.js ;)

Autor: Michał Załęcki

Michał Załęcki — Tue, 24 Dec 2013 08:29:00 +0000

> hej, mamy natywną enkapsulację
Z tą hermetyzacją, a już w ogóle natywną, w JavaScript bym uważał. Chyba najlepszym rozwiązanie, będzie i tak zwracanie „api”, powiedzmy… przez funkcję-klasę, ale nadal brakuję dużo do modyfikatorów dostępu.
> W przypadku bardziej skomplikowanych aplikacji grzęźniemy w callbackach
powsadzanych w callbacki, które z kolei są odpalane w callbackach innych
callbacków.
W JS nie jest jeszcze tak źle, szczególnie jeżeli masz doświadczenie z WordPressem. Tam oddzwanianie jest na porządku dziennym, czasami nawet całą klasą, nie tylko pojedynczą funkcją.

Do JS mam mieszane uczucia. Jest świetnie puki pracujesz offline czy używasz AJAXa, robisz jakieś animacje, dodajesz wodotryski, których robienie w CSS jest niemożliwe, albo niewarte zachodu. Jednak jak chcesz zrobić coś większego musisz wspomagać się rozwiązaniami osób trzecich. Szkoda, że JS nie dorobił się API, które pozwalało by na efektywne łączenie się z zewnętrznymi bazami danych (bez duetu np. PHP+JSON). Utrzymanie większych partii kodu też do najłatwiejszych nie należy. Jakieś dobre pomysły na utrzymywanie kodu? „Przestrzenie nazw” czy coś jeszcze?

Miło przywitać nowego redaktora :)

Autor: Mr.Mr

Mr.Mr — Mon, 23 Dec 2013 22:11:00 +0000

TL;DR – chociaż pewnie był ciekawy :P

A tak na serio to bardzo interesujące. Ja jestem chory jak słyszę AJAX, więc te wszystkie sprawy są mi bliskie sercu.

Czekam na następną część!