تا حالا به این فکر کردید که فرق بین کولیشن utf8mb4_0900_ai_ci و utf8mb4_bin دقیقا چیه؟ یا همینطور بقیه کولیشن ها؟

کولیشن utf8mb4_0900_ai_ci: کولیشن پیش‌فرض MySQL 8 برای utf8mb4.
معنی اسم:
0900 → بر اساس Unicode 9.0.0
ai → accent insensitive (تفاوت حروف با/بدون لهجه رو نادیده می‌گیره)
ci → case insensitive (تفاوت حروف بزرگ و کوچک رو نادیده می‌گیره)
یعنی:
'a' = 'A'
'é' = 'e'
پس برای سرچ و مقایسه، راحت‌تره چون نرمال‌سازی بیشتری می‌کنه.

کولیشن utf8mb4_bin: کولیشن باینری برای utf8mb4.
اینجا همه‌چیز دقیقا بایت به بایت مقایسه میشه.
یعنی case-sensitive و accent-sensitive:
'a' != 'A'
'é' != 'e'
معمولا برای جاهایی که شناسه‌ها (ID، Token، UUID، Hash، آدرس والت و ...) ذخیره می‌شن استفاده میشه، چون اونجا نباید نرمال‌سازی بشه.

خلاصه:
کولیشن utf8mb4_0900_ai_ci: مناسب برای داده‌های متنی کاربر (نام، توضیحات، محتوا) → جستجو راحت‌تر.

کولیشن utf8mb4_bin: مناسب برای داده‌های حساس به حروف/بایت (شناسه، کلید، رمز، UUID، مقایسه دقیق).

یک قانون عملی:
متن قابل خواندن توسط کاربر → utf8mb4_0900_ai_ci
داده‌ی تکنیکال/یونیک → utf8mb4_bin

@DevTwitter | <Abbas Goudarzi/>

قلم پست‌های فارسی پلتفرم اکس به «وزیرمتن» تغییر کرد — فونتی که توسط صابر راستی‌کردار، طراح خلاق و از چهره‌های دوست‌داشتنی جامعه‌ی نرم‌افزار آزاد و متن‌باز طراحی شده بود.
صابر متأسفانه در ۳۶سالگی بر اثر سرطان از دنیا رفت، اما اثرش همچنان در گوشه‌گوشه‌ی اینترنت زنده‌ست.

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

سایت Namecheap دامنه‌های ‎.site، ‎.online و ‎.store رو برای مدت محدودی، بصورت یک‌ساله رایگان می‌ده!
کد تخفیف: FREEDOMAIN25
🔗 namecheap.com/lp/winback

دوستان یادآور شدن که ۰.۲۰ دلار ICANN FEE می‌گیره و کاملاً رایگان نیست. یه پرداخت ریز باید انجام بدین.

به شخصه وقتی دارم BUG REPORT SUBMISSION FORM درست می‌کنم، همیشه یه چیزو اجباری می‌کنم: افزودن فایل اسکرین‌شات یا ویدئوشات. چون یه تصویر یا ویدئو می‌تونه به تنهایی کل داستان باگ رو بگه. بدونش، همه توضیحات متنی ممکنه ناقص یا گمراه‌کننده باشه.

نتیجه‌ش چیه؟

— سرعت فهم مشکل حداقل ۳ برابر می‌شه.
— دولوپرها خوشحال‌ترن، چون لازم نیست حدس بزنن کجا، چی اتفاق افتاده.
— حتی باعث می‌شه تیم QA و توسعه‌دهنده با هم راحت‌تر ارتباط برقرار کنن و اشتباهات کمتر پیش بیاد.

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

و یه نکته برای QAها: بدون ترس این فیلد رو اجباری کنین. بذارین همه بفهمن که این دیتا برای شما مهمه و ارزش داره.

گاهی تست‌ها به تست نیاز دارن.
نه به خاطر اینکه باگ دارن، بلکه چون فرضیات ما ممکنه اشتباه باشه. 🧠

برای همینه که همیشه باید به خود تست‌ها هم شک کرد — حتی به تست‌های خوب.

گاهی یه تست ظاهراً درست کار می‌کنه — پاس میشه، لاجیکش درسته، assertionها سر جاشن — ولی در واقع چیز اشتباهی رو می‌سنجیم یا شرایط واقعی سیستم رو بازنمایی نمی‌کنیم.
یعنی ظاهر تست خوبه، اما هدفش اشتباهه یا ناقصه. مثلاً تست به جای بررسی behavior، فقط implementation رو تأیید می‌کنه.

پس یه وقتا تستا هم خودشون باگ دارن، چون کسی تستشون نمی‌کنه.

یه قابلیت کمترشناخته‌شده از تلگرام:

اگه ته لینک یه چنل پارامتر ‎?direct‎ رو اضافه کنی، وقتی کسی روی لینک بزنه، مستقیماً صفحه دایرکت اون چنل براش باز میشه (یعنی همون جایی که میشه پیام خصوصی فرستاد).

برای مثال:
🔗 ‎https://news.1rj.ru/str/rezachannel?direct

اگه بخوای برای چنل خودت بسازی، فقط کافیه یوزرنیم چنل رو جای rezachannel بذاری. قاعدتاً باید روی چنلت قابلیت Direct Message فعال شده باشه.

هر کسی داره با غمی می‌جنگه که ما ازش خبر نداریم.

اگه فرانت‌اند کار هستید و به همکاری در پروژه‌های اوپن‌سورس علاقه دارید، تیم مرزنشین کامیونیتی برای انجام چند تسک ساده به دنبال چند نفر هم‌تیمیه. برای هماهنگی لطفاً با آیدی @iammirzam در ارتباط باشید. با تشکر.

بزرگسالی اونجایی برات اتفاق میوفته که دیگه فست‌فود برات جالب نیست، فقط کباب کوبیده.

من میگذرم، بذار طرف فکر کنه برده.

به اون کاری که امروز کردی نگو "ریفکتور" (Refactor). اگه تست نداره، اون فقط یه "گندکاریِ تمیزه".
این فقط یه جمله‌ی قشنگ نیست؛ این یه زخمه که من هنوز یادمه.
اوایل کارم، میخواستم قهرمان باشم. ‍️ تو یه پروژه‌ی لگسی، یه "God Function" هزار خطی پیدا کردم و گفتم: "من اینو تمیز میکنم!"
نشستم و تیکه‌تیکه‌اش کردم. ۵۰ تا تابع کوچولوی تر و تمیز. اصل DRY رو پیاده کردم. ظاهر کد عالی شد. "تمیز" و "حرفه‌ای". احساس غرور میکردم.
مشکل چی بود؟ اون کد اصلی لعنتی، یه دونه هم تست خودکار نداشت.
اونجا بود که فاجعه اتفاق افتاد. کاری که من انجام دادم، "ریفکتور" نبود؛ "تغییر دادنِ کورکورانه" بود.
اون کد "تمیز" من، چند تا باگ جدید و پنهان داشت. چرا؟ چون اون "کد اسپاگتی" زشت، پر از منطق‌های تجاری پنهان و وابستگی‌های زمانی بود که فقط تو همون حالت کار میکرد.
من "بدهی فنی" رو پرداخت نکردم؛ من یه بدهی کم‌بهره (مثل تکرار کد که فهمیدنش ساده بود) رو برداشتم و با یه بدهی پربهره (مثل یه "انتزاع اشتباه" که حالا دیباگ کردنش غیرممکنه) عوض کردم.
این "تله‌ی کد تمیز"ئه. مهم‌ترین تعریفی که تو این صنعت باید بلد باشیم مال مایکل فدرز (Michael Feathers) ئه: "کد لگسی، کدیه که تست نداره." همین.
تو یه سیستم لگسی، قانون اول "تمیز کن" نیست. قانون اول اینه: "اول امنش کن." برو "تست‌های مشخصه‌یابی" (Characterization Tests) بنویس تا رفتار فعلیِ سیستم (با همه‌ی باگ‌هاش) رو قفل کنی. وقتی اون تور ایمنی رو ساختی، اونوقت حق داری که شروع به تمیزکاری کنی.

@DevTwitter | <Hossein Moradi/>

ریفکتور بدون تست، اسمش ریفکتور نیست. تغییرِ کورکورانه‌ست.
وقتی هیچ تستی وجود نداره، تو حتی نمی‌تونی بفهمی رفتاری که از قبل درست بوده هنوز درسته یا نه. ظاهر کد شاید بهتر بشه، اما رفتار سیستم ممکنه بی‌صدا خراب شده باشه.

این یک قاعده‌ست:
اول رفتار فعلی سیستم رو با تست‌هات لاک کن، بعد ساختار رو تغییر بده.
بدون این کار، هر تغییری می‌تونه باگ‌های جدید بسازه، منطق‌های پنهان رو بشکنه و Technical debt رو بیشتر کنه.

ریفکتور فقط زمانی معنی داره که “رفتار ثابت بماند”.
و بدون تست، هیچ تضمینی برای این جمله وجود نداره.

گوگل پلی، مارکت اصلی دانلود نرم‌افزار برای اندروید، در نسخه ۴۸.۸ خود قابلیتی اضافه کرده که به کاربران امکان می‌دهد برنامه‌ها را مستقیماً از دستگاه‌های دیگر متصل به همان حساب گوگل، بدون نیاز به دسترسی فیزیکی به آن دستگاه‌ها، حذف کنند.
این قابلیت با افزودن دکمه "حذف نصب" در صفحه هر برنامه در پلی‌استور برای دستگاه‌های مختلف، کار می‌کند و مدیریت برنامه‌های نصب شده روی دستگاه‌های متعدد را ساده‌تر می‌سازد.
این ویژگی به تدریج برای همه کاربران منتشر می‌شود.
همچنین، از سال ۲۰۲۶ برنامه‌های پرمصرف باتری با برچسب هشدار نمایش داده خواهند شد.

منبع: jetstream.blog

بوی کد (Code Smell)
(وقتی کد درست کار می‌کنه، اما یه جاییش بو میده)

گاهی برنامه بدون خطا اجرا می‌شه، خروجی هم درسته، ولی یه حس ناخوشایند توی کد هست؛ چیزی که روی کاغذ مشکل فنی نیست، اما از دید مهندسی «یه چیزی سر جاش نیست».
این همون بوی کده؛ نشونه‌ای ظریف که میگه پشت ظاهر سالم، یه ضعف طراحی یا یه تصمیم اشتباه خوابیده.

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

بوی کد لزوماً یعنی «کد بده» نیست؛ بلکه یه «هشدار زودهنگام»ه.
میگه شاید وقتشه ساده‌ترش کنی، ساختارش رو بهتر کنی، یا حتی کل بخش رو دوباره طراحی کنی.

آخرش هم اینه:
کد خوب فقط درست کار نمی‌کنه؛ باید قابل فهم و قابل اعتماد هم باشه.
جایی که مهندسی و فهم انسانی با هم هماهنگ میشن، همون‌جاست که کد واقعاً کیفیت پیدا می‌کنه.