Настоящий Флеймер
Зарегистрирован:
16 August 2006
Сообщения: 1510
Примеры кода: 0
|
Re: Купил книжку "Разработка клиентских вэб-приложений на платформе .NET Framework". 70-528. |
18 October 2007 15:07 |
|
|
| Оценка 2.00. |
|
Устройтесь на работу в MS, и покажите им как делать настоящий robust софт. Это я пробовал. Где-то три месяца выдержал. И то еле-еле. Пока не стошнило. Моим начальником оказался какой-то бывший разводила из казино. Вибивать с него ЗП пришлось с помощью юридической службы МS. Могу сказать - что это САМАЯ ЗАМЕЧАТЕЛЬНАЯ служба в MS. Один звонок на мобильник этому разводиле из их же собственной юридической службы разрешил все вопросы с задолженностью просто в пять секунд. Не знаю, остался ли этот перец по-прежнему в MS - или уже перешел заниматься кидаловом опять в казино какое нибудь...
---
Вообще я еще книжку пробовал эту почитать... Ну раз уж деньги уплачены, прога все равно не работает... Но... Больше 10 минут я не выдержал...
Практически каждая фраза в ней - вранье или какие-то мутные недоговорки... Причем защищен этот бред ЕУЛОЙ.
1. Пролистываю введение и на четвертой странице (внизу) встречаю сразу же следующий перл:
"Каждый запрос вэб-страницы, отправляемый вэб-серверу, приводит к очистке окна вэб-браузера и отображению новой вэб-страницы. Такие технологии как AJAX позволяют веб-браузерам взаимодействовать с вэб-сервером без обновления вэб-страницы."
[q]Это неверно. [/q]Постбек не имеет никакого отношения к обновлению вэб-страницы (особенно в контексте данной главы, в которой описывается роли сервера и браузера и протокола HTTP.) Страница в браузере обновляется, когда браузер получает новую страницу от сервера.
2. Переворачиваю пару страниц и в глаза бросается следующий перл. "Наверное лучший способ разобраться в том, что происходит между веб-серверов и клиентом - это просматривать пакеты необработанных данных, передающиеся по сети. Еще один инструмент, применяемый для диагностики HTTP - утилита TELNET."
[q]Это неверно.[/q] Постбеки составляют килобайт по сто. Что-либо в этом сырье увидить без предварительной обработки невозможно. Лучший способ - без сомненья - NET-ALL в фаерфоксе.
3. Переворачиваем страничку и читаем стр 12. "Защищенный HTTP(HTTPS) использует порт 443".
[q]Это неверно.[/q] Точнее просто ерунда. Порт может быть ЛЮБОЙ. Например у меня сейчас https работает по порту 500. Эта фраза, возможно, и приобрела бы смысл, если бы в ней присутсвовала фраза ПО УМОЛЧАНИЮ. Между при описании HTTPS вообще неупомянуто про РЕАЛЬНЫЕ ограничения HTTPS - например не более одного такого соединения на один айпишник. Ну и ряд других. Информация о 443 порте бессмысленная и вводящая в заблуждение.
4. Ладно. Эту главу похоже читать тоже низзя. Пеереворачиваю пару страниц и на стр 20 натыкаюсь на фразу - "в одном вэб-приложении можно применять несколько языков."
[q]Это неверно.[/q] Точнее скрыто ГЛАВНОЕ. Классы в APP_CODE можно делать ТОЛЬКО НА ОДНОМ языке. Остальное понятно и значения не имеет.
5. Ладно. Со смыслом главы понятно. Посмотрим, что же предлашается в качестве проверки усвоенных знаний. Бегло просматриваю стр 23. Проверочные вопросы для усвоения знаний.
Смотрим на вопрос 2. "Сайт какого типа подойдет для работы с удаленным вэб-сервером, на котором установлены расширения Front Page Server Extension?
A. Сайт на основе удаленного HTTP-сервера.
B. Сайт, хранимый в локальных файлах.
С. Сайт на основе FTP-сервера.
D. Сайт на основер локального HTTP-сервера."
Логичный и разумный ответ - A. Но переворачиваем на страничку 715, чтобы проверить не разводят ли нас в очередной раз изобретатели неразменного рублика - ЕУЛЫ - обнаруживаем там следующий перл:
"А. Неверно. Этот вариант подходит только для локальных веб-серверов.
...
D. Верно. Это работает с Front Page Server Extension на удаленном компьютере."
Хм... Что за бред...
Ничего не понимаю, лезу в первоисточник на английском. И наблюдаю там следующее:
"2. If you want to create a new Web site on a Web server that is hosted by your ISP and the Web server has Front Page Server Extensions installed, what type of Web site would you create? (Choose one.)
A. Local HTTP
B. File
C. FTP
D. Remote HTTP"
Эх, ептырь, [q]дык это ж просто очепятка !!! [/q]Ответы перепутаны в русском варианте книге относительно английского. Но ответы оставлены в правильном порядке. Вот клево обучаться по такому учебнику!!!
6. Ладно, набираюсь терпения и решаюсь просмотреть еще одну главу чудо-книги. В ней описывается чрезвычайная полезность и ценность той трассировки, которая включается в страничку по директиве TRACE. Ну хотелось бы вообще-то сказать, что информация это в приниципе вообще бесполезная, ибо в ней не указываются имена мастер-пейдж для странички - из-за этого все валится скопом в событиях странички, и вся иерархия мастер-пейдж и вся иерархия контролов. По крайней мере раздел Trace Information из-за этого абсолютно бессмысленный. Ну а полезных разделов - типа расчета размеров SESSION - именно это всегда требуется - эта трассировка не содержит в принципе. Поэтому этой бесполезной прикруткой никто и никогда не пользуется. К тому же она В ПРИНЦИПЕ не работает с AJAX. Пишет обычно что-то такое: "Sys.Webform.PageRequestManagerParserExceptions: .... or server trace is enabled". Ну точнее, просто валит AJAX.
Ну ладно... понятно... читать это не будем, посмотрим сразу смысл этой главы. Стр 35. Проверочные вопросы для экзамена:
"2. Вы хотите включить трассировку для оперативного просмотра 10 последних запросов пользователей вашего вэб-сайта, но вас смущает возможность заполенния жесткого диска лишними данными. Какие настройки позволят решить эту задачу." И парвильный ответ.
D. <trace enabled="true" pagerequestlimit="10" PageOutpur="false" traceMode="SortByTime" Localonly="False" mostRecent="true" />
Причем вариант С отличается от этого только атрибутом mostRecent="false".
Хм... Что за бред вообще... Встроенная трассировка, выводимая прямо на страничку... И просмотр последних 10 запросов к сайту. Какая вообще между этими сущностями связь... Причем речь идет об экономии места на диске... Где - на сервере или на клиенте? Что вообще за бред?
Всегда для просмотров реквестов все пользовались ЖУРНАЛАМИ IIS.
Я бы конечно продолжил чтение этой книженции, но мое терпение на чтение поделок от изобретателей ЕУЛЫ истекло.
[q]Люди, не пользуйтесь рекомендациями этой книги. [/q]
1. Не верьте, что отправка постбека из браузера мгновенно стирает страничку в браузере. И только микрософтовский аякс спасает несчастную страничку от стирания. Стирание странички и отправка браузером постбека - вещи не связанные. Скорее, получение новой странички и стирание старой в браузере как-то связаны.
2. Не верьте, что лучших способ изучить взаимодействие между страничкой и сервером - это TELNET или сырой просмотр пакетов по сети. Пользуйтесь фаерфоксом - складки NET ALL.
3. Не верьте что HTTPS как-то связано с 443 портом. Это просто случайный и произвольный выбор админа.
4. Не верьте что ASP.NET приложения пишутся на РАЗНЫХ языках. Только старнички, НО НЕ КЛАССЫ.
5. Не думайте, что сайт созданный в локальном IIS пользуется какими УДАЛЕННЫМИ возможностями FrontPageServer Exstension на каких-то других удаленных вэб-серверах.
6. Не просматривайте 10 последних запросов к страничкам с помощью директивы <TRACE в конфиге. Пользуйтесь журналами IIS.
|
|