[{"data":1,"prerenderedAt":531},["ShallowReactive",2],{"posts":3},[4,163,385,503],{"id":5,"title":6,"body":7,"date":145,"description":13,"draft":146,"extension":147,"meta":148,"navigation":149,"path":150,"seo":151,"stem":152,"tags":153,"__hash__":162},"content\u002Fposts\u002Fpost-003.md","From Rule to Principle: A Deeper Dive into Single Responsibility",{"type":8,"value":9,"toc":137},"minimark",[10,14,17,22,25,28,31,60,63,67,70,73,76,79,83,86,89,92,95,99,102,105,108,128,131,134],[11,12,13],"p",{},"Many of us working in software development are familiar with the Single Responsibility Principle, often abbreviated as SRP. It's a cornerstone of the SOLID principles, frequently cited in code reviews and design discussions. We learn the definition: \"A class should have only one reason to change.\" But have we considered where this idea comes from, or how it connects to broader concepts?",[11,15,16],{},"This isn't about discarding SRP or finding fault with its common definition. Instead, let's take a slow look, perhaps over a cup of coffee, at the layers beneath this principle. By tracing its connections, we might find a deeper appreciation for why it guides us towards better software design.",[18,19,21],"h2",{"id":20},"the-familiar-ground-single-responsibility-principle-srp","The Familiar Ground: Single Responsibility Principle (SRP)",[11,23,24],{},"Let's start with SRP itself. Popularized by Robert C. Martin, the core idea is to limit the scope of a class or module. The common interpretation focuses on minimizing the reasons a piece of code might need modification. If a class handles user authentication and user profile updates and sending notification emails, a change request related to email formatting could force us to modify and re-test code that also deals with authentication logic. This entanglement increases risk and complexity.",[11,26,27],{},"Martin later clarified the \"reason to change\" by linking it to specific \"actors\" or stakeholders. A class should ideally be responsible to just one actor. For instance, the finance department might request changes to invoice generation logic, while the marketing department might request changes to promotional email logic. SRP suggests these responsibilities, driven by different actors, should reside in separate classes or modules (InvoiceGenerator, PromoMailer).",[11,29,30],{},"The benefits are tangible in our daily work:",[32,33,34,42,48,54],"ul",{},[35,36,37,41],"li",{},[38,39,40],"strong",{},"Improved Maintainability:"," Changes related to one responsibility are isolated, reducing the chance of unintended side effects elsewhere.",[35,43,44,47],{},[38,45,46],{},"Enhanced Testability:"," Smaller, focused classes are easier to unit test thoroughly.",[35,49,50,53],{},[38,51,52],{},"Reduced Coupling:"," Classes have fewer dependencies on unrelated concepts.",[35,55,56,59],{},[38,57,58],{},"Better Organization:"," Code becomes easier to navigate and understand.",[11,61,62],{},"SRP provides a practical heuristic for structuring our code at the class level.",[18,64,66],{"id":65},"broadening-the-view-separation-of-concerns-soc","Broadening the View: Separation of Concerns (SoC)",[11,68,69],{},"If we take a step back from the specifics of a single class, we encounter a more general principle in software and system design: Separation of Concerns (SoC). This principle advises structuring a system into distinct parts that address different aspects or \"concerns.\"",[11,71,72],{},"Think about common architectural patterns. Layered architectures separate presentation (UI), business logic (rules), and data access (database interaction). Each layer represents a distinct concern. On the front end, we separate HTML (structure), CSS (presentation), and JavaScript (behavior).",[11,74,75],{},"SoC aims to manage complexity by preventing different functional aspects from being tightly interwoven. Changes within one concern (like updating the visual styling in CSS) ideally shouldn't necessitate changes in how data is structured (HTML) or how user interactions are handled (JavaScript).",[11,77,78],{},"How does SRP relate? SRP can be seen as a specific application of SoC, focused primarily at the level of classes or modules within object-oriented programming. While SoC is a broader guideline for system structure, SRP provides a more concrete criterion (the \"single reason to change\" or \"single actor\") for deciding how to separate concerns within our codebase's building blocks. It helps us apply the spirit of SoC to the detailed design of our classes.",[18,80,82],{"id":81},"the-foundational-idea-division-of-labour","The Foundational Idea: Division of Labour",[11,84,85],{},"Taking an even wider view, we can see that the principle of Separation of Concerns in software mirrors a much older, more fundamental concept: the Division of Labour. This idea, discussed by thinkers like Adam Smith centuries ago but practiced long before, is fundamental to economics, manufacturing, and social organization.",[11,87,88],{},"Division of Labour involves breaking down a complex process into smaller, specialized tasks performed by dedicated individuals or groups. Consider a factory assembly line: each worker performs a specific, repetitive task, contributing to the overall product. This specialization leads to increased efficiency, expertise, and often higher quality compared to one person attempting to do everything. We see it in companies with specialized departments (Finance, Engineering, Marketing) and in countless other areas.",[11,90,91],{},"The core benefit is managing complexity and leveraging specialization. By focusing tasks, we make them more manageable, repeatable, and optimizable.",[11,93,94],{},"When we practice Separation of Concerns in software, and more specifically when we apply the Single Responsibility Principle to our classes, we are essentially applying this age-old wisdom of Division of Labour to the construction of software systems. We are breaking down the complex task of building software into smaller, specialized, more manageable units (layers, modules, classes), each with a focused responsibility.",[18,96,98],{"id":97},"from-rule-to-understanding-shadows-stages-and-insight","From Rule to Understanding: Shadows, Stages, and Insight",[11,100,101],{},"Recognizing these connections (seeing SRP as a specific form of SoC, which in turn reflects the fundamental principle of Division of Labour) doesn't change the definition of SRP. However, it can profoundly shift our perspective on learning and applying such principles.",[11,103,104],{},"It's easy to learn the rules of software design (the specific definitions of SRP, LSP, and others) without fully grasping the underlying landscape. This initial stage can feel a bit like Plato's Allegory of the Cave. We become adept at recognizing the \"shadows\" on the wall: the specific patterns and principles as they appear in our daily work within the \"cave\" of software development. These shadows are useful, even essential, for navigating our immediate environment.",[11,106,107],{},"However, the journey towards deeper understanding involves questioning those shadows and seeking the \"objects\" casting them: the more fundamental principles like SoC and Division of Labour. This journey often mirrors the stages described in the Japanese concept of Shuhari:",[32,109,110,116,122],{},[35,111,112,115],{},[38,113,114],{},"Shu (Protect\u002FObey):"," We first learn the rules, like SRP, and apply them diligently as taught. We focus on correct imitation and adherence. This is mastering the identification of the shadows.",[35,117,118,121],{},[38,119,120],{},"Ha (Detach\u002FBreak):"," We begin to understand the principles behind the rules. We connect SRP to SoC, question its boundaries, and explore the why. We start to see the objects casting the shadows, moving beyond rote application. This is the process of leaving the cave.",[35,123,124,127],{},[38,125,126],{},"Ri (Leave\u002FSeparate):"," The principles become internalized. Design decisions flow more intuitively from a deep understanding of managing complexity, cohesion, and coupling. We can adapt, combine, or even transcend the original rules appropriately because we understand the fundamental reality, not just its projections. This is akin to understanding the world outside the cave.",[11,129,130],{},"Seeing SRP not just as an isolated rule, but as part of this larger conceptual lineage (DoL -> SoC -> SRP), helps us move through these stages. It transforms SRP from a mere shadow or a rule to be obeyed (Shu) into a principle whose purpose and context we understand (Ha), paving the way towards more intuitive and effective design (Ri).",[11,132,133],{},"This deeper understanding allows for more thoughtful design decisions. We can better judge when adhering strictly to SRP yields the most benefit and when other concerns might warrant a different approach, always keeping the fundamental goal (creating clear, maintainable, and robust systems) in view.",[11,135,136],{},"So, the next time SRP comes up in a discussion or code review, perhaps we can appreciate it not just as a software design rule, but as a reflection of a fundamental strategy for tackling complexity, and reflect on our own journey in understanding its place in the broader landscape of ideas.",{"title":138,"searchDepth":139,"depth":139,"links":140},"",2,[141,142,143,144],{"id":20,"depth":139,"text":21},{"id":65,"depth":139,"text":66},{"id":81,"depth":139,"text":82},{"id":97,"depth":139,"text":98},"2025-04-04T23:39:32Z",false,"md",{},true,"\u002Fposts\u002Fpost-003",{"title":6,"description":13},"posts\u002Fpost-003",[154,155,156,157,158,159,160,161],"Software Design","SOLID","SRP","SoC","Design Principles","Programming","Object Oriented Programming","Shuhari","pn7zAEF_bkfkfDY23wEBKv4DB23v9rCZ9OZomoVVPuk",{"id":164,"title":165,"body":166,"date":373,"description":374,"draft":146,"extension":147,"meta":375,"navigation":149,"path":376,"seo":377,"stem":378,"tags":379,"__hash__":384},"content\u002Fposts\u002Fpost-002.md","TypeScript'in Go'ya port edilmesi: Ne Anlama Geliyor?",{"type":8,"value":167,"toc":365},[168,179,183,186,189,198,201,205,208,212,215,218,221,224,294,298,301,310,313,316,320,323,340,343,346,350,359,362],[11,169,170,171,178],{},"TypeScript ekibinden geçen hafta oldukça heyecan verici bir haber geldi: TypeScript'in Go'ya ",[172,173,177],"a",{"href":174,"rel":175},"https:\u002F\u002Fdevblogs.microsoft.com\u002Ftypescript\u002Ftypescript-native-port\u002F",[176],"nofollow","port edilmesi",". Bu haber epey konuşuldu ve ben de biraz kafa karışıklığı yaşadım açıkçası. Türkçe kaynak pek göremediğim için düşüncelerimi paylaşmak istedim.",[18,180,182],{"id":181},"neden-port-ediliyor","Neden Port Ediliyor?",[11,184,185],{},"TypeScript, projelerdeki developer experience'ı (DX) artıran harika bir araç, ancak son zamanlarda en çok talep edilen özellik özellikle performans oldu. Özellikle proje boyutu büyüdükçe, TypeScript'in type-checking süresi artıyor. Bazen bir süre sonra language server'ı yeniden başlatmak zorunda kalıyorduk. Bu durum DX üzerinde olumsuz etki yapıyordu.",[11,187,188],{},"Bunun ana sebeplerinden biri, TypeScript compiler'ın TypeScript ile yazılmış olmasıydı. Bu durum iki soruna yol açıyor:",[190,191,192,195],"ol",{},[35,193,194],{},"Tooling native olarak çalışmıyor; bunun yerine tsc, JavaScript'e transpile edilip Node üzerinde çalışıyor. Bu durumda performans olumsuz etkileniyor.",[35,196,197],{},"JavaScript'in dil olarak sahip olduğu limitasyonlar. JavaScript single threaded bir yapıya sahip; her ne kadar Web Worker gibi çözümlerle bu engel aşılmaya çalışılsa da, javascript genel olarak browserlari için optimize edilmiş bu yüzden bu sistem seviyesi veya cli toollarda faydası olmuyor.",[11,199,200],{},"Her ne kadar TypeScript ekibi inanılmaz yetenekli uzmanlardan oluşsa da, bu limitasyonların üstesinden gelmenin bir sınırı var ve TypeScript bu sınıra ulaştı.",[18,202,204],{"id":203},"go-portunun-avantajları","Go Portunun Avantajları",[11,206,207],{},"Yeni tsc, Go ile yazıldığı için first-class concurrency ve parallelism sunuyor. Aynı zamanda, Go'nun native binary olarak compile edilmesi performansı artırıyor. Günün sonunda, bu portun amacı yalnızca performansı artırmaktır; TypeScript'in syntax'ı ve özellikleri aynı kalacaktır.",[18,209,211],{"id":210},"esbuild-vs-tsc-fark-ne","esbuild vs tsc: Fark Ne?",[11,213,214],{},"Birçok kişinin kafasını karıştıran sorulardan biri: esbuild varken neden Go ile yazılan tsc'ye ihtiyaç duyuluyor?",[11,216,217],{},"Kısa cevap: İkisi farklı amaçlara hizmet ediyor.",[11,219,220],{},"Uzun cevap ise; esbuild sadece transpile ve bundling işlemleri yapıyor. tsc ise bundling yapmaz; onun yerine daha fazla işlevi üstlenir. tsc, TypeScript'in language server'ını çalıştırır, type-checking yapar ve declaration file'larını oluşturur. Bu işlemler esbuild'te bulunmaz.",[11,222,223],{},"Aralarındaki farkı şu şekilde özetleyebiliriz:",[225,226,227,243],"table",{},[228,229,230],"thead",{},[231,232,233,237,240],"tr",{},[234,235,236],"th",{},"Özellik",[234,238,239],{},"tsc",[234,241,242],{},"esbuild",[244,245,246,260,272,283],"tbody",{},[231,247,248,254,257],{},[249,250,251],"td",{},[38,252,253],{},"Type Checking",[249,255,256],{},"✓",[249,258,259],{},"Sınırlı",[231,261,262,267,269],{},[249,263,264],{},[38,265,266],{},"Declaration File Generation",[249,268,256],{},[249,270,271],{},"Yok",[231,273,274,279,281],{},[249,275,276],{},[38,277,278],{},"Language Server",[249,280,256],{},[249,282,271],{},[231,284,285,290,292],{},[249,286,287],{},[38,288,289],{},"Bundling",[249,291,271],{},[249,293,256],{},[18,295,297],{"id":296},"bu-değişiklik-nerede-hissedilecek","Bu Değişiklik Nerede Hissedilecek?",[11,299,300],{},"Bu değişiklik TypeScript'in çalışma anındaki performansını etkilemiyor; developer experience'ı (DX) artırıyor. Büyük hatta ortalama boyutlardaki TypeScript projeleri çalışırken bilgisayara ağır yük bindiriyor. Type-checking süreleri uzayabiliyor veya language server'ın bazı özellikleri bir süre sonra çalışmıyor.",[11,302,303,304,309],{},"Aynı zamanda, modern dönemde dil özellikleri Microsoft tarafından geliştirilen ",[172,305,308],{"href":306,"rel":307},"https:\u002F\u002Fmicrosoft.github.io\u002Flanguage-server-protocol\u002F",[176],"Language Server Protocol (LSP)"," ile sağlanıyor. LSP'ler, yazıldıkları diller için standart IDE özelliklerini sunuyor; bu sayede IDE geliştiricileri LSP'leri kullanarak pek çok dile destek sağlayabiliyor.",[11,311,312],{},"Ancak, TypeScript'in resmi bir LSP'si yok ve mevcut üçüncü parti TypeScript LSP'leri sınırlı özellikler sunuyor. LSP yerine bu dil özellikleri doğrudan VSCode'a entegre edilmiş durumda, bu da farklı IDE kullanıcılarının TypeScript'in özelliklerinden tam olarak yararlanmasını engelliyor.",[11,314,315],{},"Bu port ile beraber resmi bir LSP sunulacak ve bu sayede hem VSCode hem de VSCode tabanlı olmayan diğer IDE'lerde TypeScript dil desteğinden tamamen faydalanılabilecek. Tüm bu değişikliklerle beraber editör performansı da artacak.",[18,317,319],{"id":318},"geçiş-süreci-nasıl-i̇şleyecek","Geçiş Süreci Nasıl İşleyecek?",[11,321,322],{},"Geçiş süreci birçok kişinin kafasını karıştırmış durumda. Sürecin nasıl ilerleyeceğini özetlemem gerekirse:",[32,324,325,328,331],{},[35,326,327],{},"Go ile yazılmış tsc, TypeScript 7 sürümü ile birlikte çıkacak",[35,329,330],{},"TypeScript 6(js) ve typescript 7(go) beraber yaşıyacaklar.",[35,332,333,334,339],{},"Şu anda, public bir ",[172,335,338],{"href":336,"rel":337},"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftypescript-go",[176],"repository","'de kullanılabilir durumda",[11,341,342],{},"Bu sürümün ne zaman çıkacağı kesin olmasa da 2025 sonlarına doğru yayınlanacağını tahmin ediyorum. Yukarıda bahsettiğim giib şu anda, public bir repository'de kullanılabilir durumda, ancak henüz hazır bir binary bulunmuyor; dolayısıyla kendinizin compile etmesi gerekiyor.",[11,344,345],{},"Çoğu projenin sorunsuz bir şekilde TypeScript 7'ye geçmesi hedeflenirken, özellikle bazı legacy API'lere bağlı projelerde problem yaşanmaması için, typescript 6 js ile yazılmaya devam edecek. Bu şekilde projenizi typescript 6 ya upgrade edip ihtiyacınız olan özelliklerin go sürümüne gelmesini bekleyebilir geldiği zaman geçişi yapabilirsiniz yada tam tersi go sürümünde bulduğunuz bir hata veya eksiklik durumunda typescript 6 ya geçip devam edebilirsiniz.",[18,347,349],{"id":348},"neden-go-da-rust-değil","\"Neden Go da Rust Değil?\"",[11,351,352,353,358],{},"Bu konuda da bir tartışma var tabii. Ben bu konuyu açıkçası pek umursamadım, ama merak edenler ",[172,354,357],{"href":355,"rel":356},"https:\u002F\u002Fwww.reddit.com\u002Fr\u002Fprogramming\u002Fcomments\u002F1j8s40n\u002Fa_10x_faster_typescript\u002F",[176],"bu Reddit gönderisine"," bakabilir.",[360,361],"hr",{},[11,363,364],{},"Bu değişiklik, TypeScript ekosisteminde önemli bir dönüm noktası olacak gibi görünüyor. Performans iyileştirmeleri ve daha iyi IDE desteği, TypeScript'in zaten güçlü olan developer experience'ını daha da ileriye taşıyacak.",{"title":138,"searchDepth":139,"depth":139,"links":366},[367,368,369,370,371,372],{"id":181,"depth":139,"text":182},{"id":203,"depth":139,"text":204},{"id":210,"depth":139,"text":211},{"id":296,"depth":139,"text":297},{"id":318,"depth":139,"text":319},{"id":348,"depth":139,"text":349},"2025-03-18T21:30:09Z","TypeScript ekibinden geçen hafta oldukça heyecan verici bir haber geldi: TypeScript'in Go'ya port edilmesi. Bu haber epey konuşuldu ve ben de biraz kafa karışıklığı yaşadım açıkçası. Türkçe kaynak pek göremediğim için düşüncelerimi paylaşmak istedim.",{},"\u002Fposts\u002Fpost-002",{"title":165,"description":374},"posts\u002Fpost-002",[380,381,382,383],"typescript","go","performance","developer-experience","iRdAZNBc9xFend8cNXuO20jgOD-GWy711nrlVz35eKQ",{"id":386,"title":387,"body":388,"date":496,"description":392,"draft":146,"extension":147,"meta":497,"navigation":149,"path":498,"seo":499,"stem":500,"tags":501,"__hash__":502},"content\u002Fposts\u002Fpost-001.md","How did I created this blog?",{"type":8,"value":389,"toc":494},[390,393,400,431,475,491],[11,391,392],{},"Hey there!",[11,394,395,396,399],{},"So, I thought I’d chat a bit about the ",[38,397,398],{},"tech stack"," behind this blog. Maybe it’ll be helpful for anyone out there thinking about starting their own blog but feeling a bit lost on where to begin.",[11,401,402,403,406,407,412,413,416,417,420,421,424,425,430],{},"First off, let’s talk about why I didn’t go with the ",[38,404,405],{},"usual suspects",". The main reason? I’m not a big fan of trusting companies with my content. I want to make sure my ideas don’t get snatched up because of some sneaky legal jargon buried in a 124-page agreement. If you’ve seen the recent ",[172,408,411],{"href":409,"rel":410},"https:\u002F\u002Fblog.mozilla.org\u002Fen\u002Fproducts\u002Ffirefox\u002Fupdate-on-terms-of-use\u002F",[176],"Firefox blunder",", you’ll know companies are always looking to squeeze as much value out of users as they can, even if it’s predatory. I’d rather not deal with that. Another thing is how easy (or hard) it is to switch ",[38,414,415],{},"blog providers",". It’s not always a breeze to move your posts from one platform to another. Hosting my own blog means I can switch things up whenever I want. And then there’s the whole ",[38,418,419],{},"features and pricing"," thing. Like most people, I love free stuff, but the free options for blogging often feel pretty limited. Want to use your own domain? That’s usually a paid feature, and sometimes it’s not even an option. And don’t get me started on ",[38,422,423],{},"analytics","—I want to know what my readers are into without invading their privacy, so ",[172,426,429],{"href":427,"rel":428},"https:\u002F\u002Fanalytics.google.com\u002F",[176],"Google Analytics"," is a no-go for me. Those are the big reasons.",[11,432,433,434,436,437,440,441,446,447,452,453,458,459,464,465,470,471,474],{},"Now, let’s dive into the ",[38,435,398],{}," and the decisions I made. First, I wanted something hassle-free and easy to set up. Lucky for me, there are plenty of options out there, and of course, I wanted to host it for free. I wasn’t keen on using a ",[38,438,439],{},"frontend framework","—why overcomplicate a simple blog? So, I skipped ",[172,442,445],{"href":443,"rel":444},"https:\u002F\u002Fvuejs.org\u002F",[176],"Vue",". I was open to trying something new, so I started playing around with ",[172,448,451],{"href":449,"rel":450},"https:\u002F\u002Fastro.build\u002F",[176],"Astro",". It turned out to be more than I needed. I wanted to get my blog up and running in about an hour, and while Astro has some great themes, the setup process was a bit too much for me. Still, it’s a solid choice if you’re looking for something more than just a basic blog. I also considered ",[172,454,457],{"href":455,"rel":456},"https:\u002F\u002Fjekyllrb.com\u002F",[176],"Jekyll"," and ",[172,460,463],{"href":461,"rel":462},"https:\u002F\u002Fgohugo.io\u002F",[176],"Hugo",", checked out their themes, and eventually settled on Hugo with the ",[172,466,469],{"href":467,"rel":468},"https:\u002F\u002Fthemes.gohugo.io\u002Fthemes\u002Fnot-much\u002F",[176],"not-much"," theme. The only downside? Hugo doesn’t come with a built-in ",[38,472,473],{},"CMS",", so you’re either stuck with a third-party CMS or, like me, writing a lot of markdown.",[11,476,477,478,483,484,487,488,490],{},"For hosting, I went with ",[172,479,482],{"href":480,"rel":481},"https:\u002F\u002Fwww.netlify.com\u002F",[176],"Netlify",". They’ve got a nice free plan and some cool features that make creating and hosting your website a breeze. I used one of their templates to set up my Hugo repo, which sped things up a bit. They also have a prebuilt ",[38,485,486],{},"CI\u002FCD pipeline",", so I didn’t have to set one up myself—pretty handy. Adding your own domain is also super easy. I’m not using it, but they even have an easy way to add a ",[38,489,473],{}," to your site if you need one.",[11,492,493],{},"So, that’s the lowdown on how I put this blog together. Hopefully, it gives you some ideas if you’re thinking about starting your own!",{"title":138,"searchDepth":139,"depth":139,"links":495},[],"2025-03-01T23:40:24Z",{},"\u002Fposts\u002Fpost-001",{"title":387,"description":392},"posts\u002Fpost-001",[],"ng_U0DZEIJr8SC16cElRgk1BwMHqvXuzYNArnevEceQ",{"id":504,"title":505,"body":506,"date":524,"description":392,"draft":146,"extension":147,"meta":525,"navigation":149,"path":526,"seo":527,"stem":528,"tags":529,"__hash__":530},"content\u002Fposts\u002Fhello-world.md","Hello World",{"type":8,"value":507,"toc":522},[508,510,513,516,519],[11,509,392],{},[11,511,512],{},"Since this is my first post, I’ll keep it short and sweet—just a little introduction. My name is Yusuf, and I’m currently living in Eskişehir, Türkiye. I work as a software developer at Airties, and I’m really passionate about what I do.",[11,514,515],{},"In my free time, I love tinkering with all sorts of things. I’m into 3D printing, making coffee (yes, I’m a bit of a coffee nerd), and reading—usually about software-related topics. I’m also a huge fan of Kendrick Lamar. When it comes to gaming, I’m obsessed with Hades and Slay the Spire—both are absolute masterpieces in my book.",[11,517,518],{},"At work, I primarily use Java and Spring Boot for backend development, JavaScript\u002FTypeScript and Vue 3 for frontend, and AWS services. I’ll admit, I’m the kind of coworker who sometimes needs to learn to stop talking and avoid creating extra work for others. I’m always looking for ways to improve systems, which can sometimes mean more tasks for the team. If any of my coworkers are reading this… well, I’m not sorry! 😆",[11,520,521],{},"That’s it for my intro—short and to the point. I hope it gives you a good sense of who I am. If you’d like to connect, feel free to check out my socials in the menu. Thanks for reading, and see you around!",{"title":138,"searchDepth":139,"depth":139,"links":523},[],"2025-03-01T22:32:34Z",{},"\u002Fposts\u002Fhello-world",{"title":505,"description":392},"posts\u002Fhello-world",[],"mKKQrINxWM2u-IRlar_nZY7polZvH9COxNE2RNT6q1k",1779902577847]