Недавно, у меня случилась проблема с GD на сервере — он перестал понимать png, после получаса мытарств, решил посмотреть на ImageMagick и его PHP интерфейс IMagick
После недолгого гугления нашел замечательный блог посвященный Imagick. Там же нашел способ делать красивые превьюшки. Однако, способ, предложенный там, правильно отрабатывал только с png картинками. Я немного поковырялся и сделал свой.
Статья посвящена системе личных сообщений, но только в новом формате, который, по моему скромному мнению, больше подходит под систему ценностей «web 2.0».
Больше ничего не скажу, хоть пытайте!
Я хочу рассказать вам две истории: веселую и грустную. Очень много лет, месяцев, недель и дней меня не посещали идеи. Вообще никакие. Даже самые глупые.
Веселая история заключается в том, что в мою голову наконец-то пришла хоть какая-то идея, и я этому рад. Я радовался целый год. И даже больше!
Плохая новость заключается в том, что за год я ничего не сделал с этой прекрасной идеей, никому ее не рассказал, и никому не показал. Как ни печально, но это факт.
Шутки — шутками, а потехе — час! Сегодня я расскажу вам все самое сокровенное, а внимательный читатель, чем черт не шутит, вынесет из этого повествования что-нибудь полезное.
Серия постов про “Web, кэширование и memcached” продолжается. В первом и втором постах мы поговорили о memcached, его архитектуре, возможном применении, выборе ключа кэширования и кластеризации memcached.
Сегодня речь пойдет о:
атомарных операциях в memcached;
реализации счетчиков просмотров и онлайнеров.
Следующий пост будет посвящен проблеме одновременного перестроения кэшей.
Серия постов под общим заглавием “Web, кэширование и memcached” продолжается. В первом мы поговорили о memcached, его архитектуре и возможном применении.
Сегодня речь пойдет о:
выборе ключа кэширования;
кластеризации memcached и алгоритмах распределения ключей.
Следующий пост будет посвящен атомарности операций и счетчикам в memcached.
Этим постом хочу открыть небольшую серию постов по материалам доклада на HighLoad++-2008. Впоследствии весь текст будет опубликован в виде одной большой PDF-ки.
Введение
Для начала, о названии серии постов: посты будут и о кэшировании в Web’е (в высоконагруженных Web-проектах), и о применении memcached для кэширования, и о других применениях memcached в Web-проектах. То есть все три составляющие названия в различных комбинациях будут освещены в этой серии постов.
Решил продолжить цикл заметок по данной тематике. В данной статье особое место хотел уделить профайлингу MySQL запросов. Описать средства, которые предоставляются MySQL для профайлинга, и что нужно делать для определения узких мест запроса.
Также, после опубликования первых двух статей я получил пару отзывов и вопросов, связанных с проектированием БД / расстановкой индексов / составлением запросов. На многие вопросы старался отвечать. С некоторыми из них поделюсь и в этой статье.
Я точно не могу сказать, что заставило написать этот пост — может быть мой накопившийся опыт и принадлежность к php-программистам, которые, всемирно известны своим быдлокодом или недавний пост, в котором автор описывает проблему, появившуюся в его велосипеде и связанную с глобальными переменными в различных модулях.
Почитав комментарии к которому, мне стало уж совсем плохо… Я просто не понимал как люди не видят сути проблемы, а видят только лишь ее последствия — проблему в велосипеде. А суть то заключается в том, что у автора напрочь отсутствуют какие-либо познания в «велосипедостроении». И что самое страшное — эти знания отсутствуют не у одного него. А практически у всей массы изобретателей которые сами велосипеды видели только на картинках.
А если взять в расчет то, что они не хотят даже посмотреть на другие велосипеды…
Пообещал вчера написать статью о реальных случаях оптимизации БД MySQL.
Пришлось сегодня вставать утром пораньше чтобы воплотить обещанное в жизнь.
Централизованное управление мыслями поддерживать еще сложно, поэтому не судите строго за казусы и ляпсусы в моей статье.
В последнее время приходится достаточно часто заниматься оптимизацией производительности сайтов. И как правило «бутылочным горлышком» в производительности работы этих сайтов является именно БД, ошибки как в архитектуре так и в выполнении запросов. Начиная от неправильной расстановки индексов, либо совершенным их отсутствием, неправильным (неэкономным) выбором типов данных под определенное поле, заканчивая абсолютно нелогичной архитектурой БД и такими же нелогичными запросами.
В данной статье опишу несколько приемов, которые были использованы для приложения с 4млн+ пользователей и которое имея порядка 100млн+ хитов в сутки, а в конце опишу задачу, которая решалась недавно и может быть многоуважаемое сообщество предложит мне решения этой задачи более эффективное нежели то, к которому пришел я.
В данной статье я немного вернусь к вышеописанному и опишу пару примеров, с которыми столкнулся на проекте недавно, после этого приведу еще пару небольших примеров относительно того что такое хорошо и что такое плохо в MySQL.
Доброго времени суток.
Это мой первый серьезный пост на Хабре, так что критика приветствуется.
Сегодня я расскажу о написании плагина для JavaScript-библиотеки MooTools на примере модального всплывающего окна.
Обычно для работы с mySQL я использовал «phpmyadmin», но сегодня мой взор был направлен на новое решение «SQL buddy», я скачал, загрузил на свой сервер, и…
И это просто супер! Такой и должна быть удобная работа с БД!
Возможно «SQL buddy» не имеет столько расширенных функций как «phpmyadmin», но для рутинных и небольших работ она прекрасно подходит.
Я большой любитель собирать списки разных необходимых вещей. В этот раз это список видео-проигрывателей на флэше, жаль, но получилось всего 3 проигрывателя получилось 7 проигрывателей.
Надеюсь уважаемые комментаторы помогут дополнить список и выявить абсолютного лидера среди проигрывателей.
Уже помогли. Отдельные спасибы Elected, atri, rmb. Кармы всем за мой счет ^_^
При подгонке сайтов до единого вида во всех браузерах, верстальщик использует не один css хак.
Но зачем обычному пользователю с IE получать избыток кода для других браузеров firefox, opera, safari?!
Это проблема легко решается с помощью динамического css.
В PHP5.2 для работы с датой/временем появились классы DateTime и DateTimeZone. Вначале на них не обратил внимание, так как привык пользоваться функциями date(), etc. Но потом решил все-таки посмотреть какие возможности реализуют новые классы.
В последнее время столкнулся с тем, что Prototype не такая уж клевая библиотека. Даже в компрессии напару с scriptaculous занимают много места да и синтаксис странный. Для меня загадка, почему в Rails включили именно его. jQuery по синтаксису намного больше похож на Ruby и более легковесная библиотека. Собственно немного порыскал и нашел неплохие шпаргалки на jQuery, чтоб освоение протекало несколько легче.
Представьте себе абстрактный разговор абстрактного заказчика с абстрактным верстальщиком.
— У тебя бага в менюшке, все наверх съехало, — говорит заказчик.
— Посмотрел во всех браузерах, нету! Ты в каком смотришь? — говорит верстальщик.
— В фаерфоксе.
— Нормально все там, — говорит верстальщик, просмотрев сайт во всех версиях фаерфокса.
— Осталось бага. Если это важно, то я с мака.
