Web Uygulamaları Geliştirebileceğiniz Diller ve Platformlar

Bu yazımızda sizlerle birlikte web uygulamaları geliştirebileceğiniz bir kaç dili, onların platformlarını ve bu platformlarda kullanabileceğiniz bir kaç örnek kütüphaneyi inceleyeceğiz.

1. .NET Dilleri (Visual Basic, C#, F#)

Visual Basic, Microsoft tarafından 1991 yılında duyurulan ve Basic dilini temel alarak geliştirilen, nesne yönelimli (OOP), olay odaklı (event-driven) bir dil.

C# ise yine Microsoft tarafından 2000 yıllarında duyurulan, çoklu yönelimli (multi-paradigm) bir programlama dilidir. Nesne yönelimli, fonksiyonel ve generic programlama yaklaşımlarına sahiptir.

F#, artık tahmin edebileceğiniz gibi Microsoft tarafından 2005 yılında 1.0 versiyonuna ulaşmış, çok yönelimli, özellikle fonksiyonel programlama yapabileceğiniz bir dil. Aynı zamanda Javascript ve GPU odaklı kod oluşturma gibi yetenekleri de var.

.NET dillerini kullanarak web uygulamaları geliştirebileceğiniz bir kaç platform mevcut. ASP.NET ailesinin yanı sıra, aynı zamanda Owin (Open Web Interface for .NET) ve Nancy gibi protokole daha yakın platformlar da bulunuyor.

1.1 ASP.NET Ailesi

Popüler olanları sayacak olursak Web Forms, MVC ve Web Api platformlarını sayabiliriz. Onun dışında yeni çıkan Web Pages ve Blazor isimli platformlar da mevcut fakat bunları başka yazılarda detaylı bir şekilde inceleyeceğiz.

1.1.1 ASP.NET Web Forms

ASP teknolojisinin .NET platformunda hayat bulduğu ilk hali diyebiliriz. ASP’de olduğu gibi <% ve %> tagleri kullanılarak sunucu taraflı kod yazabilirken, aynı zamanda .NET kütüphanesinin tamamına da erişim sağlayabiliyorsunuz.

1.1.2 ASP.NET MVC

ASP.NET platformu üzerine MVC metodolojisinin kurgulandığı bir platformdur. Aynı zamanda klasik ASP’den beri kullanılan <% ve %> tagleri yerine, kullanımı biraz daha kolay olan Razor yazım şekli ile birlikte gelmiştir.

1.1.3 ASP.NET Web Api

ASP.NET MVC platformu üzerinde yapılan bir kaç değişiklik ile birlikte, RESTful API’ler geliştirilebilen bir platformdur ve son yıllarda istemci taraflı web geliştirmenin de popülerliğinin artması ile birlikte en sık kullanılan yaklaşımdır.

1.2 Owin (Open Web Interface for .NET)

Sunucu ve uygulama arasındaki bağı kopartmaya çalışan Owin, geliştiricilerin daha çok uygulamanın kendisine odaklanmasını sağlamaya çalışmaktadır. Middleware yaklaşımını kullanır ve diğer .NET platformlarına nazaran daha esnek bir API sunar.

1.3 Nancy

Herhangi bir metodolojiyi benimsemeyen Nancy, direkt olarak browser tarafından istenen kaynağa karşılık gelecek şekilde bir yazım şekli sağlar. Böylece fazla kapsamlı olmayan ihtiyaçlara karşılık çok hafif bir platform alternatifi sunar.

 

2. PHP

1995 yılında Rasmus Lerdorf tarafından yaratılan PHP, sunucu taraflı kodlama sağlıyor. WordPress, Joomla! ve Drupal gibi sistemler bu dil kullanılarak geliştirilmiş ve çok yaygın bir kullanıma sahip. Sadece PHP dilinin kendisi kullanılarak da bir web uygulaması geliştirilebilse de farklı yaklaşımları barındıran bir çok platform ortaya çıkmış. İçlerinden Symfony, CodeIgniter, Laravel, CakePHP ve Phalcon platformlarını örnek olarak sayabiliriz.

2.1 Symfony

İçerisinde 50 adet bileşen bulunduran Symfony, bu bileşenler ile birlikte kod tekrarını azaltmayı ve genel ihtiyaçları karşılamayı amaçlıyor. Drupal, phpBB, yine aşağıda inceleyeceğimiz Laravel ve daha bir çok platform tarafından da kullanılmakta.

2.2 CodeIngiter

MVC metodolojisini benimseyen CodeIgniter, MVC’yi benimsemeseniz bile kullanabileceğiniz bir platform çünkü sizi MVC yazmaya zorlamıyor. Küçük ve performanslı web uygulamaları geliştirebilirsiniz. Artı olarak detaylı ve sade bir dökümantasyona da sahip.

2.3 Laravel

Web sanatçılarının PHP kütüphanesi mottosuyla kendini gösteriyor Laravel. İçerisinde Active Record desenini implemente eden Eloquent adında bir ORM’e ve Blade adında bir şablon motoruna sahip. Yaklaşım olarak MVC tercih edilmiş.

2.4 CakePHP

Dökümanın ilerleyen bölümlerinde inceleyeceğimiz Ruby on Rails’in konseptine uygun geliştirilen CakePHP, diğer bir çok platform gibi MVC yaklaşımını benimsiyor. Laravel’de de olduğu gibi içerisinde Active Record desenini implemente eden bir kütüphaneye sahip.

2.5 Phalcon

Büyük bir çoğunluğu C ile yazılan Phalcon, diğer platformlara göre daha performanslı ve daha az kaynak harcadığını savunuyor. Aynı şekilde C ile yazılan bir ORM’e ve MVC yaklaşımına sahip.

 

3. Python

‘Python Hakkında Ufak Bir Söyleşi’ adlı yazımda kendisine detaylı bir şekilde değindim. Okumak isterseniz buradan ulaşabilirsiniz.

Bir çok web platformu mevcut fakat bir kaç örnek olarak Django, Flask ve Pyramid’i sayabiliriz.

3.1 Django

İçerisinde varsayılan olarak şablon motoru, ORM ve kimlik doğrulama gibi özellikler ile geliyor ve Python üzerinde web programlama için kullanılan en popüler platformdur.

3.2 Flask

Aşağıda da inceleyeceğimiz ve bir Ruby platformu olan Sinatra’dan ilham alan Flask, alt tabanında Werkzeug WSGI Toolkit ve Jinja2 şablon motorunu kullanıyor. Çok hafif bir yapıya sahiptir.

3.3 Pyramid

Az uğraş gerektireceğini vaad eden Pyramid, en basitinden en kapsamlısına bütün projelerde kullanılabileceğini söylüyor. İçerisinde dosya bazlı şablon motoru, doğrulama sistemi ve test kütüphaneleri ile birlikte geliyor ve geniş konfigurasyon desteği sağlıyor.

 

4. Ruby

Yukihiro “Matz” Matsumoto tarafından Japonya’da, 1990’lı yılların ortalarında geliştirilmeye başlanmış. Çoklu yönelimli bir dil olan Ruby, nesne yönelimli ve fonksiyonel programlama yaklaşımlarına sahiptir.

Dökümanda önceden de bahsedilen, Ruby için önemli sayılabilecek iki adet platform bulunuyor ; Ruby on Rails ve Sinatra.

4.1 Ruby on Rails

Convention over Configuration yaklaşımını savunan Ruby on Rails, çok hızlı bir şekilde web üzerinde çalışabilen uygulamalar geliştirmenizi sağlıyor. Ruby üzerinde kullanılan açık ara en popüler platform.

4.2 Sinatra

Nancy ve Flask gibi, minimum efor ile web uygulaması yazmanızı sağlayan bir platform. Test kütüphaneleri ve topluluk tarafından geliştirilen eklentiler ile çok daha geniş çaplı uygulamalar da yazılabiliyor.

 

Bu yazıda, .NET dilleri, PHP, Python ve Ruby dilleri için kullanılabilecek platformları inceledik.

Bir sonraki yazıda görüşmek üzere.

.NET Core, .NET Standart ve Felsefe Taşı – Part II

Previously on : .NET Core, .NET Standart ve Felsefe Taşı – Part I

“It does not do to dwell on dreams and forget to live.” ― J.K. Rowling, Harry Potter and the Sorcerer’s Stone

J.K. Rowling’in de dediği gibi, hayal dünyasının içerisinde hayat sürüp yaşamayı unutmak pek olmuyor. İşte PCL’ler hayatımıza böyle girmişti fakat, hayal dünyasının içerisinde, yani teoride mantıklı bir yaklaşım, gerçek hayata uyarlandığında pek de tutarlı olmadı, olamadı. Çok mu abarttım? Olabilir. Ama bu ortada çözülmesi gereken bir durumun olduğu gerçeğini değiştirmiyor.

Soruyu tekrar alabilir miyim?

Ha, şu soru. .NET Standart neden var? Ondan öncesinde PCL’ler neden var diye sormamız gerekiyor değil mi? Çözmeye çalıştığı problem aslında yazdığınız kodların farklı .NET proje tiplerinde kullanılabilmesini sağlamak. Peki neler bu proje tipleri ? .NET Framework, Silverlight, Windows 8 (Metro), Windows Phone, Xamarin, Mono, Universal Windows Platform (UWP), XBox 360, liste daha uzuyor.

enter image description here

Evet, tabii, güzel fikir. Bir çok ihtiyacı da karşıladı aslında, bu sebeple tamamen kötülemek doğru olmaz ama bir süre sonra bu yaklaşımın eksikliklerini görmeye başladık.

Nerede benim API’ım ?

dotnet-today

Birinci problem, PCL altyapısı, uygulamayı yazarken kullanabileceğiniz API’ı, desteklemeye çalıştığınız platformların kesişimine göre belirliyor. Bir platformda olan bir API diğer platformda yoksa, o kısım çıkartılıyor. Örneğin Xamarin.iOS, Xamarin.Android ve UWP için yaratayım bir PCL dediğinizde, yapacağınız dosya okuma ve yazma işlemleri artık düşündüğünüz kadar kolay olmuyor. Çünkü bir tarafta System.IO varken, diğer tarafta Windows.Storage var. Kesişimin içerisinde bu iki API da yok. Yani, var da yok. System.IO namespace olarak var ama tanıdık olduğumuz File ve Directory yok mesela. Bu sefer kulağınızı tersten tutmaya ve şuradaki gibi bir guide’ı takip etmeye başlıyorsunuz. Bu da size hayatınızı ve mesleki kararlarınızı sorgulatabiliyor. Halbuki sadece bir dosya okumak istemiştiniz. Bu tür eksiklikleri kapatmak için ortaya PCLStorage gibi paketler çıkıyor ama bu nedense yama hissiyatı yaratıyor. Her kombinasyonda eksik kalan parçalar ve o eksiklikleri kapatmaya çalışan paketler. Sonu gelmez bir döngü.

Ama Cross-Platform oluyor değil mi ?

Aslında tam değil. Yazdığınız kod her platform için ayrı ayrı derleniyor. Evet, bir PCL paketini NuGet üzerinden çekerken bütün desteklenen platformlar için derlenen dosyalar da yanında geliyor. Şimdi, bundan iki yıl sonra başka bir .NET platformu çıksa – ki bu hızda giderse hiç de düşük bir olasılık değil – bu paket o platformda çalışacak mı? Tabii ki hayır. Çünkü paketin, bu platform da eklenerek tekrar derlenmesi gerekiyor. Bu arada kaybedebileceğiniz API’ları da bir yandan düşünseniz iyi olur. Onlara da bir “yama” gerekecek.

.NET Standart

Yani bu iki büyük soru işaretine karşı çözüm olacak yapının, öncelikle stabil bir API sunması gerekiyor. Bu ise, hali hazırdaki platformların bu API’ı implemente etmesi gerektiği anlamına geliyor ki geliştirmek istediğim platformlara göre erişebildiğim API oranı azalmasın. Aynı zamanda, sonrasında geliştirilebilecek diğer platformların da aynı API’ı implemente etmesi sağlanırsa, bu yapı için derlenen paketlerin de gelecek platformda çalışması sağlanabilir.
Buradan ise yapının görevinin, bütün .NET platformları için ortak bir API sunmak ve bunun devamlılığını sağlamak olduğunu söyleyebiliriz ve iki soru işaretimiz de böylece ortadan kalkmış olur.

Sonuç olarak ortaya .NET Standart çıkıyor.

.NET Standart sayesinde artık tek bir API kullanarak, .NET Standart API’ını implemente etmiş olan bütün .NET platformlarını destekleyebiliyoruz. Yakın zamanda 2.0 versiyonu çıkan .NET Standart tarafından desteklenen API setinin içerisinde Networking, IO ve Threading gibi önemli yapı taşları mevcut.

netstandard-apis

Bir süre sonra PCL’ler yerini .NET Standart’a bırakacak. Kişisel kanaatim, .NET Standart’ın çok daha iyi bir yaklaşım olduğu yönünde. Umarım yakın zamanda bir standarta daha ihtiyaç duymayız.

“The truth.” Dumbledore sighed. “It is a beautiful and terrible thing, and should therefore be treated with great caution.” ― J.K. Rowling, Harry Potter and the Sorcerer’s Stone

Bir sonraki yazıda görüşmek üzere.

.NET Core, .NET Standart ve Felsefe Taşı – Part I

Merak etmeyin, bu yazının ne Harry Potter, ne de maddeyi altına dönüştürme ile bir ilgisi yok. Bu yazı dizisinde daha çok, .NET Core ve .NET Standart’ın kendilerini, ortaya çıkmalarındaki nedenleri, ekosistemde yapacakları değişiklikleri ve bizim bu değişikliklere nasıl ayak uydurmamız gerektiği ile ilgili konuşacağız.

Giriş

Yakın zamanda .NET Core 2.0 ve ASP.NET Core 2.0 duyuruldu. Bir çok değişiklik ve güzel haber var fakat boşverin, şimdi oradan kopup, biraz daha geriye, bütün bunların başladığı zamana gidelim. Fazla değil Kasım 2014’te Microsoft, .NET Core’u (CoreFX) Open Source yaptı. Tabii kimse .NET Core’un ne olduğunu bilmiyordu. Blog yazısında, aslında bu teknolojinin içeride ASP.NET 5 (vNext) ve .NET Native’de -ki başlı başına ayrı bir konu- hali hazırda kullandıklarını, gelecekte .NET platformunun temel taşının bu yapı olacağını söylediler. Open Source olmasındaki sebep ise, .NET’in arkasında daha güçlü bir ekosistem oluşturmak ve cross-platform bir hale getirmek için hazırlıklara başlamaktı.

.NET Core’un arkasındaki ana sebep ise, .NET Framework yaklaşımının pek de doğru olmaması ve bunu değiştirmeye yönelik çalışmalar yaparken de aynı zamanda zaten olması gereken cross-platform desteğini de göz önünde bulundurmaktı. İki amaç da zamana göre daha fazla önem kazanabilir.

.NET Core’un alt yapısını anlatmadan önce size .NET Framework yaklaşımını ve yanında getirdiği problemleri biraz daha açmam gerek.

Bir Sorunun Tanımı

 

Yukarıdaki ekranı hatırladınız değil mi? Hiç görmediyseniz eğer ne mutlu size, bugünün şanslı 10.000 kişisinden birisiniz. Özetlemek gerekirse, yüklediğiniz bir uygulama, çalışmak için .NET Framework’ü gerektiriyor ve önce onu yüklemeniz gerek. Bunun sadece Windows içerisinde karşılaşılan bir durum olduğunu söylemiyorum, keza diğer sistemlerde yüklediğiniz paketler, başka paketleri gereksinim olarak isteyebiliyor, fakat buradaki ana sorun teknik değil. Ana sorun, yukarıdaki problemin son kullanıcı tarafından çözülmesinin beklenmesi. Aynı zamanda bu paket öyle elzem ki, bütün .NET uygulamaları* kullanıyor ve versiyonları var. Uygulama hangi versiyonu kullanıyorsa ona göre yüklenmesi gerek. Yukarıdaki “Yes” butonuna basınca sizi o paketin indirme sayfasına yönlendiriyor, siz de inen paketi kuruyorsunuz. Tabii paket kullandığınız işletim sistemi tarafından destekleniyorsa. Örneğin Windows 7 kullandığınızı varsayarsak ve açmaya çalıştığınız uygulama .NET Framework 4.6 kullanıyorsa eğer, SP1 yükseltmesini önceden yapmış olmanız gerek. Yapmamışsanız uygulama çalışmıyor. Yani bir uygulamayı kullanmak için önce sistem güncellemesi, sonra paket kurulumu ve en sonunda kullanmak istediğiniz uygulamanın kurulumunu yapmanız gerekebilir. Bu arada bütün bunları teknik bilgisi fazla olmayan birinin yapmaya çalıştını düşünürseniz, durum pek iç açıcı değil.

Diğer bir sorun, bu kütüphanenin içerisinde herşeyin olması. Siz bir uygulama yazarken sadece küçük bir kısmını bile kullansanız, bu o uygulamanın .NET Framework kullandığı gerçeğini değiştirmiyor. .NET Framework 4.6’nın kurulum paketi 62.4 MB. Kurulum sonrası boyutu 100 MB’ı aşıyor. Amacı iki sayı toplamak olan bir konsol uygulamasının çalışması için de bu kütüphanenin kurulması gerek.

Ha bu arada yukarıdaki bu iki uygulama da diğer işletim sistemlerinde çalışmıyor.

Sanırım yavaş yavaş problemin kaynağının ne olduğunu ve nasıl çözülebileceğini düşünmeye başlamışsınızdır. Öyle bir şey olmalı ki, uygulama herhangi bir dış kaynağa gereksinim duymamalı, yani kullandığı paketleri yanında götürmeli.

* = Bütün .NET Framework uygulamaları yani WinForm, WPF, ASP.NET gibi.

Bir Efsanenin Doğuşu

.NET Core işte bu fikrin hayata geçmiş hali. Tabi şu “kullandığı paketleri yanında götürmesi” kısmı için .NET Framework parçalara ayrıldı ve çoğu paket NuGet üzerinden referans edilebilir hale getirildi. En temel parçalar (CLR ve içerisindeki GC ve JIT) ise cross-platform çalışması için baştan yazıldı ve .NET Core CLR oluştu. Tabii hepsinin cross-platform çalışması için değiştirilen bir çok yaklaşım da oldu.

Peki Web?

ASP.NET 5 (vNext) yani ASP.NET Core ise, .NET Core’un üzerine ASP.NET mimarisinin bindirilmesi ile oluşmuş bir platform. Ocak 2016’ta ASP.NET 5 adı ASP.NET Core olarak değiştirildi çünkü ASP.NET  5 sanki ASP.NET 4.5’in bir üst versiyonu gibi anlaşılıyordu. Halbuki ASP.NET 5,  yapısal anlamda ASP.NET 4.5’i andırmıyordu bile ve bu insanlarda kafa karışıklığı yaratabilirdi. Bu sebeple isim değişikliğine gidildi.

Soru İşaretleri

Peki .NET Standart bunun neresinde. Bugün itibarıyla üç tane .NET platformu var; .NET Framework, .NET Core ve Xamarin. Her birisinin amacı ve kullandıkları altyapılar farklı. Tabii bu kullanılan dil aynı olsa bile oluşan paket uyuşmazlığı, yazılan kodların platformlar arası kullanılmasını engelliyor. Zaten her biri programlayan kişiye farklı API’lar sunuyor. Yani her türlü yazılan kod belirli bir platforma özel olmuş oluyor. Bu sorunu çözmek için üretilen PCL ise sorunu daha da büyük bir hale getiriyor.

Part II’de ise .NET Standart’ın ne olduğunu ve yukarıdaki probleme nasıl bir çözüm getirdiğini göreceğiz.

.NET Core, .NET Standart ve Felsefe Taşı – Part II