کتاب Fluent Python همین الان رسید دستم

کیفیت کاغذ و کیفیت چاپش واقعا خوبه

الان درگیر هستم، توضیح دیگه ای لازم بود. همین پست رو ویرایش میکنم.

- آدرس کانال اصلی شون: @ITBook_Pub
-  نمونه کار هاشون: @ITBook_Images

ویرایش:
-دیروز خونه نبودم، وگرنه میخواستن بفرستن
-حاشیه داخلی کتاب خوبه و نیاز به سیمی کردن نداره
-چهار روز بعد از سفارش به دستم رسید، البته من ساکن تهرانم و از تهران برای من ارسال شد

تخفیف های 80 درصدی دوره های سایت دانشجویار

دوره فروشگاه جنگو من هم شامل شده

البته اینی که پای لپ تاپ ع، ظاهرا شهرشون یه متر برف باریده تو پاییز 🥶

https://www.daneshjooyar.com/landing/autumn1404/

سری مهندسی نرم‌افزار: پست 11
از لینکدین Saeed Shahrivari Joghan
قواره کردن کت به سبک خیاطی

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

۱- ادغام نقش‌ها: من خیلی از دوستان با تجربه شنیدم که نقش‌هایی مثل «مالک محصول» به درد نمی‌خوره و چرنده و ما چرا باید به یه نفر کلی حقوق ماهیانه بدیم که یه نقش الکی به نام مالک محصول داشته باشه؟ خب اگه شما حتی یه تجربه خیلی محدود در پیاده‌سازی یک سیستم مالی یا سرمایه‌گذاری داشته باشید خیلی راحت درک می‌کنید که در چنین نرم‌افزارهایی به دلیل دانش تخصصی عملاً یک مهندس نرم‌افزار بدون کمک کسی که مالک محصول باشه توانایی دلیور کردن نخواهد داشت. اما در تمام پروژه‌ها واقعا نیاز به یک مالک محصول تمام وقت نیست و خیلی از اوقات یکی از توسعه‌دهنده‌ها میتونه همزمان نقش مالک محصول رو هم ایفا کنه یا برعکس در پروژه‌های خیلی پیچیده ممکنه چندین مالک محصول داشته باشیم. بنابراین به جای حذف نقش‌های مالک محصول و اسکرام مستر میشه عوض یک فرد تمام وقت این نقش‌ها رو به
توسعه‌دهنده یا فرد دیگه‌ای سپرد ولی لطفا هرگز این نقش رو حذف نکنیم (توجه کنید که از واژه نقش استفاده می‌کنم نه فرد)

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

۳- تغییر در آرتیفکت‌ها: برای مثال اگه انجام تخمین برای وزن‌دهی به آیتم‌های بک‌لاگ با استفاده از اعداد براتون سخته میشه از سایز‌های تیشرت استفاده کرد. یا میشه تعریف done رو برای هر تیم شخصی‌سازی کرد.

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

کمی در باب UUID

توی اکثر سیستم‌های اطلاعاتی، چه در مورد پیام‌های مورد تبادل بین سرویس‌های یک نرم‌افزار مبتنی بر مایکروسرویس صحبت کنیم، چه در مورد داده‌های دیتابیس، نیاز به یک روش مطمئن برای شناسایی منحصربه‌فرد داده‌ها وجود داره. استفاده از شناسه‌های ترتیبی (Sequential Integers) مثل Auto-Increment توی دیتابیس‌ها ساده و سریعه ولی توی محیط‌های توزیع‌شده که چندین سرور به طور همزمان ID تولید می‌کنن، برای جلوگیری از تکرار، نیاز به هماهنگی مرکزی دارن که خودش گلوگاه مقیاس‌پذیریه (Scalability).

برای پاسخ به این نیاز، UUID (Universally Unique Identifier) به وجود اومده. UUID‌ها شناسه‌های 128 بیتی (۳۶ کاراکتر) هستن که بدون نیاز به هماهنگی مرکزی، منحصر به فرد بودن رو در سطح جهانی تضمین می‌کنن. سال ۲۰۲۴، استاندارد رسمی RFC 9562 نسخه‌ی ۷ رو معرفی کرده: ۴۸ بیتِ اول «تایم‌استمپ یونیکس بر حسب میلی‌ثانیه»، بقیه بیت‌ها تصادفیِ امن. نتیجه؟ شناسه‌ها زمان‌مرتب و در عین حال یونیک هستن. چرا زمان‌مرتب بودن این شناسه‌ها مهمه؟ چون مثلا توی نسخه ۴، شناسه کاملا تصادفیه و اگر به ترتیب بخواهیم مرتب کنیم احتمال اینکه شناسه‌ای که الان تولید می‌کنید بعد از شناسه‌ای که دو ساعت پیش یا دو سال پیش تولید کردید قرار بگیره زیاده. این یعنی شروع مشکل. چه مشکلی؟ ایندکس جداول یا سری‌های زمانی.

فرض کنین یه کتاب دارید که شماره صفحاتش کاملا رندوم ولی یکتا باشه. در حالت عادی که شماره صفحات مرتب و دنبال هم هستن وقتی دنبال صفحه ۱۳۷ کتاب می‌گردید، اول یه جای کتاب رو باز می‌کنید و می‌بینید مثلا ۱۸۹ است، چون مطمئنید شماره ۱۳۷ قبلش است دیگه صفحات بعدی رو نگاه نمی‌کنید، یه جا قبل‌تر رو باز می‌کنید می‌بینید ۱۲۵ است، دیگه قبل‌تر و نمی‌گردید و چند صفحه جلوتر، ۱۳۷ رو پیدا می‌کنید. این یعنی پیدا کردن سریع‌تر مطالب. حالا اگر شماره صفحات رندوم باشه، هر بار که مرتبش کنیم با اولین مقدار جدید، نظم به هم می‌ریزه و پیدا کردن صفحات دشوار می‌شه.

مرور نسخه‌ها تا به امروز:

نسخه v1: مبتنی بر زمان و MAC Address  » ترتیبی بر اساس زمان، یونیک جهانی » ولی افشای آدرس MAC (مشکل حریم خصوصی)

نسخه v2: مبتنی بر Domain محلی و Security  » رزرو شده برای DCE Security » کاربری و استفاده بسیار محدود.

نسخه v3: مبتنی بر نام (MD5 Hashing)  » همیشه برای یک "نام" و "دامین" مقدار یکسان تولید می‌شه.  » از هش قدیمی MD5 استفاده می‌کنه که منسوخ شده.

نسخه v4:  کاملاً تصادفی، یونیک جهانی با بالاترین میزان تصادفی بودن. » نامرتب؛ عملکرد ایندکس دیتابیس (B-tree) رو به شدت کاهش می‌دهه. » متاسفانه همچنان رایج، اما برای Primary Key نامناسب.

نسخه v5:  مبتنی بر نام (SHA-1 Hashing)  مشابه v3، اما از هش بهتر SHA-1 استفاده می‌کنه » فقط برای مواردی که نیاز به تکرارپذیری UUID است، مناسبه.   » بهتر از v3، برای تولید شناسه‌های ثابت از URL یا نام.

نسخه v6: مشابه v1 ولی با ترتیب زمانی بهتر » مرتب زمانی، ولی بدون افشای MAC
» هنوز نسخه draft است، » کاربردش جایگزینی v1 در آینده

نسخه v7: مبتنی بر زمان یونیکس + مقدار تصادفی » مرتب بر اساس زمان و در عین حال یونیک جهانی + عملکرد بهینه دیتابیس »   بهینه برای Primary Key خصوصا توی سیستم‌های توزیع‌شده و سری‌های زمانی »  امکان افزودن کسریِ زیرِ میلی‌ثانیه و/یا کانتر هم برای تضمین مرتب‌بودن در همان میلی‌ثانیه پیش‌بینی شده.

نسخه v8: فضای سفارشی/تجربی برای نیازهای خاص.

📌 نسخه UUIDv7 به صورت بومی توی PostgreSQL 18 و SQL Server 2025 و پایتون ۳.۱۴ و دات‌نت ۹ و گو هم gofrs/uuid v5 پشتیبانی می‌شه ولی MySQL و MariaDB و جاوا هنوز نسخه بومی رو پیاده نکردن.

✍تِک افترنون