Чертовски верно, к сожалению. Ибо так хочется, чтобы написанное автоматически становилось частью тебя. Поэтому я даже сам себе благодарен за статью :), поскольку периодически надо напоминать, а как же поступать правильно. Эдакий рефакторинг текущей деятельности.
Принцип «Не боятся ответственности за свои ошибки» работает и в простой, отличной от фриланса, жизни.
В точку. Я только-только начинаю избавляться от привычки в быту обвинять во всем правительство :)
И, я бы сказал, что заказчик виноват только в одном случае — невыполнении своих обязательств.
Этот принцип, безусловно, главенствует. Но непрофессиональный заказчик — это дико скучно. Особенно люблю слушать своих коллег, к которым постоянно приходят люди с желанием сделать быстро сайт, начать что-то продавать и жить припеваючи, при этом не обладая никакими знаниями в области того, торговлей чем они собираются заниматься.
Ох тыж ёжик, а я дурак сранивал :) Говорили мне учителя, не сравнивать несравнимое и не впихивать невпихуемое :) Сразу скажу, я в этом деле чайник и считаю, что про мозг не знаю ничего. Есть только догадки и много вопросов. Например, почему игра в шахматы является «сложной системой с неизвестным поведением» и почему, скажем, по этой же игре я не могу сравнить поведение двух рассматриваемых «расчетных механизмов» в заданных условиях? Или говоря попросту, какой идиот свел Каспарова и Fritz'а :)
Да ну бросьте :) Какая еще машина может с такой скоростью перемалывать аудио/видео информацию, осуществлять столь качественный рендеринг без лагов и потери fps. А уж какие сценарии штампует во сне. Ученые только научили процессоры управлять роботами, которые ковыляя и спотыкаясь обходят препятствия, а наши малые дети в киндер-гардене за секунду выполняют больше движений, чем эти роботы с момента запуска в эксплуатацию. У нас настолько высока тактовая частота процессора в мозгу, что всевышний даже выкинуть таковый генератор. Единственное, о чем он забыл, так это дать возможность переключать GPU на решение математических задач, например. А то порой создается такое ощущение, что у нас центральный процессор какой-то ретро-раритет в виде Z80, а вокруг окружен специализированными аудио/видео/тактильными и прочими чипами с феноменальной производительностью :)
Частично так. В IIS нет сложной цепочки IIS->ISAPI->ASP.NET, теперь ASP.NET полноправный участник IIS7 pipeline'а, но при этом он просто один из ExecuteHandler's в нем, который может быть, а может и не быть. И если зайти в настройки сайта, то в разделе IIS мы увидим свои Error Pages, а в разделе ASP.NET — свои ".NET Error Pages". И error pages IIS'а, как и полагается, о web.config ничего не знают.
Да, 404 статус он по умолчанию не ставит, позволяя девелоперу самом решать, каков он будет. Нужно 404 — просто добавлем this.Response.StatusCode = 404; в OnInit/OnLoad/Render/по вкусу.
Начать ликбез можно с того, что данная фича к IIS не имеет вообще никакого отношения. Он даже уважаемым TC не упоминался, так что причина, по которой вы его вспомнили — не ясна. Продолжить можно тем, что конкретно этот инструмент был создан именно для редиректа. О чем можно было бы догадаться, увидев опции defaultRedirect, redirect и т.п. Т.е. он работает именно так, как задумывался, что справедливо может вызвать праведный гнев :)
Справедливости ради надо упомянуть, что с версии 3.5 есть параметр redirectMode, который может быть либо в режиме redirect, либо в режиме rewrite, который снимает вопрос с повестки дня :)
ASP.NET, а точнее aspnet_isapi.dll — это один из ISAPI extensions под IIS. И обработкой файла web.config, частью которого является рассматриваемый раздел занимается исключительно он. Если быть совсем точным, то метод HandleError класса System.Web.UI.Page. Естественно, IIS о нем не знает вообще ничего. Взял первый попавшийся в сети пример — support.asus.com/test.aspx. Работает, как и декларировано, через редирект, поскольку обрабатывается aspnet_isapi.dll. Но стоит поставить расширение html, которое в данном случае им не обрабатывается — support.asus.com/test.html, так сразу видим родную ошибку 404 от IIS без всяких редиректов.
Категорически согласен, даже где-то ниже об этом писал. Тогда бы в точности соответствовало и стилю ООП-писанины. Как пишем Process.Start(...), так бы и коммандлеты писали Process-Start.
вообще-то, «alias ls» на баше — это просто «gi ls», либо «ga ls», в зависимости от используемого провайдера, а в 36 символах решается совершенно другой вопрос. Ну да кого это волнует.
Я всегда думал, что и procfs и ps суть просто обертки вокруг функций ядра и сами реализации означенной функции они не содержат. Что до функциональности, то точно также я могу для алиасов получит модули, в которых реализованы их команды. Например
$a = gi ls #получил объект алиаса для ls
$a.ResolvedCommand.DLL
А для чего я упомянул ранее LDTP, dogtail и т.п. не дошло? Или приложения, их использующие — не «тулкитозависимые»? То, что не костыли я знаю точно, это только убогие вроде меня пишут шняги под винду, ну а вы, конечно, бох :) Посмотрел задачки в вашем блоге, куда уж мне :)
В этом и главное преимущество пайпа — мы можем передавать некоторую информацию, не имеющую конкретного представление в машинном виде, но имеет представление в голове автора скрипта. При этом текстовая сериализация обладает рядом качеств:
Вообще я предполагал, что всякая информация имеет машинное представление и строка в UTF-7 — в «машинном виде» — это не тоже самое, что строка UCS-4. Даже представление целых чисел может отличаться в зависимости от платформы, а уж про вещественные, даты я вообще молчу. Поэтому когда я работал со строкой в шелле, то я привык воспринимать ее на бытовом уровне, как строку, не вдаваясь, как это выглядит в памяти. Когда я работаю с объектами — я знаю, что получить доступ к свойству объекта я могу через obj.Property, вызвать метод как obj.SomeFunc() и мне никогда не приходило в голову заморачиваться, а как же оно передается. Можете продемонстрировать хотя бы одну задачку, когда это важно?
1) Прозрачность — все что передается по пайпу, можно вывести на экран и ничего более, так же как и ничего менее не будет передано на вход другой программе. Облегчает поиск ошибок и мест их возникновения.
Если вы будете передавать картинку в бинарном виде по пайпу и попробуете ее вывести на экран, то ничего кроме мусора не получите. А я передавая картинку могу получить ширину, высоту, формат цвета, нарисовать параллелепипид и многое другое и все это вывести на экран. Поиск ошибок… Представим себе, что у меня есть переменная даты и времени в powershell'е. Чтобы получить день мне достаточно обратиться как: $d.Day. Теперь представим, что у нас есть текстовое представление даты, которое может быть по стандарту US — «mm/dd/yyyy», может ANSI — «yy.mm.dd», может GB — dd/mm/yyyy, может DE — «dd.mm.yy», может ISO — "[yy]yymmdd". Как ты расшифруешь 01.02.03? Или если взять пример с картинками. Неужчто $img.Width гораздо более сложно диагностируемо для ошибок, чем identify -format "%w"? Не поверю, что операции с датами вроде «До пьянки осталось {0} секунд» -f ($d — [DateTime]::Now).TotalSeconds дается гораздо сложнее, чем аналогичные операции в текстовом виде. И вряд ли в баше 2+2 будет 22. Или для вас скриптинг — это только пайп?
2) Гибкость — сущность, которая передается по пайпу, может меняться очень быстро, например список_пользователей -> e-mail -> md5hash -> url -> avatar.png -> vCard. Для полноценного обьектного пайпа вам пришлось бы реализовать каждую из этих сущностей отдельно и заставить каждую программу понимать эти сущности. Более того, вам придется сохранять обратную совместимость с текстовым представлением сущности. Это накладно, нудно, менее надежно.
Сколько времени работаю с повершеллом и впервые слышу о таких проблемах. Можно пример конкретизировать, а лучше в полном виде, что бы я воспроизвел и мы могли сравнить.
3) Совместимость. Проблемы обмена информацией с машинами, работающими под другой версией системы/другой архитектурой, проблемы бинарной несовместимости старых версий программ или отсутствуют, или решаются ещё одной командой.
Вообще-то объекты .NET замечательно (де)сериализуются хоть бинарно, хоть в xml. Я могу любому пайпу сделать в хвосте Export-CLIXML, а на другом хосте начать пайп с Import-CLIXML. Тут тебе и текст и разметка, а значит данные не зависят от форматирования, которое было использовано на исходной машине.
С другой стороны, современные *nix шеллы не заточены под работу со сложными структурами данных. Эта задача разрешима либо grep/sed/awk в простых случаях, либо программой на perl/python/your-favorite-language в пайпе.
Т.е. решение, которое лаконично как шеллы и имеет возможности языков высокого уровня априори плохое?
В точку. Я только-только начинаю избавляться от привычки в быту обвинять во всем правительство :)
Этот принцип, безусловно, главенствует. Но непрофессиональный заказчик — это дико скучно. Особенно люблю слушать своих коллег, к которым постоянно приходят люди с желанием сделать быстро сайт, начать что-то продавать и жить припеваючи, при этом не обладая никакими знаниями в области того, торговлей чем они собираются заниматься.
Да ну бросьте :) Какая еще машина может с такой скоростью перемалывать аудио/видео информацию, осуществлять столь качественный рендеринг без лагов и потери fps. А уж какие сценарии штампует во сне. Ученые только научили процессоры управлять роботами, которые ковыляя и спотыкаясь обходят препятствия, а наши малые дети в киндер-гардене за секунду выполняют больше движений, чем эти роботы с момента запуска в эксплуатацию. У нас настолько высока тактовая частота процессора в мозгу, что всевышний даже выкинуть таковый генератор. Единственное, о чем он забыл, так это дать возможность переключать GPU на решение математических задач, например. А то порой создается такое ощущение, что у нас центральный процессор какой-то ретро-раритет в виде Z80, а вокруг окружен специализированными аудио/видео/тактильными и прочими чипами с феноменальной производительностью :)
Вообще я предполагал, что всякая информация имеет машинное представление и строка в UTF-7 — в «машинном виде» — это не тоже самое, что строка UCS-4. Даже представление целых чисел может отличаться в зависимости от платформы, а уж про вещественные, даты я вообще молчу. Поэтому когда я работал со строкой в шелле, то я привык воспринимать ее на бытовом уровне, как строку, не вдаваясь, как это выглядит в памяти. Когда я работаю с объектами — я знаю, что получить доступ к свойству объекта я могу через obj.Property, вызвать метод как obj.SomeFunc() и мне никогда не приходило в голову заморачиваться, а как же оно передается. Можете продемонстрировать хотя бы одну задачку, когда это важно?
Если вы будете передавать картинку в бинарном виде по пайпу и попробуете ее вывести на экран, то ничего кроме мусора не получите. А я передавая картинку могу получить ширину, высоту, формат цвета, нарисовать параллелепипид и многое другое и все это вывести на экран. Поиск ошибок… Представим себе, что у меня есть переменная даты и времени в powershell'е. Чтобы получить день мне достаточно обратиться как: $d.Day. Теперь представим, что у нас есть текстовое представление даты, которое может быть по стандарту US — «mm/dd/yyyy», может ANSI — «yy.mm.dd», может GB — dd/mm/yyyy, может DE — «dd.mm.yy», может ISO — "[yy]yymmdd". Как ты расшифруешь 01.02.03? Или если взять пример с картинками. Неужчто $img.Width гораздо более сложно диагностируемо для ошибок, чем identify -format "%w"? Не поверю, что операции с датами вроде «До пьянки осталось {0} секунд» -f ($d — [DateTime]::Now).TotalSeconds дается гораздо сложнее, чем аналогичные операции в текстовом виде. И вряд ли в баше 2+2 будет 22. Или для вас скриптинг — это только пайп?
Сколько времени работаю с повершеллом и впервые слышу о таких проблемах. Можно пример конкретизировать, а лучше в полном виде, что бы я воспроизвел и мы могли сравнить.
Вообще-то объекты .NET замечательно (де)сериализуются хоть бинарно, хоть в xml. Я могу любому пайпу сделать в хвосте Export-CLIXML, а на другом хосте начать пайп с Import-CLIXML. Тут тебе и текст и разметка, а значит данные не зависят от форматирования, которое было использовано на исходной машине.
Т.е. решение, которое лаконично как шеллы и имеет возможности языков высокого уровня априори плохое?