Как и обещал, выкладываю материалы со своего выступления на сегодняшней User Group в Ижевске. Надеюсь что всем понравился мой рассказ про WCF REST Services и Windows 7 Federated Search. Лично я получил ни с чем не сравнимое удовольствие.
Конструктивная критика принимается в комментариях J.
Смотрю на список зарегистрированных на 11 встречу User Group в Ижевске. У всех, кроме меня личная страничка пустая. Возникает вопрос, зачем? Зачем ребята, которые поддерживают ресурс сделали для каждого свой узел? Лишний ресурс, куда они будут публиковать свои записи, вроде бы никому не нужен. RSS репостинг конечно дело хорошее, но зачем тратить ресурсы на поддержку кучи пустых сайтов, на которых ничего нет?
Может быть стоит ограничиться встречами, а статьи просто подхватывать из RSS, который указал пользователь.
В общем, не понимаю я …
Дорогие дети. Не ищите меня больше на 38 параллели, я перепрятался.
Купите ещё ящик таких бутылок, как я вам прислал, и бросьте обратно в море.
Ваш отец, капитан Грант.
Собственно сабж говорит сам за себя. Меня достал «необыкновенно удобный» хостинг, называемый ayola.net. Хоть и бесплатный, но жутко неудобный как с точки зрения пользователя, так и с точки зрения технической. Поддерживать свой вариант wordpress на нем, уже не очень хочется. Кроме того, после последнего обновления, оказалось что версия PHP на которой работает последний WP и версия на хостинге несколько отличны. В связи с этим, там возникли значительные косяки с кодировками, которые мне разрешить так и не удалось.
Еще сегодня проскочила новость, что MS решила закрыть блоги Live Spaces, предлагая пользователям безболезненно перейти на wordpress.com. Я попробовал настроить там блог под себя, мне понравилось. Wordpress.com стал действительно удобным сервисом для размещения своих записей. Думаю что проблем с хостингом от автора продукта должно быть значительно меньше (хотябы обновления ставить не надо руками). В той же новости говорится, что Live Writer будет теперь ориентироваться на wordpress, что на самом деле не может не нравится. Я не буду обсуждать решение MS, может это шаг в сторону PHP, может это просто экономия денег на неприбыльном продукте, это в конечном счете не важно.
В итоге, блог heeepi.zx6.ru я постепенно закрою, сейчас настроил там редирект на новый блог, так что не ругайтесь, если вас перебросит на heeepi.wordpress.com.
Я не капитан Грант, поэтому оставлю несколько ссылок, где меня искать.
http://heeepi.wordpress.com/ - Это собственно новый блог на основе wordpress.
http://heeepi.livejournal.com/ - Это моя уютная ЖЖшка.
http://heeepi.blogspot.com/ - Это блог на blogspot. Мало ли, кто-нибудь и там пишет и читает J
http://heeepi.posterous.com/ - Это блог на posterous.com, откуда собственно рассылаются все записи.
http://11035.ineta.ru/blogs/default.aspx - Это кростпост на ineta.ru.
Фразы про жизнь самурая.
Возможно некоторые идеи вы возьмете себе на «вооружение».
Не мое, взято отсюда http://office.microsoft.com/ru-ru/help/HA010336218.aspx
Столкнулся с интересной ситуацией при работе с потоками в WCF. И как всегда спешу поделиться J.
Для некоторых ошибок WCF, например, ошибке MessageSecurityException реконмендуется пересоздавать клиентский проксик. При этом, существует несколько реализаций надежных прокси-классов, которые пересоздают и открывают заново коммуникационный канал. Ситуация вроде бы очевидная и имеет простое решение:
1. Обернуть прокси-класс с помощью еще одного проксика или другой обертки (я использую Spring.NET для этого), которая будет управлять временем жизни и состоянием клиентского проксика (есть еще вариант с работой непосредственно с каналом без использования автогенерируемого прокси-класса).
2. Соответственно при выполнении метода отлавливать нужные типы ошибок, пересоздавать реальный класс проксика и вызывать метод повторно с теми же аргументами.
Если пункт 1 в принципе понятен, то в пункте 2 могут быть проблемы связанные с аргументами метода.
В момент второго обращения аргументы могут стать невалидными. Пример таких аргументов – потоки. При первой отправке сообщения поток читается для сериализации. Так как поток сериализуется, начиная с текущей позиции, то при втором запросе уйдет пустой поток. Если конечно перед этим не сбросить его Position в 0.
Однако тут придется привязаться к DataContract, поскольку потоки могут не быть непосредственным контрактом данных, а содержаться как поле одного из контрактов. Как еще один вариант решения проблемы – прикручивать свой сериализатор, который сам будет уметь сбрасывать потоки в ноль, а потом отдавать стандартному DataContractSerializer.
Сегодня, зайдя в систему я ужаснулся чистому рабочему столу с дефолтными ярлыками. Слетел профиль пользователя. Когда я полез в папку C:\Users\ то обнаружил там папки TEMP и TEMP.<GUID>. На эти папки теперь по видимому Windows ссылалась теперь. Разбираться почему так произошло как то времени не было, поэтому стал сразу искать решение в инете. Как ни странно нашел достаточно быстро вот тут.
Инструкция достаточно простая:
1. Создаем еще одного администратора компа.
2. Перегружаем машину, заходим под созданным администратором.
3. Удаляем/переносим папки C:\Users\<username>
4. Удаляем папки C:\Users\TEMP и, если есть, C:\Users\TEMP.<GUID>
5. Открываем Regedit и удаляем в ветке реестра "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ProfileList" ненужные профили.
6. Перезагружаемся и заходим от нужного пользователя. Папки C:\Users\<username> восстановятся, в них можно снова закинуть нужную инфу.
Некоторые настройки все таки восстановить не удалось. Такие как заставки на рабочем столе, языковые настройки, автозагрузку пользователей, меню Пуск и т.д. Видимо не поднялось все что должно было лежать реально в реестре.
Тот, кто работал когда-нибудь с Reflection в .NET, тот наверняка мучился, когда вставала задача, к примеру перебора или поиска типов. Нужно подгружать сборку в домен, после чего, вероятно, можно будет перебирать метаданные сборки. Почему «возможно» ? Потому что сборка может быть не загружена в домен, например из-за зависимых сборок, которые должны быть загружены в домен ранее, или расположены где то «рядом» с приложением. Кроме того, говорят что производительность Reflection несколько слабовата. Правда это или нет, другой вопрос, я натыкался только на упоминания о том, что выполнение кода через Reflection медленней в 3-4 раза (отсюда).
А недавно я наткнулся на одно незначительное упоминание о такой штуке, как Common Compiler Infrastructure: Metadata API.
Приведу просто выдержку с главной страницы codeplex, где этот проект лежит в исходниках:
Microsoft Research Common Compiler Infrastructure (CCI) is a set of libraries and an application programming interface (API) that supports some of the functionality that is common to compilers and related programming tools.
The CCI Metadata API allows applications to efficiently analyze or modify .NET assemblies, modules, and debugging (PDB) files. CCI Metadata supports the functionality of the .NET System.Reflection and System.Reflection.Emit APIs, but with much better performance. It also provides additional functionality that is not available in either .NET API.
Если в общем, то это подобие Reflection, только значительно производительней.
В дополнение к нему, есть другой проект на том же Codeplex - Common Compiler Infrastructure: Code Model and AST API.
The Common Compiler Infrastructure (CCI) is a collection of frameworks for working with .NET source code, assemblies, modules, and debug files. In part, CCI supports a more efficient version of the functionality provided by System.Reflection, System.Reflection.Emit, and System.CodeDom. However, CCI goes beyond those components to provide a unified framework for static analysis and rewriting of assembly metadata and code. CCI supports a broad range of scenarios, including:
· Compilers, which start with source code and transform it to .NET assemblies and modules.
· Static analysis tools, which analyze the contents of .NET assemblies.
· Rewriting tools, which add code or metadata to assemblies or modify existing code or metadata.
В кратце, это уже коллекция фреймворков для работы с исходниками, сборками, модулями и отладочной информацией. И вроде бы с их помощью работают такие вещи, как FxCop и Code contracts tool.
Посмотреть я решил в сторону работы с метаданными, вот что получилось. Сразу оговорюсь, что сравнивать с Reflection я тут не буду, тот, кто хочет, может сам написать такой же код на Reflection и проверить. Я не стал этим заниматься.
Итак, задачка:
По списку строк, содержащих имена фалов сборок получить:
1. Имя сборки.
2. Все типы, содержащиеся в этой сборке.
3. Все members типа: свойства, методы.
Вот такой код получился при использовании Cci. Просто и со вкусом…
MetadataReaderHost host = new PeReader.DefaultHost();
foreach (string assemblyName in references)
{
IAssembly assembly = host.LoadUnitFrom(assemblyName) as IAssembly;
if (assembly == null) continue;
string assname = assembly.Name.Value;
foreach (INamedTypeDefinition type in assembly.GetAllTypes())
{
if (type == null) continue;
string s = type.Name.Value;
foreach (IMethodDefinition method in type.Methods)
{
if (method == null) continue;
string m = method.Name.Value;
}
}
}
В списке references лежат имена файлов сборок по которым идет перебор. Для начала я натравил эту утилиту на примерно 30 сборок самого Cci, но результат в 300 мс, хотя и с небольшим разбросом мне почему то не понравился и я решил натравить на сборки в папке Microsoft.NET\Framework\v4.0.30319. В этой папочке конечно лежат не только .NET сборки, поэтому нормально обработать удалось только 112 сборок.
Мне кажется, что результат в 5 сек для 38 000 типов достаточно хорош. Интересно, каких результатов можно добиться с использованием Reflection?..
Завтра, 12 сентября 100000000 (256) день в году. А это значит, что завтра профессиональный праздник всех программистов и системных администраторов, ну в общем, то и всех IT-шников. Поэтому:
Поздравляю всех коллег с профессиональным праздником!!!
Я буду праздновать заранее в клубе Авиатор, где уже традиционно пройдет 256 Party. Уже в 4 раз … J
Число 256 = 2^8 — максимальное число количество чисел, которое можно выразить одним байтом. (Впрочем, любому ИТ-шнику это и так известно).
256 Party — это вечеринка, пропитанная настроением ИТ. В 2007 году мы впервые собрались в нашем городе, чтобы официально отпраздновать этот, тогда еще неофициальный, праздник. Праздник программистов, системных администраторов, тестировщиков — короче, всех специалистов в области информационных технологий.
Ребята на КатаемВместе.ru составили отличную классификацию велосипедистов-любителей.
1. Лось. Высшая ступень достижения велосипедиста. Выше только профики, но это уже не любительский ранг.
2. Булка. Довольно хорошая подготовка, рвёт многих.
3. Тесто (я - тесто). Булки делаются из теста. Толком неоформленный велосипедист, подающий надежды.
4. Покатушкины. В общем, тут все остальные велосипедисты, в основном неспешно катающиеся по городу, иногда вне его.
5. Поскрипулькины. Низшая каста велосипедистов, катаются по-малу, за велосипедом не ухаживают (ещё пока не видят нужды), поэтому он издаёт массу жалобных звуков.
На счёт стать лосем за год из теста - это конечно нереально. В лучшем случае можно стать сильной булкой))
Классифицирую себя как покатушкина. А Вы?
Никогда не приписывайте злонамеренности тому, что вполне может быть объяснено глупостью.
Never attribute to malice that which can be adequately explained by stupidity
Надо бы попробовать.
