Microfrontend.ir
Статистикаکانال تلگرامی وبلاگ میکروفرانتاند. مباحثی پیرامون هوش مصنوعی و یادگیری ماشین، معماری نرم افزار با تمرکز بر DDD ، میکروسرویس و میکروفرانتاند www.microfrontend.ir @hemanhp2
- Последний пост
- 10 авг.
- Последнее чтение
- 15 авг.
- Постов за неделю
- 3
- Всего постов
- 20
- Тип
- открытый
- Язык
- персидский
- Категория
- Блоги
- В каталоге с
- 13 авг.
- 1/24сутки в ленте
- 315
- 1/48двое суток
- 360
- 1/72трое суток
- 389
Оценка по просмотрам недавних постов: пост набирает почти всё за первые сутки.
Посты
видео или голосовое, без подписи
видео или голосовое, без подписи
قبلنا خیلی با قیاس مغز و سی پی یو مشکل داشتم و برداشتم این بود که اساسا قیاس درستی نیست. مغز را نمیشد با یک پردازنده مقایسه کرد؛ چون مغز برای من چیزی فراتر از یک سیستم محاسباتی بود: پیچیده، پویا، یادگیرنده و بهنوعی نامتناهی. با بالاتر رفتن سنم این قیاس بیشتر برام قابل درک شد. نه اینکه حالا فکر کنم مغز یک CPU بزرگ و پیچیده است. اتفاقاً برعکس. به نظرم نکتهی مهم این است که محدودیت، بخش جداییناپذیر هر سیستم هوشمند است. شاید مسئله این نیست که مغز را به یک کامپیوتر تقلیل بدهیم؛ مسئله این است که ببینیم چه چیزهایی در هر سیستم محدودِ محاسباتی، برای تصمیمگیری و حل مسئله مشترکاند.شاید هوش، برخلاف چیزی که گاهی تصور میکنیم، از نامحدود بودن نمیآید؛ بلکه از توانایی تصمیمگیری در میان محدودیتها میآید. هر روز بحث میکنیم که چه چیزی را کش کنیم، کی کش رو پاک کنیم، کی باید از بهینه سازی دست برداریم و مواردی از این دست. وقتی سعی کنیم در زندگی انسانی چنین تصمیمهایی بگیریم کمتر سراغ الگوریتم میرویم. این کتاب دعوتی است برای حل مسایل روزمره زندگیمون به کمک الگوریتمهایی که پیشتر باهاشون مسایل کامپیوتریمون رو حل کردیم.
اخیرا از این دوره مکتب خونه واقعا لذت بردم https://maktabkhooneh.org/course/خلاقیت-نوآوری-مهندسی-mk550
اخیرا از این دوره مکتب خونه واقعا لذت بردم https://maktabkhooneh.org/course/خلاقیت-نوآوری-مهندسی-mk550
تازه شروعش کردم ولی به نظر باحال میاد Your Code as a Crime Scene, Second Edition Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs
این کتاب با نگاهی مهندسی، مفاهیمی مثل Prompt Chaining، Tool Use، Multi-Agent Collaboration، Memory و Guardrails را با مثالهای عملی و مبتنی بر فریمورکهایی مثل LangChain، CrewAI و Google ADK توضیح میدهد. اگر به آینده طراحی سیستمهای مبتنی بر LLM و ساخت AI Agentهای Production-Ready علاقهمندید، مطالعه این کتاب میتواند دید ساختاری و مهندسی ارزشمندی به شما بدهد.
این ریپو سعی میکنه کانفیگهای مختلف رایگان رو جمع کنه و به شکل سابسکریپشن آپدیت کنه و ارائه بده https://github.com/Epodonios/v2ray-configs/
«در هردوسو نشستهاند بر طبل جنگ میکوبند، یکی با عَلَم غرور و هویت، دیگری با کُتَل آزادی و مکنت. هر دو نامِ مردم را به ودیعه میگیرند. اگر وحشتِ قرن بیستم به تجربهی نیهلیسم و فاشیسم برمیگشت، این قرن به تمام امراض قرون گذشته، گسترش بیمرزِ پوپولیسم را هم هدیه داده است. مینویسم پوپولیسم و میخوانم: به نام عوام و به کام خواص. «گزارش شهر محصور» یکی از مهمترینهای شعرهای قرن گذشته است در باب جنگ. بسیار از آن نوشتهاند. هربرت، این محاصره را، محاصرهای ابدی میداند. در این محاصرهی ابدی، قربانیان، همیشه فرودستاناند. در شعری دیگر، این شاعر بزرگ لهستانی مینویسد: آنها که بالای جایگاهها نشستهاند، همهچیز را میدانند. آری، آنها میدانند که در نتیجهی جنگ، در نتیجهی ویرانی، چیز چندانی از دست نخواهند داد و فقط تقدیر تهیدستان (مالکان ابدی ویرانهها) است که بر ترازوهاشان، سبکسنگین میشود: چند کشته اینجا، چند کشته آنجا، همین و بس. از سیاستِ کلاسیک، از سیاستِ صندوقهای مضحکِ رای انتظارِ دیگری نمیرود. سیاستِ حقیقی اما، در عرقِ جبینِ کارگران است، در خشمِ سرخِ مادران، در کوچههایی که رویاهاش، ضمانِ فسخِ تمامِ تاریخهای مقدر است.»
видео или голосовое, без подписи
https://www.linkedin.com/posts/parham-abbasi-498365338_building-an-ml-pipeline-to-predict-hourly-activity-7401993352445112320-bwTu?utm_source=share&utm_medium=member_ios&rcm=ACoAAA09fE0BB-0-I-cBT8WF8sIaGJJALQOkg-8
https://www.linkedin.com/posts/hemanhosseinpana_go-golang-softwareengineering-activity-7392116053247537152-1_Un?utm_medium=ios_app&rcm=ACoAAA09fE0BB-0-I-cBT8WF8sIaGJJALQOkg-8&utm_source=social_share_send&utm_campaign=copy_link
باید پذیرفت که جنگ قاعده تاریخ و صلح استثنای بشر است، در نگاه اول تلخ و ناامیدکننده به نظر میرسد، چرا که مرور تاریخ بشری اغلب با فتوحات، درگیریها و خونریزیها همراه بوده و دورههای صلح به نظر میرسد تنها نقطههای روشن و گذرایی در این تاریکی بیپایان بودهاند. اما همین "استثنا" بودن صلح، خود نشان از ارزش بیبدیل و جایگاه رفیع آن دارد؛ چیزی که کمیاب است، گرانبهاست. هرچند تحقق صلح دشوار است و به تلاش، گفتوگو و اراده جمعی نیاز دارد، اما هر دوره صلح در تاریخ، گواهی بر این حقیقت است که انسانیت قادر به عبور از چرخههای خشونت و ساختن جهانی بهتر است. جنگ ممکن است تکرار شونده باشد، اما صلح انتخاب ماست. انتخابی که با گامهای هرچند کوچک در مسیر مهربانی، درک متقابل و همدلی، همراه خواهد بود. بەرخۆدان ژیانە! مقاومت زندگیست!
RabbitMQ Data in Motion Full Playlist Coming Soon https://youtube.com/@microfrontend?si=di-iPW6iEczvudXS
видео или голосовое, без подписи
من عموما تلاش میکنم خیلی زیاد نت بردارم. ممکنه نتهای یک فصل از کتاب بخاطر ارجاعات و زیرنویسهاش به اندازه خود فصل باشه و همین زیاد بودن ممکنه بازگشت بهش رو برام سخت کنه. اما نوت بوک ال ام بسیار بهم کمک کرده. حالا مستقیما از Obsidian میبرم NotebookLM و پادکستشو جنریت میکنم و اتچ میکنم و میتونم راحت تر بهش برگردم. این فایل سمپل برای نتیه که دو قانون در فضای کانکارنسی که دوست داشتم. پ.ن: در حال تدوین یک دوره برنامه نویسی پارالل و کانکارنت در زبان گو و پایتون هستم :) 〰️〰️〰️〰️〰️〰️ © | @microfrontend_ir
ددلاک یا بن بست در سیستمهای همزمان: ریشه مشکل و راهکارهای پیشگیرانه در طراحی و پیادهسازی سیستمهای کانکارنت یا مالتی ترد، یکی از خطراتی که میتواند عملکرد سیستم را مختل کند Deadlock است .وضعیتی که در آن چند واحد اجرایی مانند تر، پروسس یا گوروتین برای دسترسی به منابع مشترک، بهصورت دائمی منتظر یکدیگر میمانند و هیچکدام قادر به پیشروی نیستند. تعریف دقیق Deadlock طبق نظریه کافمن ددلاک زمانی رخ میدهد که این چهار شرط بهطور همزمان برقرار باشند • منابع بهصورت انحصاری توسط یک واحد اجرایی نگهداری میشوند. • یک واحد اجرایی منبعی را در اختیار دارد و منتظر منبع دیگری است. • منابع نمیتوانند از یک واحد اجرایی گرفته شوند، مگر اینکه خودش آزاد کند. • مجموعه ای از واحدهای اجرایی وجود دارد که هر کدام منتظر منبعی هستند که در اختیار دیگری است. اگر حتی یکی از این چهار شرط شکسته شود، سیستم از deadlock در امان خواهد بود. مثال ساده فرض کنید ترد الف و ترد ب داریم: الف ابتدا ریسورس اول را لاک میکند و سپس میخواهد ریسورس دوم را لاک کند. همزمان ترد ب ریسورس دوم را لاک کرده و منتظر ریسورس اول است. در این حالت، هیچکدام نمیتوانند ادامه دهند. به این وضعیت Deadlock میگوییم راهکارهای جلوگیری از Deadlock ۱. ترتیب یکسان در دسترسی به منابع (Lock Ordering) طراحی سیستم به گونهای که تمام واحدهای اجرایی منابع را به ترتیب مشخص و ثابتی قفل کنند. این روش ساده ولی بسیار مؤثر است و مانع از بروز شرایط Circular Wait میشود. ۲. استفاده از تایماوت یا تلاش محدود برای گرفتن قفل (Timed Locking / Try-Lock) در بسیاری از کتابخانههای کانکارنسی ، امکان تلاش برای گرفتن قفل بهصورت غیرمسدودکننده یا با تایماوت وجود دارد. اگر قفل گرفته نشد، میتوان تصمیم گرفت که عقبنشینی کرده یا مسیر جایگزین طی شود. ۳. پیشگیری از شرط Hold and Wait با طراحی مکانیزمهایی که یک واحد اجرایی فقط زمانی منابع را لاک کند که همهی منابع مورد نیازش همزمان در دسترس هستند. این روش پیادهسازی دشوارتری دارد ولی مؤثر است. ۴. کاهش دانهبندی لاکها (Lock Granularity) کاهش تعداد منابع قفلشونده یا ترکیب آنها در یک قفل واحد در شرایطی میتواند طراحی را سادهتر کند و احتمال بروز Deadlock را کاهش دهد. ۵. استفاده از ابزارهای تحلیل کانکارنسی ابزارهایی مانند race detectors، lock order analyzers یا ابزارهای مدلسازی formal میتوانند در تشخیص زودهنگام مسیرهای مستعد بنبست کمک کنند. Deadlock نه تنها باعث توقف کامل بخشی از سیستم میشود، بلکه معمولاً بهسختی در محیط تست بازتولید میشود و کشف آن نیازمند تحلیل دقیق رفتار زمان اجراست. در نتیجه، طراحی صحیح از ابتدا، مستندسازی لاکها، و استفاده از الگوهای شناختهشدهی جلوگیری از بنبست، کلید مقابله با این مشکل هستند. 〰️〰️〰️〰️〰️〰️ © | @microfrontend_ir
معرفی کتاب: A Philosophy of Software Design نویسنده John Ousterhout استاد دانشگاه استنفورد و طراح سیستمهای واقعی در مقیاس بالا و خالق زبان TCL در دنیای توسعه نرمافزار، چالش اصلی معمولاً نوشتن کد نیست، بلکه مدیریت پیچیدگی در طول زمان است. این کتاب یکی از ارزشمندترین منابعی است که تا به حال در مورد طراحی نرمافزار دیدهام، نه از جنس دیزاین پترنها، بلکه در سطحی بالاتر از آن: تفکر طراحی. طراحی نرمافزار یعنی مدیریت پیچیدگی در مسیر برنامهنویسی، شاید یکی از سختترین کارها نوشتن کدی نیست که کار کند، بلکه ساخت سیستمی است که در گذر زمان قابل فهم، قابل توسعه و قابل نگهداری باقی بماند. - پیچیدگی مفهومی (نه صرفاً تعداد خطوط) مهمترین عاملی است که کیفیت نرمافزار را تهدید میکند. - اولین راهحلی که به ذهن میرسد معمولاً بهترین نیست. بازبینی و بازطراحی، بخش طبیعی فرآیند مهندسی است. - ماژولهای خوب آنهایی هستند که پشت یک رابط ساده، جزئیات زیادی را پنهان میکنند — و این باعث کاهش بار ذهنی میشود. - مخفیسازی اطلاعات فقط برای مرتب نگهداشتن نیست؛ ابزاری است برای کاهش وابستگی و افزایش انعطاف سیستم در آینده.
رفقا و همراهان گرامی نوروزتان پیروز از همه حمایتهاتون ممنونم. در شش ماه گذشته خیلی نتونستم تولید محتوا کنم. امیدوارم بتونم در سال جدید بیشتر در کنارتون باشم زنده باشید بژین
یکی از نوستالژیکترین تکنولوژیها برای من انگولار است. لحظه لحظه مستند تاریخچه انگولار برام جذاب و دلنشین بود! «انگولار؛ از یک آزمایش داخلی تا بازگشتی شگفتانگیز انگولارجیاس (AngularJS) در ابتدا بهعنوان یک آزمایش داخلی در گوگل متولد شد و حتی توسط تیمهای…