Для каждого j>0 заменить все присваивания L=j соответствующей подпрограммой Gj(в том числе и для L=1). Так как L больше никогда не будет присвоено значение j можно убрать проверку L=j (вместе с соответствующей ей веткой выполнения) из структуры программы.
выглядит как «inline» подпрограмм? эта затея осуществима для всех j>0, в любом случае? или тут схема маягче: «Для каждого j>0 пытаться заменить все присваивания L=j… », и «Если L больше никогда не будет присвоено значение j ...». Просто в данном примере заменились не все присавивания — «L=3» в структуре осталось.
Теперь построим цикл while do с заменой предикатных и функциональных блоков.
я правильно понимаю, что на этой схеме получилось нечто похожее на машину состояний — switch, в котором каждый case это подпрограмма, представляющая собой либо выбор нового значения L (одного из двух) либо выполнение операции и назначение нового L?:
L = 1
white L > 0:
switch L:
case 1: if p1 L = 2 else L = 3 ; break
case 2: f1; L = 6 ; break
...
case 8: f5; L = 0 ; break
Мне кажется для скрытия адресной строки есть разумное объяснение — google'у нужна связанность переходов. Для этого нужно, чтобы пользователи щелкали именно по ссылкам на страницах, а не меняли адресную строку как попало.
Значит в вашей системе эта логика является вполне нормальной — бизнес- — наверняка, окруженная полноценными тестами, документацией и проч. семейной атрибутикой. Нашим администраторам такая возможность не требуется. В итоге аналогичный код одиноко подвисает в слое тестов, в виде абсолютно неконтролируемой логики (чуть не сказал — женской). Получается, что интерпретация зависит от конкретного набора требований.
Так вот проблема — нужно-ли писать тесты для MotherObject или нет? :) Голос «за» — они рожают точно такие же объекты, какие появляются на свет у нормальной бизнес-логики (просто какими-то левыми сценариями). Голос «против» — кажется, это будут тесты, ради тестов.
Например, сценария createAndLoginUser() в реальном коде не существует — потому, что пользователей заводит администратор, но ни когда их не логинит. Логиняться пользователи всегда сами, но только в существующий аккаунт.
Однако в тестах очень часто участвуют именно такие вот залогиненные пользователи, поэтому от деталей их создания и логина хочется абстрагироваться. Думаю, такой код мог бы быть контроллером (если бы необходимость в такой логике, по факту, была не только в тестах).
Не знал, что это называется ObjectMother. Мы пришли к подобному паттерну, пытаясь абстрагироваться от часто повторяемых в тестах пользовательских сценариев (залогиниться, создать документ и т.п.). Поэтому называем такие фабрики UserScenario.
Только вот на душе остается какой-то не хороший осадок. Ведь эти «мамы», для того, чтобы рожать каких-то, прямо скажем, незапланированных детей, начинают «залетать» изрядными кусками сервисной логики. Причем эти куски, по своему характеру, очень напоминают соседей из business-logic — хоть тесты на них самих теперь пиши.
Вопрос о слабостях подразумевает, что в ответе вы узнаете про соискателя нечто, что возможно окажется за пределами ваших норм. Порядочный человек ни когда себе не позволит воспользоваться полученными сведениями для того, чтобы с пафосом уколоть соискателя в открывшееся слабое место, обеспечив себе ещё несколько гарантированных плюсиков. ;) Выше об этом уже писали.
Два этических вопроса:
1). Вы собеседуетесь с HR, которая уже наняла для компании 8 сотрудников. Двое из них тупые, трое — ленивые, один — умственно недоразвитый, сама она больна сифилисом. Посоветуете ли Вы ей освободить занимаемую должность?
Но прежде, чем ответить на этот вопрос, ответьте на другой:
2) Происходят выборы на должность программиста и Ваш голос — решающий. Краткие характеристики кандидатов:
а) ответил на все Ваши вопросы.
б) послал ко всем чертям.
Кого же Вы выбираете? Ответили?
Дневной оборот среднего предприятия, отправляющего платежи в банк, равен примерно сумме операций обычного физического лица за пол года-год. Отсюда мы получаем необходимость совсем разных систем для совершения операций там и там.
Получается, что в случае воровства данной суммы, предприятие находится в лучших условиях, нежели физик — физику-то нужно год «пахать», чтобы обернуть сумму, которую «среднее предприятие» оборачивает за день.
Физик вынужден гораздо чаще «светить» секретные реквизиты, совершая покупки в различных интернет- и оффлайн- магазинах.
У физика нет профессионального системного администратора, для квалифицированного обслуживания компьютера.
Банки предоставлют физикам заведомо более дырявые (удобные) способы доступа, с использованием ПО общего назначения, а так же упрощенные системы контроля операций со своей стороны.
Выходит, риски физика заведомо выше, чем у предприятия. В этой связи предложения банков в виде платного смс-информирования и страховок стоимостью 1-2% от максимальной суммы выплаты выглядят свежо и необычно. ;)
Вся спецификация вот тут rfc2396. Синаксис URI, в самом общем случае, имеет вид:
<scheme>:<scheme-specific-part>
Вот и весь обязательный синтаксис. Если посмотреть дальше, то окажется что и scheme не обязательна, т.к. существуют Relative URI. В остатке, по большому счету, важен только алфавит, а все остальные нюансы записи адресов — что считать обязательным, а что нет — это частное дело приложений.
Я понимаю вашу точку зрения. Думаю, корни заморочки нужно искать в том, что собой представляет архитектура клиент-сервер. Данная модель описывает *приложения*, которые состоят из нескольких взаимодействующих *программ*.
Модель назначает программам разные роли. Это дает опредленные бонусы разработчикам. Но с точки зрения конечного результата все это нужно воспринимать как составные части единого приложения. Т.е. сервер, браузер, прокси, джаваскипты, флеш-плееры и проч. это все программы, которые являются составными частями того приложения, результат работы которого вы можете наблюдать у себя на экране. Или не наблюдать, если какая-то программа падает. URL как таковые, тут совершенно не причем — они ни как не влияют на «живучесть» приложения в результате сбоев потому, что это всего лишь адреса. :)
Всё верно: трактовка адресов зависит от конкретного приложения — если фрагмент считается обязательным, значит так надо. Тут нет противоречий.
Можно провести аналогию с привычными адресами: для таксиста важно знать название улицы и номер дома, куда подать машину; для почтальона обязательным будет так же номер квартиры (ведь он не может оставить вашу телеграмму просто где-то возле дома).
довольно острую проблему в эпоху web 2.0, а именно чистоту URL-адресов.
Это нифига не проблема — «чистота» адресов и её полезность весьма субъективна. URI это идентификатор. Ну давайте ещё поборемся за чистоту айдишников).
Вот меняться они, по хорошему, не должны — здесь я согласен с авторской критикой.
# — это специальный символ URL, который сообщает браузеру, что последующая часть адреса представляет собой ссылку на HTML элемент с таким id или именованый якорь (named anchor) текущей страницы.
Это очень частный случай. По большому счету, часть url, именуемая fragment, указывает на фрагмент данных. Содержательный смысл этого термина, трактуется клиентом по собственному усмотрению. Например это может быть начальной позицией для отображения видеопотока, состоянием приложения, css-селектором для фрагмента html и т.п.
кажется, что вариант комменте по ссылке не верный — если условие b изначально '0', то хвост алгоритма (E) не выполнится ни разу.
Так вот проблема — нужно-ли писать тесты для MotherObject или нет? :) Голос «за» — они рожают точно такие же объекты, какие появляются на свет у нормальной бизнес-логики (просто какими-то левыми сценариями). Голос «против» — кажется, это будут тесты, ради тестов.
Однако в тестах очень часто участвуют именно такие вот залогиненные пользователи, поэтому от деталей их создания и логина хочется абстрагироваться. Думаю, такой код мог бы быть контроллером (если бы необходимость в такой логике, по факту, была не только в тестах).
Только вот на душе остается какой-то не хороший осадок. Ведь эти «мамы», для того, чтобы рожать каких-то, прямо скажем, незапланированных детей, начинают «залетать» изрядными кусками сервисной логики. Причем эти куски, по своему характеру, очень напоминают соседей из business-logic — хоть тесты на них самих теперь пиши.
Вопрос о слабостях подразумевает, что в ответе вы узнаете про соискателя нечто, что возможно окажется за пределами ваших норм. Порядочный человек ни когда себе не позволит воспользоваться полученными сведениями для того, чтобы с пафосом уколоть соискателя в открывшееся слабое место, обеспечив себе ещё несколько гарантированных плюсиков. ;) Выше об этом уже писали.
1). Вы собеседуетесь с HR, которая уже наняла для компании 8 сотрудников. Двое из них тупые, трое — ленивые, один — умственно недоразвитый, сама она больна сифилисом. Посоветуете ли Вы ей освободить занимаемую должность?
Но прежде, чем ответить на этот вопрос, ответьте на другой:
2) Происходят выборы на должность программиста и Ваш голос — решающий. Краткие характеристики кандидатов:
а) ответил на все Ваши вопросы.
б) послал ко всем чертям.
Кого же Вы выбираете? Ответили?
по-моему, ответ соискательницы это равноценный троллинг, в ответ на неэтичный, по сути, вопрос.
Получается, что в случае воровства данной суммы, предприятие находится в лучших условиях, нежели физик — физику-то нужно год «пахать», чтобы обернуть сумму, которую «среднее предприятие» оборачивает за день.
Физик вынужден гораздо чаще «светить» секретные реквизиты, совершая покупки в различных интернет- и оффлайн- магазинах.
У физика нет профессионального системного администратора, для квалифицированного обслуживания компьютера.
Банки предоставлют физикам заведомо более дырявые (удобные) способы доступа, с использованием ПО общего назначения, а так же упрощенные системы контроля операций со своей стороны.
Выходит, риски физика заведомо выше, чем у предприятия. В этой связи предложения банков в виде платного смс-информирования и страховок стоимостью 1-2% от максимальной суммы выплаты выглядят свежо и необычно. ;)
Вот и весь обязательный синтаксис. Если посмотреть дальше, то окажется что и scheme не обязательна, т.к. существуют Relative URI. В остатке, по большому счету, важен только алфавит, а все остальные нюансы записи адресов — что считать обязательным, а что нет — это частное дело приложений.
Модель назначает программам разные роли. Это дает опредленные бонусы разработчикам. Но с точки зрения конечного результата все это нужно воспринимать как составные части единого приложения. Т.е. сервер, браузер, прокси, джаваскипты, флеш-плееры и проч. это все программы, которые являются составными частями того приложения, результат работы которого вы можете наблюдать у себя на экране. Или не наблюдать, если какая-то программа падает. URL как таковые, тут совершенно не причем — они ни как не влияют на «живучесть» приложения в результате сбоев потому, что это всего лишь адреса. :)
=)
Можно провести аналогию с привычными адресами: для таксиста важно знать название улицы и номер дома, куда подать машину; для почтальона обязательным будет так же номер квартиры (ведь он не может оставить вашу телеграмму просто где-то возле дома).
Это нифига не проблема — «чистота» адресов и её полезность весьма субъективна. URI это идентификатор. Ну давайте ещё поборемся за чистоту айдишников).
Вот меняться они, по хорошему, не должны — здесь я согласен с авторской критикой.
Это очень частный случай. По большому счету, часть url, именуемая fragment, указывает на фрагмент данных. Содержательный смысл этого термина, трактуется клиентом по собственному усмотрению. Например это может быть начальной позицией для отображения видеопотока, состоянием приложения, css-селектором для фрагмента html и т.п.