Так делать не надо, поскольку, ТЗ на систему сложнее калькулятора:
1) НЕ позволяет объективно оценить стоимость и время разработки программного продукта
2) НЕ исключает потери времени и денег на ненужные действия, вынужденные доработки, длительное согласование
3) НЕ позволяет избежать разногласий и неудоволетворенности клиента и исполнителя
Однако прекрасно позволяет:
1) Потратить неведомую кучу времени на проработку документа, который превратится в устаревшую макулатуру, как только вы нажмете на кнопку «Печать»
2) Связать заказчику руки, который, на момент написания ТЗ, имеет только набор гипотез и догадок, которые вы, любезно, поможете ему упаковать в артефакт, отражающий ваши совместные галлюцинации относительно продукта, пользователей и сценариев использования и, тем более, касательно нагрузки и производительности
3) Получить иллюзию понимания сроков и стоимости проекта
4) Сделать, в итоге, совсем не то, что реально было нужно заказчику, при этом узнать об этом в самом конце.
5) Посчитать заказчика мудаком и дать ему все основания считать мудаком вас.
5) Понять, наконец, что современная разработка ПО не имеет ничего общего с постройкой зданий, и что единственной постоянным элементом требований будет только одно — их непрерывное изменение в процессе реализации.
Большое спасибо за статью! Отличный и подробный пример того, как не надо делать, если вы планируете получить на выходе конкурентноспособный и актуальный продукт.
Несколько некорректно выглядит вот это утверждение об MVC: "Модель использует событие о том что она изменилась, и все подписанные на это события Представления, получив его, обращаются к Модели за обновленными данными, после чего их и отображают" в связке с указанием о том, что этот подход применяется в ASP.NET MVC. Конкретно там View не подписывается на изменения модели и никак не следит за ними. Эта роль отводится контроллеру, он реагирует на действие пользователя, меняет модель и отдает View измененные данные для отображения.
Так и знал что кто-то задаст этот вопрос :) Абсолютно неважно в какой таймзоне передается дата на сервер. В любом случае на сервере DateTime преобразует ее в локальную. Т.е. если дату из примера выше передать в UTC «2010-01-04T07:00:00Z» (обратите внимание на букву Z на конце), на сервере к ней будет добавлено 4 часа и результат будет такой же.
Как вариант можно передавать дату вообще без указания смещения, тогда DateTime ничего не будет с ней сделать, но выставит ей DateTimeKind.Unspecified. Этого же можно добиться с помощью применения структуры DateTimeOffset. Но это все выглядит достаточно костыльно. Тем более, что при стандартной сериализации js-объектов Date в JSON (через date.toJSON() или JSON.stringify) дата переводится в UTC.
Видно, что для выбранной даты действует зимнее время и смещение +составляет +03:00. Отправляем дату на сервер, где в системе задан московский часовой пояс. В случае, если на сервере для работы с датами выбрана структура DateTime получается такая ситуация:
var dt=DateTime.Parse("2010-01-04T10:00:00+03:00");
Console.WriteLine(dt);
04.01.2010 11:00:00
Отправляли 10 часов, получили 11, несмотря на то, что с двух сторон у нас подразумевалось московское время.
Microsoft поддерживает историческую информацию о часовых поясах в своей базе. Собственно Windows в курсе, что сейчас смещение фиксированное, а до лета 2011-го года было плавающее. Но выбранная структура хранения имеет недочеты, последствия которых описаны в статье. Собственно сотрудники Microsoft подтвердили, что это баг и даже выпустили обновление, которое правда не помогло.
Структуру не отдаем. Максимум, что появляется на клиенте — это названия некоторых контроллеров и действий. Что так же происходит в любом ASP.NET MVC приложении с дефолтным шаблоном маршрутизации. Не думаю, что это является какой-то угрозой безопасности.
При использовании RouteJs на клиенте по умолчанию будут доступны все роуты, которые вы описали для приложения. Т.е. в данном случае вы пользуетесь методом Router.action() на клиенте, так же как @Url.Action() на сервере. Так же есть возможность выносить на клиент не все роуты, а только необходимые, помечая нужны экшены специальным атрибутом.
После скачивания фреймворка первый месяц вы можете бесплатно пользоваться всеми фичами, доступными в Business-лицензии. За исключением приватной тех. поддержки, пожалуй. Про отдельные условия для студентов, к сожалению, нет ни слова.
Аналогично. Сейчас от Storyboard остались только связи между экранами. В следующих проектах все буду делать исключительно через код и эту библиотеку. Работа с TableVIew в CocoaTouch вообще шокировала с плохой стороны.
Также сталкивался с проблемами 1 и 3. Но, последние обновления значительно улучшили ситуацию. Теперь сбои если и происходят, то редко. Насчет интеграции с Xcode. В качестве механизма для описания UI выбрал Storyboard и на текущий момент несколько раз уже пожалел. Во-первых это гигантский XML, который очень тяжело мерджится в случае, если над проектом работает несколько человек. Кроме того, как оказалось, пользы от «drag-n-drop» перетаскивания контролов на экраны практически никакой. Потому что практически на всех экранах используются кастомные View и динамическое добавление элементов управления. В итоге нашлась отличная библиотека для Xamarin — XibFree. Она значительно упрощает механизм создания интерфейса в коде, при этом позволяет избежать нудного рассчета положения каждого элемента при добавлении.
Согласен, я долго думал, стоит ли включать это конкретное сравнение в статью. Когда мне приходится переносить некоторый код из objective-c на C#, объем кода отличается, но не в разы. Однако, стройный синтаксис C# в связке с лямбда выражениями делают его гораздо понятнее. Конечно, если вы не первый код пишете на Objective-C, для вас это может быть не слишком актуально.
Да, в этом случае выигрыш в плане переносимости кода будет несущественным. Однако опять же, если вы любите и пишете на C#, то вам в любом случае будет приятнее вести разработку на Xamarin.
1) НЕ позволяет объективно оценить стоимость и время разработки программного продукта
2) НЕ исключает потери времени и денег на ненужные действия, вынужденные доработки, длительное согласование
3) НЕ позволяет избежать разногласий и неудоволетворенности клиента и исполнителя
Однако прекрасно позволяет:
1) Потратить неведомую кучу времени на проработку документа, который превратится в устаревшую макулатуру, как только вы нажмете на кнопку «Печать»
2) Связать заказчику руки, который, на момент написания ТЗ, имеет только набор гипотез и догадок, которые вы, любезно, поможете ему упаковать в артефакт, отражающий ваши совместные галлюцинации относительно продукта, пользователей и сценариев использования и, тем более, касательно нагрузки и производительности
3) Получить иллюзию понимания сроков и стоимости проекта
4) Сделать, в итоге, совсем не то, что реально было нужно заказчику, при этом узнать об этом в самом конце.
5) Посчитать заказчика мудаком и дать ему все основания считать мудаком вас.
5) Понять, наконец, что современная разработка ПО не имеет ничего общего с постройкой зданий, и что единственной постоянным элементом требований будет только одно — их непрерывное изменение в процессе реализации.
Как вариант можно передавать дату вообще без указания смещения, тогда DateTime ничего не будет с ней сделать, но выставит ей DateTimeKind.Unspecified. Этого же можно добиться с помощью применения структуры DateTimeOffset. Но это все выглядит достаточно костыльно. Тем более, что при стандартной сериализации js-объектов Date в JSON (через date.toJSON() или JSON.stringify) дата переводится в UTC.
Видно, что для выбранной даты действует зимнее время и смещение +составляет +03:00. Отправляем дату на сервер, где в системе задан московский часовой пояс. В случае, если на сервере для работы с датами выбрана структура DateTime получается такая ситуация:
Отправляли 10 часов, получили 11, несмотря на то, что с двух сторон у нас подразумевалось московское время.
Черт, промахнулся веткой.