По моему мнению система слишком сложная. Получается каждому нужно, еженедельно распределить какую-то сумму, не забыть это сделать и сделать это справедливо для всех сторон. Однако понятие справедливости достаточно сложно. Никто не встречался с ситуацией, когда люди в команде думают, что только они тут работают, а остальные так сбоку, хорошо, если не мешают?
Могут так же начаться всякие размышления, типа нужно же Васе накинуть, чтобы он меня не забыл, а то обидется и меня не поблагодарит, а Вася, то расчитывал не на 5 рублей за помощь, а на 20. Это может быть потенциальной угрозой в команде и перевести совместную работу в некоторые сговоры и коррупцию. Может сложится другая ситуация, когда ты ни к кому без фиги в кармане не подойдешь. Хочешь спросить простой вопрос, а тебе говорят 5 баксов, причем не в шутку, а реально расчитывая за каждую помощь на деньги.
У меня в практике был случай, когда руководитель объявлял по сути хорошую инициативу и говорил, что самый производительный сотрудник по итогам периода получит определенный бонус. Народ в коллективе быстро договорился, что бонус они в любом случае поделят на всех и продолжили работать в том же режиме.
Я все же думаю, что идея интересная, но работать может на «сферической лошади в вакууме». Т.е. все очень сильно зависит от коллектива и скорее всего, такой коллектив где-то есть, но я таких не встречал.
Я лично согласен с предыдущими постами, что премировать нужно полезные для компании инициативы, это же по сути вектор, который говорит — делай так и получишь бонус…
Согласен, что малый бизнес — это хорошо. Главное, чтобы владелец был в гармонии с самим с собой. Т.е. не у всех есть амбиции и желание ворочать миллиардами, известно ведь, чем больше деньги тем и проблемы больше. Другое дело стараться сделать свое дело максимально хорошим и удобным для клиентов, тут, по моему мнению, останавливаться не стоит, иначе можно в какой-то момент понять, что ты и твой бизнес никому не нужны…
Да, масштаб, уже несколько минут осмысливаю увиденные цифры, а в мире уже столько поменялось:) Как бы это так напрячься на минуту раз в год, чтобы 272 000 пошли именно тебе?
Пробовали.
Оба достаточно сырые. Vespolina тянет слишком много лишнего. Sylius в этом плане нам больше подходит. Мы рассматриваем возможность замены части нашей системы на один из этих наборов бандлов (или его часть) после релиза Symfony 2.1.
Если вы интересуетесь Symfony, то должны знать что из себя представляет проект CMF. Так вот Vespolina (как более продуманный в плане архитектуры набор бандлов их этих 2х) лично мне кажется еще сырее CMF. А его пока используют только в sandbox проектах и для презентаций (тут возможно я что-то упускаю ибо не было времени посмотреть презентации с Symfony Live Paris 2012, а там доклад от этих ребят был).
Прошлым летом он зарелизился, но к тому моменту его уже активно использовали. На сайте симфони где-то есть страница с… success stories. Так вот некоторые из этих проектов стартовали еще до релиза стабильной версии фреймворка.
На самом деле не стоит искать в этой статье какую-то агитацию) Каждому нравится свое. Нам тогда показался это выбор правильным и сейчас ничего не изменилось.
В дев режиме нет кеша, поэтому все работает в нем медленно и это нормально. Если полностью снести кеш, то 5-10 секунд для первого запуска это быстро. На продакшне все на порядок быстрее. Точных замеров не делал, потому что задачи ускорения быстродействия пока не стоит. Если кеш есть, то в секунду даже в самом худшем случае укладываться должно.
Для симфони жестких оптимизаций несколько:
— APC
— Он же для всякого мелкого кеша вроде автолоада, DQL
— Memcache для доктриновского result cache и хороший алгоритм его инвалидации
— Проверьте как у вас настроен логгер и что падает в лог апача
— Хорошо настроенный HTTP cache. ESI с reverse proxy мы пока не используем, но для начала хватает стандартного AppCache
— Если много рутов, можно покопаться в нете и найти для них Apache Dumper. Dumper создаст по рутам htaccess правила.
— Когда устоится схема БД, пересмотреть связи в доктрине. Тут правило одно — как можно меньше bidirectional связей и событий. У доктрины есть в доках немного про оптимизацию
— Если можно на странице обойтись голыми данными, пусть их доктрина и возвращает. Большой объект с множеством связей создается долго, простой массив — быстро.
— События ядра симфони тоже стоит использовать с умом
Я бы посоветовал прогнать ключевые страницы через какой-нибудь профилировщик. Симфони достаточно гибок, поэтому быстрым из коробки быть не может. Но и медленным я бы его не назвал. По опыту могу сказать, часто проблемы в медленных клиентских скриптах и слишком тяжелой разметке и стилях. PHP скрипт отрабатывает достаточно быстро.
Ругань, наверное, стояла на весь банк потом:) Интересно, если бы вы не вернули деньги, а использовали по своему усмотрению, но потом все же вернули кредит с процентами, это было бы мошеничество?
Сырой, мы только начали и благодярая хаброэффекту смогли понять, что нам поменять и как перестроить работу. Вам бы хотел предложить добавить своб планировку в нашу очередь и мы сделаем вашу квариру в нескольких вариантах, учитывая ваши замечания:) Сделать это можно вот тут: remmart.ru/layouts/
Спасибо за ваше мнение и советы. Всегда полезно мнение со стороны. На самом деле почти все, что вы отметили, мы уже меняем и главную страницу в том числе. Особенно ценным для меня был ваш совет номер 4. Видимо придется поменять название категории, чтобы не вводить людей в заблуждение. Там речь идет только о тех товарах, которые мы продаем, а не в принципе об отделке.
Могут так же начаться всякие размышления, типа нужно же Васе накинуть, чтобы он меня не забыл, а то обидется и меня не поблагодарит, а Вася, то расчитывал не на 5 рублей за помощь, а на 20. Это может быть потенциальной угрозой в команде и перевести совместную работу в некоторые сговоры и коррупцию. Может сложится другая ситуация, когда ты ни к кому без фиги в кармане не подойдешь. Хочешь спросить простой вопрос, а тебе говорят 5 баксов, причем не в шутку, а реально расчитывая за каждую помощь на деньги.
У меня в практике был случай, когда руководитель объявлял по сути хорошую инициативу и говорил, что самый производительный сотрудник по итогам периода получит определенный бонус. Народ в коллективе быстро договорился, что бонус они в любом случае поделят на всех и продолжили работать в том же режиме.
Я все же думаю, что идея интересная, но работать может на «сферической лошади в вакууме». Т.е. все очень сильно зависит от коллектива и скорее всего, такой коллектив где-то есть, но я таких не встречал.
Я лично согласен с предыдущими постами, что премировать нужно полезные для компании инициативы, это же по сути вектор, который говорит — делай так и получишь бонус…
Оба достаточно сырые. Vespolina тянет слишком много лишнего. Sylius в этом плане нам больше подходит. Мы рассматриваем возможность замены части нашей системы на один из этих наборов бандлов (или его часть) после релиза Symfony 2.1.
Если вы интересуетесь Symfony, то должны знать что из себя представляет проект CMF. Так вот Vespolina (как более продуманный в плане архитектуры набор бандлов их этих 2х) лично мне кажется еще сырее CMF. А его пока используют только в sandbox проектах и для презентаций (тут возможно я что-то упускаю ибо не было времени посмотреть презентации с Symfony Live Paris 2012, а там доклад от этих ребят был).
На самом деле не стоит искать в этой статье какую-то агитацию) Каждому нравится свое. Нам тогда показался это выбор правильным и сейчас ничего не изменилось.
Для симфони жестких оптимизаций несколько:
— APC
— Он же для всякого мелкого кеша вроде автолоада, DQL
— Memcache для доктриновского result cache и хороший алгоритм его инвалидации
— Проверьте как у вас настроен логгер и что падает в лог апача
— Хорошо настроенный HTTP cache. ESI с reverse proxy мы пока не используем, но для начала хватает стандартного AppCache
— Если много рутов, можно покопаться в нете и найти для них Apache Dumper. Dumper создаст по рутам htaccess правила.
— Когда устоится схема БД, пересмотреть связи в доктрине. Тут правило одно — как можно меньше bidirectional связей и событий. У доктрины есть в доках немного про оптимизацию
— Если можно на странице обойтись голыми данными, пусть их доктрина и возвращает. Большой объект с множеством связей создается долго, простой массив — быстро.
— События ядра симфони тоже стоит использовать с умом
Я бы посоветовал прогнать ключевые страницы через какой-нибудь профилировщик. Симфони достаточно гибок, поэтому быстрым из коробки быть не может. Но и медленным я бы его не назвал. По опыту могу сказать, часто проблемы в медленных клиентских скриптах и слишком тяжелой разметке и стилях. PHP скрипт отрабатывает достаточно быстро.