The Plague of the 21st century.

[Meme] xMinusEqualsMinusOneGang
https://redd.it/1p4gvu6

by @programmer_humor

[Meme] isDiscrimination
https://redd.it/1p4viui

by @programmer_humor

Dobrze że jest #git 😂

[Meme] jsLogoIsIntentional
https://redd.it/1p5au9k

by @programmer_humor

„Generatywna #AI to przereklamowana bzdura i jej nie potrzebujemy”. Twórcy gier doceniają AI, ale twierdzą, że musi ona jeszcze udowodnić swoją wartość
https://www.gry-online.pl/newsroom/generatywna-ai-to-przereklamowana-bzdura-i-jej-nie-potrzebujemy-t/za2f8ee
#gry

♨️ https://www.facebook.com/share/p/1JVwiKJcrY/
#perowskity

Bezgraniczne zaufanie do obcych technologii...
Dobrze że nie chińskich jak #premier.

Zimny prysznic dla entuzjastów #AI. Nauka ostrzega: #LLM-y nigdy nie będą „myśleć”, bo język to nie inteligencja | iMagazine
https://imagazine.pl/2025/12/01/zimny-prysznic-dla-entuzjastow-ai-nauka-ostrzega-llm-y-nigdy-nie-beda-myslec-bo-jezyk-to-nie-inteligencja/

LLM-y doskonale radzą sobie z naśladowaniem przeciętnej ludzkiej kreatywności (np. pisaniem korporacyjnych maili), ale nie są w stanie wejść na poziom ekspercki czy nowatorski. Dlaczego? Bo to, co nowatorskie, jest z definicji mało prawdopodobne statystycznie. Jeśli model spróbuje być zbyt „kreatywny”, zaczyna halucynować i generować bełkot. Jeśli trzyma się statystyki – generuje przeciętność.

PS: Ale prędzej czy później powstanie algorytm który będzie naprawdę myśleć. To tylko kwestia czasu i mocy obliczeniowej. Oraz genialnego w swej prostocie pomysłu 😁

"Nie szukajmy tajemnicy tam, gdzie jej nie ma. To, że niektórzy dziennikarze mainstreamowi czy ludzie związani z tą technologią w różny sposób chcą nią zaintrygować, odwołują się do tego pojęcia tajemniczości, czy niezrozumiałości działania tych systemów - no to bądźmy poważni."

Wyjaśnienie działania tzw. "sztucznej inteligencji" na przykładzie modelu językowego, prezentowane przez kompetentnego eksperta, a nie celebrytę/influencera czy popularyzatora. Z eksponowanym w mediach mitem bezkompromisowo rozprawia się dr hab. Jerzy Andrzej Surma, profesor Szkoły Głównej Handlowej w Instytucie Informatyki i Gospodarki Cyfrowej, specjalizujący się w inteligentnych systemach wspomagania decyzji oraz zastosowaniach i bezpieczeństwie sztucznej inteligencji.

link do materiału: https://t.me/PomyslyCiekawostkiFantazje/9029

#AI #llm

♨️https://www.facebook.com/share/p/1BtG3s2kuf/

Każda praca na celowniku AI. Prezes Google uważa, że rola CEO „jedną z łatwiejszych rzeczy” do zastąpienia przez sztuczną inteligencję 😅*
♨️
https://share.google/MgRZxcVl4Eb1BZdBo

Sztuczna inteligencja już teraz wpływa na niektóre zawody. Branża artystyczna przekształca się powoli w sektor zajmujący się korektą prac #AI, ale to nie koniec zmian. Według szefa Google powinniśmy szykować się na rewolucję, ponieważ narzędzia sztucznej inteligencji wpłyną na każdy zawód i ludzie powinni dostosowywać się do nowych realiów i zmian społecznych.

* W przypadku większości prezesów dobrym zastępnikiem była by zwykła funkcja losowa 😁

👨‍🔬 Edgar F. Codd: Architekt Relacyjnych Baz Danych
Edgar Frank Codd (1923–2003) był brytyjskim informatykiem, który pracował w firmie IBM. Jest on powszechnie uznawany za "ojca" relacyjnego modelu danych, który zrewolucjonizował sposób przechowywania i zarządzania informacjami, stanowiąc fundament dla niemal wszystkich nowoczesnych systemów baz danych, w tym najpopularniejszych obecnie systemów RDBMS (Relational Database Management System).
Jego przełomowa praca „A Relational Model of Data for Large Shared Data Banks” została opublikowana w 1970 roku. Do tego czasu dominowały mniej elastyczne i trudniejsze w zarządzaniu modele hierarchiczne i sieciowe.
📜 12 Postulatów Codda: Definicja Relacyjności
Kluczowym wkładem Codda, który stanowił punkt odniesienia dla wszystkich twórców baz danych, jest zestaw zasad, pierwotnie sformułowany w 1985 roku jako 12 Postulatów (Zasad) Codda. Miały one za zadanie precyzyjnie zdefiniować, co sprawia, że system zarządzania bazą danych jest naprawdę relacyjny, a nie tylko udaje taki.
W praktyce Codd sformułował 13 reguł, numerowanych od 0 do 12, aby podkreślić fundamentalną wagę reguły zerowej. Choć żaden komercyjny RDBMS nie spełnia ich wszystkich w pełni, stanowią one teoretyczny wzór dla projektowania baz danych.
Oto najważniejsze zasady:
1. Reguła 0: Reguła Fundamentu (Foundation Rule)
System musi zarządzać bazami danych wyłącznie za pomocą swoich relacyjnych zdolności. Oznacza to, że nie można polegać na niskopoziomowych, nierealacyjnych funkcjach do obejścia systemu.
2. Reguła 1: Reguła Informacji (The Information Rule)
Cała informacja w bazie danych musi być reprezentowana w jednym i tylko jednym sposobie: jako wartości atrybutów w tabelach (relacjach).
3. Reguła 2: Reguła Zagwarantowanego Dostępu (The Guaranteed Access Rule)
Każda wartość w bazie danych musi być teoretycznie dostępna przez podanie nazwy tabeli, wartości klucza głównego (identyfikującego wiersz/krotkę) i nazwy kolumny (atrybutu). Eliminuje to potrzebę polegania na fizycznej lokalizacji danych.
4. Reguła 3: Systematyczne Traktowanie Wartości NULL (Systematic Treatment of Null Values)
System musi obsługiwać specjalną wartość NULL w sposób spójny i systematyczny, aby reprezentować brakujące, nieznane lub nieadekwatne informacje, w sposób odmienny od wszystkich innych wartości.
5. Reguła 5: Reguła Kompleksowego Języka Danych (The Comprehensive Data Sublanguage Rule)
System musi dostarczać przynajmniej jeden język, który:
* Ma wyraźną składnię i może być używany zarówno interaktywnie, jak i w programach aplikacyjnych.
* Obsługuje definiowanie danych, manipulowanie nimi, bezpieczeństwo, integralność i zarządzanie transakcjami.
Tym językiem stał się powszechnie używany SQL (Structured Query Language), który powstał w IBM w oparciu o idee Codda i służy jako standardowy interfejs do RDBMS.
🌐 Wpływ i Dziedzictwo
Praca Codda była ogromnym krokiem naprzód, odsuwając bazy danych od skomplikowanych, powiązanych struktur na rzecz prostszej, matematycznie spójnej teorii zbiorów. Relacyjny model danych umożliwił:
* Niezależność Danych: Zmiany w fizycznej organizacji danych nie wpływają na programy aplikacyjne (Reguła 8).
* Integralność Danych: Utrzymywanie spójności dzięki kluczom głównym (Primary Key) i kluczom obcym (Foreign Key).
* Łatwiejsze Kwerendy: Stosowanie języka deklaratywnego (SQL), w którym użytkownik mówi co chce, a nie jak to uzyskać.
W 1981 roku Edgar F. Codd otrzymał Nagrodę Turinga, najwyższe wyróżnienie w informatyce, za fundamentalny wkład w teorię i praktykę systemów zarządzania bazami danych.

# 🔗 Jak działa JOIN w SQL? Proste wyjaśnienie dla każdego!

Jeśli kiedykolwiek pracowałeś z bazami danych, prawdopodobnie trafiłeś na tajemnicze słówko JOIN. Dla początkujących brzmi ono trochę jak zaklęcie, a dla ekspertów — jest jednym z najważniejszych narzędzi do pracy z danymi. JOIN-y pozwalają łączyć informacje z wielu tabel, tak jakbyś składał puzzle w jeden obrazek. 🧩

W tym artykule wytłumaczę Ci, co to jest JOIN i jakie są jego rodzaje — prosto, jasno i bez matematycznego bólu głowy. 😉

---

## 🏗 Dlaczego potrzebujemy JOIN?

Wyobraź sobie, że masz dwie listy:

* listę pracowników
* listę działów w firmie

Dane te są rozdzielone nie bez powodu — to poprawia porządek i oszczędza miejsce. Tylko że… czasem potrzebujesz informacji z obu naraz. Na przykład:
„W jakim dziale pracuje Anna?”

To właśnie moment, w którym SQL mówi:
➡️ *Spoko, zrobię JOIN i połączę za Ciebie te dane.*

---

# 🔍 Rodzaje JOIN i ich działanie

## ⭐️ 1. INNER JOIN — znajdź to, co pasuje 🎯

INNER JOIN pobiera tylko te rekordy, które mają dopasowanie w obu tabelach.

To trochę jak notes z kontaktami: jeśli masz numer telefonu i nazwisko — super. Jeśli brakuje jednego lub drugiego, tracisz dopasowanie.

### Przykład:

Łączymy pracowników z ich działami:

SELECT e.name, d.dept_name
FROM employees e
INNER JOIN departments d
    ON e.department_id = d.id;

Wynik?
Tylko pracownicy, którzy faktycznie są przypisani do jakiegoś działu.

---

## ⭐️ 2. LEFT JOIN — pokaż wszystko z lewej tabeli 🟩➡️

LEFT JOIN zwraca wszystkie rekordy z tabeli po lewej stronie, nawet jeśli nie znajdzie dopasowania w prawej.

To tak, jakbyś powiedział:
➡️ „Pokaż mi wszystkich pracowników, a przy okazji — jeśli wiadomo — ich dział.”

Jeśli działu brak, pojawi się NULL.

SELECT e.name, d.dept_name
FROM employees e
LEFT JOIN departments d
    ON e.department_id = d.id;

Super przydatne, gdy chcesz znaleźć „brakujące dane”.

---

## ⭐️ 3. RIGHT JOIN — przeciwieństwo LEFT JOIN 🟥⬅️

RIGHT JOIN działa jak LEFT JOIN, tylko w drugą stronę.

Czyli:
➡️ „Pokaż mi wszystkie działy, nawet jeśli nie mają pracowników.”

Wiele popularnych baz danych (np. SQLite) go nie obsługuje, ale warto wiedzieć, że istnieje.

---

## ⭐️ 4. FULL OUTER JOIN — pokaż wszystko ze wszystkimi 🌐

Najbardziej „otwarty” JOIN.

FULL JOIN łączy wszystko z obu tabel, niezależnie od tego, czy pasuje, czy nie.

Efekt?

* pasujące dane są połączone
* brak dopasowania → pojawia się NULL po którejś stronie

To taka pełna panorama danych. 📸
(Uwaga: SQLite go nie obsługuje.)

---

## ⭐️ 5. CROSS JOIN — każdy z każdym 🔥

To JOIN dla odważnych.

CROSS JOIN tworzy kombinację wszystkich rekordów z obu tabel.
Jeśli masz 5 pracowników i 5 działów, CROSS JOIN zrobi z tego… 25 wyników. 😅

Przykład:

SELECT e.name, d.dept_name
FROM employees e
CROSS JOIN departments d;

Świetne do generowania kombinacji, ale używaj ostrożnie!

---

## ⭐️ 6. SELF JOIN — tabela łączona sama ze sobą 🪞

Brzmi dziwnie? A jednak.

SELF JOIN to sposób na porównanie rekordów między sobą, np.:

* pracownik → jego manager
* produkt → jego podobny produkt
* wierzchołki grafu → połączenia między nimi

Przykład:

SELECT e.name AS employee, m.name AS manager
FROM employees e
LEFT JOIN employees m
    ON e.manager_id = m.id;

Jak lustro odbijające dane. 🪞

---

# 📌 Podsumowanie — który JOIN wybrać?

| JOIN | Co zwraca? |
| -------------- | ---------------------------------------- |
| INNER JOIN | tylko dopasowane rekordy |
| LEFT JOIN | wszystkie z lewej + dopasowania z prawej |
| RIGHT JOIN | wszystkie z prawej + dopasowania z lewej |
| FULL JOIN | wszystko ze wszystkimi |
| CROSS JOIN | kombinacje każdy z każdym |
| SELF JOIN | tabela łączona sama ze sobą |

JOIN to jedno z najpotężniejszych narzędzi SQL — i fundament pracy z danymi.
Gdy go zrozumiesz, świat relacyjnych baz danych staje się znacznie prostszy i bardziej logiczny. 🧠💡

[Meme] whatIsMutexLock
https://redd.it/1p6hbkh

by @programmer_humor

[Meme] usersWillBeUsers
https://redd.it/1p8p7bc

by @programmer_humor