Хочу поделиться рецептом, как совместить php-скрипт и почтовый сервер Postfix для автоматической обработки входящей почты.

С помощью такой связки мы собираем статистику по количеству возвратов bounce-писем:Undelivered Mail Returned to Sender.

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

Ошибки в обработке ошибок являются наиболее распространенным источником ошибок

Бредня, пришедшая в голову при написании этой статьи

Основные баталии по поводу того, что лучше использовать при программировании на C# – исключения или коды возврата для обработки, ушли в далекое прошлое (*), но до сих пор не утихают баталии другого рода: да, хорошо, мы остановились на обработке исключений, но как же нам их обрабатывать «правильно»?

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

Существует множество «за» и «против» такого способа перехвата и обработки исключений, но сегодня я хочу рассмотреть несколько другую тему. А именно тему обеспечения согласованного состояния приложения в свете возникновения исключения – три уровня безопасности исключений.

По просьбе tulskiy делаю вольный перевод частей официальной документации GitHub'а Fork A Repo и Send pull requests.

Итак, что же такое «запрос на включение (сделанных вами изменений)» (именно так я перевёл pull request)? В официальной документации гитхаба говорится следующее:

Pull request'ы позволяют вам рассказать другим о тех изменениях, которые вы разместили в своём GitHub-репозитории. Как только pull request отправлен, заинтересованные стороны рассматривают ваши изменения, обсуждают возможные правки или даже добавляют дополняющие коммиты, если нужно.

Говоря своим языком: Посылая pull request, вы говорите автору изначального репозитория (и всем заинтересованным лицам): «Смотрите, что я сделал, не хотите ли принять мои изменения и влить их в проект?»

Для любого программного приложения, предназначенного для массового обслуживания пользователей, необходимо проводить нагрузочное тестирование на предмет его надежности и отказоустойчивости. А так как любой web-сайт — это по своей сути система массового обслуживания, то проверка его на отказоустойчивость всегда является неотъемлемой частью разработки. Существуют различные решения для проведения нагрузочного тестирования веб-приложений. Я не буду сейчас описывать их подробно, про некоторые из них есть упоминания здесь.

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

Для тех кто ни разу не использовал JMeter, рекомендую для начала почитать базовые обзоры, например, Простой нагрузочный тест с Apache JMeter. Когда я первый раз запустил данную программу, первая мысль была разобраться во всем методом «тыка», но как выяснилось это вообще нереально, и метод «тыка» неприменим к JMeter. Поэтому если хотите его использовать, то сразу открывайте мануал, поверьте, вам придется заглядывать туда очень часто, пока полностью не разберетесь, что и как. Я же здесь сейчас опишу самое очевидное и важное, а именно: как собственно создавать нагрузочные тесты. Если бы я в свое время сразу нашел подобную статью, то сэкономил бы без малого день на изучении этой софтины.

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

1. Выучить новый язык программирования

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

Среди языков программирования отличный познавательный эффект и наверстывание опыта дают: Lisp (или Scheme), Форт, PostScript или Factor (стековые языки программирования), Haskell (строго типизированный, чистый функциональный язык) либо OCaml (объектно-ориентированный язык функционального программирования), Пролог (логическое программирование), Erlang (отличные паралельные вычисления).

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

Все мы прекрасно понимаем, что тестирование является неотъемлемой частью жизненного цикла разработки ПО. Чем чаще мы тестируем наш код, тем быстрее мы сможем обнаружить ошибку, вкравшуюся в него в ходе разработки, и быстрее её исправить. При этом стоит понимать, что тестирование крайне желательно проводить в окружении, максимально близком к боевому (ОС, ПО, Hardware, Нагрузка), что бы иметь возможность обнаружить ошибки, которые не проявляются на сервере разработки, но могут появиться в бою. Компануя два вышесказанных тезиса вместе мы получаем концепцию, называемую Continuous Integration.

Суть CI заключается в постоянной (например, после каждого commit'а) сборке и тестировании разрабатываемого ПО в максимально приближенной к боевой среде с целью как можно более раннего обнаружения ошибок и оповещения о них разработчиков. Сама идея CI принадлежит Martin Fowler, подробно описавшему её в своей статье.

Для автоматизации процесса непрерывной сборки существуют готовые решения (Hudson, CruiseControl), интеграцию одного из которых (Hudson) я и опишу в этой статье.

Несколько дней назад мы с TheShock создали топик в котором собирали ваши вопросы, касательно JavaScript (архитектура, фрэймворки, проблемы). Настало время ответить на них. Мы получили очень много вопросов, как в комментариях так и по email. Эта первая часть ответов — те вопросы, которые достались мне.

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

В статье описывается способ разделения логики и реализации логики в ant-скриптах, примененный для решения одной практической задаче по рефакторингу большого проекта в SVN-репозитории.

Предыстория

Имеется проект в SVN из 15 000 файлов и 5 000 папок. Проекту почти 10 лет, на нем поработало несколько поколений разработчиков разной квалификации. В какой-то момент, пару-тройку лет назад, а может и раньше, архитектура проекта «потекла». Разные модули и слои стали писаться в разных стандартах организации кода, возникли циклические зависимости между модулями. В итоге в SVN за долгие года образовалась свалка. Проект собирается, но совершенно шаманским способом.

Задача

Привести код к единому формату хранения. При этом сохранить историю изменений по каждому файлу и не останавливать процесс разработки.

Сложности

Сохранить историю по одному файлу или папке в SVN довольно просто с помощью команды svn copy. При небольшом количестве файлов все можно сделать вручную.
С разбором большого проекта сложно. Пока будешь вручную разбирать 15 000 файлов, разработчики накоммитят новых изменений и их тоже нужно будет копировать. Замкнутый круг.
Нужна автоматизация. Скриптик, который раз! — и переводит проект в новую структуру.

Результат

Задача была выполнена, а побочным продуктом стал подход к написанию ANT-скриптов, который в большом программировании называется инкапсуляция. Хочу поделиться полученным подходом.

(Это первая статья из серии статей, посвященных обзору различных тестов браузеров.)

Что такое Acid3? Кто его придумал? Как он устроен и как он работает? Что он измеряет на самом деле? Этими и другими вопросами мы зададимся в данной статье и попробуем найти ответы.

Что такое Acid3?

Acid3 — это третий из серии специальных тестов (до этого были Acid1 и Acid2), написанных «в помощь производителям браузеров, чтобы те могли проверить поддержку стандартов в своих продуктах». Конкретно ACID3 нацелен на тестирование спецификаций, связаных с разработкой динамичных «Web 2.0»-приложений.



Acid3 включает 100 специальных тестов, проверяющих 19 различных спецификаций.

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

(Это вторая статья из серии статей, посвященных обзору различных тестов браузеров. Ранее в серии: Погружение в ACID3.)

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



В простонародье это зовется пузомерками, а как метко подметили примерно год назад в Lenta.ru (см. ниже) — «у кого HTML5 длинее».

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

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

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

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

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

Однако, всем категориям веб-разработчиков, равно как и их клиентам, полезно иметь не обременяющие средства для кроссбраузерного тестирования.

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

Классикой жанра для решения поставленной задачи является веб-сервис:

Универсальный, но долгий browsershots.org

Он позволяет получить скриншот не только из конкретного браузера, но и выбрать его версию и ОС, в которой браузер запущен.

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

Эта статья посвящена программированию GUI на базе фреймворка Qt от Nokia. Мы рассмотрим способы разработки интерфейсов для нативного отображения на платформах Windows, Linux и Mac OS X.

Презентацию^[1] вёл Йенс Бач-Вииг (Jens Bache-Wiig) — разработчик Qt (с 2005 года), занимающийся интерфейсами (look and feel).

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

Итак, приступим. Каждое графическое окружение имеет свой свод правил (User Interface Guidelines, UIG) по созданию интерфейсов, предназначенных для этих окружений. Из основных можно отметить такие руководства как Windows User Experience Interaction Guideline, Apple Human Interface Guideline, KDE User Interface Guideline и GNOME HID. Каждое из этих руководств «определяет положение кнопочек и рюшечек» конкретного окружения. Фреймворк Qt, в свою очередь, осуществляет поддержку всех этих руководств, предоставляя разработчику возможность создавать программы с использованием виджетов, «подстраивающихся» под окружение.

Как Вы знаете — в разработке объёмного JS-приложения где используется популярнейшая библиотека jQuery наступает момент когда остро встаёт проблема производительности. Все силы кидаются на амбразуру профайлера, каждый вызов скрупулёзно исследован, каждый функционально нагруженный кусок реализации обнюхан со всех сторон и выправлен. Но беда поступает не с той стороны, откуда её ждут 90% разработчиков. Селекторы — Как много в этом слове.
Давайте разберёмся — как работает эта магия и почему поиск DOM-элементов может стать причиной падения производительности приложения.

Так получилось, что в течение нескольких месяцев я занимался разработкой букмарклетов, сделав их около десятка. Использовал как jQuery, так и native JavaScript. О том, с какими подводными камнями я столкнулся, что нового узнал и нашел — об этом пойдет речь под катом.

Как известно, Drupal является примером крайне тяжелой CMS/CMF, и нагруженные сайты строить на нем не так просто. Поскольку моя компания использует в своей разработке преимущественно Drupal — нам иногда приходится сталкиваться с оптимизацией производительности, и я бы хотел рассказать о том, как мы справляемся с нагрузкой.

В этой статье я рассмотрю один из самых эффективных методов повышения производительности — кэширование веб-сервером nginx контента для анонимных пользователей. Благодаря этому приему запросы от анонимных пользователей не вызывают обращения к бекэнду(не важно какому — apache или fastcgi). Таким образом, такое кэширование эффективнее любых средств CMS.