Веб-разработка *

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

Так уж случилось, что один из наших клиентов заказал нам добавить в его интернет магазин несколько десятков тысяч товаров. Магазин у него работал на небезызвестном PHPShop(версия 2.1.8). До этого момента, я с этим «чудом» не встречался. После добавления первых 5000 товаров магазин слег и мог показывать только белую страницу.  Тех поддержка отвечала что это все из-за хостера(MasterHost). Я им поверил и решил опробовать все на локальном веб-сервере. Магазин показывал ту же картину. Причем в списке задач отображалось, что Apache «съедает» 200 Мб оперативной памяти. Пришлось лезть во внутренности…

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



Суровая действительность указывает на то, что весь процесс разработки должен происходить при участии дизайнеров. Для достижения оптимальной эффективности дизайнер должен уметь не только нарисовать картинку, но и встроить ее! В этой статье я хотел бы поделиться несколькими соображениями о том, почему дизайнеры должны уметь верстать сайты.

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

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

1. Ъ-метод – не использовать нестандартные шрифты, достаточно в CSS сказать body {font-family: sans-serif;} и не морочить себе голову.
2. Быдло-метод – нарезать из ЖПЕГов, картинок с заголовками, ужать посильнее, что б появилась размытость и вставлять вместо текста картинки. Достаточно популярный на наших просторах метод.
3. W3C-метод – используем @font-family и наслаждаемся красивыми шрифтами без всяких заморочек. Пока этот метод не рассматривают, как рабочий, по причине слабой поддержи со стороны браузера.
4. sIFR – клевая вещь, наиболее употребляемая на сегодняшний день, но как недостаток – требует наличия Flash-плагина. Хотя это трудно назвать недостатком, но если есть инструмент, позволяющий обойтись без плагинов, то это не может не радовать.
5. Cufón – самое то. Относительно новый метод, который показывает превосходные результаты. Он и есть герой этой статьи.

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

Рекомендация первая: забудьте про блочную верстку. Весь лэйаут должен быть на таблицах. При этом, без крайней необходимости — их тоже лучше не использовать. Также следует выкинуть из головы представления о семантике, сокращенных css-правилах, валидации, плавающих блоках — и прочее. Самый распространенный в РФ почтовый сервис на данный момент (mail.ru) вообще не понимает стили (css). Любые тэги/атрибуты style заменяются на xstyle и не работают. Вообще все.

Так что, фактически, при вёрстке html для почтовой рассылки надо мысленно переместиться в 90-ые годы прошлого века и смело использовать все распространенные приёмы того времени.

Для тех, кто с ними не знаком (как я был) — напомню:

Помните мою выпадающую панель для входа/регистрации, реализованную с помощью Mootools 1.2? Я подумал, что её можно было бы улучшить как с точки зрения дизайна, так и с точки зрения функциональности, и я это сделал! Но с этого времени уже на jQuery.

Я пишу этот топик, как ответ на недавнюю статью «10 приемов, разрушающих хрупкую красоту кода», в которой разгорелось множество споров.

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

Автор во многом прав, но он слишком категоричен в убеждениях. Профессия программиста заключается в том, чтобы думать и описывать решение задачи оптимальным способом. Как и в любом искусстве, если программист будет решать все задачи «подставляя лишь шаблоны», то все его решения — будут полнейшей ерундой. Программист — человек умеющий думать, а языки программирования предоставляют охрененно гибкий интерфейс для реализаций алгоритмов решений. По этому не стоит отказываться от особенностей языка — потому что в шаблоне написано не пользоваться — уж разработчики языков за вас уже продумали всё 100 раз, чтобы оставить эти методы и уверен, что в документации вы можете найти наиболее подходящие методы использования.

То, что Автор рассказал, хорошие советы. Но он показал лишь одну сторону медали. Я сейчас покажу другую.

_{Статья приводится в сокращении из-за ограничения на объем материала.}

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

Последние несколько лет я собирал приемы программирования, разрушающие в программном коде его утонченную красоту:

1. Объявление всех переменных в начале программы;
2. Возврат результата функции через ее параметр;
3. Отсутствие локальных функций;
4. Отсутствие else if;
5. Использование параллельных массивов;
6. Хранение размера массива в отдельной переменной;
7. Доступ к свойствам объекта через obj.getProperty() и obj.setProperty(value);
8. Использование рекурсии для вычисления факториалов и Чисел Фибоначчи;
9. Отсутствие именованных параметров функции;
10. Невозможность объявления объектов «на лету».

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

Объявление всех переменных в начале программы

В двух словах:

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

«Неписанный кодекс дороги»

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

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

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

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

Нет мочи прятать такую красоту!

Вычитал на блоге товарища Bolk совершенно восхитительную штуку — описание Common Internet Scheme Syntax.

Вкратце, если Вам нужно, чтобы страница была видна как по HTTPS, так и по HTTP, но при этом Вам приходится использовать на этой странице ссылки с абсолютными путями, не пишите в ссылках на этой странице http или https — пишите "//"!

Браузер сам подставит текущую схему, будь то HTTP или HTTPS.

За более детальным описанием, я считаю, стоит прочитать саму запись в его блоге.

P.S. если захотите плюсовать, то плюсуйте Bolk!

Testcase

UPD: Нигма и Гугл говорят, что такие ссылки будут проиндексированы.
UPD2: Как справедливо заметил Bolk, в RFC 3986 такая нотация тоже описана в секции Relative Reference (http://tools.ietf.org/html/rfc3986#section-4.2)

Категорически приветствую тебя %username%.
Не знаю как у Вас, а у меня ночью наступает «творческий порыв», о чем я обычно утром очень сильно жалею. Но не будем сейчас о плохом, т.к. пока не утро, то я еще успею поделиться одним из

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

MailLink

Почти год назад была необходимость защитить большое количество адресов электронной почты от роботов по сборке мейлов, для последующей рассылки по ним спама. По этому поводу быстро набросал страничку, которая позволяет кодировать адреса посредством JavaScript. За основу был взят алгоритм из плагина шаблонизатора Smarty (для особо пытливых могу выложить реализацию на РНР отдельно).

Конечно у него есть и свои минусы:

1. адрес будет показываться только при всключенном JavaScript
2. если у робота есть поддержка JS, то он может распознать скрываемый e-mail

Насчет первого, то скорее всего выключенный JS — это паранойя во времена веб два нуль и выше. Насчет второго, то как показала практика — писателям таких пауков очень лень пытаться распознать закодированные адреса, когда на просторах сети полным полно не закодированных. Так что данных алгоритм работает в большинстве, чем 99.5% случаев.

Индустрия программного обеспечения — это, наверное, крупнейший в мире питомник новых систем управления. Agile, Экстремальное Программирование, Разработка Через Тестирование (Test Driven Development, TDD) — акронимы и фреймворки продолжают плодиться. Почему?

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

Объектно-ориентированные базы данных – базы данных, в которых информация представлена в виде объектов, как в объектно-ориентированных языках программирования.

Применять или не применять объектно-ориентированные системы управления базами данных (ООСУБД) в реальных проектах сегодня? В каких случаях их применять, а в каких нет?

Вот преимущества использования ООСУБД:

• Отсутствует проблема несоответствия модели данных в приложении и БД (impedance mismatch). Все данные сохраняются в БД в том же виде, что и в модели приложения.
• Не требуется отдельно поддерживать модель данных на стороне СУБД.
• Все объекты на уровне источника данных строго типизированы. Больше никаких строковых имен колонок! Рефакторинг объектно-ориентированной базы данных и работающего с ней кода теперь автоматизированный, а не однообразный и скучный процесс.

Интересно? Тогда стоит попробовать!

В статье описано все, что требуется для начала работы с ООСУБД db4o.

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

Артемий Лебедев, известный дизайнер, когда-то писал про рыбные тексты. С тех пор в среде дизайнеров укоренилось мнение, что все рыбные тексты всегда должны выглядеть естественно и привлекательно.