MyObject.OnEvent := procedure() begin MyObject.OnEvent := nil; MyField.MyProp := 'Value'; end;
Оказывается на MyObject.OnEvent := nil; счетчик ссылок у класса замыкания скрутится в 0 и замыкание отойдет в мир иной, а на следующей строчке привет AV.
пятница, 23 октября 2015 г.
Просто баг в коде или особенность счетчика ссылок в замыканиях
среда, 26 августа 2015 г.
Что дал переход с SVN на Git или Git как ключ для синергии хороших практик
Год назад мы в проекте выполнили переход с SVN на Git. Нас привлекали возможности бранчевания и работы с репозиторием без сети. "Сарафанное радио" регулярно доставляло сообщения о преимуществах модели распределенных систем контроля ревизий. В итоге, переход себя полностью оправдал, и Git раскрыл множество прекрасных возможностей, о которых во время перехода даже не подозревали. Но самое замечательное, что побочным эффектом оказалось поднятие общего уровня и культуры разработки.
В первой части я расскажу о своих ощущениях после перехода на Git. Если вы уже знакомы с ним, то возможно вам следует перейти сразу ко второй части, где я попытался снизить градус слащавости и пафоса и перейти уже наконец то к делу. Во второй и третьей части я коснусь практических вопросов, которые проливают свет о влияние гита на культуру разработки.
В первой части я расскажу о своих ощущениях после перехода на Git. Если вы уже знакомы с ним, то возможно вам следует перейти сразу ко второй части, где я попытался снизить градус слащавости и пафоса и перейти уже наконец то к делу. Во второй и третьей части я коснусь практических вопросов, которые проливают свет о влияние гита на культуру разработки.
Дифирамбы Git'у
Часто пользователи SVN не видят обоснованных причин для перехода на Git (на самом деле слово Git можно смело заменить на DVCS, однако опыт у меня есть только связанный с Git, потому дальше Git будет мелькать чаще). И в действительности среди плюсов на поверхности лежит лишь концепция распределенности и мифическая легкость ветвления (бранчевания). Как сказал мой друг, парадокс гита заключается в том, что вначале не можешь понять чем Git хорош, а потом не знаешь как это рассказать. Это надо только прочувствовать. Сухое сравнение разных концепций не всегда убедительно. Многие возможности есть в обоих VCS. А по некоторым возможностям SVN имеет преимущества. Кто-то скажет, что у них разные области и назначения, но используют то их чаще всего одинаково. Технические аспекты лучше всего смотреть в официальном руководстве для гита https://git-scm.com/book/ru/v1 (на мой взгляд лучшее руководство по гит), поэтому дальше в статье будут ощущения и эмоции.
С каждым днем только крепнет уверенность, что уже ничто не заставит вернуться обратно. Сказать честно, вначале было много сомнений, стоит ли игра свеч, а не будет ли это потеря времени? Теперь смело заявляю, что Git это намного больше чем SVN, или VCS в парадигме SVN (sic!). Система хранения ревизий с точки зрения SVN является просто хранилищем кода и его изменений, преследуя такие простые практические цели как обмен общими файлами проекта, навигация и возможность вернуться к нужной версии или найти виновника и задачу, в рамках которых был поломан продукт. Слышу от оппонентов: "мне Git не нужен, так как я работаю один/у нас нет веток/в гите нельзя работать с бинарными форматами/ гит слишком сложен/ и т.п." На самом деле он нужен всем (программистам, дизайнерам он может и не подходить) и вот почему.
Git меняет представление о назначение VCS. Поднимает культуру работы с кодом проекта. История изменения кода не менее важна, чем сам код, а может даже более. Git предоставляет возможности выставить акцент на истории изменения кода. В системе контроля версий начинает формироваться слой документации и требований к продукту в самой непосредственной близости к коду. И немаловажным фактором является возможность следовать новым нехитрым практикам работы с репозиторием и кодом, которые дисциплинируют разработчика. Что положительно сказывается на коде. Код становится более логичным, красивым и вылизанным.
Почему же в гите все это можно обеспечить? Краеугольный камень - это распределенность. Что она дает? Обычно говорят, что распределенность дает возможность работать без подключения к интернету и обмениваться ревизиями минуя центральный репозиторий. Да - это верно. Но не на это я хочу обратить внимание. Главное, что репозиторий у вас ЛОКАЛЬНЫЙ. Вот именно так: капсом и болдом. Это позволяет манипулировать ветками и коммитами без опасения повлиять на работу коллег. У нас есть правило, звучащее как "в репозиторий должен попадать только рабочий, целостный код, прошедший ревью". На сколько сложно это правило соблюдать в SVN, на столько легче его соблюдать в гите.
Что же еще делать в гите легко и является ежедневной рутиной, о чем SVN джедаи могли бы только мечтать? В Git'e легко создавать ветки, выполнять слияние, манипулировать коммитами. Вам, как заправскому шулеру, ничего не стоит строить цепочки коммитов, дробить коммиты на более мелкие, менять коммиты местами, менять описание текста коммита и его состав. Каждая операция требует минимального времени выполнения, никакой передачи данных по сети или копирования каталогов.
Ну ок. Все мы уже поняли, что Git хорош как Чак Норис в ковбойской шляпе и из хорошей задачи можно устроить отличный фарш из коммитов. Но зачем? Вот типичные моменты рабочего процесса под Git:
- Ветки создаются под каждую задачу или просто для проверки какой-либо идеи;
- Коммиты создаем часто, очень часто. Хотим ли особо акцентировать внимание на изменение в коде либо просто закончили итерацию, на все один ответ - коммит. В Git нет проблемы зафиксировать каждый логический блок изменений в рамках задачи отдельным коммитом. В SVN такое желание приведет к неконсистентному состоянию кода в центральном репозиторие;
- Увлеклись, написали кучу кода, и вот у нас в одном файле изменения, которые относятся к разным логическим частям? В Git это совершенно не проблема - разные логические части одного файла Git позволяет зафиксировать разными коммитами;
- Забыли написать тесты и проверить их работу до написания функционала? Не проблема, пишем тесты и новый коммит вставляем перед коммитом задачи;
- Хотим отправить изменения в центральный репозиторий, но перед этим избавиться от избытка лишней информации и вместо 15 коммитов, отправить 4 сгруппированных? Все верно - и это не проблема.
- Я уже не говорю про классические преимущества DVSC, такие как совместная работа над одной задачей разных членов команды.
Звучит как фантастика? Отнюдь - просто обычные будни работы с Git. Когда долго не работаешь с SVN забываешь, что там эти операции не возможны. Гит дает чувство пьянящей свободны, нет практически ничего, что вы не могли бы в нем делать. Все делается очень легко: манипулирование ветками и коммитами напоминает игру. И вы от это получаете удовольствие, потому что все ваши, даже сложные, задумки реализуются, а желания предугадываются. Ну и конечно вы получается удовольствие от того, что в памяти всегда свежи ощущения от SVN.
Наши практики по работе с репозиторием кода
Гит добавляет в методологию разработки новые аспекты, которых вовсе не ожидаешь, пока не начнешь его использовать. Эти аспекты мы раскрывали постепенно, шаг за шагом вводя простые правила:
| 1. | На первом шаге у нас была одна постоянная ветка, бранчи использовались очень эпизодически и не было стабильной версии продукта. Да и так бывает. Бывало даже так, что одним коммитом фиксировалось сразу несколько задач. С этого мы начинали. | ||
| 2. | Потом появились ветки SVN (до SVN использовали VSS и Perforce). SVN - хорошая система. Какое-то время использовали собственную модель бранчевания, потом сдались и перешли на стандартную раскладку trunk, tags, branches. В branches мы создавали ветки только под большие задачи. Прошло много времени, но я хорошо помню боль и отчаянье от работы с ветками в SVN. Это было долго - долго создавать ветки, долго переключать, долго смотреть лог, а слияния веток превращались в испытание. Но с проблемами можно было мириться, если работать только с долго живущими ветками. | ||
| 3. | А следом появилось ревью кода. Это была практика, которая все перевернула. Сейчас мне сложно представить разработку без ревью. | ||
| 4. | Идеальным дополнением к ревью кода стал Git. Модель Git (DVCS) как нельзя лучше подходит для ревью кода. Следующие пункты раскроют это утверждение. | ||
| 5. |
Первым делом мы ввели правила написания текста коммита. Как писать коммит у нас жестко формализовано. Сами правила начали появляться еще при SVN, но только переход на Git заставил к ним относиться строго. Главное требование гласит: текст коммита обязан содержать мотивацию принятия решений и изменений, присутствующих в коде коммита. Перед выкладыванием на сервер каждая задача проходит ревью кода. Ревью кода выполняется с помощью инструмента CodeReviewer. И вот тут основной момент - ревьюверу задачи должно быть понятно все только на основе информации из коммита: непосредственно кода и текста описания коммита. Если возникают вопросы, то описание коммита перерабатывается. Можно найти множество плюсов подобного подхода:
Теперь текст коммита стал вот таким:
"fix: исправить фокусировку на следующию ячейку после нажатия Enter #issue 40436
При этом мы придерживаемся правила - код должен документировать сам себя. Комментарий в коде - признак плохого кода. Цель описания в коммите - не описание изменений, а описание почему именно так, а не иначе. В тексте коммита можно описать альтернативные варианты решения с плюсами и минусами. К слову сказать, текст коммита у нас так же ревьювируется как и код. В SVN это правило было тяжело соблюдать. Как правило, задача уходила на сервер одним коммитом, что бы не получить в централизованном репозитории не консистентного состояния. Описание всех изменений в одном коммите теряет свою красоту и эффективность. В git'е каждую задачу можно декомпозировать до небольших логических шагов, о чем в следующем правиле. | ||
| 6. |
Правила оформления задачи в ветках.
Каждую задачу, как правило, можно декомпозировать на несколько шагов. Отделив, например, рефакторинг от непосредственно кода, исправляющего ошибку. Каждый шаг - отдельный коммит в отдельной ветке задачи. В последствии вся ветка попадет в центральный репозиторий, сохраняя для поколений структурированное решение задачи. Теперь даже коммит, который был выполнен "заодно" и не являющийся непосредственно необходимым для закрытия задачи, находится в контексте задачи (в той же ветке), позволяя видеть цель и мотивацию автора.
Задача в SVN - это большой, размазанный по разным модулям патч. Больших усилий стоит разобраться в таком патче. Гораздо проще, когда каждая задача - это структурное решение, и можно пробежаться по отдельным шагам. В таком решении отделяются "зерна от плевел".
Репозиторий стал неотъемлемой частью кода проекта.
Пример:
По ходу ревью в код могут вносится изменения, каждое такое изменение может вносится squash коммитом. Это коммит, который в последствие с помощью команды rebase можно объединить с другим коммитом (что бы ощутить мощь Git достаточно пробежаться по оглавлению способов изменить историю https://git-scm.com/book/ru/ и http://97things.oreilly.com/wiki/index.php/Record_your_rationale). Таким образом, можно будет и в ревью видеть развитие мысли автора. А после завершения ревью одной командой rebase можно изменить историю и получить красивое дерево коммитов, без лишнего мусора, объединив squash, fixup коммиты с базовыми. | ||
| 7. | Правило "юнит тесты до функциональности". Это правило говорит о том, что юнит тесты должны располагаться в дереве коммитов до исправления ошибки, которую они тестируют. В результате всегда можно проверить работу юнит теста до исправления ошибки и после. Убедиться, что тест и исправление написаны верно. Пример:
|
Про культуру
Система постоянно меняется, практически невозможно постоянно актуализировать все требования к приложения и его описания. Но теперь репозиторий взял на себя новую ответственную роль. Стал рассказывать не только кто и когда написал код, но и почему(такую роль бывает берет на себя багтрекер, но это слишком далеко от кода). Можно проследить мысль автора, узнать мотивы. Это формирует еще один уровень метаинформации. С помощью такого слоя информации мы стараемся закрыть наиболее критическое место описания системы. Практика показывает, что гораздо проще восстановить предисторию и все причины принятия конкретного решения для будущей переоценки, если они привязаны к коду и расположены прямо в репозитории. Почему важно сохранять подобного рода информацию можно почитать еще здесь 97things.oreilly.com/wiki/index.php/Challenge_assumptions_-_especially_your_own и во многих других местах. Но при при чем здесь культура?
Чтобы понимали, что я имею в виду под культурой, приведу отрывок из книги Бориса Евсеевича Чертока "Ракеты и Люди", за который меня наверное уже недолюбливают как друзья, так и коллеги, слишком уж часто я его вспоминаю:
"В первые годы работы над ракетной техникой практически никто из руководителей, критикующих завод, не мог конкретно сформулировать, что нужно сделать для повышения культуры производства, определить роль каждого начальника цеха, мастера и рабочего. Было слишком много общих решений. Устинов беспощадно расправлялся с начальниками цехов и производств за грязь и бескультурье. При посещениях завода он начинал с туалетов. Обычно в цехах задолго до подхода к туалету разносился характерный «аромат». В самих туалетах надо было ходить по лужам. Устинов приходил в ярость и гремел: «Какой сортир, такой и начальник цеха. Пока не добьетесь образцовой чистоты в своих сортирах, не будет чистоты и в цехах».С тех пор прошло очень много лет. Проблема чистоты общественных туалетов на наших заводах и в институтах так же, впрочем, как и в стране в целом, не решена. Это оказалось куда труднее, чем создать самое грозное ракетно-ядерное оружие и завоевать мировой приоритет в космонавтике.Явный дефицит культуры, общей производственной чистоты и гигиены до сих пор является одной из причин низкого качества многих отечественных изделий. За время войны и в последующие годы забота об элементарном комфорте в цехах, создание рабочему достойной и привлекательной общей обстановки считались излишней и непозволительной роскошью. Затраты на чистоту, комфорт, элементарный сервис с лихвой окупаются повышением производительности и качества. "
Если театр начинается с вешалки, то проект начинается с репозитория. Отношение к репозиторию закладывает отношение ко всему проекту. Аккуратность, формализованность, структурированность, обоснованность, ответственность и прозрачность - качества, которые культивируются приведенными выше правилами работы с репозиторием, переносятся и на другие аспекты проекта. Сам workflow выполнения задачи сопротивляется поспешным, не продуманным, ошибочным и не обоснованным решениям. Код должен выглядеть хорошо и аккуратно не только внутри, но и снаружи. Мелочей не бывает. При переходе на Git о таких вещах, к сожалению, почти не задумывались. Git конечно, не серебряная пуля и не Святой Грааль, но крайне эффективный инструмент, который может сильно изменить ландшафт методологии разработки.
Гит раскрывает свои возможности постепенно. Постоянно открываем что-то новое. В начале используется базовый набор команд. Но потом постепенно открываются все новые и новые возможности и пути оптимизации операций и повышения собственной эффективности. Кажется, что мы используем от 20 - 40% возможностей Git. Мы продолжаем познавать Git, постоянно экспериментируем и дорабатываем наши правила и стандарты. Возможно читатель поделится и своими успешными практиками.
Несколько полезных ссылок
Некоторые правила я не описал, а некоторые из приведенных правил у нас формализованы и описаны гораздо подробнее. Многие правила для подробного описания потребуют статью. Наибольшую важность несет в себе ревью и стандарт написания текста коммита. Крайне рекомендую ресурсы, на основе которых у нас формировались правила, касающиеся написания текста коммита:
- http://git.kernel.org/cgit/git/git.git/tree/Documentation/SubmittingPatches?id=HEAD
- https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit#
- https://wiki.openstack.org/wiki/GitCommitMessages
- http://stackoverflow.com/questions/3580013/should-i-use-past-or-present-tense-in-git-commit-messages
понедельник, 4 мая 2015 г.
Об альтернативе Application.ProcessMessages для TWebBrowser и разрыве стека выполнения
При использовании TWebBrowser существуют две неприятности, во-первых, это сам TWebBrowser =), а во-вторых, это Application.ProcessMessages, который необходимо выполнять чуть ли не на каждое действие (загрузить документ, сменить режим редактирования и т.п).
Использование Application.ProcessMessages может вызывать неожиданные проблемы. Особенно это актуально, когда используются оконные windows сообщения для разрыва стека выполнения. Но нашелся способ, которое позволяет не выбирать все сообщения из очереди. На первый взгляд, решение даже работает, однако буду рекомендовать никогда его не использовать и всегда использовать Application.ProcessMessage и об этом ниже.
Очевидно, что WebBrowser обрабатывает какие-то сообщения. Но поиск их казался гиблой идеей. В действительности оказалось, что ни так все плохо. С помощью Window Detective было обнаружено, что в момент загрузки происходит подозрительная посылка сообщений окну с именем класса 'Internet Explorer_Hidden'. Решил проверить и выбрал из очереди оконных сообщений в момент загрузки документа сообщения предназначенные только этому окну. К моему удивлению - все заработало.
Использование Application.ProcessMessages может вызывать неожиданные проблемы. Особенно это актуально, когда используются оконные windows сообщения для разрыва стека выполнения. Но нашелся способ, которое позволяет не выбирать все сообщения из очереди. На первый взгляд, решение даже работает, однако буду рекомендовать никогда его не использовать и всегда использовать Application.ProcessMessage и об этом ниже.
Очевидно, что WebBrowser обрабатывает какие-то сообщения. Но поиск их казался гиблой идеей. В действительности оказалось, что ни так все плохо. С помощью Window Detective было обнаружено, что в момент загрузки происходит подозрительная посылка сообщений окну с именем класса 'Internet Explorer_Hidden'. Решил проверить и выбрал из очереди оконных сообщений в момент загрузки документа сообщения предназначенные только этому окну. К моему удивлению - все заработало.
 |
| Сообщения получаемые окном IE |
Вообщем вот заготовка кода:
TMyWebBrowser = class(TWebBrowser) protected procedure WBProcessMessage; procedure InternalSetValue(const AValue: string); public procedure SetValue(const AValue: string); // Входная точка в примера procedure WaitWB; end; function EnumWindowsToFindIEHiddenProc(AHandle: HWND; AParam:NativeInt): boolean; stdcall; var IEHiddenHandle: Hwnd; implementation procedure TMyWebBrowser.SetValue(const AValue: string); begin InternalSetValue(AValue); // выполняем каким либо способом присваивание разметки WaitWB; // Ждем завершение загрузки документа. FooFunction; //Какой то функционал для работы которого необходим полностью загруженные html документ. end; procedure TMyWebBrowser.WaitWB; begin //Как то так обычно выглядит ожидание пока документ полностью не загрузиться while HTMLDocument2.readyState <> 'complete' do begin WBProcessMessage; // выбираем только нужные сообщения //Forms.Application.ProcessMessages; // выбираем все сообщения из очереди end; end; procedure TbtkHTMLEditor.WBProcessMessage; var msg: Windows.tagMSG; processID : THandle; begin IEHiddenHandle := 0; processID := GetCurrentProcessId; if EnumWindows(@EnumWindowsToFindIEHiddenProc, processID) then // �щем хендл окна IE в нашем процессе перебирая все окна if IEHiddenHandle <> 0 then // Проверяем найденный хендл валидный if PeekMessage(msg, IEHiddenHandle, 0, 0, PM_REMOVE) then // извлекаем из очереди оконных сообщений все сообщения для окна IEHiddenHandle begin Windows.DispatchMessage(msg); // Передаем извлеченные сообщения окну IE end; end; function EnumWindowsToFindIEHiddenProc(AHandle: HWND; AParam:NativeInt): boolean; var processId: NativeInt; classbuf: array[0..255] of Char; const IEWndClassName = 'Internet Explorer_Hidden'; begin result := true; if Windows.GetWindowThreadProcessId(AHandle,@processId) <> 0 then begin if AParam = processId then begin GetClassName(AHandle, classbuf, SizeOf(classbuf)); if lstrcmp(@classbuf[0], @IEWndClassName[1]) = 0 then begin IEHiddenHandle := AHandle; result := false; end; end; end; end;
Код на скорую руку, проверялся с IE 9-10 в Windows 7-8. Но в данном случае я избегаю слова "решение", тут больше подходит - "грязный хак". На самом деле, если у вас есть проблема того, что внезапный ProcessMessages нарушает строгий порядок ваших вызовов, то проблема не в ProcessMessages. ProcessMessages это данность архитектуры Windows и VCL. Если посылаете оконное сообщение, то будьте готовы, что оно может быть извлечено раньше, чем вы предполагаете. Например, из окна посылаем себе же сообщение WM_Close. Сообщение извлекается вот таким неожиданным ProcessMessages еще до раскрутки стека выполнения, который вызвал посылку этого сообщения. В результате дальнейшая раскрутка стека выполнения пойдет по освобожденным объектам, так как на WM_Close будет убито родительское окно и все дети на нем.
Подобные проблемы не решить изъятием вызовов ProcessMessages. Любой модальный диалог нарушит подобный не очень хитрый план. Для избегания подобной проблемы нужно использовать другие подходы. Мы, например, подобные проблемы решаем так называемыми контекстами асинхронного выполнения и подсистемой асинхронных команд. Говоря "асинхронные команды", я не подразумеваю много-поточное выполнение, а только разрыв стека выполнения. Что и происходит, когда посылаем в свой же поток оконное сообщение.
Вся суть в том, что асинхронные команды - это надстройка над механизмом оконных сообщений, позволяющая передавать в качестве сообщений объекты, а контекст - это состояние системы, определяющее возможность исполнения этого объекта.
Таким образом, асинхронная команда - это объект, который посылается в очередь сообщений, сообщением WM_AsyncCommand, где в качестве параметра указатель на объект. При извлечении сообщения WM_AsyncCommand из очереди сообщений, у объекта асинхронной команды вызывается обработчик, который и исполняет полезный код. Асинхронная команда принадлежит контексту. Контекст создается при запуске приложения. Если на момент извлечения асинхронной команды из очереди сообщений контекст заблокирован, тогда асинхронная команда перемещается в особый буфер команд, где дожидается разблокировки контекста. Все что осталось, это заблокировать контекст на момент начала роста стека вызовов, в котором могут посылаться команды, имеющие возможность порушить стек выполнения:
Context.Lock;
try
AnyUserAction;
finally
context.Unlock;
end;
Выше я приводил пример с WM_Close. Для этого мы используем TFormCloseAsyncCommand = class(TAsyncCommand). Ко всему прочему, контексты могут быть вложенными, а команды имеют фьючеры для возможности их отмены. Но это явно не вопрос темы текущей статьи (если кому интересно, то могу накидать шаблон кода и варианты использования в отдельной статье).
Вернемся к "грязному обходному пути" и оставим в стороне вопрос о том, что ProcessMessages - данность и не является безусловным злом. И тем не менее выборочная диспетчеризация сообщений для класса "Internet Explorer_Hidden" - сомнительный путь:
1. Данный вопрос никак не документирован. В MSDN мне попадался только код вида while (browser.IsBusy){System.Windows.Forms.Application.DoEvents();} .
2. "Решение" не проверялось на всех возможных версиях IE и Windows.
3. Нет гарантии, что мы обрабатываем все нужные сообщения.
4. В будущем архитектура WebBrowser может измениться и данный подход уже может не работать.
5. Извлекая только определенные сообщения, мы можем нарушить порядок обработки сообщений
Подписаться на:
Сообщения (Atom)