Как стать автором
Обновить
14
-1
Дмитрий Б @mypanacea87

Разработчик

Отправить сообщение

Автор описал практически всю мою боль касательно ВК, тоже жил там годы, тоже собирал музыку, в итоге я ушел за музыкой на ютуб, за общением в телеграмм и твиттер. Ощущения и эпитеты упомянутые в статье полностью разделяю

Коллеги, доброго времени суток, перечитал комменты, не нашел ни одного на тему а есть ли какая то бронь для айтишников, которые работаю в акредитованой компании? Вроде бы как госдума должна сделать разъяснения на эту тему, на сайте https://texterra.ru/blog/otsrochka-ot-armii-dlya-ajti-kto-ee-poluchit-i-budet-li-mobilizaciya-ajtishnikov.html написано что нет, но информация не внушает доверия, может у кого то есть информация на этот счет от работодателей? Мой работодатель на мой вопрос на эту тему сказал что ждут ответ сверху

спасибо за комментарий, лично меня проняло, есть о чем задуматься…
Да, во многом нам везет, а людям которым случайно погибают, по нелепым причинам не везет, тут я с вами согласен, но если не создавать предпосылки, то везения не произойдет. Мое мнение что в чем то это везение, процентов на 20, а остальное это труд, который рано или поздно чем то ознаменуется
Оглядываясь назад я бы назвал две причины, что мешало мне заняться карьерой(в контексте моего случая программированием):
Чувство зоны комфорта и плевать что сомнительного…
Совершенно отчетливое представление что у меня не хватит мозгов, мой одногруппник, разработчик — гений. Я ему так и говорил, он смеялся и говорил что мне кажется, и там где сейчас работает он много таких же гениев.
Ну и страх увольнения с текущей работы, пускай захудалой, но стабильной и не пройти исп срок на новой, а у тебя ипотека. Надо для такого случая готовить финансовую подушку, на случай если что то пойдет не так… у меня ее не было, и это не добавляло ощущения стабильности и уверенности в себе, наверное мне во многом повезло, с одногруппником, с коллегами ну и с моей упертостью, я очень много раз хотел бросить заниматься, загрузить варкрафт и открыть пиво, поначалу я себя заставлял
друг по секрету сказал мне, что скоро переедет для начала поближе к Европе)))Москва или Питер
Я с вами согласен, в моей жизни есть фитнес, волейбол, личная жизнь, но тем не менее самообразованию я уделяю много времени, это засасывает, в какой то момент тебе начинает казаться что сегодня ты мало времени уделил развитию и ты стремишься это скорей исправить, это наркотик, но мне он нравится. Если не в ущерб семье и здоровью, то почему бы и нет, я считаю
Интеграционное тестирование через MockMvc из «Недостаток 10» можно совместить с темой профилей из «Недостаток 8» и соорудить отдельно:
1. интеграционные тесты, которые смотрят на моковые XML для Soap запросов и какую то in memory DB
2. функциональные тесты, которые через настройки профиля обращаются уже к реальным системам.
а как Ваша хука внтутри работает не думали? а самому написать не хотелось? CI это хорошо, но тот же SOnar требует явного тестирования аннотаций, а не наличия аннотаций. Если бы вы писали JVM мне страшно подумать как бы осуществлялась верификация в байткод, например
А ко всем остальным минусерам, без аргументов, поражает ваше стадное чувство.
Как только я опубликовал статью, в ту же секунду кинул ее в один из своих чатов в телеграм, в ту же секунду появился первый просмотр и первый минус, то есть даже прочитать название до конца было нереально. Ну а дальше стадное чувство сработало. Спасибо sshikov, что остановили это бред.
то то и оно, статья не руководство к действию, а лишь повод и средство более детально понять как работают аннотации, как рефлексия и прокси на объекты.
Автору выше, который с юными коллегами: а Вы Spring тоже брезгуете юзать? или предпочитчаете юзать не думая, что внутри него есть рефлексия или Вам приятно думать что аннотация работает сама по себе?
Это небольшой тестовый фреймворк, даже если конкретно эта задача Вам кажется фейковой, все то что в ней использовано — используется в джавовых фреймворках.
Это «громозлкое решение» — это 180 страниц кода и один класс, странное у вас представление о громоздкости. Попробуйте сломать, это «хрупкое решение». И это тест, утилька для того чтобы убрать повторение кода по вашим тестам. Да, мне не кажется что это самые полезные тесты, на аннотацию @NonNull, но мой тим лид требует тестить, дальше что? Странно, что при всем Вашем опыте, Вы не знаете, что проекты разные бывают и требования на них те же, хотя судя по пафосу, предположу что вы сидите 10 лет на одном проекте и брызжете пафосом на более молодых колег.
P.S наверняка со своей принципиальностью в общем потоке просмотрели как не ок, так и годные идеи.
P.S.S Я бы вас с удовольствием отревъювил. Со всеми выкладками на доки и мировые best practices.
думаю что вопрос насколько оправдано использование того или иного фремворка — вопрос относительный, все зависит от сложности скорее всего. Для несложных задач, скорее всего не стоит использовать, вы скорее всего усложните на ровном месте… но вот для более сложных эта штука становится серьезным подспорьем, попробуйте реализовать какой нибудь многоступенчатый сложный процесс без паттернов(например процедуру оформления дистанционного кредита), это будет сложно и запутанно, вы сами начнете думать в сторону какого то паттерна, а тут уже готовое решение. Машина в первую очередь это архитектурное решение.
Если вы свою задачу декомпозировали и разложили на концепцию машины, то почему бы и нет.
Допустим вы находитесь в статусе RESERVED, совешаете покупку, летит Event по которому должно произойти списание денег, и переход в статус BUY, логика на списание заложена в неком Action, вы делаете метод на списание транзакционным, навешиваете Action в конфигурации States, я в статье писал про этонемного, так вот, там сработка Action будет немного по другому, вы сначала зайдете в статус, а уже потому выполнится ваш транзакционный метод, если вдруг в нем случится ошибка машина вернется в предыдущее состояние, и списания не произойдет. Там разные комбинации на который можно навешивать ваши Action, stateEntry, stateExit, state, то есть можно настроить так, чтоб перестраховаться от того что вы упали сразу после списания
мне кажется то о чем вы говорите нарушает концепцию машины в целом, если машина была остановлена, и вы после этого бросили эвент, то он не должен ее касаться, то есть у вас явно что то не по плану пошло, вы можете проверять стутус машины после восстанновления, и выставлять его принудительно в тот какой вам нужно, но это уже какое то костыльное решение имхо будет
Основное преимущество описанного мной подхода в том что это будет возможность протестировать машину через unit-тест, а не через интеграционный или функциональный, если у вас в интеграционном тесте перед каждым тестом в тестовом профиле накатываются схемы в БД, таблицы и прочее прочее прочее, то ваши интеграционные тесты со временем нормально так затягиваются, и вы точно предпочтете тестировать через Unit, если будет такая возможность
Доброго времени суток. Про Message совершенно верно подметили, есть такая возможность, но нам показалось более удобным передавать информацию через контекст. По поводу Action у нас появилось понимание довольно быстро, как только стало ясно что в конфигурации tarnsition можно навешивать много экшенов на один переход.
Статья была Ваша, извиняюсь если чем то обидел, поверьте, даже в мыслях не было. А так, ваш проект получается третий из тех что я знаю(наш, ваш, и еще в Nexign) где спринг стейт машина работает на проде.)
у нас в проекте был реализован паттерн State, сложновато конечно выглит(много дженериков), но работает как часы и добавление новой логики на разных этапах нашего бизнес кейса получилось довольно простое и прозрачное. Когда пришла очередь добавлять StateMachine для другого кейса, я точно с таким же удивлением как и вы обнаружил что есть решение от Spring. Ну и на нашу логику все просто идеально легко, так что по сторонам уже даже и не смотрели, у нас намечается третий кейс в проекте, который так же будет решаться Spring машиной, и вот огромным плюсом будет то, что вы сможем часть компонентов из предыдущей машины задействовать. Машина по сути это именно некий каркас в вашей бизнес-логике, вы можете в нее заинжектать любые сервисы, которые дергали бы из if-ов.
Добрый день. Тут будет зависеть от scope машины, если она singleton, и она находится в каком то промежуточном статусу, то она будет находиться в нем до тех пор пока не остановится спринговый контекст, либо пока вы явно не скажете ей .stop()(после этого она перейдет в конечное состояние, которое вы закодировали). В случае если вы получаете машину из фабрики, то при каждом обращении к сервису будет создаваться новая машина, соответственно при каждом запросе вы сохраняете ее состояние в базу или в Map, как у меня в примере, а при повторном запросе восстанавливаете ее, то есть если машина в промежуточном состоянии и у вас настроен персистинг, то вы вернетесь в то же самое промежуточное состояние.
вам кажется, в проекте есть шаблон error.html который и будет загружен, про полную версию кода вы придумали сами, я такого не писал, я привел примеры ключевых файлов, в которых некоторые методы todo, чтоб показать общую тенденцию происходящего, Вы же во первых это не заметили, во вторых не прочитали поясняющий комментарий на свой первый вопрос. Вы не поняли о чем эта статья(что может быть как виной автора, так и виной читающего).
спасибо, только увидев название: мне уже интересно.
1

Информация

В рейтинге
Не участвует
Откуда
Екатеринбург, Свердловская обл., Россия
Зарегистрирован
Активность