Сериал Черные паруса (Black Sails)

1. С точки зрения мореплавания и отрисовки физики кораблей (они там все компьютерные) - полная ахинея. После пребывания на Штандарте и практического понимания происходящего при просмотре тянуло...за борт. Думаю, что и без Штандарта это видно невооруженным глазом человеку, который хоть чуть понимает природу ветра и движения судна под парусом.

2. Большая часть сцен происходит на берегу. Из них еще 50% - "постельные" сцены. В кавычках, потому как происходит это везде. Из около 8 часов видео (8 серий сезона по примерно 1 часу) действий в море от силы 40 минут.

3. Много трепотни и разглагольствований

4. Цельный сюжет, связывающий все серии

5. Как и во всех сериалах, если у героев все наладилось, значит сейчас начнется еще ж*па, а если проблемы не большие, значит добавятся еще.

6. Хорошая музыка

7. Развитая линейка персонажей со своими целями и задачами, как следствие: куча всего происходящего одновременно

8. Флинт (и происходящее в непосредственной близости от него) выглядит слишком идеальным на фоне его проблем.

9. Основные действия происходят на острове Нассау

Итого: интересно увидеть развязку основного события, но для этого приходится смотреть 8 часов довольного нудной трепотни. Но даже, если посмотреть последнюю серию - будет ждать разочарование, называемое "to be continued...". Для понимания сути и основного сюжета достаточно посмотреть 1,2 и 8 серии.

Занимательные алгоритмы. Поиск цикла в односвязном списке

И снова про тараканов, которые иногда возникают в голове. Как-то раз, засыпая, я задумался на курьезными задачками из своей сферы деятельности (Lotus Notes), которые можно было бы задать на собеседовании, плавно перешел к воспоминаниям о своих первых собеседования, когда опыта работы еще не было. Опыт самих собеседований у меня не велик а места, где задавались действительно интересные задачи (а не задачки типа: написать сортировку массива любым известным способом) вообще равны одному - это ABBYY. Как минимум одна задачка в списке на знание и понимание классических алгоритмов, описанных в книге Дональда Кнута - Искусство программирования .

Unit-testing object validation when validator has DI

Summary Unit test object validation when validator(s) has a dependency. For instance, we have some custom field and cross-field validators. Want to test their combination. Additionally some of validators have dependencies, injected through constructor or setters. You're not using property injection, right? Shortcut If you are just searching for an answer, here's the fast way: Declare CustomConstraintValidatorFactory that implements javax.validation.ConstraintValidatorFactory Override getInstance method and on facing your constraint validator class instantiate it Otherwise delegate validator construction to org.hibernate.validator.internal.engine.constraintvalidation.ConstraintValidatorFactoryImpl Build validator factory and provide it your CustomConstraintValidatorFactory Build validator, using that factory... Go to demo project on GitHub for details: https://github.com/MrArtemAA/blog-demos/blob/master/test-validator-with-injection/src/test/java/ru/artemaa/...

Use @SpringBootTest for validator's unit test and be fast enough

This a continuation of the post: https://live-scripts.blogspot.com/2020/02/unit-testing-object-validation-with-di-in-validator.html#more . Last time we talked about testing a validator, which has a dependency. Using pure @SpringBootTest turned out to be too slow. So I showed a "trick" to override the validator's factory in order to inject the dependant object. This reduced test run time. I promised to show a way to use @SpringBootTest , autowiring, and still be quick enough.

Live Scripts

Поиск по этому блогу