Singleis in the Cryptocurrencies Industry

Single

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 架构：单租户与多租户 - 哪一个适合您？

Christian Science by Mark Twain, is part of the HackerNoon Books Series. You can jump to any chapter in this book . CHAPTER XV here CHAPTER XV We may take that up now.
It is not a single if, but a several-jointed one; not an oyster, but a vertebrate. Did Mrs. Eddy borrow from Quimby the Great Idea, or only the little one, the old-timer, the ordinary mental-healing-healing by “mortal” mind? If she borrowed the Great Idea, did she carry it away in her head, or in manuscript? Did she hit upon the Great Idea herself? By the Great Idea I mean, of course, the conviction that the Force involved was still existent, and could be applied now just as it was applied by Christ's Disciples and their converts, and as successfully. Did she philosophize it, systematize it, and write it down in a book? Was it she, and not another, that built a new Religion upon the book and organized it? I think No. 5 can be answered with a Yes, and dismissed from the controversy. And I think that the Great Idea, great as it was, would have enjoyed but a brief activity, and would then have gone to sleep again for some more centuries, but for the perpetuating impulse it got from that organized and tremendous force. As for Nos. 1, 2, and 4, the hostiles contend that Mrs. Eddy got the Great Idea from Quimby and carried it off in manuscript. But their testimony, while of consequence, lacks the most important detail; so far as my information goes, the Quimby manuscript has not been produced. I think we cannot discuss No. 1 and No. 2 profitably. Let them go. For me, No. 3 has a mild interest, and No. 4 a violent one. As regards No. 3, Mrs. Eddy was brought up, from the cradle, an old-time, boiler-iron, Westminster-Catechism Christian, and knew her Bible as well as Captain Kydd knew his, “when he sailed, when he sailed,” and perhaps as sympathetically. The Great Idea had struck a million Bible-readers before her as being possible of resurrection and application—it must have struck as many as that, and been cogitated, indolently, doubtingly, then dropped and forgotten—and it could have struck her, in due course. But how it could interest her, how it could appeal to her—with her make this a thing that is difficult to understand. For the thing back of it is wholly gracious and beautiful: the power, through loving mercifulness and compassion, to heal fleshly ills and pains and grief—all—with a word, with a touch of the hand! This power was given by the Saviour to the Disciples, and to all the converted. All—every one. It was exercised for generations afterwards. Any Christian who was in earnest and not a make-believe, not a policy—Christian, not a Christian for revenue only, had that healing power, and could cure with it any disease or any hurt or damage possible to human flesh and bone. These things are true, or they are not. If they were true seventeen and eighteen and nineteen centuries ago it would be difficult to satisfactorily explain why or how or by what argument that power should be nonexistent in Christians now. To wish to exercise it could occur to Mrs. Eddy—but would it? Grasping, sordid, penurious, famishing for everything she sees—money, power, glory—vain, untruthful, jealous, despotic, arrogant, insolent, pitiless where thinkers and hypnotists are concerned, illiterate, shallow, incapable of reasoning outside of commercial lines, immeasurably selfish— Of course the Great Idea could strike her, we have to grant that, but why it should interest her is a question which can easily overstrain the imagination and bring on nervous prostration, or something like that, and is better left alone by the judicious, it seems to me— Unless we call to our help the alleged other side of Mrs. Eddy's make and character the side which her multitude of followers see, and sincerely believe in. Fairness requires that their view be stated here. It is the opposite of the one which I have drawn from Mrs. Eddy's history and from her By-laws. To her followers she is this: Patient, gentle, loving, compassionate, noble hearted, unselfish, sinless, widely cultured, splendidly equipped mentally, a profound thinker, an able writer, a divine personage, an inspired messenger whose acts are dictated from the Throne, and whose every utterance is the Voice of God. She has delivered to them a religion which has revolutionized their lives, banished the glooms that shadowed them, and filled them and flooded them with sunshine and gladness and peace; a religion which has no hell; a religion whose heaven is not put off to another time, with a break and a gulf between, but begins here and now, and melts into eternity as fancies of the waking day melt into the dreams of sleep. They believe it is a Christianity that is in the New Testament; that it has always been there, that in the drift of ages it was lost through disuse and neglect, and that this benefactor has found it and given it back to men, turning the night of life into day, its terrors into myths, its lamentations into songs of emancipation and rejoicing. There we have Mrs. Eddy as her followers see her. She has lifted them out of grief and care and doubt and fear, and made their lives beautiful; she found them wandering forlorn in a wintry wilderness, and has led them to a tropic paradise like that of which the poet sings: “O, islands there are on the face of the deep
 Where the leaves never fade and the skies never weep.” To ask them to examine with a microscope the character of such a benefactor; to ask them to examine it at all; to ask them to look at a blemish which another person believes he has found in it—well, in their place could you do it? Would you do it? Wouldn't you be ashamed to do it? If a tramp had rescued your child from fire and death, and saved its mother's heart from breaking, could you see his rags? Could you smell his breath? Mrs. Eddy has done more than that for these people. They are prejudiced witnesses. To the credit of human nature it is not possible that they should be otherwise. They sincerely believe that Mrs. Eddy's character is pure and perfect and beautiful, and her history without stain or blot or blemish. But that does not settle it. They sincerely believe she did not borrow the Great Idea from Quimby, but hit upon it herself. It may be so, and it could be so. Let it go—there is no way to settle it. They believe she carried away no Quimby manuscripts. Let that go, too—there is no way to settle it. They believe that she, and not another, built the Religion upon the book, and organized it. I believe it, too. Finally, they believe that she philosophized Christian Science, explained it, systematized it, and wrote it all out with her own hand in the book Science and Health. I am not able to believe that. Let us draw the line there. The known and undisputed products of her pen are a formidable witness against her. They do seem to me to prove, quite clearly and conclusively, that writing, upon even simple subjects, is a difficult labor for her: that she has never been able to write anything above third-rate English; that she is weak in the matter of grammar; that she has but a rude and dull sense of the values of words; that she so lacks in the matter of literary precision that she can seldom put a thought into words that express it lucidly to the reader and leave no doubts in his mind as to whether he has rightly understood or not; that she cannot even draught a Preface that a person can fully comprehend, nor one which can by any art be translated into a fully understandable form; that she can seldom inject into a Preface even single sentences whose meaning is uncompromisingly clear—yet Prefaces are her specialty, if she has one. Mrs. Eddy's known and undisputed writings are very limited in bulk; they exhibit no depth, no analytical quality, no thought above school composition size, and but juvenile ability in handling thoughts of even that modest magnitude. She has a fine commercial ability, and could govern a vast railway system in great style; she could draught a set of rules that Satan himself would say could not be improved on—for devilish effectiveness—by his staff; but we know, by our excursions among the Mother-Church's By-laws, that their English would discredit the deputy baggage-smasher. I am quite sure that Mrs. Eddy cannot write well upon any subject, even a commercial one. In the very first revision of Science and Health (1883), Mrs. Eddy wrote a Preface which is an unimpeachable witness that the rest of the book was written by somebody else. I have put it in the Appendix along with a page or two taken from the body of the book, and will ask the reader to compare the labored and lumbering and confused gropings of this Preface with the easy and flowing and direct English of the other exhibit, and see if he can believe that the one hand and brain produced both. And let him take the Preface apart, sentence by sentence, and searchingly examine each sentence word by word, and see if he can find half a dozen sentences whose meanings he is so sure of that he can rephrase them—in words of his own—and reproduce what he takes to be those meanings. Money can be lost on this game. I know, for I am the one that lost it. Now let the reader turn to the excerpt which I have made from the chapter on “Prayer” (last year's edition of Science and Health), and compare that wise and sane and elevated and lucid and compact piece of work with the aforesaid Preface, and with Mrs. Eddy's poetry concerning the gymnastic trees, and Minerva's not yet effete sandals, and the wreaths imported from Erudition's bower for the decoration of Plymouth Rock, and the Plague-spot and Bacilli, and my other exhibits (turn back to my Chapters I. and II.) from the Autobiography, and finally with the late Communication concerning me, and see if he thinks anybody's affirmation, or anybody's sworn testimony, or any other testimony of any imaginable kind would ever be likely to convince him that Mrs. Eddy wrote that chapter on Prayer. I do not wish to impose my opinion on any one who will not permit it, but such as it is I offer it here for what it is worth. I cannot believe, and I do not believe, that Mrs. Eddy originated any of the thoughts and reasonings out of which the book Science and Health is constructed; and I cannot believe, and do not believe that she ever wrote any part of that book. I think that if anything in the world stands proven, and well and solidly proven, by unimpeachable testimony—the treacherous testimony of her own pen in her known and undisputed literary productions—it is that Mrs. Eddy is not capable of thinking upon high planes, nor of reasoning clearly nor writing intelligently upon low ones. Inasmuch as—in my belief—the very first editions of the book Science and Health were far above the reach of Mrs. Eddy's mental and literary abilities, I think she has from the very beginning been claiming as her own another person's book, and wearing as her own property laurels rightfully belonging to that person—the real author of Science and Health. And I think the reason—and the only reason—that he has not protested is because his work was not exposed to print until after he was safely dead. That with an eye to business, and by grace of her business talent, she has restored to the world neglected and abandoned features of the Christian religion which her thousands of followers find gracious and blessed and contenting, I recognize and confess; but I am convinced that every single detail of the work except just that one—the delivery of the Product to the world—was conceived and performed by another. About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books. This book is part of the public domain. Mark Twain (2004). Christian Science. Urbana, Illinois: Project Gutenberg. Retrieved October 2022 https://www.gutenberg.org/cache/epub/3187/pg3187-images.html This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at , located at . www.gutenberg.org https://www.gutenberg.org/policy/license.html

IT IS NOT A SINGLE IF, BUT A SEVERAL-JOINTED ONE

SEC v. Terraform Court Filing, retrieved on February 16, 2023, is part of . You can jump to any part in this filing . This is part 37 of 38. HackerNoon’s Legal PDF Series here PRAYER FOR RELIEF WHEREFORE, the Commission respectfully requests that this Court enter a Final Judgment: A. Finding that Defendants committed the violations alleged in this Complaint; B. Permanently restraining and enjoining Defendants from violating Sections 5(a) and 5(c) of the Securities Act, 15 U.S.C. § 77e(a), (c); Section 5(e) of the Securities Act, 15 U.S.C. § 77e(e); Section 6(1) of the Exchange Act, 15 U.S.C. § 78f(1); Section 17(a) of the Securities Act, 15 U.S.C. § 77q(a); Section 10(b) of the Exchange Act, 15 U.S.C. § 78j(b), and Rule 10b-5 thereunder, 17 C.F.R. § 240.10b-5; and permanently enjoining Kwon from violating Section 20(a) of the Exchange Act, 15 U.S.C. § 78t(a). C. Ordering Defendants to disgorge their ill-gotten gains, plus prejudgment interest thereon, pursuant to Sections 21(d)(3), (5) and (7) of the Exchange Act, 15 U.S.C. §§ 78u(d)(3), (5) and (7); D. Ordering Defendants to pay civil money penalties pursuant to Section 20(d) of the Securities Act, 15 U.S.C. § 77t(d) and Section 21(d)(3) of the Exchange Act, 15 U.S.C. § 78u(d)(3); E. Imposing a conduct-based injunction pursuant to Section 21(d)(5) of the Exchange Act, 15 U.S.C. §§ 78u(d)(5), prohibiting Defendants from (i) participating, directly or indirectly, in the purchase, offer, or sale of any crypto asset security, or (ii) engaging in activities for purposes of inducing or attempting to induce the purchase, offer, or sale of any crypto asset security by others. F. Grant such further relief as the Court deems appropriate. Continue Reading . Here About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings. This court case 1:23-cv-01346 retrieved on September 12, 2023, from is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. sec.gov

A Comprehensive List of Every Single Violation Terraform Labs and Do Kwon Committed

Applications that require more than one Docker container for deployment are called multi-container applications. These multi-container applications can be deployed using . Docker Compose However, Docker Compose can only be used for local deployment or in production with the native Docker orchestrator, . Docker Swarm In most cases, Docker Swarm might not be your preferred choice for container orchestration. In that case, you're left with the option of using Kubernetes or Openshift. However, Kubernetes and Openshift do not traditionally support Docker compose. Leaving you with such a time-consuming task - writing container orchestration manifests manually. This is where Kompose comes in. Kompose is a tool that automatically converts your Docker compose application into container orchestration (Kubernetes or Openshift) manifests. Using Kompose, you can create the necessary resources - services, deployments, etc., for your application with a single command. This saves you a lot of time and effort when deploying your application. This article will explore Kompose and its benefits and also help you set up Kompose. Using this article, you will learn how to generate manifests using Kompose and deploy your application to Kubernetes. What Is Kompose? Kompose, derived from the name Kubernetes and compose, is a tool that converts Docker compose files into Kubernetes or Openshift manifests. Using a single Kompose command, you can generate all the necessary resources for your application, as defined by Docker Compose. Kompose reads the Docker compose file and gathers all the information about the application. This information includes the container's name, image, ports, volumes, etc. All this information is converted into a . KomposeObject All the information is converted into the target format - Kubernetes or Openshift object. With 99% accuracy, Kompose aligns the container information from the to the specific requirements of the container orchestrators. KomposeObject KomposeObject Finally, Kompose takes this converted information and displays it on the screen or deploys it to container orchestrators like Kubernetes or OpenShift. Why Use Kompose? As you read above, Kompose is a conversion tool that converts Docker compose files into Kubernetes or Openshift manifests. This conversion is done with 99% accuracy. This means you can easily use Kompose to convert your Docker compose files into Kubernetes or Openshift manifests. : Kompose has a wide range of installation options, ensuring that no matter what environment you're working in, you can quickly set it up to facilitate the conversion of container applications from one format to another. Multi-platform compatibility The straightforward installation process makes it accessible to a broad audience, from developers to system administrators, making your container migration tasks more manageable. : Another reason to consider using Kompose is its versatility in converting Docker Compose files into Kubernetes or OpenShift objects. Kompose supports the conversion of Docker Compose files of various versions into Kubernetes and OpenShift objects, making it a valuable tool for container application migration. Versatility Whether you're working with older or newer Docker Compose file formats, Kompose can adapt and handle the conversion process. This flexibility simplifies the migration of your container applications to Kubernetes or OpenShift, regardless of the Docker Compose version you're using. : Another compelling reason to use Kompose is that it's an official Kubernetes project. This official status means that Kompose is well-vetted and maintained by the Kubernetes community, assuring users of its reliability and alignment with Kubernetes best practices. An Official Kubernetes Project Using Kompose, you're leveraging a tool actively supported and developed within the Kubernetes ecosystem. This official recognition adds a level of trust and credibility to the tool, making it a valuable choice for converting Docker Compose configurations to Kubernetes, and it's more likely to stay up-to-date with the latest Kubernetes developments and standards. How to Install Kompose Kompose is a standalone tool that can be installed on any machine. It is written in Go and is available as a binary for Linux, Windows, and Mac. Kompose is also available as a Docker image, which can be used to run Kompose as a container. You can install Kompose on Linux, macOS, Windows, CentOS, Fedora, and even through package managers like Homebrew, Chocolatey, and Docker. To install Kompose, follow the instructions in the . official documentation This article will be using the binary installation method. To install Kompose on Linux, follow the steps below: On your terminal, use the command to download the Kompose binary for Linux: curl curl -L https://github.com/kubernetes/kompose/releases/download/v1.31.1/kompose-linux-amd64 -o kompose This command fetches the Kompose binary for Linux and saves it as . kompose Make the downloaded binary executable by running: chmod +x kompose This command gives execution permission to the binary. kompose Move the binary to a directory included in your system's PATH, such as , which allows you to run it from anywhere in your terminal: kompose /usr/local/bin sudo mv ./kompose /usr/local/bin/kompose Using ensures you have the necessary permissions to move the binary. sudo After completing these steps, you should have successfully installed Kompose on your Linux system. To verify the installation, run the following command kompose version

1.31.1 (46dcb9181) How to Use Kompose After installing Kompose, the next step is to learn how to use it. Kompose is a command-line tool, which means that it is operated via the terminal. This article will focus on using Kompose to generate Kubernetes manifests. To use Kompose to generate Openshift manifests, follow the instructions in the . official documentation Prerequisites To use Kompose to create Kubernetes manifests, you need to have the following installed on your system: Minikube: Minikube is a tool that allows you to run Kubernetes locally. It creates a single-node Kubernetes cluster on your local machine. You can install Minikube by following the instructions in the . official documentation Docker compose: Docker compose is a tool that allows you to define and run multi-container applications. You can install Docker Compose by following the instructions in the . official documentation Kubectl: This tool must be configured to communicate with your cluster. You can install Kubectl by following the instructions in the . official documentation After installing these tools, you will need a docker compose file to work with. For this guide, you will use the Guestbook application. The Guestbook application is a simple application that allows users to leave messages on a website. The application consists of three containers - a Redis master container, a Redis slave container, and a PHP container. The docker-compose file for the Guestbook application is shown below: version: "2"

services:
  redis-master:
    image: registry.k8s.io/redis:e2e
    ports:
      - "6379"

  redis-slave:
    image: gcr.io/google_samples/gb-redisslave:v3
    ports:
      - "6379"
    environment:
      - GET_HOSTS_FROM=dns

  frontend:
    image: gcr.io/google-samples/gb-frontend:v4
    ports:
      - "80:80"
    environment:
      - GET_HOSTS_FROM=dns
    labels:
      kompose.service.type: LoadBalancer This Docker Compose file defines three services. The and services use different container images, exposing port . The service uses the image and maps port of the host to port of the container. redis-master redis-slave 6379 frontend gcr.io/google-samples/gb-frontend:v4 80 80 What's significant is that the service has a label set to , indicating that when converting this configuration to Kubernetes or OpenShift, it should be exposed as a LoadBalancer service, allowing external access to the application through port . frontend kompose.service.type LoadBalancer 80 Generating Kubernetes Manifests With Kompose To generate Kubernetes manifests with Kompose, follow the steps below: Create a new file called , and copy the Docker Compose file above. docker-compse.yml Start Minikube by running the command below: minikube start This command starts Minikube and creates a single-node Kubernetes cluster on your local machine. Change into the directory where the is, and run the following command to convert the Docker Compose file to Kubernetes manifests: docker-compose.yml kompose convert This single command generates Kubernetes manifests from your Docker Compose configuration. The output should look similar to this: INFO Kubernetes file "frontend-tcp-service.yaml" created
INFO Kubernetes file "redis-master-service.yaml" created
INFO Kubernetes file "redis-slave-service.yaml" created
INFO Kubernetes file "frontend-deployment.yaml" created
INFO Kubernetes file "redis-master-deployment.yaml" created
INFO Kubernetes file "redis-slave-deployment.yaml" created The manifests have been created, and you can view them using the command. ls To apply these generated manifests to your Kubernetes cluster, use as follows: kubectl apply kubectl apply -f frontend-tcp-service.yaml,redis-master-service.yaml,redis-slave-service.yaml,frontend-deployment.yaml,redis-master-deployment.yaml,redis-slave-deployment.yaml This command will deploy your application on your Kubernetes cluster. The output should indicate that services and deployments have been created. To access your application, you can use the service if you're using Minikube for development: minikube minikube service frontend-tcp After you've finished testing the application, you can clean up the deployed resources using: kubectl delete -f frontend-tcp-service.yaml,redis-master-service.yaml,redis-slave-service.yaml,frontend-deployment.yaml,redis-master-deployment.yaml,redis-slave-deployment.yaml These steps will allow you to convert a Docker Compose configuration to Kubernetes manifests and deploy your application in a Kubernetes cluster using Kompose. Conclusion Kompose is a valuable tool for converting Docker Compose configurations to Kubernetes or OpenShift manifests. It's a versatile tool that can handle Docker Compose files in various versions and is actively maintained by the Kubernetes community. With Kompose, you have a smooth workflow when migrating your container applications from Docker Compose to container orchestration platforms like Kubernetes or OpenShift. In this article, you learned about Kompose and its benefits. You also learned how to install Kompose and use it to generate Kubernetes manifests from a Docker Compose configuration.

How to Generate Kubernetes Manifests With a Single Command

Your team celebrates a success story where a trace identified a pesky latency issue in your application's authentication service. A fix was swiftly implemented, and we all celebrated a quick win in the next team meeting. But the celebrations are short-lived. Just days later, user complaints surged about a related payment gateway timeout. It turns out that the fix we made did improve performance at one point but created a situation in which key information was never cached. Other parts of the react badly to the fix, and we need to revert the whole thing. software While the initial trace provided valuable insights into the authentication service, it didn’t explain why the system was built in this way. Relying solely on a single trace has given us a partial view of a broader problem. This scenario underscores a crucial point: while individual traces are invaluable, their true potential is unlocked only when they are viewed collectively and in context. Let's delve deeper into why a single trace might not be the silver bullet we often hope for and how a more holistic approach to trace analysis can paint a clearer picture of our system's health and the way to combat problems. The Limiting Factor The first problem is the narrow perspective. Imagine debugging a multi-threaded application. If you were to focus only on the behavior of one thread, you might miss how it interacts with others, potentially overlooking deadlocks or race conditions. Java Let's say a trace reveals that a particular method, , is taking longer than expected. By optimizing only this method, you might miss that the real issue is with the synchronized block in another related method, causing thread contention and slowing down the entire system. fetchUserData() Temporal blindness is the second problem. Think of a Java Garbage Collection (GC) log. A single GC event might show a minor pause, but without observing it over time, you won't notice if there's a pattern of increasing pause times indicating a potential memory leak. A trace might show that a Java application's response time spiked at 2 PM. However, without looking at traces over a longer period, you might miss that this spike happens daily, possibly due to a scheduled task or a cron job that's putting undue stress on the system. The last problem is related to that and is the context. Imagine analyzing the performance of a Java method without knowing the volume of data it's processing. A method might seem inefficient, but perhaps it's processing a significantly larger dataset than usual. A single trace might show that a Java method, , took 5 seconds to execute. However, without context, you wouldn't know if it was processing 50 orders or 5,000 orders in that time frame. Another trace might reveal that a related method, , is retrieving an unusually large batch of orders due to a backlog, thus providing context to the initial trace. processOrders() fetchOrdersFromDatabase() Strength in Numbers Think of traces as chapters in a book and metrics as the book's summary. While each chapter (trace) provides detailed insights, the summary (metrics) gives an overarching view. Reading chapters in isolation might lead to missing the plot, but when read in sequence and in tandem with the summary, the story becomes clear. We need this holistic view. If individual traces show that like processTransaction() are occasionally slow, grouped traces might reveal that these slowdowns happen concurrently, pointing to a systemic issue. Metrics, on the other hand, might show a spike in CPU usage during these times, indicating that the system might be CPU-bound during high transaction loads. certain Java methods This helps us distinguish between correlation and causation. Grouped traces might show that every time the method is slow, the method also lags. While this indicates a correlation, metrics might reveal that cache misses (a specific metric) increase during these times, suggesting that database slowdowns might be causing cache update delays, establishing causation. fetchFromDatabase() updateCache() This is especially important in performance tuning. Grouped traces might show that the method's performance has been improving over several releases. Metrics can complement this by showing a decreasing trend in response times and error rates, confirming that recent code optimizations are having a positive impact. handleRequest() I wrote about this extensively in a previous post about the . This motion can be accomplished purely through the use of observability tools such as traces, metrics, and logs. Tong motion needed to isolate an issue Example Observability is somewhat resistant to examples. Everything I try to come up with feels a bit synthetic and unrealistic when I examine it after the fact. Having said that, I looked at my modified version of the venerable Spring Pet Clinic demo using . Running it showed several interesting concepts taken by Digma. digma.ai Probably the most interesting feature is the ability to look at what’s going on in the server at this moment. This is an amazing exploratory tool that provides a holistic view for a moment in time. But the thing I want to focus on is the “Insights” column on the right. Digma tries to combine the separate traces into a coherent narrative. It’s not bad at it, but it’s still a machine. Some of that value should probably still be done manually since it can’t understand the why, only the what. It seems it can detect the venerable Spring seamlessly. N+1 problem But this is only the start. One of my favorite things is the ability to look at tracing data next to a histogram and list of errors in a single view. Is performance impacted because there are errors? How impactful is the performance on the rest of the application? These become questions with easy answers at this point when we see all the different aspects laid together. Magical APIs The N+1 problem I mentioned before is a common bug in . The great Vlad Mihalcea has . The TL;DR is rather simple. We write a simple database query using ORM. But we accidentally split the transaction, causing the data to be fetched N+1 times, where N is the number of records we fetch. Java Persistence API (JPA) an excellent explanation This is painfully easy to do since transactions are so seamless in JPA. This is the biggest problem in “magical” APIs like JPA. These are APIs that do so much that they feel like magic, but under the hood, they still run regular old code. When that code fails, it’s very hard to see what goes on. Observability is one of the best ways to understand why these things fail. In the past, I used to reach to the profiler for such things, which would often entail a lot of work. Getting the right synthetic environment for running a profiling session is often very challenging. Observability lets us do that without the hassle. Final Word Relying on a single individual trace is akin to navigating a vast terrain with just a flashlight. While these traces offer valuable insights, their true potential is only realized when viewed collectively. The limitations of a single trace, such as a narrow perspective, temporal blindness, and lack of context, can often lead developers astray, causing them to miss broader systemic issues. On the other hand, the combined power of grouped traces and metrics offers a panoramic view of system health. Together, they allow for a holistic understanding, precise correlation of issues, performance benchmarking, and enhanced troubleshooting. For this tandem approach ensures a comprehensive and nuanced understanding of applications, optimizing both performance and user experience. In essence, while individual traces are the chapters of our software story, it's only when they're read in sequence and in tandem with metrics that the full narrative comes to life. Java developers, Also published . here

Not A Single Trace: The True Story of Java Performance

In the rapidly evolving landscape of artificial intelligence (AI), training models to perform specific tasks has always been a challenging endeavor. The complexities involved in collecting and preprocessing datasets, selecting suitable models, and writing and executing training code have often discouraged even seasoned developers from venturing into the realm of model creation. However, a promising new project is on the horizon, aiming to revolutionize this process and make it accessible to a wider audience. Enter get-LLM-trainer, an open-source tool designed to simplify the process of training high-performing task-specific models using a novel and experimental approach. AI The Struggle with Traditional Model Training Traditionally, training has been an intricate and multifaceted process, demanding expertise in data collection, preprocessing, coding, and model selection. A successful model requires a meticulously curated dataset formatted to the model’s specifications and a coherent training script that fine-tunes the model on the provided data. In the best-case scenario, this journey involves multiple steps, each fraught with challenges and intricacies. The complexity of this process has often acted as a deterrent for many enthusiasts and professionals alike, limiting the pool of individuals who can actively contribute to AI advancements. AI models A Glimpse into the Future: gpt-llm-trainer The gpt-llm-trainer project takes a bold step toward democratizing AI model training. The project’s primary objective is to simplify the journey from an idea to a fully-trained, high-performing model. Imagine a world where you can articulate your task’s description and have an AI-powered system take care of the rest. This is the driving force behind gpt-llm-trainer, an experimental pipeline that seeks to abstract away the complexities of model training. The project operates on a straightforward principle: You provide a description of the task you want your AI model to perform, and the magic begins. Behind the scenes, a chain of AI systems collaborates seamlessly to generate a dataset from scratch. This dataset is then meticulously formatted to align with the model’s requirements. Once the dataset is prepared, gpt-llm-trainer employs the powerful capabilities of to generate a variety of prompts and responses based on your provided use case, thereby expanding the model’s comprehension of potential interactions. GPT-4 The Core Features of gpt-llm-trainer At the heart of gpt-llm-trainer lies its ability to generate datasets using the advanced GPT-4 model. This eliminates the need for painstaking manual data collection and preprocessing. The project leverages GPT-4’s text generation prowess to create a diverse range of prompts and responses tailored to your task. This novel approach ensures that your model is exposed to a wide variety of training examples, enhancing its adaptability and performance. Dataset Generation Crafting an effective system prompt is a crucial step in AI model training. Gpt-llm-trainer streamlines this process by autonomously generating system prompts that resonate with your task’s context. This removes the burden of manually crafting suitable prompts, ensuring that your model’s training process is both efficient and effective. System Message Generation After the dataset and system prompts have been generated, gpt-llm-trainer takes the reins in the fine-tuning process. It automatically splits the dataset into training and validation sets, ensuring a robust evaluation of the model’s performance. Using this split dataset, the tool initiates the fine-tuning process on a cutting-edge model — the LLaMA 2 model. This fine-tuning step is essential for adapting the general language model to the task-specific domain, ultimately leading to a more accurate and relevant model. Fine-Tuning Made Effortless Embracing Accessibility: The Google Colab Notebook To further amplify gpt-llm-trainer’s accessibility, the project provides a Google Colab notebook in its . This notebook offers a user-friendly interface that simplifies the interaction with the tool. Whether you are an AI novice or a seasoned practitioner, the notebook guides you through the process, from inputting your task description to witnessing the model’s inference capabilities. GitHub repository Embracing Experimentation It’s important to note that gpt-llm-trainer is an experimental project. It represents a bold step toward simplifying AI model training, but it’s still in its early stages. As with any emerging technology, there might be limitations and areas for improvement. However, this experimental nature signifies an exciting opportunity for the AI community to contribute, provide feedback, and collectively shape the future of effortless model training. Conclusion The gpt-llm-trainer project is a beacon of hope for anyone interested in AI model training but hesitant due to its inherent complexities. By abstracting away the intricacies of data collection, preprocessing, system prompt generation, and fine-tuning, this project opens doors to a wider audience, from enthusiastic beginners to seasoned experts. Its integration of GPT-4’s capabilities and the innovative LLaMA 2 model underscores its commitment to achieving high-performing task-specific models with minimal barriers. As you embark on your journey to explore gpt-llm-trainer, remember that you’re not only engaging with a tool but also contributing to an evolving landscape of AI advancement. With the provided notebook and the project’s repository at your disposal, you’re equipped to dive into this experimental approach to AI model training. Exciting times lie ahead as we witness the transformation of complex processes into intuitive experiences powered by the ingenuity of projects like gpt-llm-trainer. Google Colab To explore the project and join the conversation, visit the gpt-llm-trainer GitHub repository: https://github.com/mshumer/gpt-llm-trainer?embedable=true Also published . here

GPT-LLM Trainer: Enabling Task-Specific LLM Training with a Single Sentence

In this article, you will learn about the following: What is SRP? Importance of SRP in software development Strengths Weaknesses Twitter Registration What Is SRP? The Single Responsibility Principle (SRP) is one of the five SOLID design principles that guide software development. : A class or module should have only one reason to change. Definition The principle states that a class should have only one reason to change and one responsibility. This principle is intended to promote modularity and help developers create easier code to understand, modify, and maintain. In essence, the SRP states that each class should have a single, well-defined responsibility and that responsibility should be encapsulated within that class. This means that a class should not have multiple responsibilities, as this can make it harder to understand and modify. By following the SRP, developers can create more maintainable and flexible code that is easier to work with over time. The SRP is a fundamental principle in object-oriented programming, and it can significantly impact the quality and effectiveness of software development. We will explore the SRP in more detail, including how it works, why it is important, and how to apply it effectively in Java programming. Importance of SRP in Software Development There are several reasons why SRP is important in software development: : Reading and understanding the code becomes easier when each class or module has a single responsibility. This helps developers quickly understand the purpose of the class or module and its relationship with other parts of the system. Enhances code readability : By breaking down complex functionality into smaller, more focused modules, SRP enables developers to make changes to the code more easily without affecting other parts of the system. This means that maintenance and troubleshooting of the code become less time-consuming and costly. Increases code maintainability : Code that adheres to SRP is often more modular and reusable. This means developers can easily reuse the code in other parts of the system or projects. Facilitates code reuse : Maintaining a single responsibility for each class or module becomes increasingly important as the codebase grows. SRP ensures that the codebase remains scalable and can easily accommodate changes or new features without impacting the rest of the system. Improves system scalability Overall, adhering to the Single Responsibility Principle improves the quality and maintainability of the codebase, making it easier to manage, test, and deploy. Advantages The advantages of following the Single Responsibility Principle (SRP) include the following: Better code organization and maintainability. Improved readability and understanding of code. Easier debugging and testing of code. A higher degree of code reusability. Facilitation of parallel development and implementation of new features. Ability to make changes to code with less risk of introducing bugs. Disadvantages Some of the disadvantages of the Single Responsibility Principle (SRP) include the following: Increased complexity, as a system may require more classes to implement the same functionality. Potential for over-engineering, leading to too much abstraction and unnecessary code. Difficulties in determining the appropriate granularity of responsibilities. Challenges in balancing the trade-off between separating responsibilities and maintaining performance. When programmers try to add features or new behavior to a software product, they frequently integrate everything within the current class. When something needs to be changed later, due to the complexity of the code, the code refactor process is extremely time-consuming and tedious. The Single Responsibility Principle helps us create simple classes that perform just one task. This helps make modifications or adding extensions to the existing code much more effortless. Twitter Registration Using Single Responsibility Principle We design Twitter registration software with the help of the single responsibility principle that contains a notification service, database repository, account service, and execution class. Let's implement the first design principle on Twitter registration flow. 🔐 Signup Process on Twitter Consider a use case where a user wants to register with Twitter. The steps Twitter takes to register are user are: Twitter asks users to register with signup forms. Twitter stores the user object in its database, which contains details - , , , and other metadata, etc. User email name password Twitter sends a welcome message to the user. Let us declare a class that does the above steps. public class TwitterRegistration {
    public void register() {
        // step 1
        System.out.println("Fill signup form");

        // step 2
        System.out.println("Store account details in database");

        // step 3
        System.out.println("Send a welcome message");
    }
} We are creating an account on Twitter, and the three steps should be handled separately. But the above class declared them all in a single class. Isn't this a violation of SRP? TwitterRegistration Also, step 2 of storing an object in the database requires additional work to open a connection with the database, authenticate the handshake, and store the user object. This is insertion logic and should be handled separately. The third step is sending out a welcome message to the user, which should be handled by , separately. NotificationService Using the SRP principle, we divide the above class into three different classes, each having a single and only one responsibility. TwitterRegistration Refactoring for SRP Refactoring TwitterRegistration the class gives: // Notification Service
class NotificationService {
    public void sendNotification() {
        // step 3
        System.out.println("Send out welcome message");
    }
} // Database handshakes
class AccountRepository {
    public void createUser() {
        // step 2
        System.out.println("🔐 Auth Success!");
        System.out.println("Store user data into database");
    }
} // Account Registration
class TwitterAccountRegister {
    public void registerUser() {
        // step 1
        System.out.println("fill account internal details");
    }
} Finally, after refactoring the above classes. We first allow the to create a couple of objects for and to register users with Twitter. TwitterAccountService AccountRepository NotificationService // Execution Class or Main class
public class TwitterAccountRegister {
    public static void main(String[] args) {
        TwitterAccountService service = new TwitterAccountService();
        service.registerUser();
    }
}

// Account Registration Service
class TwitterAccountService {
    AccountRepository repository = new AccountRepository();
    NotificationService notificationService = new NotificationService();

    public void registerUser() {
        // step 1
        System.out.println("fill account internal details");

        repository.createUser();
        notificationService.sendNotification();
    }
}

// Notification Service
class NotificationService {
    public void sendNotification() {
        // step 3
        System.out.println("Send out welcome message");
    }
}

// Database handshakes
class AccountRepository {
    public void createUser() {
        // step 2
        System.out.println("🔐Signup Success!! Registered");
        System.out.println("Store user data into database");
    }
}

/*
Outputs:
fill account internal details
🔐Signup Success!! Registered
Store user data into database
Send out welcome message
*/ In above, is doing all three tasks. The primary responsibility is to fill in account details in account details and delegate the other responsibilities to other classes. TwitterAccountService Finally, we know many teams work on the same software product. , By following the SRP principle, if we see file changes in GitHub for a file named TweetAnalytics we can be sure that the changes incorporated are related to analytics. This helps version control with ease. Conclusion In conclusion, the Single Responsibility Principle (SRP) is a software design principle that states that every class should have only one reason to change. Following SRP makes code easier to understand, maintain, and extend. It reduces the risk of introducing bugs and makes it easier to test individual components in isolation. SRP encourages the separation of concerns, making the code more modular and scalable. This principle is one of the five SOLID principles of object-oriented design and is an important aspect of creating clean, maintainable, and scalable code. You will get the complete written notes @ <https://www.ggorantala.dev/ ](https://www.ggorantala.dev/) Also published here

SOLID: Learn About the Single Responsibility Principle With Examples

Lawyers, accountants, and marketers can learn a lot from Fortnite and Donkey Kong Too many professional services firms are approaching today’s world of -like complexity with strategies more appropriate for Donkey Kong. Fortnite Here’s what’s going on. Web1 games and arcades The concept behind the classic video game Donkey Kong is simple. For 25 cents at an arcade, a player could guide the hero, , up the girders and ladders of a construction site to rescue the distressed Pauline, who was being held hostage by Donkey Kong, a giant scary ape (though actually the protagonist if you know the actual backstory). Along the way, poor Mario would have to jump over or destroy obstacles like barrels and fireballs that Donkey Kong at the top of the steel tower rolled his way. Mario The whole thing took place in two highly pixelated dimensions and four colors, pitting the player against the CPU-controlled ape. The game was the cutting-edge star of the early 1980s vibrant arcade scene. By today’s standards, it looks painfully dated, but the franchise became a cultural icon, spawning films, and fashion trends. The podcast Acquired has a great rundown of the game in the context of the history of . We can’t Nintendo recommend it enough. Enter... more players Fortnite, in contrast, is much more sophisticated. And Acquired does a great job with that larger . story too The game presents three-dimensional hybrid worlds featuring zombies, traps, and fights to the death against dozens of live players who are simultaneously online anywhere around the world. Within months of its release, Fortnite — which can be played on any major computer or gaming format — had become a true cultural . Four years later, it remains on the cutting edge. phenomenon We could keep going with the evolution of this process by tackling Roblox, but let’s keep it to these two. So, you’re going to extend the analogy to lawyers? Now let’s apply this contrast to our industry (marketing) and other professional services like fund administration for instance. In fact, let’s focus on fund services where interesting things are afoot. Fund services are generally the outsourced partner accounting and operations work of venture capital and private equity firms. One can view fund services as a series of individual workflows. Composing these workflows are many tasks related to each stage of a particular service. Each stage may include numerous financial reviews and revisions, like attorney approvals, name corrections, and adding phrases here or there to documents, before the service can move forward to its completion. The process is like an assembly line. It’s Donkey Kong. Serial work vs. parallel processing Automation makes the process easier and faster. An assembly line worker who has been manually installing rivets will be more productive with an electric rivet gun. It’s much more efficient. But it’s still an assembly line. It still requires the worker responsible for one stage of service to complete the job before passing his work along to the next stage. It’s still Donkey Kong. Most financial services software reflects the pitfalls of the single-player approach. Single-player software is helpful because one person can go in, do his or her work, and leave so someone else can enter and complete the next step. It’s orderly. But it’s also limited. Project leaders and team members, for example, don’t necessarily know where things stand, for anything at any given point, unless they are in the application. None of the people involved knows where they are in the workflow until everything is completed. In a multi-player professional service or fund administration model that resembles Fortnite, in contrast, far fewer people must wait for someone else to complete their job before another phase can begin. Numerous people can be in an application or document at the same time. Anyone given access can make necessary changes and everyone can see what everyone is doing. Let the adventure begin! Multiple actors can simultaneously review and amend documents. Everyone is always dealing with the current version of the text. It doesn’t matter if they are internal, external, or from a third party. It doesn’t matter if they are in the same place or working from points scattered around the globe. Everybody sees the dialogue and decisions that are being made in real-time. Monitoring progress is built-in, making it easier to understand the status of a process at any time. It’s Fortnite. In Donkey Kong, Mario could only ever rescue Pauline. In Fortnite, you can do so much more. Real-world Here’s how it applies to fund services for example: In a single-player financial tech application, a financial services provider can see a document that a limited partnership has sent, verify the data and note that lawyers have signed off on it. When it's a multiplayer system, the fund services partner can see and do all of those tasks but also observe delays or problems across limited partnerships and, importantly, intervene and act quickly to fix them. In addition to the fund services partner understanding where tasks are within the flow, they have full audit control with transparency across all parties in the flow. This is where leaders in the industry like 4Pines Fund Services come in. In the software development world, the multiplayer approach is not particularly new. But it was rare in the private equity industry — up until recently. These kinds of changes are generating a buzz as budgets and operations are getting more focused. This is only going to increase. This is also where a co-sourcing approach to data and cutting-edge fund administration tech stack comes in, for example, to fix real problems. You’re working to close communication gaps and fix transparency issues between fund managers, investors, and service providers. Most importantly, you’re helping chief financial officers and general partners to identify bottlenecks and key performance indicators to improve speed and efficiency. The automated system reduces human error significantly at critical points within clients’ workflows. Everything is near-instantly trackable, traceable, and auditable. Fund administrators and private equity managers seeking the most innovative professional services are opting for the multiplayer approach. And this is happening in marketing and legal services. In private capital, it improves communication between general partners, limited partners, and analysts. It efficiently shepherds sub-docs and other correspondence and compliance through quick and efficient approval processes.  It replaces slow pipelines and obstacles with the latest technologies and solutions that keep fund services running flexibly, seamlessly, and dependably. So what about your industry? Are you ready to play at a higher level? You’d better be. Featured photo: Desi Krasteva Gale

Multiplayer Professional Services Are Eclipsing the Single-Player Variety, and It’s About Time

Los servicios profesionales multijugador están eclipsando la variedad de un solo jugador, y ya era hora

Les services professionnels multijoueurs éclipsent la variété solo, et il était temps

मल्टीप्लेयर व्यावसायिक सेवाएँ एकल-खिलाड़ी विविधता को ग्रहण कर रही हैं, और यह समय की बात है

マルチプレイヤーのプロフェッショナル サービスがシングルプレイヤーの種類を追い越しつつあり、そろそろその時が来ています

Os serviços profissionais multijogador estão eclipsando a variedade de jogador único e já era hora

Các dịch vụ chuyên nghiệp nhiều người chơi đang làm lu mờ sự đa dạng của một người chơi và đã đến lúc

多人游戏专业服务正在让单人游戏种类黯然失色，现在正是时候

Ory Hydra is a popular open-source OAuth2 and OpenID Connect that provides secure authentication and authorization for applications. One of the key challenges in building a scalable and performant OAuth2 server is managing the persistence layer, which involves storing and retrieving data from a database. server Motivation Ory was approached by a popular service provider to optimize performance in their auth system at high load. They often struggled to cope with the huge influx of authorization grants during peak times (over 600logins/sec). Looking for another solution, they started to evaluate Ory Hydra, investigating if it can handle this amount of grants. After reaching out to the team, we started to investigate ways to improve the overall performance to make Ory Hydra faster and more scalable than ever before. The key to success was to re-engineer parts of Hydra's persistence layer to reduce write traffic to the database, moving to a transient OAuth2 flow. Moving to a transient OAuth2 flow One of the core parts of this work was moving a large chunk of the transient OAuth2 flow state, which is exchanged between the three parties involved in an OAuth2 flow, from the server to the client. Instead of persisting transient state to the database, the state is now passed between the parties as either AEAD-encoded cookies or AEAD-encoded query parameters in redirect URLs. AEAD stands for authenticated encryption with associated data, which means that the data is confidential and also can't be tampered with without knowing a secret (symmetric) key. The flow is then only persisted in the database once when the final consent is given. This change has several benefits. First, it reduces the amount of data that needs to be stored in the database, which in turn reduces write traffic. Second, it eliminates the need for multiple indices on the flow table that were previously used during the exchange. The OAuth2 authorization code grant flow in detail The relevant part of the OAuth2 flow that we wanted to optimize is an exchange between the client (acting on behalf of a user), Hydra (Ory's OAuth2 Authorization Server), and the login and consent screens. When a client requests an authorization code through the , the user will be redirected first to the login UI to authenticate and then to the consent UI to grant access to the user's data (such as the email address or profile information). Authorization Code Grant Below is a sequence diagram of the exchange. Observe that each UI gets a as part of the URL parameters (steps 3 and 12) and then uses this as a parameter to retrieve more information (steps 4 and 13). Finally, both UIs either accept or reject the user request, usually based on user interaction with the UI (from steps 6 to 8 and 15 to 17). This API contract keeps Ory Hydra headless and decoupled from custom UIs. CHALLENGE CHALLENGE Optimization: Passing the AEAD-encoded flow in the URL parameters To reduce database access we now pass as the , , , and an AEAD-encoded flow. This way, we rely on the parties involved in the OAuth2 flow to pass the relevant state along. LOGIN_CHALLENGE LOGIN_VERIFIER CONSENT_CHALLENGE CONSENT_VERIFIER Before After The login and consent challenges and verifiers are random UUIDs stored in the database. The login and consent challenges and verifiers are the AEAD-encoded flow. Accepting or rejecting a request from the UI involves a database lookup for the specific challenge. Accepting or rejecting a request from the UI involves decrypting the flow in the challenge and generating an updated flow as part of the verifier. Implementation Since Ory Hydra is open source, you can review code changes in the Ory GitHub repositories. This is the relevant . commit Here is where we encode the flow in the specific challenges and verifiers: // ToLoginChallenge converts the flow into a login challenge.
func (f *Flow) ToLoginChallenge(ctx context.Context, cipherProvider CipherProvider) (string, error) {
    return flowctx.Encode(ctx, cipherProvider.FlowCipher(), f, flowctx.AsLoginChallenge)
}

// ToLoginVerifier converts the flow into a login verifier.
func (f *Flow) ToLoginVerifier(ctx context.Context, cipherProvider CipherProvider) (string, error) {
    return flowctx.Encode(ctx, cipherProvider.FlowCipher(), f, flowctx.AsLoginVerifier)
}

// ToConsentChallenge converts the flow into a consent challenge.
func (f *Flow) ToConsentChallenge(ctx context.Context, cipherProvider CipherProvider) (string, error) {
    return flowctx.Encode(ctx, cipherProvider.FlowCipher(), f, flowctx.AsConsentChallenge)
}

// ToConsentVerifier converts the flow into a consent verifier.
func (f *Flow) ToConsentVerifier(ctx context.Context, cipherProvider CipherProvider) (string, error) {
    return flowctx.Encode(ctx, cipherProvider.FlowCipher(), f, flowctx.AsConsentVerifier)
} In the persister (our database repository) we then decode the flow contained in the challenge. For example, here's the code for handling a consent challenge: func (p *Persister) GetFlowByConsentChallenge(ctx context.Context, challenge string) (*flow.Flow, error) {
    ctx, span := p.r.Tracer(ctx).Tracer().Start(ctx, "persistence.sql.GetFlowByConsentChallenge")
    defer span.End()

    // challenge contains the flow.
    f, err := flowctx.Decode[flow.Flow](ctx, p.r.FlowCipher(), challenge, flowctx.AsConsentChallenge)
    if err != nil {
        return nil, errorsx.WithStack(x.ErrNotFound)
    }
    if f.NID != p.NetworkID(ctx) {
        return nil, errorsx.WithStack(x.ErrNotFound)
    }
    if f.RequestedAt.Add(p.config.ConsentRequestMaxAge(ctx)).Before(time.Now()) {
        return nil, errorsx.WithStack(fosite.ErrRequestUnauthorized.WithHint("The consent request has expired, please try again."))
    }

    return f, nil
} Let's look at the impact of the changes when compared to the code without optimizations: The flows are now much faster and talk less to the database. Improved indices lead to further performance improvements By introducing a new index on the table, we were able to increase throughput and decrease CPU usage on PostgreSQL. The screenshot below shows the execution of the benchmarks without the improved indices where CPU usage spikes to 100%, and with improved indices, where CPU usage stays below 10%. hydra_oauth2_flow With the newly added indices, CPU usage (green bars) is removed, which reduces the likelihood of BufferLocks and related issues: Results The code and database changes reduced the total roundtrips to the database by 4-5x (depending on the amount of caching done) and reduced database writes by about 50%. Benchmarks Benchmarking the new implementation on Microsoft Azure with the following specifications: Services Configuration Total max SQL connections Notes Ory Hydra Consent App OAuth2 Client App rakyll/hey (http benchmark tool) 3x Standard_D32as_v4; South Central US 5x Standard_D8s_v3; South Central US 512 Every VM ran all the processes mentioned. PostgreSQL 14 in HA configuration Memory Optimized, E64ds_v4, 64 vCores, 432 GiB RAM, 32767 GiB storage; South Central US RAM beats CPU. Ory can perform up to at the peak and in the above configuration. This is possible by making the flow stateless and optimizing indices in frequently used queries. 1090 logins per second 800 logins / second consistently Conclusion The performance optimization work done by the Ory team has resulted in a significant improvement in Hydra's performance and scalability. By reducing write traffic to the database and improving the codebase and dependencies, Hydra is now faster and more responsive than ever before. By improving the indices, Hydra now scales much more efficiently with the number of instances. In the future, we will continue to optimize Ory's software to handle even more traffic. We believe that it's possible to get 5x more throughput on a single PostgreSQL node with data model optimizations. If you're building an OAuth2 server, we highly recommend giving Ory's fully certified OpenID Connect and OAuth2 implementations a try: Ory OAuth2 – our running on the global Ory Network, based on Ory Hydra – already utilizes the optimizations described in this article and setting it up only takes few minutes! fully managed service open source Also published . here

Scaling Ory Hydra to Two Billion Monthly OAuth2 Flows on a Single PostgreSQL DB

Escalamiento de Ory Hydra a dos mil millones de flujos mensuales de OAuth2 en una única base de datos de PostgreSQL

Mise à l'échelle d'Ory Hydra à deux milliards de flux OAuth2 mensuels sur une seule base de données PostgreSQL

सिंगल पोस्टग्रेएसक्यूएल डीबी पर ओरी हाइड्रा को दो बिलियन मासिक OAuth2 फ्लो तक स्केल करना

Ory Hydra を単一の PostgreSQL DB で月間 20 億の OAuth2 フローに拡張

Dimensionando o Ory Hydra para dois bilhões de fluxos OAuth2 mensais em um único banco de dados PostgreSQL

Mở rộng quy mô Ory Hydra lên hai tỷ luồng OAuth2 hàng tháng trên một cơ sở dữ liệu PostgreSQL

在单个 PostgreSQL 数据库上将 Ory Hydra 扩展到每月 20 亿个 OAuth2 流量

CEOs are trying to squeeze out with smaller budgets, despite ongoing supply chain snags and amid questions on rates and inflation. They are undertaking major overhauls of their sales and marketing strategies as what seem to be the last vestiges of physical commerce online. opportunities migrate Now many companies are discovering that, while they have prioritized the reinvention of customer-facing products like websites and webinars, they don’t necessarily have the foundations that allow them to capitalize on the new tools they’ve created. On one hand, they’ve embarked on digital restarts in order to keep pace with the competition. On the other, they now fear a digital nightmare as the web-portal façade of their business shows signs of strain as they rush to deliver at the new pace of sales that their digital strategy has delivered. Executives who might feel as if they are frauds because they're in this predicament aren’t alone. Many CEOs are realizing they’ve been underinvesting in the core operational processes and technologies necessary to efficiently and effectively turn around quotes and deliver products in an increasingly dynamic world even as they’ve kept pace with and similar developments in their plants. They need tools to marry their front-end and back-end capabilities, in other words. Industry 4.0 The solution lies in unified e-commerce platforms, or one-stop-shop applications that can be customized to specific businesses to manage B2B and B2C transactions, sales orders, marketplaces, and vendors in a manner that integrates with enterprise resource planning, from supply chain oversight to human resources. Questions, questions, questions… The following questions can help CEOs to understand how to become heroes in this era digital transformation. Do your supply chains operate with resiliency and flexibility? Do they meet customer needs and at the same time cope with constant, fast-changing market conditions? Having easy-to-use order management, e-commerce, organized data streams, and constant access enables visibility, efficiency, flexibility and the power to anticipate product lifecycles, delivery speeds and market demand for personalization and customization. The goal is not necessarily to know more about supply chains. It’s about knowing how to manage supply chains in order to deliver products consistently. Much of that information is already within a company’s daily business flows. But many companies lack e-commerce solutions that help them unlock the insights that would help them overcome supply chain challenges. Do you have cloud-based enterprise commerce systems and processes? Can you deliver data visibility and integrity across core operations? Enterprise commerce sits at the heart of the business. It needs to be customized to the way your company works. In manufacturing, SymphonyAI has pointed out it’s not enough to have automation. It has to be tuned to the culture and capacity of your business to incorporate automation into workflows. Otherwise, your business will pay a price with employee . The same goes for order management and commerce. Can you enable leading edge decision-making to unlock realistic innovation and drive growth? burnout Are you leveraging a complete technology approach effectively to unlock performance efficiencies and ownership mindsets in your talent? The U.S. rate of employee churn across industries is 22 percent. CEOs understand this well. Replacing a frontline employee can cost of what would be paid in wages if they stayed. Finding more senior level professionals can cost six to nine of their salary. problem sixteen percent months Communications is perhaps the best way to retain talent. Forrester in the early days of the pandemic, for example, only about 43 percent of employees believed their organization had a plan for what was happening. Getting that right made it easier for executives to focus on customers and other stakeholders. Finally, installing a business continuity plan for the duration based on strong employee communications and performance loops delivers value. found Finally, can your business support your customers’ drive to take control of configuring and pricing complex products and services and get the self-help and support they want digitally? If you want to optimize revenue, you will need to offer up and refine a low friction buyer and customer experience. Get this right, and you will also gain normalized useful data you can invest downstream in business and financial functions, in addition to learning about your customers and monetizing what you see. Mark Nathan at Zipari has been a pioneer in this area for the many manufacturers look to for their teams. health insurance Unified commerce These core operational processes define intelligent, integrated and agile cloud-savvy businesses. Direct digital transformation investments are expected to total $6.8 trillion globally between 2020 and 2023. That’s a compound annual growth rate of almost 16 percent, to IDC. What’s called the digital transformation services market is forecasted to reach $186 billion by . according 2024 Moving computing power off company-owned machines and onto more nimble cloud-based services is the evolution that every industry is undergoing at present. Gartner that global spending on cloud services will approach $400 billion next year. That’s almost a 50 percent increase compared to last year. predicts And yet spending money does not equate becoming a new hero of the digital restart. It takes more than cash to overcome the struggle with legacy technological debt. Beyond technology, the emerging digital manufacturing leaders are also looking at the organizational, process and cultural foundations of their businesses. Asking these questions starts companies on the right path. What’s next? The result is avoiding lost sales opportunities, distribution shortfalls, inconsistent financial management, sub-optimal resource planning and high employee turnover. Making all this happen, frankly, will take more than the services of most consultancies today. Staffing agencies masquerading as true business partners won’t cut it. And few digital transformation prophets are purpose-built to innovate the next generation of digital operating platforms for the next generation of commercial pioneers. But the market has a way of pulling forward what it needs to move to the next level. CEOs can and will rise to the challenge of satisfying record high while simultaneously harnessing the technology of the future. demand

The Online Industrial Experience Is Gravitating Toward A Single Screen

অনলাইন শিল্প অভিজ্ঞতা একটি একক পর্দার দিকে অভিকর্ষজ করছে৷

Das Online-Industrieerlebnis tendiert immer mehr zu einem einzigen Bildschirm

La experiencia industrial en línea está gravitando hacia una sola pantalla

L'expérience industrielle en ligne gravite vers un écran unique

ऑनलाइन औद्योगिक अनुभव सिंगल स्क्रीन की ओर बढ़ रहा है

オンラインの産業体験は単一の画面に引き寄せられています

온라인 산업 경험은 단일 화면으로 향하고 있습니다.

A experiência industrial online está gravitando em direção a uma única tela

Çevrimiçi Endüstriyel Deneyim Tek Ekrana Yönleniyor

Trải nghiệm công nghiệp trực tuyến đang hướng tới một màn hình duy nhất

在线工业体验正趋向单一屏幕

The Mysterious Island by Jules Verne, is part of the HackerNoon Books Series. You can jump to any chapter in this book . Chapter XXI here Chapter XXI From this time Pencroft did not let a single day pass without going to visit what he gravely called his “corn-field.” And woe to the insects which dared to venture there! No mercy was shown them. Towards the end of the month of June, after incessant rain, the weather became decidedly colder, and on the 29th a Fahrenheit thermometer would certainly have announced only twenty degrees above zero, that is considerably below the freezing-point. The next day, the 30th of June, the day which corresponds to the 31st of December in the northern year, was a Friday. Neb remarked that the year finished on a bad day, but Pencroft replied that naturally the next would begin on a good one, which was better. At any rate it commenced by very severe cold. Ice accumulated at the mouth of the Mercy, and it was not long before the whole expanse of the lake was frozen. The settlers had frequently been obliged to renew their store of wood. Pencroft also had wisely not waited till the river was frozen, but had brought enormous rafts of wood to their destination. The current was an indefatigable moving power, and it was employed in conveying the floating wood to the moment when the frost enchained it. To the fuel which was so abundantly supplied by the forest, they added several cartloads of coal, which had to be brought from the foot of the spurs of Mount Franklin. The powerful heat of the coal was greatly appreciated in the low temperature, which on the 4th of July fell to eight degrees of Fahrenheit, that is, thirteen degrees below zero. A second fireplace had been established in the dining-room, where they all worked together at their different avocations. During this period of cold, Cyrus Harding had great cause to congratulate himself on having brought to Granite House the little stream of water from Lake Grant. Taken below the frozen surface, and conducted through the passage, it preserved its fluidity, and arrived at an interior reservoir which had been hollowed out at the back part of the storeroom, while the overflow ran through the well to the sea. About this time, the weather being extremely dry, the colonists, clothed as warmly as possible, resolved to devote a day to the exploration of that part of the island between the Mercy and Claw Cape. It was a wide extent of marshy land, and they would probably find good sport, for water-birds ought to swarm there. They reckoned that it would be about eight or nine miles to go there, and as much to return, so that the whole of the day would be occupied. As an unknown part of the island was about to be explored, the whole colony took part in the expedition. Accordingly, on the 5th of July, at six o’clock in the morning, when day had scarcely broken, Cyrus Harding, Gideon Spilett, Herbert, Neb, and Pencroft, armed with spears, snares, bows and arrows, and provided with provisions, left Granite House, preceded by Top, who bounded before them. Their shortest way was to cross the Mercy on the ice, which then covered it. “But,” as the engineer justly observed, “that could not take the place of a regular bridge!” So, the construction of a regular bridge was noted in the list of future works. It was the first time that the settlers had set foot on the right bank of the Mercy, and ventured into the midst of those gigantic and superb coniferae now sprinkled over with snow. But they had not gone half a mile when from a thicket a whole family of quadrupeds, who had made a home there, disturbed by Top, rushed forth into the open country. “Ah! I should say those are foxes!” cried Herbert, when he saw the troop rapidly decamping. They were foxes, but of a very large size, who uttered a sort of barking, at which Top seemed to be very much astonished, for he stopped short in the chase, and gave the swift animals time to disappear. The dog had reason to be surprised, as he did not know Natural History. But, by their barking, these foxes, with reddish-gray hair, black tails terminating in a white tuft, had betrayed their origin. So Herbert was able, without hesitating, to give them their real name of “Arctic foxes.” They are frequently met with in Chile, in the Falkland Islands, and in all parts of America traversed by the thirtieth and fortieth parallels. Herbert much regretted that Top had not been able to catch one of these carnivora. “Are they good to eat?” asked Pencroft, who only regarded the representatives of the fauna in the island from one special point of view. “No,” replied Herbert; “but zoologists have not yet found out if the eye of these foxes is diurnal or nocturnal, or whether it is correct to class them in the genus dog, properly so called.” Harding could not help smiling on hearing the lad’s reflection, which showed a thoughtful mind. As to the sailor, from the moment when he found that the foxes were not classed in the genus eatable, they were nothing to him. However, when a poultry-yard was established at Granite House, he observed that it would be best to take some precautions against a probable visit from these four-legged plunderers, and no one disputed this. After having turned the point, the settlers saw a long beach washed by the open sea. It was then eight o’clock in the morning. The sky was very clear, as it often is after prolonged cold; but warmed by their walk, neither Harding nor his companions felt the sharpness of the atmosphere too severely. Besides there was no wind, which made it much more bearable. A brilliant sun, but without any calorific action, was just issuing from the ocean. The sea was as tranquil and blue as that of a Mediterranean gulf, when the sky is clear. Claw Cape, bent in the form of a yataghan, tapered away nearly four miles to the southeast. To the left the edge of the marsh was abruptly ended by a little point. Certainly, in this part of Union Bay, which nothing sheltered from the open sea, not even a sandbank, ships beaten by the east winds would have found no shelter. They perceived by the tranquillity of the sea, in which no shallows troubled the waters, by its uniform color, which was stained by no yellow shades, by the absence of even a reef, that the coast was steep and that the ocean there covered a deep abyss. Behind in the west, but at a distance of four miles, rose the first trees of the forests of the Far West. They might have believed themselves to be on the desolate coast of some island in the Antarctic regions which the ice had invaded. The colonists halted at this place for breakfast. A fire of brushwood and dried seaweed was lighted, and Neb prepared the breakfast of cold meat, to which he added some cups of Oswego tea. While eating they looked around them. This part of Lincoln Island was very sterile, and contrasted with all the western part. The reporter was thus led to observe that if chance had thrown them at first on the shore, they would have had but a deplorable idea of their future domain. “I believe that we should not have been able to reach it,” replied the engineer, “for the sea is deep, and there is not a rock on which we could have taken refuge. Before Granite House, at least, there were sandbanks, an islet, which multiplied our chances of safety. Here, nothing but the depths!” “It is singular enough,” remarked Spilett, “that this comparatively small island should present such varied ground. This diversity of aspect, logically only belongs to continents of a certain extent. One would really say, that the western part of Lincoln Island, so rich and so fertile, is washed by the warm waters of the Gulf of Mexico, and that its shores to the north and the southeast extend over a sort of Arctic sea.” “You are right, my dear Spilett,” replied Cyrus Harding, “I have also observed this. I think the form and also the nature of this island strange. It is a summary of all the aspects which a continent presents, and I should not be surprised if it was a continent formerly.” “What! a continent in the middle of the Pacific?” cried Pencroft. “Why not?” replied Cyrus Harding. “Why should not Australia, New Ireland, Australasia, united to the archipelagoes of the Pacific, have once formed a sixth part of the world, as important as Europe or Asia, as Africa or the two Americas? To my mind, it is quite possible that all these islands, emerging from this vast ocean, are but the summits of a continent, now submerged, but which was above the waters at a prehistoric period.” “As the Atlantis was formerly,” replied Herbert. “Yes, my boy... if, however, it existed.” “And would Lincoln Island have been a part of that continent?” asked Pencroft. “It is probable,” replied Cyrus Harding, “and that would sufficiently, explain the variety of productions which are seen on its surface.” “And the great number of animals which still inhabit it,” added Herbert. “Yes, my boy,” replied the engineer, “and you furnish me with an argument to support my theory. It is certain, after what we have seen, that animals are numerous in this island, and what is more strange, that the species are extremely varied. There is a reason for that, and to me it is that Lincoln Island may have formerly been a part of some vast continent which had gradually sunk below the Pacific.” “Then, some fine day,” said Pencroft, who did not appear to be entirely convinced, “the rest of this ancient continent may disappear in its turn, and there will be nothing between America and Asia.” “Yes,” replied Harding, “there will be new continents which millions and millions of animalculae are building at this moment.” “And what are these masons?” asked Pencroft. “Coral insects,” replied Cyrus Harding. “By constant work they made the island of Clermont-Tonnerre, and numerous other coral islands in the Pacific Ocean. Forty-seven millions of these insects are needed to weigh a grain, and yet, with the sea-salt they absorb, the solid elements of water which they assimilate, these animalculae produce limestone, and this limestone forms enormous submarine erections, of which the hardness and solidity equal granite. Formerly, at the first periods of creation, nature employing fire, heaved up the land, but now she entrusts to these microscopic creatures the task of replacing this agent, of which the dynamic power in the interior of the globe has evidently diminished—which is proved by the number of volcanoes on the surface of the earth, now actually extinct. And I believe that centuries succeeding to centuries, and insects to insects, this Pacific may one day be changed into a vast continent, which new generations will inhabit and civilize in their turn.” “That will take a long time,” said Pencroft. “Nature has time for it,” replied the engineer. “But what would be the use of new continents?” asked Herbert. “It appears to me that the present extent of habitable countries is sufficient for humanity. Yet nature does nothing uselessly.” “Nothing uselessly, certainly,” replied the engineer, “but this is how the necessity of new continents for the future, and exactly on the tropical zone occupied by the coral islands, may be explained. At least to me this explanation appears plausible.” “We are listening, captain,” said Herbert. “This is my idea: philosophers generally admit that some day our globe will end, or rather that animal and vegetable life will no longer be possible, because of the intense cold to which it will be subjected. What they are not agreed upon, is the cause of this cold. Some think that it will arise from the falling of the temperature, which the sun will experience after millions of years; others, from the gradual extinction of the fires in the interior of our globe, which have a greater influence on it than is generally supposed. I hold to this last hypothesis, grounding it on the fact that the moon is really a cold star, which is no longer habitable, although the sun continues to throw on its surface the same amount of heat. If, then, the moon has become cold, it is because the interior fires to which, as do all the stars of the stellar world, it owes its origin, are completely extinct. Lastly, whatever may be the cause, our globe will become cold some day, but this cold will only operate gradually. What will happen, then? The temperate zones, at a more or less distant period, will not be more habitable than the polar regions now are. Then the population of men, as well as the animals, will flow towards the latitudes which are more directly under the solar influence. An immense emigration will take place. Europe, Central Asia, North America, will gradually be abandoned, as well as Australasia and the lower parts of South America. The vegetation will follow the human emigration. The flora will retreat towards the Equator at the same time as the fauna. The central parts of South America and Africa will be the continents chiefly inhabited. The Laplanders and the Samoides will find the climate of the polar regions on the shores of the Mediterranean. Who can say, that at this period, the equatorial regions will not be too small, to contain and nourish terrestrial humanity? Now, may not provident nature, so as to give refuge to all the vegetable and animal emigration, be at present laying the foundation of a new continent under the Equator, and may she not have entrusted these insects with the construction of it? I have often thought of all these things, my friends, and I seriously believe that the aspect of our globe will some day be completely changed; that by the raising of new continents the sea will cover the old, and that, in future ages, a Columbus will go to discover the islands of Chimborazo, of the Himalayas, or of Mont Blanc, remains of a submerged America, Asia, and Europe. Then these new continents will become, in their turn, uninhabitable; heat will die away, as does the heat from a body when the soul has left it; and life will disappear from the globe, if not for ever, at least for a period. Perhaps then, our spheroid will rest—will be left to death—to revive some day under superior conditions! But all that, my friends, is the secret of the Author of all things; and beginning by the work of the insects, I have perhaps let myself be carried too far, in investigating the secrets of the future. “My dear Cyrus,” replied Spilett, “these theories are prophecies to me, and they will be accomplished some day.” “That is the secret of God,” said the engineer. “All that is well and good,” then said Pencroft, who had listened with all his might, “but will you tell me, captain, if Lincoln Island has been made by your insects?” “No,” replied Harding; “it is of a purely volcanic origin.” “Then it will disappear some day?” “That is probable.” “I hope we won’t be here then.” “No, don’t be uneasy, Pencroft; we shall not be here then, as we have no wish to die here, and hope to get away some time.” “In the meantime,” replied Gideon Spilett, “let us establish ourselves here as if forever. There is no use in doing things by halves.” This ended the conversation. Breakfast was finished, the exploration was continued, and the settlers arrived at the border of the marshy region. It was a marsh of which the extent, to the rounded coast which terminated the island at the southeast, was about twenty square miles. The soil was formed of clayey flint-earth, mingled with vegetable matter, such as the remains of rushes, reeds, grass, etc. Here and there beds of grass, thick as a carpet, covered it. In many places icy pools sparkled in the sun. Neither rain nor any river, increased by a sudden swelling, could supply these ponds. They therefore naturally concluded that the marsh was fed by the infiltrations of the soil and it was really so. It was also to be feared that during the heat miasmas would arise, which might produce fevers. Above the aquatic plants, on the surface of the stagnant water, fluttered numbers of birds. Wild duck, teal, snipe lived there in flocks, and those fearless birds allowed themselves to be easily approached. One shot from a gun would certainly have brought down some dozen of the birds, they were so close together. The explorers were, however, obliged to content themselves with bows and arrows. The result was less, but the silent arrow had the advantage of not frightening the birds, while the noise of firearms would have dispersed them to all parts of the marsh. The hunters were satisfied, for this time, with a dozen ducks, which had white bodies with a band of cinnamon, a green head, wings black, white, and red, and flattened beak. Herbert called them tadorns. Top helped in the capture of these birds, whose name was given to this marshy part of the island. The settlers had here an abundant reserve of aquatic game. At some future time they meant to explore it more carefully, and it was probable that some of the birds there might be domesticated, or at least brought to the shores of the lake, so that they would be more within their reach. About five o’clock in the evening Cyrus Harding and his companions retraced their steps to their dwelling by traversing Tadorn’s Fens, and crossed the Mercy on the ice-bridge. At eight in the evening they all entered Granite House. About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books. This book is part of the public domain. Jules Verne (1998). The Mysterious Island. Urbana, Illinois: Project Gutenberg. Retrieved October 2022 https://www.gutenberg.org/files/1268/1268-h/1268-h.htm This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at , located at . www.gutenberg.org https://www.gutenberg.org/policy/license.html

Pencroft did not let a single day pass without going to visit what he gravely

Stories, News & Mentions about SINGLE

Single’s Stories on HackerNoon