Forwarded from LEFT JOIN
🔥 SQL-запрос для проведения ABC-анализа
Если вы работали с аналитикой ассортиментной матрицы или продаж, то вы точно сталкивались с таким методом, как ABC-анализ.
И сегодня вместе с ребятами из IT Resume мы решили подробно разобрать: как сделать ABC анализ с помощью всего одного SQL-запроса.
Интересно, что некоторые используют ABC-анализ даже в личном тайм-менеджменте. Все потому что он основан на законе Парето, который легко можно переформулировать на абсолютно любую сферу. Например:
20% ваших действий приносят 80% результата
20% ваших клиентов приносят 80% прибыли
20% вашего ассортимента приносят 80% продаж
Ну дальше вы поняли... Кстати, узнать все про тайм-менеджмент вы сможете в сегодняшнем выпуске подкаста Data Heroes 👾
Если вы работали с аналитикой ассортиментной матрицы или продаж, то вы точно сталкивались с таким методом, как ABC-анализ.
И сегодня вместе с ребятами из IT Resume мы решили подробно разобрать: как сделать ABC анализ с помощью всего одного SQL-запроса.
Интересно, что некоторые используют ABC-анализ даже в личном тайм-менеджменте. Все потому что он основан на законе Парето, который легко можно переформулировать на абсолютно любую сферу. Например:
20% ваших действий приносят 80% результата
20% ваших клиентов приносят 80% прибыли
20% вашего ассортимента приносят 80% продаж
Ну дальше вы поняли... Кстати, узнать все про тайм-менеджмент вы сможете в сегодняшнем выпуске подкаста Data Heroes 👾
Не корреляцией единой. Доказательства причиноследстыенной связи на пайтн
https://nuancesprog.ru/p/16095/
https://nuancesprog.ru/p/16095/
NOP::Nuances of programming
4 пакета Python для причинно-следственного анализа данных
Эти 4 пакета Python - Causalinference, Causallib, Causalimpact и DoWhy - помогут овладеть навыками причинно-следственного анализа. Изучив эту область экспериментальной статистики, вы сможете устанавливать и обосновывать причинно-следственные связи при исследовании…
Forwarded from Sysadmin Tools 🇺🇦
PGCat
PS: thanks @nosingularity for the link
#postgresql #postgres #sql #rust
PgBouncer rewritten in Rust, with sharding, load balancing and failover support.
https://github.com/levkk/pgcatPS: thanks @nosingularity for the link
#postgresql #postgres #sql #rust
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