Для добавления задач («я щас поеду домой, а ты мне к приезду скачай новую серию любимого сериала») не придумал ни одного сценария, где бы он давал хоть какой-нибудь плюс перед ftp/webdav папкой, которая периодически проверяется на наличие новых файлов.
А для всех остальных операций удаленное управление нужно либо полноценное (WebUI), либо не актуально вообще.
Свой сервис типа аггрегатора по разным трекерам? И по айпишнику детектить, какими трекерами ограничиться для каждой страны?
Или пользователь сам будет вести список трекеров, где искать?
Как быть с закрытыми трекерами?
На второй взгляд возникает естественный вопрос: а могу ли я закачивать себе эту музыку на айпод?
На третий взгляд кажется, что 160 килобит явно маловато.
На четвертый взгляд, почему-то уверен, что обязательно рано или поздно появятся патчи, убирающие рекламу, и другие альтернативы, паразитирующие на сервисе.
Ну, даже если считать в розницу, то Server 2008 + все CALы обходятся менее 100 000 рублей.
Кроме того, не стоит забывать, что у MS есть куча разных программ лицензирования (типа Open Value, Open License, etc.), которые как раз и призваны уменьшить стоимость при массовой закупке лицензий.
Потому что NaN однозначно указывает, что на входе какая-то фигня.
А с нулем еще надо дополнительно проверять, действительно ли там ноль, или 10 пробелов.
Во-первых, лично придушил бы дизайнера этого сайта за таблицы без рамок и с вертикальным выравниванием текста по центру, в результате чего нифига не ясно, к чему относится какой кусок текста.
Ну, а во-вторых, с точки зрения здравого смысла не улавливаю, почему
Пустой или состоящий из одних пробелов СтроковойЧисленныйЛитерал преобразует в +0.
По-моему, логичнее было бы возвратить NaN, разве нет?
Очевидно, авторы не знают, что op_Equality для строки — это все тот же вызов Equals. Но где-то услышали, что «не рекомендуют», и решили у себя тоже написать. И причину не объяснили.
А не рекомендуют, в основном, от того, что можно опечататься и вместо "==" написать "=", в результате чего исказится логика.
Кстати, все приличные анализаторы кода показывают предупреждение «assignment in conditional operator», поэтому если писать не в блокноте, то ничего страшного.
Инсталляторы, естественно, через RunAs запускать, тут без вариантов.
А большинство обычных программ все-таки в последнее время исправились — по UAC-у вижу, что админ им не обязателен.
Правда, некоторые все еще любят писать конфиги и прочие файлы рядом с собой (т.е. в програм файлс), но это решается виртуализацией путей в висте, а в более старых системах — в индивидуальном порядке :)
Поддерживает, правда немного иначе, чем LINQ2SQL. См. метод Load у навигационных свойств.
Дифирамбы EF я и не воспевал, просто привел пару плюсов перед типизированными датасетами. Это, скорее, дифирамбы конструктору вижуалстудии, чем самой технологии.
На одной маленькой базе пробовал. На сколько-нибудь серьезных вещах — не пробовал. «Умных» книжек не читал вообще.
1) возможностью отложенной загрузки данных
в датасете нам надо заполнить все таблицы, чтобы воспользоваться отношениями между ними (или писать кучу лишнего и нетривиального кода для догрузки по необходимости)
в LINQ2SQL и EF догрузка может производиться в «ленивом» режиме без лишнего кода.
2) nullable-типы все-таки роднее языку, чем DBNull и дурацкие проверки IsBlaBlaBlaNull()
3) Вам когда-нибудь приходилось на лету заменять строку подключения или таймаут для команд типизированному датасету? Без рефлекшена затея обречена на провал.
В EF это можно сделать, вызвав альтернативный конструктор класса.
P.S. Можно менять модель непосредственно в студии, а модель уж сама внесет нужные изменения в базу. Хотя, верно и обратное.
1) Утверждение "… это LINQ. Без него в ADO.NET никуда" неверно.
ADO.NET успешно существовал без LINQ несколько лет, LINQ — это лишь приятное удобство.
2) Зачем создавать лишние экземпляры класса? Это я, в частности, про строку 24. Разумеется, в рамках тестовой странички лишний Post — это мелочи, но все же… :)
Ну, а в остальном — хорошо, просто, доступно. Пишите еще.
Еще с ними работают браузеры (например, IE) — пишет туда поток Zone.Information, из какой зоны был скачан этот файл.
Если из достаточно небезопасной (интернет), то будет переспрашивать при попытке запуска и в окошке свойств будет соответствующий текст и кнопка «разблокировать».
Ни одной.
Ну, спрячете что-нибудь, ну и какая в этом гадость? С таким же успехом можно запихнуть куда-нибудь поглубже в обычную папку и тоже никто не найдет, если специально искать не будет.
От некоторых вообще достаточно скрыть простой установкой атрибута «hidden» :)
Для добавления задач («я щас поеду домой, а ты мне к приезду скачай новую серию любимого сериала») не придумал ни одного сценария, где бы он давал хоть какой-нибудь плюс перед ftp/webdav папкой, которая периодически проверяется на наличие новых файлов.
А для всех остальных операций удаленное управление нужно либо полноценное (WebUI), либо не актуально вообще.
Свой сервис типа аггрегатора по разным трекерам? И по айпишнику детектить, какими трекерами ограничиться для каждой страны?
Или пользователь сам будет вести список трекеров, где искать?
Как быть с закрытыми трекерами?
На второй взгляд возникает естественный вопрос: а могу ли я закачивать себе эту музыку на айпод?
На третий взгляд кажется, что 160 килобит явно маловато.
На четвертый взгляд, почему-то уверен, что обязательно рано или поздно появятся патчи, убирающие рекламу, и другие альтернативы, паразитирующие на сервисе.
Однако, интересно, она весь код анализирует, или только те ветви, которые будут исполняться на целевой платформе?
Кроме того, не стоит забывать, что у MS есть куча разных программ лицензирования (типа Open Value, Open License, etc.), которые как раз и призваны уменьшить стоимость при массовой закупке лицензий.
А с нулем еще надо дополнительно проверять, действительно ли там ноль, или 10 пробелов.
Я был счастлив, когда Майкрософт начала делать их для WPF. Бесплатно. С исходниками.
Во-первых, лично придушил бы дизайнера этого сайта за таблицы без рамок и с вертикальным выравниванием текста по центру, в результате чего нифига не ясно, к чему относится какой кусок текста.
Ну, а во-вторых, с точки зрения здравого смысла не улавливаю, почему
По-моему, логичнее было бы возвратить NaN, разве нет?
Очевидно, авторы не знают, что op_Equality для строки — это все тот же вызов Equals. Но где-то услышали, что «не рекомендуют», и решили у себя тоже написать. И причину не объяснили.
А не рекомендуют, в основном, от того, что можно опечататься и вместо "==" написать "=", в результате чего исказится логика.
Кстати, все приличные анализаторы кода показывают предупреждение «assignment in conditional operator», поэтому если писать не в блокноте, то ничего страшного.
Инсталляторы, естественно, через RunAs запускать, тут без вариантов.
А большинство обычных программ все-таки в последнее время исправились — по UAC-у вижу, что админ им не обязателен.
Правда, некоторые все еще любят писать конфиги и прочие файлы рядом с собой (т.е. в програм файлс), но это решается виртуализацией путей в висте, а в более старых системах — в индивидуальном порядке :)
Четвертый классический совет: сразу после переустановки забрать у пользователя административные права.
Дифирамбы EF я и не воспевал, просто привел пару плюсов перед типизированными датасетами. Это, скорее, дифирамбы конструктору вижуалстудии, чем самой технологии.
На одной маленькой базе пробовал. На сколько-нибудь серьезных вещах — не пробовал. «Умных» книжек не читал вообще.
1) возможностью отложенной загрузки данных
в датасете нам надо заполнить все таблицы, чтобы воспользоваться отношениями между ними (или писать кучу лишнего и нетривиального кода для догрузки по необходимости)
в LINQ2SQL и EF догрузка может производиться в «ленивом» режиме без лишнего кода.
2) nullable-типы все-таки роднее языку, чем DBNull и дурацкие проверки IsBlaBlaBlaNull()
3) Вам когда-нибудь приходилось на лету заменять строку подключения или таймаут для команд типизированному датасету? Без рефлекшена затея обречена на провал.
В EF это можно сделать, вызвав альтернативный конструктор класса.
P.S. Можно менять модель непосредственно в студии, а модель уж сама внесет нужные изменения в базу. Хотя, верно и обратное.
1) Утверждение "… это LINQ. Без него в ADO.NET никуда" неверно.
ADO.NET успешно существовал без LINQ несколько лет, LINQ — это лишь приятное удобство.
2) Зачем создавать лишние экземпляры класса? Это я, в частности, про строку 24. Разумеется, в рамках тестовой странички лишний Post — это мелочи, но все же… :)
Ну, а в остальном — хорошо, просто, доступно. Пишите еще.
Если из достаточно небезопасной (интернет), то будет переспрашивать при попытке запуска и в окошке свойств будет соответствующий текст и кнопка «разблокировать».
Ну, спрячете что-нибудь, ну и какая в этом гадость? С таким же успехом можно запихнуть куда-нибудь поглубже в обычную папку и тоже никто не найдет, если специально искать не будет.
От некоторых вообще достаточно скрыть простой установкой атрибута «hidden» :)