Но даже самый удобный редактор не решает другую важную проблему — как придумать хорошую идею для поста?

Чтобы сделать жизнь авторов чуть проще, мы собрали навигатор тем. В нём нет готовых идей. Зато есть вопросы, которые помогают выбрать направление. Просто отвечайте на них и смотрите на примеры постов от других авторов. А когда придумаете тему, переходите в редактор и начинайте писать.

Что такое #багфиксарь? Наше название января. Мы выпустили календарь на 2021, где каждый месяц получил программистское название. Не забудьте скачать электронную версию, она уже ждёт вас в личном кабинете. Кстати, с календарём и связана первая новость.

Календарь

Теперь мы каждый месяц оформляем сообщества в соцсетях в соответствии с названием месяца. #багфиксарь уже закончился, на очереди — #авраль! Кроме размещения обложек планируем проводить активности и конкурсы.

Итоги конкурса в боте

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

Каналы

Ещё наши новые каналы в телеге активно растут. Канал по пайтону уже пробил 10 000 подписчиков, по основам программирования — 9 000, а по мобильной разработке — 5 000.

Мемы и развлечения

В этом месяце починили работу мемов. Теперь они отправляются стабильнее и автоматически дополняются по ходу появления новых постов в нашем VK-паблике /dev/null и Телеграм-канале IT Юмор — раньше такого не было. А ещё появилась рассылка лучшего мема дня.

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

В меню игр вернули «Баговый ним», теперь у нас 3 игры: это Быки и коровы, Баговый ним и (пока еще доступный для прохождения и уже упоминавшийся выше) квест Сапёр.

Оптимизация сайта

Интересный результат дала работа над оптимизацией сайта. Хоть Google и считает все наши страницы «быстрыми», но в выдаче занижает. Скорее всего, это из-за проблем с метрикой FCP.

First Contentful Paint (или FCP) — это метрика, показывающая время, когда пользователь видит отрисовку на странице чего-то полезного. Это может быть что угодно: текст, иконки, канва. Если FCP занимает много времени, то проблемы могут быть связаны как с соединением, так и с тяжестью контента. И похоже, что проблемы эти у нас на Safari в iOS.

Из рубрики факапов

А ещё у нас есть излюбленная рубрика «Истории факапов». И уже не впервые проблемы вызывает резервное копирование. На этот раз бэкапы скушали всё место на диске машинки сокращателя.

Внимательные читатели могли заметить, что для красоты (и не только) внешние ссылки мы сокращаем через домен tprg.ru. И машинка с этим сокращателем (не надо так делать) работает на том же диске, на который сохраняются бэкапы. Разумеется, мы удаляли старые бэкапы, а на диске хранились только 100 последних. Когда сокращённых ссылок было мало, последние бэкапы занимали не так много места. Но чем больше ссылок, тем больше вес последнего бэкапа.

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

Дизайн ивентов

Обновили дизайн мероприятий (раздел События и курсы). Теперь внешний вид страницы ивента такой же, как у страниц с вакансиями.

Также рады представить вам новый поиск с популярными темами для удобства:

Дайджест IT-событий за #авраль

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

Мастер вакансий

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

Раньше форма заполнения данных для размещения вакансии лежала на отдельном лендинге и представляла собой форму с Tilda, а теперь идёт переход сразу на наш сайт, и мы можем его контролировать. Любой желающий разместить вакансию может попасть на него по двум первым кнопкам «Разместить».

Следующим шагом хотим сделать автоматическую публикацию вакансий без модерации.

Поделитесь в комментариях, чего вы ожидаете от нашего раздела вакансий?

Что ещё у нас произошло за этот год?

Поставили цель и идём к ней

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

Но на этом дело не кончилось: зная цель, мы продумали шаги, которые приведут нас к ней. Помогла нам в этом система OKR — Objectives and Key Results. Мы стали работать как более зрелая и осознанная команда — напрямую этого не видно, но это влияет вообще на всё, что мы делаем. А если хотите почитать подробности — пишите об этом в комментах.

Расширили команду

Мы поставили цели и поняли, что их невозможно выполнить той небольшой командой, которая была в начале года. Вы могли видеть наши вакансии: мы активно расширялись. Сейчас нас около 30 человек.

Результаты налицо: редакция возродила новостное направление, количество материалов на сайте выросло в несколько раз и появилось 3 новых канала в Telegram: Точка входа в программирование, Мобильная разработка и Zen of Python. Разработка ускорилась, мы смогли улучшить сайт и сделать качественные спецпроекты — об этом ниже.

Начали делиться новостями проекта

Мы считаем, что важно делиться своими успехами и неудачами — и внутри команды, и с сообществом. Поэтому в этом году мы запустили внутренние новости проекта, которые выходят каждую неделю, и Tproger Changelog, который выходит раз в месяц. Для нас важно быть более открытыми и честными — и мы планируем работать над этим в 2021 году.

Ещё мы начали активнее общаться с читателями, чтобы лучше понимать реакции на свой продукт и наконец построить сообщество.

Создали свой трекер событий

Чтобы принимать решения, нужно их чем-то обосновывать, а для этого нужны данные. Данные стараются собирать все, но вот делиться ими мало кто хочет, и даже Google Аналитика и Яндекс.Метрика, которые у нас подключены, не всегда дают адекватное понимание происходящего.

В этом году мы с нуля разработали и внедрили трекер событий и рассказали об этом опыте.

Кроме того, мы допилили сервис, в котором для каждой опубликованной на нашем сайте статьи автоматически собирается статистика по связанным постам в соцсетях и каналах. Эта штука для внутреннего пользования, но если вам интересно, как она реализована, — пишите в комментах, постараемся рассказать.

Работали над сайтом снаружи и внутри

Чтобы сайтом было приятно пользоваться и его любили поисковики, нужны определённые технические показатели. Мы писали об этом в статьях «SEO для программиста» и «Почему у вас проблемы от высокого CLS и как их исправить».

Мы плотно работали над техническими показателями сайта, благодаря чему Google считает наш сайт быстрым. Конечно, проблемы встречаются до сих пор — поэтому, если вы обнаружили баг, сообщите, пожалуйста. Это можно сделать в Личном кабинете -> Сообщить об ошибке.

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

Мы протестировали две механики — систему геймификации и платные подписки. Про запуск подписок писали в июньском ченжлоге (спойлер: они не сработали).

Кроме того, у нас появился UX-дизайнер, благодаря которому мы потихоньку делаем сайт красивее и удобнее.

А ещё мы выпилили jQuery — потому что с ним было медленно и неудобно.

Сделали крутые спецпроекты

Тема на стыке контента, разработки и маркетинга: у нас наконец дошли руки до интерактивного контента, которые вносит разнообразие в привычные материалы. За этот год мы сделали:

• тест-квест,
• тест в виде капчи,
• текстовую трансляцию,
• игру в боте.

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

Прокачали бота

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

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

С Новым годом!

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

В ночь с четверга на пятницу, 2 октября, у нас падал сайт. Примерно с трёх ночи до десяти утра многие страницы не открывались вообще.

Причина оказалась простой: мы с Никитой тестировали новые рассылки в боте. Для этого нужно подключаться к продакшен базе и получать свежие посты. Бот не закрывал MySQL-соединение, и мы быстро достигли лимита в 255 открытых дескрипторов (ограничение managed MySQL от DO). Я закрыл подключение для бота, и минут через 15 база данных разрешила к себе подключаться.

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

Вот такая вот история восстания сайта из своей могилы.

По рабочей необходимости мне потребовалось открыть порт для доступа к Docker API на одной из наших виртуальных машинок, развернутых в Digital Ocean. Открыл порт, воспользовался по назначению, а затем заметил, что ресурсы машины закончились. Нечто забило всю память, а потребление CPU выросло до 100%:

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

А ещё на сервере иногда запускался подозрительный контейнер с ubuntu. Я тоже подумал на себя и просто удалял его. А он опять появлялся. Ну а я опять удалял. А потом я пошёл спать.

На следующий день от Digital Ocean пришло письмо: мол, ребят, у вас на сервере запущено что-то, что сканирует порты других хостов. Если это не вы, сделайте что-нибудь.

И тут у меня сошлась картинка: открыл порт, на машинке появился незваный гость. А дело всё в том, что на машинках Digital Ocean по умолчанию нет никакого фаерволла: как только открываешь любой порт, он становится доступен всем в интернете. Это спорное решение, но упрощает задачу новичкам и злоумышленникам. Вот мне в открытый порт Docker и заслали какую-то ubuntu.

Я быстренько закрыл порты, удалил вредоносный контейнер в последний раз и всё стало хорошо.

Вот так мы не дали злоумышленнику погубить один из наших серверов.

Правда ненадолго: на следующий день вредоносная активность возобновилась, причем подозрительные процессы через ps aux не обнаруживались. Сервис пришлось перенести на другой сервер, а машинку загасить. Подскажите: как бы вы искали вредоносный процесс на своей виртуалке? Ресурсы были забиты под 100%, но в списке запущенных процессов ни один не вызвал подозрений. Сторонних контейнеров в Docker тоже запущено не было.

А вот еще история. Пишет мне наш шеф-редактор: зашла, мол, в DataLens (почитайте про наш трекер событий), собрала пару графиков, и всё сломалось. Смотрю, а ClickHouse, из которого графики читают данные, прилёг под нагрузкой. Кто виноват? Конечно же юзер! Поругался, урезал доступ к данным. Короче, молодец: если продуктом никто не пользуется — значит его никто не сломает.

Но как-то не по себе: от чего бы ClickHouse падать из-за такого простого запроса? Оказалось, почти вся оперативная память занята. Ну я и решил, всё верно: трекер работает уже несколько месяцев, мы накопили данных — значит, подросли. Значит, пора ресурсы увеличить. Согласовал небольшое увеличение бюджета. Уже знакомый способ решения проблемы, не правда ли? ?

И как-то обидно мне так стало за ClickHouse: что ж он всю оперативку занимает, даже когда запросы не выполняет? Причём потребление памяти постоянно росло:

Были у меня под подозрением словари, которые реплицируют данные с продакшн базы Tproger. В них хранятся соответствия идентификаторов постов и их заголовков, рубрик, тегов и т.п. Такое решение было реализовано из-за невозможности создать базу данных с движком MySQL в managed версии ClickHouse.

И хранятся словари как раз в памяти. Причём статистика в системной таблице system.dictionaries по ним показывает, мол, занимают в памяти мегабайт 10 от силы (а по графикам занято уже больше 7 гигов). Короче, не поверил, поменял схему обращения к проду Tproger, и вот как изменилось потребление памяти:

Оказалось, что словари действительно занимали почти всю свободную память. Теперь же данные с прода мы в ClickHouse не храним, а читаем налету. А получилось сделать так благодаря тому, что я случайно наткнулся на нужный раздел в документации ClickHouse ?

С точки зрения производительности и влияния на пользователя, негативного эффекта нет: наша продовая БД работает довольно шустро, а чтения со стороны ClickHouse из неё довольно редкие, ведь пользователей у DataLens пока немного.

В результате удалось вернуть ClickHouse в самую дешёвую конфигурацию и продолжить им комфортно пользоваться.

А как вы строите BI решения для небольших данных?

В ночь с четверга на пятницу, 2 октября, у нас падал сайт. Примерно с трёх ночи до десяти утра многие страницы не открывались вообще.

Причина оказалась простой: мы тестировали новые рассылки в боте. Для этого нужно подключаться к продакшен базе и получать свежие посты. Бот не закрывал MySQL-соединение и мы быстро достигли лимита в 255 открытых дескрипторов (ограничение managed MySQL от DO). Я закрыл подключение для бота и минут через 15 база данных разрешила к себе подключаться.

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

Из хорошего: мы увеличили базовый шрифт на сайте с 16 до 17 пикселей, читать статьи стало приятнее. Это потянуло за собой увеличение и других шрифтов, а также корректировки по отступам и в целом вёрстке. Изменение лучше заметно на мобильных:

Ещё мы наконец победили проблемы с CLS и даже написали про это отдельную статью, которая может помочь и вам:

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

В ходе нашей борьбы с jQuery пришла очередь избавиться от библиотеки просмотра изображений Lightbox, но увеличение картинки при клике мы терять не хотели. И среди нескольких кандидатов на замену мы выбрали библиотеку Photoswipe.

Что получили в итоге:

1. Самобытную библиотеку просмотра изображений, с возможностью настройки под наши требования.
2. Увеличение картинок происходит с красивой анимацией и поддержкой адаптивности.
3. В скорости загрузки особых изменений нет, но это минус одна зависимость от jQuery, а значит на дальней дистанции мы ожидаем получить прирост скорости.
4. В скором времени на основе этой библиотеки появятся галереи.

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

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

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

Доброго нам всем месяца и новых успехов.

Из комментариев к статье «Почему не hadoop: создаём свое решение на node + mongo + lxd»

Немного о том, как внедряли систему.

• Форкнули основной GitLab репозиторий Commento, научились его запускать и убрали оттуда лишний код.
• Переписали frontend часть под нас. Основная проблема в том, что там нет React/Angular/Svelte/Vue, а есть только старый JS — без ECMAScript, без тестов, в замыканиях — и всё это собирается Gulp.
• Настроили BitBucket Pipelines и Digital Ocean Spaces для запуска тестов/публикации/хранения Docker-контейнера. На production вертится только контейнер.
• Для авторизации переписали Single-Sign On, который теперь работает напрямую через Svelte + Node.js.
• Для задачи отображения счётчика комментариев дописали proxy через Node.js.

Только после релиза обнаружили серьёзный баг с отрисовкой: вы могли заметить, что некоторые комментарии пропадают, хотя отправка прошла успешно. Кстати, не волнуйтесь, они все хранятся в базе, так что технически они не потерялись — просто их не видно ? Исправление отрисовки заставило переносить модули frontend части на Svelte + Typescript и покрывать unit-тестами.

Чтобы помочь нам быстрее отловить критичные баги, присылайте баг-репорты через вкладку «Сообщение об ошибке» в личном кабинете.

Из приятного: совокупный сдвиг контента (метрика CLS из Web Vitals) на десктопе после релиза комментов упал практически до нуля. Медленная загрузка виджетов VK сильно смещала макет и портила нам всю статистику. Целевые показатели по этой метрике — меньше 0,1.

В этом месяце мы переработали идею подачи информации в наших вакансиях (кто бы мог подумать, что на эту идею натолкнёт работа над докладом для HR-ивента). Опросили больше полутора тысяч айтишников, собрали пирамиду Маслоу российского разработчика и скорректировали форму для составления вакансии на нашем лендинге. Благодаря этим действиям вакансии теперь будут подаваться по-другому, с акцентом на интересах соискателей.

А форма составления для работодателя утратила часть строк для заполнения и взамен получила пункты для выбора. В планах — пересобрать наши вакансии так, чтобы ребята из IT-сферы точно знали, что у нас они найдут то, что хотят.

Отрывки из новой формы, которую заполняет работодатель при размещении вакансии

Поговорим о факапах.

В этом месяце мы выпустили статью «Как признаться в любви айтишнику?». Я как обычно чекала комменты под анонсами статей и наткнулась на негодующие комментарии VK. То, что я видела как шуточную статью, остальным людям показалось реальным туториалом, а потому вызвало недоумение и негатив.

У статьи было сразу несколько проблем:

• Стереотипы. Много стереотипов — они внезапно (ладно, не очень внезапно) не нравятся людям.
• Не та ЦА. Большая часть нашей аудитории — мужского пола, и им статья «Как признаться в любви айтишнику?» была несколько не в тему.
• Нечёткое позиционирование. Шутка была недостаточно явной, а для серьёзной статьи она была слишком стереотипной.
• Несоответствие темы статьи и издания. Мы — издание об IT, а не об отношениях.

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

Что я хочу сказать по итогу этой ситуации: ошибаться — нормально. Все это делают. И очень важно — что в работе, что в жизни — научиться делать выводы, исправлять ошибки и идти дальше, а не впадать в ступор от чувства вины и собственной ничтожности. Я стараюсь помнить об этом сама и транслировать это в редакцию: если вы ошиблись, лучше думать «что я могу сделать, чтобы минимизировать последствия?», а не «как я мог так сглупить?».

В выпуске «за июль» рассказываем:

• как наняли сотрудников редакции с помощью мемов;
• много про разработку с примерами;
• про аналитическую систему (бесполезная статистика в комплекте).

Итак, поехали!

В этом месяце мы искали нового пишущего редактора в команду и сделали для этого вот такие крутые анонсы:

Вакансию закрыли, два новых сотрудника уже работают с нами.

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

15 числа, когда Spotify успешно запустился в России, наш мем был честно спизпозаимствован твиттером Not Spotify Russia. Естественно, о запуске написала и Meduza, собрав по такому поводу подборку мемов, в которую попал и наш мем, но под авторством Not Spotify Russia.

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

Производительность и работа с ошибками

В начале июля большая часть наших страниц на десктопе перестала считаться быстрыми в поиске Google. Проблема была в обновлённом сайдбаре. Я заменил старый код на современный, что дало нам ускорение работы сайта в целом и более читаемый текст в сайдбаре при прокрутке страницы. Однако браузер посчитал, что наш сайдбар постоянно меняет своё положение на экране так, как пользователь не ожидает. У всех страниц в 5–10 раз вырос показатель Cumulative Layout Shift и мы приблизительно за неделю вылетели из «зелёной зоны» определения быстрых страниц гуглом.

Отчёт Core Web Vitals в Google Search Console

Пришлось вернуть старый код, который в целом работает хуже, но не вызывает таких недоразумений при подсчёте важных метрик производительности. Буду искать другие решения для реализации sticky-сайдбара (обидно, что простое css-свойство position: sticky не решает нашу проблему, потому что у нас сайдбар не влезает на один экран). Может быть, вы подскажете хорошие решения?

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

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

А ещё мы добавили отслеживание превышения основных показателей скорости загрузки страницы, что позволяет отслеживать конкретные инциденты по производительности. За основные метрики взяли всё те же Core Web Vitals: LCP, FID, CLS.

Дашборд в нашей системе аналитики для выявления проблемных страниц по производительности

Пример события превышения порога по сдвигу контента в Sentry с дополнительными данными для повторения и расследования причин

Улучшения по работе с SQL

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

Вот, ловите пример. У нас в коде есть вот такая строчка:

Итоговый SQL-запрос выглядит, например, так:

Если проанализировать его через explain, то видно, что он не использует индекс и всегда проходит по всем полям. А всё потому что поле datetime — строка. А в запросе — число.

Если поменять на такой запрос:

То запрос вместо анализа 13262 строк сразу возвращает одну строчку и не проверяет остальные. Потому что есть индекс и он может сразу сказать где искать значение. В целом исходный HTTP-запрос получил ускорение примерно в 1000 раз благодаря улучшению SQL-кода на бэкенде.

Ужасный баг на iOS

Не без помощи одного своего хорошего друга я исправил скролинг на iOS-девайсах. Этот баг изрядно потрепал мне нервы: иногда сайт прокручивался пальцем по экрану телефона, а иногда — нет. Потом через 3 секунды снова всё работало. И опять нет. И это ещё зависело от направления прокрутки! Ох, прям физически было больно.

Оказалось, что панелька со списком тегов, которую можно вызвать тыкнув на «Все темы» в главном меню, прячется за счёт z-index: -9999. Она как бы всегда была с нами, просто её не было видно. iOS иногда применял прокрутку к этой панельке, а иногда к контенту сайта, который сверху. Почему это так избирательно работало я так и не узнал, но скрыл через display: none этот div пока он не нужен. Теперь всё работает.

Мы купили Slack

Не всю компанию, конечно, а только платный тариф для команды. На тарифном плане Standard нам доступен неограниченный архив сообщений, по 10 ГБ места на каждого юзера для хранения файлов, безлимитные интеграции и ещё куча всего.

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

А вы в команде используете платную версию Slack? Какой-то другой инструмент? Поделитесь в комментариях, нам интересен ваш опыт.

Я написал статью про переезд в Яндекс.Облако. А коллеги выпустили классный анонс, благодаря которому наши подписчики узнали, что мы используем в Tproger:

После успешного переезда мы отключили старое решение — Rockstat. Он был с нами около года. Его полностью заменил новый трекер. Press F.

Интересная (нет) статистика: в день в нашем новом трекере копится 330 тысяч событий. Абсолютные числа воспринимаются плохо, но сравнить сейчас особо не с чем. Хотя вот, например: у человека в среднем 150–200 тысяч волос. В два раза меньше, чем мы событий в день трекаем.

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

Суммарно за полтора месяца работы трекера мы накопили 9 гигабайт данных. Это как 31 минута видео в Full HD. Шестая часть хронометража «Мстители: Финал».

Не-не, обычно я серьезными вещами занимаюсь. И вам советую ?

Например, я сделал полезный инструмент, который сравнивает показатели в счетчике просмотров на нашем сайте и в аналитическом трекере. Если расхождения ≥15%, в Sentry отправляется исключение:

Просмотры — это базовая метрика. Число, которое отображается рядом с «глазиком» под заголовком статьи (в том числе этой), должно отражать реальную картину по запросам на загрузку страниц. Инструмент на базе Sentry позволит нам оперативно отреагировать, если счетчик просмотров сломается.

Новая пятничная рубрика

Три избранные статьи за июль

Будет интересно послушать и ваши истории в комментах: как прошёл месяц? Какие ошибки вы осознали и как с ними справлялись? Расскажите, не стесняйтесь, тут все свои.

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

Все выпуски ченжлога тут, на странице тега

Мы запустили платные подписки

…и они не заработали. Один подписчик заплатил нам в первый же день после запуска и сразу же написал, что реклама всё равно остаётся на сайте, даже если поставить все галки. Мы нашли ошибку не сразу, даже успели вернуть деньги от безнадёжности. Потом нашли ещё баги после анонсирования фичи. При этом сама система классная — реклама вырезается так, как будто её и не было никогда на сайте.

За пару недель продвижения подписок и сбора фидбека оказалось, что никто не понимает, зачем платить деньги «за то, что можно получить бесплатно» (имеется в виду AdBlock). У нас в принципе не очень принято платить за продукты интеллектуальной деятельности. Я не виню пользователей — они искренне не понимают, как устроен бизнес и какой ущерб они наносят индустрии тем, что блокируют рекламу или устанавливают пиратскую версию Windows.

Осталось воспринять это как точку роста и доработать продукт так, чтобы и для нас, и для подписчиков польза была одинаково понятна.

Наши серверы для разработки

…были доступны в интернете через адреса cdn, хотя доступ должен был быть закрыт через Cloudflare Access. Дело в том, что cdn у нас — это просто зеркало сайта, все запросы доходят до сервера, но кэшируются на больший срок и обрабатываются особым образом, если это картинки. Т.е. можно было вбить в браузер адрес devcdn.tproger.ru и зайти на сайт, как будто это dev.tproger.ru. А это потенциально много возможностей для атак — на серверах разработки никто не думает о безопасности. Этот баг нам прислал наш знакомый исследователь, который ранее сообщал о множестве проблем на tproger.ru.

Деплой на прод

…происходил на каждый коммит, даже если он не отправлен в мастер. Bitbucket поменяли интерфейс, а мы не поменяли скрипт. В итоге сервер был постоянно занят пересборкой, даже если это не было нужно. При этом хук держал соединение, пока сборка не завершится, и мы теряли php-fpm воркеры, которые должны заниматься обработкой запросов от пользователей. Сейчас всё хорошо, предупреждений от мониторинга стало меньше.

Просмотры постов

…не записывались в базу. По какой-то причине функция для сброса накопившихся в кэше просмотров в БД не вызывалась. Это и не приводило к какой-то явной ошибке, чтобы её заметить, и просмотры терялись. При этом кэш какое-то время накапливал изменения, и мы видели, как у статей растут просмотры. Потом кэш протухал, и счётчик сбрасывался в ноль. Ошибку исправили, теперь запись в БД по расписанию работает.

Новая AMP-тема для статей

…загружалась дольше, чем не-AMP версия и дольше, чем предыдущая версия AMP-темы. Мы исправили ошибки, теперь AMP-страницы работают быстро и Google не будет нас наказывать и лишать трафика из поиска.

Сброс кэша

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

Индексы в БД

…не были проставлены во всех таблицах. Дело в том, что когда создаётся таблица в MySQL, можно указать, по каким полям в дальнейшем будет много запросов. По ним строится дерево поиска (или хэш-таблица, зависит от конкретных случаев) и запросы выполняются намного быстрее. Например в таблице с рейтингом пользователей Tproger Gamify индексом было объявлено только поле id, а запросы были по полю user (что логично, обычно надо получать рейтинг конкретного пользователя). После добавления индексов база немного разгрузилась и стала работать быстрее. Теперь надо добавить их в коде и учитывать эту особенность в дальнейшей разработке.

Система сбора и анализа ошибок

…её просто не было. Установили и настроили Sentry, офигенный инструмент, который 100% стоит своих денег. Теперь сообщения об ошибках собираются, группируются и отслеживаются в красивом веб-интерфейсе. Сейчас мы получаем больше 500 сообщений об ошибках в минуту и, надеюсь, снизим их количество в ближайшие 2 недели, пока не закончился пробный период (а они берут деньги именно за количество событий). В Sentry есть много фич, достойных отдельной статьи, предлагаю заинтересованным изучить самостоятельно. Отмечу одну: с привязкой к репозиторию разработчик может получать уведомления об ошибках в коде, которые он совершил. Не просто общий список, а назначение на ответственных и проверка после фикса (вдруг не сработало). А ещё туда же можно собирать репорты пользователей о багах со всем их окружением (браузер, ОС, сообщения в консоли разработчика и т.п.). Раньше мы получали их в канал #bug-reports в Slack, но теперь для этой задачи присмотримся к Sentry.

Как только мы перешли на наш собственный трекер событий

…его база данных сломалась. Если по-простому, то базе не хватило «места» на жёстком диске (число открытых файловых дескрипторов превысило лимит).

Это было прогнозируемо, потому что для простоты я писал данные в базу (ClickHouse) не совсем правильно — по одному запросу INSERT на строку. Это является антипаттерном для ClickHouse, который на каждую вставку данных открывает новый файл. Данные перед вставкой следует буферизовать. Но я не рассчитывал, что с проблемой мы столкнемся так скоро.

Я решил увеличить место на диске. Простая операция в облачной инфраструктуре, но… после неё база поломалась совсем. Вот прям кластер умер. И никакого контроля с моей стороны за состоянием нет.

В холодном поту пишу в поддержку. Расчётное время ответа: 24 часа. База лежит, мы теряем данные. Поддержка не отвечает. Ок, покупаем расширенный пакет поддержки. С той стороны быстро ответили, что передали информацию разработчикам. Ждём ответа.

База мертва уже пару часов, поднять её своими силами нет возможности. Рискуем вообще всё потерять. Наконец поддержка ответила: базу починили. Я спрашиваю: в чём причина поломки? Поддержка: «она утонула» «сбой автоматики». Всё.

Ну что ж, хотя бы скайнет пока что мир не захватит.

Вывод: используйте инструменты правильно. Даже на маленьких мощностях.

Пока база лежала, я успел добавить в архитектуру трекера новый компонент — очередь сообщений, которая стоит между бэкендом и базой данных. Очередь решила проблему масштабируемости: теперь данные вставляются небольшими пакетами, а не построчно. Это рекомендуемый паттерн для ClickHouse в том числе из-за более экономного использования файловых дескрипторов.

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

Наша облачная инфраструктура заработала

…но я зачистил всю папку с исходниками и потерял те важные файлы, которые не хранятся в репозитории.

Прям вот rm -rf запустил. Ctrl-Z для такой ситуации нет, я даже погуглил.

А потерял я файлы Terraform с состоянием нашей облачной инфраструктуры. Long story short: восстанавливать все связи между ресурсами Terraform и инстансами облачных сервисов пришлось буквально вручную. Причём восстановить можно не всё. Что-то пришлось пересоздавать и заново настраивать связи между компонентами.

Вывод: делайте бэкапы.

Мы выпустили новость про разблокировку Телеграм всего через 5 минут после РБК

…но я облажалась с заголовком — все гуглили «Роскомнадзор разблокировал Telegram», а я написала «Роскомнадзор снял ограничения с Telegram». В итоге в новостные сниппеты поисковиков мы не попали, а повторная проверка поисковым ботом после изменения заголовка случилась только на следующий день.

Всё равно порадовалась, потому что мы впервые немедленно среагировали на инфоповод, собирали инфу напрямую с сайтов-источников (РКН и Госреестра), которые при этом ещё и лежали. И впервые сделали статью, которая дополнялась в режиме реального времени:

Что получилось в итоге, можете посмотреть здесь:

В общем, маленький шаг для количества просмотров, огромный шаг для редакции.

Мы немного порвали оч

…ень ограниченное хранилище ВКонтакте. Пару недель назад получили сообщение, что у нас в одном из пабликов накопилось слишком много фотографий и их надо отдать на удаление:

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

Выяснили, что так как мы тащим фотки для бота в Типичном программисте из /dev/null, то VK не может их переиспользовать и каждый раз загружает новый экземпляр фотографии в диалог с подписчиком. Решили, что в будущем изменим эту процедуру, а пока VK просто удалит из диалогов с нашими подписчиками картинки, загруженные полгода назад и ранее.

Давайте всё же и некоторые успехи зафиксируем

В июне мы запустили продвинутую версию игры «Быки и коровы» в том же боте, про который рассказывает Паша.

Загадывается 4-значное число (цифры в нём не повторяются, а число может начинаться с 0), ваша цель — отгадать это число. После каждой попытки бот сообщает вам, сколько цифр угадано с совпадением их позиции в исходном числе (быки) и сколько угадано без совпадения с позицией (коровы). Можно поиграть с ботом или посоревноваться с друзьями, как вам больше нравится.

Присоединяйтесь к движу ВКонтакте или в Телеграм — поучаствовало уже больше 6 000 игроков.

Выше я говорил о том, что поломалась база данных нового трекера. Но это лишь небольшая неприятность на фоне серьёзного улучшения, которое мы реализовали в июне. В прошлых выпусках я рассказывал, что мы меняем аналитическое решение для трекинга событий с опенсорсного Rockstat на свою разработку, развернутую в Яндекс.Облаке. И вот наконец последнее событие из трекавшихся в старом инструменте переехало в наш новый трекер! Это события по баннерам, они переехали с историей, которая есть у нас аж с августа 2019 года. Вот на графике момент, когда к нам в трекер начали попадать свежие события:

Игорь — наш веб-разработчик.

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

Скажу пару слов об одной из новых фичей: мы поняли, что хотим автоматизировать размещение баннеров. Это нужно, чтобы не тратить кучу времени на согласования картинок и текстов и таким образом освободить себе и партнёрам драгоценные ресурсы, которые можно и нужно вкладывать во что-то более полезное. Так появился «мастер баннеров»: теперь чтобы запустить рекламу своего продукта под статьями у нас на сайте, нужно пройти всего пару шагов в специальном инструменте.

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

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

В материале вы можете найти опрос. При этом мы не хотели провоцировать неконструктивный хейт на предмет расизма и «охреневших американцев», нам казалось важным перевести дискуссию в несколько другую плоскость. Вот скрин опроса:

Продолжая тему важных материалов: один из наших разработчиков поделился опытом и написал статью по расширениям для VS Code. Надеюсь, относительно скоро у нас на нашем же сайте появится свой блог со статьями от членов команды.

Ещё в июне мы выпустили тест, где надо угадать ОС по скриншоту. Я сосредоточилась на том, чтобы больше людей пообщались друг с другом, а потому старалась вызвать активное комментирование. В подводке рассказала, сколько сама набрала баллов при первом прохождении теста, попросила читателей писать «БИНГО», если они работали с каждой из перечисленных систем, а также в некоторых результатах добавила шуточный вопрос про то, что лучше: Windows или Linux.

В итоге на 23 700 просмотров пришлось 40 комментов. Для сравнения, в математическом тесте на 46 000 просмотров приходится 12 комментов. Тут стоило бы упомянуть, что есть куча дополнительных факторов, которые могли повлиять: другая тема, другая дата, другое соотношение источников трафика и так далее — но результат всё равно есть. И наверное был бы ещё круче, если бы у нас была своя платформа комментов, которая уже на подходе: мы знаем, что некоторые юзеры не могут подключиться к обсуждению, потому что не пользуются ВКонтакте, а у кого-то эта соцсеть вообще не работает из-за локации.

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

Кстати, если у вас есть пожелания по поводу рубрик и тем на сайте, задумки новых фичей и любые другие идеи по поводу улучшения нашего издания — присылайте на почту product@tproger.ru, обсудим.

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

Внутри есть опросы — поделитесь мнением, пожалуйста.

Все выпуски теперь можно найти по тегу Tproger Changelog.

Начнём с маленьких радостей: во вставках кода теперь красивый скрол (только в Webkit-браузерах, но это практически все популярные). Стили честно скопированы со StackOverflow.

Нам прислали ещё один отчёт об уязвимости — на этот раз раскрытие файлов, которые не должны были быть публичными. Списки пакетов и зависимостей нашего проекта. Это не очень критично, но облегчает жизнь злоумышленникам: так проще найти дыры в стороннем коде, который мы используем. Я всё исправил, заплатил ещё одну порцию вознаграждения.

На прошлой неделе Google обновил инструмент PageSpeed Insights и отчёт о скорости загрузки страниц в Search Console. Вместо времени первой отрисовки контента и задержки ввода стала использоваться Web Vitals — новая концепция поискового гиганта в оценке производительности веба. Я занимался подготовкой к этим изменениям и заранее оптимизировал явные ошибки. Итог — почти все страницы нашего сайта Google теперь считает быстрыми, как на мобильных, так и на десктопе.

На мобильных почти в два раза больше URL, потому что там есть AMP-версия сайта.

Некоторые URL ещё требуют доработок, но теперь явно видно, какие именно и что с ними не так. Больше всего проблем с видеопостами — вставки плеера через iframe загружаются долго и сдвигают контент. Но я уже знаю, как это исправить.

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

Трафик из поиска по данным Яндекс.Метрики, абсолютные значения скрыты, важен процентный прирост.

В прошлом выпуске Changelog была новость про блок «Также рекомендуем», который вы видите после прочтения материала. Сейчас мы работаем над повышением качества рекомендаций в этом блоке, их эффективность видно на графике.

Значения на диаграмме — это CTR (click through rate). Он показывает отношение числа кликов по рекомендации к числу просмотров блока рекомендаций. Мы разбили день на 4 части, по оси OX приведены шестичасовые интервалы.

Раньше рекомендации для всех пользователей были общие и строились на основе статистики просмотров наших статей (на графике — fallback). Затем мы персонализировали рекомендации с помощью сервиса Amazon Personalize: каждый пользователь стал получать индивидуальный список рекомендаций (awspersonalize-user-only). Однако для каждого пользователя список был одним и тем же под всеми статьями. Теперь же рекомендации строятся с учетом текущего просматриваемого материала (awspersonalize-user-item).

Увы, но наши текущие нововведения не снискали популярности у читателей: CTR рекомендаций падал с каждым новым внедрением. Чтобы исправить ситуацию, мы планируем поэкспериментировать с разными рецептами Amazon Personalize, а также начать обучать модель рекомендаций в режиме реального времени.

Еще расскажу про нашу аналитическую инфраструктуру — особенно интересно будет тем, кто выбирает между готовым решением и своей системой.

Как и многие создатели контента, мы пользуемся Яндекс.Метрикой и Google Analytics. Но также развернули и поддерживаем свой трекер событий на базе опенсорсной платформы Rockstat с ClickHouse в качестве базы данных. Для визуализации данных используем Redash, график по блоку рекомендаций сделан как раз в нем. Это удобный и простой инструмент, который умеет работать с ClickHouse, но с одним минусом: для его использования надо знать SQL, а это подходит не всем сотрудникам.

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

График отчета по тематикам в Яндекс.Метрике.

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

Короче говоря: собирая события самостоятельно, мы можем наделять их семантикой, специфичной для наших задач. Например, в Метрике клик будет просто кликом, а в Rockstat — кликом пользователя на закешированной странице по баннеру, относящемуся к рекламной кампании с лимитом в 10 тысяч кликов. Гораздо больше информации, не правда ли?

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

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

В прошлом месяце мы открыли каналы своих проектов в новом мессенджере от Яндекса с оригинальным названием Яндекс.Мессенджер.

Его особенность в том, что он очень здорово интегрирован в экосистему Яндекса: читать сообщения можно в приложении, браузере или на главной странице.

А чтобы помочь авторам каналов быстрее развиваться и привлекать интересующуюся аудиторию, Яндекс запустил систему рекомендаций. Мы в неё, кстати, успешно попали, и теперь в своих сервисах Яндекс показывает наши каналы и всем рекомендует на них подписаться. Благодаря этому у нас уже есть посты, которые увидели тысячи читателей. А если среди них нет вас, то и вы гляньте, что там в этом Мессенджере происходит. У нас там сейчас открыто 3 канала:

— про разработку в целом: «Типичный программист»;
— про новости технологий, который влияют на нас: «Представляешь,»;
— и программерский юмор: «IT Юмор».

В конце добавлю от себя пару новостей из раздела «прочие шалости».

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

В паблике «Типичный программист» ВКонтакте провели пятничную трансляцию на тему инфобеза и внезапно собрали больше 30 000 просмотров. Планируем попробовать ещё подобные трансляции — не пропустите.

Editor’s choice: три избранных материала за окошком месяц май

Статья с довольно очевидной информацией, но получают её обычно методом проб и ошибок. Поможет не наступить на грабли, особенно если только начинаете программировать.

Забавный тест, всегда интересно узнать, «кто ты», а тут ещё и известные личности.

Наглядная статья, и обратите внимание на опрос в конце — стали добавлять интерактив, потому что интересно мнение комьюнити и хочется, чтобы вы приходили на площадку не просто почитать статьи, но и обмениваться мнениями, спрашивать совета и делиться своими историями.

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

Продолжаем осознавать, что такое mobile-first вёрстка. Больше размеры шрифтов и больше воздуха в меню и футере на мобильных. Стало проще попадать пальцем в нужный пункт, особенно на маленьких экранах:

Улучшили читабельность надписей. Много серого цвета заменили на более чёрный или белый в зависимости от фона. Главное открытие — наш фирменный цвет с логотипа считается ошибкой дизайна для текста на белом фоне из-за отвратительной контрастности. Поэтому изменили дизайн ссылок в постах:

Сделали красивую вёрстку для внешних ссылок, когда нужен простой эмбед:

С помощью Amazon Personalize улучшили блок с рекомендациями материалов. Раньше список рекомендаций под каждой статьей для всех пользователей был общим и строился на основе статистики просмотров статей. Теперь рекомендации стали персонализированными, список строится индивидуально с учётом вашей личной активности на сайте:

Исправили уязвимости и перевели вознаграждение за репорты:

• раскрытие ip-адреса origin-сервера;
• некорректные SPF-записи для почты;
• раскрытие аккаунтов WordPress;
• возможности для DDoS.

Немного редакционных новостей

Запустили еженедельную рубрику «IT во время чумы» с самыми интересными новостями пандемии, которые связаны с технологиями. Забавно получилось с тегом, который объединяет статьи рубрики — сайт решил, что надо использовать его в блоке рекомендуемых вакансий. Скриншот немного шакальный, но другого не осталось, баг уже исправили:

Сделали ребрендинг телеграм-канала «IT Новости», увеличили там количество выпускаемого контента почти в три раза, теперь там стало ещё интереснее и веселее. Мы решили сосредоточиться на IT событиях России, СНГ и мира, которые прямым образом влияют на каждого из нас. Подписывайтесь и читайте, если ещё не сделали этого: @your_tech.

Почти везде наладили адекватную вёрстку для печати. Пример из статьи Стена технического долга: наглядная альтернатива багтрекеру.

Запустили «спонсорство рубрик» с GeekBrains. Пытаемся найти формат банеров, который будет минимально раздражающим и максимально выгодным.

Подвели итоги конкурса Tproger Gamify. Это был первый для нас опыт применения механик геймификации на сайте. Таким образом рассказали о том, какие у нас есть фишки на сайте: основная сейчас, конечно, это личные кабинеты. Разыграли ништяков, сейчас занимаемся отправкой.

Кстати, через личный кабинет можно отправить баг-репорт. Пожалуйста, не стесняйтесь, нам это нужно.

Editor’s choice: обратите внимание на эти статьи

Что происходит у нас в команде

Мы перешли на платный тариф Notion и благодаря вам всего за один пост ВКонтакте собрали денег на 1,5 месяца бесплатного пользования. Это классный нужный нам инструмент. Теперь создаём там базу знаний по проекту, ведём заметки и составляем конспекты выступлений.

Каких ещё выступлений? По четвергам у нас лекторий: раз в неделю кто-то из команды рассказывает про тему, которая ему интересна.

Сейчас почти полностью сидим на удалёнке, непривычно, но не критично. В этот четверг как раз попытаемся провести лекторий по видеосвязи. Удобно, что Google снял ограничения на корпоративный Hangouts, мы можем пользоваться через рабочие почты, пока полёт нормальный.

Ласт, бат нот зе лист: открылась вакансия пишущего редактора. Пожалуйста, распространите по знакомым. Ну и вообще мы всегда ищем специалистов, которые хотят к нам присоединиться.

До новых встреч. Будьте здоровы ?

Молодой WordPress

Это была чистая установка движка WordPress с популярной темой Bliss, которая впоследствии была значительно переделана.

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

В общем, наш сайт с треском упал через минуту после публикации ссылки на него в сообществе. И нам пришлось позвать человека-надо-было-ставить-линукс — Александра Фольца и теперь уже нашего сотрудника.

Стал администратором инфраструктуры типичного я чисто случайно. На тот момент я уже работал в ТП редактором в течение нескольких месяцев. Как мне помнится, всё началось с просьбы нашего главного типичного настроить небольшой php-скрипт. Задание было весьма тривиальным, и я подумал: почему бы и нет? Получив кое-какой первоначальный доступ, я был удивлён весьма плохим состоянием инфраструктуры (как оказалось, этим просто было некому полноценно заниматься).

После нескольких небольших задач мне предложили постоянное место. Помнится, я потратил с месяц на доведение всех параметров инфраструктуры до актуального состояния (обновление, автоматизация некоторой рутинной работы). Сначала я контролировал всё вручную, но потом мы стали разрастаться — мне пришлось использовать Icinga (форк nagios) для контроля всех основных параметров. Возможно, кто-то скажет, что целая система мониторинга «для небольшого сайта» — это перебор, однако спешу вас уверить, мы больше, чем кажемся.

Пожалуй, отдельного упоминания заслуживает веселье в начале этого года, которое связано с DDoS-атаками на tproger.ru. Нам пришлось экстренно переходить за CloudFlare, что, в свою очередь, породило кучу жарких споров в своё время. Главное в таких делах — вовремя приходить к консенсусу. Также мы получали множество угроз от весьма сомнительных личностей. Один раз я даже ночевал на работе из-за проблем с сайтом.

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

Конечно, без 100 грамм и трех уровней кеширования на WordPress высоконагруженный проект не запустить, но эта CMS стала самой популярной не просто так: оценить такие вещи стоит не только с позиции программиста, в команде есть и много других людей. Да и бизнес обычно не терпит долгие ожидания.

«Если вы запустили первую версию продукта, и вас ничего в ней не раздражает, вы запустили её слишком поздно» — Рид Хофман, основатель LinkedIn.

C тех пор утекло немало воды. Текущую версию вы видите прямо сейчас. Можете убедиться в том, что изменилось почти всё: страницы стали более информативными, поиск стал удобней с переходом на Google CSE, с мобильных всё выглядит так же хорошо, как и с десктопа, появились Push-уведомления и многое другое.

Конечно, некоторые из компонентов удалось скачать бесплатно в официальном магазине WordPress, но далеко не все. На сегодняшний день 80% всех установленных на сайте плагинов писались самостоятельно — в публичном доступе аналогов, сравнимых по качеству с нашими, просто не существует.

Интерактивные статьи

Одним из таких плагинов является движок рубрики «Эксперты»:

Он позволяет любому читателю проголосовать за тот или иной ответ общепризнанного эксперта и, посмотрев на рейтинг, понять: чьему мнению стоит доверять, а чьему нет.

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

К слову, присоединиться к созданию тестов и викторин на добровольной основе может каждый желающий — присылайте материал на admin@tproger.ru.

Дальнейшие планы

Несмотря на большой пройденный путь, Tproger не планирует останавливаться и продолжит вас радовать свежим и интересным контентом. Одним из последних тасков было обновление страницы 404, но впереди нас ждут более глобальные изменения, вплоть до полного редизайна сайта, который мы уже тестируем.

Мы всегда открыты для ваших баг-репортов, идей и предложений: контакты, по которым писать.