خب حالا که تا اینجا اومدیم و راجع بهش حرف زدیم، درباره‌ی بردار (Vector) یکم بیشتر بگم.

ما وقتی بخوایم این بردار رو توی دیتابیس ذخیره کنیم، باید یه راه درست انتخاب کنیم. چون بردار در واقع فقط یه لیست عددیه، پس چندتا روش داریم:

1️⃣ ذخیره به صورت JSON یا Array
ساده‌ترین راه اینه که کل بردار رو به شکل JSON بریزیم توی دیتابیس.
مثلاً:

[0.0607, 0.0451, 0.0398, 0.0362]

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

2️⃣ استفاده از ابزار مخصوص در دیتابیس‌ها
مثلاً PostgreSQL یه افزونه داره به اسم pgvector که بردار رو مستقیم به عنوان نوع داده ذخیره می‌کنه.
اینجوری می‌تونیم راحت توی همون دیتابیس روی بردارها جستجوی شباهت انجام بدیم (Cosine, Euclidean و …).

3️⃣ دیتابیس‌های مخصوص برداری (Vector Database)
وقتی دیتا خیلی زیاد باشه (مثلاً میلیون‌ها بردار)، باید بریم سراغ دیتابیس‌هایی مثل Pinecone، Weaviate یا Milvus.
این‌ها دقیقاً برای همین ساخته شدن.
جستجوی خیلی سریع و بهینه روی بردار ها.

من توی پروژه ای که داشتم از pgvector استفاده کردم که یک چالش خیلی کوچیک با typeorm داشت که حلش کردم و اگه دوستان خواستن میتونم شرحش بدم.

دشمن درجه یک ایرانی ها فقط گوگل!
لامصب بعضی از سرویس هات با VPN هم دیگه بالا نمیاد چیکار داری می‌کنی با خودت؟

Calm down bro!

سایت grow.google/career-dreamer ساخته شده توسط گوگل ، با اطلاعاتی که از علاقه و تجربه کاریتون می‌گیره، شغل های مناسب شما رو بهتون پیشنهاد می‌کنه.
نتایجش برای من خیلی جالب بود، پیشنهاد می‌کنم شما هم حتما امتحان کنید 👌

❗️با IP آمریکا وارد بشید.

🔺 برنامه‌نویسی کوانتومی (Quantum Programming)

برنامه‌نویسی کوانتومی بر پایه قوانین مکانیک کوانتوم ساخته شده. به جای بیت‌های کلاسیک (۰ و ۱)، در اینجا با کیوبیت سروکار داریم؛ کیوبیت می‌تونه همزمان در چند حالت باشه (به این می‌گن Superposition) و حتی با کیوبیت‌های دیگه Entanglement پیدا کنه. همین ویژگی‌ها باعث می‌شه بعضی محاسبات خیلی سریع‌تر از کامپیوترهای معمولی انجام بشه.

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

🔺 برای نوشتن برنامه‌های کوانتومی، زبان‌ها و فریم‌ورک‌های مخصوصی وجود داره:

- Qiskit (مبتنی بر پایتون)
- Quipper (مبتنی بر Haskell)
- Cirq (از گوگل)

و این برنامه‌ها روی پردازنده‌های کوانتومی مثل IBM Quantum یا Google Sycamore اجرا می‌شن.

تو این دنیا به جای دستورهای کلاسیک، از گیت‌های کوانتومی (مثل Hadamard, CNOT, Pauli-X و...) استفاده می‌کنیم. همین ابزارها پایه‌ی کاربردهای بزرگی مثل رمزنگاری نسل بعدی، بهینه‌سازی، شبیه‌سازی سیستم‌های فیزیکی و شیمیایی هستن. البته تکنولوژی هنوز در مراحل اولیه رشدشه.

🔺 برنامه‌نویسی کوانتومی در خانه: واقعاً ممکنه؟

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

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

🔺 زبان‌های برنامه‌نویسی کوانتومی

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

برخلاف زبان‌های کلاسیک، این زبان‌ها از مفاهیم ویژه کوانتوم مثل Superposition (هم‌زمان بودن در چند حالت)، Entanglement (درهم‌تنیدگی) و Quantum Parallelism (محاسبات موازی کوانتومی) پشتیبانی می‌کنن.

این زبان‌ها به پژوهشگرها و توسعه‌دهنده‌ها کمک می‌کنن برنامه‌های کوانتومی واقعی بنویسن و حتی بتونن اون‌ها رو با کدهای کلاسیک ترکیب کنن. نتیجه این ترکیب، سیستم‌های هیبریدی (کوانتوم + کلاسیک) هستن که فعلاً اصلی‌ترین مسیر توسعه کاربردهای کوانتومی به حساب میان.

https://www.bluequbit.io/quantum-programming-languages

https://learn.microsoft.com/en-us/azure/quantum/qsharp-overview

اینجا quickstart با #Q وجود داره و پیشنهاد میکنم حتمی یک نگاهی بهش بندازید‌:

https://learn.microsoft.com/en-us/azure/quantum/qsharp-quickstart

در رابطه با پستمون درباره Embedding که قبلا نوشته بودم.

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

دقیقا حرف دل من بود که می‌خواستم در این چنل اشاره کنم.
زمانی که محتوای تخصصی تر و مفید تری می‌ذارم ، می‌بینم استقبال خاصی ازش نمیشه و چه بسا که چنل ریزش هم می‌کنه.

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

‏TCP چیست و چطور کار می‌کنه؟


تو دنیای شبکه‌های کامپیوتری، اگه بخوایم داده‌ای رو از دستگاهی به دستگاه دیگه‌ای بفرستیم، نیاز به یه سیستم مطمئن داریم که خیالمون رو راحت کنه.
اینجاست که TCP وارد عمل میشه. این بزرگوار مخفف "Transmission Control Protocol" هست (پروتکل کنترل انتقال) که یکی از مهمترین پروتکل‌های لایه انتقال (Transport Layer) توی مدل OSI و TCP/IP هست. این پروتکل برای انتقال داده بین دو دستگاه (مثلا کلاینت و سرور) طراحی شده و یک سری ویژگی خاص داره که باعث میشه قابل اعتماد، منظم، و کارآمد باشه.

مقاله کامل در :
https://vrgl.ir/V097m

تفاوت هاست، سرور مجازی، اختصاصی و ابری

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

🔹 هاست اشتراکی (Shared Hosting)
در هاست اشتراکی یک سرور فیزیکی بین صدها وب‌سایت تقسیم می‌شود.
شما کنترل محدودی دارید و منابع (CPU، RAM) بین همه‌ی سایت‌ها مشترک است.

مثال: مثل این است که در یک خوابگاه زندگی می‌کنید. اتاق دارید ولی آشپزخانه و حمام را با بقیه شریک هستید.

مناسب: وب‌سایت‌های ساده مثل وبلاگ، سایت شخصی یا شرکتی کوچک.

🔹 سرور مجازی (VPS – Virtual Private Server)
یک سرور فیزیکی با نرم‌افزار مجازی‌سازی به چند ماشین مجازی تقسیم می‌شود و هر کدام منابع مشخص و جداگانه دارند.

مثال: مثل یک آپارتمان در یک برج. هرکسی واحد خودش را دارد و می‌تواند داخل آن هر طور خواست تغییر بدهد.

مزیت مهم: دسترسی کامل (Root Access)، امکان نصب نرم‌افزار دلخواه، منابع تضمین‌شده.

مناسب: فروشگاه اینترنتی، پروژه‌های نیمه‌حرفه‌ای و استارتاپ‌های کوچک.

🔹 سرور اختصاصی (Dedicated Server)
در این حالت کل سرور فیزیکی فقط برای شماست.

مثال: مثل این است که کل ساختمان مال شماست. هیچ همسایه‌ای ندارید و کنترل کامل دارید.

مزایا: حداکثر قدرت، امنیت و آزادی در پیکربندی.

مناسب: پروژه‌های بسیار بزرگ، اپلیکیشن‌های پرترافیک، سرویس‌های حساس.


🔹 سرور ابری (Cloud Server / Cloud Hosting)
سرور شما روی یک زیرساخت توزیع‌شده (چندین سرور در دیتاسنترهای مختلف) اجرا می‌شود. اگر یک سرور از کار بیفتد، سرور دیگری جایگزین می‌شود و سایت شما همیشه آنلاین می‌ماند.

مثال: مثل این است که به جای داشتن یک خانه، چند خانه در چند شهر دارید؛ اگر یکی خراب شود، سریع می‌روید سراغ بعدی.

مزیت مهم: مقیاس‌پذیری سریع (می‌توانید منابع را در لحظه کم و زیاد کنید)، پایداری بسیار بالا.

مناسب: استارتاپ‌هایی که رشد سریع دارند، اپلیکیشن‌های جهانی و پروژه‌هایی که قطعی نباید داشته باشند.

داشتم به این فکر می‌کردم که این نظرات درون سایت هایی که می‌تونی داخلش راجع به سرویس ها ، شرکت ها و .. امتیاز بدی و نظرت رو بنویسی چقدر معتبرن؟
اگه دقت کرده باشید متوجه میشید که همه شرکت ها و سرویس ها منفی‌اند.

و خب منطقی هم هست نه؟
مثلا اگه من از کیفیت یک اینترنت پروایدر راضی باشم ، نمی‌رم بدو بدو یه سایت پیدا کنم نظرم رو بنویسم بگم عاااالیه 😂

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

هستن آدم هایی که مخصوصاً برن نظر مثبت بدن؟

همیشه ما همه تلاش داریم کد با Performance خوب توسعه بدیم بدون این که این موضوع رو تصور کنیم که داخل کدبیس های #JavaScript معمولا Performance شوخیه.
ولی امروز قراره درمورد یک ویژگی جدید که در آپدیت ES2025 به #JavaScript اضافه شده صحبت کنیم که بهمون کمک میکنه که Performance بهتری داشته باشیم. سمت #NodeJS در بیزینس لاجیک های پیچیده میتونه معجزه کنه. برای #FrontEnd هم کاربردی هست ولی باتوجه به این که مرورگر های قدیمی ساپورت نمیکنن خب قطعا به این زودی استفاده ازش رو نمیبینیم.
ویژگی جدید ما اضاف شدن یک static method جدید به Iterator هست.

Iterator.from()

حالا سوال پیش میاد که چطور این به ما کمک میکنه. فرض کنید یک array بزرگ دارید و میخواید data رو map کنید به یک شکل دیگه و برای این کار یک pipeline از map ها رو ایجاد کردید:

const data = [1, 2, 3, 4, 5];

const final = data
  .map((item) => item.toString())
  .map((item) => `- ${item} -`)
  .map((item) => `${item} ${new Date()}`);

در نگاه اول مشکلی نداره ولی اگر با عینک Performance ببینیم دوتا مشکل میبینیم.
1. برای هر map مجبوریم یکبار کامل loop بزنیم خب 3 بار loop میزنیم پس داریم O(3n)
2. هربار که یک loop کامل میزنیم هربار داریم یک Array جدید بعد از map ایجاد میکنیم. به صورت خلاصه هر .map برابر هست با یک Array allocation جدید. خب اینجا یک array اورجینال داریم و 3 تا map پس 4 تا array allocation داریم.
ممکنه برای تازه کارترها سوال های زیر پیش بیاد:
1. خب چرا اصلا این استایل کد میزنیم؟
2. چرا همه رو داخل یک map انجام نمیدیم؟

پاسخ سوال اول:
- میتونیم با for ... of کار رو بهتر با یک loop در بیاریم ولی مسئله این هست که معمولا برنامه نویس های #JavaScript در اینجور مواقع حتی بدون این که خودشون بدونن دیدگاه Functional Programming دارن و خب از اونجایی که به صورت فلسفی FP ذات Declarative داره و به صورت فلسفی کار کردن با API ها Declarative خیلی راحت تر و لذت بخش تر از Imperative هست همچین چیزی رو میبینیم.
- اگر هم خیلی کنجکاوید بیشتر بدونید وقتش هست نگاهی به #Elixir #Scala یا حتی Lambda ها در #Java اونجا قشنگ متوجه میشید. یا اصلا مسیر رو برعکس برید و نگاهی به رویکرد #Golang کنید و فرق زمین تا آسمونی رو ببینید.
پاسخ سوال دوم:
- در بزینس لاجیک های پیچیده برای خوانایی کد داشتن map های بیشتر خیلی بهتر از این هست که یک map بزرگ داشته باشیم. منطقی هم هست چون خیلی بهمون God Object ها رو یادآوری میکنه.

خب حالا سوال پیش میاد چیکار کنیم؟ خیلی ساده هست کافیه فقط خط اول رو به این شکل عوض کنیم و array رو تبدیل کنیم به Iterator.

const data = [1, 2, 3, 4, 5, 6]; ❌
const data = Iterator.from([1, 2, 3, 4, 5, 6]); ✅

خب دوباره الان سوال پیش میاد که WTF الان چی شد؟ سادس.
ما دیتا رو تبدیل کردیم به یک Iterator که ذات Iterator ها به صورت Lazy هست یعنی تا وقتی که نیاز به consume شدن data نباشه هیچ پردازشی انجام نمیشه و اگر هم نیاز به map کردن باشه دقیقا در runtime به صورت on-demand برای هر index تبدیل انجام میشه و ما نیازی به alloc کردن حافظه اضافه برای Array نداریم و هیچ loop اضافه ای هم درکار نیست.

حالا به این نکات توجه کنید:
- هر iterator رو فقط یکبار میشه consume کرد و اگر نیاز باشه باید دوباره ازش بسازی. در حقیقت با .toArray داریم consume کردن رو شبیه سازی میکنیم و دومی مقدار خالی به ما میده به خاطر iterator بودن.

const data = Iterator.from([1, 2, 3, 4, 5, 6]);

data.toArray()
data.toArray()

- در این قسمت به map ها باید توجه کرد که با هر بار call شدن یک Array جدید نمیسازن بلکه یک Iterator جدید که روی Iterator قبلی سوار هست رو به ما میده! پس در نتیجه با توجه به تعریف Iterator که بالاتر گفتم نه loop اضافه ای داریم و نه alloc اضافه.

const data = Iterator.from([1, 2, 3, 4, 5, 6]);

const final = data
  .map((item) => item.toString())
  .map((item) => `- ${item} -`)
  .map((item) => `${item} ${new Date()}`);

حالا اگر یکم بیشتر دقت کنی میبینیم خیلی شبیه به stream ها هست. اصلا این دوتا api به شدت باهم سازگار هستن. در این حد که استریم ها رو میشه تبدیل کرد به iterator و برعکس. بقیه کد هم دقیقا به صورت مشابهه کار میکنه.

import { Readable } from "node:stream";
const data = Iterator.from([1, 2, 3, 4, 5, 6]);
const streamData = Readable.from(data);

دل نوشته:
حقیقتا دیگ نمیشه تفاوت بین stream, iterator, generator, rxjs, web stream, رو تشخیص داد😂. همشون رو میتونی جایگزین هم استفاده کنی. ( دلایل مختلفی برای وجود این همه api برای یک کار هست )

🧠 تفاوت SSR و CSR و تأثیرش روی سئو

توی CSR (Client Side Rendering)، سرور یه فایل HTML ساده (معمولاً خالی) می‌فرسته. مرورگر بعدش باید کلی فایل JavaScript رو دانلود و اجرا کنه تا محتوای صفحه ساخته بشه. این یعنی محتوای واقعی دیرتر به دست ربات‌های موتور جستجو می‌رسه و ممکنه ایندکس شدن صفحه عقب بیفته.

ولی توی SSR (Server Side Rendering)، سرور همون اول محتوای صفحه رو رندر می‌کنه و یه HTML کامل می‌فرسته.
در این صورت:

محتوای صفحه همون اول تو پاسخ رندر میشه.

ربات جستجو لازم نیست صبر کنه تا JS اجرا بشه، همون اول محتوا رو می‌خونه.

ایندکس شدن و رتبه گرفتن سریع‌تر انجام می‌شه.


نمونه تکنولوژی‌ها و فریم‌ورک‌هایی که SSR دارن:

‏ Next.js برای React

‏ Nuxt.js برای Vue

‏ Angular Universal برای Angular

‏ Sapper / SvelteKit برای Svelte

به همین دلیله که SSR برای سایت‌هایی مثل فروشگاه، بلاگ یا هر جایی که محتوای عمومی داره و می‌خوایم تو گوگل دیده بشه خیلی به درد می‌خوره. ولی برای اپلیکیشن‌های داخلی یا داشبوردها که ایندکس شدن مهم نیست، همون CSR کافی هست.

یه جاهایی دیدم بعضی از دوستان سر اینکه از چه لایبرری برای UI پروژه استفاده کنند خوبه بحث می‌کردن.

موردی که هست اینه که اگه شما پروژتون UI داره و دارین طبق اون پیش میرین ، اصلا منطقی نیست از هیچ لایبرری استفاده کنین! و خودتون باید کامپوننت هاش رو بنویسین.

مگر اینکه UI پروژه طبق همون لایبرری طراحی شده باشه.

وگرنه از نظر من کاستومایز کردن کامپوننت های یک لایبرری برای یک UI اختصاصی نه تنها منطقی نیست ، بله غیر حرفه ای هم هست.

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

با این حال چه مفصل چه غیر مفصل سعی می‌کنم بذارم مطالب رو.

یکشنبه هم به الکامپ میرم اگه اونجا بودید خوشحال میشم ببینمتون.

طبق تجربه ای که در استفاده از این مدل داشتم خیلی راضی کننده نبود برام.
به جاش مدل BGE-M3 رو پیشنهاد می‌کنم که با 567M پارامتر خیلی بهتر عمل کرد.
(منظورم از بین مدل های Open Source هست)

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

دیدم ناخودآگاه دارم از آرایه استفاده می‌کنم! شاید تعداد صفحاتی که برای هر موضوع انتخاب می‌کنم کم و بیش بشه و دفتر من هم که محدوده.

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

به شما هم پیشنهاد می‌کنم که در این مواقع از لیست پیوندی استفاده کنید 😁

پ.ن:البته این برای من جواب میداد چون بیشتر می‌نویسم تا بخونم. اگه شما بیشتر می‌خونید تا بنویسید ، بذارید روی همون آرایه بمونه.

خب دوستان
تا چند دقیقه دیگه یک پوششی از بازدیدی که از الکامپ کردم خواهیم داشت.