Привет! Меня зовут Владимир, я разработчик команды продукта «Сервис персонализации» в SM Lab. В этом посте я хотел бы рассказать (а в комментариях — обсудить) один очень важный и полезный инструмент разработчика — юнит-тесты.

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

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

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

При подготовке материала очень помогла книга Владимира Хорикова (@vkhorikov ) «Принципы юнит-тестирования». Рекомендую ее всем, кто хочет еще глубже погрузиться в эту тему.

Итак, поехали.

Любому Python-проекту может пойти на пользу надёжный и стабильный конвейер непрерывной интеграции (Continuous Integration, CI). В рамках таких конвейеров выполняется сборка приложений, запуск тестов, проверка кода линтерами, контроль качества программ, анализ уязвимости приложений. Правда, построение CI-конвейеров занимает много времени, требует выполнения действий, которые, сами по себе, никакой пользы не приносят. Этот материал написан для тех Python-программистов, которым нужен полнофункциональный, настраиваемый CI-конвейер, основанный на GitHub Actions. Этот конвейер оснащён всеми мыслимыми инструментами, подключён ко всем необходимым сервисам, а подготовить его к работе можно всего за несколько минут.

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

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

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

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

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

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

И тут на тебе! Оказывается в любой момент, по не зависимой от меня причине, меня могут отключить от этого технологического чуда! :-)

Меня зовут Стас Гаранжа, я выпускник курса «Python-разработчик» в Яндекс.Практикуме. Я хочу помочь начинающим разработчикам, которые приступили к изучению Django Rest Framework (DRF) и хотят разобраться, как устроен этот фреймворк.

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

В этой статье разберёмся, как сделать REST API на базе Django Rest Framework, чтобы получить по GET-запросу набор записей из базы данных (БД). Иными словами, рассмотрим, как DRF работает на чтение (о том, как с помощью него создавать, изменять и удалять записи в БД, поговорим в отдельной статье).

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

Статья является переводом поста "Introduction to Knowledge Modeling" с сайта makhfi.com сделанным с молчаливого согласия автора (запрос по-честному отправлен на почту Pejman Makhfi 30.11.2021).

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

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

Объем мирового рынка домашних интеллектуальных компьютерных устройств в 2020 году составил 801,5 млн штук

Но что такое интеллект? Концепция интеллекта основана на четырех фундаментальных принципах, которые включают: данные, информацию, знания и мудрость (также известные как интеллект).

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

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

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

Можно ли получить доступ к аккаунту умершего по закону

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

На сегодняшний день в России, как и в большинстве других стран, наследование цифровой собственности слабо регулируется. Существенный шаг в решении данного вопроса был сделан в США в 2014 году: там был принят акт, регулирующий наследование аккаунтов в соцсетях, блогов и сайтов человека, ушедшего из жизни. Благодаря этому акту, наследники покойного могут получить право собственности на цифровое имущество наследодателя.

Меня зовут Алексей Казаков, я техлид команды «Клиентские коммуникации» в Домклик. По моему опыту подавляющее большинство приложений, взаимодействующих с базой данных, использовали для этого Object Relational Mapper. В этой статье я продолжу знакомить вас с популярными ORM, которые встречались мне в продовых проектах. На очереди всемогущий SQLAlchemy.

Возможно, вы сталкивались с классической историей: поговорили с заказчиком о задаче, всем всё понятно. Начали работать — и началось: "А я думал, это и так ясно" или "Я ожидал, что ты это опишешь точнее". 

Начинается круговорот вопросов, переделок, а главное — неоправданных ожиданий и недовольств.

Как с этим бороться?

Конечно, когда мы решаемся сменить работу, мы исходим из своих личных побуждений и мотиваций; и очевидно, что увеличение своего материального положения — не последняя из причин. Но при ответе себе лично на вопрос «сколько я хочу получать» обычно оперируем своим собственным потреблением. Но случалось ли вам слышать именно на собеседовании такой вопрос: «А почему Вы хотите получать именно столько?» Мне случалось пару раз, и, признаюсь, в те разы терялся что ответить. Некоторые размышления меня натолкнули, что лучший ответ будет: «Столько предлагает рынок».

Async в моде. Async Python, Async Rust, Go, Node, .NET и т.д. Выбирайте свою любимую экосистему, и в ней будет свой модуль для асинхронности. Насколько хорошо работает вся эта асинхронная история, во многом зависит от экосистемы и среды выполнения языка, но в целом у нее есть несколько приятных преимуществ. Что действительно становится проще – это ожидание завершения операции, выполнение которой требует некоторого времени. Теперь это настолько просто, что количество способов выстрелить себе в ногу невероятно выросло. Тот способ, о котором я хочу сегодня поговорить – это тот, в котором вы не осознаете, что стреляете себе в ногу, пока система не начнет перегружаться. Да, я про управление давлением. Родственным термином в сетевых технологиях является «контроль потока». 

Прим. Wunder Fund: в этой длииинной статье вы найдете ряд полезных советов по работе с Docker, как общего характера, так и Python-специфичных. Хоть мы и давно используем Docker в работе, про некоторые советы мы подумали "а что, так можно было?". Советуем вначале пролистать статью, и отметить штуки, которые покажутся актуальными для вашей текущей ситуации.

Когда я предложил перевести на русский мою последнюю статью Easy Concurrency with Python Shared Objects на английском, поступило предложение "написать в несколько раз короче и понятнее". Просьба более чем обоснована. Поскольку я уже порядка десяти лет пишу многопоточку и БД, то описываемые мной логические связи выглядели самоочевидно, и я ошибочно расчитывал на аудиторию из трех с половиной человек, которые сидят сейчас где-то в яндексе или гугле. Судя по всему, они там и сидят, но тема им не интересна, поскольку в питоне нет настоящих потоков, а значит для этих людей такого языка программирования не существует. Потому я немножко снижаю планку и делаю общий обзор проблематики параллельных вычислений для людей, которые в них разбираются, но не являются экспертами в области.

Из-за чего весь сыр-бор?

Более пяти лет назад мы запустили платформу Slack, предоставив разработчикам легкий способ создавать приложения в Slack и публиковать их в нашей App Directory. Сегодня миллионы пользователей переносят свою работу в Slack, и их приложения, создаваемые более чем 885 000 активными разработчиками, действующими на этой платформе – залог дальнейшего улучшения совместной работы в Slack. 

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

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

Я не утверждаю, что Slack всегда проектировал API хорошо. У нас были ошибки, и платформа определенно могла бы быть удобнее для разработчиков. Но мы признаем эти ошибки и определяем, как их исправить – иногда даже дополнительно упирая на то, чтобы придерживаться какого-то выбора, сделанного в прошлом, тогда как сейчас мы бы с этим выбором не согласились — и в целом можем улучшить для разработчика опыт работы с платформой.

Всем привет!

В данной статье пройдемся по двум задачам, взятым с leetcode.com из списка часто встречаемых задач на собеседованиях в FAANG:

1. Guess the word
2. Number of Good Ways to Split a String

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