На последней встрече томского .NET сообщества MccTomskCamp выступил с докладом на тему «Continuous Testing в .NET». Все прошло не очень гладко, поэтому доклад получился слегка сумбурным. В общем, я вас предупредил :) Приятного просмотра.



Презентация (не нашел, как встроить): www.authorstream.com/Presentation/alexidsa-1463353-continuos-testing-net

P. S. Меня не покидает ощущение, что я приврал, когда рассказывал о статическом и динамическом анализе. Поправьте меня в комментариях, если что.

 

LINQ — удобная, красивая, но при этом довольно коварная абстракция. Самые неожиданные вещи обычно происходят на стыке какой-либо реализации LINQ и LINQ To Objects. Сегодня на одном примере я рассмотрю совместную работу LINQ To Entities (Entity Framework) и LINQ To Objects.

 

Давным-давно вышел ADO.NET 2.0, а вместе с ним и сборка System.Transactions, содержащая класс TransactionScope — путеводитель в мир легкого и непринужденного использования транзакций. В сегодняшней статье я рассмотрю некоторые нюансы, возникающие при использовании этой дырявой, но такой симпатичной абстракции.

Недавно мне понадобилось выполнить следующий код (представлен в максимально упрощенном виде):

public void Start()
{
    using (var transactionScope = new TransactionScope())
    {
        ...
        GetOrCreateCompany(someValue);
        ...
        transactionScope.Complete();
    }
}

private Company GetOrCreateCompany(string companyName)
{
    var company = _companiesRepository.GetCompany(companyName); //простая выборка из таблицы по названию; если компания не найдена - возвращается null
    if (company == null)
        company = _companiesRepository.Add(companyName);
    return company;
}

Код этот выполнялся в многопоточной среде, где каждый поток на вход получал метод Start (а значит у каждого потока была своя транзакция).

У этого, казалось бы, простого кода есть несколько нюансов, о которых и пойдет речь под катом.

Хабралюди, подсобите, пожалуйста, с задачкой.

На входе имеем набор объектов с разным количеством свойств. По каждому свойству выполняется полнотекстовый поиск, на выходе которого имеем релевантность. Задача: подсчитать суммарную релевантность объектов.

Самое просто решение, подсчет суммы релевантностей всех свойств объекта, не подходит из-за того, что у объектов может быть разное количество свойств. Я склоняюсь к примерно такой формуле:
итоговая_релевантность_объекта = максимальная_релевантность_из_всех_свойств_объекта + средняя_релевантность_остальных_свойств_объекта. Но эта формула высосана из пальца. Наверняка, есть целый класс подобных алгоритмов. Подскажите, в каком направлении копать.

 

Ни для кого не секрет, что львиная доля проектов, связанных с Semantic Web, разрабатывается на Java. Фреймворки для работы с семантическими онтологиями не являются исключением: все основные проекты (Jena, OWL API, Sesame и т. д.) написаны именно на Java. Единственным серьезным представителем, использующим .NET, является фирма Intellidimension с продуктами RDF Gateway и Semantics.SDK.

В этой статье опишу свой опыт работы с вышеуказанными фреймворками и поделюсь результатами тестирования.

Несколько лет назад я окончательно и бесповоротно перешел на чтение технической литературы исключительно на английском. Это достаточно распространенный в IT'шных кругах подход, поэтому в этом посте я хотел бы поговорить не о причинах (которые в общем-то лежат на поверхности), а о следствии данного решения. Не о следствиях, а именно о следствии — о том, как я стал постоянным клиентом Amazon'а.

В этом посте я хотел бы поговорить о литературе по Web 3.0, точнее об одном из лучших ее представителей — книге «SEMANTIC WEB for the WORKING ONTOLOGIST».