داستان تعزیه در ایران، به روایت MMehran. رشته‌ توییتی‌ست خوندنی:

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

https://x.com/MMehran/status/1560264132703571968

بیاید اول یکم مرور کنیم که Fuzzing چیه. فرض کنید یک فانکشن‌ای نوشتید که چهار تا عدد از تایپ integer رو به عنوان پارامتر دریافت میکنه. فرض کنید تابع‌تون چیزی شبیه به اینه :

fun foo(int x, int y, int z, int t) {
    
    // bunch of statements

    if ( (x^t+1)^3 + (2.3*y)^2.3 - 0.8*(z^4) == 0) { // call the condition as 'f'
        Bug();
    }

    // bunch of statements
}

همونطور که ملاحظه می‌کنید، توی برنامه‌ما یک point ای وجود داره که اگر reachable باشه به باگ می‌خوریم. حالا سوالی که وجود داره اینه که بفهمیم آیا این امکان وجود داره که شرط f ارضا بشه یا خیر. برای اینکه به جواب سوال‌مون برسیم، باید یک decision procedure پیاده‌ کنیم که به عنوان ورودی فرمول f رو ازمون بگیره، و بهمون true یا false برگردونه. یک computer scientist اولین سوالی که به ذهنش میرسه اینه که آیا این مسئله محاسبه پذیره یا خیر و اگر هست از نظر پیچیدگی در چه کلاسی قرار داره. به طور خلاصه خدمتتون میگم که این مسئله undecidable هستش. حالا سوالی که پیش میاد اینه که چیکار کنیم؟ رهاش کنیم بره؟ خب قطعا نه. یه راهی که از دهه ۵۰ میلادی، یعنی از زمان پانچ کارت ها وجود داره اینه که بیایم شروع کنیم با یک الگوریتم Pseudo random number generating برای این ۴ تا متغیر value جنریت کنیم و چک کنیم ببینیم که آیا این فرمول تحت اون assignment ارضا میشه یا نه. اگر شد که خب میگیم بله reachable هستش و برنامه مون باگ داره. اگر نشد... خب بیاید این یه تیکه رو فعلا اسکیپ کنیم :)

حالا قضیه‌ی Fuzzing هم ریشه‌اش برمیگرده به random testing اما قطعا با رندوم تستینگ فرق داره. می‌تونیم بگیم رندوم تستینگ ساده‌ترین و naive ترین نوع Fuzzing هستش. تکنیک‌های Fuzz testing با توسعه‌ای که از دهه ۹۰ تا الان داشتن، ساختارمند شدند و باهوش تر عمل می‌کنند. یک سری‌هاشون از نوع generation-based هستند یعنی هر iteration ورودی‌ها رو از اول تعیین می‌کنند. یک سری‌هاشونم mutation-based هستند و میان input ها رو modify می‌کنند. فاز تستینگ‌ها به شکل white و black و gray box انجام میشن. بلک باکس اینطوریه که fuzzer هیچی از ساختار برنامه نمی‌دونه. gray box یعنی اینکه ما نیاز داریم کمی instrumentation روی کدمون انجام بدیم و به طبع white box هم که مشخص میشه چیه.

فازری که داچمن رفته سراغش از نوع gray-box و mutation-based هستش. منتهی باهوش تره، یعنی بلده که mutation هاش رو به سمت یک سری هدف و یا coverage خاص که از پیش براش مشخص شدن هدایت کنه. اصلاحا به این نوع فازرها میگن Directed Grey-box fuzzing. این تکنیک توسعه‌ و پیاده‌سازیش توسط آقای Abhik Roychoudhury و تیمش صورت گرفته. ایشون یه گروه بسیار سوپر و قوی توی دانشگاه NUS دارن که تو حوزه‌ی Fuzzing و Automated Program Repair فعاله. بسیار توصیه می‌کنم اگر به این بحثا علاقه‌مند هستید برید و کارشون رو بخونید.

تا اینجا مقدمه بود میریم سراغ بحث اصلی.

بحث Graybox Fuzzing بسیار توی این سال‌های اخیر مورد توجه قرار گرفته و سعی میشه توی کابردهای مختلفی بیان و یک فازر Target-specific طراحی کنن. بزرگترین ضعف Fuzzer ها زمانیه که به دنیای Distributed Systems و Concurrency ورود می‌کنن. تمام این حرفایی که توی پست بالا در مورد AFLGo زدم صرفا منوط میشه به برنامه‌های Sequential. توی برنامه‌های ترتیبی چون صرفا یک Thread داریم، واسه همین چیزی به اسم Scheduler وجود نداره در مقابل Fuzzer. مثلا همین مثالی که من زدم یا کیس استادی داچمن، این ابزارها میان با تکنیک‌های Static Analysis بررسی میکنن که آیا اون نقطه Reachable هست و هر جا که لازم باشه برای رسیدن به اون نقطه ورودی تهییه کنن، فازر رو صدا میزنن. خیلی بخوان براتون مرام خرج کنن به جای Static Analysis میان از تکنیک‌های Runtime Analysis استفاده میکنن که البته توی اینم خیلی ضعیفن و اکثر ابزارهای قوی این حوزه تکیه شون به Static Analysis عه. یعنی میان از طریق آنالیز سینتکس کدتون پیش میرن. خود غیرقطعی بودن Fuzzer یک طرف، اینکه Static Analysis بخاطر اینکه خیلی از مسائل کلیدیش Undecidable عه کلی corner case به جا می‌ذاره یک طرف.(اینجا یکم توضیح دادم اینو). خب همه‌ی اینا باعث میشه که Fuzzer ها نسبت به یک سری از برنامه‌های ترتیبی هم حتی خوب عمل نکنن. مثلا فرض کن برای اون فرمول f ای که توی پست قبل آوردیم، بیاد و ۱ میلیارد assignment جنریت کنه ولی هیچکدوم نتونن فرمول رو ارضا کنن. سوال، آیا فرمول ارضا ناپذیره، یا اینکه واقعا assignment ای وجود داره که fuzzer نتونسته پیداش کنه؟ جواب، نمی‌دونیم. ایراد بعدی شون توی برنامه‌های Sequential، گیرم Fuzzer بیاد و یه assignment به ما برگردونه و بگه این کار رو خراب میکنه. آقای داچمن هم برن و کلی کد رو بخونن و بالا و پایین کنن و یک patch ای بدن که دیگه برنامه روی اون assignment به باگ نخوره. آیا به راستی حالا که اینطور شده، باگ برنامه برطرف شده؟ جواب، نمی‌دونیم.

حالا بریم سراغ برنامه‌های Distributed و Concurrent. توی این برنامه‌ها یک چیزی هست به اسم Scheduler که داره thread ها رو زمان‌بندی می‌کنه. فازرها وقتی به چنین سدی میخورن هیچ برنامه‌ای براش ندارن. همینطور رندوم scheduler جلو میره و هر وقت لازم باشه برای جلو رفتن یک input ای داده بشه فازر کال میشه. حتی به فرض تهش هم یک assignment ای برگردونده بشه و شما بفهمی که برنامه‌ات باگ داره. از کجا میخوای بفهمی که چه Scheduling ای ما رو به این باگ رسونده؟ عملا دیباگینگ برنامه غیرممکن میشه. حالا همین آقای Abhik سال پیش یک مقاله‌ای رو چاپ کردن با عنوان Greybox Fuzzing of Distributed Systems که نشون بدن خیز برداشتن برای Distributed System. به زودی همین امسال دیس این مقاله میاد بیرون :) برای پیش درآمدش این تاک رو ببینید ( از 5:17:29 تا 5:48:36)

با همه‌ی این توصیفات جا داره بگم که Fuzzing و Static Analysis به هیچ وجه نمی‌تونن جای خالی Verification رو پر کنن و ما این رو با توسعه JMC نشون خواهیم داد. شما وقتی برنامه‌ات رو با JMC وریفای می‌کنی، اگر باگ داشته باشه قطعا پیداش میکنه، برات یک Execution Trace از ابتدای اجرای برنامه برمیگردونه که نشون بده چی شد که به این باگ رسیدیم و علاوه بر اون دیتای کامل Scheduling ای که ما رو به این باگ رسونده رو هم بهتون میده، شما مقایسه کنید Debugging با این حجم دیتا آسون تره و یا صرفا با داشتن چهار تا Value ؟

حالا برای اینکه خیلی هم سر دیباگینگ اذیت نشید یه کاری رو داریم با خانم Andreea Costa شروع میکنیم، ایشون یکی از محققین گروه Abhik هستند، که با استفاده از JMC برنامه رو وریفای کنیم و وقتی باگ رو پیدا کردیم به شکل Automated برنامه رو Repair کنیم تا دیگه باگی نداشته باشه. یعنی نه تنها باگ رو پیدا کنیم بلکه رفعش کنیم و ثابت کنیم که باگ واقعا رفع شده. تمام تکنیک‌های Automated Program Repair تا به امروز بر پایه‌ی Static Analysis و Fuzzing ساخته شدن و قطعا می‌تونید حدس بزنید که Patch هایی که می‌سازه ممکنه واقعا Bug-free نباشه.

خلاصه که فرمال پیشه کنید.

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

استفاده از LLMها چه بلایی سر یادگیری میاره؟

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

Working hard and struggling is actually an important way of learning. When you’re given an answer, you’re not struggling and you’re not learning. And when you get more of a complex problem, it’s tedious to go back to the beginning of a large language model and troubleshoot it and integrate it.

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

https://cacm.acm.org/news/the-impact-of-ai-on-computer-science-education/

علم چیست؟ شبه‌علم چیست؟

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

وقتی راجع‌به علم صبحت میکنیم و این که ادعا کنیم که آیا روشی که به‌کار می‌بریم (یا به ‌کار برده شده) علمی یا scientificه، دو ویژگی براش درنظر گرفته میشه:

۱- تکرار‌پذیری (Replicability) داشته باشه. به این معنی که بشه در شرایط یکسان و با به‌کار گیری روش یک‌سان دوباره به اون نتیجه رسید. البته دو واژه‌ی Reproducibility و Replicability گاها به‌جای هم استفاده میشن. گاهی این دو رو به یک معنا میدونن، گاهی هم تعریف‌های متفاوتی براشون در نظر میگیرن:

In a review paper on the use of the terms reproducibility and replicability, Barba (2018) outlined three categories of usage, which she characterized as A, B1, and B2:

A: The terms are used with no distinction between them.
B1: “Reproducibility” refers to instances in which the original researcher's data and computer codes are used to regenerate the results, while “replicability” refers to instances in which a researcher collects new data to arrive at the same scientific findings as a previous study.
B2: “Reproducibility” refers to independent researchers arriving at the same results using their own data and methods, while “replicability” refers to a different team arriving at the same results using the original author's artifacts.

۲- ابطال‌پذیر (Falsifiable) باشه. به این معنی که اصولا گزاره و نظریه‌ در معرض ابطال باشن. در واقع این امکان وجود داشته باشه که بشه آزمایشی رو طراحی کرد یا مشاهده‌ای رو مطرح کرد که تحت اون بشه اون نظریه یا فرضیه رو رد کرد:

“In so far as a scientific statement speaks about reality, it must be falsifiable: and in so far as it is not falsifiable, it does not speak about reality.”
― Karl R. Popper, The Logic of Scientific Discovery

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

این اپیزود از پادکست «فلسفه‌ی علم» به این میپردازه که چطور علم رو از شبه‌علم میشه تمیز داد. «ابطال‌پذیری» یا «falsifiability» که پوپر اون رو سنجه‌ای برای تشخیص علم از شبه‌علم عنوان کرد به چه معناست و چه رابطه‌ای بین فلسفه‌ی علم و تاریخ علم وجود داره.

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

شاخص بیگ مک

It’s just a burger, but the price of a Big Mac can help us understand the dizzying cost of living.

“If [the price of a Big Mac is] moving, it means there’s something really strong going on in the economy at large,”
-Leonora Risse, associate professor of economics at the University of Canberra.

راجع به شاخص قدرت خرید و سنجش برابری قدرت خرید (PPP) داخل کانال قبلا یکی دو تا پست گذاشتم که به‌نظرم اون‌ها رو ببینید. ارجاع دادم به ویدیو‌ی چراز که خیلی خوب این ماجرا رو توضیح داده. ولی جهت یادآوری، به طور خلاصه: برای این که بشه قدرت خرید مردم کشور‌های مختلف رو سنجید درحالی که ارزش پول یک‌سان ندارند، روش‌‌های مختلفی وجود داره. یکی از اون روش‌ها، روش غیر رسمی‌ه به‌نام شاخص بیگ مک یا Big Mac Index.

ماجرا از این قراره که با پاسخ دادن به این سوال که شما توی کشورتون، با ۵۰ دلار آمریکا (به طور معمول ارز مبدا رو دلار آمریکا در نظر میگیرن)، چند تا بیگ مک میتونید بگیرید به تخمینی از قدرت خرید مردم اون کشور برسید. این که چرا بیگ مک انتخاب شده و فرقش با PPP چیه، ماجرا از این قراره:

- prevalence of the fast food chain worldwide
- the sandwich remains largely the same across all countries.

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

این مقدمه رو گفتم که این مطلب رو بذارم. تو این مقاله اومدن تغییرات هزینه‌‌ی زندگی و بحران‌هایی که در یک بازه‌ی چند‌ساله (از ۲۰۱۷ تا ۲۰۲۴) رو با همین شاخص بررسی کردن. این که چه تغییرات قیمتی توی اجزای یک ساندویچ بیگ مک پیش اومده و یه سری آمار و ارقام دیگه و به طور خاص به دوره‌ی COVID هم پرداختن. این پست اینتراکتیوه و خیلی حرف رو ساده و سر راست میزنه که خوندنش رو جذاب کرده. اگر حوصله داشتید، به‌نظرم خوندنش براتون میتونه هم جالب باشه هم مفید.

https://www.abc.net.au/news/2024-08-05/cost-of-living-interest-rates-burgers/104156654

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

یه بابایی اومده و کامپیوتر ۸‌بیتی که توی کتاب "But How Do It Know? " نوشته‌ی J Clark Scott توصیف شده رو با Go و Assembly شبیه‌سازی کرده بدون این که درگیر کار با ادوات الکترونیکی بشه. اینجا راجع‌به این تجربه‌ش نوشته:

A few months ago it dawned on me that I didn’t really understand how computers work under the hood. I still don’t understand how modern computers work. However, after making my way through But How Do It Know? by J. Clark Scott, a book which describes the bits of a simple 8-bit computer from the NAND gates, through to the registers, RAM, bits of the CPU, ALU and I/O, I got a hankering to implement it in code.

https://djharper.dev/post/2019/05/21/i-dont-know-how-cpus-work-so-i-simulated-one-in-code/


ولی اگه دلتون میخواد ببینید چطوری میشه همچین کامپیوتری ساخت و نه صرفا شبیه‌سازیش کرد، این پلی‌لیست برای شماست:

Building an 8-bit breadboard computer!

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


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

یک مورد دیگه رو هم من اشاره کنم که خیلی به چشمم اومد.

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

شاید این مثل من به درد شما هم خورد: How to read a research paper

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

احتمالا خیلی از شمایی که اینجاید مشکل خواب دارید و خب خوبه که یه فکری به حالش بکنیم. این ویدیوییه که امروز منتشر کرده با موضوع خواب:

https://www.youtube.com/watch?v=XCdjr-xbDFw

این برنامه با همکاری «مرکز تحقیقات علوم و اعصاب» و «انجمن پزشکی خواب ایران» تهیه شده.

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

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

@gocasts

Assembler, Compiler, Linker, Interpreter, Loader all in simple words

https://ce101ms.wordpress.com/wp-content/uploads/2014/02/compiler_assembler_linker_loader.pdf

اگر علاقه‌مند به سیستم‌های فشرده‌سازی (و به‌طور خاص، عکس‌ها) هستید، حتما یه نگاهی به وب‌سایت JPEG بندازید. ماجرا از اینجا شروع شد که داشتم خبر شایعه‌ی امکان اضافه‌شدن پشتیبانی و ذخیره‌ی عکس‌ها با فرمت JPEG-XL در آیفون ۱۶ رو میخوندم و به سببش با این فرمت آشنا شدم. با همون عادت همیشگی شروع کردم یکم بیشتر سرک کشیدن و خب خیلی سریع هم سر از وب‌سایت رسمی JPEG در آوردم. برام جالب بود که ما چندین و چندین نوع از JPEG داریم: XR, XS و ... که هرکدوم کاربرد و ماجرای خودشون رو دارن.

اینجا میتونید خیلی بیشتر و مفصل‌تر راجع‌به JPEG-XL بخونید و اگر خیلی نرد بودین هم، میتونید اینجا و اینجا بیشتر راجع‌به Entropy Coding که برای فشرده‌سازی Lossless استفاده میشه و در JPEG-XL هم استفاده شده بخونید.

این رشته توییت جالب از سرگذشت «یک میلیون چک‌باکس» رو از دست ندین:

https://x.com/Loc0m0/status/1832188628719825347

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

https://youtu.be/OI4DbECnp8A?si=T3Y0PLuPrZMFNCBh

مهندسی‌ نرم‌افزار برای دیتاساینتیست‌ها

واقعیت غیرقابل انکاری که وجود داره وجود یک gap میان software engineering و data scientist هاست. دیتاساینتیست‌ها معمولا به دانششون در حوزه هوش و تحلیل داده می‌نازند، در حالی که هر چه قدر هم این دانش عمیق باشه اما در موقعیت‌های عملی واقعی که نیاز به طراحی و توسعه یک محصول پایدار و منعطف با همراهی با بقیه توسعه‌دهنده‌ها می‌ره، نیاز به نوعی دانش و مهارت مهندسی نرم‌افزار وجود داره. حالا این کتاب Software Engineering for Data Scientist از انتشارات Oreilly سعی داره تا همین گپ رو برای دیتا ساینتیست‌ها پر کنه و به میزان کافی و نه بیشتر، به اونها نکات مهندسی‌طور قضیه رو هم انتقال بده. کتاب متن خوبی داره و واقعا قبل از این که یک کتاب مهندسی نرم افزار باشه یک کتابیه که انگار از زاویه دید یک دیتا ساینتیست به مسائل و راه‌حل‌هاشون نگاه کرده، برای همین خیلی‌ جاها مثال‌هاش رو حتی روی ژوپیتر نوتبوک هم زده. این کتاب ۱۵ فصل داره:
چه طوری بهتر کد بنویسم و کد خوب اصلا چیه
چه طوری و از چه زوایایی عملکرد کد رو آنالیز کنیم
چه‌طوری از داده‌ساختار‌ها بهتر استفاده کنیم و در هر موقعیت از کدامشان استفاده کنیم
برنامه نویسی OO و Functional، چطور از هر کدوم در موقعیت مخصوص به خودش استفاده کنیم.
هندل‌کردن ارورها و لاگ و دیباگ
مسائل Code Formatting و Linting
تست‌کردن کد
دیزاین و ریفکتور، چطوری پروژه‌مون رو ساختاردهی کنیم و از یک نوتبوک به یک اسکرپیت برسیم
داکیومنتیشن و این که چگونه کدمون رو برای بقیه قابل خوندن و فهمیدن کنیم
به اشتراک گذاری کد و چیزایی مثل Version Control و Dependency
درست کردن API
دپلوی‌کردن و آشنایی با ابزارهای اتومات نظیر CICD
امنیت و ریسک‌ها و خطراتی که می‌تونن تهدید کنند
مهارت‌های توسعه نرم‌افزار و یک سری مفاهیم پیشرفته‌تر از جمله این ۱۵ فصل کتاب هستند. من این کتاب رو چند وقت پیش خوندم و ضمن لذت‌بردن نوع نگاهم به بعضی مسائل رو هم تغییر داد. بعد از چند وقت اما حس کردم که برای بهتر ملکه ذهن شدنم نیاز دارم تا مطالبش رو توضیح بدم و جایی برای خودم دوباره بنویسم. از همین رو در ادامه انشالله هر از چندگاهی فصلی از این کتاب رو در موردش به صورت خلاصه و اجمالی پست رفته ‌‌میشه.

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

موضوع، راجع‌به بروز رسانی نسخه‌ی PostgresSQL از ۱۱ به ۱۶‌ه. علاوه بر نقل تجربه‌شون از شیوه‌ و چالش‌های انجام این عملیات که به‌نظرم بسیار دونستنش با ارزشه، به تفصیل به معرفی ابزار و روش‌های انجام این کار و مزایا و معایب هر کدوم از جنبه‌های مختلف پرداخته.

https://techblog.torob.com/postgresql-upgrade-from-11-to-16-torob-experience-v62efb53gn6h