Это короткая статья для новичков. Наверняка вы знаете, что в пайтоне для циклов for и while предусмотрен блок else. И с этим блоком возникает много путаницы, потому что его действие на первый взгляд неинтуитивно. Приходится тратить немного времени или заглядывать в документацию каждый раз, когда он встречается:

for f in files:
    if f.uuid == match_uuid:
        break
else:
    raise FileNotFound()

Когда будет исключение: когда файл не найден? Когда найден? Когда список пуст? На этот вопрос сложно ответить, потому что блок else находится на одном уровне с блоком for и кажется, что это какое-то условие, относящиеся к самому списку; например, когда for не нашел ни одной записи. Но достаточно знать главный секрет блока else для циклов, чтобы больше никогда не терять на это время:

При выполнении запросов современные СУБД используют стоимостную модель оптимизации — на основе сохраненных в конфигурационных файлах коэффициентов и собранной статистики высчитывают “цену” получения и объем результирующих наборов строк. При повторном выполнении запросов стоимость и селективность высчитываются заново. Можно выполнить запрос и посмотреть реальные значения этих параметров, однако, в процессе (стандартного) повторного планирования оптимизатор СУБД эту информацию никак не использует.

А что, если бы оптимизатор сохранял реальные значения стоимости, селективности и другие необходимые параметры выполнения запроса и, при повторном его выполнении ориентировался не только на стандартную собранную статистику, но и на сохраненную после предыдущего выполнения?

Это называется адаптивная оптимизация запросов, и данный способ оптимизации является перспективным. В некоторых СУБД такие технологии уже используются.

Компания Postgres Professional уже несколько лет работает над расширением AQO для PostgreSQL, которое реализует (в некотором виде) адаптивную оптимизацию. Работы еще ведутся, но уже есть что потестировать.

Сначала — подробнее рассмотрим предметную область оптимизации запросов.

Добрый день! Меня зовут Владимир Столяров, я бэкенд-разработчик в команде Клиентские коммуникации в ДомКлике. В этой статье я расскажу о том, как внедрить кросс-платформенные пуш-уведомления. Хотя про это уже написано немало, я бы хотел рассказать о некоторых нюансах, с которыми нам пришлось столкнуться в процессе внедрения. Для лучшего понимания происходящего также напишем с вами небольшое веб-приложение, способное принимать пуши.

Расшифровка доклада 2020 года Брюса Момжиана "Unlocking the Postgres Lock Manager".

(Примечание: Все SQL запросы из слайдов вы можете получить по этой ссылке: http://momjian.us/main/writings/pgsql/locking.sql)

Привет! Замечательно снова быть здесь в России. Я прошу прощение, что я не смог приехать в прошлом году, но в этом году у Ивана и у меня большие планы. Я, надеюсь, что буду здесь гораздо чаще. Я обожаю приезжать в Россию. Я буду посещать Тюмень, Тверь. Я очень рад, что мне удастся побывать в этих городах.

Меня зовут Брюс Момжиан. Я работаю в EnterpriseDB и работаю с Postgres более 23 лет. Я живу в Филадельфии, в США. Путешествую примерно 90 дней в году. И посещаю порядка 40 конференций. Мой веб сайт, который содержит слайды, которые я вам буду сейчас показывать. Поэтому после конференции вы можете с моего личного сайта их скачать. Там также содержатся около 30 презентаций. А также есть видео и большое количество записей в блоге, более 500. Это достаточно содержательный ресурс. И если вам интересен этот материал, то я вас приглашаю им воспользоваться.

В конце есть краткое содержание.

Есть в Челябинске сетевая шиномонтажка, на каждом углу стоят их маленькие ларёчки. Они выдумали хитрый способ увеличения продаж. В сезон шиномонтажа, особенно осенью, они нанимают кучу бомжей и алкашей.

Получается примерно такая структура в каждом ларьке: управляющий, нормальный шиномонтажник, и куча бомжей. Управляющий занимается оплатой и организацией труда, с клиентами разговаривает, спорные ситуации разруливает. Шиномонтажник делает всю сложную работу – балансировку, перебортовку, контроль момента закручивания гаек и т.д.

А бомжи тупо снимают и ставят колёса. И, вроде, еще умеют их в мойку засовывать.

Схема простая. Приезжает человек переобуться, без предварительной записи. Видит – уже много машин стоит, и все вроде в работе. Расстраивается – придется развернуться и уехать, искать дальше… Но не тут-то было – подбегает управляющий, говорит – рады вас видеть, то сё, ща переобуем. Гена, Коля, тащите домкрат, обслуживайте клиента!

Подбегают бомжи и снимают одно или два колеса. Ну и всё, клиент в домике.

Всем привет! Меня зовут Слава Фомин, я ведущий разработчик в компании DomClick. За свою 16-ти летнюю практику я в первых рядах наблюдал за становлением и развитием JavaScript как стандарта и экосистемы. В нашей компании мы используем JavaScript, в первую очередь, для продвинутой front-end разработки и успели перепробовать достаточно большое количество различных технологий, инструментов и подходов, набить много шишек. Результатом этого кропотливого труда стал ценнейший опыт, которым я и хочу поделиться с вами.

Всем привет! Хочу очередной раз поднять тему про найм. Только я собираюсь поговорить об этом с точки зрения кандидата, а не работодателя. Ведь собеседование, вопреки многим стереотипам, процесс двусторонний — вопросы может задавать не только интервьюер, но и сам соискатель. За прошлый год я провёл порядочное количество собеседований, и абсолютное большинство кандидатов огорчило меня отсутствием вопросов о компании, всего 5 человек стали меня расспрашивать о работе.

Я же считаю, что вопросы на собеседовании должен задавать и сам кандидат, ведь ему предстоит там работать. Из стандартного описания вакансии невозможно понять, что творится в компании, да и на собеседовании принято всё немного приукрашивать. Я думаю, что соискатель должен максимально использовать собеседование для того, чтобы выяснить реальное положение дел в компании. Мало кому захочется попасть в некомфортные условия или в убыточную компанию без перспектив. Если интересно, как во время собеседования получить реальное представление о компании, то добро пожаловать под кат. Я дам список вопросов, которые обычно не ждут интервьюеры, возможно кому-то они помогут принять правильное решение при поиске работы.

Кейс компании Appbooster

Полагаю, практически каждый проект, использующий Ruby on Rails и Postgres в качестве основного вооружения на бэкенде находится в перманентной борьбе между скоростью разработки, читаемостью/поддерживаемостью кода и скоростью работы проекта в продакшене. Я расскажу о своем опыте балансирования между этими тремя китами в кейсе, где на входе страдали читаемость и скорость работы, а на выходе получилось сделать то, что до меня безуспешно пытались сделать несколько талантливых инженеров.

С самого начала своего пути как разработчика программного обеспечения я очень любил копаться во внутренностях языков программирования. Мне всегда было интересно, как устроена та или иная конструкция, как работает та или иная команда, что под капотом у синтаксического сахара и т.п. Недавно мне на глаза попалась интересная статья с примерами того, как не всегда очевидно работают mutable- и immutable-объекты в Python. На мой взгляд, ключевое — это то, как меняется поведение кода в зависимости от используемого типа данных, при сохранении идентичной семантики и используемых языковых конструкциях. Это отличный пример того, что думать надо не только при написании, но и при использовании. Предлагаю всем желающим ознакомиться с переводом.



Попробуйте решить эти три задачи, а потом сверьтесь с ответами в конце статьи.

Совет: у задач есть кое-что общее, поэтому освежите в памяти решение первой задачи, когда перейдёте ко второй или третьей, так вам будет проще.

До весны 2020 года, т.е. до реального и вынужденного столкновения с удаленной работой, большинство людей, работающих в офисе пятидневную рабочую неделю, имели смутные или стереотипные представления о подобном формате занятости.

За последние пару месяцев около трети работающего населения России получили первый опыт работы на «удаленке», в процессе адаптации к которой многим открылась совершенно новая реальность, которая оказалось существенно глубже и противоречивей, чем существовавшие до этого представления о ней.

Привет, Хабр! Следующий этап изучения нового языка это старый добрый todo list c картинками. Чтобы научится работе с базой данных и файловой системой. Работе со стримами. За подробностями добро пожаловать под кат.

Кейси Розенталь (Casey Rosenthal), CEO и сооснователь Verica.io, выступил на митапе Test in Production. Кейси развенчал некоторые мифы о надёжности и объяснил, что многие интуитивные действия по увеличению надёжности систем на самом деле контрпродуктивны. Более того, он объяснил, как концепция непрерывной проверки (Continuous Verification) помогает разработчикам избегать таких подводных камней.

Полное выступление Кейси:

Большинство программистов понимают, что асинхронный Python-код имеет более высокий уровень конкурентности, чем обычный синхронный код. Это даёт некоторые основания полагать, что асинхронный код способен показывать более высокий уровень производительности при решении распространённых задач вроде выдачи динамических веб-страниц или поддержки веб-API.



Но, к сожалению, Python-интерпретатор не выполняет асинхронный код быстрее синхронного.

В реалистичных условиях асинхронные веб-фреймворки показывают немного худшую пропускную способность (выраженную в запросах в секунду), чем обычные, и отличаются гораздо более сильной изменчивостью задержек.

Каждый разработчик ПО должен знать как создать библиотеку с нуля. В процессе работы Вы можете многому научиться. Только не забудьте запастись временем и терпением.

Может показаться, что создать библиотеку с открытым исходным кодом сложно, но Вам не нужно быть потрепанным жизнью ветераном своего дела, чтобы разобраться в коде. Также как Вам не нужна мудреная идея продукта. Но точно понадобятся настойчивость и время. Надеюсь, что данное руководство поможет Вам создать первый проект с минимальной затратой и первого, и второго.

В этой статье мы пошагово разберем процесс создания базовой библиотеки на Python. Не забудьте заменить в приведенном ниже коде my_package, my_file и т.п. нужными вам именами.

Шаг 1: Составьте план

Мы планируем создать простую библиотеку для использования в Python. Данная библиотека позволит пользователю легко конвертировать блокнот Jupyter в HTML-файл или Python-скрипт.
Первая итерация нашей библиотеки позволит вызвать функцию, которая выведет определенное сообщение.

Теперь, когда мы уже знаем, что хотим делать, нужно придумать название для библиотеки.

В мануале есть всё. Но чтобы его целиком прочитать и осознать, можно потратить годы. Поэтому один из самых эффективных методов обучения новым возможностям Postgres — это посмотреть, как делают коллеги. На конкретных примерах. Эта статья может быть интересна тем, кто хочет глубже использовать возможности postgres или рассматривает переход на эту СУБД.

В данной HOWTO мы исправим баг в древней версии nginx ingress controller v0.20.0 и научимся работать с зависимостями Go старых версий через dep + vendor.

В предыдущей статье мы научились снимать состояние блокировок на сервере PostgreSQL ровно в тот момент, когда они происходят. В этой — научимся трактовать собранное и узнавать, кто именно может скрываться за конкретной матрицей конфликтов, и почему результат выглядит именно так.

Я провёл своё детство во Франции, много играл в футбол и слишком долго смотрел телевизор. В 80-х во Франции было три телеканала. Два из них, Antenne 2 и FR3, финансировались государством и были скучными, а TF1 был частным и показывал много японских мультиков. Моё поколение выросло на «Капитане Цубасе», «Святом Сейя», «Капитане Харлоке» и «Грендайзере».

У нас не было ни кабельного, ни Интернета, телесигнал транслировался по воздуху и на крыше каждого дома стояла ловившая волны антенна.

Всё изменилось в 1984 году с появлением четвёртого канала. Canal Plus (Channel Plus) должен был совершить революцию на рынке телеканалов, показывая современные фильмы, спортивные трансляции со всего мира и не имея при этом рекламы. Для удовлетворения амбиций владельцев «Canal» должен был финансироваться ежемесячной абонентской платой подписчиков.

Техническая трудность такой схемы была совершенно понятна. Как гарантировать, что канал смогут смотреть только заплатившие абоненты, если его сигнал транслируется всем? Легко — достаточно закодировать его технологией под названием «Discret 11».

Я из компании Luxoft.
Предлагаю ознакомиться с расшифровкой доклада Андрей Сальников из Data Egret "Инструменты создания бэкапов PostgreSQL" . В конце обновленная сводная таблица по инструментам

Данный доклад посвящен доступным инструментам бэкапирования PostgreSQL. Логические backup, бинарные backup, встроенные средства бэкапирования и сторонние инструменты. Нужны ли инкрементальные backup, когда они могут действительно помочь. Посмотрим, когда и какой инструмент уместнее использовать. Как лучше автоматизировать процесс бэкапирования и проверки целостности сделанного бэкапа. Посмотрим вблизи на инструменты, такие как pg_dump, pg_basebackup, barman, wal-e, wal-g, pgbackrest, BART и pg_probackup.

Уже давно известно, что делать бэкапы в SQL-дампы (используя pg_dump или pg_dumpall) – не самая хорошая идея. Для резервного копирования СУБД PostgreSQL лучше использовать команду pg_basebackup, которая делает бинарную копию WAL-журналов. Но когда вы начнёте изучать весь процесс создания копии и восстановления, то поймёте что нужно написать как минимум пару трёхколёсных велосипедов, чтобы всё это работало и не вызывало у вас боль как сверху, так и снизу. Дабы облегчить страдания был разработан WAL-G.

WAL-G – это инструмент, написанный на Go для резервного копирования и восстановления PostgreSQL баз данных (а с недавнего времени и MySQL/MariaDB, MongoDB и FoundationDB). Он поддерживает работу с хранилищами Amazon S3 (и аналогами, например, Yandex Object Storage), а также Google Cloud Storage, Azure Storage, Swift Object Storage и просто с файловой системой. Вся настройка сводится к простым шагам, но из-за того что статьи о нём разрозненны по интернету – нет полного how-to мануала, который бы включал все шаги от и до (на Хабре есть несколько постов, но многие моменты там упущены).