وای فای (Wi-Fi) مخفف Wireless Fidelity یک شبکه بی سیمه
تحت استاندارد IEEE 802.11
802.11a/b/g/n (WiFi 4)/ac (WiFi 5)/ax (WiFi 6)/ax (WiFi 6E)/ be (WiFi 7)
سایت زیر اطلاعات خوبی در مورد wifi بهتون میده
wiisfi.com‎

@DevTwitter | <MehrdadLinux/>

‏نحوه عملکرد کوانتوم سِرچ در کامپیوتر های کوانتومی.

@DevTwitter | <S01/>

#لاس

ببخشید شما double هستی؟
آخه همیشه تو قلب من floatـی

@DevTwitter

‏تو این رایت‌اپ سعی کردم یه مایندستی که خیلی میتونه به‌دردتون بخوره رو تو سناریو واقعی نشونتون بدم.
(آسیب‌پذیری‌ کیف‌پول تو یکی از سایت‌های ایرانی)
امیدوارم لذت ببرین.

https://huntlearn.com/blogs/Unlimited-wallet-recharge-in-one-of-the-well-known-Iranian-platforms

@DevTwitter | <Erfan Tavakoli/>

سایت roadmap.sh‎ خوب بود، خوب تر هم شد. اخیرا شروع کرده به تعریف کردن پروژه های مرتبط با هر مسیر به صورت سطح بندی شده.

@DevTwitter | <Amir/>

رودمپ میکروسرویس

@DevTwitter

خیلی وقتا وسط کار مجبوری بری توی سایت های مختلف تا یه بار JWT دیباگ کنی یه بار بری یه سایت دیگه timestamp رو چک کنی یا Json رو بتونی parse کنی یا ...

با این ابزار میتونی همه رو یه جا داشته باشی
هم نسخه های مک، ویندوز و لینوکس داره هم میتونید از سایتش استفاده کنید تا همه اینا رو کنار هم داشته باشید

https://github.com/Jamalianpour/open-dev

@DevTwitter | <Mohammad/>

کدت رو بنویس و دیگه نگران تست نوشتن نباش، من می‌نویسم برات!

این شعار هوش مصنوعی جدیدی هستش به اسم Celp که در مقام یک دستیار تمام عیار در کنارتونه و دیگه شما رو از شر دغدغه تست نوشتن‌های روزمره راحت می‌کنه و البته هنوز اول راهه اما خروجی خیلی خوبی داره در مقایسه با Github Copilot و پیشنهاد می‌کنم حتما امتحانش کنید
https://celp.ai

@DevTwitter | <Ali.T/>

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

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

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

پایبندی به فلسفه کد تمیز:
کد تمیز (Clean Code) به معنای کدی است که خوانا، قابل فهم و بدون شلوغیهای اضافی باشد. وجود کدهای کامنتشده در مخزن شما برخلاف این فلسفه است، زیرا این کدها میتوانند باعث ایجاد ابهام و سردرگمی شوند. مثلاً ممکن است یک توسعهدهنده دیگر از خودش بپرسد که آیا این کد کامنتشده باید به کد اصلی اضافه شود یا نه. این موضوع میتواند باعث کاهش بهرهوری و ایجاد خطاهای غیرمنتظره در آینده شود.


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

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

@DevTwitter | <Mohammad Abdorrahmani/>

اخیرا دارم روی یه ریپو کار می کنم که دیزاین پترن ها رو به روش کاربردی به همراه دیاگرام نشون بده. همچنین تست هاشو نوشتم تا برای کسی که می خواد نحوه تست نویسی برای پترن ها رو یاد بگیره. از این لینک می تونین ببینین (اگه خوشتون اومد ممنون میشم استار بدین )
https://github.com/vahidvdn/realworld-design-patterns

@DevTwitter | <Vahid/>

چنل توسعه دهندگان وب و برنامه نویسان!
(𝗙𝗿𝗼𝗻𝘁𝗘𝗻𝗱 & 𝗕𝗮𝗰𝗸𝗘𝗻𝗱)

@Dr_Front

نیاز به پردازش PDF دارید اما نمی‌خواهید از سرویس‌های آنلاین استفاده کنید؟ از ابزارهای خط فرمان یا سرویس‌های خود میزبانی شده مثل Stirling PDF استفاده کنید.

https://github.com/Stirling-Tools/Stirling-PDF

@DevTwitter | <Mr.Programmer/>

امروز که داشتم تو گیت هاب یه چرخی میزدم، این ریپو رو پیدا کردم. خیلی جالب بود برام!

تا میتونید کد بخونید تا با دست خط بقیه و راه های متفاوت پیاده سازی، آشنا بشید.
امیدوارم برای شما هم مفید باشه.

https://github.com/laravel98developer/laravel-hiring-projects

@DevTwitter | <Ali Salehi/>

اگه به لینکی مشکوک هستید میتونید اول رو این مرورگر مجازی بازش کنید
browser.lol‎

@DevTwitter | <kharabam/>

چرا برنامه‌نویسای فرانت‌اند هم باید به داکر توجه کنن؟

تا حالا شده به داکر فکر کنی؟
معمولاً داکر رو بیشتر توی کارای بک‌اند و DevOps استفاده می‌کنن، ولی برای فرانت‌اند هم می‌تونه خیلی مفید باشه!

حالا چرا؟

همه جا مثل هم کار می‌کنه: فرض کن یه پروژه رو روی سیستم خودت ران می‌کنی و همه چی اوکیه، ولی همون پروژه رو روی سرور ران می‌کنی و خراب میشه. داکر این مشکل رو حل می‌کنه؛ چون محیطی که توش کار می‌کنی رو دقیقاً مثل سرور می‌سازه. دیگه اون مشکل همیشگی "روی سیستم من که کار می‌کرد" رو نداری!

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

جداسازی محیط‌ها: مثلاً داری روی چند پروژه کار می‌کنی که هر کدوم نسخه‌های مختلفی از Node.js یا ابزارای دیگه رو نیاز دارن. داکر اینو خیلی راحت می‌کنه؛ هر پروژه توی محیط خودش اجرا میشه و هیچ مشکلی پیش نمیاد.

تست و استقرار راحت‌تر: با داکر می‌تونی پروژه‌ت رو به راحتی توی خط CI/CD (یک پست دربارش ساختم)ببری، یعنی تست، ساختن و استقرار پروژه خیلی ساده‌تر میشه.
مثلاً فرض کن داری توی پروژه‌ت از React استفاده می‌کنی؛ با داکر می‌تونی مطمئن باشی که همون چیزی که روی سیستم تو هست، روی سرور هم همونه.

همکاری بهتر با بک‌اند: با Docker Compose، می‌تونی کل برنامه‌ت رو با همه بخش‌هاش (فرانت، بک‌اند، دیتابیس) یه جا راه بندازی. اینجوری تیم‌های فرانت‌اند و بک‌اند راحت‌تر می‌تونن با هم کار کنن و همه چی درست کار کنه.

آزمایش و نمونه‌سازی راحت‌تر: می‌خوای یه ابزار یا فریم‌ورک جدید رو امتحان کنی؟ با داکر می‌تونی بدون اینکه چیزی رو به هم بریزی، یه محیط جدید درست کنی، امتحانش کنی و بعدشم خیلی راحت پاکش کنی!

مثال کاربردی:

فرض کن داری یه اپلیکیشن پیچیده با Micro Frontends توسعه میدی.
توی این اپلیکیشن، چندین تیم مختلف به صورت مستقل روی بخش‌های مختلفی از پروژه کار می‌کنن؛
مثلاً یه تیم داره روی بخش اصلی کار می‌کنه که با React توسعه داده شده، تیم دیگه روی یه بخش فرعی کار می‌کنه که از Angular استفاده می‌کنه، و یه تیم دیگه هم داره با Vue.js یه بخش دیگه رو می‌سازه.
حالا چالش اصلی اینه که هر کدوم از این تیم‌ها نیاز به ابزارهای مختلفی دارن، مثل Webpack، Rollup یا Parcel، و همچنین نسخه‌های مختلفی از Node.js.

حالا یکی از مشکلاتی که بوجود میاد , تداخل ابزارها و نسخه‌هاست.
فرض کن یکی از تیم‌ها به نسخه‌ای از Webpack نیاز داره که با نسخه‌ی دیگه‌ای که یه تیم دیگه استفاده می‌کنه، سازگار نیست.
اگه این نسخه‌ها رو روی یه سیستم نصب کنی، ممکنه تداخل و مشکلاتی در اجرای پروژه‌ها به وجود بیاد.

با Docker، می‌تونی برای هر بخش از Micro Frontend یه کانتینر جداگانه بسازی که توش تمام ابزارها و تنظیمات مربوط به همون بخش وجود داره. این یعنی هر تیم می‌تونه نسخه‌ها و ابزارهایی که نیاز داره رو بدون نگرانی از تداخل با سایر تیم‌ها، توی کانتینر خودش داشته باشه.

پس داکر فقط برای بک‌اند نیست! فرانت‌اندی‌ها هم می‌تونن باهاش کلی بهره ببرن.

@DevTwitter | <AmirAli Fakhari Zavareh/>

یه مقاله تازه و مفصل، که نکات ساده و پیشرفته ای رو برای React ارائه کرده

به شخصه معتقدم یکی از علل مهم تفاوت کیفیت برنامه نویس ها و محصولات در رعایت کردن یا نکردن نکات خیلی ریز هست، دونستن best practiceها کمک میکنه جزییات رو بهتر مدیریت کنیم.

یه best practice هم قرار نیست همیشه بهترین راه باشه، اما احتمالا در شرایط عمومی زیادی میشه استفاده ش کرد.
101 React Tips & Tricks For Beginners To Experts
https://dev.to/_ndeyefatoudiop/101-react-tips-tricks-for-beginners-to-experts-4m11

@DevTwitter | <Hossein Nazari/>

در لاراول بین fillable$ و guarded$ چه تفاوتی وجود دارد؟
در لاراول، ویژگی‌های fillable و guarded برای تعیین و کنترل ویژگی‌هایی از مدل که می‌توانند به‌طور جمعی در پایگاه داده ذخیره شوند، استفاده می‌شوند.



1. ویژگی fillable: این ویژگی به شما اجازه می‌دهد مشخص کنید که کدام ویژگی‌های مدل می‌توانند به صورت دسته‌ای (bulk) پر شوند. به عبارت دیگر، تنها ویژگی‌های لیست شده در $fillable می‌توانند از طریق انتساب دسته‌ای مقداردهی شوند. این روش به شما این امکان را می‌دهد تا فقط ویژگی‌های خاصی از مدل را که برای پر کردن آن‌ها مجاز هستید، مشخص کنید.

مثال :

rotected $fillable = ['name', 'email', 'password'];

در این مثال، تنها فیلدهای name، email و password می‌توانند از طریق انتساب دسته‌ای مقداردهی شوند.

2. ویژگی guarded: این ویژگی برعکس $fillable عمل می‌کند و مشخص می‌کند که کدام ویژگی‌های مدل نمی‌توانند به صورت دسته‌ای پر شوند. به عبارت دیگر، ویژگی‌های لیست شده در $guarded در برابر انتساب دسته‌ای محافظت می‌شوند و باقی ویژگی‌ها قابل انتساب هستند.

protected $guarded = ['id'];

در این مثال، تنها ویژگی id از انتساب دسته‌ای محافظت می‌شود و بقیه ویژگی‌ها قابل پر شدن به صورت دسته‌ای هستند.

اگر شما از
protected $guarded = [];

استفاده کنید، به این معناست که هیچ فیلدی در مدل شما از انتساب دسته‌ای (mass assignment) محافظت نمی‌شود. به عبارت دیگر، تمامی ویژگی‌های مدل می‌توانند از طریق انتساب دسته‌ای پر شوند.

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

برای امنیت بیشتر از
protected $guarded = [];
خودداری کنید.


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

استفاده آسان: در حالی که guarded ممکن است راحت‌تر به نظر برسد، زیرا شما فقط ویژگی‌هایی را که نمی‌خواهید پر شوند مشخص می‌کنید، اما اگر ویژگی‌های زیادی داشته باشید، این روش می‌تواند به اشتباهات بیشتری منجر شود.

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

@DevTwitter | <Mohammad Abdorrahmani/>

آشنایی با کلاسترینگ در دیتابیس mariadb

حتماً می‌دونید که کلاسترینگ یکی از روش‌های مهم برای افزایش دسترس‌پذیری و کارایی دیتابیس‌هاست. اما بیاید ببینیم کلاسترینگ چیه و چه تفاوت هایی با replication و sharding داره.

کلاسترینگ چیست؟

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

تفاوت کلاسترینگ با Replication

قابلیت Replication به معنی کپی‌کردن داده‌ها از یک سرور (master) به سرورهای دیگه (slaves) هست. در این حالت، فقط سرور master قابلیت نوشتن داده‌ها رو داره و سرورهای slave فقط خواندن داده‌ها رو انجام میدن. اگه master خراب بشه، باید به‌صورت دستی یکی از slaves ها رو به master تبدیل کنیم.

تفاوت کلاسترینگ با Sharding

قابلیت Sharding به معنی تقسیم داده‌ها بین چند سرور به‌طوری که هر سرور قسمتی از داده‌ها رو نگهداری می‌کنه. هر shard به‌طور مستقل کار می‌کنه و عملیات نوشتن و خواندن رو انجام میده. این روش برای مقیاس‌پذیری بهتره، ولی مدیریت پیچیده‌تری داره.

ابزارهای کلاسترینگ در MariaDB

دیتابیس MariaDB به‌صورت داخلی از کلاسترینگ پشتیبانی نمی‌کنه، ولی می‌تونید از ابزارهایی مثل Galera Cluster استفاده کنید. Galera Cluster یکی از محبوب‌ترین ابزارهای کلاسترینگ برای MariaDB هست که قابلیت‌های فوق‌العاده‌ای مثل replication همزمان، failover خودکار، و load balancing رو فراهم می‌کنه.

الگوریتم اجرای کلاسترینگ

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

مزایا استفاده از کلاسترینگ تو mariadb چیه؟

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

با اضافه‌کردن نودهای جدید می‌تونید به راحتی بار کاری رو بین نودها تقسیم کنید، این باعث میشه دیتابیس scale پذیر باشه.

درخواست‌های کاربر به‌طور خودکار بین نودهای مختلف تقسیم میشه و یه‌جور لود بالانسینگ تو دیتابیس درست میشه.

کی از کلاسترینگ استفاده کنیم؟

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

@DevTwitter | <shahriyar bayat/>

#لاس

الماسو نیستم، تو ruby منی

@DevTwitter