Задача

Задача такая же как и в предыдущей статье, только применимо к MySQL.

Грабли

Хорошая новость ребята! В MySQL нет проблемы с рекурсивными триггерами! Разработчики MySQL просто тупо лочат изменяемую таблицу даже на уровне триггера, вот редиски. Но, собственно, нас может остановить только отключение электричества.
Есть небольшая лазейка, с… объединенными таблицами. Хотя я не нашел в документации подтверждения того, что это так специально было задумано, но и отрицания тоже не было. Правда есть вероятность того, что эту лазейку могут прикрыть, хотя я не вижу в этом смысла.
Увы, механизм триггеров в MySQL новый и довольно сырой, что накладывает некоторые ограничения на его использование, но все же его достаточно для решения нашей задачи.

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

Простые конструкции в языке Python: ветвления и циклы имеют свои особенности по сравнению с другими языками. Поэтому я всё же решил потратить на это время и рассказать. Материал совсем простой!
Так же по просьбам читающих добавил в конец статьи разбор простой программки для наглядной демонстрации пройденного материала.

Предыстория

Присоединяюсь к MaxElc, DarwinTenk и Devgru :) Начинаю цикл статей посвященных Python. Сам я имею некоторый опыт обращения с PHP и Java. Но каждый раз, при относительном освоении какого-то инструмента — оставалось определённое неудовлетворение им, связанное с чем-то конкретным, и поиски продолжались. На сегодняшний день наиболее близко к идеалу в моих глазах стоит Python. Идеал недостижим — это понятно, посему и у Python есть недостатки. Прежде всего — это скорость выполнения, однако, эта проблема решаема несколькими путями и об этом мы обязательно поговорим чуть позднее.
Сам я начал осваивать Python буквально недавно. Начиная этот цикл статей — я преследую несколько целей. Во-первых, это дополнительная само мотивация + интерактивность, во-вторых, опыт. В-третьих, блуждая по просторам рунета — вижу, что Python куда менее популярен, чем в мире. Ситуацию надо исправлять :)
В соответствии с идеологией Python, а именно с тем, что одни из главных его козырей — это быстрота в освоении и скорость разработки, мы достаточно быстро, практически тезисно пронесёмся по основам синтаксиса и построения программ и перейдём к основной цели данного цикла — освоение django.
Итак, мы начинаем.

Каждый раз, когда мне говорят «о! новый хромиум стал еще быстре, а новая опера — еще мелодичнее», в ответ я задаю простой вопрос: «А в вашем браузере есть telnet-сервер? А вот в firefox — есть», — после чего адепты других религий понимают, что пропаганда бесполезна.

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

Ага, вот эти ребята, сейчас я покажу Вам магию ООП.

Попробуем сделать при помощи Flex простое приложение. Впрочем, это не будет обычный Hello World, это будет нечто более полезное.
Но перед тем, как попробовать сделать что-нибудь с помощью Flex, разберемся, какие возможности появились в новой версии.

Зачем может понадобиться писать демоны на PHP?

• Выполнение трудоемких фоновых задач;
• выполнение задач, которые длятся больше, чем время ожидания при HTTP-запросе (30 секунд);
• выполнение задач на более высоком уровне доступа, чем серверный процесс (читай — под рутом).

Представьте себе абстрактный разговор абстрактного заказчика с абстрактным верстальщиком.

— У тебя бага в менюшке, все наверх съехало, — говорит заказчик.
— Посмотрел во всех браузерах, нету! Ты в каком смотришь? — говорит верстальщик.
— В фаерфоксе.
— Нормально все там, — говорит верстальщик, просмотрев сайт во всех версиях фаерфокса.
— Осталось бага. Если это важно, то я с мака.

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

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

После ряда статей на тему минимизации размера файлов и распределения их по нескольким хостам у меня возник вопрос: какое оптимальное соотношение между числом (или размером) «встроенных» и внешних файлов? Какая часть страницы должна загружаться вместе с основным HTML-файлом, а какая — только с внешними файлами? Для решения этих и ряда других вопросов я собрал тестовое окружение в виде одной странице, для которой применены различные оптимизационные техники (заодно и посмотрел, как реально все эти техники влияют на скорость загрузки страницы).

Шаг первый: простая страница

Начал я с обычной страницы, для которой использовалось только gzip-сжатие HTML-файла. Это самое простое, что может быть сделано для оптимизации страницы (на самом деле, причиной было то, что мне не хотелось специально отключать сжатие для одного хоста, а потом его включать обратно :). Данная страница бралась за основу, с которой сравнивалось все остальное.

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

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

Как определить, что сайт сверстан качественно?
Есть много статей о том, как делать хорошо, но совсем нет – о том, как делать не надо, ведь даже валидный и кроссбраузерный сайт может быть сверстан отвратительно.

Из этой статьи вы узнаете:

• О плохих приемах современной верстки;
• О том, как даже не будучи профессионалом, за 5 минут определить плохо ли сверстан сайт или нет.

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

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

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

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

Примечание: ниже перевод статьи «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 →

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

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

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

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

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

Перевод заметки "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 вместо регулярных выражений.

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