✅ در این ویدیو راجع به ۱۰ اشتباهی صحبت میکنیم که معمولا آدم ها موقع کار با داکر مرتکب میشن و این اشتباهات میتونه مشکلات بزرگی رو به وجود بیاره.

در این ویدیو (قسمت اول) به موارد زیر میپردازیم:
1. Root User
2. Latest Tag
3. dockerignore File
4. Multiple Runtime Processes
5. Secrets

🖥 مشاهده در یوتوب
👉 Link: https://youtu.be/XDGOyJ_vM38?si=H3F6Vp_TLOlc5mF8

〰️〰️〰️〰️〰️〰️
@BobyDotCloud

✅ پستی از لینکدین Mohammad Azad
✔️ با اینکه استک دات نت هست. اما یه بحث کلی نرم افزاری ع و مطالعه نظرات پستش میتونه برای هر کسی مفید باشه
آپدیت: چندتا از نظرات خوبش رو کامنت کردم

یک سوال چالشی دارم می خوام ببینم نظر اهل فن چیه و کدوم دیدگاه جوابش منطقی تره 😄
یک دست خط فراگیر در کامیونیتی نرم افزار وجود داره که احتمالا همه دوستان دیدن
اونم اینه که برای Application Service Layer همیشه یک اینترفیس تعریف میکنند و بعد در یک کلاس جدا اون اینترفیس پیاده سازی میشه.

سوالی که دارم اینه با این نوع طراحی برای Application Service Layer موافق هستید یا خیر؟

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

https://www.linkedin.com/posts/azadmt_%DB%8C%DA%A9-%D8%B3%D9%88%D8%A7%D9%84-%DA%86%D8%A7%D9%84%D8%B4%DB%8C-%D8%AF%D8%A7%D8%B1%D9%85-%D9%85%DB%8C-%D8%AE%D9%88%D8%A7%D9%85-%D8%A8%D8%A8%DB%8C%D9%86%D9%85-%D9%86%D8%B8%D8%B1-%D8%A7%D9%87%D9%84-activity-7130124705625223169-PFDx?utm_source=share&utm_medium=member_desktop

برای دانشجویان درس تحلیل و طراحی سیستم‌ها، یک نمونه سوال امتحانی طراحی کردم که برای اعضای این کانال نیز مفید است. پیشنهاد می‌کنم که به راه‌حل آن فکر کنید.
@golemcourse

خوش به حال دانشجوهاش
واقعا باید قدر این استادشون رو بدونن 👏👏👏
توی دانشگاه داره دانشی یادشون میده که دقیقا خوراک بازار کار هست

چسب زخم های دنیای نرم‌افزار
✅ مطلبی از لینکدین Ali Mahmoodi


بیشتر بئست پرکتیس‌هایی که امروزه در نرم‌افزار مشاهده می‌کنیم چه در سطح معماری چه در سطح کد برگرفته از دو یا سه مقاله‌ای هست که در سالهای ۱۹۶۰ تا ۱۹۸۰ میلادی نوشته شده.
بیشتر مهندسین نرم‌افزار آموزش رو با اصول سالید آغاز می‌کنند در حالی قبل سال دو هزار هنوز اقای روبرت مارتین این اصول رو تدوین نکرده بود و قبل از ایشون دنیای نرم‌افزار از دو اصل انسجام و وابستگی استفاده می‌کردند به غیر از این دو، ذات نرم‌افزار رو قابل تغییر و پیچیده تعریف و اثبات کرده بودند.
اگر از نوشته بالا یه استنباط کنیم میتوانیم بگویم اصل تک وظیفه‌گی و باز و بسته در سالید در اصل جزیی از انسجام می‌باشد و اصل معکوس کردن وابستگی در صدد حل مشکل وابستگی هست که قبل سال دو هزار آن را می‌دانستیم...
از این رو بحث قابل تغییر بودن نرم‌افزار باعث شد شی‌گرا از طریق کپسوله سازی اون رو حل بکنه و فانکشنال پروگرمینگ با متغیرهای غیر قابل تغییر، حذف استئت‌ها، فانکشن‌های شهروند درجه یک... هر دو روش بجای قبول کردن مشکل در حال حذف مشکل هستند و حین حذف کلی پیچیدگی و سختی به کار اضافه میکند!! سوالی که پیش میاد چرا بعد از گذشت چهار دهه راحل مناسبی برای این مشکلات ارایه نشده و برعکس کلی سرپوش یا چسب زخم برای این مشکلات درست میکنند ولی هنوز خون ریزی ادامه داره!!! مثلا بحث دامین دریون دیزاین میگه هر دامین اطلاعات مربوط به خودش رو بدونه که باز بحث انسجام هست و بحث بعدی کنترل بر روی تغییر! دنبال این هست که تغییر به صورت کنترل شده در یک نقطه متمرکز بشه تا باگ‌های ناخواسته پیش نیاد این هم باز پیچیدگی دیگری به سیستم اضافه میکند...
مشکلات و پیچیدگی که این روش‌ها در صدد حلش هستند باعث شده چندین دیزاین پترن و چندین پترن معماری اضافه بشه در حالی که پارادایم‌های مهندس نرم‌افزار وعده داده بودنند حلش بکنند ولی هر چه گذشت بجای حل موضوع چسب زخم‌‌ها ارایه دادن تا خون ریزی متوقف بشه!!

چرا مهندسین نرم‌افزار یا پدران نرم‌افزار مشکل رو از زیر بنا حل نمیکنند!!

خلاصه‌ای از دست نوشته چسب زخم‌های مهندسی نرم‌افزار،
انشالله تا هفته اینده منتشر خواهیم کرد، در این مقاله پیشنهاد‌هایی برای حل مشکل خواهیم داد.

لینک:
https://www.linkedin.com/posts/ali-mahmoodi-tabriz_%DA%86%D8%B3%D8%A8-%D8%B2%D8%AE%D9%85-%D9%87%D8%A7%DB%8C-%D8%AF%D9%86%DB%8C%D8%A7%DB%8C-%D9%86%D8%B1%D9%85%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%A8%DB%8C%D8%B4%D8%AA%D8%B1-%D8%A8%D8%A6%D8%B3%D8%AA-%D9%BE%D8%B1%DA%A9%D8%AA%DB%8C%D8%B3%D9%87%D8%A7%DB%8C%DB%8C-activity-7130635841713950720-7cPu?utm_source=share&utm_medium=member_desktop

تو کامنتا خیلی سریع به جواب اشاره کردن, وقتی دارین با فست یا هر asgi دیگه ای کار میکنید باید حواستون باشه, که به هیچ وجه هیچ جایی از اپلیکیشنتون تسک IO باند نداشته باشین که بلاک کنه main thread تون رو.

چرا؟‌چون بای دیفالت روتر async رو ترد اصلی process ران میشه, بنابراین اگه بلاک شه هم ترد اصلیتون بلاک میشه هم process یعنی تو اون پروسه و ورکر دیگه نمیتونید هیچ درخواستی رو return کنید.

راه حلش چیه؟
https://asgi.readthedocs.io/en/latest/introduction.html#wsgi-compatibility

تو fastapi شما میتونید همچنان کدتون رو با sync هم ران کنید. اگه روترتون io bound داره که sync عه و بلاک میکنه میتونید روترتون رو sync کنید. اتفاقی که اون پشت میفته اینه که fastapi میاد درخواست شما رو تو یک ترد جدا هندل میکنه. داخل asgiref هم نمونه مشابهش هست, که sync_to_async هست. خودتونم میتونید مشابهشو بنویسید و تو executor thread ران کنید کنار بقیه کد های async تون. میتونید از لایبری سباستین asyncer هم استفاده کنید که داخلش از AnyIO استفاده کرده که typingتون رو خراب نمیکنه و فیچر های خوبی داره:
https://github.com/tiangolo/asyncer

اما یادتون نره که پرفومنسی تو تسک های IO همیشه async بهتره از thread چون کم هزینه تره, کانتکس سوییچ نداره, استفاده کامل تری از ریسورستون میکنید و البته cpu bound هم بخاطر وجود GIL فعلا تو پایتون تفاوتی ایجاد نمیکنه. نکته ای که باید دقت کنید بهش لایبری که استفاده میکنید بهتره در درجه اول native async باشه یعنی واقعا async باشه و رو یک ترد non blocking کارشو انجام بده. اگه لایبری mature یا خوبی پیدا نکردین در درجه دوم میتونید از همین تکنیکی که گفتم استفاده کنید.

میتونید مقاله زیر رو بخونید که یکم بیشتر با ساختار و معماری asgi و wsgi آشنا شین:
https://medium.com/p/807158ed1d4c

@ManiFoldsPython

✅ نکته ای که مانی توی کانال اش در مورد io گفته.

درسته که درباره fastapi هست و اینجا جنگولرن ع اما نکته اش و توضیحاتش به درد جنگو کارها و دیگران هم میخوره.

و اصلا نیاز به صورت مساله هم نداریم. چون توضیحاتش کامله

اگر دنبال یک پاسخ سرراست و مختصر برای «وقتی گوگل رو باز میکنیم چه اتفاقی می افته» این ویدیو با انیمیشن‌های زیبا و عمق کم در مورد URL و http و DNS و TCP و تا حدی TLS صحبت می‌کنه.

https://youtu.be/AlkDbnbv7dk?feature=shared

دیزاین پترن ها - دیاگرام کلاس Design Patterns رو چطوری بخونیم؟

در دومین ویدیو از پلی لیست الگوهای طراحی و دیزاین پترن ها به معرفی کلاس دیاگرام UML به عنوان زبان مشترک برنامه نویسان برای توصیف سیستم های شی گرا پرداختیم. نخستین گام یادگیری Design Pattern های شی گرا درک ادبیات مشترک برنامه نویسان شی گراست. ابتدا شیوه طراحی کلاس و عضو های آن به همراه سطوح دسترسی ها را شرح دادیم. در ادامه انواع روابط بین کلاس ها شامل Dependency – Association – Aggregation Composition – inheritance را با ذکر مثال توضیح دادیم. سپس مفاهیم abstraction و interface را تشریح کردیم و تفاوت abstract class و interface را مطرح کردیم.


Link: https://youtu.be/s-lJfW5YABQ

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

〰️〰️〰️〰️〰️〰️
©@microfrontend_ir

✅ توصیه میکنم این ویدئو رو در راستای اینکه فقط برنامه نویس جنگو نباشیم، ببینید

و برام عجیبه که کانال Microfrontend.ir با این همه پست های ارزشمند. اینقدر ممبر کمی داره
آدرس کانال https://t.me/microfrontend_ir

⭕️ در MSFarsi یه بوت کمپ رایگان یکماهه Azure Fundamental قراره برگزار بشه.

برای ورود به Public Cloud فرصت خوبیه مخصوصا برای بچه هایی که میخوان مهاجرت کنند.

لینک ثبتنام :
https://events.teams.microsoft.com/event/e2dd3564-b624-4c3e-8fcb-96815bff7170@b4c9f32e-da17-4ded-9c95-ce9da38f25d9
@securation

در ادامه درباره دو قابلیت مهم در پایتون پیشرفته صحبت می‌کنم ، دستورات filter و تابع map در پایتون

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

نحوه تعریف map به صورت زیر هست.

Map(function , list_name)

ورودی اول دستور map یک تابع است که باید روی لیست اعمال بشه که معمولا یک lambda function است و ورودی دوم دستور نام لیستی است که تابع روی اون اعمال میشه‌. map(lambda x: x**2, items)

#FXL
#lambda
#filter
#map
#lambda_function
#Anonymous
#true
#expression

قابلیت filter شبیه به مپ عمل می‌کنه با این تفاوت که امکان چک کردن یک شرط رو روی تمام اعضای یک لیست رو فراهم می‌کنه.

filter(lambda x: x < 0, number_list)


#FXL
#lambda
#filter
#map
#lambda_function
#Anonymous
#true
#expression

ساخت ID های منحصر به فرد در دیتابیس های توزیع شده ( قسمت اول)

سلام دوستان عزیز امیدوارم که حالتون خوب باشه. در کنارتون هستیم با یکی از پرکاربرد ترین و مهمترین مسئله های حوزه مهندسی نرم افزار و در حیطه سیستم های توزیع شده.
ما در قسمت قبل کمی درباره سیستم های توزیع شده و همینطور sharding صحبت کردیم و یه دید کلی نسبت بهش به دست آوردیم.
فرض کنید ما یک سیستم بزرگ داریم که با حجم مناسبی از داده ها سر و کار داریم ( منظورم بیگ دیتا نیست) و نیاز داریم که داده ها رو در دیتابیس های مختلفی ذخیره کنیم به جای این که یک سرور دیتابیس داشته باشیم و صفر تا صد رو داخل اون ذخیره کنیم.
اگر sql بدونید و با دیتابیس ها کار کرده باشید میدونید ما یک کلید داریم تحت عنوان primary key یا کلید اصلی. که معمولا یا یک مقدار منحصر به فرد مثل کد ملی داره و یا این که auto increment هست ( یعنی کلید هر ردیف رو به شکل اتوماتیک ست میکنه : ۱و۳و۵و... که تو این مثال کلید ها دو تا دوتا اضافه شدن).
ویژگی auto increment مزیت هایی داره :
یک ) مطمئن هستیم که هیچوقت کلید تکراری در یک دیتابیس تولید نمیشه.
دو) کلید ها از الگوی خاصی پیروی میکنن که این هم میتونه مزیت و هم عیب محسوب بشه.
اما این روش اشکالاتی هم داره. زمانی که شما میخواید از معماری توزیع شده استفاده کنید قطعا بیش از یک دیتابیس دارید. مثلا دو تا یا سه تا. و هر کدوم از این دیتابیس ها نمیتونن با یک الگوی خاص داده رو ذخیره کنن.( اینطوری کلید تکراری میخوریم و مشکل بزرگ ایجاد میشه برامون)
و اما راه حل چیه؟
راه حل اول : از الگو های متفاوتی استفاده کنیم برا auto increment به عنوان مثال در دیتابیس A و B مثال های زیر رو ببینین
A : 1,3,5,7,...
B: 2,4,6,8,...

به نظر راه حل خوبی میاد ولی چند اشکال داره:

۱.مقیاس پذیری دشوار
۲.اگر سروری کم و زیاد بشه مقیاس پذیری ما به F**k میره :)

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

ساخت ID های منحصر به فرد در دیتابیس های توزیع شده ( قسمت دوم)
سلام دوستان امیدوارم که حالتون خوب باشه. این بار میخوایم قسمت قبل رو که یه مقدمه ای بود درباره دیتابیس های توزیع شده ادامه بدیم و یکم عمیق تر موضوع رو بررسی کنیم پس با ما همراه باشید.

راه حل بعدی که برای توزیع کلید ها بررسی میکنیم اسمش هست UUID
قطعا اگر توسعه پشت-انتها ( همون بک اند خودمونه) رو کار کرده باشید حداقل یکبار اسم UUID به گوشتون خورده. به یه شکل کلی بخوام توضیحش بدم میاد یه کلیدی که احتمال منحصر به فرد بودنش خیلی بالاست رو تولید میکنه و تو فیلد primary key دیتابیس قرار میده ( ۱۲۸ بیت هست) از قابل اعتماد بودن این روش همینقد اشاره کنم که اگر صد سال شما هر ثانیه یک کلید generate کنید، تازه احتمال تولید کلید تکراری به ۵۰ درصد میرسه. جالب نیست؟
این یه نمونه از UUID هست :09c93e62-50b4-468d-bf8a-c07e1040bfb2.
اینطوری با خیال راحت میتونید کلید های منحصر به فرد رو بین سرور های مختلف پخش کنید بدون هیچگونه نگرانی از تولید کلید های مشابه.

در واقع اینطور بگم که شما اگر پروژه بک اندتون رو روی چند سرور ران کنید، هر کدوم از سرور ها هر بار که نیاز شه یک کلید مجزا تولید میکنن بدون مشکل.
مشخصه که مشکلات مقیاس پذیری میاد پایین و این روش واقعا ساده و کم هزینست.
از معایبش هم اینه ۱۲۸ بیت رو رزرو میکنه در حالی که ما ۶۴ بیت فقط نیاز داریم و این که کلید تولیدی تنها عدد نیست ( البته عیب بزرگی محسوب نمیشن)

یکی از مشکلاتی که اکثر برنامه نویسا دارن تو مدیریت دپندسیه! حالا لایبری جدید یا external service که قراره ازش استفاده کنن.

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

خب چیکار کنیم؟
اولین کاری که میکنید اینه که توتوریالشو میریزین دور. میرین داکیومنتشو خوب میخونید. متوجه میشین limitation هاش چیه. متوجه میشین سیستمش چطور کار میکنه. یک داکیومنت مختصر شده ازش میسازین و cons pro هاشو در میارین. مثلا یعنی چی؟

فکر کنید مثلا دارین یک external system اضافه میکنید. مثلا یک CRM. خب اول باید چک کنید چه limitation هایی داره؟‌ایا api داره؟‌ایا web hook داره؟ ایا share state به وجود میاد؟ هزینش چقدره؟ alternative هاش چیه؟ چطور اصلا کار میکنه؟ اصلا خوب کار میکنه؟!
بعد تو درجه دوم میرین گوگل میکنید و مقاله هایی پیدا میکنید که نقاط ضعفشو بیشتر گفته. ممکنه همه نقاط ضعفش تو داکیومنتش نباشه و یکم پنهان باشه. میبینید بقیه چه چالش هایی داشتن موقع کار کردن باهاش.
در نهایت بین آپشن ها یک لیست pro cons میسازین و تصمیم گیری نهایی رو میکنید.


اگه این کارو نکنیم چه اتفاقی میفته؟
بذارین مثال بگم. مثلا شما ندیدین این api limit احمقانه ای داره. بعد کلی روش کد میزنید. یک روزی سایز بیزنستون بزرگ تر میشه و حالا هرچی کد رو زدین باید undo کنید.


همیشه تو انتخاب دپندسی هاتون خیلی فکر کنید! من بعضا دیدم بچه ها میگن <کارفرما اینطوری گفته> یا <مدیر تیم با این بیشتر حال کرده>‌. اینا دلایل منطقی اصلا نیستن برای انتخاب یک دپندسی.

@ManiFoldsPython

یکی از مهم ترین بخش های زبان کوئری نویسی SQL قسمت WHERE JOIN هست از هر دو میتوان برای کوئری زدن روی دو و یا چند جدول استفاده کرد اما تفاوت هایی با هم خواهند داشت با ذکر یک مثال این مورد را بیشتر توضیح میدهیم.
دو جدول فرضی را در نظر بگیرید
۱. جدول User با مقادیر Id, user_name , phone_number
۲.جدول Book با مقادیر Id, name, price, phone_number
(در واقعیت جدول Book به جدول User با کلید خارجی متصل میشود ولی در این مثال از این مورد چشم پوشی شده است )

اگر بخواهیم با استفاده از WHERE اطلاعات این دو جدول را بر اساس شرط phone_number با هم ترکیب کنیم، می‌توانیم از کوئری زیر استفاده کنیم:

SELECT *
FROM User, Book
WHERE User.phone_number = Book.phone_number;

این کوئری تمام رکوردهایی را انتخاب می‌کند که مقدار phone_number آنها در هر دو جدول یکسان است.

همچنین، می‌توانیم با استفاده از JOIN اطلاعات این دو جدول را بر اساس شرط phone_number با هم ترکیب کنیم. این مثال را با استفاده از JOIN به صورت زیر توسعه می‌دهیم:

SELECT *
FROM User
JOIN Book ON User.phone_number = Book.phone_number;

این کوئری نیز تمام رکوردهایی را انتخاب می‌کند که مقدار phone_number آنها در هر دو جدول یکسان است. با استفاده از JOIN، ما رکوردهای مشابه را از دو جدول به هم متصل می‌کنیم تا نتایج را بدست آوریم.

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

#SQL
@code_crafters

✅ بالاخره بریم برای مطالعه کتاب
Fluent Python
شاید با این کتاب یکم پایتون یاد بگیریم

اگه نکته خاصی وجود داشت. توی کامنت های همین پست قرار میدم.