Поддерживаю Magento. Три магазина друзей. Все достаточно хреновенько в плане производительности. Какая-то книжная чтоли архитектура. Безумная расширяемость, офигенная модульность, но именна эта архитектура создает тонны оверхеда.
На текущих мощностях работает терпимо, но 4к траффика я бы побоялся пустить.
PS: Минусы не знаю за что вам лепят, фраза в общем-то верная. по крайней мере насчет мадженты. но чтобы ее правильно готовить нужно пуд соли сьесть :)
Там проблемы с запросами.
Предлагаю сделать штук 200 категорий с вложенностью и просмотреть профилировщиком количество запросов к базе. Когда я последний раз тыкал этот движок все было плохо.
Оптимизировать вручную можно, но это тоже время и может быть не так тривиально как кажется(чужой код, чужая архитектура, нужно быть совместимым с апдейтами).
Ответ от их сервера выглядит так: [ [EVENT_ID, ...], [EVENT_ID,...], [EVENT_ID,...] ]
Вы можете получить это событие просто отправив самому себе сообщение. Вторым массивом массивов событий как раз пойдет [101,-1,-1].
Проблема в том, что это не флаг, потому что флаги я обрабатываю и отсылаются флаги не отдельным событием, ну и для сообщения они вот такие: «UNREAD», «CHAT».
Есть специфические для приложения пакеты — их можно положить рядом. Есть пакеты SDK они лежат в GOROOT, есть чужие пакеты или пакеты общего назначения они ложатся в GOPATH.
Я для себя избрал такой способ организации.
GOPATH у меня что-то вроде /var/go/packages/
Получается в Go, значение GOPATH сугубо для одного набора исходников?
Вы какую версию Go используете? В go1.1.1 все разжевали и запретили выставлять GOPATH==GOROOT.
GOPATH это места, в котором Go ищет пакеты.
Про системы пакетов вообще рекомендую почитать go get gopath
Так получается, что оно смотрит сначала вокруг себя и ищет конфиги программы, потом ищет их в дирректории программы, если нет — создает.
Пишем мы в публичные дирректории(например в appdata), так что права администратора не нужны. Тоже самое с реестром.
То что вы описали, да, вариант. Но с датами не хочется заморачиваться, потому что при некоторых обновлениях(критических/мажорных) конфиг может сброситься.
Так получается, что оно смотрит сначала вокруг себя и ищет конфиги программы, потом ищет их в дирректории программы, если нет — создает.
Пишем мы в публичные дирректории(например в appdata), так что права администратора не нужны. Тоже самое с реестром.
напишите статью про не-gpl конфиги сисадмина, работающего по договору «вся твоя мозговая деятельность = собственность компании», мне аж интересно стало
А чем стандартный функционал разделения прав не подошел? На slave`е есть пользователь, не имеющий прав на drop/delete/replace/update, на мастере другой юзер у которого права есть.
