اکنون در دسترس! پژوهش تلگرام ۲۰۲۵ — مهمترین بینشهای سال 
نوشتههای ترمینالی
رفتن به کانال در Telegram
3 036
مشترکین
+624 ساعت
+437 روز
+7730 روز
در حال بارگیری داده...
کانالهای مشابه
ابر برچسبها
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
ژوئن '26
ژوئن '26
+19
در 0 کانالها
مه '26
+91
در 1 کانالها
Get PRO
آوریل '26
+44
در 0 کانالها
Get PRO
مارس '26
+11
در 0 کانالها
Get PRO
فوریه '26
+149
در 4 کانالها
Get PRO
ژانویه '26
+30
در 1 کانالها
Get PRO
دسامبر '25
+102
در 5 کانالها
Get PRO
نوامبر '25
+98
در 3 کانالها
Get PRO
اکتبر '25
+76
در 3 کانالها
Get PRO
سپتامبر '25
+127
در 3 کانالها
Get PRO
اوت '25
+410
در 4 کانالها
Get PRO
ژوئیه '25
+132
در 6 کانالها
Get PRO
ژوئن '25
+68
در 2 کانالها
Get PRO
مه '25
+96
در 4 کانالها
Get PRO
آوریل '25
+70
در 2 کانالها
Get PRO
مارس '25
+57
در 0 کانالها
Get PRO
فوریه '25
+74
در 1 کانالها
Get PRO
ژانویه '25
+128
در 3 کانالها
Get PRO
دسامبر '24
+98
در 0 کانالها
Get PRO
نوامبر '24
+128
در 2 کانالها
Get PRO
اکتبر '24
+165
در 3 کانالها
Get PRO
سپتامبر '24
+79
در 3 کانالها
Get PRO
اوت '24
+87
در 2 کانالها
Get PRO
ژوئیه '24
+73
در 3 کانالها
Get PRO
ژوئن '24
+79
در 4 کانالها
Get PRO
مه '24
+79
در 6 کانالها
Get PRO
آوریل '24
+67
در 0 کانالها
Get PRO
مارس '24
+61
در 1 کانالها
Get PRO
فوریه '24
+102
در 1 کانالها
Get PRO
ژانویه '24
+166
در 2 کانالها
Get PRO
دسامبر '23
+150
در 2 کانالها
Get PRO
نوامبر '23
+38
در 2 کانالها
Get PRO
اکتبر '23
+56
در 3 کانالها
Get PRO
سپتامبر '23
+30
در 0 کانالها
Get PRO
اوت '23
+20
در 0 کانالها
Get PRO
ژوئیه '23
+29
در 0 کانالها
Get PRO
ژوئن '23
+59
در 0 کانالها
Get PRO
مه '23
+61
در 0 کانالها
Get PRO
آوریل '23
+25
در 0 کانالها
Get PRO
مارس '23
+154
در 0 کانالها
Get PRO
فوریه '23
+25
در 0 کانالها
Get PRO
ژانویه '23
+104
در 0 کانالها
Get PRO
دسامبر '22
+25
در 0 کانالها
Get PRO
نوامبر '22
+390
در 0 کانالها
| تاریخ | رشد مشترکین | اشارات | کانالها | |
| 05 ژوئن | 0 | |||
| 04 ژوئن | +8 | |||
| 03 ژوئن | +4 | |||
| 02 ژوئن | +3 | |||
| 01 ژوئن | +4 |
پستهای کانال
در مورد معماری Hexagonal یا همون Port&Adaptor توی اپلیکیشن بکاندی، این بلاگ رو دیدم و خیلی خوب توضیح داده بود.
https://medium.com/fastned/the-hexagon-a-battle-tested-blueprint-for-your-event-driven-app-163d4e40bd2d
| 2 | چرا سرعت ۱۰ برابری کدنویسی با AI ممکنه به یک تلهی بدهی فنی/ technical debt تبدیل بشه؟
چند وقت پیش ویدیوی Mario Zechner (سازنده Pi coding agent) با عنوان «ساختن PI در دنیای Slop» رو دیدم و باید بگم که با نگاهش موافقم برای کسایی که با AI کد تولید میکنند. یک بلاگ راجع بهش نوشتم که لینکش را پایین میذارم.
این روزها صنعت بیش از حد درگیر «ایجنت های ماکسیمالیستی» شده؛ ابزارهای بیشتر، سابایجنتهای بیشتر، مدیریت کانتکست پیچیدهتر و کلی لایهی اضافی. اما دادهها داستان متفاوتی را تعریف میکنند.
سه نکتهی مهمی که از صحبتهای ماریو برداشت کردم:
۱- مینیمال بهتر از ماکسیمال است:
بنچمارکهایی مثل Terminal Bench نشان میدهند که سادهترین محیطها (اغلب فقط یک ترمینال) بهطور مداوم از هارنسهای پیچیده و پر از قابلیت عملکرد بهتری دارند.
ایجنت Pi هم دقیقاً همین فلسفه را دنبال میکند:
* فقط ۴ ابزار
* یک سیستمپرامپت بسیار کوچک
* بدون هیچ جادوی پنهانی برای هرس کردن کانتکست
نتیجه؟ سیگنال تمیزتر و کد بهتر.
۲- ایجنتها درد را حس نمیکنند:
یک توسعهدهندهی واقعی وقتی با یک کدبیس/codebase شلوغ و بههمریخته روبهرو میشود، خسته و کلافه میشود و در نهایت سراغ ریفکتور میرود.
اما یک ایجنت هوش مصنوعی بدون هیچ مشکلی ممکن است ۱۰ هزار خط کدی تولید کند که از نظر محلی «درست» هستند (locally correct)، ولی از نظر معماری یک فاجعهی کامل محسوب میشوند.
هوش مصنوعی فشار و هزینهی بدهی فنی را حس نمیکند؛ تا زمانی که کدبیس آنقدر بزرگ میشه که حتی خود مدل LLM هم دیگر نتواند آن را درست درک کند.
۳- اصطکاک همیشه دشمن نیست:
سالها به ما گفتهاند که هر نوع اصطکاک در فرآیند توسعه بد است و باید حذف شود.
اما ماریو نظرش متفاوته:
"اصطکاک همان چیزی است که باعث میشود درک و دانش از کد به ذهن شما منتقل شود."
اگر تمام این اصطکاک را با ایجنتها حذف کنید، کمکم دیگر توسعهدهنده نخواهید بود؛ بلکه تبدیل میشوید به کسی که فقط کدی را بازبینی میکند که خودش واقعاً آن را نمیفهمد.
استراتژی پیشنهادی برای ۲۰۲۶:
- وظایف را تا حد ممکن کوچک و مشخص تعریف کنید.
- بهشدت روی ماژولار بودن سیستم پافشاری کنید.
- از ایجنتها برای کارهای خستهکننده مثل تولید boilerplate یا بازتولید باگها استفاده کنید.
- خطوط مهم و حساس کد را خودتان بخوانید. تکتکشان را!!!
در نهایت، هوش مصنوعی یک ابزار دقیق و قدرتمند است، نه جایگزینی برای تفکر معماری و قضاوت مهندسی.
اگر دوست دارید بلاگ کامل من با عنوان «Slop, Speed, and Discipline: Hard Truths About AI Coding Agents» را بخوانید، میتوانید اینجا بخونیدش.
Blog: https://mlnotes.substack.com/p/slop-speed-and-discipline-hard-truths
@DevTwitter | <Mehdi Allahyari/> | 694 |
| 3 | این چنل آرشیو کتابها، برگه تقلب، پادکست و وبینار برای دولپرهاست، بدردتون میخوره.
t.me/+M4QujCyYc9E1N2Rk
عضوگیری محدوده رکوئست ها فردا اکسپت میشه...❤️ | 509 |
| 4 | زمانی که یه تیم دیگه به تغییر در کد ما نیاز داره، سه تا گزینه داریم، کدوم یکی بهتره:
۱- بهشون بگیم خودشون تغییر رو انجام بدن.
۲- بهشون بگیم ما کمکشون میکنیم ولی با خیلی تاخیر این کارو انجام بدیم.
۳- کار خودمون رو رها کنیم و کار اونجا رو انجام بدیم.
این مطلب میگه عموما گزینه دوم رو انتخاب میکنیم ولی گزینه سه بهتره. چون:
If you choose to finish your own task:
Your team will make it on time. The other team will be late, and will probably mention your team as the reason…
You choose to help the other team:
You will be late. The other team will be on time - and for sure they’ll mention your team saved them.
البته در نظر داشته باشید که این که به اینجا رسیدیم اصلا نشونه یکسری اشتباه بوده و باید کاری کنیم مشکلات اینچنینی به وجود نیان.
https://open.substack.com/pub/zaidesanton/p/the-delayed-opinions-givers-engineering
#زماندار | 2 508 |
| 5 | زیاد دیدم که میپرسن چرا نوتیفیکیشن اپها از بله و ایتا گرفته تا تلگرام، توییتر و بقیه این روزها یا نمیاد.
واقعیت اینه که نوتیفیکیشن فقط به خود اپ مربوط نیست.
روی اندروید تقریباً همه Push Notificationها از طریق سرویس FCM گوگل ارسال میشن و روی آیفون هم از طریق سرویس APNs اپل.
(هواوی یا شیائومی یا ... سرویس مخصوص خودشون رو دارن)
یعنی حتی اگر اپ کاملاً داخلی باشه، باز هم برای رساندن نوتیفیکیشن باید گوشی بتواند به سرویسهای گوگل یا اپل وصل شود.
وقتی اینترنت بینالملل یا دسترسی به این سرویسها مختل میشود، نتیجهاش این میشود که:
ناتیف ها اصلاً نمیرسند
سازوکارش هم خیلی ساده است:
۱- اپ روی گوشی نصب میشود
۲- از گوگل/اپل یک شناسه دریافت میکند
۳- سرور اپ(مثلا بله یا تلگرام یا ...) پیام را به سرویس گوگل یا اپل میفرستد
۴- آن سرویس نوتیفیکیشن را به گوشی تحویل میدهد
برای همین اگر ارتباط با FCM گوگل یا APNs اپل مشکل داشته باشد، عملاً سیستم نوتیفیکیشن موبایل دچار اختلال میشود.
نکته مهم اینکه:
اپ نمیره مستقیم به هواووی یا شیائومی یا گوگل و اپل API بزنه
فقط از SDK استفاده میکنه
بعد SDK میره با سرویس مناسب حرف میزنه
FCM = Firebase Cloud Messaging
APNs = Apple Push Notification service
پ.ن: امیدوارم تونسته باشم ساده توضیح داده باشم. تو این روزا که ناتیف های بله و ... نمیاد مشکل از بله نیست ، اقایان سرویس های پوش ناتیف رو در دسترس قرار ندادن.
@DevTwitter | <iSegar0/> | 2 033 |
| 6 | آیا AI جامون رو به عنوان برنامهنویس میگیره؟
https://youtu.be/NZa5lApeFic | 2 760 |
| 7 | یه بحثی شکل گرفته در مورد اینکه آیا از روی آیدی auto increment میشونه فهمید یه سایتی چقدر کاربر داره. این دغدغه امنیتی درستیه و یه سری راهحل هم داره.
در واقع این روشها اینطوری کار میکنن که آیدی عددی دیتابیس رو سمت سرور نگه میدارن و به کاربر نشون نمیدن؛ پس چیزی که به کاربر میدیم یه استرینگ یا عدد دیگهست و انتظار میره ما با سرعت مناسب بتونیم سمت سرور آیدیای که کاربر داره رو به آیدی دیتابیس تبدیل کنیم.
UUID
سادهترین ایدهای که به ذهن میاد همینه چون در واقع یه استرینگ رندومه. این روش از آیدی طولانیتره، کندتره و دیتابیس رو اذیت میکنه به عنوان کلید، ولی میتونه کمککننده باشه چون احتمال تکراری بودنش خیلی کمه، تولیدش خیلی راحته و نیاز به coordination بین سرورها نداره.
NanoID
مثل UUID ولی کوتاهتره و با الفبایی که شما میگید میتونه کار کنه، بنابراین میتونه URL safe هم باشه (پیشفرض هست).
SnowflakeID
یه آیدی عددی که از ترکیب تایماستمپ، نود و شماره ماشین تولید میشه، بنابراین عملاً هم میتونه یونیک باشه هم ترتیبی نیست. چون عددیه و رقمهای چپش بر اساس عدد زیاد میشن، در واقع صعودی هست و دیتابیس رو کمتر اذیت میکنه.
HashID
این روش آیدی رو به یه استرینگ رمزنگاری میکنه و سمت سرور قابل برگردوندن هم هست.
ایدههای دیگه هم میشه زد، مثلاً hash کردن آیدی به همراه salt، ولی به نظرم مزیت خاصی ایجاد نمیکنه نسبت به UUID. | 0 |
