• Oct
  • 18
  • 2014

NedirTV – Yazılım Teknolojileri etkinliğindeki sunumum…

Tags: , , | 170 kez okundu. |

Daha önce yine buradan duyurduğum, NedirTV Yazılım Teknolojileri etkinliğini bugün oldukça keyifli bir şekilde gerçekleşti. Microservices ile ilgili benim de küçük bir sunumum vardı. Umarım, az biraz da olsa faydalı olmuştur. Buradan tüm katılan arkadaşlara bir kez daha teşekkür etmek isterim. Açıkcası ummadığım bir şekilde, çok güzel bir kalabalık vardı. Teşekkürler…

Etkinlikteki sunumumu aşağıda bulabilirsiniz. Başka bir etkinlikte görüşmek üzere.

 

Microservices Sunumu NedirTV etkinliği

  • Oct
  • 10
  • 2014

“Code Contracts” da kullanmak lazım…

Tags: , , , , | 258 kez okundu. |

Code Contracts‘ın, uzun bir süredir .NET platformunda da olan ancak çok fazla kullanılan bir kavram olmadığını, ama oldukça önemli bir özellik olduğunu düşünüyorum. Alışkanlıkların ve kolayı tercih ediyor olmamız, avantajlarının önüne geçtiğinden öneminin çok farkında olmuyoruz sanırım bu tarz özelliklerin.

Code Contracts, temelinde yazdığımız koda, adından da anlaşılacağı üzere, statik kontratlar belirlememizi sağlıyor. Bu kontratlar, pre-condition ve post-condition olarak kodun belirtilen yerlerinde derlenme aşamasından sonra(statik analiz) ya da belirtilirse run-time sırasında da çalışıyor. “Pre-Condition” ve “Post-Condition“  dışında, koddaki sınıfların durumlarını da kontrol etmek için Code Contracts’dan faydalanabiliyoruz. Ayrıca test otomasyonu ve test edilebilir kod yazmak için, Code Contracts oldukça önemli bir özellik ve hatta kolaylık.

contracts_Yazdığımız metotların aldığı parametreleri doğrulamak ya da parametrelerin durumlarını kontrol etmek, bir yazılım geliştirirken mutlaka yaptığımız bir şey. Bu, iş kurallarının oluşturulması ve kodun sağlıklı çalışması için olarak iki açıdan yorumlanabilir. Örnek olarak, kodun sağlıklı çalışması için null kontrolünün yapılması ya da iş kurallarını oluşturmak için yaşın 18’inden büyük olmasını kontrol etmeyi verebilirim.

Bu tarz kontroller daha doğrusu ihtiyaçlar yazdığımız birim testleri ile zaten sağlanacak ya da sağlanması gerekliliği ortaya çıkacaktır. Bu noktada Code Contracts bu gerekliliğin ortaya çıkmasında oldukça faydalı.

Sizden başka kişilerin de geliştirme yapması için sunacağınız, API, kütüphane falan tarzı şeyler geliştiriyorsanız da ayrıca Code Contracts oldukça faydalı olacaktır. IsAgeValid(int age) şeklinde sunduğunuz bir metoda, statik olarak verilecek parametrelerin kontrolünü, Code Contracts ile gerçekleştirirseniz, bu metodu kullanan yazılımcı, 18’den küçük bir değer girdiğinde, derleme aşamasında hata/uyarı alacağından ilerleyen adımlarda oluşacak hataların önüne geçilebilir.

Neleri, nasıl yapıyoruz kısaca kod üzerinden de bakalım. System.Diagnostics.Contracts namespace’indeki sınıfları Visual Studio ile entegre olacak şekilde kullanabilmek için öncelikle Code Contracts Tools’u kurmak gerekiyor. Bu adresten ilgili kurulumu hemen yapabilirsiniz. Code Contracts, proje seviyesinde ayarlanabilen, açılıp, kapatılan bir özellik. Proje özelliklerini açarsanız aşağıdaki gibi bir ekran ile istediğiniz ayarı yapabilirsiniz.

CodaContracts

Sarı ile belirttiğim ayarları özellikle yapmanızı tavsiye ederim. Bu ayarlar kodunuzun statik olarak analiz edilmesi ve kontratların işletilmesini, eğer bir uygunsuzluk var ise de Error olarak çıkmasını sağlıyor. Eğer Fail build on warnings seçili olmaz ise, uygunsuzluklar Warning olarak gözükecektir.

Code Contracts’ları peki nasıl tanımlıyoruz?

Aşağıdaki gibi AddUser(User user) şeklinde bir metodumuz var diyelim. Ve bunu metodun parametresindeki User sınıfının hangi özelliklerinin tanımlanması ve nasıl tanımlanması gerektiği, metodu çağıran kişi tarafından bilinemez, -eğer farklı bir şekilde belirtilmediyse. Contract.Requires() metodu ile metotların input’larını yani parametrelerini, belli koşulları(pre-conditions) sağlıyor mu diye kontrol edebiliriz.

Devam…

  • Oct
  • 09
  • 2014

C# 6.0 ile ilgili…Bakmakta fayda var…

Tags: , | 319 kez okundu. |

İlerleyen aylarda C# 6.0 çıkacak bildiğiniz üzere. Compiler’ın komple değişmesi, servis olarak sunuluyor olması gibi bir çok büyük yenilikten ve dilin yeni özelliklerinden hep bahsetmek isteyip hep tembelliğime yenildim. Ayıp bana… Yakın zamanda bunlar ile ilgili bir şey yazmak istiyordum ki, ay başında C# 6.0’ın daha önceden duyurulan bazı yeniliklerinden vazgeçildiğini okudum. Tüm motivasyonum gitti…Nasıl bahane ama… :)

C#'ın evrimiEskiden beri blog’u takip edenler belki hatırlar; bir ara “Bakmakta Fayda Var” diye, Türkçe kaynaklar paylaşıyordum. Çeşitli bloglarda, hoşuma giden ve faydalı olduğunu düşündüğüm yazılara, görmeyen,okumayan kalmasın diye link veriyordum. C# 6.0 motivasyonumun düşmesi(!) ve bu paylaşımları uzun zamandır yapmıyor olmanın verdiği utanç ile, C# 6.0 yenilikleri hakkında yazılmış Türkçe kaynakları paylaşarak biraz ayıbımı kapatmaya çalışacağım. Belki ilerleyen zamanlarda ben de bir şeyler karalarım. Ama zaten konusunda uzman kişiler çok güzel yazıp, yenilikleri anlatmış. Daha son hali çıkmadan, neler geliyoru takip etmek için mutlaka bakın derim…

Haa bu arada C# 6.0 yeniliklerinin son durumu aşağıdaki gibi. “Primary Constructors”, “Declaration expressions” ve “Event initializers” son durumda tamamen kaldırılmış gözüküyor…Üzülmedim desem yalan olur… Son halini alana kadar, gelişmeleri ve yenilikleri http://roslyn.codeplex.com/ adresinden takip edebilirsiniz.

Feature

Example

C# VB
Primary constructors class Point(int x, int y) { … } No No
Auto-property initializers public int X { get; set; } = x; Done Exists
Getter-only auto-properties public int Y { get; } = y; Done Done
Ctor assignment to getter-only autoprops Y = 15 Done Done
Parameterless struct ctors Structure S : Sub New() : End Sub : End Structure Done Done
Using static members using System.Console; … Write(4); Done Exists
Dictionary initializer new JObject { ["x"] = 3, ["y"] = 7 } Done No
Indexed member initializer new JObject { $x = 3, $y = 7 } No No
Indexed member access c.$name = c.$first + ” ” + c.$last; No Exists
Declaration expressions int.TryParse(s, out var x); No No
Await in catch/finally try … catch { await … } finally { await … } Done Maybe
Exception filters catch(E e) if (e.Count > 5) { … } Done Exists
Typecase Select Case o : Case s As String : … No Maybe
Guarded cases Select Case i : Case Is > 0 When i Mod 2 = 0 No No
Partial modules Partial Module M1 N/A Done
Partial interfaces Partial Interface I1 Exists Done
Multiline string literals “Hello<newline>World” Exists Done
Year-first date literals Dim d = #2014-04-03# N/A Done
Binary literals 0b00000100 No No
Digit separators 0xEF_FF_00_A0 No No
Line continuation comments Dim addrs = From c in Customers ‘ comment N/A Done
TypeOf IsNot If TypeOf x IsNot Customer Then … N/A Done
Expression-bodied members public double Dist => Sqrt(X * X + Y * Y); Done No
Event initializers new Customer { Notify += MyHandler }; No No
Null propagation customer?.Orders?[5]?.$price Done Planned
Semicolon operator (var x = Foo(); Write(x); x * x) No No
Private protected private protected string GetId() { … } No No
Params IEnumerable int Avg(params IEnumerable<int> numbers) { … } Maybe Maybe
Constructor Inference new Tuple(3, “three”, true); No No
String interpolation \{p.First} \{p.Last} is \{p.Age} years old.” Planned Planned
TryCast for nullable Dim x = TryCast(u, Integer?) Exists No
Delegate combination with + d1 += d2 Exists No
Implicit implementation Class C : Implicitly Implements I Exists No
nameof operator string s = nameof(Console.Write); Done Planned
Strict modules Strict Module M Exists No
Faster CInt Dim x = CInt(Math.Truncate(d)) | Exists No
#pragma #Disable Warning BC40008 Done Done
Checked and Unchecked blocks Checked : x += 1 : End Checked Exists No
Field targets on autoprops <Field: Serializable> Property p As Integer Maybe Maybe
If(b,e1,e2) uses type context Dim x As Integer? = If(b,1,Nothing) N/A No
  • Oct
  • 08
  • 2014

ING Bank’dan bankacılık hackathon’u…

Tags: | 209 kez okundu. |

Hackathon kavramı son bir kaç yıldır oldukça yaygınlaştı. Türkiye’de de artık şirketler bu tarz yazılım etkinliklerine çok yavaş da olsa destek vermeye başlıyor. Bu desteğin en sonuncusu, Hack-ING ismi ile ING Bank’ın düzenlediği, 31 Ekim – 2 Kasım arasında gerçekleşecek olan ”Bankacılık Hackathonu”.

ing-hackathon-posterFinansal sektör için, teknoloji ve hayal gücünüz ile beraber, bir sınır olmadan tüm fikirleriniz bu hackathon’da yer alabilecek.

Aslında tek bir konu yok! İnternet bankacığılını geliştirmek, alternatif kişisel finans çözümleri veya sistemleri üretmek, alternatif mobil ödeme çözümü veya sistemi icat etmek, daha iyi veya fonksiyonel bir ATM arayüzü ya da sistemi geliştirmek, kimsenin aklına gelmeyen bankacılık işlemleri veya sistemleri alternatifleri üretmek! Kısacası bankacılıkla ilgili her şey bu etkinliğin konusu! Bankacılık hayatımızı daha nasıl kolaylaştıra bilir?

Herhangi bir sınırlama olmadan, teknoloji ve hayal gücünü kullanarak istediğiniz şeyi üretebilirsiniz!

İster takım, ister bireysel katılabileceğiniz bu etkinlik için tüm ayrıntıları ve katılım ile ilgili bilgileri bu adresten takip edebilirsiniz. Son katılım tarihi 24 Ekim, o yüzden elinizi çabuk tutun derim.

 

Hackathon dışında ING’den, Amazon ve Githup’dan da konuşmacıların yer alacağı çeşitli sunumlar da etkinlik kapsamında olacak.

 

ING Bank Hackathon program

Birinci olan kişi/ekip, 10.000TL değerinde Teknosa’dan hediye çeki ile ödüllendirilecek. Kurumsal şirketlerin bu tarz etkinlikler düzenlemesi ve bu şekilde yazılıma destek vermesi umarım ilerleyen zaman içerisinde daha çok rastladığımız bir şey olur.

 

 

  • Oct
  • 01
  • 2014

Prensip sahibi yazılımlar VOL. II

Tags: , | 262 kez okundu. |

Yazılım geliştirirken karşılaştığımız problemler ya da karşılamamız gereken ihtiyaçlar ne kadar farklı olsada, bir noktada bu problem ve ihtiyaçlara bakış açısı ortak hale geliyor. Belli kalite özelliklerini korumak ve katma değer katan çözümler oluşturabilmek için bu ortak nokta da prensipler ile karşılaşıyoruz. Bir kaç önceki yazımda ortaya atılan bu prensiplerden bahsetmeye başlamıştım. Şimdi bir kaç tanesinden daha bahsetmek istiyorum.

DRY – Don’t Repeat Yourself

Geliştirdiğimiz yazılımlarda, -hatta biraz daha derine girim; sınıflarda/metodlarda asıl katma değeri oluştururuz. Yani temelinde, bir metod içerisindeki yazdığımız algoritma ya da oluşturduğumuz obje modeli karşılamamız gereken ihtiyacın ya da çözülmesi gereken problemin cevabıdır. Çözmeye çalıştığımız problemler büyüdükçe ve karmaşık hale geldikçe, daha önce kullanmış olduğumuz cevapları tekrar kullanmaya başlarız. Bu noktada DRY prensibi dur der. Kendini tekrarlama diye karşımıza çıkar.

Geliştirdiğimiz yazılımlarda, çözüm olarak oluşturduğumuz yapıların yazılım içerisinde tek bir tane olması gereklidir.  Bunun önüne geçemezsek, bir problem için, aynı çözümün birden fazla versiyonu kodun içerisinde kendine yer bulur… Gelişir, gelişir, büyür ve kodun bakımını zorlaştırır. E-mail validasyonu yapan bir yapı ile aynı validasyonun daha farklı bir string operasyonu ile yapılıyor olması, yazılım içinde de tutarsızlığa yol açar. Sonra uğraş dur…

Kod yazarken, daha önce benzer bir çözüme benzediğini düşüyorsanız, o çözümü re-use edilebilecek hale getirmek en uygunu olacaktır.  DRY prensibini uygulamak için code-generation araçları ve kod dökümantasyonu oluşturan araçlardan faydalanmak kolaylık sağlayacaktır. Referans kitabı olarak arasıra danıştığım, David Thomas-Andrew Hunt ikilisinin yazdığı, The Pragmatic Programmer kitabını DRY prensibi ile ilgili olarak şiddetle tavsiye ederim. Uygulanabilirliği konusunda güzel ip uçları içermekte.

SoC – Seperation Of Concerns

separation of concernsSoC, yazılımdaki elemanların kendilerine özel olmasını, sorumluluklarının kendilerine ait olup, başka elemanlar ile paylaşmamasını söyler. Sorumlulukların ayrı olmasının gerekliliği bu prensibin altını çizdiği temel noktadır.  Yazılımı geliştirirken, “sınır” diyebileceğimiz kavramlar bu sorumlulukları bir birinden ayıran en net ifadeler olabilir. En basitinden, layer ve tier kavramları ile belli sorumlulukları bir birinden ayırırız. Birazcık daha içeri girersek, yazılım bileşenlerimizin namespace’leri de, sorumlulukları ayırmak için kullanabileceğimiz sınırlardır diyebiliriz.

Genelde bu sorumlulukları belirlerken, çok küçük parçalara kadar inmeye çalışırız. Çok küçük parçalardan daha önemli olan sorumluluk kümelerinin net ve ayrı olabilmesidir. Einstein’nın bir lafı vardır çok hoşuma giden,  “Make everything as simple as possible, but not simpler.” Her şeyi basit yap ama daha basit yapma…Benzer şekilde sorumlulukları küçük parçalara ayır ama daha da küçültme şeklinde bu konu için yorumlayabilirim. Sorumluluk kümelerini iyi oluşturamazsak, ayrık ayrık bir sürü parça sistemde kaybolur gider. Bu da çok iyi bir şey değil.

Yazılım içindeki bileşenlerin bir birine bağlılık derecesi(coupling) ve bileşenler içerisindeki sorumluluk ilişksi(cohesion), SoC prensibi için önemli iki kavramdır. Bileşenlerin bağlılık derecesinin düşük olması ve bir bileşen içindeki sorumluluk ilişkisinin yüksek olması her zaman tercih edilmelidir. Yani low-coupling, high-cohesion olmazsa olmaz… Bu sayede bağlılık derecesi düşük olursa, sorumlulukar bileşen başına dağılmış olacağından yazılımın kontrolü bizim elimizde daha kolay olacaktır.  Bileşenler içerisindeki sorumluluklarında bir birlerine yakın olması, re-usebility’i ortaya çıkaracaktır.

SoC prensibi, geliştirdiğimiz yazılımları genişletebilir yapabilmenin de en önemli noktasıdır. Sorumlulukları ve bağlılıkları iyi ayırabilmeyi söylediğinden dolayı, yazılımlarımızın esnek ve genişleyebilecek alt yapıda olmasına ön ayak olur.

Bu iki önemli prensip de yazılım geliştirmede oldukça önemli konuların altını çiziyor. Pratik olarak zaman zaman dikkat etmesi zor olsa da, gerçekleştirildiği takdirde oldukça faydalı sonuç vereceklerdir.

  • Oct
  • 01
  • 2014

18 Ekim, Yazılım Teknolojileri Seminerleri…

Tags: | 302 kez okundu. |

18 Ekim Cumartesi günü, İstanbul Şehir Üniversitesi‘nde düzenlenecek olan, artık geleneksel hale gelen, NedirTV?com’un bir etkinliği mevcut. Yazılım ve yazılım sektörü ile ilgili çeşitli konuların deneyimli ve tanıdık simalar tarafından paylaşılacağı bu mütevazi ve sıcak etkinliği kaçırmamanızı tavsiye ederim. Benim de Microservices ile ilgili sesli düşüneceğim bir sunumum olacak. Fırsat yaratıp da uzun süredir göremediğim arkadaşları da bu vesile ile görecek olmak benim için ayrı bir motivasyon. :)

Etkinlik programı ve ayrıntıları aşağıdaki gibi; katılmak için bu adresteki kayıt formunu doldurmanız gerekmekte.

18EkimNedirtv.com‘un düzenlediği Yazılım Teknolojileri Seminerleri yazılım dünyasının deneyimli konuşmacılarını bir araya getiren yazılım ve bilişim teknolojileri etkinliğidir. Arda Çetinkaya, Burak Selim Şenyurt, Ercan Bozkurt, Muhammed Cuma Tahiroğlu ve Nezih Tınas‘ın etkinlik boyunca yapacağı beş farklı sunuma katılmak için etkinlik.com.tr üzerindeki kayıt formunu doldurmanız yeterlidir.

Etkinlik programı
10:00 Kurumsal Uygulamaları(Enterprise Applications) Tanıyalım – Burak Selim Şenyurt
11:10 Bir “Canlı Ön Analiz” Toplantısı – Nezih Tınas
12:20 Ara
13:00 Microservices – Arda Çetinkaya
14:10 Fonksiyonel Paradigma – Muhammed Cuma Tahiroğlu
15:30 Sanal Gerçeklik – Ercan Bozkurt

Sunumlar boyunca sponsorlarımızın ilettiği sürpriz hediyelerimiz olacaktır.

Etkinlik Sponsorları
Microsoft Türkiye
Dikeyeksen Yayıncılık
Kariyer Mimarı
Portya

Destekleyenler
İstanbul Şehir Üniversitesi Kuluçka Merkezi

 

Bu etkinliğin gerçekleşmesini sağlayan ve bana da yer veren NedirTV?com‘a ve Uğur Umutluoğlu‘na buradan tekrar teşekkür ederim. Etkinlikte görüşmek üzere.

  • Sep
  • 29
  • 2014

“Test” yazamıyoruz, çünkü test edilebilir kod yazmıyoruz…

Tags: , , | 627 kez okundu. |

Test kavramı bir yazılım için olmazsa olmaz. Sanırım artık bu herkesin kabul ettiği bir şey. Yazılımın çalıştığını kanıtlamak, ihtiyaçları karşıladığını göstermek ve belli kalite özelliklerinin sağlandığını doğrulamak için en somut çalışmalardan biri. Çeşitli test adımları, test türleri ve test süreçlerinden çok yazılımcı olarak, geliştirme aşamasında yapmadığımız testlerden bahsetmeye çalışacağım. Neden yapmadığımızın sebebini bulabiliriz belki…

Neden “test” yazmıyoruz?

Bir çok sebep sayabiliriz sanırım. “Zaman bulamıyorum”, “Gerek duymuyorum”, “Test benim işim değil ki”, “Test kodu yazacağıma, 10 tane ekstra özellik yazarım” falan gibi çeşitli sebepler sanırım çoğu kişinin ortak cevabı olacaktır. Biraz acı olacak belki ama ne yazık ki bunlar bahaneden başka hiç bir şey değil. Hiç biri geçerli bir sebep değil. Test yazmıyor olmamızın en büyük sebebi, aslında kendimiziz. Test

Yazdığımız kodların, test edilebilir olmaması test yazmıyor olmamızın en büyük sebebi. Test edilebilir kod yazmak, test yazmaktan çok daha zor bir olay ne yazık ki. Test yazmak isteyip de bu gerçekle karşılaştığımız zaman, motivasyonun kaybolması ve test yazmayı bırakmak en çok duyduğum ve bizzat da yaşadığım bir olay. Test edilebilir kod yazmak, belli bir zaman geçtikten sonra bazı konulara hakim olduktan sonra daha kolay olacaktır. Bu noktada herkes biraz öz eleştiri yaparsa benzer şeyleri düşüneceğine inanıyorum. Test edilebilir kod yazmak, çeşitli yazılım geliştirme prensiplerine hakim oldukça daha kolaylaşacaktır. Yazdığınız kodlar için birim test yazmaya başladığınızda bir noktada tıkanıyorsanız, yılmadan neden yazamadığınız, kodun neresinde tıkandığınız konusunda düşünmeye başlayın. Daha sonra problem ile ilgili olabilecek prensipleri(mesela OOP prensipleri yani SOLID ya da diğer prensipleri; YAGNI,KISS….vs.), kodunuzda doğrulamaya çalışın. Bu şekilde hem kodunuzu iyileştirmiş, hem de test edilebilir bir koda sahip olmuş olacaksınız. Zamanla bu bir alışkanlık haline geleceğinden, yazdığınız kod için birim test yazmak çok daha kolay olacaktır. Yazdığınız kodlara, test yazabiliyor olmak, programınızın çalışabilirliğini doğrulamak dışında, tasarımınızı da doğru bir şekilde refactor etmenizin en etkili yöntemi olacaktır ayrıca.

TDD

Test yazmak, farklı bir düşünce yaklaşımı da gerektirdiğinden, normal bir kodla, test kodu yazmak farklılık gösterecektir. Genelde metod yazarken, ilk olarak “doğru” sonuç odaklı bir yöntem izleriz. Çünkü, “doğru”yu zaten biliyor oluruz ve bu genelde kolay gelir. MusteriGetir() diye, belli bir parametre aldığında müşteri bilgilerini getiren metodu yazarken, getirilen müşterilerin aktif/pasif durumu, geçerli bölgesi, alışveriş durumları vs. gibi kontrol edilmesi gereken arka plandaki ihtiyaçlar sonradan kodumuzda yer bulur. Hele bu ihtiyaçlar net değilse, en basit kontrol durumları bile atlanır. Olmaz demeyin, oluyor… Ancak ilk olarak “doğru” sonuçlara odaklanmak yerine, olabilecek diğer ihtimalleri de kontrol edebilecek bir şekilde kodumuzu tasarlarsak, test edebileceğimiz kapıları kendiliğinden açmış olacağız. Daha sonra test yazmak zaten kolay olacaktır. Çünkü kapılar bize neleri test etmemiz gerektiğini gösterecektir. Bu noktada TDD(Test Driven Development)’ın altını çizmek isterim. Benim çok tercih ettiğim bir yaklaşım olmasa da belki size kolaylık sağlar. TDD ve test yazmanın farklı şeyler olduğunun da ayrıca özellikle altını çizmek isterim. TDD, birim testlerinizi önce yazarak kodu geliştirme yönünde sizi motive eden bir geliştirme yöntemidir. Bunun dışında, test yazmak, birim test geliştirmek, geliştirmelerinizi tamamladıktan sonra da yapabileceğiniz bir aktivite olduğundan TDD’den farklı olarak yorumlanmalıdır. TDD’nin, test edilebilir kod yazma konusunda etkili olduğuna inanıyorum ama daha yazmadığınız bir şeyi test ederek ortaya çıkarmak, yukarıda bahsetmiş olduğum tasarımı etkili refactor etme konusunda engel olarak karşınıza çıkabilir. En azından benim çıkıyor. Belki daha yeterince oturmamıştır bazı şeyler, kim bilir… Bu konu biraz karışık ve uzun. Hatta bu sene Martin Fowler, Kent Beck ve David Heinemeir Hansson’un güzel bir sohbeti var. Biraz uzun ama mutlaka izleyin, dinleyin derim… Bu adresten ulaşabilirsiniz.

Devam…