Can we stay in the magic forever? The magic lives in the night we loved each other so much and danced beneath the Mediterranean skies. Yes, the kiss, the stars, and you, everything seemed magical to me.
Thank you for being my magic.
Can we stay in the magic forever? The magic lives in the night we loved each other so much and danced beneath the Mediterranean skies. Yes, the kiss, the stars, and you, everything seemed magical to me.
Thank you for being my magic.
നക്ഷത്രങ്ങൾ നിങ്ങൾ
ഇരുട്ടിൽ ഞാൻ
വഴികാട്ടിയാലുമെന്നെ.
I’ll meet you
In the space between darkness and light,
where everything feels divine.
And there, I’ll kiss you
like the very first time,
even after a million times.
Below are the different types of states that can exist within an application. There are three main types:
Local state pertains to a single component. An example of this would be listening to user input in a field or toggling a “show more details” button. Typically, local state is managed within the component using useState or useReducer.
Cross-component state impacts multiple components. For instance, managing the open/closed state of a modal overlay. While this can also be managed using useState or useReducer, it often involves passing state between components via props drilling.
App-wide state influences the entire application, such as themes or user authentication status. Similar to cross-component state, this can be managed using useState or useReducer, albeit with the assistance of props drilling.
The LISTAGG analytic function, introduced in Oracle 11g Release 2, greatly simplifies string aggregations within SQL queries.
SELECT pid, LISTAGG(ColumnName, ' ' ) WITHIN GROUP (ORDER BY seq) AS ColumnName
FROM B GROUP BY pid;
However, if the output of the above query exceeds 4000 characters, it triggers an error, specifically ORA-01489, indicating that the result of string concatenation is too long.
To address this limitation, Oracle Database Release 2 (12.2) enhanced LISTAGG with the ability to handle overflow errors gracefully, as demonstrated below:
SELECT pid, LISTAGG(ColumnName, ' ' ON OVERFLOW TRUNCATE ) WITHIN GROUP (ORDER BY seq) AS ColumnName
FROM B GROUP BY pid;
In this updated syntax, the output is restricted to 4000 characters, preventing the ORA-01489 error from being raised.
The ON OVERFLOW clause offers several options to manage overflow situations:
ON OVERFLOW ERROR: This is the default behavior, triggering an error if the result overflows.ON OVERFLOW TRUNCATE 'StringYouLike': Appends ‘StringYouLike(Count)’ at the end of the truncated string.ON OVERFLOW TRUNCATE '': Displays the first 4000 characters without any additional terminating string.ON OVERFLOW TRUNCATE WITH COUNT: Appends the total character count at the end, for example, ‘…(5512)’.I’ve always believed in magic,
and I felt it the first time I saw you.
Baby, I am in love with the
sparks inside you.
Can I call it hope?
Maybe it’s you, or myself.
I’m not sure
maybe it’s both of us.
But I know it’s the
angel we dreamed of
for centuries.
Can we call it hope?
Session and token authentication methods are used by the server to verify the client request is authenticated or not.
Session-based authentication is an example of stateful authentication, which involves storing user authentication data on the server. With this method, when a user logs into a website, the server creates a small file that stores user information such as a unique session ID, login time, expiration time, and other relevant data. This file is stored in the database or in-memory cache. This session ID is then sent back to the client and stored in the client’s browser as a cookie. For subsequent requests, this cookie is passed back to the server. This allows the server to verify the session ID and provide a response based on the current state.
This method is easy to use, as cookies are natively supported by browsers, so no additional JavaScript is needed. But when the application grows decoupling the frontend from the backend becomes essential. Session-based authentication can be limiting in this regard.
Instead of relying on server-side sessions, token-based authentication uses tokens and it is an example of stateless authentication. When user log in, the server create a token (usually a JSON Web Token, or JWT) using a secret key and sent to the user. For subsequent requests, user will send this token along with request and server will verify if the token is valid or not.
This method gives more scalability and stateless for the apps, but the server does not authenticate the user, so linking a token to its user can be more difficult. Also in any chance an attacker got acess to the token, they will get access to the server.
In software development, a canary release (or canary deployment) refers to the practice of rolling out a new version of software to a small, select group of users before deploying it to the entire user base. The term “canary” comes from the old practice of using canaries in coal mines to detect dangerous gases; if the canary showed signs of distress, miners knew to evacuate. Similarly, in software, the canary release acts as an early warning system to detect issues with new code before it reaches a wider audience.
Benefits of Canary Releases: Reduced Risk: Limits the impact of potential issues by exposing the new version to only a small group first. Real-World Testing: Provides the opportunity to observe how the new version performs in a live environment. Faster Rollback: Easier to revert changes if problems are detected, reducing downtime or negative user impact.