Как повысить производительность

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

Но есть ещё кое-что. Давайте разберём по шагам:

Шаг 1

Шаг 2

 

Угу, вот так всё просто.

Как я с RESS воевал

Один из проектов, над которыми я работал вместе с ребятами из nikoland.ru, подразумевал RESS — адаптивный дизайн с серверными компонентами (responsive design with server side components).

Суть такова — у макета есть три разных состояния: для широкоэкранных мониторов, для планшетов и небольших мониторов, для мобильных устройств; но дабы не перегружать, например, мобильный телефон, загружаем и используем в дальнейшем только один определённый стиль и не перестраиваем страницу при изменении размеров окна.

С этой технологией я встретился впервые. Потому сделал изначально три файла с разметкой и по три файла со стилями и скриптами. Когда отладка скриптов и правки по дизайну были готовы, настало время размять мозги и подумать, как лучше сделать «недоадаптив».

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

Второй мыслью было использовать php и ajax. Опять-таки, как я ни изощрялся, избавиться от следов махинаций в адресной строке не удалось.

Третья мысль (html5 history api) тоже не подошла — с ней пришлось бы либо отказаться от поддержки старых браузеров, либо грузить ещё скрипты. Не хорошо.

Четвёртая мысль — айфрейм. Показалось довольно логичным загружать в айфрейм нужную страницу, это даже работало… до тех пор, пока я не попробовал нажать на ссылку в меню :-)

Отдельной проблемой стали те самые три разных страницы — «надо сделать один шаблон, это удобнее для наполнения контентом», решил я. Значит, загрузкой изображений тоже нужно управлять вручную.

Так может и загрузкой скриптов и стилей тоже следует управлять самому? В голову пришла идея: я не могу убрать что-то из css файла, но могу убрать узлы из DOM, значит пишем media в качестве атрибута для ссылок на файлы, скриптом проверяем ширину и убираем из html ненужные ссылки, параллельно загружаем нужные скрипты, и, если требуется, картинки.

Сработало. Страница перед загрузкой проверяет ширину, загружает подходящие файлы, и не перестраивается при изменении размера экрана. Задача решена.

 

P.S. Есть один недостаток, метод не работает с отключённым джаваскриптом.
P.P.S. С отключённым джаваскриптом там много чего не работает :-)

Не мелочи — детали

В разработке интерфейсов нет мелочей — есть детали.

Мелочь — это нечто несущественное, не влияющее на общую картину и не ломающее работы системы, если это нечто отсутствует или сломано.

Например, кусок арматуры на складе строй.материалов — мелочь, а та же самая арматура в железобетонной плите — деталь, потому что без неё материал не будет прочным.

В том же, что касается интерфейсов, каждая «мелочь» — это деталь.

Слишком быстрая анимация — мелочь? Нет. Очень мелкий шрифт — мелочь? Тоже нет. И большие зоны ховера, и чистота кода, и приятные тексты — всё это детали, потому что в сумме они дают либо рабочую и стабильную систему, либо неподвижного динозавра, которым трудно управлять, и который очень труден для понимания.

О сроках

Никто не любит сжатые сроки.

Я стараюсь предлагать такие сроки, чтобы к концу обговорённого промежутка времени была готова моя работа; не начальная наработка, которая требует кучи доделок и дебага, а конечный желаемый результат.

Ведь каждый понимает, что два человека не могут понять друг друга с абсолютной точностью; мы же не образами общаемся, а словами, слова — это код, в коде обычно есть ошибки и неточности. Именно поэтому я стараюсь называть такие сроки, чтобы за это время успеть сделать первую версию, отдать её на рассмотрение, получить замечания с правками, и к дедлайну уже сдать готовую работу.

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

Кстати, пока я пишу каркас, в голове уже сам по себе продумывается план будущих скриптов. Обычно, к концу второй-третьей итерации динамика уже готова, остаётся её лишь написать.

Может показаться, что такой метод занимает больше времени или просто неоправдан. Я тоже так думал, но оказалось наоборот.

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

Набор шаблонов

Вёрстка — довольно рутинная работа, и временами вся она (работа) сводится лишь к тому, чтобы слепить несколько стандартных кусков в одну страницу. И поэтому, разумеется, стоит задуматься о повторном использовании каких-то кусков в следующих своих проектах.

Сперва я сделал библиотеку макетов: одноколоночный, двухколоночный (сайдбар справа, сайдбар слева), трёхколоночный, промо-страница (там, где, возможно, даже не будет хедера или футера) и т.п.

Потом, взглянув на свои работы, я заметил, что и некоторые динамические элементы встречаются довольно часто. Тогда я решил и их выносить в отдельные модули: слайдер картинок, выпадающее меню, лайтбоксы, попапы и другое — код каждого из этих элементов я повыносил в отдельные файлы, в дополнение к которым написал css-пустышки, в которых заранее прописаны названия свойств, которые понадобятся при интеграции модуля, также в отдельные файлы вынес js-код модулей.

Конечно, у меня и раньше были заготовки для проектов, но их было неудобно использовать по разным причинам, в основном, потому, что они были неуниверсальны, так как делал я их невнимательно.

А эти заготовки, могу смело сказать, хороши: сегодня я верстал стандартный шаблонный макет, половину писать не пришлось — это было в шаблоне, с динамикой тоже не было проблем — я всего лишь вставил нужный код в нужное место и указал ссылку на файл скрипта. В итоге, я сэкономил около 2-3 часов чистого времени. А именно время — самый главный ресурс в нашей работе.

Личные встречи не имеют смысла

Типичная ситуация: захожу на фрилансим.ру, смотрю проекты. Вижу отличный заказ, интересный, много занимательных фич. Открываю ссылку, читаю условия, то, что нужно знать. Горю желанием, уже готов нажать на кнопку «Ответить на проект», как вдруг в самом конце вижу строку наподобие:

«Личная встреча обязательна! Претенденты не из %город% не рассматриваются»

Почему?

Личные встречи, как мне кажется, имеют смысл только если работник устраивается по ТК на постоянную основу или для составления договора. Но большинство заказов на биржах не подразумевают договоры — стало быть, и личные встречи бессмысленны.

Если заказчик хочет узнать, каков уровень исполнителя, адекватен ли фрилансер, почему бы не связаться по скайпу?

Боязнь быть обманутым? Но здесь личная встреча тоже не гарант безопасности, если человек хочет кого-то обмануть — он обманет.

Уверенность в контроле над человеком? Почему не скайп опять-таки?

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

Новый год — новый дизайн

Теперь у моего сайта новый дизайн, за который я благодарю своего друга, дизайнера — Вадима Юмадилова.

Было решено убрать аудио-плейер с главной страницы, потому что (как и говорил Лебедев) в музыке действительно нет информативности. А убрав музыку, стало понято, что и одностраничность здесь тоже не нужна.

Теперь на сайте всего два раздела: порфтолио и заметки. В первом представлены выполненные мной проекты (вёрстка, программирование, интеграция шаблонов), во втором — те заметки, что были на старом сайте, и то, что я когда-то написал, но не стал выкладывать на всеобщее обозрение, а «повесил» лишь на свою стену вконтакте. Также заметки теперь разбиты по категориям, и на каждой странице есть удобная «листалка», чтобы быстро переходить на следующую и предыдущую заметку.

Страница портфолио тоже сильно изменилась. Во-первых, в списке проектов я решил убрать лишнее, оставив лишь превью и название; всё описание работы теперь — на странице проекта. А во-вторых, на страницах самых интересных работ есть ссылка на процесс создания, где вы сможете прочесть, как была реализована та или иная «фича».

Одно только плохо: почти в каждом проекте мне пришлось вынести ссылки на внешние скрипты в тело документа — это не быдлокод; система управления содержимым, которую я использую, работает со старой версией jquery, и появляются конфликты (потому что, система настолько наглая, что ставит свои скрипты сразу после моих же), вот чтобы избежать проблем, я и вынес скрипты внутрь документа.

Новая беда на фри-лансе

Сегодня — знаменательная дата. Фри-ланса, каким мы его знали, теперь точно больше нет.

Ребята из разработки запретили обмениваться любыми контактными данными на сайте. Теперь, чтобы найти аську или скайп исполнителя, придется... я даже не знаю, что, потому что обмен через фри-лансовскую почту контактами — это тоже обмен через сайт. (А как узнать, например, почтовый ящик? Через СБР? Было бы неплохо, если бы СБР была нормально организована. Кому охота переплачивать, да ещё и столько, да ещё и получить при этом кучу бумажной волокиты?..)

В общем, всё катится в тартарары. Не представляю, как бы я начинал работать, если бы начинал это делать сейчас.

Удачи всем фри-лансерам, теперь она действительно понадобится.