🎨 دوره آموزشی آزاد نرم‌افزار گرافیکی گیمپ (GIMP)

#به_مناسبت_روز_آزادی_نرم_افزار
#دوره_آزاد #گیمپ

🐧 سال‌هاست این باور اشتباه وجود دارد که نمیتوان کارهای گرافیکی قوی در محیط گنو/لینوکس انجام داد!

این باور عمدتاً از سوی تبلیغات نرم‌افزارهای انحصاری و محدودکننده ترویج شده تا کاربران را مجبور به پذیرش قیدوبندهای نرم‌افزارهای بسته کنند.
در حالی که مسئله اصلی، محرومیت از آزادی‌های اساسی مانند ویرایش، اشتراک‌گذاری و درک نحوه عملکرد ابزارها است نه صرفاً انحصار مالی!

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

📌 درباره این دوره
مدرس دوره: سام نیکزاد
تعداد جلسات: ۶۰ جلسه
فایل راهنما: دارد


🔗 ادامه مطلب، مشاهده دوره و دسترسی به فایل‌ها

نمیشه مثل آدم ایمیل ساخت دیگه نه؟
چندروزه در تلاشم با گوگل یا ماکروسافت ایمیل بسازم نشده، امروز با ماکروسافت ساختم اونم لاک شد :)))

🚨 اگر می‌خوای قبل از همه بفهمی سایت یا سرورت Down شده و اولین نفر از Down Time باخبر شی
🔒 اگر می‌خوای قبل از منقضی شدن SSL سایتت، متوجه بشی و Renew کنی SSL رو
⚡️ اگر دوست داری UP Time یک پورت از سرورت رو بررسی کنی
📊 اگر می‌خوای مطمئن باشی سرورات همیشه زیر نظرن و گزارش‌گیری داشته باشی

🤖 مجموعه‌ی ما می‌تونه کمکت کنه!

🚀 شروع کن با ربات: @NetSentinel24Bot
📌 کانال: @NetSentinel24
🤙 پشتیبانی: @NetSentinel24Support

🔥 حرفه‌ای‌ها همیشه یه نگهبان دارن!

این یه ابزار مدیریت پروژه متن‌باز و رایگانه که به‌عنوان جایگزینی برای ابزارهای معروفی مثل جیرا و Linear، Monday ساخته شده. در واقع این ابزار فرآیندهای مدیریت پروژه رو ساده سازی می‌کنه و پیگیری مشکلات، برنامه‌ریزی دوره‌ها (Cycles) و نقشه‌راه محصولات رو هم بدون پیچیدگی اضافی می‌تونید باهاش مدیریت کنید


کافیه توی سایتش با گوگل یا گیتهابتون لاگین کنید بعدش بهتون داشبورد رو می‌ده توش حتی هوش مصنوعی هم برای کمک داره :
plane.so

@Linuxor

می‌دونستین با Pydantic می‌تونید داده‌ها رو توی Python خوکار اعتبارسنجی کرد و مطمئن بشید که همیشه طبق مدل شما هستن؟
از انواع داده های ساده بگیر تا داده های پیچیده مثل ایمیل تا تاریخ و بقیه ساختار های پیچیده دیگه توی API ها خیلی از این استفاده می‌کنن و مدیریت خطا و راحتی کارو خیلی زیاد می‌کنه

مستنداتش :
docs.pydantic.dev/latest

داده هاش هم ميتونید بدید بهLogfire که داده‌های ساختاریافته رو ذخیره و لاگ می‌کنه تا بتوانید بعداً تحلیلش کنید


@Linuxor

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

این پروژه دقیقاً واسه همین دردسر ساخته شده.

می‌تونید درگاه‌هایی مثل زرین‌پال و زیبال رو به راحتی متصل کنید و پرداخت‌های محصولاتتون رو مدیریت کنید


https://github.com/mjavadalavi/gateway_proxy

@DevTwitter | <S.MJavad Alavi/>

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

https://github.com/MSAdevelopment/Quick-Utility

@DevTwitter | <Sadra/>

کی حال داره این همه متن رو بخونه و ادیت کنه 😫

Action up:
Interactive CLI tool to update GitHub Actions to latest versions with SHA pinning

https://github.com/azat-io/actions-up

#tools #github #actions

"Just run the goddamn code" - P.1
——————————————————

خب امروز آخر جلسه یه بحثی شد در مورد مدل چکینگ و به طور خاص Stateless Model Checking. به چند تا ابزار خاص اشاره کردیم که کارشون تست کردن برنامه‌های concurrent و distributed ای هستش که با یک زبان برنامه‌نویسی نوشته میشن. این ابزارها معماری‌شون به طور abstract بدین صورته که از ۳ جزء خیلی مهم تشکیل میشن :

1. Instrumentation :

پروسه‌ی test با این فاز شروع میشه. توی این قسمت برنامه از ورودی خونده میشه و روی سینتکسش تغییراتی صورت میگیره و چیزهایی اضافه میشه. این تغییرات در بهترین حالت باید روی کد میانی این زبان‌ها اجرا بشن. یعنی بعد از کامپایل شدن. به‌طور مثال در زبان‌های مبتنی بر JVM این تغییرات باید روی bytecode حاصل از compile صورت بگیره. اما دقیقا چه چیزهایی دست‌خوش تغییرات میشن؟ اولین چیز اینه که ما باید تمام عملیات‌های مربوط به concurrency رو تشخیص بدیم. برای مثال وقتی که یک thread یا process میخواد مقداری رو از روی یک shared variable بخونه و یا بنویسه ( عملیات‌های read و write) یا زمانی که یک ترد یا پراسس قراره ساخته بشه و استارت بشه (create , start) زمانی که یک ترد یا پراسس میخواید terminate بشه یا join بشه (join و terminate). این‌ها عملیات‌های پایه هستند و به محض شناسایی این دستورات در بایت‌کد، میایم و یک breakpoint قبل و بعد صدا شدن این دستورات قرار میدیم. این breakpoint ها میتونه صدا زدن یک تابع باشن که خودمون نوشتیم ( توی بخش دوم بیشتر توضیح میدم). علاوه بر عملیات‌های پایه باید توی کد بریم و ببینیم از چه کتابخونه‌ها و api هایی مربوط به concurrency استفاده شده. به طور مثال شما توی جاوا میتونید برای انجام عملیات‌های atomic از پکیج atomic استفاده کنید. این پکیج اجازه میده شما متغیرهایی رو از تایپ‌های atomicInteger و atomicBoolean و ... تعریف کنید و عملیات‌های اتومیک مثل compare-and-set روشون انجام بدید. کاری که باید انجام بدید اینه که تمام این api ها و کتاب‌خونه ها رو بریم کدشون رو کپی کنیم و توی یه پیکیج جدید paste کنیم و اون breakpoint ها رو جاهای درستی قرار بدیم ( به عبارت دیگه این مرحله در سطح زبان انجام میشه نه بایت کد). در ادامه هر جای که یک ترد یا پراسس از اون کتابخونه یا api استفاده کرده، آدرس پکیجش رو با اونی که خودمون نوشتیم عوض کنیم.

2. Runtime :

حالا کاری که باید انجام بدیم نوشتن یک runtime بسیار بسیار سبک و جمع جوره. چرا ما به یک runtime نیاز داریم؟ چون قراره که مدیریت scheduling تردها و پراسس‌ها رو دست بگیریم. یعنی قراره که runtime ما قبل از تست برنامه‌ی کاربر لود بشه و کنترل مدیریت تردها و پراسس‌های برنامه‌ی کاربر رو دست بگیره. اون توابعی هم که توی قسمت قبل تحت عنوان breakpoint اضافه کردیم، در حقیقت ارجاع دادن به همین runtime هست. به طور مثال یک ترد حین اجرا قراره عملیات write انجام بده. قبل از انجام عملیات، این قضیه رو به runtime اطلاع میده و wait میکنه. بعد scheduler بیدار میشه و تصمیم میگیره که آیا به اون ترد اجازه انجام write رو بده یا یک ترد دیگه رو resume کنه (توضیحات بیشتر در قسمت سوم). با plug and play کردن این runtime با کد instrument شده‌ی کاربر، ابزار ما میاد و برنامه‌ی کاربر رو با اجرا کردن برنامه تست میکنه. چیزی که توی runtime نیاز داریم داشته باشیم یک ترد scheduler برای مدیریت ترد‌هاست و علاوه بر اون نیازه که یک state بسیار کوچک و محدود از تردها نگه داریم. مثلا اینکه چندتا ترد توی برنامه در حال اجراست. یا تردها هر کدوم توی چه وضعیتی هستند. یا اینکه هر ترد چه منابعی رو (مثل lock) در اختیار داره و چه منابعی رو درخواست داده که بگیره. نگه داری این اطلاعات برای انجام scheduling لازمه و حتی کمک میکنه که deadlock و چیزهای شبیه به این رو هم کشف کنیم. توجه کنید، درسته که برنامه‌ی کاربر مالتی‌ترد هست و تردها در عمل به شکل همزمان با هم اجرا میشن، اما runtime ما تضمین میکنه که در هر لحظه فقط یک ترد از برنامه‌ی کاربر در حال اجراست و به نوعی میایم اجرای برنامه رو serialize میکنیم. این امر به ما کمک میکنه که بتونیم درستی ابزار خودمون رو بررسی کنیم و همه چیز تحت کنترل‌مون باشه.

🔶 جدیدا آی پی هایی v2ray با پورت ۴ الی ۵ رقمی زیاد شده که کلیک می کنید ۱۵ ثانیه بعد از کار می افته و به نظر میاد پورت فیک هست.

آی پی با پورت ۴۴۳ و ۸۰ خیلی کم پیدا میشه...

مثلا پورت:

45323
46964
59185

@TheRaymondDev

"Just run the goddamn code" - P.2
——————————————————

3. Strategy

آخرین و مهم‌ترین بخش اینه که ابزار ما چطور قراره interleaving های مختلف تردهای برنامه‌ی کاربر رو محاسبه کنه. به جرئت میتونم بگم که مهم‌ترین تفاوت ابزارهای این مدلی توی همین بخشه. runtime با استفاده از یک interface میتونه از strategy های مختلفی استفاده کنه. این interface شامل ۲ تا فانکشن هستش. فانکشن اول update event هستش. وقتی که runtime ما متوجه میشه یک ترد wait کرده و قراره دستور جدیدی رو اجرا کنه، این دیتا برای strategy ارسال میشه. فانکشن دوم next thread هست. بعد اینکه دیتا رو به strategy دادیم، scheduler ازش میپرسه که الان کی رو schedule کنم. اما این interface چطور میتونه پیاده بشه، این interface میتونه در قالب یک استراتژی مبتنی بر random selection پیاده بشه که حاصلش میشه random testing. میتونه یک استراتژی مبتنی بر fuzzing باشه که معادل یک fuzzer میشه. میتونه هم این استراتژی مبتنی بر محاسبه‌ی تمام interleaving های ممکن باشه که میشه یک model checker. پس عملا شما میتونی یه ابزاری بسازی که میتونه از پس هر ۳ کار بربیاد.

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

خب ادیت تموم شد. بخونید تا من بخش سوم رو هم بنویسم.

GitHub Lunched a new MCP Registry

https://github.com/mcp

#github #mcp

"Just run the goddamn code" - P.3
——————————————————

1. Weaver
با زبان Scala نوشته شده و برای برنامه‌های همروند Scala ساخته شده. فقط رندوم تستینگ داره و مدل چکینگ نمی‌کنه. distributed سیستم رو هم ساپورت نمی‌کنه. روی مموری مدل‌های مختلف هم ناتوانه
2. Loom
با rust نوشته شده و طبیعتا برای برنامه‌های rust هم کار میکنه. اینم تستینگ‌داره ولی یکمی بهنیه‌تره الگوریتمش ولی بازم مدل چکر نیست ( اگر چه که یک اثبات نصفه و نیمه‌ی completeness داره). distributed سیستم رو ساپورت نمی‌کنه. مموری مدلی که ساپورت میکنه C11 هستش و باقی رو ساپورت نمی‌کنه
3. Shuttle
اینم عین قبلیه فقط استراتژی تستش بیخیال اون completeness نصفه و نیمه شده و تمرکز بیشترش روی تسته. راجع به مموری مدل‌هایی هم که ساپورت میکنه اطلاعی ندارم :)
4. Jepsen
این با زبان Closure نوشته شده و برای برنامه‌های Distributed ای هست که با این زبان نوشته میشن. طبیعتا برنامه‌های concurrent رو ساپورت نمی‌کنه. اینم فقط رندوم تستینگ داره. اینم بگم که نمیدونم چه communication model ها رو ساپورت میکنه :) ولی کلا عشق منه و چیزی رو در من مدت‌هاست که روشن کرده!
5. Nidhugg
این با زبان C و برای برنامه‌های concurrent ای که با Pthread نوشته میشن ساخته شده. برخلاف قبلیا این مدل چکره و مموری مدل‌های مختلفی رو ساپورت میکنه مثل SC, TSO, PSO, POWER and ARM. سیستم‌های توزیعی رو ساپورت نمی‌کنه و رندوم تستینگ هم نداره.
6. Concuerror
این با زبان Erlang نوشته شده و برای همون برنامه‌ها هم کار میکنه. اینم مدل چکره مثل قبلی ولی مموری مدل‌های مختلف رو ساپورت نمی‌کنه. distributed systems رو هم همینطور. اینم خیلی عشقه و خیلی دوستش دارم.
7. TraceForge
اینو استاد راهنمای من ساخته و همکاراش توی aws. با rust نوشتن و برای برنامه‌های distributed ای که با این زبان نوشته میشن توسعه یافته. برنامه‌های concurrent رو ساپورت نمی‌کنه. مدل چکره و تستینگ نداره. communication model های مختلفی رو ساپورت میکنه. احتمالا به زودی روی این کار کنم و ساپورت concurrent programs و مدل چکینگ و تستینگ رو هم بهش اضافه کنم
8. GenMC
این یه مدل چکره معروفه که با C و Cpp نوشته شده و هدفش وریفای کردن برنامه‌های مالتی‌ترد زبان C هستنش. رندوم تستینگ نداره و distributed سیستم‌ها رو هم ساپورت نمی‌کنه. ولی تمام مموری مدل‌ها رو تفریبا ساپورت میکنه
9. Lincheck
این با Kotlin نوشته شده که برای رندوم تست برنامه‌های همروند کاتلین عه. میگن مدل چکر هم دارن ولی زر میزنن. مموری مدل هم ندارن کلا. distributed system هم ساپورت نمی‌کنن. کلا چیز چرتیه به نظرم :) ولی سر و صدا زیاد کرده
10. Coyote
این با C-sharp نوشته شده و برای تست برنامه‌های همروند نوشته شده با همین زبان به کار میره. مموری مدل خاصی رو ساپورت نمی‌کنه و مدل چکینگ هم نداره. distributed systems رو هم ساپورت نمی‌کنه.
11. Fray
اینم با جاوا نوشته شده و برای تست برنامه‌های همروند جاواست. مدل چکر نداره. distributed سیستم‌ها رو ساپورت نمی‌کنه. مموری مدل خاصی رو هم دنبال نمی کنه.
12. JMC
این با Java نوشته شده و کار این حقیر و دوستان بنده هستش. این ابزار هم مدل چکینگ میکنه هم رندوم تستینگ. هم concurrent رو ساپورت میکنه هم distributed system ها رو. مموری مدل هم SC رو ساپورت میکنه و communication model هم async. توسعه دادن استراتژی براش کار بسیار راحتیه. الگوریتم مدل چکینگ این ابزار data non-determinism رو هم ساپورت میکنه که هیچکدوم از مدل‌چکرای بالایی ساپورت نمی‌کنن. نسخه‌ی کامل این ابزار توی برنچ old-main هستش و برنچ main ورژن refactor شده‌ی پروژه رو داره که هنوز کامل نشده.

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

به نظرم کاتلین و Go مستعد ترن برای ساخت یه ابزار درست حسابی براشون.

همین دیگه خسته نباشید

Tea scum
و سختی آب قبل و بعد از تصفیه با فیلتر (اونی که بیشتره آبیه که با فیلتر تصفیه شده)