Когда перед нами встаёт задача хранения и управления иерархическими структурами данных всегда приходится выбирать из довольно ограниченного набора паттернов. Для того чтобы найти наиболее подходящий шаблон необходимо проанализировать особенности каждого способа хранения и обработки данных и оценить их с учётом задачи и специфики используемой СУБД.

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

Наша цель – разработать свою реализацию, учитывающую требования нашего приложения.

Что нового в Laravel 8. Руководство по обновлению до новой версии. Laravel Jetstream. Пакетирование задач. Набор компонентов для Blade-шаблонов.

Привет, Хабр!

Несколько лет назад я начал разрабатывать свой агрегатор контента, что бы упростить свой серфинг в сети. Изначально я парсил только rss, vk и facebook, но в прошлом году решил сделать полный рефакторинг проекта: отказаться от парсинга на клиенте, сделать нормальный back-end, использовать базу данных для хранения данных и расширить список поддерживаемых ресурсов.

Помимо стандартного набора из rss, fb, vk, twitter, instagram, youtube я добавил поддержку произвольных открытых каналов из telegram.


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

[UPDATE 2019-03-12]
Мой новый пост про парсинг телеграм каналов: habr.com/ru/post/354000. Более качественный код, микросервисы с открытым исходным кодом и новый публичный сервер для тестов.
[UPDATE 2023-10-08]
Важное напоминание: Телеграмм не разрешает парсить аудиторию каналов. Используя серверный клиент можно получить только те данные, которые видны в обычном, оффициальном приложении.

Интерфейс

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

Свойства

Все свойства методов доступа представлены в таблице pg_am (am — access method). Из этой таблицы можно получить и сам список доступных методов:

postgres=# select amname from pg_am;
 amname
--------
 btree
 hash
 gist
 gin
 spgist
 brin
(6 rows)

Хотя к методам доступа можно с полным правом отнести и последовательное сканирование, исторически сложилось так, что оно отсутствует в этом списке.

В версиях PostgreSQL 9.5 и более старых каждое свойство было представлено отдельным полем таблицы pg_am. Начиная с версии 9.6 свойства опрашиваются специальными функциями и разделены на несколько уровней:

• свойства метода доступа — pg_indexam_has_property,
• свойства конкретного индекса — pg_index_has_property,
• свойства отдельных столбцов индекса — pg_index_column_has_property.

Разделение на уровни метода доступа и индекса сделано с прицелом на будущее: в настоящее время все индексы, созданные на основе одного метода доступа, всегда будут иметь одинаковые свойства.

В прошлые разы мы рассмотрели механизм индексирования PostgreSQL, интерфейс методов доступа, и два метода: хеш-индекс и B-дерево. В этой части займемся индексами GiST.

GiST

GiST — сокращение от «generalized search tree». Это сбалансированное дерево поиска, точно так же, как и рассмотренный ранее b-tree.

В чем же разница? Индекс b-tree жестко привязан к семантике сравнения: поддержка операторов «больше», «меньше», «равно» — это все, на что он способен (зато способен очень хорошо!). Но в современных базах хранятся и такие типы данных, для которых эти операторы просто не имеют смысла: геоданные, текстовые документы, картинки…

Тут на помощь и приходит индексный метод GiST. Он позволяет задать принцип распределения данных произвольного типа по сбалансированному дереву, и метод использования этого представления для доступа по некоторому оператору. Например, в GiST-индекс можно «уложить» R-дерево для пространственных данных с поддержкой операторов взаимного расположения (находится слева, справа; содержит и т. п.), или RD-дерево для множеств с поддержкой операторов пересечения или вхождения.

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

Мы уже рассмотрели механизм индексирования PostgreSQL, интерфейс методов доступа и три метода: хеш-индекс, B-дерево и GiST. В этой части речь пойдет о SP-GiST.

SP-GiST

Вначале немного о названии. Слово «GiST» намекает на определенную схожесть с одноименным методом. Схожесть действительно есть: и тот, и другой — generalized search trees, обобщенные деревья поиска, предоставляющие каркас для построения разных методов доступа.

«SP» расшифровывается как space partitioning, разбиение пространства. В роли пространства часто выступает именно то, что мы и привыкли называть пространством — например, двумерная плоскость. Но, как мы увидим, имеется в виду любое пространство поиска, по сути произвольная область значений.

SP-GiST подходит для структур, в которых пространство рекурсивно разбивается на непересекающиеся области. В этот класс входят деревья квадрантов (quadtree), k-мерные деревья (k-D tree), префиксные деревья (trie).

Почему запрос выполняется так долго? Почему не используются индексы?
Наверное, все слышали об EXPLAIN в PostgreSQL. Но не так много тех, кто понимает, как его использовать. Сам длительное время не мог найти доступного для понимания учебника (плохо искал?).
Надеюсь, эта статья поможет желающим разобраться с этим замечательным инструментом.

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

Когда я делаю ошибку в коде, то обычно это приводит к появлению сообщения “segmentation fault”, зачастую сокращённого до “segfault”. И тут же мои коллеги и руководство приходят ко мне: «Ха! У нас тут для тебя есть segfault для исправления!» — «Ну да, виноват», — обычно отвечаю я. Но многие ли из вас знают, что на самом деле означает ошибка “segmentation fault”?

Чтобы ответить на этот вопрос, нам нужно вернуться в далёкие 1960-е. Я хочу объяснить, как работает компьютер, а точнее — как в современных компьютерах осуществляется доступ к памяти. Это поможет понять, откуда же берётся это странное сообщение об ошибке.

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

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

В данной статье будет рассмотрен пример установки и настройки VNC server и графической оболочки (GUI) на примере OC Debian 8 jessie.

Эффективная коммуникация в команде — как хорошие дороги в стране: без них только на трехколесных телегах за три месяца из Москвы в Питер, а не сильную экономику строить. И, если в команде нет удобных коммуникационных инструментов, работать такая команда будет трудно и неэффективно. У нас в ИТ тоже бывают сложности с коммуникациями. Когда тебе нужно кому-то написать, то не знаешь, куда податься: кто-то предпочитает почту, у кого-то есть Viber, у кого-то WhatsApp, у кого-то Facebook Messenger. Приходится тратить массу времени только на то, чтобы выяснить, как лучше всего связаться с человеком, не говоря уже об использовании зоопарка каналов. Более того, без налаженных коммуникаций вырастают накладные расходы при работе сотрудниками, работающими удалённо. И несколько месяцев назад я понял, что так продолжаться больше не может и пора прийти к единой модели.

Если вы изучаете веб совсем недавно, но уже успели увидеть различные красивые эффекты на сайте, по типу системы частиц или какие либо игры разработанные на canvas'e и вас это заинтриговало, но изучать что-то новое очень страшно, то я вам готов продемонстрировать, как за 50 строк js кода можно сделать что-то интересное на canvas'e.



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

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


Что нам нужно сделать?

Небольшая предыстория.

У меня есть хобби-проект трекер.ру
Алгоритм такой: пользователь вводит поисковый запрос, этот запрос «на лету» ищет торренты на сторонних трекерах (рутор, рутрекер, tfile и тд).
Для параллельного поиска идет одновременно несколько аякс запросов, которые должны обработаться асинхронно.
Однако, запросы выполнялись синхронно. Если какой-то трекер долго не отдавал ответ, то остальные запросы подвисали и ждали ответа от подвисшего трекера. Общее время выполнение запросов равнялось сумме всех запросов. Хотя, по моим планам общее время должно было равняться самому долгому запросу.
Долго ломал голову, почему так. Грешил на HTTP pipelining. Но, причина оказалась намного банальней. Все дело в сессиях. Дело в том, что сессии в php консистентны и php не даст обратиться другому процессу к уже занятой сессии.

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

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

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

Код проекта… В общем у меня осталось впечатление, что писал его недоученный студент… И это, немотря на то, что уже был сделан частичный рефакторинг другим программистом. Единственное, что радовало, то это то, что не использовался какой-либо фреймворк. Конечно, это вечно флеймовый вопрос: Иисус или Магомед? Быть или не Быть? Unix или Windows? Использовать или не Использовать? ИМХО, Моё мнение: фреймворки заточены под узкий круг типовых задач. Социальный проект — задача, как правило, не типовая… Но, в целом, мне проект показался интересным и я решил взяться за улучшение. На этом вступление можно закончить…

Наверно, про повышение производительности и тему highload не писал только ленивый WEB разработчик, знающий хоть что-то в этой области. Принципиально, что-то нового, в данной статье вы не найдёте. Основные идеи разработки highload проектов, были мною изложены в цикле статей HighLoad. Три кита.. Если вам интересно, как я увеличил производительность PHP проекта, используя NoSQL хранилище tarantool, то Добро пожаловать под кат.

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

Предистория

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

Исходный стек технологий:

— Docker
— Symfony 4
— nginx
— php-fpm
— postgresql
— elasticsearch
— rabbitmq
— jenkins

Железо:

— ноутбук под ОС Ubuntu 16.04
— продакшн сервер на хостинге KVM

Почему кроме технологического стека я перечислил ещё и стек железа?

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

Первый и наверно самый важный аспект при начале работы с докером — это операционная система вашего ноутбука. Проще всего работать с докером именно на linux системах. Если вы работаете на Windows или Mac то у вас 100 % будут некоторые сложности, но эти сложности не будут являться критическими и при желании «нагуглить» как это исправляется не составит никаких проблем.

Второй вопрос — это хостинг. Зачем нужен Hosting именно с типом виртуализации KVM? Причина в том, что виртуализация VPS разительно отличается от KVM и установить сам docker на VPS у вас попросту не выйдет, так как VPS распределяет ресурсы сервера динамически.

Подитог: для самого быстрого старта на докере резоннее всего выбирать Ubuntu в качестве локальной операционки и KVM хостинг (либо собственный сервер). Далее рассказ пойдёт опираясь именно на эти две составляющие.

Эванс написал хорошую книжку с хорошими идеями. Но этим идеям не хватает методологической основы. Опытным разработчикам и архитекторам на интуитивном уровне понятно, что надо быть как можно ближе к предметной области заказчика, что с заказчиком надо разговаривать. Но не понятно как оценить проект на соответствие Ubiquitous Language и реального языка заказчика? Как понять, что домен разделен на Bounded Context правильно? Как вообще определить используется DDD в проекте или нет?

Последний пункт особенно актуален. На одном из своих выступлений Грег Янг попросил поднять руки тех, кто практиукует DDD. А потом попросил опустить тех, кто создает классы с набором публичных геттеров и сеттеров, располагает логику в «сервисах» и «хелперах» и называет это DDD. По залу прошел смешок:)

Как же правильно структурировать бизнес-логику в DDD-стиле? Где хранить «поведение»: в сервисах, сущностях, extension-методах или везде по чуть-чуть? В статье я расскажу о том, как проектирую предметную область и какими правилами пользуюсь.

У Git есть строгие обязательства по обратной совместимости: многие продвинутые возможности скрыты за разнообразными опциями, а не применяются как поведение по умолчанию. К счастью, Git также поддерживает и алиасы, так что вы можете создавать свои собственные команды, которые делают всю характерную для Git магию. Под катом — подборка полезных (или как минимум забавных) алиасов, определённых в моём .gitconfig.