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

۱ - ما انواع نوتیف ها ( ایمیل، موبایل و پیامک) رو ساپورت میکنیم
۲ - سیستم ما به شکل real time پیاده میشه و کاربرا کمترین زمان انتظار تا دریافت نوتیف رو دارن ( جوگیر نشید تو سیستمای معمولی این روش رو پیاده کنید الکی پیچیده کنیدا ! این واسه سیستمای بزرگه)
۳ - روی دیوایس های اندروید، IOS و دسکتاپ ساپورت میشه
۴ - نوتیف توسط برنامه های مختلف سمت کاربر با هماهنگی سمت سرور دریافت میشه
۵ - روزانه ۱۰ میلیون push notif، یک میلیون پیامک و ۵ میلیون ایمیل ارسال میشه

شغل اول : برنامه نویس

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

اگر شما به کارهای تا ناموس علمی (computer science) علاقه دارید، به کارای بیزینسی چندان عشق نمیورزید و هیچ علاقه ای به سر و کله زدن با افراد دیگه ندارید یا میخواین تو کارای R&D شرکت کنین برنامه نویس شدن میتونه گزینه مناسبی برای شما باشه

شغل دوم : توسعه دهنده یا Developer

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

- زبان های برنامه نویسی و فریمورک
-دیتابیس های رابطه ای sql
-دیتابیس های غیر رابطه ای مثل Redis
-ابزار های دپلوی مثل داکر
- لینوکس سرور و پلتفرم های ابری
- ابزار های تست و مانیتورینگ و کلی چیز دیگه.

واضحه که توسعه دهنده نسبت به برنامه نویس خیلی چیزای دیگه نیازه که بدونه. بخوام یه مثال از تفاوت بین این دو بزنم:
برنامه نویس میاد Redis رو میسازه و دولپر میاد ازش برای ذخیره دیتا استفاده میکنه.

و صد البته بک اند دولپر باید برنامه نویس خوبی باشه چون با کلی الگوریتم سر و کار داره اما الگوریتم ها اغلب اونایی نیستن که جنبه computer science طوری داشته باشن.

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

✅چهار تا فروشگاه اوپن سورس (معروف) با جنگو

✔️django-oscar
لینک: https://github.com/django-oscar/django-oscar
✔️shuup
لینک: https://github.com/shuup/shuup
✔️django-shop
لینک: https://github.com/awesto/django-shop
✔️saleor
لینک: https://github.com/saleor/saleor


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

سری مهندسی نرم افزار: پست 4
از لینکدین Saeed Shahrivari Joghan
لینک

تو پست‌های قبلی راجع به محورهای سه گانه این سری صحبت کردم یعنی: نرم‌افزار، مهندسی نرم‌افزار و مهندس نرم‌افزار. تو این پست می‌خوام راجع به مفهوم «نرم‌افزار خوب» صحبت کنم.

اول دو تا نکته ریز بگم خدمتتون:
۱- معمولاً اگه در کتاب‌ها یا وب بگردید به دو مفهوم بر می‌خورید یکی «نرم‌افزار خوب» (Good Software) و یکی هم «نرم‌افزار باکیفیت» (High Quality Software) که به نظر من تقریباً یه مفهوم دارند.
۲- کیفیت از دو دید قابل بحثه یکی کیفیت داخلی مثلاً معماری خوب و یکی هم کیفیت خارجی مثلا واسط کاربری خوب. معمولاً کاربر بیشتر کیفیت خارجی رو درک میکنه و مهندس نرم‌افزار هم ناخودآگاه بیشتر به کیفیت داخلی توجه میکنه. حالا کدوم باید اولویت داشته باشه؟ به نظر من هیچکدوم برتری نداره که الآن نمیخوام راجع بهش بحث کنیم.

حالا ویژگی‌های یه نرم‌افزار خوب چیه؟ معیارها خیلی متنوعه و پراکنده ولی اجازه بدید در این مورد اقتدا بکنیم به آقای سامرویل! از دید سامرویل ویژگی‌های یه نرم‌افزار خوب موارد زیره:
- کاربردی (Functional): یعنی عملکرد لازم رو به کاربر بده یا به عبارتی درست کار کنه و به درد بخور باشه.
- کارا (High Performance): یعنی کارایی لازم رو هم ارائه بده مثلاً کند نباشه.
- قابل استفاده (Usable): یعنی سهولت استفاده داشته باشه یا به عبارتی کاربرپسند باشه.
- قابل اعتماد (Reliable): یعنی بدون خطا و خرابی کار کنه به عبارتی باگ نداشته باشه و بشه روش حساب کرد.
- قابل نگهداشت (Maintainable): یعنی به راحتی بشه تغییر، ارتقا و بهبودش داد.
- امن (Secure): یعنی امنیت لازم رو برای کاربر فراهم کنه.
البته ویژگی‌های بیشتری هم هست مثل: Scalability یا Testablity‌ یا Compatibility و ... ولی به نظرم ۶ موردی که بالا مرور کردیم تقریباً تو هر نرم‌افزاری دیده میشه ولی موارد دیگه ممکنه تو بعضی نرم‌افزارها خیلی دغدغه نباشه مثلاً مقیاس‌پذیری. لطفاً این ۶ مورد و تعاریفش رو همیشه به خاطر داشته باشیم.

چند تا نکته کنکوری و پایانی:
۱- اینا ویژگی‌های نرم‌افزار خوبه یعنی: کد، داده و مستندات. پس صرفاً شامل کد نمیشه.
۲- نرم‌افزار شامل استهلاک نمیشه یعنی با گذشت زمان خرابی توش بوجود نمیاد برای مثال مقایسه بکنید با ماشین که به مرور زمان استهلاک پیدا میکنه و بیشتر خراب میشه.
۳- یه مهندس نرم‌افزار صرفاً نباید توجهش معطوف به ویژگی‌های کیفی داخلی باشه و باید به ویژگی‌های کیفی خارجی هم توجه کنه مثل قابل استفاده بودن.
۴- این ویژگی‌ها معمولاً مثل یه تار عنکبوت به هم تنیده شدند. یعنی اگه بخوایم یکی رو افزایش بدیم ممکنه به احتمال زیاد ویژگی‌های دیگه که در تعارض هستند کاهش پیدا کنند. برای مثال معمولاً تلاش برای افزایش کارایی سیستم باعث کاهش اتکاپذیری میشه. احتمالاً در آینده راجع این موضوع بیشتر صحبت می‌کنم اما فعلاً پیشنهاد میکنم برای این بحث مقاله بسیار عالی «The web of system performance» رو مطالعه بکنید:
https://lnkd.in/d9s998jA

حالا چه کنیم که نرم‌افزار خوب تولید کنیم؟ ایشالا به شرط حیات در پست‌های بعدی بهش می‌پردازیم😉

دیزاین notification system قسمت دوم

تا اینجای کار ما فرضمون رو از سیستم نوتیفی که میخوایم طراحی کنیم گفتیم

الان نوبت میرسه به یه طراحی سطح بالا از سیستم.

مثال اول : گوشی های Apple

ممکنه بدونید که شرکت اپل برای ارسال نوتیف از APN استفاده میکنه یا همون Apple push notification service هست. به بیان دیگه یه پیام توسط provider تولید میشه و توسط APN به گوشی ها فرستاده میشه.
سه بخش مهم داریم الان:
۱ - بخش provider
2 - بخش APN
۳ - گوشی iOS

بخش provider، با دو نوع داده کلیدی سر و کار داره:

۱ - قسمت device token که شامل یک توکن منحصر به فرد برای ارسال نوتیفیکیشن هست
۲ - بخش payload که یک داده JSON شامل محتوای ارسالی نوتیفیکیشن هست

بخش APN رو هم که توضیح دادیم و کلاینت ما هم که گوشی هست.
یه دیزاین سطح بالا هم ببینیم ازش بد نیست

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

از لینکدین Reza Amini
لینک

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

- Software Engineering Daily

توی این پادکست خفن میزبان میاد و درخصوص چالش ها توی پروژه های بزرگ با مهندسین نرم افزار شرکت های بزرگ صحبت میکنه و تجربیات خوبی شیر میشه.
https://lnkd.in/evyWJjQT

- Software Engineering Radio

‏پادکست رادیوی مهندسی نرم افزار، یکی از اون پادکست های پرمحتواییه که آدم های خفن هر هفته درخصوص چالش های طراحی نرم افزار صحبت میکنند.
‏⁦ se-radio.net⁩

- CaSE

پادکست Conversations about Software Engineering سعی کرده هر سه هفته یک اپیزود برای افرادی که علاقه مند به معماری و مهندسی نرم افزار هستند رو منتشر کنه.

پادکست های رلیز شده مصاحبه طور هستند و بنظرم
جذابن.
https://lnkd.in/emXbqqNi

- Changelog

پادکست Changelog هم واقعا باحاله، خیلی از زمینه های اپن سورس، توسعه وب و برنامه نویسی و.. رو توی اپیزود هاش ساپورت میکنه و تا الان نزدیک ۵۷۰ اپیزود ضبط شده رو قرار داده روی سایتش.
https://changelog.com/

- The Cloudcast

اگه شماهم علاقه مند به Cloud, Serverless architecture, aws ,.. هستید احتمالا این پادکست از بقیه براتون جذاب تره و هر هفته داره اپیزود های جدیدی در زمینه کلاود به اشتراک میزاره.
https://lnkd.in/ejjFdwJk

- CodeNewbie

این پادکست هم با هدف باحالی اومده، آدمای مختلف داستان رسیدنشون به از صفر به پوزیشن های بالایی که الان دارن رو توی هر اپیزود میگن و میگن که چطوری از یک کورس ساده به شرکت های بزرگ نرم افزاری رسیدن.
codenewbie.org/podcast

- System Design

یکی از جذاب ترین پادکست ها برای افرادی که به سیستم دیزاین علاقه دارن، اینجا مصاحبه های سیستم دیزاین بصورت پادکست ضبط میشن و آدمای با تجربه چالش های سیستم دیزاین مختلف رو حل میکنند.
https://lnkd.in/eGsH5ufj

- Soft Skills Engineering

این بار دیگه قرار نیست محتوای فنی و کد بشنوید، با این پادکست شما قراره مهم ترین سافت اسکیل هارو تقویت کنید، بنظرم از دستش ندید.
https://softskills.audio/

- CoRecursive

این پادکست هم عناوین باحالی داره، آدم های بزرگی راجع به مسائل جذابی صحبت کردن، میتونید چک کنید.
https://corecursive.com

✅آشنایی با کلاس TemplateResponse در جنگو

توی ویوهای فانکشن بیس جنگو معمولا متد render رو return می کنیم که توی مسیر django.shortcuts هست.

✔️گاهی اوقات لازم میشه response ایی که بر میگردونیم یکم مخلفات داشته باشه. مثلا به http header ش یه چیزی (به هر دلیلی) اضافه کنیم. در این مواقع میتونیم TemplateResponse رو return کنیم.
✔️وقتی هم که Middleware سفارشی ایی داشته باشیم که تغییراتی رو توی response اعمال میکنه (ریسپانسی که template داره) ، استفاده از TemplateResponse خوبه.

اگه داکیومنت جنگو و بخش میدلورهارو خونده باشی متدی به اسم process_template_response هست.
✔️متد process_template_response در Middleware ها فقط بر روی پاسخ‌هایی از نوع TemplateResponse اجرا می‌شه.

امروز امتحان پایان ترم درس تحلیل و طراحی سیستم‌ها برگزار شد. سوالات امتحان را برایتان پیوست کردم. فکر می‌کنم برای اعضای این کانال نیز مفید باشد.

بد نیست به نکته‌ای اشاره بکنم. سوال یک اگر بخواهیم دقیق صحبت کنیم، مبنای ۳۲ به کار رفته در geohash شامل حروف a و i و l و o نمی‌شود که برای راحتی چنین فرضی در امتحان نداشتیم.

@golemcourse

اینم موتور Django 🥸

لینک

✅بیزینس لاجیک رو کجای مدل در جنگو میشه گذاشت؟
من از این چهار مورد در معماری فریمورک جنگو استفاده کردم که در ویدئو توضیحاتش رو میدم:
1. Field Constraints
2. Custom Constraints
3. Validators
4. Model Clean Method

از لینکدین Hamze Qaempanah

✅کارهایی که با QuerySet در جنگو میتونیم انجام بدیم
از لینکدین Hamze Qaempanah
✔️کوئری ست توی جنگو یک ابسترکشن از عملیات‌های دیتابیسه که کلی متد کمکی در اختیارمون می‌ذاره که خیلی‌هاش کارمون رو آسون می‌کنن و خوبه گوشه ذهنمون باشن تا ازشون استفاده کنیم.
یکسری‌ها که شاید فراموش کنیم ازشون استفاده کنیم رو مرور می‌کنم و لیست کاملش رو از سایت جنگو می‌تونین چک کنین.
البته توی ویدئو هم این‌ها رو توضیح دادم:
aggregate, annotate, dates, defer, only, diffrence, exists, field lookups, get_or_create, update_or_create, intersection, Q, select_for_update, select_related

سری مهندسی نرم‌افزار: پست 5
از لینکدین Saeed Shahrivari Joghan
لینک

تو پست‌ قبلی راجع به مفهوم «نرم‌افزار خوب و با کیفیت» صحبت کردم و اشاره کردم که هر نرم‌افزار معمولاً حداقل ۶ محور کیفی داره که در این پست می‌خوام به «قابلیت نگهداشت» یا همون Maintainability بپردازم که معمولاً یکی از جذاب‌ترین فاکتورها برای مهندسین نرم‌افزار هست.
من خیلی از مواقع طی گپ و گفت با دوستان توسعه‌دهنده این سوال رو مطرح می‌کنم که «به نظرت یه کد با کیفیت چه ویژگی‌هایی باید داشته باشه؟». یه جواب کلیشه‌ای که من خیلی دوستش ندارم اینه که «اگه اصول سالید رو رعایت کنیم، کد خوبی تولید کردیم». ایشالا اگه عمری باشه در آینده راجع به سالید مفصل صحبت می‌کنم و سعی می‌کنم نشون بدم که رعایت سالید برای تولید کد باکیفیت کافی نیست ولی خب فعلاً بگذریم.

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

حالا چه کنیم که نرم‌افزاری داشته باشیم که توسعه، تغییر و نگهداریش راحت باشه؟ از دید من کافیه که حین فرآیند تحلیل، طراحی و توسعه نرم‌افزار دو تا اصل رو رعایت کنیم:
۱- سادگی: همه چیز باید تا حد ممکن ساده نگه داشته باشه یا همون قاعده KISS
۲- رعایت اصل تفکیک دغدغه‌ها (Separation of Concerns): یعنی نرم‌افزار رو طوری به بخش‌های متمایز تفکیک کنیم که هر بخش به دغدغه متمایز بپردازه. حرف راجع به این موضوع مفصله.
اصل اول که بر همه عیانه اما معمولاً من در بین دوستان خیلی اصل تفکیک دغدغه‌ها رو نمی‌شنوم. خب این اصل رو برای اولین بار آقای دایکسترای بزرگ که یه دانشمند هلندیه در سال ۱۹۷۴ مطرح کرده و چون مثل آدمهایی مثل عمو باب معروف اهل شومن بودن نیست شاید خیلی شناخته‌شده نباشه. فعلاً تا اینجای کار داشته باشیم و برای اینکه پست طولانی نشه ایشالا در پست‌های بعد بیشتر به این دو اصل می‌پردازم.

پانوشت: بد نیست به کارهایی که آقای دایکسترا کرده یه نگاهی بندازید.

https://lnkd.in/didwSMYU