Практики тут немає. Це суцільна академічна теорія. Будь ласка, почніть додавати нарешті в свої статті реальні практичні кейси, як це втілюється в реальному житті

Simple computation проблема це поганий приклад, що ви могли побачити самі по майже стовідсотковій точності моделі (і про метріки ви взагалі нічого не сказали, а було б цікаво). Розробники мають також знати, для яких задач ML не потрібен. Hello world це був би класичний приклад розпізнавання цифр на зображеннях

Все нормально працює, якщо ставити задачу комітити кожен крок в гіт. Вся ситуація про те, які саме промпти використовуються для вайбкодингу

Lambda підтримується як CloudFront Origin вже як майже рік

Оцінка в Story points та через інші шкали це теорія Agile, і існує безліч матеріалів, які пояснюють коли це має сенс та перевагу над оцінкою в кількості часу, і навпаки. Всі підходи мають право на існування, абсолютно правильного немає. В інших коментарях підкреслюється, що однією з переваг SP є абстрактна оцінка ефорту, яка виключає форс-мажори та похибку в кілька разів при оцінці в кількості часу. Оцінки в сторі пойнтах просто складніше зрозуміти, бо необхідно знати методологію побудування цих оцінок та планування капасіті спринта.

Ще два недоліки на великому enterprise scale та великій кількості лямбд:

— Ліміт кількості Layers/Extensions на одну функцію для складних enterprise use cases. За дизайном Лямбда має все-таки бути невеликою та простою, але завжди знаходяться розробники які намагаються туди покласти якийсь Java моноліт 🥲

— IP exhausting при роботі з ресурсами в VPC

Найкраще для підготовки це курси Маарека/Девіса/Бонсо на Udemy, які можна купити (теорія плюс практика) менше ніж за 30 євро з купоном. Сам іспит на 3/4 приблизно складається саме з питань про основні сервіси та їх призначення, тому краще сфокусуватися на цьому

Сиджу сміюся з цього абзацу, не чітко зафіксовані та обґрунтовані вимоги data locality, а «вони переконані»

AWS запустив auto scaling в 2009, але пан в статті так переконливо стверджує...

Дякую за статтю! Зі свого досвіду можу підтвердити, що приблизно так воно і працює: розвиватися, щоб розуміти, як бізнес транслюється в технологію та vice versa

Дякую за статтю, зрозумілий опис на high-level актуальної теми та наявного тулінгу. Кейс Mongo -> DynamoDB дуже цікавий, бо зазвичай Dynamo не підходить і кастомери обирають або DocumentDB як «офіційний» еквівалент, або Mongo Atlas коли хочуть взяти максимум від Mongo

Щоб скласти екзамен, достатньо сполучення Маарек + Джон Бонсо. Інші ресурси допоможуть краще зрозуміти деякі теми, але на них краще відволікатися лише за реальної потреби. Skill Builder без підписки не ефективний взагалі

Будьте внимательны: там маленький Free Tier лимит, используйте сетап для локального тренинга: aws-deepracer-community.github.io/deepracer-for-cloud

Дякую за посилання на Kaggle, цікавий ресурс!

Большинство вопросов на остальных AWS экзаменах тоже выглядят как мини-задачи на проектирование. По ощущению некоторые из них это явные эдж кейсы, которые происходят редко, но это имхо помогает узнать шире/глубже все возможности сервисов. И тогда при встрече с собственным эдж кейсом можно применить более простое и красивое решение с максимальным использованием уже готовых возможностей сервисов — вместо громоздкого и с собственными костылями.

Батенька, это вторая или третья серия сезона, а в субботу вышла уже 8 ))) Остаете :-)

Ну так съездить в Зимбабве, посмотреть Африку и уволиться :-)

За такую зарплату можно поработать пару месяцев, если работа не включает криминал или сексуальные извращения

Проблема в названии этой темы + я слишком скромный, чтобы сделать саморекламу и впечатлить