Предисловие

Давно хотел написать. Мысли есть, желание есть, времени нету… Но вот нашлось, так что привет, Хабра.
Здесь я собрал все идеи, которые помогали и помогают в разработке веб-приложений. Для удобства я разбил их на группы:

1. Память
2. Оптимизация операций
3. Выделение критических участков
4. Циклы и объектные свойства
5. Немножко о DOM
6. DocumentFragment как промежуточный буфер
7. О преобразованиях в объекты
8. Разбитие кода
9. События перетаскивания
10. Другие советы

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

Память

Хоть это и не должно волновать клиентского программиста, но не забываем, что память всё-таки не бесконечна и когда-нибудь может закончиться, например, когда запущено несколько массивных программ: офис, графический редактор, компиляция большой программы и др. Несмотря на то, что приведенный пример тривиален, у меня действительно такое случилось, хоть и не из-за браузера, но он тоже сыграл свою роль: 1,3 Гб оперативы (отладчик, около 30 вкладок), начались тормоза по перегрузке страниц ОП в файл подкачки.
Чтобы уменьшить расход памяти, я предлагаю несколько способов:

CSS3 видели и пробовали все, кого он мог заинтересовать. И закругленные уголки и падающие тени мы уже можем генерировать без лишнего труда.

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

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

Браузеры, поддерживающие свойства перечислены в виде CSS комментариев. Генераторы и инструменты чаще всего могут выполнять сразу несколько функций, поэтому в таких случаях я указывал их только там, где они, по-моему, справляются лучше всего.

Как-то давно я уже писал об этом, но немного скудно и сумбурно. После я решил расширить список инструментов в обзоре, добавить статье структуры, учесть критику (большое спасибо Lefty за советы) и отправил ее на конкурс на СекЛаб (и опубликовал ссылку, но по всем понятным причинам ее никто не увидел). Конкурс закончен, результаты объявили и я с чистой совестью могу ее (статью) опубликовать на Хабре.

Бесплатные инструменты пентестера веб-приложений

В данной статье я расскажу о наиболее популярных инструментах для пентестинга (тестов на проникновение) веб-приложений по стратегии «черного ящика».
Для этого мы рассмотрим утилиты, которые помогут в данном виде тестирования. Рассмотрим следующие категории продуктов:

1. Сетевые сканеры
2. Сканеры брешей в веб-скриптах
3. Эксплойтинг
4. Автомазация инъекций
5. Дебаггеры (снифферы, локальные прокси и т.п.)

Новый справочный сайт HTML5Please может сильно помочь при разработке кросс-браузерных сайтов на HTML5.

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

HTML5Please идёт дальше. Кроме информации c caniuse.com, он ещё даёт практические рекомендации, каким образом лучше реализовать каждую фичу HTML и CSS. Просто вписываете в поисковую строку любую функцию — и сразу видите рекомендацию, можно её использовать или нет в данный момент, а если можно, то с какими условиями.

Если функция поддерживается не во всех браузерах, то сразу же приведены ссылки на соответствующие полифилы (polyfills), кросс-браузерные фрагменты кода обычно на github, которые добавляют недостающий функционал в старые браузеры (см. список полифилов). Если для функции нужен фоллбэк (откат на другую функцию или другой формат для совместимости), то вкратце описывается, как это сделать и в каких условиях это необходимо.

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

Часто стоит задача, ограничить возможность ввода букв в поле input. Во многих источниках предлагают это сделать следующим способом, навесить обработчик события keyup, со следующим кодом:

return ((event.keyCode>47)&&(event.keyCode<58))

Этот метод обладает рядом недостатков, к примеру также пользователь не сможет вводить цифры numpad, в опере не будут работать клавиши tab,up,left и т. д.
Как же сделать правильно?

Мне очень понравилась книга The Lean Startup, написанная Eric Ries. Я советовал ее прочитать всем авторам стартапов. Правда, оказалось, что не всех хватает сил прочитать 300 страниц достаточно плотного английского текста. Поэтому я решил пересказать на русском языке наиболее важные части из этой книги.

Начинается же книга с простого вопроса: «Почему стартапы умирают?»

Команда стартапа создает новый продукт в обстановке полной неопределенности. Никто еще точно не знает, кто же их реальные пользователи и каким на самом деле должен быть продукт. Как и любым бизнесом, веб­‐проектом нужно управлять. Каждым стартапом кто‐то как-то управляет, но большинство проектов погибает. Почему?

Первая проблема – безоговорочное доверие хорошему бизнес-плану, четкой стратегии и обширными маркетинговым исследованиям. В не такие уж и давние времена бизнес-планы, стратегии и исследования были хорошей заявкой на успех большинства бизнес-начинаний. Искушение внедрить аналогичный подход к планированию работы и в стартапы огромно, но в стартапах такой подход, увы, не работает, так как стартапы существуют в условиях слишком большой неопределенности. Планировать можно что-то имеющее отношение к реальности только в
том случае, если основываться на длительной и стабильной бизнес-­‐истории и условия относительно статичного рынка. У стартапов нет истории, и растут они в окружении, которое меняется с необычайной быстротой.

Есть у меня серверок (да, да, именно серверок, сервером его назвать сложно). Железо старенькое (2 гига оперативы, AMD Athlon(tm) 64 Processor 3500+, програмный RAID). Админю я его сам, без особых навыков и познаний. Когда-то давным давно (больше года назад) поставил на него Debian 5.0 Lenny (это была вторая в жизни установка linux-системы, до этого ставил только Ubuntu на рабочий ноутбук) и панель управления ISPConfig3 по мануалу. Держу на нем несколько (штук 40) сайтов друзей и клиентов, Redmine, SVN и еще немного по мелочам.
Периодически все это безобразие падает (load average > 20), и приходится на сервере раз в пару часов перегружать apache или высасывать из пальца очередную попытку оптимизации. В общем полный раздрай и разруха. И вот в одну прекрасную субботу я подумал — а почему бы не решить вопрос раз и… И вот в общем.
Под катом — история убитых выходных + предыстория. Интересна в первую очередь мне, чтобы потом легко вспомнить что именно и зачем я ставил. Может быть интересна новичкам в интересном и нелегком (ох, ...) деле серверной оптимизации постепенным(!) переводом сайтов из-под Apache c его ModRewrite под Nginx (кстати, правильно это слово читается «энжинкс»меня поправили, Сысоев на конференциях не раз говорил, что название сервера стоит читать, как «энжин-икс», спасибо bayandin и DorBer ). Возможно, будет интересна более-менее опытным товарищам, оказавшимся в тех же условиях (Debian Lenny, ISPConfig3, слабое железо, несколько хороших, не сильно хороших и разных сайтов). И более опытным может быть интересно зайти, оставить пару комментариев.

Большинство литературы посвященной паттернам в ООП (объектно-ориентированном программировании), как правило, объясняются на примерах с самим кодом. И это правильный подход, так как паттерны ООП уже по-умолчанию предназначаются для людей, которые знают что такое программирование и суть ООП. Однако порой требуется заинтересовать этой темой людей, которые в этом совершенно ничего не понимают, например «не-программистов» или же просто начинающих «компьютерщиков». Именно с этой целью и был подготовлен данный материал, который призван объяснить человеку любого уровня знаний, что такое паттерн ООП и, возможно, привлечет в ряды программистов новых «адептов», ведь программирование это на самом деле очень интересно.
Статья предназначена исключительно для новичков, так что «старожилы» ничего нового для себя не узнают. В основном статья описывает известные паттерны из книги «Приемы объектно-ориентированного программирования. Шаблоны проектирования.», но более популярным и простым языком.

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

Множество удобных инструментов, найденных командой популярного онлайн журнала SmashingMagazine, приводится под катом

В своей практике консультанта я чего только не встречал. Вот недавно у меня состоялся интересный разговор с одним приятелем. Он управляет проектами по развитию сети банкоматов в крупном российском банке. Тематика мне близка, сам сделал таких проектов немало, разговор получился довольно интересным, и основные выводы я решил запостить тут. Надо сказать, что приятель мой, как и многие менеджеры проектов, прошел почти классический для России путь: специалист в небольшой компании -> менеджер проектов в этой же небольшой компании -> переход на менеджерскую позицию в крупную компанию. Это нормальная эволюция – годы ученичества сменяются желанием порулить чем-нибудь масштабным. И именно при переходе в большую компанию поджидает менеджера проектов масса сюрпризов. Если же управлять приходится внутренними проектами, сюрпризов будет еще больше.

Как только в мире рождается новый проект, у него сразу появляются друзья и враги. Объясняется это очень просто: любой проект влечет за собой изменения. Ну а люди на перемены реагируют по-разному – кто-то к ним готов и горячо приветствует, а кто-то перемен не любит и боится, потому что видит в них угрозу для своего статуса, образа жизни, стабильности или, что еще хуже, появление у себя дополнительной работы. И первые, и вторые могут оказаться в числе людей, способных повлиять на ход и результат проекта.

Так уж получилось, что последние пару лет я много работаю с кризисными проектами. Это проекты, в которых деньги потрачены, цели не достигнуты, все сроки много раз нарушены, менеджера уволили или он сам в ужасе сбежал, а уровень мотивации команды – ниже некуда. В общем, материализовавшийся fuck up. К сожалению, большинство таких проектов нельзя просто закрыть – все они важны для заказчика.

Я не люблю CSS. Он простой и понятный. Это движущая сила Интернета, но он слишком ограниченный и им трудно управлять. Пришло время привести этот язык в порядок и сделать его более полезным, используя динамический CSS при помощи LESS.
Объясню свою позицию на примере. Почему бы вместо использования #FF9F94 для получения темно-персикового цвета просто не хранить значение этого цвета в переменной для её последующего использования? Что бы перекрасить сайт достаточно будет изменить значение переменной всего в одном месте и всё.
Другими словами: это будет очень изящно, если мы будем использовать немного программирования и логики в CSS, что бы сделать его более мощным инструментом. Хорошо, что это всё возможно с использованием LESS.

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

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

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

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

Всем привет!
Процесс обработки ошибок в Yii был для меня не совсем прозрачным с первых дней использования этого фреймворка. Даже несмотря на наличие в документации специального раздела Error Handling. В каких случаях какие view используются, как влияет ajax или debug-режим, зачем нужен errorAction, в чем отличия при обработке исключений?
В итоге после копания в документации и исходном коде фреймворка я нарисовал наглядную схему обработки ошибок, которая лично для меня оказалась весьма полезной и наверняка пригодится кому-то еще.
Под катом собственно схема и некоторые комментарии к ней.

Совсем недавно вышла первая beta php 5.4, а пока я писал топик подоспела и вторая. Одно из нововведений в 5.4 – это traits (типажи). Предлагаю разобраться во всех деталях в том, что же типажи из себя представляют в php.

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

//определение типажа
trait Pprint 
{
    public function whoAmI()
    {
        return get_class($this) . ': ' . (string) $this;
    }
}

class Human 
{
    use Pprint; //подключаем типаж, ключевое слово use

    protected $_name = 'unknown';
    
    public function __construct($name)
    {
        $this->_name = $name;
    }

    public function __toString()
    {
        return (string) $this->_name;
    }   
}

$a = new Human('Nikita');
echo $a->whoAmI(), PHP_EOL; //=> Human: Nikita

Как видно, к классу Human было добавлено поведение из типажа Pprint.

Но во всём есть свои детали.

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

Этот дайджест основан на моем приличном опыте мониторинга и анализа сайтов на рынке веб-разработок (исследования конкурентов в ADV, мониторинг и анализ участников «Тэглайн», проведение заказных аудитов для студий и пр.).

Я попытался систематизировать основные «ляпы» и упущения по нескольким основным категориям, на которых и остановлюсь подробнее:

• Ошибки позиционирования;
• Ошибки расстановки приоритетов;
• Неправильная презентация компании и услуг;
• Неправильная презентация портфолио и кейсов;
• Ошибки в коммуникации с заказчиком;

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

Сервисы опросов
userreport.com (добавил Romanych)
simpoll.ru
webanketa.com (добавил mihass)

Кнопки постинга в социальные сети
Кнопка от Яндекса
addthis.com (добавил UksusoFF)
share42.com