✅12factor

قبلا توی این پست در موردش نوشتم:
https://t.me/djangolearn_ir/78

اما بازم امروز از از Sider Fusion پرسیدم 12factor چیه؟ و ctrl + c بعدش ctrl + v 😁

یک سری اصول و الگوهایی است که برای توسعه و استقرار برنامه‌های وب مدرن طراحی شده‌اند. هدف آن کمک به توسعه‌دهندگان نرم‌افزار برای ساخت برنامه‌هایی است که مقیاس‌پذیر، پایدار و قابل نگهداری باشند. این اصول عبارتند از:

Codebase:
یک برنامه باید بر اساس یک کدبیس (codebase) واحد باشد که می‌تواند در محیط‌های متفاوت مانند توسعه، آزمایش و تولید عمل کند.

Dependencies:
برنامه باید تمام وابستگی‌ها را به‌طور واضح تعیین کرده و مستقل از سیستم عامل و محیط اجرا شود.

Config:
پیکربندی‌ها باید خارج از کد اصلی برنامه (در محیط) قرار گیرند تا قابلیت تغییر و مدیریت آسان‌تر شود.

Backing services:
هرگونه خدمات پشتیبان (مانند پایگاه داده، پیام‌رسان و ...) باید به‌عنوان منابعی از نوعی وابستگی در نظر گرفته شوند و راحت قابل تعویض باشند.

Build, release, run:
فرآیند توسعه باید به مرحله ساخت، انتشار و اجرا تفکیک شود.

Processes:
برنامه‌ها باید به‌صورت پروسه‌های بدون حفظ حالت (stateless) اجرا شوند.

Port binding:
برنامه باید به طور مستقل به پورت‌ها متصل شود و نیازی به خدمات خارجی برای راه‌اندازی نداشته باشد.

Concurrency:
برنامه باید از ویژگی همزمانی (concurrency) به خوبی بهره‌برداری کند.

Disposability:
برنامه‌ها باید به‌راحتی و سریع خاموش و روشن شوند.

Dev/prod parity:
محیط‌های توسعه و تولید باید مشابه یکدیگر باشند تا مشکلات ناشی از تفاوت‌ها کاهش یابد.

Logs:
لاگ‌ها باید به‌عنوان جریانی از رویدادها در نظر گرفته شوند و به‌صورت مرکزی مدیریت شوند.

Admin processes:
کارهای اداری و مدیریتی باید به‌صورت برنامه‌های یکباره (one-off) قابل اجرا باشند و به‌طور جداگانه از جریان اصلی برنامه اجرا شوند.

این اصول باعث می‌شوند که توسعه‌دهندگان برنامه‌هایی بسازند که نگهداری از آن‌ها ساده‌تر است و می‌توانند به راحتی مقیاس پذیر شوند.

✅فاکتور چهارم: Backing services

توضیحات از ویرگول Mohammad Ghodsian که لینکش بالاتر هست:

منظور از Backing services هر سرویسیه که برنامه حین روند طبیعی خودش از اونا استفاده میکنه. مثل دیتابیسها، راه‌های ارتباطی و ساز‌و‌کار‌های پیام‌محور (مثل ربیت یا حتی وب‌هوک‌ها)، چیزایی مثل سیستمِ کشینگ (مثل Memcached) یا هر سرویس دیگه‌ای که برنامه باهاش سر و کار داره. تمامی این سرویس‌ها باید روی بستر شبکه مثلاً به کمک آدرس‌دهی http قابل دسترس باشن، و تعیین‌کننده آدرس یا نحوه ارتباط همون کانفیگیه که به عنوان فاکتور سوم باهاش آشنا شدیم. عملاً هر کدوم از این موارد به عنوان ریسورس برنامه شناخته میشن، و چقدر خوبه که برنامه طوری نوشته شده باشه که اگه سیستم مَسِیجینگ خواست تغییر بکنه (مثلا از RabbitMQ به ZeroMQ) حتی‌المقدور با یه تغییر توی کانفیگ این امر محقق بشه (طبیعتاً نمیشه همه حالات مختلف رو در نظر گرفت ولی حدأقل میشه توی کد در نظر گرفت لایه‌ای که مثلاً وظیفه مسیجینگ رو مدیریت میکنه با کمتری تغییر ممکنه و به سرعت بتونه تغییرات لازمه رو اعمال کنه). یا به عنوان یه مثال دیگه، اگه به هر دلیلی مثلاً ادمین سیستم خواست دیتابیس رو تغییر بده (فرض کنید مشکلی برای دیتابیس فعلی بوجود اومده و برنامه خواست روی یه بک‌آپی که از دیتابیس قبلی گرفته شده و روی دیتابیس جدید نشسته ران بشه) نباید هیچ مشکلی بابت این قضیه بوجود بیاد و تغییر کد خاصی نباید صورت بگیره. این مورد نه فقط روی ورژن نهایی برنامه، بلکه در مورد تمامی deployهای برنامه صدق میکنه، به این مفهوم که برنامه نباید توی برنچ‌ها یا ورژنای مختلف، عملکردای متفاوتی نسبت به محیطی که داره روش ران میشه داشته باشه و اکثر عملکردها تنها وابستگیشون به ریسورسهاشون (که اینجا منظورمون همون backing service ها) هست باید صرفاً اطلاعاتی باشه که از کانفیگ و پارامترای سیستمی دریافت میکنن.

✅معرفی پکیج جنگویی dj-database-url
در راستای فاکتور Backing services

✔️این پکیج کاری میکنه که اطلاعات مربوط به اتصال به دیتابیس رو به سادگی از یه URL بگیریم. به‌جای استفاده از سری متغیرهای جداگانه (مثل NAME، USER، PASSWORD، HOST، PORT) با یه URL کارمون راه میافته.

✔️توی توضیحات خودش متن زیر رو نوشته، لذا لازم شد قبلش اشاره کنم به 12factor:
This simple Django utility allows you to utilize the 12factor inspired DATABASE_URL environment variable to configure your Django application.

لینک pypi:
https://pypi.org/project/dj-database-url/
لینک گیت هاب:
https://github.com/jazzband/dj-database-url

✔️آپدیت هم هست. و افراد زیادی روش کار کردن. 3 ایشو باز داره و 97 تا ایشو کلوز شده داره.

یه تخفیف واقعی و خیلی خوب برای پکیج برنامه نویسی پایتون دانشجویار

اون 15 میلیون شده 1.5 رو نادیده بگیرید. همه دارن این کارو میکنن

✔️فارغ از اینکه یکی از دوره های خودم هم توی پکیج هست، ولی واقعا این همه آموزش خیلی بیشتر از 1 و 500 ارزش دارن.

به نظرم از دست ندید

توی لینک زیر پیداش کنید:
https://www.daneshjooyar.com/blackfriday

به نظرم از دست ندید

با این تخفیف

دوره من شده کمتر از 190 هزار تومن 😱
بیش از 25 ساعت ویدئو برای این دوره ضبط کردم

✔️لذا تخفیفش واقعا خوبه

✅مصاحبه با مهندس میلاد غیاث بیگی، معمار نرم افزار و توسعه دهنده ارشد شرکت رایادرس
سر کلاس یازدهم توسعه برنامه سازی و پایگاه داده هنرستان دبیریان نازی آباد تهران

✔️ایشون تکنیکال لید شرکت رسمیو بوده
✔️هنرستانی بودن

لینک آپارات:
https://www.aparat.com/v/fwqf92h
لینک یوتیوب:
https://youtu.be/pW8uud6fFzY
✔️سوالهای زیر رو ازشون پرسیدیم:
چند سال دارید؟
دبیرستان بودید یا هنرستان؟ چه رشته ای؟
چه شرکت هایی کار کردید و چه سمتی داشتید؟
رمز موفقیت شما چی بوده؟
آیا مدرسه، دانشگاه میتونه به برنامه نویس خوب شدن کمک کنه؟
سوال دانش آموزها:
-اگر نسخه ۱۸ ساله خودشون رو ملاقات میکردن چه توصیه هایی بهشون میکردن و بهش چیا میگفتن؟
-نظر شما در مورد کارآموزی چیه؟
-نظرتون درباره واژه فول استک دولوپر چیه
-بهترین استک یا زبان برنامه نویسی کدومه؟
-چه مهارت یا ابزار یا تکنولوژی هایی لازمه که فارغ از زبان برنامه نویسی یاد بگیریم؟
-من اگه بخوام برنامه نویس بکند بشم. دیکه لازم نیست html css javascript یاد بگیرم؟

✔️ادیت ویدئو: علی اکبر غلامی - پایه یازدهم - رشته شبکه و نرم افزار رایانه

ضمن تشکر از دوستان

ویس دو تا ویدئو قبلی
این لینک ویدئوها

https://t.me/djangolearn_ir/939

https://t.me/djangolearn_ir/948

🙋🏽‍♂️ سلام وقت همگی بخیر!

🔥 همون‌طور که گفتم قرار بود که یه تخفیف خیلی خوب روی دوره صفر تا قهرمانیِ پایتون اِعمال بشه!

🤝🏼 قیمت با تخفیف: 1.599.000 تومان (599.000 تومان)

🎯 کد تخفیف : BF2024

🎯 لینک خرید دوره پایتون: https://zarinp.al/644119

🎯 ظرفیت : 50 نفر

------------------
📋 بعد از خرید تصویر رسید رو به آیدی زیر ارسال کنید تا دوره براتون اضافه بشه.

🙋🏻‍♂️ @izlearn_support

✅تست نویسی رو دستکم نگیرید
از کانال per3onal

برای اینکه تست بنویسید :

خیلی وقت بود جنگو کد نزده بودم و یک سری موارد رو فراموش کرده بودم (مواردی که مربوط میشه فقط و فقط به خود جنگو)
خیلی هم اعتقادی به TDD ندارم ولی معتقدم تست نویسی باید باشه؛ حالا که بحثش شد بذار بگم تا همین چندسال قبل بدون TDD کد نمیزدم؛ اما یک عیب بزرگ داشتم  TDD فقط و فقط وقتی درست عمل می‌کنه که شما تمام نیاز بیزینس رو بدونی و دقیقا بدونی چطور قراره از سیستم استفاده بشه.
حالا نگیم ۱۰۰٪ حداقل ۸۰٪ پروژه رو باید کامل بدونید؛ باگش در اومد دیگه بیزینسی جز بیزینس خودت وجود نداره که ۸۰٪ اش مشخص باشه. تغییرات بسیار است.

بگذریم؛ کد رو زدم و تموم شد و با Insomnia, bruno تستش کردم (bruno رو هنوز خیلی بلدش نیستم ولی باید یادبگیرم که خب درحال حاضر وقتش نیست برای همین رکوئست‌هایی که مهم نیست رو export-import میزنم بین این دوتا ابزار)
همه چیز به خوبی کار می‌کرد که رفتم سراغ تست نویسی؛ همه تست‌ها به خوبی کار می‌کرد جز یک مورد
یک generic.CreateAPIView یا views.APIView هرکاری میکردم توی یکی از تست‌های خاص جواب نمی‌داد جالبتر این بود که دقیقا همین تست توی Insomnia داشت جواب میداد؛ اونم بطور کامل و درست؛ دیباگر هم حتی هیچی نشون نمیداد.
من توی این Endpoint فقط می‌خواستم یک دیتایی رو دریافت کنم Deserialize کنم بعد با اون چیزی که توی دیتابیس دارم مقایسه کنم که یا تایید بدم یا ارور بدم.

خلاصه‌اش کنم:
نهایتا متوجه شدم روی model و یکی از فیلدها محدودیت unique=True گذاشتم و توی Insomnia دارم اون فیلد رو با دیتای متفاوتی از چیزی که توی دیتابیس ایجاد کردم صدا میزنم همینجا یادآوری شد که :

serializer.is_valid()

قبل از اینکه validate کاستوم شده شما رو اجرا کنه میره چک می‌کنه آیا دیتا رو اگر بخواد validate کنه دیتابیس بهش تایید میده یا نه.
(تابع نرمالایز کردن اون فیلد خاص رو من توی validate مربوط به serializer صدا میزدم؛ چون توی تمام فریمورک‌های استاندارد ولید کردن اول باید توی serializer صورت بگیره و محدودیت‌های دیتابیس Fallback هستند.)

خلاصه که چون توی تست‌هام از faker استفاده می‌کن (اینم خودش یک best practice هست که باید رعایت بشه) توی هر دو endpoint اون فیلد بصورت دقیقا یکسان ارسال می‌شد و باگ در اومد و با یک redesign کوچیک همه جیز درست شد.

اگر این تست نبود:
۱- من باقی بخش‌های پروژه رو با دیزاینی که باگ داشت کد زده بودم
۲- باگ خودش رو نشون نمی‌داد مگر توی stage, production توی محیط تست قطعا بازم با همین استاندارد که بذار normalization رو هم همزمان تست کنم همه چیز ادامه پیدا میکرد.
۳- درست کردن این باگ حتی اگر برای هفته بعدی هم می‌افتاد؛ حداقل ۵-۶ روزکاری زمان می‌برد تا مشکلش رو بتونیم حل کنیم.
بخاطر حجم داده و حجم کد و dependency هایی که بوجود میومد (چیزی که الان کمتر از ۱ ساعت وقت گرفت با یک redesign کامل)


تست نویسی رو دستکم نگیرید واقعا.

💎 ـPartial Functions در پایتون 💎

تا حالا شده یه تابع بنویسی که پر از آرگومان باشه و همیشه بخوای یه سری از اون آرگومان‌ها مقدار ثابتی داشته باشن؟ مثلا فرض کن توی یه پروژه مدام داری درخواست HTTP می‌فرستی و همیشه متد رو روی POST می‌ذاری. به جای تکرار این مقدار ثابت، Partial Functions به کمکت میان و کدتو خیلی حرفه‌ای‌تر می‌کنن.


🔎 ـPartial Functions چی هست؟

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

🧠 چرا Partial Functions مفیدن؟

✅ سادگی و تمیزی کد: به

جای تکرار، یه بار آرگومان ثابت رو تعریف می‌کنی.

✅ کاهش خطا:

آرگومان‌های ثابت توی یه جای مشخص مقداردهی می‌شن.

✅ ایجاد نسخه‌های شخصی‌سازی‌شده از توابع:

بدون نیاز به تعریف تابع جدید.

🛠️ چطور Partial Functions بسازیم؟

from functools import partial  

def multiply(x, y):  
    return x * y  

double = partial(multiply, y=2)  
print(double(5))  # خروجی: 10  

اینجا double نسخه‌ای از multiply شده که مقدار y همیشه 2 هست. فقط لازمه x رو بهش بدی.

🚀 کاربردهای Partial Functions

1⃣ ساده‌سازی توابع با آرگومان‌های زیاد
وقتی توابع زیادی با پارامترهای تکراری داری، Partial Functions می‌تونه کمکت کنه:

def send_request(method, url, headers, data):  
    # ارسال درخواست  
    pass  

post_request = partial(send_request, method='POST')  
post_request(url='/api/data', headers={}, data={})  
 

2⃣ انعطاف بیشتر با توابع دیگر
ـPartial Functions می‌تونه با توابعی مثل map و filter خیلی خوب کار کنه:

from functools import partial  

def power(base, exponent):  
    return base ** exponent  

square = partial(power, exponent=2)  

numbers = [1, 2, 3, 4]  
squared_numbers = list(map(square, numbers))  
print(squared_numbers)  # خروجی: [1, 4, 9, 16]  
 

3⃣ بهبود خوانایی کد در سیستم‌های بزرگ

وقتی پروژه‌هات پیچیده می‌شن، Partial Functions بهت کمک می‌کنن توابعی بسازی که واضح‌ترن:

from functools import partial  

def logger(log_level, message):  
    print(f"[{log_level}] {message}")  

info_logger = partial(logger, log_level='INFO')  
info_logger("This is an info message")  # خروجی: [INFO] This is an info message  

⚖️ مقایسه با دیگر روش‌ها
ـPartial Functions یه جایگزین سبک‌تر برای تعریف کلاس‌های خاص یا توابع جدیده. اما وقتی منطق خیلی پیچیده‌ای داری یا نیاز به شرط‌های مختلف هست، بهتره به جای Partial Functions از کلاس‌ها یا Wrapper Functions استفاده کنی.


✍️ جمع‌بندی
فهمیدیم Partial Functions ابزاری ساده اما قدرتمند در پایتون هستن که می‌تونن کدهای تکراری رو حذف کنن و انعطاف بالایی بهت بدن.

امید وارم مفید بوده باشه :)

#python #programing

🔆 CHANNEL | GROUP

این پست فعلا یه دیس لایک داره.
عالی میشه اگه دلیل دیسلایک رو بدونیم.

آیا چیزی که گفته ایراد داره؟

ویرایش:
دیس لایک ها زیاد شد. عجب

الوعده وفا!

بالاخره تمام شد. ۹ ماه پیش زمانی که ضبط دوره یادگیری عمیق را شروع کردم، قول دادم که بیش از ۱۰۰ ویدیو برای آن ضبط خواهم کرد. امروز تمام ویدیوها را می‌توانید از پلی‌لیست یوتیوب تماشا کنید. در مجموع حدود ۲۶ ساعت محتوا است و مباحث زیر را پوشش دادم:


Optimization Algorithm (SGD, Momentum, Nesterov, Adam, ...)
Deep Neural Networks
Convolutional Neural Networks
Residual Neural Networks
Transformer and Large Language Models
Autoencoder
Variational Autoencoder (VAEs)
Generative Adversarial Networks (GAEs)
Normalizing Flows
Diffusion Models
Graph Neural Networks (GNNs)
Reinforcement Learning

@golemcourse

پیکربندی لاگ زدن در جنگو - django logging

در این سری از ویدیوها که به ترفندها و نکته های جنگو میپردازیم، به سراغ لاگ زدن در جنگو رفتیم و کانفیگ ها و شیوه پیکربندی آن را از طریق بررسی و خواندن کد داخلی جنگو، شرح دادیم. در این ویدیو به جای کد نوشتن، بیشتر کد خوندیم که بفهمیم جنگو خودش برای لاگ زدن چگونه کار میکند و ما چگونه میتونیم از آن استفاده کنیم. همچنین امکان django logging را در سرویس های کلودی مانند sentry و APM هم مطرح کردیم. این مفاهیم رو در پروژه مینی ترلو به شکل عملی استفاده میکنیم.


video link: https://youtu.be/LGatKmpL7k8

playlist: https://www.youtube.com/playlist?list=PLJ9zDGwhhsBwdrfdaoOqbYev3_ocuBOfv

#django #logging #microfrontend_ir
〰️〰️〰️〰️〰️
©️ @DjangoEx

✅مصاحبه با Sadra Yahyapour تنها GitHub Campus Expert ایران
سر کلاس دوازدهم، تجارت الکترونیک
هنرستان شهید دبیریان محله نازی آباد تهران

لینک آپارات:
https://aparat.com/v/wkl8u79
لینک یوتیوب:
https://youtu.be/bxFeAh6ytVU

✔️صدرا یک مهندس نرم افزار ع Open Source Contributor هست
✔️و Technical Writer
✔️و علاقمند به Machine Learning هست و...

سوالهای زیر رو از Sadra پرسیدم:
✔️چطور دانشکده شمسی پور با رتبه خوب قبول شدی؟ چقدر درس خوندی؟
✔️چه شرکت هایی کار کردی؟
✔️داستان اوپن سورس چیه؟ و چطور میشه ازش پول در بیاریم؟
✔️چطور توی لینکدین و گیت هاب اسم در کردید؟
✔️دانشگاه دولتی یا آزاد فرقی اداره توی این مسیر؟
و...


کانال تلگرامی صدرا https://t.me/lnxpylnxpy

ویس مصاحبه با Sadra
کانال تلگرامی صدرا https://t.me/lnxpylnxpy

لینک ویدئوش
https://t.me/djangolearn_ir/960

توصیه های برادرانه من به شما


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

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


بخش اول اشتباه دوستمون این بود که مهندسی نرم افزار رو تو ابزار میدید. فک کنم در هیچ جای دنیا کسی مهندسی نرم افزار رو بر پایه ابزار تعریف نکنه.

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

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

متاسفانه اکثرا مهندسی نرم افزار رو به کد زدن محدود کردن در صورتی که کد، فقط بخشی از مهندسی نرم افزاره.
نتیجه این کار میشه برنامه های غیر قابل نگهداری و در نهایت شکست پروژه
مثل اکثر پروژه هایی که شکست خوردن و حتی پروژه هایی که شکست نخوردن اما در شرف شکست هستن.

مثلا در یکی از اپلیکیشن هایی که روزانه استفاده میکنیم، من اسمشو نمیارم اما فقدان رویکرد CICD بیداد میکنه و به شدت مشکل زا شده.

این اپلیکیشن حتی مشکل single point of failure داره. به این معنی که اگر یک بخش از سیستم بیاد پایین، کل سیستم میخوابه و عملا برای این موضوع فکر نشده و یا این که فکر شده اما بودجه محدود بوده یا هر چیز دیگه.

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