tech-afternoon

Public

مشاهده کانال

نمی‌توانید بپیوندید؟ @techafternoon

۱.۳k عضو

به‌روزرسانی شده: May 20, 2026 at 5:33 AM

tech-afternoon

تِک‌افترنون، رویدادی گاه‌به‌گاه است با موضوعات حول معماری و توسعه نرم‌افزار، این کانال هم برای اشتراک اخبار، آموزش، نکاتی حول مهندسی نرم‌افزار، دیتابیس‌، تکنولوژی و مدیریت تولید محصولات نر‌م‌افزاری خواهد بود. youtube.com/@AminTechTalks/videos امین مصباحی

Follow @techafternoon to stay updated with the latest youtubecomamintechtalksvideos trends and news

رتبه‌بندی

رتبه‌بندی جهانی

#456

رتبه‌بندی زبان

#45

رتبه‌بندی دسته‌بندی

#23

-1

رشد مشترکان (7 روز گذشته)

مجموع: 1.3K

رشد 24 ساعت: +0 0%

آخرین پست‌ها

tech-afternoon

۹ اردیبهشت ۱۴۰۵، ۰۶:۱۶

بچه‌ها قرار نیست همه برنامه‌نویس بشن، ولی باید مسئله حل کنن! مدت‌ها بود که دوست داشتم در مورد دلایل اهمیت یادگیری برنامه‌نویسی برای کودکان بنویسم؛ اینکه هیچ ربطی به شغل آینده‌ی کودک نداره و مهارت‌های پشتش باید شکل بگیره که اون‌ها مهم هستن. و فعلا برنامه‌نویسی…

1,070

tech-afternoon

۹ اردیبهشت ۱۴۰۵، ۰۶:۱۶

https://mesbahi.net/fa/blog/1404/11/19/programming-for-kids/

مدت‌ها بود که دوست داشتم در مورد دلایل اهمیت یادگیری برنامه‌نویسی برای کودکان بنویسم؛ اینکه هیچ ربطی به شغل آینده‌ی کودک نداره و مهارت‌های پشتش باید شکل بگیره که اون‌ها مهم هستن. و فعلا برنامه‌نویسی یکی از بهترین روش‌ها برای یادگیری اون مهارت‌ها به شمار میان.

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

https://mesbahi.net/fa/blog/1404/11/19/programming-for-kids/

2,990

tech-afternoon

۹ اردیبهشت ۱۴۰۵، ۰۶:۱۶

سلام؛

اگر امروز چند میلیون به سادگی فایل‌هاشون رو روی اینترنت آپلود می‌کنن و از هر نقطه‌ی دنیا با یه URL ساده بهش دسترسی دارن، بخش بزرگی از این سادگی مدیون معماری‌ایه که Amazon S3 حدود دو دهه پیش طراحی کرد.

تقریباً اکثر آبجکت‌استوریج‌های مطرح دنیا، چه از سمت Amazon، Microsoft، Google و چه نمونه‌های داخلی مثل آروان یا ستون، با API سازگار با S3 کار می‌کنن یا عملاً از همون مدل الهام گرفته‌ان.

ایده ساده ولی عمیق:
به جای فایل‌سیستم سنتی با سلسله‌مراتب پیچیده، یک مدل object-based با namespace تخت، شناسه یکتا، متادیتا، و از پایه و اساس طراحی‌شده برای مقیاس‌پذیری افقی. نتیجه؟ ذخیره‌سازی massively scalable با durability بالا و هزینه منطقی.

پروژه‌های متن‌باز مثل Ceph، MinIO و RustFS هم دقیقاً توی همین فضا رشد کردن و اکوسیستم S3-compatible رو تقویت کردن. این یعنی S3 فقط یک سرویس نبود؛ بلکه اینقدر خوب بود که تبدیل به یک قرارداد معماری شد.

اگر به طراحی سیستم‌های توزیع‌شده، trade-off بین consistency و availability، یا تصمیم‌های اولیه‌ای که بعدها تبدیل به استاندارد صنعت شدند علاقه دارین، https://www.youtube.com/watch?v=5vL6aCvgQXU توی کانال The https://www.youtube.com/@pragmaticengineerاز زاویه مهندسی و معماری نکات ارزشمندی داره. مصاحبه دقیق و فنی با معاون تکنولوژی AWS، https://www.linkedin.com/in/mailan/.

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

📢 در ضمن برای انتخاب موضوع مطالب آتی کانال خوشحال می‌شم پیشنهادهاتون رو کامنت کنید؛ اگر چیزی در موردشون بدونم یا تجربه‌ای داشته باشم، حتمن در اولویت خواهند بود 😊

tech-afternoon

۹ اردیبهشت ۱۴۰۵، ۰۶:۱۶

به خاطر میخی، نعلی افتاد
به خاطر نعلی، اسبی افتاد
به خاطر اسبی، سواری افتاد
به خاطر سواری، جنگی شکست خورد
به خاطر شکستی، مملکتی نابود شد
و همه این ها به خاطر کسی بود که میخ را خوب نکوبیده بود

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

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

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

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

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

و دوستانی که علاقه دارن خودشون تحقیق کنن شاید این کلیدواژه‌ها بد نباشن:

- Segregation of Duties (SoD)
- End-to-End Traceability
- Audit Logging & Observability
- Data Quality Management (DQM)
- Master Data Management (MDM)
- Reference Data Management
- Single Source of Truth (SSOT)

و همیشه مهندس‌ها با ابزارها و روش‌های فنی جلو فساد رو نمی‌گیرن؛ بلکه با پیاده‌سازی روش‌های به ظاهر غیر نرم‌افزاری در دل نرم‌افزارها جلو فساد رو می‌گیرن؛ کلیدواژه‌های کمکی:
- Social visibility
- Self-regulation
- Nudge theory (تلنگرهای رفتاری)
- Accountability Mechanisms
- Awareness & Participation
- Principal-Agent Theory
- Theory of Change (ToC)
- Social Norms Theory

tech-afternoon

۹ اردیبهشت ۱۴۰۵، ۰۶:۱۶

https://mesbahi.net/fa/blog/1404/10/29/engineering-ethics/

در حالی این مطلب رو می‌نویسم که حدود یک هفته است که ارتباط ایران با اینترنت قطع شده و اونچه که به بیرون میاد ترکیب آشفته‌ای از خبر و شایعه است؛ اخباری که در خوش‌بینانه‌ترین حالتش، چیزی جز صدای درد و رنج و فقدان نیست…
حتی در مورد انتشار این مطلب مردد هستم...
https://mesbahi.net/fa/blog/1404/10/29/engineering-ethics/

2,770

tech-afternoon

۹ اردیبهشت ۱۴۰۵، ۰۶:۱۶

https://mesbahi.net/fa/blog/1404/11/13/from-now-on/

چند خطی در مورد وضعیت حال و پیشنهادی برای بعد...

https://mesbahi.net/fa/blog/1404/11/13/from-now-on/

1,930

tech-afternoon

۹ اردیبهشت ۱۴۰۵، ۰۶:۱۶

⚙️ آمار و میزان محبوبیت مطالب کانال + دسترسی به ویدیو و پادکست

⭐️ https://techafternoon.mesbahi.net/analytics_report.html
https://techafternoon.mesbahi.net/
(تولید شده با استفاده )

📱ویدیوهای https://www.youtube.com/@AminTechTalks/videos
🎙 https://castbox.fm/channel/Tech-Afternoon-with-Amin-id6317817?country=us&nojump=1

1,440

tech-afternoon

۹ اردیبهشت ۱۴۰۵، ۰۶:۱۶

📷 Photo

پروژه Oh My Posh Visual Configurator

اگر شما هم بیشتر ساعات روز مستقیم یا به در حین کار با ترمینال کار می‌کنید (توی ادیتور یا IDE یا مستقل) احتمالا از ابزارهایی مثل oh my posh یا oh my zsh یا ... استفاده می‌کنید تا کار از طریق محیط ترمینال براتون سریع‌تر، و البته کم خطاتر بشه.

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

حالا https://github.com/jamesmontemagno که لید تیم ابزارهای توسعه‌دهنده‌های مایکروسافته؛ یه https://jamesmontemagno.github.io/ohmyposh-configurator/?ref=montemagno.com ساخته که راحت‌تر تنظیمات دلخواه رو بسازیم. اگر دوست داشتید تست کنید.

پروژه https://ohmyposh.dev/ یه ابزار کدباز است که محیط ترمینال رو غنی‌ و کارامد می‌کنه (مک و لینوکس و ویندوز )

https://montemagno.com/introducing-oh-my-posh-visual-configurator-finally-a-drag-and-drop-terminal-theme-builder/ در مورد configurator

1,470

tech-afternoon

۹ اردیبهشت ۱۴۰۵، ۰۶:۱۶

در آخرین ساعات سال ۲۰۲۵، https://mesbahi.net/fa/blog/1404/10/10/2026-iran-software-ecosystem-threats-opportunities/؛ اگر دوست داشتید مطالعه کنید و نظرتون رو به اشتراک بگذارید...

4,460

tech-afternoon

۹ اردیبهشت ۱۴۰۵، ۰۶:۱۶

📷 Photo

شماره https://www.infoq.com/minibooks/architecture-lenses-2025/مقالات جالبی داشت (بعد از چند شماره که به تکرار افتاده بود، این شماره دوباره جون گرفت)

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

Holistic Engineering: Organic Problem
Solving for Complex Evolving Systems

Empowering Teams:
Decentralizing Architectural
Decision-Making

فایل PDF رو در کامنت می‌گذارم تا اگر دوست داشتید دانلود و مطالعه کنید.

1,230

tech-afternoon

۲۶ فروردین ۱۴۰۵، ۱۹:۳۹

در مورد این نظرسنجی، من گزینه‌هایی رو انتخاب کردم که به نحوی به هم مرتبط باشن و انتخاب «بزرگ‌ترین» چالش رو کمی به سمت بیان نحوه‌ی تحلیل مسئولیت‌ها ببره 😅

چهار عامل بین گزینه‌ها بود که ساده‌شده‌اش می‌شه:
- کارشناس
- مدیر
- حاکم
- محیط

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

تا اینجا می‌بینیم که کلی معضل به صورت زنجیره‌ای، و متصل به‌هم دارن شرایط رو دشوار می‌کنن؛ همگی هم صحیح هستن.

💡 ولی رکن چهارم که توی توصیف بالا از هر سه عامل متأثره چی؟

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

قضاوت من با ۱۱۹ نفری که بزرگ‌ترین چالش رو خارج از کارشناس دیدن، همسو است؛ ولی با یک تفاوت مهم!

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

بخشی از بدنه کارشناسی » وارد لایه مدیریتی می‌شن » بخشی از همین مدیران وارد بخش حاکمیتی می‌شن و محیط رو می‌سازن!
حالا سوال اینه: چرا کارشناسان ضعیف به مدیران ضعیف تبدیل می‌شن؟

اینجا دو تا سناریو داریم:

سناریو ۱، خوش‌بینانه: کارشناس قوی وارد مدیریت می‌شه ولی سیستم اون رو می‌بلعه. فشارهای سازمانی، فقدان حمایت، سیاست‌ورزی، و ساختارهای فاسد مجبورش می‌کنن یا سازش کنه یا بره. در این صورت مشکل ۱۰۰٪ ساختاری‌ست و ۹۴٪ نظرسنجی کاملاً درست.

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

نکته اساسی اینه که وقتی می‌گم کارشناس چالشه، منظورم سرزنش کردن قربانی نیست. کارشناس هم قربانی این سیستمه، هم بدون اراده و آگاهی، بازتولیدکننده اون!

چرا؟
۱. سیستم آموزشی فاجعه است » دانشجو با مهارت‌های تاریخ‌گذشته یا ناکارآمد فارغ‌التحصیل می‌شه
۲. فرصت یادگیری واقعی وجود نداره » شرکت‌ها روی رشد مهارت‌‌ها سرمایه‌گذاری نمی‌کنن
۳. شایسته‌سالاری نیست » کارشناس خوب پاداش نمی‌بینه، پس انگیزه از بین می‌ره
۴. فقر اقتصادی » کارشناس مجبوره توی حالت تلاش برای بقا کار کنه، نه حالت رشد

حالا این کارشناس که توسط سیستم شکل گرفته، وارد لایه مدیریتی می‌شه، نه به خاطر شایستگی، بلکه به خاطر seniority (قِدمت)، رابطه، خلأ لایه بالاتر، یا صرفاً گذشت زمان. و چون پیش‌نیازهای مدیریتی رو نداره (تحلیل، تیم‌سازی، استراتژی)، مدیر ضعیفی می‌شه که سیستم رو بازتولید می‌کنه.

پس چرا می‌گم کارشناس چالش بزرگه؟

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

چرا؟
۱. منتظر نشستن برای اصلاح حاکمیت = بی‌نهایت
اگر بخواهیم حاکمیت عوض بشه تا محیط بهتر بشه تا مدیران بهتر بشن تا کارشناسان رشد کنن، این ۵۰ سال طول می‌کشه (اگه اتفاق بیفته).

۲. کارشناس تنها لایه‌ایه که می‌تونه از پایین فشار بیاره
حاکمیت و مدیریت ضعیف وقتی می‌ترسن که جایگزین‌های قوی‌تر ببینن. اگر ۱۰٪ کارشناسان exceptional باشن، فشار ایجاد می‌کنن.

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

- باید یادگیری جمعی ایجاد شه
- و peer accountability شکل بگیره (اشتراک دانش و تجربه واقعی)
- استانداردهای خودِ ما بالا بره (قبول نکردن شرایط زیر خط قرمز)
- بهترین‌ها صدای خودشون رو بلند کنن و الگو باشن

این کافیه؟ قطعاً نه.
بدون این، چیز دیگه‌ای کافیه؟ باز هم نه.

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

نظر و تحلیل شما چیه؟

tech-afternoon

۲۶ فروردین ۱۴۰۵، ۱۹:۳۹

[poll]

952

Showing 12 of 12 posts

No more posts

رتبه‌بندی

ورود لازم است

نظرات کاربران (0)

هنوز هیچ نظری وجود ندارد. اولین نفری باشید که نظر خود را به اشتراک می‌گذارید!

کانال‌های تلگرام مرتبط

Loading recommended channels...

tech-afternoon

tech-afternoon

رتبه‌بندی

رشد مشترکان (7 روز گذشته)

آخرین پست‌ها

رتبه‌بندی

نظرات کاربران (0)

کانال‌های تلگرام مرتبط

خطوط نقل الجامعة التكنولوجية

ریاست هرات برشنا (ریاست برق هرات)

مهندسی تولید و ژنتیک گیاهی

فنيين 🔧 ومهندسين🇸🇦

PARSICO | پارسیکو

Masoud Ahmadi

هندسة و تقنية الشبكات 🛜

قناة بحوث تخرج📚

کانال‌های تلگرام مرتبط

خطوط نقل الجامعة التكنولوجية

ریاست هرات برشنا (ریاست برق هرات)

مهندسی تولید و ژنتیک گیاهی

فنيين 🔧 ومهندسين🇸🇦

PARSICO | پارسیکو

Masoud Ahmadi

هندسة و تقنية الشبكات 🛜

قناة بحوث تخرج📚

نظرات کاربران (0)

آخرین پست‌ها