Arda Çetinkaya Yazılım ve arada kendim ile ilgili saçmaladıklarım…

vNext kavramı ile tanıştığımız Microsoft’un farklı işletim sistemlerinde de çalışan yeni framework’ü .NET Core ile ilgili önceki yazılarda birşeyler paylaşmaya çalışmıştım hatırlarsanız. Önümüzdeki günlerde RC1, 2016’nın ilk çeyreğinde de RTM versiyonun çıkması planlanan bu framework’e ben de ilerleyen zaman içerisinde biraz daha değinmek istiyorum. Bu zamana kadar çok fazla değinmek istemedim çünkü hala gelişmekte olan ve tam stabil halini almış bir versiyon henüz yok. Ama yavaş yavaş RTM’e yaklaştığımız için, yavaş yavaş ben de karalayabilirim sanırım artık.

.NET Core, Microsoft tarafından açık kaynak olarak geliştirilen, dışarıdan da katkı alan bir framework. Dolayısıyla tüm gelişme anına tanıklık edebiliyorsunuz. GitHub‘dan takip edip, siz de katkıda bulunabilirsiniz. Bunu özellikle hatırlattıktan sonra .NET Core içindeki Dependency Injection(DI) kavramından bahsetmeye çalışacağım. DI, .NET Core’un bir parçası olarak, ASP.NET 5’in de temel bir bileşeni olarak karşımıza çıkıyor. Tüm framework içerisindeki bağlılıkları yönetmek ve geliştirmek bu yeni yaklaşım ile beraber daha kolay bir hal alıyor. Kısaca ve basitçe yeni DI yaklaşımı ile .NET Core’da, tek bir yerde uygulamamızın bağlılıkları yönetebiliyoruz.  Farklı DI bileşenlerini de, bu yapının yerine geçebilecek şekilde kullanabiliyoruz tabi ki.

.NET Core içinde DI yapısı, Service Locator tasarım kalıbı ile tasarlanmış. Microsoft.Framework.DependencyInjection.IServiceCollection arayüzünden geliştirilen ServiceCollection üzerinden bağlılıklar oluşturuluyor. Uygulamalardaki bağlılıkları, uygulamaların kullandığı servisler olarak düşünebilirsiniz yani.

            var services = new ServiceCollection();

ServiceCollection sınıfı ile servisleri, yaşam döngülerine göre ekleyebiliyoruz.

            services.AddTransien<IUserService>(s=> new UserManagementService());
            services.AddInstance(typeof(IUserService),new UserManagementService());
            services.AddScoped(typeof(IUserService),s=> new UserManagementService());
            services.AddSingleton(typeof(IUserService),s=> new UserManagementService());

Bağlılıkları 4 tane farklı yaşam döngüsü ile tanımlayabiliyoruz.

  • AddTransient: Her seferinde bağlı nesnenin tekrar yaratılmasını sağlar
  • AddSingleton: Bağlı nesneye erişildiğinde tek bir nesne yaratılmasını sağlar
  • AddInstance: Her nest çağrısında, tanımlanan nesneyi sağlar
  • AddScoped: ServiceCollection’nın kapsamına göre nesnenin yaratılmasını sağlar.

Bu yaşam döngülere göre oluşturulan nesnelere; daha doğru isim ile servislere, IServiceProvider arayüzünden geliştirilen sağlayıcı sınıfı ile ulaşabiliyoruz.


            IServiceProvider provider = services.BuildServiceProvider();
            
            IUserService userService = provider.GetService<IUserService>(); 
            var userName = userService.GetUserName();

Yine tabi ki kendi sağlayıcı sınıfımızı yazmak mümkün. Sağlayıcı sınıfından gelen GetService() metodu ile bağlı olan nesneye/servise erişebiliyoruz.

VS Code

DI yeni ASP.NET 5 ve MVC 6’da built-in bir özellik olarak karşımıza çıkıyor. MVC tarafında çeşitlik konfigürasyon yöntemleri ile web uygulamalarındaki bağlılıkları yönetmek oldukça kolaylaşıyor. Bu yazıda bahsettiğim konunun örnek kodunu GitHub’a ekledim, buradan eklemeler ve düzenlemeler yapabilirsiniz diyerekten bitirelim.Bu giriş yazısı ile umarım biraz merak uyandırmayı başarmışımdır.

Bu yazıyı CoreCLR’ın Beta8 versiyonu ile yazdım. Bu versiyondan sonra Microsoft.Framework.DependencyInjection.* namespace’i Microsoft.Extensions.DependencyInjection.* olarak değişiyor.

 

Biraz geç oldu ama kaldığımız yerden devam edelim. Bir önceki yazılarda dağıtık sistemlerdeki yanılgılardan bahsetmeye başlamıştım. İlk 4 tanesini bitirmiş, geri kalanlarının üstünden de bir sonraki yazıda geçeceğimi belirtmiştim…İşte bir sonraki yazı.

8fallacies

5- Topoloji değişmez

(Topology doesn’t change)

NetworkTopologySistemleri oluştururken, ilk tasarımımız hiç değişmeyeceğini düşünmek bu yanılgıya düşmemizin en büyük sebebi. Hiç müdahale etmesek bile zaman faktörü bu değişikliğe sebep olacaktır. Bundan dolayı sistem tasarımlarımızı yaparken dış etkenlere dikkat etmemiz gerekir. IP değişiklikleri, hatta biraz daha kapsamlısı network değişiklikleri, firewall benzeri güvenlik katmanları ve benzeri fiziksel parçalar dağıtık sistemler tasarlarken mutlaka dikkat etmemiz gereken konular. Bu tarz fiziksel yapıların ayrılmış ve soyutlanmış olması çok önemli.  En basitinden “hard-coded” IP adresleri kullanıyor olmamız, değişen network’de problem yaratacaktır. Dolayısıyla DNS isimleri tercih edilmeli. İletişim protokolü olarak, daha esnek yapıların(mesela multicast) tercih edilmesi topolojideki değişikliklerden minimum derecede etkilenmemiz sağlayacaktır.

6- Sadece bir tane yönetici vardır

(There is one administrator)

system-admin-horrorKüçük sistemlerde belki bir tane “admin” gerçekten(?) vardır. Ama sistemler büyüdükçe ve dağıtık bir yapı oluştuğu zaman, bu sistemlerde yetkili olan; “admin” rolündeki kişi sayısıda artar. Bunun farkında olmadan, sistemin bir parçasında yapılan bir değişiklik ciddi sıkıntılara yol açabilir. Dolayısıyla sistemleri tasarlarken, birden fazla farklı sistem yöneticisi olabileceğinin farkında olmak lazım. Sistemin farklı bileşenlerine yapılan güncellemeler ya da patch geçişleri, geçildiği bileşeni iyileştirebileceği gibi o bileşeni kullanan diğer parçaları olumsuz etkileyebilir. Tabi bir sistemde ne kadar çok “admin” varsa o sistemde kordineli bir çalışma yapmak o kadar zordur. LDAP ya da Domain’de yapılan bir değişiklik, uygulama sunucusundaki “Authentication” modunu etkileyebileceği için, bu tarz değişiklikler tüm sistem yöneticilerinin kordineli çalışmasıyla yapılmalıdır.

 

7- Veri aktarım maliyeti sıfırdır.

(Transport cost is zero)

Veri aktarım maliyeti sıfır olsaydı gerçekten, “leased line” kavramı hayatımızda olmazdı. Dağıtık sistemlerin en önemli noktalarından biri, sistemler arasındaki verinin taşınmasının kolay olmadığı. Firmalar, dağıtık olarak tasarlardıkları sistemleri için özel network’ler kurup, network seviyesinde izole olmak için binlerce dolar harcıyor.  En basitinden böyle düşünürken maliyet sıfır değil. Ama buradaki maliyet sadece bu değil.  Günümüzde artık veri aktarırken 1sn.’nin üzerinde bir zaman problem olabiliyor. Bu zaman kavramı işte maliyetin diğer bir ayağı. Mesela network’de taşınan verinini serialization ve deserialization işlemlerinin uzun sürmesi(-ki uzun sürer) bu zaman maliyeti için önemli bir noktadır. Ama çok farkında olmayız… Bu noktada hem yazılım, hem donanım maliyetlerine dikkat edebildiğimiz, kontrol edip yönetebildiğimiz sistemler tasarlayabilmek önemli. Her ne kadar donanımsal olarak ölçeklendirebilsekte, aynı şekilde yazılımsal olarakta ölçeklendirebileceğimiz aktarım yöntemlerini düşünmemiz mutlaka gerekecektir.

8- Ağ homojendir

(The network is homogeneous)

Günümüzde artık hiç bir network homojen değil.  Tüm sistemlerin homojen olabileceği yanılgısına sanırım artık kimse düşmüyordur. Düşen varsa da, umarım biran önce farkına varır gerçeklerin. Artık öyle bir zamandayız ki, sistemlerin bir kısmı Java olurken, başka bir kısmı .NET, başka bir kısmı ise node.js olabiliyor. Veri platformu olarak Oracle tercih eden bir sistem, NoSQL veri platformunda herhangi bir ürünü kullanan sistemle beraber çalışabiliyor. SOAP mesajları alan bir sistem, başka biriyle JSON ile konuşuyor. Dolasıyla sistemleri tasarlarken bu gerçeklerin farkında olmak lazım. .NET’in ilk zamanlarında *.asmx servislerinin java ile uyumsuzluğu bir çok kişinin yaşamış olduğu bir problemdir diye düşünüyorum. Dağıtık sistemlerin farklı özelliklere sahip bileşenler ile geliştirilebileceğini ve bu bileşenlerin birlikte çalışabilmesinin sağlanması oldukça önemli. Yoksa dağıtık sistem olmasının bir önemi olmuyor zaten…

Umarım biraz olsun faydalı olmuştur ve bazı noktalara neden dikkat etmemiz gerektiğini anlatabilmişimdir. Daha az yanılgıya düştüğümüz sistemler dileyerek kapatalım konuyu…Kapattık…

Bir kaç önceki yazımda dağıtık sistemler ile ilgili bir şeyler karalamaya çalışmıştım. Daha çok kurumsal oluşumlarda büyük ve orta ölçekli çözüm ve sistemler, dağıtık sistemlere benzerlik gösterse de, Cloud kavramı ile çeşitlenen yazılım çözümlerini anlamak, hatta bu çözümlerin bir parçası olmak için temel bir kaç anahtar kelimeyi bilmek ve anlamak gerekiyor diye düşünüyorum. Bu yüzden dağıtık sistemler ile ilgili bir kaç şey daha karalayacağım, bir önceki yazının sonunda belirttiğim gibi…

Büyüyen ve gelişen teknoloji dünyasında, kompleks problemlere çözüm sağlarken çoğu zaman büyük yanılgılar içerisinde olabiliyoruz. “Yaaa onun olması zor, milyonda 1 ihtimal” diye atladığımız bazı yazılım kavramlarının saniyede 3 milyardan fazla iş yapabilen işlemcilerde çalıştığını unutuyoruz. Problem olana kadar bu yanılgıların çok farkında olamıyoruz genellikle. Özellike birden fazla parçadan oluşan dağıtık sistemlerde bu yanılgılar daha fazla oluyor. 90’larda Peter Deutcsh‘ın ortaya çıkardığı “The Eight Fallacies of Distributed Computing”, günümüzde hala çoğumuzun yanılgıya düştüğü konular olarak karşımıza çıkıyor.

8fallacies

Her ne kadar dağıtık sistemler için söylemiş olsa bile, günümüzdeki çoğu yazılım çözümleri için dikkat edilebilecek başlıklar olduklarını düşünüyorum. Açıkcası sadece bu yanılgılardan bahsetmek istemiyorum, bu yanılgılara düşmemek için çözümlerimize farklı nasıl bakabilir ile de kafanızı biraz karıştıracağım. 🙂

1- Network güvenilir…

(The network is reliable)

cayb0İş yerlerinde, yerel ağ içinde olduğumuz ve genellikle sahip olduğu kapasite zorlanmadığı için network’lerin sağlam olduğu, problem yaşanmayacağını düşünürüz. Donanım olarak artık switch’ler ve router’lar farklı özellikler ile bu problemleri çok hissettirmese de, her zaman sağlam bir network üzerinde çalışacağız diye kesin bir yargı yok. En basitinden, bilinçsizce sökülen güç kabloları yaşanan şeyler…Network üzerinde farklı sistemlerin bir araya gelmesi ile oluşan çözümlerde özellikle, network problemleri ciddi sorunlara yol açabilir. Dolayısıyla network güvenilir değil…

Bu yanılgıya düşmemek için yazılımlarımızda çeşitli iyileştirmeleri başta geliştirebiliriz. Mesela kaçımız web servis request’lerinde HttpTimeoutException‘ı dikkate alıp, bir retry mekanizması oluşturuyor. Ya da ACK/NACK(acknowledge messages) yapısı kurup, request’lerin sağlıklı gittiğini doğruluyor… Network’ün güvenilir olduğu yanılgısı içerisinde olursak, en basitinden bir e-ticaret sitesinden bir bankaya yapılan request’de oluşan timeout’ları atlayabiliriz. “Yapılan işlemler başarılı mı yapıldı, ya yapılmadıysa…Bir daha request yapalım o zaman…Ama ya başarılı olduysa, çift işlem olmasın…”

2- Network’deki geçikme sıfır…

(Latency is zero)

impossibruLatency” olarak adlandırılan bir kavram vardır; bir verinin bir noktadan, bir diğer noktaya taşınmasında geçen süreye denir. Ve ne yazık ki bu süreyi sıfıra yakın varsayarız genelde… Genelde lokal network’lerde(LAN) çalıştığımızdan böyle bir yanılgıya sahip oluyoruz. Geliştirdiğimiz uygulamalar internet üzerinde çalışacak ya da geniş bir kapalı network’lerde çalışacaksa, mutlaka ama mutlaka performans testi yapmalıyız. İstanbul’da LAN’da sorunsuz çalışırken, internete açtığınız uygulamaya 1 milyar nüfuslu Çin’den erişmek istediklerinde network’deki git-gel’lerden dolayı kesin problem yaşarsınız… Ben şimdiden söyliyim…

Mesela bir örnek olması için; genelde uygulama ve veri tabanı arasındaki iletişim bu açıdan problem yaratır. O/R Mapping araçları ile lazy-loading kavramı hayatımıza girince, uygulama-veri tabanı arası git gellerin artması network’de geçikme problemlerine sebep olabilir. DTO’ların varlık sebeplerinden bir tanesi de bu problem zaten… Bundan dolayı sadece ihtiyacımız olduğu zaman network’e çıkmalıyız, çıkmamız gerektiği durumlarda da kullanacağımız verinin hepsini almalıyız.

Devam

Bulut bilişim ile yazılımların, servis olarak her yere ve herkese ulaşabilmesinden sonra, her cihazın internete bağlanabilecek olması, önümüzdeki 5-10 yılın teknolojik olarak sanırım en büyük olayı. Sosyal medyanın öncülüğünde zaten insanoğlu 7/24, bir birine bağlı bir hale girdi. Dakikalar hatta saniyeler mertebesinde, bu teknolojiyi benimsemiş kişilere ulaşmak mümkün. Kısacası artık herkes “online” olmaya başladı.

IoTBunun bir sonraki adımı, kullandığımız cihazların da “online” olmaya başlaması. Internet of Things(IoT) yani nesnelerin interneti dediğimiz bu kavram ile; teoride, günlük hayatta kullandığımız bir çok elektronik ve mekanik cihaz internet üzerinden erişebilir ve yönetilebilir olacak. Hatta hatta bir birleri ile internet üzerinden konuşabilecek olacaklar. İçerisindeki malzemelere göre size ne yemek yapabileceğinizi öneren ya da içerisindeki azalan domatese göre yeni sipariş veren buzdolabı, eve geliş saatinize göre klimayı ya da kombiyi açan akıllı ev sistemleri, arabanızda oluşan arıza için otomatik olarak servisten randevu alan arabalar ve daha bir çok benzer değişik sistem IoT adı altında hayatımıza girecek. Bir çoğu girmeye başladı bile hatta.

Hayatımızı kolaylaştıracak şeyler olsa da, daha farkına varmadığımız bir çok problemi de getirecekler tabi ki. Güvenlik konuları daha fazla önem kazanacak. İnternet üzerinden bir şekilde erişime açık olan bu cihazların güvenliği bir noktada en büyük endişe noktamız olacak belki de… Düşünsenize, internette bağlı çamaşır makinanız, hack’leniyor ve en sevdiğiniz tişörtünüz yıkanırken çekiyor ve küçülüyor…Eyvahlar olsun… 🙂

Her cihazın internet üzerinden iletişim içerisinde olması ve yönetilebilir olması, yazılım açısından da yeni yaklaşımları ortaya çıkaracak. Yine bize iş yani… Yazılım açısından yeni kavramların, yeni problemlerin ve çözümlerin hayatımıza girecek olması heyecan verici. Bütün bunların içinde olabilmek, içinde olmasak bile neler olup bittiğini takip etmek bir yazılımcı için ayrıca önemli. Son 10 yılın en popüler mesleklerinden biri olan “yazılım geliştirici”, şimdi herkesin yazılım yapabilecek konuma geliyor olmasından dolayı daha farklı bir duruma geldi diye düşünüyorum.  Ciddi anlamda bu konuda çok becerikli bir nesil geliyor çünkü…

Ey yazılımcı, eğer doğal seleksiyonla elenmek istemiyorsan, zaten sahip olduğun becerileri korumak ve geliştirmek durumundasın. 🙂

Raspberry Pi ve hareket sensörüNeyse…Bütün bunları yazmamın sebebi, neler olup bittiğini merak edip, küçük bazı projeler geliştirmek istemem aslında. Hobi amaçlı ya da belki değil… Yeni çağın, yetişkinlerin oyuncan anlayışı belki de. Bunları da GitHub üzerinden paylaşmaya çalışacağım, hani takip edip öğrenmek isteyen olur belki diye… İnternet üzerinde yüzlerce kaynak var, eğer sizde IoT falan ilgileniyorsanız, küçük bir merakınız varsa bir göz atın derim.  Ben Raspberry Pi ve bir kaç sensor ve Azure ile başladım… Sizde başlayın, geliştirin, paylaşın…Zevkli…

 

Bonus…

Direkt konu ile alakalı değil belki, ama önümüzdeki yıllar için bizi neler bekliyoru başka bir açıdan yorumlayan bir video paylaşmak isterim. Biraz heyecanlanacak, biraz moraliniz bozulacak belki ama 15 dakikanızı ayırmanızı tavsiye ederim…

Dağıtık SistemlerBulut bilişim kavramı son bir kaç yılın, hatta gelecek bir kaç yılın da en önemli yazılım kavramlarından bir tanesi. Tanışma fırsatı elde etmediyseniz, çok yakında yollarınız kesişecektir zaten. Ama biraz öncesine gidip, “cloud-computing“(bulut bilişim)’in de bir parçası hatta belki temeli olarak yorumlanabilecek “distributed system“den (dağıtık sistemler) bahsetmek istiyorum. Cloud, biraz daha pazarlama üzerine ortaya çıkan bir kavram olduğu için, temelinde yatan “dağıtık sistemler” kavramlarının bazen atlandığını düşünüyorum. Bundan dolayı, eski konulara gidip biraz daha temellerden bahsetmek ihtiyacını hissettim…

Dağıtık sistem…

Ortak bir amaç için, çeşitli iletişim protokolleri ile birbirleri ile iletişim halinde olan birden fazla yazılım sisteminin oluşturduğu sistemlere dağıtık sistemler diyoruz. Basit olması ve daha kolay anlaşılması adına, multi-player bilgisayar oyunlarını örnek verebilirim. Tek bir bilgisayarda bir oyunu, aynı anda 100 kişi oynamaya çalıştığınızı düşünün…Yemez, ayy pardon olmaz… 🙂 Bunun  için ne yeriniz, ne işlem gücünüz ne de zamanınız yeterli olacaktır. Ama bir çok bilgisayar ile, farklı lokasyonlardan yüzlerce kişi ile, büyük bir işlem gücü ile oyunun en zor bölümünü daha rahat bir şekilde geçebilirsiniz.

Bir dağıtık sistem anatomisi…

Dağıtık sistemler ile, pratikte tek bir işlem gücüyle yapılabilecek işleri daha büyük ölçekte yapabilmek amaçlanır. Geliştirilen yazılım sistemlerinin belli bir süreden sonra çeşitli problemlere çözüm sağlayamaması, bu yazılım sistemlerini değiştirmeyi ya da genişletmeyi gerektirir. En basitinden CPU, RAM ve disk boyutu arttırma gibi fiziksel değişiklikleri düşünebiliriz. Hem ekonomik, hem de teknolojik bazı kısıtlamalardan dolayı ne yazık ki bir bilgisayara sınırsız CPU ya da hafıza eklemeniz mümkün değil. Teknolojik kısıtlarına gelene kadar, ekonomik olarak zaten herkes zorlanacaktır.

Dağıtık Sistemler

Zamanla birden fazla kullanıcı ile de problemlere çözüm sağlama ihtiyacımızdan dolayı, belli bir ağ içerisinde birbiri ile iletişim halinde olan bilgisayarları devreye almaya başlarız. İşte bu noktada artık merkezi sistemimizi dağıtmaya başlamış oluyoruz. Yeni problemlere de merhaba diyoruz tabi ki. Bu problemlere sonradan geleceğim…Şimdilik devam edelim.

Birbiri ile iletişimde olan farklı bilgisayarların iletişimlerini sağlıklı yapabilmesi için, belli protokoller radarımıza girer. Sistemimizi buna göre geliştiririz. Bazen bu protokoller yeterli olmaz ya da farklı ihtiyaçlar ortaya çıkar, dolayısıyla farklı yeni protokoller ile de iletişim sağlayacak ara katmanlar yapmamız gerekir. Fazla bileşen ve farklı sistemler olunca güvenlik konuları da ortaya çıkar. Hem iletişimin, hem de yapılan işlemlerin güvenilir olmasını sağlamak birden öncelikli olur.

Bir bakmışız, sistemle büyüyen ve gelişen iş ihtiyaçları artık farklı coğrafyalarda da sistemin 7/24 çalışmasını gerektirir. Farklı coğrafyalarda, aynı verinin güvenli bir şekilde iletilmesi ve işlenmesi gibi bir durum ortaya çıkar. Bütün bunları yaparken de, bu ayrı sistemlerin hata durumlarını yönetebileceğimiz bir senaryomuz ve hatta belli ölçekte yedek ikinci sistem ihtiyaçlarımız ortaya çıkar…

Basit olarak neden dağıtık sistemlere ihtiyaçımız olduğu ortaya çıktı aslında. Biraz daha canlanması adına havayolu yönetim sistemleri, multi-player bilgisayar oyunları, tedarik zinciri sistemleri ve ödeme sistemleri günümüzde hepimizin karşısına çıkan dağıtık sistem örnekleri olarak düşünülebilir. Hatta son zamanlarda oldukça popüler olan yazılım mimari stili olan Microservices yaklaşımı da, bu dağıtık sistem modellerinden biridir. Neyse…Şimdi tekrar oraya girmeyelim.

Karakteristik özellikleri…

Dağıtık sistemler ortaya çıktıkça belli özellikleri sağlamak ile yükümlü olurlar. Bu karakteristik özellikleri sağlıyor olmak, dağıtık sistemlerin en büyük ve en zor problemidir.  Önce bu özelliklere bir bakalım, sonra gerçekten sağlamak mümkün mü bakarız…

  • Yüksek Erişebilirlik: Dağıtık sistemlerin, erişebilirliğinin olabildiğince yüksek olması beklenir. Başarısız bir işlem olsa bile, işlemi tetikleyen kaynağın mutlaka sisteme bir şekilde erişimi olması beklenir.
  • Güvenlik: Dağıtık sistemlerde, işlemlere ve veriye erişim yetkilendirilir.
  • Performans: Dağıtık sistemlerin, kendi performanslarının farkında olması beklenir. Belli sistem yoğunluklarında alacağı aksiyonların belirli olması sistem tasarımında önemlidir.
  • Açıklık: Dağıtık sistemler genişletilmeye açık olmalıdır. Sisteme kolaylıkla alt sistem bileşenleri eklenebilmelidir.
  • Ölçeklenebilirlik: Dağıtık sistemler kaynak kullanımı konusunda kolayca ölçeklenebilmelidir. Kaynak kullanımına göre sistemin verimli çalışmaya devam etmesi bir şekilde sağlanmalıdır.
  • Tutarlılık: Sistemin tutarlı olması beklenir. Aynı anda, aynı veri kaynağına erişen sistemlerin uyumlu ve tutarlı çalışması gerekmektedir.

Bu özelliklere sahip olmak ve bunları belli bir kalite düzeyinde sağlamak oldukça zor. Hatta hepsinin birden sağlanamayacağına dair teoriler olsa da sonradan farklı yaklaşımlarda olmuştur. Eric Brewer’ın CAP teorisi ve sonrasındaki yaklaşımına göz atmanızı tavsiye ederim. (CAP Twelve Years Later: How the “Rules” Have Changed)

Dağıtık sistemlerin bu karakteristik özelliklerinden dolayı, çeşitli programlama yaklaşımları, prensipler ve kalıplar bu sistem tasarımlarında kullanılmaktadır. SOA prensipleri, mesajlaşma kalıpları, kuyruklama alt yapıları, senkron ve asenkron programlama modelleri dağıtık sistem programlama yaklaşımlarında temel olarak tercih edilen bir kaç kavramın başında gelir.  Tabi sistemin amacına göre başka farklı kavramlar da gündeminize girecektir. “Service Bus”lar, “Message Broker”lar falan filan…

Dağıtık sistem tasarlarken ya da bir şekilde içinde bir geliştirme yaparken, yukarıda bahsetmiş olduğum özellikleri sağlamanın da vermiş olduğu bir kaç yanılgıya düşeriz. Peter Deutsch, zamanında bunları çok güzel tanımlamış ve “The 8 fallacies of distributed systems” diye yazmış. Bir sonraki yazılarda bu yanılgıların ne olduğunu ve bu yanılgılardan nasıl kurtulabiliriz bunları anlatmaya çalışacağım…Şimdilik bu kadar. Fazla dağıtmayın… 🙂

Az biraz beni takip edenler, özellikle Twitter ve Instagram‘dan, yaklaşık 2 yıldır yelken ile haşır neşir olmaya çalıştığımı hatırlarlar. Hatta geçen sene yine bu zamanlar  “Büyük Yarış” yazısını ile kesinlikle unutamayacağım bir yelken yarışından bahsetmiştim… Bu sene de, yine kesinlikle unutamayacağım, unutamayacağım gibi; ileride, yaşlanınca dönüp dönüp aynı şeyi anlatacağım bir yarış haftasında buldum kendimi.

Ülkenin kara suları yetmedi, biz de Garanti Bankası Yelken Kulübü olarak İngiltere’ye Cowes Week‘e gittik. Cowes Week,  1826‘dan beri düzenlenen dünyanın en eski yelken yarışlarından biri.  Günde 40’a yakın yarış, 1000 küsur yelkenli tekne ve binlerce yelkenci… Toplam 7 gün aralıksız, gün boyu yarışlar ile oldukça efor da gerektiren bir yarış. Coğrafi olarak gerçekleştiği yer, İngiltere’nin güneyinde Isle Of Wight adasında Cowes kasabasında, denizde de Solent bölgesinde… Rüzgarından çok akıntıları ile meşhur bir yer. Rüzgar problemi yetmezmiş gibi bir de akıntı derdi var yani… Kısacası uzun süre yelken ile uğraşanlar için bile oldukça heyecan verici. Benim gibi 2 yıldır uğraşmaya çalışan biri için ise uzaya çıkmak gibi birşey…Ki cidden öyle oldu…

 

IMG_1643

DirekYelken takımımızda daha önce, 2012’de yine bir Cowes Week tecrübesi olduğu için, hazırlanma sürecim düşündüğümden daha rahat oldu. İlk bu yarışa katılacağımız belli olduğu zaman, görev dağılımı yaptığımızda, “ahaaaa s.çtık” dedim. Daha önce hiç bilmediğim bir teknede, daha önce hiç yapmadığım bir görevle karşı karşıya kalmıştım… Bowman, bizdeki adı “Başüstü Adamı“.  Ama İngiltere’ye gidiyoruz ya, gazım… Her türlü atraksiyona açığım. Yemişim baş üstünü… Yarışacağımız teknenin aynısını burada bulma şansını elde edip, bir kaç antreman yapma şansımız oldu. Takım arkadaşlarımın desteği ve yardımları ile beni nelerin beklediğini önceden az çok kestirebildim. Burdan tekrar hepsine bir daha teşekkür edim…

Marina

Yarışlar başlamadan 1 gün önceden adaya gittik ve yarışmak için kiraladığımız tekneyi aldık. Yol yorgunluğu falan dinlemeden, hemen bir tekneyi tanıyalım turu ile son antremanımızı yaptık.  Ortamın verdiği heyecan ile çok iyi bir antreman olmasa da, yarına hazırdık…

VOROrtamın verdiği heyecan diyorum, çünkü Cowes kasabası hazırlıklarını çoktan bitirmiş. Kasaba yarış haftasından dolayı oldukça kalabalıktı. Bizim teknenin olduğu marinada yüzlerce tekne, denizde de bir o kadar tekne… Kasabadaki yelken dükkanları, restoranlar, kafeler ve organizasyon firması çeşitli alanlar ile hazırlıklarını bitirmiş tam bir festival havası oluşturmuşlar. Yarış için gelen binlerce insan da olunca, insan gerçekten heyecanlanıyor.Gelen ekipler de oldukça profesyonel, ünlü yelkencilerden ve teknelerden oluşan ekipler. Ortam bayaa ciddi yani… Bu seneki Volvo Ocean Race yarışından kadınlar takımı Team SCA, Donfeng, dünyaca ünlü yelkenci Alex Thomson ve benim daha bilmediğim yüzlerce profesyonel takım ve kişi…Ne işim var lan ben burada….

 

Alan

İlk gün gelip çattığında çeşit çeşit tekne, hepsi kendi sınıfında yarışmaya hazır; Start çizgilerine doğru sabahtan yol alıyor. Gün içinde farklı sınıflar için farklı start’lar ile birden fazla yarış var. Ve bu yarışların rotası, start’dan 10-15 dakika önce telsiz ve sms ile paylaşılıyor. Ahaaa da başka bir heyecan…Nereye gideceğiz ulan…

Yarış

İlk gün heyecanı ile ilk yarışımızı oldukça güzel bir havada yaptık. Problemsiz ve güzel bir yarış oldu. Hem yarış havasını soluduk, filodaki rakiplerimizi tanıdık, hem de tekneye alıştık… Ben mi?

Kendi adıma ilk günü atlattıktan sonra oldukça rahatladım. Problemsiz ve rahat bir yarış oldu benim için. A2 balonu donat, sancaktan balon indireceğiz,  yok iskeledeki iskotayı al, izbarço at, kavançaya hazırlan, balon mandarına dikkat et derken temel şeyleri oturtmuştum. Haaa 7 gün boyunca, yapmadım hata… Tabi ki yaptım, hem de en güzellerini yaptım. Ama öğrendim… Bu açıdan da bu yarış haftası benim adıma çok anlamlı oldu. Yelkende yarış atmosferinde en zevkli pozisyonun baş üstü pozisyonu olduğunu düşünüyorum. Neyse “lessons learned” yapmayacağım size.

Devam

Windows 10 ile beraber, Microsoft yeni bir browser duyurdu bildiğiniz üzere. Önceleri Project Spartan kod adı ile anılan daha sonra resmi olarak Microsoft Edge ismini alan bu browser, Windows 10’nun en çok merak edilen uygulamalarından biri. Dolayısıyla en çok konuşulan, bundan dolayı da en çok yanlış anlaşılmaya sebep olan konusu… Bakalım bizi neler bekliyor…

Microsoft bu yeni browser(Microsoft Edge) ile gerçekten Internet Explorer’ı öldürüyor mu?

Bu sorunun cevabı, şimdilik hayır. Windows 10 ile beraber Internet Explorer kullanmaya devam edebileceğiz. Yani basitçe Windows 10’da Microsoft’un desteklediği iki browser olacak.

Internet Explorer 11Internet Explorer 11, uygulamaların uyumluluk gereksiniminden dolayı bir süre daha ortalıkta olacak. 2016’nın Ocak ayından sonra IE 11 dışındaki tüm diğer versiyonlara destek kalkacak. 2018’den sonra da IE 11’e olan destek kalkacak. Ama “extended” olarak adlandırılan destek 2023’e kadar devam edecek. Sadece güvenlik yamaları ile güncellenecek IE 11, yeni özellikler ile zenginleştirilmeyecek. Internet Explorer’ın hala yaşayacak olmasının sebebi de, hali hazırda kurumsal tarafta olan uygulama uyumluluğu ve diğer Windows sürümlerinin yaşayacak olması.

Peki bu “Microsoft Edge” ne?

Microsoft EdgeEdge kavramı aslında, HTML 5, ES6, CSS 3.0 ile farklılaşan web teknolojilerinden ortaya çıkan bir uyumluluk kavramı. Internet Explorer’ın güncel versiyonlarında, “document mode” kavramından da hatırlayanlar ya da bilenler olacaktır. Windows 10 ile beraber, bu yeni nesil standartlar artık varsayılan özellikler olarak Microsoft Edge tarayıcısı ile özerkliğini kazanıyor. Farklı bir alt yapı ile çalışan Microsoft Edge tarayıcısı, Windows 10 ile beraber Microsoft’un yeni standart tarayıcısı olacak.

Biraz daha derinlere inelim… Internet Explorer, MSHTML olarak adlandırılan bir görüntüleme motoruna sahip. Kısaca IE’deki tüm alt yapının adı MSHTML(Trident diye de biliniyor). Microsoft Edge ile beraber, bu alt yapı ciddi bir şekilde yeniden düzenlenip/yazılıp EdgeHTML olarak adlandırılıyor. Bu alt yapı, güncel tüm web standartlarını destekleyecek şekilde geliştirildiği için yeni nesil web uygulamaları için doğal olarak daha başarılı.

EdgeHtml

Internet Explorer’da olan MSHTML, kısmen de olsa Edge modu ile yeni nesil uygulamalara destek verebilmekte. Ama artık eski bir kod tabanı olduğundan, sürekli gelişen,yeni standartlara destek olması zor. Bundan dolayı da Internet Explorer’ın edge modu, Windows 10’daki Microsoft Edge ile aynı denklikte değil. Yani basitçe, Windows 10’da, Internet Explorer 11’i edge modunda kullanmak ile Microsoft Edge tarayıcısını kullanmak aynı şey değil.

Internet Explorer ve Microsoft Edge arasındaki en büyük farklılıklardan bir tanesi de Silverlight desteği. Microsoft Edge’de Silverlight desteği olmayacak. Dolayısıyla eğer Silverlight’a hala yatırım yapıyorsanız, bir kere daha düşünün.

Kısacası Microsoft Edge, Windows 10’nun karakteristik özelliklerine ve yeni nesil web standartlarına uygun ve bunları temel alarak geliştirilmiş bir tarayıcı. Standart internet tarayıcılarından farklı olarak sunduğu fonksiyonlar ile Windows 10’nun en önemli uygulaması olduğunu düşünüyorum. Tarayıcı rekabetine yeni bir soluk getireceği kesin. Ama ne yazık ki bu rekabet, bize, web uygulamaları geliştirenlere, tasarımcılara vs. yeni problemler yaratacak, benden söylemesi 🙂

Şimdilik bu kadar. Umarım biraz netleşmesi adına faydalı olmuştur. Bakalım ilerleyen zamanlarda daha neler olacak…