пользуемся activeCollab — тул очень неудобный и не фукциональный, разве что рюшечек много. Кроме того парни поперепутывали все понятия. Пользуемся только из-за того, что за него нашальник заплатил 400 баксов
одного понять немогу, почему с клиента резидента нужно брать за выполненную работу в долларах? Вы что какой-то товар покупаете за доллары? Зарплату та платят в нац валюте.
честно скажу как-то не впечатлило: много людей в одной комнате — это наверняка галдеж. В рабочих комнатах окон почти нету. Рабочие комнаты похожи на камеру.
юнит тесты не увеличивают качество кода! Они просто позволяют его в будущем дешевле изменять bishop-it.ru/?p=119
Например, Michael Feathers в своей книге Working Effectively with Legacy Code не призывает покрывать все 100% кода тестами. Мало того, он даже не призывает всегда покрывать тестами код, который вы собираетесь изменять. Он призывает думать. Каждый раз делать осознанный выбор — нужны ли вам в данном месте юнит тесты или нет. Всем советую купить и прочитать эту его книгу. Эта книга — лучшее описание теории и практики написания юнит тестов, что я встречал. Причем именно с точки зрения практики — большая часть книги посвящена описанию стандартных приемов работы со старым кодом. А сам автор имеет огромный практический опыт по улучшению legacy кода.
да согласен, но он увеличивает время разработки и уменьшает время на потдержку. Кроме того, бытует мнение что юнит тесты нужно применять только там где они нужны.
В общем при сдоровой конкуренции (фриланс) в основном выигрывает тот, кто сделает быстрее (ну и качественней), но клиент конечно же в код не лезет и понятное дело, что ему чем быстрее, тем лучше. И объясняй ему что такое юнит тесты и что это ему даст.
доступно написано. Все сам хочу использовать (пишу на cakephp ) но клиенты никак немогут понять почему я буду делать таски дольше и они будут платить больше.
да нормальный магаз! полазил по нему минут 10 — меня лично ничего не раздражает. Да это конечно не идеал но многим магазам еще и фору даст. так что не вибрируй и выше голову
хм интересно, откуда же при таком, как вы показали графике учтенного времени, у вас деньги берутся. Я бы тоже хотел столько времени тратить на болтовню блоги и чтение
тогда все становится более понятным. Ну что вариант хорош, еще бы статистических данных бы. Кстати как оказалось BerkeleyDB частоиспользуемая не реляционная БД. Плохо немного то, что юзера хранятся в другой системе, к примеру более сложные поиски по юзерам будут происходить все равно по БД. Вы будете использовать MemcacheDB только когда точно знаете UserID.
я вот еще что подумал, а можно взглянуть на структуру таблиц для юзеров? возможно у вас слишком широкие таблички, в таком случае можно их разбить на несколько более маленьких, допустим по частоте изменения данных
у меня возникли схожие вопросы с Davert вопросы. После прочтения статьи не понял почему проблемы возникли именно на логировании?? пусть, к примеру, у нас 10 000 посетителей в день, из них 50% новых. А из оставшихся 50% будут уже залогированные (вы же ведь сделали чекбокс запомнить меня). итого 50 % на регистрацию и, приблизительно, 10-25% на логирование. Как же так получилось, что логирование пользователей стало бутылочным горлышком? Почему остальной функционал используется меньше?
Еще вопрос, зачем данные пользователя хранить в мемкеше, если их удобней хранить в сессии. И еще вопрос, в мемкеш же не ризиновый и влезут ли 10 миллионов записей туда?
автор не спрашивал совета и никто не писал плохого на автора и его топик. Вы слишком критичны. ему лишь деликатно намекнули, что он пришел к неправильным выводам.
bishop-it.ru/?p=119
Например, Michael Feathers в своей книге Working Effectively with Legacy Code не призывает покрывать все 100% кода тестами. Мало того, он даже не призывает всегда покрывать тестами код, который вы собираетесь изменять. Он призывает думать. Каждый раз делать осознанный выбор — нужны ли вам в данном месте юнит тесты или нет. Всем советую купить и прочитать эту его книгу. Эта книга — лучшее описание теории и практики написания юнит тестов, что я встречал. Причем именно с точки зрения практики — большая часть книги посвящена описанию стандартных приемов работы со старым кодом. А сам автор имеет огромный практический опыт по улучшению legacy кода.
В общем при сдоровой конкуренции (фриланс) в основном выигрывает тот, кто сделает быстрее (ну и качественней), но клиент конечно же в код не лезет и понятное дело, что ему чем быстрее, тем лучше. И объясняй ему что такое юнит тесты и что это ему даст.
А Вы рассматривали вариант с распределнными серверами допустим поставить 3-4 читающих сервера и 1 пишущий?
Еще вопрос, зачем данные пользователя хранить в мемкеше, если их удобней хранить в сессии. И еще вопрос, в мемкеш же не ризиновый и влезут ли 10 миллионов записей туда?