Часто жалуются, что count (*) в PostgreSQL очень медленный.

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

Почему count (*) такой медленный?

Большинство людей без проблем понимают, что следующий запрос будет выполняться медленно:

SELECT count(*)
FROM /* сложный запрос */;

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

Но многие люди потрясены, когда узнают, что следующий запрос медленный:

SELECT count(*) FROM large_table;

Тем не менее, если вы подумаете еще раз, все вышесказанное остается в силе: PostgreSQL должен вычислить результирующий набор, прежде чем сможет его посчитать. Поскольку в таблице не хранится «магический счетчик строк» (как в MyISAM MySQL), единственный способ подсчитать строки — это просмотреть их.

Поэтому count (*) обычно выполняет последовательное сканирование таблицы, что может быть довольно дорого.

В предыдущей статье мы обсуждали, почему функциональное программирование это совсем не то, что распиарено, и что оно совершенно не противоречит ООП, так, что даже сам "Дядя Боб" пишет про хороший ФП дизайн порождающий хороший ООП дизайн программы (и наоборот).

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

Но ведь в интернете буквально сотни статей про ФП и монады, зачем писать еще одну?

Дело в том, что все их (по крайней мере те что я читал) можно поделить условно на две категории: с одной стороны это статьи где вам объяснят что монада это моноид в категории эндофункторов, и что если монада T над неким топосом имеет правый сопряжённый, то категория T-алгебр над этой монадой — топос. На другой стороне располагаются статьи, где вам рассказывают, что монады — это коробки, в которых живут собачки, кошечки, и вот они из одних коробок перепрыгивают в другие, размножаются, исчезают… В итоге за горой аналогий понять что-то содержательное решительно невозможно.

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

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

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

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

Вот пример одной из них:

/* Простое число — целое положительное число, имеющее только два делителя: 1 и само себя */
function isPrimeNumber(number) {
    /* необходимо реализовать функцию, возвращающую true в случае, если number является простым числом и false в противном случае */
}

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

Практически все статьи, которые я видел на тему «чем хорош IPv6 и почему на него стоит пошустрее переходить», говорят только о просто более широком адресном пространстве. В лучшем случае, упомянут автоматическую конфигурацию адресов и маршрутов (stateless address autoconfiguration (SLAAC)). Это удручает, а ведь IPv6 имеет много ещё других неявных плюшек, являясь очень продуманным стеком протоколов (IPv6 + ICMPv6 + NDP)! Создаётся впечатление, что IPv6 это просто тупо про расширение адресов, а дальше то особо никакого профита. Или же некоторые статьи плачутся о том, что они не видят сиюминутного профита от внедрения/перехода. Простоту и удобство, гибкость и расширенные возможности (из-за одного только избавления от NAT-а) не так то легко измерить, как какие-нибудь задержки и пропускную способность. Решил поэтому собрать моё видение прекрасного мира IPv6 протокола и его плюсы в этой статье.

Прим. перев.: Проблема DNS в Kubernetes, а точнее — настройки параметра ndots, — на удивление популярна, причём уже не первый год. В очередной заметке по этой теме её автор — DevOps-инженер из крупной брокерской компании в Индии — в весьма простой и лаконичной манере рассказывает, о чём полезно знать коллегам, эксплуатирующим Kubernetes.



Одно из главных преимуществ развёртывания приложений в Kubernetes — беспроблемное обнаружение приложений. Внутрикластерное взаимодействие сильно упрощается благодаря концепции сервиса (Service), которая представляет собой виртуальный IP, поддерживающий набор IP-адресов pod'ов. Например, если сервис vanilla желает связаться с сервисом chocolate, он может обратиться напрямую к виртуальному IP для chocolate. Возникает вопрос: кто в данном случае разрешит DNS-запрос к chocolate и как?

Недавно я читал книгу «Компьютерные системы: архитектура и программирование. Взгляд программиста». Там, в главе про систему ввода-вывода Unix, авторы упомянули о том, что в конце файла нет особого символа EOF.



Если вы читали о системе ввода-вывода Unix/Linux, или экспериментировали с ней, если писали программы на C, которые читают данные из файлов, то это заявление вам, вероятно, покажется совершенно очевидным. Но давайте поближе присмотримся к следующим двум утверждениям, относящимся к тому, что я нашёл в книге:

1. EOF — это не символ.
2. В конце файлов нет некоего особого символа.

Что же такое EOF?

Братья Хаузеры из Rockstar редко дают интервью. Вряд ли и теперь они захотят делать это чаще.



На днях выходит Red Dead Redemption — их первая за пять лет игра после GTA V. Думаю, у нее все будет хорошо и без классических журналистских репортажей из офиса, но Хаузеры все же поболтали с Vulture, рассказали, как шла разработка. В огромном тексте было много важного и интересного, но всего одна реплика перебила остальные, растиражировалась и выросла в неприятный скандал накануне релиза (который, впрочем, тоже вряд ли помешает успеху).

У меня очень странная проблема с браузером. Скрипты на некоторых страницах просто не работают, пока не пройдёт около 20 секунд.

Что бы вы ни собирались предложить — да, я уже думала об этом, и нет, не помогло. Я рассказываю об этом не в надежде, что кто-то подскажет с отладкой, а потому что этот случай заставил меня остро осознать некоторые, как бы сказать… причуды… разработки на фронте.

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

Намибия — это очень необычная для Южной Африки страна. Во-первых, там по-африкански безопасно. В смысле, что если вы передвигаетесь по улицам днём, то вас не ограбят, не убьют и не изнасилуют. С очень высокой вероятностью. Если вы боитесь за свою безопасность, знакомство с Африкой южнее Кении лучше начинать как раз с Намибии.



Во-вторых, тут очень, прямо очень много животных, и можно за неделю увидеть всё то, про что вы только читали в детстве в африканских рассказах. Настолько удобного и разнообразного наблюдения я не встречал до этого ни в одном заповеднике — даже в знаменитом парке Крюгера в соседней ЮАР.



В-третьих, тут, как и везде в Африке, очень странно.

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

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


Панель управления квартирой в феврале 2020 года (Home Assistant)

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


Строительство нашего дома в процессе — ноябрь 2016 года

Зачастую статьи личного опыта имеют три категории от двух типов людей:

• история успеха / провала от новичков;
• крутые статьи про сложные штуки от крутых ребят;
• истории про разочарование от тех же крутых ребят (но это не точно *).

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

Если визуализировать свой опыт погружения в IT, то получится примерно следующее:

Правда, по четвёртому сценарию мой опыт пока что в духе "рядом стоял / мимо крокодил".

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

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

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

Такие сцены разыгрываются по всему миру бесчисленное количество раз в день. И это ситуация, в которой сложно понять физику движения и мотивы других водителей, о чем говорит тот факт, что в Соединенных Штатах каждый год происходит 1,4 миллиона аварий при поворотах. Теперь добавьте в эту ситуацию автономные автомобили. Обычно они ограничиваются только оценкой физических параметров и принимают более осторожные решения в ситуациях с неоднозначной обстановкой.

Подписывайтесь на каналы:
@AutomotiveRu — новости автоиндустрии, железо и психология вождения
@TeslaHackers — сообщество российских Tesla-хакеров, прокат и обучение дрифту на Tesla

Подписывайтесь на каналы:
@AutomotiveRu — новости автоиндустрии, железо и психология вождения
@TeslaHackers — сообщество российских Tesla-хакеров, прокат и обучение дрифту на Tesla

У меня Tesla Model 3 уже около года и она способна проезжать 260 миль без дополнительной зарядки. Когда я её покупал, у меня были догадки, на что она способна, а на что нет. Но я столкнулся с неожиданными сюрпризами, несмотря на то, что хорошо изучил эту тему и имею большой стаж вождения.

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

Вот мои открытия за год:
1. Общественные зарядные станции часто находятся в совершенно неподходящих местах и пользы от них мало. Оказывается, что единственные места, где медленная зарядка имеет смысл, — это дома, отели и офисы, те места, где вы надолго остаетесь. И хотя я предполагал, что буду заряжаться таким образом, но в реальности оказалось, что станций в таких местах практически нет. А еще зарядные станции берут в 2-3 раза больше денег, чем я бы заплатил дома, неудобные.

2. Я был приятно удивлен, что езда по городу намного приятнее в электромобиле, чем в машине на бензине, которую нужно заправлять раз в неделю или около того. Крюки до автозаправки тратят 10-15 минут времени каждую неделю. Моя машина заряжается во время сна и экономит время, если, конечно, парковаться прямо у розетки. И приятно осознавать, что вы не жжете бензин. (Об этом я знал.)

Перевод статьи из блога инженера Джорджа Хиллиарда


Кликабельно

Я инженер встроенных систем. В свободное время я часто ищу то, что можно будет использовать в проектировании будущих систем, или что-то из разряда моих интересов.

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

Я подумал: «Эти процессоры настолько дешёвые, что их практически можно раздавать даром». И через некоторое время ко мне пришла идея сделать голую карточку для Linux в форм-факторе визитной карточки.

Вчера бывший главный редактор TJournal, Никита Лихачёв, запостил в своём телеграм-канале пару длинных аудиосообщений, почти подкаст, где рассказывает, что он думает о реестре ОРИ, письмах в крупные интернет-сервисы из ФСБ и место Хабра во всей этой истории. Знаю, на Хабре больше любят читать, чем слушать, поэтому взял на себя труд расшифровать запись. Мне этим мысли показались интересными. Под катом чтиво на 5-7 минут.

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

Прим. перев.: Новая статья с критикой полюбившейся многим Git Flow получила столь заметное внимание, что даже оригинальный автор модели обновил публикацию 10-летней давности, актуализировав свой взгляд на её применение сегодня. Публикуем перевод как самой критики, так и официальной реакции.



Git-flow — это методология ветвления и слияния, сильно популяризированная заметкой 2010 года под названием «A Successful Git branching model» (была переведена на хабре как «Удачная модель ветвления для Git» — прим. перев.).

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

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

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

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

Киберздоровье через призму Мармока

Марин Мокану, более известный как «Marmok» — один из самых популярных игровых видеоблогеров в СНГ.

Его пример весьма показателен и, что самое главное, вполне характерен для любого человека, жизнь которого проходит за компьютером — вне зависимости от конкретного рода деятельности.

_{Фото: Лиза Швец/Facebook}

Лиза Швец начала свою карьеру на кабельном заводе, работала продавцом в небольшом магазинчике в Орле, а спустя несколько лет попала в Microsoft. Сейчас она работает над ИТ-брендом «Додо Пиццы». Перед ней стоит амбициозная задача — доказать, что «Додо Пицца» не только про еду, а про разработку и технологии. На следующей неделе Лизе 30, и мы решили вместе с ней подвести небольшие итоги ее карьерного пути и рассказать вам эту историю.