КДПВ

Вечерело

Мы с товарищем, сделали простенький тест (github) на проверку доступности data-uri в браузерах. Выглядит он следующим образом:



В textarea javascript'ом вставляется navigator.userAgent. В этот момент я не знаю, что меня стукнуло в голову, но вместо DOMContentLoaded, я написал . По-быстрому проверив корректную работу в десктопных браузерах и на нескольких мобильных устройствах, подключённых к интернету через wi-fi, мы успокоились и разошлись по домам.

Солнце продиралось сквозь занавески

Утром, в полупустом вагоне метро, я как всегда открыл браузер на своем телефоне, на котором со вчерашнего вечера была открыта тестовая страничка. Сказать, что я удивился, когда я не увидел вывода userAgent внутри textarea — ничего не сказать.

Добравшись до компьютера, решил потратить немного времени на поиск проблемы. Запустив страничку на десктопе и в эмуляторе, я ничего не заметил. Открыл на телефоне. Чудеса! Всё работает.

Увидев включённый значок wi-fi, я начал догадываться о причинах проблемы. Я отключил wi-fi, подключил телефон к компьютеру и начал дебаг с помощью веб-инспектора десктопного сафари.

Наша команда занимается разработкой интерфейсов для четырех крупных проектов: Яндекс.Картинки, Яндекс.Видео и их версий для смартфонов. Разработка верстки поисковых сервисов в Яндексе обладает своей спецификой. Задачи стекаются с разных сторон: от менеджеров, разработчиков бэкэнда, поиска, проявляются баги и т.д. Внедряются новые фичи, требующие отображения в верстке. Все это стекается в наш таск-трекер (JIRA).

При этом задач всегда больше, чем ресурсов. Всем заказчикам нужно сделать задачи как можно раньше, все поднимают приоритеты своих задач. У разработчиков уходило слишком много времени на то, чтобы разобраться, какие из этих неотложных задач самые неотложные. Это очень тормозило развитие, и нужно было что-то предпринимать. Сделать так, чтобы каждый разработчик знал, какими именно задачами ему заниматься сегодня, а какие можно отложить на завтра, следующую неделю, месяц.



В конечном итоге большинство наших проблем удалось решить при помощи Agile Board и Scrum, но пришли мы к этому далеко не сразу, а поэтапно.

Присказка или зачем нужен еще один плагин?

Давным-давно в тридесятом царстве в тридевятом государстве когда web был совсем не 2.0 никому и в голову не приходила мысль о стилизации форм. Сейчас же перед нами очень много решений на чистом CSS, которые кардинально меняют внешний вид элементов. К сожалению, для некоторых элементов это не работает. Особую сложность в этом плане представляет собой input[type=file].

С этим элементом, средствами CSS, мы можем разве что изменить размер шрифта. Все мы любим власть. Ты ведь хочешь полностью контролировать этот неподатливый file? Тут нам на помощь приходит волшебная связка современного интернета — JavaScript + CSS.

В нашем проекте используется jQuery, поэтому первым делом я принялся искать решение с помощью готового плагина, но быстро разочаровался. Найденные плагины либо не соответствовали требованиям нашего заказчика, либо предоставляли дополнительный функционал, который нам совершенно не нужен. Что из этого следует? Правильно – надо написать свой велосипед плагин.