برای اولین بار توی این کانال:


ایده‌هاتونو بریزید وسط می‌خوام آپدیت ماژور بدم.

از هرچیز مفیدی استقبال میشه.


#موقت

🔶 بسیاری از مهندسان ارشد و مدیران از این می ‌ترسند که حقوق بالاتر، گزینه ‌های جابجایی شغلی را محدود کند. نظر من این است...

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

شرکت‌ها زمانی خوب پرداخت می‌کنند که باور داشته باشند شما می‌توانید تحولی ایجاد کنید.

به همین دلیل ساختن سابقه کاری قوی و ارائه نتایج ملموس بسیار مهم است. در سطوح بالاتر، تأثیر شما باید دقیق و شفاف باشد و مستقیماً با یکی از این موارد هم ‌راستا شود: صرفه‌جویی در درآمد، کاهش زمان، توسعه تیم یا ساخت سیستم‌ها.

اگر سابقه قوی نداشته باشید، احتمالاً در موقعیت فعلی گیر می‌کنید.

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

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

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

هرچه بالاتر می‌روید، باید روی نقاط قوت خود بیشتر سرمایه‌گذاری کنید تا تأثیرتان چندبرابر شود.

@TheRaymondDev

این سایته توش همه الگوریتم های مهمی که با C پیاده شدن رو جمع کرده توی کامنت های هر بخش توضیحات هر الگوریتم رو نوشته می‌تونید بخونیدش:

thealgorithms.github.io/C

@Linuxor

اگر احتمالا دنبال زیرنویس هستین و ترجمه به زبونی که میخواین وجود نداره میتونین از Workflow زیر تو n8n استفاده کنین :
https://gist.github.com/MrOplus/1436ec3c8d84e8a692e6e98f7807d4aa

@DevTwitter | </dev/nvram/>

مولانا | دیوان شمس | رباعیات | رباعی شمارهٔ ۴۲۵

مینال که آن ناله شنو همسایه است
مینال که بانک طفل مهر دایه است
هرچند که آن دایه جان خودرایه است
مینال که ناله عشق را سرمایه است

#مولانا | گنجور
📍@iipoem

خب این بنچمارک خیلی جالبی شد:)
برای اجرای 10هزار بار یک تابع wrangling
با Zero Copy تقریبا 50% حجم خط های کد افزایش داشت و عملکرد رو بدتر کرد
بهترین عملکرد رو Cython داشت و دردسر و over head کمتری نسبت به rust توی PyO3 داشت
انتخابم از این به بعد کد پایتون بهینست بدون اضافات :)

@DevTwitter | <Soroush Moosapour/>

هیچ ملتی تا ابد در زنجیر نمی‌ماند.

#NepoKids

🔍 ircf.space
@ircfspace

این GIL پایتون چقدر دردسر سازه 😬

فرض کن مسئول فنی توییتری، ساعت ۸ شبه و یه نفر با ۳۰ میلیون فالوور یه توییت میزنه، تو چند ثانیه، سیستم تو باید توییت رو ببره تو تایم لاین همه فالوراش
حالا سؤال اینه: چطوری سیستم شما باید با کمترین هزینه و بیشترین سرعت این توییت رو بزاره تو تایم لاین فالورا؟

این مشکلی بود که توییتر تو سال 2012 باید حلش میکرد اما راه حلشون چی بود؟
دوتا راهکار روبروشون بود
1- توییت یکبار تو دیتابیس ذخیره شه و هر بار کاربرا با باز کردن تایم لاین یه کوئری بزنن ببینن اونایی که فالو کردن چیا توییت کردن
2- تویتت به محض ارسال تو کش تایم لاین همه فالورا ذخیره بشه
اون اولا توییتر راه اول شماره 1 رو انتخاب کرد که این باعث میشه هر کاربر موقع باز کردن صفحه اول توییتر یک کوئری read بزنه (مثل عکس) که به مرور با افزایش تعداد خواننده ها که تقریبا دوبرابر نویسنده ها بودن بازدهیش اومد پایین!

پس توییتر اومد سویچ کرد رو حالت دوم که با زدن هر توییت میومد تو کش تایم لاین فالورا اون توییت رو اضافه میکرد اینطوری برا نوشتن یه توییت پردازش بیشتری میکرد اما این به سرعتش می ارزید اما خب همچنان یه مشکلی بود!

مشکل این بود ممکن بود یه نفر 30 میلیون فالور داشته باشه و خب نوشتن و قرار دادن اون توییت جدید برای 30 میلیون فالور پردازش و زمان زیادی میخواست و این باز سرعتو میورد پایین
راه حل جدید چی بود؟
ترکیبی از این دوتا روش!

به این صورت که برای اونا که فالورشون کم بود توییت هاشونو میزاشت تو کش تایم لاین فالوراشون و کنارش میومد برای افراد با فالور زیاد هم کوئری read میزد و بعد بر اساس زمان سورتش میکرد

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

📌 ixAbolfazl | @abolfazl_devs

در مورد اهمیت متن آگهی استخدامی برای استخدام افراد خفن!

خلاصه ماجرا اینه که افراد با استعداد اگر احساس کنن متن استخدامی با دقت نوشته نشده یا خیلی اغراق کرده اصلا متن رو نمیخونن چه برسه به این که وارد شرکت بشن.

https://news.ycombinator.com/item?id=3804134

یه پست بعدا راجبش میسازم که چرا دردسر سازه و چجوری میشه دورش زد :)

دلیل اینکه در زبان‌هایی مثل Go یا Rust یا حتی C دچار سردرگمی میشید، بخاطر این هست که میخواهید ساختارهایی که از زبان‌های شی‌گرا در ذهن دارید رو دقیقا به همون شکل در این‌ها هم داشته باشید. این زبان‌ها هم تا حدی این توهم رو ایجاد میکنند که اینکار شدنی هست؛ و میتوان گفت که همینطور است، ولی فقط در ظاهر!

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

مثلا اگر امروز به یک برنامه‌نویس Go یا Rust یک پروژه‌ی بانکی یا یک سیستم فروشگاه رو محول کنید، به احتمال زیاد این پروژه رو مبتنی بر DDD انجام خواهد داد! حتی یک برنامه‌نویس Clojure هم احتمالا همین رویه را دنبال خواهد کرد! الان احتمالا در ذهن شما این سوال پیش آمده که DDD؟ چطور همچین چیزی ممکن هست؟ مگه این برای شی گرایی نیست؟ خیر، «شما» اون رو با شی گرایی یاد گرفتید، ولی خودش یک ایده‌ی عمومی است.

شما به شکلی آموزش دیده‌اید که یونیت‌های کد را در قالب کلاس ها ببینید. و وقتی به زبان‌هایی میرسید که دارای کلاس نیستند، اولین چیزی که به فکرتان میرسد این است که کلاس را در آن‌ها شبیه سازی کنید. درست است؟

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

وقتی حرف از کلاس میشود، بیشتر افراد میکنند کلاس یک بلاک از کد است که تعدادی فیلد و متد را بین دو {} گرد هم آورده است.

اما کسی سوال نمیکند خب چرا اینکار را کردند؟ فقط چون میخواستند یک سری فیلد داشته باشند و یک سری تابع بتوانند روی ان‌ها کار کنند؟

خب این رو که از قدیم در همه زبان‌ها داشتیم. مگر اصلا جور دیگری میشود برنامه نویسی کرد؟ در تمام زبان‌ها یک سری دیتا داریم و یک سری تابع که روی آن دیتا کار میکنند. قدیمی ترین کد C ای که میتوانید پیدا کنید را باز کنید، احتمالا در آن یک استراکت پیدا میکنید به همراه تعدادی تابع که روی آن استراکت کار میکنند. این رویه قبل از شی گرایی هم وجود داشته... فقط چون این دو را کنار هم درون {} قرار میدهید اسمش میشود کلاس؟ یعنی فقط چون میخواستند کنار هم باشن؟ که تنها نباشن؟ غصه نخورن؟ فکر نمیکنید شاید دلایل مهمتری برای این موضوع وجود داشته؟

ویژگی‌هایی وجود دارد که باعث میشود کلاس، کلاس بشود:

۱. کلاس دارای مکانیزم وراثت است.
۲. کلاس پلی مورفیسم مبتنی بر وراثت را فراهم میکند (متدهای virtual)
۳. از روی کلاس، میتوان آبجکتی در حافظه تولید کرد.
۴. کلاس آبجکت‌ها را دسته بندی میکند (برای همین اسمش class است). یعنی باید بتوان جواب این سوال را جویا شد: ایا فلان آبجکت جزو فلان کلاس است؟
۵. آبجکت‌های ساخته شده از روی کلاس، دارای لایف تایم متفاوتی از سایر بلاک ها هستند. ابجکت‌ها حالت رفرنس دارند. به این معنی که تقریبا در تمام زبان‌ها، در هیپ قرار میگیرند.

اینکه دیتا و توابع را کنار هم و در یک بلاک به اسم کلاس جمع کردن‌اند، به خاطر این است که یک کانتکست یکپارچه پدید آورند که در قالب آن بتوانند همه‌ی ویژگی‌های بالا را برآورده کنند.

اینکه شما یک استراکت بسازید، و چند تابع تعریف کنید که روی آن استراکت کار کنند، کدام یک از ویژگی‌های بالا را شامل میشود؟ این دو بخش لزومی هم ندارد که جدا از هم باشند. مثلا در zig میتوانید توابع را عین یک کلاس درون همان بلاک مربوط به استراکت قرار دهید. ولی باز هم در صورت انجام اینکار، تبدیل به کلاس نمیشود چون هیچکدام از ویژگی‌های بالا را ندارد.

یا مثلا در C یا سایر زبان‌ها، فیلد‌ها و متدها را در ماژول‌ها گرد هم میاورند. ایا با اینکار آن ماژول تبدیل به کلاس شده است؟

اتفاقی که این وسط افتاده این است:
۱. شما در حین یادگیری شی گرایی بدرستی درک نکردید که کلاس چیست!
۲. بر مبنای آن درک اشتباه، فکر کردید شی گرایی یعنی کنار هم قرار دادن فیلدها و متدها در یک بلاک.
۳. اصرار به این دارید که این درک اشتباه را در زبان‌هایی که اصلا دارای کلاس نیستند پیاده سازی کنید.

این همان جایی است که در زبان‌هایی مانند Go و Rust و Zig و C سایرین به مشکل بر میخورید. برای همین هست که میگویند این‌ها را با زبان‌های شی گرا اشتباه نگیرید. چون این‌ها از نظر ظاهری، شاید شرایطی را فراهم کنند که به چشم شما مشابه چیزی باشد که در شی گرایی به یاد داشتید، ولی از نظر Semantics با زبان‌های شی گرا متفاوت اند.

@DevTwitter | <Amirreza Gh/>

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

نصب‌ و توضیحات :
typeof.net/Iosevka

@Linuxor

دلیل اینکه در زبان‌هایی مثل Go یا Rust یا حتی C دچار سردرگمی میشید، بخاطر این هست که میخواهید ساختارهایی که از زبان‌های شی‌گرا در ذهن دارید رو دقیقا به همون شکل در این‌ها هم داشته باشید. این زبان‌ها هم تا حدی این توهم رو ایجاد میکنند که اینکار شدنی هست؛ و میتوان گفت که همینطور است، ولی فقط در ظاهر!

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

مثلا اگر امروز به یک برنامه‌نویس Go یا Rust یک پروژه‌ی بانکی یا یک سیستم فروشگاه رو محول کنید، به احتمال زیاد این پروژه رو مبتنی بر DDD انجام خواهد داد! حتی یک برنامه‌نویس Clojure هم احتمالا همین رویه را دنبال خواهد کرد! الان احتمالا در ذهن شما این سوال پیش آمده که DDD؟ چطور همچین چیزی ممکن هست؟ مگه این برای شی گرایی نیست؟ خیر، «شما» اون رو با شی گرایی یاد گرفتید، ولی خودش یک ایده‌ی عمومی است.

شما به شکلی آموزش دیده‌اید که یونیت‌های کد را در قالب کلاس ها ببینید. و وقتی به زبان‌هایی میرسید که دارای کلاس نیستند، اولین چیزی که به فکرتان میرسد این است که کلاس را در آن‌ها شبیه سازی کنید. درست است؟

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

وقتی حرف از کلاس میشود، بیشتر افراد میکنند کلاس یک بلاک از کد است که تعدادی فیلد و متد را بین دو {} گرد هم آورده است.

اما کسی سوال نمیکند خب چرا اینکار را کردند؟ فقط چون میخواستند یک سری فیلد داشته باشند و یک سری تابع بتوانند روی ان‌ها کار کنند؟

خب این رو که از قدیم در همه زبان‌ها داشتیم. مگر اصلا جور دیگری میشود برنامه نویسی کرد؟ در تمام زبان‌ها یک سری دیتا داریم و یک سری تابع که روی آن دیتا کار میکنند. قدیمی ترین کد C ای که میتوانید پیدا کنید را باز کنید، احتمالا در آن یک استراکت پیدا میکنید به همراه تعدادی تابع که روی آن استراکت کار میکنند. این رویه قبل از شی گرایی هم وجود داشته... فقط چون این دو را کنار هم درون {} قرار میدهید اسمش میشود کلاس؟ یعنی فقط چون میخواستند کنار هم باشن؟ که تنها نباشن؟ غصه نخورن؟ فکر نمیکنید شاید دلایل مهمتری برای این موضوع وجود داشته؟

ویژگی‌هایی وجود دارد که باعث میشود کلاس، کلاس بشود:

۱. کلاس دارای مکانیزم وراثت است.
۲. کلاس پلی مورفیسم مبتنی بر وراثت را فراهم میکند (متدهای virtual)
۳. از روی کلاس، میتوان آبجکتی در حافظه تولید کرد.
۴. کلاس آبجکت‌ها را دسته بندی میکند (برای همین اسمش class است). یعنی باید بتوان جواب این سوال را جویا شد: ایا فلان آبجکت جزو فلان کلاس است؟
۵. آبجکت‌های ساخته شده از روی کلاس، دارای لایف تایم متفاوتی از سایر بلاک ها هستند. ابجکت‌ها حالت رفرنس دارند. به این معنی که تقریبا در تمام زبان‌ها، در هیپ قرار میگیرند.

اینکه دیتا و توابع را کنار هم و در یک بلاک به اسم کلاس جمع کردن‌اند، به خاطر این است که یک کانتکست یکپارچه پدید آورند که در قالب آن بتوانند همه‌ی ویژگی‌های بالا را برآورده کنند.

اینکه شما یک استراکت بسازید، و چند تابع تعریف کنید که روی آن استراکت کار کنند، کدام یک از ویژگی‌های بالا را شامل میشود؟ این دو بخش لزومی هم ندارد که جدا از هم باشند. مثلا در zig میتوانید توابع را عین یک کلاس درون همان بلاک مربوط به استراکت قرار دهید. ولی باز هم در صورت انجام اینکار، تبدیل به کلاس نمیشود چون هیچکدام از ویژگی‌های بالا را ندارد.

یا مثلا در C یا سایر زبان‌ها، فیلد‌ها و متدها را در ماژول‌ها گرد هم میاورند. ایا با اینکار آن ماژول تبدیل به کلاس شده است؟

اتفاقی که این وسط افتاده این است:
۱. شما در حین یادگیری شی گرایی بدرستی درک نکردید که کلاس چیست!
۲. بر مبنای آن درک اشتباه، فکر کردید شی گرایی یعنی کنار هم قرار دادن فیلدها و متدها در یک بلاک.
۳. اصرار به این دارید که این درک اشتباه را در زبان‌هایی که اصلا دارای کلاس نیستند پیاده سازی کنید.

این همان جایی است که در زبان‌هایی مانند Go و Rust و Zig  و C سایرین به مشکل بر میخورید. برای همین هست که میگویند این‌ها را با زبان‌های شی گرا اشتباه نگیرید. چون این‌ها از نظر ظاهری، شاید شرایطی را فراهم کنند که به چشم شما مشابه چیزی باشد که در شی گرایی به یاد داشتید، ولی از نظر Semantics با زبان‌های شی گرا متفاوت اند.

| <Amirreza Gh/>

اگه تازه می‌خوای بیای سمت ‌Vue این وبسایت خیلی کارتو جلو می‌ندازه یه مجموعه از ابزارها (utilities) برای Vue 3 هست که به‌صورت Composable طراحی شدن.

vueuse.org

@Linuxor

می‌خوای بدون دردسر SPA (SPA وبسایت تک صفحه ای هستش که با کلیک روی بخش هاش محتواش رفرش می‌شه بجای باز شدن صفحه جدید) بسازی ولی نمی‌خوای React یا Vue اضافه کنی؟ jquery-pjax یه گزینه سبک و سرراسته‌ست که با jQuery کار می‌کنه و نیاز به تغییر ساختار بزرگ نداره. تنها کاری که می‌کنی لینک‌ها و container صفحه رو مشخص می‌کنی.
github.com/defunkt/jquery-pjax

@Linuxor

بزرگترین حمله‌ی supply-chain تاریخ دیروز اتفاق افتاد.
با یه ایمیل فیشینگ ساده به حساب‌های اصلی دسترسی گرفتند و نسخه‌های آلوده منتشر شد.

تو متن نوشته اگه احراز هویتت رو آپدیت نکنی حسابت لاک میشه و تمام، تارگت کلیک کرد.

باید به همه چیز شک داشت مگه اینکه خلافش ثابت بشه.

@DevTwitter | <Sabber/>

🎧 اپیزود ۶، فصل دوم | امیرحسین پناهی‌فر

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

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

🔄 توی پروژه پایان‌نامه‌اش «مدل‌سازی جوامع احساسی» رو بررسی کرد و علاقه‌اش به هوش مصنوعی و سیستم‌های شبکه‌محور عمیق‌تر شد.

🌱 از روزهای کرونا گفت، از ورژن‌های مختلف خودش و اینکه چطور اصالت درونیش رو حفظ کرده و بذری از خودش رو توی دل آدم‌ها می‌کاره.

🏔️برای امیرحسین، علم یک مسیر جمعیه؛ چیزی فراتر از رقابت. باور داره که ما ادامه‌دهنده‌ی راه کسانی هستیم که قبل از ما چراغ علم را روشن نگه داشتن. هرکس پله‌ای به این مسیر اضافه می‌کنه، و در نهایت با هم آینده رو می‌سازیم.

⚔️«گلادیاتور زندگی» خودشه، که ارزش لحظه‌های زود گذر رو به خوبی درک ‌کرده.

🧱 پیام آخرش برای ساینس فکتوری: «آیین چراغ خاموشی نیست؛ وقتی شروع کردی، ادامه بده تا ته راه.»

🔗 کست باکس

🔗 اسپاتیفای

@sciencenfactory

یه ویدیو از CNCF هست که خیلی خوب توضیح می‌ده چطور دیتابیس هاتون رو با Vitess گسترش بدید و scale کنید

@Linuxor

گاهی در API یا فرم‌ها نیاز داری مطمئن بشی یک آرایه ورودی دقیقا شامل کلیدهایی باشه که انتظار داری. از لاراول 10.9 به بعد میتونی بهراحتی با rule جدید required_array_keys این کارو انجام بدی.

📌 مثال:

فرض کن ورودیه API به این شکل میاد:

{
  "user": {
    "name": "Ali",
    "email": "[email protected]"
  }
}

برای اینکه مطمئن بشیم حتما کلیدهای name و email داخل user وجود دارن، کافیه اینطوری بنویسیم:

$request->validate([
    'user' => ['required', 'array', 'required_array_keys:name,email'],
]);

حالا اگه یکی از این کلیدها در ورودی نبود، لاراول خطا میده.

این روش خیلی تمیزتر و کوتاه‌تر از نوشتن چندین rule برای هر فیلده و مخصوصا در API ها بسیار کاربردیه.
#Laravel  #لاراول

@GoldenCodeir
(به منبع و مثالش دقت کنید 👇🏾)
https://x.com/PovilasKorop/status/1964988360193155402?s=35