Не так давно на Хабре проскакивал пост о появлении нового PHP-фреймворка под названием Yii.
После ознакомления, этот фреймворк показался мне интересным, перспективным и достойным внимания.
Недавно Daniel Carrera выложил в своем блоге интересную статью «Comparison of PHP frameworks» о сравнении CakePHP, CodeIgniter и Yii.
С целью популяризации Yii среди русскоговорящего (и плохо-по-английски-читающего) населения я решил сделать перевод.

Этим постом я планирую начать серию статей о багах IE и возможных вариантах их исправления. Цикл статей решил написать в первую очередь для себя, дабы как-то систематизировать и сохранить свои знания, но я надеюсь, что он будет полезен как новичкам так и опытным верстальщикам.

Первым постом хочу затронуть одно из фундаментальных понятий при исправлении багов IE — hasLayout.

Начинаю вести серию статей Это статья про вёрстку html css js, начинаю с самого простого, потом планирую описать более сложные вещи и всякие тонкости и этим видимо так и закончил

Всем привет.
Под катом — перевод статьи Джеффа Атвуда, в которой он приводит список 25 наиболее опасных ошибок в программировании от Common Weakness Enumeration со своими комментариями.

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

Одной из редко используемых возможностей CSS2.1 являются счетчики. Описаны они в разделе спецификации, посвященной генерации контента. Что же это такое?

Приведу пример из спецификации, эмулирующий обычный нумерованый список с помощью счетчика и свойства content:

OL { counter-reset: item }
LI { display: block }
LI:before { content: counter(item) ". "; counter-increment: item }

Первым правилом мы назначаем элементам OL счетчик с именем «item», затем для всех LI меняем значение свойства display на block, вместо значения по умолчанию (list-item), чем отключаем стандартные маркеры-цифры. Наконец, в последнем правиле, мы инкрементируем счетчик для каждого элемента списка, а само его значение показываем перед элементом c помощью функции counter() и свойства content. Всё просто.

Всем привет! Хабраюзер shai_xylyd написал статью про аспекты тестирования, где им были рассмотрены некоторые понятия и ценности TDD. В частности, он упомянул очень интересный способ создания первичных юнит-тестов — когда функциональный код пишется совместно с кодом юнит-теста, чем меня очень заинтриговал.

Дело в том, что я (как программист), нахожусь в состоянии переходного процесса между «классической» разработкой и разработкой test-driven, поэтому всякими способами ищу возможности упростить и сделать более естественной последнюю. После пары приседаний, сразу включиться в методику shai_xylyd не сумел. Начал переписку с автором статьи, где он натолкнул меня на мысль подойти к решению с математической точки зрения. Идея в том, чтобы воспользоваться функциональным пространством среды программирования и «разложить» написание юнит-теста на составляющие. После чего сделать выводы.

Морфологический анализатор для русского языка — это что-то заумное? Программа, которая приводит слово к начальной форме, определяет падеж, находит словоформы — непонятно, как и подступиться? А на самом деле все не так и сложно. В статье — как я писал аналог mystem, lemmatizer и phpmorphy на Python, и что из этого получилось.

Привет всем

Я решил начать цикл статей на тему обучения программирования в .NET, а именно на C#. Я не претендую на авторство всего, что здесь и далее будет написано, я всего лишь хочу дать знания тем, кто этого желает.
На Хабре много раз могли заметить мои комментарии по поводу того, что я очень хотел бы обучать людей, но никак не мог придумать как это сделать. После цикла статей MaxElc я подумал, что тоже могу паралельно с ним начать писать.
Пожалуй начнём!

Архитектура .NET

.NET — это среда исполнения или платформа. Она располагается между кодом и Windows, позволяя предоставлять нужные службы. Платформа .NET состоит из двух основных компонентов. Это Common Language Runtime и .NET Framework Class Library.

Common Language Runtime (сокращенно CLR) можно назвать «двигателем» платформы .NET. CLR занимается управлением памятью, компиляцией и выполнением кода, работой с потоками управления, обеспечением безопасности и т.п.

.NET Framework Class Library — это набор классов на все случаи жизни.

Периодически натыкаясь на статьи, посвященные оптимизации кода на JS (вот одна из популярных) я ловил себя на мысли, что информации в них катастрофически мало. Перечислены 2-3 конструкции, 1-2 браузера и все на этом.

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

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

Upd: добавил графики результатов, предоставленные хабраюзером deerua (для тех, кто воспринимает визуальную подачу информации лучше чем табличную)

Это продолжение, а точнее развитие, статьи написанной ранее.

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

Перевод статьи Oliver Reichenstein «The 100% Easy-2-Read Standard».

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

Экран и журнал: 100%-размер шрифта — это не много. Фотограф: Wilson Miner.

Не заставляйте нас изменять размер шрифта

Мы не хотим изменять настройки браузера каждый раз когда посещаем новый сайт!

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

Постановка задачи

В проекте есть на данный момент 2 зоны:

1. географическая зона, реализованная на базе Google Maps, которая отображает нанесенные пользователями на карту географические объекты (маркеры, маршруты и области);
2. информационная зона, которая представляет собой большой иерархически организованный каталог, содержащий информационные материалы.

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

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



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

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

ФИО должны вводится в именительном падеже!
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. В случае, если пол не проставлен – форма при выходе из блока спросит, можете ли вы проставить пол?

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

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

Что есть правильная посадка в кресле?

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

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

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

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

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

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

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

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

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

Команда разработчиков symfony в очередной раз радует нас выпуском новой версии фреймворка в которой реализовано множество новых возможностей и фишек.

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

Видимо, для решения данных проблем разработчики фреймворка решили продолжить цикл статей, показывающих примеры реализации веб-проекта от начала и до конца с использованием symfony 1.2.

Называется туториал «The Jobeet», по сути это сайт для размещения вакансий, наподобие раздела «работа» на хабре.

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

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

Привет.

Наверное, многие из вас пользовались стандартными javascript-виджетами, написанными как безвестными разработчиками, так и крепкими профессионалами, так и гуру. Есть великолепные коллекции виджетов, поставляемых в качестве плагинов к известным фреймворкам (вроде jQuery, Prototype JS, YUI), так и целые фреймворки, акцентирующие свое внимание на создании виджетов, вроде Ext JS или qooXdoo.

Но что, если вы не хотите использовать достаточно объемный фреймворк для создания простого диалогового окна, или хотите разобраться в том, как создаются такие виджеты, или даже разрабатываете собственный фреймворк?

Об этом и пойдет речь в сегодняшнем посте — как сделать простейшее диалоговое окно и alert средствами чистого javascript, без применения каких-либо фреймворков.

Речь в статье пойдет о такой, казалось бы изжеваной и изъезженой теме, как валидация веб-документа по одной из DTD-схем, которые в свою очередь определяются с помощью DOCTYPE.

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

В последнее время, многие редакторы и CMS'ки автоматически проставляют DOCTYPE для документа, что само по себе является прорывом, но к сожалению этого недостаточно, так как зачастую это именно Transitional схема. Начинающие разработчики не уделяют этому должного внимания, а зачастую вобще не подозревают что у них есть выбор.