اگه دوست دارید بدونید که چرا توی چند سال گذشته انقدر نسبت به مدل SPA ساده (همون React خودمون) تغییر داشتیم، این ویدیو خوب و کامل این قضیه رو توضیح میده

https://youtu.be/Cifkb-ZVps4?si=aG3gmU-rmEoFW3Op

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

یه ویدیو خیلی خوب از فیچر های ریکت ۱۹
توضیحاتی که راجع به Transition و action و ارتباط بینشون میده خیلی جالبه

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

در ادامه همین ویدیو میتونید به صورت عملی کاربر
Transition
Action
useActionState
useOptimistic
رو هم به صورت کلاینت ساید و هم به صورت سرور ساید ببینید

نکته جالب این ویدیو اینه که شروعش با مدل هندل کردن form submition توی ریکت قبل از ۱۹ هست
و بعد تبدیلش میکنه به مدل جدید

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

این ویدیو خیلی میتونه بهتون برای درک caching توی NextJS app router کمک کنه
ولی حتما در کنارش داک next رو هم برای cache چک کنید چون ممکنه api اش تغییر کرده باشه
https://www.youtube.com/watch?v=VBlSe8tvg4U

توی دقیقه ۱۷ یه دیاگرام داره که خیلی خوب میتونه بهتون فرقی page router و app router رو نشون بده و کمک میکنه مدل ذهنی اش رو بسازید

Authorization methods

Authorization can be implemented in two ways:

RBAC (role-based action control): Specify what actions each role can take on different resources.

i.e in a blogging system:
- viewer (role) can view (action) posts (resource)
- editor (role) can view, create, and edit (actions) posts (resource)
- admin (role) can view, create, edit and delete (actions) posts (resource)

ABAC (attribute-based access control): A more flexible method that considers attributes of user, resource, and context (external factors) rather than simple roles.

i.e. in a blogging system:
- A senior (attribute) editor (role) can edit draft (attribute) posts (resource) between Monday and Friday (context)


You can find a simple RBAC implementation in the attached image.

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

بهترین قسمتش به نظرم این تیکه از جمع بندی آخرش بود

AI is a tool, it is not good or bad in itself, it’s what you do with it. I do think it can be a great tool, as long as you are not reliant on it for your workflow. Make sure you can still work effectively without it, make sure you don’t push code to production that you don’t fully understand and don’t think of AI as a replacement for your own thinking. Stay curious, keep learning.

https://lucianonooijen.com/blog/why-i-stopped-using-ai-code-editors/

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

توی این ویدیو هم میتونید مقاله رو با primeagen ببینید
https://www.youtube.com/watch?v=y3_TY4K8hVE&t=776s

احتمالاً پیش اومده براتون که پسورد یه سایتی یا اپلیکشینی که استفاده میکنین رو فراموش کرده باشید و بخواین Reset password کنین. ولی وقتی پسورد جدید رو میزنین، یه همچین پیامی میگیرید:

Your new password is too similar to your current password. Please try another password.

من اصلاً بهش توجه‌ای نمیکردم که چطور پیاده سازی میشه همچین چیزی. تا اینکه یه روز توی توییتر دیدم یکی پرسیده مگه پسورد رو Hash نمیکنین؟ پس چطور میتونین بفهمید پسورد جدید شبیه پسورد قدیدیمه Hash شده‌س؟!

ما وقتی پسورد یوزر هارو توی دیتابیس ذخیره میکنیم، نباید به صورت Plain text ذخیره کنیم. اگر به هر صورتی هک بکشیم، اینطوری کل اطلاعات یوزر های ما با یک نگاه بر باد میره. به این هم توجه کنین اکثر آدم ها از یک پسورد برای همه چیز استفاده میکنن یا پسورد هاشون توی سایت های مختلفی که استفاده میکنن خیلی شبیه به هم دیگه‌س. پس خیلی بهتره که پسورد هارو Hash کنیم.
خود Hash کردن داستان زیاد داره. حتی با Hash کردن خالی، پسورد ها هنوز تا حدی قابل حدسه! (Rainbow attack table) حتی یه سری Vulnerability خیلی خفن و عجیب مثل Timing attack password hashing وجود دارن که باید حواسمون بهش باشه. داستانش طولانیه و اگر دوس داشتین میتونم توی یه پست دیگه راجب اونم بنویسم مفصل.

اما علی‌الحساب باید چنتا نکته راجب Hashing functions بدونیم تا بهتر قضیه رو متوجه بشیم.
- یکی از ویژگی های یک Hashing function اینه که باید یک طرفه باشه. ینی وقتی من بهش A رو میدم و اون فانکشن بهم B رو برگردونه، راهی نباید باشه که من از B به A برسم.
- اندازه output که توسط Hashing function برمیگرده باید مستقل از input باشه و همیشه باید ثابت باشه. فرقی نداره که input ما چقدره.
- با کوچیک ترین تغییر input، مقدار output باید کاملاً متفاوت باشه. برای مثال:

hash("abcd") -> "JPtLwmkTrHfnH"
hash("abdc") -> "VqdmWPHCZAPdN"

حالا که همه‌ی اینارو میدونیم، به این فکر میکنیم که چطور وقتی پیام

Your new password is too similar to your current password. Please try another password.

رو میگیریم باید تعجب کنیم! مقدار Hash شده‌ی پسورد سابق ما، قابل مقایسه با پسورد جدید نیست. (چون همونطور که گفتیم با کوچیک ترین تغییر input، باید output کاملاً عوض بشه). پس تنها راهی که میتونیم مقایسه‌شون کنیم اینه که پسورد رو plain ذخیره کنیم! درسته؟ خیر:))) چنتا راه هست که این کارو به صورت امن انجام بدیم.

یه راه حلی برای مثال Facebook انجام میده اینه:
۱. شما پسورد اکانتتون برای مثال "first" هست.
۲. اقدام به عوض کردن پسوردتون میکنین و پسورد جدید رو "First2" وارد میکنین.
۳. اینجا Facebook میاد از پسورد جدید که وارد کردید، یه سری پسورد مشابه میسازه. برای مثال:
"first2", "FIRST2", "Ffirst23", ...

۴. برای هر کدوم از این پسورد هایی که ساخته خودش، Hash شون رو حساب میکنه و با Hash پسورد فعلی مقایسه‌شون میکنه.
۵. اگر پسورد جدید شما خیلی مشابه پسورد فعلی باشه، امکان داره اون الگوریتم ساخت پسورد های مشابه، پسورد سابق شمارو بسازه! توی این مثال، احتمال خیلی زیاد از "First2" میشه به "first" رسید و وقتی Hash میشه میبینیم مقدارش توی دیتابیس هست. پس در نتیجه پسورد جدید خیلی مشابه پسورد سابق هست.

یک راه دیگه Fuzzy Hashing هست. کاربرد اصلیش با Hash function هایی که ما تا الان راجبشون حرف زدیم متفاوته. از Fuzzy hashing (یا Similarity hashing) برای پیدا کردن Malware یا حتی برای تکنیک های data loss prevention استفاده میشه. ولی اینجام به کارمون میاد.
یکی از راه های ساختن این الگوریتم Context triggered piecewise hashing هستش. به زبون ساده، قسمت های مختلف input رو میشکونن و هر قسمت رو hash میکنن و بعد همه‌ی تیکه های مختلف hash شده رو بهم میچسبونن. برای مثال بیایم "first" رو به "f", "i" و ... تقسیم کنیم و هر قسمت رو hash کنیم. بحثش خیلی مفصل تره و احتمالاً توی آینده بیشتر راجب بنویسم.

👾 @geekingaround

برای شما هم پیش اومده که از میانهٔ راه یک پروژه نسبتاً بزرگ بهش اضافه شده باشین و کلی علامت سوال براتون پیش اومده باشه؟ این که چرا از فلان تکنولوژی استفاده شده؟ چرا معماری پروژه به این شیوه طراحی شده؟ چرا از ابزار X اینجا استفاده نکردن؟

اینجا اگر خوش‌شانس باشین، مستنداتی پیدا می‌کنید که اعضای قبلی پروژه این تصمیم‌ها رو توش توضیح دادن. ولی اغلب این داک‌ها قدیمی میشن و وضعیت فعلی رو نشون نمی‌دن.

در این حالت تنها راهی که باقی می‌مونه پرسیدن این سوال‌ها از اعضای فعلی تیمه. اما خب ممکنه خود اون‌ها هم همهٔ جزئیات رو به یاد نداشته باشن و یا مثل شما، از میانهٔ راه به تیم اضافه شده باشن.

اینجاست که ایدهٔ ADR مطرح میشه. این ایده می‌گه که بیایم برای نحوه انتخاب ابزارها، معماری‌ یا اضافه و حذف کردن بخش‌های پروژه، یه سند کوتاه بنویسیم توی ریپازیتوری پروژه نگه داریم.

چیزی که این ایده رو متفاوت می‌کنه اینه که اگر در طی زمان تصمیم‌هامون تغییر کرد، به‌جای پاک کردن یا بروزرسانی اون سند، یک سند جدید اضافه کنیم و دلیل این تغییر رو توضیح بدیم. اینطوری یک تاریخچهٔ خوب از تصمیم‌گیری‌ها خواهیم داشت؛ بدون این که نیاز باشه مدام حواسمون به آپدیت نگه داشتن سند‌های قبلی باشه.

اگر این مسئله ذهنتون رو قلقلک می‌ده پیشنهاد می‌کنم این نوشتهٔ کوتاه رو بخونید:
Documenting Architecture Decisions

@aminrbg