omid_rhm

@flyingthegreat لذت بردم. ممنون

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

این حقیقت رو ملکهٔ ذهنتون کنید: موفقیت نتیجهٔ انجام سلسله کارهای پیش پا افتاده، خسته کننده و غیر مهیجه؛ منتظر اتفاق یک شبه نباشید. - دارن هاردی، کتاب: اثر مرکب

@CalmExile خیر. تعریف پست از نقش مادر با اونی که توی واقعیت هست، متفاوته، بسیار مادران امروزی که فرزندان رو رها میکنن ، چون مسیولیت پذیری رو دوست ندارن (تجربه شخصی)

تایید میکنید آقایون؟

@PythonPr This slice starts at index 1, stops before index 4, and uses a step of 2, selecting elements at positions 1 and 3 to output [2, 4].

Python Quiz: What is the Output?

The struggle is real🥲

This is AI 😂😂😂

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

@e_opore F

For Frontend Engineering, Which one are you? A. HTML -> CSS -> JavaScript -> Responsive Design -> AI APIs B. React -> TailwindCSS -> JavaScript -> Component Architecture -> AI Integration C. React -> TailwindCSS -> TypeScript -> State Management -> AI APIs D. Next.js -> TailwindCSS -> TypeScript -> SSR/SSG -> AI Integration E. Vue -> TailwindCSS -> TypeScript -> Progressive Web Apps -> AI APIs F. Angular -> TypeScript -> Enterprise Frontend -> AI Integration G. Frontend Architecture -> Performance Optimization -> Web Accessibility -> AI-Driven User Experiences

@ilyaskazi @IamAroke thanks for your sharing.👌👌👌👌

@IamAroke x.com/ilyaskazi/stat…

Interviewer: Differentiate between a webhook and an API?

System Design Tip: Design for Failure, Not Perfection In real-world systems, servers crash, APIs timeout, databases slow down, and traffic spikes unexpectedly. A good system design doesn’t assume everything will work perfectly. It prepares for failure using: • Load balancers to distribute traffic • Caching to reduce database load • Queues for heavy background tasks • Retries with backoff for temporary failures • Replicas and backups for data safety • Monitoring and alerts to catch issues early The goal isn’t to build a system that never fails. It’s to build one that fails gracefully and recovers fast.

هایپ MCP دیگه از بین رفته و کامیونیتی داره میره سمت استفاده از ابزارهای CLI و یکی از بزرگترین دلایلش مصرف توکن کمتر به واسطه کامندهایی مثل grep، jq، pipe، tail و... هست چون دیگه نیاز نیست کل متن یا فایل خونده بشه! ۱. کامند grep که برای جستجوی یه کلمه خاص تو متن استفاده میشه. وقتی agent این کامند رو ران میکنه، فقط لاین‌هایی رو میبینه که اون کلمه یا regex داخلشون هست! ۲. کامند jq: فیلتر کردن بر اساس یک فیلد یا ساختار schema از فایل json، مثلا این کامند فقط فیلد name رو از این json میکشه بیرون: cat data.json | jq '.name' ۳. کامند tail برای دیدن انتهای فایل خصوصا log ها زیاد استفاده میشه. به صورت پیش‌فرض ۱۰ تا خط آخر رو برمیگردونه ولی میشه با فلگ -n بهش عدد دلخواه داد: tail -n 50 app.log ۴. پایپ pipe() که باحال‌ترینشه، خروجی یک دستور رو مستقیم به ورودی دستور بعدی می‌فرسته که قابلیت chaining تا بی نهایت رو داره :) cat largefile.txt | grep "failed" اینا دستورات مهمی هست که تو محیط ترمینالی ایجنت‌ها زیاد ازش استفاده میکنن و بد نیست در موردش بدونیم!

@patilvishi What's your opinion about Db2, postgress, oracle, MongoDb, ...

Why do so many databases end with SQL? MySQL. PostgreSQL. Microsoft SQL Server. SQLite. Coincidence?

System Design fundamentals - Day 20 CAP Theorem: Why Distributed Systems Can't Have Everything Imagine your application is running on multiple servers across different cities. Suddenly... The network connection between the servers is interrupted. Now the system has a choice: Should it continue accepting requests? Or should it reject requests until everything is synchronized? This is exactly the problem the CAP Theorem addresses. What is CAP Theorem? CAP stands for: C - Consistency Every user sees the same data, regardless of which server they connect to. Example: Transfer ₹1000. Every server immediately shows the updated balance. A - Availability Every request receives a response. Even if one or more servers are unavailable. The response may not always contain the latest data. P - Partition Tolerance The system continues to operate even if communication between servers is interrupted. In distributed systems, network failures are inevitable. The Big Rule When a network partition happens... You can choose only one of these: ✔ Consistency OR ✔ Availability You cannot guarantee both simultaneously. Partition tolerance isn't optional in distributed systems—it's something you must assume will happen. CP Systems Choose: ✔ Consistency ✔ Partition Tolerance Example: Server A ✖ Network ✖ Server B If the servers can't communicate, some requests are rejected to keep data consistent. Used in - Banking - Payment systems - Inventory management Correctness is more important than always responding. AP Systems Choose: ✔ Availability ✔ Partition Tolerance Even if servers lose communication, they continue responding. Some users may temporarily see older data. Used in: - Social media - News feeds - Product catalogs Availability is more important than immediate consistency. Real-World Examples Banking Incorrect balances are unacceptable. Prefer CP. Instagram Likes Seeing 1,024 likes instead of 1,026 for a few seconds isn't a problem. Prefer AP. Shopping Cart Many systems choose a balance. The cart should stay available, while important operations like payment remain strongly consistent. Key Takeaway CAP Theorem doesn't say: "Pick any two." It says: When a network partition occurs, you must choose between Consistency and Availability. Every distributed system makes this trade-off. Tomorrow we'll explore: Strong Consistency vs Eventual Consistency

@patilvishi Thank you for sharing your knowledge, you reviewed the concepts very well.

System design fundamentals-Day 21 Strong Consistency vs Eventual Consistency Yesterday we learned about the CAP Theorem. Today lets answer the next question: What does "Consistency" actually mean? Not every application needs every user to see the latest data instantly. --- Strong Consistency Every user sees the latest data immediately. Example: You transfer ₹1000. The moment the transaction completes... Every ATM, mobile app, and bank server shows the updated balance. User A → ₹9,000 User B → ₹9,000 ATM → ₹9,000 Everyone sees the same value. Immediately. --- Best For - Banking - Payments - Inventory - Flight Booking Correctness matters more than speed. --- Eventual Consistency Updates don't appear everywhere instantly. Instead... All replicas become consistent after a short period of time. Write Data │ ▼ Primary Server │ ┌───┴────┐ ▼ ▼ Replica A Replica B A few seconds later... All replicas contain the same data. Temporary differences are acceptable. --- Best For - Instagram Likes - Facebook Posts - Product Reviews - News Feeds If your post shows 999 likes instead of 1000 for two seconds... Nobody notices. --- Real World Examples - Banking Balance must always be correct. Choose Strong Consistency. --- Instagram Likes and comments can synchronize later. Choose Eventual Consistency. --- Amazon Product reviews... Eventual consistency. Payment processing... Strong consistency. Different parts of the same application use different consistency models. --- Why Do Companies Choose Eventual Consistency? Because it improves: ✔ Availability ✔ Scalability ✔ Performance The trade-off is that users may briefly see older data. --- Key Takeaway Strong Consistency Everyone sees the latest data immediately. Eventual Consistency Everyone eventually sees the same data. The right choice depends on what your application values more: Correctness... Or scalability. Tomorrow we willl explore: Timeouts, Retries & Idempotency

@soha1031ka من نمیدونم، چه جوری پیام شما اومده توی تایملاین من، ولی اصلا نمیتونم باور کنم...خدا بهت صبر بده

یکی از همکارا واسم از شهرشون سوغاتی آورده بود بهم داد منم کلی تشکر کردم. بعد یه شب شام رفتیم بیرون،من کارت کشیدم، دنگش میشد ۱۲۰۰ و اون ۲۰۰تومن ریخت به کارتم! گفت سوغاتیه هم شده بود یه تومن  :))))))

@Hamzaonchain find /var searching recursively -type f Limits the search to regular files only -size +100M: files larger than 100MB -exec du -h {} + : For each found file, runs du -h: du shows the file's disk usage. Sort _rh Sorts the results. head -5 Displays only the first 5 lines

TEST YOUR LINUX KNOWLEDGE Which command sequence correctly finds all files larger than 100MB in /var, sorts them by size, and outputs only the top 5? A.find /var -type f -size +100M | sort -n | head -5 B.find /var -type f -size +100M -exec ls -lh {} \; | sort -k5 -h | tail -5 C.find /var -type f -size +100M -exec du -h {} + | sort -rh | head -5 D. ls -lh /var | grep 100M | sort -r | head -5

Vertical vs Horizontal Scaling: How Do Systems Handle Millions of Users? Your application is growing. More users are signing up. More API requests are coming in. Everything works... Until one day your server reaches 100% CPU. Now what? There are two ways to scale your system. Vertical Scaling (Scale Up) Vertical scaling means making one server more powerful. Example: 4 CPU → 16 CPU 8 GB RAM → 64 GB RAM You're upgrading the same machine. Advantages ✔ Simple to implement ✔ No application changes ✔ Good for small to medium systems Disadvantages ❌Hardware has limits ❌Expensive ❌Single point of failure ---- Horizontal Scaling (Scale Out) Instead of buying a bigger server... Add more servers. Server 1 Server 2 Server 3 Server 4 A Load Balancer distributes requests among them. Advantages ✔ Handles millions of users ✔ High availability ✔ Better fault tolerance ✔ Easy to grow gradually Disadvantages ❌More complex architecture ❌Requires load balancing ❌Distributed system challenges --- Real-World Examples - Startup Users │ Server Vertical scaling is usually enough. - Netflix Users │ Load Balancer │ ┌────|────┐ ▼ ▼ ▼ App1 App2 App3 Horizontal scaling is essential. --- What Happens If One Server Fails? Vertical Scaling Server ❌ Application Down Horizontal Scaling Server 1 ✅ Server 2 ❌ Server 3 ✅ Traffic automatically goes to healthy servers. Users often don't notice. ----- Can We Use Both? Absolutely. Many companies first upgrade a server (vertical scaling). When that's no longer enough, they start adding more servers (horizontal scaling). Modern cloud architectures use both. --- Key Takeaway - Vertical Scaling Make one server stronger. - Horizontal Scaling Add more servers. If you're building applications that need to serve millions of users, horizontal scaling becomes the foundation of modern system design. Tomorrow we will explore another pair of commonly confused concepts: Availability vs Reliability

@md_kasif_uddin Angular

If you could only use one framework, which would it be?

Software engineers: You've seen millions of UUIDs. But have you ever wondered why they all contain a 4 in exactly the same position? xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx what is the reason?

@khialafarin آرزوی آرامش برات دارم، ولی دنیا پاسخ هاش خیلی زمان بره