По изоляции мне нравятся больше интеграционные тесты, по тестируемому объекту — функциональные. У таких тестов очень большое покрытие кода, это и плюс и минус одновременно… они достаточно быстро проходят (3-4 минуты ~250 тестов)
как будто про нас. :) тоже с этого начинали. и щастье при первом рефакторинге. и разочарование, когда более-менее освоили метод, а количество тестов перевалило за сотню — запуск занимает какое-то неразумное время, при этом видно невооруженным глазом, что получаемая польза не оправдывает вложения.
чем крупнее кусок системы, охватываемый тестом, тем больше у него параметров состояния и тем меньше шансов проверить, пускай даже лишь существенные, их комбинации, ничего не упустив. при этом, чем больше глубина куска (по задействованным уровням системы), тем менее очевидны связи между этими параметрами, с точки зрения внешнего наблюдателя, коим является тест.
мне кажется, что «большое покрытие кода» интеграционными тестами — иллюзия. как раз о коде они дают лишь крайне поверхностное, оценочное представление. по сто раз дергают одни и те же куски, пропуская значимые граничные аспекты. отсюда эффективность. данный вид тестов хоть и хорош в начале, но в качестве основного средства tdd-разработки не особо практичен. вроде как хождение на четвереньках.
в то время (2007) рендер freetype оставлял желать лучшего. но эти проблемы как раз относились к низким, монтиорным, dpi. на высоких dpi пляски с antialiasing и cleartype не нужны. а на печати всё было достойно. не в последнюю очередь потому, что система рендера X всю свою сознательную жизнь ориентировалась на dpi (истоки которой можете поискать в 80x по словам «PostScript» и «Apple»), и только сейчас впала в маразм.
По мне, так уже сама абстракция над if-else кажется избыточной:
def wrapper(request, *args, **kwargs):
if not condition_func(request, *args, **kwargs):
return false_func(request, *args, **kwargs)
return view(request, *args, **kwargs)
Если много потрудится, то в пределе всю логику можно выразить в виде функций и их применения, только зачем? Ведь процедурный подход в python прекрасен.
Кстати, в django присутствует схожий по смыслу механизм — стек middleware. Поэтому, в качестве альтернативы пляскам вокруг декораторов, было бы любопытно посмотреть в сторону адаптации его механизмов, под нужны отдельных view.
при указании в win, dpi, отличного от дефолтного, во многих приложениях получал странный эффект — как будто окно отрисовывается в 96dpi, а затем масштабируется с указанным коэффициентом. по сравнению с этой живописью даже jpeg отдыхает. так что не надо нам таких коэффициентов.
я не понимаю, как это случилось. для xft и gnome2 размеры всю жизнь указывались именно в dpi, а cairo, которая используется основными gtk2 движками, чудесно подцепляла эти настройки. что ещё нужно? я не припомню, чтобы у приложений были проблемы с большими dpi. наоборот, лишь при dpi выше 100 всё начинало выглядеть достойно. проблемы были с маленькими dpi — кажется, 72dpi на старых элт-мониторах, — но это другая тема.
в gtk3 откуда-то вплыли коэффициенты масштабирования с базой 96dpi, единицы измерения типа «1024 * dots/inch» и прочий бред. совершенно непонятно, что они там курили. но сейчас убунта на высоких dpi в самом деле представляет собой полный шг. и ппц (подозреваю, что ноги сего технического чуда, растут откуда-то из недр движков css и javascript, которые позаимствованы gnome3 известно откуда).
Другую знакомую уволили в результате по статье «пьянство», хотя она вообще не пьет. Ей нельзя по здоровью. Но нашлась куча свидетелей, что она «неоднократно приходила на работу в хлам», а так же «постоянно упортебляла на работе».
… подавляющее большинство новых работодателей, звонит предыдущим, для проверки. Ну а там могут рассказать все что угодно. И думаю ЗП за 3 месяца покажутся полной фигней после 6-8 месяцев безуспешных попыток устроится на работу.
ну вот кошмарить то зачем? как раз это просто доказывается. сила в правде. нужно иметь лишь каплю упорства и при таком раскладе «предыдущие» будут хлебать баланду. хеппиенд. :)
серьёзно, во время недавнего кризиса ходили подобные байки. но как показала практика, та же куча свидетелей, предупрежденных об ответственности за дачу ложных показаний, с не меньшим усердием начинает свидетельствовать против работодателя. это ж не уголовники какие-то и нормально идут на сотрудничество. ведь даже самые упоротые осознают, что точно в таком же положении находится каждый из них.
у моих знакомых прямо обратная ситуация. компания российского масштаба, занимается бурением. сезонные работы, вахтовый метод. и работяг отбирают как космонавтов. не в последнюю очередь потому, что уволить неподходящего сотрудника по нашим законам крайне сложно. даже за пьянку. волокита, и месяцами длящиеся суды, отнимают кучу ресурсов. работяги, в общем-то, так же юридически неграмотны, как и офисные одуванчики. но упорны, и не столь наивны. вероятно потому, что деваться им больше не куда. в прочем, это уже полный офф.
маркет же. такие сервисы не про разработку, а про продажи (речь не обязательно о деньгах). можно предположить, что назначение ленты отзывов (она так называется — не комментов) это собирание казуального фидбека и информирования других пользователей о проблемах в приложении. т.е. подобие «жалобной книги». отсюда её нарочитая односторонность. если комменты разработчиков будут отображаться в общей ленте, то они так же станут формировать настроение потенциальных пользователей, превратив блок, фактически, в рекламную площадку. кроме того — новая фича может стать механизмом для рассылки отозвавшимся таггерированного спама.
зы: знаете, мне определенно нравится ход ваших рассуждений. «для простоты рассмотрим баланс в кассе нашей организации. вот приход, вот расход. не трудно заметить, что ни какой вашей зарплаты здесь нет — присутствует исключительно синтаксический сахар.» :)
нет ни какого строго смысла. конкретные термины отражают конкретные понятия — воспринимаются как есть и употребляются целиком. ну нельзя их делить на слова, дабы извлечь какой-то собственный смысл. иначе можно далеко зайти рассуждая, в строгом смысле, скажем, о морских свинках)
В данном определении нам интересен термин отношение, но пока оставим его без строго определения. Лучше представим себе таблицу продуктов.
по идее, термин «отношение» должен быть знаком со школы — например, бинарное отношение равенства (=) чисел в математике. бинарное, потому что ставит в соответствие пару — чисел (x, x). а ещё каждый программист постоянно имеет дело с булевой алегброй и логическим отрицанием not x — одинарным (унарным) отношением.
кстати о логике. кроме всего прочего, отношение можно определять через функцию, принимающую некоторое количество параметров и возвращающую логическое True, либо False (т.е. предикат). скажем, то же равенство можно выразить предикатом двойкой аргументов вида eq (x, y), а отрицание — not (x) — с одним. можно вообразить функцию, принимающую 3-ку параметров foo(x,y,z) и т.д. «n-ка принадлежит отношению тогда и только тогда, когда предикат на ней возвращает значение True (или «истинно»)».
допустим, нас интересуют утверждения о том, что некоторый водитель типа Driver имеет отношение к некоторой компании типа Company. функция-предикат будет иметь вид (тип):
function Boolean company_driver (Company company, Driver driver);
короче, речь идёт о 2-ках вида (company, driver). переходя на множества, на псевдо-sql-подобном языке, отношение между компаниями и водителями можно объявить как-то так:
действительно, это чем-то похоже на таблицу, и отношения часто таком виде изображают. но есть ключевые отличия. например, очевидно, что порядок записи утверждений (кортежей, строк) в отношении, имеет ни какого значения. так же бессмысленно записывать одно и то же утверждение дважды. в таблицах это не так. и да — популярные реляционные базы работают-таки с таблицами.
в общем, реляционная алгебра — это такая навороченная логика. а ценность реляционных баз состоит в том, что они с лёгкостью оперируют миллионами утверждений, касательно различных фактов, за считанные мгновения, предоставляя мощные средства для создания логической модели предметной области вашего приложения. можно использовать и для других целей, например, для хранения данных =) — но скорее будет хреново (см. NOSQL).
чем крупнее кусок системы, охватываемый тестом, тем больше у него параметров состояния и тем меньше шансов проверить, пускай даже лишь существенные, их комбинации, ничего не упустив. при этом, чем больше глубина куска (по задействованным уровням системы), тем менее очевидны связи между этими параметрами, с точки зрения внешнего наблюдателя, коим является тест.
мне кажется, что «большое покрытие кода» интеграционными тестами — иллюзия. как раз о коде они дают лишь крайне поверхностное, оценочное представление. по сто раз дергают одни и те же куски, пропуская значимые граничные аспекты. отсюда эффективность. данный вид тестов хоть и хорош в начале, но в качестве основного средства tdd-разработки не особо практичен. вроде как хождение на четвереньках.
Если много потрудится, то в пределе всю логику можно выразить в виде функций и их применения, только зачем? Ведь процедурный подход в python прекрасен.
Кстати, в django присутствует схожий по смыслу механизм — стек middleware. Поэтому, в качестве альтернативы пляскам вокруг декораторов, было бы любопытно посмотреть в сторону адаптации его механизмов, под нужны отдельных view.
в gtk3 откуда-то вплыли коэффициенты масштабирования с базой 96dpi, единицы измерения типа «1024 * dots/inch» и прочий бред. совершенно непонятно, что они там курили. но сейчас убунта на высоких dpi в самом деле представляет собой полный шг. и ппц (подозреваю, что ноги сего технического чуда, растут откуда-то из недр движков css и javascript, которые позаимствованы gnome3 известно откуда).
ну вот кошмарить то зачем? как раз это просто доказывается. сила в правде. нужно иметь лишь каплю упорства и при таком раскладе «предыдущие» будут хлебать баланду. хеппиенд. :)
серьёзно, во время недавнего кризиса ходили подобные байки. но как показала практика, та же куча свидетелей, предупрежденных об ответственности за дачу ложных показаний, с не меньшим усердием начинает свидетельствовать против работодателя. это ж не уголовники какие-то и нормально идут на сотрудничество. ведь даже самые упоротые осознают, что точно в таком же положении находится каждый из них.
у моих знакомых прямо обратная ситуация. компания российского масштаба, занимается бурением. сезонные работы, вахтовый метод. и работяг отбирают как космонавтов. не в последнюю очередь потому, что уволить неподходящего сотрудника по нашим законам крайне сложно. даже за пьянку. волокита, и месяцами длящиеся суды, отнимают кучу ресурсов. работяги, в общем-то, так же юридически неграмотны, как и офисные одуванчики. но упорны, и не столь наивны. вероятно потому, что деваться им больше не куда. в прочем, это уже полный офф.
(2, 1, 1) = {{1}, {1, 1}, {2, 1, 1}} = {{1}, {1, 1}, {2, 1}} = {{1}, {2, 1}}
(1, 2, 1) == (2, 1, 1)
в чем подвох?)
зы: знаете, мне определенно нравится ход ваших рассуждений. «для простоты рассмотрим баланс в кассе нашей организации. вот приход, вот расход. не трудно заметить, что ни какой вашей зарплаты здесь нет — присутствует исключительно синтаксический сахар.» :)
по идее, термин «отношение» должен быть знаком со школы — например, бинарное отношение равенства (=) чисел в математике. бинарное, потому что ставит в соответствие пару — чисел (x, x). а ещё каждый программист постоянно имеет дело с булевой алегброй и логическим отрицанием
not x— одинарным (унарным) отношением.кстати о логике. кроме всего прочего, отношение можно определять через функцию, принимающую некоторое количество параметров и возвращающую логическое True, либо False (т.е. предикат). скажем, то же равенство можно выразить предикатом двойкой аргументов вида eq (x, y), а отрицание — not (x) — с одним. можно вообразить функцию, принимающую 3-ку параметров foo(x,y,z) и т.д. «n-ка принадлежит отношению тогда и только тогда, когда предикат на ней возвращает значение True (или «истинно»)».
допустим, нас интересуют утверждения о том, что некоторый водитель типа Driver имеет отношение к некоторой компании типа Company. функция-предикат будет иметь вид (тип):
короче, речь идёт о 2-ках вида (company, driver). переходя на множества, на псевдо-sql-подобном языке, отношение между компаниями и водителями можно объявить как-то так:
(найди отличия) а его значение — определить, например, перечислив все известные истинные факты, в отношении отношений водителей и компаний:
действительно, это чем-то похоже на таблицу, и отношения часто таком виде изображают. но есть ключевые отличия. например, очевидно, что порядок записи утверждений (кортежей, строк) в отношении, имеет ни какого значения. так же бессмысленно записывать одно и то же утверждение дважды. в таблицах это не так. и да — популярные реляционные базы работают-таки с таблицами.
в общем, реляционная алгебра — это такая навороченная логика. а ценность реляционных баз состоит в том, что они с лёгкостью оперируют миллионами утверждений, касательно различных фактов, за считанные мгновения, предоставляя мощные средства для создания логической модели предметной области вашего приложения. можно использовать и для других целей, например, для хранения данных =) — но скорее будет хреново (см. NOSQL).