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

Статья является расширенным сборником CSS-хаков в сравнении с аналогичной статьей.
Под хаком подразумевается метод, позволяющий воспринимать CSS только определенному браузеру.
Хаки могут использоваться не только для исправления багов в верстке, но и в случае использования определенных особенностей браузера для ускорения рендеринга web-страницы в нём (к примеру CSS3-свойства)

В одном из моих проектов мне понадобился простой javascript календарь. Но из существующих jQuery плагинов, только один «почти» соответствовал мои требованиям. Решил написать свой плагин — проба пера calendarLite plugin.

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

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

Вступление

Забавно, но когда программист разрабатывает какой-либо продукт, он редко задумывается над вопросом могут ли на одну кнопку в один момент времени нажать одновременно 2000 человек. А зря. Оказывается могут. Как ни странно но большинство движков, написанных такими программистами, очень плохо ведут себя под большими нагрузками. Кто бы подумал, а всего один лишний INSERT, не проставленный index, или кривая рекурсивная функция могут поднять load averages чуть ли не на порядок.

В этой статье я опишу как мы, разработчики проекта, сумели выжать из одного сервера с Pentium 4 HT / 512Mb RAM, максимум, держа одновременно 700+ пользователей на форуме и 120,000 на трекере. Да, проект этот — торрент трекер. Предлагаю сразу оставить в стороне разговоры о копирайтах и правах, мне это не интересно, что действительно интересно — это HighLoad.

Однажды вечером я почувствовал, что пришло время расширить 97‐ й параграф «Ководства» Артемия Лебедева.

На клавиатуре одна чёрточка, она обычно правее нуля и повыше букв «З» и «Х». Неосведомлённые люди называют её попеременно то дефисом, то минусом, то тире. Лебедев объясняет нам, что это четыре (учитывая две разновидности тире) различных символа. На самом деле их как минимум девять, и об этом я и расскажу вам сейчас.

Один из стандартных вопросов, который задает (или по идее должна задавать) веб-студия на первой встрече с клиентом – зачем вам нужен сайт? Зачастую клиент с готовностью отвечает «нам нужен сайт как инструмент». Но, как показывает опыт, иногда это примерно то же самое, что прийти в магазин и купить дрель, чтобы была. Чтобы в доме был инструмент.

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

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

Давайте рассмотрим постановку задачи на примере.

Психологи утверждают, что молодой, энергичный и амбициозный человек (а других вряд ли станут рассматривать на должность менеджера проекта) “выдерживает” на одном рабочем месте не более 5-6 лет. А для некоторых психологических типов этот срок составляет 2-3 года. Практический опыт чаще всего подтверждает эту позицию. Далее менеджеру проектов требуются новые перспективы, причем далеко не только финансовые.

Переход менеджера на новую работу — серьезный поступок, требующий взвешенного решения и тщательной подготовки. Ведь, как правило, есть что терять на том месте, где вы уже работаете. Одновременно, на новом месте всегда ждет риск. Работа менеджера проекта сродни работе футбольного тренера. Так же как и в футболе, в провале проекта будет виноват его менеджер, какими бы “объективными” ни были обстоятельства поражения. Обстоятельства надо изучать заранее и обсуждать их со своим, пока еще будущим руководством.

Главное что надо понять, прежде чем согласиться заняться проектом, это что от вас хотят и что вы сможете сделать. Понять все на 100% вряд ли удастся, но разобраться необходимо. В конце концов, представляя объем работы, легче торговаться изза зарплаты и бонусов. Предлагаю свой список, “Абсолютный минимум” шагов, которые надо предпринять до того, как сказать “да” и выйти на работу в новую команду. Ответьте “да” или “нет” на следующие вопросы:

1. Представляете ли вы себе структуру компании?
2. Знаете ли кому будете подчиняться и с кем будете взаимодействовать внутри компании?
3. Одинаково ли понимаете с вашим будущим руководством роль менеджера проекта?
4. Видит ли ваше будущее руководство перспективы ваших проектов через год?
5. Владеете ли вы методами и инструментами управления проектами, которые применяются в компании?
6. Знаете ли вы как принято документировать проект в компании?
7. Для каждого порученного вам проекта существует документация?
8. Для каждого порученного вам проекта существует план работ?
9. Существует ли отдел контроля качества?
10. Ознакомились ли вы со списком ошибок по вашим проектам в системе багтрекинга?
11. Ознакомились ли вы с резюме каждого участника вашей будущей команды?
12. Знакомы ли вы с лидером вашей команды?
13. Ознакомились ли вы со списком требований к проектам?
14. Ознакомились ли вы с общей архитектурой каждого из ваших будущих проектов?
15. Знаете ли вы заказчика вашего проекта?
16. Существует ли представитель заказчика?
17. Знаете ли вы кто был предыдущим менеджером проекта?
18. Знаете ли вы кто должен передать вам дела по проектам?

Список получился длинным, но я скорее соглашусь добавить еще пунктов, чем что то выкинуть. На все вопросы можно ответить “да” или “нет” и подсчитать количество положительных ответов. Сколько вам нужно положительных ответов чтобы согласиться на новые проекты — выбирайте сами. Тут многое зависит от индивидуального темперамента и от предлагаемой компенсации. Да много еще от чего зависит.
Чтобы ответить на все вопросы, надо серьезно поработать и изрядно потратить времени. Не всегда это время есть, особенно когда на переговоры приходится ездить в другой город. Если вы получите утвердительный ответ на все 18 вопросов, вы имеете отличные шансы на успех. Вопросы 2,3, 13, 15, 16 являются наиболее критичными, и, в случае отрицательного ответа хотя бы на один из них, надо очень осторожно давать согласие на новую работу. В этом случае вы исключительно рискуете.

Удачного старта!

Примечание: статья посвящена обзору проблемы неработающей кнопки «назад» в браузере при использовании AJAX-методов для передачи содержания страниц от сервера к клиенту. В статье рассматриваются основные принципы работы AJAX и возможные пути решения заявленной проблемы. Курсивом даны мои комментарии.

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

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

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

Представление (VIEW) — объект базы данных, являющийся результатом выполнения запроса к базе данных, определенного с помощью оператора SELECT, в момент обращения к представлению.

Представления иногда называют «виртуальными таблицами». Такое название связано с тем, что представление доступно для пользователя как таблица, но само оно не содержит данных, а извлекает их из таблиц в момент обращения к нему. Если данные изменены в базовой таблице, то пользователь получит актуальные данные при обращении к представлению, использующему данную таблицу; кэширования результатов выборки из таблицы при работе представлений не производится. При этом, механизм кэширования запросов (query cache) работает на уровне запросов пользователя безотносительно к тому, обращается ли пользователь к таблицам или представлениям.

Под катом замечательное видео от VFS об азах типографики, в очень интересной форме.

Мучения со стандартным подходом применения CSS спрайтов, а именно трудности модернизации и в некоторых случаях сложности оптимальной компоновки заставили искать альтернативный вариант оптимизации загрузки изображений. Очередной раз почитывая хабра-статьи, наткнулся на интересный подход реализации спрайтов с применением data:URI. В ходе дискуссий и умозаключений были определены слабые и сильные стороны данного подхода. Одним из значительных недостатков нового подхода является сложность сборки конечного CSS. Однако, при использовании data:URI имеет место возможность автоматизации процесса.

Многие программисты оптимизируют JavaScript и CSS-код, чтобы страница грузилась быстрее.
Но не все они делают прелоадеры, которые дают пользователю эффект субъективно более быстрой загрузки.

7 марта прошлого года W3C, после 10-летнего перерыва, возобновила работу над HTML.

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

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

Я решил выложить их в виде статьи, переработав и снабдив иллюстрациями и примечаниями.

Содержание:

1. Вступление
2. Сценарии гибели
   • Гибель ментальная, или HTML — новый ассемблер
   • Гибель физическая, или HTML — новый Turbo Pascal
3. Все ли так серьезно?
   • Ментальной гибели не будет, если web-технологии будут правильно поняты
   • Физической гибели не будет, если web-технологии будут развиваться
4. Заключение
5. Примечания

В настоящий момент мир вступает в эпоху расцвета богатых web-приложений.

Программы, работающие через Веб, все больше вытесняют традиционные десктопные приложения. Gmail, Google Map, online-офис, даже web-операционные системы… Список можете продолжить сами.

Однако, по мере продвижения web-приложений, все больше возрастают требования к основным клиентским web-технологиям: xHTML, CSS, JavaScript.

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

Когда во сне снится «ой а если сервера не хватит...»

Для начала, Доброй Ночи. Пишу что-то полезное вроде впервые (если не считать разного рода полу-тестов в моём блоге). Человек я допытливый до жути, неожиданно в голову пришло, что могу помочь сэкономить кому-то много времени ;).

Рано или поздно многие крупные проекты сталкиваются с проблемами производительности при постраничной навигации по записям. Некоторые из них решают эту проблему ограничением количества доступных для просмотра записей (скажем, не больше 1000). Вполне приемлемое решение. Но в этом случаем могут возникнуть проблемы с индексированием сайта сторонними поисковиками, которые и представляют наибольшую угрозу. В этой статье я хотел бы отказаться от привычной для всех панели навигации вида «1..2..3..4..» в пользу простой «вперед… назад» (будет проще объяснить), но это не проблема реализовать подобное и с первым вариантом.
Более точно определить тему, назвав, какое количество записей считать достаточно большим для появления тормозов, не получится, так как эта цифра для всех разная и сильно зависит от того, насколько быстрые у Вас жесткие диски, сколько памяти, и какая часть Ваших данных уже закеширована в ней и тд. Но если Вы и Ваши сервера ощущают, что n-ная страница при выводе даётся тяжелее первой, и при этом не знаете, что с этим делать – статья для Вас. Но для начала, я хотел бы на пальцах объяснить, почему ОНО работает медленно.

Кстати, тест происходит на виртуальной машинке, работаю я с СУБД под рутом, версия MySQL – 5.0.32.

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