Tele net

#Observer_Pattern #30_day_30_design_patterns_fire 🔥 روز چهاردهم تعریف الگو: Observer یه الگوی behavioral هست که یه رابطه‌ی one-to-many بین object ها تعریف می‌کنه: یه object به اسم subject (یا publisher) لیستی از observer ها (یا subscriber ها) رو نگه می‌داره، و هر وقت state اش تغییر کنه، به‌صورت خودکار به همه‌ی observer ها خبر می‌ده. observer ها می‌تونن هر وقت خواستن subscribe یا unsubscribe بشن، بدون اینکه subject نیاز داشته باشه از جزئیات داخلیشون خبر داشته باشه. توضیح استفاده: هر جا که چندتا بخش از سیستم باید از یه تغییر خاص باخبر بشن، بدون اینکه اون بخش‌ها به‌صورت مستقیم و سفت به همدیگه وابسته باشن، Observer به کارت میاد. مثال رایج: یه سیستم که وقتی قیمت یه سهم عوض می‌شه، باید هم UI آپدیت بشه، هم یه لاگ ثبت بشه، هم شاید یه notification ارسال بشه. بدون Observer، کلاس اصلی (سهم) باید مستقیماً بدونه UI و logger و notification چطور کار می‌کنن و صداشون بزنه، که باعث می‌شه هر تغییر کوچیک توی این بخش‌ها، کلاس اصلی رو هم مجبور به تغییر کنه. کد بدون پترن (مشکل‌دار): class Stock: def __init__(self, symbol, price): self.symbol = symbol self.price = price def set_price(self, new_price): self.price = new_price # Stock مستقیماً باید همه‌ی مصرف‌کننده‌ها رو بشناسه و صداشون بزنه self.update_ui() self.log_price_change() self.send_notification() def update_ui(self): print(f"UI updated: {self.symbol} is now ${self.price}") def log_price_change(self): print(f"LOG: {self.symbol} price changed to ${self.price}") def send_notification(self): print(f"Notification sent for {self.symbol}") stock = Stock("AAPL", 150) stock.set_price(155) # اگه بخوایم یه observer جدید اضافه کنیم (مثلاً ذخیره توی دیتابیس) # باید کلاس Stock رو باز کنیم و یه متد جدید داخلش اضافه کنیم مشکل اینجاست که کلاس Stock مستقیماً به همه‌ی این رفتارها (UI، لاگ، notification) وابسته‌ست. اضافه‌کردن یه observer جدید یا حذف یکیشون، یعنی باید بری خود کلاس Stock رو تغییر بدی؛ این هم Open/Closed Principle رو نقض می‌کنه، هم coupling رو خیلی زیاد می‌کنه. کد با Observer: from abc import ABC, abstractmethod # Observer interface class Observer(ABC): @abstractmethod def update(self, symbol: str, price: float): pass class UIDisplay(Observer): def update(self, symbol: str, price: float): print(f"UI updated: {symbol} is now ${price}") class Logger(Observer): def update(self, symbol: str, price: float): print(f"LOG: {symbol} price changed to ${price}") class NotificationService(Observer): def update(self, symbol: str, price: float): print(f"Notification sent for {symbol}") # Subject - manages observers and notifies them automatically class Stock: def __init__(self, symbol, price): self.symbol = symbol self.price = price self._observers = [] def subscribe(self, observer: Observer): self._observers.append(observer) def unsubscribe(self, observer: Observer): self._observers.remove(observer) def set_price(self, new_price): self.price = new_price for observer in self._observers: observer.update(self.symbol, self.price) # Usage stock = Stock("AAPL", 150) stock.subscribe(UIDisplay()) stock.subscribe(Logger()) stock.subscribe(NotificationService()) stock.set_price(155) # UI updated: AAPL is now $155 # LOG: AAPL price changed to $155 # Notification sent for AAPL حالا اضافه‌کردن یه observer جدید (مثلاً ذخیره توی دیتابیس) فقط یعنی یه کلاس جدید بسازی که از Observer ارث‌بری می‌کنه و با subscribe() بهش وصلش کنی؛ کلاس Stock هیچ‌وقت لازم نیست دست بخوره. ✨ نکته: مراقب "memory leak" رایج توی این pattern باش: اگه یه observer رو subscribe کنی ولی هیچ‌وقت unsubscribe نکنی، حتی وقتی اون object دیگه لازم نیست، subject همچنان بهش reference داره و garbage collector نمی‌تونه پاکش کنه. توی سیستم‌های بزرگ (مثلاً event listener های UI) این یکی از رایج‌ترین منابع memory leak هست، پس همیشه یادت باشه چرخه‌ی زندگی observer ها رو مدیریت کنی.

#Strategy_Pattern #30_day_30_design_patterns_fire 🔥 روز سیزدهم تعریف الگو: با Strategy وارد دسته‌ی الگوهای behavioral می‌شیم. Strategy یه خانواده از الگوریتم‌های قابل تعویض رو تعریف می‌کنه، هرکدوم رو توی یه کلاس جدا می‌ذاره، و بهت اجازه می‌ده در زمان اجرا (runtime) هرکدوم رو که خواستی انتخاب و استفاده کنی. به‌جای اینکه یه الگوریتم رو داخل کلاس اصلی hardcode کنی، اون رو به یه object جدا (strategy) می‌سپاری که می‌تونی به‌راحتی عوضش کنی. توضیح استفاده: وقتی یه رفتار یا الگوریتم داری که چندتا نسخه‌ی مختلف ازش وجود داره (مثلاً چندتا روش مختلف مرتب‌سازی، چندتا روش محاسبه‌ی تخفیف، یا چندتا روش پرداخت)، و کد اصلیت پر شده از if/else یا switch برای تشخیص اینکه کدوم روش رو اجرا کنه، Strategy این مشکل رو حل می‌کنه. مثال رایج: یه سیستم فروشگاه که بسته به نوع مشتری (عادی، VIP، تازه‌وارد) باید تخفیف رو با فرمول‌های متفاوت حساب کنه. با Strategy، هر فرمول توی کلاس خودش زندگی می‌کنه و اضافه‌کردن یه نوع تخفیف جدید یعنی فقط یه کلاس جدید اضافه کنی، بدون دست‌زدن به کد قبلی. کد بدون پترن (مشکل‌دار): class PriceCalculator: def calculate(self, price, customer_type): # هر نوع مشتری جدید یعنی یه elif جدید اینجا if customer_type == "regular": return price elif customer_type == "vip": return price * 0.8 # 20% off elif customer_type == "new": return price * 0.9 # 10% off else: raise ValueError("Unknown customer type") calculator = PriceCalculator() print(calculator.calculate(100, "vip")) # 80.0 مشکل اینجاست که با اضافه‌شدن هر نوع مشتری جدید (مثلاً "employee" یا "seasonal_sale")، باید بری همین متد رو باز کنی و یه elif جدید اضافه کنی. این هم خلاف Open/Closed Principle هست، هم با زیادشدن انواع تخفیف، این تابع به‌سرعت شلوغ و سخت‌نگهداری می‌شه. کد با Strategy: from abc import ABC, abstractmethod # Strategy interface class DiscountStrategy(ABC): @abstractmethod def calculate(self, price: float) -> float: pass class RegularDiscount(DiscountStrategy): def calculate(self, price: float) -> float: return price class VIPDiscount(DiscountStrategy): def calculate(self, price: float) -> float: return price * 0.8 class NewCustomerDiscount(DiscountStrategy): def calculate(self, price: float) -> float: return price * 0.9 # Context - uses a strategy without knowing its concrete implementation class PriceCalculator: def __init__(self, strategy: DiscountStrategy): self.strategy = strategy def set_strategy(self, strategy: DiscountStrategy): # strategy can be swapped at runtime self.strategy = strategy def calculate(self, price: float) -> float: return self.strategy.calculate(price) # Usage calculator = PriceCalculator(VIPDiscount()) print(calculator.calculate(100)) # 80.0 calculator.set_strategy(NewCustomerDiscount()) print(calculator.calculate(100)) # 90.0 حالا اضافه‌کردن یه نوع تخفیف جدید (مثلاً EmployeeDiscount) فقط یعنی یه کلاس جدید بسازی که از DiscountStrategy ارث‌بری می‌کنه؛ کلاس PriceCalculator و هیچ کد قبلی دیگه‌ای دست‌نخورده باقی می‌مونه. ✨ نکته: توی پایتون، به‌خاطر first-class function ها، خیلی وقتا نیازی به ساختن کلی کلاس و interface برای Strategy نیست؛ می‌تونی مستقیم یه تابع (function) رو به‌عنوان strategy پاس بدی. مثلاً PriceCalculator(strategy=lambda price: price * 0.8). برای پروژه‌های ساده این روش سبک‌تره؛ نسخه‌ی کلاس‌محور بیشتر وقتی به کار میاد که هر strategy نیاز به state داخلی یا چندتا متد مرتبط با هم داشته باشه. @telenetchanel

#Behavioral_Patterns #30_day_30_design_patterns_fire 🔥 شروع فصل جدید: الگوهای رفتاری 🎭 این گروه از design pattern ها دیگه کاری به «ساخت» یا «چیدمان» آبجکت‌ها ندارن؛ تمرکزشون روی یه چیز دیگه‌ست: چطور آبجکت‌ها با هم ارتباط برقرار کنن و مسئولیت‌ها رو بین‌شون تقسیم کنن. یعنی الگوریتم‌ها و جریان کنترل بین اشیاء چطور مدیریت بشه. چرا مهمه؟ چون توی پروژه‌های واقعی خیلی وقت‌ها مشکل اصلی این نیست که یه شیء چطور ساخته می‌شه، بلکه اینه که چند تا شیء باید با هم هماهنگ بشن بدون اینکه به شدت به هم وابسته بشن. Behavioral pattern ها کمک می‌کنن ارتباط بین آبجکت‌ها منظم، قابل تغییر و قابل توسعه بمونه، بدون اینکه هر تغییر کوچیک کل سیستم رو به هم بریزه. الگوهایی که توی این فصل می‌بینیم: 🔹 Strategy 🔹 Observer 🔹 Command 🔹 State 🔹 Template Method 🔹 Iterator 🔹 Chain of Responsibility 🔹 Mediator 🔹 Memento 🔹 Visitor 🔹 Interpreter فصل جدید شروع شد، آماده باشید چون قراره ببینیم اشیاء چطور مثل یه تیم هماهنگ با هم کار می‌کنن 💪 @telenetchanel

#میم عه این پترنه چقد آشناس @telenetchanel

#Proxy_Pattern #30_day_30_design_patterns_fire 🔥 روز دوازدهم تعریف الگو: Proxy یه الگوی structural هست که یه object جانشین (substitute) جلوی یه object اصلی قرار می‌ده تا دسترسی بهش رو کنترل کنه. Proxy دقیقاً همون interface ای رو داره که object اصلی داره، پس از دید کلاینت هیچ فرقی نمی‌کنه داره با اصل کار می‌کنه یا با Proxy، ولی پشت پرده Proxy می‌تونه قبل یا بعد از رسیدن request به object اصلی، کارهای اضافه‌ای مثل کنترل دسترسی، caching، یا lazy loading انجام بده. توضیح استفاده: چند تا سناریوی رایج برای استفاده از Proxy وجود داره: وقتی ساختن یه object گرون‌قیمته و می‌خوای فقط در صورت نیاز واقعی ساخته بشه (lazy initialization)، وقتی می‌خوای قبل از دسترسی به یه object چک کنی کاربر اصلاً اجازه‌ی دسترسی داره یا نه (access control)، یا وقتی می‌خوای نتیجه‌ی عملیات‌های تکراری رو cache کنی تا هر بار دوباره محاسبه نشه. مثال رایج: بارگذاری یه تصویر سنگین که فقط وقتی واقعاً نمایش داده می‌شه از دیسک خونده بشه، نه موقع ساختن object. کد بدون پترن (مشکل‌دار): class HighResImage: def __init__(self, filename): self.filename = filename print(f"Loading {filename} from disk... (expensive)") # happens immediately def display(self): print(f"Displaying {self.filename}") # حتی اگه هیچ‌وقت این تصویر رو نمایش ندیم، همون لحظه‌ی ساخت از دیسک لود می‌شه gallery = [HighResImage(f"photo_{i}.jpg") for i in range(5)] # Loading photo_0.jpg from disk... (expensive) # Loading photo_1.jpg from disk... (expensive) # ... همه‌ی ۵ تصویر بلافاصله لود می‌شن، حتی اگه کاربر فقط یکیشون رو ببینه مشکل اینجاست که همه‌ی تصویرها بلافاصله و بدون توجه به نیاز واقعی لود می‌شن. اگه کاربر فقط یکی از این ۵ تصویر رو ببینه، بقیه‌شون بی‌جهت منابع مصرف کردن. کد با Proxy: from abc import ABC, abstractmethod class Image(ABC): @abstractmethod def display(self): pass class HighResImage(Image): def __init__(self, filename): self.filename = filename print(f"Loading {filename} from disk... (expensive)") def display(self): print(f"Displaying {self.filename}") class ImageProxy(Image): def __init__(self, filename): self.filename = filename self._real_image = None # not loaded yet def display(self): if self._real_image is None: # actual loading happens only when display() is first called self._real_image = HighResImage(self.filename) self._real_image.display() # Usage: هیچ لودی موقع ساخت انجام نمی‌شه gallery = [ImageProxy(f"photo_{i}.jpg") for i in range(5)] print("Gallery created, nothing loaded yet") # فقط وقتی واقعاً display صدا زده بشه، لود انجام می‌شه gallery[2].display() # Loading photo_2.jpg from disk... (expensive) # Displaying photo_2.jpg حالا ساختن object های ImageProxy تقریباً رایگانه و هیچ کاری با دیسک انجام نمی‌ده. فقط وقتی کاربر واقعاً بخواد یه تصویر خاص رو ببینه، اون یکی به‌صورت lazy لود می‌شه؛ بقیه دست‌نخورده می‌مونن. ✨ نکته: Proxy رو با Decorator اشتباه نگیر؛ از نظر ساختار خیلی شبیه هم هستن (هر دو object اصلی رو wrap می‌کنن) ولی نیتشون فرق داره. Decorator برای اضافه‌کردن رفتار و قابلیت جدیده، ولی Proxy برای کنترل دسترسی به object اصلیه (بدون تغییر رفتار اصلیش). اگه داری چیزی به قابلیت‌های object اضافه می‌کنی، Decorator بزن؛ اگه داری دسترسی بهش رو کنترل یا مدیریت می‌کنی (lazy load، access control، caching، logging)، Proxy بزن. @telenetchanel

نمی‌گم برو روی پروداکشن پاک کردن دیتابیس رو تمرین کن ولی

#میم عه داره درباره سنگ های ابدیت صحبت میکنه سطح کپشن: لجند اولترا @telenetchanel

#Flyweight_Pattern #30_day_30_design_patterns_fire 🔥 روز یازدهم تعریف الگو: Flyweight یه الگوی structural هست که برای صرفه‌جویی در مصرف حافظه استفاده می‌شه، وقتی که باید تعداد زیادی object مشابه بسازی. ایده اینه که داده‌های object رو به دو بخش تقسیم کنی: intrinsic state (بخش مشترک و تکراری که بین همه‌ی object ها یکسانه) و extrinsic state (بخشی که مخصوص هر instance و متفاوته). بخش intrinsic فقط یه بار ساخته می‌شه و بین همه‌ی object ها به اشتراک گذاشته می‌شه، و بخش extrinsic هر بار از بیرون به object پاس داده می‌شه. توضیح استفاده: وقتی می‌خوای تعداد خیلی زیادی object مشابه بسازی (مثلاً هزاران یا میلیون‌ها تا) و ساختن هرکدوم به‌صورت جدا و کامل حافظه‌ی زیادی مصرف می‌کنه، Flyweight به کارت میاد. مثال کلاسیک: رندر کردن یه جنگل با میلیون‌ها درخت که هرکدوم texture و مدل مشترک دارن ولی موقعیت (x, y) و اندازه‌شون فرق می‌کنه، یا یه text editor که برای هر کاراکتر یه object جدا می‌سازه ولی خیلی از این کاراکترها (مثلاً همه‌ی حرف‌های "a") می‌تونن font و style مشترک داشته باشن. اگه برای هر درخت یه object کامل با کل داده‌ی texture بسازی، حافظه به سرعت پر می‌شه؛ Flyweight فقط یه نسخه از texture مشترک نگه می‌داره. کد بدون پترن (مشکل‌دار): class Tree: def __init__(self, x, y, texture, model): self.x = x self.y = y self.texture = texture # heavy data, duplicated for every tree self.model = model # heavy data, duplicated for every tree # هر درخت یه کپی کامل از texture و model سنگین رو نگه می‌داره forest = [] for i in range(100000): tree = Tree(x=i, y=i * 2, texture="oak_texture_data...", model="oak_3d_model_data...") forest.append(tree) # با ۱۰۰ هزار درخت، texture و model سنگین ۱۰۰ هزار بار توی حافظه تکرار می‌شه print(f"Created {len(forest)} trees, each with its own texture copy") مشکل اینجاست که داده‌ی سنگین و مشترک (texture، model) که بین همه‌ی درخت‌های یه نوع یکسانه، به تعداد هر درخت توی حافظه تکرار می‌شه. با افزایش تعداد object ها، مصرف حافظه به‌سرعت غیرقابل کنترل می‌شه. کد با Flyweight: class TreeType: # Intrinsic state - shared, heavy data (texture, model) def __init__(self, texture, model): self.texture = texture self.model = model def draw(self, x, y): print(f"Drawing tree at ({x},{y}) using shared texture/model") class TreeTypeFactory: _tree_types = {} # cache of shared TreeType instances @classmethod def get_tree_type(cls, texture, model): key = (texture, model) if key not in cls._tree_types: print(f"Creating new TreeType for {key} (expensive, done once)") cls._tree_types[key] = TreeType(texture, model) return cls._tree_types[key] class Tree: # Extrinsic state - unique per instance (position) def __init__(self, x, y, tree_type: TreeType): self.x = x self.y = y self.tree_type = tree_type # just a reference, not a copy def draw(self): self.tree_type.draw(self.x, self.y) # Usage forest = [] oak_type = TreeTypeFactory.get_tree_type("oak_texture_data...", "oak_3d_model_data...") for i in range(100000): tree = Tree(x=i, y=i * 2, tree_type=oak_type) # shares the same TreeType forest.append(tree) print(f"Created {len(forest)} trees, all sharing one TreeType instance") forest[0].draw() حالا فرقی نمی‌کنه چند تا درخت بسازی، همه‌شون فقط یه reference به همون یه TreeType مشترک دارن. داده‌ی سنگین texture و model فقط یه بار توی حافظه وجود داره، و هرچی تعداد درخت‌ها بیشتر بشه، صرفه‌جویی حافظه محسوس‌تر می‌شه. ✨ نکته: Flyweight رو فقط وقتی به کار ببر که واقعاً با تعداد زیادی (هزاران به بالا) object طرفی و پروفایل کردی که مصرف حافظه مشکل واقعیه. برای تعداد کم object، این pattern فقط پیچیدگی اضافه می‌کنه بدون فایده‌ی محسوس. همچنین دقت کن که extrinsic state (مثل x, y) هیچ‌وقت نباید داخل خود Flyweight ذخیره بشه؛ همیشه باید از بیرون پاس داده بشه، وگرنه دیگه object ها مشترک نمی‌مونن. @telenetchanel

#میم بدون شرح😁 @telenetchanel

#Facade_Pattern #30_day_30_design_patterns_fire 🔥 روز دهم تعریف الگو: Facade یه الگوی structural هست که یه interface ساده و یکپارچه جلوی یه سیستم پیچیده با کلی کلاس و subsystem مختلف می‌ذاره. کلاینت به‌جای اینکه مستقیم با ده‌ها کلاس داخلی سروکله بزنه و ترتیب صدا زدنشون رو بلد باشه، فقط با یه کلاس Facade کار می‌کنه که خودش پشت پرده همه‌ی اون پیچیدگی‌ها رو مدیریت می‌کنه. توضیح استفاده: وقتی یه subsystem داری که از چندتا کلاس مختلف تشکیل شده و برای انجام یه کار ساده باید چندتا از این کلاس‌ها رو به یه ترتیب خاص صدا بزنی، Facade میاد این پیچیدگی رو پشت یه متد ساده قایم می‌کنه. مثال معروف: روشن‌کردن یه سیستم home theater که باید پروژکتور، آمپلی‌فایر، پلیر و نور رو هرکدوم جدا جدا و به ترتیب مشخص تنظیم کنی. یا توی برنامه‌نویسی، وقتی چندتا API یا کتابخونه‌ی مختلف رو باید برای یه عملیات ساده مثل "ثبت سفارش" (که شامل چک موجودی، پرداخت، و ارسال ایمیل می‌شه) هماهنگ کنی. کد بدون پترن (مشکل‌دار): class InventoryService: def check_stock(self, item): print(f"Checking stock for {item}") return True class PaymentService: def charge(self, amount): print(f"Charging ${amount}") class ShippingService: def create_shipment(self, item): print(f"Creating shipment for {item}") class EmailService: def send_confirmation(self, email): print(f"Sending confirmation to {email}") # کلاینت باید ترتیب درست و همه‌ی جزئیات این چهار تا سرویس رو بلد باشه inventory = InventoryService() payment = PaymentService() shipping = ShippingService() email = EmailService() if inventory.check_stock("laptop"): payment.charge(999) shipping.create_shipment("laptop") email.send_confirmation("user@example.com") # این کد باید هر جای برنامه که سفارش ثبت می‌شه، دوباره تکرار بشه مشکل اینجاست که کلاینت باید بدونه چند تا سرویس مختلف وجود داره، ترتیب صدا زدنشون چیه، و اگه این منطق یه‌جا نوشته نشده باشه، احتمال فراموش‌کردن یه مرحله یا اشتباه توی ترتیب زیاده. کد با Facade: class InventoryService: def check_stock(self, item): print(f"Checking stock for {item}") return True class PaymentService: def charge(self, amount): print(f"Charging ${amount}") class ShippingService: def create_shipment(self, item): print(f"Creating shipment for {item}") class EmailService: def send_confirmation(self, email): print(f"Sending confirmation to {email}") # Facade: hides the complexity of coordinating all subsystems class OrderFacade: def __init__(self): self.inventory = InventoryService() self.payment = PaymentService() self.shipping = ShippingService() self.email = EmailService() def place_order(self, item, amount, email): if not self.inventory.check_stock(item): print("Item out of stock") return self.payment.charge(amount) self.shipping.create_shipment(item) self.email.send_confirmation(email) # Usage: کلاینت فقط یه متد ساده صدا می‌زنه order = OrderFacade() order.place_order("laptop", 999, "user@example.com") حالا هرجای برنامه که بخوای سفارش ثبت کنی، فقط place_order() رو صدا می‌زنی. تمام منطق هماهنگی بین سرویس‌ها یه جا نگه‌داری می‌شه و اگه فردا ترتیب یا نحوه‌ی هماهنگی عوض بشه، فقط کافیه Facade رو تغییر بدی. ✨ نکته: Facade جلوی دسترسی مستقیم به subsystem ها رو نمی‌گیره؛ یعنی اگه یه جایی واقعاً نیاز داشتی مستقیم با PaymentService کار کنی، هنوز می‌تونی. Facade فقط یه راه ساده‌تر و پیش‌فرض جلوت می‌ذاره، نه یه محدودیت اجباری. حواست باشه Facade رو با یه "super-class" که همه‌چیز رو انجام می‌ده اشتباه نگیری؛ Facade خودش منطق تجاری جدید نمی‌سازه، فقط هماهنگ‌کننده‌ی چیزهاییه که از قبل وجود دارن. @telenetchanel

ترس از پخش شدن خبر نیاز به نیروی انسانی بیشتر و کم کردن تأثیر LLM باعث شده اخبار استخدام‌ شرکت‌های بزرگ بصورت پراکنده پخش بشه چون این: هم سرمایه‌گذار‌ها رو کم می‌کنه هم ضرر مالی میده هم دستمزد نیروی انسانی رو بالا میبره مشکل اصلی: فکر می‌کردند با گذشت…

ترس از پخش شدن خبر نیاز به نیروی انسانی بیشتر و کم کردن تأثیر LLM باعث شده اخبار استخدام‌ شرکت‌های بزرگ بصورت پراکنده پخش بشه چون این: هم سرمایه‌گذار‌ها رو کم می‌کنه هم ضرر مالی میده هم دستمزد نیروی انسانی رو بالا میبره مشکل اصلی: فکر می‌کردند با گذشت زمان هزینه مدل‌های هوش مصنوعی کمتر خواهد شد. خیلی‌ها فکر می‌کردند، اگر مدل ۷۰۰ میلیارد پارامتری انقدر خوب کار می‌کنه چندسال دیگه که دیتاسنتر و چیپ‌های تخصصی و ... ساخته بشه، مدلی با سایز ۱۰ برابر بزرگتر و قیمت ۱۰ برابر ارزونتر می‌تونه همه‌ی کارها رو انجام بده. الان وضعیت اینه، توی ۴ سال مدل‌ها نهایتاً ۴-۵ برابر بزرگتر شدند. قیمت برق هرجایی که دیتاسنتر ساخته شده بالا رفته. دیتاسنتر‌ها به محل زندگی آدم‌ها نزدیکتر شدند و آلودگی صوتی بالا رفته. قیمت تولید مدل‌های بزرگتر و البته دپلوی اونها اونقدر برای شرکت‌ها ارزون نشده که سوددهی شرکت فقط از فروش مدل باشه. خلاصه: خیلی شرکت‌ها توی چندماه اخیر ساخت چندتا از دیتاسنترها رو کنار گذاشتند. شرکتی مثل spaceX داره تمام تلاشش رو می‌کنه دیتاسنترها رو به فضا منتقل کنه تا مشکلات کم بشه (فکر کنم ۲۰۲۵ بود اولین مورد از سخت‌افزارهای Nvidia رو فرستادند فضا) گزارش هم اومده که شرکت‌ها به بخش‌های بزرگ گفتند نمی‌تونند به یکباره تعداد زیادی نیرو استخدام کنند و باید استخدام رو توی تیم‌ها بشکونند تا خبری از تعداد استخدام‌ها منتشر نشه هزینه ساخت چیپ، تولید رم و البته راه‌اندازی دیتاسنتر به شدت بالا رفته و وضعیت طوری شده که تیم‌های ریسرچ Grok, Deepmind برای دسترسی گرفتن به سرور‌های تحقیقاتی خودشون باید توی صف وایسند چون شرکت‌های هوش مصنوعی دیگه اون‌ها رو اجاره کردند در نهایت، قیمت همه‌ نوع سخت‌افزار بالا رفته و هزینه دیتاسنتر‌های غیر هوش مصنوعی رو هم بالا برده (هم توی راه‌اندازی هم توی نگهداری) اوضاع عجیبی شده پینوشت: اضافه کنم؛ SpaceX همین الان داره مجوز میگیره که تا 1,000,000 ماهواره دیگه رو به فضا بتونه بفرسته البته نه برای اینترنت (مجوزهای لازم اون بخش رو گرفته) بلکه برای منتقل کردن پردازش به فضا هست، اینترنت رو که اون بالا داره تست‌های nvidia هم که پارسال جواب داد. محاسباتم بره اون بالا هزینه برق و آب و خرید زمین هم از بین میره البته هزینه‌های دیگه میاد، که اگر مثل اینترنت ماهواره‌ای باشه هر پرتاب حداقل تا ۸ برابر براش سود خواهد داشت.

تغییرات در نسخه های 5 , 5.1 , 5.2 , 6 , 6.1 برای مطالعه شخصیم داشتم صفحات مربوط به تغییرات جنگو رو بررسی میکردم که تا الان چه چیز هایی تغییر کرده تا اطلاعات کافی برای شروع ضبط جنگو مقدماتی داشته باشم و متوجه یسری تغییرات اساسی شدم که به نظرم اومد بهتره لیست بشن و در دسترس باشن که بعدا ببینم. برای همین این لیست رو تبدیل به 2 فایل کلی کردم که می تونین ازش برای تحقیق و جست و جو هم استفاده کنین. - https://docs.djangoproject.com/en/6.0/releases/5.0/ - https://docs.djangoproject.com/en/6.1/releases/5.1/ - https://docs.djangoproject.com/en/6.0/releases/5.2/ - https://docs.djangoproject.com/en/6.0/releases/6.0/ - https://docs.djangoproject.com/en/6.1/releases/6.1/ @thealibigdeli_channel #django

📚 یه منبع خوب برای یادگیری دنیای LLMها! اگه دنبال یه منبع نسبتاً جامع و در عین حال ساده برای آشنایی با تکنولوژی‌های کاربردی چند سال اخیر حوزه‌ی AI هستین، LLMs for Humans می‌تونه گزینه‌ی خیلی خوبی باشه. این کتاب بیشتر برای دولوپرها، تولیدکننده‌های محتوا و کسایی نوشته شده که به هر شکلی با محصولات AI-Powered سروکار دارن. از موضوعاتی مثل RAG، Agentها، Multimodalها، Context Engineering و کلی مفهوم دیگه صحبت می‌کنه که احتمالاً موقع کار با LLMها، چه به‌عنوان دولوپر و چه حتی کاربر، زیاد بهشون برمی‌خورین. نکته‌ی خوبش اینه که سعی کرده مفاهیم رو تا جای ممکن ساده و کاربردی توضیح بده؛ یعنی بیشتر روی چیزهایی تمرکز می‌کنه که واقعاً توی پروداکشن به کارتون میان. یکی از دوستان زحمت کشیده و کتابی با عنوان «مدل‌های زبانی به زبان آدمیزاد» منتشر کرده که سرفصل‌هاش خیلی نزدیک به همین کتابه. نمی‌دونم ترجمه‌ی مستقیمه یا بر اساس همین محتوا نوشته شده، ولی چیزی که دیدم، نسبتاً به‌روزه. 📎 فایل PDF فارسی رو هم همراه همین پست براتون گذاشتم. ❇️ @lnxpylnxpy

#میم عه میم مرتبط! @telenetchanel

#Decorator_Pattern #30_day_30_design_patterns_fire 🔥 روز نهم تعریف الگو: Decorator یه الگوی structural هست که بهت اجازه می‌ده رفتار جدید به یه object اضافه کنی، بدون اینکه کلاس اصلیش رو تغییر بدی یا از ارث‌بری (inheritance) استفاده کنی. کار اینطوریه که object اصلی رو داخل یه decorator می‌پیچی (wrap می‌کنی)، و اون decorator همون interface اصلی رو داره ولی قبل یا بعد از صدا زدن متد اصلی، یه کار اضافه انجام می‌ده. می‌تونی چندتا decorator رو هم روی هم بذاری و لایه‌لایه رفتار اضافه کنی. توضیح استفاده: وقتی می‌خوای رفتار یه object رو dynamically و در زمان اجرا گسترش بدی، بدون اینکه کلاس اصلی رو دست بزنی یا مجبور بشی برای هر ترکیب ممکن از ویژگی‌ها یه subclass جدا بسازی، Decorator دقیقاً همین مشکل رو حل می‌کنه. مثال معروف: یه سیستم سفارش قهوه که می‌تونی روی یه قهوه‌ی ساده، milk، sugar، caramel رو هرکدوم رو خواستی اضافه کنی. اگه بخوای برای هر ترکیب یه subclass بسازی (CoffeeWithMilk، CoffeeWithMilkAndSugar، ...) به همون class explosion که توی Bridge دیدیم می‌رسی. Decorator بهت اجازه می‌ده این ویژگی‌ها رو مثل لایه‌های پیاز روی هم بذاری. کد بدون پترن (مشکل‌دار): class Coffee: def cost(self): return 2.0 def description(self): return "Coffee" # برای هر ترکیب باید یه subclass جدید بسازی -> class explosion class CoffeeWithMilk(Coffee): def cost(self): return super().cost() + 0.5 def description(self): return super().description() + " + Milk" class CoffeeWithMilkAndSugar(CoffeeWithMilk): def cost(self): return super().cost() + 0.2 def description(self): return super().description() + " + Sugar" # اگه بخوای بدون milk فقط sugar داشته باشی، باز باید یه subclass جدید بسازی coffee = CoffeeWithMilkAndSugar() print(coffee.description(), "->", coffee.cost()) مشکل اینجاست که تعداد subclass ها با هر ترکیب جدید به‌صورت انفجاری زیاد می‌شه، و ترکیب‌های dynamically در زمان اجرا (مثلاً بر اساس انتخاب کاربر) عملاً غیرممکن می‌شه چون باید از قبل همه‌ی حالت‌ها رو به‌صورت subclass تعریف کرده باشی. کد با Decorator: from abc import ABC, abstractmethod class Coffee(ABC): @abstractmethod def cost(self) -> float: pass @abstractmethod def description(self) -> str: pass class SimpleCoffee(Coffee): def cost(self) -> float: return 2.0 def description(self) -> str: return "Coffee" # Base decorator - wraps a Coffee object and shares the same interface class CoffeeDecorator(Coffee): def __init__(self, coffee: Coffee): self._coffee = coffee def cost(self) -> float: return self._coffee.cost() def description(self) -> str: return self._coffee.description() class MilkDecorator(CoffeeDecorator): def cost(self) -> float: return super().cost() + 0.5 def description(self) -> str: return super().description() + " + Milk" class SugarDecorator(CoffeeDecorator): def cost(self) -> float: return super().cost() + 0.2 def description(self) -> str: return super().description() + " + Sugar" # Usage: هر ترکیبی که بخوای، در زمان اجرا و بدون subclass جدید coffee = SimpleCoffee() coffee = MilkDecorator(coffee) coffee = SugarDecorator(coffee) print(coffee.description(), "->", coffee.cost()) # Coffee + Milk + Sugar -> 2.7 # فقط sugar، بدون milk - بدون نیاز به هیچ subclass جدیدی just_sugar = SugarDecorator(SimpleCoffee()) print(just_sugar.description(), "->", just_sugar.cost()) # Coffee + Sugar -> 2.2 حالا هر ترکیبی از ویژگی‌ها رو می‌تونی در زمان اجرا و بر اساس انتخاب کاربر بسازی، بدون اینکه از قبل مجبور باشی یه subclass برای هر حالت ممکن تعریف کرده باشی. ✨ نکته: Decorator رو با inheritance ساده اشتباه نگیر. با inheritance ترکیب رفتارها در زمان compile و به‌صورت static مشخص می‌شه، ولی با Decorator می‌تونی در زمان runtime تصمیم بگیری چه لایه‌هایی رو به چه ترتیبی اضافه کنی. توی پایتون خیلی وقتا برای همین کار از decorator function ها (با @) هم استفاده می‌شه که مفهوم مشابهی داره ولی پیاده‌سازیش فرق می‌کنه؛ اینجا داریم از Decorator به‌عنوان یه design pattern شیءگرا صحبت می‌کنیم، نه syntax پایتون. @telenetchanel

#میم وضعیت ما! @telenetchanel

🌐 ایده واسه طراحی پسوورد😁 🆔 @rezadolati01

#Composite_Pattern #30_day_30_design_patterns_fire 🔥 روز هشتم تعریف الگو: Composite یه الگوی structural هست که به تو اجازه می‌ده object های تکی (leaf) و ترکیبی از اون object ها (composite) رو با یه interface یکسان مدیریت کنی. یعنی کلاینت کد فرقی نمی‌ذاره داره با یه object تنها کار می‌کنه یا با یه گروه بزرگ از object ها؛ همه رو یکسان و از طریق یه interface مشترک صدا می‌زنه. این pattern معمولاً برای ساختارهای درختی (tree structure) به کار می‌ره. توضیح استفاده: هر جا که یه ساختار سلسله‌مراتبی (hierarchy) از part-whole داری، یعنی چیزهایی که خودشون می‌تونن شامل چیزهای دیگه‌ای از همون نوع باشن، Composite دقیقاً همینجا به کارت میاد. مثال کلاسیک: سیستم فایل که فولدر می‌تونه شامل فایل باشه یا شامل فولدرهای دیگه، یا یه UI که یه panel می‌تونه شامل button و panel های دیگه باشه، یا منوی رستوران که یه دسته می‌تونه شامل غذا یا زیردسته‌های دیگه باشه. بدون Composite، کد کلاینت مجبوره همیشه چک کنه "این یه item تکیه یا یه گروهه؟" و این باعث پر شدن کد از if/else های تودرتو می‌شه. کد بدون پترن (مشکل‌دار): class File: def __init__(self, name, size): self.name = name self.size = size class Folder: def __init__(self, name): self.name = name self.children = [] # can contain File or Folder objects def get_total_size(item): # کلاینت مجبوره بفهمه با File طرفه یا با Folder if isinstance(item, File): return item.size elif isinstance(item, Folder): total = 0 for child in item.children: total += get_total_size(child) # recursive call, but logic is outside the class return total root = Folder("root") root.children.append(File("a.txt", 10)) sub = Folder("sub") sub.children.append(File("b.txt", 20)) root.children.append(sub) print(get_total_size(root)) # 30 مشکل اینجاست که منطق تشخیص نوع (File یا Folder) بیرون از کلاس‌ها و توی یه تابع جدا نوشته شده. هر تابع جدیدی که بخوایم روی این ساختار اضافه کنیم (مثل چاپ ساختار، شمارش فایل‌ها و...) باید دوباره همین if/else رو تکرار کنه. کد با Composite: from abc import ABC, abstractmethod # Common interface for both File (leaf) and Folder (composite) class FileSystemItem(ABC): @abstractmethod def get_size(self) -> int: pass class File(FileSystemItem): def __init__(self, name, size): self.name = name self.size = size def get_size(self) -> int: return self.size class Folder(FileSystemItem): def __init__(self, name): self.name = name self.children = [] # can hold File or Folder objects def add(self, item: FileSystemItem): self.children.append(item) return self def get_size(self) -> int: # doesn't care if child is a File or a Folder - same interface return sum(child.get_size() for child in self.children) # Usage: کلاینت با File و Folder دقیقاً یکسان رفتار می‌کنه root = Folder("root") root.add(File("a.txt", 10)) sub = Folder("sub") sub.add(File("b.txt", 20)) root.add(sub) print(root.get_size()) # 30 -> بدون هیچ isinstance یا if/else بیرونی حالا هر FileSystemItem، چه File باشه چه Folder پر از item های دیگه، دقیقاً با یه متد get_size() صدا زده می‌شه. کلاینت اصلاً نیازی نداره بدونه داره با یه leaf کار می‌کنه یا یه branch کامل از درخت. ✨ نکته: وقتی می‌خوای متد جدیدی مثل print_structure() یا count_files() اضافه کنی، فقط کافیه اون متد رو به FileSystemItem، File و Folder اضافه کنی؛ نیازی نیست جایی دیگه یه تابع recursive جدا بنویسی. این یکی از قدرت‌های اصلی Composite هست: منطق recursive داخل خود ساختار درختی زندگی می‌کنه، نه بیرون از اون. @telenetchanel