Мы нарисовали набор очень милых и совершенно бесплатных иконок Лупоглазики. Если иногда вам кажется, что за вами следят, то это совершенно нормально. Не волнуйтесь — у вас нет паранойи. За вами, действительно, следят. Команда отборных Лупоглазиков уже вылупили свои глаза и очень внимательно смотрят. Вот, например, гипножаба.

Наткнулся на очень интересный вариант решения очень популярной проблемы многих веб-мастеров — закругление блоков.
Для этого варианта закругления используются VML и CSS3.

Решение без картинок, работает во всех Internet Explorer’ах включая 5ый, в Firefox, в Safari, но к сожалению в старых версиях Opera не работает.

«Совершенный Ajax» — новый подход к построению web-приложений, при котором web-сервер не генерирует ни строчки HTML-кода и взаимодействует с внешним миром только посредством web-служб; а клиентский интерфейс реализуется только на основе клиентских HTML, CSS, JavaScript.

Статья состоит из двух частей. В первой части — более живой и провокационной я постараюсь заинтересовать проблемой, рассказать о технологии «Совершенный Ajax» и показать ее применение на примере нашего проекта «Система Интерактивного Тестирования Знаний “Синтез”» (который имеет ряд интересных особенностей, таких, как использование серверного JavaScript на платформе Mozilla Rhino, прототипно-ориентированная ORM и поддержка SPARQL — языка запросов к Semantic Web).

Вторая часть – более занудная будет содержать много технических деталей и выйдет в следующий раз.

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


Попробуйте угадать: к какой архитектуре относятся web-приложения?

К клиент-серверной говорите? Я ожидал, что Вы так ответите :-)

Что ж, давайте разберемся. В клиент-серверной архитектуре выделяют:

• Сервер — отвечает за хранение данных и реализацию бизнес-логики приложения.
  
  
• Клиент — отвечает за взаимодействие с пользователем ^[1].
  
  

Реализация бизнес-логики на сервере и взаимодействие с пользователем на клиенте четко разделены.

Преимущества клиент-серверной архитектуры очевидны; мы их все знаем:

1. Бизнес-логика не смешивается с пользовательским интерфейсом.
2. Можно реализовать несколько клиентов с разными пользовательскими интерфейсами: интерфейс командной строки, оконный Windows-интерфейс, Flash, web-интерфейс, мобильный интерфейс и т.д.
3. Клиентский компьютер не требователен к ресурсам;
4. И т.д.

Но, относятся ли web-приложения к клиент-серверной архитектуре?

Действительно, в web-приложениях есть сервер, отвечающий за бизнес логику приложения.

Но! За реализацию интерфейса отвечает не клиент, а тоже сервер. На сервере происходит обработка клиентской формы. Сервер генерирует HTML-код пользовательского интерфейса.

Клиент, т.е. браузер лишь визуализирует уже готовый HTML-код интерфейса. Это, фактически, то же самое, что прицепить к серверу монитор и объявить этот монитор клиентом…

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

Я занимаюсь разработкой форм ввода персональных данных. Для удобства работы пользователей и увеличения скорости ввода данных (а та же сокражения расходов на перепроверку введенных данных) был разработан метод обработки блока ФИО.



Блок состоит из следующих полей (в зависимости от специфики полей может быть меньше): фамилия, имя, отчество, дата рождения, пол, семейное положение. Переход по полям последовательный.

Логика функционирования блока «Личные данные»
После ввода фамилии, определяется пол по окончанию фамилии:
Мужской: 'ОВ', 'ЕВ' ,'ИН' ,'ЫН', 'ОЙ', 'ЦКИЙ', 'СКИЙ', 'ЦКОЙ', 'СКОЙ', 'ЦКИЙ'.
Женский: 'ОВА', 'ЕВА', 'ИНА', 'АЯ', 'ЯЯ', 'ЕКАЯ', 'ЦКАЯ'.

ФИО должны вводится в именительном падеже!
1. Если удалось определить пол по фамилии то в следующее поле «Имя» подгружаются исключительно мужские имена-справочник мужских имен(если пол мужской определился), женские имена(аналогично)-женская фамилия. В случае если фамилия оказалсь бесполой (Кравчук), то подгружаются оба справочника мужской и женский.
2. В поле «Имя», в зависимости от подгруженного справочника по первым буквам происходит подстановка полного имени, при нажатии на «Enter» происходит переход к следующему полю «отчество». Имеются также справочники отчеств, значения в поле подставляются аналогично предыдушему пункту. В случае когда введено не справочное имя(либо имя которое не содержится в справочнике), т.е. не возможно определить пол, происходит проверка опять же фамилии, и по ней происходит подгрузка значений в поле «отчество», и в случае когда не по имени не по фамилии невозможно определить пол, происходит подгрузка обоих справочников. Если имя является не справочным, то оно подсвечивается красным цветом, и отмечается в базе метка о несправочном значени, свидетельствующая о том что запись нужно повторно проверить на корректность.
3. Отчество. После ввода проверяется также на справочное значение и помечается так же как имя.
4. Форма проставляет пол автоматически при вводе информации, если есть уверенность в этом. Т.е.:
4.1. Фамилия мужская или женская, при этом имя и отчество из справочника мужские или женские – форма проставляет пол. Вам требуется обратить внимание, что пол проставлен верно.
4.2. Фамилия бесполая, имя и отчество справочные, если имя и отчество соответствуют одному полу, форма проставляет пол.
4.3. Фамилия + имя если отчество пустое или по нему невозможно определить пол.
4.4. Фамилия + отчество, если имя пустое или по нему невозможно определить пол.
5. Форма НЕ проставляет пол автоматически при наличии одной только фамилии (имя и отчество – инициалы):
5.1. Иванова И.И. – форма НЕ проставит пол, т.к. тут может быть ошибка – родительный падеж, в этом случае форма оставляет пол пустым, и Вы должны проставить его вручную с анкеты.

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

6.Форма спрашивает о соответствии ФИО и пола один раз, при выходе из блока, при повторном обращении к блоку сообщения выводиться не будут для данной анкеты. При этом анализируются сочетания:
6.1. Окончание фамилии и пол (Иванова – мужской, форма спросит «уверены ли?»).
6.2. Неверные совпадения Фамилия + Имя / Фамилия + Имя + Отчество (Иванова Алексей, или Иванов Алексей Ивановна и т.д. – форма спросит).
6.3. Неверные совпадения ФИО – пол (при наличии полного ФИО), аналогично п. (6.1) – Иванова Алексей женский – форма спросит.
7. В случае, если пол не проставлен – форма при выходе из блока спросит, можете ли вы проставить пол?

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

Недавно, у меня случилась проблема с GD на сервере — он перестал понимать png, после получаса мытарств, решил посмотреть на ImageMagick и его PHP интерфейс IMagick
После недолгого гугления нашел замечательный блог посвященный Imagick. Там же нашел способ делать красивые превьюшки. Однако, способ, предложенный там, правильно отрабатывал только с png картинками. Я немного поковырялся и сделал свой.

Приветствую Хабр.
По мотивам cайта, сделанного сами знаете кем :)
В свое время увидел, такой эффект – слева сайта находятся ссылки, при клике на которые контентная область сайта плавно перемещается к указанному идентификатору. Эффект запомнился — решил повторить.
Для реализации плавного перемещения взял JQuery.

Известен следующий баг «народного» браузера — картинки в формате .png, содержащие участки с альфа-прозрачностью отображаются неправильно. А именно — область этих участков заливается серым цветом (спасибо dreamhelg за лаконичное описание сути происходящего в данном случае).

Сегодня в в своей RSS-ленте обнаружил ссылку на очередную статью о конфронтации .png и IE. Воспринял ее, пожалуй, как и бóльшая половина удививших заголовок выше — с предубеждением (мол, опять двадцать пять). Тем не менее, выяснилось много интересного. Например, теперь фоновые .png отлично подчиняются свойствам background-position и background-repeat.

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

Механизм блокирования в MySQL

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

Как правило, реализация любой идеи начинается с обсуждения планов, графиков и прочих неотъемлемых компонентов серьёзного проекта. Впрочем, бывает и так, что люди без лишних разговоров просто делают то, что считают полезным, тем самым преподнося сюрприз окружающим. Один из примеров тому — практически полный перевод на русский язык цикла статей, входящих в курс Web Standards Curriculum, являющийся частью образовательного проекта Opera. Посему приглашаю всех заинтересованных в данных статьях, но не обладающих хорошими навыками владения английским языком, ознакомиться с русскоязычным вариантом. Уверен, что вы найдёте массу полезной информации, пригодной для использования в своих разработках и проектах.

Читать Web Standards Curriculum на русском

Мы давно мечтали о музыкальном турбосервере. Мечты сбываются! У нас появилось роскошное хранилище музыки, которую может слушать каждый сотрудник по сети через iTunes. Чтобы прослушать всю нашу музыку, понадобится целый месяц! Но это еще не всё…


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

Параллельно с развитием технологий защиты интернет-трафика от несанкционированного доступа развиваются и технологии перехвата защищенного трафика. Перехватить и изучить незашифрованный трафик пользователя уже давно не составляет труда даже для рядового юзера. Практически каждому известно слово «сниффер». Теоретически, защищенные SSL/TSL-соединения перехватить обычными средствами невозможно. Но так ли это?

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

1. Использование дефисов вместо тире em-dash.



Если вам нужно прервать мысль, то делайте это с помощью символа (alt+0151), а не парой знаков «минус». Это, пожалуй, главный источник раздражения для всех редакторов.

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

Fugue Icons

Отличный пак из 1000 иконок в размере 16x16

Эти иконки распространяются по лицензии Creative Commons Attribution 3.0 license.

Ссылка на сайт
Скачать пак | Посмотреть иконки (1199.25 КБ)

Зачем может понадобиться писать демоны на PHP?

• Выполнение трудоемких фоновых задач;
• выполнение задач, которые длятся больше, чем время ожидания при HTTP-запросе (30 секунд);
• выполнение задач на более высоком уровне доступа, чем серверный процесс (читай — под рутом).