⬆️⬆️⬆️
Далее переходим к содержимому файла. Проверяем структуру. Заголовок и значения. Заголовок файла нам ни зачем не нужен, но так как мы хотим, чтобы разработчик сделал работу ответственно, то формально требуем его наличия:

"errors": [ { "code": "missing\_header", "message": "В файле отсутствует заголовок" } ],

Что-то забыли... Помочь разработчику понять, как исправить проблему. Добавим полезную информацию:

"errors": [ { "code": "missing\_header", "message": "Нет заголовка в файле. Убедитесь, что первая строка в загружаемом файле вот такая: article;subject;date;quantity;source;address" } ],

Теперь проверим количество столбцов в строке:

"errors": [ { "code": "missing\_header", "message": "Неверное количество значений в строке" } ],

И опять. В какой строке? Каких значений? Дополним вывод

"errors": [ { "code": "invalid\_row", "message": "Количество значений в строке не равно 6. Убедитесь, что в строке ровно пять разделителей ';' и на конце строки нет этого символа", "row": 2, "content": [ "24422", "Товар 1", "2024\-06\-30", "1", "any", "", "" ] } ],

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

"errors": [ { "code": "invalid\_row", "message": "Количество значений в строке не равно 6. Убедитесь, что в строке ровно пять разделителей ';' и на конце строки нет этого символа", "row": 2, "content": [ "24422,\"Товар 1\",\"2024\-06\-30\",\"1\",\"any\",\"\"," ] } ]

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

"errors": [ { "code": "empty\_address", "message": "Пустой адрес. Если у торговой точки нет адреса, то передавайте строку «Без адреса»", "row": 2 } ],

В сообщении сразу подсказка и номер строки с ошибкой.

Всего ошибок около 30, я показал вам самые интересные случаи.

Обрабатывайте ошибки правильно, пересылайте своим разработчикам, всем чмоки!

Обрабатываем ошибки правильно Ранее, я писал, что обрабатывать ошибки надо правильно. Наши разработчики пофиксили проблему

Дано
нужно принять CSV-файл и загрузить данные из него в базу.

Как было
Файл загружался, метод загрузки возвращал «Accepted for handle», далее стартовала задача, проходила по всему файлу построчно, выкидывала строки, если в них не 6 столбцов, остальные загружала в базу.

while ($file\->valid()) { $data = $file\->fgetcsv(';'); if (!is\_array($data) || count($data) !== 6) { continue; } }

Делала это молча, отчёта о результате работы не было. Разработчики на другой стороне не понимали, почему данные не загружаются или загружаются частично. Это вызывало конфликты и многонедельные переписки с 20 людьми в копии.

Никуда не годится!

Как стало
Реализовали проверку данных сразу в процессе загрузки и возврат ошибок в виде JSON-объекта. Разделили метод загрузки, на два: один просто проверяет файл, а второй проверяет и загружает в базу. Первый нужен, чтобы пробовать загружать, исправлять и пробовать ещё раз. То есть для разработки. Второй для реальной загрузки. Самый сок этой работы именно в обработке ошибок. О ней подробнее.

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

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

О загрузке CSV мы уже знаем очень много, поэтому есть две типовые проблемы: кодировка и разделители. Они происходят из того, что Microsoft Excel по умолчанию разделяет значения в файле, который имеет тип значения разделённые запятой точкой с запятой. А ещё русская версия экселя сохраняет CSV в кодировке Windows-1251. Да, в 2024 году! Да, последняя версия тоже! Думаю, что это уже скорее для обратной совместимости.

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

Тезисы для самопроверки
1. Находим все ошибки, но не исправляем их
2. Даём разработчику максимум информации для устранения ошибок
3. Все данные должны быть указаны, никаких значений по-умолчанию

Соответственно, делаем проверку на кодировку:

"errors": [ { "code": "invalid\_encoding", "message": "Неправильная кодировка файла" } ],

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

"errors": [ { "code": "invalid\_encoding", "message": "Файл должен быть в кодировке UTF\-8, текущая кодировка: Windows\-1251" } ],

Вот! Другое дело! Теперь понятно, чего мы ждём.

⬇️⬇️⬇️

Ладно, вот вам отличная актуальная рабочая шутейка:

— Слыш, ты в интернете только такой смелый? Да я тебе глаз на жопу натяну в реале!
— Да? Ну давай! Приезжай!
— Приеду!
— Приедешь?!
— Приеду!
— Когда? Буду ждать!
— У тебя во вторник и четверг во второй половине дня слоты есть?

Главный секрет успеха любого проекта

Главный секрет успеха любого проекта, это критическая масса людей, которые настроены решить все проблемы, а не быть формально правыми.

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

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

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

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

Не заполнить контентом

У Ильи Бирмана вышел любопытный пост про кнопку «Стать клиентом». Вкратце он про то, что кнопка «Стать клиентом» ничего не значит. Если написать «Записаться на шиномонтаж», «Купить подписку», то будет понятнее.

В ЦМСках и ЦРМках есть похожая проблема. Если вы видели бэкофис-интерфейсы условного Битрикса, то там, конечно же есть всякие страницы, инфоблоки, виджеты и прочее-прочее-прочее. И всё это надо мучительно заполнять контентом. А хотелось бы добавлять товары, создавать рубрики каталога, писать статьи, создавать подборки и делать кучу разных полезных вещей ещё. А не страдать об формы, которые никакого отношения к задачам сайта не имеют.

Как вы наверное поняли, это продолжение вчерашней мысли про бэкофис.

Стоимость обслуживания. Неочевидное

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

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

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

TLDR: Проектируя новый интерфейс, не забудьте подумать, кто и как будет заполнять его данными.

Ну вот! Наконец-то первые проблески интеллекта. Так глядишь и правда человеком станет. (Это, кстати, почти не шутка. Напишу как-нибудь почему)

Observatory Management System. Коробочная версия

Я понял! Нейросети сейчас делают реверс-инжиниринг человеческой культуры по текстам и изображениям.

Занимаются информационной археологией, так сказать