Forwarded from Experimental chill
Testing on the Toilet
До года так 2005 в Google не было принято писать тесты. Компания переживала бурный рост, а хоть туда уже приходили лучшие инженеры, на тесты как-то время не хватало. Некоторые из разработчиков были недовольны таким положением вещей, и родилась какая-то абсолютно гениальная идея, с которой все единогласно согласились, и надо было лишь правильно ее исполнить.
Testing on the Toilet (TotT) -- одностраничные листовки, расклеенные в туалетных кабинках офисов Google и дающие разработчикам советы о том, как лучше тестировать их код, -- это наш, можно сказать, институт, на котором держится Google. Они упоминались в Washington Post, New York Times и единогласно были высмеяны и признаны воплощением культуры Гугла.
Как и почти все вещи в Google, TotT возник в результате попытки решить одну конкретную проблему. Код стало невозможно писать из-за слишком большого количества багов. В середине 2005 года была создана группа Unittest, чтобы обучать разработчиков, как тестировать свой код. В то время написание тестов не было прям уж нормой в Google. Члены группы начали писать Codelabs (лабораторные пошаговые работы), организовывать Fixit weeks (когда все в команде чинят flaky тесты) и проводить еженедельные лекции для Noogler (New Googler) о том, как важно писать тесты.
Как я бы сказал по-английски: "This trained the Nooglers". А что делать с теми, кого уже наняли? Во время митинга в конце марта 2006 г. один из директоров предложил идею о расклеивании листовок в публичных местах. А куда все ходят точно хотя бы раз в день? Столовые и туалеты. Кафе не были хорошим решением, так как фокус всегда был смещен на еду и общение. Остаются уборные. Что ж. Кто-то посмеялся, но никто не задал вопроса, а нужно ли это делать. В итоге это вошло в OKR, и листовки стали появляться во всех туалетах офисов Google.
Один из инженеров написал первый эпизод: "Better stubbing in Python". Его наклеили везде в офисах Долины и Лондона. Кто-то подхватил и рассказал об этом всем сокомандникам, пошло сарафанное радио. Это было необычно, и все согласились, что это может решить их проблему. TotT распространялся с немыслимой быстротой.
Ana Ulin стала лидером этой программы, когда она добровольна взяла ответственность за вычитку и качество материала. Так идея была подхвачена, на неё нашлись правильные и нужные люди. Это ещё одна часть культуры Google -- если ты что-то делаешь и делаешь это хорошо, ты теперь за это ответственен. Те, кто обожал тестирование, писали свои методы как писать правильные тесты на С++, как работать с Unicode. Абсолютно все офисы стали подхватывать это, и даже в планировки новой постройки стали рисовать места, где будут наклеивать эти листовки.
Со временем многие авторы начали писать свой контент (в том числе появились разделения на Tips of the Week, которые появлялись в блогах), и люди прислушивались к советам. Начались обсуждения, бесконечные дебаты, появились арбитры, но самое главное -- были сообщения о положительных результатах, что теперь кто-то научился правильно писать на Python или смог обойти баг с памятью в C++. Рекламировались и внедрялись новые инструменты и методы. Качество, скейл рос. Люди стали цитировать в код ревью эпизоды, люди доверяли этому источнику. Пусть решения не были идеальными, но все смогли о чём-то договориться.
TotT явно оказал сильное положительное влияние на инженерные практики. Ничего так не сработало как этот изначальный толчок -- необычно, мило, воодушевляюще, а главное, очень полезно.
Несмотря на все изменения, уже сколько раз поменявшихся лидеров программы, TotT уже 17 лет выпускает эпизоды. Появились отдельный культы и программы, которые пишутся для всех технологий. К сожалению, всё не повесишь в туалетах, а некоторые стали невозможными для публичных глаз :)
Google совершенно случайно нашёл решение, как продвигать практики, писать лучше код. Кто бы мог подумать, что можно сказать, что какая-то часть культуры Google стала богаче и сильнее из-за каких-то там туалетов.
Больше и первые эпизоды здесь:
https://mike-bland.com/2011/10/25/testing-on-the-toilet.html
До года так 2005 в Google не было принято писать тесты. Компания переживала бурный рост, а хоть туда уже приходили лучшие инженеры, на тесты как-то время не хватало. Некоторые из разработчиков были недовольны таким положением вещей, и родилась какая-то абсолютно гениальная идея, с которой все единогласно согласились, и надо было лишь правильно ее исполнить.
Testing on the Toilet (TotT) -- одностраничные листовки, расклеенные в туалетных кабинках офисов Google и дающие разработчикам советы о том, как лучше тестировать их код, -- это наш, можно сказать, институт, на котором держится Google. Они упоминались в Washington Post, New York Times и единогласно были высмеяны и признаны воплощением культуры Гугла.
Как и почти все вещи в Google, TotT возник в результате попытки решить одну конкретную проблему. Код стало невозможно писать из-за слишком большого количества багов. В середине 2005 года была создана группа Unittest, чтобы обучать разработчиков, как тестировать свой код. В то время написание тестов не было прям уж нормой в Google. Члены группы начали писать Codelabs (лабораторные пошаговые работы), организовывать Fixit weeks (когда все в команде чинят flaky тесты) и проводить еженедельные лекции для Noogler (New Googler) о том, как важно писать тесты.
Как я бы сказал по-английски: "This trained the Nooglers". А что делать с теми, кого уже наняли? Во время митинга в конце марта 2006 г. один из директоров предложил идею о расклеивании листовок в публичных местах. А куда все ходят точно хотя бы раз в день? Столовые и туалеты. Кафе не были хорошим решением, так как фокус всегда был смещен на еду и общение. Остаются уборные. Что ж. Кто-то посмеялся, но никто не задал вопроса, а нужно ли это делать. В итоге это вошло в OKR, и листовки стали появляться во всех туалетах офисов Google.
Один из инженеров написал первый эпизод: "Better stubbing in Python". Его наклеили везде в офисах Долины и Лондона. Кто-то подхватил и рассказал об этом всем сокомандникам, пошло сарафанное радио. Это было необычно, и все согласились, что это может решить их проблему. TotT распространялся с немыслимой быстротой.
Ana Ulin стала лидером этой программы, когда она добровольна взяла ответственность за вычитку и качество материала. Так идея была подхвачена, на неё нашлись правильные и нужные люди. Это ещё одна часть культуры Google -- если ты что-то делаешь и делаешь это хорошо, ты теперь за это ответственен. Те, кто обожал тестирование, писали свои методы как писать правильные тесты на С++, как работать с Unicode. Абсолютно все офисы стали подхватывать это, и даже в планировки новой постройки стали рисовать места, где будут наклеивать эти листовки.
Со временем многие авторы начали писать свой контент (в том числе появились разделения на Tips of the Week, которые появлялись в блогах), и люди прислушивались к советам. Начались обсуждения, бесконечные дебаты, появились арбитры, но самое главное -- были сообщения о положительных результатах, что теперь кто-то научился правильно писать на Python или смог обойти баг с памятью в C++. Рекламировались и внедрялись новые инструменты и методы. Качество, скейл рос. Люди стали цитировать в код ревью эпизоды, люди доверяли этому источнику. Пусть решения не были идеальными, но все смогли о чём-то договориться.
TotT явно оказал сильное положительное влияние на инженерные практики. Ничего так не сработало как этот изначальный толчок -- необычно, мило, воодушевляюще, а главное, очень полезно.
Несмотря на все изменения, уже сколько раз поменявшихся лидеров программы, TotT уже 17 лет выпускает эпизоды. Появились отдельный культы и программы, которые пишутся для всех технологий. К сожалению, всё не повесишь в туалетах, а некоторые стали невозможными для публичных глаз :)
Google совершенно случайно нашёл решение, как продвигать практики, писать лучше код. Кто бы мог подумать, что можно сказать, что какая-то часть культуры Google стала богаче и сильнее из-за каких-то там туалетов.
Больше и первые эпизоды здесь:
https://mike-bland.com/2011/10/25/testing-on-the-toilet.html
Mike Bland
Testing on the Toilet - Mike Bland
The Testing Grouplet's weekly publication for spreading testing news and views throughout Google, in the most opportune of places
Паттерны хранения деревьев в БД
https://habr.com/ru/company/bimeister/blog/672634/
• Adjacency List;
• Nested Sets;
• Closure Table;
• Materialized Path.
https://habr.com/ru/company/bimeister/blog/672634/
• Adjacency List;
• Nested Sets;
• Closure Table;
• Materialized Path.
Хабр
Обзор паттернов хранения деревьев в реляционных БД
Всем привет! Меня зовут Пантелеев Александр и я бэкенд-разработчик в компании Bimeister. Постараюсь описать исчерпывающе, кратко и понятно суть основных паттернов хранения деревьев в реляционных базах...
Итоги отпуска
Отдыхается отлично
Решил в этом году в отпуске не проходить никаких курсов и не читать книг... просто перебрать вкладки, каналы, подписки
Из 230каналов в телеге по разработке осталось 130 за которыми продолжаю следить. Часть перестала существовать, другие стали очень банальными, в третьих рекламы оказалось больше чем даже проходного контента
Все статьи и видео с постов которые остались непрочитанными с февраля отсортировал и разложил в pocket для дальнейшего изучения или повторения уже известного. Часть из того что прочитал уже запостил сюда
Попрежнему пейперы про глубокие оптимизации доставляют много попогорения по теме "тут люди делом заняты, а я чем то не тем я занимаюсь" но читать продолжаю, бо очень интересно. Продлил подписку https://getpocket.com/@cQOp9TT9Ad02dd158eg63d8gbsd1A5037fYt73h3a8ZfY9j41720VFn2y06DP2eW?s=invite еще на год.
Какнибудь потом соберу все каналы списком и опубликую тут. Ведь 230было только в ТГ, а ведь еще ютюб есть там 600+ каналов в подписках, и часто смотрю многие из них, еще есть рсс и почта))))
Отдыхается отлично
Решил в этом году в отпуске не проходить никаких курсов и не читать книг... просто перебрать вкладки, каналы, подписки
Из 230каналов в телеге по разработке осталось 130 за которыми продолжаю следить. Часть перестала существовать, другие стали очень банальными, в третьих рекламы оказалось больше чем даже проходного контента
Все статьи и видео с постов которые остались непрочитанными с февраля отсортировал и разложил в pocket для дальнейшего изучения или повторения уже известного. Часть из того что прочитал уже запостил сюда
Попрежнему пейперы про глубокие оптимизации доставляют много попогорения по теме "тут люди делом заняты, а я чем то не тем я занимаюсь" но читать продолжаю, бо очень интересно. Продлил подписку https://getpocket.com/@cQOp9TT9Ad02dd158eg63d8gbsd1A5037fYt73h3a8ZfY9j41720VFn2y06DP2eW?s=invite еще на год.
Какнибудь потом соберу все каналы списком и опубликую тут. Ведь 230было только в ТГ, а ведь еще ютюб есть там 600+ каналов в подписках, и часто смотрю многие из них, еще есть рсс и почта))))
Getpocket
Aliaksandr Master on Pocket
See what Aliaksandr Master is reading and watching on Pocket.
Forwarded from /usr/bin
Пособие по программированию модулей ядра Linux. Ч.3
Это продолжение предыдущего поста (ч.2) и предпредыдущего (ч.1).
В текущей части мы разберем работу с файловой системой /proc, взаимодействие с модулями при помощи sysfs, а также работу с файлами устройств. Читать дальше.
Это продолжение предыдущего поста (ч.2) и предпредыдущего (ч.1).
В текущей части мы разберем работу с файловой системой /proc, взаимодействие с модулями при помощи sysfs, а также работу с файлами устройств. Читать дальше.
== Notifiers python package
Providers:
Pushover, SimplePush, Slack, Gmail, Email (SMTP), Telegram, Gitter, Pushbullet, Join, Zulip, Twilio, Pagerduty, Mailgun, PopcornNotify, StatusPage.io, iCloud, VictorOps (Splunk)
https://github.com/liiight/notifiers
Providers:
Pushover, SimplePush, Slack, Gmail, Email (SMTP), Telegram, Gitter, Pushbullet, Join, Zulip, Twilio, Pagerduty, Mailgun, PopcornNotify, StatusPage.io, iCloud, VictorOps (Splunk)
https://github.com/liiight/notifiers
Forwarded from Типичный программист
Media is too big
VIEW IN TELEGRAM
Кажется, с появлением Unreal Engine 5 появился новый тренд — создавать на движке всё подряд. Кто-то воссоздаёт гиперреалистичные сцены из реального мира. Кто-то фантазирует, как будут выглядеть персонажи из ожидаемых игр. А кто-то — решил показать, как бы могла выглядеть игра Super Mario, будь у её создателей в то время такие технологии.
Как вам? Сыграли бы?
#gamedev
Как вам? Сыграли бы?
#gamedev
Forwarded from LEFT JOIN
🌀 Критика критики SQL (Запутались? Сейчас будем разбираться!) 📚
Язык SQL впервые появился в 1974 году как часть базы данных IBM System R. Прошло почти 50 лет, и SQL де-факто является языком для работы с большинством баз данных (реляционных, конечно же).
Карлин Энг работал инженером и аналитиков данных 12 лет и у него накопилось много вопросов к SQL. В статье он, как настоящий аналитик, структурированно изложил, что именно его не устраивает. Конечно, он был не первым критиком SQL, а лишь прокомментировал идеи, описанные в книге 1984 года выпуска «Критика языка баз данных SQL» математика Си Джей Дейта. Дейт был бывшим сотрудником IBM, известным исследователем баз данных и другом Э. Ф. Кодда. Однако, те замечания, которые были описаны в его книге, частично устарели и ниже будет краткая выжимка из рассуждения Карлина (которое я рекомендую прочесть в оригинале).
🤔 Что не так с SQL по версии Си Джей Дейта?
Для начала разберемся с тем, что такое ортогональность. Суть ортогональности по мнению автора в следующем: конструкции языка подобны блокам Lego — небольшое количество базовых частей можно рекомбинировать простыми и интуитивно понятными способами. Отсутствие ортогональности означает, что в языке есть много исключений в том, как компоненты могут быть объединены, что делает его сложным для изучения.
1. Отсутствие ортогональности выражений
Раньше использование FROM в SELECT было ограничено указанием только имен таблиц или представлений, а не подзапросов или общих табличных выражений (CTE). Однако, современный SQL предоставляет возможность ссылаться на CTE или подзапрос в операторе FROM.
2. Отсутствие ортогональности функций
Автор приводит множество конкретных примеров этого критического замечания, которые возникают при разном написании запроса. Один из них – оператор HAVING, которое мы разбирали в предыдущем посте. Спойлер: использование HAVING и GROUP BY теперь гораздо проще и шире, чем, например, в SQL 1983 года.
3. Отсутствие ортогональности в целом
Это замечание касается ряда небольших проблем, например, ограничение для «длинных» полей (строки больше 254 символов): на «длинное» поле нельзя было сослаться в предложении WHERE или GROUP BY. Конечно, современные системы баз данных больше не имеют этих ограничений.
4. Ключи
SQL образца 1983 года мог легко игнорировать первичные ключи, а внешних ключей даже не существовало. Хотя SQL образца 2022 допускает внешние ключи, и многие базы данных обеспечивают ссылочную целостность, последняя версия языка по-прежнему не полностью понимает семантику первичных и внешних ключей.
5. Домены или типы данных
В первоначальном SQL были только примитивные типы (int, char, float и т. д.). Сегодня Postgres обеспечивает поддержку пользовательских типов произвольной сложности, однако, большинство хранилищ данных OLAP не поддерживают определяемые пользователем типы, и SQL тут бессилен.
6. Назначение отношений
Критика здесь заключалась в следующем: Ограниченная форма присваивания отношения поддерживается через INSERT ... SELECT, но эта операция не перезаписывает предыдущее содержимое таблицы, а источником присваивания не может быть произвольное алгебраическое выражение (или эквивалент SELECT). Это уже не так. Назначение отношения может быть выполнено с помощью CREATE OR REPLACE TABLE AS. Для подзапросов и CTE источником может быть любое произвольное алгебраическое выражение.
7. Явные операторы JOIN, INTERSECT и DIFFERENCE
SQL 1983 года их не поддерживал, но в современном SQL это уже давно исправлено.
💭 Выводы
Хотя многие критические замечания в отношении SQL были исправлены обновлениями стандарта ANSI, некоторые из них все еще присутствуют, например, отсутствие ортогональности. Несмотря на несовершенство SQL, его доминирование на рынке означает, что каждый начинающий аналитик и программист должен его изучить. Однако, мне кажется, что при всех известных недостатках и попытках регулярно улучшить язык, SQL остается очень удобным и интутитивно понятным языком для работы с данными.
А вы что думаете — удобнее писать SELECT к табличке 💯или обработать массив с помощью pandas 🤡?
Язык SQL впервые появился в 1974 году как часть базы данных IBM System R. Прошло почти 50 лет, и SQL де-факто является языком для работы с большинством баз данных (реляционных, конечно же).
Карлин Энг работал инженером и аналитиков данных 12 лет и у него накопилось много вопросов к SQL. В статье он, как настоящий аналитик, структурированно изложил, что именно его не устраивает. Конечно, он был не первым критиком SQL, а лишь прокомментировал идеи, описанные в книге 1984 года выпуска «Критика языка баз данных SQL» математика Си Джей Дейта. Дейт был бывшим сотрудником IBM, известным исследователем баз данных и другом Э. Ф. Кодда. Однако, те замечания, которые были описаны в его книге, частично устарели и ниже будет краткая выжимка из рассуждения Карлина (которое я рекомендую прочесть в оригинале).
🤔 Что не так с SQL по версии Си Джей Дейта?
Для начала разберемся с тем, что такое ортогональность. Суть ортогональности по мнению автора в следующем: конструкции языка подобны блокам Lego — небольшое количество базовых частей можно рекомбинировать простыми и интуитивно понятными способами. Отсутствие ортогональности означает, что в языке есть много исключений в том, как компоненты могут быть объединены, что делает его сложным для изучения.
1. Отсутствие ортогональности выражений
Раньше использование FROM в SELECT было ограничено указанием только имен таблиц или представлений, а не подзапросов или общих табличных выражений (CTE). Однако, современный SQL предоставляет возможность ссылаться на CTE или подзапрос в операторе FROM.
2. Отсутствие ортогональности функций
Автор приводит множество конкретных примеров этого критического замечания, которые возникают при разном написании запроса. Один из них – оператор HAVING, которое мы разбирали в предыдущем посте. Спойлер: использование HAVING и GROUP BY теперь гораздо проще и шире, чем, например, в SQL 1983 года.
3. Отсутствие ортогональности в целом
Это замечание касается ряда небольших проблем, например, ограничение для «длинных» полей (строки больше 254 символов): на «длинное» поле нельзя было сослаться в предложении WHERE или GROUP BY. Конечно, современные системы баз данных больше не имеют этих ограничений.
4. Ключи
SQL образца 1983 года мог легко игнорировать первичные ключи, а внешних ключей даже не существовало. Хотя SQL образца 2022 допускает внешние ключи, и многие базы данных обеспечивают ссылочную целостность, последняя версия языка по-прежнему не полностью понимает семантику первичных и внешних ключей.
5. Домены или типы данных
В первоначальном SQL были только примитивные типы (int, char, float и т. д.). Сегодня Postgres обеспечивает поддержку пользовательских типов произвольной сложности, однако, большинство хранилищ данных OLAP не поддерживают определяемые пользователем типы, и SQL тут бессилен.
6. Назначение отношений
Критика здесь заключалась в следующем: Ограниченная форма присваивания отношения поддерживается через INSERT ... SELECT, но эта операция не перезаписывает предыдущее содержимое таблицы, а источником присваивания не может быть произвольное алгебраическое выражение (или эквивалент SELECT). Это уже не так. Назначение отношения может быть выполнено с помощью CREATE OR REPLACE TABLE AS. Для подзапросов и CTE источником может быть любое произвольное алгебраическое выражение.
7. Явные операторы JOIN, INTERSECT и DIFFERENCE
SQL 1983 года их не поддерживал, но в современном SQL это уже давно исправлено.
💭 Выводы
Хотя многие критические замечания в отношении SQL были исправлены обновлениями стандарта ANSI, некоторые из них все еще присутствуют, например, отсутствие ортогональности. Несмотря на несовершенство SQL, его доминирование на рынке означает, что каждый начинающий аналитик и программист должен его изучить. Однако, мне кажется, что при всех известных недостатках и попытках регулярно улучшить язык, SQL остается очень удобным и интутитивно понятным языком для работы с данными.
А вы что думаете — удобнее писать SELECT к табличке 💯или обработать массив с помощью pandas 🤡?
Carlineng
Carlin Eng
Homepage of Carlin Eng
== Loki - access logs the smart way
https://anaisurl.com/loki-access-logs-the-smart-way/
https://anaisurl.com/loki-access-logs-the-smart-way/
Anais Urlichs
Loki - Access logs the smart way
In this tutorial, we will learn how to access logs in Grafana through Grafana Loki. This includes installing your observability tools incl. Prometheus, Grafana, Loki and Promtail inside your Kubernetes cluster. Video included
Qibec (pronounce "Quebec") is a simple educational CPU - not a complete computer - made from discrete transistors.
This CPU (Central Processing Unit) only has 1 single native instruction, which operates on 1 data-bit.
https://mircad.com/q/index.html
This CPU (Central Processing Unit) only has 1 single native instruction, which operates on 1 data-bit.
https://mircad.com/q/index.html
Forwarded from JavaScript.Ninja News (Illya Klymov 🇺🇦)
YouTube
Ілля Климов про Vue 3, GitLab, GraphQL, npm та Node.js.
Зустрічайте 6-ий випуск подкасту "Right Tool For The Job". Гість цього випуску Ілля Климов — Senior Frontend Developer at GitLab Inc та лідер проєкту JavaScript.Ninja.
Наш ведучий Олександр Соловйов разом з Іллею поспілкувалися про Vue 3, GraphQL, npm та…
Наш ведучий Олександр Соловйов разом з Іллею поспілкувалися про Vue 3, GraphQL, npm та…
Название кликбейтное но чтото для себя даже нашел
== 8 первоклассных инструкций SQL на каждый день
https://telegra.ph/8-pervoklassnyh-instrukcij-SQL-na-kazhdyj-den-07-14
- OVER и OVER (PARTITION BY)
- Общие табличные выражения (ОТВ)
- Условные выражения
- Count (1) вместо count (*)
- Мониторинг использования индекса
- Показ N-числа наиболее затратных запросов
- Показ индексов схемы базы данных
- Поиск повторяющихся строк по имени столбца
== SQL-запросов, о которых должен знать каждый дата-инженер
https://telegra.ph/6-SQL-zaprosov-o-kotoryh-dolzhen-znat-kazhdyj-data-inzhener-07-04
- Нарастающий итог
- Обобщенные табличные выражения
- Упорядочение данных
- Добавление подытогов
- Временные функции
- Дисперсия и среднеквадратическое отклонение
== ТОП-20 хитрых вопросов по SQL для собеседования
https://proglib.io/p/sql-questions
- Как найти дубликат записи?
- Как, используя
- Напишите SQL-запрос, с применением
- Чем отличается
- Что такое план запросов? Когда бы вы его использовали? Как посмотреть план?
- Как из таблицы выбрать все записи c четными ID? А с нечетными?
- Важен ли в составном индексе порядок столбцов?
- В чем разница между однорядными и многорядными функциями? Для чего используется
- В чем разница между условиями
- Как получить последний
- Чем отличается
== 8 первоклассных инструкций SQL на каждый день
https://telegra.ph/8-pervoklassnyh-instrukcij-SQL-na-kazhdyj-den-07-14
- OVER и OVER (PARTITION BY)
- Общие табличные выражения (ОТВ)
- Условные выражения
- Count (1) вместо count (*)
- Мониторинг использования индекса
- Показ N-числа наиболее затратных запросов
- Показ индексов схемы базы данных
- Поиск повторяющихся строк по имени столбца
== SQL-запросов, о которых должен знать каждый дата-инженер
https://telegra.ph/6-SQL-zaprosov-o-kotoryh-dolzhen-znat-kazhdyj-data-inzhener-07-04
- Нарастающий итог
- Обобщенные табличные выражения
- Упорядочение данных
- Добавление подытогов
- Временные функции
- Дисперсия и среднеквадратическое отклонение
== ТОП-20 хитрых вопросов по SQL для собеседования
https://proglib.io/p/sql-questions
- Как найти дубликат записи?
- Как, используя
CTE, найти пятый по величине оклад в таблице?- Напишите SQL-запрос, с применением
UNION ALL (не UNION), использующий WHERE для устранения дубликатов.- Чем отличается
VARCHAR от NVARCHAR?- Что такое план запросов? Когда бы вы его использовали? Как посмотреть план?
- Как из таблицы выбрать все записи c четными ID? А с нечетными?
- Важен ли в составном индексе порядок столбцов?
- В чем разница между однорядными и многорядными функциями? Для чего используется
GROUP BY?- В чем разница между условиями
WHERE и HAVING?- Как получить последний
id без использования функции max?- Чем отличается
IN от EXISTS?Telegraph
8 первоклассных инструкций SQL на каждый день
Предлагаем вашему вниманию 8 инструкций SQL для экономии рабочего времени. Одни из них базовые, другие немного посложнее, но все из них вам пригодятся. Поэтому начнем без лишних разговоров. 1. Поиск повторяющихся строк по имени столбца С помощью этого простого…
== This is How IBM Will Revolutionize PC Gaming
https://youtu.be/z6u_oNIXFuU
https://youtu.be/z6u_oNIXFuU
YouTube
This is How IBM Will Revolutionize PC Gaming
We've been told by AMD (and @Hardwareunboxed) that cache matters for gaming. So how about giving everyone more cache? Not just L3, but a stonkingly massive L2 cache as well. IBM has the technology, and IBM has a deal with Intel. Coming soon, perhaps?
If…
If…