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

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

В большинстве случаев HTTP-запросы к серверу работают надёжно и возвращают желаемый результат. Однако в некоторых ситуациях запросы могут оказываться неудачными.

Представьте себе, как кто-то работает с вашим веб-сайтом через точку доступа в поезде, который несётся по стране со скоростью 200 километров в час. Сетевое соединение при таком раскладе может быть медленным, но запросы к серверу, несмотря на это, делают своё дело.

А что если поезд попадёт в туннель? Тут высока вероятность того, что связь с интернетом прервётся и веб-приложение не сможет «достучаться» до сервера. В этом случае пользователю придётся перезагрузить страницу приложения после того, как поезд выедет из туннеля и соединение с интернетом восстановится.

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

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



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

Я работаю с Реактом на протяжении почти 3 лет, использовал как Redux так и MobX и у меня к текущему моменту возник вопрос. Почему абсолютное большинство front-end разработчиков продолжают свято верить в то, что Redux + Redux Saga + Reselect + 100500 других библиотек «облегчающих» жизнь — это лучшее решение на сегодняшний момент? Я приведу 4 аргумента в пользу того, чтобы в следующем проекте вы использовали MobX вместо Redux.

В ежегодном опросе «The state of JavaScript» разработчики рассказывают о том, что они используют здесь и сейчас. Вопросы там знакомы и привычны фронтенд-сообществу. В 2019 году появился опрос «The state of CSS», который ввёл разработчиков в ступор. Оказывается, многие технологии разработчикам не знакомы, хотя большинство из них уже активно используются. Возможно, разработчики используют привычные инструменты и технологии, и не стремятся применять что-то новое? Возможно, просто нет задач под новые технологии? Зачем использовать CSS Grid, CSS Multi columns, там, где проще построить все на Flexbox? Возможно, это все касается старичков, а джуны уже и не знают про Flexbox и Float и в опросах не участвуют?



Сергей Попов (popovsergey), руководитель Лиги А, спикер и организатор конференций задался этими вопросами, провел свой мини-опрос и даже получил результаты от организаторов «The state of CSS». Всю информацию Сергей обработал, структурировал и получил срез фронтенд-сообщества: кто что знает и использует, где учатся верстальщики и сколько зарабатывают, какие технологии актуальны, а какие пора сдавать в переработку, и что изучать, чтобы применять всю мощь CSS. Расшифровка доклада — один из вариантов отчета по актуальному состоянию CSS, вместе с оригинальным отчетом «The state of CSS» подскажет, куда двигаться и какие технологии применять.

Осторожно, под катом много диаграмм и картинок, действительно много, но они все по делу. В хорошем качестве они тут.

С помощью Angular можно сделать всё что угодно. Или почти всё. Но иногда это коварное «почти» приводит к тому, что разработчик губит время, создавая обходные решения, или пытаясь понять, почему что-то происходит, или почему что-то не работает так, как ожидается.



Автор статьи, перевод которой мы сегодня публикуем, говорит, что хочет поделиться советами, которые помогут Angular-разработчикам сэкономить немного времени. Он собирается рассказать о подводных камнях Angular, с которыми ему (и не только ему) довелось встретиться.

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

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



Механизм замечательный, если бы не одно “но”. Для пользователя, который сталкивается с таким деревом впервые или же обращается к незнакомой ему части этого дерева, это не просто дерево, это целый темный лес. Причина проста — дерево может быть построено по разным принципам, размещение элементов в этой структуре обычно соответствует некоторой логике, но пользователь может не понимать по какому именно принципу все это устроено, а чтобы разобраться нужно просматривать это дерево глазами, часто читая наименование чуть ли не всех элементов в поисках подходящего.

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



1. Octotree

Если вы любите GitHub и помногу читаете код, то, вероятно, знаете, как неудобно устроен обзор GitHub-файлов онлайн. Теперь этот процесс можно упростить при помощи расширения Octotree. Здесь предоставляется панель инструментов с удобной навигацией, также поддерживающая приватные репозитории.

2. PerfectPixel by WellDoneCode

Это расширение позволяет разработчикам накладывать изображения полупрозрачным слоем поверх HTML и делать попиксельное сравнение.

3. GitHub Repository Size

Удобный и простой плагин, отображающий как объем отдельного репозитория, так и размер кажого файла в нем.

Что нынче с HTML во фронтенде? В последнее время я разговаривал со многими разработчиками. Похоже, что некоторые даже не разбираются в HTML. В смысле, кое-что они понимают. Они понимают, что такое div и что такое span, и когда всё выглядит хорошо и работает по щелчку, им этого хватает. До такой степени, что многие на вопрос о HTML отвечают: «О, да я сейчас всё делаю в React или Vue». Но на самом деле не имеет значения, что вы пишете только Javascript. Если вы разрабатываете веб-сайты, то HTML — это самое главное для вас. Это и есть веб.

Речь о том, что потребляется пользователем. Это UI и UX. Вот весь пакет. В порядке убывания важности: HTML, CSS и поведение (которое может быть обеспечено Javascript — а может и нет).

Я вижу проблему внизу этой технологической пирамиды. Наименьший общий знаменатель Сети. Основа. Ритм-группа. Савоярди всех десертов веба. Это HTML. И мне всё больше кажется, что целый пласт фронтенд-инженеров не знают или не понимают главной технологии фронтенда.

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



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

На PHDays 9 впервые в рамках кибербитвы The Standoff состоялся хакатон для разработчиков. Пока защитники и атакующие в течение двух дней боролись за контроль над городом, разработчики должны были обновлять заранее написанные и развернутые приложения, а также обеспечивать их бесперебойную работу под шквалом атак. Рассказываем, что из этого получилось.

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

Если продукт действительно новый и аналогов нет — все верно, делать можно что угодно, проверяя гипотезу за гипотезой, и SEO тут будет в последних рядах. Но если продукт уже известен, например, в соседнем регионе и есть шанс раскрутить его в вашем? Или инновационный продукт расширяет возможности хорошо известного? Тут уже есть от чего отталкиваться.

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

Привет, %username%!

RSA — первый широко используемый алгоритм асимметричной криптографии, который до сих пор популярен в индустрии. Он относительно прост, на первый взгляд. Шифрование и подпись RSA можно посчитать на листке бумаги, чем часто занимаются студенты на лабораторных работах.
Но существует просто огромное количество нюансов, без учёта которых вашу реализацию RSA сможет взломать даже ребёнок.

Вольный перевод публикации How React Hooks can replace React Router.
Автор Peter Ekene Eze.

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

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

С этой целью мы сравним React Router и hooksrouter на наглядных примерах. Для начала давайте поближе посмотрим на React Router.

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

• Это дорого. Почему я должен платить за регистрацию?
• Это долго. Транзакция может зависнуть на сутки и ничего не сделаешь.
• Это неудобно. Надо осваивать какие-то там криптокошельки, как-то их пополнять и т.п.

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

А можно ли сделать регистрацию через крипту удобной и бесплатной? И чтобы ничего более не надо было (ни юзернеймы придумывать, ни почту, ни телефон и т.п.). Я для себя ответил на этот вопрос положительно. И хотя вопросы реализации регистрации без емейлов и т.п. — это уже на совести конечного разработчика и выбранной платформы, но непосредственно бесплатную регистрацию через блокчейн — ethereum обеспечивает.

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

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

Если дефолтный порядок не устраивает, то разработчики прибегают к свойству z-index: оно даёт контроль над виртуальной осью z (глубиной), которая концептуально проходит «сквозь» страницу. Таким образом, элемент с более высоким z-index отображается «ближе» к пользователю, то есть рисуется поверх элементов с более низкими индексами.

В июне в Амстердаме прошлая очередная APIDays – конференция для всех, кто так или иначе создает и пользуется различными API. Темой конференции стал «расцвет контекстуальных коммуникаций», то есть коммуникаций, в которых обе стороны сразу и полностью понимают контекст общения. Звучит абстрактно, поэтому пара примеров: вам звонят с незнакомого номера. Соответственно, вы не знаете, кто звонит, откуда и с какой целью. И напротив, если вы делаете какую-то операцию в приложении интернет-банкинга и на каком-то шаге что-то пошло не так, вы можете прямо с этого шага позвонить в поддержку – контекст ситуации с ходу будет ясен как вам, так и оператору. Чтобы обеспечивать такую осведомленность, бизнесы используют коммуникационные платформы (CPaaS, Communications Platform as a Service), а те, в свою очередь, используют AI и Machine Learning. Именно об этом и рассказывал наш CEO Алексей Айларов, выступая на APIDays, а сегодня мы публикуем адаптацию июньского выступления.

Неделю назад я выступал на митапе по Node.JS, и многим обещал выложить запись выступления. Уже потом я понял, что мне не удалось вместить в регламентированные полчаса некоторые интересные факты. Да и сам я больше люблю читать, а не смотреть и слушать, поэтому решил выложить выступление в формате статьи. Впрочем, видео тоже будет в конце поста в разделе ссылок.

Рассказать я решил про набившую оскомину тему — жизнь в монолите. Об этом на хабре уже есть сотни статей, тысячи копий сломаны в комментах, истина давно погибла в спорах, но… Дело в том, что у нас в OneTwoTrip есть весьма специфический опыт, в отличие от многих людей, которые пишут про некие архитектурные паттерны в вакууме:

• Во-первых, нашему монолиту уже 9 лет.
• Во-вторых, всю жизнь он провёл под хайлоадом (сейчас это 23 млн запросов в час).
• А в NaN-ых, мы пишем наш монолит на Node.JS, который за эти 9 лет изменился до неузнаваемости. Да, мы начинали писать на ноде в 2010, безумству храбрых поём мы песню!

Так что всякой специфики и реального опыта у нас довольно много. Интересно? Поехали!

17 ноября 2018 года. Нас четверо. Настроение у всех приподнятое — прошли первый этап ШРИ, Школы разработки интферфейсов. Он состоял из лекций и домашних заданий: осваивали разные фронтендерские и околофротендерские технологии, инструменты, Скрам. Знали, что всё это придётся применять в боевом проекте на втором этапе. Но одно дело знать, и другое — действительно реализовать этот проект за ближайшие 5 недель.

Сейчас лето — то время года, когда во всём мире проводятся различные конференции и другие мероприятия. Программистов в эту пору буквально заваливает новой информацией, которую обычно бывает довольно непросто усвоить.

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



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

Всем привет, меня зовут Виталик, я senior фронтенд-разработчик Skyeng. Наша команда делает онлайн-платформу Vimbox для изучения английского языка. Примерно год назад мы с дизайнером доделали небольшой UI kit, искоренивший хаос в интерфейсе и кодовой базе.

Оказалось, что в компании не мы одни хотели UI kit, и к нам стали приходить другие команды за советом «как написать собственный». Нам удалось отговорить их от этой затеи, пообещав темизировать свой – это сэкономило компании сотни часов разработки. Выбирая решение, мы рассмотрели Angular Material, кастомизированные сборки и CSS Variables и в итоге остановились на последних, несмотря на их слабую совместимость с SCSS, основой имевшегося UI kit. Под катом – подробности того, что мы сделали.

Всем привет. Мы потихоньку выходим из тени и продолжаем серию статей о нашем продукте. После предыдущей обзорной статьи мы получили множество отзывов (преимущественно положительных), предложений и bug репортов. Сегодня мы покажем TestMace в деле и вы по достоинству сможете оценить некоторые фишки нашего приложения. Для более полного погружения советую обратиться к нашей документации по адресу http://docs-ru.testmace.com. Итак, поехали!