Функция, которая принимает обычное значение и возвращает результат в контексте (монадное значение), называется монадной функцией
не как могу сообразить, что к чему в примере с конями. в строчке:
List(pos) +'>>='+ raw_jumps +'>>='+ if_valid
функция raw_jumps используется совместно с оператором '>==' из монады List, значит она должна быть монадической.
по определению, функция raw_jumps должна принимать обычное значение координат, и возвращать результат в контексте (т.е. List(result)). но если посмотреть код выше, то функция определена иначе:
raw_jumps = lambda (x, y): [ ... ]
т.е. принимая координаты, функция возвращает объект встроенного типа list, который к монаде List не имеет отношения. или имеет? в чем магия?
Опишите простым и понятным языком, как взаимодействует пользователь с вашим приложением. Затем запишите все то же самое на алгоритмическом языке. Получите тест. Для большинства начинающих уже первый этап становится серьезным испытанием. :)
в данном примере нет итерации по списку. ;)
возможно, чтобы исключить путаницу, авторам нужно было воспользоваться collections.deque для реализации стека, а не list.
>Не очевидно, что метод test может принадлежать не классу Device (например, Device.init может возвращать объект Dispenser). А выглядит это так, будто Device.test существует.
определяющим фактором для fluent интерфейсов является сохранение контекста между вызовами методов (т.е. то, что метод возвращает self, а не что-то другое). поэтому en.wikipedia.org/wiki/Law_of_Demeter не нарушается и ни какой путаницы быть не может.
по большому счёту, смысл всей этой затеи состоит в том, чтобы упростить выражение, «вынеся за скобки» повторяющееся имя переменной. такое повторение часто получается при конфигурировании объектов.
существуют примеры реализации данного паттерна на уровне языка. например в VisualBasic, где программисты проводят массу времени, занимаясь конфигрурированием объектов:
With testObject
.Height = 100
.Text = "Hello, World"
.ForeColor = System.Drawing.Color.Green
.Font = New System.Drawing.Font(.Font, System.Drawing.FontStyle.Bold)
End With
В данном случае не нужно говорить «клиент» — такая подмена понятий приводит к искажению смысла (и нарушению инкапсуляции)). Если это происходит на практике, то неизбежно создаёт ситуацию когда «scrum не подходит». Вверять неподготовленному клиенту постановку продуктовых задач и взаимодействие с командой не только неразумно, это просто опасно.
В методологии scrum взаимодействие команды и невовлечённых представителей клиента (stakeholders, скажем) случается не часто и очень жестко регламентируется. Обычно команда взаимодействует с человеком, играющим конкретную роль — «Product Owner». PO это разумная прослойка между клиентом и разработчиками, которая конвертирует «хотелки» бизнеса, в требования, задачи и приоритеты, соответствующие продукту и понятные команде. Очевидно, что для этого нужно «быть в теме», и не всякая «манагерша проекта» способна играть роль PO.
Если строить аналогию, то PO как водитель автомобиля. Он должен разбираться в бизнесе примерно в той же мере в какой водитель — ориентироваться в городе. Он должен учитывать особенности продукта и команды в той же степени, в какой водитель учитывает особенности вверенного ему механизма. Т.е. с одной стороны — знать как из точки A попасть в точку Б, наиболее эффективным образом, не намотав лишние километры и не простояв лишние часы в пробках. С другой — не трогаться с места включив 5-тую передачу, не смотря на то, что она самая быстрая, планировать не только поездки, но и заправки, а так же время для мойки и тех.обслуживания.
по правде говоря, я не до конца понял, область применимости решения, предложенного в топике. Если речь идёт об учёте действий пользователей в системе, то модели об этом аспекте, в идеале, не должны знать ни чего (иначе, как ответить на вопрос «кто удалил объект?»), — тема интересна, но данное решение не подходит. Если же взаимодействие пользователя с моделью существенно, с точки зрения бизнес-логики, значит оно должно быть отражено в публичном интерфейсе модели — в таком случае пользователь будет передаваться явно, и threadlocals нафик не нужен.
Возможно, что threadlocals как лакмусовая бумажка, показывает потенциально опасные места в архитектуре. Меня настораживает, что предложенное решение привязывает модель к HTTP запросу. Т.е. пока модель используется сугубо как «штука, которая должна сохранять информацию из http запроса», всё здорово. Но если возникнет необходимость использовать модель из другого контекста — например, из консольной команды, где ни какого request нет и в помине — не знаю как в Pylons, но в Django будут заморочки, т.к. стек middleware в таком случае не отрабатывает.
это может быть решением. замечу только, что это чревато. ведь религиозная война на тему, почему так делается, например, в Pylons, и не делается в Django ещё не закончена). разработчики фреймворка вполне сознательно отключили профильную статью в своей вики code.djangoproject.com/wiki/CookBookThreadlocalsAndUser, где что-то подобное было описано.
в оригинале принцип звучал так: «What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.»
т.е. вообще говоря, LSP определяет некое условие, когда один тип объектов можно считать подтипом другого. и хотя и указатели, и классы имеют отношение к типам, но в целом, не сводятся только к ним. поэтому об этих вещах, в отношении данного принципа, можно говорить лишь в смысле каких-то частных интерпретаций.
кстати, принцип имеет импликативную форму (A => B), а это значит, что обратное утверждение в нём не сформулировано. следовательно, на основании данного принципа нельзя утверждать обратное: дескать, «правильное» наследование — когда S is a subtype of T — обеспечит неизменность поведения вашей программы при использовании объектов первого типа, вместо объектов второго типа. чем, кстати, в некоторых кейсах ООП активно пользуются — передавая программе разные объекты для того, чтобы изменить её поведение. образно говоря, хотя тип «колёса легкового автомобиля» являются конкретизацией типа «колёса», легковушка может вести себя на дороге по-разному, в зависимости от конкретной «резины».
в жизненном цикле программы можно условно выделить два периода: разработки и развития. в период разработки, когда все требования и код запросто помещаются в голове, эффект от TDD на фоне других методик не очень заметен. просто держите себя в руках, следуя классическим методикам программирования — ООД, паттерны, и что там ещё проходили в школе — и вы обязательно достигнете желаемого результата. преимущества от TDD появляются на втором этапе, когда, условно говоря, часть предыдущих разработчиков уже уволилась, а у оставшихся нюансы требований стёрлись из памяти. в отличие от людей, тесты не бросают работу и ни чего не забывают.
поэтому на коротких, одноразовых вещах (включая и описанные эксперименты на студентах) TDD не даст особых преимуществ, и запросто может оказаться экономически не выгодным. в проектах же, у которых этап развития существенно превышает этап разработки, TDD серьёзно сокращает издержки, снижая риски развала системы. думаю статистика лишь отражает вовлечённость людей в проекты того или иного рода.
мы начали использовать TDD в тот момент, когда развитие одного из наших сервисов пошло вразнос — когда каждое изменение стало откликаться появлением десятка багов в разных местах — стоимость модификаций перешла все разумные пределы и проект оказался на грани закрытия. начали с очевидного — стали описывать тестами требования высокого уровня (т.е. с приёмочных и интеграционных тестов). позже пришло понимание зачем нужно юнит-тестирование. к настоящему времени в проекте сменились два состава разработчиков. месяц назад мы закончили рефакторинг, затронувший почти половину кода. думаю, что без тестов это было бы сделать практически не реально, поскольку все требования наизусть уже не помнит ни кто.
Также то, что Unicode поддерживается только UTF-16, а не UTF-8, что было бы сильно логичнее.
ходят слухи, что ms office понимает csv в utf-8 когда в начале файла есть нужный BOM (так-ли это на самом деле не могу проверить за неимением сего чуда).
мм. интересно, это чудо как-то ограничивает количество пунктов в меню и количество символов в надписях? как реагирует если у уже открытого меню меняется описание javascript'ом (добавил 100 пунктов, через секунду убрал)? как решат проблему, что в меню можно добавить пункты с привычными пользователю названиями, но выполняющие совершенно иные действия?
кажется, дизайнеры выбрали себе действительно «серьёзную» ЦА: которая печатает одним пальцем, и воспринимает клавиатуру, в основном, как неотьемлемое ноутбучное украшение.
при «слепой» печати, когда кисти рук лежат на клавиатуре, и смотришь на экран, точки-индикаторы на клавишах находятся вне поля зрения, а индикатор на Caps Lock не будет видно совсем, ведь именно эта часть клавиши всегда закрыта мизинцем левой руки. зато перед глазами постоянно будут мелькать индикаторы питания, жесткого диска и т.п. фигня, которая бывает полезна лишь в редких случаях, в остальных лишь утомляет глаза.
отсутствие переходников hdmi/vga в комплекте означают дополнительные телодвижения для подключения внешнего монитора или проектора на презентациях. неужели такая «экономия» в комплектации действительно даёт недешевой модели сколь-нибудь существенное конкуретное преимущество в цене?
при всём уважении к марке, данная модель не вызывает желания её купить.
не как могу сообразить, что к чему в примере с конями. в строчке: функция
raw_jumpsиспользуется совместно с оператором'>=='из монадыList, значит она должна быть монадической.по определению, функция
raw_jumpsдолжна принимать обычное значение координат, и возвращать результат в контексте (т.е. List(result)). но если посмотреть код выше, то функция определена иначе: т.е. принимая координаты, функция возвращает объект встроенного типа list, который к монаде List не имеет отношения. или имеет? в чем магия?возможно, чтобы исключить путаницу, авторам нужно было воспользоваться collections.deque для реализации стека, а не list.
определяющим фактором для fluent интерфейсов является сохранение контекста между вызовами методов (т.е. то, что метод возвращает self, а не что-то другое). поэтому en.wikipedia.org/wiki/Law_of_Demeter не нарушается и ни какой путаницы быть не может.
по большому счёту, смысл всей этой затеи состоит в том, чтобы упростить выражение, «вынеся за скобки» повторяющееся имя переменной. такое повторение часто получается при конфигурировании объектов.
существуют примеры реализации данного паттерна на уровне языка. например в VisualBasic, где программисты проводят массу времени, занимаясь конфигрурированием объектов:
В методологии scrum взаимодействие команды и невовлечённых представителей клиента (stakeholders, скажем) случается не часто и очень жестко регламентируется. Обычно команда взаимодействует с человеком, играющим конкретную роль — «Product Owner». PO это разумная прослойка между клиентом и разработчиками, которая конвертирует «хотелки» бизнеса, в требования, задачи и приоритеты, соответствующие продукту и понятные команде. Очевидно, что для этого нужно «быть в теме», и не всякая «манагерша проекта» способна играть роль PO.
Если строить аналогию, то PO как водитель автомобиля. Он должен разбираться в бизнесе примерно в той же мере в какой водитель — ориентироваться в городе. Он должен учитывать особенности продукта и команды в той же степени, в какой водитель учитывает особенности вверенного ему механизма. Т.е. с одной стороны — знать как из точки A попасть в точку Б, наиболее эффективным образом, не намотав лишние километры и не простояв лишние часы в пробках. С другой — не трогаться с места включив 5-тую передачу, не смотря на то, что она самая быстрая, планировать не только поездки, но и заправки, а так же время для мойки и тех.обслуживания.
т.е. вообще говоря, LSP определяет некое условие, когда один тип объектов можно считать подтипом другого. и хотя и указатели, и классы имеют отношение к типам, но в целом, не сводятся только к ним. поэтому об этих вещах, в отношении данного принципа, можно говорить лишь в смысле каких-то частных интерпретаций.
кстати, принцип имеет импликативную форму (A => B), а это значит, что обратное утверждение в нём не сформулировано. следовательно, на основании данного принципа нельзя утверждать обратное: дескать, «правильное» наследование — когда S is a subtype of T — обеспечит неизменность поведения вашей программы при использовании объектов первого типа, вместо объектов второго типа. чем, кстати, в некоторых кейсах ООП активно пользуются — передавая программе разные объекты для того, чтобы изменить её поведение. образно говоря, хотя тип «колёса легкового автомобиля» являются конкретизацией типа «колёса», легковушка может вести себя на дороге по-разному, в зависимости от конкретной «резины».
поэтому на коротких, одноразовых вещах (включая и описанные эксперименты на студентах) TDD не даст особых преимуществ, и запросто может оказаться экономически не выгодным. в проектах же, у которых этап развития существенно превышает этап разработки, TDD серьёзно сокращает издержки, снижая риски развала системы. думаю статистика лишь отражает вовлечённость людей в проекты того или иного рода.
мы начали использовать TDD в тот момент, когда развитие одного из наших сервисов пошло вразнос — когда каждое изменение стало откликаться появлением десятка багов в разных местах — стоимость модификаций перешла все разумные пределы и проект оказался на грани закрытия. начали с очевидного — стали описывать тестами требования высокого уровня (т.е. с приёмочных и интеграционных тестов). позже пришло понимание зачем нужно юнит-тестирование. к настоящему времени в проекте сменились два состава разработчиков. месяц назад мы закончили рефакторинг, затронувший почти половину кода. думаю, что без тестов это было бы сделать практически не реально, поскольку все требования наизусть уже не помнит ни кто.
кажется, дизайнеры выбрали себе действительно «серьёзную» ЦА: которая печатает одним пальцем, и воспринимает клавиатуру, в основном, как неотьемлемое ноутбучное украшение.
при «слепой» печати, когда кисти рук лежат на клавиатуре, и смотришь на экран, точки-индикаторы на клавишах находятся вне поля зрения, а индикатор на Caps Lock не будет видно совсем, ведь именно эта часть клавиши всегда закрыта мизинцем левой руки. зато перед глазами постоянно будут мелькать индикаторы питания, жесткого диска и т.п. фигня, которая бывает полезна лишь в редких случаях, в остальных лишь утомляет глаза.
отсутствие переходников hdmi/vga в комплекте означают дополнительные телодвижения для подключения внешнего монитора или проектора на презентациях. неужели такая «экономия» в комплектации действительно даёт недешевой модели сколь-нибудь существенное конкуретное преимущество в цене?
при всём уважении к марке, данная модель не вызывает желания её купить.