Введение

В этом топике я хочу представить вам, дорогие читатели, пересказ вебинара от человека, чьё имя не нуждается в представлении. Для того, чтобы изложить часовой вебинар в виде небольшого топика, мне пришлось значительно ужать комментарии автора, поэтому я сознательно не помечаю топик как «перевод». В этот раз Стив МакКоннелл решил поделиться с нами своим опытом в виде коротких тезисов, в которых он отражает самые страшные ошибки при оценке трудоёмкости разработки программного обеспечения. В 1998 году читатели журнала Software Development назвали Стива одним из самых влиятельных людей в индустрии разработки программного обеспечения на равне с Биллом Гейтсом и Линусом Торвальдсом. Стив — автор книги «Software Estimation. Demystifying The Black Art» — одной из самых популярных книг в области оценки трудоёмкости разработки ПО. Надо признаться, что вебинар был проведён относительно давно (июнь 2009 года), но информация, представленная там, совсем не устарела. Сам топик будет построен следующим образом. Заголовки будут достаточно точно переведены из презентации, которую показывал Стив, а в остальном я постараюсь отразить только основные мысли, чтобы не перегружать топик. Если кто-то посчитает, что ту или иную мысль я излагаю неправильно — милости прошу в комментарии, можно будет меня поправить.

Иногда у веб-разработчиков возникает задача, которая требует плавного движения объекта по экрану. Это может быть строка загрузки, какой-то спрайт (например, машинки на клавогонках) или что-то ещё. Проблема возникает, когда сдвиг даже на одну точку кажется слишком резким и портит общее ощущение от происходящего. Как этого избежать? Использовать приёмы антиалиасинга.

Мы сделали небольшой пример (а затем и ещё один с зацикленным фоном), в котором можно посмотреть, как выглядит плавный сдвиг с субпиксельной точностью и антиалиасингом, и как выглядит тот же сдвиг без этого эффекта.

Как это сделано?

Этот чеклист будет полезен всем, кто запускает сайты или следит за этим увлекательным процессом. Ничего не пропустите!

Алгоритм возможно не новый, и не является идеалом, но, на удивление, работает. Никаких графов и корелляции.

Для начала, стоит отметить, что сравнение очень приблизительно (по крайней мере, на данном этапе), временами две совершенно разные фотографии оказываются похожими процентов на 60%, так же не учитываются жесткие модификации (повороты, инверсия, обрезка) – для этого нужно доводить и доводить. Лично для меня самым главным оказались два параметра: скорость, независимость от разрешения изображения и возможность сравнивать «изображения» прямо в базе данных.

Зачастую стандартный вид кнопочек не может сочетаться с концепцией дизайна, которую придумал дизайнер, поэтому он рисует свои кнопочки.

Что обычно делает верстальщик при виде такой кнопки? Правильно, просто напросто, вырезает ее как есть, и вставляет ее в верстку как картинку.

Например:

<a href="some_page.html"><img src="button.gif" alt="Button"></a>
<input type="image" src="button.gif" alt="Button">

* This source code was highlighted with Source Code Highlighter.

Вроде бы все просто, но тогда верстальщику придется под каждую форму или ссылку вырезать новую картинку, тем самым плодя кучу картинок и тратя драгоценное время.

Вариант реализации