в упомянутой в статье pdf пишут, что в лабораторных условиях на тестовой lossless wav 44,1kHz оно работало так себе (время определилось правильно для 44 из 70 записей), а при смещении частот точность становится совсем ни какой.
Метод уже доказал свою эффективность на практике в деле с дилерами оружия, адвокаты которых говорили, что полиция сфабриковала доказательства
Все подобные глюки малореально покрыть тестами, т.к. имеет место внешняя зависимость.
не сочтите за буквоедство, но глюки не покрываются тестами — они ими выявляются, как побочный эффект.
тесты бывают разные и не только автоматические. их природа не влияет на покрытие — вопрос лишь времени и стоимости).
в случае с gui, внешние зависимости это пользователь, с одной стороны, и модель предметной области — с другой. «замокать» аспекты поведения которых может быть проблемой. :)
абсолютная величина % покрытия кода тестами, штука бессмысленная — факт. что 100% что 2%.
показатель code coverage полезен, когда есть возможность прослеживать его в ретроспективе (как меняется от билда к билду) и соотносить с количеством багов, отлавливаемых в проекте с использованием других способов тестирования.
мне нравится аналогия «спринт» vs «марафон». т.е. скорость важна, но разная.
в коротких проектах тесты это выпендреж и потеря времени. но тут вообще что-либо кодить вредно — нужно искать готовые решения (покрытые тестами :)).
в длинных проектах важна не предельно возможная скорость, а сохранение темпа разработки на всем протяжении его развития (т.е. предсказуемость). поэтому тесты себя оправдывают.
> Только не совсем понятно, зачем для разметки использовать json? Ведь html для этих целей не просто так зародился.
в данном случае, html является не исходником, а результатом компиляции. поэтому, использовать html было бы не логично (на эти грабли постоянно наступают — см. ru.wikipedia.org/wiki/Самореференция) — для описания исходной структуры нужно использовать мета-язык. мне кажется, что json это какой-то панк, но принципиальной разницы в альтернативах нет.
есть два слоя с непрозрачными бекграундами, один под другим. на верхнем слое какой-то текст. как сделать этот текст прозрачным — т.е. чтобы нижний слой просвечивал через буквы?
известно, что создание прототипа является стадией разработки продукта. поэтому на прототип не может быть потрачено больше времени, чем на продукт, по определению. :)
в распределении долей времени по отдельным стадиям все может быть как угодно. прототип создается, когда ничего не понятно, время тратится на исследования. что-то собирается на коленке и через час наступает озарение, а что-то годами будет пребывать в состоянии альфы.
всем понятно, что дисплеи с высоким разрешением придумали не вчера и не в эпл. у многих производителей уже давно появились модели ноутбуков с высоким ppi. но, похоже, что особого преимущества тут нет. проблема именно в наличии софта (вплоть до уровня операционных систем), способного адекватно работать в таких условиях — которого, фактически, лишь чуть. в целом, потребители удовлетворяются большими числами и ожиданиями.
так даже как-то комфортнее — остается место на креатив, фантазию, дискуссии
Комфортно в начале проекта — когда всем хочется удивить мир, впереди еще уйма времени, все радостно делают оценки и ставят подписи под ТЗ.
Ближе к дедлайну, когда креатив, фантазии и дискуссии бъют ключом, но времени уже нет и теги к документам мир по-прежнему не удивляют, приходит откровение, что они подписались под Теорией Заговора.
какие-то еще операции, кроме git reset влияют на ORIG_HEAD и что произойдет с веткой коммитов на который указывал ORIG_HEAD после того, как он изменится?
описание PrEn разбито на последовательные этапы и поэтому производит впечатление еще и методики разработки. но выполнение таких шагов ещё не дает гарантий для получения ожидаемого результата.
например, на очередном технологическом витке может возникнуть необходимость внести изменения, которые сломают что-то на предыдущих этапах (например — добавить в код html дополнительные теги, которые требуются «навороченной» версии интерфейса),
так же это не всегда оправдано, т.к. нельзя исключать вероятность того, что реализации функциональности на базовом уровне, потребует выполнить какой-то самостоятельный объем работ для обхода технологических ограничений (например, функциональность «добавить еще, и еще одну картинку» при наличии js, тривиально, реализуется в рамках одной страницы, и потребует создавать дополнительные ручки на сервере, с использованием чего-то в роде сессий, REST и т.п. чтобы реализовать то же самое на уровне «чистого» html).
мне кажется, что корни GrDe можно поискать еще и в процессах разработки.
а. как правило верстальщик получает от дизайнера макет, на котором страница представлена уже со всеми наворотами, и на выходе требуется результат «на 100% соответствующий макету в современных браузерах».
б. без вдумчивого анализа из макета бывает сложно понять, какие фичи жизненно важны, а какими можно жертвовать.
это только две причины, из-за которых первая версия страницы создается с полным набором фич, и лишь потом её начинают подгонять под неполноценные браузеры и различные альтернативные условия.
Мы решили не ломать стандартную сортировку писем в почте, когда первое письмо — снизу, последующие — сверху, и поддержать её в тредах.. Кроме того, до нас это отлично сделал Apple Mail, так что здесь было на кого равняться.
можно-ли настроить интерфейс так, чтобы письма внутри треда сортировались в прямом хронологическом порядке, а не задом-наперед? (сами треды пусть сортируются как сейчас — в обратном порядке, по дате последнего сообщения).
мне кажется, что в отличие от того же твиттера, где отдельные сообщения между собой ни как не связаны, письма в треде связаны друг с другом самым непосредственным образом, и поэтому их удобнее читать подряд, линейно — т.е. строго сверху вниз. не знаю о чем думали разработчики эпл, но заставлять прыгать снизу вверх, прочитав предыдущее письмо, чтобы найти следующее за ним, это не логично и не гуманно. '-)
мне кажется, что применительно к IT'шникам пирамидку надо переворачивать — для них «познавательные потребности» являются базовыми, а физиологические (которые «голод, жажда, половое влечение и другие») — дело десятое. :)
волнует не сколько конкрентая ситуация, а вообще данный способ реализации dependency injection, внутри django. ведь разработчики примут это за best practices и начнут подражать направо и налево. в пределе — все ссылки внутри ForeignKey заменяются константами из settings — что дикий ужаснах.
сцылку!)
не сочтите за буквоедство, но глюки не покрываются тестами — они ими выявляются, как побочный эффект.
тесты бывают разные и не только автоматические. их природа не влияет на покрытие — вопрос лишь времени и стоимости).
показатель code coverage полезен, когда есть возможность прослеживать его в ретроспективе (как меняется от билда к билду) и соотносить с количеством багов, отлавливаемых в проекте с использованием других способов тестирования.
мне нравится аналогия «спринт» vs «марафон». т.е. скорость важна, но разная.
в коротких проектах тесты это выпендреж и потеря времени. но тут вообще что-либо кодить вредно — нужно искать готовые решения (покрытые тестами :)).
в длинных проектах важна не предельно возможная скорость, а сохранение темпа разработки на всем протяжении его развития (т.е. предсказуемость). поэтому тесты себя оправдывают.
в данном случае, html является не исходником, а результатом компиляции. поэтому, использовать html было бы не логично (на эти грабли постоянно наступают — см. ru.wikipedia.org/wiki/Самореференция) — для описания исходной структуры нужно использовать мета-язык. мне кажется, что json это какой-то панк, но принципиальной разницы в альтернативах нет.
в распределении долей времени по отдельным стадиям все может быть как угодно. прототип создается, когда ничего не понятно, время тратится на исследования. что-то собирается на коленке и через час наступает озарение, а что-то годами будет пребывать в состоянии альфы.
Комфортно в начале проекта — когда всем хочется удивить мир, впереди еще уйма времени, все радостно делают оценки и ставят подписи под ТЗ.
Ближе к дедлайну, когда креатив, фантазии и дискуссии бъют ключом, но времени уже нет и теги к документам мир по-прежнему не удивляют, приходит откровение, что они подписались под Теорией Заговора.
например, на очередном технологическом витке может возникнуть необходимость внести изменения, которые сломают что-то на предыдущих этапах (например — добавить в код html дополнительные теги, которые требуются «навороченной» версии интерфейса),
так же это не всегда оправдано, т.к. нельзя исключать вероятность того, что реализации функциональности на базовом уровне, потребует выполнить какой-то самостоятельный объем работ для обхода технологических ограничений (например, функциональность «добавить еще, и еще одну картинку» при наличии js, тривиально, реализуется в рамках одной страницы, и потребует создавать дополнительные ручки на сервере, с использованием чего-то в роде сессий, REST и т.п. чтобы реализовать то же самое на уровне «чистого» html).
а. как правило верстальщик получает от дизайнера макет, на котором страница представлена уже со всеми наворотами, и на выходе требуется результат «на 100% соответствующий макету в современных браузерах».
б. без вдумчивого анализа из макета бывает сложно понять, какие фичи жизненно важны, а какими можно жертвовать.
это только две причины, из-за которых первая версия страницы создается с полным набором фич, и лишь потом её начинают подгонять под неполноценные браузеры и различные альтернативные условия.
можно-ли настроить интерфейс так, чтобы письма внутри треда сортировались в прямом хронологическом порядке, а не задом-наперед? (сами треды пусть сортируются как сейчас — в обратном порядке, по дате последнего сообщения).
мне кажется, что в отличие от того же твиттера, где отдельные сообщения между собой ни как не связаны, письма в треде связаны друг с другом самым непосредственным образом, и поэтому их удобнее читать подряд, линейно — т.е. строго сверху вниз. не знаю о чем думали разработчики эпл, но заставлять прыгать снизу вверх, прочитав предыдущее письмо, чтобы найти следующее за ним, это не логично и не гуманно. '-)