Теперь не придётся краснеть перед работодателем или преподавателем из-за того, что вместо вас текст написал ИИ. Просто заставьте детекторы поверить, что автор — человек. В статье рассказали, как это сделать и в чём хитрость. 

Привет Хабр! Меня зовут Петр Уваров, я руководитель направления Bug Bounty в VK. Есть много статей, где багхантеры рассказывают о Bug Bounty и своем опыте в нем. Но в этой статье, я бы хотел проанализировать текущую ситуацию на российском рынке, сравнив ее с тем, что было раньше, и поговорить про ситуацию с багхантерами. Некоторые вещи, которые я буду говорить прозвучат как цитаты Капитана Очевидность. Другие могут быть приписаны Генералу Ясенпеню, но тем не менее, про них стоит рассказать.

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

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

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

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

Полтора года в нашей компании длился эксперимент, в котором участвовали 150 сотрудников. Он показал, что при разнице уровней оклада в 10-14% по сравнению с рынком разумеется не в нашу сторону специалисты от среднего до высокого уровня готовы продолжать работу при условии наличия программы заботы об их здоровье.
Иными словами, если вы не можете или не хотите платить своим сотрудникам столько, сколько платит рынок, и это "нежелание" не превышает 14%, то вы можете выдавать витамин D, что сокращает выгорание, и как следствие — текучесть кадров.

Многие считают, что DDoS-атаки могут являться форс-мажором. Учитывая это мнение, нерадивые компании IT-сферы готовы оправдывать ими свои огрехи и недоработки, иногда даже включая упоминание о них в пункты своих договоров. И правда, очень удобно в случае любого ЧП сказать своему недовольному клиенту: «Извини, дорогой, DDoS-атаки все сломали, мы здесь ни причем». В этой статье мы расскажем почему DDoS-атака не может считаться форс-мажорным обстоятельством и на конкретном кейсе разберем как его применяют хостинг-провайдеры, включая пункты о нем в свои договоры.

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

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

Я составил список своих задач и разбил их на категории. Кстати говоря, добрую половину этих задач я повесил на себя сам.

Первая статья на Хабре, будь она от компании или пользователя, — фактически визитная карточка, которая либо даст хороший старт и мотивирует писать больше и интереснее, либо отобьёт руки. Опыт показывает, что авторы в своих первых публикациях совершают одни и те же ошибки, которые смазывают впечатление и сказываются на отношении аудитории. Известно, что лучше предотвратить ошибку, чем исправлять её после совершения, поэтому решено: в этой статье разберём все типичные ошибки и будем давать на неё ссылку новичкам.

1. В монолите концентрировалось большое количество бизнес-процессов, которые охватывали сразу несколько потребителей: пользователей облачной платформы, сейлз-менеджеров (через CRM-систему), администраторов, обработчиков метрик. Получилась такая одна большая точка отказа сразу для 4 групп бизнес-процессов.
2. Каждый бизнес-процесс потребляет свой объем ресурсов. Например, для обработки метрик нужно 5 подов (чтобы запараллелить и ускорить обработку), для администрирования хватит и одного. Так как у нас все в одном сервисе, при масштабировании монолита мы будем ориентироваться на самый «прожорливый» бизнес-процесс. Часть ресурсов будет просто простаивать.
3. Хотелось добиться гранулярности, чтобы независимо писать и деплоить код для каждого бизнес-процесса. И не переживать, что какие-то изменения в одном бизнес-процессе неожиданно отрикошетят в соседний.

Я занимаю должность СТО уже около десяти лет.

К настоящему времени у меня сложилась довольно четкое понимание того, кто такой 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, рассказать о нюансах и тд...