Студенческие клубы разработки

Поездка на OS Day

Никита Рыданов — Sat, 29 Aug 2026 00:00:00 GMT

Навык думать переживёт навык писания на питоне. <…> Но молодёжи в разы труднее, чем нам.

— Александр Попов, Positive Technologies

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

Команда Some(Team) на OS Day

О конференции

OS Day — ежегодная научно-практическая конференция про операционные системы, системное программирование и разработку операционных платформ. На сайте конференции она описана как коммуникационная площадка для теоретиков и практиков системного программирования, место консолидации российских разработчиков ОС и поиска точек для совместной деятельности. Конференция проводится с 2014 года.

Главные задачи конференции:

определить актуальные технологии и перспективные направления в разработке ОС;
обозначить ключевые вызовы IT-отрасли;
дать разработчикам, производителям и заказчикам место для обмена практическим опытом.

По ощущению из программ разных лет, это не «широкая IT-конференция», а довольно узкая профессиональная встреча людей, которые делают системное ПО: ядра, RTOS/ОСРВ, драйверы, средства безопасности, сборочные системы, инструменты анализа, поддержку архитектур, доверенные среды, российские ОС и аппаратные платформы.

Победителям нашего хакатона DiscoHack — команде Some(Team) удалось выступить на ней со своим проектом. На конференцию из участников команды поехали Ваня Архипов, Саша Железко, Егор Смирнов и Ира Клюева. Мне удалось поспрашивать ребят об их впечатлениях.

Что за проект

В дистрибутивах Linux поддержка облачных хранилищ ограничена: те же GNOME Online Accounts поддерживают лишь несколько, и российских провайдеров среди них нет. В нашем случае участникам было предложено закрыть конкретную нишу — нативную интеграцию российских облачных провайдеров под операционную систему ALT Linux.

Команда назвала своё решение Pompilius. Оно состоит из двух частей:

pompiliusd — фоновый демон на Rust. Ставится как пользовательский сервис systemd, поднимает интерфейс в сессионной шине D-Bus (org.zbus.pompiliusd) и транслирует вызовы в управляющее API rclone. Через него заводятся и удаляются профили облаков, монтируются удалённые хранилища, выдаются публичные ссылки на файлы и управляется локальный кэш для офлайн-доступа.
pompilius — расширение для Nautilus на Python и GTK4. Добавляет в контекстное меню пункты для работы с облаком, диалоги настройки профилей и иконки-оверлеи, показывающие статус файла прямо в списке файлов.

Ставка на rclone позволила закрыть нишу с запасом: провайдер перестаёт быть особым случаем, поэтому Яндекс.Диск и NextCloud подключаются ровно так же, как S3 или WebDAV. А то, что делает проект уместным на конференции про операционные системы, лежит на стыке двух частей: это не веб-интерфейс поверх чужого API, а системный демон, интеграция с systemd и D-Bus и расширение штатного файлового менеджера.

Открытое удалённое хранилище с помощью pompilius

Как это случилось?

Идея представить проект победителей хакатона была неочевидной — и предложила её Инна Александровна Батраева, зав. кафедрой технологий программирования на базе филиала ООО «Мирантис ИТ» в г. Саратове, хорошо известная многим студентам ещё с приёмной комиссии. Жюри отнеслось к идее скептически:

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

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

Ребята, конечно, предложению удивились, но отказываться не стали. Некоторые скепсис жюри разделяли:

Егор: Я крайне сильно удивился, т.к. всё ещё не понимаю, что там [в проекте] на конфу тянет, но наверное ещё не осознал.

Саша: Ну мы удивились, что нас вообще приняли.

Мне было интересно, не пряталось ли за этим удивлением чувство самозванца, поэтому я спросил напрямую:

Никита: Вам было страшно выступать с докладом перед такой публикой?

Ваня: Было… Страшно интересно.

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

Ваня: Страха, что нас заплюют за доклад, точно не было.

Саша: Мы были готовы принять плевки… <смех>.

Формальный процесс был несложным — пришлось подать заявку и написать небольшой тезис:

Нууу, ничего особенного в этом [тезисе] не было. Запросили его после заявки вроде бы, написали мы его сильно позже, почти перед дедлайном. Старались ориентироваться на тезисы или работы прошлых лет (как и при подготовке презентации).

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

— Саша Железко

Впечатления от поездки

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

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

— Саша Железко

Хватило времени и на освоение местных технологий:

Пока шли по набережной, у нас создалось ощущение, что они собирают пух экскаватором… Я не знаю, он там просто ехал бессмысленно и, судя по опущенному ковшу, собирал пух… <смеются>

— Саша Железко

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

Саша: Мы жили прямо в центре…

Ваня: Ну не прям в центре-центре…

Саша: Южнее Красной площади, пешком примерно час. <…> Конечно, он выглядит идеально. Везде весёлые, довольные люди.

Ваня: Весёлые? Ну я видел везде покерфейсы.

Саша: Мне кажется, что для русских людей — это весёлые люди <смех>

Никита: Ну, то есть если не ревёт с булкой в руках, то уже неплохо. <смех>

Также Ваня указал на кажущиеся ему культурные противоречия города, о чём завязалась дискуссия:

Ваня: Около вокзала <…> стоит просто старое красивое здание. В нём стоит «Вкусно и точка». Ну, мне это не нравится, потому что у меня производится диссонанс. Очень красивое культурное здание, в котором стоит бездушная «Вкусно и точка».

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

Ваня: При этом мы видели на таком строительном полигоне, что разрушают старые здания тоже, какие-то купеческие, в угоду огромным <…> отелям.

Вкусно и стройка

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

Атмосфера конференции

О месте проведения ребята высказались куда более однозначно:

Мероприятие проходило в РЭУ Плеханова, ну и масштабы самого вуза не отметить нельзя. Огромное, 8-этажное, современное здание с открытым кампусом, благоустроенной территорией рядом, парками и кафешками. Вуз прямо как в фильмах, на секунду воображаешь, что ты попал в Google).

— Саша Железко

РЭУ Плеханова

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

— Егор Смирнов

Компании и люди

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

Роса оказалась неожиданно многопродуктовой — 170 человек в штате, своя графическая оболочка, свой пакетный репозиторий, свой кубер. ИСП РАН раздавали сборники научных статей — единственный стенд, который запомнился чем-то кроме буклетов.

— Саша Железко

На конференции можно было заметить завсегдатаев и других конференций, связанных с операционными системами: Георгия Курячего, Евгения Синельникова, Андрея Духвалова, Виталия Чепцова, Стаса Фомина и других.

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

На конференции мы были самые молодые. Следующие после нас — магистры, аспиранты. Всё остальное — рабочие люди за тридцать.

— Саша Железко

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

Доклады

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

Миша Чернигин: Как вам Стас Фомин, ведущий?

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

Не самая приятная черта конференции, которую отметили ребята — это полная отстранённость некоторых докладчиков:

Ваня: Первый день… это просто ужас. Чел рассказывал про процессы в KasperskyOS, у него был граф из 7 нод и он этот граф объяснял 20 минут. «Мы переходим, <медленно вздыхает>, из этого состояния в другое, таким образом…» Это было невозможно слушать, и всё это на протяжении минут 50. И потом был ещё один такой же коллега.

Саша: Примерно так же выступила женщина из ИСП РАН.

В целом, сложилось впечатление типичной конференции — где-то откровенно ужасные доклады ради формальной галочки, где-то понятный непрофессионализм в выступлении (всё-таки многие докладчики больше решают сложные задачи, чем представляют их), где-то попадаются более удачные доклады. Например, так Ваня высказался о докладе Александра Попова, который рассказывал про эксперименты с уязвимостями и средствами защиты ядра Linux с помощью kernel-hack-drill:

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

— Ваня Архипов

На конференции можно было встретить Евгения Тарана, выпускника факультета КНиИТ, сотрудника факультета и компании Базальт СПО. Он выступал с докладом «Методика технологического анализа возможностей систем реального времени на различных аппаратных платформах»:

Уровень доклада был достаточно высоким… Его было достаточно интересно слушать, да и сам доклад, похоже, имел смысл.

— Саша Железко

В целом, на конференции было достаточно интересных тем для студентов, интересующихся системным программированием:

Как приняли студентов

От команды доклад «Разработка средства нативного взаимодействия с облачными хранилищами в Linux на примере расширения файлового менеджера Nautilus» читали Ваня и Саша — запись выложил Стас Фомин.

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

Ваня и Саша на выступлении

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

О последнем и пойдёт дальше речь.

Оценка состояния образования

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

Состав круглого стола по образованию

Упадок науки и образования

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

Государство не двигает промышленность, промышленность не двигает науку, наука не двигает университет.

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

Главное зло всех зол — финансы. На образование уделяется минимальное количество ресурсов, а то малое, кому это надо.

Из всего этого можно вычленить понятные диагнозы:

денег нет;
промышленности нет;
рабочих мест нет;
а виноваты абстрактные политические проблемы.

Идей, как лечить больного, кстати, тоже нет:

Ну… Каких-то прямых рецептов не было.

— Ваня Архипов

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

Просто вот такая жизнь. Это не плохо и это не хорошо, просто вот так вот. Нам надо просто от этого как-то плясать.

Педагогика

Другая вечная тема — вовлечённость молодёжи в образование. Многие знают, что для меня это важный вопрос, и я, ещё будучи студентом, много говорил о двойной природе образования: «Без преподавателей нет студентов, без студентов нет преподавателей».

Напомню, что аудитория представляла собой преимущественно старшее поколение, поэтому, конечно, фокус сместился именно в зону ответственности студентов:

До тех пор, пока студент осознанно подходит к этому процессу, как он есть цель, и он знает, почему он это делает и зачем — образование как-то двигается.

Отдельный вопрос поставил один из участников по поводу т.н. «хвостового контингента»:

На двоечников я трачу в три раза больше времени, чем на отличников. И я бы хотел это изменить, но не знаю как.

В вопросе отстающих один из участников оказался категоричен:

Образование — это отбор, и он должен быть таким. Это как с евгеникой в Сингапуре. Вот вы умные — идите с умными. Вот вы не особо умные — вы вот другие.

Влияние LLM на образование

Главным холиваром оказалась, ожидаемо, дискуссия о больших языковых моделях в образовании. Ребята прокомментировали происходящее так:

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

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

«LLM — это просто инструмент, надо просто научиться им пользоваться»

Это была самая массовая позиция среди представителей индустрии. Её приверженцы высказывались так:

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

То же самое здесь: есть инструмент, да, которым мы можем пользоваться. Задача научить этим инструментам пользоваться правильно.

Если мы с вами полностью перекладываем ответственность на интеллект, это то же самое, что с автопилотом, будет чревато катастрофами.

— Борис Фёдоров

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

С помощью искусственного интеллекта создать что-то новое нельзя. Можно только обобщить уже известное.

— Андрей Духвалов

Там 90% кода, который [ИИ] выдаёт и он не работает. Этот код надо уметь отлаживать. И вот если человек не умеет отлаживать свой код, ну значит тогда он не состоялся как специалист. Если он умеет отлаживать и код, который написал, и умеет достичь той задачи, которую он хотел, значит, что и с помощью ИИ он состоялся, и ничего страшного в этом нет.

— Игорь Сорокин

«LLM подрывает саму возможность научиться»

Некоторые из участников конференции высказывались против LLM, аргументируя это тем, что используя эти технологии, невозможно чему-то научиться.

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

Проблема — это вот этот соблазн.

— Георгий Курячий

Люди бегут километр <…>, а если арбитр отвернулся, <…> он просто вызовет такси, доедет, <…> раз ленточку перешагнул — и всё, молодец, садись, пять. Ну так надо же следить за ним, что он реально бежит, а не на такси ездит.

— Валерий Егоров

Георгий Курячий высказал довольно неожиданное мнение, призывая не считать повальное использование LLM «нечестным путём».

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

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

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

Но не надо его называть программистом или дизайнером. За второй надо выдавать диплом решалы. Это очень важный диплом. Это очень важный человек в обществе.

До тех пор, пока мы и как академическое сообщество, и как общество не признаем, что это оба способа честные, и не начнём разделять, <…> мы всегда будем бороться против ветра.

— Георгий Курячий

Были любопытные аргументы против жёсткого контроля LLM:

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

Раньше себе такое представить было невозможно — взять, склонировать Redis и начать спрашивать, как он устроен. А теперь человек поощряется очень сильно за любопытство. Если ты это делаешь, ты уже очень сильно впереди.

Карьера в системном программировании

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

Её причины участники круглого стола находили в специфичности этого направления:

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

— Андрей Духвалов

У нас студент очень любит короткие дистанции. Заявляется курс, никакого несистемного программирования, а просто разработка под Linux.

Туда записывается 60 человек, 30 из них говорят: «Ой. И вот это вот всё нужно учить, чтобы что? Чтобы, значит, программу на C написать из шестидесяти строк? Ну его нафиг. Я лучше пойду там куда-нибудь, мне за семестр от начала до конца всё объяснят и всё начнётся». Это как-то коррелирует с понятием «путь самурая».

— Георгий Курячий

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

Также обращалось внимание на положение системного программирования в обществе:

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

— Юрий Титов

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

Надо, чтобы представители отрасли приходили, делали запрос на нужной квалификации специалистов. Он есть, но он не очень активно идёт в университеты.

Хороший системный программист будет получать много в тех же банках, но про это почему-то не говорят. <…> Эту тенденцию надо менять.

— Борис Фёдоров

Итоги

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

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

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

Не упускай возможности. Возможности повсюду.

Введение в LoRa. Meshtastic

Артём Рудяк — Tue, 12 May 2026 00:00:00 GMT

Введение

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

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

Mesh-сети могут работать поверх разных физических протоколов:

Wi-Fi (802.11s)
LoRa
Bluetooth/BLE
TCP/IP
Ethernet
UHF/VHF

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

Long Range — маломощная технология модуляции сети передачи данных со скоростью до 27 Кб/с и дальностью до 15 км (в идеальных условиях). Передача происходит в диапазоне частот, не требующих лицензии. Покрывает физический уровень передачи данных и умеет работать с геолокацией устройств.

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

LoRa

LoRa-mesh

На физическом уровне, mesh-сетью является набор нод, имеющий 3 одинаковых параметра:

Коэфициент расширения спектра (SF, Spreading factor) — параметр, определяющий длительность сигнала. Чем больше этот коэфициент, тем больше дальность передачи сигнала, его помехоустойчивость и длительность трансляции.
Центральная частота (CF, Central frequency) — средняя точка спектра, который занимает радиосигнал и вокруг которой происходит его модуляция.

Модуляция —- правила изменения параметров волны (частоты, амплитуды и др.), согласно которым производится кодировка и декодировка информации.
Диапазон частот (bandwidth) — диапазон частот, в котором происходит передача сигнала.

Эти параметры сгруппированы в пресеты, которые можно выставить при настройке ноды.

Chirp-ы и CSS модуляция

LoRa использует CSS модуляцию (chirp spread spectrum) основанную на chirp-ах — сигналах с циклически линейно-изменяющейся частотой во времени.

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

Пример LoRa сигнала. Преамбула отделяется от данных последовательностью down-chirp-ов.

Chirp-ы бывают возрастающие (увеличивающие частоту) и убывающие (уменьшающие частоту). Убывающие нужны только как разделитель между преамбулой и данными, во всех остальных случаях используются возрастающие.
Если сигнал достигает верхней грани диапазона, то происходит wrap и сигнал продолжается с нижней границы. Этот wrap является точкой разрыва, за счёт которого достигается модуляция. Место (а точнее время) расположения этого разрыва в пределах одного chirp-а кодирует символ.
Так как параметр SF определяет длительность сигнала в этом диапазоне, то он так же определяет количество возможных точек разрыва в каждом chirp. Следовательно, чем длительнее chirp, тем большим количеством бит кодируется каждый символ.

Устойчивость к помехам

Особенностью LoRa (а точнее CSS-модуляции) является способность работать при отрицательном SNR (Signal-to-Noise Ratio) — отношение мощности сигнала к мощности шума. При SF12 сигнал может быть декодирован при мощности сигнала на 20 дБ ниже уровня шума.
Это достигается за счёт применения механизма корреляции. Приёмник знает форму эталонного chirp-а (напомню, что эталонный chirp —- это циклический линейный сигнал, который задаётся тройкой параметров, рассмотренных выше).

\sum (chirp + noise) = \underbrace{\sum (chirp \times ref)}_{\propto \ T} + \underbrace{\sum (noise \times ref)}_{\to \ 0 \ \text{при} \ T \to \ \infin}

Так как шум случаен и не коррелирует с эталоном (ref), то при суммировании за длинный период положительные и отрицательные значения взаимно компенсируются. Сигнал с эталоном коррелирует сильно, поэтому результирующее значение будет расти пропорционально времени передачи сигнала.
Чем дольше транслируется один символ, тем больше энергии несёт в себе его сигнал (т.к. мощность передатчика фиксирована) и тем больше времени для того, чтобы компенсировать шум и получить результат.
В LoRa приёмник намеренно ждёт весь chirp для того, чтобы декодировать символ и отличить его от шума. Это отличает LoRa от, например, FM (frequency modulation, частотная модуляция), где информация кодируется в мгновенном значении частоты.
Однако, чем больше устойчивость к шуму, тем дольше транслируется один символ. SF12 при ширине диапазона в 125 кГц требует 32 мс для передачи одного символа.

Зависимость затрачиваемой энергии и максимального битрейта от расстояния трансляции LoRa сигнала.

Meshtastic

Принцип работы

Плата подключается к ПК или мобильному устройству с установленным клиентским приложением с помощью Bluetooth или COM-порта. При отправке пакета (сообщения) Meshtastic использует LoRa трансмиттер на плате.

Heltec v3. Одна из самых популярных плат на базе микроконтроллера серии ESP32

Когда пакет достигает ноды, она проверяет, был ли этот пакет получен ранее. Если да, то он игнорируется, в противном случае — ретранслируется дальше.
Нода имеет небольшую встроенную память, в которой хранится ~30 пакетов, полученных в то время, пока плата не подключена к клиентскому приложению. В случае переполнения этой памяти, старые пакеты затираются новыми.
Поверх радиосигнала существуют логические каналы —- группа нод, объединённые общим названием канала и симметричным ключом шифрования (PSK). Ключ хранится в памяти ноды. Количество каналов, которое нода может хранить ограничено 8. Это архитектурное решение, которое минимизирует требуемые технические характеристики устройства, пригодного для Meshtastic.

Пакет данных meshtastic

Пакет данных meshtastic передаётся в разделе данных LoRa payload. Сам пакет содержит в себе незашифрованные метаданные маршрута и зашифрованные данные приложения. Последние также закодированы в формате protobuf.
Содержимое пакета meshtastic следующее:

To — 4 байта Содержит номер ноды назначения. В случае, если пакет предназначен для всех нод, то содержит 0xFFFFFFFF
From — 4 байта
Packet ID — 4 байта Уникальный идентификатор пакета, по которому нода определяет дубликаты
Packet Flags — 1 байт
1. Hop limit — 3 бита Число оставшихся ретрансляций данного пакета. При ретрансляции нода уменьшает это значение на единицу.
2. Want Ack — 1 бит Определяет, требует ли отправитель подтвердить получение пакета нодой назначения
3. Via MQTT — 1 бит Показывает, был ли пакет запущен в mesh-сеть через MQTT.
  MQTT (Message Queuing Telemetry Transport) — легкий протокол обмена сообщениями по модели publish/subscribe. В Meshtastic используется как опциональный мост между Mesh-сетью и интернетом. Нода с доступом к Wi-Fi может пересылать пакеты из mesh в MQTT-брокер и наоборот, что позволяет объединять географически разрозненные mesh-сети через интернет.
4. Hop start — 3 бита Содержит изначальное максимальное число ретрансляций пакета. Нужен для определения количества ретрансляций между нодой отправки и назначения
Channel hash — 1 байт Показывает, к какому каналу принадлежит пакет. Данный хеш вычисляется из названия канала и его ключа шифрования. Получая пакет, нода перебирает имеющиеся в памяти ключи шифрования для расшифровки пакета.
Next hop — 1 байт При использовании механизма next-hop routing содержит адрес ноды для пересылки. Размер меньше чем поля From или To, потому что содержит в себе адрес соседней ноды, а не полный адрес в mesh-сети.

Next-hop routing — более эффективный, чем классический flood routing, механизм пересылки сообщений, появившийся в Meshtastic v2.6. Принцип его работы будет рассмотрен позже.
Relay node — 1 байт Идентификатор ноды, являющейся текущим ретранслятором.
Payload — 239 байт, зашифровано
1. Portnum — 1 байт Идентификатор порта приложения, который определяет, как интерпретировать переданные данные
2. Want Response — 1 бит Ожидается ли ответ от получателя. Нешифрованный флаг Want Ack определяет необходимость от самой mesh-сети, т.е. подтверждение доставки пакета. Данное поле определяет необходимость ответа непосредственно от ноды, например, данные о её геопозиции.
3. Reply ID — 4 байта Идентификатор сообщения, ответом к которому является текущее сообщение
4. Emoji flag — 1 бит Определяет, требуется ли интерпретировать текст внутри, как эмодзи
5. Application payload — <200 байт Содержит ключевую передаваемую информацию: текст сообщения, данные геолокации, телеметрия, обновлённые данные о ноде.
6. Bitfield — 1 байт Битовая маска с булевыми атрибутами пакета, определяемые ПО Meshtastic. Содержит, например, информацию можно ли передавать пакет через MQTT.

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

Алгоритм mesh-сети meshtastic

В документации meshtastic, сеть делится на 4 слоя:

LoRa radio
Это физический слой на котором данные кодируются в радиосигнал. Преамбула показывает начало сигнала и позволяет приёмнику понять, что в данный момент начинает транслироваться пакет. После преамбулы идёт слово синхронизации, которое позволяет отделить различные сети, транслируемые на одной частоте. Для сети Meshtastic это 0x2B. Заголовок LoRa пакета содержит информацию о длине пакета. После идёт информация о самом Meshtastic пакете, а в конце содержится CRC блок, который позволяет исправить ошибки передачи.
В данном слое система не имеет представления о пакетах, она оперирует непосредственно физическими сигналами — chirp-ами.

LoRa сигнал, состоящий из отдельных chirp-ов, внутри которого содержится Meshtastic пакет.
Ненадёжная прямая передача сообщений (Unreliable Zero Hop Messaging)
Данный слой вводит описание пакета и способа его передачи. Пакет пересылается всем соседям транслирующей ноды в зоне прямой радиовидимости. Перед отправкой пакета, нода обязана проводить CAD (Channel Activity Detection) — проверку занятости канала передачи сообщения другой нодой. В случае, если канал в данный момент занят, нода ждёт случайное время, определяемое окном конкуренции (Contention window, CW). Это время тем больше, чем более загружен в данный момент канал. За счёт этого происходит минимизация коллизий.
На данном слое система знает, что из себя представляет пакет и умеет его корректно транслировать, однако никаких гарантий того, что пакет будет доставлен, нет.
Надёжная прямая передача сообщений (Reliable Zero Hop Messaging)
Данный слой надстраивает над предыдущим механизм гарантированной доставки через флаг WantAck в заголовке пакета. Поведение различается в зависимости от типа пакета. Для DM нода-получатель отправляет ACK обратно отправителю — явное подтверждение что пакет дошёл.
Для Broadcast классический ACK неприменим: если каждая нода в сети отвечала бы подтверждением, это моментально перегрузило бы эфир.

Сообщения в Meshtastic делятся на 2 вида:
1. Broadcast — сообщения, транслируемые всем нодам в сети
2. DM (Direct messages) — сообщения, имеющие конкретную ноду-получатель.

Вместо этого, нода-транслятор прослушивает канал и в случае, если хотя бы одна другая нода начала ретрансляцию пакета, то отправитель самостоятельно генерирует implicit ACK.

Если в течение определенного таймаута отправитель не получил ни ACK, ни NAK, то с помощью предыдущего слоя будет выполнена повторная попытка трансляции пакета вплоть до 3 раз. Если повторные попытки также оказались неудачными, то отправитель генерирует NAK и прекращает трансляцию.
Многоузловая передача сообщений (Multi-hop messaging)

Как было сказано ранее, в случае Broadcast сообщений, нода ретранслирует их вплоть до истечения Hop Limit. В случае, если какое-то сообщение уже ретранслируется другой нодой, то текущая проигнорирует это сообщение и не станет его ретранслировать, чтобы не перегружать эфир. Такой подход называется управляемым флудингом (Managed flooding).
Для DM используется упомянутый ранее алгоритм Next-hop routing. Принцип его работы проиллюстрирован ниже.

Принцип работы алгоритма next-hop routing.

Первый пакет от ноды A до ноды D отправляется с помощью managed flooding. Если пакет успешно доставлен и вернулся ACK, при этом вернулся он через ту же ноду, которая участвовала в изначальной передаче пакета, то она запоминается для этого маршрута.
Таким образом, при отправке последующих пакетов по тому же адресу они будут транслироваться не всем нодам в радиусе покрытия радиосигнала, а конкретной ноде, чтобы уменьшить зашумление эфира. При этом такой маршрут определяется при каждой трансляции пакета. В случае, если не получилось доставить пакет с помощью next-hop routing, то выполняются стандартные 3 повторные попытки. По их истечению пакет транслируется через managed flooding.

Зависимость CW от SNR и косвенное вычисление расстояния

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

Да, Meshtastic может работать с данными геопозиции, но во-первых, это дополнительные данные, которые нужно хранить, а во-вторых, не все ноды по умолчанию идут с предустановленным GPS-модулем.

Косвенным индикатором расстояния служит SNR. Напомню, что SNR — это параметр, показывающий отношение мощности сигнала к мощности постороннего шума. Мощность шума примерно постоянна, а мощность сигнала падает с расстоянием из-за затухания в свободном пространстве — значит SNR тем ниже, чем дальше нода от источника.
Чтобы использовать это без явного обмена значениями SNR между нодами размер окна конкуренции (CW) привязана к параметру SNR напрямую. Чем меньше SNR, тем меньше CW, тем раньше нода начнёт ретрансляцию. Таким образом, дальняя нода статистически раньше начнёт ретрансляцию, чем ближняя.

Источники

Он вам не JavaScript!

Роберт Толстов — Sat, 26 Apr 2025 00:00:00 GMT

Дисклеймер!

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

В рамках лекции мы узнаем:

Как появился один из самых языков программирования
За что его не любит большинство разработчиков
Плохой ли JS язык программирования?

Люблю и ненавижу

JavaScript — это уникальный язык. Его не любят, но тем не менее повсеместно используют.

Но почему? За что вообще не любят JS? Почему JS получился таким, какой он есть? К чему может привести неопределённое поведение? Какие языки могут заменить JS? Это и многое другое мы обсудим сегодня!

Немного статистики

JS держит крепкие позиции в большинстве рейтинг-листов.

И это неудивительно: дальше мы узнаем, что JS настоящий монополист в мире фронтенда.

Итак, перейдём к краткой исторической справке.

Краткая историческая справка

Предыстория

В середине 1990-х годов, в период бурного развития интернет-технологий, компания Netscape Communications, создатель популярного веб-браузера Netscape Navigator, столкнулась с необходимостью расширения функциональности веб-страниц. Существовавшие на тот момент технологии не позволяли реализовать интерактивность на стороне клиента, что ограничивало возможности веб-разработки. Анимации и всё прочее также были недоступны.

Предпосылки создания нового языка

Марк Андриссен, сооснователь Netscape, выдвинул концепцию «динамического HTML», требовавшую создания скриптового языка, который:

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

Первоначально рассматривались существующие языки (Python, Tcl, Scheme), но они не соответствовали всем требованиям. В частности, Scheme, несмотря на свою элегантность, имел синтаксис, слишком отличающийся от распространённых языков программирования. Всё-таки, не стоит забывать, что это диалект Lisp :)

С другой стороны, в то время Sun Microsystems активно разрабатывали Oak (ныне и далее в тексте — Java). И Netscape Communications активно сотрудничала с Sun, что в итоге привело к большому воздействию Java на финальную версию JavaScript.

Возможно, возникает закономерный вопрос: почему бы в таком случае не взять Java как язык для браузеров? Ответ очевиден — вернитесь к 4 пункту.

Первый прототип

Брендан Айк, на тот момент сотрудник Netscape, получил задание создать прототип языка за крайне сжатые сроки. Конечно, с такими дедлайнами и таким смутным временем (а мы помним, что во время гонки браузеров была проблема с единообразием), получилась максимальная несуразица. Это была первая версия языка JavaScript. Работа над ней велась с мая по декабрь 1995 года.

Название ему выбрали максимально подходящее — Mocha. И уже с самого первого релиза он показал себя во всей красе.

По итогу внешне вышло что-то похожее на Java из-за сделки с Sun, а внутри — Scheme с прототипным наследованием (далее будет рассказано подробнее, что это значит).

Что будем делать с названием Mocha

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

Mocha (рабочее название) → LiveScript (при первом включении в Netscape Navigator)
LiveScript → JavaScript (из-за сделки с Sun)

Фундаментальные грехи

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

Приведение типов

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

Арифметические операции

'4' + 2; // "42" (2 -> "2")
'4' - 2; // 2    ("4" -> 4)
'4' * '2'; // 8    ("4" -> 4, "2" -> 2)
'4' / '2'; // 2    ("4" -> 4, "2" -> 2)
'4' ** '2'; // 16   ("4" -> 4, "2" -> 2)

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

Арифметические операции 2: возвращение

А сейчас я достаю из чертогов JS самое жуткое и до конца не изученное явление — сумма нематематических объектов.

Сначала примеры — а потом объяснения:

[] + []   // ""

[] + {}   // "[object Object]"

{} + []   // 0, а в console.log "[object Object]"

{} + {}   // NaN,
          // а в console.log "[object Object][object Object]"

Почему так происходит и мы получаем такие странные ответы? Дело в том, что под капотом JS происходят интересные процессы преобразования объектов по строго определённому алгоритму:

Symbol.toPrimitive() если есть
valueOf()
toString()

В конце него он гарантированно получит примитив (число, булево или строку). С ними уже можно оперировать.

Возвращаясь к примерам выше, уже не кажется магией некоторые преобразования:

[] + []   // [] -> "", [] -> "", "" + "" = ""

[] + {}   // [] -> "", {} -> "[object Object]",
          // "" + "[object Object]" = "[object Object]"

{} + []   // Смотри объяснение ниже.

{} + {}   // {} -> "[object Object]", {} -> "[object Object]",
          // "[object Object]" + "[object Object]" =
          // "[object Object][object Object]"

Ну а как это объясняет {} + []?

Да никак, это JavaScript. Это ошибка парсера: иногда, если действовать не через console.log, то он иногда может интерпретировать {} + [] как {} -> undefined и +[] -> 0 как унарный плюс. И тут важно понимать: +[] это именно унарная операция, а не undefined + 0.

Вау, а если попробовать пооперировать над массивами и числами?

[] - 1; // -1 ([] -> 0)
{
}
-(1)[5] * // NaN ("[object Object]" - 1 -> NaN)
  [2][(1, 2)] - // 10 ([5] -> 5)
  [3, 4]; // NaN ([1, 2] -> "1, 2")

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

+[] + // 0 ([] -> "" -> 0)
  {} - // NaN ({} -> "[object Object]" -> NaN)
  [] - // -0 (-0 === 0)
  {}; // NaN

Здесь всё просто, срабатывает обычное преобразование в Number.

Зная алгоритм выше, нетрудно догадаться, каким результатом обернутся операции над null, NaN, undefined. Не будем для краткости на них заостряться.

Прототипное наследование

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

Объектная модель

Да, в JS есть объекты (их ещё называют прототипами — отсюда и название парадигмы). Для того, чтобы как-то объединять их в группы наподобие классов, у каждого объекта есть скрытое свойство [[Prototype]], доступ к которому мы можем получить через __proto__:

const Animal = { eats: true };
const Rabbit = { jumps: true };

Rabbit.__proto__ = Animal; // теперь Animal — "родитель" Rabbit

console.log(Rabbit.eats); // true

При обращении к какому-то полю объекта, JS проверит его наличие в объекте, затем в его [[Prototype]]. Процесс повторяется до последнего прототипа, иначе такого поля нет.

const Animal = { eats: true };
const Rabbit = { jumps: true, __proto__: Animal };
const Richard = { owner: 'Robert', __proto__: Rabbit };

console.log(Richard.eats); // Richard.__proto__.__proto__.eats

Современные прототипы

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

const Animal = { eats: true };

const Rabbit = Object.create(Animal);
console.log(Rabbit.eats); // true
console.log(Object.getPrototypeOf(Rabbit) === Animal); // true

Object.setPrototypeOf(Rabbit, { jumps: true });
console.log(Rabbit.jumps); // true

В чём проблема прототипов?

Конечно, можно сказать, что это не похоже на ООП, не интуитивно и т.п., но лично мне так не кажется. Для меня основной проблемой является отсутствие какой-либо приватности у полей объектов:

const Secret = {
  _token: 696969,
};

console.log(Secret._token); // Иллюзия безопасности

А как же классы?

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

class Animal {
  constructor(name) {
    this.name = name;
  }

  speak() {
    console.log(`${this.name} makes noise`);
  }
}

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

Работа с `for`

На самом деле, «подводных камней» достаточно много, но они все лежат примерно на поверхности. Я бы хотел осветить один пример относительно неочевидного поведения:

const animal = { eats: true };
const rabbit = { jumps: true, __proto__: animal };

for (let prop in rabbit) {
  console.log(prop); // jumps, eats
}

Object.keys(rabbit); // ['jumps']

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

Будьте бдительны с этим!

Синтаксический сахар. Целый завод

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

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

Топ-8 способов задать функцию

В JS вы можете задать функцию целой кипой способов:

function aboba(x) { return x }
aboba = function(x) { return x }
aboba = new Function('x', 'return x')
aboba = Function('x', 'return x')
aboba = (x) => { return x }
aboba = (x) => (x)
aboba = x => x
aboba = Object.assign(new Function, { ... })

Первые два способа самые обыкновенные — function declaration и function expression соответственно.

Далее мы создаём функцию через конструктор. Это интересный способ, однако практического смысла он не несёт. Мы также можем создать её и без new, что ещё более абсурдно, ведь какой тогда смысл в new? На самом деле, различие лишь в том, что в первом случае мы явно вызываем конструктор Function, а во втором — неявно.

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

Последний способ для извращенцев. Мы создаём функцию, конвертируем её в объект и добавляем свойства, которые нам нужны. Как результат — модифицированная функция с добавленными свойствами.

И да, функция может являться объектом и может обладать собственным контекстом this, что также добавляет большую неоднозначность. Есть ли у нас контексты функций, скажем, в C++? В Rust? В Go? В Python… а, в Python есть кстати. Не сказал бы, что это его красит.

Экосистема JS и ленивые программисты

Пока вы читаете эту главу, в мире было написано по меньшей мере 13 библиотек на JS.

Гайд как сломать весь Интернет в 11 строчек кода

В марте 2016 года мир JavaScript пережил один из самых громких кризисов в своей истории — падение экосистемы из-за удаления крошечной библиотеки left-pad.

Что это вообще такое? Это маленькая библиотека, написанная Азером Кочулу, которая занимает 11 (всего!) строчек кода и просто дополняет строку пробелами слева:

module.exports = leftpad;
function leftpad(str, len, ch) {
  str = String(str);
  var i = -1;
  if (!ch && ch !== 0) ch = ' ';
  len = len - str.length;
  while (++i < len) {
    str = ch + str;
  }
  return str;
}

Не кажется ли вам, что этот код можно написать самому за пару минут? Мне тоже так кажется, однако разработчики Babel и React со мной не согласятся. Тысячи проектов использовали эту библиотеку, устанавливая её через npm.

Однако Азер Кочулу в один момент решил просто удалить все свои 273 модуля из npm. Он же имеет на это право? Ну да, имеет. Кто-то от этого застрахован? Нет, никто.

В 11:00 UTC left-pad пропал из реестра npm, что повлекло за собой поломку сборок React, Babel, ESLint и других инструментов. Тут же были остановлены деплои крупнейших компаний, таких как Netflix и Bloomberg.

И по такому случаю, через 2.5 часа, впервые в истории npm откатывает удаление библиотеки и вводит новое правило на удаление пакетов (вернее, запрет на их удаление).

Но как так получилось? Проблема в глубокой вложенности зависимостей:

react -> babel-preset-react -> babel-preset-es2015 -> babel-plugin-transform-es2015-modules-commonjs -> left-pad

После такой ситуации Азер Кочулу ушёл из JS-сообщества, а его аккаунт на Github и npm забанили на несколько месяцев. В Twitter запустили флешмоб #SaveThePad, начали появляться пародийные пакеты, как, например, fck-left-pad — реализация в 1 строчку.

И всё это из-за 11 строчек…

Не изобретай велосипед

Вы скажете: «ну и как эта история связана с проблемой экосистемы? Не нужно было ставить непопулярные пакеты».

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

Страшнее другое — на полном серьёзе в npm есть библиотеки:

is-even: проверка числа на чётность
is-odd: проверка числа на нечётность
empt: проверка массива на пустоту
is-positive-integer: проверка числа на положительность
array-index: возвращает индекс элемента в массиве
is-ice-cream: проверка на то, что строка содержит вкус мороженого

И если вам кажется, что их никто не использует в проде, то вспомните историю выше. Я почти уверен, что люди скачивают их не только забавы ради. Да, кстати, у библиотеки is-even больше 200 000 недельных скачиваний. Стоит задуматься, а умеем ли мы вообще программировать…

Как не стать жертвой абсурда

npm ls --depth=5

решит все ваши проблемы. Будьте осторожнее с пакетами в JS.

Альтернативные решения

Были попытки спасти JS. Это могут быть как его расширения, так и совсем другие языки. Об этом и поговорим в данной главе.

TypeScript

Надмножество JS со статической типизацией. Из плюсов можно отметить полную совместимость с JS (можно постепенно мигрировать). Из минусов — типы пропадают в рантайме, так как TS нужно компилировать в JS.

WebAssembly (WASM)

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

Например, в языке Rust есть фреймворк Leptos — прекрасное решение для высоконагруженных и максимально отзывчивых элементов приложения, таких как 3D-рендер или сложная анимация.

Не заменяет JS полностью (обычно используется вместе).

Dart

Изначально писался как замена JS, однако не прижился и теперь дружит с Flutter. Вместе они позволяют писать кроссплатформенные приложения.

Elm

Хорошая попытка создать убийцу JS. Достаточно быстрый язык, со строгой типизацией. Однако у него слишком высокий порог входа из-за сложного синтаксиса (мне напомнил Haskell).

Всё это — ошибка

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

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

Заключение расследования

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

Возможно, он где-то повернул не туда, а может где-то сказалось влияние грехов при первой разработке, но тем не менее я не могу придумать хорошую альтернативу JS, которая бы была на порядок лучше него (кроме TS).

SEO-оптимизация SPA

Роберт Толстов — Sat, 15 Mar 2025 00:00:00 GMT

Что такое SEO?

Search Engine Optimization — это процесс оптимизации сайта (а в нашем случае веб-приложения) для улучшения его видимости в поисковых системах.

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

Процесс поисковой индексации можно разделить на три этапа:

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

А зачем вообще SEO?

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

По каким метрикам определяется релевантность ресурса?

Технические метрики

К этому типу относятся:

Скорость загрузки.
Адаптивность: например, движок Google использует mobile-first подход, то есть мобильная версия приоритетнее.
Доступность для индексации: наличие robots.txt, sitemap.xml, canonical-ссылок и т.д.
Структура и читаемость URL.

Контентные метрики

Важно содержимое сайта. К этим метрикам относятся:

Ключевые слова и семантика: например, если пользователь ищет «купить iPhone 15», роботы проверяют наличие этих слов в <title>, <h1>, <meta name="description"> и основном тексте.
Уникальность контента.
Доступность для пользователей: использование alt-атрибутов для изображений, aria-атрибутов.

Для продвинутых существует микроразметка. Пример для запроса с iPhone 15:

<script type="application/ld+json">
  {
    "@context": "https://schema.org/",
    "@type": "Product",
    "name": "iPhone 15",
    "description": "Новый iPhone 15 с улучшенной камерой.",
    "brand": {
      "@type": "Brand",
      "name": "Apple"
    }
  }
</script>

Поведенческие метрики

Эти метрики связаны с тем, как пользователи взаимодействуют с сайтом:

Время на сайте: чем дольше пользователи остаются, тем выше релевантность.
Показатель отказов.
Глубина просмотра: пользователи должны просматривать несколько страниц за визит.
CTR (Click-Through Rate): высокий CTR в поисковой выдаче указывает на релевантность заголовка и описания страницы.

Внешние метрики

Эти метрики связаны с авторитетностью сайта и его популярностью в интернете:

Обратные ссылки: чем больше качественных ссылок с авторитетных сайтов (например, Forbes или Wikipedia), тем выше релевантность.
Доверие домена: например, хостинг на GitHub Pages повышает доверие и шансы на высокую позицию в выдаче.

Что такое SPA?

Single Page Application — современный подход к написанию веб-приложений, который становится всё популярнее из-за простоты и скорости разработки и поддержки.

Суть в следующем: приложение загружает одну HTML-страницу без значимого контента, а затем её содержимое динамически изменяется по мере взаимодействия с пользователем.

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

Готовь сани летом…

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

Server-Side Rendering (SSR)

Теория

Основная проблема SPA — отсутствие контента на старте страницы. Многие поисковые роботы плохо исполняют JavaScript, из-за чего страница индексируется в том виде, в котором она «скормлена» роботу:

<!DOCTYPE html>
<html>
  <head>
    <!-- Какие-то стили -->
  </head>
  <body>
    <div id="root"></div>
    <script src="index.js"></script>
  </body>
</html>

Непонятно, как определить, релевантен ли ресурс пользователю.

Отступление о мета-тегах

Можно задать вопрос: почему бы не добавить мета-теги в <head>? Ведь он есть, и можно просто отредактировать app.html?

Это имеет смысл и сработает, но только если у вас действительно одна страница. Мета-теги должны быть актуальны для каждой страницы.

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

Вернемся к проблеме пустой страницы. Текущая схема работы SPA:

Как получить контент сразу, не дожидаясь полной загрузки страницы? Отличное решение — шаблонизаторы, но для SPA используется SSR.

Создадим сервер-посредник между бэкендом и клиентом. Метафреймворк будет взаимодействовать с сервером. Схематично:

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

Как имплементировать в React?

Самый популярный выбор — Next.js. Это стабильное решение, которому доверяют крупные проекты.

Next.js предоставляет два типа компонентов: 'use server' для серверных и 'use client' для клиентских. Серверные компоненты имеют доступ к функции getServerSideProps(context), которая позволяет взаимодействовать с API и возвращать данные с бэкенда.

Этот подход удобен для работы с cookies или управления кэшированием.

Примеры:

Пример 1: простая передача данных через props

export async function getServerSideProps(context) {
  const res = await fetch('https://abaunda.org/post/69');
  const data = await res.json();

  return {
    props: {
      data,
    },
  };
}

export default function Page({ data }) {
  return (
    <div>
      <h1>Данные с сервера:</h1>
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </div>
  );
}

Пример 2: манипуляция заголовками запросов

export async function getServerSideProps(context) {
  const userAgent = context.req.headers['user-agent'];
  return {
    props: {
      userAgent,
    },
  };
}

Пример 3: манипуляция заголовками ответов

export async function getServerSideProps(context) {
  context.res.setHeader('Cache-Control', 'public, s-maxage=10, stale-while-revalidate=59');
  const res = await fetch('https://abaunda.org/post/69');
  const data = await res.json();

  return {
    props: {
      data,
    },
  };
}

Static Site Generation (SSG)

Теория

SSR хорош для динамических приложений, но если контент меняется редко (например, блоги или лендинги), SSR может быть избыточным.

Зачем рендерить сложное приложение каждый раз, если содержимое не меняется? Разумнее собрать проект в статические HTML-страницы, которые отправляет сервер. Это и есть Static Site Generation (SSG).

Главное преимущество SSG — экстремально высокая скорость работы. Однако для динамических приложений лучше использовать SSR.

Как имплементировать в React

Next.js поддерживает SSG через функцию getStaticProps(), которая выполняется на этапе сборки приложения.

Пример использования:

export async function getStaticProps() {
  const res = await fetch('https://abaunda.org/posts');
  const posts = await res.json();

  return {
    props: {
      posts,
    },
  };
}

export default function Blog({ posts }) {
  return (
    <div>
      <h1>Блог</h1>
      <ul>
        {posts.map(post => (
          <li key={post.id}>{post.title}</li>
        ))}
      </ul>
    </div>
  );
}

SSR + SSG

Некоторые фреймворки, включая Next.js, позволяют комбинировать SSR и SSG в одном проекте для гибкости. Всё зависит от того, как вы описываете компоненты.

Incremental Static Rendering (ISR)

Для случаев, когда данные нужно обновлять чаще, но SSR кажется сложным, Next.js поддерживает ISR для SSG через параметр revalidate:

export async function getStaticProps() {
  const res = await fetch('https://abaunda.org/posts');
  const posts = await res.json();

  return {
    props: {
      posts,
    },
    revalidate: 10, // Пересобирать страницу каждые 10 секунд
  };
}

export default function Blog({ posts }) {
  return (
    <div>
      <h1>Блог</h1>
      <ul>
        {posts.map(post => (
          <li key={post.id}>{post.title}</li>
        ))}
      </ul>
    </div>
  );
}

Страница будет пересобираться каждые 10 секунд в фоновом режиме.

Динамические мета-теги

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

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

До React 19

Для динамического управления мета-тегами используется библиотека react-helmet. Пример:

import { Helmet } from 'react-helmet';

export default function Post({ post }) {
  return (
    <div>
      <Helmet>
        <title>{post.title}</title>
        <meta name="description" content={post.description} />
        <meta property="og:title" content={post.title} />
        <meta property="og:description" content={post.description} />
        <meta property="og:image" content={post.image} />
      </Helmet>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </div>
  );
}

Это простой и проверенный способ. Для SSR рекомендуется использовать форк react-helmet-async, который требует обёртывания в специальный провайдер.

React 19

В React 19 добавлена встроенная поддержка динамических мета-тегов. Пример:

export default function Post({ post }) {
  return (
    <div>
      <title>{post.title}</title>
      <meta name="description" content={post.description} />
      <meta property="og:title" content={post.title} />
      <meta property="og:description" content={post.description} />
      <meta property="og:image" content={post.image} />
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </div>
  );
}

Мета-теги могут сделать компонент «грязнее». Если это беспокоит, можно использовать фрагмент или react-helmet.

Важно! Убедитесь, что используется React 19 или выше, иначе мета-теги окажутся в корневом компоненте, а не в <head>, и роботы их не прочтут.

Next.js (предпочтительный способ)

Next.js имеет встроенный компонент <Head>, аналогичный react-helmet, но нативный и не требующий дополнительных библиотек. Пример:

import Head from 'next/head';

export default function Post({ post }) {
  return (
    <div>
      <Head>
        <title>{post.title}</title>
        <meta name="description" content={post.description} />
        <meta property="og:title" content={post.title} />
        <meta property="og:description" content={post.description} />
        <meta property="og:image" content={post.image} />
      </Head>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </div>
  );
}

Что-то ещё?

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

`robots.txt`

Файл robots.txt указывает поисковым роботам, какие страницы можно сканировать, а какие нет. Удобно для скрытия админ-панели или страниц в разработке.

Пример:

User-agent: *
Allow: /
Disallow: /admin
Sitemap: https://abaunda.org/sitemap.xml

User-agent: * — правила для всех роботов.
Allow и Disallow — разрешённые и запрещённые для обхода адреса.
Sitemap — ссылка на карту сайта.

Поместите файл в public/ или static/ для прямого доступа по https://abaunda.org/robots.txt.

`sitemap.xml`

Файл sitemap.xml содержит список всех страниц для индексации. Для React/Next.js рекомендуется библиотека next-sitemap.

После установки в next-sitemap.config.js:

module.exports = {
  siteUrl: 'https://abaunda.org',
  // generateRobotsTxt: true, // Генерация robots.txt
};

В package.json добавьте:

"scripts": {
  "postbuild": "next-sitemap"
}

После сборки проекта будет создан sitemap.xml.

Семантическая вёрстка и атрибуты доступности `aria`

Не забывайте о семантической вёрстке и атрибутах aria для повышения доступности и SEO.

Введение в Docker (2 часть)

Артём Кудяков — Sat, 01 Mar 2025 00:00:00 GMT

Репозиторий на Github с примерами кода: https://github.com/dsc-sgu/docker-lecture-part2

Деплой приложения на сервер

Для начала необходимо создать ssh-ключ, который позволит нам подключиться к VDS-хостингу.

ssh-keygen

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

Сборка образа

docker build -t app:0.1 .

Сохраняем образ в архив

docker save app:0.1 > app.tar

Загружаем образ на сервер

scp ./app.tar user@server:/path/to/destination

Подключаемся к серверу

ssh user@server

Загружаем образ из файла

docker load < app.tar

Копируем docker-compose (прописав в него название образа, загруженного из файла). И запускаемся:

nvim docker-compose.yaml
docker compose up -d

Поздравляем! Мы запустились! Теперь можем проверить, что всё работает, с компьютера клиента

curl http://server:port/products

Эксперименты над Dockerfile’ом сервиса на Go

Для начала втупую скопируем все файлы проекта, после чего запустим процесс компиляции.

FROM golang:1.23-alpine as builder

WORKDIR /app
COPY . .
RUN go build -o ./main main.go

FROM alpine:3.20
COPY --from=builder /app/main /app/main

ENTRYPOINT ["/app/main"]

Попробуем собрать наш образ:

docker compose build app

Всё хорошо, но давайте теперь модифицируем наш код:

nvim main.go

Попробуем собрать наш образ ещё раз:

docker compose build app

Как мы можем заметить, наши зависимости начали скачиваться заново.

Теперь напишем наш Dockerfile по-другому:

FROM golang:1.23-alpine as builder

WORKDIR /app
COPY go.mod go.sum .
RUN go mod download

COPY . .
RUN go build -o ./main main.go

FROM alpine:3.20
COPY --from=builder /app/main /app/main

ENTRYPOINT ["/app/main"]

Соберём:

docker compose build app

Попробуем снова модифицировать наш код:

nvim main.go

И опять соберём образ:

docker compose build app

Теперь мы не скачиваем зависимости заново.

Разница между shell- и exec-режимами

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

CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Но разве нельзя просто записать команду строкой? На самом деле можно. Давайте так и сделаем.

CMD uvicorn main:app --host 0.0.0.0 --port 8000

Выглядит лаконично, но есть нюанс.

Давайте для простоты сделаем специальный Dockerfile, на котором мы посмотрим разницу между shell- и exec-режимами.

FROM alpine:3.20
CMD ["ping", "ya.ru"]

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

docker build -t aboba:1.0 .
docker run aboba:1.0
docker ps  # Смотрим ID контейнера
docker exec <ID-контейнера> ps

PID   USER     TIME  COMMAND
    1 root      0:00 ping ya.ru
    6 root      0:00 ps

Мы наблюдаем 2 процесса. Один процесс — это команда ps. Он тут есть в целом по понятным причинам. А вот другой процесс — это команда ping, которую мы прописали в Dockerfile. Поскольку ps обычно отрабатывает и завершает свою работу, фактически в нашем контейнере работает только один процесс — ping. Более того, он имеет PID = 1. Этот факт нам понадобится дальше, когда мы перепишем Dockerfile в shell-режиме:

FROM alpine:3.20
CMD ping ya.ru

Давайте теперь соберём и запустим наш контейнер:

docker build -t aboba:2.0 .
docker run aboba:2.0
docker ps  # Смотрим ID контейнера
docker exec <ID-контейнера> ps

И получим… Тоже самое?

PID   USER     TIME  COMMAND
    1 root      0:00 ping ya.ru
    7 root      0:00 ps

Окей. А тогда в чём же разница? Давайте попробуем заменить Alpine на Debian:

FROM debian:12.9
RUN apt-get update -y
RUN apt-get install -y iputils-ping
RUN apt-get install -y procps
CMD ping ya.ru

Собираем и запускаем:

docker build -t aboba:2.0 .
docker run aboba:2.0
docker ps  # Смотрим ID контейнера

# Введём флаг -ef, чтобы видеть ID родительнского процесса (PPID)
docker exec <ID-контейнера> ps -ef

А вот тут уже есть какие-то различия в списке процессов:

UID          PID    PPID  C STIME TTY          TIME CMD
root           1       0  0 05:28 ?        00:00:00 /bin/sh -c ping ya.ru
root           7       1  0 05:28 ?        00:00:00 ping ya.ru
root          20       0 75 05:29 ?        00:00:00 ps -ef

Что мы видим?

Процессом с PID = 1 является /bin/sh, а не ping.
ping имеет PID равный 7.
Кроме того, его PPID равен 1, а это значит, что /bin/sh

является родительским процессом для ping.

Что же будет, если мы попробуем остановить контейнер, послав сигнал SIGINT при помощи Ctrl+C?

Контейнер, созданный из образа aboba будет завершён.
Контейнер, созданный из образа aboba2 аналогично.
А вот aboba3 будет игнорировать наши попытки его завершить

(именно так и начинается Skynet).

Чтобы понять, в чём разница, мы взглянем на вывод команды docker inspect aboba и docker inspect aboba3. Эти команда нам распечатают JSON, в котором содержится метаинформация про наши образы. Там много любопытной информации, проливающей свет на то, как Docker устроен, но нас интересуют конкретные несколько строк:

docker inspect aboba

[
  {
    ...
    "Config": {
      ...
      "Cmd": ["ping", "ya.ru"],
      ...
    }
    ...
  }
]

docker inspect aboba3

[
  {
    ...
    "Config": {
      ...
      "Cmd": ["/bin/sh", "-c", "ping ya.ru"],
      ...
    }
    ...
  }
]

Как мы можем наблюдать, у нас по-разному запускается наш ping. В первом случае он запускается напрямую. Во втором же случае он запускается через /bin/sh. Собственно поэтому он и является родительским процессом для ping. И именно поэтому сигналы до процесса ping не доходят, ведь в Docker’е сигналы, посланные контейнеру, всегда идут до процесса с PID = 1, которым в aboba3 является /bin/sh.

Но что же с aboba2? Давайте тоже для него запустим docker inspect aboba2:

[
  {
    ...
    "Config": {
      ...
      "Cmd": ["/bin/sh", "-c", "ping ya.ru"],
      ...
    }
    ...
  }
]

И мы получаем то же самое… Но почему же мы получаем то же поведение, что и у aboba? Я задался таким же вопросом, когда готовился к этой лекции. Для изучения этой темы я решил воспользоваться статьёй на Хабер за 2017 год: https://habr.com/ru/companies/slurm/articles/329138/

Сама по себе статья хорошая, однако, она оказалось немного неактуальной для новых версий Alpine. Дело в том, что Alpine вместо стандартного пакета GNU Coreutils использует BusyBox. При чём, видимо модифицированный, поскольку в других дистрибутивах, где используется BusyBox, поведение sh было больше похоже на образ aboba3. Скорее всего, разработчики Alpine, нацеленные на пользователей Docker, решили модифицировать оболочку командной строки, чтобы она не имела тех багов, которые возникают с aboba3.

Тем не менее, несмотря на то, что в Alpine shell-форма не имеет тех багов, которые есть в Debian, всё же разработчики Docker рекомендуют использовать exec-форму.

Разница между CMD и ENTRYPOINT

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

FROM alpine:3.20
CMD ["echo", "Hello, World!"]

$ docker build -t hello-world-image:1.0 .
$ docker run hello-world-image:1.0
Hello, world!

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

$ docker run hello-world-image:1.0 echo "Aboba"
Aboba

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

FROM alpine:3.20
ENTRYPOINT ["echo", "Hello, World!"]

$ docker build -t hello-world-image:2.0 .
$ docker run hello-world-image:2.0
Hello, world!

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

$ docker run hello-world-image:2.0 echo "Aboba"
Hello, World! echo Aboba

Как мы видим, при использовании ENTRYPOINT переопределяется не вся команда, а только её аргументы. Это может быть удобно, если ваша программа принимает какие-либо аргументы.

При этом мы всё ещё можем переопределить команду, которая будет выполнена при запуске контейнера, используя флаг --entrypoint:

docker run --entrypoint ps hello-world-image:2.0

PID   USER     TIME  COMMAND
    1 root      0:00 ps

ENTRYPOINT + CMD

Мы можем использовать CMD для указания аргументов по умолчанию, которые будут переданы в ENTRYPOINT:

FROM alpine:3.20
ENTRYPOINT ["echo"]
CMD ["Hello, world!"]

В таком случае по-умолчанию команде echo в качестве аргумента будет передаваться строка Hello, world!. Однако, если мы укажем другой аргумент, он заменить аргумент, прописанный CMD.

$ docker build -t hello-world-image:3.0 .
$ docker run hello-world-image:3.0
Hello, world!
$ docker run hello-world-image:3.0 Aboba
Aboba

Конфигурирование приложений в Docker при помощи переменных окружения

Одним из самых частых способов для конфигурации приложения является использование переменных окружения. Давайте напишем небольшой проект на Python, который будет считывать переменные окружения DB_URL и API_KEY выводить их на экран. Для управления зависимостями мы будем использовать uv.

uv init example1
cd example1
uv add pydantic pydantic-settings python-dotenv

from pydantic_settings import BaseSettings, SettingsConfigDict
from time import sleep


class Settings(BaseSettings):
    db_url: str
    api_key: str

    model_config = SettingsConfigDict(env_file=".env", env_file_encoding="utf-8")


def main():
    settings = Settings()
    print(settings, flush=True)

    while True:
        sleep(1)


if __name__ == "__main__":
    main()

Здесь мы использовали библиотеки pydantic и python-dotenv. Первая позволяет производить валидацию нашей конфигурации, а вторая позволяет записывать значения переменных окружения из файла .env. Как правило, это делается для удобства разработчика, чтобы ему не пришлось постоянно вводить эти переменные в терминале. Впрочем, если .env файла нет, python-dotenv будет считывать значения, что называется, «по-старинке» из непосредственно переменных окружения. Этот факт нам пригодится позже.

Напишем Dockerfile для нашего приложения (данный файл можно улучшить, но это мы рассмотрим позже):

FROM python:3.13-slim AS builder
COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/
ADD . /app
WORKDIR /app
RUN ["uv", "sync", "--frozen"]
CMD ["uv", "run", "main.py"]

Теперь напишем .env файл:

DB_URL=aboba
API_KEY=aboba

Соберём и запустим наш образ:

docker build -t config-example:1.0 .
docker run config-example:1.0

Что ж, наше приложение работает!

db_url='aboba' api_key='aboba'

Однако есть несколько проблем:

Мы в образ копируем директорию .venv, которая создана на хостовой машине.

Это проблема по двум причинам:

Операционная система на хостовой машине и в контейнере могут отличаться.

А поскольку помимо зависимостей на Python у нас могут быть и бинарные зависимости, это может привести к проблемам. (Впрочем, если мы посмотрим внимательно на логи, uv автоматически удаляет случайно скопированное нами виртуальное окружение и создаёт своё. Но так происходит не всегда, особенно если не использовать uv).

.venv может весить очень много (например, в больших проектах или проектах,

использующих ML-библиотеки) => копирование будет происходить долго. Мы просто тратим время на операции, которые нам не нужны. В любом случае, нам нужно создавать своё виртуальное окружение для образа.

Также мы копируем .env файл в наш образ. Это уже проблема в безопасности.

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

Мы копируем кэш-файлы и папки, по типу __pycache__. Как и .venv, кэши

являются платформозависимыми и не должны быть включены в образ по тем же причинам.

Если вы используете Git и директория .git находится в корне проекта, то

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

Мы бы могли модифицировать команду ADD в Dockerfile, например, используя регулярные выражения или вручную прописав все необходимые для копирования файлы. Но есть более удобный способ исключить из копирования ненужные файлы — .dockerignore файл. Он работает аналогично тому, как работает .gitignore. В .dockerignore файле можно указать паттерны файлов и директорий, которые не должны быть скопированы в образ. Создадим .dockerignore файл в корне проекта:

.gitignore
.git
.venv
__pycache__
.env

Давайте снова соберём и запустим наш образ:

docker build -t config-example:2.0 .
docker run config-example:2.0

И теперь наше приложение не работает:

...
pydantic_core._pydantic_core.ValidationError: 2 validation errors for Settings
db_url
  Field required [type=missing, input_value={}, input_type=dict]
    For further information visit https://errors.pydantic.dev/2.10/v/missing
api_key
  Field required [type=missing, input_value={}, input_type=dict]
    For further information visit https://errors.pydantic.dev/2.10/v/missing

А вот как исправить эту ошибку, вы узнаете в 3 части этой лекции.

Как Linux рисует окна?

Артём Кудяков — Sun, 06 Oct 2024 00:00:00 GMT

Вступление

Уже давно в Linux-сообществе ведутся горячие дискуссии о том, когда Wayland заменит Xorg. Однако далеко не все ясно понимают, что из себя представляют эти две технологии. В этой лекции мы постараемся выяснить:

Что такое Xorg и почему он такой, какой он есть?
Почему все ненавидят Xorg?
Почему Wayland должен его заменить?

Неизбежно, изучив эту тему подробнее, мы узнаем:

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

На нашем пути познания графики в Linux мы познаем:

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

Что такое X Window System?

X Window System - это оконная система, включающая себя стандартные инструменты и протоколы для построения графического интерфейса пользователя, а также использующаяся в Unix-like системах.

X Window System состоит из двух составляющих:

Сервер - приложение, запущенное на целевом компьютере, который подключен к дисплею и устройствам ввода; X-сервер создаёт на целевом компьютере корневое окно, все остальные окна являются дочерними; при этом сам сервер не определяет, каким конкретно образом рисовать окна и оформление для них (например, как должны рисоваться заголовки у окон, кнопки сворачивания, разворачивания или закрытия); обычно этим занимаются оконные менеджеры - программы, работающие поверх X-сервера; но опять же, обязательства оконных менеджеров по тому, как и что они должны рисовать, нигде не прописаны, поэтому оформление у окон также могут рисовать и сами приложения (в таком случае их внешний вид определяется либо тулкитами, такими как GTK или QT, либо самим разработчиком).
Клиент - приложение, которое взаимодействует с X-сервером; отображается в качестве окна внутри корневого окна, созданного сервером; как правило, это обычное прикладное приложение, по типу браузера, файлового менеджера, терминала, редактора кода и так далее; при этом клиент может выполняться на удалённой машине и передавать свой интерфейс по сети.

Таким образом X Window System основан на клиент-серверной архитектуре и обладает сетевой прозрачностью - неважно, где будет запущен клиент: на той же машине, что сервер, или на другой, будет ли иметь другая машина ту же архитектуру и аппаратное обеспечение или нет. Данная архитектура была очень удобной в том историческом контексте, в котором X создавался. Однако в будущем это сыграет с ней злую шутку.

Важной частью X Window System являются протоколы, по которому общаются клиент и сервер. Протокол можно сравнить с интерфейсами в ООП или рецептами, по которым мы готовим еду. Например, рецепт пирога - это протокол, а уже приготовленный пирог - это реализация. Так же протокол можно сравнить с языком, на котором общаются люди. Язык позволяет доносить информацию другому человеку так, чтобы он её понял. Так же и в X Window System. Клиенты и сервер работают по одному протоколу, что позволяет им понимать друг друга.

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

Xming - реализация X-сервера для Windows, позволяющая запускать совместимые с X приложения на этой системе
Xquartz - то же самое, только для MacOS
XFree86 - ранее самая популярная реализация X-сервера для Linux и других Unix-like систем
XOrg - форк XFree86, сейчас считается канонической реализацией X-сервера

На момент создания X Window System подразумевалось, что X-сервер возьмёт на себя функции управления вводом и отрисовки интерфейса ОС и приложений на экран. Однако в следствие развития аппаратных технологий и повышения требований к интерфейсу, X-сервер перестал нормально справляться с этой задачей, в следствие чего многие функции из него начали выносить либо в ядро Linux, либо в тулкиты для создания приложений. Об этом будет рассказано далее.

Немного истории

Разработка протокола X началась в стенах MIT в 1984 году. X Window System разрабатывался совместными усилиями MIT, IBM и DEC, в рамках проекта Athena, чья цель была создание комьютерных технологий для обучения.

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

За основу взяли появившийся стек протоколов TCP/IP. Новую оконную систему старались делать аппаратно независимой. Сначала ранние версии протокола лицензировались за деньги, после было решено сделать разработку открытой в рамках лицензии MIT. В 1987 году выходит финальная версия протокола - X11.

XFree86 и XOrg

Проект XFree86 возник в 1992 году из сервера X386 для IBM PC-совместимых компьютеров. Со временем XFree86 превратился из просто отдельно взятого порта X в ведущую и самую популярную реализацию системы и стал де-факто руководить разработкой X.

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

Последней каплей была смена лицензии на несовместимую с GPL. Кита Паккарда выкинули на мороз. Но он вместе с другими ключевыми разработчиками X в 2004 году основали X.Org Foundation, а также создали форк XFree86, который назвали XOrg. The Open Group передали ей управление доменом x.org. Под крылом X.Org Foundation в иксах был проведён серьёзный рефакторинг кода.

Раздутый монстр

Стоит отдать должно разработчикам X Window System, она остаётся на плаву уже на протяжении 40 лет. При этом умудряясь сохранять обратную совместимость с 11 версией, разработанной аж в 1987 году.

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

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

Добавляя расширения вместо изменения базового протокола, мы не ломаем обратную совместимость
Создавая расширения вместо изменения базового протокола, мы не нуждаемся в том, чтобы править запутанный legacy-код X-сервера

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

OpenGL, GLX, DRI и немного рефакторинга

Sillicon Graphics - компания-разработчик графических станций, а также создатель OpenGL. Для своей операционной системы, которая использовалась на их графических станциях они решили выбрать оконную систему X11.

Задачей компании было подружить иксы с OpenGL для создания аппаратно ускоренного рабочего стола. Они создали расширение GLX, которое стало связующим звеном между OGL и X11.

Одновременно с этим RedHat и Sillicon Graphics создали архитектуру прямой отрисовки - DRI (Direct Rendering Infrastructure). По своей сути, это протокол, по которому X-сервер взаимодействует с драйверами видеокарты. Она позволила выводить изображение напрямую в обход X-сервера, а также обеспечить поддержку ускорение через GLX. Таким образом они добились повышения производительности графики.

Все эти изменения стали частью одного из самых значительных релизов XFree86 - версия 4.0. Помимо этого в нём появилось разделение на устройствозависимую часть (DDX - Device Dependent X) и на устройствонезависимую часть (DIX - Device Independent X). Данное разделение стало необходимым, так как разработчикам аппаратного обеспечения было крайне неудобно каждый раз добавлять в X-сервер всё новые и новые драйверы. Теперь часть, которая отвечает за отрисовку рабочего стола, 2D-ускорение, работу с DRI и OpenGL вынесли в DIX. По итогу эти драйверы стали звеном между X-сервером и Mesa.

Вынести всё из иксов, как цель жизни

Раньше иксы:

Сами переключали видеорежимы
Сами занимались 2D и 3D-ускорением через DRI
Сами управляли ресурсами GPU, забирая эксклюзивный доступ к ним и используя root-права
Управляли устройствами ввода
Даже имели в себе шрифтовой движок и сервер печати

Видеорежимы иксы переключали плохо. При переключении в виртуальную консоль по нажатию Ctrl+Alt+F1 иксам приходилось резко сбрасывать управление ядру, переключаться на кадровый буфер ядра Linux (Linux Frame Buffer). При переключении же обратно в графический сеанс необходимо было проделывать это всё в обратном направлении. Это было крайне накладно и экран во время этих манипуляций на секунду покрывался артефактами. Порой возврат в нормальный рабочий режим вовсе ломался. Приходилось либо перезапускать иксы, либо вовсе всю систему. Для исправления этого управление видеорежимами решили вынести из иксов в ядро Linux. Для этого создали KMS - Kernel Mode Settings. Это облегчило иксы и повысило производительность графики.

X-сервер традиционно имел эксклюзивный доступ к видеокарте и работал через кадровый буфер Linux. Это требовало root-прав и приводила к разного рода неприятным последствиям, когда два или более приложения пытались получить доступ к графическому ускорителю, урвать себе кусок видеопамяти и так далее. Это работало бы хорошо, если бы X-сервер был единственной программой, которой необходимо получить все ресурсы GPU, что приводило к состоянию гонки. Для исправления этой проблемы была создана подсистема ядра Linux - DRM (Direct Rendering Manager). Она брала все ресурсы видеокарты себе и делила их между программами. Теперь пользователь может пользоваться аппаратно-ускоренным рабочим столом, смотря видео в плеере без единого разрыва и рендеря сцену в Блендере. Также DRM предоставила API для программ и библиотек. Также отпала нужда запускать X-сервер от имени суперпользователя.

Обработка устройств ввода так же была вынесена из X-сервера в ядро Linux. Теперь этим занимается подсистема evdev. Поддержку горячего подключения устройств тоже вынесли, этим занимается подсистема ядра udev.

Шрифтами по большей мере стали заведовать графические тулкиты, наподобие QT или GTK. Впрочем, шрифтовой сервер не был удалён из иксов для сохранения обратной совместимости.

Красиво и без разрывов

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

Всему виной метод, как X11 рисовал окна. А рисовал он их сразу в экранный framebuffer. Этот метод хорошо работал, когда компьютеры ещё не были достаточно мощными. Однако со временем у компьютеров стало больше памяти и теперь можно использовать дополнительный буфер.

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

Композитный оконный менеджер (compositing manager) — это отдельное приложение, которое отвечает за компоновку (compositing) всех оконных буферов в конечный кадр памяти экрана. Композитный менеджер получает доступ к содержимому всех буферов, комбинирует их с учётом всех визуальных эффектов (таких как прозрачность и тени) и выводит результат на экран.

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

Для обеспечения композитинга было создано расширение Composite. Оно позволяет композиционному менеджеру окон создать Composite Overlay Window (сокращённо COW, окно композиционного слоя). После этого композитор назначается владельцем окна COW и может проводить его отрисовку.

Когда вы запускаете Compiz или GNOME Shell, эти приложения используют OpenGL для отображения перенаправленных окон на экране. X-сервер даёт им пользоваться содержимым окон с помощью GL-расширения Texture from Pixmap («текстура из пиксельной карты») или TFP. Это расширение позволяет OpenGL-приложению использоваться пиксельные карты X11 так, как если бы это были нативные текстуры OpenGL. Композиционные менеджеры окон, в принципе, могут не использовать TFP или OpenGL.

А что стало с сетевой прозрачностью?

В следствие того, что многие приложения начали себя рисовать при помощи аппаратного ускорения, теперь по сети по сути передаются готовые битмапы, что создают большое количество трафика. Xorg превратился в плохой аналог VNC. Дополнительно проблему усугубляет DBus, который не умеет работать по сети.

Ещё немного про проблемы XOrg

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

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

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

Xorg имеет монопольный захват устройств ввода и беспрепятственный доступ к корневому окну. Это приводит к различиным багам, вот пример некоторых из них:

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

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

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

А чё делает X-сервер?

Предлагаю ещё раз взглянуть на архитектуру X11, чтобы понять, а что всё же делает X-сервер. Схема и пункты взяты с сайта Wayland.

Ядро получает событие от устройства ввода и отправляет его в X через драйвер ввода evdev. Ядро выполняет всю тяжелую работу, управляя устройством и переводя различные протоколы событий, специфичные для устройства, в стандарт входных событий linux evdev.
X-сервер определяет, какое окно затрагивает событие, и отправляет его клиентам, которые выбрали для данного события это окно. На самом деле X-сервер не знает, как правильно это сделать, поскольку расположение окна на экране контролируется композитором и может быть преобразовано различными способами, которые X-сервер не понимает (уменьшение масштаба, поворот, шатание и т. д.).
Клиент смотрит на событие и решает, что делать. Часто пользовательский интерфейс должен измениться в ответ на событие - возможно, был нажат флажок или указатель попал на кнопку, которую нужно выделить. Таким образом, клиент посылает запрос на рендеринг обратно на X-сервер.
Когда X-сервер получает запрос на рендеринг, он отправляет его драйверу, чтобы тот запрограммировал оборудование на выполнение рендеринга. X-сервер также рассчитывает граничную область рендеринга и отправляет ее в композитор как damage event.
Damage event сообщает композитору, что в окне что-то изменилось и что он должен перекомпоновать ту часть экрана, где это окно видно. Композитор отвечает за рендеринг содержимого всего экрана на основе его сценографа и содержимого X-окон. Однако для этого он должен пройти через X-сервер.
X-сервер получает запросы на рендеринг от композитора и либо копирует задний буфер композитора в передний буфер, либо выполняет перелистывание страниц. В общем случае X-сервер должен выполнить этот шаг, чтобы учесть перекрывающиеся окна, которые могут потребовать обрезки, и определить, может ли он перевернуть страницу. Однако для композитора, который всегда работает в полноэкранном режиме, это еще одно ненужное переключение контекста.

Как уже говорилось выше, с таким подходом есть несколько проблем. У X-сервера нет информации, чтобы решить, какое окно должно получить событие, и он не может преобразовать координаты экрана в локальные координаты окна. И хотя X передал ответственность за окончательную закраску экрана менеджеру композитинга, X по-прежнему контролирует передний буфер и настройку режимов. Большинство сложностей, которые раньше решал X-сервер, теперь доступны в ядре или в самостоятельных библиотеках (KMS, evdev, mesa, fontconfig, freetype, cairo, Qt и т. д.). В общем, X-сервер теперь - это просто посредник, который создает дополнительный шаг между приложениями и композитором и дополнительный шаг между композитором и оборудованием. Вопрос, зачем он нужен?

А давайте выкинем X-сервер?

«А давайте!» - сказал Кристин Хогсберг и сделал Wayland.

В Wayland композитор является сервером отображения. Мы передаем композитору управление KMS и evdev. Протокол wayland позволяет композитору отправлять входные события непосредственно клиентам и позволяет клиенту отправлять damage-события непосредственно композитору.

Ядро получает событие и отправляет его в композитор. Это похоже на случай X, что замечательно, поскольку мы получаем возможность повторно использовать все драйверы ввода в ядре.
Композитор просматривает свою сценарную схему, чтобы определить, какое окно должно получить событие. Граф сцены соответствует тому, что находится на экране, и композитор понимает преобразования, которые он мог применить к элементам в графе сцены. Таким образом, композитор может выбрать нужное окно и преобразовать экранные координаты в локальные координаты окна, применив обратные преобразования. Типы преобразований, которые могут быть применены к окну, ограничены только тем, что может сделать композитор, если он может вычислить обратное преобразование для входных событий.
Как и в случае с X, когда клиент получает событие, он обновляет пользовательский интерфейс в ответ. Но в случае с Wayland рендеринг происходит в клиенте, а клиент просто посылает запрос композитору, чтобы указать область, которая была обновлена.
Композитор собирает damage-запросы от своих клиентов и затем перекомпонует экран. Затем композитор может напрямую выдать ioctl для планирования перелистывания страниц с помощью KMS.

HTML+CSS

Роберт Толстов — Tue, 17 Sep 2024 00:00:00 GMT

Введение в HTML

Введение

Веб-разработка — это динамично развивающийся процесс создания и поддержания веб-приложений и сайтов. В основе любой веб-страницы лежат два ключевых языка: HTML (HyperText Markup Language) и CSS (Cascading Style Sheets). HTML отвечает за структуру и содержание веб-страниц, определяя их логическую организацию. CSS используется для оформления и стилизации элементов, созданных с помощью HTML. Эти языки тесно взаимосвязаны и дополняют друг друга, позволяя создавать нечто большее, чем <h1>Hello, World</h1>.

Предварительные требования

Для успешного прохождения лекции достаточно уметь работать с браузером.

Что такое HTML и CSS?

HTML — это язык гипертекстовой разметки, используемый для создания структуры веб-страниц. Он состоит из тегов, которые определяют элементы страницы.

Основная задача HTML — организовать контент так, чтобы браузер мог его корректно отобразить. HTML-документ имеет древовидную структуру, включающую заголовочную часть <head> и тело документа <body>. В <head> указывается метаинформация (заголовок, кодировка, стили, скрипты), которая не отображается, но влияет на поведение страницы. В <body> находится контент: текст, изображения, видео, таблицы и т.д.

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

Основы HTML

Что такое теги?

Теги оборачивают текст или другие теги, задавая свойства своим дочерним элементам. Изучение HTML сводится к знанию тегов. Для самостоятельного изучения рекомендуем ru.w3docs.com.

Пример псевдокода:

<tag>
  Теги оборачивают текст или другие теги.
  Такие теги называют <b>парными</b>.
</tag>

Парные теги должны иметь закрывающий тег с символом "/" в начале

<tag attribute1#"aboba" attribute2>
  У тегов могут быть специальные свойства - атрибуты.
  Атрибуты всегда могут задаваться строкой, однако некоторые могут
  задавать булево значение своим присутствием (как attribute2).
  У закрывающего тега атрибуты не указываются
</tag>

<singleTag attr#"aboba" />
Некоторые теги могут быть одиночными. Обычно они не
подразумевают прямое воздействие на свой внутренний контент,
хотя и могут его содержать. Именно атрибуты помогают управлять
ими.

<!&mdash; А это специальный тег для комментариев &mdash;>

Валидный HTML-документ — это документ, который браузер корректно обрабатывает. Например, следующий код валиден:

Hello, Aboba!

Пустой документ тоже валиден:

Однако в реальной разработке нужно использовать теги, задающие поведение страницы. Шаблонный код:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width#device-width, initial-scale=1.0" />
    <title>Document</title>
  </head>
  <body>
    Content here
  </body>
</html>

Разберём:

<!DOCTYPE html> — указывает спецификацию (например, HTML5).

<html> — содержит весь контент страницы.

<head> и <body> — метаинформация и отображаемый контент.

<meta> — сообщает браузеру непечатаемую информацию (кодировка, описание, ключевые слова).

<title> — задаёт название страницы в браузере или поисковой выдаче.

Атрибуты

Атрибуты указываются в начальном теге:

<tag attr#"value">
  Content
</tag>

Атрибуты делятся на обязательные (необходимы для работы элемента) и необязательные (изменяют поведение или вид). Типы атрибутов:

Базовые атрибуты

Применяются к любому тегу:

class
id
style
title

Стандартные атрибуты

Определены в спецификации HTML:

href для <a>
src и alt для <img>

Data-атрибуты

Используются для взаимодействия с CSS и JS:

<div data-custom-attribute#"some-value"></div>

Атрибуты событий

Связывают JavaScript с событиями:

<button onclick="alert('Клик!')">Нажми меня</button>

Пользовательские атрибуты

Пример:

<button aboba="bebra">Ерунда какая-то</button>

Такие атрибуты не рекомендуется использовать, так как они нарушают совместимость.

Типографика

Форматирование текста

Для форматирования текста используются парные теги:

<strong> — полужирный текст
<em> — курсив
<small> — уменьшает размер текста
<sup> — надстрочный текст
<sub> — подстрочный текст
<mark> — выделяет текст жёлтым
<del> — перечёркивает текст

Эти стили можно переопределить через CSS.

Заголовки

Заголовки от <h1> до <h6> обозначают иерархию контента. <h1> — самый важный, <h6> — наименее значимый.

Рекомендации:

Используйте заголовки для иерархии.
Один <h1> на семантическую единицу (страница, карточка, …).
<h2> для основных подразделов, <h3> для подподразделов.

Параграфы

Тег <p> создаёт параграфы с вертикальными отступами для разделения текста.

Списки

Нумерованные списки

Используется <ol> (ordered list) с элементами <li> (list item):

<ol>
  <li>Абоба 1</li>
  <li>Абоба вторая</li>
  <li>Третья абоба</li>
</ol>

Маркированные списки

Используется <ul> (unordered list) с <li>:

<ul>
  <li>Абоба 1</li>
  <li>Абоба номер три3</li>
  <li>А важен ли порядок абоб?</li>
</ul>

Ссылки

Тег <a> создаёт гиперссылки. Атрибуты:

href — URL-адрес.
target — _self (текущее окно), _blank (новое окно), _parent, _top.
download — скачивание файла.
rel — дополнительные свойства.

Пример:

<a href="some_aboba.org" target="_blank" rel="noreferrer">ABOBA!</a>

Мультимедиа

Изображения

Одиночный тег <img> вставляет изображения. Атрибуты:

src — путь к изображению.
alt — описание для доступности и SEO.
width, height — размеры.

Видео

Парный тег <video> вставляет видео. Атрибуты:

src — путь к файлу.
controls — элементы управления.
autoplay — автозапуск.
loop — повтор.
muted — без звука.

Пример с <source> для кроссбраузерности:

<video controls>
  <source src="aboba.mp4" type="video/mp4" />
  <source src="aboba.webm" type="video/webm" />
  Ваш браузер не поддерживает видео.
</video>

Аудио

Парный тег <audio> аналогичен <video>.

Контейнеры

Контейнеры группируют элементы, часто для стилизации.

Блочные контейнеры

Тег <div> — блочный контейнер:

<div>
  <tag>Какое-то содержимое тега</tag>
  Абоба :)
</div>

Строчные контейнеры

Тег <span> — строчный контейнер:

<span>Какой-то не очень большой текст про абобу</span>

Семантические теги

Семантические теги (HTML5) улучшают структуру и SEO:

<header> — верхняя часть страницы.
<nav> — навигация.
<aside> — боковой контент.
<main> — основной контент.
<article> — независимый контент.
<section> — раздел с заголовком.
<footer> — нижняя часть.

Пример:

<article>
  <header>
    <h2>Заголовок статьи</h2>
  </header>
  <section>
    <h3>Подзаголовок статьи</h3>
    <p>Подзаголовок статьи</p>
  </section>
  <footer>
    <p>Автор: Абобус Обыкновенный</p>
  </footer>
</article>

Таблицы

Таблицы представляют данные в виде сетки. Теги:

<table> — контейнер таблицы.
<tr> — строка.
<td> — ячейка.
<th> — заголовок ячейки.
<caption> — заголовок таблицы.
<thead>, <tbody>, <tfoot> — группировка.

Пример:

<table>
  <caption>
    Пример таблицы
  </caption>
  <thead>
    <tr>
      <th>Заголовок 1</th>
      <th>Заголовок 2</th>
      <th>Заголовок 3</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Ячейка 1.1</td>
      <td>Ячейка 1.2</td>
      <td>Ячейка 1.3</td>
    </tr>
    <tr>
      <td>Ячейка 2.1</td>
      <td>Ячейка 2.2</td>
      <td>Ячейка 2.3</td>
    </tr>
  </tbody>
  <tfoot>
    <tr>
      <td colspan="3">Подвал таблицы</td>
    </tr>
  </tfoot>
</table>

Атрибуты colspan и rowspan объединяют ячейки.

Формы

Формы собирают пользовательские данные. Тег <form> с атрибутами:

action — URL для отправки данных.
method — HTTP-метод (GET, POST).
enctype — кодировка данных.

Пример:

<form action="/submit" method="POST">
  <!&mdash; Элементы формы будут здесь &mdash;>
</form>

Элементы формы

Текстовое поле

Тег <input type="text">. Атрибуты:

name — имя поля.
placeholder — подсказка.
disabled — отключает ввод.
required — обязательное поле.

Пример:

<form action="/submit" method="POST">
  <input type="text" name="username" placeholder="Введите ваше имя" />
</form>

Пароль

Тег <input type="password">. Атрибуты:

name
placeholder

Пример:

<form action="/submit" method="POST">
  <input type="password" name="password" placeholder="Введите пароль (он будет скрыт)" />
</form>

Кнопка отправки

Теги <input type="submit"> или <button type="submit">. Атрибут:

value — текст кнопки.

Пример:

<form action="/submit" method="POST">
  <input type="text" name="username" placeholder="Введите ваше имя" />
  <input type="submit" value="Отправить" />
</form>

Кнопка сброса

Теги <input type="reset"> или <button type="reset">. Атрибут:

value

Пример:

<form action="/submit" method="POST">
  <input type="text" name="username" placeholder="Введите ваше имя" />
  <input type="reset" value="Сбросить" />
</form>

Флажки

Тег <input type="checkbox">. Атрибут:

checked — выбран по умолчанию.

Пример:

<form action="/submit" method="POST">
  <input type="checkbox" name="aboba1">Я согласен с абобой =1</input>
  <input type="checkbox" name="aboba2">Я согласен с абобой =2</input>
  <input type="checkbox" name="aboba3">Я согласен с абобой =3</input>
  <input type="submit" value="Отправить">
</form>

Радиокнопки

Тег <input type="radio">. Атрибут:

name — связывает радиокнопки.

Пример:

<form action="/submit" method="POST">
  <input type="radio" name="gender" value="male">Мужчина</input>
  <input type="radio" name="gender" value="female">Женщина</input>
  <!&mdash; Либо 1, либо 2, но не оба вместе! &mdash;>
  <input type="submit" value="Отправить">
</form>

Текстовая область

Парный тег <textarea>. Атрибуты:

rows, cols — размеры.
minlength, maxlength — длина текста.

Пример:

<form action="/submit" method="POST">
  <textarea name="message" rows="4" cols="50" placeholder="Введите ваше сообщение про абобу"> </textarea>
  <input type="submit" value="Отправить" />
</form>

Выбор из списка

Парный тег <select> с <option>. Атрибут:

multiple — множественный выбор.

Пример:

<form action="/submit" method="POST">
  <select name="options">
    <option value="option1">Опция 1</option>
    <option value="option2">Опция 2</option>
  </select>
  <input type="submit" value="Отправить" />
</form>

Формы — важный инструмент для взаимодействия с пользователями, позволяющий создавать удобные интерфейсы для ввода данных.

Основы HTML это хорошо, но без стилей веб-страницы выглядят примитивно. За визуальное оформление отвечает CSS (Cascading Style Sheets) — язык таблиц стилей, который делает сайты такими, какими мы привыкли их видеть.

Основные концепции CSS

CSS (Cascading Style Sheets) — это язык стилей, используемый для оформления HTML-документов. Он позволяет отделить содержимое страницы от её визуального представления, упрощая поддержку и структурирование кода.

CSS был впервые предложен Хоконом Виум Лиеном в 1996 году. CSS2 появился в 1998 году, а CSS3 (1999) разделён на модули для ускорения развития. Основные элементы CSS:

Селекторы — выбирают элементы для стилизации.
Свойства — определяют, что стилизовать (например, цвет, размер шрифта).
Значения — задают конкретные параметры свойств.

Синтаксис CSS состоит из правил: селектор и блок объявлений в фигурных скобках.

Подключение CSS к HTML

Существует три способа подключения CSS к HTML, каждый со своими плюсами и минусами.

Встроенные стили

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

<p style="color: red; font-size: 20px;">Это текст с встроенными стилями</p>

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

Однако такой способ не подойдёт, если нам требуется написать больше 5 стилей, ведь тогда станет абсолютно нечитаемой.

Внутренние стили

Внутренние стили размещаются внутри тега <style>. Этот метод удобен для стилизации одной страницы, но не подходит для больших проектов, где требуется повторное использование стилей.

Выглядит это так:

<style>
  p {
    color: blue;
    font-size: 18px;
  }
</style>

Внешние стили

Внешние стили подключаются через ссылку на отдельный CSS-файл с помощью тега <link>. Это наиболее распространенный и рекомендуемый способ, так как он позволяет разделить содержание и стили, а также переиспользовать одни и те же стили на нескольких страницах. В таком случае все стили хранятся в отдельном файле с расширением .css.

Выглядит это так:

<head>
  <link rel="stylesheet" href="styles.css" />
</head>

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

href — указывает путь к файлу;
rel — объясняет, как интерпретировать этот файл? В данном случае это таблица стилей stylesheet, но может быть и, например, иконка icon.

Далее мы будем придерживаться именно этого подхода.

Селекторы

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

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

селектор {
  правило1: значение1;
  правило2: значение2;
  правило3: значение3;
  /** ... и так далее **/
}

Так что же такое эти селекторы? Это специальные выражения, позволяющие выбрать элементы на веб-странице для дальнейшей работы с ними.

Селекторы по тегу

Самое простое — это выбрать тег, который нам нужен и стилизовать.

p {
  color: green;
}

В таком случае стили применятся ко всем тегам <p> в документе

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

Как вы помните, одним из базовых атрибутов в HTML является class. Если его применить к тегу, то в стилях можно будет к нему обращаться.

Например, если есть такой HTML-код:

<div class="someClass">Стилизованный компонент</div>
<span class="someClass"> Другой компонент, с таким же стилем </span>
<a class="someClass"> Ещё что-то с такими же стилями </a>

то в CSS к нему можно обратиться через следующий синтаксис:

.someClass {
  color: green;
}

В таком случае стили применятся ко всем тегам с классом someClass документе. Важно, что ведущую точку мы указываем только как оператор обращения к классу в CSS, но в самом значении HTML—атрибута её нет

Селекторы по идентификатору

Аналогично атрибуту class, есть базовый атрибут id, к которому можно обращаться следующим образом:

<div id="someId">Стилизованный компонент с <strong>уникальным id</strong></div>

А в CSS обращаемся через #:

#someId {
  color: green;
}

В таком случае стили применятся к тегу с id someId. В отличие от класса, идентификатор должен применяться только к одному элементу. Обычно, их используют напорядок реже, чем классы.

Комбинированные селекторы

Пусть нам дан следующий код:

<div class="container">
  <p>Boring text</p>
  <p>Boring text</p>
  <p>Boring text</p>
  <p>Boring text</p>
  <p>Boring text</p>
  <p>Boring text</p>
</div>

И пусть нам нужно стилизовать только чётных детей div.container.

Конечно, можно вручную повесить на каждый нужный тег класс:

<div class="container">
  <p>Boring text</p>
  <p class="even">Boring text</p>
  <p>Boring text</p>
  <p class="even">Boring text</p>
  <p>Boring text</p>
  <p class="even">Boring text</p>
</div>

А затем применить стили:

.even {
  color: red;
}

Однако с ростом элементов, которых нужно стилизовать, задача всё сильнее принимает невозможный характер.

Рассмотрим другой кейс:

<div class="container">
  <p>Boring text</p>
</div>
<p>Unstyled text</p>

Нам нужно стилизовать только тег внутри div.container. Эта задача также решается с помощью добавления класса:

<div class="container">
  <p class="styled-p">Boring text</p>
</div>
<p>Unstyled text</p>

и дальнейшем применением стилей:

.styled-p {
  color: red;
}

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

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

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

Объединение селекторов

Базовые селекторы можно склеивать в один. Таким образом можно применять определённые стили к некоторым селекторам.

Пример синтаксиса:

.aboba {
  color: red;
}

.aboba.greeny {
  color: green;
}

<p class="aboba">It's a red text</p>
<p class="aboba greeny">It's a green text</p>

Обратим внинание, что имена классов в атрибуте class нужно перечислять через пробел.

Потомки селекторов

Если нужно стилизовать селекторы, которые вложены в другие, как например:

<div class="parent">
  <div class="child">Some text about aboba</div>
  <div>
    <div class="child">Some text about aboba</div>
  </div>
</div>

то можно использовать следующий синтаксис:

.parent .child {
  color: red;
}

Обратите внимание, что в данном HTML—коде второй child обёрнут в тег без класса! Однако, такой подход выберет не только первый контейнер, но и ребенка второго. Если же нам нужно выбрать только первый контейнер (то есть ребёнка .child на первом уровне вложенности относительно .parent, а не на любом), то следует использовать следующий синтаксис:

.parent > .child {
  color: red;
}

Оператор > говорит, что нужно искать классы только среди детей, а не потомков.

Смежные селекторы

Для того, чтобы выбрать элемент, находящийся на одном уровне вложенности с данным, в CSS существует следующий синтаксис:

.item-one ~ .item-two {
  color: red;
}

<div class="container">
  <div class="item-one">Aboba</div>
  <div class="odd-stuff">Other stuff</div>
  <div class="item-two">Styled aboba</div>
</div>

Как мы видим, теги не обязательно должны идти друг за другом, однако если мы хотим достичь такого, то вместо ~ следует использовать +:

.item-one + .item-two {
  color: red;
}

Тогда:

<div class="container">
  <div class="item-one">Aboba</div>
  <div class="odd-stuff">Other stuff</div>
  <div class="item-two">Unstyled aboba</div>
</div>

но:

<div class="container">
  <div class="item-one">Aboba</div>
  <div class="item-two">Styled aboba</div>
</div>

Псевдоклассы

Зачастую некоторые кейсы рационально (а иногда и необходимо) решать с помощью псевдо-классов.

CSS-псевдоклассы — это специальные ключевые слова, которые позволяют применять стили к определённым состояниям, характеристикам или положению элементов на веб-странице.

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

Общий синтаксис на примере псевдокода:

селектор:псевдо-класс(если-необходим-аргумент) {
  /** стилизуем данное состояние **/
}

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

:hover — применяется к элементу, когда курсор мыши находится над ним;
:focus — применяется к элементам, которые находятся в фокусе (обычно при навигации с помощью клавиатуры);
:active — применяется к элементам, когда они находятся в активном состоянии (например, при нажатии на кнопку или ссылку);
:hover — применяется к элементу, когда курсор мыши находится над ним.

Помимо прочего, псевдоклассы помогают выбрать определённые элементы из селекторов, например:

:first-child — выберет первый элемент из родительского контейнера по данному селектору;
:last-child — выберет последний элемент из родительского контейнера по данному селектору;
:nth-child(<последовательность>) — выбирает все элементы, номера которых удовлетворяют значениям последовательности;
:not(<другой-псевдокласс>) — выбирает все элементы, кроме псевдокласса в аргументе;

Для большего понимания устройства селекторов рекомендуем данную шпаргалку.

Каскадность и специфичность

Каскадность и специфичность являются основополагающими концепциями в CSS, которые определяют, как стили применяются к элементам на веб-странице, особенно когда несколько правил конфликтуют.

Принцип специфичности

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

Inline-стили (стили, заданные в атрибуте style элемента) имеют наивысшую специфичность;
ID-селекторы имеют более высокую специфичность, чем классы и псевдоклассы;
Классы, атрибуты и псевдоклассы имеют одинаковую специфичность и ниже, чем ID;
Селекторы элементов имеют наименьшую специфичность.

Пример расчета специфичности:

#header {
  /** Сильный приоритет **/
  color: green;
}

.nav {
  /** Средний приоритет **/
  color: blue;
}

div {
  /** Слабый приоритет **/
  color: red;
}

Однако, данное правило можно обойти, если к необходимому свойству добавить директиву !important. Тогда картина будет следующей:

#header {
  /** Сильный приоритет **/
  color: green;
}

.nav {
  /** САМЫЙ СИЛЬНЫЙ ПРИОРИТЕТ **/
  color: blue !important;
}

div {
  /** Слабый приоритет **/
  color: red;
}

Примечательно, что если добавить !important к стилям всех специфичностей, то они сохранят свои приоритеты (однако такое считается плохой практикой).

Принцип каскадности

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

Например:

p {
  color: blue;
}

p {
  color: red; /** Это правило перекроет предыдущее **/
}

Единицы измерения

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

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

body {
  font-size: 16px;
}

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

Абсолютные единицы измерения

Абсолютные единицы имеют фиксированное значение и не зависят от других элементов или устройств вывода.

Пиксели (px)

Наиболее распространенная единица измерения в CSS. Один CSS-пиксель равен $1/96$ дюйма. На устройствах с высокой плотностью пикселей (например, Retina-дисплеях) один CSS-пиксель может соответствовать нескольким физическим пикселям.

Сантиметры (cm), миллиметры (mm), дюймы (in)

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

Относительные единицы измерения

Относительные единицы зависят от других параметров, таких как размер шрифта родительского элемента или размер viewport.

Размер шрифта родителя (em)

Относительная единица, равная размеру шрифта родительского элемента.

Размер шрифта корня (rem)

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

Проценты (%)

Задают размер относительно родительского элемента. Часто используются для создания адаптивных макетов.

Ширина (vw) и высота (vh) viewport

Более продвинутые единицы, задают 1% от ширины и высоты viewport соответственно. Полезны для создания элементов, зависящих от размера экрана. Также часто используются при создании адаптивной вёрстки.

Существуют и другие разновидности единиц, зависящих от viewport, однако в рамках данной лекции опустим их.

Доля контейнера (fr)

Представляет долю свободного пространства только в grid-контейнере (см раздел про сетки в CSS).

Глобальные значения

Любое CSS—правило может принять в себя одно из глобальных значений, таких как:

none — значение не установлено;
inherit — значение будет унаследовано от родителя;
initial — значение по умолчанию;
unset — действует как inherit для наследуемых свойств и как initial для ненаследуемых свойств;
revert — отменяет любые изменения, применённые к свойству, и возвращает значение к тому, что было установлено браузером или пользовательскими стилями (если они есть).

Эти свойства обеспечивают универсальность и гибкость в управлении стилями.

Типографика

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

И вообще, мы рассмотрим далеко не все свойства (и даже не половину). Все они будут всплывать на практике по мере необходимости, поэтому авторы прикладывают ссылку на список всех свойств, функций, псевдоклассов, селекторов и т.п.

Шрифты

Font-family

Свойство font-family определяет семейство шрифтов для текста:

body {
  font-family: Arial, Helvetica, sans-serif;
}

Обратим внимание, что в CSS есть некоторые зарезервированные значения. Таковыми являются serif и sans-serif — они обозначают соответственно антикварные и гротескные шрифты, установленные в системе по умолчанию.

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

Font-size

Свойство font-family устанавливает размер шрифта:

body {
  font-size: 16px;
}

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

Font-weight

Свойство font-weight устанавливает толщину шрифта:

body {
  font-weight: 400;
}

В качестве значения принимает число от 100 до 900 или одно из ключевых слов lighter, light, normal, bold, bolder.

Font-style

Свойство font-style определяет начертание шрифта:

body {
  font-style: oblique;
}

В качестве значения принимает одно из ключевых слов italic, oblique (в отличие от italic не имитирует рукопись, а просто наклоняет текст), normal.

Цвет, выравнивание, трансформация

Color

Свойство color определяет цвет текста:

body {
  color: #affefe;
}

Цвета в CSS задаются несколькими способами:

Ключевыми словами (red, magenta и т.п.. Прозрачный цвет задаётся ключевым словом transparent);
HEX-кодом;
RGB-функцией;
HSL-функцией;

Подробнее о цветах можно прочитать в данном разделе.

Text-align

Свойство text-align определяет выравнивание текста:

body {
  text-align: center;
}

Может принимать 4 значения: left, right, center, justify.

Text-decoration

Свойство text-decoration добавляет декортивные линии. По умолчанию none у обычного текста, однако установлен у <a>:

body {
  text-decoration: underline #f77 solid;
}

Принимает три аргумента:

Определяет тип линии: underline для подчёркивания, overline для надчёркивания и line-through для перечёркивания;
Определяет цвет линии;
Определяет штрих линии: solid для сплошной линии, dashed для длинного пунктира, dotted для точечного пунктира, wavy для волны.

Стоит отметить, что аргументы можно передавать в любом порядке, но рекомендуется именно ТИП ЦВЕТ ШТРИХ.

Text-transform

Свойство text-transform изменяет регистр текста:

body {
  text-transform: uppercase;
}

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

Text-shadow

Свойство text-shadow изменяет регистр текста:

body {
  text-shadow: 2px 2px 4px #000000;
}

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

Интервалы

Line-height

Свойство line-height устанавливает высоту строки (по умолчанию 1.5):

body {
  line-height: 2;
}

Letter-spacing

Свойство letter-spacing регулирует расстояние между буквами:

body {
  letter-spacing: 2px;
}

Word-spacing

Свойство letter-spacing регулирует расстояние между словами:

body {
  word-spacing: 5px;
}

Понятие блочной модели

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

Для этого в CSS используется блочная модель. Блочная модель (Box Model) — это фундаментальная концепция в CSS, которая описывает, как элементы HTML отображаются в браузере и как они взаимодействуют друг с другом. Понимание блочной модели критически важно для эффективной верстки веб-страниц.

Свойства блочной модели

Блочная модель состоит из четырех основных компонентов:

Содержимое (Content)
Внутренние отступы (Padding)
Границы (Border)
Внешние отступы (Margin)

Каждый HTML-элемент можно представить как «коробку» с этими четырьмя слоями.

Margin

Определяет пространство вокруг элемента, за пределами границ.

.box {
  margin: 10px; /** Все стороны **/
  margin-top: 5px;
  margin-right: 10px;
  margin-bottom: 15px;
  margin-left: 20px;
}

Border

.box {
  border: 1px solid black;
  border-width: 2px;
  border-style: dashed;
  border-color: red;
}

Padding

.box {
  padding: 10px; /** Все стороны **/
  padding-top: 5px;
  padding-right: 10px;
  padding-bottom: 15px;
  padding-left: 20px;
}

Типы элементов

Существует несколько типов элементов с разными моделями. Все они регулируются свойством display.

Блочные элементы

Блочные элементы занимают всю доступную ширину, при этом начинаются с новой строки. Таковым элементом (по умолчанию) является <div>

Git

Андрей Гущин — Tue, 21 Sep 2021 00:00:00 GMT

Зачем?

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

А ещё никто не любит терять важные документы, либо часы своего драгоценного времени из-за сломанной флешки или отключенного света. А ещё обиднее ситуация, когда ты написал крайне заумную фичу, полюбовался ею и пошёл писать следующую. Но случился казус --- новая фича сломала программу, Ctrl+Z уже не может вернуть к предыдущей рабочей версии, а сам ты не можешь вспомнить как восстановить прошлое состояние проекта…

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

Но самая большая проблема возникает тогда, когда над проектом работает больше одного человека. Облачные системы синхронизации типа GDrive, YaDisk, Dropbox не сильны в решении конфликтов при синхронизации и только создадут головную боль. Как объединять две версии проекта с таким подходом даже не хочется себе представлять…

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

Установка

Linux

Установить git можно с помощью пакетного менеджера твоей системы: например, sudo apt install git или sudo pacman -S git.

MacOS

На MacOS установить git можно с помощью пакетного менеджера Homebrew. Если ты ещё не установил brew, можешь сделать это с помощью команды в терминале:

  /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

После этого установить git можно командой brew install git.

Windows

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

Git на windows используется через установленную программу git bash, вместе с которой устанавливается базовое окружение Unix систем (программы ls, cd и т.д.).

Базовые команды

Для того, чтобы начать пользоваться git’ом достаточно всего нескольких команд и некоторого понимания основных понятий.

Репозиторий --- это хранилище всех зафиксированных версий всех отслеживаемых объектов в папке проекта.

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

Состояния файлов

В любом репозитории файлы находятся в четырёх состояниях:

Untracked (не отслеживаемые) --- файлы, которые находятся в папке репозитория, но их изменения никак не влияют на само состояние репозитория;
Unstaged --- сам файл отслеживается git’ом, но изменения относительно предыдущего коммита не будут зафиксированы;
Staged --- означает, что файл и отслеживается git’ом, и изменения будут зафиксированы;
Commited --- в файле нет изменений относительно предыдущего коммита.

Необходимые команды

Для создания репозитория достаточно ввести git init в папке с проектом. После этого все файлы в этой папке будут считаться Untracked.

С помощью команды git add [files] можно перевести файлы из состояния Untracked или Unstaged в состояние Staged. Если отслеживаемый файл после выполнения этой команды файл был изменён, то необходимо снова его добавить в Stage.

Перед фиксированием изменений полезно проверить состояние репозитория. Команда git status выведет список состояний файлов в текущей папке.

  $ git status
  On branch master
  Changes to be committed:
    (use "git restore --staged <file>..." to unstage)
    modified:   file.txt

  Changes not staged for commit:
    (use "git add <file>..." to update what will be committed)
    (use "git restore <file>..." to discard changes in working directory)
    modified:   another.txt

  Untracked files:
    (use "git add <file>..." to include in what will be committed)
    third.txt

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

Само фиксирование изменений происходит с помощью команды git commit. Для коммита с простым описанием достаточно команды git commit -m "<message>". Одна строка <message> будет добавлена к коммиту и записана в хранилище. Обычно, простого описания будет достаточно. Но если необходимо более развёрнутое и многострочное описание, то можно выполнить команду git commit без аргументов. Будет вызван текстовый редактор (если не настраивать иначе, то скорее всего будет вызван Vim).

Распространение репозитория на другие компьютеры

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

Github

Для хранения репозиториев зачастую используются сервисы типа GitHub. Несмотря на то, что технически git --- это распределённая и децентрализованная система контроля версий, удобно принять один из репозиториев за центральный и синхронизировать свой репозиторий с ним.

Далее будет подразумеваться, что для хранения репозиториев используется GitHub, поэтому будет полезно на нём зарегистрироваться.

Для создания нового репозитория нужно на главной странице сервиса нажать на зелёную кнопку New, чтобы открылась следующая страница:

![Создание нового репозитория]({{< resource url=/helpful/git/github-create.png >}})

После нажатия на кнопку Create repository будет открыта страница с новым репозиторием в которой сразу же предложат скопировать на него ссылку:

![Новый репозиторий]({{< resource url=/helpful/git/github-new.png >}})

Так и поступим.

Внешние репозитории

Так как данный репозиторий хранится на серверах GitHub, нужно добавить ссылку на него в локальный репозиторий. Делается это со помощью команды git remote. Так как внешних репозиториев может быть несколько, каждому из них нужно присвоить какое-то имя. Обычно основной внешний репозиторий называют origin. Таким образом, вся команда для добавления внешнего репозитория:

  git remote add <remote-url>

Для моего только что созданного репозитория <remote-url> равна https://github.com/saintruler/git-article.git.

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

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

Клонирование репозиториев

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

При клонировании репозитория ссылка на клонируемый репозиторий сама добавляется как внешний репозиторий origin.

Непосредственно контролирование версий

Ветки

Иногда очень хочется вести две параллельные версии проекта, но при этом очень не хочется что-либо сломать. Для этого предусмотрена возможность создания веток. В новом репозитории создаётся одна ветка --- master. Чтобы удостовериться в этом можно вывести список всех веток командой git branch. Текущая ветка будет выделена в этом списке.

Для создания новой ветки используется команда git branch <name>. При этом репозиторий остаётся на старой ветке. Переключиться на другую ветку можно командой git checkout <name>. Если же хочется создать новую ветку и сразу на неё переключиться --- git checkout -b <name>.

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

Объединение веток

Команда git merge <other-branch> добавляет изменения из <other-branch> в текущую ветку. При объединении веток могут возникнуть конфликты --- обычно это изменение одного и того же места в одном и том же файле.

Именно конфликты при объединении веток обычно бывают непонятны новичкам и из-за этого вызывают множество проблем. Для облегчения решения конфликтов существуют различные внешние программы. Достаточно простой и удобной является программа Meld. Она позволяет производить решение конфликтов в трёхпанельном интерфейсе для того, чтобы проконтролировать изменения из какой ветки в итоге будут приняты. После установки этой программы нужно указать git’у, что решение конфликтов будет проводится именно ею. Это делается командой git config --global merge.tool meld. После этого можно запустить процесс решения конфликтов командой git mergetool.

Stash

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

Для того, чтобы положить изменения в копилку выполняется команда git stash. Увидеть все «спрятанные» изменения можно командой git stash list. Все эти сохранённые изменения нумеруются, поэтому их можно обратно применить на ветку командой git stash pop <number>. После этого данные изменения из копилки удалятся. Если нужно сохранить изменения в копилке, то вместо pop следует использовать apply. git stash drop <number> удаляет ненужную запись в копилке.

Revert и log

Когда изменения уже закоммичены, но стало понятно, что они либо что-то ломают, либо вообще не нужны, то их можно откатить командой git revert <commit-hash>. После выполнения этой команды могут возникнуть конфликты, которые также можно решать через git mergetool. Когда все конфликты в файлах будут решены, эти файлы нужно будет добавить через git add и закоммитить.

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

Чтобы узнать хеш коммита, можно использовать команду git log. С её помощью можно посмотреть всю зафиксированную историю текущей ветки. У данной команды есть много параметров для изменения формата вывода, которые можно посмотреть в соответствующем мануале man git log. Например, чтобы увидеть дерево репозитория в более краткой форме с визуальным отображением работы в ветках можно использовать git log --oneline --graph.

Поиск информации

Про работу с git’ом есть огромное количество информации в сети (эта страница в том числе), но основным способом изучения доступных команд являются

Официальная документация;
Страницы мануалов: man git, man git commit и т.д. в консоли linux или macOS, либо эти же страницы онлайн, если не хочется открывать консоль.

Github Flow

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

Студенческие клубы разработки

Поездка на OS Day

О конференции

Что за проект

Как это случилось?

Впечатления от поездки

Атмосфера конференции

Компании и люди

Доклады

Как приняли студентов

Оценка состояния образования

Упадок науки и образования

Педагогика

Влияние LLM на образование

«LLM — это просто инструмент, надо просто научиться им пользоваться»

«LLM подрывает саму возможность научиться»

Карьера в системном программировании

Итоги

Введение в LoRa. Meshtastic

Введение

LoRa

LoRa-mesh

Chirp-ы и CSS модуляция

Устойчивость к помехам

Meshtastic

Принцип работы

Пакет данных meshtastic

Алгоритм mesh-сети meshtastic

Зависимость CW от SNR и косвенное вычисление расстояния

Источники

Он вам не JavaScript!

Дисклеймер!

Люблю и ненавижу

Немного статистики

Краткая историческая справка

Предыстория

Предпосылки создания нового языка

Первый прототип

Что будем делать с названием Mocha

Фундаментальные грехи

Приведение типов

Арифметические операции

Арифметические операции 2: возвращение

Прототипное наследование

Объектная модель

Современные прототипы

В чём проблема прототипов?

А как же классы?

Работа с for

Синтаксический сахар. Целый завод

Топ-8 способов задать функцию

Экосистема JS и ленивые программисты

Гайд как сломать весь Интернет в 11 строчек кода

Не изобретай велосипед

Как не стать жертвой абсурда

Альтернативные решения

TypeScript

WebAssembly (WASM)

Dart

Elm

Всё это — ошибка

Заключение расследования

SEO-оптимизация SPA

Что такое SEO?

А зачем вообще SEO?

По каким метрикам определяется релевантность ресурса?

Технические метрики

Контентные метрики

Поведенческие метрики

Внешние метрики

Что такое SPA?

Готовь сани летом…

Server-Side Rendering (SSR)

Теория

Как имплементировать в React?

Static Site Generation (SSG)

Теория

Как имплементировать в React

SSR + SSG

Incremental Static Rendering (ISR)

Работа с `for`

`robots.txt`

`sitemap.xml`

Семантическая вёрстка и атрибуты доступности `aria`