Сейчас пришла пора разобраться с тем, что происходит с кодом от момента написания ASPX/ASCX- разметки и CS-кода до момента их физического выполнения в виде некоторого скомпилированного кода на сервере.

Судя по результатам голосования, которое я проводил в своём блоге, большинство пользователей никак не типографируют тексты перед публикациями (НЛО не считается). Те, кто работают над текстами, в большинстве своём делают это вручную, поэтому я решил попробовать собрать воедино рецепты экранной типографики, дабы не забывать самому и напомнить другим. Не думаю, что статья будет чем‐то новым для опытных верстальщиков. Новички узнают, профи исправят :)

Содержание

1. Дефисы, тире, минусы и другие палочки
2. Кавычки и чёрточки
3. Скобки
4. Многоточие
5. Заголовки, списки

Вот, с грехом пополам, мы и добрались до финальной статьи. Она будет про сведение и мастеринг. Первым делом поясню чем сведение отличается от мастеринга, расскажу немного про такую штуку как SideChain и еще парочку трюков. В конце — небольшая таблица, которая до сих пор помогает мне при эквализации.

В первой статье в блоге .NET «Работаем с XML» в комментариях народ потребовал статьи LINQ to XML. Что же, попробуем раскрыть принципы работы этой новой технологии от Microsoft.

Создадим базу для ведения каталога аудиозаписей.

Введение.

Доброго времени суток. Я думаю, что абсолютное большинство из вас сталкивалось с проблемой расширяемости приложений. Точно также я думаю, что многим из вас приходилось копать Reflection для выяснения того, является ли сборка плагином к вашей программе. Многим не нравилось то, что в .NET сборки по умолчанию загружаются в один домен с приложением, а затем их нельзя было выгрузить. Многие, конечно, создавали объекты в отдельных доменах через CreateInstanceAndUnwrap, но всё это приходилось делать руками. В общем «мыши плакали и кололись…». С появлением System.Addin разработчики получили в свои руки инструмент для создания расширяемого приложения, который лишён этих проблем, что называется, «из коробки». Об этой технологии я и расскажу в нескольких статьях.

Собираюсь начинать новый проект и постепенно приближаюсь к стадии написания некоторых базовых вещей. Решил собрать и систематизировать свои знания об некоторых аспектах разработки ПО на платформе ASP.Net, полученные за более чем год коммерческой разработки. В результате получилась вот такая статья. Она не претендует на принципиально новые вещи, это все давно знают, в определенном смысле это своеобразные best practices. Все, что написано ниже, скорее всего пригодится новичкам, но и опытные разработчики смогут почерпнуть для себя что-нибуть интересное.

Управлять потоком можно не только свойствами clear или overflow. Возможно, вы найдёте полезным для себя использование display:inline-block или display:table-cell, способных полностью заменить вам упомянутый overflow, избавляя вас от опасности указания размеров элемента, а также предоставляя дополнительные возможности.

Статья не содержит универсальных решений, но открывает вашему взору дополнительный инструментарий для управления потоком.

«Совершенный Ajax» — новый подход к построению web-приложений, при котором web-сервер не генерирует ни строчки HTML-кода и взаимодействует с внешним миром только посредством web-служб; а клиентский интерфейс реализуется только на основе клиентских HTML, CSS, JavaScript.

Статья состоит из двух частей. В первой части — более живой и провокационной я постараюсь заинтересовать проблемой, рассказать о технологии «Совершенный Ajax» и показать ее применение на примере нашего проекта «Система Интерактивного Тестирования Знаний “Синтез”» (который имеет ряд интересных особенностей, таких, как использование серверного JavaScript на платформе Mozilla Rhino, прототипно-ориентированная ORM и поддержка SPARQL — языка запросов к Semantic Web).

Вторая часть – более занудная будет содержать много технических деталей и выйдет в следующий раз.

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


Попробуйте угадать: к какой архитектуре относятся web-приложения?

К клиент-серверной говорите? Я ожидал, что Вы так ответите :-)

Что ж, давайте разберемся. В клиент-серверной архитектуре выделяют:

• Сервер — отвечает за хранение данных и реализацию бизнес-логики приложения.
  
  
• Клиент — отвечает за взаимодействие с пользователем ^[1].
  
  

Реализация бизнес-логики на сервере и взаимодействие с пользователем на клиенте четко разделены.

Преимущества клиент-серверной архитектуры очевидны; мы их все знаем:

1. Бизнес-логика не смешивается с пользовательским интерфейсом.
2. Можно реализовать несколько клиентов с разными пользовательскими интерфейсами: интерфейс командной строки, оконный Windows-интерфейс, Flash, web-интерфейс, мобильный интерфейс и т.д.
3. Клиентский компьютер не требователен к ресурсам;
4. И т.д.

Но, относятся ли web-приложения к клиент-серверной архитектуре?

Действительно, в web-приложениях есть сервер, отвечающий за бизнес логику приложения.

Но! За реализацию интерфейса отвечает не клиент, а тоже сервер. На сервере происходит обработка клиентской формы. Сервер генерирует HTML-код пользовательского интерфейса.

Клиент, т.е. браузер лишь визуализирует уже готовый HTML-код интерфейса. Это, фактически, то же самое, что прицепить к серверу монитор и объявить этот монитор клиентом…

Хочу начать серию статей, посвящённых отладке ваших .NET приложений на стороне заказчика, а также оптимизации вашего кода. В связи с этим понадобиться немного подготовить вашу систему. В этой статье мы ознакомимся с различными инструментами для отладки приложений, немного углубимся в описание CLR, где это будет необходимо.