اینو برای گولنگ generate کردم که جالب شد

قسمت ششم پادکست Fundamentals of Software Architecture منتشر شد.

توی این قسمت، فصل چهارم کتاب با عنوان Architecture Characteristics Defined رو بررسی می‌ کنیم، فصلی درباره ویژگی ‌هایی مثل کارایی، مقیاس‌ پذیری، دسترس‌ پذیری، امنیت و ... که موفقیت یک سیستم رو تعیین میکنه.
همچنین درباره ‌ی Trade-offهای معماری، ویژگی‌ های پنهان سیستم، و این موضوع صحبت می‌ کنیم که تلاش برای پشتیبانی از قابلیت‌ های بیش‌ از حد چگونه میتونه یک سیستم رو پیچیده و ناکارآمد بکنه.
این قسمت رو میتونید از وب‌ سایت Engineering Approach گوش بدید:

https://engineeringapproach.ir/podcasts/fundamentals-of-software-architecture

فکر کنم وقتشه طبق چیزهایی که تا الان یاد گرفتیم توی پادکست، سیستم های واقعی دیزاین کنیم، منظورم اینکه یه خوردی عملی هم بهش نگاه کنیم

کتاب آقای Alex XU مثالای خوبی داره
- URL Shortener
- Youtube
- Twitter
- Rate limiter

و سیستم های دیگه ...

حالا بحث اینجاست که فکر میکنید این جلسات آنلاین برگزاره بشه بهتره یا ویدیوش ضبط بشه توی یوتوب پابلیشش کنیم؟

there is no best design in architecture, only a least worst
collection of trade-offs

- Fundamentals of Software Architecture

قسمت هفتم پادکست Fundamentals of Software Architecture منتشر شد.

توی این قسمت، فصل پنجم کتاب با عنوان Identifying Architecture Characteristics رو بررسی می‌ کنیم، توی این قسمت درباره این صحبت میکنیم که دقیقا چطور میتونیم Architecture Characteristics های یک پروژه رو تشخیص بدیم و اینکه بتونیم به خوبی requirementهایی که stakeholder ها میدن رو ترجمه کنیم به Characteristicsهای سیستم.
این قسمت رو میتونید از وب‌ سایت Engineering Approach گوش بدید:

https://engineeringapproach.ir/podcasts/fundamentals-of-software-architecture

داخل این سرفصل به architectural katas اشاره شد که لینک سایتش رو اینجا میزارم:

https://www.architecturalkatas.com/

از آخرین فعالیتم ۳ هفته ای تقریبا میگذره و بابت مشغله زیاد کاری که برام پیش اومده بود
با کیفیت بالاتر برمیگردم

من زندگی رو یه مسیر صاف و مستقیم نمی ‌بینم. همه‌ مون از یه جایی شروع می‌ کنیم و فکر می‌ کنیم قراره به یه سمت مشخص بریم، ولی هر اتفاق، انتخاب یا فقدانی می‌ تونه مسیرمون رو عوض کنه.

درست مثل یه درخت، جای همه‌ ی این اتفاق‌ ها روی ما می‌ مونه. بعضی شکستگی‌ ها تبدیل به زخم میشن و بعضی زخم‌ ها باعث میشن از یه مسیر تازه رشد کنیم.

شاید آخرش اون آدمی نشیم که اول راه فکر می‌ کردیم، ولی هنوز زنده‌ایم و به رشد کردن ادامه میدیم. این برگ‌ها میگن که تغییر کردن همیشه به معنی شکستن نیست، گاهی همین اتفاق‌ ها هستن که ما رو تبدیل میکنن به آدمی که امروز هستیم.

این سوال رو از خودتون بپرسید که اگه همین الان دیتای دیتابیس شما از بین بره و شما بک آپتون رو برگردونید شما چقدر از دیتارو از دست دادید؟

این خیلی وابسته به اینکه چقدر سیستم شما بزرگ هستش، مثلا اگه شما اسکیل بالایی ندارید احتمالا اگر روزانه بک آپ بگیرید کافی باشه و تغییرات خیلی زیادی توی سیستم رو از دست ندید (طبیعتا از دست دادن دیتا اینجا همچنان هزینه داره)، اما اگه اسکیل شما بزرگ تر بود چی؟

وقتی اسکیل بالایی رو داریم کمی داستان فرق میکنه

اینجا Microsoft یه مقاله داره که درباره استراتژی های معماری برای disaster recovery رو توضیح میده که پیشنهاد میکنم بخونید

https://learn.microsoft.com/en-us/azure/well-architected/reliability/disaster-recovery

تا به حال براتون سوال شده که چرا LLM ها از توکن استفاده میکنن؟ چرا به جای توکن از ما به جای هر کلمه ای که تولید میکنن پول کم نمیکنن؟

توی این مقاله یه توضیحی درباره ی این مورد دادم:

https://engineeringapproach.ir/blogs/tokn-o-tokenizer-chyst

#کنجکاوی

دیزاین جدید 🔥