Using Github Copilot for coding? Nah ❌
Using Github Copilot for generating commit messages? Hell yeah✅🔥

❗️Business hours changed
No more خدمت به خلق الله⛔️

#DevExperience@sirmerdas_binary ⚡️

It’s important to understand that the Origin header is automatically set by the browser for security reasons🔒, and it cannot be overridden manually when making requests using methods like fetch or XMLHttpRequest.

So basically, from now on, everything I find out or learn from experience will be posted with the hashtag #DevExperience@sirmerdas_binary⚡️

I’m just giving you more control over what content you want to see.❤️‍🔥

#useful@sirmerdas_binary🔥

Wanna dockerize pure php apps? Checkout this repo:
https://github.com/laradock/laradock

#DevExperience@sirmerdas_binary⚡️

‼️Please please Avoid Over-Engineering in the Early Stages of Your Project

When starting a new programming project, it’s easy to fall into the trap of over-engineering. Enthusiasm and a desire to “do it right” can lead to unnecessary complexity, ultimately slowing down progress and wasting resources. Here are some key points to consider to avoid over-engineering when your project is just beginning:

1️⃣Monolithic Architecture Over Microservices

Microservices are all the rage these days, but they are not a silver bullet. While they offer scalability and modularity, they also introduce significant complexity—inter-service communication, deployment pipelines, monitoring, and debugging become exponentially harder.

For a new project, a monolithic architecture is often a better choice.

2️⃣Focus on a Few Technologies

It’s tempting to adopt a multitude of technologies and libraries—one for authentication, another for state management, and yet another for caching or API handling. But adding too many tools can:

• Increase the learning curve for your team.
• Lead to compatibility issues.
• Make maintenance more challenging.

Instead, focus on mastering a minimal tech stack that fulfills your immediate needs. For example:

• Use one database (like PostgreSQL or MySQL) instead of adding NoSQL too early.
• Stick to a simple framework (like Laravel or Express.js) instead of experimenting with exotic combinations.

3️⃣Iterate and Evolve

At the beginning, your primary focus should be delivering value. Build a Minimum Viable Product (MVP), gather user feedback, and then iterate. Over-engineering slows down this process and makes pivoting harder when you realize some of your initial assumptions were wrong.

4️⃣The KISS Principle

As the saying goes, “Keep It Simple, Stupid.” Simplicity doesn’t mean cutting corners—it means building systems that are easy to understand, maintain, and extend.


Over-engineering at the beginning of a project is a recipe for burnout and failure. By opting for a monolithic architecture and limiting the technologies you use, you can maintain focus, deliver faster, and adapt as your project evolves.

#useful@sirmerdas_binary🔥

Although your telegram account is accessible via username like these
@username or https://news.1rj.ru/str/usersname

you can access it as t.me subdomain.

Like:
https://sirmerdas.t.me

#useful@sirmerdas_binary🔥

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

من خودم استفاده کردم راضی بودم.
https://console.hamravesh.com/sentry/create


‼️البته اگه سازمانتون بزرگه و به نظرتون میصرفه میتونید رو سرور شخصی هم بالا بیارید⚡️

#DevExperience@sirmerdas_binary⚡️

In one of my recent tasks, I was storing some JSON data in the user's browser LocalStorage, encoded in Base64. At first, everything seemed fine and logical, but as the size of the JSON grew, the issues started to surface.

As you might know, encoding data in Base64 increases its size by about 33%. Now imagine that this JSON data was already quite large. Every time I needed to read it, I had to base64_decode it, make the necessary changes, base64_encode it again, and then write it back to LocalStorage.

What was the result?
The page became extremely slow, with noticeable lags that completely ruined the user experience.

So, what was the solution?
I realized that encoding the data in Base64 was completely unnecessary! In the end, I stored the raw JSON directly in LocalStorage without any encoding🤩🤩🤩.

Sometimes, keeping things simple is the best solution! (KISS💋)

———
🦁
تو یکی از تسک‌های اخیرم، داشتم یه سری داده JSON رو به صورت Base64 انکود شده توی LocalStorage مرورگر کاربر ذخیره می‌کردم. اولش به نظرم همه چیز اوکی و منطقی بود، اما کم‌کم که حجم این JSON‌ها زیاد شد، مشکلات خودش رو نشون داد.

اگه اطلاع داشته باشید، وقتی داده‌ای رو به Base64 انکود می‌کنید، حجم داده تقریباً 33٪ بیشتر میشه. حالا تصور کنید این داده‌های JSON خودشون به اندازه کافی سنگین بودن و من نه‌تنها هر بار اون‌ها رو write می‌کردم، بلکه برای خوندن هم مجبور بودم base64_decode کنم، تغییرات اعمال کنم، دوباره base64_encode کنم و دوباره write کنم تو LocalStorage.

نتیجه چی شد؟
صفحه به شدت کند شد و لگ‌های شدیدی ایجاد شد که کل تجربه کاربری رو خراب می‌کرد.

اما راه‌حل چی بود؟
به این نتیجه رسیدم که اصلاً این کارِ انکود کردن کاملاً غیرمنطقیه! در نهایت، همون JSON خام رو بدون انکود کردن، مستقیم توی LocalStorage ذخیره کردم🤩🤩🤩.

گاهی ساده‌تر کردن کارها بهترین راه‌حله!(KISS💋)

#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