Каждому, кто вложил свои силы в создание сайта или приложения, очень не хочется потерять все данные. Но какая техника не даёт 100% надёжности. Поэтому для сохранности чрезвычайно важно создавать резервные копии.
Причины потери данных могут быть самые разные:
сбой оборудования или программного обеспечения,
ошибка персонала (как разработчика, таки хостера),
хакерская атака,
злонамеренные действия сотрудников.
При этом важно:
копии должны создаваться регулярно и автоматически,
резервная должна храниться физически на другом устройстве,
в случае удаления данных из рабочей базы, они не должны удалиться из резервной копии,
периодически нужно тестировать резервные копии, чтобы убедиться, что из них действительно можно восстановить полную копию сайта.
Лучшим способом тестирования является периодическое развёртывание отдельной копии сайта. При этом это также полезно и для тестирования новых функций сайта, которые пока не нужно выкладывать для пользователей.
Когда разрабатывается приложения для бизнеса, часто результатом являются данные в табличном виде. Например, это может быть таблица заказов, поступлений, клиентов и т.п. При этом многие менеджеры и аналитики привыкли использовать Excel для работы с такими данными. Поэтому важной задачей становится возможность легко перенести данные в Excel для дальнейшей работы.
При этом собственный формат файлов Microsoft Excel достаточно сложный, генерация такого файла в веб-приложении сопряжено с трудностями. Более простым и быстрым в реализации является генерация файла в формате CSV. Формат этих файлов очень простой, но при этом Excel может открывать эти файлы также, как и обычные таблицы.
Преимущества генерации файлов CSV:
малый размер файлов,
возможность вставки числовых и строковых данных,
совместимость с Microsoft Excel и другими офисными пакетами,
поддержка русского языка при указании правильной кодировки.
Ограничения:
только один лист данных,
нет возможность использования формул в генерируемом файле (обычно это и не требуется, формулы добавляются на этапе обработки).
При разработке веб-приложений для бизнеса частой задачей является генерация печатного документа. Например, пользователь веб-приложения, являющийся юридическим лицом может запросить счёт на оплату его услуг. При этом счёт обычно формируется по установленной форме, т.к. он является важным документом бухгалтерского учёта. Другим примером является генерация билета на мероприятие, который пользователь должен распечатать и предъявить на входе.
Теоретически можно отправить на печать саму веб-страницу, в некоторых веб-приложениях так и поступают. Между тем такой способ формирования печатного документа влечёт за собой сложности, связанные с тем, что конечный вид документа плохо предсказуем. Конкретный вид документа может отличаться в зависимости от используемого веб-браузера, операционной системы, установленных шрифтов, настроек отображения и печати браузера и операционной системы.
Универсальным решением является генерация конечного документа в формате PDF. Этот формат позволяет обеспечить единообразие внешнего вида документа на любых устройствах. В том числе в файл можно встроить используемые шрифты, чтобы отображение не зависело от того, установлен ли в системе используемый шрифт.
Важным ограничением является то, что файлы в формате PDF с большим трудом поддаются последующему редактированию, поэтому мы в Эвритеке используем генерацию PDF только в том случае, когда документ уже сформирован полностью в готовом виде. Если предполагается дальнейшее его редактирование пользователем, то вместо PDF мы используем генерацию документов в формате Word.
Темная тема, или Dark Mode, становится все более популярной в веб-дизайне и приложениях. Она предлагает ряд преимуществ и недостатков, которые стоит учитывать при ее внедрении.
Преимущества темной темы
Снижение утомляемости глаз: Темная тема уменьшает нагрузку на глаза, особенно в условиях низкой освещенности. Это связано с тем, что яркий свет от экранов может вызывать дискомфорт и усталость. Исследования показывают, что использование темного фона может помочь снизить напряжение глаз, особенно при длительном чтении.
Экономия заряда батареи: На устройствах с OLED-экранами темная тема может значительно экономить заряд батареи, так как темные пиксели потребляют меньше энергии. В некоторых случаях экономия достигает 20%.
Визуальная привлекательность: Многие пользователи предпочитают стильный и современный вид темной темы. Она может создать атмосферу премиум-контента и помочь выделить важные элементы интерфейса.
Улучшение концентрации: Темная тема может помочь пользователям сосредоточиться на контенте, поскольку фон менее отвлекает внимание от текста или изображений.
Недостатки темной темы
Проблемы с восприятием текста: Текст на темном фоне иногда труднее читать, особенно при ярком свете. Исследования показывают, что светлый фон обычно способствует лучшему восприятию информации и снижению ошибок при чтении15.
Менее эмоциональный дизайн: Темные цвета могут создавать более мрачное настроение, что не всегда подходит для всех типов контента, например, для детских сайтов.
Тёмная и светлая тема на сайтах, разработанных Эвритекой
Когда мы делаем сайт или приложение для широкого круга посетителей, мы предусматриваем возможность работы как в светлой, так и в тёмной теме. Выбор темы определяется настройками операционной системы смартфона или компьютера пользователя. В некоторых случаях мы также добавляем и возможность ручного выбора.
На сегодняшний день любые статьи в интернете авторы стараются снабжать наглядными изображениями для лучшего восприятия. В итоге часто получается, что при открытии статьи необходимо клиенту загрузить сразу много изображений.
В обычном случае при открытии страницы браузер загружает все изображения, которые должны отображаться на странице. В том числе будут загружены и те, которые находятся далеко внизу по тексту страницы и не факт, что пользовать вообще прокрутит страницу достаточно вниз для того, чтобы эти изображения были загружены.
Для оптимизации работы мы в Эвритеке во всех случаях, когда производительность страницы важна, предлагаем использовать «ленивую» загрузку. В этом случае определяется размер экрана и загружаются только те изображения которые требуется отображать на текущий момент. По мере того как пользователь будет прокручивать страницу, остальные изображения также будут подгружаться.
Ранее для реализации «ленивой» загрузки приходилось внедрять на страницу специальный скрипт, который реализует эту логику. Но теперь в этом нет необходимости, поскольку современные браузеры имеют встроенную поддержку «ленивой» загрузки.
Если у вас есть концепция приложения, обычно работа над реализацией начинается с проектирования. В ходе проектирования нужно будет выяснить:
какие пользователи будут у приложения,
какие данные будет хранить или обрабатывать приложение,
из каких страниц будет состоять приложение,
с какими внешними системами нужна интеграция,
какие есть требования по надёжности и безопасности,
какая ожидается нагрузка на приложение.
На основании этого формируется:
архитектура информационной системы,
схема базы данных,
скетчи страниц.
Проектирование позволяет:
оценить затраты на разработку,
сформировать техническое задание,
начать работать над дизайном страниц.
Часто проектированием и разработкой занимаются разные команды. Проектировщик формирует техническое задание, на основании которого ищется разработчик. Мы же в Эвритеке выполняем проектирование и разработку в рамках одной команды, что позволяет избежать лишних сложностей при передаче задания другой команде, обеспечить максимальную эффективность проектирования. Мы не только проектируем, но и несём ответственность за реализуемость сформированных решений.
При разработке веб-приложения для задач бизнеса часто результатом является формирование какого-либо документа в бумажном или электронном виде.
Для работы с документами обычно применяется текстовый редактор Microsoft Word, либо его ближайшие аналоги, такие как OpenOffice. Чаще всего удобно хранить данные именно в формате Word для того, чтобы не было проблем с передачей документов контрагентам, в бухгалтерию, в государственные органы.
В таких случаях наша команда реализует формирование документа в формате Microsoft Word — docx.
При этом в таком документе могут быть:
текст с разного рода форматированием,
таблицы,
изображения,
колонтитулы, в том числе с нумерацией страниц,
могут использоваться любые шрифты, в том числе те, которые в системе пользователя не установлены.
В том числе документы могут быть оформлены на фирменном бланке организации.
В веб-приложении часто нужно, чтобы пользователь заполнил какую-то форму. Это может быть форма заказа товара или услуги, регистрация на сайте, вход в систему и т.д. Когда пользователь ввёл данные и нажал «Сохранить» или «Отправить», форма проверяется на валидность данных. Невозможно точно сказать, осмыслено ли то, что ввёл пользователь, но многие потенциальные ошибки можно отловить уже на этом этапе.
Например:
имя пользователя не должно быть пустым,
сумма заказа не должна быть отрицательной или нулевой,
e-mail не должен содержать русских букв,
номер телефона должен соответствовать принятому формату (состоять из 10 цифр, начинаться с +7 или 8),
товар, который заказывает пользователь, должен быть в наличии.
Валидация форм очень важна, чтобы не заполнять базу ошибочными данными. Но при этом всегда риск того, что пользователь не сможет ввести данные так, чтобы они прошли валидацию, что может привести к потере клиента и другим неблагоприятным последствиям.
Для того чтобы обеспечить адекватный компромисс между свободой пользователей вводить то, что они хотят, и проверкой корректности, мы стараемся придерживаться следующих правил.
сообщения об ошибках не выводятся, пока пользователь не заполнит форму до конца; если вывести ошибки сразу, пользователь может быть недоволен тем, что он ещё не заполнил форму до конца, а ему уже выводят ошибки,
все поля, обязательные для заполнения, явно отмечены; в некоторых случаях наоборот, мы помечаем необязательные поля,
даже если поля заполнены с ошибками, кнопка сохранения остаётся активной — при нажатии на неё выведутся сообщения об ошибках,
у каждого ошибочно введённого поля отображается сообщение на русском языке,
При разработке интерактивного текстового редактора часто есть необходимость дать пользователю возможно редактировать содержимое на сайте. Например, для новостного сайта часто нужна возможность, чтобы пользователи имели возможность сами присылать статьи. Также они могут подключать к работе независимых журналистов.
В сайтах и веб-приложениях используется формат HTML для отображения содержимого. Соответственно, если пользователю нужно предоставить возможность добавления статей на сайт, ему предоставляется редактор HTML. Это может быть интерактивный редактор, похожий на Word, который не требует от пользователя знания HTML-тегов, но внутри он будет всё равно являться редактором HTML.
Проблема в том, что если пользователь имеет возможность добавлять свой код HTML на сайт, то он может добавлять туда и скрипты, которые могут повлиять на работу сайта. А если этот пользователь является хакером, приварившимся независимым журналистом, то он вообще сможет перехватить контроль над сайтом. В связи с этим разработчики, которые заботятся о безопасности системы, не предоставляют внешним пользователям возможность редактировать HTML.
У нас есть решение этой проблемы — для хранения статей и другого подобного содержимого мы используем формат ProseMirror, который при необходимости легко преобразуется в HTML, но не даёт возможность произвольной вставки скриптов в код.
В веб-приложениях часто есть задача по редактированию текстовых документов. Это может быть статья для сайта, текст договора, научная статьи и т.п. В простых случаях можно просто сохранить содержимое, когда пользователь нажимает кнопку «Сохранить». Либо сделать автоматическое сохранение каждые несколько секунд.
Но при этом возникает проблема одновременного редактирования текста. Если в тот момент, когда пользователь открыл текст, начал вносить в него изменения, но пока ничего не сохранил, какой-то другой пользователь откроет тот же текст, отредактирует его и сохранит, то один пользователь затрёт все изменения другого. Кто-то из них потеряет результат своей работы. В случае же автоматического сохранения изменений это происходит ещё более неожиданно.
В некоторых компаниях пользователям даже приходится отдельно договариваться (на словах или писать друг другу в мессенджерах) о том, кто в какой момент определённый текст редактирует.
Самым правильным и эффективным решением является функция параллельного редактирования (его ещё называют одновременным или совместным редактированием, а в англоязычной среде это называют collaborate editing). В этом случае два (или более) пользователей могут открыть один и тот же текст и работать над ним. Все изменения автоматически в реальном времени синхронизуются — один пользователь может в реальном времени видеть, какие изменения вносит другой пользователь. В том числе это может работать и на мобильных устройствах. Наиболее известным инструментом с такой функцией является Google Docs.
Параллельное редактирование упрощает работу над контентом не только за счёт того, что решает проблему перезаписи изменений, но и за счёт того, что даёт возможность работать над документами в реальном времени.
Пользователи могут созвониться и совместно работать над документом. Это может быть очень полезно когда:
две стороны обсуждают условия договора или технического задания,
редактор работает с копирайтером,
ученик работать с учителем,
студент работает с научным руководителем,
два соавтора пытаются написать общий текст.
В админках сайта такая возможность редко бывает реализована. Но у нашей команды есть опыт реализации админок для работы в реальном времени для разных предметных областей.
