Привет, Хабр.

Это моя первая статья.Прошу сильно молотком не бить.

Сегодня, этим сообщением начнется мой цикл статей о фреймворках Spring.

Я не буду вдаваться в тонкости теории, здесь на хабре достаточно статей об этом. Предпочитаю практику.
Тем не менее, стоит напомнить, что работать со Spring Framework можно как с помощью xml-конфигурации, так и с помощью аннотаций. Также, ничего не мешает комбинировать оба подхода.
Лично я предпочитаю работать с аннотациями, чего и вам советую. Поэтому все примеры, которые я буду приводить, будут использовать аннотации.

Доброго времени суток, хабрасообщество!

Проблема

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

Например, допустим, у нас есть некоторая модель ActiveRecord — Expence и вот такой код:

$modelOne = Expence::model()->findByPk(10);
$modelTwo = Expence::model()->findByPk(10);
var_dump($modelOne === $modelTwo); // Вернет false

Таким образом, меняя одну модель мы никоим образом не затронем вторую(что логично, так как они ссылаются на разные объекты).

$modelOne->someField = "Data";
$modelOne->save();
/// ...какой-то код...
echo $modelTwo->someField; // Содержит старое значение
$modelTwo->save(); // Затираем ранее записаные данные

Предлагаем вашему вниманию очередную подборку с ссылками на новости и материалы.

Приятного чтения!

 

Два года назад zizop задавал аналогичный вопрос. Любопытно сравнить, насколько изменился расклад сил.

Ни для кого не секрет, что e-mail маркетинг только начинает набирать обороты во всем мире. А для России – это ещё и вовсе молодая ниша на рынке. И профессиональная верстка электронных писем здесь один из составляющих факторов успеха. Под профессиональной версткой понимается не только визуально красиво и надежно сверстанный макет, но и то, как выглядит usability открытки с маркетинговой точки зрения, как оптимизирована графика вместе с типографией для спам-фильтров и многое другое. Верстка электронных писем довольно обширная тема, в одной статье все не уместить, поэтому в данном посте постараюсь описать только базовые элементы и приемы, надежно проверенные за годы практики и работающие в top самых используемых почтовых клиентах мира: iPhone 4S/5; Outlook 07/10/13; iPad; Apple Mail; Android 2.3/4.0; Yahoo; Gmail. Если рассматривать только российский рынок, то нельзя не упомянуть о Mail.ru и Яндекс.Почта.

Что нужно знать в начале?

Сразу хочу выделить несколько из основных и важных моментов:

1. В нашем арсенале имеется очень урезанный набор css-свойств, которые поддерживаются всеми почтовиками. При этом, стили нужно прописывать inline, а в head выносить только вендорные свойства и те блоки объявлений, которые не несут нагрузки на основную стилизацию письма. Ну и использовать link in head — крайне нежелательно.
2. Не используйте background-image в основных визуальных элементах дизайна и не помещайте в изображения важную текстовую информацию. Вообще нужно всегда учитывать такой вариант, что письмо будет просматриваться получателем без единого изображения.

Каркас

Пожалуй каждый, кто хоть раз верстал письмо под рассылку, знает, что каркас лучше строить с помощью таблиц. На самом деле простая блочная модель div поддерживается на данный момент во всех перечисленных выше почтовиках, за исключением MS Outlook начиная с 2007 версии. Это связано с тем, что в качестве движка последние версии Outlook используют Microsoft Word, который в свою очередь много не знает о блочных css-свойствах. Игнорировать при верстке данный почтовый клиент я не рекомендую, поэтому в качестве фундамента все же используйте table. Да и добившись хорошего результата для Outlook, можно быть уверенным, что в большинстве почтовиках, письмо будет смотреться тоже хорошо, а скорее и лучше.

В качестве примера рассмотрим наиболее важные элементы из следующего, не сложного шаблона:

Введение

На днях, свершилось событие, которое Я и думаю еще немало людей ждали. Авторы Yii Framework выкатили превью-версию.

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

Долгожданное превью не менее долгожданного фреймворка Yii 2 стало доступно для всех желающих.

Вольный перевод официальной новости:
«Мы рады сообщить, что превью Yii 2 доступно на Github. Это важное событие в разработке Yii 2, которая началась более двух лет назад — с тех пор мы полностью переписали его.

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

Мы искренне приглашаем вас поиграться с кодом Yii 2 и написать о своих впечатлениях нам, а так же приглашаем поучаствовать в его разработке»

Yii 2 на Github
Багтрекер Yii 2
Ветка форума посвященная Yii 2

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

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

Здравствуйте!

Сегодня я расскажу как настроить массовую рассылку писем через Amazon SES с нуля.

Для начала нужно иметь аккаунт в Amazon Web Services и прикреплённый к нему метод оплаты сервиса. Если у Вас это есть, смело можем начинать!

Настройка SES

Итак, пройдём в консоль: https://console.aws.amazon.com. В списке сервисов ищем SES. Т.к. мы раньше не имели дела c SES, нас встречает удручающая надпись:

Предлагаем вашему вниманию очередную подборку с ссылками на новости и материалы.

Приятного чтения!

Предлагаем вашему вниманию очередную подборку с ссылками на новости и материалы.

Приятного чтения!

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

Многие из вас наверняка заметили, что я пишу книгу о Zend Framework. Недавно я закончил черновики двух глав: «Архитектура приложений на Zend Framework» и «Понимая Zend Framework». В первой главе объясняется архитектурный шаблон Model-View-Controller (MVC) и причины, по которым он стал стандартом де-факто для веб-приложений. Во второй исследуется связь MVC с компонентами Zend Framework, их структурой и взаимодействием.

Завершив обе главы я осознал, что большую часть времени описывал модель и ее фактическое отсутствие в Zend Framework. На самом деле ни один веб-фреймворк не предлагает нам полноценную модель (по причинам, которые я объясню чуть позже). И ни в одном из них не дается внятного объяснения этому обстоятельству. Вместо этого они последовательно связывают понятие модели с родственным, но не идентичным понятием доступа к данным, что изрядно всех запутывает.

Эта сторона фреймворков никогда не привлекала особого внимания. И все же именно она лежит в основе целого класса проблем в тех приложениях, которые пытаются использовать MVC по образу и подобию фреймворков для веб-приложений. Более того, попытки донести идею модели до других разработчиков нередко напоминают битье головой о стену. Я не хочу сказать, что все разработчики тупые или не понимают саму идею, просто никто из них (вне зависимости от того, работают они с PHP или нет) не связывает модели с той областью, которая наделяет их смыслом — принципами объектно-ориентированного программирования.

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

(<([a-z]+[^>]*)>)(.*)(</\2>)

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



Когда-то и мне пришлось по долгу службы подружиться с регулярными выражениями. Прочитав Фридла и несколько статей на Хабре, я, конечно, начал понимать этот синтетический язык. Тем не менее, каждый раз, когда приходилось написать очередную регулярку, я быстро закапывался в нагромождении скобок, слешей, точек, плюсов, знаков вопроса, и других хорошо вам знакомых конструкциях. Разобраться в этой каше было очень сложно, особенно если возвращаешься к задаче месячной давности. Я мечтал об инструменте, который помог бы мне разобраться в собственном творении. Приблизительно подходящих по смыслу сервисов нагуглилось с десяток, но все они приносили мало пользы. Как раз тогда я и начал разрабатывать этот проект.

Итак, regexponline – инструмент, способный наглядно изобразить структуру регулярного выражения, разобрав его по элементарным компонентам; продемонстрировать совпадающие и не совпадающие его части; помочь в написании и отладке выражения, которое почему-то не совпадает с нужной строчкой.

Предлагаем вашему вниманию очередную подборку с ссылками на новости и материалы.

Приятного чтения!

Довольно часто при написании модульных тестов нам приходится сталкиваться с тем, что тестируемый класс зависит от данных из внешних источников, состояние которых мы не можем контролировать. К таким источникам можно отнести далеко расположенную общедоступную базу данных или службу, датчик какого-нибудь физического процесса и пр. Либо нам необходимо убедиться, что некие действия выполняются в строго определенном порядке. В этих случаях к нам на помощь приходят Mock объекты (mock в переводе с английского — пародия), позволяя тестировать классы в изоляции от внешних зависимостей. Использованию Mock объектов в PHPUnit посвящается эта статья.

Первое правило безопасности при разработке Веб приложений гласит: —

Не доверять данным пришедшим от клиента.

Почти все это правило хорошо знают и соблюдают. Мы пропускаем через валидаторы данные форм, кукисы, даже URI.
Но недавно я с удивлением обнаружил, что есть одна переменная, приходящая от клиента, которую почти никто не фильтрует.
Речь пойдет о компрометации веб приложения через подмену значения HTTP_HOST и SERVER_NAME.

Очень часто в интернете встречаюсь со статьями, в которых приводят кучу примеров с якобы странным поведением MySQL по сравнению с другими БД. Чтобы стало понятно, о чём я говорю, приведу несколько примеров:
1. Деление на ноль возвращает NULL вместо ошибки
2. Выход за диапазон допустимых значений неявно приводит число к допустимому значению, а не к ошибке и откату транзакции
3. Вставка неверного типа данных также приводит к неявному преобразованию и успешному выполнению операции
Таких примеров я могу привести огромное число, но цель статьи не сделать очередное собрание высосанных из пальца примеров, а объяснить, почему происходит то или иное действие. Вся эта мистика MySQL давно описана в документации и легко объяснима, в чём вы сможете убедиться сами, прочитав статью до конца.
Для меня эта первая статья на хабре, поэтому я старался писать дотошно подробно. Уверен, что она будет полезна всем, кто работает с MySQL. Большую помощь в написании статьи оказала подготовка к сдаче на сертификат разработчика MySQL, а точнее книга «MySQL Certification Study Guide».
Итак, мой друг, начнём!

В марте 2012 года был анонсирован релиз PHP 5.4. В этой версии должно было появиться множество интересных нововведений, так что разработчики ждали его с нетерпением. Пожалуй самой ожидаемой особенностью стали типажи (traits). Еще до релиза, Shameer C написал замечательный обзор возможностей, которые дают нам типажи в PHP. Я настоятельно рекомендую вам ознакомиться с этой статьей, так как моя статья предполагает наличие у вас базовых знаний по типажам и понимание их работы.

Сообщество разработчиков PHP приняло типажи, в основном потому, что они уже были реализованы в других популярных языках программирования, например Java, C++ и Python. Кроме того, преимущества типажей были хорошо разрекламированы разработчиками, которые вставляли свои пять копеек, касательно того, как типажи помогут улучшить любой проект, особенно как замена наследования. Но так ли хороши типажи на самом деле? Помогут ли они повысить уровень PHP разработчиков, или же это просто очередная причуда?

PHP всегда был простым, процедурным языком программирования, черпавшим свое вдохновение из C и Perl. В PHP 5 появилась правильная объектная модель, но о ней вы уже все знаете. А вот в PHP 5.3 появились замыкания (closure), которые были серьезно улучшены в версии 5.4 (подсказка: $this теперь доступен по умолчанию).