Trabzon’da Karadeniz Teknik Üniversitesi Kariyer Gelişim Günleri’ni düzenliyor. Etkinlik kapsamında özgür yazılımlar üzerine bir seminer veriyoruz.

Konu: İş Hayatında Özgür Yazılımlar
Konuşmacı: Enver Altın
Tarih: 5 Mart 2012 Pazartesi
Saat: 13:00-14:30
Yer: Karadeniz Teknik Üniversitesi, Osman Turan Kültür Merkezi, Trabzon

Ping(packet internet groper) sistem kullanıcı ve yöneticilerinin belki de en sık ve kolay kullandığı test aracıdır diyebiliriz. Ping aslında sistemin bir noktaya ulaşıp ulaşamadığının en basit şekilde kontrol edilebildiği yöntemdir. Çalışma prensibi sisteminizin karşı tarafa gönderdiği paketler ve bunların geri dönüş zamanlarının hesaplanarak kullanıcıya veriler sunmasıdır. Ping aslında bir aktif sonar teknolojisi gibidir, ping ile...»

İşletim sistemini 32bit mi 64bit mi kurayım sorusu yakında tarih oluyor. Yaklaşık sekiz yıldır bir şekilde bu konu üzerinde çalışan/konuşan debian farklı mimarilerde kurulmuş işletim sistemlerine diğer mimarilerin paketlerinin kurulabilmesinde sona yaklaşıyor. dpkg'yi experimental deposundan kuran Debian kullanıcıları bu özelliği bir süredir test edebiliyorlar.


Çoklu-mimarili paketler sayesinde amd64 üzerine i386 paketleri (ve diğerleri) kurulabilir olacağı gibi çapraz derleme (cross-building) de çok kolaylaşacak. Elbette yapılacak çok iş, denenecek çok paket var (zlib'le bağlantılı 2000'den fazla paket var örneğin) ama Ubuntu Natty ve Debian Wheezy ile gelecek bu özellik kullanıcıları bir karmaşadan daha kurtaracak gibi duruyor.

Zaten bir Linux dağıtımının yeni sürümünden de inovatif birşeyler bekliyor insan.

Çalıştığım şirkette epey bir süredir Agile (Çevik) yazılım geliştirme metotlarından biri olan Scrum (Ragbi oyununda takımın bir mesafeyi almak için kafa kol girişmesini ifade eden bir terim :) uygulanıyor.

Agile yaklaşımın temelinde gereklerin geliştirme süreci boyunca değişeceği, dolayısıyla yazılımın artımsal olarak kısa adımlarla geliştirilmesi, müşterilerin ve geliştiricilerin süreç boyunca etkileşimi, yazılımın her anında çalışabilir olması gibi bazı genel fikirler var. Scrum ise bu fikirlerden yola çıkıp geliştirme ve planlama sürecinin nasıl yürütüleceğini ayrıntılı olarak (ve süslü deyimlerle) tanımlayan bir yöntem.

Bu yöntemler hakkında detaylı bilgi internette bulunabilir, ben yalnızca deneyimlerimden yola çıkarak öznel görüşlerimi aktaracağım.

İlk olarak, Scrum geliştirme işinin teknik yönüyle ilgili çok az şey içeriyor. Kodlama standartları, sürüm kontrol, inşa, test, vb pratikleriniz olduğunu varsayıp devam edelim.

Scrum takımı, geliştiriciler, ürünün önceliklerini belirleyen bir product owner (ürün sorumlusu) ve Scrum süreçlerinin yürütülmesi, geliştiricileri bloklayan engellerin kaldırılması, varsa diğer takımlarla iletişim gibi işleri yapan ve belli aralıklarla değişebilen bir Scrum Master'dan (Scrum yöneticisi) oluşuyor.

Scrum süreci sabit sürelerle yapılan geliştirme hamleleri (sprint) şeklinde. Bu süre genelde birkaç hafta. Her sprint başında yapılacak işler planlanıyor ve sprint süresince bu planlama değiştirilmiyor. Tabii bu süre bazı işler için küçük bazıları için büyük. Scrum'ın buna çözümü, işleri kendi başına çalışan ve sorunun çözümünde bir miktar ilerlemeye karşılık gelen küçük adımlara bölmek ve her Sprint sonunda bir miktar çalışmayı ürüne katıp o adımı geçmiş olmak. Kağıt üzerinde mantıklı da gelse, uygulamada işler bu kadar basitçe adımlara ayrılamıyor elbette. Bazı durumlarda işi artımsal adımlara bölmek toplamda daha uzun zamanda bitmesine yol açabiliyor. Ara adımlarda çıkan ürünlerin kullanıcılara ulaşması da, bakım zorluğu yaratacaksa istenmeyen bir şey olabilir. Kimi zaman da sprint bitmeden bir özelliği yada hata düzeltmeyi ürüne katıp müşteriye sunmak isteyebilirsiniz. Dogmatik yaklaşmayıp bu tür durumlarda esnek davranabilirseniz sprint yönteminin genel olarak zararlı olmadığını düşünüyorum.

Her gün belirli bir saatte, ekipteki herkesin geçen gün ne yaptığını, bugün ne üzerinde çalışacağını ve devam etmesine engel olabilecek her türlü engeli anlattığı günlük toplantı (standup) yapılıyor. Bu toplantının ayakta ve aynı odada yapılması vb gibi bir dizi kural var ama siz şekilselliğe değil amaca bakın. Önemli olan kısa sürmesi, herkesin birkaç cümle söyleyip birbirinin yaptığından haberdar olması. Amaç ekibi onbeş dakkada senkronize edip, o gün başka toplantıların yapılmasına engel olmak! Scrum'ın pratikte en faydalı uygulaması bence bu.

Akla gelen her özellik ve geliştirme önerisi, user story (kullanıcı hikayesi) adı verilen ve genellikle "bir Gazeteci olarak kelime işlem programında sözcükleri sayabileceğim bir özellik istiyorum, böylece istenen uzunluğu aşmadan yazabileceğim" gibi birinci ağızdan yazılmış fonksiyonel iş tanımları olarak, backlog (yığılmış iş) adı verilen bir listeye ekleniyor. Sprint başında takım bu listeden o sprint süresince yapılacak işleri seçiyor. İşlerin fonksiyonel ve açık biçimde belirtilmesi (user story'ler işin tamamlanma koşullarını ve çeşitli testleri de içerebilir) faydalı bir yaklaşım, ancak backlog fikrini doğru bulmuyorum. Bu konuda Rework çok daha akıllıca bir yöntem öneriyor: Uzun listeler moral bozmaktan başka bir işe yaramaz. Eğer bir işi bir kenara yazmadığınızda unutuluyorsa zaten sandığınız kadar önemli ve yapılması gereken bir şey değildir. Müşteriler ile sürekli bir iletişiminiz varsa zaten size en öncelikli ve gerekli işi sürekli hatırlatacaklardır.

Burada bir sorun da, ürün kalitesini arttıracak ama müşteriye direk yansımayan ufak işleri sıraya almanın çok zor olması. Bunları ya kendi başınıza yapacaksınız, değerlendirmelerde gözükmeyecek ve bunlara harcadığınız zamanın hesabını veremeyeceksiniz. Ya da bunlara birer user story oluşturmak yada eldekilerden birine eklemek için hem zaman hem de ekibi ikna edip sıraya aldırmak için enerji harcayacaksınız.

Backlog'a atılan user story'ler takım tarafından zorluk ve tamamlanma sürelerine göre puanlanıyor. Bu puanlar o sprint'te başlanacak işleri belirlerken ve süreç boyunca burndown chart, velocity gibi süslü isimleri olmasına karşın aslında oldukça basit istatistikleri oluştururken kullanılıyor. Amaç takımın verimini ve işlerin yürüme hızını gözlemlemek ama burada detaylarına girmeyeceğim bir dizi kurnazca yöntemle yapılmalarına rağmen neredeyse hiç bir işe yaramıyorlar. Puanlama, eğer kendinizi kandırmıyorsanız, işe başlamadan bilemeyiz demekten ibaret. Diğer istatistikler ise elma ile armutu karşılaştırıyor.

Bu ölçme girişimleri ar-ge'yi teneke kutu üretimi sanan yöneticileri tatmin etmek için icat edilmiş olsa gerek. Onlara kötü bir haberim var, eğer projeyi en ufak detayına kadar kavrayabilecek kadar bilginiz yoksa bir ar-ge projesini yönetemezsiniz. İyi niyetliler sizi terkeder, kötü niyetliler metriklerinizi kandırır. Bu noktada maalesef velocity yıllar öncesinin kod satırı sayısı kavramından bir adım öteye geçebilmiş değil. Benim önerim şu: projeyi takip mi etmek istiyorsunuz, gidip commit eposta listesini okuyacaksınız. Anlamıyorum olup biteni diyorsanız da proje yönetmeyin lütfen!

Scrum kabaca böyle. Doğru uygularsanız faydalı olabilecek bazı pratikleri var. Bir bütün olarak almayıp, her pratik için bu doğru mu? ve benim durumuma uygun mu? diye sorgulamanızda fayda var. Şekilselliklerinden ve seremonilerinden ise kaçının derim, gülünç duruma düşmeyin.

Agile felsefesine daha uygun başka uygulamalar da mevcut. Bu yazının kapsamı dışındalar, o yüzden netten kendiniz araştırabilirsiniz. Ayrıca herhangi bir çelişki halinde Rework kuralları daima geçiş üstünlüğüne sahiptir :)

28 Şubatta Balıkesir Üniversitesi Necatibey Eğitim Fakültesine Mesutcan Kurt, Engin Manap ve Serhat Rıfat Demircan ile birlikte Linux ve özgür yazılımlar hakkında konuşmak için gidiyoruz. Salı günü o saatte daha iyi bir işi olmayanları sohbet etmeye bekleriz.

Dilimizde atasözü: Ucuz etin yahnisi yavan olur. Bazı durumlar için bir gerçeği, bir derece belirtiyordur mutlaka; yine de, diğer tüm çözümlemelerin yerine geçecek mucizevi bir ölçüt bulduklarını sanırım atalar da iddia etmemiştir.

Apple şirketinin ürünlerinin pahasını o ürünlerin kalitesinin doğrudan kanıtı saymak ve Apple ürülerinin kalitesini de ürünlerin pahasıyla doğru orantılı görmek gibi yaygın bir yanılsama var.

Apple kazanıyor, onlar ise… başlıklı haberi okuduktan sonra konu üzerinde Web’de biraz gezindim. Önce şuraya uğradım. Ardından şuradan, aşağıda vereceğim grafikleri buldum. Görüleceği gibi, Apple pek alışılmadık denli yüksek kâr oranlarıyla çalışıyor. iPhone 2010′un satış fiyatının % 58,5′i Apple’ın kârı. iPad 2010′un satış fiyatınınsa % 30′u Apple kârı.

Yani, daha mütavazı kâr oranlarıyla çalışacak şirketler olabilse veya olduğu durumda, kasaba daha az para vererek aynı kalitede yahni yemek mümkün.

Grafikler üzerinde Türkçeleştirmiyorum: profit, kâr; labor, emek; material, malzeme anlamında.

iPhone 2010 değer dağılımı:

iPad 2010 değer dağılımı:

Epeyce zaman geçmiş olmasına rağmen ben de izlenimlerimi anlatayım. Bu seneki Akademik Bilişim Uşak Üniversitesi‘nde idi. Necdet Yücel‘in dürtmesi ile Kaan Özdinçer ile 4 günlük Temel Linux ve Sistem Yönetimi eğitimi vermek üzere Uşakta idik. Bu kurs için gelen 45 kadar kişi vardı. İki sınıf halinde bir kısmına ben ve Kaan konuştuk. Diğer sınıfta Emre Eryılmaz konuştu. İlk iki günkü eğitimlerde ben konuşmacı idim. Havanın karlı, yolların muhalefetli olmasına rağmen sınıf içerisinde memleketin uzak yerlerinden gelenler yanında Bilkent, Dokuz Eylül, Ege gibi üniversitelerden gelen ama öğrenci ama bilgi işlem çalışanları vardı. Dinleyici kitlesi pek homojen olmamakla beraber, ilk günün öğleden sonrasından sonra bir iletişim ortamı yakaladığımı düşünüyorum. Benim için Akademik Bilişim öncesi eğitimlerdeki ilk tecrübemdi bu seneki. 2 gün boyunca camianın hem eskilerini gördüm, hem de kendi adıma eğlendim. Seneye daha tecrübeli bir şekilde anlatırım diye düşünüyorum.

Linux Eğitimi yanında bu seneki AB’de farklı epey bir alanda eğitim vardı. Daha önceki AB eğitimlerini görenlere göre en fazla katılımın olduğu etkinlik olmuş. Gönüllü çalışmalarla devam eden bu konferansa ilgiyi ve katılımı yüksek tutmak gerek diye düşünüyorum. Sanıldığının aksine güzel işler de oluyor içerisinde.

Bir süredir yazamadığım konu da FOSDEM 2012 idi.
Continue reading "FOSDEM 2012'nin ardından (gecikmiş günlük yazıları - 2/n)"

5 haftadır koşturuyordum, sonunda birikmiş şeyleri yazacak vaktim var biraz.

Akademik Bilişim 2012 (AB 2012) bu sene Uşak Üniversitesi'nin evsahipliğinde yapıldı. Geçen 2 senede olduğu gibi, bu sene de konferans öncesinde 4 gün boyunca eğitim verme şansım oldu.
Continue reading "AB 2012'nin ardından (gecikmiş günlük yazıları - 1/n)"

Balıkesir Üniversitesi Bilgisayar ve İnternet Topluluğu tarafından 28 Şubat 2012 tarihinde Linux seminerleri düzenleniyor.

 

Konu: Linux ve Özgür Yazılım Nedir?
Özgür Yazılım Öğrencilere Ne Katar?
Konuşmacılar: Necdet Yüce, Engin Manap, Mesutcan Kurt
Yer: Balıkesir Üniversitesi Necatibey Kampüsü Eğitim Fakültesi Konferans Salonu
Tarih: 28 Şubat 2012
Saat: 15:00 – 17:30