Веб-разработка *

Значимость анализа сторонних компонентов ПО (англ. Software Composition Analysis — SCA) в процессе разработки растет по мере выхода ежегодных отчетов об уязвимостях open source библиотек, которые публикуются компаниями Synopsys, Sonatype, Snyk, White Source. Согласно отчету The State of Open Source Security Vulnerabilities 2020 число выявленных уязвимостей в open source в 2019 выросло почти в 1.5 раза в сравнении с предыдущим годом, в то время как компоненты с открытым кодом используются от 60% до 80% проектов. Если обратиться к независимому мнению, то процессы SCA являются отдельной практикой OWASP SAMM и BSIMM в качестве показателя зрелости, а в первой половине 2020 года OWASP выпустила новый стандарт OWASP Software Component Verification Standard (SCVS), предоставляющий лучшие практики по проверке сторонних компонент в цепочке поставок ПО.

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

Этот кризис влияет на платформы, творцов и потребителей.

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



В этом материале я собираюсь поговорить о том, как создан этот образ, о том, какую он может принести пользу, о его правильном использовании и о его ограничениях. В частности, я разберу тут его вариант python:3.8-slim-buster (в состоянии, представленном файлом Dockerfile от 19 августа 2020 года) и по ходу дела остановлюсь на самых важных деталях.

Оказавшись одним из счастливчиков, совершенно не готовым к тому, что с 15 февраля 2021 года авторизация в Gmail и других продуктах будет работать только через OAuth, я прочитал статью "Google хоронит расширение PHP IMAP" и загрустил начал предпринимать действия по замене расширения PHP IMAP в своём проекте на API Google. Вопросов было больше, чем ответов, поэтому заодно нацарапал мануал.

В прошлом году на конференции Build мы представили WebView2, элемент управления браузера, который отображает веб-контент (HTML / CSS / JavaScript) с новым Microsoft Edge на основе Chromium. Первоначально он был ограничен приложениями C/C++. Сегодня мы рады объявить о выпуске предварительной версии WebView2 для приложений .NET! WebView2 доступен как для .NET Core, так и для .NET Framework. Его можно использовать внутри приложений WPF, Windows Forms и WinUI 3.0 вплоть до Windows 7.

Важно: при установке пакета NuGet обязательно установите флажок Include prerelease и выберите версию с суффиксом -prerelease. В противном случае вы не получите поддержку .NET.

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

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

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

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

Можно найти статьи, датированные 2017...2018 годом, ориентированные на использование сравнительно низкоуровневых средств для отправки и получения веб-пуш сообщений, например, при помощи библиотеки web-push-libs/web-push. Эта библиотека по-прежнему развивается, однако в настоящее время гораздо проще работать с библиотеками от firebase.

Краткое описание технологии

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

Для установления соединения WebSocket клиент и сервер используют протокол, похожий на HTTP. Клиент формирует особый HTTP-запрос, на который сервер отвечает определенным образом.

Примечания

Несмотря на «похожесть» новых запросов и ответов на запросы и ответы протокола HTTP, они таковыми не являются. Например, в запросе есть тело, но в заголовках поле «Content-Length» отсутствует (что нарушает соглашения HTTP). Подробнее об этом можно прочитать в Википедии.

Одним из главных преимуществ технологии — это ее простота. На клиенте и сервере есть всего 4 события для обработки:

1. connection
2. error
3. message
4. close

Почему Websocket?

Кроме ws существуют еще два способа непрерывной передачи данных: Server-Sent Events (SSE) и Long Polling.

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

Тестировать полезно. Тесты позволяют в автоматическом режиме безопасно рефакторить код и гарантируют его работу. Тесты – это живая документация: если информация в Wiki или в Confluence может устареть, то тесты всегда актуальны. Также многие крутые практики связаны с тестированием. Например, самотестирующийся код или разработка через тестирование (TDD), когда тесты пишутся перед кодом, а некоторые практики DevOps и Extreme Programming применимы только в условиях хорошего покрытия проекта тестами.



Но написать простые тесты, которые будут помогать в написании кода и не срывать дедлайны, задача сложная. Она становится ещё сложнее, если учесть, что нам приходится тестировать вёрстку. Это не два JSON сравнить: здесь не работают простые подходы «вызову функцию, проверю результат» — тестирование UI сложнее. Как эффективно и правильно тестировать верстку и писать для неё тесты, чтобы они были полезны, а дедлайны не горели, расскажет Максим Соснов (crazymax11), ведущий разработчик в СКБ Контур.

Почти две недели назад вышла запись в блоге по поводу Rome.

Rome представляет собой целый набор инструментов — линтер, компилятор, сборщик, тест раннер и даже больше. Нацелен он на JS, TS, HTML, JSON, Markdown, CSS. Проект пытается унифицировать набор инструментов необходимых для фронт-енд разработки.

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

Rome разрабатывается как замена Babel, ESLint, Webpack, Prettier, Jest и прочих.

Под катом небольшая заметка про то как можно настроить удобное окружение для работы с PHP, xdebug через Windows Subsystem For Linux 2 (WSL 2).

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

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

Перенос legacy-проекта на Laravel. Ускорение приложения на 80% с помощью Swoole. Оптимизация кода с помощью Debugbar. Логирование всех запросов к базе данных.

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



В наши дни очень легко организовать разработку маленького React-приложения, или начать работу над ним с нуля. В особенности — при использовании create-react-app. Некоторым проектам, скорее всего, понадобится лишь несколько зависимостей (например — для управления состоянием приложения и для интернационализации проекта) и папка src, в которой, как минимум, имеется директория components. Я полагаю, что именно с такой структуры начинается работа над большинством React-проектов. Обычно, правда, по мере того, как растёт количество зависимостей проекта, программисты сталкиваются с ростом количества компонентов, редьюсеров и других входящих в его состав механизмов, предназначенных для многократного использования. Иногда всем этим становится очень неудобно и сложно управлять. Что делать, например, если больше неясно то, почему нужны некоторые зависимости, и то, как они сочетаются друг с другом? Или, как быть, если в проекте накопилось так много компонентов, что становится сложно найти среди них именно тот, который нужен? Как поступить в том случае, если программисту нужно найти некий компонент, имя которого забыто?

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

Но это скоро изменится. В такие языки, как Java и Python, интегрируется всё больше и больше концепций ФП. А более современные языки, вроде Haskell, являются полностью функциональными.



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

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

Есть одна итальянская страница на Facebook. Называется она «Il Programmatore di Merda», что в переводе означает «Дерьмовый программист». Мне нравится эта страница.

Там часто публикуют куски отвратительного кода и мемы о программировании. Но однажды я увидел там кое-что совершенно потрясающее.

Этот кусок кода заслужил почётное звание «лучшего произведения» за неделю.

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

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

Рефакторинг — сложная вещь. У каждого разработчика свои критерии хорошего, плохого и красивого кода. Из-за двух строк можно развернуть холивар на две страницы комментариев на Хабре. Почему бы тогда не сделать «Битву рефакторинга»? Мы и сделаем — с 14 по 18 сентября на Russian Python Week 2020 запускаем такую битву. На битве каждый может улучшить или «разбомбить» код своего коллеги в прямом эфире. Что это за формат и как пройдет, расскажем дальше.

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

Всего у бекенда игры было 6 архитектурных единиц, которые мы и разберём в этой статье:

1. Бекенд игровых сущностей, которые отвечали за игровые механизмы
2. Шина обмена данных бекенда и площадки на VPS
3. Транслятор из запросов бекенда (игровых элементов) на ардуино и железо на площадке
4. Ардуино, которая занималась управлением релешками, получала команды с транслятора и делала фактическую работу
5. Фактические устройства: вентилятор, гирлянды, торшеры и прочее
6. Фронтенд — сам сайт Сокола, с которого игроки управляли устройствами

Давайте пройдёмся по каждой из них.