Оправдано ли в вашем случае использование JMS как транспорта для выгружаемых данных? Не возникнут ли проблемы с памятью если объем данных резко вырастет?
Пошло сравнение BTrace с методом «держать jvm в дебаге» для разбора проблем.
Но так как BTrace так же не помощник если сервера не доступны — см. «10тыс км и кучей фаирволов», то не понятно высказанное возражение.
PS: BTrace взял на вооружение. Статья — хороший кик старт.
И тогда ДАЖЕ полный рефакторинг это не «переписать все с нуля», а «взять за основу», «создать аналог с использование другого подхода\архитектуры\библиотек» и т.д. Это позволит подойти к процессу еще более прагматично и эффективно.
PS: акцент не на полном рефакторенге, а на его примере — как может измениться отношение.
Единственное хотелось упомянуть еще о таком моменте. Разработчики, особенно молодые, мало работающие в Команде (с большой буквы) часто очень категорически оценивают старый код в виде плохой\хороший. И норовят очень много зарефаторить\переписать. И тут как мне кажется дело не только в нецелевом, раннем и других видах рефакторинга. Важную роль играет отсутствие связи кода с контекстом в котором он разрабатывался. Код писался же не сам по себе. Он пишется всегда в контексте и совокупности имеющихся у нас ограничений и с целью выполнения конкретных задач.
Ограничения, например, могут быть:
— по времени (ранний прототип, показ, пресейл, перегруз команды\разработчика)
— по использованию доступных библиотек\языков и т.д. (тех инструментов что есть сейчас могло не быть, они могли быть не доступны\под запретом)
— опыт разработчика (по своему опыту — свой прошлый код (цать времени назад) всегда найду где зарефакторить)
При этом код на то время выполнял поставленные задачи. В то время могли отсутствовать планы о модернизации, текущее видение развития архитектуры или их нивелировали вышеописанные ограничения. Код исправно, хотя и неоптимально с текущей точки зрения, но работал. И в текущей ситуации у нас может, например, не быть ограничений на железо и он может продолжать работать ибо есть более приоритетные задачи\цели.
В итоге рассматриваемый код надо классифицировать по менее эмоциональной шкале плохой\хороший. А все эмоциональное стремиться к категоричности — переписать полностью :) Гораздо правильней использовать более конструктивную шкалу: подходит, слабо подходит или не подходит под текущие требования (в том числе и к написанию\оформлению кода). И тогда полный рефакторинг это не «переписать все с нуля», а «взять за основу», «создать аналог с использование другого подхода\архитектуры\библиотек». Это позволит подойти к процессу еще более прагматично и эффективно.
Всегда пожалуйста. Документация у них не из подробных, да. Например свой SPI (способ создавать и регистрировать собственные распределенные объекты) анонсировали уже скоро год как, а описания до сих пор нет. Но благо есть открытый код. За что и любим опенсурс :)
Иногда, особенно после тренингов, тестировщики увлекаются поиском каверзных значений при которых не работает функционал в ущерб проверки success сценариев. Радуются как дети если нашли что. А при этом основной функционал не работает по итогам.
Не согласен с выводом что юнит тесты не обязательны. И видимо другие виды что пишет разработчик. Предположу что автор не сталкивался с большими и сложными проектами где очень много кода и система не находится в состоянии покоя — не сделал и сдал заказчику а постоянно эволюционирует. Вот где изменения без тестов рушат все и сразу.
С итерациями как то все тоже неоднозначно. Стараюсь использую итерации от пары недель до месяца-полтора но не больше. Никогда не получалось загнать их в рамки одного интервала. Характер и сложность работ очень варьируются. Отсюда не очень получается использовать прогноз, к пример 20% на следующие итерации или весь проект. Но чем больше не уложились или уложились, тем больше повода задуматься и перегруппировать задачи, приоритеты или ресурсы, это да.
Спасибо, интересно. Хорошо показывает что чистая математика (метод трех оценок) не достаточна а стремление дойти до 90% вероятности по описанной вами методики будет скорее всего вылетать за разумные рамки (ожиданий, бюджета и т.д.).
Заставило задуматься а как сам то ожидания строю. На вскидку получается что точность оценки у всех людей разная, сложность задач разная, учитывать надо соотнесение сложности и компетенции исполнителей, количество и характер взаимодействий между участниками проекта (цепочки) и внешними лицами, мотивацию участников и наверное это не весь список. Очень много получается факторов по которым наверное трудно построить работающую математическую модель.
Мне кажется это способ ограничения круга возможных сущностей под именем Актер до единственной — связанной с конкретной областью и контекстом — Актор. Легче узнается и воспринимается на слух.
> Это не плохо, когда мы это делаем для увеличения производительности в vert.x например. Но на высоком уровне это мне кажется излишней гибкостью.
Тут подумалось, что это ограничение легко обходится. Можно строить систему из одних только координаторов в терминах Taskurotta. Тогда все актеры будут способны ставить задачи другим. Но мы сами не предполагаем использовать такой подход в разработке.
Данное ограничение можно вынести на уровень архитектурного надзора и договоренностей внутри команды.
Оправдано ли в вашем случае использование JMS как транспорта для выгружаемых данных? Не возникнут ли проблемы с памятью если объем данных резко вырастет?
Для прототипа, конечно, это приемлемо.
Пошло сравнение BTrace с методом «держать jvm в дебаге» для разбора проблем.
Но так как BTrace так же не помощник если сервера не доступны — см. «10тыс км и кучей фаирволов», то не понятно высказанное возражение.
PS: BTrace взял на вооружение. Статья — хороший кик старт.
> для начинающих, используйте готовые пуллы: bonecp, c3p0, apache и тд.
Посмотрите плз исходный код популярных пулов соединений. Уверен, что там вы подчерпнете для себя очень много полезной информации.
PS: акцент не на полном рефакторенге, а на его примере — как может измениться отношение.
Единственное хотелось упомянуть еще о таком моменте. Разработчики, особенно молодые, мало работающие в Команде (с большой буквы) часто очень категорически оценивают старый код в виде плохой\хороший. И норовят очень много зарефаторить\переписать. И тут как мне кажется дело не только в нецелевом, раннем и других видах рефакторинга. Важную роль играет отсутствие связи кода с контекстом в котором он разрабатывался. Код писался же не сам по себе. Он пишется всегда в контексте и совокупности имеющихся у нас ограничений и с целью выполнения конкретных задач.
Ограничения, например, могут быть:
— по времени (ранний прототип, показ, пресейл, перегруз команды\разработчика)
— по использованию доступных библиотек\языков и т.д. (тех инструментов что есть сейчас могло не быть, они могли быть не доступны\под запретом)
— опыт разработчика (по своему опыту — свой прошлый код (цать времени назад) всегда найду где зарефакторить)
При этом код на то время выполнял поставленные задачи. В то время могли отсутствовать планы о модернизации, текущее видение развития архитектуры или их нивелировали вышеописанные ограничения. Код исправно, хотя и неоптимально с текущей точки зрения, но работал. И в текущей ситуации у нас может, например, не быть ограничений на железо и он может продолжать работать ибо есть более приоритетные задачи\цели.
В итоге рассматриваемый код надо классифицировать по менее эмоциональной шкале плохой\хороший. А все эмоциональное стремиться к категоричности — переписать полностью :) Гораздо правильней использовать более конструктивную шкалу: подходит, слабо подходит или не подходит под текущие требования (в том числе и к написанию\оформлению кода). И тогда полный рефакторинг это не «переписать все с нуля», а «взять за основу», «создать аналог с использование другого подхода\архитектуры\библиотек». Это позволит подойти к процессу еще более прагматично и эффективно.
Программирование (Java), распределенные системы.
www.facebook.com/romario.roman.75
taskurotta.org/
Иногда, особенно после тренингов, тестировщики увлекаются поиском каверзных значений при которых не работает функционал в ущерб проверки success сценариев. Радуются как дети если нашли что. А при этом основной функционал не работает по итогам.
Не согласен с выводом что юнит тесты не обязательны. И видимо другие виды что пишет разработчик. Предположу что автор не сталкивался с большими и сложными проектами где очень много кода и система не находится в состоянии покоя — не сделал и сдал заказчику а постоянно эволюционирует. Вот где изменения без тестов рушат все и сразу.
Заставило задуматься а как сам то ожидания строю. На вскидку получается что точность оценки у всех людей разная, сложность задач разная, учитывать надо соотнесение сложности и компетенции исполнителей, количество и характер взаимодействий между участниками проекта (цепочки) и внешними лицами, мотивацию участников и наверное это не весь список. Очень много получается факторов по которым наверное трудно построить работающую математическую модель.
Тут подумалось, что это ограничение легко обходится. Можно строить систему из одних только координаторов в терминах Taskurotta. Тогда все актеры будут способны ставить задачи другим. Но мы сами не предполагаем использовать такой подход в разработке.
Данное ограничение можно вынести на уровень архитектурного надзора и договоренностей внутри команды.
Это с монгой и без оракла.
Это чистый hazelcast — без монги и оракла.