![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
В Советской Белоруссии SQL разжигает айседа
http://theiced.livejournal.com/238346.html
Собственно, про кобол я не знаю, на дельфи пишу уже 15 лет и никак избавится от него не могу (слишком много легаси кода), а вот про SQL я с ним не согласен.
Сам по себе SQL очень хорошо подходит для генерации отчетов. Если отчет сводится к фильтрации-сортировке-группировке множеств - идеально. С рекурсивными CTE - еще и деревья можно обрабатывать, не особо включая мозг. Всунув поверх этого минимальных размеров постобработку на какой-нибудь функциональщине, можно сделать почти любой отчет, пришедший в голову свихнувшимся на Excel выпускникам нархоза, работающим в минстате, минфине и МНС.
Но когда доходит до процедурных расширений, API между СУБД и клиентскими приложениями или каких-нибудь вещей, которые забыли вовремя добавить в стандарт - начинается полная, немыслимая жопа.
Например, проклятая тема - генерация автоинкрементных ключей и возвращение значений автоматически заполненных полей. Кто во что горазд - identity, генераторы, sequence, функции (в каждой СУБД названные по разному), returning, заебы на тему "вызывать в той же транзакции и сессии" и прочая и прочая. Про вариации на тему "вернуть поле, которое заполняется автоматически, но не является ключом/identity" лучше даже не думать.
Неудивительно, что люди при первой же возможности сбегают в ORM (которые являются уже второй производной от всего этого маразма и несут на себе его неизгладимый след).
Собственно, про кобол я не знаю, на дельфи пишу уже 15 лет и никак избавится от него не могу (слишком много легаси кода), а вот про SQL я с ним не согласен.
Сам по себе SQL очень хорошо подходит для генерации отчетов. Если отчет сводится к фильтрации-сортировке-группировке множеств - идеально. С рекурсивными CTE - еще и деревья можно обрабатывать, не особо включая мозг. Всунув поверх этого минимальных размеров постобработку на какой-нибудь функциональщине, можно сделать почти любой отчет, пришедший в голову свихнувшимся на Excel выпускникам нархоза, работающим в минстате, минфине и МНС.
Но когда доходит до процедурных расширений, API между СУБД и клиентскими приложениями или каких-нибудь вещей, которые забыли вовремя добавить в стандарт - начинается полная, немыслимая жопа.
Например, проклятая тема - генерация автоинкрементных ключей и возвращение значений автоматически заполненных полей. Кто во что горазд - identity, генераторы, sequence, функции (в каждой СУБД названные по разному), returning, заебы на тему "вызывать в той же транзакции и сессии" и прочая и прочая. Про вариации на тему "вернуть поле, которое заполняется автоматически, но не является ключом/identity" лучше даже не думать.
Неудивительно, что люди при первой же возможности сбегают в ORM (которые являются уже второй производной от всего этого маразма и несут на себе его неизгладимый след).
no subject
Типа давайте поменяем фары с галогена на ксенон, ведь галоген светит лучше. Но забыли обратить внимание что авто с этими галогенными фарами ездит освещаемому складу и ему фары не нужны вообще.
no subject
С какой стати я должен тратить свое время на освоение технологии которая может быть в чем-то удобнее, но требует кучу времени на изучение и переписывание.
Не обязательно переписывать проект, можно сделать другой проект.
Вообще, желание "переписать все заново" нифига не конструктивно. Кроме того у меня проблемы с "быстрее/медленнее" нету. Она не в этом месте.
А я где-то говорил про переписать заново? Просто если вы изучили одну технологию и успокоились, то вы можете оказаться в ситуации тех самых товарищей с Cobol.
Типа давайте поменяем фары с галогена на ксенон, ведь галоген светит лучше. Но забыли обратить внимание что авто с этими галогенными фарами ездит освещаемому складу и ему фары не нужны вообще.
Да не я не против. Чем больше таких людей как вы тем больше ценнее те кто знает более одной технологии и изучает новые.
no subject
Если вдруг он перестанет быть актуальным - у меня есть куча другой работы. Программизм - не единственное мое занятие.
Я в жизни изучил не одну технологию, многие из них уже устарели, например Clipper, FoxPro, Когда-то на фортране писАл, и макроассемблере. Просто сейчас мозг уже не позволяет просто так, из любопытства изучить какую-то новую технологию. Ресурсы ограничены и их становится все меньше.
FoxPro кстати был вполне неплохим инструментом для своего времени, позволял быстро решать задачи. ;) То что я на FoxPro делал за одну ночь между командировками, имея только одну бумажную книжку - справочник и никакого опыта, кроме фортрана и макро, потом на Delphi уже делалось за неделю.
Технологии становятся все сложнее и многочисленнее, каждая заявляется как революция и панацея, но немногие переживают более нескольких лет. Все узнать и изучить невозможно. Да уже тупо и неинтересно.
no subject
У меня всего один большой проект который будет вечно ;)
Если вдруг он перестанет быть актуальным - у меня есть куча другой работы. Программизм - не единственное мое занятие.
Я сочувствую тем кому вы его пишете. Они никогда не узнают что бывает лучше.
Технологии становятся все сложнее и многочисленнее, каждая заявляется как революция и панацея, но немногие переживают более нескольких лет. Все узнать и изучить невозможно. Да уже тупо и неинтересно.
Многие технологии не заявляются как панацея и революция, они просто делают работу проще и удобнее, чтобы вместо написания SQL я мог подумать о бизнес-процессах и о том как сделать приложение удобнее.
no subject
no subject
Я пишу его себе.
В таком случае и разговаривать не о чем. Такие программы как правило не блещут красотой кода и красивой архитектурой.
no subject
no subject
Задача программы - не блистать кодом и красотой архитектуры а выполнять поставленные задачи и быть достаточно понятной для поддержки и развития.
Как раз чтобы она была понятной для поддержки развития у нее должна быть внятная архитектура и понятный код.
Архитектура должна позволять вносить изменения не скатываясь при этом до набора костылей.
Учитывая какой вы показывали код для формы у вас программ как раз набор костылей. Ну не пишут так уже давно. Это приводит к хреновой читаемости кода и размазыванию логики по всей программе ровным слоем.
no subject
Они никогда не узнают, что бывает лучше.
Но, ведь они - жители - сами все это производят и обслуживают. За деньги. Производят говно и потребляют его же. И система находится в относительном равновесии.
Возможно, кто-то первый должен начать делать не-говно не за очень большие деньги, а за свою обычную зарплату. Но, я не вижу причины, по которым первыми(читай - крайними) должны быть именно программисты.
Всякий, кто предлагает другому для решения тех же самых задач, что и раньше, работать намного больше за ту же оплату, должен подумать - в своем ли он уме.
>панацея революция бизнес-процессы буллшит-бинго
Знаете, у торгового дома проблемой является не софт, а поставщики, покупатели и логистика. Кобол здесь как был необходим и достаточен 30 лет назад, так и сейчас подходит.
no subject
no subject
Неужели я неправ?
Какого хера цены на еду, коммуналку, жилье все растут и растут, при этом покупательная способность зарплат программистов уменьшается год за годом, и тут кто-то вылазит и говорит, что "Вы должны работать еще более лучше!". Да с хуя ли? Все страдают хуйней за деньги, а почему я должен работать лучше прочих?
no subject
no subject
no subject
(no subject)
no subject
Всякий, кто предлагает другому для решения тех же самых задач, что и раньше, работать намного больше за ту же оплату, должен подумать - в своем ли он уме.
Вы в курсе что такое фактор автобуса? Вот тут он наблюдается в полный рост.
Знаете, у торгового дома проблемой является не софт, а поставщики, покупатели и логистика. Кобол здесь как был необходим и достаточен 30 лет назад, так и сейчас подходит.
Знаете обычно говорят, что про сантехников вспоминают когда начинает пахнуть, в IT ровно точно так же. Про него вспомнят когда сломается. И при использовании старых технологий можно получить адовые убытки. За счет того что придется очень долго искать спецов по технологии и они захотят много денег. Вы не читали вот этот прекрасный образчик http://hrazvedka.ru/guru/obratnyj-promyshlennyj-shpionazh-i-industrialnaya-arxeologiya.html
И это замечу вообще инженерия а не IT.
no subject
Среди близкой мне книготорговли есть такой пример - была очень крупная книготорговая компания ТОП-Книга, крупнейшая в России. Выросла она в Новосибирске, первейшие наши конкуренты. Были. Ими был занят огромный кусок рынка, владелец - математик по образованию, бизнес строился по лучшим образцам зарубежных книготорговых организаций, куча розничных магазинов в куче городов, оптовая сеть, большой штат, куча программистов, а в академгородке есть из кого выбрать, внедрялись и разрабатывались крутые программные средства.
Грянул кризис - и ТОП сдулся, полностью. Нет больше такой фирмы. Красивые программы не помогли.
no subject
no subject
По ссылке хорошее описание. Там же сказано что мораль неизвестна, и это так и есть. Проектировщики завода и люди поддерживающие налаженный техпроцесс на заводе - это разные люди. В вашем представлении проектировщики должны вечно быть при этом заводе. Но в этом случае не факт что он будет коммерчески успешным.
Это у вас проектировщики вечно при заводе, а не у меня. Я вообще-то говорю, что фактора автобуса быть не должно.
Среди близкой мне книготорговли есть такой пример - была очень крупная книготорговая компания ТОП-Книга, крупнейшая в России. Выросла она в Новосибирске, первейшие наши конкуренты. Были. Ими был занят огромный кусок рынка, владелец - математик по образованию, бизнес строился по лучшим образцам зарубежных книготорговых организаций, куча розничных магазинов в куче городов, оптовая сеть, большой штат, куча программистов, а в академгородке есть из кого выбрать, внедрялись и разрабатывались крутые программные средства.
Программные средства это инструмент. Причем у многих компаний основной инструмент и сами по себе они не панацея. Но если они ломаются, то начинаются большие проблемы. Вплоть до потерь денежных средств.
Вот вам пример http://oldmann.livejournal.com/225657.html
Если вы все еще не поняли, давайте я вам задам пару вопросов по вашему ПО:
1. Используется ли у вас последняя версия Delphi?
2. Планируется ли переход на Lazarius?
3. Есть ли система контроля версии?
4. Есть ли хоть какая-то документация по тому как это работает.
5. Есть ли описание как поставить среду с нуля для сборки проекта.
6. Проверялась ли сборка проекта после установки среды с нуля.
7. Есть ли у вас установочный пакет
8. Возможна ли автоматизированная сборка?
no subject
Фактор автобуса существует всегда.
Чем проще инструмент - тем надежнее.
Вам почему-то кажется что есть один правильный метод написания а все остальные неправильные и ущербные.
>> Если вы все еще не поняли, давайте я вам задам пару вопросов по вашему ПО:
>> 1. Используется ли у вас последняя версия Delphi?
Нет, юзается древнейшая D7. Перехода на более новую не планируется ибо пока нет причин. Будут причины - буду думать. Переходы с версии на версию проходят не гладко и без нужны нет смысла скакать по этим кочкам.
>> 2. Планируется ли переход на Lazarius?
Нет, потому что нет смысла. Для работы на линухе я отказался от некоторых заточек на сугубо виндовые реализации и программа прекрасно работает под вайном. Но это очень мало восстребовано.
>> 3. Есть ли система контроля версии?
Есть.
>> 4. Есть ли хоть какая-то документация по тому как это работает.
Хоть какая-то - есть, но документацией это назвать сложно.
>> 5. Есть ли описание как поставить среду с нуля для сборки проекта.
Есть. но писалась много лет назад, возможно сейчас по той последовательности не все пройдет гладко.
>> 6. Проверялась ли сборка проекта после установки среды с нуля.
Чем мне нравится Delphi - компиляция происходит крайне быстро, поэтому перекомпиляция проекта у меня происходит чаще чем даже сохранение. Бывает недописал команду, пошел вверх что-то посмотреть, а потом бывает проще запустить компиляцию и ткнуть в выданную ошибку и по ней перейти вместо того что бы идти на то место руками. Так что перекомпиляция применяется везде и всегда, тем более после переустановки.
>> 7. Есть ли у вас установочный пакет
Нет. Он не нужен. Программа являет собой один exe и один ini с параметрами коннекта. Бросаем в любое место и запускаем.
Для инсталляции клиенской части Firebird можно юзать инсталлятор от Firebird но я его тоже не юзаю, мне проще скопировать папку с сервером и запустить там батник из 5 строк который пропишет все куда надо, без лишних глупых вопросов.
>> 8. Возможна ли автоматизированная сборка?
Сделать можно, но не требуется.
(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)
(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
Сходили бы вы вот сюда: r42oo5.blogspot.ru/2013/04/3.html и прокомментировали.
Избранное оттуда:
...Вместо пути "над нами нет манагеров и дэдлайнов, сделаем всё просто и понятно" система пошла по накатанному: сделаем как можно сложнее, чтобы потом продавать "жреческие услуги". Каждый (Li|U)n(u|i)x админ, как известно, немного шаман. Почему? Потому что "просто и понятно" не продаётся, хоть ты тресни.
...Благо сегодня, в эру многозадачных телефонов с графическим интерфейсом, уже и ежу ясно что написать ОТЛИЧНУЮ операционку можно было за несколько лет имея ресурсов раз в 10 меньше чем у Линукса таки было, забудем откуда. "Ни в коем случае! Не позволим!" браво заявили "Линукс и его команда" и сотворили бессмысленного монстра из пыли, грязи и мегатонн унаследованного Юникс-кода и протоколов. Альтернативные 10 проектов маленьких, честных, симпатичных и подающих надежды BeOS умерли не родившись. А зачем нам хорошая ОС? У нас есть нежно любимые 6 (7? 8? кто больше?!) интерпретаторов командной строки...
Это ж песня!
У нас было 2 пакета травы, 75 таблеток мескалина, 5 упаковок кислоты, пол-солонки кокаина...no subject
А про BeOS там отдельная песня и по сложности она сравнима с linux. Вон интузиасты Haiku пилят до сих пор до Beta не добрались.
Если вы таки думаете я такой весь из себя красноглазый с надо замутить новую технологию, то увы это не так. Я вполне себе традиционные инструменты в мире java пользую spring framework, jpa, maven и это как раз дает меньше кода и больше прозрачности. Особенно за счет использования декларативки.
(no subject)
(no subject)
(no subject)
(no subject)