Alet çantası kategorisine ait bu yazıda Sublime Text metin editörünü incelemeye çalışacağız. Sublime Text kodlama yapmak, kod biçimlendirmek ve düz yazılar yazmak için geliştirilmiş bir metin editörüdür.
Sublime Text editörünün bana göre en çekici tarafları kullanıcıya akışkan bir yazım imkanı sağlaması ve kodlama sırasında göze hoş gelen bir renklendirme yapmasıdır. Performans bakımından ise son derece başarılıdır.
Çok sayıda programlama dilini destekleyen ve bu dillerde kod biçimlendirmesi yapabilen bir yapıda olması performans konusunda hiç bir sıkıntı yaşatmıyor. Desteklediği programlama dilleri C, C++, C#, Java, XML, HTML, CSS, Javascript, PHP, Phyton, Ruby, SQL, Erlang, Heskel, MATLAB gibi popüler dillerdir.
Editörün code snippet özelliği sayesinde sık kullanılan kodları dosyalayarak istediğimiz zaman editör kısayolundan çağırabiliriz.
Çoklu seçim özelliği(multiple selection) birden fazla imleç ile aynı anda çoklu değişiklik yapmaya imkan sağlar.
Editörün özellikleri eklentilerle arttırabilir. Çok sayıda eklenti desteği ile geliştiricilere kolaylık sağlar. Gerçekten denemeye değer bir editör olduğunu düşünenlerdenim. Birçok geliştiricinin özellikle bu editörü tercih etmesi bu düşünceyi güçlendirir nitelikte.
Windows 8 sonra Windows 8.1 derken eylül 2015 itibarıyla şu an ki nihai sürüm olan Windows 10 sürümüne geçiş yapmış bulunuyorum.
Windows 10 sürümünde il göze çarpan başlat menüsünün yeniden düzenlenerek klasik başlat menüsü halinde kullanıcılara sunulmasıdır. Windows 8 sürümlerinde başlat menüsü yerinde metro style denen bir arayüz tasarlanmıştı. Bana göre son derece gereksiz ve kullanışsız olan bu arayüz nihayet kaldırılmış. Ancak başlat menüsünün bir kenarında hala etkisi küçük bir pencere şeklinde devam ediyor.
Başlat Menüsü
Windows 8 sürümlerinde Windows App Store uygulamalarının tam ekranda açılması kullanıcılarının görev çubuğuna erişmesini engelliyordu. Windows 10 sürümünde bu sıkıntı ortadan kaldırılmış ve pencere şeklinde çalışma imkanı sunulmuş.
Pencere Yapısı
Bir diğer özellik olan multitask özelliği biraz değişikliğe uğramış ve Ctrl+Tab kısayolu ile çalışan uygulamaları gösteren pencerenin görünümü yenilenmiş.
Multitask
Çalışan tüm uygulamaları görebilmek için görev çubuğuna Görev Görünümü adında bir kısayol da oluşturulmuş. Görev görünümünde sağ altta Yeni Masaüstü ekleme tuşu sayesinde birden fazla sanal masa üstü ayarlamanıza olanak sağlanmış. Bu sayede iş bölümlerinde göre kategorize edilebilen masaüstleri oluşturmak mümkün hale geliyor. Örneğin internet tarayıcıları ve ofis çalışma dosyaları ayrı masaüstü kategorilerinde tutulabilir.
Sanal Masaüstü
Yeni özellikleri keşfettikçe eklemeye devam etmeye çalışacağım. Şimdilik bu kadar. Bir sonraki yazıda görüşmek dileğiyle.
Bir yazılımın ortaya çıkabilmesi için öncelikle müşterinin ne tür ihtiyaçlarını karşılayacağı belirlenmelidir. Daha sonra bu ihtiyaçlara uygun teknolojilerin ve yöntemlerin belirlenmesinin ardından kodlama ve test etme işlemleri gerçekleştirilerek müşteriye hazır bir ürün sunulur.
Waterfall Model
Yazılımın geliştirme sürecinin başından itibaren sırayla analiz, plan, tasarım, kodlama ve test süreçleri birbirini takip eden adımlar dizisidir. Bu modele waterfall(şelale) denilmektedir. Bazen bu adımlara destek(maintenance) süresi de eklenmektedir. Bir yazılımın tüm gereksinimleri müşteriden alındıktan sonra bu adımlar takip edilerek son ürün ortaya çıkmaktadır. Ancak uzun zaman alan yazılım projelerinde zaman içerisinde teknolojilerin veya müşterilerin ihtiyaçlarının değişebileceğinden yazılımda da değişiklikler gerekebilmektedir. İki sene süren bir projeyi düşünecek olursak proje başında belirlenen istekler iki sene sonunda mevzuatlar veya iş kuralları veya teknoloji değişikliğinden dolayı bazı ihtiyaçları karşılamayabilir. İş sonunda müşterinin ihtiyaç duymadığı bir ürün ortaya çıkabilir. Diğer taraftan analiz veya planlama sırasında yapılan bir hata ancak test sırasında ortaya çıkabilir. Proje zamanlaması için yapılan tahminler tutamayabilir.
Zaman ve bütçe kısıtlamasının olduğu startup gibi bir şirket için bu tür geliştirme modeli bir süre sonra işletmeye zarar ettirmeye başlar.
Zamanla edinilen tecrübeler geliştiriceleri bu modeli biraz değiştirmeye zorlamıştır. Müşterilerin ihtiyaçlarını guruplara bölerek her ihtiyaç için analiz, plan, tasarım, kodlama ve test süreçlerini yeniden yapılması uygun görülmüştür. Bu model, spiral(sarmal) model olarak adlandırılmıştır. Spiral model agile(çevik) proje geliştirme yaklaşımı içerisinde kullanılan bir modeldir. Burada çeviklikten kasıt değişime ayak uydurabilmektir.
Spiral Model
Eğer iki senelik bir proje süreniz varsa, bu model size birinci ayın sonunda müşterinin belirttiği ihtiyaçlardan birini çalışır şekilde ona sunmanızı sağlamaktadır. Müşteriye tüm proje süresi sonunda çalışan bir ürün sunmak yerine, ona her ay yeni bir özelliği devreye alınmış olan bir yazılım ürünü sunulmuş olur.
Örneğin bir hesap makinesi yapmayı tasarlıyorsanız birinci adımda dört işlemi yapabilen bir hesap makinesi yapmak ve müşteriye sunmak yeterlidir. İkinci adımda üslü ve köklü işlemler ihtiyacını karşılayan özellik eklenir. Üçüncü adımda müşteriden yeni bir talep gelir ve trigonometrik hesaplar yapabilen özellikler eklenebilir. Daha sonra gelen geri dönüşlere(feedback) göre belki matris çözebilen özellikler gerekebilir. Burada önemli olan, her adım sonunda müşterinin elinde çalışan bir hesap makinesinin olmasıdır. Eğer waterfall model ile geliştirme yapılırsa tüm özellikler ve testler bittiğinde müşteriye çalışan bir ürün teslim edilir. Belki de müşterinin hiç ihtiyaç duymayacağı matris işlemler özelliğini de eklemiş olabilirsiniz. Şunu unutmamalıyız ki; gereksiz işlere harcanan zaman, işi yapan tarafa gider olarak yazılır.
Agile Manifesto
Agile(çevik) yazılım geliştirme yaklaşımı bir işi küçük parçalara bölerek yapmayı ilke edinen bir disiplindir. Bir ürün veya yazılım aracı veya bir kodlama yöntemi değildir.
Agile (çevik) yazılım geliştirme konusunda, yazılım sektöründe tecrübeli bir ekip tarafından bir manifesto yayınlanmıştır. Manifesto içeriğine ve ilgili kişilere http://www.agilemanifesto.org/ adresindenulaşabilirsiniz.
Agile manifestonun dört temel ilkesi vardır.
English:
Individuals and interactionsover processes and tools
Working softwareover comprehensive documentation
Customer collaborationover contract negotiation
Responding to changeover following a plan
Türkçe:
Süreç ve araçlardan ziyade bireyler ve etkileşimler
Kapsamlı dökümantasyondan ziyade çalışan yazılım
Sözleşme pazarlığından ziyade müşteri ile işbirliği
Plana bağlı kalmaktan ziyade değişime yanıt vermek
Bu ilkeler ne anlama geliyor?
Manifesto ilkelerinde, yazılım geliştirme sürecinin önünü açan öncelikler belirlenmiştir. Tüm cümlelerde ortak olarak kullanılan “ziyade” kelimesi işte bu öncelikleri vurgulamaktadır.
1.Süreç ve araçlardan ziyade bireyler ve etkileşimler: Yazılımlar bilgisayarlar tarafından çalıştırılan ürünler olsa da yazılımı talep eden müşteriler ve onu geliştiren programcılar insanlardır. Müşteriler ve geliştirici ekip arasında güçlü bir iletişim olmalıdır. Ürünler ve araçlar değişebilir, eskiyebilir ve gözden çıkarılabilir. Fakat birbiriyle uyumlu iyi bir ekibiniz varsa onu gözden çıkaramazsınız. Bu nedenle bireylere değer vermek işletilen süreç ve kullanılan araçlardan daha önemlidir.
2.Kapsamlı dökümantasyondan ziyade çalışan yazılım: Projelerde müşteri ile el sıkışmanın şartı iş sonunda çalışan kaliteli bir yazılımın olmasıdır. Müşteriler kapsamlı dökümanlara para ödemek istemez ama tercihen isterler. Müşteriyi boğmayan ancak ona yeteri kadar bilgi veren bir dökümantasyonunuz olmalıdır. Bu nedenle önceliğimiz çok kapsamlı bir dökümantasyon oluşturmak yerine iyi çalışan bir yazılım olmalıdır.
3. Sözleşme pazarlığından ziyade müşteri ile işbirliği: Müşteri tarafından sunulan şartnameler ve yapılan sözleşmeler her iki tarafa güvenlik duygusu verir. Bir sözleşmeye imza atılır ve belirli bir zamanda yapılacak işler planlanmış olur. Agile süreçlerde her zaman müşteri ile işbirliği ön plandadır. Kararlar beraber alınır, sürekli görüş alışverişi yapılır, teslimatlar sonrasında geri bildirimler alınarak değerlendirmeler yapılır. Yani iş sözleşmesini ve talepleri alıp iş bitiminde görüşmek diye bir şey olmaz.
4. Plana bağlı kalmaktan ziyade değişime yanıt vermek: Agile yani çeviklik bir plana bağlı kalmadan değişime cevap vermek demektir. Zamanla gereksinimler, mevzuatlar iş kuralları değişebileceğinden uyguladığınız çözüm yöntemi de bu değişimlere ayak uydurabilmelidir.
Agile süreçlerde Scrum, Kanban ve Lean gibi proje yönetim yaklaşımları yanında Extreme Programming(XP) gibi yazılım geliştirme yaklaşımları kullanılmaktadır. Extreme Programing yazılım geliştirme yöntemleri, uzun yıllar tecrübe edilmiş ve kendini kanıtlamış yöntemler olarak bilinir. Bunlar arasında Test Driven Development gibi önce test kodunun yazılıp ardından çalışan kodun üretildiği bir yaklaşım vardır. Pair Programming yani eşli programlama diye bilinen iki programcının aynı kodu geliştirdiği yaklaşımlar vardır. Geliştiricilerin birbirlerinin kodunu incelemesi ve yorumlaması(core review) da yine bir diğer yaklaşımdır.
Bütün bu yöntemler yazılımın türüne bağlı kalmadan uygulanabilecek yöntemlerdir. Yani web uygulaması, mobil uygulamalar, oyunlar veya masaüstü uygulamaları gibi her türlü projede çevik yöntemler uygulanabilmektedir.
Neden Agile?
Bu sorunun birinci nedeni agile kavramının değişime cevap verebilme yeteneğidir. Agile geliştirmenin bir diğer nedeni ise çabuk sonuç alma isteğidir. Taleplerin adım adım karşılanıp çalışan ürünlerin müşteriye sürekli teslim edilmesi neticesinde size olumlu veya olumsuz geri bildirimler akmaya başlar. Müşteri ile işbirliği içinde olduğunuzdan doğru şeyi yapıp yapmadığınızı hemen anlayabilirsiniz. Bu sayede harcadığınıza karşılık kazandığınızı görebilirsiniz yani yatırım getirisi (Return on investment) hakkında bilgi sahibi olabilirsiniz. Agile süreçlerde büyük bir yazılımın küçük parçaları ile çalışıldığı için erken yapılan hatalar büyük bir felakete neden olmaz. Diğer bir deyişle hatanın erkenden fark edilmesi sağlanmış olur. Ekiplerin düzgün bir yapıda oluşturulması ile kaynak planlaması da daha mantıklı olacaktır. Örneğin waterfall yöntemi ile yapılan bir yıllık bir projede analiz için gerekli çalışanların işi üç ayda bittikten sonra gereksiz yere projede tutmak istemeyebilirsiniz. Ancak ilerde analiz ile ilgili bir sorun çıkarsa diye tutmak zorunda kalabilirsiniz. Spiral yöntemde ise her döngüde süreç adımları yeniden ele alındığı için bu duruma uygun bir takım oluşturulabilir.
Factory Pattern Nesne oluşturma işleminin bir iş kuralı dahilinde olduğu durumlarda kullanıcıyı kuralın dışında tutarak nesne oluşturmak için kullanılır. Kurallara uygun bir şekilde soyut tipleri implemente eden somut nesneler oluşturularak kullanıcılara verilir.
Abstract Factory Design Pattern
Factory nesneleri oluşturmak için kullanılan bir desendir. Yani Abstract Factory deseni ile soyut bir factory nesnesi oluşturulur, bu factory nesnesinden de belirlenen kural dahilinde bir nesne oluşturulur. Küme alt küme mantığına benzer bir yapı söz konusudur.
Adapter Design Pattern
Birbiriyle uyumsuz iki farklı interface arasında anlaşma sağlayan bir köprü vazifesi görür. Bunu gerçek hayatta cep telefonu ile elektrik prizi arasında görev yapan şarj aletine benzetebiliriz.
Template Pattern
Bir algoritma için soyut tipte bir iskelet oluşturarak bu iskeletten somut süreç adımları oluşturmamızı sağlar. Algoritmanın adımlarını somut sınıflarda tanımlarız. İskelet görevi gören tip bir şablon niteliğindedir.
Singleton Design Pattern
Bir sınıfa ait sadece tek bir nesne oluşturmayı ve gerektiğinde ona ulaşabilmeyi garanti eder. Yani nesne oluşturma üzerine oluşturulmuş bir desendir.
Decorator Pattern
Nesnelere kompozisyon yoluyla yeni davranışlar eklememizi sağlar. Bu işlemi aynı temel sınıftan türeterek veya ortak bir interface uygulayıp nesneye enjekte ederek yapabilmek mümkündür.
State Pattern
Bir nesnenin iç durumunda meydana gelen değişikliklerin nesnenin davranışını değiştirmesine izin verir. İç durumdan kasıt interface tipleridir.
Strategy Pattern
Çalışma zamanında dinamik olarak algoritma değişikliğine olanak sağlayan bir desendir. Algoritmalar somut nesnelerde saklanır. Client kod ise algoritma sınıfının türetildiği abstract veya interface türünü tanır.
Not: State ve Strategy pattern diyagram olarak birbirine benzerdir. Ancak çalışma prensipleri açısından birbirlerinden farklıdırlar. State pattern için nesnenin NE olduğu önemlidir. Strategy için nesnenin NASIL çalıştığı önemlidir.
Specification Pattern
İş nesneleri içerisinde gömülü olan seçim kriterlerini başka nesneler ile paylaşamazsınız veya tekrar tekrar kullanamazsınız. Specification pettern, bu problemi ortadan kaldırır.
Composite Pattern
Nesnelere ağaç yapısında ya da hiyerarşik topluluklar halinde gruplanabilme yeteneği sunar. Örneğin bir kategorinin alt kategorisi olabileceği gibi onun da alt kategorisi olabilir.
Proxy Design Pattern
Bir sınıfın işlevselliği başka bir sınıf ile temsil edilir. Cache mekanizmaları oluşturulurken kaynak kullanımını azaltmak için kullanılabilir. Örneğin veri tabanından veri getiren bir nesne, aynı verilere ihtiyaç duyulduğunda tekrar veri tabanına gitmeye gerek duyulmadan kullanılabilir.
Builder Design Pattern
Kuramsal bir iş akışını işletmek için gerekli olan kompleks bir nesnenin basit nesneler ile adım adım oluşturulmasına olanak sağlar.
Angularjs direktiflerinin görünüm tarafını template özelliği üzerinden belirleyebiliriz. Template özelliğini belirlemenin bazı yöntemleri vardır. Bunlar:
Düz metin şeklinde belirleme
URL ile dosya yolunu göstererek belirleme
$templateCache servisi ile belirleme
Bu işlemleri örnek bir personel kartı tanımlayarak gerçekleştirmeye çalışalım.
Düz Metin Şeklinde Template Belirlemek
Direktiflerin template özelliğini düz metin şeklinde belirlemek aşağıdaki yöntem izlenmelidir.
URL ile Dosya Yolunu Göstererek Belirleme
Bu yöntemde templateUrl özelliği olarak bir html dosya yolu verilir. HTML dosya üzerinde istediğimiz gibi düzenlemeleri yaparak yolunu bu şekilde direktife kolayca verebiliriz.
$templateCache Servisi ile Belirleme
URL ile template belirlerken yapılan işlem önceden hazırlanmış bir HTML dosyasının yolunu templateUrl özelliğine bildirmektir.
$templateCache servisini kullanırken HTML metinini önceden servise belirtmek gerekmektedir. Servisin kullanımı put() ve get() metodları üzerinden yapılmaktadır.
Template içeriğini uygulama başlatılırken yani modülün run fonksiyonu çalıştırıldığında gerçekleştirebiliriz.
$templateCache içerisindeki veriye templateUrl üzerinden aşağıdaki şekilde erişmek mümkündür.
Not: Angularjs uygulamalarında script şeklinde tanımlanan html içerikleri doğrudan $templateCache içerisine kaydedilir.
Bunu şu şekilde inceleyebiliriz:
Burada html içeriği script olarak tanımlanmıştır ve id değeri olarak card.html verilmiştir. İçeriğe javascript tarafından $templateCache.get(‘card.html’) şeklinde erişilebilmektedir.
Yazılım projelerinin geliştirilmesi sırasında karşılaşılan bazı genel problemler vardır. Bu problemler yazılımın Frontend veya Backend olmasına bağlı olmayan, sürecin gelişimi sırasında ortaya çıkan problemlerdir.
Projelerde istenen taleplere bağlı olarak yazılımda çok fazla kod olabilir. Kod sayısı arttıkça yazılımın çalışma performansı da düşmeye başlar. Bir süre sonra kodu yönetemez hale gelirsiniz. Artık kod sizi yönetmeye başlar ki bu durumda yeterki çalışsın mantığıyla bir dizi mantıksız işler yapmaya başlayabilirsiniz. Bu gibi durumlarla başa çıkabilmek için uyguladığınız yöntemlerde kod sayısı artsa bile kodda karmaşıklığın oluşmaması gerekmektedir. Yani bir sene süren bir projede ilk gün nasıl kafa karışıklığı olmadan rahatça kod eklenebiliyorsa, son günde de aynı rahatlıkla kod eklemesi yapılabilmelidir. Modüler yapılar kullanarak bir şekilde kodun karmaşasını azaltabiliriz, bu sefer de modül sayıları artar ve iş süreleri uzamaya başlar.
Bu noktada işlerimizi önemli ölçüde kolaylaştıracak olan araçlar Framework’lerdir. Bizim yapmamız gereken bir takım işleri Framework’lere yüklemek zaman kazanmak açısından önemlidir. Her framework amaca uygun olmayabilir. Bu nedenle Framework seçiminde kolay kullanılabilirlik, sürekli güncellenme, performans ve geniş topluluklar tarafından kullanılıyor olmak önemlidir.
Angularjs bu açıdan bakıldığında yapılabilecek en doğru seçimlerden birisidir. Üretim ve destekleme tarafında Google vardır ve çok yaygın kullanılan bir Framework’dür. Kullanım açısından son derece kolaydır. Model ve View tarafındaki ayrımı yapabilmesi (MVC mimarisi) ve modüler geliştirmeye imkan sağlayan yapısı sayesinde kullanıcı dostu bir yapısı vardır.
Angularjs Yapı Taşları
Angularjs kendine özgü bir mimari üzerine geliştirilmiştir. Belli yapı taşları üzerine oturtulmuş bir düzen söz konusudur. Bunlar:
Module
Config
Route
Controller
View
Directive
Filter
Service
Factory
şeklinde sıralanabilir.
Angularjs Proje Yapılandırması
Angularjs ile yapılandırılacak projeler mimari açıdan önemlidir. Biz geliştiricilere düzgün kod yazabilmek için birçok imkanı sunan bir framewrok ile spagetti kod oluşturmamak lazım. Bu açıdan angularjs ile çalışırken dikkat edilmesi gereken bazı hususları aşağıda başlıklar halinde ele alınmıştır.
Modüler Yapı
Müşterinin her talebi için uygulamayı bölümlendirmek ve her bölüm için farklı bir modül oluşturulmalıdır. Geniş ölçekli bir uygulama geliştirirken her bileşeni tek bir modül altına toplamak yerine iş mantığına göre tasarlanmış birden fazla modül ile çalışmak daha uygun olacaktır. Örnek olarak Email Hizmeti veren bir uygulama için modüller şu şekilde olabilir:
Angularjs tarafından sunulan Dependency Injection yapısı sayesinde soyutlamalar kolayca yapılabilmektedir. Servis yapısı ile modüller arasında izolasyonlar yapılmalıdır. Bu sayede servisler veya modüller arasında kod aktarımı ile iletişim sağlanabilir.
Oluşturulan servisler tek bir görevi yerine getirmelidir. Örneğin HTTP protokolü üzerinden bir dış kaynak ile veri alış verişi yapacak olan bir servis sadece o kaynakla konuşmalıdır. Veriyi almışken servise hadi ekranda listeleme de yapın şeklinde ikinci bir görev verilmemelidir. Aksi taktirde hep karşısında durduğumuz karmaşıklık problemine doğru ilk adımı atmış oluruz.
Kod Yapısı
Mümkün olduğunca az kod satırlarıyla hazırlanmış, gerektiğinde servisler aracılığı ile haberleşebilen modüller oluşturulmalıdır. Servis, Controller ve Template gibi kod birimlerinin içerikleri sade anlaşılır ve kısa tutulmalıdır.
HTML tarafındaki bir DOM elemanları üzerinde Controller veya Service gibi yapılar içinden erişip doğrudan işlem yapmamalısınız.
Controller sınıflarından dış kaynaklara erişilmemelidir. Bu işlemi servisler aracılığı ile gerçekleştirip, ilgili servislere controller tarafından erişim sağlanmalıdır. Veri kümelerinin controller içerisinde depolanması da yanlış bir davranıştır.
Görünüm Yapısı
Görünüm tarafındaki HTML elementlerini depoladığımız yapılara template denir. Template içerisinde sadece HTML kodları ve Angularjs direktifleri olmalıdır. İş kuralları bu kısımda tanımlanmamalıdır. Kurallar template tarafından erişilen controller içerisinde tanımlanmalıdır. Aksi taktirde görünümle alakası olmayan kural belirleme sorumluluğu controller tarafından alınıp görünüm tarafına yüklenmiş olur.
Görünüm tarafında sürekli güncellenmesi gerekmeyen içerikler için TwoWayBinding yerine OneWayBinding tercih edilmelidir.
Proje Dizin Yapısı
Proje yapısı şekillendirilirken dikkat edilmesi gereken bir diğer yapı ise proje dizin yapısının oluşturulmasıdır. Kod birimlerinizi HTML, CSS, JS gibi özelliklerine ve Angularjs yapılarına göre ayırmak ve dizinlere aktarmak sık kullanılan bir yöntemdir.
Yanlış Dizin Yapısı
Bütün controller dosyalarını Controllers dizini altında dizini altında toplamak, zamanla dizin içerisinde onlarca belki yüzlerce dosya birikmesine neden olacaktır. Bu durumda aradığımızı bulmak daha fazla zaman alacaktır. Örneğin bir EmailApplication projesi için GelenKutusu modülünün controller kodu Controllers dizininde aranacak ve görünüm için hazırlanan template kod dosyası ise Templates dizininde aranacaktır. Bu şekildeki proje tasnifi “türe göre tasnif” olarak adlandırılır. Türe göre tasnif edilen projeler zamanla projelerin karmaşık bir hal almasına neden olur.
Bunun yerine iş mantığına göre planlanmış bir dizin yapısı oluşturmak daha uygun bir yöntem olacaktır.
Uygun Dizin Yapısı
Email hizmeti ile ilgili iş kurallarını ve dosyalarını tabakalandırarak çalışmak daha uygun bir seçim olacaktır. Bu şeklide proje tasnifine ise “özelliğe göre tasnif” denir. Bu durumda Email listemizdeki kişilerle ilgili işlemlerin Contacts dizininde olduğunu özellik bakımından kolayca anlayabiliriz. Hem görünüm hem kullanım açısından sade ve anlaşılır bir yöntemdir.
Kodun organizasyon yapılandırması tamamen ekibinize veya size kalmış bir seçimdir. Bir dayatma söz konusu değildir. Temel nokta, kodun iyi bir şekilde ayrıştırılması ve ayrıştırılan bölümlerin yeni bir karmaşaya yol açmamasıdır.
Bu yazıda angularjs projeleri oluşturulurken dikkat edilmesi gereken önemli hususlardan bahsetmeye çalıştık. Umarım faydalı olmuştur. Bir sonraki yazıda görüşmek dileğiyle.
Bu yazıda angularjs ile proje geliştirirken REST servislere erişerek veri talep etmek için kullanılmak üzere hazırlanmış bir modül olan ngResourcemodülünü incelemeye çalışacağız.
ngResource modülü angular.js script dosyası içerisinde bulunmaz. Projemize ngResource modülünü dahil edebilmek için angular-resource.js javascript dosyasını projemize dahil etmeliyiz.
Modülü bağımlı modül olarak projemize ekleyerek uygulamamıza yükleyebiliriz. Yükeleme işlemini şu şekilde yapabiliriz.
angular.module('app',['ngResource']);
Yükleme işlemi gerçekleştikten sonra RESTful servislere erişmek için modül içerisinde bulunan $resource servisini kullanabiliriz. $resource servisi kendi içerisinde $http servisine bağımlıdır ve bu servis sayesinde sunucu ile iletişime geçebilir. $resource servisinin kullanım şekli kısaca aşağıdaki gibidir.
Burada {update: { method: “PUT” }} şeklinde özel bir fonksiyon tanımlanmıştır. Çünkü HTTP PUT metodu, $resource içerisinde standart bir kavram olarak ele alınmamıştır.
Diğer bir parametre olan {id: “@id”} ise URL adresinin sonundaki “/:id” ifadesini değişken hale getirmek için tanımlanmıştır.
Artık controller içerisinde $resource servisinin metodlarını kullanabiliriz.
Bu şekilde REST servisi işlemleri için her metoda karşılık bir controller oluşturmuş olduk. İsterseniz tek bir controller içerisine her HTTP metodu için bir fonksiyon da tanımlayabilirsiniz.
Angularjs ile asenkron işlemler gerçekleştirilirken kullanılan $promise nesnesine $resource servisi üzerinden erişmek de mümkündür.
Bir yazılım ürünü hakkında bilgi edinmek istediğimizde About(Hakkında) diyalog kutuları veya Readme(Beni Oku) metin dosyalarına bakarız. Bilgiler içerisinde yazılım adı, şirket adı, telif hakkı gibi bilgiler yanında yazılımın sürüm numaraları da bulunur.
Yazılım ürünü, bir masaüstü programı ise hakkında kutusu aşağıdaki gibi olacaktır:
internet explorer about box
Bir .Net kütüphanesi ise AssemblyInfo dosyasında versiyon numarası aşağıdaki gibi olacaktır:
.Net Kütüphanesi AssemblyInfo
Her iki durumda da versiyon numaraları noktalarla ayrılmış 4 adet sayıdan oluşmaktadır. Bazı yazılım ürünleri, 3 basamaklı şekilde gösterilmektedir. Öncelikle bu ifade şekillerinin ne anlama geldiğini bilmeliyiz ki yazılımın bize ne söylemek istediğini anlayalım.
sürüm numaraları
Genellikle 1.0.35.40 gibi dört sayıdan oluşan yazılım sürüm numaralarının her bir basamağı:
Basamak Major
Basamak Minor
Basamak Build
Basamak Revision
olacak şekilde ifade edilmektedir.
Burada 1.0.40 gibi üç basamaklı sürüm numaraları için bir not düşecek olursak:
Basamak Major
Basamak Minor
Basamak Revision
şeklinde ifade edilmektedir. Yani Build basamağı ihmal edilmiştir.
1 Major: Yazılım sürümünün ilk basamak numarası, büyük(major) sürüm numarasıdır. Bir yazılımın ilk ana sürümü için bu numara 1 olacaktır. Yazılımda köklü değişiklikler olduğunda bu versiyon numarası değiştirilir. Örneğin yazılım geliştirme sürecinde bir teknoloji değişikliği yapıldığında veya ana işlevlerde değişiklikler yapıldığı durumlarda major sürüm numarası bir arttırılır.
2 Minor: Yazılım sürümünün ikinci basamak numarası, küçük(minor) sürüm numarasıdır. Yazılımın çalışma şeklini değiştirmeyen yeni özellikler eklendiğinde, service pack gibi iyileştirici düzenlemeler yapıldığında minor sürüm numarası bir arttırılır.
3 Build: Yazılım sürümünün üçüncü basamak numarası, geliştirme sürecinde tamamlanan iterasyonları ifade eden sürüm numarasıdır. SDLC (Software Development Life Cycle) methodolojilerini uygulayan takım çalışmalarında Waterfall veya Spiral gibiiterasyon temelli döngüler tamamlandığında belli modüller oluşur. Her döngü tamamlandığında build sürüm numarası bir arttırılır.
4 Revision: Yazılım sürümünün dördüncü basamak numarası, düzeltilen hataların(bug) sayısını gösteren sürüm numarasıdır. Hiçbir yazılım mükemmel değildir. Gözden kaçan hatalı noktalarda yazılım istendiği şekliyle çalışmayacaktır ve bu noktaların düzeltilmesi gerekecektir. Her hata düzeltme işlemi sonrasında dördüncü sürüm numarası bir arttırılır.
Bugün 19 Ağustos 2015. Blog sayfam 4 yaşında. Geride bıraktığımız senelerde birçok yeni konuyu paylaşma fırsatı buldum. Olumlu olumsuz birçok eleştiri aldım. Bir o kadar yeni arkadaş edinme fırsatı buldum. Özelden gelen sorulara elimden geldiğince cevap vermeye ve sizlere yardımcı olmaya çalıştım. Özetle işin hakkını vermeye çalıştım.
Yazsam da yazmasam da zaman her türlü geçiyor. Yazmayı ve paylaşım yapmayı, geçen zamanı boş geçirmemek adına faydalı bir aktivite olarak görüyorum.
Sayfamı oluştururken belli bir yazı hedefi oluşturmadım. Fakat epeyce yazı ve yorum birikimi oldu. Bu bağlamda beni sürekli gelişime iten okuyucularıma da sonsuz teşekkürlerimi sunuyorum.
Önümüzdeki yılda yeni yazılarda buluşmak dileğiyle…
Entity Framework veya NHibernate veya benzeri ORM araçlarının Lazy Loading özelliği ilişkili tablolardan veri çekerken geliştiricilere büyük kolaylık sağlar. Her kolaylığın bir maliyeti vardır ve ilişkili tablolardan veri çekme işlemi sırasında oluşan maliyetin faturası veri tabanlarına yansıtılmaktadır. Bu yazıda veritabanlarından ilişkili veri çekimi sırasında ORM araçlarının nasıl sorgular oluşturduğunu incelemeye çalışacağız.
İlişkili Tablolar
Yukarıdaki şema Blog tablosuna bağlı birçok Article olabileceği gibi, Article tablosuna bağlı birçok Tag olabileceğini göstermektedir. (Veritabanı MsSQL Express’dir.)
Bu yapıya göre bir Blog altındaki Article listesini görmek istediğimizde ve her Article için kaç Tag olduğunu listelemek istediğimizde nasıl bir yol izlemeliyiz? Bunu Entity Framework kullanarak incelemeye çalışalım.
public class Blog
{
public int Id { get; set; }
public string Name { get; set; }
public virtual ICollection Articles { get; set; }
public override string ToString()
{
return string.Format("{0} ({1})",Name, Articles.Count);
}
}
public class Article
{
public int Id { get; set; }
public int BlogId { get; set; }
public string Title { get; set; }
public string Content { get; set; }
public virtual Blog Blog { get; set; }
public virtual ICollection Tags { get; set; }
public override string ToString()
{
return string.Format("{0} ({1} Tags)", Title, Tags.Count);
}
}
public class Tag
{
public int Id { get; set; }
public int ArticleId { get; set; }
public string Name { get; set; }
public virtual Article Article { get; set; }
}
public class BloggingContext:DbContext
{
public DbSet Blogs { get; set; }
public DbSet Articles { get; set; }
public DbSet Tags { get; set; }
}
Bu kısımda Entity Framework için veritabanı tablolarını temsil eden tipler oluşturulmuştur. App.config veya Web.config dosyaları içerisinde connectionString ayarlamalarını yaptıktan sonra BloggingContext nesnesi ile veritabanında işlemler gerçekleştirilebilmektedir. Bu işlem aşağıdaki gibi yapılmaktadır.
static void Main(string[] args)
{
using (var context = new BloggingContext())
{
foreach (var blog in context.Blogs.ToList())
{
Console.WriteLine(blog);
foreach (var article in blog.Articles)
{
Console.Write("\t");
Console.Write(article);
Console.Write("\n");
}
}
}
}
Run
Öncelikle Blog’lar listeleniyor ve parantez içinde her Blog türüne bağlı Article sayısı yazdırılıyor. Article satırına da her Article türüne bağlı Tag sayısı yazdırılıyor.
Bu işlem gerçekleşene kadar acaba veritabanında neler olup bitiyor? Bunu anlamak için Express Profiler aracından faydalanabilirsiniz. Express Profiler aracı veritabanına giden tüm sorguları yakalayabilen bir özelliğe sahiptir.
Kodumuzu çalıştırdığımızda Express Profiler penceresinde bir dizi işlemler raporlanacaktır.
Express Profiler
Entity Framework öncelikle veritabanının var olup olmadığını sorgular. Daha sonra ilgili tabloların olup olmadığını sorgular. Daha sonra MigrationHistory tablolarını sorgular. Derken bizi ilgilendiren kısım olan Blog listesini çeken sorguyu oluşturulur.
Bu sorgu sonrasında Blog listesindeki ilk Blog’a bağlı Article listesi seçilir.
Article listesi geldikten sonra ilgili Article için Tag listesi çekilir.
Bu işlem döngü şeklinde devam eder gider.
Şu anda listelediğim örnek tablolarda toplamda 10 veya 15 veri vardır. Bu işlem yüz binlerce kayıt barındıran tablolarda yapılmaya çalışıldığında epeyce maliyetli olabilir. Maliyeti düşürmek adına JOIN ile oluşturulabilecek ham SQL sorguları kullanmak daha ucuz bir yöntem olacaktır.
SELECT B.Name, COUNT(A.Id)
FROM Blogs as B
LEFT JOIN Articles as A
ON A.BlogId=B.Id
GROUP BY B.Name
ORM araçlarına savaş açmak yerine uygun ve yerinde çözümler üretmek hayat kurtarıcı olabilir.
