‏راهنمای رفع ارور ۴۰۳ در پروژه‌ها مخصوصاً پروژه OpenAi می‌تونید آدرس پروکسی رو در .env ذخیره کنید و با لود کردن اون توی کل ترمینال و اپتون دسترسی به پروکسی داشته باشید.این روش جواب برای زمانی عه که proxy دارید ولی بازم 403 میگیرید.

@DevTwitter | <M.Sadegh/>

یکی از بهترین روشهای یادگیری مدلهای transformers اینه که تصویری ببینیم چطورکارمیکنن بخصوص قسمت attention.یک نفر یک اپ درست کرده که عالی نشون میده مدلهای GPT چطور کارمیکنن. جالب اینکه مدل GPT-2 را درbrowser اجرا میکنه که میتونید با تکست خودتون امتحان کنید.

https://poloclub.github.io/transformer-explainer/

@DevTwitter | <Mehdi Allahyari/>

تجربه به من ثابت کرده خیلی‌ها مثل من فایل‌های PDF رو ذخیره می‌کنند که یه روزی مطالعه کنند ولی در اکثر موارد اون روز نمی‌رسه.

این AI کمک می‌کنه فایل PDF رو خلاصه کنید. من دو تا فایل تست کردم ناراضی نبودم.
لینک:

pdfsummarizer.org‎

@DevTwitter | <Saman Faegh/>

وای فای (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/>