среда, 15 августа 2012 г. - www.msmirnov.ru

Должны ли разработчики иметь доступ к данным на рабочих системах?

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

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

Обычно в этом случае они имеют доступ только к системам, предназначенным для разработки и тестирования.

Обновление, настройка и мониторинг рабочих систем в этом случае, как правило, выполняется администраторами.

Такой подход предназначен для того, чтобы защитить данные пользователей от несанкционированного доступа и в некоторых случаях имеет право на существование.

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

А именно:
  1. Часто у рабочей группы в этом случае нет возможности работать с тестовыми данными или действиями пользователей или средой идентичными рабочим. Причем, часто характер этих данных или действий может быть такой, что может быть довольно трудно осуществить генерацию таких тестовых данных, чтобы они по своему характеру могли соответствовать реальным. Это может приводить к разработке не самых оптимальных решений, созданных без учета реальной картины.
  2. У рабочей группы нет возможности осуществлять обнаружение и устранение проблем еще до момента их появления. Мониторинг работы систем, выполняемый администраторами, как правило работает уже по факту появления проблем, а не для их предотвращения заранее. Особенно это касается вопросов производительности, оптимизации и тому подобных вещей.
  3. У рабочей группы нет возможности корректировать действия пользователей, анализируя ту ситуацию с данными, которая у них сложилась. Особенно это касается систем с большим объемом пользовательских данных.
  4. Такой подходит снижает скорость и качество устранения проблем. Информация о проблемах, передаваемых от администраторов или службы поддержки, часто бывает неполной или искаженной и не дает возможности проанализировать и устранить проблему. Это проводит к запросам дополнительной информации о проблеме и т.д.
    В результате время работы над проблемой увеличивается.
В итоге, часто бывает так, что по мере возникновения различных проблем, разработчики постепенно, один за одним, все-таки получают доступ к пользовательским данным, который потом у них, обычно и остается.

Конечно, в ряде случаев, рабочие системы содержат данные, которые не желательны к распространению. Но все-равно, невозможно на все 100% закрыть доступ к этим данным. Кто-то (администраторы, служба поддержки) все равно смогут при желании получить к ним доступ. Так что здесь уже возникают вопросы доверия своей команде и юридического оформления неразглашения.

Да и в подавляющем большинстве случаев пользовательские данные не настолько конфиденциальны и интересны, чтобы их скрывать от разработчиков. Исключения, конечно, есть, но встречаются они не так часто.
Мой сайт - www.msmirnov.ru

вторник, 14 августа 2012 г. - www.msmirnov.ru

От Groove к SharePoint Workspace

Microsoft SharePoint Workspace 2010 вышел в свет уже давно, но мы только на прошлой неделе полностью отказались от использования Microsoft Groove в пользу этого инструмента.

Как я уже неоднократно упоминал, мы несколько лет использовали Microsoft Groove в качестве инструмента для хранения и обмена проектной документацией, общения и даже в некоторой степени управления проектами.

Однако, работа Microsoft Groove становилась все менее и менее стабильной. Синхронизация peer-to-peer стала все чаще давать сбои - документы и другие обновления рабочих областей перестали доходить до участников по непонятным причинам. Сначала не часто, а потом все больше и больше. В конце концов пользоваться стало невозможно и документами стали обмениваться через Skype, что привело к полной дезорганизации их хранения.

В конце концов мы переключились на Microsoft SharePoint Workspace 2010, который, хоть и имеет свои недостатки по сравнению с Groovе (например, теперь у нас нет чата или обмена мгновенными сообщениями), но все же, поскольку в нем вместе синхронизации peer-to-peer используется синхронизация с сервером, он избавляет нас от тех проблем, при которых мы не могли нормально обмениваться документами.

Конечно, синхронизация по расписанию не всегда удобна, но все равно, плюсов намного больше.
Мой сайт - www.msmirnov.ru

воскресенье, 29 июля 2012 г. - www.msmirnov.ru

Вебинар Дмитрия Безуглова "Карьерный путь Product Manager"

Сегодня посмотрел весьма толковый вебинар Дмитрия Безуглова "Карьерный путь Product Manager".

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

Последнее время, как мне кажется, наблюдается некоторый дефицит полезных вебинаров.

А этот  рекомендую посмотреть по вот этой ссылке: http://www.system-approach.ru/2012/07/product-manager-careerpath/ или на YouTube:
Мой сайт - www.msmirnov.ru

пятница, 25 мая 2012 г. - www.msmirnov.ru

Желаемый синтаксический сахар в Microsoft SQL Server

Версия MS SQL 2012, конечно, несет много интересных доработок.

Однако, меня давно интересует, почему в SQL Server'е не добавить немного синтаксического сахара относительно курсоров.

В самом деле, если бы у нас была возможность пробегаться по курсорам при помощи конструкций примерно следующего вида, то было бы намного проще:

foreach MyRow in (select * from MyTable)
    begin
        select MyField from MyRow
    end


Сейчас, для того, чтобы сделать тоже самое, нам приходится постоянно набирать куски кода вроде этого:

declare @MyField int
   
declare cur cursor for
select MyField from MyTable

open cur

fetch next from cur into @MyField

while @@FETCH_STATUS = 0
    begin
        select
@MyField
       
        fetch next from cur into @MyField
    end

close cur
deallocate cur

Который по своему функционалу аналогичен предыдущему, но как видно, намного длиннее.

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

Кроме того, его можно было бы дополнить и различными настройками курсора, если уж это может кому-то потребоваться.

Прощу представителей компании Microsoft, в случае прочтения данного сообщения, считать это моим личным пожеланиям относительно новой функциональности в дальнейших версиях SQL Server.
Мой сайт - www.msmirnov.ru