در مورد رندوم چند تا ویدیو دیدم اخیرا که جالب بود:

چرا ما در تولید عدد تصادفی بد هستیم:

https://youtu.be/tP-Ipsat90c?si=H87JgbY1bzpuj0Qc

چرا به نظر ما ۳۷ عدد خیلی رندومیه؟
https://youtu.be/d6iQrh2TK98?si=qWlxnQu-0QlweQCP


ایا با داشتن اطلاعات کامل از لحظه کنونی جهان هستی میشه کامل و دقیق اینده رو پیش‌بینی کرد؟ نگاهی به قانون دوم ترمودینامیک هم میندازه
https://youtu.be/sMb00lz-IfE?si=mSXCblUK4aTSMsX2

یه چیز جالبی بهم معرفی شد الان.

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

لینک:
https://swlt.app/programmers-day

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

ویدیو جالبی بود در مورد سطح های متفاوت کاربرد LLM برای برنامه نویس های جونیور تا سنیور

آیا هوش مصنوعی جایگزین ما میشود؟ فعلا فقط جونیور ها

شاید با protobuf یا msgpack از قبل آشنا باشید. این استاندارد ها هر کدوم یه فرمت باینری برای serialise deserialize دیتا هستن.
اما تنها آپشن ها نیستند، اگر ارسال کننده و دریافت کننده هردو گولنگی باشن میتونید از encoder decoder مخصوص خود گولنگ استفاده کنید که پرفورمنس بالایی داره و استفاده ازش ساده‌ست. اسمش هم هست gob.

https://go.dev/blog/gob

یه ویژگی جدیدی که به گولنگ اضافه شده و در عین ساده بودن به نظرم کاربردیه و کد رو تمیز و زیبا می‌کنه، متد run روی waitgroupئه. به این شکل که به جای این که به صورت دستی هم go routine جدید بسازید و هم wg رو یکی زیاد کنید و آخر تابع هم doneش کنید، تابعتون رو به متد run جدید می‌دید و خودش این کارا رو انجام میده.

اطلاعات بیشتر و نمونه کد:
https://appliedgo.net/spotlight/go-1.25-waitgroup-go/

این هفته GPT5 توی openrouter انگار تخفیف داره ۵۰ درصد. گفتم بذار برای این یه پروژه کوچک ازش استفاده کنم و واقعا بده. من فکر می‌کردم روی پروژه‌های بزرگ بده ولی این پروژه ۴۰۰ خط هم نیست هنوز و وقتی گفتم یه interface تعریف کن، افتاده تو لوپ داره با خودش کشتی می‌گیره =)))))))

چرا protobuf بد است و توسط یکسری جونیور طراحی شده؟!
نگارنده این مطلب خودش توی گوگل کار کرده و نظراتش رو در مورد اشکالات protobuf میگه مخصوصا تایپ سیستمش و این که مشکلاتی رو حل می‌کنه که به جز گوگل در جای دیگر وجود ندارن. حتی به عقیده اون، توی خود گوگل هم می‌شد کارهای بهتری کرد.
https://reasonablypolymorphic.com/blog/protos-are-wrong/

میخواید تو کامیت مسیج هاتون ایموجی بذارید؟

میتونید به این روش عمل کنید :)))
https://gitmoji.dev/

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

Commit Message Generator
https://whatthecommit.com/

توضیح: چند بار رفرش کنید.

بعد از یک ماه تمدید، نهایتا قراره فردا ایمج ها از دسترس خارج بشن :)

خسته نباشید به مهندسایی که دارن شب اخری، بدو بدو تگ ایمج ها رو عوض می‌کنن.

It's Hacktoberfest time! Here's everything you need to know! 🥇

https://itsfoss.com/hacktoberfest-guide/

دوستان اکتبر شروع شده و باز برنامه هکتوبرفست در جریانه.

قضیه از این قراره که اگه توی ماه اکتبر ۶ تا مرج ریکویست ارسال کنید که مرج بشه، بج هکتوبرفست می‌گیرید. قبلا تیشرت هم می‌دادن البته ولی با توجه به سواستفاده ها دیگه انگار خبری نیست. :)

https://hacktoberfest.com

در مورد hookهای git:
گیت امکانات مختلفی داره و یکی از امکاناتش که دستمون رو خیلی باز می‌کنه برای انواع شخصی سازی ها، hook ها هستن. قضیه از این قرارها که توی پوشه .git/hooks میتونید یکسری اسکریپت قابل اجرا بگذارید با اسم های معلوم و خود گیت در زمان های مشخص اونا رو اجرا می‌کنه. معلوم ترینش precommit hook هست که گیت بعد از اومدن دستور کامیت و قبل از این که واقعا کامیت کنه اون اسکریپت رو اجرا می‌کنه. توی اون اسکریپت می‌تونید کد رو فرمت کنید یا تست ها رو اجرا کنید تا مطمین بشین که کامیت های atomic دارید. البته قابل دور زدن هم هست.

فقط دقت کنید که هوک ها جزو چیزاییه که خودتون اونجا می‌گذارید و توی خود گیت ورژن کنترل نمیشه.

یه استفاده که من اخیرا از git hook کردم ابن بود که مطمین بشم کامیت مسیج های یه سری پروژه خاص، یه فرمت خاصی رو رعایت میکنن. برای این کار از هوک commit-msg استفاده کردم. این هوک هم میاد قبل از این که واقعا کامیت صورت بگیره اجرا میشه و کامیت مسیج رو دریافت می‌کنه. در نهایت با کمک exit code میتونید مشخص کنید که کامیت مورد تایید هست یا باید ریجکت بشه.

کدی که من نوشتم:

#!/bin/bash
commit_regex='some regex'
error_msg="Aborting commit."
if ! grep -E "$commit_regex" "$1"; then    echo "$error_msg" >&2
  exit 1
fi
این فایل باید به این اسم سیو بشه: commit-msg توی پوشه hooks اون ریپوزیتوری.


اما حالا برای این که این اسکریپت رو همه جا تکرار نکنم چیکار کردم؟ اومدم از core hooks استفاده کردم. به این شکل میتونم بگم پوشه هوک دیفالت برای همه پروره‌ها یکی باشه و نیاز نیست برم داخل هر پروژه تک تک چک کنم.

کامندی که استفاده کردم اینه:
git config core.hooksPath

و نهایتا کانفیگ گیت اینطوری میشه:
[core]
hooksPath = /path/to/hooks/dir


اما اینجا هنوز یه تیکه گمشده دیگه هست. با این تغییراتی که من دادم این فرمت برای همه‌ی پروژه ها روی سیستمم اعمال شد ولی من اینو نمی‌خوام، بلکه می‌خوام فقط توی پروژه خاصی خاصی اعمال بشه. کاری که میکنم استفاده از conditional config توی گیته. قضیه اینطوریه که یه فایل کانفیگ ثانویه می‌سازم که این کانفیگ توش نوشته شده و توی کانفیگ اصلی میگم includeif: یعنی فقط وقتی این کانفیگ رو اعمال کن که پوشه گیت من داخل یکی از این پوشه ها بود یا داخل مسیری بود که این پترن رو داشت.

منابع:
https://git-scm.com/docs/githooks
و
https://dev.to/chaz8080/git-smart-streamlining-your-workflow-with-the-prepare-commit-msg-hook-432p
و
https://medium.com/@mrjink/using-includeif-to-manage-your-git-identities-bcc99447b04b


و اگه خواستید دقیقش رو توی dotfile م ببینید:

https://github.com/rsharifnasab/dotfiles/blob/2b3ba235c300e8a5dbec53a7a84dde350ca372af/configs/.config/git/config#L51
و
https://github.com/rsharifnasab/dotfiles/blob/37f0812046ef9eceb7c3e18ff0e9fb6b30843828/configs/.config/git/snapp#L9

برای هر کامیت git خوبه که یه مسیج خوب بنویسیم. معمولا git commit -m می‌زنیم و همونجا توی ترمینال یه مسیج یک خطی مینویسیم. اما اگه بخوایم حرفه‌ای تر عمل کنیم چی؟
یه راهش استفاده از git commit template ئه. اگر از این آپشن استفاده کنیم زمانی که git commit رو بدون -m بزنیم ادیتور باز میشه و اون تمپلیت رو به عنوان متن اولیه ما نشون میده و میتونیم روی اون تغییرات رو اعمال کنیم.

این مطلب هم آموزش فوق‌العاده‌ای برای شروع کار با کامیت مسیج ها بود. من لینک قسمت commit template ش رو گذاشتم براتون، ولی اسکرول کنید و باقی قسمت ها رو هم ببینید.
https://axolo.co/blog/p/git-commit-messages-best-practices-examples#how-to-set-up-a-git-commit-message-template

اگه به git hook ها علاقه مند شدید، یکسری ابزار ساده هم هست که میتونید استفاده کنید تا کمی کارتون راحت تر باشه. من husky رو پیدا کردم که میاد با کمک core hooks براتون هوک ها رو مدیریت می‌کنه. سبک وزن و بامزه‌ست ولی بدون اون هم کارتون راه میوفته.

https://typicode.github.io/husky/

یکسری امکانات. pre commit hook هم میتونید توی این پروژه پیدا کنید.
https://pre-commit.com/
و گیتهابشون:
https://github.com/pre-commit/pre-commit-hooks

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

این شما و این هم rundown ai
https://www.therundown.ai/

Swiss Table
______________________________
روش‌های مرسوم رفع تصادم (collision) توی hashmap رو تو درس ساختمان داده خوندیم:

1- open addressing
2- chaining
3- hybrid

خیلی خلاصه بخوام هرکدوم رو مرور کنم اینطور میشه:

در open addressing اینطور عمل می‌کنیم که وقتی تصادم رخ داد، اینقدر توی آرایه‌ی wrap شده جلو می‌ریم تا به اولین خونه‌ی خالی برسیم و item رو اونجا بذاریم.

در روش chaining هر خونه‌ی آرایه‌ی ما یک عنصر نگه می‌داره و یک پوینتره به یک ساختمان‌داده‌ی دیگه که می‌تونه یک linked list باشه یا یک درخت متوازن مثل red-black یا AVL. در صورتی که توی اون خونه‌ی آرایه از قبل داده‌ای وجود داشته باشه، آیتم جدید رو push می‌کنیم توی اون ساختمان‌داده‌ای که اون خونه بهش اشاره می‌کنه.

در روش سوم، یکی از روش‌های اول و دوم رو با مکانیزم هش‌چندباره ترکیب می‌کنیم. به این صورت که چند الگوریتم هش متفاوت رو در نظر می‌گیریم. در صورتی که با هش آیتم مدنظرمون تصادم رخ داد، یک الگوریتم هش جدید رو انتخاب می‌کنیم. مکانیزم انتخاب الگوریتم هش هم می‌تونه هرچی باشه. ما ساده و round robin در نظر می‌گیریم. این کار رو تا زمانی ادامه می‌دیم که تمام الگوریتم‌های هش‌مون رو تست کرده باشیم و همشون منجر به تصادم شده باشن. بعد با استفاده از یکی از روش‌های ۱ یا ۲ اقدام به ذخیره کردن آیتم می‌کنیم.

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

توی جاهایی مثل Cloudflare که عملکرد در حد میکروثانیه مهمه، گاهی باید پا رو فراتر گذاشت. گاهی ساده‌ترین جزئیات می‌تونن تفاوت چندبرابری در سرعت ایجاد کنن. انگار یه نوع amplification رخ میده؛ بهینه‌سازی کوچیک که باعث میشه کل سیستم خیلی سریع‌تر به‌نظر بیاد.

یکی از ایده‌هایی که دقیقاً با همین ذهنیت طراحی شده، ساختار Swiss Tableه. گوگل با در نظر گرفتن چالش کش سرور‌ها دست به طراحی این ساختار زده. زبان‌هایی مثل Rust هم از همین ساختار برای پیاده‌سازی پیش‌فرض HashMap خودشون استفاده می‌کنن.
گوگل تو کنفرانس CppCon 2017 هم درباره‌ی طراحی و بهینه‌سازی این ساختار ارائه‌ای داشت که دیدنش خالی از لطف نیست:

CppCon 2017: Matt Kulukundis – Designing a Fast, Efficient Hash Table

Swiss Table در اصل هنوز از ایده‌ی open addressing استفاده می‌کنه؛ یعنی داده‌ها مستقیماً در یک آرایه ذخیره می‌شن و وقتی تصادم رخ بده، دنبال خونه‌ی بعدی می‌گردیم تا جایی برای درج پیدا کنیم. ولی تفاوت اصلیش اینه که چطور این آرایه
bucket‌
بندی میشه و چطور CPU ازش استفاده می‌کنه.

در Swiss Table، آرایه‌ی اصلی به چند bucket تقسیم میشه. هر bucket معمولاً چند تا slot داره (مثلاً 8 تا)، یعنی هر bucket خودش می‌تونه تا 8 تا عنصر نگه داره.
در کنارش یه آرایه‌ی کوچیک‌تر از metadata داریم که برای هر slot فقط یه بایت اطلاعات ذخیره می‌کنه. توی این بایت، یه تیکه از هش کلید (مثلاً 7 بیت از اون) نگه داشته میشه تا CPU بتونه سریع‌تر بفهمه کدوم slot احتمالاً مربوط به کلید مورد نظره.

وقتی می‌خوایم دنبال یه کلید بگردیم یا کلید جدیدی وارد کنیم، Swiss Table با استفاده از
SIMD (Single Instruction, Multiple Data)
چند بایت metadata رو با هم می‌خونه (مثلاً 16 تا در یک لحظه) و در عرض یک دستور CPU بررسی می‌کنه که آیا هش کوچیک ذخیره‌شده توی اون‌ها با هش کلید ما یکیه یا نه.
بعد اگه یکی از اون‌ها match کرد، تازه می‌ره سراغ داده‌ی واقعی و بررسی دقیق‌تر انجام میده.

Swiss Table تنها نمونه‌ی چنین طراحی‌ای نیست. بعد از گوگل، پروژه‌های بزرگ دیگه مثل
Facebook’s F14
ایده‌های مشابه استفاده کردن.
زبان‌هایی مثل Rust و Go هم با الهام از همین طراحی، نسخه‌های خودشون رو ساختن.

در پیاده‌سازی Go، تیم توسعه با یه چالش جدی روبه‌رو شد که به‌طور مفصل توی این پست توضیح داده شده:

The Go Blog – Swiss Table

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

این فرایند در سیستم‌های عادی چندان مشکلی ایجاد نمی‌کنه، ولی در سرورهای کش که چند ترابایت دیتا داخل مموری دارن، این resize می‌تونه به شدت زمان‌بر و کند باشه.
راه‌حلی که گولنگ برای این موضوع ارائه داد، استفاده از hashmapهای چند‌لایه (multi-level) بود. به‌جای resize کامل، داده‌های جدید در یک لایه‌ی بالاتر ذخیره می‌شن و به‌صورت تدریجی داده‌های قدیمی جابه‌جا می‌شن. اینطوری عملیات resize به بخش‌های کوچیک تقسیم میشه و فشار ناگهانی از روی سیستم برداشته میشه.

این پست رو هم از دست ندین:

A new fast hash table in response to Google’s new fast hash table