‏به عنوان کسی که تو سه تا کشور هم به عنوان مصاحبه‌کننده هم مصاحبه‌شونده تجربه‌های زیادی داره، اجازه بدید چندتاشون رو باهاتون به اشتراک بذارم شاید به کارتون بیاد:

1. قسمت معرفی خودتون رو خیلی جدی بگیرید. نه خیلی کوتاه و مختصر، نه روده‌درازی. یه بخش مهمی از تصمیم اونجا گرفته میشه

‏2. تو قسمت غیرتخصصی مصاحبه، 50% اهمیت داره که جواب درست بدید و 50% اینکه چطور جواب می‌دید. یعنی در واقع گاهی لزوماً جواب درست وجود نداره، فقط مهمه شما چطور جوابتون رو ارائه می‌دید.

3. لبخند، خوشرویی، نشون ندادن استرس، آشنایی نسبی با کار شرکت و آماده بودن بسیار اهمیت داره.

4. تو مصاحبه به زبان دوم، به جز شغل‌هایی که فن بیان و روان بودن (مثلا معلمی) توش اهمیت داره "عالی" بودن زبان اونقدر اهمیت نداره پس به خودتون استرس ندید.

5. وقتی می‌گن یه مثال از اشتباهات گذشته بزن، نه مثالی بزنید که توش رسماً گند زده باشید، نه بگید "من هیچ وقت اشتباه نمی‌کنم"


✍سوربا

@cappuccino_plus

Is it worth the effort to design software well?

بخونید از مارتین بزرگ
بزرگوار سال ۲۰۰۷ واقعا کجا ها سیر میکرده 🙂

DesignStaminaHypothesis:

https://martinfowler.com/bliki/DesignStaminaHypothesis.html


@ManiFoldsPython

فرهنگ issue مطرح کردن تو کامینیتی که متاسفانه خیلیامون رعایت نمیکنیم:

۱. لطفا لاجیکتون رو از کدتون جدا کنید. کسی علاقه نداره لاجیک پشت کدتون رو بخونه که سر در بیاره کدتون چیکار میکنه.
۲. اگه کدتون پیچیدست سعی کنید خیلی ساده و بدون پیچیدگی یک کدی بنویسید که همون مشکل رو reproduce کنه.
۳. تست بنویسید که fail شه. بنویسید از چه نسخه پایتونی استفاده میکنید و از چه نسخه ای لایبری استفاده میکنید. مثلا کدتون اگه با پایندانتیک ۲ داره ران میشه باید ذکر کنید این موضوع رو.
۴. اسکرین شات با ‍سایت هایی مشابه ray.so بنویسید


ایشو هایی که اینطوری مطرح میشن خیلی راحت تر برطرف میشن و همه روش وقت میذارن :)
@ManiFoldsPython

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

این بنظر میاد replacement خوبی باشه.

https://chrome.google.com/webstore/detail/swoosh-cookie-and-local-s/giompennnhheakjcnobejbnjgbbkmdnd

کوکی و همه چیم داره یک جا میتونید استفاده کنید. از UI اش خیلی خوشم اومد
@ManiFoldsPython

https://www.youtube.com/live/RtAWGrXUXNs?feature=share

امشب به همراه سایه جان هاست هستم تو ‍tech immigrant

@ManiFoldsPython

پروژه های خفنی که pydantic رو ساپورت میکنن:

Rocketry: Modern scheduling library for Python

RedisOM: Object mapping, and more

polyfactory: Simple and powerful factories for mock data generation

Beane: Modern Async ODM for MongoDB

Litestar: Light, Flexible and Extensible ASGI API framework Litestar


خودم شخصا با rocketry و redis om خیلی حال میکنم 👍و کار میکنم با جفتشون.
راکتری خیلی گاده.
@ManifoldsPython

چند نکته که چرا راکتری لایبری خوبیه:
۱. اولا کاندیشن کاستوم میتونید بنویسید. که اگه این شد آنگاه این تسک ران شه. این خیلی خوبه برای پیاده سازی معماری EDD. 👍کلا به درد microservice میخوره

۲. ران کردن async و ‍sync و multiprocessing توش خیلی راحت تر از چیزیه که فکر میکنید. تو decorator تابعتون میتونید بهش بدید.

۳. موقع ران تایم میتونید تسک جدید رجیستر کنید!‌ یا ساعت تسک رو عوض کنید. مثلا یک دیتابیس داشته باشین که ساعت تسکا رو توش ست کنید و تغییر بدید. میتونید براش یک UI هم طراحی کنید. لیست تسکایی که ران هستند رو بگیرین. state هر تسک رو ببینید. ببینید اخرین بار کی ران شده کی تموم شده و اکسپشن داشته یا نه.

۴. میتونید با uvicorn بالا بیارینش. با فست همزمان رو یک شل ران شن. و توی خود فست هم میتونید ازش استفاده کنید مستقیما. به جای سلری خیلی sync تره با فست.

۵. لاگر initiate کردن توش خیلی قشنگه. کلا نصف کدایی که زده مربوط به همین log انداختنه و نمیدونم چرا اینقدر عاشق لاگه :))

۶. به شدت تست های زیادی داره و سنگین. کاوریجش ۹۷ درصده و من باگی ندیدم ازش تو این مدتی که استفاده کردم.


چند نکته منفی این لایبری:
۱. به شدت حجم کد زیادی داره و نمیدونم چرا. چیزی که با ۱۰ خط میشد انجام داد ۱۰۰ خط کد نوشته.

۲. پاینداتیک نسخه ۱ رو فقط ساپورت میکنه. با این حجم کدی که داره من حالا حالا ها نمیبینم که بخواد پایدانتیک ۲ رو ساپورت کنه. اگه پروژتون پایدانتیکه ۲ هست تو گیت هاب من یک ریپو هست که backward compalbity اینو اوکی کرده که با ۲ هم ران شه. اگرچه وقتی نسخه ۲ رو نصب میکنید راکتری همچنان داره از نسخه یک استفاده میکنه داخل اینترنالش. میخواستم کلا ببرمش رو ۲ که دیدم ۱۵۰ تا تست fail داد بیخیال شدم. :)) البته رو پرفومنس اصلا تاثیر نمیذاره چون خیلی کار زیادی با pydantic انجام نمیده.


@ManifoldsPython

من یک tools نوشتم برای شرکت که کارش این بود که SOUP جنریت کنه.
حالا SOUP چیه؟
Software Of Unknown Pedigree

خلاصه باید یک فایل اکسل میدادیم بیرون که توضیح میداد از چه لایبری هایی استفاده شده. چه نسخه ای. چه vulnerability شناخته شده ای دارن. چه نسخه ای داریم استفاده میکنیم و چه نسخه ای آخرین نسخه اش هست. چرا داریم استفاده میکنیم(کار لایبری) و به چه دلیل اون لایبری خوبه. اینا روند قانونی بوده که مهم نیست. که بر اساس poetry lock و pypi این اطلاعاتو در میاره و parse میکنه به صورت کاملا async. کلا شد نزدیک ۱۷۰ لایبری هیچ کدوم آسیب پذیری شناخته شده ای هم نداشتن که هندل نکرده باشن.

حالا داستان جایی شروع شد که من اومدم برای ریپو های بقیه جاهامون هم اینو بنویسم.
تو ریپو فرانت نوشتم و ران کردم اسکریپتو که یک دفعه دیدم Memory error داد. تعجب کردم.
متوجه شدم تو لایبری های فرانتمون از ۳.۷ هزار لایبری استفاده میکنیم :))) ۳.۷ هزار درخواست همزمان هم داشتم میزدم به سایتای مختلف :)) چندین مورد هم حتی آسیب پذیری دارن.

@ManifoldsPython

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

برای خیلی از زبون های برنامه نویسی هم داره. برای پایتون:

https://docs.snyk.io/scan-application-code/snyk-open-source/snyk-open-source-supported-languages-and-package-managers/snyk-for-python

پکیج پایتونم ادره که اینترفیسش بنظرم افتضاحه و میتونست یک CLI tool باشه
https://github.com/snyk-labs/pysnyk

@ManifoldsPython

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

۱. روش TDD به چه درد میخوره؟‌چرا میگن ۴ برابر حدودا بیشتر طول میکشه؟

چون تو کد زدن معمولی تو اول کد مینویسی و بعدشم نهایتش یک UI Test مینویسی. و تمو میشه میره. کاملا سریع.

ولی تو TDD تو اول میای:
۱. دیزاین میکنی پروداکتو. یعنی بیرونی ترین اینترفیست طبیعتا باید تست شه. مثلا
def calculate_factorial(num) -> int: ...

۲. ‌میای تست مینویسی براش. و حتی با کد دیزاین شدت که هیچی نیست هنوز توش میتونی تستو ران کنی دیگه.

۳. حالا کد میزنی. اینقدر کد میزنی که همه تستات پاس میشن.

۴. مرحله ۲ و ۳ رو تکرار میکنی برای سناریو های مختلف تا کل کدت تکمیل شه


این تستا صرفا unit test نیستن. میتونن UI باشن. میتونه integration test باشه میتونه e2e باشه میتونه application test باشه(مثلا با appium) کلا تو روش TDD میگه محصولی که میدی بیرون باید تست کاوریج خیلی خوبی داشته باشه و از هر جنبه تست شده باشه.

خوب بودن یا نه بستگی به سناریو داره. من شخصا زیاد حال نمیکنم با این روش چون خیلی کنده و بیزنس رو عقب میندازه.یک فیچر میخواد ادد شه کلی طول میکشه. و البته معایبی هم داره اینه که کدتو با توجه به تست مینویسی. یک جورایی بنظرم خلاقیتو کم میکنه حتی. چون خیلی وقتا ادم ‍out of picture یک دفعه میزنه یک ریفکتور سنگین میکنه. اون موقع باید کل تستایی که نوشتی بندازی دور. پس هیچوقت دنبال ریفکتور نمیری(یا بهتره بگم میلت نمیخواد که بری) و همین موضوع باعث کم شدن
خلاقیتت میشه.

و یک نکته دیگه, موقع تست نویسی ما رفتار کد رو بررسی میکنیم. بعضی وقتا ممکنه TDD دقیقا اینطوری پیاده نشه چون حساسیت بیش از حدی داره رو تست نشون میده

@ManifoldsPython

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

تستا کلا ۲ دسته هستند. تستایی که 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