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

Чтобы понять, насколько революционным был их подход, давайте просто вспомним, что Heroku создала в 2007-2011 году. Я могу назвать как минимум 3 вещи - контейнеры, serverless и доставку кода через push в GIT. Во многом современный технологический ландшафт был вдохновлен решениями Heroku, увидевшими свет 15 лет назад.

В этой статье я хочу поговорить об истории компании и причинах утраты “былого величия” в наши дни. 

Начало истории Heroku

В 2007 году трое разработчиков Ruby — Джеймс Линденбаум, Адам Виггинс и Орион Генри — основали Heroku. Поначалу это был редактор кода в браузере. Проект вызывал “ВАУ эффект”, но не сильно вовлекал пользователей. С этим проектом основатели даже прошли Y Combinator. В ходе доработки платформы разработчики сделали, как им тогда казалось, второстепенную фичу - возможность разворачивать приложения из мастер ветки привязанного GitHub. Цель была простая - дать возможность разработчикам сразу понять, как работает их код. Почему фича казалась второстепенной? На тот момент GitHub только появился, и делать интеграцию с ним было далеко не очевидной идеей. 

Но однажды, анализируя то, как пользователи используют проект, основатели Heroku заметили, что многие клиенты используют только функцию развертывания приложений через push в GIT. И с этого момента началась новая страница развития сервиса.

Некоторые авторы уже 2–3 года как младше Хабра. 17 лет — большой срок для любого интернет-ресурса и прожить их в онлайне гораздо тяжелее, чем в оффлайне: ежемесячно появляются новые технологии, требования, законы, правила игры и им нужно соответствовать, если хочешь быть современным, актуальным и, что важно, своевременным. Хабр смог! Ежемесячно сюда заходят 12 млн. уникальных пользователей, которые находят что-то нужное, ценное, интересное: туториалы, ответы на вопросы, занимательное чтиво, свежие новости, активные дискуссии, возможность поделиться знаниями и опытом, да хоть новую работу. Чтобы всё это работало, команде Хабра иногда приходится работать 24/7.

Как любой герой, Хабр окружён мифами. Давайте сегодня поговорим про самые странные, прикольные и несправедливые (а что-то может и не миф вовсе)? А ещё под катом маленький конкурс!

У лукоморья дуб зеленый;
Златая цепь на дубе том:
И днем и ночью кот ученый
Все ходит по цепи кругом;
Идет направо – сайты кодит,
Налево – платы мастерит.

Там чудеса: там леший бродит,
…
(из поэмы А. С. Пушкина «Руслан и Людмила», две строки изменены автором этой статьи).

Привет! Меня зовут Катя Седова, я продуктовый дизайнер и иллюстратор в Тинькофф. Примерно 50% моей работы — создание картинок к клиентским письмам и дайджестам. Рассылки происходят постоянно, поэтому рисовать нужно много и быстро. 

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

Это вторая статья про 2Д рендеринг разнообразных эффектов в нашей игре. Предыдущую статью можно прочитать здесь. Напомню, что игра двухмерная и разрабатывается на движке Game Maker Studio 2.

Сегодня рассмотрим четыре стихии — воду, огонь, землю и воздух. Какие графические эффекты они скрывают в себе? Давайте узнаем.

Так исторически сложилось, что последние 5 лет своей продуктовой разработки я работаю с микросервисами вокруг брокеров сообщений (преимущественно RabbitMQ и Kafka).

И все это время меня не покидало чувство некой неудовлетворенности и неполноценности инструментария, который был мне доступен.

Приходя из мира HTTP фреймворков ты чувствуешь себя как будто на костылях - ни тебе hotreload'а, который есть практически в любом wsgi-asgi сервере, хочешь тестировать - поднимай контейнеры окружения или мокай зависимости (особенно удобно в CI, ага), не забудь о реконнектах, логировании, трассировке и тд и тп.

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

Так появился на свет фреймворк Propan.