Недавно на Хабре была опубликована статья Морской бой в PostgreSQL. Должен признаться: я обожаю решать на SQL задачи, для SQL не предназначенные. Особенно одним SQL-оператором. И полностью согласен с авторами:

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

И еще. Будем честны: всегда использовать SQL по назначению — тоска зеленая. Вспомните, какие примеры приводятся во всех учебниках, начиная с той самой статьи Кодда? Поставщики да детали, сотрудники да отделы… А где же удовольствие, где же фан? Для меня один из источников вдохновения — сравнение процедурных решений с декларативными.

Я, позвольте, не буду объяснять, что такое Жизнь Джона Конвея. Скажу только, что — оказывается — используя клеточный автомат Жизни, можно построить универсальную машину Тьюринга. Мне кажется, это грандиозный факт.

Так вот, можно ли реализовать игру Жизнь одним оператором SQL?

Привет!

Поговорим о том, что реально влияет на скорость передачи данных в современных беспроводных сетях, развенчаем пару мифов и ответим, пора ли поменять свой старенький роутер на сверкающего рогатого пришельца с MU-MIMO на борту.

Для разминки — небольшая задачка. Представьте себе беспроводную сеть Wi-Fi, состоящую из точки доступа (AP) и двух одинаковых клиентских устройств (STA1 и STA2).

Читаем надписи на коробках:
AP: 1733,3 Мбит/c
STA1, STA2: 866,7 Мбит/c

Внимание, вопрос. Оба клиента одновременно начинают загружать с сервера большой файл. На какую пропускную способность может рассчитывать каждое из устройств?

Задача: используя наименьшее возможное количество ресурсов, отрендерить осмысленный текст.

• Насколько маленьким может быть читаемый шрифт?
• Сколько памяти понадобится, чтобы его хранить?
• Сколько кода понадобится, чтобы его использовать?

Посмотрим, что у нас получится. Спойлер:

Чтобы разобраться в этом вопросе, нужно понимать основные принципы и условия работы данного устройства. Усилитель сотовой связи или по-другому репитер, повторитель сигнала, решает поставленную перед ним задачу в связке с другими компонентами — приёмопередающими антеннами — внешней и внутренней, а также высокочастотным кабелем, объединяющем все устройства в единую систему усиления сигнала.

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

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

Принцип работы усилителя сотовой связи

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

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

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

Наблюдение за изменением состояния в базе данных, мониторинг размера очередей, телеметрия с удаленных серверов, запуск деплой скриптов и получение нотификации по завершению — конфигурируется за минуту простым YAML файлом.

Код доступен на гитхабе. Инструкции по установке — для Linux, macOS и (экспериментально) Windows.

У нас было 150 дисков, 300 литров пива и 150 айтишников, готовых пустить все это в дело.
Это мы про DISKOBALL: первые в России соревнования по метанию HDD-дисков, которые пройдут 23 августа в Москве.

Участники соревнований поборются за главный приз — электросамокат.
А всех желающих ждет настольный теннис, гигантская дженга, уничтожение HDD-дисков кувалдой и вкусные угощения весь вечер.

Если вы сисадмин, инженер или просто практикующий ИТ-специалист, ждем вас
23 августа в 15 часов на стадионе «Метеор» (г. Москва).
Подробности и регистрация на официальном сайте

P.S.: С таким летом, возможно, нам понадобится не пиво, а глинтвейн и пледы — но веселью это все равно не помешает ;)

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

Затем мы рассмотрели внутристраничную очистку (и HOT-обновления), обычную очистку, ну а сегодня посмотрим на автоматическую очистку.

Автоочистка (autovacuum)

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

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

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

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

Автоматическая очистка — как раз тот самый механизм, который позволяет запускать очистку в зависимости от активности изменений в таблицах.

Осторожно, лонгрид. TL;DR. Много курил, давно бросил. Есть интересное наблюдение на тему вредных привычек. Не встречал его в других источниках. У части людей, бросивших курить, годами сохраняется зависимость, несмотря на то, что они не употребляют сигареты. Привычка продолжает косвенно влиять на жизнь. Это можно исправить. Ниже опишу некоторые признаки проблемы и постараюсь ее декомпозировать. Ничего не продаю. Это личный опыт, из которого выжата кое-какая теоретическая база. Может пригодиться, если вы бросили курить, но боитесь рецидивов. Или разделяете один из характерных стереотипов, например: «бывших курильщиков не бывает», «это болезнь на всю жизнь...», «курение — страшное зло». Мне кажется, принцип актуален и для других зависимостей от доступных эндорфинов: тяги к сладкому, обжорства, алкоголизма на обратимых стадиях, игромании и др.

C. G. Bell, W. D. Strecker, “Computer What Have We Learned from the PDP-11,” The 3rd Annual Symposium on Computer Architecture Conference Proceedings, pp. l-14, 1976.

Эта статья, которую я выбрал сегодня, является ретроспективой компьютерного дизайна. Это одна из ряда статей Гордона Белла с различными соавторами, описывающей разработку, рост, и внезапную замену культовой линейки продуктов компании, миникомпьютеров PDP-11.

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

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

Но компанию, ее культуру это внедрение превратило в ад — бюрократический, системный и бессмысленный.

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

Обо всем по порядку.

IT — не детский садик. Это место для взрослых, руководствующихся логикой и здравым смыслом. Их не надо опекать, не надо следить за словами, не надо переживать, что у них сформируются комплексы. Если человек некомпетентен, надо дать ему об этом явно понять, а не беречь его нежные чувства в ущерб всем остальным.

Так какого же чёрта моё прекрасное IT превращается в детский сад «Весёлый Програм-Мишка»?

Очень коротко покажу, как настроить PG для логирования планов выполнения запросов и как потом, не искать по логам всё, что медленно исполнялось

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

В небольшой команде тимлид может попытаться судить обо всем происходящем на основе субъективных ощущений, но, чем больше компания, тем важнее использовать объективные данные и метрики. Александр Киселев (AleksandrKiselev) и Сергей Семенов в своем докладе на TeamLead Conf показали, как использовать данные, которые вы уже накопили, где взять дополнительные, и что они все вместе могут помочь определить неочевидные проблемы. И даже, аккумулировав опыт многих коллег, предложили варианты решения.


О спикерах: Александр Киселев и Сергей Семенов в IT мы уже больше 8 лет. Оба прошли путь от разработчика до тимлида и далее до product-менеджера. Сейчас работают над аналитическим сервисом GitLean, который автоматически собирает аналитику у команд разработки для тимлидов и CTO. Задача этого сервиса в том, чтобы технические менеджеры могли принимать свои решения на основе объективных данных.

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

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



Все это очень сильно бьет по эго и самооценке. Почему это происходит? Как с этим справиться? И надо ли справляться? Давайте разбираться вместе.

Последнее мероприятие Apple, на котором были представлены обновленные модели MacBook Air и Mac mini, прошло с обычной для компании торжественностью. Оба устройства, равно, как и MacBook Pro и iMac Pro, показанные ранее, оснащены чипом Т2. Чип, по словам представителей корпорации, повышает уровень безопасности пользовательских данных. Т2, собственно, является сопроцессором, который «специализируется» на информационной безопасности.

Несколько позже оказалось, что разработчики новых систем Apple очень широко понимают термин «информационная безопасность». В частности, компанией была введена новая мера — блокирование возможности ремонта устройств неавторизованными сервисными центрами и обычными ремонтниками. Об этом узнали едва ли не случайно.

От переводчика: Хоть посыл статьи Najaf Ali, переведённой ниже, и носит слегка рекламный оттенок («оставьте криптографию нам, экспертам»), но описанные в ней примеры показались мне довольно интересными и заслуживающими внимания.
Кроме того, никогда не будет лишним повторить прописную истину: не придумывайте свою крипто-защиту. И эта статья отлично иллюстрирует почему.

Мой сын заинтересовался программированием на Python, и у меня появился вопрос – есть ли сегодня возможность купить книгу для ребёнка в качестве самоучителя? Самоучители для взрослых детям не подходят – мотивации продираться самостоятельно через учебники программирования и у взрослых не всегда хватает, а у ребёнка скучное «академическое» изложение вообще может убить весь интерес к предмету на пятой странице.

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

Привет всем! Хочу поделиться с Вами своей идеей машинного обучения.

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

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

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

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

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