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.

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.