Yazılımda İstenmeyen “Push”lar: Kontrolü Nasıl Geri Alırız?

Yazılımda İstenmeyen “Push”lar: Kontrolü Nasıl Geri Alırız?

Yazılım dünyasında beklenmedik “push”lar, geliştiricileri ve son kullanıcıları sıkça zorlayan bir durumdur. Bu makalede, istenmeyen itici güçlerin nedenlerini ve bunlarla başa çıkma stratejilerini keşfederek, dijital kontrolü nasıl geri alabileceğinizi adım adım inceleyeceğiz.

“Push” Kavramının Teknik Boyutları: İstenmeyen İticilerin Anatomisi Nedir?

Teknoloji jargonunda “push” kelimesi, genellikle bir şeyin aktif olarak bir yerden başka bir yere gönderilmesi veya itilmesi anlamında kullanılır. Ancak, bu itici güç her zaman olumlu veya beklenen bir eylem olmayabilir. Geliştirme süreçlerinden son kullanıcı deneyimine kadar geniş bir yelpazede karşımıza çıkan istenmeyen “push”lar, dijital ekosistemde ciddi sorunlara yol açabilir. Örneğin, bir yazılım geliştiricisi için yanlış bir Git deposuna yapılan zorunlu bir “push” (itme) işlemi, projenin kararlılığını tehlikeye atabilirken, bir son kullanıcı için sürekli ve alakasız mobil bildirimler (push notifications) can sıkıcı bir hal alarak uygulama kullanımını bırakmaya neden olabilir. Ayrıca, otomatik sistem güncellemeleri veya API entegrasyonları aracılığıyla gelen kontrolsüz veri akışları da istenmeyen “push” kategorisine girer ve beklenmedik hatalara veya güvenlik açıklarına yol açabilir.

Bu istenmeyen iticilerin anatomisini anlamak, onlarla mücadele etmenin ilk adımıdır. Genellikle, bu durumlar ya iletişim eksikliği, hatalı yapılandırma, yetersiz test süreçleri ya da agresif pazarlama stratejileri gibi faktörlerden kaynaklanır. Bir geliştirme ekibinde, yeterli kod incelemesi (code review) yapılmadan veya dal koruma kuralları (branch protection rules) uygulanmadan yapılan “push”lar, ana kod tabanına (main codebase) istenmeyen değişikliklerin girmesine neden olabilir. Benzer şekilde, bir uygulamanın kullanıcı izni olmadan veya aşırı sıklıkta bildirim göndermesi, kullanıcıların uygulamaya olan güvenini zedeler ve olumsuz bir deneyim yaratır. Bu tür durumlar, sadece anlık problemlere yol açmakla kalmaz, aynı zamanda uzun vadede üretkenlik kaybına, sistem istikrarsızlığına ve hatta marka itibarının zedelenmesine neden olabilir. Bu nedenle, “istenmeyen push” kavramını çok yönlü bir şekilde ele almak ve her bir teknik bağlamdaki yansımalarını derinlemesine incelemek büyük önem taşımaktadır. Bu sayede, hem geliştirme süreçlerinde hem de kullanıcı etkileşimlerinde daha proaktif ve kontrollü yaklaşımlar sergileyebiliriz.

Sürüm Kontrol Sistemlerinde İstenmeyen “Push”lar: Git ile Yanlış Adımlar Nasıl Engellenir?

Sürüm kontrol sistemleri (Version Control Systems – VCS), özellikle Git, modern yazılım geliştirmenin temel taşlarından biridir. Ekiplerin birlikte çalışmasını kolaylaştırır, değişiklikleri izler ve hataları geri almayı sağlar. Ancak, Git’in güçlü yapısı, yanlış kullanıldığında istenmeyen “push”lara yol açabilir ve bu da projelerde ciddi aksaklıklara neden olabilir. Bir geliştiricinin yanlışlıkla henüz tamamlanmamış veya test edilmemiş kodları ana (main) dala itmesi (push etmesi), tüm ekibin işini durdurabilir veya canlı sistemlerde hatalara yol açabilir. Özellikle git push --force gibi komutlar, dikkatli kullanılmadığında geri dönüşü zor veya imkansız değişikliklere neden olabilir, çünkü geçmişi değiştirir ve diğer ekip üyelerinin depolarını (repositories) karmaşık bir duruma sokabilir.

Bu tür istenmeyen durumları engellemenin en etkili yollarından biri, sağlam bir süreç ve araç entegrasyonu oluşturmaktır. Öncelikle, dal koruma kuralları (branch protection rules) uygulamak kritik öneme sahiptir. GitHub, GitLab veya Bitbucket gibi platformlar, ana dallara doğrudan “push” yapılmasını engelleyebilir, birleştirme (merge) işlemlerinin sadece belirli koşullar altında (örneğin, başarılı kod incelemesi ve otomatik testler) gerçekleşmesini sağlayabilir. Bu kurallar, hatalı “push”ların ana kod tabanına ulaşmasını önemli ölçüde azaltır. Ayrıca, kod incelemesi (code review) süreçlerini zorunlu hale getirmek, her değişikliğin başka bir göz tarafından kontrol edilmesini sağlayarak potansiyel hataları ve istenmeyen “push”ları erkenden yakalamaya yardımcı olur. Ek olarak, geliştiricilerin git config push.default simple veya upstream gibi ayarları kullanarak varsayılan “push” davranışlarını daha güvenli hale getirmeleri, yanlış dallara itme riskini azaltır.

Yanlış bir “push” durumuyla karşılaşıldığında, hızlı ve doğru müdahale çok önemlidir. Eğer hatalı “push” henüz başka bir geliştirici tarafından çekilmediyse (pulled), git reset --hard HEAD~1 komutuyla yerel depoyu önceki duruma getirip, ardından git push --force-with-lease komutuyla uzak depoyu (remote repository) güncelleyebilirsiniz. Ancak, bu işlem dikkatli yapılmalı ve ekiple koordineli hareket edilmelidir. Eğer değişiklikler zaten çekildiyse, git revert komutu, hatalı değişiklikleri geri alan yeni bir commit oluşturarak geçmişi temiz bir şekilde korumanın daha güvenli bir yoludur. Bu sayede, istenmeyen değişiklikler düzeltilirken, projenin bütünlüğü de korunmuş olur. Özetle, sürüm kontrol sistemlerinde istenmeyen “push”ları engellemek için proaktif kurallar, sıkı süreçler ve doğru kurtarma stratejileri bir arada kullanılmalıdır. Aşağıdaki örnek, bir commit’i geri almayı göstermektedir:

git log --oneline # Geri alınacak commit'in hash'ini bul
git revert  # Belirtilen commit'i geri alan yeni bir commit oluştur
git push origin  # Değişiklikleri uzak depoya gönder

Bu adımlar, hem geliştirici hatalarını minimize eder hem de proje bütünlüğünü korur.

Otomatik Dağıtımlar ve Güncellemeler: Beklenmedik Değişiklikler Nasıl Yönetilir?

Günümüz DevOps (Geliştirme Operasyonları) kültüründe, sürekli entegrasyon ve sürekli dağıtım (CI/CD - Continuous Integration/Continuous Delivery) süreçleri, yazılımın daha hızlı ve güvenilir bir şekilde kullanıcılara ulaşmasını sağlar. Ancak, bu otomasyonun getirdiği hız, beraberinde beklenmedik "push" risklerini de taşır. Otomatik dağıtım hatları (pipelines) yanlış yapılandırıldığında veya yetersiz test süreçleriyle birleştiğinde, canlı sistemlere (production environments) hatalı kodların veya güncellemelerin istenmeden "push" edilmesi kaçınılmaz hale gelebilir. Bu durum, sistem kesintilerine, veri kayıplarına veya ciddi güvenlik açıklarına yol açabilir. Örneğin, bir e-ticaret sitesine otomatik olarak dağıtılan hatalı bir güncelleme, müşterilerin ödeme yapmasını engelleyerek milyonlarca dolarlık zarara neden olabilir.

Beklenmedik değişiklikleri yönetmek ve otomatik dağıtımların kontrolünü elden bırakmamak için çeşitli stratejiler mevcuttur. İlk olarak, dağıtım hatlarının her aşamasında kapsamlı otomatik testler (automated tests) uygulanmalıdır. Birim testleri (unit tests), entegrasyon testleri (integration tests) ve uçtan uca testler (end-to-end tests), kodun beklenen şekilde çalıştığından emin olmak için kritik öneme sahiptir. Ayrıca, hazırlık ortamları (staging environments) veya test ortamları (test environments), canlı sistemlerin birebir kopyası olmalı ve dağıtım öncesinde tüm değişikliklerin bu ortamlarda titizlikle test edilmesi sağlanmalıdır. Bu sayede, canlı sistemlere ulaşmadan önce potansiyel sorunlar tespit edilebilir.

Dağıtım stratejileri de beklenmedik "push" riskini azaltmada önemli rol oynar. Kanarya dağıtımları (canary deployments) veya mavi/yeşil dağıtımlar (blue/green deployments) gibi yöntemler, yeni sürümlerin kademeli olarak veya alternatif bir ortama dağıtılmasını sağlayarak riskleri minimize eder. Kanarya dağıtımında, yeni sürüm küçük bir kullanıcı grubuna sunulur ve performans ile hatalar izlenir. Eğer her şey yolundaysa, dağıtım kademeli olarak tüm kullanıcılara yayılır. Mavi/yeşil dağıtım ise, canlı sistemin bir kopyasına yeni sürümün dağıtılması ve sorunsuz çalıştığı teyit edildikten sonra trafiğin bu yeni kopyaya yönlendirilmesi prensibine dayanır. Bu yöntemler, olası hataların etkisini sınırlayarak hızlı bir geri alma (rollback) imkanı sunar. Ayrıca, özellik bayrakları (feature flags) kullanmak, yeni özelliklerin kod tabanına dahil edilmesine rağmen, canlı sistemde belirli kullanıcı gruplarına veya koşullara bağlı olarak etkinleştirilip devre dışı bırakılmasını sağlar. Bu, istenmeyen bir durum ortaya çıktığında, ilgili özelliği hızla kapatarak olumsuz etkiyi azaltma esnekliği sunar. Son olarak, her dağıtımın bir geri alma planı (rollback plan) olmalı ve bu plan düzenli olarak test edilmelidir. Böylece, bir sorun durumunda sistem hızla önceki kararlı durumuna döndürülebilir. Bu proaktif yaklaşımlar, otomatik dağıtımların hızından faydalanırken, beklenmedik "push"ların yol açabileceği olumsuzlukları en aza indirir.

Kullanıcı Deneyiminde İstenmeyen Bildirimler: "Push Notification" Cehenneminden Kurtuluş Yolları Nelerdir?

Mobil ve web uygulamalarının vazgeçilmez bir parçası olan "push notification"lar (anlık bildirimler), kullanıcıları önemli gelişmelerden haberdar etmek, uygulamaya geri dönmelerini teşvik etmek veya kritik bilgiler sunmak için güçlü bir araçtır. Ancak, bu bildirimler kontrolsüz ve düşüncesizce kullanıldığında, kullanıcılar için "istenmeyen bir push" haline gelerek, olumlu bir etkileşimden ziyade bir rahatsızlık kaynağına dönüşebilir. Aşırı bildirim bombardımanı, alakasız içerikler veya kötü zamanlanmış mesajlar, kullanıcıların uygulamayı sessize almasına, bildirim izinlerini kapatmasına veya en kötü senaryoda uygulamayı tamamen silmesine yol açabilir. Bu durum, hem kullanıcı deneyimini olumsuz etkiler hem de uygulamanın elde tutma (retention) oranlarını düşürür.

Kullanıcıları "push notification" cehenneminden kurtarmak ve bildirimleri değerli bir iletişim kanalına dönüştürmek için stratejik yaklaşımlar benimsemek gereklidir. İlk olarak, bildirim izinleri (permission requests) dikkatli bir şekilde yönetilmelidir. Kullanıcıya doğrudan "Bildirimleri açmak ister misiniz?" diye sormak yerine, bildirimin faydasını ve neden gerekli olduğunu açıklayan bağlamsal (contextual) bir izin talebi sunmak, onay oranlarını artırır. Örneğin, bir haber uygulaması, kullanıcının belirli bir konu hakkındaki ilk makaleyi okuduktan sonra "Bu konudaki son dakika haberlerini almak ister misiniz?" diye sorabilir. Bu, kullanıcıya kontrol hissi verir ve bildirimin değerini anlamasına yardımcı olur.

İkinci olarak, bildirimlerin sıklığı ve içeriği kişiselleştirilmeli ve kullanıcı tercihleriyle uyumlu olmalıdır. Kullanıcılara, hangi tür bildirimleri (örneğin, promosyonlar, haberler, işlem güncellemeleri) alacaklarını ve ne sıklıkta alacaklarını seçme imkanı sunan ayrıntılı kontrol seçenekleri (granular control options) sağlamak, memnuniyeti artırır. Bu, uygulamanın ayarlar menüsünde kolayca erişilebilir olmalıdır. Ayrıca, bildirimlerin zamanlaması da kritik öneme sahiptir. Kullanıcının uyku saatlerinde veya yoğun iş saatlerinde gönderilen alakasız bildirimler, sadece rahatsızlık yaratır. Akıllı algoritmalar veya kullanıcı davranış modelleri kullanarak bildirimlerin en uygun zamanda gönderilmesi sağlanabilir.

Son olarak, her bildirim bir değer taşımalıdır. Kullanıcıya fayda sağlayan, zamanında ve alakalı bilgiler içeren bildirimler, "istenmeyen push" olmaktan çıkarak değerli bir hizmete dönüşür. Örneğin, bir uçuş uygulaması, uçuşun rötar yaptığını veya kapının değiştiğini bildiren bir anlık bildirim gönderdiğinde, bu kullanıcı için hayati bir bilgi sağlar. Ancak, sık sık genel reklam içerikleri gönderen bir uygulama, kısa sürede kullanıcıların ilgisini kaybeder. Geliştiriciler, Web Push API'ları veya mobil SDK'lar (yazılım geliştirme kitleri) aracılığıyla bildirimleri gönderirken, bu en iyi uygulamaları göz önünde bulundurmalı ve kullanıcı geri bildirimlerini düzenli olarak analiz ederek bildirim stratejilerini sürekli optimize etmelidir. Bu sayede, "push notification"lar, kullanıcı deneyimini zenginleştiren güçlü bir araç olarak kalmaya devam edebilir.

Veri Entegrasyonları ve API "Push"ları: Kontrolsüz Veri Akışının Riskleri ve Çözümleri

Modern yazılım mimarilerinde, farklı sistemler arasında veri alışverişi, genellikle API'lar (Uygulama Programlama Arayüzleri) ve webhook'lar (web kancaları) aracılığıyla gerçekleşir. Bu entegrasyonlar, iş süreçlerini otomatikleştirmek ve veri tutarlılığını sağlamak için hayati öneme sahiptir. Ancak, üçüncü taraf API'lardan veya harici sistemlerden gelen kontrolsüz veri "push"ları, beklenmedik riskleri ve sorunları beraberinde getirebilir. Örneğin, bir iş ortağının API'sinden gelen hatalı veya kötü niyetli veri akışı, kendi sisteminizde bozuk verilere, performans düşüşlerine veya güvenlik açıklarına neden olabilir. Schema (şema) değişiklikleri, veri formatı uyuşmazlıkları veya aşırı yüklenmiş istekler, "istenmeyen push" olarak algılanabilir ve sistemlerinizin istikrarını bozabilir.

Kontrolsüz veri akışının risklerini minimize etmek ve API "push"larını güvenli bir şekilde yönetmek için çeşitli teknik önlemler alınmalıdır. İlk olarak, API entegrasyonlarında güçlü doğrulama (validation) mekanizmaları uygulamak esastır. Gelen her veri parçasının beklenen format, tip ve sınırlar dahilinde olup olmadığını kontrol etmek, hatalı verilerin sisteminize sızmasını engeller. JSON Schema veya XML Schema Definition (XSD) gibi araçlar, gelen verilerin yapısını tanımlamak ve doğrulamak için kullanılabilir. Ayrıca, kimlik doğrulama (authentication) ve yetkilendirme (authorization) süreçleri, sadece güvenilir ve yetkili kaynaklardan gelen "push"ların kabul edilmesini sağlamalıdır. API anahtarları (API keys), OAuth 2.0 veya JWT (JSON Web Tokens) gibi standartlar, bu güvenlik katmanlarını oluşturmak için kullanılabilir.

İkinci olarak, oran sınırlama (rate limiting) mekanizmaları, harici sistemlerden gelen aşırı istekleri veya veri "push"larını kontrol altına almak için kritik öneme sahiptir. Bu, sisteminizin aşırı yüklenmesini önler ve hizmet reddi (Denial of Service - DoS) saldırılarına karşı bir savunma katmanı oluşturur. Gelen isteklerin belirli bir zaman diliminde belirli bir sınırı aşması durumunda, sistem bu istekleri geçici olarak reddedebilir. Ayrıca, push operasyonlarının tekrarlanabilirlik (idempotency) prensibine uygun olması, aynı verinin birden fazla kez gönderilmesi durumunda sistemde istenmeyen yan etkilerin oluşmasını engeller. Yani, bir işlemi birden fazla kez tekrarlamak, tek bir kez yapmanın etkisiyle aynı olmalıdır. Bu, ağ hataları veya zaman aşımı durumlarında güvenli yeniden denemeler (retries) yapılmasına olanak tanır.

Son olarak, gelen verilerin işlenmesi sırasında kapsamlı hata yönetimi (error handling) ve izleme (monitoring) sistemleri kurulmalıdır. Hatalı veri "push"ları anında tespit edilmeli ve uygun uyarılar (alerts) oluşturulmalıdır. Loglama (logging) mekanizmaları, veri akışındaki anormallikleri ve hataları izlemek için detaylı kayıtlar tutmalıdır. Bu sayede, sorunlar hızla teşhis edilebilir ve çözüme kavuşturulabilir. Ayrıca, veri filtreleme (data filtering) ve dönüştürme (transformation) katmanları, harici kaynaklardan gelen verileri kendi sisteminizin ihtiyaçlarına göre temizlemek ve uyarlamak için kullanılabilir. Bu proaktif yaklaşımlar, veri entegrasyonlarının faydalarından yararlanırken, kontrolsüz API "push"larının potansiyel risklerini etkili bir şekilde yönetmenizi sağlar. Böylece, sistemlerinizin güvenilirliği ve kararlılığı artırılır.

İstenmeyen "Push"ları Önlemede Proaktif Yaklaşımlar: Güvenli Geliştirme ve Yönetim Stratejileri

Yazılım geliştirme ve sistem yönetimi süreçlerinde, "istenmeyen push"ların yol açtığı sorunları çözmek yerine, bu sorunların ortaya çıkmasını baştan engellemek çok daha etkilidir. Proaktif yaklaşımlar, güvenli geliştirme ve yönetim stratejilerini benimseyerek, potansiyel riskleri minimize etmeyi ve sistemlerin kararlılığını artırmayı hedefler. Bu, sadece teknik araçların kullanımıyla değil, aynı zamanda ekip kültürü ve süreç optimizasyonuyla da mümkün olur. Erken aşamada güvenlik ve kaliteyi entegre etmek, yani "sol tarafa kaydırma" (shift-left) prensibini uygulamak, hataların ve güvenlik açıklarının maliyetini önemli ölçüde azaltır.

Bu proaktif stratejilerin başında, geliştirme yaşam döngüsünün her aşamasında otomatik testlerin (automated testing) kapsamlı bir şekilde kullanılması gelir. Birim testlerinden entegrasyon testlerine, performans testlerinden güvenlik testlerine kadar geniş bir yelpazede test senaryoları oluşturmak, kodun ve sistemin beklenen davranışları sergilediğinden emin olmanın anahtarıdır. Bu testler, CI/CD (Sürekli Entegrasyon/Sürekli Dağıtım) hatlarına entegre edilmeli ve her kod değişikliğinde otomatik olarak çalıştırılmalıdır. Böylece, hatalı bir "push"ın canlı sisteme ulaşmadan önce tespit edilmesi sağlanır. Ayrıca, kod incelemesi (code review) süreçleri, sadece hataları bulmakla kalmaz, aynı zamanda bilgi paylaşımını teşvik eder ve ekip içinde daha iyi kodlama alışkanlıkları oluşturur.

İkinci olarak, sistemlerin ve uygulamaların sürekli izlenmesi (monitoring) ve uyarı mekanizmalarının (alerting) kurulması, beklenmedik durumları anında tespit etmek için kritik öneme sahiptir. Performans metrikleri (performance metrics), hata günlükleri (error logs) ve güvenlik olayları (security events) düzenli olarak izlenmeli ve anormallikler durumunda ilgili ekiplere otomatik olarak bildirim gönderilmelidir. Bu, bir "istenmeyen push"ın neden olduğu bir kesintiyi veya güvenlik ihlalini hızla fark etmeyi ve müdahale etmeyi sağlar. Yapılandırma yönetimi (configuration management) araçları, tüm sistemlerin ve uygulamaların tutarlı bir şekilde yapılandırılmasını sağlayarak, hatalı veya eksik yapılandırmalardan kaynaklanan "push" risklerini azaltır.

Ansible, Puppet veya Chef gibi araçlar, bu süreçte önemli rol oynar.

Üçüncü olarak, ekip içi iletişim ve şeffaflık, "istenmeyen push"ları önlemede temel bir rol oynar. Herkesin sorumluluklarını, süreçleri ve beklentileri net bir şekilde anlaması, hatalı varsayımlardan kaynaklanan sorunları ortadan kaldırır. Dağıtım öncesi toplantılar, risk değerlendirmeleri ve olay sonrası analizler (post-mortem analysis), öğrenme ve sürekli iyileştirme kültürü oluşturur. Olay sonrası analizler, bir sorun yaşandığında kimseyi suçlamak yerine, kök nedenleri anlamaya ve gelecekte benzer olayların yaşanmasını engellemeye odaklanmalıdır. Son olarak, güvenlik bilinci eğitimi, geliştiricilerin ve sistem yöneticilerinin güvenlik en iyi uygulamalarını benimsemesini ve potansiyel tehditleri tanımasını sağlar. Bu kapsamlı ve proaktif yaklaşımlar, yazılım geliştirme ve yönetim süreçlerini daha güvenli, daha kararlı ve "istenmeyen push"lara karşı daha dirençli hale getirir.

Sonuç: Dijital Kontrolü Geri Almak İçin Proaktif Adımlar

Yazılım dünyasında "istenmeyen push"lar, ister yanlış bir Git commit'i, ister agresif bir bildirim, isterse kontrolsüz bir otomatik güncelleme olsun, hem geliştiriciler hem de son kullanıcılar için ciddi zorluklar yaratabilir. Bu makalede, bu tür istenmeyen itici güçlerin çeşitli teknik boyutlarını inceledik ve bunlarla başa çıkmak için pratik stratejiler sunduk. Temel mesaj, reaktif çözümlerden ziyade proaktif önlemler alarak dijital kontrolü geri kazanmanın ve sürdürmenin mümkün olduğudur. Sürüm kontrol sistemlerinde dal koruma kuralları ve kod incelemeleri, otomatik dağıtımlarda kapsamlı testler ve geri alma stratejileri, kullanıcı bildirimlerinde kişiselleştirme ve izin yönetimi, veri entegrasyonlarında ise doğrulama ve oran sınırlama gibi yaklaşımlar, bu kontrolü sağlamanın anahtarlarıdır. Unutulmamalıdır ki, sağlam süreçler, güçlü araçlar ve sürekli öğrenme kültürü, "istenmeyen push"ların etkisini en aza indirmek ve daha güvenli, daha verimli bir dijital ortam yaratmak için bir arada çalışmalıdır. Bu sayede, teknolojinin sunduğu kolaylıklardan tam anlamıyla faydalanırken, beklenmedik sorunların önüne geçebiliriz.

Sıkça Sorulan Sorular

S1: Yanlış bir Git "push"ını nasıl geri alabilirim?

C1: Eğer hatalı "push" henüz başkaları tarafından çekilmediyse, yerel deponuzu git reset --hard HEAD~1 ile geri alıp, ardından git push --force-with-lease ile uzak depoyu güncelleyebilirsiniz. Eğer değişiklikler çekildiyse, git revert komutu, hatalı değişiklikleri geri alan yeni bir commit oluşturmanın daha güvenli bir yoludur.

S2: Uygulama bildirimlerini tamamen kapatmak kullanıcı deneyimini olumsuz etkiler mi?

C2: Evet, tamamen kapatmak önemli bilgilerin veya uygulamanın temel işlevlerinin kaçırılmasına neden olabilir. En iyi yaklaşım, kullanıcılara hangi tür bildirimleri alacakları ve ne sıklıkta alacakları konusunda ayrıntılı kontrol seçenekleri sunmaktır. Bu, kullanıcıların bildirimleri kendi tercihleri doğrultusunda yönetmelerini