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

https://github.com/3lf/design-patterns-for-humans

@DevTwitter | <Ladoya/>

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

https://mentorjet.org/

پ.ن : کاملا رایگانه

@DevTwitter

اگه ubuntu نصب کردین و سورس پکیج منیجرتون روی ir.archive.ubuntu.com‎ بود احتمالا تو نصب و آپدیت‌ها به مشکل میخورین.
خیلی راحت میتونید برید داخل software & updates قسمت download from رو تغییر بدین مثلا به main server و مشکل حل میشه.

@DevTwitter | <Mohsen Khodabakhshi/>

این خبر توی کامیونیتی کلاد مثل بمب ترکیده: بصورت فاجعه‌آمیز ومسخره‌ای آمازون طی یک روز ممکنه چند هزار دلار براتون صورتحساب صادر کنه بدون اینکه شما اصلا کاری بکنید! فقط کافیه سر انتخاب اسم برای یک باکت S3 خصوصی و خالی بدشانس باشید!
داستان از این قراره که یکی اومده یه باکت رو S3 با یه اسم متداول مثل example-backup-bucket ساخته (باکت شبیه یه فولدره که اسمش باید منحصر به فرد باشه). از شانس بد طرف، همین اسم توی یه ابزار بکاپ‌گیری به عنوان نام پیشفرض باکت برای بکاپ‌ها استفاده شده بوده که باید قبل اجرای ابزار، به اسم واقعی تغییر داده بشه.
ولی خب می‌تونید حدس بزنید که خیلیا یادشون میره عوضش کنن و یا برای تست با همون کانفیگ و نام اولیه، ابزار رو اجرا می‌کنن. نتیجه این شده که طی یک روز بالای ۱۰۰ میلیون درخواست آپلود آبجکت (فایل) اومده رو باکت. از آنجایی که AWS برای درخواست‌های نامعتبر و غیرمجاز هم از شما پول میگیره، با وجود خصوصی و خالی بودن باکت، باز طرف طی یک روز بالای ۱۳۰۰ دلار پیاده شده!
این یعنی صرفا با دونستن اسم یک باکت برای شخص یا شرکت دیگه و با یه کد چند خطی می‌تونید چندین هزار دلار بهشون ضرر بزنید و عملا هیچ کاری از دستشون بر نمیاد!
همیشه توصیه میشه از اسم باکت‌ها محافظت بشه، ولی هیچوقت گفته نمیشه که باهاشون در حد داده خیلی حساس مثل پسورد رفتار بشه. در نتیجه پیدا کردن اسم باکت نسبتا راحته و سر پیاده‌سازی اشتباه یا ناقص، همین الان کلی اپ و وبسایت دارن اسم باکتاشون رو افشا می‌کنن.
این شخص این داستان رو توی مدیوم نوشته و به دلیل حساسیت موضوع، اسم اون ابزار بکاپ‌گیری و باکت بدشانس رو ننوشته. ولی انقدر کامیونیتی شوکه شده و عکس‌العمل نشون داده که توی توییتی که کوت کردم نایب رئیس AWS مجبور به توضیح دادن شده و گفته مشغول پیگیری موضوع هستن تا مشتریا بابت درخواست‌های غیر مجاز مجبور به پرداخت هزینه نشن. که خب مسلما آمازون از وایرال شدن همچین موضوعی به هیچ وجه خوشحال نیست، چرا که همین تغییر کوچیک احتمالا چند میلیون دلار از درآمد (کاذب) آمازون کم کنه! بماند که همین الان ملت شروع کردن میگن سرویس‌های دیگه AWS هم هزینه‌های کاذب مثل این داره که بعضا هیچ راهی برای کنترل کردنشون وجود نداره.

@DevTwitter | <Yashar/>

خب جوری که خبر رسیده Neofetch دیگه توسعه پیدا نمی‌کنه و پروژه‌اش هم توی Github آرشیو شده.

هرچند به زودی فورک میشه و بهتر میاد، اما حیف بود.

https://news.itsfoss.com/neofetch-rip/

@DevTwitter | <Mohammad Shokoohi/>

دستور Neofetch یک ابزار خط فرمان بود
که مجموعه ای از اطلاعات سیستم را روی یک ترمینال از جمله لوگوی سیستم عامل نمایش میداد
اینقدر این fetch ها معادل دارند که کار کشیده به awesome-fetch
در لینک زیر میتوانید نزدیک به ۱۰۰ تا از انواع fetch پیدا کنید
beucismis.github.io/awesome-fetch/‎

@DevTwitter | <MehrdadLinux/>

یه سری ریسورس برای پروژه هاتون

~ Hosting
netlify.com

~ HTML templates
htmlrev.com

~ Icons
lineicons.com

~ Fonts
fonts.google.com

~ Illustrations
hundraw.co

~ Photos
unsplash.com

~ Videos
dareful.com

~ Color Palettes
coolors.co

~ UI components
flowbite.com

~ Animations
animista.net

~ Charts
chartjs.org

~ UI inspiration
uigarage.net

@DevTwitter

همیشه یکی از خفن ترین آموزش ها برای لاراول رو Laracast داشته

توی این دوره ی کوتاه و کامل، یک فروشگاه رو صفر تا صد با لاراول و لایووایر مینویسه و آموزش میده

https://laracasts.com/series/build-a-web-shop-from-a-z

اینقدر تایمش کم و آموزش حرفه ایه که ارزش وقت گذاشتن رو داره.

@DevTwitter

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

خلاصه ۴۰۰ گیگ آزاد شد و دوباره ویندوزِ به درد نخور مثل روز اولش شد.

@DevTwitter | <Sabber/>

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


خیلی باحاله ، تست کنید

https://samperson.itch.io/desktop-goose

@DevTwitter | <Shima Fallah/>

#کدبوک

این ریپو سری کتاب های Head First رو به شکل کامل قرار داده که دانلود کنید.
تقریبا برای اکثریت زبان ها و ابزارها این سری کتاب نوشته شده

https://github.com/Contove/head_first_series_books/

@DevTwitter | <Ladoya/>

نرم افزار های anydesk و teamviewer کاربردی اند
اینجا ایرانه یک بار تحریم یک بار فیلتر گزینه های معادل متن باز
نرم افزار RustDesk
https://github.com/rustdesk/rustdesk/blob/master/docs/README-FA.mdp
نرم افزار hoptodesk روی Cloudflare با worker
https://gitlab.com/hoptodesk/hoptodesk

@DevTwitter | <MehrdadLinux/>

چرا NGINX انقدر وحشتناک سریعه؟!
بخش اول: Traffic Routing

مدتی بود دنبال پروژه ای بودم که با هدف عمیق تر شدن توی مفاهیم شبکه و کانکارنسی بتونم با سی++ پیاده سازی کنم، هم فال بود و هم تماشا .
بعد از یه مدت تصمیم گرفتم سمت وب‌سرورها برم و رفتار اونارو زیر بار بررسی کنم، سورس NGINX رو دانلود کردم و شروع کردم به بیلد کردنش و بعد از سر و کله زدن با openssl در نهایت بیلدش کردم، هدف من بیشتر مشاهده ی رفتار NGINX روی حالتی بود که میخواست Load balancing کنه .
طبق چیزی که دیدم NGINX میاد و به دو روش معمول ترافیک رو به سمت سرور های مقصد ارسال میکنه، به طوری که میتونیم بگیم به روش Reverse proxy داره ترافیک رو سمت سرور مقصد هدایت میکنه. وقتی درخواستی از سمت کلاینت ارسال میشه NGINX اون رو دریافت میکنه و طبق الگوریتمی سرور مقصد رو .
انتخاب میکنه و روش یه سوکت جدید باز میکنه همچنین ممکنه از سوکت های قبلی که اماده داره به سرور مقصد استفاده کنه تا زمان Connection Establishing رو کاهش بده، بعد ترافیک رو از کلاینت میخونه و به سمت سرور اصلی فوروارد میکنه و منتظر جواب میمونه(بخش های بعدی میگم چطور) بعد از اینکه .
جواب از سرور مقصد دریافت شد اون رو به کلاینت برمیگردونه و تمام.

حالا چرا گفتم ۲ روش؟ چون هم میتونه این کار رو توی لایه ی ۴ نتورک مدل OSI انجام بده هم میتونه توی لایه ی ۷ مدل OSI انجام بده، اگه بخواییم بهتر متوجه بشیم من هم میتونم به NGINX بگم که درخواست هارو بر اساس هدر، سشن .
یا اندپوینت هدایت کنم (لایه‌ی ۷)، هم میتونم اجازه بدم بر اساس IP یا PORT کاربر این اتفاق بیوفته (لایه‌ی ۴)
‌ وقتی ما نیاز داریم که سشن یا هدر رو چک کنیم در حقیقت نیاز داریم که داده ای که برامون ارسال شده رو باز کنیم و پردازشش کنیم و بعد بر اساس اون تصمیم بگیریم ولی توی مدل دوم.
نیازی به پردازش داده ی ارسالی نداریم و IP و PORT کاربر مشخصه، پس میتونیم بگیم روش اول توی لایه ی هفتم و روش دوم توی لایه ی چهارم اتفاق میوفته که طبیعتا سریعتر از روش اول باید باشه .

@DevTwitter | <Abolfazl/>