به بهانه معرفی فریمورک <جای‌خالی> با ۳ برابر سرعت در پاسخگویی نسبت به FastAPI و البته باهدف battery included بودن مثل django

وقتی صحبت از بکند توی پایتون میشه تا همین چندسال قبل تنها گزینه خوب فقط و فقط django بود و مرسی دولوپرهاش؛ تو زمانی که همه غر میزدند پایتون کند هست و نباید و ... (تو ایرانم ازین حرفا زیاد بود) قشنگ یادمه ی بنده خدایی اسم نمیبرم ولی معروفم هست توی یکی از دانشگاها پنل سخنرانی داشت.
گفت که پایتون فقط یک جو هست و خیلی زود هم تموم می‌شه؛ بعد هم ادعا کرد به همین دلیل مطالبش رو نیاورده و ترجیح میده راجب مطالب مهمتر صحبت کنه (سخنرانی به شوخی گذشت و تنها کسی که اعتراض کرد توی سالن ۳۰۰-۴۰۰ نفری من بودم) الان شنیدم همون بنده خدا داره از پایتون نون میخوره و دوره هم میذاره.

بگذریم اومد جلوتر و async معرفی شد؛ هوش مصنوعی از فقط ریسرچ بودن داشت خارج میشد و تجریه دپلوی مهم شد.
دپلوی رو django انقدر سخت و غیر بهینه بود که عملا خیلی از تیم‌هایی که پروژه‌هاشون مشتری کافی رو داشت مجبور به توسعه بکند توی زبان‌های برنامه نویسی دیگه بودند؛ خیلی از بچه ها رفتند سراغ C, C++ , Go-lang و ...
حتی جوگیری زیاد شد مدل هارو سمت وب و موبایل و ... هم بردند که صحبتی نیست.

یادی کنم از شب زنده داری‌ها و دپلوی کدها و مدل‌ها با Majid A.M (آیدی نمیزارم ولی احتمالا هرکی django کار می‌کنه میشناسه) عزیز و حجم اپتیمایز‌های بالا جزو اولین نفرات و تیم‌هایی بودیم که کل مدل هوش مصنوعی و اپتیمایز و وب و ... همه روی پایتون بود و البته دسترسی و درخواست رایگان (این برای زمانی بود که همه میرفتن سراغ C, ... برای دپلوی و کسی باورش نمیشد بشه مدل‌های سنگین رو روی سرور بیاری و اون تعداد ریکوست رو با پایتون جواب بده) اون زمان همه فکر میکردند روی سرورهای خفن و ...هستیم ولی این موضوع رو اولین بار هست دارم اعلام می‌کنم؛
۲ نسخه اول مدل‌های پردازش تصویرمون روی کلاستر رزپبری پای و نسخه آخر روی لپ‌تاپ شخصی بنده بود.

ازین دوران گذشتیم flask با ایده‌های جدید اومد و خوبیش این بود که دیگه به اندازه django سنگین نبود (برای تست‌های کوچیک خیلی جواب بود ولی بازم همون مشکلات رو داشت)
البته اضافه کنم سرویس‌هایی مثل Celery, ... خیلی از مشکلات رو توی django حل می‌کردند

بعد از این زمان FastAPI معرفی شد؛ روی همون کامیت‌های اولیه که عمومی شد چون از بچه‌ها و همکارای بکندم توی شرکت‌های سیلیکون‌ولی و ... بسیار راجبش شنیدم به خیلی از دوستان بکند دولوپرم پیشنهاد کردم که وقتش هست یاد بگیرند و بهش کد donate کنند (کاش خودم اینکارو میکردم) خیلی هم مسخره میکردند. همون Majid A.M جزوشون بود.

به لطف همه‌ی دولوپرهای پروژه‌های قبلی django - flask - fastapi حالا خیلی‌ها باور دارند پایتون می‌تونه توی پروداکشن و برای پروژه‌های بزرگ استفاده بشه؛ خیلی‌ها قبول دارند که میشه با پایتون کد زد و از پکیج‌هایی استفاده کرد که سرعت پردازش بسیار بیشتر بشه .
دولوپرهای پروژه‌های قبلی نشون دادند که توسعه پکیج‌هایی با ایده‌هایی حتی کمی بهتر بسیار ارزش داره و جامعه پایتون همیشه قدردان این زحمات خواهد بود.

تا اینجا که حالا community زبانی مثل Rust برای توسعه یک web framework با سرعت بیشتر و البته به راحتی موارد قبلی برای Python وارد شده و پروژه Robyn رو به حد خوبی رسونده بطوری که امروز توی چندین جلسه مختلف با دوستان و همکاران بسیار درمورد این پروژه شنیدم.
توی مطالبی که داشتم میخوندم و بنچمارک‌هایی که از باقی شنیدم اکثرا اشاره می‌کنند که به راحتی سرعتی ۳ برابر fastapi رو ارائه میده.
از نظر کدهم شخصا یک نگاهی انداختم به همون سادگی هست؛ خلاصه که شمارو نمی‌دونم اما شخصا فکر کردم باید قدردان زحمات تیم‌های توسعه django, flask, fastapi و برو بچه هایی که توی دوران سخنرانی ضد سرعت و ... پایتون با این زبان برنامه نویسی ادامه دادند باشم.

🔷کلیپی کمیاب از نبرد 9 روزه برلین

🔹در نوامبر سال 1941 نیروهای آلمان نازی به 30 کیلومتری قلب مسکو و کاخ کرملین رسیده بودند، حالا 4 سال بعد در چنین روزهایی از آوریل 1945 نیروهای شوروی به دروازه‌های رایش سوم دست یافته بودند، شوروی قوای نزدیک به 1.5 میلیون سرباز را برای عملیات محاصره و سپس فتح برلین آماده کرده بود که از این تعداد نیم میلیون نفر برای جنگ داخل شهر در نظر گرفته شده بودند.

🔹در سمت دیگر رایش سوم با آخرین نیروهای خود که شامل 45 هزارنفر ورماخت، 40 هزارنفر فولکس شتورم(شهروندان برلین که مسلح شده بودند)، نیروهای پلیس و صدها نفر از سازمان نوجوانان هیتلری با مجموع قوای نزدیک به 90 هزارنفر برای دفاع از برلین آماده شده بودند.

▪️تصاویر به وسیله هوش مصنوعی رنگی شده‌اند.

Maverick
@Partisan2015

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

https://www.youtube.com/watch?v=TLHYwbrhGJc

بلاخره منتشر شد
به روز باران...

یکی از چالش های که وقتی با دیتابیس های ( به اصطلاح) 'NoSql' بر می‌خوریم اینکه چطور باید دانشی که در زمینه مدل سازی رابطه‌ای که برامون آشناست به مدلی مناسب برای کار کردن با nosql تبدیل کرد. یه راه خوب اینکه آدم یه مسئله یکسان با دو مدل سازی متفاوت ببینه.

اگر علاقمندید یک مثال نسبتا کامل از یک مدل سازی رابطه ای و معادلش در cassandra رو ببنید؛ فصل پنجم کتاب زیر بخونید

یکی از دیتابیس های no sql آپاچی کاساندرا هست. این دیتابیس از مدل row oriented استفاده می‌کنه. در شروع پیداسازیش برای توزیع داده از dynamo db و دیتا مدلش از Google big table ایده گرفتند.

"You keep on learning and learning, and pretty soon you learn something no one has learned before"

Richard Feynman

دیروز ارائه با عنوان Structured Concurrency
در سمینار #s4 داشتم. خلاصه کلام این بود thread انتزاع(abstraction) خوبی نیست. برای جزئیات بیشتر pdf ارائه رو ببنید

اگر دوست دارید بدونید scope function در Kotlin چی هستند و چطور کار می کنند این ویدیو رو ببنید

https://youtu.be/d0BYBs4JSsE?si=paRnMfo6Mc_YCpHD

جان عزیزتون از uuid استفاده نکنید.

متن زیر خلاصه از روند تاریخی این بلای دیتابیس سوز هست. باید در نظر داشت علاوه بر داستان افزایش حافظه مصرفی، هر ساختاری که از خانواده الگوریتم های B-tree استفاده می کنند رو دچار مشکل میکنه.

https://planetscale.com/blog/the-problem-with-using-a-uuid-primary-key-in-mysql

#UUID

An Illustrated Guide to Covariance and Contravariance in Kotlin

part1: https://typealias.com/guides/illustrated-guide-covariance-contravariance/

part2: https://typealias.com/guides/ins-and-outs-of-generic-variance/

#kotlin
#in
#out