Секреты быстрой верстки шаблонов сайтов
Проблема уникальных шаблонов стоит в текущее время самым полным ростом. Давайте рассмотрим 2 варианта быстрой верстки и слизывания дизайна для промышленных масштабов, чтобы как заработать вебмани на своих сайтах в самый короткий срок.
Вариант первый базируется на плагине для FF ScrapBook. Прост как 2 капли воды:
1. Открываем страничку которую будем слизывать
2. Жмем заграбить веб-страницу
3. Получаем на выходе уже готовую html страничку и всю графику к ней.
4. Пошустряку перебиваем страницу, наполнив ее шаблонами под требуемый конкретный дизайн для выбраной cms
5. Возможно подтачиваем кое-где графику под себя.
Время изготовления шаблона в первый раз часа 3, потом можно даже с довольно сложной версткой управиться где-то за час.
Второй вариант базируется на нарезке psd макета или любого другого графического представления дизайна. Пользоваться мы для этого будем программой Photoshop.
Уже довольно давно в фотошопе есть замечательный инструмент SliceTool о котором впрочем мало кто знает. Данный инструмент находится в нижней части зоны с выделениями и позволяет резать изображение на регионы. В старых версиях придется загнать слайсованую картинку в imageready. Начиная кажется с CS3 нужды в этом нет.
После нарезки слайсов просто выбираем сохранить для веб. А там указываем, что нам нужно сохранить все слайсы и html представление. При таком подходе на выходе мы получаем тот же самый готовый макет что и в предыдущем способе, который просто остается наполнить управляющими конструкциями под требуемую cms.
Основная проблема этого подхода в нарезке фона. По нормальной схеме если используется резиновый фон или чет такое, нужно выключать часть изображения, резать фон отдельно, а потом слегка дотачивать конечный документ.
При должной прямоте рук нарезка слайсами занимает не более часа. (для среднего по сложности шаблона).
Где-то так…
Стандарты оформления кода
Пару суток назад пришел интересный заказ на доработку скрипта. В данный момент пребываю в глубоком желании дать по рукам человеку, который это писал до меня.
Я не сторонник тотального документирования, но глубоко убежден что использовать односимвольные имена переменных в ключевых участках кода это свинство.
Я не сторонник описывать все и вся, но ставить хотя бы блочные комментарии для систем сложнее одной функции просто необходимо.
Мне ложить на лицензии, но в больших проектах я считаю просто необходимым указывать свои координаты и как со мной связаться, если уж впадлу описать общую логику приложения.
Использование n-мерных представлений для двухмерных данных это моветон. Я убежден в этом.
31 запрос к БД для формирования одной страницы двухмерного отчета это вещь за которую нужно расстреливать.
Наличие в БД избыточных полей и присутствие в таблицах-хранилищах дублирующих текстовых ключей это извращение, это заслуживает строжайшего порицания.
На сегодняшний день, на мой простите профессиональный взгляд на первое место в разработке выходит понятность и лаконичность кода, внимание к структуре БД (неужели трудно нагуглить что такое НФ) и простота дальнейшей поддержки и модернизации.
В 2010 году всем нужно просто обязательно выучить что такое процедуры, а для особо продвинутых стоит озаботиться даже объектами. После этого сверхусилия из многих модулей объемом 41к можно будет получить 20к, а иногда даже 7к что положительно скажется на вашей карме.
That`s all.
