Релиз SPCAF Contrib

Для тех кто не в курсе что такое SPCAF. SPCAF – аббревиатура SharePoint Code Analysis Framework, инструмент позволяющий проводить проверки кода решений SharePoint и собирать полезные метрики. SPCAF состоит из четырех компонент: SPCop, SPMetrics, SPInventory, SPDependency. Первый компонент распространяется отдельно и бесплатно. Весь SPCAF стоит 2500 евро (очень дорого).
SPCAF создавался для крупных компаний, которые работают с кучей подрядчиков, и для них очень актуальна проблема стабильности фермы в таких условиях. Проблемы, с которыми программисты сталкиваются во время разработки, в базовом наборе правил SPCop адресованы очень слабо.
Поэтому мы решили создать набор правил для SPCop, чтобы облегчить процесс разработки решений и ловить многие проблемы до того, как они проявятся во время тестирования или промышленной эксплуатации. Также создали правила, которые подсказывают best pratices при разработке решений.
Кстати мы это:

Как использовать

1. Поставить SPCop из галереи расширений Visual Studio
image
2. Скачать spcafcontrib.dll и положить в папку C:\Program Files (x86)\SPCOPCE\
3. Запустить анализ в Visual Studio
image
4. Анализируйте результаты и настраивайте правила
image

Заключение

Сайт SPCAF - http://www.spcaf.com/
Ссылка на сайт проекта - http://spcafcontrib.codeplex.com/
Презентация - http://www.slideshare.net/gandjustas/sharepoint-code-quality
Ставьте, используйте, оставляйте feedback на сайте проекта.


Поиск в приложениях SharePoint. Часть 2.

Untitled

Первая часть этой серии была написана примерно полтора года назад, после этого появился SharePoint 2013, в котором добавили очень много возможностей для использовании поиска в решениях. Но недавний опрос в сообществе (https://www.facebook.com/groups/sharepointrussian/permalink/514677285314072/?stream_ref=2) показал, что наиболее популярной версией до сих пор является SharePoint 2010.

В первой части я рассказывал как использовать стандартные веб-части поиска в SharePoint 2010, теперь расскажу как с помощью небольшого объема кода получить максимальное мощное решение для создания порталов.

DataFormWebPart

Стандартная веб-часть SharePoint позволяет использовать различные источники данных и формировать разметку с помощью XSL. Источник данных описывается с помою класса наследника System.Web.UI.DataSourceControl. В разметке страницы или .webpart файле можно указать какой DataSource использовать в веб-части.

SearchDataource

Для начала создадим DataSource, который возвращает результаты поискового запроса. На MSDN есть инструкция по созданию класса DataSource - http://msdn.microsoft.com/RU-RU/library/92e191zc(v=vs.90)

public class SearchDataSource: DataSourceControl
{
    protected override DataSourceView GetView(string viewName)
    {
        return new SearchDataSourceView(this);
    }

    public string QueryText { get; set; }

    public string SelectProperties { get; set; }        
}
Основная работа делается в классе SearchDataSourceView, наследнике DataSourceView.
class SearchDataSourceView: DataSourceView
{
    SearchDataSource dataSource;

    public SearchDataSourceView(SearchDataSource dataSource): base(dataSource,"")
    {
        this.dataSource = dataSource;
    }

    public override bool CanPage
    {
        get
        {
            return true;
        }
    }

    public override bool CanSort
    {
        get
        {
            return true;
        }
    }

    public override bool CanRetrieveTotalRowCount
    {
        get
        {
            return true;
        }
    }

    protected override System.Collections.IEnumerable ExecuteSelect(DataSourceSelectArguments arguments)
    {
        var query = GetQuery(arguments.SortExpression);

        query.StartRow = arguments.StartRowIndex;
        query.RowLimit = arguments.MaximumRows;

        var results = query.Execute()[ResultType.RelevantResults];
        arguments.TotalRowCount = results.TotalRows;
        return results.Table.DefaultView;
    }

    private KeywordQuery GetQuery(string sortExpression)
    {
        /* omited for clarity */
    }
}

Основной метод класса – ExecuteSelect, он должен возвращать IEnumerable, поддерживающий TypeDescriptor, например DataView. Про TypeDescriptors я писал ранее – http://gandjustas.blogspot.ru/2011/08/blog-post_22.html. Класс DataSourceView может поддерживать разбиение на страницы и сортировку, это определяется свойствами, которые я переопределил в начале.

Код создания запроса:

private KeywordQuery GetQuery(string sortExpression)
{
    var query = new KeywordQuery(SPContext.Current.Site);
    query.QueryText = this.dataSource.QueryText;
    query.ResultTypes = ResultType.RelevantResults;

    if (!string.IsNullOrEmpty(this.dataSource.SelectProperties))
    {
        query.SelectProperties.Clear();
        foreach (var property in this.dataSource.SelectProperties.Split(','))
        {
            query.SelectProperties.Add(property.Trim());
        }
    }

    if (!string.IsNullOrEmpty(sortExpression))
    {
        query.SortList.Clear();
        foreach (var sort in sortExpression.Split(','))
        {
            if (sort.EndsWith(" DESC"))
            {
                query.SortList.Add(sort.Substring(0, sort.IndexOf(" DESC")), SortDirection.Descending);
            }
            else
            {
                query.SortList.Add(sort, SortDirection.Ascending);
            }
        }
    }

    return query;
}

Этот код заполняет базовые параметры, запрашиваемые свойства и параметры сортировки.

Настройка веб-части

Добавляем веб-часть на страницу

image

 

Далее заменяем DataSource и вставляем identity transform

image

Директиву Register нужно вставлять прямо в раздел DataSource. В XSL надо вставить Identity Transform, чтобы получить данные в виде XML :

<xsl:stylesheet version="1.0"  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output indent="yes"/>
    <xsl:template match="/"  >
        <xmp>
            <xsl:copy-of select="." />
        </xmp>
    </xsl:template>
</xsl:stylesheet>

В результате получим такое:

image

Далее можно скопировать полученный XML и сделать необходимый XSL в Visual Studio или в SharePoint Designer.

Например так:

image

Создаем пакет решения

Чтобы завернуть полученный результат в WSP надо экспортировать веб-часть с сайта. Получившийся .webpart файл включить в решение. Это все.

Причем можно деплоить сборку с DataSource в farm solution, а .webpart файлы в sandbox.

Для конкретных задач можно расширить функционал:

  • Добавить обработку параметров DataSource. Параметры позволяют использовать значения QueryString, связи между веб-частями и другие внешние факторы. Также можно создавать свои параметры.
  • Сделать аналогичный DataSource для RefinementResults, чтобы получать статистику. Что очень часто нужно для главной страницы порталов.

Если вам нужна веб-часть в одном экземпляре (что бывает чуть менее, чем всегда), то можно не париться с сохранением .webpart и ковырянием в SharePoint Designer. Достаточно просто сделать наследника DataFormWebPart и переопределить метод GetDataSouce. При этом можно также переопределить XSL, чтобы он всегда указывал на файл в виртуальной файловой системе. Это значительно облегчит сопровождение решения.

Заключение

Как обычно исходники можно найти на http://spsamples.codeplex.com. Также сделал релиз: https://spsamples.codeplex.com/releases/view/117762.

Качайте, смотрите, изучайте, интегрируйте в свои решения.



Восприятие SharePoint

Пост-перевод http://veroniquepalmer.com/2014/01/16/your-sharepoint-perception/

Не правда ли, что мы склонны видеть мир через через призму нашего опыта, но не так, как на самом деле. Возьмите SharePoint например ...

  • Если вы пришли из области автоматизации работы, то SharePoint всего лишь движок workflow.
  • Если вы пришли из области работы с документами, то SharePoint всего лишь хранилище документов с метаданными.
  • Если вы пришли из области веб-дизайна, то SharePoint обязательно надо брендить.
  • Если вы пришли из области разработки, то SharePoint обязательно требует кастомизации.
  • Если вы пришли из области обработки данных, то SharePoint всего лишь панели монтиторинга.
  • Если вы пришли из области обучения, то SharePoint можно использовать только после обучения.
  • Если вы пришли из области управления, то SharePoint работает только если есть регламенты.
  • Если вы пришли из области бизнес-анализа, то SharePoint требует годы планирования.
  • Если вы пришли из области социальных медиа, то SharePoint можно использовать только с версии 2013.
  • Если вы пришли из области разработки расширений, то SharePoint может работать только вашим самым продаваемым продуктом.

И так можно продолжать очень долго.

Это человеческая природа, думать, что наш путь является единственным Но это не так, это лишь один из способов. Нельзя фокусироваться на одной вещи, так как SharePoint это очень большая платформа и умеет много чего еще.

Давайте посмотрим на это другим взглядом. В первую очередь взглядом потребителя. Например, если вы не используете личные узлы, это не значит что в них нет ценности для других. Расширяйте свое видение платформы и станете более более ценным специалистом.

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

perception



Нелегкая судьба Best Practices

НеНаступи_small

(картинка отсюда)

Именно такое отношение к лучшим практикам встречается чуть менее, чем всегда. Можно подумать что не все знают про эти best practices. Но как только человек делает что-то не так, ему сразу же указывают как делать правильно. И что после этого происходит? НИЧЕГО. Только единицы начинают делать правильно после того как узнают про best practices, остальные продолжают жрать кактус и плакать о плохих менеджерах\вендорах\подрядчиках\клиентах\государстве.

Почему так происходит?

  1. Люди последовательны. Если человек уже что-то делает одним образом, то существует психологический барьер делать по-другому.
  2. Люди избегают потерь. Потому что в "другой путь" уже вложено много сил, и есть психологический барьер отказаться от этих "результатов" и пойти правильным путем.
  3. Люди не хотят быть неправыми. Есть у людей такой психологический механизм, который рационализирует любое нерациональное поведение. Даже если первоначальные действия были просто ошибкой, то человек придумает 100500 причин почему этот путь был самым правильным.

Вывод

Если кто-либо (в том числе Вы) не следуете best practices, то для этого почти никогда нет никаких рациональных причин. Когда следующий раз вы узнаете про лучшие практики в вашей области и подумаете "это мне не подойдет потому что...", остановитесь, и еще раз взгляните на картинку в начале поста.



Опыт работы не имеет значения

Знаете ли вы, что за все годы существования индустрии разработки ПО не было выявлено сильной связи межу опытом работы и качеством кода и продуктивностью сотрудника?

В 1968 году было проведено исследование продуктивности работы программистов (источник), которое показало что соотношение лучших и худших программистов составило:

  • 20:1 по времени написания кода
  • 25:1 по времени отладки кода
  • 10:1 по скорости работы программы
  • 5:1 по объему кода

Эти цифры в разных вариациях уже все видели. А вот тот факт, что исследование проводилось на программистах, имевших в среднем 7 лет опыта разработки с небольшими отклонениями, не знает никто.

Но это было давно и в исследовании куча ошибок...

Аналогичные исследования повторялись другими группами ученых на протяжении 30 лет:

  • Curtis, Bill. 1981. "Substantiating Programmer Variability." Proceedings of the IEEE 69, no. 7: 846.
  • Mills, Harlan D. 1983. Software Productivity. Boston, Mass.: Little, Brown.
  • DeMarco, Tom, and Timothy Lister. 1985. "Programmer Performance and the Effects of the Workplace." Proceedings of the 8th International Conference on Software Engineering. Washington, D.C.: IEEE Computer Society Press, 268-72.
  • Curtis, Bill, et al. 1986. "Software Psychology: The Need for an Interdisciplinary Program." Proceedings of the IEEE 74, no. 8: 1092-1106.
  • Card, David N. 1987. "A Software Technology Evaluation Program." Information and Software Technology 29, no. 6 (July/August): 291-300.
  • Boehm, Barry W., and Philip N. Papaccio. 1988. "Understanding and Controlling Software Costs." IEEE Transactions on Software Engineering SE-14, no. 10 (October): 1462-77.
  • Valett, J., and F. E. McGarry. 1989. "A Summary of Software Measurement Experiences in the Software Engineering Laboratory." Journal of Systems and Software 9, no. 2 (February): 137-48.
  • Boehm, Barry, et al, 2000. Software Cost Estimation with Cocomo II, Boston, Mass.: Addison Wesley, 2000.

Они также показали разницу между худшими и лучшими в разы (хотя конечно меньше чем в 25 раз). И также не показали никакой связи между продуктивностью и опытом работы.

Что это значит?

С 1968 года в разработке улучшилось буквально все: языки, фреймворки, инструменты, а также программированию теперь обучают несколько лет в вузе. Тем не менее продуктивность программистов как отличалась в разы 30 лет назад, так и отличается сегодня.

Это наводит на мысль, что есть некоторый икс-фактор, не связанный с опытом, который отличает хорошего программиста от плохого. На сегодняшний момент нет единого мнения что это за фактор. Одни говорят что это умение планировать свою работу и “видеть” структуру кода еще до того, как код написан. Другие говорят, что самые продуктивные программисты те, кто умеет быстро выдавать видимый результат. Мои личные наблюдения говорят о том, что лучше всего пишут код те, кто умеет читать код.

И что теперь делать?

Если отбросить этическую сторону вопроса, то надо уволить всех низко продуктивных программистов, невзирая на опыт. Серьезно, учитывая факты выше, можно набрать небольшую команду относительно недорогих, но высоко продуктивных, программистов. И это будет в разы выгоднее чем держать штат опытных специалистов.

Еще один вывод, который немного противоречит логике, но часто встречается на практике: программист не станет более продуктивным, получив годы опыта. Единственный способ улучшить продуктивность и качество кода программистов – проводить целенаправленное обучение и тренировку .

Последнее, но не менее важное - надо сильно пересмотреть методику найма программистов. Вместо отсева по ключевым словам в резюме и задач на логику надо писать код, желательно в “лабораторных” условиях, чтобы можно было отследить продуктивность и качество кода.

Заключение

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