Android Uygulamalarında Müziklerle Çalışmak

Online olarak gerçekleştirdiğimiz Android Uygulama Geliştirme Eğitimi ders notları
Android Uygulamalarında Müziklerle Çalışmak

İzlediğimiz adımlar;
Proje Oluştur
Müzik Dosyalarını Projeye Ekle: R.raw.allemande müzik dosyamız
Tasarımı Yap
Kodları Yaz
Test Et
Görselleri Projeye Ekle: R.drawable.baslat görsel dosyamız
Butonların Görsellerini Düzenle
Test Et

Mevcut Projeyi GitHub'a Yüklemek

Scrum'da "Bitti" (Done) Tanımı

Bir Ürün İş Listesi kalemi veya bir Ürün Parçası için “Bitti” deniyorsa, herkes “Bitti”nin ne olduğunu anlamalıdır. Scrum Takımlarının birbirinden farklı “Bitti” tanımları olabilir. Şeffaflığı sağlamak için, bir takım içerisindeki herkes işin hangi durumda bitmiş sayılacağına dair aynı bilgiye sahip olmalıdır. İşte bu Scrum Takımının “Bitti” tanımıdır ve Ürün Parçası üzerindeki çalışmanın değerlendirilmesi için referanstır.

Aynı tanım, Geliştirme Takımına Sprint Planlamada kaç Ürün İş Listesi kalemini seçeceğinde rehberlik eder. Her Sprintin amacı, Scrum Takımının “Bitti” tanımına uyacak şekilde potansiyel olarak yayınlanabilir işlevselliğe sahip Ürün Parçaları teslim etmektir.

Geliştirme Takımları her Sprintte işlevselliğe sahip bir Ürün Parçası teslim eder. Ürün Parçası, Ürün Sahibinin hızlı yayın kararı verebilmesi için kullanılabilir hâldedir. Eğer bir Ürün Parçasının “Bitti” tanımı, geliştirmeyi yapan organizasyonun kılavuzları, standartları ve genel iş yapış şeklinin bir parçasıysa, Scrum Takımları bunlara asgari standart olarak uymalıdır. Eğer “Bitti” tanımı organizasyonun iş yapışının bir parçası değilse, Geliştirme Takımı ürün için uygun olan bir “Bitti” tanımı yapmalıdır. Eğer sistem veya ürün yayını üzerinde çalışan birden fazla Scrum Takımı varsa, tüm Geliştirme Takımları ortak bir “Bitti” tanımı getirmelidir.

Her bir Ürün Parçası, tüm önceki ürün Parçalarının üzerine gelir ve bunların birlikte çalışmalarını temin edecek şekilde test edilir.

Scrum Takımları olgunlaştıkça, “Bitti” tanımlarının yüksek kalite için daha zorlu kriterler içerecek şekilde genişlemeleri beklenir. Bir ürünün veya sistemin üzerinde yapılacak herhangi bir işlemin standardını ifade eden bir “Bitti” tanımı olmalıdır.

Kaynak: Scrum Kılavuzu

Scrum ile ilgili geçmiş yazılara ulaşmak için tıklayınız.

Scrum Eserlerinin Şeffaflığı

Scrum şeffaflığa dayanır. Eserlerden ne anlaşılıyorsa ona göre değeri en üst seviyeye çıkarma ve riski kontrol etme kararları verilir. Şeffaflığın tam olması hâlinde, bu kararların sağlam bir temeli olur. Eserlerin tam olarak şeffaf olamaması hâlinde kararlar zayıftır, üretilecek değer azalabilir ve risk artabilir.

Scrum Master, eserlerin tam olarak şeffaf olup olmadığını anlamak için Ürün Sahibi, Geliştirme Takımı ve ilgili taraflarla birlikte çalışmalıdır. Eksik şeffaflıkla başa çıkmak için belli pratikler vardır; Scrum Master şeffaflığın eksik olması halinde en uygun yöntemi kullanması için herkese yardım etmelidir. Scrum Master, eserleri gözlemleyerek, davranış kalıplarını sezerek, ne söylendiğine iyi kulak vererek ve beklenenle gerçek sonuçlar arasındaki farkları inceleyerek eksik şeffaflığı tespit edebilir.

Scrum Masterın görevi eserlerin şeffaflığını artırmak için Scrum Takımı ve organizasyonla birlikte çalışmaktır. Bu görev genellikle öğrenme, ikna ve değişimi içerir. Şeffaflık bir gecede sağlanmaz; bir yolculuktur.

Kaynak: Scrum Kılavuzu

Scrum ile ilgili geçmiş yazılara ulaşmak için tıklayınız.

Scrum Ürün Parçası (Increment) Nedir?

Ürün Parçası, bir Sprint boyunca tamamlanan Ürün İş Listesi kalemlerinin ve tüm geçmiş Sprintlerin Ürün Parçalarının değerlerinin toplamıdır.

Sprintin sonunda, yeni Ürün Parçası “Bitti” olmalıdır yani kullanılabilir durumda olmalı ve Scrum Takımının “Bitti” tanımına uymalıdır.

Ürün Sahibi yayın kararı versin veya vermesin, kullanılabilir bir durumda olmalıdır.

Kaynak: Scrum Kılavuzu

Scrum ile ilgili geçmiş yazılara ulaşmak için tıklayınız.

Scrum: Sprintin İlerlemesini İzlemek

• Sprint İş Listesindeki toplam kalan iş, Sprintin herhangi bir anında hesaplanabilir.
• Geliştirme Takımı, Sprint Hedefini gerçekleştirmeye ne derece yakın olduğunu görebilmesi için en azından her Günlük Scrumda toplam kalan işi izler.
• Geliştirme Takımı, Sprint boyunca kalan işi izleyerek ilerlemesini yönetebilir.

Kaynak: Scrum Kılavuzu

Scrum ile ilgili geçmiş yazılara ulaşmak için tıklayınız.

Scrum Sprint İş Listesi (Sprint Backlog) Nedir?

Scrum Sprint İş Listesi, Sprint için seçilen Ürün İş Listesi kalemlerini ve Ürün Parçasını teslim etme ve Sprint Hedefine ulaşma planını içerir. Sprint İş Listesi, Ürün Parçasında hangi fonksiyonların olacağına ve bu fonksiyonları “Bitti” tanımına uygun bir Ürün Parçasına dönüştürmek için gerekli olan işe dair bir öngörüdür.

Sprint İş Listesi, Geliştirme Takımının Sprint Hedefine ulaşmak için gerekli gördüğü tüm işleri görünür kılar.

Sprint İş Listesi, Günlük Scrumda ilerlemenin anlaşılabilmesi için yeterli ayrıntıyı içeren bir plandır. Geliştirme Takımı, Sprint boyunca Sprint İş Listesini değiştirir; Geliştirme Takımı Sprint içerisinde plana uygun çalıştıkça ve Sprint Hedefine ulaşmak için gerekli olan işi daha fazla anladıkça Sprint İş Listesi belirginlik kazanır.

Yeni bir iş gerektikçe, Geliştirme takımı bunu Sprint İş Listesine ekler. İş yapıldıkça, kalan iş miktarı tahmini güncellenir. Gereksiz görülen her unsur plandan çıkarılır. Sadece Geliştirme Takımı, Sprint boyunca Sprint İş Listesini değiştirebilir. Sprint İş Listesi, Geliştirme Takımının Sprint boyunca başarmayı planladığı işin son derece görünür, gerçek-zamanlı bir resmidir ve sadece Geliştirme Takımına aittir.

Scrum: Proje Hedefine Doğru İlerlemeyi İzlemek / Öngörmek

Hedefe ulaşmak için geriye kalan iş her an hesaplanabilir. Ürün Sahibi en azından her Sprint Değerlendirme toplantısında geriye kalan toplam işi izler. Ürün Sahibi projelendirilen toplam işin istenen zamanda tamamlanıp tamamlanamayacağını anlamak için önceki Sprint Değerlendirme toplantısında kalan işle bu rakamı kıyaslar. Bu bilgi tüm paydaşlar nezdinde şeffaflaştırılır.

İlerlemeyi öngörmek için aşağı-tüketim (burn-down), yukarı-tüketim (burn-up) veya kümülatif akış (cumulative flow) gibi eğilim ölçen çeşitli planlama araçları kullanılmaktadır. Bu araçların faydası kanıtlanmıştır. Ancak bunlar deneyciliğin önemini gölgeleyemezler. Karmaşık ortamlarda, ne olacağı bilinemez. İleriye dönük kararlar almada sadece geçmişte ne olduğu bilgisinden faydalanabilirsiniz.

Kaynak: Scrum Kılavuzu

Scrum ile ilgili geçmiş yazılara ulaşmak için tıklayınız.

Sorularla Scrum Ürün İş Listesi

SORU: Ürün İş Listesinin içeriğinden, erişilebilirliğinden ve sıralamasından kim sorumludur?

a) Scrum Takımı
b) Ürün Sahibi
c) Scrum Master
d) Geliştirme Takımı


SORU: "Bir Ürün İş Listesi asla tam değildir, dinamiktir" ifadesi;

a) doğrudur
b) yanlıştır


SORU: Ürünün içinde kullanılacağı ortam değiştikçe;

a) Ürün İş Listesi de değişir.
b) Ürün İş Listesi oluşturulduktan sonra dokunulamaz.


SORU: Tek bir ürün üzerinde birden fazla Scrum Takımı çalışabilir mi?

a) Evet
b) Hayır


SORU: Tek bir ürün üzerinde birden fazla Scrum Takımı çalıştığında ürünle ilgili yapılacak işleri tarif etmek için tek bir Ürün İş Listesi mi kullanılır? Her takıın kendi Ürün İş Listesi mi olur?

a) Tek
b) Ayrı


SORU: Geliştirme sürecindeki tüm tahminlerden kim sorumludur?

a) Geliştirme Takımı
b) Scrum Takımı
c) Scrum Master
d) Her takım üyesi kendi tahminlerinden sorumludur
e) Tüm sorumluluk ürün sahibindedir


Scrum ile ilgili geçmiş yazılara ulaşmak için tıklayınız.

Scrum: Ürün İş Listesini İyileştirme (Refinement)

Ürün İş Listesini iyileştirme; Ürün İş Listesindeki kalemlere ayrıntı, tahmin ve sıra özellikleri ekleme eylemidir. Ürün Sahibi ve Geliştirme Takımının Ürün İş Listesi kalemlerinin ayrıntıları üzerinde çalıştığı devamlı bir süreçtir. Ürün İş Listesi iyileştirme çalışması esnasında kalemler gözden geçirilir ve güncellenir.

Scrum Takımı iyileştirmenin ne zaman ve nasıl yapılacağına karar verir. İyileştirme işlemi genellikle Geliştirme Takımının kapasitesinin %10’undan fazlasını almaz. Ancak Ürün İş Listesi kalemleri Ürün Sahibi tarafından veya onun takdiriyle her an güncellenebilir.

Üst sırada olan Ürün İş Listesi kalemleri genelde daha açıktır ve alt sıradakilerden daha ayrıntılıdır. Açıklık ve ayrıntı arttıkça daha isabetli tahminler yapılabilir. Sıranın altına doğru indikçe ayrıntı azalır. Ürün İş Listesi kalemlerinin Sprint süresi içerisinde “Bitti” olabilmesi için Geliştirme Takımının sıradaki Sprintte meşgul olacağı kalemler iyileştirilir. Geliştirme Takımının bir Sprintte “Bitti” durumuna getirebileceği Ürün İş Listesi kalemleri Sprint Planlamada seçim için “Hazır” kabul edilir. Ürün İş Listesi kalemleri genellikle yukarıda tarif edilen iyileştirme faaliyetleriyle böyle bir şeffaflık derecesine ulaşır.

Geliştirme Takımı tüm tahminlerden sorumludur. Ürün Sahibi, Geliştirme Takımını ilgili kalemleri anlaması ve uygun tercihler yapması için etkileyebilir. Ancak son söz, işi yapan Geliştirme Takımınındır.

Kaynak: Scrum Kılavuzu

Scrum ile ilgili geçmiş yazılara ulaşmak için tıklayınız.

Üniversite Sınavında İletişim Sorusu

Üniversite Sınavında İletişim Sorusu:
https://www.facebook.com/ogretmenlr/videos/1831201640476161/

İzlenmesi gereken bir video.

Yazılım eğitimlerine gelen öğrenciler de genel olarak konuyu kavramaktansa komut öğrenme peşinde oluyorlar. Bu video bakış açısını vermek için faydalı olacaktır diye düşünerek ekledim anlatılacaklar listeme.

Scrum Ürün İş Listesi (Product Backlog) Nedir?

Scrum Ürün İş Listesi (Product Backlog) Nedir?

Ürün İş Listesi, üründe ihtiyaç duyulan her şeyin sıralandığı bir listedir ve üründe yapılacak herhangi bir değişiklik için yegâne gereksinimler kaynağıdır. Ürün Sahibi, Ürün İş Listesinin içeriğinden, erişilebilirliğinden ve sıralamasından sorumludur.

Bir Ürün İş Listesi asla tam değildir. Başlarda ilk bilinen ve en iyi anlaşılan gereksinimleri gösterir. Ürün ve içinde kullanılacağı ortam değiştikçe Ürün İş Listesi de değişir. Ürün İş Listesi dinamiktir; ürünün kullanışlı, rekabetçi ve faydalı olabilmesi için neye ihtiyaç duyduğunu belirlemek amacıyla sürekli değişir. Bir ürün var oldukça, Ürün İş Listesi de var olur.

Ürün İş Listesi, üründe gelecek yayınlarda yapılacak değişikliklerin kaynağı olan tüm özellikleri, işlevleri, gereksinimleri, iyileştirmeleri ve düzeltmeleri sıralar. Ürün İş Listesi kalemlerinin tanımı, sırası, (büyüklük) tahmini ve değeri vardır.

Bir ürün kullanıldıkça, değer kazandıkça ve pazar geri bildirim verdikçe Ürün İş Listesi daha geniş ve ayrıntılı bir listeye dönüşür. Gereksinimler sürekli değiştiği için Ürün İş Listesi yaşayan bir listedir. İş gereksinimlerindeki, pazar koşullarındaki veya teknolojideki değişmeler Ürün İş Listesinde de değişikliklere neden olabilir.

Aynı ürün üzerinde çoğunlukla birden fazla Scrum Takımı çalışır. Ürünle ilgili yapılacak işleri tarif etmek için tek bir Ürün İş Listesi kullanılır. Böyle bir durumda Ürün İş Listesi kalemleri gruplandırılabilir.

Kaynak: Scrum Kılavuzu

Scrum ile ilgili geçmiş yazılara ulaşmak için tıklayınız.

JavaScript For/In İfadeleri ile Nesne Özellikleri Üzerinde Döngüye Girmek

JavaScript For/In Döngüleri

JavaScript for/in ifadeleri, diğer dillerde foreach olarak bilinen döngü çeşidine karşılık gelmektedir. Diziler üzerinde döngü kurmak için kullanılabileceği gibi, ayrıca; bir nesnenin özelliklerinde dönmek için de kullanılabilir.

Örnek kullanım aşağıda verilmiştir;

Scrum Eserleri (Scrum Artifacts)

Scrum Eserleri (Scrum Artifacts)

Scrumın eserleri, şeffaflığın yanı sıra gözlem ve adaptasyon fırsatları sunmak için yapılan işi veya üretilen değeri temsil eder. Bu eserler, herkes eserden aynı şeyi anlayabilsin diye kilit bilginin şeffaflığını en üst seviyeye yükseltecek şekilde tasarlanmıştır.

Scrum Eserleri aşağıda listelenmiştir;

• Ürün İş Listesi (Product Backlog)
• Sprint İş Listesi (Sprint Backlog)
• Ürün Parçası (Increment)

Kaynak: Scrum Kılavuzu

Scrum ile ilgili geçmiş yazılara ulaşmak için tıklayınız.

Scrum Sprint Retrospektifi (Sprint Retrospective)

Scrum Sprint Retrospektifi (Sprint Retrospective)

Sprint Retrospektifi, Scrum Takımının kendini gözlemlemesi ve sıradaki Sprintte yapacağı iyileştirmelere ilişkin bir plan oluşturması için bir fırsattır.

Sprint Retrospektifi, Sprint Değerlendirmeden sonra ve Sprint Planlamadan önce yapılır. Bir aylık Sprint için 3 saatle sınırlıdır. Daha kısa Sprintler için etkinlik süresi genellikle daha kısadır. Scrum Master, etkinliğin gerçekleşmesini ve katılımcıların etkinliğin amacını anlamasını temin eder. Scrum Master herkese toplantıyı zaman sınırı içerisinde tutmasını öğretir. Scrum Master, Scrum sürecini yönetme sorumluluğu sebebiyle herhangi bir takım üyesi gibi toplantıya katılır.

Sprint Retrospektifinin amaçları şunlardır:

• Son Sprintin insanlar, ilişkiler, süreç ve araçlar bakımından nasıl geçtiğini gözlemlemek
• İyi giden noktaları ve muhtemel iyileştirme alanlarını tespit edip sıralamak
• Scrum Takımının iş yapış tarzını iyileştirecek bir plan oluşturmak.

Scrum Master, sıradaki Sprinti daha etkili ve keyifli kılmak için geliştirme sürecini ve pratiklerini iyileştirme yönünde Scrum Takımını cesaretlendirir. Her Sprint Retrospektifi esnasında, Scrum Takımı “Bitti” tanımını uygun şekilde adapte ederek ürün kalitesini artıracak yolları planlar.

Sprint Retrospektifinin sonunda, Scrum Takımı sıradaki Sprintte uygulayacağı iyileştirme alanlarını tespit etmiş olur. Bu alanları iyileştirmek Scrum Takımının kendini gözlemleyerek adapte olmasıdır. İyileştirmeler herhangi bir anda yapılabilse de, Sprint Retrospektifi gözlem ve adaptasyona odaklanmak için resmî bir fırsattır.

Kaynak: Scrum Kılavuzu

Scrum ile ilgili geçmiş yazılara ulaşmak için tıklayınız.

Scrum Sprint Değerlendirme (Sprint Review)

Scrum Sprint Değerlendirme (Sprint Review)

Sprint Değerlendirme, her bir Sprintin sonunda Ürün Parçasını görüp kontrol etmek ve gerekiyorsa Ürün İş Listesini uyarlamak için düzenlenir. Scrum Takımı ve paydaşlar bu toplantıda Sprintte yapılan işi görüşürler. Bu görüşmeye ve Sprint boyunca Ürün İş Listesinde yapılan değişikliklere dayanarak, katılımcılar değeri en üst seviyeye çıkarmak adına yapılabilecekleri belirlemek için işbirliği yaparlar. Bu gayrı resmî bir toplantıdır, bir durum tespiti toplantısı değildir. Ürün Parçasını sunmanın amacı geribildirim almak ve işbirliğini artırmaktır.

Bir aylık Sprint için bu toplantının süresi 4 saatle sınırlıdır. Daha kısa Sprintler için, bu süre genellikle daha kısadır. Scrum Master, etkinliğin gerçekleşmesini ve katılımcıların bunun amacını anlamasını sağlar. Scrum Master herkese zaman sınırı içerisinde kalmasını öğretir.

Sprint Değerlendirme şu unsurları içerir:

• Katılımcılar Ürün Sahibi tarafından davet edilen kilit paydaşlar ve Scrum Takımıdır
• Ürün Sahibi, Ürün İş Listesi kalemlerinden hangilerinin “Bitti” olup olmadığını açıklar
• Geliştirme Takımı Sprint boyunca neyin iyi gittiğini, hangi sorunlarla karşılaştığını ve bu sorunları nasıl çözdüğünü tartışır
• Geliştirme Takımı “Bitti” dediği işi gösterir ve Ürün Parçasıyla ilgili soruları yanıtlar
• Ürün Sahibi, Ürün İş Listesini tartışır. O güne kadar olan ilerlemeye dayanarak yaklaşık tamamlama sürelerini öngörür (eğer gerekliyse)
• Gruptaki herkes bir sonraki yapılacak şey hakkında birlikte çalışarak takip eden Sprint Planlama toplantısı için değerli girdiler sağlar 
• Pazarın veya ürünün potansiyel kullanımının, sıradaki en değerli işin seçimini değiştirip değiştirmediğinin kararlaştırılması
• Ürünün sıradaki yayını için zaman planının, bütçenin, potansiyel yeteneklerin ve pazarın değerlendirilmesi

Sprint Değerlendirmenin çıktısı, sıradaki Sprint için seçilebilecek kalemleri içeren güncellenmiş bir Ürün İş Listesidir. Ürün İş Listesi, yeni fırsatları yakalayabilmek için baştan aşağı elden geçirilebilir.

Kaynak: Scrum Kılavuzu

Scrum ile ilgili geçmiş yazılara ulaşmak için tıklayınız.

Javascript Yerine TypeScript

.NET geliştiricilerle dolu bir odada Javascript lafı duyulduğu anda, bir anda herkesin tüyleri ürperir, hava buz keser, rahatsız edici bir ortam oluşur. Bu durumu rahatlıkla gözlemleyebilirsiniz. Bu baştan savma yarım yamalak dilde bir şeyler kodlama ihtiyacı herkese dehşet verici gelir. .NET dünyasında Javascript 'in pek de popüler olmamasının sebepleri var elbet. Zamanınızın çoğunu C#, VB.NET, ya da F# gibi dillerde kod yazarak geçirdiğinizde bazı beklentileriniz oluyor. Otomatik kod tamamlama kullanamayacağınız, tip güvenliği olmayan ve nesne yönelimli özelliklerin rahat kullanılamadığı bir dil kimseye sıcak gelmiyor. İşte bu noktada çare TypeScript. Artık; Javascript yazarken tip güvenliği, class, interface ne lazımsa bizlerle.

Transpiler Nedir? #TypeScript

Transpiler Nedir?

TypeScript ile çalışmaya başladığınızda daha önce benzer işler yapmadıysanız hayatınıza yeni bir kelime daha giriyor olacak. Transpiler.

Transpiler ifadesi TRANSlate ve comPILER kelimelerinden birleştirilerek oluşturulmuştur. Bu ifade, bir dildeki kaynak kodları başka bir dildeki kaynak kodlara çeviren yazılımlar için kullanılır. Bir nevi derleyici diyebiliriz. Fakat; derleme sonrasında elde ettiğimiz sonuç yine kaynak koddur. Örneğin; TypeScript, CoffeeScript, Caffeine, Kaffeine ve daha birçok farklı dil JavaScript diline transpile edilir.