Software Architecture: The Hard Parts

Software Architecture: The Hard Parts book is the follow-up book after the Fundamentals of Software Architecture book. This new book is all about software architecture trade-offs. These trade-offs are in many different aspects of the architecture; service identification, service communication, data ownership, data consistency, databases, distributed transactions, transactional sagas, service contracts. They spotlessly explain these trade-offs, and I like their clean approach. To select a solution after evaluating these trade-offs, we need a context.

The Accelerate Book

The Accelerate book has been on my reading list for a long time, and I bought the book last year. I checked it a few times, and I thought that I was already familiar with the book’s content, so I didn’t read it from the start. Last Tuesday, I visited Udemy’s new Ankara office; we talked about some software engineering practices to improve our software development and delivery performance with a few friends in the kitchen area.

Distributed Services with Go, Travis Jeffery

I’ve recently read Distributed Services with Go as part of my morning reading ritual. I’ve been working on a new service with Go for our experimentation platform at Udemy. This service will be a Kubernetes sidecar. Our default technologies for services are Kotlin and SpringBoot at Udemy. But, Kotlin and SpringBoot aren’t good enough technologies to implement a Kubernetes sidecar solution that should be efficient in resource usage, bootstrap time, docker image size, etc.

Release It!, Michael T. Nygard

I read the Release It! book recently. The center of the book is building production-ready software. Being on production might be very different from our local, test, staging, any other non-production environments, so we should be aware of potential problems that we might face on the production and we should be ready for them. Software design as taught today is terribly incomplete. It only talks about what systems should do. It doesn’t address the converse—what systems should not do.

Fundamentals of Software Architecture Book

I read the book Fundamentals of Software Architecture. The book deserves its name, it covers some basic concepts of software architecture and being an architect. There are many topics but they are not so much deep. I like the balance that they set up for the breadth and depth of these topics. Some topics are driven by the expectations of a software architect that they define; There are eight core expectations placed on a software architect, irrespective of any given role, title, or job description:

Unit Testing Best Practices

Unit tests are an important scaffold for large-scale software development; they enable us to design, write, and deploy production code with confidence by validating that software will behave as expected. Even though they may not execute in live systems, their development and maintenance requires the same care as general production code. Sometimes developers do not realize this which leads to testing code with more code smells than production code. Engineers may not give enough attention to test code changes in the code review process.

Software Engineering at Google Book

I read the Softare Engineering at Google book recently. It seems to me the book has a similar approach with The Pragmatic Programmer book. The book has a wide range of topics, from cultural ones to technical ones. There are three main parts; culture, processes, and tools. With the help of these topics, you can imagine how a giant software engineering company like Google works, at least at a high level.

Domain-Driven Design Concepts

In this post, I’ll try to explain some high-level concepts of Domain-Driven Design and then I’ll mention my experience with the application of these concepts. What, Why, When? Domain-Driven Design is a set of practices to model complex business domain into software better. These practices try to tackle different aspects of complex business domains, like communication, high-level design, team relationships/communications, low-level class designs, etc. Domain-Driven Design is not bound to Object-Oriented Design.

QCon London 2020 Notes

Last week I attended the QCon London 2020 Conference first time. I think it’s one of the best-rated software engineering conferences in Europe. I had two main expectations from the conference; the first one is inspiring ideas, the other one is experience sharings about some architectural design. A view scene from the Queen Elizabeth II Centre The conference was organized very well, it reflected the experience of the team behind it.

Finding Ideal JVM Thread Pool Size With Kubernetes and Docker

In this post, I explain why we use JVM thread pools, what are the parameters that we should take into account when we decide a thread pool and it’s size. And how these parameters are affected when we run our application with Docker and Kubernetes. Why do we use thread pools? We use thread pools to align our system workload with system resources efficiently. This system workload should be tasks that can run independently, for example, every Http request to a web application can be in this category, we can process every request without thinking another Http request.

Contributing to Open Source Projects

Contributing to open source projects can have many different benefits and motivations for different individuals or companies. In this blog post, I’m going to write about my motivation and process for contributing to open source projects. My Journey I have been aware of that contributing to open source projects is one of the best alternatives to improve professional skills for a long time. But I had also postponed it for a long time, even for the times that I couldn’t find enough opportunities to learn and grow at my employer.

Instrumenting And Monitoring Spring Boot 2 Applications

In this post, I try to introduce you some basic concepts of an instrumentation of a Spring Boot 2 application with tools such as Micrometer, Prometheus, Grafana. There are 3 main phases while you’re instrumenting an application, first, one is producing metrics in the application(Micrometer), the second one is gathering these metrics to persist(Prometheus) and the third one is monitor these metrics(Grafana). What’s Software Instrumentation? According to Wikipedia, instrumentation, in terms of computer programming, is;

Innova Internal Coderetreat

Kasım 2017’den beri çalıstığım bölümdeki junior developer’lar için bilgi/deneyim paylaşım aktiviteleri düzenliyorum. Bu paylaşım aktivitelerinde bazı şeyler çok teorik seviyede kalabiliyor, bunu hem ben hissediyorum hem de bazen katılımcılardan geri bildirim olarak geliyor, özellikle projelerinde çok fazla bir şeyler deneyimleme imkanı olmayan arkadaşlarda problem biraz daha büyüyor. Bunu aşabilmek için bazı session’ları tamamen pratiğe yönelik yaptım, bazı sessionlarda da anlattığım çoğu şeyi pratik olarak temel seviyede göstermeye çalıştım ancak bu yetmedi.

One Year as a Technical Leader

After 2011 in my career, I decided to become a good technical manager and I had been reading lots of things about agile software development, scrum, people-oriented processes, organizations, etc. I started to share my knowledge in-house. This has lasted for about 5 years. I did lots of thing in terms of software development management with my teams and the other teams. I sold agile software development at some level in my department.

Udemy'de Yayınladığım Java ile Unit Test Eğitiminin Hazırlanış Süreci

Bu yazımda Udemy’de yayınlanan “Java, JUnit ve Mockito ile Unit Test Yazma Eğitimi” ni hazırlayış sürecimden bahsedeceğim. Yapabilir miyim? İnsanların öğrenmek için okumak ve dinlemek yerine izlemeyi daha çok tercih etmeye başlaması ile birlikte online eğitimler de, özellikle yazılım geliştirme sektöründe, çoğumuzun hayatına girdi. Eğitim deyince benim aklıma hep bu işi profesyonel olarak yapan insanların verdikleri eğitimler geliyordu, belki sınıf içi eğitim veren insanlardan kaynaklı oluşan bir algı. Youtube vb. ortamlarda eğitim tarzında içerik hazırlayan ve bu işi profesyonel olarak değil daha çok bir konferans’da veya meetup’da bir şeyler anlatıyormuş gibi yapan insanlar vardı ama onlarınki eğitimden ziyade bir paylaşım gibi geliyordu bana.

Udemy'de Java, Junit5 ve Mockito ile Unit Test Yazma Egitimi Yayınladım

Udemy’de Java’da JUnit5, AssertJ ve Mockito gibi araclar ile nasıl unit test yazılacağını anlatan bir eğitim yayınladım. Bu eğitimi bir programlama dilini bilen birisinin, buna paralel olarak o programlama dilinde yazdığı kodları otomatik olarak nasıl test edebileceğini yani nasıl unit test yazabileceğini de öğrenmesi gerektiğine inandığım için hazırlamak istedim. Eğitimi hazırlarken en temel motivasyonlarından birisi de yıllardır bir çok projede unit testler olmadığı için hep benzer sorunlar ile yüzleşmem. Unit testlerin olmaması ve bunun sonucunda çıkan bir çok hata, çok fazla maliyeti olan ve çok uzun süren manuel testler, fazla mesai’ler, 1 saat’de yazılan kodun sisteme olan genel etkisi için 3 gün test yapılması gerekmesi vs.

Process and Challenges of Growing a Team - II

In the first part of this blog post I wrote our problem about the mentoring to junior developers, results of this problem and a solution we wanted to apply. In this part, I write about the details of our solution, some practices and challenges of the process. Project Management Methodology One of the advantages of the project is that this project is a replacement project for an already existing system, and I know the business domain well for this legacy system because a few years ago I had worked in a project that’s one of the clients of this legacy system.

Process and Challenges of Growing a Team - I

In this 2-post series, I would like to write about our 5-month-old project team’s growth process or journey. When we talk about people related problems it’s very hard to propose standard solutions. Solutions can change for different countries, cultures, people, organizations, projects etc. So I can just talk only my own experiences about my team. And these are just my own ideas and observations, not the company I worked with.

How I Build My Blog with Hugo?

Previously I’ve used Blogspot for my blogs. I’m not a very active blogger, I have just a few entry in Turkish at Blogspot. Recently I decided to share more things regularly with my blog posts both in Turkish and English and also improve my sharing environment. I’ve wanted to keep my entries with my full control, not in an external environment such as Blogspot, Wordpress, Medium etc. Also, I’ve wanted to use my own domain name and I thought mucahit.

The Mythical Man-Month

Frederic Brooks’un The Mythical Man-Month kitabı yazılım geliştirme literatüründe klasik kitaplardan birisidir. Yazılım geliştirmede insan faktörü, kültür, sorunlar, kariyer, organizasyon vs. bir çok konuda bu kitaba referans verildiğini, bir çok kişi tarafından “must read” olarak belirtildiğini görebilirsiniz. Ben bir kaç defa kitabı okumaya yeltendim ancak yarıda bıraktım, dili yabancı geldi anlamakta zorlandım, bahsedilen konuların günümüze yansımalarını bulmakta zorlandım. Sonunda kitabı bitirmeye karar verdim, bunu yaparken de benimle aynı durumda olan insanlara kitap hakkında genel bir intiba vermek adına özet bazı notlar almaya çalıştım.

Teknik Liderlik

Nedir teknik liderlik, neler yapar, nelerden sorumludur, nelere dikkat etmesi gerekir, zorlukları nelerdir, kişiye ve takıma avantajları dezavantajları nelerdir gibi konulardan bahsetmek istiyorum. Öncelikle kabaca nasıl bir teknik liderden bahsedeceğimizi tanımlamak faydalı olacaktır çünkü benzer rolde ancak çok farklı pratiklerle/sorumluluklarla çalışanlar mevcut. Benim bahsedeceğim daha doğrusu olmasını istediğim teknik lider: Bir geliştirme takımından sorumlu lider ve zamanının en az üçte birini takım ile beraber kod yazarak geçiren kişidir. Teknik liderliğe geçiş geliştirme takımının içindeki birisinin bu pozisyona geçmesine duyulan ihtiyaç ile olur.

Bakarsan Bağ Bakmazsan Dağ Olur

Kendi halinde, daha çok bilgisayar ile konuşan ve genellikle bilgisayar üzerinden çözülebilecek sorunları olan bir developer iken bir gün gelir şirket büyür, ekip büyür ve sana sen artık bu ekibin takım liderisin veya teknik liderisin derler. Geçiş genelde hızlı olur, ne bir eğitim ne bir hazırlık, kendi yolunu kendin bulacaksındır. Yöneticinin, ekip arkadaşlarının ve zamanla muhattap olmaya başladığın müşteri, iş birimi gibi diğer paydaşların senden beklentileri hakkında da kafanda bir şeyler yok ise işin daha da zordur.

Bir Yazilimcinin Kariyerinden Kim Sorumlu

Yazılım geliştiren insanlar özelinde sektörde geleceğe yönelik net bir planı olmayan çok fazla insan var, bu kategoriden kendimi de çok dışlamıyorum. İşi sadece yaşamını belirli seviyede devam ettirebilmek için belirli seviyede yapan insanlar, sadece iş. Her gün ayağını sürüye sürüye işe gitmek. Her sabah ofise girdiğinde biran önce akşam olsada eve gitsem düşüncesi. Her gün niye bu saçmalıklarla uğraşıyorum düşüncesi. Normal mi, değil, özellikle doğrudan insana, insanın psikolojisine, yeteneklerine, işini sevmesine bağımlı olan yazılım geliştirme gibi bir sektörde.

Yazilim Gelistirme Ekibinin Butunselligi

Bir yazılım geliştirme ekibi nasıl olmalıdır sorusuna yazılım projesinin bağlamına, müşterisine, karakterine vs. göre farklı farklı cevaplar verilebilir ancak çoğu zaman gözlemlediğim ve beni rahatsız eden bir yapılanma şekli çok yaygın; rollere göre kurulan ayrı ayrı ekipler. Mimari ekip, altyapı ekibi, tasarım ekibi, geliştirme ekibi, test ekibi, analiz ekibi, kalite ekibi vs. Bu ekiplerin hepsinin başında bir lider ve bu liderler de hiyerarşide bir üstte birine(proje yöneticisi, proğram yöneticisi, çözüm yöneticisi, direktör vs.

Yazılım Üreten Organizasyonlarda Merkezileşme

Organizasyonel anlamda merkezileşme’den kastım daha çok karar mekanizmaları bağlamında; onlarca, yüzlerce insanın her gün yaptığı işi etkileyen kararların 2-3 kişi tarafından alınması. Konu(Organizasyon, yönetim vs.) hakkında derinlemesine bilgi sahibi birisi değilim, bahsedeceğim bazı yönetimsel kavramları tam anlamıyla açıklayamayabilirim, ancak yazılım üreten şirketlerdeki bu çeşit politikalar, yazılım üreten insanlara ve yazılım projelerine bakış açıma çok uymuyor, dolayısı ile ben konuya merkeze insanı koyarak neden merkezileşmemeliyiz bakış açısıyla bakmaya çalışacağım, biraz beyin fırtınası tarzında olacak.

Sprint Retrospective Nasıl Yapılabilir?

Agile yazılım geliştirme yaklaşımının öne çıkan özelliklerinden ikisi, değişime cevap verebilme ve değişen şartlara adaptasyondur. Bunu sağlayabilmek için yapılması gerekenlerden birisi de sürekli olarak nerede olunduğunun, nereye gidilmeye çalışıldığının değerlendirilmesi ve alınması gereken aksiyonların alınmasıdır. Agile manifesto’da bununla ilgili olan prensip; “Takım, düzenli aralıklarla nasıl daha etkili ve verimli olabileceğinin üzerinde düşünür ve davranışlarını buna göre ayarlar ve düzenler.” “Her zaman iyileştirilebilecek bir şeyler vardır.”, “Hiç bir şey mükemmel değildir ama her şey mükemmelleştirilebilir.

Cucumber Ile Bdd

Behaviour Driven Development kavramı son zamanlarda dikkatimi çeken bir konu. İlk önce Dan North tarafından ortaya atılmış. Dan North, TDD(Test Driven Development) ile ilgili bazı tecrübelerinden yola çıkarak gördüğü aşağıdaki gibi bazı eksikliklerden dolayı bu kavramı ortaya atmış; Testler nerede başlar nerede biter belli olmuyor, Testlere verilen isimleri sadece developer’lar anlıyor, Ortak bir dil(ubiquitous language) kullanılamıyor, Test, Analist, Development arasında ortak bir anlayış sürece dahil edilemiyor. BDD ile aynı amacı güden pratikler farklı isimlerle anılabiliyor, bunlardan bazıları; Specification by Example, Acceptance Test Driven Development, Extenden Test Driven Development.

Agile Maliyetlendirme

Yapılacak olan işlerin önceden maliyetlendirilmesi yazılım geliştirme sektöründeki kritik işlerden birisidir ve bu konuda function point, uzman görüşü(expert judgement), story point kullanımı vb. çeşitli yöntemler günümüzde kullanılmaktadır. Her yöntemin olumlu olumsuz yönleri olduğu için tek bir standart model yok(yazılım dünyasının en büyük derdi standartlar yoktur çok fazla). Agile dünyada maliyet hesabı için kullanılan yöntemlerden birisi de story point kavramı ile maliyetlendirmedir. Burada kritik kavramlar ekip, büyüklük, hız, süre ve takvimdir. Kısaca story pointler kullanılarak maliyetlendirmenin nasıl yapılacağından bahsetmeye çalışacağım.

Holding Space

Türkçe karşılığını bulamadığım holding space kavramı basitce insanın kendisi veya bir başkasının bir şeyleri yapması için ona müdahalelerden, ön yargılardan uzak bir ortamı sağlaması, onun ilerlemesi bir şeyler ortaya çıkarabilmesi için desteklenmesi yani ona kendini bir şekilde ifade edebilmesi için alan açılması anlamına geliyor. Bu kavram farklı alanlarda uygulanmakla birlikte daha çok yoga vs. gibi meditasyon teknikleri alanında karşınıza çıkıyor. Ben bu kavram ile ilk defa Lyssa Adkins’in Coaching Agile Teams kitabında karşılaştım.