4я встреча IT Talk в Харькове

Был вчера на IT Talk. Мероприятие привлекает довольно много людей и развивается. Теперь уже докладчики - не приглашенные "варяги", а те посетители, кто изъявил желание о чем-то рассказать. Но все-равно у меня лично целый ряд вопросов/замечаний:

• Так и не понял для себя: кто является целевой аудиторией (чисто визуально половина аудитории - студенты и интересующиеся, а половина - "представители индустрии"). При этом доклады по большому счету не ориентированы ни на одну из этих групп: для одних, пожалуй, чересчур сложно, а для других в основном беспредметно.
• Второй (или даже третий - точно не припомню) раз хожу туда и так и не пойму цели мероприятия (может, правда, это я лично ожидаю от него слишком многого). Мне бы виделось, что если мероприятие массовое, то и цель у него должна быть понятна (и близка) этим самым массам. А по факту получается полигон, на котором очень ограниченный круг товарищей "демонстрирует шары". Причем конструктивизма в большинстве высказываний ни на грош - они имеют целью либо показать какой говорящий "классный, всезнающий и профессиональный" или что докладчик "ничего не смыслит в колбасных обрезках".
• Организация: если мы хотим дискуссию (а судя по названию мероприятия мы таки ее хотим), то нужно либо организовывать круглый стол (с ограниченным числом говорящих) - наподобие "Свободы слова" или "К барьеру", либо сокращать количество участников. Ибо дискуссия во время лекции или после оной - это балаган (тем более в отсутствии ведущего).
• Тема должна быть более конкретной и конструктивной. А не: "Я тут вам сейчас расскажу что-нибудь (а вы подеретесь из-за деталей, о которых я намеренно не говорил)". Кто-то может поделиться опытом? Пожалуйста! Только нужно рассказывать об условиях, в которых этот опыт получен: размер проектной команды, ее квалификация, сложность проекта, каков заказчик (как он участвует в процессе), есть ли бюрократия и т.п. - с деталями (ведь именно они зачастую и делают разницу между номинально похожими проектами колоссальной).

С одной стороны, конечно, приятно, что в городе есть какое-то публичное общество разработчиков, организуются какие-то мероприятия, но осадок остается после каждой такой встречи - время было потеряно впустую (ну или почти впустую). Вспоминается фраза из одной песни: "Иди тусуйся!" - в этом по-моему (на данном этапе) и заключается суть мероприятия. А могло бы быть полезным. Хочется надеяться таким оно когда-нибудь станет (если кризис нас всех не прикончит ;-) ).

svn:keywords и Unicode

Давно хотел, чтобы все было как у людей: в каждом файле в заголовке - номер последней ревезии, в которой этот файл изменялся, автор изменений и дата. Такой заголовок особенно полезен для sql - скриптов, которые создают хранимые процедуры и пользовательские функции (в общем: логику), ибо позволяет заглянув в базу сразу же узнать кто и когда менял тот или иной объект.

Для тех, кому повезло использовать SVN для контроля за версиями (мне, как раз повезло), есть, казалось бы, простой и безболезненный способ - svn:keywords. Выставляем для sql (или любого другого) файла это свойство (см. руководство по TortoiseSVN здесь), и в файле используем ключевые слова, например так:

-- $Rev$

-- $Author$

CREATE PROCEDURE ...

и вот оно счастье...

Но не тут-то было! Проблема появляется оттуда, откуда ее никто не ждал. SQL Server Management Studio по-умолчанию сохраняет все файлы в формате Unicode. Причем не просто Unicode, а UTF-16 с byte-order mark. Точно также поступают и некоторые библиотеки (в частности SMO). А SVN помечает файлы в этой кодировке как имеющие mime-type: octet-stream/application - т.е. фактически считает их бинарными и, соответственно, никакой подстановки ключевых слов не делает. Обидно, тем более, что файл-то текстовый.

Поиск в Google дает мало толковых результатов: да, есть такая проблема, можно попытаться обойти (и то, сайт недоступен, можно почитать только из кэша Google). И только покопавшись еще глубже, можно обнаружить вот это: SVN поддерживает Unicode, но текстовым будет считаться только файл в кодировке UTF-8 (а не UTF-16 или UTF-32) - соответсвенно и ключевые слова будут работать только если файл в одной из однобайтовых кодировок (верх "крутизны" - та самая UTF-8).

Ну лучше уж так, чем никак. В результате:

• быстренько сделал утилиту по переконвертированию файлов в кодировку UTF-8 (зачем пользоваться shareware, если самом сделать - дело 5ти минут? ;) ). Исполняемый файл здесь, исходник (если кому интересно) здесь.
• сделал так, что dbbuilder теперь сохраняет все скрипты в кодировке UTF-8

Надеюсь кому-нибудь поможет.

AlexS

Пару слов о Sql Server Management Objects (SMO) (v.9 и v.10)

На днях повысил версию SMO. Причин на то было две: категорически не устраивала работа SMO v.9 с полнотекстовыми индексами и хотелось добавить поддержку SQL Server 2008 (что в любом случае требовало SMO v.10). Но обо всем по-порядку.

Когда появилась настоятельная необходимость добавить в dbbuilder поддержку полнотекстовых объектов (каталогов и индексов), то первым (вполне очевидным) решением было обратиться к SMO и при генерации скриптов сохранять еще пару типов объектов. При создании базы проблем возникнуть не должно было. Но на деле оказалось, что в SMO v.9 есть такая "особенность": при создании скрипта для полнотекстового индекса в него всегда добавляется USING [<исходная БД>]. Причем эта "фича" гнездится в самом коде SMO (спасибо, Reflector) и на нее не влияют ScriptingOptions равно как и порядок создания скриптов. В результате мы всегда получаем скрипты, которые непригодны к использованию сразу после генерации и требуют ручной "доработки напильником" (удаления USING), что нехорошо.

Поругавшись про себя решил посмотреть: а как обстоит дело в SMO v.10? Оказалось что хорошо обстоит: баг (или фичу) починили (или убрали) и теперь скрипты получаются такие, какие и дОлжно. В ходе тестовых запусков обнаружил, что задачи по генерации скриптов/созданию базы стали выполняться быстрее. Решил проверить и с еще большим удивлением обнаружил, что таки да, таки что-то произошло: SMO v.10 работает значительно быстрее v.9. Сравнительные (усредненные по двум запускам) результаты для некоторой базы данных (141 таблица, 194 хранимых процедуры, 2 триггера, 10 пользовательских функций и 5 представлений) приведены в таблице ниже.

	SMO v.9	SMO v.10
Создание новой (пустой) базы	0:24	0:20
Генерация скриптов	8:35	0:58

Признаюсь: меня сильно впечатлило увеличение скорости генерации скриптов почти на порядок.

А теперь ложка дёгтя: SMO как-то очень забавно работает с SQL Server Express. Если я попытаюсь через SMO обратиться к полнотектовому каталогу базы данных, работающей на SQL Server Express with Advanced Services (в котором есть Full-text search), то получу исключение "SQL Server Express не поддерживает Full-Text". Отлично, просто отлично! Но этот самый Full-text, к счастью, работает вне зависимости от того, что на этот счет "думает" SMO.

Надеюсь кому-то поможет.

AlexS

Начало

Сегодня я решил положить начало блоговой эры в моей жизни. Формальным поводом стало решение создать проект с открытым исходным кодом - dbbuilder. Хотя и без этого в последнее время у меня периодически возникает желание записать что-то, с чем приходится сталкиваться в своей профессиональной деятельности - для себя (для истории), ну и может еще кому-нибудь пригодится.

Так что начнем.