@vrkr tzw. archiwizacja w niszczarce

@damw tak widzę kod pisany przez ludzi, którzy uważają, że programiści i szkolenie juniorów nie jest już potrzebne.

Co do używania systemu GPS to raczej marne szanse. Kilku futurystów obliczyło że w okolicach 2050 rozwój technologiczny będzie tak szybki i zaawansowany że ludzie nie będą nadążać umysłami za tym i będzie potrzebna sztuczna inteligencja zeby nam to tłumaczyć xD

@damw "dlaczego programiści nie stracą roboty jeszcze przez jakiś czas na jednym obrazku"

niestety username musi byc publicznie znanym adresem mailowym zeby mozna bylo potem wymusic 2FA za pomoca platnych SMSow i kroic frajerow przy kazdym zalogowaniu

Awruk123!

Ja tam lubie i nie mam problemu pre-commit ogarnia

@damw - wystarczy linter i formatter kodu - i problem znika

Poza tym sam Python dokładnie pokazuje w której lini jest złe wcięcie

@damw w devopsie i je⁎⁎⁎ym jamlu jest identycznie ( ͠° ͟ʖ ͡°)

@WujekAlien kalendarz lepszy

@vrkr - za duck.ai:

Oto lista "głupich" rzeczy związanych z operatorami porównywania w JavaScript:

1. **Używanie `==` zamiast `===`**: Operator `==` wykonuje konwersję typów, co może prowadzić do nieoczekiwanych wyników. Zawsze lepiej używać `===`, aby porównywać zarówno wartość, jak i typ.

2. **Porównywanie różnych typów bez zrozumienia**: Porównywanie wartości różnych typów (np. liczby i stringi) może prowadzić do zaskakujących wyników, np. `0 == '0'` zwraca `true`, ale `0 === '0'` zwraca `false`.

3. **Używanie `!=` zamiast `!==`**: Podobnie jak w przypadku `==`, operator `!=` wykonuje konwersję typów, co może prowadzić do błędów. Zawsze lepiej używać `!==`.

4. **Porównywanie obiektów**: Porównywanie obiektów za pomocą operatorów porównania (np. `obj1 == obj2`) porównuje referencje, a nie zawartość obiektów, co może prowadzić do nieporozumień.

5. **Używanie `Object.is()` bez zrozumienia**: `Object.is()` ma swoje specyficzne zasady porównywania (np. `NaN` jest równe `NaN`, a `-0` nie jest równe `+0`), co może być mylące.

6. **Porównywanie wartości `null` i `undefined`**: Używanie `==` do porównania `null` i `undefined` zwraca `true`, co może prowadzić do niejasności, gdy nie jest to zamierzone.

7. **Zbyt skomplikowane wyrażenia porównawcze**: Tworzenie złożonych wyrażeń porównawczych, które są trudne do zrozumienia, może prowadzić do błędów i utrudniać czytelność kodu.

8. **Ignorowanie kontekstu logicznego**: Używanie operatorów porównania w kontekście logicznym (np. w instrukcjach warunkowych) bez zrozumienia, jak działają, może prowadzić do błędnych założeń.

9. **Porównywanie z `NaN`**: `NaN` nie jest równe żadnej wartości, w tym samemu sobie, co może prowadzić do nieoczekiwanych wyników w porównaniach.

10. **Używanie operatorów porównania w pętlach bez zrozumienia**: Używanie operatorów porównania w pętlach (np. `for`) bez zrozumienia ich działania może prowadzić do nieskończonych pętli lub błędów logicznych.

Unikanie tych pułapek może pomóc w pisaniu bardziej niezawodnego i przewidywalnego kodu w JavaScript.

@vrkr Tak na oko to obstawiłbym C. Myślę, że A zwraca true, B jest ciekawszym przypadkiem bo bez podania argumentów Math.min() będzie infinity, a Math.max() będzie -infinity także również będzie to true. NaN nie jest równy innemu obiektowi NaN i dalej nie muszę myśleć.

Metodą wykreślania poprawnych odpowiedzi:

A - w JS prawie wszystko jest obiektem więc to zwróci true

B - funkcja do zwracania najmniejszej wartości z podanych zwróci domyślnie największą możliwą liczbę a ta przeciwna odwrotnie więc też true

D - koncepcja truthy/falsy w JS gdzie przy takim porównywaniu wartości są "konwertowane" na true albo false, zero jest false a pusty string jest falsy więc zwróci true

No i pozostaje to C, gdym rozwiązywał jakiś test i nie miał dostępu od internetu to bym zaznaczył tę odpowiedź. A teraz podczas pisania tego zdania sprawdziłem na internecie dlaczego NaN != NaN i jak się nad tym pomyśli to ma to sens (jak wszystko w JS gdy zna się odpowiednio ten język, ale wtedy wszelkie te memy przestają bawić).

Dla ciekawskich tutaj są odpowiedzi:

https://www.reddit.com/r/ProgrammerHumor/comments/sh1ji1/stop_pretending_nan_nan_was_a_good_idea_it_wasnt/

https://stackoverflow.com/questions/10034149/why-is-nan-not-equal-to-nan

Bez foreign keys

@vrkr Bool nie ma warunku definicji rozmiaru, ponieważ rozmiary typów całkowitych też nie mają gwarancji być zawsze takie same. Ma tylko następujące wytyczne:

• wartości boolean są tego samego rozmiaru przy porównywaniu
  

• jest prawdą jeśli wartość jest niezerowa
  

Taka minimalna logika pozwala różnym językom implementować to jak chcą, dając użytkownikowi tryb "tak bardzo wyjebane" ja tylko używam true i false i am w d⁎⁎ie jak kompilator robi.

Sorry, ale tzw padding istnieje nie bez powodu, baba jak zwykle robi problem z niczego.

Ale struktura 8 booli nie musi zajmować 8 bajtów.

Ludzie mają windowsa tylko dlatego że trzeba uruchomic grę.

Change my mind