Летные испытания гиперзвукового самолета - это дорого и сложно. Но есть способы в разумных пределах упростить эту задачу, примером чему служит летный эксперимент HiFire-IV, выполненный в составе международной исследовательской программы HiFire

По материалам AIAA

В современном мире приложение — это огромная связка микросервисов. Функционально её протестировать сложнее, чем монолит. Кто-то решает это единым staging’ом и чатиком синхронизации: «займу auth на полчасика». Другой уходит с головой в shift-left или тестирует в canary. Разберём, как катнуть веточку сервиса и получить свой личный staging.

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

Хабр, привет! Сегодня хочу поделиться подборкой игр для детей и подростков, обучающих текстовому программированию. Научиться программировать можно самостоятельно, нужна только усидчивость и интерес к IT. 

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

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

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

Платформ на рынке значительно больше, как минимум 40, в наше сравнение попали следующие: WSO2 API Manager, Axway Amplify, Red Hat OpenShift API Management, Microsoft Azure API Management, Gravitee, Mulesoft Anypoint Platform, Tyk, Google Apigee API Management, IBM API Connect и Tibco Cloud API Management.

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

Всем привет! Меня зовут Сергей и я практикующий психолог.

Дисклеймер: В силу подхода к работе так сложилось, что обычно я консультирую людей интеллектуального труда. В последний год это преимущественно управленцы и сотрудники IT-сферы. Это люди, которые всю жизнь решали любые проблемы "через голову". Такой подход неизбежно накладывает отпечаток на личность и внепрофессиональную жизнь. Минимизацией негативных последствий таких особенностей я занимаюсь. И в рамках статей на данном ресурсе занимаюсь обобщением своего профессионального опыта и дать полезную информацию.

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

Как выглядит процесс принятия решений в ваших командах? Если вам нужно принять совместное, устраивающее всех, решение, то как вы достигаете консенсуса? С какими сложностями сталкиваетесь? Если у вас есть молчуны, то решение принимают самые громкие?

Меня зовут Александра Баптизманская, мы с Евгенией Чумачковой и Оксаной Сливинской работаем Agile-коучами, у нас есть небольшая компания Co-Actors. Сегодня мы научим вас, как при помощи довольно простых фасилитационных техник помочь принять решение группе — не единолично, не демократическим способом и не методом «Два лида договорились». Расскажем, как вовлечь всю группу и провести ее через этот процесс — от генерации идей через споры-обсуждения к выбору решения, которое устроит всех, и достичь консенсуса.

Расскажу о календарях YouGile, Битрикс-24, Weeek, ClickUp, Wrike, Asana, Trello. Давно анализирую системы управления проектами, делаю обзоры, сравниваю функции, подкидываю идеи по продукту разработчикам. Протестировала более 50 систем. 

Все календари проектов похожи. Задачи попадают туда с досок или из списков и to-do-листов, если проставлены даты. Есть цветная маркировка и фильтрация. Можно добавить задачу, изменить сроки перетаскиванием, завершить. 

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

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

Yandex Rate Limiter (далее просто YARL) — это сервис лимитирования нагрузки для распределённых сервисов. Его особенность в том, что он способен работать с миллионами квот, имея при этом очень низкие накладные расходы на проверку квоты. Если совсем кратко, это система распределённых Leaky Bucket'ов, с помощью которых можно ограничивать разные величины, связанные со временем: скорость передачи данных по сети, запросы в секунду и т. п.

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

Привет, меня зовут Евгений, я PHP-разработчик в Broniboy. Ища в очередной раз на Хабре нужную информацию, поймал себя на мысли, что здесь маловато статей, на пальцах объясняющих суть и особенности применения микрофронтендов. Поэтому хочу добавить в копилку знаний.

Очередная история успеха после череды неудач. Расскажу, чего мне стоило получить офферы от Facebook*, Google, Amazon, JP Morgan в Европе, как я готовился, сколько собесов зафейлил перед тем, как удача повернулась ко мне правильной стороной.

TL;DR. Послал сотни резюме. Прорешал около 100 задач на Leetcode. Прочел книжку по архитектуре (не той, которая про дома, а той, которая system design). Прошел 9 интервью. Получил 4 оффера. Принял 1. Жил, пока что, не очень долго, но, вполне себе, счастливо в Лондоне.

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

Я расскажу об обычных проблемах, с которыми люди сталкиваются при использовании API-схем. Как можно использовать API-схемы для описания property-based-тестов, и чем здесь может помочь Schemathesis. И покажу на практике, как его можно интегрировать в  существующий проект.

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

На прошедшей в апреле конференции TeamLead Conf 2021 я поделился своим опытом, как вытащить проект из пожара и обойтись без человеческих жертв. Под катом моя история, а если предпочитаете смотреть — вот запись выступления.

Все, так или иначе, используют Open Source. Но что делать, если нам нужна новая фича или мы нашли критический баг? Можно, конечно, форкнуть репозиторий и быстро что-то поправить. Но форк нужно поддерживать, а новая версия может оказаться несовместимой с вашей. Например, GitHub потратил полтора года, чтобы обновить фреймворк Ruby on Rails с версии 3.2 до версии 5.2.

Можно отправить pull request. Так вы решите не только свою проблему, но и поможете сообществу. Но у мейнтейнера есть свой Open Source проект и контрибьюторы ему обычно только мешают. Поэтому ваш pull request могут не принять. И первый, и второй, и  десятый.

Как же тогда работать с Open Source? Михаил Грачёв, тимлид из Evrone, расскажет,  как в компании выстроили работу с Open Source и превратили это в культуру. Для тех, кто предпочитает смотреть видео — запись его выступления на TeamLead Conf 2021.

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

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

Это дало мне сильнейший толчок и изменило мою жизнь до неузнаваемости. За прошедшие пять лет я попутешествовал по куче стран, полтора года прожил в солнечной Черногории, переехал в Израиль, несколько раз менял работу на компании с гораздо лучшими условиями, в последний раз устроившись на работу, на которой мой доход в более чем 15 раз превышает мой доход пять лет назад, и на которой я делаю продукты для всемирно известных корпораций и организаций, создал три более-менее успешных open-source проекта на Github и написал множество статей на Хабрахабр, некоторые из которых имели ошеломительный успех у читателей.

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

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

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

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

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

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

Давайте посмотрим на плюсы, которые предлагает E2E тестирование.