Arda Çetinkaya Yazılım ve arada kendim ile ilgili saçmaladıklarım…
Internet Of Things(IoT) konuları hobi olarak takip ettiğim, evde boş zamanlarımda kendimce bir şeyler yapmaya çalıştığım bir konu. Uzun süredir beni takip edenler, ara sıra paylaşımlarımdan fark etmiştir zaten. Hatta basit bir çalışma ile de bir şeyler paylaşmaya çalışmıştım. “Maket yapma” hobisinin yeni nesil versiyonu gibi sanırım. Mevcut yazılım bilgilerim ile de birleştirince açıkçası yaptığım şeylerden daha fazla keyif alıyorum. Bir şeyler paylaşarak, biraz olsun ilham vermek, benden daha fazla bu konulara ilgisi olanlara fikir vermek adına bir şeyler paylaşmak istiyorum.

Geçen gün Twitter’dan bir tweet paylaşmıştım. Yeni bir yazının yolda olduğu mesajı ile beraber. Ahaaa da işte bu o yazı 🙂 Buyrun başlıyoruz…

Bu küçük ve basit projeden bahsederek, Internet Of Things(IoT)’in ne olduğu, neleri nasıl yapabiliyoruz, bunu bir “konsept” olarak anlatmaya çalışacağım.

Öncelikle projemiz Raspberry Pi(3) üzerinde; Windows IoT Core ile basit bir sıcaklık ve nem ölçer. DHT11 sıcaklık sensörü ile ortamdaki sıcaklığı ölçüp, I2C üzerinden bir LCD(16×2) ekrana bunu yazdırıyoruz. Aynı zamanda Azure IoT Hub servisi üzerinden bu bilgiyi düzenli aralıklar ile Microsoft Azure’a aktarıyoruz. Kullandığım sensör, bunların bir biri ile bağlantısı ve bunları nasıl alabilirsiniz gibi konuları yazının sonunda bulabilirsiniz. Şimdilik bunlara takılmayalım.

Nem ve sıcaklık ölçen Raspberry Pi cihazımızı basit bir IoT cihazı olarak düşünebiliriz. Bu cihazın üzerinde Windows IoT Core çalışıyor. Dolayısıyla UWP tipinde bir uygulamayı bu cihazın üzerinde geliştirip, çalıştırabiliyoruz. Window IoT Core’da çalışacak uygulamamız bir Background Application(IoT) uygulaması olacak. Dolayısıyla projemizi seçerken buna göre seçmek gerekecek. Tabi öncelikle proje şablonunu yüklemek gerekecek. Yüklemek için Visual Studio Market Place‘e gitmeniz yeterli.

Projemize başlamadan önce, geliştireceğimiz senaryo için aşağıdaki NuGet paketlerini de projemize eklememiz gerekecek.

Dht, sensörümüzü kullanabilmemiz için gerekli kütüphane, Microsoft.Azure.Device.Client, IoT cihazımızın Azure IoT Hub ile iletişim kurmasını sağlayan kütüphaneler. Microsoft.NETCore.UniversalWindowsPlatform ise Windows IoT Core için temel kütüphaneleri barındırıyor. Bu zaten projeyi yarattığımız zaman otomatik olarak geliyor.

Projeyi yarattıktan sonra aşağıdaki gibi bir metoda sahip bir sınıf oluşacak.

    public sealed class StartupTask : IBackgroundTask
    {
        public void Run(IBackgroundTaskInstance taskInstance)
        {


        }

    }

IBackgroudTask arayüzünden oluşturulan bu sınıf, Windows IoT Core’da arka tarafta çalışan uygulamalar için başlangıç noktası. Run() metodunun içerisinde bütün gereksinimlerimizi yazabiliriz. Bizim projemizde de burası giriş noktamız.


        public void Run(IBackgroundTaskInstance taskInstance)
        {

            //Attach to cancel event to cancel if it is needed;
            taskInstance.Canceled += TaskInstance_Canceled;
            _deferral = taskInstance.GetDeferral();

            _deviceClient = DeviceClient.CreateFromConnectionString(_deviceConnectionString);

            //Thread timer to check sensor data
            _periodicTimer = ThreadPoolTimer.CreatePeriodicTimer(new TimerElapsedHandler(PeriodicTimerCallback), TimeSpan.FromSeconds(60));

            //Init PINs and LCD 
            _pin = GpioController.GetDefault().OpenPin(4, GpioSharingMode.Exclusive);
            _screen = new displayI2C.LCDisplay(DEVICE_I2C_ADDRESS, I2C_CONTROLLER_NAME, RS, RW, EN, D4, D5, D6, D7, BL);
            _screen.Init();

        }

Burada bir kaç önemli satırın üzerinden geçerek bazı şeyleri netleştirmek isterim. Öncelikle uygulamamızın Azure IoT Hub ile iletişimini sağlayan DeviceClient sınıfı üzerinden sağlıyoruz. 8 satırda, bu cihazımızı oluşturuyoruz. Azure tarafında oluşturduğumuz cihaz bilgileri ile cihazımız bu sınıf üzerinden eşleşiyor. Cihazımızın Azure IoT Hub ile iletişimini sağlamak için öncelikle Azure IoT Hub üzerinde bir Hub yaratıp, daha sonra cihazımızı Provision etmemiz lazım. Bunlar ile ilgili daha ayrıntılı linkleri yine aşağıda paylaşacağım. Azure IoT Hub üzerinde tanımladığımız Hub bilgileri içerisinde bir ConnectionString bilgisi var. Bunu DeviceClient.CreateFromConnectionString() ile kullanıp cihazımızı Hub ile eşleştiriyoruz. Burada önemli bir nokta var, bizim senaryomuzda Hub’ın Azure Iot Hub tarafında yaratılmış olduğunu varsaydık. Eğer orada yaratmadıysak, kod tarafında önce Hub’ı yaratan bir geliştirmemiz lazım.

TheadPoolTimer ile sensörleri ne kadar bir sürede kontrol edeceğimizi belirtiyoruz. Daha sonra Raspberry Pi tarafındaki PIN’leri ve LCD ekranımızı tanımlıyoruz. LCD ekranı için yine bir kütüphane kullandım.

Read More

Geçtiğimiz hafta SignalR‘ın ASP.NET Core için Alpha(2) versiyonu yayınlandı. ASP.NET Core için baştan yazılan ve bazı önemli değişikliklere sahip olan bu yeni versiyon, açıkcası şu an PROD ortamlar için bence çok yeterli değil. Ancak .NET Core’un gelişim süresini göz önüne alınca yeni SignalR’ın da hızlı bir şekilde günümüz ihtiyaçlarını karşılayacağına eminim. Hem ASP.NET Core’a uygun olması, hem de daha basit bir şekilde kullanılabilmesi için bu değişikliklerin yapıldığının altını çizmek isterim.

SignalR’ın ne olduğu ya da ne olmadığıyla ilgili değil de, yeni SignalR’da şimdilik neler değişiyor, yeni neler geliyor onlardan bahsetmek istiyorum. Yeni versiyona olan hazırlıklarınızı yapmanıza ya da SignalR’ı cesaret edip şu an bile kullanmayı düşünüyorsanız neler sizi bekliyoru görmenize biraz olsun yardımcı olabilirim belki.

Şu an BETA bile olmadığının, Alpha versiyonun olduğunu ve en son versiyonu ile yazıda bahsedeceğim şeylerin değişebileceğini hatırlatmak isterim.

Client uygulamalar için yeni Javascript kütüphanesi…

SignalR’ın JavaScript client’ı için olan kütüphaneler de baştan yazıldı. TypeScript ile yazılan yeni client kütüphaneleri jQuery bağımlığını ortadan kaldırıyor. Ancak kütüphane tarafındaki farklılıklar ve genel SignalR’daki yeniliklerden dolayı, yeni client’ların eski SignalR Server uygulamaları ile iletişimi mümkün değil. Aynı şekilde yeni SignalR Server uygulamalarınında eski client’lar ile iletişimi mümkün değil. Yeni JavaScript kütüphaneleri popüler tüm browser’lar ile uyumlu.

Otomatik bağlantı desteği şu an yok…

Önceki versiyonlarda SignalR client’ları bağlantı koptuğu zaman otomatik olarak yeniden bağlanıyor, bağlanmayı deniyordu. Şu anki versiyonda bu özellik yok. Bağlantının kopması durumlarında, tekrar bağlantı kurma işlerini client tarafında bizim yönetiyor olmamız lazım.

Sticky-Session zorunlu…

Şu an ne yazık ki sticky-session zorunlu. Büyük bir ihtimal bunun son versiyonda değişeceğini düşünüyorum ama şu anki versiyonda, eğer Load-balance arkasında çalışan uygulamalarınız varsa SignalR Client’ları sadece ilk bağlandığı server ile iletişim kurabiliyor.

İletişim yöntemlerindeki değişiklik…

Önceki versiyonlarda SignalR Client’ları ve Server uygulamaları, browser’ların desteklediği transport yöntemlerine göre iletişim kuruyor, SignalR desteklenmeyen bir transport yöntemi varsa, diğerini deniyordu. Yani eğer WebSockets desteklenmiyorsa, Server-Sent Events ya da foreever-frame ya da hiç bir şey desteklenmiyorsa long-polling şeklinde bağlantı kuruluyorsa. Yeni versiyonda artık bu da değişiyor. Eğer desteklenmeyen bir transport var ise, diğer transport yöntemleri denenmiyor.

Streaming artık mümkün…

Server-Client arasında veri akışı artık mümkün. Bu sayede bir metod çalışmasını bitirmeden veriyi client tarafına aktarmak mümkün olacak.

“Binary Data” ve yeni protokollerin desteği…

Yeni SignalR versiyonu ile binary formatında verileri iletmek mümkün. Bu hem verilerin boyutlarında(burası değişken) avantaj sağlayacak hem de performans konusunda. Bu destek MessagePack mesaj protokolü alt yapısına uygun bir şekilde geliştirildiği için, custom protokollerinizi geliştirip veri iletişimini bunlar üzerinden sağlamanız mümkün.

Şimdilik bu kadar… Umarım az biraz olsun bazı konularda aklınızdaki sorulara cevap sağlamış ya da cevaplar için anahtar kelimeleri sağlamışımdır.

Son olarak aşağıdaki videoya da göz atmanızı tavsiye ederim. Biraz uzun ama SignalR’ın yeni versiyonu için tüm sorulara cevap veriyor.

Introducing ASP.NET Core Sockets – Damian Edwards & David Fowler from NDC Conferences on Vimeo.

Razor Pages’in adını ilk olarak ASP.NET Core 2.0 Preview 1 çıktığında duymuştuk. İlk çıktığında da oldukça merak uyandırmıştı açıkcası, akıllara da ASP.NET Web Pages’i getirmişti. Sonu onun gibi olursa falan diye biraz çekinerek yaklaşmıştım. Küçük bir kaç PoC için tercih etmem gerekti ve oldukça hoşuma gitti. ASP.NET Core 2.0 da artık son halini aldığına göre biraz daha ayrıntılı bahsetmenin tam zamanı diye düşünüyorum.
Nedir bu Razor Pages?

ASP.NET Core 2.0 ile beraber hayatımıza giren Razor Pages, ASP.NET Core MVC alt yapısında, sayfa bazlı web uygulamaları geliştirebileceğimiz bir programlama modeli. Tamamen MVC alt yapısı üzerine geliştirilmiş bir kabuk olarak düşünebilirsiniz. MVC template’lerindeki klasör sayısını azaltmak, sayfa bazlı uygulamaları daha kolay geliştirmek için tasarlanmış yeni bir model. Altını çizerek belirtmek isterim ki, MVC’ye alternatif ya da onun yerini alacak bir model değil. Genelde yeni bir şey çıkınca bu şekilde soru işaretleri oluşuyor. Ben baştan söyliyim, yok öyle bir şey…

PHP ya da eski ASP ile tecrübesi olanların ya da scripting dilleri ile uygulama geliştirenlerin daha çok hoşuna gideceğini düşünüyorum. Büyük bir ihtimal, web uygulaması geliştirmeyi daha basite indirgemek ve script tabanlı dilleri tercih edenleri de mutlu etmek için böyle bir modele yönelmiş olabilir Microsoft. Ama asıl önemlisi web uygulaması yapmayı yeni öğrenmek isteyen kişileri çekmek sanırım Razor Pages’ın en büyük amacı.Çünkü gerçekten kolay.

MVC alt yapısını kullanarak yapıldığı için uzun zamandır MVC modeli ile geliştirme yapanlar için çok fazla bir şey ifade etmeyecektir. Hatta bir çok MVC tercih eden kişi, ne gerek vardı falan da diyor. Kendilerince haklılar. Burda tekrar belirtmek isterim ki, Razor Pages, MVC’nin bazı özelliklerini daha basit ve kolay hale getiriyor. Uzaya roket gönderebileceğiniz bir teknoloji değil…

Razor Pages, adından da anlaşılacağı üzere “Razor” ve “Sayfa” konsepti üzerine geliştirilmiş bir model. MVC’deki View kavramı, biraz daha geleneksel tabirle “sayfa” olarak karşımıza çıkıyor. Ama tabii ki Layouts, TagHelpers gibi yaklaşımlar Razor Pages’de de var.

Razor Pages’de sayfalar birer PageModel ile tanımlanıyor. PageModel’leri MVC’deki Controller ve Model olarak düşünebilirsiniz. Web sayfanıza gelen talepler(request), Controller’daki gibi PageModel tarafından karşılanıyor. Controller’a ek olarak View tarafına taşınan model de bu PageModel üzerinde olabilmekte.

Razor Pages dosya düzeniDosya yapısı olarak MVC’den biraz daha basit bir yapısı var. Default olarak Pages klasörü altına koyduğunuz *.cshtml’ler sayfalarınızı oluşturuyor. MVC’deki routing ile ilgili uymanız gereken yapı biraz daha basitleştirilmiş. Bir Razor Pages’in tanımlamak için *.cshtml’in @page yol göstericisinin sayfanın başında olması gerekmekte. Benzer bir şekilde @model yol göstericisi ile de sayfanın hangi PageModel sınıfını kullandığı belirtilmek durumunda. PageModel, Razor Pages ile gelen yeni bir abstract sınıf. Geliştirdiğimiz sınıflar, bu sınıftan(PageModel) türemek durumunda. Razor Pages’i sağlıklı kullanmak için geliştirdiğimiz sayfaların modelleri mutlaka bu şekilde olmalı.

Razor Pages’in önemli bir özelliği *.cs(code-behind) dosyası olmadan, *.cshtml’in içinde C# kodu yazarak, sunucu tarafında çalışacak kod ile HTML ve Razor kodlarını bir arada yazabilmeniz. Biliyorum kulağa çok kötü geliyor. Hatta sadece kulağa değil, göze de çok kötü geliyor. Böyle bir özelliğin olması, illa ki o şekilde kullanmanın zorunlu olduğu anlamına gelmiyor. Bu yüzden siz böyle kullanmayın 🙂

Read More

İş, güç, hayat derken yine burayı çok ihmal ettim. Ayıp bana…Ama artık alışmış olduğunuzu düşünüyorum. (: Bu hafta başında .NET tarafında güzel gelişmeler oldu, hem arayı kapatmak için, hem de bu güzel gelişmeleri özetlemek için güzel bir zaman olduğunu düşünüyorum…Buyrun efenim;

.NET Core 2.0 için geçen hafta nuget paketleri güncellenmiş ama resmi bir açıklama yapılmamıştı. Bu haftanın başında tüm .NET Core 2.0 alt yapısındaki API’ler RTM oldu. Yani artık; ASP.NET Core 2.0, Entity Framework Core 2.0‘ı üretim ortamlarında kullanabilirsiniz. Bu yayınlanma döngüsü içerisinde .NET Standard 2.0‘da tamamlandı. 1.6 versiyonuna göre desteklenen API sayısı ciddi anlamda artmış oldu böylece. .NET Framework’deki toplam yaklaşık 32000 API, .NET Standard 2.0 ile kullanılabilir hale geldi. Bu ne demek? Yani eğer geliştirdiğiniz kütüphaneler,kodlar…vs., .NET Standard 2.0’ın kontratının sunduğu API’leri kullanarak geliştirildiyse, farklı işletim sistemlerinde de çalışabilecek. Çok güzel, değil mi… 🙂

.NET Core 2.0, tamamen .NET Standard 2.0 API’lerini destekleyecek şekilde RTM olmuş durumda. En önemli çıktı bu diyebilirim ama tabi ki bunun dışında performans konusunda da ciddi iyileştirmeler mevcut. Ayrıca ARM32 sistemlerinde de kullanılabilir durumda. .NET’i her ortamda çalıştırabilmek için güzel bir gelişme.

NetStandardPlatforms

ASP.NET Core 2.0 ile beraber de bir çok iyileştirme ve yenilik mevcut. En dikkat çeken Razor Pages diyebilirim. MVC kalıbının biraz daha kolay uygulanabilmesini sağlayan ek bir sayfa modeli diyebilirim. Biraz daha ön yüz tarafına odaklanmanız gerek uygulamalar için kullanabileceğiniz bir yapı. Rahmetli ASP.NET Web Pages’i hatırlayanlar ve sevenler Razor Pages’ı da çok sevecektir diye düşünüyorum.  Bir yeni ve güzel özellik DbContextPooling… DbContext tipindeki EF context objelerinizi pooling yaparak daha performanslı kullanmanıza olanak sağlanıyor. DBContext instance’larının her request’de baştan tekrar tekrar yaratılmasının sebep olduğu sıkıntılar biraz olsun giderilmiş durumda. Tüm geliştirilen maddeler ve giderilen bug’ları daha ayrıntılı bir şekilde GitHub sitesinden takip edebilirsiniz.

Son olarak EF Core 2.0‘dan da biraz bahsederek, sizleri daha ayrıntılı araştırmanız için azat edim. LINQ sorgularının oluşturduğu T-SQL sorgularında ciddi anlamda bir iyileştirme yapılmış. Kompleks LINQ ifadelerinden oluşturulan T-SQL cümlecikleri artık biraz daha hızlı oluşacak. Bunun haricinde EF.Functions.Like() ile artık SQL’deki LIKE ifadesine denk gelen LINQ ifadeleri yazmak mümkün. Bir güzel gelişme EF6.x’de olan ama EF Core’da sıkıntılı olan TableSplitting kavramı da EF Core 2.0’da çözümlenmiş durumda. İki farklı entity’yi tek bir tabloya map etmek artık daha kolay.

Son olarak .NET Core 2.0’ı indirmek için https://www.microsoft.com/net/download/core adresini hatırlatmak isterim. Her şeyin başlangıcı…Yumulun…

Bu zamana kadar içerik ve katılım olarak en dolu etkinliklere imza atan Women Techmakers(WTM) Istanbul, 19 Mart‘da yine güzel bir etkinliğe imza atıyor. Bahçeşehir Üniversitesi’nin Beşiktaş kampüsünde gerçekleşecek etkinlikte, “Telling Our Story” teması altında yazılımcılar bir araya geliyor. 25+ konuşmacının katılımı ile gerçekleşecek etkinlik için ayrıntıları http://2017.wtmistanbul.com adresinden takip edebilirsiniz.

WTM Istanbul

Etkinlikte konusunda uzman ve başarılı bir çok konuşmacı olacak; Google Londra’dan Sarah Gordon, Google İrlanda’dan Hale Dönertaşlı, Gram Games’den Erin O’Brien ve Ayla Kara Çoban, Insider kurucusu Hande Çilingir, Armut.com kurucusu Başak Taşpınar Değim, ScaleX kurucusu Dilek Dayınarlı ve Webrazzi’den Merve Kara bu isimlerden sadece bir kaçı.

Daha önceki etkinliklerde oldukça geniş kitlelere ulaşıldığı için biran önce bu adresten kaydınızı yapmayı ihmal etmeyin.

 

Uzun zamandır bir şey yazamıyordum, güzel bir etkinlik haberi ile bu araya son verim; bu sene ilk defa düzenlenen Devnot Developer Summit, 8 Nisan‘da yazılımcıları İstanbul’da bir araya getiriyor. Devnot‘un düzenlediği bu etkinlikte 15 farklı oturum ile birbirinden güzel konular ele alınacak. Tüm gün sürecek olan etkinlikte, yazılım sektörünün başarılı ve konusunda uzman kişileri, 2 farklı salonda paralel oturumlar gerçekleştirecek. Docker’dan, TypeScript’e, mobil uygulamalardan, Linux’a kadar geniş bir yelpazeye sahip olanetkinlik, Kadir Has Üniversitesi Cibali kampüsünde gerçekleşecek.

Etkinlik ile ilgili gelişmeleri ve kayıt işlemleri için http://summit.devnot.com adresini takip edebilirsiniz. Etkinliğe biran önce kayıt olun derim. Kısa zamanda yer konusunda sıkıntı yaşayabilirsiniz benden söylemesi. Ben şimdiden yerimi aldım 🙂

Developer Summit 2017

Developer Summit 2017 - Konusmacilar

 

 

 

 

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)

Read More