در این قسمت از سری پادکست‌های Code lodge، به بررسی عمیق نقش هوش مصنوعی در دنیای توسعه نرم‌افزار می‌پردازیم. در این گفتگو، همراه با دوست صمیمی‌مان، مسعود عزیز، به نقد جنبه‌های مختلف استفاده از AI در محیط‌های دولوپمنت می‌پردازیم؛ از جمله مباحث پیرامون نگرانی‌های مرتبط با اتوماسیون بیش از حد و جایگزینی نیروی انسانی و دست کم گیری نقش مهم مدل های زبانی در توسعه. هدف ما ارائه بینشی جامع از چالش‌ها و فرصت‌هایی است که هوش مصنوعی برای توسعه‌دهندگان به ارمغان می‌آورد و راهکارهایی برای حفظ کیفیت و خلاقیت در کار ارائه می‌دهد.
میزبانان شما:
⁠بهنیا آزاد⁠
⁠مسعود بیگی⁠

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

- 🔗Spotify

- 🔗Amazon

- 🔗Castbox

-🔗Apple podcast

-🔗 Shenoto


#Codelodge
#Software
#AI
#LLM
#softwareDeveloper
#SoftwareEngineer
@codeLodge

خیلی از زمان ها لازم میشه سلامت یک کابل رو تست کنیم.قطعا مطمئن ترین راه می تونه بررسی کابل با ابزار های تست های موجود باشه ، اما اگر برای مثال تجهیزات ما داخل دیتاسنتر یا مکانی باشه که دسترسی بهش به راحتی ممکن نیست چه راهی رو داریم ؟ اینجاست که تست TDR مطرح میشه.

بطور کلی از TDR یا Time-Domain Reflectometer برای بررسی و پیدا کردن خطا در metallic cables استفاده میشه (برای مثال کابل های شبکه یا coaxial ) .

نکات مهم قابل توجه قبل از اجرا تست :

وقتی که این تست رو برای یک interface اجرا کنید ، برای حدود 5 الی 7 ثانیه interface موردنظر از دسترس خارج میشه ، پس اگر بصورت remote متصل هستید و این تست رو برای یک interface مربوط به مثلا آپلینک اجرا کنید بطور کلی اتصال شما قطع خواهد شد.

این تست بصورت محدود تغییراتی در POE هم ایجاد میکنه ، پس اگر به interface یک دستگاه متصل هستش که از POE استفاده میکنه ، ممکنه خاموش / روشن بشه.

پورت مورد نظر رو هنگام اجرای تست TDR تغییر ندید.

اگر پورت در حال اجرای تست TDR رو به یک پورت Fast Ethernet وصل کنید، جفت سیم‌های غیر فعال (4-5 و 7-8) به عنوان معیوب گزارش می‌شن، چون سر دیگر کابل این جفت‌ها رو خاتمه نمی‌ده (پشتیبانی نمیشه)

به دلیل ویژگی‌های کابل، بهتره تست TDR رو چندین بار اجرا کنید تا نتایج دقیقی به دست بیارید.

در طول تست، وضعیت پورت (مثل جدا کردن کابل از هر دو سر) رو تغییر ندید، چون ممکنه نتایج نادرست بشه.

هدف TDR اینه که بفهمه کابل چقدر بد کار می‌کنه، نه این که کابل معیوب رو پیدا کنه.

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


- دستورات موردنیاز برای اجرا تست TDR :

در قدم اول دستور زیر رو اجرا کنید و بجای <interface> اسم interface موردنظر رو قرار بدید :
test cable tdr interface <interface>

5 الی 7 ثانیه صبر کنید و سپس این دستور رو اجرا کنید :
show cable tdr interface <interface>

- روی همه دستگاه ها این تست اجرا میشه ؟

نسخه IOS دستگاه نیازه بالاتر از 12.2 باشد.پشتیبانی این تست در سوئیچ های سیسکو به این شکل هستش :
Model / TDR Support

2960 / Yes *

2960G / Yes

2960S / Yes

2918 / Unknown

2350 / Unknown

2360 / Unknown

2975 / Unknown

3560 / No

3560G Yes

3560E-3560X / Yes

3750 / No

3750G / Yes

3750E-3750X / Yes

Nexus 2K / Unknown

Nexus 5K / Unknown

Nexus 7K / Yes *

Sup7E-X4548 / Yes
همچنین در اکثر دستگاه های خانواده 9000 هم پشتیبانی میشه اما با توجه به مدل آنها کیفیت تست متفاوت هستش.

سوییچ 2960 از تست TDR در هر دو نوع پورت FastEthernet و GigabitEthernet دوحالته پشتیبانی می‌کنه، اما وقتی این تست روی پورت FastEthernet اجرا بشه، فقط دو جفت اول، یعنی جفت‌های A و B، تست می‌شن. به دلایل مشخص، جفت‌های C و D در پورت‌های غیر GigabitEthernet تست نخواهند شد.

به‌جز مدل WS-C2960-48PDL، هنگام استفاده از پورت GigabitEthernet  در سوییچ Catalyst 2960، باید قبل از اجرای تست، به‌صورت دستی نوع اینترفیس رو با استفاده از فرمان "media rj" روی حالت Copper تنظیم کنید.

مدل‌های ساده (یا پورت‌های غیر GigabitEthernet مسی) 3560 و 3750 قبل از سوییچ 2960 عرضه شدن. تراشه مربوط به تست TDR در طراحی سوییچ 2960 گنجانده شد. زمانی که Cisco مدل‌های 3560G و 3750G رو عرضه کرد، تصمیم گرفته شد که ویژگی TDR به‌صورت استاندارد در این مدل‌ها وجود داشته باشه. بنابراین، مدل‌های ساده 3560 و 3750 تنها سری‌هایی هستن که قابلیت TDR رو ندارن.

🎯 الگوریتم‌های مسیریابی در شبکه (Distance Vector و Link State)
یکی از کارهای اصلی لایه شبکه، پیدا کردن بهترین مسیر برای رسیدن داده‌ها از مبدأ به مقصد هست. این کار با کمک الگوریتم‌های مسیریابی انجام می‌شه، مخصوصاً وقتی با چند روتر طرفیم.

📌 دو الگوریتم اصلی توی این زمینه داریم:
🔹الگورتیم  Distance Vector
🔹الگوریتم Link State

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

🛰 الگوریتم Link State  چیه؟ یه سیستم دقیق و باهوش
اینجا ماجرا فرق می‌کنه. هر روتر مثل یه شهره که به یه سیستم ماهواره‌ای وصله و نقشه‌ی لحظه‌ای از کل کشور داره. همه‌چی رو می‌دونه:
کی با کی وصله، کیفیت لینک‌ها چطوره، کجا قطعی هست و...
این اطلاعات با بسته‌هایی به اسم LSA بین همه پخش می‌شه و هر روتر خودش بهترین مسیرها رو محاسبه می‌کنه (با الگوریتم Dijkstra). سریع، دقیق و مناسب برای شبکه‌های بزرگ.

هر روتر اطلاعات دقیقی از اتصال‌های مستقیم خود (مثل اینکه به کدام روترها متصل است و کیفیت آن لینک‌ها چگونه است) را در قالب بسته‌هایی به نام LSA Link State Advertisement به تمام روترهای دیگر می‌فرستد. این اطلاعات به‌صورت فراگیر پخش می‌شود تا همه روترها تصویری یکسان از ساختار شبکه داشته باشند. پس از آن، هر روتر با استفاده از الگوریتم دایکسترا مسیرهای بهینه به همه مقصدها را محاسبه می‌کند.

اگر معاشرت با دیگران تو را آزرده می‌کند، همیشه قدری از تنهایی ات را با خود به جمع ببر. 
یعنی بیاموز آنچه می‌اندیشی را فوراً ابراز نکنی،
چیزی که می‌شنوی را زیاد جدی نگیری و از دیگران بیش از اندازه انتظار نداشته باشی.

در باب حکمت زندگی
آرتور شوپنهاور 

VTP Version 3

در واقع VTP نسخه 3 دارای بسیاری از ویژگی ها و پیشرفت های مهم نسبت به نسخه 1 و 2 است مانند:

از دامنه گسترده VLAN (VLANs 1006 تا 4094) در اعلان پشتیبانی می نماید. V1 و V2 فقط با VLAN های 1 تا 1005 کار می کنند.
از VLAN های خصوصی پشتیبانی می کند (vlan خصوصی تکنیکی است برای پارتیشن بندی یک VLAN واحد به ‘sub-VLAN’ های مجزا).
از اعلان برای اطلاعات Multiple-Spanning-Tree (MST) پشتیبانی می نماید.
از احراز هویت پیشرفته پشتیبانی می کند. رمزهای عبور را می توان به صورت secret یا مخفی و hidden تنظیم نمود.
از گزینه خاموش کردن VTP پشتیبانی می کند. در V1 و V2 فقط می توانید VTP را در حالت transparent تنظیم کنید اما نمی توانید آن را به طور کامل خاموش کنید.
کنترل بیشتری بر پایگاه داده VLAN از طریق مفهوم سرور اولیه VTP و سرور ثانویه VTP دارا می باشد. در این نسخه مشکل بازنویسی ویرایش “revision overwrite” را که در VTP نسخه 1 و VTP نسخه 2 وجود دارد، حل می کند. حتی اگر یک سوئیچ خارجی به عنوان یک سرور VTP با همان دامنه/رمز عبور و شماره نسخه بالاتر به شبکه متصل شود، پایگاه داده VLAN را بازنویسی نمی کند چراکه این مزیت های سرور اصلی VTP را نخواهد داشت (این مزیت ها به صورت دستی توسط مدیر شبکه اعطا می شود).

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

این نکته رو هم اضافه کنم که همچنان میتونید از طریق ربات کانال با ما در ارتباط باشید.

بعد از یک تایم دوری از داکر و کانتینر و اینجور داستانا
دوباره شروع کردم ، انصافا خیلی حال میده ،
فعلا دارم با کتاب Docker Deep Dive گرم میکنم
بریم ببینیم چی میشه...😉

سلام دوستان ، امیدوارم حالتون خوب باشه😊
از اونجایی که خیلیا دوست دارن یاد بگیرن اما وقت نمیکنن کتاب بخونن🫤
گفتم بیام هر کتاب رو فصل به فصل خلاصه کنم و نکته های کلیدیش رو براتون اینجا قرار بدم 🤩🥳
اونوقت چه اتفاقی میوفته؟ هم من موشکافی کردم کتاب رو بیشتر فهمیدم ، هم شما به صورت کلی متوجه میشید موضوع چیه و کتاب چی میگفته😉🤓
اسم این کارو هم میزارم "کتاب زیر ذره بین"📕🔍
تا کی این داستان ادامه پیدا میکنه؟ تا هر موقع که حوصلم بکشه😅
از همین کتاب اخیری که دوباره دارم میخونم هم شروع میکنم : Docker Deep Dive
امیدوارم به کارتون بیاد!!!
بریم ببینیم چی میشه😎

کتاب زیر ذره بین📕🔍

Docker Deep Dive - Chapter 1 Episode 1

قدیما ، معمولا میومدن هر اپلیکشن رو ، روی یک سرور نصب میکردن ، یعنی هر سرور میرفت برای یک اپلیکیشن ، گاهن خیلی هم اطلاعی از این که یک اپلیکشن چقدر منابع برای اجرا شدن نیاز داره نداشتن ، پس در نتیجه میرفتن خفن ترین مدل سرور رو میگرفتن و کلی هزینه رو دست شرکت میزاشتن ، و تازه ، ممکن بود اصلا اون اپلیکشن بیشتر از 5 تا 10 درصد منابع سرور رو هم استفاده نکنه 🫤

اینجا بود که VMware شنل قهرمانانش رو تن کرد و تو عرصه ی IT ظهور کرد🦸🏻. حالا دیگه بازی عوض شد ، دیگه نیازی نبود هر بار شرکت به اپلیکیشن جدید نیاز داره بره سرور تهیه کنه ، دیگه میتونه روی هر سرور ماشین های مجازی با منابع مختص به خودش رو ایجاد کنه و دیگه قرار بود منابع و هزینه هدر نره چون منابع رو بین ماشین ها تقسیم میکرد😍 بهتر از این نمیشه ... اما ، و همیشه یک اما وجود داره ، امایه داستان اینه که حالا هر VM نیاز به سیستم عامل خودش رو داره ، هر سیستم عاملی منابع CPU و RAM خودش رو میخواد ، هر سیستم عامل باید جدا جدا مانیتور میشد و هر سیستم عامل لایسنس خودش رو میخوادووووووو
گذشت و گذشت تا گوگل شروع به استفاده از تکنولوژی کرد به عنوان کانتینر ، تفاوتش با VM چی بود؟ کانتینر ها نیازی به سیستم عامل مجزا ندارند ، همین موضوع باعث میشه کلیییی از منابع سخت افزاری سیو بشه .🤗

کانتینر های مدرن از روی لینوکس شروع به کار کردن ، و به لطف Google LLC ، بسیاری از فناوری‌های مرتبط با کانتینر را به هسته لینوکس ارائه داد. و ویندوز هم کلی سخت کارکرد که بحث کانتینر هارو روی ویندوز هم بیاره🙂‍↔️اما با همه ی تلاشش ، وقتی شما از داکر دسکتاپ ویندوز استفاده میکنی ، تقریبا همون حسی رو میگیری که با داکر روی لینوکس کار میکنی.

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

حالا داکر این وسط از کجا اومد؟ اینم یک شرکتی بود که اومد ساخت کانتینر ها رو مدیریت و راحت کرد .
کوبرنتیز چی میگه این وسط؟ این یک ابزاره که باهاش میایم کانتینر هارو توسعه و مدیریت میکنیم. (میرسیم بهش)

#بررسی_کتاب

ببینید دوستان ، لینوکس در واقع یک کرنل هست ، که کارش مدیریت منبع سخت افزاری و باقی داستانه ، اینو تروالدز نوشته ، و به این کرنل میگیم لینوکس ، حالا یکسری پکیج و کتابخونه و اینا میاد رو این کرنل سوار میشه و باهاش تعامل میکنه ، که میشه توزیع های لینوکس ، که هرکدوم بسته به سلیقه و مدلشون ، یک جوری دارن از کرنل استفاده میکنن ، که یکیش میشه Ubuntu ، یکیش میشه CentOS ، یکیش میشه Debian و الی آخر ، از روی هر توزیع هم ، معمولا توزیع های دیگه رو میدن بیرون ، که درواقع بیس همونه ، اما یکسری تغییرات دادن و به اسم خودشون ثبت میکنن و انتشار میدن ، قدرت متن باز بودن اینجاست که شما یک کرنل داری که متن بازه ، میتونی بسته به سلیقه ی خودت تغییرش بدی ، یک توزیع داری که اینم متن بازه و اینم میتونی به سلیقه ی خودت تغییر بدی ، فقط کافیه زبان برنامه نویسی مناسب به خودش رو بلد باشی ، معمولا غول های کرنل لینوکس ، مسلط به زبان C هستند ، که واقعا توی استفاده از این زبان استادن

به عنوان یک تجربه ی شخصی خدمتتون عرض کنم ، توی صنف های دیگه نمیدونم این موضوع هست یا نه ، اما توی صنف IT ، اگه به یک موضوع جدیدی رسیدید یا یک راهکار نوینی رو پیدا کردید که داخل شرکتتون تاحالا پیاده سازی نشده بود ، قبل از اینکه اعلامش کنید و جار بزنید ، بدون اینکه خودتون بلدش باشید یا مطالعه ی کافی در موردش کرده باشید ، حتما یکبار تلاش کرده باشید پیادش کنید و به نتیجه ی مطلوبی برسید ، و نتیجه ای که خودتون بدست آوردید رو اعلام کنید .
چرا؟
چون دوحالت داره ، اگر خیلی خفن و کاربردی باشه ، همیشه یکسری سارق فنی هستند ، که منتظرن یکی یچیزی رو بگه ، سریع میرن ته توشو درمیارن ، بعدم به اسم خودشون ثبت میکنن و حسابی به به و چه چه برا خودشون درست میکنن😏
یااااا ، خودتون رو توی یک دام بزرگی میندازید ، که یک مسئولیت الکی بهتون داده میشه ، فردا هم میشه وظیفه و حالا بیا و درستش کن.🤦‍♂️

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

نکته ؛ اگر خیلی ایدتون خفن بود ، دست بجنبانید ، چون شما اجراش نکنید ، یکی دیگه انجامش میده و باقی ماجرا که خودتون میدونید!!!😉

کتاب زیر ذره بین📕🔍

Docker Deep Dive - Chapter 1 Episode 2

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

خب بریم کمی در مورد خوده داکر هم نکته هایی رو بگیم ، اول از همه ، داکر توسط یک دولوپر آمریکایی-فرانسوی به اسم Solomon Hykes توسعه پیدا کرد .
داکر یک نرم افزاری هست که روی ویندوز و لینوکس اجرا میشه ، کارش ایجاد و مدیریت کانتینر هاست .
اسم داکر از اصطلاح British به معنای Dock worker گرفته شده که به معنای کسی بوده که کانتینر هارو از کشتی ها خارج میکرده یا بار میزده، در نهایت هم سال 2013 تصمیم گرفتن اسم کمپانی رو به همون Docker تغییر بدن. و کاملا موفقیت آمیز تونستن بحث داکر و کانتینر هارو جزو جریان های مهم دنیای IT کنن.😎
خیلی از افراد وقتی در مورد داکر صحبت میکنن ، تصورشون تنها اجرای کانتینر هاست ، اما پشت پرده ی این تکنولوژی چخبر هست؟
کتاب اینجای داستان ، اومده داکر رو به سه قسمت runtime , daemon , orchestrator تقسیم کرده که ما توی این قسمت runtime رو طبق کتاب توضیح میدیم.

توی بحث اجزای داکر ، ما لول بندی داریم ، هرچی عملیات نزدیک به کرنل باشه و ارتباط مستقیمی با کرنل داشته باشه ، پیچیدگی کمتری داره ، و کار ها و وظایف مشخص تری رو به انجام میرسونن ، اصطلاحا به این عملیات ها ، low-level میگن و در مقابل هرچی عملیات با کرنل رابطه ی غیر مستقیم تری داشته باشه ، معمولا پیچیده تره و چندین وظایف مختلفی رو به انجام میرسونi که اصطلاحا به این عملیات ها high-level

الان runtime جزو هردو دسته هست ، کارش چیه؟ استارت و استاپ کانتینر ها در لول پایین و مدیریت کانتینر ها در لول بالا🙂
تو لول پایین جزئی وجود داره به اسم runc که تنها وظیفش ساخت کانتینر هست⬇️
تو لول بالا هم جزئی وجود داره به اسم containerd که وظیفه ی مدیریت کانتینر رو به عهده داره .⬆️
به همین سادگی نیست ، تو قسمت بعدی توضیحات مفصل تری میدم.
#بررسی_کتاب

به بخش Runtime توجه فرمایید!

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

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