Сегодня компания Embarcadero разослала приглашение пользователям Delphi, C++ Builder, RAD Studio и прочим разработчикам, принять участие в ежегодном опросе, посвященном средствам разработки компании.
Данный опрос несколько отличается от предыдущих. Прежде всего, в него включены те «неудобные» вопросы, относительно которых неоднократно велась дискуссия среди разработчиков. Качество реализации различных технологий, качество документации и тому подобные вопросы. Особое внимание уделяется пожеланиям пользователей. В частности, относительно приоритетности поддержки новых платформ, новых локализаций IDE и т.д.
Читать полностью »
Рубрика «Delphi» - 19
Пишем свой ORM для Delphi
2013-06-26 в 14:01, admin, рубрики: Delphi, orm, Песочница, метки: Delphi, orm Всем привет!
Сегодня я расcкажу вам о своем опыте написания ORM для Delphi с использованием RTTI под влиянием практик работы с Doctrine и Java EE.
Зачем?
Под мою власть недавно попал старый проект на Delphi7 в котором ведется активная работа с базой данных под Interbase 2009. Код в этом проекте радовал, но ровно до тех пор, пока речь не заходила о самом взаимодействии с бд. Выборка данных, обновление, внесение новых записей, удаление — все это занимало немало строк в логике приложения, отчего разобраться в коде порой становилось довольно сложно (спасение в добросовестном разработчике, который круглосуточно отвечал на мои глупые вопросы). В мои руки проект был передан с целью устранения старых бед и добавления в него нового модуля, задача которого — покрыть новые таблицы в БД.
Мне нравится MVC подход и очень хотелось разделить код логики с кодом модели. Да и если уж на чистоту — я не захотел для каждой новой таблицы переписывать по новой все get/set методы. Пару лет назад я познакомился с понятием ORM и мне это понравилось. Мне понравился принцип и я был в восторге, применяя его в своей работе.
В тот же момент я ринулся искать в Delphi7 хоть что-нибудь похожее на Doctrine или может генераторы Entity/Facade классов для таблиц… Ни того ни другого. Зато в поисковой выдаче нашлось несколько готовых решений. Например DORM. В целом, отличная штука и, по сути, то что нужно!
Но, не знаю бывает ли у вас, я отказался от готового решения и решился писать свой велосипед. С осознанием того что хочу, с пониманием всех недостатков, я стал на этот скользкий путь и, кажется, дошел до…
Читать полностью »
Записи докладов запуска RAD Studio XE4
2013-06-14 в 11:19, admin, рубрики: Delphi, Программирование, метки: DelphiУважаемые разработчики!
Совсем недавно мы проводили запуск RAD Studio XE4 в Москве, Минске и Киеве.
Специально для тех, кто не смог посетить мероприятия мы сделали запись видео-трансляции, в которую даже включили сессию вопросов и ответов.
Посмотреть запись всех докладов можно здесь:
1 часть — youtu.be/S-qeJIFTupw — Кирилл Раннев, Стратегия компании Embarcadero и вступительное слово
2 часть — youtu.be/LTTAYAMhojQ — Всеволод Леонов, Разработка мобильных и настольных приложений на основе единой базы исходных кодов
3 часть youtu.be/ICjxcU8unHE — Ярослав Бровин, Использование FireMonkey для разработки приложений под iOS
4 часть youtu.be/hnlNvJvx-NM — Кирилл Раннев — Редакции продуктов и способы лицензирование
Читать полностью »
Создание простого интерактивного помошника
2013-06-04 в 15:43, admin, рубрики: Delphi, ИИ, искусственный интеллект, Песочница, метки: Delphi, ИИ, искусственный интеллект 
Привет! Вдохновившись последними достижениями в области прикладного ИИ и личных помощников (Siri, Google Now и им подобные), я решил написать под себя помощника, пусть и не такого продвинутого как коммерческие аналоги, зато со своим блекджеком и своей изюминкой.Читать полностью »
Работа с переменными класса класса-наследника в базовом классе
2013-06-03 в 8:29, admin, рубрики: Delphi, ооп, Песочница, метки: Delphi, оопЗачем это нужно?
С такой необходимостью я столкнулся, например, при сериализации классов. Было желание вынести весь рутинный код и информацию о классах-наследниках в базовый класс. Ну, лень ведь, прописывать одно и то же для каждого дочернего класса. Вот и призадумался, может сюда дженерики прикрутить.
Читать полностью »
Сортировка списка по аналогу «Проводника Windows»
2013-06-01 в 12:39, admin, рубрики: Delphi, Алгоритмы, украшательства, метки: украшательства Когда проект практически завершен и вся бизнес логика находится в тестировании иногда возникает желание дополнить его «рюшечками и фишечками» и прочими «украшательствами», ну например перерисовать пару иконок на более красивые, или сделать выделение элементов через градиент с альфаканалом.
Вариантов таких спонтанных хотелок (особенно при наличии времени) много и все из серии украшательств, не несущих по сути никакой смысловой нагрузки — но вот хочется и все :)
В данной мини-статье я рассмотрю одну из таких «хотелок».
Допустим у вас есть список элементов, отображаемый в TListView, вы пробуете его отсортировать и получаете вот такой результат.
Не красиво, почему это второй элемент с именем «101» находится не на своем месте? Ведь это число, а стало быть место ему как минимум после элемента с именем «2». Да и «New Folder (101)» явно должна быть после «New Folder (2)». Ведь в проводнике все выглядит нормально.
Попробуем разобраться в причинах такого поведения и реализовать алгоритм более правильной, с точки зрения человека, сортировки.
Буквально на днях ко мне обратились с вопросом.
А зачем нужен префикс LOCK, или его аналог InterlockedDecrement при вызове процедуры _LStrClr из модуля System. Данная процедура декрементирует счетчик ссылок строки и при его обнулении освобождает память, ранее занятую строкой.
Суть вопроса была такова — практически невозможно представить себе ситуацию, когда строка потеряет рефы одновременно из двух нитей, а стало быть атомарная операция в данном случае избыточна.
В принципе предпосылка интересная, но…
Нужны ли недокументированные API?
2013-05-30 в 18:34, admin, рубрики: api, Delphi, метки: api, Delphi В чем прелесть высокоуровневых языков программирования?
Программист перестает задумываться о том «как оно на самом деле фунциклирует» и выдает на гора тонну не сопровождаемого кода, который иногда даже работает, но периодически подтормаживает. Более того, частенько, он даже не собирается об этом задумываться, так как у него банально отсутствуют необходимые знания (увы, так сейчас учат).
Потом из всего этого появляются такие умные слова как «паттерны проектирования», внутренние фреймфорки, на которые без слез не взглянешь и прочая светотень включая техдокументацию, которую нужно написать так, чтобы ее смог понять некий сторонний пейзанин, который к программированию, по сути (да и по должности), имеет самое отдаленное отношение.
Слова умные, для высокоуровневого кода вполне даже может подходят, но…
А потом, выполнив очередной умный «паттерн» он начинает разбираться — где же тормозит алгоритм. Причем, если программист более настырен, он изучает реализацию VCL и иногда даже докапывается до сути, где получается так, что тормоза упираются в вызовы известных ему по документации API, пройдя к которым он со спокойной душой останавливается и закрывает тикет в багтрекере фразой: «функция ХХХ тормозит, вариантов обхода нет».
Не встречались с ситуацией?
Значит повезло…
Правильное применение сплайсинга при перехвате функций подготовленных к HotPatch
2013-05-27 в 18:55, admin, рубрики: Delphi, перехват системных функций, метки: Delphi, перехват системных функцийВ прошлой статье я рассмотрел пять вариантов перехвата функций включая их вариации.
Правда в ней я оставил не рассмотренными две неприятных ситуации:
1. Вызов перехваченной функции в тот момент, когда ловушка снята.
2. Одновременный вызов перехваченной функции из двух разных нитей.
В первом случае программист, установивший перехватчик не будет видеть всю картину в целом, т.к. часть данных пройдет мимо него.
Второй случай грозит более серьезными последствиями, вплоть до падения приложения, в котором установлен перехватчик.
Обе этих ситуации могут быть только в случае применения сплайсинга. При перехвате через таблицы импорта/экспорта и т.п. модификации тела перехватываемой функции не происходит, поэтому данные варианты перехвата не требуют излишних телодвижений.
В этой статье более подробно будет рассмотрен сплайсинг точки входа функции подготовленной к HopPatch, т.к. данные функции предоставляют нам способ ухода от вышеперечисленных ошибок.
Перехват сплайсингом через JMP NEAR OFFSET или PUSH ADDR + RET (наиболее уязвимый к данным ошибкам) рассмотрен не будет, т.к. по хорошему, без реализации дизассемблера длин, заставить данный вариант перехвата работать как нужно не получится.
Особенности применения интерфейсов в Delphi
2013-05-27 в 10:28, admin, рубрики: Delphi, интерфейсы, метки: интерфейсыИнтерфейсы в Delphi появились не сразу, а когда появилась необходимость поддержать работу с COM и на мой взгляд они не очень стройно вписались в язык.
Скажу честно, я как правило пользуюсь интерфейсами не для взаимодействия с внешним миром посредством механизма СОМ. И, подозреваю, что не только я. В Delphi интерфейсы нашли себе другое полезное применение.
Фактически, интерфейсы полезны в двух случаях:
- Когда необходимо использовать множественное наследование;
- Когда ARC (автоматический подсчет ссылок) серьезно облегчает управление памятью.
В Delphi исторически нет и не было множественного наследования в той форме, как это принято в некоторых других языках программирования (например, С++). И это хорошо.
В Delphi проблемы множественного наследования решаются интерфейсами. Интерфейс — это полностью абстрактный класс, все методы которого виртуальны и абстрактны. (GunSmoker)
И это практически так, но не совсем так! Интерфейсы очень похожи на абстрактные классы. Очень похожи, но в конечном итоге классы и интерфейсы ведут себя очень по-разному.
В связи с грядущими изменениями, то есть по мере появления ARC в новом компиляторе тема управления жизнью Delphi-объектов получает новую актуальность, так как прогнозируемо будут новые «священные войны». Мне бы не хотелось именно сейчас резко вставать на ту или иную сторону, хочется лишь поисследовать существующие области пересечения «классического» подхода и «ссылочных» механизмов управления жизнью объекта как программисту-практику.
Тем не менее, позволю себе выразить надежду на то, что ARC в новом компиляторе даст возможность действительно воспринимать интерфейсы всего-лишь как абстрактные классы. Хотя я отношусь к подобным революционным изменениям с опаской.
Часто программисты «интерфейсных морд» к БД игнорируют вопросы управления памятью объектов, что не умаляет важность темы, которая до сих пор возбуждает явный интерес профессионалов, которые продолжают исследовать применимость «интерфейсов» для выработки альтернативных классическим подходов.
По моему мнению, смешивать в работе классы и интерфейсы следует крайне осторожно. Всему виной счетчик ссылок. Для понимания этого давайте проделаем простое упражнение.
Читать полностью »