Forwarded from کانال مهرداد لینوکس (Mehrdad Linux)
عدم دسترسی کارشناسان نرمافزاری کشورهای تحریم شده به خدمات GitHub
منبع: همکاران سیستم
شرکت GitHub از بزرگترین پلتفرمهای توسعه نرمافزار در جریان سازگاری با تحریمهای تجاری آمریکا دسترسی به سیستمهای خود را برای توسعهدهندگان نرمافزار در کشورهای تحریم شده مسدود کرد. این سایت به اشتراک گذاری کدهای منبع نرمافزاری که از زیرمجموعههای شرکت مایکروسافت محسوب میشود هم اکنون توضیحاتی را در اختیار توسعه دهندگان نرمافزار قرار داده و توضیح داده است که از قوانین تجاری آمریکا پیروی میکند.
این طور که خبرگزاری زد.دی.نت ژوئیه امسال گزارش داد، GitHub پیشتر دسترسی به خدمات اصلی خود را برای توسعه دهندگان نرمافزاری ساکن کشورهای تحت تحریم تجاری آمریکا از جمله کوبا، ایران، کره شمالی و سوریه مسدود کرده بود.
تلاش جدید شرکت GitHub برای مطابقت با کنترلهای طولانی مدت تجاری آمریکا باعث شده است برخی توسعهدهندگان نرمافزار نادیده گرفته شوند و بر این اساس نتوانند به مخازن خصوصی کدهای منبع دسترسی پیدا کنند یا آنها را ایجاد کنند.
«نات فریدمن» مدیرعامل این شرکت توضیح داد که GitHub در تلاش است تا «طبق قوانین ایالات متحده» اقدامی بیشتر از آنچه که معین شده است را انجام ندهد. با این حال، روشهای گاه به گاه این شرکت برای همکاری با شرکتهای مختلف تاثیراتی را بر کسب و کارها و توسعه دهندگان نرمافزار که در کشورهای تحریم نشده سکونت دارند هم برجا گذاشته است و از جمله آنها میتوان به متخصصان و شرکتهای نرمافزاری در بریتانیا اشاره کرد.
یکی از روش هایی که GitHub برای تشخیص میزان دسترسی کاربران به سایت خود از کشورهای تحریم شده مورد استفاده قرار می دهد، اسکن کردن آدرسهای IP است.
منبع: همکاران سیستم
شرکت GitHub از بزرگترین پلتفرمهای توسعه نرمافزار در جریان سازگاری با تحریمهای تجاری آمریکا دسترسی به سیستمهای خود را برای توسعهدهندگان نرمافزار در کشورهای تحریم شده مسدود کرد. این سایت به اشتراک گذاری کدهای منبع نرمافزاری که از زیرمجموعههای شرکت مایکروسافت محسوب میشود هم اکنون توضیحاتی را در اختیار توسعه دهندگان نرمافزار قرار داده و توضیح داده است که از قوانین تجاری آمریکا پیروی میکند.
این طور که خبرگزاری زد.دی.نت ژوئیه امسال گزارش داد، GitHub پیشتر دسترسی به خدمات اصلی خود را برای توسعه دهندگان نرمافزاری ساکن کشورهای تحت تحریم تجاری آمریکا از جمله کوبا، ایران، کره شمالی و سوریه مسدود کرده بود.
تلاش جدید شرکت GitHub برای مطابقت با کنترلهای طولانی مدت تجاری آمریکا باعث شده است برخی توسعهدهندگان نرمافزار نادیده گرفته شوند و بر این اساس نتوانند به مخازن خصوصی کدهای منبع دسترسی پیدا کنند یا آنها را ایجاد کنند.
«نات فریدمن» مدیرعامل این شرکت توضیح داد که GitHub در تلاش است تا «طبق قوانین ایالات متحده» اقدامی بیشتر از آنچه که معین شده است را انجام ندهد. با این حال، روشهای گاه به گاه این شرکت برای همکاری با شرکتهای مختلف تاثیراتی را بر کسب و کارها و توسعه دهندگان نرمافزار که در کشورهای تحریم نشده سکونت دارند هم برجا گذاشته است و از جمله آنها میتوان به متخصصان و شرکتهای نرمافزاری در بریتانیا اشاره کرد.
یکی از روش هایی که GitHub برای تشخیص میزان دسترسی کاربران به سایت خود از کشورهای تحریم شده مورد استفاده قرار می دهد، اسکن کردن آدرسهای IP است.
Forwarded from DevTwitter | توییت برنامه نویسی
بچه ها بیکار بودم یه پکیج npm زدم میاد یه بررسی از پروژتون بهتون میده که چقدر کد زدین چیا دارین چقدر کامنت دارین و اینا
دوست داشتین نگاش کنین
کافیه بزنین
npx react-loc-analyzer
یه خروجی این شکلی باید بده بهتون
اینم npm اشه اگه خواستین کامند دقیق تر بدین
https://npmjs.com/package/react-loc-analyzer
@DevTwitter | <amiram/>
دوست داشتین نگاش کنین
کافیه بزنین
npx react-loc-analyzer
یه خروجی این شکلی باید بده بهتون
اینم npm اشه اگه خواستین کامند دقیق تر بدین
https://npmjs.com/package/react-loc-analyzer
@DevTwitter | <amiram/>
Forwarded from Software Engineer Labdon
🍾یه سری رودمپ بدرد بخور براتون ردیف کردم
🔻Engineering Manager
https://roadmap.sh/engineering-manager
🔻Software Design and Architecture
https://roadmap.sh/software-design-architecture
🔻System Design
https://roadmap.sh/system-design
🔻Software Architect
https://roadmap.sh/software-architect
➖➖➖➖➖➖➖➖
https://t.iss.one/addlist/KpzXaiSpKENkMGM0
🔻Engineering Manager
https://roadmap.sh/engineering-manager
🔻Software Design and Architecture
https://roadmap.sh/software-design-architecture
🔻System Design
https://roadmap.sh/system-design
🔻Software Architect
https://roadmap.sh/software-architect
➖➖➖➖➖➖➖➖
https://t.iss.one/addlist/KpzXaiSpKENkMGM0
Forwarded from Meitix
شاردینگ چیه؟ اصلاً چرا شاردینگ کنیم؟! 😅
وقتی دیتابیسمون بزرگ میشه و دیگه یه دونه سرور جوابگو نیست، باید دیتا رو بین چند تا دیتابیس یا حتی جدول تقسیم کنیم. این میشه همون شاردینگ. حالا بیایم ببینبم روشهاش چیه
---
1⃣ بر اساس رنج (Range-Based)
مثلاً دیتا رو بر اساس بازهی آیدی کاربرها تقسیم کنیم:
شارد ۱: کاربرهای ۱ تا ۱۰۰۰۰
شارد ۲: کاربرهای ۱۰۰۰۱ تا ۲۰۰۰۰
راحت و سادهست، ولی اگه یه بازه خیلی شلوغ باشه، دیتابیس کلافه میشه!
2⃣ بر اساس هش (Hash-Based)
بیا یه فرمول ساده بذاریم:
userID % تعداد شاردها = شماره شارد
اینطوری دیتا تقریباً یکنواخت پخش میشه. ولی اگه یه شارد اضافه یا کم کنیم، کل دیتارو باید دوباره بچینیم. 😩
3⃣ بر اساس جغرافیا (Geographic)
دیتای هر منطقه رو تو یه شارد بذاریم. مثلاً:
شارد ۱: آمریکا
شارد ۲: اروپا
ولی اگه یه منطقه مثل هند خیلی شلوغ بشه، چی؟!
4⃣ زمانی (Time-Based)
دیتا رو بر اساس زمان تقسیم کنیم. مثلاً:
شارد ۱: دیتاهای سال ۲۰۲۴
شارد ۲: دیتاهای سال ۲۰۲۵
این عالیه برای لاگها یا دیتاهای تاریخدار، ولی دیتاهای قدیمی رو کمتر کسی میخواد.
وقتی دیتابیسمون بزرگ میشه و دیگه یه دونه سرور جوابگو نیست، باید دیتا رو بین چند تا دیتابیس یا حتی جدول تقسیم کنیم. این میشه همون شاردینگ. حالا بیایم ببینبم روشهاش چیه
---
1⃣ بر اساس رنج (Range-Based)
مثلاً دیتا رو بر اساس بازهی آیدی کاربرها تقسیم کنیم:
شارد ۱: کاربرهای ۱ تا ۱۰۰۰۰
شارد ۲: کاربرهای ۱۰۰۰۱ تا ۲۰۰۰۰
راحت و سادهست، ولی اگه یه بازه خیلی شلوغ باشه، دیتابیس کلافه میشه!
2⃣ بر اساس هش (Hash-Based)
بیا یه فرمول ساده بذاریم:
userID % تعداد شاردها = شماره شارد
اینطوری دیتا تقریباً یکنواخت پخش میشه. ولی اگه یه شارد اضافه یا کم کنیم، کل دیتارو باید دوباره بچینیم. 😩
3⃣ بر اساس جغرافیا (Geographic)
دیتای هر منطقه رو تو یه شارد بذاریم. مثلاً:
شارد ۱: آمریکا
شارد ۲: اروپا
ولی اگه یه منطقه مثل هند خیلی شلوغ بشه، چی؟!
4⃣ زمانی (Time-Based)
دیتا رو بر اساس زمان تقسیم کنیم. مثلاً:
شارد ۱: دیتاهای سال ۲۰۲۴
شارد ۲: دیتاهای سال ۲۰۲۵
این عالیه برای لاگها یا دیتاهای تاریخدار، ولی دیتاهای قدیمی رو کمتر کسی میخواد.
Forwarded from Go Casts 🚀
معماری Event-Driven یه پارادایم هست که روی produce و consume کردن eventها برای اکشن های مهم سیستم و تغییرات state سیستم تاکید میکنه.
یکی از مهم ترین مزیت هاش چیه؟ اینه که producer خیلی loosely coupled میشه نسبت به consumerها و قسمت های دیگه سیستم.
مزیت های دیگه هم داره از جمله اینکه مقیاس پذیری سیستم رو راحت تر میکنه و انعطاف بیشتری به سیستم میده.
ولی خب چالش هایی هم داره، از جمله اینکه مدیریت eventها پیچیده تر میشه و مدیریت data consistency بین سرویس های مختلف رو سخت تر میکنه.
به همین دلیل، تعریف schemaی مناسب برای eventها و داشتن error handling درست روی produce و consume کردن eventها مهم میشه.
این مقاله رو دوست داشتید بخونید، مفاهیم مقدماتی رو توضیح میده
Introduction to Event-Driven Architecture
https://medium.com/microservicegeeks/introduction-to-event-driven-architecture-e94ef442d824
تعداد مشارکت کنندگاه دوره از ۵۰۰ نفر گذشت 🔥
به همین مناسبت، تخفیف ۵۳ درصدی دوره در نظر گرفتیم
جزییات بیشتر در این پست 👇
https://t.iss.one/gocasts/572
@gocasts
یکی از مهم ترین مزیت هاش چیه؟ اینه که producer خیلی loosely coupled میشه نسبت به consumerها و قسمت های دیگه سیستم.
مزیت های دیگه هم داره از جمله اینکه مقیاس پذیری سیستم رو راحت تر میکنه و انعطاف بیشتری به سیستم میده.
ولی خب چالش هایی هم داره، از جمله اینکه مدیریت eventها پیچیده تر میشه و مدیریت data consistency بین سرویس های مختلف رو سخت تر میکنه.
به همین دلیل، تعریف schemaی مناسب برای eventها و داشتن error handling درست روی produce و consume کردن eventها مهم میشه.
این مقاله رو دوست داشتید بخونید، مفاهیم مقدماتی رو توضیح میده
Introduction to Event-Driven Architecture
https://medium.com/microservicegeeks/introduction-to-event-driven-architecture-e94ef442d824
تعداد مشارکت کنندگاه دوره از ۵۰۰ نفر گذشت 🔥
به همین مناسبت، تخفیف ۵۳ درصدی دوره در نظر گرفتیم
جزییات بیشتر در این پست 👇
https://t.iss.one/gocasts/572
@gocasts
Forwarded from Go Casts 🚀
یه ویدیوی تازه و داغ که یه کتابخونه جدید رو هم معرفی میکنه برای event stream processing
Processing Millions of Events Per Second Reliably Using Generics
https://youtu.be/tedFyfKqKeI?si=HoWXARoDv0BRbQRo
A blazingly fast event stream processing library powering the reveald event processing daemon.
https://github.com/runreveal/kawa
Kawa: The Event Processor for the Grug Brained Developer
https://blog.runreveal.com/kawa-the-event-processor-for-the-grug-brained-developer/
تعداد مشارکت کنندگاه دوره از ۵۰۰ نفر گذشت 🔥
به همین مناسبت، تخفیف ۵۳ درصدی دوره در نظر گرفتیم
جزییات بیشتر در این پست 👇
https://t.iss.one/gocasts/572
@gocasts
Processing Millions of Events Per Second Reliably Using Generics
https://youtu.be/tedFyfKqKeI?si=HoWXARoDv0BRbQRo
A blazingly fast event stream processing library powering the reveald event processing daemon.
https://github.com/runreveal/kawa
Kawa: The Event Processor for the Grug Brained Developer
https://blog.runreveal.com/kawa-the-event-processor-for-the-grug-brained-developer/
تعداد مشارکت کنندگاه دوره از ۵۰۰ نفر گذشت 🔥
به همین مناسبت، تخفیف ۵۳ درصدی دوره در نظر گرفتیم
جزییات بیشتر در این پست 👇
https://t.iss.one/gocasts/572
@gocasts
Forwarded from Meitix
البته البته، انتخاب Shard Key درست یکی از مهمترین قدمها توی طراحی دیتابیس مقیاسپذیره! 😅 اگه شارد کی اشتباهی انتخاب نکنیم، سیستم میتونه خیلی زود دچار مشکلاتی مثل hotspot یا عدم تعادل در شاردها بشه.
1⃣ کاردینالیته بالا!
شارد کی که انتخاب میکنیم باید کاردینالیته بالا داشته باشه. یعنی تعداد مقادیر ممکن باید زیاد باشه تا بتونیم دادهها رو به خوبی بین شاردها تقسیم کنیم. مثلاً یه فیلد booleanخیلی محدود میشه و تعداد شاردها رو به دو تا میرسونه. انتخابهای بهتر مثل userID یا timestamp میتونن کار رو بهتر انجام بدن.
2⃣ توزیع یکنواخت (Frequency)
توی انتخاب شارد کی باید مطمئن بشیم که دادهها به طور یکنواخت پخش بشن. مثلاً اگه از سن به عنوان شارد کی استفاده کنیم، ممکنه همه دادهها توی رنج سنی ۳۰ تا ۴۵ جمع بشه و یه شارد شلوغ بشه! 🤦♂️ پس بهتره از یه شارد کی استفاده کنیم که دادهها توش پخش شده باشن.
3⃣ تغییرات یکنواخت (Monotonic Change)
اگه شارد کی یه ویژگی تغییر یکنواخت داشته باشه، مثلاً timestamp که همیشه بیشتر میشه، ممکنه همش دادههای جدید تو یه شارد بریزه. این کار میتونه باعث بشه یه شارد سنگین بشه و بقیه شاردها خالی بمونن. راهحل اینه که شارد کی رو با یه فیلد دیگه ترکیب کنیم.
1⃣ کاردینالیته بالا!
شارد کی که انتخاب میکنیم باید کاردینالیته بالا داشته باشه. یعنی تعداد مقادیر ممکن باید زیاد باشه تا بتونیم دادهها رو به خوبی بین شاردها تقسیم کنیم. مثلاً یه فیلد booleanخیلی محدود میشه و تعداد شاردها رو به دو تا میرسونه. انتخابهای بهتر مثل userID یا timestamp میتونن کار رو بهتر انجام بدن.
2⃣ توزیع یکنواخت (Frequency)
توی انتخاب شارد کی باید مطمئن بشیم که دادهها به طور یکنواخت پخش بشن. مثلاً اگه از سن به عنوان شارد کی استفاده کنیم، ممکنه همه دادهها توی رنج سنی ۳۰ تا ۴۵ جمع بشه و یه شارد شلوغ بشه! 🤦♂️ پس بهتره از یه شارد کی استفاده کنیم که دادهها توش پخش شده باشن.
3⃣ تغییرات یکنواخت (Monotonic Change)
اگه شارد کی یه ویژگی تغییر یکنواخت داشته باشه، مثلاً timestamp که همیشه بیشتر میشه، ممکنه همش دادههای جدید تو یه شارد بریزه. این کار میتونه باعث بشه یه شارد سنگین بشه و بقیه شاردها خالی بمونن. راهحل اینه که شارد کی رو با یه فیلد دیگه ترکیب کنیم.
Forwarded from DevTwitter | توییت برنامه نویسی
This media is not supported in your browser
VIEW IN TELEGRAM
وردپرس رو بدون WAF رها نکنید.
اگه از طریق CDN براتون مقدور نیست، افزونه NinjaFirewall یه وف واقعیه که درخواستها رو قبل از رسیدن به وردپرس، هوک، اسکن، پاکسازی یا رد میکنه.
تمام اسکریپتها در محل نصب وردپرس محافظت میشن و رولهای امنیتی، ساعتی بهروز میشه.
https://wordpress.org/plugins/ninjafirewall
@DevTwitter | <Yaser Shahi/>
اگه از طریق CDN براتون مقدور نیست، افزونه NinjaFirewall یه وف واقعیه که درخواستها رو قبل از رسیدن به وردپرس، هوک، اسکن، پاکسازی یا رد میکنه.
تمام اسکریپتها در محل نصب وردپرس محافظت میشن و رولهای امنیتی، ساعتی بهروز میشه.
https://wordpress.org/plugins/ninjafirewall
@DevTwitter | <Yaser Shahi/>
Forwarded from Ninja Learn | نینجا لرن
خب خب خب Django Channels چیه؟ و چرا من ازش خوشم نمیاد
قبل از اینکه با هم بریم سراغ Django Channels، یه کم درباره WebSocket بگیم که اصلاً بدونیم داریم درباره چی حرف میزنیم. خب، WebSocket یه پروتکل که بهت اجازه میده ارتباط دوطرفه و دائمی بین کلاینت و سرور داشته باشی. یعنی چی؟ یعنی مثلاً تو یه اپلیکیشن چت، به جای اینکه هر چند ثانیه یه بار درخواست بفرستی "چیزی جدید اومده؟"، سرور خودش هر وقت یه پیام جدید داشت، بلافاصله میفرسته سمتت 🚀.
حالا Django Channels چی میگه؟ 🤔
ـDjango Channels یه ابزار تو اکوسیستم Djangoئه که میاد پشتیبانی از WebSocket، پروتکلهای real-time و کارای async رو به پروژههات اضافه میکنه. به زبان ساده، اگه Django عادی رو یه "خیابون یکطرفه" فرض کنیم، Channels میاد این خیابون رو دوطرفه میکنه. این یعنی میتونی کارایی مثل:
و...
رو خیلی راحتتر با Django انجام بدی.
خب پس مشکلش چیه؟ چرا من ازش خوشم نمیاد؟ 🤷♂️
از دور که نگاه میکنی، Channels خیلی جذاب به نظر میاد، ولی وقتی میخوای باهاش کارکنی، مشکلات خودش رو نشون میده:
1⃣ پیچیدگی توی تنظیمات 😵💫
ـDjango همیشه به خاطر سادگی معروف بوده، ولی Channels میاد این سادگی رو خراب میکنه خیلی خراب میکنه. باید ASGI رو راه بندازی، Redis نصب کنی، routing یاد بگیری، و کلی تنظیمات دیگه انجام بدی. یه پروژه ساده که با Django راحت بود، یهو برات میشه یه جنگل از تنظیمات.
2⃣ وابستگی به Redis 🤦♂️
یکی از مشکلات بزرگ Channels اینه که برای مدیریت eventها و ارتباطها حتماً نیاز به Redis داره. خب چرا؟ دلیلش اینه که Redis بهعنوان message broker استفاده میشه تا پیامها بین کلاینتها و سرور مدیریت بشه. ولی اگه پروژه کوچیک باشه، این وابستگی میتونه دردسرساز بشه.
3⃣ محدودیت توی scale کردن 😩
اگه پروژه کوچیک باشه، Channels بد نیست. ولی وقتی تعداد کاربران زیاد میشه و حجم درخواستها بالا میره، Channels سریع از نفس میافته. این محدودیت بیشتر به خاطر پیچیدگی WebSocket و محدودیتهای سرورهای تک رشته ای هست تا خود Channels. برای پروژههای بزرگ و real-time محور، ابزارای دیگهای مثل Socket.IO یا FastAPI خیلی بهتر عمل میکنن.
4⃣ مشکلات performance 🚨
حتی اگه پروژه خیلی هم بزرگ نباشه، Channels برای real-time پروژههای سنگین خوب عمل نمیکنه. کارای پیچیده async و ارتباطات real-time میتونن سرور رو داغون کنن. البته با تنظیم درست workerها و Redis channel layers میتونی بخشی از این مشکلات رو کم کنی، ولی باز هم کار اضافهست.
5⃣ کمبود مستندات و منابع آموزشی درست و حسابی 📚
یکی دیگه از مشکلات اینه که منابع آموزشی کامل و بهروزی برای Channels خیلی کمه. هر وقت گیر کنی، یا باید بری توی GitHub دنبال issueها، یا دست به دامن دیگران بشی. این باعث میشه زمان زیادی صرف حل مشکلات کنی.
خب حالا راهحل چیه؟ 💡
اگه بخوای real-time کار کنی، اینا میتونن گزینههای بهتری باشن:
ـFastAPI: اگه دنبال سرعت، سادگی و پرفورمنس خوب هستی، FastAPI انتخاب فوقالعادهایه. با WebSocket خیلی راحت کار میکنه و خبری از دردسرای Channels نیست 🚀.
ـSocket.IO: این یکی برای پروژههای real-time شاهکاره. خیلی ابزارای متنوع داره و با Node.js هم عالی مچ میشه.
جمعبندی 🎯
ـDjango Channels میتونه برای پروژههای کوچیک و ساده مناسب باشه، ولی اگه بحث scale، پرفورمنس یا راحتی کار مطرح باشه، اصلاً گزینه خوبی نیست. من از پیچیدگیها و محدودیتهاش خسته شدم و به جای اون سراغ ابزارای دیگه رفتم.
نظر تو چیه؟ Django Channels تا حالا اذیتت کرده یا ازش خوشت میاد؟ بگو ببینم چی تو ذهنت میگذره🧐
➖➖➖➖➖➖➖➖➖
قبل از اینکه با هم بریم سراغ Django Channels، یه کم درباره WebSocket بگیم که اصلاً بدونیم داریم درباره چی حرف میزنیم. خب، WebSocket یه پروتکل که بهت اجازه میده ارتباط دوطرفه و دائمی بین کلاینت و سرور داشته باشی. یعنی چی؟ یعنی مثلاً تو یه اپلیکیشن چت، به جای اینکه هر چند ثانیه یه بار درخواست بفرستی "چیزی جدید اومده؟"، سرور خودش هر وقت یه پیام جدید داشت، بلافاصله میفرسته سمتت 🚀.
حالا Django Channels چی میگه؟ 🤔
ـDjango Channels یه ابزار تو اکوسیستم Djangoئه که میاد پشتیبانی از WebSocket، پروتکلهای real-time و کارای async رو به پروژههات اضافه میکنه. به زبان ساده، اگه Django عادی رو یه "خیابون یکطرفه" فرض کنیم، Channels میاد این خیابون رو دوطرفه میکنه. این یعنی میتونی کارایی مثل:
چت real-time 💬
نوتیفیکیشنهای فوری 🔔
استریم داده (مثل قیمتهای ارز دیجیتال) 📈
و...
رو خیلی راحتتر با Django انجام بدی.
خب پس مشکلش چیه؟ چرا من ازش خوشم نمیاد؟ 🤷♂️
از دور که نگاه میکنی، Channels خیلی جذاب به نظر میاد، ولی وقتی میخوای باهاش کارکنی، مشکلات خودش رو نشون میده:
1⃣ پیچیدگی توی تنظیمات 😵💫
ـDjango همیشه به خاطر سادگی معروف بوده، ولی Channels میاد این سادگی رو خراب میکنه خیلی خراب میکنه. باید ASGI رو راه بندازی، Redis نصب کنی، routing یاد بگیری، و کلی تنظیمات دیگه انجام بدی. یه پروژه ساده که با Django راحت بود، یهو برات میشه یه جنگل از تنظیمات.
نکته: از Django 4.0 به بعد، پشتیبانی از ASGI مستقیم داخل هسته Django اومده، پس برای پروژههای ساده شاید نیاز نباشه کل پروژه رو وابسته به Channels کنی.
2⃣ وابستگی به Redis 🤦♂️
یکی از مشکلات بزرگ Channels اینه که برای مدیریت eventها و ارتباطها حتماً نیاز به Redis داره. خب چرا؟ دلیلش اینه که Redis بهعنوان message broker استفاده میشه تا پیامها بین کلاینتها و سرور مدیریت بشه. ولی اگه پروژه کوچیک باشه، این وابستگی میتونه دردسرساز بشه.
جایگزین: میتونی از RabbitMQ یا حتی راهحلهای سادهتر مثل In-Memory Layers برای پروژههای سبک استفاده کنی.
3⃣ محدودیت توی scale کردن 😩
اگه پروژه کوچیک باشه، Channels بد نیست. ولی وقتی تعداد کاربران زیاد میشه و حجم درخواستها بالا میره، Channels سریع از نفس میافته. این محدودیت بیشتر به خاطر پیچیدگی WebSocket و محدودیتهای سرورهای تک رشته ای هست تا خود Channels. برای پروژههای بزرگ و real-time محور، ابزارای دیگهای مثل Socket.IO یا FastAPI خیلی بهتر عمل میکنن.
4⃣ مشکلات performance 🚨
حتی اگه پروژه خیلی هم بزرگ نباشه، Channels برای real-time پروژههای سنگین خوب عمل نمیکنه. کارای پیچیده async و ارتباطات real-time میتونن سرور رو داغون کنن. البته با تنظیم درست workerها و Redis channel layers میتونی بخشی از این مشکلات رو کم کنی، ولی باز هم کار اضافهست.
5⃣ کمبود مستندات و منابع آموزشی درست و حسابی 📚
یکی دیگه از مشکلات اینه که منابع آموزشی کامل و بهروزی برای Channels خیلی کمه. هر وقت گیر کنی، یا باید بری توی GitHub دنبال issueها، یا دست به دامن دیگران بشی. این باعث میشه زمان زیادی صرف حل مشکلات کنی.
خب حالا راهحل چیه؟ 💡
اگه بخوای real-time کار کنی، اینا میتونن گزینههای بهتری باشن:
ـFastAPI: اگه دنبال سرعت، سادگی و پرفورمنس خوب هستی، FastAPI انتخاب فوقالعادهایه. با WebSocket خیلی راحت کار میکنه و خبری از دردسرای Channels نیست 🚀.
ـSocket.IO: این یکی برای پروژههای real-time شاهکاره. خیلی ابزارای متنوع داره و با Node.js هم عالی مچ میشه.
جمعبندی 🎯
ـDjango Channels میتونه برای پروژههای کوچیک و ساده مناسب باشه، ولی اگه بحث scale، پرفورمنس یا راحتی کار مطرح باشه، اصلاً گزینه خوبی نیست. من از پیچیدگیها و محدودیتهاش خسته شدم و به جای اون سراغ ابزارای دیگه رفتم.
نظر تو چیه؟ Django Channels تا حالا اذیتت کرده یا ازش خوشت میاد؟ بگو ببینم چی تو ذهنت میگذره🧐
#programming #web #django
➖➖➖➖➖➖➖➖➖
🔆 CHANNEL | GROUP
Forwarded from linuxtnt(linux tips and tricks) (hosein seilany https://seilany.ir/)
🔰نحوه مشاهده لاگها در لینوکس (dmesg, journalctl)
🔹در لینوکس، برای بررسی و عیبیابی مشکلات سیستم، از لاگها استفاده میشود. دو ابزار مهم برای این کار dmesg و journalctl هستند.
🔸نمایش لاگها به صورت زنده:
این دستور لاگها را به صورت زنده نمایش میدهد و هر تغییری که در لاگها ایجاد شود، بلافاصله نمایش داده میشود.
🔸نمایش لاگهای امروز:
این دستور فقط لاگهای مربوط به امروز را نمایش میدهد.
🔸نمایش فقط لاگهای با سطح خطا (err):
این دستور فقط لاگهایی که سطح آنها "خطا" (error) است را نمایش میدهد. -p err مخفف --priority=err است.
🔸نمایش لاگهای با سطوح خطا (err) و هشدار (warning):
این دستور لاگهایی با سطوح ۳ (err) و ۴ (warning) را نمایش میدهد. در اینجا ۳ و ۴ نشاندهنده سطوح اولویت لاگها هستند.
🔸نمایش لاگهای مربوط به یک سرویس خاص:
به جای <نام_سرویس> نام سرویس مورد نظر را قرار دهید. به عنوان مثال برای مشاهده لاگهای سرویس sshd از دستور زیر استفاده کنید:
dmesg - لاگ سیستم هسته (خواندن از /var/log/kern.log یا مستقیماً از هسته)
این دستور برای مشاهده پیامهای مربوط به هسته سیستم (kernel) استفاده میشود.
🔸نمایش خروجی به صورت صفحهبندی شده (با less):
این دستور خروجی dmesg را به صورت صفحهبندی شده نمایش میدهد و میتوانید با استفاده از کلیدهای بالا و پایین در آن حرکت کنید.
🔸نمایش خروجی با فرمت خوانا (timestamp):
این دستور زمان دقیق هر پیام را نیز نمایش میدهد.
🔸نمایش سطح (اولویت) پیامها:
این دستور اطلاعات بیشتری در مورد هر پیام، از جمله سطح اهمیت آن، نمایش میدهد.
🔸نمایش خروجی به صورت زنده:
این دستور پیامهای جدید هسته را به صورت زنده نمایش میدهد.
🔸ترکیب چند گزینه:
این دستور خروجی را به صورت صفحهبندی شده، با فرمت خوانا و با نمایش سطح پیامها نمایش میدهد.
📌نویسنده: حسین سیلانی
📌منبع : آکادمی کندوی دانش
https://learninghive.ir
🔹در لینوکس، برای بررسی و عیبیابی مشکلات سیستم، از لاگها استفاده میشود. دو ابزار مهم برای این کار dmesg و journalctl هستند.
🔸نمایش لاگها به صورت زنده:
journalctl -f
این دستور لاگها را به صورت زنده نمایش میدهد و هر تغییری که در لاگها ایجاد شود، بلافاصله نمایش داده میشود.
🔸نمایش لاگهای امروز:
journalctl -S today
این دستور فقط لاگهای مربوط به امروز را نمایش میدهد.
🔸نمایش فقط لاگهای با سطح خطا (err):
journalctl -S today -p err
این دستور فقط لاگهایی که سطح آنها "خطا" (error) است را نمایش میدهد. -p err مخفف --priority=err است.
🔸نمایش لاگهای با سطوح خطا (err) و هشدار (warning):
journalctl -S today -p 3..4
این دستور لاگهایی با سطوح ۳ (err) و ۴ (warning) را نمایش میدهد. در اینجا ۳ و ۴ نشاندهنده سطوح اولویت لاگها هستند.
🔸نمایش لاگهای مربوط به یک سرویس خاص:
journalctl -u <نام_سرویس>.service
به جای <نام_سرویس> نام سرویس مورد نظر را قرار دهید. به عنوان مثال برای مشاهده لاگهای سرویس sshd از دستور زیر استفاده کنید:
journalctl -u sshd.service
dmesg - لاگ سیستم هسته (خواندن از /var/log/kern.log یا مستقیماً از هسته)
این دستور برای مشاهده پیامهای مربوط به هسته سیستم (kernel) استفاده میشود.
🔸نمایش خروجی به صورت صفحهبندی شده (با less):
dmesg -H
این دستور خروجی dmesg را به صورت صفحهبندی شده نمایش میدهد و میتوانید با استفاده از کلیدهای بالا و پایین در آن حرکت کنید.
🔸نمایش خروجی با فرمت خوانا (timestamp):
dmesg -T
این دستور زمان دقیق هر پیام را نیز نمایش میدهد.
🔸نمایش سطح (اولویت) پیامها:
dmesg -x
این دستور اطلاعات بیشتری در مورد هر پیام، از جمله سطح اهمیت آن، نمایش میدهد.
🔸نمایش خروجی به صورت زنده:
dmesg -w
این دستور پیامهای جدید هسته را به صورت زنده نمایش میدهد.
🔸ترکیب چند گزینه:
dmesg -HTx
این دستور خروجی را به صورت صفحهبندی شده، با فرمت خوانا و با نمایش سطح پیامها نمایش میدهد.
📌نویسنده: حسین سیلانی
📌منبع : آکادمی کندوی دانش
https://learninghive.ir
Forwarded from DevTwitter | توییت برنامه نویسی
دو ماه پیش قالب ساده و مدرن پاندا برای وردپرس نوشتم که با استقبال مواجه شد. احتمالا این قالب برای انتشار جهانی در تم وردپرس منتشر خواهد شد و به صورت پیش فرض انگلیسی و مناسب برای وبلاگ است.
امکانات نظیر :
- منو بار
- دارک مد
- جستجو در سایت
- دکمه لایک
- ترجمه قالب
- برچسب ها
- پست های مرتبط
- دسته بندی ها
- اشتراک گذاری در فوتر
- لینک کوتاه پست
- تب بندی جدید و دیدگاه ها
- رسپانسیو شده
- کد نویسی اختصاصی
- و ...
https://github.com/Rayiumir/Panda
@DevTwitter | <Raymond Baghumian/>
امکانات نظیر :
- منو بار
- دارک مد
- جستجو در سایت
- دکمه لایک
- ترجمه قالب
- برچسب ها
- پست های مرتبط
- دسته بندی ها
- اشتراک گذاری در فوتر
- لینک کوتاه پست
- تب بندی جدید و دیدگاه ها
- رسپانسیو شده
- کد نویسی اختصاصی
- و ...
https://github.com/Rayiumir/Panda
@DevTwitter | <Raymond Baghumian/>
Forwarded from CleverDevs (Mammad)
بین top ها مختلف برای دیدن یا مدیریت پروسس ها neohtop از لحاظ قیافه یه سر و گردن از بقیه بالاتره و برای کاربرای ادایی خوبه
https://abdenasser.github.io/neohtop/
پ.ن البته مصرف خودشم همچین کم نیست
#tools #gnu #linux
@CleverDevs - @CleverDevsGp
https://abdenasser.github.io/neohtop/
پ.ن البته مصرف خودشم همچین کم نیست
#tools #gnu #linux
@CleverDevs - @CleverDevsGp
Forwarded from Anophel | آنوفل
یا شاید دلت بخواد یه بار فانکشنها رو آماده کنی و هر وقت خواستی دوباره اجراشون کنی؟
اینجاست که مفهوم Wrapper Types تو گولنگ میاد وسط. تو این پست، میخوام یه راه حل تمیز و شیک بهت معرفی کنم: ConcRunner
Wrapper Types چیه؟
فرض کن یه چیزی داری مثل اجرای فانکشنها به صورت همزمان (concurrently). خب، این کار خودش یه ذره پیچیدگی داره چون باید با goroutineها و sync.WaitGroup کلنجار بری. حالا ما اومدیم یه نوع جدید به اسم ConcRunner درست کردیم که این داستان رو میپیچه تو خودش. دولوپر فقط میگه «هی، این فانکشنهام رو بگیر و همزمان اجراشون کن»، دیگه نمیپرسه چطور این کار انجام میشه.
مثال تصویر 1
سادگی در استفاده: دیگه کسی لازم نیست نگران goroutine و sync.WaitGroup باشه.
قابلیت استفاده مجدد: فانکشنها رو هر چند بار که بخوای میتونی اضافه و اجرا کنی.
محافظت از جزئیات: کل سینک شدن و داستانهای پشت پرده رو میسپری به ConcRunner، تمیز و بیدردسر.
#گو #گولنگ #go #golang
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from a pessimistic researcher (Kc)
خیلی ها بیخیال نشدن. و خب به لطف بیخیال نشدن این عزیزان ما امروزه foundation مناسبی برای توسعهی تکنیکهای software model checking داریم. حالا اگر طبق عادتم دوباره نرفتم توی یک غیبت طولانی، براتون اولین تلاشها برای رفع این مشکل رو توضیح میدم و میبینیم که چطور با ارائه چند تکنیک ساده تونستن model checker ای بسازن به اسم SPIN که با گذشت بیش از ۳۰ سال هنوزم یکی از قویترین ابزارهای verification برنامههای distributed و multi-thread هستش.
مسئلهی Reachability با تمام سادگیش، مسئلهی Hard ای محسوب میشه و توی ترک B تئوری علوم کامپیوتر اگر نگم مهم ترین، ولی یکی از مهمترین مسائلی هست که پاسخ دادنش در هر setting ای ارزش بالایی داره.
به شکلی که ما یک کنفرانسی داریم به نام Reachability problems conference یا به اختصار RP که ۱۸ ساله داره برگزار میشه.
این کنفرانس برای ۱۹ امین سال قراره که توی سال ۲۰۲۵ در موسسهی IMDEA software واقع در شهر مادرید برگزار بشه و ددلاین ارسال مقالهاش هم ۶ ماهه دیگه. اگر شما هم این موضوع براتون جذابیت بالایی داره، give it a shot و سعی کنید یه چیزی برای این کنفرانس آماده کنید.
https://rp25.software.imdea.org/index.html
مسئلهی Reachability با تمام سادگیش، مسئلهی Hard ای محسوب میشه و توی ترک B تئوری علوم کامپیوتر اگر نگم مهم ترین، ولی یکی از مهمترین مسائلی هست که پاسخ دادنش در هر setting ای ارزش بالایی داره.
به شکلی که ما یک کنفرانسی داریم به نام Reachability problems conference یا به اختصار RP که ۱۸ ساله داره برگزار میشه.
این کنفرانس برای ۱۹ امین سال قراره که توی سال ۲۰۲۵ در موسسهی IMDEA software واقع در شهر مادرید برگزار بشه و ددلاین ارسال مقالهاش هم ۶ ماهه دیگه. اگر شما هم این موضوع براتون جذابیت بالایی داره، give it a shot و سعی کنید یه چیزی برای این کنفرانس آماده کنید.
https://rp25.software.imdea.org/index.html
rp25.software.imdea.org
RP 2025
19th International Conference on Reachability Problems 2025; October 1-3 2025, Madrid, Spain; Submission deadline: TBA
Forwarded from DevTwitter | توییت برنامه نویسی