Comments 68
Во-первых, почему «Я» везде большое?
А во-вторых, чем вам готовые решения (bundling and minification) в ASP.net 4 не угодили?
А во-вторых, чем вам готовые решения (bundling and minification) в ASP.net 4 не угодили?
Во-первых, почему «Я» везде большое?
Простите, привычка с английского…
А во-вторых, чем вам готовые решения (bundling and minification) в ASP.net 4 не угодили?
- Не все ещё купили последнюю студию.
- Минификация происходит в рантайме и требует .NET'а. А если статик-сервер, скажем, на NAS'е или на апаче, то минификация не спасёт.
- Не сжимает HTML код, который всегда первостепенен, по сравнеию с остальным контентом.
Не все ещё купили последнюю студию.
А зачем вам для этого последняя студия?
Минификация происходит в рантайме и требует .NET'а. А если статик-сервер, скажем, на NAS'е или на апаче, то минификация не спасёт.
Вообще-то, в рамках тех же проектов есть и билд-тайм утилита WebGrease.
А зачем вам для этого последняя студия?
Вообще-то, в рамках тех же проектов есть и билд-тайм утилита WebGrease.
«WebGrease is a dependency of the Web Optimization library in Visual Studio 2012 RC».
Да и HTML опять не сжимает.
Моё решение работает в 8, 9, 10 студии.
И первая версия написана в 2009 году. (Только недавно решил выложить… Всё руки написать не доходили...)
При этом, WebGrease не даёт выполнять дополнительные операции над выкладываемыми файлами.
См.:
CSS/JS файлы находятся в основном проекте и при выкладывании основного решения перемещаются на общий сервер.
В дополнение к вышесказанному:
Вы своим примером по WebForms жестоко насилуете наследие Барбары Лисков, паттерн MVP и саму концепцию рипитера, как контрола.
Надо не мусор из html вычищать, а код писать так, чтобы он не генерировался.
Вы своим примером по WebForms жестоко насилуете наследие Барбары Лисков, паттерн MVP и саму концепцию рипитера, как контрола.
Надо не мусор из html вычищать, а код писать так, чтобы он не генерировался.
Это пример. Естественно, в реальных решениях блочная вёрстка.
А в качестве примера приводить решение на Ext.NET или на других клиентских фреймворках будет не всем понятна.
«Надо» — это правильно, но никакое «надо» не переломит человеческий фактор…
А в качестве примера приводить решение на Ext.NET или на других клиентских фреймворках будет не всем понятна.
Надо не мусор из html вычищать, а код писать так, чтобы он не генерировался.
«Надо» — это правильно, но никакое «надо» не переломит человеческий фактор…
Проблема совсем не в блочной верстке и клиентских фреймворках. Проблема в исходно неверном подходе — в двух репитерах и том как они выбираются по свичу. Смотрите «принцип замещения Лисков».
Хм, Я когда пример писал, даже не задумывался о том, что он может быть проблематичным…
Он даже не запустится, т.к. не хватает явного преобразования.
Но, спасибо, что обратили на это внимание.
Он даже не запустится, т.к. не хватает явного преобразования.
Но, спасибо, что обратили на это внимание.
Собственно, необходимость явного преобразования — один из симптомов.
И если переписать нормально, то скорее всего проблемы с мусором в html не будет.
Простите, если слишком резок, но с таким примером получается, что вы «костылем» решаете проблему, которая имеет совсем другие корни.
И если переписать нормально, то скорее всего проблемы с мусором в html не будет.
Простите, если слишком резок, но с таким примером получается, что вы «костылем» решаете проблему, которая имеет совсем другие корни.
А Вы можете переписать этот код в правильный без использования «допустим»?
И ничего не зная о:
При этом, чтобы конечному читателю было понятно о чём идёт речь и о базовом функционале.
У меня опыта в написании статей нет, и это Мой первый опыт, так что Я будут только рад позитивной критике.
И ничего не зная о:
- Источниках данных из которых получаются эти данные?
- Правильности этого куска кода (такого кода в природе нет)?
- Многоразового использования этого кода на других платформах/проектах?
При этом, чтобы конечному читателю было понятно о чём идёт речь и о базовом функционале.
У меня опыта в написании статей нет, и это Мой первый опыт, так что Я будут только рад позитивной критике.
А не надо писать код в таких условиях. Надо опираться на свой реальный опыт (тогда код будет оттуда) или на свои исследования (тогда код будет оттуда).
А выдуманные задачи тем и плохи, что разваливаются при столкновении с реальным анализом.
А выдуманные задачи тем и плохи, что разваливаются при столкновении с реальным анализом.
А выдуманные задачи тем и плохи, что разваливаются при столкновении с реальным анализом.
А при написании «Hello World» Вы тоже ожидаете что мир Вам ответит?
Или Вам найти книги от M$ Press, где рассказываются азы программирования на ASP.NET с использованием SqlConnection и SqlCommand?
Так что Вы в корне забываете о уровне программистов, которые при появлении jQuery начали его использовать для «скругления углов», а не для облегчения реализации тривиальных задач.
Надо опираться на свой реальный опыт (тогда код будет оттуда) или на свои исследования (тогда код будет оттуда).
Я правильно понимаю, что Вас смущает написанный мной пример, а сам Add-In'а Вас вполне устраивает?
К счастью, пример не имеет никакого отношения к моему решению проблемы автоматизации, так что Я могу удалить его не кривя душой. :)
А Ваша детская выходка, lair, связанная со знаниями Моего опыта или Моих исследований, не подтверждённых никакими аргументами, никак не тянет на господина, которому уже больше 30 лет.
А при написании «Hello World» Вы тоже ожидаете что мир Вам ответит?
Цели другие.
Я правильно понимаю, что Вас смущает написанный мной пример, а сам Add-In'а Вас вполне устраивает?
Лично меня смущает велосипедостроение без видимой необходимости.
А Ваша детская выходка, lair, связанная со знаниями Моего опыта или Моих исследований, не подтверждённых никакими аргументами,
Ну так приведите пример из реальной ситуации, когда это нужно, и когда нельзя использовать существующие инструменты.
Лично меня смущает велосипедостроение без видимой необходимости.
Надеюсь, дискуссию с рантайм библиотеками для сжатия продолжать не стоит? Т.к. Я в самом начале статьи описал, что Я найду более интересные задачи для фермы, нежели сжимать динамичный контент вручную, рассказывая всем членам комманды как надо и не надо писать код. Или на статик-сервера подключать подерржку ASP.NET'а.
Необходимость ожидания первого сервис пака перед планированием перехода на новую версию, в коммерческих реалиях, надеюсь, Вам объяснять тоже не придётся.
- Я Вам сейчас 100% статистику по обращениям показать не смогу, т.к. мониторинг контента на firewall'е основного решения выключен. Но при последнем мониторинге вторичный контент создавал 30% от общего трафика в день. Т.е. ~70% трафика создаёт именно HTML (Это при том, что Я стараюсь результатирующую страницу вместе со вторичным контентом не выпускать за рамки 500Кб).
- Коммандная строка даёт гораздо больше свободы разработчику, нежели только сжатие CSS и JS.
Так, какие существующие инструменты перекрывют моё решение и дают больше функционала?
Офтопик:
Еси-бы Вы посмотрели файлы, то обратили внимание, что сам Add-In основан на плагинах и заниматься сжатием — это не основная задача :).
Я пока не вижу конкретную задачу, которую вы решаете.
При этом я знаю, что WebGrease написан командой msn.com, а им я в вопросах оптимизации как-то доверяю.
При этом я знаю, что WebGrease написан командой msn.com, а им я в вопросах оптимизации как-то доверяю.
Я пока не вижу конкретную задачу, которую вы решаете.
Давайте примем за аксиому, что дублирования кода быть не должно. Т.е. если путь публикации (Пример: \\server\www\Site1\) прописан в одной переменной (В нашем случае в VS), то только там его и надо брать, а не писать в документации: «Не забудьте поменять путь {здесь}, {здесь} и {здесь}».
Доменные папки, DFS и NLB позволяют программисту не задумываться о кол-ве серверов в ферме на данный момент времени. Но накладывают задержку с работой DFS. Соответственно, при выкладке приложения в рабочую папку, мы получим дерготню IIS'а:
_shutdownReason: ConfigurationChangeИз-за этого, выкладывать приходится в соседнюю папку. Пример: \\server\www\Site1 (В которую смотрит IIS), \\server\www\Site2.
- Через ADSI (жалко мне поддержку IIS6 выкидывать...) получаю папку в которую сейчас смотрит IIS. В нашем примере это \\server\www\Site1.
- Публикую проект в папку \\server\www\Site2, сжимая код после выкладывания.
- Публикация уходит в таймаут на ~5 мин., чтобы дать время DFS'у синхронизировать все сервера.
- Переключаю (автоматом) IIS с папки \\server\www\Site1 на папку \\server\www\Site2
В результате получаю задержку на клиенте в несколько секунд, за которые он даже таймаут не получит.
а им я в вопросах оптимизации как-то доверяю.
Так Я своё приложения для сжатия для примера привёл. К примеру, у гугла есть интересные варианты, которые даже затеняемость кода поддерживают. В данном случае мой код сжимает не только JS и CSS, но и HTML(ASP.NET) паралельно используя инлайн сжатие для JS/CSS.
Вы про webdeploy тоже не слышали?
Слышал. И?
Если применять по назначению, всех ваших проблем можно избежать.
Но такое решение неудобно по 2 причинам:
- Физического доступа на сервер может не быть.
- Действие происходит не явно.
Не? На somee хостинге мне никто не позволит ставить вебдеплой.
А решение нужно универсальное.
Да и статик-сервера никто не отменял, о которых Я писал выше.
Ну и ещё одна проблема, которая уже несколько раз спасала мой ночной сон:
Если в 2-4 часа ночи вылезла ошибка, когда кеш-сервера обновились, то у админов есть шанс переключиться на предыдущую версию.
А уже потом, звонить и спрашивать «что делать»…
А решение нужно универсальное.
Чтобы везде было одинаково неудобно?
Нет, спасибо. Это какие-то очень надуманные рамки.
Чтобы везде было одинаково неудобно?
Что не удобно-то?
Весь функионал в одном месте:
- Клиент — разработка, тестирование, развёртка.
- Сервер — предоставление сервиса.
Ограничив любое звено, получаем функционирующий и масштабируемый код.
(Развертывание неудобно.)
MS явно заявляет, что позиционирует WebDeploy как the инструмент для развертывания решений на базе asp.net. У меня нет причин им не верить.
MS явно заявляет, что позиционирует WebDeploy как the инструмент для развертывания решений на базе asp.net. У меня нет причин им не верить.
MS явно заявляет, что позиционирует WebDeploy как the инструмент для развертывания решений на базе asp.net. У меня нет причин им не верить.
У M$ — основная задача продавать свои продукты, а не решать проблемы разработчиков.
Перегнать возможности вебдеплоя Я не стремлюсь, предоставленное мной решение необходимо совершенно для других целей.
Если Вы покажете мне инструмент, который на этапе выкладки сжимает код на aspx страницах и пользовательских элементах управлениях, то моим решением пользоваться бессмысленно.
Но существующие инструменты, позволяют сжимать только вторичный код.
Если код на страницах достаточно динамичный, то в результате, даже с сжатием на уровне протокола, может получиться достаточно хороший процент паразитного трафика.
Если вспомнить историю, то фейлы с 2-3 Mb вьюстейтами, на сегодняшний день, заменили фейлы с 2-3 Mb jQuery + плагины. И в большинстве своём, разработчикам всё равно, насколько распухает код в финальной отдаче конечному клиенту страницы…
У Вас, к примеру, какой лимит на, скажем, титульную страницу со всем вторичым трафиком на фронтенде?
Если Вы покажете мне инструмент, который на этапе выкладки сжимает код на aspx страницах и пользовательских элементах управлениях, то моим решением пользоваться бессмысленно.
А зачем?
У Вас, к примеру, какой лимит на, скажем, титульную страницу со всем вторичым трафиком на фронтенде?
У нас его нет.
А зачем?
А какую Вы преследуете цель в Нашей дискуссии?
У нас его нет.
Фронтенда? Тогда вообще проблем нет :)
На бекенде Мы тоже всякий код тестируем и условия пользования ставим :)
А какую Вы преследуете цель в Нашей дискуссии?
Уничтожение лишних сущностей.
Фронтенда?
Лимитов на титульную страницу.
Уничтожение лишних сущностей.
Посмотрите, для примера, код страниц гугля, яндекса, бинга.
Весь первичный контент сжат. И наверняка сжатие происходит не в рантайме.
Им тоже стоит уничтожить лишние сущности?
Вы гугль, яндекс или бинг? Или хотя бы MSN?
А во-вторых — откуда вы знаете, как у них происходит сжатие?
А во-вторых — откуда вы знаете, как у них происходит сжатие?
Вы гугль, яндекс или бинг? Или хотя бы MSN?
Нет. А что, надо быть обязательно MSNом чтобы писать компактный код?
А во-вторых — откуда вы знаете, как у них происходит сжатие?
Не знаю. Вы можете подождать пару итераций, может, как и с типизированным репитером, сотрудники M$ включат что-то подобное в очередную версию студии. ;)
Честно говоря, при правильно настроенном кэшировании статики не вижу большой разницы в рантайме происходит сжатие или где и когда угодно еще.
Я и не уговариваю. Если кому-то будет полезно, то Я рад.
Ну а лимиты времени выполнения, или лимиты на размер результатирующего кода — это дело лично (или не лично) каждого.
А у Вас есть лимиты на время выполнения и на размер результатирующего кода?
Ну а лимиты времени выполнения, или лимиты на размер результатирующего кода — это дело лично (или не лично) каждого.
А у Вас есть лимиты на время выполнения и на размер результатирующего кода?
Что такое «время выполнения» в случае веб-приложения, простите?
У нас есть лимиты на время завершения операций и на время отклика.
У нас есть лимиты на время завершения операций и на время отклика.
Что такое «время выполнения» в случае веб-приложения, простите?
Спасибо, что обратили на это внимание. Я написал общее понятие, которое включает в себя не только время завершения операции, но и время загрузки всей страницы.
Есть. Но мы ждем миграции продакшна на новый дотнет.
Я все еще не понимаю принципиальной разницы между:
1. Взяли с жесткого диска, закэшировали, дальше отдаем из кэша.
2. Взяли из рантайма, закэшировали, дальше отдаем из кэша.
Я все еще не понимаю принципиальной разницы между:
1. Взяли с жесткого диска, закэшировали, дальше отдаем из кэша.
2. Взяли из рантайма, закэшировали, дальше отдаем из кэша.
MS заявляет, что TFS является очень удобным средством коллективной работы и умеет много-много всего из коробки, а если нужно — всё гибко и просто настраивается. А вы попробуйте прикрутить какой-нибудь слегка специфичный сценарий установки приложений, или добавить возможность отслеживания (traceability) и планирования билдов. После этого причин им верить поубавиться.
Если в 2-4 часа ночи вылезла ошибка, когда кеш-сервера обновились, то у админов есть шанс переключиться на предыдущую версию.
У нас такие ситуации решаются деплоем предыдущей версии из версионника.
А хостингом, который не поддерживает webdeploy лучше не пользоваться, имхо.
У нас такие ситуации решаются деплоем предыдущей версии из версионника.
У Вас этим админы занимаются? 0_o
Можно и админам. Это инструмент развертывания приложения. Допустим у нас клиент через WebPi ставит пакет, при деплое прогоняются PS скрипты для создания счетчиков, ивент сорсов и и тд. Настраивает его на стэйджинге, после чего делает создание пакета на из настроенного инстанса и распространяет по боевым серверам.
Тот же пакет может содержать кучу всего, например настройки ACL для файловой системы и тд.
Тот же пакет может содержать кучу всего, например настройки ACL для файловой системы и тд.
Можно и админам.
У нас админы за кодом не следят. Максимум на что можно уговорить, так на переключение IISов.
Есть несколько систем мониторинга, которые пытаются связаться с разработчиками, при фатальных проблемах. В разработке система мониторинга потока ошибок со всех приложений, которая при достижении определённого лимита определённых исключений в отрезок времени поднимала панику. CEP работает, а вот настройка пока не удаётся…
Это инструмент развертывания приложения.
Спасибо за позитивную критику. :)
У Нас ещё паралельно логируются все деплои: кто, куда, когда.
И отправляются сообщения всем сотрудникам, создавшим таски и ожидающие их завершения.
Админ получает готовый пакет. По сути джавовский war. У нас невозможен автодеплой на прод, так как пока не придет дяденька из ИБ и не даст сертификатиков — все курят.
Для мониторинга есть счетчики производительности и тд. Ошибки приложения льют на отдельный сервак. Для этого просто таргет в нлоге написать или листнер для трэйсов. Админ отвечает за развертывание приложения у маленьких и отдел внедрения у больших клиентов.
А за логирование деплоев отвечает аудит на серваке =)
Для мониторинга есть счетчики производительности и тд. Ошибки приложения льют на отдельный сервак. Для этого просто таргет в нлоге написать или листнер для трэйсов. Админ отвечает за развертывание приложения у маленьких и отдел внедрения у больших клиентов.
А за логирование деплоев отвечает аудит на серваке =)
Ошибки приложения льют на отдельный сервак.
У нас они тоже льются на отдельный сервак из WebForms, WCF, WinForms, WinCE приложений.
Но проблема с паникой. Т.к. разработчикам СМС приходят, когда приложение полностью отвалилось. Но появилась, скажем, плавающая ошибка. Т.е. приложение начинает проявлять в логах подозрительную активность. И на глаз, на графике, это увидеть можно, но вот настроить так монитор, чтобы он отслеживал не только повышение активности приложения, но и учитывал повышения активности клиентов оказалось не так-то и просто…
Счетчики. Ну и отдельная подсистема аудита. А весь сыр-бор из-за того, что для целей деплоймента просто прекрасно подходят стандартные тулзы — WebDeploy и WebPlatformInstaller. У последнего есть либа с логикой, которую можно включить в свой агент обновлений, и прекрасно раскатывать пакеты через внутренний фид приложений, причем не ограничиваясь только пакетами для IIS, а раскатывая вообще что угодно.
А весь сыр-бор из-за того, что для целей деплоймента просто прекрасно подходят стандартные тулзы — WebDeploy и WebPlatformInstaller.
Вебдеплой плохо работает, когда необходимо размазать одно решение по нескольким доменам приложений. Там уже костылить приходится…
Приведите пример «размазывания» =)
Статик сервера (Пока на IIS'е, но ничто не мешает на апач перекинуть)
АппДомены для CDN (они на IIS'е, т.к. там часть кода БЛ поднимается).
АппДомены для CDN (они на IIS'е, т.к. там часть кода БЛ поднимается).
А кто мешает деплоить разные пакеты в соответствие с ролью сервера? =) Это не сложно и даже не костыль: Microsoft.Web.PlatformInstaller
А кто мешает деплоить разные пакеты в соответствие с ролью сервера? =) Это не сложно и даже не костыль: Microsoft.Web.PlatformInstaller
Не многовато всего писать?
Я это решаю несколькими командами выполняемыми автоматом во время паблиша с клиента для каждого проекта. При неудачной исполнении любой команды, Я могу поправить ошибку и продолжить выполнение с этой команды.
А если валится деплой, то он валится целым куском.
При необходимости расширить функционал паблиша, в репозиторий добавляются/обновляются необходимые плагины, расширяющий функционал студии в нужном направлении, а не только в сторону паблиша. Если Вы обратили внимание — это просто SAL обёртка, расширяемая как конструктор.
Да. Как и поддержкой продакшн-серверов как таковой.
А должно быть как-то иначе?
А должно быть как-то иначе?
1. Источники данных абсолютно не важны.
2. Я недавно рефакторил практически идентичный кусок (на предмет оптимизации производительности), поэтому глаза и резануло.
3. Ваш код совсем не многоразовый, почти не расширяемый, и что хуже, делает кучу лишней работы.
Чтобы я сделал:
1. Замаппил ваши данные на иерархию вьюмоделей (да, на каждый тип фильтра по классу).
2. Вынес бы каждый фильтр в отдельный контрол и связал бы с моделями. См. паттерн MVP в вариации для WebForms.
3. Вместо размножения рипитеров выбирал бы нужный контрол во время привязки данных.
2. Я недавно рефакторил практически идентичный кусок (на предмет оптимизации производительности), поэтому глаза и резануло.
3. Ваш код совсем не многоразовый, почти не расширяемый, и что хуже, делает кучу лишней работы.
Чтобы я сделал:
1. Замаппил ваши данные на иерархию вьюмоделей (да, на каждый тип фильтра по классу).
2. Вынес бы каждый фильтр в отдельный контрол и связал бы с моделями. См. паттерн MVP в вариации для WebForms.
3. Вместо размножения рипитеров выбирал бы нужный контрол во время привязки данных.
Чтобы я сделал:
Такой код половину статьи займёт… Я-ж его в качестве примера привёл, а не как основное на что стоит заострять внимание…
на предмет оптимизации производительности
А Вы по трассировке смотрели результатирующую производительность?
Готов поспорить, что вынос контроллов в отдельные файлы, в качественно написанном коде, только замедлит выполнение.
3. Вместо размножения рипитеров выбирал бы нужный контрол во время привязки данных.
Если код вторично используемый, то есть смысл его выводить во вторичные элементы управления, а если код используется только в одном месте, то выносить его со страницы просто усложнит дальнейшую поддержку верстальщикам и программистам.
Такой код половину статьи займёт… Я-ж его в качестве примера привёл, а не как основное на что стоит заострять внимание…
Пример должен показывать реальную проблему. Тогда уж лучше ничего не приводить.
А Вы по трассировке смотрели результатирующую производительность?
Готов поспорить, что вынос контроллов в отдельные файлы, в качественно написанном коде, только замедлит выполнение.
Компиляцию — да. Выполнение — нет.
Если код вторично используемый, то есть смысл его выводить во вторичные элементы управления, а если код используется только в одном месте, то выносить его со страницы просто усложнит дальнейшую поддержку верстальщикам и программистам.
А вот мой верстальщик почему-то громко ругается на большие шаблоны и дублирование верстки.
Пример должен показывать реальную проблему. Тогда уж лучше ничего не приводить.
Это был тонкий троллинг того, что в 4.5 типизированный репитер наконец то появился в коробке от M$'а.
Даже год, автора и источник появления этого репитера указал. :)
Ещё в начале 2010 года Я в M$ про него писал, при миграции на .NET 4.
Простите, что сразу про это не написал…
Компиляцию — да. Выполнение — нет.
Т.е. проблема была не в том, что разработчик использовал вложенность репитеров?
Это уже радует. Т.к. Я предпочитаю весь код иметь в одном месте, а не разбросанным по проекту.
А вот мой верстальщик почему-то громко ругается на большие шаблоны и дублирование верстки.
Я полностью согласен с Вашим верстальщиком. Дублирование вёрстки недопустимо.
А вот с большими шаблонами — не знаю. Лимит на размер методов, как известно, давно опубликовали специалисты из patterns & practice.
А вот по поводу больших шаблонов рекомендаций Я не встречал. У Вас есть какие-то ограничения?
А если сюда заглянуть? Cassette. В одном из проектов успешно уже год живет. Плюс там Less, Sass и Coffee Script поддерживаются.
Спасибо за ссылку, искал что-то подобное ;)
А если сюда заглянуть?
Не знал про такой…
Во первых, он сжимает в рантайме. Т.е. распределить нагрузку по нескольким доменам не получится. (Ограничение по масштабируемости)
А во вторых, Я не нашёл сжатие asp[c]x/Master страниц. (Может плохо искал, т.к. только его поставил...)
Да ладно?
Ух, тыкните, пожалуйста, где-ж они первичный трафик сжимают.
А то по этой ссылке опять Я только про оптимизацию вторичного трафика расказывается…
Cassette provides an MSBuild task that creates the processed bundle cache at compile-time
Also, the configuration section in Web.config if modified to tell Cassette where to find the compile-time generated cache files.
Also, the configuration section in Web.config if modified to tell Cassette where to find the compile-time generated cache files.
Вы
- IL смотрели?
- Запускали?
Где там HTML сжатие? (Я просмотрел только IL...)
Не совсем понимаю, зачем вам сжимать HTML в Asp.Net? Не проще тогда уже просто написать свой ViewEngine с оптимизированным под ваши задачи результатом?
Не совсем понимаю, зачем вам сжимать HTML в Asp.Net?
Люблю копаться в HTML коде понравившихся сайтов.
Особенно интересно было копаться в коде сайтов сони, пока их не поломали. Теперь комментариев в коде стало значительно меньше. :(
А тут, как-то залез в код титульной страницы гугля и прям там мне их компактный код понравился, что пришла в голову мысль поизучать эту проблему поподробнее.
Sign up to leave a comment.
ASP.NET и сжатие клиентского кода