Программисты с Etsy.com поделились опытом, как им удалось эффективно решить задачу по пакетному ресайзингу фотографий с 1,5 МБ до 3 КБ (после смены дизайна оказалось, что старые превью-окошки не вписываются в новые шаблоны страниц). Задача не такая банальная, как кажется. Дело в том, что Etsy.com — крупный интернет-аукцион, и количество изображений различных товаров превышает 135 млн штук.

Ради шутки они прикинули, сколько займёт эта работа вручную в «Фотошопе». Если на каждую фотографию отдать по 40 секунд, то выходит 170 лет непрерывного труда. Затем они начали считать, можно ли отдать пакет в облако EC2 и во сколько это встанет. Посмотрев на получившуюся сумму, программисты решили поискать другой способ.

В итоге им удалось завершить обработку 135 млн фотографий всего за 9 дней, задействуя четыре 16-ядерных сервера. Средняя скорость обработки составила 180 изображений в секунду.

Перевод статьи Sara Golemon «Extension Writing Part I: Introduction to PHP and Zend».

Существует цепочка в мозгу: мы напишем юнит тесты, затем эти тесты нам расскажут если мы что-то сломали, затем они нам почту будут отправлять о том, что проект поломался.
Это ничто иное, как иллюстрация непрерывной интеграции (Continious Integration) нычне крайне модного направления гибкой разработки. Единственный недостающий элемент цепочки — «КАК». Ниже коротенький рецепт, как бы отвечающий «очень просто».

Большинство разработчиков на MySQL знакомы с командой EXPLAIN, однако значительно меньше людей знают о команде EXPLAIN EXTENDED, появившуюся ещё в MySQL 4.1, и ещё меньше умеют ею пользоваться.

EXPLAIN EXTENDED умеет показывать, что же конкретно делает с Вашим запросом оптимизатор MySQL. Для разработчика может быть совсем не очевидно, насколько сильно может отличаться написанный им запрос от того, который в действительности будет выполнен сервером. Этот процесс называется механизмом перезаписи запросов (query-rewrite), и он является частью любого хорошего SQL-оптимизатора. Команда EXPLAIN EXTENDED добавляет дополнительные предупреждения (warnings) к выводу команды EXPLAIN, в том числе и переписанный SQL-запрос.

Привет, разработчики на хабре!

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

1. Не проставляйте ключи!

СУБД пишут умные люди. Некоторые из них даже получают за это деньги. Зачем подсказывать им, как устроены данные? Пускай догадываются сами из названий полей и самих данных. В крайнем случае, админы поправят профайлером.

Эта статья — продолжение статьи «Каким надо быть руководителем? Секреты профессии.»

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

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

Ситуация 1. Перфекционист. Один из партнеров пригласил помочь с проектом внедрения системы сбалансированных показателей в государственной компании. При анализе проекта выяснилось, что в данный момент в проекте написано ТЗ (очень объемное), сделана часть разработок. Но! весь бюджет проекта уже «съеден» на этапе написания ТЗ. А чтобы закончить проект в срок нужно еще два месяца работ и привлечение дополнительных внешних специалистов на почасовой оплате. Руководитель проекта со стороны исполнителя сам писал ТЗ, финансами проекта «не интересовался», задержку сроков связывал с тем что «плохо работать не буду, моя репутация пострадает», вся ситуация оказалась для него неприятной неожиданностью, идей по путям выхода из ситуации сам руководитель проекта предложить не мог.

Скажу сразу — «Америку не открываю», так же как не «изобретаю велосипед». Статья базируется на модели ситуационного лидерства Херси-Бланчарда. Сама модель в значительной степени изменена в применении к управлению именно ИТ-командами в нашей стране и подкреплена практическим опытом управления командами в Майкрософт Рус и в собственном бизнесе.

Выбирая между «академическим» и «популярным» стилями изложения выбрал «академический». Все таки разговор о серьезных вещах. Так что если эта тема Вам прямо сейчас не супер-актуальна — смотрите диаграммы, их достаточно для понимания идеи. Остальное — для достаточно узкой аудитории.

...Skype — это дьявольски хитрая программа, написанная бесспорно талантливыми людьми..._{Крис Касперски}

Доброго времени суток!

Skype сейчас я встречаю чаще на компьютерах чем другие IM клиенты, мне он практически заменил icq, вся рабочая переписка ведется в skype, но речь пойдет не о том, что лучше или популярней. Часто бывает так, что участвуешь сразу в нескольких чатах где количество участников превышает 10, что собственно и приводит к тому, что на рабочем столе и в трее постоянно обновляется количество новых сообщений, а также уведомления в виде всплывающих сообщений, а теперь представьте что у вас 3 окна чата с друзьями, 1 с вашим боссом, другой с девушкой — все это в сумме начинает запутывать, отвлекать и порой раздражать. Хотелось бы расставить приоритеты…

Раньше я чаще всего настраивал «политику» уведомлений только через глобальные настройки программы
Случилось так, что я узнал, что в каждом окне чата skype возможно использование команд, например /alertsoff отключит уведомления для конкретного окна чата, соответственно /alertson включит их обратно.
Поискав немного я наткнулся на некое how-to, оказывается у skype чата довольно много текстовых команд, подобие IRC команд. Далее я постарался попробовать все возможные из них на двух имеющихся у меня платформах, как оказалось не все и не везде работает… Прошу под кат.

Какой главный инструмент работы айтишника? Компьютер? Я думаю иначе. Прежде всего мы работаем головой. А как работает мозг? Почему-то об этом нам не рассказывают в школе, университете и на работе, или рассказывают очень мало. Чтобы работать эффективно, нужно не только уметь прекрасно пользоваться необходимым программным обеспечением, но и знать, как настроить свой мозг на работу.

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

В данной статье я проведу краткий экскурс в наиболее распространенные средства, связанные с безопасностью Linux. Информация предоставлена в сжатом виде, и если какое-то средство вас заинтересует, можно пройтись по ссылкам и прочитать более подробно. По заявкам пользователей некоторые механизмы можно будет рассмотреть более подробно в последующих статьях.

Будут рассмотрены следующие средства: POSIX ACL, sudo, chroot, PAM, SELinux, AppArmor, PolicyKit. Виртуализация, хотя и относится в какой-то мере к средствам безопасности, рассматриваться не будет, тем более что это отдельная обширная тема.

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

Год 2010 получается довольно занятой в целом, весна случилась урожайная на конференции в частности. Поэтому писать в блог на Хабр регулярно получается плохо, но как минимум пачкой новостей и ссылок хочется поделиться (уже пора!). Краткая сводка —

1. с начала года прошло 3 конференции (Confoo, MySQL UC, RIT++) с докладами про Сфинкс, доступны слайды;
2. в течение месяца предстоит еще 2 (DORS/CLUC, DevConf), где запланированы доклады и (внимание, нечто новое) мастерклассы про все тот же Сфинкс;
3. полтора месяца назад запустили (англоязычный) блог, пытаемся регулярно писать интересное туда, пока даже получается (сам очень удивляюсь);
4. RT апдейты дозрели до публичного релиза настолько, что релиз задерживают не они; SVN версия местами крутится в продакшне, и даже почти что не падает (удивляюсь еще сильнее);
5. самозародились плагины для WordPress, Zend Framework (не наши).

Подробности под катом!

От переводчика

Хотелось бы поделиться переводом сказки (или даже басни), написанной Джеральдом Уинбергом, автором известной книги «Психология программирования». Сказка повествует о неприятных последствиях «вырезания» тестирования из процесса разработки ПО.
Несмотря на то, что контекст, в котором сказка подает процесс «готовки-разработки» довольно утопичен (знаем, что, когда и как), сама мысль, лежащая в её основе, универсальна и близка многим, работавшим в компьютерной индустрии. К тому же форма, в которой она подана, весьма ненавязчива и оригинальна.
Приятного чтения.

Мы уже пол года успешно используем Redis в своих highload проектах. За это время было выработано много удачных решений на Redis для задач, с которыми сталкиваются разработчики большинства крупных проектов. Примерами этих решений я и хотел бы поделиться на предстоящей DEVCONF, чтобы на практике показать возможности, преимущества и слабые стороны Redis.

Когда БД проекта вырастает за пределы трех-пяти таблиц, продолжая при этом постоянно изменяться, на свет рождаются неудобства обмена изменениями между разработчиками. Проблема стара как мир, но инструмента удовлетворяющего мои требования я в ноябре 2009го найти не сумел.

Мои требования к инструменту очень просты:

• Как бы я не издевался над структурой данных в приложении, инструмент должен уметь изменить структуру в другой инсталляции приложения так, чтобы она была идентична моей.
• System requirements: PHP и MySQL — не более того.
• Бесплатность.
• Открытость.

Предисловие переводчика
Эта статья продолжает серию переводов официальной документации по PHPUnit на русский язык.
Часть 1, Часть 2, Часть 3,

Данная заметка не предназначена для начинающих изучать регулярные выражения, для начинающих я бы посоветовал книгу Ben Forta "Teach Yourself Regular Expressions in 10 Minutes" (ISBN: 0-672-32566-7).

Для тестирования и отладки регулярных выражений идеально подходит программа RegexBuddy (http://www.regexbuddy.com). Чтобы отлаживать следующие примеры нужно во вкладку Test скопировать HTML какой-либо страницы или вбить несколько тегов самим.

Задача — найти в HTML все теги IMG и вытащить из тегов значения атрибутов SRC и ALT.

Полностью автоматизированный инструмент проверки безопасности ваших веб приложений от Google. Основные возможности:

высочайшая скорость: написан на C, оптимизированные HTTP запросы, минимальные требования к CPU — скорость запросов легко достигает 2000 в секунду.

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

отличная логика безопасности: высокое качество работы, различные способы проверки безопасности.

Поддерживаются операционные системы — Linux, FreeBSD, MacOS X и Windows (требуется Cygwin).

Google skipfish

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

Звучит несложно, правильно?

У читателя предполагается наличие опыта компиляции программ и работы в Линуксе. Небольшое умение читать ассемблерный код тоже пригодится.

Предисловие переводчика:
Недавно начал изучать PHPUnit (framework семейства xUnit) и с удивлением обнаружил, что на русском языке нет статей про автоматические тесты для самых-самых чайников.
В первой главе документации по PHPUnit на примерах очень доступно рассказывается, что такое автоматическое тестирование.


Даже хорошие программисты допускают ошибки. Разница между хорошим программистом и плохим заключается в том, что хороший программист как можно чаще использует тесты, чтобы найти свои ошибки.
Чем раньше Вы начнете тестировать, тем выше Ваши шансы найти ошибку, и тем ниже цена исправления.
Это объясняет, почему откладывание тестирования до момента передачи программы заказчику является очень плохой практикой. Большинство ошибок так и не будет найдено, а цена исправления станет такой высокой, что Вам придется составить большой график работы, т.к. сразу Вы не сможете их все исправить.