Все правильно. Agile — набор ценностей из манифеста. Отследить их нарушение просто. Scrum — каркас с известной классической схемой — отследить его нарушение еще проще. Kanban — тоже игра с определенными правилами.
По факту при внедрении тех или иных инструментов мы привыкли внедрять их понемногу. Поробовали какую то часть — оценили результат — не понравилось — стали искать что то еще.
С эджайл методиками такое не прокатит. Все их составные части очень сильно повязаны друг на друга. Одно без другого не работает. Нужно внедрять классическую схему полностью. Именно так, как написано в умных книжках.
Конечно. Но без этого ограничения я смогу использовать продукт полностью бесплатно на всем жизненном цикле проекта, если у меня команда меньше пяти человек.
В случае ограниченного количества сборок это будет уже не так. + Нужно будет парится по поводу того, как часто гоняются билды, как то пытаться их сэкономить — напряги могут быть немалые.
Вариант с локальным сервером я не рассматриваю.
Если отказаться от деплоймента через TFS- то нужно будет задумываться как его синтегрировать со сторонней CI системой. И поразмыслив можно будет решить, что не так уж он и нужен — благо аналогов решений из TFS пруд пруди.
В том числе в бесплатный план будет включено некоторое количество автоматизированных сборок.
Я правильно понимаю, что я не смогу ипользовать бесплатную версию TFS для системы непрерывной интергации, потому что количество выполнений сценариев для развертывания системы ограничено?
В нормальном тесте инициализация не должна занимать 15 строк кода. Для тестового класса возможно. Но для этого есть специальный атрибут в тестовом фреймворке. Классический модульный тест тестирует один метод. Значит when шаг — одна строчка. Самый код будет в ассертах да. Это нормальный стиль — вы видите в одном тестовом методе весь тестовый случай — все три шага рядом. Так задумывалось изначально создателями mstest и nunit.
Нет смысла их разделять. Вопрос распухания инициализации конкретно решается другими средствами.
Это сейчас у вас класс с минимальным количеством логики. А завтра он вырастет в монстра — потому что любой продукт имеет свойство эволюционировать. Только код который будет заточен под ваше решение уже не переделать — и вы останетесь на продукте с ним навечно. Да чего я вам объясняю очевидные проблемы велосипедов.
Понятно что вас потом уже уволить не смогут — ведь только вы уже будете мастером по этому решению.
Без необходимости разбираться и работать с новыми фреймворками. — в вышеуказанных фреймворках разбираться ничуть не сложнее чем в том, что вы предложили. Можно статью на хабре даже короче написать. Посмотрите обзор — он очень прост.
Интересно писать для себя. Но потом обязательно возникнет желание впихнуть в какой нибудь рабочий проект, продав как свои знания.
И это уже проблема. Вот вы же предложили распространить решение NuGet пакетом?
Хотя нет — сейчас подумал — это может пригодится как раз если вам не нужен полноценный DSL, а нужно писать модульные тесты в BDD стиле.
Только вот зачем…
При правильной организации модульных тестов given — в предыницализации теста, when — одна строчка, then — мясо теста.
Наверно у вас просто неправильные тесты — раз понадобился такой странный механизм.
Фреймворков для реализации подобного функционала целая пачка (NBehave, Specflow).
И они просты, легки в использовании и их поддерживают уважаемые сообщества.
Отправляйте наработку в свой архив и не вздумайте использовать на работе.
Как вспомню моду на самописные ORM в компаниях несколько лет назад так вздрогну.
Specflow — хорош очень многим. Вы можете почитать на их сайте. Это порт на .net лидера bdd фреймворков кукумбера. Создана в рамках компании TechTalk. За приличное количество лет своего существования этот продукт эволюционировал до очень крутого уровня.
Я в документации по nbehave нашел только пару вещей, которой я не припомню в specflow — это Examples и возможности по вызову степов из юнит тестов — но так ли уж это надо — вопрос.
В свою очередь specflow имеет массу возможностей, которых нет в nbehave и главное новые очень быстро появляются — перечислять не хочется — почитайте на сайте.
Самое главное — он поддерживает большое количество тестовых провайдеров, в том числе MsTest и NUnut.
И различные платформы кроме .net — Mono, Silverlight, Windows Phone 7.
При любом событии внутри UpdatePanel происходит PostBack и выполняются все события страницы, в которых могут происходить трудные вычисления или запросы к базе данных.
Это решается серверным кешированием в сессию по моему. Вроде так и задумывался механизм — нет?
Видим, что для вывода простого текста внутри UpdatePanel потребовалось 2 кб html и еще почти 100 кб скриптов.
И насколько это много? На серьезных проектах обычно полно разметки и скриптов целая пачка. Решается клиентским кешированим и сжатием скриптов.
ViewState. Однако в большинстве случаев без него можно обойтись.
Это стандартный механизм для работы с состоянием клиентского вью. Лучше там нет. Какой выигрыш дает отказ от него? Эта игра действительно стоит свеч?
при разработке контролов для ASP.NET не особо задумывались о чистоте и оптимальности верстки, количестве запросов и скорости работы этих самых контролов.
Еще как задумывались. Да — генеренная верстка там не оптимальна — но механизм позволяет абстрагироваться от от html и рассматривать его в ряде случаев как некий веб ассемблер. Стандартные контролы удобны в использовании если уметь их готовить. Проблема только в производительности — но она решается отдельными механизмами. Уходить от них опасно — придется смешивать разные стили разработки, подружить разные инструменты — дополнительные риски.
По минимизации javascript и сжатию html снимаю шляпу. Это правильно — и это стандарт разработки под asp.net.
Хотелось бы увидеть результаты тестирования производительности продукта. Без цифр невозможно оценить стоит ли использовать значительную часть из приведенных вами механизмов.
Существует эвристическое правило, которое говорит о том, что большая часть вновь созданных объектов используются очень короткое время и их спокойно можно будет удалить при первой же возможности.
Вот если бы правило звучало так, то не было бы смысла отделять другие обьекты, так как их все равно слишком мало и мы практически не выиграем исключая их из сборки мусора.
По моему это правило должно звучать так: если обьект живет достаточно долго, то вероятно он будет жить еще дольше. То есть обьекты, которые прошли одну сборку мусора, скорее всего пройдут и следующую.
Поэтому мы делим обьекты на короткоживущие и долгоживущие. При этом сколько тех и других — это отдельный вопрос.
Возможно просто единичный случай.
Удалили по ошибке аккаунт, а теперь не знают как сказать пользователю, что его не вернуть.
Решили занять агрессивную позицию.
Но вообще возможность вот так удалять все без обьяснения причин пугает. Впредь буду читать лицензионные соглашения подробнее.
Мне кажется должно быть можно через usb3 подключить — проверьте. Могут быть переходники какие нибудь. Или купите монитор самсунговский со встроенной докстанцие и изернетом.
1) Какие на данный момент документы нельзя в электронном виде посылать?
Вроде все налоговые и счета-фактуры можно?
2) Для ведения электронного документооборота действительно нужна полная компьютеризация?
Насколько много людей в компании обычно ведут документооборот?
Так оно и есть. А если даже какой то блок памяти выйдет из строя — это вовсе на значит, что диск накроется, и даже не обязательно, что потеряется информация. SSD сейчас очень развитые. Поэтому даже в таких случаях стоит говорить лишь об общек количесвте поддерживаемой перезаписи. А это очень много.
Я конечно не специалист по SSD. Говоря 10к цеклов перезаписи опираюсь на данные википедии по MLC формату, который поддерживают современные SSD. Там написано 10к. Также говорится, что более дорогие виды памяти SLC — имеют более 100к цеклов перезаписи. Правда в английской версии внизу есть ссылка на статью, где написано, что MLC от 1к до 10к циклов.
Но для нас это все равно как разница между триллионом долларов и 10 триллионами. Все равно.
По поводу торрентов интересный вопрос. Я боюсь тоже торренты качать на SSD — а вообще хотелось бы знать стоят ли опасения свеч. Может кто нибудь сможет посчитать. Есть специалисты по торрентам?
1) Видео. Мы его смотрим. Значит сервис по его хранению должен просто обеспечить потоковую закачку с кешированием. Вышеприведенный сервис его обеспечивает, как и специализированные. В этом случае нужен интернет, который обеспечит нужную скорость или придется заранее скачивать.
Проблемы с правообладателями решаются использованием сервисов, которые на них забивают. Это если у вас есть желание нарушать закон. Пока что такие сервисы есть. И поправьте меня, если я не прав, но без разницы — на свое хранилище вы его загружаете или на чужое, если вы его не распространяете.
2) Образы. Мы их монтируем. Значит просто должен поддерживаться ftp/webdav протоколы. Таких сервисов меньше. Но по сути ситуация как с потоковым видео — только скорость уже не так критична. Вышеприведенный сервис такой вариант использования вроде тоже подразумевает. Как и многие другие.
По моему все упирается в скорость интернета. Но необходимые скорости в реальности очень невелики. Не нужно вам по таким сценариям быстро ни фильмы, не образы скачивать. Вообще их не нужно скачивать.
Средний пользователь интернета в нашей стране может обеспечить необходимые скорости — разве нет?
Agile — набор ценностей из манифеста. Отследить их нарушение просто.
Scrum — каркас с известной классической схемой — отследить его нарушение еще проще.
Kanban — тоже игра с определенными правилами.
По факту при внедрении тех или иных инструментов мы привыкли внедрять их понемногу. Поробовали какую то часть — оценили результат — не понравилось — стали искать что то еще.
С эджайл методиками такое не прокатит. Все их составные части очень сильно повязаны друг на друга. Одно без другого не работает. Нужно внедрять классическую схему полностью. Именно так, как написано в умных книжках.
И если сложить c# и .net, то всюду он обгонит c++ например — и выводы были бы у автора статьи совсем другие.
В случае ограниченного количества сборок это будет уже не так. + Нужно будет парится по поводу того, как часто гоняются билды, как то пытаться их сэкономить — напряги могут быть немалые.
Вариант с локальным сервером я не рассматриваю.
Если отказаться от деплоймента через TFS- то нужно будет задумываться как его синтегрировать со сторонней CI системой. И поразмыслив можно будет решить, что не так уж он и нужен — благо аналогов решений из TFS пруд пруди.
Я правильно понимаю, что я не смогу ипользовать бесплатную версию TFS для системы непрерывной интергации, потому что количество выполнений сценариев для развертывания системы ограничено?
Нет смысла их разделять. Вопрос распухания инициализации конкретно решается другими средствами.
Понятно что вас потом уже уволить не смогут — ведь только вы уже будете мастером по этому решению.
Без необходимости разбираться и работать с новыми фреймворками. — в вышеуказанных фреймворках разбираться ничуть не сложнее чем в том, что вы предложили. Можно статью на хабре даже короче написать. Посмотрите обзор — он очень прост.
И это уже проблема. Вот вы же предложили распространить решение NuGet пакетом?
Только вот зачем…
При правильной организации модульных тестов given — в предыницализации теста, when — одна строчка, then — мясо теста.
Наверно у вас просто неправильные тесты — раз понадобился такой странный механизм.
Фреймворков для реализации подобного функционала целая пачка (NBehave, Specflow).
И они просты, легки в использовании и их поддерживают уважаемые сообщества.
Отправляйте наработку в свой архив и не вздумайте использовать на работе.
Как вспомню моду на самописные ORM в компаниях несколько лет назад так вздрогну.
Я в документации по nbehave нашел только пару вещей, которой я не припомню в specflow — это Examples и возможности по вызову степов из юнит тестов — но так ли уж это надо — вопрос.
В свою очередь specflow имеет массу возможностей, которых нет в nbehave и главное новые очень быстро появляются — перечислять не хочется — почитайте на сайте.
Самое главное — он поддерживает большое количество тестовых провайдеров, в том числе MsTest и NUnut.
И различные платформы кроме .net — Mono, Silverlight, Windows Phone 7.
Это решается серверным кешированием в сессию по моему. Вроде так и задумывался механизм — нет?
И насколько это много? На серьезных проектах обычно полно разметки и скриптов целая пачка. Решается клиентским кешированим и сжатием скриптов.
ViewState. Однако в большинстве случаев без него можно обойтись.
Это стандартный механизм для работы с состоянием клиентского вью. Лучше там нет. Какой выигрыш дает отказ от него? Эта игра действительно стоит свеч?
при разработке контролов для ASP.NET не особо задумывались о чистоте и оптимальности верстки, количестве запросов и скорости работы этих самых контролов.
Еще как задумывались. Да — генеренная верстка там не оптимальна — но механизм позволяет абстрагироваться от от html и рассматривать его в ряде случаев как некий веб ассемблер. Стандартные контролы удобны в использовании если уметь их готовить. Проблема только в производительности — но она решается отдельными механизмами. Уходить от них опасно — придется смешивать разные стили разработки, подружить разные инструменты — дополнительные риски.
По минимизации javascript и сжатию html снимаю шляпу. Это правильно — и это стандарт разработки под asp.net.
Хотелось бы увидеть результаты тестирования производительности продукта. Без цифр невозможно оценить стоит ли использовать значительную часть из приведенных вами механизмов.
Вот если бы правило звучало так, то не было бы смысла отделять другие обьекты, так как их все равно слишком мало и мы практически не выиграем исключая их из сборки мусора.
По моему это правило должно звучать так: если обьект живет достаточно долго, то вероятно он будет жить еще дольше. То есть обьекты, которые прошли одну сборку мусора, скорее всего пройдут и следующую.
Поэтому мы делим обьекты на короткоживущие и долгоживущие. При этом сколько тех и других — это отдельный вопрос.
Удалили по ошибке аккаунт, а теперь не знают как сказать пользователю, что его не вернуть.
Решили занять агрессивную позицию.
Но вообще возможность вот так удалять все без обьяснения причин пугает. Впредь буду читать лицензионные соглашения подробнее.
1) Какие на данный момент документы нельзя в электронном виде посылать?
Вроде все налоговые и счета-фактуры можно?
2) Для ведения электронного документооборота действительно нужна полная компьютеризация?
Насколько много людей в компании обычно ведут документооборот?
А критичную информацию надо просто бекапить.
Но для нас это все равно как разница между триллионом долларов и 10 триллионами. Все равно.
По поводу торрентов интересный вопрос. Я боюсь тоже торренты качать на SSD — а вообще хотелось бы знать стоят ли опасения свеч. Может кто нибудь сможет посчитать. Есть специалисты по торрентам?
1) Видео. Мы его смотрим. Значит сервис по его хранению должен просто обеспечить потоковую закачку с кешированием. Вышеприведенный сервис его обеспечивает, как и специализированные. В этом случае нужен интернет, который обеспечит нужную скорость или придется заранее скачивать.
Проблемы с правообладателями решаются использованием сервисов, которые на них забивают. Это если у вас есть желание нарушать закон. Пока что такие сервисы есть. И поправьте меня, если я не прав, но без разницы — на свое хранилище вы его загружаете или на чужое, если вы его не распространяете.
2) Образы. Мы их монтируем. Значит просто должен поддерживаться ftp/webdav протоколы. Таких сервисов меньше. Но по сути ситуация как с потоковым видео — только скорость уже не так критична. Вышеприведенный сервис такой вариант использования вроде тоже подразумевает. Как и многие другие.
По моему все упирается в скорость интернета. Но необходимые скорости в реальности очень невелики. Не нужно вам по таким сценариям быстро ни фильмы, не образы скачивать. Вообще их не нужно скачивать.
Средний пользователь интернета в нашей стране может обеспечить необходимые скорости — разве нет?