Yalnızca SQLite ile dayanıklı iş akışları kurulabilir

 (obeli.sk)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Dayanıklı yürütmenin özü altyapının kendisi değil, iş akışı durumunun korunmasıdır; ilerleme durumu kaydedildiğinde yeniden çalıştırma ve kurtarma mümkün olur
  • Obelisk, iş akışı ilerlemesini çalıştırma günlüğüne kaydeder ve kalıcı geçmişten yeniden oynatır; etkinlik yeniden denemelerine uygun bir yapıya sahiptir
  • SQLite, ayrı bir veritabanı servisi, ağ atlamaları veya ek kontrol düzlemi olmadan yerel bir dosya üzerinden işlem tabanlı dayanıklı durum sağlar
  • Litestream, SQLite değişikliklerini S3 uyumlu nesne depolamaya eşzamansız olarak akıtır; ancak kopyalama yapılmadan önce birim kaybolursa en son yazmalar kaybedilebilir
  • Obelisk, Postgres de destekler; daha yüksek erişilebilirlik, paylaşımlı ölçeklenebilirlik ve ağ veritabanı özellikleri gerektiğinde daha uygundur

SQLite ve Litestream işletim modeli

  • Litestream, SQLite değişikliklerini S3 uyumlu nesne depolamaya eşzamansız olarak akıtabilir
  • Veritabanını çalışma ortamına yakın tutarken, yedekleme, taşıma ve inceleme için veritabanını dışarı kopyalamayı da mümkün kılar
  • Eşzamansız çoğaltma özelliği nedeniyle, SQLite birimi kopyalama öncesinde kaybolursa geri yükleme sırasında en son yerel yazmalar kaybedilebilir
  • Yapı, Obelisk sunucusunun SQLite veritabanıyla birlikte çalıştırılması, Litestream ile yedeklenmesi ve gerektiğinde gözlemcinin ihtiyaç duyduğu veritabanını çekmesi şeklindedir
  • Aynı SQLite dosyası yerel yeniden oynatma, hata ayıklama ve ajanın gerçekte yaptığı işleri anlamak için kullanılabilir

Uygun kullanım alanı ve Postgres seçme ölçütleri

  • Yapay zeka ajanları ve yapay zeka tarafından üretilen iş akışları çoğu zaman ani yük artışları gösterir ve deneyseldir; bu yüzden ajan veya kiracı başına küçük, kendine ait durum birimlerine sahip bir yapılandırmayı anlamak daha kolaydır
  • Mikro VM'ler veya container'lar içindeki birçok küçük sunucunun her birinin kendi SQLite veritabanına ve nesne depolama yedeğine sahip olması, tek bir büyük ve sürekli çalışan paylaşımlı sistemden daha basit, daha ucuz olabilir ve daha iyi arıza yalıtımı sağlayabilir
  • Nesne depolamaya eşzamansız çoğaltma istenen dayanıklılık modeli değilse ya da daha yüksek erişilebilirlik, daha geniş paylaşımlı ölçeklenebilirlik ve ağ veritabanı özellikleri gerekiyorsa Postgres daha uygundur
  • Birçok iş akışı sistemi ilk günden bu düzeyde bir altyapıya ihtiyaç duymaz; durum gereksinimlerinden daha büyük bir altyapıyla başlamaya gerek yoktur
  • Yerel bir SQLite veritabanı, Litestream ile S3 yedeklemesi ve düşük maliyetli worker kombinasyonu bile az altyapıyla dayanıklı bir sistem kurmak için yeterli olabilir; bu, yapay zeka ajanı alanında makul bir varsayılan olabilir

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News yorumları

  • İş akışlarını Temporal ile kurmaya başladım; yerel bir uygulama olarak oldukça hafif dağıtılıyor ve izole yerel kurulumlarda SQLite kullanıyor
    API yeniden denemelerini ele almak, iş akışlarını ve görevleri temizlemek gerçekten çok basitleşiyor; bu yüzden denemenizi tavsiye ederim. Felsefi olarak bu yazının önerdiği şeyle tam olarak aynı yönde, ama ajanların kullanması için çok zengin ve esnek bir arayüz de ekliyor. Web UI üzerinden iş akışlarını incelemek ve ajan çalıştırmalarını gözden geçirmek de kolay
    Temporal, sisteme neredeyse bedavaya çok daha yüksek güvenilirlik katıyor. Dağıtık ve güvenilir sistemler zor olduğu için tekerleği yeniden icat etmemek daha iyi bence
    SQLite veritabanını kolayca incelemek, iş akışında neler olduğunu anlamak, tek tek görevleri birleştirmek ve iş akışlarını basitçe çağrılabilir hale getirmek istiyorsanız Temporal'a bakmaya değer
    Bununla birlikte, ajanlar için dosya kullanımını neredeyse bıraktım. Markdown ve JSON güzel ama küçük yerel uygulamalar yaparken bir tuzak gibi hissettiriyor. LLM'ler SQLite ile iyi çalışıyor ve oradan Markdown, JSON ya da istenen başka bir biçime render edebilirsiniz. Ajan jq çalıştırmak veya Markdown üzerinde grep yapmak yerine yalnızca belirli satırları sorgulayabilirse çok fazla token da tasarruf ediliyor. Birden fazla dosya yerine veri yapısını daha disiplinli hale getiren, taşınabilir ve kendi içinde yeterli bir veri yönetim sistemi elde ediyorsunuz. Küçük yerel projeler büyür ya da daha resmî hale gelirse MySQL/Postgres'e de geçilebilir ve o noktada zaten şema ile veri disiplini oturmuş olur

    • Daha çok tek makinede çalıştırıyormuşsunuz gibi geliyor
      Temporal ölçek büyüdükçe çok daha karmaşık hale geliyor. Cassandra işletmek keyifli değil ve Ringpop ile TChannel da bir sorun çıktığında debug etmesi zor şeyler. SQL backend desteği ise tutarlılık gereksinimleri nedeniyle yatay ölçekli replikaları desteklemiyor; yalnızca tek bir instance mümkün
      Kodu nasıl yazdığınıza bağlı olarak, iş akışına gömülü kodu değiştirmek de karmaşıklaşıyor. Geçmiş event sırasını değiştiren değişiklikler, zaten dağıtılmış worker'ların determinizmini bozuyor
      Biz Temporal'ı çok kullanıyoruz; basit scripting ya da otomasyonla başlayan herkes seviyor, ama bunun üstüne gerçek üretim sistemleri kuran herkes nefret ediyor. Belki operasyonel olgunluk eksikliğidir ama bu yorumlarda görülen pembe tablo benim deneyimimle uyuşmadı
    • HN'de duyduğum kadarıyla ya Temporal'ın yönetilen çözümüne beklenenden fazla para ödüyorsunuz ya da sonunda çok ağır bir sistemi kendiniz işletip kayda değer bir operasyon yükü üstleniyorsunuz
      Bunu bizzat yapmadım ama gerçek deneyimleri daha çok duymak isterim
    • jq ya da grep ile Markdown işlemek yerine SQLite kullanmaya dair somut bir örnek verebilir misin?
    • Temporal reklamı gibi okunuyor :)
    • Dosya ve veritabanı yaklaşımı tartışması ilginç. Ben de gidip geldikten sonra sonunda veritabanında karar kıldım

  • Gerçek üretim uygulamalarında SQLite kullanma takıntısını anlamıyorum. SQLite gömülü bir veritabanı; eşzamanlılık yönetimi için hiç uygun değil
    Zaten bu işler için Postgres, MySQL gibi veritabanı sunucuları var. Bunların tüm varlık nedeni, birden fazla sürecin farklı makinelerde aynı anda veriyi değiştirebilmesini sağlamaktır
    Bu bilgisayar biliminin temel ilkelerinden biri; “her şeye SQLite” diye bağıran taraf biraz deneyimsiz görünüyor

    • Ne tür eşzamanlılık olduğu ve bu gereksinimlerin nasıl karşılanması gerektiği konusunda anlayış epey sınırlı gibi görünüyor. Bunun sunucu olup olmaması bu tartışmada pek önemli değil
      SQLite birçok gerçek iş yükünde mükemmel bir üretim veritabanıdır ve bu durum geniş biçimde belgelenmiştir. Postgres’ten çok farklıdır; dolayısıyla tamamen farklı bir teknoloji öğrenmek gerekir
      Bir bakış açısına göre, sistem içinde doğal olarak güçlü biçimde bölümlenen kısımlarda SQLite çok uygun olabilir
    • SQLite ile bir eşzamanlılık frontend’i, örneğin Go’nun net/http sunucusu birleşimiyle bile bazı servislerin hayal edilebilecek tüm yükünü karşılamak çoğu zaman mümkündür. Zamanla donanımı büyütebiliyorsanız bu daha da geçerlidir ve SQLite yüz binlerce TPS’ye kadar kolayca ölçeklenebilir
      Aslında vazgeçtiğiniz şey yüksek erişilebilirlik/failover ve felaket kurtarma tarafıdır; bunun da çözümleri var. Tek sunuculu sistemler genelde şaşırtıcı derecede sağlamdır. Çünkü karmaşık bir kontrol düzlemi olmadığında sistem büyüdükçe çalışma süresinin düşmesi sık görülen bir durumdur
    • SQLite birçok kullanım için iyidir ama siz muhtemelen zamanınızın çoğunu ağ veritabanı ve sharding gerektiren büyük ölçekli web uygulamaları üzerinde harcıyorsunuz. O alan da ilginç ama başka alanlar da var
      Teknolojik değişimler ışığında mevcut “en iyi uygulamaları” yeniden değerlendirmeyi seviyorum. Özellikle de daha fazla sadelik sağlıyorsa. Aile için olan bir sosyal medya sitesini tek bir VPS üzerindeki SQLite DB ile çalıştırmak harika. Yaklaşık 15 kullanıcı var ve neredeyse hiç bakım gerekmiyor. FreshRSS instance’ımı ve “now” sayfamı da SQLite ile çalıştırıyorum
      İş yerinde de son birkaç on yıldır SQLite’ı her türlü amaçla kullandım. Geçici iş kuyrukları, yerelde çok sayıda logu hızlıca yükleyip sorgulama ve simonw’nin harika https://github.com/simonw/datasette aracıyla bunları gerçek zamanlı gösterip filtreleme için kullandım
      Bence mesele “her şeye SQLite” değil, daha çok “düşündüğünüzden çok daha fazla yerde SQLite”
      kentonv/Cloudflare’ın edge SQLite çalışmaları bu fikri biraz daha popülerleştirmiş olabilir ama bu zaten önceden var olan bir akımdı. https://blog.cloudflare.com/sqlite-in-durable-objects/
      Böyle küçük ama faydalı kullanım örneklerini bilmek ve değerlendirmek istemek deneyimsizlik değil, aksine deneyim göstergesi olabilir
    • O yüzden mi milyarlarca SQLite veritabanı var?
      SQLite’ın, diğer tüm veritabanı motorlarının toplamından daha fazla kullanılıyor olması çok muhtemel. Vahşi doğada milyarlarca SQLite kopyası bulunuyor. Android cihazlarda, iPhone ve iOS cihazlarında, Mac’lerde, Windows 10/11 kurulumlarında, Firefox/Chrome/Safari’de, Skype’ta, iTunes’da, Dropbox istemcisinde, TurboTax ve QuickBooks’ta, PHP ve Python’da, çoğu TV ve set-top box’ta, çoğu araç multimedya sisteminde ve sayısız uygulamada yer alıyor
      https://sqlite.org/mostdeployed.html
    • Veri doğal olarak shard ediliyorsa ve yazmalar tek bir shard içinde gerçekleşiyorsa paralellik kolaylaşır. İstekler, kullanıcının verisinin bulunduğu shard’a yönlendirilir ve okuma/yazma işlemleri yerelde yapılır
      Bu yaklaşım ölçeklenebilirliği anlamayı çok daha kolaylaştırır. Kesip kopyalarsınız, sonra bir kez daha yaparsınız. Her N kullanıcı için bir shard daha eklersiniz
      Bunun karşılığında shard’lar arası sorgular, örneğin analitik, ayrıca kullanıcılar ayrıldığında ya da sistem eskidikçe yükü nasıl dengeleyeceğiniz gibi başka sorunlar ortaya çıkar
      Ama çok büyük kullanıcı sayılarında ekleme/güncelleme nedeniyle oluşan paylaşımlı indeks ölçekleme problemlerinin tamamından kaçınabilirsiniz
      Artık ilişkisel veritabanından çok hiyerarşik bir veritabanına dönüşür

  • Şunların tamamını Go + SQLite ile değiştirdim: Intercom, Zendesk, e-posta pazarlaması, Kanban, Todo, ödeme yığını, issue tracker, forum, uptime monitörü, PagerDuty klonu
    Sattığım ürün sayısı onlarcayı bulunca, hepsini neden kendim yapmayayım diye düşündüm
    Hepsi aynı sunucuda çalışıyor ve çok az bellek kullanıyor. Kullandığım tüm SaaS araçlarını bunlarla değiştirdim
    Dedicated sunucuya geçince, yönetilen bulut çözümlerine ödediğim maliyet yaklaşık 1/10’a düştü; aynı yüksek erişilebilirliği korurken gecikme de azaldı. Bunun sebeplerinden biri de VPS’lerdeki noisy neighbor sorununun tail latency’yi artırmasıydı
    Eskiden bunlara ciddi para harcıyordum ama şimdi 4 aydır prod’da çalışıyorlar ve yalnızca ufak güncellemeler gerekti
    Dağıtım gerçekten çok basit. Docker da yok Kubernetes de; sadece systemd servisleri ve geliştirme makinesinde derlenip dağıtılan binary’ler var
    MaxMind veya IPData gibi servislere de para ödüyordum ama kendi IP coğrafi konum servisimi yaptım ve testlerde mevcut çözümlerin çoğundan daha iyi performans verdi
    Başlangıç noktası Uptime Robot yerine geçecek bir şey yapmaktı, sonra özgüven geldi ve PagerDuty’nin yerine geçeni yaptım. Ardından Intercom’un yerine geçeni yaptım
    Son olarak, hep “ödeme stack’ini kendin yazma” sözünü duydum ama YOLO deyip o hatayı bizzat yapmaya karar verdim. Mevcut ödeme çözümlerini inceledim, kendim geliştirip deploy ettim ve şu ana kadar hiç sorun yaşamadım
    Ön tarafta Caddy kullanıyorum
    Çoğu SaaS ürününün sunduğu özelliklerin gerçekte yalnızca %1–5’ini kullandığımı, asıl ihtiyaç duyduğum özelliklerin ise bu “enterprise-grade” platformların içinde giderek daha derine gömülüp iş akışını zorlaştırdığını fark ettim
    Ticari ürünleri göstermeyeceğim; ortaklarım ve müşterilerim ne kadar ucuza mal ettiğimi görmeyi muhtemelen sevmez. Ama ben buna beceriklilik diyorum
    Ücretsiz uygulamayı gösterebilirim. Kısa süre önce yayınlandı ve 20 binden fazla kullanıcısı var: https://macrocodex.app/
    Bu uygulama yalnızca Zendesk klonunu kullanıyor. E-posta ise Cloudflare routing ile işleniyor, bu yüzden işletme maliyeti neredeyse yok

    • Uptime monitörünü kendin yaptıysan, bölgesel dağıtımı veya konut tipi bağlantı testlerini nasıl farklı ele alıyorsun?

  • Dosyadan çok bölümlü bir veritabanına geçiş arasında büyük bir uçurum var. Gerçek üretim yükü söz konusuyken veritabanını container içinde çalıştırmak benim tarzım değil
    Bana göre birçok ETL işi, enterprise veritabanı devreye sokulmadan yerelde işlenebilir. Bu gibi durumlarda DuckDB, SQLite’tan 5–10 kat daha iyi ve özel bir Postgres veritabanı ayağa kaldırmaktan çok daha basit ve hızlı
    Genel script yazımında, 20 satırlık bir awk script’i ile DuckDB tabanlı, çok daha temiz, sağlam ve bakımı yapılabilir eşdeğer bir SQL script’i arasında kıyas bile olmaz
    Umarım MotherDuck, IPO uğruna pump and dump yapmak zorunda kalmaz. Sıradan kurumsal açgözlülük yüzünden bu aracı kaybetmek üzücü olur

    • DuckDB developer relations ekibindeyim. Öncelikle güzel sözler için teşekkürler :)
      20 satırlık awk script’i kısmı ilginç. Dün Ubuntu Summit’te neredeyse aynı savı öne sürdüm. Belli bir noktadan sonra GNU coreutils ile shell script yazmak gerçekçi olmaktan çıkıyor; DuckDB SQL script’leri karmaşıklık, bakım kolaylığı ve çoğu zaman performans açısından çok daha iyi ölçekleniyor. Slaytlar burada: https://blobs.duckdb.org/slides/duckdb-ubuntu-summit-2026.pd... sayfa 32–36
      Ayrıca MotherDuck, DuckDB üzerinde proprietary source bir DBaaS geliştiriyor. DuckDB üzerinde inşa ediliyor ve DuckDB ile MotherDuck’a bağlanıyorsunuz, ancak Seattle merkezli, ayrı ve VC destekli bir şirket
      DuckDB ise Amsterdam merkezli, bootstrap yani gelir odaklı bir şirket olan DuckLabs tarafından geliştiriliyor. Projenin fikri mülkiyeti de üçüncü bir kuruluş olan Hollanda merkezli kâr amacı gütmeyen DuckDB Foundation’da bulunuyor. Ayrıntılar için https://duckdb.org/faq#how-are-duckdb-the-duckdb-foundation-... bağlantısına bakabilirsiniz

  • S3 üzerindeki SQLite DB’yi güvenli şekilde eşzamanlı güncelleyebilmenizi sağlayan bir kütüphane yaptım[0]
    Pek bilinmeyen SQLite sessions uzantısını ve küçük metadata dosyaları üzerinde S3 compare-and-swap kullanarak bunu oldukça verimli ve güvenli çalışacak hale getirdim. Durum saklamak için bir DB’ye ihtiyaç duyulan ama tam bir veritabanı instance’ının maliyetini ödemek istenmeyen birçok küçük Lambda projesinde bunu keyifle kullanıyorum
    [0]: https://github.com/psanford/s3db

  • SQLite, tek düğümlü uygulamalarda Postgres ile kıyaslandığında bile şaşırtıcı derecede iyi performans veriyor
    Postgres çok daha fazla bellek kullanıyor ve G/Ç’nin process’ler arası iletişim üzerinden geçmesi gerekiyor. SQLite’ta ise shared connection pool üzerinden her şeyi process içinde tutabiliyorsunuz
    Agent harness için çeşitli storage engine’leri test ediyorum; SQLite ile tek bir vCPU üzerinde 7,5 bin eşzamanlı oturuma kadar çıkabildim ama Postgres ya çöküyor ya da bağlantıları tüketiyordu
    [0] https://github.com/impalasys/talon/pull/23#issuecomment-4577...

    • SQLite’ı doğru kullanırsanız, aslında fiilen process içi bir method call gibidir. Geriye kalan tek engeller runtime, kernel, dosya sistemi ve yerel NVMe depolamaysa, barındırılan alternatiflerden ezici ölçüde hızlı olabilir
      Mevcut thread’in dışına çıktığınız anda gecikme açısından kaybetmeye başlarsınız. Thread’ler arası iletişimi zorunlu kılmazsanız SQLite mikrosaniye ölçeğinde çalışabilir
    • SQLite’ın çok iyi bir yazılım olduğunu kabul ediyorsak, tek düğümlü uygulamalarda Postgres’e kıyasla iyi performans göstermesi zaten beklenmez mi?
      Tek düğüm bağlamında Postgres fazla kaçıyor. SQLite ile rekabet etmesi beklenmemeli
      Bu biraz, neredeyse bellek içi bir HashMap ile Redis’i benchmark edip ideal koşullarda HashMap’in iyi sonuç vermesine şaşırmaya benziyor

  • Yıllardır SQLite hakkında bir şeyler okuyup durduktan sonra bunu kişisel bir projede denedim; Postgres kullandıktan sonra tip sistemi o kadar zayıf geldi ki şoke oldum
    Gerçekten çok yetersiz; neden bu kadar övüldüğünü anlamıyorum
    https://sqlite.org/datatype3.html
    https://www.postgresql.org/docs/current/datatype.html
    Tarih/saat ile uğraşma hissi 30 yıllık bir veritabanı kullanıyormuşsun gibi ve ekleme sırasında hiçbir şey zorunlu tutulmuyor. Neden bu kadar çok insanın sevdiğini birinin açıklaması lazım

    • STRICT tablolar kullanılabilir: https://sqlite.org/stricttables.html
    • Evet, aslında SQLite hakkında neredeyse tek şikayetim bu. Katı bir tip sistemi olan bir SQLite harika olurdu
    • Bu, geriye dönük uyumluluğun hatası ve bedeli. Çoğu SQLite kullanıcısının her bağlantıda birkaç pragma çalıştırması gerekiyor
      PRAGMA journal_mode = WAL
      PRAGMA foreign_keys = ON

      Something non-null

      PRAGMA busy_timeout = 1000

      This is fine for most applications, but see the manual

      PRAGMA synchronous = NORMAL

      If you use it as a file format

      PRAGMA trusted_schema = OFF
      Binding'e göre ek seçenekler gerekebilir. Örneğin Python uygulamaları sqlite3 modülünün varsayılanlarını kullanmamalı. O varsayılanlar düpedüz yanlış. 3.12 öncesinde standart kütüphane dışı bir binding kullanmak dışında alternatif de yoktu: https://docs.python.org/3/library/sqlite3.html#transaction-c...
      strict table da kullanılmalı. https://www.sqlite.org/stricttables.html
      Kullanımı kötü olsa da CHECK kısıtları da kullanılabilir. Örneğin SQLite'ın yerleşik tarih desteğiyle mümkün ama tuhaf:
      CHECK (
      date(my_date_col) IS NOT NULL
      AND my_date_col = date(my_date_col)
      )
      IS NOT NULL gerekli, çünkü date geçersiz tarihler için NULL döndürüyor. Diğer kontrol ise Julian day değerlerini de kabul ettiği için var; date('2026') MÖ 4707 yılında bir tarihe denk geliyor
    • Tek bir dosya olduğu için
    • Tip sistemi dışındaki şeyler yüzünden övülüyor
      Özellikle strict table öncesinde hayal kırıklığı yarattığına katılıyorum
      DuckDB'ye bakmalısın. Doğru dürüst tiplere sahip SQLite'a daha yakın. Ama OLTP yani struct of arrays değil, OLAP yani array of structs tarafında olduğu için tipik SQLite yüklerinde performansı daha kötü olabilir. Gerçekte, ikisinden birini değerlendiren bir uygulama için aradaki farkın büyük olacağını sanmıyorum

  • Birden fazla büyük Postgres kümesi kullandıktan sonra SQLite'a geçtim; aylık aktif kullanıcısı 7 haneli olan bir servis tamamen SQLite durable objects üzerinde çalışıyor
    Erişim kalıplarını farklı düşünmek gerekiyor ama getirileri buna fazlasıyla değdi

  • Bu iyi bir çerçeveleme. Asıl sorun iş akışı durumunu kalıcı olarak saklamak, incelenebilir ve kolayca kurtarılabilir hale getirmekse, SQLite çoğu zaman yeterlidir

  • Bu fikrin bir sonraki yinelemesi olarak “kalıcı iş akışları için gereken tek şey bir logdur” cümlesini görmeyi sabırsızlıkla bekliyorum

    • Beklemene gerek yok. Zaten oluyor
      “Tek gereken bir logdur” tarzı çözümlerin başarısız olabileceği nedenlerden biri, güvenilmeyen logların enjeksiyon saldırısına dönüşmesidir[1]
      SBOM'u kontrol etmeyi unutmayın; buna CI/CD pipeline'ını da dahil edin[2]
      [1] https://news.ycombinator.com/item?id=48315440
      [2] https://github.com/jqwik-team/jqwik/issues/708#issuecomment-...
    • Ciddi konuşursak, “kalıcı iş akışları için gereken tek şey S3'tür” fikrini kabul eder ve bunu S3'ten S3'e veri taşıyan veri işleme uygulamaları için kullanırdım
    • Yalnızca loglarla kalıcı iş akışları gerçekten yeterli mi? Kafam karışık. Logların üzerinde iç içe geçmiş veya ilişkili verileri nasıl kalıcı hale getirip sorguluyorsunuz? Buradaki log ile Elasticsearch ya da Meilisearch gibi bir şey mi kastediliyor?
    • Sonra da “kalıcı iş akışları için gereken tek şey soketlerdir” gelir, en sonunda da “kalıcı iş akışları için gereken tek şey çekirdeğin temel yapıtaşlarıdır” denir
      Ciddi konuşursak, uzman olmak iş için doğru aracı kullanmaktır