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

https://pypistats.org/


مثلا sqlalchemy تو روز گذشته ۲ میلیون دانلود داشته در حالی که ‍tortoise orm تو یک ماه گذشته کلا ۱۰۰ هزار دانلود داشته. ولی ستاره هاشو باهم مقایسه کنید میبینید فقط sqlalchemy دو برابره tortoise ستاره خورده پس مشخصا sqlalchemy به مراتب خیلی بیشتر استفاده میشه داخل شرکتا تا tortoise

احتمالا بشه امار فیک هم درست کرد پس خیلی objective نگاه نکنید. چیزایی مثل تست و داک و learning curve و دپندسی هاش هم مد نظرتون باشه.

پ.ن:‌آمار دانلود cfcrawler رو میتونید ببینید تو عکس 😁 تا الان ۲۲۵ نفر نصب کردن.

@ManiFoldsPython

سلنیوم رو بندازین دور و از playwright استفاده کنید بلکه به راه راست هدایت شوید!

Playwright: https://playwright.dev/python/

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

یک پست دوست داشتم بنویسم, راجب review کردن و نگه داری یک PR با بست پرکتیس هایی که باید رعایت شه

اولا study نشون داده که شما هرچقدر بیشتر وقت بذارین رو review کردن یک PR همونقدر پروداکتتون جلوتر میفته. یعنی چی؟ مگه میشه؟‌اره خب , شما هرچی زودتر جلوی باگو بگیری زمان کمتری براش صرف میکنی. قبل کد زدن بهترین موقع برای پیدا کردن باگه!‌(یک requirement خیلی خوشگل و تمیز). در درجه بعدی موقع کد زدن و فکر کردن به کدی که میزنید. در درجه بعدی موقع بررسی PR. در درجه بعدی رو dev و بعد رو staging و در نهایت رو پروداکشن. چرا اینو میگم؟‌چون مثلا اگه یک باگی پیدا کنیم که تو staging باشه ولی تو پروداکشن نباشه یعنی یکی از pr ها مشکل بوده. ولی مشکل که بره رو پروداکشن خیلی سخت تر میشه track اش کرد که دقیقا منشا اش کجا بوده و بیشتر طول میکشه چون پهنا بیشتری داره.

حالا سوال اینجاست چیکار کنیم موقع review؟ اولین کاری که میکنید اینه که requirement رو نگاه میکنید و تو ذهنتون آنالیز میکنید چه چیزایی نیازه. بعد رو کد میگردین دنبال edge case. ممکنه حتی تو requirement هم به edge case و باگ برسین! تا اینجا فقط باگای لاجیکاله. در درجه بعدی سعی میکنید تستا رو بخونید. اگه pr ای تست نداره, فیچری تست نداره بهتره اصلا مرج نشه. تستا رو که خوندین حتما کیس هایی هست که دستی باید تست شه حداقل یک بار. کیس هایی که شاید خیلی خوب نمیشد تست اتوماتیک نوشت براش. میرین و checkout میکنید و یک دور تست دستی هم انجام میدین. احتمال اینکه باگ پیدا کنید خیلی زیاد میشه اینطوری. و درنهایت میپردازین به مباحث دیزاین کد و پرفومنس اگه جایی مثلا نیاز به decoupling داشت یا جایی نیاز. بود یک ‍queryبهینه تر نوشته شه.

با این فرمول اگه برین جلو اکثر مواقع PR به ‍changes requested میخوره مخصوصا برای نیروی جدید. سعی کنید یک PR رو خیلی گنده نکنید چون review اش خیلی سخت تر میشه و احتمال پیدا کردن باگ کمتر.
یک مشکل دیگه که خیلیا انجام میدن اینه که داخل PR میان بیشتر از تایتلش انجام میدن. مثلا طبق git flow مشخصه یک PR چه چیزایی میتونه باشه. یک pr همزمان نباید هم یک issue رو درست کنه هم یک فیچر اضافه کنه. اگه وسط توسعه به اون issue رسیدین و شناساییش کردین باید یک برنچ جدا بسازین, اون ایشو رو اونجا درست کنید با تست فیل و cherry pick کنیدش رو برنچ فیچری که داشتین کار میکردین که جداگانه review شه و سریعتر مرج شه.

@ManiFoldsPython

این کالچر خیلی جا داره تو ایران قوی شه و واقعا کیفیت یک پروداکت رو به مراتب خیلی بیشتر میکنه... طبق چیزی که از بچه ها میشنوم اکثرا تو شرکت ایرانی میبینن تست پاس شده approve میکنن. خب چرا زحمت میدین به خودتون؟‌یک گیت هاب اکشن بنویسید هر pr ای تستاش انجام شد approve شه دیگه 😁 یا اکثرا موقع بررسی pr فکر میکنن فقط باید ایراد به دیزاین و پرفومنس بگیرن. در صورتی که خوده کد کلا کار نمیکنه چه برسه به اینکه بخواد خوشگل باشه یا سریع.
@ManiFoldsPython

خیلی ویدیو باحالیه
این ویدیو به شما نشون میده که تو دنیای امنیت:
۱. کلمه boundary چیه؟
۲. کلمه آسیب پذیری چیه
۳. کلمه ضعف امنیتی چیه

https://youtu.be/LxUAnZY_08o?si=iD2nvFhyJwmEJ6Do

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

@ManiFoldsPython

یک میم خیلی جالب راجب همین موضوع :))

توصیه میکنم حتما ویدیو رو ببینید
@ManiFoldsPython

یک سوال ذهنمو درگیر کرده از دیروز اصلا میتونه سیستم پیچیده ای یک پروداکتی باشه که event driven نباشه؟ من حس میکنم جواب این سوال نه هست.

@ManiFoldsPython

برای پیدا کردن شغل میتونید از Xing هم استفاده کنید
یک نوع لینکدینه ولی تو آلمان خیلی محبوب تره
معمولا رنج حقوق و بودجه هم رو اگهی درج میشه

شغل ریموتم شاید تونستین پیدا کنید.
xing.com
@ManiFoldsPython

کی از class استفاده کنیم و کی از فانکشن؟
سوالیه که معمولا من دیدم تو مصاحبه ها میپرسن اکثرا جواب خوبی نمیدن. یا اصلا خودشون هم واقعا نمیدونن.

این ویدیو کوتاه طرز فکره منه دقیقا و خیلی خوب گفته:
https://www.youtube.com/shorts/oIyq0q5Q7eo

@ManiFoldsPython

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

کار خیلی جذابی شده

این پکیج قابلیت اینو داره که یک سری آبجکت جنگویی بگیره
و برای شما import رو تو سلری انجام بده که خیلی سریع باشه (چون write هست خیلی کندتر میشه) -> با csv
حتی export هم میتونه تو سلری انجام بگیره ولی طبیعتا یک جایی باید ذخیره شه. ->‌ با csv


فوایدش:
۱. با pydantic کار میکنه کاملا
۲. ترتیب csv تونو مهم نیست. مثلا تو این کیس میتونید اول Port رو بذارین بعد Ip. بر اساس هدر csvتون تصمیم میگیره و منیج میکنه 😁
۳. راحت باهاش میتونید example بسازین و جنریت کنید و بدین فرانت
۴. اول کامل دیتا رو ولیدیت میکنه و اگه اوکی بود اونوقت میتونید بندازین رو سلری

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

@ManiFoldsPython

بچه ها واقعا ممنون میشم اگه ui ux دیزاینری میشناسید این پستو براش بفرستین.
من دنبال فرانت کار نیستم, دنبال کسیم که تخصصی ui ux بلده و بتونه e2e ux flow رو کامل پیاده سازی کنه برای یک پروداکت.
اگه شخصی میشناختین که ممکنه حتی لید دیزاینه و دستمزدش بالا هست, یا حتی مشغول باشه, بازم خوشحال میشم به صورت مشاور باهامون همکاری کنه.

@ManifoldsPython

حالا یک سوال پایتونی نسبتا خیلی راحت
کدی که زدم رو ببینید

چرا آبجکت pydantic_model بدون اینکه بهش تایپ بدم تایپ داره؟
@ManiFoldsPython

from typing import TypeVar, Generic,Type
from pydantic import BaseModel
from django.db import Model

TModel = TypeVar("TModel", bound=Model)
TPydanticModel = TypeVar("TPydanticModel", bound=BaseModel)

class CsvOps(ABC, Generic[TModel, TPydanticModel]): 
     db_model: Type[TModel]
     base_model: Type[TPydanticModel]
  
     def create_in_db(self, pydantic_model: TPydanticModel) -> None: ...

این میشه جوابش. ترکیبی از جنریک و TypeVar

type hint >>>>>>

پ.ن:‌حتی نیازی نبود من db_model و base_model رو تعریف کنم. میتونستم همونطور که IDE میگیره از جنریکش بگیرم. منتهی too magic میشد و میخواستم زودتر کدو بزنم تموم شه بره پی کارش. الان اگه یک وقت گاف بدم (جنریک کلس با db_model یکی نباشه تایپش مثلا) خود ide بهم وارنینگ میده.

@ManiFoldsPython

نکنید اینکارو... من قلبم ضعیفه :))

staging/dev داشته باشین حتما

خوب رو staging تست کنید. دستی تست کنید. تست اتوماتیک به این منظور نیست که تست دستیو ببوسین بذارین کنار. سناریو های پیچیده تری که سخته اتوماتیک تست شن بهتره دستی تست شن. اگه میبینید تستی تو اتوماتیک واقعا requirementتون رو خوب assert نمیکنه و اعتماد به نفس نمیده پس پاکش کنید و دستی تست کنید.

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

تست نویسی فقط unit نیست. با انواع تستا آشنا شین و سعی کنید داشته باشین

@ManiFoldsPython

این مسیر roadmap بک انده. خیلی استاندارد و تمیزه. از سایت roadmap.sh. بهتر از این من ندیدم جایی. یکم کلاد و دوآپس هم بهش اضافه کنید.

اینا رو شما باید بلد باشین. اما بلد بودن چند درجه داره. در درجه اول اینه که اسمشو شنیده باشین. توصیه میکنم حداقل ۳-۴ روز راجب تک تک آیتم های تو این رودمپ یک تحقیق کنید که بدونید چی هستن تا مسیر براتون مشخص باشه.
در درجه دوم شما یک استفاده کوچیک کردین. مثلا تو سلری بروکر رو گذاشتین ریبت. تا اینجا اصلا بلد نیستین درواقع.
تو مرحله سوم شما کمی عمیقتر میشین. ازش استفاده میکنید و چالش هایی تو استفاده ازش بهش برمیخورین. مقاله مختلف میخونید و کارتونو درمیارین. میتونید راجب اون چیز حداقل ۲۰ دقیقه حرف بزنید. بگن ربیت چیه میتونید ۲۰ دقیقه توضیح بدین. تو این level شما یک دانش کاربردی و مختصر دارین. و در نهایت شما کتاب میخونید. عمیق تر میشین. تو پروداکتتون استفاده پیچیده تر میکنید و باهاش بیشتر دست و پنجه نرم میکنید. و تو مرحله اخرم میرین internal اش رو میخونید و حتی contribute میکنید که میشین اکسپرت اون چیز.

@ManiFoldPython

حالا اینکه چقدر یک چیزی رو یاد بگیرین میذارم با قضاوت خودتون. از gpt برای یافتن ریسورس کمک بگیرین. از amazon و گوگل برای دیدن rate و review یک کتاب کمک بگیرین. از مدیوم برای خوندن مقاله های خوب و محبوب. و از گوگل برای پیدا کردن مقاله متنوع تر.

تو گروه ها و جمع ها contribute کنید چون به پیشرفت سطحتون خیلی کمک میکنه و peer effect هم داره براتون
@ManiFoldsPython

یک نکته اگه دوست داشتین رعایت کنید خیلی به سطح پستای کانال کمک میکنه 🙏
اگه از یک تایپ پست خوشتون میاد reaction مثبت بدین. اگه نمیاد ری اکشن منفی بدین. من بر اساس ری اکشن و تعداد forward و کامنت و سوالایی که ازم تو پیوی میپرسن معمولا تصمیم میگیرم چه پستی مناسب تره.

@ManiFoldsPython