Используйте Web Money - это очень удобно

вторник, 31 мая 2016 г.

Как преобразовать url в WEBDAV в Sharepoint.

Все время забываю, так как редко нужно. Работает для Sharepoint 2010 Адрес типа http://portal/it/docs/DocLib1/Forms/AllItems.aspx превращается в \\portal\DavWWWRoot\it\docs\DocLib1 - и легко открывается в проводнике.

понедельник, 7 марта 2016 г.

Документирование результатов внутренней разработки. Стоит ли рисковать?

Я думаю, что каждый хоть раз встречался с результатами внедрения внутренней разработки в компании. Это может быть и крупная самописная система и маленькое приложение для преобразования из одного формата в другой. Документирование таких разработок ИТ специалистами и разработчиками редко ведется в достаточном объеме и качестве. И это не только "злой умысел" разработчика написать систему, в которой разбирается только он (по понятным причинам), и не количество задач которыми его "завалило" начальство и пользователи. Зачастую это нежелание "творца" тратить время на написание "ненужной" бумажки. Тем более, что после написания документации, её необходимо регулярно обновлять вместе с доработками и изменениями системы. К чему приводит такая политика и какие риски она несет для предприятия? Первый риск - при увольнении команды разработки (разработчики частенько уходят в стартапы или их перекупают софтверные компании) развитие системы приостанавливается, а иногда систему приходится заменять. Это конечно крайний случай, но и его нужно иметь ввиду, планируя собственную разработку. В лучшем случае нанимаются новые разработчики и они в течении N месяцев разбираются с исходным кодом. Время зависит и от качества исходного кода и скорости найма новых сотрудников. При этом необходимо учитывать, что разработчики не очень любят копаться в чужом коде. При менее критичной ситуации из команды уходит тимлид или один из разработчиков. В этом случае разработка новой функциональности не прекращается, но существенно замедляется. Конечно вы можете возразить, что при увольнении необходимо потребовать от сотрудников описания их проектов и документацию на систему. И вы даже ее получите, но за две недели описать результаты 2-3 х лет работы, и не забыть при этом мелочи, на мой взгляд не возможно. Еще один риск - это отпуск или больничный разработчика. Если в его отсутствие система ломается и отсутствует документация, остальные участники проекта испытывают совершенно не нужную дополнительную нагрузку и стресс, пытаясь в сжатые сроки разобраться в коде и исправить ошибку или восстановить работоспособность системы после сбоя. Конечно документирование это не панацея, но при качественном документировании как части рабочего процесса компания снижает свои риски, сроки восстановления системы и время на адаптацию новых сотрудников. Мой опыт в этом вопросе: Используйте вики, желательно на простом и удобном движке. Добавление и оформление статьи не должно занимать много времени. Например, Sharepoint 2010 с его вики мы использовать не смогли - слишком сложный процесс добавления и редактирования. На первой странице зафиксируйте правила оформления исходного кода и документирования результатов работы. Очень удобно когда репозиторий и вики интегрированы с системой постановки задач (багтрекинга). Если интеграции нет, то договоритесь о том, что бы в каждой статье и каждом комите по задаче была ссылка на эту самую задачу. Заранее продумайте области видимости для сотрудников компании - в вики вы можете положить не только внутреннюю документацию ИТ, но и инструкции пользователей и справочную информацию. Вики поддерживает загрузку документов, но если у вас есть портал или иное хранилище для проектной документации правильнее складывать ТЗ и требования, а также мануалы и описания в папку по проекту. Ссылку на эту папку указывать в вики. Оформление результатов разработки по разделам (понятно должно быть любому сотруднику ИТ, не только программисту): 1. Что это? При описании достаточно одного абзаца. 2. Описание установки. Как поставить и где развернуто. Желательно пошаговая инструкция. 3. Подробное описание логики работы и интеграций. 4. Администрирование. (Как добавить шаблон/отчет/пользователя и т.п.) 5. Работа над ошибками. (В ходе эксплуатации выявляются типовые проблемы - в этом разделе необходимо описать как они решаются). 6. Где лежит исходный код. 7. Доработки. Не все разделы нужны для каждого проекта. Полнота документирования сугубо индивидуально, но я сторонник инструкций для тупых, это в значительной степени сокращает время затрачиваемое новым сотрудником на взятие системы на сопровождение. Надеюсь, эта статья поможет организовать или хотя бы задуматься о документировании проектов в вашей компании.

Новая публикация

Долгое время я не публиковал новых статей по технологиям, и забросил свой блог. Отчасти это было связано с тем, что я практически перестал разрабатывать и все больше занимался архитектурой и управлением разработкой. Времени на вдумчивые статьи не хватало, а про ерунду писать не хотелось. Сегодня совершенно случайно посмотрел на свое детище и увидел, что кто-то заходит и смотрит мои старые статьи. Посмотрев на это я решил опубликовать пару статей на темы которыми занимался. Возможно они помогут начинающим и не очень ИТ специалистам решить свои задачи. В своих статьях я хочу затронуть следующие темы: Автоматизация предприятия. Старая тема - нужен ли внутренний портал предприятию и что полезного, на мой взгляд, он должен делать. Личный кабинет. Управление разработкой. Если у читателей есть интерес к какой-то из тем в большей степени, пишите в комментариях, буду на них ориентироваться.

воскресенье, 30 сентября 2012 г.

Мониторим Sharepoint

Каждый из нас сталкивался с проблемами фермы. Куда смотреть, что бы понять почему ферма работает не стабильно, медленно или вообще не работает. Я предлагаю следующий перечень мест и действий: 0. Посмотрите монитором ресурсов нет ли проблем с ресурсами CPU, RAM, свободное место и очередь диска. Проверьте ping между серверами фермы (должен быть <1ms, не равен, а меньше) 1. Посмотрите состояние фермы в центре администрирования. 2. Посмотрите логи Sharepoint. 3. Посмотрите логи Windows. 4. Посмотрите состояние SQL сервера activity monitor'ом 5. Проверьте наличие deadlock профилировщиком SQL. Выясните их причины. 6. Профилируйте w3wp.exe - выясните, какие библиотеки и методы нагружают систему и приводят к медленной работе. Правилом хорошего тона является регулярный перезапуск служб (раз в сутки), а также написание и запуск прогревочных скриптов. Удачи.

вторник, 8 ноября 2011 г.

Рабочие процессы в Sharepoint

Коллеги, доброго времени суток!
Решил поделиться интересной информацией по рабочим процессам. Каждый, кто когда-либо сталкивался с рабочими процессами боролся с проблемой производительности. Хочу посоветовать следующие варианты решения:
1. Делайте рабочие процессы как можно меньше. От размера рабочего процесса зависит и время запуска и время компиляции (если это рабочий процесс из дизайнера или Nintex).
2. В принципе есть возможность компилировать рабочие процессы вручную скриптом. Это в значительной степени сократит время запуска первый раз. В этом случае вы получите две выгоды. Сократите время запуска и утечки памяти (при правильном подходе :)).
3. Не делайте рабочие процессы, которые запускают другие рабочие процессы сразу после запуска - время ожидания пользователя сильно возрастет.
4. Старайтесь использовать ожидание только на изменение элемента и ожидание на период, в остальных случаях система будет проверять тригер каждый раз.
5. Не используйте циклы - это прямая нагрузка на систему. Используйте машины состояний.
6. Таймер выполняющий рабочие процессы течет (на данный момент).
7. Первый сервис пак ограничивает размер (по количеству активити) стартующего рабочего процесса. Эту настройку можно изменить.

Удачи!

понедельник, 18 июля 2011 г.

Хорошая статья про разработку

http://habrahabr.ru/blogs/pm/124241/

вторник, 21 июня 2011 г.

Рабочие группы для неупорядоченного массива данных

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

среда, 8 июня 2011 г.

Sharepoint forever

После долгого перерыва решил продолжить этот блог. За прошедшее время было много проектов, технологий и не было времени. Буду как и раньше писать про проблемы и и варианты их решения.

среда, 19 мая 2010 г.

Настройка MOSS 2010 - учетные записи

Настройка учетных записей при установке Sharepoint 2010
Что там точно не указали:

svcSharepointCrawl

svcSharepointPPS

svcSharepointSecureStore

svcSharepointUserProfile


Цитирую из источника:

Active Directory required accounts

It is strongly recommended to create domain accounts and use them as service accounts. You need to create at least the following accounts in Active Directory:

Account type Account name
SQL Service sqlSvcAcc
Setup Admin spAdmin
Farm Account spFarmAcc

Additionally you should create for every service a separate service account in order to meet least-privilege security best practice*. (cool phrase isn’t it? ;)

Account type Account name
Application Pool Account
spAppPoolAcc
Application Pool Account for BDC Service Application spAppPoolBDCAcc
Application Pool Account for Excel Service Application spAppPoolEXCELAcc
Application Pool Account for PowerPoint Service Application spAppPoolPPTAcc
Application Pool Account for Word Service Application spAppPoolWORDAcc
SharePoint Foundation Search Service Account spfSearchSvc
SharePoint Foundation Search Content Access Account spfSearchCAAcc
more to come...

* You should give a service account only the permissions needed by the service to work properly. E.g. the content access account only needs read permissions. Using the SharePoint Farm Account which is member of the farm administrators group as the content access account isn’t the thing I would do.