Forwarded from Milad Hatami
Media is too big
VIEW IN TELEGRAM
⭕️💢کافه جنگو💢⭕️
آموزش جنگو پایتون
جلسه : دوم
موضوع این جلسه: ارث بری در پایتون و ساخت اولین پروژه جنگو
رشته: فنی پایه 11 کتب جدید
پایه: 11 فنی و 11 و 12 کاردانش
درس: وب
سطح: متوسط
مدرس: مهندس حاتمی
🔻🔻🔻🔻🔻🔻
#کافه_دانش
#کافه_جنگو
#جلسه_2
#سطح_متوسط_پیشرفته
#توسعه_وب
#یادگیری_مفاهیم_وب
#دبیرخانه_کشوری_رایانه
#مستقر_در_استان_زنجان
#کانال_شاد_دبیرخانه_رایانه
@Yvt_computer
#کافه_دانش
t.me/Zncd_ir_Cafe
#آدرس_سایت_دبیرخانه_رایانه
ZNCD.ir
آموزش جنگو پایتون
جلسه : دوم
موضوع این جلسه: ارث بری در پایتون و ساخت اولین پروژه جنگو
رشته: فنی پایه 11 کتب جدید
پایه: 11 فنی و 11 و 12 کاردانش
درس: وب
سطح: متوسط
مدرس: مهندس حاتمی
🔻🔻🔻🔻🔻🔻
#کافه_دانش
#کافه_جنگو
#جلسه_2
#سطح_متوسط_پیشرفته
#توسعه_وب
#یادگیری_مفاهیم_وب
#دبیرخانه_کشوری_رایانه
#مستقر_در_استان_زنجان
#کانال_شاد_دبیرخانه_رایانه
@Yvt_computer
#کافه_دانش
t.me/Zncd_ir_Cafe
#آدرس_سایت_دبیرخانه_رایانه
ZNCD.ir
👍6🔥3❤2
جنگولرن
⭕️💢کافه جنگو💢⭕️ آموزش جنگو پایتون جلسه : دوم موضوع این جلسه: ارث بری در پایتون و ساخت اولین پروژه جنگو رشته: فنی پایه 11 کتب جدید پایه: 11 فنی و 11 و 12 کاردانش درس: وب سطح: متوسط مدرس: مهندس حاتمی 🔻🔻🔻🔻🔻🔻 #کافه_دانش #کافه_جنگو #جلسه_2 #سطح_متوسط_پیشرفته…
این ویدئو رو برای همکاران آموزش و پرورش ساختم.
کلاس به صورت آنلاین بود.
بیش از 45 نفر در کلاس شرکت داشتن. و استقبال خوبی شد، خداروشکر.
لینک آپارت این ویدئو:
https://www.aparat.com/v/tczby8h
ویدئو جلسه دوم - آپارات
سال آینده ظاهرا قراره پایتون و جنگو به کلاس 11 رشته شبکه و نرم افزار رایانه، فنی و حرفه ای اضافه بشه.
اگه نکته ای یا انتقادی دارید، توی کامنت ها بنویسید لطفا
کلاس به صورت آنلاین بود.
بیش از 45 نفر در کلاس شرکت داشتن. و استقبال خوبی شد، خداروشکر.
لینک آپارت این ویدئو:
https://www.aparat.com/v/tczby8h
ویدئو جلسه دوم - آپارات
سال آینده ظاهرا قراره پایتون و جنگو به کلاس 11 رشته شبکه و نرم افزار رایانه، فنی و حرفه ای اضافه بشه.
توی این ویدئو که برای همکاران هنرستانی برگزار شد، ارث بری در پایتون رو توضیح دادیم.
بعدش رفتیم سراغ نکاتی در مورد نصب جنگو و نسخه های جنگو
سپس venv مون رو ساختیم و بعد از نصب آخرین نسخه جنگو، پروژه رو ایجاد کردیم و اجراش کردیم.
سعی کردم مطالبی که توی این قسمت مطرح کردم، بیشتر ارتباط با جنگو رو داشته باشه.
توی این دوره قراره بر اساس کتاب Django 5 By Example پیش بریم. ولی مفاهیمی فراتر از کتاب رو قطعا پوشش خواهیم داد.
تمرکز این دوره بر پرسش و پاسخ خواهد بود. که بتونیم به همکاران راهنمایی بدیم.
اگه نکته ای یا انتقادی دارید، توی کامنت ها بنویسید لطفا
👏4❤1
جنگولرن
رفتار تابع id توی پایتون ضایع م کرد توی جلسه دوم آموزش جنگو برای همکاران هنرستان یه جا خواستم با تابع id یه مفهومی رو توضیح بدم اینو نوشتم: m = 10 m1 = 10 print(id(m)) print(id(m1)) خروجی هر دو print یه عدد شد. دلیلش رو می دونستید؟ لطفا 👎🏻 بزنید اگه نمی…
نظر فنی یکی از دوستان در مورد این پست:
سلام. خوندم کامنت ها رو، یک سری حرف های درست زده شده بود که به خودی خود درست هستن ولی وقتی کنار هم گذاشته میشدن ابهام ایجاد میشد که چرا اینجا پس نشد و بعد میرفت تو حدس و گمان هایی که اون جدس ها درست نبود.
جواب اون رفتار این پاراگراف از داکیومنت هست:
https://docs.python.org/3/reference/executionmodel.html#structure-of-a-program
A Python program is constructed from code blocks. A block is a piece of Python program text that is executed as a unit. The following are blocks: a module, a function body, and a class definition. Each command typed interactively is a block.
شما باید ببینید code block شما که به عنوان یک unit داره compile میشه چیه !
یکم عقب تر بیام، اینکه int های توی اون رنج موقع startup مفسر کش میشن یه حرف درسته و همه جا هم درسته. اینکه immutable type ها میتونن که share بشن (چون share شدنشون مشکل ساز نیست + مموری ذخیره میشه) حرف درستیه.
شما وقتی توی "شل" پایتون میزنید:
>>> a = 1000
>>> b = 1000
>>> a is b
False
>>> c = 999; d = 999
>>> c is d
True
به متن داکیومنت دقت کنید، الان توی a و b این ۲ تا توی ۲ تا code block یا unit مختلف هستن . از طرفی توی اون رنجی که همیشه کش میشن هم نیستن در نتیجه id ها فرق میکنه. توی c و d این ۲ تا باهم compile شدن. با اینکه توی اون رنج نیستن ولی یک آبجکت ساخته شده برای optimization.
یه مثال دیگه با code block عه فانکشن:
>>> def fn1():
... a = 1000
... b = 1000
... print("id of 'a'", id(a))
... print("id of 'b'", id(b))
...
>>> def fn2():
... c = 1000
... print("id of 'c'", id(c))
...
>>> fn1()
id of 'a' 2441294813616
id of 'b' 2441294813616
>>> fn2()
id of 'c' 2441294813264
>>>
اون 1000 ای که توی fn2 هست id ش یه چیزه. ولی توی fn1 هر دوتا یکی شدن.
حالا یه code block مرسوم چیه؟ ماژول! دلیل اینکه اون دوست توی ماژولش عدد خارج از اون رنج مینوشت و id ها یکی میشدن اینه که خب ماژول هم یه code block عه.
یه کامنت دیگه هم سعی کرده بودن با محاسبات این رو نقض کنن:
>>> e = 100 ; f = 10 ** 2
>>> e is f
True
یه چیزی تو پایتون هست به اسم peephole opmization (یکی از مراحل compile هست) این یکی از کارایی که میکنه میاد محاسبات رو انجام میده موقع کامپایل و دیگه ده به توان ۲ رو یک راست مینویسه ۱۰۰. پس این محاسبات رو میتونید literal تو کد بنویسید برای خوانایی. هیچ کاهش پرفورمنسی ندارید.
یه چیز دیگم که یادم رفت اضافه کنم اینا implementation detail هستن. ممکنه تو نسخه های مختلف تغییر کنه. ولی فرقی به حال ما که برنامه نویس هستیم نمیکنه چون کدی نمیزنیم که وابسته به این مدل رفتار ها باشه. صرفا دونستنش جالبه برای کسی که علاقه داره
سلام. خوندم کامنت ها رو، یک سری حرف های درست زده شده بود که به خودی خود درست هستن ولی وقتی کنار هم گذاشته میشدن ابهام ایجاد میشد که چرا اینجا پس نشد و بعد میرفت تو حدس و گمان هایی که اون جدس ها درست نبود.
جواب اون رفتار این پاراگراف از داکیومنت هست:
https://docs.python.org/3/reference/executionmodel.html#structure-of-a-program
A Python program is constructed from code blocks. A block is a piece of Python program text that is executed as a unit. The following are blocks: a module, a function body, and a class definition. Each command typed interactively is a block.
شما باید ببینید code block شما که به عنوان یک unit داره compile میشه چیه !
یکم عقب تر بیام، اینکه int های توی اون رنج موقع startup مفسر کش میشن یه حرف درسته و همه جا هم درسته. اینکه immutable type ها میتونن که share بشن (چون share شدنشون مشکل ساز نیست + مموری ذخیره میشه) حرف درستیه.
شما وقتی توی "شل" پایتون میزنید:
>>> a = 1000
>>> b = 1000
>>> a is b
False
>>> c = 999; d = 999
>>> c is d
True
به متن داکیومنت دقت کنید، الان توی a و b این ۲ تا توی ۲ تا code block یا unit مختلف هستن . از طرفی توی اون رنجی که همیشه کش میشن هم نیستن در نتیجه id ها فرق میکنه. توی c و d این ۲ تا باهم compile شدن. با اینکه توی اون رنج نیستن ولی یک آبجکت ساخته شده برای optimization.
یه مثال دیگه با code block عه فانکشن:
>>> def fn1():
... a = 1000
... b = 1000
... print("id of 'a'", id(a))
... print("id of 'b'", id(b))
...
>>> def fn2():
... c = 1000
... print("id of 'c'", id(c))
...
>>> fn1()
id of 'a' 2441294813616
id of 'b' 2441294813616
>>> fn2()
id of 'c' 2441294813264
>>>
اون 1000 ای که توی fn2 هست id ش یه چیزه. ولی توی fn1 هر دوتا یکی شدن.
حالا یه code block مرسوم چیه؟ ماژول! دلیل اینکه اون دوست توی ماژولش عدد خارج از اون رنج مینوشت و id ها یکی میشدن اینه که خب ماژول هم یه code block عه.
یه کامنت دیگه هم سعی کرده بودن با محاسبات این رو نقض کنن:
>>> e = 100 ; f = 10 ** 2
>>> e is f
True
یه چیزی تو پایتون هست به اسم peephole opmization (یکی از مراحل compile هست) این یکی از کارایی که میکنه میاد محاسبات رو انجام میده موقع کامپایل و دیگه ده به توان ۲ رو یک راست مینویسه ۱۰۰. پس این محاسبات رو میتونید literal تو کد بنویسید برای خوانایی. هیچ کاهش پرفورمنسی ندارید.
یه چیز دیگم که یادم رفت اضافه کنم اینا implementation detail هستن. ممکنه تو نسخه های مختلف تغییر کنه. ولی فرقی به حال ما که برنامه نویس هستیم نمیکنه چون کدی نمیزنیم که وابسته به این مدل رفتار ها باشه. صرفا دونستنش جالبه برای کسی که علاقه داره
Python documentation
4. Execution model
Structure of a program: A Python program is constructed from code blocks. A block is a piece of Python program text that is executed as a unit. The following are blocks: a module, a function body, ...
👏8❤1😁1🤮1
سخن بزرگان
ما توی الستیک سرچ دنبال سرچ ایم؟
نه ما دنبال relevancy هستیم.
یعنی نزدیک ترین جواب به جواب ما
ما توی الستیک سرچ دنبال سرچ ایم؟
نه ما دنبال relevancy هستیم.
یعنی نزدیک ترین جواب به جواب ما
👍14
Forwarded from tech-afternoon (Amin Mesbahi)
🧪 مفهوم و کاربرد API Mocking & Virtualization
خیلی از سردردها از نداشتن محیط اجرای مناسب نشأت می‌گیره؛ و خیلی از محیط خوب نداشتن‌ها از ترس پیچیده یا زمان‌بر بودنِ پیاده‌سازی. از طرف دیگه خیلی از integration ها با آسودگی و سرعت پیش نمی‌رن؛ چون API سیستمِ دیگه، شفاف نیست، یا محیط test نداره.
شنیدن جمله "منتظرم API شون آماده شه!" چیز غریب و نادری نیست! ولی واقعیت اینه که توی تیم‌های بالغ، منتظر نمی‌مونن، mock می‌کنن، یا قبل از توسعه API واقعی، اول API Spec رو می‌نویسن و در اختیار تیم‌های دیگه قرار می‌دن. اگر هم خیلی بالغ باشن که به جز API Spec ساز و کارkey management برای محیط‌های dev/test/stage/production رو هم محیا و ارائه می‌کنن.
بیاین در گام اول بیخیالِ میزان بلوغ تیم مقابل بشیم و خودمون رفتارهای بالغانه در تیم داشته باشیم:
مفهوم Mocking و Virtualization یعنی ساخت یه نسخه‌ی شبیه‌سازی‌شده از سرویس‌ها، قبل از اینکه backend واقعی در دسترس باشه. این کمک میکنه تا فرانت‌اند یا بکندی که API رو صدا میکنه، یا تست خودکار، و حتی هم‌زمانی توسعه بین تیم‌ها سریع‌تر بشه.
🚦 چرا مهمه؟
- کاهش وابستگی‌ها: تیم‌ها میتونن موازی کار کنن.
- بهبود تست و استیجینگ: سناریوهای خطا و پاسخ‌های خاص قابل بازسازی هستن.
- تکرارپذیری: تست‌ها بدون وابستگی به داده‌های زنده انجام میشن.
- پیشرفت بدون صبر: تا backend آماده بشه، frontend یا consumer هم رشد میکنه.
🧰 ابزارها
۱: ابزار Mockoon
رایگانه، دسکتاپ اپلیکیشن با رابط گرافیکی خوب است (نسخه مک و ویندوز داره) نسخه CLI هم داره.
۲: ابزار WireMock
یکی از بهترین ابزارها بود تا اینکه نسخه رایگان و پولی منتشر کرد! هنوز هم از نظر قابلیت‌ها ابزار خیلی خوبیه و مثلا rule-based mock، یا fault simulation رو خیلی خوب پشتیبانی میکنه.
۳: ابزار Microcks
هنوز به بلوغ WireMock نرسیده ولی ابزار خیلی خوبیه، یه UI وب ساده هم داره ولی هنوز کامل نیست (مثلا اینکه بتونید با UI انواع payloadها رو تعریف کنید یا chain بسازید رو نداره.
۴: ابزار (سرویس) Postman Mock Server
خب پست‌من دیگه برای همه شناخته شده است، ولی سرویس‌ها انترپرایزش نیاز به لایسنس داره چون نسخه رایگان همین mock server فقط ۳ کاربر رو پشتیبانی میکنه و محدودیت‌های زیادی داره.
چجوری payload رو محیا کنیم؟
۱. استخراج از مستندات موجود
اگر تیم backend مستندات OpenAPI/Swagger داره، راحت‌ترین راهه:
حتی اگر schema دقیق نباشه، حداقل مسیرها و ساختار پایه آماده‌ست.
۲. Sniff کردن درخواست‌ها در زمان کار
اگه endpointها در محیط تست یا staging یا جایی که بتونین حداقل یک بار صداشون کنین در دسترس هستن؛ ولی مستندات ندارن:
از Fiddler, Charles, یا mitmproxy یا ابزارهای مشابه استفاده کنید برای کپی کردن و استخراج درخواست‌ها و پاسخ‌ها. بعد اون‌ها رو به JSON تبدیل و برای mock استفاده کنین.
(یه snapshot واقعی از تعامل سیستم‌هاست)
۳. تولید خودکار مدل از JSON
وقتی چند تا نمونه JSON داری ولی model نه:
ابزارهای زیادی از جمله خود IDE های رایج سریع JSON رو به تایپ تبدیل می‌کنن و این کمک میکنه تا schema بسازین و بر اساس اون mock بنویسین.
۴. ساخت چند سناریو
فقط happy path رو mock نکن! یعنی اینکه همه چیز خیلی خوب و باب طبع باشه کافی نیست؛ سناریوهای مختلف مثل انواع خطاهای کد 4xx یا 5xx یا کندی‌ها یا تام‌اوت یا... رو هم در mockهات بسازین.
جمع‌بندی
فراموش نکنین که Mocking فقط یه کار “موقتی” نیست، یه مهارت توسعه‌ی تیمیه برای استقلال، سرعت و کیفیت. وقتی payloadها درست جمع‌آوری بشن، Mocking تبدیل میشه به پلی بین توسعه، تست و واقعیت سیستم.
💬 اگر موضوعاتی مثل Governance and Standardization یا API-First یا API Monitoring براتون جذاب بود حتمن بگید تا کمی در موردشون گپ بزنیم.
خیلی از سردردها از نداشتن محیط اجرای مناسب نشأت می‌گیره؛ و خیلی از محیط خوب نداشتن‌ها از ترس پیچیده یا زمان‌بر بودنِ پیاده‌سازی. از طرف دیگه خیلی از integration ها با آسودگی و سرعت پیش نمی‌رن؛ چون API سیستمِ دیگه، شفاف نیست، یا محیط test نداره.
شنیدن جمله "منتظرم API شون آماده شه!" چیز غریب و نادری نیست! ولی واقعیت اینه که توی تیم‌های بالغ، منتظر نمی‌مونن، mock می‌کنن، یا قبل از توسعه API واقعی، اول API Spec رو می‌نویسن و در اختیار تیم‌های دیگه قرار می‌دن. اگر هم خیلی بالغ باشن که به جز API Spec ساز و کارkey management برای محیط‌های dev/test/stage/production رو هم محیا و ارائه می‌کنن.
بیاین در گام اول بیخیالِ میزان بلوغ تیم مقابل بشیم و خودمون رفتارهای بالغانه در تیم داشته باشیم:
مفهوم Mocking و Virtualization یعنی ساخت یه نسخه‌ی شبیه‌سازی‌شده از سرویس‌ها، قبل از اینکه backend واقعی در دسترس باشه. این کمک میکنه تا فرانت‌اند یا بکندی که API رو صدا میکنه، یا تست خودکار، و حتی هم‌زمانی توسعه بین تیم‌ها سریع‌تر بشه.
🚦 چرا مهمه؟
- کاهش وابستگی‌ها: تیم‌ها میتونن موازی کار کنن.
- بهبود تست و استیجینگ: سناریوهای خطا و پاسخ‌های خاص قابل بازسازی هستن.
- تکرارپذیری: تست‌ها بدون وابستگی به داده‌های زنده انجام میشن.
- پیشرفت بدون صبر: تا backend آماده بشه، frontend یا consumer هم رشد میکنه.
🧰 ابزارها
۱: ابزار Mockoon
رایگانه، دسکتاپ اپلیکیشن با رابط گرافیکی خوب است (نسخه مک و ویندوز داره) نسخه CLI هم داره.
۲: ابزار WireMock
یکی از بهترین ابزارها بود تا اینکه نسخه رایگان و پولی منتشر کرد! هنوز هم از نظر قابلیت‌ها ابزار خیلی خوبیه و مثلا rule-based mock، یا fault simulation رو خیلی خوب پشتیبانی میکنه.
۳: ابزار Microcks
هنوز به بلوغ WireMock نرسیده ولی ابزار خیلی خوبیه، یه UI وب ساده هم داره ولی هنوز کامل نیست (مثلا اینکه بتونید با UI انواع payloadها رو تعریف کنید یا chain بسازید رو نداره.
۴: ابزار (سرویس) Postman Mock Server
خب پست‌من دیگه برای همه شناخته شده است، ولی سرویس‌ها انترپرایزش نیاز به لایسنس داره چون نسخه رایگان همین mock server فقط ۳ کاربر رو پشتیبانی میکنه و محدودیت‌های زیادی داره.
چجوری payload رو محیا کنیم؟
۱. استخراج از مستندات موجود
اگر تیم backend مستندات OpenAPI/Swagger داره، راحت‌ترین راهه:
curl https://api.company.com/openapi.json -o spec.json
mockoon-cli import --data spec.json
حتی اگر schema دقیق نباشه، حداقل مسیرها و ساختار پایه آماده‌ست.
۲. Sniff کردن درخواست‌ها در زمان کار
اگه endpointها در محیط تست یا staging یا جایی که بتونین حداقل یک بار صداشون کنین در دسترس هستن؛ ولی مستندات ندارن:
از Fiddler, Charles, یا mitmproxy یا ابزارهای مشابه استفاده کنید برای کپی کردن و استخراج درخواست‌ها و پاسخ‌ها. بعد اون‌ها رو به JSON تبدیل و برای mock استفاده کنین.
(یه snapshot واقعی از تعامل سیستم‌هاست)
۳. تولید خودکار مدل از JSON
وقتی چند تا نمونه JSON داری ولی model نه:
ابزارهای زیادی از جمله خود IDE های رایج سریع JSON رو به تایپ تبدیل می‌کنن و این کمک میکنه تا schema بسازین و بر اساس اون mock بنویسین.
۴. ساخت چند سناریو
فقط happy path رو mock نکن! یعنی اینکه همه چیز خیلی خوب و باب طبع باشه کافی نیست؛ سناریوهای مختلف مثل انواع خطاهای کد 4xx یا 5xx یا کندی‌ها یا تام‌اوت یا... رو هم در mockهات بسازین.
جمع‌بندی
فراموش نکنین که Mocking فقط یه کار “موقتی” نیست، یه مهارت توسعه‌ی تیمیه برای استقلال، سرعت و کیفیت. وقتی payloadها درست جمع‌آوری بشن، Mocking تبدیل میشه به پلی بین توسعه، تست و واقعیت سیستم.
Please open Telegram to view this post
VIEW IN TELEGRAM
Mockoon
Mockoon - Create mock APIs in seconds with Mockoon
Mockoon is the easiest and quickest way to run mock REST API servers. No remote deployment, no account required, free, open source and cross-platform.
❤2🆒2
Media is too big
VIEW IN TELEGRAM
گفتگو با سید محمد خشنوا برنامه نویس وب دیجی کالا
این گفتگو توی هنرستان انجام شد
توی این ویدئو با سید محمد خشنوا صحبت کردیم و به چندین سوال که از قبل براش فرستاده بودیم، پاسخ داد.
بعدش سوالات دانش آموزهارو پاسخ داد. البته بخش سوالهارو به دلیل رعایت حریم خصوصی دانش آموزان اجازه نداشتم ضبط کنم.
سید محمد خشنوا برنامه نویس وب دیجی فای زیرمجموعه دیجی کالا هست.
هنرستان شهید دبیریان در منطقه 16 تهران و محله نازی آباد تهران هست.
لینک ویدئو در آپارات:
https://www.aparat.com/v/ccl5kc1
لینک ویس این گفتگو:
https://t.me/djangolearn_ir/1193
لینک کانال سید محمد خشنوا:
https://t.me/seyed_bax
ویس این گفتگو هم توی پست بعدی میزارم
این گفتگو توی هنرستان انجام شد
توی این ویدئو با سید محمد خشنوا صحبت کردیم و به چندین سوال که از قبل براش فرستاده بودیم، پاسخ داد.
بعدش سوالات دانش آموزهارو پاسخ داد. البته بخش سوالهارو به دلیل رعایت حریم خصوصی دانش آموزان اجازه نداشتم ضبط کنم.
سید محمد خشنوا برنامه نویس وب دیجی فای زیرمجموعه دیجی کالا هست.
هنرستان شهید دبیریان در منطقه 16 تهران و محله نازی آباد تهران هست.
لینک ویدئو در آپارات:
https://www.aparat.com/v/ccl5kc1
لینک ویس این گفتگو:
https://t.me/djangolearn_ir/1193
لینک کانال سید محمد خشنوا:
https://t.me/seyed_bax
ویس این گفتگو هم توی پست بعدی میزارم
🔥7❤2
Forwarded from Code With HSN
چرا شرکت‌های بزرگ از Object Storage استفاده می‌کنند؟ (در 14 دقیقه)
در این ویدیو به زبون ساده توضیح میدم چرا Object Storageهایی مثل S3 و MinIO ساخته شدن و چطور شرکت‌های بزرگی مثل دیجی‌کالا، اسنپ و آمازون ازش استفاده می‌کنن.
اگر تا حالا برات سوال بوده S3 دقیقا چیه یا چطور MinIO باهاش سازگاره، این ویدیو رو ببین.
00:00 مشکل چی‌بود ObjectStorage خلق شد
04:32 نحوه ارتباط سرویس ها روی Diagram
06:20 کاربرد AWS S3 یا MinIO بیشتر است؟
07:14 ارسال یک آبجکت به AWS S3
10:39 سازگاری MinIO با S3
13:23 معرفی SDK اختصاصی MinIO
برای مشاهده ویدیو بیاید یوتیوب 🤫
پلی لیست: Cloud & Architecture Series
مدت زمان ویدیو: 14 دقیقه
مسیر طولانی با یه قدم شروع میشه. روز خوبی داشته باشید 🫂
در این ویدیو به زبون ساده توضیح میدم چرا Object Storageهایی مثل S3 و MinIO ساخته شدن و چطور شرکت‌های بزرگی مثل دیجی‌کالا، اسنپ و آمازون ازش استفاده می‌کنن.
اگر تا حالا برات سوال بوده S3 دقیقا چیه یا چطور MinIO باهاش سازگاره، این ویدیو رو ببین.
00:00 مشکل چی‌بود ObjectStorage خلق شد
04:32 نحوه ارتباط سرویس ها روی Diagram
06:20 کاربرد AWS S3 یا MinIO بیشتر است؟
07:14 ارسال یک آبجکت به AWS S3
10:39 سازگاری MinIO با S3
13:23 معرفی SDK اختصاصی MinIO
برای مشاهده ویدیو بیاید یوتیوب 🤫
پلی لیست: Cloud & Architecture Series
مدت زمان ویدیو: 14 دقیقه
مسیر طولانی با یه قدم شروع میشه. روز خوبی داشته باشید 🫂
❤5🔥3✍2👍2👏2🆒1
Code With HSN
چرا شرکت‌های بزرگ از Object Storage استفاده می‌کنند؟ (در 14 دقیقه) در این ویدیو به زبون ساده توضیح میدم چرا Object Storageهایی مثل S3 و MinIO ساخته شدن و چطور شرکت‌های بزرگی مثل دیجی‌کالا، اسنپ و آمازون ازش استفاده می‌کنن. اگر تا حالا برات سوال بوده S3 دقیقا…
درسته که توی بخش کوچیکی از ویدئو داره کد سی شارپ مینویسه.
اما 99 درصد ویدئو مفاهیم هست و ربطی به زبان برنامه نویسی نداره.
اینم یه پکیج پایتونی minio
https://pypi.org/project/minio-py3/
اینم خود minio
https://www.min.io/
راستی لیارا، آروان، ایران سرور و... این سرویس Object Storage ع S3 رو دارن
اگه توی پایتون در این مورد تجربه ای داری کامنت کن لطفا
مثلا ابزار جایگزین میشناسی یا...
تشکر از تو
اما 99 درصد ویدئو مفاهیم هست و ربطی به زبان برنامه نویسی نداره.
اینم یه پکیج پایتونی minio
https://pypi.org/project/minio-py3/
اینم خود minio
https://www.min.io/
راستی لیارا، آروان، ایران سرور و... این سرویس Object Storage ع S3 رو دارن
اگه توی پایتون در این مورد تجربه ای داری کامنت کن لطفا
مثلا ابزار جایگزین میشناسی یا...
تشکر از تو
👍3❤1
سوال یکی از دوستان (اگه می دونید، راهنمایی ش کنید):
سلام خسته نباشید کتاب خوب برای جنگو چی پیشنهاد میکنید که عالی باشه !؟ و ترجمه خوبی داشته باشه و همه ساختار های جنگو رو پوشش بده
سلام خسته نباشید کتاب خوب برای جنگو چی پیشنهاد میکنید که عالی باشه !؟ و ترجمه خوبی داشته باشه و همه ساختار های جنگو رو پوشش بده
Forwarded from Milad Hatami
Media is too big
VIEW IN TELEGRAM
⭕️💢کافه جنگو💢⭕️
آموزش جنگو پایتون
جلسه : سوم
موضوع این جلسه: ساختار جنگو، ساخت اولین اپ و آشنایی با urls
رشته: فنی پایه 11 کتب جدید
پایه: 11 فنی و 11 و 12 کاردانش
درس: وب
سطح: متوسط
مدرس: مهندس حاتمی
🔻🔻🔻🔻🔻🔻
#کافه_دانش
#کافه_جنگو
#جلسه_3
#سطح_متوسط_پیشرفته
#توسعه_وب
#یادگیری_مفاهیم_وب
#دبیرخانه_کشوری_رایانه
#مستقر_در_استان_زنجان
#کانال_شاد_دبیرخانه_رایانه
@Yvt_computer
#کافه_دانش
t.me/Zncd_ir_Cafe
#آدرس_سایت_دبیرخانه_رایانه
ZNCD.ir
آموزش جنگو پایتون
جلسه : سوم
موضوع این جلسه: ساختار جنگو، ساخت اولین اپ و آشنایی با urls
رشته: فنی پایه 11 کتب جدید
پایه: 11 فنی و 11 و 12 کاردانش
درس: وب
سطح: متوسط
مدرس: مهندس حاتمی
🔻🔻🔻🔻🔻🔻
#کافه_دانش
#کافه_جنگو
#جلسه_3
#سطح_متوسط_پیشرفته
#توسعه_وب
#یادگیری_مفاهیم_وب
#دبیرخانه_کشوری_رایانه
#مستقر_در_استان_زنجان
#کانال_شاد_دبیرخانه_رایانه
@Yvt_computer
#کافه_دانش
t.me/Zncd_ir_Cafe
#آدرس_سایت_دبیرخانه_رایانه
ZNCD.ir
👍3❤1
جنگولرن
⭕️💢کافه جنگو💢⭕️ آموزش جنگو پایتون جلسه : سوم موضوع این جلسه: ساختار جنگو، ساخت اولین اپ و آشنایی با urls رشته: فنی پایه 11 کتب جدید پایه: 11 فنی و 11 و 12 کاردانش درس: وب سطح: متوسط مدرس: مهندس حاتمی 🔻🔻🔻🔻🔻🔻 #کافه_دانش #کافه_جنگو #جلسه_3 #سطح_متوسط_پیشرفته…
ویدئو جلسه سوم - ساختار جنگو، ساخت اولین اپ و آشنایی با urls
لینک آپارت این ویدئو:
https://aparat.com/v/itu3kk2
این ویدئو رو برای همکاران آموزش و پرورش ساختم.
کلاس به صورت آنلاین بود.
بیش از 30 نفر در کلاس شرکت داشتن. و استقبال خوبی شد، خداروشکر.
اگه نکته ای یا انتقادی دارید، توی کامنت ها بنویسید لطفا
یا به @miladhzz پیام بدید
لینک آپارت این ویدئو:
https://aparat.com/v/itu3kk2
این ویدئو رو برای همکاران آموزش و پرورش ساختم.
کلاس به صورت آنلاین بود.
بیش از 30 نفر در کلاس شرکت داشتن. و استقبال خوبی شد، خداروشکر.
توی این ویدئو که برای همکاران هنرستانی برگزار شد، اولین اپلیکیشن جنگو رو ساختیم.
ابتدا با جداول جنگو در دیتابیس sqlite آشنا شدیم. بعدش رفتیم سراغ ORM جنگو و در ادامه تونستیم لیست کاربران و همچنین جزییات کاربر رو نمایش بدیم.
با مثال کاربران با urls و templates آشنا شدیم. و فهمیدیم که هر اپ میتونه اجزای مخصوص خودش رو داشته باشه.
آخر کلاس هم پرسش و پاسخ داشتیم.
توی این دوره قراره بر اساس کتاب Django 5 By Example پیش بریم. ولی مفاهیمی فراتر از کتاب رو قطعا پوشش خواهیم داد.
تمرکز این دوره بر پرسش و پاسخ خواهد بود. که بتونیم به همکاران راهنمایی بدیم.
اگه نکته ای یا انتقادی دارید، توی کامنت ها بنویسید لطفا
یا به @miladhzz پیام بدید
👏4❤1
مسیر ساخت WAF در ترب؛ نگاهی به چالش‌ها و تجربه‌های به‌دست آمده
مسیر طراحی و پیاده‌سازی WAF در ترب، سفری بود از ابزارهای آماده و متنوع تا ساخت یک سیستم اختصاصی و متناسب با نیازهای خودمان. در ابتدا با راه‌حل‌هایی مانند OPNsense و iptables تلاش کردیم تا جلوی درخواست‌های مشکوک را بگیریم. این روش‌ها ساده و سریع بودند، اما در مقیاس بالا مشکلاتی مثل کندی، دشواری در عیب‌یابی و محدودیت در نمایش خطا به کاربر داشتند.
در ادامه، با استفاده از Traefik سعی کردیم کنترل ترافیک را به لایه‌ی ۷ منتقل کنیم تا بتوانیم رفتار کاربران را دقیق‌تر تحلیل کنیم و در صورت نیاز، با نمایش چالش (challenge) از صحت درخواست‌ها مطمئن شویم. این روش هر چند مزیت‌هایی داشت، اما در برابر رشد ترافیک و حملات DDoS پایداری کافی نداشت و نگهداری از قوانینش در مقیاس بالا سخت بود.
در نهایت، با مهاجرت به Envoy و توسعه‌ی سیستمی بر پایه‌ی فیلتر External Processing، امکان پیاده‌سازی WAF برای ترب فراهم شد. در این معماری جدید، وظایف مدیریت قوانین و اعمال قوانین از هم جدا شدند (control plane و data plane)، قوانین با ساختاری ساده ولی کارآمد مدیریت می‌شوند، و عملکرد سیستم در تست‌ها نشان داد که افزایش زمان پاسخ‌گویی ناچیز و قابل قبول است.
استفاده از فرمت mmdb برای ذخیره‌ی قوانین IP باعث شد تا مصرف منابع به شکل چشم‌گیری کاهش یابد و انتقال قوانین از control plane به data plane سریع‌تر انجام شوند. به این ترتیب، WAF جدید توانست بدون فدا کردن سرعت یا پایداری، جایگزین مناسب و قابل توسعه‌ای برای زیرساخت‌های قبلی باشد.
در مجموع، این تجربه برای تیم ما تنها ساخت یک ابزار امنیتی نبود، بلکه گامی در جهت یادگیری، بهینه‌سازی و ساخت زیرساخت‌هایی بود که در برابر چالش‌های آینده مقاوم‌تر باشند.
لینک پست
مسیر طراحی و پیاده‌سازی WAF در ترب، سفری بود از ابزارهای آماده و متنوع تا ساخت یک سیستم اختصاصی و متناسب با نیازهای خودمان. در ابتدا با راه‌حل‌هایی مانند OPNsense و iptables تلاش کردیم تا جلوی درخواست‌های مشکوک را بگیریم. این روش‌ها ساده و سریع بودند، اما در مقیاس بالا مشکلاتی مثل کندی، دشواری در عیب‌یابی و محدودیت در نمایش خطا به کاربر داشتند.
در ادامه، با استفاده از Traefik سعی کردیم کنترل ترافیک را به لایه‌ی ۷ منتقل کنیم تا بتوانیم رفتار کاربران را دقیق‌تر تحلیل کنیم و در صورت نیاز، با نمایش چالش (challenge) از صحت درخواست‌ها مطمئن شویم. این روش هر چند مزیت‌هایی داشت، اما در برابر رشد ترافیک و حملات DDoS پایداری کافی نداشت و نگهداری از قوانینش در مقیاس بالا سخت بود.
در نهایت، با مهاجرت به Envoy و توسعه‌ی سیستمی بر پایه‌ی فیلتر External Processing، امکان پیاده‌سازی WAF برای ترب فراهم شد. در این معماری جدید، وظایف مدیریت قوانین و اعمال قوانین از هم جدا شدند (control plane و data plane)، قوانین با ساختاری ساده ولی کارآمد مدیریت می‌شوند، و عملکرد سیستم در تست‌ها نشان داد که افزایش زمان پاسخ‌گویی ناچیز و قابل قبول است.
استفاده از فرمت mmdb برای ذخیره‌ی قوانین IP باعث شد تا مصرف منابع به شکل چشم‌گیری کاهش یابد و انتقال قوانین از control plane به data plane سریع‌تر انجام شوند. به این ترتیب، WAF جدید توانست بدون فدا کردن سرعت یا پایداری، جایگزین مناسب و قابل توسعه‌ای برای زیرساخت‌های قبلی باشد.
در مجموع، این تجربه برای تیم ما تنها ساخت یک ابزار امنیتی نبود، بلکه گامی در جهت یادگیری، بهینه‌سازی و ساخت زیرساخت‌هایی بود که در برابر چالش‌های آینده مقاوم‌تر باشند.
لینک پست
ویرگول
مسیر ساخت WAF در ترب؛ نگاهی به چالش‌ها و تجربه‌های به‌دست آمده
مروری بر چگونگی اعمال محدودیت برای درخواست‌های مشکوک در ترب
❤3✍3
Forwarded from tech-afternoon (Amin Mesbahi)
توسعه‌ی نرم‌افزار رو میشه مثل ساختمون، بدون نقشه و طرح معماری ساخت! نگید نمیشه؛ چون خیلیا می‌سازن و شده! 😂 تیم‌ها شروع می‌کنن به دیوارکشی (توسعه فرانت‌اند و بک‌اند)، ولی وقتی می‌رسن به اتصالات (Integration)، می‌بینن لوله‌کشی و سیم‌کشی (API) شبیه خونه‌ی پت‌ومت در اومده که از پریز برق آب میاد، لوله برق داره یا درِ پارکینگ به جای کوچه، به پذیرایی همسایه باز میشه؛ ساختمونه هم بین ساختمون‌های مجاورش شبیه جوجه کلاغ وسط صد تا جوجه اردکه!
رویکرد سال‌های دور (دلار هزار تومنی) این بود که API یه "محصول جانبی" برای ارتباط با سایر سیستم‌ها محسوب میشد؛ یعنی اول بک‌اند نوشته میشد، بعد یه قسمتی از اون رو به‌صورت API در معرض استفاده قرار می‌دادن. ریشه‌های این روش، عموما توی خاک سیستم‌های داده‌محور (Data-First) رشد می‌کرد؛ و کمتر "مصرف‌کننده‌محور" (Consumer-Centric) بود.
از طرفی زیاد دیدیم که تیم‌ها معطل هم برای آماده شدن API می‌مونن! یا اعصابشون سر تغییراتی که تیم مقابل روی APIهاش بعد از تفاهم اولیه داده خورد میشه! فرانت می‌گه "API تون درست کار نمیکنه"، بکند می‌گه "شما درست صداش نمی‌زنین"، و QA هم وسط این دعوا نرخ تعیین میکنه! یه بخش بزرگ از این سردردها از نداشتن یه زبون مشترک و قرارداد واضح بین تیم‌هاست.
از طرف دیگه، خیلی وقت‌ها می‌بینیم که بکند کدش رو نوشته، بعد مستندات رو مینویسه، بعد معلوم میشه مصرف‌کننده یه چیز دیگه می‌خواسته! حالا برگردیم و دوباره بنویسیم؟ یا همینجوری با کثیف‌کاری وصلش کنیم؟ شنیدن جمله "ما بعداً مستندات رو کامل می‌کنیم!" چیز غریب و نادری نیست! ولی واقعیت اینه که توی تیم‌های بالغ، اول API Spec رو می‌نویسن، بعد کد. اگر هم خیلی بالغ باشن، این Spec رو به عنوان یه قرارداد (Contract) بین تیم‌ها در نظر می‌گیرن و با ابزارهای خودکار، صحت پیاده‌سازی و انطباق عینی با طرح و نقشه‌ی اولیه رو کنترل می‌کنن.
🧭 مفهوم API-First یعنی چی؟
مفهوم API-First یعنی قبل از نوشتن کد، اول API رو طراحی کنیم (عموما توسط معمار این اتفاق می‌افته) یعنی بشینیم، فکر کنیم، بنویسیم که چه endpointهایی داریم، چه input/output هایی، چه status codeهایی، چه headerهایی... و همه‌ی این‌ها رو توی یه فایل OpenAPI Spec یا مشابهش ثبت کنیم.
این یعنی API ما از ابتدا مستند شده، با بیزنس، با پروداکت، با تیم‌های همکار میشه سناریوسازی و مرور کرد؛ تغییر داد و منطبقش کرد با نیاز واقعی؛ و بعد به کد! بعتر هم برای تغییرات، اول API Spec تغییر میکنه و بعد کد. چه اتفاق میوفته؟
- پیش‌بینی‌پذیری: همه می‌دونن قراره چه داده‌ای رد و بدل بشه.
- موازی‌سازی توسعه: تیم‌های مختلف میتونن هم‌زمان پیش برن؛ یکی Mock بسازه، یکی پیاده‌سازی واقعی.
- مستندسازی خودکار: چون API از اول با استانداردهایی مثل OpenAPI تعریف میشه، مستندات همیشه با واقعیت هم‌راستا می‌مونن.
- کیفیت بالاتر: چون قبل از کدنویسی، درباره طراحی و naming و consistency فکر می‌کنی.
اینطوری API Spec شما اولا توی سورس‌کنترل نگهداری میشه، همواره نسخه تست، استیج رو به صورت live در دسترسی داریم، API Owner هر دامنه مشخصه؛ هر کی عشقش کشید به هر شکلی یه API نمی‌نویسه، breaking changeها و کانفلیکت‌ها قبل از تغییر در API آشکار میشن و کلی مزیت دیگه که از حوصله پست تلگرامی خارجه.
رویکرد API-First فقط یک روش نیست، یک تغییر فرهنگی در سازمان، و تغییر استراتژیک در توسعه نرم‌افزاره. این رویکرد، API رو از یک "افزونه" به یک "محصول اصلی" تبدیل میکنه که برای تجربه توسعه‌دهنده، سرعت و کیفیت نهایی خیلی حیاتیه. وقتی API-First باشیم، سیستم‌های ما در برابر تغییرات مقاوم‌تر، انعطاف‌پذیرتر و آماده‌تر برای Integration Economy خواهند بود. یکی از شرکت‌هایی که بر اساس رویکرد API First کار میکنه زالاندو است که اتفاقا خیلی سخاوتمندانه، یا به توصیف دقیق‌تر، هوشمندانه، دستورالعمل و راهنمای خودش رو سال‌هاست به صورت کدباز منتشر کرده و به نظر من بسیار مستند پخته و خوبیه.
پیشنهاد می‌کنم API رو با ساده‌سازی‌هایی که go, fastAPI, flask, .NET یه موضوع خیلی ساده نبینیم، طراحی و نگهداری بد، مصیبت‌های خودش رو در بلندمدت نشون میده، موقع اینتگریشن‌های بعدی نشون میده و اون وقته که متوجه می‌شیم ای کاش از ابتدا مشورت گرفته بودیم و صرف «کار کردن» API به خودمون نمره قبولی نمی‌دادیم! حتمن این روش پرهزینه‌تر و نیازمند زمان آماده‌سازی و توسعه بیشتریه، ولی عملا سرمایه‌گذاری زمان رشد و اینتگریشن خواهد بود.
Zalando RESTful API and Event Guidelines
Please open Telegram to view this post
VIEW IN TELEGRAM
✍7👍4