Topic: AELF ($ELF) Blockchain (RESMİ ANA KONU) - ANA AĞ (MAINNET) TARİHİ: 10 ARALIK - page 18. (Read 27333 times)

Aelf Teknik Konuşmalar: Bağımlılık Enjeksiyonu Bölüm 4

Bağımlılık Enjeksiyonunun (Dependency Injection - DI) Üç Boyutu



Bu son bölümde, her biri tamamlayıcı olan bağımlılık enjeksiyon teknolojisinin üç boyutu hakkında kısaca konuşacağız.

1) Nesne kombinasyonu

Birleştirilmiş kök, bağımlılıkları yapılandırır.

2) Yaşam Döngüsü Yönetimi

Yalnızca kombinasyon kökünün bağımlılığı belirleyen yerleşim olduğunu söyledik. Aslında bağımlılığı ayarlarken bağımlılık enjeksiyonu, ayrıca her nesnenin yaşam döngüsünün yönetilmesini gerektirir.

DI uygulanırken, bağımlılıkların birleştirilmiş kök içerisinde ayarlandığını zaten biliyoruz. Ayrıca birleşik nesnenin nesnesine veya yöntemine kompozitör olarak başvurabiliriz. Birleştirici, düzeneğin dayandığı nesneyi ifade eden birleşik bir terimdir. Veya yöntem. Genel olarak bir DI kapsayıcısı, bir birleştiricidir.

Birleştiricinin varlığından dolayı nesne, bağımlılıklarının oluşturulmasını yönetmemeye mahkumdur. Bağımlılığın tahribi nedir? Bağımlılıklar zamanında tahrip edilmezse, bellek sızıntısı riski vardır.

.NET kullanan herkes GC'nin otomatik olarak kullanılmayacak nesneleri geri kazanacağını bilir ve IDisposable arayüzünü uygularsak, nesneleri kendimiz imha edebiliriz.

DI'de, bir nesnenin yaşam döngüsü bir birleştirici tarafından yönetilir. Birleştirici, bağımlı bir nesnenin diğer farklı nesnelerle paylaşılıp paylaşılmayacağına veya nesneyi ne zaman serbest bırakacağına karar verebilir: belirli bir tüketicinin kapsamı dışında mı yoksa tüm tüketicilerin rolü ötesinde mi bırakılacağına karar verebilir.

Nesne yaşam döngüsünün yönetimi, bağımlılık enjeksiyonunda en karmaşık problemlerden biri olmalıdır. Bağımlılık enjeksiyonunun uygulanmasını desteklemek için Uzantılar adlı Microsoft’un Repo’suna göz atalım. Bu proje, tüm nesnelerin “ServiceLifetime” da tanımlanan üç yaşam tarzına sahip olduğunu belirtir. Kelimenin kendisi yaşam tarzı ya da iş tarzı anlamına gelir ve bir yaşam döngüsü türüne çevrilmiş gibi görünmektedir. Bu üç yaşam döngüsü tipi, DI kapsayıcısı perspektifinde daha iyi anlaşılabilir, ancak DI kapsayıcısı kullanılmadığında nesne yaşam döngülerini yönetme önerisi de mevcuttur. Bu üç kategori hâlâ geçerlidir:

- Singleton. Aynı soyutlama örneği, başvuru boyunca her zaman paylaşılır.

- Kapsamlı. Belirli bir rol için bir singleton kullanmak, ancak farklı kapsamlar için farklı örnekler sağlar.

- Geçici. Her istek yeni bir örnek döndürür.

3) Intercept

Teoride, kod uygulaması SOLID ilkesine uygunsa, dekoratör modunda Cephe yönelimli programlama (Aspect-oriented programming  - AOP) uygulanabilir. Genel yaklaşım, önceki XXService için XXServiceDecorator adlı bir alt sınıf oluşturmak, XXService'e XXServiceDecorator'a bir yapıcı parametresi olarak enjekte etmek ve XXServiceDecorator'da genelde, doğrudan çağrı, koşullardan önce ve sonra intercept için XXService yöntemini yeniden uygulamaktır. Son olarak, birleştirilmiş kökte XXService yerine XXServiceDecorator değerini ayarlayın.

Not: AOP uygulamanın, Dinamik Interception (dinamik proxy de denir) ve Derleme Süresi Weaving (ayrıca IL Weaving olarak da bilinir) olmak üzere iki yolu vardır. Bu iki konu hakkında inceleme yapmayacağız.

# Demo

https://github.com/EanCuznaivy/DIDemo?source=post_page-----3015d4a5f7a1----------------------

KAYNAK: https://medium.com/aelfblockchain/aelf-tech-talks-dependency-injection-part-4-3015d4a5f7a1

Aelf ekibi, son sürat çalışmaya devam ediyor  

Hala yaşıyor mu bu aelf hayret. Uzun zamandır duymuyordum.

💰Yorum Yap & Kazan!💰

📢 Haftalık Dapper (The Dapper Weekly) Twitter Giveaway burada!

1️⃣ Takip et
2️⃣ Retweetle & Beğen
3️⃣ Favori bölümünü yorum olarak belirt (Tüm bölümler tweet altındadır)

⭐️ Bu Giveaway'e sponsor oldukları için Aelf Blockchain'e, State Of The DApps'e ve Dapp Review'a çok teşekkür ediyoruz!

Tweet: https://twitter.com/mappopk_crypto/status/1181444710943969281

Aelf Teknik Konuşmalar: Bağımlılık Enjeksiyonu Bölüm 3



## Arayüz Ayrıştırma Prensibi (Interface Segregation Principle - ISP）

> İstemciler, kullanmadıkları arabirimlere bağımlı olmaya zorlanmamalıdır.

Bir sınıfın diğerine bağımlılığı asgari düzeyde olmalıdır.

Bu prensibi izleyerek, birden fazla sorumluluk için yöntemleri tanımlayan şişirilmiş arayüzleri önlersiniz. Tek Sorumluluk Prensibinde açıklandığı gibi, sık sık değiştikleri ve yazılımınızın bakımını zorlaştırdığı için çoklu sorumluluk içeren sınıflardan ve arayüzlerden kaçınmalısınız.

Bir çapraz sözleşme çağrısı için Aelf ekibi, AElf Sözleşme Standardı (ACS) adlı bir sözleşme standardı sağladı ve her bir ACS bazı Arayüz tanımlar. Çapraz sözleşme çağrısı yaparken, belirli bir ACS'de hangi arabirimin tanımlandığı konusunda endişelenmenize gerek yoktur. Yalnızca istenen ACS'yi uygulayan bir sözleşme sağlamanız gerekir. Öte yandan her bir sözleşme, birden fazla ACS uygulayabilir. Diğer sözleşmeler tarafından çağrıldığında, yalnızca uyguladığı ACS'lerden biriyle ilgilenebilir. Böylece yalnızca bu ACS'ye dayanırsınız ve bu sözleşmeyi almazsınız. Diğer yöntemler, çapraz sözleşme çağrılarına maruz kalmaktadır. Bu sadece arayüz izolasyonu prensibinin bir açıklamasıdır.

Bağımlılık İnversiyon Prensibi (Dependency Inversion Principle - DIP）

> Yüksek seviyeli modüller düşük seviyeli modüllere bağlı olmamalıdır. Her ikisi de soyutlamalara bağlı olmalıdır. Soyutlamalar, detaylara bağlı olmamalıdır. Detaylar, soyutlamaya bağlı olmalıdır.

Bu tanımın önemli bir detayı, yüksek seviye ve düşük seviye modüllerinin soyutlamaya bağlı olmasıdır. Tasarım ilkesi, adını ilk defa okurken beklediğiniz gibi sadece bağımlılığın yönünü değiştirmez. Aralarında bir soyutlama tanıtarak yüksek ve düşük seviye modülleri arasındaki bağımlılığı böler. Sonuçta iki bağımlılık elde edersiniz:

1.Yüksek seviye modülü, soyutlamaya bağlıdır
2.Düşük seviye, aynı soyutlamaya bağlıdır

Bu, olduğundan daha karmaşık gelebilir. Sonuç olarak Açık/Kapalı Prensibini ve Liskov'un Yerine Geçme Prensibini kodunuza uygularsanız, Bağımlılık İnversiyon Prensibi'ni de takip eder.

Bir kelimeyle: arayüz odaklı programlama. Arayüzü daha düşük-seviye modülüne koyabilir ve daha sonra bu arayüzün üst-seviye modülde uygulanmasını sağlayabiliriz. Farklı üst seviye modüller arasındaki iletişim, temel modüllerdeki arayüzlerle de yapılır. Örneğin, Log’u yüksek seviye bir modül olarak ele alıyoruz. Temel modülde farklı log seviyelerinin yazdırılması için bazı yöntemler sağlayan tek bir ILogger arayüzü vardır. Özel yazdırma uygulaması log modülüne yerleştirilir. Diğer modüller kayıt yapmak için log modülüne dayanabilir, NLog kullanabilirsiniz, ayrıca log4net kullanabilirsiniz, log modülü bir bağımlılık haline gelir ve hangisini kullanacağımız bu bağımlılığı manuel olarak nasıl enjekte ettiğimize bağlıdır. Peki nasıl enjekte ediyorsunuz? Daha sonra Bileşim Kökünü (Composition Root) tartışacağız.

Örnek projede gördüğünüz gibi, yalnızca Açık/Kapalı ve Liskov'un Yerine Geçme Prensiplerini kod tabanınıza uygulamanız gerekir. Bunu yaptıktan sonra sınıflarınız, Bağımlılık İnversiyon Prensibi'ne de uyar. Herhangi bir arayüz soyutlamasını değiştirmediğiniz sürece bu, diğer sınıfları etkilemeden daha yüksek ve daha düşük bileşenleri değiştirmenizi sağlar.

# DI, IoC ve DIP arasındaki fark

Buradaki DI, DI kapsayıcı değil DI teknolojisidir. Autofac, Ninject, vb. geliştirilmesinde kullandığımız bağımlılık enjeksiyon yapısı, DI kapsayıcına aittir.

Bileşim Kökü, bir tasarım desenidir. Bu tasarım desenini kullanmanın anahtarı, Bileşim Kökünün bulunduğu yeri bulmak zorunda olduğumuzdur. Neyse ki, öncekiler bize bir çözüm verdi: uygulama giriş noktasına mümkün olduğu kadar yakın… Peki Bileşim Kökü ne içindir? Kısacası, yapılandırma, bu yanıltıcı olabilir, ancak birleşik kök bir DI kapsayıcısıdır- başka bir deyişle, bağımlı bir ilişki kurar. Yani, bu uygulamada hangi soyut tipin hangi özel tipe tekabül ettiği, bileşim kökünde bir şekilde ayarlanması gerektiğidir. Burada belirtilen soyut tip, C#'da bir arayüz veya soyut bir sınıf olabilir. Aslında, DI uygulama pratiğinde bu şekilde soyutlama yapmak önemli değildir. Soyut türünü yalnızca belirli Tür bağımlılıklarına karşılık gelecek şekilde birleşik kökte ayarlamamız gerekir. Bu ayar doğrudan DI kapsayıcısındaki Register veya AddSingleton gibi yöntemleri çağırabilir. Ancak DI teknolojisinin uygulanması, mutlaka bir DI kapsayıcısının kullanılmasını gerektirmez.

Kombinasyon kökleri kavramını "sondan başlayarak" bakış açısıyla yeniden düşünüyoruz: Üretim için kullanılabilecek eksiksiz bir uygulamanın çok sayıda hizmet içermesi gerektiği düşünülebilir ve bu uygulamanın uygulanmasının gevşek bir şekilde birleştirilmesini istiyorsak, arayüz izolasyon prensibi kullanılacaktır. Bir servisteki diğer servisleri kullanmamız gerektiğinde, kodu yazarken hangi servislerin uygulanacağını bilemeyiz, bu nedenle kodda doğrudan bir soyutlama çağırırız. Uygulama çalıştıktan sonra, soyuta yapılan asıl çağrıdan önce bir montaj süreci olmalıdır. Sözde derleme, koddaki soyut türe dayanır ve çalışma zamanında somut bir uygulama sağlar; bu da soyut türler ve belirli türler arasında manuel olarak bir haritalama ilişkisi kurmamızı gerektirir. Birleştirilen kök, ilişkinin manuel olarak sağlandığı yerdir. En kolay konsol uygulaması, çalıştırmak için her bir bileşen arasında iş birliği gerektirecektir. Temel bileşenlere dayanan birçok türde üst düzey bileşen vardır. Şu anda en yaygın kullanılan, yapıcı enjeksiyonudur. Uygulanabilir yapıcı enjeksiyonuna bir arayüz atamazsınız, manuel olarak yeni bir uygulama oluşturmanız gerekir. Bu işlem, soyut türü ve belirli bağımlılık türlerini ayarlamaktır.

Açık Kapalı Prensibe tekrar bakıyoruz, belirli bir fonksiyonun modifiye edilmesi gerektiğinde, orijinal uygulamayı değiştiremeyiz, ancak dekorasyon modu ile bir realizasyon sağlayabiliriz ve daha sonra kombinasyon kökünde yeni bir uygulamaya ilgili bağımlılığı ayarlayabiliriz. Sadece kodu eklemeniz ve kombinasyon kökünü değiştirmeniz yeterlidir. Yeni uygulamanın sorunları varsa, eski uygulamanın gerekli olmadığını öğrenene kadar istediğiniz zaman geri çekebilirsiniz. Bu gereksiz ilişkiyi ortadan kaldırmak için bir yeniden düzenleme adımı uygulanmaktadır. İnsanlar, özellikle çalışmalarını başkalarıyla uzlaştırdıklarında, güvenilmez olabilirler. Bu nedenle, yeniden yapılanmadan önce yeterli birim testi eklememiz ve hatta uygulama öncesi birim testleri yazmamız gerekiyor. Test Odaklı Tasarım, birim testinin önce yazılmasını gerektirir, ünite testi başarısız olursa, test başarılı olana kadar uygulama güncellenir. Ancak yazılım geliştirme burada sona eriyorsa, Test Odaklı değil, yalnızca İlk Test Tasarımı olarak adlandırılabilir. Tasarımın özü yeniden yapılanmadır ve tatmin edici bir düzeye dek ayrıklaştırmadır ve test durumu, yeniden yapılanmanın fonksiyonu bozmayacağının önemli bir garantisidir.

Bu serinin başında da belirtildiği gibi DI, aslında bir IoC uygulamasıdır, ancak IoC kavramı önerdiği bakış açısına göre daha da yönlendirilmiştir. Birçoğu Hollywood ilkesini duydu: beni arama, ben seni çağıracağım. Bu bir bağımlılık modülü olarak somut bir türdür. Ne zaman ve nasıl çağrılacaklarını önemsemelerine gerek yoktur sadece kendilerinin çağrılması için beklemeleri gerekecektir.

Son olarak SOLID'deki DIP, üst seviye modüllerin temel modüllere dayanmaması, hepsinin soyutlamaya dayanması gerektiğini gösterir. Bu açıdan DIP, soyutlamanın derecesine fazla dikkat eder. Yani, özel uygulama ve kodun şekli budur.

Ancak aşağı yukarı bu üç kavramın bir fikri ifade ettiğini, rafine edilmesi gereken bir şey varsa arayüz odaklı programlama olduğunu düşünebiliriz. Arayüzü en alta koymak için uygulama en üste yerleştirilir.

KAYNAK: https://medium.com/aelfblockchain/aelf-tech-talks-dependency-injection-part-3-2c89a6159056

aelf Enterprise (Kurumsal) 0.8.0 Beta Resmi Olarak Yayınlandı



aelf Enterprise 0.8.0 beta; bütün bir blockchain sistemi, geliştirme kitleri, geliştirme belgeleri ve destekleyici altyapı ve altyapı hizmetlerini içeren eksiksiz ve tam bir blockchain ticarileştirme çözümü setidir.

aelf Enterprise 0.8.0 beta sürümü sistem entegrasyonu

1. aelf Enterprise
• aelf Enterprise v0.8.0 beta
• DevKit v0.8.0 beta

2. aelf Harici Uygulamalar
• aelf blockchain tarayıcı v0.1.6
• aelf tarayıcı MySQL plugin v0.8.0 beta
• aelf kaşifi v0.8.0 beta
• aelf cüzdan v0.8.0 beta
• aelf JS SDK v3.2.17
• aelf JS SDK Çapraz Zincir v1.0.1
• Nodejs v0.1.15’te aelf CLI

3. aelf Tarayıcı Uzantısı V0.8.0 beta

Aelf Enterprise 0.8.0 beta sürümünün Aelf Enterprise 0.8.0 alfa sürümüne kıyasla önemli özellikleri şunlardır:
• Geliştirilmiş stabilite
• Daha eksiksiz ekonomik sistem
• Çapraz zincir kabiliyetinin tam seti
• Daha eksiksiz çapraz zincir destek araçları

Bu güncelleme ve önemli özellikleri

aelf Enterprise v0.8.0 beta:

AEDPOS Konsensüs Mekanizması:
• Rastgele blok sırası
• Üretim bloğu mantığı
• Konsensüs doğrulama ve hile cezası

Ekonomik sistem:
• Teklif ve çoklu imzalama mekanizması
• Üç oylama modeli (parlamento oyu / birlik oyu / referandum)
• Bancor tabanlı TOKEN (çoklu varlık) ticareti
• Düğüm seçimi oylama / değiştirme
• Temettü / ödeme mekanizması

Ana zincir:
• P2P ağı ve düğüm yönetimi
• Ticaret havuzu
• Zincir yönetimi
• Blok / işlem doğrulama ve yönetimi
• Veri depolama
• WebAPI arayüzü
• Komut satırı arayüzü
• SDK geliştirme (Javascript)

Çapraz zinciri:
• Alt zincir ve ebeveyn zincir indeksleme mekanizması
• Çapraz zincir doğrulama ve çapraz zincir transfer

Sözleşme sistemi:
• Çalışma süresi (Runtime)
• Sözleşme Geliştirme SDK
• Sözleşme güvenlik kontrolü
• Sözleşme geliştirme standardı (acs)

Paralel yürütme:
• Kaynak algılama ve gruplama
• Gruplar arasında paralel yürütme
• Çatışma yönetimi

DevKit:
Geliştirici Belgeleri
• Yeni düğüm yapısı
• Yeni çapraz sözleşme çağrıları
• CLI kullanım belgeleri güncellendi
• WebAPI kullanım belgeleri güncellendi, RPC ile ilgili belgeler kaldırıldı


aelf Harici Uygulamalar güncellemesi:

aelf Cüzdanı:
• Çoklu token durumunda işlem kaydı sorgusunun hatası düzeltildi

aelf Kaşif:
• Arayüz yeniden yapılandırma, yüzlerce milisaniyede arayüz yanıtı
• Mantığın kısmı websocket kullanılarak optimize edilmiştir
• İşlem kaydı sorgu optimizasyonu

aelf JS SDK Çapraz Zincir:
• Çapraz zincir JS SDK eklendi

Nodejs’de aelf CLI
• Yeni teklifle ilgili yöntemler eklendi

Entegrasyon özelliklerine giriş:

1. aelf Enterprise
• aelf Enterprise v0.8.0 beta https://github.com/AElfProject/AElf
— Yüksek Performanslı Akıllı Sözleşme Çalışma Zamanı
— Konsensüs Sistemi
— Çoklu Token Sistemi
— Oylama sistemi
— Çapraz Zincir Sistemi
— Web API

• DevKit
— Boilerplate https://github.com/AElfProject/aelf-boilerplate
— TestKit
— BenchmarkKit
— IDE entegrasyonu
— Belgeler https://docs.aelf.io/
— Öğreticiler https://docs.aelf.io/main/main

1.1 aelf Enterprise v0.8.0 beta

Minimize edilmiş blok zinciri kerneli, DPoS konsensüs mekanizması, akıllı sözleşme sistemi, oylama sistemi, token sistemi ve temel çapraz zincir sistemi dahil olmak üzere tam bir blok zincir sistemidir.

Yüksek Performanslı Akıllı Sözleşme Çalışma Zamanı
• Sözleşme yürütme seviyesi: Protobuf’a dayanarak grpc gibi bir akıllı sözleşme yürütme ortamı uygulandı. Tüm nesnelerin girdi ve çıktıları ve depolanması Protobuf yüksek performanslı serileştirme işlemine dayanır. Durum depolaması, redis gibi yüksek performanslı bir dağıtılmış veri tabanı kullanır.
• Genel sözleşme yapısı: grpc eklentisi ile oluşturulan kodlar, bir grpc sunucusuna eşdeğer performansları gösterir.
• Sözleşme Kontrolü: Bloklar içinde paralel yürütme, AKKA kümeleri üzerinden gerçekleştirilebilir.

Konsensüs Sistemi
• Güvenlik: Gizli Paylaşım algoritması, seçilen tüm düğümlerde dağıtılmış rasgele sayıların üretilmesini sağlayabilir. Her turdaki blok üretim sırası; üretilen rasgele sayılarla belirlenir, böylece düğüm gizli anlaşması ve kötü niyetli davranış olasılığını azaltır.
• Verimli: Düğümlerin ⅔'ü bir bloğu doğruladıktan sonra blok, geri ters çevrilemez blok olur ve veriler çatal tarafından ters çevrilmeden zincire kalıcı olarak sabitlenir.

Çoklu Token Sistemi
Sözleşme sistemine dayanarak Blockchain çapraz zincir sağlayabilen dâhili bir Token Sistemi uygulanır. Tüm varlıklar; zincirler arasında ihraç edilebilir, transfer edilebilir ve kilitlenebilir.

Oylama sistemi
Sözleşme sistemine dayanarak bir evrensel oylama sistemi, işlevseldir ve çevrimiçi yönetişimi ve ikincil gelişmeyi kolaylaştırır.

Çapraz Zincir Sistemi
Zincirdeki herhangi bir verinin zincir boyunca iletecek bir mekanizma sağlar. Sistem, Merkle Ağaç Kökü endeksine dayanarak uygulanır ve tüm sistem çok seviyeli ana yan zincir endeksini gerçekleştirebilir, böylece ölçeklendirme ve dağıtıklaştırma gerçekleştirilebilir.

Web API
ASP.Net Çekirdek sunucusu, yüksek performanslı etkileşimli bir yapı gerçekleştirmek için uygulanmaktadır.

1.2 DevKit
https://github.com/AElfProject/aelf-boilerplate
Geliştirme Şablonları ve Öğreticileri, Geliştirici Kılavuzu, TestKit, BenchmarkKit ve IDE Entegrasyonunu içerir
• Geliştirici Kılavuzları: Aelf sisteminin ve API dokümantasyonunun ayrıntılı bir tanıtımını sağlar
• TestKit: Geliştiricilerin sözleşmeleri hakkında kısa bir test yapmasına izin verir
• BenchmarkKit: Dahili performans testi durumları sağlar
• IDE Entegrasyonu: Geliştiricilerin, geliştirme sırasında akıllı sözleşmelerin hatalarını ayıklamalarına izin verir ve birim test kodu kapsamı istemi sağlar

Geliştiriciler, hızlı bir şekilde Aelf temelli Blockchain sistemleri kurabilir ve Aelf tarafından sağlanan geliştirme kitlerine ve araçlarına dayalı olarak Dapp‘ler oluşturabilirler. ve Aelf’i geliştirici dokümantasyonu aracılığıyla hızlıca tanımaya başlayabilirler.

2. Aelf Harici Uygulamalar
Aelf Blockchain tarayıcı https://github.com/AElfProject/aelf-block-scan
• Zincir tarama programı, geliştiricilerin zincirdeki verileri zincir dışında kolayca depolamasını ve böylece geliştirici geliştirme maliyetlerini düşürmesini sağlar.
• Uygulamayı ilgili veri tabanı ile eklemek gerekir, topluluk varsayılan MySQL ekleme sürümü olarak aelf-scan-MySQL sağlar.

Aelf Tarayıcı MySQL eklentisi https://github.com/AElfProject/aelf-scan-mysql
• Geliştiriciler, MySQL veri tabanına veri eklemek için zincir tarama programını kolayca kullanabilir
• İşlem, blok, TPS, kaynak veri depolaması varsayılan olarak desteklenir

Aelf Kâşifi https://github.com/AElfProject/aelf-block-explorer
• Blok ve işlem sorguları uygulandı

Aelf Cüzdan https://github.com/AElfProject/aelf-web-wallet
• Yerel olarak depolanan özel anahtar
• Temel token transferi ve işlem kayıtlarını görüntüleme uygulandı
• Aelf sözleşme tokenlerini arayabilir ve ekleyebilir

Aelf JS SDK https://github.com/AElfProject/aelf-sdk.js
• Aelf'in çapraz link/bağlantı transfer arayüzü, geliştiricilerin hızlı bir şekilde başlamasını kolaylaştırmak için kısa ve öz biçimde açıklanmıştır.

Nodejs’de Aelf CLI https://github.com/AElfProject/aelf-command
• Çok fazla sayıda komut istemi sağlanır.
• Hesap oluşturma, blok bilgisi alma, işlem (trading) bilgisi alma ve sözleşmeleri yayınlama gibi işlevler sağlar.

3. Aelf Tarayıcı Uzantısı
https://github.com/AElfProject/aelf-web-extension
• Özel anahtarları yerel olarak depolar ve bir anahtar yönetim kullanıcı arayüzü sağlar
• Eklenti ve uygulama arasında şifreli iletişim sağlar
• AElf ekosistemindeki DAPP işlem imzalarını destekler
• Kullanıcıların uygulama izinlerini görsel olarak yönetmesini destekler

KAYNAK: https://medium.com/aelfblockchain/aelf-enterprise-0-8-0-beta-officially-released-38b41622893e

Aelf, BTCManager ile partnerlik kurdu. Yeni partnerlik ile birlikte artık Aelf ile ilgili tüm haberleri https://btcmanager.com/ adresinde bulabilirsiniz.

Aelf Teknik Konuşmalar: Bağımlılık Enjeksiyonu Bölüm 2

SOLID Tasarım İlkeleri



Bu serinin 1. bölümünde Bağımlılık Enjeksiyonu ve IoC tartışıldı. Bağımlılık Enjeksiyonu derinlemesine girmeden önce, nesne yönelimli tasarım modelinin beş SOLID ilkesini anlamak önemlidir. Bu bölümde ilk üç ilke incelenecektir.

1) Tek Sorumluluk İlkesi (SRP, Single Responsibility Principle)

> Bir sınıfın değişmesi için hiçbir zaman birden fazla sebep olmamalıdır.

Bir şaka duymuş olabilirsin:

- Hata olmadan kod yazdın mı?

- Evet, daha önce yaptım: Merhaba Dünya.

Bu paragraf bize doğruyu söyler: kod ne kadar basitse, bir hata olması o kadar az olasıdır.

Peki kodu nasıl basitleştiririz? Her kod satırını yazarak tek bir şey yapmak için. Uygulamada, bir sınıfın sadece bir şey yapmasına izin verdik. Ve eğer bu sınıfa basit ve sezgisel bir isim verebilirsek, kodun kendisinin bildirilmesi çok iyi olacaktır. Alibaba’nun Java spesifikasyonunun, bir sınıfın bir tasarım deseni kullanıyormuş gibi adlandırma için gereksinimleri olduğunu hatırlıyorum. Tasarım deseninin adını ismin içinde yerleştirmek gerekir. Şu anda, yorumlar gereksizdir ve kod insanların okuması ve bakımı için kolaydır.

Tek sorumluluk ilkesinin tanımına geri dönelim. Martin, bir sorumluluğu değişimin nedeni olarak tanımlar ve bir sınıf veya modülün değiştirilmek üzere bir ve yalnızca bir nedeni olması gerektiği sonucuna varır (yani yeniden yazılması). Örnek olarak, bir rapor derleyen ve yazdıran bir modül düşünün. Böyle bir modülün iki nedenden dolayı değiştirilebileceğini hayal edin. İlk olarak, raporun içeriği değişebilir. İkincisi, raporun formatı değişebilir. Bu iki şey çok farklı nedenlerle değişir. Tek sorumluluk ilkesi, sorunun bu iki yönünün gerçekten iki ayrı sorumluluk olduğunu ve bu nedenle ayrı sınıf veya modüllerde olması gerektiğini söylüyor. Farklı zamanlarda farklı nedenlerle değişen iki şeyi birleştirmek/eşleştirmek, kötü bir tasarım olacaktır.

Bir sınıfı tek bir endişeye odaklamanın önemli olmasının nedeni, sınıfı daha sağlam ve güçlü kılmasıdır. Yukarıdaki örnekten devam edersek rapor derleme işleminde bir değişiklik olursa, aynı sınıfın bir parçasıysa yazdırma kodunun kırılması daha büyük bir tehlikedir.

Ayrıca bir sınıfın tek sorumluluk ilkesine uygun olup olmadığına karar vermek için bir standart vardır. Bu, sınıftaki öğelerin uygunluğuna bağlıdır. Bir yineleyici uygulayan bir sınıfta yazma fonksiyonuna sahip olamazsınız. Bunun hakkında düşünmeyin. En önemseyeceği panonun boyutunu kontrol etmesidir. Başka bir deyişle, panonun kendisi yineleyicilerin sınıfına dahil edilmemeli, yalnızca bir hizmet olarak var olmalı ve Depo modunu kullanmayı düşünebilirsiniz.

Yüksek korelasyon, yüksek uyum ve işlevde daha küçük bir granülite anlamına gelir.

Burada belirtilen sınıf, bir varlığa veya bir servise başvurabilir. Domain-driven Design kitabında Eric, uygulamadaki nesneleri üç türe ayırır: değerler, varlıklar ve hizmetler. Bir varlık, değerlerin bir kombinasyonu olarak düşünülebilir ve bir hizmet, iş mantığını içeren koddur.

2) Açık Kapalı Prensibi (Open Closed Principle - OCP)

> Sınıflar, modüller ve fonksiyonlar gibi yazılım varlıkları; uzantı için açık olmalı ancak varlığın kaynak kodunu değiştirmeden davranışının genişletilmesine izin verebilecek şekilde değişikliklere kapalı olmalıdır.

Açık Kapalı Prensipten bahsedersek bu, dekoratör modeli aracılığıyla anlaşılması özellikle kolay olan bir tasarım desenidir. Bir senaryo hayal edebiliriz. Bir süpermarkette yazarkasa sistemi veya bir e-ticaret web sitesi yapıyoruz. Her halükârda emtia varlığı vardır. Emtia varlığı, bir GetPrice (FiyatAl) yöntemine sahiptir ve şimdi ürüne bir indirim işlevi eklemelisiniz. Malın sınıf kategorisinin tek sorumluluk prensibine uygun olduğunu varsayarsak, şu anda üç seçenek vardır:

1. Şimdi ihtiyacınız olan işlevselliği sağlamak için arayüze bir yöntem ekleyin.
2. Sınıfın uygulamasını modifiye edin ve yeni özellikler imzalamak ve sağlamak için önceki yöntemi kullanın.
3. Bir sınıfı tekrar oluşturun, önceki uygulama sınıfını kalıt alın (inherit), önceki yönteme bir katman yerleştirin ve yeni bir uygulama sağlayın.

Açık Kapalı Prensibi, üçüncü çözümü seçmemizi önerir. Bunun nedeni arayüzü modifiye ederek, bu arayüzü uygulamak isteyen diğer sınıfların uygulamayı eklemesi gerekir. Bu yeni uygulamanın gereksiz olması muhtemeldir, çünkü tüm ürünler için aynı gün içerisinde indirim yapılması muhtemel değildir. İkinci çözüm, sadece tehlikeli bir operasyondur. Kesinlikle birim testini etkileyecektir (eğer varsa) ve hataların ortaya çıkması gibi büyük bir olasılık vardır. Üçüncü seçenek en güvenli olanıdır. Önceki uygulama için bir dekoratör sağlayabiliriz ve ardından yeni işlevsellik sağlamak için dekoratör çağırabiliriz. Önceki örnekte önceki uygulama, ürünün orijinal fiyatını dekoratörün “indirim dekoratörü” olarak adlandırdığı şeyi döndürmektir ve daha sonra indirimli fiyatı döndürmek için aynı yöntemi çağırır. Önceki uygulama, yapıcı parametreleri vasıtasıyla dekoratöre enjekte edilir. Gerçek kullanım o kadar basit olmayabilir ancak bu, prensibin basit bir açıklamasıdır.

Daha sonra enjeksiyonun birleşik kökü hakkında konuştuğunuzda, tekrar Açık Kapalı Prensipten bahsedeceksiniz.

3) Liskov'un Yerine Geçme Prensibi (Liskov Substitution Principle - LSP)

> Temel sınıflara işaretçiler veya referanslar kullanan fonksiyonlar, türetilmiş sınıfların nesnelerini bilmeden kullanabilmelidir.

Bu en gözden kaçan prensiplerden biri gibi görünüyor.

Sorunlara neden olan “is a” tekniğinin klasik örneği daire-elips problemidir (ya da dikdörtgen kare problemdir). Ancak, ben penguen kullanacağım.

İlk önce, gökyüzünde uçan kuşları gösteren bir uygulama düşünün. Birden fazla kuş türü olacaktır ve bu nedenle geliştirici, yeni kuş türlerinin eklenmesiyle ilgili kodu “kapatmak” için Açık Kapalı Prensibini kullanmaya karar verir. Bunu yapmak için, aşağıdaki soyut Kuş temel sınıfı oluşturulur:



BirdsFlyingAroundApp sürümünün büyük bir başarıdır. İkinci versiyon, kolaylıkla başka 12 farklı kuş türünü ekler ve ayrıca bir başarıdır. Yaşasın Açık Kapalı Prensibi! Ancak, uygulamanın üçüncü sürümü penguenleri desteklemek için gereklidir. Geliştirici, Kuş sınıfından kalıt alan yeni bir Penguen sınıfı yapar, ancak bir sorun vardır:



Bir geçersiz kılma yöntemi hiçbir şey yapmazsa veya yalnızca bir istisna atarsa, muhtemelen LSP'yi ihlal ediyorsunuzdur.

Uygulama çalıştırıldığında tüm uçan modeller yanlış görünür, çünkü Penguen nesneleri setAltitude yöntemini önemsemez. Penguenler sadece yerde dolaşıyorlar. Geliştirici OCP'yi izlemeye çalışsa da başarısız oldu. Penguen sınıfına uyması için mevcut kodun modifiye edilmesi gerekir.

Bir penguen teknik olarak “kuş” iken, Kuş sınıfı tüm kuşların uçabileceğini varsaymaktadır. Penguen alt sınıfı uçuş varsayımını ihlal ettiğinden, Kuş sınıfı için Liskov'un Yerine Geçme Prensibi’ni karşılamıyor.

LSP'yi İhlal Etmek Neden Kötüdür?

Soyut bir temel sınıf kullanmanın amacı; gelecekte yeni bir alt sınıf yazıp mevcut, çalışan ve test edilmiş bir koda ekleyebilmenizdir. Açık Kapalı Prensibinin özü budur. Ancak, alt sınıflar soyut temel sınıfın arayüzüne uygun bir şekilde bağlanmadığında, mevcut alt kodu gözden geçirmeniz ve hatalı alt sınıfları içeren özel durumları hesaba katmanız gerekir. Bu, Açık Kapalı Prensibinin açıkça ihlalidir.

Örneğin, bu kod parçasına bir bakınız:



LSP, kodun Kuş nesnesinin gerçek sınıfını bilmeden çalışması gerektiğini söylüyor. Ya devekuşu gibi bir başka uçamayan kuş türü eklemek isterseniz? O zaman mevcut tüm kodunuzu gözden geçirmeli ve Kuş işaretçilerinin gerçekten Devekuşu işaretçisi olup olmadığını kontrol etmelisiniz.

İki Olası Çözüm

Mevcut kodu modifiye etmeden Penguen sınıfını ekleyebilmek isteyebiliriz. Bu, kötü kalıtım hiyerarşisini LSP'yi karşılayacak şekilde düzelterek sağlanabilir.

Sorunu çözmenin çok iyi olmayan bir yolu, isFlightless adlı Kuş sınıfına bir yöntem eklemektir. Bu şekilde, en azından OCP'yi ihlal etmeden uçamayan kuş sınıfları eklenebilir. Bu, şöyle bir kodla sonuçlanacaktır:



Bu gerçekten geçici bir çözümdür. Temel sorunu çözmedi. Sadece sorunun belirli bir nesne için var olup olmadığını kontrol etmenin bir yolunu sağlar.

Uçamayan kuş sınıflarının uçan sınıfları üst sınıflarından kalıt almadığından emin olmak daha iyi bir çözüm olacaktır. Bu böyle yapılabilir:



Kuş temel sınıfı, herhangi bir uçan işlevsellik içermez ve FlightfulBird alt sınıfı, bu işlevselliği ekler. Bu, bazı işlevlerin hem Kuş hem de UçanKuş nesnelerine uygulanmasına izin verir. Ancak, uçamayan olabilecek Kuş nesneleri, FlightfulBird nesnelerini alan işlevlere dönüştürülemez.

Bu serideki bir sonraki bölümde, Bağımlılık Enjeksiyonunun son bölümü daha ayrıntılı olarak tartışmadan önce kalan 2 prensip incelenecektir.

KAYNAK: https://medium.com/aelfblockchain/aelf-tech-talks-dependency-injection-part-2-c2525376e8e8

Aelf Çin'de Blockchain’e ve DLT Ulusal Standardı'na Rehberlik Etmeye Yardımcı Oluyor

Aelf, “Bilgi Teknolojileri Blok Zinciri ve Dağıtılmış Defter Teknolojisi (Distributed Ledger Technology – DLT) Referans Mimarisi” Ulusal Standartlar Derleme Toplantısına katıldı.



20 Eylül 2019'da Sanayi ve Bilgi Teknolojileri Bakanlığı CESI (Çin Elektronik Teknolojisi Standardizasyon Araştırma Enstitüsü) tarafından düzenlenen “Bilgi Teknolojileri Blok Zinciri ve Dağıtılmış Defter Teknolojisi Referans Mimarisi” Ulusal Standartlar Derleme Toplantısı Şanghay’da yapıldı. Toplantıya katılmak için Aelf Teknik Ekosistem Direktörü Zongzhe Huang; Çin Halk Bankası’ndan, Çin Menkul Kıymetler Düzenleme Komisyonu’ndan, Nankin ve Fudan Üniversiteleri’nden ve diğer kurum ve kuruluşlardan kıdemli uzmanlarla birlikte toplantıya davet edildi.

Ulusal Standartlar Derleme Toplantısı; Bilgi Teknolojileri Blok Zinciri ve Dağıtılmış Defter Teknolojisi Referans Mimarisinin ulusal standardına odaklandı. Toplantıda, aşağıdaki hususlara ilişkin tartışmalar yer aldı:

• Blockchain referans mimarisinin kullanıcı ve fonksiyonel görünümü

• Kullanıcı görünümü roller, alt roller ve etkinlikleri ve roller arasındaki ilişkileri içerir

• Fonksiyonel görünüm, fonksiyonel bileşenleri ve bunların belirli fonksiyonlarını içerir

• Fonksiyonel bileşenler arasındaki ilişkiler

Uzmanlar ve bilim adamları, “Bilgi Teknolojileri Blok Zinciri ve Dağıtılmış Defter Teknolojisi Referans Mimarisi” konulu titiz bir analiz ve derinlemesine gösteri yönettiler. Huang, nihai karar için oy kullanmadan önce tartışmaya aktif olarak katıldı. Uzmanlar ve bilim adamları; kendi görüşlerini paylaştı, farklı endüstri perspektiflerinden revizyon görüşlerini sağladı ve fikir alışverişi yaptı ve bir sonraki adım için hazırlık planını açıkladılar.



Gelişen bir teknoloji olarak Blockchain; finansal hizmetler, tedarik zinciri yönetimi, eğlence, akıllı üretim, sosyal refah ve eğitim istihdamı alanlarında geniş bir uygulama alanına sahiptir. Blockchain standardizasyonu; Blockchain anlayışını birleştirmeye, çeşitli endüstrilerdeki Blockchain uygulamalarını yönlendirmeye ve Blockchain'in temel teknik konularını desteklemeye yardımcı olur.

Aelf, Blockchain endüstrisinin standardizasyonuna katkıda bulunmak için hem teknik hem de pratik açıdan endüstri standartları tartışmalarına aktif olarak katılmaya ve endüstri standartlarının iyileştirilmesine katkıda bulunmaya devam edecektir.

KAYNAK: https://medium.com/aelfblockchain/aelf-helps-guide-blockchain-and-dlt-national-standard-in-china-4805b538e16a

Aelf, Huawei Cloud'a Teknoloji Partneri Olarak Katıldı ve Dijital Dönüşüme Yardımcı Olmak için 2019 Huawei Connected Konferansına Davet Edildi!

Telekom endüstrisinde bir Blockchain sağlayıcısı olarak Aelf iş birlikleri konusunda Huawei ile görüşmelerde



 18 Eylül 2019'da üç günlük Huawei Connect 2019 Konferansı (HC2019), Şangay Dünya Fuar Kongre ve Gösteri Merkezi'nde ve Şangay Dünya Fuar Gösteri Salonu'nda başladı. Bu konferansın konusu “Gelişmiş Akıl, Aklın Yeni İrtifalarını Sağlar” idi. Açılış konuşmaları, yuvarlak masa toplantıları ve alt forum tartışmaları; Huawei Cloud, Akıllı Bilişim, Bağlantı, Ağ Güvenliği, Akıllı Şehirler, Akıllı Ulaşım, Akıllı Finans, Geliştirici ve Kurumsal Hizmetler ve Devlet İşleri ve Eğitim konusundaki konuşmalar için bir platform sağladı. Bir Huawei Cloud teknoloji ortağı olarak Aelf, Huawei Connect 2019 Konferansı’na ve Akşam Yemeği'ne katılmak üzere davet edildi.

Liang Chen (Huawei Cloud Global Partner İş Birimi Başkanı), Lim Chee Siong (Huawei Cloud Güney Pasifik bölgesinin Baş Pazarlama Yöneticisi), Kevin Teoh (Huawei Cloud Asya Pasifik İş Geliştirme Direktörü) ve Justin Ching Lee (Huawei Cloud Global Partner İş Birimi Menajeri) yemeğe katıldı. Nancy Yan (Huawei Cloud Asya Pasifik Partner İş Birimi Başkan Yardımcısı), Aelf’i bizzat memnuniyetle karşıladı ve katıldıkları için Aelf ekibine teşekkür etti. Aelf Kurucu Ortağı & COO’su Zhuling Chen, akşam yemeğinde Huawei Cloud Teknoloji Partnerlerinin bir temsilcisi olarak kısa bir konuşma yaptı.

“Aelf'in HC2019 endüstri festivaline Huawei Cloud teknoloji ortağı olarak katılması için davet edildiğinden dolayı çok mutluyum. Akıllı dünyanın hızlanmasıyla birlikte, gittikçe daha fazla işletme ve devlet kurumu aklın değerini ve önemini fark etmektedir. Endüstrinin önde gelen merkezi olmayan bulut bilişim platformu olarak Blockchain bulut hizmetlerinin iş birliğini keşfetmek ve optimize etmek, güvenilir bir dijital ekonominin temel taşını oluşturmak ve işletmeler için daha güvenli hizmetler sunmak için Huawei Cloud ile çalışmayı umuyoruz. Güvenilir, verimli ve yüksek kaliteli Blockchain bulut hizmetleri; işletmelerin katlanarak büyümesini mümkün kılıyor.”

Zhuling, Blockchain’in Telekomünikasyon Operatörlerine hizmet etme potansiyeli hakkında Liang Chen (Huawei Cloud Global Partner İş Birimi Başkanı) ile uzun bir görüşme yaptı. Aelf, dünya çapında birkaç önde gelen Telekomünikasyon Operatörü ile görüşmelerde bulundu ve Huawei, global olarak Telekomünikasyon Operatörleri için en büyük global yazılım ve donanım sağlayıcısıdır. Bu partnerlik, iki tarafın da uzmanlıklarını geliştirmeleri için karşılıklı olarak yararlı olacaktır.

Huawei Cloud’un çapraz zincir projesine dahil edilen aelf Enterprise 0.7.0 Beta; tam bir Blockchain sistemi, geliştirme kitleri için destek, web araçları ve programları için destek gibi özelliklere sahiptir. Geliştiriciler; sağlanan geliştirme kitleri ve araçlarına dayalı olarak uygulamaları hızlıca dağıtabilir. Ek olarak Aelf, kullanıcıların işletmelere ve geliştiricilere kolayca güçlü uygulamalar geliştirmelerine yardımcı olmak için iş mantığını ve uygulama geliştirmeye odaklanmalarını sağlayan bir rehber öğretici sunar.



Aelf, iş dünyasının kendi kendini geliştirmesi ve refahını ilerletmek için teknoloji ve ileriye dönük bir endüstri perspektifinden yararlanır. Huawei ve Aelf, kurumsal müşterilerine hizmet etmede iş birliği için daha fazla fırsat keşfetmeye devam edecektir. Sektördeki konumumuzu derinleştirip teknolojik avantajları sağlayarak Aelf, Huawei Cloud ile olan geniş kapsamlı iş birliğimizi daha da güçlendirecektir.

Aelf Enterprise Huawei Cloud Adresi --> https://marketplace-intl.huaweicloud.com/product/00301-129125-0--0

KAYNAK: https://medium.com/aelfblockchain/aelf-joins-huawei-cloud-as-technology-partner-invited-to-2019-huawei-connected-conference-to-aid-ac97b095886b

Aelf Teknik Konuşmalar: Bağımlılık Enjeksiyonu Bölüm 1

Yiqi Zhao tarafından yazılmıştır



Bağımlılık enjeksiyonu (dependency injection) nedir?

Geliştirici topluluğu içerisinde, “bağımlılık” olarak adlandırılan bir konsepte sahibiz. Bir programın bir üçüncü parti kütüphanesini kullanması gerektiğinde, bu kütüphaneyi bağımlılık olarak adlandırılabilir. Fakat “enjeksiyon” nereden geliyor?

Bir insana değer bulmak için karşıtına bakmanız gerektiği söylenir. Bağımlılık enjeksiyonunun karşıtı bağımlılık aramasıdır (dependency lookup). Bağımlılık enjeksiyonu ve bağımlılık araması, Kontrolün İnversiyonu (Inversion of Control - IoC) uygulamasının iki yoludur.

IoC ve Bağımlılık Enjeksiyonunun temel amacı bir uygulamanın bağımlılıklarını ortadan kaldırmaktır. Bu, sistemi daha ayrışmış ve bakımlanabilir kılar.

IoC

İlk önce IoC'yi anlamaya çalışalım. Eski bilgisayar programlama günlerine geri dönerseniz program akışı, kendi kontrolünde çalıştırırdı. Örneğin, aşağıdaki akış şemasında gösterildiği gibi basit bir sohbet uygulaması akışını düşünelim.

1- Kullanıcı sohbet mesajı gönderir.

2- Uygulama, diğer taraftan gelen mesajı bekler.

3- Hiçbir mesaj bulunamazsa, 2. adıma gider ya da 4. adıma geçer.

4- Mesajı görüntüler.

5- Kullanıcı çalışmalarına devam eder.



Şimdi program akışını yakından analiz ederseniz, bu sıralıdır. Program kendi kendini kontrol ediyor. IoC, programın kontrol akışını yönetecek başka birine devrettiği anlamına gelir. Örneğin, sohbet uygulaması olayını temel alarak yaparsak programın akışı aşağıdaki gibi olacaktır:

1- Kullanıcı sohbet mesajı gönderir.

2- Kullanıcı çalışmalarına devam ediyor.

3- Uygulama olayları dinler. Bir mesaj gelirse, olay etkinleşir ve mesaj alınır ve görüntülenir.



Programın akışını görürseniz, sıralı değildir, olayı temel alır. Yani şimdi kontrol tersine çevrildi. Akışı kontrol eden dahili program yerine, olaylar program akışını yönlendirir. Olay akışı yaklaşımı, daha fazla esnekliğe yol açan dolaysız bir başvuru olmadığından daha esnektir.

IOC'nin sadece olaylar tarafından uygulandığı sonucuna varmayın. Kontrol akışını geri arama delegeleri, gözlemci modeli, olaylar, DI (Bağımlılık enjeksiyonu) ve başka birçok yolla delege edebilirsiniz.

DI (Bağımlılık enjeksiyonu) IOC'nin bir alt kümesi iken IOC genel bir ana terimdir. IOC, uygulama akışının ters çevrildiği bir konseptir.

Daha önce bahsedilen iki yöntem, bağımlılık enjeksiyonu ve bağımlılık araması, her yerde kullanabileceğiniz yöntemlerdir.

Servis konumlandırıcısını (service locator) Spring Framework’de duymuş olabilirsiniz. Şimdi Servis konumlandırıcısının bir model karşıtı olduğunu düşünen birçok öncüller vardır. Aslında Servis konumlandırıcısı, bağımlılık aramanın somut bir uygulamasıdır. Servis konumlandırıcısı ve bağımlılık enjeksiyonu fikri esasen zıt olmasına rağmen, MS.DI bağımlılık enjeksiyon yapısını uygularken Servis konumlandırıcısını kullanır.

Eğer Spring’i kullanmadıysanız, sorun değildir.

İkisi arasındaki ilişkiyi açıklamaya çalışalım. Açıkçası, Bağımlılık Enjeksiyonu temel olarak enjekte etme ile ilgilidir. Yığın Taşması (stack overflow) üzerine Bağımlılık Enjeksiyonu konusunda çok ilginç bir cevap vardır. Soru, beş yaşındaki bir çocuğa bağımlılık enjeksiyonunun nasıl açıklanacağıdır:

Bir çocuk kendi başına buzdolabından bir şeyler çıkardığında, sorun çıkartabilir. Kapıyı açık bırakabilirler veya anne ya da babanın sahip olmasını istemediği bir şey alabilirler. Hatta sahip olmadıkları veya süresi dolmuş bir şeyi bile arıyor olabilirler.

Yapmaları gereken şey “öğle yemeği ile içmek için bir şeye ihtiyacım var” gibi ihtiyacı belirtmek ve sonra ebeveyn, yemek için otururken bir şeylerinin olduğundan emin olacaktır.

Bu yüzden doğru yaklaşım, çocuklara neye ihtiyaçları olduğunu sormaktır; o zaman buzdolabından bir şey bulur ve onlara veririz.

Bir benzetme yapacak olursak buzdolabından bir şeyler alan çocuklar bağımlılık aramaya benzer; çocuklara yetişkinler olarak bir şeyler sunduğumuzda, bu bağımlılık enjeksiyonudur.

Bağımlılık enjeksiyonunu ayrıntılı olarak tartışmadan önce, tasarım modellerinin beş prensibini gözden geçirmemiz gerekir (bazı yerler altı hatta yediden bahseder, ancak bunlar temel olarak beştir). Bu serideki 2. bölümde bu ilkelerin ilk çifti incelenecektir.

KAYNAK: https://medium.com/aelfblockchain/aelf-tech-talks-dependency-injection-part-1-a95714f41042

🔊 Aelf COO'su ve Kurucu Ortağı Zhuling Chen, Şanghay'da düzenlenen Staking Sonbahar Forum'una katıldı. Farklı paydaşların staking ekonomideki rolleri ve Pos'taki tipik zorluklar hakkında konuşuldu.

Aelf'in Türkiye topluluk moderatörlüğünü yapmaktayım.

kursat aelf calısanı mısın

Aelf Blockchain NASDAQ, Google Cloud, Oracle, SAP, Ethereum ve Bitcoin ile iletişim kuracak



Aelf; yalnızca iletişim kurma yeteneğine sahip olmayan, aynı zamanda güvenilir ve değişmez veri Oracles’ı aracılığıyla diğer Blockchainler’den ve veri kaynaklarından doğrulanabilir verilere dayanan birkaç Blockchain’den biri olacaktır.

Chainlink Oracles ile bağlanarak Aelf Blockchain; NASDAQ, Google Cloud, Oracle ve SAP gibi veri kaynaklarına ve Bitcoin ve Ethereum gibi Blockhainler’e erişime sahip olacaktır. Oracles, veriyi doğrulayarak verinin Aelf Blockchain’e gönderilmeden önce hem güvenilir hem de doğru olmasını sağlar. Bu, ekosistemde çalışan akıllı sözleşmelerin doğruluğunu ve güvenliğini büyük ölçüde artırır.

Ek olarak Aelf ekosistemi dışında bu tür güvenilir veriler sağlayarak Blockchain uygulamasının bir çözüm olarak uygulanması, daha önce benzer çözümlerin uygulanması konusunda endişeli olan birçok işletme için gerçekçi bir seçenek haline gelmiştir.

Bu neden benzersizdir?

Blockchainler doğal olarak diğer veri kaynaklarına veya Blockchainler’e kendi başlarına bağlanma yeteneğinden yoksundur. Bu, belirli sonuçlara veya durumlara dayanarak yürütmeye çalışan akıllı sözleşmeler için çok sınırlı bir mevcut veri setiyle sonuçlanır.

Bu temel konuyu hafifletmek için diğer kaynaklardan veri girişine izin vermek için Blockchainler’e bağlı bağlayıcıların geliştirilmesi, bir Oracle şeklinde mevcut olan birçok seçenekle sonuçlanmıştır. Bu Oracles; akıllı sözleşmeden veri talebini alan, arama yapan ve ilgili sonuçları derleyen merkezi bir 3. taraftır. Bu, bir anlamda halka açık bir merkezsizleşmiş Blockchain’in amacını yitirerek bu Oracles’lara büyük ölçüde güven duyulmasını gerektirir. Oracles, Blockchain’deki en zayıf halka haline gelir ve akıllı sözleşmelerin hatalı verilere bir cevap olarak yanlış bir işlem yürütmesine neden olabilecek manipülasyon veya kurcalamaya açıktır.

Blockchainler’e gerçek zamanlı veriyi güvenilir ve doğrulanabilir bir şekilde sunan çok az seçenek vardır.

Akıllı Sözleşmeler nedir?

Bir akıllı sözleşme; merkezsizleşmiş bir Blockchain altyapısında yürütülen belirleyici, kurcalamaya karşı korumalı ve güvenilir bir dijital anlaşmadır.
Akıllı sözleşmelerin iki nedenden dolayı standart, günlük sözleşmeler üzerinde üstünlüğü vardır.

İlk olarak akıllı sözleşmeler; güvenilir, paylaşılan kayıtlardır. Bireysel tarafların tek bir doğruluk kaydının olmamasından dolayı birden fazla departmanın birbiriyle çelişen iş akışlarına sahip olduğu modern şirketler için bir nimet olan kendi yedek kopyalarını tutmalarına gerek olmadığından çok güvenlidirler.

İkinci olarak akıllı sözleşmeler, oldukça belirleyicidir. Geleneksel senaryolarda sözleşmeler, hata veya isteksizlik dışında kararlaştırıldığı gibi yürütülmeyebilir. Akıllı sözleşmeler, tam olarak yazıldığı gibi yürütüldüğü ortamlarda çalıştırılır ve her adımda onay gerektirmez. Önceden belirlenmiş koşullar yerine getirilmişse, anahtar parametreler otomatik olarak yürütülür.

Oracles nedir?

Yukarıda bahsedildiği gibi Oracles, temel olarak bir Blockchain’i dış veri kaynaklarına, pazar yayınlarına veya web API'lerine bağlayan bir portaldır. Gerçek dünya pazarlarındaki ve web API'lerindeki veri yayınları, genellikle Blockchainler ve akıllı sözleşmeler gibi belirleyici değildir. Oracles, dış ve deterministik olmayan bilgileri bir Blockchain’in belirli koşulları anlayabileceği ve yürütebileceği bir formatta özümseyebilecek bir köprü görevi görür.



Aşağıdakiler dahil olmak üzere çeşitli Oracles biçimleri vardır:

- Donanım Oracles
- Yazılım Oracles
- Konsensüs Oracles
- Gelen Oracles
- Giden Oracles

Donanım Oracles, somut fiziksel nesnelerle entegre sensörlerdir. Birincil örnekler, ürünlerin çevresel koşulları gibi verileri Blockchain’e beslemek için RFID etiketlerinin kullanılmasıyla tedarik zinciri takibinde olacaktır.

Yazılım Oracles, web API'leri gibi üçüncü taraf kaynaklardan veri çeken ve uçuş durumları ve hava durumu verileri gibi gerçek dünya bilgilerini içerebilen en yaygın formdur.

Konsensüs Oracles, merkezsizleşmiş Oracles'e doğru bir adımı temsil eder ve özgünlüklerini ve doğruluğunu belirlemek için çeşitli Oracles'dan gelen verileri özel yöntemlerle toplamaya dayanır.

Gelen Oracles, “bu fiyat bir varlık tarafından karşılanıyorsa, bir satış tetikle” gibi yazılım Oracles’ları ile ilgili “eğer bu gerçekleşirse bunu yap” senaryolarını yansıtır.

Giden Oracles, akıllı sözleşmelerin üzerinde bulundukları Blockchain ağının dışındaki kaynaklara veri göndermesine olanak tanır ve aynı zamanda Yazılım Oracles’larıdır.

Chainlink Çözümü

Chainlink, akıllı bir sözleşmeyi tetikleyen bir Blockchain’e dahil edilmeden önce veri doğruluğunu tanımlayan ve doğrulayan merkezi olmayan bir Oracle ağı geliştirmiştir. Chainlink Blockchain, akıllı sözleşmeler tarafından yapılan bireysel veri taleplerine cevap veren oracle düğümlerinden oluşur. Blockchain sistemine 3 bileşen vardır:

• İtibar Sözleşmesi
• Emir Eşleştirme Sözleşmesi
• Toplama Sözleşmesi

İtibar Sözleşmesi, oracle servis sağlayıcı metriklerini depolamak ve izlemek için özel bir yöntem kullanır.

Emir Eşleştirme Sözleşmesi, bir servis seviyesi anlaşması (Service Level Agreement - SLA) alır ve eş zamanlı olarak oracle sağlayıcılarından teklif alırken SLA'nın veri parametrelerini kaydeder.

Toplama Sözleşmesi, oracle sağlayıcısının cevaplarını toplar ve ilk ChainLink sorgusunun son toplu sonucunu hesaplar.

Temel olarak bir akıllı sözleşme, Chainlink aracılığıyla SLA şeklinde bir veri talebi yapacaktır ve bu, oracle düğümlerinin her birine yayınlanacaktır. Oracle düğümleri, verileri sağlayacak ve veri talebini tamamlamak için bir teklif sunacaktır. Tüm bunlar Emir Eşleştirme Sözleşmesi tarafından yönetilir, gönderilen veriler daha sonra farklı düğümlerden gelen birden fazla yanıtı karşılaştırarak Toplama Sözleşmesi aracılığıyla doğruluk için karşılaştırılır.

Tamamlanan her bir SLA'dan kaynaklanan ilgili bilgiler, İtibar Sözleşmesine geri gönderilecektir ve sonuç olarak alınan teşviki etkileyen her bir düğümün itibarını değiştirir.

SLA, kullanıcıların Oracles'ın itibarı veya kaç Oracle’ın dahil edilmesi de dahil olmak üzere istenen veri kümeleri için açık parametreler ve girdiler belirlemesine izin verdiği için bu sistemin temel bir bileşenidir.

Zincir dışı verilerden zincir içi verilere geçiş, her bir oracle tarafından bilginin zincir dışından alınması ve doğrulama için zincir içine gönderilmesi ile tamamlanır. Bir veri talebini tamamlamak için kullanılan verilerine sahip olan Oracles, itibarlarına göre ağırlaştırılan LINK adı verilen Chainlink tokenleri ile sağlanır.



Hali hazırda Chainlink; Bitcoin, Ethereum ve Hyperledger gibi Blockchainler’in yanı sıra NASDAQ, Google Cloud, Oracle, SAP ve çoklu bankalar gibi diğer veri kaynaklarından da veri çekmektedir. Ek olarak Aelf ile bağlanarak sadece bu kaynakların herhangi birinden gelen veriler, Aelf Blockchain'deki akıllı sözleşmeleri tetiklemekle kalmaz; aynı zamanda Aelf Blockchain'deki veriler artık Ethereum veya Hyperledger gibi Blockchainler de dahil olmak üzere diğer platformlardaki olayları tetiklemek için kullanılabilir.

İletişim birlikte çalışabilirlik anlamına mı geliyor?

Birçok Blockchain’in geliştirmek istediği özelliklerden biri, çapraz zincir birlikte çalışabilirliğidir. İletişimi tartışırken bu kolayca Blockchain birlikte çalışabilirliği olarak yanlış yorumlanabilir ancak gerçekte onlar aynı şey değildir. Evet, birlikte çalışabilirlik Blockchainler arasında iletişim gerektirir ancak ayrıca bundan da fazlasını gerektirir. Aelf Blockchain, uygun Blockchain birlikte çalışabilirliği özelliğine sahip tam bir çözüm geliştiriyor ve bu, Chainlink’in oracle ağı ile çalışacaktır.

KAYNAK: https://medium.com/@mappopk/aelf-blockchain-will-communicate-with-nasdaq-google-cloud-oracle-sap-ethereum-and-bitcoin-e6863f3b27a9

Merkezi Olmayan Uygulamalar (Dapps) Blockchain Benimsenmesini Olumlu mu Yoksa Olumsuz mu Etkiliyor?



DApp'ler potansiyel olarak Blockchain’in benimsenmesinde en önemli bileşenlerden biridir. Onlar bir anlamda benimsenmenin gerçek dünyasıdır, bir yazılım parçasından bir çözüme geçişi temsil ediyorlar.

DApp’ler nedir?

DApp, merkezi olmayan uygulamanın kısaltmasıdır. Merkezi olmayan bir Blockchain üzerinde çalışan herhangi bir uygulamaya teorik olarak dApp denebilir. DApp'lerin çoğunluğu, temel Blockchain’i oluşturanlarla ilişkili olmayan 3. taraflar veya ekipler tarafından geliştirilmiştir. Farklı Blockchainler için tasarlanmış birden fazla varyasyon mevcut olmasına rağmen bir dApp, bir bireysel Blockchain’e özgüdür.

Windows ve Apple’da mevcut olabilen bir uygulamaya benzer şekilde, üzerinde çalışması gereken işletim sistemine bağlı olarak ayrı bir yükleyiciye sahip olacaktır. Temel olarak bir dApp’ın eşdeğeri, bir yükleme dosyası aracılığıyla PC'nize veya telefonunuza yüklediğiniz herhangi bir uygulamadır (bazıları etkileşimli bir web sitesi olmasına rağmen) ve temel Blockchain kendi cihazınızın işletim sistemidir.

Her şey bir dApp değildir

Blockchain üzerinde çalışan bazı uygulamalar, teknik olarak bir dApp olarak sınıflandırılmayabilir çünkü IBM'in izin verilen bir özel Blockchain üzerinde çalışan bir uygulama olan FoodTrust uygulaması gibi tamamen merkezsizleştirilmemiş olabilirler. Genel olarak konuşursak, izin verilen özel bir Blockchain sınırlı ya da merkezsizleşmemiş anlamına gelir ve bazı örnekler basitçe bir veri tabanı olarak sınıflandırılabilir.

Aslında, Blockchain teknolojisinin kurumsal düzeyde benimsenmesi için sınırlayıcı faktörlerden biri, Blockchain kullanan herhangi bir uygulamanın tamamen merkezsizleştirilmesi ve dolayısıyla kamuya açık hale getirilmesi gerektiği konusundaki yanlış anlama ile doğrudan ilgilidir. Bu açıkça yanlıştır. Gerçekte Blockchain’de çalışan bir uygulama, tamamen merkezi bir veri tabanı veya tamamen merkezi olmayan bir halka açık ledger ve bunların arasındaki her şey olabilir.

DApp'ın Yükselişi

Ethereum'un 2015 yılı ortalarında akıllı sözleşmelerin dahil edilmesi ile piyasaya sürülmesi, geliştiricilerin Blockchain özelliklerini kullanan uygulamaları uygun şekilde tasarlayabilecekleri ortamı yarattı. Bundan önce Blockchain kullanımı, tek tek izole edilmiş ve basit bir işlev olarak finansal işlemlerle sınırlıydı. Akıllı sözleşmelerin dahil edilmesi, sadece işlemlerin bir “if then” tasarımda birbirine bağlanmasına izin vermekle kalmadı, aynı zamanda uygulama potansiyelini diğer birçok sektöre ve endüstriye yaydı. dApp gelişiminin 2017'nin etkisi ile hareket etmesi 2 yıl sonrasına kadar değildi. Başka bir 2 yıl ve dApp gelişmesi, artık her gün onlarca dapp çalıştıran çoğu Blockchain platformu ile normdur.

State of the Dapps (https://www.stateofthedapps.com/ ) ve Dapp Review (https://dapp.review/ ) tarafından sunulan gibi DApp gelişimini destekleyen Blockchain platformları; Ethereum, Tron, EOS, IOST, WICC, STEEM, Ont, Neo, Loom, Tomo, Nas, Bos, POA, xDai, Klaytn, GoChain'den oluşur. Her bir web sitesi, bu platformlarda mevcut dApp'lerin çoğunluğunu sırasıyla 3.021 ve 3.113 dApp'ler ile listelemektedir.



Ethereum en fazla dApp sayısına sahip olmasına rağmen aktif kullanıcıların sayısı, EOS ile karşılaştırıldığında günde 4-8 kat daha düşüktür.





dApp Benimsenmesi

Daha da şaşırtıcı olan şey hem State of the Dapps hem de DappReview’in istatistiklerine göre, dApp başına ortalama 35-45 kullanıcı ve EOS’un dApp başına yaklaşık 150 kullanıcı ile en başarılı platform olmasıydı.

Bu, bu dApp'lerin çoğunun başarısının ciddi şekilde sınırlı olduğunu veya hiç etkili olmadığını gösterir. Aslında DappReview'a göre ilk 5 EOS dApp, aktif EOS kullanıcılarının %70'inden fazlasını oluşturuyor. Bir de bunun üstüne dApp’ların yarısından fazlası kumarhane ve yüksek risk kategorisine giriyor. Marka imajı ve ahlaki duruşlar üzerindeki endişeler nedeniyle bir bütün olarak, birçok kişi ve kuruluşlar bu dApp’ler ve potansiyel Blockchain ile bağlantılarını sınırladığından bu, büyük ölçüde benimsenmeyi sınırlayabilir.



Mevcut dApp durumuyla ilgili bir endişe, bunun daha geniş kamuoyuna verdiği zihniyet veya imajdır. Çok sayıda yüksek riskli ve kumarhane / gazino dApp'ler, halkın aklındaki olası Blockchain kullanım durumunu sadece riskli finansal teşvik programlarına daraltabilir. Gerçekte bu, bu teknolojinin uygulanabileceği birçok uygulamadan sadece biridir. En büyük ilerlemelerin bir kısmı, uygulamalarını tamamen merkezi olmayan bir şekilde geliştirmek istemeyen işletmeler tarafından gerçekleştirilmiştir.

Avustralya Menkul Kıymetler Borsası (ASX), ana platform olan CHESS'e (https://www.asx.com.au/services/chess-replacement.htm) Blockchain odaklı bir geliştirme şirketi olan Digital Assets aracılığıyla yeni bir yükseltme geliştiriyor. Bu projenin, 2016’dan beri prototip gelişimine rağmen, 2021'den önce tam olarak başlatılması beklenmemektedir. Bu uygulama, platformda kayıtlı kullanıcı olan binlerce kurum ve aracının kullanımına açık olacak ancak uygulama ASX tarafından yönetilecek ve çalıştırılacaktır.

IBM, Walmart ile FoodTrust (https://cointelegraph.com/news/national-fisheries-institute-and-ibms-food-trust-work-on-seafood-blockchain-traceability) adlı tedarik zinciri uygulamasını hayata geçirdi ve ABD, Avrupa ve Avustralya da dahil olmak üzere tüm dünyada endüstri genelinde sayısız müşteriye yer verdi. Bu uygulama, aynı zamanda izin verilen bir özel blockchain olarak da çalışmakta ve merkezsizleşmiş değildir.

Visa, sınır ötesi ödemeleri kolaylaştıran bir Blockchain esin kaynağı olan Visa B2B Connect'i (https://cointelegraph.com/news/visa-launches-global-cross-border-network-based-on-certain-aspects-of-blockchain) başlattı. Ağ, Hyperledger'ın (https://cointelegraph.com/tags/hyperledger) öğelerini birleştirmiştir ve IBM ile iş birliği içinde geliştirilmiştir.

Yukarıdakiler gibi işletmeler tarafından geliştirilen kullanım durumlarının çoğu, Blockchain’in belirli bir sorunu çözmek için geliştirilen daha büyük bir çözümün parçası olması gerçeğinden dolayı kullanıcılar tarafından küresel olarak daha geniş bir benimsenmeyi görecektir. Bu, çözdükleri belirli bir sorun olmadan Blockchain için bir uygulama sağlamak amacıyla geliştirilen dApp'lerin çoğuna zıttır.

Benimsenme açısından Blockchain teknolojisini sergilemek için bir dApp geliştirmenin faydalı olduğu zaman geçmiştir. Odak, kendilerini belirli bir endüstri veya bir Blockchain odaklı uygulama için bir yazılım çözümü olarak konumlandıran bir şirketle daha bütünsel olmalıdır. Ek olarak, yazılım çözümlerinin tam olarak ihtiyaçlar doğrultusunda geliştirilmesine olanak tanıyan temel halka açık ve özel Blockchain platform teknolojisinde iyileştirmeler yapılması gerekmektedir. Burası Aelf'in devreye girdiği yerdir. Mevcut işletmeler ve yazılım çözüm sağlayıcıları için doğru Blockchain uygulaması ile çözümlerini geliştirmek için ihtiyaçlarına uygun şekilde tasarlanmış bir tramplen etkisi sağlayacak bir platform geliştiriyoruz.

KAYNAK: https://medium.com/aelfblockchain/are-dapps-driving-or-derailing-blockchain-adoption-a2d66cb622a6

Aelf'in resmi Türkiye Telegram grubu olan https://t.me/aelf_turkish adresinde "Aelf Puan Yarışması" olarak adlandırılan yeni ve ödüllü bir topluluk etkinliği bugün itibariyle başlayacaktır. Tüm detaylar için https://t.me/aelf_turkish adresini ziyaret edebilirsiniz.

🔊 ELF, Crypto.com uygulamasında listelenmiştir.

https://twitter.com/cryptocom/status/1171320189075378178