Всем привет, это adlook!

Вы хотите зарабатывать на сайтах и стать крутым пабом? У вас есть сын маминой подруги, который может помочь быстро наклепать сайт на коленке? Отличный вариант, если ваши планы — отсутствие профита и постоянные 404-ошибки. 

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

Как подготовиться к созданию seo-сайта?

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

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

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

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

Привет, Хабр! Я Смолин Максим, разработчик и администратор баз данных в продуктах RPA BluePrism и SaluteRPA в Блоке Технологий Сбербанка, руководитель ИТ-направления. Мы с командой развиваем продукт SaluteRPA — роботизированная автоматизация процессов Сбербанка. Я расскажу, почему нас не устраивала платформа от зарубежного вендора, и почему мы решились на создание собственной платформы роботизации.

В 2017 году в банке начали использовать систему RPA BluePrism. На этапе MVP всё было великолепно, но потом началось много вопросов. ЦПУ (центральное процессорное устройство) сервера БД зашкаливали за 95 %, процессы тормозили и не успевали отрабатывать в нужное время, инциденты сыпались как из рога изобилия. С этого момента началась наша работа по превращению софта, рассчитанного на малый бизнес, в софт уровня предприятия с тысячами роботов. В итоге она привела к написанию собственного продукта SaluteRPA.

Архитектура RPA BluePrism достаточно проработана. Но вот реализация на уровне БД имела много замечаний с нашей стороны. Что-то мы отправляли на переделку вендору, что-то дорабатывали сами, а что-то смогли реализовать только в своём продукте.

Забегая вперёд, скажу, что внедренные нами изменения позволили преодолеть ограничение RPA BluePrism в 100 роботов на одну БД и уверенно держать нагрузку до 500 роботов на одну БД.

Эта статья строится на двух простых идеях:

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

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

Руслан Гнатовский aka @Number55 в свой статье Когда ни туда, ни сюда, или в поисках оптимальной границы Domain слоя описал известную проблему протекания бизнес-логики из агрегата, в случае если эта логика зависит от данных которые находятся вне агрегата, и предложил несколько решений этой проблемы, каждое из которых не лишено недостатков. Многие из этих недостатков были описаны в статье а также в комментариях поэтому я не буду здесь дублировать эту информацию а попытаюсь предложить решение которое этих недостатков лишено.

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

Можно долго искать решения, читать различные комментарии и книги про разделение бизнес-логики от приложения. И все равно ваша конкретная ситуация будет казаться вам уникальной, как будто ничего нельзя сделать либо надо снова переписывать Domain слой, дабы ни одно зернышко бизнес-логики не выпало за его пределы. А можно просто закрыть глаза на некоторые моменты, забыть об идеале и спать спокойно, рассчитывая, что все чудесным образом само разрулится.

Продолжаем делиться конспектами Алексея Барабанова, IT-директора «Хлебницы». На этот раз обсудим специфику работы RabbitMQ с высокими нагрузками (High Load) и обеспечением высокой доступности (High Availability). Рассмотрим различные методы увеличения производительности и горизонтального масштабирования, разберём и настроим внутренние инструменты. Также по мере погружения постараемся изучить основные подводные камни всех подходов.

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

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

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

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

DDD не на коленке, а за дорого ;)

В своём прошлом посте я рассказал теорию своего подхода к декомпозиции систем на модули. Теперь пришло время проверить её на практике.

Кэмп - реальный проект, который стоил семизначную сумму для заказчика, выполнялся командой из 12 человек (включая двух бакэндеров) и сейчас запущен в промышленную эксплуатацию. Суммарно на выполнение проекта было затрачено 5500 человеко/часов, из которых 950 - на бакенд.

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

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

Привет! Меня зовут Ваня, последние несколько лет я занимаюсь backend-разработкой в Сравни. Моя команда разрабатывает интеграции с сервисами наших партнёров, код пишем на PHP и Symfony Framework.

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

В этой статье я расскажу о том, как в Messenger-компоненте Symfony устроен механизм повторной обработки сообщений при ошибках (или по-простому – механизм ретраев), а также поделюсь опытом его использования и некоторыми важными нюансами его работы.

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

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

Redis и Memcached – два из самых популярных и мощных инструментов для реализации кэширования. Redis, изначально разработанный как in-memory хранилище данных, позволяет эффективно хранить и быстро извлекать информацию в памяти, что делает его идеальным выбором для кэширования. Memcached, с другой стороны, специализируется исключительно на кэшировании данных и предоставляет простой, но мощный способ ускорить доступ к данным.

Вопрос подготовки релизов и внесения новых изменений стоит перед любыми командами. Но чем масштабнее сфера применения каждого конкретного решения, тем важнее не допустить downtime, связанного с ошибками в новом функционале. В этом посте я расскажу о том, почему нам в Леруа Мерлен потребовалось развивать новый механизм работы с обновлениями, из-за чего не подошел ни один из популярных инструментов и что мы стали делать в итоге. Также мы обсудим различные подходы к организации функций Feature Toggle. Если вы тоже интересуетесь этой темой, приглашаю под кат!

В мае 2018 года Европа переключится на обновлённые правила обработки персональных данных, установленные Общим регламентом по защите данных (Регламент ЕС 2016/679 от 27 апреля 2016 г. или GDPR — General Data Protection Regulation). Данный регламент, имеющий прямое действие во всех 28 странах ЕС, заменит рамочную Директиву о защите персональных данных 95/46/ЕС от 24 октября 1995 года. Важным нюансом GDPR является экстерриториальный принцип действия новых европейских правил обработки персональных данных, поэтому российским компаниям следует внимательно отнестись к ним, если услуги ориентированы на европейский или международный рынок.

Новый регламент предоставляет резидентам ЕС инструменты для полного контроля над своими персональными данными. С мая 2018 года ужесточается ответственность за нарушение правил обработки персональных данных: по GDPR штрафы достигают 20 миллионов евро (около 1,5 млрд руб.) или 4% годового глобального дохода компании. В настоящей статье мы проанализировали новые правила обработки персональных данных в ЕС и сформулировали рекомендации для российских компаний по методам реагирования на GDPR.