Haberde Sayılarla Çalışma İpuçları| Veriyle Başla, Hikayeyle Bitir
Veri Gazeteciliği el kitabından çevrilen bir bölümdür
Veriyle uğraşmada en iyi ipucu bundan hoşlanmanızdır. Veri korkutucu görünebilir. Ama onun sizi yıldırmasına izin verirseniz hiçbir yere varamazsınız. Veriyi onunla oynayacak ve keşfedilecek bir şey olarak görürseniz o da şaşırtıcı bir kolaylıkla sıklıkla size gizler ve hikayeler verecektir.
O halde diğer kanıtlarda olduğu gibi onu da korkusuz ya da iltimas geçmeden ele alın. Özellikle de bunu bir tasavvur etme pratiği olarak düşünün. Veriyle uyumlu ve onu daha iyi açıllayabilecek alternatif hikayeleri tasarlamada yaratıcı olun ve diğer kanıtlara karşı veriyi test edin. “Başka hangi hikaye bunu açıklayabilir?” diye sormak bu sayının, açıkçası büyük ya da kötü sayının bir sayı dizisi değil de nasıl şunun ya da bunun net kanıtı olabileceğini düşünmek için elverişli bir komuttur.
Veri hakkında şüpheciliği siniklikle karıştırmayın. Şüphecilik iyidir, siniklik ise veriyi elinden atar ve ayrılır. Eğer veri gazeteciliğine inanıyorsanız (ki muhtemelen inanıyorsunuz, yoksa bu kitabı okuyor olmazdınız), o halde verinin lanet karikatür yalanlarından ya da gözü dönen manşetlerin öldürücü olgularından çok daha iyi sunacağı şeyler olduğuna da inanmak zorundasınız. Eğer dikkatli kullanılırsa, veri bize derin bilgi sunar. Ne sinik ne de naif, ama hep uyanık olmamız gerekir.
Eğer ben size durgunluk dönemlerinde alkol tüketiminin arttığını söylersem, siz de bana bunun nedeni olarak herkesin depresyonda olmasını söyleyebilirsiniz. Eğer ben size alkol tüketiminin azaldığını söylersem siz de herkesin beş parasız olduğunu söyleyebilirsiniz.
Başka bir deyişle, verinin ne dediği, sizin kararlı bir biçimde yaptığınız yorumda hiç bir farklılık yaratmaz, yani bir şeyler öyle ya da böyle berbat haldedir. Eğer yüksekse kötüdür, düşükse de kötüdür. Buradaki mesele şu, eğer veriye inanıyorsanız o halde siz kendi modunuza, inançlarınıza ya da beklentilerinize göre çarptırmadan onun konuşmasına izin verin. O kadar çok veri var ki, biraz bakınsanız, sıklıkla sizin önceki inançlarınıza teyid bulabilirsiniz. Bir diğer deyişle, veri gazeteciliği, siz açık fikirli olmadıkça en azından benim için, çok değer katmaz . Sayılara dayandığı için değil ancak siz bu yönde mücadele verirseniz ancak nesnel olabilir.
Belirsizlik olabilir. Biz sayıları yetkiyle ve kesinlikle ilişkilendiririz. Sıklıkla ise cevap bir cevabın olmayışıdır, ya da aldığımız cevap alabildiğimiz en iyisidir ama tam doğruluğu tutturamamışızdır. Bence bunları konuşmalıyız. Bu size hikayeleri öldürmenin iyi bir yolu gibi gözüküyorsa, ben de aslında yeni sorular sormanın harika bir yolu olduğunu savunabilirim. Aynı şekilde, veriyi azaltmanın çoğunlukla birden fazla meşru yolu vardır. Sayılar ya doğru ya da yanlış olmak zorunda değildir.
Araştırma hikayedir. Bulmak için nasıl araştırdığınızın hikayesi iyi bir gazetecilik oluşturabilir, bir kanıt parçasından diğerine gittiğinizde ya da bir sayı çok az işe yaradığında veriden kanıt çıkarmaya çalıştığınızda. Farklı kaynaklar yeni açılar, fikirler ve daha zengin bir anlayış sağlar. Yetkin olmaya ve insanlara cevabı vermeye çok asılıp da nasıl iz sürdüğümüzü göstermeyince işin püf noktasını kaçırıp kaçırmadığımızı çok merak ediyorum.
En iyi sorular aslında eski sorular: Bu gerçekte büyük bir sayı mı? Nereden geldi? Senin neyi saydığını düşündüğünü saydığından emin misin? Bunlar genellikle veri hakkında düşünürken hatırlatıcı talimatlardır, tek bir sayıya bakarken sıkışan kenarlardaki şeylerdir, gerçek hayat karmaşıklıklarıdır, zaman, grup ya da coğrafik olarak diğer potansiyel karşılaştırmaların oluşturduğu geniş spektrumdur, kısacası bağlamdır.
=== Veriyle Başla, Hikayeyle Bitir
Okuyucularınızı uyandıracak ve dikkatlerini çekecek bir manşet figürüyle onları çekebilmek zorundasınız. Neredeyse bir veri setinden geldiğini bilmek zorunda kalmadan bir hikayeyi okuyabilmelisiniz. Heyecanlı kılın ve süreçte izleyicinizin kim olduğunu hatırlayın.
Buna ilişkin bir örnek AB Komisyonu Araştırmacı Gazetecilik Bürosu tarafından sürdürülen bir projede http://bit.ly/ec-fts[Financial Transparency System]. bulunabilir. Burada hikaye veri setine özgül sorularla yaklaşılmasıyla inşa edildi.
Biz de veriye “kokteyl”, “golf” ve “uzaktaki günler” gibi anahtar terimlerle baktık. Bu bizim Komisyonun bu kalemlerle ilgili ne harcamış olduğunu belirlememize olanak tanıdı ve izlenecek pek çok soru ve haber dizisi yarattı.
Ancak anahtar terimler her zaman istediğinizi vermez. Bazen arkanıza yaslanmak ve gerçekten neyi istediğiniz hakında düşünmek zorundasınız. Bu proje boyunca biz aynı zamanda komisyon üyelerinin özel jet seyahatlerine ne kadar para harcadıklarını bulmak istedik. Ama veri dizisi “özel jet” ifadesini içermediğinden diğer araçlarla seyahat sağlayıcılarının adını almak zorunda kaldık. Bir kere Komisyonun hizmet sağlayıcısının adını öğrendikten sonra, “Abelag” idi, Abelag tarafından sağlanan hizmetlere ne kadar harcandığını bulmak için veriye soru sorabilir hale geldik.
Bu yaklaşımla veriye soru sormada açıkça tanımlanmış bir amacımız vardı. Bu da bir manşet oluşturabilecek bir sayı bulmaktı.
Diğer yaklaşım ise bir kara listeyle başlamak ve burada dışarıda kalanları aramaktır. Veriden hikaye dizisi yaratmanın kolay bir yolu da orada neyi bulmamanız gerektiğini bilmektir. Bunun nasıl çalışabileceğine iyi bir örnek AB Yapısal Fonlar projesi kapsamında Financial Times ve Araştırmacı Gazetecilik Bürosu işbirliğiyle gerçekleştirilen projede gösterilir.
Biz de Komisyonun yapısal fonları almada hangi tür şirket ve kuruluşların yasaklandığına dair kurallarına dayanarak veriye sorular sorduk. Bir örnek tütün ve tütün üreticileriyle ilgili harcamalardı.
Veriye tütün şirketleri, üreticileri ve yetiştiricilerinin adlarıyla ilgili sorular sorduğumuzda British American Tobacco’nın Almanya’daki bir fabrika için 1.5 milyon euro aldığını ortaya koyan veriyi bulduk.
Bu fonlama Komisyonun harcamalara ilişkin kurallarının dışında olduğundan, bu, veriden hikaye bulmanın hızlı bir yoluydu.
Bir veri setinde neyi bulabileceğinizi hiçbir zaman bilemezsiniz. O halde sadece bakın. Oldukça cesur olmalısınız. Bu yaklaşım genellikle de filtreleme aracılığıyla gözükecek (en büyük, en aşırı, en yaygın gibi) belirgin özellikleri saptamaya çalışırken işe yarar.
=== Veri Gazetecileri Seçtikleri Araçları Tartışıyor ===
Psssss. Bu ses hava geçirmez kabından sızan verinizin sesi. Şimdi ne olacak? Neyi arıyorsunuz? Hangi araçları kullanıyorsunuz? Veriyle nasıl çalıştıkları hakkında bize birşeyler söylemeleri için veri gazetecilerine sorduk. İşte söyledikleri:
____
Guardian Datablogu’nda gerçekten okuyucularımızla etkileşim kurmayı çok seviyoruz. Onların hızlıca veri gazeteciliğimizin aynını yapmasına izin vermemiz bizim çalışmamızın üstüne inşa edebilmeleri ve bazen de bizim yapmadığımız noktaları belirlemeleri anlamına geliyor. Veri araçları ne kadar sezgiselse o kadar iyidir. Biz herhangi birisinin bir programlama dili öğrenmeksizin ya da özel bir eğitim almaksızın ve ağır bir ücret ödemeksizin kullanacağı araçlar seçmeye çalışıyoruz.
Bu nedenle şu anda ağırlıkla Google ürünlerini kullanıyoruz. Bizim toparladığımız ve yaydığımız tüm veri setleri Google Spreadsheet olarak mevcut, Google hesabı olan insanlar veriyi yükleyebilir, kendi hesaplarına aktarabilir ve kendi grafiklerini yapıp veriyi düzenleyip pivot tabloları yaratabilir ya da istedikleri bir araca veriyi aktarabilir.
Veriyi haritalandırmak için Google Fusion tabloları kullanıyoruz. Fusion’da sıcaklık haritaları yarattığımızda KML biçimli dosyalarımızı paylaşıyoruz ve böylece okuyucular yükleyebilir ve kendi haritalarını yaratabilir, belki de Datablog’un orjinal hariatsına yeni veri tabakaları da ekleyebilirler. Bu Google araçlarının bir dğer hoş özelliği de okuyucularımızın bloga erişmek için kullandıkları bilgisayar, cep telefonu ve tablet gibi pek çok platformda çalışıyor olmaları.
Google Spreadsheets ve Fusion’a ek olarak günlük çalışmamızda iki araç daha kullanıyoruz. Birincisi çok boyutlu veri setlerini görselleştirmek için Tableau; ikincisi ise verinin hızlı analizi için ManyEyes. Bu araçların hiçbiri kusursuz değil, o nedenle okuyucularımızın hoşlanacağı daha iyi görselleştirme araçları aramaya devam ediyoruz.
____
Hiç kodlayıcı olabilecek miyim? Çok az ihtimalle! Ben şahsen tüm gazetecilerin kodlamayı bilmeleri gerektiğini kesinlikle düşünmüyorum. Ama neyin mümkün olduğuna ve kodlayıcılarla nasıl konuşacaklarını bilmeye ilişkin daha genel bir farkındalığa sahip olmalarının onlar için oldukça değerli olduğunu düşünüyorum.
Eğer başlıyorsanız koşmayın, yürüyün. İş arkadaşlarınızı ve editörlerinizi veriyle çalışmanın başka türlü elde edemeyeceğiniz hikayeleri elde etmenizi sağlayacağına ve bunun da denemeye değer bir iş olduğuna ikna etmeniz gerek. Bir kere bu yaklaşımın değerini görünce onları daha karmaşık hikayelere ve projelere doğru açabilirsiniz.
Benim önerim Excel’i öğrenmek ve öncelikle basit hikayeler yapmak. Küçük ölçekli başlayın ve veri tabanı analizi ve haritalamaya kadar çıkın. Excel ile çok fazla şey yapabilirsiniz. Excel gerçekten çok güçlü bir araç ve çoğu insan işlevselliğinin bir parçasını bile kullanmıyor. Eğer yapabilirseniz Centre for Investigative Journalism tarafından verilen gibi gazeteciler için bir Excel dersine gidin.
Veriyi yorumlamakla ilgili olarak ise bunu çok hafife almayın. Vicdanlı olmalısınız. Ayrıntıya dikkat edin ve sonuçlarınızı sorgulayın. Veriyi nasıl işlediğinize ilişkin notlar alın ve orjinal verinin bir kopyasını tutun. Hata yapmak çok kolay. Ben her zaman analizi en baştan pratik olarak iki ya da üç kez daha yaparım. Bunun daha da iyisi editörünüze ya da bir başkasına ayrıca veriyi analiz ettirmek ve sonuçları karşılaştırmaktır.
____
Bir muhabirin bir haberi yazması kadar çabukça karmaşık bir yazılımı yazmak ve kullanmak becerisi oldukça yeni bir şey. Çok daha fazla zaman alıyordu eskiden. İki ücretsiz a.ık hızlı gelişim çerçevesinin gelişmesi sayesinde bir şeyler değişti: Bunlardan Django ve Ruby on Rails ilk kez 2000’lerin ortalarında çıkarılanlardandı.
Python programlama dili üzerinden yaratılan Django, Kansas Lawrence’da the Lawrence Journal-World haber odasında çalışan Adrian Holovaty ve ekibi tarafından geliştirildi. Ruby on Rails ise Şikago’da David Heinemeier Hansson ve bir web uygulama şirketi olan 37Signals tarafından geliştirildi.
`İki çerçeve de `MVC örüntüsü”ne farklı yaklaşsalar da, ikisi de mükemmeldir ve çok hızlı bir biçimde daha karmaşık web uygulamaları yapmayı olanaklı kılarlar. Bir uygulama geliştirmek için gereken temel çalışmanın bazısını ortadan kaldırırlar. Veri tabanından kalemler yaratma ve çekme ve URL’leri uygulamadaki özgül kodla eşleştirme bu çerçevelerde yapılır ve böylece geliştiricilerin böyle basit şeyler için kod yazmasına gerek kalmaz.
ABD’de haber uygulamaları ekiplerine dair bir formel araştırma bulunmasa da çoğu ekibin genel olarak veri tabanı destekli haber uygulamaları için bu iki çerçeveden birisini kullandığı anlaşılmaktadır. ProPublica’da biz Ruby on Rails’i kullanıyoruz.
Amazon Web Hizmetleri gibi “hisse” sağlayıcı hızlı web sunucularının gelişmesi, web uygulama dağıtımının bir zamanlar olduğu gibi yavaş bir süreç olmasını ortadan kaldırdı.
Bunun dışında veriyle çalışırken oldukça standart araçlar kulanıyoruz. Veriyi temizlemek için Google Refine ve Microsoft Excel; istatistik için SPSS ve R; Gıs için ArcGIS ve QGIS; kaynak kod yönetimi için Git; kod yazımı için TextMate, Vim ve Sublime Text ve veri tabanları için MySQL, PostgreSQL ve SQL Server karışımını kullanıyoruz. JavaScript’de ön-uç ağır uygulamaları çok hızlı geliştirmemize yardımcı olmak üzere `Glass” adlı kendi JavaScript çerçevemizi geliştirdik.
____
Bazen en iyi araç en basit araç olabilir-Bir spreadsheetin gücünü hafife almak .ok kolaydır. Herşey DOS’da iken geri dönüp spreadsheeti kullanmak benim The Texas Rangers’ın sahipleri için geliştirilen karmaşık ortaklık sözleşmesi formülünü anlamamı sağladı-o zaman George W. Bush anahtar sahiplerden birisiydi. Bir spreadsheet hesapta aykırı olanları ya da hataları çok kolay göstermeye yardımcı olur. Düzgün senaryolar ve daha da fazlasını yazabilirim. Bir veri gazetecisi için araç kutusunun temelidir.
Bunu söylesem de benim favori araçlarım daha da güçlü-Istatistiksel analiz için SPSS ve haritalama programları coğrafik olarak örüntüleri görmeme olanak tanır.
____
Ben Python’ın büyük hayranıyım. Python okuması ve yazması kolay olan harika bir açık kaynak programlama dili (örneğin, her satırdan sonra virgül koymak zorunda değilsiniz). Daha da önemlisi, Python.harika bir kullanıcı tabanına sahip ve böylece gerçekten ihtiyacınız olan her şey için paketler olarak adlandırılan plug-inlere sahip.
Ben Django’yu veri gazetecileri tarafından nadiren ihtiyaç duyulacak birşey olarak değerlendirirdim. Bir Python web uygulama çerçevesi-yani büyük, veri tabanı güdümlü web uygulamaları yaratmak için bir araç. Küçük, etkileşimsel, enformasyon içeren grafikler için kesinlikle çok ağır.
Ben bir de QGis’i kullanıyorum; arada coğrafik veriyle uğraşan veri gazetecilerinin ihtiyacı olduğu GIS işlevselliğine dair geniş bir yelpaze sunan bir açık kaynak araç seti.Eğer coğrafik uzamsal veriyi bir formattan diğerine dönüştürmeniz gerekiyorsa, o zaman ihtiyacınız olan şey QGis. Neredeyse var olan her coğrafik veriyi halledebilir (Shapefiles, KML, GeoJSON, vc.). Eğer birkaç bölgeyi kesmeniz gerekiyorsa, QGis bunu da yapabilir. Ayrıca QGis’in büyük bir topluluğu var, o nedenle webde bunun gibi http://bit.ly/goettingen-tutorial[tutorials] tonlarca kaynak bulabilirsiniz.
R, esasında bir bilimsel görselleştirme aracı olarak yaratıldı. R’de zaten yapılmamış bir görselleştirme yöntemi ya da veri tartışma tekniği bulmak zor. R kendi içinde bir evren, görsel veri analizinin mekkesi. Bir kusuru ise R’in zaten kendi dili olduğu için (bir tane daha) programlama dili öğrenmenizin gerekmesi. Ama bir kere öğrenme eğrisine bir başlangıç tırmanışı yaptığınızda, R’den daha güçlü bir araç yok. Eğitimli veri gazetecileri Excel’in sınırlarını aşan çok büyük veri setlerini analiz ederken R’ı kullanabilir (örneğin bir milyon satırlık tablonuz varsa).
R’le ilgili gerçekten hoş bir şey şu ki tüm süreç boyunca veriyle ne yaptığınıza ilişkin tam bir “protokol” tutabiliyorsunuz; Bir CVS dosyasını okumaktan bir grafik yaratmaya kadar. Eğer veri değişirse bir klikle grafiği yeniden yaratabilirsiniz. Eğer birisi sizin grafiğinizin bütünlüğünü merak ediyorsa ona tam kaynağı gösterebilirsiniz ki bu da herkese kendi grafiğini yeniden yaratma olanağını da verir (ya da yaptığınız hataları bulma).
NumPy + MatPlotLib ise Python ile bir çeşit aynı şeyi yapar. Eğer Python’da iyi eğitim aldıysanız bir seçenektir. Aslında NumPy ve MatPlotLib, Python paketlerinin iki örneğidir. Veri analizi ve veri görselleştirmesinde kullanılabilirler ve ikisi de istatistiki görselleştirmeyle sınırlıdır. Bunlar tooltipler ve daha ileri şeyler içeren etkileşimsel grafikler yaratmada kullanılamazlar.
Ben MapBox’ı kullanmıyorum ama OpenStreetMap temelli daha karmaşık haritalar istiyorsanız harika bir araç olduğunu duydum. Örneğin sizin harita stillerini isteğinize göre biçimlendirmenize olanak tanır (renk, etiket gibi). Bir de Leaflet olarak adlandırılan MapBox’a eş bir başka şey var. Leaflet temel olarak JavaScript kütüphanesinin daha yüksek düzeyi ve harita sağlayıcıları arasında kolayca geçiş yapmanıza olanak tanıyan bir haritalama (OSM, MapBox, Google Maps, Bing, vb.).
RaphaelJS daire, çizgi ve metin gibi çok temellerle çalışmanıza ve onları canlandırmanıza ve etkileşimler eklemenize vb. izin veren oldukça düşük düzeyli görselleştirme kütüphanesidir. Hazır kullanımda grafikler gibi şeyler yoktur, o nedenle bir dikdörtgenler dizisini kendiniz çizmek zorundasınız.
Bununla birlikte Raphael’le ilgili iyi bir şey yarattığınız herşeyin aynı zamanda Internet Explorer’da çalışacak olmasıdır. Bu d3 gibi pek çok diğer (büyüleyici) görselleştirme kütüphanesi için geçerli değildir. Maalesef, pek çok kullanıcı hala IE kullanıyor ve hiçbir haber odası kullanıcılarının % 30’unu görmezden gelmezlik edemez.
RaphaelJS’in yanısıra, bir de IE için Flash fallback yaratma seçeneği var. Bu temel olarak The New York Times’ın yaptığı şey. Bu da demektir ki her uygulamayı iki kez geliştirmek zorundasınız.
IE ve modern tarayıcılar için “en iyi” görselleştirme taşıma sürecinin ne olduğu hakkında hala ikna olmuş değilim. Sıklıkla RaphaelJS uygulamalarını IE’de korkunç yavaş işlerken buldum, burada modern tarayıcılar kullanan Flash’dakinden on kez daha yavaş işlerler. O halde, eğer tüm kullanıcılar için yüksek nitelikli animasyonlu görselleştirmeler sağlamak istiyorsanız Flash fallbacks daha iyi bir seçenek olabilir.
____
Benim harekete geçirici aracım Excel ki CAR problemlerinin çoğunun üstesinden gelebiliyor ve pek çok muhabir için öğrenmesi kolay ve erişilebilir olma avantajlarına sahip. Tabloları birleştirme ihtiyacım olduğunda, tipik olarak Access kullanıırm, ana daha ileri çalışma için birleşen tabloları tekrar Excel’e yüklerim. Coğrafik analizler için ESRI’s ArcMap kullanırım; çok güçlü ve coğrafik olarak kodlanmış veriyi toplayanlar tarafından kullanılıyor. TextWrangler ise acaip düzendeki metin verisini analiz ederken harikadır ve düzenli ifadelerle karmaşık arama ve yeniden yerleştirmeleri yapabilir. Lineer regresyon gibi istatistiki tekniklere ihtiyaç duyulduğunda, SPSS kullanırım; çok kullanışlı doğrult ve tıkla menüsü vardır. Ciddi filtreleme gerektiren milyonlarca kayda sahip ve değişken dönüşümlerini programlayan veri setleriyle çalışmak gibi çok daha ağır işler için ise SAS yazılımı kullanırım.
____
Bizim seçtiğimiz araçlar veriyi ele geçirme, parçalama ve oynamada Python and Django ve çılgın web haritaları yaratmada PostGIS, QGIS, ve the MapBox’dır. Yakın zamanlardaki favori veri aracımız yerel olarak üretilen CSVKit ise de şimdilik araştırıcı veri analizi ara. seçimimizde üstünlüğü ele geçiren R ve NumPy + MatPlotLib’dir. Yaptığımız her şey az ya da çok cloud’da kullanılır.
____
La Nacion’da bizim kullandığımız:
* Veriyi temizleme, organize etme ve analiz etmede Excel;
* Google Fusion tabloları ve the Junar Open Data Platformu gibi yayınlama ve bağlantılandırma hizmetleri için Google Spreadsheetleri;
* Verimizi paylaşma ve makale ve blog yazılarımıza yerleştirme için Junar;
* Etkileşimli veri görselleştirmelerimiz için Tableau Public;
* Geniş veri setlerini analiz etme ve filtreleme için çok hızlı bir ticari zeka aracı olarak Qlikview;
* PDF’leri metin ve Excel dosyalarına dönüştürme için NitroPDF; ve
* Harita görselleştirmeleri için Google Fusion Tabloları.
____
Teknik olarak hiçbir önyargısı olmayan radikal bir topluluk olarak biz Transparency Hackers’da pek çok farklı araçlar ve programlama dilleri kullanırız. Her bir üyenin kendi tercihler dizisi vardır ve bu büyük çeşitlilik bizim hem gücümüz ve hem de zayıflığımızdır. Aslında bazılarımız herhangi bir yerde liveboot yapabileceğimiz ve veriyi hacklemeye başlayacağımız “Transparency Hacker Linux Distribution,”ı kuruyorlar. Bu araç seti veriyle uğraşmada Refine, RStudio ve OpenOffice Calc gibi ilginç araçlar ve kütüphanelere sahip (bu genellikle bu konudaki çok bilgililerce görmezden gelinen ama hızlı ve küçük şeyler için gerçekten çok yararlı bir araçtır). Ayrıca veri sonuçlarını online olarak hızlıca prototipleştirme ve kaydetmede Scraperwiki’yi de çok kullanırız.
Veri görselleştirme ve grafikler için sevdiğimiz çok sayıda araç var. Python ve NumPy oldukça güçlü araçlar. Toplulukta çok az kişi R ile oynuyordu ama neticede hala d3, Flot, ve RaphaelJS gibi Javascript örüntüleme grafik liblerinin projelerimizdeki çoğunluk tarafından kullanıldığını düşünüyorum. Son olarak, haritalamayla ilgili epeyce deney yapıyorduk ve Tilemill gerçekten çalışması çok ilginç bir araç oldu.
____