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

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

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

— Два месяца? На простейший функционал? Это неприемлемо! — вы пытаетесь давить, пугать, просить, торговаться; разработчики явно нервничают, но сроки не двигают. В итоге вы приходите к какому-то компромиссу, который не нравится никому, злые и недовольные. 

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

У меня несколько сайтов со статьями. Есть трафик и даже какие-то деньги я с них зарабатываю. Как раз тот случай, когда “просто закинуть на хостинг” - уже мало, а нанимать целую команду толковых программистов - ещё дорого.

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

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

С тех пор в разработке интерфейсов произошло море изменений: сначала в продакшн пришли флексы, потом подтянулись гриды, умер IE, все переехали из Фотошопа в Фигму, и много чего ещё. Каждое это изменение влияло на наши критерии, и мы постоянно их дорабатывали.

Сейчас пришло время обсудить с сообществом обновлённые критерии.

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

Введение

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

Представляю вашему вниманию результаты небольшого исследования, посвященного очистке данных, хранящихся на стороне клиента по сигналу сервера. Речь идет об относительно новом HTTP-заголовке Clear-Site-Data. Также в этой статье мы немного поговорим про карту импортов (imports map).

Статья состоит из двух частей: теоретической и практической.

В теоретической части мы кратко рассмотрим карту импортов и более подробно Clear-Site-Data.

В практической части мы поднимем два сервера — один будет запускаться локально и, помимо прочего, обслуживать статические файлы нашего приложения, другой мы развернем на Heroku. Сначала мы запросим данные (включая куки) от серверов, сохраним эти данные в браузере с помощью трех наиболее популярных механизмов (локальное хранилище, индексированная база данных и интерфейс кеширования), затем попробуем очистить их с помощью заголовков Clear-Site-Data. Для разрешения путей импортируемых в приложении модулей мы будем использовать карту импортов.

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

Emmet - это утилита для текстовых редакторов, которая упрощает и повышают скорость написания кода. Первоначально слово "Emmet" означало муравей - маленькое насекомое, которое может нести в 50 раз больше своего веса.

JSDoc - это язык разметки, используемый для аннотирования исходного кода JavaScript с использованием комментариев. Аннотации обрабатывается различными инструментами для создания документации в доступных форматах, таких как HTML и Rich Text Format.

Привет, Хабр! Несколько месяцев назад Wrike публично объявил об отказе дальнейшей разработки на Dart и переходе на новый стек.

Это было сложное решение. И, как это часто бывает во времена больших перемен, нам захотелось сравнить и провести параллели. А как происходила миграция у других компаний? Чем она была вызвана, и удалось ли завершить процесс перестройки без серьезных потерь? Мы попросили коллег поделиться своим опытом миграции на фронтенде, рассказать о всех сомнениях и трудностях, что встретились на этом пути. 

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

В интернете немало публикаций на тему реализации Dependency Injection (далее - DI) в React, также существует немало сторонних npm-пакетов, таких как inversify-react, react-simple-di и других. Но, по моему мнению, DI настолько просто реализуется средствами самого React, без дополнительных выкрутасов и boilerplate-кода, что никакая сторонняя библиотека во многих случаях попросту не нужна. В данной небольшой статье я постараюсь обосновать это свое мнение. Примеры кода будут приведены на TypeScript.

Предприниматель на старте своего дела не располагает большими деньгами. А самым доступным для него способом продвижения является Интернет. Как получить эффективный сайт и не прогадать?

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

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

Это перевод статьи Nic Chan «A Complete Guide To Accessibility Tooling» из журнала Smashing Magazine.

Бизнесы работают с клиентами через встречи, звонки, SMS, сайты и сообщения в социальных сетях. Чем больше этого общения вынесено в онлайн — тем оно быстрее для клиента и дешевле для бизнеса.

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

Теги img и picture предназначены для загрузки изображений. Каждый из них позволяет задать набор правил, согласно которым браузер будет выбирать, какое из изображений загружать. В статье рассмотрены синтаксис и различия данных тегов.

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

Предлагаю вашему вниманию результаты небольшого исследования, посвященного сравнению Redux и Vuex. Это вторая часть статьи, вот ссылка на первую.

Введение

Redux и Vuex — это библиотеки для управления состоянием приложений, написанных на React и Vue, соответственно. Каждая из них по-своему реализует архитектуру для создания пользовательских интерфейсов, известную под названием Flux.

Немного зная теорию музыки, чтобы создать цифровой инструмент, мы можем воспользоваться простыми HTML, CSS и JavaScript без каких-либо библиотек или аудиосэмплов. К старту курса по Frontend-разработке делимся статьёй, автор которой рассказывает, как написать простой, но эффектный синтезатор.

Привет, я Паша из Ozon. В рабочее время занимаюсь тестированием поиска, а по вечерам надеваю маску инди-разработчика. И моя самая частая задача — написать скрипт → залить его на сервер → периодически мониторить, что сервер доступен. Эта статья как раз и будет строиться вокруг последнего пункта.

Вы наверняка в курсе, что существуют Grafana, Prometheus, Kibana, LogDNA и другие инструменты для мониторинга, визуализации и анализа данных. C первыми двумя я вплотную познакомился в Ozon, а про Kibana слышал когда-то давно и только в паре со словом «логи». Чтобы графики в Grafana рисовать — придется штат аналитиков нанять (ба-дум-тсс). Для пет-проекта это перебор, нужно что-то сильно проще (с точки зрения стоимости, простоты настройки и удобства). Ниже расскажу, какие готовые инструменты для мониторинга небольших пет-проектов я нашёл в пучинах интернета, а также оставлю комментарии и рекомендации по использованию.

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

Ключевое слово — в конкретный момент времени. Например, база непонятно от чего напряглась на 5 минут, потом всё само рассосалось, и очень хочется знать, почему. Отчёты за сутки, присылаемые dba на основе pg_stats_statements, не всегда проясняют ситуацию. Другие графики и логи могут помочь. Но всё же хочется не гадать на кофейной гуще, а конкретно посмотреть, что такому-то запросу в такое-то время было плохо, или его было много.

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

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