Разработка веб-сайтов *

Давайте без лишних слов разберёмся, какие бывают типы значений у CSS-свойств, и определим, чем отличаются абсолютные и относительные значения (все эти em, rem, vh, vw), как задать красный цвет шестью способами, и зачем нужны CSS-директивы.

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

— Окей, Гугл! Переведи мне вот эту страницу, пора сделать мультиязычный сайт!

Иногда кажется, что именно по такому принципу некоторые и добавляют версии сайта на других языках. Кривые переводы, поплывшая верстка, куски невесть откуда взявшихся текстов или очередной lorem ipsum вместо контента. Знакомо, правда?

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

Меня зовут Илья, я фронтенд-разработчик в команде BuyerX. Раньше я публиковал статью о том, как мы пришли к использованию монорепозитория в нашем юните и какие проблемы решило его использование. В этот раз хочу поделиться чуть менее радостным опытом и рассказать, как получилось так, что потребовалось почти полтора года, чтобы перевести две кнопки со страницы объявления на React.

Нативная поддержка JSON одно из преимуществ разработки full-stack JavaScript приложений. JSON является простым, не требующим схемы и человекочитаемым - качества особенно ценимые на ранней стадии разработки, когда ваша модель данных подвержена частым изменениям. Однако за все надо платить, а именно размером и скоростью обработки данных.

JSON будучи текстовым форматом кодирует все значения как UTF-8, что приводит к увеличению размера данных при работе с нетекстовыми данными. Отсутствие схемы означает, что мы должны кодировать нашу структуру данных (ключи объекта) вместе с самими данными. Мы также делаем дополнительную работу при обработке данных, поскольку нам необходимо преобразовать бинарные данные в их текстовое представление до превращения в JSON и соответственно наоборот в случае декодирования.

Привет, Хабр! Сегодня хочется поговорить про XPath — мощный и гибкий инструмент для работы с веб-интерфейсами, который при этом почему-то остается не особенно популярным. Статей и мануалов по XPath очень много, и в этом посте я постараюсь рассказать, как мы применяем данный инструмент и почему считаем его более эффективным, чем другие подходы. Если вам знаком термин “селектор”, а тем более — если вы слышали про XPath, добро пожаловать под кат, там много полезного!

От переводчика: Этот пост является продолжением поста о реализация паттернов React-компонентов в Ember.js. Автор рассматривает концепцию React-хуков для абстракции логики состояния (stateful logic) и сравнивает ее реализацию с реализацией в Ember. И хотя в экосистеме React эта концепция признана весьма полезной, в Ember.js попытки предложить похожую не нашли особенного отклика. Причина этому - наличие в фреймворке достаточных инструментов для решения этой задачи без использования хуков. О каких инструментах идет речь, вы узнаете из этого материала.

Этот материал — карманный справочник о том, как работать с цветом в CSS и вебе в целом. Он начинается с теоретических основ и содержит множество инструментов и примеров работы с градиентами, анимацией, SVG и не только.

Статья будет полезна и новичку, и специалисту с опытом. За подробностями приглашаем под кат, пока у нас начинается курс по Frontend-разработке.

Создание общедоступного URL в сети интернет к вашему локальному проекту

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

Немного предыстории...

Присоединившись к новому большому проекту, над которым работают десятки разработчиков и QA специалистов, я столкнулся с тем, что разработка ведется удаленно на специально выделенных серверах.

А т.к. я уже несколько лет разработку приложений веду исключительно в докере, я никак не мог адаптироваться к текущему подходу.

Думаю все, кто более менее освоил работу в докере, уже не мыслят как можно разрабатывать без него. Причин на это много. Конечно, как и везде у докера есть своя цена и это тоже уже много раз обсуждалось.

Итак, новый проект не похож на предыдущие. Он имеет много зависимостей с другими сервисами, как внутренними так и внешними.

Большое количество внешних интерграций порождало проблему связи локального приложения с внешним миром. И если объединить внутренние сервисы используя docker netwokr не вызывало каких либо проблем, то необходимость связать внешний сервис уже требовал дополнительных инструментов.

Интеграции платежных систем всегда подразумевает, что будут callback (notification).

При такой необходимости, часто выбирают Ngrok. Хорошее решение, но в удобном варианте - платное. Особенно это ощущается, когда разработчиков много.

Т.к. Ngrok не подходил, первое что пришло в голову, создать виртуалку, на нее завести домен, и создавать ssh туннель с ним.

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

И вот, спустя пять лет случается флешбэк — выходит статья о нагрузочном тестировании Azure, в которой автор добивается 4 запроса в секунду за 250$ в месяц. Тут уж я просто не мог пройти мимо. Ведь не может такого быть, чтобы второе по величине облако давало так мало за не самые маленькие деньги, правильно? Поэтому я очень быстро набросал простейшее веб приложение на .NET, накатил базу StackOverflow за 2010 год, запустил туда скромную нагрузку в 100 RPS и стал судорожно протирать свои глаза. Даже такую нагрузку мое приложение не держало, причем вообще. 50 RPS тоже оказались слишком высокой планкой, как, впрочем, и 25. И тут я понял, что так дело не пойдет — к вопросу надо подходить системно.

Итак, кому интересно сколько стоит 100 RPS в Azure с .NET Core MVC + .NET 5 + MSSQL на Kestrel — берите кофей и прошу под кат.

Я уже публиковал свою точку зрения, что Progressive Web Applications - это, прежде всего, технология для мобильных устройств. Основная особенность классических web-приложений - это клиент-серверная архитектура, а основная особенность "прогрессивных" web-приложений - возможность работы в offline. Понятно, что это очень сильно разные подходы в архитектуре - "всегда на связи" и "всё своё с собой". Совместить два таких разных подхода в одном приложении "это очень дорого и ни к чему".

Отталкиваясь от этой своей точки зрения, я решил посмотреть текущую статистику по браузерами - какие на данный момент у PWA-приложения возможности стать популярным и на какие браузеры оно должно ориентироваться. Данные для публикации взяты с сайта gs.statcounter.com

Привет, друзья!

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

Основной функционал нашего приложения будет следующим:

• админка с возможностью добавления данных (далее — проекты) путем их набора (ввода) или копирования/вставки, либо путем загрузки файла;
• сохранение проектов на сервере;
• безопасная запись, чтение и удаление файлов на любом уровне вложенности;
• получение названий существующих проектов и их отображение в админке;
• возможность редактирования и удаления проектов;
• унифицированная обработка GET, POST, PUT и DELETE запросов к любому существующему проекту, включая GET-запросы, содержащие параметры и строки запроса;
• обработка специальных параметров строки запроса sort, order, limit и offset;
• и многое другое.

Наша админка будет выглядеть так:

Для быстрой стилизации приложения будет использоваться Bootstrap.

Исходный код проекта находится здесь.

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

При разработке приложения мы будет придерживаться 2 важных условий:

• формат данных — JSON;
• основная форма данных — массив.

Обратите внимание: статья рассчитана, преимущественно, на начинающих разработчиков, хотя, смею надеяться, что и опытные найдут в ней что-нибудь интересное для себя.

Вы готовы? Тогда вперед.

Всем привет! Меня зовут Петр Солопов, я руководитель отдела фронтенд-разработки в SuperJob. Думаю, многие из вас видели популярную серию картинок в интернете про фронтенд и бэкенд: на бекенде всегда какой-то монстр, а на фронте — все мило, летают бабочки. На мой взгляд, это не соответствует действительности и все не так радужно и безоблачно: чего только стоят настройка Webpack, тона зависимостей, особенности фреймворков и многое другое. За подробностями под кат.

От переводчика: Я прототипирую интерфейсы на Ember.js. И всегда испытываю трудности, когда нужно переключиться на React и написать что-нибудь используя этот de facto выбор по-умолчанию в современной фронт-энд разработке. Каждый раз сталкиваешься с трудностями на ровном месте и вынужден думать о том, о чем привык не думать, писать велосипеды. Мне всегда хотелось это как-то выразить и на днях я нашел статью, где автор очень наглядно показывает разницу на кодовых примерах. Представляю вашему вниманию ее перевод.

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

Хотя я никоим образом не являюсь экспертом по React, всегда интересно наблюдать, как другие js-сообщества решают сходные с нашими проблемы при реализации SPA-приложений. Я не могу авторитетно говорить о качестве реализаций обсуждаемых шаблонов компонентов, но, судя по тому, что я видел в открытом доступе и читал о паттернах компонентов в React, похоже, эти подходы достаточно активно используются разработчиками. А поскольку проблемы, с которыми мы сталкиваемся при разработке клиентских приложений, одинаковы для разных экосистем, идеи, лежащие в их основе, интересны разработчикам, независимо от их вероисповедания выбора фреймворка.

Владимир Матасов, выпускник курса Skillbox по веб-вёрстке, рассказал о своём опыте работы с плагином Emmet. Также подготовил инструкции по основным возможностям и командам для начинающих верстальщиков.

Около десяти лет назад сообщество веб-разработчиков впервые начало обсуждать концепцию "Single-Page Application" и искать способы ее реализации. К тому моменту разработка графических интерфейсов уже не являлась чем-то новым и поэтому многие вещи заимствовались у существующих решений и немного адаптировались под специфику браузеров.

Наиболее успешным результатом подобной работы оказался Backbone.js — объектно-ориентированный MVC-фреймворк, который в свое время использовался в BitBucket, Basecamp, Stripe, Airbnb и Trello. Со временем он был полностью вытеснен следующим поколением фреймворков, но...

Что если бы этого не случилось? Как бы тогда выглядела современная разработка веб-интерфейсов?