یادداشتها
بلاگ
یادداشتهایی درباره مهندسی فرانتاند، سئو، هوش مصنوعی، تحلیل داده و ساخت محصول واقعی.
42 مقاله
با وجود وعده «منابع تضمینشده — بدون اشتراک»، میانگین CPU Steal در VPS من از AVA Hosting برابر 32.73٪ بود
VPS مبتنی بر KVM من در AVA Hosting زیر ترافیک عادی تولید، بهطور میانگین 32.73٪ CPU steal، صفر درصد CPU idle و نزدیک به 99٪ فشار CPU نشان داد. این یک نقد منفی نیست؛ روایت یک عیبیابی واقعی است از چیزی که Linux داخل ماشین مجازی گزارش کرد.
VPS من در FDCServers بیش از 3 ترابایت ترافیک را بدون مشکل جابهجا کرد؛ بعد خواندن از دیسک به 18 ثانیه رسید
VPS من در FDCServers ابتدا ترافیک واقعی را عادی پردازش کرد و بیش از 3 ترابایت داده انتقال داد. بعد، همان بار معمول باعث توقفهای شدید دیسک مجازی شد: CPU iowait به 100٪ رسید، فشار I/O لینوکس به نزدیکی 100٪ رفت، latency خواندن 18.7 ثانیه شد و flush بیش از 53 ثانیه طول کشید.
VPS من در REGXA حتی بدون ترافیک 94٪ CPU Steal نشان میداد
در بررسی مشکل شدید کارایی یک VPS مبتنی بر KVM در REGXA، به 92 تا 94 درصد CPU steal، درخواستهای چندثانیهای localhost، صفهای رو به رشد اتصال و پاسخهای HTTP 504 با بیش از دو دقیقه تأخیر رسیدم. با حذف کامل ترافیک production، CPU steal به 94.17٪ افزایش یافت و REGXA بعداً علت را resource contention در زیرساخت اشتراکی خود اعلام کرد.
دو ماه استفاده از Bunny Storage پشت Nginx: چرا تصویر، ویدئو و صوت را به یک سرور رسانهای جدا منتقل کردم
بهمدت دو ماه Bunny Storage را نه از طریق Bunny CDN، بلکه بهعنوان origin خصوصی پشت کش Nginx خودم استفاده کردم. لاگهای production نشان دادند درخواستهای cold media گاهی گرفتار تأخیرهای طولانی اتصال میشوند و MP4 نیز مشکل جداگانهای با Nginx Slice و ETag ناسازگار دارد؛ در نهایت به یک media origin خصوصی و ساده مهاجرت کردم.
SSIMULACRA2 در تبدیل WebP به AVIF: چرا برای منبع 60 و برای مشتقهای Lossy عدد 65 را استفاده میکنم
وقتی AVIF از WebPای ساخته میشود که قبلاً با اتلاف فشرده شده، SSIMULACRA2 فقط نسل دوم افت کیفیت را میسنجد. به همین دلیل برای منابع تمیز 60/58 و برای مشتقهای Lossy شناختهشده 65/63 را انتخاب کردهام.
DeepSeek قیمتها را بالا برد — همان V4 Flash را ارزانتر از تعرفه قدیمی پیدا کردم
صبح ۱۷ اوت دیدم هزینه DeepSeek API من تقریباً پنج برابر حالت عادی شده است. بعد همان checkpoint DeepSeek-V4-Flash-0731 را نزد یک ارائهدهنده دیگر پیدا و آزمایش کردم که قیمت فعلیاش حدود 45% پایینتر از تعرفه قدیمی DeepSeek است.
چگونه WebP متحرک، GIF و APNG را بدون خرابکردن قابها یا زمانبندی به H.264 MP4 تبدیل میکنم
فرایند تولید من قابهای کاملی را که کاربر واقعاً میبیند بازسازی میکند، زمانبندی منبع را حفظ میکند، برای هر MP4 نهایی یک CFR برمیگزیند، بدون بزرگنمایی کوچکترین بوم مشترک را میسازد، قطعههای سازگار H.264 را کُدگذاری و بدون نسل اتلافی دوم به هم متصل میکند و هم فایل و هم تحویل آن از طریق HTTP را اعتبارسنجی میکند. در یک اجرای اندازهگیریشده، 217 فایل WebP متحرک با حجم کل 1.49 GB به یک H.264 MP4 با حجم 78.49 MB تبدیل شدند.
برای همهچیز هشدار میگرفتم: چگونه نویز خطاهای مرورگر را به پایش مفید محیط تولید تبدیل کردم
گزارشگر فرانتاند من مسدود شدن تبلیغات، خرابی GTM، خطای AbortError، پیام مبهم Script error و خرابی واقعی چانکهای Next.js را یکسان میدید. پایش را بر اساس مالکیت خطا، اثر بر کاربر، کیفیت شواهد، همبستگی رویدادها و بازیابی بازطراحی کردم.
چرا تبهای قدیمی Next.js بعد از استقرار خراب میشوند: HTML قدیمی، چانکهای حذفشده و ناهمخوانی نسخهها
بعد از یک استقرار، مانیتورینگ محیط تولید من شکست بارگذاری یک چانک JavaScript متعلق به خود برنامه Next.js را ثبت کرد. لاگ وقوع خطا را ثابت میکرد، نه علتش را. این مقاله با تکیه بر همان اتفاق، تبهای قدیمی، HTML قدیمی، فایلهای گمشده /_next/static، ناهمخوانی نسخهها، دوره نگهداری، deploymentId، ترتیب استقرار، مانیتورینگ و بازیابی کنترلشده را توضیح میدهد.
یک تیک که CFR من را شکست: چرا 5580 برابر 5625 نبود و 3751 برابر 3750 نشد
اعتبارسنج من بارها MP4 با نرخ 16 فریمبرثانیه را رد کرد، چون مدت یک بسته 5580 تیک بود نه 5625؛ بعدتر هم بستهای با 3751 تیک پیدا کرد، در حالی که 24 فریمبرثانیه دقیقاً 3750 میخواست. این دو خطا باعث شدند زمانبندی منبع، کوانتیزهکردن CFR، مبنای زمان MP4، PTS/DTS، مالتیپلکسکردن و اعتبارسنجی در سطح بسته را از هم جدا کنم.
چطور با H.264 یک ویدیوی واقعی را از حدود 280 MB به حدود 50 MB رساندم
یک ویدیوی واقعی از سامانهٔ عملیاتی پس از بازطراحی تنظیمات H.264 با CRF 28، x264 veryslow، سقف وضوح در ردهٔ 720p، نرخ فریم مفید و الزامات متعادل برای رمزگشا، از حدود 280 MB به حدود 50 MB رسید. در مرحلهای قدیمیتر همان نمونه از حدود 350 به 238 MB کاهش یافته بود و بررسی کتابخانهٔ قدیمی نیز نشان داد فایلهای H.264 با نرخ چند مگابیت بر ثانیه رایج بودهاند.
Gitae را ساختم تا قطعی سایت را فراتر از یک جواب سادهٔ «بالاست یا پایین» عیبیابی کنم
Gitae را برای یک سؤال عملی ساختم: آیا سایت واقعاً در دسترس نیست یا مشکل فقط محلی است؟ این ابزار بررسیهای VDS خارجی از مسکو و هلسینکی را با DNS، HTTPS/TLS، پورت، routing، IP، hosting و نشانههای CMS ترکیب میکند و هر نتیجه را بهعنوان قرینه میبیند، نه اثبات قطعی.
چرا TypeScript در توسعهٔ نرمافزار واقعی با Codex اینقدر خوب کار میکند
در محیط production، TypeScript چیزی به Codex میدهد که حتی یک prompt خوب هم جای آن را نمیگیرد: قراردادهای قابلبررسی توسط ماشین، بازخورد سریع compiler و مسیر امنتر برای refactorهای بزرگ.
Jurfi.com را ساختم: استودیوی مرورگری برای پیشنویسهای حقوقی ساختارمند
Jurfi.com را ساختم تا فرمها و قالبها را در مرورگر به پیشنویسهای کاری حقوقی ساختارمند تبدیل کند، امکان نگهداری محلی پیشنویسها را بدهد و بازبینی را بخش صریح فرایند نگه دارد؛ بدون این ادعا که نرمافزار میتواند جای وکیل را بگیرد.
اولین درآمد SaaS من: یک پرداخت واقعاً چه چیزی را ثابت کرد؟
اولین پرداختی که برای یک محصول SaaS ساخته خودم دریافت کردم کوچک بود، اما کیفیت شواهدی را که داشتم تغییر داد. این نوشته درباره چیزی است که یک تراکنش میتواند تأیید کند، چیزی که نمیتواند ثابت کند و اینکه چرا تکرار مهمتر از خود نقطه عطف است.
چطور با Codex همزمان ۱۵ پروژه را بازبینی میکنم و کنترل نهایی را از دست نمیدهم
بازبینی ۱۵ پروژه نرمافزاری قبلاً یعنی غرق شدن در بررسیهای تکراری. Codex کمک میکند باگها، تستها، SEO، ترجمهها، بومیسازی و سازگاری را خیلی سریعتر بررسی کنم، اما هر finding هوش مصنوعی را فقط یک سرنخ میدانم، نه حکم نهایی، و هر تغییر باید توسط خودم تأیید شود.
چرا ۳ تا ۵ درصد آخر محدودیت Codex در ChatGPT Plus را صرف کارهای مهندسی بزرگ میکنم — بهروزرسانی: در تابستان ۲۰۲۶ این روش دیگر کار نکرد
بهروزرسانی: تا تابستان ۲۰۲۶ این workflow دیگر برای من قابل اتکا نبود. شمارنده ۵ ساعته از حسابم ناپدید شد، فقط محدودیت هفتگی دیده میشد و کار طولانی میتوانست با تمام شدن آن متوقف شود.
۱۰ هزار مقاله سئویی با هوش مصنوعی منتشر کردم؛ در نهایت سایت من به صفر صفحه در ایندکس Google رسید
انتشار انبوه با AI ابتدا شبیه میانبر بود: Google همه ۱۰ هزار URL مقاله تولیدشده را crawl کرد، اما فقط حدود ۱۰۰۰ صفحه واقعاً وارد ایندکس شدند، در Search دیده شدند و ترافیک واقعی آوردند. بعد همان صفحات هم کمکم حذف شدند تا کل سایت به صفر صفحه ایندکسشده رسید. این تجربه نگاه من به AI، SEO، ترجمه و مسئولیت تحریریه را عوض کرد.
پنج سال با MacBook M1 با ۸ گیگابایت رم و ۲۵۶ گیگابایت SSD: چرا هنوز عوضش نکردهام
MacBook M1 پایه با ۸ گیگابایت حافظه و SSD ۲۵۶ گیگابایتی را حدود ۱۰۰۰ دلار خریدم و تقریباً روزی ۱۵ ساعت برای توسعه نرمافزار، کار با ویدئو و صدا و تصویر، نوشتن، یادگیری و پروژههای جانبی از آن استفاده کردم. پنج سال بعد محدودیتهایش را واضح میبینم، اما دلیل فکر کردن به ارتقا این است که حجم کارم بزرگتر شده، نه اینکه دستگاه دیگر مفید نباشد.
وبلاگم را با ChatGPT به ۲۰ زبان ترجمه کردم و از سراسر دنیا ورودی جستجو گرفتم
هوش مصنوعی اقتصاد انتشار چندزبانه را برای من عوض کرد. از یک وبلاگ تکزبانه به انتشار هر مقاله در حداکثر ۲۰ زبان رسیدم و هر نسخه محلی به یک ورودی جدید از جستجوی ارگانیک تبدیل شد.
QRViz را بهعنوان یک سازنده رایگان QR ثابت راهاندازی کردم — و توزیع را به SEO سپردم
qrviz.com را بهعنوان یک سازنده رایگان کد QR راهاندازی کردم؛ بدون بودجه تبلیغاتی، جذب پولی یا قیف درآمدی. برای دیدهشدن کاملاً به SEO تکیه دارم و همین توزیع، بزرگترین بخش نامطمئن پروژه است.
چرا جذب مشتری برای من از ساختن یک SaaS سختتر بود
یک درس از تجربه مستقیم من در ساخت SaaS: مهندسی بازخورد روشن و قابلبررسی میداد، اما توزیع، positioning، messaging و retention به حلقهای متفاوت و بسیار کمتر قابلپیشبینی نیاز داشتند.
یک محصول SaaS را کاملاً تنها ساختم؛ با فعال شدن پرداختها ماهیت کار عوض شد
این محصول را شبها، آخر هفتهها و در تعطیلات بهتنهایی ساختم. وقتی پرداختها فعال شد، باگ، onboarding، moderation، retention و اعتماد دیگر موضوعات «برای بعد» نبودند و به بخشی از اداره یک محصول واقعی تبدیل شدند.
I Got 550 Views from One Image, Voiceover, and Subtitles: What Three Shorts Tests Actually Taught Me
A simple YouTube Short built from one static image, a voiceover, and subtitles reached 550 views. After three early tests, the useful lesson was not a proven formula, but a repeatable way to experiment without confusing a promising signal with proof.
نزدیک 6,000 درخواست برای یک موقعیت Frontend در مسکو دیدم؛ این عدد درباره بازار IT روسیه چه میگوید و چه نمیگوید؟
اواخر 2023، استخدامکنندهها به من میگفتند 300–500 درخواست برای یک موقعیت شغلی عدد بالایی است. در 20 ژانویه 2026 یک موقعیت Frontend سطح میانی در مسکو دیدم که ظرف چند ساعت به نزدیک 6,000 درخواست رسید. اینجا توضیح میدهم این عدد چه سیگنالی دارد، چه چیزی را ثابت نمیکند و من امروز بهعنوان متقاضی چطور آن را تفسیر میکنم.
DeepSeek چطور workflow من با Node.js را عوض کرد: بیش از ۴۰۰۰ commit در شش ماه
نمودار GitHub من در سال 2025 از تقریباً خالی به بیش از ۴۰۰۰ commit در نیمه دوم سال رسید. این مقاله توضیح میدهد AI coding چگونه workflow پروژههای جانبی Node.js من را عوض کرد، کجا زمان ذخیره کرد، کجا اشتباه کرد و چرا verification از سرعت تولید مهمتر ماند.
اولین TikTok من در ۲۸ سالگی: یک دموی عمودی محصول چه چیزی درباره ترافیک به من یاد داد
در ۲۸ سالگی اولین TikTok خودم را منتشر کردم و همان دموی محصول را در Reels و Shorts هم قرار دادم. نکته مهم تعداد بازدید نبود؛ مهم این بود که قاب ۹:۱۶ چقدر یک رابط دسکتاپ را تغییر میدهد و چطور باید ترافیک ویدیوی کوتاه را بدون اشتباه گرفتن reach با acquisition سنجید.
یک دامنه 25 ساله خریدم؛ URLهای مرده روزی بیش از 1,000 درخواست میگرفتند
بعد از راهاندازی سایت روی دامنهای که اولین بار در سال 2000 ثبت شده بود، روزانه بیش از 1,000 درخواست برای URLهای قدیمی و بیش از 900 خطا در Yandex Webmaster طی یک شب دیدم. اینجا مشخص میکنم چه چیزهایی واقعاً قابل اثبات بود، چرا 410 را هدفمند استفاده کردم و امروز یک دامنه قدیمی را چگونه بررسی میکنم.
یاندکس 12,500 صفحه را ایندکس کرده بود، اما ترافیک روسیه تقریباً صفر بود: مشکل Cloudflare که از چشمم دور مانده بود
یاندکس 12,500 صفحه را ایندکس کرده بود، اما ترافیک از روسیه تقریباً صفر بود. مشکل را تا مسیر شبکه محدود کردم، پراکسی Cloudflare را خاموش کردم، کش، فشردهسازی و حفاظت پایه را به Nginx روی VDS خودم منتقل کردم و دسترسی را برگرداندم.
سایت استاتیک Next.js من هر روز هزاران اسکن آسیبپذیری میگیرد؛ Nginx تقریباً متوجه نمیشود
لاگهایم پر از probe برای WordPress، بکدورهای PHP، فایلهای .env و .git/config است. روی سایت استاتیک Next.js + Nginx من، بیشتر این درخواستها به miss و 404 کمهزینه ختم میشوند و بار CPU هنگام مشاهده ثابت ماند. این تجربه درباره امنیت سایت استاتیک چه چیزی را واقعاً نشان میدهد و چه چیزی را نه؟
Yandex برای سایت جدیدم ترافیک آورد، در حالی که Google تقریباً تکان نخورد
در همان پروژه جدید، Google طی یک بازه طولانی فقط حدود 300 کلیک داشت، اما Yandex Webmaster رشد مشخصی نشان میداد و در مقطعی افزایش +500٪ کلیک را گزارش کرد. نکته اصلی این است که بدانیم این اعداد چه چیزی را ثابت میکنند و چه چیزی هنوز فقط یک فرضیه است.
Yandex در یک شب ۴٬۲۷۸ صفحه Next.js من را ایندکس کرد؛ این اتفاق واقعاً چه چیزی را ثابت کرد؟
Yandex تقریباً یکباره ۴٬۲۷۸ صفحهای را که با Next.js بهصورت استاتیک ساخته بودم وارد ایندکس کرد. این یک نقطه عطف فنی واقعی بود، اما اثبات رتبه یا ترافیک نبود. در این مطلب دقیقاً جدا میکنم که این نتیجه درباره SSG و Programmatic SEO چه چیزی را نشان میداد و چه چیزی را نه.
ماه اول SEO من: ۶۳۲ بازدیدکننده ارگانیک و یک واقعیتسنجی درباره ترافیک رباتها
برای آماده شدن برای یک برنامه بزرگتر SEO در محل کار، از یک پروژه شخصی بهعنوان محیط آزمایش استفاده کردم. بعد از یک ماه ۶۳۲ بازدیدکننده ارگانیک داشتم، اما روزی با ۸۳ بازدیدکننده نشان داد ترافیک مشکوک و محدودیت ابزارهای تحلیل چقدر راحت میتوانند تصویر نتیجه را عوض کنند.
نزدیک بود Yandex Webmaster را نادیده بگیرم؛ دو هفته بعد ترافیک بیشتری از Google میفرستاد
برای کسب تجربه پیش از یک پروژه کاری که SEO در آن حیاتی بود، یک side project با Next.js ساختم. در دو هفته اول 58 بازدیدکننده از Google و 200 بازدیدکننده از Yandex دیدم و فهمیدم ترافیک، ایندکس و diagnostics را باید جدا سنجید.
Yandex Metrica در برابر Google Analytics: چرا بعد از یک هفته Metrica را ترجیح دادم
Google Analytics و Yandex Metrica را یک هفته روی یک پروژه جدید بهصورت همزمان اجرا کردم. دلیل اصلی اینکه بیشتر سراغ Metrica رفتم Webvisor و بازپخش سشنها بود؛ اما این نتیجه درباره workflow من است، نه اثبات برتری یک پلتفرم برای همه.
Yandex وبلاگم را بدون /en خزید؛ ریدایرکتهای 308 جلوی 404 را گرفتند
بعد از اضافهکردن حدود ۳۰۰۰ صفحه با ساختار /en/blog/... به sitemap دیدم Yandex مسیرهای متناظر /blog/... را امتحان میکند. ریدایرکتهای 308 که از قبل داشتم نگذاشتند این درخواستها به 404 ختم شوند. نکته اصلی این نبود که Yandex «sitemap را خراب کرده»، بلکه ارزش یک لایه ریدایرکت دقیق برای مقاومتر کردن معماری URL بود.
دو سایت جدید در Google جهش کردند و چند روز بعد ترافیک حدود ۱۰ برابر افت کرد
در دو لانچ پیاپی، ایمپرشنهای Google بلافاصله جهش کردند و چند روز بعد ترافیک تقریباً به یکدهم رسید. خود الگو واقعی بود، اما نمیتوانم ثابت کنم علت آن «ماهعسل Google» بوده است.
۲٬۰۰۰ صفحه یکشبه از جستجوی Yandex ناپدید شدند؛ واقعاً چه چیزی از آن میشد فهمید؟
در Yandex Webmaster دیدم که ۲٬۰۰۰ صفحه از حدود ۸٬۰۰۰ صفحه دیگر در جستجو مشارکت ندارند. افت ۲۵٪ چشمگیر بود، اما درس مهمتر این بود که تغییر مشاهدهشده در وضعیت حضور صفحات در جستجو را با علت اثباتشده یکی ندانم.
در MoscowJS 66 بیش از 10 سؤال پرسیدم و دو جایزه بردم
در MoscowJS 66 بیش از 10 سؤال درباره ارائههای مربوط به رباتهای Telegram، LangChain.js، معماری سایتساز و تست typeهای TypeScript پرسیدم. دو سؤال بهعنوان بهترین سؤالها انتخاب شدند و با دو جایزه برگشتم.
چیزهایی که از PiterJS #79 با خودم آوردم: مونولیت قدیمی، FrontOps، عملکرد وب و سؤالهای بهتر
PiterJS #79 در سنپترزبورگ روی نگهداری سیستمهای موجود تمرکز داشت: یک مونولیت قدیمی، FrontOps و معیارهای عملکرد وب. با یادداشتهای کاربردی، دو جایزه از Q&A و یادآوری ارزش مشارکت واقعی در meetupهای حضوری برگشتم.
وبلاگ Next.js را به 21 زبان منتشر کردم؛ 439 ایمپرشن Google واقعاً چه چیزی به من گفت؟
در هفتهی اول، وبلاگ Next.js من با 21 زبان 439 ایمپرشن و 5 کلیک از Google گرفت. بعدتر 436 صفحه از 471 صفحه ایندکس شده بودند. مهمترین درس برای من جدا کردن دیدهشدن، ایندکسشدن و عملکرد واقعی در جستجو بود.
MoscowJS 65 بعد از شش سال کار با JavaScript: چرا هنوز به میتاپهای محلی میروم
۵ ژوئن ۲۰۲۵ در MoscowJS 65 در T Bank شرکت کردم. چهار ارائه از زاویههای متفاوت به AI نگاه میکردند، اما نتیجه اصلی من سادهتر بود: میتاپهای محلی هنوز چیزی به من میدهند که مستندات و ویدئوهای ضبطشده نمیتوانند کاملاً جایگزینش شوند.