Пароль должен сохраняться в браузере

Всегда важно предоставлять вашим пользователям пользоваться автоматическим сохранением пароля в браузере. На десктопах это позволяет сэкономить несколько секунд, а на мобильниках несколько минут. Попробуйте например набрать несколько раз пальцем на тачскрине логин типа askme@usabili.ru и пароль типа ">pf,bkbnbvj,bkmybrjd-pkj". Поэтому это очень важный момент. К сохранению в браузере я отношу и плагины менеджеров паролей, типа roboform.

Форма логина должна проверяться без перезагрузки

Когда вы ошибаетесь в наборе логина и пароля — очень раздражает, если каждый раз вам приходится загружать новую страницу на которой написано только то что вы ошиблись, или использовали недопустимый символ. Поэтому логично делать проверку авторизации аяксом, вида form onsubmit="somecheck();return false;".

В самой функции somecheck() делается ajax запрос, проверяется результат, и, в случае успеха, делается редирект в закрытый раздел через self.location="/some".

Пару месяцев назад, мы с коллегами столкнулись с досадным багом в хроме. Хром не предлагает сохранить пароль если onsubmit формы возвращает false. Баг с ноября 2009, уже полгода имеет статус fixed, хотя работает до сих пор. Примеры тут: простой и сложный. В сложном примере на секунду появляется таки запрос сохранения, но тут же пропадает. В dev-версии хрома (18) сложный пример работает как надо.

Решением было обнулять функцию сабмита формы, а затем сабмитить её. Разумеется при этом action формы должен вести куда надо.

document.getElementById('login_form').onsubmit=function(){return true;};
document.getElementById('login_form').submit();

Конечная страница не должна получать лишних POST параметров

 Дело в том, что когда страница содержит данные, переданные методом POST, то при обновлении страницы (например нажав F5) браузер сначала спросит хотите ли вы отправить данные ещё раз. Это ненужный пользователю вопрос. Чтобы этого избежать нужно не сразу посылать пользователя на конечную страницу, а посылать на другую, которая сделает редирект на нужную. В таком случае не будет лишних POST параметров. Пример можно увидеть в действии при авторизации в этом блоге.

Пароль должен быть по-желанию открыт пользователю

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

Якоб Нильсен — один из известнейших юзабилистов в мире, с 1995 года писал о безопасности паролей и человеческом факторе (Human Factors of Password Security), и в 2000 писал (Security & Human Factors), и в 2009 писал (Stop Password Masking). Много всего хорошего о паролях, и в частности о том, что звёздочки у паролей пользователям-то не нужны. Но почему-то никто не воплощает его слова в реальность. Даже в мобильных (!!!) браузерах нет настройки "показать мне все мои пароли", это искренне бесит. А ведь на многих сайтах для регистрации просят "подтвердить пароль" (пожалуйста, не менее 6 символов, используйте цифры и буквы разного регистра) — господи дай этим людям мозгов. В большинстве настроек андроида пароли тоже скрываются, хотя казалось бы...

It's time to show most passwords in clear text as users type them. Providing feedback and visualizing the system's status have always been among the most basic usability principles. Showing undifferentiated bullets while users enter complex codes definitely fails to comply.

Most websites (and many other applications) mask passwords as users type them, and thereby theoretically prevent miscreants from looking over users' shoulders. Of course, a truly skilled criminal can simply look at the keyboard and note which keys are being pressed. So, password masking doesn't even protect fully against snoopers.

More importantly, there's usually nobody looking over your shoulder when you log in to a website. It's just you, sitting all alone in your office, suffering reduced usability to protect against a non-issue.

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

Итак, что тянуть резину, давайте сделаем это! Вот какой концепт получился у меня — http://usabili.ru/labs/browser_bugs/test_visible_passwd.html. Это кроссбраузерная (Chrome, Opera, Firefox) реализация незамаскированного пароля. Важно именно то, что браузер здесь запоминает пароль, хотя пароль может вводиться открытым текстом. Для того чтобы любой браузер вообще предлагал сохранять пароль — необходимо чтобы пароль был полем type="password", при загрузке страницы.

Просто так менять яваскриптом тип поля ввода — нельзя. Чтобы поменять его — необходимо пересоздать весь элемент. Для этого воспользуемся такой функцией:

function changeInputType(oldObject, oType) {
	var newObject = document.createElement('input');
	newObject.type = oType;
	if(oldObject.size) newObject.size = oldObject.size;
	if(oldObject.value) newObject.value = oldObject.value;
	if(oldObject.name) newObject.name = oldObject.name;
	if(oldObject.id) newObject.id = oldObject.id;
	if(oldObject.tabIndex) newObject.tabIndex = oldObject.tabIndex;
	if(oldObject.placeholder) newObject.placeholder = oldObject.placeholder;
	if(oldObject.className) newObject.className = oldObject.className;
	oldObject.parentNode.replaceChild(newObject,oldObject);
	return newObject;
}

Итак, основной концепт состоит в следующем. Когда страница грузится — тип поля с паролем обязательно должен быть password. После этого пользователь может показать или скрыть пароль. Во время сабмита формы (при проверке аяксом, см. выше) — пароль необходимо принудительно скрыть. А затем вызвать сабмит формы.

Однако есть одна особенность. В файрфоксе и опере — вызов .submit() формы — не вызовет диалог сохранения пароля. Однако этот диалог — вызывается если кликнуть по кнопке сабмита данной формы вызвав .click();. Таким образом, для кроссбраузерной реализации, перед сабмитом формы — мы должны кликнуть по кнопке сабмита. Общий алгоритм в вашей аякс-проверке должнен получиться примерно такой:

if(auth_success) {
	changeInputType(document.getElementById('password'), 'password');
	document.getElementById('login_form').onsubmit=function(){return true;};
	document.getElementById('login_button').click();
	document.getElementById('login_form').submit();
	return true;
}

Кнопку переключения маскировки можно оформить иконками, как это предложено Лебедевым. Например так:

Так же проставить полям атрибуты tabindex и placeholder.

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

• Stop Password Masking (Jakob Nielsen's Alertbox)
• Schneier on Security: The Problem with Password Masking
• Schneier on Security: The Pros and Cons of Password Masking
• Is usability worth more than security?
• Keep an eye on your iPhone | Naked Security
• Usability and security gurus agree that masked passwords should go
• Security guru says he was 'probably wrong' to attack masked passwords
• Password Masking – a Necessary Evil » CounterMeasures
• Apparently we should no longer blank passwords when entered on websites. Thoughts? | Security Active Blog
• about face on bruce schneier | Jahne - Virus and Spyware Removal
• The websecurity June 2009 Archive by thread

А что думаете вы?

Чтож, хотя это никому не интересно, я выскажу своё отношение к браузеру.

Файрфокс для меня и моих коллег - является инструментом №1 в работе. Кроме удобных расширений, типа web-developer toolbar, httpfox, и html validator браузер имеет ряд нативных инструментов, таких как подсветка кода, удобный style editor в nightly версиях и доступный в свежем релизе инспектор html. Так же огромным плюсом является низкое потребление памяти. Например для одинаковых 20 вкладок фф потребляет 330 мб, а свежий хром 585, т.е. почти в 2 раза больше. (В опере 383). Файрфокс более старый и привычный браузер, хотя UX-сотрудники mozilla всячески пытаются сделать его непривычным и отбить нелояльных пользователей.

Что касается частой смены релизов, которое так обсуждают на хабре, в духе "Опять новый фарфокс, вот в советское время он так часто не выходил", то я считаю частую смену мажорной версии нормальным решением. И кстати соответсвующим духу mozilla, вспомним, что браузер Netscape - пропустил выход 5й версии когда вышел ie6. Если почитать например про нумерацию версий программного обеспечения в википедии, то можно найти ряд ещё более экзотических примеров. Например Опера, по абсолютно глупым причинам с 10й версии указывает в строке User-agent - версию 9.80. А так, я считаю всем уже всё равно какой цифры браузер. Хотя конечно правильнее было бы выпускать одну версию в квартал, как планировалось, а не одну версию в 6 недель как сейчас. Мне кажется, что в будущем файрфокс либо будет именовать версии номером года и месяца (как убунта например), либо придумает новое название, как photoshop cs.

Какие-то революционные перемены должны произойти и в быстродействии. По моим субъективным меркам Файрфокс является весьма медленным браузером по сравнению с Оперой и Хромом. Дело в том, что несмотря на то что файрфокс выигрывет в скорости на ряде математических действий - работа с Dom и CSS у него поставлена весьма плохо.

Одним из таких изменений должен стать проект electrolysis, который на начальном этапе позволил сделать Out-of-process plugins, а в конечной позволит сделать Out-of-process tabs, как это сделано в хроме. Т.е. быстродействие конкретной вкладки перестанет зависеть от других вкладок и вообще от их количества.

Также разработчикам нужно серьёзно переструкрутировать их базу данных, например places.sqlite, потому что сейчас например работа с закладками превращается в кошмар, когда их собрано более тысячи штук. Пока что разработчики фф пытаются начать взаимодействие собственно с разработчиками sqlite чтобы оптимизировать работу с ней, либо вообще отказаться от этой библиотеки.

Что касается прочего быстродействия, то разработчикам нужно перестать гнаться за количеством багов, а смотреть на качество. В баглисте текущего релиза  http://www.mozilla.org/en-US/firefox/10.0/releasenotes/buglist.html всего несколько багов затрагивающих быстродействие. Складывается впечатление что разработчикам проще писать новый код, чем вносить правки в старый. Неужели проще было вводить поддержку html5-элемента <bdi>, чем ввести поддержку input[type=number], или сделать хотя бы черновую поддержку других input элементов? Почему поддержка <video> и <audio> появилась довольно быстро несмотря на сырость, а по каким-то вопросам идёт многолетнее ожидание окончательной спецификации?

Ну и конечно заявление о том что большинство дополнений файрфокс теперь по-умолчанию совместимо с файрфокс - для меня звучит как шутка. =)

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

Спасибо моим коллегам за помощь в написание статьи.

Я до этого не обращала внимания что там нового у яндекса, а оказалось новый формат разметки они уже с ноября прошлого (2011) года поддерживают. А ввели его Google, Microsoft и Yahoo аж в июне. Что ж, обычные микроформаты сказала я, глянув один раз на пример. Глянув на пример второй раз я заметила что микроформаты как раз необычные. И более того, используют кажущуюся невалидной с точки зрения html разметку. Об этом я и хочу сегодня рассказать, надеюсь статья будет интересной.

Микроформаты от Microformats.org

Я думаю что вам всем знакомы такие микроформаты типа hcard, hProduct и т.п. большая часть которых написана Тантеком Селиком (Tantek Çelik)  (известным веб-идеологом, редактором спецификации CSS и других). Они позволяют добавить семантическую аннотацию к тем элементам разметки которые вы используете посредством имён классов. Например так:

<div class="vcard">
 <div>
   <span class="category">Кафе</span>
   <span class="fn org">Ромашка</span>
 </div>
 <div class="adr">
   <span class="locality">г. Солнечный</span>,
   <span class="street-address">просп. Романтиков, д. 21</span>
 </div>
 <div>Телефон: <span class="tel">+7 (890) 123-45-67</span></div>
 <div>Мы работаем <span class="workhours">ежедневно с 11:00 до 24:00</span>
   <span class="url">
     <span class="value-title" title="http://www.romashka-cafe.some"> </span>
   </span>
 </div>
</div>

Данная разметка как видно полностью валидна с точки зрения html, и так же доступна для стилизации через css. Подробнее о микроформатах можно почитать в хелпе яндекса.

Микроформаты от Schema.org

Данный вид микроформатов заметно отличается, как видно из примера:

<span itemscope itemtype="schema.org/ImageObject">
  <h2 itemprop="name">Винни-Пух</h2>
  <img src="vinni.jpg" itemprop="contentURL" />
  <span itemprop="description">Винни-Пух залезает на дерево.</span>
</span>

Он не использует классы, для элементов разметки, а вместо них использует новые, пока ещё не валидные атрибуты. Говоря слово "пока", я должна перейти к ответу на самый главный вопрос в статье.

Валидна ли вёрстка от Schema.org?

И отвечая на этот непростой вопрос, я хочу сказать, "Да, вёрстка валидна". Теперь постараюсь ответить почему.

Дело в том что эта схема, вовсе не выдумка поисковых систем. Данный метод для семантической аннотации структурированных данных в HTML, впервые предложил никто иной как Хикси (Ян Хиксон, действующий редактор стандарта разметки html5). И предложил он это ещё три года назад в рассылке группы whatwg. Очень рекомендую к прочтению:

[whatwg] Annotating structured data that HTML has no semantics for
Ian Hickson, Май 2009

В данный момент, он же, под пишет полноценную спецификацию W3C касательно микроформатов - www.w3.org/TR/microdata/

Данная спецификация представляет собой модуль, расширяющий спецификацию HTML, (примерно как сейчас выходят новые модули к CSS), одним из нововведений которого, являются 5 новых глобальных атрибутов:

• itemid
• itemprop
• itemref
• itemscope
• itemtype

Напомню, что это атрибуты которые могут применяться к любому тегу. В текущей спецификации html всего 14 глобальных атрибутов.

Что касается поддержки в браузерах, то в ней пока нет смысла, в них ничего не развалится. Для xml разметки логический атрибут itemscope, должен записываться как обычно, в виде itemscope="itemscope".

Интереснее с поисковыми системами. Пока что именно для них микроформаты и предназначены. Здесь хочется поздравить соотечественников, в рабочую группу Schema.org, с ноября месяца, наряду с Гугл, Микрософт (bing) и Яху, входит и Яндекс. Соответственно данные микроформаты в полной мере распознаются данными поисковиками и учитываются в поиске.

Данные глобальные атрибуты уже добавлены в ряд неофициальных валидаторов разметки, но пока не попали в официальный validator.w3.org. Однако повторюсь, уже сейчас я признаю эту разметку полностью валидной.

Узнать какие схемы использует в поиске яндекс можно в соответствующем разделе хелпа. Замечу, что хотя это не сказано открыто, вместо <div> или <span> вы можете использовать любые (блочные и строчные) элементы. Проверить вашу разметку микроформатов можно тут: http://webmaster.yandex.ru/microtest.xml.

Что же ещё готовит спецификация?

Для браузеров, спецификация готовит ряд функций для работы с DOM: http://www.w3.org/TR/microdata/#microdata-dom-api примерно реализующие предпосылки 2009 года (см. ссылку ранее). Возможности стилизации используя CSS пока не предполагается, автор делает упор на разграничения классов используемых для CSS и семантики.

Спецификации от Schema.org и Microformats.org - не взаимоисключающие, вы можете использовать их на одной странице, например микроформаты hcard и ImageObject.

Дополнительные ссылки:

• Semantic Web Interest Group - Web Schemas Task Force
• Microformats vs. Schemas ~ A Blog Not Limited
• 3.2.3 Global attributes — HTML5
• Re: [whatwg] Annotating structured data that HTML has no semantics for. by Eduard Pascual
• Много нового про семантическую разметку от Яндекса / Микроформаты (microformats) / Хабрахабр (заметьте, ни слова о валидности!)
• - rNews 1.0: Schema.org-compatible Implementation Guide HTML 5 Microdata

Сама статья о том что автор, якобы нашёл баг в отображении браузерами табличной вёрстки. Причём основное внимание внимание обращается на отличия в хроме, и особенно на глюки с шириной. Исходный код страницы здесь. Статья набрала 67 комментариев и 61 добавление в избранное!

Но, позвольте, ежу ведь понятно что дивы (слева) никогда не будут отображаться так же как ячейки (справа). Единственный баг который мне бросается просто в глаза - это  баг файрфокса в отображении свойства box-sizing:border-box, для элементов с типом отображения table-cell, баг известный и старый (bug 338554), смотрите так же bug 243412 где изложена точка зрения мозиллы на этот счёт.

Что касается всего остального - отображение браузеров полностью соответствуют спецификации. Неужели сложно прочитать два параграфа из неё?

http://www.w3.org/TR/CSS2/tables.html#width-layout

Потратьте время, вкурите мануалы, и убедитесь почему это так.

Я считаю, люди, которые умеют верстать, либо ушли работать в серьёзные компании, типа яндекса, оперы и т.п., либо у них просто нет времени сидеть на хабре. Или быть профессионалом уже не модно?

Если вы делаете багрепорт - ссылайтесь на спецификацию!

Автор в примере даже использует атрибут cellspacing для таблиц. Фееричнее всего смотрится рассуждение о возможности использования border-collapse: collapse вкупе со ссылкой на http://htmlbook.ru/html/table/cellspacing ! Зайдём на страницу, что написано? "Аналог CSS: border-spacing". Вуаля! Почему об этом не сказал никто из полусотни комментаторов? Как могут люди всерьёз считать, что отображение таблиц в десктопных браузерах отличаться между операционными системами в одних и тех же версиях! 

Всем кто не знает сообщаю:

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

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

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

18 января (UTC-5) на 24 часа в знак забастовки отключена Википедия на английском языке. День выбран в связи с заседанием Конгресса, на котором должен обсуждаться законопроект SOPA. Сообщество Википедии на русском языке поддерживает коллег и призывает всех тех, кто видит этот текст, помочь в противодействии принятию закона.

Я считаю что если кто-то делает сплеш баннер который блокирует частично или полностью содержимое сайта - он должен быть наказан. Вне зависимости от законопроектов. Т.е. если бы все страницы с википедии - стали бы пересылаться на сайт конгресса США (задосив его тем самым), то это было бы правильно, я считаю. Ну, подумаешь день сайт не работает.

Но использование сплеш скрина который закрывает сайт после загрузки сайта - это моветон и чёрное seo. Я решила бороться с этим через следующие правила фильтрации AdBlock:

|http://en.wikipedia.org/w/index.php?title=Special:BannerController*
|http://ru.wikipedia.org/w/index.php?title=%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:BannerController*

 Расширение Adblock, если кто не в курсе служит для блокировки рекламы в Firefox и Chrome. Данные фильтры - возвращают доступ к английской википедии. Ну и заодно убирают грустные лица создателей с российской версии.

Я считаю что когда википедия ограничивает мой доступ к статьям про Римский календарь, Делитель нуля, Процедурное программирование, Разделение ответственности, Дамаст, ECMAScript, Объекты первого класса, Boot to Gecko, Божественный объект, Прокрастинацию, Songket, Эритрею, Напалм, SATA и сериал Рим, тогда это хуже чем любая SOPA!

С прошедшими праздниками вас!

С праздником!

Developers! Developers! Developers! Developers! © Stiven Ballmer

Речь в сегодняшней статье пойдёт в основном о яваскриптах, потому что именно их я преподаю сейчас стажёру нашей компании. Поэтому статья носит в основном методологический характер.

Что такое объект?

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

Объект — Сущность в адресном пространстве вычислительной системы, появляющаяся при создании экземпляра класса или копирования прототипа (например, после запуска результатов компиляции и связывания исходного кода на выполнение).
Википедия

Заметьте, в довольно простое определения навязали адресное пространство, компиляцию, классы и прототипы. Это всё равно что спросить что такое птица, а в ответ получить что это сущность употребимая в пищу и вылупляющаяся из яиц!

Объект — некоторая сущность в виртуальном пространстве, обладающая определённым состоянием и поведением, имеет заданные значения свойств (атрибутов) и операций над ними (методов). Как правило, при рассмотрении объектов выделяется то, что объекты принадлежат одному или нескольким классам, которые в свою очередь определяют поведение (являются моделью) объекта. Время с момента создания объекта (конструкция) до его уничтожения (деструкция) называется временем жизни объекта

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

Объект — это сущность, которой можно посылать сообщения, и которая может на них реагировать, используя свои данные. Данные объекта скрыты от остальной программы. Сокрытие данных называется инкапсуляцией.

Опять таки. В определении говорится об инкапсуляции. А что если данные объекта не скрыты? В прочем поскольку моя статья про яваскрипты, данное определение вообще никакой смысловой нагрузки не несёт.

Объект в программировании, это такая штука, которая не всегда может иметь визуальное представление, типа кнопки или поля. Скорее наоборот.
Представь себе массив — упорядоченный набор переменных. Каждая переменная в обычном массиве может содержать строку, число, (любую типизированную переменную) или другой массив. Поэтому моё определение звучит так:

Объект — это массив, который может содержать в качестве переменных, кроме всего прочего, функции или другие объекты.

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

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

The programming construct that combines data with a set of methods for accessing and managing those data is called an object. © en.wikipedia.org

Т. е. данные, и набор функций (методов) для работы с этими данными называются объектом.

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

Объекты в Javascript

Теперь внимание, дальше вы можете запутаться!

В яваскриптах — почти всё является объектами, но не всё называется объектами. Число — или строковая переменная (или сущность) — не называются сами по себе объектами! Но по факту — являются ими.

Например у числа или строки могут быть встроенные функции. Т. е. функция.split например — аналог строковой функции explode в php и т. п.

var a = 'te.st';
var b = a.split('.'); // в b - будет массив из значений te и st

Чтобы понять сказанное выше утверждение, приведу такой аналог: «насекомые и птицы — не называются животными, хотя по факту являются ими». Т. е. вы видите на улице собаку или слона и говорите «О, какое животное». А когда видите птицу, говорите «какая птица», хотя из биологии это тоже царство животных. А собаки или слоны относятся к млекопитающим. Так и тут, когда вы видишь число или строку — нет нужды говорить «о, какой объект». Лучше сказать какая строка или какое число. А вот когда вы видите, например, документ html — document, или его тело — document.body — тут уж можно сказать «какой объект», просто потому что он уже и не число и не строка.

Далее, небольшая тонкость касающаяся массивов. В яваскриптах есть названия для классов объектов — строка, число, массив и, внимание(!), Объект. Так и приходится писать объект объект.

новый массив можно создать например как:
a = new Array(); или в сокращённой нотации a = [];
новый Объект (буду писать с большой буквы), можно создать так:
a = new Object(); или в сокращённой нотации a = {};

в объект массива — [] — мы можем записывать только числовые, строковые и булевы переменные. Ну и другие массивы тоже. В объект Объекта — мы можем записывать то же самое + функции. Пример:

var a = {1,2,3, 'my_func': function(){ do_something; } };

Обращу внимание, что функция будет доступна как элемент массива: a['my_func'](); и как метод объекта a.my_func(); — в принципе равнозначно, как кому нравится.

Теперь внимание — массив, может содержать индексы элементов, т. е. на какой позиции какая переменная находится. В яваскриптах массив может содержать только ЧИСЛОВЫЕ индексы. В то время как объект — может содержать любые индексы переменных.

Индексы в записи Объекта пишут так index:value, однако это не подходит для записи массива (спасибо SelenIT в комментариях), поэтому запись

a= [1:'something', 2:'something']; — НЕ верна
a= ['first':'something', 2:'something']; — НЕ верна
a= {'first':'something', 2:'something'}; — верна

Но можно создать такой объект

var a = {'вася':'Пупкин'};

и обращаться к нему как к массиву

alert(a['вася']));

Подробнее об этом написано в моей статье «Javascript — работа с массивами и объектами» (09.2009).

Теперь я расскажу о функциях. Функции — так же как и строки, и числа, и Объекты, являются в какой-то степени объектами. Они, согласно моему определению «объект — это данные + функции» — могут содержать набор данных, и (!) функций.
Отличия от строк — и т. п. — в том что чтобы вызвать внутреннюю функцию функции, или же переменную объявленную внутри функции необходимо вызвать саму функцию, объявляются внутри с помощью кодового слова this. Вся эта конструкция выглядит так:

function test(){
         // do_something;
         this.x = 5;
}
тогда a = test().x; // равно 5

функция при этом выполняется, и может что-то делать:

<script>
function test(){
         // do_something;
        alert('test');
         this.x = 5;
}
a = test().x;

</script>

присвоит переменной число 5 — и покажет alert().

Ссылки на объекты

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

Когда происходит присвоение переменной строки, числа или логической переменной, это создаёт копию этого значения. В то время как присваивание переменной массива или объекта создаёт ссылку на это значение. Это вызывает путаницу, т. к. оказывается что изменение одной копии массива изменяет и вторую когда не надо, и наоборот когда надо присваивание свойства элемента переменной не изменит его с изменением этого свойства.

Пример:

a=document.title; // Присваиваем переменной a - значение заголовка документа 
 a='test'; // присваиваем переменной другое значение, заголовок документа не меняется 
a=document; // присваиваем переменной значение документа 
 a.title='test'; // присваиваем заголовку значение - меняется заголовок окна.

Об этом, и о том как копировать объекты и массивы, так же написано в моей прошлой статье «Javascript — работа с массивами и объектами».

P.S. Так же очень хочу сказать что Джон Ресиг (создатель jquery если кто не в курсе), недавно выступил с отличной и правильной идеей преподавания javascript в качестве первого языка программирования. Пожалуйста прочитайте его статью: Яваскрипт как первый язык программирования.В ней он так же затрагивает некоторые вопросы методологии, и как и я подчёркивает то, что в яваскриптах всё, включая функции является объектами. Цитирую:

Function Declarations

Perhaps the most interesting change that we can make is a rather subtle one, but it's eschewing normal function declarations for creating anonymous functions and assigning them to a variable.

// Don't do this:
function getData() { }
// Do this instead:
var getData = function() { };

There are a number of good habits that are instilled when you use this particular technique.

Makes it easier to understand "functions as an object". I've found that when you show new developers a function being assigned to a variable it suddenly becomes much more obvious that a function is actually an object and can be manipulated as such (and that a function can be passed as an argument to another function). Thus students are advanced along the path towards a better understanding of functional programming.

С удовольствием выслушаю ваши замечания по теме.

С наступающим, дорогие друзья!
Я так и не нашла силы побороть лень и дописать таки статью о вариантах комментариях, которую пишу уже месяца четыре. Думаю ничего страшного если она полежит у меня в запасниках ещё немного.

Сегодня я зашла таки, на рекламированный Вадимом Макеевым портал Web-Standards.ru. И, на удивление обнаружила там перевод заметки «Why we don’t have a parent selector» Джонатана Снука, написанная, что символично, 10 октября прошлого года (10.10.10). Собственно вот ссылка на сам перевод — «Почему у нас нет селектора по родителю» 20.09.11.

Сама статья бесспорно хорошая, в ней говорится вообще о том как писать быстрый код, почему селектор потомков медленный, почему селектор родителя был бы ещё медленнее, однако не говорится почему собственно есть хоть одна причина такой селектор не сделать. Да, это будет медленно. Да, всем понятно что селектор по id самый быстрый. Но в любом случае мы говорим о миллисекундах машинного времени. Обычно этим можно принебречь если сайт нагружен картинками и потоковым видео.

Собственно я бы не стала об этом писать если бы не прочитала ещё в сентябре черновик селекторов четвёртого уровня. Т. е. то, что мы будем называть CSS4.
Ссылка: http://www.w3.org/TR/2011/WD-selectors4-20110929/#overview
В самом низу указан родительский селектор: $E > F , который выбирает элемент E, родитель элемента F.

Кроме селектора родителя, конечно добавилось много других новых, клёвых селекторов, которые отнимут у Джонатана Снука ещё лишние секунды жизни.

Заключение

Безусловно, в тех проектах, в которых важна скорость работы в браузере — нет места подобным селекторам. Пример: проект, который я сейчас разрабатываю, расчитан на использования только в современных браузерах полностью исключая IE6-8, и возможно IE9 из-за их низкой скорости работы с dom; и тем не менее, в оформлении используются только селекторы id и класса; в яваскриптовом коде большинство селекторов заменены с jquery на нативные и т. п.

Т. е. каждый разработчик обязан представлять себе где и сколько времени отнимает выполнение его кода (css, js, html). Но при этом инструменты для того чтобы сделать «быстро и сразу» должны быть. Например на главной странице моего блога, менее 400 элементов в DOM, использование тормозящего селектора в данном случае вообще не будет заметно.

Спасибо что читаете мой блог! =)

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

• в байте 1024 бита
• в байте 8 бит потому что 8 — степень двойки
• бит принимает всякие разные значения от 0 до 1

В числе прочих забавных случаев: для выбора десяти случайных чисел из бд, соискатели десять раз делают запрос; для открытия файла на чтение используют в PHP флаг 'a+'; не умеют работать со строками, кодировками и указателями. Написать функцию, которая возвращает строку задом намерёд, не используя переменную-буфер — вообще непосильная задача.

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

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

• Бит — это двоичный логарифм вероятности равновероятных событий или сумма произведений вероятности на двоичный логарифм вероятности при равновероятных событиях; (или другими словами) бит — это единица информации, равная результату эксперимента, имеющему два исхода
• Бит — минимальная единица информации.
• Байт — минимальная адресуемая единица информации.

Из-за этих определений, в умах будущих программистов ЭВМ, больше каши, чем из-за каких-либо других определений! Они совершенно истинны, но совершенно бесполезны для обучения. Я превращаюсь в Халка, когда слышу их.

Про биты

Итак, дети, садитесь, урок первый, представьте себе выключатель. Нет, не двоичный логарифм вероятности… А обычный такой выключатель, тумблер, рычажок, что угодно, включающее например лампочку, когда находится в одном положении и выключающее в другом. На некоторых рычажках даже подписывают буковки I/O, как указатели положений ручки. Нет, выключатель не несёт в себе информацию. Он выключает свет.

У выключателя есть два положения — вкл/выкл. Если мы поставим рядом два выключателя, то количество комбинаций позиций, которое могут занимать их ручки — четыре. (Когда оба выключены, когда оба включены, и две комбинации когда включен только один из них). Если мы возьмём систему из трёх выключателей — они смогут занимать восемь комбинаций. И так далее, N выключателей имеют 2^N комбинаций. Выключатель который имеет только два положения (вкл/выкл) мы можем назвать битом. Если мы представим, что положениям вкл/выкл соответствуют числа 1 и 0, то можно легко записать какое-нибудь целое число в двоичной системе счисления, используя только последовательный набор выключателей, так чтобы каждый выключатель отвечал за свой двоичный разряд.

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

Однако, в этих ноликах и единичках нам надо хранить информацию. Какую же информацию нам можно хранить? Давайте рассмотрим один бит. Мы можем условно договориться, что он может хранить информацию, и два его состояния вкл/выкл содержат значения «баклажан» и «не баклажан» соответственно. Это отлично подходит, когда нам надо произвести учёт баклажанов! Однако в реальном мире компьютеры, которые умеют только считать баклажаны — не пользуются спросом. Выходит выключатель (бит) не может нести в себе информацию. Чтобы записывать ноликами и единичками какую-то информацию, было решено группировать их по несколько штук, и такую группу называть байтом.

Байт

На заре компьютеров байты составляли 4, потом 5, потом 6 бит… Группа из 6 бит может принимать целых 64 значений. Вполне неплохо, так как можно создать некую таблицу соответствий этих значений определённым символам — кодировку. Такая кодировка уже может содержать цифры и заглавные буквы латинского алфавита, а также некоторые арифметические знаки. «Шестибитные-кодировки» — применялись на компьютерах в 1950-х — 1960-х годах.

Для человека который только начинает изучать информатику, будет понятно и легко запомнить что байт — является минимальной единицей информации. В байт можно записать какое-нибудь число, либо например какой-нибудь символ из таблицы символов (англ. charset, буквально «набор символов») — кодировки (codepage, encoding).

С развитием компьютеров, появилась потребность в большем количестве значений для байта. В 1963-м году появилась первая редакция семибитной кодировки ASCII. Поэтому байты стали занимать 7 бит. 7 бит, требующиеся для одного символа данной кодировки позволяют использовать 128 значений. В этой кодировке уже были включены строчные латинские символы, и больший набор управляющих и арифметических символов.

Всемирное распространение компьютеров подтолкнуло дальнейшее расширение границ занимаемых байтом. Для различных языков требовалось чтобы таблица символов также могла хранить алфавит того языка, где используется данная ЭВМ. На текущий момент восемь — это последнее и видимо окончательное количество бит составляющих байт. Соответственно байт может принимать 256 значений. По сравнению с таблицей ASCII в. новых таблицах символов — организовалось 128 вакантных мест. Теперь я думаю можно рассказать как значения хранятся в различных кириллических кодировках.

Кодировки

Итак, чтобы хранить символы не входящие в ASCII, необходимо было придумать новые кодировки. Поскольку до этого таблица ASCII была наиболее подходящей (были и другие), то она и пошла в основу новых кодировок. Поэтому следующие кодировки отличаются только значениями начиная с 80 (hex). Для наглядности оставлю только кириллические символы.

Так выглядела наиболее популярная кодировка под DOS. Примечательно что файлы в этой кодировке до сих пор встречаются. Как правило среди устаревшей архивной информации, в программах WinRar, Блокнот и WordPad, до сих пор есть опции «открыть как текст DOS», впрочем последними двумя мало кто пользуется =).

Кодировка koi8 была примечательна тем, что русские буквы там располагались на позициях английских звуков из нижней половины (т. е. ASCII). Это когда-то давно позволяло смягчить переход со старых серверов понимающие только ascii на новые, что было актуально среди почтовых серверов. Смысл был в том что если отправленное вами письмо приходило на старый сервер, то пользователю оно показывалось как транслит, что позволяло хоть как-то понять текст письма.

Самая популярная у нас в России однобайтная кодировка, на сегодняшний день, это именно «windows-1251». Разумеется популярность её целиком обусловлена популярностью Windows среди других операционных систем. Возможностей кодировки вполне хватает для использования её в широком круге задач. Например движок моего блога, по-умолчанию, использует для работы именно данную кодировку.

Я не могу не упомянуть о кодировке ISO, Удивительно, но несмотря на то что её никто никогда не использовал, эта кодировка является единственной кодировкой имеющей статус стандарта.

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

Но что делать когда этого не достаточно?

Многобайтные кодировки

Если вам хочется создать кодировку которая бы имела коды одновременно для русского и греческого алфавита? Одним байтом тут не отделаться. Появилась задача разработать кодировку один знак которой может занимать больше чем один байт, так как два байта могут принимать уже 2^16 = 65536 значений, а четыре байта аж 4294967296. Поэтому сначала придумали стандарт кодирования символов — Юникод, который включал бы в себя максимально полный перечень символов которые может принимать один знак.

Первая версия Юникода (Unicode 1991 г.) представляла собой 16-битную кодировку с фиксированной шириной символа; общее число разных символов было 2¹⁶ (65 536).

Вторая версия Юникода (UCS-2), стала называться UTF-16, она позволяла гораздо расширить количество возможных значений, также используя для символов 16-битные последовательности (т. е. по 2 или по 4 байта на символ).

Символы с кодами 0×0000.0xD7FF и 0xE000.0xFFFF представляются одним 16-битным словом, а символы с кодами 0×10000–0×10FFFF — в виде последовательности двух 16-битных слов. Количество символов, представляемых двумя 16-битными словами равно (2²⁰). Для представления символов с кодами 0×10000–0×10FFFF используется матрица перекодировки. Первое слово из двух переданных лежит в диапазоне 0xD800-0xDBFF, а второе — 0xDC00-0xDFFF. Именно этот диапазон значений не может встречаться среди символов, передаваемых с помощью одного 16-битного слова, так что расшифровка кодировки всегда однозначна. Ясно, что имеется как раз 2¹⁰ * 2¹⁰ = 2²⁰ таких комбинаций.

Википедия — UTS-2

Кодировка UTF-32 (UCS-4) использует по 32 бита, или 4 байта на хранение одного символа. Строго говоря, стандарт Unicode не описывает символы со значениями выше 2^21, так что хватило бы и трёх байт, на символ, вероятно компьютеры работают несколько быстрее с мелкими блоками памяти кратными двум, или для того чтобы в сектор диска попадало кратное количество символов. Так или иначе это единственная из многобайтных кодировок с постоянной длиной. Помимо недостатка — использования четырёх байт на символ, у неё есть и очевидное преимущество — возможность прямой адресации к N-ному символу. В других кодировках требуется последовательное вычисление позиции каждого символа. Поэтому текстовые редакторы, внутри себя хранят всю информацию в виде UCS-4.

В 1992 году Кеном Томпсоном и Робом Пайком был изобретён формат UTF-8. Он отличается тем, что он ASCII совместим, и значения из таблицы Юникода могут занимать от 1 до 4х символов.

Символы UTF-8 получаются из Unicode следующим образом:

Символы, в кодировке UTF-8, могут занимать до шести байт, но Unicode не определяет символов выше 0×10ffff, поэтому символы Unicode могут иметь максимальный размер в 4 байта в UTF-8.

Заключение

Вот собственно и всё что я хотела рассказать. Я считаю что очень интересно разбираться в том как работает компьютер, знать как хранятся в нём символы которые я набираю на клавиатуре, представлять насколько однобайтная кодировка например win-1251 (или utf-32 с фикс. длиной) работает быстрее со строковыми функциями и почему и т. п. Надеюсь статья вам понравилась.

Большое спасибо Википедии за возможность скопировать цитаты и таблицы, а то бы писала статью ещё месяц.

Все кто хочет узнать больше, также могут почитать про то в каком порядке записываются байты в кодировках UTF-16 и UTF-32 — в википедии тут и тут. А также что такое порядок байтов тут: Порядок_байтов. Также интересна будет статья Юникод_в_операционных_системах_Microsoft.

Всем JS-программистам и верстальщикам отдельно желаю чтоб заказчики не пользовались IE.

Текущая реализация, сейчас удовлетворяет главную задачу — автоматически сообщать вам, когда я отвечу на ваши комментарии. Однако имеется и ряд недостатков:

• Подписаться на рассылку комментариев можно только оставляя комментарий.
• Соответственно, подписаться можно только авторизуясь на сайте.
• Нет ссылки отписаться от рассылки, в тексте уведомления.
• Нет ссылки отписаться от рассылки на самом сайте.
• Нет списка новостей на комментарии к которым вы подписаны.

Прошу читателей блога помочь мне найти ещё недостатки текущей реализации и придумать что-нибудь полезное, связанное с комментированием новостей. На каких сайтах вам понравилась форма комментариев? Вы подписываетесь на комментарии к какой-то новости?

Спасибо.

1) После авторизации показывать пользователю окно с перенаправлением

Стремитесь проектировать взаимодействие с пользователем в 1-Клик. Для программиста это не очевидно, но каждое дополнительное открытие не нужного промежуточного окна увеличивает время достижения результата на 100% от идеального показателя.

Многие известные системы страдают этим. Насколько я помню у всех форумов phpBB до сих пор после авторизации идёт страница «Подождите, вы будете перенаправлены, если ваш браузер не поддерживает редиректы нажмите…  блаблабла». Не стоит даже обсуждать случай, когда браузер пользователя действительно не поддерживает meta-перенаправления, потому что тогда время его взаимодействия на данном действие возрастёт на 1000%. Замечу что плохи именно meta, а не http редиректы (301,302).

Обычно ошибка заключается в том что программист реализует функцию проверки авторизации используя переменные $_COOKIE, а проводит авторизацию используя функцию setcookie(), которая устанавливает куксу, но не устанавливает переменную. Или же проверка авторизации запускается после авторизации на странице.

Решение: принудительно устанавливать переменную $_COOKIE, а вызов функции авторизации подвинуть выше проверки на авторизацию.

2) После авторизации показывать главную страницу, или страницу профиля пользователя

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

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

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

Решение — использовать в этой функции http-переадресацию на страницу $_SERVER['HTTP_REFERER'], если она задана. Либо производить авторизацию на той же странице (т. е. на любой странице движка), используя в качестве action адреса формы авторизации — значение $_SERVER['REQUEST_URI'].

Замечу, что авторизация на отдельной странице /login/ и переадресация на нужную пользователю страницу, методом http-редиректа, является предпочтительной, т. к. в случае обновления страницы, браузер не спросит нужно ли посылать данные формы заново. Вы можете проверить это, войдя на сайт чтобы оставить комментарий к этой статье =).

3) При отсутствии авторизации перенаправлять на главную страницу

Это больше всего характерно для админ-панелей сайтов, и подобных закрытых систем. Очень часто, когда менеджер сайта заходит по ссылке /admin/items/edit_4999.html — он обнаруживает, что не авторизован на сайте. Адрес страницы часто бывает сложно запомнить, и система управления контентом должна приложить определённые усилия, чтобы менеджер никак не потерял этот адрес. Перенаправлять в данном случае не авторизовавшихся пользователей — не вежливо. Сайт который мы с коллегами улучшали сегодня — просто говорил о том что доступ запрещён, на нужной странице, и содержал ссылку на страницу с формой авторизации, что не многим лучше.

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

Решением для админ-панелей — является показ формы авторизации на странице требующей пароля. Так, чтобы пользователь попал куда надо в 1-клик.

4) Вызывать проверку авторизации в каждой функции

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

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

Решение — в одном месте будет гораздо проще отследить, какой функционал требует авторизации, а какой нет.

Заключение

Надеюсь статья поможет начинающим программистам сделать несколько улучшений их кода.

P. S. Кстати, слова «авторизироваться» в русском языке нет, правильно говорить «авторизоваться». Я считаю, что это эквивалентно словам «входить» и «войти». Правильно — «авторизовавшись», вместо «авторизировавшись».

P. P. S. Термин 1-клик можно увидеть в действие на сайте amazon.com, он был реализован Джеффом Безосом, основателем компании Amazon.com и его проэктировщиками. О проектировании подобных интерфейсов вы можете прочитать в книге Алана Купера «Психбольница в руках пациентов».

В предыдущем посте (Zend Guard пролетел…), коллега Bars задал вопрос, как быть если просят открыть код, до оплаты проекта, и как работать с западными заказчиками.

О геополитике

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

Сложнее обстоят дела на Украине, откуда судя по всему и пишет тов. Bars. Украинский внутренний рынок сайтостроительства вообще не насыщен, особенно по дизайнам (пруф. ищите ссылки на интервью А.Лебедева). Т. е. ситуация такая, что свой, украинский заказчик, не может платить столько, сколько платят на западе, например. Поэтому на Украине более развито направление работы с западными заказчиками. Работа на внутреннем рынке ведётся, но пока медленно. Украинские компании пока вообще не понимают, зачем им сайты. Билл Гейтс со своей книжкой «Бизнес со скоростью мысли» видимо уже 12 лет никак не попадёт на книжные лавки Киева. А жаль. Зато именно украинским дизайнерам мы обязаны такому обилию шаблонов на западных темплейт-стоках.

Совсем тяжко сейчас в Белоруссии (Беларуси). Батька запретил всё, что только можно. Знакомые минчане очень переживают. Все банковские транзакции перекрыты. Перевод валют не осуществляется. Даже банк «Москва-Минск» не совершает переводов Москва-Минск! О кризисе внутренней насыщенности белорусского рынка, можно понять, просто посмотрев на сайт того же банка — http://www.mmbank.by/. А потом, для сравнения, на не самый лучший сайт Банка Москвы http://www.bm.ru/.

В странах Европы, ситуация поздоровее. Люди работают и на внутренний и на западный рынок.

Как вести себя с заказчиками

Статьи с примерно таким заголовком вам нужно читать в больших количествах. Легко отличить хорошие статьи от плохих, но прочитать критически стоит почти все. Также полезно практиковаться в риторике и прикладной психологии. Но самое полезное — это завести себе крутого менеджера, если у вас его ещё нет. Если вы делаете сайт один — то менеджер должен просить никак не меньше 30–50% с заказа, или он просто не понимает своих задач.

Далее, что касается закрытости кода. Конечно можно его обфусцировать, но почти вся обфускация сводится к "$blablabla=blablabla; eval($blablabla);" т. е. эффективность ноль. Как правильно начал делать тов. Bars в своей статье — сайт нужно показывать на своём хостинге. И никуда его не устанавливать до тех пор пока вам не будет переведена вся сумма в полном объёме. Если заказчик из СНГ, и вообще производит впечатление приличного человека, можно пойти на уступки и заранее оговорить, что после демонстрации на своём хостинге он оплачивает 66% стоимости, тогда он будет уверен, что вы перенесёте сайт, а для вас остаток как раз и будет той платой за труды по переносу. Услуги по переносу желательно сразу включать в общую стоимость (и уточнить заказчику что это не 5 минут обычно, а больше). Хорошей практикой будет полностью оплачивать хостинг сайта (на пару недель), а потом передавать сайт прямо с этим хостингом — заказчик не будет нервничать, что-то сломается.

У нас не утопия. Если у заказчика будет большой соблазн кинуть — он кинет. Настройте себя на эту мысль. Достаточно один (иногда два =)) раза наступить на грабли кидания, чтобы понять, в какой момент передавать свой код. Код, который вы уже написали — больше всего нужен заказчику, а не вам. Если заказчик не хочет платить — не отдавайте код. Умный заказчик купит готовый продукт охотнее и дороже, чем будет ждать разработки с нуля. Потому что пара недель простоя его бизнеса стоит гораздо больше, чем ваша пара недель. Он может ругаться, но не может не заплатить. Иначе убытки будут у него, а не у вас. Это основная идея — запомните её и никаких проблем не будет.

Начну статью издалека, для тех кто не в курсе. Есть такая хитрая заокеанская компания Zend, известная тем что является разработчиком языка PHP, на основе своего Zend Engine. Сам язык PHP — проповедует обратную совместимость, т. е. код написанный для ранних версий языка запуститься и на более поздних, а версия для более поздней версии языка, де-юре, запуститься на языке с той же главной версией. Однако сам язык является интерпретируемым, т. е. не имеет возможности быть скомпилирован в запускаемое приложение. Что приводит, по сути, к тому, что весь код написанный на PHP — в какой-то степени открыт. Конечно компания Zend понимает, что многие компании захотят делать свой, написанный на PHP, коммерческий продукт закрытым, даже для владельца лицензии. В качестве какого-то решения, компания использует продукт под названием Zend Guard (и Zend Optimizer на серверной части). Суть продукта в том, что он может обфусцировать ваш скрипт, оптимизировать его и частично переводить в машинный код. Алгоритм обфускации и кодирования отличается у разных версий Zend Guard, но по сути вполне поддаётся декомпилированию. Статьи с примерами можно найти например в журнале Хакер, либо поискать на китайских форумах версию программы Dezender для требуемой версии.

Проблема в том, что обратная совместимость закодированного Guard’ом кода, была утрачена в версии PHP 5.3. Код скомпилированный последними версиями гварда должен быть скомпилирован для абсолютно конкретной версии PHP. В случае с последней версией 5.3 на сервер необходимо ставить обновлённый Zend Optimizer — сейчас он называется Zend Loader. Это привело к тому что сейчас в интернете повсеместно распространена версия 5.2, которая прекратила поддерживаться 16 декабря 2010 (пруфлинк). При этом уже спустя небольшое время в ней были найдены уязвимости и компания Zend была таки вынуждена выпустить обновление (пруфлинк). Знакомые владельцы крупных хостингов пока не знают как переносить клиентов на версию 5.3, которая поддерживается в настоящий момент, и выходит уже два года как. Некоторые хостеры ставят её только на новые сервера, только для новых клиентов.

Сам Zend Guard для версии PHP 5.2 работает довольно нестабильно. Он может от раза к разу по разному сжимать одинаковый код (даже если отключить обфускацию и оптимизирование), который может то читаться сервером, то нет. Один и тот же код может запускаться или нет в зависимости от малой версии PHP или даже операционной системы (бывали разные результаты на фёдоре, убунте и freebsd)!

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

Чего и вам желаем товарищи =).

Похвала

Всю похвалу файрфоксу попытаюсь уместить в начале статьи, чтобы не мешать критике, но и чтобы никуто вдруг не подумал что мне файрфокс не нравится. О том, как я люблю файрфокс я и так регулярно пишу в статьях (не сарказм): файрфокс для разработчика незаменим, несмотря на встроенную в Chrome панель разработчика, у файрфокса есть плагины без которых невозможно жить: Web-developer toolbar, Html validator, Adblock, удобный лог js-ошибок, и кстати веб-консоль для разработчиков тоже прикрутили (плагины пока всё равно лучше), гугл кстати предоставляет некоторый функционал консоли Хрома, как расширение к расширению Firebug. Т.е. Файрфокс это очень добротная бронемашина, на которую можно легко поставить как пулемёт, так и межконтинентальные ракеты, не говоря уже о тюнинге в виде поисковых плагинов, скинов, и легкой раскраски вместо них (Personas).

Файрфоксом я пользуюсь уже много лет, потому что когда я наконец поняла что IE совсем плох, были альтернативы только в виде глючной оперы и надстроек над IE, вроде MyIE. Поэтому я пересела на Netscape 7, с него на тяжеловесный mozilla suite, а затем собственно на отколовшийся от него phoenix, который потом переименовали в firebird и наконец в firefox. И до сих пор довольна им. В 4 версии он достаточно хорошо поддерживает CSS3 и HTML5, у очень многих свойств из css-transition убран префикс -moz который использовался ранее, на этом похвалы браузеру хочу закончить. И перейти к основной части статьи

Критика FF4

Баги в программах, как известно, можно исправлять бесконечно. В файрфокс 4 разработчики настолько устали от полуторогодовой разработки браузера, что чрезвычайно спешили выпустить уже хоть что-то релизное. Последние пару месяцев руководство мозиллы вообще запретило заниматься какими-то багами кроме имеющих статус Blocking. К релизу не пофиксили даже их - полторы сотни остались незакрытыми.

Самый показательный баг - регрессия производительности при отображении главной страницы дополнений - about:addons, там в ифрейме грузится внешняя страница с сайта addons.mozilla.org, скроллинг которой ужасно тормозит даже на топовых компьютерах (баги 623615, 626536, 625253). В результате пользователи Firefox 3 сменят окошко удобного, быстрого и понятного менеджера дополнений на страницу, которая, во-первых, тормозит, во-вторых, плохо отображается в скинах версии 3го файрфокс. Да, вся куча скинов оказалась несовместимой с новой версией, а найти что-то хорошее из текущего выбора очень сложно. Тем же кто принудительно использует старые скины придётся терпеть некрасивый addon manager и отсутствие бекграундов под модальными диалогами js (alert, confirm, prompt).

В программе также были сделаны очень неприятные изменения в плане usability о которых я уже писала - это убрана строка состояния, и объединены кнопки stop-reload. Впрочем это можно пофиксить дополнением status-4-evar и перестановкой кнопок на панели навигации.

Планы развития Firefox

Планы развития браузера можно почитать на странице Firefox/Roadmap - MozillaWiki. Главное что мозилла, наконец решила выпускать более частые релизы. Это очень здорово, если конечно не продиктовано стремлением набрать номер побольше, а то IE9, Chrome 10, Opera 11... Просто это позволит быстрее поддержку новых возможностей для сайтостроителей, сейчас мы до сих пор должны писать -moz-border-radius пока все пользователи не перейдут на FF4. Не знаю, насколько это удастся команде разработчиков, но nightly билд уже имеет номер 4.2a. Команда наконец принялась разгребать малозначительные баги, каждый день исправляется по 40-50 штук (на rss исправлений можно читать тут Firefox Daily, уже год как читаю).

Будет развиваться проект Electrolisys разделяющий задачи и сущности браузера, начальным этапом был out-of-process-plugin который вынес всё отображение плагинов, таких как flash, из основного процесса браузера. В конечном итоге разработчики стремятся выделить каждую вкладку в отдельный процесс. И заодно улучшить расход за распределением памяти в них. Я думаю это будет здорово, потому что у меня обычно открыто 20-30 вкладок, и почему-то через некоторое время нужды памяти файрфокса увеличиваются и он начинает кушать гигабайт и в попытках умерить аппетит начинает кушать процессорные ресурсы, приходиться его перезапускать. Также это будет положительно влиять на стабильность и безопасность вкладок.

Большая ставка также делается на мобильные устройства и социальность. Ну куда ж без них.

P.S.

Вот в целом всё что я хотела сказать о файрфоксе на текущий момент. Обычно друзья и коллеги просят меня написать меня о чём-то конкретном, или провести какое-то исследование. Из более чем сотни моих читателей обычно комментариев единицы. Но это конечно не останавливает меня раскрывать тут профессиональные секреты и делиться опытом =). Написание будущих статей вы можете ускорить, попросив в комментариях написать меня на какую-нибудь конкретную тему. Например это могут быть:

• микроформаты
• об использовании шрифтов на страницах
• zend guard
• Mercurial - система контроля версий
• Trac - багтрекинг система
• приоритет css селекторов

спасибо что читаете мой блог =)