SQL Cheatsheet

〰️〰️〰️〰️〰️〰️
© | @microfrontend_ir

در قسمت یازدهم از آموزش برنامه نویسی به زبان گو به بررسی روند و مراحل Go Compiler پرداختیم.


Link: https://youtu.be/WkKGAhD9DRY

PlayList: https://www.youtube.com/playlist?list=PLJ9zDGwhhsBx6qqziDa4PoWUlKBw4rlBO

〰️〰️〰️〰️〰️〰️
© | @microfrontend_ir

گزارش "Future of Jobs Report 2025" از World Economic Forum درباره آینده مشاغل در سال 2030

این گزارش 300 صفحه‌ای و طولانیه، ولی نکات مهمش رو می‌تونید تو ویدیو 1 دقیقه‌ای زیر ببینید.

@reza_jafari_ai

خلاصه نکات Future of Jobs Report 2025

@reza_jafari_ai

هفته نامه Golang Nugget رو اگه دوست داشتید دنبال کنید.
منابع خوبی رو معرفی میکنه
این یه نمونه ش هست

https://golangnugget.com/p/go-concurrency-upgrade-strategies-memory-management-january-6-2024

این خبرنامه رو آقا لیام عزیز مدیریت میکنه
https://x.com/liammanesh


@gocasts

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


〰️〰️〰️〰️〰️〰️
© | @microfrontend_ir

در اواخر دهه ۱۹۶۰، دانشمندان کامپیوتر در آزمایشگاه‌های بل، دنیس ریچی و کن تامپسون، کار بر روی پروژه‌ای را آغاز کردند که از یک سیستم‌عامل به نام Multics الهام گرفته شده بود. این سیستم‌عامل نتیجه همکاری مشترک MIT، شرکت جنرال الکتریک (GE) و آزمایشگاه‌های بل بود. ویکتور ویسوتسکی، میزبان و راوی این فیلم، نیز در پروژه Multics فعالیت داشته است. ریچی و تامپسون که برخی مشکلات این سیستم‌عامل را شناسایی کرده بودند، تصمیم گرفتند یک سیستم انعطاف‌پذیرتر، کاربردی‌تر و قابل حمل‌تر برای برنامه‌نویسان ایجاد کنند.

آنچه در مورد رشد UNIX شگفت‌انگیز است، مدت‌زمان طولانی‌ای است که این سیستم به‌طور طبیعی و بر اساس نیازهای کاربران و برنامه‌نویسان توسعه یافت. اولین نصب این سیستم در سال ۱۹۷۲ روی یکی از کامپیوترهای شعبه NY Telephone انجام شد. این پیشرفت هم‌زمان با تکامل زبان برنامه‌نویسی C بود که طراحی آن عمدتاً توسط دنیس ریچی صورت گرفت.

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

فیلم "The UNIX System: Making Computers More Productive" یکی از دو مستندی است که آزمایشگاه‌های بل در سال ۱۹۸۲ درباره اهمیت، تأثیر و قابلیت استفاده از UNIX تولید کرد. حتی ۱۰ سال پس از اولین نصب این سیستم، این فیلم همچنان به‌عنوان مقدمه‌ای بر UNIX محسوب می‌شد. فیلم دیگر، "The UNIX System: Making Computers Easier to Use" تقریباً مشابه همین فیلم اما کمی کوتاه‌تر بود. فیلم اول بیشتر برای توسعه‌دهندگان نرم‌افزار و دانشجویان علوم کامپیوتر تهیه شده بود، درحالی‌که فیلم دوم بیشتر بر برنامه‌نویسان تمرکز داشت.

در این مستند، مصاحبه‌هایی با توسعه‌دهندگان اصلی مانند ریچی، تامپسون، برایان کرنیگان و بسیاری دیگر انجام شده است.

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

تصاویر این مستند با همکاری آرشیو و مرکز تاریخ AT&T در وارن، نیوجرسی ارائه شده است.

Link: https://www.youtube.com/watch?v=tc4ROCJYbm0

〰️〰️〰️〰️〰️〰️
© | @microfrontend_ir

یکی از نوستالژیک‌ترین تکنولوژی‌ها برای من انگولار است. لحظه لحظه مستند تاریخچه انگولار برام جذاب و دلنشین بود!

«انگولار؛ از یک آزمایش داخلی تا بازگشتی شگفت‌انگیز
انگولارجی‌اس (AngularJS) در ابتدا به‌عنوان یک آزمایش داخلی در گوگل متولد شد و حتی توسط تیم‌های جیمیل و گوگل مپس چندان جدی گرفته نشد. اما خیلی زود به یکی از محبوب‌ترین فریمورک‌های جاوااسکریپت تبدیل شد. بااین‌حال، زمانی که فشارهای داخلی تیم را به سمت بازنگری اساسی در این فریمورک سوق داد، جامعه توسعه‌دهندگان احساس کردند که کنار گذاشته شده‌اند. آنچه در پی آمد، سال‌ها تلاش برای بازگرداندن انگولار به دوران اوج خود، بدون ایجاد یک شکست دیگر در اکوسیستم بود.
انگولار که زمانی مرده و دفن‌شده به نظر می‌رسید، اکنون دوباره بر سر زبان‌ها افتاده و در حال گسترش مرزهای جاوااسکریپت است. این فریمورک نه‌تنها جایگاه خود را در گوگل تثبیت کرده، بلکه به یکی از مهم‌ترین ابزارهای توسعه وب تبدیل شده است.
از انگولار ۲ تا آیوی (Ivy)، از سیگنال‌ها (Signals) تا همگرایی با ویز (Wiz) و همه تحولات بین این مسیر، داستان تکامل انگولار را با حضور چهره‌هایی همچون میشکو هوری (Miško Hevery)، ایگور مینار (Igor Minar)، برد گرین (Brad Green)، مینکو گچف (Minko Gechev)، سارا درزنر (Sarah Drasner)، الکس ریکابا (Alex Rickabaugh)، ادی عثمانی (Addy Osmani)، رایان کارنیتو (Ryan Carniato) و سیمونا کوتین (Simona Cotin) مرور خواهیم کرد.»

Link: https://youtu.be/cRC9DlH45lA?si=pUsnYUyddTnzqhfp

〰️〰️〰️〰️〰️〰️
© | @microfrontend_ir

در سال 1965، تونی هور، یکی از پیشگامان علوم کامپیوتر، مفهوم Null Reference را معرفی کرد. چندین دهه بعد، او از این تصمیم به عنوان "یک اشتباه یک میلیارد دلاری" یاد کرد، چرا که Null Reference منبعی برای تعداد بی‌شماری از باگ‌ها، کرش‌ها و آسیب‌پذیری‌های امنیتی در نرم‌افزارها شده است.

https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/

〰️〰️〰️〰️〰️〰️
© | @microfrontend_ir

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

زنده باشید
بژین

معرفی کتاب: A Philosophy of Software Design

نویسنده John Ousterhout استاد دانشگاه استنفورد و طراح سیستم‌های واقعی در مقیاس بالا و خالق زبان TCL

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

طراحی نرم‌افزار یعنی مدیریت پیچیدگی

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

- پیچیدگی مفهومی (نه صرفاً تعداد خطوط) مهم‌ترین عاملی است که کیفیت نرم‌افزار را تهدید می‌کند.

- اولین راه‌حلی که به ذهن می‌رسد معمولاً بهترین نیست. بازبینی و بازطراحی، بخش طبیعی فرآیند مهندسی است.

- ماژول‌های خوب آن‌هایی هستند که پشت یک رابط ساده، جزئیات زیادی را پنهان می‌کنند — و این باعث کاهش بار ذهنی می‌شود.

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

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

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

• منابع بهصورت انحصاری توسط یک واحد اجرایی نگهداری میشوند.
• یک واحد اجرایی منبعی را در اختیار دارد و منتظر منبع دیگری است.
• منابع نمیتوانند از یک واحد اجرایی گرفته شوند، مگر اینکه خودش آزاد کند.
• مجموعه ای از واحدهای اجرایی وجود دارد که هر کدام منتظر منبعی هستند که در اختیار دیگری است.

اگر حتی یکی از این چهار شرط شکسته شود، سیستم از deadlock در امان خواهد بود.


مثال ساده
فرض کنید ترد الف و ترد ب داریم:
الف ابتدا ریسورس اول را لاک می‌کند و سپس می‌خواهد ریسورس دوم را لاک کند.
هم‌زمان ترد ب ریسورس دوم را لاک کرده و منتظر ریسورس اول است.
در این حالت، هیچ‌کدام نمی‌توانند ادامه دهند. به این وضعیت Deadlock می‌گوییم

راهکارهای جلوگیری از Deadlock
۱. ترتیب یکسان در دسترسی به منابع (Lock Ordering)

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

۲. استفاده از تایم‌اوت یا تلاش محدود برای گرفتن قفل (Timed Locking / Try-Lock)
در بسیاری از کتابخانه‌های کانکارنسی ، امکان تلاش برای گرفتن قفل به‌صورت غیرمسدودکننده یا با تایم‌اوت وجود دارد. اگر قفل گرفته نشد، می‌توان تصمیم گرفت که عقب‌نشینی کرده یا مسیر جایگزین طی شود.

۳. پیشگیری از شرط Hold and Wait
با طراحی مکانیزم‌هایی که یک واحد اجرایی فقط زمانی منابع را لاک کند که همه‌ی منابع مورد نیازش همزمان در دسترس هستند. این روش پیاده‌سازی دشوارتری دارد ولی مؤثر است.

۴. کاهش دانه‌بندی لاک‌ها (Lock Granularity)
کاهش تعداد منابع قفل‌شونده یا ترکیب آن‌ها در یک قفل واحد در شرایطی می‌تواند طراحی را ساده‌تر کند و احتمال بروز Deadlock را کاهش دهد.

۵. استفاده از ابزارهای تحلیل کانکارنسی
ابزارهایی مانند race detectors، lock order analyzers یا ابزارهای مدل‌سازی formal می‌توانند در تشخیص زودهنگام مسیرهای مستعد بن‌بست کمک کنند.

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

〰️〰️〰️〰️〰️〰️
© | @microfrontend_ir

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

این فایل سمپل برای نتیه که دو قانون در فضای کانکارنسی که دوست داشتم.

پ.ن: در حال تدوین یک دوره برنامه نویسی پارالل و کانکارنت در زبان گو و پایتون هستم :)



〰️〰️〰️〰️〰️〰️
© | @microfrontend_ir