Вы, наверное, уже слышали о grid вычислениях (решетчатые вычисления), особенно если следите за развитием всяких высокопроизводительных систем — сейчас это считается самой интересной и перспективной технологией, коммерческие рельсы которой закладывает компания Oracle, впервые выводя это в бизнес-среду. В основном же такие вычислительные фермы (или гриды, этот термин пошёл от энергосети и по сути означает, что вычисления не только распределены в пространстве, но и доступны с любой точки в необходимом количестве, как и электрическая энергия). используются для научных расчётов, визуализации сложных сцен и других высокоёмких расчётов. Кстати, не думайте, что это удел только сверхсекретных лабораторий и больших корпоративных заказчиков. Отнюдь! Используя только open-source ПО вы сами можете построить свою собственную небольшую вычислительную grid-сеть и использовать таким образом объединённые ресурсы для своих нужд. Например, это может пригодится в учебных заведениях для объединения парка компьютеров различных классов в одну сеть для проведения научных расчётов (ведь у образования зачастую нет средств на суперкомпьютеры, а если и есть, то все равно задачи перед учёными всегда требуют на порядок больше вычислительной мощи, чем есть).

Понадобилась тут такая «штука», как TrackBar только с двумя ползунками, готового решения на jQuery не нашел, решил писать самостоятельно, правда не на jQuery а на чистом JS. Вроде от этого хуже не стало. «Штука» эта нужна была для выбора числовых значений в формах информационного киоска.

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

Речь идёт о системе мониторинга Hyperic HQ, которая предназначена для обеспечения постоянного и полного контроля за всей ИТ-инфраструктурой. Она может применяться и в дата-центрах, и хостинговых компаниях, для слежения за собственными серверами внутри компании, для стартапов где нужна и важна максимальная доступность и оперативное реагирование на возникшие проблемы.

Мне было интересно почитать, наверняка кому-то тоже пригодится.

• Как организованы кластеры Google
  www.slideshare.net/ultradvorka/google-cluster-innards
  
  Как строить дизайн системы с тэгами на Mysql, а также как
  проектировать базу MySQL с Master/Slave, чтобы распределять нагрузка
  на узлы веб-фермы (от майсиквелиста) — с примерами SQL
  www.slideshare.net/jonathanbaij/building-a-tag-system-with-mysql
  
  Как оптимизировать вызовы Javascript/AJAX на сайтах (от гуглиста)
  www.slideshare.net/souders/web-20-expo-even-faster-web-sites
  
  Как организован DIGG (PHP + MYSQL)
  www.slideshare.net/epee/mysql-2007-tech-at-digg-v3
  
  Как оптимизировали Fotolog (самое большое сообщество по фото
  блоггингу) MySQL, JAVA, PHP, Memcached, дизайн БД
  www.slideshare.net/frankmashraqi/fotolog-scaling-the-worlds-largest-photo-blogging-community
  
  Как оптимизировать БД MySQL
  www.slideshare.net/techdude/how-to-kill-mysql-performance
  
  Как организован Flickr (PHP, PEAR, ImageMagic, Perl, Java, XML)
  www.slideshare.net/coolpics/flickr-44054
  
  

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

Это может быть help, справочная информация, быстрая навигация по админ-панели, древовидное меню и т.д. Пользователю такая организация навигации понятна, так как она реализивана во всех операционных системах.

Поиск хороших решений неприменно приводил к красиво оформленным и хорошо документированыи коммерческим библиотекам, например Zapatec Tree. За unlimited версию там просит 799$.

Дорого! Будем поддерживать разработчиков свободного ПО и искать хорошо написанное дерево на JavaScript.

Если вы разработчик AJAX приложений или интерфейсов, то вам это окажется полезным. Если приходится хранить некоторые достаточно обьемные данные в структурированном виде на стороне клиента, то каким образом это оптимально сделать? Конечно, вам могут помочь обычные массивы (тип данных или, скорее, встроенный обьект Array), и он даже предоставит базовые функции для управления массивом данных и основные операции над ним, но это очень, скажем так, низкоуровневое решение, часть функционала может зависеть от реализации JS-движка в конкретном браузере. Кроме этого, что-то делать с сохраненными данными нужно писать достаточно много собственного кода, и в конце концов ваш код превращается в такое нагромождение вызовов, функций и переменных, что разобраться в этом ой как сложно.

Да, выход из этого есть. В частности, самым лучшим решением (в теории) является использовать специальных плагинов для расширения функциональности браузера, для примера, в Google Gears встроена полноценная СУБД (SQLite), и вы получаете в свое распоряжение все ее возможности прямо в JavaScript коде (самое ценное, по моему, кроме хранения большого обьема данных, является полнотекстовый поиск). Аналогичные инструменты можно встретить в спецификации HTML 5, да и в последних версиях Mozilla Firefox будет встроена база данных в качестве клиентского стораджа, в среде Adobe AIR также используется встроенная база SQLite. Но что делать, если все эти радости по какой-либо причине недоступны либо их использование ограничено, а удобное хранение и работа с данными нужно иметь уже здесь и сейчас, и без дополнительных надстроек. Выход, конечно же есть!

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

Основы масштабирования

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

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

Наверняка пост под названием 80+ Smashingmagazine AJAX-Solutions For Professional Coding у многих в закладках. Эта подборка включает в себя самые новые на, то время, и вкусные решения с применением Ajax, собранные со всего мира.
И вот, почти год спустя новая подборка новых вкусных решений — 60 More AJAX — and Javascript Solutions For Professional Coding. Многие скрипты уже знакомы, но есть и замечательные новинки.

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

Музыка, Медиа

Лэйблы убьет не пиратство, а сам Интернет — музыкантам и слушателям больше не нужен посредник. Более того, артист больше будет не решать, сколько он возьмёт за альбом, записанный один раз, 10 лет назад. Ему придётся играть концерты, придумывать что-то новое.

Образование

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

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

Приветствую всех читателей. Популярность AJAX такая, что это, по сути, уже стандарт де-факто для многих проектов. Хотя, как и все технологии (особенно, новые и/или модные), она часто применяется (чего уж грех таить) и там, где без нее не обойтись, и там, где вполне можно, а зачастую и нужно. Впрочем, сегодня речь пойдет о другом.

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

Но все же – допустим, у нас есть простенький, но претенциозный веб-сайт визитка, где по переходам меню AJAX подгружает и выводит контент, а мы хотим дать знакомому по ICQ ссылку на контактную страницу (или любую другую, не суть важно).

Есть два подхода решения проблемы ссылок.

Когда-то давно видел подобное действо на хабре ( спасибо elfiki за линк habrahabr.ru/blog/la_france/24341.html ), но, недавно, пришлось столкнуться с этим самому. Старое решение мне не понравилось количеством javascript, решил попробовать реализовать, по возможности, с минимальным JS. Пара просмотренных воркэраундов не подошла, так как задать размер в пикселях для input file мне не удалось (если это вообще реально), а даже при фиксированном шрифте в разных браузерах «пиксели», почему-то, «разные» получились. Особенно ИЕ удивил, уместив в DIV размером 400px два дива размером по 200 и еще половину третьего.

в итоге получилось примерно такое решение:



Итого, мое доработанное, может кому пригодится.

Позднее Статическое Связывание (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 для чайников» — ни одна из этих парадигм не даст ощутимый прирост производительности, если конечно ваши программисты не выше как минимум на голову.

Пару лет назад я занимался проблемой data URL в Internet Explorer, добился определённых результатов, но то, что получилось, использовать было невозможно. Data URL (иногда его ещё называют «протокол data:») — возможность вставлять ресурсы (графику, CSS, JavaScript и так далее) в HTML код.


Подробнее о data URL можно узнать из свежей статьи на «Хабре» «Картинки в теле страницы с помощью data:URL». Хотелось только её дополнить двумя замечаниями: IE8b1 поддерживает data URL длиной не более 32Кб, в современных версиях других браузеров ограничений увидеть не удалось, Safari/Opera/FF показали изображения размером около 700Кб.


Теперь амбула.


Вчера ночью мне пришла в голову идея как можно попытаться корректно совместить data URL и включение картинок через протокол mhtml. То, что у меня не получилось два года назад, получилось сейчас.


Результат — готовый код на PHP из двух функций. Первую функцию («bolk_data_uri_header») нужно вызвать в самом начале перед выводом любого вашего кода, вторую («bolk_data_uri») собственно для включения картинки в код.


Надеюсь на примерах всё понятно:

bolk_data_uri_header();
bolk_data_uri('myjpeg.jpg');
bolk_data_uri('ourpng.png', 'border: 2px dotted red');

Код самой библиотеки:

function bolk_data_uri_header() 
{ 
    echo "<!--\n" 
        ."Content-Type: multipart/related; boundary=\"=_NextPart_01C6A9B1.539AB070\"\n\n" 
        ."--=_NextPart_01C6A9B1.539AB070\n" 
        ."Content-Transfer-Encoding: base64\n" 
        ."Content-Type: text/html\n" 
        ."-->\n\n"; 

} 

function bolk_data_uri($file, $style = '') 
{ 
    if (!( file_exists($file) && ($data = @getimagesize($file)) )) return false; 

    $name = uniqid('', true); 

    if ($style <> '') $style = ' style="'.htmlspecialchars($style).'"'; 
    $mime = strpos($_SERVER['HTTP_USER_AGENT'], 'Gecko') ? " type='{$data['mime']}" : '';

    echo "<!--\n" 
        ."--=_NextPart_01C6A9B1.539AB070\n" 
        ."Content-Location: {$name}\n" 
        ."Content-Transfer-Encoding: base64\n" 
        ."Content-Type: {$data['mime']}; -->\n" 
        ."<object data='data:{$data['mime']};base64,\n\n"; 

    echo base64_encode(file_get_contents($file)); 

    echo "' {$data[3]}{$style}{$mime}'><img " 
        ."src='mhtml:http://{$_SERVER['HTTP_HOST']}"
        ."{$_SERVER['REQUEST_URI']}!{$name}' {$data[3]}{$style} /></object>\n\n" 
        ."<!--\n" 
        ."--=_NextPart_01C6A9B1.539AB070-->"; 

    return true; 
}

Секрет в совмещении данных, чтобы IE, обратившись к странице по протоколу mhtml нашёл нужный кусор, «спрятанный» внутри тега, а остальные браузеры увидели бы картинку через data URL.


Код тестировался под Opera 9.50b, FF 2.0.0.13, Safari 3.1 и IE6. Предложения и результаты испытаний — прошу в комментарии.


Оригинал записи опубликован в моём блоге.

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

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

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

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

Всем доброго времени суток.

Перевод заметки "40 Tips for optimizing your php code". Автор — Reinhold Weber.

1. Если метод может быть статическим, объявляйте его статическим.
2. echo быстрее, чем print.
3. Передавайте в echo несколько параметров, вместо того, чтобы использовать конкатенацию строк.
4. Устанавливайте максимальное количество проходов ваших циклов for до цикла, а не во время его выполнения.
5. Удаляйте свои переменные для освобождения памяти, тем более, если это большие массивы.
6. Остерегайтесь магических методов, таких как __set, __get, __autoload.
7. require_once дорого обходится.
8. Указывайте полные пути в конструкциях include/require, меньше времени будет тратится на поиск файла.
9. Если вам необходимо определить время, когда скрипт был запущен, используйте $_SERVER[’REQUEST_TIME’] вместо time().
10. Старайтесь использовать strncasecmp, strpbrk и stripos вместо регулярных выражений.

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

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

Эта инструкция научит Вас, как создавать очень красивые и удобные текстовые кнопки (с эффектом нажатия), используя CSS.