#help_me

دانلود منیجر خوبی برای linux اگر می‌شناسید معرفی کنید

تا قبل از این از Persepolis استفاده می‌کردم ولی آپدیت های اخیرش انقدر باگ منطقی و مشکلات داره که عصبیم کرده

۱- اسم فایل‌هارو نمی‌تونه detect کنه

۲- حجم هارد رو چک نمی‌کنه، فایل رو دانلود می‌کنه ولی روی null می‌نویسه

۳- اسم فایل رو detect می‌کنه ولی همرو نهایت روی هم با یک اسم می‌نویسه و پارت‌های قبلی فایل overwrite میشه

۴- بخش صف‌ها بسیار کند شده و خیلی وقتا اگر تعداد فایل زیاد بشه وقتی روش کلیک می‌کنید، برنامه بسته میشه

و کلی مشکلات دیگه، که با هر آپدیت داره بیشتر هم میشه

اگر جایگزین خوبی با تمام ویژگی‌های مهم دارید معرفی کنید لطفاً


#موقت

پ.ن : لطفاً مواردی رو بگید که برای Redhat Base هم کار میده


مهمترین فیچر؛ با مرورگرها هم کار کنه extension داشته باشه برای link selection

دنبال این که کدوم زبان مطلقا بهتره هیچ وقت نرید، هیچ وقت هیچ زبانی نمیتونه توی همه ویژگی ها بهتر از زبان دیگه باشه و اون زبان بده هنوز وجود داشته باشه.

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


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

🐧 @Linuxor

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

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

- ما قراره توی این مسیر یکسری چالش و مسئله رو طرح کنیم و روی اون ها تمرکز کنیم.
- فعالیت نباید محدود باشه و افراد تا یه حدی میتونن غیبت داشته باشن (فقط یک جلسه حضور کافی نیست و باید بعنوان عضو ثابت سعی کنید حضور داشته باشید و فعالیت قراره تیمی باشه)
- توی این پروسه فقط نمیخونیم، سعی میکنیم حل کنیم و حل کنیم تا بهتر بشیم.

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

@RezaAmini_ir

اگرم نظری دارید راجع به این کار توی بخش کامنت ها بگید به من.

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

چرایی اهمیت #یادگیری #دانش هایی موثر برای آینده نزدیک با غلبه کامل #هوش_مصنوعی بر زندگی ما

با دیدن این پست موضوعی که خیلی وقت هست از خود من زیاد پرسیده میشه، (را بجای جواب خصوصی تکراری،) خیلی صریح (explicit) اینجا پاسخ بدم. خوشبختانه یا متاسفانه با سرعت خیلی زیاد، خیلی از شغل هایی که الان وجود داره، در حال از بین رفتن هستند. جنس این تغییر رویکرد (انقلاب صنعتی چهارم) به شدت متفاوت از #انقلاب_صنعتی (ویکی پدیا) های گذشته هست، به نوعی که واقعا هنوز پاسخ روشن و شفافی وجود ندارد که جایگزین این همه شغل هایی که از بین خواهند رفت، برای انسان ها چی می تونه باشه. یکی از راه کارهای موثر که چند سال هست به شکل خیلی جدی تر در جوامع توسعه یافته در حال اجرا هست، کاهش میزان ساعت کاری اشخاص و قطعا افزایش روزهای تعطیل به حتی 4 روز در هفته می باشد. ولی خوب تا کجا این روش، امکان ادامه دادن خواهد داشت؟ اگر فرضیه خوبی برای پاسخ داشتید، حتما کامنت بذارید.
قطعا برای پاسخ به سوالات باز زیادی که هر روز جواب دادن بهشون هم پررنگ تر میشه از حوزه #علم رشته های مختلف باید خارج بشیم و #فلسفه_علم رشته تخصصی خودمون را یاد بگیریم. یک از اهداف سلسه جلسات آشنایی با فهم #فلسفه_علم ما همین موضوع مهم هست. یادمون باشه #ناآگاهی باعث ایجاد ترس میشه. بدلیل تکامل ما انسان ها، در هنگام ترس، بجای پاسخ دادن، واکنش نشان می دهیم که خودش باعث کلی مشکل برای ما میشه. واکنش معمولا بدون تحلیل داده های پیش رو اتفاق میفته و بر اساس عادات و رفتار ماست. پس هر چقدر بیشتر عادات و رفتار ما با یادگیری دانش های موثر بهتر شده باشه، احتمال ایجاد واکنس های بد مثل افسردگی در ما کمتر میشه.

یکم اینبار بیشتر از #تلنگر_ذهنی تشریح کنم و خیلی شفاف بگم در آینده خیلی خیلی نزدیک داشتن دانش هایی مثل فهم پروتکل هایی مانند http (restful) دیگه اصلا مزیت برای یک اصطلاحا بک اند یا فرانت اند کار، نیست. با فاصله کمی حتی دانش هایی با درجه خلاقیت بیشتر مانند توسعه محصول هم عملا کاربردی نیست. یادآوری کنم که در خیلی از جنبه ها همین الان هم ما درون این انقلا هستیم ولی در خصوص بعضی از زوایا، در مورد تغییر از فردا صبح صحبت نمی کنیم ولی قطعا در مورد زمانی صحبت می کنیم که در بازه کار حرفه ای خیلی از ماها خواهیم دید، پس باید با برنامه ریزی کافی، آمادگی اون روزها را داشته باشیم چه از لحاظ فکری و روانی و چه از لحاظ مالی. مثلا تا الان فرصت استفاده از آخرین زمان هایی هست که دانش های خلاق تر را یاد بگیریم فریب افرادی که واقعیت ها را نه می بینند و نه قبول می کنند (به اصطلاح سر خودشان را در برف فرو برده اند) نخوریم با یادگیری دانش های موثر تر مثل توسعه محصول، ثروت اندوزی همراه با پس انداز بیشتری را انجام بدیم. از سازمان هایی که شما را مجبور به یادگیری دانشی می کنند که در حال یا آینده به شکل خیلی خیلی بهتری هوش مصنوعی در حال انجامش هست، جدا پرهیز کنید یا حداقل به شکل شفاف دلایل موضوع را تشریح کنید.

اگه دنبال درست کردن اپلیکیشن 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