Никак нет, так как я не знаю глубину курса, его качество и т.д. Список технологий очень хороший и актуальный. Из Европы цена выглядит смешной, но равняться нужно на местный рынок.
А еще у нас в России любят критиковать много, в Европе люди намного мягче. Вот и уважаемый Lany нашел недочеты. Я же помню, сколько я усилий потратил, чтобы привести древний курс в более-менее достойный и актуальный вид, это адский труд. Поэтому поддерживаю вас в ваших начинаниях :)
Стоимость космос? 700 евро за 5 месяцев: Вы шутите? Вы посмотрите, сколько возьмут за такой курс за рубежом — будете приятно удивлены. Для примера — я преподаю в Ирландии курс java для новичков — за 52 часа (~2+ месяца) стоимость составляет 1200 евро. Причем курс был не фонтан, мне пришлось многое менять и добавлять, чтобы сделать его ближе к реальному рынку. Этот курс же охватывает все актуальные технологии и фреймворки, очень даже симпатично
Ну это уже другая тема, комбинаторный взрыв называется, первый признак, что наследование желательно заменить другими паттернами типа Bridge или Decorator.
Просто применительно к первому примеру со стримом, который сделали readonly через бросание эксепшна и тем самым нарушили LSP — чинится легко для простого случая с двумя методами. В-целом, выдерживать LSP не так сложно, если знать некоторые простые правила, особенно по части обращения к внутренним полям суперкласса. Выдерживать LSP относительно реализаций интерфейса проще, если не ломать контракты его методов.
Сорри, маленько не понимаю — если мой метод принимает Stream, который расширяет WriteStream и ReadStream — значит, он умеет делать обе вещи и я могу им пользоваться легко? В случае, конечно, если реализация не бросает UnsupportedOperation в одном из методов, о чем Вы упомянули прежде.
По поводу Stream примера — вроде еще третий путь возможен: вынести read и write методы в отдельные интерфейсы и сделать Stream расширяющим их? В этом случае LSP не ломается.
А вообще очень хорошо сказано, дополню только, что выполнение LSP зависит напрямую от опыта. На моей практике первые пять лет разработчики о нем в лучшем случае не думают, в худшем — попросту не знают. И работают отлично, создают кучу кода, считая себя опытными зубрами. Вот только в последствии всем их наследникам приходится разгребать недостатки LSP с помощью шлака наподобие
if (o instanceof SomeChild) {
// do some implementation specific processing
}
На моей практике именно парадигма «if-instanceof» чаще всего служит признаком сломанных LSP принципов. Если их придерживаться при проектировании/рефакторинге иерархий классов, то с абстракцией всегда можно работать напрямую без ветвлений.
Собственно продолжу мысль: даже многие опытные разработчики не ведают о LSP принципе. Но большая часть старших программистов все-таки начинает мыслить именно в этом русле — как только встает необходимость отнаследовать класс или реализовать интерфейс (наследование все-таки сложнее и чаще приводит к ошибкам) мысленно прогоняет наследник/реализацию через LSP принципы. Это как работа с массивами или ссылками — опытный программист всегда автоматически проверит индекс на попадание в диапазон или ссылку на предмет Null, тогда как начинающий непременно закодит алгоритм без нужных проверок и отхватит проблемы в продакшне
Очень качественная статья, спасибо. Про Spring Cloud + Spring Boot читал раньше, то, как они автоматизируют какие-то типовые вещи — конечно, мега. Обнаружение серверов и поддержание конфигураций, настройка все на уровне java-аннотаций — мега мощно. Ну и микросервисные фреймворки + библиотеки от Нетфликса интегрировались очень органично.
Если я бы сейчас выбирал стек фреймворков и библиотек для самостоятельной реализации облака микросервисов — в первую очередь смотрел бы в сторону спринга.
Тысячу лет назад GridGain позиционировался как IMDG — грубо говоря распределенная мапа, «все данные в памяти». Прошло много лет, они уже ушли от этого термина, но в-целом главный юзкейс остается прежним — данные, распределенные по узлам в виде ключ-значение (лучшего пока не придумали), которые можно обрабатывать локально на узле. Если бы автор не использовал расшаренный диск, то правильным сценарием было бы — распределить данные по узлам, запустить код, обрабатывающий данные, а локальность (affinity) была бы достигнута автоматически
Генетический алгоритм?? Зачем так сложно?? Ээээ, это задача WordLadder на leetcode со средней сложностью, обычный обход дерева в ширину! Причем решение мегаэлегантное, даже граф строить не надо, для коротких слов можно последовательно менять каждую букву и проверять на наличие в словаре — таким образом получим «ребро», которое кладем в очередь.
Интересная статья, примерно такое спрашивали на собеседовании в Гугл, тут, правда, индексу альтернатив нет, эту тему раскрыть легко, но дьявол кроется в деталях, спасибо.
Вопрос про опечатки — обнаруживаете ли и на каком этапе? Какой метод используется? Самое простое — нагенерировать термов из данных префиксов и в путь — искать в префиксном дереве, видимо )
Чаще всего отсутствие схемы — миф. Схема присутствует, но рассыпана по коду, изменение схемы — изменение в коде (причем код становится запутанным и раздутым из-за необходимости поддерживать старую схему для уже существующих данных и т.д.). А такое неявное присутствие схемы делает сложным понимание вообще структуры и взаимосвязей данных — нет никакой мета информации, как на уровне БД о колонках и их типах, ссылочности, ограничениях и т.д. А это, следовательно, увеличивает вероятность багов со стороны разработчиков, которые, могут по коду упустить какие-либо изменения схемы, сделанные другими разработчиками и т.д.
Отсутствие схемы — это произвольные json документы, но никак не бизнес-сущности в приложении. Любые бизнес-сущности, засунутые в один JSON — это полноценная, но жутко неудобная схема в неявном виде
Главные риски — OSGI. На словах и в теории (часто и на практике, если круг задач узок и типичен) это круто, модульно и деплоебельно. Но часто настройка нетипичных бандлов становится гемороем, если у вас планируется большой стек технологий и библиотек, то сначала лучше создайте прототип и попробуйте весь зоопарк поднять. Для новичков это становится неприятным сюрпризом и шишок будет набито немало :)
Те компоненты, о которых вы сказали, есть самодостаточно в кэмеле, поэтому имхо ServiceMix сам по себе профита не даст
С этой точки зрения не очень понятно, зачем вам ActiveMq, не легче было запустить процесс с Camel рутом, который бы слушал входящие http сообщения и обрабатывал их асинхронно?
есть пару проектов, даже в центральном мавеновском хранилище, в названии присутствует «sizeOf». Присутствует в том числе и «глубокая» оценка объектов — с полным деревом ссылок, видимо, через рефлекшн делается.
Александр, видео планируется?
О Вертике читал когда-то в сравнении с Хадупом, но вроде также слышал, что в сфере распределенных баз данных лидером является Teradata…
А еще у нас в России любят критиковать много, в Европе люди намного мягче. Вот и уважаемый Lany нашел недочеты. Я же помню, сколько я усилий потратил, чтобы привести древний курс в более-менее достойный и актуальный вид, это адский труд. Поэтому поддерживаю вас в ваших начинаниях :)
Просто применительно к первому примеру со стримом, который сделали readonly через бросание эксепшна и тем самым нарушили LSP — чинится легко для простого случая с двумя методами. В-целом, выдерживать LSP не так сложно, если знать некоторые простые правила, особенно по части обращения к внутренним полям суперкласса. Выдерживать LSP относительно реализаций интерфейса проще, если не ломать контракты его методов.
А вообще очень хорошо сказано, дополню только, что выполнение LSP зависит напрямую от опыта. На моей практике первые пять лет разработчики о нем в лучшем случае не думают, в худшем — попросту не знают. И работают отлично, создают кучу кода, считая себя опытными зубрами. Вот только в последствии всем их наследникам приходится разгребать недостатки LSP с помощью шлака наподобие
На моей практике именно парадигма «if-instanceof» чаще всего служит признаком сломанных LSP принципов. Если их придерживаться при проектировании/рефакторинге иерархий классов, то с абстракцией всегда можно работать напрямую без ветвлений.
Собственно продолжу мысль: даже многие опытные разработчики не ведают о LSP принципе. Но большая часть старших программистов все-таки начинает мыслить именно в этом русле — как только встает необходимость отнаследовать класс или реализовать интерфейс (наследование все-таки сложнее и чаще приводит к ошибкам) мысленно прогоняет наследник/реализацию через LSP принципы. Это как работа с массивами или ссылками — опытный программист всегда автоматически проверит индекс на попадание в диапазон или ссылку на предмет Null, тогда как начинающий непременно закодит алгоритм без нужных проверок и отхватит проблемы в продакшне
Если я бы сейчас выбирал стек фреймворков и библиотек для самостоятельной реализации облака микросервисов — в первую очередь смотрел бы в сторону спринга.
П.с. не туда ответил, веткой выше хотел
Только вот что такое «кастовать»? Ужасное слово, режет слух, во всем программном мире «cast» понимается как «приводить тип» все-таки, а не что-то иное
Вопрос про опечатки — обнаруживаете ли и на каком этапе? Какой метод используется? Самое простое — нагенерировать термов из данных префиксов и в путь — искать в префиксном дереве, видимо )
Отсутствие схемы — это произвольные json документы, но никак не бизнес-сущности в приложении. Любые бизнес-сущности, засунутые в один JSON — это полноценная, но жутко неудобная схема в неявном виде
Те компоненты, о которых вы сказали, есть самодостаточно в кэмеле, поэтому имхо ServiceMix сам по себе профита не даст
О Вертике читал когда-то в сравнении с Хадупом, но вроде также слышал, что в сфере распределенных баз данных лидером является Teradata…