02 Eki 2025·8 dk
Larry Wall, Perl ve Metin İşleri İçin Koli Bandı Zihniyeti
Larry Wall’ın “koli bandı” felsefinin Perl’i web otomasyonunda nasıl vazgeçilmez kıldığı ve bunun bugün pratik metin işleme hakkında hâlâ öğrettiği dersler.
Larry Wall’ın “koli bandı” felsefinin Perl’i web otomasyonunda nasıl vazgeçilmez kıldığı ve bunun bugün pratik metin işleme hakkında hâlâ öğrettiği dersler.
“Koli bandı programlama”, en iyi aracın genellikle gerçek problemi hızla çözen araç olduğu fikridir—çözüm hoş olmayabilir, kalıcı olmayabilir veya büyük bir sistem olarak tasarlanmamış olabilir, ama işi görür.
Bu, özensiz iş yapmak anlamına gelmez. Dağınık girdiler, eksik şartnameler ve mimari diyagramınızın ne kadar zarif olduğuna bakmayan bir teslim tarihiyle yüzleştiğinizde ivmeyi değerli kılmaktır.
Koli bandı zihniyeti basit bir soruyla başlar: Acıyı yok eden en küçük değişiklik nedir? Bu, 10.000 dosyayı yeniden adlandıran kısa bir betik, günlüklerden hata satırlarını çıkaran hızlı bir filtre veya kaotik bir dışa aktarımı bir tablo programının okuyabileceği bir şeye dönüştüren tek seferlik bir dönüşüm olabilir.
Bu makale, Larry Wall ve Perl’i bu tavrın tarihsel bir örneği olarak kullanıyor—ama amaç nostalji değil. Metin, günlük, CSV, HTML parçacıkları veya aslında sadece tutarsız dizeler yığını olan “veri” ile çalışırken hâlâ geçerli olan pratik dersleri çıkarmak.
Eğer profesyonel bir geliştirici değilseniz ama düzenli olarak şunlara dokunuyorsanız:
…tam da hedef kitlesiniz.
Sonunda dört net çıkarımınız olacak:
Larry Wall “zeki” bir dil icat etmeyi hedeflemedi. Gün boyunca dağınık metinlerle uğraşan, çalışan bir mühendis ve sistem yöneticisiydi: günlük dosyaları, raporlar, konfigürasyon parçaları, mail üstbilgileri ve el kitabının vaat ettiği formatla hiç tam olarak uyuşmayan ad-hoc veri dökümleri.
1980’lerin ortalarına gelindiğinde Unix’in zaten mükemmel araçları vardı—sh, grep, sed, awk, pipe’lar ve filtreler. Ama gerçek işler nadiren tek ve düzenli bir komuta sığardı. Bir pipeline ile başlardınız, sonra küçük bir durum makinesine, daha iyi string işlemeye, yeniden kullanılabilir bir betiğe ve gelecek hafta tekrar düzeltebilecek kadar okunaklı tutma yoluna ihtiyaç duyduğunuzu keşfediyordunuz.
Larry’nin motivasyonu pratikti: “tutkal işi”nin sürtünmesini azaltmak; araçları bağlamak ve metni dönüştürmek için sürekli yapılan, parıltısız ama gerekli işi hafifletmek.
Perl’in asıl hedefi Unix araçlarının yerini almak değil—bir tek satırlık pipeline’ın mini bir programa dönüştüğü durumlarda bunları düzenlemeyi kolaylaştırmaktı. Birden fazla yardımcı program arasında (her birinin kendi tırnaklama kuralları ve kenar durumları varken) atlamak yerine, Perl şu işi tek yerde sunuyordu:
Bu “koli bandı” zihniyeti: mükemmellik değil, işleri bir arada tutan hızlı, dayanıklı bir çözüm.
Perl kültürü, günlük gerçeklikle uyuşan bazı değerleri benimsedi: saflık yerine pragmatizm, tören yerine ifade özgürlüğü ve meşhur “bir işi yapmanın birden fazla yolu vardır” yaklaşımı. Bunlar gösteriş için slogandan fazlasıydı—özünüzdeki en az acıyla problemi çözme izniydiler.
Perl’in erken popülerliği geriye dönüp bakınca gizemli gelebilir. Değildi. O dönemin ihtiyacına uyuyordu: dağınık girdilerle başa çıkabilen, mevcut sistemlerle entegre olabilen ve yorgun bir insanın bir sonraki alarm gelmeden önce çalışan bir betik göndermesine izin veren bir dil.
Erken web siteleri uygulama çerçeveleri ve yönetilen hizmetlerle çalışmıyordu. Birçok site bir web sunucusu, bir dizi CGI betiği, birkaç düz dosya ve belki henüz her şeye “merkezi” gelmeyen basit bir veritabanından oluşuyordu.
Operasyonlar günlük ağırlıklıydı: erişim günlükleri, hata günlükleri, yükleme klasörleri, form gönderimlerini alan e-posta kutuları ve sessizce veritabanına dönüşen metin dosyaları. Bir şey bozulduğunda, genellikle dünkü günlükleri grep’leyip bir betikte ince ayar yaparak teşhis ediyordunuz.
Otomasyon basitçe: birinin her seferinde manuel yapmasına gerek kalmadan çalıştırılabilen yineleyebilir bir görevdi.
Bu görev bir web isteğiyle tetiklenebilirdi (biri form gönderdiğinde, “ara”ya tıkladığında, bir rapor indirdiğinde) veya planlanmış bir iş tarafından (cron her saat günlükleri döndürmek, sayfaları yeniden oluşturmak, özetler göndermek için) tetiklenebilirdi.
Küçük sitelerin bile yapması gerekirdi:
Bunu elle yapmak zaman kaybettirmekle kalmaz—hatalar ve gecikmeler getirirdi.
Perl her şeyin arasında güzelce yer buldu:
grep, sed, awk, sort)Perl bir isteği okuyup sistem komutlarını çalıştırabilir, dağınık metni dönüştürebilir ve HTML yazabilir veya dosyayı güncelleyebilirdi—hepsi bir betikte. Bu “tutkal dil” rolü erken web otomasyonunu pratik kıldı: ayrı ayrı faydalı ama güvenli ve tekrar edilebilir şekilde zincirlemeyi zor olan parçaları birleştirdi.
Perl, klasik Unix komut satırı araçları ile yeni web betik dünyası arasında rahatça oturabildiği için “koli bandı” itibarını kazandı. Veriniz günlüklerden, e-postalardan, CSV dışa aktarımlarından veya HTML parçacıklarından başladıysa, Perl bunları alıp yeniden şekillendirebilir ve bir sonraki araca teslim edebilirdi—tüm bunlar yeni bir ekosistem benimsetmeye zorlamadan.
Kutudan çıktığı gibi Perl, metin manipülasyonunu alışılmadık derecede doğrudan hissettirdi:
split, join, replace) gerçek temizlik işleriyle eşleşirBu kombinasyon, günlük ayrıştırma ve düzenleme işleri için uzun bir araç zincirine ihtiyaç duymamanızı sağladı.
Unix, küçük odaklı programların birbiriyle bağlanmasını teşvik eder. Perl bu parçalardan biri olabilir: standart girdiden oku, metni dönüştür ve sonucu bir sonraki araç için yaz.
Yaygın zihinsel model şuydu:
oku → dönüştür → yaz
Örneğin: sunucu günlüklerini oku, tarih formatını normalize et, gürültüyü kaldır, sonra temizlenmiş dosyayı yaz—önce veya sonra sort, uniq veya grep ile pipe’layarak. Perl Unix araçlarını değiştirmedi; “awk + sed + shell” kombinasyonu zorlaştığında onları bir araya getirdi.
Aynı betik-önce yaklaşımı erken web geliştirmeye de taşındı. Bir Perl betiği form girdisini kabul edip onu herhangi bir diğer metin akışı gibi işleyebilir ve HTML çıktısı yazabilirdi—bu da sistem yardımcı programları ile web sayfaları arasında pratik bir köprü yaptı.
Çünkü Perl birçok Unix-benzeri sistemde çalışıyordu, ekipler genellikle aynı betiği makineler arasında minimal değişiklikle taşıyabiliyordu—dağıtımların basit, manuel ve sık olduğu zamanlarda değerliydi.
Düzenli ifadeler (genellikle “regex” diye kısaltılır) metin desenlerini tanımlamanın bir yoludur—tam kelime arama yerine kurallarla çalışan bir “bul ve değiştir” aracı gibi. Tam [email protected] gibi bir dize aramak yerine regex “bir e‑posta adresine benzeyen her şeyi bul” demenizi sağlar. Bu tek kayma—tam eşleşmeden desen eşleştirmeye—çok erken otomasyonu mümkün kıldı.
Regex’i şu tür soruları cevaplayan mini bir dil olarak düşünün:
Bir metni tablo programına yapıştırıp sütunlara sihirli şekilde bölünmesini istediyseniz, regex’i istemişsinizdir.
Erken web betikleri dağınık girdilerle yaşadı: insanlar tarafından yazılmış form alanları, sunucular tarafından üretilen günlükler ve farklı sistemlerden birleştirilmiş dosyalar. Regex üç yüksek değerli işi hızlıca yapmayı pratik hale getirdi:
Girdi doğrulama (ör. “bu bir URL’ye benziyor mu”, “bu bir tarih gibi mi görünüyor”).
Alan çıkarma (ör. bir günlük satırından durum kodu ve istek yolunu çekmek).
İçerik yeniden yazma (ör. telefon numaralarını normalize etme, eski linkleri değiştirme, kaydetmeden önce kullanıcı girdisini temizleme).
Perl’in regex desteği sadece orada olmakla kalmadı—sürekli kullanılmak üzere tasarlanmıştı. Bu, “koli bandı” zihniyetiyle mükemmel uyum sağladı: tutarsız metni alın, birkaç hedef kural uygulayın ve gönderilecek kadar güvenilir bir şey elde edin.
Regex günlük yaşamınızda “neredeyse yapısal” metinlerde öne çıkar:
12/26/25i 2025-12-26ya dönüştürme veya birden fazla tarih stilini tanıma.Regex o kadar güçlüdür ki şifreli hale gelebilir. Kısa, zekice bir desen gözden geçirmek, hata ayıklamak ve girdinin değiştiği durumlarda kırmak zor olabilir.
Sürdürülebilir bir yaklaşım, desenleri küçük tutmak, (dil destekliyorsa) yorum eklemek ve birinin gelecek ay dokunması gerekecekse bir “dahi” ifadesi yerine iki net adımı tercih etmektir.
Perl one-liner’ları şu şekilde düşünülmelidir: küçük betikler: terminalinizde doğrudan çalıştırabileceğiniz, metni dönüştürmek için tek amaçlı küçük komutlar. Hızlı bir temizlik, tek seferlik bir geçiş veya tam bir program yazmadan önce hızlı bir kontrol gerektiğinde parlıyorlar.
Bir one-liner genellikle standart girdiden okur, bir değişiklik yapar ve sonucu yazdırır. Örneğin, bir dosyadan boş satırları kaldırmak:
perl -ne 'print if /\S/' input.txt > output.txt
Veya boşlukla ayrılmış metinden belirli “sütunları” (alanları) çıkarmak:
perl -lane 'print "\$F[0]\t\$F[2]"' data.txt
Toplu yeniden adlandırma için Perl, temel bir yeniden adlandırma aracından biraz daha fazla kontrol sağlayabilir:
perl -e 'for (@ARGV){(my $n=$_)=~s/\s+/_/g; rename $_,$n}' *
(Bu son komut boşlukları alt çizgiyle değiştirir.)
One-liner’lar uygundur:
Gerçek bir betik yazın:
“Hızlı” izlenemez olmamalı. Kabuk geçmişinizi kaydedin (veya komutu bir not dosyasına yapıştırın), bir önce/sonra örneği ekleyin ve neyin neden değiştiğini kaydedin.
Aynı one-liner’ı iki kez çalıştırırsanız, onu bir dosya adı, yorumlar ve öngörülebilir giriş/çıkış yolu olan küçük bir betiğe sarmanın zamanı gelmiştir.
CPAN (Comprehensive Perl Archive Network), basitçe söylemek gerekirse Perl için paylaşılan bir modül rafıdır: herkesin indirebileceği ve kullanabileceği halka açık yeniden kullanılabilir modüller koleksiyonu.
Her özelliği sıfırdan yazmak yerine, küçük ekipler iyi test edilmiş bir modülü alıp gerçek problemelerine odaklanabilir—bugün çalışan bir betiği göndermek gibi.
Günlük web görevlerinin çoğu, CPAN sayesinde tek bir geliştiricinin erişebileceği hale geldi çünkü CPAN, aksi halde günler veya haftalar alacak yapı taşlarını sundu. Yaygın örnekler:
Bu önemliydi çünkü erken web otomasyonu genellikle “sistemde zaten meşgul bir yere eklenen bir betik” idi. CPAN o betiğin hızla—ve çoğu zaman daha güvenli—bir şekilde bir araya gelmesini sağladı.
Takas gerçek: bağımlılıklar bir tür bağlılıktır.
Modülleri çekmek hemen zaman kurtarır, ama aynı zamanda sürüm uyumluluğu, güvenlik düzeltmeleri ve bir modülün bakımının durması durumunda ne olacağı gibi konuları düşünmeniz gerektiği anlamına gelir. Bugünkü hızlı kazanım yarının kafa karışıklığına dönüşebilir.
Bir CPAN modülüne güvenmeden önce, bakımı açıkça yapılanları tercih edin:
CPAN düşünceli kullanıldığında, “koli bandı” zihniyetinin en iyi ifadelerinden biridir: işe yarayanı yeniden kullan, ilerlemeye devam et ve ihtiyaç duymadığın altyapıyı kurma.
CGI (Common Gateway Interface) web’in “sadece bir program çalıştır” aşamasıydı. Bir istek sunucuya geldi, sunucu Perl betiğinizi başlattı, betiğiniz girdileri (çoğunlukla ortam değişkenleri ve STDIN’den) okudu ve sonra genellikle bir HTTP başlığı ve bir HTML bloğu yazdı.
En basit haliyle, betik:
name=Sam&age=42)Content-Type: text/html) ve sonra HTML üretirBu model bir şeyi hızlıca göndermeyi kolay kıldı. Aynı zamanda bir şeyi hızlıca riskli şekilde göndermeyi de kolaylaştırdı.
Perl CGI pratik web otomasyonu için kestirme yol oldu:
Bunlar genellikle küçük ekip kazançlarıydı: bir betik, bir URL, anında değer.
CGI betikleri isteğe göre çalıştığı için küçük hatalar çoğalıyordu:
Hız bir özelliktir, ama sınırlarla birlikte. Hızlı betikler bile net doğrulama, dikkatli tırnaklama ve öngörülebilir çıktı kurallarına ihtiyaç duyar—bunlar küçük bir yönetim aracını mı yoksa modern bir uç noktayı mı yazıyor olursanız olun hâlâ işe yarar alışkanlıklardır.
Perl, zekice çözümleri kolaylaştırdığı için okunması zor bir şöhrete kavuştu. Yoğun noktalama içeren sözdizimi, bağlama bağımlı davranışlar ve “işin birden fazla yolu vardır” kültürü kısa, etkileyici kodu teşvik etti. Bu gece 2’de yapılan hızlı çözüm için harika—ama altı ay sonra orijinal yazar bile bir one-liner’ın ne yaptığını hatırlamakta zorlanabilir.
Sürdürülebilirlik problemi Perl’in benzersiz olarak okunamaz olması değil—Perl’in niyeti sıkıştırıp niyeti görünmez kılmasıdır. Yaygın suçlular arasında yorum olmayan sıkıştırılmış regex’ler, $_ gibi örtük değişkenlerin yoğun kullanımı ve satır tasarrufu sağlayan ama anlayışı zorlaştıran akıllı numaralar (yan etkiler, iç içe ternary’ler, sihirli varsayılanlar) vardır.
Bazı alışkanlıklar okunabilirliği ciddi şekilde artırır ve sizi yavaşlatmaz:
Perl topluluğu basit koruyucuları normalleştirdi: use strict; ve use warnings; etkinleştirmek, temel testler yazmak (birkaç sağlık kontrolü bile yeterli) ve varsayımları inline yorumlar veya POD ile belgelendirmek.
Bu uygulamalar kodu “kurumsal” yapmaz—onu hayatta kalabilir kılar.
Daha geniş ders her dil için geçerli: gelecekteki kendiniz ve ekip arkadaşlarınız için yazın. En hızlı betik, gereksinimler değiştiğinde güvenle değiştirilebilen olandır.
Metin işleri daha temiz olmadı—sadece yer değiştirdi. Artık CGI betiklerini sürdürmüyor olabilirsiniz, ama yine de CSV dışa aktarımları, SaaS webhook’ları, günlük dosyaları ve kalıcı hale gelen “geçici” entegrasyon akışlarıyla uğraşıyorsunuz. Perl’i kullanışlı kılan aynı pratik beceriler hâlâ zaman kazandırır (ve sessiz veri bozulmalarını önler).
Çoğu problem "zor ayrıştırma" değil, tutarsız girdidir:
1,234 vs 1.234, 03/04/05 gibi tarihler, farklı dillerde ay adları.Her girdiyi "güvenilmez" olarak ele alın, sistemden gelmiş olsa bile. Erken normalleştirin: bir kodlama seçin (genelde UTF-8), yeni satırları standartlaştırın, bariz gürültüyü kırpın ve tutarlı bir şemaya dönüştürün.
Sonra varsayımları açıkça doğrulayın: “bu dosya 7 sütunlu”, “ID’ler sayısal”, “zaman damgaları ISO-8601”. Bir şey bozulduğunda yüksek sesle hata verin ve gördüğünüzü kaydedin (örnek satır, satır numarası, kaynak dosya).
Mümkün olduğunda, açık formatları ve gerçek ayrıştırıcıları tercih edin. Size JSON verilmişse JSON ayrıştırın. CSV verilmişse tırnaklamayı anlayan bir CSV ayrıştırıcısı kullanın. Tahmin etmek, bir müşterinin adında virgül olduğunda işe yarar—ta ki sonuçlarınız bozulana kadar.
Bu beceriler günlük görevlerde işe yarar: bir olay sırasında uygulama günlüklerini filtrelemek, finans dışa aktarımlarını temizlemek, CRM içe aktarımlarını dönüştürmek, API entegrasyonlarını köprülemek ve “neredeyse doğru”nun kabul edilemez olduğu tek seferlik veri geçişleri yapmak.
Perl’in “koli bandı” itibarının anlamı özensizlik değil—kullanışlı olmaktı. Bu miras bir ekip küçük bir betikle dışa aktarımları karşılaştırması, günlükleri normalize etmesi veya yarı yapılandırılmış bir metin yığınını tabloya/DB’ye sindirilebilir hale getirmesi gerektiğinde ortaya çıkar.
Modern betik genellikle Python, Ruby veya JavaScript (Node.js) tarafını tercih eder. Bu dillerin rolleri örtüşür: hızlı otomasyon, diğer sistemlerle entegrasyon ve araçlar arasında tutkal kodu yazma.
Perl’in klasik güçlü yönleri (ve hâlâ öyle) işletim sistemine doğrudan erişim, ifade özgürlüğüyle metin manipülasyonu ve “işi hallet” kültürüdür. Python okunabilirliği ve geniş standart kütüphaneyi vurgular; Ruby geliştirici ergonomisine ve web‑odaklı konvansiyonlara eğimlidir; JavaScript yaygınlık ve Node’un çalışabildiği her yerde dağıtım kolaylığı sunar.
Bugünün işleri çerçeveler, kararlı API’lar, bulut hizmetleri ve daha iyi araçlarla şekillendi. Eskiden özel betik gerektiren birçok görev artık yönetilen hizmetler, barındırılan kuyruklar ve hazır konektörlerle halledilebiliyor.
Dağıtım da farklı: konteynerler, CI boru hatları ve bağımlılık sabitleme beklenen uygulamalar haline geldi.
Gerçek dünyadaki metin hâlâ dağınık. Günlükler sürprizler barındırır, dışa aktarımlar “yarı doğru”dır ve verinin güvenilir hale gelmesi için hâlâ dikkatli dönüşümler gerekir.
Perl’in öğrettiği kalıcı ders budur: otomasyonun parıltısız %80’i ayrıştırma, temizleme, doğrulama ve öngörülebilir çıktı üretmektir.
En iyi seçim genellikle ekibinizin sürdürebileceği araçtır: dile aşinalık, güçlü bir ekosistem ve gerçek dağıtım kısıtları (ne yüklü, güvenlik izinleri, operasyonel destek). Perl’in mirası “her zaman Perl kullan” değil—"elinizdeki dağınıklığa uyan aracı seç" demektir.
Ayrıca “koli bandı” içgüdüsünün modern AI‑yardımlı iş akışlarında da göründüğünü not etmek faydalı: örneğin, Koder.ai gibi bir vibe-coding platformu, hızlı bir dahili araç (bir günlük görüntüleyici, CSV normalizer veya küçük bir admin UI) gerektiğinde ve sohbet üzerinden yineleyerek iskeleti el ile kurmaktan daha hızlı iterasyon yapmak istiyorsanız işe yarayabilir. Aynı uyarı geçerlidir: hızlı gönderin, ama sonucu okunabilir, test edilebilir ve bugünün “geçici” düzeltmesi yarının kritik yolu olduğunda geri alınabilir bırakın.
Perl’in en büyük hediyesi belirli bir sözdizimi değil—dağınık metin problemlerine yönelik çalışır bir tavırdır. Bir şeyi otomatikleştirmeye başlamadan (bir yeniden adlandırma işi, günlük temizliği, veri içe aktarımı), bu “koli bandı” kontrol listesini kullanarak pragmatik kalın ama gelecekte sorun çıkaracak bir yük oluşturmaktan kaçının.
Küçük başlayın:
Şunları dahil edin: girdiler, çıktılar, birkaç önce/sonra örneği, varsayımlar (kodlama, ayırıcılar) ve bir geri alma planı (“yedekten geri yükle X” veya “önceki sürümle tekrar çalıştır”).
Perl hem web dönemi metin işinin tarihsel bir direği hem de devam eden bir öğretmendir: pratik olun, dikkatli olun ve başka bir insanın güvenebileceği bir betik bırakın.
Bu, pratikçi bir yaklaşımdır: özellikle dağınık girdiler ve eksik şartnamelerle karşılaştığınızda, gerçek acıyı hızlıca çözen en küçük etkili değişikliği kullanmaktır.
Bu, özensiz çalışmak için bir mazeret değildir. “Koli bandı” kısmı, işe yarayan bir sonuca ulaşmak ve sonra o düzeltmenin tuzak haline gelmemesi için yeterli güvenliği (testler, yedekler, notlar) eklemektir.
“Bir daha yaparsanız otomatikleştirin” kuralını kullanın: aynı elle yapılan temizliği iki kez yapıyorsanız, otomatikleştirin.
İyi adaylar şunlardır:
İş üretim verisini etkiliyorsa, yürütmeden önce koruyucu önlemler (kuru çalıştırma, yedekler, doğrulama) ekleyin.
One-liner’ları küçük betikler olarak değerlendirin:
Uzunlaşıyorsa, hata ayıklama gerekiyorsa veya tekrar kullanılacaksa, argümanları ve net giriş/çıkış yolları olan gerçek bir betiğe dönüştürün.
Regex, metin “neredeyse yapısal” olduğunda (günlükler, e-postalar, kimlikler, tutarsız ayırıcılar) doğrulama, çıkarma veya yeniden yazma için mükemmeldir.
Okunabilir tutmak için:
Hızlı bir düzeltme, başkalarının buna güvenmesi, tekrar kullanılması veya bir iş akışına (cron, boru hattı, dokümanlar) gömülmesi halinde “kalıcı” hale gelir.
Sertleştirme zamanının işaretleri:
Bu noktada: doğrulama, logging, testler ve varsayımları anlatan bir README ekleyin.
CPAN zaman kazandırır, ancak her bağımlılık bir taahhüttür.
Pratik seçim listesi:
Ayrıca dağıtımı planlayın: sürümleri sabitleyin, kurulum adımlarını belgelendirin ve güvenlik güncellemelerini takip edin.
CGI döneminden alınacak en büyük ders: sınırlar olmadan hız, zafiyet oluşturur.
Kullanıcı veya diğer sistemlerden girdi kabul ediyorsanız:
Bu alışkanlıklar modern betiklere, serverless fonksiyonlara ve web uç noktalarına da aynen uygulanır.
Yaygın sorunlar şunlardır:
Erken normalleştirin (kodlama, yeni satırlar), varsayımları doğrulayın (sütun sayısı, zorunlu alanlar) ve hatayı örnek satır/line numarası ile yüksek sesle raporlayın.
Kural olarak: eğer gerçek bir formatsa, gerçek bir parser kullanın.
Regex ve ad-hoc ayırma, desen çıkarma ve hafif temizleme için uygundur—ta ki bir kenar durumu (ör. bir isimde virgül) sonuçlarınızı sessizce bozuncaya kadar.
Ekip olarak çalıştırıp sürdürebileceğiniz aracı seçin:
Perl’in mirası: hep Perl kullanmak değil—elinizdeki dağınıklığa uygun aracı seçmek.