#Tips@sirmerdas_binary♥️

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

#DevExperience@sirmerdas_binary⚡️

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

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

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

#useful@sirmerdas_binary🔥

If you need to compress, mangle, beautify and ... your js files offline, you can use this package.


https://www.npmjs.com/package/uglify-js

#DevExperience@sirmerdas_binary⚡️

What challenges do you think exist in this part from a software perspective?

به نظرتون چه چالشی تو این بخش از لحاظ نرم افزاری وجودی داره؟

#DevExperience@sirmerdas_binary⚡️

The challenge here is calculating the total duration of songs in a playlist. The most straightforward solution that might come to mind is to loop through all the songs in the playlist, get their durations, and then sum them up. However, this is the worst possible approach. Why?

At first, this method might seem fine, but as your user base grows—for example, to 500 users—this approach quickly becomes inefficient. If every request involves calculating the total duration for a playlist with 100 songs, it will place a significant computational load on your system. This can result in high server resource consumption and even lead to system downtime.

What's the alternative?
A more efficient solution is to add a new column to your playlists table, named something like total_duration. You calculate this value just once when the playlist is created and store it. You can further optimize by caching this value in a high-performance tool like Redis.

When the playlist is updated (e.g., adding or removing songs), you simply recalculate the duration for that single change and update the column. This way, instead of recalculating for all 100 songs, you're only dealing with one song at a time.

Of course, this isn’t the actual architecture of Spotify, and at their scale, things are much more complex. But I thought this would be a fun challenge to share with you all.

P.S: This approach applies specifically to relational databases.

#DevExperience@sirmerdas_binary⚡️

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

اولش شاید همه چیز خوب و اوکی به نظر برسه، ولی وقتی که مثلا تعداد کاربرانت برسه به فقط پونصد نفر، اگه قرار باشه به ازای هر درخواست به پلی لیستی که فقط 100 تا آهنگ توش وجود داره این مجموع زمانی محاسبه شه، این رویکرد ناکارآمد میشه و کلی بار پردازشی رو سیستم اعمال میشه و حتی ممکنه سیستم down بشه.

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

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

#DevExperience@sirmerdas_binary⚡️

Variable shadowing

In computer programming, variable shadowing occurs when a variable declared within a certain scope (decision block, method, or inner class) has the same name as a variable declared in an outer scope. At the level of identifiers (names, rather than variables), this is known as name masking. This outer variable is said to be shadowed by the inner variable, while the inner identifier is said to mask the outer identifier. This can lead to confusion, as it may be unclear which variable subsequent uses of the shadowed variable name refer to, which depends on the name resolution rules of the language.
source: Wikipedia

#useful@sirmerdas_binary🔥
این ویدئو رو از آقا رضا ببینید و لذت ببرید

https://www.youtube.com/watch?v=HkmpTvR_Eeg

اگه میتونستم نحوه مرگم رو خودم انتخاب کنم، قطعا انتخاب میکردم که با آهنگ‌های پلی لیستم خفم کنن.
چطوری؟ نمیدونم🤷‍♂️

#DevExperience@sirmerdas_binary⚡️

با یه دوستی بحث بود سر اینکه چرا ایپی استاتیک برای مودم‌های خونگی پولین ولی ایپی‌ رندوم پولی نیست.

یه خانوم دل‌انگیز و دانا لطفا☺️😭

#DevExperience@sirmerdas_binary⚡️

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

که شکر خدا بعد 2 روز همین الان تموم شد😂

#lifeUpdate@sirmerdas_bianry✨

داکر اشکمو درآورده🐳

#DevExperience@sirmerdas_binary⚡️

به هیچ عنوان حتی اگر محبور بودید روی اوبونتو سرور داکر رو از snap نصب نکنید، از هر ابزار تحریم شکنی که میتونید استفاده کنید ولی سراغ snap نرید.
اصلا معلوم نیست چجوری نصب میکنه سطح دسترسی باگ داره، یوزر docker وجود نداره و ...
خلاصه سراغش ندارید.
(راستش مطمئن نیستم شایدم من بلد نبودم ولی خوب ارزش وقت تلف کردن نداشت🗿)