Arda Çetinkaya Yazılım ve arada kendim ile ilgili saçmaladıklarım…
Tanımlı bir problemi ya da belirli bir ihtiyacı çözmek için başladığımız yazılım projelerinin büyük bir çamur topuna dönüşmesi oldukça kolay. Çözmeye çalıştığımız problemin karmaşıklığına göre ve bunu çözmeyi vaat ettiğimiz zamana göre işler daha da çirkinleşecektir. Açıkcası bundan kaçmak çok olası değil ama çamur topunun büyümemesi için yapılacakların farkında olup, önlemleri alırsak çamur topunun altında ezilmeyiz.
bigballofmud

(Big Ball of Mud)

“Big Ball of Mud”, belli bir çerçeveye göre tasarlanmamış, iş ihtiyaçlarının baskısı altında ezilmiş, sürekli yamalar ile gelişmiş, sürdürebilirliği maliyetli, kod kalitesinin düşük olduğu ve kötü kokan spagetti kodların olduğu yazılımları tanımlamak için uzun zaman önce yazılım geliştirme literatüründe yerini almış bir kavram. Ne yazık ki kendimizi bu iğrenç çamur topunun içinde bulmak oldukça kolay. İçine düşmenin kötü olduğu gibi, bu çamur topunun oluşmasına katkı sağlamak da ayrı bir kötü durum.

Üzgünüm ama kod yazmaya başladığımız andan itibaren bu büyük çamur topunun oluşması da başlıyor. Bunun farkında olursak, bu topun büyümemesi için farkındalığımız daha yüksek olacaktır. Önemli olan bu çamur yığınının büyümemesi, yönetilebilecek derecede kontrol altında olması. Günümüzde değişimlerin çok hızlı oluyor olması bu çamur topundan kaçınamamamızın en büyük sebebi. Tabi ki insan faktörü de bu sebebin birinci katalizörü.

Yazılım projeleri sonuçta kendi kendilerine ortaya çıkan şeyler değil. Bizler yazıyoruz, geliştiriyoruz. Çamur topunu da biz oluşturuyoruz. Bunu oluştururken de, bir çoğunuza tanıdık gelen belli söylemlerin arkasına sığınıyoruz.

Müşterinin ne istediği net değildi…

Çok sevdiğimiz bir söylem. “Müşterinin ne istediği net değildi”… Bizden istenen ihtiyaç net olmadığı zaman, ister istemez yazdığımız kod da çok net olmaz. Net olmadığını ilk başta fark etmediğimiz için(!!!) ve belli varsayımlara göre ihtiyaçları geliştirdiğimizde ortaya çıkan kod, karmaşıklığın ilk hali olacaktır. Müşterinin istediği bizim tarafımızda net olmadığı sürece, her yeni istek çamur topunu büyütecektir. Kötü bir haberim var; ne yazık ki müşterilerinizin ne istediği %70 net olmayacak… Dolayısıyla müşterinin ne istediğini net olarak anlamaya çalışmak için çaba sarf etmemiz lazım. Değişimlerin sürekli olduğu bir çağda yaşadığımız için de, bu değişimleri yönetebilecek bir yaklaşım içerisinde olmamız gerekiyor. Yazdığımız kodların kolay değiştirilebilir bir alt yapıya sahip olması, kodun içerisindeki bağımlılıkların yönetilebilir olması kod yazarken dikkat edebileceğimiz şeyler olabilir.

dilber-on-customer-requirements

(Big Ball of Mud)

Devam

Son yılların popüler konularından Microservices, beraberinde yeni problemleri ve ihtiyaçları da geliştirme hayatımıza sokuyor. Bu senenin sıcak kavramlarından “Serverless” da bunların başında geliyor. Dağıtık sistemlerin, günümüz yazılım alt yapılarının vaz geçilmez sistemler olması “Serverless” kavramını daha da ilginç hale getiriyor. “Nasıl yani, uygulamalar sunucularda çalışmıyor mu artık?” ya da “Sunuculara gerek yok mu artık?” gibi sorular ne yazık ki ilk aklımızdaki beliren sorular oluyor. Ama tabi ki olay, bu değil.

Açıkcası “Serverless” isminin, -ne yazık ki tüm IT sektörünün isimlendirme konusundaki zaafının en yeni ürünü olarak düşünüyorum. Her türlü karmaşık probleme çözümler üretebiliyor olmamıza rağmen, hala şu isimlendirme olayını çözemiyor olmamız da bizim ayıbımız olsun. Neyse…

There are only two hard things in Computer Science: cache invalidation and naming things.

Phil Karlton

“Serverless” tabi ki, artık sunuculara gerek yok ya da uygulamalar sunucularda çalışmayacak gibi bir yaklaşım değil. Yazılım geliştirme ve yönetme açısından, daha az, sunucu kavramına kafa yormamızı sağlayan bir yaklaşım ya da mimari kalıp diyebiliriz. Ölçeklendirme, yük dağıtımı, sunucu konfigürasyonları, hata yönetimi, deployment ve hatta run-time gibi konuları dert etmeyin temeline dayanıyor aslında.

serverless-architecture“Serverless” için bir başka bakış açısı da, başka sağlayıcılardan alınan servisler ile uygulama mantığını oluşturan ya da destekleyen bir mimari kalıp olması. Yetkilendirme için bir sağlayıcı, e-mail için başka farklı bir sağlayıcı, persistence için başka bir sağlayıcı ile bir logic oluşturmak ve uygulamaları bu şekilde tasarlamak için düşünebileceğimiz bir kalıp olarak da düşünebiliriz. Bu bakış açısında sağlayıcıları basit olarak fonksiyonlar; Functions as a Service(FaaS) olarak düşünmek bazı şeyleri daha iyi anlamamızı sağlayabilir.

Bu iki yaklaşımın da öne çıkan ve önemli olan noktası ölçeklendirmenin önemli olması ve “serverless” çatısı altında otonom bir şekilde yapılması. Ölçeklendirme ve maliyet konuları, dağıtık sistemlerde önemli konular olduğu için bu tarz farklı mimari yaklaşımlar, tasarımlar ve kalıplar gündeme geliyor. Tartışılıyor, geliştirilip uygulanıyor ve zamanla literatürdeki yerini alıyor. “Serverless” ile ilgili daha kapsamlı ve ayrıntılı olarak Martin Fowler’ın sitesindeki yazıyı başlangıç olarak tavsiye ederim.

Peki neden?

Bazı kavramları anlamak için çözdüğü problemlerin farkında olup, problemleri iyi anlamak önemli diye düşünüyorum. “Serverless” kavramını da daha iyi anlamak için problemi önce anlamamız lazım. Geliştirme yaparken, çözmeye çalıştığımız problem logic’i dışında başka şeyleri de düşünmek durumundayız. Çalışacağı sunucu konfigürasyonu, sunucu yetkilendirmesi, oturum yönetimi, yük dağıtımı gibi konular bunlardan sadece bir kaçı. Bir CRM uygulamasının problem domain’i dışında bu tarz konular ile de ilgilenmek, hızlı ve çevik çözüm üretme konusunda günümüzde bir engel artık. Çünkü ne yazık ki hiç birimiz Ninja değiliz ve tüm bu konulara yüksek bir kalitede hakim olamayız. Dolayısıyla bu tarz konuları ya da fonksiyonları başka sağlayıcılardan alabiliriz. Aynı şekilde kendi çözümlerimizi de ihtiyacı olacak sistemlere sunabiliriz. Cloud Computing, servis odaklı mimariler, PaaS ve FaaS gibi konular aslında bunlara çözüm olarak geliştirilen kavramlar. Peki “Serverless” bu noktada nasıl konumlanıyor? Uygulama geliştiren kişiler için yukarda bahsettiğim tüm konular birer maliyet. Sadece maddi anlamda değil tabi ki.

Efor, zaman, yönetim gibi konular da geliştirilen sistemler büyüdükçe artan maliyetler olarak bizlerin karşısına çıkıyor. Verim ve maliyet oranları gündeme geldiğinde “Serverless” yaklaşımı önemli bir konu haline geliyor. “Serverless” yaklaşımında maliyet olabilecek konuları başka sağlayıcılardan alıp, kendi ihtiyaçlarınıza göre ölçeklendirmek mümkün. Bu ölçeklendirmenin de otomatik olarak sağlanması, sadece tüketilen kaynakların maliyet olarak karşımıza çıkması da “Serverless”ın önemli bir avantajı. Uygulamalar açısından, ödeme özelliklerinin kullanılan ya da çalışan fonksiyona kadar indirgenmesi ve bunun maliyet açısından avantaj sağlaması, “Serverless” kavramını daha fazla duymamızın en büyük sebeplerinden biri olacak.

AWS Lambda ve Azure Functions, “Serverless” uygulamalar geliştirebileceğiniz Cloud’daki sistemler. İlginizi çekiyorsa bunlara göz atmanızı tavsiye ederim. Şimdilik bu kadar, bir sonraki yazıda görüşmek üzere.

Agile Turkey Summit

Geçen senelerde oldukça başarılı geçen Agile Turkey Summit, bu sene yine oldukça önemli konuşmacılar ile 6 Ekim 2016 tarihinde IT sektörünü bir araya topluyor. Wyndham Grand Levent‘de gerçekleşecek etkinlik için duyurulan konuşmacılar ile bu sene de etkinlik oldukça cazip.

Bu sene “End to End Agile Mind Shift” ana teması altında 4 farklı alt kategori ile paralel oturumlar yapılacak. “DevOps”, “Agile in a Nutshell”, “The Mind Shift” ve “Software Craftsmanship” konularının işleneceği etkinlik yine çok dolu geçecek. Agile dönüşüm ile ilgileniyorsanız, mutlaka kaçırmamanız gereken bir etkinlik.

Etkinlik ile ilgili son dakika gelişmelerini ve tüm konuşmacıları http://www.summit.agileturkey.org adresinden takip edebilirsiniz. Ayrıca kayıt işlemlerini için de siteden bilgi alabilirsiniz.

speakers

Agile Turkey Summit 2016 Speakers

.NET Core emekleme aşamasını geçtiğimiz aylarda 1.0 RTM versiyonu ile tamamladı. Yürüyor ama sağa sola çarpıyor, şu sıralar biraz daha düzgün yürümeyi öğreniyor diyebiliriz. Açık kaynak olması ve farklı platformlarda, aynı şekilde çalışan bir framework amaçlanması, mevcut .NET Framework kadar olgun bir hale gelmesi için biraz daha bekleyeceğiz demek. Bu gelişme ve olgunlaşma süresince de .NET Core ile ilgili bir çok yeni kavram da geliştirme kütüphanemize girdi, girmeye de devam ediyor.

Şu sıralar .NET Core ile ve ASP.NET Core ile sıkça uğraşmaktayım. Dolayısıyla bir çok yeni şeyi öğreniyor, sindiriyor ve fark ediyorum. Projelerinizi .NET Core alt yapısına çevirmeye başladıysanız büyük bir ihtimal benzer şeyleri yaşıyoruz. Yeni şeyleri fark ederken yaşadığım bir “publish” problemdeninden dolayı .NET Core ile ilgili bir şeylerden bahsetmek istiyorum. Bildiğiniz gibi .NET Core’un, platform bağımsız ve taşınabilir olması amaçlanıyor. Platform bağımsız derken, hem geliştirme hem çalışma ortamlarının Windows, OS X ya da Unix sistemlerde olması, taşınabilir derken de, Windows’da çalışan uygulamanın, aynı dosyalar ile Unix’e taşınıp, orada da sorunsuz çalışabilmesini kastediyorum.

Bu noktada .NET Core uygulamalarının “taşınabilirlik” özelliğinden biraz bahsetmeye çalışacağım. Geliştirdiğiniz uygulamaların bir çok farklı platformda çalışabilmesi için yapacağınız publish ayarlarını ve konfigürasyonları anlamak için, .NET Core da “taşınabilirlik” ne demek biliyor olmamız lazım.

.NET Core’da bu çerçevede iki farklı uygulama tipi var. “Portable”(Taşınabilir) ve “Self-Contained”(Bağımsız) uygulamalar…

“Portable” uygulamalar

“Portable” uygulamalar, çalışacağı makine de .NET Core’un yüklü olmasını gereksinimine sahip uygulamalardır. Geliştirdiğiniz uygulama eğer bu tip bir uygulama ise, .NET Core yüklü herhangi bir sistemde çalışacaktır. Uygulamanızın çalışması için oluşturulan “publish” paketi içerisinde sadece sizin yazdığınız bileşenler ve varsa kullandığınız diğer yardımcı bileşenler, uygulamanızın çalışması için yeterli olacaktır. Bu uygulama tipi, .NET Core uygulamalarının varsayılan tipi. Bu tip uygulamalar geliştirmek için projecj.json dosyanızın içeriği temel olarak aşağıdaki gibi ve dependencies‘deki .NET Core’un “type:platform” özelliğini yeterli olacaktır.

{
    "buildOptions": {
        "emitEntryPoint": true
    },
    "dependencies": {
        "Microsoft.NETCore.App": {
            "version": "1.0.0",
            "type": "platform"
        }
    },
    "frameworks": {
        "netcoreapp1.0": {}
    }
}

Eğer projenizde destekleyici farklı bir bileşen kullanıyorsanız bunlarıda “dependencies” altına eklemeniz gerekecektir tabi ki. Bu uygulamanızı “publish” ettiğinizde; dotnet publish, publish klasöründe sadece ilgili *.dll’leri görürsünüz. Bu *.dll’leri .NET Core yüklü herhangi bir sisteme taşıdığınız takdirde uygulamanız sorunsuz çalışacaktır.

Screen Shot 2016-08-21 at 7.30.23 PM

“Self-Contained” uygulamalar

Bu tip uygulamalar, adından da anlaşılabileceği gibi, bağımsız olup, çalışacağı sistemde .NET Core’un yüklü olmasını gerektirmez. Çünkü “publish” olduğunda tüm gerekli dosyaları içerisinde barındıracaktır. Bu “publish” içeriğinin daha büyük olmasına neden olacaktır tabi ki, ama Docker gibi container platformlarında uygulamanızı host etmek isterseniz tercih edilebilecek bir yaklaşım olabilir.

Bu tip uygulamaların project.json konfigürasyonu biraz daha farklı olacaktır. “Portable” tipdeki uygulamalardan farklı olarak “type:platform” özelliği dosyanın içerisinde olmamalı.

{
    "buildOptions": {
        "emitEntryPoint": true
    },
    "dependencies": {
        "Microsoft.NETCore.App": {
            "version": "1.0.0"
        }
    },
    "frameworks": {
        "netcoreapp1.0": {}
    },
    "runtimes": {
        "win10-x64": {},
        "osx.10.11-x64": {}
    }
}

publish self-containedEk olarak “runtimes” özelliğinde uygulamanın çalışacağın platformlar belirtilmelidir. Bu tanımlamaya göre projemizi publish ettiğimizde ilgili platform için uygulamamızın çalışması için gerekli tüm bileşenler publish klasöründe olacaktır. Böylece çalışacağı sistemde .NET Core yüklü olmak gerekliliği ortadan kalkmış oluyor.

Farklı amaçlar için tercih edebileceğimiz bu uygulama tipleri, .NET Core uygulamalarının çalışması için önemli bir konu. Şimdilik bu kadar, bir sonraki yazıda görüşürüz.

!!!Önemli!!! .NET Core’un ilerleyen versiyonlarında project.json değişeceği için bu yazıdaki örnekler ilerleyen versiyonlarda farklılaşabilir.

“Code Review” yani kod gözden geçirme bir çoğumuzun bildiği, çoğumuzun(?) da uyguladığı bir yazılım geliştirme adımı diye düşünüyorum. Yazdığımız kodun, başkası tarafından gözden geçirilmesi olarak basitçe tanımlayabileceğimiz bir adım. Araştırmalar, hata tespit etme ve kod kalitesini arttırmada birim test, fonksiyonel test gibi test adımlarından daha etkili olduğunu söylüyor. “Daha etkili” kısmını doğrulamak için, nasıl daha etkinli kod gözden geçirme yapılır bunun üstüne de biraz kafa yormak gerekiyor sanırım.

Gözden geçirilecek kod 400-500 satırı geçmesin.

code-reviewGözden geçirilecek küme, ne kadar az olursa “code review” o kadar etkili olur. Gözden geçirmeye başlamadan öncede, gözden geçirilecek kod kümesini belirlenmeli ve net olmalı. 400-500 satırdan fazla kodu gözden geçirme hem yorucu olacaktır, hem de hata ve iyileştirmelerin tespitini zorlaştıracaktır. Samanlıkta iğne aramak gibi aslında…Ne kadar az saman, o kadar kolay iğne bulmak.

 

Gözden geçirme 1 saati geçmemeli

Gözden geçirme oturumu maksimum 1 saatlik farklı bloklar şeklinde olmalı. Uzadığı takdirde gözden geçirilen kod üzerindeki konsantrasyon kaybolur dolayısıyla bulguları bulmak zorlaşır. Zaman sınırı olan senaryolarda birden fazla kişi farklı kod kümeleri üzerinde gözden geçirmeyi yapabilir.

Kodu yazan kişi değil, kod gözden geçirilmeli

Kod gözden geçirecek kişi egosunu bir kenara bırakmalı. Ayrıca kodu yazanı değil, kodu gözden geçirmeli. Bu vesile ile tekrardan “Egosuz programlama için 10 emir…” yazısını hatırlamakta fayda var. Eğer kodu gözden geçiren kişi, kodu yazan kişiye göre çok daha tecrübeli bir kişiyse bunun farkında olup, “Bu kod bloğu saçma sapan olmuş”, “Bu ne biçim kod” yerine “Burada ne yapmak istedin”, “Bu kısım şöyle daha iyi olabilir” şeklinde yapıcı bir gözle kodu gözden geçirmeli.

code-review1

“Code Review” ve “Pair Programming” ayrımı yapılmalı

Kod gözden geçirme sırasında, kodu gözden geçiren kişi, tek başına bu görevi yapmalı. Kodu yazan kişinin o an müdahalesi olayı, “Pair Programming” etkinliğine dönüşecektir. Bulunan bulgular anında düzeltilmeye çalışılacak, hatta egosal durumlardan dolayı stresli bir olaya dönecektir. Kodu gözden geçirilecek kişiden öncesinde bir hazırlık yapması, gerektiğini düşündüğü yerlere açıklamalar yazabilmesinin sağlanması kodu gözden geçirecek kişiye yardımcı olacaktır.

Kontrol listesi olsun

Gözden geçirme sırasında takip edilebilecek bir liste olması, kod gözden geçirmenin etkisini arttıracaktır. Kod standartlarına uygunluk, null kontrolleri, güvenlik kontrolleri, varsa; kullanılan framework/API standartlarına uygunluk gibi bir kontrol listesinin olması işleri kolaylaştıracaktır. Bu kontrol listesine çeşitli puanlama sistemleri ile ölçülebilme özelliği eklemek, gelişimi gözlemlemek için faydalı olacaktır. Ayrıca bu kontrol listesine takılan bulguların düzeltilip düzeltilmediği de takip edilmeli.

Kod gözden geçirme düzenli olmalı

Kod gözden geçirme adımı düzenli olarak ve sürekli olarak yapılmalı. Aksi takdirde hiçbir önemi olmayacaktır. Biz de zaman zaman atlamak durumunda kalıyoruz, bu da bizim ayıbımız olsun. Ama atlandığı zaman, ortaya çıkan “bug”ların çözülmesi için harcanan efor, kod gözden geçirme için yapılacak efordan daha fazla olacaktır. Bu yüzden düzenli olarak yapmak şart.

Mümkünse bir uygulama kullanın

Kullandığınız IDE ya da SCM için mutlaka bir kod gözden geçirme eklentisi vardır, eklenti yoksa bile ayrı uygulamalar kullanabilirsiniz. Kod gözden geçirmenin sistematik hale gelmesini, hem de kolay yapılması için yardımcı olacaktır.

Kod gözden geçirme, hem kodu gözden geçiren, hem de kodu gözden geçirilen için oldukça öğretici bir adım; bunu da hiçbir zaman unutmamak lazım. Genel geliştirme sürecini iyileştirmek ve yazılımın kalitesini arttırmak için yapıldığını, kimseyi yargılamak için yapılmadığının da bilincinde olmak gerekli. Mutlu kodlamalar…

Bugün .NET Framework’ün kuzeni olarak nitelendirebileceğim, farklı platformlarda .NET uygulamaları çalıştırmamızı ve geliştirmemizi sağlayan .NET Core 1.0 versiyonu ile RTM oldu. 2 yılı aşkın süredir açık kaynak olarak geliştirilen .NET Core, farklı platformlarda da .NET uygulamaları geliştirmek isteyenler için Microsoft’un resmi olarak desteklediği bir alt yapı olarak önümüzdeki yıllarda daha da çok gündeme gelecek gibi.

.NET Core ile berebar doğal olarak ASP.NET Core 1.0‘da RTM olmuş oldu. MVC 6, Web API gibi web uygulaması alt yapılarını tek bir çatı altında toplayan ASP.NET Core 1.0 yine platform bağımsız bir alt yapı. .NET Core ile beraber bugün Entity Framework Core 1.0’da yayınlandı. İlerleyen zamanlarda yeni Core ailesi ile ilgili bir çok gelişme daha hızlı bir şekilde gündemimize gelecek gibi. .NET Core alt yapısına port edilen bileşenler de daha hızlı bir şekilde hayatımıza girmeye başlayacak. Bütün bu gelişmeler ile ilgili güncel linkleri sizin için derlemeye çalıştım. Buyrun efenim…

ASP.NET tarafında uzun zamandır büyük bir değişiklik var, Web Forms’un yanına MVC kalıbının gelmesi, .NET Framework’ün yeni versiyonları çıktıkça MVC’nin daha popülerleşmesi, OWIN, WebAPI, SignalR falan derken, ASP.NET kavramı ilk çıktığı zamankinden çok farklı bir hal aldı. .NET Framework’ün açık kaynak olabilmesi için, ondan ortaya çıkan .NET Core ile ASP.NET 5 duyurulmuştu. Bulut için uygun, performans açısından daha gelişmiş ama aynı zamanda alt yapıdaki karmaşıklığın basitleştirildiği, WebAPI, MVC gibi kavramların tekilleştiği ve içerisinde daha bir çok geliştirmeyi barındıran bir alt yapı olarak kısa zamanda çok sık konuşulmaya başlandı. Bu arada .NET Core != .NET Framework yazımı hatırlatmak isterim. Yeni nesil .NET Core alt yapısının ne olduğu öğrenmek ya da hatırlamak isteyenler göz atabilir.

mass_confusionKısa zamanda, acaba geleneksel ASP.NET ölüyor mu, .NET Framework ne olacak gibi karmaşıklıklarda gündemde oldu. Komple yeni bir alt yapının, mevcut versiyon ağacından ASP.NET 5 diye ortaya çıkması bunun en büyük sebebi. Aynı şey Entity Framework 7 ile de olmuştu. EF 6’dan sonra, tüm alt yapıyı değiştirdik, *.edmx alt yapısını kaldırdık diye EF 7’yi duyurunca da kısa bir şaşkınlık olmuştu. Kısaca Microsoft bunu hep yapıyor… Ama hangimiz yapmıyor ki…

Hem bu kafa karmaşıklıklarını yok etmek, hem de gerçekten yeni bir alt yapı olduğu için Microsoft’daki meslektaşlarımız ASP.NET 5’in artık ASP.NET Core 1.0 olduğunu geçen ay duyurdu. Bununla ilgili Scott Hanselman‘nın duyurusundaki ilk giriş cümlesi de aslında olayı özetliyor. “Naming is hard”

Neyse…Bu isim değişikliğinden sonra yeni isimler aşağıdaki gibi oldu;

  • ASP.NET 5 –> ASP.NET Core 1.0.
  • .NET Core –> .NET Core 1.0.
  • Entity Framework 7 –> Entity Framework Core 1.0

Şu an mevcut Github içeriklerinde ya da tüm resmi sayfalarda da bu değişiklikler yayınlanmaya başladı. Bu isimlendirme değişikliğinden dolayı RTM tarihlerinde biraz değişiklik oldu dolayısıyla. Son tarihleri bilemiyoruz ama buradan roadmap’i takip edebilirsiniz.

aspnet-core

Bu isimlendirme değişikliklerinden önce, aslında paralel demek kafa karışıklığını biraz azaltır; dnx tarafında da bir değişiklik oldu. Yine DNX, DNVM,DNU neydi hatırlamak isteyenlere bu konuyla alakalı önceki yazımı tavsiye ederim. Yeni nesil .NET Core uygulamaları ve ASP.NET 5’i geliştirmek ve çalıştırmak için gerekli olan runtime ve bileşenleri(dnx,dnvm…) .NET Core Command-line şeklinde değişti ve tek dotnet komutu ile yeni nesil .NET Core uygulamaları çalıştırılabilir oldu. .NET Core Command-line(Core CLI) araçları olarak yeniden düzenlenen komutlar ASP.NET Core 1.0 RC2 ile dnx tarafının yerini alacak. Şimdilik öncesinde GitHub sitesinden de indirip kurabilirsiniz. Ya da http://dotnet.github.io/getting-started/ adresinden de ayrıntılı olarak başka bilgilere hatta docker imajına ulaşabilirsiniz.

Kısacası değişiklikler artarak devam ediyor. Bütün bu değişim içerisinde, bu yeni şeyleri kavramak, denemek oldukça zahmetli olabiliyor. Daha tam oturmamış olması, .NET Framework tarafında olup .NET Core tarafında desteklenmeyen namespace’ler olması biraz uğraştırıyor. Ama işin keyifli ve güzel yanlarından biri de bu değil mi? Son durumun özeti olması adına faydalı olduğunu düşünüyorum. Bir sonraki kafa karışıklığında görüşmek üzere 🙂