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

Привет, Хабр! Я участвую в разработке ECM системы. И в небольшом цикле статей хочу поделится нашим опытом и историей разработки своего React Data Grid (далее просто грид), а именно:

• почему мы отказались от готовых компонент
• с какими проблемами и задачами мы столкнули при разработке своего грида
• какой профит дает разработка своего грида

Предыстория

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

Практически любой сайт сегодня использует cookies, а если на него хотя бы иногда заходят пользователи из Европы, то сразу встает вопрос о соблюдении GDPR.

Те, кто не хочет вникать в юридические тонкости европейского регламента могут проверить cookies на соответствие GDPR и сразу получить отчет по сайту. Я же, в который раз озадачившись необходимостью установки на своих проектах cookie-баннера для европейских посетителей, взялся изучить вопрос cookies и GDPR более подробно.

У нас, у фронтендеров, есть такая категория инструментов, которые никак не решают стоящие перед нами задачи, а скорее влияют на сам процесс их решения. Изменяют его. Отношение к таким инструментам самое разное – начиная от мании в духе “давайте эту штуку пихать везде, это же так круто” и заканчивая отговорками вроде “раз не решает задачи бизнеса, значит оно нам не нужно”. Но, так или иначе, сегодня мы поговорим про PostCSS — один из таких инструментов.

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

Читаю блог Поселка программистов и радуюсь за ребят. Устроить такое — убедить семьи, потянуть финансово, преодолеть бюрократию, найти единомышленников. На грани фантастики.

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

Но реальность сурова. Работа второй половинки не подразумевает удаленности, дети ходят в какую-то конкретную городскую школу. Бабушки-дедушки, родственники — все здесь, рядом. Рвать все связи и уезжать далеко в лес к единомышленникам, к сожалению, не вариант. Бросить всех и уехать на зиму в какой-нибудь Тайланд — тоже...

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

Наверняка многие слышали понятие MVP (Минимально жизнеспособный продукт вики). На хабре тоже много статей про MVP, но в основном это или просто описание что такое MVP и для чего оно, или различные success и не очень story. Но я не нашел ни одной статьи, где бы описывалось на чем кто свое это MVP делал. Но ведь считается, что блоги личные проще делать на одном движке, интернет-магазины на другом и т.п. (каждый подставит свое название любимого движка для этих целей). Но почему тогда не определен более удобный движок для MVP? Я не дам четкого ответа на этот вопрос, но поделюсь своими мыслями чем именно для создания MVP хороша моя Prisma CMS, о которой я писал здесь пару месяцев назад. Кому интересно, прошу под кат.

Сегодня я был изумлен тем, как обычно позитивное и дружелюбное сообщество Vue.js скатилось в печальное противостояние. Две недели назад создатель Vue Эван Ю опубликовал предложение (RFC) с новым функциональным API для компонентов в грядущем Vue 3.0. Сегодня критическое обсуждение на Reddit и аналогичные комментарии на Hacker News вызвали наплыв разработчиков в изначальный RFC с возмущениями, порой даже чересчур резкими.

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

Друзья, добрый день!

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

Поскольку я предпочитаю методологию БЭМ, начав работать с opencart, я сразу же столкнулся с ужасными для меня вещами, это вложенные селекторы. Они повсюду! Начиная от шаблона по умолчанию, заканчивая практически всеми модулями и авторскими шаблонами. Почему так? Мне кажется тут ряд причин:

Поговорим о JMeter’е? Скорее всего, если вы в теме, то давно уже прочли всё об этом инструменте для нагрузочного тестирования. Но мне есть чем вас удивить. За три года работы в QA я понял, что JMeter очень универсален и может использоваться в самых разных целях. Например, для:

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

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

Я пишу это в основном для себя в будущем, чтобы у меня было куда сослаться, когда кто-нибудь спросит меня, почему я скептичен в отношении веб-компонентов и почему Svelte не компилируется в веб-компоненты по умолчанию. (Тем не менее, он может компилироваться в веб-компоненты, а так же интегрироваться с ними, что подтверждается превосходной оценкой на Custom Elements Everywhere).

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

Анимация в приложениях React — популярная и обсуждаемая тема. Дело в том, что способов ее создания очень много. Некоторые разработчики используют CSS, добавляя теги в HTML-классы. Отличный способ, его стоит применять. Но, если вы хотите работать со сложными видами анимаций, стоит уделить время изучению GreenSock, это популярная и мощная платформа. Также для создания анимаций существует масса библиотек и компонентов. Давайте поговорим о них.

Веб стремительно меняется, не отставай и ты!

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

Давайте-ка шаг за шагом разберём важнейшие принципы веб-дизайна в 2019 году.

Обязательно дайте пользователю знать, что у сайта есть мобильное приложение

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

Ну а кратчайший путь к этому — показать здоровенное модальное окно:

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

Совет: Если у вас нет мобильного приложения, не беда! Просто запихните весь сайт в  webview с отключенной безопасностью и пишите, что это мобильное приложение!

Основная идея проекта — формализация взаимодействия между внутренней ИБ и внешними исследователями, давая четкое указание как и куда направлять информацию об уязвимостях или проблемах безопасности. Формализация взаимодействия — серьезная проблема, не все сайты имеют программы bug bounty, или даже просто указывают контакты специалистов по безопасности. А попытки достучаться через службу поддержки и твиттер зачастую заканчиваются уверениями что «Все так и должно быть», и последующим игнорированием.

Конечно, это будет работать только если компания, размещающая информацию в security.txt, готова проверять и своевременно реагировать на информацию, полученную через этот канал.

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



Здесь представлено 13 однострочников. Примеры подготовлены с использованием Node.js v11.x. Если вы будете использовать их в другой среде — это может повлиять на их выполнение.

В 2013 году я начал понимать, что утечки приватных данных становятся повсеместными. Действительно, такие случаи участились. И возросло влияние этих утечек на их жертв, включая меня. Всё чаще я писал в блоге на эту тему, которая казалась увлекательным сегментом индустрии инфобеза: как повторное использование паролей на Gawker и Twitter привело к массовому черничному спаму в твиттере, и о том, что пароли юзеров Sony Pictures оказались действительно настолько плохими, насколько можно было ожидать от этих людей, но чёрт побери, до сих пор шокирует видеть свой пароль в этой утёкшей базе. При этом 59% паролей из базы Sony совпадали с паролями от почтовых ящиков Yahoo.

Примерно в то время произошла утечка данных Adobe, и это заставило меня действительно заинтересоваться данным сегментом отрасли, не в последнюю очередь потому, что я был в той базе. Дважды. Самое главное, что она содержала 153 млн других людей. Это была исключительно массовая утечка, даже по сегодняшним стандартам. Всё это вместе — частота утечек, мой анализ баз и масштаб Adobe — заставили меня задуматься: интересно, сколько людей знают? Понимают ли они, что их данные ушли в открытый доступ? Понимают ли, сколько раз? И, возможно, самое главное: изменили ли они свой пароль (да, почти всегда единственный) в других службах, которые используют? И так родился проект Have I Been Pwned (HIBP): поиск своих паролей в множестве утёкших баз.

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

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

В этой статье расскажем, как мы настроили выборочное логирование трафика для сервисов SOAP.

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



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

В статье пойдет речь о том, какую пользу оказывает логирование. Расскажу о логах по PSR. Добавлю немного личных рекомендаций по работе с уровнем, сообщением и контекстом логируемого события. Будет приведен пример, как можно организовать логирование и мониторинг с помощью ELK в приложении, написанном на Laravel и запущенном через Docker на нескольких инстансах. Распишу важное правило системы оповещения. Приведу пример скрипта, который поднимает одной командой весь стек мониторинга.