پرسیدید چرا نویسنده می‌گه این مورد appalling هست؟ با اینکه بنظر رفتار خیلی خوبی میاد.

من یک نمونه کد زدم که نشون بدم چرا بد هست این رفتار؛ توی این حالت من بیش از حد سخت گرفتم و همه چیز NewType هست (یا یک رفتاری رو نباید دنبال کنید یا کل کد باید یک استاندارد رو رعایت کنه)

اولین و مهمترین نکته :
توجه کنید نویسنده همین رفتار یعنی تعریف مداوم تایپ جدید برای نوع داده‌های اصلی رو بد می‌دونه!
اینکه بجای str, bool, int تایپ جدید تعریف کنید که پارامتر ورودی شما بهتر بنظر برسه!

حالا بررسی کنیم خود ایرادات وارده رو:

۱- تعریف نوع داده‌ای جدید هیچ عملکرد بهتری برای runtime بهم نمیده!
خیلی از افرادی که اینکار رو می‌کنند برای فرار از تست کردن کدها؛ فرار از نوشتن ولیدیشن؛ فرار از چک کردن پارامتر‌های ورودی و ... اینکار رو می‌کنند! این چیزی هست که شخصا بسیار توی این مدل کد زدن دیدم (قطعا هستند افرادی که اینطوری عمل نمی‌کنند ولی خب من ندیدم)

۲- خط ۹۱ کد رو ببینید؛ هرجایی از کدم که بخوام یک str یا ... رو برای این توابع استفاده کنم حتما باید توی NewType ایی که تعریف کردم بذارمش!

ادامه پست بعدی:

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

۳- وقتی این NewType هیچ runtime چکی نمیده؛ چه فرقی بین

email: Email
email: str 

هست؟ استفاده از اسم متغییر درست به توسعه دهنده بعدی به درستی می‌فهمونه که باید ایمیل استفاده کنه و نه چیز دیگری

اینجا باید ترجیح بدید که Email رو تبدیل به یک کلاس کنید که validation های مختلف خودش رو هم حتما داشته باشه!

۴- احساس امنیت کاذب؛ توی مورد ۱ به این موضوع اشاره کردم!
حالا بخش بدتر این قضیه کجاس ؟ دولوپرهای حواس‌پرت به mypy تکیه می‌کنند که دولپر دیگری از کدشون سواستفاده نکنه بجای اینکه دقیقا پارامتر ورودی رو بررسی کنند و اگر ایمیل ولید نیست ارور برگردونند.

۵- توی پایتون NewType چون قوانین نامگذاری شبیه به Class داره و البته که Syntax Highlight هم مثل کلاس می‌بینه باعث سردرگمی میشه!
کلاس بدون رفتار ؟
اینم موردی دیگه و یک anti-pattern دیگه

در نهایت :
NewType
چیز بدی نیست؛ جو گیری بده. وقتی سورس کد بزرگ هست و شما این موضوع رو بیش از حد پیش بردید اتفاقات قشنگی نخواهد افتاد.
دقت کنید این موارد حتی توی زبان‌های کامپایلری و lowlevel هم قفل هست.

خلاصه که هرچیزی رو در جای درست خودش استفاده کنید؛ این مورد یک فیچر هست توی پایتون که قطعا استفاده خواهد شد ولی بهتره درجای درست و برای مفهوم درست استفاده بشه!
کل صحبت نویسنده کتاب هم همین بوده که سعی کردم با مثال توضیح بدم.

نسخه با کیفیت تصویر

پیام دادید یک راهکار یا ... برای اینکه تست کنیم معماری که استفاده کردیم واقعاً microservice هست یا Distributed monolothic پیشنهاد می‌دید ؟

سوال جالبی بود و هیچوقت به این فکر نکرده بودم که چطوری میشه؛ یک تست سریع راه انداخت، اما بنظرم بهترین جواب هم توی خود ویژگی‌های microservice هست:

تمام سرویس‌ها اگر که باهم اجرا بشه؛ سیستم باید کار کنه!
اما اگر هر سرویس رو خاموش کنید (مثلاً برای ۵ دقیقه) باقی سرویس‌ها باید بدون مشکل کار کنند، وقتی بعد از ۵ دقیقه اون سرویس خاموش شده رو روشن کردید، سیستم باید کامل کار کنه.

مثال: فرآیند خرید محصول (انسانی)
ثبت سفارش - تایید موجودی - تایید سفارش و صدور فاکتور - پرداخت - تایید پرداخت - آماده سازی - ارسال.

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

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

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

پ.ن:
سعی کردم مثالم خیلی ساده باشه (چون خودشون ذکر کردند جونیور هستند)

سمت ما
__init__.py
لزوماً خالی نیست؛ خیلی وقتا تنظیمات خاص و راحت تر و ... داخلش هست
و یا حتی re-export برای راحتی بیشتر کاربر.

برای اولین باز :
شخصا این کتاب رو هنوز نخوندم (۲ فصل فقط)

با توجه به مطالب اخیر؛ سوالات زیادی برام اومده راجب معرفی منبع! و خیلی از دوستان خواستند که هرچه زودتر این اتفاق بیوفته.

این کتاب رو یکی از دوستان به من هدیه داده (که خب هنوز وقت نکردم خوندنش رو کامل کنم) توی کانال @pyrust درگیری این مدتم رو نوشتم.

اما چون خودش خونده و بسیار تعریف میکرد؛ منم توی یک مرور سریع دیدم راجب بسیاری از مفاهیم مهم به خوبی صحبت شده گفتم معرفی کنم.

برای اونهایی که واقعا نیاز دارند به این موضوعات درحال حاضر پیشنهادش می‌کنم. اما اگر کتاب‌های دیگه که معرفی شده رو نخوندید می‌تونید صبر کنید تا شخصا کتاب رو بخونم و بعد نظر دقیقتر بدم!

به همین دلیل این پست رو هشتگ نمیزنم که قاطی باقی کتاب‌های اصلی نشه!

#Quick
یکی از دلایل خوب استفاده از containar اینه که آپدیت ورژن‌ها ساده‌تر باشه!

پروژه‌ای رو داشتم که هنوز از Postgres 12 استفاده می‌کرد؛ ۱۴ نوامبر ۲۰۲۴ پشتیبانی این نسخه تموم شده (سرچ کردم حفظ نیستم).
بعد بنده خدا مدیر شرکت می‌خواست optimization بزنه که مشکلاتش کمتر بشه، همین که ابزارهایی که استفاده می‌کردند رو آپدیت کردم و البته معماری سیستم رو کمی بهتر (مثلاً برای دسترسی به یک سری سرویس‌های داخلی چون نتونسته بودند کانفیگ کنند، درخواست‌ها رو از اینترنت رد می‌کردند که خودش باعث میشه latency زیاد بشه) بیش از ۷۰-۸۰٪ مشکلاتشون حل شد.
بخصوص میزان مصرف منابع!

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

پیام پاول دوروف به مناسبت تولد ۴۱ سالگی و البته قوانین کنترل شدید اینترنت اروپا؛

https://t.iss.one/durov/452

سایتای داکر دان شده؛ دست به چیزی نزنید!

یکی از دوستان توی گروه اطلاع دادند.

Issues accessing Registry, Hub, Scout, DBC, DHI - We are seeing issues accessing and using our services across many of our products. See dockerstatus.com⁠ for updates.

پینوشت:
بنظر میاد مشکل اصلی از AWS هست

#توصیه@per3onal

دقیقاً، پیشرفت بعد از درک نفهمیدم هست.

این رو به خواهر دوستم گفتم؛ رفیقم زنگ زده، که آقا خواهر من یک شرکتی وارد شده بهش یه سری منابع دادند که بخونه، تازه ۲ هفته‌اس وارد شده (این اولین تجربه کاریش هست)

ولی همش می‌گه، هیچی متوجه نمی‌شه؛ دوره آموزش یا راهکار یا چیزی داری براش ؟
راهنمایی‌اش کردم و تمام، گفتم این پست رو بنویسم ...

وقتی قراره چیزی یاد بگیری، چه دانشجو، چه کاری چه اصن سنیور

همیشه باید یک نکته‌ای رو یادت باشه؛

تو بخاطر اینکه هیچ درکی از اون موضوع نداری یا اصلا بلدش نیستی داری اون موضوع رو یاد میگیری.

یعنی اینکه به خودت بگی؛
من چه غلطی دارم می‌کنم.
من هیچ چیزی نمی‌فهمم.
من هیچ درکی از کاری که می‌کنم ندارم.
و ....

کاملاً طبیعی هست؛ نمی‌گم درسته‌ها حرف تو دهن من نذارید بعداً، می‌گم طبیعی هست.

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

اما مهمترین بخشش هم همین هست؛ اون اوایل که هیچی ازش نمی‌فهمی نا امید نشی و ادامه بدی.

بذارید مثال ساده بزنم، یکی رو پیدا کنید که هیچی برنامه‌نویسی بلد نیست و می‌خواد پایتون یاد بگیره؛
بعد جلوش کدهای یک سنیور از پروژه‌ی Django رو بذارید؛ هیچ منبع دیگه‌ای بهش ندید جز چندماه وقت.

بنظرتون بعد از چندماه اگر ببینیدش، انگیزه‌ای براش مونده ؟
یا اینکه اگر بیاد به شما بگه چیزی نفهمیده، خنگ‌ترین آدم دنیاس ؟

حالا کنار دست همین آدم، یک راهنما بذارید یک چیزی مثل chatgpt, grok, gemini یا ...
بنظرتون حالا چطوری عمل می‌کنه ؟

احتمالاً بازهم انگیزه کمی خواهد داشت، اما دیگه مباحث زیادی رو هم می‌دونه؛
مثلاً می‌دونه که متغییر چیه؛ یا def برای تعریف تابع هست

حالا کنار دست همین آدم منابع دیگری رو هم بذارید؛ مثل یوتیوب یا ...
ممکنه کمی کند ولی راه خودش رو هم پیدا می‌کنه؛ از پایتون شروع می‌کنه تا به جنگو برسه.


داستان همین هست؛ خیلی از منابعی که می‌خونید ورژن ساده‌تر نداره.
کتاب Latency که چندروز پیش گفتم؛ واقعاً نسخه ساده‌تر نداره!
خیلی از بخش‌هاش رو انقدر توی کار تجربه کردم که برام کاملاً واضح هست و می‌گم چرا نویسنده وقت مارو داره تلف می‌کنه ؟
و یک سری بخش‌ها هم، کاملاً اینطوری هستم که من اصلاً نمی‌فهمم این چی می‌گه! اصلاً این کلمه‌ها چیه استفاده کرده و ....

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

اما همین احساس خوب موقتی باعث میشه یادم بره من برای اینکه چیز جدید یاد بگیرم این کتاب رو انتخاب کردم و وقتی وارد مباحثی که بلد نیستم می‌شم؛ چون توی فصل‌ها و بخش‌های قبلی اون حس خوب کاذب رو داشتم، باعث میشه به خودم بگم :

من هیچی نمی‌فهمم،
من خنگم و ....

خلاصه که اگر شماهم مثل خواهر این دوست من یادتون میره درحال یادگیری هستید، یکجا بنویسید و بذارید جلو چشمتون:

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

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

در نهایت:
قدم اول برای اینکه شروع کنید به یادگیری، این هست که بفهمید اون موضوع رو یاد نگرفتید یا نفهمیدید.

Make the test pass faster (fun)

۹ ثانیه بعد از این رو ببینید؛
بعد اگر دوست داشتید کامل ببینید.

ولی من واقعا برام این اتفاق افتاده؛ یکجا CI/CD نوشته بودم بعدها بهم گفتند این نیرو جدیده که اومده یک جوری Optimization زده که کدها خیلی سریعتر دپلوی میشه.
گفتم دمش گرم برم ببینم چیکار کرده که یاد بگیرم؛ با کلی بحث و ... محدد دسترسی گرفتم به اون پروژه شرکت و دقیقا همین اتفاق افتاده بود.

این ویدئو رو یکی از بچه‌های همون تیم برام فرستاد.

Youtube Link

اگر روی Optimization کار می‌کنید؛ پیشنهاد میدم این سخنرانی رو ببینید.
خیلی نکات خوبی رو می‌گه

شخصا بسیار لذت بردم

این ویدئو روی Rust هست؛ اما تکنیک‌هایی که برای پیدا کردن مشکل و اپتیمایز کردن کدها گفته می‌شه کاملا روی پایتون هم جواب میده.
قبلا راجب پروفایلینگ روی پایتون صحبت کردم.

با توجه به اینکه اکثر دوستان اینجا بکند یا هوش مصنوعی کار می‌کنند بنظرم دیدن این ویدئو خالی از لطف نیست.

Youtube Link

اینبار برای TimescaleDB اوایل سال راجب تستم ازش یک متنی نوشتم توی یکی از کانال‌ها زیر قضیه همون Postgres هست ولی بجای اینکه شما Partitioning, ... رو انجام بدید این دیتابیس این موارد رو بهتون میده.
توی این آموزش هم که همه چیز باهم رو تمرین می‌کنید.

اگر از uv استفاده می‌کنید حتما اون رو آپدیت کنید یک باگ
RCE: Remote Code Execution
توی یکی از کتابخونه‌ها پیدا شده که البته uv هم ازون کتابخونه استفاده می‌کرده.

چون موضوع مربوط به Rust هست توضیحات بیشترش رو داخل کانال Rust می‌نویسم ولی خواستم اعلام کنم که حتما آپدیت کنید uv رو
@pyrust

یک آپدیت روی این بدم؛ یک چندوقتی هست بجای Makefile دارم از Justfile استفاده می‌کنم:
بنظرم یک آپدیت خیلی خوب هست روی Makefile و خیلی هم syntax راحتی داره (اگر قبلتر روی Makefile کار کردید)
مثلا ارسال پارامتر بعد از کامند یا گذاشتن مقدار دیفالت براش خیلی خیلی ساده‌اس

انیجوری نیست که بگم این فیچرهای بهتری داره پس بریم سراغش؛ مثل taskfile هم نیست که یک سری چیز مخصوص به خودش رو اضافه کرده باشه که توی ابزارهای دیگه نبوده و نیست؛ و به نظرم همین هم باعث شده ابزار خوبی باشه اینکه Makefile ولی بهتر رو ارائه داده

مثل کامند‌ less که همون more هست ولی بهتر!

Just Github

پینوشت: توی مثال قبلی من از Makefile بعنوان Command Runner استفاده می‌کنم و نه Builder حواستون به این نکته باشه که Just کاربردش فقط همین هست.

"When the bad file with more than 200 features was propagated to our servers, this limit was hit — resulting in the system panicking."
"This resulted in the following panic which in turn resulted in a 5xx error:
thread fl2_worker_thread panicked: called Result::unwrap() on an Err value"

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

حالا مشخص شده اون باگ از یک خطای انسانی افتضاح میاد.
داستان اینه؛
یک سرور به محدودیت می‌خوره و از دسترس خارج می‌شه که باعث میشه تمام ریسپانس‌هاش خطای ۵۰۰ باشه؛ اما یک توسعه دهنده بجای اینکه response رو بررسی کنه که آیا ۲۰۰ هست یا نه
فرض کرده چون ما داخل دیتاسنتر هستیم و کلودفلیر هیچوقت غیر از ۲۰۰ نمی‌گیریم.
پس unwrap زده و چون غیر از ۲۰۰ گرفته بوده؛ سیستم ترکیده.

چندتا نکته :
۱- هیچ چیزی رو فرض نکنید، همه چیز رو تست کنید.
من هم توی بعضی کدهام unwrap می‌نویسم؛ اما خیلی وقتا عمدی هست چون واقعاً نمی‌دونم خروجی اون تابع یا ماکرو چطور می‌تونه Error باشه!
می‌نویسم که بیزینس در بیاد.

۲- زبان برنامه‌نویسی Rust فقط امنیت روی مموری بهتون میده؛ قراره نیست براتون نون هم بخره.
نکته جالبتر اینکه؛ AI هم این خطاهارو تشخیص نمی‌ده !!
اینه که همیشه از peer-review استقبال باید بشه.

۳- مورد راحتی مثل خطای 5xx توی http و اینکه حتی این مورد ساده هم تست نشده؛ نشون میده کلودفلیر هم که بری؛ قرار شیت کد ببینی.
پس دوست عزیز حداقل تست بنویس.

#خارج_از_بحث

این پست راجب git هست و استخدام؛ می‌خواستم توی رندرنج بنوسیم ولی چون مدیرایی که می‌شناسم بیشتر توی این کانال هستند گفتم اینجا بذارم.
مدیرعامل یک شرکتی باهام تماس گرفت (از طریق یک واسط) مشکلش این بود :
ما یک نیروی Senior استخدام کردیم؛ چون توی شرایط بدی بودیم خیلی هم سریع پروسه استخدام رو پیش بردیم اما الان به یک سری مشکلات خوردیم:

۱- نیروی سنیور پرفورمنس خیلی پایینی داره؛ درحالی که وقتی رزومه‌ای که برامون فرستاد رو بررسی کردیم یک چندتا پروژه روی گیت‌هاب داشت که بسیار شبیه کارهایی بود که ما داریم می‌کنیم (منظورش این بود مطالب باید براش تکراری باشه).
۲- نیروهای دیگه شرکت که بیشتر سطح متوسط و مقدماتی هستند همه از نیروی سنیور (لید تیم هم هست به نوعی) ناراضی هستند و حتی سواد فنی‌اش رو هم قبول ندارند.
درنهایت وقتی هم که به خودش می‌گم؛ می‌گه نیروها دانش کمی دارند؛ حرفای منو متوجه نمی‌شوند و همین باعث شده پرفورمنس خودمم بیاد پایین چون همش باید دنبال یک راهکاری برای توضیح دادن به اینا باشم.

قرارشد من بعنوان مشاور یا کسی که قراره CTO تیم بشه با نیروها صحبت کنم؛ مشکل رو پیدا کنم اگر راه حل داشت ارائه بدم اگر باید نیروها اخراج می‌شدند و نیروی جدید استخدام می‌شد بگم. جز مدیرعامل شرکت کسی این موضوع رو نمی‌دونست.

یک مقدار کدها رو خوندم بعد با نیروی مثلا سنیور قرار شد چندتا جلسه بذاریم (بحث این بود که ایشون توی جایگاه خودش بمونه و من وارد بشم چون ۳ تا تیم با موضوعات دیگه قرار هست وارد بشه)
همون جلسه اول من بهش مشکوک شدم؛ باور کنید یا نه آدم ناشی و اصطلاحات و لغت حفظ کرده از آدم کار بلد و توی کار تست کرده توی ۱۰-۲۰ دقیقه صحبت فنی به راحتی تفکیک میشه مخصوصا اینجا که یک پروژه واقعی درجریان هست.
با این حال من ۲ تا جلسه دیگه هم با ایشون شرکت کردم.

درنهایت متوجه شدم که کلا دلیل استخدام ایشون پروژه‌های github بوده؛ دوتا شک داشتم خرید ساعت کاری و سفارش به شخص که با اکانت ایشون کامیت بزنه (خودم یک زمانی برای پچه‌های دکتری و ... خارج از ایران اینکار رو می‌کردم. قبلا دربارش گفتم ولی برای کسانی اینکار رو می‌کردم که باسواد بودند و با شرکت‌های خوبی کار می‌کردند و مشکل این بود زمان کافی برای کلاس رفتن و حل تمرین کلاس نداشتند منم واسه یادگیری پول می‌گرفتم.)
شک دومم که بعد از بررسی یک سری پروژه‌های گیت‌هاب بیشتر شد؛ این بود که پروژه‌های آدمای دیگه رو گرفته و لاگ رو تغییر داده.


همین هم بود؛ خلاصه اینکه:
فکر نکنید لاگ git تا ابد ثابت هست؛ همه کاری میشه باهاش کرد.
تغییر ساعت و جزئیات commit؛ تغییر اطلاعات
تغییر اینکه کی commit زده
commit message, branch, merge info, ...

من این موارد رو نشون دادم و اشتباه اون آدم رو هم توی git-log پیدا کردم (یکجا دولوپر اصلی توی یکی از اطلاعات commit خیلی قدیمی یک ایمیل گذاشته بود و ...)
خلاصه که این موضوع رفته برای شکایت یا توافق؛ ولی حواستون باشه git, ... به تنهایی ارزشی نداره دانش شخص و سوادش برای کاری که شما ازش می‌خواید خیلی خیلی مهم تر هست.

یاد داستان اون شخص افتادم که توی گوگل بود؛ به زور کردنش مدیر یک بخش فنی؛ بنده خدا زبونش می‌گرفت نمی‌تونست بگه توی گوگل آبدارچی بوده! چون زودی می‌پریدن تو حرفش 😂

شرکت Meta در ادامه پروژه‌های OpenSource بالاخره پروژه Pyrefly رو توی نسخه beta منتشر کرد
vscode, pycharm, neovim, ...
مواردی هستند که Extension براشون منتشر شده.

این پروژه یک Language Server, Type checker هست روی پایتون.
چرا Meta اینکار رو کرده ؟
خودشون اعلام کردند مشکل از کدبیس بزرگ Instagram شروع شده تا جایی که انقدر این کد بزرگ بوده که navigate, code complete و ... یا زمان زیادی می‌برده یا بخوبی انجام نمی‌شده برای همین Pyrefly رو توسعه دادند که اولین مشتریش هم تیم Instagram هست و بصورت هفتگی هم آپدیت خواهد شد.
جالبترین نکته اینکه؛ این پروژه هم با Rust نوشته شده و به همین دلیل هم هست که سرعت خیلی بالایی داره.

مهمترین بخش آپدیت Beta بنظرم پشتیبانی از Pydantic, Django هست؛ بخصوص برای Django که کلی کانفیگ نیاز بود توی ابزارهای جایگزین.

درنهایت:
شخصا روی تنظیمات؛ neovim بعد از استیبل شدن اضافه خواهم کرد (اگر خوب پیش بره) و درحال حاضر روی vscode فقط تستش می‌کنم.

Pyrefly Github

مشکل امنیتی جدید whatsapp که باعث شده 3.5 میلیارد پروفایل و اطلاعات پروفایل در کرال بشه؛
این گزارش ربطی به هک شدن واتساپ و ... نداره (چون دیدم بعضی کانالا می‌گن واتساپ هک شده؛ یا سرورهای متا هک شده)

مشکل اصلی که ضرر مالی بزرگی هم مثل اینکه به Meta زده سر نداشتن Rate Limit بوده البته متا سریعا آپدیت کرده و سرعت کرال داده رو کند کرده ولی خب بعد از اینکه ۳.۵ میلیارد اکانت کرال شده.
شماره تماس؛ وضعیت و اگر تصویر پابلیک بوده عکس پروفایل.

خداروشکر من اصلا یوزر واتساپ نیستم؛ حتی برای کار هم نصب نکردم.
ولی خطر کرال شدن این دیتاها برای کاربرها چیه ؟

۱- فیشینگ؛ طرف کلی اطلاعات از شما داره (اسم و فامیل + عکس + شماره تماس) همین می‌تونه برای انجام فیشینگ کافی باشه. ولی بیاید فرض کنیم مثل من فکر کنه.
شماره موبایل شمارو توی پلتفرم‌های دیگه سرچ می‌کنه؛ تلگرام + توییتر + فیسبوک و ...
از تلگرام آیدی‌ها و عکس‌های بیشتر؛ علاقه مندی و ... می‌تونه پیدا بشه
از توییتر و اینستاگرام؛ آدمای نزدیک به شما؛ جبهه گیری سیاسی و کلی اطلاعات بدرد بخور دیگه که ادامه نمیدم ولی فقط همینقدر که تگ زدن شما به لطف LLM ها کار سخت و زمانبری نیست.

۲- پروفایل سازی؛ با این حجم دیتا و داشتن شماره تماس؛ چیزی که توی قدم قبلی گفتم می‌تونه از شما و تمام آدم‌های نزدیک بهتون پروفایل بسازه. توی پلتفرم‌های مختلف بررسی کنه و روی گراف بیاره تا بدونه از چه طریقی به شما نزدیک بشه امکان نفوذ بیشتر هست.

۳- جستجوی یوزر با یک تصویر صورت؛ بدست آوردن شماره و ....

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

کاری هم که کردن ساده بوده؛ تمام شماره‌های موجود رو درست کردن ۶۳ میلیارد بعد شروع کردن سرچ کردن اون شماره‌های روی واتساپ!
توی تلگرام اگر این کار رو کرده باشید؛ بلاک می‌شید یا اینکه بعد از ۲۰۰ مورد باید اون‌هارو به شماره‌هاتون اضافه کنید که ظرفیت اینکار هم ۲۵۰ مورد هست.

اما درس امروز برای بکند دولوپر‌ها؛
حتما rate limit بذارید این گروه همه‌ی شماره‌هارو از یک ip کرال کردند. منم کلی پلتفرم ایرانی رو کرال کردم قبلا پس مطمئنم که خیلی‌ها rate limit نمی‌ذارند.

پینوشت:
مثل اینکه این گروه تحقیقاتی بودند و مقاله‌ نوشتن راجبش (آنالیز روی دیتاها زدند)