مهندسی نرم‌افزار - Software Inside

описание

جایی برای گفت‌و‌گو در مورد نرم‌افزار، مهندسی، برنامه نویسی

← к каналу @software_inside

330

подписчиков

Охват к подписчикам

313,3%

ERR

Реакции к просмотрам

0,61%

119 на 19 постов

Пересылки к просмотрам

1,54%

303

Постов в день

0,0

всего 20

Где отзываются чаще

доля реакций к просмотрам

7 мар. 2025 г.Hello World!1,68%
5 мая 2025 г.#مطلب #Redis Redis 8 is GA Redis is Open Source Again دوتا خبر مهم در مورد ردیس منتشر شده: ۱- انتشار نسخه‌ی 8 ردیس: - قابلیت‌هایی که قبلا تحت عنوان Redis Stack به صورت پولی فروخته می‌شد الان به صورت رایگان به نسخه‌ی OSS اضافه شده. قابلیت ذخیره سازی داده‌های Time Series یا JSON و کلی داده‌ساختار جدید دیگه اضافه شده. همچنین Redis Query Engine هم رایگان شده که اجازه میده Secondary Index بسازیم و حتی روی داده‌ها Full-Text Search هم بزنیم. - این نسخه سریع‌ترین ردیسی هست که تا به حال داشتیم و خودشون ادعا می‌کنن بعضی از کامندها تا 80٪ هم سریع‌تر شده همچنین Throughput هم تا دوبرابر می‌تونه بهتر بشه. - با ترند شدن AI و فراگیر شدن LLM ها، دیتابیس‌های vector based هم رونق گرفتن و ردیس هم از قافله جا نمونده. یه داده‌ساختار جدید به اسم VectorSet اضافه کرده که به ما اجازه میده embedding ها رو توش ذخیره کنیم و Vector Search انجام بدیم. ۲- ردیس لایسنسش رو دوباره عوض کرد و از لایسنس اوپن سورس استفاده می‌کنه: داستان اینه که شرکت‌های بزرگ ابری مثل AWS و Google Cloud میان ابزارهای اوپن‌سورس رو به عنوان خدمت ارائه میدن و ازش پول درمیارن اما پولی به اون توسعه‌دهنگان اصلی که دارن اون نرم‌افزار رو توسعه میدن پرداخت نمی‌کنن. همین قضیه باعث شده که نرم‌افزارهای اوپن سورس به فکر تغییر لایسنس بیافتن. مثلا قبل از ردیس، MongoDB و Elasticsearch هم لایسنسشون رو به SSPL تغییر داده بودن. لایسنس SSPL میگه که اگر میخوای نرم‌افزار منو به عنوان سرویس ارائه بدی باید سورس کد کل سرویست رو منتشر کنی(از رابط کاربری گرفته تا ابزارهای مدیریتی و همه‌ی چیزای مربوطه). این لایسنس OpenSource محسوب نمیشه و همین باعث شد که کامیونیتی انتقادات زیادی رو متوجه این نرم‌افزارها بکنن و برن سراغ اینکه یه فورک اوپن سورس درست کنن. طبیعتا شرکت‌های بزرگ هم از این فورک‌های اوپن سورس حمایت کردن. مثلا Valkey که فورک ردیسه یا OpenSearchکه فورک Elastic هست سر همین داستانا به وجود اومدن. حالا ردیس اومده نسخه‌ی 8 رو با لایسنس AGPLv3 ارائه کرده که یک لایسنس اوپن‌سورس محسوب میشه و به نسبت SSPL سخت‌گیری کمتری داره. قبل از ردیس الستیک سرچ هم لایسنسش رو برگردونده بود و اونم اوپن سورس شده بود دوباره. برای جزئیات بیشتر می‌تونید به لینک مطالبی که در بالای پست قراره گرفته مراجعه کنید. ✴️ @software_inside - مهندسی‌نرم‌افزار1,68%
11 окт. 2025 г.#talk #postgres Hands On PostgreSQL 18 هفته‌ی پیش نسخه‌ی جدید پستگرس منتشر شده و تغییرات زیادی داشته. ارائه‌ی پایین خیلی خوب این تغییرات رو توضیح میده و با نسخه‌های قبلی مقایسه می‌کنه و بنچ‌مارک میگیره. دوتا از چیزایی که به نظرم جالب اومد این دوتاست: مورد اول Async I/O: از این نسخه به بعد شما می‌تونید IO های دیتابیس رو به صورت Async انجام بدید. به صورت پیشفرض پستگرس سه تا پراسس دیگه برای هندل کردن IO میاره بالا که اینا IO رو انجام میدن؛ این روش کوئری‌ها رو بهتر می‌کنه اما بهترین نیست. اگر روی لینوکس باشید و نسخه‌ی کرنل +6.5 باشه می‌تونید از سیستم‌کال‌های io_uring استفاده کنید که اسکن‌ها رو خیلی خیلی سریع‌تر میکنه. توی ارائه تنظیم کردنش و بنچ‌مارک‌هاش رو نشون میده. مورد دوم Btree skip scan هست. تا الان اگر شما روی سه تا فیلد ایندکس میذاشتید(مثلا به ترتیب روی a و b و c)، اگر کوئری میزدید که b توش بود ولی a نبود از این ایندکس استفاده نمیشد. در واقع همیشه یه prefix ایی از فیلدهایی که ایندکس کردید باید توی کوئریتون می‌بود تا این ایندکس استفاده بشه. اما توی نسخه‌ی 18 این قابلیت اضافه شده که این ایندکس‌ها توی کوئری‌هایی که prefix ندارن هم استفاده بشه. مثلا توی مثال ما اگر فقط روی b کوئری بزنید بازم از این ایندکس استفاده میشه. این قابلیت مخصوصا وقتی cardinality ستون‌های اول کمتره باعث میشه به ایندکس‌های کمتری نیاز داشته باشید. YouTube: Hands On PostgreSQL 18 ✴️ @software_inside - مهندسی‌نرم‌افزار1,62%
11 нояб.Transactional Outbox Pattern فرض کنید یه مولفه‌ای دارید که باید توی دیتابیس یه سری رکورد رو تغییر بده و بعدش نتیجه رو بفرسته داخل یه بروکری مثل کافکا یا RabbitMQ. برامون مهمه که این فرایند کلا atomic باشه و ارسال پیام و آپدیت دیتابیس یا کلا انجام بشن یا انجام نشن. چون دوتا سیستم مختلف داریم(مثلا Postgres و RabbitMQ) استفاده‌ از قابلیت تراکنش هر کدومشون به تنهایی کافی نیست و اینا باید باهم ترکیبی کار کنن تا واقعا تراکنشی که میخوایم اتفاق بیافته. توی این شرایط چی کار میشه کرد؟ یکی از راه‌هایی که وجود داره استفاده از Outbox pattern هست. توی این روش میگه بیاین مولفه رو به دوتا پراسس بشکونید. پراسس اول کارهایی که لازمه رو انجام بده و به جای اینکه پیام رو مستقیما به بروکر بفرسته، به جاش توی یه جدولی به اسم outbox بیاد یه پیامی که باید فرستاده بشه رو insert کنید. اینطوری چون فقط یه دیتابیس دارید می‌تونید از قابلیت تراکنش اون سیستم به تنهایی استفاده کنید. پراسس دوم که ما بهش میگیم Message Relay کارش اینه که از جدول outbox پیام‌ها رو بخونه و بفرسته به بروکر و بعد پاکشون کنه. اینطوری مشکل داشتن تراکنش بین دوتا سیستم مختلف حل میشه. مشکلش چیه؟ مشکل اینه که Message Relay ممکنه فیل بشه یا وسط کار ری‌استارت بشه و یه پیام رو دوبار بفرسته. برای همین مهمه که توی سمت گیرنده idempotent باشه و حواسش به پیام‌های duplicate باشه. البته مستقل از این پترن، توی سیستم‌های توزیع شده این idempotent بودن سمت کانسیومر رو خوبه کلا رعایت کنیم چون فرض Exactly Once معمولا خیلی سخته و بروکرها معمولا At least once delivery رو گارانتی می‌‌کنن که بازم نیاز به idempotent بودن کانسیومر داره. به جز روش Outbox برای این مسئله روش‌های دیگه‌ای مثل پترن CDC یا two phase commit هم هست که اونا پیچیده‌تر هستن و پیاده‌سازیشون دردسر بیشتری داره. مطلب پایین این پترن رو به خوبی باز کرده و توضیح داده: https://microservices.io/patterns/data/transactional-outbox.html #pattern #microservices ✴️ @software_inside - مهندسی‌نرم‌افزار1,37%
13 мар. 2025 г.#بازی https://www.sqlnoir.com/ یه بازی باحال که شما در نقش کارآگاه هستید و با زدن SQL query و گشتن توی جدول‌های دیتابیس باید معماها رو حل کنید. برای تقویت raw sql زدن خوبه.1,22%
2 авг. 2025 г.#مطلب Time to upgrade your monitor https://tonsky.me/blog/monitors/ 🖥 برای برنامه‌نویسی چه مانیتوری داشته باشیم خوبه؟! مطلب بالا مفصل به این قضیه می‌پردازه و یه سری پیشنهاد در این زمینه میکنه که پایین همین پست خلاصش رو نوشتم. یکی از چیزایی که مهمه Text Clarity و کیفیت نمایش متن‌هاست. خیلیا فک میکنن resolution تنها ملاک کیفیته و اگر مثلا صفحه‌ای FullHD باشه کیفیتش خوبه. اما این همه‌ی ماجرا نیست! 1. برای اینکه کیفیت نمایش بالا بره باید چگالی پیکسل‌های صفحه یا Pixels Per Inch بیشتر باشه. مثلا یه مانیتور 24 اینچ FullHD دارای 92 پیکس در هر اینچه در صورتی که مانیتور 27 اینچ دارای 82 پیکسل در هر اینچه و کیفیتش از 24 اینچ کمتره. هرچه PPI بیشتر باشه، جزئیات بهتر نمایش داده میشه و کیفیتش بالاتر میره. 2. دومین موردی که مهمه فاصله‌ی چشم ما تا ماینتوره، هرچقدر ما صفحه رو نزدیک‌تر به چشممون بذاریم پیکسل‌هاش بیشتر توی چشم میزنه و کیفیت پایین‌تر جلوه میکنه. برای همینه که چگالی پیکسل توی گوشی‌های موبایل معمولا از مانیتورها خیلی بیشتره. چون آدما صفحه‌ی موبایل رو خیلی نزدیک به چشم میگیرن و اگر PPI پایین باشه به راحتی پیکسل‌های تصویر مشخص میشه و توی ذوق میزنه. اگر فاصلتون از صفحه به حدی باشه که چشمتون نتونه پیکسل‌ها رو از هم تشخیص بده، اصطلاحا میگن شما در فاصله Retina هستید. این کلمه توسط اپل معرفی شده. برای اینکه یه صفحه‌ی 24 اینچ FullHD به صورت رتینا به نظر برسه شما باید از فاصله 94 سانتی متری بهش نگاه کنید! 3. سومین موردی که مهمه میزان refresh rate مانیتور هست که با واحد Frame per second سنجیده میشه. هرچقدر FPS بالاتر باشه تغییرات رو نرمتر و روونتر می‌بینید. این قضیه مخصوصا برای زمانی که دارید متن‌ها رو اسکرول میکنید به چشم میاد. حالا مطلب بالا به صورت کامل نکات مهم رو توضیح میده و درنهایت توصیه‌های زیر رو میکنه: - مانیتور حداقل 4K باشه - حداقل FPS برابر با 120hz باشه - از Integer Scaling استفاده کنید(توضیح کاملش توی متن هست. من برای بزرگ نشدن پست اینجا توضیحش نمی‌دم) پیشنهاد خودم اینه که ماینتور 27 اینچ باشه. چون نه خیلی کوچیکه نه خیلی بزرگ. همچنین برای اینکه صفحه رتینا به نظر بیاد باید فاصله 53 سانتی از مانیتور داشته باشید که فاصله نرمالیه برای یه مانیتور. توی سایت زیر توضیحات کاملی در مورد PPI و فاصله retina وجود داره. عکس جدول فواصل رو توی پست گذاشتم. لینک تجربه‌ی شما توی این زمینه چیه؟ چقدر موافقید با این مطلب؟ ✴️ @software_inside - مهندسی‌نرم‌افزار1,22%
27 июн. 2025 г.پاسخ به یک سوال معروف مصاحبه ها: وقتی گوگل رو در مرورگر باز می‌کنیم چه اتفاقی میوفته؟ این مطلب یه جواب خیلی کامل و مفصل به این سوال ارائه داده ولی قاعدتا تو مصاحبه با این عمق فرصت نمیشه بگیم :)) https://github.com/alex/what-happens-when1,09%
24 мар. 2025 г.#معرفی #serialization MsgPack: It's like JSON but fast and small. یه فرمت کمتر شناخته شده‌ای وجود داره به اسم MsgPack که بعضا توی طراحی سیستم‌ها به کار میاد. این فرمت شبیه به JSON هست و بدون Schema کار می‌کنه. دوتا مزیت داره: یکی اینکه حجمش کمتره و compact تر هست و مزیت بزرگ دومش اینه که به صورت binary هست و برخلاف JSON لازم نیست حتما داده‌ها UTF8 باشن و decode شده باشن. همین قضیه باعث میشه که سرعت serialize شدنش بیشتر باشه و داده های خام رو هم می‌تونیم باهاش جابجا کنیم. برای دید بهتر به عکس بالا توجه کنید. بدیش اینه که human-readable نیست. این فرمت توی تکنولوژی‌هایی مثل redis یا fluentd هم استفاده میشه و جاهایی که انعطاف برامون مهمه و human-readable بودن برامون مهم نیست یا میخوایم داده‌های binary و دیکد نشده جابجا کنیم به کار میاد. ❇️ @software_inside1,07%
15 мар. 2025 г.#ابزار برای اینکه متوجه بشیم یه کوئری روی دیتابیس چطوری داره اجرا میشه یا چرا کنده معمولا از اون کوئری explain می‌گیریم و سعی می‌کنیم از روی خروجی explain این چیزا رو متوجه بشیم. متاسفانه خوندن خروجی خام این دستور مخصوصا وقتی پارامترهایی مثل analyze یا buffer و ... رو استفاده کردیم خیلی کار ساده‌ای نیست و خروجیش ممکنه خیلی بزرگ بشه. برای مثال یه نمونه از خروجی خام رو توی عکس‌ها می‌بینید. https://explain.dalibo.com https://explain.depesz.com/ دوتا سایت بالا با گرفتن خروجی explain، گزارش‌های خوبی تولید می‌کنه و باعث میشه راحت‌تر متوجه بشیم چه اتفاقی داره میافته. مخصوصا سایت اولی که به صورت گرافیکی نمودار می‌کشه و interactive هم هست.1,04%
1 июн. 2025 г.#مطلب Here’s how I use LLMs to help me write code https://simonwillison.net/2025/Mar/11/using-llms-for-code/ با اومدن LLM ها و ابزارهایی مثل Cursor و Windsurf نحوه‌ی کد زدن خیلی از مهندسان نرم‌افزار هم عوض شده و استفاده از این ابزارها به بخشی از کارهای روزمره تبدیل شده. از طرفی استفاده‌ی درست از LLM ها به گونه‌ای که بتونیم بهترین بهره‌وری رو داشته باشیم کار ساده‌ای نیست و نیاز به آزمون و خطا و تجربه کردن داره. مقاله‌ی بالا به همین موضوع می‌پردازه و سعی میکنه به ما کمک کنه که چطوری بهتر از LLM ها توی کد زدن استفاده کنیم. چندتا نکته‌ی کوتاه که جالب بود رو اینجا آوردم ولی پیشنهاد میکنم حتما مقاله‌ی اصلی رو بخونید: - هوش مصنوعی یه دستیار خوب و سریعه ولی با اعتماد به نفس بیش از اندازه: با اینکه خیلی از چیزا رو درست میگه اما یکسری از چیزها رو هم با اعتماد به نفس کامل اشتباه میگه و ممکنه شما رو کلا گمراه کنه. اگر یک انسان اینکار رو انجام بده احتمالا شما اعتمادتون رو بهش از دست میدید و دیگه چیزی رو ازش نمی‌پرسید اما با هوش مصنوعی نباید مثل یه انسان برخورد کرد! در عوض بهتره نقاط قوت و ضعف مدل‌های مختلف رو بشناسیم و یادبگیریم که چیا رو می‌تونن انجام بدن و توی چه چیزهایی خوب نیستن - تاریخ cuttoff رو حتما مد نظر قرار بدید تاریخ cutoff نشون میده اطلاعاتی که مدل روش آموزش دیده چقدر بروز بوده. برای مثال اگر cutoff یه مدلی 2023 باشه احتمالا تغییراتی که توی 2025 اتفاق افتاده رو نمی‌دونه یا بد عمل میکنه. البته با اومدن قابلیت tools و سرچ کردن این مشکل بهتر شده اما همچنان اگر مدل روی داده‌های جدیدتر آموزش دیده باشه بهتر می‌تونه جواب بده. خوبه زمان cutoff مدلی که استفاده می‌کنید رو بدونید. برای همین هرچقدر از کتابخونه‌های معروف‌تر که توی اینترنت درموردشون دیتای بیشتری هست استفاده کنید احتمالا LLM ها بیشتر می‌تونن بهتون کمک کنن. - کانتکست خیلی مهمه! جواب مدل‌ها خیلی خیلی وابسته به این هست که چه چیزی رو توی پیام‌های قبلی براشون فرستادید. تمامی پیام هایی که بین شما و مدل رد و بدل میشه توی کانتکست مدل هست و اونا رو میدونه. برای همین خیلی مهمه که کانتکست خوبی بهش بدید. مثلا اگر میخواید یه کار بزرگی بهش بدید خوبه اول یه iteration کوچیک باهاش برید و بهش بگید کم کم پیچیدش کنه و قسمت‌های مختلفش رو بزنه. اینطوری چون تمامی کدها و کانتکست قبلی رو داره می‌تونه بهتر جواب بده - مدل‌های زبانی برای prototype زدن و تست گرفتن ایده‌های مختلف خیلی خوبن - هنگام استفاده از مدل‌ها توی کد پروداکشن محافظه‌کارتر باشید توی کدهای پروداکشن بهتره دقیقا به LLM بگید چی‌میخواید و با جزئیات براش توضیح بدید. کدهایی که LLM میزنه به نظر درست میاد، اسم متغیرها درسته اسم توابع به نظر درست میاد اما این نباید شما رو گول بزنه. حتما حتما باید کدهای LLM رو تست کنید و درستی یه کدی رو تا با چشمتون ندیدید باور نکنید. احتمال اینکه باگ‌های ریز توی جاهای مختلف باشه زیاده که به چشم نمیان. همچنین اگر تست‌ها رو میدید که خود LLM بزنه خوبه خیلی دقیق کدهای تست رو بررسی کنید که چه چیزی رو دارن تست میکنن. - آماده‌ی مداخله‌ی انسانی باشید! مدل‌های زبانی قرار نیست جای تجربه و شهود شما رو بگیرن. بزرگ‌ترین مزیت این مدل‌ها سرعت زیادشون هست اما خیلی جاها باید آماده باشید که مداخله کنید و یه تغییراتی رو خودتون اعمال کنید. قرار نیست سر تا ته یه پروژه رو بدید LLM بزنه. داخل مقاله کلی مثال و prompt و نکته‌ی باحال دیگه هم هست که من اینحا نیاوردم و پیشنهاد میکنم حتما مقاله‌ی اصلی رو بخونید. ✴️ @software_inside - مهندسی‌نرم‌افزار0,61%
17 мар. 2025 г.#ابزار برای اینکه متوجه بشیم یه کوئری روی دیتابیس چطوری داره اجرا میشه یا چرا کنده معمولا از اون کوئری explain می‌گیریم و سعی می‌کنیم از روی خروجی explain این چیزا رو متوجه بشیم. متاسفانه خوندن خروجی خام این دستور مخصوصا وقتی پارامترهایی مثل analyze یا buffer…0,54%
7 мар. 2025 г.#مطلب HBase Deprecation at Pinterest در سال‌های اخیر HBase نقش کلیدی و جدی توی زیرساخت Pinterest داشته و بسیاری از سرویس‌های پینترست بر مبنای HBase بنا شده بوده. برای مثال پینترست بر روی Hbase دیتابیس Zen رو ساخته بوده که داده‌های گرافی رو نگه میداره، از OpenTSDB که باز یه دیتابیس رو HBase هست برای نگهداری داده‌های TimeSeries استفاده می‌کرده و ... اما اخیرا یه پستی توی بلاگ فنیشون گذاشتن که قراره HBase رو بازنشسته کنن و به جاش مهاجرت کنن به دیتابیس‌های جدیدتر. قرارشده داده‌های OLAP رو به Druid/Starrocks و داده‌های KeyValue رو به KVStore و داده‌های گرافی رو به Goku منتقل کنن(دوتای آخری دیتابیس‌های درونی خود پینترست هست). و برای باقی نیازمندی‌هاشون قراره داده‌های Hbase رو مهاجرت بدن به یه NewSQL به اسم TiDB. دلیلی که دارن HBase رو بازنشسته می‌کنن هزینه‌ی زیاد نگهداری، کمبود امکانات لازم ( مثل Secondary Index و distributed transactions) و کوچیک‌شدن کامیونیتی و پیدانشدن نیروهای expert هست(qoute پایین از مقاله در همین مورد جالبه). For the past few years, we have seen a seemingly steady decline in HBase usage and community activity in the industry, as many peer companies were looking for better alternatives to replace HBase in their production environments. This in turn has led to a shrinking talent pool, higher barrier to entry, and lower incentive for new engineers to become a subject matter expert of HBase. لینک مقالات: Part1: HBase Deprecation at Pinterest Part2: TiDB Adoption at Pinterest Part3: Structured DataStore (SDS): Multi-model Data Management With a Unified Serving Stack Online Data Migration from HBase to TiDB with Zero Downtime ✴️ @software_inside - مهندسی‌نرم‌افزار0,48%