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

تستا کلا ۲ دسته هستند. تستایی که stateful هستند و تستایی که stateless هستند.
خود unit test باید stateless باشه یعنی نباید دیتایی اینسرت کنه یا اینتراکشنی داشته باشه با خود محصول واقعی. صرفا باید یک سری چیزا رو ماک کنه.‌خیلی وقتا به جای integration test میشه با ماک کردن unit test نوشت.

ولی stateful تست هایی هست که واقعا داره یک کاری میکنه. واقعا یک state ای داره. مثلا واقعا یوزر اضافه میکنه به دیتابیس. (حالا منظورم استیجینگ یا لوکاله مهم نیست)

مثلا ما تو شرکتمون integration انجام میدیم با بقیه api ها و برای تست میایم ‍openapi اشون رو داینامیک تبدیل به یک api میکنیم(ماک api میگیریم)‌بعد با اون api فرضی تستامون رو پاس میکنیم. پس تستامون stateless میشن.
ولی اگه واقعا از روی staging مثلا یک اسکریپت بنویسیم و با اون api درگیر شه اون موقع میشه integration test stateful

تست های stateful معمولا نباید برن رو CI/CD. ولی تست های stateless باید تو CI/CD ران شن
تستای stateful رو معمولا دستی انجام میدیم مثلا قبل از هر ریلیز.

و اینکه هر چیزی رو میشه تست کرد. چیزی نیست که با stateful یا ‍stateless نشه تست کرد. وقتی کدمون architecture خوبی داره پس میشه. وقتی کدمون architecture بدی داره اون موقع نمیشه تست کرد. مثال میگم
فکر کنید میخواین یک task manager رو تست کنید.
اون موقع شما یک تسک میسازین که هر ۱ ثانیه ران شه. بعد چک میکنید بعد ۱ دقیقه ۶۰ تا ران شده ازش؟‌پس تست پاس شده.
بعد کل بدنه کدتون یک جای دیگست. که فقط تو اون تسک منیجر اون قسمت از کد رو صدا میزنید

@task("every 1 hour")
def do_something():
     Tasks.do_something()

اون موقع میتونید برای کلس Tasks کد بنویسید. و درواقع دیگه نیازی نیست خود فانکشن دکوریت شده رو تست بنویسید. یعنی اگه decouple رو خوب انجام بدین هم ماک راحت میشه هم تست نویسی. اگه کدتون سخته براش تست بنویسید پس یا تایپ تستی که انتخاب کردین بد بوده یا معماری کدتون مشکل داره.

@ManifoldsPython

سوال آخر
به عنوان برنامه نویس چقدر باید تست بنویسیم؟‌وظیفه QA نیست؟

شما باید تست تمام سرویس ها و فیچر هایی که خودتون اضافه میکنید بنویسید. حالا میخواد stateless باشه یا stateful.

میخواد unit test باشه یا هرچی. مثلا اگه فرانت کارید بهتره تست فرانت رو خودتون بنویسید. چون بهترین کسی که میتونه یک تست رو بنویسیه همون کسیه که اون کد رو نوشته. (چه از لحاظ اقتصادی و چه از لحاظ کد نویسی). چون edge case هارو شما بهتر از هر شخصی تشخیص میدین.

خود QA مثلا میتونه اینتگریشن تست بنویسه. مثلا با playwright بیاد تست کنه ایا دیتایی که میدیم فرانت واقعا میره سمت بک اند؟‌ایا فرانت جواب بک اند رو درست parse میکنه؟ ایا اگه یک چیزی از فرانت میس شده بود بک اند ارور میده؟(مثلا یک فیلد)

و البته تست دستی 🙂 بعضی جاهایی که ارزش نداره تست بنویسیم بهتره دستی هم تست کنیم.

@ManifoldsPython

یک نکته که عرفان اشاره کرده:

مثلا من گاهی واقعا میبینم بچه ها over engineering میکنن که یه چیزو در optimize ترین حالت ممکن بنویسن یا فلان چیز یه وقت سربار نداشته باشه در صورتی که فراموش میکنن اصلا اصل ایده شون کار میکنه ؟
این زمانی که میذارن ارزش داره تا اگه یه زمانی ۱۰ هزار یوزر اومد تو سایت (تجربه نشون داده این اگه ها معمولا اتفاق نمیوفتن) داون نشه ؟
مثل یه جور وسواسه بین برنامه نویسا که باعث میشه واقعا غرق چیزی بشن که اون لحظه لازم نیست و نیاز نیست. قبول دارم چیزی به اسم technical debt وجود داره ولی این از اون سر بوم افتادنه که همیشه باید مراقبش باشیم.

دقیقا. کاملا درسته بنظرم.
نداشتن technical debt باعث شکست استارت آپ میشه (چون خیلی وسواس الکی به خرج دادن)
و زیاد داشتنش هم بعد از مدت کوتاهی باعث شکستش میشه (چون اصلا وسواس به خرج ندادن)

خوبه همیشه تکنیکال دبت داشت. فقط باید حدشو رعایت کرد.
@ManifoldsPython

البته این pure python نیست مثالم اینه که شما خودتون implement کردین حالا چه با built in module ها چه لایبری های کمکی مثل aiohttp

ولی سوالم اینجاست
چه چیزی باعث شد که شما از اسکرپی استفاده کنید؟
و چه چیزی باعث شده که سمت اسکرپی نرید؟

@ManiFoldsPython

آموزش PostgreSQL

در اولین ویدیو و مقدمه پلی لیست آموزش PostgreSQL به بررسی تاریخچه و روند شکل گیری پستگرس پرداختیم. از پروژه مادر یعنی Ingres و سپس اضافه شدن امکانات object-relational از طریق پروژه Post-Ingres صحبت کردیم و چند اکستنشن مهم پستگرس یعنی PostGIS و Timescale صحبت کردیم.

Video: https://youtu.be/2f9RAkpQGj4


playlist: https://www.youtube.com/playlist?list=PLJ9zDGwhhsByAI0AbbJ4oUTziNsaffKnq
〰️〰️〰️〰️〰️〰️
© | @microfrontend_ir

دیفالت کانفیگ postgresql برای ترافیک بالا مناسب نیست

و وقتی این کانفیگ رو کاستومایز میکنید متوجه میشین چقدر پرفومنس بهتر میشه
و البته بیشتر ریسورس مصرف میشه 🙂

میتونید کانفیگ مناسب اپلیکیشنتون رو از سایت زیر پیدا کنید. الگوریتم خوبی داره
https://pgtune.leopard.in.ua/

@ManiFoldsPython

آپدیت جدید گیتهاب اومده, و من چقدر با این فیچر حال کردم :))
میخواستم ریپو عوض کنم باید پنج تا کلیک میکردم یا میخواستم یک issue تو یک ریپو دیگه رو ببینم

@ManiFoldsPython

من همیشه به یک چیزی اعتقاد دارم و آن، دید مهندسی است. از خصوصیات مفید و بزرگ دانشگاه خوب رفتنم، همین دید مهندسی است.

حالا این دید مهندسی یعنی چی؟

یعنی شما وقتی بدونید memory management چیست و GC چه کاری تو پایتون انجام می‌دهد، باعث می‌شود کدی که می‌نویسید، memory friendly‌تر باشد.

یا وقتی SQL بلدید و PostgreSQL هم بلدید، باعث می‌شود خیلی وقتا query بنویسید که به جای ۳ بار هیت، یک هیت به دیتابیس بزند. out of box ترش این است که اگر query که می‌زنید، read هست، چند تا read replication بسازید و horizentonal scaling انجام دهید تا سرعت query بهتر شود. اگر می‌بینید query که می‌زنید، مثلاً ۱۰ درصد ریزالت کل دیتابیستون است و حجیم است، از طرفی مثلاً ۲ تا column خیلی استفاده می‌شود توی آن query، آن وقت می‌توانید ترکیب آن دو تا column را ایندکس کنید تا پرفورمنس بهتری بگیرید. اما اگر ریزالت برگشتی ۷۰ درصد دیتابیستون باشد، آن موقع ایندکسها سربار دیتابیستون می‌شوند و نه تنها کمک نمی‌کنند بلکه سرعت شما را هم کاهش می‌دهند.

به این می‌گویند دید مهندسی. یعنی بدانید از چه چیزی کجا و به چه اندازه‌ای استفاده کنید.

همه اینها را گفتم تا برسم به این کتاب:
https://www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1449373321

این کتاب به شما یک دید مهندسی فوق‌العاده می‌دهد. تازه شروع کردم و می‌تونم بگم محشره ✌️

اگه با postgresql نسخه ۱۴ به بالا کار میکنید این مقاله به احتمال خیلی زیاد به دردتون میخوره.

Cascade of doom: JIT, and how a Postgres update led to 70% failure on a critical national service

https://dev.to/xenatisch/cascade-of-doom-jit-and-how-a-postgres-update-led-to-70-failure-on-a-critical-national-service-3f2a

نویسنده هم ایرانیه
@ManiFoldsPython

یک نکته ای که اضافه کنم اینه که اگه انگلیسی بلد نباشین همیشه از دنیا چند پله عقب ترین
یعنی تا داک فست ترجمه نشده نمیتونید بخونید
تا آموزش K8s فارسی نیاد نمیتونید یاد بگیرین
تا آموزش داکر فارسی نیاد نمیتونید یاد بگیرین
تا Mojo داکش فارسی نشه یا اموزش نیاد نمیتونید یاد بگیرین..
هیچوقت doc string رو نمیتونید بخونید.

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

@ManiFoldsPython

من خودم از کلاس چهارم کلاس زبان رفتم. ۱ سال تخصصی زبان خوندم. ۳ سال هم تو دانشگاه به زبان انگلیسی درس خوندم پس تجربیاتم رو بهتون میگم:

اولا اشتباهی که تقریبا تو ۹۰درصد کلاس های زبان تهران(تا ۶ سال پیش که من اطلاع داشتم) میشد این بود که هنوز طرف دو کلمه نمیتونه حرف بزنه میان گرامر به خردش میدن‌😄 اگه میخواین زبان یاد بگیرین اصلا سمت گرامر و writing نرید. شما نیاز دارید اول زبان رو بفهمید. من تاسال ۵ام زبان انگلیسی خوندم یک گرامر خیلی ساده هم بلد نبودم.

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

تو این پست نمیگنجه که بگم برای هر مرحله چیکار کردن ولی برای اولین مرحله:
۱. دیدن انیمیشن تا یک سطحی که ۹۰درصد متوجه شین. اشتباهه شما فیلم ببینید وقتی متوجه نمیشید چی دارن میگن. انیمیشن لغات راحت تری داره و راحت تر میتونید متوجه شید. انقدر ببینید که کامل متوجه شین
دومین قدم:‌دیدن فیلم و یوتیوبه. فیلمی که میبینید نباید تاریخی باشه. نباید لهجه خاصی داشته باشه(مثل بریتیش یا اسکاتیش یا استرالیایی).
اولش با ساب تایتل انگلیسی ببینید. بعدش ساب تایتل انگلیسی رو بردارین زمانی که ۹۰درصد متوجه شدید چی میگن. حالا گوشتون هم عادت میکنه.

و از همه مهم تر, هیچوقت از translate انگلیسی به فارسی استفاده نکنید. خیلی سمه. هیچوقت زبان یاد نمیگیرین شما‌اگه اینکارو کنید.
چون تو ضمیر ناخودآگاهتون همیشه قبل حرف زدن باید یک دور فارسی فکر کنید بعد تبدیلش کنید به انگلیسی
بعد انگلیسی صحبت کنید.

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

@ManiFoldsPython

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

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

از یاد گرفتن یک زبان دوم ضرر نمیکنید.

@DevTwitter | <Amirreza Gh/>

دو visualization platform که از پایتون تو سورس کدشون استفاده شده و کلی دیتابیس ساپورت میکنن:

این یک autogenerative AI داره میاره که شما مینویسید چی میخواین و query هم خودش مینویسه. 😁البته هنوز لانچ نشده.
https://superset.apache.org/

این یکی هم عالیه.
https://redash.io/


@ManiFoldsPython

تو لینکدین دیدم جالب بود
@ManifoldsPython

چقدر حقه این ویس 🙂
خیلی وقتا همه فکر میکنن چون صرفا یک چیز تو فریم ورکه پس یعنی درسته. پس یعنی استفاده ازش خوبه.
این مثال لایبری مدرن و غیر مدرن و قدیمی نمیشناسه. تو فست بخواین تو کوکی JWT توکن پاس بدید باید یکم کاستومایز کنید چون دیفالت تو هدر تعریف شده و تو پروژه های تمرینی سباستین هم دقیقا همینطوریه در صورتی که این اشتباهه (قبلا توضیح دادم چرا)

و همینطور تو جنگو رست فریم ورک هم همینطوره. در واقع DRY رو تبدیل به Don't respect yourself کرده که به قول امیربهادر میری تو views.py میبینی صد مدل view مختلف هست و ادم گیج میشه. SOLID کلا زیر سوال میره و بیزنس لاجیکو تکنولوژیو همه رو میکنه توهم دیگه

"The most dangerous phrase in human language is We've always done it this way "
- Grace Hopper

@ManiFoldsPython

Well said :)

@ManifoldsPython

Parse, don't validate

فکر کنید یک دیتا کلس داریم

@dataclass
class Order:
    id: UUID
    customer: Customer
    created_at: datetime
    accepted_at: Optional[datetime]
    paid_at: optional[datetime]
    shipped_at: Optional[datetime]

میخوایم این سناریو هارو پیاده سازی کنیم
Order that is received -> Order that is accepted
Order that is accepted -> Order that is paid
Order that is paid -> Order that is shipped

یک تابعی داریم که این چنین کار میکنه:
def ship_order(order: Order) -> Order:
...

خب طبیعتا مشکلی که وجود میاد اینه که چه چیزی باعث میشه که ما به flow و جریان دیتا احترام بذاریم؟
Order that is received -> Order that is shipped
چطور جلوی این رو میگیریم؟‌باید هردفعه تو ship order کلی چک بنویسیم که ۱۰۰درصد خیالمون راحت باشه که عملیاتی که میشه داره درست انجام میشه. به این کار میگن validation

تازه این یک سناریو ساده بود. همین ولیدیشن باید برای همه توابع دیگه ای که نیاز داریم نوشته شه یعنی:
accept_order
return_order
update_order

تازه وقتی تو سورس کد میبینیم همچین چیزی رو نمیدونیم کی باید این تابع رو کال کنیم و ایا type safe هست یا نه؟ یعنی اگه من هر اوردری بدم بهم اوردر شیپ شده میده؟ از کجا میتونم ۱۰۰درصد خیالم راحت باشه اروری چیزی نمیخوره؟ از کجا میتونم بفهمم اوردی که برمیگرده ship شده هست؟ پس باید doc string رو بخونم و همینطور کد هم چک کنم! و این خیلی بده 🙂

حالا parse چیه؟ وقتی اوردر رو parse میکنید یعنی دارید آنالیز میکنید اوردر دقیقا تو چه state ای قرار داره

def ship_order(order: PaidOrder) -> ShippedOrder:
...

و تو کلس PaidOrder هم ۱۰۰درصد پارس میکنم که اوردر باید تو وضعیت paid باشه. این کاملا تایپ سیفه یعنی هر PaidOrder ای بهش بدم ShippedOrder به من میده. بدون اینکه کد کثیف و پر از ولیدیشن نوشته شه تو تابع! و البته برای درکشم نیازی به داک استرینگ و خوندن کد ندارم‌:)


مقاله کامل تر

@ManiFoldsPython

یک سوال تو مصاحبه ای که روش ریپلای زدم پرسیده شده بود ازم جالب بود:

۱. تفاوت having و where تو sql . که خب سوال راحتیه.

۲. چرا تو سناریویی که از having استفاده میکنیم نمیتونیم از where استفاده کنیم؟ (دلیل فنی پشت implementation having یا بهتره بگم دلیل وجود سینتکس having )

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

تو کامنتا جوابشو بگید
@ManiFoldsPython

جواب جفت سوالو تو کامنت اشاره کردن
دلیلش فقط به خاطر ‍execution order و تایم لاینی هست که اجرا میشه. یعنی where میاد قبل از group by اجرا میشه برای همین نمیتونستیم هیچ فیلتری توی group by امون انجام بدیم. مثلا میخوایم بگیم sum فلان فیلد بیشتر از ۱۰۰ باشه. نمیتونستیم با این معماری و where . (البته میشه cte زد)
و مرسی از مهدی عزیز بابت اشتراک گذاری این پست:

Visualizing a SQL query

SQL statements are executed by the database system in several steps, including:
- Parsing the SQL statement and checking its validity
- Transforming the SQL into an internal representation, such as relational algebra
- Optimizing the internal representation and creating an execution plan that utilizes index information
- Executing the plan and returning the results


@ManiFoldsPython