![[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
Я пишу код таким что бы я же с ним мог и разобраться.
Я уже обращал внимание, на то что это ваш код и если не дай бог случится фактор автобуса, тот кто будет за вами его разбирать будет вникать дольше. Опять же сколько у вас человек код пишет? Один два?
То же самое со сторонними фреймворками - упоротые разработчики наваяют красивостей в сто слоев абстракций вместо того что бы тупо написать линейный код делающий ровно то же самое, но блять оно ведь не по феншую будет... А доку написать по всем их поделиям и слоям абстракций - кишка тонка.
Это вот из разряда не читал, но осуждаю. Для начала давайте вы посмотрите две документации
http://www.yiiframework.com/doc/guide/
http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/
И расскажете что тут не так по вашему и чего же так остро не хватает и тому и тому.
no subject
Пишет один - я, плюс брал еще одного товарисча по удаленке, москвича. Он пишет неплохо но сложно - как вам и нравится, обвешать все классами и объектами так что физ.смысл что это все делает заипешься отслеживать. Мне в памяти ячеек не хватает все это одновременно удерживать :) Поэтому давал ему такие вещи которые в случае возникновения косяков на критичные вещи в программе не повлияют.
По поводу чтения документации - у меня совершенно нет желания копаться в документации к продукту с которым я не работаю. Без этого никаких выводов по доке сделать нельзя. Дока может выглядеть красиво и информативно, но как начнешь продукт реально использовать - всегда натыкаешься на то что в доке даны элементарные вещи и если повезет - основы и принципы. А тонкости - дай бог что бы хотя бы упомянуты были, а уж что бы были разжеваны с примерами - так и вообще чудо.
Могу дать пример такого продукта. VirtualTreeView. Хорошая дока, и компонент. Но страдает тем же. И я не уверен что есть хоть что-то что было бы описано полностью. Хотя нет, вспомнил - документация на ОС РАФОС, он же RT11. Если ты там чего-то не нашел это означало только одно - плохо искал. Все что надо я там в конце-концов находил. "Но сейчас так уже не делают".
no subject
У меня тупо кода мало - в нем и разбираться проще.
Пишет один - я
Ну этим можно и закончить. Для того чтобы начать ценить такие вещи как ORM фреймворки и прочее надо поработать там где код пишет не один человек.
По поводу чтения документации - у меня совершенно нет желания копаться в документации к продукту с которым я не работаю. Без этого никаких выводов по доке сделать нельзя. Дока может выглядеть красиво и информативно, но как начнешь продукт реально использовать - всегда натыкаешься на то что в доке даны элементарные вещи и если повезет - основы и принципы. А тонкости - дай бог что бы хотя бы упомянуты были, а уж что бы были разжеваны с примерами - так и вообще чудо.
Как я и говорил. К тому времени когда надо будет копаться уже будет поздно.
no subject
И не претендую на звание сильно продвинутого программиста.
Поддерживая культуру монотехнологии, или неувеличения их количества в проекте я упрощаю его поддержку. Для проекта это плюс. И этого достаточно.
no subject
Поддерживая культуру монотехнологии, или неувеличения их количества в проекте я упрощаю его поддержку. Для проекта это плюс. И этого достаточно.
Увы нет. Упрощение происходит тогда когда используется известный и документированный инструментарий, а так же общеизвестные практики. У вас этого всего нет. И у вас есть фактор автобуса. Проще говоря если вас завтра собьет автобус будет проще выкинуть весь ваш код и написать с нуля. У меня был проект по описанной вами "монотехнологии" как раз на дельфи. В результате вместо разбирательств с накопленным линейным и монокультурным кодом было принято решение выкинуть его к хренам и переделать все на базе spring framework. И кода внезапно стало меньше и в нем проще стало искать что нужно. Потому что банально следовали общепринятым практикам.