Software General Questiosn Flashcards
What does the OS?
At the most superficial level, an operating system does two things:
- It manages the hardware and software resources of the system. These resources include processors, memory, disk space, and more in computers, tablets, and smartphones.
- It provides a stable, consistent way for applications to deal with the hardware without knowing all the hardware details.
How the Internet works and how to access a site?
Basicamente Internet seria la tuberia y el “World Wide Web” seria el agua que pasa por esa tuberia.
Se intenta acceder a un documento (pagina web) desde un determinado punto. entonces tenemos el punto A (tu computadora/celular) desde donde queres acceder al documento, y el punto B todavia no lo conocemos.
Para conocer el punto B, necesitamos la URL. Con la URL y el protocolo HTTP, al poner la URL en el browser, esta URL va a un DNS resolver.
“… For most users, their DNS resolver is provided by their Internet Service Provider (ISP), or they are using an open source alternative such as Google DNS (8.8.8.8) or OpenDNS (208.67.222.222). This can be viewed or changed in your network or router settings. At this point, the resolver goes through a process called recursion to convert the domain name into an IP address… “
Una vez que el DNS resolver/server tiene la IP, la devuelve al browser (Application), que inicia la conexion TCP para empezar a cargar la pagina.
https://www.catchpoint.com/blog/domain-name-to-ip-address
what is the advantage of HTTPS (SSL) vs just TCP?
Secure - When using HTTPS, data across the network is completely secure using industry-standard SSL encryption. Firewall friendly - Most companies allow HTTP(S) traffic through their company firewall.
webSocket vs Server Sent Event (advantages, disadvantages, use cases)
WEB SOCKET
Advantages
- Send binary data (more performant)
- bi-directional data between client and server (for more complex systems)
Disadvantages
- Just use HTTP for the first request, then just TCP (less secure)
- More complex to configure
- Vulnerable to cross site (webSocket) Hijacking
Use cases
- real time poling, chats, media players, multiplayer games
SSE
Advantages
- Easier to implement
- Run over HTTP
Disadvantages
- Mono directional
- Can’t send binary data
- maximum number of open connections restriction
Use Cases
- push notifications, state update, social media news feed
Explain the N+1 problem
The N+1 software problem refers to a situation where a program makes repeated database queries, resulting in excessive and inefficient database requests. This can occur when the program (ORM) retrieves a set of data and then makes an additional query for each item in that set, leading to unnecessary overhead and slower performance.
Let’s break it down in more detail:
N represents the number of initial queries: When a program needs to fetch a set of data from a database, it typically starts with one query to retrieve the main data set. This could be a list of products, users, or any other relevant information.
+1 refers to the additional query: After retrieving the initial data set, the program may need to gather additional details or related data for each item in the set. Instead of fetching all the necessary information in one go, it ends up making an extra query for each item, resulting in N+1 queries.
Impact on performance: Making multiple queries can significantly impact the performance and efficiency of the program. Each additional query incurs network overhead, database processing time, and potentially slower response times. This can be especially problematic when dealing with large data sets or under heavy loads.
Potential solutions: One solution to the N+1 problem is called eager loading, where the program fetches all the necessary data in a single query using techniques like joins or data preloading. Another approach is lazy loading, where the program fetches the additional data only when it’s explicitly needed, reducing unnecessary queries.
PUT vs PATCH?
PUT is Idempotent and PATCH is not.
PUT is considered idempotent. When you PUT a resource, these two assumptions are in play:
- You are referring to an entity, not to a collection.
- The entity you are supplying is complete (the entire entity).
Let’s look at one of your examples.
{
“username”: “skwee357”, “email”:
“skwee357@domain.example”
}
If you POST this document to /users, as you suggest, then you might get back an entity such as
/users/1
{
“username”: “skwee357”,
“email”: “skwee357@domain.example”
}
If you want to modify this entity later, you choose between PUT and PATCH. A PUT might look like this:
PUT /users/1
{
“username”: “skwee357”,
“email”: “skwee357@gmail.com” // new email address
}
You can accomplish the same using PATCH. That might look like this:
PATCH /users/1
{
“email”: “skwee357@gmail.com” // new email address
}
You’ll notice a difference right away between these two. The PUT included all of the parameters on this user, but PATCH only included the one that was being modified (email).
When using PUT, it is assumed that you are sending the complete entity, and that the complete entity replaces any existing entity at that URI. In the above example, the PUT and PATCH accomplish the same goal: they both change this user’s email address. But PUT handles it by replacing the entire entity, while PATCH only updates the fields that were supplied, leaving the others alone.
continuos integration vs continuos delivery vs continuos deployment
CONTINUOS INTEGRATION: the practice of automating the integration of
code changes from multiple contributors into a single software project.
CONTINUOS DELIVERY: automates the deployment of a release to an environment for staging or testing.
CONTINUOS DEPLOYMENT: software practice in which all the new code that passes the tests in the pipelines will be released WITHOUT the approval of any developer. It automatically deploys every release through your pipeline (including testing) and to production.
While they are different, continuous deployment is an extension of the continuous delivery concept
*Cada uno va extendiendo al anterior
Explain a good flow of CI/CD
BUILD => Testing Env => Prod Env (1 box) => Prod Env
BUILD
- Require X reviewers
- Run Unit tests
- Enforce code coverage (+80%)
- Review eslint
Test Env
- Run Integration Tests (E2E most important functionalities)
Prod Env (1 box / Canary Release)
- 10% of traffic
- Alarms of Business metrics, Errors and Performance
- Canary (cron job that runs every X amount of time, to test a functionality, like an API, setting the input and checking the output)
Prod Env
- Finish test with 90% of traffic
- Same as “Prod Env (1 box)”
THINGS TO TAKE INTO ACCOUNT
- Devs should have their own Cloud account with their things
- Different AWS accounts for Dev, stagging and Prod
- INTERNATIONAL DEPLOYS: If I have servers for different parts of the world, I could deploy it in parallel or sync in every step (be careful with parallel because it could have some problems).
- EXTRA ENV: Depending on the size of your system, maybe you would want to have an extra environment between Testing and Prod (for just QA)
- BLUE GREEN DEPLOYMENTS: For prod, it is a technique where you have kind of a Proxy as a “Router” that point to the Green deployment (the old one) or to the Blue one (the new one). So if the new one (blue) fail, you can just re router to the green one super fast!
TUTORIAL:
AWS CI CD: https://www.youtube.com/watch?v=EVDw0sdxaec&ab_channel=BeABetterDev
Explain how a Dictionary works
Hash table. Use the key of the dictionary, pass it to a Hash table that converts the key to the index of the “array”. That is why the time complexity is O(1)
PROs vs CONs of Serverless architecture
PROS:
Scalability: Serverless platforms automatically handle the scaling of resources based on the workload. This means your application can easily accommodate varying levels of traffic without manual intervention.
Cost-Efficiency: With serverless, you only pay for the compute resources you actually use, typically measured in terms of execution time. This can lead to cost savings, especially for applications with variable workloads.
Simplified Development: Serverless allows developers to focus on writing code and building features without the need to manage servers or infrastructure. This can lead to faster development cycles and reduced operational overhead.
High Availability: Serverless platforms are designed to be highly available by default. Cloud providers replicate functions across multiple data centers, ensuring that your application remains accessible even in the event of hardware failures.
Easy Integration: Serverless platforms often have built-in integrations with various services, databases, and event sources, making it easier to connect and extend your application.
Rapid Deployment: Serverless applications can be deployed quickly, allowing for rapid iteration and updates. This is particularly beneficial for continuous integration and continuous delivery (CI/CD) workflows.
CONS:
Cold Starts: Serverless functions may experience a delay (cold start) when they are invoked for the first time or after a period of inactivity. This can impact the responsiveness of your application.
Vendor Lock-In: Adopting serverless architecture can tie your application to a specific cloud provider’s ecosystem, making it challenging to migrate to another platform in the future.
Limited Control: Serverless platforms abstract away much of the underlying infrastructure, which means you have less control over server configurations, network settings, and other low-level details.
Cost Uncertainty: While serverless can be cost-effective, it can also be challenging to predict costs accurately, especially as usage scales up. Unexpected spikes in traffic can lead to higher-than-expected bills.
State Management: Serverless functions are typically stateless, which means managing application state can be more complex and may require external services (e.g., databases or caches).
Security Concerns: Serverless applications may introduce security challenges, such as the need to secure function execution, manage authentication, and protect against common serverless-specific vulnerabilities.
The best things about functional programming
Immutable Data: In functional programming, data is typically immutable, meaning once a value is created, it cannot be changed. This eliminates many common bugs related to mutable states and simplifies reasoning about code.
Pure Functions: Functional programming encourages the use of pure functions, which have no side effects and return the same output for the same input. This predictability simplifies testing, debugging, and reasoning about code.
Modularity: Functional programming promotes the creation of small, reusable functions that can be easily composed to solve larger problems. This modular approach enhances code reusability and maintainability.
Referential Transparency: Referential transparency is a property of functional programs where a function’s output depends only on its inputs. This property simplifies reasoning about code and facilitates optimization.
High order function: A function can be used as a parameter of another function, and can be returned
