NEW BOT Телеграм, страница

tech-afternoon

📔 ساده‌تر شدن اجرای نرم‌افزارهای کوچیک در دات‌نت ۱۰

نسخه پیش‌نمایش ۴ دات‌نت ۱۰ امکانی رو فراهم کرده تا بودن فایل پراجکت و سولوشن هم به راحتی بشه کد سی‌شارپ نوشت. قبلا با استفاده از فایل‌های اسکریپت csx. هم می‌شد این کار رو کرد، ولی امکان جدید، جامع‌تر و ساده‌تره.
کابردش: آموزش، اسکریپت‌های مورد استفاده برای DevOps و...
ابتدای فایل به ذکر :# و بعدش skd یا package چیزهایی رو که قبلا توی فایل csproj مشخص می‌کردیم، اینجا می‌تونیم توی یک فایل قرار بدیم.

مثلا: کد زیر فقط با یه فایل cs کار می‌کنه و چک می‌کنه اگر rabbitmq و postgresql اوکی بودن، ورژن نرم‌افزار رو توی دیتابیس به‌روز می‌کنه و یه وب‌پیچ هم محیا می‌کنه برای مشاهده وضعیت.

#! /usr/bin/dotnet run

#:sdk Microsoft.NET.Sdk.Web
#:package markdig@0.41.*
#:package Npgsql@9.0.*
#:package RabbitMQ.Client@7.1.*


using Markdig;
using Npgsql;
using RabbitMQ.Client;
using System.Reflection;

var rabbitMqHost = Environment.GetEnvironmentVariable("RABBITMQ_CONNECTION_STRING") 
    ?? "amqp://guest:guest@localhost:5672/";
var pgConnStr = Environment.GetEnvironmentVariable("POSTGRES_CONNECTION_STRING") 
    ?? "Host=localhost;Username=postgres;Password=yourpassword;Database=yourdb";

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", async () =>
{
    bool rabbitOk = false;
    try
    {
        var factory = new ConnectionFactory() { Uri = new Uri(rabbitMqHost) };
        using var connection = factory.CreateConnection();
        using var channel = connection.CreateModel();
        rabbitOk = connection.IsOpen && channel.IsOpen;
    }
    catch { rabbitOk = false; }

    bool pgOk = false;
    string errorMsg = "";
    try
    {
        using var conn = new NpgsqlConnection(pgConnStr);
        await conn.OpenAsync();
        pgOk = conn.State == System.Data.ConnectionState.Open;

        var version = Assembly.GetEntryAssembly()?.GetName().Version?.ToString() ?? "unknown";
        var now = DateTime.Now;

        using var cmd = new NpgsqlCommand(
            "INSERT INTO application (checked_at, version, rabbitmq_ok, postgres_ok) VALUES (@date, @ver, @rmq, @pg)", conn);
        cmd.Parameters.AddWithValue("date", now);
        cmd.Parameters.AddWithValue("ver", version);
        cmd.Parameters.AddWithValue("rmq", rabbitOk);
        cmd.Parameters.AddWithValue("pg", pgOk);
        await cmd.ExecuteNonQueryAsync();
    }
    catch (Exception ex)
    {
        errorMsg = ex.Message;
    }


    var content = $"""
    # System Health Check

    - **RabbitMQ:** {(rabbitOk ? "OK" : "FAILED")}
    - **PostgreSQL:** {(pgOk ? "OK" : "FAILED")}
    {(string.IsNullOrWhiteSpace(errorMsg) ? "" : $"\n- **Error:** {errorMsg}")}
    """;

    return Results.Content($"""
        <html>
            <body style="font-family: sans-serif;">
                {Markdown.ToHtml(content)}
            </body>
        </html>
        """, "text/html");
});

app.Run();

Please open Telegram to view this post

VIEW IN TELEGRAM

18👍8❤1

952 viewsAmin Mesbahi, 04:59

tech-afternoon

🎮💡 مقایسه مفهوم ACID و BASE

مقدمه: دو مدل اصلی برای مدیریت تراکنش‌ها وجود داره: ACID و BASE. هر کدوم از این مدل‌ها رویکرد متفاوتی نسبت به «تضمین صحت» و «در دسترس‌پذیری» داده‌ها دارن و انتخاب مناسب بستگی به نیازهای خاص سیستم داره.

💎 مدل ACID: تضمین صحت و یکپارچگی داده‌ها
مدل ACID که مخفف چهار ویژگی Atomicity (اتمی بودن)، Consistency (سازگاری)، Isolation (انزوا) و Durability (دوام) است، از بدیهی‌ترین و ابتدایی‌ترین مفاهیم RDBMSهاست و توی تقریبا همه‌شون دیده می‌شه.

*️⃣مفهوم Atomicity (اتمیک بودن): تراکنش‌ها به صورت یک واحد کامل اجرا می‌شن؛ یا کل عملیات موفق میشه یا هیچ‌کدمم اعمال نمی‌شه. چرا می‌گیم اتمیک؟ چون به زبون عامیانه و ساده، اگر اتم آهن رو فرض کنیم، هر جزء کوچک‌تر از اتم آهن، دیگه آهن نیست! یه چیز دیگه است. وقتی میگیم این ۱۰ عمل باهم میشه تراکنش خرید، حتی ۹ تاش رو هم داشته باشیم، «خرید» نداریم!

*️⃣مفهوم Consistency (سازگاری): تراکنش‌ها داده‌ها رو از یک وضعیت معتبر به وضعیت معتبر دیگه منتقل می‌کنن، بدون نقض قوانین تعریف‌شده.

*️⃣مفهوم Isolation (انزوا): اجرای همزمان تراکنش‌ها به گونه‌ای است که انگار هر کدوم به تنهایی اجرا شده‌ باشن، بدون تأثیر بر همدیگه (البته بستگی به سطح ایزوله کردن داره که مفاهیمی مثل unrepeatable read و phantom read پیش میاد.

*️⃣مفهوم Durability (دوام): پس از تأیید تراکنش، تغییرات به طور دائمی در پایگاه داده ذخیره می‌شون (تضمین می‌شه)، حتی در صورت بروز خطا یا قطع برق.

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

⚡️ مدل BASE: تمرکزش روی دسترس‌پذیری و مقیاس‌پذیریه.
مدل BASE که مخفف Basically Available، Soft state و Eventually consistent است، توی پایگاه‌های داده NoSQL مثل Cassandra و DynamoDB استفاده می‌شه.

*️⃣مفهوم Basically Available (اساساً در دسترس): سیستم همیشه در دسترسه، حتی در صورت بروز خطا یا قطعی شبکه.

*️⃣مفهوم Soft state (وضعیت نرم): وضعیت سیستم ممکنه در طول زمان بدون ورودی‌های جدید تغییر کنه.

*️⃣مفهوم Eventually consistent (در نهایت سازگار): در نهایت، تمام nodeهای سیستم به یک وضعیت سازگار می‌رسن، حتی اگر در کوتاه‌مدت ناسازگاری‌هایی وجود داشته باشه.

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

🧠 نتیجه‌گیری

انتخاب بین ACID و BASE به نیازهای خاص هر سیستم بستگی داره؛ در برخی شرایط، ترکیبی از این دو مدل گزینه مطلوب رو شکل می‌ده، به ویژه توی معماری‌های میکروسرویس که نیاز به انعطاف‌پذیری بیشتری وجود داره و نیاز هر سرویس الزاما با بقیه‌ سرویس‌ها یکی نیست. یعنی مثلا شاید شما دیتای master مالی توی مایکروسرویس مالی رو ACID نیاز داشته باشین، ولی بخشی از داده مالی که توی مایکروسرویس دیگه‌ای جهت ریپورتینگ نگهداری می‌شه رو BASE.

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

Please open Telegram to view this post

VIEW IN TELEGRAM

❤25👍6

897 viewsAmin Mesbahi, 05:59

tech-afternoon

💡 سه خبر از کنفرانس بیلد ۲۰۲۵

1️⃣ تمرکز مایکروسافت روی Blazor
یه نکته مهم توی کنفرانس اخیر بیلد این بود که مایکروسافت اعلام کرد که Blazor رو به‌عنوان بستر اصلی و آینده‌دار برای توسعه رابط کاربری وب توی دات‌نت انتخاب کرده. این تصمیم، تاثیر زیادی روی اکوسیستم NET. خواهد داشت و نشون‌دهنده‌ی تغییراتی توی استراتژی‌های توسعه‌ی وب مایکروسافته. چرا تغییر؟ چون React و React Native همه‌جای مایکروسافت حضور دارن؛ از Teams تا منو استارت ویندوز تا آفیس... کماکان Razor Pages و MVC و... هم توسعه خواهند داشت ولی Blazor فعلا سوگولی است و هم روی پرفرمنسش هم اکوسیستمش داره با تمرکز کار می‌شه.

2️⃣ قابلیت جدید Kestrel یعنی Memory Trim در دات‌نت ۱۰
وب‌سرور اصلی و پیش‌فرض دات‌نت Kestrel (هم توی ویندوز و هم لینوکس) یکی از مشکلات وب‌سرورها توی سرویس‌های بزرگ رو یعنی مدیریت و بهینه‌سازی مصرف رم در بازه‌های زمانی طولانی رو سعی کرده برطرف کنه. تا الان Kestrel امکان مموری‌تریم نداره؛ یعنی وقتی در طول زمان رم مضرفی‌اش زیاد می‌شه، دیگه حافظه آزاد شده رو پس نمی‌ده. اگر حافظه‌ی تخصیص‌یافته به‌موقع آزاد نشه، برنامه دچار "memory bloat" یا حتی OutOfMemory می‌شه.

حالا Memory Trim چیه؟
نسخه‌های جدید Kestrel (هم‌زمان با Net 10)، ویژگی جدید Memory Trim رو خواهد داشت که به شکل دوره‌ای (یا هنگام کاهش بار سرور) حافظه‌ی بلااستفاده‌اش رو به سیستم‌عامل بگردونه. این باعث بهینگی بیشتر پرفرمنس و کاهش هزینه ابری می‌شه.

3️⃣ اضافه‌شدن JSON Patching به System.Text.Json + افزایش پرفرمنسش که سهولت تصمیم برای مهاجرت از Newtonsoft.Json به System.Text.Json رو فراهم می‌کنه.

توضیح تکمیلی:
وقتی NET 9. منتشر شد، Nick Chapsas، از Roth که عنوان شغلیش Principal Product Manager, ASP.NET است، درباره Blazor و استفاده داخلی مایکروسافت ازش پرسید. دو دلیل اصلی برای استفاده کم از Blazor در مایکروسافت، به ویژه برای برنامه‌های عمومی مثل آفیس، ارائه می‌ده که مهمه! یکی از این دلایل تاریخیه، یعنی زمانی که آفیس برای اولین بار React رو پذیرفت، Blazor در دسترس نبود. با این حال، دلیل دیگه روشن‌تره؛ می‌گه Blazor برای حل مشکل توسعه‌دهنده‌های NET. که به دانش عمیق جاوا اسکریپت نیز نیاز دارن، طراحی شده، که "هزینه و بار ناشی از استفاده از چند تکنولوژی (تایپ‌اسکریپت، ری‌اکت، دات‌نت و...) رو کم کنه". پلتفرم NET. برای استفاده روی سرور بهینه شده و Blazor تیم‌ها رو توانمند می‌کنه تا از همون توی مرورگر استفاده کنن. Blazor ارزش افزوده ایجاد می‌کنه، "وقتی نیاز داریم بدون یک تیم جداگانه جاوا اسکریپت front-end، کارهای بیشتری انجام بدیم."

نکته مهم اینه که Roth صریح اعتراف می‌کنه که شرکت‌هایی به اندازه مایکروسافت، در حال حاضر تیم‌های front-end متخصص توی جاوا اسکریپت یا TypeScript دارن که Blazor رو کمتر جذاب می‌کنه.

پی‌نوشت: بیلد امسال و دات‌نت ۱۰ روی بهینگی‌های minimal API هم زیاد پرداخته شد، که به نظر میاد برای پروژه‌های بیشتری می‌تونه جذاب باشه. خصوصا که کامپایل AOT رو پشتیبانی می‌کنه کنه که توی controller-based ها نداریمش.

💬 نکته یا تجربه یا نظری دارید؟

Please open Telegram to view this post

VIEW IN TELEGRAM

YouTube

Microsoft Build 2025 | Satya Nadella Opening Keynote

Join the Microsoft Build 2025 opening keynote, streamed live from Seattle. Follow along as Satya Nadella and other top Microsoft leaders explore new opportunities in the age of AI and set the stage for what’s ahead.

Chapters:
0:00 - Keynote opening
2:50…

👍155

752 viewsAmin Mesbahi, 11:51

tech-afternoon

⛳️ نکاتی در مورد تصمیم‌گیری تکنولوژی

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

1️⃣ چارچوب‌های تصمیم‌گیری معماری یا Architectural Decision-Making Frameworks

۱-۱ چارچوب ATAM (Architecture Tradeoff Analysis Method)
این چارچوب توسط SEI (Software Engineering Institute) در دانشگاه کارنگی ملون توسعه داده‌شده و در مراحل اولیه چرخه حیات توسعه نرم‌افزار وارد می‌شه. فازهای مشخص برای تحلیل نیازمندی‌ها، شناسایی گزینه‌ها و مقایسه trade-offها رو بررسی می‌کنه. و اینکه هر تکنولوژی چطور بر شاخص‌های کیفیت سیستمی، مثل پایداری، مقیاس‌پذیری، امنیت و غیره اثر می‌گذاره.

مراحل ATAM:
- شناسایی اهداف کسب‌وکار و نیازمندی‌های کیفیتی (Quality Attributes)
- لیست‌کردن گزینه‌های تکنولوژیک
- تحلیل سناریوهای کاربردی
- شناسایی trade-offها و ریسک‌ها
- انتخاب گزینه‌ای که بیشترین تطابق را با اهداف و کمترین ریسک را دارد.
توضیح مقدماتی در مورد ATAM
توضیح بیشتر؟ ری‌اکشن: ⚙️

۱-۲ چارچوب ADR (Architecture Decision Records)
یک روش برای مستندسازی تصمیمات تکنولوژیک به شمار میاد و هر تصمیم شامل: زمینه، گزینه‌ها، دلایل انتخاب، تاثیرات مثبت/منفی، و رد گزینه‌های دیگه رو می‌نویسم و افراد تیم می‌خونن یا برای آیندگان به یادگار می‌گذاریم. به تجربه عرض می‌کنم که نوشتن دقیق (و نه سَمبَل‌نویسی، خیلی خیلی به درک و تصمیم بهتر کمک می‌کنه، به شفاف شدن مسئله و نیاز کمک می‌کنه. درست برعکس حرف زدن که جمله سوم نرسیده، نکات جمله اول فراموش می‌شه!) برای تیم کوچک تا خیلی بزرگ می‌تونه کاربرد داشته باشه. مثال‌هایی از اسناد ADR

————————-

⚙️ در مورد ۲ و ۳ در صورت استقبال از بخش اول، در پست‌های بعدی خواهم نوشت.

2️⃣ مدل‌های مقایسه‌ای (Decision Matrix/Weighted Scoring Model)

3️⃣ چارچوب‌های شرکت‌های بزرگ (مثلاً ThoughtWorks Technology Radar، Gartner Magic Quadrant)
—————————

4️⃣

پرسش‌های کلیدی که خوبه پاسخ بدیم و حداکثر تلاشمون رو برای پاسخ دقیق دادن بهشون به کار ببندیم:

🔤آیا تکنولوژی با نیازمندی‌های پروژه و بودجه همخونی داره؟

🔤آیا لیستی از معیارهای مهم (کارایی، هزینه، امنیت، پشتیبانی، یادگیری، بازار کار) داریم؟

🔤تیم چقدر تجربه یا علاقه بهش داره؟ (بر اساس معیار استاندارد و نه حس شخصی)

🔤کامیونیتی و ساپورتش چطور است؟ (کامیونیتی در دسترس و مشابه، از نظر سایز و عمق دانش)

🔤توسعه، نگهداری و مقیاس‌پذیری در بلندمدت چطور خواهد بود؟

🔤امنیت، ریسک vendor lock-in یا پشتیبانی تجاری داره یا نه؟

🔤در صورت اشتباه، راه بازگشت داریم؟

🔤چقدر تحت تاثیر trend و هیجان و علاقه شخصی خواهد بود، چقدر تابع بررسی و تحلیل؟

💬 تجربه و روش مورد استفاده شما چیه؟

Please open Telegram to view this post

VIEW IN TELEGRAM

17👍2

837 viewsAmin Mesbahi, 10:45

tech-afternoon

🔌 توسعه محصول و اهمیت استفاده از Feature Toggle
(یا Feature Flag یا Release Toggle)

تا حالا شده یه امکان جدید توی نرم‌افزار رو بخواهید فقط برای عده مشخصی از مخاطبین فعال کنید؟ یکی دو تاش رو شاید بشه با if ولو کثیف پیاده کرد، ولی اگر زیاد شد چی؟ اگر خواستید مثلا از یه جا مدیریت کنید که مثلا ۱۰ درصد از کاربرهای خارج از ایران به جای متد الف، از متد ب استفاده کنند. این قابلیت رو که نرم‌افزارها قابلیت‌هایی رو توی خودشون دارن که فقط برای برخی افراد یا در صورت تمایل اون‌ها فعال می‌شه، این روزها خیلی جاها می‌شه دید، از پلتفرم‌های وب، تا سوییچ‌های گوگل کروم تا تلگرام... (یک نسخه ولی قابلیت‌ها یا رفتارهای متفاوت بسته به شرایط دلخواه ما)

ارائه‌ی تدریجی ویژگی‌های جدید (features) یکی از پایه‌های Continuous Delivery و توسعه چابک محصوله. به‌جای انتشار تغییرات بزرگ و پرریسک، تیم‌ها ترجیح می‌دهن قابلیت‌های جدید رو مرحله‌به‌مرحله منتشر کنن، و یا در محیط واقعی آزمایش کنن، ولی نه برای همه! نهایتا بر اساس بازخورد کاربران بهبود بدن تا آماده عرضه عمومی بشه یا شایدم از چرخه خارج شه. اینجا جاییه که مفهوم Feature Flags یا Feature Toggles وارد می‌شه.

❓مفهوم Feature Toggle چیه؟

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

❓چرا خوبه که از Feature Toggle استفاده کنیم؟

✅ تحویل تدریجی (Progressive Delivery): امکان rollout تدریجی به درصدی از کاربران.

✅ آزمایش A/B: مقایسه‌ی اثربخشی نسخه‌های مختلف از یک قابلیت.

✅ رفع سریع خطا: در صورت وجود خطا، می‌تونیم قابلیت رو بدون rollback نسخه غیرفعال کنیم (حتی از راه دور، یا بدون دخالت).

✅ فعال‌سازی مبتنی بر کاربر یا نقش: قابلیت خاص فقط برای کاربران خاصی فعال باشه (مثلاً کارمندان، beta testerها یا مشتریان ویژه).

✅ آزمایش در محیط production: بدون درگیر کردن همه کاربرها.

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

✨ پلتفرم‌های تخصصی برای مدیریت Feature Toggle

خیلی از سازمان‌ها به‌جای نوشتن سیستم داخلی، از ابزارهای آماده استفاده می‌کنن که قابلیت‌های پیشرفته مثل UI مدیریتی، rollout تدریجی، آنالیتیکس، logging و SDKهای آماده ارائه می‌دهند:

➖پلتفرم LaunchDarkly: ابزار محبوب تجاری
➖پلتفرم Unleash: پروژه‌ی متن‌باز با رابط کاربری قابل قبول.
➖پلتفرم Flagsmith: پلتفرم متن‌باز و SaaS.
➖ پلتفرم Microsoft Feature Management: در پلتفرم Azure App Configuration.
➖ پلتفرم Split.io: با قابلیت‌های تحلیلی قوی.

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

💬 نظر؟ تجربه؟ سوال؟

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

Please open Telegram to view this post

VIEW IN TELEGRAM

LaunchDarkly

LaunchDarkly: Feature Flags, Feature Management, and Experimentation

Maximize the value of every software feature through automation and feature management.

👍236🙏1

1.21K viewsAmin Mesbahi, 04:33

tech-afternoon

📌 تفاوت Strong Consistency و Eventual Consistency در یک نگاه

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

🧱 Strong Consistency (سازگاری قوی)
هر تغییری که انجام بشه، همه باید فوراً ببینن. یعنی وقتی یه کاربر داده‌ای رو آپدیت کرد، تمام کاربران دقیقاً همون مقدار جدید رو ببینن — هیچ تأخیری در دیدن داده‌ی به‌روز وجود نداره.

✅ مناسب برای:

- سیستم‌های مالی یا رزرو که "دوگانگی" براشون قابل قبول نیست
- تراکنش‌های حیاتی مثل خرید سهام، پرداخت آنلاین

مثال ساده:
اگه از ATM پول برداریم، باید فوراً موجودی‌مون در همه جا بروز بشه. وگرنه ممکنه دوباره از یه دستگاه دیگه پول بکشیم!

🌊 Eventual Consistency (سازگاری نهایی)
داده ممکنه در لحظه همه جا یکی نباشه، ولی در نهایت (مثلاً چند ثانیه بعد) همسان می‌شه. این مدل performance بالاتری داره و مقیاس‌پذیرتره.

✅ مناسب برای:

- شبکه‌های اجتماعی
- سیستم‌های کش (Cache)
- فروشگاه‌های بزرگ آنلاین
- توزیع محتوا (CDN)

مثال ساده:
تو اینستاگرام یه پست رو لایک می‌کنی، ولی ممکنه چند ثانیه طول بکشه تا تعداد لایک برای بقیه آپدیت بشه — ولی در نهایت همه یه عدد می‌بینن.

💡 باید واقع‌بین بود، برخی موارد، تیم فنی این موضوع رو از یه آدم غیر فنی می‌پرسه که «قربان» دستور می‌فرمایید کدام گونه‌ی consistency را به خدمت گیریم؟! قربان هم پاسخ می‌ده: ببین مهندس «سامانه» ما خیلی مهمه، قراره میلیان‌ها بلکه میلیاردها کاربر در لحظه داشته باشه. فلذا داده‌ها باید در همه جا یکسان باشه، بلادرنگ، در لحظه! این می‌شه که آخرش نه توزیع‌یافتگی محقق می‌شه، وقتی هم محقق می‌شه با کندی و بدبختی و فلاکت برقرار می‌شه، اگر هم درست برقرار بشه، هزینه‌ی تمام‌شده معقولی نداره!
مثال تجربی و واقعی: سال‌ها پیش (۱۳۸۷) همین چالش دشوار قانع کردن یک سازمان بزرگ برای غیرالزامی بودن strong consistency داشتم، از یک طرف مشکلات عدیده مقیاس‌پذیری و دسترس‌پذیری داشتن، از یه طرف اصرار مکرر بر اینکه ما کارمون حیاتیه و باید راهکار تضمین کنه که داده‌ها همه‌جا در لحظه یکسانه. با هزار اما و اگر، نهایتا راضی به تست شدند که ترکیبی از این دو رو پیاده کنم تا بخشی از سیستم، داده‌ها رو به لحظه داشته باشه، و بخش دیگه‌ای از سیستم بین ۴ تا ۱۰ ثانیه بعد توی ۳۷ نقطه در کشور داده‌ی به‌روز دریافت کنه. بعد از تست و دوره پایلوت، اون ساختار و معماری سال‌ها کار کرد (می‌کنه) و ثابت شد که «به‌روز» یک مفهوم مطلق و جهان‌شمول نیست. در حالیکه اگر قرار بود همه‌جا strong consistency بدم، تفریبا محال ممکن بود که کار انجام شه، یا اگر انجام میشد هزینه پیاده‌سازی و نگهداریش شاید بارها بیشتر بود، در حالیکه ۴ تا ۱۰ ثانیه برای اون نیاز، کاملا قابل قبول بود.

Please open Telegram to view this post

VIEW IN TELEGRAM

👍197

1.88K viewsAmin Mesbahi, 04:30

tech-afternoon

Please open Telegram to view this post

VIEW IN TELEGRAM

❤11

16:38

tech-afternoon

🧬 در مورد Arazzo Specification و کاربردهاش!

کمتر اپلیکیشنی رو می‌شه پیدا کردن که مستقیم یا غیرمستقیم با APIها خصوصا REST مرتبط نباشن. حالا Arazzo Specification یه استاندارد جدید و البته «باز»، از OpenAPI Initiative است که به‌عنوان مکمل OpenAPI Specification برای توصیف جریان کار (workflow) APIها طراحی شده. توسعه‌دهنده/معمار می‌تونه دنباله‌ای از فراخونی‌های API و وابستگی‌هاش رو به‌صورت ساختاریافته و قابل فهم برای انسان (فنی و کسب‌وکاری) و ماشین تعریف کنه.

📜 سابقه و هدف
قبلن، OpenAPI با تمرکز روی توصیف endpointها توسعه داده شده بود. با swagger یا ابزارهای دیگه به راحتی endpointها رو می‌شه بررسی کرد، ولی خیلی از فرایندها، چندین endpoint رو درگیر می‌کنن اما در عمل، حالا چرخه‌ی فراخونی این endpointها به نحوی باید مستند و قابل رویت باشه. چه تیم فنی و چه تیم کسب‌وکاری باید بتونن فرایند فراخونی APIها رو بررسی کنن، که کدوم API اول باید کال بشه و بعد دومی و سومی و الی آخر. برای پاسخ به این نیاز، Arazzo Specification سال ۲۰۲۴ معرفی شد تا بشه جریان‌های کاری، خصوصا پیچیده‌ها رو توصیف و تشریح کرد.

🎯 اهمیت و کاربرد
- مستندسازی API call workflow: توصیف دقیق دنباله‌ی فراخونی APIها برای سناریو خاص.
- تولید خودکار مستندات و SDK: ایجاد مستندات اینتراکتیو و تولید کدهای کلاینت بر اساس جریان‌های کاری تعریف‌شده.
- تسهیل تست‌های end-to-end: تعریف سناریوهای تست پیچیده با استفاده از جریان‌های کاری.
- ادغام با هوش مصنوعی: ارائه ساختار قابل فهم برای مدل‌های زبانی بزرگ (LLMs) برای تعامل با APIها.
- بهبود تجربه توسعه‌دهنده (DX): کاهش نیاز به مستندسازی دستی و افزایش وضوح استفاده از APIها.

🧩 ساختار Arazzo
یک سند Arazzo معمولاً شامل بخش‌های زیره:

بخش arazzo: نسخه مشخصه Arazzo (مثلاً 1.0.1).
بخش info: اطلاعات متادیتا درباره سند.
بخش sourceDenoscriptions: فهرستی از منابع (مثل فایل‌های OpenAPI) که جریان‌های کاری بهشون ارجاع می‌دن.
بخش workflows: تعریف یک یا چند جریان کاری، شامل مراحل، ورودی‌ها، خروجی‌ها و معیارهای موفقیت یا شکست.
بخش components: تعریف مؤلفه‌های قابل استفاده مجدد برای جلوگیری از تکرار.

مثال توی کامنت
لینک مستند رسمی Arazzo Specification
مخزن GitHub Arazzo
مقاله در Swagger Blog

جدی گرفتن رویکرد API First نه تنها کمک بزرگی به توسعه اصولی‌تره، بلکه به تیم/سازمان‌سازی بهتر کمک می‌کنه، همون‌طور که تست نوشتن بخشی از مسیر بلوغ تیم و سازمانه؛ مستندسازی درست و ساختارمند هم بخشی از مسیر بلوغ توسعه‌دهنده، تیم و سازمانه. فایل ورد یا کانفولئنس یا ... ابزار مدیریت مستندات API نیستن!

💬 نظر شما چیه؟!

Please open Telegram to view this post

VIEW IN TELEGRAM

spec.openapis.org

The Arazzo Specification v1.0.1

The Arazzo Specification provides a mechanism that can define sequences of calls and their dependencies to be woven together and expressed in the context of delivering a particular outcome or set of outcomes when dealing with API denoscriptions (such as OpenAPI…

6🤓4👍1

861 viewsAmin Mesbahi, 04:32

tech-afternoon

💡 اگر قرار باشه یکی دو مطلب در باب مسیر شغلی و مهارت‌های لازم، در قالب اشتراک تجربه و پیشنهاد داشته باشیم (فارغ از تکنولوژی و زبان؛ و فقط ذیل نرم‌افزار) سن خودتون در در کدوم گروه بیان می‌کنین؟
(رأی‌گیری ناشناس است)

Anonymous Poll

سن فقط یه عدده و تاثیری نداره

موضوع جذابی نیست

145 voters824 viewsAmin Mesbahi, 13:19

tech-afternoon

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

من ۳ بار رو به خاطر دارم که چنین مشورتی رو گرفته باشم (۱۶، ۱۹ و ۲۱ سالگی) و چیزی که می‌نویسم آمیزه‌ای از تجربه و یادگیری خودمه، لذا ذیل درس و پند و پیشنهاد بیانش نمی‌کنم؛ بلکه یک روایته، فارغ از اینکه چقدر مفیده یا گستره‌ی دامنه‌اش چقدر می‌تونه باشه!

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

بخش ۱: فرصت طلایی ۲۰ تا ۳۰ سالگی

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

*️⃣انعطاف‌پذیری ذهنی بالاست؛ تغییر عادات هنوز کم‌هزینه است.
*️⃣مسئولیت‌های زندگی (خانواده، وام، تعهدات شغلی ثابت) معمولاً کمتره و می‌شه ریسک کرد.
*️⃣بازار کار حاضره به «جونیورهای مشتاق» فرصت یادگیری بده.

🧠 مهارت‌های فکری پایه

✅

تفکر الگوریتمی: بهترین سال‌های این مهارت در کودکی است، ولی دهه ۲۰ سالگی سال‌های خوبیه که اگه این مهارت کسب نشه، در سال‌های بعدی محال که نه؛ ولی دشوار می‌شه این مهارت رو در خودمون ایجاد و تقویت کنیم. شکستن مسئله به مراحل کوچک‌تر. توانایی، عادت به نوشتن و بیان راه حل روی کاغذ؛ و نهایتا تفکر انتقادی نسبت به مسایل و راه‌حل‌ها با هدف پیدا کردن بهبودهای احتمالی و البته مقرون‌به‌صرفه.

✅

یادگیری مادام‌العمر: فناوری‌ها زود منقضی می‌شه؛ مهارت اصلی، «یاد گرفتنه» نه «دانسته‌ داشتن».
اینکه یاد بگیریم چجوری یاد بگیریم، چجوری مطالب رو به‌صورت منفرد و منفک یاد نگیریم و مقدمه و موخره و کاربردشون رو یاد بگیریم؛ منبع اصیل رو از غیراصیل تشخیص بدیم و کلی نکته در مورد یادگیری مستمر رو در خودمون نهادینه و تبدیل به رویه کنیم چیزی که توی این دهه آخرین شانس‌هاش رو داریم و بعدش سخت و سخت‌تر می‌شه.

✅

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

✅

پیدا کردن متر و معیار: تمرین کنیم هر پیروزی، هر شکست، هر تعریف و تمجید، هر دستاورد رو فقط در مختصات محیط اطرافمون نسنجیم. شاید یک کار یا بهبود توی محیط فعلی‌مون یک دستاورد بزرگ و درخور تمجید و تشویق باشه؛ ولی همون کار توی محیط بزرگ‌تر و پیشرفته‌تر یک امر بدیهی و پیش‌وپا افتاده باشه. منظورم این نیست که خودمون رو دست‌کم بگیریم و دستاوردهامون رو با دستاورد دانشمندان مرکز تحقیقات سِرن یا فلان لابراتوار ام‌آی‌تی مقایسه کنیم؛ بلکه بدونیم نسبت دستاوردمون با محیط بیشینه‌ی پیشرفتگی ذهنمون + ۱ واحد، چقدر فاصله داره. این کمک می‌کنه ذهنمون بزرگ‌تر از محیط اطرافمون باشه؛ بدونیم دنیای بعد از پرچین‌های مزرعه چه شکلیه! همین‌طور اشتباهات و شکست‌هامون رو درست بسنجیم، الکی کوچیک یا بزرگشون نکنیم بلکه نسبتش رو یاد بگیریم...

⚙️ مهارت‌های فنی

➖ حداقل یک زبون سطح بالا رو اول تا سطح ساخت پروژهٔ واقعی و بعدتر به صورت عمیق و تا لایه‌های پایینش مسلط شید.
➖ ابزارهای عمومی و پایه مثل Git یا کامندنویسی لینوکس و ابزارهای توسعه مشارکتی یا ALM رو اصولی و عمیق یاد بگیرید، تا به کارهای مقدماتی و ابزارهای گرافیکی محدود نباشید.
➖ ساختمان داده‌ها، الگوریتم‌ها، پایگاه داده و مفاهیم پایهٔ سیستم‌عامل رو خوب بشناسید—نه برای امتحان، برای حل مسئله! برای تحلیل شرایط و مشکل، برای درک چیزی که داره اجرا می‌شه یا حتی اجرا نمی‌شه! حتی اگر دانشگاه در تدریس این مفاهیم کم‌توجهی کرده یا حتی از رشته زمین‌شناسی تغییر فیلد دادید و پیشینه‌اش رو نداشتین، اینا واقعا کاربردی هستن... اگر به احمق بودن کسانی که کتاب و جزوه بی‌کیفیت رو صرفا ترجمه کردن شک کردید، هرگز به احمق نبودن کسانی که این دروس رو «تألیف» کردن شک نکنین!

تمایل دارید این بحث ادامه پیدا کنه؟ (ادامه ۲۰ تا ۳۰ سالگی، و بعدتر دهه‌های قبل و بعدش)، ری‌اکشن ⚙️ ۱۰ درصد تعداد ویو)

Please open Telegram to view this post

VIEW IN TELEGRAM

58❤4👍2

1.45K viewsAmin Mesbahi, 04:33

tech-afternoon

🙂 روایت ۲۰ تا ۳۰ سالگی، بخش دوم...
(مطالعه بخش اول)

🏛 ساختن نمونه‌کار

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

🔣 ریپوهای شخصی‌ خودتون رو مثل محصول واقعی نگه‌داری کنید: README، Issues، Releases, Chane log، پیام کامیت درست بنویسد... تمرینی خواهد بود برای دهه‌ای که همین ریزه‌کاری‌ها از شما کاراکتر استانداردتری می‌سازه برای کارهای بزرگ.

🔣

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

📇 مشارکت در اجتماع

🔣 در اوپن‌سورس مشارکت «ارزش آفرین» کنید: Issue triage، مستندسازی، رفع باگ ساده، و هرگز سراغ مشارکت‌هایی که مسئله‌ای حل نمی‌کنه نرید. به بیان ساده خودتون رو گول نزنید و بقیه رو علاف پول‌ریکوئست بی‌ارزش نکنید...

🔣 در رویدادهای محلی یا آنلاین شرکت کنید؛ شبکه‌سازی کنید، اگر حتی در حد چند دقیقه مطلب می‌تونید تهیه کنید، مشارکت کنید.

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

🔋مدیریت زمان و انرژی

➖ روش‌های مختلفی برای تمرکز روی کار و استفاده بهینه از زمان وجود داره، مثل قانون ۴۵–۱۵: ۴۵ دقیقه تمرکز، ۱۵ دقیقه استراحت فعال (مثل قدم‌زدن، نه گوشی چک کردن). خیلی از ما به خودمون میایم و می‌بینیم کل روز داریم می‌دویم ولی آخرش هم از همه کارها عقبیم. کار عمیق، تمرکز و زمان‌بندی چیزهاییه که این روزها خصوصا با وجود شبکه‌های اجتماعی و اخبار و... سخت تبدیل به رفتار و عادت می‌شن. جدی بگیریمشون!
➖ خواب کمتر از ۷ ساعت، بدهی فنی ذهنی ایجاد می‌کنه (آسیب‌های جسمی که من به واسطه کم خوابید در سنین کم‌تر، در سنین بالاتر تجربه کردم اهمیتش رو بهم ثابت کرد).
➖ نرمش، پیاده‌روی یا هوازی باعث می‌شه در دهه ۴۰ درگیر عدم تمرکز و وقفه در کار و پیشرفتتون به خاطر کمردرد و زمین‌گیر شدن نشید. همچنین کمک می‌:نه درگیر burnout شدن و خستگی فکری نشید.

😵‍💫 اشتباهات رایج

✖️

عجله و طمع! برای سنیور شدن (خطاب شدن)، برای درآمد فلان، برای دیده شدن، و... عجله و طمع نکنید، تیر خلاص خواهد بود به تمام سال‌های پیشِ روی شما... از دریایی که در نزدیکی ساحل عمقش ۱۰ سانتیمتر است ولی کمی جلوتر عمقش به چند ده متر می‌رسه؛ تبدیل می‌شید به استخری که سرتاسرش عمق ۱۰ سانتیمتری داره!
✖️ مقایسهٔ خطی با دیگران در لینکدین؛ توییتر و.. مسیر آدم‌ها متفاوته.
✖️تعویق بیش‌ازحد یادگیری علوم پایه‌ای؛ دیر یا زود به درک پیچیدگی نیاز پیدا می‌کنید؛ یه جا می‌رسه که به خاطر علوم پایه‌ای رو خوب بلد نبودن (ریاضی، الگوریتم و...) متوقف می‌شید؛ توی CRUD گیر می‌کنید.
✖️شکارچی مد روز نشید، خصوصا بدون درک اصول. اول اصول، بعد ابزار.

✏️ جمع‌بندی
دههٔ ۲۰ سکوی پرش مهمیه، نه خط پایان. این دهه، سن کاشت است، و نه برداشت! تا می‌تونید بکارید، تا می‌تونید به جای فکر کردن به تصویر زیبای روی خاک، به فکر شخم خوب و بذر خوب کاشتن و خلاصه زیر خاک باشید، چیزی که دیده نمی‌شه فعلا، ولی فصل برداشت زیبایی خودش رو نشون می‌ده، به فکر گل‌هایی که عمرشون و زیبایی‌شون چند صبا بیشتر نیست نباشید... تله‌ها و فریب‌ها این سنین زیاد هستن، مراقبشون باشین 😉

در صورت تمایل جمع و فیدبک مثبت (⚙️) از این بحث، در پست بعدی دربارهٔ استراتژی‌های ۳۰ تا ۴۰ سالگی و تحولات مسیر شغلی و رفتاری صحبت خواهیم کرد. 💬 اگر نکته یا سؤال خاصی دارید بنویسید تا در نسخه‌های بعدی اضافه کنم.

Please open Telegram to view this post

VIEW IN TELEGRAM

54❤3

1.89K viewsAmin Mesbahi, 04:30

tech-afternoon

✨ طی ۲۴ ساعت گذشته، و احتمالا چند روز آینده، خیلی‌هامون ذهنمون درگیر شرایط و اخبار ایرانه (چه ایران باشیم؛ چه از دور دنبال‌کننده اخبار و نگران وضعیت عزیزانمون) در شرایطی که اخبار نگران‌کننده‌ای در جامعه وجود داره، حفظ تمرکز و آرامش برای ما اهمیت زیادی داره.…

۸ ماه پیش، وقتی شرایطی مشابه امروز (البته با گستردگی و شدت خیلی کمتر) برای کشور پیش اومده بود، چند خطی رو به عنوان پیشنهاد یا بلند بلند فکر کردن نوشتم، که اگر دوست داشتید مطالعه کنید.

تصور می‌کنم با در نظر گرفتن ابعاد گسترده‌تر این نوبت، اضافه کردن چند مورد دیگه بد نباشه:

۱: مهم‌تر از غرق شدن توی سیل تحلیل‌ها و اخباری که شاید آمیخته با شایعه و اغراق و جانبداری (به هر سو) باشن، بهتره «آماده» باشیم برای مواجهه با «خطرات معقول و محتمل»؛ پس اگر در شهر یا منطقه‌ای زندگی می‌کنیم که احتمال شمول خطر داره، مکان‌های امن، مراکز درمانی و... نزدیک محل سکونتمون رو شناسایی کنیم و این کار رو برای عزیزان و نزدیکانمون رو هم انجام بدیم.

۲: خیلی سخته، ولی به جای درگیر شدن با انبوه نظرات و شایعات و اخبار غیردقیق، «مهندسی» فکر کنیم، یادتونه در مورد Left shift صحبت کردیم؟، شاید بد نباشه اینجا هم این متد رو به کار بگیریم، فرض کنید همین الان مخاطره‌ای در نزدیکی شما اتفاق افتاده، آیا سفر به فلان شهر در اون لحظه ممکنه یا بهتره به مکان امن نزدیک، خودمون رو برسونیم؟ اگر امکان قطع دسترسی به اینترنت و یا موبایل محتمله، آیا رادیو در دسترس داریم و باطری داره؟ و سوالاتی از این دست رو از خودمون بپرسیم.

۳: یادمون نره ما در این لحظه نه تحلیل‌گر سیاسی هستیم، نه متخصص نظامی، نه پیشگو! مقدم بر هر چیز عضو یک خانواده و شهروند ایرانیم. وظیفه ما کمک به حفظ «حس حمایت» به عزیزان و اطرافیانمون؛ و هوشیاریه، تا اینکه سرگرم لایک و توییت و تحلیل و... باشیم.

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

❤24👍6

2.09K viewsAmin Mesbahi, 09:33

tech-afternoon

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

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

۱: کاهش ریسک از دست دادن داده‌ها

۲: افزایش تاب‌آوری سرویس‌ها و کوتاه‌کردن زمان بازگشت به سرویس

برای سازمان یا کسب‌وکارتون کمکی کنه، حتمن روی کمک من حساب کنید.

شرمنده‌ام که بخش اعظم آموخته‌هام توی ایران بوده ولی در این لحظه کمکی بیش از این از دستم ساخته نیست.

* نکته: پیشنهاد می‌کنم چه با من یا هر فرد مشاوری که شناخت و اطمینان کامل ازش ندارید، «هیچ» دیتایی در مورد نام سازمان یا کسب‌وکارتون به اشتراک نگذارید.
تخریب زیرساخت‌ها و توقف کار و زندگی چیزیه که هر کدوممون باید به سهممون کمک کنیم تا کمینه بشه.

👌12❤7👏5

1.23K viewsAmin Mesbahi, 09:38

tech-afternoon

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

نشت اطلاعات فوق‌محرمانه و حتی سری، هک‌های متعدد و... نشون داد ضعف عمیق دانش، و اجرای مفاهیمی مثل security | compliance | trust and control | information classification ابتدا در سطح فرایند، دوم در سطح معماری و توسعه سیستم‌های کشور، یکی از دلایلی بود که محرمانگی اطلاعات طبقه‌بندی‌شده اینطور شکننده باشه. نوشتم «یکی از دلایل» چون امنیت نرم‌افزاری، و نرم‌افزار امنیتی؛ عملا ذیل امنیت اطلاعات (از شفاهی تا کاغذی و...) معنی داره. و این یعنی «فرهنگ»، یعنی جایی که آدم‌ها باید یاد بگیرن، اعتماد کردن، یا اعتبار خریدن با بیان موضوعات طبقه‌بندی شده تا چه‌اندازه می‌تونه پیامدهای جدی داشته باشه. فقدان آموزش مناسب (منظورم جزوه چاپ کردن نیست، مشکل اینه که هرچقدر سطح سازمانی فرد بالاتر بره لزوم و احساس نیاز به یادگیری کمتر حس می‌شه، و این تنها بخشی از آسیب‌ها بوده).

فرایندها و سیستم‌ها باید به گونه‌ای طراحی و تولید بشن که شما به محض نشت اطلاعات بتونی لیستی از نقاط مستعد نشت (افرادی که به اون اطلاعات دسترسی داشتن) رو پیدا کنید. و سیستم‌های مدرن، بعد از چند مورد نشت قادرن با روش‌های ماشین‌لرنینگ، و شناسایی الگوهای نشت اطلاعات، لیست افراد مورد ظن رو محدود کنن. این یعنی سیستم‌های متمرکز، یا توزیع‌شده‌ی متصل. نه «سامانه‌»های احمقانه و محدود به CRUD که از فقط مسئول‌دفترها و کارمندها بهشون دسترسی دارن.

شاهد بودیم که نه تنها «معماری اطلاعات» شکننده بود، بلکه در سطح نرم‌افزار و زیرساخت هم بدتر! این به معنی انگشت اتهام گرفتن به سمت فقط نظامی‌ها نیست، در سطح دولت، بانک‌ها و هر جایی می‌شد دید که تفاوتی بین مدیریت بحران در سال ۱۴۰۴ با دوران پیش از عصر نرم‌افزار و ارتباطات نیست!

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

من این چند روز خیلی فکر کردم که چطور نرم‌افزار می‌تونست به پیش‌گیری از بحران فعلی؛ تا مدیریت بهتر بحران کمک کنه. در دولت‌ها و سیستم‌های امنیتی برای پیش‌بینی وقایع، سال‌هاست نرم‌‌افزارهایی وجود داره که کاری که ذهن اغلب انسان‌ها ازش عاجزه، یعنی کنار هم چیدن انبوه اخبار و صحبت‌ها و تصمیم‌ها و تغییرات در رویکردها و... و پیش‌بینی‌هایی مبتنی بر هوش‌مصنوعی از وقایع پیش رو (مثلا وزیر a از کشور b در مورد c با لحن d حرف رو زد و آقای e از کشور f با لحن g پاسخ داد و ... => یعنی گراف‌های بسیار بزرگ از وقایع، اخبار، تصمیمات و...). که ما از چنین سیستم‌هایی ‌برخوردار نیستیم، یا بهتر بگم چون بضاعتمون CRUD است!

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

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

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

❤20👍71

2.32K viewsAmin Mesbahi, 14:37

tech-afternoon

آیا آ‌تش‌بس شیرینی نداره؟! 😉🤔
دورهمی فنی «ویژه» داشته باشیم؟ (آنلاین و احتمالا یکشنبه)

Final Results

37%

داشته باشیم، میام.

13%

داشته باشیم، نمیام/شاید بیام.

داشته باشیم: موضوع رو توی کامنت پیشنهاد می‌‌دم

13%

داشته باشیم: موضوع با خودت

37%

بیخیال، وقت مناسبی نیست.

60 voters1.25K viewsAmin Mesbahi, 14:18

tech-afternoon

💡

مفهوم، اصول و مزایای Pair Programming چیه؟

برنامه‌نویسی دونفره/جفت (معادل فارسی مناسبی برای سراغ ندارم) یعنی دو نفر توسعه‌دهنده، به‌صورت همزمان روی یک تسک یا تیکت با هم کار کنند — معمولاً هم با استفاده از یک صفحه نمایش مشترک (حضوری یا با اشتراک‌گذاری صفحه، یا با امکانات جدیدتر مثل live sharing).

اما این فقط "دو نفر که با هم کدنویسی می‌کنن" نیست. هدف اصلی اینه که با هم فکر کنن، با هم تصمیم بگیرن و از هم یاد بگیرن.

🎯 چرا از Pair Programming استفاده کنیم؟

- آموزش، آنبورد سریع‌تر نیروهای جدید
- انتقال مستمر دانش در تیم (در زمینه‌های متنوع و کدبیس‌های مختلف)
- افزایش کیفیت کد (کاهش باگ، نام‌گذاری بهتر، منطق تمیزتر)
مالکیت مشترک کد — بیش از یک نفر در جریان کد هست
- یادگیری ابزارها، الگوها و تکنیک‌ها در عمل
- شکستن سیلوها و افزایش هماهنگی در تیم (دانش یک بخش از کد در یک نفر متمرکز نمیشه و افراد می‌تونن همدیگه رو پوشش بدن)

✅ کجا از Pair Programming استفاده کنیم؟

- حل باگ‌های پیچیده
- کار روی کد ناآشنا
- آشنایی نیروهای جدید با یک فیچر
- تغییرات حساس یا حیاتی
- طراحی ساختار داده یا الگوریتم
- توسعه با رویکرد TDD یا بهینه‌سازی عملکرد

❌ کجا مفید و مناسب نیست (معمولا)؟

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

🧑‍💻 نقش‌ها در Pair Programming
- نقش Driver (راننده): کدنویسی می‌کنه، تمرکزش روی منطق فوری و نگارش است.
- نقش Navigator (ناوبر): هم‌زمان کد رو مرور می‌کنه، به ساختار، تست‌ها و موارد خاص فکر می‌کنه.
نکته مهم: نقش‌ها رو هر ۲۰ تا ۳۰ دقیقه جابه‌جا کنید تا ذهن هر دو نفر فعال بمونه، و ناوبر تبدیل به تماشاچی نشه!

🧭 چجوری Pair Programming مؤثری داشته باشیم؟

- هدف مشترک جلسه رو قبل از شروع مشخص کنید: دقیقاً دنبال چی هستید؟
- فرمت همکاری رو مشخص کنید: Driver/Navigator یا نوبتی؟
- مدت جلسه رو محدود کنید: مثلاً ۹۰ دقیقه با استراحت در میانه
- نقش‌ها رو به‌صورت منظم عوض کنید
- حین کار بلند فکر کنید، توضیح بدی، سوال بپرسید، پیشنهاد بدهید
- در پایان یک مرور کنید: چی یاد گرفتیم؟ قدم بعدی چیه؟

🧠 ملاحظات مربوط به ظرفیت تیم

درسته که دو نفر روی یک تیکت کار می‌کنن، ولی این به معنی نصف شدن بهره‌وری نیست. در بسیاری از مواقع، Pair Programming باعث:
- تحویل سریع‌تر در storyهای پیچیده
- راه‌حل‌های با کیفیت‌تر و قابل نگهداری‌تر
- کاهش اصطکاک در بازبینی و افزایش درک مشترک

💡 نکته: اگه قراره چندین تیکت به صورت Pair انجام بشن، ظرفیت تیم رو تنظیم کنید — مثلاً ۱۵–۲۰٪ استوری‌پوینت کمتر در نظر بگیر، یا تیکت‌های دونفره رو جداگانه پیگیری کنید.

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

✅ نکات و بهترین روش‌ها

- پارتنر مناسب انتخاب کنید: تعادل در تجربه، دامنه دانش، یا تکنولوژی
- صبور باشید: هدف، سرعت نیست — کیفیت و یادگیری مهمه
- بیش از حد کیبورد رو از دست نفر مقابل نگیرید — بگذارید هر دو فعال باشند
- سوال «چرا؟» رو تشویق کنید — یادگیری بخش اصلی کاره
- حتماً استراحت بدید — خستگی ذهنی طبیعی و تأثیرگذاره
- اگه بعد از ۳۰–۴۰ دقیقه حس کردید که کار پیش نمی‌ره، یه قدم عقب برید و برنامه‌ریزی رو بازنگری کنید

💬 تجربه یا نظر شما چیه؟

Please open Telegram to view this post

VIEW IN TELEGRAM

👍12❤4👌3🔥2

3.11K viewsAmin Mesbahi, 03:59

tech-afternoon

نیم‌نگاهی به Data-Oriented Programming

مفهوم برنامه‌نویسی داده‌گرا (DOP) الگوییه داده رو محور قرار می‌ده و اولویت اصلیش سازماندهی کارآمد داده‌ها است. درسته که ریشه‌هاش به LISP (1958) برمی‌گرده، اما در دهه ۲۰۱۰ با ساختارهای داده مدرن، پایدار و کارآمد، مورد توجه قرار گرفت. برخلاف برنامه‌نویسی شی‌گرا (OOP) که داده‌ها و رفتار رو درون اشیاء محصور می‌کنه، «DOP کد رو از داده‌ها جدا می‌کنه» و از ساختارهای داده عمومی و تغییرناپذیر استفاده می‌کنه.

مفهوم DOP اولین‌بار در جوامع خاصی مثل توسعه‌دهنده‌های بازی‌های ویدیویی (game devs) و سیستم‌های real-time مطرح شد. توی این حوزه‌ها، ساختار داده و نحوه‌ی دسترسی به حافظه (memory layout) نقش مهمی در عملکرد و کارایی داره. بعدها این تفکر توسط توسعه‌دهنده‌هایی مثل Yehonathan Sharvit در حوزه‌ی طراحی سیستم‌های تجاری (business systems) مطرح و ترویج شد.

کتاب “Data-Oriented Programming” (از انتشارات Manning)، یکی از منابع مرجع برای معرفی و آموزش این پارادایمه که توسط Yehonathan نوشته شده.

🔑 اصول کلیدی برنامه‌نویسی داده‌محور (DOP)

۱: داده رو از رفتار جدا کنید
در OOP، داده‌ها و متدها در کنار هم درون کلاس‌ها قرار می‌گیرن ولی در DOP، داده‌ها معمولاً به صورت ساختارهای ساده مثل JSON یا map/record تعریف می‌شون و توابع (behavior) جداگانه بر روی این داده‌ها عمل می‌شن.

۲: استفاده از داده‌های ساده (plain data)
داده‌ها باید قابل عبور بین سرویس‌ها، قابل سریال‌سازی، قابل لاگ‌کردن و قابل ذخیره باشند. این یعنی نباید شامل توابع، متدها، یا ویژگی‌هایی مثل اینترفیس‌های پیچیده باشن.

۳: عدم اعتماد به وضعیت پنهان (hidden state)
اشیای OOP ممکنه stateهای مخفی داشته باشن که باعث ایجاد باگ و رفتار غیرمنتظره بشه. در DOP، داده‌ها باید شفاف و قابل مشاهده باشن.

۴: تبدیل داده به داده
در DOP، توابع از نوع Data → Data هستند. مثل JSON in → JSON out. این باعث تست‌پذیری بسیار بالا می‌شه.

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

⚖️ مقایسه با برنامه‌نویسی تابعی (FP)
در نگاه اول، DOP شباهت زیادی به FP داره:
- هر دو داده رو immutable در نظر می‌گیرن.
- توابع pure رو ترجیح می‌دن.

اما تفاوت مهمی وجود دارد:
- در FP تمرکز روی توابع و محاسبات ریاضی است. در حالی که توی DOP تمرکز اصلی روی ساختار داده و سادگیه.
- توی FP گاهی تمایل به انتزاع‌های سنگین مثل monad و functor است. ولی DOP از این انتزاع‌ها دوری می‌کنه و مدل خودش رو تا حد ممکن ساده و نزدیک به JSON نگه می‌داره.

⚖️ فرقش با Go و سبک داده‌محور
زبان Go خودش یک زبان شی‌گرا نیست و کلاس نداره، به همین دلیل خیلی از برنامه‌نویس‌های Go به طور ضمنی به سبک داده‌محور نزدیک هستن:

- داده‌ها struct هستند و بدون منطق پیچیده درون آن‌ها.
- تابع‌ها به صورت مستقل تعریف می‌شن و گاهی روی struct گیرنده دارن (methods) ولی معمولاً ساده‌ان.
- سریال‌سازی (JSON, protobuf) بسیار رایجه.

با این حال، Go هنوز هم اجازه‌ی مدل‌های ترکیبی می‌ده، و استفاده‌ی بیش از حد از interfaceها ممکنه باعث پنهان شدن رفتار بشه!

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

جمع‌بندی:
برنامه‌نویسی داده‌محور قرار نیست جای OOP یا FP را بگیره، جوگیر نشیم از فردا راه بیوفتیم و «امروزه، عصر داده‌محور است! راه بندازیم»! بلکه یک رویکرد مکمل برای حل مشکلات پیچیدگی و مدیریت داده‌هاست. اگر تا الان درگیر کلاس‌های پیچیده، تست‌نشدن رفتارها، و ساختارهای مبهم بودید، شاید شاید و شاید بد نباشه به داده‌محور فکر کنید.

💬 نظر؟ سوال؟ گپ؟

Please open Telegram to view this post

VIEW IN TELEGRAM

9✍3❤3👍1

997 viewsAmin Mesbahi, 04:30

tech-afternoon

🔓

مرور ۱۰ ریسک مهم امنیتی API طبق OWASP 2023 (بخش اول)

مقدمه: OWASP چیه؟
اختصار Open Worldwide Application Security Project، یه پروژه‌ی بازمتنه که از سال ۲۰۰۱ تا امروز به صورت مداوم، در حوزه ارتقاء امنیت نرم‌افزارها فعاله. این پروژه با فراهم کردن منابع، ابزارها و استانداردهایی مثل OWASP Top 10 به توسعه‌دهنده‌ها، معماران و امنیت‌کارها کمک می‌کنه تا ریسک‌های امنیتی را بهتر بشناسن و کاهش بدن.

طی سال‌های اخیر، با افزایش وابستگی به APIها، OWASP نسخه‌ی تخصصی‌تر از Top 10 رو برای امنیت APIها منتشر کرده که آخرین نسخه‌اش مربوط به سال ۲۰۲۳ است.

1️⃣ تهدید API1: Broken Object Level Authorization
مجوزدهی ناقص در سطح آبجکت

اگر API به درستی بررسی نکنه که آیا کاربر مجاز به دسترسی به یک آبجکت خاص (مثل userId یا accountId) هست یا نه، مهاجم می‌تونه به داده‌های دیگران دسترسی پیدا کنه.

مثال:

GET /api/users/12345/profile

شاید کاربر توی UI فقط پروفایل خودش رو ببینه، ولی اگر از طریق API شناسه کاربر دیگه‌ای رو درخواست بده می‌تونه پروفایل اون کاربر رو هم ببینه. کافیه تا سیستم چک نکنه که آیا اجازه داره پروفایل کاربر 12345 رو ببینه یا نه، اطلاعات افشا می‌شه.

روش‌های جلوگیری:

- بررسی دقیق سطح دسترسی در لایه‌ی بک‌اند برای هر درخواست.
- استفاده از tokenهایی که به صورت داخلی با دسترسی محدود مدیریت می‌شن.
- عدم اعتماد به اطلاعات ارسال‌شده از سمت کلاینت.

2️⃣تهدید API2: Broken Authentication
احراز هویت ناقص

سیستم‌هایی که از احراز هویت ناامن یا ناقص استفاده می‌کنن ممکنه اجازه‌ی دسترسی غیرمجاز رو محیا کنن.

مثال:

- استفاده از توکن‌های قابل پیش‌بینی یا بدون انقضا.
- ارسال اطلاعات ورود در متن ساده (plaintext).

روش‌های جلوگیری:

- استفاده از استانداردهای امن مثل OAuth 2.0 و OpenID Connect.
- توکن‌های کوتاه‌مدت با امکان ابطال (revocation).
- فعال کردن MFA (احراز هویت چندمرحله‌ای).

3️⃣تهدید API3: Broken Object Property Level Authorization
مجوزدهی ناقص در سطح ویژگی آبجکت‌ها

حتی اگر کاربر مجاز به دسترسی به یک آبجکت باشه، ممکنه مجاز به دسترسی یا تغییر همه‌ی ویژگی‌های اون آبجکت نباشه (مثلاً تاریخ ایجاد اون آبجکت یا تغییر مقدار حقوق خودش یا نقش کاربری‌اش).

مثال:
یک کاربر معمولی بتونه فیلدی مثل isAdmin=true را در payload قرار بده و نقش ادمین بگیره.

روش‌های جلوگیری:

- اعتبارسنجی دقیق ورودی‌ها و فیلتر کردن فیلدهای حساس.
- استفاده از DTOها (Data Transfer Object) برای کنترل فیلدهایی که کاربر می‌تونه ببینه یا تغییر بده.

4️⃣تهدید API4: Unrestricted Resource Consumption
مصرف بدون محدودیت از منابع

اگر API اجازه‌ی مصرف نامحدود منابع رو فراهم کنه (مثل حافظه، CPU یا اتصالات)، ممکنه با حملاتی مثل DoS مواجه بشه.

مثال:

GET /api/messages?limit=1000000

روش‌های جلوگیری:

- محدود کردن تعداد درخواست‌ها (Rate limiting).
- اعمال محدودیت روی پارامترهایی مثل limit, offset.
- احراز هویت برای دسترسی به عملیات سنگین.

5️⃣تهدید API5: Broken Function Level Authorization
مجوزدهی ناقص در سطح عملکرد

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

مثال:
یک کاربر معمولی بتونه از API ادمین استفاده کنه:

DELETE /api/users/12345

روش‌های جلوگیری:

- تعیین سطح دسترسی دقیق برای هر endpoint و method.
- استفاده از Role-Based Access Control (RBAC).
- عدم اعتماد به نقش ارسال‌شده از سمت کلاینت.

💬 نظر؟ سوال؟ مفید بود؟

Please open Telegram to view this post

VIEW IN TELEGRAM

14👍8❤6

941 viewsAmin Mesbahi, 11:04

tech-afternoon

🔓

مرور ۱۰ ریسک مهم امنیتی API طبق OWASP 2023 (بخش دوم)

» در ادامه بخش اول

6️⃣تهدید API6: Unrestricted Access to Sensitive Business Flows
دسترسی بدون کنترل به فرآیندهای حیاتی

زمانی که API بدون احراز هویت یا محدودیت خاصی به عملیات مهم مثل ثبت‌نام، پرداخت یا بازیابی رمز عبور اجازه می‌ده.

مثال:
بات‌ها بتونن میلیون‌ها ثبت‌نام جعلی انجام بدن، یا فراموشی رمز عبور رو بارها صدا بزنن.

روش‌های جلوگیری:
- نرخ‌گذاری (rate limiting) و CAPTCHA.
- احراز هویت برای عملیات حساس.
- مانیتور کردن رفتارهای غیرعادی.

7️⃣تهدید API7: Server Side Request Forgery (SSRF)
جعل درخواست از سمت سرور

زمانی که کاربر مجاز است تا URLهایی رو به API بفرسته تا در نهایت سرور آن‌ها را بخواند (مثلاً برای preview یا دانلود)، اینجاست که ممکنه مهاجم از این امکان سوءاستفاده کنه.

مثال:

POST /api/fetch?url=http://internal.service.local/admin

روش‌های جلوگیری:

- اعتبارسنجی URLهای ورودی و لیست سیاه / سفید کردن مقصدها.
- جلوگیری از دسترسی به IPهای داخلی (مثلاً 127.0.0.1).
- محدود کردن دامنه‌ی درخواست‌های سرور.

8️⃣تهدید API8: Security Misconfiguration
پیکربندی امنیتی اشتباه

تنظیمات اشتباه مثل فعال بودن دیباگ، خطایاب‌ها، یا endpointهای داخلی در محیط تولید، باعث آسیب‌پذیری می‌شه.

مثال:
- فعال بودن Swagger UI یا StackTrace در محیط production.

روش‌های جلوگیری:
- استفاده از DevSecOps و اسکن مداوم پیکربندی‌ها.
- حذف یا غیرفعال کردن endpointهای غیرضروری در production.
- اعمال هدرهای امنیتی.

9️⃣تهدید API9: Improper Inventory Management
مدیریت نادرست موجودی API

نبود فهرست دقیق از APIها، نسخه‌ها، محیط‌ها و وضعیت‌های هر endpoint ممکن است باعث شه تا برخی از APIهای قدیمی یا ناامن در دسترس باقی بمونن.

مثال:
- وجود API نسخه‌ی v1 که هنوز فعالن ولی دیگه نگهداری و تو توسعه و نظارت ندارن.

روش‌های جلوگیری:
- مستندسازی و نسخه‌بندی دقیق APIها.
- استفاده از ابزارهایی برای کشف خودکار APIها مثل API gateways.
- اسکن دوره‌ای برای یافتن APIهای ناشناخته.

0️⃣

1️⃣تهدید API10: Unsafe Consumption of APIs
مصرف ناامن APIهای خارجی

استفاده از APIهای خارجی بدون اعتبارسنجی پاسخ‌ها یا اعتماد بی‌جا ممکنه باعث وارد شدن داده‌های جعلی یا مخرب بشه.

مثال:
- اتکا به داده‌ی مالی از API خارجی بدون بررسی امضا یا صحت داده.

روش‌های جلوگیری:
- بررسی دقیق پاسخ API خارجی قبل از استفاده.
- محدود کردن منابع مورد اعتماد.
- قرار دادن تایم‌اوت و بررسی JSON schema.

💬 نظر؟ سوال؟ تجربه؟

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

بخش اول:
- معرفی SSDLC
- معرفی SDL
- مفهوم Shift-left testing
- مدلس‌ازی تهدیدات امنیتی (Threat Modeling) با استفاده از STRIDE

بخش دوم:
- معرفی Static Application Security Testing (SAST)
- معرفی Dynamic Application Security Testing (DAST)
- معرفی Interactive Application Security Testing (IAST)
- معرفی Runtime Application Self-Protection (RASP)
- معرفی Software Composition Analysis (SCA)
- مفهوم Safe Codingو Security by Design و Secure Coding
- مفهوم Defensive Programming, Defensive Design, Offensive Programming
- سرفصل‌های دوره CSSLP

Please open Telegram to view this post

VIEW IN TELEGRAM

tech-afternoon

🔓مرور ۱۰ ریسک مهم امنیتی API طبق OWASP 2023 (بخش اول)

مقدمه: OWASP چیه؟
اختصار Open Worldwide Application Security Project، یه پروژه‌ی بازمتنه که از سال ۲۰۰۱ تا امروز به صورت مداوم، در حوزه ارتقاء امنیت نرم‌افزارها فعاله. این پروژه با فراهم کردن منابع، ابزارها…

10❤4👍4

1.18K viewsAmin Mesbahi, 04:33

tech-afternoon

CareerRoadmap-techafternoon.png

2.3 MB

🚀 🗺 الگوی پیشنهادی برای مسیر شغلی

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

- خودشناسی
- تعیین هدف با رویکرد SMART
- ارزیابی دقیق توانمندی‌ها) و تدقیق «شکافِ مهارتی» (Skills Gap)
- یادگیری و پایش (رویکرد عملی)
- ارزیابی و تعیین گام بعدی (استفاده از SMART KPI)

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

27❤6👏3

1.3K viewsAmin Mesbahi, 05:18

tech-afternoon

🍰🚀 معماری Vertical Slice

مقدمه
طراحی معماری نرم‌افزار همیشه تلاشی بوده برای اینکه پیچیدگی‌ها رو مهار، تغییرات رو ساده، و تیم رو چابک نگه داره. چندین ساله که در گفتگوها Clean Architecture رو زیاد می‌شنویم و گویی که لازمه داشتن یک معماری خوب اینه که اول clean رو پیاده کنیم، بعد به سایر جنبه‌ها فکر کنیم!! طی «حداقل» این پست، مقایسه‌ای خواهیم داشت بین معماری vertical slice و clean، و بعد تفاوت‌ها و شباهت‌ها، مزایا و معایب، و در نهایت سناریوهای انتخاب رو مرور خواهیم کرد.

فبل از شروع دو تا مفهوم رو مرور کنیم:
- وابستگی یا Coupling:
میزان وابستگی بخش‌های مختلف سیستم به همدیگه. tight coupling یعنی تغییر یک بخش، می‌تونه بخش دیگه‌ای رو خراب کنه. loose coupling اجازه می‌ده بخش‌های مختلف سیستم، مستقلا تکامل و تغییر داشته باشن
.
- همبستگی یا Cohesion:
تناسب و یکدستی عناصر داخل یک ماژول. high cohesion یعنی همهٔ اجزای ماژول یک هدف روشن دارند و چون یک هدف رو دنبال می‌کنن درکشون ساده‌تره؛ low cohesion یعنی کدهای بی‌ربط کنار هم‌ قرار گرفتن.

خلاصه‌ اینکه Coupling → «چقدر به هم وابسته‌ایم؟»
و Cohesion → «چقدر به هم متعلقیم؟»

ایده اصلی clean architecture رو uncle bob معروف سال ۲۰۱۲ طرح کرد، اونم با هدف اینکه جهت وابستگی باید همیشه به سمت «درون» باشه و درونی‌ترین لایه هم که domain است، ولی این صورت ماجراست، هدف اصلی‌ کاهش وابستگی‌ها (control/loose coupling) بود. گاهی (که بعدن توضیح می‌دم کجا) پَرش بین پوشه‌ها و کدهای مختلف زیاد و دشوار می‌شه؛ چرا؟ چون تقسیم‌بندی و جداسازی کدها براساس ماهیت تکنیکال اون‌ها انجام شده، مثلا همه سرویس‌ها زیر پوشه سرویس‌ها، همه کامندها زیر پوشه کامندها و...

حالا vertical slice تقسیم‌بندی رو بر اساس use caseها یا featureها انجام می‌ده، یعنی همه مفاهیم تکنیکال مرتبط با یک feature (قابلیت) کنار هم قرار خواهند گرفت. اینجوری cohison بالاتر و complexity کمتر خواهد شد و مدیریت راحت‌تر خواهد بود. مثل یک قطعه از کیک که تمام لایه‌ها رو با هم داره 🍰
معماری Vertical Slice رو Jimmy Bogard سال ۲۰۱۸ در کنفرانس NDC سیدنی معرفی رسمی کرد با اینکه ایده اولیه‌اش رو از ۲۰۱۵ مطرح می‌کرد. شاید بد نباشه بدونید Jimmy Bogard خالق AutoMapper, MediatR و Respawn است.

مقایسه ساختاری:

Clean Architecture Sample:

┬ src
├── Domain
│   └── Entities/
├── Application
│   └── UseCases/
├── Infrastructure
│   └── Persistence/
└── WebApi
    └── Controllers/

Vertical Slice Architecture Sample:

┬ src
├── Orders
│   ├── Create
│   │   ├── Command.cs
│   │   ├── Handler.cs
│   │   ├── Validator.cs
│   │   └── Tests/
│   └── Cancel/...
└── Shared/...

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

💬 نظر و تجربه شما چیه؟ دوست دارید روی این موضوع عمیق‌تر شیم؟

Please open Telegram to view this post

VIEW IN TELEGRAM

❤108👍3👏1

1.16K viewsAmin Mesbahi, edited 04:35

About

Blog

Apps

Platform