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

چرا وبلاگ داشتن برای ی برنامه‌نویس مهمه؟
تو کتاب 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 تا دوره و کتاب ببینی و بخونی. وقتی تمرین نکنی، هیچی نمیشی 😂

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

انتخاب محل ذخیره سازی تصاویر: فایل سیستم یا پایگاه داده؟

تصمیم گیری در مورد بهترین راه برای ذخیره سازی تصاویر بین Blob (Binary Large Object)در پایگاه داده و فایل سیستم (مانند S3) همیشه بحث برانگیز بوده.

پایگاه داده یا فایل سیستم؟ کدوم بهتره؟

اول از همه، بریم سراغ مزایای هر کدوم:

پایگاه داده:

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

فایل سیستم (مانند S3):

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

پس کدوم رو انتخاب کنیم؟

خب، بستگی به نیاز شما داره!

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

در نهایت...

هیچ راه حل کاملی وجود نداره و انتخاب بهترین روش به نیازهای شما بستگی داره.

#Database #General
@Code_Crafters