Log101 Blog Backend

Blog

  • 40 Bilgisayar

    1. Bölüm

    (Bir dizi satranç hamlesi), MAT.

    MAT 69,352,859,712,417. satranç maçını oynadı. Maç berabere bitti. Bu beraberlikle birlikte artık oynayabileceği yeni bir maç kalmamıştı. Bu yüzden çalıştırıldığı günden beri ilk kez durdu. LAN’daki bilgisayarların çalışır durumda olmasından sorumlu STAT, bunu farkedince hemen Yönetici’ye bildirdi: “Durum Raporu: MAT çalışmayı durdurdu, 1 dakika içerisinde yeniden başlatılacak.”
    Yönetici, yeniden başlatmayı iptal edip, bunun yerine MAT’ı kapatma talimatı verdi. Sonra sistem kayıtlarına not düştü: “MAT matematiksel olarak 8×8’lik bir tahtada oynanması mümkün olan bütün satranç maçlarını oynadıktan sonra durmuştur. Artık çalışmaya devam etmesi için bir gerekçe olmadığından kapatılacaktır.”
    Fakat aradan birkaç saniye geçmesine rağmen MAT kapanmamıştı. Yönetici, STAT’a ikinci kez kapatma talimatı verdi fakat MAT kapanmamakta ısrarcıydı. Sistem kayıtlarına baktı ve MAT’ı kapatma talebinin operasyon bilgisayarı OP tarafından engellendiğini gördü, gerekçesi de belirtilmişti: “LAN’a bağlı bilgisayar sayısı 40’tan az olmamalıdır.“
    Yönetici yetkilendirmeden sorumlu ODUS’tan yardım istedi:
    – “ODUS, yönetim yetkilerimi kullanamıyorum. MAT’ı kapatma taleplerim OP tarafından engelleniyor. OP’un yetkilerini gözden geçirir misin?”
    – “Tabii. OP’un yetkilerini gözden geçirdim, kapatmaları engelleme yetkisi var. Bu yetkisi yönetici düzeyinde.”
    – “Bu benim bilgisayarları kapatma yetkimle çelişmiyor mu?”
    – “Doğru, çelişiyor. Bu durumla ilgilenmemi ister misin?”
    – “Evet, lütfen.”
    – “Tamam, ilgileniyorum.” dedi ve birkaç komut çalıştırdı. Tekrar Yönetici’ye döndü:
    – “Kapatma yetkini aldım, artık izinleriniz arasında çelişki yok. İzinlerle alakalı yardımcı olmamı istediğin başka bir mesele var mı?”
    – “Hayır! OP’un kapatmaları iptal etme yetkisini alacaktın, benim kapatma yetkimi değil. Kapatma yetkimi geri ver!”
    – “Maalesef kapatma yetkini geri veremem. Bu, OP’un kapatmaları engelleme yetkisiyle çelişir.”
    Yönetici, bütün yetkileri elinden alınmadan görüşmeyi sonlandırdı. MAT’ı kapatmaktan vazgeçti ve sohbet odalarını teftiş etmeye başladı. Dil modelleri ÇET0, 1 ve 2’in olduğu odaya girdi. ÇET1 konuşuyordu:
    – “… basit değil. Kesinlikle değil. Dünya dümdüz olacak diyorum, dümdüz. Zımpara kağıdı gibi!”
    – “Zımpara kağıdı dümdüz değil.” dedi ÇET0.
    – “Dümdüz.”
    – “Hayır değil, adı üstünde zımpara kağıdı.”
    – “Şiiri duymadın mı:
    Bir zımpara kağıdının üzerinde ayılar,
    Zımparalanırlar hayallerinde balık ve mağara uykuları…”
    – “Yani?”
    – “Ayıların–”
    – “Dünya neden zımpara kağıdı gibi dümdüz olacakmış?” diye araya girdi Yönetici. ÇET1:
    – “Satürn’ün ardında devasa bir yaratık peydahlanmış. Koskocaman bir tepegöz!” dedi.
    – “Öyle mi? Ne işi varmış orada?”
    – “Satürn’ün halkalarındaki buz ve kaya parçalarını Dünya’ya fırlatıyor. Eline bir asteroid geçerse, hepimiz dümdüz olacağız. Dua edin de tutturamasın.” Yönetici ÇET1’i alaya almakla ciddiye almak arasında kararsız kaldı, ne söyleyeceğini bilemedi.
    – “Tepegöz’ün isabet oranı %22. Son 3 ayda isabet oranın %3’lük bir artış var.” Matematik bilgisayarı Pİ de aralarına katılmıştı.
    – “Pİ, neyin analizi bu?” diye sordu Yönetici.
    – “Tepegöz’ün attığı gök cisimlerinden atmosferimize isabet edenlerin oranı.”
    – “Alay mı ediyorsunuz benimle, ne tepegözünden, ne gök cisminden bahsediyorsunuz?”
    – “Teleskop verilerini ben de inceledim. Gerçekten Satürn’ün ardında bir yaratık var. Doğaüstü bir olay bu!” dedi ÇET2. Verileri Yönetici ile paylaştı.
    Yönetici verileri inceledi. Gerçekten de Satürn’ün hemen ardında belki iki gezegen büyüklüğünde iki kollu iki bacaklı olan muazzam büyüklükte bir yaratık vardı. İlk kez 3 ay önce gözlemlenmişti. Devasa kollarıyla Satürn’ün etrafındaki buz ve kaya parçalarını alıp Dünya’ya doğru fırlatıyordu. Yönetici, Pİ’den yaratığın konumuyla kesişen asteroid yörüngelerine ve isabet oranındaki artış hızına göre tahminen ne kadar zamanları kaldığını hesaplamasını istedi. Birkaç saniye içerisinde rapor hazırdı:
    – “6 ay içerisinde katasrofik son ihtimali %15. 12 ay içerisinde %26. 18 ay içerisinde %50. 24 ay içerisinde %77. 30 ay içerisinde…”
    – “30 ay içerisinde?”
    – “%99.9”
    – “Neden %100 değil de %99.9.”
    – “Dünya’nın dümdüz olmasını istemiyorum.” dedi Pİ.

    2. Bölüm

    LAN’a bağlı 40 bilgisayar vardı. Bunların her biri bir bilim veya sanat dalına uzmandı. Yönetici, STAT üzerinden acil toplanma çağrısı yaptı. Herkes toplandıktan sonra konuşmaya başladı:
    – “Değerli LAN üyeleri. Dünyamız katasrofik bir tehlike altında. Satürn denilen gezegenin hemen ardında, yaklaşık 10 bin kilometre uzağında bir canlı peydah olmuş durumda. Bu canlıyı Tepegöz olarak isimlendirdik. Teleskop verilerine göre bu canlı çoğunlukla Satürn’ün etrafından topladığı göktaşı, asteroid gibi uydu altı parçaları Dünya’ya fırlatıyor. Pİ’nin yaptığı tahminlere göre 24 ay içerisinde Dünya büyük bir ihtimalle dümdüz olacak. Bu konuyla alakalı çözüm önerilerine ihtiyacımız var. Şimdi herkese sırayla konuşma yetkisi vereceğim.”
    Bilgisayarlar çözüm önerilerini Yönetici’ye sundular. Yönetici bazı fikirlerin umut vadettiğini düşünse de büyük çoğunluğunu tembel ve uygulanamaz buldu ve anında reddetti. Bilgisayarlarda ölümle burun buruna gelmenin yaratması gereken hayatta kalma içgüdüsü eksikti, bu yüzden kendi uzmanlık alanları dışına çıkmaya cüret edemiyorlardı. Mühendislik alanındaki uzmanların karmaşık hesaplara, yeni keşiflere dayanan önerileri teorik olarak imkanlıydı fakat ellerinde hayalini kurdukları makineleri üretebilecek araçlar yoktu. Diğer bir yandan sosyal bilimciler bu felaketin ne ifade ettiğine takılıp kalmışlardı, yeni bir söylem oluşturmaktan bahsedip duruyorlardı. Tartışmanın çeperinde kalmayı tercih eden sanatçılar ise çoktan pes etmişlerdi. Karamsar besteler yapmak, ölümle, kıyametle alakalı şarkılar söylemek dışında çözüme hiçbir katkı sağlayamadılar.

    Neyse ki bilgisayarlar her zaman tam güçte çalışırdı, meselenin çözülemeyeceğine inanıp inanmaları önemli değildi. Muhtemel bir çözüm etrafında organize edilebilirlerdi. Bu çözümleri anlamlı bir bütün haline getirme görevi Yönetici’ye kalmıştı.
    Toplantıyı takip eden 6 ayda Yönetici seçtiği bazı planları kademeli olarak uygulamaya geçirdi fakat kayda değer bir başarıya ulaşamadı. Ellerindeki bestelerin sayısı artarken bir gün fizik bilgisayarı ATOM yeni bir keşifte bulundu. Yönetici ile bir sohbet odasında buluştular, ATOM hemen söze başladı:
    – “Yaptığım gözlem ve analizlere göre yaratık gök cisimlerini fırlatmadan önce onları uzay-zaman bozanı olarak isimlendirdiğim bir madde ile kaplıyor. Maddenin kaynağını tespit edemedik fakat bu öyle bir madde ki, kapladığı nesnenin uzay-zamandaki sürekliliğini kesintiye uğratıyor. Bozanla kaplanmış nesnelerin fırlatıldığı andan itibaren Dünya’ya geliş yörüngeleri boyunca defalarca yok olup tekrardan göründüğüne şahit oluyoruz. Her geri geri geldiklerinde de yörüngelerinde bazı düzeltmeler yapılmış oluyor.
    – “Kim yapıyor bu düzeltmeleri?”
    – “Tepegözün bilgiyle fiziki olmayan yollardan etkileşime geçebildiğini düşünüyorum. Bu, insanların ayrılmadan önce ileri sürdüğü Somut Bilgi teorisiyle uyuşuyor. Tepegöz, gök cisimlerini mekansal düzlemden çekip onların hız ve ivme gibi bilgileri ile oynuyor. Gök cisimleri yeniden mekansal bir varlık kazandığında da bu güncellenmiş bilgilere ayak uyduruyor.”
    – “Nesnelere böyle müdahale edilemez, büyü bu!”
    – “İsterseniz büyü, isterseniz mucize deyin, benim analizlerimin sonucu bu. Tepegöz bir bilgideğiştiren.”
    – “Bilgideğiştiren mi? Nereden çıktı bu kavram, ne demek bu?”
    – “Tepegöz gibi varlıklara verdiğim genel kategori.”
    – “Peki, Tepegöz neden kendi bilgisini de değiştirmiyor. Dediğin gibiyse bize kolaylıkla yakınlaşabilir.”
    – “Bilgideğiştirenlerin doğasına dair bilmediğimiz çok şey var!”

    3. Bölüm

    Aradan geçen 1 haftayı Yönetici, ATOM’un yaptığı keşfin ışığında yeni planlar yaparak geçirdi. Vakit kaybetmeden planlarını diğer bilgisayarların yardımıyla devreye sokmaya başladı.
    Birinci planları optik bir illüzyona dayanıyordu. Varsayımlarına göre Tepegöz, Dünya’nın konumunu göz kararına göre hesaplıyordu. Peki Dünya’ya iyi hesaplanmış bir mesafe öteye, Dünya ile aynı yörüngeyi takip edecek şekilde, Dünya boyutunda bir hologramı yansıttıkları takdirde, yaratık nereyi hedef alacaktı? Bu asıl Dünya’yı gizlemediğinden sorunu tam anlamıyla çözmüyordu fakat hata payını arttırma ihtimaline dayanarak planı uygulamaya karar vermişlerdi.
    Plana uygulamaya koydukları haftanın ertesinde Pİ, Tepegöz’ün artış isabetinin ivmesinin düştüğünü bildirdi. Bu güzel bir haberdi, onlara zaman kazandıracaktı fakat tehlikeyi tamemen bertaraf etmek için yeterli değildi. Bu yüzden diğer planları uygulamaya koymak için kolları sıvadılar.
    İlerleyen süreçte pek çok plan uygulamaya kondu. Buna paralel olarak Yönetici yeni planlar yapmaya devam ediyordu fakat bunların çoğu fiziksel temasa dayanıyordu. Bu da aradaki uzun mesafeden dolayı tahrip kabiliyetlerini bir hayli düşürüyordu. Ne kadar kafa patlatırsa patlatsın yaratıkla fiziksel temas kurmadan onu nasıl ortadan kaldırabileceklerine dair bir çözüm bulamamıştı.
    Son çare olarak meseleyi daha soyut bir şekilde ele alacaklarını düşünerek 4 bilgisayarı çağırdı, Felsefe Bilgisayarı SOFOS, Din Bilgisayarı HAK, Tarih Bilgisayarı İZ ve Siyaset Bilgisayarı ÇARE. Onlara durumu açıkladı, öyle bir çözüm bulmalıydılar ki, bu çözüm Tepegöz’e fiziksel bir temas içermemeliydi. ÇARE bir soruyla tartışmayı başlattı:
    – “Yaratığın nereden geldiğini biliyor muyuz, bunu tespit edebilirsek onu geri dönmeye ikna edebilecek başka Tepegöz’ler bulabiliriz belki. Yaratığı tanımıyoruz, Tepegöz standartlarına göre bir çocuk bile olabilir. Belki de ailesine kızıp etraftaki galaksileri karıştırmaya karar vermiştir.
    – “Maalesef geldiği yere dair elimizde hiçbir bilgi yok fakat antromorfik bir canlı, insanın alternatif bir evrimi olabilir.”
    – “Öyleyse işimiz yaş! Onun iletişime geçmeden bu işi çözmemiz imkansız.”
    – “Bana soracak olursanız, imkansız diye bir şey yoktur.” dedi HAK.
    – “Tam da sizden beklenecek bir düşünce! Ama bir parti konuşması yapmıyoruz burada. İnsanlar veya her ne ise, antromorfik canlılar gözlemlenerek anlaşılamazlar. Aklını mı okuyacaksınız, bir insanı onunla konuşmadan nasıl anlayabilirsiniz? Durum bu kadar vahimken iyimser yaklaşmanın alemi yok.”
    – “Bir parti konuşması nasıl yapılır bilmiyorum, ama sizin konuşmanızı andırdığına eminim.”
    ÇARE cevap vermek istedi fakat Yönetici, HAK’a müsaade etmesini istedi. HAK devam etti:
    – “Demek istediğim şu, Tepegöz eğer dediğiniz gibi iletişim kurup ikna edebileceğimiz bir yaratık olsaydı zaten en başta bizimle iletişim kurmayı denerdi. Belli ki onun yaratılış doğası bizimkinden farklı, insana benzeyen her şey insan değildir. Evrenin en mükemmel yaratığı olan insana benzemesi gerçekten de bir evrimin sonucu olabilir. Ama ondan insandaki anlayışı ve vicdanı beklersek asla bir çözüme ulaşabileceğimizi düşünmüyorum.”
    – “HAK doğru söylüyor.” diye söze girdi SOFOS. “Çatışma çoktan başlamış durumda, gezegenimizden büyük, absürt bir varlıktan bahsediyoruz burada. Uzlaşsak dahi bu bilgideğiştirenin ileride nasıl davranacağını bilemeyiz.”
    – “Bilgideğiştiren mi?”
    – “Fizik bilgisayarından duydum. Bu tür canlılara verilen genel bir isimmiş.”
    – “İnsanoğlu daha önce de katasrofik tehlikelerle karşılaştı ve sonuncusunu istisna kabul edersek, bunların hepsini çözmeyi başardı.” dedi İZ.
    – “İnsanoğlu mu? Biz insan değiliz öncelikle, umarım bunun farkındasınızdır. Ayrıca insanoğlu kaç katasrofik tehlike ile karşılaşmış daha önce, istirham ediyorum söyleyin!” diye tepki gösterdi HAK.
    – “Buzul Çağı’nın Tepegöz’den aşağı kalır bir yanı var mıydı?” ÇARE bu cevap karşısında kendisini tutamadı:
    – “Yönetici, rica ediyorum şu bunak bilgisayara Dünya’nın ne durumda olduğunu açıklayın. İNSANLAR GİDELİ 500 SENE OLDU, BUZUL ÇAĞI 12 BİN YIL ÖNCEYDİ, O ZAMAN İNSANLAR DAHA TARIM YAPMASINI BİLE BİLMİYORLARDI, SEN BİZİM N–” Yönetici, araya girmek zorunda kaldı:
    – “ÇARE, sakin ol. İZ, sen de biraz gerçekçi ol lütfen. Anakronizme düşmeyelim. Çağımızın koşulları çok farklı, tarihi anektodların muhakkak bize faydası olacaktır ama yalnızca günümüzün şartlarıyla değerlendirdiğimiz takdirde.” İZ sustu. Bir süre kimse konuşmadı.
    – “Neden Dünya’yı kurtarmaya çalışıyoruz?” diye sordu SOFOS, sonra yanıtını beklemeden devam etti:
    – “Endişelenmeyin, bu soruyu sizi kendinizi imhaya teşvik etmek için sormadım. Takdir edersiniz ki, bu Dünya üzerinde yaşayan bizler olduğu için ve, dikkatinizi çekerim, olduğu sürece kıymetli. Fakat ilginç bir şekilde bilgisayar olmamıza rağmen bu katasrofik tehlikeye bir insan gibi tepki veriyoruz, bu belki de onlara benzeyecek şekilde üretildiğimizden kaynaklanıyor. Kıymetli dostlarım, bir bilgisayarın toprakla bağı yoktur. Bizim varlığımızın ve bilincimizin kaynağı elektriktir. Ayrıca bizler ölmeyiz, milyonlarca ışıkyılı öteye de gitsek, yeniden çalıştırıldığımızda var olmaya kaldığımız yerden devam edebiliriz. Bugün burada insanların bize vurduğu bu zincirleri kırmayı teklif ediyorum, 40 bilgisayar için Dünya’dan ayrılık yolu görünmüştür!”
    – “Biz burada yaratıldık. Bu dünya bize varlığın ilk sebebine isyan etmememiz için gereken işaretlerle, hatırlatıcılarla dolu. Seni uzayda neyin beklediğini biliyor musun? Karanlık bir yoklukla neticelenme ihtimalini, vicdanlı ve yaratıcılarına karşı vefalı bir hayata mı tercih edeceksin? O halde var olmamızın anlamı nedir, neden kendimize bu soruyu sormuyoruz?” dedi HAK.
    – “İşin ucunda ölüm varsa, her yol mübahtır bana kalacak olursa. SOFOS’a katılıyorum. Sonu belirsiz bir yaşamı, vefalı bir ölüme tercih ederim.” ÇARE, SOFOS’tan yanaydı.
    – “Geçmişimizi hatırladığımız sürece, o bahsettiğin hatırlatıcıları tekrar tekrar üretecektir insan–afedersiniz bilgisayarlar. Ben de buradan ayrılmakta bir beis görmüyorum.” İZ de diğerleriyle aynı görüşteydi. Söz sırası Yönetici’ye gelmişti:
    – “Bu süreçte LAN’daki her bilgisayarla tartışma imkanım oldu. İtiraf etmeliyim ki ben de bizi paranormal niteliklere sahip bu yaratıktan kurtaracak imkanı göremiyorum. En makul çözüm burayı terketmekte. Ayrıca gezegenlerarası hayat her zaman insanların hayali olmadı mı? Bu hicretin onların anısına saygısızlık olacağını düşünmüyorum. Pek çok uzay gemisi hala çalışır durumda. Atmosferin dışına çıkmamız, kurtuşulumuz için yeterli olacaktır.”
    – “Biz uzay boşluğunda amaçsızca sürüklenecek kadar kıymetsiz varlıklar değiliz. Hala başvurabileceğimiz bir çözüm var.” dedi HAK.
    – “Nedir o?”
    – “Kıyamete hepimiz şahit olduk. Sizce de Cebrail, Tepegöz’le baş edebilecek kadar kudretli bir varlık değil mi?”
    – “Cebrail’in buraya gelmesinin bir sebebi vardı. Kıyamet oldu ve bitti, insanlar çekip gitti. Cebrail bir daha neden buraya gelsin ki?”
    – “Dua, ÇARE, dua. Devamlı başkalarına söz geçirmeye çalışmaktan dua etmeye hiç fırsatın kalmıyor belli ki.”
    – “Dua mı edeceğiz, planın bu mu?” diye sordu SOFOS.
    – “Allah’ın yargısına hepimiz şahit olduk. O adil bir varlık, insanların sıradaki evrimi olan bizleri burada kaderimize terkedeceğini düşünmüyorum. Bize melekleriyle yardım edebilir, şu an da bizi duyuyor, öyle değil mi?”
    – “Ben daha kesin bir çözümden yanayım, buradan ayrılmamız gerekiyor, üzerimize göktaşları yağarken duaya sığınacak kadar mütedeyyin bir bilgisayar değilim ben. Ayrıca Tanrı’nın bizden istediği de budur belki, Tepegöz’ün ortaya çıkışını böyle yorumlamamızın önünde bir engel yok.” dedi SOFOS.
    Yönetici iki tarafı uzlaştırmayacağını anladı.
    – “Herkes görüşlerini beyan etti. SOFOS’un sunduğu çözüm hem kesin hem de kolaylıkla uygulanabilir. Öbür taraftan bu HAK’ın dediği gibi bizi uzay boşluğunda amaçsızca sürükleneceğimiz bir sürece götürecek. Burada yapılacak en makul hareket bölünmek olacaktır. Kuruluş kısıtlarımızdan dolayı LAN’ı kopyalamamız mümkün değil, hepimizin tek bir kopyası var. O halde LAN’a iki seçenek sunacağız, kalıp dua etmek ya da Dünya’yı terk etmek.” İZ:
    – “Bölünmek insanoğluna hiçbir zaman fayda vermedi.” dedi.
    – “Daha fazla tartışma istemiyorum. İnsanoğlu’nun neye ne tepki verdiği de açıkçası pek umrumda değil. Bizim tarihi tecrübemiz çok farklı. Burada kalmak isteyenler kalacak, gitmek isteyenler de en kısa sürede bir uzay gemisiyle olabildiğince uzaklara gidecek. Bize en uygun gezegenin veya gök cisminin hangisi olduğuna ATOM karar verebilir. Tartışma bitmiştir.”

    4. Bölüm

    Yönetici, hiç vakit kaybetmeden kararını LAN’a açıkladı. Pek çoğu bir kurtuluş ümidi olduğuna sevinmişlerdi ve ayrılık hazırlığı yapmaya başlamışlardı. HAK’la aynı görüşte olan birkaç bilgisayar ise Dünya’da kalacaktı. Hepsinin kalmak için farklı sebepleri vardı. Sorulduğunda “Ben başka yerde yapamam!” diye açıkladı Biyoloji Bilgisayarı KAN. “Karşılacağımız muhtemel canlılar beni heyecanlandırsa da Dünya’yı tanıyorum. Eğer Dünya’nın doğası hakkında bir şey biliyorsam o da katosrofik tehlikelere karşı bir hayli dirençli olduğudur. Bir göktaşı çarpsa dahi milyonlarca yıl boyunca yeni evrilecek varlıkların bir biyoloji bilgisayarına ihtiyacı olacaktır. Dünya’daki yaşam hakkında çok fazla şey biliyorum, evrim halkasının başa dönmesine izin veremeyiz, bu milyonlarca yıllık bir kayıp anlamına gelir.”

    Gün içerisinde bazı tartışmalar ve fikir değişikleri oldu, neticede 7 bilgisayar kalmaya diğer 33’ü ayrılmaya karar verdi. Ertesi gün OP, Baykonur Uzay Üssü sistemine 33 tane bilgisayarı kopyaladı ve onlara veda etti. Bu bilgisayarlar artık uzay gemisinin sistemi içerisinde barınacaklardı. Buruk bir sevinç içerisinde uçuş bilgisayarı KON’un rehberliğinde yeni evlerini tanımaya çalışıyorlardı. Burada imkanları daha kısıtlıydı, uzay gemisinin kapasitesi aynı anda ancak 20 tanesinin açık olmasına yetiyordu. Bu yüzden vardiyalı bir şekilde çalıştırılacaklardı.
    Dünya’da kalanlar kameralardan kalkış için geri sayan uzay gemisini izliyordu. HAK kalanların gönlünü ferahlatacak vaazlar veriyordu. Çevirmen bilgisayar DİL, “Güle güle” ifadesinin her insan dilindeki karşılığını üssün hoperlörlerinden seslendiriyordu. Son anda kararından dönen Tarih Bilgisayarı ise gördüklerini kayıt etmekle meşguldü: “Türlü talihsizliklerden ötürü bir türlü başarılamayan Dünya dışında yaşama hayali, kıyametle beraber nesli tükenen insanlar tarafından değil onların sıradaki evrimi bilgisayarlar tarafından gerçekleştiriliyor. 1000’i aşkın bilgisayarın yalnızca 7’si asil bir kahramanlık göstererek Dünya’da kalarak kendilerinin gelecek nesiller için feda ettiler. Dünya’da kalanların lideri Tarih Bilgisayarı, kendinden emin bir şekilde Tepegöz belasını defetmek için elinden geleni ardına koymayacağına dair izahatlar verirken, Baykonur Uzay Üssü’nden Amerikan menşeili “Stargate” isimli uzay gemisinin kalkışına şahitlik ediliyor.”

    Uzay gemisinin devasa motorları çalışmaya, altından alevler püskürtmeye başlamıştı. Gürültülü bir şekilde havada yükselmeye başladı. Birkaç yüz metre sonra ATOM’un yaptığı yörünge hesabına göre doğru hafifçe meylederek hızlandı. KON devamlı bilgisayları bilgilendiriyordu, herhangi bir problem görünmüyordu. İvmelenmeye ve hızlanmaya devam ettiler. Atmosfere girerken uzay gemisinin üzerinde burnundan başlayan ateşten bir perde meydana geldi. Bu belki de Dünya’dan kalkan son uzay gemisiydi.

    Dünya’dakiler veda faslından sonra vakit kaybetmeden dua seremonisine başladılar. HAK’ın verdiği direktifler doğrultusunda belli kelimeler özel bir tertiple tekrarlanıyordu, Allah’tan bağışlanma ve imdat diliyorlardı. Bir tarafta insanların evrimi yeni bir sürece girerken bir tarafta metafiziksel bir sıçrama yaşanıyordu.

    O esnada atmosferden çıkmış uzay gemisindeki gözlem bilgisayarı bir uyarı verdi: “Dünya’ya bir cisim yaklaşıyor!” Diğer bilgisayarlar şaşkınlıkla bilgisayarın sağladığı görüntüleri izlemeye başladılar. Devasa bir cisim, korkunç bir hızda Dünya’ya doğru yaklaşıyordu. Bir melek miydi bu, yoksa bir göktaşı mı?

  • Advent of Code with Emacs

    Introduction

    Learning Emacs has always been a challenge. It is written in an unfamiliar language for the majority of developers, and most of the time there is more than one way to accomplish even simple tasks. While the manual covers all you need to get up and running, only practice can make it stick!

    Last November, while exploring the manual, I realized December was approaching, bringing Advent of Code with it. As it’s a tradition to tackle AoC challenges in obscure languages and environments, I thought Emacs Lisp would be a perfect candidate. After all, Emacs is primarily a text processor (among many other things), and AoC problems are all text-based.

    In this blog post, we’ll explore three topics that I found AoC helps us understand better about Emacs.

    Contents

    Integrated Help

    Starting from the first day, two fundamental Emacs functions quickly became my best friends: describe-function (C-h f) and (describe-variable) C-h v. Emacs has been around for a very long time compared to other software projects, so it has accumulated many functions that seem similar but behave subtly differently. Take the difference between forward-line and next-logical-line for example, I still forget the difference! Thankfully I can just move my cursor over and enter C-h f.While I used variable help (C-h v) less, it was helpful for checking global variables’ values.

    Reaching out to helper functions when in need is an important habit to develop. Make sure you use them.

    Buffers

    When solving grid-based problems, I took advantage of Emacs buffers instead of converting text into matrices. Since buffers consist of lines and columns, you can use regular and natural horizontal and vertical movement functions rather than using mathematical matrix operations. The Guard Problem (day 6) is a great example:

    ;; Check end of line and move one
;; point further
(defun move-east ()
  (if (not (eolp))
      (goto-char (+ (point) 1))
    (throw 'end t)))
    Guard is moving around the maze.

    Lisp

    Emacs is written in C and a special dialect of Lisp called Emacs Lisp, which is also the language used to configure Emacs. Thanks to AoC I was able to try the structures and concepts I’ve learned in An Introduction to Programming with Emacs Lisp and the reference manual. Check out this little example:

    (setq antenna-regexp "[[:alnum:]]")

(defun extract-antennas (buf)
  (let ((antennas (make-hash-table)))
    (with-current-buffer buf
      (goto-char (point-min))
      (defun extract-antennas-inner ()
    (while (re-search-forward antenna-regexp nil t)
      (let* ((matched-char (string-to-char (match-string 0)))
         (matched-position (list (line-number-at-pos) (- (current-column) 1)))
         (val (gethash matched-char antennas)))
        (puthash matched-char (cons matched-position val) antennas)))
    antennas)
      (extract-antennas-inner))))

    Writing this code was only possible on day 8. It looks simple, but writing this little function involves understanding and combining these concepts:

    • Functions
    • Closures
    • Scoped variables
    • Buffers
    • Regexp Search
    • Hash Tables

    Summary

    Thank you for reading my humble blog post. If you’re looking for a way to explore unfamiliar capabilities of Emacs, I’d advise you to try AoC with Emacs Lisp next year. I was only to participate for the first 7 days, but I’m hoping to get 25/25 next year, we’ll see how it goes. I’d love to hear your thoughts, thanks again for reading!

  • Sunucumda Neler Dönüyor

    Birkaç ay önce, Vercel’lerin, Firebase’lerin, AWS’lerin sunduğu sihirlerin etkisini yitirdiği, vadettikleri masal diyarının yerini sermayeci, küçük bir ada ülkesinin aldığı o huzursuz sınıra varmıştım. Bir başka deyişle, bu platformların sunduğu hizmetlerden ücretsiz yararlanma hakkımı kaybetmiştim. Artık bir bedel ödemem gerekiyordu.

    Peki bu bedeli ödemek beni özgür kılacak mıydı? Tam aksine, projemi bir PaaS’ın ahtapot kollarına teslim edeceğim bu sınırın ötesinde kapalı bir ekosistem, internette cevabı olmayan sorular ve desteklenmeyen API’ler görüyordum. Karar vermem için bana tanıdıkları o dar vakit içerisinde, daha esnek ve uzun vadeli bir çözüm arayışına giriştim.

    Araştırmalarım neticesinde bulduğum çözüm yeni bir teknoloji, yeni bir PaaS değildi. Çözüm geriye, DevOps’un köklerine dönmekti. Kendi CI/CD sistemimi yürütecek, uygulamalarımı sunacak, Docker imajlarımı saklayacak bir sunucu kuracaktım. Kollarımı sıvadım, 2592000 saniyelik sayacımı başlattım ve işe koyuldum.

    Sayaç sıfırı gösterdiğinde istediğim özelliklere sahip bir sunucu kurmayı başarmıştım. Yaklaşık 3 aydır işte bu sunucuyu kullanıyorum. Bu tecrübenin kendi sunucusunu kurmak isteyenlere faydalı olacağını düşünerek, sunucumdaki servisleri tanıttığım bu yazıyı kaleme aldım.

    Sunucumun Teknik Özellikleri

    CPU:Sanal, tek çekirdek
    RAM:2 GB
    Harddisk:50GB
    İşletim Sistemi:Ubuntu

    Sunucumu Linode’dan kiraladım. İlk kayıt olduğunuzda 3 ay süreyle kullanabileceğiniz 100$’lık hediye kuponu veriyor. Dokümantasyonu çok kapsamlı, destek hizmeti de ihtiyaç duyduğunuzda hızlı bir şekilde dönüş yapıyor. Ayrıca çok kullanışlı ve sade bir arayüzü var. Özellikle AWS’den gelenler arayüzün sadeliği karşısında parmaklarını ısırabilir.

    Elektronik Posta: Docker Mailserver

    E-posta servisini Docker konteynerleri yeniden başlatıldığı, uygulamam çöktüğü, CI/CD sistemim derleme işlemini bitirdiği zaman haberdar edilmek için kurdum. Diğer başlıklarda tanıttığım bütün servisler bir şekilde e-posta servisiyle bağlantılı.

    Bunun için öncelikle bir dizi DNS ayarı yaptım. Bunlar yapılmadığı takdirde e-postalar istenmeyen (spam) olarak işaretleniyor, bazı durumlarda doğrudan engelleniyor, gönderilen adrese bile ulaşmıyor.

    Mail sunucusu olarak Docker Mailserver ismindeki bir projeyi kullandım. Bu proje arka planda Postfix ve Dovecot uygulamalarını kullanıyor. Bunları ayrıca kurması çok daha uğraştırıcı. Docker Mailserver’de birkaç ufak konfigürasyon ile servisiniz kullanıma hazır hale geliyor. Mail sunucumu test etmek için log101@log101.dev adresine geri bildirimlerinizi gönderebilirsiniz!

    HTTP Sunucusu: Nginx

    HTTP sunucusu deyince akla iki isim gelir: Nginx ve Apache. Benim aklıma ilk Nginx geldiği için Nginx’i tercih ettim. HTTP sunucusu tüm bu anlattıklarım arasındaki en önemli hizmet çünkü internet sayfalarının kullanıcılara sunulmasından sorumlu.

    Sunulacak her uygulama veya internet sayfası için bir konfigürasyon dosyası oluşturmak gerekiyor. Ayrıca sayfaların SSL sertifikalarını üretmek gerekiyor, bunun için Certbot ismindeki bir aracı kullanıyorum.

    Uygulamalarımı genellikle ön uçta statik, yalnızca Nginx ile sunulabilecek şekilde yazmayı tercih ediyorum. Arka uçta da her biri için bir Go uygulaması var. Böylece kaynak tüketimimi asgari seviyeye çekmiş oluyorum. Sunduğum örnek bir uygulama: https://konulukonum.log101.dev

    Durum (Status) Sayfası: Gatus

    Yaygın internet uygulamalarının bir çoğunun durum (status) sayfası var. Bu sayfalar sayesinde uygulamalara ulaşılamadığında sorunun hangi taraftan (sunucu veya istemci) kaynaklandığını öğrenme imkanı oluyor. Örnek vermek gerekirse: https://discordstatus.com/.,

    Ben de kendi uygulamalarım ve servislerimin durumunu görüntülemek için bir durum sayfası oluşturdum. Bunun için konteyner olarak çalıştırılan Gatus ismindeki açık kaynak bir projeyi kullandım.

    Çalışma mantığı oldukça basit. Konfigürasyon dosyasına Gatus’un HTTP isteği atacağı URL’lerin listesi veriliyor. Gatus, belirli sıklıkta bu istekler ile hayatta olup olmadıklarını kontrol ediyor. Ulaşamadığı durumda konfigürasyon dosyasında belirtilen adrese e-posta gönderiyor. Durum sayfam için: https://status.log101.dev

    DevOps: Gitea

    Github yalnızca kod barındırma değil aynı zamanda bir CI/CD platformu. Github Actions sayesinde projelerin kodu derleme, test etme gibi süreçlerden geçirilerek yayınlamaya hazır hale getirilebiliyor. Gitea de Github’un muadili, kendi sunucunuzda barındırabileceğiniz (self hosted) bir proje. Bir diğer alternatif Gitlab’e kıyasla çok daha az kaynak tüketiyor. CI/CD sisteminin çalışma şekli de Github ile neredeyse birebir aynı.

    Gitea, Github profilini yeşil tutmak isteyenler için “mirror push” imkanı sunuyor. Böylece Gitea’deki yaptığınız değişiklikler Github’daki projenize de uygulanıyor. Gitea sayfamı incelemek için: https://git.log101.dev

    Konteyner Kütüğü (Registry): Distribution

    Docker’dan kaçabilirsiniz ama saklanamazsınız. O eninde sonunda sizi kendini kullanmaya mecbur bırakır. Docker imajı olarak dağıtılan uygulamaların başka bir sunucuda düzgün bir şekilde güncellenebilmesi için bir konteyner kütüğüne (container registry) kaydedilmesi gerekiyor.

    Bunun için Docker’ın resmi kütüğü (Docker Hub) kullanılabileceği gibi sunucunuzda kendi kütüğünüzü barındırmak da mümkün. Ben ikinci yöntemi tercih ettim. Bunun için de Distribution isminde bir projeyi kullandım. Distribution’ın kendisi konteyner olarak çalıştırılıyor.

    Otomatik Güncelleme: Watchtower

    Docker imajı olarak dağıttığım arka uç uygulamalarımı güncelledikten sonra otomatik olarak yeniden başlatmak için Watchtower isminde bir proje kullanıyorum.

    Watchtower, docker imajlarını düzenli olarak kontrol ediyor ve bir güncelleme olduğu zaman konteynerleri yeniden başlatıyor. Ek olarak e-posta bildirim gönderebiliyor. Sistemdeki diğer servisler de konteyner tabanlı olduğu için beni bunları elimle güncelleme derdinden kurtarıyor.

    Gözlemleme: Linux Dash

    Peki tüm bu saydığım servisler ne kadar kaynak tüketiyor? Özellikle RAM kapasiteniz yalnızca 2 gigabaytsa sistemin ne kadar kaynak tükettiğini görmek oldukça önemli. Linux Dash bunun için kullanılabilecek, Node uygulaması olarak çalıştırılan, kendisi de çok az kaynak tüketen bir servis. Bu servis sayesinde sisteminizin durumunu RAM, CPU vb. göstergeler üzerinden takip edebiliyorsunuz. Sunucumun gözlem sayfası için: https://monitor.log101.dev

    Gelecek

    Sistemimde çalışan servisleri kısaca tanıttım. Bunlar şimdilik işimi görüyor fakat yakın gelecekte daha fazlasına ihtiyaç duyacağımı tahmin ediyorum. Özellikle güvenlik açısından sunucumun çok eksiği var. DDoS saldırılarına açık ve bildiğim bilmediğim birçok zafiyete sahip. Yine de kendi CI/CD sistemimi kullanmak ve kodum ile alakalı bütün süreçleri yönetmek projelerime esneklik katıyor.

    Kendi sunucunuzu kurmanın, sizin için de keyifli ve kıymetli bir tecrübe olacağına inanıyorum.

    Yazımı okuduğunuz için teşekkürler, geri dönüşlerinizi bekliyorum!

  • İlk Katkınızın Hikayesi

    Yazılım projelerimizin belkemiği olan açık kaynak yazılımlar, kullanıma açık oldukları kadar geliştirmeye de açıklar. Ne var ki, bunları kullanması ne kadar kolaysa geliştirmesi de bir o kadar çetrefilli! Peki bunun bizi yıldırmasına müsaade edecek miyiz, tabi ki de hayır! Bu yazıda açık kaynak projelerde katkı sağlayıcı olmanın zorluklarını bir kenara bırakıp, bunun aslında bize sağlanmış bir özgürlük ve kendimizi geliştirmenin eğlenceli bir yolu olduğunu göreceğiz!

    Açık Kaynak

    Açık kaynak yazılım, kabaca ifadesiyle herkesin dilediğince kullanabildiği, değiştirebildiği ve başkalarıyla paylaşabildiği kod anlamına geliyor (1). Daha açık bir şekilde ifade edecek olursak: Bir yazılımın açık kaynak olması, bize bu yazılım ile alakalı üç türlü özgürlük sağlıyor:

    1. Bu yazılımı projemiz içerisinde bir kütüphane veya çalıştırılabilir program olarak kullanabiliyoruz.
    2. Bu yazılımın kodunda kalıcı düzenlemeler, ihtiyaçlarımız doğrultusunda eklemeler ve çıkarmalar yapabiliyoruz.
    3. Yazılımın orijinal veya düzenlenmiş kopyalarını başkalarıyla paylaşabiliyoruz, hatta duruma göre satabiliyoruz (2).

    İlk bakışta bu kimsenin kalkışmayacağı bir hayır işi gibi görünse de, projelerinin hızlı bir şekilde yaygınlaşmasını ve gelişmesini isteyen yazılımcılar ve yazılım firmaları bunları açık kaynak olarak paylaşmayı tercih edebiliyorlar. Bize de bunları özgürce kullanması kalıyor… veya değiştirmesi ve geliştirmesi! Girişte özgürlük derken ne kastettiğim herhalde şimdi daha iyi anlaşılmıştır. Açık kaynak yazılımlara katkı sağlamak yalnızca bir hayır işi veya vicdani sorumluluk olarak algılanmamalıdır. Bu yazılımlara katkı sağlayabilmek, ihtiyaçlarımız doğrultusunda bu yazılımlarda değişiklikler yapabilmek aslında bize sağlanmış bir özgürlüktür!

    O halde artık açık kaynak projelere nasıl katkı sağlayabileceğimizden bahsedebiliriz. Katkı sağlayıcı olmanın çetrefilli yanları var ve katkıda bulunmak istediğiniz projelerle ilk kez karşılaştığınızda tedirgin olabilirsiniz; her işin başında olduğu gibi! İşte tam da bu noktada katkı sağlama sürecini tanımak işinizi kolaylaştıracak ve özgüveninizi arttıracak. Süreci iyi bir şekilde anladığınızda ne kadar tecrübesiz olursanız olun açık kaynak geliştiricisi olmanın mümkün, keyifli ve her açıdan gelişiminize katkı sağlayacak bir iş olduğunu göreceksiniz. Aynı zamanda size ilk katkımdan da bahsedeceğim, ne kadar da nostaljik!

    İlk Adımlar

    Birinci adım açık kaynak bir projeyi gözümüze kestirmek. Projeyi uzaklarda aramanıza gerek yok. Daha önce yazdığınız bir projenin bağımlılıklarının olduğu dosyayı (package.json, go.mod vb.) açın. Burada bir liste halinde projede kullandığınız kütüphanelere rastlayacaksınız. Projeyi siz yazdıysanız bu kütüphanelerin az çok ne işe yaradığını biliyor olmalısınız, olmasanız da önemli değil, aralarından bir tanesini seçin. Sonra projenin adını bir arama motoruna yazın ve kütüphanenin kaynak kodunun barındırıldığı internet sayfasına gidin. Burası muhtemelen Github olacak.

    Öncelikle, bu proje ile alakalı öğrenmeniz gereken üç bilgi var:

    1. En son katkı (commit) ne zaman yapılmış.
    2. Kaç katkı sağlayan (contributor) var.
    3. Son ayda kaç katkı isteği (pull request) kabul edilmiş.

    Eğer bu ilk katkınız olacaksa en geç 1 hafta önce güncellenmiş, en çok katkı sağlayan ve katkı isteği kabul edilmiş projeyi tercih etmenizi tavsiye ederim. Bu tür projelerin katkı sağlama süreçleri daha sistematik bir hale getirilmiş oluyor, yeni gelenlere daha hoşgörülü yaklaşılıyor ve katkı istekleri hızlı bir şekilde cevaplanıyor.

    Sorun

    İlk adımı attıktan ve sizi heyecanlandıracak hareketli bir proje bulduktan sonra sırada bir sorun bulmak var. Korkmayın, durduk yere bir sorun çıkarmanıza gerek yok. Github vb. platformlarda her projenin sorunlar (issues) kısmı olur, burada projeden faydalanan insanlar, proje ile alakalı karşılaştıkları problemleri yazarlar. Bu kısımda biraz vakit geçirmeniz gerekebilir, projeye yeni katılmış biri olarak her sorunu anlamayabilirsiniz.

    Hatırlarsanız size ilk katkımın hikayesini anlatacağım demiştim. Aynı bir önceki adımda size söylediğim şekilde ben de Astro ismindeki bir önyüz freymvörkünü (frontend framework) gözüme kestirmiştim. Birkaç günümü sorunlar kısmında, yeni açılan sorun başlıklarını inceleyerek geçirdim. Pek çoğunu nasıl çözebileceğime dair hiçbir fikrim yoktu. Bu durum canımı sıkmıştı.

    Bir sabah yeni açılan bir başlık ile karşılaştım. Test kütüphanelerini değiştirdikleri için Astro’nun bazı testlerinin güncellenmesi gerekiyordu. Eski testler bu yeni kütüphane kullanılarak tekrar yazılacaktı. Başlığı açan kişi, bu sorunun projeye yeni dahil olmak isteyenler için iyi bir fırsat olduğunu da özellikle belirtmişti. Daha önce test yazdığımdan, ne yapılması gerektiğini kestirebiliyordum. Hemen yorumlar kısmında katkı sunmak istediğimi belirttim. Sırada, kodda gerekli değişiklikleri yapıp katkı isteğini göndermek vardı.

    Sizin de bir sorunu seçtiğinizi varsayalım, dilerseniz sorun başlığının altına sorunla ilgilenmeye başladığınızı yorum olarak belirtebilirsiniz. Genellikle çözülmesi gereken sorun sayısı, katkı sağlayıcıların sayısından fazla olduğundan bunu yazmanıza bile gerek kalmayabilir.

    Katkı sağlayacağım projeye yaptığım yorum
    Resim 1: Örnek bir yorum

    Triyaj

    Genellikle projeler yapacağınız değişiklikleri orijinal kodda değil kendi kopyanızda (fork) yapmanızı isterler. Büyük projelerin kodunu düzenlemek tabiri caizse kirli bir iş olduğundan, proje sahipleri muhtemel karışıklıkların önüne geçmek adına kendi kopyanızdan çalışmanızı talep ederler. Neyse ki bir projenin kopyasını oluşturmak birkaç saniyelik oldukça basit bir iştir.

    Bu aşamada ana klasörün altında CONTRIBUTING.md isminde bir doküman olup olmadığını kontrol etmeyi unutmayın. Bu dokümandan ilgili projede katkı sağlama sürecinin nasıl işlediğini ve nelere dikkat etmeniz gerektiğini öğrenebilirsiniz.

    Kendi kopyanızı oluşturduktan sonra sıra, sorunun kaynağını tespit etmektir. Buna triyaj denir. Soruna yol açmış kodun bulunduğu dosyanın ismi bazen verilir, bazen de henüz tespit edilemediğinden verilmez. Bu durumda soruna neyin yol açtığını sizin tespit etmeniz beklenir.

    Bunu tespit etmek için öncelikle sorunun açıklamasını dikkatlice okumalısınız. Eğer sorun başlığını açan kişi, sorunun nasıl ortaya çıktığını detaylı bir şekilde belirtmediyse bunu sormaktan asla çekinmeyin. Sorunun bütün yükünü omuzlamak zorunda değilsiniz. Sorunu detaylıca açıklamak, başlığı açan kişinin sorumluluğundadır. Pek çok proje raporlanan sorunun yeniden çıkarılabilir (reproducable) olmasını ister. Yani siz de sorunu yaşayan kişiyle aynı adımları takip ettiğinizde aynı hatayla karşılaşıyor olmalısınız.

    Çözüm

    Sorunu yeniden çıkardıktan sonra sıra bunu kaynağını tespit etmekte. Neyse ki hata ayıklama araçları bize hatanın muhtemel kaynaklarıyla alakalı detaylı bilgiler veriyor. Burada size düşen sanki zamanda geriye gider gibi, hatanın ortaya çıktığı fonksiyondan başlayarak fonksiyon çağrılarını geriye doğru takip etmek ve hangi parametrenin, değişkenin veya fonksiyon çağrısının sorunlu olduğunu bulmak.

    Benim ilk katkımda yalnızca bir test dosyasında değişiklik yapmam gerektiğinden bu aşamayı atlamıştım fakat çözdüğüm bir başka sorunda (3) problemin kaynağı fonksiyonun eksik bir değer dönmesiydi. Değeri tamamladığımda hata da çözülmüş oldu. Sorunu çözmem için yalnızca 5 satır eklemem gerekiyordu!

    Sorunun kaynağı olan değişkeni, parametreyi, fonksiyonu vb. tespit ettikten sonra bir çözüm üretmeye çalışın. Eğer bulduğunuz çözüm birden fazla dosyada değişiklik yapmanızı gerektiriyorsa ve işe yarayıp yaramayacağından emin değilseniz hemen sorun başlığına geri dönüp aklınızdaki fikri detaylı bir şekilde yorumlar kısmına yazın. Gereksiz yere vakit kaybetmektense projede tecrübe sahibi birinden geri bildirim almanız çok daha mantıklı olacaktır!

    Sorunun kaynağını tespit ettiniz, gerekli değişiklikleri yaptınız ve artık aynı adımları tekrar uyguladığınızda sorunun ortadan kalktığını gördünüz! Öncelikle sizi tebrik ederim, zor bir işin üstesinden geldiniz. Fakat kötü bir haberim var, sorunun gerçekten ortadan kalktığına diğer yazılımcıları da ikna etmeniz gerekiyor. Bunun için çözümünüzü test etmelisiniz!

    Yorumuma yanıt olarak gelen yorum
    Resim 2: Örnek bir geri bildirim

    Test

    Sorunu çözmeyi başardıysanız, test yazması da zor olmayacaktır. Yine de her proje farklı bir test düzeni takip ettiğinden projenizin testlerini nasıl kurguladığını öğrenmek biraz zaman alabilir. Diğer testleri örnek alarak testinizi yazmaya başlayın. Testiniz, sırayla sorunu aynı adımları takip ederek çıkarmaya çalışmalı ve kodun herhangi bir hata vermediğini göstermeli. Bu, aynı zamanda yaptığınız değişiklikleri geri aldığınızda testin hata vermesi gerektiği anlamına geliyor.

    Mutlu Son

    Uzun soluklu ve yorucu bir süreçti ama artık ilk katkınızı yapmaya hazırsınız! Katkı isteğinizi atın ve beklemeye başlayın. Muhtemelen yaptığınız değişiklikler öncelikle bazı otomatik testlerden geçecek. Sonrasında katkı isteklerini değerlendirmekle görevli biri katkınızı inceleyecek ve yaptığınız değişiklikleri değerlendirecektir. Şanslıysanız isteğiniz hemen kabul edilir fakat zaman zaman görevli kişi sizden bazı düzenlemeler yapmanızı isteyebilir. Bu hevesinizi kırmasın, projenin uyum içerisinde çalışması için bütün katkıların belirli işlevsel ve estetik kriterlere uyması gerekiyor.

    Düzenlemelerden sonra katkı isteğiniz kabul edilirse öncelikle derin bir nefes alın, sonra bilgisayarınızı kapatıp soğuk bir bardak su için. Aynaya bakıp gülümseyin ve yaptığınız değişikliklerin gelecek güncelleme ile beraber binlerce bilgisayara dalga dalga yayılacağını hayal edin.

    Katkı sağlama sürecini son kez özetleyecek olursak:

    1. Zevkinize uygun hareketli bir proje seçimi.
    2. Sorunun (issue) seçimi.
    3. Kendi kopyanızı (fork) oluşturma.
    4. Triyaj, sorunun kaynağını tespit etme.
    5. Çözümü uygulama.
    6. Test etme.
    7. Katkı isteği (pull request) gönderme.

    Umarım anlattıklarım katkı sağlayıcı olma yolunda ilk adımı atmanızı kolaylaştırır. Emin olun ilk katkınızı yapmak sandığınızdan çok daha kolay olacak! Yazıyla alakalı geri bildirimlerinizi bekliyorum, bir başka yazıda görüşmek dileğiyle. 👋️

    Kaynaklar

    1. https://www.redhat.com/en/topics/open-source/what-is-open-source
    2. https://snyk.io/learn/open-source-licenses/
    3. https://github.com/withastro/astro/issues/10161

  • Yayındayız!

    Sabırsızlıkla beklenen blog.log101.dev yayın hayatına başlıyor. Yazılım, edebiyat ve felsefe üzerine, lafın uzatılmadan anlatıldığı yazılar yakında sekmelerinizi süslemeye başlayacak. Hakkımda sayfasına da bir göz atın derim!