Türkiye`nin Bitcoin Forum Sitesi

Geri git   Türkiye`nin Bitcoin Forum Sitesi > Tüm Kripto Coinlerin Tartışma Alanı > Kripto Para Birimleri > Altcoinler

Altcoinler Altcoinler


AELF ($ELF) Blockchain (ANA KONU)

Altcoinler


Altcoinler Altcoinler

 
Seçenekler Arama Stil
  #181  
Alt 20 Eylül 2019, 12:29
KursatAelf - ait Kullanıcı Resmi (Avatar)
Yeni Üye
 
İstanbul Avrupa Şubesi
Mesajlar: 190
Konular: 1
Ticaret Sayısı: (0)
Ticaret Memnuniyeti: (0%)
Standart Cevap: AELF ($ELF) Blockchain (ANA KONU)

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...01-129125-0--0

KAYNAK: https://medium.com/aelfblockchain/ae...d-ac97b095886b
Alıntı ile Cevapla
  #182  
Alt 22 Eylül 2019, 00:13
KursatAelf - ait Kullanıcı Resmi (Avatar)
Yeni Üye
 
İstanbul Avrupa Şubesi
Mesajlar: 190
Konular: 1
Ticaret Sayısı: (0)
Ticaret Memnuniyeti: (0%)
Standart Cevap: AELF ($ELF) Blockchain (ANA KONU)




Alıntı ile Cevapla
  #183  
Alt 24 Eylül 2019, 16:57
KursatAelf - ait Kullanıcı Resmi (Avatar)
Yeni Üye
 
İstanbul Avrupa Şubesi
Mesajlar: 190
Konular: 1
Ticaret Sayısı: (0)
Ticaret Memnuniyeti: (0%)
Standart Cevap: AELF ($ELF) Blockchain (ANA KONU)

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/ae...a-4805b538e16a
Alıntı ile Cevapla
  #184  
Alt 27 Eylül 2019, 10:13
KursatAelf - ait Kullanıcı Resmi (Avatar)
Yeni Üye
 
İstanbul Avrupa Şubesi
Mesajlar: 190
Konular: 1
Ticaret Sayısı: (0)
Ticaret Memnuniyeti: (0%)
Standart Cevap: AELF ($ELF) Blockchain (ANA KONU)

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/ae...2-c2525376e8e8
Alıntı ile Cevapla
  #185  
Alt 27 Eylül 2019, 10:48
KursatAelf - ait Kullanıcı Resmi (Avatar)
Yeni Üye
 
İstanbul Avrupa Şubesi
Mesajlar: 190
Konular: 1
Ticaret Sayısı: (0)
Ticaret Memnuniyeti: (0%)
Standart Cevap: AELF ($ELF) Blockchain (ANA KONU)

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

Alıntı ile Cevapla
  #186  
Alt 05 Ekim 2019, 11:48
KursatAelf - ait Kullanıcı Resmi (Avatar)
Yeni Üye
 
İstanbul Avrupa Şubesi
Mesajlar: 190
Konular: 1
Ticaret Sayısı: (0)
Ticaret Memnuniyeti: (0%)
Standart Cevap: AELF ($ELF) Blockchain (ANA KONU)

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



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

> İ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***65289;

> 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/ae...3-2c89a6159056
Alıntı ile Cevapla
  #187  
Alt 08 Ekim 2019, 09:26
KursatAelf - ait Kullanıcı Resmi (Avatar)
Yeni Üye
 
İstanbul Avrupa Şubesi
Mesajlar: 190
Konular: 1
Ticaret Sayısı: (0)
Ticaret Memnuniyeti: (0%)
Standart Cevap: AELF ($ELF) Blockchain (ANA KONU)

-Yorum Yap & Kazan!

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

- Takip et
- Retweetle & Beğen
- 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/s...44710943969281

Alıntı ile Cevapla
  #188  
Alt 08 Ekim 2019, 19:54
KursatAelf - ait Kullanıcı Resmi (Avatar)
Yeni Üye
 
İstanbul Avrupa Şubesi
Mesajlar: 190
Konular: 1
Ticaret Sayısı: (0)
Ticaret Memnuniyeti: (0%)
Standart Cevap: AELF ($ELF) Blockchain (ANA KONU)

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/DIDem...--------------

KAYNAK: https://medium.com/aelfblockchain/ae...4-3015d4a5f7a1
Alıntı ile Cevapla
  #189  
Alt 11 Ekim 2019, 07:40
KursatAelf - ait Kullanıcı Resmi (Avatar)
Yeni Üye
 
İstanbul Avrupa Şubesi
Mesajlar: 190
Konular: 1
Ticaret Sayısı: (0)
Ticaret Memnuniyeti: (0%)
Standart Cevap: AELF ($ELF) Blockchain (ANA KONU)

***9989; Zhuling Chen ve Aelf Singapur ekibi, Huawei Konferansına katılmak üzere davet edildi. Zhuling; Aelf Blockchain'in avantajları ve sürekli büyüyen, olası kullanım durumları ve Huawei ile olan partnerlik ile ilgili bir sunum yaptı.







Alıntı ile Cevapla
  #190  
Alt 15 Ekim 2019, 11:52
KursatAelf - ait Kullanıcı Resmi (Avatar)
Yeni Üye
 
İstanbul Avrupa Şubesi
Mesajlar: 190
Konular: 1
Ticaret Sayısı: (0)
Ticaret Memnuniyeti: (0%)
Standart Cevap: AELF ($ELF) Blockchain (ANA KONU)

Blockchain Küresel Göç için Kutsal Kâse midir?



Göç; genellikle yeni bir ülkede demokratik bir varoluşu sürdürmeyi ümit eden savaş, baskı ve ırkçılıktan kaçan vatandaşlar için son çaredir. Blockchain teknolojisi; göçmenler, teknoloji uzmanları, hükümetler, Sivil Toplum Kuruluşları (STK'lar) ve bu süreçteki diğer seçmenler için ortaya çıkan çeşitli zorlukların çözülmesine yardımcı olabilir. Bu makalede Blockchain'in göç sürecini daha adil ve ilgili tüm taraflar için daha şeffaf hale getirmesine yardımcı olabilecek bazı yöntemleri inceleyeceğiz. İlk önce ABD Başkanı Donald Trump'ın önerdiği yeni göç politikalarına değineceğiz, daha sonra Blockchain teknolojisinin yardımıyla göçün daha demokratik hale gelebileceği 4 ana yöntem üzerinde duracağız.

Son zamanlarda ABD Başkanı Donald Trump'ın ABD'deki mülteci yerleştirmesini azaltmak için yarattığı tartışmalı yürütme emrine karşı çıkan bir hareket başladı. Trump'ın önerisi, 2020 mali yılı içinde ABD'ye girmesine izin verilen mülteci sayısını 18 bine kadar azaltabilir. Geçen yıl Trump, ülkeye kabul edilen mültecilerin sayısını 30 binin altında bir rekor olarak belirledi. Bunların çoğu, başkanın Meksika ve Orta Amerika’daki çeşitli ülkelerden gelen mültecilere bakış açısından kaynaklanıyor. Trump yönetimi tarafından bu yaklaşım, dünyadaki birçok kişi için kabul edilebilir değildir ve #Blackout4Refugees küresel etiketini yaratan etkendi. ABD’ye mültecilerin kabulüne ilişkin ortalama yıllık kota 1980’den başlayarak her yıl 95 bini aştı.

Blockchain teknolojisinin benimsenmesi, dünyanın en büyük zorluklarının çoğunu çözmede kritik öneme sahiptir. Halka Açık Blockchainler’in gerçekten devrimci yapan birçok özellik aşağıda uluslararası ve tanınmış Blockchain uzmanı Andreas Antonopoulos tarafından belirtilmiştir. Andreas'ın eğitim materyallerinin çoğunda odaklandığı 5 ana Blockchain teknolojisi dayanağı vardır: 1.) Açık 2.) Genel/Halka Açık 3.) Sınırsız 4.) Nötr/Yansız 5.) Sansür Dirençli. Blockchain teknolojisini gerçek bir ezber bozucu yapan 6. kalite, değişmezliğidir. Aelf’in Blockchain ağının, küresel göç uygulamalarının daha verimli ve şeffaf bir şekilde ilerlemesini sağlayacak bazı nitelikleri vardır. Bunlar arasında birlikte çalışabilirlik, optimize edilmiş bir yönetim yapısı, uyarlanabilirlik ve hızlı, yüksek derecede ölçeklenebilir bir protokol vardır.

Blockchain teknolojisinin göçmenler, hükümetler ve göçmenleri ülkelerine kitlesel olarak kabul eden diğer ögeler için şeffaflığı artırmaya yardımcı olabileceği çeşitli yöntemler vardır:

1. Dijital Kimliklere ve Diğer Temel Belgelere Erişilebilirlik

Göçmenlerin başka bir ülkeye göç etmeyi kabul edilmeden önce Kimlik (ID) ve diğer önemli belgelerini 2 yıla kadar hükümetlere teslim etmeleri gerekmektedir. Bunun gibi durumlar genellikle aşırı derecede verimsiz hükümet uygulamalarının ve diğer faktörlerin bir sonucudur. Dijital bir kimliğe uygun erişime sahip olmak, başka bir ülkeye göç etmiş biri için de çok önemlidir. Bir kullanıcının Passport, Sürücü Belgesi veya Kimlik Numarasının dijital bir versiyonunu saklamak, bireyin kimliğini her zaman kanıtlayabileceği anlamına gelir. Bu, yetkililerin kişisel bilgileri aramalarını ve göç etme haklarını sürdüren bir kişinin güvenilirliğini kanıtlamalarını sağlar. Dijital kimlikler ayrıca her yıl çok sayıda mülteci alan ülkelere yardımcı olmaktadır. Bu, yeni ülkelerine geniş sağlık hizmetleri ve sabıka kaydı kontrolleri yoluyla bireyleri eleme imkânı veriyor. Bu sürecin, dünya çapındaki uluslardaki yerli vatandaşların güvenliğini olumlu yönde etkilediği görülmüştür. Daha fazla şeffaflık, hem göçmenler hem de onları kabul eden ülkeler için daha fazla sorumluluk anlamına gelir. Blockchain teknolojisi; Myanmar, İsrail veya Macaristan gibi belirli etnik azınlıklardan yararlanılan bölgelerde gücün kötüye kullanılmasının önlenmesine yardımcı olabilir. Örneğin bir kişinin kimliğini kanıtlama yeteneği, Rohingya Müslümanları için yaşam ile ölüm arasındaki fark anlamına gelebilir. Blockchain teknolojisi; dünyamızdaki dijital kimliğin daha şeffaf, güvenli ve değişmez bir şekilde ilerlemesini sağlar.

2. Bir Butona Tıklayarak Değer Aktarımına Anında Erişilebilirlik Verilmesi

Dünya genelinde milyonlarca göçmen işçi düzenli olarak kendi ülkelerindeki ailelerine geri para gönderiyor, böylece hayatta kalabiliyorlar. Mobil Blockchain cüzdanlarını kullanmak, birçok bölgedeki kişilerin geleneksel banka hesaplarına erişmenin genellikle mümkün olmadığı finansmana erişmesini sağlar. ELF, Ethereum, Bitcoin veya diğer tür kripto paraların transferi; değerin bir alıcıdan diğerine anında aktarılmasını sağlar. Bankalar ve finansal kurumlar yüksek düzeyde ücretler alırlar ve işlemlerin tamamlanması günler alır. Bu, binlerce kilometre uzaklıkta aileleri için geçim kaynağı sağlayan göçmenler ve göçmen işçiler için sürdürülebilir değildir. Yeni mobil ödeme altyapısı; mobil Blockchain cüzdanına sahip kullanıcıların gıda, benzin ve hayatta kalabilmek için gereken çeşitli diğer temel malzemeleri ödemesini mümkün kılıyor.

3. Şeffaflığı Sağlamak İçin Mülteci Sorunlarına Yönelik Kitle Fonlamasının ve Bağışların Takibi

Blockchain teknolojisi; kitle fonlama işleminin güvenli, erişilebilir ve şeffaf olmasının yanı sıra genel olarak doğrulanabilir olmasını sağlar. Bu; para birimini oluşturmak, dağıtmak ve değiştirmek için bir platform olarak onu mükemmel yapar. Bu süreç, özellikle dünyanın her yerindeki vatandaşların, yeni ülkelerde yerleşen mültecilerin ve göçmenlerin refahına maddi olarak katkıda bulunmalarına yardımcı olmak için etkilidir. Bağışları ve kitle fonlama katkılarını daha güvenli ve dürüst bir şekilde takip edebilme yeteneği, hırsızlığı neredeyse imkânsız kılarken fonların maksimum etkisini de sağlar. İhtiyacı olanlara yardım etmek için bu modeli kullanan çeşitli Blockchain projeleri vardır. Blockchain teknolojisini kullanan kitle fonlaması platformlarının başarı oranları genellikle kullanmayanlardan daha yüksektir. Geleneksel işletme finansmanı genellikle elde etmek çok zordur, çünkü genellikle kendi kendini finanse etme, banka finansmanı veya risk sermayesi şirketleri tarafından gerçekleştirilir. Çoğu insan için kendi kendini fonlama son derece sınırlıdır, banka finansmanı ise güçlü gelir ve nakit akışı olan mevcut bir işi gerektirir. Girişim sermayesi, genellikle güçlü bir talebe sahip olan bir ürünü veya hizmeti ve piyasaya sürülmeye yakın bir işi gerektirir. Aelf'in Blockchain teknolojisi, ileriye dönük zor durumlarla karşı karşıya kalan göçmenler için kitle fonlaması sürecini geliştirmek için kullanılabilir.

4. Hükümetler ve Sivil Toplum Kuruluşları Tarafından Sahte/Hileli Göçmen Politikaları Olasılığını Azaltma

Göçmenler ve mülteciler, Blockchain teknolojisini yalnızca faydaları için kullanamazlar. Bu süreç; hükümetler, STK’lar ve diğer seçmenler tarafından haksız yere istismar edilen göçmen haklarının korunmasına yardımcı olur. Bu kuruluşlar, sıkı göç politikalarını dürüst ve güvenilir bir şekilde kullanarak sorumlu tutulmalıdır. Dünyadaki birçok ülkede, mültecilere ve göçmenlere yönelik şiddet içeren şiddetli suistimaller yaygın hale gelmiştir. Bu kesinlikle Macaristan'da açıkça görülüyor ve birçok durumda meydana geldi. Avrupa'nın önde gelen insan hakları ajansı, Avrupa Konseyi, kıtadaki vatandaşların haklarını korumaya çalışıyor. Mültecilere yardım etmeye çalışan sivil toplum kuruluşları taciz edildi ve sansürlendi. Ek olarak, Macaristan'da göçmenlerin haklarının korunmasına yardımcı olmak amacıyla mahkemeler Macar hükümeti tarafından büyük bir baskı altına alınmıştır.

Aelf'in birlikte çalışabilirlik yetenekleri (birden fazla Blockchain ile iletişim kurabilme), Chainlink'in oracle tabanlı teknolojisi ile birleştirildi (Chainlink’in merkezi olmayan Oracle ağı, tek bir başarısızlık noktasına açık olmayan akıllı sözleşmelere benzer şekilde oldukça sağlam bir güvenlik sağlar), verilerin herkes tarafından erişilebilen tek bir yerde bulunurken birden fazla taraf arasında paylaşılmasını sağlar. Doğru göç ve göç uygulamalarını belirlemek için önemli bilgiler güvenli ve doğrulanabilir bir şekilde bulunmalıdır. Aelf’in halka açık/özel Blockchain ekosistemi, ayrıca belirli verilerin potansiyel olarak kötü niyetli oyunculara karşı özel kalmasını sağlamanın yanı sıra önemli verilerin doğru taraflarca erişilebilir olmasını da sağlar.

Birçok yönden Aelf’in Blockchain projesine yaklaşımı, blok zincir teknolojisinin küresel olarak göç ve göç politikalarıyla ilgili sorunların çözümünde yardımcı olabileceği sorunların çoğunu yansıtmaktadır. Aelf’in güçlü yönetişim yapısı, Aelf Blockchain kullanıcılarına büyük bir şeffaflık hissi veriyor çünkü Aelf token sahipleri projenin ilerlemesine büyük katkıda bulunur. Bu; blockchain teknolojisinin, problemin göçmenlerinin, hükümetlerin ve STK'ların yüzeyine düzenli olarak çözülmesine yardımcı olarak dünyaya nasıl daha fazla şeffaflık sağladığına benzerdir. Aelf gibi çözümlerle, gün geçtikçe daha da belirginleşiyor ve dünyanın en büyük zorluklarının çoğunu çözmek için Blockchain teknolojisinden yararlanılabilir.

KAYNAK: https://medium.com/aelfblockchain/is...n-77432927f8a2
Alıntı ile Cevapla
Cevapla


Konuyu Toplam 3 Üye okuyor. (0 Kayıtlı üye ve 3 Misafir)
 
Seçenekler Arama
Stil



Coinforumu.com olan bitcoin forum sitemize eklenen içeriklerden, içeriği ekleyen kullanıcı sorumludur. Kullanıcı bazlı herhangi bir telif hakkından Coinforumu.com sitesi ve site yetkilileri sorumlu değildir. Telif hakkı kapsamında bulunan içerikler ile ilgili hukuksal bildirimleriniz için bu bağlantı ie iletişime geçebilirsiniz. Btc forumu yönetimi size en geç 48 saat içerisinde dönüş yapacaktır.