اگه دنبال درست کردن اپلیکیشن Saas هستید این قالب آماده (template) خیلی کار را راحت میکنه. با Wasp که بر اساس React, NodeJS, Prisma هست نوشته شده و همراه کلی فیچر مثل Stripe, آپلود فایل در AWS S3 و SMTP برای فرستادن ایمیل و.... هست.
Github: https://github.com/wasp-lang/open-saas

@DevTwitter | <Mehdi Allahyari/>

🔶 درخواست افزودن زبان فارسی برای Github Readme Stats شکست خورد.

خیلی سختگیره 🤦‍♂️

https://github.com/anuraghazra/github-readme-stats/pull/3922

@TheRaymondDev

پرامپت بده، عکس بگیر 🤖

امروز یک ai بهتون معرفی میکنم که بهتون امکان میده به طور Real Time، پرامپت های خودتون رو بنویسید و همون موقع عکس مد نظر رو به طور نامحدود تحویل بگیرید. برای استفاده از این هوش مصنوعی کافیه روی لینک زیر کلیک کنید.

🔗 Link

#ai
@CodeModule

سناریو ها سو استفاده از گیت، ببینید و لذت ببرید

Today TheRecordMedia released an article regarding Ford's new patent: targeted advertisements by actively monitoring and listening to passengers conversations.

It sounds bad, but reading the article it's actually x100 worse.

More information: https://therecord.media/ford-patent-application-in-vehicle-listening-advertising

چجوری کامیت های تمیز و مفهومی بنویسم؟!
کامیت به عنوان اجزای سازنده, کار یک برنامه نویس عمل می کنند. آنها اگر که به درستی نوشته شوند، ارزش قابل توجهی دارند. یک پیام commit به خوبی نوشته شده ضروری است زیرا آنها زمینه را فراهم می کنند، در غیر این صورت یک پیام commit در وهله اول مورد نیاز نخواهد بود.

آقای پیتر هاترر میگه:
یک کامیت خوب نشان می دهد که آیا یک توسعه دهنده یک همکار خوب است .

خب، کامیت های شما باید تمیز و قابل درک باشه:
به عنوان مثال اگر میخواید در UI تغییراتی اعمال کنید، کامیت رو به صورت زیر بنویسید:

git commit -m "Enhance UI: Header and sidebar Improvements"

یا
git commit -m " fix: prevent racing of requests"

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


@DevTwitter | <Mohammad Abdorrahmani/>

اگر دنبال ابزاری هستید که بتونید باهاش از پلتفرم‌های مختلف(یوتیوب، تیک‌تاک، اینستاگرام و ...) ویدیو و یا حتی فایل صوتی دانلود کنید، سایت زیر که از قضا اپن‌سورس، رایگان، بدون تبلیغ و هرنوع trackerی هست این کار رو براتون انجام می‌ده. اخیراً هم به نسخه جدیدی آپدیت شده و الان ویدیوهای یوتیوب رو تا کیفیت 8k می‌تونید دانلود کنید ازش. محدودیت خاصی هم نداره.
cobalt.tools
hadi @geekalerts

📕 کتاب REST API Design Rulebook

📌 فصل دوم: Identifier Design with URIs

📍پارت: پنجم

#کتاب

‏💎 URI Query Design 💎
این بخش درباره قوانین طراحی کوئری‌های URI صحبت می‌کنه. طبق استاندارد RFC 3986، کوئری URI (که اختیاری هست) بعد از مسیر (path) و قبل از تکه‌ی اختیاری (fragment) قرار می‌گیره:

URI = schema "://" authority "/" path [ "?" query ] [ "#" fragment ]

کوئری تو URI به شناسایی منحصربه‌فرد بودن یه منبع کمک می‌کنه. به این مثال توجه کن:

https://api.college.restapi.org/students/morgan/send-sms

https://api.college.restapi.org/students/morgan/send-sms?text=hello

اولی URI یه منبعی هست که پیامک می‌فرسته. دومی همون منبع رو نشون می‌ده ولی با این تفاوت که توش پیام "hello" فرستاده می‌شه.

قسمت کوئری URI شامل یه سری پارامتره که به عنوان یه نوع تغییر یا نسخه‌ای از منبع اصلی (که تو بخش مسیر URI تعریف شده) تفسیر می‌شه. پس این دو منبع دقیقاً یکی نیستن، ولی به هم خیلی نزدیکن.

قسمت کوئری تو URI می‌تونه به کلاینت‌ها امکانات بیشتری مثل جستجو یا فیلتر کردن بده. به همین دلیل، این بخش از URI ممکنه برای کلاینت‌های یه REST API شفاف باشه (یعنی زیاد براشون مهم نباشه).

در ضمن، کل URI یه منبع باید برای واسطه‌های شبکه مثل کش‌های HTTP غیرشفاف (opaque) باشه. کش‌ها نباید رفتار خودشون رو فقط بر اساس وجود یا عدم وجود کوئری توی URI تغییر بدن. یعنی پیام‌های پاسخ نباید فقط به خاطر وجود کوئری از کش شدن حذف بشن. همونطور که تو فصل ۴ توضیح داده شده، برای کنترل رفتار واسطه‌های کش باید از هدرهای HTTP استفاده بشه، نه کوئری‌ها.

⭕️ قسمت کوئری URI می‌تونه برای فیلتر کردن کالکشن ها یا Store ها استفاده بشه.
یعنی می‌تونی ازش برای مشخص کردن معیار جستجو توی یه مجموعه یا ذخیره استفاده کنی. یه مثال بزنیم:

GET /users
GET /users?role=admin

تو درخواست اول، کلاینت از سرور لیست همه کاربران رو درخواست می‌کنه.
تو درخواست دوم، کلاینت از سرور لیست کاربرانی که نقش (role) "admin" دارن رو می‌خواد.

در واقع، قسمت کوئری (?role=admin) داره لیست کاربرا رو فیلتر می‌کنه تا فقط اونایی که نقش "admin" دارن تو پاسخ نمایش داده بشن.


⭕️ قسمت کوئری (Query) توی URI باید برای صفحه‌بندی (pagination) نتایج مجموعه یا ذخیره‌ها استفاده بشه.
کلاینت یه REST API باید از پارامترهای pageSize و pageStartIndex توی کوئری استفاده کنه. پارامتر pageSize تعداد عناصر حداکثری رو که باید توی پاسخ برگردونده بشه مشخص می‌کنه، و pageStartIndex مشخص می‌کنه که اولین عنصر از کجا شروع بشه (با ایندکس صفر).

مثال:

GET /users?pageSize=25&pageStartIndex=50

این درخواست لیستی از ۲۵ کاربر رو برمی‌گردونه که از کاربر شماره ۵۰ شروع می‌شه.

اگه نیاز به صفحه‌بندی یا فیلتر کردن پیچیده‌تری داشته باشی که با فرمت ساده کوئری قابل انجام نباشه، می‌تونی یه کنترلر خاص طراحی کنی که با مجموعه یا ذخیره کار کنه. مثلاً:

POST /users/search

اینجا، به جای استفاده از کوئری توی URI، کلاینت می‌تونه درخواست‌های پیچیده‌تری مثل محدوده‌های خاص یا ترتیب‌های خاص رو توی بدنه (body) پیام ارسال کنه. فقط باید مطمئن باشی که نتایج کش‌شده کنترلر به درستی مدیریت بشن.


📝 قوانین طراحی URI در REST API 📝

این خلاصه، اصطلاحات مهمی رو که تو طراحی URIs برای REST API ها به کار میره توضیح میده:
‏
🔑 Authority: بخشی از URI که مسئول فضای نام هست.
📂 Collection: نوعی منبع که مثل یه دایرکتوری از منابع سرور مدیریت می‌شه.
🛠 Controller: منبعی که عملکردهای اجرایی رو مدل‌سازی می‌کنه (مثل یه تابع).
💾 CRUD: مخفف چهار عمل اصلی: ایجاد، خواندن، بروزرسانی و حذف.
🌐 Developer portal: یه رابط کاربری وب برای جذب کلاینت‌های جدید به API.
‏🏠 Docroot: نقطه شروع مدل REST API که والد همه منابع دیگه است.
📄 Document: منبعی که یه مفهوم منفرد رو مدل‌سازی می‌کنه.
🔗 Forward slash separator (/): علامتی که برای جدا کردن منابع مرتبط در URI به کار می‌ره.
👁 Opacity of URIs: یه اصل که می‌گه ساختار URI برای کاربر نباید مهم باشه.
📍 Parent resource: منبعی که یه مفهوم زیرمجموعه رو مدیریت می‌کنه.
🔍 Query: بخشی از URI که برای جستجو و فیلتر استفاده می‌شه.
🔧 Resource archetypes: چهار نوع اصلی منابع (مستند، مجموعه، ذخیره، کنترلر).
🗄 Store: یه منبع که به‌عنوان یه مخزن مدیریت‌شده توسط کلاینت مدل‌سازی می‌شه.
📌 URI path segment: بخشی از URI که نمایانگر یه گره (node) تو مدل سلسله مراتبی منبعه.
📑 URI template: فرمت URI که شامل متغیرهایی هست که قبل از استفاده باید جایگزین بشن.

@ninja_leanr_ir

به‌روز رسانی جدید کبالت، ویژگی‌های جدید و قابل توجّهی رو از جمله امکان خودمیزبانی، به این سکّوی کارآمد، اضافه کرد.

#news #FLOSS
@amiria703_channel

تجربه و نظرتون رو در مورد repository pattern در قسمت نظرات بنویسید.

چرا این چیزی که به عنوان repository pattern که معروف شده انقدر نچسب و بدقلق هست؟!
(شایدم به ما غلط آموزش دادند... 😯)

👇👇👇

چرا باید پروژتون رو منتشر کنید حتی اگه بد باشه؟

واقعاً در شروع کار مهم نیست که پروژه ها چقدر ساده، ناپخته یا «غیر حرفه‌ای» باشن. مهم اینکه تموم و منتشر بشن. حالا چرا؟ افراد زیادی هستن که وارد این حوزه میشن و شروع میکنن تویه یک چرخه ی بی پایان از دوره دیدن گیر کردن و در نهایت از اینکه خروجی ای نمی بینن از کارشون نا امید میشن. پس فقط شروع به ساختن کنید و بذارید بقیه کارتون رو ببینن. چیزی که مهمه اینه که در نهایت یه چیزی ساختید و این حس خوبی بهتون میده. درنهایت سریع تر یاد می‌گیری و کلی پروژه میزنی!

خودتو از نتیجه کار جدا کن.

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

بس کن یادگرفتن رو!

تو دیگه به اندازه کافی بلدی که بتونی پروژه های خفن بسازی. وقتی میگم "بس کن یادگرفتن رو" منظورم این نیست که دیگه یاد نگیری (چون همه ما همیشه در حال یادگیری هستیم)، منظورم اینه که:

ویدئو تو یوتیوب و حتی کتاب رو ببند،
حتما این پست رو هم تموم کن!
به جای این کارها چی کار کنی؟ کد ادیتورت رو باز کن و شروع کن به کد نویسی.

میگم "اول باید <مفهوم-خاص> رو بهتر یاد بگیرم تا بتونم چیزی بسازم."
یا "باید در مورد <موضوع-خاص> بیشتر بدونم."
یا "چطور میشه اگه <ویژگی-خاص> من طبق بهترین شیوه های فعلی نباشه؟"

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


کپی‌کاری اشکال نداره!

یه کاری که هزار نفر دیگه انجامش دادن، چرا خودت بخوای از اول شروع کنی؟ البته این معنی‌اش این نیست که هیچی یاد نگیریا، فقط می‌گم یه سری کارا رو لازم نیست از صفر شروع کنی. آخر سر، هرچی بسازی یه جوری بوی خودتو می‌ده. پس نترس که بقیه فکر کنن کپی‌کاری کردی. راستش رو بخوای، خیلی هم خوبه که از کارای بقیه استفاده کنی. مثلاً یه کد آماده پیدا کنی و روش کار کنی، یا بری تو گیت هاب و کد بقیه رو بخونی. اینجوری خیلی زودتر به نتیجه می‌رسی.

یه فیچر یه فیچر کارو جلو ببر

برنامه‌ریزی خوبه، اما اگه بخوای باهاش کارو ول کنی اصلا خوب نیست! برنامه‌ریزی یه جور خودتو گول زدنیه که میگی: «آهان، خب من که برنامه‌ریزی کردم، پس کارم تمومه!»
یه چیز دیگه هم هست، ممکنه وسط کار یه چیزی یادت بیاد که اصلا تو برنامه‌ت نبوده. پس زیاد خودتو درگیر برنامه‌ریزی نکن. یه فیچر رو درست کن، بعد بعدی رو. مثلا اگه پروژه ی جدید ساختی شروع کن به تعریف کردن ماژول هاش مثل:

-> auth
-> client
-> admin
-> landing-page
-> payment

اینجوری نه خسته می‌شی، نه گیج. هر فیچری که تموم می‌شه، حسابی کیف می‌کنی که یه قدم جلو رفتی. حتی اگه خیلی کوچیک باشه و از todo list هم غافل نشید.

ولش کن بابا، زود منشترش کن!

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


تمومش کن، حتی اگه گند باشه!

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

کلام آخر

حالا که دارم این پست رو تموم می‌کنم، می‌خوام یه نقل قول از Kurt Vonnegut بهتون بگم. اگه کدنویسی رو یه نوع هنر حساب کنیم، حرفای اون خیلی به کارمون میاد:

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

خب دوستان، حالا برید و حسابی کد بزنید :)

🆔 @MdDaily

نحوه استفاده از اندپوینت‌های سفارشی برای بهبود فرایند اتصال در برنامه‌های #oblivion و #oblivionDesktop ...

🎥 youtu.be/zF8cpEetuRY?t=108
💡 ircfspace.github.io/endpoint

🔍 ircf.space
@ircfspace

یکی از بهترین بیلد بک اند هایی که میتونید تو پروژتون داشته باشین hatchling هست.
خیلی کارای خوب و زیادی انجام میده براتون که تو یک پست نمیگنجه بخوام کلشو توضیح بدم.

احتمالا از پکیج منیجر استفاده میکنید مثل uv یا poetry یا pdm یا ... . اگه استفاده نمیکنید, حتما بکنید 😅

برای استفاده از hatchling کافیه تو pyprojectتون اینو بذارین

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

بعد مثلا سورس کدتون داخل یک دایرکتوری به اسم src هست. که همه ایمپورت هاتون این شکله:
from src.models import User

اونوقت کافیه اینم اضافه کنید به پای پروجکت

[tool.hatch.build.targets.wheel]
packages = ["src"]

@PyBackendHub

جایگزین Llama3.1 فقط می‌تونه یک نسخه بهتر براساس همین معماری باشه :

arcee-ai/Llama-3.1-SuperNova-Lite

مدل ۸ میلیارد پارامتری هست، مدل ۷۰ میلیاردی فقط از طریق api در دسترس هست.
طبق ادعا از 405b, gpt4o, ... بهتر عمل می‌کنه؛ البته برای تسک‌های مربوط به
instruction-following

شخصاً هم همین رو احساس کردم توی تست‌ها.

issues.chromium.org/issues/41294170

زندگی رقمی‌تون رو بر مبنای چیزی که اهمیّتی به ایرادهای حتّیٰ گزارش‌شده نمی‌ده؛ نسازید.
این ایراد، از سال ۲۰۱۷ پابرجاست.

#note
@amiria703_channel

🔵 عنوان مقاله
makefile-graph: Turn a Makefile into a Graph

🟢 خلاصه مقاله:
این مقاله به بررسی و توضیح ابزاری پرداخته است که هم به عنوان کتابخانه و هم به عنوان ابزار خط فرمان (CLI) قابل استفاده است. این ابزار، فایل‌های makefile را تجزیه کرده و نمودارهایی را تولید می‌کند که روابط بین هدف‌های (targets) مختلف را نشان می‌دهند. نمودارهای تولید شده توسط ابزار dot متعلق به Graphviz، رندر می‌شوند. این فرآیند به توسعه‌دهندگان کمک می‌کند تا درک بهتری از وابستگی‌ها و تعاملات بین اجزاء مختلف در پروژه‌های بزرگ نرم‌افزاری داشته باشند و مدیریت وابستگی‌های پروژه را بهبود ببخشند. این ابزار به طور خاص برای کاربرانی طراحی شده که به بهینه‌سازی و دقت در مدیریت تکالیف و پروژه‌های خود نیاز دارند.

🟣لینک مقاله:
https://github.com/dnaeon/makefile-graph

➖➖➖➖➖➖➖➖
👑 @gopher_academy

حدود ۱ ماهه از ویندوز به لینوکس مهاجرت کردم. دومین باره که ترکوندمش و به کمک ChatGPT همه‌چیز رو برگردوندم.
حالا اگه ویندوز بود، باید اشک می‌ریختم و OS عوض می‌کردم

پ.ن: هنوز کورس لینوکس نگذروندم و فقط در حد نیاز روزانه یه دیتاساینتیست جونیور ازش استفاده می‌کنم

@DevTwitter | <Fatemeh Eslami/>