Drim Dev

Опубликовали на YouTube запись вчерашней лекции про финтех - https://youtu.be/bKJ-bzcTm7U?si=IR2Z09Wytzv6Vahv. Это первая лекция из цикла лекций про финтех. В ней мы обсудили фундаментальные технологии этой индустрии, такие как эквайринг и поставщики платёжных услуг, заложив тем самым фундамент для дальнейшего развития. После лекции участники высоко оценили качество и ценность материала, поэтому всем рекомендую к просмотру ☀️.

Напоминаем, что сегодня в 20:00 по времени Астаны Дмитрий Мельник проведёт открытую онлайн-лекцию на тему "Введение в финтех на примере поставщика платёжных услуг Stripe" (тема немного изменилась с момента прошлого анонса). Это первая лекция из планируемого цикла открытых лекций про финтех. После прохождения цикла участники смогут хорошо ориентироваться в том, как устроен финтех. Это индустрия, которая по прогнозам вырастет до 700 миллиардов долларов к 2030 году. Сейчас объем рынка составляет 200 миллиардов долларов. То есть прогнозируется рост в 3 раза. Это создаёт много возможностей как для предпринимателей, так и для разработчиков в этой сфере - можно построить успешную карьеру 💰. Подписывайтесь на канал @drim_channel, чтобы узнавать о следующих лекциях. Ссылка на Google Meet, где будет проведена сегодняшняя лекция - meet.google.com/uay-qcfe-fgs Приходите на лекцию и начните свой путь в мире финтеха 🚀

18 декабря в 20:00 по времени Астаны Дмитрий Мельник проведёт публичный семинар на тему "Использование платёжного шлюза Stripe для приёма онлайн-платежей". Это первый семинар из цикла на тему платёжных систем. На нём участники узнают, какие есть платёжные шлюзы, и какие проблемы они решают. После этого мы посмотрим, как организовать на сайте приём платежей за товары и услуги с помощью популярного сервиса Stripe. Бекенд демонстрационного приложения будет создан с помощью ASP.NET Core 9, а фронтенд - с помощью React и Next.js. На следующих семинарах из цикла мы изучим более продвинутые возможности платёжных шлюзов, такие как подписки и отложенные платежи. Приходите, будет интересно и полезно! Ссылка на событие - https://www.meetup.com/drim-events/events/304858560. Вступайте в группу https://www.meetup.com/drim-events, чтобы не пропустить это событие и узнавать о новых 🚀 Ссылка на Google Meet - meet.google.com/uay-qcfe-fgs Больше информации о Drim можно получить на сайте https://drim.dev/.

Вчера я запустил лендинг Drim - https://drim.dev/ На сайте можно прочитать о всех предложениях по развитию и обучению. Кроме того, можно почитать отзывы участников. Буду благодарен, если поделитесь ссылкой с теми, кому это может быть полезно.

Я решил изменить язык канала с английского на русский. Причина в том, что на текущем этапе развитие Drim будет сфокусировано на рынке СНГ. Русский язык позволит расширить аудиторию канала и сделать его более полезным.

If you are interested but don't know if you have the necessary skills, I can assess them by calling and talking to you.

My friend Askhat Omarov is looking for a tech lead for his product https://farel.io. I can recommend Askhat as a competent manager who has created a team of senior and lead level specialists. Contact me @mitro52 if you are interested. Here is the position description: Farel is a San Francisco-based startup revolutionizing how airlines manage inventory and sales with our cutting-edge SaaS platform. We’ve raised over $4M from top-tier Silicon Valley investors, including Y Combinator (the launchpad for companies like Airbnb, Dropbox, and Coinbase). Our previous team successfully built an online travel agency (OTA) that was acquired by a publicly-traded company. With a diverse and dynamic global team across the US, Georgia, Turkiye, Kazakhstan, Brazil, and Mexico, we are ambitiously pushing the boundaries of the aviation industry. We are looking for a Tech Lead to join our growing team and help bridge the gap between business requirements and technical execution. In this role, you will ensure that our system architecture is cohesive, scalable, and aligned with business objectives. You will take ownership of the technical vision, work closely with business and engineering teams and provide leadership in making key decisions. Key Responsibilities: • Design, review, and approve architectural solutions for new and existing features, ensuring seamless integration and scalability across the platform • Act as a bridge between product managers and developers, ensuring business requirements are effectively translated into technical implementations • Lead discussions on technical challenges and solutions, providing clear guidance to the development team, and making authoritative technical decisions • Collaborate with product managers and developers to define technical project roadmaps, aligning them with business goals and ensuring efficient resource utilization • Establish and promote software engineering best practices for code quality, security, and system performance, with a focus on sustainable long-term architecture • Provide technical guidance and mentorship to backend and frontend developers, helping them grow their skills and ensure alignment with the overall architecture • Maintain a high-level view of the project, identifying potential bottlenecks and areas for improvement, and ensure that all technical decisions contribute to the broader business strategy Qualifications: • 6+ years of experience in software architecture, solution design, or technical leadership roles • Deep technical knowledge of Spring, Spring Boot, PostgreSQL, Angular, Azure, Kubernetes, and GitLab. Proven experience translating business requirements into robust technical solutions • Strong communication and interpersonal skills, with the ability to influence both technical and non-technical stakeholders • A passion for solving technical challenges while understanding the broader business context. Additional Skills: • Experience working with cross-functional teams in a startup environment. • Ability to make high-stakes decisions and take responsibility for their outcomes. • Understanding of BPMN and workflow design, a plus.

A video recording of the ADR seminar can be found at https://youtu.be/iOuRxI0dbPo

Join the online meeting where we will discuss architectural decision records. https://www.meetup.com/drim-events/events/303461315/

Do you want to become a more proficient developer? Do you want to improve your software architecture skills? Do you want to make better software design decisions? Do you want to build software faster and with greater quality? Use architectural decision records. What is it? An architectural decision record is a document that captures a significant architectural decision made during software system development. It records the reasoning behind the decision, the context in which it was made, and any alternatives that were considered. The primary purpose of an ADR is two-fold. First, it gives the team a concrete process for making architectural decisions. Second, it aims to provide future developers, architects, and stakeholders with the historical context of why the team chose a particular approach. Let's look at an example. Suppose you are developing a microservices application and decide to use gRPC as a communication method. You create a diagram depicting the microservices and arrows between them labeled "gRPC." With this approach, you document what design decision you've made. But you don't document why you've made this decision. Is it necessary to elaborate on the "why" side? Yes, it is. Here are the reasons: 1. The formal process of decision documenting forces the team members to think more thoroughly about possible design options and their trade-offs, thus reducing the number of poor choices. 2. Team members can review decisions using pull requests, allowing them to do so asynchronously and more thoughtfully. 3. If a team member has any questions about implementing a feature, ADRs are a good place to consult and learn how to do it. 4. Evolving the system design and architecture will be easier based on the decision history. 5. New team members can read through all ADRs and quickly gain a broad understanding of the system design and implementation, thus reducing onboarding time. 6. Writing ADRs is an excellent exercise for improving software design skills. Returning to the gRPC example, you can see what an ADR regarding this decision can look like. It is an ADR from the Drimstarter project (we'll talk about this project later) https://github.com/drim-dev/drimstarter/blob/develop/documents/adrs/backend/0001-grpc-communication.md. I described the basic idea of ADRs and hope you will consider using them on your projects. In future posts, we will discuss specific details and formats. Before that, you can consult a couple of excellent resources on ADRs: * https://adr.github.io/ * https://github.com/joelparkerhenderson/architecture-decision-record I will be glad to hear your questions and feedback in the comments.