С первой серьезной трудностью я столкнулся спустя пару минут (образно говоря) как я решил начать учить ЯП. После некоторых «исследований» выбор пал на пайтон (или питон?). Слово за слово, кодом по столу, я приступил к установке змея на комп. Все шло гладко до момента установки змея в ВС код. Он просто не скачивался.
Казалось бы, решение трудности очевидно: ВПН. В итоге несколько часов танцев с бубном (да, я в курсе что есть и другие IDE) не дали НИЧЕГО.
Благо начал я с курса на степике и там есть встроенный змей, отложив затею на неопределенный срок, я наконец научился писать Hello world.
И вот, спустя буквально 2-3 дня, я на работе решил попробовать накатить змея в ВС код ииии …. Он встал
Вечером я пришел домой и попробовал еще раз поставить его себе на комп и он тоже встал
Я так и не понял что все это было, но во всем этом есть определенно некий философский смысл, надеюсь осознать его в будущем
Всем привет, я мужчина в самом закате сил и здесь начинается мой путь в айти. Надеюсь нас всех ждет увлекательное приключение, ребята!
Я человек, который абсолютно не умеет программировать, но с появлением Cursor стало интересно попробовать что-нибудь навайбкодить.
Моим первым проектом стал довольно простой сайт, который помогает найти торговый центр, который лучше всего подходит именно вам. Вы вводите названия магазинов, которые хотите посетить, а система показывает ТЦ с наибольшим количеством совпадений.
Пока доступны Москва (15 ТЦ) и Санкт-Петербург (3 ТЦ). Со временем буду добавлять новые города и торговые центры.
Я собрал базу данных, арендовал VPS, задеплоил проект и начал тестирование. Сначала всё шло хорошо, но в какой-то момент я начал замечать, что база данных просто исчезает. Я делаю миграцию — всё работает, проходит какое-то время и снова ручки начинают пятисотить.
Долго не мог понять, в чём проблема. Тем более что раньше у меня был Telegram-бот с ровно таким же функционалом, на том же хостинге, и никаких проблем не возникало.
Покопавшись в логах, я обнаружил вот такое сообщение:
LOG: statement: DROP DATABASE (название бд);
Оказалось, что у меня были открыты внешние порты для подключения, и кто-то просто подключился к базе данных. Периодически они дропали мою БД и оставляли сообщение с вымогательством денег за типо восстановление данных. А все потому, что Cursor поставил пароль от моей БД - postgres и оставил внешние порты открытыми)))
INSERT INTO readme (text_field) VALUES
('After paying send mail to us: (тут был имейл)
and we will provide a link for you to download your data.
Your DBCODE is: (тут был набор цифр);
Мораль сей басни такова. ИИ — это не панацея и уж точно не полноценная замена разработчику. Я писал промпты про усиление безопасности, но это всё равно не спасло. Базовые вещи вроде сетевой изоляции и нормальных паролей всё ещё лежат на человеке.
Паспортные данные - это персональная информация. Она нужна, чтобы идентифицировать человеке.
Но как их хранить, что с ними делать, кому давать доступ?
Это очень часто становится развилкой в организации хранения данных.
Об этом ниже.
А пока подписывайся на мой каналНа связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0. Его я веду с нуля подписчиков. Разбор частых ошибок и задачи по накопительной сумме уже в канале. Присоединяйся!
Паспорт - это не просто набор цифр. Это ключ к человеку: по нему можно понять, кто он, где живёт, какие услуги получал и что с ним происходило в системе.
Именно поэтому вокруг паспортных данных всегда много вопросов:
Можно ли хранить паспорт в базе данных?
Почему иногда по паспорту делают JOIN?
Почему в одних системах паспорт виден полностью, а в других — нет?
Паспорт это не просто набор цифр. Это ключ к человеку: по нему можно понять, кто он, где живёт, какие услуги получал и что с ним происходило в системе.
Именно поэтому вокруг паспортных данных всегда много вопросов:
Можно ли хранить паспорт в базе данных?
Почему иногда по паспорту делают JOIN?
Почему в одних системах паспорт виден полностью, а в других — нет?
В идеальном мире паспортные данные:
Хранятся в базе данных Да, это важно сразу проговорить - 👉 паспорт всё равно лежит в БД, иначе с ним просто невозможно работать.
Но не в открытом виде Это значит:
не просто текстом 1234 567890
не так, чтобы любой сотрудник мог его посмотреть запросом
Доступны только тем, кому действительно нужно Например:
пользователю в личном кабинете
сотруднику KYC / поддержки
системе проверки документов
В реальных системах ID клиента — не всегда надёжен.
Пример из жизни:
человек зарегистрировался в системе
потом пришёл снова, но:
с другим номером телефона
с другой почтой
через другой канал (офис / сайт / партнёр)
В итоге в базе:
два разных client_id
но один и тот же паспорт
👉 И это прямой сигнал: это один и тот же человек
Поэтому в некоторых случаях:
делают объединение (JOIN) по паспорту
чтобы понять, что записи относятся к одному человеку
Это особенно важно:
в банках
в финтехе
в государственных системах
в CDI (системах, которые собирают данные о клиентах из разных источников)
Тогда почему паспорт нельзя просто зашифровать и забыть?
Потому что с паспортом делают проверки и сравнения.
Например:
«Этот паспорт уже есть в системе?»
«Этот человек уже проходил идентификацию?»
«Это новый клиент или старый?»
Если просто заменить паспорт на набор звёздочек: **** ****** - с ним не возможно напрямую работать
Поэтому часто используют подход:
паспорт хранится в защищённом виде
но система всё равно может:
сравнивать
находить совпадения
связывать записи
Когда паспорт виден в явном виде
Да, такие случаи есть. И они нормальны, если соблюдены условия.
1️⃣ Личные кабинеты пользователей
Пользователь:
сам вводит паспорт
сам его видит
сам может исправить ошибку
Это допустимо, потому что:
это его данные
он дал согласие
доступ есть только у него
2️⃣ Банковские и финтех-системы
Сотрудники:
видят паспорт полностью
но не напрямую из базы
а через интерфейс системы
Важно:
каждый просмотр логируется (записывается)
есть роли доступа
нельзя просто «посмотреть ради интереса»
3️⃣ CDI и KYC-системы
Это системы, которые:
собирают данные о клиенте из разных источников
проверяют документы
подтверждают личность
Здесь паспорт:
часто нужен целиком
иначе невозможно выполнить проверку
Почему аналитики обычно не видят паспорт
Потому что:
аналитике не нужен сам паспорт
аналитике нужен идентификатор человека
Поэтому в аналитических базах:
паспорт заменяют на client_id
или на специальный технический ключ
👉 Это снижает риск утечек и ошибок.
В некоторых слоях хранения данных, паспорт хранится в виде хэша. Но надо помнить, что хэш ≠ шифрование
Хэширование - это дорога в одну сторону. Есть еще метод шифрования и при его использование можно восстановить данные, если есть ключ.
Хэш не подходит, если паспорт нужно:
показать пользователю
передать в другую систему
проверить вручную
Хэш не подходит, если паспорт нужно:
показать пользователю
передать в другую систему
проверить вручную
Но тогда где хранится настоящий паспорт?
В реальных системах обычно два уровня хранения:
1️⃣ Паспорт в зашифрованном виде
хранится в БД
может быть расшифрован
доступ есть только:
у сервиса
у строго ограниченного круга ролей
Это нужно, когда:
пользователь открывает личный кабинет
сотрудник банка смотрит данные
идёт проверка документа
2️⃣ Хэш паспорта - для связей и аналитики
используется для:
поиска дублей
объединения клиентов
JOIN между системами
никогда не раскрывается наружу
👉 Аналитик работает с хэшом 👉 Операционная система - с зашифрованным паспортом
Почему нельзя хранить только хэш?
Потому что тогда:
нельзя показать паспорт пользователю
нельзя исправить ошибку
нельзя передать данные в гос-сервис
нельзя провести ручную проверку
Хэш отвечает только на вопрос:
«Совпадает или нет?»
Но не отвечает на вопрос:
«А что именно там написано?»
Можно ли «достать паспорт из хэша»?
Нет. И если кто-то говорит, что «у нас хэшируется, но при необходимости мы восстанавливаем» - 👉 значит это не хэш, а шифрование.
В моем канале На связи: SQL все простыми словами и с конкретными примерами. Подписывайся!
Скоро Новый год, и мне хотелось бы поздравить вас всех с этим прекрасным праздником! 🎄 Год был нелёгкий, но каким бы он ни был — он заканчивается. А значит, мы с вами будем верить в лучшее.
В качестве небольшого подарка хочу поделиться с вами приложением, которое пилю уже довольно давно. Ну как «сам»… программист из меня — как из пластилина пуля, так что пилю вместе с Cursor: я тут скорее менеджер проекта и тестировщик 😄 (Сочувствую всем тестировщикам — я теперь реально понимаю, через что вы проходите.)
Началось всё с того, что в продажу вышла мышь Logitech MX Master 4. Мне очень понравилась идея боковой кнопки, которая вызывает кастомное меню. Удобно же, когда всё нужное под рукой. Но покупать такую мышку по цене почки за 10к (на момент выхода) мне было дороговато. И я решил создать…
Нет, Бендер, другое.
...свою менюшку😎
Для начала я набросал небольшое ТЗ. В старте использовал DeepSeek — код он пишет неплохо, но сильно ограничен по длине чата. Приходилось постоянно переносить ТЗ и описания в новые диалоги, что было жутко неудобно. Потом попробовал Qwen: поначалу всё ок, но в какой-то момент он не мог найти простую ошибку и повторял её снова и снова. С этим наброском я пришёл к Grok — сначала писал нормально, а потом начал ломать код и выпиливать функции. Горело у меня знатно)) В итоге все мои изыскания привели меня к Cursor. Не буду его нахваливать — у него тоже хватает проблем, но основные задачи он помог решить и довести это безобразие до ума)
Основные настроки
Теперь, собственно, о самой программе. Это кастомная менюшка, которая собирает всё самое нужное и кладёт вам буквально «в одну руку»: программы, горячие клавиши, команды, ссылки, папки, файлы — всё для быстрого доступа.
Когда программа была почти готова, вылезла проблема: в некоторых играх и приложениях меню могло вызываться из-за совпадения клавиш. А выпрыгивающее поверх игры меню — то ещё удовольствие 😅 Поэтому я добавил возможность указывать приложения-исключения.
У меня, к сожалению, нет Helldivers — если кто-то сможет протестировать вызовы подкрепления и прочие штуки, буду рад 👀
В программах вроде Blender, Photoshop, AutoCAD меню может быть полезно как кастомная панель горячих клавиш. Если вы программист и вам нужны свои команды — в окне «Команды» можно прописать их, сохранить, подписать и назначить на любой элемент.
В процессе разработки я понял, что одного меню может быть мало: в одной программе нужно одно, в другой — другое. Так появилась идея сценариев, между которыми можно переключаться на лету.
Каждый сценарий можно подписать и настроить под конкретные задачи. Между сценариями можно быстро переключаться с помощью Ctrl+1, Ctrl+2, Ctrl+3 (в зависимости от количества сценариев). Для каждой настройки есть описание — что это и зачем. Можно отключать надоедливые подсказки в настройках)) Меню полностью настраивается под вкус и цвет. Так как я немного пишу музыку, добавил звуки.
Винда при запуске может ругаться на программу, так как программа отслеживает нажатие клавишь. И это логично, иначе как вызывать программу. Так что просьба не паниковать) Прогамма ни каких данных не собирает, никуда ничего не передаёт.
Так как у каждого монитора свой DPI пришлось сделать для этого отдельный ползунок в настройках. Есть светлая тема и ̶п̶о̶ж̶а̶л̶е̶й̶т̶е̶ ̶м̶о̶и̶ ̶г̶л̶а̶з̶а̶ тёмная тема🌚 Все элементы я рисовал сам. В будущем, возможно, буду добавлять новые элементы и звуки. Если вы умеете работать в Adobe Illustrator — могу в следующем обновлении добавить открытую папку для ваших эскизов (формат SVG). Да, я знаю что вы сейчас напишите, что таких програм много. Знаю. Но это моя программа, я делал её сам и делюсь с вами. Программа бесплатная. Есть ссылка на донат, если кто захоет отблагодарить и скинуть на чашку кофе)). А так же почта для обратной связи, если есть идеи и предложения.
Если будут какие-то ошибки, ошибки, можете написать в комментарии или на почту. И ещё раз, я не программист)) Делал как мог, стестировал как мог, так что сильно не пинайте😄 Программа ещё в процесе разработки, так что буду ещё допиливать потихоньку. На счёт ссылки на яндекс, я так понял, что там нельяз обновлять файл, а в гугл диске можно.
В общем, всех с наступающим Новым годом! 🎄 Пусть в новом году вам сопутствует удача, а беды обходят стороной. И пусть случится всё хорошее! 🍾🥂🎁🎆
Я - инженер-программист. В качестве подработки решил выполнять студенческие работы (курсовые, дипломные, презентации, рефераты, лабораторные-практические...).
В качестве инструментов у меня есть: Gemini Pro 3, ChatGPT 5.2. Ну и мой собственный хрен.
Я беру заказ у клиента, сую его текст в Gemini Deep Research, получаю текст, а для форматирования по нормам методички пересовываю полученный результат в ChatGPT 5.2.
Однако, сколько же я намуздался с данными заказами: например, нейросеть не может мне составить даже нормальный чертёж детской площадки для граф. дизайнера. Не может отформатировать документ строго по методичке, чтобы я потом туда не лез. Не может разместить красиво формулы в документе без использования Латеха (хотя я сто раз его просил об этом). Не может эргономично разместить текст на презентации и валит всё в единую кучу...
И так далее и тому подобное.
Но я ИМЕЮ ПРАВО НА ИНТЕЛЛЕКТ! Имею право на работу ИИ! Как быть?
В далекие времена после университета, я работала специалистом по качеству данных. Данные были клиентские: ФИО, адреса, телефоны, email. И надо было, чтобы данные были качественные. Для этого в компании использовалось ПО по стандартизации данных, надо было следить, чтобы ПО работало корректно, если замечаешь, что при обработке допущена ошибка, то выставляешь ТЗ на доработку, проверяешь, чтобы новый релиз работал как минимум не хуже чем предыдущий ну и т.д.
Так вот, хоть я и работала с клиентскими данными, но я не работала с БД. Хотя все данные лежали в БД. У меня там были выгрузки в Excel, их формировал кто-то другой. И я в Excel обрабатывала эти данных - надо было, чтобы процент плохих или неразобранных данных был меньше 3.
Перешла я в другую компанию - тоже на проект с качеством клиентских данных. И тут мне предлагают: "а давай мы тебе доступ к БД дадим, ты там будешь селектики делать, статистику считать". И тут у меня загорелись глаза. "Да, конечно, я хочу, но я ничего не знаю, не знаю как пользоваться, хотя в универе у меня был курс, связанный с базами данных. Но я ничего не помню. Так у меня началось осознанное знакомство с SQL.
А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0. Его я веду с нуля подписчиков. Разбор частых ошибок и задачи по накопительной сумме уже в канале. Присоединяйся!
Глаза горели, а руки делали в тот момент. Я начала знакомится, что такое БД, DWH, а потом стали появляться Data Lake.
Все эти слова (База данных, DWH, Data Lake) - это про совокупность данных. Везде здесь могут быть связи. Везде может использоваться одна и та же технология (PostgreSQL, S3, ClickHouse и т.д.)
Почему же, если это все про совокупность данных, стали появляться разные слова для этого?
Посмотрим на кусок мяса. Мы его можем варить, жарить, мариновать. Но это все равно остается мясом.
Получается, что мясо - это сырье. А стейк, бульон, котлета - это не мясо, а БЛЮДА.
А теперь попробуем сделать проекцию на данные.
Данные = мясо. БД/DWH/Data Lake - не мясо, а способ организации этого мяса
База данных - это технология хранения DWH и Data Lake - это концепции организации данных
У DWH есть своя БД У Data Lake - своя БД Но не каждая БД - это DWH И не каждая БД - это Data Lake
База данных - это как холодильник. Он хранит еду, ему все равно, будет ли это суп или торт. БД - это "контейнер + правила": - как хранить данные - как читать - как писать - как обеспечивать целостность
БД Не говорит - зачем хранить эти данные, как они буду использоваться.
Что же такое DWH?
Это ближе уже к готовому блюду. Его не переделывают, его едят и анализируют (это в идеале, конечно)
В DWH данные: - приведены к единому виду - нормализованы (чаше всего встречается 3-я форма нормализации - этого достаточно) - уже очищены - изменения задним числом недопустимы Все это не про связи, это про правила жизни данных.
Тогда что включает в себя Data lake?
Озеро данных - это "склад без разборки" Многие компании не знают, что пригодится завтра, поэтому максимально пытаются сохранить большее количество данных. Данных действительно бывает много, не все они участвуют в бизнес-процессах и монетизируются. Но терять их никто не хочет.
Поэтому компании организовывают Озеро данных: - данные хранятся как есть - без очистки - без структуры - без гарантий - связи между данными могут быть, а могут и нет
Но в некоторых данных встречала, что какие-либо отчеты формируются на данных из "озера".
Поэтому появляются термины, чтобы сказать: - это БД, которая используется как DWH - это БД, которая используется как Data Lake
В итоге, получается, что БД - это "где хранятся данные". DWH и Data Lake - это как и в каком виде они там хранятся.
В моем канале На связи: SQL все простыми словами и с конкретными примерами. Подписывайся!
Расскажу, как я написала тектовый редактор для переводчиков. И главное - зачем, когда есть ворд и гугл докс и куча всего еще.
Картинка для привлечения внимания :)
Итак, у нас есть огромная куча текстовых редакторов со всевозможными прибамбасами и свистопeрдeлками на все случаи жизни. Казалось бы, это удобно. А вот не всегда! Когда нужно сосредоточиться на написании книги (или ее переводе), то лишние функции только мешают, бесят и забивают голову. Хочется, чтобы все было максимально просто и ничего не отвлекало от творческой работы.
Именно поэтому пишу книги я в минималистичном редакторе Q10 с его имитацией старого компьютера и звуком пишущей машинки. И поэтому же написала свой TangoText.
Чем не подошел для переводческих целей тот же Q10? А тем, что мне нужны были две колонки, ширину которых легко менять, если вдруг перевод оказался короче или длиннее оригинала (люблю, когда они ровненько и рядом). Раньше я делала в опен офисе или гугл доксах табличку с двумя колонками для этой цели. Но с таблицами куча мороки, и это раздражает. К тому же, таблица втиснута в шаблон страницы, так что колонки всегда получаются узкие. Неудобно.
В общем, разозлившись на очередную поехавшую таблицу, я поняла, что идея созрела: мне нужен эдакие Q10, но для переводчиков: с двумя колонками. И чтобы сохранял работу в простой текстовый файл, где оригинал и перевод не перемешаны, а идут друг за другом. А при открытии снова правильно раскидывал их по колонкам.
Два дня работы - и вот он, TangoText - переводческий редактор моей мечты. Причем, в двух версиях: браузерной, которую даже скачивать не нужно, и портативной, которая работает без установки.
Знаю, штука очень специфичная, но вдруг пригодится еще кому-то, кроме меня. TangoText - минималистичный текстовый редактор для переводчиков!
На прошлой неделе я не внес значительных изменений. Однако я всё же успел реализовать несколько важных задач.
Типы транспорта
Ранее я уже говорил о необходимости добавить типы транспорта для более точного расчёта закрытия объекта. Это также пригодится в будущих анализах.
К сожалению, в тулбаре теперь отображается на один объект больше. Но, к счастью, тулбар анимирован, поэтому место для новых элементов ещё есть.
Кнопка "Транспорт" в тулбаре
Нажимая на "Транспорт" открывается диалоговое окно, которое показывает полный список созданных типов транспорта и их вместимость.
Пользователь может:
Создать новый тип
Редактировать
Удалить
Окна создания и редактирования между собой похожи
Создание и редактирования типа транспорта
При создании записи с данными в SQLite каждый пользователь, работающий с исходным файлом, видит изменения в своём интерфейсе.
Пользователь также может привязать типы транспорта к региону с уникальной ценой за трак. Важно понимать, что цена за трак не всегда отражает реальную стоимость перевозки. Существует KPI по проценту утилизации трака, который показывает, насколько эффективно используется транспорт.
В транспортной и складской логистике успешная транспортировка считается, когда процент утилизации трак стремится к 100%. Однако это редкое явление, так как часто перевозят воздух в коробках, а упаковка, например, стрейч, также влияет на утилизацию. Если же транспортировка осуществляется паллетами, то процент утилизации обычно ниже 85%.
С учётом этих факторов мы рассчитываем реальную стоимость перевозки. Например, трак объёмом 70 кубических метров стоит 300 тысяч рублей, а его утилизация составляет 90%. В этом случае перевозка одного кубического метра в среднем будет стоить 4,7 тысячи рублей. Различные цены на разные автомобили позволяют нам получить разные средние цены перевозки 1 кубического метра.
Как это работает. Пользователь выбирает склад, нажимает «Рисовать регион» и обводит на карте зону доставки. Затем он указывает типы автомобилей, которые могут использоваться для перевозки, и среднюю стоимость доставки одного кубического метра.
Эти данные попадают в расчёты «Анализ закрытия» и «Анализ открытия» (начал его разрабатывать).
Анализ расчета стоимости перевозки товара
Мы понимаем, что машина может следовать по рейсу, поэтому в отчёте программа автоматически рассчитывает рейсы. Но возникает вопрос: что делать, если машина утилизирована не полностью? Например, если товары для магазинов А и В попали в один маршрут, но их хватило только на 70% утилизации?
На этот случай тоже есть решение. Логика учитывает ближайшие объекты и дополняет рейс товарами для них. Если объём отгрузки небольшой, программа определяет оптимальный тип транспорта. В итоге мы получаем более-менее верное решение.
Данную логику сидел, проверял вручную в EXCEL и с помощью обычной карты. Попадание в 97% точности. Где-то не учла верность перераспределения и тем самым занизила на 3% стоимость перевозок. Но 3% (а вообще до 5%) в рамках погрешности, поэтому можно сказать что "Успех".
Доработка с транспортом - не сама тяжелая, она отняла у меня буквально 3 вечера.
Декомпозиция старого кода
Когда начинал писать программу, особо еще не знал правильность. Был такой юношеский максимализм. Писал огромные модули в одном файле, вследствие чего те же «Дашборды» разрослись на 5 файлов по 4к строк кода в каждом.
Сидел на прошлой неделе и думал: «Надо добавить пару новых графиков, а как делать-то? Я уже не помню этот код, куча вызовов, да и он больше на монолит похож». Пытался добавить спарку «График + гистограмма» — получил ошибку методов, начал ковырять глубже — так вообще пришлось откат из репозитория делать.
Новая структура выглядит более удобной, и можно вносить изменения с минимальными правками:
Новая структура
Для сравнения вот старая модель:
Старая структура
Это был настоящий кошмар. Стили, логика и подключения были объединены в один файл. Оркестратор "Менеджер" тоже содержал много лишнего..
Пример декомпозиции
UI — это то, что мы видим на экране. При любом взаимодействии с интерфейсом система вызывает посредника, который отправляет сигнал в логику. Логика получает сигнал и решает, нужно ли ей работать с хранилищем. Если да, она собирает данные и отправляет их обратно посреднику. Посредник проверяет, нет ли ошибок, и передает данные в UI, который их отображает.
Такая структура позволяет легко и быстро вносить изменения. Новые стили, графики, страницы и меню можно добавить за один вечер, не нарушая логику работы всей системы.
В целом вообще сейчас стараюсь переписывать часть старого кода, с опытом многое понял про правильность и оптимизацию. Старые методы которые я писал с кучей подключений на 200-300 строк, получается сократить до 100-150. Первое - много принтов для логирования (часть убрал), второе - лишние проверки переменных. Добавлял на случай "Что бы на верняка".
Анализ открытия
Вечером пятницы сидел и понимал что пора развивать новый отчет. В начале набросал UI составляющую сотканную из заглушек.
Новый отчет
На скриншоте выше - это только концепт-макет.
Структура отчета
Накидал быстро файловую структуру которая будет для данного анализа.
По структуре видно что планируются такие логики как "Каннибализации". Это когда объект может забрать часть продажи у другого объекта
ROI с учетом всяких вводных типа "ФОТ, Аренда, опексы, стоимость транспортировки товара на магазин". Так как программа для компаний с большой историей, то и считать она будет исторические данные для точки. Например ближайшие магазины и какие продажи, какие тут были доставки и тп. Исходя из этого, строится предполагаемая модель продаж, выручка, считаются долгосрочные вложение и получаем сколько надо месяцев на окупаемость магазина.
Продуктовая матрица - как раз в ROI частично описал. Смотрим ближайшие магазины, смотрим что уходило в эту зону на доставку, считаем ABC, смотрит запас товара в регионе - формируем матрицу.
Логистическая карта - обратная функция от закрытия. Как измениться зона курьерских доставок и времени если именно тут открыть магазин.
И т.д.
Сейчас даже не знаю сколько потребуется времени на реализацию всей задумки. Пока что закладываю месяц на стартовый отчет и еще недели 2 на правки. Но впереди праздники, возможно стоит приступить к этому после Нового Года, а до этого момента исправить старые недочеты.
Как обычно, всем спасибо за прочтение. Если есть какие-то идеи, предложения по улучшению UI или логики программы - пишите, буду рад принять что-то новое!😊
Следующие новости - после праздников. Всех с Наступающим Новым Годом!☃️
