Создаёт инстанс класса MySQLOrderRepository сразу. Исользуя lazy-loading используя лямбду будет более экономичным решением, если учесть, что в проекте таких вызовов могут быть тонны. Всё равно каждый раз надо грузить в сценарий лишь используемые классы.
Примера ради:
$orderModel->setRepository(function () { return new MySQLOrderRepository()});
Далее не буду описывать описывать механизмы проверки, загружен ли уже сервис и т.д.
Думаю, алгоритм понятен.
Я всё понимаю, не новичок.
А что у вас за шаред такой, позвольте узнать? Для себя бы я такой хостинг не брал, если только поразвлечься :-)
Суть была не в конкретном хостинге, что где-то это возможно, а в потоке проектов: заказ -> реализация -> сдача. Т.е есть ядро (CMS/CMF) с этой «мулькой», а хостинг без разницы какой. Ты одал и не волнуешься, что там у кого работает, у кого нет. Т.е была бы 99% совместимость либы в её скриптовом варианте.
Как вы разворачивали без компиляции под конкретную среду? Есть зависимости пакетов, системы и т.д.
Короче, это оффтоп и смысла нет продолжать.
Да? Для того, что бы их использовать на шареде — их надо сначала проинсталить, не правда ли? Хостер, если он конечно маразмом не страдает никогда не поставит на рабочую среду неизвестно какой софт, который может содержать эксплоит, например, и тем более, ради одного юзера. Так что причем тут shell_exec? Смысл моего коммента был в самой возможности установить его на шаред. Поэтому я и заикнулся про порты на скриптовых языках.
Вообще, впечатляет.
Что касается третьего изображения, то если посмотреть девушке на губы, то видна очень даже существенная разница. Попробовал уменьшить изображение на 50%, то разницы и вовсе не заметно. Т.е, для небольших и некоторых средних картинок будет весьма полезна. Интересны были бы порты на разных языках, к примеру: python, perl, php. Применимости и динамичности было бы больше. Из консоли под Debian процессить конечно хорошо, но это ограничивает ипользование на шаред хостингах и в качестве built-in tool-а, например, в продуктах. Но это уже отдельная тема.
В закладки, спасибо.
$params = Zend_Json::decode($data);
$errors = array();
$validate = function(array $what) use ($params, $errors) {
if (!is_array($params) || empty($params)) {
throw new InvalidArgumentException('Invalid params has provided');
}
foreach ($what as $name) {
if (!isset($params[$name])) {
$errors[$name] = ucfirst($name) . ' can\'t be empty!';
} elseif ('email' == $name) {
$validator = new Zend_Validate_EmailAddress();
if (!$validator->isValid($params[$name])) {
$errors[$name] = current($validator->getMessages());
}
}
/*
* Your additional logic here
* .................................
*/
}
};
try {
$validate(array('email', 'name', 'password'));
} catch (InvalidArgumentException $e) {
// Handle exception
}
if (empty($errors)) {
// Success
} else {
// Failure
}
А лучше сделать всё сервисом, используя factory pattern, для того что бы иметь возможность авторизовать пользователя к примеру через Facebook или Twitter, а не только учётной записью вашей локальной базы.
Имея такой подход можно с лёгкостью добавлять новые методы авторизации, написав лишь для каждого новый адаптор имплементрирующий конвенцию интерфейса, которую вы уже сами реализуете.
Тут, конечно, на вкус и цвет… Но, надо приучать себя писать scalable код, потому как никогда точно не знаешь, как может в последствии развиться проект и какие новые потребности могут появиться. Экономиться куча времени на рефакторинге и нервов, когда в конечном итоге приходиться всё переписывать. А тут, оп-оп и в дамках! :-)
Для чего надо делать проверку !isset($email) || !isset($name) || !isset($password), если переменные явным образом определены несколькими строчками ранее?
Дело в том, что соответствующих элементов массива после Zend_Json::decode() может не быть, а это уже: Notice: Undefined index: email.
Мы не можем быть уверены точно, что JSON придёт именно тот, что нам нужен.
В рамках данного контекста кода, на мой взгляд проверку как раз таки надо было делать так:
После того, как переменные определены и имеют какие-то значения, только тогда уже проверять и не isset(), а уже null !== $email.
И вообще, код в DeviceapiController::signupAction() мягко говоря шокировал меня:
if (!isset($email) || !isset($name) || !isset($password) || (filter_var($email, FILTER_VALIDATE_EMAIL)==FALSE))
{
if (!isset($email)) {
$err['email'] = "Email is missing";
}
Зачем так делать?!
Я понимаю, что это всё примера ради, но всё же надо позаботиться, что бы это было как подобается, тем более, как я понял — это копипаст с рабочего проекта.
Что касается типизации, то PHP уже имеет оную в виде SPL Type Handling реализации посредствам PECL либы.
На данный момент имеются:
SplInt, SplFloat, SplEnum, SplBool и SplString.
Не скажу, что это ох как красиво и нативно, на как есть, так есть. Может, кому-то будет интересно.
Мыслите шире. Приведу пару примеров, которые хоть и косвенно относятся к этой теме, но всё.
После того как в 1960-х годах в рекламе Alka-Seltzer стали бросать в стакан с водой не одну, как раньше, а две таблетки — продажи лекарственного препарата увеличились ровно вдвое. Хитрый рекламный ход придумало агентства Tinker&Partners.
Существует аналогичная байка про гениального маркетолога, который первым придумал указать в инструкции по применению шампуня, что его следует наносить на волосы и смывать дважды, что привело к двойному росту продаж. Ну и вспомните рекламные ролики жевательных резинок в подушечках. По сколько подушечек кладут в рот герои рекламы? То-то и оно.
И ещё, я не говорю, что этот ход сильно приумножит доходы Apple. Это скорее больше для независимости брэнда, уникальности и имиджа. Кто поймёт — тот поймёт.
В чём собственно суть поста? Где завязка, где развязка, где кульминация? :-)
Вы просто взяли example, вставили свои параметры и туру-ру.
Если бы пост был о сравнения различных библиотек для построения графиков — было бы гораздо интереснее почитать. Ясен красен, что их много, взять хотя бы топовые. Кстати, клиентские «либы» графопостроителей зачастую покрывают все необходимые задачи.
Стратегия Apple очевидна!
Тестирование, разработка, обеспечение совместимости… Теперь придётся уже покупать соответствующий «яблочный» девайс для этого, соответственно, продажи увеличатся.
Вот он, коммент с реальными доводами. Озвучил то, что было в моей голове, но сформулировать не мог.
Увы, но это так. Существуют альтернативы, но опять же, с ними будут подводные камни, да и админам больше мороки. Зачем рвать опу за то, что не принесёт дополнительной копейки, ведь есть давно отлаженный «степ бай степ», как говориться — «Поставил и забыл». Надежда на энтузиастов, которым это будет интересно.
Надо уже начинать мстить за 7 и 8. Вообще, когда «мелкософтовцы» уже возьмутся за ум. Если FF и Chrome уже освоили ту или иную фичу, то IE подтягивается только через год или того позже. И сообщения о небезопасном контенте рубят, не смотря на то, что их можно отключить.
Хотя, если так разобраться, не все юзеры виноваты, что их заставляют пользоваться устаревшим софтом, зачастую — это политика компании, жёсткие настройки сисадмина или же легаси железо. В большинстве случаев эта статистика с западных клерковских контор, где всё работает и слава богу.
Впечатлило!
Создаёт инстанс класса MySQLOrderRepository сразу. Исользуя lazy-loading используя лямбду будет более экономичным решением, если учесть, что в проекте таких вызовов могут быть тонны. Всё равно каждый раз надо грузить в сценарий лишь используемые классы.
Примера ради:
Далее не буду описывать описывать механизмы проверки, загружен ли уже сервис и т.д.
Думаю, алгоритм понятен.
А что у вас за шаред такой, позвольте узнать? Для себя бы я такой хостинг не брал, если только поразвлечься :-)
Суть была не в конкретном хостинге, что где-то это возможно, а в потоке проектов: заказ -> реализация -> сдача. Т.е есть ядро (CMS/CMF) с этой «мулькой», а хостинг без разницы какой. Ты одал и не волнуешься, что там у кого работает, у кого нет. Т.е была бы 99% совместимость либы в её скриптовом варианте.
Как вы разворачивали без компиляции под конкретную среду? Есть зависимости пакетов, системы и т.д.
Короче, это оффтоп и смысла нет продолжать.
Что касается третьего изображения, то если посмотреть девушке на губы, то видна очень даже существенная разница. Попробовал уменьшить изображение на 50%, то разницы и вовсе не заметно. Т.е, для небольших и некоторых средних картинок будет весьма полезна. Интересны были бы порты на разных языках, к примеру: python, perl, php. Применимости и динамичности было бы больше. Из консоли под Debian процессить конечно хорошо, но это ограничивает ипользование на шаред хостингах и в качестве built-in tool-а, например, в продуктах. Но это уже отдельная тема.
В закладки, спасибо.
Почему лучше strategy? Обоснуйте.
А лучше сделать всё сервисом, используя factory pattern, для того что бы иметь возможность авторизовать пользователя к примеру через Facebook или Twitter, а не только учётной записью вашей локальной базы.
Имея такой подход можно с лёгкостью добавлять новые методы авторизации, написав лишь для каждого новый адаптор имплементрирующий конвенцию интерфейса, которую вы уже сами реализуете.
Тут, конечно, на вкус и цвет… Но, надо приучать себя писать scalable код, потому как никогда точно не знаешь, как может в последствии развиться проект и какие новые потребности могут появиться. Экономиться куча времени на рефакторинге и нервов, когда в конечном итоге приходиться всё переписывать. А тут, оп-оп и в дамках! :-)
Статья не плохая, развивайтесь!
Удачи вам!
Для чего надо делать проверку !isset($email) || !isset($name) || !isset($password), если переменные явным образом определены несколькими строчками ранее?
Дело в том, что соответствующих элементов массива после Zend_Json::decode() может не быть, а это уже: Notice: Undefined index: email.
Мы не можем быть уверены точно, что JSON придёт именно тот, что нам нужен.
В рамках данного контекста кода, на мой взгляд проверку как раз таки надо было делать так:
После того, как переменные определены и имеют какие-то значения, только тогда уже проверять и не isset(), а уже null !== $email.
И вообще, код в DeviceapiController::signupAction() мягко говоря шокировал меня:
Зачем так делать?!
Я понимаю, что это всё примера ради, но всё же надо позаботиться, что бы это было как подобается, тем более, как я понял — это копипаст с рабочего проекта.
На данный момент имеются:
SplInt, SplFloat, SplEnum, SplBool и SplString.
Не скажу, что это ох как красиво и нативно, на как есть, так есть. Может, кому-то будет интересно.
Пример:
$string = new SplString(«Testing»);
try {
$string = array();
} catch (UnexpectedValueException $uve) {
echo $uve->getMessage(). PHP_EOL;
}
var_dump($string);
echo $string; // Выведет «Testing»
P.S: использовать тэги и линки карма не позволяет, звиняйте.
Где-то я уже видел пару эпизодов с его участием.
А вы знаете, что mysql_connect и весь его процедурных подход уже депрекейтед?
См. php.net/manual/en/function.mysql-connect.php
Используйте PDO расширение.
После того как в 1960-х годах в рекламе Alka-Seltzer стали бросать в стакан с водой не одну, как раньше, а две таблетки — продажи лекарственного препарата увеличились ровно вдвое. Хитрый рекламный ход придумало агентства Tinker&Partners.
Существует аналогичная байка про гениального маркетолога, который первым придумал указать в инструкции по применению шампуня, что его следует наносить на волосы и смывать дважды, что привело к двойному росту продаж. Ну и вспомните рекламные ролики жевательных резинок в подушечках. По сколько подушечек кладут в рот герои рекламы? То-то и оно.
И ещё, я не говорю, что этот ход сильно приумножит доходы Apple. Это скорее больше для независимости брэнда, уникальности и имиджа. Кто поймёт — тот поймёт.
Вы просто взяли example, вставили свои параметры и туру-ру.
Если бы пост был о сравнения различных библиотек для построения графиков — было бы гораздо интереснее почитать. Ясен красен, что их много, взять хотя бы топовые. Кстати, клиентские «либы» графопостроителей зачастую покрывают все необходимые задачи.
Тестирование, разработка, обеспечение совместимости… Теперь придётся уже покупать соответствующий «яблочный» девайс для этого, соответственно, продажи увеличатся.
А вы защитник отечественного автопрома или просто любите под машиной полежать? :-)
Это дело вкуса!
Увы, но это так. Существуют альтернативы, но опять же, с ними будут подводные камни, да и админам больше мороки. Зачем рвать опу за то, что не принесёт дополнительной копейки, ведь есть давно отлаженный «степ бай степ», как говориться — «Поставил и забыл». Надежда на энтузиастов, которым это будет интересно.
habrastorage.com/?v=1262794437.jpg
Хотя, если так разобраться, не все юзеры виноваты, что их заставляют пользоваться устаревшим софтом, зачастую — это политика компании, жёсткие настройки сисадмина или же легаси железо. В большинстве случаев эта статистика с западных клерковских контор, где всё работает и слава богу.