Kategori: Yazılım

Layer Supertype Pattern

Süperli müperli şeyler görünce heyecanlanmıyor değilim.

Nedir?

Martin Fowler’ın1 kim olduğunu bilmiyor olabilirsiniz, fakat ismini kesin bir yerlerde duymuşsunuzdur. Kendisi, şu an için pek hakim olamadığımız “Patterns of Enterprise Application Architecture”(İleri Seviye Yazılım Mimarisi Kalıpları) kitabının yazarı, bir nevi ortamların ağalarından bir tanesidir. Kendisini araştırın derim.

Martin Fowler’ın PoEAA2 kitabında bahsettiği kalıplardan bir tanesi olan Layer Supertype’a bakalım istedim bugün. Güzel bir kalıp ve çok da işe yarıyor, şahsen büyük bir programda kullanma fırsatım olmadı ama sizin imkanınız olabilir, ben de ekleyeceğim ilk fırsatta kendi programlarıma.

Fowler der ki; Kendi katmanında bulunan tüm tipler için bir süpertip oluşturan tip.

Kısaca açıklama çalışırsam; Bir katmanda birden fazla tip – diğer adıyla Entity – kullanıyorsanız ve bu entitylerde ortak olan noktalar var ise, tüm bu entitylerin türeyeceği bir tip yaratın ve bu ortak noktaları oraya yerleştirin.

Bir daha yazayım; Kendi katmanında! Ayrıca bir katmanda birden fazla Supertype olması gayet doğal, rahat olun agalar.

Hangi Durumlarda Kullanılır?

Yukarıda açıklamaya çalıştığım gibi birden çok Entity içerisinde kontrol etmeniz gereken bir durum var ise bunun için bir BaseEntity oluşturup, tüm Enity’leri buradan oluşturursanız, kontrol fonksiyonlarını tek bir süpertip’e vermiş olursunuz.

Örnek verecek olursa; ID alanının boş geçilmemesi her Entity için olabilecek bir şeydir. Genelde de zaten bu örneği verirler ya kıl olurum. Neyse, ID’nin boş geçmemesi için bir ID kontrol’ü yapan Supertype oluşturabilirsiniz.

Aslında anlatılmak istenen durum, bu ID alanının boş olmaması için gerekli küçük Framework’ün yaratılması için gerekli altyapının hazırlanmasıdır. Filozof gibi adam bu Fowler, zira PoEAA’da bu konuda pek bir şey de yazmamış, “kolay ya, ben hep yabıyom” demiş.

Uygulama

Hiç bir zaman şu kod örneklerini, diğer insanlar gibi vermemek gibi bir huyum olduğu için ben ID değil de, kendi kullandığım, Datanın Silinmemesi3 ilkesine göre bir örnek kod oluşturacağım. Bu arada bu kod kopyala yapıştır ile çalışmayabilir, zira direk düz metin olarak yazıyorum pseudo gibi algılayabilirsiniz.

Diyelim ki bir proje geliştiriyoruz, bu proje ne olursa olsun ben her Entity objem için DB’de IsActive, CreatedBy, CreationDate alanlarını tutarım. Bu alanlarım her Entity için var ise, neden bir Supertype yapmayayım ki?

[code lang=text]
namespace MyProject.Model
{
public abstract class SuperEntity
{
private DateTime _createdDate; // Kontrol edilecek alan
private IList<string> _errors = new List<string>(); // Hata içerikleri
private bool _dateEntered = false; // Data girildi mi ki?

public SuperEntity()
{ }

public DateTime CreatedDate
{
get { return _createdDate; }
set {
if (_dateEntered)
BanaTarihHatasiVer();

_createdDate = value;
_dateEntered = true;
}

private void BanaTarihHatasiVer()
{
throw new ApplicationException("Yaratılma tarihi bir kere atandıktan sonra değiştirilemez!");
}

public bool IsValid()
{
ClearBusinessErrors();
CheckErrors();
return _errors.Count() == 0;
}

private void ClearBusinessErrors()
{
_errors.Clear();
}

protected abstract void CheckErrors();

public IEnumerable<string> GetBusinessErrors()
{
return _errors;
}

protected void AddError(string error)
{
_errors.Add(error);
}
}
}
[/code]

Buradan bir SuperEntity oluşturduk, şidmi diğer Entitylerde uygulamasına bakalım bunun;

[code lang=text]
namespace MyProject.Model
{
public class News : SuperEntity
{
public News() { }

public string Yazar { get; set; }

protected override void CheckErrors()
{
if(String.IsNullOrEmpty(Yazar))
base.AddError("Yazar olmadan haber mi olur?");
}
}
}
[/code]

Kullanımını yapabilirsiniz.

Şimdi biz ne yaptık?

1- news.CreatedDate alanı için bir kere değer girildi mi, bir defa daha girilmesini elgelledik.
2- Hata kontrol sistemi entegre ettik. Yani news.Yazar alanı eğer boş geçilmişse, news.IsValid()bize o entity için boş geçilmiş, doldurulması zorunlu alanları verdi.
3- Ayrıca ortak olan fieldleri de bir supertype içine koyarak, mapping işlemleri için kolaylık sağladık.
4- Entity objemiz böyle sade bir entity oldu, içinde tekrar eden fieldler ve bunlar için kod olmadı, okunabilir oldu.

Aynı işlemi daha da genişletebiliriz, IsActive ve CretedBy alanlarını ekleyebilir. Tüm üç alanı, Error kontrolüne sokabilirdik.

İşte bu da bir yazılım kalıbı arkadaşlar, kullanıp kullanmamak tabii ki elinizde, fakat ben ilk gördüğümde gözlerim fal taşı gibi açılmadı diyemem. Darısı sizin başınıza.

  1. Martin Fowler Wikipedia ↩
  2. Patterns of Enterprise Application Architecture ↩
  3. Daha sonra detaylıca anlatacağım! ↩

Anti-Pattern: Smart UI

“Anti-pattern” kavramı hakkında pek fazla bilgiye sahip olmayabilirsiniz. Açıkcası benim için de çok yeni bir kavramdı, sağolsun Nedir TV’nin bir etkinliğinde Burak Selim Şenyurt‘un verdiği bir eğitimde varlığından haberdar olmuştum. Hatta dediğine göre, ülkemizde bazı üniversitelerde ders olarak bile gösteriliyormuş. Bu konu üzerine daha çok araştırma yapınca ben de paylaşım yapmaya özen göstereceğim.

Şimdilik bu konulardan sadece bir tanesi olan Smart UI adındaki anti-pattern’i size anlatmak istiyorum, hem basit bir anti-pattern hem de sık sık yaptığımız bir şey.

Anti-Pattern Nedir?

Çoğumuzun bildiği – ya da bildiğini sandığı – Design Pattern konusu vardır ya hani, yazılım yazmayı kolay hale getiren bazı kalıpları kullanarak hem kolay hem de stabil yazılımlar yazmamız amaçlanır – genelde elimize yüzümüze bulaştırırız. İşte DP1 gibi anti-pattern dediğimiz kavramlar da bize kalıplar sunar, fakat bu kalıplar kod yazarken yaptığımız hataları kapsamaktadır. DP’nin aksine AP2 direk kod içerisinde yapılan saçma hataları ele almaktadır ve tüm yazılımı hedef almaktadır. Öyle ki AP içerisinde proje yönetiminden, user interface’e kadar geniş bir aktegori yelpazesi bulunmaktadır.

O yüzden bir anti-pattern gördüğünüzde, bu direk yapmamanız gereken bir şeyi betimlemektedir! Bu tanım sanırım olabilecek en güzel tanım.

Smart UI

Bir anti-pattern olarak Smart UI, “User Interface”(kullanıcı arabirimi) kategorisine girmektedir. Esasında daha önce bir kaç yerde araştırmama rağmen, resmi AP listelemelerinde karşılaşamadım kendisi ile. Daha çok okuduğum kitaplarda geçen bir AP. Benim gibi Asp.Net üzerine uzmanlaşmış ya da uzmanlaşan birisi iseniz bu Smart UI kesinlikle yazılım hayatınızın bir parçası oluyor, bu yüzden de buna özellikle dikkat etmemiz gerekmekte.

Tanımı

Bir asp.net projesi açtığımızda – hangi tipte olursa olsun – yaptığımız ilk şey genelde UI’ı tasarlamak oluyor. Genelde UI tarafına girmeseniz de fark etmez, sonuçta UI tarafına illa giriyorsunuz ve bu kısımı hemen bitirip diğer işlerinize geçmek istiyorsunuz. Benim gibi işviçre çakısı gibi bir yazılımcı iseniz, sınırlı vakitte maksimum kazanç sağlamak için şirket zaten size dağ kadar iş vermiş ve hemen projenin bitmesini beklemekte sizden. Siz de vakit kaybetmemek için hemen projenin içine sayfayı açıp, gerek sürükle bırak yöntemi, gerek hemen buton altına kod yazma ile fonksiyonları tek sayfanın altında yaratıyorsunuz. Sonuçta proje çalışıyor mu? – Evet çalışıyor. O zaman sorun olmaması gerek. İşte bu Smart UI anti-pattern’i.

  • Proje hızlıca bitsin site tüm fonksiyonların ilgili sayfada toplanması,
  • Fonksiyonları katmanlamak yerine tek bir yerde toplayarak başka yerlerde kullanımlarda aynı fonksiyonların yazılması ya da static değişkeni tanımlayarak projenin bütünlüğünü bozmak

Etkileri

Yukarıdaki işlem bir anti-pattern’i tanımlar. Yani projeniz çalışsa da bir hata yaptığınızı tanımlar. Bu hatanın sonucunda;

  • Kodun bakımı, sistem karmaşıklaştıkça zorlaşır,
  • Geliştirme yapacağınız zaman, unutulan sayfalarda, işe yarar kodlar kalır,
  • Katmanlı mimariye geçilme aşamasınsa vakit kaybı yaratır,

Sonuçta hızla halledeyim dediğinizde, aslında geleceğe yönelik büyük bir hata yaptığınızın farkına varırsınız. Zaten anti-patternler de bu sorunu ortadan kaldırmak için vardır.

Çözüm

Çözüm için belirli bir yol yok. Aslında çözüme geçmeden önce cevap vermeniz gereken bir tane soru bulunmakta. Bu soru;

Bu ekran ya da projenin, ilerleyen zamanlarda geliştirmesi devam edecek mi?

Eğer cevabınız “Evet” ise, çözüm bulmanız gerekmekte. Fakat cevabınız “Hayır” ise, bir çözüm uygulamanıza pek de bir gerek yok. Zira zaten gelişimi devam etmeyecek bir proje ve başka yere de bağlanmayacak, o zaman neden çözesiniz ki, sonuçta amacınız projenin çalışması. Fakat daha sonradan pişman olup da tekrar sayfayı tasarlarken bulursanız kendinizi şaşırmayın.

“Evet” diyenler için çözüm belli, “Separation of concerns3“ uygulamasınız, yani “Endişelerin dağıtılması”. Bunun manası da bir design pattern ya da dizayn mimarisi kullanmanızdan geçer. Dizayn mimarileri ile ilgili daha detaylı bir makale anlatacağım, fakat örnek vermek gerekirse MVC ve MVVC birer dizayn patterndir.

İlla ki direk MVC uygulamanıza gerek yok, sonuçta kodunuzun ne kadar gelişeceği burada merak unsuru. Sonuçta sizin projeniz ve istediğiniz şekilde çözümleyebilirsiniz. Bu durumda size tavsiyem, UI katmanı içerisinde fazla fonksiyonlara yer vermemeniz ve Business ile ilgili kodları ayrı sınıflara toplamanızdır. En azından genel bir mantık kurana kadar sizi idare edecektir.

Anti-Pattern konusunda devam yazılarım olacak, şimdiden iyi boş zaman geçirmeler…

  1. Design Patterns’in tarafımdan verilen kısaltması. ↩
  2. Anti-Pattern’in tarafımdan verilen kısaltması. ↩
  3. Separation of concerns ↩

Proje Yönetiminde Ego Faktörü

Bugün ilginç bir konu ile karşınızdayım, “Proje yönetiminde ego faktörü”. Bu kısa makale aslında sadece yazılımcı olanlar için değil, analist olmak isteyenler için de açıklayıcı olacaktır. Zira boş işler konusunda kafa yormakta üstüme olmayan şahsımın, bu konuda bir çok fikri bulunmakta.

Proje Yönetimi

Bu konuda detaylı bir makale yazacağım. Özellikle o makalede ele alacağım konuları aşağıda özetleyebilirim.

  • Proje Yönetimi nasıl olmalıdır?
  • Proje Yönetimi esasen hangi faktörlere dayanır?
  • Proje Yönetimi adı altında yerel yazılım sektöründe ne gibi sorunlar var.
  • ve daha nicesi…

Şimdilik bu konulara fazla dalmayalım, vakti geldiğinde bu yazı da zaten o yazı dizisinin bir parçası olacak ve detaylıca bir sonuç ortaya çıkartacağız. Şimdilik konuya hakim olduğunuzu ve şirketinizde bir Proje Yönetimi olduğunu varsayalım. Muhtemelen yok ama yine de olduğunu düşünelim. Haliyle yazılımcı da olsanız, analist de olsanız verilen görev neticesinde sizden bir Analiz Dokümanı çıkarmanız istenmekte, buna müteakip projeyi yapacağınız birim ile bir toplantı ayarlamanız lazım. Siz de tabii tüm saflığınız ve isteğinizle gidip, paşa paşa toplantı yapacağınızı düşünerek karşınızdaki kişi ile masaya oturdunuz. İşte tüm hayalleriniz birazdan o masada yıkılacak, daha önce yıkılmadıysa bir sonraki masada yıkılacak. Korkmayın hemen bu aslında çok güzel bir şey, çünkü gerçek hayatı deneyimliyorsunuz.

Toplantı Masası

Masaya oturdunuz, özenle aldığınız defterinizi ve şirketin size aslında dokuz liralık gösterdiği iki liralık kalemi elinize alarak karşınızdaki kişiden bir PROJE çıkartacağınızı düşünüyorsunuz. O kadar iyimsersiniz ki, poliyanna yanınızda otursa size bakıp ağlardı. O masanın karşısında oturan şahıs ya da şahıslar, sizin gibi kaç tane kişinin leşini bıraktı o masada farkında mısınız? Hayalleriniz, planlarınız toz bulutu olup kaybolmadan önce karşınızdakine bakın. Telefonunu nereye koyuyor? Gözünüzün içine bakıyor mu? Soru sormanıza izin veriyor mu?

Size hiç hayatın sırrını ya da toplantıda x hareketini yaparsanız karşınızdaki daha rahat hissedecek falan demeyeceğim, zira böyle şeylere inanan birisi de değilim. Fakat her toplantım sonrasında elimdeki notları dolduran birisiyim. Zira önemli olan da odur. Toplantı masası savaş meydanıdır, orada yapacağınız en ufak hata sizin savaşı kaybetmenize sebep verebilir.

Projenin hayat döngüsünü özetlersek;
– Proje Talebi: “Kaşık istiyorum, çorba içeceğim”
– Analiz Toplantısı: “Çatal lazım, batırıp yiyemiyorum”
– Proje Sunumu: “Alın size bıçak, artık kesip küçük lokmalar yapabilirsiniz”

Toplantının Ön Analizinin Toplantısı

Bodoslama toplantıya dalan bir tip olmayın! Gidin önce, toplantı yapacağınız kişi hakkında bir ön bilgi edinin, şirketteki iş arkadaşlarınızla ya da daha önce o müşteriye gitmiş kişilerle biraz muhabbet edin. Nasıl bir insandır önce öğrenin; ”Düşmanı Tanımak” ya da “Egoyu Ölçeklemek” dediğimiz bu işlem size kişinin nasıl bir ego haritasına sahip olduğu hakkında fikir verecektir. Gözünüzü korkutmayın, baştan korkarsanız hiç bir projeyi tam olarak çıkartamazsınız, müşterinin kölesi durumuna gelir ve saçma sapan, sonu gelmeyen isteklerin kölesi olursunuz.

Kişinin olabileceği tipleri burada ele almaya çalışırsak kendi başına büyük bir makale olur. Zira onu da başka bir yerde inceleyeceğim. Ego bakımından tehlike derecesine göre üç ana kategoriye ayrılır bu insanlar.

  • Egosu olmayan müşteri; kısaca projeye muhtaç müşteri.
  • Egosu orta seviye olan müşteri; kısaca sizi küçümseyen ama dile getiremeyen müşteri.
  • Egosu tavan yapmış müşteri; onunla ancak CEO irtibata geçebilir, siz kimsiniz ki karşısına çıktınız onun?

Toplantının Hazırlığı

Toplantı yapacağınız mekana gitmeden önce yapmanız gereken işleri gözden geçirmeniz gereken aşama burası. Önce dokümanlarınızı hazırlayın, asla orada eksik belgenizin olmasını istemezsiniz. Toplantı daha önceden ayarlanmışsa, bir iki gün öncesinden kız isteme mesajı atın; ”Yarın yapacağımız toplantı için uygun musunuz?” gibi kibarlıktan öleceğiniz bir mesaj. Toplantı günü için ayarlanmış kaliteli kıyafetler. Falan filan, bunları her yerde bulabilirsiniz. Esas önemli olan o kişiye karşı uygulayacağınız stratejinin nasıl olacağıdır.

Kişinin ego seviyesini, yeterli kişi ile görüştükten sonra çıkarttıysanız bu kişilere karşı uygulayacağınız stratejik planı da çıkartmanız gerekmektedir. Ayrıca bu bilgileri toplarken, Proje Yöneticinizden projenin anlam ve önemi hakkında bir bilgi de isteyiniz, eğer bu konuda bilgi sahibi değilse maalesef bir bacağınız topal olacak ama yine de sağ çıkacaksınız, korkmayın!

Toplantının yapılacağı yere erken gelmeniz değil, toplantı odasına toplantı vakti girmeniz önemlidir! Egosu ne olursa olsun, insan sonuçta saygı görmek ister.

Toplantı Masası

Toplantıyı eğer birden fazla kişi ile yapacaksanız, masanın asla başına oturmayın, yan taraflara oturun ki masayı geniş bir şekilde görebilir, kişilere eşit ilgi gösterebilirsiniz. Toplantı masası yukarıda da dediğim gibi sizin savaş alanıdır ya da daha kibar hali ise satranç tahtanız. Burada soracağınız her soru, proje için diyeceğiniz her laf ilerde sizin aleyhinize delil olarak kullanılabilir. O yüzden bu masanın heyecanına kapılıp asla olmayacak şeyler için söz vermeyin. Karşınızdaki kişi mantar değil sonuçta, o da çalıştı ve buralara kadar geldi.

Strateji!

Karşınıza müşteri geldiğinde, kişiyle ilgili edindiğiniz önyargıları hemen masanın kenarına itin. Önce karşınızdaki kişiyi anlamaya çalışın. Adettendir bir beş dakika ya da on dakika bir geyik yapın. Hem onun stresini alırsınız, hem de kendi gerginliğiniz yatışır. Eğer acelesi varsa standart “naber”, “naaptın reyiz” cümlelerini kullanabilirsiniz. Tabii ana fikri anladığınızı düşünüyorum.

Ego derecesine göre strateji yönelimlerini ele alalım.

Düşük Ego

Yukarıda özetlediğim gibi, bu kişiler esasında sizin projenize muhtaç olan kişilerdir. Yine de bu insanlara, onların sizin projenize olan ihtiyaçlarını belli etmemek büyük bir özen ister. Zira köşesine sıkışmış bir kediyle asla uğraşmak istemezsiniz! Bu kişiye var olan projenizi dilediğiniz gibi anlatabilir, diğer müşterilerinizle ne kadar mutlu mesut yaşadığınızı belirtebilirsiniz. Hatta eğer karşıdaki ile kanka moduna girmeye yaklaşırsanız, müşterileriniz ile yaşadığınız sorunları esprili bir dille anlatabilirsiniz.

Orta Ego

Bu arkadaş aslında daha önceden bir ajansta falan çalışmıştır ya da içten içe kıl olduğu bir akrabası ya da arkadaşı yazılımla ilgilenmektedir ve bunu dile getirmek için fırsat kollamaktadır. Asla ama asla o kişiye karşı tepki vermeyin, haklısınız deyin geçin. Zira amacınız orada laf dalaşına girmek değil, proje hakkında bilgisini almaktadır. Kısaca biraz okşayın arkadaşı – fiziksel değil, laflarınızla. Bu arkadaşın o zamanlardan kalan sinirini ya da bilgisini kullanın; o zamanlardan laf açın, projede eksik gördüğü kısımları belirtmesini isteyin, onun gibi zamanında bizim sektörümüzde çalışmış kişilerin bilgisinin programa çok fazla yarar sağlayacağını, bunun sayesinde hem onun hem de şirketin kazanacağını belirtin. Kısaca biraz yağlayın arkadaşı. O zaten sizin böyle davrandığınızı gördüğü anda bayrakları indirecektir. Çok vermeyin yağı ama egosu makul ölçülerde seyretsin.

Bu tip kişilere ayrıca toplantı sonrasında doküman paylaşımı, istedikleri güncellemeleri gönderebilecekleri bir e-posta adresini ve iyi niyetlerinizi verin. Kapıdan çıkınca hepsini unutacaksınız zaten.

Yüksek Ego

İşte şimdi ayvayı yediniz. Bu arkadaşa yapabileceğiniz tek şey onun egosunun altında ezildiğiniz hissiyatını vermektir. Genel kanının aksine yönlendirilmesi en kolay insanlar da bu insanlardır. Nasıl diye soracaksanız az önce dedim ya, ona hiç görmediği kadar ilgi gösterin. Onun engin bilgisinden ve deneyimlerinden elde edeceğiniz güzellikleri anlatın, projeyi daha önce profesörlerle ve nice PMP’ler ile tasarlamış olsanız bile, onunla konuştuktan sonra yeniden tasarlayacağınızı hatta ve hatta sırf bunun için geldiğinizi anlatın. Size baştan sona kadar projenin nasıl olması gerektiğini anlatsın dursun.

Toplantı içerisinde zaten projede olan şeyleri size hiç yokmuşçasına anlatacaktır çünkü o kategorinin ya da butonun ismi farklıdır. Siz yine de notunuzu alın, ilgiyle, canla, başla dinleyin kendisini. Hatta toplantıyı uzatmayın. Daha sonra tekrar görüşmek için kendisinden bir tane daha toplantı koparın. Bu insanla iki taneden az toplantı yapmayın, süreç hakkında sürekli saçma sapan e-postalar atın ki ilgilendiğinizi falan sansın.

En sonunda da zaten var olan modülleri sanki o anlatmış da siz development ekibine yeniden yaptırmış gibi pazarlayın.

Sonuç

Her şeyden önce toplantı öncesinde görüşeceğiniz kişiyi tanıyın, o kişi hakkında ne kadar fazla kişi ile görüşürseniz, hedefinizi tanımanız o kadar kolay olacaktır. Sinirlenme ya da savunma asla size bir satır daha fazla not aldırmayacaktır. Uyumlu olun, anlayışlı olun, gerekirse projeyi yapmış olan ekibi satın ama o bilgiyi o insandan söküp alın. Çetin ceviz olmak önemli bir noktadır fakat bilgiyi almak daha farklı bir nokta.

Yazılım’ın Boş Bir İş Olması

Şimdi aynı meslek grubundaki arkadaşlar bana kızabilirler, hatta başlığı okuyup eksiyi de basabilirler, fakat yazının sonuna kadar dayananlar anlayacak ki biz de biliyoruz da konuşuyoruz. Sonuçta bu meslekte az denemeyecek kadar çalışan birisiyim ben de1. Önce madde madde bu mesleği ele alalım, korkmayın gayet mantıklı şeylerden bahsedeceğim – şu an için bana mantıklı geliyor da olabilir. Öncelikle belirtmem gerek ki burada bahsettiğim tüm bilgiler kendi kişisel görüşlerimin yansımasıdır, başka bir amaca hitap etmemektedir.

Yazılım’ın Diğer Tanımı

Yazılım dediğimiz şey, şu an bu yazıyı okumanızı sağlayan teknolojinin ihtiyaç uyduğu mantığı, bilinci, yöntemi belirleyen sistemlerdir. Basitçe ele alırsak yazılımcı dediğimiz de bu sistemin oluşmasını sağlayan insanlara verilen genel ad, aslında bu meslek grubundaki insanların hepsinin başka adları da var, örneğin veritabanı uzmanı ya da yazılım mimarı gibi isimleri. Fakat bu blog içerisinde kimseye ayrımcılık göstermeyeceğimiz için, hepsine yazılımcı diyeceğim.

Basit tanımları geçtiğimize göre esas tanımlara geçebiliriz – sizi burada Boş işler yazılımcısının harikalar diyarına alıyoruz. Yazılım dediğimiz şey, esasında soyut bir şeydir ve soyut kavramlar kendi içlerinde ikiye ayrılırlar;

  • Boş soyutluk durumu: Sevgi, Aşk, Nefret gibi tanımlayabileceğimiz şeyler boş soyut kavramına girer.
  • Dolu soyutluk durumu: Bilgi, Felsefe, Din gibi tanımlayabileceğimiz şeyler de dolu soyut kavramına girer.

Yazılım da “dolu soyutluk durumu” içerisinde ele alabileceğimiz bir yaratımdır. Bu soyutluk durumunda, madde açısından bir şey yoktur. Sadece bilgi ve onun yansıması vardır. Bilgi ile diğer insanlara bir şeyler anlatabilir, onlara bir şeyler katabilirsiniz. Yazılım ile de hem kişiye, hem de teknolojiye bir şeyler anlatabilir, istediğiniz şeyi yapmasını sağlayabilirsiniz. Fakat yazılım da bilgi gibi somut bir duruma geçmeden önce tamamen soyut olarak ele alınan temellere dayanmaktadır.

Yazılım’ı Babaya Anlatmak

Başlığı okuyunca yüzünüzde oluşan ifadeyi gözlerimde görür gibiyim, genelde bu ifade küçük çocukların ebeveynlerine çok sevdikleri bir çizgifilmi alnatırken ortaya çıkmakta. Konudan şaşmadan devam edeceğim, soyut olayların en büyük sorunu başka insanlara anlatılmasıdır. Zira somut bir şey her daim paylaşılması en kolay şeydir, bir odunu başkasına göstererek, dokundurarak, koklatarak, hatta ve hatta ısırtarak anlatabilirsiniz ama bir yazılımda bunu yapamazsınız. “Gösterebilirsiniz, dinletebilirsiniz, robot kollarla dokundurabilirsiniz” demeyeceğim zira bunlar maalesef yazılımın sonrasında çıkan şeyler sayesinde olur. Yazılım geliştirdiğiniz IDE’de bulunan kodları gösterin bakalım karşı taraf ne anlayacak ondan. Bu maalesef soyut kavram içerisinde çalışan insanların kaderinde var.

Yazılım vs …

Bu meslek ile uğraşıyorsanız, siz de çok iyi biliyorsunuz ki toplumun gözünde asla bir marangoz kadar değerli olmayacaksınız. Sadece toplum olsa, aileniz öncelikli gelecek, sonra kız arkadaşınız, belki de çocuklarınız. Hiç bir zaman bir marangoz olamayacaksınız, çünkü o bir odunu alıp, ondan kereste almaktadır – burada marangozlardan saygıyla bahsedilmiştir, hayalimdeki meslek oydu – fakat siz bir avuç kelimeyi, çok az kişinin bildiği bir dile sökerek bir sonuç, bir sayfa, bir uyarı ekranı çıkartmak zorundasınız. Ayrıca sadece elektronik eşyalara bağlısınız, bir marangoz meyva bıçağı ile bilişer yapabilirken siz elinizde bir akıllı telefon olmadan ne yapabilirsiniz ki?

Görsel somut algılar maalesef içinde bulunduğumuz toplumun temelinde yatmaktadır. Yazılım maalesef bu mantığa uygun bir meslek ya da iş değişdir. İlerleyen zamanlarda belki teknolojinin gelişmesi ile bu konuda daha somut adımlar elde edebiliriz, ne bileyim maatbaa makinası gibi bir alete kodları yerleştirip tuşuna basınca yazılım falan çıkar aletin diğer ucundan, olur bir şeyler.

Felaket Senaryoları

Bu geyiği yapmadan bu blog girdisini bitiremezdim, yapamazdım, anlayın beni. Olası “Dünyanın Sonu” senaryolarını kafanızdan geçirin, çok dalmayın hızlıca geçirin. Sunucuların çalışmadığı, elektriğin olmadığı, teknolojinin 16.yy’a gerilediği bir dünyada siz ne iş yapabilirsiniz? O dünyada bir Felilozofa ne kadar ihtiyaç varsa bir Yazılımcıya da aynı ölçüde ihtiyaç vardır. Fakat bir marangoz öyle mi, alır eline aletlerini, barikatını kurar, mobilyalarını inşa eder. Somut adımlar atar ve prensesi kurtarır, siz anca ona bağımlı yaşayan sidekick’den öteye geçemezsiniz.

Hayatta kalmak için bile yeterli olmayan bir mesleğe mendup kişiler olarak bana Yazılım‘ın boş bir iş olmadığını maalesef kanıtlayamazsınız. Diğer insanlara kanıtlayabilirsiniz, hem de çok basit bir şekilde; Onlara sadece ne kadar maaş aldığınızı söyleyin.

  1. Sen mi büyüksün, hayır ben büyüğüm ben Yaşar Usta! ↩

Android Üzerine

Mobil, yazılımın geleceğidir!

Bu lafın doğruluğu tartışılamaz. Adamlar haklı, ne desek de haklı. Ben de bu haklılığa katılsam da, imkanlar izin vermediğinden pek yatırım yapamadım. Gel gör ki hiç umulmadık bir zamanda, bir insanın, şirketin ERP1 sistemine giriş yapan bir Android applikasyonunu piyasaya çıkartması ile ben de Mobil piyasına giriş yapmış bulundum. Tabii öncelikle o arkadaşa olan sinirimi bir kenara bırakmam da gerekmedi diyemem, burada dikkat etmemiz gereken nokta, şirket içinde kelle avını başlatmak yerine, bu arkadaşın açtığı karmaşayı bir nevi kâra çevirmek. Arkadaşımız iyiliklerle yazmış olsa da, şifreleri alıp kopyalamadığının garantisi maalesef yok, e biz de oturup bekleyemeyeceğimize göre kendi programımızı çıkartmalıydık.

Hikaye kısmı

Burası bildiğiniz hikaye kısmı. Gidilir Project Manager’dan onay alınır, IT Manager’dan onay alınır ve şirketin Android alanında uzman yazılımcısı bir gün kapatılarak proje hemen yazılmaya başlanır. Proje dediğime de bakmayın, bildiğin ERP sistemine link verecek olan, WebView aplikasyonu işte. Tasarımcıdan bir logo alınır, proje arkadaşın el hızlılığı ile 4 satırda halledilir ve Google Play Store‘a yüklenir2. Artık Google’ın onayı sonrasında duyuru yapmak kalmıştır. Burada dikkat edilmesi gerekilen nokta ise – esasen hepimizin kaçırdığı -; Hiç bir proje, bu kadar kolay yazılmaz!

Sorunlar

Play store’da çıkan programın üzerinde site açılır, kafalar rahattır ya da öyle sanılır. Sonrasında hemen geri dönüşler gelmeye başlar. Sen tabii git 2600 kişilik şirkete “Android’e yazılım yaptık eki eki” diye mesaj at, onlar da indirsin ve sorunlar başlasın. Sorunları ele alırsak;

  • Dosya download edemiyoruz,
  • Ekran çok küçük geliyor,
  • Raporlar sayfası açmıyor,
  • …ve bir takım eleştiriler…

Çözümler

İşte bugün tüm gün ilk noktaya kastık. Önce “Ya tabii WevView’de download yakalamamız gerek, ondan sanırım” dedik, değilmiş. Sonra “Başkalarında da olmalı bu sorun, bir de Google’a soralım” dedik, başımıza bela aldık. Sorunun iki yönlü ele alınması gerekiliyormuş;

  1. Android ayağı,
  2. ERP ayağı.

Çözümün Android Ayağı

Şimdi şöyle ki, siz böyle bir uygulama geliştirdiğinizde Android işletim sistemi için WebView kullanıyorsunuz, bu component de gidip sizin sitenizi açıyor fakat o kadarla bitse ne kadar güzel – iOS’da öyle3. Bu component bir nevi browser olduğu için bunu ayarlamanız ve buna uygun değişiklikler yapmanız gerekmekte. Bunlara örnek olarak javascript’in window.Open() methodu gibi kullandığınız noktaları açmanız4. Sonrasında isterseniz her açılan sayfanın uzantısına bakarak onu download edebilir, browser’a yollayabilir, DownloadManager’a göndermeye çalışabilirsiniz. Bu kısmi ayarlamaları yapmaya özen gösteriyoruz.

Çözümün ERP Ayağı

ERP her eşye hazırlıklı diyemeyiz tabii, o kısımda da yapılması gerekilen güncellemeler var. Bunlar tabii downloadManager.aspx dosyasında yapılmalı. Önce her gönderdiğimiz dosyanın header özelliklerini elden geçirmemiz gerek; Content-Type: application/octet-stream bunlardan biri. Sonrasında – hatta hiç ekstra eklemeden – Content-Disposition: attachment; filename="test.PDF" ekliyoruz. Bu ikinci kısımda “Content Disposition” kısmında dikkat etmemiz gereken noktalar ise; birincisi filename=”” olmalı yani filename’i çift tırnak içinde yazmalı, ikincisi ise uzantının büyük harflerle yazılması.

Çözümün Açıklaması

Android tarafında internetten bulduğunuz ilk kodu yapıştırdığınızda her şeyin güzel olacağını sanıyorsunuz ama öyle olmuyor, sırası ile gerçekleşen işlemler;

  1. WebView’dan proje açılır ve bir download linki tıklanır
  2. webView.setDownloadListener() kodu çalışır, bu kod ilgili sayfayı default browser’a gönderir
  3. Default browser POST yapar, aa bu bir file imiş ben bunu DownloadManager’a göndereyim der
  4. URL, Download Manager’a gelir. Bir kez de burada POST yapılır.
  5. Response Header dosyaları okunmaya çalışılır – okunamaz – ve dosya indirilir.

Kusura bakmayın ama böyle aşkın ben ızdırabını… Bu yöntemden kurtulmak için yaptığınız onca çalışma aslında daha da çok batmanıza sebep veriyor, Download Manager’a direk gönderim yapılabilir tabii bunu ben deneyemedim, vaktim yetmedi a dostlar. En kötü bir POST işlemi ile bitirirdik durumu.

Açıkcası bu kadar salak saçma bir mantıkla ilk defa karşılaşıyorum, kullanırken de sinirlendim ama sonuçta Android benim işletim sistemim değil. Bu işlemleri yapmamıza rağmen halen çalışmıyorsa – aslında çalışmıyorsa kodunuz yanlış, buradan eminiz, fakat kodunuz doğru ama yine de çalışmıyorsa – elimizde iki sonuç var demektir;

  • Download yapmaya çalıştığınız URL, korumalıdır.
  • Elinizdeki test aletinin Android sürümü uygun değildir.

Bizim durumumuzda her ikisi de kaynaklanmaktaydı. Şöyle ki siz bir dosya download ederken, o downloadManager.aspx dosyasına – artık hangi dilse – Session bazlı bir uygulama yaparsanız ya da HttpContext bazlı bir güvenlik yaparsanız, URL sürekli oradan buraya taşınacağı için bu değerleri yitirmekte ve sizi engellemektedir. Çok pis bir durum değil mi? Kendi güvenlik kodunuz tarafından alıkonmak!

Çözüm için, Android App içine gömeceğiniz bir URL validator kodu ile, sizin ERP projenizde bu validator string’i kontrol etmeniz. Eğer doğru ise kim olduğuna bakmadan download ettirmeniz. Ha bu teorik olarak bir güvenlik açığı yaratmaz mı? Bence babalar gibi yaratır ama elimizde maalesef çözüm olarak bu bulunmaktadır.

Ayrıca dikkat edelim test yaparken, ne kadar etrafınızda Android telefon varsa test edin, birinde çalışan kod diğerinde çalışmamakta ve bu sinir katsayılarını zıplatmaktadır. Siz çalışıyorsa bozmayın, direk yayına alın. Gerisini kullanıcılar düşünsün.

Bu konu ile ilgili devam eden yazılar tabii ki olacak, o zamana dek görüşmek üzere…

  1. Enterprise Resource Planning [Wikipedia] (http://tr.wikipedia.org/wiki/Kurumsal_kaynak_planlaması “Kurumsal Kaynak Planlaması”) ↩
  2. Sizden 25$ gibi bir ücret alıyor ama şirket adına gösterebiliyorsunuz. ↩
  3. Bu kısımla ilgili detaylı bir post hazırlanacaktır. ↩
  4. Bu “Sorunlar” kısmının üç numaralı sorununun çözüm noktasıdır, gözlerden kaçmasın. ↩

Yıllar sonra yeniden blog açmak

Bugün blog açacağım diye o kadar çok kastım, o kadar çok servisi araştırdım ki ne kadar boş bir insan olduğu tekrar anladım. Neyse uzun lafın kısası WordPress’de kaldık yine. Fakat bu blog açma serüveninde eskilere gitmedim diyemem.

Ah o eskiler

İlk blog sayfamı 08.2007 yılında açmışım. O zamanlar WordPress’de var ama bu kadar parlak bir geleceği belli değildi – ya da ben yanlış yorumlamıştım – ve ben Blogger üzerinde açmışım. Aslında ondan da önce bir blog açmışım gibi bir his var, böyle web 2.0 zamanlarının olduğu vakit açmış olmam lazım ama pek emin olamadım. Şimdi tutup da kendi adımı Google’da aramak da istemiyorum, çok sıkılıyorum sonra bulduklarımdan.

Eski Blogda bir sürü boş şeyden bahsetmişim, kedim varmış o zamanlar. Düşünün, kedim varmış!!! lan kaç yıl önceki olay kedi beslediğim günleri bile unuttum sayılır. Zaman ne kadar da hızlı geçiyor. 2008 zamanında çok entry girmişim oraya ama sonra pek uğramamışım, en son 2010 yılında Blogger API için bir entry girmişim. Sonrasonda tekrar blog açmak istedimsede olmamış, “ne yapalım allah baba da beni böyle yaratmış” diyerek kaderimi kabul etsem de, son zamanlarda aklıma gelen fikirleri paylaşmak için geçen sene ya da ondan önceki sene bir hikaye blog’u açmıştım; Yazdım, Oku! adında. Gayet de güzel başlasa da, sonrasında elimde draft halde bulunan hikayeleri oraya paylaşamayacak kadar boş işim oldu elimde.

Yeni Başlangıç

İşte bu yüzden, sonra zamanlarda aklımda olan Yazılım Blog‘u açma fikrini bugün hayata geçirdim. Fakat burada bir sürü teknik – şeyden – detaydan bahsetmek yerine, bu işin felsefik yanlarına da değinmeyi planlıyorum. Tabii yazılımla ilgili takıldığım noktalarla ilgili yazılarım olmayacak değil. İlerleyen zamanlarda, burayı terk ettikten sonra en azından anı olur bana, eğlenirim falan.