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

Я решил посвятить свою первую статью SQL. Вопросы, рассмотренные ниже мне задавали на собеседованиях на позицию python-разработчика. Естественно отвечать правильно получалось не всегда, а если точнее то чаще не правильно, однако проведя N часов в рефлексии я составил перечень ответов, которыми пользуюсь до сих пор.

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

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

Самое первое и главное заблуждение — "нужен поиск, так бери эластик!". Но в действительности, если вам нужен шустрый поиск для небольшого или даже вполне себе крупного проекта, вам стоит разобраться в теме поподробней и вы откажетесь от использования именно этой системы.

Я очень люблю тесты и считаю, что любой код должен быть покрыт ими, желательно качественными :)  
Поэтому хочу поделиться с вами опытом внедрения мутационных тестов в проект, рассказать зачем оно нужно и какую ценность несет. Рассмотрим пример внедрения Infection в приложение на Laravel. Но сначала немного теории.

Всем привет! Меня зовут Илья Денисов, я занимаюсь backend разработкой уже более пяти лет и сейчас пишу на языке go. Сегодня я предлагаю вам поговорить о кэшировании. Постараюсь рассказать о базовых концепциях, а также затронуть ряд особенностей, неочевидных на первый взгляд.

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

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

1. Богатая (насыщенная) модель — данные и поведение инкапсулируются внутри объектов предметной области.
2. Анемичная модель — в объектах предметной области инкапсулируются только данные, поведение (методы) выносится в отдельный слой сервисов.

В прошлых двух статьях мы рассказывали об IIoT — индустриальном интернете вещей — строили архитектуру, чтобы принимать данные от сенсоров, паяли сами сенсоры. Краеугольным камнем архитектур IIoT да и вообще любых архитектур работающих с BigData является потоковая обработка данных. В ее основе лежит концепция передачи сообщений и очередей. Стандартом работы с рассылкой сообщений сейчас стала Apache Kafka. Однако, для того, чтобы разобраться в ее преимуществах (и понять ее недостатки) было бы хорошо разобраться в основах работы систем очередей в целом, механизмах их работы, шаблонах использования и основной функциональности.

Мы нашли отличную серию статей, которая сравнивает функциональность Apache Kafka и другого (незаслуженно игнорируемого) гиганта среди систем очередей — RabbitMQ. Эту серию статей мы перевели, снабдили своими комментариями и дополнили. Хотя серия и написана в декабре 2017 года, мир систем обмена сообщениями (и особенно Apache Kafka) меняется так быстро, что уже к лету 2018-го года некоторые вещи изменились.

Микросервисы сейчас — это новый черный. Все больше и больше компаний переходят именно на микросервисную архитектуру. И при переходе ловят самые разные ошибки. Самая популярная происходит из-за того, что люди просто не готовы к тому, что их приложения начинают активно использовать сеть. Потому что IPC и RPC-запросы  — это абсолютно разные вещи.

Я техлид в команде Авито в проекте SLA. Сегодня расскажу, как мы оптимизировали сетевые вызовы, чтобы избежать проблем с сетью при переходе в микросервисный мир. Разговор будет про оптимизацию CURL-запросов, деградацию сервисов и FAIL-FAST-подходы.

В одной конторе соискателю на позицию Senior C# developer выдали тестовое задание: отсортировать файл со строками определенного формата.

Требования такие:

* Формат строки: число, точка, пробел, далее любые символы до конца строки.

* Порядок сортировки — сначала сортируем текстовой части строки, потом по числу если текстовые части совпадают.

* Кодировка — UTF-8.

* Размер файла — 100гб - гарантированно больше объема ОП.

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

Как и многие другие программисты, узнав о таком тестовом задании, я возмутился. Внешнюю сортировку слиянием практически всех проходили в ВУЗе, но практически никто никогда не писал её. Задача очень непрактическая и непонятно какие навыки проверяет. Так мне казалось.

Эта задача вызвала бурные обсуждения о способах её решения. Многие программисты, причисляющие себя к рангу senior, предложили использовать базы данных, ибо не барское это дело - вручную писать алгоритмы сортировки. Некоторые даже попытались сделать решение на Apache Spark. Однако никто до конца задачу не решил, ибо мало кому удалось отсортировать в нужном порядке даже 10ГБ файл менее чем за 15 минут без SSD.

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

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

А у вас накопились долги?

Всем привет! Меня зовут Дмитрий Шкилёв, я тимлид команды Teachers Platform. Мы занимаемся личным кабинетом преподавателя и внутренними ресурсами, которые необходимы для обеспечения работы преподавателей. 

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

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

Всем привет! Меня зовут Константин, и я работаю ведущим тестировщиком в дружной команде back-end компании Solit. Мои коллеги уже не раз делились различными хитростями и ноу-хау, которые они применяют в своих проектах. Я же решил пойти немного другим путём и поделиться с вами набором сервисов и утилит, которые помогают нам прийти к недостижимой цели — работа приложений без дефектов.

 В мою подборку попали те приложения, которые прижились в нашей команде и ими пользуется более одного человека. Конечно, есть очевидные вещи, типа Notepad++. Но есть и более редкие «звери», типа JWT.

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

Приложения для генерации данных

Правильная подготовка тестовых данных — уже половина успешного тестирования. В этом разделе я собрал приложения, которые помогают быстро сгенерировать большие (я бы даже сказал, очень БОЛЬШИЕ) объёмы тестовых данных.

pgCodeKeeper

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

 В нашем случае она прижилась именно как генератор тестовых данных для БД Postgres. Подробнее о том, как он работает, можно прочитать в официальной справке pgCodeKeeper.

Ещё одна статья на избитую тему? Да! Потому что за два часа поиска не нашёл ни одной, по которой можно было пройтись от и до и получить работающее окружение.

Шагов, на самом деле, немного, все очень простые, нужно лишь...

Какие качества отличают хорошего технического лида? Уверены, как минимум инициативность, стратегическое видение, интерес к новым практикам и инструментам, идущие рука об руку с желанием постоянно развиваться. Немалую роль в lifelong learning техлида могут сыграть правильно подобранные книги.

Немет, Луц, Лав, Танненбаум, Страуструп, Олифер, Лукас — вот лишь некоторые известные авторы, о которых мы сегодня не будем говорить. Надеемся, что раз вы стали лидером технической команды, то с фундаментальной литературой в своей области знаний знакомы не понаслышке.

Под катом рекомендуем 7 изданий о soft-skills, методологиях, управлении командами и проектами.

Дочитав эту статью до конца, вы сможете решать точно задачу коммивояжёра на сотню элементов за считанные секунды!

Заинтригованы? Тогда, добро пожаловать под кат.

Существует множество разных подходов к построению архитектуры серверных приложений. В данной статье рассмотрим Event-driven архитектуру (она же событийно-ориентированная). Рассмотрим основные принципы, как перейти от связей Компонент А <-> Компонент В, к связям через события Компонент А -> Событие А -> Компонент Б и зачем это нужно?

Я недавно начала заниматься администрированием проектов в ИТ-инфраструктуре. Здесь много постов менеджеров проектов о том, как ставить задачи технической команде, контролировать статусы и общаться так, чтобы тебя не ненавидели. Однако оказалось, что с инженерами универсальные способы часто не работают, или работают, но не со всеми.

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