Сергей Протько

Laravel/Symfony. Yii стоит брать только для быстрой разработки. CI брать вообще уже не стоит.

<?php

$api = '{"return":[{"usd":0.73644968},{"btc":0.01526533},{"66":0},{"aero":0},{"ar":0},{"asce":0},{"bank":0},{"blz":0},{"bltr":0},{"bnc":0},{"bpc":0},{"brit":0},{"bst":0},{"btcs":0},{"btq":0},{"cam":0},{"cann":0},{"ccn":0},{"cesc":0},{"cfc2":0},{"cln":0},{"cnl":0},{"coin":0},{"cool":0},{"cinni":0},{"crt":0},{"cso":0},{"doge":0},{"drk":0},{"duck":0},{"dvc":0},{"elite":0},{"enrg":0},{"fire":0},{"food":0},{"frsh":0},{"fry":0},{"fsc":0},{"ftc":0},{"ghc":0},{"gly":0},{"god":0},{"grc":0},{"hodor":0},{"html":0},{"icg":0},{"isis":0},{"isr":0},{"lgbt":0},{"lit":0},{"lize":0},{"ltc":0},{"lts":0},{"max":0},{"min":0},{"mj":0},{"mona":0},{"moto":0},{"mtc":0},{"neb":0},{"nhc":0},{"nmc":0},{"note":0},{"nud":0},{"pcc":0},{"pes":0},{"plcn":0},{"pop":0},{"pos":0},{"pro":0},{"pseud":0},{"pyra":0},{"qb":0},{"rce":0},{"rox":0},{"rsn":0},{"rvc":0},{"sbc":0},{"sdc":0},{"spata":0},{"spcc":0},{"spn":0},{"start":0},{"stc":0},{"super":0},{"svc":0},{"tech":0},{"thank":0},{"tor":0},{"trk":0},{"trust":0},{"uro":0},{"via":0},{"vrc":0},{"vtc":0},{"water":0},{"was":0},{"web":0},{"xan":0},{"xbd":0},{"xbl":0},{"xgr":0},{"yacc":0},{"x15c":0},{"xfc":0}]}';
$data = json_decode($api, true);

// переводим курсы валют в удобный нам формат
$currencyRates = array_reduce($data['return'], function ($rates, $rate) {
	return array_merge($rates, $rate);
}, []);

var_dump($currencyRates);

$usd = $currencyRates['usd'];

ideone.com/UDKezx - тут можно проверить.

1) все те же. Разделение приложения на два отдельных (можно сделать через одну точку входа и использовать мидлвар URL-map что бы разруливать разные приложения по урлам. Можно разделить на бандлы - FrontendBundle/BackendBundle. Этот вариант чуть менее гибок, так же как и в случае с модулями в Yii. Хотя жить можно. Лично я пробовал вариант с полным разделением лишь один раз, ибо логика бэкэнда и фронтэнда и настройки приложений слишком уж различались. Да и изначально разработчики Symfony планировали что люди будут так делать, но подход с бандлами стал популярнее.

Разве что могу сказать, что выносить общие настройки приложений, общие части и т.д. с Symfony чуть проще.

2) Бандлы должны быть самодостаточны. По сути это модули. Если вы не планируете реюзать код в других проектах, то смысла выносить этот код в отдельный бандл нету. В 99% случаев смысла разности бизнес-логику приложения по разным бандлам нет.

Обычно делают какой-то CoreBundle/SiteBundle/AppBundle или что-то в этом духе и там делают всю логику проекта. Если появляется какой-то функционал, который можно реюзать (например слой абстракции для работы с платежными системами, система уведомлений или чего еще), это дело можно вынести в отдельный бандл и в последствии реюзать.

Так же довольно распространенная практика хранить код просто в неймспейсе проекта, а в бандлах хранить только вещи специфичные для Symfony (регистрация сервисов, настройки валидаторов, мэппинг базы и т.д., то есть все то что нужно именно Symfony). Подобная структура проекта частенько мелькает когда рассказывают о DDD, да и на самом деле таким образом проще держать проект в чистоте. Если у вас еще и контроллеры как сервисы определены, то вообще красиво выходит. Но это все для ослабления связи кода вашего проекта и фреймворка.

3) Это неймспейс. Обычно вместо Acme пишут либо название проекта либо имя фирмы исполнителя/никнейм фрилансера...

Большинство людей смущает необходимость хранить код на один уровень ниже. Скажем у вас только один неймспейс, код весь в нем, какой смысл в папке src хранить одну единственную папку? Вот и придумали стандарт PSR-4, который позвляет указать префикс. Например что бы избавиться от папки Acme, все его содержимое можно перетащить на уровень выше (прямо в src), и в composer.json прописать

"autoload": {
    "psr-4": {"Acme\\": "src/"}
}

Это все чисто вопрос нэймспейсов и настройки автозагрузки.

Короче ресерчил ресерчил... решил побаловаться со смешиванием цветов. Итог:
jsfiddle.net/2MHPh/2
Правда ускорение тут есть только для повышения яркости. Методов вычитания цвета нету, а что бы добиться понижения яркости сложением нужно два раза инвертировать изображение (исходник, можно инвертировать перед операциями заранее, и результат). В этом случае производительность будет явно такой же.

jsperf.com/imagedata-manipulatioons - сравнение производительности. Каждый тест-кейс по сути представляет собой обработчик события изменения значения яркости.

Update:
Сделал инверсию через мод смешивания "difference".
jsfiddle.net/sjGcA/2
теперь это полноценная реализация. Разницу стоит смотреть на мобильных девайсах.

опечатки в путях? Как минимум две опечатки вижу.

Между колонками сетки есть отступы (по дефолту 30 пикселей), которые задаются свойством padding. Так как у первой колонки будет лишний отступ, может возникнуть ситуация, при которой последняя колонка не будет влазить, или просто наши колонки будут сдвинуты на ширину отступа. Что бы это дело компенсировать, нужно для контейнера ввести отрицательный отступ (margin) на ширину отступа от колонки.

Просто посмотрите через инпектор пример сетки и отключите отрицательный margin.

Вся суть виртуальной машины в том, что бы разработчики не парились о ее реализации. Более того, с момента релиза Android 4.4 прошло достаточно времени что бы разработчики могли проверить как их ПО работает с ART, а Google смог отладить виртуальную машину.

Организуйте пулл соединений, очередь запросов и разруливайте.