Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL.

Новости

Главное событие месяца — это, конечно, Feature Freeze. Мартовский коммитфест закрыт. Основной облик версии PostgreSQL 12 определился. Дальше будут доработки и исправления, но не изменения в функциональности. О наиболее важных фичах 12 версии в ближайшее время мы сделаем отдельную публикацию.

Уязвима ли «уязвимость»

Под загадочным кодом CVE-2019-9193 скрывается политически важная для сообщества причина беспокойства. Речь о конструкции COPY… PROGRAM, появившейся еще в 9.3, которая дает возможность исполнять в запросе файлы ОС и писать в стандартный ввод или читать из стандартного вывода программы.

When a vulnerability is not a vulnerability

Однако, классик PostgreSQL Магнус Хагандер (Magnus Hagander) разъясняет в своем блоге:
Эта «уязвимость» эквивалентна тому факту, что в типичной Unix-системе вы можете залогиниться рутом и создавать или редактировать файлы, и исполнять команды как root. <...> Будучи суперюзером, можно запускать файлы в ОС отнюдь не только при помощи COPY… PROGRAM." <...> Итак, уязвимости в PostgreSQL нет, зато однозначно есть уязвимые инсталляции PostgreSQL.

Когда я начал изучать JavaScript, то первым делом составил список приемов, которые помогали мне экономить время. Я подсмотрел их у других программистов, на разных сайтах и в мануалах.

В этой статье я покажу 12 отличных способов улучшить и ускорить свой JavaScript-код. В большинстве случаев они универсальны.

На Ruby и многих других языках есть удобные ORM-решения для программного доступа к СУБД. Также есть фреймворки вроде RubyOnRails для простого и удобного создания web-приложений, работающих с базой данных. Простые соглашения позволяют писать мало кода и при этом создавать мощные интерфейсы.

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

Стандартные действия для получения возможности работы с сущностью в Rails — создать модель, создать контроллер, создать представление (а если у нас полный набор REST-действий, то два — на получение списка и на получение одной записи в случае работы через API). Действия простые, и файлы очень простые. И когда словарей много, то файлов получим также большое количество. Большое количество простых и однотипных файлов. И где-то среди них будут затеряны большие, нетипичные файлы. Кроме большого количества файлов, мы получаем проблемы с необходимостью прописывать маршруты. Даже тем, кто такие системы поддерживает не один год, ориентироваться в проекте будет тяжело, не то что новому разработчику.

Здесь на помощь приходит магия Rails.

Для простоты предположим, что мы строим JSON API. Хотя ничто не помешает нам добавить поддержку XML.

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

В 20-м веке жизнь и работа людей шли по плану. На работе (упрощая — можно представить завод) у людей имелся четкий план на неделю, на месяц, на год вперед. Упрощая: тебе надо выпилить 20 деталей. Никто не придет и не скажет, что деталей теперь надо выпилить 37, а кроме того, написать статью с размышлениями о том, почему форма этих деталей именно такая — и желательно вчера.

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

В этих условиях сформировался культурный код, где ты чувствуешь себя удовлетворенным, если выполнил все задачи. И это было реально. Невыполнение всех задач — отклонение от нормы.
Сейчас все иначе. Орудием труда стал интеллект, и в рабочих процессах необходимо его использовать в разных ипостасях. Современный менеджер (особенно топ-менеджер) проходит через десятки задач разного типа в течение дня. А главное — управлять количеством «входящих сообщений» человек не может. Новые задачи могут отменить старые, изменить их приоритет, изменить саму постановку старых задач. В этих условиях сформировать заранее план и потом его выполнять поэтапно практически невозможно. Ты не можешь на прилетевшую задачу «у нас срочный запрос от налоговой, надо ответить сегодня, иначе штраф» сказать «запланирую на следующую неделю».

Как с этим жить — чтобы оставалось время на жизнь вне работы? И можно ли применить какие-то рабочие алгоритмы менеджмента в повседневной, бытовой жизни? 3 месяца назад я кардинальным образом поменял всю систему постановки задач и контроля за ними. Хочу рассказать, как я к этому пришёл и что в итоге получилось. Пьеса будет в 2 частях: в первой — немножко про, если так можно выразиться, идеологию. А вторая — целиком про практику.

Как похорошел интернет при… или какие полезные (и не очень) госуслуги можно получить онлайн.

Наркоман ли я? Бабушкин суд у подъезда думает, что да (на самом деле нет — я всегда с ними здоровался, а теперь и справка есть!). Был ли я зеком? Сведений не имеется, гласит другая справка. Проходил ли я диспансеризацию? Однозначно да, хотя я этого и не помню, но это не повод не заплатить 1400 рублей за такую «услугу» государству в адрес медучреждения. Какой размер моего ИПК? Государство говорит, что он у меня большой и с возрастом будет становиться только больше и лучше, но мы-то знаем (ц).

Американские хакеры решили повлиять на результаты выборов в России, но пока просто не могут зарегистрироваться на сайте Госуслуг.
_{(с) интернет}

О статье

Под катом я расскажу с нотариально незаверенными скриншотами про полезные и не очень государственные услуги, полученные мной (либо не полученные вовсе). Опишу как они упрощают жизнь, либо наоборот её усложняют. Пост будет больше ироничным, т.к. большинство услуг всё же бесполезны, либо работают не так как надо, а те что работают — используются нечасто.

Думали ли вы о том, чтобы воспользоваться при разработке своего очередного веб-проекта простейшим из существующих набором технологий? Если это так — значит материал, перевод которого мы публикуем сегодня, написан специально для вас.

JavaScript-фреймворки существуют для того чтобы помочь нам создавать приложения, обладающие сходными возможностями, используя обобщённый подход. Однако многим приложениям вся та мощь, которую дают фреймворки, не нужна. Использование какого-нибудь фреймворка в проекте небольшого или среднего масштаба, к которому предъявляются некие специфические требования, вполне может оказаться ненужной тратой сил и времени.



В этой статье мы поговорим о применении современных технологий при разработке веб-приложений, возможности которых не ограничены возможностями фреймворков. Кстати, если вам это нужно, то вы, с использованием описываемых здесь технологий, сможете создать собственный узкоспециализированный фреймворк. Чистый JavaScript и другие базовые веб-технологии дают разработчикам возможность делать то, что им нужно, не ограничивая себя рамками применяемых ими инструментов.

Технологии контейнеризации приложений нашли широкое применение в сферах разработки ПО и анализа данных. Эти технологии помогают сделать приложения более безопасными, облегчают их развёртывание и улучшают возможности по их масштабированию. Рост и развитие технологий контейнеризации можно считать одним из важнейших трендов современности.

Docker — это платформа, которая предназначена для разработки, развёртывания и запуска приложений в контейнерах. Слово «Docker» в последнее время стало чем-то вроде синонима слова «контейнеризация». И если вы ещё не пользуетесь Docker, но при этом работаете или собираетесь работать в сферах разработки приложений или анализа данных, то Docker — это то, с чем вы непременно встретитесь в будущем.

→ Часть 1: основы
→ Часть 2: термины и концепции
→ Часть 3: файлы Dockerfile
→ Часть 4: уменьшение размеров образов и ускорение их сборки
→ Часть 5: команды
→ Часть 6: работа с данными



Если вы пока не знаете о том, что такое Docker, сейчас у вас есть шанс сделать первый шаг к пониманию этой платформы. А именно, освоив этот материал, вы разберётесь с основами Docker и попутно приготовите пиццу.

Итак, вы решили сделать новый проект. И проект этот — веб-приложение. Сколько времени уйдёт на создание базового прототипа? Насколько это сложно? Что должен уже со старта уметь современный веб-сайт?

В этой статье мы попробуем набросать boilerplate простейшего веб-приложения со следующей архитектурой:

Что мы покроем:

• настройка dev-окружения в docker-compose.
• создание бэкенда на Flask.
• создание фронтенда на Express.
• сборка JS с помощью Webpack.
• React, Redux и server side rendering.
• очереди задач с RQ.

Предисловие

Markdown это прекрасный способ написать небольшую статью, а иногда и достаточно объемный текст, с несложным форматированием в виде курсива и толстого шрифта. Также Markdown неплох для написания статей с включением исходного кода. Но иногда хочется без потерь, танцев с бубном перегнать его в обычный, хорошо оформленный файл PDF, и чтобы не было проблем при конвертации, какие, например были у меня — нельзя писать по русски в комментариях исходного кода, слишком длинные строки не переносятся, а обрезаются и прочие мелкие проблемы. Инструкция позволит быстро настроить конвертер md2pdf не особенно вникая как это работает. Скрипт для более менее автоматической установки ниже в соотвествующем разделе.

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

Мы продолжаем публиковать видео и расшифровки лучших докладов с конференции PGConf.Russia 2019. В первой части доклада Ивана Фролкова речь шла о непоследовательном именовании, о constraints, о том, где лучше сосредоточить логику — в базе или в приложении. В этой части вас ждет разбор обработки ошибок, конкурентного доступа, неотменяемых операций, CTE и JSON.



Расскажу такую историю. Наш клиент говорит: «Медленно работает база, а наше приложение занимается обслуживаем населения. Мы боимся, что нас тут поднимут на вилы». Выяснилось, что у них было очень много процессов в состоянии idle in transaction. Приложение начало транзакцию, ничего не делает, но и транзакцию не завершает. Если вы взаимодействуете с какими-то внешними сервисами, то, в принципе, это нормальная ситуация. Другое дело, что если у вас состояние idle in transaction длится долго (больше минуты уже подозрительно), то это плохо потому, что PostgreSQL очень не любит долгие транзакции: VACUUM не сможет почистить все те строки, которые он мог бы увидеть, и долго висящая транзакция эффективно блокирует VACUUM. Начинают разбухать таблицы, индексы становятся всё менее эффективными.

Привет, Хабр! Эту статью меня подвигла написать замечательная история, как одна новозеландская компания 8 недель работала с тремя выходными. И как мы ими как бы гордимся.

Контекст

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

Мы придумываем, как этим управлять и первые пробы и эксперименты, разумеется, ставим на себе. Очевидно: занимается мы HR в ИТ.

Итак

Эксперимент: четырехдневная рабочая неделя.

Место действия: Москва и Киев. Распределенный коллектив.
Интеллектуальный труд. Самоокупаемая коммерческая компания.
Продолжительность эксперимента: более 100 сотруднико-лет.
Подробности под катом.

— Коля, отвали…
— Ну Ира…
Коля стоял и канючил, сам толком не зная, чего. Староста Ира, организатор до мозга костей, руководила даже подготовкой к экзамену. До прихода профессора оставалось минут пятнадцать, и Ира бегала, как заведённая, между студентами и у всех что-то спрашивала. Коля таскался следом.
— Ну Ира… Как мне быть-то…
— Да ты достал уже, Коля! Если у тебя мозгов нет, я что сделаю!
— Да почему нет-то… Смотри, какие я шпоры нарисовал.
Коля дрожащими руками теребил маленькие бумажки – они, надо сказать, действительно были хороши.
— Коля… — простонала Ира. – Ты же был на консультации, и на обсуждении после нее. Что мы решили делать?
— Я не помню…
— БОМБЫ, КОЛЯ! – закричала староста. – Он палит так, что мама не горюй! Столы пустые, только листок и ручка, а ты свои шпоры притащил! Что ты с ними делать будешь?
— Так это, списывать же… — не отставал Коля. – Как всегда…
— Как всегда не получится! Господи, какой же ты… Всё, отвали!

Чуть более месяца назад в Москве состоялась крупнейшая конференция постгресового сообщества PGConf.Russia 2019, собравшая в МГУ свыше 700 человек. Мы решили выложить видео и расшифровку лучших докладов. Выступление Ивана Фролкова с разбором типичных ошибок при работе с PostgreSQL было отмечено лучшим на конференции, поэтому мы начнем с него.

Для удобства мы разбили расшифровку на две части. В этой статье речь пойдет о непоследовательном именовании, о constraints, о том, где лучше сосредоточить логику — в базе или в приложении. Во второй части будут разобраны обработка ошибок, конкурентный доступ, неотменяемые операции, CTE и JSON.



В нашей компании я занимаюсь поддержкой клиентов по вопросам, связанным с приложениями, то есть помогаю в случаях проблем с соединениями, с оптимизацией запросов и прочими подобными вещами. Насмотрелся я приложений самых разных. Чего я только не видел! Может быть даже больше, чем хотелось бы. Часть из того, что я буду рассказывать, относится не только к PostgreSQL, а к любой базе, но кое-что прежде всего к PostgreSQL.

Главный вывод, который я смог сделать из того, что я видел, довольно неожиданный: фактически любое приложение при должной настойчивости можно заставить работать. Был замечательный проект (я не могу упоминать все компании, с которыми мы работали), в котором еще более замечательное приложение создавало таблицы миллионами. Выглядело это так: в понедельник система работает неплохо, а уже в пятницу она практически не работает. На выходные дни запускают VACUUM FULL, и в понедельник она опять работает хорошо. Оказывается, над PostgreSQL можно вот так издеваться, и всё это довольно долго будет жить и работать. Другой товарищ сделал странную вещь: у него всё было построено на триггерах, процедур не было вообще. То есть большую часть таблиц трогать нельзя, сделать что-либо не получалось, но и эта база жила.

Здравствуйте уважаемые!
Расскажу о «бизнесе» — призоловство. И сколько денег на нём можно поднять. Сразу скажу – если ты не ленишься и живешь в городе милионнике – в летний месяц легко делать порядка 100-150 тыс руб., причем даже не бросая основного места работы.
Моя специализация была: «пластик» — это крышки различных акций напитков и пива: спрайт, гринбир, колы всякие, медведь, три толстяка… можно перечислить все представленные на нашем рынке продукты.


Но, так же я не брезговал и другими акциями: сигаретные, продуктовые и т.д – благо, если ты «барыжишь» хотя бы одним видом кодов, то их всегда с удовольствием готовы обменять на любом призоловском форуме.

Давайте пробежимся коротко по эволюции вагона. Очень быстро и поверхностно, небольшими интересными кусочками без длинных периодов доделки. Начнём с тормозной магистрали и кондукторов. Тормозную воздушную магистраль поезда придумали далеко не сразу. Сначала были вот такие места тормозильщиков (их на французский манер сразу назвали кондукторами): на тормозной площадке вагона сидел человек, который ждал тройного свистка. Это был сигнал закручивать тормоз. После остановки он ждал сигнала откручивать тормоз. На фото реконструкции Музея железных дорог России в Петербурге не видно, как сильно он старался завернуться в одежду. Мёрзли они очень сильно:



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



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

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

Все бы ничего, только с помощью такого отчета сложно управлять. Анализировать – можно, если есть куча свободного времени. А у кого есть куча свободного времени? У аналитика есть, например. Ладно, если он по должности аналитик. Есть ведь по призванию души аналитики. Должность у него, например, менеджер по продажам, но продавать он не хочет или не умеет, а вот в цифрах ковыряться – милое дело.

У руководителя времени на ковыряние в отчете, увы, нет. По крайней мере, в рамках регулярного менеджмента. Ему нужна короткая, емкая информация, отвечающая на простой вопрос: как идут дела? Или по-другому: у нас все хорошо?

Как на такой вопрос ответить с помощью портянки? Да никак. Портянка как бы говорит руководителю: ты хотел информацию? Ну вот она. ВСЯ! Давай, разбирайся, и ищи ответ на свой вопрос.

Привет, Хабр! Несколько месяцев назад у меня остро встал вопрос смены профиля деятельности и я обнаружил, что для претендента на вакансию web-разработчика сейчас недостаточно навыков десятилетней давности (какая неожиданность!). Пришлось срочно актуализировать свои знания. Заодно я решил составить шпаргалку с описанием большинства современных технологий, чтобы в случае чего кидать жаждущим новых знаний линк на эту статью, да и самому не забывать.

Как это вам надо две недели на эту задачу? Что, правда? Вот на эту элементарную формочку с тремя полями и двумя кнопками? Две недели? Да вы надо мной издеваетесь, наверное! Давайте разбираться.

Что? Нужна ли валидация данных при вводе? Ну, конечно, нужна! И вообще, вот это поле лучше разбить на два, так понятнее. А вот в это добавить маску. А вот это — заменить на выпадающий список. Где брать варианты для этого списка? В базе на сервере, конечно. Как это их там нет? А, ну да, это же в другом проекте они у нас были… Ну, значит надо добавить. Взять там и добавить сюда. Сейчас я дам вам контакт разработчика того проекта — обсудите с ним. Он, правда, у нас уже не работает, но я думаю, вполне можно спросить что и как — он расскажет, скорее всего.

Мы всё обсудили? Нет? Что ещё?

В этой статье вас ждёт десять лучших докладов от Андрея Александреску, Дэвида Вандервурда, Джона Калба и многих других.

Фичи компилятора C++, асинхронность, многопоточность, параллелизм, модель памяти, алгоритмы и STL, метапрограммирование и рефлекшен, огромное множество тем.

Всё это — записи с конференции C++ Russia, самой большой в истории. Восемь сотен участников, немаленький зал, спикеры с мировым именем. Прошёл год, но большинство докладов ничуть не утратило своей актуальности. Впрочем, и неудивительно — именно такие доклады и попадают в топ по оценке участников.

Формат таков:

• Обязательное видео на YouTube
• Слайды, если есть
• Подробное описание доклада на русском языке
• Краткая биография докладчика

Плюс у вас есть комментарии Хабра, чтобы обсудить увиденное. Реклама на ютубе отключена, никто не будет мешать. Есть всё, чтобы начать смотреть прямо сейчас.