یکی از پترن های بد ولی رایج توی نصب نرم‌افزار اینه که اسکریپت نصب رو curl کنیم و مستقیم اجرا کنیم.
مشکلی که وجود داره اینه که ممکنه تنی اون اسکریپت هرچیزی وجود داشته باشه و ما اون رو اجرا میکنیم، گاهی حتی با sudo


مثال:
curl -sSL https://example.com/install.sh | bash

برای این که سمت این پترن نریم، راه خوب اینه که اول اسکریپت رو بگیریم و تو دیسک ذخیره کنیم و بعد با ادیتور یا pager محتواشو بررسی کنیم.

ابزار vet اومده این کارو ساده کرده. با گرفتن آدرس میاد و اسکریپت رو دانلود می‌کنه، محتواشو (یا diffشو به نسبت دفعه قبل) بهتون نشون میده و حتی با shell check براتون چک می‌کنه و اگه مشکلی نبود، با اوکی شما اجراش می‌کنه. یه مقدار هم منو یاد aur helper ها میندازه که باید اول بررسی کنید اسکریپت رو و بعد نصب اتفاق میوفته.
https://github.com/vet-run/vet


این ابزار کار خاصی نمی‌کنه که اگه نصب نکنید ممکن نیست، ولی دیدگاهی که داره، «ساده کردن عادت خوب»ـه که برا من جالب بود.

https://www.linkedin.com/posts/seyyed-sajjad-fazeli-a58aa1360_python-programming-gil-activity-7356961415074574337--Tzl?

عزیزان کسی با utm se رو آیپد تا حالا لینوکس یا OS دیگه ای نصب کرده؟
بهترین معماری سیپیویی که میشه برای دبیان بیس ها گذاشت براش چیه؟
لطفاً بهم پیام بدید اگر تجربه کار با UTM SE رو دارید

وقتی کاربر به ارور 404 خورد، ننویس درصورتی که این صفحه رو می‌بینی تروخدا با پشتیبانی تماس بگیرید؛ پشت صحنه یه لاگ ساده ذخیره کن تعداد اصابت هارم بنویس هر چند وقت یه بار چکش کن اون لینک هایی که زیاد اصابت می‌خوره رو بگرد ببین کجا اشتباهی جاش گذاشتی.
@Linuxor

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

مثلاً یه اشتباه رایج اینه که یه فایل یا پوشه به اسم utils درست می‌کنید، و بعد یه پکیج خارجی که importش می‌کنید هم داخلش فایلی به همین اسم داره، و متأسفانه گاهی وقتا اون پکیج به‌جای import نسبی که به این شکله؛

from .utils import *

از import مطلق یا همون بدون دات

from utils import *

استفاده کرده.
در این حالت ماژول خارجی سعی می‌کنه از لایبرری داخل پروژه استفاده کنه و کل پروژه می‌ره رو هوا!
نمونه‌ش SDK پایتون درگاه پرداخت زرین پال (zarinpal-py-sdk) هست که بخاطر رعایت نکردن استاندارد Packaging مجبورم کردن توی پروژه‌ی خودم همه جاهایی که از اسم utils استفاده کرده بودم به یه چیز دیگه تغییرش بدم، که خب منطقی نیست.

⚠️ برای اینکه از این دردسرها دور بمونید:
همیشه داخل پکیج‌ها از import نسبی استفاده کنید
از اسم‌هایی مثل utils, helpers, main, test, email, json و ... که یا کلی‌ان یا با استانداردهای پایتون تداخل دارن، پرهیز کنید یا حداقل خاص‌ترش کنید

از ابزارهایی مثل isort, flake8, pylint یا pyright کمک بگیرید تا مشکلات import رو زودتر متوجه شید
بسته‌بندی پایتون قلق داره؛ ازش غافل نشید.

@mat_log

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

https://www.linkedin.com/posts/soheilimani81_aebaewaepaesabraetaedaepaevaeqaev-codeabrwithabrsoheil-activity-7357651662972334081-DqXy?

ارشیو پروژه های اوپن سورس به زبان پارسی
📔 t.me/TheGeeksArchive‎

وقتی چندماه از ددلاین اولین پروژه‌ بکندت گذشته و هنوز که هنوزه کارش تموم نشده:

#meme

کد تخفیف مکتبخونه: HAMDELI
لیست دوره‌هاش:
https://land.maktabkhooneh.org/hamdeli/

ممنون از Ehsan H

اگر می خواید AI جاتون رو نگیره سعی کنید Requirement Engineering رو یاد بگیرید و بفهمید.

یک کتاب خفن در موردش
Software Requirements Third Edition - Joy Beatty

متن بالا بخشی از یه پست کانال thisisnabi بود 😁

توضیحات chatgpt:
مهندسی نیازمندی‌ها یا Requirement Engineering بخشی از فرآیند توسعه نرم‌افزار است که به شناسایی، تحلیل، مستندسازی و مدیریت نیازمندی‌های سیستم می‌پردازد. هدف از این علم، اطمینان از این است که نرم‌افزار در نهایت به نیازها و خواسته‌های کاربران و ذینفعان پاسخ می‌دهد.

فرآیند مهندسی نیازمندی‌ها معمولاً شامل مراحل زیر است:

1. شناسایی نیازمندی‌ها**: در این مرحله، نیازمندی‌های واقعی سیستم شناسایی می‌شوند. این کار معمولاً با جمع‌آوری اطلاعات از ذینفعان، مصاحبه‌ها، کارگاه‌ها و بررسی مستندات موجود انجام می‌شود.

2. تحلیل نیازمندی‌ها**: نیازمندی‌ها تحلیل و بررسی می‌شوند تا مشخص شود که آیا آنها قابل فهم، کامل، قابل اندازه‌گیری و قابل تحقق هستند یا خیر.

3. مستندسازی نیازمندی‌ها**: نیازمندی‌ها باید به شکل مستند و مطابق با استانداردهای مشخصی ثبت شوند تا در آینده بتوان به آنها مراجعه کرد.

4. تایید نیازمندی‌ها**: پس از مستندسازی، نیازمندی‌ها باید توسط ذینفعان تأیید شوند تا از صحت و تناسب آنها اطمینان حاصل شود.

5. مدیریت نیازمندی‌ها**: نیازمندی‌ها باید به طور مداوم مدیریت شوند تا تغییرات و اصلاحات لازم در طول فرآیند توسعه نرم‌افزار اعمال شوند.

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

فکر می‌کنی مانیتورینگ فقط متریک CPU و رم گرفتن از سروره؟ SkyWalking می‌گه نه، باید بفهمی سرویس A چرا دیر جواب داد، کدوم کال ازش رد شد و چطور به سرویس C رسید. اینجاست که tracing و dependency mapش به کارت میاد.

یه ابزار لازم برای هرکسی که با معماری سرویس‌محور (microservices) زیاد سرو کله می‌زنه، خیلی جالبه آپاچی انقدر ابزار هاش زیاده من تازه اینو دیدم :)

دانلود :
skywalking.apache.org

@Linuxor

ایده هاتون رو بیشتر مواقع با بقیه به اشتراک بزارید؛ ایده های پیاده نشده واقعا آنچنان ارزش ندارن؛ ولی ممکنه زود تر به این نتیجه برسید که ایده اشتباهه. یه جوری مثل Bloom Filter هستش ... شاید تضمینی برای تایید کسی بهتون نده ولی تضمین رد دقیقی ممکنه بگیرید.

بلوم فیلتر : یه چیزیه که توی دیتابیسا استفاده میکنن برای اینکه سریع بفهمن یه داده وجود نداره؛ اما اگه بگه وجود داره ممکنه اشتباه باشه.


@Linuxor

بزرگترین ترس یه Developer چیه؟ اینکه کدی که با کلی زحمت نوشته، فقط روی یه پلتفرم خاص (مثلا AWS یا Azure) کار کنه و نشه راحت جابجاش کرد. Dapr با یه ایده هوشمندانه این مشکل رو حل کرده. این ابزار یه لایه انتزاعی (abstraction layer) روی سرویس‌های مختلف مثل صف پیام (message queues) و دیتابیس‌ها می‌کشه. یعنی تو کد خودت رو فقط برای Dapr می‌نویسی، و Dapr خودش با هر سرویسی که زیرش باشه (مثل RabbitMQ یا Redis) ارتباط برقرار می‌کنه.

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

مستندات و توضیحات بیشتر :

dapr.io

@Linuxor

یکی از قابلیت‌های کمتر شناخته‌شده Git که می‌تونه زندگی کاری‌تون رو آسون‌تر کنه، 𝐠𝐢𝐭 𝐰𝐨𝐫𝐤𝐭𝐫𝐞𝐞 هست.
باهاش می‌تونید چندین محیط کاری جدا از هم داشته باشید، هر کدوم روی یک شاخه مستقل، ولی همه از یک ریپازیتوری.

✅ فرض کنید روی برنچ A هستید و ناگهان باید روی برنچ B کار کنید. به جای اینکه تغییرات رو stash کنید و شاخه عوض کنید، می‌تونید یک 𝐰𝐨𝐫𝐤𝐭𝐫𝐞𝐞 جدید بسازید:

𝐠𝐢𝐭 𝐰𝐨𝐫𝐤𝐭𝐫𝐞𝐞 𝐚𝐝𝐝 ../𝐁-𝐟𝐨𝐥𝐝𝐞𝐫 𝐁


✅ با این دستور، یک پوشه جدید به نام 𝐁-𝐟𝐨𝐥𝐝𝐞𝐫 ساخته میشه که روی برنچ B هست. الان می‌تونید داخل این فولدر، کد رو تغییر بدید، تست کنید و commit بزنید، بدون اینکه کاری به شاخه فعلی‌تون داشته باشید.

اگر اهل کار موازی روی چند فیچر یا رفع باگ هستید، این ابزار می‌تونه سرعت‌تون رو چند برابر کنه.

داکیومنت رسمی گیت درباره worktree رو ‌می‌تونید از لینک زیر مطالعه کنید:
https://git-scm.com/docs/git-worktree

از این مقاله هم می‌تونید برای مطالعه بیشتر و بررسی مثال‌ها استفاده کنید:
https://mskadu.medium.com/mastering-git-worktree-a-developers-guide-to-multiple-working-directories-c30f834f79a5

منبع: لینکداین