Главная

Главная


История одной заглушки Давным давно, в XIII веке, в Праге начиналось строительство одной из теперешних святынь Чехии - Собора Святого Вита. Его сооружение растянулось на столетия. Времена тогда были другие, про agile-разработку никто и не слыхивал, так что к делу приступили серьезно и основательно. Первое время все шло как по маслу, но потом заказчик начал проявлять некоторое нетерпение и интересоваться результатами. По правде признаться, это было уже второе поколение заказчиков - Карл IV к тому времени благополучно скончался и контрольный пакет чешского королевства попал к его сыну Вацлаву.

Посетовав на несовершенство тогдашних методологий и затянутость первой итерации (более сорока лет) Вацлав деликатно намекнул, что пора мол и релиз какой-нибудь выставить. Чем раньше выставим версию - тем раньше начнем получать прибыль.

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

Метр Парлеж, занимавший тогда должность главного архитектора проекта, срочно проводит кризис-митинг, в результате которого была выбрана важнейшая с точки зрения бизнеса user-story: "пользователи могут прийти и помолиться".

Вот тогда-то кто-то и предложил: "а давайте пока по быстрому сделаем заглушечку". И был построен провизориум - стена, закрывавшая хор поперек сроящегося собора. Это дало возможность а) освятить храм, значительно повысив его карму и б) дать простым пользователям место, где бы они могли спокойно помолиться, без необходимости пробираться в каске по стройплощадке.
Времена тогда все еще были другие, делали все обстоятельно ... так что и заглушка благополучно простояла более полутысячи лет.

К чему это я все? [читать дальше]

Team Foundation Server Сразу о главном: Виктор Шатохин выложил полную версию замечательного документа "Групповая разработка с использованием Visual Studio Team Foundation Server. Шаблоны и практики." в русском переводе.

Чтобы понять, чем же он такой замечательный, вспомните, где вы брали информацию о TFS с появлением сначала беты, а потом и релиза этого продукта? [читать дальше]

Когда-то Борхес писал, что историй - всего четыре. Одна, самая старая — об укрепленном городе, который штурмуют и обороняют герои. Вторая, связанная с первой, — о возвращении. Третья история — о поиске. Последняя история — о самоубийстве бога. И сколько бы времени нам ни осталось, мы будем пересказывать их — в том или ином виде.

Так, и в программировании, есть несколько вечных историй. Одна, самая старая - о проекте, который практически готов, осталось только ... Вторая, связанная с первой, - о планировании "в следующий раз мы обязательно уложимся в срок, потому что ...". А вот еще одна - о настройке окружения для нового участника проекта. [читать дальше]

Давайте теперь посмотрим, как можно реализовать наши требования при помощи ISAPI Rewrite.

1. Работа с поддоменами
Во-первых, нужно связать наше веб-приложение с нужными доменами под IIS. Делается это в оснастке IIS, при помощи диалога "Advanced Web Site Identification", показанного на рис. 1. В нем мы дожны перечислить все варианты интересующих нас поддоменов, а именно: [читать дальше]

А теперь пришло время понять, зачем мы разбирали нелегкий жизненный путь запросов :) Вспомните, кроме всего прочего, мы хотели перенаправлять urls типа http://news.ru/fooball/. Все ли мы сделали, чтобы работать с такими запросами? Уже догадались, в чем дело? Правильно! Все, о чем мы только что говорили, реализовано в нашем веб-приложении на ASP.NET. Но для того, чтобы ему выполнить rewriting, он должен как минимум получить управление. По умолчанию IIS настроен так, чтобы передавать управление ASP.NET при запросах страниц с расширением .aspx (и еще некоторых расширений). Если же он получит запрос без расширения, то будет думать, что это каталог и попробует определить для этого пути документ по умолчанию - то есть сделает вовсе не то, что нам нужно. [читать дальше]

1. Итак, IIS передает ход ISAPI Application aspnet_isapi.dll, а тот, в свою очередь, перенаправляет запрос процессу w3wp.exe (для Windows 2003) или aspnet_wp.exe (если у вас Windows XP), которые и являются движками, для выполнения ASP.NET прилолжений.

2. Здесь картина опять повторяется. Сначала ASP.NET по очереди вызывает все модули (HttpModules), зарегистрированные для web-приложения. Для этого просматриваются секции всех конфигурационных файлов, начиная от корневого machine.config и заканчивая web.config файлом, ближе всех расположенным к вызываемой странице. Именно таким образом вызываются системные модули типа Session (поддерживающий понятие "сессия") или FormsAuthentication (выполняющий аутентификацию пользователей). [читать дальше]

К сожалению, это не название какой-то технологии или библиотеки. Это всего-то значит, что url rewriting мы можем реализовать и сами. Сразу хочу вас успокоить, есть несколько библиотек, которые реализуют эту идею, их мы рассмотрим ниже. Но, во-первых, всегда лучше знать, по какому принципу что-то работает (помните, "знание общих принципов заменяет незнание отдельных фактов"), а во-вторых, часто для счастья нужно совсем чуть-чуть, но вот этого чуть библиотека и не позволяет. Так что посмотрим, как можно реализовать rewriting своими руками. [читать дальше]

Если вы попали на эту страницу с поискового сервера - вам не нужно объяснять зачения этих слов. Cтатья поможет вам упорядочить картину "URL rewriting, что и как я могу сделать", а так же понять, что находится в арсенале разработчика ASP.NET, плюсы и минусы основных решений.

Если же вы зашли сюда по старой памяти, давайте взглянем на слова "SEO, user and serach engine friendly urls, improving the search relevancy, protect site content". Если выражение вашего лица стало хоть чуть более заинтересованным - наливаем кофе, устраиваемся поудобнее и читаем дальше.

Для того, чтобы уйти от общих фраз, давайте сразу представим себе реальный пример: скажем, владелец домена news.ru заказал у вас разработку новостного портала. И как у нас водится - это должен быть портал всех порталов, убийца остальных новостных ресурсов и т.д. Он будет содержать десятки тысяч новостей, разбитых по категориям и темам и, естественно, должен быть вооружен последними достижениями SEO, чтобы максимально ускорить вожделенный и столь горячо обсуждаемый процесс "монетаризации".

Что нам может понадобится? [читать дальше]

Вы начали разработку нового web-приложения. Аналитики обсудили с заказчиком и утвердили ТЗ. Заказ на макет первой страницы ушел в студию web-дизайна (если в вашей компании есть собственный дизайнер, все становиться проще). Его утвердили и дизайнеры принялись нарезать макет в html. Команда разработчиков получила спецификации и html-прототип дизайна, запустила Visual Studio и с энтузиазмом ломанулась навстречу премии за успешное завершение проекта.

Если во время чтения последней строки у вас появилась скептическая улыбка - читайте дальше, возможно эта статья вам пригодится :) [читать дальше]

Все вы, наверное, помните holy wars "Windows vs Linux" или "С++ vs Java"? Что-то вроде:

- А Винду зато любой чайник поставить может!

- А ты попробуй в Форточках поднять внутренний VPN под внешним, так, чтобы маршрутизацию не менять!

- А ты вот объясни нашей бухгалтерше, что значит: $ mount /media/cdrecoder1 && \ cp -Rv /media/cdrecoder1/* /d/ && \ umount /media/cdrecoder1 && eject

и т. д.

Улавливаете суть? Есть нечто, с чем может начать работу даже неподготовленный пользователь, но оно ставит его в тупик, когда появляются более сложные задачи. И есть еще что-то, для работы с которым не обойтись без серьезных знаний. Зато оно позволяет легко решать сложные задачи тем, кто этими знаниями таки обладает. [читать дальше]