Да, у Kannel релизов не было давно, но тот же Jasmine вполне себе ещё живой судя по github. Да и не понятно, в чем по вашему разница. Разбираться и править библиотеку jsmpp или же разбираться и править тот же Jasmine например. Баги есть и там и там.
А почему не воспользовались шлюзом? Jasmine или Kannel? На мой взгляд работать с REST API куда приятнее и проще, чем разбираться во всех тонкостях SMPP. Пусть и используя при этом уже готовую java-библиотеку.
Этот вариант обязывает Вас переводит сообщение в байты, после чего делить их на подсообщения и в первых битах указывать их нумерацию и количество. Будет весело.
Я вот ровно об избавлении от всего этого веселья. Так как шлюз на себя берет реализацию всех этих нюансов
Разбиение на части длинных сообщений
Борьба с кодировками
Дозирование нагрузки на SMPP канал за счёт очереди
Асинхронные callback'и при ответах от SMPP. Например отчёты о доставке SMS.
Сохранение истории отправки SMS в каком-нибудь хранилище.
В семилетней статье нету, например, описания что такое служебная подобласть (Supporting Subdomain). Этого нету и в DDD Quickly.
В вашем случае служебная подобласть не тоже самое, что GENERIC SUBDOMAINS? О которых рассказывается и в оригинальной книге Эванса и упоминается в InfoQ (что логично, учитывая что это просто краткое содержание оригинала)? Из вашего описания, я не увидел между ними никакой разницы, если объясните, буду признателен.
Я возможно что-то упускаю из виду. Скажите, в этой статье есть что-то, чего нет в The Big Blue Book Эванса или в той же книге Вернона, на которую вы сами ссылаетесь? Или в материалах, перечисленных в этой статье https://habrahabr.ru/post/61524/ семилетней давности?
Сначала обрадовался заголовку в ленте. Ожидал разбора классных кейсов в нестандартных доменах. А ощущение, что почитал ещё ужатый InfoQ: DDD Quickly.
Магии с класслоадерами не избежать и в OSGi, в том смысле что он там не один и это тоже нужно понимать. Но всё-таки магия OSGi больше походит на белую, а не на черную, это стоит признать.
О какой версии Liferay идет речь? Не было в планах выложить в OpenSource ваш микрофреймворк для написания портлетов с использованием Spring MVC и Closure Templates?
Люди из разных источников черпают информацию. Кому-то проще прочитать целую книгу, а кому-то через поисковик найти статью по нужной теме. Да, в «Изучаем Java EE 7» целая глава посвящается CDI и в ней гораздо больше информации, чем в цикле из этих трех статей. Но ведь после опубликования своей книги Antonio не удалил статьи из своего блога за ненадобностью. Пусть не многим, но кому-то эти статьи могут показаться полезными.
Ну например в IDEA и он не нужен, там автосохранение :) Но если взять тот же ctrl+s, то люди тоже не сразу к нему пришли. Пару раз весь набранный текст исчезнул в след за крешем редактора или оси и начали чаще сохранять.
Думаю аналогичная история есть и у сторонников очень частых коммитов. Пару раз стоит потерять отличную наработку (изначально таковой не казавшуюся) не сделав промежуточный коммит и личный рабочий процесс немного меняется. Мне правда сложно судить, так как я не считаю себя столь уж частым коммитером. Но учитывая продвинутость современных инструментов разработки могу точно утверждать, что накладные расходы на частые коммиты минимальны — хоткей в IDE и коммит готов.
Вы правда считаете, что стоит навязывать разработчику формат работы с локальным репозиторием? Лично мне всё равно, что делает разработчик моей команды со своим локальным репозиторием, если результат при этом удовлетворяет всем командным договоренностям.
Мне кажется в комментарии VladimirAndreev речь не шла про однострочные коммиты. Это был абсолютно искуственный пример, демонстрирующий правило "commit frequently". Если разработчику удобнее и привычнее делать десяток коммитов в день, то почему нет.
Мне кажется VladimirAndreev имел ввиду, что в одном коммите будет реализована функция подсчета видимых звезд, а потом будут 50 отдельных коммитов, в которых будут правиться соответственно 50 мест, в которых эта функция требуется.
Просто не вижу, как это может быть связано с грязной историей.
В контексте этой ветки коментариев речь идет о том, что когда вы тестируете бранч, не являющийся линейным продолжением текущего состояния проекта, то вы потенциально тестируете бранч с конфликтами. Если тестирование например ручное или автоматизированное, но долгое, то очень дорого обойдется вам это тестирование, так как после разрешения конфликтов нужен будет полный ретест. Поэтому многие стремятся как можно быстрее избавляться от конфликтов, используя мерж или, как в описанном в этой статье флоу, ребейз.
3) Его разве не проще просматривать в трекере задач?
Куда-то совсем не туда. Прочитайте пункт 4 из этого комментария ещё раз. В данном случае речь идет именно об этом изменении скоупа. Утром заказчику нужна поставка с фичами А и Б, а к обеду он уже хочет А, Д и выкинуть поставленную вчера В.
На дерево не смотрел ни разу, если не считать случаев из любопытства.
GUI представление, ни что иное, как визуализация операции git log. Пользовались им, значит смотрели дерево. В какой программе вы на него смотрели, SourceTree или консоль, это не так важно.
возможно у вас слишком перенасыщенные классы
Описываемый в статье флоу потребовался команде из нескольких десятков человек. Из сухой статистики: проекту 4 года, чисто тикетов перевалило за 15К, а число строчек кода уже давно за миллион. В этих условиях могу с уверенностью утверждать, что каких только классов у нас нет, в том числе полно перенасыщенных :))
Не особо понимаю практический смысл такой чистой истории. Если вам не сложно, не могли бы вы пояснить его?
Не совсем понимаю, что конкретно требует пояснения. Старался сделать в это в самой статье, включая ссылки на сторонние статьи. Да и в комментариях уже много информации. Если конкретизируете вопрос по непонятному моменту, постараюсь прокомментировать.
1) Какое событие инициирует тесты? (вы ведь про ci?)
Ну это очень зависит от команды и проекта. У кого-то тесты работают несколько часов и их запускают по крону. У кого-то все тесты проходят за несколько секунд и можно прогонять их после каждого коммита.
2) Используйте номер таска в названии коммита.
Хорошая практика. В своей команде мы её используем.
3) Какую информацию предоставляет «частое изменение скоупа, полученное из истории гита»?
Никакую. Частое изменение скоупа влечет за собой активную работу с бранчами, откуда возникает потребность выполнять эту работу с минимальными сложностями за минимальное время.
Я просто не встречал ситуацию на практике, когда мне нужно было использовать графическое представление истории.
Вы действительно никогда не пользовались командой git log? На мой взгляд это достаточно странно, хотя быть может каким-то командам в их процессах оно действительно не требуется. Главное ведь, чтобы командная работа была эффективной и без боли :)
Все так. И если на историю просто смотреть, то фильтров отображения будет более чем достаточно. Но бывает так, что команде приходится часто манипулировать коммитами из истории. И тогда сложно отрицать, что revert/cherry-pick отдельного коммита заметно проще и занимает меньше времени, по сравнению с аналогичными операциями для merge-коммитов.
Мои действия очевидны — ручная кропотливая работа. Когда речь заходит об изменениях скоупа, которые затрагивают зависимые друг от друга изменения, то тут никакой flow не спасет от ручной работы. Поэтому речь всё-таки шла больше о логически атомарных изменениях.
В любом случае для принятия какого-то flow на вооружение команды, его нужно пропускать через призму многих факторов, в том числе и внешних. Когда я писал, что "серебряной пули нет", я не лукавил. Так же как и GitFlow, я не считаю Rebase Flow идеальным. У получаемых возможностей всегда есть цена и риски, о которых нужно знать. Приведенные вами примеры тому подтверждение.
За ссылки спасибо. Хотя я больше сторонник превентивных мер воздействия :) Когда же дело дошло до bisect, то тут хорошего мало, как на это не посмотри.
Вы правы, чистая история конечно же не может быть самоцелью и для нас она таковой не являются. На мой взгляд ситуация такова.
Есть потребности (они же цели):
Тестировать актуальную версию исходного кода
За минимальное время находить информацию, являющуюся причиной изменения исходного кода
Иметь возможность быстро реагировать на частые изменения скоупа
Есть средство, гарантирующее удовлетворение обозначенным потребностям — это чистая история. На собственной практике мы убедились, что она действительно это гарантирует.
И есть инструменты (rebase, squash и т.д.), позволяющие организовать чистую историю.
На мой взгляд очень даже пользуемся. На code review уходит именно feature-бранч. А в команде из нескольких десятков разработчиков у большинства даже прав нет на пуш в develop.
Да, у Kannel релизов не было давно, но тот же Jasmine вполне себе ещё живой судя по github. Да и не понятно, в чем по вашему разница. Разбираться и править библиотеку jsmpp или же разбираться и править тот же Jasmine например. Баги есть и там и там.
А почему не воспользовались шлюзом? Jasmine или Kannel? На мой взгляд работать с REST API куда приятнее и проще, чем разбираться во всех тонкостях SMPP. Пусть и используя при этом уже готовую java-библиотеку.
Я вот ровно об избавлении от всего этого веселья. Так как шлюз на себя берет реализацию всех этих нюансов
В вашем случае служебная подобласть не тоже самое, что GENERIC SUBDOMAINS? О которых рассказывается и в оригинальной книге Эванса и упоминается в InfoQ (что логично, учитывая что это просто краткое содержание оригинала)? Из вашего описания, я не увидел между ними никакой разницы, если объясните, буду признателен.
Я возможно что-то упускаю из виду. Скажите, в этой статье есть что-то, чего нет в The Big Blue Book Эванса или в той же книге Вернона, на которую вы сами ссылаетесь? Или в материалах, перечисленных в этой статье https://habrahabr.ru/post/61524/ семилетней давности?
Сначала обрадовался заголовку в ленте. Ожидал разбора классных кейсов в нестандартных доменах. А ощущение, что почитал ещё ужатый InfoQ: DDD Quickly.
А не было опыта использования компонент из PrimeNG? На сколько они вообще пригодны или есть куда более продвинутые наборы компонент?
Магии с класслоадерами не избежать и в OSGi, в том смысле что он там не один и это тоже нужно понимать. Но всё-таки магия OSGi больше походит на белую, а не на черную, это стоит признать.
О какой версии Liferay идет речь? Не было в планах выложить в OpenSource ваш микрофреймворк для написания портлетов с использованием Spring MVC и Closure Templates?
Люди из разных источников черпают информацию. Кому-то проще прочитать целую книгу, а кому-то через поисковик найти статью по нужной теме. Да, в «Изучаем Java EE 7» целая глава посвящается CDI и в ней гораздо больше информации, чем в цикле из этих трех статей. Но ведь после опубликования своей книги Antonio не удалил статьи из своего блога за ненадобностью. Пусть не многим, но кому-то эти статьи могут показаться полезными.
Ну например в IDEA и он не нужен, там автосохранение :) Но если взять тот же ctrl+s, то люди тоже не сразу к нему пришли. Пару раз весь набранный текст исчезнул в след за крешем редактора или оси и начали чаще сохранять.
Думаю аналогичная история есть и у сторонников очень частых коммитов. Пару раз стоит потерять отличную наработку (изначально таковой не казавшуюся) не сделав промежуточный коммит и личный рабочий процесс немного меняется. Мне правда сложно судить, так как я не считаю себя столь уж частым коммитером. Но учитывая продвинутость современных инструментов разработки могу точно утверждать, что накладные расходы на частые коммиты минимальны — хоткей в IDE и коммит готов.
Вы правда считаете, что стоит навязывать разработчику формат работы с локальным репозиторием? Лично мне всё равно, что делает разработчик моей команды со своим локальным репозиторием, если результат при этом удовлетворяет всем командным договоренностям.
Мне кажется в комментарии VladimirAndreev речь не шла про однострочные коммиты. Это был абсолютно искуственный пример, демонстрирующий правило "commit frequently". Если разработчику удобнее и привычнее делать десяток коммитов в день, то почему нет.
Мне кажется VladimirAndreev имел ввиду, что в одном коммите будет реализована функция подсчета видимых звезд, а потом будут 50 отдельных коммитов, в которых будут правиться соответственно 50 мест, в которых эта функция требуется.
В контексте этой ветки коментариев речь идет о том, что когда вы тестируете бранч, не являющийся линейным продолжением текущего состояния проекта, то вы потенциально тестируете бранч с конфликтами. Если тестирование например ручное или автоматизированное, но долгое, то очень дорого обойдется вам это тестирование, так как после разрешения конфликтов нужен будет полный ретест. Поэтому многие стремятся как можно быстрее избавляться от конфликтов, используя мерж или, как в описанном в этой статье флоу, ребейз.
Куда-то совсем не туда. Прочитайте пункт 4 из этого комментария ещё раз. В данном случае речь идет именно об этом изменении скоупа. Утром заказчику нужна поставка с фичами А и Б, а к обеду он уже хочет А, Д и выкинуть поставленную вчера В.
GUI представление, ни что иное, как визуализация операции git log. Пользовались им, значит смотрели дерево. В какой программе вы на него смотрели, SourceTree или консоль, это не так важно.
Описываемый в статье флоу потребовался команде из нескольких десятков человек. Из сухой статистики: проекту 4 года, чисто тикетов перевалило за 15К, а число строчек кода уже давно за миллион. В этих условиях могу с уверенностью утверждать, что каких только классов у нас нет, в том числе полно перенасыщенных :))
Не совсем понимаю, что конкретно требует пояснения. Старался сделать в это в самой статье, включая ссылки на сторонние статьи. Да и в комментариях уже много информации. Если конкретизируете вопрос по непонятному моменту, постараюсь прокомментировать.
Ну это очень зависит от команды и проекта. У кого-то тесты работают несколько часов и их запускают по крону. У кого-то все тесты проходят за несколько секунд и можно прогонять их после каждого коммита.
Хорошая практика. В своей команде мы её используем.
Никакую. Частое изменение скоупа влечет за собой активную работу с бранчами, откуда возникает потребность выполнять эту работу с минимальными сложностями за минимальное время.
Вы действительно никогда не пользовались командой
git log? На мой взгляд это достаточно странно, хотя быть может каким-то командам в их процессах оно действительно не требуется. Главное ведь, чтобы командная работа была эффективной и без боли :)Все так. И если на историю просто смотреть, то фильтров отображения будет более чем достаточно. Но бывает так, что команде приходится часто манипулировать коммитами из истории. И тогда сложно отрицать, что revert/cherry-pick отдельного коммита заметно проще и занимает меньше времени, по сравнению с аналогичными операциями для merge-коммитов.
Мои действия очевидны — ручная кропотливая работа. Когда речь заходит об изменениях скоупа, которые затрагивают зависимые друг от друга изменения, то тут никакой flow не спасет от ручной работы. Поэтому речь всё-таки шла больше о логически атомарных изменениях.
В любом случае для принятия какого-то flow на вооружение команды, его нужно пропускать через призму многих факторов, в том числе и внешних. Когда я писал, что "серебряной пули нет", я не лукавил. Так же как и GitFlow, я не считаю Rebase Flow идеальным. У получаемых возможностей всегда есть цена и риски, о которых нужно знать. Приведенные вами примеры тому подтверждение.
За ссылки спасибо. Хотя я больше сторонник превентивных мер воздействия :) Когда же дело дошло до bisect, то тут хорошего мало, как на это не посмотри.
Вы правы, чистая история конечно же не может быть самоцелью и для нас она таковой не являются. На мой взгляд ситуация такова.
Есть потребности (они же цели):
Есть средство, гарантирующее удовлетворение обозначенным потребностям — это чистая история. На собственной практике мы убедились, что она действительно это гарантирует.
И есть инструменты (rebase, squash и т.д.), позволяющие организовать чистую историю.
На мой взгляд очень даже пользуемся. На code review уходит именно feature-бранч. А в команде из нескольких десятков разработчиков у большинства даже прав нет на пуш в develop.
На мой взгляд все иначе. И статья и мой комментарий рассказывают именно о том, как покрыть возникшие потребности используя возможности git'а.
"Так исторически сложилось. " ©
Когда-то давно, когда не было никаких github и все радовались gitosis, прошла успешная миграция с SVN на Git. А сейчас причин для очередной миграции просто нет, так как возможности git'а полностью покрывают все потребности командной работы.