В предыдущей статье у нас получился красивый слайдер («карусель») с круговым вращением. А сегодня я создам слайдер, пролистывающий стопку «полароидных» снимков.
Пока не смотрите код, сначала я должен вам многое про него рассказать. Поехали! К старту нашего курса по Fullstack-разработке на Python.
В этой статье я расскажу вам о том, как использовать API Google Analytics для получения данных и отображения их на своём сайте самым простым способом.
Прочитав эту статью, вы сможете с легкостью использовать это в своем проекте. Итак, без дальнейших объяснений, давайте перейдем к делу.
Здравствуй, уважаемый Хабр!
Хочу представить вашему вниманию еще одно видение инструмента, предназначенного для оптимизации затрат на разработку информационных систем.
Продолжим строить подобие JSON-RPC сервера, начатого в части 1 и анализировать его плюсы и минусы. В прошлой статье был описан механизм отделения бизнес логики бэкенда от транспортного протокола (HTTP) через шаблон проектирования "Front Controller", роль которого исполняет в нашем случае JsonRpcController.
Бэкенд API до передачи запроса в код, отвечающий за бизнес логику, обычно предоставляет частичный функционал API шлюза (API gateway) - он может делать аутентификацию, авторизацию, роутинг, валидацию данных, логгирование, кэширование, обеспечивать меры безопасности и другое.
Продолжение поста про интеграцию с ГИС ЖКХ - https://habr.com/en/post/710462/
В этой части разберём как правильно подписать xml-запрос в php при помощи openssl
В этой статье я не разбираю почему xmldsig формируется именно так - я привожу пример реализации. Поэтому я ожидаю, что вы уже знакомы с основными понятиями и алгоритмом подписания по xmldsig.
Будем использовать модифицированную версию openssl из первого поста, поэтому он обязателен к прочтению
В основе всего лежит базовый класс Xml, наследуемый от DOMDocument:
Это ода данному посту и его законное продолжение.
Реализация описана для PHP, но подходит для всех.
Конфиги
Начнём с контейнера, из которого будем общаться с ГИС ЖКХ. Тут приведён конфиг контейнера с продакшена, поэтому есть лишние (для вас) пакеты.
Пока просто посмотрим, пояснения будут после кода.
Привет, Хабр! Все знают что для того, чтобы ваш сайт увидели поисковые роботы вам нужен SSR. Но единственное ли это решение? Всегда ли он нужен? Есть ли другие варианты роботам увидеть контент? Что мы можем выиграть от альтернатив?
В этой статье рассмотрим альтернативное решение для SSR, а именно Динамический рендеринг (он же Пререндеринг).
Всем привет, сегодня я хотел бы подискутировать на примере "очередной революции" в так называемом WEB 3.0 от команды TON, как развивается веб и в целом куда мы идем, статья не претендует на истину, все ниже изложенное является личным мнением автора.
Слайдеры изображений, также известные как карусели картинок, очень распространены. Есть множество вариантов обычного CSS-слайдера, в котором изображения смещаются слева направо (или наоборот). Можно использовать JavaScript-библиотеки для создания красивых слайдеров со сложной анимацией. Но здесь я подойду к созданию карусели иначе.
В серии статей я расскажу вам, как создать необычные и красивые слайдеры исключительно в CSS. Если вы устали от одинаковых слайдеров, вам это понравится! Продолжение — к старту нашего курса по Fullstack-разработке на Python.
Привет, друзья!
В этой статья я немного расскажу вам о Bun — новой среде выполнения JavaScript-кода.
Обратите внимание: Bun — это экспериментальная штуковина, поэтому использовать ее для разработки производственных приложений пока не рекомендуется.
Интересно? Тогда прошу под кат.
В прошлой заметке я представил общественности шаблон проектирования Мейоз, как способ управления состоянием одностраничного javascript приложения. Шаблон не связан с конкретной библиотекой рендеринга, и опирается исключительно на небольшую функцию stream и нативную реализацию объекта Array в javascript.
Идея шаблона заключается в использовании streams (потоков) для хранения состояния приложения, глобального или локального (например состояния html формы), связывания, свертки и комбинации потоков в функциональном стиле. Шаблон предлагает использовать определенные реактивные структуры данных, но не обязательно буквально так как это делает автор. В рамках шаблона можно реализовать любое удобное и понятное поведение приложения.
В этой заметке я перепишу небольшое приложение "Кубики", и вместо библиотеки mithril для рендеринга будем пользоваться reactjs. Будем использовать потоки для управления глобальным и локальным состоянием, а так же, сервисы — объекты, определяющие функции, которые выполняются всякий раз, когда изменяется состояние.
Упаковка веб-приложения в Docker - довольно простая задача, если разобраться с базовыми понятиями работы контейнеров. Готовим контейнер для бэкенда, для базы данных, для фронтенд-приложения - и вуаля, приложение полноценно функционирует. В большинстве случае стандартная настройка сети и конфигурация в Docker покрывает все нужды разработчиков.
Но в данной конкретной ситуации, несмотря на кажущуюся простоту структуры проекта, этой базовой конфигурации оказалось мало.
Всем привет!
Все мы прекрасно знаем что построить полноценный стор на react context достаточно тяжело, а оптимизировать его ещё тяжелее.
А что если я расскажу как это можно сделать быстро и просто?
Возможно, вы уже попадали в ситуацию, когда во время пика продаж сервер, на котором расположен ваш интернет-магазин или другой проект, приносящий прибыль, выходит из строя.
К сожалению, даже надежная техника может отказать в самый неподходящий момент. На сервере могут возникнуть проблемы с дисками, дисковыми и сетевыми контролерами, оперативной памятью, блоком питания и другим оборудованием. В дата-центре, где находится ваш сервер, могут отказать каналы передачи данных, электропитание или даже случиться пожар.
Конечно, можно отремонтировать сервер или установить новый в том же или в другом дата-центре. Но на ремонт или аренду нового сервера с последующей подготовкой его к работе, на восстановление данных из бекапа может уйти очень много времени.
А есть ли способы, защитить ваш интернет-магазин или другой сервис от таких проблем?
Да, конечно, есть, и не один, но также есть и множество нюансов.
К сожалению, обычно отказоустойчивое решение стоит очень и очень дорого. Даже в простых конфигурациях ежемесячные расходы могут достигать 100–200 тысяч рублей и больше. Немало средств придется потратить и на первоначальную настройку. Но есть и недорогие решения.
Эта статья поможет вам настроить доступный вариант отказоустойчивости, созданный на базе технологии VRRP (Virtual Router Redundancy Protocol) и сервиса keepalived.
Такой вариант подойдет, если у вас нет возможности использовать, например, весьма дорогостоящие в эксплуатации контейнеры, систему Kubernetes или отказоустойчивые облака, а весь проект размещается на одном сервере. Описанная в статье технология будет полезна, если многократное увеличение расходов на оборудование и сопровождение при внедрении отказоустойчивости крайне нежелательно.
Однажды я захотел создать небольшую NPM библиотеку по всем “best practices” - с покрытием тестами, написанием документации, ведением нормального версионирования и changelog'а и т.п. Даже написал пару статей, которые в деталях описали, какие вопросы решает библиотека и как её использовать. И одной из интересных для меня меня задач при создании библиотеки была задача по максимальному уменьшению размера выходного NPM пакета - того, что в конечном итоге в теории будет использовать другой программист. И в этой статье я бы хотел описать, к каким методам я прибегал для того, чтобы достигнуть желанной цели.
Vuetify - один из самых популярных Material Design фреймворков для Vue, которому недавно исполнилось 6 лет. И 6 января 2023 года его основатель заявил, что проект Vuetify перестал окупаться и он ищет работу. Отсюда - некролог в названии статьи.
Статья состоит из шести небольших частей, в которых мы пробежимся от первой версии до третьей, посередине разобрав, как фреймворк обновлялся до Vue 3, будем вместе смотреть за поведением основателя движка, а также тем, как можно справиться с переходом на Vue 3, пожалуй, хуже, чем кто-либо еще, включая команду Nuxt.
В этом, надеюсь, преждевременном некрологе я расскажу, где Vuetify был 6 лет назад, почему он был так популярен, где он сейчас и как вошел в кризисное состояние.
Каждый день мы пользуемся десятками различных мобильных приложений и посещаем десятки, если не сотни, всевозможных сайтов. Часто при этом мы сталкиваемся с какими-то их неприятными особенностями — что-то сделано недостаточно продуманно, где-то разработчик запилил фичу спустя рукава. И всё бы ничего, но некоторые из этих моментов по-настоящему вездесущи, встречаются ежедневно и неимоверно раздражают.
В этой статье я попытался перечислить некоторые из таких наиболее распространённых косяков. Если вы отвечаете за разработку/дизайн/менеджмент какого-либо сайта или приложения, пожалуйста, никогда так не делайте. Правда, ну сколько можно...
Для передачи данных по сети есть хорошо зарекомендовавшие себя стандарты - например, SOAP, gRPC, AMQP, REST, GraphQL.
При создании вебсайтов малой, средней и большой сложности с потоками данных к бэкенду и обратно в JSON формате обычно используются последние два с их вариантами. Верней, только варианты, потому что REST и GraphQL - ресурсо-ориентированные стандарты. Это как бы просто перенос элементарной работы с базой данных на клиента (хотя под "ресурсом" может пониматься и абстракция). Обычно таких запросов не больше трети от всего бэкенд API.
Попытка сделать весь API максимально RESTful страшно раздувает код и грузит сеть. Потому что остальные две трети запросов - в форме команд на бэкенд проделать какие-то действия, слабо отображающиеся на CRUD над некими ресурсами. И вариантов послать такие запросы достаточно много. Даже, чересчур.
Простой и красивый синтаксис, множество библиотек под самые разные задачи и большое комьюнити делают Python одним из самых популярных языков программирования на сегодняшний день, который активно используется в data science и машинном обучении, веб-разработке и других областях программирования.
Когда я начал изучать питон, у меня возникло несколько вопросов.
