Пользователь
В жизни любого разработчика наступает момент, когда он роняет прод. Представьте: полдень, в Skyeng час пик, тысячи запланированных онлайн-уроков, а наша платформа лежит…
Все упало из-за ошибки в процессе деплоя, которая связана с тонкостью PostgreSQL. К сожалению, на этом моменте у нас прокололась не одна команда. И чтобы такое больше не произошло ни у нас, ни в другой компании — велкам под кат.
Привет, Хабр! Технический долг есть в любом крупном проекте. Он возникает, когда копятся компромиссные решения, проблемы в коде или архитектуре. Важно, что эти решения и проблемы усложняют и удорожают поддержку и обновление кода в будущем. Это своеобразные «проценты». Чем больше долг, тем больше «процентов» приходится платить.
В статье поделимся опытом работы с техдолгом. Сначала определим, что это, затем подумаем, как решать. Пишите в комментариях свой опыт — подискутируем.
Полтора года в нашей компании длился эксперимент, в котором участвовали 150 сотрудников. Он показал, что при разнице уровней оклада в 10-14% по сравнению с рынком разумеется не в нашу сторону специалисты от среднего до высокого уровня готовы продолжать работу при условии наличия программы заботы об их здоровье.
Иными словами, если вы не можете или не хотите платить своим сотрудникам столько, сколько платит рынок, и это "нежелание" не превышает 14%, то вы можете выдавать витамин D, что сокращает выгорание, и как следствие — текучесть кадров.
Многие считают, что DDoS-атаки могут являться форс-мажором. Учитывая это мнение, нерадивые компании IT-сферы готовы оправдывать ими свои огрехи и недоработки, иногда даже включая упоминание о них в пункты своих договоров. И правда, очень удобно в случае любого ЧП сказать своему недовольному клиенту: «Извини, дорогой, DDoS-атаки все сломали, мы здесь ни причем». В этой статье мы расскажем почему DDoS-атака не может считаться форс-мажорным обстоятельством и на конкретном кейсе разберем как его применяют хостинг-провайдеры, включая пункты о нем в свои договоры.
Моя предыдущая статья вызвала довольно бурное обсуждение на тему, кто такой тимлид и чем он занимается, поэтому в этой статье я хотел рассказать о том, чем занимаюсь я.
Вообще задачи тимлида могут сильно отличаться в разных компаниях. В моем опыте обычно было так: чем меньше в команде представлено ролей, тем больше задач будет у тимлида. Я как-то работал с тимлидом, которому приходилось даже тестировать, потому что в команде не было тестировщика.
Я составил список своих задач и разбил их на категории. Кстати говоря, добрую половину этих задач я повесил на себя сам.
Первая статья на Хабре, будь она от компании или пользователя, — фактически визитная карточка, которая либо даст хороший старт и мотивирует писать больше и интереснее, либо отобьёт руки. Опыт показывает, что авторы в своих первых публикациях совершают одни и те же ошибки, которые смазывают впечатление и сказываются на отношении аудитории. Известно, что лучше предотвратить ошибку, чем исправлять её после совершения, поэтому решено: в этой статье разберём все типичные ошибки и будем давать на неё ссылку новичкам.
Я занимаю должность СТО уже около десяти лет.
К настоящему времени у меня сложилась довольно четкое понимание того, кто такой CTO, что делает CTO успешным, а что - нет.
Однако, даже сейчас я замечаю, что эта роль является одной из самых неправильно понимаемых в сфере технологий.
Через любую высоконагруженную систему ежесекундно проходит огромный поток трафика. Релизы, хотфиксы, ddos-атаки, невалидные и ухудшающие эксперименты и многие другие события могут привести к проблемам, которые влияют на пользователей. Поэтому такие ситуации не терпят задержек.
Можно провести простую аналогию: если вы чем-то заболели, то лучше узнать об этом как можно раньше и тем самым минимизировать побочные эффекты после и в процессе выздоровления. Так и в сервисе: будь то баннерная крутилка, поиск, маркетплейс или онлайн-доставка пиццы.
Меня зовут Владимир Точилин, я работаю в группе развития рекламных продуктов и стабильности. Вместе со своим коллегой, Александром Самусенко, я расскажу, как мы создали новый инструмент realtime-детекции разладок в проде рекламных технологий. Мы работаем с системой, где на отдельные кластеры нагрузка превышает 1000000 RPS.
Историю будет интересно прочитать аналитикам, разработчикам и менеджерам любого уровня.
Может ли kubernetes сделать жизнь админов небольших и средних компаний проще или же это шайтан-машина для кровавого enterprise и оголтелых стартапов?
Вот уже пару лет, как я рекомендую всем моим знакомым использовать Firefox, как браузер для повседневного серфинга в интернете. Я люблю этот браузер за его гибкость в настройке, скорость и заботу о приватности. Много раз на форумах меня спрашивали про какие-то отдельные случаи по настройке, поэтому я решил написать статью с подробным описанием настроек, как шпаргалку для себя и чтобы делится ею, в случае новых вопросов.
Надеюсь она немножко поможет в популяризации этого чудесного браузера.
Всем привет, меня зовут Ростислав, я занимаю должность Front Lead в компании ДомКлик. Хочу поделиться с вами опытом создания Web Core команды и сразу ответить на следующие вопросы:
После года существования команды Web Core, у всех сложилось понимание, что в больших компаниях это необходимо, а в стартапах — не обязательно.
Безусловно. Изначально было сложно измерить и спрогнозировать выгоду от её создания, все расчеты, P&L были на словах, в цифрах — только примерные предположения. Спустя год мы можем посчитать сэкономленное время, профиты, и все расчеты говорят о том, что это было не зря.
Если у вас одна цель — создать дизайн систему и выпустить библиотеку компонентов под ключ, то возможно. Если же вы хотите это всё динамически развивать и расширять зоны ответственности команды, то это точно надолго.
Основное направление — дизайн система, но по ходу её разработки у нас появилось еще много интересных задач.
Eloquent ORM кажется простой, но под капотом существует много полускрытых функций и менее известных способов. В этой статье я покажу вам несколько трюков.
Привет, Хабр! Вот уже почти 5 из 10 лет я совмещаю работу сетевиком с любимым хобби — подкастом про IT. За это время наш сервер для аудиотрансляций развивался, менялся и оказался полезен не только нам, но и коллегам. Недавно я правильно клонировал нашу сборку на базе Linux для радио ЦОД.fm в DataLine и решил поделиться своими наработками со всем сообществом.
Сегодня покажу, из чего я собирал новогоднее радио для затравки к онлайн-корпоративу и создания праздничного настроения у коллег перед новым годом.
Есть такой продвинутый инструмент Scrutinizer CI.
Для OpenSource он абсолютно бесплатный и платный для приватных репозиториев.
Вы о нем слышали, наверное, а если нет, то лично я использую его для анализа кода на различного рода уязвимости, а также в качестве замены статическому анализатору типа Psalm, ну и для покрытия конечно же, т.к. при довольно простой сквозной интеграции с GitHub оно внедряется в ваши PR и можно ревьюить код, наблюдая покрытие по аналогии с Cubertura в GitLab.
Это удобно, но к моему великому удивлению, на хабре, как и в целом на просторах интернета, довольно мало информации о том, как быстро и просто подключить этот крутой инструмент к вашему репозиторию в GitHub, ну а если вы еще и английского не знаете, то картина еще более грустная.
Поэтому я решил поделиться с вами своим опытом интеграции со Scrutinizer CI, рассказать о нюансах и тд...
Привет!
Саша Инкин и я регулярно пишем на Хабр статьи по Angular. Почти все они основаны на нашем опыте разработки большой библиотеки компонентов.
Эту библиотеку мы развиваем, перерабатываем и дополняем уже несколько лет, а свои идеи проверяем на нескольких десятках проектов Тинькофф Бизнеса и внутренних систем компании. Мы рады сообщить: выложили нашу библиотеку в открытый доступ!
В этой статье хочу описать основные концепции и практики, на которых строится библиотека, а также рассказать, почему ее стоит внедрить как в новые проекты, так и в уже готовые — с иными компонентами или UI Kit’ами.
Громкий заголовок статьи, конечно, не означает, что в ней будут прямо даны способы это сделать. Пардон, если дал ложные надежды. Эта статья - один из первых шагов к пониманию сути времени и вариантам управления им (конечно, имеется в виду не тайм-менеджмент) с уклоном на практическую реализацию. Множество людей хотели бы вернуться на некоторое время в прошлое и исправить свои ошибки или даже спасти близкого человека от смерти. К сожалению, наука пока не предлагает нам готовых вариантов для этого, а все теории для перемещения в прошлое основаны на фантастических малореальных кротовых норах, чёрных дырах и сверхсветовом движении, на которых реальную "машину времени" не построишь, нужны более приземлённые варианты.