< CyberCesar />

درود دوستان فراموش کردم کپشن این عکس رو بذارم😬 تازگی یه نفر با GPT 6 Astra فتوشاپ رو به طور کامل با صرف دو هزار دلار توکن vibe code کرده و از نو نوشته، ولی رایگان(البته برای ما ایرانیا که فتوشاپشم رایگان بود ولی خب)! برای همین دانلودش کردم و تصویر ریپلای شده رو ساختم. لینک دانلود برنامه اش: https://tenzen.studio/photon/ برخی قسمت ها مثل layer settings به طرز اعجاب آوری دقیق و کامل پیاده شدن، بعضی قسمت ها مثل quick selection و magic wand که ابزارهای مهم و کار راه بنداز فتوشاپن افتضاحن و درست کار نمیکنن. ولی برای یه پروژه تکی و کاملا ساخته شده توسط AI باورنکردنیه.

تنها I can fix him موفق تاریخ این دو تا توی Ben 10 بودن.

یه شب خوب: وقتی همه تست ها(126 تا) پاس میشن🥂

سال تحصیلی جدید مبارک❤️، به یاد دانشجویان و استادانی که امسال پیشمون نیستن💔

هر روز داریم یک قدم به فیلم Wall-E نزدیکتر میشیم💀 (اینکه انسان‌ها بخور و بخواب کنن و ربات‌ها همه کارا رو انجام بدن😬)

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

فرانت‌کارمون از ما بک‌اندکارا به عنوان داده تستی استفاده میکنه💔 به این صورت که صدامون میزنه، تا برمیگردیم عکس میگیره میذاره روی پروژه. برای همین اینجوری دارم نگاه میکنم.

زده free یکیشم free نیست

آقا یکی از تفاوت های stack برنامه نویسی وب و بازیسازی، اینه که نقش ها در برنامه نویسی وب از هم کاملا جدا هستن. البته این به این معنا نیست که کار Back-end کار تاثیری روی کار Front-end کار نداره، به این معناست که جفتشون بدون اینکه ذره ای از کار هم دیگه سوادی داشته باشن، میتونن روی json اتفاق نظر داشته باشن. یعنی فرانت به بک میگه چیا میخواد توی json و تمام! مثلا بک اند کار نمیدونه component چیه و responsive یعنی چی و... از طرفی فرانت کار هیچ تصوری از دیتابیس نداره و نمیدونه چجوری کار میکنه! ولی بازی سازی برعکسه! شما به عنوان یک بازی ساز باید UI بلد باشی تا بازیت توی هر گوشی ای responsive باشه، باید منطق برنامه نویسی و ریاضی بلد باشی، باید دیتابیس بلد باشی، باید شبکه بلد باشی، باید... حالا اون راک استار هست که چین و چروک پیشونی کاراکترا هم یه موقعیت شغلی داره😂. ولی توی بازیسازی اکثر مواقع همه کارا رو خود Programmer انجام میده و تفکیک وظایف به دقت توسعه وب نیست. فوقش اگه کار تیمی باشه، ساخت asset های بازی و طراحیا رو یه artist انجام میده.

5/5 بقیه جاهایی که دوست داریم دیتابیس رو دور بزنیم، بسته به برنامه فرق داره. دو مورد قبلی که گفتم، یعنی نقش کاربر و زبان کاربر، متداول ترین مواردی هستن که روی تک تک درخواست های کاربر به سرور تاثیر دارن و بهتره به هیچ وجه شامل کوئری اضافه نشن! بقیه مواردی که میتونین لحاظ کنین، واحد پول، تقویم، شهر محل سکونت و... هست. مثلا ممکنه در سایت فروشگاهی شما، شهر محل سکونت روی خیلی از API ها تاثیر بذاره و میشه داخل توکن گذاشتش که هر سری نریم از دیتابیس بپرسیم این آقا/خانم اهل کجاست!!!

4/5 دومین مورد: زبان کاربر در واقع علت اینکه این پست رو گذاشتم، این بود که امروز توی شرکت سر این قضیه دچار چالش شدیم! ببینید زبان کاربر یا میتونه توی دیتابیس ذخیره بشه(که هر بار درخواست میده، باید برید ببینید زبانش چیه و بر اون اساس جوابشو بدید! که اصلا کار جالبی نیست و غلطه.) یا اینکه جزو پارامترهای header، بگید زبان مدنظرتون چیه. اگه دقت کنین توی URL ها خیلی به en و fa و... برمیخورید مثل تصویر بالا. اینطوری نیاز نیست دیتابیس بخونه زبان شما چیه.(البته توی سایتی که در تصویر گذاشتم اصلا احراز هویت نداریم و تنها راه انتخاب زبان همینه و شاید مثال های بهتری بشه گذاشت) اما یک روش هیبریدی جالب اینه که زبان کاربر رو ذخیره کنید، ولی سایت یک بار query بزنه و زبان کاربر رو دربیاره در صفحه اول، و بعد برای API های مخلتف همون زبان رو بذاره توی هدر و استفاده کنه(البته جزییات و ظرایف و مشکلات دیگه ای هم داره که در حوصله این مطلب نمی گنجه) اینطوری مثلا کاربر آلمانی زبان میتونه از وبسایت به زبان انگلیسی استفاده کنه و با هر دستگاهی لاگین کنه، انگلیسی باشه و تجربه بهتری داشته باشه. به دیتابیس هم صد بار کوئری نمیزنیم!

4/5 دومین مورد: زبان کاربر در واقع علت اینکه این پست رو گذاشتم، این بود که امروز توی شرکت سر این قضیه دچار چالش شدیم! ببینید زبان کاربر یا میتونه توی دیتابیس ذخیره بشه(که هر بار درخواست میده، باید برید ببینید زبانش چیه و بر اون اساس جوابشو بدید! که اصلا کار جالبی نیست و غلطه.) یا اینکه جزو پارامترهای header، بگید زبان مدنظرتون چیه. اگه دقت کنین توی URL ها خیلی به en و fa و... برمیخورید مثل تصویر سوم. اینطوری نیاز نیست دیتابیس بخونه نقش شما چیه.(البته توی سایتی که در تصویر سوم گذاشتم اصلا احراز هویت نداریم و تنها راه انتخاب زبان همینه و شاید مثال های بهتری بشه گذاشت) اما یک روش هیبریدی جالب که میشه پیاده کرد، اینه که زبان کاربر رو ذخیره کنید، ولی فرانت سایت یک بار query بزنه و زبان کاربر رو دربیاره در صفحه اول سایت، و بعد برای API های مخلتف همون زبان رو بذاره توی هدر و استفاده کنه(البته جزییات و ظرایف و مشکلات دیگه ای هم داره که در حوصله این مطلب نمی گنجه) اینطوری مثلا کاربر آلمانی زبان میتونه از وبسایت به زبان انگلیسی استفاده کنه و با هر دستگاهی لاگین کنه، انگلیسی باشه و تجربه بهتری داشته باشه.

3/5 دیکد کردن این توکن آسونه! ولی برعکسش که یه توکن خاص رو بگیرین و سعی کنین یه قسمتیشو عوض کنین تا بشه چیز موردعلاقه خودتون، به لحاظ محاسباتی به تعداد وحشتناکی حالت داره! مثلا الان من یک حرفو عوض کردم که سعی کنم خودمو از Customer بکنم Admin ولی کلا پیام دیکد شده خراب شد! بدین ترتیب، سرور دیگه نیازی به خوندن role شما در هر بار درخواست شما به سرور نداره. از توکن شما نقشتون رو برمیداره و اصلا به دیتابیس کاری نداره! پس برای تعیین دسترسی، دیتابیس رو در اکثر مواقع دور زدیم.

2/5 اولین مورد: نقش کاربر شما به عنوان کاربر عادی یا ادمین یا... دسترسی های متفاوتی دارین. نقش شما در دیتابیس ذخیره میشه. یک دو دو تا چهار تا که کنیم، این یعنی به ازای هر API و درخواست کاربر، باید بریم توی دیتابیس و ببینیم نقشش چیه! که این پیدا کردن نقش، یعنی شما باید سه تا جدول(تصویر اول) Users UserRoles Roles رو با هم جوین بزنید تا ببینید نقش کاربر چیه! که بشدت کار مسخره ای هست و سرور رو نابود میکنه! حالا راهکار چیه؟ یه چیزی داریم به اسم JWT token که سرور میاد یه پیام رمزشده با رمز یکطرفه به شما میده که توش میاد میگه نقش شما چیه. توی تصویر دوم اگه نگاه کنین، یه پیام انکد شده میبینید که در تصویر سوم دیکد شده. در یکی از فیلدهای تصویر سوم که هایلایت کردم، نقش شما رو نوشته و نوشته Customer. یعنی شما ادمین نیستی، فروشنده هم نیستی. مشتری هستی. خب اینکه خیلی احمقانس! من میرم نقشمو مینویسم admin و میذارم توی توکن!

1/4 فرآیندی که در تصویر بالا می بینید، خلاصه اکثر برنامه های پرکاربر روزانه ماست. به ترتیب در چند مرحله داریم(توی تصویر هم شماره زدم): 1. کاربرانی که یک سری درخواست به سرور میدن(گرفتن لیستی از داده ها، آپدیت اطلاعات یک یا چند داده و...) 2.منطق برنامه(شامل الگوریتم ها و قوانین ما، مثلا برای سرور یک بازی میشه الگوریتم محاسبه امتیاز یا برای یک فروشگاه اینترنتی میشه محاسبه تخفیف و...) 3. دسترسی به دیتابیس برای خواندن یا نوشتن در داده ها. مثل گرفتن لیست آرایشگاه ها در شهر اصفهان. طبیعا در یک برنامه stateful دیتابیس ضروری هست و همیشه بهش کوئری داریم. ولی خب به علت اینکه دیتابیس در دیسک ذخیره میشه (البته در رَم هم کشینگ داریم، ولی خب احتمال miss شدنش هست) و دسترسی به دیسک خیلی از دسترسی به رَم کندتره، ترجیح میدیم بعضی وقتا قسمت سوم رو دور بزنیم و سمتش نریم! در این رشته پیام میخوایم چند نمونه از این موارد رو بررسی کنیم.

درود خدمت دوستان عزیز. توی دوران بی اینترنتی بعد از جنگ، یک بات جرئت حقیقت برای Delta Chat طراحی کردم. حالا تصمیم گرفتم روی گیت هاب قرارش بدم که اگه داخل پیامرسان های دیگه مثل تلگرام دوست دارین، استفاده اش کنین. بخاطر ساختار ماژولارش، میشه فایل bot.py رو به راحتی برای تلگرام بازنویسی کرد و به بقیه قسمتاش دست نزد. بانک سوال نداره ولی داخل README(که توضیحات مختصر و مفیدی داره) دو سه نمونه سوال قرار دادم. لطفا اگه گیت هاب دارین، STAR فراموش نشود🌟 لینک ریپازیتوری: https://github.com/HazardousArash/Truth-or-Dare-Bot-DeltaChat