Singleis in the Cryptocurrencies Industry

Single

100 Complex Cryptocurrency Terminologies Explained in a Single Sentence

100 Complex LLM Terminology Explained in One Single & One Simple Sentence

The Single Responsibility Principle (SRP) is one of the five SOLID principles of code design. It states that a unit of code should have only one reason to change. However, this principle is often misunderstood and misapplied, as we can see in too numerous 'big (or distributed) balls of mud' and 'spaghetti' code bases. In this article, we will explore what the SRP is and how to make following it practical and actually beneficial. First things first, why the SRP? Why should we care about it? The SRP helps write code that is easier to understand, maintain, and extend. Essentially, being able to follow the SRP is one of the key factors in writing clean code. The next thing is that the SRP can be applied not only to classes but also to methods and contracts in general. This means that the SRP is not just about classes but about any unit of code that can change. And by a 'contact' I mean a set of inputs, outputs, and behaviors that a unit of code is expected to provide. The main challenge in the SRP is exactly in defining the 'reason' to change, to outline the responsibilities - this is what the article will revolve around. The irony is that there is probably not a single developer who would not know about the SRP or would say that it is not important. However, in practice, we see high coupling, overcomplicated dependency graphs, the costs of changes and maintenance keep growing way too fast, and the code becomes a nightmare to work with - and all the while everyone knows about the SRP and even tries to follow it. How the SRP Is Often Introduced and Why It Does Not Really Help Normally, the description of the SRP starts with an example where a few different responsibilities are combined together, and then it goes by separating those responsibilities into different classes, and stating that this is it, this is the SRP. Yes, separating concerns may lead to a good and cleaner design, and it would be an example of the SRP, but it is just a limited application of it. Essentially, such examples show how to separate concerns, but not how to really apply the SRP. Once the concerns are separated, we still need to implement the functionality that uses them together in a single flow. So, the SRP is not about separating different concerns, it is about how to properly outline the responsibilities in the first place. And the definition of 'proper' comes from the definition of the SRP itself - 'a unit of code should have only one reason to change.' Let's take the of a class that compiles and prints a report, even though it is rather limited, but we can start with it. Clearly, building or compiling a report and printing or saving it into a representation are two different functionalities that are quite independent of each other. However, in the end, they form a single responsibility. Wikipedia example may Let's ask ourselves a question: is this software ever going to need a different way to compile or build a report? Or a different way to print it or save it into another representation form? Does it actually have such reasons to change? The answer to these questions comes from the business requirements - it is not about the code itself or not about the code itself. only So, the typical view on the Single Responsibility Principle is fine we balance it with proper bounds that will not lead us into a trap of over-engineering the code. It is very much like premature optimizations - just not in terms of performance or memory consumption but in terms of design and architecture. "If it is not broken, do not fix it. If it is not needed, do not add it." Do not write code or create designs that are not needed now and may never be needed. if It would be great to augment the canonical definition of the SRP - 'a unit of code should have only one reason to change' - with an understanding that the 'reasons to change' should be limited by the existing and potential, though still justified, requirements. What the piece of software that this unit of code is a part of is supposed to do, and what it is not supposed to do. Ok, all this sounds good but there may be a question: why not just separate concerns and be done with it? Even if this separation will never be required by our software, even if we will have only a single implementation of each of those concerns and probably just a single use for each of them - why not separate them? We can have a cleaner implementation, more in line with the SRP, 'clean code', etc. Again, if our software is small and simple, this separation will not actually hurt. The answer to this question is that such separation of concerns creates new abstractions, new interfaces, new classes, and new dependencies. More abstractions potentially mean higher coupling. And since we are normally dealing with large and complex software, this separation may lead to a combinatorial explosion of abstractions, and thus - higher coupling. So, it will help with making our code cleaner and easier to understand and maintain. What is often omitted when describing the SOLID principles, and the SRP in particular, is that everything comes at a cost, and we need to balance these costs in order to keep our code maintainable and understandable. not To make this statement clearer, just count how many new abstractions we have after we carelessly separated concerns, and how many new dependencies we would need to inject into our classes to make them work - the higher the numbers, the higher the coupling. Well, the next arising and rather justified question can be about the testability of such code, if we do not separate concerns. And yes, it can be very justified to separate concerns in order to make the code more testable, as this is often a part of our NFRs (non-functional requirements). But again, should we really introduce new abstractions and dependencies just to make our code more testable? Can it be tested just fine without introducing new abstractions? And the answer, surprisingly, can often be 'yes.' Following the Wikipedia example, we can still apply the SRP on the level of methods, without introducing additional abstractions, and such methods can be tested just fine. The SRP From the Point of View of Contracts The Single Responsibility Principle is a design principle, and the design often starts with contracts. We can describe the contracts in a rather wide form - as a set of inputs, outputs, and behaviors that a unit of code is expected to use and provide. This description should be good enough for the purpose of this article. Let's see how the SRP can be applied to contracts, and let's repeat its definition - 'a unit of code should have only one reason to change.' The contracts often have the most direct influence on when and why the code should change; if a contract changes, the code that implements or uses it should change as well. And while we strive to maintain the contracts stable, they connect the pieces of code together, and thus, are quite likely to change when the co-related requirements change. In other words, we do not control some of the 'reasons to change' even if the requirements for our own unit of code are stable. A contract can be described in terms of a 'dependency-consumer' relationship: another piece of code provides some behaviors used by our unit of code and those behaviors may create some data required by our unit of code. In turn, our unit of code gets consumed by other units of code. A method with its list of parameters and return values is an example of such a contract. In the same way, a class or interface provides a contract with its methods, and we can keep climbing the abstraction ladder, speaking about the contracts on the level of modules, services, APIs, and so on. When designing contracts for our code, we normally take into account this co-relation between the units of code, as it is quite clear that a contract we are designing should serve specific 'consumers' and will depend on other contracts. However, when looking at a contract from the point of view of the SRP, we should also consider that the 'reasons to change' for our contract are also influenced by those 'consumers' and 'dependencies', or if we look 'from inside out' - the behavior provided by our contract, and thus its output, influence the 'reasons to change' for the 'consumers' of our contract. If we deal with quite a stable code base where the requirements are not changing often, and our contract most likely is going to be stable, we just need to design it well with sufficient thoughtfulness regarding its consumers and dependencies. However, if we deal with a code base that is more fluid, where the requirements for our consumers and dependencies may change, we may want or will have to, either accept that our contract will keep changing as well, or design additional abstractions that will protect our contract from those changes. One such abstraction is a mapping layer that will convert the data from the representation produced by the dependencies into the representation that our contract expects, and the same way around for our consumers. In fact, this is a common practice in the design of APIs, bounded contexts, and other similar units of code. The main question is the cost - what is going to be less expensive, changing our contract and implementation when the dependencies change, thus invoking in turn potential change in our consumers, or introducing additional abstractions that will isolate our contract from those changes? In real-world scenarios, we often begin with what is faster to implement, and then, we see how it evolves. Ideally, our working process has enough space to address and solve the arising technical debt, and we can refactor our code when needed with the goal of keeping it maintainable at the lowest cost. And by the 'cost' I mean not only the time and effort needed to implement a particular change but also how costly it will be to maintain and extend the code in the future. Many of us know all too well that what costs very little to do right away may and will cost a lot in the future. So, a bit unexpectedly, the SRP got connected not only with immediate design decisions and long-term maintainability but also with the costs of maintaining the code and addressing the technical debt. Of course, the developers are not seers, but by applying the SRP properly for code design at the contract level, we can achieve better maintainability and lower future costs - both for the business and for the developers. The SRP and the Leaky Abstractions A leaky abstraction is an abstraction that leaks details of what it is supposed to abstract away. Wikipedia On the practical level, a leaky abstraction can be anything that exposes, directly or indirectly, how a unit of code works - something that the consuming code is not expected to know about or use. For example, the response object contains a public property that logically should not be there, as it exposes internal state or implementation detail that the consuming code should not be aware of. Another example is when a class method output should be additionally processed by another method of the same class in certain scenarios, which the consuming code does not control but is forced to check for. One more example is submitting a parameter that controls the input data processing while the parameter value could be deducted from the input itself or should come from another source that the consuming code does not own or use for any other purpose. Leaky abstractions are related to the Single Responsibility Principle because they introduce additional 'reasons to change' for a unit of code, even if only potentially. Leaky abstractions add to contract instability, both in terms of consumption and exposure. Let's look at leaky abstractions from the point of view of contract design, which we discussed in the previous part. A few good checkup questions to ask when designing a contract are: Does the contract really need a particular input parameter? Is the exposed behavior atomic and self-sufficient, or will the consumers have to invoke additional behaviors of our contract on a condition not determined by the consumer? Does the contract expose any internal, or even public, state that is not required by the consumers? Let's go over these checkpoints in more detail to see why they may be related to leaky abstractions and the SRP. Does the contract really need a particular input parameter? Why should we be concerned about an input parameter of a contract? Besides the obvious reason of not being used by the code, we should also consider if we can deduce this parameter from the input data itself without incurring additional costs or if the parameter is a part of the global application state, and thus, could be injected into the contract implementation at the dependency resolution stage. Well, normally we do need our parameters at the calling site, but we should be sure that it is within the responsibility of our consumers to provide them, and it is not the responsibility of our contract to obtain them. If these responsibilities are mixed up, we may have a leaky abstraction and we create an additional 'reason to change' either for our unit code or for its consumers. Is the exposed behavior atomic and self-sufficient? This may not affect our own unit of code 'reasons to change' directly, but it may affect the consumers of our contract, as this influences the contract stability. If the exposed contract behavior is not atomic, changes in its internal logic are more likely to affect the contract itself which will be a breaking change for the consumers. This would also be a violation of the SRP on the contract level as the contract should not change when only the internal behavior changes. While the contract still provides the same final result, it has changed because of internal reasons that should not be exposed to the consumers, and this is another example of leaky abstractions. Does the contract expose any internal or even public state that is not required by the consumers? As well as introducing the risk of potentially breaking changes for the consumers, exposing internal or not needed state may also lead to unexpected coupling or 'reasons to change'. Let's say the consumers of our contract came to rely on an unintentionally exposed state, and for some reason, it is impossible or too expensive now to update the consumers; while this state cannot or should not be maintained by our code because the requirements have changed, and the code should be updated. So, our code will be forced to maintain this state and implement an additional workaround to keep the consumers working - we now have an extra 'reason to change' for our code. Consuming Leaky Abstractions Of course, we should also be watchful when consuming leaky abstractions. Let's again take the Wikipedia example for the SRP regarding a class implementing a report persistence functionality. A report may be persisted into a local file, a database, or any other type of storage. Each of these methods of persistence has its own internal specifics that may leak out, and our code may mistakenly rely on them. For example, the local or remote file persistence may expose the file location that our code may want to use for some reason. When the application is expanded with a new persistence method, say, a database, our code will have to change - simply because it was built around a leaky abstraction. In a sense, leaky abstractions provide 'false contracts' that are not stable and may change at any time or simply be absent or different in other contract implementations, thus introducing additional 'reasons to change' for a unit of code and violating the SRP. Let's Summarize... Of course, all code is written in a context, and the context is the king, as it is defined by business requirements, NFRs, the current state of the code base, the current level of expertise of developers, the way the costs are balanced, and by many other factors. Nonetheless, it is possible to outline some points for additional considerations when creating designs or implementing code that would help to stay more in line with the Single Responsibility Principle within the context present at the moment. Outline the responsibilities within the units of code based on valid 'reasons to change' that are defined by the business and non-functional requirements, and not by the code itself. "If it is not broken, do not fix it. If it is not needed, do not add it." Before extracting or creating a new abstraction, consider if it is really needed - check the 'reasons to change' for already existing code and for the new abstraction. If they are not different, it may most likely be better to keep the code together. When driven by the code testability requirements, consider applying the SRP on the level of methods, not only on the level of abstractions. If the only reason for a new abstraction is to make the code more testable, try adjusting your testing approach first, and introduce new abstractions only when there is no other way. When designing contracts in a complex system, consider if the potentially required dependencies are stable enough to be used directly, or if it is better to introduce additional abstractions that will protect your code from the changes in those dependencies. The cost of adding and maintaining extra abstractions should be balanced with the cost of potentially breaking changes when the dependencies change. Check for leaky abstraction in your code and in the dependencies it needs. If you see that the abstractions are leaking, consider replacing them with more stable abstractions. The cost of relying on leaky abstractions, or better to say the risk, should be balanced with the cost of replacing them. As you see, sometimes, we should not add a new abstraction and sometimes we should - the context is the king, we just need to make sure it can rule happily for as long as possible and define the 'reasons to change' and the cost balancing are the keys in applying the SRP.

Making the Single Responsibility Principle Practical

**SAN FRANSCISCO, California, March 12th, 2024/Chainwire/--**DeFi trading platforms are starting to offer advanced utilities that are challenging conventional financial systems. These emerging platforms feature cutting-edge technology and offer decentralised alternatives to legacy systems. Especially in the context of asset trading, users can leverage the potential of blockchain technology to have access to unparalleled insights. New DeFi platform is spearheading this change by bringing together artificial intelligence (AI) and blockchain technology. Algotech (ALGT) The platform aims to transform the global asset trading landscape by providing traders with advanced performance tools. With a vision to maximize data-driven performance, Algotech has introduced an expansive suite of tools designed to empower traders to enhance their chances of achieving maximum returns. Key platform features include elements like Breakout Detection and High Volume Arbitrage that allow traders to identify emerging opportunities across a variety of asset classes. Algotech is also set to introduce Social Trading features that will allow users to share trading setups with their digital communities. The platform offers over 10,000 unique trading pairs across a variety of crypto asset classes. Ensuring Community-Driven Development - The ALGT Token Platform users can seamlessly trade assets and access proprietary trading strategies, all powered by the $ALGT token, which serves as the fundamental backbone of the platform. The token plays a central role in regulating the ecosystem and ensuring seamless governance. By leveraging advanced machine learning, Algotech aims to address the constraints of traditional trading platforms. The $ALGT tokens also serve as a fundamental tool for regulating the governance of the platform. Holders can vote on critical proposals along with an expansive range of governance rights. Additionally, the platform is also empowering community growth with profit shares on trading fees. Algotech (ALGT) Crosses $2 Million Milestone in Record Time Algotech launched its public presale in February 2024, and since then, the project has exceeded all of the team's expectations with a $2.1 million raise within weeks. Over 50 Million ALGT tokens have been sold to 5,000 unique holders. The token is priced at $0.06 in the current presale stage but is expected to jump to $0.08 shortly in the next round. About Algotech Algotech is an algorithmic trading platform that leverages advanced algorithms and machine learning technology to provide strategic advantages to traders. The platform features data analysis and risk management tools that are designed to give a competitive edge. Algotech users can also have access to trading strategies and arbitrage cross-platform opportunities. Users can visit Algotech Presale , and can also Join The Algotech Community . here here Contact Algotech Team Algotech algotechsolutionsio@gmail.com This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here.

DeFi Platform Algotech Raises $250,000 In A Single Day To Cross $2M Presale Milestone

Are you running into scenarios where you have a single line of text that can get too long, and you want to truncate it? How about multiple lines that you want to constrain to a known number of lines and then truncate? Well, in this post, I’ll show you how to do both with nothing but . Let’s check it out! CSS https://youtu.be/SrKwDEihwB4?embedable=true Truncating a Single Line of Text With the text-overflow Property With CSS, we have the property that we can use any time we want to truncate a single line of text. Seems simple enough, right? But there are a couple of things to be on the lookout for, so let’s look at an example. text-overflow Here, we have some issues with our username being displayed in the header bar for our site. This person has a long name, and it’s breaking our layout. Let’s truncate it when this happens. Here on our username, we already have set to because we want to keep the name on a single line. white-space nowrap .username {
  white-space: nowrap;
} So, to truncate it, we use the with a value of . text-overflow ellipsis .username {
  white-space: nowrap;
  text-overflow: ellipsis;
} But nothing happens. This is because we need to do a few more things here. First, text-overflow won’t work without adding overflow hidden. .username {
  white-space: nowrap;
  text-overflow: ellipsis;
  overflow: hidden;
} Properly Handling text-overflow Within a Flex Container Another issue we have with this particular example is that it’s contained within our header, which is a flex container. Both the nav and our user sections will be flex items that have a min-width value of auto by default. We need to make our user item flexible, which we can do by adding a flex of one. .user {
  flex: 1;
} And now, we need to allow it to shrink by setting a min-width to zero. .user {
  flex: 1;
  min-width: 0;
} Ok, now we’re getting somewhere, but our avatar is getting a little squeezed. This is probably because we need to make our username flexible, too, so let’s add flex one. .username {
  white-space: nowrap;
  text-overflow: ellipsis;
  overflow: hidden;
  flex: 1;
} Yep, that was it. Nice, so we have this single line of text truncated properly now. You can check out the final example below: https://codepen.io/brianmtreese/pen/vYvPzzY?embedable=true Truncating Multiple Lines of Text With the line-clamp Property What if we had multiple lines that we wanted to truncate? Well, we can do this again with a handful of properties and the webkit prefixed property. Let’s take a look at another example. CSS line-clamp Here, we have this list of blog posts that show an excerpt. But we only want to see three lines of the excerpt in each post. Well, let’s add our webkit property with a value of three. line-clamp p {
  -webkit-line-clamp: 3;
} Ok, just like the last example, nothing happens. This is because we need a few more properties, too. First, we need to set the display property to webkit-box. p {
  -webkit-line-clamp: 3;
  display: -webkit-box;
} Then we need to add -webkit-box-orient: with a value of vertical. Almost there, I promise. p {
  -webkit-line-clamp: 3;
  display: -webkit-box;
  -webkit-box-orient: vertical;
} The last thing we need to add is overflow hidden. p {
  -webkit-line-clamp: 3;
  display: -webkit-box;
  -webkit-box-orient: vertical;
  overflow: hidden; 
} Tada. There it is; now, these are properly truncated to three lines of text. And, even as they shrink and grow, they will continue to show three lines. Pretty cool. It’s probably important here to mention that, in most cases similar to this, you’d want to be sure that you’re not hiding a lot of text for performance reasons. Like if these excerpts were actually a full blog post here, that wouldn’t be great. It’s better to do something more like what we have, where we have a fairly short excerpt for each post, and then we truncate with CSS. Check out the final example below: https://codepen.io/brianmtreese/pen/Jjwzmdg?embedable=true Also published here .

Text Truncation in CSS: Learn Single and Multiple Line Truncation with Ease

In my , we saw about Low-Rank Adaptation or LoRA. LoRA is quite effective for deploying large models and is also fast for inference, thereby solving the inference problem of fine-tuned LLMs. However, when it comes to training, LoRA doesn’t do the trick. For example, to fine-tune a LLAMA 65 billion parameter model, LoRA needs 780 GB of GPU memory. That is about 16 A40 GPUs. The answer to this problem lies with QLoRA, where Q stands for Quantisation. The main motivation for QLoRA is to achieve fine-tuning on a single GPU. previous article QLoRA does this with only three innovations namely: 1. (NF4), a new data type that is information-theoretically optimal for normally distributed weights. 2. to reduce the average memory footprint by quantizing the quantization constants. 3. to manage memory spikes. 4-bit NormalFloat Double Quantization Paged Optimizers In this article, let's look at all three of these novelties and understand QLoRA. Visual Learning If you are a visual learner like me and would like a video version of this article, you may find it on YouTube: https://youtu.be/6l8GZDPbFn8?si=Dx7ubp9bLpb-_lTP&embedable=true Quantization Let's start with Quantisation, which is fundamental to QLoRA. Simply put, quantization works by rounding and truncating to simplify the input values. For the sake of simplicity, consider we are quantizing from Float16 to int4. Int4 has a range of -8 to 7. As we only have 4 bits to work with, we can only have 2 power 4, which is 16 bins to quantize into. So, any input float value needs to be mapped to the centers of one of these 16 bins. Getting into neural networks, the inputs are tensors, which are large matrices. And they are usually normalized between -1 and 1 or 0 and 1. Let's consider the case of a simple tensor with 3 values, say, -0.976, 0.187, and 0.886. We are lucky with this example as the values are distributed equally across the normalized range. When we quantize to int4, each of the 3 numbers takes a unique bin. One problem with quantization is that of outliers, motivating for blockwise quantization Let's take a slightly different example where the input values are no longer equally distributed in the input range. Let two inputs be close together, with one far apart. If we now quantize to int4, the first two numbers fall in the same bin. while the third one is fine. Oh, we don’t want this because, if at all you want to dequantize and convert back to float16, the two numbers no longer convert back to unique values. In other words, we lost valuable information through . quantization error Blockwise Quantization Blockwise quantization, where we divide the input range into blocks. The illustration is with three blocks, each having its quantization constants. One way to overcome this problem could be to divide the input range into separate blocks. In this example, we have three blocks. And we quantize each block separately with each having its own range. So now, the two values that are close together find different bins inside a block. And the third one never had a problem, so it's fine. By dividing into blocks, we independently quantized each block and so each block comes with its quantization parameters, which often is the quantization constant c. In this example, they are c_1, c_2 and c_3. What we just saw is which we illustrated with three blocks. block-wise quantisation, But practically, QLoRA uses a block size of 64 for the weights for high quantization precision. NormalFloat Talking of the weights, one of the interesting properties of pre-trained neural network weights is that they are normally distributed, and centered around zero. Re-weighting of the quantization values with a normal distribution leads to NormalFloat datatype This means that there is a very high probability for values occurring closer to zero rather than around -1 or plus 1. But our standard quantization to int4 is not aware of this fact. And so goes by the assumption that each of the 16 bins has an equal probability of getting the values. To address this problem with standard quantization, we can develop a slightly specialized type of quantization that considers the normal distribution of the neural network weights. This is exactly what QLoRA does, and it names it k-bit NormalFloat. In NormalFloat, the bins are weighted by the normal distribution, and hence, the spacing between two quantization values are far apart near the extremes of -1 or 1 but are closer together as we get closer to 0. To throw some additional light, the green dots show the 4-bit NormalFloat quantization versus the standard 4-bit quantization shown in the blue dots. Let's now move to the next contribution of the paper, which is double quantization. Because the motivation of QLoRA is to train on a single GPU, it is essential to squeeze every bit of memory as possible. If we recall blockwise quantization, we saw that we use 64 blocks to quantize the weights, and each of these blocks has a quantization constant *c*. So, double quantization is the process of for additional memory savings. And through double quantization, we gain half a bit per parameter on average. quantizing the quantization constants The last bit of the puzzle is paged optimizers. Paged Optimizers Paged Optimizers use the CPU memory whenever there is an overflow of memory on the GPU, thereby coping with long sequences. Paged Optimizers prevent memory spikes whenever we abruptly get a long input. Let's say we are working with documents, and suddenly, we have a long document. When we use a single GPU for training, this spike in sequence length generally breaks the training. So to overcome this, the state of the optimizer, say, Adam, is moved from the GPU memory to the CPU till the long sequence is read. Then, when the GPU memory is freed, the optimized state is moved back to the GPU. At a high level thats what happens if we leverage paged optimizers. In terms of the implementation, the paged optimizer is part of the bits and bytes library. And you can enable or disable it during your QLoRA training by simply setting the flag is_paged on or off. Putting together the above-mentioned three components, QLoRA efficiently uses a low-precision storage data type, in our case usually 4-bit, and one computation data type that is usually BFloat16. What does that mean? Going back to LoRA, it means that to optimize for the memory, the weights of the model are stored in NF4. This enables us to load the weights into a single GPU, and the loaded weights are converted into BFloat16 for the computation of gradients during backpropagation. To link it to LoRA, let's look back at this equation from LoRA, where is the input, and is our pre-trained model weights. and are low-rank matrix decompositions. x W_0 A B With QLoRA, our input is . Our weights are stored as (NF4). During the computation of gradients, our weights and quantization constants go through a double dequantization, which is the reverse of double quantization. It happens by first dequantizing the quantization constants and . Then, using the constants, we once again dequantize the weights to BrainFloat16, which is used to compute the gradients. x BrainFloat16 Normal Float4 c_1 c_2 If you are wondering how good is NormalFloat and double quantization, the authors of QLoRA experimented with four datasets and showed that in all four cases, using normal float and double quantization improves the mean zero-shot accuracy of training compared to simply using float. In terms of the GLUE score, QLoRA can replicate the accuracy of 16-bit LoRA and full-finetuning. The authors conclude that 4-bit QLORA with NF4 data type matches 16-bit full finetuning and 16-bit LoRA finetuning performance on academic benchmarks with well-established evaluation setups. So, if you are interested in finetuning on a single GPU and would like the fine-tuned model to match the performance of standard finetuning on multiple GPUs, then QLoRA is the way to go. I hope that was a useful insight into QLoRA. I will see you in my next. Until then, take care. Also published . here

QLoRA: Fine-Tuning Your LLMs With a Single GPU

Previous Parts: Clean Code: Functions and Methods in TypeScript [Part 1] Clean Code: Naming and Code Composition in TypeScript [Part 2] Clean Code: Classes and Objects in TypeScript [Part 3] We are continuing to consider approaches to making our code clean, flexible, and maintainable. And now, let’s start to investigate clean architectural solutions. SOLID principles were introduced by Robert C. Martin and are widely regarded as best practices in object-oriented programming and software design. In this article, we will take a look at the three first SOLID principles: The Single Responsibility Principle, the Open/Closed Principle, and the Liskov Substitution Principle on practical examples. Table of Contents: Single Responsibility Principle Open/Closed Principle Liskov Substitution Principle 1. Single Responsibility Principle (SRP) A class should have only one reason to change In other words, a class should have a single responsibility or job. It is important because a class with a single responsibility is easier to understand, modify, and maintain. Changes in one area of the code won't ripple through the entire system, reducing the risk of introducing bugs. Let’s take a look at a practical example and ways to follow the single responsibility principle: // Bad
class UserSettingsService {
  constructor(user: IUser) {
    this.user = user;
  }

  changeSettings(settings: IUserSettings): void {
    if (this.isUserValidated()) {
      // ...
    }
  }

  getUserInfo(): Promise<IUserSettings> {
    // ...
  }

  async isUserValidated(): Promise<boolean> {
    const userInfo = await this.getUserInfo();
    // ...
  }
} In this example, our class carries out actions in different directions: it sets up context, changes it, and validates it. To follow SRP, we need to split these different responsibilities. // Better
class UserAuth {
  constructor(user: IUser) {
    this.user = user;
  }

  getUserInfo(): Promise<IUserSettings> {
    // ...
  }

  async isUserValidated(): boolean {
    const userInfo = await this.getUserInfo();
    // ...
  }
}

class UserSettings {
  constructor(user: IUser) {
    this.user = user;
    this.auth = new UserAuth(user);
  }

changeSettings(settings: IUserSettings): void {
    if (this.auth.isUserValidated()) {
      // ...
    }
  }
} Why Is It Important? SRP aims to enhance code modularity, minimizing challenges stemming from inter-dependencies. By organizing code into functions, separated classes, and promoting modularity, it becomes more reusable, saving time that might otherwise be spent re-coding existing functionality. 2. Open/Closed Principle (OCP) Software entities (classes, modules, functions) should be open for extension but closed for modification You should be able to add new functionality without changing existing code. It is important because by adhering to this principle, you can introduce new features or components to your system without risking the stability of the existing code. It promotes code reusability and reduces the need for extensive changes when extending functionality. // Bad
class Product {
 
  id: number;
  name: string[];
  price: number;

  protected constructor(id: number, name: string[], price: number) {
    this.id = id;
    this.name = name;
    this.price = price;
  }
}

class Ananas extends Product {
  constructor(id: number, name: string[], price: number) {
    super(id, name, price);
  }
}

class Banana extends Product {
  constructor(id: number, name: string[], price: string) {
     super(id, name, price);
   }
} 

class HttpRequestCost {
  constructor(product: Product) {
    this.product = product;
  }

  getDeliveryCost(): number {
     if (product instanceOf Ananas) {
        return requestAnanas(url).then(...);
    }
    
    if (product instanceOf Banana) {
        return requestBanana(url).then(...);
    }
  }
}


function requestAnanas(url: string): Promise<ICost> {
    // logic for ananas
}

function requestBanana(url: string): Promise<ICost> {
    // logic for bananas
} In this example, the problem is in class , which, in method, contains conditions for the calculation of different types of products, and we use separate methods for each type of product. So, if we need to add a new type of product, we should modify the class, and it is not safe; we could get unexpected results. HttpRequestCost getDeliveryCost HttpRequestCost To avoid it, we should create an abstract method in class without realizations. The particular realization will have inherited the classes: Ananas and Banana. They will realize the request for themself. request Product will take the parameter following the class interface, and when we pass particular dependencies in , it will already realize method for itself. HttpRequestCost product Product HttpRequestCost request // Better
abstract class Product {

  id: number;
  name: string[];
  price: string;

  constructor(id: number, name: string[], price: string) {
    this.id = id;
    this.name = name;
    this.price = price;
  }

  abstract request(url: string): void;
}


class Ananas extends Product {
   constructor(id: number, name: string[], price: string) {
     super(id, name, price);
   }

   request(url: string): void {
      // logic for ananas
   }
}

class Banana extends Product {
   constructor(id: number, name: string[], price: string) {
     super(id, name, price);
   }

   request(url: string): void {
      // logic for bananas
   }
}


class HttpRequestCost {
  constructor(product: Product) {
    this.product = product;
  }

  request(): Promise<void> {
    return this.product.request(url).then(...);
  }
} Why Is It Important? Following this principle, you will reduce code coupling and save the system from unpredictable behavior. 3. Liskov Substitution Principle (LSP) Objects of a superclass should be replaceable with objects of its subclasses without breaking the application. To understand this principle, let’s take a look at this example: // Bad
class Worker {
  work(): void {/../}

  access(): void {
    console.log('Have an access to closed perimeter');
  }
}

class Programmer extends Worker {
  createDatabase(): void {/../}
}

class Seller extends Worker {
  sale(): void {/../}
}

class Designer extends Worker {
  access(): void {
    throwError('No access');
  }
} In this example, we have an issue with the class. , , and are all Workers, and they inherited from the parent class . But at the same time, Designers do not have access to closed perimeter because they are Contractors, not Employees. And we have overridden the method and broke the Liskov Substitution Principle. Contractor Designer Programmer Seller Worker access This principle tells us that if we replace the superclass with its subclass, for example class, the functionality should not be broken. But if we do it, the functionality of the class will be broken - the method will have unexpected realizations from class. Worker Designer Programmer access Designer Following the Liskov Substitution Principle, we should not rewrite the realizations in subclasses but need to create new layers of abstraction where we define particular realizations for each type of abstraction. Let’s correct it: // Better
class Worker {
  work(): void {/../}
}

class Employee extends Worker {
  access(): void {
    console.log('Have an access to closed perimeter');
  }
}

class Contractor extends Worker {
  addNewContract(): void {/../}
}

class Programmer extends Employee {
  createDatabase(): void {/../}
}

class Saler extends Employee {
  sale(): void {/../}
}

class Designer extends Contractor {
  makeDesign(): void {/../}
} We created new layers of abstractions and and moved method to the class and defined specific realization. If we replace class with subclass , the functionality will not be broken. Employee Contractor access Employee Worker Contractor Worker Why Is It Important? If you adhere to LSP, you can substitute any subclass instance wherever a base class instance is expected, and the program should still work as intended. This promotes code reuse, modularity, and makes your code more resilient to changes. In the next article, we will take a look at Interface Segregation and Dependency Inversion SOLID principles.

Clean Code: Single Responsibility, Open/Closed, Liskov Substitution SOLID Principles in TS [Part 4]

ক্লিন কোড: একক দায়িত্ব, খোলা/বন্ধ, টিএসে লিসকভ প্রতিস্থাপন সলিড নীতিগুলি [পর্ব 4]

Clean Code: Einzelverantwortung, offen/geschlossen, Liskov-Substitution SOLID-Prinzipien in TS [Teil 4]

Código limpio: responsabilidad única, abierto/cerrado, sustitución de Liskov Principios SÓLIDOS en TS [Parte 4]

Code propre : responsabilité unique, ouvert/fermé, substitution Liskov Principes SOLID dans TS [Partie 4]

स्वच्छ कोड: टीएस में एकल जिम्मेदारी, खुला/बंद, लिस्कोव प्रतिस्थापन ठोस सिद्धांत [भाग 4]

クリーンなコード: 単一責任、オープン/クローズ、リスコフ置換 TS における SOLID 原則 [パート 4]

클린 코드: 단일 책임, 공개/폐쇄, Liskov 대체 TS의 SOLID 원칙 [4부]

Código Limpo: Responsabilidade Única, Aberto/Fechado, Substituição de Liskov Princípios SOLID em TS [Parte 4]

Чистый код: единая ответственность, открытость/закрытость, замена Лискова Принципы SOLID в TS [Часть 4]

Temiz Kod: Tek Sorumluluk, Açık/Kapalı, TS'de Liskov Değiştirme SOLID İlkeleri [Bölüm 4]

Mã sạch: Trách nhiệm duy nhất, Mở/Đóng, Nguyên tắc SOLID thay thế Liskov trong TS [Phần 4]

简洁代码：TS 中的单一职责、开放/封闭、里氏替换 SOLID 原则 [第 4 部分]

Django is a popular framework that you can select to develop an application for your company. But what if you want to create a SaaS application that multiple clients will use? What architecture should you choose? Let’s see how this task can be approached. Single-Tenant Architecture The most straightforward approach is to create a separate instance for each client you have. Let’s say we have a Django application and a database. Then, for each client, we need to run its own database and application instance. That means that each application instance has only one tenant. This approach is simple to implement: you need to just start a new instance of every service that you have. But at the same time, it can cause a problem: each client will significantly of the infrastructure. It may be not a big deal if you plan to have just a few clients or if each instance is tiny. increase the cost However, let’s assume that we are building a large company that provides a corporate messenger to 100,000 organizations. Imagine, how expensive it can be to duplicate the whole infrastructure for each new client! And, when we need to update the application version, we need to deploy it for each client, so . the deployment will be slowed down too Multi-Tenant Architecture There is another approach that can help in a scenario when we have a lot of clients for the application: a multi-tenant architecture. It means that we have multiple clients, that we call , but they all use only one instance of the application. tenants While this architecture solves the problem of the high cost of dedicated instances for each client, it introduces a new problem: how can we be sure that the client’s data is securely isolated from other clients? We will discuss the following approaches: Using : We can identify which tenant owns the data by the foreign key that we need to add to each database table. a shared database and shared database schema Using : This way, we won’t need to maintain multiple database instances but will get a good level of tenant data isolation. a shared database, but separate database schemas Using : it looks similar to the single-tenant example, but won’t be the same, as we will still use a shared application instance and select which database to use by checking the tenant. separate databases Let’s dive deeper into these ideas and see how to integrate them with the Django application. A Shared Database With Shared Schema This option may be the first that comes to mind: to add a ForeignKey to the tables, and use it to select appropriate data for each tenant. However, it has a huge disadvantage: the tenants’ data is not isolated at all, so a small programming error can be enough to leak the tenant’s data to the wrong client. Let’s take an example of database structure from : Django documentation from django.db import models


class Question(models.Model):
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField("date published")


class Choice(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    choice_text = models.CharField(max_length=200)
    votes = models.IntegerField(default=0) We’ll need to identify which records are owned by which tenant. So, we need to add a table and a foreign key in each existing table: Tenant class Tenant(models.Model):
    name = models.CharField(max_length=200)


class Question(models.Model):
    tenant = models.ForeignKey(Tenant, on_delete=models.CASCADE)
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField("date published")


class Choice(models.Model):
    tenant = models.ForeignKey(Tenant, on_delete=models.CASCADE)
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    choice_text = models.CharField(max_length=200)
    votes = models.IntegerField(default=0) To simplify the code a little bit, we can create an abstract base model that will be reused in each other model that we create. class Tenant(models.Model):
    name = models.CharField(max_length=200)


class BaseModel(models.Model):
    tenant = models.ForeignKey(Tenant, on_delete=models.CASCADE)

    class Meta:
        abstract = True


class Question(BaseModel):
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField("date published")


class Choice(BaseModel):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    choice_text = models.CharField(max_length=200)
    votes = models.IntegerField(default=0) As you can see, there are at least two major risks here: a to the new model, or a developer can forget to add a tenant field developer can forget to use this field while filtering the data. The source code for this example can be found on GitHub: . https://github.com/bp72/django-multitenancy-examples/tree/main/01_shared_database_shared_schema A Shared Database With Separate Schemas Keeping in mind the risks of the shared schema, let’s consider another option: the database will be still shared, but we’ll create a dedicated schema for each tenant. For implementation, we can look at a popular library ( ). django-tenants documentation Let’s add to our small project (the official installation steps can be found ). django-tenants here The first step is the library installation via : pip pip install django-tenants Change the models: the model will now be in a separate app and models won’t have a connection with the tenant anymore. As different tenants’ data will be in separate schemas, we won’t need to link the individual records with the tenant rows anymore. Tenant Question Choice The file tenants/models.py from django.db import models
from django_tenants.models import TenantMixin, DomainMixin


class Tenant(TenantMixin):
    name = models.CharField(max_length=200)

    # default true, schema will be automatically created and synced when it is saved
    auto_create_schema = True


class Domain(DomainMixin):  # a required table for django-tenants too
    ... The file polls/models.py from django.db import models


class Question(models.Model):
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField("date published")


class Choice(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    choice_text = models.CharField(max_length=200)
    votes = models.IntegerField(default=0) Notice that Question and Choice don’t have a foreign key to Tenant anymore! The other thing that was changed is that the Tenant is now in a separate app: it’s not only for separating the domains but also important as we will need to store the table in the shared schema, and tables will be created for each tenant schema. tenants polls Make changes to the file to support multiple schemas and tenants: settings.py DATABASES = {
    'default': {
        'ENGINE': 'django_tenants.postgresql_backend',
        # ..
    }
}
DATABASE_ROUTERS = (
    'django_tenants.routers.TenantSyncRouter',
)
MIDDLEWARE = (
    'django_tenants.middleware.main.TenantMainMiddleware',
    #...
)
TEMPLATES = [
    {
        #...
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.request',
                #...
            ],
        },
    },
]
SHARED_APPS = (
    'django_tenants',  # mandatory
    'tenants', # you must list the app where your tenant model resides in

    'django.contrib.contenttypes',

    # everything below here is optional
    'django.contrib.auth',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.messages',
    'django.contrib.admin',
)

TENANT_APPS = (
    # your tenant-specific apps
    'polls',
)

INSTALLED_APPS = list(SHARED_APPS) + [app for app in TENANT_APPS if app not in SHARED_APPS]

TENANT_MODEL = "tenants.Tenant"

TENANT_DOMAIN_MODEL = "tenants.Domain" Next, let’s create and apply the migrations: python manage.py makemigrations python manage.py migrate_schemas --shared As a result, we’ll see that the public schema will be created and will contain only shared tables. We’ll need to create a default tenant for the schema: public python manage.py create_tenant --domain-domain=default.com --schema_name=public --name=default_tenant Set to if asked. is_primary True And then, we can start creating the real tenants of the service: python manage.py create_tenant --domain-domain=tenant1.com --schema_name=tenant1 --name=tenant_1
python manage.py create_tenant --domain-domain=tenant2.com --schema_name=tenant2 --name=tenant_2 Notice that there are now 2 more schemas in the database that contain tables: polls Now, you’ll get the Questions and Choices from different schemas when you call APIs on the domains that you set up for the tenants - all done! Although the setup looks more complicated and maybe even harder if you migrate the existing app, the approach itself still has a lot of advantages such as the security of the data. The code of the example can be found . here Separate Databases The last approach that we will discuss today is going even further and having separate databases for the tenants. This time, we’ll have a few databases: We’ll store the shared data such as tenant’s mapping to the databases’ names in the and create a separate database for each tenant. default_db Then we’ll need to set the databases config in the settings.py: DATABASES = {
    'default': {
        'NAME': 'default_db',
        ...
    },
    'tenant_1': {
        'NAME': 'tenant_1',
        ...
    },
    'tenant_2': {
        'NAME': 'tenant_2',
        ...
    },
} And now, we’ll be able to get the data for each tenant by calling QuerySet method: using Questions.objects.using(‘tenant_1’)… The downside of the method is that you’ll need to apply all migrations on each database by using: python manage.py migrate --database=tenant_1 It also may be less convenient to create a new database for each tenant, compared to the usage of the or just using a foreign key as in the shared schema approach. django-tenants On the other hand, the isolation of the tenant’s data is really good: the databases can be physically separated. Another advantage is that we won’t be limited by using only Postgresql as it’s required by the , we can select any engine that will suit our needs. django-tenants More information on the multiple databases topic can be found in the Django . documentation Comparison Single-tenant MT with shared schema MT with separate schema MT with separate databases Data isolation ✅High ❌Lowest ✅High ✅High Risk of leaking data accidentally ✅Low ❌High ✅Low ✅Low Infrastructure cost ❌Higher with each tenant ✅Lower ✅Lower ✅❌ Lower than single-tenant Deployment speed ❌Lower with each tenant ✅ ✅❌ Migrations will be slower as they need to be executed for each schema ✅❌ Migrations will be slower as they need to be executed for each database Easy to implement ✅ ❌ Requires a lot of changes if the service was already implemented as a single-tenant app ✅ ✅ Conclusion To summarize all the above, It looks like there is no silver bullet for the problem, each approach has its pros and cons, so it’s up to the developers to decide what trade-off they can have. Separate databases provide the best isolation for the tenant’s data and are simple to implement, however, it costs you a higher for maintenance: n database to update, database connections numbers are higher. A shared database with a separate schema bit complex to implement and might have some problems with migration. Single tenant is the most simple to implement, but it costs you by resource over-consumption since you have an entire copy of your service per tenant.

Django SaaS Architecture: Single-Tenant vs Multi-Tenant - Which Is Right for You?

জ্যাঙ্গো সাস আর্কিটেকচার: একক-ভাড়াটে বনাম মাল্টি-টেন্যান্ট - আপনার জন্য কোনটি সঠিক?

Django SaaS-Architektur: Single-Tenant vs. Multi-Tenant – Welche ist die richtige für Sie?

Arquitectura Django SaaS: inquilino único frente a inquilino múltiple: ¿cuál es la adecuada para usted?

Architecture SaaS Django : mono-locataire ou multi-locataire – Qu'est-ce qui vous convient ?

Django SaaS आर्किटेक्चर: सिंगल-टेनेंट बनाम मल्टी-टेनेंट - आपके लिए क्या सही है?

Django SaaS アーキテクチャ: シングルテナントとマルチテナント - どちらが最適ですか?

Django SaaS 아키텍처: 단일 테넌트와 다중 테넌트 - 귀하에게 적합한 것은 무엇입니까?

Arquitetura Django SaaS: Inquilino único vs Multi-inquilino - Qual é a certa para você?

SaaS-архитектура Django: одноарендная или мультитенантная — что подойдет именно вам?

Django SaaS Mimarisi: Tek Kiracılı mı Çok Kiracılı mı - Hangisi Size Uygun?

Kiến trúc Django SaaS: Một người thuê và Nhiều người thuê - Cái nào phù hợp với bạn?

Django SaaS 架构：单租户与多租户 - 哪一个适合您？

SINGLE

singlefinance.io

-- employees

Since n.d.

COMPANY RANKING

SINGLE

EVERGREEN INDEX #9604

Representing this company? Click here to claim and customize this page!

Single WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

SINGLE

singlefinance.io

-- employees

Since n.d.

COMPANY RANKING

SINGLE

EVERGREEN INDEX #9604

RELATED COMPANIESRANK

STORIES ABOUT SINGLE

Representing this company? Click here to claim and customize this page!

Single WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!