Плакать tr ,eltv

andrewk
Есть нифига не маленькая прога, изначально писанная на FPD, которая 20 лет вполне успешно работает во многих конторах, в том числе в активно-сетевом режиме.

Для меня всегда было загадкой - если прога успешно работает, то зачем ее "куда-то переводить"?

Конечно, техника развивается, и приходится под нее "подстраиваться", потому как и производителям харда, и производителям софта "нет решительно никакого дела" до успешно работающей в течение 20 лет проги. Более того, такая прога для них является эдаким "бельмом в глазу", мешающим выкачивать бабло из незадачливых потребителей IT-индустрии. Вот потому написанный на новых программых средствах исполняемый модуль, выводящий на дисплей фразу "Hello, World!" (к этому и сводится весь его функционал), занимает около 10 мегабайт.

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

Э, нет. Это аргументация для Курилки. Здесь такая не катит.

Ну так и критика "перевода" без аргументации того же фасона
"Просто так" крайне редко что-либо "переводят". Обычно есть чёткие цели, среди которых:
1) Упрощение/удешевление сопровождения (поскольку найти специалиста на FPD уже так же сложно как и на Cobol-е).
2) Повышение надёжности - файл-сервер совершенно ненадёжная система. Попытки вручную повысить надёжность (все эти переиндексаторы, чинильщики dbf файлов, архиваторы/восстановители) - это достаточно дорого, сложно и всё равно не повышает надёжность даже до уровня бесплатных и несложных "серверных" СУБД.
3) Более привычный и приятный пользователям интерфейс. Можно сколь угодно долго хвалить псевдографический оконный интерфейс FPD (и радоваться своему гениальному преодолению проблемы размещения кучи информации в окне 80*25 символов), но подавляющее большинство нынешних пользователей предпочтут таки Windows-подобный вариант. Это даже если не рассматривать ещё более правильную миграцию в сторону web-решений.
4) Повышение скорости работы. Да, в FPD в принципе можно добиться неплохой скорости - если всё тщательно "вылизывать" и "основательно" подходить к любому моменту обращения с данными. В том же VFP банальные SQL-запросы даже при не самой высокой квалификации разработчика могут дать ускорение на 2 порядка. Да и в других системах при нормальном подходе ни "медленнее" ни "хуже" не будет.
5) Та самая работа на нынешнем железе. Без надобности в эмуляторах и прочих тонкостях. А если это будет веб-решение, при том достаточно грамотное, то и работа по сути без администрирования клиентских рабочих мест, и с использованием и планшетов и тех же телефонов (как для ввода данных - склад, экспедитор, собственно клиенты, так и для оперативного просмотра данных - самый распространённый, хотя и глуповатый, пример с директором возлежащем на пляжУ в Тенерифе, но тем не менее бдительно следящим за тем что на предприятии всё ок, все работают и проблем нет).

Т.е. как таковой "перевод" и даже просто рефакторинг - т.е. переписывание лишь некоторых "кусков" программы не есть зло - зло это некомпетентность работников, и непросчитанность бюджета - когда одни врут о том что за 100р всё сделают, а другие врут о том что могут эти 100р заплатить

Это всё понятно. Таковы нынешние реалии. Но...

IT - индустрия идет по тому же пути, куда идут и все остальные мировые профессиональные артели. "Простое" завещание может занимать 15 страниц - юристы тоже стараются. Куда конь с копытом, туда и рак с клешней. Про медицину даже не буду начинать. Это, так сказать, "общий фон".
И "Hello, World", занимающий около 10 Mб, из этой же серии.

Но оставим лирику.

В любой информационной системе есть разные уровни (кроме вырожденных случаев). Важным является первичный уровень, а именно уровень порождения первичной информации и первичных документов. Доя этого уровня не нужен "Hello, World" весом в 10 Мб. Для этого уровня вполне сгодится простое и надежное программное обеспечение на том же FPD. Проблема не в том, что "не найти специалиста по сопровождению", а в том, что там нечего сопровождать, и там не срубить бабла ни на лицензиях, ни на сервис-паках, ни на "революционных платформах", выжимающих из потребителей последние соки. Вот где реальная проблема.

Подготовленная же на низовом уровне инфа может быть куда угодно интегрирована и встроена. И вот на том уровне уже пусть подключаются промышленные СУБД и облачные сервисы. Богу Богово, а кесарю кесарево.



Исправлено 1 раз(а). Последнее : Simple777, 05.06.18 14:08

Странная позиция, а что на том же VFP нельзя сделать надёжную "вбивалку" данных (первичной информации)?

Думаю, часто вопрос в элементарной целесообразности: "Если мне за это не то, что ни фига не заплатят, но даже спасибы не скажут".
А оно таки и так работает. Ну и пускай себе, как говорится, и дальше продолжает. [attachment 29498 bk.gif]

Crispy
Думаю, часто вопрос в элементарной целесообразности: "Если мне за это не то, что ни фига не заплатят, но даже спасибы не скажут". А оно таки и так работает. Ну и пускай себе, как говорится, и дальше продолжает. [attachment 29498 bk.gif]

Можно понять, когда уже есть такая "вбивалка" и она годами работает и юзеры привыкли и начальство не хочет ничего менять и вкладываться, и всех и всё устраивает. Но если это новый проект "вбивалки", то позиция Симпле777 для меня не понята Для чего упираться в FPD. Конечно если за него платят и заказчик сам пальцем тыкает в FPD и говорит - хочу и заплачу Тогда все желания за ваши деньги





Исправлено 1 раз(а). Последнее : Божья_коровка, 05.06.18 15:00

Simple777
IT - индустрия идет по тому же пути, куда идут и все остальные мировые профессиональные артели.

Жизнь сама по себе усложняется. Что лучше - полностью роботизированный завод, обслуживаемый командой из 2-3 специалистов, обычный завод прошлого века, где работает 5-10тыс персонала "среднего" образования, или 100500 кустарных мастерских, где работнику не требуется практически никаких знаний - даже читать/писать не обязательно При сравнимом выходе готовой продукции (по качеству разговор вообще отдельный)?
Так что тенденция к усложнению производства продиктована далеко не только желанием "поразвешивать лапшу на уши".

Simple777
И "Hello, World", занимающий около 10 Mб, из этой же серии.

Это на FPD со встроенными библиотеками поддержки?
Так то на большинстве современных языков объём этого приложения в чистом виде вряд ли превысит пару Кб. Но это некорректный пример - среднестатистическое приложение гораздо сложнее HelloWorld, и потому доля занимаемая инфраструктурой, кажущаяся "гигантской" для HelloWorld, покажется совершенно несущественной для любого другого приложения. А учитывая что инфраструктура унифицирована для многих приложений - так и подавно.
В общем языки программирования эффективно делающие HelloWorld и нужны исключительно для HelloWorld, а ничего другого они нормально не смогут делать

Simple777
Важным является первичный уровень, а именно уровень порождения первичной информации и первичных документов. Доя этого уровня не нужен "Hello, World" весом в 10 Мб. Для этого уровня вполне сгодится простое и надежное программное обеспечение на том же FPD.

Взять данные по ценам с сервиса магазина, взять курсы валют с сервиса ЦБ, проложить маршрут при помощи гуглмапс и просчитать затраты на бензин согласно этому расстоянию, снять штрихкоды при помощи промышленного сканера (установленного/подключенного вовсе даже не к обычному компьютеру, и уж тем более без драйверов под DOS), "нарисовать" схему склада, чтобы можно было ткнуть на картинку для указания места хранения, нарисовать интерфейс ввода работающий на планшете - всё это ты готов сделать на FPD? Ну, удачи

Simple777
Проблема не в том, что "не найти специалиста по сопровождению", а в том, что там нечего сопровождать

Я не видел ни одного примера приложения на FPD/Clipper которое не требовало бы сопровождения. Да, порой они работают без вмешательства грамотного специалиста (скажем так, поддержка силами эникейщика/админа заказчика) по нескольку лет - но рано или поздно их приходится сопровождать - даже не касаясь вопросов изменения бизнес-требований - просто исправлять ошибки, которые пользователю надоедает "обходить" (да, видел и такое - скажем перед печатью некоторых отчётов закрывали и заново запускали прогу - "а мы уже привыкли").
И да, разницы по сравнению с ПО написанном на любом другом языке в этом плане нет абсолютно. Что написано хорошо - довольно долго может работать без вмешательства специалиста. Что написано "как обычно" - так и на FPD будет требовать ежедневного "придерживания пальцем". Никакой магии.

Simple777
Подготовленная же на низовом уровне инфа может быть куда угодно интегрирована и встроена. И вот на том уровне уже пусть подключаются промышленные СУБД и облачные сервисы.

Проблема в том, что интегрировать такую информацию зачастую не просто сложно, а сверхсложно. Нормализация структуры БД? Вменяемые имена таблиц/полей? Циферки в поле сумма и дата в поле даты, а не вдохновенные тексты "накинуть 5% к сс" или "послезавтра"? Единая БД с общей структурой, а не 100500 dbf (слегка различающихся, т.к. в разные периоды времени создавались, разными версиями гениального ПО) живописно раскиданных по совершенно произвольным папкам?

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

Как аналогия - не покупать машину в сборе, а купить движок у китайцев, кузов у французов, колёса - найти в ближайшей деревне телегу и с неё снять.
А что, колёса круглые и даже катятся, движок рычит и коленвал крутит, корпус ваще отпадный "дизайнЁрский"... А всё вместе - груда бесполезных запчастей

Ни разу не убедительно. Примеры утрированы.

Насчет интеграции - просто смешно лолшто. Типа накупим кучу крутого софта хрен знает за какие бабки, наймет еще более крутых спецов - и всё "само сынтегрируется". Всё настолько круто, что по другому и быть не может. Качество интеграции определяется не крутизной программных средств ни разу. А отсутствие дров и прочего - ну дык "покупайте крутое" - там всё будет работать в новых версиях. Отсутствие разработок дров, провайдеров и т.п. под DOS - это не есть аргумент в том смысле, что это всё могло быть реализовано, но "не интересно". Интереснее бабло тянуть за "новые революционные платформы".



Исправлено 1 раз(а). Последнее : Simple777, 05.06.18 17:35

Не могло. Под однозадачную ОС, управляющуюся с трудом (и во многом через ж...) с 32Мб-ми памяти, 16-битный код... Это именно и будет - собирать Боинг в средневековой кузнице.
Забыл, ой забыл ты что такое "чистый дос", и как весело в нём живётся прикладному софту. Даже с учётом всевозможных "расширителей памяти", TSR, и т.п.

Аргумент тут один - так делать нетехнологично -> ненадёжно и дорого.

Впрочем, в мире вполне себе есть и примеры сравнительно успешной борьбы с прогрессом - те же Амиши Правда они чуть консервативнее тебя - компьютеры напрочь отвергают, не только современные, но и DOS-времён тоже - считать "удои и привесы" вполне себе можно и на бумажке, при свете керосиновой лампы

Быть по сему. [attachment 29501 bg.gif]

Simple777
В любой информационной системе есть разные уровни (кроме вырожденных случаев). Важным является первичный уровень, а именно уровень порождения первичной информации и первичных документов. Доя этого уровня не нужен "Hello, World" весом в 10 Мб. Для этого уровня вполне сгодится простое и надежное программное обеспечение на том же FPD. Проблема не в том, что "не найти специалиста по сопровождению", а в том, что там нечего сопровождать, и там не срубить бабла ни на лицензиях, ни на сервис-паках, ни на "революционных платформах", выжимающих из потребителей последние соки. Вот где реальная проблема.

Рантайм питона можно обрезать и скомпилять для конкретной оси на пару мегабайт плюс sqlite.so - 250kb. "Hello, World" - в байтах измеряется. Надёжный. Работает как на 286-ом, так и на ультрасовременных 64-х разрядных машинах. Интерфейс для консольного приложения можно один-в-один как на FPD сделать (только символов больше чем 80х25). С лицензиями - вообще шикардос. Даже винду не нужно покупать, но можно и под винду сделать, если уже куплена. И спецов по сопровождению - легион.

По приведённым вами же аргументам python+sqlite дёргает FPD в разы.

PS. Кстати. Можно ещё nginx добавить на пару мегабайт и тогда можно полноценную трёхзвенку организовать. А для любителей тёплого и лампового - lynx в качестве клиента.



Исправлено 1 раз(а). Последнее : pasha_usue, 06.06.18 09:15

pasha_usue
По приведённым вами же аргументам python+sqlite дёргает FPD в разы.

Пусть дергает. Однако это не значит, что надо срочно "всё бросать" и работающий на FPD софт забесплатно переделывать под питона или еще какого удава. И еще неизвестно, куда этот удав приползет в будущем. А вот от FPD никаких сюрпризов не будет.

Simple777

pasha_usue
По приведённым вами же аргументам python+sqlite дёргает FPD в разы.

Пусть дергает. Однако это не значит, что надо срочно "всё бросать" и работающий на FPD софт забесплатно переделывать под питона или еще какого удава. И еще неизвестно, куда этот удав приползет в будущем. А вот от FPD никаких сюрпризов не будет.

Просто нет никакой другой аргументации кроме: "Это уже написано, и работает".

pasha_usue
Просто нет никакой другой аргументации кроме: "Это уже написано, и работает".

А мотивация к переделке, видимо, такая: "переделаем, потому что это работает, и пусть нам за это еще заплатят и спасибо скажут".

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



Исправлено 2 раз(а). Последнее : Simple777, 06.06.18 09:28

Simple777

pasha_usue
Просто нет никакой другой аргументации кроме: "Это уже написано, и работает".

А мотивация к переделке, видимо, такая: "переделаем, потому что это работает, и пусть нам за это еще заплатят и спасибо скажут".

Если продукт не востребован, то мотивации к переделке нет.

Simple777
Накрайняк при переходе на новые платформы

Собственно говоря, это и есть постоянный "плач Ярославны" - типа злобные враги выпускают новые платформы, на которых наш замечательный DOS-овский софт не фурычит А ещё и железо выпускают такое, что не всунуть антикварные платформы (если что, Win7 уже тоже завершила свой жизненный путь).
Хотя проблема то надумана. Не цепляйся за антиквариат, и не будет никаких "неудобств".

.NET выпущен в 2002 году, Java - вообще в 1996 году. За 15-20 лет можно раз этак 5 переписать даже очень большую программу.
FPD умер где-то в середине 90-х, VFP в 2007-м.
Есть лишь один "аргумент" за то чтобы продолжать что-то писать на этих системах - лень и нежелание изучать что-либо новое
А проблемы клиентов со старым софтом - это проблемы клиентов, и разработчика они никак не касаются. Жмот он - ну пусть ищет такое же антикварное железо, чтобы запускать антикварный софт. При чём тут разработчик то? А если разработчик сопровождает ПО - т.е. получает за это деньги - ну так пусть переписывает (конечно же всё зависит от объёма финансирования) - это будет никак не "бесплатно за просто так".

Simple777
Для меня всегда было загадкой - если прога успешно работает, то зачем ее "куда-то переводить"?

Ну я имел ввиду не «прога написана 20 лет назад и в том же виде пашет». У меня квартплата и всё, что с этим связано. Законодательство в этой сфере меняется очень часто, иногда кардинально (и очень часто – алогично, непоследовательно, реально театр абсурда). Переписываю что-то постоянно. А такие вещи, как формы паспортного стола, обмен с ГИС ЖКХ, работа с фискальными регистраторами, двумерный штрихкод на платёжках, подгон разного пользовательского текста в платёжках, удобства интерфейса и всякое другое, – реализовать под DOS или невозможно или крайне затруднительно. Недавно вот здесь же обсуждали и успешно сделал авто-получение ключевой ставки ЦБ с их сайта, ну удобно же. Так что «перевод» в данном случае – необходимость.
И да, полностью поддерживаю 5 доводов Игоря выше. К ним ещё можно добавить меняющийся персонал на местах и увеличение числа клиентов, при этом первичное обучение DOS-интерфейсу мягко говоря затруднительно.