Arda Çetinkaya Yazılım ve arada kendim ile ilgili karaladıklarım…

Çok uzun süredir yazmıyormuşum bir şeyler…Bunun bile farkında değildim, ne feci…Geçtiğimiz günlerde Microsoft, TechEd etkinliğinde, ASP.NET ile ilgili açıkladığı yeni şeylerin gazı ile, belki aradaki boşluğu kapatırım.(İç ses: Yalannn!!! :P)

Neyse, fazla dağılmadan paylaşmak istediğim konuya geliyorum hemen…ASP.NET vNEXT…Geçtiğimiz haftalarda Microsoft, TechEd North America etkinliğinde ASP.NET ile ilgili gelecek vizyonunu ve nelerin geleceğini ilk defa paylaştı. Oldukça şaşırtıcı ve merak uyandırıcı konular, önümüzdeki aylarda bayaa karşımıza çıkacak gibi. Bu büyük yenilikler, geliştirilen uygulamalara nasıl yansıyor olacak, ayrıca merak ettiğim bir konu ama zamanı gelince hep beraber görüyor ve hatta içinde olacağız sanırım.

.NET vNext
Öncelikle gelen en büyük yenilik, CLR’ın server ve cloud için optimize edilmiş olması. Bu sayede, sunucuda çalışan web uygulamalarının, standart .NET Framework CLR’ından ayrı, cloud/server senaryolarına uygun bir CLR ile daha performanslı çalışabilmesi düşünülmüş. Yani web uygulamasının çalıştığı CLR, artık tüm .NET Framework CLR’ını içermek zorunda kalmayacak. Bu hız ve kaynak kullanımı yönünde oldukça olumlu bir gelişme.

Bu gelişmenin bir çıktısı olarak da, ASP.NET vNext ile artık sadece gerekli olan CLR bileşenlerini sunuculara deploy etmeniz mümkün olabilecek. Farklı versiyondaki bileşenleri,farklı uygulamalarda kullanabiliyor olacaksınız. Yani bir web uygulamanız MVC.v1.dll’ini kullanırken, diğer uygulamanız MVC.v2.dll’ini kullanabilecek.(MVC.vX örnek olarak uydurduğum CLR bileşeni :P) Ve bu bileşenler NuGet paketleri ile yönetilebilecek.

Bu noktada “Dependency Injection” kavramının ASP.NET vNext ile beraber built-in olarak geldiğini de belirtmekte fayda var. Kendi seçeceğiniz IoC ile bağımlılıkları yönetebiliyor olacaksınız.

MVC, Web API, ve Web Pages gibi kavramlar tek bir çatı altında, MVC6 adında bir araya geliyor. Bu ne demek? MVC Controller’ları ve Web API’nin yapabildiği ortak şeyler artık tek bir yapı ile ortak olacak. İnternette dolanan bütün tartışmalar bitecek yani (:
Ortak bir routing yapısı, ortak bir filter yapısı falan gibi…Ve bu yeni çatının System.Web’e olan bağlılığı gibi bir durumu da yok. Bu noktada HttpContext’in memory’deki obje yapısının değiştiğini ve büyük ölçüde küçüldüğünün de altını çizebilirim.

ASP.NET vNext ile artık uygulamaları, IIS dışında, kendi geliştireceğimiz process’lerde de host edebilecek konuma geleceğiz. Bu da lightweight uygulamalar için komple IIS kaynaklarını kullanmak zorluluğunu kısmen de olsa ortadan kaldıracak.

Bir güzel ve değişik yenilik ise, ASP.NET vNext ile compile edilmiş bir *.dll zorunluluğunun kalkması. Rosyln sayesinde(compiler-as-service) runtime sırasında compile işlemi gerçekleşebilecek. Yani kodu değiştirip, sadece browser’de refresh yapmanız değişikliği görmenizi sağlayacak…

Ve son olarak bütün bu ASP.NET vNext’in open-source ve platform bağımsız(Linux, Mac OS X) olacağını söyleyerek heyecanımı sizle paylaşmayı bitirebilirim sanırım.

İlerleyen zamanlarda daha fazla ayrıntı, oynayacak, kurcalayacak daha fazla şey çıkacaktır. Onları da zaman buldukça ve tabi heyecanımı korudukça paylaşmaya çalışacağım.

Daha fazla ayrıntıyı http://www.asp.net/vnext adresinde bulabilir ve gelişmeleri oradan takip edebilirsiniz. https://github.com/aspnet/home adresinden GitHub’a ulaşabilir, kendiniz de kurcalayabilirsiniz.

Ayrıca örnek olarak http://www.asp.net/vnext/overview/aspnet-vnext/walkthrough-mvc-music-store adresindeki örnek uygulamaya bakmanızı tavsiye ederim.

Şimdilik bu kadar…

Nedir-TVNedirTv‘nin her yıl düzenlenen etkinliği, bu sene 8.si ile 1 Mart 2014 Cumartesi günü Bahçeşehir Üniversitesi’nin Beşiktaş kampüsünde. Her zamanki gibi çeşitli konularda, oldukça keyifli sunumlar sizleri bekliyor olacak.   Burak Selim Şenyurt, Ercan Bozkurt, Muhammed Cuma Tahiroğlu
ve Nezih Tınas’ın sunumlarının olacağı bu etkinliğe bu adresten ücretsiz bir şekilde üye olarak katılımınızı belirtebilirsiniz. Etkinliğin programı aşağıdaki gibi;

 

10:00 Gizli Tehlike: Anti-Patterns
11:10 Yazılım Geliştirmede Sadelik (Lean Software Development)
12:20 Bilişim Sektöründeki Saçma Kariyer Planları
14:00 Yazılımcılar İçin Kişisel Gelişim ve Zaman Yönetim Taktikleri
15:10 Yazılımcı Perspektifinden NoSQL

 

Seattle

/ Leave a comment / ~ 4 dakikada okuyabilirsiniz.

Geçen hafta Seattle’a gitme fırsatı yakaladım. Amerika’ya da ilk defa gidiyor olduğumdan benim için oldukça heyecanlı ve zevkli bir zaman dilimi oldu. Müzikle az çok ilgilenenler grunge’ın çıkış noktasının Seattle olduğunu ve Nirvana, Pearl Jam, Alice In Chains, Soundgarden, Melvins gibi grupların buradan çıktığını bilir. IT sektörü ile haşır neşir olanlar da, Microsoft, Amazon gibi şirketlerin merkezlerinin Seattle’da olduğunu duymuştur. Bu iki konuda hayatımda önemli bir nokta olduğu için, benim için heyecanlı bir seyahetti…Neyse…

Space NeedleABD’de başka bir yere gitmediğim için çok bir karşılaştırma yapamacağım oralar ile. Ancak İstanbul’a göre oldukça küçük, huzurlu ve rahat bir şehir…Ya da bölge…Ya da ne zıkkımsa işte… Belki biraz Ankara… 2 milyon ile ikisinden de küçük, o yüzden çok da mantıklı bir karşılaştırma yapmadım sanırım. Asıl olay huzurlu ve rahat bir yer olması işte.

Amerika’nın en kuzeyinde, Kanada sınırında olması biraz soğuk ve genel olarak yağmurlu bir havaya sahip olmasında büyük etken olsa da, umulduğu gibi çok fazla kar yağan bir yer değil(miş). Ben kışın ortasında kar ile karşılanırım diye umuyordum ki, güneşli bir hava ile karşılaştım. Eeee daha demin soğuk demiştin, şimdi güneş diyorsun diyenlere, Seattle’da güneşin sadece aydınlatma amaçlı olduğunu söyleyebilirim. Bunun dışında sıcaklık konusunda pek bir etkisi yok…Ciddi ciddi soğuk yani…Ama bir Ankara’lı olarak, yemişim Seattle’ın soğunu…

Space NeedleSeattle, çok fazla turistlik bir yer değil. Şunu yapmaya gidim, şunu görmeye gidim diyecek pek bir şey yok…Haa biraz kuzeyinde kayak açısından extreem sporlar yapabileceğiniz dağlar varmış ama bilemiyorum. Bunun dışında Space Needle ve EMP Museum, Seattle’ın en büyük turist atraksiyon yerleri…Space Needle, Ankara’yı ve Atakule’yi bilenler için çok yeni bir şey değil. Tıpkısının aynısının, “Made In USA” etiketli olanı. Biraz daha büyük, biraz daha uzun…Komple bütün Seattle’ı görebiliyorsunuz. Turist atraksiyonu olması adına gidilip, bol bol fotoğraf çekilebilir. Tepede ayrıca bir restoran var, döne döne yemek yiyebiliyorsunuz. Gece, ışıklı bir Seattle manzarası ile değişik bir tecrübe olabilir…

Space Needle’ın hemen aşağısında EMP Museum var. Bence Seatle’da mutlaka gidilmesi gereken yegane yer…Gerçi genel olarak sergileri nasıl oluyor bilemiyorum ama benim bulunduğum zaman diliminde Nirvana, Jimi Hendrix ile oldukça ayrıntılı bölümler, Icons of Science Fiction adında bilim kurgu dünyasının televizyon ve sinemadaki örneklerinden örnekler, korku sinemasına ayrıl bir bölüm, Block By Block adında legodan yapılmış gökdelenlerin sergilendiği bir bölüm ve Martin Schoeller’in Close Up fotoğraf sergisi vardı. Lego ve Martin Schoeller dışındakiler sanırım sürekli sergi.

EMP

Müzede ayrıca oldukça geniş bir mini-stüdyo(lar) var. Bunlara arkadaşlarınız ile girip, jam session yapabiliyorsunuz. Gitardan,davula oldukça eğlenceli zaman geçirebileceğiniz bir şekilde yapmışlar. Oldukça uzun bir zaman geçirdim diyebilirim müzede. Bir an bile sıkılmadım…Bu arada müze, Microsoft kurucularından Paul Allen’nın ön ayak olup, kurduğu bir müze. Bu notu da eklemeden geçmiyim…Paul Allen, Seattle’ın sanırım fahri sahibi bu arada…

Space Needle’dan şehir merkezine(downtown) bölgesine 30-35 dakikada yürüyerek gidebiliyorsunuz. Tavsiye ederim. Sokak dolaşmasını seven biri olarak genelde tercih ettiğim bir ulaşım yöntemi olan tabanway’ı Seattle’da oldukça kullandım diyebilirim. (:

IMG_4401

Downtown bölgesinde Pike Place Market, Seattle’ın en orjinal ve gezmesi keyifli yerlerinden biri. Adından anlaşılacağı üzere bizdeki pazarlar gibi bir yer. Sadece kapalı bir mekan. Yemek yiyebileceğiniz yerlerden, meyve-sebze satışı yapan yerlere, eski eşya satan dükkanlardan, el işi ıvır zıvır satan stantlara kadar oldukça çeşit sizi bekliyor. Dükkanlara girip kafayı yemek mümkün…

Seattle, Starbucks’ın ilk açıldığı yer. Kahve sevenler için ilk Starbucks’ı da Pike Place Market’in karşısında bulabilirsiniz. İçini aynen korumuşlar. Ben çok ilgilenmedim ama önünde ve içinde ciddi bir kalabalık vardı. Downtown’dan şehrin güneyine doğru Pioneer Square’e doğru yürüyüp, biraz daha sokak gezip belki değişik bir şeylere rastlamanız mümkün. Pioneer Square, Seattle’ın eski bir merkezi olduğundan gezerken binalar falan biraz daha göze hoş geliyor. Ama Downtown’un hareketi ve kalabalıklığı yok.

IMG_4411Seattle’ın çevresi bilimum park ve göllerden oluşmakta, dolayısıyla gezecek oldukça yer var. Ama tabi kışın soğukta pek mantıklı olmuyor. Seattle ve çevresi aynı zamanda bir çok teknoloji firmasının merkezini bünyesinde barındırıyor. Bellevue ve Redmond’da ki Microsoft ofisleri ve kampüsü sanırım bu açıdan Seattle ile en özdeşmiş yer. Amazon’nun da merkezi, Cisco,Google, Facebook, Blackberry gibi firmalarında ciddi anlamda önem verdikleri ofisleri burada. IT sektörü içerisinde, yazılım ile uğraşıyorsanız özellikle Redmond’a gitmenizi tavsiye ederim. Ayrıca Boeing’in de merkezi ve fabrikası burada, hatta kendi müzesi bile var. Ama ne yazık ki gitme şansım olamadı ):

9 günlük Seattle seyahatimin en akılda kalıcı yanı sanırım SuperBowl’du…Amerikan futbolunun bu en önemli finaline, Seattle’ın SeaHawks takımı kalmış. Benim hiç alakam olmasa da, bir hafta boyunca Seattle’da ki tek olay bu maça hazırlıktı. Bütün restoran ve cafelerde bu maça hazırlık, tüm Seattle’da yaşayanların üstünde formalar, arabalarda bayraklar herkes bu maçı bekliyordu. Maçı izleme ve sonrasına katılma şansım ne yazık ki olamadı ama bir haftalık hazırlığın, SeaHawks galibiyeti ile doruk noktasına ulaştığı haberlerini aldım. Go SeaHawks…Seneye de katıl da, belki yine denk gelirim 😀

IMG_4442 IMG_4444 IMG_4347

2014’e kıtalar arası gezi olayı ile başladım…Bakalım bu sene bizi nereye götürecek…2014’ün ilk yazısı oldu…Bayadır ihmal etmişim bu arada onu fark ettim…Ayıp bana…

TypeScript’de interface kavramı,  Javascript’deki, genişletilebilirliği sağlayan en esnek yapı. Normalde Javascript’de interface kavramı bildiğiniz üzere yok. Dolayısıyla type-safe bir yapı oluşturmak, doğası gereği zor. TypeScript’de ki interface’ler temel olarak bu zorluğu ortadan kaldırmak için geliştirilmiş diyebiliriz.

TypeScript’deki interface, temelinde bir tip tanımından başka birşey değildir. class ve function‘lar nesnelerin davranışlarını tanımlarken, interface‘ler nesnelerin tiplerini tanımlar şeklinde düşünebiliriz. Javascript’de interface kavramı olmadığı için TypeScript’de bir interface tanımladığınız ve compile ettiğiniz zaman, onun bir Javascript kodu üretmediğini görürsünüz. Bu noktada interface’lerin compile zamanında tipleri tanımladığını ve geliştirme aşamasında da kolaylık sağladığını belirtmek isterim.

Aşağıda TypeScript’de nasıl bir interface tanımlarız bunu basitçe görebilirsiniz. IShape diye adlandırdığımız interface’imizin getPerimeter() diye,-daha sonra içeriğini tanımlayacağımız, bir fonksiyonu var.

interface IShape {
getPerimeter(): number;
}

Şimdi bu interface’den yaratacağımız Square sınıfımıza bir bakalım. “implements” anahtar kelimesi ile sınıfımızın IShape interface’inden oluşacağını belirtiyoruz. Aslında burada Square sınıfımızın tipi IShape arayüzü ile tanımlı olacaktır da demiş oluyoruz.

class Square implements IShape {

}

Bu noktada Visual Studio’nun verdiği bir uyarının altını çizmek isterim. Yukarıdaki gibi bir ifadede, Visual Studio, Square sınıfının getPerimeter() fonkisyonunun implement edilmediğini söyleyerek hata verecektir. TypeScript’deki interface kavramının en güzel yanı aslında bu. Javascript’de tiplerin genişletilebilirliğini yönetmek zor olduğundan, çok fazla hata yapmak mümkün olabiliyordu. Ancak TypeScript’in bu özelliği ile genişletilebilirlik özelliği tamamen bizim kontrolümüze geçmiş oluyor.

TypeScript

Yavaştan Square sınıfımızı biraz daha anlamlı hale getirmeye başlıyalım ve interface’mizin getPerimeter() fonkisyonunu kare için tanımlayalım.

class Square implements IShape {
    private length: number;
    constructor(l: number)
    {
        length = l;
    }
    getPerimeter(): number {
        return length * 4;
    }
   
}

Compile ettiğimiz zaman, aşağıdaki gibi bir javascript kodunu elde edeceğiz. Dikkat ederseniz, IShape’e dair herhangi bir tanım, herhangi bir ifade yok.

var Square = (function () {
    function Square(l) {
        length = l;
    }
    Square.prototype.getPerimeter = function () {
        return length * 4;
    };
    return Square;
})();

window.onload = function () {
    var s = new Square(4);
    console.log(s.getPerimeter());
};

Yukarıda interface’ler TypeScript’de genişletilebilirliği sağlayan en önemli kavram demiştim. Peki nasıl yapıyoruz bunu?

Javascript, type-safe bir dil olmadığı için, execution anında TypeScript sayesinde tip ekleyip, tipleri genişletebiliriz. Mesela var olan Date tipini genişletip yeni bir metod ekleyelim. Bu metod, bulunduğumuz günün adını versin bize. Bunun için mevcut Date tipini, aynı isimle bir interface yaratıp getTodayName() metodu ile genişletiyoruz.

interface Date {
    getTodayName(): string;
}

Bu metodun içeriğini daha sonra, Date tipinin prototpye’ları arasında implement ediyoruz. Javascript ile haşır neşir olanların oldukça tanıdık olduğu bir ifade olacaktır.

Date.prototype.getTodayName = function () {

    var d = new Date();
    var weekday = new Array(7);
    weekday[0] = "Pazar";
    weekday[1] = "Pazartesi";
    weekday[2] = "Salı";
    weekday[3] = "Çarşamba";
    weekday[4] = "Perşembe";
    weekday[5] = "Cuma";
    weekday[6] = "Cumartesi";

    var name = weekday[d.getDay()];
    return name;
}

Daha sonra Date tipinde bir değişken tanımladığımız zaman onun getTodayName() diye bizim yeni eklediğimiz fonksiyona da sahip olduğunu göreceğiz.


window.onload = () => {

    var d: Date = new Date();
    console.log(d.getTodayName());

};

TypeScript’de interface kavramı basitçe böyle. OOP yaklaşımlarını Javascript tarafında uygulayabilmek için güzel bir yapı. Artık yapabilecekleriniz sizin elinizde…

Kodcu ya da yazılımcı…Fark eder mi? Pek farkında olunmadan, yapılan farklı işlerden ve projelerden dolayı, yazılım geliştirenlere söylenen bir tanım ikiside aslında…Yapılan işi, -yazılım geliştirme, hangisi daha iyi anlatıyor tartışılır. Tartışmak çok da anlamlı mı onu da bilemiyorum. Ama çevremdeki yazılım geliştiren kişileri ve yapılan işleri düşündüğümde kendimce bir şey saçmaladım. Paylaşmazsam olmaz dedim. 😀

Kodcu da yazılımcı da, ikiside yazılım geliştiren kişilerdir, bir kere bunda bir anlaşalım. Ama yazılım geliştirme yöntemleri ve tercihleri farklı kişilerdir. Ve ikisi de bir yazılım geliştirme evresinde gerekli ve önemli rol oynayan kişilerdir. Kodcu, yazılımcıya göre daha çözüm odaklı olabilir. Problemin biran önce çözülmesi kodcu, problemin kaliteli bir şekilde çözülmesi de yazılımcı için önceliklidir. Kodcu, yazılım geliştirirken, hedefinde neyin olduğuna daha iyi bir şekilde odaklanır. Yazılımcı, hedefe giderken, yolda tökezlememek için tedbirli olur. Yazılımcı, başından itibaren geliştirilen yazılımın yaşam döngüsünün bilincinde olur, ona göre geliştirir. Kodcu, yazılımın doğmasına odaklanır. Yazılımcı, yazılım mühendisliğinin ya da literatürün söylediği şeyleri dikkate alır, kodcu bu konulara çok bulaşmadan daha özgür olabilir. Yazılımcı, güvenlik,erişebilirlik,modülerlik gibi çeşitli kalite özelliklerine kafa yorarken, kodcu çözüm sağlayan daha kolay evet diyebilir.

Kodcu vs. yazılımcıKodcu biraz daha özgür düşünebildiği için, aklındaki fikirleri daha çabuk gerçekleştirebilir. Çözüm odaklı düşündüğünden, kullanacağı teknoloji üzerinde fazla komplike arayışlara girmez, çözümüne uygun, hızlı geliştirme yapabileceği teknolojiyi seçer. Startup’lar bu açıdan kodcular için uygun olabilir. Kodcular teknolojiyi daha hızlı tüketirler. Çözümü hızlı gerçekleştirebilmek için bu hafta Ruby ile geliştirme yaparken, haftaya PHP’ye geçebilirler. Yazılımcılar, bu geçişleri çok hızlı yapamazlar. Daha fazla parametreyi değerlendirme aşamasında ele alırlar. Kodcular, yazılımın kullanım anına göre yaklaşımlarda bulunurken, yazılımcılar, yazılımın uzun yaşaması için geliştirme yaparlar.

Kodcu, anlık çözüm geliştirirken, yazılımcılar büyük çerceve içindeki resimi görüp uzun soluklu yazılımları hedefler. Kodcu, yazılımcıya göre, herşeyin yapılabileceğine daha çok inanır. Yazılımcı tecrübeleri doğrultusunda, problemlere daha şüpheyle yaklaşır.

Kodcu, her sektörde rahatken, yazılımcı kurumsal ölçekli orta ve büyük sektörlerde rahattır. Kodcu, problemlere geliştirdiği yazılım penceresinden bakarken, yazılımcı bütün sistem için bakar. Kodcunun geliştirdiği yazılımlar, oluşturduğu çözümler yazılımcının yaklaşımları ile olgunlaşır.

Başta söylediğim gibi yazılımcı da kodcu da, yazılım geliştirme evresinde beraber olması gereken ve önemli rol oynayan kişiler. Yukarıda bahsettiğim farklılıklara çok katılmıyor olabilirsiniz, gerçekten böyle olduğu için yazdığım şeyler de değil aslında. Ama farklı iş ihtiyaçları ve sektörlerde, yazılım geliştirirken, geliştirdiğimiz çözümleri, neden geliştirdiğimizi, geliştirirken nelere dikkat etmemiz gerektiğini sorgulamamızı sağlayan iki kavram olarak düşünüyorum. Kısacası her yazılım geliştiren kişi bazen kodcu, bazen de yazılımcı olmak durumundadır diyerekten bitiriyorum…Kalın sağlıcakla…