KolejnyWykopowyJanusz
KolejnyWykopowyJanusz
  • 512
Dyskryminacja wzrostowa mężczyzn to fakt!

link do artykułu: http://www.jonathanrauch.com/jrauch_articles/height_discrimination_short_guys_finish_last/

Wnioski:

1) Wysokim przypisuje się pozytywne cechy charakteru (dojrzały, inteligentny, dominujący, pewny siebie) a niskim negatywne (dziecinny, uległy, nieśmiały, wycofany)

2) W wyborach prezydenckich prawie zawsze wygrywa wyższy kandydat (w Polsce wyższy Komorowski wygrał z Kaczyńskim, a z Komorowskim wygrał wyższy od niego Duda)

3) Większość prezesów dużych firm to ludzie wysocy, jest ich tam znacznie więcej niż w ogólnej populacji

4) Niscy
KolejnyWykopowyJanusz - Dyskryminacja wzrostowa mężczyzn to fakt! link do artykułu...

źródło: comment_Uy0ZBDA4jLdmqIIVOE6v1EO1CsBRnkAr.jpg

Pobierz
oMatej
oMatej
  • 0
Ale powiedzmy sobie szczerze - ciężko, żeby osoby wysokie nie zarabiały więcej skoro:

- Nie są w stanie sobie kupić ciuchów w praktycznie żadnej sieciówce;
- Nie są w stanie przejść przez przeciętne drzwi bez schylania się;
- Nie mieszczą się w przeciętnych rozmiarów łóżku;
- W zasadzie nie ma opcji na wygodne poruszanie się komunikacją miejską;
- A i przy zakupie samochodu też nie jest tak różowo;
- ...

Ciężko byłoby
  • Odpowiedz
beer_man
beer_man
  • 1
Już #!$%@?ąc od tego czy warto/nie warto uczyć się #javascript (Sry. za wołanie, nie będę raczej tego nagminnie używał) Ale tu też mam pytanie czy nazewnictwo jest aż tak istotne? Tzn. uczyć się tych pojęć wszystkich czy w praktyce i tak to wejdzie w łeb? Tzn. Zainspirowany innym Mirkiem (sry, nie pamiętam nicku) próbuję się uczyć #js od tego samuraja z YT i o dziwo rozumiem co się dzieje. Ale dobra do
oMatej
oMatej
  • 1
@beer_man: tak, jest coś takiego jak NPM, gdzie jest kilkaset tysięcy jakichś modułów / bibliotek, które możesz sobie zaciągać i wykorzystywać w swoich projektach.
  • Odpowiedz
oMatej
oMatej
  • 4
Próbuję stworzyć własny OAuth serwer, ale nie jestem pewien czy to w jaki sposób chciałbym zbudować bazę danych ma jakiś większy sens, a także tego, czy dobrze rozumiem sposób, w jaki miałyby być obsługiwane poszczególne sposoby autoryzacji użytkowników / klientów.

Aktualnie mam w ten sposób wyglądający schemat bazy danych:
https://i.imgur.com/CHuwz5f.png
Chciałbym, żeby ten serwer autoryzacyjny wspierał obecnie trzy sposoby autoryzacji: Authorization Code, Client Credentials oraz Resource Owner Password Credentials.

1.
oMatej
oMatej
  • 0
@xetrov: jak teraz tak na to patrzę, to w sumie widzę, że zapomniałem między innymi o sytuacji, w której aplikacja zewnętrzna w adresie przekaże scope=x,y,z.

W takiej sytuacji powinna chyba powstać relacja między access_tokenem, a oauth_scopes. No ale właśnie - skoro ja chciałbym używać JWT, nie mam w bazie tabeli dla tokenów.

A i tak pewnie nie przewidziałem lub źle podszedłem do dziesiątek innych rzeczy (╥﹏
  • Odpowiedz
oMatej
oMatej
  • 0
@Zaszczyk: tak, też to widziałem. Widziałem też implementacje, które z tego korzystają (m.in. Laravel Passport). Niestety, problemem jest - przynajmniej w mojej opinii - ubogość, jeśli chodzi o schematy baz danych (ewentualnie same migracje, jak np. w Laravelu). Najgorsze jest to, że porównując różne implementacje - każda wygląda zupełnie inaczej, przez co strasznie ciężko jest się połapać w tym co jest takim "must have".

Stąd mój schemat. Jest on takim zlepkiem
  • Odpowiedz
oMatej
oMatej
  • 0
@Zaszczyk: tak, wiem, że OAuth nie powinien handlować rolami. Ale chciałbym umieścić je również w access_tokenie, żeby przeglądarka użytkownika też miała do nich dostęp, a przy okazji pozostałe mikroserwisy nie musiały odpytywać o role bazy danych przy każdym zapytaniu.

Jeśli chodzi o komunikację wewnętrzną - ok, przekazujesz jakiś tam token jako nagłówek. Ale co teraz z tokenem użytkownika? Jakiś głębiej zagnieżdżony mikroserwis w ogóle go nie dostaje? Więc zakładasz, że
  • Odpowiedz
trustME
trustME
  • 4
Mirki, robię logowanie / rejestrację przez Google i Facebook.
Na froncie używam hello.js więc dostaję accesstoken'a do aplikacji stamtąd.
Wysyłam sobie tego access tokena na backend i mogę pobrać dzięki temu profil, co za tym idzie emaila, więc zalogować się da.

Ale gdzie tu clientsecret ? Myślałem, że potrzebuję go by zweryfikować że ten token jest dla mojej aplikacji ale chyba nie jest to konieczne?

Czy więc poprawne będzie po
oMatej
oMatej
  • 0
@trustME jeśli dobrze pamiętam, clientsecret jest potrzebny w przypadku flow authorizationcode. Wtedy klient w przeglądarce nie ma dostępu do access_tokenu, bo google przekierowuje go tylko z kodem, który serwer wymienia na token.

Ty, korzystając z jakiejś biblioteki na frontendzie wykorzystujesz jakiś inny flow.
  • Odpowiedz
Domons
Domons
  • 1
Polećcie jakiś dobry tutorial jak zrobić video stream w przeglądarce z kamerki internetowej, tak aby inni mogli to oglądać.
Niby coś tam znalazłem ale w większości nie jest to chyba tym czego szukam.

Jest też kwestia tego, że wiele użytkowników może robić swój stream i inni mogą je oglądać jak to rozwiązać? Dla każdego streamu potrzebuje osobny serwer w #nodejs ? Czy może wgl nie w #nodejs a coś innego?

#webdev
oMatej
oMatej
  • 0
@Domons tak jak @Dzakus napisał, WebRTC prawdopodobnie będzie najlepszym rozwiązaniem.

Swego czasu robiłem podobny projekt, tzn streaming obrazu z kamerki do aplikacji klienta. Co prawda nie bezpośrednio w przeglądarce, bo korzystałem z Electrona, ale temat dość zbliżony. W moim przypadku aplikacja pozwalała na odbiór obrazu przez WebSockety oraz dgram z Node.js.

Same websockety to chyba dość kiepskie rozwiązanie dla czegoś takiego, ale działało, chociaż trzeba było przesyłać obraz w niskiej rozdzielczości,
  • Odpowiedz

Osiągnięcia