Postlar filtri




Windsurf logosini yangilabdi, free planda ham o'zgarishlar bor emish agar kimdir menga o'xshab pul to'lagisi kelmay turgan bo'lsa :)

https://analyticsindiamag.com/ai-news-updates/windsurf-upgrades-its-free-plan-with-brand-new-logo/




To‘g‘ri, bu ahmoqona savol, lekin siz aqlli javob bersangiz bo‘ladi:

SQL uchun qaysi ORM ishlatgan yaxshi (Node.js stackda)?

P.s. umumiy gaplar kerakmas, faqat "nozik" joylarini yozinglar :)


Everyone ignores me. Maybe I'm an ESLint warning🤔😢

P.s. Share yours in the comment, birga siqilamiz ))






Attention QA Engineers, Can You Spot the Differences?

1. Retesting vs. Regression Testing
- Retesting verifies that a fixed defect is resolved.
- Regression Testing ensures that unchanged features still work correctly.
- Retesting is manual, Regression Testing is mostly automated.

2. Priority vs. Severity
- Priority indicates how urgent the bug fix is.
- Severity measures the impact on the application.
- Priority is dynamic, Severity is static.

3. Static vs. Dynamic Testing
- Static Testing is review-based with no execution.
- Dynamic Testing is execution-based, running the program.

4. Verification vs. Validation
- Verification checks if we are building the product correctly.
- Validation checks if we are building the right product.
- Verification is review-based, Validation involves actual testing.

5. Functional vs. Non-Functional Testing
- Functional Testing tests what the system does (e.g., login, payments).
- Non-Functional Testing assesses how the system performs (e.g., speed, security).
- Functional testing is requirement-based, Non-functional testing is performance-based.

6. Positive vs. Negative Testing
- Positive Testing examines valid inputs to ensure expected behavior.
- Negative Testing evaluates invalid inputs to test error handling.
- Positive testing guarantees expected outputs, while Negative testing uncovers hidden defects.

Master these fundamental testing concepts to excel in your QA interviews!

©️ LinkedIn


Ehh Skypejon, qadring bilinadigan bo'ldi, sensiz nima qilamiz endi, mayli Teams ishlatarmiz Macrohard aytganidek😢




O'zi biror narsa yozish uchun Notepad zo'r ekan, mazza qilib yozaman, o'chib ham ketmaydi agar behosdan chiqib ketsam ham. Mayli bu qiziq emas umuman olganda :). Ba'zi paytlari o'tmishni eslab turaman: o'tgan yillar, xotiralar, insonlar, voqealar, sarguzashtlar, hayotiy darslar, yo'qotishlar, yutuqlar. Hammasini o'ziga yarasha xotiradamda qoldirgan izlari bor. Qandaydir sifatsiz kadrlar miyamda saqlanib qolgan, 3-4 sekundlik xira videolar xuddiki. Nastalgiya. Shular bo'lmasa o'zi kim bo'lib qolaman? Ahir meni men bo'lishimning butun boshli yo'li-ku bu! Nega undan kechishim kerak?! Nega uni yomon ko'rishim yoki unitishim kerak?! Nega balki uyalishim yoki har-har zamonda eslamasligim kerak?! Onda-sonda esimga tushib beehtiyor yuzimga kulgu keltiradigan shular-ku ahir! Ko'chada tasodifan eshitib qolib ta'sirlanib ketgan qo'shiqlarim bor-ku ularning ichida! Qo'limga qandaydir buyum olib, u bilan qachondir o'tmishda qandaydir voqea bo'lgani esimga tushib etim jimirlashi shular tufayli-ku! Ba'zi savollarga uzoq va chuqur o'ylanishdan so'ng javob berishimning sababchisi-ku bu xotiralar! O'ylashimcha inson uchun eng qadrli va shu bilan birga eng shaxsiy boyligi bu - xotiralari. Ularni hech qachon, aytaylik yoqotishga yoki, balki iloji bo'lganda, sotishga rozi bo'lmaymiz, hech qachon. Oldinroq Telegramdagi "Saved messages"im o'chib ketgandi. O'chib ketganini bilganimdagi emotsiyamni ta'riflab bersam ham buni baribir his qilolmaysiz toki sizga ham shu narsa sodir bo'lmaguncha, ilohim bunday bo'lmasin, dushmanimga ham ravo ko'rmayman buni. O'shanda juda yaxshi bilib olganman inson uchun xotiralar qanchalik muhim ekanligini. Bundan sal oldin boshqa bir o'zim haqimda post yozishni boshlagan kanalimni o'chirib tashladim va bu narsa qanchalik og'riqli bo'lishini yana bir bor his qildim. Umuman olganda 3-4 oylik o'zim haqimdagi fikrlarim unchalik qimmatli bo'lmasligi kerak deb o'ylagandim, ammo shuni o'zi ham kayfiyatimga birmuncha ta'sir qildi. Qiziq tarafi, bu ahmoqona qarorlarimdan xulosa chiqarmagan holda @scriptjs kanalini ham o'chirib tashlash haqida o'ylanib qoldim bugun. Bu huddi tomog'i og'riyotgan odamning muzqaymoq yeyishiga o'xshaydi. Nega o'zimni bunday jazolashim kerak? Men shunga loyiqmanmi? O'zi nima yetishmaydi menga? O'ylab o'ylab menimcha javobini topdim - uyqu. Yaxshi dam oling azizlar. Bugun Yakshanba. To'yib uxlang. Vaqtli uyg'onib qolsangiz yaqinlaringiz bilan vaqtingizni o'tkazing. Siz bunga loyiqsiz!




I still love you ...






SOLID was originally formulated with object-oriented programming in mind, and many of its principles—like the Open/Closed Principle or Liskov Substitution—rely on concepts such as inheritance and polymorphism that are central to OOP. In contrast, functional programming (FP) emphasizes pure functions, immutability, and the use of higher-order functions.

That said, some of the core ideas behind SOLID, like ensuring that a module or function has a single responsibility, can still be valuable in FP. However, many of the SOLID guidelines either don’t directly translate or become less relevant because FP naturally avoids some of the pitfalls that SOLID is meant to address in OOP. For example, FP’s avoidance of mutable state and side effects often sidesteps issues that arise from complex object hierarchies and tight coupling.

Below is a mapping of each SOLID principle to concepts or patterns in functional programming (FP). While FP doesn’t always need to follow the same guidelines as OOP, similar design concerns exist and can be addressed in FP’s own style.

1. Single Responsibility Principle (SRP)
OOP Context: Each class should have one and only one reason to change.

FP Analogy:
Pure Functions: In FP, you write small, pure functions that perform one clear task. Each function’s purpose is narrow and well-defined, which naturally aligns with SRP.
Modularity and Composition: Instead of bundling responsibilities into one object, FP encourages composing functions so that each function handles a single piece of the logic.

2. Open-Closed Principle (OCP)
OOP Context: Software entities should be open for extension but closed for modification.

FP Analogy:
Higher-Order Functions & Composition: Instead of extending classes, FP leverages higher-order functions and composition. You build new behavior by composing existing functions, thereby extending functionality without modifying the original functions.
Algebraic Data Types (ADTs): When working with ADTs and pattern matching, you can design your types in a way that minimizes the need for changes, though sometimes extending a sum type does require modifying pattern matches.

3. Liskov Substitution Principle (LSP)
OOP Context: Subtypes should be substitutable for their base types without altering the correctness of the program.

FP Analogy:
Parametric Polymorphism & Type Classes: FP relies on parametric polymorphism (e.g., generics) and type classes (or traits) to ensure that functions work uniformly over different types. This creates a contract similar to LSP—any type that satisfies the contract (the type class or interface) can be substituted without unexpected behavior.
Equational Reasoning: The emphasis on pure functions and referential transparency means you can replace one function with another that fulfills the same contract, knowing that the overall behavior remains consistent.

4. Interface Segregation Principle (ISP)
OOP Context: Clients should not be forced to depend on methods they do not use.

FP Analogy:
Granular, Composable Functions: FP naturally leads to creating small functions that do one thing well. Instead of a “fat” interface with many methods, you have a collection of fine-grained functions that can be composed as needed.
Specific Type Classes: When abstraction is necessary, FP often uses multiple small type classes (or traits in languages like Scala) that can be mixed in as needed, ensuring that only the relevant behavior is required.

5. Dependency Inversion Principle (DIP)
OOP Context: Depend on abstractions rather than concrete implementations.

FP Analogy:
First-Class Functions as Dependencies: In FP, functions are first-class citizens. You can pass behavior (functions) as parameters, which allows you to invert dependencies.
Reader Monad / Environment Passing: The Reader monad is a common FP pattern that allows you to pass an environment (dependencies) implicitly to functions. This is analogous to dependency injection in OOP, where the details of a dependency are abstracted away from the business logic.

#ashnaqa


#savol

SOLID prinsplari functional programming uchun ham aktualmi?

Comment go!


APIni testlashda Postman bilan random data yuborish kerak bo'lsa pre-request scriptlardan foydalansangiz bo'ladi, ishingizni ancha osonlashtiradi.

Aytaylik sizda POST /inventory endpoint bor, unga name yuborish kerak va u unique bo'lishi kerak. Quyidagi pre-request script bilan buni qila olamiz:
const randomName = `Inventory name ${Date.now()}`
pm.collectionVariables.set('randomName', randomName)

Va albatta collection ichida randomName degan variable ochishiz kerak bo'ladi. Uni request body'da quyidagicha ishlatib ketaverasiz:
{
"name": `randomName`
}

#recommend


27' 2K/4K curved monitor recommend qilinglar plz🙏👇


🚨 Automation Engineers Are Not Testers—And That’s a Problem 🚨

I see it all the time: teams hiring “QA Automation Engineers” who don’t actually test anything. They write code. They build frameworks. They automate whatever test cases they’re handed.

But here’s the problem—automation without real testing skills is just code that gives you a false sense of security.

I’ve worked with engineers who could build a perfect framework from scratch but had no clue how to design a meaningful test. Worse, they didn’t even question the test cases they were automating. They just blindly followed whatever was written, without improving or expanding them.

And the result?
❌ A bloated test suite that’s expensive to maintain but adds little value.
❌ Missed edge cases because “it wasn’t in the test case.”
❌ Tests that pass even when something is obviously broken—because they weren’t designed to truly validate behavior.

Good automation starts with good testing. That means:
✅ Knowing what’s worth automating (and what isn’t).
✅ Thinking like a tester first, not just a developer writing code.
✅ Reviewing and improving test cases, not just following them blindly.

If we forget the testing mindset, we’re just writing code that go through the motions without proving anything meaningful.

©️ LinkedIn

20 ta oxirgi post ko‘rsatilgan.