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

این ۱۰ پکیج (Nuget Package) عصای دست توسعه‌دهندگان حرفه‌ای هستند:

۱. MediatR
قلب تپنده بسیاری از پروژه‌های مدرن (به خصوص Clean Architecture). این کتابخانه پیاده‌سازی الگوی Mediator و CQRS را بسیار ساده می‌کند و باعث کاهش وابستگی بین اجزای سیستم می‌شود.

۲. xUnit
استانداردترین فریم‌ورک برای نوشتن Unit Test در دات‌نت. سبک، مدرن و توسعه‌پذیر است و مایکروسافت هم برای پروژه‌های خودش از آن استفاده می‌کند.

۳. Moq
وقتی تست می‌نویسید، نیاز دارید وابستگی‌ها (مثل دیتابیس) را شبیه‌سازی کنید. Moq محبوب‌ترین ابزار برای ساختن این اشیای مصنوعی (Mock Objects) در تست‌هاست.

۴. Refit
تبدیل اینترفیس‌های C# به HTTP Client! با این کتابخانه دیگر نیازی به نوشتن کدهای تکراری HttpClient ندارید؛ فقط اینترفیس تعریف کنید، Refit بقیه کار را انجام می‌دهد.

۵. MassTransit
اگر سمت میکروسرویس یا رویدادها (Events) می‌روید، این ابزار ضروری است. مدیریت ارتباط با Message Brokerها (مثل RabbitMQ و Kafka) را به شکلی انتزاعی و قدرتمند انجام می‌دهد.

۶. Bogus
داده‌های تستی واقعی نیاز دارید؟ Bogus می‌تواند هزاران رکورد داده جعلی اما منطقی (نام، آدرس، ایمیل و...) برای تست کردن دیتابیس یا UI تولید کند.

۷. StackExchange.Redis
پروژه‌ای نیست که بزرگ شود و به Caching نیاز نداشته باشد. این کتابخانه، کلاینت استاندارد و با پرفورمنس بالا برای کار با Redis در دات‌نت است.

۸. Quartz .NET
یک سیستم زمان‌بندی (Scheduling) بسیار دقیق و قدیمی. اگر نیازهای زمان‌بندی پیچیده‌ای دارید (مثل Cron Jobهای خاص) که فراتر از توانایی Hangfire است، Quartz انتخاب اول است.

۹. OpenTelemetry
استاندارد جدید برای مانیتورینگ و Trace کردن درخواست‌ها در سیستم‌های توزیع شده. به شما نشان می‌دهد یک درخواست دقیقا کجا کند شده یا به خطا خورده است.

۱۰. Humanizer
جزئیات کوچک اما مهم! این کتابخانه داده‌های کامپیوتری را به زبان انسان تبدیل می‌کند. (مثلاً تاریخ 2023-10-01 را به "2 days ago" یا PascalCase را به "Pascal Case" تبدیل می‌کند).

ترجمه فارسی The Pragmatic Programmer

این کتاب فقط درباره نوشتن کد نیست؛ درباره ساختن ذهنیت یک توسعه‌دهنده حرفه‌ایه

مسئولیت‌پذیری، تصمیم‌گیری بهتر، و نوشتن کدی که هم قابل اعتماد باشه هم قابل نگهداری، حتی وقتی پروژه بزرگ و تیم شلوغ می‌شه.
با گذشت سال‌ها هنوز هم یکی از بهترین منابع رشد شغلیه؛ از جونیور تا سنیور.


https://github.com/hheydarian/the-pragmatic-programmer-parsion

فصل هفتم - الگوهای کارآموزی

نتیجه‌گیری (پایان یا آغاز؟)

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

ویولن‌های استرادیواری ۳۰۰ سال است که بی‌رقیب مانده‌اند. چرا؟ چون او نتوانست نبوغ خود را فرموله کند و به شاگردانش یاد دهد. با مرگ او، کارگاهش هم مُرد.

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

۱. استادی یعنی انتقال مهارت:
نبوغ شخصی کافی نیست. سِمل‌وایس (پزشکی که فهمید شستن دست‌ها جان مادران را نجات می‌دهد) یک نابغه بود، اما یک نابغه‌ی شکست‌خورده. چون نتوانست دیگران را قانع کند. او دیوانه شد و مُرد، و ۲۰ سال طول کشید تا دنیا حرفش را بفهمد.
استاد نرم‌افزار کسی نیست که کد خارق‌العاده می‌زند؛ کسی است که می‌تواند آن مهارت خارق‌العاده را به دیگران هم یاد بدهد.

۲. خطر توهم مهارت:
بیشتر برنامه‌نویسان فکر می‌کنند بالاتر از میانگین هستند. این اثر "دنینگ-کروگر" است: ما آنقدر نمی‌دانیم که حتی بفهمیم چقدر نمی‌دانیم.
استادی یعنی درک اینکه مقیاس مهارت از ۱ تا ۱۰ نیست؛ از ۱ تا ۱۰۰ است و ما شاید تازه به ۹ رسیده باشیم.

۳. هیچ‌کس خودش را استاد نمی‌نامد:
اگر کسی گفت "من استاد هستم"، به او شک کنید. استادی یک برچسب است که دیگران (آن هم دیگر استادان) باید به تو بدهند.
مدرک واقعی استادی، کیفیت کار شاگردان توست. اگر شاگردانت از تو بهتر شدند، یعنی تو استادی.

۴. هنوز استادان واقعی نداریم:
نویسندگان کتاب صادقانه می‌گویند: ما خودمان هنوز استاد نیستیم. ما مسافریم.
شاید هنوز در تاریخ نرم‌افزار، استادی در تراز میکل‌آنژ یا استرادیواری ظهور نکرده باشد. اما این یک خبر بد نیست؛ این یک دعوت‌نامه است.
شاید نسل بعدی کارآموزان (شما) همان کسانی باشید که می‌گویید:
استادان نرم‌افزار وجود نداشتند... تا اینکه ما آمدیم.

این کتاب تمام شد، اما مسیر The Long Road تازه شروع شده است.

کدنویسی شغل نیست؛ یک مسیر طولانی است

دانشگاه و بوت‌کمپ‌ها به ما سینتکس یاد می‌دهند، اما کسی به ما یاد نمی‌دهد چطور در این اقیانوس بی‌انتها غرق نشویم، چطور رشد کنیم و چطور از یک کدنویس معمولی به یک استاد نرم‌افزار تبدیل شویم.
کتاب Apprenticeship Patterns (الگوهای شاگردی) دقیقاً همان حلقه گمشده است.
این کتاب درباره جاوا یا پایتون نیست؛ درباره تو است. درباره مسیر شغلی‌ات، طرز تفکرت و عادات روزانه‌ای که تفاوت میان یک کارمند خسته و یک مهندس خلاق را رقم می‌زند.
من در هفته‌های گذشته، عصاره‌ی این کتاب ارزشمند را فصل‌ به‌ فصل خلاصه کردم تا راهنمایی باشد برای تمام کسانی که نمی‌خواهند درجا بزنند.
اگر احساس می‌کنید رشدتان متوقف شده، یا اگر تازه اول راه هستید و نقشه راه می‌خواهید، این مجموعه پست‌ها برای شماست.
- دسترسی به خلاصه تمام فصل‌ها

- فصل اول: الگوهای کارآموزی (چرا باید ذهنیت شاگردی داشته باشیم؟)

- فصل دوم: خالی کردن فنجان (چگونه غرور دانایی مانع یادگیری می‌شود؟)

- فصل سوم: پیمودن راه طولانی (چرا نباید عجله کرد و چگونه در مسیر بمانیم؟)

- فصل چهارم: ارزیابی دقیق خود (چرا باید همیشه بدترین عضو تیم باشیم؟)

- فصل پنجم: یادگیری همیشگی (تفاوت کار کردن و تمرین کردن؛ اسباب‌بازی‌های شکستنی)

- فصل ششم: ساخت برنامه درسی خود (چگونه منتظر دیگران نمانیم و مسیر یادگیری خودمان را بسازیم؟)

- فصل هفتم: نتیجه‌گیری (آیا استادان نرم‌افزار وجود دارند؟)

۵ اشتباه رایج در نوشتن رزومه که باعث رد شدن در نقش‌های بین‌المللی می‌شود

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

این ۵ خطا، بیشتر از هر چیز، باعث رد شدن رزومه ها میشود:

❌ ۱) نوشتن وظایف شغلی به جای نتایج
✔️ کارفرما دنبال اثر است، نه فعالیت.
❗ بهجای:
“Worked on Python APIs”
✔️ بنویس:
“Reduced API latency by 34% through refactoring Python microservices.”

❌ ۲) نداشتن مهارت‌های کلیدی همان نقش
سیستم‌های ATS دقیقاً دنبال همان ۵–۸ Skill اصلی هستند.
✔️ مهارت ها باید با Job Description همراستا باشند نه پراکنده.

❌ ۳) جمله‌های طولانی، بدون اعداد
اعداد = واقعیت + تاثیر
✔️ “Improved ETL throughput by 45%”
✔️ “Cut cloud cost by 27%”

❌ ۴) نبود بخش Tech Stack کاربردی
کارفرما باید در ۵ ثانیه متوجه شود با چه ابزارهایی کار کردهاید.
✔️ “Python, FastAPI, Airflow, AWS, Docker, PostgreSQL, BigQuery”

❌ ۵) رزومه ی طولانی بدون ساختار
یک رزومه موفق برای نقشهای بین‌المللی:
دو صفحه
بخش بندی حرفه‌ای
Bullet Points
مثال های عدددار

🔗 LinkedIn

اگر کدهاتون هنوز پر از if و else هست، دارید به سیشارپ مدرن خیانت میکنید! 🔪🩸

بیایید رو راست باشیم؛ نیمی از کدهایی که ما روزانه مینویسیم، فقط چک کردن شرایط هستن.
( عددش مثبته؟ نوعش درسته؟ وضعیتش فعاله؟ Null هست؟)
نتیجه؟ ده‌ها خط کد اسپاگتی با ifهای تو در تو که خوندنش عذاب آوره. 🍝
اما Pattern Matching در نسخههای جدید سی شارپ فقط یک سینتکس قشنگ نیست؛ یک تغییر پارادایم (Paradigm Shift) برای نوشتن کدهای Declarative (توصیفی) به جای Imperative (دستوری) هست.

چرا باید همین امروز استایل کدنویسی تون رو عوض کنید؟
۱. خداحافظی با Cast کردنهای دستی (Type Pattern)
دیگه لازم نیست بنویسید:
if (obj != null && obj is Employee) { var emp = (Employee)obj; ... }

خیلی شیک بنویسید:
if (obj is Employee emp) { ... }

۲. شرط های خوانا مثل زبان انسان (Logical Patterns)
به جای عملگرهای ریاضی گیج کننده، با کامپیوتر حرف بزنید:
❌ if (number > 0 && number < 10)
✅ if (number is > 0 and < 10)

۳. قدرت نمایی در Switch (Switch Expressions)
این قابلیت، قاتلِ case و break های قدیمیه! شما میتونید ۱۰ خط switch قدیمی رو تبدیل کنید به یک خط کد که مستقیماً مقدار برمیگردونه. تمیز، کوتاه و بدون باگ.

۴. جراحی دقیق آبجکت ها (Property Pattern)
میخواید چک کنید که آیا کاربر فعاله و اهل تهرانه؟
if (user is { IsActive: true, City: "Tehran" })
بدون نیاز به نوشتن user.IsActive && user .City == ...

💡 نکته حرفه‌ای:
کد نویسی با Pattern Matching فقط خلاصه‌نویسی نیست؛ بلکه باعث میشه نیت کد شما واضح‌تر بشه. وقتی کد رو میخونید، درگیر چطوری انجام دادن نمیشید، بلکه چی بودن رو میبینید.
❓ صادقانه بگید: چند درصد از کدهای پروژه تون هنوز به سبک C# 5.0 و پر از If/Else نوشته میشه؟

اعتراف کنید! هنوز دارید با as کد مینویسید و منتظر NullReferenceException هستید؟ 💣

بیایید درباره یکی از شایع‌ترین بوهای بد کد (Code Smell) در سی شارپ حرف بزنیم: Type Checking و Casting.
خیلی از ما هنوز به سبک C# 2.0 کد مینویسیم. اما واقعیت اینه که استفاده نادرست از is و as و Castهای مستقیم، مثل مین گذاری توی کدبیس شماست!
👇 بیایید این ۴ روش رو کالبد شکافی کنیم:

۱. روش خطرناک (Direct Cast):
(Employee)obj
این یعنی: من مطمئنم این آبجکت از نوع Employee هست، اگه نبود برنامه رو بترکون! 💥
نتیجه: اگر اشتباه کرده باشید، یک InvalidCastException زیبا در زمان اجرا میگیرید.
✅ کاربرد: فقط و فقط وقتی ۱۰۰٪ مطمئنید.

۲. روش ترسو (The as operator):
var emp = obj as Employee;
این یعنی: سعی کن تبدیلش کنی، اگه نشد، null برگردون.
مشکل اینجاست که خیلی‌ها بعدش یادشون میره چک کنن که نتیجه null شده یا نه! و چند خط پایین‌تر... بوم! NullReferenceException. ❌

۳. روش قدیمی (The old is):
if (obj is Employee) { ... }
امن هست، ولی کُد رو زشت و تکراری میکنه. اول چک میکنی، بعد دوباره داخل if مجبور Cast کنی. چرا کار تکراری؟

🔥 ۴. روش مدرن و حرفه‌ای (Pattern Matching is):
اینجاست که باید سبک کدنویسی تون رو عوض کنید!
از C# 7.0 به بعد، اپراتور is قدرت Pattern Matching پیدا کرده. همزمان هم چک میکنه و هم Cast، بدون خطر:

if (obj is Employee emp)
{
Console.WriteLine($"Hello {emp.Name}");
}

✅ مزایا:
اتمیک: چک و کست در یک حرکت.
امن: متغیر emp فقط داخل بلاک معتبره و نال نیست.
خوانا: خداحافظی با کدهای تکراری.
💡 خلاصه کلام برای مهندسین مدرن:
دور Cast مستقیم (T)x رو خط بکشید (مگر اینکه عاشق Exception هستید).
از as فقط زمانی استفاده کنید که null بودن براتون یک نتیجه معتبره، نه خطا.
برای ۹۹٪ موارد، Pattern Matching بهترین دوست شماست.

❓ شما هنوز کجا از as استفاده میکنید؟ تو کامنت ها بنویسید!

ساخت استارتاپ، خروج موفق و شروع سرمایه گذاری - پارسا غفاری

#ویدئو_کدنویس
🔗 YouTube

#استخدام

[email protected]

تفاوت datetime و datetime2 در SQL Server

اگر هنوز در پروژه های جدید از datetime استفاده میکنی، این پست رو از دست نده 👇

در SQL Server دو نوع داده ی پرکاربرد برای تاریخ و زمان داریم:
datetime و datetime2
اما این دو اصلاً معادل هم نیستند

⏱ دقت (Precision)
- نوع datetime دقت حدود 3.33 میلی ثانیه دارد و زمان ها گرد میشوند
- نوع datetime2 دقت تا 100 نانوثانیه و کاملاً دقیق

📌 برای لاگ ها، پرداخت ها، رویدادها و سیستم های حساس، این تفاوت حیاتی است

📆 بازهی تاریخ

- نوع datetime از سال 1753
- نوع datetime2 از سال 0001

اگر با داده های تاریخی، مهاجرت داده یا محاسبات خاص سر و کار دارید، datetime2 امن تر است

💾 حجم ذخیره‌سازی

- نوع datetime همیشه 8 بایت
- نوع datetime2 بین 6 تا 8 بایت (بسته به دقت)

➡️ یعنی حتی ممکن است کم حجم تر هم باشد

📐 استاندارد و آینده نگری

- نوع datetime یک نوع قدیمی و غیر استاندارد است
- نوع datetime2 مطابق ISO 8601 طراحی شده

مایکروسافت برای پروژه های جدید استفاده از datetime2 را توصیه میکند

⚙️ سازگاری با .NET و EF Core

در EF Core به صورت پیشفرض DateTime را به datetime2 نگاشت میکند.

استفاده از datetime میتواند باعث:
- خطاهای مقایسه
- مشکلات Sort
- لاگ های نادقیق شود

🧠 جمع‌بندی
اگر در حال طراحی دیتابیس جدید هستی:
نوع datetime2(7) انتخاب استاندارد، دقیق و حرفه ای است
نوع datetime فقط برای پروژه های قدیمی قابل توجه است، نه سیستم های مدرن

🔗 LinkedIn

اگر کسب و کار دارید، تا دیر نشده ( البته کمی شده ) ، 20 مورد زیر را هزار بار چک کنید

1- اگر روی وب نیستید، دیگر حتی جای جبران مافات هم نیست ، جمعش کنید
2- اگر روی وب هستید و Responsive و Mobile Support نیستید ، سریعا فکری بکنید
3- اگر تم دارک ندارید، سریعا فکری بکنید
4- اگر Chat bot ندارید ، سریعا فکری بکنید
5- اگر کسب و کار شما در صفحات مجازی هویت درست و حسابی ندارد، به نظرم جمع کنید ، ولی خوب شاااااید هنوز امیدی باشد ، زودتر اقدام کنید
6- اگر بخش رضایت مشتریان و امکان ایجاد رضایت مندی کامل برای مشتری ندارید، سریعا فکری بکنید
7- اگر CRM ندارید، جمع کنید بروید خانه
8- اگر در واتزآپ و اینطور آشغالها کسب و کار میکنید، جمع کنید
9- اگر کالا می فروشید و سیستم انبار ندارید، جمع کنید بروید
10 - اگر نمی توانید به شکلی اداره کنید که پرسنل بتوانند خارج از دفتر کار هم ساپورت و فروش انجام بدهند ، جمع کنید اصلا خانه هم نروید ، شما کلا از دست رفته اید
11- اگر با زدن یک دکمه نمی توانید سابقه و تحرکات یک مشتری را ببینید، یا با رفتن یک پرسنل ، امکان Assign کردن هر چه تا الان انجام داده به دیگری به صورت سیستمی ندارید، جمع کنید، شما شانسی زنده هستید
12- اگر رسید و دیگر اسناد را برای مشتری به صورت اتوماتیک ایمیل نمی کنید، شما شانسی شانسی هنوز در بازار حضور دارید
13- اگر با زدن یک دکمه مشخص نمی شود بابت ارائه یک سرویس یا فروش یک محصول چقدر هزینه شده و چقدر سود کرده اید ، شما کلا شانسی هستید
14- اگر هنوز AI وارد سیستم کاری شما نشده است، زودتر فکری بکنید
15 - اگر هنوز نمی دانید چطوری پرسنل را با AI جایگزین کنید ( لازم نیست انجامش بدهید ، فقط بهش فکر شده باشد ) ، شما مشخص نیست بکجا خواهید رفت
16- اگر سرعت انجام عملیاتهای داخلی خود را با رقبا Benchmark نکرده اید ، در سال 2026 هزینه ها برای شما عجیب خواهد شد
17- اگر برند و لوگو و رنگ مشخصی ندارید ، به زودی فراموش خواهید شد
18- اگر سرعت بخشهای مرتبط با IT در سیستم کاری و کسب و کار شما کند و قدیمی است ، مشتری معطل شما نخواهد ماند ، میره TAB بعدی را باز میکند و به سراغ دیگران می رود
19- قیمت سرویسهای شما تا وقتی خیلی برای مشتری دردآور نشود، زیاد برای آنها مهم نیست ، کار خوب تحویل بدهید، پول زیادتر هم بگیرید، مهم نیست
20 - پرسنل راضی نباشند، مشتری هم راضی نخواهد بود

🔗 LinkedIn

بیشتر مهندسان نرم‌افزار فکر می‌کنند کدنویسی با هوش مصنوعی آن‌ها را سریع‌تر می‌کند.
اما اشتباه می‌کنند…

کدنویسی با هوش مصنوعی (AI) میزان خروجی را افزایش می‌دهد،اما هم‌زمان تعداد مشکلات را هم بیشتر می‌کند…
بر اساس گزارش CodeRabbit ،
ء Pull Requestهایی که با کمک هوش مصنوعی نوشته شده‌اند، ۱.۷ برابر بیشتر از Pull Requestهای کاملاً انسانی مشکل ایجاد کرده‌اند.
با این حال، کد تولیدشده توسط هوش مصنوعی معمولاً در نگاه اول درست به نظر می‌رسد.
چرا؟

دلیلش این است که هوش مصنوعی برای درستی سطحی کد بهینه‌سازی می‌کند، نه برای درک عمیق از کانتکست پروژه.
به همین خاطر، کدنویسی با AI نه «خوب» است و نه «بد».
بلکه الگوها را تقویت (Amplify) می‌کند — حتی الگوهای اشتباه را.

طبق گزارش CodeRabbit، مهندسان هنگام استفاده از کدنویسی با AI باید روی این موارد تمرکز کنند:

1️⃣ منطق و درستی (Logic & Correctness)
↳ مشکلات منطقی و درستی کد در PRهای مشترک با AI ۷۵٪ بیشتر بوده است.
↳ خطاهای الگوریتمی و منطق کسب‌وکار ۲.۲۵ برابر بیشتر دیده شده‌اند.
↳ ضعف در مدیریت خطا و exceptionها ۲ برابر افزایش داشته است.
↳ ریسک Null Pointer، تنظیمات اشتباه، ترتیب نادرست وابستگی‌ها و خطاهای concurrency همگی افزایش قابل توجهی داشته‌اند.
2️⃣ کیفیت کد و قابلیت نگهداری (Code Quality & Maintainability)
↳ مشکلات خوانایی کد در PRهای AI محور بیش از ۳ برابر بوده است.
↳ ایرادات فرمت‌بندی ۲.۶۶ برابر بیشتر ظاهر شده‌اند.
↳ ناهماهنگی در نام‌گذاری تقریباً ۲ برابر افزایش داشته است.
↳ وجود کدهای بلااستفاده یا تکراری نیز بیشتر شده است.
این مشکلات معمولاً بلافاصله باعث خرابی در محیط production نمی‌شوند،
اما فرآیند review را کند می‌کنند و بدهی فنی را افزایش می‌دهند.
3️⃣ ریسک‌های امنیتی (Security Risks)
↳ یافته‌های امنیتی به‌طور کلی در PRهای AI محور حدود ۱.۵ برابر بیشتر بوده‌اند.
↳ مدیریت نادرست رمز عبور ۲ برابر بیشتر مشاهده شده است.
↳ ارجاعات ناامن، ریسک‌های injection و deserialization ناامن نیز افزایش یافته‌اند.
هیچ‌کدام از این آسیب‌پذیری‌ها جدید نیستند؛
اما با کمک AI بیشتر تکرار می‌شوند.
4️⃣ ناکارآمدی‌های عملکردی (Performance Inefficiencies)
↳ مشکلات مرتبط با performance به‌طور کلی کم بوده‌اند.
↳ اما عملیات I/O بیش از حد، در PRهای نوشته‌شده با AI ۸ برابر بیشتر بوده است.
این موضوع نشان می‌دهد که AI، اگر هدایت نشود، شفافیت کد را به کارایی ترجیح می‌دهد.
5️⃣ حجم کار Review و پراکندگی مشکلات
↳ در صدک ۹۰ام، PRهای AI محور ۲ برابر بیشتر از PRهای انسانی مشکل داشته‌اند.
↳ این موضوع باعث reviewهای شلوغ، کند شدن pipeline و افزایش ریسک defect می‌شود.

🚀 پس چطور می‌توان با خیال راحت مقیاس‌پذیر از AI در کدنویسی استفاده کرد؟
با حذف reviewها نه…
بلکه با قوی‌تر کردن آن‌ها:
↳ ارائه‌ی کانتکست و محدودیت‌های پروژه از همان ابتدا
↳ اعمال فرمت‌بندی، نام‌گذاری و ساختار کد با سیاست‌های CI
↳ اضافه‌کردن گاردهای ایمن برای error handling، nullability و control flow
↳ تعریف پیش‌فرض‌های امنیتی به‌صورت کدنویسی‌شده، نه تکیه بر پیشنهاد AI
↳ استفاده از code reviewهای آگاه به AI برای شناسایی خطاهای مخصوص کد تولیدشده توسط AI


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

🔗 LinkedIn

معماران دنیای دیجیتال: ۲۰ نابغه‌ای که کدنویسی و زندگی ما را برای همیشه تغییر دادند

(قسمت اول: پیشگامان و خالقان زبان‌ها)
اگر امروز می‌توانیم با چند خط کد، دنیایی را خلق کنیم، روی شانه غول‌هایی ایستاده‌ایم که دهه‌ها پیش، غیرممکن‌ها را ممکن کردند.
این سری پست‌ها، ادای احترامیست به ۲۰ نفر از اثرگذارترین ذهن‌های تاریخ علوم کامپیوتر.
در قسمت اول، سراغ ۵ نفری می‌رویم که الفبای ما را ساختند:
۱. دنیس ریچی (Dennis Ritchie) - پدر C و یونیکس
بدون او، احتمالاً دنیای مدرن وجود نداشت! خالق زبان C (پایه اکثر زبان‌های مدرن مثل C++, Java, CSharp) و سیستم‌عامل یونیکس. او به ما یاد داد که سادگی، نهایتِ پیچیدگی است.

۲. گریس هاپر (Grace Hopper) - مادر کامپایلرها
بانوی اول نرم‌افزار که اولین "باگ" واقعی کامپیوتری را ثبت کرد! او اولین کامپایلر دنیا را ساخت و زبان COBOL را توسعه داد. او بود که به کامپیوترها یاد داد زبان انسان (انگلیسی) را بفهمند، نه فقط صفر و یک.

۳. کن تامپسون (Ken Thompson) - خالق B و یونیکس
همکار افسانه‌ای دنیس ریچی. او علاوه بر یونیکس و زبان B، بعدها در گوگل یکی از خالقان زبان Go شد. مردی که رد پایش در همه جا، از سیستم‌عامل‌ها تا زبان‌های مدرن دیده می‌شود.

۴. بیارنه استروستروپ (Bjarne Stroustrup) - خالق C++
کسی که قدرت C را گرفت و به آن "کلاس" داد! او با خلق C++، پایه‌های برنامه‌نویسی شی‌گرا (OOP) را در مقیاس صنعتی محکم کرد. هنوز هم موتورهای بازی‌سازی و سیستم‌های پرفورمنس بالا مدیون او هستند.

۵. جیمز گاسلینگ (James Gosling) - پدر Java
شعارش این بود: "یک بار بنویس، همه جا اجرا کن." او با معماری جاوا و ماشین مجازی (JVM)، رویای پرتابلیت (Portability) واقعی نرم‌افزار را محقق کرد و دنیای وب و اینترپرایز را تسخیر کرد.

در قسمت‌های بعدی:
سراغ خالقان وب، لینوکس و غول‌های دنیای مدرن خواهیم رفت.
❓ به نظر شما جای چه کسی در این لیست ۲۰ نفره قطعاً باید باشد؟ حدس بزنید!

معماران دنیای دیجیتال: ۲۰ نابغه‌ای که کدنویسی را برای همیشه تغییر دادند

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

۶. تیم برنرز-لی (Tim Berners-Lee) - خالق وب WWW
مردی که می‌توانست میلیاردر شود، اما هدیه‌اش را رایگان به دنیا داد. او پروتکل HTTP، زبان HTML و اولین مرورگر وب را ساخت تا دانش بشری بدون مرز به اشتراک گذاشته شود.

۷. لینوس توروالدز (Linus Torvalds) - خالق لینوکس و Git
شاید تاثیرگذارترین برنامه‌نویس زنده جهان! او فقط یک بار دنیا را تغییر نداد، بلکه دو بار:
۱. با خلق هسته لینوکس که امروز اینترنت و اندروید روی آن اجرا می‌شود.
۲. با خلق Git که نحوه همکاری تمام برنامه‌نویسان جهان را متحول کرد.

۸. ریچارد استالمن (Richard Stallman) - پدر نرم‌افزار آزاد gnu
فیلسوف دنیای کد. او کسی بود که گفت "نرم‌افزار باید مثل آزادی بیان باشد، نه مثل آبجو رایگان." با بنیان‌گذاری جنبش GNU و لایسنس GPL، مفهوم Open Source را متولد کرد تا ما امروز بتوانیم کدها را ببینیم و تغییر دهیم.

۹. برندان آیک (Brendan Eich) - خالق JavaScript
کسی که زبان وب را در ۱۰ روز نوشت! شاید خودش هم فکر نمی‌کرد پروژه‌ای که با عجله ساخت، روزی به محبوب‌ترین زبان برنامه‌نویسی دنیا تبدیل شود و از مرورگرها فراتر برود (Node.js).

۱۰. گویدو ون روسوم (Guido van Rossum) - دیکتاتور مهربان Python
او ثابت کرد که کدنویسی می‌تواند لذت‌بخش باشد. با خلق پایتون، زبانی ساخت که خوانایی را در اولویت قرار داد و امروز از هوش مصنوعی تا اتوماسیون، همه جا رد پای اوست.

در قسمت‌های بعدی:
سراغ غول‌های الگوریتم و پیشگامان مدرن خواهیم رفت.
❓ به نظرتون جای خالی استیو جابز یا بیل گیتس توی این لیست هست یا نه؟ (چون اونا بیشتر بیزنس‌ من بودن تا برنامه‌نویس). نظرتون چیه؟

معماران دنیای دیجیتال: ۲۰ نابغه‌ای که کدنویسی را برای همیشه تغییر دادند

(قسمت سوم: خدایان الگوریتم و خالقان هوش مصنوعی)
ما تا اینجا از خالقان C و جاوا و وب گفتیم. اما قبل از اینکه کدی نوشته شود، کسی باید منطق را تعریف می‌کرد.
در این قسمت سراغ ۵ افسانه‌ای می‌رویم که به ماشین‌ها یاد دادند چگونه فکر کنند. کسانی که مرز بین انسان و ماشین را شکستند.

۱۱. آلن تورینگ (Alan Turing) - پدر علم کامپیوتر مدرن
همه چیز با او شروع شد. او نه تنها جنگ جهانی دوم را با شکستن کد انیگما کوتاه کرد، بلکه مدلی را طراحی کرد ماشین تورینگ که هنوز هم اساس کار تمام کامپیوترهای جهان است. او پرسید: "آیا ماشین‌ها می‌توانند فکر کنند؟" و پاسخ ما امروز ChatGPT است!

۱۲. ایدا لاولیس (Ada Lovelace) - نخستین برنامه‌نویس تاریخ
یک قرن قبل از اختراع اولین کامپیوتر، او اولین الگوریتم را نوشت! او دیدگاهی داشت که هیچکس نداشت: "کامپیوترها فقط با اعداد کار نمی‌کنند، آن‌ها می‌توانند موسیقی و هنر خلق کنند." او مادر تمام ما برنامه‌نویس‌هاست.

۱۳. جان مک‌کارتی (John McCarthy) - پدر هوش مصنوعی (AI)
اگر امروز از AI حرف می‌زنیم، مدیون او هستیم. او واژه هوش مصنوعی را ابداع کرد و زبان LISP را ساخت. جالب است بدانید قابلیت Garbage Collection (مدیریت خودکار حافظه) که در زبان‌های مدرن عاشقش هستیم، اختراع اوست!

۱۴. دونالد کانوث (Donald Knuth) - یودایِ دنیای الگوریتم
نویسنده کتاب مقدسِ The Art of Computer Programming. او به ما یاد داد که برنامه‌نویسی فقط کد زدن نیست، بلکه یک هنر است. او کسی است که تحلیل پیچیدگی الگوریتم‌ها (Big O Notation) را وارد دنیای نرم‌افزار کرد.

۱۵. مارگارت همیلتون (Margaret Hamilton) - خالق مهندسی نرم‌افزار
کسی که کدنویسی را از یک تفریح به یک رشته مهندسی تبدیل کرد. کدهای او بود که انسان را روی ماه نشاند (پروژه آپولو ۱۱). او مفهوم نرم‌افزارِ بدون خطا (Fault-Tolerance) را در حساس‌ترین لحظات تاریخ تعریف کرد.

در قسمت آخر (قسمت چهارم):
لیست را با ۵ نفر از غول‌های مدرن و دیتابیس‌ها به پایان می‌رسانیم.
❓ یک سوال چالشی: با توجه به انفجار هوش مصنوعی در سال‌های اخیر، آیا الان "جان مک‌کارتی" مهم‌ترین آدم این لیست نیست؟ نظرتون چیه؟

معماران دنیای دیجیتال: ۲۰ نابغه‌ای که کدنویسی را برای همیشه تغییر دادند

(قسمت آخر: غول‌های دیتابیس و معماران عصر مدرن)
این پایان سفر ۲۰ نفره ماست.
در سه قسمت قبل از خالقان زبان‌ها، وب و هوش مصنوعی گفتیم. اما نرم‌افزار بدون داده هیچ است.
در قسمت آخر سراغ ۵ نابغه‌ای می‌رویم که به ما یاد دادند چطور داده‌ها را ذخیره، مدیریت و معماری کنیم.
۱۶. ادگار اف. کاد (Edgar F. Codd) - پدر دیتابیس‌های رابطه‌ای (RDBMS)
اگر امروز می‌توانید SELECT * FROM Users بزنید، مدیون او هستید! او بود که مدل رابطه‌ای (Relational Model) را در IBM اختراع کرد و هرج‌ومرج داده‌ها را به نظم تبدیل کرد. بدون او، SQL وجود نداشت.

۱۷. مایکل استون‌بریکر (Michael Stonebraker) - معمار دیتابیس‌های مدرن
کسی که فقط به یک دیتابیس راضی نشد! او خالق اصلی PostgreSQL و Ingres است. تاثیر او روی تکنولوژی‌های دیتابیس به قدری عمیق است که جایزه تورینگ را برد. او استاندارد دیتابیس‌های متن‌باز و قدرتمند را تعریف کرد.

۱۸. رابرت سی. مارتین (Uncle Bob) - پدر Clean Code
شاید هیچکس به اندازه عمو باب روی کیفیت کدنویسی روزمره ما تاثیر نگذاشته باشد. او با معرفی اصول SOLID و کتاب Clean Code، به نسل‌های مختلف یاد داد که کدنویسی کافی نیست، باید تمیز کد زد.

۱۹. مارتین فاولر (Martin Fowler) - پیامبر معماری نرم‌افزار
اگر از Microservices، Refactoring یا CI/CD حرف می‌زنیم، یعنی داریم با زبان فاولر صحبت می‌کنیم. او کسی است که پیچیده‌ترین مفاهیم معماری سازمانی را ساده‌سازی کرد و نقشه‌ی راهِ توسعه‌دهندگان سنیور را ترسیم کرد.

۲۰. جف دین (Jeff Dean) - مغز متفکر گوگل و کلاود
افسانه‌ای‌ترین مهندس گوگل. کسی که سیستم‌های BigTable، Spanner و MapReduce را ساخت. بدون او، گوگل نمی‌توانست گوگل باشد! او زیرساخت‌هایی را ساخت که امروز به ما اجازه می‌دهد ترابایت‌ها داده را در کسری از ثانیه پردازش کنیم.

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

۲۰ نابغه‌ای که دنیای ما را ساختند: لیست کامل معماران دنیای دیجیتال

آیا تا به حال فکر کرده‌اید اگر این ۲۰ نفر نبودند، امروز دنیای ما چه شکلی بود؟
احتمالاً نه اینترنتی داشتیم، نه گوشی هوشمندی، و نه هوش مصنوعی‌ای که با آن چت کنیم!

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

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

- دسترسی به تمام قسمت‌ها:

- قسمت اول: پیشگامان و خالقان زبان‌ها
(دنیس ریچی، گریس هاپر، خالقان C++ و جاوا)
🔗 لینک پست اول

- قسمت دوم: خالقان وب و انقلابیون متن‌باز
(تیم برنرز-لی، لینوس توروالدز، خالقان پایتون و جاوا اسکریپت)
🔗 لینک پست دوم

- قسمت سوم: خدایان الگوریتم و خالقان هوش مصنوعی
(آلن تورینگ، ایدا لاولیس، جان مک‌کارتی و مارگارت همیلتون)
🔗 لینک پست سوم

- قسمت چهارم: غول‌های دیتابیس و معماران عصر مدرن
(ادگار کاد، عمو باب، مارتین فاولر و جف دین)
🔗 لینک پست چهارم

چرا شناختن این‌ها مهم است؟
چون برنامه نویس بودن بدون شناختن تاریخچه این رشته، مثل این است که نویسنده باشید اما شکسپیر و حافظ را نشناسید. شناختن ریشه‌ها، دید شما را به آینده باز می‌کند.