Hızlı hareket etmek ve vazgeçmek
(engineersneedart.com)- 1991 civarındaki tamamlanmamış Mac oyunlarını kurtarma sürecinde, fikirleri hızla hayata geçirip yeterince eğlenceli ya da tamamlanabilir görünmüyorsa cesurca rafa kaldıran bir geliştirme biçimi tekrar tekrar uygulanmış
- O dönemki listede 27 başlık vardı, ancak gerçekten yayımlananlar 5 taneydi; geri kalanı yaklaşık 18 ay boyunca yapılan hızlı prototiplere daha yakındı
- Sprite tabanlı oyunlar için kullanılan ortak kabuk sayesinde yeni denemelerin maliyeti düşüktü ve ses, high score, kayıt gibi özellikler ancak potansiyel doğrulandıktan sonra erteleniyordu
- kite-fighting, K-10, Thief of Baghdad gibi denemelerde devam edip etmeme kararı; kontrol hissinin eğlencesi, oyunun amacı ve tek bir geliştiricinin kaldırabileceği sanat ve uygulama yükü üzerinden veriliyordu
- Rafa kaldırılan projeler de israf değildi; Fisher–Yates shuffle, ekran renk derinliği geçişi, çarpışma tespiti, trigonometrik lookup table gibi kodlar sonraki projelerde yeniden kullanıldı
Eski Mac oyun projelerini kurtarmak
- Yaklaşık 35 yıl önce yazılmış oyun dosyalarını eski bir sabit diskten kurtarırken, yayımlanmış işlerden çok neredeyse hiç tamamlanamamış deneysel projeler daha ilginç bir konu olarak öne çıktı
- Geçmişte yayımlanan shareware oyunlar disk imajları halinde paketlenip Soft Dorothy Software — Early Shareware Projects adresine yüklendi
- Bu disk imajları, Basilisk II, Sheepshaver, MiniVMac gibi 68K veya PPC Mac emülatörlerine sürükleyip bırakılarak kullanılabilecek biçimde hazırlanmış
- Casady & Greene tarafından 1991'de yayımlanan Glider 4.0 ile ilgili kaynaklar ve build araçları, Casady & Greene Projects disk imajında yer alıyor
- AirBikes tamamlanmış olsaydı fütüristik bir yarış oyunu olacaktı, ancak gerçekte tamamlanmadan kaldı
27 başlığın yalnızca 5'i yayımlandı
- 1991 civarında hazırlanmış bir belgede her oyunun creator code'u, adı ve durumu listelenmişti
- creator code, OS X öncesi Macintosh döneminde kullanılan, oldukça kaba bir bundle identifier benzeri yapıydı ve her uygulama için benzersiz olması gerekiyordu
- Listede 27 başlık vardı ve bunların yalnızca 5'i yayımlandı
- Geri kalanların çoğu hızlı prototiplerden ibaretti
- Bu projeler yaklaşık 18 aylık bir süre içinde üretildi
- Listenin yazıldığı sırada aynı anda 3 başlık üzerinde çalışıldığı da görülüyor
- UnMask adlı bir yardımcı araç da yayımlandı, ancak yapımı yaklaşık 10 dakika süren bir araç olduğu için analiz dışında bırakılabilecek bir iş olarak değerlendirildi
Hızlı prototipleme yaklaşımı
- Her gece geç saatlere kadar kod yazılarak çok sayıda deneme üretildi ve sprite tabanlı oyunlar için hazırlanan ortak kabuk, yeni prototip oluşturmanın maliyetini düşürdü
- Yeni oyun eskizlerinde zamanın çoğu MacPaint ile sprite ve çizim üretmeye gidiyor, benzersiz giriş yöntemi, oyun mekaniği ve fizik uygulaması içinse bir miktar kod gerekiyordu
- Ses, high score, kayıtlı oyun gibi özellikler en baştan yapılmıyor, yalnızca yaşatmaya değer görünen oyunlar için daha sonraya bırakılıyordu
- Esas amaç, fikrin gerçekten eğlenceli olup olmadığını hızla doğrulamaktı
- Kağıt üzerinde eğlenceli görünen bir fikrin gerçekten oynarken de eğlenceli olması garanti değildi
- Sadece kontrolleri ve fiziği birkaç gün içinde uygulamak bile devam etmeye değip değmeyeceğini gösterebiliyordu
Eğlenceyi hızla doğrulama ölçütü
- kite-fighting oyunu için birkaç gün içinde uçurma kontrolleri ve fizik uygulanıp test edilebiliyordu
- Uçurtmayı kontrol etmek başlı başına fazla zorsa, oyundan keyif alacak kişi sayısı da düşük olabilirdi
- Savaş unsuru olmadan yalnızca uçurtma uçurmak bile eğlenceliyse umut vardı
- Arcade oyunu Joust'ta düşmanlar ortaya çıkmadan önce bile flap tuşuyla uçup dolaşmanın kendisi eğlenceliydi
- Yavaş çırpmanın gerektiği anlarla hızla yükselmek için çılgınca tuşa basılan anlar birlikte oyun hissini oluşturuyordu
- Kağıt uçağın dağınık bir evin içinde yerdeki havalandırma çıkışlarından kaldırma kuvveti aldığı oyunda da, odalarda ilerleme ve tost makinesi gibi engellerden kaçınma hedefi daha belirginleşmeden önce bile belli ölçüde eğlence vardı
- K-10, adını Kansas highway 10'dan alan bir başka yarış oyunuydu, ancak prototip aşamasını aşamadı
Bırakma ya da devam etme kararı
- Bazı oyunlar erken uygulama aşamasına kadar geldi ama sonrasında ne yapılacağı netleşmedi
- Listede bazı oyunların yanına acımasızca
<no point>yazılmıştı
- Listede bazı oyunların yanına acımasızca
- Platform oyunu Thief of Baghdad'da sihirli halı üzerinde zıplamak eğlenceliydi, ancak sonrasında oyunun amacının ne olduğu belirsizdi
- Tek başına geliştirilen bir projede, potansiyel taşısa bile tamamlanması bir yıldan fazla sürecek işlere devam etmek zordu
- Dungeons and Dragons tarzı, sprite tabanlı bir adventure oyunu çekiciydi, ancak oyuncu silahlarına göre hareketler, canavarlar, büyü efektleri ve savaş sistemi gibi unsurlar çok büyük bir iş yükü çıkarıyordu
- Kılıçla saplama ve savuşturma animasyonları yapıldıktan sonra, topuz, yay, pelerin gibi varyasyonların da eklenmesi gerektiğinden sanat yükü giderek büyüyordu
Yeniden açmak ve kodu tekrar kullanmak
- Ertelenmiş oyunlar tamamen ölmüş projeler değildi; kaynak, varlıklar ve proje dosyaları bulunabiliyorsa yeniden ele alınabiliyorlardı
- Thief of Baghdad yaklaşık 18 ay sonra renkli bir sürüm olarak yeniden başlatıldı, Scheherazade adını aldı ve belli bir amaç hissi de oluşmaya başladı
- İkinci denemede de sonunda tarif etmesi zor o çekicilik yeterince oluşmadığı için yeniden durduruldu
- Askıya alınan projelerdeki kodlar sonraki işlerde yeniden kullanılabiliyordu
- Fisher–Yates shuffle algorithm
- Erken dönem Mac'lerde monitör renk derinliğini değiştiren kod
- polygon-point çarpışma kodu
- Hızlı trigonometri için sine lookup table
- dot-product ve cross-product rutinleri
- Bu tür prototip çalışmaları israf olarak görülmüyordu
Apple'da da süren iteratif yaklaşım
- 1990'lar ilerledikçe indie Mac oyun geliştiriciliği dönemi kapanıyor gibi görünüyordu ve California'ya gidip Apple'da çalışma teklifi gelince bunu kabul etti
- Apple'a katıldıktan sonra boş zamanda Apple dışı projeler yapamayacağını düşündü
- Teknik olarak, iş dışı kod yazmak için yöneticiden yazılı izin almak gerekiyordu
- Apple oyun işinde olmadığı için izin alınabilirdi, ancak isteyip de reddedilme ihtimali caydırıcıydı
- Oyun dışı iş projelerinde de hızlı prototipleme yaklaşımı sürdü
- Diğer çalışma arkadaşları tasarımı beyaz tahtada tekrar tekrar gözden geçirip kod yazmadan önce dikkatle plan yapıyordu
- Kendisi ise doğrudan dalıp derleyerek iterasyon yapmayı tercih ediyordu
- Kodu hızla bir araya getirip darboğazları erkenden görmek ve gerekirse projeyi neredeyse baştan başlatmak tekrar tekrar uygulandı
- Bir projeyi üç kez başlatıp yeniden başlamış olsa bile, dikkatle tasarlayan çalışma arkadaşlarının kodu çalıştırdığı zamana yakın bir noktada yeterince iyi bir sonuca ulaşabiliyordu
- Son kod revizyonu çoğunlukla sadeleştirme oluyordu; baştan itibaren kodu büyük ölçüde değiştirilebilir bir şey gibi ele alarak nasıl düzenlenmesi gerektiğine dair sezgi geliştiriyordu
- Bloom Filter öneren bir iş arkadaşına, gerçek verinin o kadar küçük olduğunu, performans kazancının önemsiz kaldığını ve yalnızca kod tabanının karmaşıklığını artırdığını gördüğü için bunu zaten attığını söyleyebildiği bir deneyimi de olmuştu
Always Be Iterating
- Emekliliğe yaklaşırken Apple'da katkı sunan bir çalışan ve iyi bir ekip arkadaşı olduğunu hissetti
- Tek başına sabahlara kadar kod yazdığı günlerin aksine, Apple'daki en iyi taraf birlikte çalıştığı mühendislerdi
- Birlikte çalıştığı kişiler arasında kendisinden bir büyüklük sırası daha iyi programcılar da vardı
- Kendini en hızlı programcılardan biri olarak görüyordu; o haftaki toplantı demosu için bir prototip gerekiyorsa iki farklı sürüm çıkarabilecek kişi olmaya daha yakındı
- Kızlarına tekrar tekrar söylediği ifade A.B.I. idi
- “Always”
- “Be”
- “Iterating”
- Yani “Always Be Iterating”
- Yayımlanamamış oyunların proje, kaynak ve araçları disk imajları halinde düzenlenip GitHub'da paylaşıldı
- Volume 3 de planlanıyor, ancak her projeyi “release” edilebilir duruma getirme işi bulunduğundan yayımlanma zamanı için bir söz verilmiyor
1 yorum
Hacker News yorumları
1989 civarında programlamaya başladığımdan beri yarım bıraktığım proje sayısı en azından bir düzine, en fazla yüz civarında; çoğu da oyun. Çoğunu Mac Plus ya da Mac LC için yaptım; yazıda bahsedilenlere benzer mekaniklere veya sanat tarzlarına sahip olanlar da çoktu.
Yayınladığım ya da içinde yer aldığım az sayıdaki proje, bana kendimin bir gölgesi gibi geliyor. Özgeçmişim ve kariyerim de öyle. Erken dönemde başarılar biriktirme fırsatı bulamadığı için gerçeğe dönüşememiş bir rüya hayatı yaşamış bütün bir varlığın parmak izleri gibi. Bu yüzden temel gelirin, insan potansiyelini 10 ya da 100 kat büyütebileceğini; hizmet ekonomisinden özne olmaya ve kendini gerçekleştirmeye geçişi sağlayıp herkesin pasif gelir yaratmasına imkân verebileceğini düşünüyorum. Bir de Pararena'yı gerçekten çok oynadım.
Sizin çevrenizde durum farklı olmuş olabilir ya da ülkenizde böyle bir yaklaşım uygulanmamış olabilir. Birden fazla oyun üzerinde çalışmak ile tek bir oyuna odaklanıp onu bitirmek arasındaki farkın ne olduğunu merak ediyorum. Temel gelir olsa, tamamlanmış projeler çıkacak kadar; üstelik kısa süreliğine değil, sürekli olarak bunları yapabilir miyiz? Ebeveyn olunan dönem ya da çocukluk gibi yaşamın bazı evrelerinde temel gelir mantıklı olabilir, ama insanın kendini aradığı dönemde sorumluluğun yardımcı olduğunu düşünüyorum.
Bu düşünce tarzını anlamak gerçekten zor. Sihirli temel gelir, çalışmayan kitleler için bir asgari ücret olacak; bunun nasıl sürdürülebilir ya da iyi bir şey olabileceğini düşünüyorsunuz?
Teorik olarak bunları düzgünce tamamlama seçeneği vardı; ama bunu yapmaya çalışsaydık kurum batardı, dolayısıyla bu sadece teorik bir seçenekti. İşte kullandığım ve özel hayatımda da mecburen kullanmak zorunda kaldığım yazılımların hâline bakınca, çevremdeki herkes böyle bir hayat yaşıyormuş gibi geliyor. Neyse ki kullanıcıların seçeneği yok; ya berbat olanı satın almak ya da hiçbir şey almamak zorundalar. Berbat şeyleri satarken güvendeyiz.
Çalıştığım birçok şirket tam da böyle işliyordu. Mühendisler parlak yeni özellikler yapıyor, bunlar yayınlanıyor, herkes mutlu oluyor. Birkaç ay sonra ise bir sürü bug birikiyor.
İlk yapan kişiler çoktan başka ekiplere geçmiş oluyor. Gerekçe “silo'ları kırmak” ama gerçekte daha çok “herkesi ikame edilebilir yapmak” gibi. Projeyi devralan mühendisler, başka bir ekip devralana kadar bakım yapmak ve bug düzeltmek zorunda kalıyor. Korkunç bir şey.
Üstelik “minimum düzeyde uygulanabilir” olmak, “uygulanamaz”dan yalnızca bir adım uzakta. Her proje İkarus'a dönüşüyor; kanatlar erimeden önce güneşe ne kadar yaklaşabileceğini test ediyor.
[1]: https://store.steampowered.com/app/246900/Viscera_Cleanup_De...
Devralan kişiler karar verecek yetkinlikte değildi, büyük vizyonum kenara itildi ve o özelliğin yönetilmesindeki beceriksizliği izlemek dayanılmazdı; hâlâ aptalca bug'lar çıktıkça sinirleniyorum. Üstelik yeterince uyum sağlama zamanı varken uyardığım hâlde böyle oldu. Yine de önemli bir ders aldım ve bir dahaki sefere inatçı biri gibi görünsem bile geri adım atmayıp mücadele edeceğimi kesin olarak söyleyebilirim.
Bağımsız geliştiricilere de iyi uyuyor; bir ölçüde büyük şirketlere de uygulanabilir. Bu felsefe, anlamlı zaman harcanacak özellikleri ya da ürünleri belirlemek için iyi. Hatta sizin tarif ettiğiniz durum, asıl yazının önerdiği yöntemi izlememenin doğrudan sonucu olarak da görülebilir.
Son zamanlarda retro geliştirmeye dönüp onunla uğraşıyorum. Programlamayı ilk öğrendiğim 68K Macintosh için yazılım yapıyorum.
Eski kitapları, comp.sys.mac.programmer yazılarını, Soft Dorothy ve GliderPro gibi kaynak kodlarını epey karıştırdım. Eski koda yeni gözlerle bakmak tuhaf bir deneyim. Eski Mac’lerin neden bu kadar sık çöktüğünü, bunun yalnızca “bellek koruması yoktu” açıklamasının ötesindeki nedenlerini de görüyorsunuz. Yazarın söylediği gibi 1 bit sanatı da seviyorum; 1 bit sanat paylaşan Twitter hesaplarının bir listesini tutuyorum. Eksik biri varsa haber verirseniz sevinirim: https://twitter.com/i/lists/1578111923324944397
Kısıtlı sistemler için programlama yapmanın güzel yanı, seçeneklerinizi sınırlaması. Uygun kütüphaneyi çekince her şeyi yapabildiğiniz modern deneyimden iyi bir mola oluyor. Bazen hesaplama gücünün donup kaldığı, iyi anlaşılmış sistemler için yazılımın yalnızca giderek daha iyi hâle geldiği bir dünya hayal ediyorum. Mac 68K gibi eski sistemlerde donanım ilerleme hızı baş döndürücü kadar yüksekti. 68020 ya da 80386 gibi yeni bir işlemci çıktığında, onun potansiyelini gerçekten kullanan bir şeyler yapmak için en fazla birkaç yılınız olurdu. Çok geç kalırsanız, yeni donanım nesli için yeni yazılımlarla rekabet etmek zorunda kalırdınız.
Handle vb. şeyleri ele alan sarmalayıcı fonksiyonlar da yapmak istiyorum. Yine de dediğiniz gibi, modern işletim sistemleriyle karşılaştırınca Toolbox’ın ne kadar basit olduğu şaşırtıcı. Yeniden retro geliştirme yapmak gerçekten eğlenceli geliyor.
Blogun tamamı harika. Göz atmaya değer çok ilginç içerik var.
Bir şeyi bırakmak sorun değil; bırakılan projelerden de öğrenilebilir ve bazı parçalar yeniden kullanılabilir. Benim için dönüm noktası, bitirebileceğim kadar küçük yapmaya karar verdiğim andı. Bitirme becerisini geliştirmeye yardımcı oldu; bu ayrı bir beceri ve öğrenmesi zor. Çünkü ancak çok uzun ve zorlu bir sürecin sonunda ortaya çıkıyor, bu yüzden çoğu kişi neredeyse oraya kadar gelemiyor. Video oyunu yapan arkadaşlarımın hepsi işe kendi motorlarını yazarak başlıyor ve seviye editörü yapma aşamasına geldiklerinde tükeniyorlar. Araç geliştirme gibi konularda çok şey öğreniyorlar ama ironik biçimde bunlar zaten yapabildiklerine benzer şeyler oluyor; asıl oyunu ise yapamıyorlar. Bu, bir katedral inşa ederken taş ustalığını öğrenmeye benziyor; sonunu göremezsiniz. Başarısız olamayacak kadar küçük başlamalı, sonra giderek daha büyük projelere çıkmalısınız.
Şu anda bir Unity projesi üzerinde çalışıyorum ve RTS tarzı bir bina yerleştirme sistemini en iyi nasıl kuracağımı düşünürken zorlanıyordum. Her zamanki gibi doğrudan dalmak yerine, oyuncunun bina yerleştirmeye hiç ihtiyaç duymayacağı şekilde oyun konseptini değiştirmeye karar verdim. Deneyince, yapmaya çalıştığım şey için bunun aslında daha iyi bir kullanıcı deneyimi olduğunu gördüm. Başta “bir sonraki iterasyonda bina sistemini eklerim” diye kendimi ikna ediyordum ama artık muhtemelen eklemeyeceğim.
Eksiltmek neredeyse her zaman daha iyidir. Küçük bir başlangıç noktasını gerçekten tamamlamak, bir sonraki iterasyon için nitrometan gibidir. %100’e ulaşmanız gerekir ki bir sonraki tur çok daha iyi olsun. %80’de durursanız geriye yalnızca kayayı tekrar tepenin üstüne itmeniz gerektiği hissi kalır.
Erişilebilirlik işi yapmaya başladıktan sonra bunların çoğunu tekrar çıkarıp erişilebilir hâle getirerek yeniden yaptım. Bazıları çok eski Bootstrap sürümleri kullanıyordu, bu yüzden güncel Bootstrap’e yükseltme işini de birlikte yaptım. Eski tasarımları erişilebilir hâle getirmek bile bana gerçekten çok şey öğretti. Siteleri ve uygulamaları değerlendirirken neye bakmam gerektiği konusunda çok daha iyi bir bakış açısı kazandığımı hissediyorum. Kendi yaptığım şeylerin ne kadar erişilemez olduğunu fark etmemi de sağladı.
John’un oyunları, çocukken Mac’te programlamayı ilk öğrenen benim için ilham kaynağıydı. Glider’ı çok oynadım, Pararena’yı ise daha da çok. O yankılı açılış örneği hâlâ kafamda çakılı duruyor.
Muhtemelen ResEdit ile o oyunların resource fork’larını kurcalamaya bundan çok daha fazla zaman harcamışımdır. Çok fazla şey bitiremedim ama birkaç küçük shareware oyununu tamamlayıp AOL’e yükledim. Birkaç ay sonra uzak Kaliforniya’dan posta kutuma bir çek geldiğinde gerçekten şaşırmıştım.
Erken Mac dönemi gerçekten özel bir zamandı; tek başına geliştirme yapan birinin, yaratıcılığı ve zamanı varsa bir şeyler yapıp dünyaya sunabileceği hissi vardı. Böyle bir yazı yazıp beni anılara götürdüğün için teşekkürler; umarım emekliliğin tadını çıkarıyorsundur.
İlk bilgisayar kullanıcıları ve ilk geliştiriciler olarak bizim için her şey yeni olduğu için mi özeldi? Yoksa o zamanlar havada başka bir şey mi vardı? Yaptığım küçük oyunları sevmiş olmana sevindim. Kaliforniya’dan gelen o çekin, bugünkü kariyerin ne olursa olsun seni o yola iten şey olup olmadığını da merak ediyorum.
Bu yazının amacı projeleri terk etmeyi normalleştirmekse, bunun iyi bir fikir olduğundan emin değilim. Her şeyi bir kenara bıraksak bile muazzam bir zaman kaybı olabilir ve “yine de bir şey öğrendik” demek tek başına bunu haklı çıkarmaz. Bitirirken de öğrenmek gerekmez mi?
Daha önce kimsenin yapmadığı bir şey olduğu için ilerlerken yöntemi buluyorlar ve süreç içinde epey hata yapıyorlar. Videoda vurgulanan noktalardan biri, böyle bir şey olduğunda ekibin durup aynı şeyi yeniden denememesi. Devam edip işi tamamen bozuyorlar ve bunu malzemelerle istedikleri gibi deney yapma fırsatına çeviriyorlar.
Bunun ne kadar harika olduğundan uzun uzun bahsediyor. Bitmiş ve parlatılmış bir ürün üretme yolunda olsalardı yapamayacakları denemeleri özgürce yapabildikleri için, kullandıkları malzemenin davranışını daha iyi öğrenmek adına eşsiz bir fırsatı değerlendiriyorlar. Zaten çöpe dönüşmüş bir şeyi daha fazla bozmak zor olduğundan, artık risk aldıklarını söylemek de pek kolay değil.
Başarıya odaklanmaktansa öğrenme ve deneye odaklanan bir zihniyetin, yaptığın işte gerçekten çok iyi olmanın en iyi yollarından biri olduğu tespitine katılıyorum.
ChatGPT bunu “Hızlıca yap, asla yayımlama. Yayımlayana kadar” diye özetledi.
Bazen hiçbir yere gitmeyen bir projeye tutunup yeterince uğraşırsam bir yere varır diye düşünüyorum; ama artık ne eğlenceli oluyor ne de yeni bir şey öğreniyorum. “Bitirmeliyim, bitirmeliyim” diye kendimi zorluyorum; sonra “neden?” diye sorunca genelde bunun bitirememekten duyulan korku olduğunu, ya da belki de zor bir dönem ile başarısız bir proje dönemini ayırt edememekten korktuğumu görüyorum. Hangisi olursa olsun, başarısız olduğunda özgürleşmiş hissettiğim çok oldu. Yeniden başlamak için bir fırsat oluyor.
Ekran görüntüsündeki piksel sanatlarının bazıları gerçekten harika.
Şahsen küçük şeyler yayımlayıp sonra yineleyerek ya da atarak çok daha fazla öğrendim ve kazandım.
Bu yaklaşımı seviyorum ve ilginç buluyorum, ama organizasyon düzeyinde daha zor görünüyor. Projeler ve teknolojiler hakkında keşfettiğimiz pek çok şey, gerçek projenin çalıştığı ölçekte uygulanabilirlikle ilgili ve küçük deneylerde mutlaka ortaya çıkmıyor.
Bazen mesele teknik bir sorun değil, “buradaki geliştiricilerin çoğunun bunu bu şekilde yapmayı anlamasını sağlayabilir miyiz?” gibi bir şey de olabiliyor. Bu, böyle denemeleri daha az yapalım demek değil. Küçük projeler deneyerek öğrenilebilecek şeyler var. Sadece bunun büyük ölçekte de çalışacağını garanti etmez.
Benim sorunum sadece zaman. İşten çıkıp eve geldiğimde bilgisayarın başına oturmak en son yapmak istediğim şey.
Haftadaki iki izin günüm de ev işleriyle doluyor; bu yüzden yine bilgisayar ekranının karşısına geçmek istemiyorum.
Sizin gibi yapabilen insanlara imreniyorum. Şu anda sektör, teknoloji ve programlamayı tüm hayatı haline getiren insanları arayan bir tarikat gibi geliyor. Gereksinimlerin kendisinden nefret etmiyorum; iş ahlakım var ve iyi olmak istiyorum, ama beklentiler her zamankinden yüksek görünüyor.
Ekrana bakmayı gerektirmeyen hobiler edinebilecek kadar iş güvencesine kavuşmayı umuyorum. Yakında metal işçiliğini denemek istiyorum.