วีดีโอ

Питання з чату треба задавати в кінці відео.. невже це не очевидно..

Взагалі не структуроване відео.

Сейчас в методе AutoConfigurationImportSelector#getCandidateConfigurations() используется не SpringFactoriesLoader, а ImportCandidates.load(AutoConfiguration.class, getBeanClassLoader()). В доке написано о нём следующее: "загружает имена кандидатов для импорта из classpath. Имена кандидатов для импорта хранятся в файлах с именами META-INF/ spring/full-qualified-annotation-name.imports"

Java лучше подходит для начинающего программиста, ФАКТ 100%. JS на самом деле язык на много сложнее, просто потому, что он мультипарадигменный, Java императивщина в чистом её виде. Да, для JS инструментов для разработки больше, скажем скорость написание hello world на JS будет быстрее, но это совсем не показатель, простоты входа в язык. В Java достаточно будет взять любую книжку около 500 страниц, при этом освоив структуры и алгоритмы, в JS офигеешь от чтения EcmaScript спецификации, а не зная ES будешь, верить в магию какую-то или думать, что JS кривой ЯП. Так, что считаю, совсем не верным аргумент, что JS проще для входа чем Java. В дополнительном времени услышал, от представителя JS, что якобы сложность с абстракциями не нужна, у меня после этого большие сомнения в профессионализме JS разработчика. Берет и начинаете пилить и как запиливается? или потом, уже приходит понимание, что полкоманды не знает, как работает JS и приложение начинает тупить, падать и вообще ведет себя очень странно. Повторюсь JS сложен, хотя бы потому, что нужно знать алгоритмы работы его машинерии. Да на нем можно быстро написать скриптик. Да можно быстро сделать какой-нибудь REST, но полноценный продакшн, на нем пилить по времени придется столько же, сколько и на Java, а может и больше. --- В общем считаю, представитель Java более аргументированно подошел. Моё личное мнение, для Java это закат, императивное программирование умирает как вид в коммерческой среде. Будущее на ближайшие 10 лет будет за JavaScript + Rust. Java это в основном будет поддержка легаси в корпоративной среде, что успели настрочить за последние 25 лет.

Hi everyone! Thank you for joining and we hope you enjoyed the talk. We'd like to respond to some questions and comments, that we couldn't cover during the live stream: 1. How does the "API First" approach impact the speed of development and deployment in a project? Kiryl: - API First itself decreases late-stage integration issues so it decreases delivery time. Besides, using auto-generation tools such as one presented on the talk speeds up the development for sure. As a proof - see point 5 here 😉 2. Can you provide some examples of challenges one might face when implementing the "API First" approach and how to overcome them? Kiryl: - Main challenge IMO is that you need to manage API specs in some centralized way to avoid arbitrary changes to it on the one hand, on the other hand you need to keep you actual endpoints up to date with the spec. This challenge could be resolved by automation of Backend/Client generation and use as it was shown during the talk. Plus, you might consider contract auto Tests which verify the spec against your actual APIs. - You might need some linter tool to ensure spec is always correct and confirms to OpenAPI standard and your project standards. Example of such tool is: zalando/zally: A minimalistic, simple-to-use API linter (github.com) 3. What are some common anti-patterns or pitfalls to avoid when using OpenAPI and an API-first design? Kiryl: - not keeping a specification aligned with actual endpoints, that can be covered by contract tests - not aligning on data types conversion between OpenAPI and backend language - overthinking of consumers’ needs - as API First implies the contract to be created first we might tend to add here just everything “for future need”. You will have to implement all corresponding code even though it might be not needed by API consumers 4. How does the "API First" approach affect the testing process? Are there any specific testing strategies you would recommend? Kiryl: - if you have API auto-tests (likely yes) early contracts allow testing team to start preparing their scenarios, scripts beforehand, not waiting for actual API implementations. Besides API mocks can be easily generated based on the schema. - you may consider contract auto-tests which will verify that actual endpoints correspond to request/response schemas defined in the spec. 5. We use the OpenAPI generator in out Kotlin projects and I can guarantee: it significantly increases the speed of development and helps to automatically validate your API against schema. I can't imagine how to work without this approach! Kiryl: Agree, same feeling! And thanks for participation! 6. How can I implement Api First approach except Open API instrument? Kiryl: OpenAPI is a format of describing your API. For RESTful APIs, OpenAPI is the most used specification type nowadays, I can’t even recommend smth else here. However, if you deal with other communication types (technologies) such as async interaction via events or gRPS - you may use other spec types such as CloudEvents or gRPC specific format. 7. Can I we use OpenAPI generator plugin for other languages so we can integrate microservices written using different languages/platforms? Kiryl: The plugin provides a bunch of generators for both server and client sides for different languages and frameworks, full list here: Generators List | OpenAPI Generator (openapi-generator.tech) 8. What if my API providers/consumers not in Spring/java? Does generator support other frameworks/languages? Kiryl: The plugin provides a bunch of generators for both server and client sides for different languages and frameworks, full list here: Generators List | OpenAPI Generator (openapi-generator.tech) 9. I previously experimented with this approach in a test project (github.com/rabestro/pig-latin-rest/) and was curious to see if it was being utilized in real-world applications. This presentation was incredibly enlightening and I thoroughly enjoyed it! Kiryl: thank you so much! 10. When do I push new version of api, i could still use old version and it won't be deleted in future? Kiryl: short answer is yes. This is totally a matter of the retention policy in your antifactory (artifact repo), let me give you an example: we publish our API clients (Jars) into JFrog under a specific version. All versions are kept there so you can use any of those unless you have some policy deleting older versions. 11. What we need to do if will need to update the api schema? We can have situation when we need to update api schema but some of the services already use old version of the service which generated from old schema. How can we support such case? Kiryl: You can publish a new API client version into artifactory upon each schema change, preserving old versions as well, so any API consumer can you whatever version it needs. However, if you do breaking changes to your API (not extending it but changing current APIs) - older clients will fail of course, here you need to introduce a new API version to keep old clients up until they are ready to switch. 12. How can we ensure security when adopting an "API First" approach? Kiryl: it depends on which kind of security you’re talking about. - If you mean API security - OpenAPI standard allows you to declare security related headers, or you might declare your own. But overall, API security is not a concern of API First, it’s more about the security design in your app, the schema just allows reflecting whatever security tokens/headers you use in API. - If you mean security in terms of how secure you autogenerated code is - feel free to apply any vulnerabilities scanner to it. 13. Does this approach make any sense without contract testing? The API provider publishes a client that matches the API schema, but API consumers may use older versions. Without contract testing, it seems unreliable. Kiryl: Contract testing is a vital thing, but I would like to mention the following: You can publish a new API client version into artifactory upon each schema change, preserving old versions as well, so any API consumer can you whatever version it needs. However, if you do breaking changes to your API (not extending it but changing current APIs) - older clients will fail of course, here you need to introduce a new API version to keep old clients up until they are ready to switch. So the contract tests would at least allow you to make sure no one did breaking changes not intentionally. 14. Do we have alternatives for OpenAPI? Kiryl: In terms of REST API definition - nothing same widely used nowadays afaik. However for other technologies/communication types - of course, e.g. GraphQL schema, CloudEvent specification for event communication CloudEvents | or gRPC own format for remote procedure calls. 15. What do you think about using GraphQL for API-First? Kiryl: absolutely fine, we used it on one of the projects. GraphQL has it’s own schema definition, the plugin provides GraphQL generators and schema validation capabilities, see here Generators List | OpenAPI Generator (openapi-generator.tech)

It was quite interesting to see such an approach, but I would prefer gRPC over it - also provides a good contract, but also more readable and has better performance. But in cases where only REST - it could work really well.

Очень жаль, что MJC закрылся. Надеюсь, что они когда-то вернутся как в старые и добрые времена

Спаситель❤ Спасибо за контент.

Really good presentation! It was short, concise, interesting!

Дебаты вышли, конечно, посредственными. Человек который говорит, що js движки однопоточные, видимо не открывал официальную спецификацию, 30% которой о Atomic API, которая и есть многопоточностью, а однопоточный js в браузере из-за MutationObserver, и только. Со второй стороны, человек который говорит про странности JS тоже не читал доку, по-этому слажение масива с масивом - пустая строка, это так, из-за особенностей знака +, который выступает как сложение и конкатенация строк одновременно, по-этому, масив просто приводится к строковому виду

35:30 - забавляет меня это "Я заранее написал"... А на 8-й строчке HashMapCurrencyModeService из какой, простите, задницы появилось??? Откуда это вообще, где его описание? Заранее он написал...🤣 Надо было весь код заранее написать и показать как он классно работает. Ролик бы получился на 3 минуты, а не на 1,5 часа. ... пришлось переделывать часть кода 😄

Target architecture на 15:39. Тут есть минус. В том, что никто не думает о клиентах. Как недавно столкнувшийся с тем, что я делаю /post, мне возвращается некий id, а потом я же вынужден пинговать статус в виде /get/<id>. Меня как клиента, совсем не устраивает такой процесс. Мне не нужна сложность эта. Я делаю запрос и хочу результат)

Вообще ничего не понятно

блин че это было

Эмм, для тех кто не понимает в аннотациях, тут вы им не научитесь, это шестиминутное видео нужно минут на 60 разворачивать, чтобы объяснить не поверхностно

Спасибо за доклад! Но почему отказались от названия Минск джава комьюнити?

Could you share the link to GitHub?

Спасибо за видео. Особенно понравилась манера изложения. Успехов!

че так быстро

Шикарное видео, лектор спасибо и вечного счастья!

С Новым Годом 🎄 Пожелаю всем в 2024 новых побед 🏆 карьерного роста. Может кто посоветует видео в ютуб , где разбираются более сложные проекты на java. Работаю на Питон, но необходимо на Java работать дополнительно. Надо перестроится по синтаксису. Два проекта посмотрел, сапер игра и сетевой чат. Хотелось бы еще проекты посмотреть.

Я думал в видео расскажут как ConcurrentHashMap устроена

Круто, за колокол лайк)

Да, комитаемся грустно слышать.

my favourite teacher, the best one I have ever had :)

Though today there is lower demand of employees for this field .Can we accept this demand will increase exponentially in coming years?

Можно вас попросить сделать видео по Spring без бута. А если совсем размечтаться, то написать на Java основы спринга без Спринга. Как это устроено. Контейнер бинов на рефлексии, DispatcherServlet на сервлете, простейшее подключение БД - как это сделано в спринге, АОП уже разобран, спасибо.

код стал ххуже и больше, в чем смысл подобного рефактора?

Лекция не плохая и даже полезная. Но испорчена очень слабой подачей. Слушал на скорости 1.25. Медленней просто невозможно. И почему "Elastic Such", а не "Elastic Search" - не понятно.

It always does not have to be career change, nowhere you guys says how do devs can incorporates ML in their dev career. ML is no utopia land where you just click, click and make millions. Come on now!

Павел Вейник жулик

12:10 а откуда вся эта функциональность? получается она хранится в неком файле. а где этот файл и как он попал на комп к нам? тогда когда мы сгенирировали проект и скачали его с сайта ?

Можно ли подключиться к уже существующему боту через api ?

Interesting topic and great tips for transitioning. The background music is very distracting though.

Ужасный докладчик, ужасный монтаж видео

Спасибо докладчику. Не смотря на то, что использовал Spring уже давно, всё равно узнал ряд полезных вещей.

Hi, thanks for this fullfit introduction in ML for Java engineers and other ML work options!) I have question around MLOPS, in your presentation the qualifications in each item is about 3-5 years for MLOPS, I understand that you are ML Engineer, but maybe you can clarify as well, is it difficult to be involved in MLOPS sphere if you have cloud experience only in 1 year of deploying java projects(creating CI/CD pipelines, CloudWatch, etc) ? Thanks.

Звучит сложно и непонятно, подтяну свои скиллы и вернусь пересмотреть видос!

Очень хорошо поставленная речь и круто структурированный материал! Спасибо!

Видно мужик много чего знает.

Круто всё вышло, большое спасибо

Лет ми спик фром май харт.

Great video! thank you

Thank you for the video. The theme is vital important!

guys, did you really want to publish this video? a guy reading from script? :D

Добрый день ,как использовать class InlineQueryResultGame. никак не получается сделать игру Помогите

Hi guys! Thank u so much for this interview! What do you think about ahead of time compilation in Java: is it gonna be a trend and we'll be facing more and more attempts to make our apps\services boot faster, or it will stay niche due to limitations it entails?

Спасибо!!! Мне как раз нужно было сконфигурёлить приложение на спрингбуте и понять на сколько скрыта его мощь!))

Спасибо!!!!! На удивление понятно (других не понимаю - многого не говорят, думают, что все и так знают)

Идеальные инглиш)))