Bazen bir süre yazılım mühendisi olarak çalıştığınızda zanaatın hangi alanlarının bataklık olduğunu öğrenirsiniz.  Bunu nasıl yapacağınızı tam olarak biliyorsunuz, olabilecek tüm sorunları biliyorsunuz ve bu tür alanlara özel bir dikkatle yaklaşıyorsunuz, birisi bunu daha hızlı ve daha iyi yapabileceğini düşündüğünde, sizi neyin beklediğini bilmeden yüksek sesle gülüyorsunuz.  Bu, kariyerim boyunca pek çok deneyime sahip olduğum alanlardan birinin hikayesi.  400 Saatlik Video Yüklemelerinin Bana Öğrettiği Şeyler  2007 yılı civarında bir yerde YouTube zaten iki yaşındaydı, yani neredeyse hiç kimse bundan haberdar değildi. İnsanlar videoları SD'ye kaydediyor ve bunları CD veya DVD'lerde saklıyordu.  Eskiden hiç kimse her videoyu internete yükleyeceğinizi düşünmezdi çünkü bunları indirmek çok pahalıydı.  Belki torrentler hariç. Ancak ekranınızı kaydetmek ve altyazı eklemek için zaten uygulamalar vardı, bu nedenle çevrimiçi eğitim videoları yükleyip yükleyemeyeceğinizi görmek ilginçti.  Bundan sonra bir CentOS sunucusu satın aldım ve çevrimiçi bir video eğitim sitesi oluşturmaya başladım.  İşlevsel olması için iki şeyi çözmem gerekiyordu: insanların eğitimleri yüklemesine nasıl olanak tanıyacağım ve insanların bunları izlemesine nasıl olanak tanıyacağım.  Video yüklemenin oldukça kolay olduğunu düşündüm. Sadece HTML'ye bir giriş alanı eklersiniz ve dosyayı sunucuya alırsınız.  Ancak tahmin edilenden daha zor oldu. Birincisi videonun boyutu, ikincisi ise internet bağlantısının kalitesiydi.  İhtiyaç duyduğunuz her şeyi sunan (hala da bunu sağlayan) tek dil olan PHP'yi kullanan sunucum harikaydı. Apache'de ve daha sonra Nginx'te çalışıyordu.  Ngnix'in ilk sürümlerinde böyle bir yük beklenmemesi vardı. Sunucunun 30-60 dakikaya kadar sürekli yüklemeyi ve aktarım boyutunu kabul etmesini sağlamak için çeşitli ayarları yapılandırmam gerekiyordu. Biraz deneme gerektirdi ve sonunda işe yaradı.  Sorunlu olan bir diğer şey de Ngnix'in süreçleri çatallama şekliydi. Ngnix'in ilk sürümlerinde çatalların beklenmedik şekilde takılmasına neden olan bazı hatalar vardı.  Bir kullanıcı tarafından asılan böyle bir çatal, daha sonra diğer kullanıcılara devredildi, bu da onların da video yükleyemediği anlamına geliyordu.  Kimin hangi işlemi kullandığına dair bilgiyi depolamak ve zamanı geldiğinde onları öldürmek zorunda kaldım. Üstelik gün içinde hatalar biriktiği için her gece düzenli olarak tüm süreçleri kapatmak zorunda kalıyordum.  Nginx ve PHP yapılandırmasında geçirilen uzun saatler sonunda yükleme işlemi çalışmaya başladı.  Bir sonraki adım, videoları kullanıcılara göstermekti. O zamanlar bir çevrimiçi oyuncu mevcuttu. Adını hatırlamıyorum ama güzeldi ve altyazılıydı. Bu önemliydi çünkü herkesin video eğitimlerinden öğrenebilmesini istedim.  Ancak başka bir sorun ortaya çıktı. Ham video oynatmak çok zordu. Oldukça hızlı bir bağlantıda çok fazla hata veriyordu ve hatta bazen tarayıcıyı bile bozuyordu.  Zaten ffmpeg vardı, bu yüzden videoyu nasıl optimize edeceğimi buldum. Video eğitimlerinde önemli olan, ekranın tamamını yüksek kalitede göstermek istemenizdir. Çünkü aksi takdirde insanlar neye tıkladığınızı ve monitörde hangi metinlerin görüntülendiğini göremez.  O zamanki canlı kayıtlarla karşılaştırıldığında video eğitimlerinin kalite gereksinimleri daha yüksekti (bu nedenle video eğitimleri uzun yıllar boyunca YouTube'un güçlü bir ayağı değildi).  Yüksek kalite ve küçük video boyutu avantajını kazanmak için ffmpeg ile pek çok deneme yapılması gerekti. Elbette bu anında yapılamazdı, dolayısıyla MySQL veritabanlarını sorgulayan ve halihazırda düzgün şekilde dönüştürülmemiş videoları bulan bir cron işi vardı.  Bir videonun yalnızca ffmpeg tarafından üretilip üretilmediğini kontrol etmek de önemliydi. Ffmpeg harika olmasına rağmen bazen video veya ses sıkıştırma formatını, hatta giriş videosunun boyutunu bile beğenmiyordu. Sonuç olarak bir çıkış videosu üretti, ancak siyahtı.  Bu yüzden başka bir cron işi ekledim. Görevi, çıktı videosunda ffmpeg'i tekrar çalıştırmak, boyutunu, çözünürlüğünü okumak ve küçük resim için de ihtiyacım olan bir kareyi yakalamaktı. Daha sonra süreç, küçük resmin siyah olup olmadığını görmek için pikselleri kontrol etti. Hiçbir hata yoksa ve küçük resim siyah değilse, dönüşümün başarılı olduğu varsayılırdı.  Yeterli olacağını düşünmüştüm ama öyle olmadığı ortaya çıktı. Çünkü bazen ffmpeg veya diğer kütüphane takılıp kalıyor. Yani dönüştürme süreci veya doğrulama süreci de askıda kaldı ve bir şeyler ters giderse bilgileri kaydedemedi.  Bu yüzden başka bir cron işlemi ekledim. Üçüncü süreç önceki iki süreci kontrol etmekti. Bir dönüştürme işleminin ne zaman başladığını, en son ne zaman canlı olduğunu bildirdiğini ve mevcut zamanla karşılaştırmasını veritabanında kontrol etti.  Örneğin, bir dönüşüm üç saat boyunca yanıt vermediyse, dönüşümü başarısız olarak işaretledim ve yeniden çalıştırma için ekledim. Bir doğrulama işlemi 30 dakikalık çalışmanın ardından yanıt vermezse veritabanı doğrulaması başarısız oldu, bu nedenle videonun sıfırdan dönüştürülmesi ve süreçlerin durdurulması gerekiyordu.  Genellikle bu yardımcı oldu. Sistem üçüncü kez e-posta gönderdiğinde işe yaramadıysa bir sorun var demektir.  Sonunda sistem çalıştı ve insanlar video yükleyebildi. Videolar dönüştürüldü ve sayfada küçük resim ve altyazılarla birlikte gösterildi.  400 saatten fazla zaman harcadığım ilginç bir projeydi. Bana video, ses işleme ve doğrulama hakkında çok şey öğretti.  Ancak aynı zamanda yükleme işlemlerinin odaklanmam gereken bataklık bir alan olduğunu da öğretti. Bu ödendi…  Yüklemeleri Sınırlayarak Satışları Sınırlarsınız  Şimdi 2023'te durumun farklı olduğunu düşünebilirsiniz. Ama değil. Pek çok şey değişti elbette. İşlem gücü ve depolama elde etmek daha kolaydır. İnternet bağlantıları daha iyi. Araçlar daha iyidir ve daha ayrıntılı belgelere sahiptir.  Ancak yine de varsayılan ayarlarla bazı yüklemeler boyut nedeniyle başarısız olacaktır. Varsayılan yükleme formu Android cihazlarda çalışmaz. Bu sorunu birçok web uygulamasında tekrar tekrar görüyorum.  Birden fazla video formatını ve hatta fotoğrafları yönetmek zordur. Özellikle şu andan itibaren yeni deneysel formatlar var.  Örneğin birkaç yıl önce sosyal medya için bir içerik yönetimi ve planlama sistemi geliştiriyordum.  Pazarlamacılara yüklenen fotoğrafı düzenleme olanağı sunması gerekiyordu. Kırpma ve filtreler gibi sadece temel şeyler. En son kütüphaneleri kullanırken bile %100 güvenilir değildi ve en azından kabul edilebilir ölçüde kullanılabilir hale getirmek için çok fazla ince ayar yapılması gerekiyordu.  Çoğu durumda dosya yüklemek sürecin önemli bir adımıdır. Örneğin uzun bir form doldurduğunuzda son adımda bir dosya yüklemeniz gerekiyor.  Yükleme herhangi bir nedenden dolayı başarısız olursa, kullanıcıyı daha önce girmiş olduğu tüm verileri kaybetmekten korumanız gerekir.  Yükleme başarısız olduğunda bir senaryoyu veya dosyaya uyguladığınız sonraki herhangi bir işlemi ele almanız gerekir.  Bu tür sorunlardan bazılarını çözmenin bir yolu, kullanıcıları boyut ve formatla sınırlamaktır. Kulağa cazip geliyor.  Son zamanlarda insanların fotoğraf yükleyerek kendi ürünlerini oluşturabildikleri bir e-ticaret projesi üzerinde çalışıyordum. Ancak uygulama, görüntü boyutunu 2 MB ve çözünürlüğü 1000x1000 piksel ile sınırladı.  Bu sınırların 3 MB ve 2000x2000 piksele çıkarılması önerisi vardı. Telefonumu çıkardım, fotoğrafını çektim ve insanlara fotoğrafın boyutunu gösterdim.  4 MB boyutunda ve 3000x3000 piksel civarındaydı. Dolayısıyla bunu açıklamak için başka bir teklif yapıldı. Ben de telefonumun fotoğraf çektiği çözünürlüğü arttırdım ve bu sınırları tamamen kaldırmamız gerektiğini söyledim.  Ayrıca, insanların yüklemeden önce fotoğrafları dönüştürüp küçültebilmesi nedeniyle sınırların korunmasına yönelik bir öneri de vardı.  Bu doğru. Ancak insanların çoğunluğu bunu nasıl yapacağını bilmiyor, düşünmek istemiyor ve bunu yapmakta zorlanabilir. Müşteriyi ve ekibi sınırları tamamen kaldırmaya ikna edebildim.  Bu harika bir hamleydi çünkü satışları büyük ölçüde artırdı ve çıkış oranı da düştü, bu da insanların telefonlarından ürün satın almak istediklerini ancak gereksinimler nedeniyle engellendiklerini kanıtladı. Sınırların kaldırılması, birçok insanın istediği ürünleri satın alabilmesini sağlayacak kolay bir çözümdü.  Dosya yüklemek bataklık bir alandır ancak bazı durumlarda satış ve müşteri memnuniyeti (yine satış) açısından kritik olabilir.  Bu nedenle geliştirdiğim sistemlerin dosya yükleme işlemlerini gerçekleştiren bu alanlarına özellikle dikkat ediyorum çünkü burası müşterinin işini en çok etkileyebilecek yer.  Dosya yüklemeyle ilgili hikayeleriniz var mı? Yorumda paylaşın!  Ayrıca kalp simgesine tıklayın, beğenin ve sosyal medyada paylaşın. Bu tür konular hakkında daha fazla yazmak beni motive ediyor!  Bir yazılım mühendisi olarak bu konuyu çok fazla düşünmek istemiyorsanız   da göz atın. Javascript dosya yüklemelerini işlemek için bir API'dir. Bu hikayeyle katıldığım bir yarışmaya sponsor oluyorlar. Filestack ve HackerNoon - paylaşma motivasyonunuz için teşekkürler! Bunu yapmak harikaydı! Filestack'a

2022 - HackerNoon Contributor of the Year - Monitoring

Read My Stories

Nominated for 2022 - HackerNoon Contributor of the Year - Monitoring

Bu ses hikayenin orijinal dilinde üretilmiştir!

400 Saat Sonra 2 MB Sınırını Kaldırmak Satışları Nasıl Büyük Bir Şekilde Arttırdı?

About Author

YORUMLAR

ETİKETLERİ ASIN

BU YAZI

Related Stories

HackerNoon Yazma Yarışmasını mı Kazanmak İstiyorsunuz? İşte #crypto-api Yarışması Kazananlarının Önerileri

İş Akışınızı 10 Kat Nasıl İyileştirirsiniz: 17 Temel Uygulama

Sulara Yelken Açmak: Data Lakes ile Üretim Sınıfında RAG Uygulamaları Geliştirme

Kripto Büyümesi: Etkili Kullanıcı Kişilikleri Oluşturma

HackerNoon Yazma Yarışmasını mı Kazanmak İstiyorsunuz? İşte #crypto-api Yarışması Kazananlarının Önerileri

İş Akışınızı 10 Kat Nasıl İyileştirirsiniz: 17 Temel Uygulama

Sulara Yelken Açmak: Data Lakes ile Üretim Sınıfında RAG Uygulamaları Geliştirme

Kripto Büyümesi: Etkili Kullanıcı Kişilikleri Oluşturma

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps