Некоторое время назад ко мне обратился знакомый, хозяин одного из филиалов крупной сети по доставке суши и пицц. Их нынешняя ERP его вообще не устраивала, так как не было контроля за кухней и доставщиками, а так как кухонь по городу у него 5, то это была серьёзная проблема. Он предложил мне написать под него новую систему. Единственное условие – так как он во франшизе, и особо с головниками портить отношения не хотел, необходимо интегрировать с существующей системой максимально скрытно.
Первый вопрос, который у меня возник – это средство разработки. Можно было взять что-то новомодное типа NodeJS для сервера, и отдавать web-интерфейс клиентам – самый простой, но самый тормозной вариант (аналогичные решения требуют i3). Можно прописывать отдельно серверную часть, отдельно каждое приложение (windows/android/ios). Или NodeJS сервер, и C# (xamarin если точнее) под все клиенты единый код. Или взять последнюю Rad studio и написать на единой кодовой базе всё. Так как я понимал, что разный код, описывающий одни и те же вещи – это потенциальная проблема, и что я буду работать над проектом один, я выбрал последний вариант.
Второй вопрос – это архитектура. Можно по-быстрому набросать на форму компоненты, ручками или через LiveBindings всё связать, и быстро получить результат. Но любое небольшое изменение в каком-то алгоритме требует пересборки и обновления всех программ, а это большие затраты по времени на тестирование, чтобы в другом месте ничего не сломалось. Поэтому я принял решение использовать xml для описания всех таблиц и интерфейсов, а всю логику убрать в скрипты.
Для этого я написал собственный редактор форм, через RTTI обращался ко всем свойствам и подсвойствам.
На скриншоте видно, что элемент связан с таблицей Orders, но отображает не её содержимое, а ссылку на customer, колонку FirstName (имя заказчика). Так же при нажатии будет вызван обработчик atApplyChanges, который применит все изменения на форме, и закроет её. Без единой строчки кода! Естественно, когда в таблице Orders что-то будет меняться, то вызовется скрипт, который проверит корректность изменения. Что-то типа:
То есть произойдёт проверка смены, кассы, если надо выпишутся приходники/расходники и т.д. Так же если поменять в этом алгоритме что-то, то не надо повторно пересобирать программы и обновлять всё везде. Достаточно клиенту перелогиниться.
Следующий момент, который безумно напрягает во всех нынешних решениях – это латентность. Любое действие приводит к select из базы. Т.е. время пинга+передачи пакета+select+gzip — это минимальное время, через которое у оператора что-то произойдёт. А когда праздники и мало того, что повышенная нагрузка на оператора да ещё и сервер начинает тормозить, вот тут начинаются реальные денежные потери. Что бы этого не происходило, я сделал кэширование всех нужных данных в ОЗУ, и выборку оттуда через запросы. Сервер напрягается лишь транзакциями update/insert, а потом изменённые и новые данные рассылает всем подписчикам.
С отображением информации тоже пришлось сделать интересные оптимизации. Так как у нас нет select из 10 таблиц, то как, например, из таблицы деталей доставки выяснить, куда везти заказ (у меня точка хранится в таблице домов ФИАС)? Примерно вот так:
Т.е. прошли через 3 промежуточные таблицы и сопоставили заказ с точкой на карте, что бы её нарисовать. Всё очень быстро, и без единого обращения на сервер. И нарисовали в браузере ручками через соответствующее api. То есть так как у гугла большие проблемы с картами в России “в замкадье”, на андроиде использую яндекс, у которого эти проблемы выражены гораздо меньше. Через api 1.1 даже кода разработчика получать не надо, что бы отобразить пункты назначения и пробки например.
Естественно, всё это надо было как-то сопрягать с (пока) основной бизнес-системой. Основная бизнес-система (не буду её называть) печатает на принтере заказы. Небольшое использование сниффера показало, что печатается pdf. Через пол дня была готова моя программа, которая полностью копировала протокол оригинальной (до байта, спасибо, что исходники компонент дельфи доступны и там можно легко поправить заголовок не заморачиваясь с raw socket), но помимо печати на принтере парсила эти pdf и вычитывала оттуда заказ, загружая его в базу. Но этот метод носил некоторые ограничения. Во-первых, выгружалась не вся нужная информация, а пару полей приходилось перезаполнять оператору, а во-вторых, это была лишь синхронизация по заказам. Например, рейсы доставки приходилось формировать и там и там. Поэтому был написан прокси, который анализировал всю проходящую через него информацию и эта проблема решилась.
Оно отсылает в фоне на сервер трек. То есть оператор может в реальном времени наблюдать за перемещением курьеров. Так же для подтверждения доставки заказа курьер должен находиться в некотором заданном радиусе от точки доставки. Но при этом может отсутствовать интернет. И тогда программа передаст информацию о том, что заказ доставлен, как только интернет появится. Естественно, можно из программы запустить яндекс-навигатор, который автоматически проложит путь до адреса; можно посмотреть все адреса на карте, или позвонить клиенту, нажав 2 кнопки, и так далее.
В общем, система получилась очень мощной, с большим количеством возможностей реализованных, и с ещё большим количеством заложенных. И… оказалась не нужна. В последний момент заказчик стал изменять изначальные требования: начал в приказном тоне говорить, чтобы я делал так-то и так-то, потому что иначе это работать не будет (к слову, это требования полного переписывания всего на другом ЯП, просто «чтобы было»)… На резонный вопрос “а ведь работает”, “работает быстрее, чем текущая система” и т.д. меня будто не слышал. На этом мы расстались. В общем, сейчас у меня есть интересная, почти готовая, ERP система. Там не хватает каких-то отчётов, хорошо бы допилить (если это будет востребовано) изначально заложенный функционал автоматического разброса заказов по кухням, в зависимости от пробок и текущей загрузки точек и т.д. Доработать это, а так же реализовать дополнительный функционал – совершенно не сложно. А до тех пор моя ERP система ищет нового заказчика, а я новую работу. :)
P.S. Многим, я думаю, будет интересно узнать какого вообще разрабатывать кросс-платформенные приложения на RAD Studio. Выскажу своё субъективное и предвзятое мнение: на последней студии, со всеми апдейтами работать можно. Есть некоторые проблемные компоненты типа TWebBrowser, у которого сложности с удалением себя под всеми OS. Или проблемы у компонент типа TGrid на тач устройствах. Но это всё решаемо. Так же есть большая проблема, что установленный apk ~ это 100Mb. Да, жесть, согласен, но в остальном лишь преимущества. Единая кодовая база, куча компонент из коробки на все случаи жизни, причём под FireMonkey они стали гораздо гибче, чем vcl. Так что основная проблема нынешней Rad studio – это цена. Всё остальное в ней весьма достойно.
Первый вопрос, который у меня возник – это средство разработки. Можно было взять что-то новомодное типа NodeJS для сервера, и отдавать web-интерфейс клиентам – самый простой, но самый тормозной вариант (аналогичные решения требуют i3). Можно прописывать отдельно серверную часть, отдельно каждое приложение (windows/android/ios). Или NodeJS сервер, и C# (xamarin если точнее) под все клиенты единый код. Или взять последнюю Rad studio и написать на единой кодовой базе всё. Так как я понимал, что разный код, описывающий одни и те же вещи – это потенциальная проблема, и что я буду работать над проектом один, я выбрал последний вариант.
Второй вопрос – это архитектура. Можно по-быстрому набросать на форму компоненты, ручками или через LiveBindings всё связать, и быстро получить результат. Но любое небольшое изменение в каком-то алгоритме требует пересборки и обновления всех программ, а это большие затраты по времени на тестирование, чтобы в другом месте ничего не сломалось. Поэтому я принял решение использовать xml для описания всех таблиц и интерфейсов, а всю логику убрать в скрипты.
Для этого я написал собственный редактор форм, через RTTI обращался ко всем свойствам и подсвойствам.
На скриншоте видно, что элемент связан с таблицей Orders, но отображает не её содержимое, а ссылку на customer, колонку FirstName (имя заказчика). Так же при нажатии будет вызван обработчик atApplyChanges, который применит все изменения на форме, и закроет её. Без единой строчки кода! Естественно, когда в таблице Orders что-то будет меняться, то вызовется скрипт, который проверит корректность изменения. Что-то типа:
Немного скрипта
CurOrderState := GetNewValueF('Orders','OrderState');
LastOrderState := GetOldValueF('Orders','OrderState');
IsCashbackOnCurier := GetNewValue('Orders','CashbackOnDeliverer') = 'True';
PayType := GetNewValueF('Orders','PayType');
OldPayType := GetOldValueF('Orders','PayType');
OrderTurn := GetNewValueF('Orders','Turn');
CurTurn := GetConstantValue('CurrentTurn');
OrderNo := GetNewValue('Orders','OrderNo');
OrderPrice := GetNewValueF('Orders','Price');
PaySum := GetNewValueF('Orders','PaySum');
LastPaySum := GetOldValueF('Orders','PaySum');
CurTurn := GetConstantValue('CurrentTurn');
CurCashbox := GetConstantValue('CurrentCashbox');
if (OrderTurn > 0) and (OrderTurn <> CurTurn) then
begin
ShowMessage('Нельзя производить действия с заказом другой смены. Заказ №'+IntToStr(OrderNo));
exit;
end;
if (LastOrderState = 9) then
begin
ShowMessage('Нельзя производить действия с завершенным заказом');
exit;
end;
if (LastOrderState = 8) then
begin
ShowMessage('Нельзя производить действия с отменённым заказом');
exit;
end;
if (LastOrderState <> 8) and (CurOrderState = 8) then
begin
TransactionCanAccept;
exit;
end;
if (CurOrderState > 2) and (CurTurn < 1) then
begin
ShowMessage('Смена не открыта. Действие не может быть совершено');
exit;
end;
if (CurOrderState > 4) and (CurCashbox < 1) and (CurOrderState <> 8) then
begin
ShowMessage('Касса не открыта. Действие не может быть совершено');
exit;
end;
//Запрет изменения сумм, так как есть кассовые доки.
if IsCashbackOnCurier then
begin
if PaySum <> LastPaySum then
begin
ShowMessage('Уже нельзя менять суммы оплаты');
exit;
end;
Price := GetNewValueF('Orders','Price');
LastPrice := GetOldValueF('Orders','Price');
if Price <> LastPrice then
begin
ShowMessage('Уже нельзя менять суммы оплаты');
exit;
end;
end;
// Формируем сдачу
if (CurOrderState >= 6) and (CurOrderState < 8) and (PayType = 1) and (not IsCashbackOnCurier) then
begin
if (PaySum - OrderPrice) > 0 then
begin
ss := 'Выдача сдачи для заказа №'+IntToStr(OrderNo);
CreateCashboxDoc(ss,1,OrderPrice - PaySum);
IsCashbackOnCurier := True;
SetValue('Orders','CashbackOnDeliverer',True);
end;
end;
//Отмена сдачи для курьера по статусу
if (CurOrderState < 6) and IsCashbackOnCurier then
begin
if (PaySum - OrderPrice) > 0 then
begin
CreateCashboxDoc('Отмена выдачи сдачи для заказа №'+IntToStr(OrderNo),1,PaySum - OrderPrice);
IsCashbackOnCurier := False;
SetValue('Orders','CashbackOnDeliverer',False);
end;
end;
// Формируем возврат сдачи
if (CurOrderState >= 8) and IsCashbackOnCurier then
begin
if (PaySum - OrderPrice) > 0 then
begin
ss := 'Возврат сдачи для заказа №'+IntToStr(OrderNo);
CreateCashboxDoc(ss,1,PaySum - OrderPrice);
IsCashbackOnCurier := False;
SetValue('Orders','CashbackOnDeliverer',False);
end;
end;
// Формируем приходник на сумму заказа
if (CurOrderState = 9) and (LastOrderState <> 9) and (PayType = 1) then
begin
ss := 'Розничная выручка с заказа №'+IntToStr(OrderNo);
CreateCashboxDoc(ss,2,OrderPrice);
end;
// Назначаем смену и филиал при переходе из статуса новый дальше
if (LastOrderState < 3) and (CurOrderState >= 3) then
begin
if CurTurn <= 0 then
begin
ShowMessage('Смена не открыта. Движение заказа не возможно.');
exit;
end;
SetValue('Orders','Turn',CurTurn);
CurFilial := GetConstantValue('FilialID');
SetValue('Orders','Filial',CurFilial);
end;
if (CurOrderState <= 2) and (LastOrderState > 2) then
begin
SetValue('Orders','Turn',0);
end;
TransactionCanAccept;То есть произойдёт проверка смены, кассы, если надо выпишутся приходники/расходники и т.д. Так же если поменять в этом алгоритме что-то, то не надо повторно пересобирать программы и обновлять всё везде. Достаточно клиенту перелогиниться.
Следующий момент, который безумно напрягает во всех нынешних решениях – это латентность. Любое действие приводит к select из базы. Т.е. время пинга+передачи пакета+select+gzip — это минимальное время, через которое у оператора что-то произойдёт. А когда праздники и мало того, что повышенная нагрузка на оператора да ещё и сервер начинает тормозить, вот тут начинаются реальные денежные потери. Что бы этого не происходило, я сделал кэширование всех нужных данных в ОЗУ, и выборку оттуда через запросы. Сервер напрягается лишь транзакциями update/insert, а потом изменённые и новые данные рассылает всем подписчикам.
С отображением информации тоже пришлось сделать интересные оптимизации. Так как у нас нет select из 10 таблиц, то как, например, из таблицы деталей доставки выяснить, куда везти заказ (у меня точка хранится в таблице домов ФИАС)? Примерно вот так:
fids := CComponentBaseLink.ClassGetPrintValue('Orders_Delivery_Details','Order|Orders->CustomerAddress|Customer_address->FiasHouse|Fias_Houses->ID',orid);
if not StrToInteger(fids,fid) then
Continue;
las := g_Base.GetTblValueByID('Fias_Houses','PointLatitude',fid);
los := g_Base.GetTblValueByID('Fias_Houses','PointLongitude',fid);Т.е. прошли через 3 промежуточные таблицы и сопоставили заказ с точкой на карте, что бы её нарисовать. Всё очень быстро, и без единого обращения на сервер. И нарисовали в браузере ручками через соответствующее api. То есть так как у гугла большие проблемы с картами в России “в замкадье”, на андроиде использую яндекс, у которого эти проблемы выражены гораздо меньше. Через api 1.1 даже кода разработчика получать не надо, что бы отобразить пункты назначения и пробки например.
Естественно, всё это надо было как-то сопрягать с (пока) основной бизнес-системой. Основная бизнес-система (не буду её называть) печатает на принтере заказы. Небольшое использование сниффера показало, что печатается pdf. Через пол дня была готова моя программа, которая полностью копировала протокол оригинальной (до байта, спасибо, что исходники компонент дельфи доступны и там можно легко поправить заголовок не заморачиваясь с raw socket), но помимо печати на принтере парсила эти pdf и вычитывала оттуда заказ, загружая его в базу. Но этот метод носил некоторые ограничения. Во-первых, выгружалась не вся нужная информация, а пару полей приходилось перезаполнять оператору, а во-вторых, это была лишь синхронизация по заказам. Например, рейсы доставки приходилось формировать и там и там. Поэтому был написан прокси, который анализировал всю проходящую через него информацию и эта проблема решилась.
Курьерское приложение.
Оно отсылает в фоне на сервер трек. То есть оператор может в реальном времени наблюдать за перемещением курьеров. Так же для подтверждения доставки заказа курьер должен находиться в некотором заданном радиусе от точки доставки. Но при этом может отсутствовать интернет. И тогда программа передаст информацию о том, что заказ доставлен, как только интернет появится. Естественно, можно из программы запустить яндекс-навигатор, который автоматически проложит путь до адреса; можно посмотреть все адреса на карте, или позвонить клиенту, нажав 2 кнопки, и так далее.
В общем, система получилась очень мощной, с большим количеством возможностей реализованных, и с ещё большим количеством заложенных. И… оказалась не нужна. В последний момент заказчик стал изменять изначальные требования: начал в приказном тоне говорить, чтобы я делал так-то и так-то, потому что иначе это работать не будет (к слову, это требования полного переписывания всего на другом ЯП, просто «чтобы было»)… На резонный вопрос “а ведь работает”, “работает быстрее, чем текущая система” и т.д. меня будто не слышал. На этом мы расстались. В общем, сейчас у меня есть интересная, почти готовая, ERP система. Там не хватает каких-то отчётов, хорошо бы допилить (если это будет востребовано) изначально заложенный функционал автоматического разброса заказов по кухням, в зависимости от пробок и текущей загрузки точек и т.д. Доработать это, а так же реализовать дополнительный функционал – совершенно не сложно. А до тех пор моя ERP система ищет нового заказчика, а я новую работу. :)
P.S. Многим, я думаю, будет интересно узнать какого вообще разрабатывать кросс-платформенные приложения на RAD Studio. Выскажу своё субъективное и предвзятое мнение: на последней студии, со всеми апдейтами работать можно. Есть некоторые проблемные компоненты типа TWebBrowser, у которого сложности с удалением себя под всеми OS. Или проблемы у компонент типа TGrid на тач устройствах. Но это всё решаемо. Так же есть большая проблема, что установленный apk ~ это 100Mb. Да, жесть, согласен, но в остальном лишь преимущества. Единая кодовая база, куча компонент из коробки на все случаи жизни, причём под FireMonkey они стали гораздо гибче, чем vcl. Так что основная проблема нынешней Rad studio – это цена. Всё остальное в ней весьма достойно.
brrr
Так может стоило более подробно разобраться и донастроить? Мне тоже не нравиться Linux/Windows/MacOS… Может не стоило убегать от проблем?)) И хочется услышать, что за система была изначально у знакомого? И по описанию то, что вы делали ну никак не ERP, скорее CRM
"Огласите весь список пожалуйста", что же умеет в итоге система-то, чего не умеют другие? Почему интересная? Что значит почти готовая?
В целом мне кажется статья получилась скомканная. Я не понял прелестей ни Delphi, ни RAD studio, и не понял о чем система, почему же она "мощная".
VolCh
Контроль за персоналом это уже точно ERP фича, да и логистика тоже.
brrr
Нет. ERP имеет весьма формализованное представление.
gks
ERP = MRP I + MRP II + финансовый контур
MRP I — это специальный алгоритм управления запасами для производства
MRP II — Это управление производственными мощностями
То есть тут нет ни одного пункта из ERP,
Транспортная логистика, работа с персоналом не входят в ERP
ERP II = ERP + CRM
У вас часть CRM + HRM
akadone Автор
Вся производственная мощность — это и есть персонал, которому надо говорить в какой момент что делать. Это распределение нагрузок и пр. И это именно ERP система. Естественно в архитектуру это заложено, но сейчас например нет одной из главных вещей — автоматическое распределение заказов по точкам с учётом текущей нагрузки и пробок. Так же и некоторых других.
Пока решались другие проблемы: например что заказ начинался делаться через 10 минут после поступления. А всего на приготовление и упаковку 20 мин.
Dementor
Возможно у вас именно ERP и вы полностью повторили функциональность SAP R3, но почему вы в статье рассказывали исключительно только про CRM (работа с клиентами), HRM (работа с персоналом) и TMS (работа с доставкой)? Вам же подсказывают про MRP I и MRP II. Где ваши анализы сезонных продаж (с учетом праздников) и составление на их основе планов производства и закупки ингредиентов (закупите больше — увеличите затраты из-за просрочки неиспользованного; закупите меньше — получите недополученную прибыль и уменьшение лояльности покупателей)? Где ваши расчеты по заготовке полуфабрикатов (последний элемент для суши и пиццы вообще очень важен, так как эти классы продуктов компонуют из заготовок, срок жизни которых от пары часов до суток, а потом нужно буквально утилизировать «деньги»)?
akadone Автор
Не хочу спорить кто что подразумевает под этой аббревиатурой. Исходная система заказчика имела куда более скромные возможности, но тоже носило гордое название Farfor ERP. Хотя по факту там только приём заказов, пара выгрузок, да десяток отчётов.
VolCh
ERP в широком смысле — это управленческая стратегия. ERP-система — система, помогающая эту стратегию реализовать, как правило, без перехода в другие системы, но не обязательно. ERP-система может импортировать первичные данные из одних (например, фискальных) систем и экспортировать в другие (например, OLAP). Так же имеется тенденция выделять в отдельные системы (пускай и интегрированные с ERP) то, что обычно было их модулями/подсистемами. например CRM модули.
Dementor
VolCh, не люблю цитировать википедию, но уж больно хорошо у них написано:
akadone Автор
Подскажите, пожалуйста, что не так с целью оптимизации и контроля за производством: в каждый конкретный момент система говорит что делать конкретному сотруднику, перераспределяет нагрузки между кухнями, контролирует выполнение и так далее. Почему это не ERP? Не понимаю.
В этом бизнесе опоздание и пересорт — самые частые косяки. Не заметны убытки от того, что испортилась какая-то залежавшаяся рыба на фоне 2-х отказов за день из-за косяка повара, который по запарке перепутал ингредиенты. Или косяка, что нет доставщика на точке в важный момент, так как все 4-5 стоят в пробках из-за не оптимально составленных рейсов.
Dementor
Нельзя просто взять сказать «я сделал ERP-систему» и далее рассказывать о том, как парсишь PDF-документ и с телефона передаешь GPS-трек. Нельзя, потому что самое быстрое внедрение уже готовой ERP-системы про которое я слышал заняло три месяца (настройки, обучение, перенос данных). Внедрения с доработками идут по году. А написание систем для управления ресурсами предприятия «с нуля» занимает годы.
Что еще не так в статье? Не сказано, чем именно не устраивала система FARFOR, какие блоки автоматизации процессов были доработаны и какие вообще написаны заново, как именно была выполнена связка с основной системой? Я так и не понял — у вас «прокси» на корпоративный софт с вашим дополнительным функционалом или отдельная самостоятельная полноценная система, которая никак не зависит от легаси и имеет с ней двухстороннюю синхронизацию как отключаемую опцию? В целом, ну никак не показана ценность созданной системы. У меня сложилось впечатление, что вы просто какой-то плагин сделали, который работает исключительно поверх чужой программы.
gks
Попробую зайти из далека и объяснить принципиальные вещи.
Существует две производственные модели:
1. Выталкивающий типа, когда делается анализ рынка и строится производственный план. И далее весь произведенный товар выкидывается на рынок и его толкают.
2. Вытягивающего типа, когда делается заказ, и уже производственная система производит товар согласно заказу.
Как не сложно догадаться, ваша система вытягивающего типа. ERP система — это система поддерживающая первый, выталкивающий тип производства.
Поэтому ваша система просто по определению не может быть ERP. Там другие алгоритмы и модели управления производством. Поэтому, ERP звучит очень модно и люди часто используют это слово для продвижения своей системы. Тут ничего плохого нет. Только у вас не ERP. Вам нужно позиционироваться как системы вытягивающего типа, там своя терминология, и тоже не менее популярна. Например, бережливое производство LEAN Production.
ru.wikipedia.org/wiki/%D0%91%D0%B5%D1%80%D0%B5%D0%B6%D0%BB%D0%B8%D0%B2%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B8%D0%B7%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE
akadone Автор
Что донастраивать, если просто НЕТ этого функционала? Ни из коробки, ни вообще.
Что именно не понятно?
brrr
Ответьте для начала на мои вопросы в коментарии
akadone Автор
Прочитайте для начала текст статьи. Там всё описано. Зачем задавать вопрос, если статью не читал?
Whuthering
Я вот внимательно прочитал, и даже не один раз, но тоже могу сказать, что ответов на вопросы, затронутых автором комментария, там нет. Может все-таки ответите?
akadone Автор
Что умеет система, чего не умеют другие? Система заточена под конкретный бизнес. Аналогов в данной области ей нет. Просто нет, так как там конкуренты типа ArchiDelivery и Farfor ERP. То есть ни о чём. Я за пару месяцев вывел функционал на более высокий уровень, чем они пиля годами и 10-ю программистами. Но область достаточно специфичная, крупные игроки её или всерьёз не воспринимают, или вовсе не знают о ней. Почему — свечку не держал.
Про остальное -достоинства RAD Studio — в статье постарался подробно изложить. А о донастройке систетемы — сам не понял о чём автор поста сказал. Причём тут windows/linux/mac вообще.
brrr
То есть целые команды и продукты ни о чем? Только наш «одинокий рейнджер/ниндзя» знает и могёт лучше, чем все эти… Да тут мания величия на лицо. Хотя лучше всего вашу статью вашу статб описывает комментарий ниже https://m.habrahabr.ru/post/345274/comments/#comment_10582048
akadone Автор
Когда целая команда из 8 человек за месяц не может найти куда пропадают заказы с планшета — говорит о многом.
Что же до того комментария — вот как я могу постороннему человеку продемонстрировать работу своего ПО? Дать логин/пароль? Может сразу админский?
P.S. Я предпочитаю троллей не кормить.
FyvaOldj
> Когда целая команда из 8 человек за месяц не может найти куда пропадают заказы с планшета — говорит о многом.
Говорит что руководство не умеет адекватно взаимодействовать с ИТшниками (наприме: некорректно ставят задачи, не адекватно платят, не требуют результатов/не контролируют). Тут бы новому исполнителю ИТшнику насторожиться бы. А нет — полезем головой в петлю. Хоть предоплату то взяли?
Приятно конечно мнить себя в восемь раз более эффективным чем коллеги. Однако это было бы так если бы этот одиночка-«гений» сумел бы внедрить систему.
А невнедренная система ни о чем не говорит.
Может ее при внедрении переделывать да доделывать на 90% еще.
akadone Автор
Руководство поставило им простую задачу: на кухню и упаковку надо поставить планшеты, курьерам телефоны. Было это где-то в сентябре (могу чуть путать). И это не просто IT отдел, а целая контора (в гугле быстро ищется). Они рулят серверами, допиливают функционал. Нюансов их внутренней кухни я не знаю, но в середине декабря их решение по планшетам было почти готово. Последний месяц они искали «куда деваются заказы с планшета». Это цитата.
Да. Это так. Внедрение началось, достаточно успешно, и тут заказчик «включил заднюю». Поэтому я и решил посоветоваться с хар-сообществом, но вместо позитива меня заминусовали. Ну что же. Бывает и такое.
FyvaOldj
То есть вариант что здесь люди знающие и если они говорят что вы сделали ни то — вы исключаете и им не верите?
Dementor
Я хоть и не плюсовал, но и не минусовал. Как-то нейтрален к вашей истории. Но вам не нужно сейчас включать обиженного и жаловаться на непонимание сообществом. Если хотели посоветоваться, то нужно было открыто просить совета в статье, а не пиарить RAD Studio и не пытаться искать потенциальных заказчиков на оказавшуюся ненужной программу.
brrr
Мне не понятна ваша реакция.
Лейтмотив вашей статьи и комментариев — это противопоставление вас одного целому пласту науки о проектировании ПО и профсообществу. Статья более, чем туманна:
Вы восхваляете свои решения, но при этом выдаете либо "эскизы" кода, либо вовсе умалчиваете о реализации, говоря обобщенно.
Вы описываете предпосылки создания субъективным желанием без даже малейших попыток анализа существующих решений.
Вы описываете систему немногочисленными возможностями, тут же называете ее "мощной", но абсолютно умалчиваете об инфраструктуре решения, не называете ни сроков реализации, ни заявленных требований, ни критериев качества по которым можно оценить результаты.
Вы пытаетесь акцентировать внимание на ЯП и инструменты разработки, которые к вашей т.н. ERP имеют посредственное отношение.
А демонстрация системы ограничивается только передачей админского пароля?
Вместо того, чтобы хамить и обзывать троллями, вы бы могли просто нас просвятить и выпустить две отдельные статьи одна — презентация системы, другая — о том, как здорово работать в RAD studio. Блесните знаниями и опытом более детально.
izzholtik
А как происходит обновление информации в кэше клиента?
p.s. настоящие люди умеют распознавать такие капчи :)
vism
тоже очень интересно, я как это прочитал, офонарел аж!
electronus
А какова же истинная причина «заднего хода» заказчика?
yarosroman
А у меня вопрос один, вы студию купили или с торрентов скачали, а друг вас кинул с оплатой?
bgBrother
Возможны разные пути «бесплатно» получить лицензию: named через работодателя или «одолжить» concurrent лицензию у друга. Простите, но я считаю, что нет смысла здесь это обсуждать и, тем более, намекать о пиратстве практически ничего о авторе не зная.
Правила лицензирования Rad Studio
bgBrother
Если это вовсе никакой не намёк, прошу извинить.
kxl
опАздание?
kalaider
За что минусуем, товарищи? Мне тоже глаз режет. Хотя о таком все-таки лучше в личку.
kxl
Согласен, насчет лички, это если в статье ошибка, понятное дело. Тут же… я думаю, заказчик оценил.
kalaider
После прочтения самой статьи того же мнения.
antonksa
Пез… ц
kuftachev
"Мощная ERP", один человек делал… Что-то совсем не сходится. Я бы ещё понял, если бы лёгкая и персонализированная под конкретного заказчика без лишнего функционала...
Suvitruf
Эх, сразу вспоминаю университет и свою «мощную ERP», которую писал для диплома. Спасибо за статью, всплакнул.
Areso
Нет ТЗ и договора — результат ХЗ и без денег.
Shtucer
Либо после слова "какого" пропущено слово на букву "х", либо… впрочем, меня и этот вариант устраивает.
cleaner_it
Каждый должен написать свой велосипед) Это, конечно, не ERP, но для небольшой компании может быть востребовано — только описание нужно сделать толковое. Про то, как разошлись с заказчиком, можно не говорить, достаточно сказать, что система в бета-релизе. Желаю удачи.
PS: Грамматические и орфографические ошибки нужно вычитывать перед публикацией.
vism
Когда читал статью, был в шоке.
Сам в основном занимаюсь разработкой ERP, CRM.
Очень рад за клиента, что он отказался и надеюсь не заплатил.
Автор, когда клиент к тебе обращается — он ждет что-то хорошее.
А ты с момента выбора технологии и реализации начал клиенту свинью подкладывать.
ERP такая штука, которая всегда подвержена доработкам и изменениям, притом доработкам, порой очень нелогичным (которые не укладываются в логику).
Такие системы должны быть:
1. Очень гибкие — чтоб можно было менять и дорабатывать все что угодно, особо при этом не ломая другие модули
2. Написаны на популярных и простых технологиях — если вдруг за такой код, как вы делали, вас в лес увезут, чтоб другой программист мог дальше работать. Ваш код легче выкинуть, чем копаться в ваших изобретениях.
И да, согласен с этим комментом habrahabr.ru/post/345274/#comment_10581006
И вобще, я засмеялся когда прочел это
Вы там зазвездились? Вы сделали и пусть работают как хотят с вашими костылями? )))
И что за дер… код вы написали, при котором все переписывать надо?) Да и в целом сразу не догадались, чтоб будут такие проблемы?)
Выбрали ЯП для задачи, которую намного лучше решать другими ЯП -> Сами в статье написали что нихрена оно не удобно и вы написали свой редактор форм (Карррл, уже тут надо было СТОП) -> на нем все закодили. А потом вдруг оно не гибким оказалось? Пришлось не код под функционал, а функционал под код подстраивать?? КАААРЛ!!!
А как вы сделали рассылку кэша по клиентам?
Я так понял вы при каждом обновлении рассылали кэш по всем клиентам? в Оперативку всю базу по сути??? Вы там совсем упали с высоты, слово на букву е.. чтоли???
Пошел пить валидол…
VolCh
Судя по наличию слова «подписчики», клиенты подписываются на изменения интересующих их сущностей.
vism
То есть для руководителя и помощника руководителя, для полноценной работы по сути все должно грузиться?)
Допустим база клиентов в 150К с адресами, историей заказов и т.п.
Оно как на сервере… захадркожена пагинация которая на клиенте и отдаются клиенты в соответствии с текущей страницей или все сразу?
Если отдается в соответствии с текущей страницей, всякие фильтры, сортировки — это уже отдельно на сервере вычисляется из кэша и отдается или как?
Если отдается вся база в 150К пользователей с зависимостями, как оно там на клиенте сортируется, да и в целом хранится)
VolCh
Клиент сам решает на что подписаться и сообщает серверу о своём решении. Обычно, да, текущая страница списка +- несколько для плавной прокрутки, если говорить об отображении списков. Детализация — по месту решается, если строка списка отличается от полного представления несколькими полями, то проще сразу отдать их, если разница в разы или на порядки, то сделать отдельный запрос.
vism
вы мне паттерн описываете, или то как было реализовано у автора статьи?
kuftachev
У нас, когда столкнулись с сайтом на Ruby, люди сделали какашку, а нам предлагали взять после них на поддержку, родилась шутка, что сайты нужно было делать на Erlang, а дальше как в анекдоте:
Украинец и еврей отбились от каравана в пустыне, каждый естественно прихватил самое дорогое себе, украинец -мешок с салом, еврей — мешок с золото. Еврею кушать хочется, и говорит:
Сознательно или несознательно, но выбор технологий сделан так, чтобы никто ничего не правил...
Whuthering
Вот те же мысли при прочтении.
Я примерно догадываюсь, как появилась эта статья — некоторое время назад автор бил пяткой в грудь и прославлял RAD Studio, нелицеприятно отзываясь о тех, кто выдвигал какие-то сомнения и контраргументы. Когда автора попросили привести современных, сложных и широкоиспользуемых проектов сделанных в RAD Studio, был рассказ про «мою крутую систему которая умеет столько всего и не тормозит», а когда попросили показать, как оно работает и устроено — замолчал. И вот появилась статья.
И, честно говоря, как-то тоскливо становится. Навернуты свои костыли для дизайна форм и скриптования. Применены очень сомнительные архитектурные решения. По описанию продукт выглядит как какая-то наколенная поделка или диплом студента IT-шной специальности. И в итоге выясняется, что разработка оказалась никому не нужна.
Вот четсно, по-моему такие примеры — это скорее не реклама, а наоборот антиреклама использованной технологии разработки. А хороших примеров по-прежнему нет.
brrr
Отличное резюме для этой статьи. Мне кажется в анамнезе у автора немного мании величия)))
vladob
молодость?
o4karek
Склад, сборка и доставка — это совсем не ERP.
Ну и написать ERP в одно лицо если и можно, то на это придется потратить лет 5+ и при этом очень неплохо разбираться в экономике. И немного программировать :)
Но самое интересное начнется потом, когда созданную «ERP» кто-то купит :)
Начнутся ошибки, хотелки (которые зачастую противоречат одна другой), падение производительности под нагрузкой (хотя-бы человек 150-200 одновременно), а самое главное — поддержка под текущее законодательство.
И весь описанный выбор фреймворков, классов и прочего инструментария окажутся такими не важными и не интересными…
vism
Да если ERP под одно предприятие, не большое, как у заказчика из статьи, то в принципе можно. Только при этом надо писать по частям, много общаться и встречаться с заказчиком по поводу бизнес процессов. Т.к. обычно у таких заказчиков требования слабо формализованы изначально.
Ну и будет это все писать не то что долго, а скорее постоянно дорабатываться, годами.
Бизнес всегда меняется, предприниматель всегда крутится и меняет что-то. Под это обычно и система меняется.
Но как оказалось, не все это понимают)))
o4karek
Только это будет не ERP :)
Ведь всякие SAP-ы и прочие 1C-ы, не говоря о Галактиках — они ведь удавятся от бессилия.
И да, никто не спорит, что можно написать заказную систему для конкретного заказчика. Но при этом надо понимать, что «писатель» попал в рабство на всю жизнь. Он будет неотъемлемой частью написанного. Даже когда ему опостылет это писать :)
Ну и стоит посмотреть на этого «заказчика», который, кажется, не понимал, на что он подписывается в описанном случае.
vism
Да, часто это проблема. Но, есть заказчик — найдется и исполнитель :)
Когда это пишется на популярных технологиях и фрэймворках профессионалом, не все так страшно.
Я когда пишу код, всегда пишу с тем расчетом, что в любой момент разработчик может сменится. И чтоб другой, кто увидит мой код и возьмет его доработку, мог как можно легче разобраться и приступить.
Ну и когда растет система, если один разработчик, надо бить в колокола и объяснять заказчику, что нужна команда, документация и т.п. Иначе с разбитым корытом останется :)
o4karek
У меня нет понимания, как может один человек хорошо разбираться с таком объеме предметной области. А если понимания не будет — будет стандартная софтина, созданная из говна и палок. Не потому, что писатель кривой, а потому, что понимания предмета нет.
Т.е. код и его качество — это вторичный вопрос (увы) по сравнению с качество постановки задачи.
VolCh
Эксперты со стороны заказчика должны, прежде всего. разбираться и передать разработчику необходимую ему для реализации часть своих знаний предметной области. Что передали, то и получат. Да, хорошо, если разработчик разбирается, и может заметить, что, например, не переданы некоторые детали и уточнить их, или заметить, что требования не включают решения стандартных для отрасли проблем, с которыми заказчик ещё не столкнулся, но в обозримом будущем с большой вероятностью столкнётся. Но это не обязательно для успешного внедрения. Тут как раз качество кода роляет — насколько код готов к оперативным изменениям, когда заказчик увидит, что он получил не то, что хотел, а то, что озвучил.
o4karek
Это не то, чтобы заблуждение, но такое внедрение, скорее всего, будет обречено на провал. Причина очень простая — заказчик будет пытаться всех своих текущих тараканов затащить в новую систему. При этом далеко не факт, что текущие тараканы: а) законны, б) корректны и в) оптимальны с точки зрения бизнеса заказчика. Их тянут по одной причине — они привычны!
Постановщик со стороны исполнителя обязан разбираться в предмете и обладать квалификацией для поддержания корректного и аргументированного спора по предмету.
И качество кода, повторюсь, здесь вторично. Первичная — общая архитектура системы, структура базы данных. Именно это определяет возможность модернизировать систему.
Если, условно говоря, у вас свойство «пол» физ.лица — это булево, то любое качество кода не позволит этой системе быть успешно внедренной на территории некоторых стран :)
VolCh
Зависит от постановки целей проекта в целом. Если автоматизировать имеющиеся бизнес-процессы, то это одно. Если оптимизировать их, в том числе путём автоматизации, но и не только, то это совсем другое. В обоих случаях у заказчика могут быть описания имеющихся, а могут и не быть. Ещё вариант может быть: вот есть (дорогая, тормозная, ещё какие-то минусы) система с такой-то функциональностью, в которой нам нужно только то-то и то-то, надо сделать систему аналогичную, но только с нужной функциональностью.
Архитектуру я неразрывно связываю с качеством кода. А вот структуру базы уже нет — это тактические решения, а не архитектурные. Если, конечно, архитектура не завязана на конкретное хранилище, типа решения всю бизнес-логику хранить в хранимых процедурах PostgreSQL.
o4karek
Если автоматизировать бардак — получится автоматизированный бардак :)
А есть такие же, только перламутровые? :)
Я в данном случае не пытаюсь убедить вас в чем-то. Я озвучиваю свой опыт из очень большой практики автоматизации предприятий (10+ лет).
Любая доработка системы является компромиссом между хотелкой заказчика, предметной компетентностью исполнителя и возможностями дорабатываемой системы.
Вы поймите, если я закажу вам систему «как 1с» только дешевле — я от вас если что-то и получу, то очень не скоро. Ну т.е. совсем не скоро. И сильно не факт, что дешевле, чем купить готовое у той же 1С. А если добавить еще несколько хотелок — то, возможно, и никогда не получу.
Ну и (ИМХО): для экономического софта качество базы данных — это ключевое, стратегическое качество софтины. Ибо если существующая структура БД не позволяет обеспечить некоторые хотелки, это тянет за собой столько подпрыгиваний и такой геморой, что хочется убиться.
VolCh
Ну, например, относительно быстро вы можете получить от меня систему ведения кассы на торговой точке, если только это вам и нужно от 1С. Но, вообще, 1С не очень пример, поскольку относительно дешевая. SAP или Галактика лучше :)
Не согласен в целом. Всё зависит от архитектуры — если она сильно завязана на схему данных, то вы правы. Если она, как говорится, storage agnostic, то выбор конкретной системы хранения не повлияет на функциональность. Не знаю как сейчас обстоят дела в той же 1С, но помнится были времена, когда она предлагала несколько вариантов хранения данных на выбор.
o4karek
Вот это я точно не посоветую делать на 1с. Особенно, если кэшлайн длинный, номенклатура 700+ тысяч и проходимость хорошая.
И да, у меня будет много вопросов по вашему предложению :)
Если вы под этим термином понимаете независимость от конкретной СУБД, то я вообще о другом. Я говорю именно о структуре базы данных. Какие там таблицы, что в них лежит и как эти таблицы связаны. В какой СУБД это лежит — вопрос 145. И если структура базы «плохая» — на функциональность это влияет напрямую и драматически.
VolCh
Говоря "таблицы", вы, скорее всего, уже подразумеваете реляционные СУБД или даже SQL. Да и в целом, скорее всего, имеете в виду не функциональность, а нефункциональные требования типа скорости работы и потребляемой памяти.
o4karek
Да, SQL СУБД.
Конечно нет. Имеется ввиду и то и то.
VolCh
Как структура СУБД может повлять на функциональность? Ну, считая, что все нужные данные для какой-то функциональности в базе есть и известно где они есть.
o4karek
У меня не получается осмыслить эту фразу :(
Но все-таки не стоит уходить глубже, т.к. в этом случае мы скатываемся в предметную область. И без четкого описания обсуждаемого предмета хорошей дискуссии не получится, т.к. стороны будут вольны уточнять постановку в процессе дискуссии :)
VolCh
ну условно, как повлияет на функциональность полностью нормализованная у нас база, полностью денормализованная или вообще EAV какая-то?
o4karek
Скорее всего никак :) Ибо речь опять не о том.
…
Дальше будет притянутый за уши пример.
Пример: у вас есть таблица, которая хранит продажи со структурой: Товар, Количество, СуммаРубль, СуммаДоллар
Такая таблица доставит вам массу проблем, как только вы захотите продавать товар не только в долларах. Причем не только для задачи зафиксировать факт. А еще надо отчеты какие-то строить…
Такая таблица: Товар, Количество, Валюта1, Сумма1, Валюта2, Сумма2
Создаст значительно меньше проблем при двухвалютном учете, но трехвалютный уже не потянет. Специфика предметной области даст понимание, нужен нам трехвалютный учет или нет. Вот это и есть структура базы.
А теперь на секунду представляем себе, что самая первая структура данных успешно работала N лет. В базе накоплено X Гигабайт данных, с которыми работают M отчетов и всего остального. И теперь надо это все резко сделать многовалютным. И это надо сделать а) примерно вчера и б) база не будет остановлена больше, чем на пару минут/часов/дней (но всегда меньше, чем надо).
И вот тут сразу забывается качество кода, фреймворк, на котором все написано, и вся прочее. А начинаются размышления на тему: как
рыбку съесть и кости сдать за деньгиминимально дешево перелить данные из «старой» таблицы в «новую» и как потом сделать так, чтобы весь тот софт, который раньше работал с простыми циферками, стал быстро и правильно (!) работать с непростыми циферками.На мой непросвященный взгляд — это и есть главная сложность. А на чем и как рисуются формочки и печатаются отчетики — это не самое интересное. SAP вон вполне себе работает на визуальных технологиях терминального века и ничего, живой :)
Ведь не зря вендоры экономического софта меряются не фреймворками и модными технологиями, а [десятками] тысяч работающих в одной базе пользователей и поддержкой актуального законодательства.
VolCh
Тут не в структуре таблиц дело, прежде всего, а в том, что архитектурно заложен строго двухвалютный учёт. Основная проблема не в том, как столбцы называются, а в том что логика, код не заточены под мультивалютный. Изменение структуры данных задача относительно простая, даже вообще без даунтайма, при нормальном коде, в частности в случае когда все операции, которым известно про структуру данных, находятся в одном месте типа репозитория. По сравнению с задачей доработки бизнес-логики.
Areso
Расскажите, пожалуйста, это Борису Нуралиеву. А то мы тут мучаемся с их наиболее распиаренным продуктом (якобы флагманским) 1С:ERP. Каждый раз приходится простой согласовывать, причем простой где-то в середине ночи.
VolCh
Я говорю о системах, где у вас достаточно полный контроль над кодовой базой. Грубо, о "самописе", в котором вы можете, например, без особых проблем организовать запись в две таблицы (старая и новая) новых данных, пока где-то в фоне переливаются сотни гигабайт старых.
FyvaOldj
Ваш оппонент забыл упомянуть чем приходиться платить за "изменение без даунтайма" и пояснить почему все таки при всех их недостатках по гибкости от реляционных СУБД полностью не отказались до сих пор.
o4karek
Для понимания вопроса — можете озвучить свой реальный опыт по изменению структуры таблиц в боевой БД размером гигов 100 и порядка 100 активных пользователей или ваш опыт чисто теоретический?
При правильной структуре БД доработки бизнес-логики, можно считать, бесплатны. Хотя смотря что называть бизнес-логикой :)
VolCh
Не чисто. На вполне себе боевой базе MySQL на таблицах в десятки миллионов записей с обычной миграцией на тестовых контурах от 8 часов.
Бизнес-логика — логика предметной области, не имеющая отношения в общем случае к техническим деталям типа СУБД или ЯП.
SergeyUstinov
Качество базы данных — это не СУБД, а качество логической структуры (ER диаграммы). Если структура хорошая, то её можно для начала хоть на SQLite реализовать, а потом переносить на другие субд, и все обойдется относительно небольшими переделками. А если структура базы плохая — такую ERP ничего не спасет.
VolCh
Для меня структура база данных и структура данных приложения, модель предметной области в приложении, вещи хоть и связанные на практике, но слабо.
michael_vostrikov
То есть у вас есть нестандартная среда разработки (редактор форм), свой скриптовый язык, движок для него написан на устаревшем языке, компилятор которого к тому же стоит немало, и вы считаете, что это недостаточные причины просить использовать другой язык? Где и за какие деньги ему искать программиста искать для доработки, если с вами связь потеряется или вы будете слишком заняты на другой работе? А потом еще ждать, пока программист в документации на все это разберется (у вас ведь она есть).
И вопросов по реализации здесь тоже хватает.
michael_vostrikov
Почитал комменты автора, думаю эти вопросы написать не помешает.
Ну так вы не весь функционал сделали, а только часть, естественно она будет быстрее работать.
Почитайте что-ли как делаются API (серверные) и что такое WebSocket. А для вашего черно-белого интерфейса никакого i3 не надо.
Отказались от скриптового серверного NodeJS, но в результате все равно сделали скрипты на сервере. К чему тогда слова про единую кодовую базу?
То есть у вас клиент коннектится напрямую к базе? А пароль захардкожен или вы каждому свой выдаете? А если оператор SQL-клиент скачает?
Ну так в web, от которого вы отказались, все это есть из коробки. Достаточно страницу обновить.
Во всех решениях на Delphi? Возможно. О чем это говорит? Что она плохо подходит для таких приложений.
А если оператор захочет вчерашний заказ открыть? Вы всю таблицу с заказами на клиент вытаскиваете? Судя по контексту второй фразы, еще и с промежуточными таблицами. Вместо i3 требуем оперативную память.
Ага, специально взяли себе проблему и героически ее решаем.
Это все в виде ассоциативных массивов, без всякой типизации?
Даа, изменили системные компоненты? То есть у стороннего программиста, скачавшего установщик с сайта, оно в принципе не заработает?
Whuthering
Хорошие вопросы. Интересно было бы послушать ответы (а не «читайте статью, там все написано», когда на самом деле ничего не написано). Про i3 для JS тоже повеселило, кстати.
Whuthering
Может это у автора специально задумка такая была — написать на почти загнувшемся некоторое время назад и уже нераспространенном языке, навернуть своих костылей, запутать код — чтобы к нему потом всю жизню за поддержкой обращались и платили?) Жаль только, не прокатило… :)
Areso
Многие накинулись на автора, мол, непопулярный язык, странное решение (xml для описания форм), и т.д., но вот вопрос: а было ли в первоначальной постановке задачи хоть что-то про желаемый заказчиком набор технологий?
И даже если был бы описан язык (к примеру, PHP+JS), то это никак бы не уберегло от непопулярных фреймворков, старых релизов (или наоборот, слишком новых, которые бы поддерживались 10% клиентских устройств), и вот таких вариантов с самописными (или не совсем) xml-template разметками.
vism
Это уже вопрос профессионализма автора и клиента. Клиент решил не делать свой отдел для разработки, а взять одного удаленного человека.
Теперь он знает, что это путь в никуда.
Areso
Клиент без опыта (вроде очевидно), взял человека, предположительно, без опыта разработки больших систем напрямую конечному заказчику = результат немного предсказуем.
Дело не в формате работы, имхо. Дело в качестве начальной проработки требований к ИС (как функциональных, так и общих).
Т.е. с тезисом про профессионализм согласен, с тезисом про формат удаленщика-фрилансера — не согласен.
vism
Я скорее про формат одного человека хотел сделать акцент.
Нельзя быть уверенным в одном человеке, лучше всегда иметь 2-х программистов, больше вероятность успеха)
Areso
И бюджет на двух программистов. Если это не вчерашние студенты или не демпингующие специалисты из Горно-Алтайска (любой другой Тьмутаракани по-вашему вкусу), то это недешевое удовольствие.
Areso
Когда я выступал заказчиком на биржах, и сроки горели, я обычно заказывал реализацию у двух разных независимых фрилансеров. Обычно получалось. Но бюджет приходилось резервировать на 2х, ну, а оплата от 1Х до 2Х. Но объем работы был меньше.
michael_vostrikov
Суть не столько в языке, сколько в том, что автор не понимает, почему заказчик просил его переписать. Ну и да, при создании системы надо думать о поддержке ее другими программистами.
akadone Автор
Заказчик от этого как раз котел уйти. Ставить на каждое место оператора i3 из-за того, что там JS — это бред.
F0iL
Грамотно написанное SPA на JS с интерфейсом без свистелок и перделок может реактивно летать в браузере даже на 600-мегагерцовом ARM'е с полугигом памяти. Поэтому бред это скорее «i3 нужен для JS» :) А говнокода с кривой архитектурой можно хоть на Delphi, хоть на C++, хоть на чем угодно навернуть.
akadone Автор
Возможно наверно. Но я ни разу такого не видел. Большинство интернет магазинов еле ворочаются у меня на i5. И там сидят хорошие программисты, а фильтр по товарам — это как-бы гораздо проще, чем отображение всего того, что нужно оператору в ERP системе.
michael_vostrikov
Большинство интернет-магазинов — это не SPA. В большинстве интернет-магазинов дизайн сложнее, чем у вас. А размер базы у них не позволяет загрузить ее полностью на клиент.
И нет, фильтр в интернет-магазине (фасетный поиск) это не так просто, как вам кажется.
Areso
Согласитесь, что фильтр и фасетный поиск — это не одно и то же). И далеко не каждый интернет-магазин может похвастать фасетным поиском. А вот простой фильтр вполне себе прозаичен
SELECT * FROM smartphones WHERE cores >= 4 AND release_date >= 2016 AND RAM >= 2048
Ну и вернуть это обратно.
michael_vostrikov
Вот сложность начинается в том, чтобы определить какие есть варианты кроме 2048, и что вместо этого будет для refrigerators. Фиксированный список опций в магазине на 1 товар это конечно несложно. Но автор же имеет в виду большие и медленные.
Areso
Соглашусь, но позволю себе заметить, что говнокод на Delphi/C++ будет быстрее оного на PHP/JS (надеюсь, вы не станете с этим спорить, а если все же захочется — добро пожаловать в Performance-Test в моем ГХ). Во-вторых, большинство современных программистов навешивают такое количество overhead'a на собственно нужный код, что это потом ворочается еле-еле.
Поверьте мне, я знаю, о чем говорю — у меня третий компьютер — Raspberry Pi 3, и на нем пользоваться сайтами (большинством) настоящая боль. Недавно была нужда сделать заказ через интернет в МедиаМаркт. Я на неслабом устройстве (4ядра по 1600МГц, 2 ГБ ОЗУ) измучался, пока разместил заказ. Проклинал их программистов самыми разными проклятиями))
Areso
имеется в виду смартфон.
michael_vostrikov
Это не требования JS, это требования той ERP. JS работал в браузерах когда никакого i3 в помине не было. Как напишете, такая и будет скорость.
F0iL
Вот и я о том же. Сделать ajax-запрос, отрендерить MVC-форму с данными и кнопочками, заполнить табличку, нарисовать меню — браузеры/js с подобным отлично справлялись еще 10 лет назад, если не больше, когда никаких i3 с гигами памяти даже в проекте не было :)
Areso
Справлялись, да. А теперь не справляются. У меня был нетбук с первым поколением Intel Atom N270 (1 физическое ядро 1.6GHz, 2 потока благодаря HT), 1 ГБ DDR2 RAM. В 2008 на нем можно было играть в игры, ходить в Интернет, запускать студию и т.п.
Прошло почти 10 лет, старые игры на нем вполне работают (как и старая студия), а вот в Интернет на нем лучше не ходить. Совсем.
F0iL
Тут проблема не в браузерах и не в JS, а в разработчиках, дизайнерах, и, не побоюсь это сказать, в пользователях.
Достаточно просто сравнить, насколько разбухли сами страницы сайтов со всеми их ресурсами за эти 10 лет — в наше время повсеместным и нормальным считаются тонны HiRes графики, визуальных эффектов, сложных стилей, и т.д., и при этом никакой оптимизации. Раньше на страницу размером в мегабайт недовольно ворчали
(а еще раньше никто бы не дождался даже ее загрузки), сейчас уже можно встретить 10-20-30 мегабайтные морды, даже больше.
В качестве контрпримера можно привести «мобильные версии» сайтов (те, что действительно мобильные версии, а не адаптивная верстка «больших» страниц) — все быстро, компактно и без излишеств.
Проблема в том, что мало кто тестирует свой продукт на железе N-летней давности, и мало кто вообще ориентируется на подобное. Если бы разработчикам и QA принудительно выдавали low-end железо с 2G в качестве канала связи — все бы работало ооооочень по-другому. А если вы сам разработчик, и осознаете проблему — то все в ваших руках.
Areso
Ну, у меня есть пет-проект, где я, по крайней мере, стараюсь.
В том числе делаю тесты на слабых устройствах.
Вот, после очередного набора оптимизаций:
290KB transfered, Finish 1.96 s, DOMContentLoaded 483 ms
И там есть куда двигаться дальше.
"http://cosmodream.ga/js-html-mycity/
is faster than the top-performing sites in the Games industry"
FyvaOldj
Бредом это является только если ваша система планировалась бы для экономии железа на 100 точках.
Для 5 точек дешевле не то что i3, а даже и i7 — по сравнению со стоимостью разработки описываемой системы
maxzh83
Думал, это осталось в прошлом: теплый ламповый Delphi; все эти прекрасные ":=", «TЧтоТо»; работа без тз, азарт, с которым бросаешься на задачу, не понимая масштабов трагедии и т.д. Спасибо за статью, почти как «Дискотека 90х».
VolCh
Не останется это в прошлом ещё долго, если не привязываться конкретно к Delphi.
maxzh83
Я не против, пусть живет. Просто нигде этого не видел давно (по работе, статьи и т.д.), вот и показалось. Когда-то давно писал на Delphi, вот и понастальгировал
brrr
Не знаю, за что минусанули вас, но я тоже подумал о прежних временах "автоматизации" :)
И вспонимается модель зрелости процессов разработки ПО.
Уровень 1. Начальный. Производственный процесс характеризуется как создаваемый каждый раз под конкретный проект, а иногда даже как хаотический. Определены лишь некоторые процессы и успех проекта зависит от усилий индивидуумов.
F0iL
в Delphi нет enum, или я что-то не понимаю в этом мире?)
bgBrother
Есть.
F0iL
Это был сарказм, видимо, не очень удачный :)
akadone Автор
Это не дельфи текст, а текст из скрипта. Перенести туда все enum и прочие кнстанты я пока не успел.
F0iL
То есть для скриптования у вас используется не PascalScript, умеющий enum и константы, а что-то свое?
Или же вы сначала пишете код «абы как», а потом перепиливаете?
Кажется, я начинаю понимать реакцию заказчика…
akadone Автор
PascalScript не работает под android. Точнее я не смог его заставить собраться без больших правок. Поэтому использую легковесный Pascalc. Там можно почти тоже самое.
Кстати если разбирать конкретно этот момент — эти константы задаются в базе. Поэтому их надо тянуть не через enum, я через Table.RowName что немного сложнее. Поэтому первоначальные скрипты писались используя просто константы.
А по поводу реакции заказчика — единственное его членораздельное замечание — почему приложение на андроиде запускается целых 4(!) секунды. Работает без лагов и прочих проблем, но запускается 4(!) секунды. В общем истиной причины разрыва я, к сожалению, не знаю.
vkus
Интересно, я один такой, кто сумел на скриншоте увидеть телефон Дарьи?
Надеюсь, что это фейковые данные.
А теперь по существу статьи: по сути и обсуждать нечего — автор перешел в своих изысканиях на второй уровень (создание скриптового языка на компилируемом + «нескучные» формы), опробовал это на бедолаге-заказчике, попутно окрестив свое творение ERP, и сейчас пытается найти хоть какое-то применение всему этому.
Могло бы быть интереснее, если бы:
goncharenko_d
ERP — это и склад с его логистикой, и учет главного ресурса всех предприятий — персонала, и учет продаж закупок, по возможности, еще и учет производства, увязывание этого всего с бухгалтерским учетом с его планами счетов и отчетностью.
Вы вначале упомянули «так как не было контроля за кухней и доставщиками» и описали учет заказов и доставки. А как же кухня? И где же ведется объединенный учет всего этого?
akadone Автор
Склад с логистикой нужен далеко не везде. В данном случае нужен учёт, что такой-то продукт заканчивается. Не более. Это настолько простая задача, что я её даже упоминать не стал. Естественно должно быть подробное описание как готовить такой-то сет или салат, так как текучку кадров ни кто не отменял, должны быть фото упакованных заказов, что бы если что не так, сразу понимать кто накосячил: кухня, упаковка или доставка. Это всё есть.
Про кухню и упаковку — это отдельные модули, которые как раз внедрялись, когда произошло расстование с заказчиком.
А ERP система это прежде всего контроль за персоналом. А потом сведение это всё в отчёты и анализ эффективности каждого объекта отчёта. Будь то сотрудники подразделения, и в целом доставка, или в целом филиал. Ну, например, когда на одном запарка и опоздания, а на другом в это время всего 3 заказа.
Вот для этого и была создана моя система.
VolCh
Не согласен. Есть бизнесы, где персонала раз-два и обчёлся, причём этот персонал в основной деятельности на задействован, всё полностью автоматизировано.
akadone Автор
Согласен, но я про контекст задачи. Т.е. ресторанный бизнес. Тут в основном косячит персонал. Реже проблема с закончившимися продуктами и пр. Здесь нужна автоматизация только по распределению заказов по точкам и составлению рейсов курьерам. Всё остальное — это контроль в текущем времени — решение проблем с опозданиями и недовольными клиентами которым привезли не то или не вкусное.
PravdorubMSK
Ничего страннее, чем писать/дописывать ERP нет на свете. Куча внутренних наркоманов-заказчиков, которые сами не знают чего хотят, полный бардак в коде и текучка разработчиков.
FyvaOldj
И совершенно непонятно почему не была выбрана придуманная как раз для решения именно таких задач 1С Предприятие.
Даже реализация с нуля на этой платформе позволила бы не тратить 90% времени на решения вопросов общего характера (связи форм с данными и пр. и т.п) а сразу же перейти непосредственно к программированию непосредственно нужных бизнесу задачам.
Причем тут непонятны и позиции заказчика и позиции исполнителя. Наверное денег лишних много...
Если лет 10 назад еще был смысл писать своеобразного дублера 1С Предприятия то сейчас это целесообразно только для очень узко заточенных решений
VolCh
Позиция исполнителя вполне понятна: 1С Предприятие не знает, не хочет с ним разбираться и(или) использовать. Или просто оценивает работу с 1С как менее выгодную по разным причинам.
У заказчиков бывает, что предпочитают подобные решения по двум причинам (или их комбинации): считают, что в конечном счёте своя система будет дешевле и(или) более адаптированная под их нужды. Или просто не знают об альтернативах, есть знакомый разработчик, опимали задачу, он назвал приемлемую для заказчика цену и тот соглашается. Возможно даже поинтересовавшись стоимостью подобных разработок в каких-то фирмах, которые при одинаковой оценке трудозатрат разработчика называют сумму раза в два большую, по понятным причинам.
Areso
Далеко не каждый сумеет подружить мобильные устройства (очевидно, что заказчиком требовались [почти] нативные приложения) и 1С: Предприятие. Там своё, особенное кунг-фу. А если не использовать последние достижения науки и техники, я хотел сказать, платформы 1С: Предприятия, то мы еще упремся в какие-нибудь сторонние решения типа Агент Плюс (со своим же скриптовым языком, и отдельными лицензиями на каждое клиентское устройство). И да, там тоже надо быть парнем не промах.
FyvaOldj
Стоимость лицензий Агент+ по сравнению со стоимостью самописа очень даже невелика.
Dementor
Нет там никакого кунг-фу. Был по обе стороны барикад (и как android-разработчик и как 1С-разработчик) еще до изобретения в платформе «1С: Предприятие 8» такой простой и приятной штуки как HTTP-сервисы, но и тогда не было особых причин для жалоб. Сейчас несложно организовать обмен с 1С по обычным HTTP-запросам (get, post, put, delete и всеми прочими), даже формат данных можно задавать самостоятельно — XML, JSON или что-то свое (но парсинг на стороне 1С придется делать самостоятельно).
Что вы хотели этим сказать? Что «работу» нужно «работать»? Так нам же за это деньги платят! :)
В Агент Плюсе 1.5 применяется простой и всем известный Lua, а в двоечке действительно решили все сделать максимально как в 1С и выпустили конфигуратор, где можно точно так же как в 1С создавать новые объекты, описывать их интерфейс и писать код на 1С-подобном языке L9 (детальнее).
zhavoronok
Вся проблема в вашей статье — это заголовок и текст, читатель вашей статьи должен быть менеджером и программистом, отсюда этот формализм в комментах и скомканость в понимании статьи. Если вы затолкали это в раздел «Управление», то зачем здесь про весь этот код, скрипты, базы. Если вы сделали крутую систему, которая разворачивает всё производство начиная от планов, позволяет при этом отбалансировать мощности, рассчитать закупку, учесть сбыт и т.д., при этом смогли все это внедрить, то это круто. И вот об этом и надо было написать. Насколько реально повысилась эффективность (просрочки стало меньше, уменьшилось ли время доставки, готовки и т.д.), насколько выросла прибыль? А если хотели про фишки разработки и про новую студию рассказать, так и надо было отдельно в разработку писать.
Обычно в таких ситуациях хуже другое, то, что сразу не видно — сопровождение и доработка. Почему все покупают обычно уже известные и готовые системы, потому что там во-первых, есть реальный кейс, как из этого получить прибыль, во-вторых — там есть лучшие практики логики, архитектуры, технологий, которые позволяют через год, два, пять не оказаться у разбитого корыта, когда очередной разработчик-одиночка потеряет энтузиазм под нагрузкой растущего бизнеса и устанет/задолбается реализовывать хотелки. При отсутствии документации, влезать в такие дебри никто не захочет. А разработка документации — это отдельный бюджет.
Ваш клиент пошел на большой риск, и ему 10 раз надо подумать, как этот риск окупить. Я не говорю, что он поступил плохо, если все риски просчитаны и эффект сопоставим, то вопросов нет.
alexey_public
Хм… Оказался в такой же ситуации в этом году и тоже Delphi :-) Может тенденция :-))
Был на фрилансере простой заказ на CRM для предприятия, проводящего освидетельствования водителей и автотранспорта с горящими сроками. Я решил на него отозваться, т.к. заказчик был территориально рядом (обычно заказчики в Москве и не хотят работать с теми, кто не может подъехать в офис и там пообщаться, было такое много раз, после чего я перестал реагировать на такие заказы).
У меня есть готовая и отработанная платформа для ERP под win32 без веб-морды. Т.к. отработала более 10 лет, то быстрая реализация на ней всех требований по учету проверяемого автотранспорта, водителей, предприятий, всех сопроводительных документов и документов на автотранспорт и водителей заняла буквально 3-4 дня с базовой доводкой интерфейса, БД на бесплатной версии SQL Server, справочники, основной интерфейс учета, отчеты по проделанной работе. И это по нескольким от руки нарисованным листочкам заказчика, который сам не знал чего хотел, но срочно и сейчас.
Ладно, принес, начинаю показывать и тихо прихожу в ужас, заказчик мыслит на уровне блокнота, но хочет много всего и не понимает как этим пользоваться. У него начинается расхождение хотелок и необходимости понять тот достаточно простой интерфейс (таблицы и формы редактирования их содержимого с простым и понятным набором полей). Дал структуру взаимосвязей таблиц, благо база небольшая и было все достаточно прозрачно по назначению, вот тут водители, они относятся к предприятиям и они необходимы, чтобы выпустить в рейс машину, на которой они уедут после освидетельствования.
Да — структура базы в отличие от кода сразу была привязана к задачам предприятия, но это всего лишь CRM и специализированная для конкретного случая. К тому же упрощает работу по обслуживанию, мало ли что. А так все данные хорошо просматриваются.
Но ладно думаю, как-нибудь пройдет, деньги очень небольшие, мне было интересно просто сделать что-то такое. Пусть думаю поработают, система запросто может переварить под сотню рабочих мест и миллионы строк записей в реалтайме на обычных ксеонах без каких-то усилий.
Одним словом движок гораздо мощнее, чем им потребуется в обозримом будущем, а как вырастут — можно будет легко добавить любой разумный функционал.
И вот через пару дней они меня просят приехать и обговорить то что они увидели в том что я сделал, а заодно я подкрутил некоторые места по интерфейсу, постаравшись реализовать его на максимально доступном понимаю уровне.
И вот я приехал и началось — собрались абсолютно непричастные и раздались вопли — а вот хотим интерфейс как в банке! И чтобы вот тут и вот тут и вот эдак. При этом начинаем разбираться — и выясняется что они и работу в форме таблиц не понимают и взаимосвязей между сущностями, с которыми работают, до конца не уяснили.
И при этом — они нажимают на то что им срочно, они открылись, только что открылись, к ним сейчас прибежит сотня клиентов и вот сейчас надо уже всех учитывать. Тихонько интересуюсь, а сколько работаем уже — два дня, а сколько клиентов пришлось учесть при помощи ручки и бумажки, ни одного, еще ни одного клиента у них не было :-)
В общем после всех этих воплей уехал и начал задумываться, а надо ли оно мне, потраченного времени было уже в три раза больше, чем мне обещали заплатить. Но хотелось увидеть свой продукт в работе. И я продолжил, но уже без энтузиазма, понимая что их ждут проблемы. Ага, через пару дней позвонили и поинтересовались когда, хотя сроки в общем-то были оговорены(из-за всех выходных на пару дней больше). И вот тогда мне невзначай сообщили — мол уже ищут другого. Это было последней каплей. Обычно с клиентами я веду себя вежливо и никого никуда не послал. Просто моментально отказался от дальнейшей работы. Пусть теперь развлекаются со студентами (никто больше на эту сумму не согласится) и оплатой вызовов специалистов (своего админа и сервера у них не было). Что их ждет догадаться несложно.
А вот основное внедрение и поддержка моей первой версии ERP было гораздо более интересным, там действительно было активно работающее предприятие — рекламное агентство с большим (более 500 страниц) оффлайновым журналом, с жесткими требованиями к реалтайму по всем данным, отчетам и прочему. Фиксации каждой мелочи, поддержка работы нескольких предприятий (они в процессе разделились на два отдельных со своими коллективами, но база общая на едином сервере, т.к. владелец общий), работы с клиентами и основной самый сложный функционал — это верстка этого самого журнала, сначала реалтайм, чтобы каждый мог увидеть текст и графику наполнения по всем полосам, и видеть что и куда ставить — в ERP, причем вид каждой страницы в интерфейсе ERP был полностью до каждого поля идентичен журналу, вплоть до шрифтов и их размеров, пришлось долго изучать все их параметры и автоматизировать работу с ними.
А потом полностью автоматизированная верстка с учетом множества требований, вплоть до совмещения баннеров по заполнению (светлые или темные стороны баннеров вместе, причем учет и по вертикали и по горизонтали), с учетом их размеров, форматов заполнения, проданных местах в каждой полосе (сверху, снизу, в начале полосы, справа от развертки и т.д. и т.п.) и выгрузкой в Indesign где его уже выверяли и отправляли в печать. Было приятно — то что ранее делал целый отдел за день (еженедельно) а то и более перед выставкой, теперь занимало не более полчаса-часа у одного специалиста.
Проработало много лет и активно дорабатывалось на ходу. А потом оффлайн умер, а онлайн уже не требовал такой сложной верстки и там все было сделано иначе и уже не мной.
Но я не сдаюсь и работаю над следующей версией ERP :-) Вебморду обещаю прикрутить :-)