Опубликовали на YouTube запись вчерашней лекции про финтех - https://youtu.be/bKJ-bzcTm7U?si=IR2Z09Wytzv6Vahv.
Это первая лекция из цикла лекций про финтех. В ней мы обсудили фундаментальные технологии этой индустрии, такие как эквайринг и поставщики платёжных услуг, заложив тем самым фундамент для дальнейшего развития.
После лекции участники высоко оценили качество и ценность материала, поэтому всем рекомендую к просмотру ☀️.
Это первая лекция из цикла лекций про финтех. В ней мы обсудили фундаментальные технологии этой индустрии, такие как эквайринг и поставщики платёжных услуг, заложив тем самым фундамент для дальнейшего развития.
После лекции участники высоко оценили качество и ценность материала, поэтому всем рекомендую к просмотру ☀️.
YouTube
Введение в финтех на примере Stripe
Первая лекция из цикла про финтех. На лекции мы обсудили, как развивался рынок финтеха и какие у него перспективы.
Вначале мы узнали, что такое эквайринг, как он развивался, и какие преимущества и недостатки у него есть. Затем мы поняли, как поставщики платёжных…
Вначале мы узнали, что такое эквайринг, как он развивался, и какие преимущества и недостатки у него есть. Затем мы поняли, как поставщики платёжных…
🔥6❤2👍2
Поздравляем всех с новым 2025 годом! ☀️
Желаем крепкого здоровья, много энергии и баланса между личной жизнью и работой! Уверенно идите по дороге, которая ведёт к процветанию и профессиональному успеху!
Нам с вами по пути! 🚀
Желаем крепкого здоровья, много энергии и баланса между личной жизнью и работой! Уверенно идите по дороге, которая ведёт к процветанию и профессиональному успеху!
Нам с вами по пути! 🚀
🎉14❤5👍4
Сегодня познакомился с одним человеком и решил описать ему, чем занимаюсь и какие ставлю цели. В итоге получился целый пост, решил опубликовать его в канале)
👍4🔥3
Цель моей активности - выведение индустрии ИТ в Казахстане на новый уровень. Чтобы у нас делали крутые вещи, активно участвовали в опен-сорсе, были крутые известные специалисты. За пример можно индустрию Украины взять, где делают много классных продуктов и много классных профессионалов.
Понятно, что это звучит масштабно и амбициозно, но чем больше цель, тем больше можно сделать на пути к ней)
Сейчас какая ситуация у нас в стране. Есть компании, хорошие и плохие. Есть разработчики, которые там работают, но больше особо ничем не занимаются. Есть какие-то встречи, конференции, лекции. Но не хватает конкретики, на мой взгляд. Чтобы были такие точки притяжения, куда можно постучаться, увидеть, что прикольного делают, и получить поддержку, чтобы тоже начать это делать. И тем самым выйти на новый уровень развития.
Вот такую точку притяжения я создаю - сообщество Drim Team.
Теперь о конкретике. Сейчас в сообществе мы периодически проводим лекции и семинары и обсуждаем текущие задачи участников. Плюс параллельно начинают появляться более продвинутые проекты. Ниже расскажу об одном из них.
Месяц назад ко мне пришёл участник сообщества за советом по поводу централизованного логгирования. У них в компании используется прямая запись логов из сервисов в Elasticsearch. Он же хотел рассмотреть и предложить руководству другую схему - использование OpenTelemetry Collector (эту схему мы детально изучали на одном из моих курсов). С этой идеей он обратился ко мне, чтобы обсудить плюсы и минусы.
Главная проблема текущего решения заключалась в производительности. Под большой нагрузкой им иногда приходилось отключать логгирование, чтобы снизить нагрузку на сервера. Это сильно снижало потребление процессора и памяти. Но кто даст гарантию, что схема с OpenTelemetry Collector будет более производительной? Единственный способ это узнать - провести нагрузочное тестирование обоих подходов и сравнить потребление ресурсов. Это мы и решили делать.
В итоге родился вот этот проект https://github.com/drim-dev/logging-benchmarks.
Там мы нагружаем систему с прямым логгированием в Elasticsearch, потом с OpenTelemetry Collector, потом без логгирования, и сравниваем метрики. Реальные результаты уже есть, скоро их опубликуем.
Это хороший пример взаимной пользы участника и сообщества. Участник придёт с предложением и проработанным обоснованием этого предложения к руководству своей компании. Это жирный плюс и хорошо продвинет его на пути к архитектору, куда он нацелен. Так и должны расти крутые специалисты.
Сообщество же получит полезный проект, который можно использовать для изучения использованных в нём практик и технологий. Кроме этого, уже сейчас рождаются идеи о том, как можно этот проект развить.
Первая идея - создание оператора Kubernetes для того, чтобы он автоматически создавал сервера, разворачивал инфраструктуру для нагрузочного тестирования, проводил нагрузку, собирал результаты и удалял сервера. Тогда эксперименты по сравнению разных технологий можно будет описывать в виде Custom Resource Definition. Это один YAML-файл, который можно быстро изучить и понять, что с чем сравнивалось. Плюс каждый сможет воспроизводить полученные результаты и проводить свои собственные эксперименты. Такого инструмента я нигде не видел, и он может стать востребованным на мировом уровне, делая специалистов из Казахстана более известными.
Вторая идея - использование AI для анализа результатов проведённых экспериментов. Анализ это трудоёмкая операция и требует просмотра многих метрик и сопоставление их друг с другом. Вполне может быть, что получится создать такой AI-бот, который сможет проводить анализ и описывать его результаты. Это позволит значительно ускорить решение проблем с производительностью. И такого инструмента я тоже нигде ещё не видел.
Это всё идеи и нет гарантии, что они будут полноценно реализованы. Но они помогут добиться главной цели - формирования точки притяжения и совместной работы над топовыми проектами.
Пишите, если вам интересно. И подписывайтесь на канал, чтобы быть в курсе ☀️
Понятно, что это звучит масштабно и амбициозно, но чем больше цель, тем больше можно сделать на пути к ней)
Сейчас какая ситуация у нас в стране. Есть компании, хорошие и плохие. Есть разработчики, которые там работают, но больше особо ничем не занимаются. Есть какие-то встречи, конференции, лекции. Но не хватает конкретики, на мой взгляд. Чтобы были такие точки притяжения, куда можно постучаться, увидеть, что прикольного делают, и получить поддержку, чтобы тоже начать это делать. И тем самым выйти на новый уровень развития.
Вот такую точку притяжения я создаю - сообщество Drim Team.
Теперь о конкретике. Сейчас в сообществе мы периодически проводим лекции и семинары и обсуждаем текущие задачи участников. Плюс параллельно начинают появляться более продвинутые проекты. Ниже расскажу об одном из них.
Месяц назад ко мне пришёл участник сообщества за советом по поводу централизованного логгирования. У них в компании используется прямая запись логов из сервисов в Elasticsearch. Он же хотел рассмотреть и предложить руководству другую схему - использование OpenTelemetry Collector (эту схему мы детально изучали на одном из моих курсов). С этой идеей он обратился ко мне, чтобы обсудить плюсы и минусы.
Главная проблема текущего решения заключалась в производительности. Под большой нагрузкой им иногда приходилось отключать логгирование, чтобы снизить нагрузку на сервера. Это сильно снижало потребление процессора и памяти. Но кто даст гарантию, что схема с OpenTelemetry Collector будет более производительной? Единственный способ это узнать - провести нагрузочное тестирование обоих подходов и сравнить потребление ресурсов. Это мы и решили делать.
В итоге родился вот этот проект https://github.com/drim-dev/logging-benchmarks.
Там мы нагружаем систему с прямым логгированием в Elasticsearch, потом с OpenTelemetry Collector, потом без логгирования, и сравниваем метрики. Реальные результаты уже есть, скоро их опубликуем.
Это хороший пример взаимной пользы участника и сообщества. Участник придёт с предложением и проработанным обоснованием этого предложения к руководству своей компании. Это жирный плюс и хорошо продвинет его на пути к архитектору, куда он нацелен. Так и должны расти крутые специалисты.
Сообщество же получит полезный проект, который можно использовать для изучения использованных в нём практик и технологий. Кроме этого, уже сейчас рождаются идеи о том, как можно этот проект развить.
Первая идея - создание оператора Kubernetes для того, чтобы он автоматически создавал сервера, разворачивал инфраструктуру для нагрузочного тестирования, проводил нагрузку, собирал результаты и удалял сервера. Тогда эксперименты по сравнению разных технологий можно будет описывать в виде Custom Resource Definition. Это один YAML-файл, который можно быстро изучить и понять, что с чем сравнивалось. Плюс каждый сможет воспроизводить полученные результаты и проводить свои собственные эксперименты. Такого инструмента я нигде не видел, и он может стать востребованным на мировом уровне, делая специалистов из Казахстана более известными.
Вторая идея - использование AI для анализа результатов проведённых экспериментов. Анализ это трудоёмкая операция и требует просмотра многих метрик и сопоставление их друг с другом. Вполне может быть, что получится создать такой AI-бот, который сможет проводить анализ и описывать его результаты. Это позволит значительно ускорить решение проблем с производительностью. И такого инструмента я тоже нигде ещё не видел.
Это всё идеи и нет гарантии, что они будут полноценно реализованы. Но они помогут добиться главной цели - формирования точки притяжения и совместной работы над топовыми проектами.
Пишите, если вам интересно. И подписывайтесь на канал, чтобы быть в курсе ☀️
🔥14❤5👍1
В предыдущем посте я обещал опубликовать результаты сравнения двух популярных подходов к централизованному логированию:
1. Прямая запись логов приложением в Elasticsearch
2. Запись приложением логов в файл с последующим чтением и отправкой в Elasticsearch с помощью OpenTelemetry Collector
Результаты готовы и оформлены.
Но вначале пара слов о том, как родился этот проект. В сообществе Drim Team мы сообща изучаем новые технологии и помогаем друг другу с разными задачами. В начале декабря ко мне пришёл участник сообщества Сергей Рубцов (https://news.1rj.ru/str/sergey_rubtsov) за советом по поводу централизованного логирования. На работе у них используется схема с прямой записью в ES, он же хотел предложить руководству использовать вариант с OpenTelemetry Collector.
В процессе обсуждения мы поняли, что у нас не было информации, какое из этих решений работает быстрее. Решили провести нагрузочное тестирование и узнать это. Кроме того, решили замерить потребление ресурсов с отключенным логированием, чтобы понять, насколько его использование увеличивает нагрузку на систему. Так родился этот репозиторий https://github.com/drim-dev/logging-benchmarks.
В README репозитория описаны результаты сравнения https://github.com/drim-dev/logging-benchmarks/blob/main/README.md. Почитайте - там интересные цифры. Приведу здесь основные выводы на русском:
1. Логирование вносит значительную дополнительную нагрузку. Обе схемы логирования (напрямую в Elasticsearch и через OTel Collector) повышают загрузку процессора с 32% до примерно 50–55%. Потребление CPU возрастает на 65–75%, что очень значительно. Потребление оперативной памяти также сильно возрастает.
2. OTel Collector обеспечивает лучшую производительность по сравнению с прямой отправкой в Elasticsearch. Несмотря на немного более высокую загрузку процессора (55% по сравнению с 52%), решение на базе OTel Collector демонстрирует самые низкие значения летенси (средней, медианной и 90-95 перцентилей). При этом потребление памяти значительно ниже (8,5% по сравнению с 12%). Похоже, что такая конфигурация снимает часть нагрузки с процесса приложения, делая летенси более стабильной и предсказуемой.
Эти выводы помогут Сергею и его команде выбрать оптимальную для них схему логирования. Уверен, что вам они будут полезны тоже. Вы можете взять репозиторий и адаптировать его для сравнения нужных вам компонентов. Кстати, пишите в комментариях, как часто вы проводите нагрузочное тестирование для принятия архитектурных решений. Также пишите все возникающие вопросы и предложения.
Теперь о планах на будущее. Мы не собираемся останавливаться на полученных результатах. Весь процесс от идеи до публикации результатов занял у нас полтора месяца работы в свободное время. Это долго. Поэтому мы начинаем работу над проектом, который позволит сократить время для решения подобных задач с нескольких недель до нескольких часов. Это будет оператор Kubernetes, автоматизирующий весь процесс от развёртывания окружения до проведения нагрузочного тестирования и до публикации итоговых результатов.
Подписывайтесь на канал, следите за новостями, будет интересно и полезно 🚀
Если вам интересно узнать больше о сообществе Drim Team, информацию вы можете найти на сайте https://drim.dev
P.S. Буду признателен, если вы поставите звёздочку проекту на GitHub 🙂
1. Прямая запись логов приложением в Elasticsearch
2. Запись приложением логов в файл с последующим чтением и отправкой в Elasticsearch с помощью OpenTelemetry Collector
Результаты готовы и оформлены.
Но вначале пара слов о том, как родился этот проект. В сообществе Drim Team мы сообща изучаем новые технологии и помогаем друг другу с разными задачами. В начале декабря ко мне пришёл участник сообщества Сергей Рубцов (https://news.1rj.ru/str/sergey_rubtsov) за советом по поводу централизованного логирования. На работе у них используется схема с прямой записью в ES, он же хотел предложить руководству использовать вариант с OpenTelemetry Collector.
В процессе обсуждения мы поняли, что у нас не было информации, какое из этих решений работает быстрее. Решили провести нагрузочное тестирование и узнать это. Кроме того, решили замерить потребление ресурсов с отключенным логированием, чтобы понять, насколько его использование увеличивает нагрузку на систему. Так родился этот репозиторий https://github.com/drim-dev/logging-benchmarks.
В README репозитория описаны результаты сравнения https://github.com/drim-dev/logging-benchmarks/blob/main/README.md. Почитайте - там интересные цифры. Приведу здесь основные выводы на русском:
1. Логирование вносит значительную дополнительную нагрузку. Обе схемы логирования (напрямую в Elasticsearch и через OTel Collector) повышают загрузку процессора с 32% до примерно 50–55%. Потребление CPU возрастает на 65–75%, что очень значительно. Потребление оперативной памяти также сильно возрастает.
2. OTel Collector обеспечивает лучшую производительность по сравнению с прямой отправкой в Elasticsearch. Несмотря на немного более высокую загрузку процессора (55% по сравнению с 52%), решение на базе OTel Collector демонстрирует самые низкие значения летенси (средней, медианной и 90-95 перцентилей). При этом потребление памяти значительно ниже (8,5% по сравнению с 12%). Похоже, что такая конфигурация снимает часть нагрузки с процесса приложения, делая летенси более стабильной и предсказуемой.
Эти выводы помогут Сергею и его команде выбрать оптимальную для них схему логирования. Уверен, что вам они будут полезны тоже. Вы можете взять репозиторий и адаптировать его для сравнения нужных вам компонентов. Кстати, пишите в комментариях, как часто вы проводите нагрузочное тестирование для принятия архитектурных решений. Также пишите все возникающие вопросы и предложения.
Теперь о планах на будущее. Мы не собираемся останавливаться на полученных результатах. Весь процесс от идеи до публикации результатов занял у нас полтора месяца работы в свободное время. Это долго. Поэтому мы начинаем работу над проектом, который позволит сократить время для решения подобных задач с нескольких недель до нескольких часов. Это будет оператор Kubernetes, автоматизирующий весь процесс от развёртывания окружения до проведения нагрузочного тестирования и до публикации итоговых результатов.
Подписывайтесь на канал, следите за новостями, будет интересно и полезно 🚀
Если вам интересно узнать больше о сообществе Drim Team, информацию вы можете найти на сайте https://drim.dev
P.S. Буду признателен, если вы поставите звёздочку проекту на GitHub 🙂
🔥6👍2❤1
Drim Dev
Теперь о планах на будущее. Мы не собираемся останавливаться на полученных результатах. Весь процесс от идеи до публикации результатов занял у нас полтора месяца работы в свободное время. Это долго. Поэтому мы начинаем работу над проектом, который позволит сократить время для решения подобных задач с нескольких недель до нескольких часов. Это будет оператор Kubernetes, автоматизирующий весь процесс от развёртывания окружения до проведения нагрузочного тестирования и до публикации итоговых результатов.
В предыдущем сообщении я писал, что мы начинаем работу над проектом для проведения сравнительного нагрузочного тестирования. Мы будем использовать оператор Kubernetes для реализации этого инструмента.
Мы провели первый звонок, где обсудили, как можно реализовать оператор на языке Go с помощью Operator SDK https://sdk.operatorframework.io/
Вот запись звонка. Рекомендую к просмотру тем, кто хочет развиваться в автоматическом тестировании, Kubernetes и Go. Вы сможете наблюдать (или участвовать) за проектом и получать нужный вам опыт.
https://youtu.be/2U0xRhKK9A0
Мы провели первый звонок, где обсудили, как можно реализовать оператор на языке Go с помощью Operator SDK https://sdk.operatorframework.io/
Вот запись звонка. Рекомендую к просмотру тем, кто хочет развиваться в автоматическом тестировании, Kubernetes и Go. Вы сможете наблюдать (или участвовать) за проектом и получать нужный вам опыт.
https://youtu.be/2U0xRhKK9A0
👍4
Получил недавно очередной отзыв о деятельности нашего сообщества. Классно понимать, что курсы и сообщество помогают людям расти и идти вперёд по карьерному пути. Это сильно мотивирует!
Вот отзыв:
Прошло полтора года с тех пор, как я начал проходить курсы и присоединился к сообществу Drim Team. Тогда я озвучил цель «снова начать писать на C#» и «понять, как сейчас пишут современные приложения на C# и .NET». Для себя хочу отметить, что обе цели были достигнуты и перевыполнены благодаря всем тем лекциям, что провел Дмитрий Мельник. Активности на курсах и в сообществе вернули мне интерес к учёбе и развитию.
И самое главное - знания, полученные в Drim, помогли мне получить должность техлида в команде разработчиков C#!
Дархан Изтлеу, техлид в "Банк ЦентрКредит"
Вот отзыв:
Прошло полтора года с тех пор, как я начал проходить курсы и присоединился к сообществу Drim Team. Тогда я озвучил цель «снова начать писать на C#» и «понять, как сейчас пишут современные приложения на C# и .NET». Для себя хочу отметить, что обе цели были достигнуты и перевыполнены благодаря всем тем лекциям, что провел Дмитрий Мельник. Активности на курсах и в сообществе вернули мне интерес к учёбе и развитию.
И самое главное - знания, полученные в Drim, помогли мне получить должность техлида в команде разработчиков C#!
Дархан Изтлеу, техлид в "Банк ЦентрКредит"
👍8⚡1
Forwarded from Devs.kz (Askar Aituov)
От стэнфордского преподавателя Lakshya Jain. Я преподаю базы данных в Беркли в этом семестре. Мои студенты кажутся необычайно блестящими. Немногие приходят за консультациями на office hours, и не так много людей задают вопросы по проекту на форуме курса. Странно, но на экзамене был самый низкий средний балл за 10 семестров, что я его преподаю. Другими словами, я почти уверен, что многие студенты информатики используют ChatGPT для выполнения своих заданий по программированию вместо того, чтобы делать их самостоятельно. Если это правда, то это огромная проблема. Процесс обучения отладке имеет решающее значение для роста как инженера. По моему мнению, следствием этого может стать то, что курсы должны будут давать еще меньше поддержки, чтобы студенты не могли полностью выполнить задание с помощью GPT. Дизайн проектов также может стать еще более важным. Теория также станет еще более важным фильтром для оценки компетентности.
Вот проблема использования GPT в качестве студента. В производственных системах вы столкнетесь с вещами, где ЭТО НЕ РАБОТАЕТ. Вы не можете просто использовать GPT как костыль, отчасти потому, что у вас даже не будет контекста, необходимого для составления запроса для решения проблемы. Например, бывают случаи, когда код настолько запутан, а ошибка настолько невероятно сложна для отладки, что вы не сможете пробиться через нее с помощью GPT. Единственный способ исправить это — установить точку останова, войти в отладчик и посмотреть, какие значения у определенных переменных. При настройке кодовой базы бывают случаи, когда GPT терпит неудачу. Здорово использовать GPT в качестве помощника — я использую его постоянно. Вы не можете использовать его в качестве основного средства разработки, потому что вы функционально не понимаете, что делаете (кроме копирования и вставки).
Теперь вы можете спросить что, если мои задачи на работе достаточно просты, чтобы GPT все легко решал? Разве я не могу просто использовать его для этого? Поздравляю. Возможно, вы открыли путь к безработице. Если ИИ делает все, что вы можете делать, зачем им вас держать? Для набора навыков в области информатики, который нельзя просто заменить ИИ, вам нужно изучить основы. Это позволит вам выполнять задачи, которые ИИ до сих пор не может, потому что ваш мозг очень мощный. Если вы прокладываете себе путь с помощью ChatGPT, вы не строите никаких связей для дальнейшего использования. Переведно через Gemini AI. Автор промпта А. Айтуов- @devs_kz
Вот проблема использования GPT в качестве студента. В производственных системах вы столкнетесь с вещами, где ЭТО НЕ РАБОТАЕТ. Вы не можете просто использовать GPT как костыль, отчасти потому, что у вас даже не будет контекста, необходимого для составления запроса для решения проблемы. Например, бывают случаи, когда код настолько запутан, а ошибка настолько невероятно сложна для отладки, что вы не сможете пробиться через нее с помощью GPT. Единственный способ исправить это — установить точку останова, войти в отладчик и посмотреть, какие значения у определенных переменных. При настройке кодовой базы бывают случаи, когда GPT терпит неудачу. Здорово использовать GPT в качестве помощника — я использую его постоянно. Вы не можете использовать его в качестве основного средства разработки, потому что вы функционально не понимаете, что делаете (кроме копирования и вставки).
Теперь вы можете спросить что, если мои задачи на работе достаточно просты, чтобы GPT все легко решал? Разве я не могу просто использовать его для этого? Поздравляю. Возможно, вы открыли путь к безработице. Если ИИ делает все, что вы можете делать, зачем им вас держать? Для набора навыков в области информатики, который нельзя просто заменить ИИ, вам нужно изучить основы. Это позволит вам выполнять задачи, которые ИИ до сих пор не может, потому что ваш мозг очень мощный. Если вы прокладываете себе путь с помощью ChatGPT, вы не строите никаких связей для дальнейшего использования. Переведно через Gemini AI. Автор промпта А. Айтуов- @devs_kz
В интересном треде преподаватель из Стэнфорда поднимает важную проблему - https://x.com/lxeagle17/status/1899979401460371758 Массовое использование больших языковых моделей (LLMs) приводит к тому, что существующие методики обучения перестают работать. Мы не можем запретить использование LLM, поэтому нужно встраивать их в процесс. Сейчас опишу свой опыт в этом.
Недавно я начал обучение GameDev-разработчика, который хочет переквалифицироваться в DevOps. С самого начала мы решили, что для обучения будем активно использовать ChatGPT. Это решение было основано на двух гипотезах:
1. ChatGPT позволит значительно сократить время обучения
2. Нужно сразу учиться решать задачи с использованием ChatGPT. Ведь в реальной работе это так и будет происходить
В итоге я сформировал следующую методику:
Обучение происходит путём выполнения конкретных приближенных к реальности задач. Есть выдуманный стартап под названием AI Tutor. Он разрабатывает бота-преподавателя. Студент работает в нём в качестве DevOps. По мере роста стартапа появляются всё новые задачи, которые нужно выполнять.
Примеры задач:
1. Нужно запустить лендинг стартапа. Для этого нужно на виртуалке AWS запустить nginx и захостить там простой лендинг. После чего купить и привязать домен. На виртуалке нужно организовать SSH-доступ для разработчика. Разработчик должен иметь права только на модификацию лендинга.
2. Прошли первые питчи, пошли первые посетители, стартапу теперь нужен блог. Нужно развернуть блог с использованием ghost и настроить роутинг в nginx, чтобы он был доступен по пути /blog на сайте лендинга. Кроме того, давайте сразу настроим отказоустойчивость. Ожидается посещение сайта серьезными партнёрами, поэтому он должен быть доступен всегда. Для этого нужно поднять вторую виртуалку AWS и создать балансировщик.
И так далее.
Я не объясняю студенту, как настраивать nginx или SSH. Ему об этом расскажет ChatGPT. Но как понять, что ChatGPT дал корректный ответ? Для этого у студента должен быть хороший теоретический фундамент. Если конкретные задачи это первый столп методики, то изучение теории - второй. Для этого в рамках каждой задачи я даю студенту вопросы, ответы на которые он должен подготовить (тоже с помощью ChatGPT, скорее всего).
Когда студент всё сделал, мы созваниваемся. Он показывает результат и отвечает на вопросы. Я корректирую и даю дополнительную информацию. Так мы формируем системные фундаментальные знания. Они позволят понять, что, к примеру, nginx и traefik это просто разные инструменты, но они могут решать общую задачу - роутинг. И теперь опыт работы с nginx может быть переложен на traefik. Создаётся система знаний.
Вот примеры вопросов после первой задачи:
1. Что такое HTML?
2. Что такое HTTP? Как работает этот протокол?
3. Что такое веб-сервер?
4. Как пользоваться curl для отправки запросов по HTTP?
5. Как работает DNS?
6. Как устроена система пользователей и ролей в Linux?
7. Что такое процесс? Как nginx использует процессы для своей работы?
Вот примеры вопросов после второй задачи:
1. Что такое балансировка нагрузки? Какие варианты балансировки нагрузки существуют?
2. Что такое reversy proxy? Как можно настроить nginx для выполнения роли reverse proxy?
3. Что такое TCP/IP? Чем эти протоколы отличаются от HTTP?
4. Что такое пакетный менеджер? Какие есть пакетные менеджеры в дистрибутивах Linux? Как в деталях работают пакетные менеджеры?
Если вернуться к треду, то там автор предлагает: давать меньше поддержки, делать упор на конкретные задачи с отладкой, фокусироваться на проверке теории. Это совпадает с методикой, которую я создал. И это признак того, что мы движемся в правильную сторону.
Недавно я начал обучение GameDev-разработчика, который хочет переквалифицироваться в DevOps. С самого начала мы решили, что для обучения будем активно использовать ChatGPT. Это решение было основано на двух гипотезах:
1. ChatGPT позволит значительно сократить время обучения
2. Нужно сразу учиться решать задачи с использованием ChatGPT. Ведь в реальной работе это так и будет происходить
В итоге я сформировал следующую методику:
Обучение происходит путём выполнения конкретных приближенных к реальности задач. Есть выдуманный стартап под названием AI Tutor. Он разрабатывает бота-преподавателя. Студент работает в нём в качестве DevOps. По мере роста стартапа появляются всё новые задачи, которые нужно выполнять.
Примеры задач:
1. Нужно запустить лендинг стартапа. Для этого нужно на виртуалке AWS запустить nginx и захостить там простой лендинг. После чего купить и привязать домен. На виртуалке нужно организовать SSH-доступ для разработчика. Разработчик должен иметь права только на модификацию лендинга.
2. Прошли первые питчи, пошли первые посетители, стартапу теперь нужен блог. Нужно развернуть блог с использованием ghost и настроить роутинг в nginx, чтобы он был доступен по пути /blog на сайте лендинга. Кроме того, давайте сразу настроим отказоустойчивость. Ожидается посещение сайта серьезными партнёрами, поэтому он должен быть доступен всегда. Для этого нужно поднять вторую виртуалку AWS и создать балансировщик.
И так далее.
Я не объясняю студенту, как настраивать nginx или SSH. Ему об этом расскажет ChatGPT. Но как понять, что ChatGPT дал корректный ответ? Для этого у студента должен быть хороший теоретический фундамент. Если конкретные задачи это первый столп методики, то изучение теории - второй. Для этого в рамках каждой задачи я даю студенту вопросы, ответы на которые он должен подготовить (тоже с помощью ChatGPT, скорее всего).
Когда студент всё сделал, мы созваниваемся. Он показывает результат и отвечает на вопросы. Я корректирую и даю дополнительную информацию. Так мы формируем системные фундаментальные знания. Они позволят понять, что, к примеру, nginx и traefik это просто разные инструменты, но они могут решать общую задачу - роутинг. И теперь опыт работы с nginx может быть переложен на traefik. Создаётся система знаний.
Вот примеры вопросов после первой задачи:
1. Что такое HTML?
2. Что такое HTTP? Как работает этот протокол?
3. Что такое веб-сервер?
4. Как пользоваться curl для отправки запросов по HTTP?
5. Как работает DNS?
6. Как устроена система пользователей и ролей в Linux?
7. Что такое процесс? Как nginx использует процессы для своей работы?
Вот примеры вопросов после второй задачи:
1. Что такое балансировка нагрузки? Какие варианты балансировки нагрузки существуют?
2. Что такое reversy proxy? Как можно настроить nginx для выполнения роли reverse proxy?
3. Что такое TCP/IP? Чем эти протоколы отличаются от HTTP?
4. Что такое пакетный менеджер? Какие есть пакетные менеджеры в дистрибутивах Linux? Как в деталях работают пакетные менеджеры?
Если вернуться к треду, то там автор предлагает: давать меньше поддержки, делать упор на конкретные задачи с отладкой, фокусироваться на проверке теории. Это совпадает с методикой, которую я создал. И это признак того, что мы движемся в правильную сторону.
❤6👍4
В посте выше я писал, что в эпоху LLM мы должны изменить традиционные подходы к обучению. Фокус должен смещаться в сторону изучения фундаментальных принципов создания и поддержки программных систем. А конкретный синтаксис или API всегда можно узнать у условного ChatGPT.
Есть несколько способов изучения этих принципов, и один из них это чтение хороших книг. На мой взгляд, эталоном книги с фундаментальными знаниями является "Designing Data-Intensive Applications" Мартина Клеппмана (в русскоязычном сообществе известна под названием "Кабанчик") https://a.co/d/f2DYvKt. После её прочтения в голове формируется целостная картина принципов и технологий работы с данными. А это базы данных, очереди сообщений, кеши - всё то, что мы практически всегда используем в создаваемых нами системах. Каждый разработчик должен прочесть эту книгу.
И скоро выйдет второе издание! 🔥
Об этом автор книги Мартин Клеппман с соавтором второго издания Крисом Риккомини рассказали в сессии вопросов-ответов на Monster Scale Summit 2025 https://youtu.be/T-d1wR7adB8?si=jEVzB4w6eYE8Szz5. Кроме этого, они обсудили ряд современных трендов в работе с данными, таких как облачные хранилища, встроенные базы данных, расширения баз данных. Рекомендую к просмотру.
Что же нового будет во втором издании? Основной источник нового материала - это облачные технологии. С момента выхода первого издания книги прошло 8 лет, и за это время облачные хранилища данных, такие как AWS S3 и облачные БД, существенно повлияли на то, как мы проектируем системы работы с данными. Например, Grafana Loki, Tempo и Mimir используют не файловую систему, а объектные хранилища (AWS S3, Azure Blob Storage, Google Cloud Storage) для хранения данных. Этот тренд набирает популярность и нужно его систематизировать. Что и будет сделано во втором издании.
В общем, если вы ещё не читали "Кабанчика", то стоит подождать до декабря 2025 года, когда выйдет второе издание. А если читали, то тоже подождать и прочитать заново 🙂 И тогда можно не волноваться, что вас заменит ИИ. Наоборот, он станет вашим помощником, вместе с которым вы будете быстро создавать надёжные и производительные системы. 🚀
Есть несколько способов изучения этих принципов, и один из них это чтение хороших книг. На мой взгляд, эталоном книги с фундаментальными знаниями является "Designing Data-Intensive Applications" Мартина Клеппмана (в русскоязычном сообществе известна под названием "Кабанчик") https://a.co/d/f2DYvKt. После её прочтения в голове формируется целостная картина принципов и технологий работы с данными. А это базы данных, очереди сообщений, кеши - всё то, что мы практически всегда используем в создаваемых нами системах. Каждый разработчик должен прочесть эту книгу.
И скоро выйдет второе издание! 🔥
Об этом автор книги Мартин Клеппман с соавтором второго издания Крисом Риккомини рассказали в сессии вопросов-ответов на Monster Scale Summit 2025 https://youtu.be/T-d1wR7adB8?si=jEVzB4w6eYE8Szz5. Кроме этого, они обсудили ряд современных трендов в работе с данными, таких как облачные хранилища, встроенные базы данных, расширения баз данных. Рекомендую к просмотру.
Что же нового будет во втором издании? Основной источник нового материала - это облачные технологии. С момента выхода первого издания книги прошло 8 лет, и за это время облачные хранилища данных, такие как AWS S3 и облачные БД, существенно повлияли на то, как мы проектируем системы работы с данными. Например, Grafana Loki, Tempo и Mimir используют не файловую систему, а объектные хранилища (AWS S3, Azure Blob Storage, Google Cloud Storage) для хранения данных. Этот тренд набирает популярность и нужно его систематизировать. Что и будет сделано во втором издании.
В общем, если вы ещё не читали "Кабанчика", то стоит подождать до декабря 2025 года, когда выйдет второе издание. А если читали, то тоже подождать и прочитать заново 🙂 И тогда можно не волноваться, что вас заменит ИИ. Наоборот, он станет вашим помощником, вместе с которым вы будете быстро создавать надёжные и производительные системы. 🚀
👍3❤2⚡1
1 августа в Астане состоится концерт Дженнифер Лопес. Звёзды такой величины редко посещают Казахстан, поэтому это событие ожидаемо вызвало ажиотаж. Почитатели таланта знаменитости стали терпеливо ждать 11 апреля - день, когда в сервисе Ticketon должны были начаться продажи билетов. В первые минуты этого дня десятки тысяч покупателей устремились на сайт.
И сервис упал.
Ситуация, когда интернет-сервисы не справляются с нагрузкой и перестают стабильно работать, не является редкой. На это есть разные причины. Возможно, маркетологи недооценили спрос. Или техническая команда неверно рассчитала сколько железа необходимо. Или с нагрузкой не справились внешние сервисы. Ситуация плохая и она бьёт по репутации компании. Но всё же она не критичная. Обычно команда достаточно быстро находит причины падения и устраняет их. Те, кто не смог купить билеты сразу, могут это сделать через некоторое время.
Но в случае с Ticketon ситуация оказалась гораздо хуже.
После падения сервис подняли и люди продолжили покупать билеты. И только позже стало понятно, что Ticketon даёт возможность купить несколько билетов на одно и то же место💥
А вот это уже катастрофа. Представьте, что человек за 100 тысяч тенге купил билет и пришёл на концерт. А вокруг его места стоит ещё 5 человек с таким же билетом. На трибунах будет одна большая драка. И это сто процентов приведёт к срыву концерта.
Как только стала понятна проблема дублирования билетов, продажи тут же прекратили. Но множество одинаковых билетов уже было продано. Начались действия по минимизации ущерба. Кому-то смогли найти новые места, кому-то пришлось возвращать деньги вместа с компенсацией. Как итог - тысячи разгневанных клиентов, сотни миллионов тенге убытков для Ticketon и большой репутационный ущерб. Детали рекомендую прочитать в сообщениях руководителей Freedom Holding - компании, владеющей Ticketon. Вот сообщения Тимура Турлова - https://www.threads.net/@timurturlov/post/DIePx8Zt_VX Вот сообщения Алексея Ли - https://www.threads.net/@alexnomad/post/DIWntcuokzV
Как говорится, умные учатся на чужих ошибках. Поэтому давайте подумаем, как должны были отработать менеджмент и техническая команда Ticketon, чтобы исключить возможность подобных катастроф. И попробуем сформулировать конкретные рекомендации. Всё это в следующих постах.
И сервис упал.
Ситуация, когда интернет-сервисы не справляются с нагрузкой и перестают стабильно работать, не является редкой. На это есть разные причины. Возможно, маркетологи недооценили спрос. Или техническая команда неверно рассчитала сколько железа необходимо. Или с нагрузкой не справились внешние сервисы. Ситуация плохая и она бьёт по репутации компании. Но всё же она не критичная. Обычно команда достаточно быстро находит причины падения и устраняет их. Те, кто не смог купить билеты сразу, могут это сделать через некоторое время.
Но в случае с Ticketon ситуация оказалась гораздо хуже.
После падения сервис подняли и люди продолжили покупать билеты. И только позже стало понятно, что Ticketon даёт возможность купить несколько билетов на одно и то же место
А вот это уже катастрофа. Представьте, что человек за 100 тысяч тенге купил билет и пришёл на концерт. А вокруг его места стоит ещё 5 человек с таким же билетом. На трибунах будет одна большая драка. И это сто процентов приведёт к срыву концерта.
Как только стала понятна проблема дублирования билетов, продажи тут же прекратили. Но множество одинаковых билетов уже было продано. Начались действия по минимизации ущерба. Кому-то смогли найти новые места, кому-то пришлось возвращать деньги вместа с компенсацией. Как итог - тысячи разгневанных клиентов, сотни миллионов тенге убытков для Ticketon и большой репутационный ущерб. Детали рекомендую прочитать в сообщениях руководителей Freedom Holding - компании, владеющей Ticketon. Вот сообщения Тимура Турлова - https://www.threads.net/@timurturlov/post/DIePx8Zt_VX Вот сообщения Алексея Ли - https://www.threads.net/@alexnomad/post/DIWntcuokzV
Как говорится, умные учатся на чужих ошибках. Поэтому давайте подумаем, как должны были отработать менеджмент и техническая команда Ticketon, чтобы исключить возможность подобных катастроф. И попробуем сформулировать конкретные рекомендации. Всё это в следующих постах.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤2
Менеджмент и маркетинг.
1. Реалистичная оценка ажиотажа: Понятно, что JLo – это мегазвезда для Казахстана. Ожидать стандартной нагрузки было нельзя. Менеджменту следовало не просто предположить высокий спрос, а заложить в планы пиковую, возможно, даже чрезмерную нагрузку, исходя из масштаба события и медийного шума. Это включает коммуникацию с технической командой о порядке ожидаемых цифр (не "будет много", а "ожидаем X десятков тысяч одновременных запросов в первую минуту").
2. Стратегия продаж: Запуск всех билетов одномоментно в полночь – классический рецепт для создания пиковой нагрузки. Менеджмент мог рассмотреть альтернативы:
* Предрегистрация/лотерея: Собрать заявки заранее и распределить возможность покупки.
* Поэтапный старт: Начинать продажи по секторам или ценовым категориям с интервалом в несколько часов.
* Очередь: Внедрить систему виртуальной очереди, которая пропускает на сайт ограниченное количество пользователей одновременно. Да, это тоже вызывает недовольство ожидающих, но предотвращает падение и хаос.
3. Коммуникация: Заранее предупредить пользователей о возможном высоком спросе и потенциальных сложностях, объяснить, как будет работать система (если используется очередь или поэтапный старт). Это управляет ожиданиями.
1. Реалистичная оценка ажиотажа: Понятно, что JLo – это мегазвезда для Казахстана. Ожидать стандартной нагрузки было нельзя. Менеджменту следовало не просто предположить высокий спрос, а заложить в планы пиковую, возможно, даже чрезмерную нагрузку, исходя из масштаба события и медийного шума. Это включает коммуникацию с технической командой о порядке ожидаемых цифр (не "будет много", а "ожидаем X десятков тысяч одновременных запросов в первую минуту").
2. Стратегия продаж: Запуск всех билетов одномоментно в полночь – классический рецепт для создания пиковой нагрузки. Менеджмент мог рассмотреть альтернативы:
* Предрегистрация/лотерея: Собрать заявки заранее и распределить возможность покупки.
* Поэтапный старт: Начинать продажи по секторам или ценовым категориям с интервалом в несколько часов.
* Очередь: Внедрить систему виртуальной очереди, которая пропускает на сайт ограниченное количество пользователей одновременно. Да, это тоже вызывает недовольство ожидающих, но предотвращает падение и хаос.
3. Коммуникация: Заранее предупредить пользователей о возможном высоком спросе и потенциальных сложностях, объяснить, как будет работать система (если используется очередь или поэтапный старт). Это управляет ожиданиями.
👍4
Техническая команда.
1. Нагрузочное тестирование: Это альфа и омега подготовки к таким событиям. Нужно было не просто проверить, что сайт работает, а симулировать реалистичный сценарий: одновременный заход десятков тысяч пользователей, массовые запросы к базе данных (проверка наличия мест, создание заказов). Тестирование должно выявить "узкие места" – будь то серверные мощности, пропускная способность сети, неоптимизированные запросы к БД или проблемы во внешних сервисах (например, эквайринг).
2. Масштабируемая архитектура: Современные облачные технологии позволяют гибко наращивать мощности (auto-scaling) под нагрузку. Команда должна была убедиться, что инфраструктура настроена на автоматическое или быстрое ручное масштабирование всех компонентов системы: веб-серверов, серверов приложений, баз данных.
3. Оптимизация: Проанализировать и оптимизировать самые ресурсоемкие операции, особенно те, что связаны с проверкой и бронированием мест. Использовать кэширование где возможно (например, для статической информации о мероприятии).
4. Самое главное! - предотвращение продажи дубликатов: Вот здесь и произошла катастрофа. Падение сервера – полбеды. Продажа одного места нескольким людям – это фундаментальная ошибка в логике приложения или управлении данными. Как это предотвратить:
* Атомарность операций: Процесс "проверить доступность места -> занять место -> создать заказ" должен быть атомарным. Это означает, что он либо выполняется целиком и успешно, либо полностью откатывается, если на каком-то этапе произошел сбой или место уже занято другим запросом. Это достигается с помощью механизмов транзакций в базах данных.
* Блокировки: При попытке купить конкретное место, на него должна ставиться блокировка на короткое время (пока идет оформление), чтобы другой процесс не мог его занять. Важно использовать правильный уровень изоляции транзакций и грамотно управлять блокировками, чтобы не парализовать систему, но гарантировать эксклюзивность места.
* Уникальные ограничения (unique constraints): На уровне базы данных должно быть жесткое ограничение, не позволяющее добавить две записи с одинаковым местом на одно и то же мероприятие. Это последняя линия обороны, которая не даст записать дубликат, даже если логика приложения даст сбой.
* Тестирование конкурентного доступа: Нужно было специально тестировать сценарии, когда несколько "покупателей" одновременно пытаются купить одно и то же место. Эти тесты должны доказать, что система корректно обрабатывает такие "гонки запросов" (race conditions).
5. План действий при сбоях (incident response plan): Что делать, если система все-таки упала? Как быстро ее поднять? Критически важно: перед тем как снова открывать продажи после сбоя, необходимо провести проверку целостности данных. Убедиться, что не возникло аномалий вроде "подвисших" заказов или некорректного статуса мест. Похоже, именно этот шаг был пропущен, что и привело к продаже дублей после восстановления работы.
Катастрофа с Ticketon – это результат целого комплекса проблем: недооценка нагрузки менеджментом, недостаточная подготовка и тестирование со стороны технической команды, и, вероятно, отсутствие должного контроля и стратегического видения со стороны технического руководства (CTO) в части обеспечения фундаментальной надежности критически важной функции – продажи уникального товара (билета на место). Падение сервера – это плохо. Продажа дубликатов – это показатель системного сбоя на уровне архитектуры, процессов разработки и тестирования.
Ticketon обещали опубликовать постмортем, где они опишут все причины, приведшие к этой ситуации. Посмотрим, насколько они будут пересекаться с тем, что я написал выше.
Этот случай – болезненный, но ценный урок для всей IT-индустрии Казахстана о том, насколько важен не только внешний функционал сервиса, но и его внутренняя надежность, особенно когда на кону стоят большие деньги и доверие тысяч людей. Надеюсь, нужные выводы будут сделаны и подобных ситуаций в будущем удастся избежать.
1. Нагрузочное тестирование: Это альфа и омега подготовки к таким событиям. Нужно было не просто проверить, что сайт работает, а симулировать реалистичный сценарий: одновременный заход десятков тысяч пользователей, массовые запросы к базе данных (проверка наличия мест, создание заказов). Тестирование должно выявить "узкие места" – будь то серверные мощности, пропускная способность сети, неоптимизированные запросы к БД или проблемы во внешних сервисах (например, эквайринг).
2. Масштабируемая архитектура: Современные облачные технологии позволяют гибко наращивать мощности (auto-scaling) под нагрузку. Команда должна была убедиться, что инфраструктура настроена на автоматическое или быстрое ручное масштабирование всех компонентов системы: веб-серверов, серверов приложений, баз данных.
3. Оптимизация: Проанализировать и оптимизировать самые ресурсоемкие операции, особенно те, что связаны с проверкой и бронированием мест. Использовать кэширование где возможно (например, для статической информации о мероприятии).
4. Самое главное! - предотвращение продажи дубликатов: Вот здесь и произошла катастрофа. Падение сервера – полбеды. Продажа одного места нескольким людям – это фундаментальная ошибка в логике приложения или управлении данными. Как это предотвратить:
* Атомарность операций: Процесс "проверить доступность места -> занять место -> создать заказ" должен быть атомарным. Это означает, что он либо выполняется целиком и успешно, либо полностью откатывается, если на каком-то этапе произошел сбой или место уже занято другим запросом. Это достигается с помощью механизмов транзакций в базах данных.
* Блокировки: При попытке купить конкретное место, на него должна ставиться блокировка на короткое время (пока идет оформление), чтобы другой процесс не мог его занять. Важно использовать правильный уровень изоляции транзакций и грамотно управлять блокировками, чтобы не парализовать систему, но гарантировать эксклюзивность места.
* Уникальные ограничения (unique constraints): На уровне базы данных должно быть жесткое ограничение, не позволяющее добавить две записи с одинаковым местом на одно и то же мероприятие. Это последняя линия обороны, которая не даст записать дубликат, даже если логика приложения даст сбой.
* Тестирование конкурентного доступа: Нужно было специально тестировать сценарии, когда несколько "покупателей" одновременно пытаются купить одно и то же место. Эти тесты должны доказать, что система корректно обрабатывает такие "гонки запросов" (race conditions).
5. План действий при сбоях (incident response plan): Что делать, если система все-таки упала? Как быстро ее поднять? Критически важно: перед тем как снова открывать продажи после сбоя, необходимо провести проверку целостности данных. Убедиться, что не возникло аномалий вроде "подвисших" заказов или некорректного статуса мест. Похоже, именно этот шаг был пропущен, что и привело к продаже дублей после восстановления работы.
Катастрофа с Ticketon – это результат целого комплекса проблем: недооценка нагрузки менеджментом, недостаточная подготовка и тестирование со стороны технической команды, и, вероятно, отсутствие должного контроля и стратегического видения со стороны технического руководства (CTO) в части обеспечения фундаментальной надежности критически важной функции – продажи уникального товара (билета на место). Падение сервера – это плохо. Продажа дубликатов – это показатель системного сбоя на уровне архитектуры, процессов разработки и тестирования.
Ticketon обещали опубликовать постмортем, где они опишут все причины, приведшие к этой ситуации. Посмотрим, насколько они будут пересекаться с тем, что я написал выше.
Этот случай – болезненный, но ценный урок для всей IT-индустрии Казахстана о том, насколько важен не только внешний функционал сервиса, но и его внутренняя надежность, особенно когда на кону стоят большие деньги и доверие тысяч людей. Надеюсь, нужные выводы будут сделаны и подобных ситуаций в будущем удастся избежать.
👍15
Ситуация с Тикетоном вызвала большой резонанс в среде казахстанских ИТ-специалистов. Её много обсуждали, примеряли на себя, думали, как поступили бы они. А группа ребят из чата тимлидов Казахстана (включая меня) решила провести хакатон, где команды будут проектировать и реализовывать базовый функционал аналога Тикетона. А затем эти решения будут подвергаться нагрузкам, чтобы оценить их производительность и корректность. Следующим постом скину предварительный анонс этого мероприятия.
Forwarded from Stanislav Belyaev
Привет!
Мы в чате Тимлидов (@teamleads_kz) по итогу обсуждения сложностей проектирования высоконагруженных систем, пришли к выводу что в Казахстане есть потенциальный запрос на проведение образовательного Хакатона на эту тему.
Мы готовы взять на себя полностью организацию и подготовку инфраструктуры, но нужно понять есть ли запрос или интерес к этому мероприятию со стороны сообществ разработки.
Если вы разработчик и готовы принять участие в хакатоне по разработке высоконагруженного сервиса - заполните опросник:
https://forms.gle/W7tTdGAwEXTZKHR4A
О мероприятии:
Предварительные планы на Август 2025 года. Задача - разработать командой сервис, который способен будет выдержать нагрузку по покупке билетов (на подобии Тикетона), при этом не сломав бизнес-сценарии и не допустив потерь бизнесу (двойные продажи билетов, противостояние фроду, выдержать нагрузку и т.д.). Пример задания
Мы готовы приветствовать среди участников как студентов, начинающих специалистов, так и опытных разработчиков, готовых применить свои навыки на практике в отличной от ваших рабочих задач среде.
Мероприятие будет в Алмате, возможно подключиться онлайн. Ожидаем, что это будет бесплатное мероприятие, но зависит от предварительного спроса. Если будет большой спрос на данное мероприятие, то могут быть введены критерии отбора. Но это мы уточним только когда поймет спрос. Для этого, ждем ваши ответы в форму. Спасибо!
Мы в чате Тимлидов (@teamleads_kz) по итогу обсуждения сложностей проектирования высоконагруженных систем, пришли к выводу что в Казахстане есть потенциальный запрос на проведение образовательного Хакатона на эту тему.
Мы готовы взять на себя полностью организацию и подготовку инфраструктуры, но нужно понять есть ли запрос или интерес к этому мероприятию со стороны сообществ разработки.
Если вы разработчик и готовы принять участие в хакатоне по разработке высоконагруженного сервиса - заполните опросник:
https://forms.gle/W7tTdGAwEXTZKHR4A
О мероприятии:
Предварительные планы на Август 2025 года. Задача - разработать командой сервис, который способен будет выдержать нагрузку по покупке билетов (на подобии Тикетона), при этом не сломав бизнес-сценарии и не допустив потерь бизнесу (двойные продажи билетов, противостояние фроду, выдержать нагрузку и т.д.). Пример задания
Мы готовы приветствовать среди участников как студентов, начинающих специалистов, так и опытных разработчиков, готовых применить свои навыки на практике в отличной от ваших рабочих задач среде.
Мероприятие будет в Алмате, возможно подключиться онлайн. Ожидаем, что это будет бесплатное мероприятие, но зависит от предварительного спроса. Если будет большой спрос на данное мероприятие, то могут быть введены критерии отбора. Но это мы уточним только когда поймет спрос. Для этого, ждем ваши ответы в форму. Спасибо!
🔥4
Каждые 2 недели мы в сообществе Drim Team проводим семинары по использованию ИИ. Там мы изучаем возможности современных инструментов. В частности, мы концентрируемся на использовании ИИ для помощи в программировании. Изучаем, как устроены LLM. Изучаем, какие есть инструменты. Пробуем использовать эти инструменты. Делимся практическим опытом. Цель - найти такие сценарии использования ИИ, которые позволят каждому из нас в разы повысить свою производительность.
В эту субботу мы провели очередной созвон. На нём мы попробовали использовать Cursor. В отличие от AI-ассистентов типа GitHub Copilot, которые помогают писать код в каком-то конкретном файле, Cursor - это пример AI-агента. Его отличие в том, что он оперирует всем проектом. Для решения задачи он может добавлять новые файлы, редактировать существующие, выполнять команды в консоли.
В качестве проекта мы взяли наш учебный проект Drimstarter (аналог Kickstarter). И попросили Cursor добавить операцию создания проекта. Следует отметить, что в Drimstarter мы используем Vertical Slices Architecture, которая используется реже классической слоёной архитектуры. То есть Cursor должен был понять, что используется именно этот подход и файлы нужно создавать в соответствии с ним. Мы ввели запрос на русском языке "Реализуй функцию CreateProject по аналогии с функцией CreateCategory" и стали смотреть, что получится.
Следующие наши эмоции можно сравнить с теми эмоциями, которые все испытывали, когда первый раз использовали ChatGPT. Это фантастика. Cursor дописал proto-файлы, написал эндпоинт ASP.NET Core, хендлер операции и валидатор. После этого он попытался скомпилировать код и получил несколько ошибок компиляции. На основании ошибок он внёс правки и скомпилировал снова. На этот раз ошибок не было.
Затем мы попросили Cursor написать тесты. Он быстро сделал и это. Правда, в этот раз было несколько моментов, которые он не учёл. Мы быстро их поправили и запустили тесты. Они были зелёные 🤯 Среди участников звонка повисла тишина. То, на что нужно было потратить час, Cursor сделал за 10 минут. Определённо, на более сложных задачах, результат может быть не таким прямолинейным. Но у Cursor есть система правил, которые помогают ему адаптироваться к структуре и соглашениям проекта, повышая качество его работы.
В конце семинара мы все сошлись на том, что теперь нам нужно устанавливать Cursor и начинать его использовать для рабочих задач. На следующих семинарах мы поделимся полученным опытом и расскажем о результатах. Но всем уже очевидно, что такие инструменты как Cursor сильно изменят то, как мы программируем.
В эту субботу мы провели очередной созвон. На нём мы попробовали использовать Cursor. В отличие от AI-ассистентов типа GitHub Copilot, которые помогают писать код в каком-то конкретном файле, Cursor - это пример AI-агента. Его отличие в том, что он оперирует всем проектом. Для решения задачи он может добавлять новые файлы, редактировать существующие, выполнять команды в консоли.
В качестве проекта мы взяли наш учебный проект Drimstarter (аналог Kickstarter). И попросили Cursor добавить операцию создания проекта. Следует отметить, что в Drimstarter мы используем Vertical Slices Architecture, которая используется реже классической слоёной архитектуры. То есть Cursor должен был понять, что используется именно этот подход и файлы нужно создавать в соответствии с ним. Мы ввели запрос на русском языке "Реализуй функцию CreateProject по аналогии с функцией CreateCategory" и стали смотреть, что получится.
Следующие наши эмоции можно сравнить с теми эмоциями, которые все испытывали, когда первый раз использовали ChatGPT. Это фантастика. Cursor дописал proto-файлы, написал эндпоинт ASP.NET Core, хендлер операции и валидатор. После этого он попытался скомпилировать код и получил несколько ошибок компиляции. На основании ошибок он внёс правки и скомпилировал снова. На этот раз ошибок не было.
Затем мы попросили Cursor написать тесты. Он быстро сделал и это. Правда, в этот раз было несколько моментов, которые он не учёл. Мы быстро их поправили и запустили тесты. Они были зелёные 🤯 Среди участников звонка повисла тишина. То, на что нужно было потратить час, Cursor сделал за 10 минут. Определённо, на более сложных задачах, результат может быть не таким прямолинейным. Но у Cursor есть система правил, которые помогают ему адаптироваться к структуре и соглашениям проекта, повышая качество его работы.
В конце семинара мы все сошлись на том, что теперь нам нужно устанавливать Cursor и начинать его использовать для рабочих задач. На следующих семинарах мы поделимся полученным опытом и расскажем о результатах. Но всем уже очевидно, что такие инструменты как Cursor сильно изменят то, как мы программируем.
👍3
Разработка с помощью AI-агентов сильно отличается от обычной разработки. Это имеет как плюсы, так и минусы. Среди плюсов - значительное повышение производительности программиста. Среди минусов - атрофия навыков самостоятельной разработки. Необходимо явно осознавать этот риск и принимать меры, чтобы избежать атрофии. На эту тему у нас недавно было интересное обсуждение.
Дархан Изтлеу:
"Немного мыслей после вчерашней встречи)
Начну с того, что я услышал новость (оригинала, к сожалению, нет) о том, что средняя оценка по экзаменам у студентов-инженеров стала худшей во второй половине 2024 года. Та же история наблюдается и в школах.
Не трудно догадаться что могло повлиять на это)
Давайте поговорим о работе мозга. Он очень ленивый: создавать новые нейронные связи — дорого, и поддерживать их тоже. Поэтому мозг пытается всё автоматизировать. Возьмём, к примеру, тот же поход до работы: большинство даже не замечают, как добираются, сколько ступенек преодолевают по пути. В этом есть плюс — мы можем думать о чём-то другом. Но стоит изменить высоту одной ступеньки, и мы споткнёмся. И вот когда у нас есть такой замечательный инструмент как «большая языковая модель», мне кажется человек даже сам того не осознавая, просто перестает учится. А зачем, если можно спихнуть эту работу на GPT!
К чему я это? Я стал всё чаще использовать ИИ в работе, и это сильно повысило мою продуктивность. Однако не стоит забывать об обратной стороне этой технологии — деградации собственных мыслительных способностей. Ведь к хорошему быстро привыкаешь (попробуйте сейчас что-то найти в тексте без `Ctrl+F`).
Для себя я решил: теперь нужно решать задачи на LeetCode, отключая все подсказки IDE (вроде Copilot) или просто используя встроенный редактор на сайте. Можно даже перерешивать уже решённые задачи — делать так называемые «упражнения Като». Ещё лучше — использовать разные языки программирования.
В общем, в интересное время мы живём. Кажется, современные LLM — это одна из тех технологий, которые создают хорошие времена а как мы знаем … *«Хорошие времена рождают слабых людей»* — и сейчас, как никогда, важно развивать себя."
Дмитрий Мельник:
"Ты поднял важную тему. Я согласен с тобой. Теперь, когда мы увидели, как инструменты типа Cursor могут программировать, становится очевидно, что код мы будем писать по-другому. Мы будем просто следить, что пишет ИИ, и подтверждать или поправлять его. И это изменит нейронные связи в нашем мозгу. Произойдёт атрофия.
Можно провести аналогию с физической активностью. До 20 века большинство людей работало физически. Но в 20 веке технологии позволили многим начать работать сидя в офисе. И у людей появились проблемы с физической формой. И поэтому появились фитнес-клубы, в которые люди начали ходить специально, чтобы поддерживать физические кондиции. Я думаю, ИИ приводит нас к тому же сценарию. Только на этот раз начнут проседать не физические способности, а интеллектуальные. Поэтому теперь нужно заниматься внерабочими активностями для поддержания интеллектуальной формы. Очень возможно, что появятся клубы для таких тренировок.
Решение задач на LeetCode - хороший пример такой внерабочей активности. Но я бы добавил ещё другие. К примеру, написание полноценных приложений без помощи ИИ. Чтобы не утратить навыков структурирования и детализации архитектуры и кода. Вообще, перед нами открывается область, где мы увидим много интересного. Но каждый уже сейчас должен понять, что нужно явно заниматься тренировкой своего ума. Иначе мы станем просто придатками машины."
Дархан Изтлеу:
"Немного мыслей после вчерашней встречи)
Начну с того, что я услышал новость (оригинала, к сожалению, нет) о том, что средняя оценка по экзаменам у студентов-инженеров стала худшей во второй половине 2024 года. Та же история наблюдается и в школах.
Не трудно догадаться что могло повлиять на это)
Давайте поговорим о работе мозга. Он очень ленивый: создавать новые нейронные связи — дорого, и поддерживать их тоже. Поэтому мозг пытается всё автоматизировать. Возьмём, к примеру, тот же поход до работы: большинство даже не замечают, как добираются, сколько ступенек преодолевают по пути. В этом есть плюс — мы можем думать о чём-то другом. Но стоит изменить высоту одной ступеньки, и мы споткнёмся. И вот когда у нас есть такой замечательный инструмент как «большая языковая модель», мне кажется человек даже сам того не осознавая, просто перестает учится. А зачем, если можно спихнуть эту работу на GPT!
К чему я это? Я стал всё чаще использовать ИИ в работе, и это сильно повысило мою продуктивность. Однако не стоит забывать об обратной стороне этой технологии — деградации собственных мыслительных способностей. Ведь к хорошему быстро привыкаешь (попробуйте сейчас что-то найти в тексте без `Ctrl+F`).
Для себя я решил: теперь нужно решать задачи на LeetCode, отключая все подсказки IDE (вроде Copilot) или просто используя встроенный редактор на сайте. Можно даже перерешивать уже решённые задачи — делать так называемые «упражнения Като». Ещё лучше — использовать разные языки программирования.
В общем, в интересное время мы живём. Кажется, современные LLM — это одна из тех технологий, которые создают хорошие времена а как мы знаем … *«Хорошие времена рождают слабых людей»* — и сейчас, как никогда, важно развивать себя."
Дмитрий Мельник:
"Ты поднял важную тему. Я согласен с тобой. Теперь, когда мы увидели, как инструменты типа Cursor могут программировать, становится очевидно, что код мы будем писать по-другому. Мы будем просто следить, что пишет ИИ, и подтверждать или поправлять его. И это изменит нейронные связи в нашем мозгу. Произойдёт атрофия.
Можно провести аналогию с физической активностью. До 20 века большинство людей работало физически. Но в 20 веке технологии позволили многим начать работать сидя в офисе. И у людей появились проблемы с физической формой. И поэтому появились фитнес-клубы, в которые люди начали ходить специально, чтобы поддерживать физические кондиции. Я думаю, ИИ приводит нас к тому же сценарию. Только на этот раз начнут проседать не физические способности, а интеллектуальные. Поэтому теперь нужно заниматься внерабочими активностями для поддержания интеллектуальной формы. Очень возможно, что появятся клубы для таких тренировок.
Решение задач на LeetCode - хороший пример такой внерабочей активности. Но я бы добавил ещё другие. К примеру, написание полноценных приложений без помощи ИИ. Чтобы не утратить навыков структурирования и детализации архитектуры и кода. Вообще, перед нами открывается область, где мы увидим много интересного. Но каждый уже сейчас должен понять, что нужно явно заниматься тренировкой своего ума. Иначе мы станем просто придатками машины."
👍3❤2👌1
Вы используете ИИ-агентов для разработки? ИИ-агент это приложение, которое может самостоятельно писать код, создавая новые файлы и редактируя существующие. Примеры - Cursor, Windsurf, Bolt, JetBrains AI Assistant.
Anonymous Poll
32%
Да
29%
Нет, но планирую начать
24%
Нет, и пока не планирую
16%
Хочу посмотреть ответы
Forwarded from Data Secrets
Выпустили 2 MoE и 6 dense моделей в весах на любой вкус, 0.6В до 235B. Разбираем.
Самая большая модель на уровне со всеми звездами – Gemini 2.5 Pro, Grok-3, o1, R1. И это MoE всего с 22В активных параметров. На 30В MoE модель тоже крутая получилась: на бенчах видно, что она лучше предыдущего ризонера QwQ-32B (при этом активных параметров у нее всего 3В, то есть в 10 раз меньше).
Что еще чтоит знать:
1. Это полу-ризонеры, как Sonnet 3.7 или Gemini 2.5 Pro. То есть модель будет «думать», если задать мод think, и не думать, если задать Non-Thinking. Бюджет рассуждений тоже можно контролировать.
2. Модели мультиязычные (русский тоже есть), но не мультимодальные. Довольствуемся тем, что есть.
3. Улучшены агентные способности на уровне поиска в браузере, использования интерпретатора и др. Что особенно приятно – добавили поддержку MCP.
4. Претрейнинг был в три этапа: сначала на 30 триллионах токенов с контекстом 4К, затем отдельно на сложных научных текстах (5Т), потом на длинных контекстах до 32К токенов.
5. Пост-трейнинг: файн-тюнинг на CoT + несколько стадий RL. Интересно, что мелкие модели до 30В обучали дистилляцией из крупных.
В общем, пробуем и наслаждаемся здесь
Веса | Блогпост | Гитхаб
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM