Комментарии 26
Вот теперь думаю, что с ней делать. Выбросить – жалко. Но рынок очень узкий и достаточно закрытый.
Идти в мир 1С, если нравится работа с такого рода задачами, и там, вы можете стать очень хорошим и востребованным профи.
Так как типичные кодеры 1С в основном знают только 1С, и кричат что им этого достаточно и они гуру.
Настоящие профи — знают более чем 1 язык программирования, а реальные профи — минимум 3-4. Да, может не на 100%, но это и не надо.
У меня в 1С сейчас возникают схожие задачи, например, если контора, там есть торговые и курьеры, и служба доставки, и прочие прелести.
Так вот, со времени внедрения мы задали клиенту всего один вопрос:
«Как курьер решает — куда ехать в первую очередь?».
Это все переросло в громадный проект, где:
1. Гео позиции взятых заказов, с анализом того, заказ был взят около клиента, или хз где.
2. Решение задач коммивояжера
3. GPS трек в машинах
4. Вывод карт с реальным и оптимальным маршрутом, рассчет себестоимости доставки вплоть до конкретного клиента (а это еще та задачка)
5. Вывод и наложение маршрутов, с расчетом расстояния и простоев
6. Служебные поездки и оптимизация ГСМ
И куча куча всего другого.
Тут пришлось кодить карты, причем иногда это Яндекс, иногда опенстрит, так как нужны графики пирогов по особому алгоритму, которые ни гугл, ни яндекс не дает делать нормально.
Тут же мобильные прилоежения (в том числе на 1С), и службы сбора текущих координат (это уже нативное)
Тут и вывод карт, сохранение скринов карт с анализом дальнейшим
Тут же интеграция с гуглом, яндексом, свои приблуды, с GPS трекерами и т.д.
И увы, большенству 1Сников такие задачи не поднять, в силу ограниченности знаний только 1С, и чаще всего не умением вкурить в английские мануалы, та и вообще в английский. А чаще всего — они даже не знают что так вообще можно.
А вот вы, с вашим опытом и знанием, и уже даже пониманием предметной области, можете очень не хило зарабатывать тут, и заниматься чуть ли не сразу интересными проектами, начиная с того, что помогать 1Сникам в написании вот таких приблуд как я описал.
Так как и 1Сникам не легко веб программисту объяснить многие тонкости учета бизнеса, и почему это надо именно так, большенство из них (веб программистов) думает, что это 1С такая тупая и не может по другому, а по факту — это требование бизнеса, и тут не выкрутиться.
Плюс, 1С умеет в oData и rest full api, причем для работы с ними — не надо лицензии (если память не изменяет), так что если вы свою приблуду сделаете как сверхлегкий клиент, который будет только описывать интерфейс, то и тут тоже вам рынок будет.
Короче — подумайте :)
А в дельфе
Надо бить клавиатурой по попе разработчиков, которые Delphi называют дельфёй. Чисто из уважения к этому некогда блистательному инструменту.
Когда читал статью, был в шоке.
Сам в основном занимаюсь разработкой ERP, CRM.
Очень рад за клиента, что он отказался и надеюсь не заплатил.
Автор, когда клиент к тебе обращается — он ждет что-то хорошее.
А ты с момента выбора технологии и реализации начал клиенту свинью подкладывать.
ERP такая штука, которая всегда подвержена доработкам и изменениям, притом доработкам, порой очень нелогичным (которые не укладываются в логику).
Такие системы должны быть:
1. Очень гибкие — чтоб можно было менять и дорабатывать все что угодно, особо при этом не ломая другие модули
2. Написаны на популярных и простых технологиях — если вдруг за такой код, как вы делали, вас в лес увезут, чтоб другой программист мог дальше работать. Ваш код легче выкинуть, чем копаться в ваших изобретениях.
При этом вы там формы переделали, я так понимаю даже программист на этом будет долго мучаться.
Средством разработки был выбран Rad Studio. Студия по некоторым причинам не очень популярна, но в данном случае мне, во-первых, хотелось получить единый код на всех устройствах, так как я один и не могу себе позволить несколько раз прописать одну и ту же структуру данных в нескольких средах разработки, а потом при любом изменении править в 10 местах. А во-вторых, я на всех платформах получаю компилированное приложение, которое теоретически всегда должно работать быстро. Но прежде всего меня волновала скорость на рабочем месте оператора.
Ну конечно, если вы слона проглотить решили в одиночку.
Только сделать это на вебе было бы очень даже не плохо и работало бы очень быстро.
Вы в курсе что последние годы это делают на вебе, когда нет возможности и целесообразности писать отдельные приложения.
И код был бы единый, с константами, без хаков и главное Поддерживаемый!!! Это самое главное что нужно клиенту!
Клиенту всегда нужно, чтоб бизнесс работал, а не ваши изобретения. Он всегда хочет знать, что если вы пропадете по любой причине, его бизнес не сдох из-за вашего выбора технологий. И что пару лямов он потратил не привязавшись только к вам как единственному, кто может апдейтить систему.
Вы свинством занимаете, еще и продать теперь хотите кому-то.
Очень гибкие — чтоб можно было менять и дорабатывать все что угодно, особо при этом не ломая другие модули
У меня именно так и есть.
Очень гибкие — чтоб можно было менять и дорабатывать все что угодно, особо при этом не ломая другие модули
А вот тут позвольте не согласиться. Можно нанять 1 человека за $1500, и 6-8 человек на $800, и они что-то будут делать годами. И любая серьёзная доработка — это тележенье заказчика минимум пол года (это сугубо из практики). А можно одного нормального программиста тысяч за 5, пару джуниуров в помощники тысячи по 1.5, и пару скриптовиков за те-же $600-800. Лид за короткое время допилит основную часть системы, и переключится на другую задачу, джуниоры будут допиливать расширения api, сборку проекта и пр. Ну а скриптовики будут как раз и удовлетворять все потребности заказчика. Чем не вариант? Он кстати дешевле, стабильнее и как-бы эффективнее.
Только сделать это на вебе было бы очень даже не плохо и работало бы очень быстро.
На вебе это не может ни когда работать быстро. Точнее может только в теории. Я ни разу в жизни не видел ни одного интернет магазина с полноценным юзабилити, который не тормозит. Чего говорить о сложных вещах? Даже в каком-нибудь сбере большую часть времени оператор не делает что-то полезное, а смотрит на кручение каких-нибудь ожидалок. А там работают, наверное, лучшие программисты из данной сферы. Что уж про остальных говорить?
Он всегда хочет знать, что если вы пропадете по любой причине, его бизнес не сдох из-за вашего выбора технологий.
Найти специалиста в любой области — не проблема. Только специалист стоит денег.
Замените браузер на нативное приложение на Delphi или C++
И станет возможно много делать на клиенте, не ставя в него i5, и одновременно не заставляя по 2-3 секунды оператора ждать открытия заказа или смены фильтрации. Всё начинает работать моментально (без лишних обращений на сервер как минимум). Что повышает комфорт и производительность работника.
На вебе это сделать скорее всего не возможно, по крайней мере я таких примеров не знаю.
Для успешности надо владеть разными инструментами. Лично я пол года назад вообще не знал что такое RTTI, слабые ссылки, и прочая «муть» из современного Delphi. Мои основные языки разработки были c++/Java/C#, я разрабатывал VR решения, занимался OpenCV/SLAM позиционированием, реверс инжинирингом, из особых свежих моих достижений был самый эффективный лендинг для 4k в VR среди конкурентов в мире к примеру.
То есть как-бы дорогущая Rad Studio — это вообще не мой профиль. Естественно я сто раз подумал, перед тем как выбрать Delphi. Отдать денег ведь надо было много за просто лицензию разработчика. Но нету ей альтернативы в этой области. Просто нет. Есть потуги мелко-мягких: xamarin, есть Qt. В первом случае слишком много проектов за последние 10 лет MS выкупала и уничтожала, что бы как-то серьёзно ставить на xamarin. Ну а Qt — интерфейс кросс-платформенный, но имеет слишком много ограничений. Ну и всё. Нет больше кросс-платформенных решений кроме html
А специалисты гораздо охотнее берутся за работу, опыт которой будет ценен для них в дальнейшем
Нет. Кодеры берутся за работу, на которую они способны устроиться. А разработчики пишут, что разработали такую-то сисетму. И во-втором случае ЯП — это лишь уточнение.
Лидом конечно сложно устроиться, а сеньёром — без проблем.
С точки зрения Заказчика или менеджера, чтобы получить максимум прибыли, важно с помощью автоматизации: во-первых, выжать максимум из имеющихся ресурсов — это достигается оптимизацией производственной цепочки и балансировкой ресурсов; во-вторых, чтобы полученная «автоматизация» жила и могла развиваться. И когда Заказчик адекватен и работает вдолгую, то второму вопросу он уделяет внимания даже больше, чем первому, потому что это окупаемость инвестиций. Если они не окупятся, то эта игрушка никому не нужна.
С позиции менеджера скажу вам так, собственные разработки программистов одиночек на Delphi сейчас никому не нужны — это дорого, рискованно и неэффективно. Если мне нужна будет ERP, я охотнее вложу в 1С, даже если это будет дороже. Но покупая такое решение, я буду покупать не вашу способность писать код по моим/вашим ТЗ, а чью то экспертизу, которая уже обкатана и показала эффективность. Заказчик в большинстве случаев не знает как автоматизация может ему помочь (реально) и его бухгалтера/менеджеры/закупщики/повара/и пр. тоже не знают и они никогда не дадут вам нормального ТЗ. Но и инвестировать в технаря-программиста, который на вашем проекте ничем не рискует, а делает себе коробку, чтобы потом продавать и зарабатывать — глупо, потому что риски.
А по поводу того, что делать с вашей разработкой — ну тут вариантов то не много. Если коротко, то читайте про развитие стартапов, в вашем случае, я другого пути не вижу. Если это рынку не надо — оно и не взлетит.
но в данном случае мне, во-первых, хотелось получить единый код на всех устройствах
Какой именно код в итоге остался общим? Вы ведь сделали скриптовый язык на сервере.
спасибо, что исходники компонент дельфи доступны и там можно легко поправить заголовок http не заморачиваясь с raw socket
Опишите пожалуйста подробнее, зачем вам было нужно менять исходники стандартных компонентов, в чем была проблема?
их программа раз в минуту опрашивает сервер, и, если есть новый заказ, то печатает pdf
То есть в ответе от сервера возвращался только pdf? Никаких JSON или XML? Решение с парсингом PDF выглядит странно.
Если координат нет, геокодируем
А почему сразу нельзя было геокодировать, без ФИАС? Ответы складывать в кэш, кэш постепенно наполнится, и будет то же самое, только без дополнительной интеграции.
Если данные в нём есть, обратимся сразу, если нет, то придётся подождать, пока сервер отдаст их.
То есть обращения к серверу в процессе работы все же есть? А как данные выгружаются из кэша? Допустим оператор начнет пролистывать все заказы за последние полгода с целью найти какой-то конкретный.
всем подписчикам придёт об этом уведомление с новыми данными
Как решается вопрос когда у одного из клиентов в этот момент сеть недоступна? Он потеряет обновление?
Несколько замечаний в целом.
А во-вторых, я на всех платформах получаю компилированное приложение, которое теоретически всегда должно работать быстро.
Скорость работы таких систем зависит от скорости ввода-вывода, а не от компилированности.
Вдруг такое сочетание «улица-дом» уже встречалось, тогда берём координаты оттуда.
Выглядит как неправильно спроектированная архитектура. Должна быть одна таблица для адресов и координат, чтобы не искать в 10 местах.
но принять данные не возможно ни в какой форме
Сам не пробовал, но то что сходу нашлось: чтение из window, чтение поля формы
CurOrderState := GetNewValueF('Orders','OrderState');
LastOrderState := GetOldValueF('Orders','OrderState');
В современных подходах у вас есть объект класса Order
и данные запроса, и вся эта куча кода превращается в order.state
и request.state
.
Но так как это можно в любой момент переписать, и код совсем не сложный и не большой, я решил пока оставить так.
Ну так сначала сделайте, а потом продавайте. Раз еще не сделали, значит есть сложности.
Брали бизнес-логику прямо «голыми руками» и сразу в код? Неужели действительно EPR так можно «состряпать»? Вроде бы как понятие «Enterprise» в аббревиатуре ERP к этому обязывает.
Может быть, получится нарисовать описание «архитектуры предприятия» Вашего ERP, как это предлагается в третьем разделе https://habrahabr.ru/post/345424
Или вообще любая ERP никакого отношения к ЕА и BPM и прочей алхимии не имеет?
Как я писал собственную ERP систему, ver. 2.0