نکته سوال دوم: scale این پروژه به شدت سخته. جایی که وب سوکت میاد به شدت سخت scale میشه چون state داره اپلیکیشن. شما فکر کنید ۱ میلیون کاربر یک دفعه به وب سوکتتون وصل میشن، حالا ۲ تا اپ جدید میذارین، کسی بهش وصل‌نمیشه! چون همه به اپ اول وصلن هنوز. ولی rest api اینطوری نیست چون state نداره. فکر کنید میخواین دیپلوی کنید، اگه وب سوکت رو بیارین پایین همه ۱ میلیون کاربر باهم قطع میشن. وقتی داره یک دانلود بزرگ رخ میده، احتمال اینکه مموری بچسبه به سقف هم خیلی زیاده!

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

@PyBackendHub

✅ همه چیز درباره Caching
از لینکدین Pouria Jahandideh

ممکنه تو مصاحبه ازتون در مورد Caching بپرسند

یا حتی بخواهید که برای سایتتون Caching راه بندازید تا سریع تر لود بشه

یا ممکنه Cache داشته باشه و تو invalidate کردن مشکل بخورید

تو این داکیومنت من به صورت ساده Caching رو توضیح دادم

اما یادتون باشه که اینا همشون تئوری هستند و پیشنهاد می‌کنم که سعی کنید چند تا تمرین آخرش رو انجام بدید

یعنی سعی کنید که با nginx و CDN و Squid و Service Worker و Redis کش های مختلف پیاده‌سازی کنید تا مفهومش کامل براتون جا بیفته و بهش تسلط پیدا کنید.

✔️فایل PDF رو ببینید

خب دوستان درمورد نظرسنجی که بالا درمورد انتخاب پلتفرم بلاگ نویسی گذاشتم ی سری پوینت‌ها رو مناسب دیدم بنویسم.

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

چه پلتفرم‌هایی برای شروع بلاگ نویسی وجود دارن؟
طبق چیزی که من تحقیق کردم میشه گفت ۳ نوع پلتفرم برای بلاگ نویسی وجود داره:
۱- سایتهای اشتراک مقاله مثل مدیوم یا نسخه وطنی اون ویرگول.
اینا خوبن، شناخته شده هستن، کاربر زیاد دارن و افراد متعددی میتونن مقالات شما رو دنبال کنن.
اما اون کاربرها در واقع کاربر شما نیستن بلکه برای همون پلتفرم هستن.
شما نمیتونید اونجا اقدام به تبلیغ یا اتصال درگاه پرداخت برای فروش محصولات کنید.
و اگه روزی اون پلتفرم تصمیم بگیره اکانت شما رو ببنده یا پست‌های شما رو پاک کنه کاری از دست شما برنمیاد و این اتفاقیه که به کرات افتاده.
۲- اپ اختصاصی:
ی برنامه‌نویس میتونه خودش برای خودش ی پروژه شروع کنه و ی اپ وبلاگ بنویسه.
اینکار میتونه باعث بشه شخص کد خودش رو تو گیتهابش منتشر کنه و ی پوینت اضافه کنه به خودش.
حتی میتونه مراحل ایجادش رو ضبط و بعنوان آموزش پروژه محور منتشر کنه.
اما خودش باید تمام موارد از جمله تکنولوژی هایی که لازمه برای پیاده‌سازی و دیپلوی پروژه رو بلد باشه یا یاد بگیره، سئو و بهینه‌سازی برای موتورهای جستجو رو باید بلد باشه، بحث امنیت رو باید بلد باشه و رعایت کنه، اگه فیچری نیاز داشت باید خودش بشینه کد بنویسه و اضافه کنه، کلی باگ و دیباگ و... و به این ترتیب با اینکه اینجا دستش بازه و هر کاری خاست میتونه بکنه اما از اونطرف هم کلی زمان از دست میده و فکر نکنم بعدش برای بلاگ نویسی انگیزه‌ای براش بمونه(چون دائم در حال دیباگه 😂)
۳- اپ‌های آماده مثل وردپرس و جوملا و...
و در آخر اگه هدف شخص تنها شروع بلاگ نویسیه میتونه از اپ‌های رایگان آماده مثل وردپرس استفاده کنه که مثلا در بحث سئو رو دست نداره، تست شده است و کامیونیتی فعال و قوی داره، هر فیچر یا تمی خاست اضافه کنه براحتی میتونه با نصب ی پلاگین در ی لحظه انجامش بده و کلی کار خفن دیگه.

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

این نکات رو تو این چند روز کلی مقاله و ویدیو مرور کردم و بدست آوردم و خوشحالم تو اشتراک گذاریش کمکم کنی، دمت گرم 🫠

@osmanpydev

✅اسم اپ های جنگو جمع باشه یا مفرد؟

از لینکدین Mohammad Amin Amjadi

✔️فایل PDF رو ببینید

خب در ادامه قراره پست قبلی رو کامل‌تر و دقیق‌تر توضیح بدم و اگر جایی نظر دوستان مخالف بود و یا پیشنهاد مناسبی دادن رو هم باهاتون در میون بذارم.

پیرو نظر برخی دوستان که نامگذاری "جمع" بجای "مفرد" بود، مجدد مقالات، سورس کد خود جنگو، داکیومنت و ... رو بررسی کردم و باز دلیل انتخاب خودم رو برای انتخاب نام اپ مفرد رو گفتم.

ممنون میشم شما هم نظر و رویه خودتون رو به اشتراک بذارین

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

شما مسئول چنین مواردی نیستید و به هیج وجه نمی‌تونید اونها رو تضمین کنید

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

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

پاتون رو از گلیم خودتون درازتر نکنید و دروغ به خورد مردم ندید

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

سخنی به دانشجویان: هیچ کس با گذراندن یک دوره که هیچ با گذراندن ۱۰۰ دوره هم سنیور نمی‌شود.
خود مدرس دوره هم که داره به شما تدریس میکنه سنیور نیست، پس گول نخورید .

@purecoder_ir

طراحی میکروسرویس با جنگو بخش دوم میکروسرویس چیست

میکروسرویس ها روندهای جدید توسعه هستند. امروزه شرکت ها معماری میکروسرویس را برای توسعه پروژه ترجیح می دهند. این یک راه حل بسیار فشرده برای یک پروژه است. مدیریت ماژول را آسان می کند و اجرای پروژه را سریعتر می کند. همچنین به توسعه سریعتر پروژه کمک می کند. این دلایل ذکر شده و بسیاری موارد دیگر باعث تقاضای میکروسرویس می شود.

معرفی میکروسرویس
برای میکروسرویس تعریف خاصی وجود ندارد و ممکن هست هر فرد به شکلی آنرا تعریف کند اما دو تعریف عمده آن به شکل زیر است
۱-میکروسرویس‌ها، سرویس‌های کوچک و مستقلی هستند که باهم کار میکنند
۲-میکروسرویس‌ها معماری سرویس گرا با زمینه‌های محدود هستند،بطور مستقل و با یک جزء دیگر در داخل ارتباط برقرار میکنند، این معماری بسیار خودکار و و سیستم‌های نرم افزاری را تکامل می‌دهد

بیایید ببینیم که آیا از معماری سرویس گرا (SOA) آگاه هستید یا خیر، سپس ماژولار بودن پروژه و ارتباط از طریق پیام را نیز می دانید. اگر از شیوه های DevOps آگاه هستید، در مورد استقرار خودکار نیز می دانید. هر دو بیشتر به رویکرد میکروسرویس نزدیک هستند.


سه اصل مهم در طراحی میکروسرویس‌ها:
۱-از میکروسرویس برای استقرار سیستم‌ها و پروژه‌های بزرگ استفاده کنید: برای تمام مقیاس‌های پروژه استفاده از میکروسرویس اشتباه است، بلکه مناسب پروژه‌های بزرگ است که مدیریت آن چالش برانگیز باشد، اما خود این موضوع هم سردرگم کننده هستش اینکه کدوم پروژه رو کوچیک، متوسط، بزرگ بنامیم، منتها اگر سیستم ما دارای بار بالایی از درخواست کاربر است و نیاز به مقیاس پذیری دارد، میتوانیم رویکرد میکروسرویس رو پیاده سازی کنیم(در حجم تعداد اپ نیز تعداد اپ بالا میتواند به این منزله باشد)

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

۳-قابلیت تعویض ماژول ها: در پروژه های توسعه یافته قبلی که با رویکرد میکروسرویس ساخته نشده اند، امکان تغییر هر جزء از پروژه کمتر است. قبل از تغییر سازنده کامپوننت باید در مورد تغییرات برنامه ریزی کند، وابستگی کد خاصی را پیدا کند، در صورت عدم موفقیت کد به هر دلیلی، مراحل بازگشت را فهرست کند و تاثیر کد را مشخص کند. پس از همه، تغییرات نیاز به انجام عملیات تست واحد و سپس آزمایش ادغام با کل محصول دارند


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

در میکروسرویس ها، کل پروژه را بر اساس ماژول ها به یک جزء‌های کوچک تقسیم می کنیم. بطوری که امکان تکرارپذیری را بر روی هر جزء فراهم می کند که تعمیر و نگهداری پروژه رو راحتتر میکند

اپلیکیشن‌های میکروسرویس دارای بخش‌های مهم زیر هستند:
● به اندازه های کوچک تقسیم می شوند
● برای برقراری ارتباط نیازمند انتقال پیام هستند
● مقید به زمینه‌ها هستند
● توسعه انها بصورت مستقل هستش
● استقرار هر بخش مستقل هست
● متصل به کنترل کننده مرکزی نیستند
● ساخت ها توسط فرآیندهای خودکار مستقر می شوند

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

تمرکززدایی:به این معنی است کل کارهای داخلی پروژه شامل اجرای هر ماژول، مدیریت وظایف و جابجایی کامل پروژه دیگر توسط یک سیستم واحد، مدیریت و کنترل نمیشود

استقلال: به این معنی است که به تیم‌های توسعه خود برای تولید نرم افزار ایمان داشته باشیم

مزیت این دو رویکرد این است که تغییرات در نرم افزار آسانتر و سریعتر میشود و امکان تصمیم گیری سریعتر را فراهم میکند


ادامه در وبسایت

لینک وبسایت


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

#microservice
#django

@code_crafters

سری مهندسی نرم‌افزار: پست 10
از لینکدین Saeed Shahrivari Joghan
اسکرام چکش طلایی نیست!

در پست قبلی اجمالاً راجع به چارچوب بودن اسکرام صحبت کردم. مجدداً تاکید می‌کنم که من طرفدار اسکرام نیستم ولی شدیداً با روال توسعه بی‌برنامه و یلخی هم مشکل دارم. من اخیراً تیم‌های زیادی رو دیدم که با توسل به حربه «ما داریم کنبان کار می‌کنیم» بدون داشتن فرآیند تکرارشونده حرکت می‌کنند و متاسفانه حتی قوانین پایه کنبان مثل «تعیین WIP» رو هم اجرا نمی‌کنند و یا در برخی موارد من زیاد دیدم که مدیر تیم بدون برگزاری حتی یک جلسه گروهی در ماه صرفا به صورت هفته به هفته و با استفاده از یک دفترچه و جلسات یک به یک به اعضای تیم وظایف هفتگی می‌ده. اغلب مخالفین سرسخت اسکرامی که من تا به حال دیدم خودشون یکبار به صورت عمیق راجع بهش مطالعه نکردنند و یا در برخی موارد حوصله روال و قانون رو ندارند. بدیهیه که برای هر پروژه‌ای اسکرام و حتی اجایل ممکنه مناسب نباشه و خیلی جاها همون تکنیک «مدیر + دفترچه یادداشت + جلسات تک به تک» ممکنه کار کنه ولی من مطابق تجربه خودم در بازار طی سال‌های اخیر به این رسیدم که روش‌های چابک در خیلی از پروژه‌ها کار می‌کنند فقط باید از روش چابک مناسب، در جای مناسب، و با تیلورینگ/کاستومایزیشن مناسب استفاده کرد (بازم تاکید می‌کنم که تیلورینگ به معنی تغییرات اساسی در چارچوب نیست بلکه به معنی انطباق روش با شرایطه). معمولاً در سازمان‌های بالای ۱۰۰ نفر، استفاده از مشاوره و یا همکاری یک فرد مسلط و با تجربه در زمینه چابکی می‌تونه خیلی کمک‌کننده باشه.

واقعیت تلخ و شاید شیرین اینه که اسکرام برای هر پروژه‌ای مناسب نیست! اسکرام معمولاً برای پروژه‌های با پیچیدگی بیزینسی بالا که نیاز به انعطاف بالایی در اجرا دارند مناسبه. برای چند نمونه از جاهایی که استفاده از اسکرام فایده‌ی زیادی نداره میشه به این موارد اشاره کرد:
◀️ پروژه‌های کوتاه مثلاً در حد یکی دو ماه
◀️ پروژه‌های که تیم‌های خیلی بزرگ و پراکنده از نظر جغرافیایی دارند. در این موارد شاید استفاده از چارچوب‌های مثل SAFe بهتر باشه
◀️ تیم‌هایی که بیشتر درگیر نگهداشت محصول هستند و بیشتر تیکت حل می‌کنند مثلاً تیم‌های DevOps و SRE (البته نه همیشه)
◀️ تیم‌هایی که کراس-فانکشنال نیستند مثلاً یه تیم UX و یا DevOps مستقل (بازم نه همیشه)
◀️ پروژه‌هایی که کل مسیر و گانت از اول تا آخر واضح و مشخصه و تغییری هم توش نخواهد بود
◀️ پروژه‌های خیلی خیلی تکنیکال مثلاً طراحی و توسعه یه هسته جدید برای یک سیستم‌عامل نهفته
◀️ تیم‌هایی که اصلاً به اسکرام و حتی در مرتبه بالاتر به چابکی اعتقادی ندارند

در پایان این نکته رو مرور کنیم که روش‌های متنوع چابک وجود دارند که اسکرام یکی از اونهاست و اسکرام قرار نیست همه جا کار کنه اما چابکی به معنی بی‌برنامگی نیست. در پست بعدی مفصلاً راجع به کاستومایز کردن صحبت می‌کنم.

✅دوره رایگان آموزش برنامه نویسی توسط سید و رفقا (کانال @SEYED_BAX)

✔️قطعا مطالب مفیدی توی این دوره رایگان میتونید یاد بگیرید.
امشب (شنبه 25 فروردین 1403) اولین جلسه است.

من سید (@seyed_dev) رو میشناسم و میدونم دانش خوبی توی برنامه نویسی (بخصوص پایتون) و دیتابیس های no sql و داکر و... داره. ازش یاد بگیرید/بگیریم

✅معرفی پکیج Django-Hijack

بدون اینکه رمز کاربرهای سایت تون رو بدونید وارد اکانت شون بشید 😬
من نمیدونم کجا میتونه کاربرد مفیدی داشته باشه

https://github.com/django-hijack/django-hijack

✅کاملترین دوره آموزشی کار با فرم ها در #جنگو به زبان فارسی
عجب اعتماد به نفسی داشتم 4 سال پیش 😂

یاد نموداره افتادم

دوره کار بر فرم ها در جنگو رو برای دانشجویار حدودا 4 سال پیش ساختم. امروز یه نگاهی بهش انداختم.
آموزش بدی نیست. فقط موندم چرا توی دمو اینقدر رسمی حرف زدم.

✔️این دوره رایگان نیست

✅نکته مهم
یادگیری بدون تمرین به درد نمیخوره
✔️هفته ای 8 تا دوره و کتاب ببینی و بخونی. وقتی تمرین نکنی، هیچی نمیشی 😂

انگار جنگولرن داره از جنگو فاصله میگیره 😡🤬