Введение

В русскоязычной части Интернета присутствует большое количество статей, посвященных веб-службам на основе SOAP и XML-RPC, но почему-то почти ничего нет про вполне заслуживающую внимания (но менее распространенную) архитектуру RESТ.

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

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

Сразу говорю, те, кто уже знает и использует такие программы как IEtester и multiple IE, под кат можно не ходить.

А тут мы поговорим о них.

О чем это?

Возможно ли узнать более детальную информацию о браузере посетителя кроме строки, содержащейся в $_SERVER[«HTTP_USER_AGENT»]: поддерживает ли яву, апплеты, таблицы стилей и фреймы? А может это вообще гуглобот зашел?

Прочитал статью «Фрагментарное кэширование в MVC веб-фреймворках». Статья описывает проблему кеширования фрагмета отображения, а именно проблему полного разделения контроллера и отображения — контроллер отрабатывает полностью до вызова отображения. Если в отображении мы кешируем фрагмент, это ничего не меняет — контроллер-то уже отработал! В статье описан способ этого избежать: сделать запрос данных «ленивым».

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

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

Примечание: ниже расположен перевод статьи «jQuery for JavaScript programmers», в которой автор высказывает свое мнение об этой библиотеке, ориентируясь, в первую очередь, на продвинутых программистов, и приводит несколько десятков примеров ее использования.

Когда jQuery увидела свет в январе 2006, я подумал: «очередная красивая игрушка». Выбор CSS-селекторов в качестве базиса было, конечно, изящной идеей (подробнее о ней в моей заметке getElementsBySelector), но использование цепочек преобразований выглядело немного замысловато, и сама библиотека, по-видимому, не покрывала всех возможных случаев. Я расценивал тогда jQuery только как временное и проходящее решение.

Только несколько месяцев спустя понял я, насколько же ошибался по отношению к ней. jQuery является просто произведением инженерного искусства. Она умело покрывает достаточно широкой диапазон повседневных функций и предоставляет при этом удобный API для расширений, с помощью которых можно добавить любую другую функциональность. Абстрактность в ней заложена на уровне ядра — речь идет о выборе DOM-элементов — и она извлекает из него максимум пользы. И что важнее всего, использование этой библиотеки подразумевает следование хорошему стилю в программировании и хорошо сочетается с другими частями JavaScript-кода.

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

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

Шаблоны я обычно строил с помощью инклюдов: в начале подключался header.tpl, в конце — footer.tpl, в середине ещё что-нибудь нужное. В целом разметка получалась довольно аккуратной, но не проходило ощущение, что не хватает чего-то важного. Окончательно понимание этого чего-то появилось, когда мне случилось написать простенькое приложение на Django. И это «что-то», как все поняли, оказалось наследованием шаблонов. Простая, как и всё гениальное, идея позволяла существенно упростить шаблоны и избавиться от дублирующих блоков.

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

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

В последнее время при разработке сайтов все меньше и меньше учитывается разрешение 800х600, что само по себе не удивительно, если взглянуть на статистику. Соответственно либо сайты оптимизированы под 1024х768 и выше, либо они «резиновые», что встречается в реже.

Ситуация закономерная и соответствует развитию рынка мониторов и стремлениям дизайнеров/разработчиков. Я уже размышлял над этим год назад. Так вот, год спустя, мои мысли приобрели немного другое направление.

Вступление

Те, кто когда-то только-только начинали изучать CSS, особенно имея небольшой опыт программирования десктопных приложений на Delphi или VB, наверняка хотели иметь возможность использовать конструкции вроде left:30%+10;
Потом все мы научились использовать margin, вложенные и плавающие блоки. Тем, кто всё-таки не прочь побаловаться, посвящается: JSCSS

При подгонке сайтов до единого вида во всех браузерах, верстальщик использует не один css хак.
Но зачем обычному пользователю с IE получать избыток кода для других браузеров firefox, opera, safari?!
Это проблема легко решается с помощью динамического css.

Часто пользователи удивляются, откуда спаммеры узнают их e-mail адреса и выливают на них тонны спама. Оставляя за рамками этой статьи такие способы пополнения спаммерских базы, как вирусы, «слив» адресов владельцами почтового сервера или прослушивание HTTP и ICQ траффика, рассмотрим самый распространенный случай.
Одним из основных источников новых e-mail адресов являются собственно веб-страницы, на которых беспечные пользователи (а порой и владельцы сайта) открыто публикуют свой e-mail, откуда спамботы (сборщики e-mail) без проблем его извлекают и используют в своих нехороших целях.

Далее будут рассмотрены основные приемы шифрования e-mail адресов от спамботов, а также приведены результаты замера эффективности каждого из приемов, путем практического использования каждого способа для свежезарегистрированных e-mail адресов и оценки количества спама.

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

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

Однажды мне понадобилось сделать прозрачные боковые поля для одного дизайна. Я решил использовать прозрачность CSS.

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

Недавно я наткнулся на замечательную технику, позволяющую устранить эту проблему, ею я и хочу с вами любезно поделиться.

В последнее время стало модно объединять все внешние JavaScript-файлы вашего сайта в один большой, загружаемый один раз и навсегда. Это, скажем прямо, хорошо — браузер не делает сто миллионов запросов на сервер для отображения одной страницы ¹, скорость загрузки повышается, пользователи счастливы, разработчики отдыхают.
Как всегда, в бочке мёда есть ложка дёгтя — в объединённый файл в этом случае попадает много того, что при первом запросе можно было бы и не загружать.² Здесь должна была быть ссылка на хабратопик с соответствующим обсуждением. Успешно потеряна. Чаще всего для борьбы с этим предлагают выкидывать ненужные части руками… Лично у меня перспектива каждый раз перелопачивать несколько десятков (а то и сотен ³) килобайт JavaScript кода вызывает острое нежелание работать — а у вас?
под катом: описание простейшего алгоритма разрешения зависимости между модулями

Как сказал Robots: « а если без шуток, …, дилетантам лучше читать и учиться, а создание топиков оставить профессионалам.»

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

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

В этой статье я объединил (скомпилировал) уже изложенные мысли (!) многих людей, но почему-то так и не донесенные до большинства. (www.flack.ru, www.pepelsbey.net и некоторые другие)

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

Здесь представлены

Представьте себе абстрактный разговор абстрактного заказчика с абстрактным верстальщиком.

— У тебя бага в менюшке, все наверх съехало, — говорит заказчик.
— Посмотрел во всех браузерах, нету! Ты в каком смотришь? — говорит верстальщик.
— В фаерфоксе.
— Нормально все там, — говорит верстальщик, просмотрев сайт во всех версиях фаерфокса.
— Осталось бага. Если это важно, то я с мака.

Как-то всегда обходил эту проблему стороной, а теперь надоело. Суть в том что при большом размере кнопки IE растягивает свой «батон» превращая его в какое-то страшнейшее убожество:



Особенно обратите внимание на прелестные артефакты прозрачности по углам.

Какие есть выходы из этой ситуации?

Практически на каждом сайте нужно реализовывать меню. Обычно в этом нет никакой проблемы — заворачиваем все в ненумерованный список — ul, прописываем все наобходимые стили и готово.
Но очень часто дизайнеры, пытаясь создать очередной мегаопупительный макет, делают какие-либо 3D кнопки, либо кнопки с закругленными краями и кучей градиентов, либо еще что либо ужасное :)

Речь в данном топике пойдет о том, как реализовать такое меню, с учетом того, что размеры каждого пункта меню не фиксированны, то есть могут «тянуться».