کلون ریپازیتوری بدون تاریخچه کامل

وقتی یه ریپازیتوری گیت تاریخچه خیلی طولانی داشته باشه، git clone ممکنه زمان و حجم زیادی مصرف کنه؛ در حالی که شاید فقط به آخرین نسخه کد نیاز داشته باشیم. اینجا می‌تونیم از --depth استفاده کنیم. توی مثال فقط آخرین کامیت رو دریافت می‌کنیم و به همین خاطر clone سریع‌تر و کم‌حجم‌تر میشه.

این روش یه shallow clone ایجاد می‌کنه و به همین دلیل کل تاریخچه گیت رو نداریم. اگر بعدا به تاریخچه کامل نیاز داشتیم، می‌تونیم با git fetch --unshallow کل تاریخچه رو دریافت کنیم.

#git

@techstuff100

چطور تصمیم‌های فنی و معماری رو مدیریت کنیم؟

توی این ویدیو با RFC و ADR و نقش اون‌ها در بهبود ارتباط و هماهنگی بین تیم‌های فنی آشنا میشیم. با بررسی دو نمونه واقعی، روند پیشنهاد و بررسی یک تغییر در RFC و ثبت تصمیم‌های معماری در ADR رو می‌بینیم. همچنین تفاوت کاربرد RFC و ADR و اهمیت ثبت context تصمیم‌ها رو بررسی می‌کنیم.

ویدئوی یوتوب:
https://www.youtube.com/watch?v=0zLf2Nl4jv8&list=PLOpUynAWw-VY&index=1&pp=iAQBsAgC

#software_engineering

@techstuff100

جلسه قراره یه هدف مشخص داشته باشه و وقتی این هدف فراموش بشه، جلسه خیلی راحت تبدیل میشه به اتلاف وقت.

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

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

#Skills_of_a_Successful_Software_Engineer

@techstuff100

این مقاله سوال‌های رفتاری که نویسنده توی مصاحبه شرکت‌هایی مثل آمازون، گوگل، کانوا و ... ازش پرسیدن رو بررسی کرده. سوال‌هایی مثل:
- تا حالا با هم‌تیمیت به مشکل خوردی؟
- یه اشتباه مهمی که کردی چی بوده؟
- تا حالا شده با یه تغییر مخالف باشی؟

به نظرم خوندن این مقاله بخصوص برای کسی که داره برای مصاحبه آماده میشه خیلی مفیده.

[لینک مقاله]

@techstuff100

هدر 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