ASP.NET и сжатие клиентского кода

Со времён MSIE4 и блокнота, Я люблю комментировать написанный код. Но одно дело, когда проект создаётся для себя, или при компиляции комментарии не попадут конечному пользователю. И совсем другое дело, когда написанные комментарии могут попасть конечному клиенту. Во первых, они ему не нужны, а во вторых, в комментариях может содержаться некий текст, который может подвергнуть опасности этот или другой проект. И в третьих, содержимые в клиентском коде (HTML, JS, CSS) комментарии, даже в сжатом виде, создают паразитный трафик.
Изучая такой код иногда можно натолкнуться на интересные вещи. Вот, к примеру, один из кусков комментариев на одном всеми известном сайте:
…
//ubepua07/default/main/SonyStyle/WORKAREA/Common/SonyStyleStorefrontAssetStore/include/CMSpot
…
А внизу всего этого хозяйства красуется вот такой текст:
…
(Developers should log their changes, including line number for reference here)
…
Вот пример комментариев от компании Яндекс:
"Любишь заглядывать в консоль? А может и js умеешь писать?…"


Я хочу рассказать о нескольких ситуациях, с которыми мне приходится сталкиваться достаточно часто:
  1. Клиентский код в виде ресурсов в сборке
  2. Клиентский код в качестве файлов WebForms или MVC решения
  3. Клиентский код, находящийся на сайте для статичных ресурсов (http://static.sitename.com)
В тексте статьи Я использую самописный инструмент: SourceCruncher. Есть намного более эффективные средства для сжатия кода вёрстки HTML, CSS и JS скриптов с поддержкой затенения и более эффективного процесса сжатия. (Я написал свой вариант для более детального понимания процесса парсинга браузерами кода вёрстки и скриптов.)

Клиентский код в виде ресурсов в сборке.

Я начал искать варианты решения задачи используя подручные средства. И для сжатия ресурсов внутри сборки решение нашлось достаточно быстро. На идею про сжатие скрипта в сборке меня натолкнул скрипт, который я использовал до появления в 10ой студии опции, с видоизменением файлов Web.config для разных конфиураций выкладывания решения (Идея была не моя и автора идеи Я забыл). В Visual Studio можно написать команду выполняемую до и после сборки проекта.

(Project Properties → Build Events → {Pre-build event command line/Post-build event command line})
Для того, чтобы работал этот метод, необходимо прописать команду копирования наших клиентских файлов во временный файл. За это отвечает команда копирования:
copy "$(ProjectDir)Script.js" "$(ProjectDir)Script.orig.js" /V /Y
Затем, необходимо применить сжатие для файла скрипта. В данном проекте, программа для сжатия находится в корневой папке:
"$(SolutionDir)..\..\SourceCruncher.exe" /IO:"$(ProjectDir)Script.js" /Y
После того, как сборка собралась, необходимо вернуть наш клиентский скрипт в оригинальный вид. Для этого, добавляем в событие «Post-build event command line:» код перемещения сжатого варианта файла на не сжатый вариант:
move /Y "$(ProjectDir)Script.orig.js" "$(ProjectDir)Script.js"
Важно!
Не забудьте включить событие post-build только после успешной сборки:
Run the post-build event: On successful build.
Иначе, при ошибки компиляции файл Script.js останется сжатым.
В данном примере есть одно ограничение. Если необходимо отладить клиентский код, то необходимо будет вручную убрать код копирования и сжимания js файла. Или захардкодить для отладочного примера ссылку на оригинальный файл скрипта, а не на сжатый файл ресурса из сборки. Это связано с тем, что Build Events выполняется во всех конфигурациях.

Клиентский код в качестве файлов WebForms или MVC решения

Из готовых решений, Я нашёл только один вариант, сжимать клиентский код в рантайме через регулярное выражение. С одной стороны, решение очень простое, но Я лучше потрачу ресурсы процессора на более интересную задачу, нежели сжатие одного и того-же файла при каждом запросе.
Ещё можно написать сервис и мониторить изменение файлов на жёстких дисках серверов и сжимать их при изменении. Но такое решение неудобно по 2 причинам:
  1. Физического доступа на сервер может не быть.
  2. Действие происходит не явно.
Пришлось искать решение в режиме «До выкладывания». Сначала Я решил делать это через события «Build Events» как и в случае с кодом ресурсов сборки. Но они происходят каждый раз после сборки проекта, а не перед выкладыванием. Во первых, затормаживая сам процесс сборки (особенно если учесть что клиентского кода может быть очень много), а во вторых, усложняет процесс поиска ошибок в клиентском коде.
Т.к., в большинстве случаев, я выкладываю проект через команду «Publish Web» (т.е. имеется физический доступ к серверу), в студии, то Я решил копать в эту сторону и попытаться сжимать файлы сразу после выкладывания проекта на рабочий сервер.
Вот тут я столкнулся с первой проблемой: Для события публикации в студии нет стандартного UI.
Немного погуглив, необходимое событие нашлось в EnvDTE для студии, которое используется для написания Add-In’ов.

Итак, написав небольшой Add-In Я добавил в него необходимые команды и радовался жизни. Для примера, команда на сжатие файла Style.css выглядела следующим образом:
"$(SolutionDir)\Solution Items\SourceCruncher.exe" /IO:"\\server\Path\styles\Style.css" /Y
В начале, проблемы не было, т.к. каждый проект выкладывался только в одну папку и путь к папке можно было захардкодить. Но если необходима бесперебойная работа сервера, то отключать пользователей сообщением App_Offile.html, Я считаю не вполне этично. Так что сначала начал выкладывать проекты в 2 папки. По принципу, рабочая версия/предыдущая версия. Сначала Я решил эту проблему таким образом:
  1. Подлключаюсь к IIS через ADSI
  2. Беру путь папки в которой у меня работает решение
  3. Удаляю всё содержимое папки {ProjectName}_PrevVersion
  4. Копирую всё решение из этой папки в папку {ProjectName}_PrevVersion
  5. Переключаю решение с рабочей папки на папку {ProjectName}_PrevVersion
  6. Выкладываю решение в рабочую папку
  7. Переключаю папки с {ProjectName}_PrevVersion на рабочую папку.
Но такой подход занимает много времени, несмотря на то, что всё это решается автоматом. А если ещё весь проект лежит на DFS, то сервера будут заниматься лишней работой перетасовывания файлов.
Пришлось копать дальше… В документации на разработку Ad-In’ов для студии нет ни одного упоминания о пути куда выкладывалось решение. В результате, самым прямолинейным путём осталось копать память. К моему облегчению, код публикации написан на управляемом коде, так что использование рефлексии помогло найти место переменной для VS 2005 и 2008 быстро. Для VS 2010 место переменной, где хранится путь к папке, куда выкладывалось решение пришлось поискать подольше, т.к. разработчики добавили профили выкладывания (Publish Profile).
В результате, получился Add-In позволяющий выполнять произвольные команды перед и после выкладывания проекта.
Установка Add-In'а
(Пример для Visual Studio 2008, но от VS 2010 никаких различий нет.)
Элемент меню AddIn'а

Запуск окна с надстройкой:

К сожалению, вариант установки есть только один — ручками. Инсталлера, увы, нет.:
  1. Скачиваем весь архив и распаковываем его в желаемую папку (Или в известную папку с Add-in’ами, если у Вас такая уже есть).
  2. Затем, открываем студию: Tools → Options → Add-in/Macros Security и в окне Add-in File Paths прописываете путь который Вы указали на шаге один. (Или переносите распакованные файлы в папку указанную в этом списке).
  3. Перезапускаем студию, включаем Add-In через «Add-in Manager» (Tools→Add-in Manager...→Flatbed.EnvDTE)
  4. И в меню Tools появится команда «Flatbed.EnvDTE Properties».
  5. После этого, загружаем проект
  6. Если разработчиков проекта несколько человек, то добавляем в проект консольное приложение для сжатия кода (В данном случае, в качестве примера, используется моя утилита SourceCruncher). Или указываем сетевой путь до консольного приложения, которое будет доступно всем разработчикам.
  7. Открываем окно настройки плагина «PluginDTE.CmdLine» (Tools→Flatbed.EnvDTE Properties→PluginDTE.CmdLine)
  8. И прописываем консольную команду на сжимание интересующих файлов. Пример:
    "\\server\Path\SourceCruncher.exe" /IO:"${PublishLocation}js\Utils.js" /Y
  9. После того, как команды прописаны, нажимаем Ctrl+S для сохранения команд. (Команды сохраняются в .sln файле решения, так что все разработчики проекта у которых будет стоять этот Add-In увидят все внесённые изменения).
    Тут есть один минус, если проект лежит в TFS’е, то каждый раз при открытии проекта файл .sln будет браться на редактирование (Check out).

Прописанные комманды сохраняются в .sln файле решения, так что все разработчики решения у которых будет стоять этот Add-In смогут выложить решение с применением необходимого сжатия.
Проблемы:
При использовании TFS 2010 есть проблема (ссылка больше не доступна). Соответственно, при использовании VS9 и VS10, при открытии решения любым разработчиком, sln файл будет взят разработчиком на изменение автоматически.
Если Вы пользуетесь VSS или Tortoise, то таких проблем нет.
Есть ещё одна проблема связанная с TFS, которую Я пока до конца не изучил: Если .sln файл взят на изменение другим разработчиком, то плагин не может прочитать команды для сжатия из sln файла.

Пример на WebForms

Приведу пример ситуации, при котором генерируемый код вёрстки получается сильно замусоренный лишним текстом (Для примера Я использовал типизированный Repeater, написанный Andrey Shchekin в 2007 году):
<user:TypedRepeater ID="repFilters" DataItemTypeName="Company.Dal.Catalog.FilterToc" OnItemDataBound="repFilters_ItemDataBound" runat="server">
	<ItemTemplate>
		<tr>
			<td><%# Container.DataItem.FilterName %></td>
			<td>
				<%-- Строковый тип фильтра--%>
				<user:TypedRepeater ID="repFiltersString" DataItemTypeName="Company.Dal.Catalog.FilterString" runat="server">
					<ItemTemplate>
						<asp:TextBox Text="<%# Container.DataItem.FilterValue %>" runat="server" />
					</ItemTemplate>
				</user:TypedRepeater>
				<%-- Битовый тип фильтра --%>
				<user:TypedRepeater ID="repFiltersBit" DataItemTypeName="Company.Dal.Catalog.FilterBit" runat="server">
					<ItemTemplate>
						<asp:CheckBox Checked="<%# Container.DataItem.FilterValue %>" Text="<%# Container.DataItem.FilterName %>" runat="server" />
					</ItemTemplate>
				</user:TypedRepeater>
…
			</td>
		</tr>
	</ItemTemplate>
</user:TypedRepeater>
Если представить что типов фильтров может быть, скажем, 10, так же как и среднее кол-во фильтров на страницу, то в файле отправляемом клиенту будет большое кол-во паразитного траффика.

Клиентский код, находящийся на сайте для статичных ресурсов

Есть несколько решений, которые используют одни и те-же стили. Допустим, основной сайт и интранет сайт одной из задач которого является написание статей для основного сайта в WYSIWYG редакторе. Соответственно, базовые стили обоих сайтов должны быть идентичными. Для этого используются файлы стилей и изображений доступным обоим сайтам (это статья не о версионности, так что проблему соответствия всех сайтов одним глобальным стилям Я опускаю. Так же как и проблему хранения версий). Для примера приведу несколько вариантов:
  1. CSS/JS файлы находятся внутри основного решения в виде ссылок на актуальные файлы на общем сервере.
    В таком случае можно применять к ним сжатие как и к файлам основного решения описанного в пп.2 статьи.
  2. CSS/JS файлы находятся в основном проекте и при выкладывании основного решения перемещаются на общий сервер.
  3. Если верстальщик не пользуется VS, а использует свой инструмент для редактирования общих файлов, то можно использовать программу DropTarget в совокупности с программой для сжатия клиентского кода.
Источник проекта находится тут. Но т.к. проект находится на бесплатном хостинге, то чтобы быть уверенным что файлы будут доступны, Я закачал последнюю версию на Яндекс Диск (В будущем, обновлений на ЯДиске ожидать не стоит):
  1. Visual Studio 2005 Add-In
  2. Visual Studio 2008 Add-In
  3. Visual Studio 2010 Add-In
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 68

    +3
    Во-первых, почему «Я» везде большое?

    А во-вторых, чем вам готовые решения (bundling and minification) в ASP.net 4 не угодили?
      +1
      Во-первых, почему «Я» везде большое?

      Простите, привычка с английского…
      А во-вторых, чем вам готовые решения (bundling and minification) в ASP.net 4 не угодили?

      1. Не все ещё купили последнюю студию.
      2. Минификация происходит в рантайме и требует .NET'а. А если статик-сервер, скажем, на NAS'е или на апаче, то минификация не спасёт.
      3. Не сжимает HTML код, который всегда первостепенен, по сравнеию с остальным контентом.
        0
        Не все ещё купили последнюю студию.

        А зачем вам для этого последняя студия?

        Минификация происходит в рантайме и требует .NET'а. А если статик-сервер, скажем, на NAS'е или на апаче, то минификация не спасёт.

        Вообще-то, в рамках тех же проектов есть и билд-тайм утилита WebGrease.
          +1
          А зачем вам для этого последняя студия?

          Вообще-то, в рамках тех же проектов есть и билд-тайм утилита WebGrease.

          «WebGrease is a dependency of the Web Optimization library in Visual Studio 2012 RC».
          Да и HTML опять не сжимает.
          Моё решение работает в 8, 9, 10 студии.
          И первая версия написана в 2009 году. (Только недавно решил выложить… Всё руки написать не доходили...)

          При этом, WebGrease не даёт выполнять дополнительные операции над выкладываемыми файлами.
          См.:
          CSS/JS файлы находятся в основном проекте и при выкладывании основного решения перемещаются на общий сервер.
      0
      В дополнение к вышесказанному:
      Вы своим примером по WebForms жестоко насилуете наследие Барбары Лисков, паттерн MVP и саму концепцию рипитера, как контрола.
      Надо не мусор из html вычищать, а код писать так, чтобы он не генерировался.
        +1
        Это пример. Естественно, в реальных решениях блочная вёрстка.
        А в качестве примера приводить решение на Ext.NET или на других клиентских фреймворках будет не всем понятна.
        Надо не мусор из html вычищать, а код писать так, чтобы он не генерировался.

        «Надо» — это правильно, но никакое «надо» не переломит человеческий фактор…
          0
          Проблема совсем не в блочной верстке и клиентских фреймворках. Проблема в исходно неверном подходе — в двух репитерах и том как они выбираются по свичу. Смотрите «принцип замещения Лисков».
            0
            Хм, Я когда пример писал, даже не задумывался о том, что он может быть проблематичным…
            Он даже не запустится, т.к. не хватает явного преобразования.

            Но, спасибо, что обратили на это внимание.
              0
              Собственно, необходимость явного преобразования — один из симптомов.
              И если переписать нормально, то скорее всего проблемы с мусором в html не будет.

              Простите, если слишком резок, но с таким примером получается, что вы «костылем» решаете проблему, которая имеет совсем другие корни.
                0
                А Вы можете переписать этот код в правильный без использования «допустим»?
                И ничего не зная о:
                1. Источниках данных из которых получаются эти данные?
                2. Правильности этого куска кода (такого кода в природе нет)?
                3. Многоразового использования этого кода на других платформах/проектах?

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

                У меня опыта в написании статей нет, и это Мой первый опыт, так что Я будут только рад позитивной критике.
                  0
                  А не надо писать код в таких условиях. Надо опираться на свой реальный опыт (тогда код будет оттуда) или на свои исследования (тогда код будет оттуда).

                  А выдуманные задачи тем и плохи, что разваливаются при столкновении с реальным анализом.
                    0
                    А выдуманные задачи тем и плохи, что разваливаются при столкновении с реальным анализом.

                    А при написании «Hello World» Вы тоже ожидаете что мир Вам ответит?

                    Или Вам найти книги от M$ Press, где рассказываются азы программирования на ASP.NET с использованием SqlConnection и SqlCommand?
                    Так что Вы в корне забываете о уровне программистов, которые при появлении jQuery начали его использовать для «скругления углов», а не для облегчения реализации тривиальных задач.

                    Надо опираться на свой реальный опыт (тогда код будет оттуда) или на свои исследования (тогда код будет оттуда).

                    Я правильно понимаю, что Вас смущает написанный мной пример, а сам Add-In'а Вас вполне устраивает?
                    К счастью, пример не имеет никакого отношения к моему решению проблемы автоматизации, так что Я могу удалить его не кривя душой. :)

                    А Ваша детская выходка, lair, связанная со знаниями Моего опыта или Моих исследований, не подтверждённых никакими аргументами, никак не тянет на господина, которому уже больше 30 лет.
                      0
                      А при написании «Hello World» Вы тоже ожидаете что мир Вам ответит?

                      Цели другие.

                      Я правильно понимаю, что Вас смущает написанный мной пример, а сам Add-In'а Вас вполне устраивает?

                      Лично меня смущает велосипедостроение без видимой необходимости.

                      А Ваша детская выходка, lair, связанная со знаниями Моего опыта или Моих исследований, не подтверждённых никакими аргументами,

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

                        Надеюсь, дискуссию с рантайм библиотеками для сжатия продолжать не стоит? Т.к. Я в самом начале статьи описал, что Я найду более интересные задачи для фермы, нежели сжимать динамичный контент вручную, рассказывая всем членам комманды как надо и не надо писать код. Или на статик-сервера подключать подерржку ASP.NET'а.

                        Необходимость ожидания первого сервис пака перед планированием перехода на новую версию, в коммерческих реалиях, надеюсь, Вам объяснять тоже не придётся.

                        1. Я Вам сейчас 100% статистику по обращениям показать не смогу, т.к. мониторинг контента на firewall'е основного решения выключен. Но при последнем мониторинге вторичный контент создавал 30% от общего трафика в день. Т.е. ~70% трафика создаёт именно HTML (Это при том, что Я стараюсь результатирующую страницу вместе со вторичным контентом не выпускать за рамки 500Кб).
                        2. Коммандная строка даёт гораздо больше свободы разработчику, нежели только сжатие CSS и JS.

                        Так, какие существующие инструменты перекрывют моё решение и дают больше функционала?

                        Офтопик:
                        Еси-бы Вы посмотрели файлы, то обратили внимание, что сам Add-In основан на плагинах и заниматься сжатием — это не основная задача :).
                          0
                          Я пока не вижу конкретную задачу, которую вы решаете.

                          При этом я знаю, что WebGrease написан командой msn.com, а им я в вопросах оптимизации как-то доверяю.
                            0
                            Я пока не вижу конкретную задачу, которую вы решаете.

                            Давайте примем за аксиому, что дублирования кода быть не должно. Т.е. если путь публикации (Пример: \\server\www\Site1\) прописан в одной переменной (В нашем случае в VS), то только там его и надо брать, а не писать в документации: «Не забудьте поменять путь {здесь}, {здесь} и {здесь}».

                            Доменные папки, DFS и NLB позволяют программисту не задумываться о кол-ве серверов в ферме на данный момент времени. Но накладывают задержку с работой DFS. Соответственно, при выкладке приложения в рабочую папку, мы получим дерготню IIS'а:
                            _shutdownReason: ConfigurationChange
                            Из-за этого, выкладывать приходится в соседнюю папку. Пример: \\server\www\Site1 (В которую смотрит IIS), \\server\www\Site2.
                            1. Через ADSI (жалко мне поддержку IIS6 выкидывать...) получаю папку в которую сейчас смотрит IIS. В нашем примере это \\server\www\Site1.
                            2. Публикую проект в папку \\server\www\Site2, сжимая код после выкладывания.
                            3. Публикация уходит в таймаут на ~5 мин., чтобы дать время DFS'у синхронизировать все сервера.
                            4. Переключаю (автоматом) IIS с папки \\server\www\Site1 на папку \\server\www\Site2

                            В результате получаю задержку на клиенте в несколько секунд, за которые он даже таймаут не получит.

                            а им я в вопросах оптимизации как-то доверяю.

                            Так Я своё приложения для сжатия для примера привёл. К примеру, у гугла есть интересные варианты, которые даже затеняемость кода поддерживают. В данном случае мой код сжимает не только JS и CSS, но и HTML(ASP.NET) паралельно используя инлайн сжатие для JS/CSS.
                              0
                              Вы про webdeploy тоже не слышали?
                                0
                                Слышал. И?
                                  0
                                  Если применять по назначению, всех ваших проблем можно избежать.
                                    0
                                    Но такое решение неудобно по 2 причинам:
                                    1. Физического доступа на сервер может не быть.
                                    2. Действие происходит не явно.


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

                                    Ну и ещё одна проблема, которая уже несколько раз спасала мой ночной сон:
                                    Если в 2-4 часа ночи вылезла ошибка, когда кеш-сервера обновились, то у админов есть шанс переключиться на предыдущую версию.
                                    А уже потом, звонить и спрашивать «что делать»…
                                      +1
                                      А решение нужно универсальное.

                                      Чтобы везде было одинаково неудобно?

                                      Нет, спасибо. Это какие-то очень надуманные рамки.
                                        0
                                        Чтобы везде было одинаково неудобно?

                                        Что не удобно-то?

                                        Весь функионал в одном месте:
                                        • Клиент — разработка, тестирование, развёртка.
                                        • Сервер — предоставление сервиса.

                                        Ограничив любое звено, получаем функционирующий и масштабируемый код.
                                          0
                                          (Развертывание неудобно.)

                                          MS явно заявляет, что позиционирует WebDeploy как the инструмент для развертывания решений на базе asp.net. У меня нет причин им не верить.
                                            0
                                            MS явно заявляет, что позиционирует WebDeploy как the инструмент для развертывания решений на базе asp.net. У меня нет причин им не верить.

                                            У M$ — основная задача продавать свои продукты, а не решать проблемы разработчиков.

                                            Перегнать возможности вебдеплоя Я не стремлюсь, предоставленное мной решение необходимо совершенно для других целей.
                                            Если Вы покажете мне инструмент, который на этапе выкладки сжимает код на aspx страницах и пользовательских элементах управлениях, то моим решением пользоваться бессмысленно.

                                            Но существующие инструменты, позволяют сжимать только вторичный код.
                                            Если код на страницах достаточно динамичный, то в результате, даже с сжатием на уровне протокола, может получиться достаточно хороший процент паразитного трафика.

                                            Если вспомнить историю, то фейлы с 2-3 Mb вьюстейтами, на сегодняшний день, заменили фейлы с 2-3 Mb jQuery + плагины. И в большинстве своём, разработчикам всё равно, насколько распухает код в финальной отдаче конечному клиенту страницы…
                                            У Вас, к примеру, какой лимит на, скажем, титульную страницу со всем вторичым трафиком на фронтенде?
                                              0
                                              Если Вы покажете мне инструмент, который на этапе выкладки сжимает код на aspx страницах и пользовательских элементах управлениях, то моим решением пользоваться бессмысленно.

                                              А зачем?

                                              У Вас, к примеру, какой лимит на, скажем, титульную страницу со всем вторичым трафиком на фронтенде?

                                              У нас его нет.
                                                0
                                                А зачем?

                                                А какую Вы преследуете цель в Нашей дискуссии?

                                                У нас его нет.

                                                Фронтенда? Тогда вообще проблем нет :)
                                                На бекенде Мы тоже всякий код тестируем и условия пользования ставим :)
                                                  0
                                                  А какую Вы преследуете цель в Нашей дискуссии?

                                                  Уничтожение лишних сущностей.

                                                  Фронтенда?

                                                  Лимитов на титульную страницу.
                                                    0
                                                    Уничтожение лишних сущностей.

                                                    Посмотрите, для примера, код страниц гугля, яндекса, бинга.
                                                    Весь первичный контент сжат. И наверняка сжатие происходит не в рантайме.
                                                    Им тоже стоит уничтожить лишние сущности?
                                                      0
                                                      Вы гугль, яндекс или бинг? Или хотя бы MSN?

                                                      А во-вторых — откуда вы знаете, как у них происходит сжатие?
                                                        0
                                                        Вы гугль, яндекс или бинг? Или хотя бы MSN?

                                                        Нет. А что, надо быть обязательно MSNом чтобы писать компактный код?

                                                        А во-вторых — откуда вы знаете, как у них происходит сжатие?

                                                        Не знаю. Вы можете подождать пару итераций, может, как и с типизированным репитером, сотрудники M$ включат что-то подобное в очередную версию студии. ;)
                                                          0
                                                          Нет. А что, надо быть обязательно MSNом чтобы писать компактный код?

                                                          Я просто не вижу смысла писать этот самый «компактный код», пока он не оказывает фундаментального влияния на производительность.

                                                          Не знаю.

                                                          Вот тогда и не говорите.
                                                            0
                                                            Я просто не вижу смысла писать этот самый «компактный код», пока он не оказывает фундаментального влияния на производительность.

                                                            А по регионам обслуживаемой области, полную скорость загрузки содержимого Вы считали?
                                                              0
                                                              Нет. Не видим смысла.
                                                        0
                                                        Честно говоря, при правильно настроенном кэшировании статики не вижу большой разницы в рантайме происходит сжатие или где и когда угодно еще.
                                                          0
                                                          Я и не уговариваю. Если кому-то будет полезно, то Я рад.
                                                          Ну а лимиты времени выполнения, или лимиты на размер результатирующего кода — это дело лично (или не лично) каждого.
                                                          А у Вас есть лимиты на время выполнения и на размер результатирующего кода?
                                                            0
                                                            Что такое «время выполнения» в случае веб-приложения, простите?

                                                            У нас есть лимиты на время завершения операций и на время отклика.
                                                              0
                                                              Что такое «время выполнения» в случае веб-приложения, простите?

                                                              Спасибо, что обратили на это внимание. Я написал общее понятие, которое включает в себя не только время завершения операции, но и время загрузки всей страницы.
                                                              0
                                                              Есть. Но мы ждем миграции продакшна на новый дотнет.

                                                              Я все еще не понимаю принципиальной разницы между:
                                                              1. Взяли с жесткого диска, закэшировали, дальше отдаем из кэша.
                                                              2. Взяли из рантайма, закэшировали, дальше отдаем из кэша.
                                                                0
                                                                дальше отдаем из кэша.

                                                                В нашем случае, рантайм отдаётся под клиента, его так просто не закешировать…
                                                  0
                                                  MS заявляет, что TFS является очень удобным средством коллективной работы и умеет много-много всего из коробки, а если нужно — всё гибко и просто настраивается. А вы попробуйте прикрутить какой-нибудь слегка специфичный сценарий установки приложений, или добавить возможность отслеживания (traceability) и планирования билдов. После этого причин им верить поубавиться.
                                                    0
                                                    Ну прикрутили мы туда «слегка специфичный сценарий». Неприятно, но не смертельно.
                                              +1
                                              Если в 2-4 часа ночи вылезла ошибка, когда кеш-сервера обновились, то у админов есть шанс переключиться на предыдущую версию.


                                              У нас такие ситуации решаются деплоем предыдущей версии из версионника.

                                              А хостингом, который не поддерживает webdeploy лучше не пользоваться, имхо.
                                                0
                                                У нас такие ситуации решаются деплоем предыдущей версии из версионника.

                                                У Вас этим админы занимаются? 0_o
                                                  0
                                                  Можно и админам. Это инструмент развертывания приложения. Допустим у нас клиент через WebPi ставит пакет, при деплое прогоняются PS скрипты для создания счетчиков, ивент сорсов и и тд. Настраивает его на стэйджинге, после чего делает создание пакета на из настроенного инстанса и распространяет по боевым серверам.

                                                  Тот же пакет может содержать кучу всего, например настройки ACL для файловой системы и тд.
                                                    0
                                                    Можно и админам.

                                                    У нас админы за кодом не следят. Максимум на что можно уговорить, так на переключение IISов.

                                                    Есть несколько систем мониторинга, которые пытаются связаться с разработчиками, при фатальных проблемах. В разработке система мониторинга потока ошибок со всех приложений, которая при достижении определённого лимита определённых исключений в отрезок времени поднимала панику. CEP работает, а вот настройка пока не удаётся…

                                                    Это инструмент развертывания приложения.

                                                    Спасибо за позитивную критику. :)
                                                    У Нас ещё паралельно логируются все деплои: кто, куда, когда.
                                                    И отправляются сообщения всем сотрудникам, создавшим таски и ожидающие их завершения.
                                                      0
                                                      Админ получает готовый пакет. По сути джавовский war. У нас невозможен автодеплой на прод, так как пока не придет дяденька из ИБ и не даст сертификатиков — все курят.

                                                      Для мониторинга есть счетчики производительности и тд. Ошибки приложения льют на отдельный сервак. Для этого просто таргет в нлоге написать или листнер для трэйсов. Админ отвечает за развертывание приложения у маленьких и отдел внедрения у больших клиентов.
                                                      А за логирование деплоев отвечает аудит на серваке =)
                                                        0
                                                        Ошибки приложения льют на отдельный сервак.

                                                        У нас они тоже льются на отдельный сервак из WebForms, WCF, WinForms, WinCE приложений.
                                                        Но проблема с паникой. Т.к. разработчикам СМС приходят, когда приложение полностью отвалилось. Но появилась, скажем, плавающая ошибка. Т.е. приложение начинает проявлять в логах подозрительную активность. И на глаз, на графике, это увидеть можно, но вот настроить так монитор, чтобы он отслеживал не только повышение активности приложения, но и учитывал повышения активности клиентов оказалось не так-то и просто…
                                                          0
                                                          Счетчики. Ну и отдельная подсистема аудита. А весь сыр-бор из-за того, что для целей деплоймента просто прекрасно подходят стандартные тулзы — WebDeploy и WebPlatformInstaller. У последнего есть либа с логикой, которую можно включить в свой агент обновлений, и прекрасно раскатывать пакеты через внутренний фид приложений, причем не ограничиваясь только пакетами для IIS, а раскатывая вообще что угодно.
                                                            0
                                                            А весь сыр-бор из-за того, что для целей деплоймента просто прекрасно подходят стандартные тулзы — WebDeploy и WebPlatformInstaller.

                                                            Вебдеплой плохо работает, когда необходимо размазать одно решение по нескольким доменам приложений. Там уже костылить приходится…
                                                              0
                                                              Приведите пример «размазывания» =)
                                                                0
                                                                Статик сервера (Пока на IIS'е, но ничто не мешает на апач перекинуть)
                                                                АппДомены для CDN (они на IIS'е, т.к. там часть кода БЛ поднимается).
                                                                  0
                                                                  А кто мешает деплоить разные пакеты в соответствие с ролью сервера? =) Это не сложно и даже не костыль: Microsoft.Web.PlatformInstaller
                                                                    0
                                                                    А кто мешает деплоить разные пакеты в соответствие с ролью сервера? =) Это не сложно и даже не костыль: Microsoft.Web.PlatformInstaller

                                                                    Не многовато всего писать?

                                                                    Я это решаю несколькими командами выполняемыми автоматом во время паблиша с клиента для каждого проекта. При неудачной исполнении любой команды, Я могу поправить ошибку и продолжить выполнение с этой команды.
                                                                    А если валится деплой, то он валится целым куском.

                                                                    При необходимости расширить функционал паблиша, в репозиторий добавляются/обновляются необходимые плагины, расширяющий функционал студии в нужном направлении, а не только в сторону паблиша. Если Вы обратили внимание — это просто SAL обёртка, расширяемая как конструктор.
                                                    0
                                                    Да. Как и поддержкой продакшн-серверов как таковой.

                                                    А должно быть как-то иначе?
                              0
                              1. Источники данных абсолютно не важны.
                              2. Я недавно рефакторил практически идентичный кусок (на предмет оптимизации производительности), поэтому глаза и резануло.
                              3. Ваш код совсем не многоразовый, почти не расширяемый, и что хуже, делает кучу лишней работы.

                              Чтобы я сделал:
                              1. Замаппил ваши данные на иерархию вьюмоделей (да, на каждый тип фильтра по классу).
                              2. Вынес бы каждый фильтр в отдельный контрол и связал бы с моделями. См. паттерн MVP в вариации для WebForms.
                              3. Вместо размножения рипитеров выбирал бы нужный контрол во время привязки данных.
                                0
                                Чтобы я сделал:

                                Такой код половину статьи займёт… Я-ж его в качестве примера привёл, а не как основное на что стоит заострять внимание…

                                на предмет оптимизации производительности

                                А Вы по трассировке смотрели результатирующую производительность?
                                Готов поспорить, что вынос контроллов в отдельные файлы, в качественно написанном коде, только замедлит выполнение.

                                3. Вместо размножения рипитеров выбирал бы нужный контрол во время привязки данных.

                                Если код вторично используемый, то есть смысл его выводить во вторичные элементы управления, а если код используется только в одном месте, то выносить его со страницы просто усложнит дальнейшую поддержку верстальщикам и программистам.
                                  0
                                  Такой код половину статьи займёт… Я-ж его в качестве примера привёл, а не как основное на что стоит заострять внимание…


                                  Пример должен показывать реальную проблему. Тогда уж лучше ничего не приводить.

                                  А Вы по трассировке смотрели результатирующую производительность?
                                  Готов поспорить, что вынос контроллов в отдельные файлы, в качественно написанном коде, только замедлит выполнение.


                                  Компиляцию — да. Выполнение — нет.

                                  Если код вторично используемый, то есть смысл его выводить во вторичные элементы управления, а если код используется только в одном месте, то выносить его со страницы просто усложнит дальнейшую поддержку верстальщикам и программистам.


                                  А вот мой верстальщик почему-то громко ругается на большие шаблоны и дублирование верстки.
                                    0
                                    Пример должен показывать реальную проблему. Тогда уж лучше ничего не приводить.

                                    Это был тонкий троллинг того, что в 4.5 типизированный репитер наконец то появился в коробке от M$'а.
                                    Даже год, автора и источник появления этого репитера указал. :)
                                    Ещё в начале 2010 года Я в M$ про него писал, при миграции на .NET 4.
                                    Простите, что сразу про это не написал…
                                    Компиляцию — да. Выполнение — нет.

                                    Т.е. проблема была не в том, что разработчик использовал вложенность репитеров?
                                    Это уже радует. Т.к. Я предпочитаю весь код иметь в одном месте, а не разбросанным по проекту.
                                    А вот мой верстальщик почему-то громко ругается на большие шаблоны и дублирование верстки.

                                    Я полностью согласен с Вашим верстальщиком. Дублирование вёрстки недопустимо.
                                    А вот с большими шаблонами — не знаю. Лимит на размер методов, как известно, давно опубликовали специалисты из patterns & practice.
                                    А вот по поводу больших шаблонов рекомендаций Я не встречал. У Вас есть какие-то ограничения?
                    0
                    А если сюда заглянуть? Cassette. В одном из проектов успешно уже год живет. Плюс там Less, Sass и Coffee Script поддерживаются.
                      0
                      Спасибо за ссылку, искал что-то подобное ;)
                        0
                        А если сюда заглянуть?

                        Не знал про такой…

                        Во первых, он сжимает в рантайме. Т.е. распределить нагрузку по нескольким доменам не получится. (Ограничение по масштабируемости)
                        А во вторых, Я не нашёл сжатие asp[c]x/Master страниц. (Может плохо искал, т.к. только его поставил...)
                          0
                            0
                            Да ладно?

                            Ух, тыкните, пожалуйста, где-ж они первичный трафик сжимают.
                            А то по этой ссылке опять Я только про оптимизацию вторичного трафика расказывается…
                              0
                              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.
                                0
                                Also, the configuration section in Web.config if modified to tell Cassette where to find the compile-time generated cache files.

                                Вы
                                • IL смотрели?
                                • Запускали?

                                Где там HTML сжатие? (Я просмотрел только IL...)
                                  0
                                  Не совсем понимаю, зачем вам сжимать HTML в Asp.Net? Не проще тогда уже просто написать свой ViewEngine с оптимизированным под ваши задачи результатом?
                                    0
                                    Не совсем понимаю, зачем вам сжимать HTML в Asp.Net?

                                    Люблю копаться в HTML коде понравившихся сайтов.
                                    Особенно интересно было копаться в коде сайтов сони, пока их не поломали. Теперь комментариев в коде стало значительно меньше. :(

                                    А тут, как-то залез в код титульной страницы гугля и прям там мне их компактный код понравился, что пришла в голову мысль поизучать эту проблему поподробнее.
                                      0
                                      Ну дак как раз, Asp.Net имеет точку расширения в виде ViewEngine. Можно изгаляться там как хочется. Вьюхи вообще можно скомпилировать и запихать в ресурсники.

                      Only users with full accounts can post comments. Log in, please.