В последние дни было зарегистрировано три уязвимости, касающиеся PHPMailer и SwiftMailer:

• 25.12.2016, CVE-2016-10033 Уязвимость удалённого выполнения кода через PHPMailer
• 27.12.2016, CVE-2016-10045 Уязвимость удалённого выполнения кода через PHPMailer
• 28.12.2016, CVE-2016-10074 Уязвимость удалённого выполнения кода через SwiftMailer

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

1 Почему JavaScript отстой
• 1.1 Плохая конструкция
• 1.2 Система типов
• 1.3 Плохие функции
• 1.4 Отсутствующие функции
• 1.5 DOM
2 Почему Lua отстой
3 Почему PHP отстой
• 3.1 Исправлено в поддерживаемых в настоящее время версиях
4 Почему Perl 5 отстой
5 Почему Python отстой
• 5.1 Исправлено в Python 3
6 Почему Ruby отстой
7 Почему Flex/ActionScript отстой
8 Почему скриптовые языки отстой
9 Почему C отстой
10 Почему C++ отстой
11 Почему .NET отстой
12 Почему C# отстой
13 Почему VB.NET отстой
15 Почему Objective-C отстой
16 Почему Java отстой
• 16.1 Синтаксис
• 16.2 Исправлено в Java 7 (2011)
• 16.3 Модель
• 16.4 Библиотека
• 16.5 Обсуждение
17 Почему Backbase отстой
18 Почему XML отстой
19 Почему отстой XSLT/XPath
20 Почему CSS отстой
• 20.1 Исправлено в CSS3
21 Почему Scala отстой
22 Почему Haskell отстой
23 Почему Closure отстой
24 Почему Go отстой
• 24.1 Базовые средства программирования (базовый язык)
• 24.2 Взаимосовместимость
• 24.3 Стандартная библиотека
• 24.4 Набор инструментальных средств
• 24.5 Сообщество
25 Почему Rust отстой
• 25.1 Безопасность
• 25.2 Синтаксис
• 25.3 Конструкция API и система типов
• 25.4 Сообщество
• 25.5 Набор инструментальных средств

Почему JavaScript отстой

Плохая конструкция

В очередной раз на меня свалилась задача найти хорошего PHP-программиста.
По результатам прозвона потенциальных кандидатов, 90% тех, кто мнит себя Middle, на самом деле Junior и годы опыта не спасают, потому что клепают однотипный код в пределах заданий, посланных свыше.
Прописал минимальный план желающим сделать рывок и перейти на следующий уровень без отрыва от производства.

$generator = new imgGenerator();
$textGenerator=new imgTextGenerator();
$textGeneratorTop=new imgTextGenerator();

$label=$textGeneratorTop
	->seTextShadow("#000000", 75, 1, 2, 2)
	->setText("Test Site","#ffffff",imgGenerator::position_center_top,"1/12",0 )
	->setBackground("#000000",'3%')
	->setFont($_SERVER["DOCUMENT_ROOT"]."/upload/fonts/fonts2_7/hinted-PTF55F.ttf");

$text=$textGenerator
	->seTextShadow("#000000", 75, 1, 2, 2)
	->setText("Морковь как двигатель прогресса человечества","#ffffff",imgGenerator::position_center_center,"1/7",array(0,'5%',0,'5%'))
	->setFont($_SERVER["DOCUMENT_ROOT"]."/upload/fonts/fonts2_7/hinted-PTF55F.ttf");

$generator
	->addText($text)
	->addText($label)
	->fromImg($_SERVER["DOCUMENT_ROOT"] . "/upload/dynamic/2016-08/15/carrot-big.jpg")
	->resizeFor("autodetect")
	->addOverlay(0.5,"#000000")
	->show();

Примеры картинок

• Берем за основу картинку или цвет
• Уменьшаем до нужного размера
• Накладываем сверху полупрозрачный фон
• Устанавливаем логотип
• Добавляем надпись
• Кешируем результат

Требования

• Окружение должно развертываться на Windows, MacOS, Linux
• Установка должна быть максимально простой
• Быстрая работа с файловой системой
• Интеграция с IDE PHPStorm
• Несколько версии PHP интерпретаторов (5.6, 7.0)

JavaScript сильно изменился за последние годы. Вот 12 новых возможностей, которые можно начать использовать уже сегодня!

История

Новые добавления в язык называются ECMAScript 6. Или ES6 или ES2015+.

С момента появления в 1995, JavaScript развивался медленно. Новые возможности добавлялись каждые несколько лет. ECMAScript появился в 1997, его целью было направить развитие JavaScript в нужное русло. Выходили новые версии – ES3, ES5, ES6 и так далее.

Как видите, между версиями ES3, ES5 и ES6 есть пропуски длиной в 10 и 6 лет. Новая модель – делать маленькие изменения каждый год. Вместо того, чтобы накопить огромное количество изменений и выпустить их все за раз, как это было с ES6.

От переводчика:
Уже опубликовано много материалов по MVC и его производным паттернам, но каждый понимает их по-своему. На этой почве возникают разногласия и холивары. Даже опытные разработчики спорят о том, в чем отличие между MVP, MVVM и Presentation Model и что должен делать тот или иной компонент в каждом паттерне. Ситуация усугубляется еще и тем, что многие не знают истинную роль контроллера в классическом варианте MVC. Предлагаю вашему вниманию перевод хорошей обзорной статьи, которая многое проясняет и расставляет всё по своим местам.

CREATE TABLE IF NOT EXISTS `user_myisam` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `login` varchar(8) NOT NULL,
  `money` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `login` (`login`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

INSERT INTO `user_myisam` (`id`, `login`, `money`) VALUES
(1, 'ivanov', 100),
(2, 'petrov', 200),
(3, 'sidorov', 300);

CREATE TABLE IF NOT EXISTS `user_innodb` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `login` varchar(8) NOT NULL,
  `money` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `login` (`login`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

INSERT INTO `user_innodb` (`id`, `login`, `money`) VALUES
(1, 'ivanov', 100),
(2, 'petrov', 200),
(3, 'sidorov', 300);

SHOW TABLE STATUS;

$mysqli = new mysqli($host, $user, $password, $database);

1. Видео с доклада
2. Слайды

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

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

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

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