Syntax | سینتکس

آیا کشتی نرم‌افزار شما هم مثل تایتانیک غرق میشه؟ پترن Bulkhead اصطلاح Bulkhead از مهندسی کشتی سازی می آید. در قدیم، بدنه کشتی‌ها یک فضای خالی بزرگ و یکپارچه بود. اگه صخره‌ای به بدنه می‌خورد و سوراخی ایجاد می‌شد، آب وارد می‌شد، کل فضای زیر کشتی پر از آب می‌شد و کشتی غرق می‌شد (مثل تایتانیک). مهندسان راه‌حل رو پیدا کردند: تقسیم فضای داخلی به اتاقک‌های جداگانه و ضدآب. حالا اگه بدنه سوراخ بشه، فقط همون یک اتاقک پر از آب میشه. درهای اون اتاقک بسته میشه و بقیه کشتی خشک و شناور میمونه. در نرم افزار بدون Bulkhead: فرض کنید یک فروشگاه آنلاین دارید: ۱. سرویس خرید محصول(حیاتی) ۲. سرویس پیشنهاد محصولات(سنگین و وابسته به هوش مصنوعی) بدون Bulkdhead تمام منابع سرور(ترد ها، کانکشن های دیتابیس و سی پی یو و ..) در یک استخر مشترکن. اگه سرویس پیشنهاد محصولات کند بشه، تمام منابع رو میبلعه. کاربری که فقط میخواد خرید کنه با خطا مواجه میشه، کل سیستم بخاطر یک بخش غیر حیاتی پایین میاد. با پترن Bulkhead: برای هر بخش سهمیه مشخصی تعیین میکنیم و استخر جداگونه خودشون رو دارن. اگه سرویس پیشنهادات خراب بشه و مثلا زیر لود سنگینی باشه، فقط همین بخش دچار مشکل میشه و بقیه بخش ها کارشون رو انجام میدن و استخرشون دست نخورده باقی میمونن. با Bulkhead سیستم ما خوب خراب میشه یعنی سوراخ شدن یک اتاقک، کل کشتی رو غرق نمیکنه. درباره Bulkhead pattern در Azure Architecture Center https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead #buldhead @Syntaxfa

جمنای چقدر داره خفن میشه. الان یهو دیدم آزمونم طراحی میکنه

شما نتفلیکس نیستید! پس چرا از روز اول با پیچیدگی میکروسرویس‌ها خودکشی می‌کنید؟ صنعت نرم‌افزار در حال یک بازگشت عقلانی به سمت معماری‌های یکپارچه مدرن (Modular Monolith) است. جایی که یاد می‌گیریم معماری کد (Logical) باید از معماری استقرار (Physical) کاملا جدا باشه. در اولین مقاله‌ام در ویرگول، با کالبدشکافی پروژه اپن‌سورس Quick Connect، معماری Code-Level Monolith رو معرفی کردم. معماری‌ای که حلقه گمشده بین سادگی و مقیاس‌پذیریه. در این معماری: ۱. امروز: با سرعت بالا و هزینه کم به صورت یکپارچه دپلوی می‌کنید (مناسب برای ۹۰٪ پروژه‌ها). ۲. فردا: بدون بازنویسی کد و فقط با تغییر کانفیگ، ماژول‌های پرفشار رو جدا کرده و میکروسرویس می‌کنید (مثل Grafana Loki). با این رویکرد، یکبار برای همیشه پرونده جنگ مونولیت علیه میکروسرویس رو ببندید! مطالعه کامل مقاله (فارسی و انگلیسی): ویرگول: https://vrgl.ir/JIk5n Dev.to: https://dev.to/alireza_feizi_2aa9c86cac4/code-level-monolith-the-hybrid-architecture-the-art-of-flexible-deployment-2jm2 #modulith @Syntax_fa

خب چرا باید ایشو و فلان باز کنید و لینک کپی کنی😐؟ همین بری داخل خود گیت هاب فایل readme رو ویرایش بزنی و داخل عکسا و فایلاتو درگ کنی توی سرور گیت هاب آپلود میشه و لینک میده بهت بعد تغییر readme رو ثبت میکنی.

💻 Read Phenomena در دیتابیس‌ها: وقتی تراکنش‌ها همزمان روی داده‌ها کار می‌کنند در دنیای پایگاه داده‌ها، وقتی چند تراکنش به‌صورت همزمان روی داده‌ها کار می‌کنند، ممکن است نتایج غیرمنتظره‌ای هنگام خواندن داده‌ها رخ دهد. این رفتارها تحت عنوان Read Phenomena شناخته می‌شوند و می‌توانند باعث شوند داده‌هایی که یک تراکنش می‌خواند، همیشه پایدار یا معتبر نباشند. 🔹 سه نوع اصلی Read Phenomena: 1️⃣ خواندن داده کثیف یا همون Dirty Read تراکنش A یک رکورد را تغییر می‌دهد اما هنوز commit نکرده است. تراکنش B همان رکورد را می‌خواند. اگر تراکنش A بعداً rollback شود، تراکنش B داده‌ای خوانده که واقعی نبوده است. 2️⃣ خواندن غیرتکراری یا همون Non-Repeatable Read تراکنش A یک رکورد را می‌خواند، تراکنش B همان رکورد را تغییر می‌دهد و commit می‌کند. وقتی تراکنش A دوباره همان رکورد را می‌خواند، مقدار آن متفاوت است. 3️⃣ خواندن شبح یا همون Phantom Read تراکنش A مجموعه‌ای از رکوردها را می‌خواند. تراکنش B بین دو خواندن، رکوردی اضافه یا حذف می‌کند. وقتی تراکنش A دوباره همان مجموعه را می‌خواند، نتیجه متفاوت می‌شود. 🔹 راه‌حل: برای کنترل این مشکلات، از سطوح Isolation در SQL استفاده می‌کنیم: Read Uncommitted Read Committed Repeatable Read Serializable هر سطح، تعادل متفاوتی بین کارایی و دقت داده‌ها ایجاد می‌کند. 📌 جمع‌بندی: درک Read Phenomena کمک می‌کند تا سطح Isolation مناسب انتخاب شود و از مشکلاتی مثل محاسبات نادرست، داده‌های ناقص یا تداخل تراکنش‌ها جلوگیری شود که در پست های بعدی با جزئیات بهشون می پردازم. #database @Syntax_fa

تکنیک Issue Trick یا Github Asset Hosting میخواید پروژتون رو توی README با استفاده از گیف و ویدیو معرفی کنید ولی نمیدونید فایل هارو کجا قرار بدید؟ اگه فایلتون حجمش کمه مثلا زیر 3 مگ، میتونید تو دایرکتوری docs داخل خود سورس کد پروژه بذارید ولی بازم روش خوبی نیست بنظرم. اما اگه فایلتون حجمش زیاده بنظرتون اینکار منطقیه؟ یکی بخواد clone کنه باید همراهش چند تا فایل بی ربط رو دانلودش کنه. خب چه کار هایی میتونیم؟ میتونیم تو فضای ذخیره سازی ای مثل aws و ... قرار بدیم ولی بازم وابسته شدیم به یه سرویس خارجی که فردا ممکنه فیلتر یا قطع بشه. راهکار حرفه ای یه ترفند جالبیه که تو پروژه های بزرگ اپن سورس استفاده میشه. میریم قسمت ایشو یک ایشو جدید باز میکنیم بعد فایلمون رو تو قسمت description آپلود میکنیم. بعدش صبر کنید تا آپلود فایل تموم بشه. گیتهاب به شما یک لینک میده. همونو کپی کنید تو README قرارش بدید! نکته طلایی: اصلا نیازی نیست دکمه submit new issue رو بزنید! حتی اگه ایشو کنسل بشه یا کامل ببندید و نسازیدش، اون فایل روی سرور های پرسرعت گیت‌هاب باقی میمونن! به همین سادگی بدون اینکه حجم پروژه بالا بره، داکیومنت های حرفه ای داشته باشید. #github @Syntax_fa

میتونید gemini enterprise یک ماهه اشتراک آزمایشی بگیرید و هیچیم نمیخواد ازتون. https://business.gemini.google/

چند تا گیتهاب اکشن کاربردی که بدرد اکثر ریتوزیتوری ها میخوره: 1. اکشن لینت با این اکشن، اکشن هارو لینت کن و بررسی کن ورژن ها، سینتکس و همه چی اوکیه یا نه. همچنین خودش تو پول ریکوئست ها کامنت هم میذاره و مشکلات رو میگه. نمونه کد: https://github.com/syntaxfa/quick-connect/blob/main/.github/workflows/action-lint.yml 2. داکر لینت: فایل Dockerfile هارو لینت میکنه از نظر امنیتی، استاندارد و اینکه الکی حجم ایمیج رو زیاد نکرده باشید و ... لینت میکنه. نمونه کد: https://github.com/syntaxfa/quick-connect/blob/main/.github/workflows/docker-lint.yml 3. کامیت لینت: لینت کردن کامیت ها مسیج کامیت و ... نمونه کد: https://github.com/syntaxfa/quick-connect/blob/main/.github/workflows/commit-lint.yml 4. SQL Lint: فایل های sql رو لینت میکنه. نمونه کد: https://github.com/syntaxfa/quick-connect/blob/main/.github/workflows/sql-lint.yml 5. دپلوی روی داکر هاب نمونه کد: https://github.com/syntaxfa/quick-connect/blob/main/.github/workflows/admin-deploy.yml #github #action @Syntax_fa

چرا Code-level Monolith معماری برنده است؟ (درس‌هایی از Grafana Loki) دوراهی مونولیت یا میکروسرویس: از یک طرف، مونولیت (Monolith) ساده است اما اگر بد نوشته شود به "کد اسپاگتی" تبدیل می‌شود. از طرف دیگر، میکروسرویس (Microservices) مقیاس‌پذیر است اما شما را در جهنمی از پیچیدگی‌های شبکه، دیپلوی و مدیریت ۵۰ کانتینر مختلف غرق می‌کند. اما اگر راه سومی وجود داشته باشه چی؟ راهی که در آن کدتان را "مثل میکروسرویس" می‌نویسید، اما آن را "مثل مونولیت" اجرا می‌کنید. در معماری Code-level Monolith، شما مرزهای سرویس‌هایتان را کاملا رعایت می‌کنید. یعنی سرویس Auth و سرویس Order کدهای کاملا جداگانه‌ای دارند (درست مثل میکروسرویس). اما در زمان بیلد (Build Time)، به جای اینکه آنها را در کانتینرهای جداگانه بسته‌بندی کنید، همه را در یک فایل اجرایی (Binary) واحد لینک می‌کنید. شعار این معماری: > *"میکروسرویس در توسعه، مونولیت در اجرا."* جادوی Grafana Loki و Tempo بهترین مثال زنده این معماری در دنیا، ابزارهای شرکت Grafana Labs (مانند Loki برای لاگ، Tempo برای تریس و Mimir برای متریک) هستند. سورس کد Grafana Loki از اجزای مختلفی تشکیل شده است: * Ingester (دریافت لاگ) * Distributor (توزیع بار) * Querier (جستجو) نکته نبوغ‌آمیز اینجاست: همه این‌ها در یک کدبیس و یک فایل باینری هستند. 1. حالتِ من و شما (All-in-One): وقتی می‌خواهید Loki را روی لپ‌تاپ یا سرور کوچک خود اجرا کنید، دستور زیر را می‌زنید: ./loki -target=all در این حالت، تمام اجزا در یک پروسه اجرا می‌شوند. ارتباط بین Distributor و Ingester از طریق Function Call در حافظه رم انجام می‌شود. * تاخیر: صفر نانوثانیه. * پیچیدگی: صفر. 2. حالتِ اسکیل بالا (Microservices): وقتی ترافیک شما میلیونی می‌شود، همان فایل باینری را با فلگ متفاوتی اجرا می‌کنید: ./loki -target=ingester حالا این باینری فقط نقش Ingester را بازی می‌کند و بقیه کدها خاموش می‌شوند. در این حالت، ارتباطات به صورت خودکار به gRPC/HTTP تغییر می‌کند. چرا باید به این روش فکر کنید؟ 1. حذف سربار شبکه (Zero Latency): در میکروسرویس، داده‌ها باید Serialize شوند، به شبکه بروند و Deserialize شوند. در Code-level Monolith، این فقط یک جابجایی اشاره‌گر (Pointer) در حافظه است. سرعت اجرای شما وحشتناک بالا می‌رود. 2. دیپلوی آسان (Operational Simplicity): برای شروع پروژه، نیازی به Kubernetes و مدیریت ۱۰ تا فایل YAML ندارید. یک فایل باینری را کپی و اجرا می‌کنید. 3. انعطاف‌پذیری (Agility): شما امروز نمی‌دانید پروژه شما چقدر بزرگ می‌شود. با این روش، شما امروز ساده شروع می‌کنید، اما کدتان "Ready to Scale" است. هر زمان لازم شد، با تغییر کانفیگ، مونولیت را می‌شکنید. چطور پیاده‌سازی کنیم؟ (مثال Go) کلید کار در استفاده از Interface**هاست. به جای اینکه سرویس A مستقیماً با gRPC کلاینتِ سرویس B صحبت کند، با یک اینترفیس صحبت می‌کند. * **در حالت Monolith: پیاده‌سازی اینترفیس، مستقیماً متد سرویس B را صدا می‌زند. * در حالت Microservice: پیاده‌سازی اینترفیس، یک درخواست gRPC می‌فرستد. —- این مقاله به خوبی پیاده سازیش رو توضیح میده: بیایید فرض کنیم اینکه برنامه میکروسرویس باشد یا مونولیت، فقط یک جزئیات پیاده‌سازی است سوال: در گوئیک کانکت چطور میشه به code level monolith رسید؟ https://github.com/syntaxfa/quick-connect #code_level_monolith @Syntax_fa

چهار ریپو پر ستاره دنیا در گیتهاب: build-your-own-x (۴۴۲ هزار استار) "چرخ را دوباره اختراع کن تا یاد بگیری چطور کار می‌کند!" این ریپوزیتوریِ جذاب به تازگی به رتبه اول صعود کرده است. ایده آن ساده اما فوق‌العاده است: لیستی از آموزش‌ها برای اینکه تکنولوژی‌های معروف را از صفر بسازید. * دوست دارید «گیت» (Git) خودتان را بسازید؟ * می‌خواهید یک «سیستم عامل» یا «دیتابیس» ساده کدنویسی کنید؟ اینجا بهترین جا برای کسانی است که می‌خواهند از سطح مصرف‌کننده ابزار، به خالق ابزار تبدیل شوند. freeCodeCamp (۴۳۳ هزار استار) "دانشگاه رایگان برنامه‌نویسی" سال‌ها در رتبه اول بود و هنوز هم معتبرترین منبع آموزشی رایگان است. این مخزن سورس‌کدِ پلتفرم freeCodeCamp.org است که میلیون‌ها نفر با آن برنامه‌نویسی وب را یاد گرفته‌اند. اگر دنبال یک مسیر یادگیری (Roadmap) کامل و دریافت مدرک رایگان هستید، اینجا خانه شماست. awesome (۴۱۷ هزار استار) "لیستی از لیست‌های عالی" تا حالا شده دنبال "بهترین کتابخانه‌های پایتون" یا "بهترین ابزارهای هک و امنیت" بگردید؟ ریپوزیتوری Awesome یک دایرکتوری غول‌پیکر است که لینکِ تمام منابع باکیفیت برای هر زبان و تکنولوژی را یکجا جمع کرده است. گوگل کردن خوب است، اما گشتن در Awesome شما را سریع‌تر به نتیجه‌های حرفه‌ای می‌رساند. 996.ICU (حدود ۲۷۰ هزار استار) "صدای اعتراض برنامه‌نویسان" این مخزن با بقیه فرق دارد؛ اینجا کدی برای اجرا نیست، بلکه نماد یک جنبش است. نام آن به فرهنگ کاری ناعادلانه در شرکت‌های فناوری چین اشاره دارد: کار از ۹ صبح تا ۹ شب، ۶ روز در هفته. برنامه‌نویسان با استار دادن به این ریپوزیتوری، اعتراض خود را به شرایط کاری سخت و استثمار نیروهای فنی در سراسر جهان نشان می‌دهند. @Syntax_fa

صفحه بندی داده داده‌ها: Limit/Offset و Cursor-Based وقتی صحبت از نمایش حجم زیادی از داده‌ها در صفحات مختلف میشه، استفاده از pagination ضروری میشه. دو روش رایج برای این کار وجود داره که هر کدوم سادگی‌ها و چالش‌های خاص خودشون رو دارن: صفحه بندی با Limit و Offset سادگی ولی ... صفحه بندی با Limit و Offset رو میشه ساده‌ترین و اولین روشی دونست که به ذهن میرسه. شما به دیتابیس میگید "فقط Limit تا رکورد بهم بده" و "از Offset مشخصی شروع کن". سادگی: پیاده‌سازی خیلی آسونی داره. برای صفحات اول که تعداد رکوردها کمه، عملکرد خوبی داره. چالش‌ها: عملکرد ضعیف در صفحات بالا: با افزایش Offset، دیتابیس مجبور میشه تعداد زیادی از رکوردها رو اسکن کنه و بعد اونا رو دور بندازه که باعث کندی شدید میشه. مشکل تغییر داده‌ها: اگه در حین حرکت بین صفحات، داده‌ای اضافه یا حذف بشه، ممکنه رکوردهای تکراری ببینید یا بعضی از رکوردها رو از دست بدید. مرتب‌سازی (Sorting): معمولاً نیازمند مرتب‌سازی روی یک فیلد ثابت هستید تا نتیجه قابل پیش‌بینی باشه. مثال ساده (SQL): برای گرفتن ۱۰ رکورد اول از جدول products (صفحه ۱):

SELECT *
FROM products
ORDER BY id
LIMIT 10 OFFSET 0;

برای گرفتن ۱۰ رکورد بعدی (صفحه ۲):

SELECT *
FROM products
ORDER BY id
LIMIT 10 OFFSET 10;

صفحه بندی با روش Cursor-Based Pagination: راه حلی برای مقیاس‌پذیری صفحه بندی با Cursor-based pagination با استفاده از یک "نشانگر" (cursor) که معمولاً یک فیلد یکتا و مرتب‌سازی شده (مثل تاریخ ایجاد یا ID) هست، صفحه بعدی رو مشخص میکنه. به جای گفتن "صفحه N رو بیار"، میگیم "رکوردها رو از بعد از این نقطه مشخص بیار". محدودیت‌ها و نکته‌ها: پیچیدگی پیاده‌سازی: نسبت به Limit/Offset کمی پیچیده‌تره و نیازمند طراحی دقیق‌تر کوئری‌هاست. مرتب‌سازی: باید همیشه بر اساس فیلد Cursor مرتب‌سازی انجام بشه. این یعنی نمیتونید هر جور دلتون خواست داده‌ها رو مرتب کنید. پرش به صفحات دلخواه: معمولاً قابلیت "پرش به صفحه 5" رو نداره و فقط میتونید به صفحه بعدی یا قبلی برید (Next/Previous). مناسب برای فیدها و لیست‌های طولانی: برای سیستم‌هایی مثل فید شبکه‌های اجتماعی که فقط به اسکرول کردن ادامه دار نیاز دارن و پرش به صفحه خاصی مطرح نیست، عالی عمل میکنه. مثال ساده (SQL): فرض کنید آخرین id محصولی که در صفحه قبلی دیده‌اید 1234 بوده:

SELECT *
FROM products
WHERE id > 1234
ORDER BY id
LIMIT 10;

#pagination #sql @Syntax_fa

یکی اومده یچی ساخته به اسم لارا‌مپ! کارش چیه؟ میان اونجا پهپ کار ها ثبت نام میکنن 😒 تا بصوت نقطه ای و دقیق بدونن پهپ کار ها کجا زندگی میکنن. کامنت های پسته عالیه #fun @Syntax_fa

ربات های فوق انسان نما در نمایشگاه کیش رونمایی شد که باعث ریزش شدید سهام تسلا شده!

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

#fun @Syntax_fa

Go + HTMX ادمین پنل Quick Connect ما توی پنل ادمین(سرویس adminapp) قید فریم‌ورک‌های سنگین جاوااسکریپت (مثل React/Vue) رو زدیم و مستقیم سراغ ترکیب Go + HTMX رفتیم. چرا؟ چون سریعه، ساده و فوق‌العاده قدرتمنده. معماری چطوریه؟ الگوی BFF هستش. adminapp ما یک Backend for Frontend (BFF) کلاسیک هست. این یعنی چی؟ Go Server (BFF): adminapp یک سرور Go هست که مخصوص UI ادمین ساخته شده. این سرور، "مرورگر رو به عنوان فرانت‌اند خودش می‌بینه. ارتباط باطن با gRPC. این سرور Go، برای گرفتن دیتا (مثلا لیست یوزرها)، با managerapp یا سرویس‌های دیگه از طریق gRPC صحبت می‌کنه. رندر سمت سرور (SSR): وقتی دیتا رو از gRPC گرفت، میاد اون رو توی قالب‌های HTML (فایل‌های .../templates/) رندر می‌کنه. بدون JSON، فقط HTML: اینجا دیگه خبری از API یی که JSON برگردونه و یه فرانت‌اند جاوااسکریپتی اون رو بگیره و کامپوننت بسازه نیست. سرور Go مستقیم خود HTML نهایی رو می‌سازه و می‌فرسته. ا. HTMX اینجا چیکار می‌کنه؟ جادوی واقعی اینجاست! بارگذاری اولیه: کاربر صفحه داشبورد رو باز می‌کنه. سرور Go کل صفحه dashboard.html رو رندر می‌کنه و می‌فرسته. کاربر روی دکمه «ساختن یوزر جدید» کلیک می‌کنه. ا. HTMX (که یه فایل .js کوچیکه) یه درخواست AJAX به سرور Go می‌فرسته (مثلاً به POST /htmx/users/create-modal). سرور Go این درخواست رو می‌گیره. ا. Go فقط و فقط فایل user_create_modal.html رو رندر می‌کنه (نه کل صفحه رو!). این تکه HTML کوچیک به مرورگر برمی‌گرده. ا. HTMX این تکه HTML رو می‌گیره و تو صفحه "swap" می‌کنه (مثلاً داخل یه div خالی می‌ذاره). نتیجه؟ ما یه داشبورد داینامیک و سریع داریم که حس اپلیکیشن‌های SPA (مثل ری‌اکت) رو می‌ده، اما: * ۹۹٪ منطق توی Go نوشته شده. * نیازی به Build Step جاوااسکریپتی نداریم. * سرعت لود اولیه فوق‌العاده‌ست. * توسعه‌ش به‌شدت ساده و لذت‌بخشه. اگه از نوشتن Go لذت می‌بری و دلت نمی‌خواد درگیر پیچیدگی‌های فرانت‌اند مدرن بشی، معماری adminapp دقیقاً همون چیزیه که دنبالش می‌گردی. Quick Connect AdminApp #go #htmx @Syntax_fa

این چنل آرشیو کتاب‌ها، برگه تقلب، پادکست و وبینار برای دولپرهاست، بدردتون میخوره t.me/+M4QujCyYc9E1N2Rk

هممون می‌دونیم تلگرام یکی از خفن‌ترین پیام‌رسان‌های دنیاست. سریعه، امکاناتش بی‌نهایته و از نظر مهندسی واقعا کارآمده. کلی خوبی داره، ولی بیاید روی یکی از تاریک‌ترین نقطه‌ضعف‌هاش دست بذاریم. معماری تلگرام، اون رو به یک بهشت آشوب تبدیل کرده. مشکل فقط چندتا کانال متخلف نیست؛ مشکل در هسته‌ی طراحی این پلتفرمه. ۱. توهمِ نظارت (جعبه سیاه ریپورت) وقتی شما یه کانال وحشتناک (مثل آزار حیوانات، کلاهبرداری یا ترویج خشونت افراطی) رو ریپورت می‌کنید، چه اتفاقی میفته؟ حقیقت اینه که هیچکس نمی‌دونه. سیستم ریپورت تلگرام یه جعبه‌ی سیاه مبهمه. معلوم نیست چندتا ریپورت لازمه تا یه کانال بسته بشه یا اصلا یک انسان اون گزارش رو می‌بینه یا نه. تلگرام برند خودش رو روی آزادی ساخته، و این یعنی عمدا سیستم نظارت رو حداقلی نگه داشته تا از پلتفرم‌های سخت‌گیرتر متمایز باشه. نتیجه؟ کانال‌های مجرمانه و افراطی، هفته‌ها و ماه‌ها قبل از اینکه شاید (فقط شاید) بسته بشن، به فعالیت ادامه می‌دن. ۲. مشکل هیدرا (محتوای ابدی) این خطرناک‌ترین بخش ماجراست. فرض کنید یه محتوای مجرمانه (مثلاً یه ویدیوی دلخراش) در یک کانال پست می‌شه. حالا هزاران نفر اون رو می‌بینن، در Saved Messages خودشون ذخیره می‌کنن، یا به پیوی و گروه‌های خصوصی فوروارد می‌کنن. شما اون کانال اصلی رو ریپورت می‌کنید و بالاخره تلگرام اون کانال رو می‌بنده. اما اون فایل ویدیویی از سرور پاک نشده. تمام اون هزاران نفری که اون فایل رو جایی ذخیره کردن، هنوز بهش دسترسی کامل دارن. اون‌ها یک کپی از فایل نساختن؛ اون‌ها فقط یک Bookmark به اون فایلِ آپلود شده روی سرور تلگرام دارن. تا زمانی که حتی یک نفر اون فایل رو در جایی داشته باشه، اون محتوا روی سرورها قابل دسترسیه. شما یک سر هیدرا رو زدید، در حالی که اون محتوا در هزاران چت خصوصی و کانال پشتیبان، دوباره رشد می‌کنن ۳. اکوسیستم جنگل تاریک (ویترین عمومی، انبار خصوصی) این معماری، یک اکوسیستم دوگانه ساخته: 1. "ویترین عمومی" (Public Channels): جایی که نظارت (هرچند ضعیف) وجود داره. این‌ها برای تبلیغ و جذب نیرو استفاده می‌شن. 2. "جنگل تاریک" (Private Ecosystem): شامل گروه‌های خصوصی و چت‌های شخصی. اینجا هیچ نظارتی وجود نداره. صفر. گروه‌های مجرمانه، افراطیون و کلاهبردارها در "ویترین عمومی" تبلیغ می‌کنن و اعضا رو به "جنگل تاریک" (گروه‌های خصوصی) می‌کشونن. جایی که دیگه هیچ قانونی وجود نداره. @Syntax_fa

ما به هر جا سر می‌زنیم، انگار می‌خوایم وارد مرحله نهایی مصاحبه CIA بشیم! از احراز هویت دومرحله‌ای بگیر تا اسکن قرنیه چشم (که فقط مونده همینو بخوان). اصلا یه فرم پر می‌کنی، انگار داری برای ویزای شینگن اقدام می‌کشی. نام پدر؟، کد پستی محل سکونت جد پدری؟ شماره کارت اعتباری‌ای که تاریخ انقضاش تا ابدیت باشه؟ بعد می‌گن چرا پیشرفت نمی‌کنیم! ما کل انرژی‌مون صرف این می‌شه که اینترنتمون رو وصل کنیم و مبادا آیپیمون لو بره! یا بعد از کلی کلک کاری که یه خارجی انجام میده رو، انجامش بدیم. البته از یه سمت دیگه توانایی هایی رو بدست بیاریم که برای یه خارجی قفله. مثلا: اومدم یه کارت دانشجویی فیک درست کردم که از واقعیش، واقعی تره. تازه اونم با جمنای که میگفت نمیتونم کارت دانجویی رو کنم خلاف قوانینه. دیگه خودتون تفاوت قائل میشید مارو مجبور میکنید دور بزنیم 😠 #fun @Syntax_fa

- ‏وقتی به جای گروک و‌چت جی پی تی میرم سراغ گوگل: من برگشتم خونه...استاد source #fun @Syntax_fa

هوش مصنوعی توی فرانت اند برای فرانت اند پروژه های اپن سورس دارم از AI استفاده میکنم و خروجی دوتا از پروژه ها این دوتا بودن: وب سایت معرفی کوئیک کانکت: https://quick-connect.syntaxfa.ir وب سایت معرفی دانجو: https://danjoo.syntaxfa.ir قبلا زیاد امتحان نکرده بودم و برای خودم خیلی جالب بود. نسبت به توضیحی که داده بودم خیلی خوب درآوردن کارو. @Syntax_fa

دامنه رایگان بدون دردسر https://github.com/DigitalPlatDev/FreeDomain مراحلش سادست کافیه ثبت نام کنید و طبق توضیحاتشون پیش برید. @Syntax_fa