I have decided to post some articles and arricle-ish writings in English occasionally starting with a cross-post from a post on my LinkedIn which was inspired by recently announced polyglot virtual machine GraalVM by Oracle. Here we go.

What?

GraalVM, a polyglot virtual machine has been announced recently by Oracle. It’s like JVM, but besides Java, Kotlin, Groovy, GraalVM supports LLVM based languages like C and C++ and some other popular ones like Python 3, R, Ruby and Javascript. As of today, you can create Jupyter Notebooks using more than 40 languages -more like scripting versions of well-known languages. You can create a cross platform dotnet application using C#, F# or VB.Net within the same solution / project. Similarly, GraalVM creates a polyglot ecosystem consisting supported languages. It’s not unusual to have a multilingual project, yet this improvement would change the nature of development trends like MEAN Stack changed. It’s possible to call the GraalVM supported languages as an ecosystem, a stack or a framework anytime soon, but there will be consequences. In a software project where only one language is supported -let’s assume C- it’s easy to have a spaghetti code while following basic rules, coding conventions and even best practices etc. It’s easier to have it when there are more "best practices paths" to follow, more rules and conventions to apply. …

Hesap Yönetimi (devam)

Önceki yazıda kullanıcının kim olduğunu aldıktan sonra kullanıcının erişim yetkilerinin kontrolü aşamasına geliyoruz. Soru şu: X kullanıcısı Y işlemini yapmaya yetkili mi?

2. RBAC vs ABAC: X kullanıcısı Y işlemini yapmaya yetkili mi?

Brute force bir kod yazma sürecine başlarsanız aklınıza ilk gelecek olan şey X kullanıcıları ve Y işlemlerini birbirine bağlayan bir mekanizma kurmak olacaktır. İlişkisel veritabanı kullanmaya alışkınsanız ilk olarak bir ISLEM tablosu oluşturmak ve bunu KULLANICI tablosu ile ilişkilendirmeyi deneyebilirsiniz. Ancak many-to-many bir ilişki olduğundan bir ISLEM_KULLANICI_MAPPING tablosu oluşturmayı, kullanıcı id’si ve işlem id’si ile bağlanan bir eşleştirme işlemiyle kontrolü sağlayabilirsiniz.

Ancak uygulama geliştikçe yeni özellikler gelecek, mevcut özellikler değişecek ya da silinecektir. Bunun yanında kullanıcıların sayısı da artınca tek tek kontrol etmek masraflı bir hale gelecektir. Zira m adet kullanıcı ve n adet ilişkiyi kontrol etmek m x n kez kontrol gerektirir. …

Önceki yazımda legacy code devralma üzerine bir örnek olaydan bahsedip olay akışına uygun biçimde yaptığım geliştirmeleri ekledim. Bu bölümde sonraki yaptığım işlem olan hesap yönetimi hakkında yazacağım.

Hesap Yönetimi

Bu bölümde kullanıcı kimlik ve erişim kontrolü, parola yönetimi gibi hesap yönetimi unsurlarının teorik altyapısına değineceğim. Söz konusu uygulama açık kaynak olmadığı için örnekler kısıtlı olacak.

1. Kimlik Kontrolü (Authentication)

İkinci adımda parola kontrolü kısmına geliyoruz. Bir ASP.Net geliştiricisi olarak Visual Studio’nun yeni proje açarken geliştiriciye sunduğu birkaç kimlik kontrolü(authentcation) seçeneği var.

Kurumsal yazılımlarda Active Directory bağlantılı çalışan Windows Authentication ve Office360, Azure Active Directory gibi bulut kimlik sağlayıcılarını kullanan Work and School Accounts seçenekleri sıkça tercih edilir. Zira kullanıcının kimlik bilgilerini ve yetkilerini bir otoriteden (yetki sağlayıcı) kontrol ettiğimiz için bu sorumluluğu, işi zaten bu olan birilerine devretmiş oluyoruz. Individual User Accounts seçeneği ise en sık rastladığımız, kullanıcının e-posta ve birtakım kimlik bilgileri ile kendini sisteme kaydettirdiği, bu kayda dayanarak oluşturduğu parola ve kullanıcı adı ile oturum açtığı, uygulama yöneticileri tarafından verilen yetkiler dahilinde işlem yapabildiği sistemleri ifade ediyor. …

Legacy code her zaman kötüdür, değil mi? Eski programcının kodlarına bakar, bir çok hata görür, “böyle mi yapılır bu” diye söyleniriz. Bir iki günlük -ya da haftalık, kodun içine girme süreniz bağlı- Dunning Kruger sendromu sonrası mimariyi ve içinde bulunduğu kısıtları gördüğünüzde birkaç refactoring dışında bir şey ekleyemez olduğunuzu görürsünüz. Proje tıkanır, “bu adam olmaz, yeniden yazmak gerek” dersiniz. İşte o an aslında fark edilmesi gereken şey sizin kodunuzun da -eğer olacaksa, yaşam döngüsünün sonunda değilse- bir sonraki programcı tarafında aynı tepkiyle karşılaşacağı olmalı. Çünkü sizin kodunuz da derlediğiniz andan itibaren artık legacy code’dur. …

Bugüne kadar kişisel projelerde biraz Java, profesyonel olarak da .Net (C#) üzerinde çalıştım. C++ ile ilişkim hiç olmadı. Okulda öğrendiği kadar C bilen biri için anlamsız sayılacak bir bir maceraya giriyorum.

C++ ile 13 yıl önce yazılmış bir Text-to-Speech uygulamasını C# ile yeniden yazmak.

Yol haritam kaba bir taslak biçiminde. Özetle,

1. Mevcut cpp ve h dosyalarını kullanarak Visual Studio 2015 üzerinde yeni bir Win32 projesi açmak.
2. Projeyi çalışır hale getirmek. Zira oldukça büyük bir hata listesi ile karşılaştım.
3. C++ kodunu temel bir refactoring sürecine tabi tutmak
4. CppSharp yardımıyla C++ header dosyalarını kullanarak, uygulamayı C# ile yeniden yazmak.

Neden böyle saçma bir işe kalkıyorum?

Yeni bir dil öğrenme konusunda bir motivasyona ihtiyacım vardı. Öğrenme metodolojisi olarak da hedef odaklı çalışan biriyim. Bu bağlamda motivasyon kaynağım, bir problem üzerinde çalışmak ve onu sonuca ulaştırmak demeliyim sanıyorum.

Kaynak kodları Github’a yükledim. Proje bir sonuca ulaşacak mı, göreceğiz.