А между тем выпуск по плюсам уже на ютубе, вк и других площадках (включая аудио) https://youtu.be/-6RCZhM9hqU?si=IbvGURYfquEUIPFO

Альтернативные ссылки: Аудио | vk

Гости для подкаста

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

За последние три месяца подкаст + шортсы из него посмотрели почти 5 миллионов раз! Правда тут надо учесть один шортс с Бугаенко. Он один собрал 3 миллиона и это какой-то рекорд, который я вообще не факт что смогу побить. Но даже без него получается пару миллионов, что довольно некисло.

За все время подкаста самым популярным стало видео:

⁃ Кира Кузьменько
⁃ Егор Бугаенко
⁃ Деми Мурыч

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

Я все еще не разобрал конкретные фреймворки, системный дизайн и все что в него входит по элементно, стили программирования, концепции, computer science в целом (и лямбды и теорию типов). Никуда не делась история с лайвкодингом, дебатами и моими разборами, которые я хотел бы делать чаще. Поэтому если у вас есть видео на разбор, присылайте его.

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

Ссылки: Телеграм | Youtube | VK

Тестируем вызовы API с помощью кассет

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

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

class VCRTest < Test::Unit::TestCase
  def test_example_dot_com
    VCR.use_cassette("synopsis") do
      response = Net::HTTP.get_response(URI('https://www.iana.org/domains/reserved'))
      assert_match /Example domains/, response.body
    end
  end
end

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

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

Кстати порты этой либы есть наверное для всех языков. Накидайте в комментах ссылки на популярные решения для вашего стека. Рубишная вот: https://github.com/vcr/vcr

Ссылки: Телеграм | Youtube | VK

Продолжаем про подкасты 🙂 Рынок IT-найма все еще лихорадит. Количество специалистов растёт, вакансий меньше, а рекрутинг переживает, пожалуй, один из самых турбулентных периодов за последние годы. Мы говорим с Алексеем Сухоруковым — человеком, который с 2005 года занимается IT-рекрутментом помогая инженерам находить работу по всему миру

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

Мы также говорим о переходе от удалёнки к офисам, налогах и релокации в Европу, Восточной Европе как новом центре роста, а ещё вспоминаем истории о зарождении российского аутсорса, дотком-буме и даже «сектантских» практиках некоторых ранних компаний. youtube.com/watch?v=o-LQSbo6w2s

Альтернативные ссылки: Аудио | vk

Как правильно откатывать миграции

Если коротко, то никак. В продакшене миграции могут идти только вперед. Какого?

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

Ролбек, в идеале, это просто переключение с одной версии кода на другую. Но ведь тогда возможны ошибки связанные с изменениями в базе? Если делать через жопу, то возможны. При правильном подходе, база всегда обратно совместима как минимум на одну версию. Только в этом случае мы можем обеспечить и бесшовный деплой (zero downtime deploy) и практически моментальный откат.

А это значит, что нельзя менять тип у колонок (если тип сужается), нельзя менять именования таблиц и полей. Если это все таки нужно, то существует немало техник, позволяющих сделать переход через создание новых сущностей и синхронизацией либо через код либо через саму базу (например с помощью триггеров). По этой теме даже написали целую книгу "Refactoring Databases: Evolutionary Database Design".

Получается, что любые ошибки в базе будут только накапливаться? Не совсем. Обратная совместимость обычно нужна только на текущую и следующую версию. Если у нас не коробка, а облачное решение, то одновременно могут работать только две версии. В таком случае, мы без проблем можем писать любые миграции, которые удаляют и меняют все что угодно, что уже не используется. Заметьте, это не откат, а новые миграции.

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

Ссылки: Телеграм | Youtube | VK

Тут в закромах мы готовим мощное видео с аналитикой и интервью hr на тему того как они смотрят на сопроводительные с реальными кейсами. Хотим поставить так сказать жирную точку в этом вопрос, надо ли писать и если надо то как. Вы можете принять непосредственное участие в создании, ответив на несколько вопросов из нашей анкеты про ваше отношение к сопроводительным: https://docs.google.com/forms/d/e/1FAIpQLSfubAb9OLRPZPWmYg8O8STZMFgLJY36C1MmC1aIVvHO-EAqtA/viewform?usp=header Будьте бобры 🙂 и не забудьте переслать друзьям программистам!

Ссылки: Телеграм | Youtube | VK

Пятничный пост

Решил включить эксперимент и написать что-нибудь личное, а не только профессиональное. Если зайдет, буду иногда постить, если нет, то только в инсте.

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

В конечном итоге мне прислали чек на 3500$ из которых я уже заплатил около 1000$ за тест. Честно говоря это сильно меньше, чем ремонт, который надо было бы сделать. К этому моменту я уже был наслышан про то как судятся со страховыми и решил пойти по этому пути.

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

Начали мы бодро, мне сказали что офигенный кейс, есть фотки видео, а еще плесень, красота. Насчитали что мы сможем получить около 75 000$.

Дальше был интересный процесс, который называется mediation. Все в зуме. На этом процессе есть я и мой attorney, с другой стороны представитель страховой. Между нами есть человек, что-то вроде судьи (я так понял это бывшие судьи), который ведет процесс. Идея в том, что каждый выражает свое мнение, дальше мы расходимся по комнатам где обсуждаем сумму. Мы говорим сумму подключившемуся к нашей комнате судье, дальше судья идет в комнату страховой и говорит наше предложение, они делают контрпредложение. И это реально выглядит как жесткие переговоры, с угрозами "наше финальное предложение 10 000$ или мы уходим". В общем предложили нам сумму, которая нас не устроила и attorney уговорила меня продолжить процесс.

И на этом все встало примерно совсем. Прошел год, потом другой и я уже смирился с тем, что никаких денег не увижу, когда вдруг мне написали что готовится очередной mediation. Видимо все таки, какая-то движуха за эти годы там была, может и не так активно. Короче в этот раз мы договорились до суммы в 30 000$. При этом мы не согласились на то, что ее берем, там такая фишка, что это предложение от страховой действует в течение недели и мы можем еще попытаться что-то с этим делать. Мой attorney сказала, что она сможет на фоне увеличить эту сумму, потому что они неправы. В итоге через неделю она подняла выплату до 35000$ на которую мы уже согласились.

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

Как вы думаете сколько я получил? В итоге из этих 35 000$ моих там было 16 000$. Вот такая вот история

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

Ссылки: Телеграм | Youtube | VK

Редакторы кода и инструменты для разработчиков — тема, вокруг которой строится целая индустрия. Когда-то переименование переменной казалось подвигом, а сегодня IDE умеют делать десятки сложнейших трансформаций так, чтобы программа оставалась корректной. В выпуске мы говорим с Дмитрием Ивановым, руководителем платформы Sourcecraft в Яндексе, о том, как развивались JetBrains и IntelliJ IDEA, почему в СССР писали компиляторы для Алгола-68, и чем отличается подход «IDE как комбайн» от современной архитектуры LSP.

Обсуждаем истории изнутри JetBrains, появление Kotlin как ответа на невозможность поддерживать Scala, и то, как AI-тулы и LLM-редакторы вроде Cursor меняют правила игры. Затрагиваем вечный спор Vim против IDE, сравниваем глубину анализа кода и ограничения протокола LSP, вспоминаем курьёзные случаи из практики и прогнозируем, что ждёт рынок инструментов разработки к 2026 году
https://youtube.com/watch?v=mIbtxa27K4E

Альтернативные ссылки: Аудио | vk

Полиморфизм и наследование

Каждый раз, когда я слышу от кого-то описание или определение полиморфизма, там присутствует слово "наследование".

> Объясните что такое полиморфизм? Ну это когда базовый класс и наследники...

Давайте по порядку. Полиморфизмов вообще существует больше чем один. Но, все таки, когда речь идет про массовое программирование (простите функциональщики), по умолчанию говорят о полиморфизме подтипов (subtyping). Упрощенно, в этом полиморфизме мы заменяем иф на общий метод для разных типов объекта. Таким образом сам объект (его тип) определяет реальное поведение, а вызывающий код про это не знает, он просто дергает метод (или методы):

function doSomething(logger) {
  // Где-то снаружи выбирается конкретный логгер
  // Разные логгеры могут работать сильно по разному
  logger.info('hey');
}

Что мы тут получили? Возможность менять поведение конфигурированием приложения (меняем реализацию объекта во время настройки), а не тем, что ходим по ифам где выбирается конкретная реализация и меняем там код.

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

Кстати, для реализации полиморфизма подтипов классы тоже не нужны. Есть немало языков где он есть, но там нет ни классов ни ооп в привычном варианте.

p.s. Является ли перегрузка функций полиморфизмом?

Ссылки: Телеграм | Youtube | VK

Как научиться программировать лучше

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

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

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

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

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

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

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

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

Почему это так? А потому что в остатке мы упираемся в побочные эффекты, барьеры абстракции (тут сикп) и грамотное управление состоянием. Вот такие пироги

Ссылки: Телеграм | Youtube | VK

Пятничный пост

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

В общем где-то в ковид, мы поплыли первый раз в путешествие по карибам на роял карибиан, на корабле Oasis of the Seas, на тот момент, третий по размерам корабль в мире. Я конечно был в шоке, ощущение, что крутой турецкий отель поставили на платформу и теперь мы на нем плаваем. А самое главное насколько это удобно, ты просто на машине заезжаешь на парковку рядом с кораблем и примерно как в аэропорту проходишь стойки регистраци и вуаля. И ладно бы это просто был отель, так мы ж плывем и путешествуем. Буквально за первую поездку + 3 новых страны. Самый ржач, что одной из этих стран была Франция (и вроде дания?) Там один остров делят пополам и везде евро в деньгах, номерах и разговоры на французском.

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

Кстати последний раз плавали на европейском корабле, где в основном плавают люди из европы. Они реально сюда летели 10-12 часов, чтобы 5 дней прокатиться.

Ссылки: Телеграм | Youtube | VK

Я регулярно набрасывал на книгу Мартина "Идеальный код". Пришло время, так сказать разложить по полочкам. На моем канале вышло первое видео из большого разбора. Начинаем с функций
https://youtube.com/watch?v=-tp2bfP36Hg

Альтернативные ссылки: Аудио | vk

Рекрутеры и HR. Вопрос у меня есть для вас. Насколько сопроводительные письма влияют на ваше отношение к резюме? Мы на Хекслете делаем большое и подробное видео на эту тему, где хотим показать статистику и отношение к этому с вашей стороны. Насколько влияет, стоит ли писать, если да то что, если нет то почему. Поучаствуйте плс в небольшом опросе (буквально на минутку) и поделитесь своим мнением https://forms.gle/tSKsbtd533yCkBuMA

p.s. Честно не уверен что у меня большая аудитория среди hr, но все таки вдруг. Отметьтесь плс, интересно посмотреть 🙂

Понимание побочных эффектов

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

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

Словосочетание "побочный эффект" (side effects) действительно прочно ассоциируется у нас в обычной жизни с чем-то, что не задумывалось и чего бы лучше не было. И обсуждая логику построения кода мы можем говорить о том, что функция делает какие-то действия, которые выходят за границы того она должна делать. Но! Это все относится к единой ответственности и это более инженерно-философское понятие, в отличии от понятия сайд эффекта.

В англоязычной среде термин side effect это строгое техническое понятие, которое закреплено в университетских курсах, учебниках и даже в стандартах языков. Любой студент CS в США или Европе проходит курсы вроде SICP или использует современные учебники вроде ТАПЛ, где написано: side effect = любое изменение состояния или взаимодействие с внешним миром, помимо возврата значения. Сюда относятся изменения глобального состояния, исключения, работа с памятью и взаимодействие с вводом/выводом (запись чтение файлов, сеть и т.п.)

Structure and Interpretation of Computer Programs (Abelson, Sussman, 1985)

> Side effects are changes of state produced by a procedure in addition to returning a value.

Types and Programming Languages (Benjamin Pierce, 2002)

> A side effect is any observable interaction with the outside world other than producing a return value

ISO C Standard (ISO/IEC 9899:2018, §5.1.2.3)

> Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects.

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

Java Language Specification (Java SE 17, §15.4)

> Evaluation of an expression may produce side effects, which are changes in the state of the execution environment

Rust Reference (раздел Unsafe Code Guidelines)

side effects явно перечисляются: запись в память, вызовы внешних функций, работа с volatile

И Мартин прекрасно понимает что он имеет ввиду под побочными эффектами (естественно он использует термин Side Effects) и более того, описывает это: A function should do one thing. Side effects are things like writing to a file, changing a global variable, throwing an exception

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

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

p.s На ютубе тьма видео, которые это все подробно и популярно объясняют. Можно начать отсюда: https://www.youtube.com/watch?v=_nG09Z_tdUU

Ссылки: Телеграм | Youtube | VK

Какая должна быть длина у функций?

Щас скажу кое-что неочевидное. На эту проблему нельзя смотреть в статитке. Вот правильно 4 строки, 10, 100, поэтому разбиваем как-только доходим до предела. Я смотрю на это в динамике.

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

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

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

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

p.s. Смог тут загуглить исследование сотен миллионов строк на гитхабе: https://arxiv.org/pdf/1806.04556 (на скрине выдержка)

Ссылки: Телеграм | Youtube | VK

За последние годы развитие браузеров происходило настолько высокими темпами, что многие теряются в происходящем. Я решил это исправить. Мы поговорили с Вадимом Макеевым — экспертом по веб-стандартам из Mozilla (ранее работавшим в Opera), и обсудили, как эволюция браузеров изменила работу разработчиков.

В выпуске мы вспомнили, почему Chrome занял рынок, а Firefox потерял позиции, разобрали, как Google проталкивал API под свои сервисы, а Safari оставался «догоняющим», но задавал рамки приватности. Мы обсудили новые возможности: Navigation API, контейнерные запросы и baseline от MDN, показали, как Core Web Vitals стали новой валютой оптимизации, и поговорили о будущем JavaScript с нативной типизацией.

Мы также затронули тему LLM-браузеров и обсудили, как появление ИИ в браузере может изменить разработку и саму философию веба. Этот разговор оказался не только о технологиях, но и о том, как решения корпораций и сообществ напрямую повлияли на повседневную работу инженеров.
https://www.youtube.com/watch?v=uPIUl8Bdq5A

Альтернативные ссылки: Аудио | vk

SEO для программистов #1

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

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

Поиск отличный индикатор спроса. Через его аналитику можно смотреть чем интересуются люди и что имеет смысл для них делать, если мы решили запустить что-то свое. Делается это тут wordstat.yandex.ru Если вы никогда не тыкали ворстат, то очень рекомендую это сделать. Плюс если вы хотите запустить что-то свое, сначала убедитесь, что людям это надо. Если в вордстате нет запросов на ваш потенциальный сервис, то вероятность его успеха стремится к нулю.

Допустим спрос есть и мы делаем курсы по программированию, которые нам кажутся лучшими на свете. Смогут ли люди их найти в поиске? Почти наверняка нет, кроме случаев, когда они ищут прямо конкретно ваши курсы, это так называемый бренд трафик. Запросы с такого трафика всегда содержат название компании/человека представляющего эту компанию в публичном поле. Например "хекслет курсы" это брендовый запрос. Брендовый спрос работает только в том случае, если вы известны или делаете много рекламы (часто кликают не по самой рекламе, а гуглят компанию после того как ее увидели). Например много брендового трафика у ютуберов и известных компаний. В поиске эти компании почти всегда выше остальных за счет известности, поисковики это любят (потому что это любят люди).

А если набирают просто "курсы по программамированию?" Вы заметите что там кто угодно, кроме вашего проекта. Да возможно вы появляетесь на 20 странице, но до нее доходят единицы людей и почти никто не кликает. И дальше встает вопрос, а как сделать так, чтобы наш сайт был выше в поиске по запросам, которые нас интересуют?

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

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

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

В итоге схема выглядит так. Мы анализируем спрос собирая семантическое ядро, это все запросы, которые делаются под вашу тематику. Дальше оно сводится к конкретным запросам, которые мы превращаем в посадочные (лендинги) и работаем со сформированным спросом. То есть теми людьми, которые уже хотят наш товар. А мы хотим чтобы его купили у нас, а не у наших конкурентов. Общая схема воронки:

запросы => посадочная => заявка => продажа

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

p.s. Какая часть из seo вам интереснее всего?

Ссылки: Телеграм | Youtube | VK

SEO для программистов #2

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

1. Подсказки самих поисковиков

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

2. Производительность

Запомните два главных слова: Core Vitals. Это ключевые показатели, которые должны быть в зеленой зоне. По хорошему они ставятся как часть KPI для разработчиков. Никто кроме них за это не отвечает и не может сделать правильно. Остальное как обычно, высокая скорость отдачи, кеширование всего и вся, лейзи, использование последних версий http, cdn и чо там еще можно придумать. Эти показатели можно отслеживать через кабинеты в поисковиках + page speed

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

3. Разметка

Сервер должен отдавать html. Либо серверная шаблонизация (классика), либо ssr. Никакого рассчета на то, что поисковик проиндексирует ваш js. Да, в теории он может, но на практике это дорого поэтому индексация не надежна и будет происходить сильно дольше и без гарантий.

Обязательно заголовки в правильном порядке (от h1 по h6). Бывает что разработчики вместо заголовков делают дивы с большим размером шрифта. Это шляпа.

Мета теги тоже важны. Минимум: title, description и canonical. Последний имеет очень важное значение для правильности индексации и не так просто как может показаться, особенно если речь идет про постраничную навигацию. Тут лучше копнуть в статьи или ИИ.

В целом нужно прогонять верстку через валидатор и не допускать косяков.

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

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

4. Перелинковка

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

5. Ошибки

Смотрим в кабинеты поисковиков и устраняем все проблемы, от 404 и 500 до страниц закрытых от индекса в robots.txt (этого недостаточно). Ошибок должно быть мало в процентном отношении к количеству проиндексированных страниц. В целом следим за корректностью кодов и правильными редиректами.

6. Мобилки

Сейчас весь поиск мобайл-ферст. Это значит, что сайт на мобилках должен летать и соответствовать хорошей доступности плюс адаптивность конечно. Если это не так, то пессимизация в поиске гарантирована. Где смотреть? Кабинеты + page speed и аналоги.

7. Индексация

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

- Не индексировать то, что не ищут (не давать ссылок на внутренние разделы, использовать мета тег noindex, а не robots.txt)
- Делать и загружать в кабинетах sitemap.xml
- Использовать по месту noindex, nofollow.

Ссылки: Телеграм | Youtube | VK

В гостях — Андрей Кобец, фронтенд-разработчик, преподаватель и человек с огромным опытом в IT, начавший путь в 2004 году. Мы вспоминаем, как выглядела разработка двадцать лет назад: первые проекты на PHP, устройство на работу «по знакомству», собеседования в Яндекс, жизнь внутри команды Метрики, офлайн-формат работы и зарождение российских соцсетей.

Обсуждаем, как в отсутствие курсов и системных материалов приходилось самостоятельно искать путь в профессию, чем отличались собеседования тех лет, какую роль играли софтскилы в офлайн-командах, как менялись подходы к образованию, и почему функциональное программирование стало для многих настоящим откровением. youtube.com/watch?v=7MeMdrgJ2Uo

Альтернативные ссылки: Аудио | vk