Microfrontend.ir

https://x.com/hemn_hp/status/1856414598896988203?t=M_XsHzsx8cT9Zm7pzT0Q7g&s=35

مجموعه مقالات سال ۲۰۲۳ آقای Alex Xu  درباره سیستم دیزاین. ایشون یکی از شناخته‌شده‌ترین آدم‌ها در مارکت سیستم دیزاینه و کتابهاش بست‌سلرن!

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

تعریف دقیق نیازمندی‌ها در معماری نرم‌افزار حیاتی و عباراتی مانند «سریع»، «پاسخگو» یا «قابل گسترش» به خودی خود کافی نیستند؛ زیرا معیاری برای سنجش آن‌ها وجود ندارد. با این حال، کاربران همچنان این ویژگی‌ها را می‌خواهند. نقش معمار این است که این ویژگی‌ها را تا حد امکان فراهم کرده و بین تضادهای احتمالی آن‌ها تعادل ایجاد کند.
 
اگر این نیازها به‌طور مشخص و قابل اندازه‌گیری بیان نشوند، هیچ مبنایی برای پذیرش سیستم توسط کاربران وجود نخواهد داشت و راهنمایی ارزشمندی از مهندسان در حین کار گرفته می‌شود. در نتیجه، معماران باید تلاش کنند این نیازها را با سوالاتی مانند «چقدر؟»، «در چه مدت زمانی؟»، «چند بار؟»، «چقدر سریع؟» و غیره به مقادیر دقیق تبدیل کنند. اگر این اطلاعات در برنامه تجاری سیستم نیست، باید علت آن را جستجو کرد و آن‌ها را دریافت.
 
همچنین باید نیازمندی‌های نامشخص را به‌صورت محدوده‌ای تعریف کرد: حداقل، مطلوب، و حداکثر. اگر این محدوده‌ها مشخص نشوند، یعنی رفتار مورد نظر سیستم به‌درستی درک نشده است. این کار ممکن است وقت‌گیر و هزینه‌بر باشد، اما اگر هیچ‌کس به‌اندازه کافی به عملکرد اهمیت ندهد که هزینه تست‌های عملکرد را بپردازد، احتمالاً عملکرد مهم نیست و می‌توان روی جنبه‌های دیگر تمرکز کرد.
 
برای مثال، نیازمندی‌هایی مثل: «باید به ورودی کاربر در حداکثر ۱۵۰۰ میلی‌ثانیه پاسخ دهد. تحت بار عادی (تعریف شده به‌عنوان...) زمان پاسخگویی بین ۷۵۰ تا ۱۲۵۰ میلی‌ثانیه باشد. پاسخگویی زیر ۵۰۰ میلی‌ثانیه توسط کاربر قابل تشخیص نیست، بنابراین برای کمتر از این مقدار هزینه نخواهیم کرد»، نیازمندی‌های واقعی هستند.  ‏"نیازمندی‌هایی مثل 'سریع' و 'قابل گسترش' بدون معیار مشخص بی‌فایده‌اند. برای تعریف درست، اعداد و محدوده‌ها را مشخص کنید: چقدر سریع؟ چند کاربر؟ چه زمانی؟ اگر برای تست عملکرد هزینه نمی‌شود، شاید اصلاً مهم نباشد."
#TIP-10

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

به محض اینکه صحبت از کاهش هزینه‌ها می‌شود، مدیر پروژه می‌پرسد: «آیا واقعاً به این نیاز داریم؟» و برای «این» هر چیز مهم و ضروری که در سیستم لازم است، جایگزین می‌شود؛ از جمله مجوزهای نرم‌افزاری، سرورهای اضافی، پشتیبان‌گیری‌های خارج از سایت یا منابع برق.
 
در چنین شرایطی، پاسخ درست این است که بگوییم: «بله، به آن نیاز داریم.» اما اکثر اوقات، پاسخ متفاوتی ارائه می‌دهیم. چون به‌عنوان مهندسان، به مصالحه و انتخاب‌های مختلف عادت کرده‌ایم. به همین دلیل به جای پاسخ قاطعانه، شروع به توضیح دادن و توجیه می‌کنیم و معمولاً مدیر بعد از کلمه «خب...» دیگر گوش نمی‌دهد.
 
مشکل اصلی این است که ما کار خود را به‌عنوان مهندسی و حل مسأله می‌بینیم، در حالی که مدیر پروژه آن را به چشم یک مذاکره نگاه می‌کند.
«وقتی مدیر پروژه می‌پرسه "آیا واقعاً به این نیاز داریم؟" به جای توضیح فنی، بگو "بله، بدون این، سیستم سه بار در روز سقوط می‌کنه، مخصوصاً وسط جلسه هیئت مدیره!" گاهی مذاکره یعنی قاطعیت، نه توضیح!

 #TIP-09

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

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

 #TIP-08

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

معماران نرم‌افزار که از موقعیت‌های فنی به نقش‌های رهبری منتقل می‌شوند نکات مهمی را باید در نظر داشته باشند. در این نقش‌ها، ارتباط مؤثر به اندازهٔ مهارت‌های فنی اهمیت دارد. نکات کلیدی برای بهبود مهارت‌های ارتباطی در این نقش عبارتند از:
 
1. قدرت حضور را درک کنید: وقتی برای صحبت با گروهی می‌ایستید، دینامیک جلسه به نفع شما تغییر می‌کند. این کار به طور طبیعی اقتدار و اعتماد به نفس شما را نشان می‌دهد و باعث می‌شود دیگران کمتر صحبت شما را قطع کنند و بیشتر به حرف‌هایتان توجه کنند.
    
2. استفاده از زبان بدن و ارتباط چشمی: زبان بدن و ارتباط چشمی در انتقال مؤثر ایده‌ها اهمیت دارند. ایستادن به شما کمک می‌کند تا با تعداد بیشتری از افراد ارتباط چشمی برقرار کنید و با استفاده از حرکات دست، پیام خود را بهتر منتقل کنید.
    
3. تأثیر روی صدا و بیان: وقتی ایستاده صحبت می‌کنید، حالت صدا، حجم، سرعت و لحن شما به طور طبیعی تغییر می‌کند. این تغییرات باعث می‌شوند نکات مهم را با تأثیر بیشتری به مخاطب منتقل کنید و پیام خود را واضح‌تر بیان کنید.
    
 
به عنوان یک معمار نرم‌افزار، برای انتقال بهتر ایده‌ها، هنگام صحبت با گروه بایستید. ایستادن به شما اقتدار و اعتماد به نفس می‌بخشد، زبان بدن و ارتباط چشمی را بهبود می‌دهد و تأثیرگذاری پیام شما را دو برابر می‌کند.

#TIP-07

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

در قابلیت‌های درخواستی، به دنبال _ارزش_ بگردید.
داستان هواپیمای F-16 فالکون مثال خوبی است؛ جایی که نیاز اصلی "فرار از نبرد" بود، نه دست‌یابی به سرعت ۲ تا ۲.۵ ماخ که از نظر فنی بسیار چالش‌برانگیز بود. با درک نیاز اصلی، تیم طراحی توانست یک هواپیمای سبک و چابک طراحی کند که با هدف واقعی مأموریت هماهنگ بود و نیازی به سرعت بالا نداشت.

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

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


#TIP-06

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

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

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

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

#TIP-05

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

ارتباطات پادشاه و بندگانش شفافیت و رهبری است!

معماران نرم‌افزار برای موفقیت پروژه باید با تیم‌های خود ارتباطی روشن و رهبری مؤثر داشته باشند. معمولاً زمانی که معماران به‌جای تعامل، از بالا دستورات خود را به توسعه‌دهندگان تحمیل می‌کنند، اختلافات زیادی به‌وجود می‌آید و پروژه از اهداف اصلی فاصله می‌گیرد.
ارتباط مؤثر نیازمند سادگی و وضوح است؛ به‌جای اسناد طولانی و پیچیده، استفاده از ابزارهای ساده‌ای مانند نمودارهای اولیه و جلسات غیررسمی روی وایت‌برد پیشنهاد می‌شود. این روش‌ها امکان تغییرات سریع را فراهم می‌کنند و ایده‌ها را واضح‌تر انتقال می‌دهند. ثبت این جلسات با عکاسی و اشتراک آن‌ها در ابزارهایی مانند ویکی نیز پیشنهاد می‌شود تا همه اعضای تیم بتوانند به اطلاعات دسترسی داشته باشند.
علاوه بر این، معماران باید نقش خود را به‌عنوان رهبر بپذیرند و به‌جای پنهان‌کردن تصمیمات از تیم، آن‌ها را در فرآیندهای کلیدی شرکت دهند. این شفافیت باعث می‌شود که تصمیمات معماری اعتبار بیشتری پیدا کنند و همه اعضای تیم (توسعه‌دهندگان، تیم QA، تحلیل‌گران و مدیران پروژه) در جهت اهداف پروژه هم‌سو باشند.


#TIP-04

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

اهمیت ارتباطات و دینامیک‌های بین‌فردی در موفقیت پروژه‌های نرم‌افزاری قابل کتمان نیست و که تکنولوژی به تنهایی معمولاً دلیل شکست‌ها نیست. در اینجا چند نکته کلیدی آمده است:
 
1. مردم به جای تکنولوژی: موفقیت یا شکست یک پروژه معمولاً به دینامیک تیم و نحوه ارتباط آن‌ها بستگی دارد، نه به فناوری خاصی که انتخاب شده است.
    
2. گفتگو به عنوان یک ابزار: برقراری گفتگوهای باز و محترمانه می‌تواند به حل مسائل موثرتر از درگیری‌ها کمک کند. ایجاد محیطی که در آن اعضای تیم احساس شنیده شدن و ارزشمندی کنند، بسیار مهم است.
    
3. مدیریت احساسات: نزدیک شدن به بحث‌ها با ذهنیت آرام و مثبت بسیار حیاتی است. نشانه‌های غیرکلامی می‌توانند تأثیر زیادی بر نحوه دریافت پیام‌ها داشته باشند.
    
4. تعیین اهداف مشترک: همکاری برای تعیین اهداف مشترک می‌تواند تمرکز را از رفتارهای فردی به سمت موفقیت جمعی هدایت کند و همکاری و مسئولیت‌پذیری را تقویت کند.
    
5. فرصت‌های یادگیری: برخورد با چالش‌ها به عنوان فرصت‌هایی برای رشد می‌تواند به بهبود روابط و نتایج بهتر پروژه‌ها منجر شود.
    
 
در نهایت، تأکید بر عنصر انسانی در توسعه نرم‌افزار است، جایی که ارتباطات مؤثر و همکاری می‌تواند اغلب مسائل را که تنها با تکنولوژی حل نمی‌شوند، برطرف کند.

#TIP-03

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

ساده سازی پیچیدگی‌های ذاتی و کم کردن پیچیدگی‌های تصادفی
- پیچیدگی ذاتی، به دشواری‌های ذاتی یک مسئله اشاره دارد که بدون از دست دادن جزئیات مهم نمی‌توان آن را ساده‌تر کرد. برای مثال، کنترل ترافیک هوایی یک کشور به خودی خود یک مسئله پیچیده است، زیرا باید موقعیت دقیق، سرعت، جهت و مقصد هر هواپیما را در لحظه ردیابی کرد تا از برخوردها جلوگیری شود. همچنین، برنامه‌ریزی زمان‌های پرواز و مدیریت تغییرات آب و هوایی هم به پیچیدگی ذاتی این مسئله اضافه می‌شود.
    
- پیچیدگی اتفاقی به بار اضافی اشاره دارد که توسط سیستم‌ها یا چارچوب‌هایی که برای حل پیچیدگی ذاتی ساخته شده‌اند، اضافه می‌شود. در مثال ترافیک هوایی، سیستم‌های قدیمی کنترل ترافیک هوایی یک نمونه از پیچیدگی اتفاقی است. این سیستم‌ها که برای مدیریت پیچیدگی‌های ترافیک هوایی ایجاد شده‌اند، به مرور زمان قدیمی شده و انعطاف‌پذیری خود را از دست داده‌اند، به‌طوری‌که به‌روزرسانی آن‌ها بسیار دشوار شده است و لایه‌های غیرضروری به مشکل اصلی اضافه کرده‌اند.
    
 
گاهی اوقات، توسعه‌دهندگان به دلیل چالش‌برانگیز بودن مسائل پیچیده، به سمت پیچیدگی جذب می‌شوند، اما این میل می‌تواند باعث ایجاد سیستم‌های بیش از حد پیچیده و دارای پیچیدگی اتفاقی شود. چالش برای معماران سیستم این است که چارچوب‌ها و راه‌حل‌هایی را انتخاب کنند که این پیچیدگی اتفاقی را به حداقل برسانند و روی کدی تمرکز کنند که مستقیماً به حل مشکل اصلی کسب‌وکار کمک می‌کند، نه اینکه ساختار را با راه‌حل‌های بی‌جهت پیچیده کنند.
 
برای دستیابی به این هدف، توصیه‌ها عبارتند از:
 
1. انتخاب چارچوب‌هایی که در عمل موثر بودن خود را اثبات کرده‌اند به جای طرح‌های نظری صرف.
2. ارزیابی درصد کدی که فقط به ارتباط بین کاربر و سیستم می‌پردازد و مستقیماً مشکل اصلی را حل نمی‌کند.
3. با دقت انتخاب کردن راه‌حل‌های ارائه شده توسط فروشندگان، زیرا این راه‌حل‌ها گاهی بیشتر پیچیدگی اتفاقی را افزایش می‌دهند تا اینکه آن را برطرف کنند.
 
در نهایت، وظیفه معمار سیستم این است که پیچیدگی‌های ذاتی را به‌درستی مدیریت کند و از افزودن پیچیدگی اتفاقی جلوگیری کند تا راه‌حل‌های بهینه، قابل نگهداری و انعطاف‌پذیر ایجاد شوند.
 
"پیچیدگی ذاتی در هر مسئله وجود دارد، اما پیچیدگی اتفاقی از راه‌حل‌های اضافه و غیرضروری ناشی می‌شود. وظیفه معماران سیستم این است که بدون افزودن پیچیدگی غیرضروری، راه‌حل‌هایی ساده و کارآمد برای مسائل پیچیده طراحی کنند."
#TIP-02

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

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

‎#TIP-01

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

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

* بخشی از مستند زیبای «تهران انار ندارد»
〰️〰️〰️〰️〰️〰️
© @microfrontend_ir

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

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

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

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

۳. تحلیل متن و زبان: استفاده از پردازش زبان طبیعی برای تحلیل محتوای رسانه‌های اجتماعی و سایر منابع متنی.

۴. مطالعه دینامیک‌های اجتماعی: بررسی چگونگی گسترش اطلاعات، ایده‌ها و رفتارها در جوامع.

۵. سیاست‌گذاری مبتنی بر شواهد: استفاده از داده‌های بزرگ برای تصمیم‌گیری‌های سیاسی و اجتماعی.

۶. بررسی افکار عمومی: تحلیل نظرات و دیدگاه‌های مردم در مقیاس وسیع.

۷. پیش‌بینی روندهای اجتماعی: استفاده از الگوریتم‌های یادگیری ماشین برای پیش‌بینی تغییرات اجتماعی.

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

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

برخی از نتایج و کاربردهای این تحلیل عبارتند از:

1. شناسایی رهبران کلیدی: با تحلیل مرکزیت در شبکه، افرادی که نقش محوری در انتقال اطلاعات و هماهنگی عملیات داشتند، شناسایی شدند.

2. درک ساختار سلسله مراتبی: تحلیل شبکه نشان داد که FARC علیرغم ظاهر غیرمتمرکز، دارای ساختار سلسله مراتبی مشخصی است.

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

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

5. تأثیر بر استراتژی‌های مقابله: این تحلیل‌ها به نیروهای امنیتی کمک کرد تا استراتژی‌های مؤثرتری برای مقابله با گروه طراحی کنند.

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

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

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

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

لینک Generative AI for Software Development
@reza_jafari_ai

من میلاد حاتمی، برنامه نویس از سال 2008، قصد دارم به علاقمندان یادگیری طراحی سایت، به صورت خصوصی جنگو آموزش دهم.
🎯در صورتی که من مربی خصوصی جنگو شما بصورت آنلاین باشم:
⚡️یک اینترنت پر سرعت نیاز دارید.
✅قبل از شروع اولین جلسه به صورت رایگان:
⚡️با سوالاتی ساده، سطح مهارت شما در جنگو را ارزیابی می کنم.
⚡️به سوالات شما در مورد سرفصل ها پاسخ می دهم.
⚡️در صورت تمایل شما، با هم یک پروژه برای آموزش مشخص می کنیم.
⚡️در مورد هزینه، تعداد جلسات، ساعت آموزش و… صحبت می کنیم.
✅در طول جلسه :
⚡️نکات کاربردی را به شما یاد می دهم.
⚡️آموزش یکطرفه نخواهد بود و شما هم بعضی مواقع کد می نویسید و با چالش هایی مواجه خواهید شد.
⚡️با برخی ابزارهای کنترل سورس نظیر github آشنا خواهید شد.
⚡️با روش صحیح جستجوی سوالات برنامه نویسی در سایت های معتبر آشنا می شوید.
⚡️شما مجازید یک میلیون سوال بپرسید 🙂
✅بعد از هر جلسه:
⚡️با هم آموزش را مرور می کنیم.
⚡️در صورت لزوم به شما تمرین می دهم.
⚡️نظر شما را جهت بهتر شدن جلسه بعدی می پرسم.
⚡️در مورد جلسه بعدی برنامه ریزی می کنیم.
جهت ارتباط با من با @miladhzz در ارتباط باشید

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

شما دیزاین پترن محبوبتون کدوماست؟

Tweet Link: https://x.com/hemn_hp/status/1828808242862215483?t=fRTVRVsajVzf0f4n_2MEmw&s=19

Design Patterns PlayList:
https://www.youtube.com/playlist?list=PLJ9zDGwhhsBxUIWhfp9euGlbBIrQUhm2Q

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

در روزهای آینده برمی‌گردم به پلی لیست Go و تا آخر شهریور تمومش کنم!

در این ویدیو از پلی لیست آموزش جنگو و نکته‌ها و ترفند‌های آن به بررسی مفهوم Django Custom Field پرداختیم. ابتدا نوع داده JSONB Array در پستگرس را با یک مثال شرح دادم و سپس یک کاستوم فیلد نوشتیم که بتوان این نوع داده را ذخیره و بازیابی کنیم. سپس یک Custom lookup هم نوشتیم که بتوان داده ها را فیلتر کرد.


** در این ویدیو اساسا دنبال آموزش خاصی نبودم و دنبال این بودم که ترغیبتون کنم در تله آموزش نیافتید و شروع کنید به خوندن کد خود جنگو که بهترین منبع مستر شدنه :)

Video Link: https://youtu.be/I0Ry63LO-Rg

** پلی لیست نکته ها و ترفندهای جنگو:
https://www.youtube.com/playlist?list=PLJ9zDGwhhsBwdrfdaoOqbYev3_ocuBOfv

** کلاس آنلاین آموزش جنگو
https://www.youtube.com/playlist?list=PLJ9zDGwhhsByH5tcpM9H3VzdHYpne3bSa
〰️〰️〰️〰️〰️〰️
© @microfrontend_ir

برای یک مساله‌ای من نیاز به یک کاستوم فیلد جنگو داشتم که از نوع jsonb[] پشتیبانی کنه. دیدم بد نیست که یک ویدیو هم ازش بسازم. رو این حساب اول یک مقدمه‌ای بر jsonfield جنگو گفتم و تو ویدیو بعدی که شنبه منتشر خواهد ساخت کاستوم فیلد رو توضیح خواهم داد.

پلی لیست آموزش Go رو هم از دوشنبه ادامه می‌دم.

Django Json Field
سال‌هاست که ذخیره سازی داده‌ها به شیوه رابطه‌ای بهترین و رایج ترین شیوه ذخیره سازی است با این وجود در سال‌های اخیر و با معرفی مفهوم NoSQL شیوه‌های دیگری نیز مطرح شده اند که پرکاربردترین آنها Document یا ذخیره داده به شکل JSON است. ابزارهای مختلفی مانند mongodb در این فضا رشد کرده‌اند اما امروزه اغلب دیتابیس‌های رابطه‌ای به شما امکان ذخیره و بازیابی این نوع از داده‌ها را می‌دهند و شاید بتوان گفت بهترین آنها PostgreSQL است. در این ویدیو ابتدا شیوه‌ اجرای پستگرس از طریق داکر را شرح دادیم و سپس با اتصال به آن یک دیتابیس و یک جدول ساختیم که بتوان داده‌های JSON را نیز در آن ذخیره کرد. سپس همان رویکرد را بر روی جنگو و با استفاده Django Json Field پیاده سازی کردیم و چند مثال از query داده‌ها را بررسی کردیم.

Video Link: https://youtu.be/aVahpcJQ8tE

** پلی لیست نکته ها و ترفندهای جنگو:
https://www.youtube.com/playlist?list=PLJ9zDGwhhsBwdrfdaoOqbYev3_ocuBOfv

** کلاس آنلاین آموزش جنگو
https://www.youtube.com/playlist?list=PLJ9zDGwhhsByH5tcpM9H3VzdHYpne3bSa
〰️〰️〰️〰️〰️〰️
© @microfrontend_ir

در قسمت هشتم از آموزش برنامه نویسی به زبان GO نوع داده struct و کاربردهای آن را بررسی کردم. برای تعریف نوع جدید در زبان گو از کلمه کلیدی type استفاده می کنیم که دو کاربرد مهم دارد. نخست برای ایجاد alias برای نوع‌های موجود که اسم معناداری را به نوع‌ها می‌توان اختصاص داد و کاربرد دوم تعریف نوع داده جدید است. در این ویدیو تعریف نوع داده struct و ویژگی‌های آن را شرح دادیم و سپس با یک مثال شیوه فراخوانی سرویس‌های REST و ذخیره نتایج در نوع struct را توضیح دادیم. در نهایت مفاهیم Alignment and Padding و اهمیت آنها در مدیریت حافظه را بررسی کردیم.

Link: https://youtu.be/ndJS2XP_hRU

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

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

در قسمت هفتم از آموزش GO نوع داده map و نکته‌های آن را بررسی کردیم. ابتدا ضرورت وجود این نوع داده و شیوه تعریف و استفاده از آن را شرح دادیم. سپس ساختار داخلی آن را بررسی کردم. در گو هم به مانند سایر زبان‌های برنامه نویسی از hash table برای پیاده سازی استفاده شده است. دراین زبان داده‌ها در مجموعه‌ای از Bucket ها که به فراخور نیاز رشد می‌کنند ذخیره می‌شود. دو مورد مهم که بایستی در استفاده از map به آن دقت کنیم را با مثالی شرح دادم. ابتدا این مورد را که با همان رشدی که map در استفاده از حافظه دارد، در زمان پاک کردن آیتم ها باکت‌ها حذف نمی‌شوند و GC این کار را بر عهده خواهد گرفت و همچنین اینکه اگر سایز تخمینی برای map تعریف کنیم بهینه‌تر خواهد بود.


Link: https://youtu.be/4bxlgFFt8m4

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

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

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

در قسمت ششم از آموزش GO کار با Slice و نکته‌های آن را بررسی کردیم. ابتدا تعریف متغیر از نوع اسلایس و ساختار آن در مموری را شرح دادیم. هر متغیر slice در واقع شامل یک هدر یک آرایه است. در هدر جزییات و مشخصات دیتا تعریف و داده‌ها در درون آرایه ذخیره می‌شود. سپس دستور make که به ما امکان تعریف اسلایس اما با کنترل بیشتر بر روی هدر می دهد را توضیح دادیم. برای رسیدن به پویایی یعنی اضافه کردن آیتم به اسلایس را از طریق دستور append توضیح دادم. یکی از جذابیت‌های اسلایس این است که می‌توان از یک آرایه یا اسلایس دیگر به عنوان دیتای اصلی استفاده کنیم. این رویکرد هم انعطاف بالایی به اسلایس می‌دهد و هم ممکن است چالش ‌هایی را به وجود بیاورد که سعی کردیم این چالش ها را بررسی کنیم و در نهایت استفاده از حلقه for range برای پیمایش عناصر اسلایس و نکته‌های مهمی در استفاده از آن را مطرح کردم.



Link: https://youtu.be/Mlp1aPtFCnY

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

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

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

Link: https://youtu.be/VGC2AjSTYfQ

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

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

در قسمت چهارم از آموزش GO به بررسی انواع داده در زبان گو پرداختیم. در گو Data Type های مختلفی وجود دارد که اساسی ترین آنها Built-in Type ها یعنی اعداد، رشته و بول است. ابتدا نوع داده رشته‌ای را تشریح و چالش‌های آن بویژه در تغییر و مقایسه آنها را توضیح دادم. بعد از نوع داده بول به بررسی انواع عددی و ویژگی‌های آن‌ها بویژه مفهوم Overflow پرداختیم.

Link: https://youtu.be/Tyifao9VwNU

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

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

در قسمت سوم از آموزش Go به معرفی مفهوم const و تعریف آن پرداختیم. ابتدا مفهوم literal در زبان‌ها برنامه نویسی را شرح و سپس از معایب Implicit Conversion صحبت کردیم و در نهایت شیوه تعریف const در golang را شرح دادیم. در زبان گو دو نوع const وجود دارد. نوع اول بدون نوع است و میتواند در زمان استفاده نوع خود را دریافت کند و به برنامه نویس امکان implicit conversion می دهد و نوع دوم ثابت های نوع دار هستند که نوع آن ها قابل تغییر نیست.



Link: https://youtu.be/rJoYcSPlmoY

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

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

تو این قسمت یه تشری به جاوا اسکریپت زدم و گفتم 1+'1' کار می‌کنه و عملکردی متفاوت از 1-'1' دارد. اما آیا این دستورات رو تو Go امتحان کردید؟
آنچه در قسمت بعدی خواهید دید 🙂

در قسمت دوم از آموزش Go ابتدا به بررسی Type System گو پرداختیم و سپس شیوه تعریف متغیر را در این زبان توضیح دادیم. در نهایت مقدمه‌ای داشتیم بر پوینتر و reflection در این زبان برنامه نویسی.



Link: https://youtu.be/Pq-CHQjODvM

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

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