metaclass | В Советской Белоруссии SQL разжигает айседа

В Советской Белоруссии SQL разжигает айседа

http://theiced.livejournal.com/238346.html
Собственно, про кобол я не знаю, на дельфи пишу уже 15 лет и никак избавится от него не могу (слишком много легаси кода), а вот про SQL я с ним не согласен.
Сам по себе SQL очень хорошо подходит для генерации отчетов. Если отчет сводится к фильтрации-сортировке-группировке множеств - идеально. С рекурсивными CTE - еще и деревья можно обрабатывать, не особо включая мозг. Всунув поверх этого минимальных размеров постобработку на какой-нибудь функциональщине, можно сделать почти любой отчет, пришедший в голову свихнувшимся на Excel выпускникам нархоза, работающим в минстате, минфине и МНС.

Но когда доходит до процедурных расширений, API между СУБД и клиентскими приложениями или каких-нибудь вещей, которые забыли вовремя добавить в стандарт - начинается полная, немыслимая жопа.
Например, проклятая тема - генерация автоинкрементных ключей и возвращение значений автоматически заполненных полей. Кто во что горазд - identity, генераторы, sequence, функции (в каждой СУБД названные по разному), returning, заебы на тему "вызывать в той же транзакции и сессии" и прочая и прочая. Про вариации на тему "вернуть поле, которое заполняется автоматически, но не является ключом/identity" лучше даже не думать.
Неудивительно, что люди при первой же возможности сбегают в ORM (которые являются уже второй производной от всего этого маразма и несут на себе его неизгладимый след).

Flat | Top-Level Comments Only

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

Вы в курсе что такое фактор автобуса? Вот тут он наблюдается в полный рост.

Знаете, у торгового дома проблемой является не софт, а поставщики, покупатели и логистика. Кобол здесь как был необходим и достаточен 30 лет назад, так и сейчас подходит.

Знаете обычно говорят, что про сантехников вспоминают когда начинает пахнуть, в IT ровно точно так же. Про него вспомнят когда сломается. И при использовании старых технологий можно получить адовые убытки. За счет того что придется очень долго искать спецов по технологии и они захотят много денег. Вы не читали вот этот прекрасный образчик http://hrazvedka.ru/guru/obratnyj-promyshlennyj-shpionazh-i-industrialnaya-arxeologiya.html
И это замечу вообще инженерия а не IT.

хоть на цитаты растаскивай же

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

Это у вас проектировщики вечно при заводе, а не у меня. Я вообще-то говорю, что фактора автобуса быть не должно.

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

Программные средства это инструмент. Причем у многих компаний основной инструмент и сами по себе они не панацея. Но если они ломаются, то начинаются большие проблемы. Вплоть до потерь денежных средств.
Вот вам пример http://oldmann.livejournal.com/225657.html

Если вы все еще не поняли, давайте я вам задам пару вопросов по вашему ПО:

1. Используется ли у вас последняя версия Delphi?
2. Планируется ли переход на Lazarius?
3. Есть ли система контроля версии?
4. Есть ли хоть какая-то документация по тому как это работает.
5. Есть ли описание как поставить среду с нуля для сборки проекта.
6. Проверялась ли сборка проекта после установки среды с нуля.
7. Есть ли у вас установочный пакет
8. Возможна ли автоматизированная сборка?

>> Это у вас проектировщики вечно при заводе, а не у меня. Я вообще-то говорю, что фактора автобуса быть не должно.

Фактор автобуса существует всегда.
Чем проще инструмент - тем надежнее.
Вам почему-то кажется что есть один правильный метод написания а все остальные неправильные и ущербные.

>> Если вы все еще не поняли, давайте я вам задам пару вопросов по вашему ПО:

>> 1. Используется ли у вас последняя версия Delphi?

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

>> 2. Планируется ли переход на Lazarius?

Нет, потому что нет смысла. Для работы на линухе я отказался от некоторых заточек на сугубо виндовые реализации и программа прекрасно работает под вайном. Но это очень мало восстребовано.

>> 3. Есть ли система контроля версии?

Есть.

>> 4. Есть ли хоть какая-то документация по тому как это работает.

Хоть какая-то - есть, но документацией это назвать сложно.

>> 5. Есть ли описание как поставить среду с нуля для сборки проекта.

Есть. но писалась много лет назад, возможно сейчас по той последовательности не все пройдет гладко.

>> 6. Проверялась ли сборка проекта после установки среды с нуля.

Чем мне нравится Delphi - компиляция происходит крайне быстро, поэтому перекомпиляция проекта у меня происходит чаще чем даже сохранение. Бывает недописал команду, пошел вверх что-то посмотреть, а потом бывает проще запустить компиляцию и ткнуть в выданную ошибку и по ней перейти вместо того что бы идти на то место руками. Так что перекомпиляция применяется везде и всегда, тем более после переустановки.

>> 7. Есть ли у вас установочный пакет

Нет. Он не нужен. Программа являет собой один exe и один ini с параметрами коннекта. Бросаем в любое место и запускаем.
Для инсталляции клиенской части Firebird можно юзать инсталлятор от Firebird но я его тоже не юзаю, мне проще скопировать папку с сервером и запустить там батник из 5 строк который пропишет все куда надо, без лишних глупых вопросов.

>> 8. Возможна ли автоматизированная сборка?

Сделать можно, но не требуется.

Фактор автобуса существует всегда.
Чем проще инструмент - тем надежнее.
Вам почему-то кажется что есть один правильный метод написания а все остальные неправильные и ущербные.

Да мне кажется ущербным использование практически мертвой технологии причем находящейся не в
opensource в 2013 году. И стоит его минимизировать.

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

Знаете когда появятся причины будет поздно. Причины будут вида ой у нас больше эта версия под новой виндой не работает. А при попытках перехода выяснится что тех версий где это могло бы работать просто нигде нет.

Нет, потому что нет смысла. Для работы на линухе я отказался от некоторых заточек на сугубо виндовые реализации и программа прекрасно работает под вайном. Но это очень мало восстребовано.

Смысл как раз есть. В отличии от Delphi этот проект является opensource. И от воли компании закрыть среду не зависит.

Есть.

И то хлеб.

Хоть какая-то - есть, но документацией это назвать сложно.
Есть. но писалась много лет назад, возможно сейчас по той последовательности не все пройдет гладко.

Понятно.

Чем мне нравится Delphi - компиляция происходит крайне быстро, поэтому перекомпиляция проекта у меня происходит чаще чем даже сохранение. Бывает недописал команду, пошел вверх что-то посмотреть, а потом бывает проще запустить компиляцию и ткнуть в выданную ошибку и по ней перейти вместо того что бы идти на то место руками. Так что перекомпиляция применяется везде и всегда, тем более после переустановки.

Это не ответ. Значит считаем что нет.

По факту же мы имеем ПО которое после того как разработчик перестанет его поддерживать придется выкинуть как бы оно красиво не ложилось на бизнес-процессы.

>> Да мне кажется ущербным использование практически мертвой технологии причем находящейся не в
>> opensource в 2013 году. И стоит его минимизировать.

Дрочка на opensource не нужна. Я не собираюсь разбираться с косяками того же лазаруса.
Delphi в текущем виде устраивает, на полочке лежит купленный диск с Delphi Express на который перейти не нашел повода, а интерфейс там заметно поменялся что и отпугнуло от немотивированного перехода.
Так же имеются в продаже Delphi XE3 включающий в себе кроме собственно XE3 так же и XE2, XE, 2010, 2009, 2007 и 7.
Слухи о гибели Delphi высосаны из пальца.
А вот перспективы лазаруса крайне туманны.

>> Это не ответ. Значит считаем что нет.

Есть, в любой момент без каких-либо препятствий.

>> По факту же мы имеем ПО которое после того как разработчик перестанет его поддерживать придется выкинуть

Не увидел каким образом это утверждение согласуется с реальностью.

Дрочка на opensource не нужна. Я не собираюсь разбираться с косяками того же лазаруса.

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

Слухи о гибели Delphi высосаны из пальца.

Панк не умер, он просто плохо пахнет (с)
Вы сейчас можете найти современную программу на Delphi? Я вот такой не припомню ни одной. Delphi давно не mainstream. Сейчас под windows все пишут на .NET.

Есть, в любой момент без каких-либо препятствий.

Возьмите windows 7 причем 64 битную и проверьте как это все там собирается.

Не увидел каким образом это утверждение согласуется с реальностью.

Мы имеем код написанного в среде разработки которой в этом году уже 11 лет. Этот код довольно велик, не документирован, не имеет четкой архитектуры. Разработчиков под него уже сейчас надо искать с факелами. Перенос на новую Delphi займет довольно много времени и сил. Использует РСУБД той же давности. И никаких действий по приведению ее к современному состоянию как-то не прикладывается.

>> Дрочка на opensource не нужна. Я не собираюсь разбираться с косяками того же лазаруса.

>> Ну-ну. Я так понимаю о рисках использования закрытого ПО в длительной перспективе вы ничего не знаете и не читали.

С опенсорсем риски тоже есть, они другие но их не меньше.
Как показывает жизнь Борланд и Эмбаркадеро достаточно надежные компании что бы не бояться использовать их продукт.

>> Вы сейчас можете найти современную программу на Delphi? Я вот такой не припомню ни одной.

TheBat, SPlan. Куча корпоративного софта и софта государственных контор.
Более плотно вопрос не изучал.

>> Delphi давно не mainstream. Сейчас под windows все пишут на .NET.

Последние версии Delphi, если не ошибаюсь, тоже поддерживают .NET.

Дрочка на mainstream не нужна. Он слишком часто меняет свое направление.
Перепись программы на .NET только потому что "Сейчас под windows все пишут на .NET." - верх идиотизма.

>> Возьмите windows 7 причем 64 битную и проверьте как это все там собирается.

У меня ее нет. Если не будет собираться или работать - это не конец цвета. У нас бизнес а не шашечки. Если не пойдет под 64 - можно просто не использовать 64. Дрочка неа 64 не нужна. Но думаю что все будет работать без проблем.

Хотя вспомнил, ставили мы сервер и клиента на бук с семеркой 64. Работало.
Delphi - не ставил.

>> Мы имеем код написанного в среде разработки которой в этом году уже 11 лет.
>> Этот код довольно велик, не документирован, не имеет четкой архитектуры.

141 форма, общим размером DFM 1.3мб
146 юнитов общим размером паскалевского кода около 2мб
и некоторое количество своих и сторонник библиотек используемых не только в этом проекте.

Библиотеки без исходного кода принципиально не используются.

База:
- 64 таблицы
- 108 процедур
- 107 триггеров
- 85 генераторов
- 28 исключений
- 179 индексов

Скрипт создания базы - 368кб

Итого на 141 форму суммарно 2,5мб исходного кода.
На одну соответственно 17кб в среднем.
А сколько, в среднем у вас кода на одну форму? На экономном ОРМ?

>> Разработчиков под него уже сейчас надо искать с факелами.

80% тех кто работает с Firebird - пишут на Delphi.
Гнездо Firebird известно :)
Так что проблема поиска с факелами - в бОльшей степени надумана.
То что на Delphi мало пишет молодняк - это даже плюс, люди с опытом :)

>> Перенос на новую Delphi займет довольно много времени и сил.

Перенос на что бы то ни было займет много времени и сил. Но перенос ради переноса - не нужен.

>> Использует РСУБД той же давности.

Это вы выдумываете. Используется последний зарелизенный Firebird 2.5.1.

>> И никаких действий по приведению ее к современному состоянию как-то не прикладывается.

Если вы про переписывание на язык по писку последней моды - то да, не делается. А рефакторинг потихоньку происходит практически при залазе в исходники, с целью повышения стройности кода и архитектуры.

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject