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

Все инструкции шаблона заключаются в символы.

1. Введенние.
2. Zval.
3. Циклические ссылки.
4. Сборщик мусора.
5. Алгоритм работы сборщика мусора.
6. Смотрим глазами.
7. Слабые ссылки.
8. Бонус-трэк: WeakMap.
9. Заключение.

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

Меня зовут Александр Пряхин, я TechUnit Lead в Авито. В IT работаю уже 14 лет. Из них 8 лет руковожу командами. Параллельно с этим преподаю и менторю. Сегодня разберём, как готовить демонов на PHP — от А до Я, и почему это актуально.

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

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

Я Александр Калинка из компании Evrone. Мы работаем удалённо с 2008 года и делаем это на собственных устройствах. Иногда возникает проблема, как установить, настроить и запустить все приложения и сервисы, необходимые для использования в проекте. Кто-то идет классическим путем, ставит необходимое локально на компьютер и работает с этим стеком. Но есть определенная часть программистов (и, несомненно, проектов), которые для развертывания необходимого зоопарка приложений используют Docker и Docker Compose. Устройства бывают разные, но особенно популярны Apple на чипсете M1 2020 года и на чипсете M2 2022 года. Работа Docker на них имеет некоторые особенности, о которых я хотел бы рассказать.

Ранее (11 февраля 2019) пост уже публиковался мной с таким заголовком, но был отправлен в небытие по причине смерти домена, а как следствие и сервиса с ним связанного. Причин тогда было две — статистика скачивания докер-образа оставляла желать лучшего, и цена за продление домена (что был зарегистрирован в nic) стала для меня неожиданно выше той, которую я был морально готов заплатить за него.

Но есть время не продлять домены разбрасывать камни, а есть время извиниться за сделанную ошибку. Все, кому сервис был полезен, кто им пользовался и однажды заметил что он (localhost.tools) не резолвится — приношу свои извинения, и исправляю ситуацию (лучше поздно чем никогда, верно?).

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

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

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

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

Начнем с конца: в итоге нам удалось освободить более чем 70 GB не оптимизированного и неиспользуемого пространства без удаления индексов и данных. 

Эта статья представляет собой краткий (шутка!) конспект одноименного (почти) вебинара, недавно проведенного автором.

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

Ну и немного раскрыть глаза на то, что, оказывается в PHP есть и асинхронность, и многопоточность, и в общем-то не нужно ждать мифической версии PHP 10, чтобы начать их использовать уже прямо сейчас!

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

Прим. перев.: автор данного исследования — Marc Richards, Solutions Architect и DevOps-инженер — продемонстрировал потрясающую настойчивость и тщательность в тотальной оптимизации производительности веб-приложения. Получившийся материал — кладезь полезных знаний для расширения своего кругозора в области оптимизации, особенностей сетевого стека в Linux и не только, даже вне зависимости от практической заинтересованности в конечном результате автора. Приготовьтесь к по-настоящему длинному техническому путешествию с обилием терминологии, увлекательных графиков и полезных ссылок.

Существует великое множество статей об оптимизации PostgreSQL — эта «кроличья нора» весьма глубока. Когда несколько лет назад я начал разрабатывать бэкэнд аналитического сервиса, у меня уже был опыт работы с другими СУБД, такими как MySQL и SQL Server. Тем не менее, раньше мне не приходилось так фокусироваться на производительности. В прошлых проектах, над которыми я работал, либо не было жестких требований к времени обработки (DS/ML), либо не требовалось обрабатывать много строк одновременно (обыкновенные веб-приложения). Однако в этот раз мои запросы:

• состояли из 3-10 JOIN-ов по коррелирующим запросам;

• уielded от 10 до 1,000,000 строк;

• должны были выполняться в течение времени, определенного UX-ом;

• не могли быть hinted — пока Cloud SQL, управляемый PostgreSQL в Google Cloud, не стал поддерживать pg_hint_plan в конце 2021 года;

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

Получение целого миллиона строк в одном API endpoint сигнализирует о проблеме в алгоритме или архитектуре. Конечно, все можно переписать и перепроектировать, но за это нужно платить.

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

В PostgreSQL есть два типа данных: JSON и JSONB. Первый формат является текстовым хранилищем, в котором json хранится "as is",  второй — бинарным, в нем ключи отсортированы  (сначала по длине ключа, а потом по его названию), дубликаты удалены, а пробелы удалены.

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

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

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

Зачем это может понадобиться? Предоставляя услуги поддержки инфраструктуры нашим клиентам, нам часто приходится искать баланс между эффективностью и затраченными ресурсами. Когда есть потребность в нескольких рабочих окружениях для разработчиков (stage, dev, test, review и т.п.), как правило, ограничивающим фактором в их реализации являются деньги. Поэтому для решения такой задачи — в дополнение к динамическим окружениям (или вместо них) — задействуются локальные окружения прямо на рабочих местах разработчиков, о которых и пойдет речь далее.

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

Именно этот вариант мы рассмотрим сегодня и покажем, как запускать отладчик на кластере Kubernetes через IDE-среду Visual Studio Code (VS Code). В качестве приложения у нас будет программа на Go, но всё изложенное вполне применимо и к другим языкам программирования и отладчикам.

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

Повествование будет разбито на две части, от простого к сложному. 

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

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