هدر Cache-Control

این هدر مشخص می‌کنه یه ریکوئست یا ریسپانس چطور و برای چه مدتی می‌تونه کش بشه. توی مثال اگر سرور این هدر رو برگردونه، یعنی ریسپانس می‌تونه توسط کش‌های عمومی ذخیره بشه و تا ۳۶۰۰ ثانیه از کش استفاده بشه و لازم نباشه هر بار از سرور گرفته بشه.

توی ریسپانس، public یعنی ریسپانس می‌تونه توسط کش‌های عمومی مثل CDN ذخیره بشه، در حالی که private معمولا برای ریسپانس‌هایی استفاده میشه که مخصوص یک کاربر هستن و نباید توسط کش‌های عمومی ذخیره بشن.

دایرکتیو no-store یعنی اصلا ریسپانس رو ذخیره نکن و همیشه مقدار جدید رو دانلود کن که برای اطلاعات حساس مناسبه. no-cache برخلاف اسمش نمیگه کش نکن؛ میگه قبل از استفاده مجدد از نسخه کش‌شده باید با سرور اعتبارسنجی بشه.

استفاده از no-cache روی ریسپانس باعث میشه هر بار قبل از استفاده از نسخه کش‌شده با سرور revalidation انجام بشه. در نتیجه یا یه ریسپانس جدید دریافت میشه، یا اگر نسخه موجود معتبر باشه، سرور می‌تونه 304 Not Modified برگردونه. بنابراین no-cache هزینه داره، چون مرورگر رو مجبور می‌کنه برای هر بار استفاده یک درخواست اضافی به سرور بزنه.

@techstuff100

رویداد پیاده سازی و انواع Pagination در طراحی API

بررسی انواع مدل های پیاده سازی pagination به همراه بررسی نقاط ضعف و قدرت در عملکرد هریک از این ساختار ها در صفحه بندی جداول و اطلاعات

https://thealibigdeli.ir/r/TJRgHi/

@thealibigdeli_channel
#event

یچیزی وجود داره به اسم مغلطه‌‌ی هزینه هدررفته (Sunk Cost Fallacy).

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

در تصمیم‌گیری بهتره هزینه‌هایی که تا الان انجام شدن رو کنار بذاریم و ببینیم از این لحظه به بعد، کدوم گزینه منطقی‌تره. چیزی که قبلا از دست رفته، با ادامه دادن لزوما برنمی‌گرده.

@techstuff100

Auditory Prompt Injection

یه‌ چند روزی بود داشتم ویدئو های اینستا رو نگاه می کردم روی بعضی هاشون ۲ تا وویس صحبت بود انگار یکی پشت صحنه داشت یه چیزی می گفت ولی صدای جلویی مانع بود.

همینطوری ازش گذشتم تا به این تیتر رسیدم توی یه جایی که امکان تزریق دستور توی یک وویس دیگه از طریق فرکانس پایینتر و ... وجود داره و میشه یسری موسیقی ها رو طوری دستکاری کرد که این موضوع توش قرار بگیره و بشه اطلاعات و یا سلسله ای از دستورات رو از طریقش انجام داد.

حالا در کنار نوشته های مخفی توی تصویر و یا ویدئو و یا skills های آلوده و خیلی چیزای دیگه، به این فکر کنین دیگه چیا می تونن حامل یک عملیات مخرب بشن. 😐

دیگه به چی تقریبا میشه اعتماد کرد؟

@thealibigdeli_channel
#ai

بعضی وقت‌ها چیزی که به مدیرمون میگیم، بیشتر از خود جمله پیام منتقل می‌کنه. مثلا وقتی دیر می‌رسیم و شروع می‌کنیم به توضیح دادن که «دیشب مهمونی بودم»، شاید ناخواسته این برداشت ایجاد بشه که کار و تاثیرش روی تیم برامون خیلی مهم نبوده. یا وقتی باگ گزارش میشه و سریع میگیم «ما همیشه همین‌طوری انجامش می‌دادیم» یا «این باگ رندومه»، ممکنه نشون بده که قبل از بررسی کردن، داریم مشکل رو رد می‌کنیم. حتی جمله «تقصیر من نبود» هم وقتی یه مشکل برای تیم پیش اومده تصویر خوبی نمی‌سازه. لازم نیست مسئول همه‌چیز باشیم، ولی می‌تونیم برای پیدا کردن مشکل و حلش کمک کنیم.

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

#Skills_of_a_Successful_Software_Engineer

@techstuff100

یه مسئله جالب برای تمرین dynamic programming، مثلث پاسکاله. توی این مثلث، هر عدد از جمع ۲ عددی که دقیقا بالای اون قرار دارن محاسبه میشه.

لیتکد:
https://leetcode.com/problems/pascals-triangle

یه مسئله تکمیلی Pascal's Triangle II هم داره:
https://leetcode.com/problems/pascals-triangle-ii/

#algorithm

@techstuff100

رویداد استفاده از Wireshark در مهندسی معکوس

چطور می تونیم با بررسی ارتباط بین یک کلاینت و سرور رفتار مشابه رو شبیه سازی و مهندسی معکوس کنیم. این رفتار رو میشه با ضبط پکت های ارتباطی و باز نویسی و یا حتی ارسال مجدد باز طراحی کرد، که حتی برای موارد امنیتی هم در نظر گرفته میشه.

https://thealibigdeli.ir/r/wq2eQ6/

@thealibigdeli_channel
#event

چه کسانی مهندسان ارشد ۲۰۳۵ خواهند بود؟

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

این مقاله تاثیر AI روی مهندسای جونیور رو بررسی می‌کنه و در نهایت برای افراد توی سطحی که هستن (مهندس یا رهبر ارشد، مدیر و یا برنامه‌نویس تازه‌کار) پیشنهاداتی ارائه میده.

#recent_reads

@techstuff100

چرا Big O یکسان به معنی سرعت یکسان نیست؟

فرض کنید ۲ تا تابع داریم که هر دو پیچیدگی زمانی O(n) دارن. این لزوما به این معنی نیست که هر دو در عمل یک سرعت اجرا دارن. مثال رو در نظر بگیرین. print_items و print_items2 هر دو یکبار روی لیست حلقه می‌زنن. اما print_items سریع‌تره؛ چون یک ثانیه مکث برای پرینت هر آیتم رو نداره.

وقتی که میگیم پیچیدگی زمانی O(n) هست، منظورمون اینه که زمان اجرای اون با رشد n به صورت خطی رشد می‌کنه. در اصل داریم میگیم c * n که این c یه مقدار زمان ثابته که الگوریتم ما میگیره. مثلا برای print_items ممکنه 10ms و برای print_items2 همون 1s باشه.

اگر دو الگوریتم پیچیدگی زمانی big O متفاوتی داشته باشن، معمولا مقدار c رو نادیده می‌گیریم. مثلا بین جستجوی باینری و جستجوی خطی، مقدار c تاثیری نداره؛ چون در نهایت جستجوی باینری سریع‌تره.

یه نمونه از زمانی که مقدار ثابت c اهمیت پیدا می‌کنه، quick sort در برابر merge sort ه. quick sort مقدار ثابت c کوچک‌تری از merge sort داره. پس اگه جفتشون O(n log n) باشن، quick sort سریع‌تره.

#Grokking_Algorithms #algorithm

@techstuff100

استراتژی‌های Retry در سیستم‌های توزیع‌شده

وقتی یه درخواست fail میشه، معمولا می‌تونیم Retry کنیم.
چند تا از استراتژی‌های رایج:

یک. Immediate Retry: بلافاصله دوباره درخواست می‌فرستیم. ساده و سریعه؛ ولی اگه مشکل همچنان وجود داشته باشه، می‌تونه باعث درخواست‌های پشت‌سرهم و فشار بیشتر بشه.

دو. Fixed Interval: بعد از هر خطا مدت زمان ثابتی صبر می‌کنیم؛ مثلا هر ۵ ثانیه یک‌بار. ساده‌ست؛ ولی ممکنه فاصله انتخاب‌شده بیش از حد کوتاه یا طولانی باشه.

سه. Incremental Interval: فاصله Retryها کم کم بیشتر میشه؛ مثلا ۱، ۲، ۳، ۴ ثانیه.

چهار. Exponential Backoff: فاصله بین Retryها به‌صورت نمایی افزایش پیدا می‌کنه؛ مثلا ۱، ۲، ۴، ۸ ثانیه. برای خطاهایی که احتمال میدیم بعد از مدتی برطرف بشن معمولا انتخاب مناسبیه. بهتره تعداد Retry یا حداکثر زمان انتظار هم محدود بشه.

پنج. Jitter: یک مقدار تصادفی به زمان انتظار اضافه می‌کنیم تا چندین کلاینت هم‌زمان Retry نکنن.

شش. Circuit Breaker: وقتی تعداد خطاها از حد مشخصی بیشتر بشه، موقتا Retry و درخواست‌های جدید رو متوقف می‌کنیم تا سرویس مقصد فرصت ریکاوری داشته باشه.

هفت. Adaptive Retry: استراتژی Retry رو بر اساس شرایط فعلی سیستم، مثل Load، Failure Rate و Response Time تغییر میدیم.

هشت. Cancel: اگر خطا دائمی باشه یا Retry کردن احتمال موفقیت نداشته باشه، به‌جای ادامه دادن، درخواست رو کنسل می‌کنیم.

در عمل معمولا یک ترکیب از این روش‌ها استفاده میشه؛ مثلا Exponential Backoff + Jitter + محدودیت تعداد Retry. همچنین برای درخواست‌هایی مثل پرداخت باید Idempotency رو هم در نظر گرفت تا Retry باعث اجرای چندباره یه عملیات نشه.

#system_design

@techstuff100

همونایی که فقط یه مهندس نرم‌افزار می‌تونه ببینه 👀

این داستان یکی از بچه‌ها توی هلند هست برام جالب بود:

مدتی هست که بخاطر هوش مصنوعی فشار کار فنی کمتر شده، سعی می‌کنم از فرصت پیش‌اومده استفاده کنم و یکم از نقش خودم بالاتر برم و کارهایی بکنم که در سال‌های قبل از هوش مصنوعی اصلاً به ذهنم هم خطور نمی‌کرد و کسی هم انتظار نداشت انجام بدم. مثلاً به تیم‌های دیگه مثل تیم فروش و بازاریابی سر می‌زنم و می‌ببینم محصولی که ساختیم از دیدگاه اونها یا مشتری‌ها چطوریه و آیا کم و کاستی داره یا نه

یکی از چیزهایی که جدیداً انجام دادم این بود که درخواست کردم دسترسی Search Console گوگل رو بهم بدن تا ببینم اپ توی سرچ گوگل وضعیتش چطوریه. و دیدم یه سری چیزها و آمارها بالا پایین هست 😄🙈 و گره‌های ریزی توی دشبرد وجود داره شاید از دید یک فرد غیر فنی پنهان بمونه. چیزهایی که وظیفه تیم فنی بود.

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

اگه مهندس نرم‌افزار هستید سعی کنید از این نکته‌ها و فعالیت‌ها غافل نشین. اینطور که من بازار و تغییرات مشاغل رو می‌بینم، شغل مهندسی نرم‌افزار کم‌کم داره از حالت کلاسیک خودش که ۸۰٪ کدنویسی بود فاصله می‌گیره و فعالیت‌‌هایی فراتر از اون یعنی تعاملات انسانی توی اون داره پررنگ‌تر میشه

یه مقاله هم جدیداً خوندم با عنوان «شغل‌های جدید مهندسی نرم‌افزار توی دوران هوش مصنوعی». یکی از این شغل‌ها که خیلی داره سر زبون‌ها میچرخه Forward Deployed Engineer هست که به مهندس نرم‌افزاری گفته میشه میره پیش مشتری‌ها، الگوهای پیدا و پنهان اون شرکت رو یاد بگیره (همونایی که فقط یه مهندس نرم‌افزار می‌تونه ببینه) و از این تجربه یه محصول قابل استفاده برای همه مشتری‌های فعلی و بعدی بسازه

متود reduceRight در جاوااسکریپت

متود reduceRight شبیه به reduce عمل می‌کنه؛ با این تفاوت که reduceRight تابع کال بک reducer رو از راست به چپ (ایندکس نزولی) اعمال می‌کنه و مقدار نهایی رو بر می‌گردونه. پارامتر‌ها و مقدار بازگشتیش دقیقا مثل reduceه. مثال رو ببینید.

#javascript

@techstuff100

هدر Referer

یه سوالی که ممکنه باهاش مواجه شیم اینه که بازدیدکننده‌ها از کجا دارن میان به وبسایتمون. مثلا از گوگل ما رو پیدا کردن یا لینکدین. با هدر Referer می‌تونیم جواب این سوال رو بدیم.

این هدر آدرس URLی رو میده که کاربر از اونجا به سایت مقصد رسیده. مثلا توی گوگل وقتی یچیزی رو سرچ می‌کنیم و روی یه لینک کلیک می‌کنیم، مقدار این هدر مثل عکس میشه. ازش می‌تونیم برای analytics و logging استفاده کنیم. اما خیلی هم نمیشه بهش اعتماد کرد؛ چون میشه برای مثال با curl تغییرش داد.

یه نکته امنیتی هم داره. توی صفحات فراموشی رمز عبور، URL صفحه معمولا چنین چیزیه:
jalali[.]com/forgot-password?token=ABC
حالا اگه توی این صفحه، لینک به صفحات اجتماعی مثل اینستاگرام و لینکدین داشته باشیم و کاربر روش کلیک کنه، به مثلا اینستاگرام هدایت میشیم درحالی که Referer چنین مقداری گرفته:
jalali[.]com/forgot-password?token=ABC
و این یعنی که توکن کاربر لو رفته.

#cyber_security

@techstuff100