Какое-то время назад преимуществом Delphi/Builder перед C# была возможность собрать "монолитное" приложение в которое залинковано все что надо, без необходимости тащить огромный рантайм.
Сейчас, конечно, рантайм C# есть везде, за исключением самых экзотических случаев. Но, имхо, рантайм все равно может доставить головной боли своими версиями, если стоит задача поддерживать приложение на сотнях машин
Вчера тут пробегала статья про натриевые лампы. Там в камментах пробегала мысль что их хорошо использовать для освещения теплиц - большой световой поток, лучшее соотношение лм/Вт и практически идеальный спектр
Кстати, выше писали об очистке цепи при помощи WD-40 с последующей смазкой. Знаю людей которые просто "смазывали" цепь ВД-шкой - через пару дней покатушек после обработки цепь выглядела жутко грязной
Немного про нестандартные способы использования ВэДэ-шки...
В начале двухтысячных жил-был окушечный автофорум. В силу бюджетности авто, народ подобрался рукастый и смекалистый.
И конечно же, был на форуме раздел посвященный миллиону способов использования WD-шки. От банального открутить гайку, менее банального разморозить/"смазать" замки, до более экзотических типа пропшикать уплотнители дверей после мойки и "сушки" и защиты высоковольтных катушки и проводов (катушка "удачно" располагалась аккурат над колесной аркой, так что утопить ее в брызгах при проезде лужи был распространенный кейс).
И вот в ветке появляется миллион-первый совет - как потушить WD-шкой начавшийся пожар :) У чувака подтекал топливопровод или карбюратор, и всё это дело загорелось. Чувак переполошился, схватил что под руки попалось, и потушил огонь WD-шкой (видимо просто сбило пламя). Форумчане прифигели с безбашенности и удачливости кекса, и объяснили, что керосином тушить огонь такая себе идея :)
ЗЫ: еще один из недостатков использования WD-40 в качестве смазки - обработанное место быстро набирает на себя пыль или грязь и довольно скоро всё становится еще хуже чем до обработки
Хотя нет. Был у нашей биллинговой системы момент когда она не только принимала карточки много раз, более того, она принимала любые введенные комбинации цифр подходящей длины. В течении недели. Извинением могло служить лишь то, что начислений тоже не было. И никого не блокировали даже за лютейший фрод. Просто напросто у нас не было базы данных.
Жил был маленький но гордый региональный сотовый оператор. Денег грёб лопатой, но на системе бэкапа экономил - всё потом как-нибудь. И однажды у БД очень нехорошо развалился raid. Сбойнул контроллер, развалив логическую структуру томов. Диски читались и были исправны, но монтироваться в массив отказывались. Очень уважаемая контора, производитель массива, повздыхала, сослалась на сбой из-за высокоэнергетической частицы из космоса (в частном, конечно, разговоре, не в официальной переписке, но тем не менее раньше я думал что отмазка про шальные частицы это фольклор) и признала что починить никак нельзя. Позвали спеца из Москвы, он охнул, крякнул, и погрузился в шестнадцатиричный редактор служебных областей дисков.
Стало понятно что какое-то время живем без базы. В таких условиях руководство сказало, что война войной, а деньги собирать надо. Ну не знаем корректных пин-кодов карт, черт с ними. На коленке за полдня был сооружен сервис просто логировавший все введенные данные в файл.
Где-то через неделю некромантии удалось восстановить массив. Весь лог введенных секретных кодов прогнали через штатный механизм, начисляя деньги на счета и отсеивая всё что не прошло. Еще пол-недели нагоняли тарификацию скопившихся в файлах звонков с коммутатора.
История закончилась не так ужасно как могла бы и все извлекли из нее урок. Руководство - что экономия на железе выходит боком. ИТшный отдел подумал о единой точке отказа. Лично я - досконально понял принцип "show must go on"
А еще были интернет-карточки. Работали они очень просто: купил в ларьке карточку, пришел домой, стер защитный слой, под которым либо уже написана пара логин-пароль, либо написан код, который надо ввести в веб-интерфейсе биллинга провайдера, после чего тебе на счет упадет соответствующее число рублей или минут.
Хе-хе. Много было компаний пытающихся писать биллинги в духе
select card_status into :Status from card where card_pin=:Pin
if :Status='unused' then
update card set status='used' where card_pin=:Pin
с последующим увеличением баланса лицевого
Хотя транзакционные базы при грамотном применении начисто исключали саму возможность неконсистентного изменения данных, достаточно было дописать условие в update:
update card set status='used' where card_pin=:Pin and status='unused'
Если изменено ноль строк - выходим. Первая сессия залочит строку до окончания транзакции. Вторая будет ждать ее окончания и обломится по условию статуса. Даже при страшных тормозах сервера БД, физически невозможно активировать карты дважды.
Лет 10 назад делали аналитическую систему, которая выгружала данные из PI с целью дальнейшего «верчения» в OLAP.
Даже тогда у PI был вполне сносный SQL драйвер, который позволял не просто выгрузить данные, но еще и применить встроенные функции PI к этим данным
Зачем в нее играть, когда интереснее сломать? )
Вспоминается новогодний ночер, куча народа вокруг компа (286, что позволяло не парится о ресурсах), дизасемблер, заметки и адреса на салфетках. Логика в отличии от стрелялок, где достаточно было патчить переменную здоровья, сложная. Так толком и не сломали, но ночь пролетела незаметно
Видел барабанный принтер советского производства в местных энергосетях. К сожалению счастью выведенный из эксплуатации. Местные говорили, что адская машина была, как по производительности, так и по и производимому шуму.
Имхо самое стрёмное — «прыжок веры». В одном месте надо было прыгнуть в соседний экран через пропасть. А что на соседнем экране непонятно — его по геймплею не показывали, подсмотреть, что на нем было, никак нельзя. И в этих условиях надо было выбрать — сделать короткий прыжок или длинный. Правильный выбор — короткий прыжок. Если выбрать длинный, то проскакиваешь короткую площадку и улетаешь в следующую пропасть.
Никогда не забуду как я мялся перед этим прыжком, и какое чувство было когда угадал с первого раза.
ЗЫ: кажется, этот момент описан в «Принце госплана». Но его я читал позже.
Принц Персии, мне так и не удалось пройти дальше второго уровня в те годы, и до сих пор не уверен, реально ли его пройти.
Вполне реально, сам проходил на МС-1502 с подключенным винтом и расширением памяти.
С расширением памяти был курьезный случай:
Как-то друг не пришел на зачет. Позже на вопрос «что так?», ответил что дошел до предпоследнего уровня, какой тут зачет.
Это все объясняло — у него тоже была мс-1502 со слотом расширения памяти. Оставить игрушку на полдня (в статье писали про лимит 60 минут, но у нас его не было — видимо ломаная версия), означало что комп неминуемо повиснет и придется проходить заново.
Частично согласен с предыдущим автором. Индекс к теме соединений не относится непосредственно, но мне кажется можно было сделать краткую ремарку на счет индексов. Иначе у человека не в теме может возникнуть вопрос — а зачем вообще NL при его катастрофической по сравнению с другими алгоритмами производительности
+1 к предыдущему комментарию.
Интересно как тестируются процедуры которые изменяют данные? (А что еще должен делать код в пакаджах базы? Это как бы его основная задача).
Раскатать тестовый набор данных прогнать тесты и откатить состояние к первоначальному?
Тем более непростой становится задача если тесты запускаются параллельно и/или в произвольном порядке.
Цель VIEW как раз обратная — оградить приложения от изменения структуры базы. Именно этим они и удобны :)
Пример из практики, как раз в тему статьи. У нас в одной из версий системы (речь о oracle, но суть та же) pk/fk были number. В следующей версии сделали их number(9,0). Все приложения со статической типизацией полей стали валиться с ошибками несоответствия типов. Поправили типы полей. Однако хочется и обратной совместимости — чтобы приложения могли работать и с предыдущей версией БД. Если бы не было view пришлось бы поддерживать 2 версии, а так просто во VIEW поправили select pk… на select cast(pk as number(9,0)) as pk…
И да, самое сложное не в самой базе, а в приложения ее использующих — далеко не все из приложений стерпят молча замену int на bigint
Самое страшное в вашем случае (как и в моем) — переход с AnsiChar на WideChar. Это зачастую может быть даже сложнее — с однобайтной кодировки string в D7 перепрыгнуть в двухбайтную современную.
PChar тоже не подарок — повсеместно раньше использовался как аналог PByte (возможно его и не было те времена). А это всё низкоуровневое общение с памятью и куча проблем со старыми/сторонними компонентами
procedure TApplication.Initialize;
begin
if InitProc <> nil then TProcedure(InitProc);
end;
В простом проекте это пустышка — InitProc nil.
Только всякие платформозависимые модули добавляют обработчик — ComObj, ComServ, OleAuto и почему-то DBTables. Хотя и в нём всё сводится к тому-же CoInitialize. Оно и понятно — кто раньше застолбил потоковую модель использования COM, того и тапки.
С последним обстоятельством был связан очень неприятный баг — у нас клиент-серверное приложение работающее по DCOM с потоковой моделью FreeThread. На некоторых компах клиент (точнее винда) при попытке коннекта выдавал ошибку о несовпадении потоковой модели COM клиента и сервера. Оказалось драйверы принтера некоторой корпорации (не буду показывать пальцем, та у которой статьи почему чернила дороже чем кровь) при загрузке переинициализировали потоковую модель в SingleThread. Да MS явно в доке пишет что такое недопустимо, но что делать если хочется… Пришлось алаверды в dpr дописывать код принудительной переинициализации COM
необходимо в so-библиотеке… определить инициализацию Application в секции initialization и завершение в finalization
{$IFDEF FPC}
initialization
Application.Initialize;
finalization
Application.Terminate;
end.
{$ENDIF}
Удивил момент что надо инициировать Application в каждой библиотеке. В Delphi/VCL, насколько я помню, Application глобальный singleton объект и повторная инициализация смысла не имеет.
Машинариум кажется на флэше. Огромный квест с кучей ресурсов запаковали во флэш — это о границах технологии, оно не ограничивалось мелкими проектами и/или игрухами. Но всеми приходит конец. RIP
Какое-то время назад преимуществом Delphi/Builder перед C# была возможность собрать "монолитное" приложение в которое залинковано все что надо, без необходимости тащить огромный рантайм.
Сейчас, конечно, рантайм C# есть везде, за исключением самых экзотических случаев. Но, имхо, рантайм все равно может доставить головной боли своими версиями, если стоит задача поддерживать приложение на сотнях машин
Вчера тут пробегала статья про натриевые лампы. Там в камментах пробегала мысль что их хорошо использовать для освещения теплиц - большой световой поток, лучшее соотношение лм/Вт и практически идеальный спектр
Кстати, выше писали об очистке цепи при помощи WD-40 с последующей смазкой. Знаю людей которые просто "смазывали" цепь ВД-шкой - через пару дней покатушек после обработки цепь выглядела жутко грязной
Думаю что нем, ВД-шка же "жирная" - такие разводы будут, что фиг ототрешь потом
Немного про нестандартные способы использования ВэДэ-шки...
В начале двухтысячных жил-был окушечный автофорум. В силу бюджетности авто, народ подобрался рукастый и смекалистый.
И конечно же, был на форуме раздел посвященный миллиону способов использования WD-шки. От банального открутить гайку, менее банального разморозить/"смазать" замки, до более экзотических типа пропшикать уплотнители дверей после мойки и "сушки" и защиты высоковольтных катушки и проводов (катушка "удачно" располагалась аккурат над колесной аркой, так что утопить ее в брызгах при проезде лужи был распространенный кейс).
И вот в ветке появляется миллион-первый совет - как потушить WD-шкой начавшийся пожар :) У чувака подтекал топливопровод или карбюратор, и всё это дело загорелось. Чувак переполошился, схватил что под руки попалось, и потушил огонь WD-шкой (видимо просто сбило пламя). Форумчане прифигели с безбашенности и удачливости кекса, и объяснили, что керосином тушить огонь такая себе идея :)
ЗЫ: еще один из недостатков использования WD-40 в качестве смазки - обработанное место быстро набирает на себя пыль или грязь и довольно скоро всё становится еще хуже чем до обработки
ЛА со схемой "летающее крыло" не слишком манёвренные, так что шансы что-то перехватить так себе
Хотя нет. Был у нашей биллинговой системы момент когда она не только принимала карточки много раз, более того, она принимала любые введенные комбинации цифр подходящей длины. В течении недели. Извинением могло служить лишь то, что начислений тоже не было. И никого не блокировали даже за лютейший фрод. Просто напросто у нас не было базы данных.
Жил был маленький но гордый региональный сотовый оператор. Денег грёб лопатой, но на системе бэкапа экономил - всё потом как-нибудь. И однажды у БД очень нехорошо развалился raid. Сбойнул контроллер, развалив логическую структуру томов. Диски читались и были исправны, но монтироваться в массив отказывались. Очень уважаемая контора, производитель массива, повздыхала, сослалась на сбой из-за высокоэнергетической частицы из космоса (в частном, конечно, разговоре, не в официальной переписке, но тем не менее раньше я думал что отмазка про шальные частицы это фольклор) и признала что починить никак нельзя. Позвали спеца из Москвы, он охнул, крякнул, и погрузился в шестнадцатиричный редактор служебных областей дисков.
Стало понятно что какое-то время живем без базы. В таких условиях руководство сказало, что война войной, а деньги собирать надо. Ну не знаем корректных пин-кодов карт, черт с ними. На коленке за полдня был сооружен сервис просто логировавший все введенные данные в файл.
Где-то через неделю некромантии удалось восстановить массив. Весь лог введенных секретных кодов прогнали через штатный механизм, начисляя деньги на счета и отсеивая всё что не прошло. Еще пол-недели нагоняли тарификацию скопившихся в файлах звонков с коммутатора.
История закончилась не так ужасно как могла бы и все извлекли из нее урок. Руководство - что экономия на железе выходит боком. ИТшный отдел подумал о единой точке отказа. Лично я - досконально понял принцип "show must go on"
Хе-хе. Много было компаний пытающихся писать биллинги в духе
select card_status into :Status from card where card_pin=:Pin
if :Status='unused' then
update card set status='used' where card_pin=:Pin
с последующим увеличением баланса лицевого
Хотя транзакционные базы при грамотном применении начисто исключали саму возможность неконсистентного изменения данных, достаточно было дописать условие в update:
update card set status='used' where card_pin=:Pin and status='unused'
Если изменено ноль строк - выходим. Первая сессия залочит строку до окончания транзакции. Вторая будет ждать ее окончания и обломится по условию статуса. Даже при страшных тормозах сервера БД, физически невозможно активировать карты дважды.
Даже тогда у PI был вполне сносный SQL драйвер, который позволял не просто выгрузить данные, но еще и применить встроенные функции PI к этим данным
Вспоминается новогодний ночер, куча народа вокруг компа (286, что позволяло не парится о ресурсах), дизасемблер, заметки и адреса на салфетках. Логика в отличии от стрелялок, где достаточно было патчить переменную здоровья, сложная. Так толком и не сломали, но ночь пролетела незаметно
сожалениюсчастью выведенный из эксплуатации. Местные говорили, что адская машина была, как по производительности, так и по и производимому шуму.Никогда не забуду как я мялся перед этим прыжком, и какое чувство было когда угадал с первого раза.
ЗЫ: кажется, этот момент описан в «Принце госплана». Но его я читал позже.
Вполне реально, сам проходил на МС-1502 с подключенным винтом и расширением памяти.
С расширением памяти был курьезный случай:
Как-то друг не пришел на зачет. Позже на вопрос «что так?», ответил что дошел до предпоследнего уровня, какой тут зачет.
Это все объясняло — у него тоже была мс-1502 со слотом расширения памяти. Оставить игрушку на полдня (в статье писали про лимит 60 минут, но у нас его не было — видимо ломаная версия), означало что комп неминуемо повиснет и придется проходить заново.
Интересно как тестируются процедуры которые изменяют данные? (А что еще должен делать код в пакаджах базы? Это как бы его основная задача).
Раскатать тестовый набор данных прогнать тесты и откатить состояние к первоначальному?
Тем более непростой становится задача если тесты запускаются параллельно и/или в произвольном порядке.
Пример из практики, как раз в тему статьи. У нас в одной из версий системы (речь о oracle, но суть та же) pk/fk были number. В следующей версии сделали их number(9,0). Все приложения со статической типизацией полей стали валиться с ошибками несоответствия типов. Поправили типы полей. Однако хочется и обратной совместимости — чтобы приложения могли работать и с предыдущей версией БД. Если бы не было view пришлось бы поддерживать 2 версии, а так просто во VIEW поправили select pk… на select cast(pk as number(9,0)) as pk…
И да, самое сложное не в самой базе, а в приложения ее использующих — далеко не все из приложений стерпят молча замену int на bigint
PChar тоже не подарок — повсеместно раньше использовался как аналог PByte (возможно его и не было те времена). А это всё низкоуровневое общение с памятью и куча проблем со старыми/сторонними компонентами
В простом проекте это пустышка — InitProc nil.
Только всякие платформозависимые модули добавляют обработчик — ComObj, ComServ, OleAuto и почему-то DBTables. Хотя и в нём всё сводится к тому-же CoInitialize. Оно и понятно — кто раньше застолбил потоковую модель использования COM, того и тапки.
С последним обстоятельством был связан очень неприятный баг — у нас клиент-серверное приложение работающее по DCOM с потоковой моделью FreeThread. На некоторых компах клиент (точнее винда) при попытке коннекта выдавал ошибку о несовпадении потоковой модели COM клиента и сервера. Оказалось драйверы принтера некоторой корпорации (не буду показывать пальцем, та у которой статьи почему чернила дороже чем кровь) при загрузке переинициализировали потоковую модель в SingleThread. Да MS явно в доке пишет что такое недопустимо, но что делать если хочется… Пришлось алаверды в dpr дописывать код принудительной переинициализации COM
Удивил момент что надо инициировать Application в каждой библиотеке. В Delphi/VCL, насколько я помню, Application глобальный singleton объект и повторная инициализация смысла не имеет.
nicky7
bpl это расширенная версия dll с точки зрения интерфейса — к стандартным функциям добавлены дополнительные под нужды среды/vcl
PS: Очень впечатлён! Мне казалось что портирование сколько-то сложного проекта задача просто непосильная.