• Jul
  • 02
  • 2014

jsist, 27-28 Eylül 2014′de İstanbul’da…

Tags: | View: 188 | Comments:

jİstanbul ve Koç Üniversitesi, 27-28 Eylül 2014 tarihinde gerçekleşecek, 2 günlük bir javascript etkinliği düzenliyor. jsist olarak adlandırılan etkinlikte, javascript ve javascript ile ilgili son teknolojiler, konusunda tecrübeli kişiler tarafından anlatılacak. Önümüzdeki günlerde içeriği de paylaşılacak olan etkinlik ile ilgili ayrıntıları ve katılım bilgilerini http://jsist.org/ adresinden takip edebilirsiniz. Elinizi çabuk tutun derim. Etkinlik katılım ücreti şu sıralar indirimde.

speakers

  • Jun
  • 22
  • 2014

IT sektöründe çalışan insanların en büyük problemi…

Tags: | View: 316 | Comments:

IT sektöründe çalışan insanların en büyük problemlerinden biri de, yaptığı işi, sektör ile alakası olmayan ya da teknolojiyi çok takip etmeyen ya da kullanmayan insanlara, yaptığı işi tarif etmek olsa gerek… En basitinden, hangimizin anneannesi,babaannesi ve dedesi yaptığımız işten haberdar… Ne yapıyorum ben diye sorsam, stress mtress yaratıp, sıkıntıya sokarım diye korkuyorum…Yaşlı insanlar sonuçta… (:

Bindiğiniz takside muhabbet açmaya çalışan şöförün, “Ne iş yapıyorsun? Bilgisayarcısın demek…Şimdi tam olarak ne oluyor yani?” şeklindeki ölümcül soruları bir yana,  eşin, dostun ya da aile bireylerinin “Yaa şimdi bu bilgisayarların en iyisi hangisi? En iyi virüs programı ne? Bizim ufaklık oyun oynamasın, nasıl engelleriz?” gibi soruları bir yana olsun, bir şekilde cevap vermemiz beklenen sorular her an, her yerde karşınıza çıkıyordur. Şahsen benim çok çıkıyor… Hatta kimi zaman, öyle zor(?) sorular geliyor ki ne diyeceğimi şaşırıyorum. Bu kadar mı kompleks ya da bu kadar mı bir şey ifade etmeyen bir mesleğim var diye düşünmüyor değilim…

software_developer

Donanım tarafıyla ilgili olsam, biraz daha kolay olacaktı sanırım bazı şeyler… En azından somut olarak bir çıktısı var…Ama yazılıma yoğunlaşınca, uzaya roket çıkartıyormuşum izlenimi, “en ucuz ve en hızlı bilgisayar şimdi hangisi” sorusuna verdiğim cevabın tatminsizliği ve sonrasındaki “yaaa sen de, hiç bir şey bilmiyorsun” tepkisiyle alt üst oluyor…Üzülüyorum…:D

Yazılım yapıyorum diyince,  yetmeyeceğini bildiğimden “Bilgisayarda kullandığınız o programlar var ya, işte onları bilgisayarın anlayacağı şekilde kodlar ile yazıyorum” diye efendi efendi anlatmaya çalışsam da, “Kağıda mı yazıyorsunuz peki?” ya da “Benim anlamadığım şeyi, bilgisayar nasıl anlıyor?” şeklinde tepkiler gelince, bazen isyan da etmiyor değilim… Teknoloji hayatımıza girdikçe, insanoğlunun da merak ve öğrenme isteği artıyor doğal olarak; hak veriyor ve efendiliğimden dolayı da söylemek istediklerimi söyleyemiyorum…

Dışardan bir insan gözü ile baktığımda da, bir programın arkasında atılan taklaların, algoritmaların, tasarım kalıplarının, “yok efendim burada “IoC” implementasyonu yaptım ki, şöyle olsun”, “burada DDD presinplerini kullandım”, “servis alt yapısı çok süper ve stabil oldu, aferim bana” gibi konuların bir hiç olduğunu görüyorum…Daha da üzülüyorum…

Neyse, yine efendiliğimi koruyup burada bitiriyorum şimdilik… :D

  • Jun
  • 03
  • 2014

Visual Studio “14″ CTP’si yayınlandı…

Tags: , , , , | View: 272 | Comments:

Geçtiğimiz aylarda, Microsoft, geliştiriciler için bir çok yeniliği ve yeni ürünü sundu. Bunlardan sanırım en çok merak uyandıran ASP.NET vNext oldu desem çok yanılmış olmam.

Bugün itibari ile bu yenilikleri kapsayan ve daha bir çok yenilik ile tanışmamızı sağlayacak olan Visual Studio’nun yeni, evet yanlış okumadınız, “yeni” versiyonun ilk CTP’sini yayınladı. Visual Studio “14″ adıyla yayınlanan bu CTP’yi bu adresten indirip kurabilirsiniz.

Bu CTP versiyonunda, ASP.NET vNext ile duyurulan yenilikleri geliştirebileceğiniz ortama, Rosyln’nin yeniliklerine sahip olmuş olacaksınız. İlgileniyorsanız mutlaka kurun ve kurcalayın derim. Ancak Microsoft’un da altını çizdiği bir noktayı, ben de belirtim; mutlaka ayrı bir bilgisayara ya da VM’e ve önceki Visual Studio versiyonlarının olmadığı bir şekilde kurun.

  • May
  • 29
  • 2014

Deadline…Proje teslim tarihi değil, ruhu teslim tarihi…

Tags: , | View: 322 | Comments:

Son zamanlarda çevremde konusu geçtiği için “fazla mesai” ve “sinir-stres” ile ilgili bir şeyler karalamak istedim. Bir nevi sesli düşünme belki…Neyse…Esnek çalışma saatleri altında, IT sektöründe bir şekilde “fazla mesai” kavramı kendine yer bulmuş; bazen güzel sonuçlara vesile olsa da, çoğu zaman çok can yakan bir kavram aslında. Zamanında bu ikisini de çok yaşadığım diyebilirim. “Fazla mesai”, bazı problemlerin “sinir-stres” kıvamının çok yüksek olması ile çirkinleşen bir olay aslında…Yoksa yapılan işin kalitesini arttırma isteği ile güzel sonuçları da oluyor. Ama ne yazık ki can yakan kısmı daha çok…

Kimse normal çalışma saatleri dışında, bir şirkette fazladan çalışmayı tercih etmez. Sektöre yeni girmiş ve bilgiye aç insanlar da olsa bir süre sonra, herkes kendi zamanını yönetmeyi ve korumayı ister. Bu mesleğinizi ve yaptığınız işi çok sevseniz bile geçerli olan bir durum. Bu noktada; eee madem tercih edilen bir şey değil, peki neden “fazla mesai” yapıyoruz sorusu herkesin sorduğu bir sorudur sanırım. Bu soruya, yapılan işin yönetimi ve yapılma şekilleri başta olmak üzere herkesin söyleyecek, şikayet edecek bir şeyi mutlaka vardır. Üst düzey yöneticeden, geliştiriciye, sistemciden, proje yöneticisine kadar her IT çalışanının, çok da doğru tespitleri mutlaka vardır. Kısaca, şikayet etmekte herkes haklı…Ama peki çözüm? Tam bir bilinmez…

Aslında bütün olay müşteri-proje ilişkisinin, tüm paydaşlar tarafından düzgün yönetilmemesinden kaynaklanıyor.“Deadline” kavramı, proje teslim tarihi değil de, ruhu teslim tarihi olarak çirkin bir hal alıyor. İlk zamanlarda güllük gülistanlık olan proje, sıkışık bir takvim içerisinde, kalitesiz bir duruma düşüyor. “Fazla mesai”ler, bug’lar, bitmeyen geceler de ek olarak yanında geliyor…

Bir geliştiricinin “Bu 2 hafta da olmaz, 3 hafta da biter, 2 hafta da isteniyorsa, şu eksik olur.” gibi yorumları yönetici/müdür tarafından dikkate alınmazsa, aynı şekilde yönetici/müdür bunu düzgün bir şekilde müşteriye/üst yönetime anlatmazsa, alt pozisyondaki paydaşlar öncelikli olmak koşulu ile herkes bir süre sonra olumsuz etkilenir, -ki etkileniyor da. Kimisine “fazla mesai”, kimisine “sinir-stres” şeklinde yansıyor ne yazık ki… Bu süreçler içinde, bir de araya kişisel çıkarlar ve egolar girdi mi, offff eğlenceye gel… Sözde, her şey projeyi zamanında teslim etmek için… Ama pratikte gelinen durum pek iç açıcı olmuyor.

Devam…

  • May
  • 22
  • 2014

Nedir bu ASP.NET vNext?

Tags: , | View: 622 | Comments:

Ç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…

  • Feb
  • 16
  • 2014

NedirTV, 8. yıl etkinliği 1 Mart’da…

Tags: | View: 495 | Comments:

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

 

  • Feb
  • 10
  • 2014

Seattle

Tags: | View: 536 | Comments:

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 :D

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…

  • Nov
  • 25
  • 2013

TypeScript ve “interface”…

Tags: , , | View: 694 | Comments:

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…

  • Nov
  • 13
  • 2013

“Kodcu” vs. “Yazılımcı”

Tags: , | View: 1,069 | Comments:

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. :D

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…

  • Nov
  • 01
  • 2013

TypeScript’de fonksiyonları nasıl “overload” ederiz?

Tags: , , | View: 583 | Comments:

TypeScript’de yazdığımız metodları, alışmış olduğumuz şekilde ne yazık ki overload edemiyoruz. Ama tabi ki bu, TypeScript, “overloading”‘i desteklemiyor demek değil. Hatta TypeScript’in spesifikasyonunda overload desteğinin olduğunu görebilirsiniz.

Aşağıdaki gibi, C#’dan benzer bir yaklaşım ile yapabileceğimizi düşünsekte, aşağıdaki kodu derlemeye çalıştığımızda hata alıyor olacağız.

class MainClass {
    MethodA(): void {
       
    }
    MethodA(s: string): void {
        
    }

    MethodA(s: number, p: string) {

    }
}

window.onload = () => {

    var s: MainClass = new MainClass();
    s.MethodA('TEST');


};

Alacağımız hata “Duplicate identifier ‘MethodA’” şeklinde bir şey olacaktır. Bunun sebebi Javascript tarafında, fonkisyonların tek bir tanımının olması gerekliliği. Peki nasıl yapacağız?

Overload yapacağımız metodların, deklarasyonlarını ayrıca belirtmemiz gerekiyor. Daha sonra bu deklerasyonlara uyumlu, tek bir metod ile metoda gelen parametrelerin tiplerini kontrol ederek overload özelliklerini tanımlayabiliriz.

class MainClass {
    MethodA(): void; //1.MethodA
    MethodA(s: string): void;//2.MethodA
    MethodA(s: number, p: string): void;//3.MethodA

    MethodA(s?:any,p2?:string): void {

        if (s && typeof s == "string")
        {
            alert('2.MethodA');
        }
        else if ((s && typeof s == "number") && (p2 && typeof p2 == "string"))
        {
            alert('3.MethodA');
        }
        else if(s===undefined && p2 ===undefined)
        {
            alert('1.MethodA');
        }

    }
   
}

window.onload = () => {

    var s: MainClass = new MainClass();
    s.MethodA();
    s.MethodA('Hello');
    s.MethodA(1,'Hello');

};

Burada önemli olan methodların içini tanımladığımız en son MethodA()’nın parametreleri ve içeriği. Dikkat ederseniz parametrelerin yanında “?” var. Bu o parametrenin olmayabileceğini de söylüyor. 2 parametre için de “?”ni koyuyor olmamız, boş parametre ile çağırabileceğimiz ilk MethodA deklarasyonunu sağlıyor. İlk parametrenin “any” keyword’ü ile olması da, o parametrenin herhangi bir tipde olabileceğini belirtiyor.

Bu sayede TypeScript’de metodlarımızı overload edebiliyor. Çok alışa gelmiş bir yöntem değil ama mevcut Javascript alt yapısından dolayı bu şekilde yapabiliyoruz ne yazık ki.

Kodumuzun derlendiğinde ortaya çıkan Javascript’de aşağıdaki gibi olacaktır.
Devam…