Adrin Amin Salehi
Software Developer and IT Consultant
Basel, Switzerland
Adrin is a software developer and IT consultant working with industry clients to create amazing apps with Azure and .NET.
When he was seven years old, his dad bought their first Windows 95 PC. From that moment on, he was amazed by the personal computer. He has been programming with C # since school but due to university and intrinsic curiosity, he broadened his horizon with other programming languages like C++, Java, and Python. As a tech enthusiast, Adrin also focuses a lot on cloud computing, IoT, and AI.
Links
Area of Expertise
Topics
terraform + Azure + Gitlab = ❤️ ?
Heutzutage können verschiedenste Tools und tech stacks miteinander kombiniert werden, aber macht das überhaupt Sinn?
In diesem Vortrag geht es um das Zusammenspiel von Terraform, Azure und GitLab zur Umsetzung von Infrastructure-as-Code. Ich möchte mit euch meine Erfahrungen bei der Implementierung von Terraform-Code teilen und zeigen, wie Azure als Cloud-Provider und GitLab als Versionskontrollsystem optimal aufgesetzt werden kann, um mögliche Risiken und Probleme im weiteren Verlauf der Applikationsentwicklung zu minimieren.
Wir diskutieren auch, wie diese Tools zusammenarbeiten, um ein nahtloses Entwicklererlebnis zu schaffen. Lasst uns gemeinsam herausfinden, ob Terraform, Azure und GitLab wirklich Liebe auf den ersten Blick ist 🥰 !
The story of building a Visual Studio Add-On, using DDD and CQRS.
We use DDD and CQRS in every new project.
This came as a no-brainer to us in the team, so we decided to rely on these technologies when developing our new applications.
I want to take you on a journey to experience the joys and perils of using DDD and CQRS in a project with many dependencies on other systems. How will this ubiquitous language help us?
How are we going to deal with the many dependencies?
Will we have to adopt the principles of DDD and CQRS to real-world conditions? Or will we have to throw it all overboard altogether?
I can say one thing already: We will be amazed at where the decisions on DDD and CQRS will lead us. We will have more systems than we expected at the beginning - some complex, some less complex. We will gain important insights that will help us plan future projects much better and avoid risks early on.
In this talk, we will have a look at the architecture of a Real-World project that consists of, among other things, a Visual Studio Add-On, which we tried to implement using the ideas and principles of DDD and CQRS.
Building small and highly scalable REST APIs with .NET 6 and Azure Functions
REST is now around for more than 20 years. It's a critical architectural style in creating a standard communication format between computer systems. Nowadays, it is one of the most used foundations for modern web APIs. ASP.NET Core Web gives us an easy way to write clean and simple REST APIs in .NET. But what if we want to leverage serverless capabilities from the cloud? What if we're going to write a serverless REST API that is highly scalable and easy to deploy?
Here is where Azure Functions come into play. Azure Functions is a serverless offer from Microsoft Azure where you can easily create, build and deploy highly scalable serverless functions.
In this talk, I want to demonstrate how to build a REST API fast and easy with Azure Functions and .NET 6. What are the benefits, and might there be any drawbacks? Are there any stepping stones? And how we can leverage Azure Functions and .NET 6 to create awesome REST APIs.
Verifizieren von Business Rules mit Hilfe einer Testing-API
Automatisierte Tests sind ein integraler Bestandteil der Softwareentwicklung. Produktivcode sollte immer, so gut es geht, mit Code Tests (unit, integration, end-to-end) abgedeckt sein. Aber vor allem bei schwammigen oder unklaren Business-Anforderungen neigen wir zu struktureller Kopplung zwischen Produktivcode und Testcode. Im schlimmsten Fall gibt es für eine Methode im Produktivcode eine entsprechende Testmethode. Auf den ersten Blick scheint dieses Problem harmlos zu sein, da man dadurch eine sehr hohe Testabdeckung erreicht. Doch strukturelle Kopplung erschwert späteres Refactoring enorm.
Eine Testing-API zwischen Produktivcode und Testcode löst diese Kopplung. Basierend auf dem Softwaredesign-Prinzip "don't depend on volatile things" ermöglicht diese API das Verifizieren von Business Rules und entkoppelt unserer Tests von der Applikation. Die Erweiterbarkeit ist weiterhin gewährleistet und sollte sich der Produktivcode hinter der API einmal ändern, laufen unsere Tests immer noch durch.
Die Implementation einer solchen Testing-API ist kein Selbstläufer. Deshalb gilt es folgende Fragen zu beantworten:
- Wie konzipieren wir solch eine API am besten?
- Können wir solch eine API überhaupt in unser bestehendes Software-Design implementieren?
- Wie lässt sich solch eine Testing-API mit .Net aufbauen?
Scrum mit Azure DevOps von 0 auf 100
Am Anfang eines Softwareprojektes gibt es viele Fragen zu klären: Welche Architektur nutzen wir? Wie sieht das Software-Design aus? Welchen Tech-Stack wollen nutzen wir? Wenn man diese Fragen geklärt hat, will das Team meistens direkt mit der Entwicklung beginnen. Doch dann stellen sich noch weitere, größere Fragen.
Mit welcher Methodik wollen wir arbeiten und mit welchen Tools wollen wir unsere Prozesse abbilden???
Diese zwei Fragen sind genauso wichtig wie die vorherigen, wenn nicht sogar noch wichtiger. Denn ohne klar definierte Prozesse und Tools, stehen sich,insbesondere bei größeren Teams, die Teammitglieder oft gegenseitig im Weg. Dennoch wird recht voreilig auf Scrum oder Kanban als agile Methodik zurückgegriffen. Aber hier fehlt leider immer wieder das effiziente Zusammenspiel von Tools und Prozessen.
Azure DevOps bietet viele Möglichkeiten, um Teams innerhalb des agilen Prozesses zu unterstützen. Egal, ob Item-Tracking oder Kapazitätsplanung. Es gibt viele Einstellungsmöglichkeiten, um agile Prozesse sauber abzubilden.
Anhand der Erfahrung aus verschiedene Projekten stelle ich praktische Best Practices zum optimalen Einsatz von Azure DevOps im Scrum Prozess vor. Auf was muss geachtet werden, um beide Welten zusammenzuführen? Und was sind Stolpersteine, auf die man gerade am Anfang der Projektphase achten sollte?
Adrin Amin Salehi
Software Developer and IT Consultant
Basel, Switzerland
Links
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top