День второй →

11:00 — Открытие: видеоприветствие Стива Балмера

Не знаю почему, но на эту важнейшую технологию обращают так мало внимания. Я хочу несколько исправить положение, поэтому это — первая статья в цикле «Кодогенерация». При рассмотрении данной темы будет использован язык PHP и БД MySQL, но кодогенерация сама по себе возможна на любом языке и с использованием любой БД, просто на PHP мне будет проще объяснять некоторые важные моменты. Так же я буду обращать внимание на состояние дел в других системах и языках.

Данная статья посвящена одному вопросу: какие проблемы присутствуют в современном программировании.

Web 2.0 победоносно шагает по виртуальному миру. Социальные сети растут как грибы после дождя. Теперь в одном месте вы можете хранить свои фото, видеозаписи, писать блоги и слушать музыку. Все это можно комментировать, класть в избранное, копировать… Возможностей много, контент социальных сетей разнородный и разнообразный, и в этом их преимущество.

А теперь представьте себе структуру БД какого нибудь «Вконтакте». Представили? И что вы видите? Множество таблиц с данными? А что еще? Множество таблиц для связей много-ко-многим! Необходимых, с точки зрения реляционной БД, но лишних с точки зрения логики. Но это еще не все. Среди полей таблиц мы видим огромное количество «лишних» полей, являющихся всего лишь внешними ключами, служащими для связей один-ко-много, так же необходимых с точки зрения реляционной теории, но абсолютно бесполезных с точки зрения логики.

Вчера в клубе «Бизнес в стиле .RU» прошла очередная встреча, на которой выступал Антон Мажирин из Free-lance.ru
Антон поделился своими оценками рынка фриланса в России. Так, по его мнению, 45% заказов для фрилансеров исходит от мелких студий, 40% от менеджеров компаний, 10% — крупных студий и 5% от менеджеров одиночек. Причем, по словам Антона, последние в ближайшие годы должны продемонстрировать бурный рост и составить вскорем 40%.Около 60% фрилансеров совмещают фриланс с постоянной работой, и только 35% занимаются исключительно фрилансом.
По подсчетам Антона, только 33% российских компаний не работают с фрилансерами, а остальные регулярно прибегают к их услугам. Такая цифра получилась из количественного сравнения зарегистрированных фирм на сайтах hh.ru и free-lance.ru Конечно, точные цифры отсюда получить невозможно, но можно оценить примерный порядок компаний, заинтересованных во фрилансерах.
Среди людей, которые ищут работу с помощью Интернета — только 6% фрилансеры. Но если взять в расчет, что далеко не все профессии совместимы с фрилансом, то по словам Антона эта цифра должна составлять около 40%.
Так же были затронуты вопросы преимуществ и недостатков фриланса как для работодателей, так и для самих фрилансеров. Немного поговорили о быстро ставшей популярной теме — coworking . По признанию Антона, он сам узнал о таком понятии только на прошедшем неделю назад РИФе. Хотя что-то подобное уже давно зреет у него в голове, как например возможность организации рабочего пространства для участников free-lance.ru.
Разумеется, было рассказано и об истории free-lance.ru. Что приятно удивило, так это то, что Антон свободно говорил о финансовой составляющей проекта. Так, ежемесячный бюджет проекта составляет примерно $20k, а месячный доход $30k. Так же сообщил, что по 20% купили hh.ru И DST за $1,1 млн. Капитализацию Антон оценивает в $3,5 млн.

Видеозапись встречи чуть позже можно будет скачать с hsetube.ru/archive

upd. Презентация Антона
upd2. Видео

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

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

• спусковые (большие вертикальные пропуски в первой полосе издания) и концевые пробелы полосы,
• абзацные отступы и концевые пробелы абзаца,
• межстрочные пробелы (между строками текста),
• межсловные пробелы (между словами в одной строке),
• межбуквенные пробелы (между буквами в слове).

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

Вторая часть моего доклада на конференции UA WEB про социальные сети. Тема части: перспективы развития социальных сетей.

Для пропустивших, советую сначала прочитать первую часть

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

 

Несколько статей и переводов по оптимизации (gzip для Apache, gzip для CSS- и JS-файлов, CSS-сжатие, JS-сжатие) уже затрагивали тему применения архивирования для уменьшения размера файлов, и, тем самым, увеличения скорости их передачи конечному пользователю. В данном исследовании я задался вопросом: а как динамическое gzip-сжатие влияет на быстродействие сервера? Рентабельно ли включать mod_gzip / mod_deflate для высоконагруженных проектов? И в каких случаях архивирование вообще лучше не использовать?

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

читать дальше на webo.in →

Позднее Статическое Связывание (Late Static Binding, LSB) является бурно темой обсуждений последние три года в кругах разработчиков PHP (и наконец мы его получили в PHP 5.3). Но зачем оно нужно? В данной статье, как раз и будет рассматриваться, как позднее статическое связывание может значительно упростить ваш код.

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

1) Какой бы ерундой вы не занимались с PHP, узкое место _всегда_ — БД. PHP — он как Буратино — тупОЙКАк… дрова. Lighttpd и Nginx позволяют разнести его по множеству физических серверов на раз без шума и пыли. Зарплата адекватного спеца по PHP в Москве — 30-45 тыс. рублей в месяц, стоимость аренды нормального сервера — от 3 тыс. рублей в месяц. А вы не знали ;)?

2) Какой бы ерундой вы не занимались — 30-60% производительности (возможно и больше) PHP-кода решит правильно выбранный и настроенный акселератор.

3) Серебряной пули нет. Не важно, какой концепт вы применяете — строгое ООП (в стиле Zend Framework), функции в стиле PHP4 (или ограниченное ООП) или вообще лапшу в стиле «PHP для чайников» — ни одна из этих парадигм не даст ощутимый прирост производительности, если конечно ваши программисты не выше как минимум на голову.

Примечание: ниже расположен перевод статьи «Inline Images with Data URLs», в которой рассматривается вопрос о внедрении картинки на веб-страницы при помощи data:URI. Эта схема позволяет вставить код картинок прямо в (X)HTML-страницу без обращений к внешним файлам, что уменьшает общее количество HTTP-обращений к серверу. Мои комментарии далее курсивом.

Встроенные (inline) изображения используют схему data:URI для внедрения прямо в тело веб-страницы. Как было определено в RFC 2397, такие URI предназначены для вставки небольших объектов как «непосредственные» данные. Такие объекты должны рассматриваться так же, как и любые другие внешние файлы. Использование встроенных изображений позволяет сэкономить HTTP-запросы к внешних ресурсах.

Поддержка браузерами data:URL

Хотя Opera 7.2+, Firefox, Safari, Netscape и Mozilla поддерживают data:URI, Internet Explorer 5–7 совсем нет. Однако, сообщается, что Internet Explorer 8 будет поддерживать эту схему, так как проходит Acid2 тест, что позволяет использовать data:URL как реальную альтернативу для внедрения небольших декоративных изображений. Существует также несколько приемов для поддержки старых версий Internet Explorer.

читать дальше на webo.in →

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

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

Отчего-то всегда хотел сделать свой сервис для загрузки файлов. Всевозможные slil/zalil не устраивали своей скоростью. ifolder — обилием рекламы. Пользовался не очень популярным (от этого он ни чуть хуже не становился) сервисом up.spbland.ru. Но это как-то не правильно. И тут я решил написать свой сервис. Не буду вдаваться в подробности и рутину, только концепция.

Примечание: ниже перевод статьи «JavaScript optimization, are chained calls expensive?». В ней автор тестирует, насколько медленнее производятся цепочки вызовов функций по сравнению с их кешированными аналогами. В конце приведены результаты моих тестов производительности.

Sree Kotay в своем блоге оставил небольшую заметку о JavaScript. (Если вас интересуют технические подробности, я рекомендую ознакомиться с презентацией Simon Willison «A (Re)-Introduction to JavaScript».) В своем блоге Sree пишет следующее:

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

for (i=0; i < 100; i++) a.b.c.d(v);

… ЗНАЧИТЕЛЬНО медленнее, по крайней мере, в JavaScript, чем:

var f=a.b.c.d;
for (i=0; i < 100; i++) f(v);

… потому что, в конце концов, JS — это динамический язык. Я предоставлю несколько более конкретных советов для JavaScript и тестов производительности, которые прояснят эту ситуацию.

читать дальше на webo.in →

Наверняка большинство программистов, работающих с современными веб-фрейворками, реализующими схему MVC, сталкивалось с таким небольшим затруднением: кэширование фрагмента View.

Хорошие фреймворки предлагают инструменты для полного кэширования страниц, фрагментарного, или кэширования экшенов. Недавно я посмотрел 90 выпуск подкаста Railscasts, посвященный именно фрагментарному кэшированию в Ruby on Rails и уважаемый автор решал проблему, как мне показалось, неоптимально.

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

markItUp! это «легкий» редактор для jQuery. Это не WYSIWYG редактор и никогда им не будет. Вся «соль» этого редактора в том, что можно настроить его для использования с любыми средствами подсветки. BBCode, Markdown, Wiki синтаксис, Textile и конечно же HTML.

Особенности:
— Легкая интеграция
— Поддержка «горячих» клавиш
— Панель управления легко настраивается
— Легко изменяется и настраивается
— Просмотр результатов через AJAX
— Настраиваемый внешний вид

Примеры использования
Домашняя страница

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

Примечание: ниже приведен перевод статьи «Replace GIF with PNG Images» о том, в каких случаях стоит использовать PNG-формат вместо GIF. Мои комментарии далее курсивом.

Введение

Переносимый сетевой графический формат (Portable Network Graphics, PNG) разрабатывается как более эффективная, гибкая и свободная от патентов замена GIF-формату. PNG был задуман для хранения отдельных растровых изображений для дальнейшего распространения по компьютерным сетям (1). PNG был создан в 1995 в ответ на давление со стороны Unisys и их патента на алгоритм LZW-сжатия, используемый в GIF. Хотя срок действия патента Unisys уже закончился, причины на переход от GIF к PNG остались, практически, прежними (2). Заменив ваши GIF-изображения теми же самыми, но в формате PNG, вы можете ускорить загрузку ваших страниц и сэкономить трафик ваших пользователей.

PNG против GIF: алгоритмы сжатия

PNG использует алгоритм deflate-сжатия обычно с 32Кб скользящим (sliding) окном. Deflate является улучшенной версией алгоритма сжатия Lempel-Ziv (LZ77), который используется в ZIP- и GZIP-файлах (3, 4). Созданный Phil Katz для второй версии PKZip, deflate совмещает LZ77 с кодированием Huffman и является от 10% до 30% более эффективным, чем LZW при сжатии без потери информации. Так же, как и GZIP, некоторые инструменты по PNG-сжатию предполагают опциональный параметр «степень сжатия», которая варьируется от 1 до 9. По умолчанию выставляется 6. 9 является практически всегда лучшим выбором для максимального сжатия.

Не удивительно, что изображения, сохраненные как PNG, обычно от 10% до 30% меньше, чем GIF, хотя в некоторых редких случаях они могут быть больше по размеру (5, 6). В нашем тестировании мы обнаружили, что часть картинок могут быть сжаты от 40% до 50% или даже больше (до 85% для одного примера), в зависимости от изображения. По большей части изображения с большими однотонными областями сжимаются лучше, чем градиентные с большим количеством переходов между цветами.

читать дальше на webo.in →

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

Мы также не будем касаться вопросов проверки смысловой точности цитирования, правильного использования купюр, сокращений и дополнений — всех интересующихся ждёт «Справочник издателя и автора» А. Э. Мильчина и Л. К. Чельцовой.

Надеемся, что эту запись будет удобно использовать как справочник по часто встречающимся вопросам оформления цитат.