۲ سال پیش، در همین روز gpt منتشر شد. ۲ سال گذشته و هنوز بعضیا نگرانن جاشون رو GPT ممکنه بگیره تقریبا این سوالو روزی ۱۰ بار میشنوم. اما حقیقت اینه که GPT در حال حاضر یک درصد کاره پروداکت هم نتونسته بکنه بعد از ۲ سال توسعه. توسعه یک پروداکت تو یک تیم پروداکت…

بچه هایی که نگران هوش مصنوعی هستن من حقیقتا نمی خواستم این راهو افشا ولی خب دیگ دلم نیومد به شما نگم

ببینید من یه پلنی دارم که مدت هاست دارم بهش فکر می کنم
فرض کنید یهو یه هوش مصنوعی می‌آد که می‌تونه همه برنامه نویسا رو بی کار کنه مثلا همین https://devin.ai/
فرض کنید خیلی پیشرفته تر شه

حالا من یهو می‌رم ازش می‌خوام که خودش رو بسازه به اسم
https://beni.ai/
بعد منم میلیونر می‌شم

همین دیگ
فقط لطفا به کسی نگین

@BenDevelop

یک نقل قول (و حق) دیگه از پرایم
اگه از AI استفاده میکنید toolbox تون باشه، نه boxتون!

به زبون ساده تر، از AI مثل یک جعبه ابزار استفاده کنید. نه اینکه کامل بهش وابسته باشین.

ما به طور کلی دو مشکل داریم وقتی کد میزنیم،

یا داریم به کامپیوتر میگیم چیکار کنه. مثلا اگه رو این دکمه کلیک کردم، یک modal باز شه. فریم ورک و AI و جعبه ابزار هایی که داریم، به ما تو این مسیر کمک میکنن. این کاره خیلی سختی نیست. بالاخره از پسش برمیایم.

یا داریم فکر میکنیم که کامپیوتر باید چیکار کنه. اصل پیچیدگی کار ما همینجاست. و تو این مورد AI اصلا نباید و نمیتونه کمکتون کنه!

@PyBackendHub

یک باگ خیلی مزخرف تو pylance که هنوز بعد ۳ ماه اصلاح نشده هنوز

وقتی type alias دارین تو پروژتون, دیگه تو یک فایل دیگه وقتی میخواین ایمپورتش کنید suggest بهتون نمیده.
اگه pylanceتون رو به نسخه 2024.9.2 داونگرید کنید درست میشه.

@PyBackendHub

خیلیا منظور این متن رو متوجه نشدن، قرار نیست شما انجین دیتابیس بنویسی. ولی همین که بدونی چیه و بتونی راجبش ۵ دقیقه حرف بزنی خیلی مهمه چون بیشتر روز باهاش درگیری. یا بهتره خوده raw sql رو یاد بگیری تا اینکه orm django رو بدون یاد گرفتن sql استفاده کنی ازش.
ایا میشه بدون دونستن sql از جنگو استفاده کرد؟ بله. آیا در این صورت شما skilled worker محسوب‌میشین؟ نه.

خیلی وقتا ممکنه بخاطر دانش بیشترتون، یک راهکار بهتر به ذهنتون برسه که برد بزرگی رو برای بیزنس رقم بزنه. به خاطر دانش بیشترتون، کدتون ممکنه باگ کمتری داشته باشه که براتون پروموشن خواهد داشت. و …

نقل قول ازنظرر Kurt Guntheroth، با ۴۰ سال سابقه و نویسنده چند کتاب معروف:

Some software jobs you can get after a 2-year Associate’s Degree from a community college, or a 9-month boot camp, just like a blue-collar job.
Some software jobs don’t require much independent thought and analysis. How hard is it to arrange content on a web site? (Yes, I know, as hard as you want to make it. But not always).
Some software jobs are done in assembly-line fashion. Pull the next feature card off the stack and start coding, pull the next bug report off the list and start looking for a fix. Your job has no beginning and no end, just an endless stream of little tasks (called sprints), with no time to rest in between, just like a blue-collar job.
Some bosses of software people are Dickensian horrors, driving their team to work long, uncompensated hours. Never a word of praise, but the sure prospect of getting fired for not toeing the mark, just like a blue-collar job.
But those same bosses will insist software is a white collar job, because if it ever did become a blue-collar job, they would have to pay time-and-a-half for overtime (in the US).
I think what’s true is that the software profession is diverging into two levels of skill, professional software developers, and programmers. Once upon a time it was like this, but the original reason for programmers (typing code onto punch cards and running it on batch terminals) went away. Now we’ve got easy problems solved by programmers with limited education, and really hard problems, solved by highly educated and trained professionals.

@PyBackendHub

یکی از اشتباهات رایج و خیلی بد تو دیزاین دیتابیس که من دیدم خیلی انجام میدن اینه که سعی میکنن state یک entity رو با چند boolean ست کنند.
مثلا برای یوزر داریم:
is_active
is_banned
یا شما میتونی برای پردازش یک دیتایی اینطوری هم ذخیره کنی:
is_pending
is_success

اما خیلی پرکتیس بدیه. چرا؟ به ۲ دلیل:
۱. حالت هایی به وجود میاد از ترکیب این boolean ها که رخ دادنش ممکن نیست. مثلا چطوری میشه is_pending=true باشه و is_success هم true باشه؟ حالا هرچی جلوتر برید و تعداد boolean هاتون بیشتر شه این ترکیب هایی که امکان رخ دادنشون وجود نداره خیلی بیشتر میشه. مثلا ۴ تا boolean میشه ۱۶ حالت. آیا واقعا همه ۱۶ حالت رو دارین؟!
۲. راه حل دوم خیلی بهتره! راه حل دوم چیه؟‌استفاده از یک Enum تو دیتابیستون.

PENDING
SUCCESS
FAILED

حالا یک جایی نیازه که ایمیل بزنید اگه این پردازش موفقیت آمیز نبود. خیلی راحت میتونید رو همه حالت ها match case کنید. و در نهایت یک assert never هم قرار بدید.
اینطوری فردا اگه یک state جدید اضافه کنید به اپلیکیشنتون, همه جای کدتون ارور تایپینگ میخورید تا مجبور شید رفتار و ساید افکت state جدید رو تو همه جا هندل کنید.

```

match state:
case State.FAILED:
email_to_user()
case State.SUCCESS | State.FAILED:
pass # do nothing
case _:
assert_never(state)

```

@PyBackendHub

یکی از دلایل اصلی که این لایبری رو نوشتم این بود:

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

همین موضوع راجب view هم رخ میده. که دلایلش داکیومنت شده اینجا که چرا این موضوع fail میشه.

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

@PyBackendHub

امروز خیلی خوشحالم که بالاخره Naked SQLAlchemy رو معرفی میکنم، یه thin wrapper روی SQLAlchemy Core که کار با دیتابیس‌ها تو پایتون رو ساده‌تر می‌کنه. بعد از اینکه با pitfallهای ORM مواجه شدم—مثل اینکه داده‌های توی حافظه با وضعیت واقعی دیتابیس یکی نبود به خاطر پیچیدگی‌هایی مثل identity mapping و dirty tracking—فهمیدم این ویژگی‌هایی که قرار بوده کار رو راحت کنن، در واقع باعث پیچیدگی و سخت‌تر شدن یادگیری می‌شن. Naked SQLAlchemy با ترویج استفاده صریح از SQL و map مستقیم نتایج کوئری به dataclassهای پایتون، این لایه‌های غیرضروری رو کنار می‌زنه.

علاوه بر بهبود سرعت قابل توجه (تقریباً دو برابر سریع‌تر از ORM)، یادگیری Naked SQLAlchemy آسونه چون بر پایه دانشی هست که احتمالاً از قبل داری. امکاناتی مثل مپ کردن dataclass، مدیریت session بدون داشتن state، و امکان تعریف SQL View رو لایه ORM. با تمرکز روی ویژگی‌های اساسی و دوری از abstractionهای پیچیده، به شما این امکان رو می‌ده که کدهای واضح و ‍explicit و قابل نگهداری بنویسن، بدون دردسرهای معمول ORM.

فلسفه من اینه که کمتر، بیشتره. با کنار گذاشتن لایه‌های غیرضروری، Naked SQLAlchemy یه راهکار قابل اعتماد، کارآمد و ساده برای دسترسی به دیتابیس تو پایتون ارائه می‌ده. اگه دنبال ابزاری هستی که از pitfallهای معمول ORM دوری کنه و از تخصص SQLی که از قبل داری استفاده کنه، دعوتت می‌کنم Naked SQLAlchemy رو امتحان کنی.

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

@PyBackendHub

سادگی همیشه خبر از پیچیدگی میده!

خیلی وقت‌ها ما از کتابخونه و فریم‌ورک‌ها استفاده میکنیم به خاطر اینکه یک کار رو ساده میشه باهاشون انجام داد، از جنگو استفاده میکنیم چون کار باهاش راحته، داخل جنگو از DRF و simple jwt استفاده میکنیم چون ساخت api و لاگین رو برامون خیلی راحت میکنن. اما اینجا یک چیزی گاهی فراموش میشه.

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

و شاید بگید خوب این خوبه دیگه یارو کد برای ما زده و استفاده می‌کنیم و لذتشو میبریم. تو خیلی از مواقع این درسته، ولی امان از اون روزی که بخوایید یکچیزی رو تغییر بدید که فریم‌ورک/کتابخونه براتون انجام داده :) اونجاست که این سادگی که ازش لذت میبردید تبدیل کابوس میشه :D

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

این گفتم که بدونید همیشه هر سادگی خوب نیست، گاهی بهتره تن به کار بدید و اون کد خودتون بزنید تا با نیاز شما هماهنگ باشه نه اینکه یک کتابخونه هزارخطی نصب کنید تا از ۱۰۰ خطش استفاده کنید.

@TorhamDevCH