
Веб-разработка *
Делаем веб лучше
Уходящая от вас безопасность
Я посетил встречу Messaging, Malware and Mobile Anti-Abuse Working Group (m3aawg.org) в Бруклине, Нью-Йорк. Я ожидал лучшей погоды, чтобы побродить по городу, насладиться конференцией, и широким выбором еды на районе. Я настолько был уверен в ясности неба, что даже не взял с собой ничего от дождя. И всю неделю шел дождь. Это вынудило меня оставаться в моем номере в отеле с бесплатным WiFi и моим рабочим ноутбуком. Я решил потратить это время за исследованием Node.js и их сопутствующих пакетов, доступных на https://www.npmjs.com.
Там есть тысячи пакетов от пользователей, доступные для скачивания и установки в ваш проект. Я поискал в NPM по популярным названиям пакетов, таких как file, backup, download, или upload. Последний поисковый запрос показал мне проект под названием jQuery file upload от пользователя Blueimp. Его описание показалось достаточно интересным, чтобы скачать и исследовать его.
Локальный NPM репозиторий за 5 минут со своими пакетами и кэширование
Рано или поздно в организациях возникают проблемы с распространением js модулей между проектами, настало то время когда в нашей компании встал этот вопрос.
Копировать и вставлять код это путь на темную сторону, поэтому было принято решение писать не просто js код, а создавать из него npm пакеты чтобы распространять между своими проектами.
Поиск бесплатных, частных npm репозиториев завел в тупик, а использование частных репозиториев на npm требует платы (а это не наш менталитет).
Поскольку в офисе есть сервер, который работает всегда(почти), было решено развернуть локальный npm.

За что я не люблю современный веб

Самый первый этап в работе с вебом — отправка данных в ваше серверное приложение. И если парсинг десятка мелких строк можно доверить фреймворку, то как быть с загрузкой файлов?
Возьмем для примера PHP, хотя описанное справедливо и для 99% остальных языков и технологий. Допустим, мы хотим позволить пользователю загружать картинки на сайт, для этого делаем формочку с полем типа file и… Внешне все очень просто, всего-то изменилось несколько байт в форме и в коде, зато теперь вместо текста из форм можно работать с файлами! Но не всё так просто, вашему файлу надо сначала осесть где-то в /tmp/, пока запрос не придет полностью, ваш скрипт просто не получит управления и вы ничего не сможете с этим сделать. К примеру, вместо картинки, пользователь загрузил exe-файл, но вы узнаете об этом только после того, как загрузка будет окончательно завершена. Тем самым, злоумышленник на некоторое время может забить вам канал и время вашей дисковой подсистемы, делая вид, что загружает полезные файлы, а вы об этом даже не узнаете. Если перед сервером приложений стоит кеширующий сервер, то ситуация еще хуже: к примеру, nginx создает временные файлы, т.е. сначала запрос от пользователя осядет на диске, как только он завершится, то файл перечитывается и быстро отдается серверу приложений (в нашем случае php), где он сохраняется на диск ЕЩЕ раз. Итого тройное использование диска, даже если пользователю надо просто вывести сообщение «ты забыл ввести капчу».
CSS: интересные возможности border-radius
border-radius? Автор материала, перевод которого мы публикуем, говорит, что больше, чем кажется на первый взгляд. В частности, речь идёт о том, что углы элементов, скруглённые с помощью этого свойства, могут иметь весьма интересную форму.
Предлагаем поговорить о тонкостях использования
border-radius.Тестовый сервер для команды разработчиков
Работа с изображениями на Python
О спикере: Александр Карпинский работает в компании Uploadcare и занимается сервисом быстрой модификации изображений на лету. Участвует в разработке Pillow — популярной библиотеки для работы с изображениями на Python, развивает собственный форк этой библиотеки — Pillow-SIMD, который использует современные инструкции процессоров для наибольшей производительности.
Реактивное приложение без Redux/NgRx

Сегодня мы детально разберем реактивное angular-приложение (репозиторий на github), написанное целиком по стратегии OnPush. Еще приложение использует reactive forms, что вполне типично для enterprise-приложения.
Мы не будем использовать Flux, Redux, NgRx и вместо этого воспользуемся возможностями уже имеющимися в Typescript, Angular и RxJS. Дело в том, что данные инструменты не являются серебряной пулей и могут внести излишнюю сложность даже в простые приложения. Нас об этом честно предупреждают и один из авторов Flux, и автор Redux и автор NgRx.
Но эти инструменты дают нашим приложениям очень приятные характеристики:
- Predictable data flow;
- Поддержка OnPush by design;
- Неизменяемость данных, отсутствие накопленных side effect-ов и прочие приятные мелочи.
Мы попытаемся получить эти же характеристики, но без внесения дополнительной сложности.
Как вы сами убедитесь к концу статьи, это довольно простая задача — если убрать из статьи детали работы Angular и OnPush, то остается лишь несколько простых идей.
Школа магии TypeScript: дженерики и расширение типов
Со временем автор этого материала понял, что каждый раз, когда он обходит ошибки, выявляемые на этапе компиляции, он закладывает в свой код бомбу замедленного действия, которая может рвануть во время выполнения программы. Каждый раз, когда он «боролся» с ошибками, используя простенькую конструкцию
as any, ему приходилось платить за это многими часами тяжёлой отладки.
В итоге он пришёл к выводу о том, что лучше так не делать. Он подружился с компилятором, начал обращать внимание на его подсказки. Компилятор находит проблемы в коде и сообщает о них задолго до того, как они могут нанести реальный вред. Автор статьи, глядя на себя как на разработчика, понял, что компилятор — это его лучший друг, так как защищает его от него самого. Как тут не вспомнить слова Альбуса Дамблдора: «Требуется большая храбрость, чтобы выступить против своих врагов, но не меньше ее требуется и чтобы выступить против своих друзей».
Каким бы хорошим другом ни был компилятор, ему не всегда легко угодить. Иногда избежать использования типа
any очень непросто. А порой кажется, что any — это единственное разумное решение некоей проблемы.Этот материал посвящён двум ситуациям. Избежав использования в них типа
any можно обеспечить типобезопасность кода, открыть возможности по его повторному использованию и сделать его интуитивно понятным.Как избежать фейлов при разработке продукта: 10 советов от Rookee

1. Забудьте о процессе, работайте на результат
Нередко компании при разработке продукта все внимание и ресурсы направляют на процесс создания и производства. Даже если каждый этап работ выполнен «строго по технологии», результат может оказаться не таким радужным, как представлялось в начале.
Поваренная книга Ruby-разработчика: Domain Driven Design рецепты ( 1-я часть, область применения )
Введение
Я хотел бы рассказать об опыте применения практик DDD к существующему Ruby on Rails проекту. Изначально, мы имели монолит, который писался 10 лет. Основная трудность проекта была в достаточно сложных процессах, и высокой связанности. Нам удалось не только декомпозировать приложение на отдельные сервисы, но и существенно повысить читаемость кода, сделать описываемые процессы прозрачными.
Решение задач в рамках системы стало предсказуемым, мы перестали работать с черным ящиком, и в конечном итоге система сама стала подсказывать нам решения.
Для облегчения как восприятия, так и написания, рассказ о применяемых подходах будет представлен в виде цикла статей. Данный подход не является "серебряной пулей", поэтому я бы хотел выделить прежде всего тот сегмент проектов, которым это решение сможет подойти. Далее, я более подробно расскажу о DDD методологии и микросервисной реализации данного паттерна, распишу возможные комбинации применяемых паттернов с учетом их имплементации, и в конечном итоге приведу пример конкретной реализации одного небольшого сервиса.
GitHub анонсировал собственный CI/CD и начал раздавать инвайты

Ближайшие события
Произошел почти двухчасовой сбой в работе сервисов YouTube, сейчас сервис стал работоспособен
В 6 утра по МСК работы сервиса были восстановлены.

Мультиязычные деревья в Yii2 на примере создания модуля меню
Вступление
Многие начинающие веб-разработчики сталкиваются с необходимостью создания меню, каталогов или рубрикаторов для своего проекта на Yii2, которые бы имели иерархическую структуру, но при этом поддерживали мультиязычность. Задача довольно простая, но не совсем очевидная в рамках данного фреймворка. Есть большое количество готовых расширений для создания древовидных структур (меню, каталогов итд.), но довольно сложно найти решение, которое бы поддерживало полноценную работу с несколькими языками. Причём речь тут идёт не о переводе интерфейса штатными средствами фреймворка, а про хранение данных в базе на нескольких языках. Также достаточно сложно найти удобный и полностью работоспособный виджет для управления деревом, который мог бы также работать с многоязычным контентом без сложных манипуляций с кодом.
Я хотел бы поделиться рецептом того, как можно создавать подобные модули на примере реализации модуля меню. Для примера я буду использовать шаблон приложения Yii2 App Basic, но вы можете адаптировать всё под свой шаблон, если он отличается от базового.
Архитектура Redux. Да или нет?

Конференция про Python и про общение

Хотя, подождите, не спешите перескакивать на следующую тему. На картинке выше написано: «Профессиональная конференция» — то есть, предназначена она для профессиональных разработчиков. Но гостями мы видим не только собственно Python-разработчиков, но еще программистов, преимущественно использующих другой стек, но заинтересованных в возможностях Python для вспомогательных задач. Последним должны зайти доклады, например, про Apache Kafka, Wagtail, SQLAlchemy или линтеры.
Павел 2.0: консультант-рептилоид на JS, node.js с сокетами и телефонией

Принципы SOLID, о которых должен знать каждый разработчик

Материал, перевод которого мы сегодня публикуем, посвящён основам SOLID и предназначен для начинающих разработчиков.

