Текстовая версия видео по протоколу HTTP из обновленного курса по компьютерным сетям для начинающих.

Рассматриваем основы работы HTTP, применяем HTTP на практике в терминале, используем Wireshark для анализа пакетов HTTP. 

Привет всем! Меня зовут Юля, я фронтенд-разработчик, наставник на курсах по JS и React и организатор профессионального сообщества Tbilisi JS. В Практикуме я помогаю студентам на курсе «React-разработчик».

За время работы в разных компаниях и над разными проектами я поняла, что Git — это не только (и не столько!) знание самой технологии и конкретных команд, но и определённая культура взаимодействия, практики, подходы, договорённости. Всё это помогает участникам команды лучше понимать друг друга и работать быстрее и чётче.

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

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

В этой заметке перечислим, о чём важно помнить, работая по найму.

Хабр, я снова пришёл к вам с практическими советами про доступность вместе с Ильёй. Мы показываем, как HTML и CSS могут улучшить или ухудшить её. Напоминаю, что Илья — мой незрячий знакомый, который помогает мне найти наши косяки в вёрстке.

Сегодня мы рассмотрим следующие аспекты:

• какие скрытые проблемы с паттерном «visually-hidden» нас ждут;
• в каких ситуациях кнопка «Закрыть» указывает на выход;
• чем вредно значение contents у свойства display;
• почему подсказка с помощью атрибута aria-label вызывает недоумение.

Давайте начнём!

Рассказываю о своём опыте использования Xray (с протоколом VLESS-Reality) - одного из лучших решений для преодоления интернет-цензуры на сегодняшний день. Я потратил много времени на то, чтобы разобраться с ним - теперь вам достаточно одного вечера, чтобы поднять свой сервер на несколько десятков пользователей, c xray на борту!

• скрипт ex.sh для простой настройки и установки; есть поддержка Docker

• легко добавлять пользователей; клиентские конфиги в форме url-ссылок

• правильные конфиги: скрытность + удобство

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

• для xray есть приложения под все популярные ОС - делюсь инструкциями

• только https, нет udp; торренты через сервер блокируются по возможности

• мой проект на гитхабе: easy-xray

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

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

Привет любителям котиков! Меня зовут Юля, я backend‑разработчик компании CDEK. Я сама не так давно изучала все эти сложные понятия в программировании, поэтому решила помочь и вам разобраться с одним из них.

С какой стороны IT вы бы не пытались войти — в какой‑то момент столкнётесь с понятием REST API. Эта статья создана, чтобы смягчить данное столкновение. Новые темы всегда легче воспринимаются на простых примерах, ну а если это примеры с котиками, то варианта не разобраться просто нет. Хочется обойтись без сложных научных определений, а рассказать самым простым языком. Поэтому, если вы любите сухие и точные формулировки, то вам нужна другая статья :)

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

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

Вы изучили команды Git но хотите представлять, как непрерывная интеграция (Continuous Integration, CI) происходит в реальности? Или может вы хотите оптимизировать свои ежедневные действия? Этот курс даст вам практические навыки непрерывной интеграции с использованием репозитория на GitHub. Данный курс не задуман как некий визард, который можно просто прокликать, напротив, вы будете совершать те же действия, что люди на самом деле делают на работе, тем же способом, которым они это делают. Я буду объяснять теорию по мере прохождения вами имеющих к ней отношение шагов.

Что мы будем делать?

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

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

Вы пройдёте такие стандартные для CI сценарии:

• Работа над фичей;
• Применение автотестов для обеспечения качества;
• Реализация приоритетной задачи;
• Разрешение конфликта при слиянии ветвей (merge conflict);
• Возникновение ошибки в продуктивной среде.

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

Всем привет! Меня зовут Артём Харченков, и я руководитель подразделения разработки программных продуктов в компании Crosstech Solutions Group. Сегодня я расскажу, как успешно пройти свой первый испытательный срок, что нужно делать обязательно и чего лучше не делать. 

Для начала – кратко обо мне, чтобы было понятно, почему мне стоит доверять в таком вопросе.

/слайд обо мне/

Образование у меня ИБ-шное, в ИТ я работаю с 2012 года. За свою карьеру занимался внедрением, был разработчиком, инженером, главным техническим специалистом в группе разработчиков и даже делал проекты практически в одиночку :) В «Кросстех Солюшнс Групп» руковожу разработкой чуть более трех лет. Здесь мы создаем системы для обеспечения безопасности данных, сейчас импортозамещаем зарубежные продукты, ушедшие с российского рынка. К слову, активно нанимаем сотрудников: еще в прошлом году в компании было 50 человек, а в этом году стало уже больше 200.

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

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

В этой статье мы рассмотрим, как настроить пайплайн CI/CD в GitHub: подготовим репозиторий, зальём туда приложение, создадим файлы конфигурации GitHub Actions, в которых опишем, как собирать наше приложение и деплоить его в кластер Kubernetes, развёрнутый под управлением Deckhouse Kubernetes Platform. Деплоить будем с помощью Open Source CLI-утилиты werf. Она помогает организовать полный цикл доставки приложений в Kubernetes и рассматривает Git как единый источник истины для состояния развёрнутого приложения. Статья рассчитана на тех, кто только начинает свой путь в мире облаков и кластеризации.