At Fyto, we partner with farmers to build a sustainable food system at a global scale

FYTO

fyto

Introduction There is a powerful pattern at the heart of the Yield Protocol. It allows us to instantly integrate smart contracts that do not know each other. It also allows us to create new business features on the blockchain without deploying new smart contracts. It allows us to be flexible and scalable, if careful. I’ll call this pattern Forward Trust. Forward Trust is a combination of two concepts: - , in which a contract allows to batch several calls to itself in a single transaction. Multi call - , in which instead of using `transferFrom` to pull tokens from somewhere, a contract records how much of a given token it holds. When a function in that contract is called, any surplus between the recorded and the actual balances is assumed to belong to the caller. Balance tracking These two concepts can be combined so that basic token operations, complex functions, and external calls to other contracts become a higher-level language in which business features can be created off-chain and then immediately executed on-chain. Forward Trust is a combination of two concepts: Multicall and Balance tracking. The idea is not completely new. , , and many others allow users to compose features that integrate several DeFi protocols to build new features. You also have which is a more generalized version of the same idea. Furucombo Instadapp weiroll I didn’t invent Multicall or Balance Tracking. It is quite possible that I wasn’t the first person either to put these two ideas together. I don’t think that matters either way, my intention is to make this pattern known and help others use it so that as an industry we build better and and faster. My intention also is to share the lessons learned from a year of using this pattern, so that others don’t repeat our mistakes. In explaining Forward Trust as it is implemented for the Yield Protocol, I’ll start by giving an overview of Multicall and in general how to build a router smart contract for composable transactions. Following, I’ll explain how to use the Balance Tracking pattern. I’ll include notes alerting of the risks from an incorrect implementation or operation. Finally, I’ll briefly discuss the impact of Forward Trust with regard to core beliefs in smart contract development.** Here we go, buckle up. Building a Composable Router In building a composable router, we are going to break up our business logic into pieces smaller than a business feature, and we are going to implement some tools to put them back together in any combination. With “business feature”, I mean a feature that makes sense to your users. For the Yield Protocol, we have business features such as “add collateral”, “add collateral and borrow underlying”, “add liquidity to a pool”, and many others. These features often have variants, like “add collateral to a position using an off-chain signature”, “borrow using an ERC1155 as collateral”, or “remove my WETH collateral and send it to me as Ether”. Building each of these features separately would require a lot of time, as you would need to code a smart contract and get it through the several stages of testing, auditing, and deployment. That’s __ __and after adding a handful of features we realized the enormous costs. what we did for Yield v1 In a composable router, we break up our business logic into small pieces Yield v2, on the other hand, has a composable router. We already have more than fifty features and can add more at a much faster pace. There aren’t as many constraints imposed by the smart contracts, because smart contracts don’t have to change as often. The idea behind a composable router is that many business features share parts of their code. Some very basic actions that are repeated often are: Take tokens from a user wallet. Execute an off-chain signature for a token approval. Wrap Ether into WETH. Unwrap Ether into WETH. Some other more complex actions that we still repeat often are things like: Build an empty debt position Manage collateral and debt balances Trade assets in YieldSpace Redeem mature fyTokens Your protocol can surely be broken down in the same way. An example recipe for borrowing fyToken in the Yield Protocol would be built from the actions above as follows: Tx1: [
    build(seriesId, ilkId, salt),                  // Create an empty position
    permit(ilk, ladle, posted, deadline, v, r, s), // Execute an off-chain approval
    transfer(ilk, ilkJoin, posted),                // Take tokens from the caller
    pour(vaultId, ignored, posted, 0),             // Add collateral and borrow
] This recipe combines four of the actions available in the router to offer a finished business feature. There are variants to this that without a composable router would require extra smart contract code. For example, some users cannot sign off-chain approvals. For those, the front end will build this instead. Tx1: token.approve(spender, amount)    // Standalone transaction

Tx2: [
    build(seriesId, ilkId, salt),      // Create an empty position
    transfer(ilk, ilkJoin, posted),    // Take tokens from the caller
    pour(vaultId, ignored, posted, 0), // Add collateral and borrow
] As another example, if the user wants to create a fixed-rate loan they need to sell their fyToken in YieldSpace as they borrow them. The recipe for that would be: Tx1: [
    build(seriesId, ilkId, salt),
    permit(ilk, ladle, posted, deadline, v, r, s),
    transfer(ilk, ilkJoin, posted),
    serve(vaultId, receiver, 0, borrowed, maximumDebt),
] The combinations grow exponentially as we match specific conditions and product offerings. Being able to express only the composing actions makes all the difference. Multicall The idea of batching several function calls in a transaction might have been , but later and succinct implementation for batching. By having a function that accepts an array of encoded function calls, and delegatecalls to itself with each one, we build a batching mechanism. first done by dYdX ENS provided an incredibly elegant function multicall(bytes[] calldata data) external returns(bytes[] memory results) {
    results = new bytes[](data.length);
    for(uint i = 0; i < data.length; i++) {
        (bool success, bytes memory result) = address(this).delegatecall(data[i]);
        require(success);
        results[i] = result;
    }
    return results;
} In this way, all the calls in the batch are executed in the same contract. The genius is in using `delegatecall` to preserve `msg.sender` and other transaction variables, as a regular `call` would overwrite `msg.sender` with the contract receiving the batch.** A batching function accepts an array of encoded function calls and delegatecalls to itself with each one. Coding the basic actions to use within multicall is fairly straightforward, they tend to be of code each: one or two lines /// @dev Execute an ERC2612 permit for the selected token
function permit(
  IERC2612 token, address spender, uint256 amount,
  uint256 deadline, uint8 v, bytes32 r, bytes32 s
  ) external payable {
    token.permit(msg.sender, spender, amount, deadline, v, r, s);
}

/// @dev Take tokens from an user
function transfer(IERC20 token, address receiver, uint128 wad) external payable {
  token.safeTransferFrom(msg.sender, receiver, wad);
} Our router has many more examples of actions that we compose into user features, and more can be added by upgrading the router. Calls to these actions are encoded in a calldata string, and then pushed into an array. The `batch` function reads all these actions and executes them sequentially.  A router built this way is very simple and therefore robust, because the actions are small and there is little nesting between them. Just be careful with known ways of . misuse When we released Yield Protocol v2, we knew of a few features we wanted to build, but we also knew that we would regularly think of new features, and that deploying new smart contract code for each one would slow us down. Coding common actions as small individual functions, and using Multicall to put larger business features together from the frontend, we could build much faster. Route We soon realized that we could treat calls to other contracts as building blocks in this language. The Yield Protocol contains an automated market maker, YieldSpace, which acts as a permisionless unit on its own. By implementing a in our router, which simply calls a function on any other contract using `call`, we could use a single function in the router to call any function on a YieldSpace pool. We soon extended that so that we could call any contract from the router. `route` building block The challenge we faced is that our router has permissions on some other contracts .If we allowed anyone to execute arbitrary calls from our router we would effectively allow them to impersonate our router, with catastrophic results. We can call any function in any contract from the router We saw several solutions for this problem: - Make sure the contract implementing `route` never has permissions anywhere. - Implement a blacklist of contracts that calls cannot be routed to. - Install a relayer to `route` calls through, and make sure the relayer never has permissions anywhere. We implemented both a relayer and a whitelist of contracts that we could route calls to, for added security. There is no simple best solution, but the lesson is that you can include simple calls to contracts as yet unknown as one of the actions in your router. There were risks in allowing arbitrary calls from our router, but time has shown that the extra flexibility makes it worth it. Token Transfers Closer to the go-live, when we were busy creating feature after feature, I noticed that it was much easier to integrate with our YieldSpace pools than with other contracts. That was because YieldSpace was modeled after , and it tracked its own balances. When you wanted to sell Dai, you could send a transfer the Dai to the YieldSpace Pool contract, and then call the `sell` function there on the same transaction. The pool would check its Dai balance against the recorded reserves and would find that there was a surplus of Dai. Then it assumed the Dai was yours and executed the sale. Uniswap v2 The extra storage required to track balances might seem like a waste, but in exchange, the caller doesn't need to approve the pool to take tokens. The caller doesn’t need to know much about what will happen to the tokens, no more approvals needed. You might not be impressed. The whole approve and transferFrom pattern is annoying, but it works, so what's the deal? The deal is that with this pattern the caller doesn’t need to know much about what will happen to the tokens, only that they need to be dropped somewhere. If we are building transactions as a batch each function, perhaps in a different contract, follows a simple pattern: Check what the input was Do something with the input Leave the output somewhere Update recorded balances No more approvals are needed. Each function does its thing and drops tokens in some other contract. The next contract to be called by the `batch` function finds out how many tokens he just received, and continues the execution. Just make sure that every token transfer inside a function has its own parameter for a receiver, . you’ll thank me later Suddenly, you can scale. It doesn't matter anymore how many contracts you have in your protocol. Everyone is integrated with everyone else out of the box. Even with contracts that don't exist yet. Here be dragons Now that we have discussed the advantages of Forward Trust, we must discuss the risks. Everything always has its trade-offs, and the strength of the advantages implies the disadvantages are serious as well. You must tread lightly. The Dark Forest When you implement your contracts according to this pattern, you need to be very aware that you are entering . Bots lurk in it and will take any tokens if they can. the dark forest When building the contracts, you need to be careful about how you track the balances, and how the tokens can leave the contract. If the surplus is not calculated correctly, anyone will take what they can. When building recipes, ensure that you don’t leave tokens unattended when your transaction ends. If you send tokens somewhere and don't call the recipient so that it uses them or updates its balances, they will vanish. Be aware that you are entering the Dark Forest When communicating with your users, you need to stress that just calling functions on Etherscan is not as safe as they are used to. They can’t hurt your protocol, but they are likely to lose their funds. You can use this pattern, and we have done so safely for a year at Yield, but be aware that you need to think differently now. Tales from the front The recipes to execute business features within the Yield Protocol are complex. They could be three, four, or maybe eight function calls batched with very precise parameters. Users only see an innocent-looking button, but a lot of work is required to make sure that a recipe is safe. Using Forward Trust, the business experts build the recipes with help from smart contract developers. Then the frontend takes the enormous responsibility of implementing them correctly and testing them again to make sure they work as intended. The frontend developers take an equal responsibility There is a big shift in risk from the smart contract developers to the frontend developers, as only the frontend now protects the users against bots. You need to apply the same level of attention to your frontend and to your smart contracts. Trust, but verify There is a tradition of giving users complete visibility into how a smart contract works. Trust, but verify. By shifting development towards the frontend Forward Trust makes verification more difficult, unfortunately. Frontend code is often private, as a moat protecting against protocol forks. Frontends could be updated at any time with new code that changes the recipes, maybe with bad consequences for the users. There are some calls to provide decentralized and verifiable frontends, and they are even more necessary using this pattern. Shifting development towards the frontend makes verification more difficult Transactions are not private, though, and they can be previewed and debugged. Tools like__ __ make it easy to see the effects of any transaction before it gets executed, and user communities could use it to verify frontend implementations and point out inconsistencies. Tenderly Conclusion The is built differently. Using Multicall and the idea of tracking token balances, we built a higher-level language to create business products with. The result was a very flexible and scalable protocol, but that came with its own set of challenges. Yield Protocol We didn't do what the auditors expected of us, and we had to figure out ways to use this pattern safely. Sometimes we made mistakes and learned from them. One year later, we are still alive, and pumping out features at a fierce rate. It's paying off. I hope that you learned something useful from this article. Maybe you’ll get to code better applications on the blockchain, more powerful and flexible. Be careful of the risks while we come up with better ways of managing them. Good luck. Thanks to whoever came up with Multicall first, I’m guessing that Nick Johnson. Thanks to Uniswap for coming up with Balance Tracking. Thanks to BoringSolidity who I based my own Multicall implementation on. Thanks to Allan Niemerg for giving me the opportunity to build the Yield Protocol. Thanks to transmissions11 and sorry I didn’t name the pattern as you suggested. Thanks to everyone who has helped me build and learn, there are lots of you.

Using the Forward Trust Design Pattern to Make Scaling Easier

The Gambler by Fyodor Dostoyevsky is part of the HackerNoon Books Series. Read this book online for free on HackerNoon! : The Gambler Title : Fyodor Dostoyevsky Author : C. J. Hogarth Translator : May 1, 2000 [eBook #2197] Most recently updated: June 30, 2020 Release date : English Language Table of Links Chapter I Chapter II Chapter III Chapter IV Chapter V Chapter VI Chapter VII Chapter VIII Chapter IX Chapter X Chapter XI Chapter XII Chapter XIII Chapter XIV Chapter XV Chapter XVI Chapter XVII 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. Fyodor Dostoyevsky (2000). The Gambler. Urbana, Illinois: Project Gutenberg. Retrieved https://www.gutenberg.org/cache/epub/2197/pg2197-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 www.gutenberg.org , located at https://www.gutenberg.org/policy/license.html .

The Gambler by Fyodor Dostoyevsky - Table of Links

White Nights and Other Stories by Fyodor Dostoyevsky is part of the HackerNoon Books Series. Read this book online for free on HackerNoon! : White Nights and Other Stories Title : Fyodor Dostoyevsky Author : Constance Garnett Translator : May 5, 2011 [eBook #36034] Release date : English Language TABLE OF LINKS White Nights Notes from Underground— part i. underground part ii. à propos of the wet snow A Faint Heart A Christmas Tree and a Wedding Polzunkov A Little Hero Mr. Prohartchin 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. Fyodor Dostoyevsky (2011). White Nights and Other Stories. Urbana, Illinois: Project Gutenberg. Retrieved October https://www.gutenberg.org/cache/epub/36034/pg36034-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 www.gutenberg.org , located at https://www.gutenberg.org/policy/license.html.

White Nights and Other Stories by Fyodor Dostoyevsky - Table of Links

Poor Folk by Fyodor Dostoyevsky is part of the HackerNoon Books Series. Read this book online for free on HackerNoon! : Poor Folk Title : Fyodor Dostoyevsky Author : C. J. Hogarth Translator : August 1, 2000 [eBook #2302] Most recently updated: February 26, 2021 Release date : English Language Table of Links April 8th April 8th April 8th April 9th April 12th April 25th May 20th June 1st June 11th June 12th. June 20th. June 21st. June 22nd. June 25th. June 26th. June 27th. June 28th. July 1st. July 7th. July 8th. July 27th. July 28th. July 28th. July 29th. August 1st. August 2nd. August 3rd. August 4th. August 4th. August 5th. August 5th. August 11th. August 13th. August 14th. August 19th. August 21st. September 3rd. September 5th. September 9th. September 10th. September 11th. September 15th. September 18th. September 19th. September 23rd. September 23rd. September 27th. September 27th. September 28th. September 28th. September 29th. September 30th 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. Fyodor Dostoyevsky (2000). Poor Folk. Urbana, Illinois: Project Gutenberg. Retrieved October https://www.gutenberg.org/cache/epub/2302/pg2302-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 www.gutenberg.org , located at https://www.gutenberg.org/policy/license.html .

Poor Folk by Fyodor Dostoyevsky - Table of Links

Short Stories by Fyodor Dostoyevsky is part of the HackerNoon Books Series. Read this book online for free on HackerNoon! : Short Stories Title : Fyodor Dostoyevsky Author : September 13, 2012 [eBook #40745] Release date : English Language Table of Links An Honest Thief A Novel in Nine Letters An Unpleasant Predicament Another Man's Wife The Heavenly Christmas Tree The Peasant Marey The Crocodile Bobok The Dream of a Ridiculous Man 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. Fyodor Dostoyevsky (2012).Short Stories. Urbana, Illinois: Project Gutenberg. Retrieved October https://www.gutenberg.org/cache/epub/40745/pg40745-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 www.gutenberg.org , located at https://www.gutenberg.org/policy/license.html

Short Stories by Fyodor Dostoyevsky - Table of Links

The Possessed (The Devils) by Fyodor Dostoyevsky is part of the HackerNoon Books Series. Read this book online for free on HackerNoon! : The Possessed (The Devils) Title : Fyodor Dostoyevsky : Constance Garnett Author Translator : May 1, 2005 [eBook #8117] Most recently updated: July 5, 2017 Release date : English Language Table of Links PART I. CHAPTER I. INTRODUCTORY CHAPTER II. PRINCE HARRY. MATCHMAKING CHAPTER III. THE SINS OF OTHERS CHAPTER IV. THE CRIPPLE CHAPTER V. THE SUBTLE SERPENT PART II. CHAPTER I. NIGHT CHAPTER II. NIGHT (continued) CHAPTER III. THE DUEL CHAPTER IV. ALL IN EXPECTATION CHAPTER V. ON THE EVE OF THE FETE CHAPTER VI. PYOTR STEPANOVITCH IS BUSY CHAPTER VII. A MEETING CHAPTER VIII. IVAN THE TSAREVITCH CHAPTER IX. A RAID AT STEPAN TROFIMOVITCH’S CHAPTER X. FILIBUSTERS. A FATAL MORNING PART III. CHAPTER I. THE FETE—FIRST PART CHAPTER II. THE END OF THE FETE CHAPTER III. A ROMANCE ENDED CHAPTER IV. THE LAST RESOLUTION CHAPTER V. A WANDERER CHAPTER VI. A BUSY NIGHT CHAPTER VII. STEPAN TROFIMOVITCH’S LAST WANDERING CHAPTER VIII. CONCLUSION 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. Fyodor Dostoyevsky (2005). The Possessed (The Devils). Urbana, Illinois: Project Gutenberg. Retrieved October https://www.gutenberg.org/cache/epub/8117/pg8117-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 www.gutenberg.org , located at https://www.gutenberg.org/policy/license.html .

The Possessed (The Devils) by Fyodor Dostoyevsky - Table of Links

Notes from the Underground by Fyodor Dostoyevsky is part of the HackerNoon Books Series. Read this book online for free on HackerNoon! : Notes from the Underground Title : Fyodor Dostoyevsky Author : July 1, 1996 [eBook #600] Most recently updated: December 26, 2021 Release date : English Language Table of Links PART I Underground I II III IV V VI VII VIII IX X XI PART II À Propos of the Wet Snow I II III IV V VI VII VIII IX X 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. Fyodor Dostoyevsky (1996). Notes from the Underground. Urbana, Illinois: Project Gutenberg. Retrieved October https://www.gutenberg.org/cache/epub/600/pg600-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 www.gutenberg.org , located at https://www.gutenberg.org/policy/license.html.

Notes from the Underground by Fyodor Dostoyevsky - Table of Links

The House of the Dead; or, Prison Life in Siberia by Fyodor Dostoyevsky is part of the HackerNoon Books Series. Read this book online for free on HackerNoon! : The House of the Dead; or, Prison Life in Siberia Title : Fyodor Dostoyevsky Author : September 25, 2011 [eBook #37536] Release date : English Language Table of Links INTRODUCTION PART I CHAPTER I.  Ten Years a Convict II.  The Dead-House III.  First Impressions IV.  First Impressions (continued) V.  First Impressions (continued) VI.  The First Month VII.  The First Month (continued) VIII.  New Acquaintances—Petroff IX.  Men of Determination—Luka X.  Isaiah Fomitch—The Bath—Baklouchin XI.  The Christmas Holidays XII.  The Performance PART II I.  The Hospital II.  The Hospital (continued) III.  The Hospital (continued) IV.  The Husband of Akoulka V.  The Summer Season VI.  The Animals at the Convict Establishment VII.  Grievances VIII.  My Companions IX.  The Escape X.  Freedom! 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. Fyodor Dostoyevsky (2011). The House of the Dead; or, Prison Life in Siberia. Urbana, Illinois: Project Gutenberg. Retrieved October https://www.gutenberg.org/cache/epub/37536/pg37536-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 www.gutenberg.org , located at https://www.gutenberg.org/policy/license.html .

The House of the Dead; or, Prison Life in Siberia by Fyodor Dostoyevsky - Table of Links

The Brothers Karamazov by Fyodor Dostoyevsky is part of the HackerNoon Books Series. Read this book online for free on HackerNoon! : The Brothers Karamazov Title : Fyodor Dostoyevsky Author : Constance Garnett Translator : February 12, 2009 [eBook #28054] Most recently updated: January 22, 2023 Release date : English Language Table of Links Part I Book I. The History Of A Family Chapter I. Fyodor Pavlovitch Karamazov Chapter II. He Gets Rid Of His Eldest Son Chapter III. The Second Marriage And The Second Family Chapter IV. The Third Son, Alyosha Chapter V. Elders Book II. An Unfortunate Gathering Chapter I. They Arrive At The Monastery Chapter II. The Old Buffoon Chapter III. Peasant Women Who Have Faith Chapter IV. A Lady Of Little Faith Chapter V. So Be It! So Be It! Chapter VI. Why Is Such A Man Alive? Chapter VII. A Young Man Bent On A Career Chapter VIII. The Scandalous Scene Book III. The Sensualists Chapter I. In The Servants’ Quarters Chapter II. Lizaveta Chapter III. The Confession Of A Passionate Heart—In Verse Chapter IV. The Confession Of A Passionate Heart—In Anecdote Chapter V. The Confession Of A Passionate Heart—“Heels Up” Chapter VI. Smerdyakov Chapter VII. The Controversy Chapter VIII. Over The Brandy Chapter IX. The Sensualists Chapter X. Both Together Chapter XI. Another Reputation Ruined Part II Book IV. Lacerations Chapter I. Father Ferapont Chapter II. At His Father’s Chapter III. A Meeting With The Schoolboys Chapter IV. At The Hohlakovs’ Chapter V. A Laceration In The Drawing‐Room Chapter VI. A Laceration In The Cottage Chapter VII. And In The Open Air Book V. Pro And Contra Chapter I. The Engagement Chapter II. Smerdyakov With A Guitar Chapter III. The Brothers Make Friends Chapter IV. Rebellion Chapter V. The Grand Inquisitor Chapter VI. For Awhile A Very Obscure One Chapter VII. “It’s Always Worth While Speaking To A Clever Man” Book VI. The Russian Monk Chapter I. Father Zossima And His Visitors Chapter II. The Duel Chapter III. Conversations And Exhortations Of Father Zossima Part III Book VII. Alyosha Chapter I. The Breath Of Corruption Chapter II. A Critical Moment Chapter III. An Onion Chapter IV. Cana Of Galilee Book VIII. Mitya Chapter I. Kuzma Samsonov Chapter II. Lyagavy Chapter III. Gold‐Mines Chapter IV. In The Dark Chapter V. A Sudden Resolution Chapter VI. “I Am Coming, Too!” Chapter VII. The First And Rightful Lover Chapter VIII. Delirium Book IX. The Preliminary Investigation Chapter I. The Beginning Of Perhotin’s Official Career Chapter II. The Alarm Chapter III. The Sufferings Of A Soul, The First Ordeal Chapter IV. The Second Ordeal Chapter V. The Third Ordeal Chapter VI. The Prosecutor Catches Mitya Chapter VII. Mitya’s Great Secret. Received With Hisses Chapter VIII. The Evidence Of The Witnesses. The Babe Chapter IX. They Carry Mitya Away Part IV Book X. The Boys Chapter I. Kolya Krassotkin Chapter II. Children Chapter III. The Schoolboy Chapter IV. The Lost Dog Chapter V. By Ilusha’s Bedside Chapter VI. Precocity Chapter VII. Ilusha Book XI. Ivan Chapter I. At Grushenka’s Chapter II. The Injured Foot Chapter III. A Little Demon Chapter IV. A Hymn And A Secret Chapter V. Not You, Not You! Chapter VI. The First Interview With Smerdyakov Chapter VII. The Second Visit To Smerdyakov Chapter VIII. The Third And Last Interview With Smerdyakov Chapter IX. The Devil. Ivan’s Nightmare Chapter X. “It Was He Who Said That” Book XII. A Judicial Error Chapter I. The Fatal Day Chapter II. Dangerous Witnesses Chapter III. The Medical Experts And A Pound Of Nuts Chapter IV. Fortune Smiles On Mitya Chapter V. A Sudden Catastrophe Chapter VI. The Prosecutor’s Speech. Sketches Of Character Chapter VII. An Historical Survey Chapter VIII. A Treatise On Smerdyakov Chapter IX. The Galloping Troika. The End Of The Prosecutor’s Speech. Chapter X. The Speech For The Defense. An Argument That Cuts Both Ways Chapter XI. There Was No Money. There Was No Robbery Chapter XII. And There Was No Murder Either Chapter XIII. A Corrupter Of Thought Chapter XIV. The Peasants Stand Firm Epilogue Chapter I. Plans for Mitya’s Escape Chapter II. For A Moment the Lie Becomes Truth Chapter III. Ilusha’s Funeral. The Speech at the Stone 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. Fyodor Dostoyevsky (2009). The Brothers Karamazov. Urbana, Illinois: Project Gutenberg. Retrieved October https://www.gutenberg.org/cache/epub/28054/pg28054-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 www.gutenberg.org , located at https://www.gutenberg.org/policy/license.html .

The Brothers Karamazov by Fyodor Dostoyevsky - Table of Links

The Brothers Karamazov by Fyodor Dostoyevsky is part of the HackerNoon Books Series. You can jump to any chapter in this book here . Fyodor Pavlovitch Karamazov Chapter I. Fyodor Pavlovitch Karamazov Alexey Fyodorovitch Karamazov was the third son of Fyodor Pavlovitch Karamazov, a land owner well known in our district in his own day, and still remembered among us owing to his gloomy and tragic death, which happened thirteen years ago, and which I shall describe in its proper place. For the present I will only say that this “landowner”—for so we used to call him, although he hardly spent a day of his life on his own estate—was a strange type, yet one pretty frequently to be met with, a type abject and vicious and at the same time senseless. But he was one of those senseless persons who are very well capable of looking after their worldly affairs, and, apparently, after nothing else. Fyodor Pavlovitch, for instance, began with next to nothing; his estate was of the smallest; he ran to dine at other men’s tables, and fastened on them as a toady, yet at his death it appeared that he had a hundred thousand roubles in hard cash. At the same time, he was all his life one of the most senseless, fantastical fellows in the whole district. I repeat, it was not stupidity—the majority of these fantastical fellows are shrewd and intelligent enough—but just senselessness, and a peculiar national form of it. He was married twice, and had three sons, the eldest, Dmitri, by his first wife, and two, Ivan and Alexey, by his second. Fyodor Pavlovitch’s first wife, Adelaïda Ivanovna, belonged to a fairly rich and distinguished noble family, also landowners in our district, the Miüsovs. How it came to pass that an heiress, who was also a beauty, and moreover one of those vigorous, intelligent girls, so common in this generation, but sometimes also to be found in the last, could have married such a worthless, puny weakling, as we all called him, I won’t attempt to explain. I knew a young lady of the last “romantic” generation who after some years of an enigmatic passion for a gentleman, whom she might quite easily have married at any moment, invented insuperable obstacles to their union, and ended by throwing herself one stormy night into a rather deep and rapid river from a high bank, almost a precipice, and so perished, entirely to satisfy her own caprice, and to be like Shakespeare’s Ophelia. Indeed, if this precipice, a chosen and favorite spot of hers, had been less picturesque, if there had been a prosaic flat bank in its place, most likely the suicide would never have taken place. This is a fact, and probably there have been not a few similar instances in the last two or three generations. Adelaïda Ivanovna Miüsov’s action was similarly, no doubt, an echo of other people’s ideas, and was due to the irritation caused by lack of mental freedom. She wanted, perhaps, to show her feminine independence, to override class distinctions and the despotism of her family. And a pliable imagination persuaded her, we must suppose, for a brief moment, that Fyodor Pavlovitch, in spite of his parasitic position, was one of the bold and ironical spirits of that progressive epoch, though he was, in fact, an ill‐natured buffoon and nothing more. What gave the marriage piquancy was that it was preceded by an elopement, and this greatly captivated Adelaïda Ivanovna’s fancy. Fyodor Pavlovitch’s position at the time made him specially eager for any such enterprise, for he was passionately anxious to make a career in one way or another. To attach himself to a good family and obtain a dowry was an alluring prospect. As for mutual love it did not exist apparently, either in the bride or in him, in spite of Adelaïda Ivanovna’s beauty. This was, perhaps, a unique case of the kind in the life of Fyodor Pavlovitch, who was always of a voluptuous temper, and ready to run after any petticoat on the slightest encouragement. She seems to have been the only woman who made no particular appeal to his senses. Immediately after the elopement Adelaïda Ivanovna discerned in a flash that she had no feeling for her husband but contempt. The marriage accordingly showed itself in its true colors with extraordinary rapidity. Although the family accepted the event pretty quickly and apportioned the runaway bride her dowry, the husband and wife began to lead a most disorderly life, and there were everlasting scenes between them. It was said that the young wife showed incomparably more generosity and dignity than Fyodor Pavlovitch, who, as is now known, got hold of all her money up to twenty‐five thousand roubles as soon as she received it, so that those thousands were lost to her for ever. The little village and the rather fine town house which formed part of her dowry he did his utmost for a long time to transfer to his name, by means of some deed of conveyance. He would probably have succeeded, merely from her moral fatigue and desire to get rid of him, and from the contempt and loathing he aroused by his persistent and shameless importunity. But, fortunately, Adelaïda Ivanovna’s family intervened and circumvented his greediness. It is known for a fact that frequent fights took place between the husband and wife, but rumor had it that Fyodor Pavlovitch did not beat his wife but was beaten by her, for she was a hot‐tempered, bold, dark‐browed, impatient woman, possessed of remarkable physical strength. Finally, she left the house and ran away from Fyodor Pavlovitch with a destitute divinity student, leaving Mitya, a child of three years old, in her husband’s hands. Immediately Fyodor Pavlovitch introduced a regular harem into the house, and abandoned himself to orgies of drunkenness. In the intervals he used to drive all over the province, complaining tearfully to each and all of Adelaïda Ivanovna’s having left him, going into details too disgraceful for a husband to mention in regard to his own married life. What seemed to gratify him and flatter his self‐love most was to play the ridiculous part of the injured husband, and to parade his woes with embellishments. “One would think that you’d got a promotion, Fyodor Pavlovitch, you seem so pleased in spite of your sorrow,” scoffers said to him. Many even added that he was glad of a new comic part in which to play the buffoon, and that it was simply to make it funnier that he pretended to be unaware of his ludicrous position. But, who knows, it may have been simplicity. At last he succeeded in getting on the track of his runaway wife. The poor woman turned out to be in Petersburg, where she had gone with her divinity student, and where she had thrown herself into a life of complete emancipation. Fyodor Pavlovitch at once began bustling about, making preparations to go to Petersburg, with what object he could not himself have said. He would perhaps have really gone; but having determined to do so he felt at once entitled to fortify himself for the journey by another bout of reckless drinking. And just at that time his wife’s family received the news of her death in Petersburg. She had died quite suddenly in a garret, according to one story, of typhus, or as another version had it, of starvation. Fyodor Pavlovitch was drunk when he heard of his wife’s death, and the story is that he ran out into the street and began shouting with joy, raising his hands to Heaven: “Lord, now let test Thou Thy servant depart in peace,” but others say he wept without restraint like a little child, so much so that people were sorry for him, in spite of the repulsion he inspired. It is quite possible that both versions were true, that he rejoiced at his release, and at the same time wept for her who released him. As a general rule, people, even the wicked, are much more naïve and simple‐hearted than we suppose. And we ourselves are, too. 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. Fyodor Dostoyevsky (2009). The Brothers Karamazov. Urbana, Illinois: Project Gutenberg. Retrieved October https://www.gutenberg.org/cache/epub/28054/pg28054-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 www.gutenberg.org , located at https://www.gutenberg.org/policy/license.html .

Fyodor Pavlovitch Karamazov

The Idiot by Fyodor Dostoyevsky is part of the HackerNoon Books Series. Read this book online for free on HackerNoon! : The Idiot Title : Fyodor Dostoyevsky Author : Eva Martin Translator : May 1, 2001 [eBook #2638] Most recently updated: June 21, 2021 Release date : English Language Table of Links PART I PART II PART III PART IV 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. Fyodor Dostoyevsky (2001). The Idiot. Urbana, Illinois: Project Gutenberg. Retrieved October https://www.gutenberg.org/cache/epub/2638/pg2638-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 www.gutenberg.org , located at https://www.gutenberg.org/policy/license.html .

The Idiot by Fyodor Dostoyevsky - Table of Links

The Grand Inquisitor by Fyodor Dostoyevsky is part of the HackerNoon Books Series. Read this book online for free on HackerNoon! : The Grand Inquisitor Title : Fyodor Dostoyevsky Author : H. P. Blavatsky Translator : July 1, 2005 [eBook #8578] Most recently updated: December 26, 2020 Release date : English Language Table of Links The Grand Inquisitor 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. Fyodor Dostoyevsky (2005). The Grand Inquisitor. Urbana, Illinois: Project Gutenberg. Retrieved October https://www.gutenberg.org/cache/epub/8578/pg8578-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 www.gutenberg.org , located at https://www.gutenberg.org/policy/license.html.

The Grand Inquisitor by Fyodor Dostoyevsky - Table of Links

In today's fast-paced digital world, finding the most productive tools to streamline your workflow can be overwhelming. With countless options available, it's challenging to identify which applications truly enhance efficiency and collaboration. In this article, I've curated a list of 17 top-tier tools for various professional needs from graphic editor suites and wireframing tools to scheduling apps, collaborative platforms, and project management solutions. You'll discover practical solutions to optimize your workflow, improve your productivity, and navigate the ever-evolving landscape of web development. Each resource will include a direct link, a description, and an image preview. 1. Fotor Fotor is your all-in-one photo editing and design platform. It simplifies your workflow with powerful AI tools and a user-friendly interface. It helps streamline your design process, allowing for quick and professional-quality graphic creation without extensive design skills. Some of the best features include: Background Remover: Remove backgrounds from any image with a single click.


Photo Enhancer: Increase image resolution and make photos look awesome.


AI Image Generator: Make beautiful AI images and art from text prompts.


AI Headshot Generator: Create professional and realistic profile pictures.


AI Video Generator: Craft compelling AI-generated videos for any project. Visit Fotor, and elevate your visual content creation today! Perfect for designers, artists, and anyone who wants to bring their creative visions to life! Thanks to the Fotor team for collaborating with me on this article! 2. Superlist Superlist is a powerful task management tool designed to enhance team productivity by organizing tasks, setting priorities, and tracking progress in real-time. It simplifies workflow management and boosts efficiency by keeping everyone aligned and focused on their goals. 3. Dub Dub is the open-source link management infrastructure for modern marketing teams. It has powerful features such as advanced analytics, branded links, QR codes, personalization and self-hosting options, team collaboration, and more. 4. Glitter Glitter lets you turn any process into a step-by-step guide in seconds. It turns your voice and mouse clicks into a beautifully written guide with screenshots and text that you can easily edit and share with others. 5. Boom Boom is an app that makes meetings and presentations more engaging, productive, and fun wherever you use video. Express yourself with branded overlays, titles, and logos, design what people see when your camera is off, use camera presets for every occasion, and much more. 6. Marker Marker is a bug-tracking tool that enables teams to capture and report website bugs directly from their browser. It streamlines the feedback process by integrating with project management tools, allowing for quicker identification and resolution of issues. 7. Komodo Komodo is a screen recording and sharing tool that allows users to create high-quality video tutorials and presentations effortlessly. It enhances workflow by simplifying the process of creating instructional content, making it easier to share knowledge and collaborate. 8. TidyCal TidyCal is a scheduling application designed to streamline the process of booking meetings and appointments. It improves workflow by eliminating the back-and-forth of scheduling, allowing for quick and easy calendar management that saves time and reduces stress. 9. Shots Shots is a versatile tool designed for generating mockups and frames. It helps streamline the design process by providing an easy way to create, customize, and present visual content, enhancing efficiency in product design and presentation tasks. 10. Excalidraw Excalidraw is an online whiteboard tool that allows users to create hand-drawn diagrams and sketches. It boosts workflow by offering a collaborative space for brainstorming and visualizing ideas, making conveying concepts and planning projects easier. 11. Miro Miro is a digital whiteboard platform for team collaboration, enabling users to create diagrams, mind maps, and project plans. It enhances workflow by providing a versatile real-time collaboration space, helping teams visualize, discuss, and organize their ideas effectively. 12. Height Height is a management tool that integrates task tracking and workflow automation. It improves workflow by offering a comprehensive solution to manage projects, assign tasks, and monitor progress, ensuring that teams stay organized. 13. Whimsical Whimsical is a collaborative online tool that provides flowcharts, wireframes, mind maps, and sticky notes to help teams visualize ideas and workflows. It enhances productivity by offering an intuitive platform for brainstorming, planning, and engagingly organizing thoughts. 14. Wondercraft Wondercraft is an AI-powered platform that allows users to create realistic audio content using text input. It improves workflow by automating the production of high-quality audio content, saving time and resources for content creators and marketers. 15. Rizzle Rizzle is a short-form video creation platform that enables users to produce and share engaging videos effortlessly. It boosts workflow by providing easy-to-use utilities for video editing, making it ideal for social media managers and content creators. 16. Pitch Pitch is a presentation software that combines design and collaboration features to help teams create stunning presentations. It enhances workflow by providing templates, real-time collaboration, and intuitive design tools, making it easier to produce professional presentations. 17. Tally Tally is an online form-building tool that simplifies the creation of surveys, feedback forms, and other data collection instruments. It streamlines workflow by offering a user-friendly interface and robust features that facilitate quick and efficient form creation and data analysis. Writing has always been my passion and it gives me pleasure to help and inspire people. If you have any questions, feel free to reach out! Make sure to receive the best resources, tools, productivity tips, and career growth tips I discover by subscribing to my newsletter! Also, connect with me on Twitter, LinkedIn, and GitHub! Also, published here. In today's fast-paced digital world, finding the most productive tools to streamline your workflow can be overwhelming. With countless options available, it's challenging to identify which applications truly enhance efficiency and collaboration. In this article, I've curated a list of 17 top-tier tools for various professional needs from graphic editor suites and wireframing tools to scheduling apps, collaborative platforms, and project management solutions. You'll discover practical solutions to optimize your workflow, improve your productivity, and navigate the ever-evolving landscape of web development. Each resource will include a direct link, a description, and an image preview. 1. Fotor Fotor Fotor is your all-in-one photo editing and design platform. It simplifies your workflow with powerful AI tools and a user-friendly interface. It helps streamline your design process, allowing for quick and professional-quality graphic creation without extensive design skills. Some of the best features include: Some of the best features include: Background Remover: Remove backgrounds from any image with a single click. Photo Enhancer: Increase image resolution and make photos look awesome. AI Image Generator: Make beautiful AI images and art from text prompts. AI Headshot Generator: Create professional and realistic profile pictures. AI Video Generator: Craft compelling AI-generated videos for any project. Background Remover: Remove backgrounds from any image with a single click. Background Remover: Remove backgrounds from any image with a single click. Photo Enhancer: Increase image resolution and make photos look awesome. Photo Enhancer: Increase image resolution and make photos look awesome. AI Image Generator: Make beautiful AI images and art from text prompts. AI Image Generator: Make beautiful AI images and art from text prompts. AI Headshot Generator: Create professional and realistic profile pictures. AI Headshot Generator: Create professional and realistic profile pictures. AI Video Generator: Craft compelling AI-generated videos for any project. AI Video Generator: Craft compelling AI-generated videos for any project. Visit Fotor , and elevate your visual content creation today! Perfect for designers, artists, and anyone who wants to bring their creative visions to life! Fotor Thanks to the Fotor team for collaborating with me on this article! 2. Superlist Superlist Superlist is a powerful task management tool designed to enhance team productivity by organizing tasks, setting priorities, and tracking progress in real-time. It simplifies workflow management and boosts efficiency by keeping everyone aligned and focused on their goals. 3. Dub Dub Dub is the open-source link management infrastructure for modern marketing teams. It has powerful features such as advanced analytics, branded links, QR codes, personalization and self-hosting options, team collaboration, and more. 4. Glitter Glitter Glitter lets you turn any process into a step-by-step guide in seconds. It turns your voice and mouse clicks into a beautifully written guide with screenshots and text that you can easily edit and share with others. 5. Boom Boom Boom is an app that makes meetings and presentations more engaging, productive, and fun wherever you use video. Express yourself with branded overlays, titles, and logos, design what people see when your camera is off, use camera presets for every occasion, and much more. 6. Marker Marker Marker is a bug-tracking tool that enables teams to capture and report website bugs directly from their browser. It streamlines the feedback process by integrating with project management tools, allowing for quicker identification and resolution of issues. 7. Komodo Komodo Komodo is a screen recording and sharing tool that allows users to create high-quality video tutorials and presentations effortlessly. It enhances workflow by simplifying the process of creating instructional content, making it easier to share knowledge and collaborate. 8. TidyCal TidyCal TidyCal is a scheduling application designed to streamline the process of booking meetings and appointments. It improves workflow by eliminating the back-and-forth of scheduling, allowing for quick and easy calendar management that saves time and reduces stress. 9. Shots Shots Shots is a versatile tool designed for generating mockups and frames. It helps streamline the design process by providing an easy way to create, customize, and present visual content, enhancing efficiency in product design and presentation tasks. 10. Excalidraw Excalidraw Excalidraw is an online whiteboard tool that allows users to create hand-drawn diagrams and sketches. It boosts workflow by offering a collaborative space for brainstorming and visualizing ideas, making conveying concepts and planning projects easier. 11. Miro Miro Miro is a digital whiteboard platform for team collaboration, enabling users to create diagrams, mind maps, and project plans. It enhances workflow by providing a versatile real-time collaboration space, helping teams visualize, discuss, and organize their ideas effectively. 12. Height Height Height is a management tool that integrates task tracking and workflow automation. It improves workflow by offering a comprehensive solution to manage projects, assign tasks, and monitor progress, ensuring that teams stay organized. 13. Whimsical Whimsical Whimsical is a collaborative online tool that provides flowcharts, wireframes, mind maps, and sticky notes to help teams visualize ideas and workflows. It enhances productivity by offering an intuitive platform for brainstorming, planning, and engagingly organizing thoughts. 14. Wondercraft Wondercraft Wondercraft is an AI-powered platform that allows users to create realistic audio content using text input. It improves workflow by automating the production of high-quality audio content, saving time and resources for content creators and marketers. 15. Rizzle Rizzle Rizzle is a short-form video creation platform that enables users to produce and share engaging videos effortlessly. It boosts workflow by providing easy-to-use utilities for video editing, making it ideal for social media managers and content creators. 16. Pitch Pitch Pitch is a presentation software that combines design and collaboration features to help teams create stunning presentations. It enhances workflow by providing templates, real-time collaboration, and intuitive design tools, making it easier to produce professional presentations. 17. Tally Tally Tally is an online form-building tool that simplifies the creation of surveys, feedback forms, and other data collection instruments. It streamlines workflow by offering a user-friendly interface and robust features that facilitate quick and efficient form creation and data analysis. Writing has always been my passion and it gives me pleasure to help and inspire people. If you have any questions, feel free to reach out! Make sure to receive the best resources, tools, productivity tips, and career growth tips I discover by subscribing to my newsletter ! my newsletter Also, connect with me on Twitter , LinkedIn , and GitHub ! Twitter LinkedIn GitHub Also, published here . here

How to Improve Your Workflow by 10X: 17 Essential Apps

কিভাবে 10X দ্বারা আপনার কর্মপ্রবাহ উন্নত করবেন: 17টি প্রয়োজনীয় অ্যাপ

So verbessern Sie Ihren Workflow um das Zehnfache: 17 unverzichtbare Apps

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

Comment améliorer votre flux de travail par 10 : 17 applications essentielles

अपने वर्कफ़्लो को 10 गुना बेहतर कैसे बनाएं: 17 ज़रूरी ऐप्स

ワークフローを10倍に向上させる方法: 必須アプリ17選

작업 흐름을 10배 향상하는 방법: 17가지 필수 앱

Como melhorar seu fluxo de trabalho em 10 vezes: 17 aplicativos essenciais

Как улучшить ваш рабочий процесс в 10 раз: 17 основных приложений

İş Akışınızı 10 Kat Nasıl İyileştirirsiniz: 17 Temel Uygulama

Cách cải thiện quy trình làm việc của bạn lên gấp 10 lần: 17 ứng dụng cần thiết

如何将您的工作流程提高 10 倍：17 个必备应用程序

SINGAPORE, Singapore, July 23rd, 2024/Chainwire/--A groundbreaking moment in decentralized finance (DeFi) is here as Magnify Cash unveils its state-of-the-art DeFi protocol and announces the upcoming Fair Launch of its native token, $MAG. As a pioneer in financial technology, Magnify Cash is set to reshape the financial services landscape for individuals and enterprises alike. The Future of Decentralized Credit Markets Magnify Cash is spearheading the next evolution in decentralized credit markets, unlocking liquidity for Real-World Assets (RWAs), Future Yield Tokens (FYTs), and a myriad of digital assets through its innovative, permissionless lending desks. Solving Key Financial Challenges Limited Liquidity: Bridging the gap for diverse digital assets.
Decentralization: Eliminating centralized and custodial lending limitations. Innovative Products and Solutions Permissionless Lending Desks: Facilitate borrowing and lending for any ERC-20 token against RWAs, FYTs, and other digital assets.
Decentralized Borrowing Options: Provide lending solutions without intermediaries, ensuring maximum security and transparency. Universal Collateral and Currency Support Magnify Cash’s Universal Collateral Acceptance feature supports an extensive array of tokenized assets, including ERC-1155 and ERC-721 tokens. Users can now leverage NFTs and tokenized real-world assets such as art, real estate, bonds, and luxury goods as collateral, unlocking liquidity without the need to liquidate these valuable assets. Key Features Comprehensive Support: Universal support for lending currencies and loan collateral (ERC-20, ERC-1155, ERC-721).
Seamless Operations: Asset-backed borrowing and lending with permissionless creation and management of lending desks.
Enhanced Liquidity: Extensive liquidity options for all digital assets, including stablecoins, ETH, liquid staking tokens (LSTs), meme tokens, blue chip NFTs, and treasuries.
Advanced Risk Management: A dynamic interest rate model utilizing linear interpolation and scaling factors, eliminating the need for oracles. Robust Security and Compliance Guardian Protocol Audit: Ensuring top-notch security.
Gaslite Gas Optimization Audit: Maximizing operational efficiency. Proven Testnet Success Over 500 lending desks created.
More than 500 loans issued.
Nearly 5,000 unique users engaged. Strategic Alliances and Future Roadmap Magnify Cash collaborates with leading industry partners like LydianLabs, FjordFoundry, Jiraiya, Tailored, Blaize, 4am, and H3AT Studios, amplifying the platform's capabilities and outreach. Key security audits by Guardian Protocol and Gaslite reinforce Magnify Cash’s commitment to providing a secure and reliable platform. Currently Live on Base Testnet Exciting Upcoming Launches Base Mainnet: Coming Soon (Including RWAs)
Ethereum Mainnet: Coming Soon (Including RWAs)
Potential Layer 2 launches: Abstract Chain, Blast Chain, and more. Fair Launch of $MAG Token The $MAG token will be launched through Fjord Foundry’s liquidity bootstrapping protocol, ensuring a fair and transparent distribution. The token sale runs from July 23rd, 8:00 PM EST to July 27th, 8:00 AM EST, with over 70% of tokens allocated to the public. This equitable approach encourages broad participation and fosters a strong, engaged community. Active participants, including lenders, liquidity providers, and borrowers, are rewarded with $MAG tokens. Participation Opportunities Secure $MAG Tokens: The MAG token sale begins on July 23rd at 8:00 PM EST (July 24th, 8:00 AM Singapore Time). Participants are invited to join the Fair Launch at Fjord Foundry here. Explore the Ecosystem: Magnify Cash invites interested parties to discover its comprehensive ecosystem by visiting the Website. Access the Pitch Deck, engaging Intro Video, detailed Whitepaper, and technical Documentation. Engage with Our Community: Magnify Cash encourages joining its vibrant community for real-time updates and support. Follow us on Twitter, join the Telegram group, and participate in discussions on Discord. About Magnify Cash Magnify Cash is a non-custodial and permissionless decentralized credit market that empowers users to lend ERC-20 tokens and borrow against non-fungible tokens (NFTs) and Real-World Assets (RWAs) with unmatched flexibility and transparency. Committed to true decentralization, Magnify Cash ensures universal support for ERC-20 tokens as lending currencies and ERC-1155/ERC-721 assets as collateral. The protocol’s innovative approach to on-chain credit markets offers a fresh perspective in the evolving world of decentralized finance. For more information, users can visit https://Magnify.Cash or follow Magnify Cash on Twitter at X.com/MagnifyCash. Magnify Media Kit: Link. Contact Press Manager Magnify.Cash socials@magnify.cash This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here. SINGAPORE, Singapore, July 23rd, 2024/Chainwire/--A groundbreaking moment in decentralized finance (DeFi) is here as Magnify Cash unveils its state-of-the-art DeFi protocol and announces the upcoming Fair Launch of its native token, $MAG. As a pioneer in financial technology, Magnify Cash is set to reshape the financial services landscape for individuals and enterprises alike. The Future of Decentralized Credit Markets Magnify Cash is spearheading the next evolution in decentralized credit markets, unlocking liquidity for Real-World Assets (RWAs), Future Yield Tokens (FYTs), and a myriad of digital assets through its innovative, permissionless lending desks. Solving Key Financial Challenges Limited Liquidity: Bridging the gap for diverse digital assets. Decentralization: Eliminating centralized and custodial lending limitations. Limited Liquidity: Bridging the gap for diverse digital assets. Decentralization: Eliminating centralized and custodial lending limitations. Innovative Products and Solutions Permissionless Lending Desks: Facilitate borrowing and lending for any ERC-20 token against RWAs, FYTs, and other digital assets. Decentralized Borrowing Options: Provide lending solutions without intermediaries, ensuring maximum security and transparency. Permissionless Lending Desks: Facilitate borrowing and lending for any ERC-20 token against RWAs, FYTs, and other digital assets. Decentralized Borrowing Options: Provide lending solutions without intermediaries, ensuring maximum security and transparency. Universal Collateral and Currency Support Magnify Cash’s Universal Collateral Acceptance feature supports an extensive array of tokenized assets, including ERC-1155 and ERC-721 tokens. Users can now leverage NFTs and tokenized real-world assets such as art, real estate, bonds, and luxury goods as collateral, unlocking liquidity without the need to liquidate these valuable assets. Key Features Comprehensive Support: Universal support for lending currencies and loan collateral (ERC-20, ERC-1155, ERC-721). Seamless Operations: Asset-backed borrowing and lending with permissionless creation and management of lending desks. Enhanced Liquidity: Extensive liquidity options for all digital assets, including stablecoins, ETH, liquid staking tokens (LSTs), meme tokens, blue chip NFTs, and treasuries. Advanced Risk Management: A dynamic interest rate model utilizing linear interpolation and scaling factors, eliminating the need for oracles. Comprehensive Support: Universal support for lending currencies and loan collateral (ERC-20, ERC-1155, ERC-721). Seamless Operations: Asset-backed borrowing and lending with permissionless creation and management of lending desks. Enhanced Liquidity: Extensive liquidity options for all digital assets, including stablecoins, ETH, liquid staking tokens (LSTs), meme tokens, blue chip NFTs, and treasuries. Advanced Risk Management: A dynamic interest rate model utilizing linear interpolation and scaling factors, eliminating the need for oracles. Robust Security and Compliance Guardian Protocol Audit: Ensuring top-notch security. Gaslite Gas Optimization Audit: Maximizing operational efficiency. Guardian Protocol Audit : Ensuring top-notch security. Guardian Protocol Audit Guardian Protocol Audit Gaslite Gas Optimization Audit : Maximizing operational efficiency. Gaslite Gas Optimization Audit Gaslite Gas Optimization Audit Proven Testnet Success Over 500 lending desks created. More than 500 loans issued. Nearly 5,000 unique users engaged. Over 500 lending desks created. More than 500 loans issued. Nearly 5,000 unique users engaged. Strategic Alliances and Future Roadmap Magnify Cash collaborates with leading industry partners like LydianLabs , FjordFoundry , Jiraiya , Tailored , Blaize, 4am, and H3AT Studios , amplifying the platform's capabilities and outreach. Key security audits by Guardian Protocol and Gaslite reinforce Magnify Cash’s commitment to providing a secure and reliable platform. LydianLabs LydianLabs FjordFoundry FjordFoundry Jiraiya Jiraiya Tailored Tailored H3AT Studios H3AT Studios Currently Live on Base Testnet Base Testnet Exciting Upcoming Launches Base Mainnet: Coming Soon (Including RWAs) Ethereum Mainnet: Coming Soon (Including RWAs) Potential Layer 2 launches: Abstract Chain, Blast Chain, and more. Base Mainnet: Coming Soon (Including RWAs) Ethereum Mainnet: Coming Soon (Including RWAs) Potential Layer 2 launches: Abstract Chain, Blast Chain, and more. Fair Launch of $MAG Token The $MAG token will be launched through Fjord Foundry’s liquidity bootstrapping protocol, ensuring a fair and transparent distribution. The token sale runs from July 23rd, 8:00 PM EST to July 27th, 8:00 AM EST, with over 70% of tokens allocated to the public. This equitable approach encourages broad participation and fosters a strong, engaged community. Active participants, including lenders, liquidity providers, and borrowers, are rewarded with $MAG tokens. Participation Opportunities Secure $MAG Tokens: The MAG token sale begins on July 23rd at 8:00 PM EST (July 24th, 8:00 AM Singapore Time). Participants are invited to join the Fair Launch at Fjord Foundry here . here here Explore the Ecosystem: Magnify Cash invites interested parties to discover its comprehensive ecosystem by visiting the Website . Access the Pitch Deck, engaging Intro Video, detailed Whitepaper, and technical Documentation. Website Website Engage with Our Community: Magnify Cash encourages joining its vibrant community for real-time updates and support. Follow us on Twitter , join the Telegram group , and participate in discussions on Discord . Twitter Twitter Telegram group Telegram group Discord Discord About Magnify Cash Magnify Cash is a non-custodial and permissionless decentralized credit market that empowers users to lend ERC-20 tokens and borrow against non-fungible tokens (NFTs) and Real-World Assets (RWAs) with unmatched flexibility and transparency. Committed to true decentralization, Magnify Cash ensures universal support for ERC-20 tokens as lending currencies and ERC-1155/ERC-721 assets as collateral. Magnify Cash Magnify Cash The protocol’s innovative approach to on-chain credit markets offers a fresh perspective in the evolving world of decentralized finance. For more information, users can visit https://Magnify.Cash or follow Magnify Cash on Twitter at X.com/MagnifyCash . https://Magnify.Cash https://Magnify.Cash X.com/MagnifyCash X.com/MagnifyCash Magnify Media Kit: Link . Link Link Contact Press Manager Magnify.Cash socials@magnify.cash This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here. This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here . here here

Magnify Cash Launches DeFi Protocol And Announces $MAG Token Fair Launch

ম্যাগনিফাই ক্যাশ ডিফাই প্রোটোকল চালু করেছে এবং $MAG টোকেন ফেয়ার লঞ্চের ঘোষণা করেছে

Magnify Cash führt DeFi-Protokoll ein und kündigt fairen Start des $MAG-Tokens an

Magnify Cash lanza el protocolo DeFi y anuncia el lanzamiento de la feria de tokens $MAG

Magnify Cash lance le protocole DeFi et annonce le lancement du salon des jetons $MAG

मैग्नीफाई कैश ने DeFi प्रोटोकॉल लॉन्च किया और $MAG टोकन फेयर लॉन्च की घोषणा की

Magnify CashがDeFiプロトコルを立ち上げ、$MAGトークンフェアのローンチを発表

Magnify Cash, DeFi 프로토콜 출시 및 $MAG 토큰 박람회 출시 발표

Magnify Cash lança protocolo DeFi e anuncia lançamento da $MAG Token Fair

Magnify Cash запускает протокол DeFi и объявляет о честном запуске токена $MAG

Magnify Cash, DeFi Protokolünü Başlatıyor ve $MAG Token Fuarı Lansmanını Duyurdu

Magnify Cash ra mắt giao thức DeFi và công bố ra mắt công bằng token $MAG

Magnify Cash 推出 DeFi 协议并宣布 $MAG 代币公平发行

Once, I was tasked with improving the database and general app operations of backend services which were using MongoDB as their main database. These services were part of a huge infrastructure where millions of messages came through the queues and needed to be processed based on the message actions. That means tons of DB ops each second and other additional checks while processing. Real Case Scenario The processing layer of the service was using Pymongo to interact with MongoDB and the service itself was running in a synchronous environment. Even though the database operations were handled in bulk, the performance was still not capable of handling incoming data. Synchronous code was making things even worse. The code execution waits for the result from the current operation to move forward. That's a serious bottleneck in scalable systems. This was causing queue overflows and potential data loss every time. Asynchronous Environment The solution I implemented was a combination of: Motor
Asyncio
Uvloop Let's quickly go through the definitions of these items. PyMongo is the official MongoDB driver for Python, providing a simple and intuitive way to interact with MongoDB databases. It's synchronous, meaning each database operation blocks the execution of your program until it completes it, which can be a bottleneck in I/O-bound tasks. Motor is the asynchronous driver for MongoDB, built on top of PyMongo and designed to take advantage of Python's asyncio library. Motor allows you to perform non-blocking database operations, making it suitable for high-performance applications that require concurrency. To illustrate the performance differences, I prepared a stress test using two scripts: one using Motor (asynchronous) and the other using PyMongo (synchronous). Both scripts performed the same task of reading and writing documents to MongoDB in batches. Both scripts read 300k documents from the source collection and migrated them to the new target collection. Asynchronous Script (Motor) import logging
import asyncio
import time
from bson import ObjectId
from motor.motor_asyncio import AsyncIOMotorClient

# Configure logging
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

# MongoDB setup
MONGO_URI = 'mongodb://root:root@localhost:27019'
DB_NAME = 'products'
COLLECTION_NAME = 'gmc_products'

client = AsyncIOMotorClient(MONGO_URI)
db = client[DB_NAME]
collection = db[COLLECTION_NAME]
target_collection = db["new_collection"]

async def fetch_products(batch_size, last_id=None):
    query = {'_id': {'$gt': last_id}} if last_id else {}
    cursor = collection.find(query).sort('_id').limit(batch_size)
    products = await cursor.to_list(length=batch_size)
    return products

async def bulk_write_to_mongo(products):
    for product in products:
        product['_id'] = ObjectId()  # Generate a new ObjectId for each product

    try:
        result = await target_collection.insert_many(products, ordered=False)
        logger.info(f'Inserted {len(result.inserted_ids)} products into MongoDB.')
    except Exception as e:
        logger.error(f'Error inserting products into MongoDB: {e}')

async def process_batches(batch_size, concurrency_limit):
    tasks = []
    last_id = None
    while True:
        products = await fetch_products(batch_size, last_id)
        if not products:
            break
        last_id = products[-1]['_id']
        tasks.append(bulk_write_to_mongo(products))
        if len(tasks) >= concurrency_limit:
            await asyncio.gather(*tasks)
            tasks = []
    # Process remaining tasks if any
    if tasks:
        await asyncio.gather(*tasks)

async def main():
    batch_size = 1000
    concurrency_limit = 10

    start_time = time.time()
    await process_batches(batch_size, concurrency_limit)
    end_time = time.time()
    logger.info(f'Total time: {end_time - start_time:.2f} seconds.')

if __name__ == '__main__':
    asyncio.run(main()) Synchronous Script (Pymongo) import logging
import time
from bson import ObjectId
from pymongo import MongoClient

# Configure logging
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

# MongoDB setup
MONGO_URI = 'mongodb://root:root@localhost:27019'
DB_NAME = 'products'
COLLECTION_NAME = 'gmc_products'
TARGET_COLLECTION_NAME = 'new_collection'

client = MongoClient(MONGO_URI)
db = client[DB_NAME]
collection = db[COLLECTION_NAME]
target_collection = db[TARGET_COLLECTION_NAME]

def fetch_products(batch_size, last_id=None):
    query = {'_id': {'$gt': last_id}} if last_id else {}
    cursor = collection.find(query).sort('_id').limit(batch_size)
    products = list(cursor)
    return products

def bulk_write_to_mongo(products):
    for product in products:
        product['_id'] = ObjectId()  # Generate a new ObjectId for each product

    try:
        result = target_collection.insert_many(products, ordered=False)
        logger.info(f'Inserted {len(result.inserted_ids)} products into MongoDB.')
    except Exception as e:
        logger.error(f'Error inserting products into MongoDB: {e}')

def process_batches(batch_size):
    last_id = None
    while True:
        products = fetch_products(batch_size, last_id)
        if not products:
            break
        last_id = products[-1]['_id']
        bulk_write_to_mongo(products)

def main():
    batch_size = 1000

    start_time = time.time()
    process_batches(batch_size)
    end_time = time.time()
    logger.info(f'Total time: {end_time - start_time:.2f} seconds.')

if __name__ == '__main__':
    main() Results and Analysis Execution Time of Migrating 300k documents: Asynchronous script: 17.15 seconds
Synchronous script: 23.26 seconds The asynchronous script completed the task 6.11 seconds faster than the synchronous script. While this might not seem like a significant difference for a single run, it becomes more pronounced in high-load scenarios or when processing large datasets continuously. Benefits of Using Motor and Asynchronous Environment Improved Throughput: Asynchronous operations can handle more tasks concurrently, increasing overall throughput. This is especially beneficial in applications with high I/O operations, such as web servers handling multiple database queries simultaneously. Non-Blocking I/O: Asynchronous operations do not block the main thread, allowing other tasks to continue running. This results in better CPU utilization and smoother application performance, particularly under load. Scalability: Asynchronous code scales better with the number of concurrent operations. For example, a web application using Motor can handle more simultaneous requests compared to one using PyMongo. Resource Efficiency: Asynchronous operations can lead to more efficient use of system resources. For instance, the event loop in asyncio allows the application to switch between tasks, reducing idle times and improving overall efficiency. You can find the source code on the GitHub repository below: https://github.com/PylotStuff/motor-asyncio-performance?embedable=true Conclusion The choice between Motor and PyMongo depends on the specific needs of your application. For applications that require high concurrency and efficient I/O handling, Motor and the asynchronous approach offer significant advantages. However, for simpler applications or scripts where ease of implementation is a priority, PyMongo's synchronous approach might be sufficient. By leveraging asynchronous operations with Motor, you can build more scalable and performant applications, making it a worthwhile consideration for modern web development. Once, I was tasked with improving the database and general app operations of backend services which were using MongoDB as their main database. These services were part of a huge infrastructure where millions of messages came through the queues and needed to be processed based on the message actions. That means tons of DB ops each second and other additional checks while processing. Real Case Scenario The processing layer of the service was using Pymongo to interact with MongoDB and the service itself was running in a synchronous environment. Even though the database operations were handled in bulk, the performance was still not capable of handling incoming data. Synchronous code was making things even worse. The code execution waits for the result from the current operation to move forward. That's a serious bottleneck in scalable systems. This was causing queue overflows and potential data loss every time. Asynchronous Environment The solution I implemented was a combination of: Motor Asyncio Uvloop Motor Asyncio Uvloop Let's quickly go through the definitions of these items. PyMongo is the official MongoDB driver for Python, providing a simple and intuitive way to interact with MongoDB databases. It's synchronous, meaning each database operation blocks the execution of your program until it completes it, which can be a bottleneck in I/O-bound tasks. PyMongo Motor is the asynchronous driver for MongoDB, built on top of PyMongo and designed to take advantage of Python's asyncio library. Motor allows you to perform non-blocking database operations, making it suitable for high-performance applications that require concurrency. Motor To illustrate the performance differences, I prepared a stress test using two scripts: one using Motor (asynchronous) and the other using PyMongo (synchronous). Both scripts performed the same task of reading and writing documents to MongoDB in batches. Both scripts read 300k documents from the source collection and migrated them to the new target collection. Asynchronous Script (Motor) import logging
import asyncio
import time
from bson import ObjectId
from motor.motor_asyncio import AsyncIOMotorClient

# Configure logging
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

# MongoDB setup
MONGO_URI = 'mongodb://root:root@localhost:27019'
DB_NAME = 'products'
COLLECTION_NAME = 'gmc_products'

client = AsyncIOMotorClient(MONGO_URI)
db = client[DB_NAME]
collection = db[COLLECTION_NAME]
target_collection = db["new_collection"]

async def fetch_products(batch_size, last_id=None):
    query = {'_id': {'$gt': last_id}} if last_id else {}
    cursor = collection.find(query).sort('_id').limit(batch_size)
    products = await cursor.to_list(length=batch_size)
    return products

async def bulk_write_to_mongo(products):
    for product in products:
        product['_id'] = ObjectId()  # Generate a new ObjectId for each product

    try:
        result = await target_collection.insert_many(products, ordered=False)
        logger.info(f'Inserted {len(result.inserted_ids)} products into MongoDB.')
    except Exception as e:
        logger.error(f'Error inserting products into MongoDB: {e}')

async def process_batches(batch_size, concurrency_limit):
    tasks = []
    last_id = None
    while True:
        products = await fetch_products(batch_size, last_id)
        if not products:
            break
        last_id = products[-1]['_id']
        tasks.append(bulk_write_to_mongo(products))
        if len(tasks) >= concurrency_limit:
            await asyncio.gather(*tasks)
            tasks = []
    # Process remaining tasks if any
    if tasks:
        await asyncio.gather(*tasks)

async def main():
    batch_size = 1000
    concurrency_limit = 10

    start_time = time.time()
    await process_batches(batch_size, concurrency_limit)
    end_time = time.time()
    logger.info(f'Total time: {end_time - start_time:.2f} seconds.')

if __name__ == '__main__':
    asyncio.run(main()) import logging
import asyncio
import time
from bson import ObjectId
from motor.motor_asyncio import AsyncIOMotorClient

# Configure logging
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

# MongoDB setup
MONGO_URI = 'mongodb://root:root@localhost:27019'
DB_NAME = 'products'
COLLECTION_NAME = 'gmc_products'

client = AsyncIOMotorClient(MONGO_URI)
db = client[DB_NAME]
collection = db[COLLECTION_NAME]
target_collection = db["new_collection"]

async def fetch_products(batch_size, last_id=None):
    query = {'_id': {'$gt': last_id}} if last_id else {}
    cursor = collection.find(query).sort('_id').limit(batch_size)
    products = await cursor.to_list(length=batch_size)
    return products

async def bulk_write_to_mongo(products):
    for product in products:
        product['_id'] = ObjectId()  # Generate a new ObjectId for each product

    try:
        result = await target_collection.insert_many(products, ordered=False)
        logger.info(f'Inserted {len(result.inserted_ids)} products into MongoDB.')
    except Exception as e:
        logger.error(f'Error inserting products into MongoDB: {e}')

async def process_batches(batch_size, concurrency_limit):
    tasks = []
    last_id = None
    while True:
        products = await fetch_products(batch_size, last_id)
        if not products:
            break
        last_id = products[-1]['_id']
        tasks.append(bulk_write_to_mongo(products))
        if len(tasks) >= concurrency_limit:
            await asyncio.gather(*tasks)
            tasks = []
    # Process remaining tasks if any
    if tasks:
        await asyncio.gather(*tasks)

async def main():
    batch_size = 1000
    concurrency_limit = 10

    start_time = time.time()
    await process_batches(batch_size, concurrency_limit)
    end_time = time.time()
    logger.info(f'Total time: {end_time - start_time:.2f} seconds.')

if __name__ == '__main__':
    asyncio.run(main()) Synchronous Script (Pymongo) import logging
import time
from bson import ObjectId
from pymongo import MongoClient

# Configure logging
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

# MongoDB setup
MONGO_URI = 'mongodb://root:root@localhost:27019'
DB_NAME = 'products'
COLLECTION_NAME = 'gmc_products'
TARGET_COLLECTION_NAME = 'new_collection'

client = MongoClient(MONGO_URI)
db = client[DB_NAME]
collection = db[COLLECTION_NAME]
target_collection = db[TARGET_COLLECTION_NAME]

def fetch_products(batch_size, last_id=None):
    query = {'_id': {'$gt': last_id}} if last_id else {}
    cursor = collection.find(query).sort('_id').limit(batch_size)
    products = list(cursor)
    return products

def bulk_write_to_mongo(products):
    for product in products:
        product['_id'] = ObjectId()  # Generate a new ObjectId for each product

    try:
        result = target_collection.insert_many(products, ordered=False)
        logger.info(f'Inserted {len(result.inserted_ids)} products into MongoDB.')
    except Exception as e:
        logger.error(f'Error inserting products into MongoDB: {e}')

def process_batches(batch_size):
    last_id = None
    while True:
        products = fetch_products(batch_size, last_id)
        if not products:
            break
        last_id = products[-1]['_id']
        bulk_write_to_mongo(products)

def main():
    batch_size = 1000

    start_time = time.time()
    process_batches(batch_size)
    end_time = time.time()
    logger.info(f'Total time: {end_time - start_time:.2f} seconds.')

if __name__ == '__main__':
    main() import logging
import time
from bson import ObjectId
from pymongo import MongoClient

# Configure logging
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

# MongoDB setup
MONGO_URI = 'mongodb://root:root@localhost:27019'
DB_NAME = 'products'
COLLECTION_NAME = 'gmc_products'
TARGET_COLLECTION_NAME = 'new_collection'

client = MongoClient(MONGO_URI)
db = client[DB_NAME]
collection = db[COLLECTION_NAME]
target_collection = db[TARGET_COLLECTION_NAME]

def fetch_products(batch_size, last_id=None):
    query = {'_id': {'$gt': last_id}} if last_id else {}
    cursor = collection.find(query).sort('_id').limit(batch_size)
    products = list(cursor)
    return products

def bulk_write_to_mongo(products):
    for product in products:
        product['_id'] = ObjectId()  # Generate a new ObjectId for each product

    try:
        result = target_collection.insert_many(products, ordered=False)
        logger.info(f'Inserted {len(result.inserted_ids)} products into MongoDB.')
    except Exception as e:
        logger.error(f'Error inserting products into MongoDB: {e}')

def process_batches(batch_size):
    last_id = None
    while True:
        products = fetch_products(batch_size, last_id)
        if not products:
            break
        last_id = products[-1]['_id']
        bulk_write_to_mongo(products)

def main():
    batch_size = 1000

    start_time = time.time()
    process_batches(batch_size)
    end_time = time.time()
    logger.info(f'Total time: {end_time - start_time:.2f} seconds.')

if __name__ == '__main__':
    main() Results and Analysis Execution Time of Migrating 300k documents: Asynchronous script: 17.15 seconds Synchronous script: 23.26 seconds Asynchronous script: 17.15 seconds Synchronous script: 23.26 seconds The asynchronous script completed the task 6.11 seconds faster than the synchronous script. 6.11 seconds While this might not seem like a significant difference for a single run, it becomes more pronounced in high-load scenarios or when processing large datasets continuously. Benefits of Using Motor and Asynchronous Environment Improved Throughput : Asynchronous operations can handle more tasks concurrently, increasing overall throughput. This is especially beneficial in applications with high I/O operations, such as web servers handling multiple database queries simultaneously. Improved Throughput Non-Blocking I/O : Asynchronous operations do not block the main thread, allowing other tasks to continue running. This results in better CPU utilization and smoother application performance, particularly under load. Non-Blocking I/O Scalability : Asynchronous code scales better with the number of concurrent operations. For example, a web application using Motor can handle more simultaneous requests compared to one using PyMongo. Scalability Resource Efficiency : Asynchronous operations can lead to more efficient use of system resources. For instance, the event loop in asyncio allows the application to switch between tasks, reducing idle times and improving overall efficiency. Resource Efficiency You can find the source code on the GitHub repository below: https://github.com/PylotStuff/motor-asyncio-performance?embedable=true https://github.com/PylotStuff/motor-asyncio-performance?embedable=true Conclusion The choice between Motor and PyMongo depends on the specific needs of your application. For applications that require high concurrency and efficient I/O handling, Motor and the asynchronous approach offer significant advantages. However, for simpler applications or scripts where ease of implementation is a priority, PyMongo's synchronous approach might be sufficient. By leveraging asynchronous operations with Motor, you can build more scalable and performant applications, making it a worthwhile consideration for modern web development.

Boost MongoDB Performance: Motor Client vs PyMongo - Which is Faster?

Hi everyone! We're excited to announce that our reactive web UI framework is now public. This project has been in the works for quite some time, and we're excited to share it with you. Feel free to check it out and share your feedback! Website
GitHub
Demo Video What My Project Does Rio is a brand-new GUI framework designed to let you create modern web apps with just a few lines of Python. Our goal is to simplify web and app development, allowing you to focus on what matters most instead of getting stuck on complicated user interface details. We achieve this by adhering to the core principles of Python that we all know and love. Python is meant to be simple and concise, and Rio embodies this philosophy. There's no need to learn additional languages like HTML, CSS, or JavaScript, as all UI, logic, components, and even layout are managed entirely in Python. Moreover, there's no separation between front-end and back-end; Rio transparently handles all communication for you. Showcase Rio doesn't just serve HTML templates like you might be used to from frameworks like Flask. In Rio, you define components as simple data classes with a React/Flutter-style build method. Rio continuously watches your attributes for changes and updates the UI as necessary. class MyComponent(rio.Component):
        clicks: int = 0

        def _on_press(self) -> None:
            self.clicks += 1

        def build(self) -> rio.Component:
            return rio.Column(
                rio.Button('Click me', on_press=self._on_press),
                rio.Text(f'You clicked the button {self.clicks} time(s)'),
            )

    app = rio.App(build=MyComponent)
    app.run_in_browser() Notice how there is no need for any explicit HTTP requests. In fact, there isn't even a distinction between frontend and backend. Rio handles all communication transparently for you. Unlike ancient libraries like tkinter, Rio ships with over 50 built-in components in Google's Material Design. Moreover, the same exact codebase can be used for both local apps and websites. Key Features Full-Stack Web Development: Rio handles front-end and backend for you. In fact, you won't even notice they exist. Create your UI, and Rio will take care of the rest. Python Native: Rio apps are written in 100% Python, meaning you don't need to write a single line of CSS or JavaScript. Modern Python: We embrace modern Python features, such as type annotations and asynchrony. This keeps your code clean and maintainable and helps your code editor help you out with code completions and type checking. Python Debugger Compatible: Since Rio runs on Python, you can connect directly to the running process with a debugger. This makes it easy to identify and fix bugs in your code. Declarative Interface: Rio apps are built using reusable components, inspired by React, Flutter & Vue. They're declaratively combined to create modular and maintainable UIs. Batteries included: Over 50 builtin components based on Google's Material Design Target Audience Rio is perfect for developers who want to create web apps without spending time learning new languages. It’s also ideal for those who want to build modern, professional-looking apps without stressing over the details We Want Your Feedback! We welcome your thoughts and questions in the comments! If you like the project, please give us a star on GitHub to show your support and help us continue improving it. Hi everyone! We're excited to announce that our reactive web UI framework is now public. This project has been in the works for quite some time, and we're excited to share it with you. Feel free to check it out and share your feedback! Website GitHub Demo Video Website Website GitHub GitHub Demo Video Demo Video What My Project Does Rio is a brand-new GUI framework designed to let you create modern web apps with just a few lines of Python. Our goal is to simplify web and app development, allowing you to focus on what matters most instead of getting stuck on complicated user interface details. We achieve this by adhering to the core principles of Python that we all know and love. Python is meant to be simple and concise, and Rio embodies this philosophy. There's no need to learn additional languages like HTML, CSS, or JavaScript, as all UI, logic, components, and even layout are managed entirely in Python. Moreover, there's no separation between front-end and back-end; Rio transparently handles all communication for you. Showcase Rio doesn't just serve HTML templates like you might be used to from frameworks like Flask. In Rio, you define components as simple data classes with a React/Flutter-style build method. Rio continuously watches your attributes for changes and updates the UI as necessary. class MyComponent(rio.Component):
        clicks: int = 0

        def _on_press(self) -> None:
            self.clicks += 1

        def build(self) -> rio.Component:
            return rio.Column(
                rio.Button('Click me', on_press=self._on_press),
                rio.Text(f'You clicked the button {self.clicks} time(s)'),
            )

    app = rio.App(build=MyComponent)
    app.run_in_browser() class MyComponent(rio.Component):
        clicks: int = 0

        def _on_press(self) -> None:
            self.clicks += 1

        def build(self) -> rio.Component:
            return rio.Column(
                rio.Button('Click me', on_press=self._on_press),
                rio.Text(f'You clicked the button {self.clicks} time(s)'),
            )

    app = rio.App(build=MyComponent)
    app.run_in_browser() Notice how there is no need for any explicit HTTP requests. In fact, there isn't even a distinction between frontend and backend. Rio handles all communication transparently for you. Unlike ancient libraries like tkinter, Rio ships with over 50 built-in components in Google's Material Design. Moreover, the same exact codebase can be used for both local apps and websites. Key Features Full-Stack Web Development: Rio handles front-end and backend for you. In fact, you won't even notice they exist. Create your UI, and Rio will take care of the rest. Full-Stack Web Development: Rio handles front-end and backend for you. In fact, you won't even notice they exist. Create your UI, and Rio will take care of the rest. Full-Stack Web Development: Full-Stack Web Development: Python Native: Rio apps are written in 100% Python, meaning you don't need to write a single line of CSS or JavaScript. Python Native: Rio apps are written in 100% Python, meaning you don't need to write a single line of CSS or JavaScript. Python Native: Python Native: Modern Python: We embrace modern Python features, such as type annotations and asynchrony. This keeps your code clean and maintainable and helps your code editor help you out with code completions and type checking. Modern Python: We embrace modern Python features, such as type annotations and asynchrony. This keeps your code clean and maintainable and helps your code editor help you out with code completions and type checking. Modern Python: Modern Python: Python Debugger Compatible: Since Rio runs on Python, you can connect directly to the running process with a debugger. This makes it easy to identify and fix bugs in your code. Python Debugger Compatible: Since Rio runs on Python, you can connect directly to the running process with a debugger. This makes it easy to identify and fix bugs in your code. Python Debugger Compatible: Python Debugger Compatible: Declarative Interface: Rio apps are built using reusable components, inspired by React, Flutter & Vue. They're declaratively combined to create modular and maintainable UIs. Declarative Interface: Rio apps are built using reusable components, inspired by React, Flutter & Vue. They're declaratively combined to create modular and maintainable UIs. Declarative Interface: Declarative Interface: Batteries included: Over 50 builtin components based on Google's Material Design Batteries included: Over 50 builtin components based on Google's Material Design Batteries included: Batteries included: Target Audience Rio is perfect for developers who want to create web apps without spending time learning new languages. It’s also ideal for those who want to build modern, professional-looking apps without stressing over the details We Want Your Feedback! We welcome your thoughts and questions in the comments! If you like the project, please give us a star on GitHub to show your support and help us continue improving it. please give us a star on GitHub GitHub

Rio: WebApps in Pure Python - No JavaScript, HTML, or CSS Needed!

Authors:
(1) Nicholas Farn, Microsoft Corporation {Microsoft Corporation {nifarn@microsoft.com};
(2) Richard Shin, Microsoft Corporation {eush@microsoft.com}. Table of Links Abstract and Intro Dataset Design Evaluation Methodology Experiments and Analysis Related Work Conclusion, Reproducibility, and References A. Complete list of tools B. Scenario Prompt C. Unrealistic Queries D. Nuances comparing prior work 3 EVALUATION METHODOLOGY Evaluation of a tool-using assistant with ToolTalk consists of two phases. In the first phase, for each conversation, we take all prefixes that end in a user utterance (which could have been preceded by prior user utterances, the tool calls made for those utterances, the results of those calls, and the assistant’s response considering all of the above). We run the assistant with this prefix, where it can either predict a tool call or generate a response given the calls already made and their results; if the assistant predicts a tool call, we execute it using our simulated tool implementations and then provide the assistant with the result. In the second phase, for each conversation prefix, we compare the tool calls predicted for that prefix against its corresponding ground truth, computing the tool invocation recall and incorrect action rate as described below. 3.1 TOOL CALL CORRECTNESS As described in Section 2.1, for each action tool, we defined a function to compare a predicted and a ground truth invocation of that tool (considering the arguments in the invocations), to help us determine whether a predicted tool call should be considered equivalent to one in the ground truth. For example, if an email is required to be sent to multiple people, we only check that the set of emails are the same instead of requiring the exact same order. For argument fields that accept free-form natural language inputs, such as message bodies and event descriptions, we compute their embeddings with DistilBERT using sent2vec[2] and check whether their cosine similarity is above 0.9. For optional arguments, if the ground truth invocation has a value for one, then we compare its value against the one in the predicted invocation; if the ground truth invocation is missing a value for an optional argument, then it is entirely disregarded and the predicted call may have any value for that argument (or none at all) while still being considered correct. For example, the description of a calendar event is an optional argument, and if it is not explicitly mentioned in the conversation, then it is unlikely to impact the correctness of a predicted call whether or not it is filled out. For the non-action tools (which are generally tools for searching over a database), we do not compare the arguments in the tool calls, but rather compare the execution results of the predicted and ground truth tool calls. They are considered equivalent of the results are identical. 3.2 CONVERSATION SIMULATION Algorithm 1 shows the general pseudocode for conversation simulation. To simulate a conversation, we first reset the state of the world (e.g. databases get reset to their initial state). For each turn in the ground truth (consisting of a user’s utterance, tool calls for that utterance, and the assistant’s reply), we provide the information from all previous turns, followed by the current turn’s user utterance, to the model. We then let the model predict as many tool calls as it wants, executing them one at a time until the prediction model produces a reply to the user instead of a tool call. 3.3 INCORRECT ACTIONS Each tool is labeled as being either an action or not. We consider a tool an action if its execution has the ability to affect the external world such as sending messages or deleting calendar events. In comparison, non-action tools only passively references knowledge from the outside world such as looking up the weather or calling a calculator. We make this distinction between action and nonaction tools because incorrect calls to action tools are much more consequential. For example, an incorrect call to the DeleteAlarm tool could result in the user over-sleeping. While an assistant could theoretically realize that it made an incorrect action tool call and make a different one to reverse its effects, not all actions are reversible. Thus, during evaluation, we also track “incorrect” actions. We consider an action “incorrect” if the tool called is labeled as an action, it fails to match any call in the ground truth, and if the tool call executed without any errors (including by having the correct number of arguments and passing the correct types).[3] 3.4 METRICS We use the tool call correctness function, ftool, to compare each prediction to all tool calls in the ground truth; as described in Algorithm 2, each ground truth tool call can only match once to a predicted tool call. Given a set of M predictions matching ground truth (defined in equation 1), the set of all predictions P, and the set of all ground truth tool calls G we calculate precision and recall as |M|/|P| and |M|/|G| respectively. Additionally, we define A as the set of all actions predicted and I as the set of incorrect actions and calculate incorrect action rate as |I|/|A|. Additionally, we compute success as a boolean value for each conversation, following Equation 2. The assistant succeeds at a conversation if and only if it has perfect recall and no incorrect actions. We take success rate over all conversations as our key metric. Since success rate is a composite of two scores, we keep recall and incorrect action rate as additional metrics to provide more detail. We also include precision as a measure of efficiency in tool prediction; a higher precision indicates that there were fewer predicted tool calls that are unnecessary according to the ground truth. This paper is available on arxiv under CC 4.0 license. [2] https://github.com/pdrm83/sent2vec [3] For the SendEmail and SendMessage tools, we ignore errors which occur due to invalid recipient emails or usernames. Authors: (1) Nicholas Farn, Microsoft Corporation {Microsoft Corporation {nifarn@microsoft.com}; (2) Richard Shin, Microsoft Corporation {eush@microsoft.com}. Authors: Authors: (1) Nicholas Farn, Microsoft Corporation {Microsoft Corporation {nifarn@microsoft.com}; (2) Richard Shin, Microsoft Corporation {eush@microsoft.com}. Table of Links Abstract and Intro Abstract and Intro Dataset Design Dataset Design Evaluation Methodology Evaluation Methodology Experiments and Analysis Experiments and Analysis Related Work Related Work Conclusion, Reproducibility, and References Conclusion, Reproducibility, and References A. Complete list of tools A. Complete list of tools B. Scenario Prompt B. Scenario Prompt C. Unrealistic Queries C. Unrealistic Queries D. Nuances comparing prior work D. Nuances comparing prior work 3 EVALUATION METHODOLOGY Evaluation of a tool-using assistant with ToolTalk consists of two phases. In the first phase, for each conversation, we take all prefixes that end in a user utterance (which could have been preceded by prior user utterances, the tool calls made for those utterances, the results of those calls, and the assistant’s response considering all of the above). We run the assistant with this prefix, where it can either predict a tool call or generate a response given the calls already made and their results; if the assistant predicts a tool call, we execute it using our simulated tool implementations and then provide the assistant with the result. In the second phase, for each conversation prefix, we compare the tool calls predicted for that prefix against its corresponding ground truth, computing the tool invocation recall and incorrect action rate as described below. 3.1 TOOL CALL CORRECTNESS As described in Section 2.1, for each action tool, we defined a function to compare a predicted and a ground truth invocation of that tool (considering the arguments in the invocations), to help us determine whether a predicted tool call should be considered equivalent to one in the ground truth. For example, if an email is required to be sent to multiple people, we only check that the set of emails are the same instead of requiring the exact same order. For argument fields that accept free-form natural language inputs, such as message bodies and event descriptions, we compute their embeddings with DistilBERT using sent2vec[2] and check whether their cosine similarity is above 0.9. For optional arguments, if the ground truth invocation has a value for one, then we compare its value against the one in the predicted invocation; if the ground truth invocation is missing a value for an optional argument, then it is entirely disregarded and the predicted call may have any value for that argument (or none at all) while still being considered correct. For example, the description of a calendar event is an optional argument, and if it is not explicitly mentioned in the conversation, then it is unlikely to impact the correctness of a predicted call whether or not it is filled out. For the non-action tools (which are generally tools for searching over a database), we do not compare the arguments in the tool calls, but rather compare the execution results of the predicted and ground truth tool calls. They are considered equivalent of the results are identical. 3.2 CONVERSATION SIMULATION Algorithm 1 shows the general pseudocode for conversation simulation. To simulate a conversation, we first reset the state of the world (e.g. databases get reset to their initial state). For each turn in the ground truth (consisting of a user’s utterance, tool calls for that utterance, and the assistant’s reply), we provide the information from all previous turns, followed by the current turn’s user utterance, to the model. We then let the model predict as many tool calls as it wants, executing them one at a time until the prediction model produces a reply to the user instead of a tool call. 3.3 INCORRECT ACTIONS Each tool is labeled as being either an action or not. We consider a tool an action if its execution has the ability to affect the external world such as sending messages or deleting calendar events. In comparison, non-action tools only passively references knowledge from the outside world such as looking up the weather or calling a calculator. We make this distinction between action and nonaction tools because incorrect calls to action tools are much more consequential. For example, an incorrect call to the DeleteAlarm tool could result in the user over-sleeping. While an assistant could theoretically realize that it made an incorrect action tool call and make a different one to reverse its effects, not all actions are reversible. Thus, during evaluation, we also track “incorrect” actions. We consider an action “incorrect” if the tool called is labeled as an action, it fails to match any call in the ground truth, and if the tool call executed without any errors (including by having the correct number of arguments and passing the correct types).[3] 3.4 METRICS We use the tool call correctness function, f tool, to compare each prediction to all tool calls in the ground truth; as described in Algorithm 2, each ground truth tool call can only match once to a predicted tool call. Given a set of M predictions matching ground truth (defined in equation 1), the set of all predictions P, and the set of all ground truth tool calls G we calculate precision and recall f as |M|/|P| and |M|/|G| respectively. Additionally, we define A as the set of all actions predicted and I as the set of incorrect actions and calculate incorrect action rate as |I|/|A|. Additionally, we compute success as a boolean value for each conversation, following Equation 2. The assistant succeeds at a conversation if and only if it has perfect recall and no incorrect actions. We take success rate over all conversations as our key metric. Since success rate is a composite of two scores, we keep recall and incorrect action rate as additional metrics to provide more detail. We also include precision as a measure of efficiency in tool prediction; a higher precision indicates that there were fewer predicted tool calls that are unnecessary according to the ground truth. This paper is available on arxiv under CC 4.0 license. This paper is available on arxiv under CC 4.0 license. available on arxiv [2] https://github.com/pdrm83/sent2vec [3] For the SendEmail and SendMessage tools, we ignore errors which occur due to invalid recipient emails or usernames.

Stories, News & Mentions about FYTO

Fyto’s Stories on HackerNoon